Les agents de codage sont là
Les agents de codage ont franchi un cap : ils ne se contentent plus d’être de simples aides à la saisie automatique. Ils peuvent enchaîner des tâches, modifier un dépôt, exécuter des tests, proposer des refactorisations et parfois même pousser les modifications jusqu’à la mise en production. Mais plus ces outils gagnent en capacités, plus une chose apparaît clairement : leur valeur ne réside pas dans l’autonomie brute. La valeur réside dans la manière dont l’humain garde le contrôle du résultat.
Les dernières données vont dans le même sens. JetBrains indique que 90 % des développeurs professionnels utilisent des agents de codage au moins une fois par semaine, et 68 % les utilisent quotidiennement. Aux États-Unis, Claude Code affiche un taux d’adoption de 47 % parmi les développeurs interrogés. Cela signifie que le codage par agent n’est plus une expérience de niche ; il devient une composante normale du travail logiciel. Mais « normal » ne signifie pas « sans supervision ».
La question n’est donc plus : « Une IA peut-elle écrire du code ? » La véritable question est : « Quel est le bon système de commande et de contrôle autour de cette IA ? » C’est là que réside la différence entre une équipe qui accélère en toute sécurité et une équipe qui crée des risques évitables.
Les humains restent le point d’ancrage
La première raison est simple : le contexte métier reste humain. Un agent peut lire une base de code, mais il ne sait pas ce qu’un incident coûte à l’entreprise, quels types de dette technique sont acceptables, quels compromis sont défendables auprès d’un client, ni quelle contrainte de conformité doit primer sur la rapidité. Sans ces jugements, l’agent optimise des indicateurs locaux et peut dégrader le système dans son ensemble.
Une bonne utilisation des agents commence donc avant même que le moindre code ne soit écrit. La tâche doit être cadrée, les limites doivent être explicites, les objectifs mesurables doivent être clairs, les tests de sortie doivent être définis, et les moments où un humain doit reprendre le relais doivent être précisés d’emblée. Une tâche bien formulée n’est pas une simple instruction générique ; c’est une spécification exploitable.
Vient ensuite la vérification. Un agent peut proposer une solution convaincante qui reste néanmoins erronée. Il peut résoudre le symptôme tout en passant à côté de la cause. Il peut ajouter un test qui réussit sans pour autant garantir le comportement escompté. Il peut introduire un problème de sécurité subtil ou une dépendance superflue. C’est pourquoi la révision humaine doit aller au-delà d’une simple vérification visuelle : il faut lire le diff, exécuter les tests, inspecter les effets secondaires et examiner les cas limites.
Le marché lui-même semble converger vers cette idée. Un article récent de TechCrunch sur les agents d’OpenAI posait une question centrale : à quoi ressemble un bon « harnais » ? En pratique, les meilleurs systèmes ne sont pas ceux qui suppriment l’intervention humaine. Ce sont ceux qui la structurent. Ils permettent aux développeurs de déléguer des sous-tâches tout en conservant la décision finale, la responsabilité technique et le droit de dire non.
Ce que les équipes doivent garder en main
- Cadrage du problème : transformer une intention vague en une tâche vérifiable.
- Risque : déterminer ce qui peut mal tourner et ce qui est inacceptable.
- Validation : lire le diff, exécuter les tests et rechercher les effets secondaires.
- Mise en production : ne confondez pas une démo avec un déploiement.
- Responsabilité : savoir qui est responsable en cas de problème.
Cela est particulièrement vrai dans les environnements réels : bases de code héritées, contraintes de sécurité, équipes distribuées, dépendances multiples, clients exigeants. Dans ces contextes, l’agent est utile lorsqu’il accélère l’exploration et la génération d’options. Il devient dangereux lorsqu’on lui confie un mandat sans garde-fous. Le gain de productivité provient d’une itération plus rapide, et non de l’abandon du jugement.
On peut réduire le rôle humain à cinq responsabilités essentielles : la définition du problème, l’évaluation des risques, la validation technique, la prise de décision concernant la mise en production et l’acceptation de la responsabilité. L’agent peut apporter son aide à chacune de ces étapes, mais aucune d’entre elles ne doit être entièrement confiée à une « boîte noire » fonctionnant sans supervision.
Pourquoi la certification est-elle pertinente ?
Dans un contexte de certification comme celui d’OrkestrAI, ce point revêt encore plus d’importance. La maturité ne consiste pas à prouver qu’un agent est capable de construire une application entière à lui seul en mode entièrement autonome. La maturité consiste à démontrer qu’une équipe est capable d’exploiter correctement le système : décomposer la demande, déléguer ce qui doit l’être, revérifier ce qui doit l’être, et conserver un intervenant humain capable de décider quand les contraintes liées au code, à la sécurité ou au produit nécessitent de ralentir le rythme.
La bonne attitude n’est ni la peur ni l’enthousiasme naïf. L’IA au service du développement est déjà suffisamment puissante pour mériter une certaine discipline, mais pas assez fiable pour être laissée sans gouvernance. L’avenir souhaitable n’est pas celui d’une opposition entre l’IA et les humains. C’est celui d’une IA aux côtés des humains, avec ces derniers qui gardent le contrôle. C’est cette discipline que les équipes doivent apprendre, documenter et certifier.
Les meilleurs agents ne remplacent pas le jugement humain ; ils le renforcent.
