Je ne savais pas ce que je faisais. Voici ce que ça a donné.
Ça a commencé avec une maquette dans stitch un outil Google que j'ai voulu tester.
Ça a fini avec une faille de sécurité que j'avais mise en prod sans le savoir, trois versions, et un outil que j'ai intégralement jeté pour recommencer à zéro.
Voici la vraie histoire du Megaprompt Generator.
L'idée, et Google Stitch
J'utilisais des LLMs tous les jours.
Et tous les jours, je me retrouvais à bricoler mes prompts dans un coin de fichier texte — sans structure, sans méthode, avec des résultats aléatoires.
L'idée : un outil qui assemble le prompt à ma place, à partir de paramètres simples.
Pour le design, j'ai cherché une maquette de départ. J'ai trouvé Google Stitch, un outil Google qui génère des interfaces à partir d'une description. J'ai décrit mon projet, il m'a généré tout un design hyper propre pour différents templates de pages en quelques secondes, assez bluffant.
Je l'ai montrée à Claude.
"Construis ça."
Il a construit ça.
Un formulaire en 4 étapes, une sidebar de navigation, un terminal de résultat en fond sombre. Fonctionnel. En une session.
J'aurais dû tester avant de passer à la suite.
Je ne l'ai pas fait.
La V2 avant d'avoir testé la V1
L'outil était là. Build OK. Je n'avais pas encore cliqué sur un seul bouton.
Et j'ai décidé de tout refaire en mieux.
C'est une habitude que j'ai : commencer par planifier avant d'exécuter. Parfois c'est utile. Parfois c'est de la procrastination déguisée en rigueur.
Là, c'était les deux.
La session entière a été de la réflexion pure. Zéro ligne de code écrite.
Ce qu'on a décidé :
- Passer de 10 personas courts à 20 personas détaillés, avec contexte complet
- Sortir toutes les données du code vers des fichiers JSON séparés (personas, tons, formats, boosters, templates, audiences)
- Permettre de combiner deux personas — un Marketing + un Juridique, par exemple
- Générer une URL partageable qui encode toute la configuration
L'idée de combiner deux personnalités IA dans un même prompt, j'en suis encore content.
L'audit
Quelques sessions plus tard, v2 en place, j'ai demandé à Claude (en mode Opus, plus lent et plus critique) de regarder l'outil avec un œil hostile.
Pas "dis-moi ce qui va bien".
"Dis-moi ce qui va mal. Franchement."
Il m'a sorti 29 problèmes.
Dont 6 qualifiés d'"honteux".
Le premier : une faille de sécurité XSS.
Le XSS que j'avais mergé sans le savoir
XSS — Cross-Site Scripting — c'est quand du code HTML ou JavaScript se glisse là où il ne devrait pas, parce qu'on a utilisé innerHTML sur des données qu'on n'a pas filtrées.
Dans mon cas : les inputs de l'utilisateur (sa demande, son persona libre) étaient injectés directement dans le rendu HTML du prompt. Sans vérification. Sans échappement.
Si quelqu'un avait entré <script>alert('pwned')</script> dans le champ demande, ça aurait été exécuté.
La faille existait depuis le premier commit. Personne ne l'avait signalée.
L'audit l'a trouvée.
Même chose avec unescape() — une fonction JavaScript dépréciée depuis des années, que Claude avait quand même écrite dans le code d'encodage d'URL. Et que j'avais mergée sans regarder.
C'est ça, travailler avec l'IA sans expertise technique : le code fonctionne, mais il peut embarquer des problèmes que tu ne détectes pas parce que tu ne sais pas quoi chercher.
La bonne nouvelle : 26 des 29 problèmes ont été corrigés en une seule session.
Le replace_all qui se mord la queue
Pendant les corrections, j'ai voulu centraliser les couleurs de l'interface.
144 valeurs hexadécimales dispersées dans le CSS. L'idée : les remplacer toutes par 12 variables CSS (--mp-navy, --mp-orange, etc.) en une opération.
Ça a marché. Et ça a immédiatement cassé.
Le replace_all avait aussi remplacé les valeurs dans les définitions des variables elles-mêmes.
Résultat : --mp-navy: var(--mp-navy).
Une variable qui se référence elle-même. Boucle infinie. Propriété invalide. Tout gris.
Corrigé manuellement en 10 minutes. Mais la leçon reste : une opération de remplacement massif ne sait pas faire la différence entre une utilisation et une définition.
L'audit UI/UX — 6,5 sur 10
Les corrections de sécurité faites, j'ai lancé un autre audit. Celui-là sur l'interface — pas le code.
J'ai demandé à Opus de jouer le directeur artistique d'un jury Awwwards.
Il m'a mis 6,5 sur 10.
Ce qu'il a relevé :
Le texte était en 9px partout. Pas illisible sur grand écran. Illisible sur mobile. Le genre de chose que tu ne vois plus quand tu as le nez dans le code depuis des semaines.
52 options à scanner avant de commencer. 20 personas. 16 tons. 16 formats. Posés là, sans catégorie, sans hiérarchie. Le paradoxe du choix — trop d'options = abandon.
4 patterns de sélection différents pour la même action.
- Personas : bordure gauche colorée
- Ton : fond navy
- LLM cible : bordure inférieure
- Format : fond navy aussi, mais différent
Quatre façons de dire "sélectionné". Sur un seul outil.
"Le genre de trucs que tu ne vois plus quand tu as le nez dedans."
C'est exactement ça.
Tout corriger. Puis tout jeter.
17 problèmes identifiés. Plan en 5 phases. Build propre.
J'ai testé l'outil à la main.
Et j'ai été insatisfait.
Pas à cause d'un bug. Pas à cause d'une couleur. À cause du concept même.
Le formulaire en 4 étapes cachait le résultat jusqu'à la fin. C'est comme écrire un email sans voir ce qu'on tape — tu construis quelque chose dans le vide, tu appuies sur "Générer", et seulement là tu vois ce que tu as produit.
Ce n'est pas comme ça qu'on travaille.
La décision : tout jeter. Recommencer.
Nouveau concept : un studio. Panneau de contrôle à gauche. Aperçu live à droite. Le prompt se construit en temps réel à chaque interaction. Pas de bouton "Générer". Pas de wizard.
La V3
L'implémentation complète — les 713 lignes Astro et les 896 lignes JavaScript — a été réécrite en deux sessions.
Les 20 personas en grille ont été remplacés par un dropdown cherchable, avec recherche fulltext et 5 catégories. On trouve son persona en 3 secondes au lieu de 30.
Les templates sont devenus le point d'entrée principal — 7 points de départ pour avoir un premier prompt en 15 secondes.
Le bouton flottant mobile (FAB) pour basculer entre composition et aperçu a créé un bug inattendu : style.display = 'flex' via JavaScript écrasait la classe Tailwind lg:hidden. Le bouton était visible en desktop. Fix : toggle de classe CSS avec !important dans un media query, au lieu du style inline. 20 minutes pour trouver, 30 secondes pour corriger.
Le déploiement, et les 4 retours UX dans les 2h qui suivent
V3 déployée. Build OK. Playwright OK.
Deux heures après : 4 retours d'usage réels.
Le bouton Réinitialiser était invisible — même couleur que le fond. La FAQ était illisible — texte navy sur fond noir, parce que la section était en dehors du div principal (fond blanc) et héritait du body dark du site. Les champs ton et format n'avaient pas d'option "libre". L'aperçu n'était pas cliquable directement.
Tout ça n'est pas apparu dans les tests automatisés.
C'est apparu en testant l'outil pour de vrai.
C'est ça la vraie différence entre "testé" et "utilisé".
En quelques minutes, tout était corrigé.
Ce que j'en retiens
Je ne suis pas développeur. Je ne le serai jamais.
Mais j'ai appris quelque chose sur ce que ça veut dire de construire avec l'IA : l'IA construit vite, souvent bien, et parfois avec des erreurs que seul quelqu'un qui sait regarder le code peut détecter.
L'audit n'est pas optionnel.
Le test manuel ne remplace pas Playwright. Playwright ne remplace pas le test manuel.
Et parfois, corriger 17 problèmes n'est pas la bonne réponse — parce que le vrai problème, c'est le concept.
L'outil est là. Vous pouvez l'essayer.
Je ne sais toujours pas exactement ce que je fais. Mais je regarde ce qui se passe. Et je partage.