Dans les entreprises de développement logiciel, l'essor des agents de codage a souvent conduit à une question simple : comment gérer le code généré ?
- Davantage de code est généré, et le temps manque souvent pour les reviews. Comment résoudre cela ?
- Le code généré doit-il être relu tout court ?
- Qui est réellement responsable des modifications dans le code ?
Je vois cela de manière assez pragmatique : les fondamentaux d'un bon développement logiciel ne changent pas simplement parce que les outils deviennent plus puissants.
Qui porte la responsabilité ?
L'auteur du code reste la personne qui "opère" l'agent de codage. Elle est pleinement responsable du résultat. Le fait qu'une IA tape les lignes ne dispense pas le développeur de l'obligation de comprendre le code et de garantir sa justesse.
Les agents de codage sont des outils, des outils très puissants certes, mais au final, ce qui compte, c'est le résultat que nous, professionnels, intégrons dans la base de code.
Quantité avant qualité ?
L'IA produit souvent davantage de code en moins de temps. Il faut alors examiner cela de façon critique : ce code est-il vraiment nécessaire ou déjà obsolète ?
Crée-t-on ici une vraie valeur, ou bien le cinquième cas de test redondant a-t-il simplement été généré ? J'ai déjà vu des cas de test avec Assert.True(true) uniquement pour avoir "plus de tests". Ce type de code doit être supprimé sans hésitation. La quantité n'est pas un critère de qualité, et le "Vibe Coding" ne doit pas conduire à inonder nos dépôts de boilerplate et de code inutile.
Les code reviews comme transfert de connaissances
La code review en particulier est un vecteur essentiel de transfert de connaissances au sein de l'équipe. La review doit recevoir au moins autant d'attention que le développement lui-même.
Je sais que la réalité du quotidien projet est souvent différente et que les reviews sont perçues comme pénibles. Mais là aussi, l'IA générative peut aider à structurer et compléter la review. Un prompt comme "Regarde tel et tel aspect de la Pull Request #123" peut aider l'IA à effectuer une première analyse. Cela me donne un point de départ pour relire efficacement même une grande PR sans me perdre dans les détails. L'IA ne remplace pas la review, elle l'assiste.
De la clarté de la part du leadership
Les Scrum Masters, chefs de projet, architectes et responsables ont pour tâche d'apporter de la clarté à des affirmations comme "Nous devons utiliser davantage l'IA" et "L'IA peut nous aider".
Il doit être clair ce que cela signifie : pas remplacer les code reviews, les développeurs juniors et tout le reste qui semble seulement coûter de l'argent en pilotage. Ce qui doit être entendu, c'est le soutien du développement ET des code reviews pour chaque développeur. L'IA doit nous permettre de mieux travailler, pas de supprimer l'assurance qualité.
Le devoir des développeurs
Il est de notre devoir, en tant que développeurs, d'assumer la responsabilité de nos propres modifications de code, qu'elles soient écrites à la main ou générées. Nous devons exiger activement des code reviews et nous accorder suffisamment de temps pour qu'elles aient lieu. C'est la seule manière d'obtenir un réel impact dans l'équipe et d'éviter que la dette technique n'explose à cause d'un code IA non maîtrisé.
TL;DR
Les agents de codage accélèrent le rythme et déplacent encore davantage la perspective vers la création de code. Il revient d'autant plus aux développeurs de corriger cette perspective et de faire suffisamment de place aux code reviews. Le management, les Scrum Masters et les architectes doivent accorder cet espace et apporter de la clarté quant à l'usage des agents de codage.
Besoin d'aide ?
Vous voulez introduire des agents de codage dans votre entreprise mais vous ne savez pas comment structurer les processus et les reviews ? Nous pouvons vous aider. Contactez-nous via notre page de contact et nous verrons ensemble comment préparer votre équipe pour l'avenir.
