Construire une app complète avec Claude Code : exemples concrets

Un builder sans aucun background en game dev a sorti un jeu GTA en navigateur tournant sur de vraies villes Google Earth en un seul week-end. Claude a écrit environ 80 % du code. Le jeu récupère de vraies stations de police, aéroports et ports depuis OpenStreetMap. La radio in-game se syntonise automatiquement sur les stations locales via l'API Radio Garden.

Ce n'est pas une démo. C'est une vraie liste d'attente sur cw.naveen.to.

Le schéma derrière ce build, et plusieurs autres comme lui, est précis et reproductible. Ce post explique ce que les builds réussis ont fait et ce qui a mal tourné quand ils ne l'ont pas fait.

Ce qu'on peut vraiment construire en un week-end

Commençons par trois builds réels d'avril 2026. L'étendue compte.

Naveen (@naveenvkt sur X) a sorti Crimeworld : un jeu GTA en navigateur sur de vraies villes Google Earth. Stack : Cesium, Google 3D Tiles, Three.js, API Radio Garden, et données OpenStreetMap. Aucun background en game dev. Claude a écrit environ 80 % du code. Le build s'est fait en un seul week-end. C'est fonctionnel, avec quelques bugs par-ci par-là, et il a une vraie liste d'attente.

Santiago a construit career-ops : un système IA de recherche d'emploi sans aucun code d'application traditionnel. Tout le système fait environ 3 200 lignes de fichiers markdown de prompts. Quatorze modes de compétences vivent dans un répertoire modes/. CLAUDE.md est la couche d'orchestration. Le système a évalué 740+ offres d'emploi, généré 100+ CVs optimisés ATS, et décroché un poste de Head of Applied AI. Il utilise un traitement par lots en parallèle avec des workers claude -p pour les sous-agents. La validation humaine avant chaque soumission est intégrée dans le design. Le système note les emplois de A à F et déconseille de postuler en dessous de 4,0/5. Le code source est sous licence MIT sur santifer/career-ops sur GitHub.

Un troisième builder sans background en finance a testé une stratégie de comptage de places de parking par satellite, utilisée par des hedge funds. Il a décrit l'hypothèse en anglais courant : des images satellites optiques des parkings de détaillants devraient prédire les résultats. Claude a construit tout le pipeline d'analyse depuis cette description. Quand l'approche optique a échoué avec une précision d'environ 33 %, le builder a décrit une nouvelle hypothèse en anglais courant : le radar réfléchit différemment sur les véhicules en métal que sur l'asphalte. Claude a reconstruit le pipeline de zéro. Le système final récupère des données optiques Sentinel-2 et radar Sentinel-1 via Google Earth Engine, traite les limites des parkings depuis OpenStreetMap, et exécute des tests de permutation, des tests binomiaux, et un bootstrap resampling sur 35+ scripts Python. Le radar sur trois détaillants a atteint 100 % de précision. Sur dix détaillants, il est tombé à 50 %. La conclusion du builder : "le fossé défensif, c'est la qualité des données, pas l'algorithme." C'est le type de résultat honnête qu'on obtient quand on construit pour tester plutôt que pour prouver.

Trois domaines différents. Trois backgrounds techniques différents. Une approche cohérente. Ils ont tous décrit ce qu'ils voulaient en anglais courant, découpé le travail en morceaux, et laissé Claude s'occuper de l'implémentation.

Avant d'écrire le premier prompt

La spec d'abord. Toujours.

Les recommandations officielles d'Anthropic pour Claude Code : laisse Claude t'interviewer avant d'écrire le moindre code. Demande à Claude de poser des questions de clarification sur l'implémentation technique, l'UI/UX, les cas limites, les contraintes et les compromis. Écris les réponses dans un fichier SPEC.md. Démarre une nouvelle session pour exécuter depuis cette spec. Le builder de WorthIt (un dev junior en bootcamp, principalement backend Java, sans expérience préalable d'app complète) l'a dit ainsi : "les prompts détaillés battent les vagues à chaque fois, des specs produit complètes, pas 'construis-moi un dashboard.'"

CLAUDE.md n'est pas de la documentation de projet. Cette distinction compte plus que la plupart des guides ne le laissent entendre.

