Vibe coding pour designers : l'étape qui détermine si ça fonctionne

L'expérience courante est que les deux premiers écrans sont bluffants et que le dixième est un chaos. Ce n'est pas le modèle qui se dégrade. C'est qu'aucun élément du projet n'a jamais fixé l'apparence visuelle, donc chaque itération redécide tout : un espacement légèrement différent ici, un nouveau gris là, une nouvelle couleur d'accentuation parce que la précédente « paraissait un peu fade ».

Les praticiens qui livrent systématiquement décrivent la même habitude : esquisser l'infrastructure d'abord — thème, grille, typographie, couleurs — et seulement ensuite demander des fonctionnalités. Cet ordre change tout, et c'est précisément l'étape que l'on saute parce que le prompting est plus amusant.

1. 1

   Intégrez un ensemble de tokens au projet

   Des rôles de couleurs nommés pour le mode clair et sombre, une échelle typographique, des espacements, des rayons de bordure. Pas une palette, mais des rôles, pour que la réponse à « quelle couleur pour un bouton désactivé » existe avant même d'en avoir besoin. Une seule commande installe un ensemble complet si vous préférez ne pas le composer vous-même : npx shadcn add https://identityforge.io/r/ambient-sage.json.

2. 2

   Rédigez un fichier de règles qui interdit certaines pratiques

   Peu importe ce que votre outil lit — .cursor/rules/design.mdc, .devin/rules/design.md, une ligne dans CLAUDE.md. Restez sur des politiques, pas sur des goûts : utilisez uniquement les tokens sémantiques, jamais de hex brut, pas de seconde couleur d'accentuation sur un écran, ne livrez jamais un changement en mode clair sans son équivalent en mode sombre, et posez la question plutôt que d'inventer quand le système est muet.

3. 3

   Lancez un aperçu avant de construire quoi que ce soit

   Vous êtes designer ; vous validez en regardant. Si vous ne pouvez pas voir le changement s'appliquer, vous relisez du code, ce qui est précisément la chose pour laquelle vous n'êtes pas équipé.

4. 4

   Effectuez le premier commit

   Avant la première fonctionnalité. C'est votre base de référence, et à partir de là, chaque prompt est annulable. git est le bouton d'annulation — celui du chat ne l'est pas.

Le fichier de règles est plus important qu'il n'y paraît, et plus spécifiquement les interdictions. Une préférence ajoute une option ; une interdiction supprime toutes les autres. « Utilisez notre vert » laisse tous les défauts génériques valides. « N'introduisez jamais une couleur qui n'est pas un token » ne le permet pas. Nous avons analysé 299 documents de design publics écrits précisément dans ce but et 76 % ne listaient que des préférences, ce qui explique exactement pourquoi ils cessent de fonctionner vers le cinquième écran.

Le problème auto-infligé le plus courant est de demander trop de choses à la fois. Un prompt qui produit un diff de quarante fichiers est un diff que personne ne lit, ce qui signifie que la dérive visuelle s'est installée sans revue et que vous la découvrirez plus tard en vous demandant « pourquoi cette page est-elle différente ».

• Un écran ou un composant par itération. Regardez-le, commitez-le, passez à la suite.
• Commitez avant chaque prompt, pas après. Ainsi, l'état stable précédent est toujours à une commande de distance et vous n'avez jamais à décider si le dernier changement valait la peine d'être conservé tout en essayant de le corriger.
• Précisez ce qu'il ne faut pas toucher. « Modifie uniquement ce composant » évite que l'agent ne refactorise, avec une bonne intention, trois fichiers que vous aviez déjà validés.
• En cas de dérive, revenez en arrière plutôt que de négocier. Trois cycles de « non, pas comme ça » produisent un résultat bricolé qui satisfait la conversation, mais pas le design. Revenez au dernier commit stable et reformulez votre demande avec un meilleur prompt.

C'est la compétence qui vaut la peine d'être apprise : c'est une compétence de revue de design appliquée à git. Vous ne vérifiez pas si le code est bon. Vous vérifiez quatre points, et ces quatre points sont visibles sans comprendre une seule ligne de logique.

Ces quatre vérifications prennent environ une minute par diff et détectent la plupart des causes de dérive. Tout le reste — si la gestion d'état est cohérente, si la requête est efficace — n'est absolument pas votre travail à ce stade. Prétendre le contraire est précisément ce qui pousse les designers à éviter totalement la revue.

• L'acceptation complaisante. Si vous demandez « est-ce que cela respecte le design system ? », on vous répondra généralement oui. Demandez plutôt : « liste toutes les valeurs de couleur dans ce fichier qui ne sont pas des tokens » — une question dont la réponse est vérifiable.
• Le hardcoding pour que ça marche. Une valeur collée en lieu et place d'un token rend l'écran correct, mais le système erroné. Cela devient flagrant la première fois que vous modifiez un token et qu'un composant ne bouge pas.
• Corriger le résultat plutôt que la cause. Une marge ajoutée pour compenser un layout erroné deux composants plus haut. Chaque correctif est minime ; le dixième est la raison pour laquelle plus rien ne peut être modifié sans risque.
• Améliorer le système en cours de tâche. Une nouvelle couleur introduite « pour le contraste ». C'est une dérive avec une justification, et c'est le type le plus difficile à détecter car le raisonnement semble logique.
• Passer le mauvais test. Le rendu s'affiche, donc ça marche. Vérifiez le mode sombre, un état vide et une chaîne de caractères longue dans une colonne étroite avant de valider.

Moins que ce que suggèrent les cours, mais plus que zéro. Heureusement, la quantité requise est spécifique et non générale.

• Lire un diff. Vert pour les ajouts, rouge pour les suppressions, et les quatre vérifications ci-dessus. Une après-midi.
• Les bases de git. Commit, consulter un log, revenir à un commit. Une demi-heure, et c'est l'investissement le plus rentable possible.
• L'organisation des fichiers. Quel fichier correspond au thème, lequel est un composant, lequel est une page. Demandez à l'agent d'expliquer la structure une fois — il est très efficace pour cela.
• Lire une erreur. Pas la corriger. Être capable de copier-coller la partie pertinente plutôt qu'une capture d'écran de tout le terminal.

Ce dont vous n'avez pas besoin, c'est d'écrire du React, de comprendre les outils de build ou de gérer les dépendances. C'est précisément le rôle de l'agent. Le temps passé à apprendre ces notions est du temps que vous ne passez pas à maîtriser la revue, compétence que rien d'autre ne peut acquérir pour vous.

Le vibe coding est exceptionnel pour les prototypes, les outils internes, les sites marketing et pour prouver qu'une interaction vaut la peine d'être développée. Il est cependant risqué dès que l'erreur n'est pas visuelle : authentification, paiements, manipulation de données clients ou migrations. Ces échecs n'apparaissent pas dans la prévisualisation, qui est votre seul canal de revue.

Une règle simple : si le pire résultat d'une erreur est un rendu visuel médiocre, déployez et itérez. Si le pire résultat est l'altération des données ou de l'argent d'un tiers, c'est un handoff, pas un prompt.