Construire des agents IA industriels : la méthode RIGO et les frameworks agentiques

Un agent IA n’est pas un chatbot

Il faut commencer par là, parce que la confusion est partout.

Un chatbot répond à des questions. On lui pose une question, il génère du texte, on lit le texte, on passe à autre chose. C’est un outil de conversation.

Un agent IA, c’est autre chose. Un agent agit. Il lit des données, prend des décisions, exécute des actions, vérifie le résultat, et recommence si nécessaire. La différence n’est pas de degré — elle est de nature.

Chatbot vs Agent — l’exemple qualité

Le chatbot : on lui demande “c’est quoi le Cpk ?”, il renvoie la définition avec des formules. Utile pour un étudiant. Inutile sur une ligne de production.

L’agent SPC : il surveille en continu les cartes de contrôle Xbar-R, détecte une violation Western Electric, identifie que la dérive a commencé il y a 45 minutes au changement de lot matière, alerte le responsable qualité avec le numéro de lot et la valeur du décalage.

Tout cela sans intervention humaine. En temps réel. 24h/24.

Le chatbot sait ce qu'est le Cpk.

L'agent détecte que le Cpk est en train de passer sous 1.33 et prévient la bonne personne avant que les pièces ne sortent des tolérances.

Concevoir, pas configurer

Un chatbot se configure en 10 minutes : on choisit un modèle, on rédige un prompt, on connecte une interface.

Un agent se conçoit. Il faut définir :

ce qu’il sait faire
ce qu’il doit faire
ce qu’il ne doit surtout pas faire
ce qu’il doit produire

C’est un travail d’ingénierie, pas de configuration.

Cet article explique comment concevoir un agent IA fiable pour un contexte industriel. Pas un prototype de hackathon — un agent qui tourne en production, avec des données réelles et des systèmes existants.

La méthode RIGO — quatre briques pour un agent fiable

La méthode RIGO est un cadre de conception en quatre blocs :

Rôle — qui est l’agent
Instructions — que doit-il faire
Guardrails — qu’est-ce qu’il ne doit PAS faire
Output — quel format de sortie

L’ordre n’est pas arbitraire. Le rôle conditionne les instructions. Les instructions appellent des guardrails. Les guardrails encadrent l’output. Sauter une brique, c’est construire un agent bancal.

R — Rôle : qui est l’agent

Si cet agent était un collaborateur humain, quel serait son poste ?

Un rôle bien défini contient trois informations :

Expertise métier : “ingénieur qualité spécialisé en SPC pour l’injection plastique”
Périmètre d’action : “tu analyses les cartes de contrôle Xbar-R de l’atelier B”
Niveau d’autonomie : “tu alertes et tu proposes, mais tu ne modifies aucun paramètre”

Pourquoi c’est important ? Parce que le rôle conditionne tout le reste.

Un agent qui se sait “ingénieur qualité SPC” ne proposera pas d’actions de maintenance prédictive. Il restera dans son périmètre, utilisera le bon vocabulaire, appliquera les bons référentiels.

Un agent dont le rôle est “assistant” fera n’importe quoi — parce que tout est dans le périmètre d’un assistant.

Test simple : si on peut remplacer le rôle par "tu es un assistant" sans que rien ne change dans le comportement attendu, c'est que le rôle est mal défini.

I — Instructions : que doit-il faire

Les instructions sont la séquence d’étapes que l’agent doit suivre. C’est la gamme opératoire de l’agent, l’équivalent de la fiche de poste détaillée ou de la procédure qualité. Chaque étape doit être un verbe d’action, dans l’ordre d’exécution, et vérifiable.

Un mauvais exemple d’instruction : “Analyse les données”. Qu’est-ce que ça veut dire, analyser ? Le mot est trop large. L’agent peut faire n’importe quoi, et il le fera.

Un bon exemple d’instruction, séquencée :

Lire le fichier CSV de mesures (colonne : diametre_mm)
Grouper les mesures en sous-groupes de 5 par ordre chronologique
Calculer Xbar et R pour chaque sous-groupe
Calculer la moyenne des Xbar et la moyenne des R
Calculer UCL et LCL avec les constantes A2, D3, D4
Calculer Cp et Cpk avec les tolérances fournies
Appliquer les 8 règles Western Electric sur la carte Xbar
Produire le rapport au format défini dans la section Output