Le conseil standard est de remplir CLAUDE.md avec des descriptions de stack technique, des conventions, et des notes sur ta structure de dossiers. Cette approche a un vrai défaut. Tout ce qui est dans CLAUDE.md a une haute priorité dans le contexte de Claude. Un CLAUDE.md trop chargé fait que Claude perd des instructions spécifiques. Si Claude continue à faire quelque chose que tu ne veux pas malgré une règle que tu as écrite, le fichier est probablement trop long et la règle se noie.

L'usage le plus puissant de CLAUDE.md, c'est comme fichier de contrôle d'orchestration. Définis des workflows opérationnels et des patterns de délégation. Déplace la documentation de stack et les conventions de code dans des skills qui se chargent à la demande. Garde CLAUDE.md concentré sur les choses que Claude ne peut pas déduire en lisant ton code : commandes bash, conventions de nommage des branches, instructions de test, décisions architecturales prises pour des raisons non évidentes, particularités de l'environnement de dev.

Le test officiel pour chaque ligne de CLAUDE.md : supprimer cette ligne amènerait-il Claude à faire une erreur ? Si non, coupe-la.

Utilise /init pour générer un CLAUDE.md de départ depuis ton codebase existant avant d'écrire quoi que ce soit de zéro.

La hiérarchie de priorité des instructions pour les projets structurés : CLAUDE.md (haute, toujours chargé) au-dessus des répertoires de règles (haute, filtré par chemin) au-dessus des skills (moyen, chargé à la demande) au-dessus du contenu des fichiers (standard, quand lus). Le sweet spot pour un projet structuré, c'est 200 à 400 lignes de règles opérationnelles, pas 60 lignes d'anecdotes sur le projet.

SESSION.md est l'autre pièce que la plupart des builders sautent. Maintiens un fichier séparé qui trace ce qui a été accompli, l'état actuel, les points ouverts, et les fichiers clés modifiés. Mets-le à jour avant de terminer chaque session. Démarre les nouvelles sessions avec "Resume project X". Note pourquoi tu as décidé d'implémenter ou non une feature, avec des dates. SESSION.md transforme le dépassement de contexte d'un événement catastrophique en quelque chose de gérable.

Le processus de build week-end

Tous les builds d'apps complètes réussis ont suivi le même rythme : une feature par session, /clear entre les features.

La contamination de contexte des features précédentes crée des suppositions incorrectes et des bugs subtils. Quand tu termines une feature et commences la suivante, Claude emporte des suppositions sur ce que tu faisais. Ces suppositions sont souvent fausses pour la nouvelle feature. /clear remet le contexte à zéro et te donne un point de départ propre.

Plan Mode avant chaque feature non triviale. Shift+Tab deux fois ou /plan. Claude explore ton codebase et liste les fichiers qu'il va créer, les fonctions qu'il va introduire, les cas limites qui existent. Examine et affine le plan avant l'exécution. Ajoute toujours "Liste les suppositions" à ton prompt de plan. Les suppositions que Claude fait silencieusement sont la source des bugs.

Ce qui fait un bon prompt :

Périmètre : ce que fait cette feature et explicitement ce qu'elle ne fait pas
Contraintes : quels fichiers sont hors limites, quels patterns suivre
Un fichier exemple : pointe vers un fichier existant qui a la forme que tu veux
Critères de succès : précis, testables, pas "fais que ça marche"

Le critère de succès mérite d'être souligné. Au lieu de "implémenter la validation email", écris "Écris une fonction validateEmail. Cas de test : user@example.com est vrai, invalid est faux, user@.com est faux. Lance les tests après implémentation." Sans critères de succès, tu es la seule boucle de feedback.

Examine toujours le diff avant d'accepter une sortie. Vérifie spécifiquement les suppressions de fichiers, les renommages d'API publiques, les changements de fichiers hors limites, les nouvelles entrées dans package.json, et les migrations de schéma. Claude peut renommer des endpoints d'API publiques dans tout ton codebase sans prévenir. Chaque client qui dépendait de ces endpoints va casser. Le diff, c'est là que tu l'attrapes.

Gestion du contexte : la compétence qui sépare les bons builds des abandonnés

Comprendre ce qui remplit ta fenêtre de contexte, c'est ce qui sépare les builds qui finissent de ceux qui dérivent dans la confusion.

