Formulaire de devis : après une erreur, votre prospect peut-il vraiment terminer ?

« Vérifiez les informations saisies. » Le message est poli. Il ne dit pas lesquelles.

Imaginez une personne qui demande un devis d’agencement depuis son téléphone. Elle a décrit la pièce, précisé sa commune et ses disponibilités. Une faute dans son adresse e-mail bloque la validation. Elle corrige, puis découvre que la description du projet a disparu. Cette scène est fictive, mais elle fournit un bon point de départ pour examiner un formulaire : que se passe-t-il quand le visiteur ne réussit pas du premier coup ?

La longueur du formulaire n’est alors qu’une partie du sujet. Il faut pouvoir identifier l’erreur, la corriger sans tout recommencer et savoir si la demande est effectivement parvenue à l’entreprise. Ces trois étapes méritent des preuves différentes.

Remplacer le reproche par une instruction

Un message général placé tout en haut de la page peut rester hors écran sur mobile. Une bordure rouge attire parfois l’attention, mais elle ne précise ni le problème ni le format attendu. Le formulaire doit nommer le champ et aider la personne à agir.

Voici trois exemples de rédaction à adapter au fonctionnement réel du site :

• Champ manquant : « Adresse e-mail : renseignez ce champ pour que nous puissions vous répondre. »
• Adresse mal formée : « Adresse e-mail : utilisez un format comme [email protected]. »
• Pièce jointe refusée : « Votre fichier dépasse la taille autorisée. Choisissez un fichier de moins de 5 Mo. » Ce dernier texte n’est pertinent que si cette limite est réellement configurée et annoncée avant l’envoi.

Ces phrases évitent le vague « une erreur est survenue ». Elles ne doivent pas non plus raconter plus que le contrôle ne sait : une adresse dont le format paraît valide n’est pas nécessairement une boîte existante ou joignable. Écrivez « format incorrect » lorsque c’est ce qui est vérifié, pas « adresse inexistante ».

Le critère 11.10 du RGAA encadre le contrôle de saisie : indications des champs obligatoires, formats attendus et identification des erreurs, selon les tests et leurs conditions. Le critère 11.11 porte sur les suggestions facilitant la correction, avec les types, formats ou exemples nécessaires. Ce sont des repères précis, pas une obligation de reproduire mot pour mot les formulations ci-dessus.

Dans une entreprise de services, le libellé compte aussi. « Commune du chantier » est plus explicite que « Ville » si le lieu d’intervention peut différer de l’adresse du demandeur. Indiquez les contraintes utiles avant la validation : obliger quelqu’un à se tromper pour découvrir la règle ajoute une étape inutile.

Le libellé reste, même quand on écrit

Le texte grisé à l’intérieur d’un champ, appelé *placeholder*, peut donner un exemple. Il ne remplace pas un libellé durable : dès que l’on saisit, le repère disparaît. Conservez « Adresse e-mail » à proximité du champ et associez-le correctement dans le code. Le RGAA traite les étiquettes et leur pertinence dans ses critères 11.1 et 11.2.

Pour le message d’erreur, proximité visuelle et restitution par les technologies d’assistance doivent être vérifiées ensemble. Un attribut ARIA ajouté isolément n’est pas une réparation universelle. Le prestataire doit pouvoir montrer ce qui est annoncé lorsqu’on atteint le champ et ce qui se passe après correction.

Corriger une faute ne devrait pas effacer le projet

Reprenons la demande d’agencement. Le prospect a déjà fourni un effort : il a décrit ce qu’il souhaite. Une erreur d’adresse ne rend pas cette description inutile. Notre recommandation est de conserver les champs non sensibles nécessaires pendant la correction, sans imposer une nouvelle saisie de tout le formulaire.

Cela ne signifie pas « enregistrer tout dans le navigateur ». Une conservation temporaire pendant le parcours et une persistance après fermeture de la page sont deux choix différents. Le second peut exposer des informations sur un appareil partagé. Ne stockez pas durablement le contenu d’une demande par défaut ; définissez quelles données sont utiles, pendant combien de temps et comment elles sont effacées. Une pièce jointe peut nécessiter une nouvelle sélection selon le mécanisme employé : expliquez-le au lieu de laisser croire qu’elle sera transmise.

