J'ai Arrêté le Coding à l'Instinct et Créé une Vraie App. La Méthode que Personne n'Enseigne.

Vous avez demandé à une IA de vous créer une app. Elle a l'air bien et elle fonctionne. Presque. Dès que vous touchez à une fonctionnalité, une autre se casse.

À chaque fois qu'un vrai utilisateur l'essaie, il y a un bug. (Non non, ne cliquez pas sur ça.) La connexion ne protège rien du tout. Les clients d'un utilisateur s'affichent dans le tableau de bord d'un autre. La page de paiement récupère la carte bancaire mais n'enregistre jamais la transaction.

Votre processus est cassé. Le code n'est que le symptôme.

J'ai construit une maison en paille de mes propres mains. Cinq ans. Le parallèle avec le logiciel (je suis dans l'IT depuis 30 ans) est saisissant : même besoin de séquençage, même besoin de comprendre chaque spécialité sans devenir spécialiste. J'en ai fait une méthode pour que vous puissiez développer votre app comme un pro.

TLDR : Arrêtez de dire à l'IA "construis-moi X." Commencez par spécifier ce que X signifie, ce que ça implique, comment le vérifier. Huit étapes, même boucle à chaque fois. Commencez par votre prochaine fonctionnalité.

Le fossé dont personne ne parle

Le vibe coding est cassé. Pas les outils. Pas l'IA. La façon dont les gens l'utilisent.

Tous les tutoriels montrent la même chose : tapez un prompt, obtenez une app, célébrez. Et ça marche, pour une démo. Un écran avec des boutons qui ont l'air corrects.

Puis vous avez besoin que l'app fasse de vraies choses. Plusieurs utilisateurs qui voient chacun seulement leurs propres données. Des paiements qui se traitent vraiment. Une nouvelle fonctionnalité qui ne casse pas silencieusement trois anciennes.

L'IA optimise pour "marche maintenant." Une vraie app a besoin de "marche encore dans six mois." Ce fossé n'est pas une question de qualité de code. C'est savoir quoi demander, dans quel ordre, et comment vérifier qu'on l'a obtenu.

La méthode Blueprint

Huit étapes. Même boucle pour chaque fonctionnalité, d'une simple liste de clients à l'intégration Stripe.

1. Spec globale. Que voulez-vous, en langage simple ? "Je veux gérer des clients." Vague exprès. Juste assez pour commencer.

2. Implications. L'étape que la plupart sautent, et celle qui vous sauve. Demandez à l'IA : "Qu'est-ce que ça implique techniquement ? Quelles tables, pages, composants j'ai besoin ?" L'IA décompose votre demande en liste de choses concrètes qui doivent exister. Certaines vous les attendiez. D'autres (une colonne ID, timestamps, règles de validation) vous n'y aviez pas pensé. Maintenant vous voyez l'image complète avant de construire quoi que ce soit.

3. Spec détaillée. Soyez précis. Champs, types, validation, gestion d'erreur, que se passe-t-il quand ça foire. C'est là que "construis-moi une liste de clients" devient utilisable.

4. Construction. Donnez la spec détaillée à l'IA. Laissez-la construire.

5. Explication. Demandez à l'IA : "Explique ce que tu viens de construire et pourquoi." Vous ne lisez pas le code. Mais vous comprenez le flux. Cette compréhension s'accumule. À votre dixième fonctionnalité, vous avez un modèle mental riche de toute votre app.

6. Vérification. Vérifiez que ça marche. Pas en lisant le code. En utilisant l'app, testant les cas limites, et demandant à l'IA "qu'est-ce qui pourrait mal se passer avec ça ?"

7. Qu'est-ce qui peut foirer. Chaque fonctionnalité a ses pièges spécifiques. Auth ? L'IA stocke les mots de passe en clair. Paiements ? Elle ignore les échecs de webhook. Sécurité ? Politiques trop permissives. Nommez les pièges pour les attraper.

8. Non-régression. Vérifiez que tout ce qui venait des fonctionnalités précédentes marche encore. L'échec le plus courant du vibe coding : ajouter quelque chose de nouveau qui casse silencieusement trois trucs anciens.

