Aller au contenu
← Idées

Comment concevoir un formulaire professionnel qui recueille des données utiles sans créer de friction

Concevez des formulaires qui facilitent l’action suivante : définissez l’utilité de chaque champ, limitez les champs obligatoires et testez les erreurs, les exceptions et les appareils.

Personne examinant à l’écran un formulaire professionnel aux champs organisés et aux choix clairement présentés

Un formulaire n’est pas une liste de données à recueillir « au cas où ». Il fait partie d’un processus : une personne le remplit pour faire une demande, créer un compte ou signaler un besoin, puis une autre personne ou un système doit agir à partir des réponses. Si les données reçues sont incomplètes, ambiguës ou difficiles à exploiter, ajouter des questions ne résout pas toujours le problème. Cela peut augmenter le nombre d’abandons et entraîner encore plus de corrections.

Lorsqu’on conçoit un formulaire professionnel, la question centrale est de savoir quelle décision ou quelle action chaque réponse doit permettre. À partir de là, on peut déterminer quelles informations sont nécessaires, quand les demander et comment aider la personne à les fournir. Ce guide propose des critères pratiques pour y parvenir, de la sélection des champs à l’évaluation continue de la qualité des données recueillies.

Commencez par l’action à réaliser, pas par la liste des champs

Commencez par l’action à réaliser, pas par la liste des champs

Avant de rédiger les questions, décrivez ce qui se passe lorsqu’une réponse est reçue. Il peut s’agir, par exemple, d’attribuer une demande à une équipe, de préparer une proposition, de vérifier un compte ou de coordonner une intervention. Identifiez qui utilise les données et ce que cette personne doit savoir pour accomplir sa tâche sans avoir à recontacter l’auteur du formulaire.

Retracez ensuite le parcours qui mène de la réponse à l’action. Si une donnée ne modifie ni la décision, ni l’attribution, ni l’application d’une règle, ni une étape ultérieure, il n’est peut-être pas nécessaire de la demander immédiatement. Elle pourra être utile plus tard, sans pour autant devoir figurer sur le premier écran. Distinguez les informations indispensables pour lancer le processus de celles qu’il est possible de recueillir au moment où elles deviennent réellement nécessaires.

Il est utile de valider cette cartographie avec les personnes qui reçoivent et traitent les réponses. La personne qui demande un champ n’est pas forcément celle qui résout le cas. Demandez quelles informations manquent le plus souvent, quelles ambiguïtés imposent de demander des précisions et quelles données sont rarement utilisées. Cet échange permet de repérer aussi bien les questions manquantes que les questions héritées du passé qui ne sont plus utiles.

Attribuez un objectif à chaque champ et décidez s’il est obligatoire

Pour chaque champ, consignez simplement son objectif, les personnes qui utilisent la réponse, l’action qu’elle permet et les conséquences d’une absence de réponse. Si ces éléments ne sont pas clairs, supprimez le champ, reportez-le ou justifiez mieux sa nécessité. Cette vérification aide également à repérer les doublons : deux questions peuvent demander la même information avec des mots différents, ou une donnée peut être obtenue dans un système autorisé au lieu d’être redemandée à la personne.

Rendez un champ obligatoire uniquement si empêcher l’envoi sans cette information est nécessaire pour lancer correctement le processus. Ne le marquez pas comme obligatoire simplement parce que la réponse pourrait être utile. Une question pratique à se poser est la suivante : quelle conséquence concrète y a-t-il à ne pas connaître cette réponse maintenant ? Si la réponse est « aucune ; quelqu’un la consultera peut-être plus tard », le champ devrait probablement être facultatif ou être présenté à une autre étape.

  • Obligatoire : sans cette donnée, l’étape suivante est impossible ou une règle essentielle ne peut pas être appliquée.
  • Facultatif : la réponse apporte du contexte, mais le processus peut avancer sans elle.
  • Conditionnel : la question n’apparaît que si une réponse précédente la rend pertinente.

Les questions conditionnelles réduisent la charge pour les personnes qui n’ont pas besoin d’y répondre. Par exemple, si la personne indique qu’elle agit au nom d’une organisation, il peut être pertinent d’afficher un champ permettant d’identifier cette organisation. La condition doit être compréhensible et ne pas créer d’impasse pour les cas valides qui ne correspondent pas à l’option prévue.

Choisissez des formats qui limitent les réponses ambiguës

Le type de champ influe sur la qualité des données. Une liste de choix est utile lorsque les possibilités sont connues et compréhensibles ; un champ libre convient mieux lorsque les réponses peuvent varier et que l’équipe doit les lire. Ne transformez pas une liste en obligation de choisir une réponse incorrecte simplement pour pouvoir continuer.

Utilisez des formats structurés lorsqu’ils répondent à un besoin opérationnel. Une date répartie en plusieurs champs peut faciliter le traitement ultérieur, mais se révéler moins pratique qu’un sélecteur clair. Une longue liste peut être difficile à parcourir ; si les choix sont nombreux ou évoluent, prévoyez un moyen de les distinguer sans ambiguïté. Dans chaque cas, réfléchissez à la façon dont la réponse sera enregistrée et utilisée, et pas seulement à son apparence à l’écran.

