Tu choisis ton outil de code IA en consultant le classement. SWE-bench Verified — un test standardisé où les modèles IA corrigent des bugs dans des projets Python open source — publie un joli tableau de scores, et chaque éditeur te le brandit sous le nez. Score plus élevé, meilleur outil. Simple, non ?

Sauf que des outils propulsés par des modèles quasi identiques donnent des résultats complètement différents sur ton vrai code. L'un gère un refacto sur trois fichiers sans broncher, l'autre hallucine un import qui n'existe pas. Le score dit qu'ils sont jumeaux. Ton lundi matin dit le contraire.

10 000 développeurs confirment que le classement ment

L'enquête AI Pulse de JetBrains est tombée ce mois-ci — plus de 10 000 développeurs professionnels, huit langages, des données terrain — et elle confirme ce que ton instinct savait déjà : la satisfaction des développeurs diverge radicalement entre des outils construits sur des modèles à une marge d'erreur près sur SWE-bench. Le benchmark affiche un match nul à trois. Les développeurs, eux, ne sont pas du tout d'accord.

Ce n'est pas une découverte. Dès février, OpenAI a signé l'acte de décès de SWE-bench Verified. L'autopsie : GPT-5.2, Claude Opus 4.5 et Gemini 3 Flash pouvaient reproduire mot pour mot les solutions gold-patch de mémoire — avec rien d'autre que l'identifiant de la tâche. Les modèles ne résolvaient pas de problèmes. Ils récitaient des réponses mémorisées. OpenAI a aussi audité 27,6 % des tâches échouées et découvert que 59,4 % avaient des tests défaillants qui rejetaient du code fonctionnellement correct. Le benchmark ne testait pas seulement la mémorisation — il marquait aussi les bonnes réponses comme fausses.

Le classement en direct au 13 avril 2026 confirme l'absurdité : Claude Opus 4.5 à 80,9 %, Opus 4.6 à 80,8 %, Gemini 3.1 Pro à 80,6 %. Trois modèles frontière à 0,3 points de pourcentage d'écart. Un match nul statistique déguisé en course hippique.

La variable que personne ne benchmarke

Si le score n'explique pas l'écart de satisfaction, qu'est-ce qui l'explique ? La stratégie de contexte — à quel point l'outil comprend réellement ton projet avant d'écrire la moindre ligne.

SWE-bench teste des corrections de bugs isolées dans des dépôts open source bien documentés. Toi, tu passes tes journées sur du développement multi-fichiers dans des codebases propriétaires bourrées de savoir tribal et de ce fameux fichier de config que Kévin a écrit en 2019 et que personne n'ose toucher. Voici comment chaque outil majeur aborde le problème — et où chacun craque :

Claude Code lit ton arborescence et tes fichiers CLAUDE.md — des documents texte brut où tu apprends à l'IA les conventions de ton projet, les patterns interdits et les décisions d'architecture. Il envoie le contenu complet des fichiers dans la fenêtre de contexte : du vrai code, pas des résumés. La limite : les fenêtres de contexte sont finies. Sur un monorepo de 50 000 fichiers, il ne peut pas tout charger en même temps et compte sur tes fichiers d'instructions pour lui indiquer ce qui compte. CLAUDE.md bâclé, résultats bâclés. L'outil est exactement aussi intelligent que la carte que tu lui dessines.

Cursor prend l'approche inverse. Sa fonctionnalité @Codebase construit un index vectoriel propriétaire — une base de données d'embeddings du sens sémantique de ton code. Quand tu fais une requête, il récupère les chunks les plus pertinents par recherche de similarité, naviguant dans de gros codebases sans tout charger en contexte. Le mode d'échec : les embeddings perdent les relations structurelles. Une fonction appelant trois helpers sur deux fichiers peut matcher sémantiquement, mais l'index rate la chaîne de dépendances. L'index a aussi du retard sur les modifications dans les gros projets — tu modifies un fichier, et pendant les minutes suivantes l'IA répond sur l'ancienne version.

