L'agent n'est pas devenu plus intelligent — c'est le projet qui a changé

Il y a six mois, une tâche de programmation nécessitait une session entière d’explications. La semaine dernière, le même type de tâche a tenu en une seule phrase. Le modèle n’a pas changé entre ces deux sessions. Claude Opus 4.6 a servi les deux. Mêmes poids, même architecture, même fenêtre de contexte, mêmes capacités.

L’agent IA n’est pas devenu plus intelligent entre la session 1 et la session 500 ; c’est l’infrastructure du projet qui a changé. C’est l’affirmation centrale du territoire de l’ingénierie de l’IA : le modèle est une constante, et la variable, c’est tout ce que vous construisez autour de lui. Sur des projets de longue haleine, le modèle contribue environ à 30 % de la qualité des sessions, tandis que le contexte accumulé fournit les 70 % restants : documents de conventions, mémoires de décisions, artefacts de passation, hooks, skills et couverture de tests. Un modèle moins performant sur un projet riche surpasse souvent un meilleur modèle sur un projet dénudé.

C’est le projet qui a changé.

La mauvaise conversation

La conversation sur la productivité de l’IA porte presque exclusivement sur les capacités des modèles. Quel modèle est le plus rapide. Quel modèle écrit le meilleur code. Quel modèle gère le contexte le plus long. L’hypothèse implicite, c’est que le modèle est la variable : mettez à niveau le modèle, améliorez la sortie.

Cette hypothèse est fausse pour les projets de longue haleine. Sur un projet sur lequel je travaille depuis six mois, avec plus de 500 sessions d’agent, le modèle contribue peut-être à 30 % de la qualité des sessions. Les 70 % restants proviennent de l’infrastructure de projet accumulée : documents de conventions, mémoires de décisions, artefacts de passation, hooks comportementaux, skills codifiées et couverture de tests.

Un meilleur modèle sur un projet dénudé produit une meilleure sortie qu’un modèle moins performant sur un projet dénudé. Un modèle moins performant sur un projet avec 500 sessions de contexte accumulé produit souvent une meilleure sortie qu’un meilleur modèle sur un projet dénudé. L’infrastructure domine le modèle. C’est pour cette raison que le contexte est une architecture — la connaissance accumulée du projet n’est pas une information supplémentaire mais une structure porteuse.

Les preuves

Le correctif de performance de la page marché illustre ce point. Une seule phrase : « corrige la performance de la page marché ». L’agent a :

Lu un document de passation d’une session précédente qui diagnostiquait le goulet d’étranglement
Identifié le bon chemin de code (market_hub(), et non _fetch_market_data())
Implémenté une requête de base de données paginée avec un RPC d’agrégation
Écrit des tests
Déployé

Austin est passée de 14 secondes à 108 millisecondes. Une amélioration de 132× à partir d’une seule instruction.¹

Cela ne s’est pas produit parce que le modèle est intelligent. Cela s’est produit parce que le document de passation existait. La passation a saisi un diagnostic qui a survécu à trois corrections de revue de code et à deux réorganisations de priorités sur quatre jours. Sans la passation, l’agent serait parti de zéro. Il aurait enquêté sur le mauvais chemin de code (comme l’avait fait la première version de la passation). Il aurait proposé des partiels HTMX inutiles (comme le faisait le plan initial). La passation contenait les erreurs déjà commises et corrigées. L’agent a hérité de la compréhension corrigée.

La contribution du modèle a été de lire la passation et d’implémenter le correctif. La contribution de l’infrastructure a été de disposer de la bonne passation à lire.

Ce qui change et ce qui ne change pas

Entre la session 1 et la session 500 sur le même projet, une seule chose reste constante : le modèle. Tout le reste change.

Ce qui change :

Le CLAUDE.md passe de vide à complet. Les questions de conventions disparaissent. L’article sur les patterns AGENTS.md décrit les patterns spécifiques qui rendent ces fichiers efficaces.
Les fichiers de mémoire s’accumulent. Les décisions sont mises en cache. Les compromis sont consignés. Le projet cesse de rejuger les questions déjà tranchées.
Les hooks s’accumulent. Chacun empêche une catégorie d’échec survenue lors d’une session précédente. 84 hooks interceptent 15 des 26 types d’événements de cycle de vie que Claude Code expose, chacun étant la cicatrice d’un incident passé.
Les skills s’accumulent. Les workflows répétitifs deviennent des opérations à une seule commande. Le nightcheck qui avait demandé une session entière de conception s’exécute désormais en 2 minutes.
Les tests s’accumulent. L’agent effectue des modifications plus audacieuses parce qu’il peut les vérifier immédiatement.
Les documents de passation s’accumulent. Les investigations complexes persistent au-delà des frontières de session.

Ce qui reste identique :

Le modèle. Mêmes poids. Mêmes capacités. Même tendance à dériver hors tâche, à vérifier fantomatiquement les résultats de tests (voir la porte des preuves) et à proposer des abstractions inutiles.

Les modes de défaillance du modèle sont constants. La capacité de l’infrastructure à attraper ces modes de défaillance croît à chaque session. La session 500 est meilleure que la session 1 non pas parce que le modèle s’est amélioré, mais parce que l’infrastructure a appris à compenser les faiblesses constantes du modèle.

