Je veux être très clair sur une chose avant de commencer.
Gardez ça précieusement :)
Je ne suis pas développeur. Je ne l'ai jamais été. Je n'ai pas de diplôme en informatique. Je n'ai suivi aucun bootcamp de codage. Je suis incapable de lire la plupart du code et de vous dire ce qu'il fait.
Mais le week-end dernier, j'ai mis en ligne une application web fonctionnelle. De vrais utilisateurs se sont inscrits. De vraies données ont été stockées. De vraies fonctionnalités ont marché.
J'ai construit l'intégralité du truc avec Claude Code en deux jours. Et je vais vous dire la vérité sur ce que cette expérience a vraiment été. Pas la version édulcorée. La réalité bordélique, frustrante et pleine de percées.
Parce que toutes les histoires du genre "j'ai créé une app avec l'IA" en ligne donnent l'impression que c'est facile. Ça ne l'est pas. Mais c'est très, très possible.
Samedi matin : l'idée
Je voulais construire un outil simple. Un calendrier de contenu qui permet de planifier vos publications sur différentes plateformes, de les glisser-déposer entre les jours et de les marquer comme publiées. Rien de révolutionnaire. Mais quelque chose dont j'avais vraiment besoin pour mon propre workflow.
J'ai ouvert Claude Code dans mon terminal pour la première fois à 9h samedi.
À 9h15, j'avais déjà fait ma première erreur.
Erreur n°1 : commencer sans plan
Ma toute première instruction à Claude Code a été :
Construis-moi une application de calendrier de contenu
Claude a généré un tas de fichiers. Quelque chose est apparu à l'écran. On aurait dit un calendrier de contenu conçu par quelqu'un qui n'avait jamais vu de calendrier.
C'est là que 90 % des gens abandonnent. Ils tapent une instruction vague, obtiennent un résultat vague et concluent que le codage par vibes ne marche pas.
Le problème n'était pas Claude. Le problème, c'était moi. Je ne lui avais rien donné de concret avec quoi travailler.
Ce que j'aurais dû faire :
J'aurais dû commencer en mode Planification. Appuyez sur Shift + Tab dans Claude Code pour passer du mode Action au mode Planification. En mode Planification, Claude réfléchit avant de construire. Il pose des questions. Il conçoit l'architecture. Il vous montre ce qu'il prévoit de créer.
J'ai fait machine arrière et j'ai fait les choses correctement :
Je veux construire une application web de calendrier de contenu. Avant d'écrire du code, planifions ça.
L'application doit avoir :
- Une vue hebdomadaire avec 7 colonnes (lundi à dimanche)
- La possibilité d'ajouter des publications avec un titre, une plateforme (Twitter, LinkedIn, Instagram) et un statut (brouillon, programmé, publié)
- Glisser-déposer pour déplacer les publications entre les jours
- Un design simple et propre utilisant Tailwind CSS
- Les données stockées dans une base de données locale pour qu'elles persistent entre les sessions
Quelle stack technologique devrions-nous utiliser ? Quelle est la structure des dossiers ? Explique-moi l'architecture avant de construire quoi que ce soit.
Claude est revenu avec un plan détaillé. Next.js pour le framework. SQLite pour la base de données. Tailwind pour le style. Une structure de dossiers propre, fichier par fichier.
Leçon retenue : commencez toujours en mode Planification. Décrivez toujours ce que vous voulez en détail. Les 5 minutes que vous passez à planifier vous évitent 2 heures de reconstruction.
Erreur n°2 : essayer de tout construire d'un coup
Après avoir planifié, j'étais surexcité. J'ai dit à Claude de tout construire d'un seul coup.
Le résultat était un foutoir. Certaines fonctionnalités marchaient. D'autres étaient à moitié implémentées. Le glisser-déposer était cassé. La base de données ne sauvegardait pas correctement. Je n'avais aucune idée par où commencer pour réparer.
Ce que j'aurais dû faire :
Construire une fonctionnalité à la fois. C'est la règle d'or du codage par vibes.
J'ai recommencé et suivi cet ordre :
Session 1 : juste la mise en page de base. Sept colonnes. Aucune fonctionnalité. Session 2 : ajouter la possibilité de créer une publication (juste un formulaire simple). Session 3 : afficher les publications sauvegardées dans la colonne du jour correspondant. Session 4 : ajouter la fonctionnalité glisser-déposer. Session 5 : ajouter la fonctionnalité de statut (brouillon/programmé/publié). Session 6 : rendre le tout joli.
Chaque fonctionnalité a eu sa propre conversation. Contexte frais. Tâche claire. Résultat propre.
Quand je construisais une fonctionnalité à la fois, chacune marchait parfaitement. Quand j'essayais de tout construire d'un coup, rien ne marchait.
Leçon retenue : une conversation par fonctionnalité. Ne mélangez jamais plusieurs fonctionnalités dans la même session Claude Code.
Erreur n°3 : ne pas créer de fichier CLAUDE.md
Samedi après-midi, j'avais une mise en page de base fonctionnelle et j'étais excité. Mais je rencontrais sans cesse les mêmes problèmes :
Claude ajoutait sans cesse de la complexité inutile. Il créait des systèmes de gestion d'erreurs élaborés alors que je voulais juste un simple try-catch. Il ajoutait des bibliothèques d'animation alors que je voulais juste une transition propre. Il restructurait tout mon système de dossiers pour un petit changement demandé.
Je corrigeais les mêmes choses encore et encore.
Puis je me suis souvenu avoir lu quelque chose sur CLAUDE.md.
J'ai créé un fichier à la racine de mon projet :
CLAUDE.md
Règles du projet
- C'est un calendrier de contenu simple. Gardez tout minimal.
- Utilisez Next.js 14 avec le App Router
- Utilisez Tailwind CSS pour tout le style. Pas d'autres frameworks CSS.
- Utilisez SQLite avec Prisma ORM pour la base de données
- Restez simple. Pas d'abstractions ni de patrons de conception inutiles.
- Quand je dis "rends-le joli", je veux dire : espacement propre, polices lisibles, effets de survol subtils, coins arrondis
- N'ajoutez jamais de nouvelles dépendances sans me demander d'abord
- Demandez avant de refactoriser du code existant
Style de code
- Code simple et lisible. Un débutant doit pouvoir le comprendre.
- Noms de variables clairs. Pas d'abréviations.
- Commentaires uniquement pour la logique non évidente
Après avoir créé ce fichier, l'expérience a changé radicalement. Claude a arrêté de sur-ingénierie. Il a arrêté d'ajouter des bibliothèques aléatoires. Il a arrêté de restructurer des choses que je n'avais pas demandé à toucher.
Chaque fois que Claude faisait quelque chose que je ne voulais pas, j'ajoutais une nouvelle règle dans [CLAUDE.md](http://claude.md/). Dimanche soir, ce fichier contenait plus de 30 règles et Claude les suivait toutes parfaitement.
Leçon retenue : créez [CLAUDE.md](http://claude.md/) dès le premier jour. Mettez-le à jour constamment. C'est l'outil le plus puissant de Claude Code.
Erreur n°4 : ne pas utiliser de captures d'écran
Samedi soir. L'application marche fonctionnellement mais est moche. J'ai tapé :
Rends le design plus moderne et professionnel
Claude a changé des choses. Ça avait l'air différent. Pas mieux, juste différent.
J'essayais de décrire des problèmes visuels avec des mots. C'est incroyablement inefficace.
J'ai donc commencé à prendre des captures d'écran de sites web dont j'aimais le design. Je les ai collées directement dans Claude Code :
[capture d'écran d'une interface de calendrier propre]
Je veux que mon calendrier ressemble à ça. Notamment :
- Cette nuance exacte de gris pour l'arrière-plan
- Ces cartes arrondies pour chaque publication
- Cet espacement entre les éléments
- La façon dont le jour actif est surligné en bleu
Claude a reproduit le design presque parfaitement. Du premier coup.
Ensuite, quand quelque chose clochait, au lieu de le décrire, je prenais une capture d'écran, j'entourais le problème, je la collais et je disais "cet espacement est faux" ou "cette police est trop petite."
Leçon retenue : les captures d'écran sont 10 fois plus efficaces que les mots pour le feedback visuel. Collez toujours des images plutôt que de décrire ce que vous voyez.
Dimanche : tout s'est assemblé
Dimanche matin, j'avais une application fonctionnelle avec un design propre, glisser-déposer, des données persistantes et une base de données qui marchait. J'avais construit le tout sans comprendre la majeure partie du code.
Mais ça n'existait que sur mon ordinateur portable. Il était temps de déployer.
Erreur n°5 : avoir peur du déploiement
Le déploiement me paraissait terrifiant. Serveurs. Noms de domaine. DNS. Fichiers de configuration.
J'ai presque arrêté. J'ai presque décidé que "tourner en local, c'est bien assez."
Mais j'ai persévéré et j'ai demandé à Claude :
Je veux déployer cette application en ligne. Je veux utiliser Vercel parce qu'on dit que c'est le plus simple. Explique-moi les étapes exactes.
Claude m'a donné sept étapes :
- Pousser le code sur GitHub (Claude m'a aidé à configurer Git)
- M'inscrire sur Vercel (gratuit)
- Connecter Vercel à mon dépôt GitHub
- Configurer les variables d'environnement pour la base de données
- Cliquer sur Déployer
- Attendre 90 secondes
- Obtenir mon URL en ligne
J'ai suivi les étapes. Trois minutes plus tard, mon application était en ligne. J'ai envoyé l'URL à cinq personnes. Ils l'ont ouverte. Ça marchait.
Leçon retenue : le déploiement n'est pas effrayant. C'est juste une liste de choses à faire. Claude vous guidera à chaque étape.
Les 12 règles que j'aurais aimé connaître avant de commencer
Tout ce que j'ai appris en deux jours, résumé en règles :
Règle 1 : Commencez toujours en mode Planification. Shift + Tab. Réfléchissez avant de construire.
Règle 2 : Une conversation par fonctionnalité. Un contexte frais est un meilleur contexte.
Règle 3 : Créez CLAUDE.md dès le premier jour. Chaque correction devient une règle permanente.
Règle 4 : Utilisez des captures d'écran pour chaque problème visuel. Entourez le problème. Collez-la directement.
Règle 5 : Construisez d'abord la version la plus simple. N'ajoutez de la complexité qu'après que la version simple fonctionne.
Règle 6 : Décrivez ce que vous voulez en détail. Plus votre instruction est spécifique, meilleur est le résultat. "Construis une page de connexion" donne quelque chose de mauvais. "Construis une page de connexion avec des champs email et mot de passe, un lien 'mot de passe oublié' en dessous, un bouton de soumission bleu et une redirection vers /dashboard en cas de succès" donne exactement ce que vous avez demandé.
Règle 7 : Utilisez /compact quand les conversations deviennent longues. La qualité de Claude baisse quand le contexte se remplit.
Règle 8 : Faites un commit Git après chaque fonctionnalité qui marche. Claude peut vous aider à le faire. Si quelque chose casse, vous pouvez revenir en arrière.
Règle 9 : Quand quelque chose casse, copiez le message d'erreur et collez-le dans Claude. Dites "Diagnostique la cause racine avant de réparer quoi que ce soit." Claude trouve presque toujours le problème instantanément.
Règle 10 : N'essayez pas de comprendre chaque ligne de code. Comprenez ce que fait chaque fichier et comment ils se connectent. C'est suffisant pour diriger Claude efficacement.
Règle 11 : Quand Claude reste bloqué dans une boucle à réparer la même chose encore et encore, arrêtez. Commencez une nouvelle conversation. Collez seulement le fichier concerné et une description claire du problème.
Règle 12 : Lancez-le avant qu'il soit parfait. La version 1 n'a pas besoin d'être belle. Elle doit fonctionner. Vous pourrez toujours l'améliorer dans la version 2.
Ce que j'ai construit depuis ce week-end
C'était il y a trois semaines. Depuis, j'ai construit :
- Un portail d'onboarding client avec connexion et téléchargement de fichiers
- Un tableau de bord interne qui suit mes métriques de contenu
- Un générateur de factures simple qui crée des PDF à partir d'un formulaire
- Un gestionnaire de marque-pages qui sauvegarde et organise les liens par thème
Je ne sais toujours pas lire la plupart du code. Je ne comprends toujours pas 80 % de ce qui se passe dans les fichiers. Mais je peux décrire ce que je veux assez clairement pour que Claude le construise. Je peux déboguer des problèmes en montrant l'erreur à Claude. Je peux déployer des produits fonctionnels en ligne.
C'est ça, le codage par vibes. Vous n'êtes pas le programmeur. Vous êtes le chef de produit. Claude est le programmeur. Votre travail est de savoir quoi construire et de le communiquer clairement.
La plupart des gens continueront à se dire qu'ils doivent apprendre à coder avant de pouvoir construire quoi que ce soit.
Ceux qui ouvrent leur terminal ce week-end auront une application qui marche lundi matin. Je le sais parce que c'est exactement ce qui m'est arrivé.
Suivez-moi @eng_khairallah1 pour plus de cours, d'outils et de workflows IA. Nouveau contenu chaque semaine.
J'espère que ça vous a été utile, Khairallah ❤️
