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. C’est là que les meilleurs modèles frontières peuvent devenir piégeux : le développeur ne prend pas nécessairement le temps de comprendre ce que l’IA code, ce qui mène à une dette de connaissance.

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. Cela suppose trois choses : arbitrer les décisions que prend l’IA, vérifier qu’elle a bien compris l’ensemble de la tâche, et lui donner les outils et l’environnement nécessaires pour implémenter et tester son code elle-même.

Garder le contrôle, c’est aussi savoir relire. 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 : on planifie, l’IA implémente, on valide. Le développeur intervient aux deux extrémités, et ce sont justement ces deux étapes qui lui permettent de garder la main et sa responsabilité vis-à-vis du code.

L’IA ne remplacera donc pas les développeurs : elle amplifiera leur productivité, mais ne déplacera pas la responsabilité du code. Le défi est de profiter de cette vitesse tout en restant maître des décisions et en comprenant ce que l’on livre.