Démonstration Cyberviseur · persona fictive · aucune mission réelleEn savoir plus
Evan ElliotSécurité · Full-stack · OSS
Menu

Lab · Témoignage · 15 janvier 2026 · 16 min de lecture

J’ai fait une formation vibe-coding + self-hosting. Effarant de me découvrir aussi vulnérable.

Ce texte est le témoignage d'une cliente, Léa, fondatrice d'une plateforme d'accompagnement parental. Publié avec son autorisation, légèrement édité pour la lisibilité. Les noms, sauf le sien, sont changés.

Je m'appelle Léa, j'ai 34 ans, et je ne suis pas développeuse. Ce qui suit est l'histoire de comment j'ai cru avoir construit quelque chose de sérieux — et de comment Evan, en trois jours d'audit, m'a démontré le contraire. Sans humiliation. Avec une espèce de patience presque agaçante. Mais en me laissant zéro illusion.

D’où je viens

J'ai un master de psycho clinique, j'ai bossé six ans en cabinet, puis j'ai eu un enfant. Pendant le congé mat', j'ai commencé à animer un compte Instagram sur la parentalité bienveillante. Trois ans plus tard, 80 000 followers, des sollicitations en pagaille, et l'idée d'une plateforme — un mix consultations / podcasts privés / communauté de parents membre.

Je n'ai pas voulu prendre un dev. Trois raisons :

  • Mon budget de lancement était de 4 500 €, je n'avais pas de quoi salarier ou prestater 30 jours
  • J'avais entendu plein d'histoires de fondatrices non-techniques arnaquées par leur dev
  • J'avais croisé sur Insta des contenus sur le « no-code + IA » qui semblaient justement faits pour des gens comme moi

Donc j'ai pris une formation. Un truc en ligne, 1 200 €, étiqueté « Construire ton SaaS rentable avec Cursor et n8n en 30 jours ». Bien fait, profs sympas, communauté Discord active. Je recommande encore aujourd'hui — pour ce qu'elle est. Le problème, c'est que je ne savais pas ce qu'elle n'était pas.

Ce que la formation enseignait (et ce qu’elle n’enseignait pas)

Elle enseignait : prompter Cursor correctement, structurer une app Next.js, brancher Supabase, gérer l'auth magic link, déployer sur Vercel, automatiser via n8n, accepter des paiements Stripe, self-héberger n8n et Plausible sur un VPS Hetzner. Tout ça. Très concret, très efficient.

Elle n'enseignait pas: ce qu'est un IDOR, ce qu'est une politique RLS, comment configurer une CSP, pourquoi les uploads doivent être sandboxés, comment durcir un VPS, ce qu'est une attaque par injection SQL, ce qu'est un secret manager, ce qu'est une attaque CSRF, à quoi servent SPF/DKIM/DMARC, comment gérer une fuite de données, qui est la CNIL, qu'est-ce qu'un DPO, ce qu'est un backup 3-2-1.

Je ne reproche pas à la formation de ne pas avoir enseigné tout ça — un cursus universitaire en sécurité, c'est trois ans, ce n'est pas raisonnable de le caser dans 30 jours. Je reproche autre chose : la formation ne disait pas que ça existait. Elle laissait entendre qu'avec ses 30 jours, on était équipée.

Je n'étais pas équipée. J'étais opérationnelle. Ce n'est pas pareil.

Lancement — euphorie

Mars 2025. La plateforme sort. 600 inscrits la première semaine, 80 abonnements payants à 19 €/mois. Je m'auto-pince. J'envoie des captures d'écran à ma mère.

Tout marche. Le paiement Stripe fonctionne. Les emails de confirmation arrivent. Les enregistrements de séance se stockent dans S3. n8n route les automatisations. Plausible self-hosted affiche mes stats sur le tableau de bord que j'ai construit moi-même.

Je me sentais extraordinairement compétente. Je publiais des posts LinkedIn qui faisaient 4 000 likes, avec l'ambiance « non-techniques, vous pouvez le faire, le monde du dev est moins effrayant qu'il en a l'air ». C'est vrai, d'ailleurs — il est moins effrayant. Mais il y a un détail.

Juin 2025 — le doute

