Avant d’approuver la mise en ligne d’un site en français et en anglais, suivez une demande de soumission jusqu’à la personne qui doit la traiter. Ouvrez la page du service, remplissez le formulaire, vérifiez ce que le visiteur reçoit, puis retrouvez la demande dans l’outil de votre équipe.
Ce parcours donne un critère concret pour accepter le travail. Une page peut être bien présentée alors que la confirmation, la langue de réponse ou l’affectation de la demande restent à régler.
La méthode ci-dessous porte sur un seul service et ses deux versions linguistiques. Elle convient à une refonte comme à l’ajout d’un nouveau parcours sur un site existant. Elle complète les autres vérifications du projet, notamment le contenu, les redirections depuis les anciennes pages, la performance et les droits d’accès.
Définir ce qui doit se passer
Commencez par une phrase que le responsable du service et la personne qui construit le site peuvent approuver :
Une personne intéressée par notre service peut décrire son projet en français ou en anglais. La demande arrive dans notre outil de suivi avec les renseignements convenus, et la personne désignée sait qu’elle doit la traiter.
Précisez ensuite le point d’arrivée. Il peut s’agir d’une boîte courriel surveillée, du tableau des réponses d’un formulaire hébergé ou d’un CRM déjà utilisé. Choisissez celui dans lequel votre équipe travaille réellement. L’achat d’un nouveau logiciel n’est pas un préalable à ce test.
Notez aussi la prochaine étape annoncée au visiteur : examen de la demande, appel de qualification ou proposition de rendez-vous. Une demande de soumission ne doit pas donner l’impression qu’un prix, une intervention ou une réservation est déjà confirmé.
Préparer un essai reconnaissable
Convenez du test avec votre équipe et votre prestataire. Utilisez de préférence l’environnement de test du projet, des coordonnées que vous contrôlez et des renseignements fictifs. Inscrivez un repère comme « ESSAI FR 01 » dans le message pour retrouver facilement la demande.
Prévoyez un essai français et un essai anglais, sur un téléphone puis sur un ordinateur. Si plusieurs parcours ou branches sont prévus au contrat, ajoutez un cas pour chacun. Il ne suffit pas de tester seulement le chemin le plus court.
Si une réservation ou un paiement fait partie du parcours, utilisez le mode de test convenu. Après la mise en ligne, refaites un essai contrôlé avec l’équipe, sans créer de fausse commande ou de rendez-vous laissé dans un agenda de production.
1. Vérifier que le changement de langue garde le bon contexte
Ouvrez directement la page française du service. Passez à l’anglais, puis revenez au français. Vous devriez retrouver le même service et pouvoir entreprendre la même démarche.
Vérifiez les éléments qui influencent la décision : ce que le service comprend, le territoire desservi, les conditions annoncées et le bouton qui mène au formulaire. Les textes n’ont pas besoin d’être des traductions mot à mot, mais ils doivent décrire la même offre approuvée.
Pour le référencement, Google recommande des adresses distinctes pour les versions linguistiques et des liens permettant de choisir sa langue. Demandez à votre prestataire de vérifier leur configuration. Ce contrôle technique accompagne le test du parcours; il ne promet aucune position dans les résultats de recherche.[1]
2. Remplir le formulaire, puis provoquer une erreur simple
Sur téléphone, commencez à saisir une demande. Les libellés doivent rester compréhensibles lorsque vous écrivez. Vérifiez que les questions, les choix et les instructions correspondent à la langue de la page. W3C recommande d’identifier les champs avec des libellés correctement associés aux commandes du formulaire.[2]
Essayez ensuite de soumettre le formulaire en laissant un champ obligatoire vide. Repérez ce qui est indiqué, où le message apparaît et comment revenir au champ concerné. Refaites l’essai dans l’autre langue.
Le message doit expliquer la correction attendue. « Indiquez une adresse courriel valide » est plus utile qu’un simple code d’erreur. W3C recommande une rétroaction claire après l’envoi, tant pour les erreurs que pour la réussite.[3]
Sur ordinateur, parcourez aussi le formulaire au clavier. Notez tout champ impossible à atteindre ou toute étape où le champ ou le bouton actif devient difficile à repérer. Ces essais repèrent des problèmes concrets; ils ne constituent pas une évaluation complète de l’accessibilité.
3. Lire la confirmation comme un client
Envoyez maintenant la demande complète. Lisez le message affiché et, si le parcours le prévoit, le courriel reçu.
La confirmation indique-t-elle la bonne prochaine étape ? La langue est-elle cohérente ? Les coordonnées sont-elles à jour ? Si un délai de réponse est annoncé, a-t-il été validé par la personne qui doit le respecter ?
Voici un exemple fictif de confirmation à adapter :
Votre demande a été reçue. Notre équipe examinera les renseignements transmis avant de vous proposer la prochaine étape. Cet envoi ne confirme pas une intervention.
Le texte exact dépend du service et du fonctionnement réel de l’entreprise. Évitez d’ajouter automatiquement une promesse de réponse rapide que personne n’a acceptée.
4. Retrouver la demande du côté de l’équipe
Demandez au responsable d’ouvrir l’outil de destination et de retrouver « ESSAI FR 01 ». Comparez les renseignements affichés avec ceux qui ont été saisis : service, description, coordonnées et langue de communication lorsqu’elle fait partie du parcours convenu.
Si une pièce jointe était prévue, vérifiez qu’elle est disponible pour la bonne personne. Si une notification était prévue, vérifiez sa réception. Confirmez enfin qui prend la demande en charge et où cette responsabilité est visible.
Dans un exemple fictif d’entreprise de rénovation commerciale, le formulaire pourrait transmettre un type de projet, une municipalité et une description au responsable des demandes. Le test consiste à retrouver ces valeurs au bon endroit. Il ne permet pas encore de décider si le projet est réalisable ou rentable.
Convenez également du traitement des incidents. Qui est averti si la connexion au CRM échoue ? Où peut-on retrouver une demande en attente de transfert ? Que fait l’équipe si un visiteur soumet deux fois le même projet ? Faites démontrer les cas prévus dans le périmètre du projet, dans un environnement où l’essai ne perturbera pas les opérations.
5. Conserver une fiche d’acceptation
Pour chaque cas, inscrivez le résultat attendu, le résultat observé et ce qui doit être corrigé puis testé de nouveau. Une simple fiche partagée suffit.
| Point à vérifier | Preuve à conserver |
|---|---|
| Même service dans les deux langues | Adresses des pages testées et observation |
| Formulaire utilisable | Appareil, navigateur, langue et résultat |
| Erreur compréhensible | Champ testé et message observé |
| Confirmation exacte | Texte affiché et courriel, s’il est prévu |
| Demande reçue | Repère de test retrouvé dans l’outil convenu |
| Prise en charge définie | Nom du responsable ou règle d’affectation |
| Incident traité | Cas testé, résultat et procédure convenue |
| Correction vérifiée | Date du nouvel essai et résultat |
Conservez des captures avec des données fictives. Une anomalie qui empêche l’envoi ou la réception mérite une décision explicite avant le lancement. Pour les autres points, attribuez un responsable et une date de correction, puis refaites le cas concerné.
Mesurer la demande sans la confondre avec une vente
Si Google Analytics fait partie du projet, vérifiez ce que chaque événement représente. Sa mesure améliorée distingue notamment le début d’interaction avec un formulaire et sa soumission. Google précise aussi qu’aucun renseignement permettant d’identifier une personne ne doit être transmis à Analytics.[4]
Dans votre fiche, gardez des contrôles distincts pour l’événement analytique, la réception dans l’outil et la qualification par l’équipe. Notre recommandation est de vérifier les trois séparément : un compteur de formulaires ne remplace pas la lecture d’une demande et ne démontre pas une vente.
Préparer le bon projet
Cette vérification aide à définir ce qui manque réellement. Il peut s’agir d’un texte de confirmation, d’un formulaire, d’une connexion à votre outil actuel ou d’un parcours plus complet.
Pixel & Practice conçoit des sites bilingues et les systèmes qui les accompagnent, à Montréal. Pour discuter d’un projet, indiquez le service concerné, l’outil dans lequel votre équipe reçoit les demandes et l’étape que vous souhaitez améliorer. Nous convenons des livrables, des responsabilités et des critères d’acceptation avant le début des travaux.
Sources
- Google Search Central, Managing multi-regional and multilingual sites, mis à jour le 10 décembre 2025, consulté le 12 septembre 2026.
- W3C Web Accessibility Initiative, Labeling Controls, mis à jour le 13 mai 2024, consulté le 12 septembre 2026.
- W3C Web Accessibility Initiative, User Notification, mis à jour le 3 juin 2022, consulté le 12 septembre 2026.
- Google Analytics Help, Enhanced measurement events, page non datée, consultée le 12 septembre 2026.