Contexte technique
Je ne m'attarde pas sur le débat lui-même mais sur une faille architecturale : l'orchestrateur génère un sous-agent, et celui-ci traîne le modèle parent sans commutateur natif. Pour l'automatisation IA, c'est une mauvaise nouvelle, car même un outil simple se met soudainement à tourner sur un modèle coûteux là où une classe mini aurait suffi.
C'est là que j'arrête généralement le projet et plonge dans les mécaniques. Si un outil n'a pas de paramètres de sélection de modèle, aucune belle instruction dans le prompt ne se transforme en véritable routage. Un agent peut « savoir » qu'il faut économiser, mais techniquement, il n'y a rien à choisir.
D'après ce qui ressort de la discussion, le problème n'est pas la qualité du modèle en soi, mais l'absence d'une couche de gestion de configuration lors de la création des sous-agents. C'est une différence importante. Quand la sélection de modèle n'existe qu'au niveau du parent, l'enfant devient une copie coûteuse au lieu d'un exécutant spécialisé.
Je teste généralement ces choses de manière très pragmatique : je prends un même scénario où l'orchestrateur décide si une recherche, un résumé ou une mise en forme est nécessaire, et j'observe quels appels partent vraiment vers l'API. Si chaque étape enfant part sur un modèle lourd, les tokens brûlent non pas parce que la tâche est complexe, mais parce que l'intégration IA est faite sans routage correct.
Chercher dans la documentation ouverte n'aide pas beaucoup, honnêtement : les présentations générales de LangChain, AutoGen et CrewAI parlent beaucoup de flexibilité, mais n'offrent presque jamais de réponse concrète sur la manière d'éviter cet héritage en production réelle. Il faut donc regarder non pas le marketing du framework, mais le code d'initialisation de l'agent, le binding de modèle au niveau du nœud et les fabriques de sous-agents.
Ce que cela change pour les entreprises et l'automatisation
Le premier impact est évident : le budget. Si le support, la recherche et la validation passent tous par un seul modèle lourd, le coût du pipeline augmente sans bénéfice.
Le deuxième impact est plus discret mais plus douloureux : vous perdez en prévisibilité. Impossible de calculer correctement l'économie unitaire si les sous-agents ne peuvent pas basculer entre un mode économique et un mode puissant selon la tâche.
Ceux qui construisent des solutions IA pour les entreprises avec un contrôle explicite des modèles à chaque nœud gagneront. Les équipes qui croient que l'orchestrateur « comprendra bien tout seul » et optimisera les coûts sans paramètres perdront.
Chez Nahornyi AI Lab, nous nettoyons précisément ces goulets d'étranglement : nous décomposons l'orchestration par rôles, mettons en place un routage explicite des modèles et supprimons les dévoreurs cachés de tokens. Si votre implémentation IA fonctionne déjà mais que les factures augmentent plus vite que les bénéfices, examinons ensemble le graphe d'appels et construisons une automatisation IA où le système réfléchit là où c'est nécessaire, pas à chaque éternuement.