Lorsqu’une commande, une demande ou un dossier traverse plusieurs applications, il est courant que chaque équipe en voie une situation différente. Le CRM peut l’afficher comme « clôturé », l’outil opérationnel comme « en attente » et le service client comme « en suspens ». Il ne s’agit pas toujours d’une défaillance technique : c’est souvent le résultat de l’absence de définition de ce que représente chaque état, du système habilité à le modifier et des faits qui le justifient.
La conception des états de processus dans les intégrations transforme un parcours métier en contrat compréhensible entre les équipes produit, opérations et technologie. Son objectif n’est pas d’imposer un catalogue identique à toutes les applications. Il consiste à garantir qu’un état partagé possède une signification univoque, une preuve observable et des règles de transition respectées par tous les systèmes connectés.
Déterminer si un état partagé est nécessaire
Tous les systèmes ne doivent pas utiliser les mêmes états internes. Une application peut nécessiter des étapes techniques qui n’apportent aucune valeur aux autres équipes : validation de format, file d’attente, synchronisation ou calcul. Le problème apparaît lorsqu’un état sert à coordonner des décisions entre différents domaines ou à communiquer une promesse au client.
Il est pertinent de mettre en place un modèle partagé si un ou plusieurs de ces signes sont présents :
- Deux équipes répondent différemment à la question : « qu’est-il arrivé à cette demande ? ».
- Une application autorise une action sur la base d’un état qu’une autre ne reconnaît pas encore.
- Les annulations, les rejets ou les reprises sont gérés par des canaux manuels.
- Les rapports agrègent des libellés locaux qui semblent équivalents, mais couvrent des cas différents.
- Les nouvelles tentatives d’une intégration ramènent un processus à une phase antérieure ou dupliquent des tâches.
Si le besoin consiste uniquement à afficher des informations locales, une table de correspondance peut suffire. Par exemple, plusieurs états techniques peuvent être présentés comme « en cours » dans une vue métier. Mais si plusieurs systèmes prennent des décisions, facturent, notifient ou clôturent du travail selon cette phase, un contrat explicite est nécessaire. Traduire des libellés ne remplace pas la définition des responsabilités ni des transitions.
Concevoir le modèle à partir du parcours métier
Le meilleur point de départ n’est pas la liste des états d’un outil existant, mais le cycle de vie de l’entité métier. Représentez le parcours complet d’une commande, d’un dossier ou d’une demande, puis demandez-vous quel engagement représente chaque étape. Dans de nombreux processus transverses, cinq moments apparaissent, même si leurs noms changent :
- Début : l’entité existe et a été reçue ou créée.
- Évaluation ou engagement : les informations sont vérifiées, puis la demande est acceptée, rejetée ou fait l’objet d’une demande de correction.
- Exécution : un travail est activement mené pour honorer l’engagement.
- Résultat : l’exécution se termine par un succès, un échec, un rejet ou une annulation.
- Clôture : les conséquences ultérieures sont réalisées, telles que la communication, le rapprochement ou l’archivage.
Ces moments n’imposent pas de créer cinq états. Ils servent à identifier les décisions importantes. Un état mérite d’exister lorsqu’il modifie ce qu’une personne ou un système peut faire, l’attente qu’une autre partie doit recevoir ou le contrôle opérationnel requis. Si deux états entraînent exactement les mêmes décisions, ils ajoutent probablement de la complexité sans valeur.
Pour chaque état partagé, documentez au minimum :
- Sa définition en langage métier et la condition observable qui l’atteste.
- L’entité à laquelle il s’applique et, si nécessaire, sa portée : demande complète, ligne, expédition ou tâche.
- Le système propriétaire autorisé à le confirmer.
- Les états d’origine autorisés et les déclencheurs valides.
- Les actions activées, interdites ou obligatoires lors de son entrée.
- La politique de sortie : automatique, manuelle, déclenchée par un événement externe ou par le temps.
Une définition telle que « terminé lorsque l’équipe a fini » est ambiguë. Il vaut mieux écrire : « terminé lorsque le système opérationnel enregistre que toutes les tâches obligatoires de la demande ont été achevées avec succès ». Cette formulation peut ainsi être vérifiée, auditée et automatisée.
Ne pas confondre état, événement, motif et action
Une grande partie des incohérences provient de l’utilisation d’un même libellé pour des concepts différents. Les séparer réduit les discussions et permet de conserver le contexte sans multiplier les états.
- État : condition actuelle et persistante de l’entité, telle que « en exécution » ou « annulée ».
- Événement : fait survenu à un instant donné, tel que « paiement autorisé », « documents reçus » ou « opération démarrée ».
- Motif : explication codifiée d’une décision ou d’un résultat, comme un motif de rejet ou d’annulation.
- Action : instruction visant à provoquer un changement, telle que « annuler la demande », « relancer l’envoi » ou « affecter un agent ».
Par exemple, « le client a appelé » ne devrait pas être un état : c’est un événement d’interaction. « Annulée car doublon » associe un état final et un motif. Les séparer permet de mesurer les annulations sans perdre leur cause et évite de créer une interminable liste de variantes.
Il convient également de distinguer l’état métier de l’état technique. « Message en attente de publication » peut être essentiel à l’observabilité, mais ne doit pas remplacer « demande acceptée ». Maintenez l’état métier indépendant des détails de transport ; exposez les données techniques lorsqu’elles aident à résoudre des incidents.
Attribuer l’autorité et contrôler les transitions
Un état partagé nécessite une source de vérité pour chaque décision, même si l’entité est répliquée à plusieurs endroits. Le CRM peut être propriétaire de l’admission d’une demande ; le système opérationnel, de son exécution ; et un système financier, d’une confirmation d’encaissement. Le risque consiste à autoriser plusieurs systèmes à écrire le même état sans règle de priorité.
Construisez une matrice simple comprenant l’état, le système autorisé, la preuve et les consommateurs. Définissez ensuite les transitions autorisées. Un diagramme est utile, mais les règles doivent pouvoir être implémentées. Par exemple :
reçue -> validée -> en_exécution -> terminée reçue|validée|en_exécution -> annulée validée -> rejetée
Toutes les transitions ne doivent pas être réversibles. Les états terminaux doivent être traités comme terminaux, sauf correction gouvernée. Si une erreur apparaît après le passage à « terminée », il ne convient pas de revenir silencieusement à « en exécution ». Enregistrez une action corrective, le motif, le responsable et, si le métier l’exige, un nouveau cycle ou une entité dérivée.
Les états intermédiaires sont nécessaires lorsqu’ils modifient une attente ou une règle opérationnelle. « En attente du client » peut justifier la suspension d’un délai et déclencher une communication ; « en file d’attente » est peut-être une condition interne qui ne doit pas sortir du système opérationnel. Définissez également des limites de temps : combien de temps une demande peut rester dans chaque phase, qui examine l’exception et quelle alerte est générée.
Annuler, relancer et récupérer sans créer de régressions
Les intégrations distribuées échouent, prennent du retard et peuvent livrer plusieurs fois le même message. La conception des états doit en tenir compte. Publier un changement n’implique pas que tous les consommateurs le traiteront une seule fois, ni dans un ordre parfait.
Pour chaque changement d’état, publiez un identifiant stable de l’entité, un identifiant unique de l’événement, le nouvel état, la date effective, l’origine et une version ou une séquence. Un consommateur doit pouvoir ignorer sans risque un événement déjà appliqué et détecter un événement ancien. L’opération de mise à jour doit être idempotente : traiter deux fois le même changement ne peut pas créer deux tâches, deux notifications ou deux annulations.
Les nouvelles tentatives techniques ne devraient pas non plus modifier à elles seules l’état métier. Si la livraison d’un message annonçant « en exécution » échoue, relancez la livraison et enregistrez l’incident ; ne ramenez pas la demande à « validée ». Lorsque des messages arrivent dans le désordre, définissez une politique explicite : rejeter les événements portant une version inférieure, les conserver pour examen ou ne les accepter que si la transition reste valide.
L’annulation exige une décision métier claire. Déterminez :
- Quels états autorisent une annulation par le client, par les opérations ou automatiquement.
- Quels effets doivent être compensés : tâches, réservations, communications ou mouvements ultérieurs.
- Dans quels cas l’annulation est immédiate et dans quels cas elle reste « demandée » jusqu’à ce qu’un système confirme qu’il peut arrêter le travail.
- Quels motifs sont obligatoires et quels rôles peuvent réaliser une correction manuelle.
Une modification manuelle doit laisser une trace ; elle n’est pas une exception invisible. Conservez l’identité de son auteur, la date, le motif, l’état précédent et les effets notifiés. Ces informations permettent de résoudre les réclamations et d’améliorer des règles défaillantes.
Exemple et contrôles avant le déploiement
Imaginez une demande créée dans un formulaire, gérée dans un CRM, exécutée dans une application opérationnelle et consultée par le service client. Le formulaire peut créer l’état « reçue », le CRM confirmer « validée » ou « rejetée », et les opérations déclarer « en exécution » puis « terminée ». Le service client consomme l’état partagé, mais ne le modifie pas. Si le client demande une annulation pendant l’exécution, le service client crée une action d’annulation ; le système opérationnel confirme ensuite « annulée » ou indique qu’il n’est plus possible d’arrêter le travail. Une demande est ainsi distinguée d’un résultat.
Avant de mettre en œuvre le modèle, passez en revue cette liste de contrôle :
- Chaque état répond-il à une décision métier ou opérationnelle réelle ?
- Existe-t-il une condition observable et un unique système autorisé à la confirmer ?
- Les motifs, événements et actions sont-ils séparés de l’état persistant ?
- Les transitions non valides, les états terminaux et les corrections exceptionnelles sont-ils définis ?
- Les consommateurs prennent-ils en charge les doublons, les retards et les messages reçus dans le désordre ?
- Existe-t-il des alertes en cas de durée anormale et un rapprochement entre la source et les répliques ?
- Les modifications du contrat incluent-elles une version, des responsables et un plan de compatibilité ?
Le modèle doit évoluer avec le processus, mais pas par des changements informels de libellés. Examinez régulièrement les états qui connaissent le plus d’attentes, d’interventions manuelles, d’écarts ou de demandes auprès du support. Ces signaux indiquent qu’une définition est insuffisante, qu’un événement manque ou qu’un état technique est utilisé pour représenter une décision métier. Un contrat restreint, explicite et gouverné est plus utile qu’un catalogue exhaustif qu’aucun système n’interprète de la même façon.