Agents IA de codage : ce qui change vraiment quand vous renforcez votre équipe de dev

Vos développeurs utilisent déjà Claude Code ou Codex. Ceux que vous recrutez, et ceux qu'une ESN place chez vous en renfort d'équipe. La question n'est plus de savoir s'ils vont plus vite. Elle est de savoir ce que cette vitesse vous coûtera dans six mois.

Notre position est simple : un renfort qui utilise l'IA sans cadre vous coûtera plus cher qu'un renfort sans IA. Pas parce que l'outil est mauvais. Parce qu'un agent exécute vite ce qu'on lui demande, y compris ce qu'on lui demande mal.

Voici ce que ça change concrètement pour une équipe de dev, et ce qu'il faut exiger quand on renforce la sienne.

L'agent lit votre code, pas votre métier

Un agent de codage explore un dépôt, repère les fichiers concernés, propose un plan, modifie le code et lance les tests. Sur une base de code qu'il découvre, il fait en quelques minutes ce qui prendrait une demi-journée à un développeur.

Prenons une demande banale : ajouter un rôle « responsable d'agence » dans une application métier. L'agent trouvera sans difficulté le modèle des rôles, les décorateurs de permission, les routes d'API et les écrans à adapter. Il produira un code propre, qui compile, avec des tests verts.

Ce qu'il ne trouvera pas : la règle selon laquelle un responsable d'agence ne voit que les dossiers de son agence, sauf ceux transférés au siège. Cette règle n'est écrite nulle part. Elle vit dans la tête du product owner et dans trois tickets clos depuis deux ans.

Le résultat est donc fonctionnel… et faux. Personne ne s'en rend compte avant qu'un utilisateur voie des données qu'il ne devrait pas voir.

C'est toute la nouveauté : l'exécution n'est plus le goulot d'étranglement. Le contexte, si.

Trois façons de travailler, trois niveaux de risque

Un bon développeur ne délègue pas tout à l'agent. Il choisit, tâche par tâche, entre trois modes. Savoir choisir le bon est devenu une compétence à part entière.

La délégation n'est donc pas un mode « paresseux ». C'est le plus exigeant en préparation : objectif, contraintes et critères de validation doivent être écrits avant que l'agent touche au code.

Le piège : aller plus vite, payer plus tard

Un agent produit du code qui fonctionne. Ce n'est pas la même chose qu'un code qui convient. La requête SQL renvoie les bonnes lignes mais s'effondre à 100 000 enregistrements. L'endpoint répond correctement mais expose un champ sensible. Le composant React marche mais ignore le design system.

Ces défauts existaient avant l'IA. Ce qui change, c'est leur débit : on peut désormais en produire dix fois plus vite.

Le test qui ment

Le risque le moins visible est celui-ci : un test écrit par l'agent qui a codé la fonctionnalité reproduit ses hypothèses. S'il a mal compris la règle métier, il écrira un test qui valide sa mauvaise compréhension. Les tests passent, la pipeline est verte, le bug part en production.

La parade est simple à énoncer : les critères de validation doivent venir d'ailleurs que de l'agent. Critères d'acceptation rédigés avant, tests de recette écrits par une autre personne ou une autre session, revue humaine sur les zones sensibles.

Mesurer la productivité au bon endroit

Le temps de génération ne dit rien. Ce qui compte, c'est le temps jusqu'à une mise en production stable : génération, revue, corrections, retours de recette, dette créée. Une fonctionnalité livrée en une heure puis corrigée pendant trois jours n'est pas un gain.

Ce qu'un CTO doit cadrer

Mettre Claude Code ou Codex à disposition de l'équipe prend une journée. Sans règles communes, chaque développeur invente sa méthode, et la qualité varie d'une Merge Request à l'autre. Cinq décisions suffisent à poser le cadre :

1. Les outils autorisés. Quels agents, sur quels postes, avec quel compte. Un agent personnel branché sur le dépôt client n'est pas un détail.
2. Les données accessibles. Code source, oui. Base de production, secrets, données clients : jamais sans décision explicite.
3. Le contexte écrit. Conventions, architecture, règles métier non évidentes, dans un AGENTS.md ou CLAUDE.md versionné avec le code. Ce qu'on répète deux fois à un agent doit y figurer.
4. Les actions soumises à validation. Modifier des fichiers, oui. Lancer une migration, pousser sur une branche protégée, appeler un service externe : sur accord humain.
5. Les contrôles obligatoires avant fusion. Revue humaine, lint, analyse statique, tests d'intégration. Identiques que le code vienne d'un humain ou d'un agent.

Ce cadre ne ralentit pas l'équipe. Il lui évite de payer en recette ce qu'elle a gagné en développement.

Renfort d'équipe : l'IA ne dispense pas de s'intégrer

Un développeur externe arrive sur un produit qu'il ne connaît pas : son architecture, son historique, ses règles métier implicites. C'est exactement là où l'agent est le plus fort (explorer vite) et le plus dangereux (combler les trous par des suppositions).

Un renfort équipé d'agents IA peut être opérationnel plus tôt. Il peut aussi livrer plus tôt du code qui contourne vos conventions. La différence ne tient pas à l'outil, mais à la méthode de la ressource et de l'ESN qui l'encadre.

Avant de signer, posez ces questions à votre prestataire :

• Vos développeurs utilisent-ils des agents IA, et selon quelles règles ?
• Comment s'alignent-ils sur notre cadre (outils autorisés, données, revue) plutôt que sur le leur ?
• Qui valide le code produit par un agent avant qu'il arrive en Merge Request ?
• Comment le contexte métier appris pendant la mission est-il documenté pour l'équipe interne ?

Une ESN qui n'a pas de réponse précise vend de la capacité de production. Ce dont vous avez besoin, c'est d'une équipe qui produit dans votre système.

Accélérer, oui. À condition de piloter.

Les agents IA ne changent pas ce qu'est un bon logiciel. Ils changent la vitesse à laquelle on s'en approche, ou on s'en éloigne. Ce qui fait la différence, c'est le cadre : du contexte écrit, des tâches découpées, des validations indépendantes.

C'est ce cadre que DevelopA applique à chaque ressource placée en renfort d'équipe.