Guide · Méthode et architecture

Un schéma d’orchestration IA se teste sur les exceptions.

À 16 h 20, le modèle a résumé l’e-mail, le CRM contient déjà un autre nom et la pièce jointe ne s’ouvre pas. Le schéma d’orchestration IA doit dire qui vérifie, où le dossier s’arrête et ce qui repart ensuite.

Tester un schéma sur un flux réel
Schéma abstrait d’un flux documentaire reliant une entrée, une orchestration et une décision
Illustration éditoriale : une orchestration lisible relie les outils et garde un point d’arrêt.

Ce que ce guide établit

  • 01

    Dessiner avant de choisir

    Un schéma décrit l’entrée, les sources, les décisions, les actions et les reprises avant la configuration.

  • 02

    Écrire les arrêts

    Doublon, pièce illisible, donnée manquante ou confiance insuffisante doivent conduire à une file connue.

  • 03

    Mesurer le même échantillon

    Le pilote compare une série de dossiers avant et après, avec des définitions stables et des limites explicites.

Un schéma d’orchestration relie les rôles et les outils.

Un outil exécute une tâche : lire un PDF, appeler une API, classer un e-mail ou écrire une fiche. L’orchestration décrit le chemin entre ces tâches. Elle précise la source qui fait foi, la règle qui choisit la prochaine étape, l’action autorisée et le moment où une personne reprend le dossier.

Le dessin utile tient sur une page. Chaque bloc porte un verbe et une donnée d’entrée. Une flèche doit répondre à une question : quelle condition permet de continuer ? Si la flèche ne peut pas être expliquée à la personne qui exploitera le flux, elle cache probablement une décision non documentée.

Cette approche évite de confondre une démonstration de modèle et un processus exploitable. La réponse générée peut être correcte sur un cas propre ; le schéma doit aussi montrer le doublon, l’absence de pièce, l’accès expiré et l’action de reprise.

Les six blocs à dessiner avant la configuration.

Commencez par le document ou l’événement qui déclenche le flux. Ajoutez ensuite la donnée de contexte qui permet de reconnaître le dossier, puis les décisions et les actions dans l’ordre où elles se produisent réellement. La validation n’est pas une note en bas de page : c’est un bloc avec un responsable et une sortie attendue.

6 panneaux côte à côte : 1. Entrée, 2. Identité, 3. Contexte, 4. Décision, 5. Action, 6. Contrôle. Sujet : les six blocs à dessiner avant la configuration.
Six blocs à poser sur une feuille avant d’ouvrir le moindre outil de configuration.
  • 1. Entrée

    E-mail, formulaire, fichier ou statut qui démarre le traitement. Le format accepté et la fréquence sont écrits.

  • 2. Identité

    Client, dossier ou commande rapprochés avec une clé stable. En cas de doublon, le flux s’arrête.

  • 3. Contexte

    Pièces, historique et source de vérité nécessaires pour interpréter le texte sans inventer une donnée.

  • 4. Décision

    Règle déterministe en priorité, modèle pour le texte libre, personne lorsque l’action engage l’entreprise.

  • 5. Action

    Brouillon, mise à jour, notification ou création d’une tâche. Le système cible et le champ écrit sont nommés.

  • 6. Contrôle

    Trace, validation et file d’exception. Quelqu’un sait où retrouver le dossier et comment le reprendre.

Exemple : une demande de devis BTP en morceaux.

Un client appelle pendant un chantier, envoie deux photos et ajoute l’adresse dans un second message. Le flux commence par la boîte partagée. Il rapproche le numéro de téléphone et le nom, conserve chaque pièce originale, puis prépare une fiche avec le lieu, la nature des travaux, les contraintes et les informations manquantes.

La règle ne laisse pas l’agent IA calculer un prix. Elle lui demande de distinguer les éléments confirmés de ceux qui viennent d’une interprétation de photo, puis de préparer une relance si l’accès ou les dimensions manquent. Le responsable reçoit une tâche dans le logiciel déjà utilisé, avec les liens vers les messages et les pièces.

