Le graph engineering rend-il vos agents IA fiables en prod?

Le graph engineering rend vos agents IA plus fiables parce qu’il sort la logique critique du flou des prompts. On garde le LLM là où il est utile, et on encadre le reste avec état typé, routes, validations, checkpoints et intervention humaine.

C’est quoi le graph engineering ?

Le graph engineering, c’est une façon plus saine de construire une application IA. Au lieu de donner un objectif vague à un agent et d’espérer qu’il prenne les bonnes décisions tout seul, je représente l’application comme un graphe exécutable.

Un graphe, ici, c’est simplement une suite de blocs reliés entre eux. Chaque bloc a un rôle clair. Un bloc cherche une information. Un autre décide. Un autre vérifie. Un autre reformule. Un autre appelle un outil. Et entre ces blocs, je définis les chemins possibles.

La vraie bascule est là. Je ne laisse pas le modèle improviser toute l’orchestration. Je définis ce qui doit arriver, quand, pourquoi, et sous quelles conditions.

Dans une boucle d’agent autonome, le modèle reçoit une consigne, réfléchit, choisit un outil, observe le résultat, recommence, puis décide quand s’arrêter. C’est séduisant sur une démo. En prod, ça devient vite flou. On ne sait plus vraiment pourquoi il a pris telle route, pourquoi il a sauté une validation, ou pourquoi il a continué alors qu’il aurait dû s’arrêter.

Avec un graphe, les responsabilités deviennent visibles.

• Les nœuds représentent les étapes importantes, comme rechercher, analyser, valider ou générer une réponse.
• Les transitions disent comment on passe d’une étape à l’autre.
• L’état partagé garde les informations utiles pendant l’exécution, comme les données trouvées, les erreurs, les décisions ou le contexte utilisateur.
• Les routes orientent le parcours selon des conditions simples, par exemple “si la confiance est faible, demander une vérification”.
• Les garde-fous empêchent certaines actions risquées, comme envoyer une réponse sans validation.
• Les points de récupération permettent de reprendre proprement après une erreur, au lieu de relancer tout le processus.
• Les limites de contrôle fixent ce que le modèle peut décider seul, et ce qui doit rester déterministe.

Chez un client, le vrai problème n’était pas la qualité du modèle. Le modèle était correct. Le souci, c’était l’absence de séparation claire entre recherche, décision, validation et finalisation. Tout était mélangé dans un seul prompt énorme. Dès qu’un cas sortait un peu du cadre, l’agent bricolait.

Le graph engineering remet de l’ordre. Le modèle garde sa valeur là où il est fort, comprendre, résumer, classer, raisonner. Le workflow reprend le contrôle sur la séquence, les règles, les validations et les sorties attendues.

Pour rendre ça concret, il faut regarder les composants du graphe un par un.

Quels composants rendent le graphe robuste ?

Un graphe robuste, ce n’est pas un gros schéma compliqué. C’est surtout une façon de limiter les dégâts quand l’IA hésite, se trompe, attend une info ou doit recommencer proprement. En prod, je préfère toujours un graphe un peu “ennuyeux” mais lisible, plutôt qu’un agent magique qui improvise tout.

Les nœuds sont les unités d’exécution. Un nœud peut être un appel LLM, donc un appel à un modèle de langage, un agent avec des outils, une fonction Python, une requête en base de données, une API, un validateur, un test, une demande humaine ou même un sous-graphe complet. L’idée simple, c’est qu’un nœud fait une chose claire. Pas quinze.

Un point important : les règles business déterministes doivent rester hors du LLM quand c’est possible. Si une remise ne doit jamais dépasser 15 %, je ne demande pas au modèle de “faire attention”. Je code la règle. J’ai vu ça chez un client sur de la génération de devis, et le simple fait de sortir les règles tarifaires du prompt a supprimé une grosse partie des erreurs.

Les arêtes, elles, décrivent les transitions autorisées. Elles disent où le flux peut aller, et dans quelles conditions :

