Un agent hôtelier traite une réservation directe. Le workflow est vert : appel API réussi, confirmation préparée, CRM mis à jour. Plus tard, la réception constate qu’aucune réservation n’existe dans le PMS.
Pour le workflow, le run a réussi. Pour l’hôtel, la chambre n’est pas réservée.
La réconciliation sert à détecter cet écart. On ne demande plus seulement si les étapes techniques ont renvoyé un statut positif ; on vérifie si l’état métier attendu existe réellement dans le système cible.
Les équipes financières font ce genre de rapprochement depuis toujours. Les automations IA l’oublient facilement parce que l’outil de workflow montre déjà des coches vertes. Elles ne racontent qu’une partie de l’histoire.
La réconciliation commence par une post-condition
Il faut définir ce que « terminé » signifie.
Pour un rendez-vous : exactement un événement calendrier, bon client, bonne heure et bonne prestation ; CRM avec l’ID du rendez-vous ; confirmation client liée à ce même objet.
Pour une réservation d’hôtel : ID PMS confirmé, dates et tarif corrects ; dossier client lié ; message de confirmation avec la même référence.
Pour un follow-up : message accepté par le fournisseur, statut CRM mis à jour et prochaine tâche créée.
Le statut success du workflow n’est pas la post-condition.
Fait confirmé : les workflows distribués peuvent produire des états partiels ou incohérents ; les patterns Saga et les transactions compensatoires adressent ce type de processus multi-étapes.
Recommandation : écrivez un état final vérifiable par machine pour les automations importantes.
Les trois écarts à chercher
Missing : l’objet attendu n’existe pas. Timeout, mapping erroné, mauvaise destination ou suppression ultérieure.
Wrong : l’objet existe mais avec mauvaise heure, mauvais client, mauvais montant ou statut.
Duplicate : l’objet existe plusieurs fois. La réconciliation rencontre alors l’idempotence.
Il faut distinguer ces erreurs de l’eventual consistency. Certains systèmes prennent du temps à propager une écriture. Un contrôle immédiat peut générer un faux incident.
Choisissez donc une fenêtre adaptée : quelques secondes, cinq minutes ou fin de journée selon la conséquence métier.
Le contrôle doit rester déterministe lorsque les données le permettent
Pour vérifier « la réservation 88421 existe-t-elle ? », un modèle de langage n’est pas nécessaire.
Le flow peut être simple :
- Enregistrer l’état attendu au moment de l’action.
- Lire le système cible après le délai choisi.
- Comparer la post-condition : présence, champs essentiels, nombre d’objets, références.
- Appliquer les tolérances prévues : sync, arrondi ou transformation légitime.
- Recontrôler les écarts transitoires.
- Créer une exception avec owner pour les différences persistantes, avec attendu, réel et dernier step connu.
L’IA peut résumer des logs ou aider sur un dossier non structuré. Les contrôles exacts sont généralement plus fiables avec des IDs et des règles.
Une différence n’est pas toujours une erreur à corriger
Pendant une panne, une employée déplace manuellement un rendez-vous de 14 h à 15 h. L’état attendu du vieux job indique toujours 14 h.
Le contrôle voit la différence. S’il « répare » automatiquement à 14 h, il écrase une décision humaine correcte.
Le processus doit tenir compte de la récence et de l’origine. Qui a modifié ? Quand ? Le cas était-il en degraded mode ? La valeur peut-elle être restaurée sans conséquence client ?
Un tag interne manquant peut être corrigé automatiquement. Une heure, un prix ou un paiement modifié par un humain doit souvent produire une exception.
Le handover ne doit concerner que cette minorité ambiguë, pas tous les dossiers.
Pilote minimal : un rapprochement quotidien
Choisissez un seul workflow avec une sortie claire. Pour chaque action, stockez l’ID cible ou une clé métier stable. Faites tourner le contrôle à intervalle régulier.
Injectez volontairement quatre problèmes : objet supprimé, champ modifié, doublon et synchronisation retardée. Le système doit repérer les trois premiers sans faire trop de bruit sur le quatrième.
Mesurez le taux de post-conditions remplies, les missing/wrong/duplicate, les faux alertes, le temps moyen de détection, le temps moyen de résolution et les exceptions avec un owner explicite.
Regardez surtout les cas métier incomplets que le workflow d’origine avait marqués comme succès. C’est là que la réconciliation apporte le plus de valeur.
Conclusion : 200 OK n’est pas l’achèvement du processus. L’automation est terminée lorsque le bon état existe réellement dans le système qui fait foi. La réconciliation crée cette vérification.
Le rapprochement a besoin d’un registre minimal de l’intention. Au moment de l’action, stockez ce qui était attendu, la clé métier, l’ID cible si disponible, l’heure et le dernier état connu. Sans cette trace, le contrôle du lendemain ne sait pas distinguer « objet manquant » de « objet créé sous un autre identifiant ».
La fréquence doit suivre le risque métier. Un ticket interne peut être contrôlé en fin de journée ; une réservation pour le jour même mérite une vérification beaucoup plus rapide. Il faut aussi prévoir un délai de grâce pour les systèmes à cohérence éventuelle, sinon le rapprochement produit une avalanche de faux positifs juste après chaque écriture.
Enfin, séparez détection et réparation. Beaucoup de différences peuvent être détectées automatiquement, mais seules les corrections à faible impact devraient être appliquées sans revue. Pour un prix, un paiement, un rendez-vous ou une décision humaine récente, le système crée un dossier d’exception avec état attendu, état réel et dernière action connue.
L'idempotence évite des doublons. L'arrêt d'urgence limite l'erreur. Le rapprochement prouve le résultat.
Sources
FAQ
La réconciliation est-elle juste du logging ?
Non. Les logs montrent des événements ; la réconciliation compare le résultat attendu avec l’état actuel.
Faut-il contrôler immédiatement ?
Pas toujours. Respectez les délais normaux de synchronisation pour éviter les faux positifs.
Peut-on réparer automatiquement les écarts ?
Oui pour des cas sûrs et réversibles. Les états clients ou financiers méritent plus de prudence.
L’IA est-elle nécessaire au rapprochement ?
Non. Les règles déterministes sont souvent meilleures pour des IDs et champs structurés.
Quelle différence avec l’idempotence ?
L’idempotence empêche les doublons ; la réconciliation contrôle après coup les résultats manquants, faux ou multiples.