Conception de formulaires

Concevoir un questionnaire client court, accessible et mesurable

Un questionnaire client en ligne, comme un formulaire de demande de devis ou de contact sur votre site, est une interface complète : arrivée, champs, branches, validation, erreurs, retour en arrière et confirmation. Sa qualité se mesure à la compréhension du parcours, à son accessibilité sur mobile et à la capacité de terminer sans perdre ses réponses.

En pratique. Le formulaire que Rappli propose à vos appelants est prêt à l’emploi : ses questions s’adaptent à votre activité, sans conception de votre part. En mode « SMS avec formulaire », l’appel manqué renvoyé vers Rappli apparaît dans votre tableau de bord. Rappli envoie automatiquement à l’appelant un SMS avec un lien vers un formulaire, si son numéro et vos réglages permettent l’envoi. Ce SMS a pour expéditeur « Rappli » : l’appelant ne peut pas y répondre. Lorsqu’il transmet sa demande, Rappli vous prévient par SMS et e-mail ; sinon, l’appel figure dans le récapitulatif envoyé à 19 h. Rappli ne garantit pas la complétion et ne remplace pas les questions du rappel.

1. Tracer le parcours et tous ses états avant de dessiner les champs

Un schéma de formulaire qui montre seulement les questions est incomplet. Dessinez aussi l’arrivée, les validations, le retour, le récapitulatif, la confirmation et l’échec technique. Pour chaque état, indiquez ce que l’utilisateur comprend, ce qu’il peut faire et ce que le système conserve.

Utilisez un identifiant stable pour chaque étape et testez tous les chemins possibles. Une branche rarement choisie reste une partie du produit : elle doit pouvoir être terminée, corrigée et reprise comme le parcours principal.

2. Répartir les champs selon l’effort et le moment

Présentez d’abord les choix qui orientent le parcours, puis les précisions propres à la branche, et enfin les coordonnées ou le récapitulatif. Cette progression évite d’afficher une longue page qui mélange des champs sans rapport.

Une question par écran facilite la concentration lorsque les réponses sont complexes ; un petit groupe cohérent réduit les clics pour des champs simples. Choisissez selon l’effort réel, pas selon une règle universelle. Sur mobile, vérifiez notamment que le bouton d’action reste visible quand le clavier est ouvert et qu’aucun message n’est masqué sous la zone de saisie.

Annoncez une durée uniquement si elle reste réaliste pour toutes les branches. Une barre de progression doit refléter l’avancement réel : si la suite dépend d’une réponse, évitez une promesse exacte avant de connaître le chemin.

Exemple : une demande de devis en cinq écrans

Exemple fictif pour un électricien qui reçoit des demandes par son site :

1. Motif : « Nouvelle installation », « Panne » ou « Suivi d’un chantier en cours ».
2. Précision de la branche : pour une panne, « Qu’est-ce qui ne fonctionne plus ? », avec quelques choix et un champ libre.
3. Lieu et délai : commune de l’intervention, puis « Dès que possible », « Cette semaine » ou une date.
4. Coordonnées : nom et téléphone, e-mail et photo facultatifs.
5. Récapitulatif modifiable, puis confirmation qui annonce la suite réelle : « Nous vous rappelons avant demain 12 h. »

Chaque écran sert une seule décision, et la personne en panne ne voit jamais les questions réservées aux nouvelles installations.

3. Signaler clairement le facultatif, l’obligatoire et l’erreur

Le libellé visible doit nommer le champ. Ajoutez « facultatif » directement dans le libellé lorsque la réponse peut être omise ; ne comptez pas uniquement sur un astérisque expliqué en haut de page. L’instruction et l’exemple ne remplacent pas le libellé.

Validez au moment utile. Une contrainte de format peut être signalée après la saisie ou à l’envoi, mais le message doit indiquer comment corriger : « Saisissez un code postal à cinq chiffres » est plus utile que « Valeur invalide ». Associez techniquement le message au champ et conservez toutes les réponses valides.

• Placez un résumé d’erreurs en tête lorsque plusieurs champs sont concernés.
• Déplacez le focus vers le résumé ou la première erreur de façon prévisible.
• N’utilisez pas la couleur seule pour signaler le problème.
• Ne désactivez pas sans explication un bouton que l’utilisateur doit chercher à rendre actif.
• Autorisez la correction sans recommencer le parcours.

4. Afficher une branche utile et préserver un retour cohérent

Une branche retire les questions qui ne concernent pas la personne. Par exemple, « Nouvelle demande », « Suivi en cours » et « Sujet administratif » peuvent ouvrir trois suites différentes. L’utilisateur ne doit jamais parcourir les écrans des autres motifs. Le formulaire que Rappli envoie par SMS après un appel manqué suit ce principe : il s’ouvre sur trois choix, « Faire une nouvelle demande », « Suivre une demande en cours » et « Laisser un autre message ».