Ce flux reprend la logique du guide sur la demande de devis chantier : une automatisation utile remet les morceaux ensemble, elle ne transforme pas une image en métré. Le schéma permet de vérifier que le dossier reste accessible si le client répond dans un autre fil ou si la connexion au CRM échoue.

Écrire les conditions d’arrêt avant les branches heureuses.

Un bon schéma montre ce qui ne continue pas. La condition d’arrêt protège le dossier et donne un endroit où agir. Elle doit préciser le motif, la personne avertie, le délai de reprise et la trace conservée. Une phrase comme « le modèle gère les cas difficiles » ne décrit aucune reprise.

4 panneaux côte à côte : Dossier en double, Pièce absente ou illisible, Donnée contradictoire, Service indisponible. Sujet : écrire les conditions d’arrêt avant les branches heureuses.
Les quatre conditions d’arrêt qui reviennent partout. Elles se dessinent avant le chemin nominal.
  • Dossier en double

    Conserver les deux sources, suspendre l’écriture et demander à une personne de confirmer l’identité.

  • Pièce absente ou illisible

    Marquer le champ manquant, préparer une question et laisser le fichier original inchangé.

  • Donnée contradictoire

    Afficher la source et la date de chaque valeur ; ne pas choisir silencieusement la plus récente.

  • Service indisponible

    Mettre le dossier en attente, journaliser l’erreur et définir une reprise sans recréer l’entrée.

Mesurer un pilote avec la même règle avant et après.

Choisissez un échantillon représentatif de dix à trente dossiers et conservez la période, le type de demande et les critères d’inclusion. Pour chaque dossier, notez le temps actif, le délai total, le nombre d’exceptions, les champs manquants et le nombre de reprises humaines. Un échantillon plus petit peut servir à prototyper, mais il ne permet pas de généraliser un résultat.

La méthode est reproductible : (1) mesurer les dossiers avant le pilote ; (2) faire tourner le même périmètre avec le schéma ; (3) compter séparément les dossiers traités sans intervention et ceux qui s’arrêtent ; (4) relire les sorties contre la source ; (5) comparer les médianes et la liste des exceptions. La médiane évite qu’un dossier exceptionnel masque le reste, mais elle ne remplace pas le détail des cas.

Documentez aussi ce qui n’a pas été mesuré : saison, volume faible, accès de test, données anonymisées ou intervention d’une personne déjà familière du flux. Aucune baisse de temps, de clics ou d’erreurs ne doit être annoncée avant cette comparaison.

Ce que le schéma ne garantit pas.

Un dessin ne rend pas une donnée exacte et ne valide pas un engagement commercial, réglementaire ou contractuel. Il rend les responsabilités visibles. Les règles de confidentialité, les droits d’accès, la conservation des traces et le choix du fournisseur de modèle doivent être examinés avec les personnes responsables du traitement.

La CNIL rappelle qu’une solution d’IA se choisit selon le besoin, les données, le fournisseur et les mesures de sécurité. France Num recommande de partir d’un processus maîtrisé et d’accompagner les équipes. Ces repères ne remplacent pas l’analyse de votre flux : ils donnent les questions à poser avant le pilote.

Si une étape reste trop ambiguë pour être décrite, elle n’est pas prête à être automatisée. Le bon résultat peut être une simplification, une règle déterministe ou un point de décision mieux placé. Le schéma sert aussi à décider de ne pas connecter un outil.

Questions fréquentes.

Les points à trancher avant de lancer un pilote.

Un schéma d’orchestration remplace-t-il un outil métier ?

Non. Il décrit comment les outils existants échangent une donnée, appliquent une règle et demandent une validation. Le CRM, l’ERP ou la messagerie restent les espaces de travail légitimes.

Où placer les points de décision ?

Placez-la avant toute action engageante, sur les cas ambigus et lorsque la donnée manque ou se contredit. Le bloc doit nommer la personne ou la file qui reçoit le dossier et la trace attendue.

Combien de dossiers faut-il pour tester un schéma ?

Il n’existe pas de nombre universel. Un premier test Flux45 commence avec dix dossiers réels et anonymisés, puis s’élargit si les cas sont variés. La même période et les mêmes critères doivent servir avant et après le pilote.

Un 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.

Demander un diagnostic