Jorge Ataíde

codeTAC · 2026

Vibe coding : la vitesse avec responsabilité

Le vibe coding accélère la production de code, mais il n'est durable que si celui qui le livre connaît le code qui a été généré.

Qu'est-ce que le vibe coding

Avec le vibe coding, le développeur décrit ce qu'il veut en langage naturel et un assistant d'IA écrit le code. Le cycle consiste à demander, tester dans l'interface, demander à nouveau. Souvent, personne ne lit le code ligne par ligne : si ça marche à l'écran, on avance.

Cela a une vraie valeur. Dans bien des cas, des prototypes qui prenaient des semaines sont prêts en quelques heures, et des personnes sans formation technique approfondie parviennent à construire des outils utiles.

Le problème : du code sans propriétaire

Quand personne ne comprend le code, personne n'en est vraiment responsable. Les risques apparaissent plus tard, presque toujours en production :

• Maintenance : une modification simple oblige à tout redemander à l'IA, sans savoir ce qui va casser.
• Débogage : quand quelque chose échoue, le développeur ne sait pas par où commencer à chercher.
• Sécurité : des clés exposées dans le code, des validations manquantes, une logique sensible exécutée côté client ou des dépendances que personne n'a demandées passent inaperçues.
• Architecture : chaque demande ajoute une couche ; le projet grandit sans structure cohérente et avec du code dupliqué.
• Transmission : un nouveau membre de l'équipe hérite d'un système que même son auteur ne sait pas expliquer.

Pourquoi connaître le code reste nécessaire

L'IA écrit le code, mais la responsabilité reste à celui qui le livre. Un développeur qui connaît le code peut évaluer ce que l'IA propose, refuser les mauvaises solutions et expliquer le système à un client, à un auditeur ou à un collègue.

Connaître le code ne veut pas dire en avoir écrit chaque ligne. Cela veut dire savoir répondre à des questions simples : où se trouve la logique de cet écran, d'où viennent ces données, que se passe-t-il quand on clique sur ce bouton, qu'est-ce qui casse si je change ceci.

Comment rendre les développeurs connaisseurs de leur code

1. Relire en proportion du risque. Traiter les modifications de l'IA comme la pull request d'un collègue, avec plus d'attention là où l'erreur coûte le plus : authentification, paiements, données personnelles, accès à la base de données. L'interface et les styles peuvent faire l'objet d'une relecture plus légère.
2. Demander des explications à l'IA, et les vérifier. Utiliser l'assistant pour expliquer ce qu'il a fait et pourquoi, mais vérifier l'explication dans le code : l'IA peut décrire avec assurance quelque chose qu'elle a fait autrement.
3. Cartographier le code à partir de l'interface. Relier chaque élément visible au fichier, à la fonction et aux données qui le soutiennent.
4. Tout garder sous contrôle de version. Des commits petits et fréquents, un par itération, permettent de voir exactement ce qui a changé et de revenir en arrière quand une demande casse ce qui fonctionnait.
5. Des tests qui définissent le comportement. Décider d'abord ce que le code doit faire, et seulement ensuite demander les tests. Les tests écrits par l'IA à partir du code lui-même ont tendance à confirmer ce qu'il fait, pas ce qu'il devrait faire.
6. Documenter les décisions. Consigner l'architecture et les choix principaux dans un document vivant, mis à jour à chaque itération. C'est la mémoire du projet.
7. Une validation humaine explicite. Définir des points de contrôle (avant une livraison, avant la mise en production) où une personne confirme qu'elle comprend et approuve ce qui a été fait. C'est le moment de la décision.

Conclusion

Le vibe coding change qui écrit le code, pas qui en répond. La vitesse n'est payante que si elle s'accompagne de compréhension ; sinon, le temps gagné aujourd'hui se paie avec intérêts à la prochaine panne.

Lien permanent →