Le terme de vibe coding s’est imposé dans le vocabulaire, et il traduit une réalité : une IA frontière est aujourd’hui capable de produire du code qui, à la fin, marche. Mais ce code fonctionne un peu comme une boîte noire, dont on ne sait pas exactement de quoi l’intérieur est fait. Pour des prototypes, pour montrer une démonstration de faisabilité, c’est super. Pour le mettre en production, c’est une autre affaire.

Car les projets dans lesquels il y a, par la suite, une mise en production ont un fort impact, que ce soit sur les clients ou sur les équipes en interne. Il ne suffit plus que le code marche le jour où on le livre : il faut pouvoir le comprendre pour le maintenir dans les mois qui suivent.

Et c’est là que se joue l’essentiel : ne pas s’approprier le code qu’il y a derrière est une très mauvaise idée. Il faut comprendre tous les éléments du code, parce que si on ne les comprend pas, on ne se les approprie pas, et on ne s’approprie donc pas la responsabilité qui va avec.

Tout l’enjeu est donc de garder le contrôle sur le code, et cela passe par le fait de rester dans la boucle de développement. Concrètement, cela suppose d’arbitrer les décisions que prend l’IA, car elle n’a jamais tout le contexte. Elle ignore qu’une dépendance a été écartée pour des raisons de sécurité, ou qu’un service maison existe déjà et qu’il faut passer par lui ; elle ignore, plus simplement, que l’équipe a ses bibliothèques de prédilection. C’est donc à l’équipe d’imposer sa stack à l’IA, plutôt que l’inverse, et c’est de cette manière que le développeur qui est derrière garde le contrôle.

Ce contrôle ne s’arrête pas au choix de la stack. Je pense que le métier se déplace : moins de tâches de codage, davantage de tâches de relecture. Encore faut-il en être capable, car pour relire il faut garder la main sur le code. Il faut toujours savoir coder pour bien relire, et cela vaut dans tous les domaines : relire un système fondé sur un LLM ou l’entraînement d’un modèle de machine learning demande d’être compétent dans les bibliothèques et dans le langage concernés. C’est cette compétence qui permet ensuite de challenger les idées de l’IA, et challenger est une autre façon de reprendre le contrôle : si on sait discuter une proposition, c’est qu’on sait pourquoi elle a choisi ce code et pas un autre.

Ces manières de rester impliqué dessinent en réalité une boucle, dans laquelle le développeur est présent du début à la fin. On planifie, l’IA implémente, on valide. Le développeur intervient donc aux deux extrémités, et c’est précisément là que se prennent les décisions.

L’IA ne remplacera donc pas les développeurs, elle amplifiera leur productivité. Mais elle ne déplace pas la responsabilité : celle-ci reste entière du côté de celui qui livre.