Graph Engineering : faut-il vraiment 100 agents IA ?

Le « Graph Engineering » promet de passer d’un prompt unique à des dizaines, voire des centaines d’agents qui travaillent ensemble. L’image est spectaculaire. Pour une entreprise, la vraie question est moins impressionnante mais beaucoup plus utile : peut-on découper un travail complexe, exécuter certaines parties en parallèle, contrôler les résultats et reprendre proprement en cas d’échec ?

Ce sujet ne concerne pas seulement les équipes techniques. Une veille réglementaire, une comparaison de fournisseurs, un audit documentaire ou la préparation d’un appel d’offres peuvent suivre la même logique. Encore faut-il distinguer une nouvelle étiquette des pratiques déjà connues, et ne pas transformer chaque tâche en usine à agents.

1. Que désigne réellement le « Graph Engineering » ?

Dans ce contexte, un graphe représente la manière dont un travail circule entre plusieurs étapes. Chaque nœud accomplit une tâche : rechercher une source, analyser un contrat, interroger une base, calculer un score, vérifier une affirmation ou demander une validation humaine. Les flèches indiquent les dépendances réelles entre ces étapes.

La règle la plus utile tient en une question : l’étape suivante a-t-elle besoin du résultat de la précédente ? Si la réponse est non, les deux travaux peuvent souvent être lancés en parallèle.

Prenons une étude de marché. L’analyse des tarifs de trois concurrents n’a pas besoin d’être effectuée dans l’ordre. Trois agents ou trois tâches peuvent travailler simultanément, puis un nœud de synthèse compare les résultats. À l’inverse, la recommandation finale dépend bien des analyses : cette flèche est réelle.

Un graphe utile mélange généralement plusieurs types de nœuds. Tout n’a pas besoin d’un modèle d’IA.

• Un agent pour comprendre une demande ambiguë ou résumer des documents.
• Du code classique pour trier, dédupliquer, calculer ou appliquer une règle connue.
• Un vérificateur séparé pour contrôler les sources, le format ou les risques.
• Une validation humaine avant une action difficile à annuler.
• Un stockage durable pour savoir ce qui a été fait et reprendre après une interruption.

2. Est-ce une vraie nouveauté ou surtout un nouveau mot ?

Le terme « Graph Engineering » est encore émergent et ne possède pas de définition industrielle commune. Les documentations d’Anthropic, d’OpenAI et de LangGraph parlent plutôt d’orchestration, de subagents, de workflows, de routage, de parallélisation, d’état et de reprise.

Les mécanismes, eux, sont établis. Les graphes orientés, les machines à états, les moteurs de workflow, les files de messages, les tâches parallèles, les contrôles et les reprises après incident existent depuis longtemps. La nouveauté vient surtout du contenu de certains nœuds : un agent IA peut interpréter une demande, utiliser des outils et adapter sa recherche en cours de route.

L’étiquette a donc une utilité si elle oblige à regarder la forme du travail. Elle devient du buzz si elle laisse croire qu’il suffit de lancer cent agents pour obtenir une réponse cent fois meilleure.

Anthropic indique que son système de recherche multi-agent consomme environ quinze fois plus de jetons qu’une conversation classique. L’entreprise explique aussi que cette architecture convient surtout aux recherches larges, parallélisables et suffisamment importantes pour justifier le coût. Pour une tâche courte ou fortement séquentielle, un seul agent reste souvent plus rapide et plus simple.

3. Claude Code et Codex savent-ils déjà travailler ainsi ?

Oui, avec des différences de mise en œuvre et de visibilité.

Claude Code documente plusieurs moyens de paralléliser le travail : des subagents dans une même session, des agents coordonnés, des sessions séparées et des worktrees pour isoler les modifications. Chaque subagent peut disposer de son propre contexte, de consignes spécialisées et d’outils limités. Le modèle principal peut déléguer des recherches indépendantes puis rassembler leurs conclusions.

Codex propose lui aussi une organisation multi-agent. L’application permet de faire travailler plusieurs agents en parallèle dans des tâches séparées et d’isoler leurs modifications avec des worktrees. Avec GPT-5.6, OpenAI propose en plus une capacité multi-agent en bêta capable de coordonner des subagents concurrents et de synthétiser leurs résultats dans une même requête.

Pour construire un produit durable, les deux écosystèmes proposent également des briques programmatiques. Le Claude Agent SDK permet de définir des subagents isolés. L’OpenAI Agents SDK distingue l’orchestration laissée au modèle de l’orchestration écrite en code, plus prévisible pour les coûts, les délais et les autorisations.

