Le Graph Engineering fiabilise-t-il les agents IA ?

Le Graph Engineering rend les agents IA plus fiables en sortant la logique du prompt pour la mettre dans un graphe exécutable. On voit qui fait quoi, quand, avec quel état, quelles validations et quelles reprises possibles. C’est souvent ce qui manque aux agents IA bricolés trop vite.

Pourquoi sortir de l’agent unique ?

On sort de l’agent unique parce que ses décisions, ses transitions et ses responsabilités restent trop implicites dans le contexte du modèle.

Dans une boucle d’agent unique, on donne un objectif à un LLM, un LLM c’est un modèle de langage, puis on le laisse décider quoi faire ensuite. Il peut appeler un outil, relire l’historique, reformuler, tenter une autre action. Sur le papier, c’est élégant. Dans la vraie vie, une grosse partie de la logique finit cachée dans le prompt, dans l’historique de conversation, ou dans le raisonnement interne du modèle. Et là, quand ça dérape, c’est compliqué de savoir pourquoi.

Dans une application IA modélisée comme un graphe exécutable, on rend les choses visibles. Les agents, les fonctions, les outils, les humains, les routes, les conditions, les validateurs, l’état partagé et les checkpoints deviennent explicites. Un checkpoint, c’est juste un point de sauvegarde qui permet de reprendre proprement après une erreur ou une interruption. Ce n’est pas magique, mais ça change tout en production.

Sur des projets client, je vois souvent le même sujet revenir. Le vrai problème n’est pas toujours la qualité du modèle. C’est l’absence de structure autour du modèle. Un agent peut très bien répondre 8 fois sur 10. Mais si on ne sait pas reprendre après erreur, tracer une décision, ou forcer une validation humaine sur un cas risqué, ça reste fragile. Et fragile, en production, ça finit toujours par coûter cher.

Le Graph Engineering ne remplace pas le LLM. Il encadre son rôle. Les décisions métier connues restent dans du code déterministe, donc du code qui donne le même résultat avec les mêmes entrées. Le LLM intervient là où il est vraiment utile : interpréter une demande floue, générer une réponse, proposer un plan, gérer l’ambiguïté. C’est beaucoup plus sain que de lui demander de porter toute l’application sur ses épaules.

Sujet	Agent unique	Graphe d’agents
Logique de décision	Souvent cachée dans le prompt ou le contexte.	Définie par des routes, conditions et règles explicites.
Visibilité	Difficile de comprendre pourquoi l’agent a choisi une action.	Chaque étape peut être tracée et inspectée.
Reprise après erreur	Souvent improvisée ou dépendante du modèle.	Possible via état partagé et checkpoints.
Validation humaine	Ajoutée au cas par cas, souvent tardivement.	Intégrée comme un nœud du workflow.
Passage en production	Rapide au début, fragile ensuite.	Plus structuré, plus contrôlable, plus robuste.

De quoi se compose un graphe IA ?

Un graphe IA se compose de nœuds, d’arêtes, d’un état partagé, de routes, de conditions de garde, de réducteurs d’état et de checkpoints. Dit simplement, c’est une façon de rendre un agent moins flou, parce qu’on découpe son comportement en blocs visibles, testables, et contrôlables.

Un nœud, c’est une unité bornée d’exécution. Ça peut être un appel à un LLM, un agent avec outils, une fonction Python, une récupération documentaire, une requête en base de données, un appel API, une vérification de politique, une suite de tests, une demande d’approbation humaine ou même un sous-graphe. J’aime bien cette idée de “borne”, parce qu’on sait ce qui entre, ce qui sort, et ce qu’on peut surveiller.

Une arête définit ce qui peut s’exécuter après un nœud. L’état, lui, c’est l’enregistrement partagé qui traverse tout le workflow. On y garde la demande utilisateur, les documents trouvés, le brouillon, les scores de risque, les validations, les erreurs. Les routes choisissent le chemin à prendre. Les conditions de garde autorisent ou bloquent une transition. Les réducteurs d’état combinent les mises à jour parallèles, par exemple quand plusieurs recherches reviennent en même temps. Les checkpoints sauvegardent l’état pour reprendre plus tard, sans tout relancer.

