Questions fréquentes

Lethavia peut étudier les besoins de PME, d’organisations de services, d’organismes, d’équipes internes et de porteurs de produits qui doivent créer ou faire évoluer un logiciel, une application, une plateforme, un site professionnel, un commerce en ligne ou un processus automatisé. La pertinence est évaluée selon le problème à résoudre, les utilisateurs concernés, le niveau de risque, la disponibilité des parties prenantes et la capacité à prendre des décisions pendant le projet. Lorsqu’un besoin sort du champ d’expertise ou nécessite une spécialité complémentaire, cela doit être indiqué clairement dès le départ.

Non. Une description honnête du processus actuel, du problème, des personnes touchées et du résultat recherché suffit pour commencer. Le cadrage sert justement à transformer ces informations en priorités, limites, dépendances, scénarios utilisateurs et critères de réussite. Un cahier des charges existant peut accélérer l’analyse, mais il sera tout de même vérifié afin d’éviter de construire sur des hypothèses devenues inexactes.

Ils sont définis après une phase de découverte proportionnée à la complexité du projet. Lethavia examine les fonctionnalités prioritaires, les intégrations, les données, la sécurité, l’accessibilité, le contenu, les appareils visés, les responsabilités internes et les contraintes de lancement. La proposition doit préciser ce qui est inclus, ce qui ne l’est pas, les hypothèses, les livrables, les étapes de validation et les facteurs pouvant modifier l’échéancier ou le budget.

Oui, et c’est souvent préférable. Une première version utile peut être isolée, testée avec de vrais utilisateurs et enrichie par étapes, sans sacrifier la qualité de la fondation. Cette approche permet de valider les décisions plus tôt, de limiter le risque et d’investir en priorité dans ce qui produit réellement de la valeur. Les étapes doivent toutefois être cohérentes entre elles afin d’éviter une succession de correctifs temporaires difficiles à maintenir.

Oui, après un diagnostic de la base actuelle. Le travail commence par comprendre l’architecture, les données, les dépendances, les incidents connus, les contraintes d’hébergement et les processus critiques. L’objectif n’est pas automatiquement de tout reconstruire : certaines parties peuvent être stabilisées, isolées, remplacées ou migrées progressivement. Un plan de retour arrière, des sauvegardes et une stratégie de continuité doivent accompagner les changements sensibles.

Les responsabilités et les droits doivent être écrits dans l’entente. L’organisation devrait conserver le contrôle de son nom de domaine, de ses comptes d’hébergement, de ses données et des accès administratifs essentiels. La propriété du code sur mesure, des composants réutilisables, des licences tierces et des éléments de marque doit être précisée avant le début des travaux. Lethavia privilégie une structure qui évite de rendre le client dépendant d’un compte qu’il ne contrôle pas.

Ces sujets sont intégrés au cadrage, à l’architecture et aux critères de validation plutôt qu’ajoutés à la fin. Selon le contexte, cela comprend la minimisation des données, la validation des entrées, le contrôle des accès, la gestion des secrets, la journalisation utile, les sauvegardes, les limites de téléversement, les parcours clavier, le contraste et les technologies d’assistance. Les mesures sont adaptées aux risques réels et aux obligations applicables; un site public simple n’a pas le même profil qu’un portail contenant des informations sensibles.

Oui. Les routes, les composants, les messages de validation, les métadonnées, le contenu et les parcours peuvent être structurés pour le français canadien et l’anglais canadien dès la fondation. L’objectif n’est pas seulement de traduire les mots, mais d’adapter les formulations, les formats, le référencement et les attentes de chaque marché. Une architecture bien préparée peut ensuite accueillir d’autres langues sans dupliquer toute l’application.

Une migration SEO sérieuse commence par l’inventaire des URL existantes, des pages indexées, des métadonnées, des liens internes et des contenus qui génèrent du trafic. Les redirections permanentes, les URL canoniques, les variantes linguistiques, le sitemap, les données structurées et les performances doivent être vérifiés avant et après le lancement. Il est impossible de garantir un classement précis, mais il est possible de réduire fortement les pertes évitables et de mesurer les changements dans Search Console et Analytics.

L’hébergement, le domaine, les environnements et les responsabilités de déploiement sont discutés selon le projet. Lethavia peut préparer l’architecture, les variables d’environnement, les contrôles de production et la documentation nécessaires, puis accompagner la mise en ligne. L’organisation doit toutefois rester propriétaire de ses comptes principaux. Les coûts récurrents, les sauvegardes, les limites du fournisseur et la procédure d’urgence doivent être connus avant le lancement.

Le modèle dépend du niveau de certitude. Un périmètre bien défini peut être structuré par phase ou au forfait, tandis qu’une initiative encore exploratoire peut commencer par un mandat de découverte. Lorsque les priorités doivent évoluer pendant la réalisation, une capacité réservée ou une facturation au temps peut être plus appropriée. Dans tous les cas, le modèle, les limites, les modalités de paiement, les validations et la gestion des demandes supplémentaires doivent être documentés.

La demande est examinée pour comprendre le besoin, vérifier les contraintes évidentes et déterminer si une conversation exploratoire est pertinente. Les informations manquantes sont clarifiées avant toute estimation. Un premier échange peut ensuite servir à confirmer le contexte, les décideurs, le calendrier, le budget indicatif et la prochaine étape. L’envoi du formulaire ne crée pas automatiquement un engagement contractuel et les documents transmis restent soumis aux règles de confidentialité du site.

Selon l’entente, la suite peut inclure une période de stabilisation, la surveillance des erreurs, les mises à jour de sécurité, l’amélioration de la performance, le soutien opérationnel, la documentation, la formation et l’évolution du produit. La continuité ne doit pas rester implicite : les responsabilités, les délais de réponse, les niveaux de priorité, les sauvegardes et la façon de demander une évolution sont définis avant le lancement. Un projet bien livré doit pouvoir être compris et repris par une autre personne qualifiée.

Les indicateurs doivent être reliés aux objectifs du projet : réduction du temps de traitement, diminution des erreurs, adoption, conversion, satisfaction, performance ou disponibilité. Analytics peut mesurer les interactions générales sans envoyer de informations personnels, tandis que les données opérationnelles doivent rester dans les systèmes appropriés. Un bilan après lancement permet de distinguer les problèmes techniques, les difficultés d’adoption et les nouvelles possibilités d’amélioration.