Un de mes utilisateurs, un papa développeur (parce qu'évidemment), m'envoie un email :

« Bonjour Léa, j'ai remarqué un truc bizarre. Quand je change le numéro dans l'URL de mes séances, je tombe sur les séances d'autres utilisateurs. Je voulais vous prévenir avant que quelqu'un en abuse. Bonne continuation. »

Mon cœur s'arrête. Je vérifie. Il a raison. L'URL/seance/142 donne accès à n'importe quelle séance — y compris les enregistrements audio, qui contiennent de la parole intime de parents en détresse sur des sujets ultra-sensibles (deuil périnatal, violence conjugale, dépression post-partum). 600 utilisateurs. Une fuite éthique majeure.

Je désactive la plateforme dans la demi-heure. Je publie un message sobre disant qu'une « maintenance prolongée est en cours ». Je passe la soirée à pleurer. Le lendemain matin, je cherche un consultant.

L’audit — humiliation contrôlée

Evan répond le jour même. Appel diagnostic 45 min, gratuit (déjà ça, je n'y croyais pas). Il me pose des questions précises, sans me faire sentir bête. Devis le lendemain : 4 500 € HT pour trois jours d'audit complet. Je signe.

Trois jours plus tard, restitution. Le rapport fait 48 pages. Je le lis en grimaçant. Voici les huit critiquesqu'il a trouvées (il y en avait aussi 14 hautes, 23 moyennes, mais je vais pas tout mettre) :

1. L’IDOR évident (celui qu’on m’avait signalé)

Endpoint /api/seance/[id]sans vérification que la séance appartenait à l'utilisateur loggué. Supabase RLS pas activée sur la table. Fix : 6 lignes de SQL + 4 dans le code.

2. Les enregistrements S3 en lecture publique

Mon bucket S3 était configuré public-readparce que la formation montrait ça pour « simplifier les URLs d'avatar ». Sauf que j'y avais aussi mis les enregistrements de séances. Avec une URL prédictible par numéro.Donc même sans IDOR, n'importe qui connaissant le format pouvait télécharger.

3. La clé API Stripe en clair dans le repo

Au début, j'avais collé ma clé Stripe directement dans le code parce que je ne comprenais pas les variables d'environnement. J'avais corrigé deux semaines plus tard, mais — comme me l'a expliqué Evan — l'historique Git garde tout. Pendant deux semaines, ma clé Stripe live était publique. Heureusement, mon repo était privé. Si je l'avais mis public « pour la transparence avec ma communauté » comme j'avais failli le faire, la note aurait été salée.

4. Le n8n self-hosted sans authentification

J'avais self-hébergé n8n sur un VPS Hetzner, comme la formation l'enseignait. Sauf que j'avais sauté l'étape « activer l'auth basique + reverse proxy avec TLS » parce que ça « ne marchait pas du premier coup et j'y reviendrais plus tard ». Mon n8n était accessible publiquement, sans mot de passe, avec mes credentials Stripe, Supabase, et Mailgun configurés dans les workflows. N'importe qui pouvait les afficher.

5. CSP absente, headers absents

Aucun Content-Security-Policy. Aucun X-Frame-Options. Strict-Transport-Security absent. Mon site pouvait être chargé en iframe sur un domaine attaquant, qui pouvait alors déclencher des actions au nom de l'utilisateur (clickjacking).

6. Mots de passe stockés en clair dans une table « legacy »

J'avais commencé avec un système d'auth maison « simple » avant de migrer sur Supabase. J'avais oublié de supprimer l'ancienne table — qui contenait 47 mots de passe utilisateur en texte clair. Pour tester si certains étaient réutilisés ailleurs, Evan a fait une recherche dans haveibeenpwned : 31 sur 47 étaient déjà dans des dumps publics. Mes utilisateurs réutilisaient ces mots de passe sur leur Gmail, leurs banques.

7. RGPD : zéro

Pas de registre des traitements. Pas de mentions correctes. Cookies analytiques (Plausible quand même, donc anonymisés, ouf) déposés avant consentement. Pas de procédure de suppression de compte (légalement obligatoire). Pas de DPO désigné. Si la CNIL avait audité, je prenais une amende et une obligation publique de communication sur la non-conformité.

8. Pas de sauvegarde testée

Je « savais » que Supabase faisait des sauvegardes. Je n'avais jamais testé une restauration. Evan m'a fait simuler la restauration en environnement de staging. Échec : un schéma de migration récent n'était pas dans la sauvegarde disponible (rétention 7 j sur le plan que j'avais). Si ma base avait été corrompue ce jour-là, j'aurais perdu 6 jours de données.

Le coût total du « j’apprends sur le tas »

Ce que j'avais « économisé » en ne prenant pas un dev au lancement (en gros, ~15 k€ HT pour 30 jours d'intervention sérieuse) :

  • 4 500 €d'audit Evan
  • 9 000 € de sprint de remédiation (3 semaines)
  • 2 mois de plateforme fermée = ~3 000 € de MRR perdu + 80 désabonnements (~1 500 €/mois perdus en récurrent)
  • 1 200 € à mon avocat pour la notification CNIL et le courrier aux utilisateurs
  • ~25 nuits de sommeil pourries, qui ne se chiffrent pas

