GLOSSAIRE IA · MARCHÉ
Vibe coding
Développement piloté par l'IA
Le vibe coding consiste à décrire en langage courant l'application qu'on veut et à laisser l'IA écrire le code, en itérant sur le résultat sans forcément relire chaque ligne. La pratique a rendu le prototypage accessible à des non-développeurs, et déplacé le travail vers la description du besoin et le test du résultat.
- Origine du terme
- Début 2025
- Principe
- Décrire, tester, corriger
- Public
- Développeurs et non-développeurs
- Usage idéal
- Prototype et outil interne
- Usage risqué
- Production critique
- Catégorie
- Pratique de développement
Décrire plutôt qu'écrire
Le changement porte moins sur l'outil que sur le rapport au code produit.
Le terme est apparu début 2025 pour désigner une façon de travailler devenue possible avec les assistants de code de dernière génération : on décrit ce qu'on veut obtenir, l'IA génère le code, on regarde si ça marche, on décrit ce qui ne va pas, et on recommence. Le développeur pilote par le résultat visible plutôt que par la lecture du code.
Cette approche a explosé pour une raison simple : elle rend le prototypage accessible à des gens qui ne savent pas programmer. Un responsable marketing peut sortir un outil interne fonctionnel en une soirée, là où il aurait fallu inscrire le besoin dans une file de développement pour plusieurs semaines.
Le mot porte aussi une nuance critique, souvent perdue quand on l'emploie comme argument commercial. Le vibe coding désigne à l'origine le fait d'accepter de ne pas relire le code produit, en se fiant au comportement observé. C'est ce renoncement à la relecture qui définit la pratique, et c'est aussi ce qui en fait la limite.
Comment se déroule une session de vibe coding
Une boucle courte, répétée jusqu'à ce que le résultat tienne.
- 01
Décrire l'objectif, pas la solution
On expose ce que l'application doit faire, pour qui, avec quelles contraintes. Décrire le besoin fonctionne mieux que dicter une architecture technique qu'on ne maîtrise pas.
- 02
Laisser générer une première version
L'assistant produit une base fonctionnelle, souvent en quelques minutes. Elle est rarement bonne, mais elle est exécutable, ce qui suffit pour démarrer la boucle.
- 03
Tester et décrire l'écart
On utilise le résultat, on repère ce qui ne va pas et on le formule en langage courant : le bouton ne fait rien, la liste n'est pas triée, le formulaire accepte des dates passées.
- 04
Itérer jusqu'au comportement voulu
L'assistant corrige, on reteste. Le cycle se répète, en général une dizaine à une trentaine de fois pour une petite application.
- 05
Faire relire avant tout usage sérieux
C'est l'étape que la pratique originelle omet et que tout usage professionnel doit rajouter. Un regard humain sur la sécurité, la gestion des données et les cas limites reste indispensable.
Où le vibe coding fonctionne bien
Le critère décisif est le coût d'un bug non détecté.
-
Prototypes et maquettes fonctionnelles
Montrer une idée en état de marche plutôt qu'en diapositives change complètement une discussion de cadrage. C'est le cas d'usage le plus solide.
-
Outils internes à faible enjeu
Un tableau de bord d'équipe, un formulaire de collecte, un convertisseur maison. Si l'outil casse, personne ne perd d'argent.
-
Scripts ponctuels
Nettoyer un fichier de données, automatiser une manipulation répétitive, extraire des informations d'un lot de documents.
-
Apprentissage par la pratique
Voir du code fonctionnel produit à partir de son propre besoin est un excellent point d'entrée, à condition de prendre le temps de lire ce qui a été écrit.
-
Accélération pour un développeur confirmé
Pour qui sait relire, l'IA supprime la partie mécanique du travail. C'est là que les gains sont les plus nets, précisément parce que la relecture reste faite.
Ce que le vibe coding produit de dangereux
Les problèmes sont invisibles tant que l'application a l'air de fonctionner.
-
Les failles de sécurité ne se voient pas à l'usage
Clés d'API exposées dans le code exécuté côté navigateur, absence de contrôle d'accès, données personnelles stockées sans protection. Rien de tout cela n'empêche l'application de marcher.
-
La dette technique s'accumule vite
Au bout de quelques dizaines d'itérations, le code devient difficile à faire évoluer, y compris pour l'IA elle-même qui se met à casser ce qui marchait.
-
Personne ne sait comment ça marche
Quand le seul auteur du code est un modèle et que personne ne l'a lu, le premier incident sérieux devient très coûteux à diagnostiquer.
-
Les cas limites sont systématiquement oubliés
L'IA code le chemin nominal. Ce qui se passe quand le fichier est vide, la connexion coupée ou la valeur négative n'apparaît que lorsqu'un utilisateur réel le déclenche.
-
La conformité n'est pas gérée
Traitement de données personnelles, conservation, consentement, journalisation : aucune de ces obligations n'apparaît spontanément dans le code généré.
EN CLAIR
Pour le dire simplement
C'est faire construire une maison en décrivant les pièces à un ouvrier très rapide, sans jamais regarder les plans ni les fondations. Pour une cabane de jardin, c'est parfait et vous gagnez trois semaines. Pour une maison où vous allez vivre, il faudra bien que quelqu'un vérifie que les murs porteurs portent quelque chose.
Ce qu'il faut arrêter de croire.
-
IDÉE REÇUE
Le vibe coding rend les développeurs inutiles.
EN RÉALITÉ
Il rend le premier jet bon marché, ce qui augmente la valeur de la relecture, de l'architecture et de la sécurité. Les gains les plus importants sont mesurés chez des développeurs expérimentés, pas chez des débutants.
-
IDÉE REÇUE
Si l'application fonctionne, le code est bon.
EN RÉALITÉ
Un comportement correct ne dit rien de la sécurité, de la maintenabilité ni de la gestion des cas limites. Ce sont précisément les problèmes qui ne se voient pas à l'usage qui coûtent cher plus tard.
-
IDÉE REÇUE
C'est réservé aux non-développeurs.
EN RÉALITÉ
La pratique s'est répandue d'abord chez les développeurs, qui l'utilisent pour accélérer le travail répétitif. La différence est qu'ils relisent, ce qui change complètement le profil de risque.
-
IDÉE REÇUE
On peut mettre ça en production directement.
EN RÉALITÉ
Pour un outil interne à faible enjeu, souvent oui. Pour une application traitant des paiements, des données personnelles ou des accès, une revue de sécurité par un humain compétent n'est pas négociable.
Questions fréquentes.
Qu'est-ce que le vibe coding exactement ?
C'est le fait de développer une application en décrivant ce qu'on veut en langage courant et en laissant une IA écrire le code, en pilotant par le résultat observé plutôt que par la lecture du code produit. Le terme est apparu début 2025 avec la montée des assistants de développement.
Quels outils utiliser pour faire du vibe coding ?
Pour créer une application complète depuis une description, Lovable et Replit sont les plus directs. Pour travailler dans une base de code existante, Cursor et GitHub Copilot sont les références. Le choix dépend surtout de si vous partez de zéro ou d'un projet en cours.
Faut-il savoir coder pour faire du vibe coding ?
Non pour produire un prototype qui fonctionne. Oui pour savoir si ce prototype est utilisable en conditions réelles. C'est précisément l'écart entre les deux qui explique la plupart des mauvaises surprises.
Le vibe coding est-il sûr ?
Pas par défaut. Les failles les plus courantes sont invisibles à l'usage : clés d'accès exposées, absence de contrôle des droits, données personnelles mal protégées. Tout ce qui touche à des paiements, des accès ou des données sensibles demande une revue humaine.
Quelle différence entre vibe coding et no-code ?
Le no-code assemble des blocs préfabriqués dans une interface visuelle, sans jamais produire de code que vous possédez. Le vibe coding produit du vrai code, modifiable et hébergeable où vous voulez, mais que personne n'a nécessairement relu.
Peut-on maintenir une application créée en vibe coding ?
Cela devient difficile passé un certain volume. Le code accumule des incohérences et l'IA elle-même finit par casser ce qui fonctionnait. La parade consiste à faire relire et restructurer par un développeur avant que le projet ne dépasse le stade du prototype.
Révisé le 27 juillet 2026