Composant	Rôle	Exemple simple
Nœud	Exécute une action précise	Générer un brouillon avec un LLM
Arête	Définit la suite possible	Après recherche, passer à rédaction
État partagé	Stocke les données du workflow	Demande, sources, brouillon, score de risque
Route	Choisit le prochain chemin	Aller vers correction ou validation
Condition de garde	Bloque ou autorise une transition	Interdire la finalisation sans source fiable
Réducteur d’état	Fusionne des résultats parallèles	Regrouper plusieurs preuves trouvées
Checkpoint	Sauvegarde pour reprendre	Reprendre après approbation humaine

Un exemple concret, c’est un workflow de rédaction contrôlée :

• Demande utilisateur.
• Plan de tâche.
• Recherche de preuves.
• Génération d’un brouillon.
• Validation des sources et des règles internes.
• Correction si la validation échoue.
• Approbation humaine si le risque est élevé.
• Finalisation.

Demande utilisateur
  -> Plan de tâche
  -> Recherche de preuves
  -> Brouillon
  -> Validation
      -> Si erreur : Correction -> Validation
      -> Si risque élevé : Approbation humaine -> Finalisation
      -> Sinon : Finalisation

LangGraph a popularisé cette approche côté agents IA avec des graphes avec état, de la persistance, du streaming, du human-in-the-loop, c’est-à-dire l’intervention humaine dans le workflow, et le support des exécutions longues. C’est utile quand un agent ne doit pas juste répondre vite, mais tenir un processus fiable sur plusieurs étapes.

Comment gérer l’état sans chaos ?

On gère l’état sans chaos en le typant, en limitant ce que chaque nœud lit ou modifie, et en définissant des règles de fusion quand plusieurs branches écrivent au même endroit.

C’est un sujet très concret. Dans un workflow d’agents IA, l’état partagé sert à éviter de repasser toute la conversation, tout l’historique, toutes les décisions, à chaque agent. Chaque nœud lit ce dont il a besoin, écrit ce qu’il produit, et le reste du graphe peut voir clairement les entrées et les sorties. Ça rend le système plus lisible, plus testable, et franchement plus facile à débugger quand ça part de travers.

WorkflowState = {
  user_request: string,
  task_plan: list,
  retrieved_evidence: list,
  draft: string,
  validation_result: dict,
  retry_count: number,
  approval_status: string
}

Je vois souvent l’erreur inverse chez des clients : ils mettent tout dans l’état. Les prompts complets, les brouillons intermédiaires sans valeur, les logs bruts, les réponses temporaires, parfois même des données sensibles qui n’ont rien à faire là. Mauvaise idée. L’état doit garder ce qui sert au routage, à la validation, à la reprise après erreur ou à la traçabilité. Le reste peut rester local au nœud, puis disparaître.

Le point critique, c’est ce qui se passe quand plusieurs branches écrivent au même endroit. Imaginons trois agents de recherche qui retournent chacun des preuves. Sans règle claire, le dernier résultat peut écraser les deux autres. Et là, vous avez un agent qui “oublie” des infos, sauf que ce n’est pas vraiment l’agent, c’est votre gestion d’état qui est floue.

Un réducteur d’état règle ce problème. Un réducteur, c’est simplement une règle qui dit comment combiner une ancienne valeur avec une nouvelle valeur. Pour des preuves, on concatène des listes. Pour des métadonnées, on fusionne des dictionnaires. Pour un statut, on garde peut-être la dernière valeur. Pour une validation, on applique une politique personnalisée, par exemple “rejeté gagne toujours sur approuvé”.

• Typer l’état pour savoir exactement ce que chaque champ contient.
• Séparer logique déterministe et logique LLM, parce qu’un calcul simple n’a pas besoin d’un modèle IA.
• Nommer clairement les champs, sans abréviations obscures ni noms fourre-tout.
• Définir les réducteurs pour éviter les écrasements silencieux entre branches.
• Éviter l’état fourre-tout, sinon le graphe devient vite illisible.
• Journaliser les changements importants pour comprendre qui a modifié quoi, et pourquoi.

