Vibe coder son site sans tomber dans les mêmes pièges : le mode d'emploi

Suite de l'article « J'ai refait mon site sans savoir coder ». Si le premier billet racontait les pièges traversés, celui-ci documente comment je referais le projet aujourd'hui, dans l'ordre, avec les briques utilisées et les garde-fous qui m'auraient évité plusieurs semaines de tâtonnement.

Si vous voulez juste lire les leçons pour les achats et passer le mode d'emploi technique.

Cadrer le scope avant de toucher au code

L'erreur fondatrice du premier projet a été de me lancer sans cadre écrit. « Je refais mon site » n'est pas un scope, c'est une intention. Le scope, c'est la liste explicite de ce qui rentre et de ce qui sort, avec un budget temps associé à chaque bloc.

Aujourd'hui, je commencerais par poser sur une page de Notion les éléments suivants, et je ne lancerais aucune commande tant qu'ils ne seraient pas tranchés.

D'abord, le périmètre fonctionnel : combien de pages, quelles fonctionnalités sont indispensables au lancement, lesquelles peuvent venir en v2. Mon premier projet a explosé sur ce point précis. Soixante pages de funnel, des outils d'assessment, des démos interactives, rien de tout ça n'était au scope initial, tout ça s'est rajouté en cours de route parce que le vibe coding rendait l'ajout trop facile pour résister à la tentation.

Ensuite, le budget temps maximal. Pas une estimation optimiste : un plafond au-delà duquel on s'arrête, on évalue, on tranche. Un acheteur sait faire ça pour un appel d'offres. On l'oublie pour ses propres projets.

Enfin, les critères de succès mesurables. Pour mon site, ça aurait dû être : pas de régression de visibilité Google sur les pages clés à 90 jours, temps de chargement comparable ou meilleur que l'ancien site, taux de conversion équivalent ou supérieur. Sans ces critères, on ne sait pas si le projet a réussi. On a juste un site différent.

Ce cadrage prend deux heures. Il économise plusieurs semaines.

Avant toute commande, cadrer trois choses.

Les briques qui font tourner le site

Plutôt que de lister un stack technique, voici la même chose vue côté fonction : qu'est-ce que chaque brique apporte concrètement au site, et pourquoi c'est utile.

La couche visible, ce que voient les visiteurs. Une application moderne qui génère les pages côté serveur, ce qui veut dire concrètement : les pages s'affichent vite, et Google voit le contenu correctement quand il indexe le site. C'est l'opposé d'une « application web qui charge en JavaScript dans le navigateur », où Google voit souvent une page vide. Pour un site qui dépend du référencement organique, ce point n'est pas négociable. (Pour les curieux du nom : Next.js.)

Le système de gestion de contenu, où j'écris mes articles et mes pages. Une interface d'administration intégrée au site, qui me permet de créer ou modifier des contenus éditoriaux sans toucher au code. La grosse différence avec WordPress : le système est en code et ne dépend d'aucun plugin tiers. Le risque de mise à jour qui casse tout disparaît. (Payload CMS.)

Le coffre des données, utilisateurs, progressions, certifications. Une base de données qui stocke tout ce qui doit survivre à un rechargement de page : les comptes d'apprenants de la plateforme de formation, leur progression dans chaque cours, leurs certifications obtenues, l'historique de leurs connexions. C'est la mémoire de la plateforme. (Supabase, qui repose sur Postgres.)

L'identification, comment l'utilisateur se connecte. Pour la plateforme de formation, j'ai choisi la connexion par compte Google plutôt que par mot de passe. L'utilisateur clique sur « Se connecter avec Google », confirme, et il est dans son espace. Aucun mot de passe à gérer, aucune procédure « j'ai oublié mon mot de passe », et une surface d'attaque qui se résume à la sécurité du compte Google de l'utilisateur, qui est largement meilleure que ce que je pourrais coder moi-même.

