J'ai « vibe codé » notre site, et ce qui ne se voit pas m'a pris le plus de temps

Une vingtaine de jours, et l'abonnement pour seul budget

Notre site selea.pro est en ligne depuis le 31 août 2026, et je l'ai construit moi-même en développement assisté par IA. Le budget se résume à l'abonnement Claude que je payais déjà pour le reste de mon activité, avec un passage à la formule Max au mois d'août pour ne plus buter sur les limites de session ; aucune dépense n'a donc été engagée pour le site lui-même.

La durée, elle, ne se raconte pas en mois : j'ai commencé au printemps, avec de longues pauses puisque je travaillais en parallèle sur notre étude In Vino Digitas, et écrire que le site m'a demandé 5 mois ne dirait rien de ce qu'il a réellement coûté. En jours travaillés, je l'évalue à une vingtaine de jours-homme, estimation et non relevé, et ce compte couvre les deux phases du chantier : j'ai commencé sur une plateforme de génération assistée, pour voir ce qu'elle donnait, puis j'ai rapatrié le dépôt pour gagner en autonomie et en réactivité.

Le prérequis que l'outil ne donne pas

Rapatrier un dépôt suppose de savoir le pousser, et c'est le premier point que le développement assisté ne remplace pas. Un outil génératif produit des fichiers ; il ne pousse pas un dépôt Git qui n'est pas paramétré, il ne règle pas une zone DNS chez OVH, il ne rattache pas un nom de domaine à un hébergeur, et il ne va pas configurer de lui-même le compte Brevo qui reçoit les demandes du formulaire de contact. Sans ces bases, on sort une plaquette HTML avec une courte espérance de vie.

Le décor technique, lui, tient en quelques lignes : le site tourne sur React 19 et React Router 7 en mode framework, compilé par Vite, habillé par Tailwind, et chaque page est prérendue en HTML sur le disque. Il se passe de CMS, la plupart étant trop lourds pour mes besoins, et les contenus vivent dans le dépôt : les textes dans un fichier JSON, le référencement de chaque page dans un second, les publications dans des fichiers markdown déposés dans un dossier. L'hébergement est statique chez Netlify, avec un déploiement à chaque commit et une seule fonction serverless, celle du formulaire. Le build casse volontairement sur une donnée mal formée, parce qu'il est le dernier contrôle avant la mise en ligne et qu'un contrôle qui n'arrête rien ne sert à rien.

Les arbitrages qui ne se voient pas à l'écran

Le reste tient dans des subtilités techniques qu'on ne trouve qu'en soulevant le capot, et elles ont occupé la plus grande part de ces jours.

J'ai retravaillé toute la palette de notre charte graphique pour que chaque couleur de texte tienne les ratios de contraste du niveau AA. Notre cuivre a été ramené à #B23B00, la valeur la plus claire qui reste conforme sur les quatre fonds clairs du site, et il prend une seconde valeur sur fond sombre. Trois essais de pastilles translucides ont été menés puis abandonnés après mesure : à 20 % d'opacité, la première tombait à 1,7:1 quand le seuil est à 4,5:1.

Les polices sont auto-hébergées et découpées par plage de caractères, 18 fichiers pour 268 Ko au total, de sorte qu'une page en français ne télécharge que ce qu'elle affiche. La famille principale est déclarée une seule fois, en police variable : la redéclarer graisse par graisse ferait télécharger le même fichier autant de fois qu'il y a de graisses. J'ai fait poser un lien d'évitement, qui permet à quelqu'un qui navigue au clavier de sauter le menu et d'atteindre directement le contenu de la page. Le site est mesuré avec Umami, sans cookie, et il n'a donc pas de bandeau de consentement à afficher.

Rien de tout cela n'aurait empêché le site de fonctionner, et un client qui reçoit un site le vérifie rarement.

Une journée d'itérations, et ce que les relevés disent

L'optimisation a demandé une journée pleine d'allers-retours sur la performance, le référencement et l'accessibilité. J'obtiens 100 en accessibilité, en bonnes pratiques et en référencement, et ces trois scores n'ont pas bougé d'un point sur l'ensemble de mes relevés. La performance donne 99 sur ordinateur et 88 sur mobile, médianes de 5 passages conduits le 5 septembre 2026, le test mobile simulant un terminal d'entrée de gamme sur un réseau bridé en 4G.

Le score composite est pourtant le chiffre le moins solide du lot. Le 4 septembre, PageSpeed Insights a donné 89 à 14h21, 71 à 14h46 et 98 à 14h50 sur un site inchangé à l'octet, soit 27 points d'écart en une demi-heure. Les métriques qui composent ce score, elles, se tiennent : le temps de blocage du navigateur est resté à 0 ms sur les 9 mesures mobile dont je dispose, rapports PageSpeed compris, quand le seuil recommandé est de 200 ms.

Mon point faible est ailleurs, et je le donne tel quel : l'affichage du contenu principal sur mobile s'établit à 3,3 s de médiane, quand Google recommande de rester sous 2,5 s. J'ai par ailleurs mesuré puis abandonné plusieurs pistes qui ne gagnaient rien, et changé de modèle en cours de route, Opus butant sur des correctifs que Fable a repris et menés au bout. Les derniers points de score mobile s'obtiendraient en retardant le chargement du JavaScript, donc en dégradant l'interactivité pour de vrais visiteurs : j'ai préféré le visiteur au chiffre.

Pourquoi je ne le ferais pas pour un client

J'ai pu mener ce chantier grâce à plus de 20 ans de projets numériques, et c'est exactement ce que l'IA ne fournit pas : Claude Code, Lovable ou un autre exécutent très bien ce qu'on pense à leur demander, sans signaler ce qu'on ignore.

Je dis d'ailleurs à mes clients que je ne ferai pas leur site en vibe coding. Mon intervention s'arrête au cadrage fonctionnel, à la conception détaillée et à la coordination avec de vrais développeurs, pour trois raisons que je leur donne telles quelles.

• Un développeur qui lit réellement le code le répare sans dépendre de l'outil qui l'a produit. Un code écrit avec assistance et compris par personne n'a pas d'autre réparateur que cet outil, et cette dépendance ne se voit pas tant que rien ne casse.
• Le maintien en conditions opérationnelles suppose une astreinte, une procédure de retour en arrière et un suivi des vulnérabilités des dépendances, que je n'assure pas.
• L'hébergement de production suppose de la même façon un choix de plateforme, une supervision à mettre en place et à surveiller, et une protection à maintenir dans la durée.

Ces trois raisons valent tout autant pour notre propre site, à ceci près qu'ici le client, c'est moi. J'y trouve encore des choses à corriger ou à ajouter, et je serais curieux de savoir ce que vous proposeriez d'améliorer.