25 juillet 2026

Je suis tombé sur un tweet de Andrej Karpathy qui m’a fait réfléchir sur quand commencer à orchestrer des agents (la plupart du temps c’est prématuré)

Lorsque Andrej Karpathy parle de « understand the model underneath first », il ne dit pas qu’il faut connaître les équations des transformeurs ou être chercheur en IA. Il veut dire qu’avant de construire des agents sophistiqués, il faut comprendre ce que sait réellement faire un LLM, ses limites et la manière de le piloter efficacement.

En d’autres termes, il faut maîtriser le modèle de base avant de construire une architecture complexe autour de lui.

1. Comprendre ce qu’un LLM sait faire naturellement

Un modèle de langage moderne est déjà capable de nombreuses tâches sans nécessiter d’agent :

• Résumer un document.
• Écrire du code.
• Expliquer un concept.
• Transformer un texte.
• Extraire des informations.
• Planifier une suite d’actions.
• Générer du contenu structuré.

Beaucoup de développeurs créent aujourd’hui des architectures comportant plusieurs agents, alors qu’un simple prompt bien conçu adressé à GPT-5 ou Claude permettrait d’obtenir le même résultat. ET je ne vous dis pas ce que ça vous coûte en tokens !

L’objectif est donc de connaître les capacités natives du modèle avant d’ajouter des couches de complexité.

2. Connaître les limites du modèle LLM

Un bon développeur d’agents doit également connaître les faiblesses du modèle.

Par exemple :

• Il peut halluciner lorsqu’il manque d’informations.
• Il oublie progressivement une partie du contexte lorsque celui-ci devient très long.
• Il est sensible à la formulation des instructions.
• Certains modèles sont meilleurs pour le raisonnement, d’autres pour le code ou la rédaction.
• Les performances évoluent fortement d’une version à l’autre.

Très souvent, lorsque l’on pense que « l’agent fonctionne mal », le véritable problème provient du modèle sous-jacent.

3. Savoir guider le modèle

Avant d’investir du temps dans un framework d’agents, il est essentiel de maîtriser les techniques permettant d’exploiter pleinement un LLM.

Parmi elles :

• Le prompt engineering.
• Les instructions système.
• Les sorties structurées (JSON, XML…).
• Le few-shot prompting.
• Le function calling.
• La gestion du contexte.
• Les techniques de raisonnement lorsqu’elles sont appropriées.

Selon Karpathy, une bonne maîtrise de ces mécanismes permet déjà de résoudre une très grande partie des problèmes rencontrés.

4. Comprendre le coût réel des agents

Un agent complexe peut facilement exécuter une séquence comme celle-ci :

Dans certains cas, un prompt mieux conçu permettrait d’obtenir le même résultat en un ou deux appels seulement.

Avant d’ajouter des agents, il est donc important de se demander si la tâche nécessite réellement une orchestration complexe.

5. Comprendre les capacités émergentes

L’un des messages importants de Karpathy est que les capacités des modèles progressent très rapidement.

Ce qui nécessitait plusieurs agents hier peut devenir une simple capacité native demain.

Par exemple :

En 2023 voilà comment fonctionnait un LLM

Les progrès du modèle rendent progressivement inutiles certaines architectures multi-agents qui semblaient indispensables auparavant.

Pourquoi Karpathy évoque-t-il OpenAI ?

Il fait référence à une tendance observée dans les débuts de la recherche en IA.

À cette époque, beaucoup d’efforts étaient consacrés à la construction de systèmes complexes :

• planificateurs ;
• orchestrateurs ;
• mémoires sophistiquées ;
• architectures d’agents.

Or les plus grandes avancées sont finalement venues de l’amélioration du modèle fondamental :

• davantage de données ;
• davantage de puissance de calcul ;
• meilleure architecture (Transformer) ;
• meilleures méthodes d’entraînement ;
• lois de scaling.

Une fois le modèle devenu suffisamment performant, une grande partie des mécanismes complexes n’était plus nécessaire.

Et c’est exactement en phase avec ce que je dis plus haut au début de cet article. Quand vous n’avez pas encore exploité à fond un LLM, c’est pas la peine de faire des orchestrations inutilement.OpenAI, à très tôt, avant d’avoir pu exploiter à fond un LLM, ce qui est normal puisque les LLM n’étaient encore perfectibles. Ils avaient commencé à faire des orchestrations d’agents en voulant améliorer les résultats mais en fait ils sont allés dans des complications vraiment très grandes.

De cette expérience, il en a tiré qu’il faut exploiter un LLM jusqu’au bout. Et c’est seulement quand il montre ses limites que vous allez vers l’orchestration d’agents. Pas avant.

Alors développeur quand allez vous faire de l’orchestration comme tonton Boris?

Les frameworks d’agents deviennent réellement intéressants lorsque le problème nécessite :

• des tâches longues ;
• plusieurs outils externes ;
• une mémoire persistante ;
• une orchestration complexe ;
• des validations indépendantes ;
• des processus asynchrones.

Conclusion

Un agent n’est qu’une couche d’orchestration autour d’un LLM.

Si le modèle est mal compris ou mal exploité, ajouter davantage d’agents ne fera qu’augmenter la complexité, les coûts et les risques d’erreur.

À l’inverse, lorsqu’on maîtrise parfaitement les capacités du modèle sous-jacent, il devient beaucoup plus facile de savoir quand un agent est réellement nécessaire et quand un simple appel au LLM est largement suffisant.

Je trouve que le terme de prompt engineer n’est finalement pas si futile que ça !