Depuis quelques mois, les agents IA ont pris une place considérable dans le quotidien des équipes de développement via la génération de code, rédaction de pull requests, couverture de tests… Les gains de productivité sont réels, et personne chez WexIT ne remet ça en question. On utilise ces outils au quotidien, et ils accélèrent clairement certaines phases de nos projets.
Mais en tant que PMO, ce qui m’intéresse, ce n’est pas seulement la vitesse à laquelle on produit du code. C’est la capacité d’une équipe à livrer du code fiable en production, sans que la rapidité de génération ne crée un faux sentiment de sécurité. C’est une thématique que nous avons abordée dans cet article : « OWASP Top 10 LLM : les 10 failles de sécurité des apps IA, expliquées avec des exemples concrets«
Et c’est précisément là que le sujet devient délicat.
Le vrai problème : un code qui a l’air parfait, mais qui ne l’est pas
Ce qui rend les agents IA particulièrement piégeux du point de vue projet, c’est la qualité apparente de leurs outputs. Le code généré respecte les conventions du repo, passe l’analyse statique, embarque des tests unitaires plausibles et s’accompagne d’une description de PR propre et structurée.
Vu de loin, ça ressemble à du travail d’ingénieur senior. Sauf que derrière cette façade, il manque un ingrédient essentiel qui est la connaissance du contexte de production.
Un agent ignore que votre instance Redis approche de la saturation, que votre base de données est configurée sur une seule région ou qu’un feature flag en cours de déploiement va modifier le profil de charge d’un service en aval. Il génère du code qui fonctionne dans l’absolu, mais pas forcément dans votre réalité technique.
Et quand les tests passent au vert, il est tentant de considérer que tout va bien. Sauf que dans un contexte d’agents IA, un pipeline vert n’est pas une preuve de sûreté. C’est simplement la preuve que l’agent a su convaincre votre chaîne de CI/CD que le changement était inoffensif.
Utiliser l’IA vs. se reposer dessus : une distinction structurante
En accompagnant les équipes techniques de nos clients, j’observe deux postures très différentes face aux agents de code.
La première, c’est la délégation passive. L’agent génère, les tests passent et on merge. Personne ne construit de modèle mental du changement. Les PR grossissent, les hypothèses implicites s’accumulent, et quand un incident survient, personne n’est en mesure d’expliquer précisément ce que le code fait.
La seconde, c’est l’utilisation maîtrisée. L’agent accélère l’itération, mais le développeur reste propriétaire de chaque ligne. Il comprend le comportement du code, il identifie les risques et il assume la responsabilité de ce qu’il livre.
Chez WexIT, on résume ça par une question simple que chaque membre de l’équipe devrait se poser avant de valider une PR : Est-ce que je serais à l’aise pour gérer un incident lié à ce code en production ?
Si la réponse est non, il reste encore du travail. Et ce n’est pas qu’une simple question de compétence, mais bien de rigueur dans le processus.
Ce que ça change côté pilotage de projet
Pour un PMO, l’arrivée des agents IA transforme concrètement l’organisation des équipes et la manière de piloter les projets.
La revue de code doit changer de nature
Quand le volume de code généré augmente fortement, la review humaine ne peut plus suivre ligne par ligne. Il faut repenser ce qu’on attend d’une code review : moins de vérification syntaxique, plus d’analyse d’impact.
- Est-ce que ce changement modifie un comportement critique ?
- Est-ce qu’il touche à de l’infrastructure partagée ?
- Est-ce qu’il introduit des side effects non couverts par les tests ?
Les déploiements doivent devenir progressifs par défaut
Le déploiement en big bang a toujours été risqué, mais il devient franchement dangereux quand le rythme de production s’accélère grâce à l’IA. Chaque changement devrait transiter par un pipeline de déploiement progressif : canary release, feature flags, rollback automatique… Si un déploiement dégrade les métriques, il s’arrête et se rétracte sans intervention humaine.
C’est un investissement en infrastructure, mais c’est la condition pour que la vélocité offerte par les agents IA reste un avantage et ne devienne pas un facteur de risque.
Les best practices doivent être exécutables et non pas documentées
Un point qui me parle particulièrement en tant que PMO, ce sont les procédures qui vivent uniquement dans une page Notion ou un wiki interne ne suffisent plus. Quand le rythme s’accélère, personne n’a le temps de relire une documentation avant chaque déploiement.
La bonne approche, c’est d’encoder ces pratiques sous forme d’outils exécutables. On en parle plus précisément dans l’article : Vibe coding, specs, skills, agents : arrêtez de prompter à l’aveugle, structurez votre IA. Un plan de rollout ne devrait pas être un document à suivre manuellement, mais il devrait être un script qui configure les feature flags, définit les conditions de rollback et spécifie les métriques de validation. Les guardrails les plus efficaces sont ceux que les agents (et les humains) suivent automatiquement, sans effort de mémorisation.
C’est exactement la logique que l’on retrouve dans certaines briques de plateforme, comme les annotations readonly ou destructive de l’Abilities API WordPress, qui rendent explicite le niveau de risque d’une action et permettent d’encadrer nativement le comportement des agents.
L’enjeu n’est pas de freiner l’IA, mais de structurer son intégration
Il ne s’agit pas de diaboliser les agents IA ou de ralentir les équipes. Les gains de productivité sont tangibles, et les modèles ne vont faire que s’améliorer. Les diffs vont grossir, le code généré sera de plus en plus convaincant, et la tentation de merger sans vérification approfondie ne fera qu’augmenter.
L’enjeu pour les équipes techniques et les PMO est de construire un environnement où la rapidité reste sûre par conception. Non parce que chaque développeur serait irréprochable, mais parce que l’infrastructure limite les risques et applique les bonnes pratiques par défaut.
C’est exactement la philosophie qu’on défend chez WexIT dans nos projets d’architecture et de modernisation IT : des systèmes headless, maîtrisés, dans lesquels la qualité n’est pas un effort supplémentaire mais une propriété du système.
Trois questions à se poser avant chaque mise en production
Pour conclure, voici le filtre que j’utilise (et que je recommande à nos clients) avant chaque livraison impliquant du code assisté par IA :
1. Qu’est-ce que ce code fait exactement, et comment se comporte-t-il une fois déployé ?
2. Quels sont les scénarios dans lesquels ce changement peut impacter négativement la production ou les utilisateurs ?
3. Est-ce que je suis à l’aise pour assumer un incident lié à cette PR ?
Si vous répondez oui aux trois, vous exploitez l’IA de manière responsable. Si ce n’est pas le cas, il reste du travail et cela est parfaitement normal.
