Orchestration : faire circuler l'information entre vos outils

Chaque outil détient une part de la vérité. La comptabilité connaît les factures, le CRM connaît les clients, le tableur de suivi connaît les commandes en cours, la messagerie connaît les échanges, l'enregistreur connaît les événements.

Aucun ne détient l'ensemble. Et pour reconstituer une vue complète, quelqu'un exporte, copie, colle, recoupe.

Ce travail de couture est invisible, chronophage, et il ne produit rien : il ne fait que compenser l'absence de connexion.

Le réflexe classique est de vouloir un système unique. Un ERP qui ferait tout.

Ce projet échoue presque toujours dans une PME. Il coûte cher, prend des années, demande de migrer des données, et aboutit souvent à un outil qui fait tout moyennement là où les précédents faisaient bien chacun leur partie.

L'orchestration prend le problème par l'autre bout : on ne remplace rien, on fait circuler l'information entre ce qui existe.

Tout projet d'intégration se ramène à trois situations, et il faut les distinguer au diagnostic.

Le système expose une API. Cas favorable : lecture et écriture propres, authentifiées, documentées. La plupart des outils modernes entrent dans cette catégorie.

Le système ne produit que des fichiers. Exports, rapports périodiques, dépôts partagés. On travaille sur ces fichiers. C'est moins élégant, parfaitement viable, et cela couvre une bonne partie des logiciels de gestion marocains.

Le système est fermé. Il reste l'interface, l'export manuel périodique, ou la décision de ne pas l'intégrer. Nous le disons franchement plutôt que de promettre une connexion fragile qui cassera à la première mise à jour.

Ce sont elles qui séparent une orchestration qui tient d'une orchestration qui crée des dégâts.

Règle 1 · L'idempotence. Rejouer une opération ne doit jamais produire un doublon.

Concrètement : si une coupure réseau interrompt un enchaînement au milieu et que le système reprend, il ne doit pas créer une deuxième facture, envoyer une deuxième relance ou passer une deuxième commande. Chaque opération porte un identifiant unique, et le système vérifie qu'elle n'a pas déjà été effectuée.

C'est le défaut le plus courant des automatisations improvisées, et il se découvre toujours au pire moment.

Règle 2 · La file d'attente avec reprise. Quand un système est indisponible, l'opération est mise en attente et rejouée quand il revient. Elle n'est pas perdue, et elle n'est pas exécutée à moitié.

Sans cette règle, une indisponibilité de quinze minutes produit un trou dans les données que personne ne remarque avant des semaines.

L'orchestration classique enchaîne des actions selon des règles. La couche d'intelligence traite ce que la règle ne peut pas traiter.

Interpréter une entrée non structurée. Un email libre, un document, un message. La règle ne sait pas quoi en faire ; le modèle en extrait l'information et la règle prend le relais.

Router selon le contenu. Diriger une demande vers le bon service selon ce qu'elle dit, pas selon un mot-clé dans l'objet.

Décider quand transmettre. Sur un cas atypique, le système signale au lieu d'appliquer une règle inadaptée.

La ligne de partage reste la même : le modèle interprète, la règle exécute et vérifie.

Un journal complet. Qui a circulé, quand, dans quel sens, avec quel résultat. Sans journal, une anomalie est indiagnosticable.

Des enchaînements versionnés. On doit pouvoir savoir quelle version tournait quand, et revenir en arrière.

Une gestion explicite des cas d'échec. Que se passe-t-il si le système cible ne répond pas ? Si la donnée est refusée ? Si le format a changé ? Ces réponses doivent exister avant la mise en production, pas être découvertes après.

L'orchestration ne fait rien de visible : elle fait circuler. C'est pourtant elle qui transforme une capacité technique en gain opérationnel — et les deux règles d'idempotence et de reprise sont ce qui la rend sûre.