Pourquoi un MVP vibe-codé a aussi besoin d'un plan B

Le vibe coding a simplifié beaucoup de choses, et c'est une bonne nouvelle. On prototype plus vite, on rend l'outil accessible à des gens qui n'auraient jamais ouvert un terminal il y a cinq ans, on transforme une idée en interface fonctionnelle en une soirée. Rien à redire là-dessus.

Le vibe coding, aujourd'hui, c'est concrètement ça : la possibilité de sortir un MVP qui fonctionne sans dix ans d'expérience en développement, en décrivant l'idée plutôt qu'en écrivant chaque ligne.

Cette accessibilité est réelle, et je ne vais pas la critiquer, moi qui forme justement des gens à ces outils. Mais elle a un revers qu'on préfère ne pas nommer tout de suite : elle donne l'impression que la compétence technique devient optionnelle.

Elle ne le devient pas. Elle se déplace, elle se cache derrière l'interface, et elle refait surface le jour où le projet doit tenir la charge, se sécuriser, ou simplement rester payant à l'usage. Prendre du recul, ça veut dire accepter de se former sur ces sujets-là aussi, pas seulement sur le prompt qui a lancé le projet.

Mais il y a un endroit précis où le vibe s'arrête net et où la technique reprend ses droits sans prévenir : le moment où ce projet né d'un prompt bien tourné doit encaisser un vrai trafic.

Simplifier, ok. Rendre accessible, ok aussi.
Mais le scaling ne se laisse pas vibe-coder.

Il demande du recul, une lecture de chiffres que personne ne montre dans les démos, et une expertise qui ne s'improvise pas au moment où la facture tombe.

readme.club, la communauté que j'anime autour des liseuses Xteink, m'a servi de rappel concret cet été. Comme beaucoup de mes projets ces dernières années, il est né vite, avec les outils qui font gagner du temps, une idée validée par l'usage avant même de se poser la question de la charge.

C'est exactement le terrain décrit plus haut : accessible à construire, mais livré sans le manuel de scaling.

En juillet, j'ouvrais l'onglet Billing de Supabase plus souvent que d'habitude. Pas par curiosité. Par réflexe d'alerte. Un marché de niche, pourtant : des passionnés de liseuses e-ink, des guides de firmware, des wallpapers optimisés pour écran e-ink. Rien qui devrait faire trembler une infra Vercel + Supabase.

Sauf que la courbe ne mentait pas. Sur les trois derniers mois, Vercel Analytics affiche 165 841 visiteurs uniques (+58 %) et 793 582 pages vues (+34 %). Une tendance de fond, pas un pic isolé. Et une tendance de fond, sur une infra facturée à l'usage, ça finit toujours par se voir sur la facture.

Un site de niche n'est pas un petit site. C'est un site dont personne ne surveille la facture avant qu'elle explose, ni la technique avant qu'elle manque.

Ce que les chiffres racontaient déjà

Avant de toucher à quoi que ce soit, j'ai regardé d'où venait vraiment le trafic. Deux choses sautent aux yeux. D'abord, la page /wallpapers écrase tout le reste avec 17 000 visiteurs sur la période, loin devant la page d'accueil (3 900) ou /firmware (2 100).

Ce sont des fichiers lourds, téléchargés en masse, pas du texte. Une image pensée pour écran e-ink n'a rien d'un JPEG optimisé pour le web : les liseuses affichent en niveaux de gris avec un rendu par dithering, ce qui pousse à distribuer des fichiers en haute résolution, souvent en PNG non compressé, pour que le rendu reste net une fois passé par l'écran.

Un wallpaper pensé pour une Xteink pèse facilement plusieurs mégaoctets là où un visuel web classique en pèse quelques dizaines de kilooctets. Multiplié par des milliers de téléchargements, la bande passante grimpe vite, même sur un marché de niche.

Ensuite, les référents : Reddit apporte à lui seul plus de 2 000 visiteurs, avec un relais notable depuis 4pda.to, un forum russe spécialisé dans le hardware de niche. Un post qui prend sur Reddit, sur un sujet de niche, ça ressemble à rien sur le papier. Sur la bande passante, ça ressemble à un pic de CDN.

C'est là que le bât blesse. Un site de niche ne génère pas un trafic modeste et régulier. Il génère un trafic faible la plupart du temps, et des pics disproportionnés le jour où la bonne communauté le repère. Le prévisionnel devient vite excitant sur le papier et un peu inquiétant en pratique, parce que l'infra qui encaissait un trafic tranquille n'a jamais été pensée pour encaisser un pic.

La décision Cloudflare

Le déclic de juillet, ce n'était pas une panne. C'était une facture Supabase qui grimpait pendant que je regardais la courbe de trafic continuer de monter. Deux signaux qui pointent dans la même direction, ça vaut le coup de les prendre au sérieux avant que ça devienne un vrai problème.

J'ai mis Cloudflare devant Vercel et Supabase. Pas juste le proxy DNS par défaut (le petit nuage orange qu'on active en cinq minutes et qu'on oublie), mais une configuration complète : cache, WAF, bot management, rate limiting, Workers. Et c'est précisément là qu'il faut être honnête sur ce que fait vraiment cet outil.

Cloudflare ne rend pas un site rapide. Il évite que ton serveur d'origine ait à répondre à des questions qu'il a déjà résolues une minute avant.

