Vous aviez à peine digéré le prompt engineering (bien formuler sa demande), puis le context engineering (bien choisir ce qu’on montre au modèle), que les développeurs d’agents sortent un nouveau mot : le graph engineering. Promis, ce n’est pas un buzzword de plus. C’est même la plus vieille idée du génie logiciel appliquée à l’IA : dessiner le plan avant de construire. Dans chat, agent, loop, toute la différence tenait dans une question : qui décide de l’étape suivante ? Le graph engineering apporte une réponse inattendue : les deux. Vous dessinez les routes autorisées ; le modèle choisit aux embranchements. On démonte ensemble, vous allez voir : c’est pas sorcier.

Le taxi, le funiculaire et le train

Jusqu’ici, pour mettre un LLM au travail sur une tâche à plusieurs étapes, vous aviez deux options :

  • Le workflow figé, c’est le funiculaire. Une seule voie, un seul sens : étape 1, étape 2, étape 3. Prévisible, économique… et rigide. À la moindre situation imprévue, tout le monde descend.
  • L’agent libre, c’est le taxi tout-terrain. Vous donnez la destination, il se débrouille : sa boucle agentique décide chaque étape en route. Formidable en terrain inconnu. Mais parfois il prend des détours surprenants, le compteur tourne, et personne ne sait à l’avance par où il passera.

Entre les deux, il y a le réseau ferroviaire : des gares où le travail se fait, des rails qui les relient, et des aiguillages où l’on choisit une voie plutôt qu’une autre. Le train ne quitte jamais les rails (c’est vous qui avez décidé des routes possibles), mais le trajet exact dépend de ce qui se passe en chemin. Concevoir ce réseau, gare par gare, aiguillage par aiguillage : voilà le graph engineering. Gardez cette image, on la suit jusqu’au terminus.

Quatre mots à connaître : gare, rail, aiguillage, bordereau

Un graphe d’agent, c’est quatre pièces, pas une de plus :

  • Le nœud, c’est la gare. Une étape où le travail se fait. À l’intérieur, ce que vous voulez : un appel au modèle, du code classique, un appel d’outil, ou même un petit agent complet enfermé dans la gare.
  • L’arête, c’est le rail. Elle dit ce qui vient après : quand la gare « classifier » a fini, direction la gare « chercher ».
  • L’arête conditionnelle, c’est l’aiguillage. Selon le résultat, le train part sur la voie A ou la voie B. Qui manœuvre l’aiguillage ? Parfois trois lignes de code (un simple if), parfois le modèle lui-même. C’est le seul endroit où le modèle « choisit », et uniquement parmi les voies que vous avez posées.
  • L’état, c’est le bordereau de fret. Un document qui voyage avec le train. Chaque gare le lit, fait son travail, et le complète : la question du client, la catégorie détectée, les extraits trouvés, le brouillon de réponse, le verdict de vérification. À l’arrivée, le bordereau contient toute l’histoire du trajet.

Un exemple concret : le support client

Dessinons le réseau d’un agent de support :

flowchart TD
    Q([Question client]) --> C{Classifier}
    C -->|facturation| F[Chercher dans les conditions]
    C -->|technique| T[Chercher dans la doc]
    C -->|hors sujet| H[Transmettre à un humain]
    F --> R[Rédiger la réponse]
    T --> R
    R --> V{Vérifier}
    V -->|à revoir| R
    V -->|validé| E([Envoyer])

Suivez le train : la question entre en gare « classifier », où un petit modèle bon marché fait le tri (le pattern routing, tout simplement). L’aiguillage envoie vers la bonne recherche documentaire (du RAG classique), puis la gare « rédiger » où le gros modèle compose la réponse. La gare « vérifier » relit contre des critères explicites : réponse incomplète ? Le train repart en arrière pour un nouvel essai (deux maximum, ensuite on transmet à un humain). Et la question hors sujet n’a même pas visité le gros modèle : voie directe vers un humain.

Rien de magique : chaque gare est petite, spécialisée, et remplit sa case du bordereau.

Un vrai réseau a des boucles

