Pourquoi Claude 4.6 ne suffit pas sans contexte : l'angle mort du développement avec les LLM

Un LLM puissant ne rattrape pas une mauvaise entrée : si l'agent ne voit qu'un fragment de code, et non l'architecture, les dépendances et les règles de l'environnement, les erreurs deviennent presque inévitables. Un développeur passé presque entièrement au codage assisté par IA avec Cursor et Claude 4.6 explique pourquoi le contexte s'est révélé plus important que le choix entre les modèles.

Ce n'est pas le modèle, c'est le contexte

Dans le développement avec les LLM, il est facile de s'enfermer dans la comparaison entre GPT, Claude et Gemini et dans le peaufinage des prompts. Mais en pratique, le gain vient souvent non d'un changement de modèle, mais de la quantité d'informations utiles que l'agent reçoit avant sa première action. Si le contexte comprend la structure des services, les contraintes de l'infrastructure, les bibliothèques partagées, les conventions de l'équipe et les décisions passées, le modèle agit comme un ingénieur qui a déjà travaillé sur le projet. Sinon, même un agent puissant se met à deviner, et en production, les approximations coûtent cher.

L'auteur est catégorique : l'écart entre un « agent avec contexte » et un « agent sans contexte » ne se mesure pas en pourcentages de qualité, mais en conséquences. L'un boucle la tâche en quelques minutes ; l'autre perd une heure, casse des services voisins et finit par un retour en arrière. Pour un développeur solo avec des dizaines de microservices et d'hôtes, ce n'est pas un risque théorique, mais un problème opérationnel quotidien. Ici, l'IA ne travaille pas dans un bac à sable, mais dans un système vivant, où la moindre erreur touche aussitôt d'autres composants.

«

La différence, c'est le chemin entre une solution en cinq minutes et une heure d'erreurs et de retours en arrière. »

Comment les agents se brisent

Quand l'IA écrit du code de façon presque autonome, voir uniquement le fichier courant ne lui suffit pas. Dans les systèmes réels, la logique est dispersée entre dépôts, configurations, infrastructure et règles informelles. Un agent peut réécrire correctement une fonction tout en cassant une intégration, parce qu'il ignore une ancienne dépendance, un réglage inhabituel de l'hôte ou une convention documentée nulle part de façon explicite. Plus le système ressemble à un écosystème vivant, plus l'absence de ce savoir coûte cher.

• liens entre microservices et ordre de déploiement
• particularités des bibliothèques partagées et contrats d'API internes
• limites du matériel, des machines virtuelles et de l'environnement local
• règles de test, de vérification manuelle et de retour en arrière

C'est pourquoi l'auteur organise son travail autour d'une base de connaissances plutôt que d'un seul prompt réussi. Le but est que l'agent voie non seulement le code, mais aussi une carte du système : ce qui est relié à quoi, où se trouvent les points faibles, quelles décisions ont déjà été prises et quelles contraintes ne doivent pas être violées. Un bon prompt aide à poser la tâche, mais ne remplace pas la mémoire du projet. Sans elle, le LLM reste un exécutant rapide mais myope, qui peut avancer avec assurance dans la mauvaise direction.

Une couche système de connaissances

L'approche a été éprouvée sur Claude 4.6 Opus, avec une fenêtre de contexte pouvant atteindre un million de tokens. C'est une réserve importante : la méthode dépend non seulement de la qualité des descriptions, mais aussi de la capacité du modèle à retenir physiquement un grand volume d'informations et à en dégager l'essentiel. Une petite fenêtre de contexte coupera la moitié des informations utiles, et une analyse faible se noiera dans le bruit même avec un bon corpus de documents. Dans ce schéma, la taille du contexte devient une partie de l'outil, et non un chiffre flatteur dans une annonce de version.

La conclusion pratique est simple : il faut construire le contexte comme une couche distincte du système. Elle comprend des notes d'architecture, la description des services, la liste des dépendances, l'organisation des environnements, les scénarios de test types et les règles pour des modifications sûres. Mieux cette couche est organisée, plus l'agent d'IA se rapproche d'un véritable partenaire technique : il ne se contente pas de générer du code, il comprend où ce code s'insère et ce qu'il peut affecter. Autrement dit, la documentation se met à fonctionner comme une interface pour le modèle.

Cela se voit surtout dans le mode où le développeur formule d'abord la tâche, discute ensuite du plan d'architecture avec l'agent, puis le modèle écrit le code et les tests, lance lui-même les vérifications et corrige les erreurs trouvées. Cette orchestration ne fonctionne que si l'agent dispose de la vue d'ensemble du projet. Sinon, l'automatisation accélère non pas le développement, mais la propagation des mauvaises décisions. Plus on confie d'actions au modèle, plus chaque lacune de connaissances coûte cher.

Ce que cela signifie

Le marché du codage assisté par IA passe peu à peu de la course aux modèles à la course au contexte de qualité. Pour les développeurs et les équipes, cela veut dire que le prochain grand gain de productivité viendra non d'un nouveau prompt, mais d'une base de connaissances du projet bien construite. Les gagnants ne seront pas ceux qui disposent simplement d'un LLM plus puissant, mais ceux qui lui apprendront à voir le système dans son ensemble. C'est là qu'apparaît aujourd'hui le véritable avantage concurrentiel.