L’IA sait déjà coder : ce que les agents de code changent pour vos équipes produit

Le développement assisté par IA a changé de nature. Les agents de code, comme Claude Code, Codex, GitHub Copilot ou Cursor, ne se contentent plus de compléter une ligne : ils lisent un dépôt, modifient plusieurs fichiers, lancent les tests et soumettent leurs changements à la relecture. Pour une équipe produit, le gain ne vient pas de la vitesse de frappe mais de l’organisation : un projet qui contient ses specs et ses décisions, des tâches isolées, une revue humaine sans complaisance.

« L’IA sait déjà coder. Apprenez à la diriger. » C’est la conviction que nous défendons en conférence comme en mission. Voici pourquoi 2025 et 2026 marquent une rupture, où se situe désormais le vrai goulot d’un projet, la méthode de travail qui tient en production, ce qui change pour chaque rôle, les risques à maîtriser et la façon de démarrer.

De l’autocomplétion aux agents : qu’est-ce qui a changé ?

Les outils publics les plus répandus couvrent ce spectre. Claude Code (Anthropic) et Codex (OpenAI) travaillent dans le terminal, l’éditeur ou le cloud. L’agent de GitHub Copilot prend en charge une issue (un ticket) et ouvre une pull request, c’est-à-dire une demande de fusion de ses modifications, soumise à relecture. Cursor est un éditeur de code construit autour de l’IA, avec ses propres agents. Les modèles changent vite ; la méthode, elle, reste.

Pourquoi 2025-2026 marque-t-il une rupture ?

Quatre évolutions se sont conjuguées.

• Les agents agissent. Lire, écrire, exécuter, tester, corriger : ils enchaînent les étapes seuls et s’arrêtent quand les tests passent, ou quand ils bloquent.
• Le contexte s’est allongé. Un agent garde en tête une large part d’un projet et va chercher lui-même les fichiers utiles. Il raisonne sur l’ensemble, plus sur un extrait.
• L’usage d’outils est devenu fiable. Git, terminal, navigateur, bases de données, et vos applications métier via des protocoles comme le MCP : l’agent exécute au lieu de décrire.
• Le coût s’est effondré. Selon l’AI Index 2025 de l’université Stanford, le coût d’inférence d’un système du niveau du modèle qui animait ChatGPT à son lancement a été divisé par plus de 280 entre novembre 2022 et octobre 2024.

L’usage suit. Dans l’enquête 2025 de Stack Overflow, 84 % des répondants utilisent ou prévoient d’utiliser des outils d’IA pour développer, contre 76 % un an plus tôt. Les agents n’étaient pas encore généralisés : 52 % des répondants n’en utilisaient pas ou s’en tenaient à des outils plus simples.

Méfiez-vous en revanche des promesses de productivité chiffrées. L’organisme de recherche METR a mesuré début 2025 que des développeurs open source expérimentés mettaient 19 % de temps en plus avec l’IA, sur des projets qu’ils connaissaient bien. En février 2026, METR jugeait l’effet probablement plus favorable avec les outils récents, ses nouvelles données suggérant une accélération, mais reconnaissait ne pas pouvoir le mesurer de façon fiable. Il rappelait aussi que les gains déclarés par les développeurs eux-mêmes peuvent être très peu fiables. Conclusion pratique : mesurez chez vous, sur vos propres indicateurs.

Le vrai goulot n’est pas le code, c’est la communication

Dans une équipe produit classique, le besoin voyage en relais. La direction fixe le cap, les commerciaux rapportent ce que veulent les clients, le product manager priorise, le product owner écrit les règles, le designer dessine les écrans, le développeur code, le testeur vérifie, l’équipe d’exploitation déploie. Chacun détient un morceau du contexte ; personne n’a le produit en entier. À chaque relais, de l’information se perd, et une bonne part du temps passe à se coordonner.

Quand l’écriture du code s’accélère, ce relais devient le facteur limitant. Un agent qui reçoit une spec ambiguë produit, très vite, un code qui répond à la mauvaise question. Le travail qui prend de la valeur est celui d’avant et d’après le code : formuler le besoin, trancher, relire, vérifier.

Comment faire du projet le « cerveau central » de l’équipe ?

La réponse consiste à ramener la connaissance dans le projet lui-même, là où les agents et les humains la trouvent.