La fenêtre de contexte effective pour Claude Code est d'environ 200K tokens, mais environ 20K sont réservés pour la sortie de compaction. L'auto-compact se déclenche quand il reste environ 13 000 tokens. Un seuil d'avertissement apparaît autour de 20 000 tokens. Le compact manuel est bloqué en dessous de 3 000 tokens. Ces chiffres viennent de l'analyse du code source de Claude Code.

Trois commandes officielles :

/clear : réinitialise le contexte entre des tâches sans lien. Après deux corrections ratées sur le même problème, arrête d'essayer de corriger et utilise /clear avec un meilleur prompt initial.
/compact <instructions> : résume avec un focus personnalisé. Exemple : /compact Focus on the API changes garde le contexte pertinent et laisse tomber le reste.
Esc + Esc ou /rewind : reviens en arrière avant que les choses aillent de travers.

Pour les tâches d'investigation, utilise des sous-agents. Lance-les dans des fenêtres de contexte séparées, fais-leur rapporter des résumés. Ta session principale reste propre. Le pattern Writer/Reviewer fonctionne de la même façon : utilise une nouvelle session pour réviser le code que ta session principale vient d'écrire. Un contexte frais capte ce qu'un contexte fatigué rate.

Trois anti-patterns des docs officielles :

La session cuisine sink : une tâche, puis quelque chose sans lien, puis retour à la première. Le contexte se remplit de données non pertinentes. Fix : /clear.

Corriger encore et encore : approche ratée, tu corriges, ça échoue encore, tu corriges à nouveau. Après deux corrections sur le même problème : /clear et écris un meilleur prompt initial.

Exploration infinie : demander à Claude d'"investiguer" sans périmètre et il lit des centaines de fichiers. Ton contexte se remplit de code dont tu n'as pas besoin pour cette feature. Fix : délimite l'investigation précisément, ou utilise un sous-agent.

SESSION.md gère le problème de mémoire à plus long terme. Après environ 30 messages, Claude peut référencer des décisions qui n'ont jamais été prises, des fichiers mentionnés différemment, ou du code modifié plus tôt dans la session. La session commence à confondre ce qui s'est vraiment passé. SESSION.md comme état externe, combiné avec /clear entre les features, empêche que ça déraille un build.

Les modes d'échec dont personne ne te prévient

Ce sont des échecs documentés, précis, tous sourcés depuis de vrais projets.

Fichiers fantômes. GitHub issue #26771 sur le dépôt officiel Claude Code : Claude Code rapporte avec confiance avoir créé des fichiers qui n'ont jamais été écrits sur le disque. La sortie de l'outil dit succès. git status raconte une autre histoire. Les causes : erreurs de permissions, échecs de résolution de chemin, et appels d'outils abandonnés. Le fix est simple : toujours vérifier avec git status après des opérations sur fichiers. Ne suppose pas que le fichier existe parce que Claude l'a dit.

Hallucination de méthodes API. Claude a généré du code utilisant prisma.$upload(). Cette méthode n'existe pas dans Prisma. Autres exemples documentés : inventer des options de configuration (trustProxy comme option rate-limiter), inventer des noms de packages qui n'existent pas sur npm. Le fix : lance tes tests. Ne suppose pas que le code généré fonctionne parce qu'il a l'air raisonnable.

Le piège de l'over-engineering. Un builder avec 100+ sessions d'historique de projet a demandé à Claude de corriger un bug où des popups d'approbation n'apparaissaient parfois pas. La correction proposée par Claude : sauvegarder l'état d'approbation sur le disque pour qu'il survive aux crashes. Le problème : l'agent reprend depuis le log de session en cas de crash, donc l'état d'approbation ne serait de toute façon pas récupéré. Une correction totalement inutile qui avait l'air d'un bon engineering. La question à poser avant d'accepter toute proposition complexe : ce problème a-t-il vraiment besoin d'être résolu ?

Renommages d'API silencieux. Claude a renommé des endpoints d'API publiques dans tout un codebase sans prévenir. Chaque client qui dépendait de ces endpoints a cassé. Fix : toujours examiner le diff avant d'accepter. Vérifier spécifiquement les renommages d'API publiques et les suppressions de fichiers.

