C'est dans la phase post-codage que l'IA a encore besoin des humains
Les outils de codage IA s’améliorent dans le domaine que tout le monde peut voir : la génération de code, de tests et même de plans de mise en œuvre succincts. Mais plus les outils gagnent en maturité, plus le véritable problème se déplace ailleurs. Le plus difficile n’est pas de produire du code. Il s’agit de s’assurer que ce code est adapté au produit, à l’architecture, aux règles de conformité, au processus de mise en production et à la tolérance au risque de l’équipe. C’est ce qu’on appelle le « fossé post-code », et c’est précisément là que le contrôle humain reste le plus important.
Cette analyse est corroborée par les tendances actuelles en matière d’adoption. JetBrains indique que 90 % des développeurs professionnels utilisent des agents de codage basés sur l’IA au travail au moins une fois par semaine, et que 68 % d’entre eux les utilisent quotidiennement. Aux États-Unis, Claude Code affiche un taux d’adoption de 47 % selon l’enquête. En d’autres termes, les agents de codage ne sont plus une nouveauté. Ils font désormais partie intégrante des équipes de développement logiciel. Lorsqu’un outil devient aussi courant, la question n’est plus de savoir s’il faut l’utiliser, mais comment le réguler.
Un rapport de TechCrunch consacré à Harness décrit une évolution importante : l’IA dépasse désormais la simple génération de code pour s’étendre aux tâches « post-code » que sont les tests, la vérification, la sécurité et la gouvernance. C'est la bonne direction à prendre, car la plupart des défaillances logicielles ne proviennent pas d'erreurs de syntaxe. Elles proviennent de la phase qui suit la compilation du code : hypothèses erronées, contrôles manquants, paramètres par défaut non sécurisés, attentes de déploiement non respectées et écarts entre ce que fait le système et ce que l'équipe avait prévu.
Pourquoi le code n’est qu’un début
Un agent peut proposer un correctif en quelques secondes, mais il ne peut pas décider si ce correctif doit exister en premier lieu. Il ne sait pas quel service est politiquement sensible, quelle API constitue une dépendance contractuelle, quel workflow est soumis à une réglementation, ni quelle solution de contournement temporaire est devenue une dépendance invisible en production. Ce sont là des jugements humains. Ce sont également ces jugements qui déterminent si une modification peut être fusionnée en toute sécurité.
C’est pourquoi la meilleure utilisation de l’IA dans le développement ne réside pas dans un transfert entièrement autonome. Il s’agit d’un workflow structuré où l’agent rédige, l’humain encadre et révise, et l’automatisation vérifie. L’agent doit accélérer l’exploration, mais l’humain doit rester maître de l’intention, du risque et de l’approbation finale. Une équipe qui fait l’impasse sur cette étape ne gagne pas de temps ; elle ne fait que déplacer le risque en aval.
- Intention : l’humain définit le problème.
- Mise en œuvre : l’agent propose du code et des tests.
- Vérification : les contrôles automatisés et la révision humaine détectent ce que le modèle a manqué.
- Mise en production : l’équipe décide quand la modification peut être déployée en toute sécurité.
Les systèmes de type « harness » concrétisent cette philosophie. Leur intérêt ne réside pas dans le fait qu’ils éliminent l’intervention humaine du processus, mais qu’ils ajoutent une couche fiable autour de celui-ci. Ils aident les équipes à gérer les tests, la gouvernance et les vérifications post-implémentation afin que le réviseur humain ne se retrouve pas face à des résultats bruts dépourvus de contexte. Concrètement, cela se traduit par une meilleure traçabilité, des limites d’approbation plus claires et moins de surprises après la fusion.
Ce que la certification devrait récompenser
Pour OrkestrAI, c’est là le véritable signe de maturité : non pas la capacité d’une équipe à laisser un agent agir sans contrôle, mais sa capacité à le maintenir dans des limites définies. Un workflow crédible montre que l’équipe est capable de répartir le travail, de solliciter l’aide de l’IA là où cela s’avère utile, tout en conservant aux humains la responsabilité des changements qui comptent. Les meilleures équipes considèrent l’IA comme un multiplicateur de capacité de jugement, et non comme un substitut à celui-ci.
C’est pourquoi l’exemple le plus utile de l’IA dans le domaine logiciel n’est pas « l’agent a tout écrit », mais « l’équipe a utilisé l’agent, a vérifié le résultat et a gardé le contrôle de l’issue ». C’est cette discipline qui rend l’adoption de l’IA durable. C’est également ce qui donne tout son sens à une certification.
En d’autres termes : la génération de code est la partie la plus facile ; la gouvernance, c’est le produit. Et à mesure que les outils d’IA gagnent en puissance, le rôle de l’humain devient plus important, et non l’inverse.