La profondeur augmente au fur et à mesure. Votre première spec fait deux phrases. Quand vous arrivez aux paiements, elle fait deux pages. Même méthode. Votre compétence grandit.

Un exemple concret : l'authentification

C'est là que le vibe coding échoue le plus spectaculairement.

Avant.

"Ajoute une connexion à mon app."

L'IA construit une page avec des champs email et mot de passe, un bouton, une redirection. Ça ressemble à une connexion. L'UI va bien. Mais l'auth n'est pas une fonctionnalité d'UI. L'auth c'est de l'infrastructure. La page de connexion c'est les 10% visibles. Les autres 90% c'est la gestion de session, validation de token, protection de routes, isolation de données. L'IA zappe tout ça parce que vous n'avez pas demandé.

Vous livrez. L'utilisateur A se connecte. L'utilisateur B se connecte. L'utilisateur B voit les données de l'utilisateur A.

Après.

Même fonctionnalité, avec la méthode.

Étape 1 (spec globale) : "Chaque utilisateur a son propre compte. Il se connecte avec email et mot de passe. Une fois connecté, il voit seulement ses données."

Étape 2 (implications) : vous demandez à l'IA d'expliquer ce que ça signifie techniquement. Elle revient avec : authentification vs autorisation (deux choses différentes), sessions, tokens, protection de routes, et lier les données aux utilisateurs (chaque enregistrement a besoin d'une colonne user_id). Vous ne saviez pas que vous aviez besoin de la moitié de ça. Maintenant si. Avant d'écrire un seul prompt pour construire quoi que ce soit.

Étape 3 (spec détaillée) : inscription avec confirmation email. Connexion avec email et mot de passe. Bouton déconnexion. Session qui expire automatiquement après inactivité. Protection de route pour TOUTES les pages sauf connexion et inscription. Une colonne user_id sur chaque table de données. Filtrage automatique par utilisateur sur chaque requête.

Ça c'est un contrat. Chaque attente énoncée, chaque comportement défini.

Puis vous construisez, vérifiez, nommez les pièges (sessions qui n'expirent jamais, user_id vérifié sur INSERT mais pas sur UPDATE ou DELETE), et vérifiez la régression contre chaque fonctionnalité précédente. Vous connaissez la boucle. Mêmes huit étapes.

La différence entre "ajoute une connexion" et ça, c'est la différence entre une porte qui a l'air verrouillée et une porte qui l'est vraiment.

La séquence de construction

Construisez dans cet ordre :

• Setup et déploiement (mettez quelque chose en ligne immédiatement, même une page blanche)
• Comprendre les blocs de construction (frontend, backend, base de données, comment ils communiquent)
• Designer l'interface avant de la construire (vocabulaire + règles de cohérence)
• Votre première fonctionnalité (CRUD simple, apprenez la boucle)
• Relations de données (choses qui se connectent à d'autres choses)
• Authentification (qui êtes-vous)
• Isolation de données (chaque utilisateur voit seulement ses propres données)
• Tests (automatisez la vérification que vous faisiez à la main)
• Tableau de bord et polish (donnez l'impression d'un produit)
• Paiements (la fonctionnalité avec les bugs les plus chers)
• Mise en ligne pour de vrai (déploiement production, domaine, monitoring)

Chaque étape se base sur la précédente. Vous ne pouvez pas ajouter l'authentification avant d'avoir des pages à protéger. Vous ne pouvez pas ajouter les paiements avant d'avoir des utilisateurs à facturer. Vous ne pouvez pas tester efficacement avant d'avoir des fonctionnalités à tester.

Chaque désastre de vibe coding que j'ai vu suit le même schéma : quelqu'un a construit la fonctionnalité cool en premier (paiements, tableaux de bord, UI fancy) et a boulonné les trucs ennuyeux après (auth, sécurité, gestion d'erreur). Les trucs ennuyeux ne s'ajustent jamais bien parce qu'ils n'ont jamais fait partie de l'architecture.

Sautez des étapes, et vous câblez l'électricité dans une maison sans murs.

La boucle de la mort (et comment s'en échapper)

Vendredi après-midi. Vous voulez juste livrer un dernier fix avant le week-end. Le bug est petit. Vous promptez l'IA. Le fix marche. Sauf que maintenant la sidebar est cassée. Vous promptez encore. Sidebar réparée, mais le bouton save ne soumet plus. Un prompt de plus. Save marche, sidebar recassée, et la page de connexion est un écran blanc.

Votre piscine vous attend. Vos enfants demandent quand vous avez fini. Vous continuez à prompter. Il y a trois rounds vous aviez un bug. Maintenant vous en avez quatre. 🫠

C'est la boucle de la mort.

Chaque patch répare une chose et en casse une autre parce que l'IA continue à traiter les symptômes. La cause racine est toujours là, enterrée sous des couches de fixes rapides. Vous ne débuggez plus. Vous empirez les choses à chaque prompt.

La sortie est toujours la même. Vous arrêtez de prompter. Vous revenez à la dernière version qui marchait (c'est pour ça que Git existe). Et vous revenez avec un prompt différent : "Ne répare pas le symptôme. Explique ce que cette erreur signifie à la racine. J'ai essayé de la réparer deux fois et chaque fix a créé de nouveaux bugs."

Parfois la fonctionnalité est trop emmêlée pour être sauvée. Vous revenez en arrière et la reconstruisez de zéro avec une meilleure spec. Ça sonne douloureux. En fait c'est plus rapide qu'un sixième round de tape-taupe.

Les équipes restent coincées dans des boucles de la mort pendant des semaines. C'est pourquoi le diagnostic dans la crise de productivité du coding IA de Bloomberg était à côté : ils ont mesuré la vitesse de sortie, pas la fréquence de boucle.

La qualité de spec, c'est tout

Même fonctionnalité. Deux specs. Deux résultats.

Mauvaise spec : "Construis-moi une page client."

L'IA devine tout. Layout, colonnes, boutons, que se passe-t-il quand il n'y a pas de données. Le résultat est aléatoire. Vous n'avez rien spécifié, donc l'IA a rempli chaque blanc avec son propre jugement. Qui est souvent faux.

Bonne spec : "Construis une page liste de clients avec une navigation sidebar. Dans la zone principale, un tableau avec colonnes : nom, téléphone, email, ville. Une barre de recherche au-dessus du tableau. Un bouton 'Ajouter client' qui ouvre un formulaire modal. Quand il n'y a pas de clients, affiche 'Pas encore de clients, ajoutez le premier' avec un bouton. État de chargement avec un skeleton. État d'erreur avec un message user-friendly."

Chaque élément est spécifié. Le résultat est prévisible. Et (c'est la clé) vous pouvez le vérifier, parce que vous savez exactement ce que vous avez demandé.

Mauvaise spec = mauvais contrat. L'IA remplit les blancs avec des suppositions. Bonne spec = bon contrat. Chaque attente énoncée, chaque comportement défini. J'ai construit le framework complet de contrats de prompts après assez de fonctionnalités qui ont mal tourné. Même principe : la spec est le produit.

C'est apprenable. Votre première spec fera deux phrases. À la dixième, vous écrirez deux pages sans y penser. La méthode vous forme, une fonctionnalité à la fois.

Spec. Construire. Vérifier. Répéter.

L'IA écrit tout le code. J'en écris zéro. Mais je spécifie exactement ce que je veux, je comprends ce qui a été construit (sans lire le code), et je vérifie tout systématiquement. C'est comme ça que je livre des apps de production avec de vrais utilisateurs, de vrais paiements, et une isolation de données qui tient vraiment.

"Construire" et "livrer" ne sont pas le même verbe.

Vous avez demandé à une IA de vous construire une app. Maintenant vous savez comment vraiment la livrer. Huit étapes, même boucle. Fastidieux. Pas sexy.

Aller au bout, c'est à vous de voir.

(*) La couverture est générée par IA. La maison en paille est vraie par contre.