Sur le papier, on imagine un organigramme bien sage qui descend de haut en bas. En production, c’est faux : les graphes qui fonctionnent sont pleins de boucles. Le retour « à revoir » du schéma ci-dessus, c’est le duo générateur-évaluateur : une gare produit, une gare critique, et ça tourne jusqu’à validation (ou plafond d’essais). Autre boucle classique : la gare « demander une précision à l’humain », d’où le train repart avec un bordereau enrichi.

Ce n’est pas nous qui le disons : les auteurs de LangGraph, l’outil qui a popularisé le terme (plus de 65 millions de téléchargements par mois), insistent après trois ans de pratique : les graphes de production ne sont jamais des lignes droites. Réessayer, valider, redemander : les boucles sont la règle, pas l’exception. Côté Microsoft, l’Agent Framework parle de « workflows » pour la même idée ; le vocabulaire varie, le plan de réseau reste.

Pourquoi se donner ce mal ?

Face au taxi tout-terrain, le réseau ferré a quatre arguments sérieux :

  1. La prévisibilité. Le train ne quitte pas les rails. Un agent libre peut « oublier » de vérifier avant d’envoyer ; ici c’est impossible, la gare « vérifier » est posée sur la voie, le train passe dedans, point.
  2. La testabilité. Vous testez gare par gare, avec de vraies évals : la classification tombe-t-elle juste sur 50 cas connus ? La vérification attrape-t-elle les mauvais brouillons ? Tester un taxi qui change de route à chaque course est beaucoup plus difficile.
  3. Le coût. Chaque gare choisit son modèle. Un mini-modèle pas cher à l’aiguillage de classification, le gros modèle uniquement là où il apporte quelque chose (la rédaction). Sur des milliers de tickets, la différence sur la facture de tokens se voit.
  4. La sécurité. Les permissions se règlent par gare. La gare « envoyer l’email » exige une validation humaine ; la gare « chercher dans la doc » n’a le droit que de lire. Des garde-fous posés dans le béton du réseau, pas dans les bonnes intentions du prompt.

Le mot d’honnêteté

Le graph engineering n’est pas la réponse à tout, et il vaut mieux le savoir avant de poser des rails partout :

  • Si la route est entièrement connue d’avance (aucun choix en chemin), pas besoin de graphe : un simple enchaînement d’appels (prompt chaining) suffit. On ne construit pas une gare de triage pour un funiculaire.
  • Si la tâche est vraiment exploratoire (déboguer un problème inconnu, une recherche ouverte), le taxi reste meilleur : impossible de dessiner des rails vers une destination qu’on ne connaît pas. C’est pour ça que les agents de code restent largement « libres ».
  • Le graphe brille entre les deux : quand la structure du travail est connue (classifier, chercher, rédiger, vérifier) mais pas le chemin exact de chaque demande.
  • Le piège classique : la sur-ingénierie. Quarante gares pour une tâche à trois étapes, c’est un réseau ingérable. Commencez par trois gares ; ajoutez un aiguillage le jour où un vrai problème le réclame.

En résumé

Élément du graphe L’image Le rôle
Nœud la gare une étape qui travaille (code, LLM, outil, agent)
Arête le rail ce qui vient après
Arête conditionnelle l’aiguillage choisir la voie selon le résultat
État le bordereau de fret le document que les gares se passent et complètent
Le graphe entier le plan du réseau toutes les routes que vous autorisez
  • La généalogie est logique : le prompt engineering règle ce que vous dites, le context engineering ce que vous montrez, le graph engineering les routes que vous autorisez.
  • Le modèle décide aux aiguillages, jamais des rails : l’autonomie exactement là où elle est utile.
  • Funiculaire si tout est connu, taxi si rien ne l’est, réseau ferré entre les deux.
  • Notre collection de patterns (routing, prompt chaining, générateur-évaluateur…) est en fait un catalogue de morceaux de réseau prêts à poser.

La prochaine fois qu’on vous présente un « agent IA d’entreprise », demandez à voir le plan du réseau. Des gares, des rails, des aiguillages, un bordereau : si vous savez lire un plan de métro, vous savez lire un graphe d’agent. C’est pas sorcier.