L'hébergement et la mise en ligne, comment le site arrive sur internet. Le code vit dans une archive en ligne (GitHub). Chaque modification que je sauvegarde dans cette archive déclenche automatiquement une mise à jour du site visible, en deux ou trois minutes. Pas de « FTP », pas de manipulation manuelle, pas de risque d'oublier un fichier. (Vercel pour l'hébergement, GitHub pour l'archive du code.)

Le nom de domaine. Hostinger, en mode passif. Aucun hébergement WordPress, aucun panneau d'administration utilisé. Juste les paramètres qui font que theprocurementor.com pointe vers la bonne machine.

La prise de rendez-vous. Une page de réservation autonome, intégrée au site, qui permet à un prospect de prendre un créneau dans mon calendrier sans passer par un échange d'emails. J'ai migré de Calendly vers Cal.com pour gagner en granularité sur les types d'événements (audit gratuit 30 min, appel commercial 45 min, atelier de cadrage 90 min) et pour bénéficier d'options gratuites plus larges.

L'envoi d'emails. Brevo pour les newsletters et les communications marketing. Un point qui semble anodin mais ne l'est pas : avant le premier envoi, il faut paramétrer ce qu'on appelle l'authentification du domaine (en pratique, trois enregistrements techniques chez le fournisseur DNS). Sans ça, les emails partent en spam et la réputation du domaine se dégrade durablement.

Ce stack a deux qualités fonctionnelles. Tout est code-contrôlé, donc transférable d'une plateforme à une autre si besoin. Et chaque brique a une porte d'entrée pour l'IA (j'y reviens dans la section suivante), donc maintenable par un solo opérateur.

Le stack vu côté fonction, en huit briques.

Le process IA en deux temps

La deuxième leçon majeure, c'est qu'il ne faut pas envoyer l'IA coder dès le premier prompt. Le bon flux a deux temps distincts.

Temps 1 : la co-conception avec l'IA dans le navigateur. Avant d'écrire la moindre ligne de code, j'ouvre une conversation avec Claude, je décris le besoin, je joins le contexte (mon stack, mes contraintes, ma marque, mes erreurs passées). Je demande un plan d'implémentation détaillé. Je le lis, je le critique, je le fais itérer. Plusieurs tours. L'objectif est de transformer une idée vague en une spécification fonctionnelle suffisamment précise pour qu'un agent code la suive sans réinventer.

Cette phase produit un document que je sauvegarde dans Notion : ce qu'on construit, dans quel ordre, avec quels outils, quels tests à effectuer. C'est ce document qui devient l'instruction d'implémentation.

Temps 2 : l'implémentation avec l'IA dans le terminal. Claude Code prend le plan, lit le repo, et l'implémente. Ma valeur ajoutée à cette étape est essentiellement de la revue : je lis les changements proposés sans tout comprendre techniquement, je vérifie que rien d'inattendu n'a été ajouté, je teste la page concernée avant de publier.

La discipline cruciale : ne pas re-concevoir pendant l'implémentation. Si je vois en cours de route qu'il manque un truc, je note l'idée pour une itération suivante, je ne la balance pas dans la commande en cours. C'est exactement ce que je n'ai pas fait sur la première version du site, et c'est ce qui a généré les soixante pages de funnel.

Le process IA, en deux temps distincts.

Les connecteurs qui transforment l'IA en assistant opérationnel

Le différentiel de productivité ne vient pas de l'IA toute seule. Il vient des connecteurs qui lui permettent d'agir directement dans les outils de ton stack, sans que tu joues le facteur entre les deux.

Trois m'apparaissent indispensables pour ce type de projet.

Le connecteur vers le système d'hébergement. Sans lui, à chaque erreur de mise en ligne, je dois copier le message d'erreur depuis l'interface du fournisseur et le coller dans le chat. Avec lui, l'IA récupère l'info elle-même, identifie ce qui ne va pas, propose un correctif, et peut même relancer une publication. Le gain de temps est immédiat dès la deuxième erreur de la journée. (Le connecteur Vercel, dans mon cas.)