En pratique, la comparaison est la suivante.

• Claude Code : très adapté lorsque l’on veut déléguer des sous-tâches dans un dépôt, spécialiser des agents et isoler leurs contextes ou leurs fichiers.
• Codex : très adapté pour superviser plusieurs tâches en parallèle, conserver des environnements séparés et appliquer ce mode de travail au code comme à d’autres travaux numériques.
• Agents SDK : préférable lorsque le graphe doit devenir une fonction permanente de l’entreprise, avec des règles, un historique, des coûts mesurés et des validations explicites.

Aucun de ces outils ne supprime le travail de conception. Ils peuvent exécuter un graphe, parfois même proposer un découpage, mais ils ne savent pas automatiquement quelles dépendances métier sont réelles ni quel niveau de risque l’entreprise accepte.

4. Dans quels cas une PME peut-elle réellement y gagner ?

Le gain apparaît surtout lorsque plusieurs recherches ou analyses sont indépendantes, que leur résultat peut être vérifié et que le temps gagné a une valeur réelle.

• Une veille réglementaire peut répartir le travail entre plusieurs sources, puis dédupliquer les changements et ne conserver que ceux qui touchent l’entreprise.
• Une étude de marché peut analyser simultanément les concurrents, les prix, les avis clients et les signaux sectoriels avant une synthèse commune.
• Un audit documentaire peut répartir les contrats ou procédures, faire vérifier chaque conclusion dans un contexte séparé, puis produire une liste de risques consolidée.
• Une équipe informatique peut analyser différents modules en parallèle, à condition que les modifications soient isolées et que les tests servent de contrôle extérieur.

Il faut en revanche rester sur un agent unique lorsque la tâche tient dans un seul contexte, avance surtout par dialogue, comporte beaucoup de dépendances ou peut être vérifiée en quelques minutes par une personne.

Le risque principal n’est pas seulement financier. Un graphe mal conçu peut multiplier les erreurs, cacher une branche qui a échoué ou donner une apparence de consensus à plusieurs agents qui s’appuient sur la même mauvaise hypothèse. La vérification doit donc porter sur des éléments extérieurs : sources accessibles, calculs reproductibles, tests, données métier et validation humaine.

Avant de lancer plusieurs agents, une PME devrait pouvoir répondre à cinq points simples.

1. Quel résultat précis attend-on ?
2. Quelles tâches sont réellement indépendantes ?
3. Comment chaque sortie sera-t-elle structurée et contrôlée ?
4. Quelle action exige une validation humaine ?
5. Quel budget de temps, de jetons et de relances accepte-t-on ?

5. Comment tester le concept sans construire une usine à agents ?

On commencerait par une mission ponctuelle, large mais délimitée. Par exemple : comparer cinq solutions, chercher les changements réglementaires d’un secteur ou analyser plusieurs familles de documents.

La première version peut être lancée directement dans Claude Code ou Codex avec une consigne explicite : séparer les recherches indépendantes, utiliser un contexte distinct pour la vérification, citer chaque source, signaler les branches incomplètes et demander une validation avant toute modification.

Le test doit mesurer le temps total, pas seulement la durée affichée par l’agent. Il faut compter la préparation de la demande, les autorisations, la revue, les corrections et les résultats inutilisables. On comparerait ensuite ce total à une exécution plus simple avec un agent unique.

Si l’expérience est concluante et doit être répétée, on formaliserait progressivement les entrées, les sorties, les règles de routage, les contrôles et l’état. Un framework comme LangGraph peut gérer des workflows d’agents avec exécution durable et intervention humaine. Un moteur de workflow classique peut également convenir si l’entreprise possède déjà cette compétence.

On ne commencerait pas par cent agents. On commencerait par deux tâches réellement indépendantes, un point de réunion et un contrôle fiable. Le graphe grandit uniquement lorsque le travail l’exige.

Le verdict Clarifya

Le « Graph Engineering » est une étiquette récente posée sur une évolution réelle : les agents ne sont plus seulement utilisés un par un, ils peuvent devenir des composants coordonnés dans un workflow. Claude Code et Codex permettent déjà de tester cette approche sans développer toute l’infrastructure.

Pour une PME, la compétence importante n’est pas de savoir lancer le plus grand nombre d’agents. C’est de découper un problème, supprimer les fausses dépendances, limiter les droits, vérifier les sorties et garder un humain là où une erreur coûte cher. Si ces règles ne sont pas claires, le graphe ajoute surtout du coût. Si elles le sont, il peut transformer une mission longue et séquentielle en travail parallèle, contrôlé et réutilisable.