L’écart entre penser et faire
Chaque architecture d’agent IA moderne suit le même schéma : un modèle de langage raisonne sur ce qu’il faut faire, puis une couche d’exécution le fait. Le problème est que la plupart des équipes traitent la couche d’exécution comme un simple wrapper — un dispatcher de fonctions basique. C’est une erreur architecturale fondamentale qui mène au non-déterminisme, à la dérive et à l’échec à grande échelle.
Considérez ce qui se passe quand un LLM décide de déployer un service. Le modèle produit quelque chose comme {"action": "deploy", "target": "prod", "version": "2.4.1"}. Dans une implémentation naïve, cela est dispatché directement vers votre système de déploiement. Mais qu’est-ce qui valide que cette séquence est sûre ? Qu’est-ce qui garantit que le modèle n’a pas sauté l’étape de staging ?
Pourquoi les wrappers fins échouent
L’approche wrapper fin traite l’exécution des agents comme une API REST : requête en entrée, action en sortie. Mais les exécutions des agents ne sont pas des requêtes individuelles — ce sont des graphes acycliques dirigés (DAG) d’opérations dépendantes. Chaque étape peut produire des effets de bord qui contraignent ce qui peut se passer ensuite.
Quand vous laissez un LLM orchestrer directement ces dépendances, vous héritez de tout le non-déterminisme du modèle. Le modèle peut choisir des ordres différents d’un run à l’autre. Il peut halluciner des étapes intermédiaires. Il peut ignorer la validation parce que ses données d’entraînement incluaient des exemples où la validation était optionnelle.
Le LLM doit décider quoi faire. Un plan de contrôle déterministe doit décider comment le faire, dans quel ordre, avec quelles validations.
Les graphes d’exécution comme citoyens de première classe
La solution consiste à modéliser les exécutions des agents comme des graphes explicites. Chaque noeud représente une action atomique avec des entrées, sorties, préconditions et postconditions définies. Les arêtes représentent le flux de données et les contraintes de dépendance.
Ce n’est pas un concept nouveau en ingénierie système. Les contrôleurs Kubernetes, les plans Terraform et les gestionnaires de transactions de bases de données implémentent tous exactement ce pattern. L’innovation est de l’appliquer au domaine des agents IA, où le « contrôleur » est un LLM qui produit des plans avec une incertitude inhérente.
Le pattern du plan de contrôle
Un plan de contrôle agent adéquat fournit trois garanties qu’un simple wrapper ne peut pas offrir :
- ✓ Validité structurelle — Le plan d’exécution doit former un DAG valide. Pas de cycles, pas de dépendances manquantes.
- ✓ Validité sémantique — Les préconditions de chaque étape doivent être satisfaites par les sorties de ses prédécesseurs.
- ✓ Fidélité d’exécution — Une fois validé, le graphe s’exécute identiquement à chaque fois. C’est ce qui rend le replay possible.
Sans ces garanties, vous n’avez pas un système agent. Vous avez un chatbot avec un terminal. La distinction compte quand votre agent gère de l’infrastructure de production ou traite des transactions financières.
Implications pour l’architecture agent
Adopter un pattern de plan de contrôle change fondamentalement la façon dont vous construisez des systèmes agents. Le rôle du LLM se réduit à l’extraction d’intent et la proposition de plan. Le plan de contrôle gère la validation, l’ordonnancement, l’exécution, le rollback et l’observabilité.
Surtout, cela rend votre système agent auditable. Chaque exécution produit une trace complète. Dans les industries réglementées, ce n’est pas optionnel — c’est le prix d’entrée.