IA agentique : ce qui change vraiment dans une équipe de développement

La complétion de code assistée est entrée dans les habitudes sans bouleverser l’organisation : elle accélère la frappe, le développeur garde la main sur chaque ligne. Les agents posent une question différente. On ne leur demande plus de suggérer, mais d’exécuter : lire un dépôt, modifier plusieurs fichiers, lancer les tests, ouvrir une pull request. Le changement n’est pas de degré, il est de nature.

Assistant ou agent : la distinction utile

Cette dernière ligne est celle qui compte. Tant que la validation portait sur trois lignes proposées dans l’éditeur, elle était quasi gratuite. Quand elle porte sur une modification de quinze fichiers, elle redevient un vrai travail d’ingénierie — et c’est là que les équipes se font surprendre.

Ce que nous observons dans les équipes

Les gains réels ne sont pas là où on les annonce. Sur les missions et les sessions que nous animons, trois usages ressortent nettement.

1. 01

   Les tâches ingrates et bien cadrées

   Migration d’une API dépréciée sur un dépôt entier, harmonisation de conventions, écriture de tests de non-régression sur du code existant. Le cadre est clair, le résultat vérifiable mécaniquement : c’est le terrain le plus rentable.

2. 02

   L’exploration d’un code inconnu

   Reprendre une base héritée sans documentation. Faire expliciter par un agent le flux d’une fonctionnalité fait gagner des jours d’acclimatation — à condition de vérifier ses affirmations, il en invente.

3. 03

   Le travail hors dépôt

   Rapprocher un ticket, une trace d’erreur et le commit fautif ; préparer une note de version. C’est souvent là que le temps se gagne, pas dans l’écriture du code lui-même.

À l’inverse, les tâches où le besoin est mal défini restent difficiles : l’agent produit vite une réponse plausible, et une réponse plausible à une mauvaise question coûte plus cher qu’une page blanche. La qualité de la spécification est devenue une compétence technique de premier plan.

Les risques que l’on sous-estime

• L’exfiltration de code et de données. Un agent qui lit le dépôt lit aussi ce qui n’aurait jamais dû y être : secrets commités, jeux de données clients, exports de production. La question du périmètre d’accès se tranche avant le déploiement, pas après.
• Les injections de prompt indirectes. Un agent qui lit une issue, une page web ou une dépendance peut y trouver des instructions rédigées pour lui. Tout contenu externe est une donnée, jamais une consigne — un principe à imposer dans l’outillage, pas seulement dans les têtes.
• La dette de compréhension. Du code fusionné que personne dans l’équipe ne sait expliquer six mois plus tard. Le coût n’apparaît qu’à la première panne en production.
• L’érosion des compétences juniors. Ce que l’agent fait à leur place est précisément ce par quoi on apprend le métier. La question de la montée en compétences se pose explicitement, sinon elle se règle mal toute seule.

« Un agent bien outillé sur un périmètre restreint est plus utile qu’un agent tout-puissant sur l’ensemble du système d’information. La contrainte n’est pas une réserve envers l’outil, c’est ce qui le rend exploitable. »

Standardiser l’accès aux outils

Un agent n’a d’intérêt que par ce qu’il peut atteindre : gestionnaire de tickets, base de données de test, documentation interne, chaîne d’intégration. Longtemps, chaque intégration était un développement spécifique. L’émergence de protocoles standardisés d’accès aux outils — le MCP en particulier — change l’économie du sujet : on expose une fois un outil interne, et l’ensemble des agents peut s’y connecter.

Ce qui déplace la compétence clé : moins « savoir prompter » que savoir concevoir et sécuriser l’outillage que l’agent utilisera — périmètres d’accès, traçabilité des actions, garde-fous sur les opérations destructrices.

Les compétences à installer dans l’équipe

1. 1Cadrer une tâche pour un agent : contexte, critères d’acceptation, périmètre de modification autorisé.
2. 2Relire vite et bien une modification volumineuse que l’on n’a pas écrite — la compétence la plus rentable, et la moins enseignée.
3. 3Concevoir l’outillage : exposer les systèmes internes proprement, avec le bon niveau de privilège.
4. 4Évaluer, plutôt que ressentir : mettre en place des mesures de qualité et de régression pour savoir si l’agent aide réellement.
5. 5Poser le cadre de conformité : ce qui peut être transmis à un service tiers, ce qui reste interne, et comment le tracer.

Le sujet bouge vite, et beaucoup de ce qui s’écrit dessus relève de la promesse commerciale. La position la plus solide reste l’expérimentation encadrée : un périmètre restreint, des critères de réussite définis à l’avance, et une décision prise sur des mesures plutôt que sur des impressions.