Le commercial ouvre un dossier marqué « validé », le back-office le voit « incomplet » et le reporting le compte « terminé ». Aucun écran n’est forcément cassé : chacun déduit son statut de champs et de dates différents. Le problème apparaît quand ces trois lectures déclenchent relance, facturation ou clôture incompatibles.
Le symptôme commence souvent par une couleur corrigée localement, une colonne ajoutée au reporting ou une règle cachée dans le front. Puis les équipes ne savent plus si elles discutent du même dossier. La reprise manuelle augmente, les clients reçoivent des messages contradictoires et l’historique ne permet pas d’expliquer la décision.
En pratique, un badge unique ne résout pas les divergences d’interprétation. Un modèle d’états métier sépare les faits, les transitions, l’état canonique et les projections d’affichage ; il fixe aussi les invariants, les droits et les preuves qui rendent chaque passage reproductible sans forcer tous les écrans à montrer le même libellé.
Dawap construit ce socle dans ses projets de développement web sur mesure. La landing porte l’accompagnement global ; cette méthode traite la cohérence du dossier avant de développer davantage d’écrans ou d’automatisations.
Repérer les vérités concurrentes
Une vérité concurrente existe lorsqu’une même décision reçoit plusieurs réponses selon l’interface. Peut-on facturer, relancer, annuler ou fermer ? Si les équipes consultent des colonnes différentes, le statut n’est qu’un raccourci local.
Chercher les conséquences plutôt que les libellés
Deux écrans peuvent employer des mots différents tout en autorisant les mêmes gestes ; le risque reste faible. À l’inverse, deux badges « terminé » peuvent masquer, pour le premier, un paiement reçu et, pour le second, une prestation livrée. L’audit compare droits et effets avant de normaliser les couleurs.
Le coût caché se mesure en dossiers rouvertes, actions annulées, recherche de preuve et temps support. Contrairement à ce que l’on croit, harmoniser le design avant le modèle rend souvent la divergence plus difficile à voir.
Savoir quand modéliser les états
Le modèle devient indispensable lorsqu’un dossier traverse plusieurs rôles, possède des étapes non réversibles, déclenche des effets externes ou doit être expliqué après plusieurs mois. Un formulaire simple et éphémère peut rester plus léger.
Qualifier les décisions réellement partagées
Vente, opérations, finance, support et conformité n’ont pas besoin du même écran, mais ils doivent partager les faits qui autorisent une action. Le chantier commence par ces décisions transverses, pas par une liste exhaustive de micro-statuts.
Un signal faible apparaît lorsque l’équipe demande « quel écran fait foi ? ». Un second se voit quand une correction SQL devient la procédure normale. Dès qu’une transition critique dépend d’une interprétation humaine, le modèle exige un responsable et des tests.
Partir du dossier et de ses décisions
Le dossier possède une identité, une finalité, des parties et un cycle de vie. Il ne se confond ni avec une page, ni avec une table, ni avec un ticket. L’équipe liste d’abord les décisions : accepter, instruire, engager, exécuter, suspendre, compenser et clore.
Définir une frontière métier stable
Un dossier de demande peut contenir pièces, validations, paiements et échanges sans devenir chacun de ces objets. Les sous-objets gardent leurs états ; le dossier agrège seulement ce qui commande sa décision globale.
La frontière nomme le responsable, l’identifiant, les événements d’entrée, la sortie terminale et la durée de conservation. Si deux finalités indépendantes évoluent à des rythmes différents, elles deviennent deux agrégats reliés plutôt qu’un statut géant.
La modélisation documente également les dossiers qui n’entrent volontairement pas dans cette frontière. Une conversation support, une pièce brute ou une tentative de paiement garde son propre cycle. Le dossier référence leur résultat utile, ce qui évite qu’un changement secondaire force une transition globale et simplifie la reprise ciblée.
Séparer faits, état et affichage
Un fait décrit ce qui s’est produit : document reçu, paiement confirmé, contrôle refusé. L’état canonique résume les conséquences valides de ces faits. L’affichage adapte cette information à un rôle sans inventer une autre réalité.
Recalculer sans réécrire l’histoire
La chronologie conserve événements, auteurs, motifs et versions. Un correctif ajoute un nouveau fait ou une compensation. Il ne remplace pas silencieusement la décision antérieure, sinon l’audit ne peut plus expliquer le parcours.
Le front reçoit état, capacités et raisons. Il ne déduit pas « facturable » d’une combinaison locale de cinq champs. Cette capacité est produite par le domaine qui possède les invariants de facturation.
Écrire les invariants métier
Un invariant reste vrai après chaque transition : aucun dossier engagé sans consentement, aucune facture sans base, aucune clôture avec action critique ouverte. Ces règles protègent la cohérence plus efficacement qu’une liste de statuts autorisés.
Formuler une règle qui peut refuser
« Les pièces doivent être complètes » reste vague. « La transition vers prêt à instruire exige les trois pièces obligatoires valides à la date de décision » nomme état, population et preuve. Le rejet retourne les éléments manquants.
Les invariants sont testés au niveau domaine et rejoués sur des dossiers historiques. Une exception légitime devient une autre transition avec autorité et motif ; elle ne désactive pas la règle pour toute la population.
Définir les transitions autorisées
Une transition contient état de départ, commande, préconditions, décideur, effets et état d’arrivée. « Modifier le statut » disparaît de l’interface au profit d’actions métier comme approuver, demander une pièce, suspendre ou annuler.
Refuser les sauts qui contournent une preuve
Passer de reçu à terminé peut sembler pratique pour corriger un dossier importé, mais efface contrôle et engagement. Une migration ou une reprise possède sa commande dédiée, ses preuves et son audit.
Les transitions concurrentes utilisent version ou verrou optimiste. Si deux personnes décident depuis le même état, alors la seconde reçoit le nouvel état et requalifie son action au lieu d’écraser la première.
Distinguer états global et partiels
Un dossier peut être administrativement complet, financièrement en attente et opérationnellement en cours. Fusionner ces axes dans un seul enum crée une explosion de combinaisons ou masque l’information utile.
Composer sans fabriquer un statut impossible
Chaque sous-cycle possède ses invariants. L’état global exprime une décision de haut niveau et référence les axes qui la justifient. Il ne concatène pas mécaniquement tous les états.
Par exemple, « exécutable » peut exiger conformité validée et paiement autorisé, tandis que la livraison reste non commencée. L’écran support montre les axes ; le tableau de pilotage peut agréger la capacité « à lancer ».
Construire des projections par usage
La vue commerciale met en avant prochaine action et échéance ; le back-office voit pièces et contrôles ; la finance voit engagement et règlement. Ces projections lisent le même état canonique et les mêmes événements.
Autoriser des libellés adaptés sans changer le sens
Un client peut lire « étude en cours » pendant que l’interne distingue trois étapes. La projection conserve le mapping versionné et ne promet pas une décision déjà prise. Toute simplification possède une phrase explicative ou une capacité associée.
Les projections sont reconstruisibles. Si leur cache diverge, un replay restaure l’affichage depuis les faits. Une colonne modifiée manuellement sans retour vers le domaine est interdite.
Chaque projection publie sa fraîcheur et la version du dernier fait traité. Une équipe sait ainsi distinguer un dossier réellement bloqué d’une vue en retard. Au-delà du seuil de deux minutes pour une action urgente, l’interface désactive le geste sensible, recharge la source et affiche la raison plutôt que de laisser l’utilisateur décider sur un état périmé.
Relier droits et transitions
Un rôle n’a pas le droit générique de modifier un état. Il peut exécuter certaines commandes sur certaines populations lorsque les préconditions sont vraies. Le domaine répond avec les capacités disponibles et leur motif d’indisponibilité.
Conserver le décideur et la délégation
L’événement porte auteur humain ou système, mandat, date et règle appliquée. Une délégation possède périmètre et échéance. L’automatisation agit comme un acteur identifié, jamais comme une mise à jour sans origine.
Le refus d’autorisation reste distinct du refus métier. Le premier protège l’accès ; le second explique pourquoi l’état ne permet pas la commande. Cette séparation réduit les contournements support.
Conserver dates et chronologie
Date effective, date d’enregistrement et date de réception peuvent différer. Le modèle conserve ces horloges et indique laquelle commande le SLA, le reporting ou la décision. Un événement tardif ne gagne pas seulement parce qu’il arrive dernier.
Mesurer le temps dans chaque état
L’âge commence à l’entrée réelle et se termine à la transition. Les pauses autorisées portent un motif et un responsable. Une moyenne globale ne doit pas masquer vingt dossiers bloqués depuis dix jours derrière mille passages rapides.
Les échéances sont des faits calculés à partir d’une règle versionnée. Si la règle change, les nouveaux dossiers l’appliquent ; les anciens sont migrés par décision explicite ou gardent leur engagement initial.
Traiter exceptions et compensations
Une exception légitime est un chemin métier nommé. Une erreur technique empêche l’exécution d’un chemin valide. Les mélanger dans « bloqué » rend impossible le bon geste et fausse la mesure.
Compenser plutôt que remonter artificiellement le temps
Après un paiement ou un envoi, revenir à l’état précédent ne supprime pas l’effet. La commande d’annulation crée remboursement, retour ou contre-écriture, puis rejoint un nouvel état explicable.
La procédure de reprise contient l’entrée, la sortie, le responsable, les dépendances, le seuil et le repli de chaque scénario. Une correction directe en base reste réservée à une intervention auditée qui produit ensuite les faits manquants.
Partager le modèle entre services
Le domaine expose commandes, événements et vues plutôt que sa table. Les consommateurs déclarent la version comprise. Les schémas décrivent forme ; le contrat métier décrit sémantique, ordre et garanties.
Garder une autorité unique sans créer un monolithe
Un service possède la décision, mais plusieurs projections peuvent la distribuer. Une API synchrone sert une action immédiate ; des événements alimentent recherche, notifications et reporting. Les deux portent le même identifiant et la même version.
Les dépendances ne se répondent pas par mises à jour circulaires. Si un paiement modifie la capacité du dossier, il émet un fait ; le domaine décide la transition. Cette direction réduit les boucles et rend le replay déterministe.
Le contrat d’intégration contient l’entrée de chaque commande, sa sortie, les erreurs métier, l’idempotence et l’ordre des événements. Le responsable du domaine surveille les rejets, la file et le délai de projection. En cas de rupture, le repli bloque les nouvelles décisions risquées tout en laissant les consultations et les opérations indépendantes continuer.
Rejouer un dossier complet
Cas concret : une demande reçoit trois pièces, passe en instruction et obtient une approbation. Le paiement échoue, puis réussit après relance. Entre-temps, une pièce expire et oblige à suspendre l’exécution sans annuler l’approbation.
Préserver chaque décision dans les projections
Le dossier reste approuvé mais non exécutable. Le commercial voit « action client requise », la conformité voit « pièce à renouveler » et la finance voit « paiement confirmé ». Chaque projection explique sa vue depuis les mêmes faits.
Après réception de la pièce, la capacité d’exécuter revient sans refaire l’approbation. Le scénario passe si historique, droits, SLA et reporting concordent, et si le support retrouve la cause de suspension en moins de trois minutes.
Une variante de frontière est aussi rejouée : la pièce expire après le début d’un effet irréversible. Dans ce cas, la suspension interdit la suite mais ne remet pas l’effet à zéro. Une tâche de compensation possède un responsable, une échéance et une preuve. Ce résultat confirme que le modèle raconte le passé autant qu’il commande la prochaine action.
Contrôler les divergences
L’instrumentation suit les transitions refusées, les états impossibles, les projections en retard, les corrections manuelles et les dossiers sans prochaine action. Les alertes portent une population et un responsable, pas seulement une exception technique.
Comparer les décisions entre écrans
Un test synthétique ouvre le même dossier dans plusieurs vues et compare capacités, pas seulement badges. Si le commercial peut annuler alors que le back-office indique un point de non-retour, l’incident est critique même si les textes semblent cohérents.
Le seuil pilote exige zéro invariant violé, 100 % des transitions critiques tracées et moins de 1 % de projection en retard au-delà du SLA. Chaque écart est rejoué avant extension.
Plan d’action et migration
Les entrées sont les écrans, les tables, les règles, les procédures, les incidents et les dossiers représentatifs. Les sorties sont la carte d’objets, les états canoniques, les transitions, les invariants, les projections, les fixtures, la migration et la procédure d’exploitation.
Passer des colonnes au contrat métier
- Jours 1 à 5 : inventorier les décisions et les vérités concurrentes.
- Jours 6 à 10 : définir objet, faits, invariants et transitions critiques.
- Jours 11 à 15 : construire projections, droits et chronologie.
- Jours 16 à 20 : rejouer vingt dossiers et qualifier les écarts.
- Jours 21 à 25 : migrer une cohorte, observer et exercer le repli.
- Jours 26 à 30 : rapprocher les vues, tenir le verdict et étendre.
- À faire d’abord : les décisions qui engagent argent, droit ou promesse.
- Ensuite : les projections qui diffusent ces décisions aux équipes.
- Puis : les automatisations dont les préconditions deviennent enfin stables.
- À différer : les badges sans conséquence opérationnelle.
- À refuser : une migration qui ne sait pas expliquer les dossiers existants.
La migration traduit chaque ancien état depuis ses faits disponibles. Les cas ambigus entrent dans une file de décision avec un responsable ; ils ne reçoivent pas un statut par défaut destiné à faire passer le script.
Le pilote commence sur une population bornée et maintient l’ancienne lecture en observation. Les écarts sont classés entre erreur de traduction, règle manquante et donnée absente. Seule la première est corrigée automatiquement.
Le repli restaure les projections et arrête les nouvelles commandes sans supprimer les faits produits. La reprise repart d’un point de coupure prouvé. Les consommateurs accusent la version du modèle qu’ils utilisent.
Le verdict exige des dossiers explicables, des actions cohérentes et une charge support maîtrisée. Si plus de 2 % de la cohorte requiert une décision manuelle non prévue, alors l’extension attend une nouvelle règle.
Éviter les erreurs fréquentes
Modéliser les écrans lie le métier à l’interface. Créer un enum géant mélange les axes. Autoriser le statut libre contourne les invariants. Réécrire l’historique détruit la preuve.
Refuser les raccourcis qui créent une seconde vérité
Calculer dans chaque front multiplie les règles. Confondre erreur et exception déclenche la mauvaise procédure. Migrer par défaut masque les cas ambigus. Mesurer seulement le statut final ignore les blocages.
Le piège inverse est une machine à états pour chaque détail. Les changements éditoriaux ou réversibles restent des attributs. Un état existe lorsqu’il change droits, prochaine action, engagement, délai ou capacité de reprise.
- Conserver comme attribut : l’information qui n’ouvre ni ne ferme aucune capacité.
- Modéliser comme état : la situation qui commande une décision durable.
- Tracer comme événement : le fait daté qui explique la transition.
Relier architecture, statuts et mesure
L’architecture d’un workflow métier à fortes exceptions traite orchestration, effets externes et compensations. Le modèle présent se concentre sur la vérité partagée par tous les consommateurs.
Compléter sans reprendre les intentions existantes
La méthode pour supprimer les zones grises des statuts métier aide à rendre les transitions lisibles. Le taux d’achèvement du workflow mesure ensuite la capacité à atteindre une sortie utile.
Ici, l’enjeu est le modèle de données et de décision qui empêche plusieurs écrans de reconstruire un dossier différent. Cette frontière renforce la landing de développement sans dupliquer l’architecture ou le pilotage du workflow.
Lorsque le run doit suivre décisions, exceptions et preuves entre équipes, Ciama peut soutenir la visibilité opérationnelle. L’application métier reste propriétaire des invariants et des transitions.
Conclusion : un état explicable
Un dossier fiable ne possède pas nécessairement un statut unique affiché partout. Il possède une histoire unique dont chaque projection restitue la part utile sans contredire les autres.
Faits, invariants, transitions, capacités, droits et chronologie forment ce modèle. Ils rendent les décisions reproductibles et les reprises possibles même lorsque les parcours deviennent complexes.
Les écrans cessent alors d’être des sources concurrentes. Ils deviennent des vues adaptées sur un contrat métier que les équipes peuvent tester, migrer et faire évoluer sans effacer le passé. Cette continuité réduit aussi le temps d’onboarding : une nouvelle personne retrouve la décision, sa preuve et la prochaine action sans dépendre d’une explication orale.
L’accompagnement de Dawap transforme ce socle en développement web sur mesure, afin que produit, opérations et technique partagent enfin la même histoire du dossier.
