Vibe Design vs Vibe Coding : où ils se séparent et pourquoi ça compte
Le vibe design et le vibe coding ne sont pas des rivaux — ce sont les deux moitiés d'un même mouvement, et c'est dans l'écart entre eux que les équipes saignent. Voici la vraie différence, les deux modes d'échec dont personne ne vous avertit (la falaise de la maquette et la dérive du design), et un cadre pour savoir lequel choisir et quand.
La plupart des explications du vibe design vs vibe coding s'arrêtent à une définition : l'un fabrique des designs, l'autre du code, fin de l'histoire. C'est vrai et parfaitement inutile. Je travaille sur la couture entre les deux chez Open Design — la partie où un design généré est censé devenir une interface qui tourne — et je peux vous assurer que ce n'est pas dans la définition que se trouve l'enjeu. L'enjeu est dans l'écart entre les deux : l'endroit où une superbe maquette ne part jamais en production, et où le code généré dérive discrètement loin de tout design cohérent. Si vous vous trompez sur la frontière, vous payez à chaque fois dans l'une de ces deux monnaies.
Ceci n'est donc pas un énième glossaire. C'est ce qui diffère réellement, les deux modes d'échec que personne ne mentionne sur la page produit, et un cadre pour savoir lequel choisir selon le moment. Si vous voulez d'abord la définition de base, le guide qu'est-ce que le vibe design l'explique.
La vraie différence : même instinct, artefact différent
Les deux partent du même instinct — décrire le vibe (une sensation, une direction, une référence) et laisser l'IA produire quelque chose, plutôt que de placer chaque rectangle à la main ou de taper chaque div à la main. Ils divergent sur ce qu'il vous reste entre les mains :
- Le vibe design produit un design — un écran, une mise en page, une maquette que vous regardez et à laquelle vous réagissez. L'artefact est une décision : « oui, cette direction. »
- Le vibe coding produit du code — un front-end qui tourne et sur lequel vous pouvez cliquer. L'artefact est un livrable : « ça marche. »
Tout le reste découle de cet unique embranchement. Un design est peu coûteux à modifier et impossible à mettre en production. Le code part en production et coûte cher à restyler. Ce qui signifie que les deux outils échouent de façons exactement opposées — et c'est cela, pas la définition, qui devrait guider votre choix.
| Vibe design | Vibe coding | |
|---|---|---|
| Ce que vous obtenez | Un design / une maquette éditable | Du code front-end qui tourne |
| Optimisé pour | Explorer une direction | Produire quelque chose qui tourne |
| Les changements sont | Peu coûteux — c'est une image | Coûteux — c'est un build |
| Livrable tel quel ? | Non — il faut le construire | Oui — mais stylé comme le modèle l'a deviné |
| Outil typique | Visily, Uizard, Figma AI | v0, Lovable, Bolt |
| Échoue par | La falaise de la maquette | La dérive du design |
Les deux modes d'échec dont personne ne vous avertit
La falaise de la maquette (l'échec du vibe design). Vous générez quelque chose de magnifique en 30 secondes, la salle hoche la tête, puis ça reste là — parce qu'une maquette est une description d'une application, pas une application. Quelqu'un doit toujours la construire, et plus la maquette est belle, plus le coût irrécupérable est élevé quand le build arrive différent. J'ai reconstruit en code le même écran « terminé » plus de fois que je n'aimerais l'admettre. La maquette donnait l'impression d'un progrès ; c'était une reconnaissance de dette.
La dérive du design (l'échec du vibe coding). C'est celui qui surprend les équipes. Demandez à un outil de génération de code écran après écran et chacun est plausible mais subtilement décalé — un rayon de bouton différent ici, un gris hors palette là, des espacements qui correspondent presque. Il y a un fil Reddit qui dit simplement « la dérive de design créée par le vibe coding est démente », et c'est tout le problème en une ligne. Le code tourne, donc on dirait que c'est parti en production — mais vous avez accumulé une douzaine d'à-peu-près qui ne forment pas un système. Personne n'a décidé du design ; le modèle l'a deviné douze fois.
Voici la partie qui compte : ces deux échecs ont la même cause racine. La falaise de la maquette et la dérive du design surviennent toutes deux parce que le design et le code ne partagent pas de source de vérité. La maquette ne sait pas comment elle sera construite ; le code ne sait pas ce que dit le design system. Réglez cette seule chose et les deux modes d'échec disparaissent en grande partie.
Lequel choisir, et quand
Laissons tomber le « ça dépend ». Voici l'arbitrage que je ferais :
Optez pour le vibe design quand l'artefact est une décision. Vous explorez une direction, vous avez besoin de l'adhésion des parties prenantes avant que quiconque écrive du code, il n'y a pas encore d'ingénieur dans la pièce, ou vous êtes dans le bazar du zéro-à-un où jeter dix directions à la poubelle est précisément l'objectif. Vous voulez le moyen le moins cher possible de voir et de rejeter des options. Ne le mettez pas en production — décidez avec.
Optez pour le vibe coding quand l'artefact doit tourner. Le prototype a besoin d'une vraie interaction, vous êtes passé de la direction au « faisons-le marcher », ou le chemin le plus rapide vers l'apprentissage est de cliquer sur quelque chose de vivant. Allez-y simplement en sachant que vous vous êtes engagé à gérer la dérive — ce qui veut dire qu'il vous faut un design system que la génération peut réellement suivre, pas seulement des vibes.
L'indice pour savoir où vous êtes : demandez-vous « la prochaine décision, c'est qu'est-ce que ça devrait être ou est-ce que ça marche ? » La première, c'est du vibe design. La seconde, du vibe coding. La plupart des équipes attrapent l'outil qu'elles préfèrent au lieu de répondre à la question qu'elles se posent réellement — c'est ça l'erreur.
La vraie réponse : faites-en une seule boucle
Le cadrage « design vs coding » est lui-même le piège. Traités comme des étapes séparées, vous obtenez un passage de relais — et les passages de relais sont là où vivent les deux modes d'échec. Les équipes qui ne saignent pas les traitent comme une seule boucle, et ce qui ferme la boucle est tout bête : un design system qui est un artefact réel et partagé auquel les deux moitiés obéissent.
C'est le pari sur lequel Open Design est bâti. Le design system n'est pas une bibliothèque Figma que le code ne peut pas lire ni un guide de style que le modèle ignore — c'est un fichier DESIGN.md portable que l'étape de design et l'étape de génération de code consomment toutes deux. Générez un design à partir de lui, générez du code à partir de lui, et la maquette ne peut plus tomber de la falaise (elle pointe déjà vers du vrai code) et le code ne peut plus dériver (il est épinglé au système). Le vibe design et le vibe coding cessent d'être un duel et deviennent un seul mouvement, de l'intention à la mise en production. Pour les outils qui vivent de chaque côté de la ligne aujourd'hui, j'ai passé le terrain en revue dans les outils de vibe design.
FAQ
Quelle est la différence entre le vibe design et le vibe coding ? Le vibe design génère un design auquel vous réagissez ; le vibe coding génère du code qui tourne et que vous pouvez utiliser. Même instinct « l'intention d'abord », artefact différent — une décision contre un livrable.
Le vibe design n'est-il pas juste du vibe coding pour designers ? Non. Le vibe coding produit du code (et le design dérive sauf si un système le contraint) ; le vibe design produit un design (qui ne part jamais en production tant que quelqu'un ne le construit pas). Ce sont des moitiés complémentaires, pas la même chose pour des publics différents.
Lequel devrais-je apprendre en premier ? Celui qui correspond à votre prochaine décision : qu'est-ce que ça devrait être (vibe design) ou est-ce que ça marche (vibe coding). À long terme, le levier réside dans le fait de les relier pour qu'aucun n'échoue seul.
Le vibe coding remplace-t-il les designers ? Il remplace le placement de rectangles à la main, pas la décision de ce qui est juste. Le jugement sur ce qui devrait exister — et le système qui le maintient cohérent — c'est exactement la partie qui ne s'automatise pas. La dérive en est la preuve.
À retenir
Le vibe design et le vibe coding ne sont pas concurrents ; ce sont les deux extrémités d'un seul mouvement, et chaque équipe qui les traite comme des étapes séparées paie le péage au milieu — une maquette qui ne part jamais en production ou une UI qui dérive. Choisissez selon la question devant vous : décider ce que ça devrait être, ou le faire tourner. Puis faites ce que presque personne ne fait — donnez aux deux moitiés le même design system auquel obéir, pour que le vibe survive tout le long, de l'intention au code en production qui vous appartient.