• Transitions directes, quand l’étape suivante est toujours la même.
• Transitions conditionnelles, quand on choisit selon l’état courant.
• Branches parallèles, quand plusieurs traitements peuvent tourner en même temps.
• Boucles, pour réessayer ou améliorer une sortie.
• Chemins d’erreur, pour éviter que tout le workflow explose.
• Intervention humaine, quand une validation ou une décision est nécessaire.
• Déclenchement événementiel, quand un signal externe relance ou continue le graphe.

L’état, c’est l’enregistrement partagé du workflow. Il contient par exemple user_request, task_plan, retrieved_evidence, draft, validation_result, retry_count ou approval_status. Quand cet état est typé, on sait ce qu’on manipule. On évite les chaînes de texte floues qui changent de forme à chaque étape.

Les réducteurs servent à fusionner proprement les mises à jour, surtout en parallèle. Une liste peut être concaténée. Un dictionnaire peut être fusionné. Une valeur peut prendre la dernière version connue. Un conflit peut être résolu avec une règle explicite. Sans ça, deux branches peuvent écraser le travail l’une de l’autre sans prévenir.

Les routes et les conditions de garde sont du code qui choisit la suite selon l’état. Si validation_result vaut “failed”, on corrige. Si retry_count dépasse 3, on escalade. Si approval_status vaut “approved”, on publie. C’est simple, visible, testable.

Les checkpoints sont des instantanés du graphe. Ils permettent de reprendre après une panne, inspecter ce qui s’est passé, rejouer une exécution, ou attendre un feedback humain sans perdre le contexte. Pour moi, c’est un des vrais marqueurs d’un agent prêt pour la prod.

Composant	Rôle
Nœuds	Exécutent une action bornée et compréhensible.
Arêtes	Définissent les transitions autorisées entre les étapes.
État typé	Centralise les données partagées du workflow.
Réducteurs	Fusionnent les mises à jour sans écrasement sauvage.
Routes et gardes	Choisissent la suite avec des règles explicites.
Checkpoints	Permettent reprise, inspection, replay et attente humaine.

Où faut-il laisser décider le LLM ?

Je vois souvent le même piège en prod : on donne trop de pouvoir au LLM, puis on s’étonne que le système soit dur à stabiliser. Le bon réflexe, c’est de séparer ce qui relève d’une règle claire de ce qui relève vraiment du langage, du jugement ou de l’ambiguïté.

Une règle explicite doit vivre dans le routage, pas dans le prompt. Si une validation est obligatoire, si un seuil de retry est fixé à 3 tentatives, si une règle de conformité dit “pas de réponse sans source vérifiée”, ça doit être codé comme une condition de garde. Une condition de garde, c’est juste une barrière propre dans le graphe : si l’état ne respecte pas la condition, on ne passe pas à l’étape suivante.

Le LLM est utile quand la décision demande une interprétation. Par exemple, classer une demande client un peu floue, reformuler une réponse pour qu’elle soit plus claire, synthétiser trois documents contradictoires, détecter une intention dans un message mal écrit. Là, le modèle apporte quelque chose. Il gère la nuance.

La frontière saine ressemble à ça :

• Dans le code de routage : Les seuils, les validations obligatoires, les règles de conformité, les droits d’accès, les passages en revue humaine, les retries, les blocages.
• Dans le LLM : Les classifications floues, les synthèses, les reformulations, les extractions avec ambiguïté, les jugements qualitatifs.

Cacher des contraintes fortes dans un prompt finit souvent mal. Pas parce que le prompt est inutile, mais parce qu’il devient une zone grise. Vous testez comment une règle écrite en langage naturel au milieu de 40 lignes d’instructions ? Vous auditez comment une décision qui dépend d’une formulation ? Vous reproduisez comment un comportement quand le modèle change légèrement sa réponse ? J’ai vu ça chez un client : la règle critique était “normalement” dans le prompt, sauf que parfois le modèle la suivait, parfois il l’interprétait. En prod, “normalement” coûte cher.