Où placer les règles de contrôle ?

Les règles de contrôle importantes doivent être placées dans les routes, les conditions de garde et les validateurs, pas seulement dans les prompts.

Si une règle est critique pour le business, je n’aime pas la cacher dans un prompt. Je préfère la voir dans le code de routage, testable, lisible, versionnable. Un prompt peut orienter le comportement d’un agent, oui. Mais il reste probabiliste. Une règle de contrôle, elle, doit être explicite.

Une route, c’est la décision qui choisit la prochaine arête du graphe. En gros, après une étape, où va-t-on maintenant ? Vers la recherche, la validation, la revue humaine, la finalisation ? Une condition de garde, c’est le contrôle qui vérifie si cette transition est autorisée. La route dit “on veut aller là”. La garde dit “ok, mais seulement si les critères sont remplis”.

Dans un graphe d’agent IA, je vois souvent ces types d’arêtes :

• Les arêtes directes, quand le flux va toujours d’un nœud à un autre.
• Les arêtes conditionnelles, quand la suite dépend d’un score, d’un statut ou d’un résultat.
• Les arêtes parallèles, quand plusieurs tâches partent en même temps.
• Les arêtes en boucle, quand l’agent doit recommencer une étape.
• Les arêtes d’erreur, quand un outil échoue ou renvoie une réponse invalide.
• Les arêtes contrôlées par un humain, quand une validation manuelle est nécessaire.
• Les arêtes déclenchées par événement, quand un signal externe relance le flux.

Un exemple simple, inspiré d’une fonction route_after_review, ressemble à ça :

def route_after_review(state):
    foundation_score = state.get("foundation_score", 0)
    risk_level = state.get("risk_level", "low")
    retries = state.get("retries", 0)

    if retries >= 3:
        return "escalate_or_block"

    if foundation_score < 0.75:
        return "research_again"

    if risk_level == "high":
        return "human_review"

    return "finalize"

Ce code n’est pas spectaculaire, et justement c’est ça que j’aime. On comprend la règle en dix secondes. Un client m’avait mis ce genre de logique dans un prompt système énorme. Résultat, impossible de savoir pourquoi certains dossiers passaient en validation et d’autres non. Une fois la règle sortie du prompt et mise dans le routage, les tests sont devenus évidents.

Situation	Route probable
Information insuffisante	Relancer la recherche ou demander une précision
Risque élevé	Envoyer en revue humaine
Validation réussie	Finaliser le traitement
Erreur outil	Passer par une route d’erreur, retry ou fallback
Attente humaine	Mettre le graphe en pause jusqu’à décision

Comment reprendre après une erreur ?

On reprend après une erreur grâce aux checkpoints, aux routes d’erreur et à un état suffisamment clair pour rejouer ou corriger le workflow sans repartir de zéro.

Un checkpoint, c’est simplement une sauvegarde de l’état du graphe à un moment donné. Pas juste “le script a planté”. Plutôt “on était dans tel nœud, avec telles données, telle réponse API déjà reçue, telle décision en attente”. Et ça change tout.

Dans un workflow IA, vous avez souvent plusieurs étapes fragiles :

• Un appel API qui timeout.
• Un modèle qui répond mal ou trop lentement.
• Une validation humaine qui prend deux jours.
• Un fichier à traiter qui fait planter une étape.
• Une donnée métier qui doit être corrigée avant de continuer.

Sans checkpoint, vous relancez tout. Et parfois, relancer tout veut dire repayer des appels IA, rappeler des APIs externes, recréer des documents, ou pire, générer des résultats différents parce que le modèle n’a pas répondu pareil. Je l’ai vu chez un client sur un workflow de qualification de leads. Une erreur sur l’enrichissement CRM obligeait à retraiter toute la file. Ça coûtait du temps, de l’argent, et surtout ça rendait l’équipe méfiante.

Avec un graphe bien conçu, on peut sauvegarder des instantanés, reprendre après une interruption, récupérer après une défaillance, attendre un retour humain, inspecter un état antérieur, puis rejouer une partie du workflow. Pas tout. Juste ce qu’il faut.