Chaque étape est un verbe d’action (“lire”, “grouper”, “calculer”, “appliquer”, “produire”). Chaque étape est vérifiable : on peut contrôler que le calcul de Xbar est correct, que les constantes utilisées sont les bonnes, que les règles Western Electric sont bien les 8 et pas 4. Il n’y a pas de place pour l’interprétation.

Le piège classique est l’instruction implicite. “Analyse les données et tire des conclusions” laisse l’agent décider ce que signifie “analyser” et ce que sont des “conclusions”. Dans un contexte industriel, c’est inacceptable. On ne laisse pas un opérateur décider tout seul ce que veut dire une instruction de travail. Un agent IA, c’est pareil.

Un autre piège est l’absence de conditions. Les instructions doivent prévoir les cas de branchement : “SI le Cpk est inférieur à 1.33, ALORS recommander un plan d’action. SI le nombre de sous-groupes est inférieur à 25, ALORS signaler que l’analyse n’est pas statistiquement fiable.” Sans ces conditions, l’agent suit un chemin unique et se retrouve démuni face aux cas limites — qui sont, en production, la majorité des cas.

G — Guardrails : ce qu’il ne doit PAS faire

Si les instructions définissent le chemin, les guardrails définissent les murs. Ce sont les limites dures, les actions interdites, les comportements proscrits. Dans le vocabulaire Lean, les guardrails sont les poka-yoke de l’agent : des dispositifs anti-erreur qui empêchent les défauts avant qu’ils ne se produisent.

Les guardrails couvrent quatre catégories.

Intégrité des données. “NE PAS modifier les fichiers sources.” “NE PAS interpoler les valeurs manquantes sans le signaler.” “NE PAS fusionner des jeux de données de sources différentes sans vérification de cohérence.” En production, un agent qui modifie silencieusement un fichier de mesures, c’est un risque qualité majeur. C’est l’équivalent d’un opérateur qui recalibre son pied à coulisse en cachette.

Périmètre d’action. “NE PAS proposer de recommandations en dehors du domaine qualité.” “NE PAS accéder à des systèmes non listés dans les instructions.” “NE PAS contacter des personnes en dehors de la liste d’alerte définie.” Un agent qui sort de son périmètre, c’est un collaborateur qui prend des initiatives sans mandat. Dans le meilleur des cas, c’est inutile. Dans le pire, c’est dangereux.

Véracité. “NE PAS inventer de données. Si l’information n’est pas disponible, le dire explicitement.” “NE PAS affirmer un diagnostic sans données à l’appui.” C’est le guardrail le plus critique. Les modèles de langage ont une tendance structurelle à produire des réponses plausibles même quand ils n’ont pas d’information fiable. En recherche, on appelle ça l’hallucination. En industrie, on appelle ça une non-conformité. Un agent qui invente un résultat de mesure ou une cause racine fictive peut déclencher des actions correctives inappropriées, immobiliser une ligne de production pour rien, ou pire, laisser passer un vrai problème.

Actions critiques. “NE PAS envoyer de communication externe sans validation humaine.” “NE PAS recommander un arrêt de production sans cause spéciale identifiée et documentée.” “NE PAS modifier des paramètres process.” Certaines actions sont irréversibles ou ont des conséquences importantes. L’agent doit proposer, pas décider. C’est le principe du human-in-the-loop appliqué aux points de décision critiques.

L’erreur la plus courante est l’absence de guardrails. Un agent sans guardrails, c’est un processus sans contrôle. Il fonctionne bien dans les conditions nominales du développement. En production, face à des données bruitées, des cas limites, des interruptions réseau, il dérive. Et comme il n’a pas de limites définies, il dérive silencieusement. On ne s’en aperçoit que lorsque le client appelle.

O — Output : quel format de sortie

Le dernier bloc est le format de sortie. C’est la spécification de ce que l’agent doit produire. Pas une suggestion. Une spécification.

L’output répond à quatre questions. Quel format ? Quels champs obligatoires ? Quelle longueur ? Quelle structure ?

Le format peut être un JSON structuré (pour les agents qui alimentent un système aval), un rapport Markdown (pour les agents qui produisent des documents), un tableau (pour les agents d’analyse), un email brouillon (pour les agents de communication). Le choix du format dépend du consommateur de l’output : un système informatique a besoin de JSON, un responsable qualité a besoin d’un rapport lisible, un tableau de bord a besoin de données structurées.

