Un formulaire de contact utile demande les informations dont votre équipe a besoin pour répondre, explique la suite et aide les visiteurs à corriger les problèmes. Avant de valider un nouveau formulaire, vérifiez tout le parcours de demande : saisir les informations, corriger une erreur, recevoir une confirmation claire et retrouver la demande à la destination convenue.
Cette checklist s'adresse aux entreprises qui préparent le cahier des charges d'un site de services ou en évaluent la réalisation. Elle transforme « ajouter un formulaire de contact » en décisions qu'un prestataire peut mettre en œuvre et démontrer. Les champs et les modalités d'acheminement adaptés dépendent de la façon dont votre entreprise traite les demandes.
1. Définir la demande et l'action suivante
Commencez par la question à laquelle le formulaire doit répondre. La personne souhaite-t-elle se renseigner sur un service, demander un devis ou signaler un problème ? Ces parcours peuvent nécessiter des informations et des destinations différentes. Un formulaire de demande générale ne devrait pas devenir discrètement un dossier de candidature, un système de réservation ou un processus de tickets d'assistance sans raison claire.
Résumez l'objectif en une phrase, puis nommez la personne ou l'équipe qui lira la demande. Décrivez son action suivante : répondre par e-mail, organiser un appel ou demander un brief de projet. Partez de cette action pour déterminer les informations nécessaires au premier contact. Si personne n'utilise un champ pour orienter la demande ou y répondre, envisagez de le supprimer ou de recueillir cette information plus tard.
Indiquez des attentes réalistes à côté du formulaire. Précisez le type de demande accepté et la façon dont l'entreprise répondra. N'annoncez un délai de réponse que si votre équipe peut le respecter. Un formulaire indiquant « Réserver maintenant » ne devrait pas simplement envoyer une demande non confirmée par e-mail ; son bouton et sa confirmation doivent décrire ce qui se passe réellement.
Séparer le premier contact de la qualification
Un visiteur ne connaît pas forcément encore son budget, son calendrier ou ses exigences techniques. Déterminez quelles inconnues empêchent réellement votre équipe de répondre. Lorsqu'un choix aide à orienter la demande, proposez une option appropriée comme « Je ne sais pas encore ». Réservez les questions de découverte détaillées à une conversation ultérieure si le visiteur a besoin de plus de contexte pour y répondre.
2. Donner une raison d'être à chaque champ
Utilisez le tableau ci-dessous pour examiner le formulaire proposé. Il s'agit d'un exemple de demande de service traitée par e-mail, pas d'un minimum universel ni d'une consigne de recueillir les six éléments. Indiquez si chaque champ retenu est obligatoire ou facultatif et notez comment l'équipe destinataire l'utilisera. Rendez ces choix visibles dans l'interface.
| Champ possible | Raison de l'inclure | Question avant de le rendre obligatoire |
|---|---|---|
| Adresse e-mail | Donner à l'équipe un moyen de répondre | L'e-mail est-il le canal de réponse annoncé ? |
| Nom | S'adresser à la personne dans la réponse | La première réponse exige-t-elle vraiment le nom légal complet ? |
| Message ou résumé du projet | Comprendre la demande dans les mots du visiteur | Une courte indication aiderait-elle la personne à commencer ? |
| Choix du service | Orienter les demandes vers la bonne équipe | Les visiteurs peuvent-ils choisir « Je ne sais pas » ou décrire un autre besoin ? |
| Numéro de téléphone | Permettre une réponse téléphonique convenue | L'équipe peut-elle répondre sans appeler ? |
| Budget ou calendrier | Identifier les contraintes pratiques du projet | Ces précisions peuvent-elles être discutées après le premier contact ? |
Examinez les règles restrictives avec autant de soin que la liste des champs. Les noms peuvent contenir des espaces, des accents ou de la ponctuation ; les numéros de téléphone internationaux peuvent inclure un indicatif de pays. Ne rejetez pas des informations plausibles parce qu'un prototype n'a été testé qu'avec un seul exemple. Demandez au prestataire d'expliquer les limites de longueur et les formats autorisés dans un langage courant.
Pour une demande générale, évitez de demander des mots de passe, des informations de paiement ou des documents sensibles. Si l'ajout de fichiers est nécessaire, définissez-en explicitement le périmètre avec l'équipe technique responsable, notamment les types acceptés, les limites de taille, le stockage et l'accès. Un champ de fichier ajoute des responsabilités absentes d'une simple demande textuelle. Expliquez le traitement des données concerné dans les informations de confidentialité appropriées du site, au lieu de dissimuler les détails opérationnels derrière une case à cocher vague.
3. Faciliter les libellés et la saisie sur mobile
Chaque champ a besoin d'un libellé clair qui reste disponible pendant la saisie. Des exemples dans le texte indicatif peuvent expliquer un format, mais un texte indicatif qui disparaît ne doit pas constituer le seul libellé. Le tutoriel du W3C sur les formulaires recommande des libellés, des instructions, une structure adaptée et des retours pour rendre les formulaires plus faciles à comprendre et à utiliser. Demandez ces éléments fondamentaux dans le cahier des charges au lieu de vous fier uniquement à la qualité visuelle.
Utilisez des libellés précis comme « Adresse e-mail » et « Comment pouvons-nous vous aider ? » plutôt que le vocabulaire interne de l'entreprise. Placez les instructions utiles avant l'action qu'elles expliquent. Si un message a une limite de longueur ou qu'un champ téléphonique attend un format précis, affichez cette information là où elle est nécessaire. Le caractère obligatoire ou facultatif doit être compréhensible sans devoir interpréter uniquement la couleur.
Vérifiez le formulaire proposé sur un écran de téléphone étroit. Les libellés doivent passer proprement à la ligne, les champs tenir dans la page et le clavier virtuel ne doit pas rendre l'action suivante inaccessible. Demandez au développeur d'utiliser des types de saisie et des indications de remplissage automatique adaptés. MDN explique comment l'attribut autocomplete décrit au navigateur les informations attendues. Le comportement réel du remplissage automatique dépend toutefois du navigateur et des informations enregistrées par l'utilisateur.
Parcourez au clavier toutes les commandes dans un ordre logique, y compris les cases à cocher, les liens d'aide et le bouton d'envoi. Le focus actif doit être visible. Intégrez un contrôle avec lecteur d'écran à l'évaluation d'accessibilité convenue afin d'examiner les libellés et les retours au-delà de leur apparence. Réussir une inspection visuelle ou obtenir un score automatisé ne suffit pas à établir une accessibilité complète.
4. Prévoir les erreurs et leur correction avant le parcours idéal
Demandez à voir un champ obligatoire laissé vide, une adresse e-mail mal formatée et un envoi qui ne peut pas aboutir. Ce sont des situations différentes qui ne doivent pas toutes produire le même message « Une erreur est survenue ». Les retours associés aux champs doivent indiquer ce qui nécessite une intervention et proposer une correction utile, par exemple demander une adresse e-mail au format attendu.
Après une erreur, conservez les informations que la personne ne devrait pas avoir à ressaisir, lorsque la mise en œuvre le permet en toute sécurité. Rendez le problème facile à repérer sans compter uniquement sur un contour rouge. Les recommandations du W3C sur les notifications de formulaire expliquent comment fournir des retours clairs, globaux et au niveau des champs, y compris une confirmation de réussite. La personne chargée de la vérification doit contrôler que ces retours sont accessibles aux technologies d'assistance et pas seulement affichés à l'écran.
Convenez du comportement à adopter lorsque la réponse est lente. L'interface doit indiquer que l'envoi est en cours et gérer les activations répétées de manière délibérée. Si le résultat est incertain, évitez de demander aux visiteurs de continuer à cliquer jusqu'à ce qu'il se passe quelque chose. Proposez une prochaine étape compréhensible et un autre moyen de contact adapté à l'entreprise.
Les vérifications du navigateur aident les utilisateurs à corriger rapidement leur saisie, mais elles ne constituent pas toute la mise en œuvre. MDN distingue la validation côté client des contrôles côté serveur également nécessaires. Demandez au prestataire de décrire la validation serveur, la protection contre les abus et la gestion des erreurs incluses dans votre périmètre. Ne considérez pas un astérisque de champ obligatoire ou une vérification du format d'e-mail comme une preuve de sécurité.
5. Distinguer confirmation, acheminement et réponse
Un écran de réussite doit décrire l'étape réellement atteinte par le système. L'acceptation par le service de formulaire, l'arrivée dans la boîte de réception d'une équipe et une réponse humaine sont des événements distincts. Demandez au prestataire ce qui doit se produire avant que le site affiche une réussite, où la demande est conservée ou transférée et comment l'équipe responsable détecte un problème d'acheminement.
Choisissez la destination avec soin. Consignez la boîte de réception ou le système, la personne qui en est responsable dans l'entreprise et un contact de secours pour les problèmes opérationnels. Confirmez qui gère le compte et tout abonnement dont il dépend. Si plusieurs personnes reçoivent une copie des demandes, convenez de qui répond afin d'éviter des réponses contradictoires au visiteur.
Décidez si le visiteur reçoit un accusé de réception par e-mail. S'il est prévu, examinez son objet, son expéditeur, sa langue et sa formulation comme un livrable distinct. Il ne doit pas promettre un rendez-vous confirmé ou un projet convenu si le système ne l'a pas réellement créé. Définissez séparément le périmètre de tout parcours marketing ultérieur et celui de la réponse immédiate à une demande.
Une demande fictive adressée à un cabinet de conseil
Imaginez un cabinet de conseil qui répond par e-mail. Il choisit un champ d'adresse e-mail et un message court, avec un nom et un choix de service facultatifs. L'aperçu signale clairement un format d'adresse e-mail invalide et conserve le message après correction. Dans un environnement de test convenu, la demande acceptée atteint la destination désignée de l'équipe et la confirmation explique l'étape suivante. Cet exemple illustre une méthode de recette, pas un résultat client rapporté.
6. Convenir d'un test de recette sûr et documenté
Rédigez un petit plan de test avant la mise en ligne. Nommez l'environnement d'aperçu ou de test, les adresses de test autorisées et les destinations prévues. Utilisez des contenus fictifs et coordonnez les messages de test avec l'équipe destinataire. N'envoyez pas de véritables données clients, ne créez pas de rendez-vous involontaires et n'expédiez pas de messages inattendus simplement pour voir si le bouton fonctionne.
Couvrez une demande valide, des informations obligatoires manquantes, une erreur de format, une réponse lente ou un échec, ainsi que les activations répétées. Incluez les textes longs, les caractères accentués, la navigation au clavier et une zone d'affichage mobile étroite. Pour un formulaire multilingue, vérifiez les libellés, la validation, la confirmation et tout accusé de réception dans chaque langue prise en charge ; traduire uniquement le titre de la page ne complète pas le parcours.
Consignez ce que chaque vérification prouve réellement. Une capture d'écran montre le retour affiché. La réception d'un test à la destination convenue prouve que cette demande précise est arrivée. Ni l'une ni l'autre ne prouve que tous les messages futurs seront acheminés ou recevront une réponse. Conservez la version testée, la date, le scénario, le résultat et tout problème non résolu afin que la décision de mise en ligne repose sur des éléments que l'équipe pourra réexaminer.
Attribuez à chaque problème non résolu une personne responsable et une prochaine action. Convenez des problèmes qui bloquent la mise en ligne, comme l'absence de moyen de réponse ou un état de réussite trompeur. Documentez comment signaler les défaillances ultérieures et qui vérifie la destination après une modification de compte ou d'intégration. Il s'agit d'un accord pratique de fonctionnement, pas d'une obligation d'acheter un produit de surveillance particulier.
7. Intégrer tout le parcours au cahier des charges du site
Le cahier des charges du formulaire doit désormais inclure son objectif, les champs, le canal de réponse, les libellés, les états d'erreur, le texte de confirmation, la destination et les vérifications de recette. Ajoutez ces décisions au cahier des charges du projet web avant de commencer la conception et le développement. Si les demandes doivent entrer dans un processus commercial, utilisez le guide distinct sur l'automatisation CRM pour planifier ce processus en aval.
Avant d'accepter la livraison, confirmez qu'un visiteur peut terminer le parcours prévu, corriger une erreur et comprendre l'étape suivante. Vérifiez la destination convenue au moyen d'un test coordonné et conservez les notes de fonctionnement avec les documents de passation du site. Un formulaire fonctionnel comprend à la fois une interface utilisable et une responsabilité clairement attribuée dans l'entreprise pour le traitement de la demande.
Chez Digital Studio, la création de site web commence à 2 190 EUR pour une réalisation ponctuelle de cinq pages maximum à partir des contenus fournis, avec un design responsive, les bases du SEO, un formulaire de demande et la mise en ligne sur votre domaine. Les formulaires conditionnels, l'ajout de fichiers, les parcours de réservation, les connexions CRM et la surveillance continue doivent être discutés et convenus pour votre projet ; cette checklist ne les ajoute pas à l'offre publiée. Décrivez votre site et vos besoins en matière de demandes afin de définir le périmètre du parcours nécessaire avant le début des travaux.