La correction doit aussi fonctionner sans souris. Demandez une démonstration au clavier : atteindre les champs, déclencher la validation, repérer l’erreur, revenir au champ concerné puis terminer. Le focus — le repère de l’élément actuellement actif — doit rester visible et suivre un parcours compréhensible. Un résumé d’erreurs relié aux champs peut être utile sur un formulaire long ; il doit lui-même être testé.

Faites ensuite vérifier ce parcours avec une technologie d’assistance adaptée et consignez le navigateur, l’outil et les résultats. Une capture d’écran ou une inspection du HTML ne démontre pas que le message est correctement restitué. Après correction, l’ancienne erreur ne doit pas rester affichée ou annoncée comme si rien n’avait changé.

Ce travail peut s’inscrire dans une amélioration ciblée du site internet. Il ne suppose pas automatiquement de refaire toutes les pages ni de remplacer le logiciel du formulaire.

« Demande envoyée » : que sait réellement le site ?

Il faut distinguer quatre événements : le navigateur considère les champs valides ; le serveur accepte la requête ; la demande est enregistrée si le système prévoit un stockage ; une notification arrive dans la boîte de la personne chargée de répondre. Un écran de succès ne prouve pas, à lui seul, la réception d’un e-mail.

Le texte de confirmation doit correspondre à ce que le système sait. « Votre demande a été enregistrée » convient si un enregistrement est confirmé. Cette phrase ne prouve ni la lecture par l’équipe ni l’envoi d’un devis. Évitez également de promettre une réponse sous un délai que l’entreprise ne peut pas tenir.

Pour une petite entreprise, le point important est opérationnel : qui peut retrouver les demandes si la notification ne part plus ? Certains formulaires ne font qu’envoyer un e-mail, sans conserver de copie dans un espace de gestion. Ne leur attribuez pas un registre inexistant. Documentez cette limite et choisissez une solution adaptée au besoin de continuité, avec accès et conservation encadrés.

Une coupure après le clic est un autre cas. Le navigateur peut ne pas recevoir la réponse alors que le serveur a déjà traité la demande. Afficher « échec » puis encourager les clics répétés peut créer plusieurs demandes. Le site devrait expliquer l’incertitude et prévoir une reprise maîtrisée. Lors d’une recette, le prestataire recherche d’abord la demande de test dans le système destinataire avant de la rejouer.

Un bouton temporairement désactivé limite les clics impatients ; il ne démontre pas que deux tentatives ne créeront jamais deux enregistrements. Le contrôle doit porter sur le résultat, pas seulement sur l’animation du bouton. Aucun détail interne ni contenu de demande ne doit être exposé au public pour faciliter ce rapprochement.

La recette à confier au prestataire

Choisissez un formulaire, une page et un environnement de test, avec des données fictives et une boîte de réception dédiée. Les scénarios ci-dessous constituent une proposition de recette, pas des tests réalisés sur votre site ni sur celui de 1Design. Ne provoquez pas de panne sur le site public pour les reproduire.

Côté visiteur : trois passages à observer

Un champ obligatoire vide. La personne comprend ce qui manque et atteint le bon champ au clavier. L’équipe technique vérifie qu’aucune demande n’a été créée pour cette tentative invalide.

Une adresse mal formée. Le format attendu est expliqué ; la description du projet reste présente. Conservez une capture expurgée et le résultat de la validation, sans données personnelles réelles.

Une correction suivie d’une validation. L’erreur obsolète disparaît, le parcours continue et la confirmation devient accessible. Retrouvez la demande fictive acceptée avec une référence permettant le rapprochement, si le système en fournit une.

Côté entreprise : trois résultats à rapprocher

Réseau interrompu avant la réponse. Le visiteur voit un état compréhensible et garde sa saisie non sensible. Le mainteneur détermine si le serveur a agi avant de recommencer le test.

