Vérifier la saisie
Essayez les champs requis, les formats incorrects et une demande valide avec des données de test clairement identifiées. Contrôlez les libellés, les messages d’erreur et la navigation au clavier. Faites aussi un essai sur téléphone.
Contrôler le traitement
Vérifiez la réception par le service puis par la personne chargée de répondre. Comparez les informations reçues à celles envoyées, y compris la prestation et la préférence de rappel. Évitez d’utiliser de vraies données clients pour ce test.
Examiner les échecs
Simulez les erreurs dans un environnement de test lorsque c’est possible. Le visiteur doit comprendre que l’envoi n’est pas confirmé et retrouver sa saisie. Vérifiez également qu’un double clic ne crée pas plusieurs envois simultanés.
Le journal de test de bout en bout
Pour chaque essai, notez appareil, navigateur, page d'origine, scénario, retour affiché et réception réelle. Faites un essai normal, un essai avec champ requis manquant et un essai d'échec maîtrisé sur un environnement de test. Vérifiez aussi la boîte destinataire et les éventuels indésirables. Un message de réussite à l'écran ne permet pas, à lui seul, de conclure qu'une personne peut traiter la demande.
Vérifier la reprise humaine
Exemple hypothétique : la demande arrive dans une boîte commune mais personne n'en est responsable. Le formulaire fonctionne techniquement, tandis que le parcours commercial s'arrête. Désignez qui prend connaissance du message, où il note son traitement et comment un collègue reprend le dossier en cas d'absence. Faites apparaître dans le journal la version du site testée pour pouvoir relier un problème à une modification précise.
Définir une réception acceptable
La demande de test doit être reconnaissable, lisible et sans données sensibles réelles. Supprimez-la selon votre procédure après le contrôle. Ne provoquez pas de panne sur le site public : testez le comportement d'erreur dans un aperçu adapté. Le guide technique web.dev Learn Forms aide à examiner validation et retours de formulaire. La décision finale est simple : la personne sait ce qui s'est passé et l'équipe sait quoi faire ensuite.
Votre grille de travail
Une trame proposée par koldia, à adapter à votre situation.
| Scénario | Côté visiteur | Côté destinataire |
|---|---|---|
| Demande fictive valide | Confirmation après envoi réussi | Données complètes, bon destinataire |
| Champ indispensable manquant | Erreur compréhensible près du champ | Aucune fausse demande créée |
| Échec simulé en environnement de test | Saisie conservée et moyen de contact | Pas de doublon lors de la reprise |
Avant de passer à la suite
Cochez les points vérifiés pendant votre lecture.
Questions pratiques
À quelle fréquence refaire le test ?
Refaites-le après une modification du formulaire, du service de réception ou des destinataires. Ajoutez un contrôle régulier adapté à votre activité.
Références officielles
Liens consultés le 20 octobre 2026.
- Google web.dev — conception et tests des formulaires
Repères techniques pour la saisie, les libellés, la validation et les essais.
Vous souhaitez avancer sur ce sujet ?
Un premier échange offert de 15 minutes par téléphone, sans engagement.
Parlons de votre projet