Le connecteur vers l'archive du code. Il donne accès à l'historique : qui a changé quoi quand, quelles modifications ont été refusées, quelles branches sont en attente de revue. Utile pour les diagnostics du type « pourquoi cette fonctionnalité s'est mise à fonctionner différemment la semaine dernière », sans avoir à reconstituer l'historique de mémoire. (Le connecteur GitHub.)

Le connecteur vers la base de données. Il permet à l'IA d'inspecter directement la structure des données, de proposer des évolutions de cette structure, et d'exécuter des consultations en lecture seule pour diagnostiquer une donnée qui ne s'affiche pas correctement. Le différentiel de productivité par rapport à passer par une interface web à chaque vérification est très net. (Le connecteur Supabase.)

Ces trois connecteurs couvrent 80 % des opérations quotidiennes. À ajouter selon les besoins : un connecteur vers Notion si la documentation projet vit là, un connecteur analytics si tu veux que l'IA corrèle un comportement utilisateur avec un bug.

Un piège peu documenté : chaque connecteur actif consomme de la mémoire de travail de l'IA, même quand on ne s'en sert pas dans la session en cours. Au-delà de trois ou quatre connecteurs actifs en même temps, l'IA devient moins précise sur le reste. La discipline est d'activer uniquement ceux dont on a besoin pour la session, et de désactiver les autres.

Les 3 connecteurs indispensables.

Verrouiller la marque avant de coder

Un piège que j'ai sous-estimé : la marque doit être documentée avant que l'IA touche au design. Sinon, chaque session re-invente les couleurs, les espacements, la typographie, et tu passes des heures à rétablir une cohérence.

Le minimum à fournir au début du projet :

Les couleurs primaires et secondaires avec leurs codes exacts. Pour theprocurementor.com, c'est un dark #1b2a34, un teal #00ac97, un accent lime #cff42a. La police principale et la police secondaire avec leur usage défini (Montserrat pour les titres, Poppins pour le corps, dans mon cas). Les principes typographiques : taille de base, hiérarchie, espacement. Le ton éditorial : pour moi, praticien-direct, sans jargon excessif, sans engagement bait. Et enfin quelques exemples concrets de pages ou composants qui incarnent la marque, comme référence pour les nouvelles créations.

Je garde ce document dans un fichier BRAND.md à la racine du projet. L'IA le lit automatiquement quand je lui demande de créer ou modifier un composant. Le gain de cohérence est immédiat.

Verrouiller la marque avant que l'IA touche au design.

Tester en aperçu, pas en production

C'est probablement le conseil qui m'aurait fait gagner le plus de temps si on me l'avait donné au début.

Le principe : chaque modification peut être déployée sur une copie temporaire du site, accessible sur une adresse dédiée, avant d'être publiée pour les vrais visiteurs. C'est l'équivalent d'un brouillon de document Word qu'on relit avant de l'envoyer au client. La copie temporaire est complète : la page de contact fonctionne, les formulaires envoient, les paiements peuvent même être testés en mode bac-à-sable. Mais ton vrai site, lui, n'est pas affecté.

Le bon réflexe est donc de ne jamais publier directement en production. Chaque changement, même mineur, part d'abord sur un aperçu. Tu testes là. Si ça casse, ton site visible reste intact. Tu corriges. Une fois validé, tu valides la mise en production officielle.

Pour quelqu'un qui ne sait pas coder, c'est le filet de sécurité le plus important du dispositif. Le coût en temps est marginal, deux minutes d'attente pour la génération de l'aperçu. Le coût d'une régression non détectée en production est, lui, démultiplié : pages cassées, formulaires qui n'envoient plus, prospects qui voient une erreur sur la page services et ne reviennent pas.

