Une commande affiche « en cours » depuis trois jours. Le client attend, le vendeur affirme avoir expédié et le prestataire de paiement indique une opération réussie. Le support voit trois informations plausibles, mais aucune ne dit quel événement manque ni quelle action reste autorisée. Modifier le statut à la main semble rapide ; c’est souvent le début d’un second incident.
Le premier signal faible apparaît quand deux écrans donnent des états différents pour le même dossier. Le second survient lorsque le support possède une liste privée de manipulations « qui débloquent ». Ces symptômes montrent que le statut visible n’est plus la conséquence d’une règle partagée, mais le résultat fragile de corrections successives.
Le vrai enjeu d’une machine à états consiste à rendre une décision reproductible. Vous allez comprendre comment séparer les objets, écrire leurs transitions, arbitrer la concurrence, traiter les événements tardifs et donner au support une reprise bornée. Une transition sans cette preuve reste impossible à expliquer, même si son libellé paraît correct.
Cette discipline soutient la conception d’une marketplace opérateur. Elle devient particulièrement importante dans l’architecture des intégrations du système d’information, lorsque commandes, vendeurs, paiement, logistique et service client évoluent à des rythmes différents.
Distinguer état, événement et action
Un état décrit un fait durable
Un état répond à une question que le métier peut trancher : la commande est-elle confirmée, le paiement est-il accepté, la sous-commande est-elle expédiée, le remboursement est-il exécuté ? Il reste vrai jusqu’à un nouvel événement. « Vérification du stock » décrit plutôt une action en cours ; « stock réservé » décrit le résultat durable de cette action.
Cette distinction réduit les états vagues comme « traitement », « anomalie » ou « terminé ». Un bon libellé permet au support de dire ce qui est acquis, ce qui manque et qui doit agir. Il ne cherche pas à résumer tout le dossier dans un seul mot.
Un événement explique pourquoi le fait change
L’événement rapporte quelque chose qui s’est produit : paiement autorisé, commande acceptée par le vendeur, colis remis au transporteur, délai expiré ou remboursement confirmé. Il est nommé au passé et porte les données nécessaires à la décision. Une commande ne devient pas expédiée « parce qu’un service a tourné », mais parce qu’une remise au transporteur a été constatée selon une règle définie.
L’action est la conséquence demandée : réserver le stock, notifier le client, créer une écriture financière ou solliciter un transporteur. Elle peut échouer après la transition métier. La confondre avec l’état produit des faux succès : l’interface affiche « remboursé » alors que seule la demande de remboursement a été envoyée.
Découper les états par objet métier
Une marketplace ne possède pas une machine unique. La commande acheteur, chaque sous-commande vendeur, le paiement, l’expédition, le remboursement et le litige suivent des cycles liés mais distincts. Une commande peut être confirmée alors qu’un transfert vendeur reste en attente ; écraser ces deux réalités dans un statut global crée une contradiction.
Le statut synthétique présenté au client est une projection calculée à partir de plusieurs objets. Il ne doit pas devenir une source que l’on modifie indépendamment. « Partiellement expédiée » peut ainsi être déduit de deux sous-commandes expédiées sur trois, sans inventer un événement supplémentaire au niveau de chacune.
Les frontières suivent les décisions et les responsabilités. Le domaine paiement décide si une opération financière est recevable ; le domaine logistique décide si une preuve d’expédition est valide ; le domaine commande orchestre la promesse globale. Le découpage évite qu’un composant s’autorise à réécrire le fait détenu par un autre.
Contre-intuitivement, multiplier les petits cycles cohérents simplifie souvent le support. Une immense liste de statuts paraît centralisée, mais elle combine tant de dimensions que personne ne peut expliquer une transition sans relire plusieurs systèmes.
Reconstituer les transitions réellement utilisées
Partir des décisions, pas du diagramme idéal
L’inventaire commence par les historiques de production, les tickets du support et les opérations du back-office. Pour chaque dossier problématique, l’équipe note l’état observé, l’état attendu, l’action manuelle réalisée et l’information qui manquait. Cette collecte révèle les transitions implicites que la documentation ne mentionne plus.
Les libellés identiques sont ensuite comparés. « Annulée » peut signifier refus avant paiement, annulation client, expiration vendeur, échec de stock ou décision du support. Ces causes n’ont pas les mêmes conséquences sur la commission, le remboursement et la disponibilité. Elles méritent des événements distincts, même si l’état final visible reste commun.
Repérer les chemins sans sortie
Une transition incomplète se voit lorsqu’un dossier entre dans un état dont aucune action normale ne permet de sortir. « Remboursement en attente » sans expiration, relance ni procédure d’examen devient un parking permanent. Chaque état non final doit posséder au moins une sortie métier ou une procédure d’escalade clairement bornée.
L’équipe vérifie aussi les chemins interdits. Une sous-commande remboursée ne doit pas redevenir expédiée sur réception tardive d’une notification logistique. Une commande annulée avant capture du paiement ne doit pas déclencher une demande de remboursement inutile. La liste de ces impossibilités forme une part essentielle du contrat.
Écrire le contrat de chaque transition
Le W3C décrit dans sa recommandation SCXML sur les machines à états des transitions déclenchées par des événements, soumises à des conditions et associées à du contenu exécutable. Sans imposer ce format à l’application, cette séparation offre une grille utile pour écrire un contrat compréhensible.
Chaque ligne de la matrice indique l’état source, l’événement, la condition de passage, l’état cible et les effets demandés. Elle ajoute l’acteur ou le système autorisé, les données obligatoires, le motif de refus, la version de règle et la preuve conservée. Un développeur peut l’implémenter ; le produit, le support et la finance peuvent la relire.
Les conditions restent sans effet de bord : vérifier un montant ou une version ne doit pas envoyer un courriel ni débiter un compte. Les effets surviennent après que la décision est enregistrée. Cette séparation facilite les tests et empêche une simple consultation de modifier le dossier.
Les refus sont aussi contractuels. Si l’événement arrive depuis le mauvais état, le système renvoie la situation actuelle, la transition demandée, la raison du rejet et, lorsque c’est possible, l’action autorisée. Une réponse « opération impossible » ne suffit pas au support.
Protéger les règles qui ne doivent jamais céder
Un invariant reste vrai quelle que soit la transition. Le montant remboursé ne dépasse pas le montant encaissé ; une quantité expédiée ne dépasse pas la quantité confirmée ; un transfert ne vise qu’un compte vendeur vérifié ; une commande clôturée ne porte plus de ligne active. Ces règles sont contrôlées à l’endroit qui détient la décision.
Les invariants ne sont pas de simples validations d’interface. Une notification entrante, une tâche planifiée ou une commande d’administration doit rencontrer la même protection. Sinon le chemin le moins visible devient celui qui contourne la règle.
Les contraintes techniques renforcent les règles métier : unicité d’une référence, version attendue, relation obligatoire ou plafond de montant. Elles ne remplacent pas le message métier, mais empêchent qu’une course entre deux traitements crée un état impossible avant que l’application ne réagisse.
Une exception autorisée reste une transition explicite avec motif et droit particulier. Désactiver temporairement un contrôle pour « débloquer » plusieurs dossiers efface la frontière entre réparation et nouvelle règle. Si l’exception se répète, elle doit rejoindre le modèle normal ou être refusée.
Arbitrer deux décisions concurrentes
Comparer la version lue à la version courante
Deux agents peuvent ouvrir le même dossier lorsqu’il est « à valider ». Le premier accepte, le second refuse quelques secondes plus tard depuis une page ancienne. Sans contrôle de concurrence, la dernière écriture gagne et efface une décision pourtant valide. Le système associe donc une version à l’objet et refuse la seconde transition si cette version a changé.
Le refus montre le nouvel état et invite à relire le dossier. Il ne rejoue pas automatiquement l’ancienne intention sur la version récente, car les conditions ont pu changer. Cette stratégie protège aussi les appels entre services lorsque deux réponses arrivent presque simultanément.
Définir une priorité seulement quand le métier la justifie
Certaines décisions possèdent une priorité naturelle. Une annulation confirmée avant expédition peut rendre caduque une acceptation vendeur arrivée plus tard. Dans d’autres cas, l’ordre d’arrivée ne suffit pas : un litige et une demande de remboursement doivent être examinés ensemble. La règle indique alors quelle transition bloque, remplace ou attend l’autre.
Une horloge locale ne constitue pas une preuve d’ordre entre plusieurs systèmes. L’application conserve l’heure déclarée, l’heure de réception et, si le partenaire la fournit, un numéro de séquence. Elle prend une décision selon le contrat de la source, pas selon la précision apparente d’un horodatage.
Répéter une demande sans créer un second effet
Un réseau peut couper après que le serveur a enregistré la transition mais avant que le client reçoive la réponse. La répétition est alors normale. L’idempotence signifie que plusieurs demandes équivalentes produisent le même effet métier voulu qu’une seule. Le RFC 9110 sur la sémantique HTTP donne cette définition au niveau des méthodes ; l’application doit encore protéger ses opérations métier.
Une clé de demande stable est associée à l’acteur, à l’objet et à l’intention. Si elle revient avec les mêmes données, le système retourne le résultat déjà connu. Si elle revient avec un montant ou une cible différente, il refuse l’ambiguïté au lieu de recycler silencieusement la première réponse.
L’unicité doit couvrir les effets externes. Enregistrer deux fois « remboursement demandé » n’est pas acceptable si le prestataire financier reçoit deux ordres. La clé ou la référence transmise au partenaire doit permettre de rapprocher la tentative avec l’opération effective avant toute relance.
La méthode consacrée à l’idempotence des commandes marketplace approfondit cette protection. Ici, son rôle reste précis : garantir qu’une transition et ses conséquences ne sont pas dupliquées par une répétition technique.
Traiter les événements tardifs ou désordonnés
Une notification logistique peut arriver après un remboursement, ou un succès de paiement après une expiration locale. Le système ne doit pas appliquer aveuglément l’événement au statut courant. Il vérifie sa source, son identifiant, la version du contrat et les états depuis lesquels cette transition reste autorisée.
Un événement ancien n’est pas forcément inutile. Il peut compléter l’historique, déclencher une enquête ou confirmer qu’une action externe s’est produite malgré l’annulation locale. Il ne doit simplement pas réécrire le présent sans décision. Le traitement distingue donc « information enregistrée » et « transition acceptée ».
Pour les partenaires qui fournissent un numéro de séquence, la dernière séquence appliquée est conservée par flux. Sans séquence, l’équipe définit une règle de dédoublonnage et accepte qu’une réconciliation soit nécessaire. Inventer un ordre total à partir des seules dates rend le système sûr en apparence, pas dans les faits.
Le coût caché des événements tardifs apparaît dans les corrections en cascade : stock remis à tort, client notifié deux fois, commission recalculée puis export comptable repris. Les bloquer tôt et les diriger vers une file qualifiée coûte moins cher que réparer chaque conséquence.
Représenter l’échec sans fabriquer de faux succès
Séparer décision acceptée et effet confirmé
Une commande peut être acceptée alors que la notification vendeur échoue. Un remboursement peut être demandé alors que le partenaire de paiement ne l’a pas encore exécuté. Le modèle conserve ces deux dimensions : la décision métier et l’état de l’effet externe. Il n’annonce pas le résultat avant sa confirmation.
Les états intermédiaires restent limités aux situations que le support doit comprendre ou que le système doit reprendre. Créer un statut pour chaque étape interne d’un traitement transforme le parcours métier en tableau technique illisible. Les détails fins vivent dans les tentatives et les journaux.
Donner une échéance à chaque attente
Un état « en attente » indique ce qui est attendu, de qui et jusqu’à quand. À l’expiration, une transition relance, escalade, annule ou place le dossier en examen. Sans échéance ni action, le système ne sait pas distinguer une latence normale d’un dossier oublié.
La reprise précise les entrées nécessaires, la file concernée, les responsabilités, le seuil d’escalade et la sortie attendue. Cette traçabilité permet à une autre personne de résoudre le cas sans message privé ni accès exceptionnel.
Corriger par compensation sans effacer le passé
Une transition effectuée ne se « détransitionne » pas toujours. Si un paiement a été capturé, revenir visuellement à « paiement autorisé » ne rend pas l’argent. La correction demande une opération inverse ou compensatrice, puis un nouvel état qui décrit son résultat.
Le même principe s’applique au stock, aux commissions et aux notifications. Réserver puis libérer une quantité produit deux faits utiles. Les remplacer par la valeur finale masque la durée de réservation et empêche d’expliquer une indisponibilité observée entre-temps.
La compensation peut échouer. Le dossier porte alors l’intention de correction, la tentative et le résultat externe. Le support doit pouvoir dire : « l’annulation est acceptée, le remboursement est encore en attente », plutôt que présenter une clôture faussement rassurante.
Une correction administrative suit elle aussi une transition autorisée. Elle indique la donnée erronée, l’ancienne valeur, la nouvelle valeur, le motif et la personne habilitée. L’historique ne doit pas être modifié directement pour ressembler au résultat souhaité.
Conserver un historique utile et proportionné
Journaliser la décision plutôt que tout dupliquer
Une entrée utile contient l’objet, l’état source, l’événement, l’état cible, l’acteur, la date, la version et le motif. Elle référence les preuves ou opérations externes sans recopier aveuglément leur contenu. Le journal reste ainsi consultable et limite la duplication de données sensibles.
Les paramètres nécessaires à l’explication sont conservés selon une durée définie. Les secrets, jetons d’accès et pièces non pertinentes sont exclus. Un historique complet n’est pas une collecte illimitée ; il doit respecter les règles de sécurité, de confidentialité et de conservation applicables.
Corréler sans confondre trace technique et preuve métier
Le standard W3C Trace Context définit un format partagé pour propager un identifiant à travers plusieurs composants. Cette corrélation aide à suivre une opération distribuée, mais elle ne remplace pas le motif métier ni l’autorisation de la transition.
Le dossier associe donc identifiant métier, identifiant de demande et identifiant de trace technique. Le support part du dossier ; l’équipe technique peut ensuite retrouver les appels concernés. Afficher seulement une longue référence de trace ne rend pas la décision compréhensible.
Donner au support une explication actionnable
L’écran présente l’état actuel, sa date, l’événement qui l’a produit et l’acteur concerné. Il sépare les sous-objets : commande, sous-commandes, paiement, expéditions, remboursements et litiges. La synthèse reste visible, mais chaque divergence peut être développée.
Les actions proposées dépendent de l’état et des droits. Le support ne voit pas un bouton universel « changer le statut » ; il voit relancer la confirmation, demander une pièce, annuler selon le motif autorisé, ouvrir un examen ou transférer à la finance. Chaque action annonce ses conséquences avant validation.
Un refus d’action explique la condition manquante : paiement non confirmé, version du dossier modifiée, délai dépassé, expédition déjà constatée ou bénéficiaire non vérifié. La personne peut alors résoudre la cause, au lieu de chercher un accès plus puissant.
Le back-office opérateur et ses écrans indispensables complète cette approche en structurant recherche, preuves, droits et traitement des exceptions pour l’exploitation quotidienne.
Suivre une commande avec deux vendeurs
Du paiement à l’expédition partielle
Par exemple, un client commande deux produits auprès de vendeurs différents. Le paiement global est autorisé, puis la plateforme crée deux sous-commandes. Le vendeur A accepte et expédie ; le vendeur B refuse faute de stock. La commande globale devient « partiellement confirmée », mais les états détaillés restent « expédiée » et « refusée ».
Le refus du vendeur B déclenche la libération de son stock éventuel et une demande de remboursement partiel. Il ne modifie ni l’expédition A ni sa future commission. L’état client est calculé depuis les deux sous-commandes et l’état du remboursement, sans forcer tous les objets vers un libellé commun.
Ajouter une notification tardive
Dans un second scénario, une ancienne notification du vendeur B annonce une acceptation après le refus. La transition est rejetée, car la sous-commande n’est plus dans un état compatible et sa version a changé. L’événement est conservé comme information tardive avec son identifiant ; il ne recrée pas une vente.
Si la notification révèle qu’une expédition réelle a tout de même eu lieu, le support ouvre un examen distinct. Il ne fait pas passer directement la sous-commande à « expédiée », car le paiement, le stock et la communication client ont déjà suivi la décision de refus. Le cas exige une compensation coordonnée.
Tester la matrice, la concurrence et les pannes
Les tests unitaires parcourent chaque transition autorisée et vérifient chaque transition interdite. Pour un état donné, ils couvrent événement valide, condition absente, acteur non habilité, version ancienne et données invalides. La matrice devient ainsi une spécification exécutable plutôt qu’un schéma oublié.
Les tests de concurrence lancent deux décisions sur la même version. Une seule réussit ; l’autre reçoit l’état récent sans effacer la première. Les tests de répétition rejouent la même clé avec les mêmes données, puis avec des données différentes, afin de contrôler résultat stable et rejet d’ambiguïté.
Les tests d’intégration interrompent la réponse du partenaire après l’envoi d’un effet externe. La reprise doit consulter l’opération existante avant de retenter. Ils injectent aussi notification tardive, ordre inversé, doublon et indisponibilité temporaire.
Enfin, une recette avec le support demande d’expliquer plusieurs dossiers sans aide des développeurs. Le test réussit lorsque la personne retrouve la cause, l’action autorisée et la preuve depuis l’interface, même si aucune correction n’est permise immédiatement.
Mesurer les blocages et corrections manuelles
Le volume de dossiers par état révèle les accumulations, mais l’ancienneté est plus décisive. Dix remboursements en attente depuis cinq minutes peuvent être normaux ; deux dossiers bloqués depuis vingt jours demandent une enquête. Chaque attente possède donc une durée cible par catégorie.
Le taux de transitions refusées est segmenté par événement et cause. Une hausse peut signaler un partenaire qui envoie des notifications tardives, une interface qui travaille sur des versions anciennes ou une règle devenue trop stricte. Masquer les refus par des reprises automatiques ferait perdre ce diagnostic.
Le nombre de corrections administratives mesure la dette du modèle. Chaque correction porte un motif ; les motifs répétés alimentent une décision produit. Un objectif de zéro correction n’est pas réaliste pour toutes les activités, mais une hausse durable indique que le parcours normal ne représente plus le terrain.
Le délai de compréhension par le support complète les mesures techniques. Si la transition est correcte mais nécessite vingt minutes et trois outils pour être expliquée, l’exploitation reste coûteuse. La cible consiste à résoudre les cas courants depuis un dossier unifié et à transmettre seulement les vraies exceptions.
Éviter les erreurs fréquentes de modélisation
Créer un état pour chaque détail technique
Des statuts comme « message placé dans la file » ou « troisième tentative lancée » exposent l’implémentation sans aider la décision métier. Ces informations appartiennent au suivi technique. Le support a besoin de savoir quel effet est attendu, depuis quand et quelle issue est prévue.
Le bon niveau conserve « remboursement en attente » dans le dossier et place le nombre de tentatives dans le détail technique. La personne comprend ainsi la promesse sans perdre l’information utile au diagnostic.
Autoriser le changement direct de statut
Un menu déroulant universel contourne conditions, effets et historique. Il donne l’impression de réparer vite, mais crée des dossiers dont les mouvements financiers ou logistiques ne correspondent plus à l’écran. Les opérations de support doivent appeler des transitions métier dédiées.
Si une correction exceptionnelle reste nécessaire, elle possède son propre droit, un motif obligatoire et des conséquences annoncées. Elle ne doit jamais devenir un raccourci partagé pour éviter la règle normale.
Utiliser un état global comme source unique
La commande, le paiement et l’expédition ne se terminent pas au même moment. Un statut global reste une synthèse de lecture ; le prendre comme vérité de toutes les dimensions détruit l’information nécessaire aux remboursements partiels et aux commandes multi-vendeurs.
La synthèse doit pouvoir être recalculée depuis les objets responsables. Lorsqu’elle diverge, l’équipe corrige la projection ou la source défaillante, pas les deux valeurs indépendamment.
Ignorer les événements rejetés
Un événement invalide ou tardif peut signaler une divergence réelle. Le supprimer sans trace empêche de détecter un partenaire désynchronisé. Il faut enregistrer le rejet avec sa cause, sans pour autant appliquer la transition.
Une alerte agrégée distingue alors le bruit ponctuel d’une série anormale. Le support conserve le dossier, tandis que l’équipe d’intégration dispose des références nécessaires pour enquêter sur la source.
Savoir quand une machine à états est justifiée
Elle devient utile dès qu’un objet traverse plusieurs décisions, implique plusieurs acteurs ou déclenche des effets externes. Commande multi-vendeur, onboarding, paiement, remboursement, litige et modération sont de bons candidats, car leur historique et leurs sorties conditionnent directement l’exploitation.
Elle peut rester légère pour un parcours court, local et réversible. Une table de transitions explicite dans le code suffit souvent ; adopter un moteur spécialisé n’est pas une obligation. L’essentiel réside dans le contrat, les invariants et les tests, pas dans le nom de l’outil.
Un moteur devient pertinent lorsque les parcours sont nombreux, configurables ou partagés entre plusieurs composants. Il faut alors évaluer versionnement, persistance, concurrence, visibilité, reprise et compétences d’exploitation. Ajouter une dépendance lourde pour trois statuts stables augmente le coût sans améliorer l’explication.
La décision doit d’abord viser les objets qui produisent le plus de corrections manuelles, de pertes financières ou d’incompréhensions client. Modéliser tout le catalogue en une fois retarde la valeur ; fiabiliser un parcours critique fournit une preuve plus utile.
Plan d’action : fiabiliser un parcours en six semaines
Semaines 1 et 2 : inventorier et décider
L’équipe sélectionne un objet critique, extrait un échantillon de dossiers et reconstruit les transitions normales, manuelles et impossibles. Produit, support, opérations et technique nomment les états comme des faits, séparent les objets et écrivent les invariants.
Une matrice précise pour chaque transition les entrées, la condition, les responsabilités, les effets, le motif de refus et la sortie attendue. Les cas sans décision claire sont arbitrés ou retirés du périmètre initial.
Semaines 3 et 4 : implémenter et observer
Le développement introduit version, historique, clés de répétition et contraintes d’unicité. Les effets externes obtiennent des références réconciliables. L’interface du support expose état courant, événement source, divergence et actions autorisées.
Les journaux techniques propagent un identifiant de corrélation sans recopier les secrets. Les alertes surveillent états anciens, transitions refusées, événements tardifs et opérations externes dont l’issue reste inconnue.
Semaines 5 et 6 : éprouver puis ouvrir
La recette exécute concurrence, répétition, ordre inversé, expiration, panne partenaire et compensation. Le support traite les scénarios depuis le back-office ; la technique intervient seulement lorsque la règle prévoit une escalade.
Le déploiement commence sur une catégorie ou un volume borné. L’extension est autorisée lorsque les états anciens diminuent, les refus sont expliqués et aucune correction directe n’est nécessaire pour les cas courants.
- Choisir l’objet dont les statuts incohérents produisent le plus de risque client, financier ou opérationnel.
- Écrire ses transitions autorisées et interdites avant de choisir un moteur ou de modifier le back-office.
- Tester concurrence, répétition, événements tardifs et effets externes avant le premier dossier réel.
- Élargir seulement quand le support explique et reprend le parcours sans modification directe ni information privée.
- Ouvrir. Les invariants tiennent, l’historique explique les décisions et chaque effet externe possède une référence rapprochée.
- Différer. Un état ancien ou une opération incertaine exige encore une intervention technique non documentée.
- Refuser. Une transition permet d’effacer le passé, de contourner un droit ou de produire deux effets sur répétition.
Guides complémentaires sur architecture et support
La machine à états encadre les décisions d’un objet. Les ressources suivantes approfondissent le découpage des responsabilités, l’architecture globale et l’interface nécessaire à l’exploitation.
Découper la marketplace selon les décisions métier
La méthode sur les contextes métier bornés d’une marketplace aide à séparer commande, paiement, catalogue et logistique sans créer un modèle partagé que chaque composant peut réécrire.
Elle complète la machine à états lorsque l’équipe doit décider quel domaine possède une transition et quelles informations doivent seulement être projetées ailleurs.
Concevoir l’architecture technique complète
Le cadrage de l’architecture technique d’une marketplace replace les états dans l’ensemble formé par le front, les interfaces, le catalogue, les commandes, les paiements et les systèmes de l’entreprise.
Cette vision évite de résoudre localement un statut alors que la responsabilité ou la donnée de référence se trouve dans un autre composant.
Orchestrer un service de bout en bout
Le parcours d’une marketplace de services montre comment appliquer ces principes à qualification, devis, capacité, preuve, paiement et litige.
Il illustre un cas où plusieurs cycles autonomes doivent produire une expérience cohérente sans être aplatis dans un statut unique.
Conclusion : expliquer avant de permettre une correction
Une machine à états utile ne cherche pas à multiplier les libellés. Elle transforme chaque changement en décision vérifiable, avec un point de départ, un événement, une règle, une cible et des conséquences maîtrisées.
La qualité se voit lorsque le parcours quitte le cas idéal. Concurrence, répétition, événement tardif et panne externe doivent laisser le dossier dans un état vrai, même si une action reste à reprendre.
Le support gagne alors une explication et des actions bornées. Il n’a plus besoin de corriger le statut pour que l’écran ressemble à la situation ; le système porte réellement l’historique et la prochaine décision autorisée.
Dawap accompagne la modélisation, l’intégration et les écrans d’exploitation nécessaires à une marketplace opérateur explicable et maintenable, depuis la première matrice jusqu’aux scénarios de reprise.
