Un vendredi soir, vous décrivez votre idée à Claude. Deux heures plus tard, l'application tourne : les écrans s'enchaînent, les données s'enregistrent, la démo impressionne. Vous n'avez presque pas touché au clavier. Puis les semaines passent. Un bug étrange apparaît, que ni vous ni Claude n'arrivez à coincer. Chaque nouvelle fonctionnalité en casse une ancienne. Les sessions s'allongent, la facture de tokens aussi, et le projet qui avançait à toute vitesse se met à reculer.
Ce guide existe pour ce moment précis. Coder avec une IA fonctionne, et fonctionne remarquablement bien. Mais c'est une pratique qui s'apprend, avec ses gestes, ses outils et ses pièges. Autrement dit : un métier.
La soirée magique, et le lendemain
Le scénario du vendredi soir n'a rien d'une caricature : c'est la trajectoire normale d'un projet lancé sans méthode. Et il faut commencer par dire ce que ce guide ne dira jamais : ce n'est pas de votre faute, et ce n'est pas celle de l'outil.
Claude fait exactement ce qu'on lui demande. Le problème, c'est que "fais-moi une application de réservation" ne demande presque rien, et laisse l'IA décider de tout : l'architecture, les cas limites, la gestion d'erreurs, la structure des données. Elle décide vite, avec assurance, et de façon plausible.
Le code plausible est le plus dangereux qui soit : il compile, il marche à la démo, et il est faux dans les recoins que personne n'a regardés.
En quinze ans de développement mobile, j'ai repris beaucoup de projets en difficulté. Depuis deux ans, une nouvelle catégorie est apparue : les projets générés par IA qui "marchent globalement". Ils partagent quatre symptômes, toujours les mêmes.
Les quatre symptômes du projet sans méthode
- 01 · Les bugs fantômesLe code n'a jamais été testé, seulement essayé. Un essai vérifie le chemin heureux, un test vérifie aussi les recoins. Sans tests, chaque correction est une rustine posée à l'aveugle, qui en fissure une autre plus loin.
- 02 · Le fichier uniqueSans consigne d'architecture, le réflexe de l'IA est connu : tout dans un app.js qui enfle à chaque demande. Et pour la moindre retouche, l'agent réécrit ce fichier entier : chaque modification coûte le prix du fichier complet, et chaque réécriture peut glisser une régression dans du code qui marchait la veille. C'est le plus grave des quatre, et le chapitre 4 lui est entièrement consacré.
- 03 · La structure illisibleChaque session a pris ses propres décisions, faute de mémoire commune : trois conventions de nommage, deux façons d'appeler l'API, des composants qui font la même chose. Le projet n'a pas été conçu, il s'est accumulé.
- 04 · La facture de tokensLe symptôme le plus discret et le plus révélateur : sessions interminables, fichiers collés dix fois, le modèle le plus cher pour renommer une variable. Un contexte mal géré se paie deux fois, en euros et en qualité (chapitre 10).
La même demande, deux métiers
Regardez la différence, sur un cas qui va nous accompagner tout au long du guide : Talia, kiné, veut un site de réservation pour son cabinet. Voici la demande telle qu'elle arrive le vendredi soir :
❯ Fais-moi un site de réservation pour le cabinet de Talia. · Claude génère... Écriture de app.js... Terminé. Tout le site tient dans un fichier. ✓ Le site tourne sur http://localhost:3000 ✓ Annulation en un clic : le patient reçoit /annuler?id=812 1 fichier, 1 240 lignes : écrans, données, logique métier mélangés. Chaque retouche réécrira ce fichier en entier : des tokens facturés à chaque fois, et des régressions glissées au passage.
Et voici la même demande, formulée par quelqu'un dont c'est le métier :
❯ Lis PRODUCT.md et CLAUDE.md. On attaque la réservation de créneaux. ❯ Contraintes : une kiné, séances de 30 min, annulation jusqu'à 24 h avant. ❯ Propose un plan et le schéma de données. On code après validation, ❯ et chaque règle métier a son test. · Claude lit le projet... Plan proposé : 1. schéma (Patient, Creneau, Reservation) 2. règle des 24 h côté serveur, testée 3. UI ensuite. Question avant de commencer : que se passe-t-il si deux patients réservent le même créneau en même temps ?
Vibe coding, vibe engineering
Le second prompt n'est pas plus long à écrire qu'un mail. Mais tout a changé, et le métier tient dans cet écart. Les chapitres 3 et 4 vous apprennent à produire ce cadrage systématiquement.
Le terme "vibe coding" a été lancé début 2025 par Andrej Karpathy, cofondateur d'OpenAI : coder en décrivant, accepter ce qui sort, ne jamais lire le code. Pour un prototype du week-end, c'est une liberté formidable. Le malentendu, c'est de croire que la même posture produit un logiciel qui dure.
Simon Willison, l'un des observateurs les plus respectés du domaine, a forgé le terme d'en face : "vibe engineering". Même outil, autre posture : l'IA écrit l'essentiel du code, mais un humain cadre, fait vérifier, assume la responsabilité de ce qui part en production. Son constat rejoint le mien.
Faire produire du bon logiciel à des agents récompense l'expérience d'ingénierie, elle ne la remplace pas.
Concrètement, le métier ne s'est pas volatilisé, il s'est déplacé :
Où vit la valeur d'un développeur
Avant, la valeur était ici
- Écrire le code ligne à ligne
- Connaître les API par cœur
- Taper vite, débugger à la main
- Être le seul à savoir où tout se trouve
Elle est maintenant là
- Cadrer : brief, contraintes, critères de done
- Faire vérifier : tests, build, preuves exécutables
- Orchestrer : les bons rôles, le bon modèle, au bon moment
- Décider : relire les plans, trancher, assumer la prod
Bonne nouvelle pour les développeurs : vos années d'expérience sont l'atout maître de la colonne de droite. Bonne nouvelle pour les non-développeurs : la colonne de droite s'apprend sans savoir écrire une boucle for.
Une équipe entière dans un terminal
Il reste une idée reçue à démonter avant d'entrer dans la méthode : "Claude est un développeur". C'est très en dessous de la réalité. Une équipe qui livre un produit, ce n'est pas un développeur : c'est un product owner qui cadre le besoin, un architecte qui structure, un développeur qui implémente, un testeur qui cherche ce qui casse, un expert sécurité qui audite avant la mise en prod, un réviseur qui relit, et quelqu'un qui livre proprement.
Claude peut tenir chacun de ces postes, et les tenir bien, à une condition : qu'on les lui fasse jouer un par un, avec la posture et le regard de chaque rôle. C'est le cœur du chapitre 8, et honnêtement, c'est le chapitre qui change le plus la pratique de ceux qui l'appliquent.
Le guide suit cette logique de bout en bout, en quatre actes :
- Acte I · Changer de regardComment Claude pense (ch. 2), comment lui donner une mémoire de projet (ch. 3), et l'architecture qui décide de tout le reste (ch. 4).
- Acte II · Le geste professionnelExplorer et planifier avant de coder (ch. 5), faire vérifier (ch. 6), itérer proprement (ch. 7).
- Acte III · L'équipe dans le terminalTous les rôles (ch. 8), la boîte à outils skills, subagents, MCP et hooks (ch. 9), payer juste (ch. 10).
- Acte IV · Le niveau au-dessusClaude à distance et automatisé (ch. 11), la génération de contenu (ch. 12), et les pièges nommés avec l'auto-audit de votre pratique (ch. 13).
Questions fréquentes sur le vibe coding
Qu'est-ce que le vibe coding ?
Le vibe coding consiste à créer un logiciel en décrivant ce qu'on veut à une IA et en acceptant le code produit sans le lire. Le terme a été popularisé début 2025 par Andrej Karpathy. La pratique est excellente pour prototyper une idée en quelques heures, mais insuffisante seule pour un produit destiné à durer : sans cadrage ni vérification, les bugs et la dette technique s'accumulent aussi vite que les fonctionnalités.
Peut-on créer une application sans savoir coder ?
Oui, et c'est l'un des apports majeurs d'outils comme Claude Code : cadrer un besoin, exiger des tests, découper le travail et relire ce qui est proposé s'apprennent sans écrire de code. Mais soyons honnête : l'expérience creuse l'écart. Un développeur senior qui maîtrise le vibe coding atteint une qualité exemplaire, parce qu'il reconnaît en une seconde une mauvaise architecture, un test creux ou une faille. Un non-développeur peut livrer un produit solide, au prix de plus de méthode, plus de vérification et plus d'humilité sur le périmètre. C'est exactement pour cela que c'est un métier, et ce guide existe pour combler l'écart.
Pourquoi mon application générée par IA est-elle pleine de bugs ?
Parce qu'elle a été essayée, pas testée. Une IA à qui l'on ne demande que "fais que ça marche" optimise le chemin de démonstration, pas les cas limites : entrées invalides, accès concurrents, erreurs réseau. La solution n'est pas de générer moins, mais d'exiger des preuves : tests unitaires et fonctionnels, critères de done exécutables, revue par un rôle séparé.
Qu'est-ce que le vibe engineering ?
Le terme, proposé par Simon Willison, désigne la pratique professionnelle du développement assisté par IA : l'agent écrit l'essentiel du code, l'humain cadre le besoin, impose des vérifications exécutables, orchestre les rôles et assume ce qui part en production. C'est la différence entre subir la vitesse de l'IA et la diriger.
La suiteAu chapitre 2, on ouvre le capot : comment Claude pense réellement, ce qu'est la fenêtre de contexte, et pourquoi cette seule notion explique toutes les bonnes pratiques du guide.
David Silvera
Développeur mobile & web freelance · 15 ans · Android, iOS, React Native, Next.js
Ce guide est tiré de ma pratique quotidienne : ce site lui-même est développé avec Claude, selon la méthode qu'il enseigne. J'accompagne aussi les équipes qui veulent monter en compétence : audit de pratique, formation, mise en place d'outillage.
Discutons de votre équipe