Pendant les six premiers mois de mon projet, je publiais directement en production parce que je ne comprenais pas l'utilité de ce filet. C'est aussi pour ça que mon référencement a souffert. Ne refais pas cette erreur.

Tester en aperçu, pas en production.

Les autres pièges que je n'ai pas couverts dans le premier article

Quelques sujets que j'ai vus mordre d'autres solo opérateurs autour de moi, et qu'il vaut mieux anticiper.

Les identifiants sensibles. Une clé d'accès à un système de paiement ou à une base de données qui se retrouve par accident publique sur internet est exploitée en quelques heures, et l'addition se présente. La règle absolue : aucun identifiant en clair dans le code. Les fournisseurs sérieux (Vercel, par exemple) proposent un coffre-fort dédié, par projet et par environnement. À utiliser systématiquement.

Les évolutions de versions. Les composants logiciels qui font tourner le site évoluent en permanence. Une mise à jour mineure d'un composant peut changer un comportement subtil sans que tu t'en rendes compte. La discipline : figer les versions exactes au moment où ça marche, et ne mettre à jour qu'en sachant pourquoi et en testant en aperçu d'abord.

Le suivi des changements de structure de données. Au début, c'est tentant de modifier la structure de la base de données directement dans l'interface web du fournisseur. Au bout de trois mois, plus aucune trace de qui a changé quoi quand, et recréer un environnement de test devient impossible. À adopter dès le premier changement de structure : un journal des évolutions, géré comme du code, versionné, traçable.

La conformité RGPD et les bandeaux cookies. Si le site fait du tracking analytics ou marketing, il faut un bandeau de consentement et des mentions légales conformes. C'est pénible, ça n'a pas l'air de matter, et puis un client allemand pose la question avant signature et tu passes une journée à régulariser.

Le suivi des erreurs en production. Le fournisseur d'hébergement alerte quand une mise en ligne échoue, mais pas quand un visiteur rencontre une erreur sur le site live. Sans système de suivi dédié, on ne sait pas qu'un formulaire est cassé tant qu'un prospect ne le signale pas, et il ne le signale pas, il va voir ailleurs. Un outil de monitoring (Sentry est le plus connu) remonte les erreurs rencontrées par les utilisateurs et te les notifie.

La sauvegarde et la procédure de restauration. Le code est sauvegardé par l'archive en ligne, ça suffit. La base de données, c'est moins évident. Selon le plan choisi chez le fournisseur, des sauvegardes automatiques sont incluses ou non. Le point critique : tester au moins une fois la procédure de restauration. Une sauvegarde qu'on n'a jamais restaurée n'est pas une sauvegarde, c'est un espoir.

Les pièges en plus à anticiper.

[Unsupported MDX element: a]

Pour conclure

Si je devais résumer la différence entre le projet initial et la version 2 mentale de ce que je ferais aujourd'hui, c'est l'introduction d'un cadre minimal là où je m'étais lancé sans.

Le vibe coding ne se substitue pas à la discipline projet. Il accélère brutalement l'exécution. Si la discipline manque, l'accélération produit du désordre en plus de la productivité. Si la discipline est là, le levier est réel et difficile à concurrencer.

Discipline + accélération, le vrai levier.

Pour une direction achat qui réfléchit à équiper ses équipes en outils internes vibe-codés, le sujet n'est donc pas l'outil. Le sujet est le cadre. Un acheteur formé à la rigueur d'un appel d'offres a déjà la grille mentale pour cadrer un projet de ce type. Il lui manque juste les briques de base et la connaissance des pièges. C'est précisément ce que je traite dans mes interventions sur la digitalisation de la fonction achat indirecte.

Pour les achats : le sujet, c'est le cadre.

Alex Lio accompagne les directions achats d'ETI françaises et de filiales germano-suisses sur la transformation de la fonction achat indirecte. Plus d'informations sur theprocurementor.com.