Le cache absorbe les requêtes répétées sur du contenu statique. Le WAF filtre les requêtes malveillantes avant qu'elles n'atteignent l'application. Le bot management distingue un visiteur d'un scraper. Le rate limiting empêche une seule source de saturer une route.

Chacun de ces mécanismes a ses propres règles à configurer, ses faux positifs à corriger, ses seuils à ajuster selon le trafic réel du site. Rien de tout ça ne fonctionne correctement en mode « activer et oublier ».

Ce que ça change, chiffres à l'appui

Sur les 30 derniers jours, Cloudflare a traité 21,76 millions de requêtes pour readme.club. Sur ce total, 7,67 millions ont été servies directement depuis le cache, sans jamais réveiller Vercel ou Supabase. Côté bande passante, c'est encore plus parlant : sur 1,02 To de trafic total, 681 Go sont sortis du cache Cloudflare. Deux tiers du volume qui n'ont jamais eu besoin de traverser l'infra d'origine.

L'autre chiffre, plus inconfortable, vient des statistiques de sécurité sur 24 heures. Sur l'ensemble des requêtes GET (711 160), la catégorie « Unknown/Others » domine à la fois le classement des navigateurs (346 350) et celui des systèmes d'exploitation (352 570). Autrement dit, une bonne partie du trafic ne se présente pas comme un navigateur identifiable.

Trois adresses IP isolées cumulent chacune plus de 6 000 requêtes sur la même journée, un rythme qu'aucun visiteur humain, même le plus passionné de liseuses e-ink, ne tient. Ça commence à ressembler à une enquête technique à mener.

Sur un marché de niche, on imagine des passionnés qui cliquent. On oublie les robots qui aspirent.

C'est exactement le genre de trafic qu'un cache seul ne filtre pas, parce qu'un cache sert du contenu à qui le demande, humain ou script. C'est le rôle du WAF et du bot management de trier avant que la requête ne compte.

Le chantier pas fini

Voici la partie que je pourrais facilement passer sous silence pour que l'article se termine sur une victoire nette. Je ne vais pas le faire, parce que ce serait mentir sur ce que ces outils permettent réellement.

Sur le cycle de facturation Supabase en cours (6 août au 6 septembre), l'egress en cache dépasse déjà le quota inclus de 250 Go, avec un dépassement de 209,96 Go. Heureusement que tout se remet à zéro le 6 du mois. D'ailleurs, on voit bien la différence avant /après mise en place de Cloudflare sur début août.

Le montant facturé reste modeste (6,30 $ sur ce poste), mais le volume, lui, ne l'est pas. Et je n'ai pas encore vérifié un point technique précis : est-ce que les wallpapers et les firmwares, les fichiers les plus lourds et les plus téléchargés du site, passent par une URL Supabase Storage directe, non couverte par le cache Cloudflare, ou sont-ils bien proxyés ? Je ne le sais pas encore avec certitude, et c'est justement le genre de question qu'on ne se pose qu'après avoir regardé les vrais chiffres, pas avant.

Mettre un CDN devant son application ne protège que ce qui passe par l'application. Les fichiers servis en direct depuis le stockage restent à découvert.

En attendant d'avoir vérifié ce point, j'ai changé une habitude simple : je regarde le dashboard Cloudflare et celui de Supabase le même jour, une fois par semaine, plutôt que d'attendre l'alerte de dépassement pour ouvrir l'un des deux. Ça ne remplace pas la vérification technique qu'il me reste à faire, mais ça évite de redécouvrir le problème en juillet prochain.

Comment le reproduire

Si ton propre projet de niche commence à te faire regarder l'onglet Billing plus souvent que prévu, voici l'ordre dans lequel j'ai procédé.

1. Active le proxy Cloudflare sur ton domaine. C'est l'étape la plus simple et la moins suffisante à elle seule. Elle place Cloudflare entre les visiteurs et ton origine, mais ne configure rien d'utile par défaut.
2. Identifie tes routes les plus lourdes en bande passante, pas les plus visitées. Une page HTML légère avec 10 000 vues pèse moins qu'une image ou un firmware téléchargé 500 fois. Regarde le poids réel, pas le trafic brut.
3. Écris des règles de cache spécifiques pour ces routes lourdes, avec une durée de vie adaptée à la fréquence de mise à jour du contenu. Le cache par défaut de Cloudflare ne couvre pas tout, en particulier les fichiers servis depuis un stockage tiers (Supabase Storage, S3 et équivalents) si l'URL ne passe pas par ton domaine proxyé.
4. Active le WAF et regarde les logs avant de bloquer quoi que ce soit. Les règles managées génèrent des faux positifs sur certains projets. Une semaine d'observation évite de bloquer des visiteurs légitimes.
5. Mets en place du rate limiting sur les routes API et les endpoints de recherche, celles qu'un script peut interroger en boucle sans qu'un humain ne le remarque immédiatement.
6. Croise les statistiques de deux côtés : celles de Cloudflare (ce qui arrive à la porte) et celles de ton hébergeur d'origine (ce qui la traverse encore). Un écart entre les deux signale exactement ce qu'il reste à corriger.

Aucune de ces étapes ne se fait une fois pour toutes. Le trafic d'un site de niche change de forme dès qu'une communauté le découvre, et la configuration qui tenait la semaine dernière peut se retrouver dépassée la semaine suivante.

Combien de projets nés d'un prompt tournent aujourd'hui sans cette couche de technique, simplement parce que personne ne leur a dit qu'elle restait à construire ?

Et on ne parle même pas encore de sécurité là ... 😄