• Un fichier d’instructions à la racine du dépôt (AGENTS.md ou CLAUDE.md selon les outils) : conventions, commandes de test, pièges connus, ce qu’il ne faut jamais faire.
• Des spécifications versionnées avec le code, une par fonctionnalité, avec des critères d’acceptation vérifiables.
• Des décisions tracées : une note courte par choix structurant (contexte, options, décision), pour ne pas rejouer le débat six mois plus tard.
• Un glossaire métier, pour que « client », « commande » ou « chantier » aient le même sens pour tout le monde, IA comprise.

Le projet devient interrogeable en langage naturel. Un product owner demande à un agent comment une remise est calculée ; un commercial vérifie qu’une fonction existe ; un nouveau développeur se fait expliquer l’architecture. Ce socle réduit aussi les erreurs de l’IA : un agent ancré dans des specs précises improvise moins.

La méthode : une tâche, un agent, un espace isolé, une branche, une pull request

1. Découper. Une tâche produit un résultat vérifiable, décrit dans un ticket avec ses critères d’acceptation. Si le résultat ne tient pas dans une pull request qu’on relit d’une traite, la tâche est trop grosse.
2. Isoler. Chaque agent travaille dans son propre espace (un worktree Git, c’est-à-dire une copie de travail séparée du dépôt, un conteneur ou un environnement cloud) et sur sa propre branche, une version parallèle du code. Plusieurs agents avancent en parallèle sans se marcher dessus, et une piste ratée se jette sans dégât.
3. Déléguer. L’agent implémente, écrit ou complète les tests, lance la suite et corrige jusqu’à ce qu’elle passe. Il résume ce qu’il a fait dans la description de la pull request.
4. Vérifier automatiquement. L’intégration continue (CI) rejoue à chaque modification les tests, l’analyse statique, le contrôle des dépendances et la détection de secrets.
5. Relire en sceptique. Un humain relit chaque pull request comme le code d’un inconnu talentueux mais pressé : que se passe-t-il sur les cas limites ? Qu’est-ce qui n’est pas testé ? Un second agent peut faire une première relecture critique ; il ne remplace pas la vôtre.
6. Fusionner sous contrôle. La branche principale est protégée : pas de modification directe, relecture approuvée et tests au vert obligatoires avant fusion. Les droits sur le dépôt (GitHub, GitLab) restent entre vos mains, pas entre celles des agents.

Exemple : une fonctionnalité, de la spec à la fusion

Prenons un cas fictif : une PME veut ajouter l’export PDF des devis à son outil interne. Le product owner rédige la spec dans le dépôt (mise en page, mentions obligatoires, cas d’un devis sans remise). Un développeur crée le ticket et lance un agent dans un espace isolé. L’agent lit la spec et le code existant, implémente l’export, ajoute des tests (devis vide, devis de cinquante lignes) et ouvre la pull request. L’intégration continue passe au vert. À la relecture, le développeur remarque que les montants sont arrondis ligne par ligne au lieu de l’être sur le total, comme le prévoit la spec : un écart de quelques centimes, invisible en démonstration. Il le signale, l’agent corrige et ajoute le test qui manquait. Le product owner valide le rendu sur l’environnement de prévisualisation, puis la branche est fusionnée. Le code a été écrit par la machine ; les deux décisions qui comptaient ont été prises par des humains.

Ce qu’on ne délègue pas à un agent

Un agent peut proposer, jamais trancher seul sur ce qui est structurant ou irréversible : les choix d’architecture, le code de sécurité critique (authentification, droits, chiffrement), les migrations de données de production, les suppressions et tout ce qui touche à un environnement réel. Sur ces sujets, l’agent prépare, un humain décide et exécute.

Ce qui change pour chaque rôle

Product managers et product owners

La spec devient le levier principal : un agent exécute ce qui est écrit, ambiguïtés comprises. Les PM et les PO gagnent à rédiger des critères d’acceptation testables, à prototyper eux-mêmes une idée pour la montrer plutôt que la décrire, et à valider le comportement livré sur un environnement de prévisualisation plutôt qu’en lisant le code.

Développeurs

