LangGraph contre Google ADK en 2026 : orchestration explicite ou composition d’agents

Tout ceux qui développent des agents de production aujourd’hui se heurtent au même marché très concurrentiel : LangGraph, Google ADK, l’OpenAI Agents SDK, PydanticAI, CrewAI, AutoGen, LlamaIndex, ainsi que probablement un autre framework apparu pendant que cette liste était rédigée. La question qui vient naturellement à l’esprit est de savoir lequel est le meilleur, mais c’est là une mauvaise approche. Une question plus pertinente est de déterminer où le framework doit prendre les décisions et où l’application doit conserver le contrôle.

Posée de cette manière, la comparaison entre LangGraph et le Google Agent Development Kit (ADK) devient plus intéressante en 2026 que ne le suggère l’ancien slogan « graphes contre agents ». Les deux permettent de créer des agents sophistiqués. Ce qui les distingue, c’est l’endroit où réside le contrôle, les fonctionnalités préinstallées par défaut et le niveau de complexité d’orchestration que l’équipe doit gérer.

Les deux frameworks convergent

Les comparaisons anciennes dessinent une ligne de démarcation claire : LangGraph s’agit d’une orchestration de graphes de bas niveau, tandis qu’ADK est un cadre multi-agents de niveau supérieur. Cela reste partiellement vrai, mais cela omet beaucoup de détails.

LangGraph est organisé autour de nœuds explicites, d’états, de transitions, de mécanismes de persistance, de tentatives de réexécution et d’un contrôle précis de l’exécution. Sa conception repose fortement sur une exécution fiable, des flux avec intervention humaine, une gestion des états et une orchestration détaillée.

ADK couvre désormais également plusieurs styles d’orchestration :

• flux de travail basés sur des graphes
• flux de travail dynamiques
• flux de travail collaboratifs multi-agents
• nœuds d’exécution déterministes
• délégation pilotée par des agents

Dans ADK 2.x, un graphe peut combiner des agents LLM, des fonctions simples, des outils, une logique de routage, un état et des entrées humaines. Ainsi, le choix ne se porte plus entre un graphe et des agents, car chaque framework peut gérer les deux. Ce qui diffère, c’est la manière dont le système est construit.

Comment LangGraph fonctionne

LangGraph est d’abord perçu comme un moteur d’orchestration. La conception commence par une série de questions : quel est l’état ? Qu’est-ce qui le modifie ? Où peut se diriger l’exécution ensuite ? En termes visuels, le flux s’organise comme ceci :

State
  ↓
Node
  ↓
Decision
 ↙   ↘
A     B
↓     ↓
Tool  Agent
 \     /
  ↓   ↓
 Validation
     ↓
    End

Le graphique présenté ici ne se limite pas à la gestion des canalisations ; il fait partie de l’architecture, ce qui s’avère avantageux lorsque le système contient une logique métier déterministe importante. Un flux de travail peut avoir besoin de :

• pause et attendre que quelqu’un approuve quelque chose
• reessayer une opération qui a échoué
• se remettre en marche après une panne d’outil
• reprendre depuis un état persisté
• diviser le flux en branches en fonction de données structurées
• exécuter du code ordinaire entre les appels aux modèles
• conserver l’état au cours de tâches longues

LangGraph rend chacun de ces aspects explicite, ce qui constitue un modèle solide. Le inconvénient est que l’équipe doit assumer une plus grande responsabilité dans la conception de l’orchestration.

La façon de penser d’ADK

ADK se rapproche davantage d’un framework d’applications d’agents. Plutôt que de partir d’une machine à états, la conception peut commencer par des agents :

Coordinator
├── Specialist Agent
├── Specialist Agent
├── Specialist Agent
└── Specialist Agent

Chaque agent peut posséder ses propres instructions, outils, responsabilités, limites, sous-agents et paramètres de modèle. Le cadre propose alors plusieurs méthodes de coordination. Un système assez autonome peut confier le travail aux spécialistes via un coordinateur. Un processus prévisible peut faire appel à l’orchestration graphique. Les tâches plus faciles à exprimer en code peuvent utiliser des workflows dynamiques.

Ce qui est attrayant dans les ADK modernes, c’est qu’ils offrent des abstractions d’agents bien définies sans exiger que chaque étape soit gérée par un LLM. Lorsque la fiabilité l’exige, l’exécution peut reposer sur du code déterministe.

La question centrale : qui contrôle le workflow ?

