L’intelligence artificielle a bouleversé la façon dont nous produisons du code. Aujourd’hui, n’importe qui peut générer une fonction complexe en quelques secondes, voire une application complète. Mais cette facilité a donné naissance à deux approches diamétralement opposées : le « vibe coding » aveugle et le développement augmenté par l’IA.
Comprendre la différence entre les deux n’est pas qu’une question de sémantique : c’est la frontière entre, d’une part, un projet pérenne et une performance optimale, et d’autre part, une dette technique insurmontable, voire une catastrophe en production.
Pour comprendre ce qui se joue avec l’IA aujourd’hui, il faut remonter le temps. Je suis assez vieux pour avoir connu cette époque où des développeurs puristes codaient des projets entiers sur le Bloc-notes (souvenez-vous d’UltraEdit…) ou sur des éditeurs de texte rudimentaires. Lorsqu’ont émergé les premiers IDE (Environnements de Développement Intégrés) avec l’autocomplétion intelligente, la coloration syntaxique et le refactoring automatique, une partie de la communauté a crié au scandale :
« Les développeurs vont devenir paresseux ! Ils ne connaîtront plus la syntaxe ! »
La réalité ? L’IDE n’a pas remplacé le cerveau du développeur. Il a simplement automatisé la charge cognitive inutile (se souvenir d’un point-virgule ou du nom exact d’une méthode) pour permettre au développeur de se concentrer sur l’architecture et la logique métier, d’éviter des erreurs et de gagner du temps… Bref, de gagner en productivité.
L’IA d’aujourd’hui est le nouvel IDE. Le problème survient lorsque l’on confond l’outil d’assistance avec le pilote.
Le « vibe coding » (terme que je trouve très négatif) consiste à formuler des requêtes vagues à une IA (Claude, ChatGPT, Gemini ou GitHub Copilot), à copier-coller le bloc de code généré, et à le tester. Si ça plante, on copie l’erreur et on la renvoie à l’IA jusqu’à ce que ça marche. Les mauvais développeurs avaient déjà cette même habitude du copier-coller sans discernement avec des sites comme Stack Overflow ou Reddit.
Les dangers de cette approche sont simples à comprendre :
- La dépossession du code : le développeur ne comprend pas ce que fait le code, il l’accepte simplement parce qu’il « compile ».
- Les failles de sécurité : l’IA peut halluciner ou suggérer des pratiques obsolètes et vulnérables.
- Le cauchemar de la maintenance : sans vision globale de l’architecture, le projet devient un monstre de Frankenstein (le fameux « code spaghetti »). Dès qu’un bug complexe surviendra, personne dans l’équipe ne sera capable de le déboguer sans repartir de zéro.
Prenons le cas de Claude : sans directive claire, il va devenir le roi de la duplication de code et risque de générer une architecture non maîtrisée.
À l’inverse, ce que j’appelle « l’ingénierie du développement avec l’IA », c’est le développement augmenté. Cela consiste à utiliser l’IA comme un pair-programmeur junior extrêmement rapide, supervisé par le développeur qui conserve le rôle d’architecte et de pilote.
Un développeur augmenté :
- Décompose le problème avant de solliciter l’IA ;
- Lit et critique chaque ligne de code générée ;
- Utilise l’IA pour des tâches spécifiques : générer des tests unitaires, écrire du code boilerplate (répétitif), ou expliquer un bloc de code obscur ;
- Garde la maîtrise de l’architecture logicielle, des modèles de conception (design patterns) et de la sécurité.
Utiliser l’IA efficacement passe par des règles d’équipe : comment encadrer la pratique ?
Pour qu’une équipe passe du risque du « vibe coding » à la puissance du développement augmenté, il faut un cadre et des règles de gouvernance claires. Voici quelques idées qui me semblent importantes :
Règle absolue : « Tu le génères, tu le maintiens. » C’est la règle d’or. Chaque développeur est à 100 % responsable du code qu’il pousse sur le dépôt (repo), qu’il ait été tapé à la main ou généré par une IA. En cas de bug, l’excuse « c’est Copilot qui l’a fait » est irrecevable. Cela force à lire et comprendre le code avant de le valider. Aucun code n’est commité sous le pseudo de Claude ; c’est le développeur qui est responsable de son travail.
Un développeur doit lire et comprendre chaque ligne de code générée. Si ce n’est pas le cas, il faut la réécrire. Un code non maîtrisé n’a aucune valeur. C’est d’ailleurs souvent l’occasion d’apprendre de nouvelles choses. Si vous posez la question : « Pourquoi as-tu choisi cette implémentation ? » et que l’auteur ne sait pas l’expliquer, le code doit être rejeté.
Partagez des règles de bonnes pratiques Décidez si les IA doivent avoir accès à certains serveurs ou fichiers. Il semble par exemple essentiel de partager un fichier CLAUDE.md qui interdit la lecture des fichiers de configuration contenant des mots de passe, ou qui refuse à l’IA l’accès aux serveurs de préproduction, voire de production.
Partage de contexte et standardisation des prompts Le bon usage de l’IA est une compétence qui se partage. Créez un canal de communication (ex. : Google Chat, Slack, Teams) ou une documentation interne dédiée aux meilleures requêtes (prompts) pour votre stack technique. Fournissez à l’IA le contexte global (règles de linter, architecture du projet, framework utilisé) via des fichiers de configuration ou des prompts système prédéfinis pour que l’outil génère un code qui respecte les standards de l’équipe, et non un code générique.
Limitez l’usage pour les profils juniors ou les nouveaux (le paradoxe de l’apprentissage) C’est la partie la plus difficile, mais qui me semble essentielle. Un junior qui utilise l’IA pour tout faire risque de ne jamais construire les bases logiques nécessaires pour devenir senior. Un nouveau développeur doit vous montrer ce qu’il est capable de faire sans IA. Vous n’embauchez pas une IA, mais les compétences du pilote ! Encouragez les juniors à utiliser l’IA comme un tuteur (« Explique-moi ce concept », « Pourquoi mon code plante ? ») plutôt que comme un générateur de solutions (« Écris-moi cette fonction »).
En conclusion
Tout comme l’IDE a fait passer les développeurs du statut de simples « dactylographes du code » à celui de concepteurs logiciels, l’IA nous pousse à devenir de véritables directeurs techniques de nos propres applications. Le « vibe coding » est un divertissement risqué ; le développement augmenté, encadré par des règles d’équipe strictes, est le seul véritable avenir de notre métier et ne peut lui être comparé.
Maîtrisé et encadré, le développement augmenté permet d’aller plus loin et d’apprendre plus rapidement. Contrairement au « vibe coding », c’est une pratique pérenne qui garantit un code applicatif stable en production.
