Le code avec des agents : écrire devient bon marché, vérifier non

Les outils et leurs trois modes

Dans l'IDE, l'agent modifie le code dans votre éditeur sous vos yeux. Dans le terminal, un agent en ligne de commande lit le dépôt, lance commandes et tests, et modifie les fichiers. Dans le cloud, vous confiez une tâche et récupérez une pull request.

Deux formats ouverts limitent la dépendance : AGENTS.md, un fichier Markdown d'instructions pour agents lancé en août 2025 et adopté par plus de 60 000 projets open source en décembre, et MCP pour les outils et les données (voir MCP expliqué).

Benchmarks : regardez la version et le harnais

SWE-bench Verified, le sous-ensemble validé par des humains qu'OpenAI a publié en août 2024, était le chiffre cité à chaque lancement. En février 2026, OpenAI a cessé de le publier : l'état de l'art n'était passé que de 74,9 % à 80,9 % en six mois, un audit de 138 problèmes difficiles a trouvé des tests défectueux dans 59,4 % d'entre eux, et GPT-5.2 a résolu 31 tâches jugées presque impossibles, signe de contamination. Il est absent des tableaux de lancement de Claude Opus 5.5 et de GPT-6 Astra.

Ses successeurs sont plus durs et changent plus vite. SWE-bench Pro (Scale AI, septembre 2025) compte 1 865 tâches longues issues de 41 dépôts, mais son classement public n'inclut pas encore les modèles de mi-2026. Terminal-Bench est passé de la version 1.0 à la 4.0 en 15 mois ; sur le classement officiel de la 4.0, GPT-6 Astra dans Codex mène avec 58,2 %, devant Claude Fable 5.1 dans Claude Code (57,9 %), tandis que les 66,4 % annoncés par Anthropic pour Opus 5.5 (voir notre analyse) n'y figurent pas encore. Dans le tableau DeepSWE v1.1 d'OpenAI, cinq modèles de trois éditeurs se tiennent en moins de 7 points.

Nommez donc le modèle et le harnais, le logiciel qui fait tourner l'agent ; ne comparez qu'au sein d'une même version ; et testez sur votre code. Anthropic recommande de démarrer l'évaluation d'agents avec 20 à 50 tâches tirées d'échecs réels : pour le code, des tickets clos de vos propres dépôts. La méthode est dans notre guide d'évaluation des LLM.

Ce qu'ont trouvé les études de productivité

L'étude la plus rigoureuse reste l'essai randomisé de METR, publié en juillet 2025 : 16 développeurs open source expérimentés, 246 tickets réels d'environ deux heures chacun, dans des dépôts matures de plus d'un million de lignes. Avec l'IA autorisée, surtout Cursor Pro avec Claude 3.5 et 3.7 Sonnet, les tâches ont pris 19 % de temps en plus. Les développeurs attendaient un gain de 24 % et pensaient encore, après coup, avoir gagné 20 %.

Le suivi, lancé en août 2025 et publié en février 2026, estime un gain de temps de 18 % pour les participants revenus et de 4 % pour les nouveaux, mais les deux intervalles de confiance incluent zéro. METR juge ces données peu fiables : 30 % à 50 % des participants ont écarté les tâches qu'ils ne voulaient pas faire sans IA, donc le gain réel est probablement plus élevé.

Les enquêtes montrent le même écart. Dans DORA 2025 (près de 5 000 répondants), 90 % utilisent l'IA au travail et plus de 80 % se disent plus productifs, mais 30 % font peu ou pas confiance au code généré, et l'adoption va de pair avec plus de débit mais moins de stabilité des livraisons. Dans l'enquête 2025 de Stack Overflow, seuls 14,1 % utilisaient des agents d'IA chaque jour.

Sécurité : le code de l'IA échoue de façon connue

En 2025, Veracode a testé plus de 100 modèles sur des tâches en Java, Python, C# et JavaScript : 45 % des échantillons introduisaient une vulnérabilité du Top 10 OWASP, de 72 % en Java à 38 % en Python. La qualité fonctionnelle s'est améliorée, pas la sécurité, quelle que soit la taille du modèle.

• Dépendances. Un modèle peut suggérer un paquet qui n'existe pas, et un attaquant peut enregistrer ce nom avant vous. Figez les versions, installez via un registre interne ou une liste autorisée, et faites de chaque nouvelle dépendance une décision humaine (voir la sécurité de la chaîne d'approvisionnement IA).
• Secrets. Un agent voit ce que voit son terminal. Donnez-lui des identifiants éphémères au périmètre minimal, jamais ceux de production, et analysez chaque pull request à la recherche de secrets.
• Injection de prompt. Un ticket, une page web ou un README peuvent contenir des instructions que l'agent suit, et OpenAI juge peu probable que le problème soit un jour totalement résolu (voir injection de prompt et agents).
• Isolation. L'isolation du système de fichiers et du réseau a réduit de 84 % les demandes d'autorisation chez Anthropic, ce qui freine la validation machinale. Anthropic a aussi observé qu'environ 0,8 % des actions d'agents semblaient irréversibles : rare, mais pas nul.

