Guide · Méthode et architecture
Trois outils IA dans l’entreprise, et personne pour dire lequel décide.
Le service client a son assistant, la compta teste un lecteur de factures, un commercial paie un abonnement de son côté. Chacun fonctionne. Aucun ne sait ce que l’autre a déjà fait, ni lequel doit s’arrêter quand le dossier devient ambigu.
Demander un diagnostic
Ce que ce guide établit
- 01
Un outil exécute, une orchestration décide
Elle définit l’ordre des étapes, la source qui fait foi et le moment où la main revient à une personne.
- 02
Elle se juge sur les cas ambigus
Une démonstration réussit toujours sur le cas propre. La valeur se mesure sur le dossier en double et la pièce illisible.
- 03
Elle n’impose pas de remplacer vos logiciels
La couche se pose au-dessus du CRM, de l’ERP et de la messagerie qui sont déjà en place.
Ce que le mot désigne exactement.
L’orchestration IA est la couche qui décide quel outil agit, sur quelle donnée, dans quel ordre, et à quel moment le travail repasse à une personne. Elle ne produit rien elle-même. Elle organise des composants qui, eux, produisent : un modèle qui lit un document, une règle qui vérifie un format, un connecteur qui écrit dans l’ERP, une notification qui réveille un humain.
La distinction n’est pas un raffinement de vocabulaire, elle se voit sur une facture. Un assistant conversationnel coûte un abonnement par utilisateur et laisse chaque personne libre de son usage. Une orchestration coûte un travail de conception une fois, puis fonctionne sans que quiconque ait à s’en souvenir. La première dépend de la discipline de vingt personnes, la seconde d’un flux écrit.
Beaucoup de PME possèdent déjà les composants et n’ont pas la couche. C’est la situation la plus fréquente que nous rencontrons : trois outils qui marchent, zéro chemin entre eux, et une personne qui fait la liaison à la main sans que ce soit écrit dans sa fiche de poste.
Quatre signes qu’il manque une couche d’orchestration.
Le premier est la double saisie qui persiste malgré les outils. Si une information passe par un assistant IA puis se retrouve recopiée dans le CRM par un humain, l’outil a produit du texte sans supprimer le travail.
Le deuxième est l’absence de source qui fait foi. Deux systèmes affichent un statut différent pour le même dossier et l’équipe a appris lequel croire, sans que la règle soit écrite nulle part. Cette connaissance disparaît avec la personne qui part.
Le troisième est l’échec silencieux. Un flux tombe, personne ne le voit, et le problème se découvre trois semaines plus tard sur une réclamation client. Une orchestration correcte rend l’échec visible dans une file que quelqu’un regarde.
Le quatrième est le cas ambigu traité au hasard. Deux clients portent le même nom, une pièce est illisible, un montant ne correspond pas. Sans règle d’arrêt, chaque outil choisit, et personne ne sait qu’un choix a été fait.
Ordonner
Les étapes s’enchaînent dans un ordre écrit, pas dans l’ordre des arrivées.
Arbitrer
Une source fait foi quand deux systèmes se contredisent, et c’est documenté.
Rendre visible
Un échec entre dans une file consultée, il ne disparaît pas dans un journal.
Arrêter
Les cas ambigus remontent à une personne au lieu d’être tranchés en silence.
Pourquoi « agence IA » et « orchestrateur » ne vendent pas la même chose.
Une bonne partie des prestataires positionnés sur l’IA vendent un livrable : un chatbot, un site, un agent conversationnel. Le travail se termine à la livraison, et la question de savoir comment cet objet cohabite avec l’ERP existant reste au client.
L’orchestration commence à l’endroit où ce livrable rencontre le reste. Elle est moins spectaculaire à montrer, parce qu’elle n’a pas d’interface : quand elle fonctionne, on ne la voit pas. Elle se démontre sur des traces, pas sur un écran. Combien de dossiers sont passés seuls, combien se sont arrêtés, et pour quel motif.
Ce positionnement a une conséquence commerciale que nous assumons. Nous refusons certaines demandes, notamment quand une entreprise veut un agent visible pour montrer qu’elle fait de l’IA. Un objet de démonstration se construit vite et ne survit pas au premier trimestre.
Ce qu’on écrit avant de connecter quoi que ce soit.
Le déclencheur : qu’est-ce qui fait démarrer le flux, et à quelle fréquence. Une boîte partagée, un dépôt de fichier, un statut qui change dans l’ERP. Un déclencheur mal choisi produit des exécutions inutiles qui coûtent en crédits et brouillent les journaux.
Les décisions : à chaque embranchement, qui tranche. Une règle déterministe quand c’est possible, un modèle quand le texte est libre, une personne quand la décision engage l’entreprise. Confier à un modèle ce qu’une règle fait mieux est l’erreur la plus coûteuse de ce métier, parce qu’elle rend non reproductible quelque chose qui l’était.
Les sorties et les arrêts : ce que le flux écrit, où, et dans quel cas il refuse d’écrire. Un flux sans condition d’arrêt finit toujours par produire une action que personne n’a voulue. Nous écrivons ces conditions avant la configuration, et elles font partie du livrable au même titre que le reste.
Le test tient en une question : que se passe-t-il quand c’est ambigu ?
Prenez le flux que vous envisagez d’automatiser et cherchez ses cas sales. Le client qui existe en double. La pièce jointe corrompue. Le montant qui ne tombe pas juste. Le dossier arrivé par un canal qui n’était pas prévu. Si personne dans l’entreprise ne sait dire ce qui devrait se passer dans ces cas-là, l’automatisation n’est pas prête, quel que soit l’outil.
Cette question sépare aussi les prestataires. Un fournisseur qui répond « le modèle gère » n’a pas conçu de règle d’arrêt. Un fournisseur qui répond en décrivant où le dossier atterrit et qui reçoit l’alerte a déjà fait le travail.
Apportez un flux réel au premier échange, avec ses exceptions. Nous vous dirons quelle partie relève d’une règle, quelle partie d’un modèle, et quelle partie gagne à rester manuelle. Cette dernière catégorie existe toujours.
Vous avez trois outils qui ne se parlent pas ?
Décrivez le trajet réel d’un dossier entre eux, exceptions comprises. Nous poserons la couche manquante avant de proposer un outil de plus.
Demander un diagnosticUn exemple réel vaut mieux qu’une liste d’outils.
Apportez un dossier, un e-mail ou un passage entre deux logiciels. Nous le transformons en périmètre testable, exceptions comprises.
Premier échange non facturé. Le devis précède toute connexion à vos systèmes.