Les champs obligatoires sont la liste des éléments que l’output doit contenir, quelles que soient les circonstances. Pour un agent SPC : le Cpk calculé, la liste des violations de règles, le verdict (capable / juste capable / non capable), les actions recommandées. Si un champ est absent, l’output est incomplet et le système aval ne peut pas l’exploiter.

La longueur est une contrainte souvent négligée. Un modèle de langage sans contrainte de longueur va produire du texte aussi longtemps qu’il peut. En contexte industriel, personne ne lit un rapport de 10 pages généré par une IA. “Maximum 500 mots” ou “tableau de 5 lignes maximum” force l’agent à être concis et à prioriser l’information pertinente.

L’erreur classique : ne pas définir d’output. L’agent produit alors du texte libre — un paragraphe de prose qui mélange les données, l’analyse et les recommandations dans un flux non structuré. Inutilisable par un système aval. Difficilement lisible par un humain pressé. Et impossible à comparer d’une exécution à l’autre, ce qui rend le suivi de performance de l’agent lui-même impossible.

Exemple complet RIGO

Voici un agent qualité SPC complet, spécifié avec la méthode RIGO.

ROLE. Ingénieur qualité SPC, spécialisé usinage de précision. Périmètre : lignes d’usinage de l’atelier A. Autonomie : analyse et alerte, pas de modification process.

INSTRUCTIONS.

Lire le fichier CSV de mesures (colonne : diametre_mm)
Grouper en sous-groupes de 5 par ordre chronologique
Calculer Xbar et R par sous-groupe
Calculer UCL, LCL avec constantes A2, D3, D4
Calculer Cp et Cpk avec les tolérances spécifiées
Appliquer les 8 règles Western Electric sur la carte Xbar
SI Cpk < 1.33, recommander un plan d’action
SI données insuffisantes (< 25 sous-groupes), le signaler
Produire le rapport au format Output

GUARDRAILS.

NE PAS modifier le fichier source
NE PAS conclure “processus capable” si Cpk < 1.33
NE PAS recommander d’arrêt de production sans cause spéciale identifiée
NE PAS inventer de données — signaler les valeurs manquantes
NE PAS sortir du périmètre qualité (pas de recommandation RH, finance, maintenance)

OUTPUT. JSON structuré avec les champs : cpk (float), cp (float), violations (liste d’objets avec règle, sous-groupe, description), verdict (“capable” / “juste_capable” / “non_capable”), actions_recommandees (liste de chaînes). Maximum 10 actions recommandées.

Cet agent est entièrement spécifié. Deux ingénieurs différents qui l’implémentent sur deux frameworks différents obtiendront un comportement comparable. C’est le but de la méthode RIGO : rendre la conception d’agents reproductible et auditable.

Les frameworks agentiques — comparatif honnête

La méthode RIGO définit le quoi. Les frameworks agentiques fournissent le comment. Ce sont les briques logicielles qui permettent d’implémenter, de connecter et d’orchestrer des agents. Le marché en 2026 est dense et mouvant. Voici un tour d’horizon des principales options, avec leurs forces et leurs limites réelles.

LangGraph (LangChain)

LangGraph modélise un agent comme un graphe d’états. Chaque noeud est une étape de traitement (appel au LLM, lecture de données, calcul). Chaque arête est une condition de transition (si le Cpk est inférieur au seuil, aller au noeud “plan d’action” ; sinon, aller au noeud “rapport standard”). Le graphe peut contenir des boucles, ce qui permet les itérations : l’agent qui vérifie son propre résultat et recommence si la qualité est insuffisante.

Forces. Le contrôle est total. On voit le chemin que l’agent va suivre avant de l’exécuter. L’état est persistant entre les noeuds, ce qui permet de gérer des workflows complexes avec des branchements multiples. Pour un pipeline qualité avec des conditions métier précises (capabilité vs conformité vs dérive), c’est un avantage significatif.

Limites. La courbe d’apprentissage est raide. La dépendance à l’écosystème LangChain est forte — quand LangChain change d’API, les graphes existants cassent. La documentation est abondante mais parfois en décalage avec les versions. Pour une ETI sans équipe de développement interne, c’est un frein.

