Verdict factuel : les résultats de l’AI Index 2026 de Stanford montrent que les modèles ont fait passer leur score sur SWE-bench Verified d’environ 60 % à presque 100 % en un an. C’est un signal fort pour les équipes qui évaluent un assistant de code. Ce n’est pas, à lui seul, la preuve qu’un agent peut prendre en charge un dépôt, une revue ou une mise en production sans contrôle humain.
Le mot-clé visé ici est SWE-bench Verified et assistants de code IA. Le sujet compte parce qu’un chiffre proche du plafond rend le benchmark moins discriminant : deux outils peuvent sembler équivalents sur ce test et produire pourtant des résultats très différents sur le code, les droits d’accès, le coût ou les règles de confidentialité d’une équipe.
Les 3 points à retenir
- Le saut est réel : Stanford rapporte une hausse d’environ 60 % à presque 100 % sur SWE-bench Verified en une année de mesure.
- Le test est précis : il vérifie des correctifs sur des issues réelles de projets Python, avec des tests associés ; il ne mesure pas toute l’ingénierie logicielle.
- Le choix ne se réduit plus au score : contexte disponible, intégration IDE/terminal, revue, latence, prix et traitement des données deviennent des critères concrets.
Le chiffre qui change la lecture des assistants de code
| Indicateur | Valeur publiée | Périmètre et prudence |
|---|---|---|
| SWE-bench Verified | ≈ 60 % à presque 100 % en un an | Benchmark de résolution d’issues ; ce n’est pas un taux de réussite en production. |
| Incidents IA documentés | 362 en 2025, contre 233 en 2024 | Base d’incidents recensés ; hausse des cas documentés, pas mesure directe de tous les dommages. |
| Étude METR auprès de développeurs expérimentés | 19 % plus de temps avec l’IA | 16 développeurs sur leurs propres tâches, début 2025 ; résultat non généralisable à tous les outils ou profils. |
Le premier chiffre vient du chapitre Technical Performance de Stanford HAI, publié dans l’édition 2026. Le rapport parle bien de near 100%, pas de 100 % exact : conserver cette nuance évite de transformer une tendance de benchmark en promesse de perfection.
Ce que SWE-bench Verified mesure réellement
SWE-bench est un jeu d’évaluation open source. Chaque exemple part d’un ticket GitHub et d’un état de dépôt ; le système doit générer un patch qui passe les tests. La variante Verified resserre le jeu autour d’instances vérifiées pour obtenir une évaluation plus fiable. C’est utile : on juge un changement exécutable, pas seulement une explication de code convaincante.
Mais le benchmark simplifie volontairement le travail. Une issue est déjà formulée, l’environnement est cadré et la réussite est décidée par des tests. Dans une équipe, il faut aussi clarifier une demande floue, chercher les conventions du dépôt, arbitrer une dette technique, vérifier les dépendances, respecter les secrets et assumer le suivi après déploiement. Aucun score SWE-bench ne remplace ces étapes.
Pourquoi un score proche du plafond ne suffit plus à choisir
Quand un indicateur s’approche de son maximum, il différencie moins bien les produits. Un outil peut être excellent pour modifier une fonction isolée mais moins sûr lorsqu’il doit lire plusieurs services, exécuter des commandes ou proposer une migration. À l’inverse, un assistant légèrement moins performant sur un benchmark public peut mieux convenir à une DSI s’il offre des journaux d’audit, des contrôles d’accès et une politique de rétention compatible avec ses règles.
Les comparaisons marketing sont aussi fragiles : version du modèle, configuration de l’agent, limite de temps, accès internet et règles d’exécution peuvent modifier le résultat. Demandez toujours le nom exact du benchmark, la date, le taux de résolution et les paramètres. « Meilleur sur SWE-bench » sans ces éléments ne permet pas une décision d’achat.
Ce que les données prouvent — et ce qu’elles ne prouvent pas
Elles prouvent une progression spectaculaire sur une tâche de correction structurée. Elles ne prouvent ni un gain de productivité automatique, ni une baisse certaine des bugs, ni l’autonomie d’un agent sur un produit réel. La distinction est importante : l’étude de METR, menée auprès de 16 développeurs open source expérimentés au début de 2025, a observé un ralentissement de 19 % avec les outils IA disponibles dans ce protocole. C’est une petite étude, sur un contexte précis, mais elle rappelle que la vérification et l’intégration peuvent absorber le temps gagné à générer un patch.
Le second garde-fou est la sécurité. Le chapitre Responsible AI de Stanford relève 362 incidents IA documentés en 2025, contre 233 en 2024. Cette série ne dit pas que les assistants de code causent tous ces incidents ; elle signale plutôt que déployer plus de systèmes sans évaluation de risque crée un angle mort. L’accès d’un agent au terminal, aux tickets ou aux secrets mérite donc une revue distincte du benchmark de code.
Comment tester un assistant de code dans votre équipe
- Choisissez 10 à 20 tâches passées, sans données client ni secrets, avec une définition de terminé claire.
- Mesurez le cycle complet : compréhension, patch, tests, revue humaine et retouches. Ne chronométrez pas seulement la génération.
- Comparez deux solutions à modèle et droits d’accès documentés : qualité des tests ajoutés, lisibilité du diff, coût par tâche et latence.
- Testez les refus utiles : secret dans un fichier, dépendance vulnérable, instruction ambiguë, commande destructive. Un bon agent doit savoir s’arrêter.
- Décidez par usage : correction localisée, tests, documentation, migration ou support interne n’exigent pas le même niveau d’autonomie.
Les critères qui départagent désormais les alternatives
| Critère | Question à poser | Conséquence |
|---|---|---|
| Code et raisonnement | Le système explique-t-il le diff et ajoute-t-il des tests pertinents ? | Réduit la charge de revue, pas seulement le temps de saisie. |
| Multimodal | Peut-il exploiter maquette, capture ou trace sans exposer de données sensibles ? | Utile pour le débogage, à encadrer. |
| Vitesse et coût | Quelle latence et quelle consommation sur une tâche complète ? | Un agent lent ou coûteux peut annuler le gain. |
| API et intégration | IDE, CLI, CI et journalisation sont-ils compatibles avec le dépôt ? | Détermine la répétabilité du flux. |
| Confidentialité | Les prompts et le code servent-ils à l’entraînement ? Où sont-ils traités ? | Critère bloquant pour certains projets. |
| Français | Comprend-il les tickets, commentaires et consignes en français ? | À vérifier dans votre jeu d’essai, pas sur une démo. |
Pour qui ce chiffre est utile
Pour une petite équipe, il justifie de tester un assistant sur des correctifs étroits et répétitifs. Pour un responsable engineering, il invite à déplacer la grille d’achat vers le contrôle, la confidentialité et le coût total. Pour un développeur, il rappelle qu’un patch qui passe un test n’est pas nécessairement une décision d’architecture. L’usage le plus prudent consiste à laisser l’humain propriétaire du ticket et à traiter l’agent comme un contributeur rapide, mais révisable.
Questions fréquentes
Un score proche de 100 % sur SWE-bench signifie-t-il que l’IA code sans erreur ?
Non. Il concerne un benchmark défini et des correctifs validés par des tests. La production ajoute architecture, sécurité, exploitation et demandes ambiguës.
Quel assistant de code choisir en 2026 ?
Comparez au moins deux solutions sur vos propres tâches, avec le même protocole. Score public, vitesse, prix, API, confidentialité et qualité de revue comptent ensemble.
Peut-on envoyer un dépôt privé à un agent IA ?
Seulement après avoir vérifié les conditions de traitement, de conservation, d’entraînement et les contrôles administrateur du fournisseur. Limitez aussi les droits et les secrets accessibles.
Sources utiles
- Stanford HAI — AI Index Report 2026 (2026, source primaire).
- Stanford HAI — Technical Performance (2026, source primaire).
- SWE-bench — dépôt et documentation du benchmark (source primaire du jeu d’évaluation).
- Stanford HAI — Responsible AI (2026, source primaire).
- METR — étude sur des développeurs expérimentés (2025 ; utilisée faute d’équivalent 2026 identifié).
Vincent Vandegans suit les outils IA et leurs usages concrets pour Minderlist. Il privilégie les mesures, les conditions de test et les limites opérationnelles plutôt que les promesses de démonstration.
