La Bitter Lesson appliquée aux agents IA

En 2019, Rich Sutton publiait "The Bitter Lesson" — un essai qui tient en une phrase : les méthodes qui exploitent la puissance de calcul brute finissent toujours par battre celles qui encodent de la connaissance humaine. Sept ans plus tard, cette leçon s'applique parfaitement aux agents IA.

La leçon originale

Sutton observait un pattern récurrent dans 70 ans de recherche en IA : les chercheurs construisent des systèmes experts bourrés de règles humaines. Ces systèmes marchent bien au début. Puis arrive une approche "stupide" qui utilise simplement plus de calcul et de données — et elle écrase tout.

Les échecs : Deep Blue (force brute) a battu les moteurs à heuristiques humaines. La reconnaissance vocale : les modèles statistiques ont écrasé les systèmes à règles linguistiques. La vision : les réseaux de neurones ont rendu obsolètes les détecteurs de features manuels.

La leçon amère : les chercheurs humains surestiment toujours la valeur de leur expertise encodée.

Le cas Vercel : la preuve par l'expérience

L'équipe Vercel a construit un agent Text-to-SQL. Première version : des dizaines d'outils spécialisés. Un outil pour lire le schéma, un pour valider la syntaxe SQL, un pour gérer les erreurs, un pour formatter les résultats. Résultat : 80% de réussite.

Deuxième version : ils ont supprimé 80% des outils. Il ne reste que trois capacités fondamentales — lire des fichiers, exécuter du bash, chercher du texte. L'agent doit se débrouiller avec ça.

Résultat de la version simplifiée :

• 100% de réussite (contre 80%)
• 3.5x plus rapide
• 40% moins de tokens consommés

Pourquoi ? Parce que chaque outil spécialisé est une contrainte. L'agent doit apprendre quand utiliser quel outil, dans quel ordre, avec quels paramètres. Plus il y a d'outils, plus il y a de décisions à prendre, plus il y a d'erreurs possibles.

Le principe ROI de Manus

Manus (racheté par Meta en 2025) a formalisé cette idée en trois règles :

• Reduce — Réduire le contexte au strict nécessaire. Ne pas donner 50 pages de documentation quand 5 lignes suffisent.
• Offload — Décharger la mémoire sur le système de fichiers. L'agent écrit ses avancées dans un todo.md au lieu de tout garder en contexte.
• Isolate — Isoler les sous-tâches. Une recherche web complexe est déléguée à un sous-agent qui ne renvoie qu'un résumé de 200 mots.

Claude Code : 4 outils pour tout faire

L'approche d'Anthropic avec Claude Code est le cas le plus radical. L'agent n'a que quatre outils : Read, Write, Edit, Bash. Pas de framework, pas d'orchestrateur, pas de plugin system.

Avec ces quatre outils, il peut : lire n'importe quel fichier, modifier du code, exécuter des commandes, lancer des tests, installer des dépendances, déployer. Tout ce qu'un développeur fait dans un terminal, l'agent le fait aussi.

La puissance vient du modèle (Opus 4.6), pas de l'architecture autour. C'est la Bitter Lesson en action : investir dans le "moteur" plutôt que dans le "châssis".

Conseils pratiques

1. Le filesystem comme mémoire — Arrêtez d'essayer de tout mettre dans le prompt. Écrivez l'état dans un fichier, relisez-le quand nécessaire. Un fichier state.json de 2KB remplace 50K tokens de contexte.
2. Le pattern progress.md — Forcez votre agent à maintenir un fichier de progression. Au début de chaque action, il lit le fichier. À la fin, il le met à jour. Si l'agent plante et redémarre, il sait exactement où il en était.
3. Isoler les sous-tâches — Ne donnez pas une tâche de 15 étapes à un seul agent. Découpez en 3-4 sous-tâches indépendantes. Chaque sous-agent a un scope limité et renvoie un résultat concis.
4. Résister à l'envie d'ajouter — Quand un agent échoue, le réflexe est d'ajouter un outil, un garde-fou, une règle. Résistez. Essayez d'abord de simplifier. Souvent, le problème est que l'agent a trop de choix, pas pas assez.

La contre-leçon

Attention : la Bitter Lesson ne dit pas "ne réfléchissez jamais". Elle dit que les gains d'ingénierie manuelle sont temporaires face à l'augmentation de puissance de calcul. En pratique, un minimum de structure est nécessaire — des garde-fous de sécurité, des limites de budget, une boucle de feedback. L'art est de trouver le minimum viable d'architecture qui laisse le modèle faire ce qu'il fait de mieux.