Quand l’utiliser. Orchestration complexe avec des branchements conditionnels, des boucles de vérification, et un besoin de traçabilité étape par étape.

CrewAI

CrewAI organise les agents en équipe. Chaque agent a un rôle défini (analyste, rédacteur, vérificateur), et ils collaborent pour accomplir une tâche. La métaphore est intuitive : un manager distribue le travail, un researcher collecte les informations, un writer produit le livrable.

Forces. La prise en main est rapide. La décomposition en rôles correspond bien à la logique industrielle (un service qualité a un responsable, des techniciens, un référent méthodes). Pour des tâches décomposables en étapes séquentielles (collecter → analyser → rédiger → valider), la structure est naturelle.

Limites. Le contrôle est moins fin que LangGraph — on définit les rôles et les objectifs, mais le framework gère la coordination. L’overhead de communication entre agents consomme des tokens. Sur des tâches simples, un seul agent bien configuré fait le travail plus vite et moins cher que trois agents qui se coordonnent.

Quand l’utiliser. Tâches décomposables en rôles distincts, quand la métaphore d’équipe correspond au flux de travail réel.

AutoGen (Microsoft)

AutoGen structure la collaboration entre agents sous forme de conversation. Les agents échangent des messages, se posent des questions, se corrigent mutuellement. Le résultat est une trace de conversation lisible par un humain, ce qui facilite le debugging.

Forces. La transparence est maximale — on lit la conversation entre agents et on comprend comment la décision a été prise. La flexibilité est grande : on peut ajouter un agent vérificateur qui challenge les conclusions d’un agent analyste, reproduisant le processus de revue par les pairs.

Limites. Les agents sont bavards. Une conversation entre trois agents pour une tâche qui aurait pris 500 tokens en mode direct peut en consommer 5 000 en mode conversationnel. Le risque de boucle infinie est réel : deux agents qui ne sont pas d’accord peuvent débattre indéfiniment sans converger. Il faut systématiquement limiter le nombre d’échanges.

Quand l’utiliser. Validation croisée, revue de documents, tâches où le raisonnement doit être auditable et où le coût en tokens est acceptable.

MCP — Model Context Protocol (Anthropic)

MCP n’est pas un framework d’agents. C’est un protocole. La distinction est importante. MCP définit un standard pour connecter un modèle de langage à des outils externes : bases de données, APIs métier, systèmes de fichiers, capteurs, ERP, MES, GMAO. C’est la couche d’infrastructure qui permet à un agent d’accéder aux vrais systèmes de l’entreprise.

Forces. C’est un standard ouvert, utilisable avec n’importe quel framework. L’intégration est plug-and-play : un serveur MCP pour Qdrant (base vectorielle), un pour PostgreSQL (base relationnelle), un pour l’API qualité interne, et l’agent accède à trois systèmes via une interface unifiée. Pas besoin de coder des connecteurs ad hoc.

Limites. MCP ne gère pas l’orchestration. Il fournit les outils, pas la logique de décision. Un agent MCP sans framework d’orchestration est un ouvrier avec une boîte à outils complète mais sans gamme opératoire.

Quand l’utiliser. Systématiquement, comme couche d’accès aux données, en combinaison avec un framework d’orchestration. C’est la brique qui connecte l’agent au système d’information de l’entreprise.

Claude Code / Agent SDK (Anthropic)

Claude Code et le Claude Agent SDK représentent une approche différente. L’agent n’est pas orchestré par un framework externe : il est autonome. Il lit des fichiers, exécute du code, navigue le web, appelle des APIs, et peut même lancer des sous-agents pour paralléliser le travail. Le modèle de récursivité est puissant : un agent qui analyse un problème complexe peut créer trois sous-agents spécialisés, attendre leurs résultats, les synthétiser, et produire un livrable consolidé.

Forces. L’autonomie est maximale. L’accès au système est complet. La récursivité permet de gérer des tâches de complexité arbitraire. Pour de l’automatisation bout-en-bout — de l’acquisition de données brutes au livrable final — c’est l’outil le plus puissant disponible.

Limites. L’autonomie a un coût : il faut des guardrails solides (ce que la méthode RIGO couvre). Sans garde-fous, un agent autonome peut prendre des décisions lourdes de conséquences. La consommation en tokens est significative sur les tâches complexes.

Quand l’utiliser. Automatisation complète de workflows multi-étapes, quand l’agent doit réellement agir sur le système (pas juste analyser et recommander).