Nouvelle tentative après un résultat incertain. Le responsable du formulaire rapproche les tentatives et les demandes effectivement reçues ou enregistrées. Le résultat attendu est une seule demande métier, ou un traitement explicite des doublons, pas deux dossiers silencieusement attribués à deux personnes.

Acceptation sans notification reçue. La confirmation affichée est comparée à l’enregistrement, au journal de notification disponible et à la boîte de test. « Accepté par le service d’envoi » et « présent dans la boîte destinataire » sont des preuves distinctes. Le responsable commercial confirme le dernier point ; le mainteneur explique où se situe la rupture.

Cette répartition évite un malentendu fréquent : demander au développeur de certifier ce qu’il ne peut pas voir dans la boîte de réception, ou demander au dirigeant d’interpréter seul un journal serveur.

Une restitution qui permet de décider

Le livrable utile n’est pas une collection de captures. Pour chaque anomalie, demandez le scénario reproductible, le résultat attendu, le résultat observé, la preuve expurgée, le responsable de la correction et la contre-vérification après intervention.

Exemple de restitution entièrement fictif : « La confirmation apparaît et la demande DEMO-014 est enregistrée. La notification correspondante n’est pas retrouvée dans la boîte de test. Le mainteneur doit diagnostiquer la notification ; l’équipe dispose provisoirement d’un accès contrôlé aux demandes enregistrées. Un nouveau test vérifiera l’ensemble après correction. » Ce constat serait plus utile que « formulaire OK » après un simple clic.

Priorisez d’abord les demandes qui n’arrivent pas ou que personne ne peut retrouver, puis les erreurs qui empêchent de terminer. Viennent ensuite les améliorations de confort. Pour évaluer l’effet commercial, comparez des périodes et des parcours comparables : une baisse des erreurs ne suffit pas à démontrer une hausse des devis signés.

Un diagnostic du parcours vers la demande de devis peut aider à situer le problème. La vérification technique de bout en bout décrite ici a cependant son propre périmètre, à convenir avec le prestataire : elle ne doit pas être confondue avec un simple examen visuel de la page.

Questions pratiques

Une bordure rouge suffit-elle pour signaler l’erreur ?

Non. Il faut pouvoir identifier le champ et comprendre l’action attendue sans dépendre uniquement de la couleur. Le message et sa restitution doivent être vérifiés dans le parcours réel.

Le placeholder peut-il remplacer le libellé ?

Non. Un exemple dans le champ n’est pas un repère durable. Gardez un libellé compréhensible et correctement associé, même lorsque le champ contient déjà du texte.

Un succès affiché garantit-il la livraison de l’e-mail ?

Non. L’acceptation, l’éventuel enregistrement et la réception de la notification doivent être rapprochés. Une capture du message de succès ne prouve que ce qui était affiché.

Faut-il conserver tous les champs après une erreur ?

Non. Préservez les informations non sensibles nécessaires à la correction, sans créer de stockage durable inutile. Le traitement des pièces jointes et des données sensibles exige un choix explicite adapté au formulaire.

Ce contrôle rend-il le site conforme au RGAA ?

Non. Il ne couvre qu’un périmètre partiel. Une recette ciblée n’est ni un audit global ni une certification. Les obligations applicables doivent être déterminées selon la situation de l’organisme ; cet article ne fournit pas de conclusion juridique.

Faire vérifier un formulaire précis

Vous souhaitez vérifier un formulaire de devis ? Présentez-nous la page concernée et le blocage observé. Nous pourrons cadrer un diagnostic du parcours, des messages d’erreur et de la réception des demandes. Une URL et une description sans données personnelles suffisent pour commencer ; aucun identifiant d’accès n’est nécessaire à ce premier échange.

Sources et périmètre

Référentiel officiel consulté le 8 octobre 2026 : RGAA, critères 11.1 et 11.2 sur les étiquettes, 11.10 sur le contrôle de saisie et 11.11 sur les suggestions de correction. Les tests complets, leurs conditions et cas particuliers restent la référence. La conservation temporaire, le rapprochement après coupure et la vérification de réception sont ici des recommandations opérationnelles 1Design, pas des exigences attribuées à ces seuls critères.