Définissez le comportement lorsqu’une réponse est modifiée. Si le nouveau choix rend une ancienne réponse incompatible, prévenez avant de l’effacer. Si elle reste valable, conservez-la. Au retour, replacez le focus sur le titre ou le champ modifié et gardez un moyen clair de poursuivre.

Limitez la profondeur et donnez des titres d’étape compréhensibles. Une arborescence complexe qui empile des sous-choix peut être remplacée par une orientation principale, une précision ciblée et un champ libre pour le contexte inattendu.

5. Écrire des labels, aides et messages d’erreur sans ambiguïté

Un bon libellé reste compréhensible lorsqu’il est lu seul par un lecteur d’écran ou dans un résumé de réponses. Utilisez les mots des clients, une seule idée par question et des options qui ne se chevauchent pas. Évitez les catégories internes, les doubles négations et les exemples qui ressemblent à une réponse obligatoire.

Réservez le texte d’aide à une contrainte réellement utile : unité, format, raison d’une donnée inhabituelle ou conséquence du choix. Le placeholder disparaît pendant la saisie et ne doit contenir ni le libellé ni une information indispensable.

6. Choisir le contrôle adapté à la réponse attendue

Les choix fermés sont efficaces pour orienter et filtrer. Le texte libre révèle le contexte inattendu. Un bon questionnaire combine les deux : quelques choix courts, puis un champ libre ciblé plutôt qu’une succession de menus.

Le bon format améliore aussi la restitution. Une réponse impossible à parcourir rapidement dans le tableau de bord ralentit le professionnel même si elle était facile à saisir. Pensez dès la conception à l’endroit où chaque réponse sera lue et suivie, par exemple dans le registre décrit pour organiser les demandes clients d’une petite entreprise.

7. Rendre le questionnaire accessible sur mobile

Un questionnaire accessible reste utilisable quelle que soit la manière de lire et de saisir : au doigt, au clavier, avec le zoom, un lecteur d’écran ou la commande vocale. Les règles WCAG 2.2 du W3C servent de référence internationale. Tenir sur un écran de téléphone ne suffit pas : chaque champ doit être identifiable, son format annoncé et le résultat de l’envoi compréhensible.

Depuis le 28 juin 2025, certains services destinés aux consommateurs, dont le commerce en ligne, doivent en outre respecter des exigences d’accessibilité. Les entreprises de moins de dix personnes qui fournissent des services, avec un chiffre d’affaires annuel ou un total de bilan d’au plus deux millions d’euros, en sont dispensées (article L412-13 du Code de la consommation). Même sans obligation, ces règles rendent le formulaire plus simple à remplir d’une main, dehors ou avec une vue fatiguée.

Choisir le bon type de champ

Dans un outil de formulaires comme dans du code, le type de champ décide du clavier affiché et de la saisie automatique :

Acceptez aussi les formats variés quand ils peuvent être normalisés ensuite : refuser un numéro parce qu’il contient des espaces n’apporte rien.

Trois critères WCAG 2.2 à vérifier sur mobile

• Zones tactiles : chaque cible mesure au moins 24 × 24 pixels CSS, ou reste assez espacée des autres (critère 2.5.8, niveau AA). C’est un minimum : prévoyez plus grand pour le bouton d’envoi.
• Affichage à 320 pixels CSS de large : le contenu reste lisible et utilisable sans défilement horizontal (critère 1.4.10, niveau AA). Laissez les blocs se réorganiser au lieu de réduire la police.
• Champ actif visible : l’élément qui reçoit le focus n’est jamais entièrement caché par un contenu de la page, comme une barre ou un bouton fixe (critère 2.4.11, niveau AA). Vérifiez-le avec le clavier du téléphone ouvert.

8. Limiter les données et expliquer leur usage

Définissez la finalité de chaque donnée personnelle, son accès et sa durée de conservation. Évitez les pièces d’identité, données de santé, mots de passe, coordonnées bancaires ou informations très précises si elles ne sont pas indispensables à cette étape.

Distinguer l’obligatoire du facultatif n’est pas qu’une question d’ergonomie. Au moment de la collecte, le RGPD impose d’indiquer si la personne est tenue de fournir ses données et ce qu’entraîne un refus, lorsque cette fourniture conditionne un contrat ou découle d’une obligation (article 13). La CNIL propose des exemples de mentions : une information en deux niveaux peut présenter l’essentiel près du formulaire et renvoyer vers une notice complète.

Pour organiser ces décisions au-delà du questionnaire, utilisez la checklist RGPD pour les données clients.