Le cadre de l’investissement

Si le modèle n’est pas la variable, alors le choix du modèle n’est pas la principale décision d’investissement. L’investissement principal porte sur l’infrastructure de contexte.

Une équipe qui dépense 200 $/mois pour Claude Max (qui fait tourner Opus 4.7 par défaut) et qui investit massivement dans les fichiers CLAUDE.md, les systèmes de mémoire, les hooks, les skills et la couverture de tests surpassera une équipe qui dépense 200 $/mois pour le même plan sans investissement en infrastructure. Le coût du modèle est identique. La qualité de sortie diverge parce que l’infrastructure diverge.

Cela recadre la question de la productivité. La question n’est pas « quel modèle devrions-nous utiliser ? » La question est « qu’avons-nous construit autour du modèle qui rend chaque session meilleure que la précédente ? »

Les organisations que je vois en difficulté avec la productivité de l’IA n’utilisent pas le mauvais modèle. Elles démarrent chaque session de zéro. Pas de document de conventions. Pas de système de mémoire. Pas de hooks. Pas de skills. Pas de contexte accumulé. Chaque session est la session 1, quel que soit le nombre de sessions précédentes.

Le modèle va s’améliorer

Les modèles continueront de s’améliorer. Claude Opus 4.7 était meilleur que Claude Opus 4.6, Opus 5 sera encore meilleur. L’amélioration est réelle et précieuse. Mais l’amélioration est additive, pas multiplicative.

Un modèle qui est 20 % meilleur en génération de code produit une sortie 20 % meilleure sur un projet dénudé. Le même modèle avec 500 sessions de contexte accumulé produit une sortie qualitativement différente, pas seulement quantitativement meilleure. L’infrastructure de contexte n’ajoute pas 20 % à la capacité du modèle. Elle fournit le diagnostic, les contraintes, les critères de vérification et l’historique opérationnel que le modèle ne peut pas produire seul, quelle que soit sa capacité.

Aucun modèle, aussi capable soit-il, ne peut savoir que market_hub() charge toutes les lignes company_markets et pagine en Python à moins que quelque chose ne le lui dise. Le document de passation le lui dit. Le modèle lit et agit. L’intelligence est distribuée entre le modèle (lecture, raisonnement, implémentation) et l’infrastructure (connaissance, contrainte, vérification).

La session 500

Voici à quoi ressemble la session 500 : j’énonce ce que je veux en une seule phrase. L’architecture d’agent Ralph est le système qui rend cela possible. L’agent lit le CLAUDE.md et connaît les conventions. Il lit les fichiers de mémoire et connaît les décisions. Il lit la passation et connaît le diagnostic. Il rencontre un hook qui empêche la même erreur qu’un autre agent a commise il y a trois mois. Il vérifie son travail par rapport à la suite de tests. Il rend compte de l’achèvement avec des preuves pour chaque affirmation.

Voici à quoi ressemble la session 1 : j’explique le schéma de base de données, les conventions de routage, l’héritage de templates, la couche de cache, le pipeline de déploiement et les patterns de test. L’agent pose des questions de clarification. Il propose une approche qui viole trois conventions. Je la corrige. Il implémente le correctif. Il rapporte que « les tests passent » sans avoir exécuté pytest.

Le modèle est identique dans les deux sessions. Le projet, non.

FAQ

La qualité du modèle n’a-t-elle pas encore de l’importance ?

Si. Un modèle plus solide lit le contexte plus efficacement, raisonne plus précisément sur les compromis et implémente les solutions plus proprement. La qualité du modèle fixe le plancher. L’infrastructure élève le plafond. Sur un projet mature, le plafond compte davantage que le plancher.

Est-ce spécifique aux agents de programmation ?

Non. Tout workflow d’IA où le même domaine de tâches réapparaît au fil des sessions bénéficie du contexte accumulé. Rédaction, recherche, analyse, support client. L’infrastructure spécifique diffère (guides de style au lieu de CLAUDE.md, bases de connaissances au lieu de hooks), mais la dynamique est la même : le projet s’améliore parce que le contexte autour du modèle s’accumule.

Qu’en est-il des modèles multimodaux ou des modèles de raisonnement ?

Même principe. Un modèle de raisonnement qui peut réfléchir pendant 10 minutes à un problème doit encore savoir à quel problème réfléchir. Le document de passation, le fichier de conventions et le système de mémoire fournissent la définition du problème. Le modèle fournit le raisonnement. Un meilleur raisonnement sur un problème bien défini produit de meilleurs résultats qu’un raisonnement inférieur, mais un meilleur raisonnement sur un problème indéfini produit une confusion qui sonne mieux.

Par où commencer si je n’ai aucune infrastructure de contexte ?

Rédigez un fichier CLAUDE.md qui décrit les conventions de votre projet. Ce seul fichier est l’investissement au plus fort impact. Tout le reste se compose à partir de là.²

Sources

Blake Crosley, « Compound Context: Why AI Projects Get Better the Longer You Stay With Them », blakecrosley.com, mars 2026. ↩
Anthropic, « Manage Claude’s memory », Documentation Anthropic, 2026. ↩