Vibe coding d’un site web : ce que c’est, et où ça déraille
Décrire le site, laisser l’assistant l’écrire, ne jamais lire le code. C’est le vibe coding, et pour un site web ça marche, à une condition.
Sur cette page
TL;DR
Le vibe coding consiste à construire un logiciel en le décrivant à une IA et en acceptant le code sans le lire. Un site web est le meilleur cas possible : le résultat, ce sont quelques fichiers statiques que n’importe qui peut juger en les regardant. Là où ça rate est prévisible : contenu inventé, images qui cassent, premier écran trop lourd, look de template, et rien de relu. Le remède n’est pas de lire le code. C’est une discipline : brief, construction, relecture, publication, et un retour arrière si on s’est trompé.
Ce que vibe coding veut vraiment dire
L’expression date de février 2025, quand Andrej Karpathy a décrit une façon de travailler où l’on « s’abandonne complètement aux vibes », où l’on parle à l’assistant, où l’on accepte ce qu’il écrit sans lire le diff, et où l’on décrit un bug en mots plutôt que de le corriger soi-même. C’était à moitié une blague. C’est devenu le mot pour tout ce qui se construit en conversation.
Il vaut la peine d’être précis, parce que le mot couvre aujourd’hui aussi bien un prototype de week-end qu’une entreprise. Le vibe coding n’est ni un produit ni un outil. C’est une posture : le code est un moyen, on juge le résultat, et on n’ouvre jamais le fichier. Que cette posture soit imprudente ou sensée dépend entièrement de ce qu’on construit.
Pourquoi un site web est le cas facile
La plupart des mises en garde sur le vibe coding visent des applications : des choses avec des comptes, une base de données, des paiements, les données d’autres personnes. Là, un code qu’on n’a pas lu peut fuir, perdre ou exposer quelque chose, et rien ne le montre à l’écran. L’écran a l’air correct jusqu’au jour où il ne l’est plus.
Un site web, c’est l’inverse. Un site statique, ce sont quelques fichiers, du HTML, du CSS, des images, et tout ce qu’il fait est visible. S’il manque une section, vous la voyez. Si le numéro de téléphone est faux, vous le voyez. Pas de serveur à compromettre, pas de base à faire fuir, rien qui tourne quand personne ne regarde. La règle « ne lisez pas le code » ne coûte rien quand le code est une page.
C’est pour ça qu’un assistant peut construire un vrai site web aujourd’hui, et que le résultat est le même HTML qu’un développeur livrerait pour un site simple. Le risque n’est pas la vibe. C’est ce que vous n’avez pas demandé.
Les cinq façons dont ça déraille
On les retrouve sur presque tous les sites générés que nous regardons, et aucune n’est une erreur de code. C’est tout le sujet : lire le code n’en aurait attrapé aucune.
- Un contenu qui se lit comme vrai et ne l’est pas. Un témoignage, une année de création, un nom de client, inventés pour combler un trou, mis en forme comme du vrai, et oubliés là.
- Des images qui cassent plus tard. L’assistant fait pointer une photo vers un fichier sur le site de quelqu’un d’autre, et un jour ce site le déplace. Personne ne vous prévient.
- Un premier écran de trois mégaoctets. Le modèle n’a aucune idée du poids du fichier qu’il vient de référencer, et un premier écran lent perd des visiteurs avant qu’ils aient lu un mot.
- Le look de template. Un hero centré, trois cartes, des icônes génériques, des ombres douces partout. Pas faux, juste la moyenne de toutes les pages qu’il a vues.
- Rien de relu. L’assistant qui vient d’écrire la page en est le pire juge, et le deuxième pire, c’est vous, trente secondes après la démo.
Chacun de ces ratés est visible sur la page. Le vibe coding d’un site échoue au grand jour, et c’est exactement pour ça que ça se répare.
La vibe, c’est le brief
Voici ce que le mot cache : la qualité d’un site vibe-codé se décide avant la première ligne de code, dans ce que vous avez dit. « Fais-moi un joli site pour mon atelier » vous donne la moyenne. Ce que vous vendez et à qui, l’action unique qu’un visiteur doit faire, trois preuves, vos informations pratiques, et une courte liste de ce que vous ne voulez pas : ça vous donne un site sur vous.
Vibe ne veut pas dire vague. Les gens qui obtiennent de bons résultats d’un assistant ne lisent pas mieux le code. Ils disent mieux ce qu’ils veulent, et ils demandent à l’assistant de les interviewer quand ils ne le savent pas. Le premier guide, c’est cette conversation, écrite noir sur blanc.
La discipline : brief, construction, relecture, publication
- Le brief. Quatre réponses et une liste de ce que vous ne voulez pas, en un message. Demandez à l’assistant de vous interviewer d’abord si vous préférez ne pas l’écrire.
- La construction. Une page, dans l’ordre qui convertit : hero, offre, preuves, contact, pied de page. Une action, répétée avec le même libellé.
- La relecture. Demandez à l’assistant de s’arrêter, de changer de rôle et de noter son propre travail en directeur artistique sur huit axes. Corrigez le point le plus faible. Deux passes, pas dix.
- La publication. Dites-le. Avec un connecteur, le site part en ligne dans la même conversation, sur une vraie adresse, en une version qui n’est jamais perdue.
- Le retour arrière si vous vous êtes trompé. La version d’avant est de nouveau en ligne en une phrase. Publier n’est pas une porte sans retour.
Remarquez ce qui n’est pas dans la liste : lire le code. La relecture est une passe notée par l’assistant lui-même, et le filet de sécurité est une version à laquelle revenir. C’est toute la discipline, et elle tient en cinq messages.
Le vibe coding ne veut pas dire sauter la relecture. Il veut dire que la relecture est une phrase, pas une lecture de code.
Où s’arrête le vibe coding d’un site
Les limites, honnêtement. Une boutique avec un panier, des comptes clients, un moteur de réservation qui encaisse, un espace membres : ce sont des applications, avec de l’état et des données, et c’est là que les mises en garde s’appliquent. Faites-les avec un développeur, ou avec un service fait pour ça.
Ce qu’un site statique peut encore faire dépasse ce qu’on croit : un formulaire de contact, un lien de réservation, un lien de paiement, une carte, une vidéo intégrée, un agenda, des données structurées qui le rendent trouvable. La documentation trace la ligne précisément. Pour un portfolio, un cabinet, un restaurant, un événement ou une page de lancement, la ligne est très loin de vous.
Dites ceci
Construis-moi un site d’une page à partir de ce brief. Avant d’écrire du code, demande-moi ce qui te manque plutôt que de l’inventer. Quand c’est fini, relis-le en directeur artistique, note la typographie, la composition, la hiérarchie, le mouvement, la copie, l’anti-template, les images et l’accessibilité, corrige le point le plus faible, et seulement ensuite dis-moi qu’il est prêt à publier.
Questions fréquentes
Qu’est-ce que le vibe coding ?
Une façon de construire un logiciel en décrivant ce qu’on veut à un assistant IA et en acceptant le code qu’il écrit sans le lire. Le terme vient d’Andrej Karpathy, en février 2025, et couvre aujourd’hui l’essentiel de ce qui se construit en conversation.
Peut-on vibe-coder un site web ?
Oui, et c’est le meilleur cas : un site statique, ce sont quelques fichiers dont chaque résultat est visible sur la page, sans serveur, base de données ni données d’utilisateurs en jeu. Ce qui décide de la qualité, c’est le brief que vous donnez et la relecture que vous demandez, pas le code.
Le vibe coding est-il sûr pour un site web ?
Pour un site statique, les risques sont visibles : contenu inventé, images liées ailleurs, premier écran trop lourd, look de template. Aucun n’est un problème de sécurité. Les applications avec comptes, paiements ou base de données sont une autre affaire et demandent un vrai développement.
Dois-je lire le code que mon assistant a écrit ?
Pas pour un site statique. Demandez à l’assistant de relire son travail en directeur artistique et de le noter, publiez en version, et revenez en arrière si une version est mauvaise. La relecture est une phrase, pas une lecture de code.