L’état typé du chapitre précédent rend cette séparation beaucoup plus simple. Si validation_result contient des champs clairs, le graphe peut router proprement. Si validation_result indique “manque de preuve”, on retourne vers la recherche. Si validation_result indique “risque élevé”, on envoie en revue humaine. Si tout est validé, on finalise. Le LLM peut aider à produire ce résultat, mais la décision critique de route reste lisible, testable et maintenable.

Comment gérer le parallèle sans casser l’état ?

Quand je mets plusieurs nœuds en parallèle dans un agent IA, le vrai sujet n’est pas juste “ça va plus vite”. Le vrai sujet, c’est qui a le droit de modifier quoi dans l’état partagé, et comment on combine ces modifications sans tout casser.

Imaginez un agent qui lance trois recherches en même temps, deux validations métier, puis un appel API pour vérifier un stock. Chaque nœud revient avec un bout de vérité. Sans règle claire, le dernier qui écrit peut écraser les autres. Ou pire, vous gardez un état incohérent, avec un statut “validé” et une erreur bloquante au même moment. J’ai déjà vu ça chez un client : le modèle était accusé de “faire n’importe quoi”, alors que le problème venait juste d’un état mis à jour sans contrat clair.

C’est là que les state reducers deviennent importants. Un reducer, c’est une règle qui dit comment fusionner une nouvelle mise à jour avec l’état existant. Ce n’est pas un détail technique. C’est une décision d’architecture, parce que ça définit ce que votre système considère comme vrai quand plusieurs choses arrivent en même temps.

Les stratégies utiles sont souvent simples, mais elles doivent être explicites :

• Concaténer les listes quand plusieurs nœuds ajoutent des preuves, des sources ou des observations.
• Fusionner des dictionnaires quand chaque nœud enrichit une partie différente du profil, du contexte ou du résultat.
• Garder la valeur la plus récente pour un statut temporaire, comme “en cours”, “terminé” ou “à relancer”.
• Choisir la valeur la plus prioritaire pour une erreur, surtout si certaines erreurs doivent bloquer tout le workflow.
• Bloquer quand deux résultats sont incompatibles, au lieu d’inventer une moyenne absurde.

Type de mise à jour	Reducer adapté	Risque évité
Liste de preuves	Concaténation	Perte de sources utiles
Données structurées	Fusion de dictionnaires	Écrasement d’informations
Statut d’exécution	Valeur la plus récente	État obsolète
Erreur métier	Priorité la plus forte	Erreur critique masquée
Résultats contradictoires	Blocage ou arbitrage explicite	Décision impossible à reproduire

Dans les projets IA, les bugs les plus pénibles ne viennent pas toujours du modèle. Ils viennent souvent de l’état qui change sans règles claires. Et quand ça arrive en prod, c’est l’enfer à déboguer, parce que le même input peut produire deux comportements différents selon l’ordre de retour des appels.

Que faut-il prévoir avant la production ?

Avant la prod, je regarde rarement le diagramme en premier. Je regarde ce qui se passe quand ça casse, quand ça coupe, quand le modèle hésite, quand un utilisateur doit valider, ou quand on doit comprendre pourquoi l’agent a pris une mauvaise décision deux heures plus tôt.

Dans une démo, tout est fluide. L’agent reçoit une demande, appelle un outil, résume, répond. En prod, c’est autre chose. Une API tombe. Un token expire. Une réponse du modèle est ambiguë. Un client demande une trace. Un métier veut approuver avant l’envoi d’un email sensible. C’est là que le graph engineering devient utile, parce qu’il oblige à prévoir les vrais chemins, pas seulement le chemin heureux.

Le point que je vois souvent oublié, c’est le checkpoint. Un checkpoint, c’est une sauvegarde de l’état du workflow à un moment précis. Pas juste un log. Un état exploitable. Il permet plusieurs choses très concrètes :

• Reprendre après interruption, sans relancer tout le workflow depuis zéro.
• Récupérer après erreur, en repartant du dernier état sain.
• Attendre une approbation humaine, puis continuer exactement au bon endroit.
• Inspecter un état précédent, pour comprendre ce que l’agent savait au moment de décider.
• Rejouer le workflow, avec les mêmes entrées, pour déboguer ou comparer deux versions.