GitHub Copilot utilise des Knowledge Bases sur le tier Enterprise (39 $/utilisateur/mois) — des dépôts indexés plus de la documentation que Copilot exploite pendant les complétion. Il peut croiser plusieurs dépôts, ce qui convient aux architectures microservices. Ce que personne ne dit : les tiers gratuit et Pro n'ont rien de tout ça. La plupart des développeurs individuels utilisent Copilot avec zéro contexte projet — juste le fichier ouvert et peut-être un onglet voisin. L'écart entre Copilot Enterprise et Copilot classique est plus grand que l'écart entre n'importe quels deux outils du classement.

Zed parse le code structurellement via Tree-sitter — il voit des arbres syntaxiques abstraits, pas des chaînes de texte. Il comprend nativement les portées, les frontières de fonctions et l'imbrication. Rapide et léger. Le compromis : la syntaxe sans la sémantique. Tree-sitter sait qu'une fonction existe et comment elle s'appelle, pas ce qu'elle fait ni pourquoi elle compte. Pour le boilerplate et les modifications mono-fichier : précis. Pour « comment le middleware d'auth affecte cet endpoint API trois packages plus loin ? » : dépassé.

Même tier de modèle. Compréhension de projet radicalement différente. Les données de satisfaction commencent à faire sens.

Simon Willison argumentait dès octobre 2025 que la meilleure stratégie de contexte n'est pas dans des fichiers d'instructions sophistiqués — c'est dans les fondamentaux barbants : des tests automatisés (il en fait tourner 1 500 dans un projet), des serveurs de dev interactifs, des Issues GitHub bien structurées. Traduction : écrivez des tests, bande de sauvages. La config de contexte la plus élaborée du monde ne sauvera pas du code qui n'a aucune suite de tests pour se vérifier lui-même. Il a raison de façon agaçante — mais ce n'est pas l'un ou l'autre. Une bonne stratégie de contexte plus une suite de tests solide, c'est ça qui fait boule de neige.

Le prix qui n'est pas sur l'étiquette

Voici le piège que personne n'intègre dans la comparaison : chaque stratégie de contexte ci-dessus est propriétaire et non portable. Tes fichiers CLAUDE.md ne signifient rien pour Cursor. Ton index Cursor ne se transfère pas vers Copilot. Changer d'outil signifie tout réapprendre à ton projet depuis zéro — des heures de setup, des semaines d'ajustement de prompts et de documentation.

L'abonnement à 20 €/mois, c'est la partie bon marché. La partie chère, c'est le savoir institutionnel que tu déverses dans le format spécifique d'un outil.

Et le clou du spectacle : aucun benchmark standard ne mesure la compréhension de codebase. OpenAI avait recommandé SWE-bench Pro comme remplaçant de Verified en février, mais deux mois plus tard, l'adoption reste anecdotique et Pro teste toujours des tâches isolées. Les modèles qui scorent ~80 % sur Verified tombent à environ 23 % sur Pro. Personne n'a construit le benchmark qui teste ce qui compte vraiment.

Ce que ça change pour toi

Arrête de lire les classements. Le chiffre que tu compares est un score de mémorisation sur un examen cassé.

Prend deux ou trois outils, fais tourner chacun sur ton dépôt pendant une semaine, et mesure la précision sur des tâches nécessitant une compréhension inter-fichiers — le genre de boulot que tu fais vraiment. Fais attention au temps de setup, parce que c'est ton coût de migration pour toujours.

La course aux modèles a plafonné à ~81 %. La course au contexte vient juste de commencer, et personne ne tient les comptes. C'est soit terrifiant, soit la plus grande opportunité dans l'outillage développeur en ce moment — selon que tu es un éditeur ou un développeur avec une semaine devant toi pour une évaluation honnête.