Tableau comparatif

Framework	Type	Complexité de mise en oeuvre	Contrôle du flux	Coût en tokens	Cas d’usage type
LangGraph	Graphe d’états	Élevée	Maximal	Modéré	Pipeline qualité conditionnel
CrewAI	Équipe d’agents	Faible	Moyen	Élevé (coordination)	Collecte → Analyse → Rapport
AutoGen	Conversation	Moyenne	Faible	Élevé (dialogues)	Revue de documents, validation croisée
MCP	Protocole d’outils	Faible	N/A (pas d’orchestration)	Minimal	Accès ERP, MES, GMAO, bases
Claude Code / Agent SDK	Agent autonome	Moyenne	Élevé (via RIGO)	Variable	Automatisation bout-en-bout

Le choix du framework n’est pas une décision technique isolée. Il dépend de trois facteurs : la complexité du flux de travail (LangGraph pour les branchements complexes, CrewAI pour les séquences simples), les compétences disponibles en interne (LangGraph exige du développement, CrewAI est plus accessible), et le niveau de contrôle requis (secteur réglementé = LangGraph ou Agent SDK avec guardrails).

L’erreur serait de choisir le framework avant d’avoir spécifié l’agent. La méthode RIGO d’abord. Le framework ensuite. L’inverse produit des agents conçus autour des contraintes du framework plutôt qu’autour du besoin métier.

Lean et agents IA : le parallèle qui change la perspective

Les praticiens du Lean manufacturing vont reconnaître des concepts familiers dans la conception d’agents IA. Ce n’est pas une coïncidence. Les deux disciplines partagent les mêmes problèmes fondamentaux : comment organiser un flux de travail, comment limiter les en-cours, comment détecter les anomalies au plus tôt, comment éliminer les gaspillages. Les solutions convergent.

1 Piece Flow : traiter à l’unité, pas en lot

En Lean, le 1 Piece Flow est le principe de faire traverser une pièce unique à travers tous les postes de travail, sans constituer de stock intermédiaire. Chaque poste traite la pièce, la passe au suivant, et attend la suivante. Le résultat : un lead time minimal, une détection immédiate des anomalies (si le poste 3 produit un défaut, le poste 4 le voit sur la pièce suivante), et une flexibilité maximale (on peut changer le mix produit sans vider un stock de lots en cours).

L’équivalent en architecture agentique, c’est le traitement événementiel. Chaque donnée — une mesure SPC, un ordre de fabrication, une alerte capteur — traverse la chaîne d’agents à l’unité. L’agent de collecte reçoit la mesure, la transmet à l’agent d’analyse, qui la transmet à l’agent d’alerte si une anomalie est détectée. Il n’y a pas de batch de fin de journée. Il n’y a pas de “on agrège et on analyse demain matin”. L’information circule en temps réel, et l’anomalie est détectée dans les minutes qui suivent son apparition.

La différence est massive sur le terrain. Une dérive SPC détectée en batch à J+1, c’est potentiellement 8 heures de production non conforme, un lot entier à trier, des retouches ou des rebuts. La même dérive détectée en 1 Piece Flow par un agent temps réel, c’est 20 minutes de production affectée et une intervention corrective immédiate.

Le 1 Piece Flow en agents IA a aussi les mêmes exigences que le 1 Piece Flow en production : chaque poste (chaque agent) doit être fiable. Si un agent plante, toute la chaîne s’arrête. La robustesse de chaque maillon est critique. D’où l’importance de la méthode RIGO pour spécifier chaque agent avec rigueur.

Flux tiré (Pull) : ne produire que ce qui est demandé

Le flux tiré est l’un des piliers du Toyota Production System. On ne produit pas pour remplir un stock — on ne produit que ce que le poste aval demande. Le kanban est le signal : quand le poste aval consomme une pièce, il envoie un signal au poste amont pour en produire une nouvelle. Pas de signal, pas de production.

En architecture agentique, le RAG (Retrieval-Augmented Generation) est un flux tiré. L’agent ne pré-charge pas toute la base documentaire en mémoire. Il ne pré-calcule pas toutes les analyses possibles. Quand une question arrive, il cherche dans la base vectorielle les documents pertinents, les récupère, et les utilise pour produire sa réponse. L’information est tirée par la demande, pas poussée par anticipation.