Notre recommandation : les mêmes contrôles de sécurité pour toute pull request, humaine ou d'agent, et un pentest web et API externe avant d'exposer une application critique.

Ce qui change dans l'équipe

Des specs avant les prompts. Les agents travaillent mieux à partir d'une spécification courte : critères d'acceptation, fichiers concernés, ce qui ne doit pas changer. AWS a bâti Kiro autour de cette idée, et le harnais d'Anthropic pour agents de longue durée avance une fonctionnalité à la fois, après avoir vu des agents tout tenter d'un coup, se déclarer terminés trop tôt et laisser des fonctions non testées.

Les tests comme contrat. Un agent qui écrit le code et les tests peut se tromper des deux côtés de la même façon. Les tests qui définissent le comportement doivent être écrits ou validés par une personne, protégés par des code owners et jamais modifiés dans la pull request qu'ils valident.

La revue devient le goulot. Gardez des pull requests petites (une tâche, une pull request), demandez des preuves à l'agent (sortie des tests, captures, ce qu'il n'a pas fait) et étiquetez le travail des agents pour le mesurer à part. Selon Anthropic, avec l'expérience, la supervision passe de l'approbation de chaque action au suivi du travail.

Check-list avant d'activer des agents en arrière-plan

1. Un AGENTS.md avec les commandes de build, de test et de lint, et les zones interdites.
2. Des tests d'acceptation sur les chemins critiques, tenus par des personnes.
3. Des contrôles en CI : tests, types, analyse statique, détection de secrets, de dépendances et de licences.
4. Une taille maximale par pull request ; un agent ne fusionne jamais son propre travail.
5. Des identifiants d'agent éphémères, au moindre privilège, séparés des comptes humains.
6. Un bac à sable au réseau restreint et une étiquette sur les commits d'agents.

Gouvernance, licences et propriété intellectuelle en Colombie et en Europe

D'abord, une politique. Le modèle de capacités IA de DORA inclut une politique d'IA claire : quels outils, quels dépôts, quelles données, et qui peut activer des agents en arrière-plan. Sans elle, chacun apporte ses propres outils.

Le code est une donnée. Les dépôts contiennent des secrets d'affaires et parfois des données personnelles. Choisissez des offres qui excluent l'entraînement sur votre code, tenez les données de production hors de portée des agents et vérifiez où tourne l'inférence. En Colombie, un prestataire qui traite des données personnelles pour votre compte exige un contrat de transmission, et les transferts internationaux relèvent de l'article 26 de la loi 1581 de 2012. Dans l'UE, le RGPD s'applique, et l'article 4 modifié de l'AI Act (en vigueur depuis le 27 juillet 2026) demande aux entreprises de soutenir la maîtrise de l'IA chez leur personnel.

Paternité et licences. Le Copyright Office américain a conclu en janvier 2025 que des prompts seuls ne rendent pas un résultat d'IA protégeable : la protection exige une paternité humaine. Conservez les preuves de la contribution humaine (specs, revues, commits), lisez les clauses de propriété intellectuelle de votre éditeur et analysez les licences, car le code généré peut ressembler à du code open source existant.

Risque fournisseur. Les outils changent de propriétaire (Cursor appartient désormais à SpaceX) et l'accès peut changer pour des raisons politiques : une directive américaine de contrôle des exportations a obligé Anthropic à retirer Fable 5 à tous ses utilisateurs du 12 juin au 1er juillet 2026. Gardez les instructions dans des formats ouverts, les outils sur MCP et une seconde option testée.

Un modèle opérationnel et les indicateurs qui comptent

Déployez par étapes. Commencez là où la spécification est claire et la vérification peu coûteuse : bugs avec un test qui les reproduit, mises à jour de dépendances, écriture de tests, documentation, migrations mécaniques. Ajoutez des agents en arrière-plan une fois les contrôles et les indicateurs en place, et gardez l'architecture, le code sensible et les migrations de données sous contrôle humain étroit. Après 8 à 12 semaines, comparez avec la référence et décidez dépôt par dépôt.

Notre règle pratique quand nous construisons du logiciel sur mesure : l'agent écrit, les tests et les relecteurs décident. Pour les agents au-delà du code, lisez les agents d'IA en production.