Un crochet vert ne veut pas toujours dire que le travail est terminé. Sur un portail, Envoyer peut seulement confirmer que la demande a été acceptée. Elle doit encore traverser une file, un système métier et parfois une décision humaine. L’interface doit dire quel engagement vient réellement d’être pris.

Prenons une demande de changement d’adresse. Le portail valide le format, enregistre une commande avec un identifiant et retourne reçue. Un worker appelle ensuite le CRM; celui-ci vérifie le client, met à jour l’adresse et publie un événement. D’autres systèmes, comme facturation et livraison, consomment cet événement.

Un état explicite remplace le faux succès

Je donnerais à la demande cette machine à états :

1. brouillon : données locales modifiables;
2. reçue : portail a persisté la commande;
3. en traitement : worker l’a réservée;
4. appliquée : système maître a confirmé;
5. rejetée : règle fonctionnelle non satisfaite;
6. à vérifier : résultat incertain après un incident.

Le navigateur affiche l’identifiant et l’état, puis permet de revenir. Si l’appel au CRM dépasse le timeout, le worker ne sait pas si l’écriture a eu lieu. Il ne marque pas automatiquement rejetée. Il vérifie par identifiant idempotent ou place la demande à vérifier.

Une transaction locale peut enregistrer la demande et un événement à publier dans la même base. Un processus d’outbox expédie ensuite l’événement. Sans cela, l’application pourrait écrire la donnée puis tomber avant la file, laissant une demande que personne ne traite.

La source de vérité doit être nommée

Si CRM et facturation peuvent chacun modifier l’adresse, les événements vont finir par se contredire. On choisit quel système fait autorité pour chaque attribut et qui a le droit de proposer un changement. Les autres conservent une copie avec version et heure de synchronisation.

Les messages peuvent arriver deux fois ou dans le désordre. Chaque consommateur garde les identifiants traités et compare la version. Une file de rejets doit avoir propriétaire, alerte et outil de reprise; sinon elle devient un cimetière silencieux. Rejouer après correction ne doit pas facturer ou expédier deux fois.

La sécurité suit le parcours. Le portail authentifie le client, l’API autorise l’accès à son dossier, les services s’authentifient entre eux et l’audit garde l’ancien et le nouveau sans exposer inutilement l’adresse dans tous les logs.

Donner au support un outil de reprise sûr

Le support ne devrait pas corriger un statut avec une requête SQL. Une console affiche la demande, ses événements, versions et dernière erreur, puis offre des commandes autorisées : reprendre, annuler, marquer résolue avec justification. Chaque commande passe les règles du domaine et écrit un audit. Le bouton de reprise exige que l’opération soit idempotente; sinon il propose une réconciliation. Des filtres montrent les demandes les plus vieilles et celles sans propriétaire. Cet outil transforme une panne distribuée en travail contrôlé et évite que la réparation crée un état que le logiciel normal ne sait plus interpréter.

Je définirais avec le métier ce que signifient Envoyer, Reçu et Terminé, puis j’injecterais une panne entre chaque composante. Si la demande reste traçable, récupérable et compréhensible par l’utilisateur, le processus existe vraiment. Le crochet vert peut alors confirmer une étape précise plutôt qu’une promesse vague.