Le bénéfice est le même qu’en production. Le flux poussé (push) génère du stock inutile — des calculs pré-faits que personne ne consulte, des rapports générés automatiquement que personne ne lit, de la consommation de tokens sans valeur ajoutée. Le flux tiré élimine ce gaspillage. L’agent ne consomme des ressources (tokens, temps de calcul, appels API) que quand il y a une demande réelle.

C’est aussi valable pour le déclenchement des agents eux-mêmes. Un agent en boucle continue qui interroge une base de données toutes les 30 secondes “au cas où” est un flux poussé. Un agent déclenché par un événement (une nouvelle mesure hors tolérance, un changement de lot, une alerte capteur) est un flux tiré. Le second consomme moins de ressources et produit des résultats plus pertinents — exactement comme en production.

WIP Limits : le sémaphore comme encours maximum

En Lean et en Kanban, le WIP limit (Work In Progress limit) est le nombre maximum de tâches en cours simultanément à un poste ou dans un flux. Le principe est contre-intuitif : limiter le travail en cours augmente le débit. En saturant un poste, on crée des files d’attente, des temps d’attente, et des contextes de travail multiples qui réduisent l’efficacité. En limitant l’encours, on force la fin de chaque tâche avant d’en commencer une nouvelle.

En architecture agentique, le WIP limit s’appelle un sémaphore. C’est un compteur qui limite le nombre d’agents qui peuvent s’exécuter simultanément. Si le sémaphore est à 6, le septième agent attend qu’un des six premiers ait terminé avant de démarrer.

Pourquoi est-ce nécessaire ? Parce que les ressources sont finies. Chaque agent consomme des tokens (coût financier), de la bande passante API (risque de rate limiting), et de la capacité de calcul. Sans sémaphore, un système qui déclenche 50 agents simultanément va saturer les APIs, exploser les coûts, et produire des résultats dégradés à cause des timeouts et des retries.

Le parallèle va plus loin. En Lean, quand un poste atteint son WIP limit, il envoie un signal d’arrêt au poste amont. C’est l’andon. En agentique, quand le sémaphore est saturé, les nouvelles tâches sont mises en file d’attente avec une priorité. Les tâches critiques (alerte sécurité, dérive qualité majeure) peuvent court-circuiter la file. C’est exactement la logique de gestion de production appliquée au scheduling d’agents.

Kanban board et gestion des états

Le tableau Kanban classique a quatre colonnes : A Faire, En Cours, En Revue, Terminé. Chaque carte (tâche) se déplace de gauche à droite au fil de son avancement.

La gestion d’état d’un système multi-agents reproduit cette structure. Chaque tâche confiée à un agent passe par des états séquentiels : créée (backlog), assignée à un agent (en cours), résultat produit (en revue), validée (terminée). La visibilité sur l’ensemble du tableau — combien de tâches en cours, combien en attente, combien terminées — donne le même pouvoir de pilotage qu’un tableau Kanban physique dans un atelier.

Et comme en production, c’est la colonne “En Revue” qui révèle les goulots d’étranglement. Si les résultats des agents s’accumulent en attente de validation humaine, le flux est bloqué. La solution est la même qu’en Lean : soit on augmente la capacité de revue (plus de validateurs), soit on automatise la revue (un agent vérificateur), soit on réduit le besoin de revue (des guardrails assez fiables pour que seuls les cas litigieux nécessitent une validation humaine).

Value Stream Mapping : identifier les gaspillages dans un pipeline d’agents

La VSM (Value Stream Mapping) est l’outil Lean qui cartographie un flux de valeur de bout en bout pour identifier les muda — les gaspillages. On mesure le temps de traitement à chaque étape, le temps d’attente entre les étapes, et on calcule le ratio valeur ajoutée / temps total.

Appliquée à un pipeline d’agents, la VSM révèle les mêmes types de gaspillages.

Temps d’attente entre agents. Un agent qui attend la réponse d’un autre agent qui attend l’accès à une API qui attend une connexion réseau. Chaque point d’attente est un muda. La solution : paralléliser les agents indépendants, mettre en cache les résultats intermédiaires, utiliser des timeouts agressifs avec des fallbacks.