C’est probablement la première chose à déterminer lors du choix entre les deux approches. Pensez à deux extrêmes.

Principalement déterministe

Le processus est déjà connu, étape par étape :

Receive request
→ validate
→ retrieve information
→ classify
→ call service
→ validate result
→ human approval if necessary
→ respond

Le modèle ajoute de l’intelligence au sein du processus, tandis que l’application gère le processus lui-même. Cela correspond à la manière dont LangGraph incite les développeurs à penser, et les workflows graphiques ADK peuvent désormais modéliser le même style.

Principalement piloté par des agents

Ici, l’objectif est connu, mais l’ordre des étapes ne l’est pas :

User goal
   ↓
Coordinator
   ↓
Which specialist is needed?
   ↓
Delegate
   ↓
Maybe call another specialist
   ↓
Synthesize

Dans ce cas, la coordination est en partie sémantique, et le modèle multi-agent collaboratif d’ADK s’y adapte naturellement. LangGraph peut également mettre en œuvre ce schéma. Les capacités ne font aucun doute. Ce qui compte, c’est de déterminer quelle abstraction correspond le mieux à l’architecture déjà envisagée.

Le point fort de LangGraph : l’état explicite

L’état semble peu intéressant tant qu’un agent n’entre pas en production, mais il devient alors l’un des éléments les plus importants du système. Les opérateurs ont besoin de réponses à des questions telles que celles-ci :

What has already happened?What did the previous agent produce?Which tools were executed?What has been validated?What still needs approval?Where should execution resume?What should the next node actually see?

LangGraph conserve l’état partagé au cœur même de son modèle de programmation, ce qui rend les transitions visibles. Il encourage également une discipline utile : conserver un état structuré plutôt que de tout entasser dans un prompt géant supplémentaire. L’état de l’application et le contexte du modèle ne devraient pas être automatiquement identiques, et cette différence s’accentue à mesure que les systèmes d’agents se développent.

La force d’ADK : composer des agents

La meilleure abstraction d’ADK réside dans la facilité avec laquelle des agents spécialisés deviennent des blocs de construction. Au lieu d’un seul agent géant doté d’un prompt système volumineux, les responsabilités sont séparées :

                Coordinator
                      │
        ┌─────────────┼─────────────┐
        ↓             ↓             ↓
    Research       Domain        Action
     Agent          Agent         Agent
        │             │             │
        └─────────────┼─────────────┘
                      ↓
                  Validation

Cela est important car la conception multi-agents ne devrait pas signifier créer davantage d’agents. Elle devrait plutôt impliquer l’établissement de limites significatives. Un spécialiste mérite d’exister lorsque l’isolation de son contexte, de ses outils, de ses permissions, de ses responsabilités, de son modèle ou de ses critères d’évaluation permet d’obtenir une architecture meilleure. Sans cela, un autre agent n’est qu’une autre appel de modèle portant un nom ingénieux.

Plus d’agents ne signifie pas un système meilleur

Une erreur très courante consiste à supposer cette logique arithmétique :

1 agent = simple
5 agents = sophisticated
20 agents = extremely sophisticated

C’est pas comme ça que ça fonctionne. Chaque agent supplémentaire peut entraîner une autre requête vers le modèle, un autre prompt, un autre contexte, un autre transfert de responsabilités, une autre façon d’échouer, une autre limite d’évaluation, plus de latence, plus de tokens et plus de tâches de débogage.

Avant d’en ajouter un, demandez quelle capacité s’améliore réellement, car cette responsabilité doit être isolée. Des raisons solides incluent un ensemble d’outils distinct, des permissions de sécurité plus strictes, un contexte séparé, un modèle différent, une évaluation indépendante, une spécialisation réutilisable ou des tâches pouvant être exécutées en parallèle. L’affirmation « L’architecture multi-agent semble meilleure » ne doit pas figurer sur cette liste.

Le point clé

Le cadre le plus utile n’est pas celui qui oppose graphes et agents. Il s’agit plutôt de l’orchestration explicite contre la composition centrée sur les agents. LangGraph part du flux de travail, de son état ainsi que des mécanismes de contrôle qui le entourent. ADK, quant à lui, part des agents qui utilisent des outils et coopèrent, en y ajoutant progressivement des fonctionnalités explicites de flux de travail. Une fois l’un ou l’autre système mis en production, les questions suivantes portent sur l’ingénierie du contexte, les contrats, l’exécution avec intervention humaine, l’observabilité et l’évaluation.