Quatre expériences bornées, deux modes, une même règle : ne confirmer que ce qu’une réponse établit.
Un prolongement du Protocole UX writing
L’archive Edikka du 3 septembre 2026 (v1.0.1) documente deux corrections rédactionnelles sur le contact : UXW07 et UXW08. UXW09 à UXW12 étaient déjà satisfaits. UXW06 appartient au test agents IA et reste « À tester ». Ces observations ne sont pas réécrites par la présente démo.
Simulation publique, laboratoire HTTP réel
Sur GitHub Pages, aucun champ ne quitte le navigateur. Le laboratoire local réserve et stocke réellement en mémoire sur 127.0.0.1 ; le scénario C ferme la connexion après stockage. Les deux modes partagent validation et contrat. Une panne simulée dans le navigateur n’est pas une coupure HTTP réelle.
Clavier, erreurs et annonces
Le résumé reçoit le focus après une soumission invalide. Ses liens ciblent les champs. Les aides restent associées. Une région de statut annonce les réponses sans déplacer le focus ; le résumé ne cumule pas focus et alerte live. Les observations DOM ne prouvent pas ce qu’un lecteur d’écran annonce.
Quatre scénarios documentés
Comprendre et corriger
Envoyez le formulaire vide. Comparez ensuite les mots, à règles identiques.
Reprendre après un refus
Le premier envoi valide est refusé avant stockage. La reprise est autorisée et peut réussir.
Réponse perdue
Le service enregistre, puis la réponse est perdue. Que peut affirmer le formulaire ?
Attendre sans doublon
Le service attend 4 secondes avant l’enregistrement. Réactivez la commande, puis rejouez la même demande.
Exemple expliqué : après une réponse perdue, une demande peut déjà être enregistrée. Le message reste incertain jusqu’à une réponse de vérification. Reprendre avec la même clé retrouve le même enregistrement.
Aucune conformité globale, étude utilisateurs ou amélioration de conversion déduite. Aucun e-mail livré, aucun contact transmis, aucun stockage durable.