LangGraph vs chaînes classiques : quand l’orchestration devient nécessaire

Il y a une tentation, dès qu’on découvre LangGraph, de tout modéliser comme un graphe d’état. Ce n’est pas toujours la bonne réponse — une chaîne linéaire (prompt → modèle → parsing) reste plus simple à lire, tester et déboguer.

Le signal qui justifie un graphe

Le vrai signal n’est pas « le projet est complexe », c’est plus précis que ça : est-ce que le nombre d’étapes ou leur ordre dépend du résultat d’une étape précédente ?

• Si la réponse est non — la séquence est toujours la même — une chaîne suffit, même avec plusieurs étapes.
• Si la réponse est oui — un agent doit parfois relire, parfois chercher une source supplémentaire, parfois s’arrêter tôt — c’est le signal qu’il faut un graphe d’état plutôt qu’une séquence figée.

Un exemple concret

Dans OZONE-AID, le copilote de diagnostic suit ce schéma : classifier la panne, chercher dans la documentation technique, puis soit proposer un diagnostic, soit demander une information complémentaire au mécanicien avant de continuer. Cette branche conditionnelle est exactement le genre de logique qu’une chaîne linéaire gère mal — elle finit par se transformer en un enchaînement de if autour d’appels au modèle, ce qu’un graphe d’état exprime nativement :

graph.add_conditional_edges(
    "diagnose",
    lambda state: "ask_more_info" if state["confidence"] < 0.6 else "propose_fix",
)

Ce que ça coûte

L’orchestration a un coût réel : plus de surface pour les bugs d’état, un débogage moins linéaire, et une courbe d’apprentissage pour l’équipe. Pour un simple résumé de document ou une extraction structurée, une chaîne classique reste le bon choix — et souvent plus rapide à livrer.