L’autre sujet critique, c’est l’humain. Trop souvent, on le rajoute après coup avec un Slack, un email, ou un bouton bricolé dans un coin. Ça marche en démo. Ça devient vite ingérable. Si une validation humaine est nécessaire, alors l’humain doit être un nœud ou une route du graphe. Le workflow doit savoir qu’il attend une décision, qu’il peut être refusé, modifié, relancé, ou escaladé.

Des frameworks publics comme LangGraph ont popularisé cette façon de faire avec des graphes à état, des cycles, de la persistance et du human-in-the-loop, c’est-à-dire l’intervention humaine intégrée dans le flux. Mais je ne choisirais pas un outil juste parce qu’il est à la mode. Le vrai sujet, c’est de rendre les responsabilités explicites.

Le graph engineering n’enlève pas l’incertitude de l’IA. Il la met dans un cadre contrôlable, observable, et surtout exploitable quand on passe du prototype au système réel.

Et si vos agents IA avaient surtout besoin d’un cadre clair ?

Le graph engineering ne rend pas un modèle magique. Il rend l’application IA plus lisible, plus testable et plus contrôlable. Au lieu d’avoir un agent qui boucle, appelle des outils et prend des décisions dans une logique difficile à suivre, on sépare les rôles : nœuds, état typé, routes, validations, reducers, checkpoints et intervention humaine. C’est souvent là que se joue la différence entre une démo sympa et un système fiable. Mon avis est simple : gardez le LLM pour ce qu’il fait bien, codez le reste proprement. Le bénéfice pour vous, c’est moins d’improvisation, moins de dette technique, et des agents IA vraiment exploitables.

FAQ

• Qu’est-ce que le graph engineering pour agents IA ?
  C’est une manière de construire une application IA comme un graphe exécutable. Chaque étape a un rôle clair : agent, outil, fonction, validation, source de données, intervention humaine. L’objectif est de ne pas laisser toute l’orchestration au modèle.
• Pourquoi un seul agent IA ne suffit pas toujours ?
  Un agent unique peut vite devenir difficile à contrôler. Il décide quoi faire, quand appeler un outil, quand s’arrêter, quand recommencer. Avec un graphe, je rends ces décisions visibles et testables avec des routes, des conditions de garde et des checkpoints.
• À quoi sert un état typé dans un graphe IA ?
  L’état typé sert à faire circuler les informations utiles entre les nœuds sans renvoyer tout l’historique à chaque agent. On peut suivre la demande utilisateur, le plan, les preuves récupérées, le brouillon, le résultat de validation, les retries ou le statut d’approbation.
• Les règles business doivent-elles être dans les prompts ?
  Quand une règle est claire, je préfère la mettre dans du code déterministe. Un prompt peut aider pour du langage ou une décision floue, mais une contrainte forte doit être dans une route, une condition de garde ou un validateur. C’est plus fiable et plus simple à auditer.
• Pourquoi les checkpoints sont importants en production ?
  Les checkpoints capturent l’état du workflow à un moment donné. Ils permettent de reprendre après une erreur, d’attendre une validation humaine, d’inspecter ce qui s’est passé et de rejouer un scénario. Sans ça, un agent IA en production devient vite pénible à déboguer.

 

 

A propos de l’auteur

Je suis Franck Scandolera, responsable de l’agence webAnalyste et de l’organisme Formations Analytics. J’accompagne des équipes sur le tracking avancé server-side, l’Analytics Engineering, l’automatisation No/Low Code avec n8n, l’intégration de l’IA en entreprise et le SEO/GEO. J’ai travaillé avec des clients comme Logis Hôtel, Yelloh Village, BazarChic, la Fédération Française de Football ou Texdecor. Si vous voulez cadrer vos agents IA, automatiser vos workflows ou fiabiliser vos données, contactez-moi, je peux vous aider à poser une architecture propre.