Les frameworks orientés graphe comme LangGraph vont clairement dans ce sens avec des mécanismes de persistance et de reprise. C’est utile, surtout pour les agents qui durent plus que quelques secondes. Mais ce n’est pas magique. Il faut décider ce qu’on met dans l’état, où on pose les points de contrôle, et quelles routes on suit quand une erreur arrive.

Le vrai moment où on gagne en sérénité, sur les automatisations IA, c’est quand on peut ouvrir une exécution, voir où elle s’est arrêtée, corriger l’entrée ou attendre un humain, puis reprendre. Là, on n’est plus dans le bricolage. On pilote.

Problème	Mécanisme du graphe	Bénéfice opérationnel
Appel API instable	Checkpoint avant et après l’appel	Reprise sans relancer tout le workflow
Validation humaine en attente	État persistant et nœud d’attente	Pause propre, reprise quand la décision arrive
Donnée incorrecte	Route d’erreur vers correction	Correction ciblée sans perte du contexte
Workflow long et coûteux	Instantanés réguliers de l’état	Moins de coûts, moins de doublons, plus de confiance

Et si vos agents IA avaient enfin une vraie structure ?

Le Graph Engineering ne rend pas un agent IA intelligent par magie. Il rend surtout son fonctionnement visible, contrôlable et récupérable. On découpe l’application en nœuds, on explicite les routes, on type l’état, on ajoute des validations, des réducteurs et des checkpoints. C’est moins spectaculaire qu’une démo d’agent autonome, mais beaucoup plus utile quand on parle production, qualité et responsabilité. Mon avis est simple : dès qu’un workflow IA touche à un vrai processus business, il mérite cette structure. Le bénéfice pour vous, c’est moins d’opacité, moins de bricolage, et des agents IA qu’on peut vraiment exploiter.

FAQ

• Qu’est-ce que le Graph Engineering pour agents IA ?
  Le Graph Engineering consiste à représenter une application IA comme un graphe exécutable. On y trouve des nœuds, des arêtes, un état partagé, des règles de routage, des validateurs et des checkpoints. L’idée est simple : rendre explicite ce qui est souvent caché dans un agent unique.
• Pourquoi un agent unique devient vite fragile ?
  Un agent unique garde souvent ses décisions dans le prompt, l’historique ou le contexte du modèle. C’est rapide pour une démo, mais difficile à contrôler en production. On sait moins bien pourquoi il passe d’une action à l’autre, comment il récupère après erreur, ou quand il doit demander une validation humaine.
• Quel est le rôle de l’état dans un graphe d’agents ?
  L’état est la mémoire structurée du workflow. Il contient par exemple la demande utilisateur, le plan, les preuves récupérées, le brouillon, le résultat de validation, le nombre de tentatives et le statut d’approbation. Bien typé, il évite de transmettre toute la conversation à chaque nœud.
• À quoi servent les checkpoints ?
  Les checkpoints sauvegardent un instantané de l’état du graphe. Ils permettent de reprendre après une interruption, de gérer une erreur, d’attendre une approbation humaine, d’inspecter une exécution passée ou de rejouer une partie du workflow. Pour les processus IA longs, c’est un vrai filet de sécurité.
• LangGraph est-il obligatoire pour faire du Graph Engineering ?
  Non, le concept ne dépend pas d’un seul outil. LangGraph est une option connue parce qu’il propose des graphes avec état, la persistance, le streaming, le human-in-the-loop et les exécutions longues. Mais le principe reste le même : structurer l’application IA sous forme de graphe contrôlable.

 

 

A propos de l’auteur

Je suis Franck Scandolera, expert et formateur en Tracking avancé server-side, Analytics Engineering, automatisation No/Low Code avec n8n, intégration de l’IA en entreprise et SEO/GEO. J’accompagne des équipes qui veulent passer des démos IA aux vrais workflows exploitables, traçables et maintenables. Je dirige l’agence webAnalyste et l’organisme Formations Analytics. 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 structurer vos automatisations IA et vos agents, contactez-moi, je peux vous aider.