Total chiffrable : ~21 k€ + plusieurs mois de réputation. J'avais économisé 15 k€ au lancement. Bilan net : -6 k€. Et ça, c'est dans le scénario où l'utilisateur sympa m'a prévenue avant qu'un malveillant n'exfiltre les 600 séances. Le scénario optimiste.

Ce que je dirais à la Léa de mars 2025

Je ne lui dirais pas « prends un dev senior dès le départ ». Ce n'était pas dans son budget, ce ne l'est dans le budget d'à peu près personne quand on lance. Je lui dirais ceci, dans cet ordre :

  1. Fais ta formation et lance ton MVP.Le monde du dev est moins effrayant qu'il en a l'air. Tu vas y arriver.
  2. Mais avant le premier euro encaissé en prod, paie un audit court (1 500 - 3 000 €)à un consultant indépendant qui te dira tes 3-5 trous critiques. C'est le ratio coût/protection le plus rentable que tu ne feras jamais.
  3. Bloque 10 % de ton CA mensuel pour la sécu/maintenance dès le démarrage.Ce sera l'équivalent d'une demi-journée par mois avec quelqu'un de sérieux. C'est ce qui sépare un projet qui grandit d'un projet qui s'effondre au premier mauvais coup.
  4. Apprends qui est la CNIL. C'est gratuit, ils ont des fiches pratiques excellentes, et tu n'as pas le choix de toute façon — tu es responsable de traitement dès que tu collectes un email.
  5. Quand tu hésites entre « plus de fonctionnalités » et « plus de robustesse », choisis robustesse. Toujours. Tes utilisateurs ne te quitteront pas parce qu'il manque une fonctionnalité ; ils te quitteront dans la seconde si tu fuites leurs données.

Aujourd’hui

La plateforme tourne. 920 abonnés actifs, ~17 500 €/mois de MRR. Je travaille avec Evan une demi-journée par mois en mandat fractional — il relit mes PR critiques, fait les mises à jour de sécurité, gère les renouvellements de certificats. ~600 €/mois. Le coût d'un abonnement Notion équipe que je n'utilise même pas.

Je continue à recommander la formation. Je n'ai aucun intérêt à la descendre — ce qu'elle enseigne est précieux. Mais je préviens systématiquement : « avant de mettre des vrais humains dessus, fais auditer ».

Si vous lisez ça en vous disant « ah, mais moi je sais ce que je fais »... je vous suggère, sans humiliation et avec une patience presque agaçante, de quand même prendre l'appel diagnostic gratuit. Si vous avez raison, on perdra 45 min ensemble et vous repartirez rassurée. Si vous avez tort, vous le saurez avant qu'il soit trop tard.

— Léa

Note d’Evan

Ce témoignage est composite, fictif sur la forme (Léa n'existe pas littéralement), mais représentatif de ce que je vois vraiment. Sur la centaine de fondatrices et fondateurs non-techniques que j'ai audités après une formation vibe-coding ou no-code, je n'ai jamais trouvé moins de 4 vulnérabilités critiques. Le record est à 17.

Ce n'est pas la faute des formations. Ce n'est pas la faute des fondatrices. C'est l'écart structurel entre « savoir construire » et « savoir protéger », et cet écart, personne ne le comble par défaut. Il faut quelqu'un dont c'est le métier.

Si vous reconnaissez votre cas dans celui de Léa, faites le pas qu'elle a fait : prenez l'appel. Vous ne perdez rien à savoir où vous en êtes.