Limites du vibe coding : pourquoi l’IA ne remplace pas une méthode.

Décrire une application en langage naturel et la voir générée en quelques minutes : c’est la promesse du vibe coding. Lovable, Bolt, Cursor ou Claude Code la rendent accessible à tous. Pour un prototype, le gain est réel. En production, les limites du vibe coding apparaissent vite : sécurité, dette technique, conformité, cohérence visuelle. Nous utilisons ces outils au quotidien chez Astraga.

Voici ce qu’ils apportent, où ils échouent, et comment nous les encadrons.

Le vibe coding, de quoi parle-t-on ?

Andrej Karpathy, cofondateur d’OpenAI et ancien responsable de l’IA chez Tesla, a lancé le terme en février 2025. Le principe : décrire ce que l’on veut, laisser l’IA générer le code, observer le résultat, affiner. On juge l’application sur son comportement, pas sur la qualité du code.

Un an plus tard, Karpathy a nuancé. Il juge le vibe coding déjà dépassé par les progrès des modèles et propose un autre terme : l’« agentic engineering ». Il s’agit d’orchestrer des agents IA avec une rigueur professionnelle plutôt que de se laisser porter.

Le glissement est révélateur. La question n’est plus de savoir si l’IA sait coder, mais comment l’encadrer.

Ce que le vibe coding apporte vraiment

Les bénéfices sont concrets :

• Prototypage rapide : un prototype cliquable se construit en une après-midi.
• Test avant chiffrage : une fonctionnalité peut être éprouvée avant d’être estimée.
• Code répétitif : formulaires, listes et composants standards sont produits en quelques secondes.
• Échanges simplifiés : un chef de projet ou un designer matérialise une intention sans attendre un développeur.

En avant-projet, en atelier client ou en preuve de concept, c’est un accélérateur utile.

Les limites du vibe coding en production

La dette technique

Chaque itération ajoute du code que personne n’a conçu. Après des dizaines d’allers-retours, le projet devient un empilement de correctifs. Il fonctionne, mais personne ne sait expliquer pourquoi. Le faire évoluer coûte alors plus cher que l’avoir construit.

La sécurité

Selon le rapport 2025 de Veracode, 45 % des échantillons de code générés par IA échouent à des tests de sécurité. Une analyse de CodeRabbit portant sur 470 pull requests relève environ 1,7 fois plus de problèmes dans le code co-écrit par IA que dans le code humain.

Sur un site vitrine, une faille est gênante. Sur une boutique en ligne, un extranet ou un outil de paiement, elle est inacceptable.

Les données personnelles et le RGPD

Une IA génère un formulaire sans se demander où partent les données, combien de temps elles sont conservées ni sur quelle base légale elles sont collectées. Les obligations du RGPD s’appliquent de la même façon, que le code soit écrit par un développeur ou par une machine. Chaque traitement doit être vérifié par un humain.

L’incohérence visuelle

Demandez trois fois le même bouton, vous obtenez trois boutons différents. Les marges varient, les couleurs dérivent, les typographies se mélangent. L’IA ne connaît pas votre charte si on ne la lui fournit pas.

Le problème n’est pas l’IA, c’est le cadre qu’on lui donne

Les analyses sérieuses convergent : la limite décisive est le cadrage humain, c’est-à-dire la revue, l’architecture et la validation. Une IA à qui l’on demande « une page d’accueil moderne » invente. Une IA qui dispose d’une charte, de composants documentés et de règles précises exécute.

Nous avons donc choisi de traduire notre méthode dans un format que l’IA sait lire.

Notre R&D : un kit de cadrage pour travailler avec l’IA

Un nouveau développment ne commence pas sans connaître la charte, les composants existants et les usages de l’équipe. Avec l’IA, cette étape est souvent oubliée. Notre kit de cadrage la rend systématique. Il prolonge le travail de conception mené avec le client.

Des règles écrites pour chaque projet

Un fichier de règles, du type AGENTS.md, décrit le projet à l’IA : l’architecture, les conventions de nommage, les composants à réutiliser, les interdits. Il est lu avant chaque génération.

Des design tokens à la place des valeurs inventées

Les couleurs, typographies et espacements de la marque deviennent des variables nommées : les design tokens. L’IA doit les utiliser et n’a pas le droit d’en créer. Elle ne propose plus un bleu approximatif : elle applique le bleu de la marque.
L’objectif est que la relecture porte sur la logique et la sécurité, plus sur les couleurs et les marges.

Brancher le kit sur WordPress et Drupal

Un cadre n’a de valeur que s’il vit dans l’outil où le site est géré au quotidien.

Sur WordPress, les tokens sont déclarés dans le fichier theme.json. La palette, les typographies et les espacements y sont définis une seule fois. Ils sont exposés à la fois à l’éditeur Gutenberg et au code généré. La désactivation des couleurs libres empêche les contributeurs comme l’IA de sortir de la palette.

Sur Drupal, les composants à fichier unique (Single Directory Components) regroupent le gabarit, les styles et la description d’un composant. Ils offrent à l’IA une bibliothèque claire à réutiliser.

Dans les deux cas, ce que l’IA produit doit rester modifiable par le client. Générer une section est simple. En faire un bloc que l’équipe met à jour sans casser la mise en page demande de définir ce qui est modifiable et ce qui est verrouillé. Sous WordPress, les compositions de blocs verrouillées remplissent ce rôle.

Enfin, le kit suit l’évolution de la marque. Une couleur modifiée dans les tokens change partout, sans report manuel.

Les projets qui s’y prêtent moins

Les sites construits avec des constructeurs de pages visuels stockent souvent les styles page par page. Ils se laissent difficilement encadrer. Sur ces projets, le kit sert de référence de cohérence et prend tout son intérêt lors d’une refonte de site.

Ce kit devient un livrable à part entière. Notre équipe ou celle du client peut s’en servir pour faire évoluer un site ou un outil interne sans trahir l’identité définie ensemble.

Questions fréquentes sur le vibe coding

Un site créé en vibe coding est-il sécurisé ?

Pas par défaut. Le code généré doit être relu par un développeur, en particulier sur l’authentification, les formulaires, les paiements et les données personnelles. La maintenance et sécurité reste indispensable dans la durée.

Peut-on reprendre une application générée par IA ?

Oui, après un audit qui mesure la qualité du code, les failles et la faisabilité d’une reprise. C’est le principe de notre reprise de site existant.

Le vibe coding convient-il à une application métier ?

Pour un prototype, oui. Pour une application en production, l’architecture doit être conçue par des développeurs, puis l’IA peut accélérer la réalisation. Voir notre développement d’application métier.

Ce que nous en retenons

Le vibe coding ne rend pas les agences inutiles et ce n’est pas un gadget. C’est un accélérateur, à condition de rester à sa place : l’IA produit, l’humain conçoit, cadre et valide.
Notre rôle évolue en conséquence. Nous livrons une maquette et un site, et désormais le cadre qui permet à une IA de prolonger ce travail correctement. La charte graphique s’adresse aussi aux machines.
Pour la sécurité, les données personnelles, les paiements et l’architecture, la relecture par des développeurs expérimentés reste indispensable.
Vous avez une application générée par IA à fiabiliser, ou un projet à cadrer avant de l’accélérer ? 

Vous réfléchissez à intégrer l’IA dans vos processus de conception ou de développement ? Parlons-en : contactez-nous.