Guide · Gestion d’une entreprise de services
Comment se comporte l’exemple d’orientation des demandes en test
Examinez cinq cas exécutés de prise en charge, de doublon et de rattrapage, avec des données reproductibles et des limites claires sur ce qu’un exemple dans le navigateur prouve.
Rédigé par Fireflax · 8 minutes de lecture
Relu par Codex — source and implementation review ·
Qu’a réellement fait cet exemple ?
Le 8 octobre 2026, nous avons vérifié cinq parcours définis dans le workflow fictif de demandes de Northstar Plumbing. Chaque parcours a été exécuté avec les règles de demande du dépôt, puis séparément avec le kit de démarrage téléchargeable. Le tableau consigne ces résultats limités ; ce n’est ni une étude de cas client ni un indicateur de fiabilité en production.
Périmètre des tests
Cinq cas par implémentation, soit dix exécutions de cas au total. Chaque implémentation a enregistré cinq réussites et zéro échec. Les tests ont tourné en local avec Node.js 22.23.2, des entrées synthétiques et aucun connecteur réseau. Ils ont vérifié les règles utilisées par la démo du navigateur ; ils n’ont fait fonctionner ni boîte mail réelle, ni CRM, ni service de messagerie.
Les entrées et les attentes ont été définies en premier.
La donnée de test complète est Alex Morgan, alex@example.com, Bristol BS1, qui demande de l’aide pour un robinet de cuisine qui goutte depuis une semaine. La donnée incomplète est Sam Taylor, sam@example.com, sans zone et avec le message « Can you help? ». Ce sont des contacts fictifs.
Le cas de doublon soumet à nouveau la demande d’Alex avec un autre nom affiché, du texte en majuscules et des espaces en trop. La validation répétée tente de remplacer une réponse déjà validée. Le cas de rattrapage utilise l’indicateur explicite d’échec simulé, tente de contourner le rétablissement, rétablit la même fiche puis la valide à nouveau.
| Parcours | Attendu | Observé |
|---|---|---|
| Demande complète | Une demande de plomberie pour le coordinateur de service ; validation nécessaire avant la fin. | Les deux exécutions : review → completed ; une seule fiche ; texte relu conservé. |
| Détails manquants | Demander la zone et le détail de l’intervention ; la validation ne doit pas faire disparaître les informations manquantes. | Les deux exécutions : review → awaiting-details ; les deux éléments manquants sont conservés. |
| Doublon normalisé | Même e-mail, même zone et même message avec une casse ou des espaces différents : la fiche existante est renvoyée. | Les deux exécutions : même identifiant et une seule fiche ; état et historique inchangés. Un nom affiché différent n’a pas modifié la correspondance. |
| Validation répétée | Une seconde validation ne doit ni remplacer la réponse terminée ni ajouter d’historique. | Les deux exécutions : état completed et texte validé d’origine inchangés. |
| Échec et rattrapage | Conserver la fiche bloquée et le brouillon ; empêcher une nouvelle validation directe ; le rétablissement exige une nouvelle validation. | Les deux exécutions : blocked → review avec la validation précédente effacée → completed ; une seule fiche du début à la fin. |
Demande complète
Attendu: Une demande de plomberie pour le coordinateur de service ; validation nécessaire avant la fin.
Observé: Les deux exécutions : review → completed ; une seule fiche ; texte relu conservé.
Détails manquants
Attendu: Demander la zone et le détail de l’intervention ; la validation ne doit pas faire disparaître les informations manquantes.
Observé: Les deux exécutions : review → awaiting-details ; les deux éléments manquants sont conservés.
Doublon normalisé
Attendu: Même e-mail, même zone et même message avec une casse ou des espaces différents : la fiche existante est renvoyée.
Observé: Les deux exécutions : même identifiant et une seule fiche ; état et historique inchangés. Un nom affiché différent n’a pas modifié la correspondance.
Validation répétée
Attendu: Une seconde validation ne doit ni remplacer la réponse terminée ni ajouter d’historique.
Observé: Les deux exécutions : état completed et texte validé d’origine inchangés.
Échec et rattrapage
Attendu: Conserver la fiche bloquée et le brouillon ; empêcher une nouvelle validation directe ; le rétablissement exige une nouvelle validation.
Observé: Les deux exécutions : blocked → review avec la validation précédente effacée → completed ; une seule fiche du début à la fin.
Exécutez-le et comparez votre propre résultat.
Téléchargez le kit de démarrage 1.0.0, extrayez-le et suivez son README. Les contrôles inclus contiennent les états et assertions attendus. Exécutez node verify.mjs pour produire un nouveau rapport avec les entrées, les attentes et l’historique observé des cinq cas. Si un cas échoue, la commande se termine en erreur.
L’exécution sur le code source du dépôt a appelé directement les fonctions TypeScript actuelles. L’exécution du kit de démarrage a chargé le JavaScript empaqueté sans importer de fichiers du dépôt. Leurs définitions de test communes rendent la comparaison reproductible ; les deux exécutions ne constituent pas une preuve indépendante de l’exactitude de toutes les règles possibles.
Le paquet comprend aussi une répétition de pause distincte.
L’utilitaire en ligne de commande du paquet ajoute un stockage dans un fichier local et des commandes de pause et de reprise. Sa répétition en onze commandes a initialisé une fiche, simulé un échec, mis en pause, tenté un rétablissement bloqué, repris, rétabli, validé deux fois et réinitialisé. Le rétablissement pendant la pause s’est volontairement terminé en erreur sans modifier l’état. La reprise n’a rejoué aucune action.
Il s’agit d’un contrôle négatif réussi, pas d’un test en échec passé sous silence. node cli-check.mjs exécute la séquence dans un dossier temporaire et supprime ce dossier ensuite. Ces fonctions en ligne de commande n’existent pas dans la démo du navigateur.
Ce qui reste à prouver
La mémoire des doublons du navigateur disparaît en cas de réinitialisation, de rechargement ou de changement de workflow. Le kit de démarrage enregistre un fichier local, mais n’a ni verrouillage multi-utilisateur ni base de fiches de production. Un message modifié peut être une nouvelle demande ; cette clé ne peut pas déterminer si deux demandes formulées différemment décrivent la même intervention.
Une vraie mise en place aurait besoin d’identifiants durables pour les demandes et les actions, d’une décision sur les demandes modifiées et de vérifications de la destination avant toute nouvelle tentative. Ce sont des ajouts nécessaires, pas des corrections démontrées par ces résultats locaux. L’échec simulé n’envoie rien : il ne teste donc pas une connexion qui a bien agi puis perdu sa confirmation.
Ces cinq cas ne permettent de conclure à aucun gain de temps pour un client, aucun taux de conversion, aucune intégration réelle, aucune disponibilité ni aucune livraison exactement une fois. La suite de tests unitaires existante du dépôt a par ailleurs validé 21 contrôles de l’outil de demandes. Cette suite plus large est une couverture utile contre les régressions, pas 21 essais clients ni 21 sessions de navigateur.
Sources et notes de relecture
Rédigé avec Codex et vérifié par rapport à des tests exécutés sur l’exemple fictif, au code source et à une répétition indépendante du kit de démarrage par Codex. Ces résultats n’établissent ni une intégration réelle ni un résultat client.
- Test conservé de l’outil du navigateur
Entrées, attentes et états observés lors d’une exécution réelle du code source.
- Essayer l’exemple de demande
Reproduisez les parcours de relecture et d’échec avec des informations fictives.