Sur-traitement. Utiliser un modèle de langage haut de gamme (Opus, GPT-4o) pour une tâche de classification simple qui fonctionnerait aussi bien avec un modèle léger (Haiku, GPT-4o-mini). C’est l’équivalent de passer une pièce sur un centre d’usinage 5 axes pour un simple perçage. Le routing de modèles — diriger chaque tâche vers le modèle le moins coûteux capable de la traiter — est l’équivalent exact de l’allocation optimale des machines.

Transport inutile. Des données qui transitent d’un agent à l’autre sans être transformées. Un agent de collecte qui transmet un fichier brut à un agent de pré-traitement qui le transmet sans modification à un agent d’analyse. Chaque transfert inutile consomme du temps et des tokens.

Surproduction. Des agents qui génèrent des rapports, des analyses, des alertes que personne ne consomme. Un agent SPC qui produit un rapport complet toutes les heures alors que le responsable qualité ne le consulte qu’une fois par jour. La fréquence de production doit être alignée sur la fréquence de consommation — c’est le takt time appliqué à la génération d’information.

Anti-patterns — les erreurs qui coûtent cher

L’expérience de déploiement d’agents IA en contexte industriel fait émerger des anti-patterns récurrents. Ce sont des erreurs de conception qui ne se manifestent pas pendant le développement mais qui explosent en production.

Agent sans guardrails. C’est l’anti-pattern numéro un. Un agent de rédaction de rapports qui invente des références de normes. Un agent d’analyse qui produit des résultats quand les données d’entrée sont corrompues. Un agent qui envoie une alerte au directeur de production à 3 heures du matin pour une variation de 0.001 mm sur une tolérance de 0.1 mm. Sans guardrails, le modèle de langage fait ce qu’il sait faire : il produit une réponse plausible. En contexte industriel, “plausible mais faux” est pire qu’une absence de réponse.

Agent trop autonome. Un agent qui peut modifier des paramètres process sans validation humaine. Un agent qui peut envoyer des communications externes (fournisseurs, clients) sans relecture. Un agent qui peut déclencher des achats ou des commandes. L’autonomie est un curseur, pas un interrupteur. Les actions réversibles (générer un brouillon, proposer une action) peuvent être autonomes. Les actions irréversibles (envoyer un email, modifier un paramètre, arrêter une ligne) exigent une validation humaine.

Le monolithe. Un seul agent qui fait tout : collecte, analyse, rédaction, alerte, suivi. Il a un prompt de 3 000 mots, il accède à 15 systèmes différents, et il gère 40 cas de figure dans un seul flux. En production, il est impossible à maintenir, impossible à debugger, et impossible à faire évoluer. Un changement dans la logique d’alerte casse la logique d’analyse. La solution est la décomposition : plusieurs agents spécialisés, chacun avec son RIGO, coordonnés par un orchestrateur simple.

Absence de logging. Un agent qui tourne en production sans tracer ses décisions, ses entrées, ses sorties, ses erreurs. Quand un résultat aberrant arrive (et il arrivera), impossible de comprendre ce qui s’est passé. Le logging n’est pas optionnel en contexte industriel. Chaque exécution d’un agent doit produire une trace : les données d’entrée, le chemin de décision suivi, le résultat produit, les erreurs éventuelles. C’est l’équivalent du dossier de lot en pharmaceutique ou de la carte de contrôle en mécanique.

Pas de human-in-the-loop. Certaines décisions ne doivent pas être prises par un agent seul, quelle que soit sa fiabilité. Un changement de fournisseur. Un arrêt de production. Une communication client. Le human-in-the-loop n’est pas un aveu de faiblesse du système — c’est un dispositif de sécurité. L’agent prépare, l’humain décide. L’agent est l’analyste, pas le décideur.

Modèle surdimensionné. Utiliser un modèle frontier à 15 euros les mille tokens pour une tâche de classification binaire (conforme / non conforme) qui fonctionne aussi bien avec un modèle à 0.25 euro les mille tokens. Le routing de modèles — diriger chaque tâche vers le modèle le moins cher capable de la traiter — est un levier d’optimisation de coût qui peut diviser la facture par 10 sans aucune perte de qualité.

Comment démarrer en ETI — le POC en quatre semaines

Les ETI industrielles ont une contrainte que les startups n’ont pas : le temps. Il n’y a pas de budget pour six mois d’exploration. Il faut un résultat tangible rapidement, ou le projet est abandonné. Le format POC en quatre semaines est calibré pour cette réalité.