Layouts mobiles. Claude génère des layouts desktop solides. Les vues mobiles ont régulièrement des éléments qui se chevauchent, du texte qui déborde, et des espacements étriqués. Claude n'a aucun mécanisme pour tester sur de vrais appareils. Fix : vérifie chaque layout sur un vrai téléphone avant de le marquer comme terminé.

Faux souvenirs de contexte. Après environ 30 messages, Claude peut référencer des décisions qui n'ont jamais été prises, des fichiers mentionnés différemment, ou du code modifié depuis le début de la conversation. La session commence à confondre ce qui s'est vraiment passé. Fix : SESSION.md comme état externe, et /clear entre les features.

Le problème des 80/20

Tu peux avoir 80 % d'une app fonctionnelle en un week-end. Les 20 % restants, c'est là que la plupart des projets vibe-codés échouent silencieusement.

Ce qui échoue silencieusement après le build initial : la conformité aux app stores, les performances sur vrais appareils, la sécurité du flux d'authentification, les décisions d'architecture (pas de tests, pas de CI/CD), et les cas limites de la logique métier. Ce n'est pas une observation théorique. Une entreprise avec des millions d'utilisateurs construite avec accélération IA avait cinq ingénieurs qui faisaient de la review de code IA pendant des mois. Leur conclusion : "Même Claude plus un développeur compétent regarderait ce code et dirait 'ouais, ça va.' Ce n'était pas bien."

Le builder de WorthIt a lancé une passe de renforcement de sécurité dédiée après le lancement et a trouvé des lacunes de validation d'entrée, une gestion des erreurs manquante, et aucune protection XSS. La sécurité n'était pas automatique. La recherche de Columbia DAPLab identifie la gestion des erreurs et la logique métier comme les patterns d'échec silencieux les plus graves et les plus courants dans le code généré par IA.

Le fix pratique : traite la sécurité comme une partie de chaque feature, pas une étape post-lancement. Lance une passe de sécurité après chaque feature majeure. Vérifie les layouts mobiles sur un vrai appareil avant de marquer quoi que ce soit comme terminé. Ajoute des tests à tes critères de succès dès le départ, pas comme une réflexion après coup.

Ce n'est pas un argument contre construire avec Claude Code. C'est un argument pour être honnête sur ce que l'outil gère automatiquement et ce qu'il ne gère pas.

L'alternative structurée

Les builds décrits ci-dessus sont tous ad hoc : une personne, une session Claude Code, feature par feature. Cette approche fonctionne et a de vraies limites.

Les limites apparaissent de façon prévisible. La sécurité n'est pas automatique. Les quality gates demandent de la discipline pour être lancées à chaque fois. L'infrastructure post-lancement (surveillance des erreurs, optimisation des performances, scanning de sécurité) doit être construite ou configurée séparément pour chaque projet. Le piège de l'over-engineering et le problème des fichiers fantômes exigent une vigilance manuelle.

Build This Now, c'est ce que les meilleurs vibe-coders se construisent pour eux-mêmes. Il emballe l'orchestration, les quality gates, et l'infrastructure post-lancement comme un système prêt à l'emploi. Les 14 commandes post-lancement (/security, /pentest, /performance, /audit) gèrent le travail que les builders individuels découvrent avoir besoin après le lancement. La sécurité au niveau des lignes sur chaque table de base de données est le comportement par défaut, pas une réflexion après coup. Les agents Quality Gate et Build Fixer attrapent les échecs qui semblent complets dans la sortie de Claude mais échouent en pratique. L'agent Planner sépare les décisions architecturales de l'implémentation, avec trois spécialistes qui analysent les features simultanément avant qu'une seule ligne de code soit écrite.

L'approche ad hoc est gratuite et fonctionne pour apprendre. L'approche structurée, c'est ce qui passe à l'échelle. buildthisnow.com a les détails.

Les builds week-end ci-dessus ne sont pas des cas exceptionnels. C'est ce qui se passe quand tu spécifies avant de prompter, que tu vides le contexte entre les features, que tu examines chaque diff, et que tu traites la sécurité comme une partie du build. L'étendue va d'un clone GTA sur Google Earth à un système de recherche d'emploi sans code d'application. Les pratiques qui les ont rendus possibles sont les mêmes.