9. Mesurer les erreurs et abandons branche par branche

Suivez au minimum l’ouverture, le démarrage, l’étape atteinte, l’envoi et les erreurs techniques. Comparez les branches : un taux global peut cacher un parcours très fluide et une option secondaire impossible à terminer.

Une baisse à une étape ne prouve pas que la question est trop longue. Elle peut révéler une réponse introuvable, un champ qui fonctionne mal, une demande jugée intrusive ou une personne qui a obtenu l’information suffisante ailleurs.

Complétez les chiffres par quelques observations ou retours. Changez une variable importante à la fois et vérifiez également la qualité des demandes reçues : augmenter les envois en supprimant une information décisive peut déplacer le travail vers le rappel.

10. Dix contrôles pour auditer chaque écran

1. Le titre de l’étape et le libellé du champ restent-ils compréhensibles isolément ?
2. Le caractère facultatif ou obligatoire est-il annoncé avant la saisie ?
3. Le contrôle choisi correspond-il à la réponse attendue sans imposer de contournement ?
4. Le clavier, l’autocomplétion et le format de saisie sont-ils adaptés sur mobile ?
5. Le message d’erreur indique-t-il précisément quoi corriger et reste-t-il associé au champ ?
6. Le retour en arrière conserve-t-il les réponses encore compatibles ?
7. Le parcours reste-t-il utilisable au clavier, au zoom et sans défilement horizontal ?
8. Les boutons et choix disposent-ils d’une zone tactile suffisante et d’un état visible ?
9. Le récapitulatif permet-il de modifier une réponse avant l’envoi, puis la confirmation annonce-t-elle la vraie suite ?
10. Les événements de mesure distinguent-ils erreurs techniques, abandon et changement volontaire sans collecter le contenu sensible ?

Tester avant de publier

Faites aussi remplir le formulaire par deux ou trois personnes qui ne le connaissent pas, sur leur propre téléphone : leurs hésitations en disent plus que le temps total. Avant d’adopter un nouvel outil de formulaires, vérifiez avec le guide des outils numériques pour indépendants et TPE qu’il répond à un besoin distinct et permet de récupérer vos données.

Sources de référence : W3C WAI — tutoriel sur les formulaires ; GOV.UK Design System — pages de questions ; GOV.UK Design System — vérification des réponses ; CNIL — minimiser les données collectées ; CNIL — informations sur les formulaires de collecte ; RGPD, article 13 (texte publié par la CNIL) ; W3C — WCAG 2.2, critère 2.5.8 (taille des cibles) ; W3C — critère 1.4.10 (reflow) ; W3C — critère 2.4.11 (focus non masqué) ; Code de la consommation, article L412-13 (accessibilité des produits et services) ; France Num — accessibilité des sites de e-commerce. Sources W3C WAI, GOV.UK et CNIL formulaires consultées le 31 juillet 2026, autres sources le 29 septembre 2026.

Questions fréquentes

Faut-il afficher une question par page ?

Pas toujours. Une question complexe peut bénéficier d’un écran dédié ; quelques champs simples et cohérents peuvent partager une page. Testez l’effort, le nombre de clics et la compréhension sur mobile.

Comment signaler un champ facultatif ?

Ajoutez « facultatif » dans son libellé visible. Évitez de laisser l’utilisateur déduire la règle à partir d’un astérisque ou de la seule apparence du champ.

Quelle taille minimale pour un bouton sur mobile ?

Les règles WCAG 2.2 demandent au moins 24 × 24 pixels CSS par cible, ou un espacement suffisant entre deux cibles plus petites. C’est un seuil de conformité : pour le bouton d’envoi et les choix fréquents, une zone plus grande reste préférable.

Quand afficher les erreurs ?

Après une interaction ou lors de l’envoi, selon la contrainte. Le message doit rester près du champ, être annoncé aux technologies d’assistance et expliquer la correction attendue.

Que faire des réponses lorsqu’une personne revient en arrière ?

Conservez celles qui restent compatibles. Prévenez avant d’effacer une réponse devenue incohérente et ne transmettez jamais silencieusement une donnée provenant d’une branche abandonnée.

Quelle différence avec la qualification d’une demande ?

La qualification définit ce qu’il faut comprendre pour décider d’une suite. Le questionnaire organise l’interface, les contrôles, les erreurs, les branches, l’accessibilité et la mesure de ce parcours.

En résumé

Un questionnaire client court est une interface sans impasse : chaque écran possède un but, chaque champ un libellé, chaque erreur une correction et chaque branche un retour cohérent. Concevez tous les états, testez-les au clavier et sur mobile, puis mesurez séparément les erreurs techniques et les abandons.