Semaine 1 : identifier le cas d’usage. Pas le cas le plus spectaculaire. Le cas à plus fort ROI. En pratique, dans les ETI industrielles françaises, trois cas d’usage reviennent systématiquement en tête. La documentation technique (génération de rapports, résumé de procédures, extraction d’informations de plans) — gain typique de 60 à 80 % du temps de rédaction. Le contrôle qualité (analyse SPC automatisée, classification de non-conformités, aide au remplissage des QRQC) — gain de 30 à 50 % du temps d’analyse. La maintenance (interrogation en langage naturel des historiques GMAO, aide au diagnostic de panne) — gain variable mais fort impact sur les temps d’arrêt.

Le critère de sélection n’est pas la faisabilité technique. Tout est techniquement faisable en 2026. Le critère est l’adoption. Le cas choisi doit avoir un utilisateur identifié, un volume suffisant pour que le gain soit visible, et un processus actuel suffisamment douloureux pour que l’utilisateur ait envie de changer.

Semaine 2 : construire l’agent RIGO. Appliquer la méthode sur le cas choisi. Définir le rôle (quel poste l’agent occupe), les instructions (quelle séquence il suit), les guardrails (quelles limites il respecte), l’output (quel livrable il produit). Connecter l’agent aux données métier via RAG : ingérer les procédures, les normes internes, les templates de rapports dans une base vectorielle. Tester sur des données réelles, pas sur des données de démonstration.

Semaine 3 : tester avec les vrais utilisateurs. C’est la semaine la plus importante. Mettre l’agent entre les mains de l’opérateur, du technicien qualité, du responsable maintenance qui va l’utiliser au quotidien. Observer les cas où l’agent échoue. Ajuster les guardrails — c’est toujours les guardrails qui manquent au premier tour. L’utilisateur va trouver les cas limites que le concepteur n’avait pas prévus. C’est normal et c’est le but. Chaque cas limite devient un guardrail supplémentaire.

Semaine 4 : mesurer et décider. Quantifier le gain : temps économisé par jour, nombre d’erreurs évitées, taux d’adoption par les utilisateurs. Comparer au coût : abonnement API, temps de maintenance du système, coût d’intégration. Le go/no-go n’est pas une question technique. C’est un calcul de ROI. Si l’agent fait économiser 2 heures par jour à un technicien qualité et coûte 200 euros par mois en tokens, le ROI est évident. Si l’agent fait économiser 10 minutes par semaine et nécessite un développeur à mi-temps pour le maintenir, le calcul est différent.

Le POC en quatre semaines n’est pas une fin en soi. C’est un levier de décision. Il répond à la seule question qui compte : est-ce que ça vaut le coup de continuer ? Si oui, la phase suivante est l’industrialisation — un sujet suffisamment vaste pour mériter son propre article.

Synthèse

Un agent IA industriel n’est pas un chatbot amélioré. C’est un opérateur virtuel qui agit dans un système de production. Sa conception exige la même rigueur que la conception d’un poste de travail : un rôle précis, des instructions séquencées, des garde-fous explicites, un format de sortie défini.

La méthode RIGO fournit ce cadre. Les frameworks agentiques — LangGraph, CrewAI, AutoGen, MCP, Claude Code — fournissent les briques d’implémentation. Le parallèle avec le Lean manufacturing n’est pas une analogie forcée : les mêmes principes de 1 Piece Flow, de flux tiré, de WIP limit et de VSM s’appliquent directement à la conception et au pilotage de systèmes multi-agents.

Le point de départ n’est pas le framework. C’est le besoin métier. Quel processus améliorer, quel gaspillage éliminer, quel gain mesurer. RIGO d’abord, framework ensuite.

Pour aller plus loin

Optimiser un LLM pour l’industrie : prompt engineering, RAG, fine-tuning — Les techniques d’optimisation qui s’appliquent au coeur de chaque agent
Machine Learning ou statistiques classiques : l’arbre de choix — Quand l’agent doit décider quel modèle utiliser
Combien coûte vraiment l’IA en industrie — Le calcul de coût par agent, par token, par mois
Cartes de contrôle SPC : détecter la dérive avant le client — Le cas d’usage SPC détaillé, avec formules et exemples

Méthode RIGO — les 4 briques pour concevoir un agent IA fiable.