Des exemples peuvent préciser le niveau de détail attendu. Au lieu d’une indication générique telle que « Informations complémentaires », une consigne brève peut expliquer quoi inclure, par exemple le numéro de référence, s’il est disponible. Évitez les exemples qui ressemblent à des exigences implicites ou qui incitent à communiquer des données personnelles inutiles. Les libellés doivent nommer l’information demandée ; les consignes doivent expliquer comment la fournir ou, si cela aide la personne à décider, à quoi elle servira.

Lorsque cela favorise la confiance ou aide à remplir la demande, expliquez de manière accessible l’utilisation des informations. Ne demandez que les données nécessaires à l’objectif défini et limitez leur accès aux personnes qui en ont besoin pour ce processus. Si des informations sensibles sont concernées, vérifiez les règles applicables avec les personnes responsables avant de les intégrer au formulaire ; ne les demandez pas par simple commodité.

Intégrez la validation et la gestion des erreurs au recueil des données

Une validation utile prévient les erreurs réelles sans rejeter les réponses valides. Avant d’imposer un format, vérifiez que l’équipe a besoin de ce niveau de précision. Par exemple, si un numéro de téléphone est demandé pour reprendre contact, une règle trop stricte peut exclure des numéros légitimes. Si une date est nécessaire pour planifier une action, indiquez le format attendu et vérifiez que la date est cohérente avec le processus.

Lorsqu’une réponse n’est pas acceptable, indiquez quel champ doit être vérifié, quel est le problème et comment le corriger. Évitez les messages vagues comme « Erreur dans le formulaire », qui obligent la personne à chercher elle-même ce qui ne va pas. En cas d’erreur de validation ou d’interruption, conservez les réponses déjà saisies, dans la mesure où la conception et les conditions du système le permettent. Si la progression ne peut pas être enregistrée, signalez cette limite avant que la personne ne consacre du temps au formulaire.

Testez aussi les situations incomplètes et les exceptions : une organisation qui ne possède pas la donnée demandée, une demande ne correspondant à aucune catégorie ou une personne qui ne connaît pas encore la réponse. Déterminez si elle peut poursuivre, s’il faut proposer un choix tel que « Je ne sais pas » ou « Sans objet », ou s’il convient de prévoir un autre moyen de contact. Mieux vaut définir ces solutions que contraindre les personnes à inventer des informations pour soumettre le formulaire.

Testez le formulaire avec des tâches réelles et sur plusieurs appareils

Avant sa mise en ligne, demandez à des personnes représentatives de le remplir à partir de tâches courantes et de cas moins fréquents. Observez les moments d’hésitation, les interprétations différentes et les informations qu’elles chercheraient avant de répondre. Leur demander simplement si le formulaire leur semble facile ne suffit pas : un test pratique fait apparaître des problèmes qui échappent souvent à une vérification interne.

Vérifiez que les libellés restent visibles, que l’ordre des champs est logique et que le formulaire fonctionne sur les petits écrans et avec différents modes d’interaction. Assurez-vous aussi que les questions obligatoires sont identifiables, que les erreurs peuvent être corrigées et que l’envoi est possible sans dépendre uniquement de la couleur ou de consignes ambiguës. Les principes d’accessibilité et les normes du Web constituent des références utiles pour examiner ces aspects.

Faites participer les personnes qui traitent les réponses aux tests. Une réponse qui paraît claire à la personne qui la donne peut être insuffisante pour attribuer ou résoudre la demande. Demandez aux membres de l’équipe d’effectuer l’action prévue à partir des données recueillies et de préciser quelles informations ils ont réellement dû redemander.

Mesurez la qualité et réexaminez le formulaire lorsque le processus évolue

Mesurez la qualité et réexaminez le formulaire lorsque le processus évolue

Le taux d’envoi ne suffit pas à déterminer si le formulaire fonctionne bien. Examinez également les étapes où les personnes abandonnent, les champs laissés vides, les réponses corrigées et le nombre de demandes nécessitant des précisions. Si les abandons se concentrent sur une question, cherchez à savoir si la donnée est difficile à trouver, si la question est incompréhensible ou si elle semble inutile. Si les demandes de précision se multiplient, il manque peut-être des instructions ou une option correspondant à une situation fréquente.

Interprétez ces signaux avec prudence : un champ facultatif peut rester vide sans que cela révèle un problème, et un faible taux d’abandon ne garantit pas que les données soient exploitables. Mettez les indicateurs en regard d’exemples de réponses et de l’expérience de l’équipe. Lorsque c’est possible, ne modifiez qu’un élément à la fois : il sera ainsi plus facile de savoir quel ajustement a amélioré la collecte.

Réexaminez la conception lorsque les règles, les responsables, les outils ou le service demandé changent. Un champ qui permettait auparavant de prendre une décision peut devenir inutile ; une nouvelle exception peut nécessiter un parcours différent. Désignez une personne responsable de la révision et consignez l’objectif des champs clés. Un bon formulaire n’est pas celui qui pose le plus de questions, mais celui qui recueille les informations nécessaires à l’action et indique clairement comment poursuivre lorsqu’une réponse manque.

Fuentes y referencias

  1. Web standardsW3C
  2. OWASP Cheat Sheet SeriesOWASP Foundation
  3. Web performanceweb.dev