Le métier glisse de l’écriture vers la direction : découper, cadrer l’agent, relire, tester, arbitrer l’architecture. Un développeur expérimenté peut piloter plusieurs tâches en parallèle ; sa valeur tient à son jugement. Pour les profils juniors, le risque est d’accepter du code qu’ils ne comprennent pas : prévoyez des revues pédagogiques et du temps de pratique sans assistance. Notre article sur les métiers de l’IA détaille l’évolution des rôles techniques.

QA et testeurs

Si le code arrive plus vite, la vérification doit suivre. L’ANSSI et le BSI, son homologue allemand, recommandent que les équipes qualité et sécurité profitent de gains de productivité comparables ou soient renforcées en conséquence. Le testeur passe de l’exécution manuelle à la stratégie : quels cas couvrir, quels tests automatiser (les agents les écrivent volontiers), quelles explorations garder humaines.

Direction et CTO

Choisir les outils et leurs conditions contractuelles, fixer les règles d’usage (données, secrets, droits), mesurer l’effet réel. C’est aussi le moment de revoir certains arbitrages : quand construire coûte moins cher, un outil interne peut remplacer un abonnement, comme nous l’analysons dans outil sur mesure ou SaaS.

Quels sont les risques du code généré par l’IA ?

• Le code plausible mais faux. C’est le premier piège. Dans l’enquête Stack Overflow 2025, 66 % des répondants citent des solutions « presque justes, mais pas tout à fait » comme principale frustration, et 45 % estiment que déboguer du code généré prend plus de temps. Parade : petites pull requests, tests écrits avant ou avec le code, relecture ciblée des cas limites.
• La dette. Un agent produit beaucoup, vite, et duplique volontiers au lieu de réutiliser. Sans conventions écrites ni relecteurs qui savent dire non, la base de code grossit plus vite que sa qualité. Parade : conventions dans le fichier d’instructions, tâches régulières de nettoyage, limite de taille des pull requests.
• La sécurité. Le code généré peut contenir des failles, et les agents ouvrent de nouvelles portes : des dépendances inventées qu’un attaquant peut publier sous le même nom, des instructions malveillantes cachées dans une documentation ou un ticket (injection de prompt). Le rapport de l’ANSSI et du BSI sur les assistants de programmation (2024) rappelle qu’ils ne remplacent pas des développeurs expérimentés, recommande une analyse de risques avant leur introduction et demande que le code généré soit, en règle générale, vérifié par les développeurs. Voir aussi notre article sur la sécurité de l’IA générative.
• Les secrets. Un agent lit ce qui se trouve dans son espace de travail, fichiers de configuration compris. Ne lui confiez jamais de clés de production : environnements séparés, secrets injectés au déploiement, détection de secrets à chaque commit, droits minimaux sur les dépôts et les services.
• Les données confiées aux outils. Préférez aux comptes personnels des comptes entreprise dont le contrat précise l’usage de vos données (réentraînement ou non, hébergement), comme le recommandent aussi l’ANSSI et le BSI. Fixez ces règles dans une charte IA.

Comment démarrer avec les agents de code ?

Pas besoin d’une plateforme sophistiquée pour commencer : un agent (Claude Code ou Codex, par exemple), un dépôt GitHub ou GitLab et quelques règles suffisent. Le reste s’apprend en faisant, sur un mois.

1. Semaine 1 : cadrer. Un projet réel mais non critique, deux ou trois volontaires, des comptes entreprise, une charte d’usage. Protégez la branche principale et activez les tests automatiques.
2. Semaine 2 : outiller le projet. Écrivez le fichier d’instructions pour les agents, déposez dans le dépôt les specs des prochaines fonctionnalités, documentez les commandes de test.
3. Semaines 3 et 4 : produire et mesurer. Appliquez la règle « une tâche, une branche, une pull request ». Suivez quelques indicateurs : délai entre ticket et fusion, taille des pull requests, retouches demandées en relecture, anomalies après livraison.
4. Fin du mois : décider. Faites le bilan avec l’équipe : ce qui a marché, les garde-fous à ajouter, les projets suivants.

Le facteur limitant est rarement l’outil. C’est la capacité de l’équipe à écrire une spec exploitable, à découper le travail et à relire avec exigence. C’est ce que nous travaillons dans nos formations en entreprise, sur vos cas d’usage réels, ou en conférence pour vos dirigeants. Pour construire un programme plus large, voyez notre guide pour former ses équipes à l’IA.