J'aurais pu te donner un projet tout fait. Un dossier zippé à télécharger, des fichiers déjà prêts, un point de départ clé en main. C'est ce que j'avais prévu au début.
J'ai changé d'avis, parce que ce n'est pas comme ça qu'on comprend le mieux ce qu'il se passe.
Pour cette première session, on va créer le projet ensemble, depuis un dossier vide, en parlant à Claude Code. Avant même de modifier quoi que ce soit. Le projet en question est minimaliste : une page web qui affiche une citation aléatoire à chaque rechargement. Quelques fichiers, une centaine de lignes de code, un résultat visible immédiatement à l'écran. C'est exactement ce qu'il faut : assez simple pour ne pas se perdre, assez concret pour que tout ce qu'on touche se vérifie à l'œil.
Et surtout, en le créant nous-mêmes, on comprend tout de suite quelque chose d'important : Claude Code voit exactement le dossier que je lui ai ouvert dans l'application. Ni plus, ni moins. Il ne lit pas dans mes pensées, il ne connaît pas un historique secret, il n'a pas accès à une documentation cachée. Il voit le dossier qu'on a ouvert. C'est son terrain de jeu, et c'est aussi le mien.
Cette symétrie, je ne l'avais pas anticipée. Elle change tout à la façon dont on travaille ensemble.
Créer un dossier vide pour le projet
Avant d'ouvrir Claude, crée le dossier qui va accueillir le projet. Sur ton bureau (ou ailleurs, du moment que tu sauras le retrouver), crée un nouveau dossier vide et appelle-le generateur-de-citations. Rien dedans. C'est exactement ce qu'on veut.
Ouvrir l'onglet Code et pointer ce dossier
Ouvre l'application Claude, va dans l'onglet Code. Au-dessus du champ de conversation, choisis l'environnement "Local", puis sélectionne comme dossier de projet le generateur-de-citations que tu viens de créer.
À gauche de l'écran, tu vois maintenant ton dossier. Vide. Pas un fichier dedans. À droite, une zone de conversation qui attend. C'est là qu'on va parler. Pas de fenêtre noire, pas de commande à taper : tu écris, comme dans n'importe quelle conversation.
La première demande : créer le projet
Voici exactement ce que tu vas copier-coller dans Claude Code :
Dans ce dossier vide, crée-moi un mini-projet avec Vite comme outil de build minimal qui affiche une citation aléatoire à chaque rechargement de la page.
Stack minimale : HTML, CSS, JavaScript vanilla (pas de framework comme React). Le projet doit pouvoir se lancer avec npm install puis npm run dev. Une dizaine de fichiers maximum, plus le package.json standard de Vite.
Une dizaine de fichiers maximum, répartis dans une arborescence claire (index.html à la racine, un dossier css/, un dossier js/, un dossier data/ pour les citations). Code commenté en français, sobrement.
Contenu : une page web avec un titre principal "Daily Quote" en haut. En dessous, une zone qui affiche une citation aléatoire et son auteur. Un bouton "Nouvelle citation" qui en affiche une autre sans recharger la page. Les citations sont stockées dans un fichier JSON séparé avec une dizaine de citations en anglais.
Design minimaliste, fond clair, typographie serif pour la citation, sans-serif pour le reste. Centré dans la page. Pas de couleurs criardes, pas d'animations.
Ajoute un fichier README.md à la racine qui explique en 10 lignes maximum ce que fait le projet et comment le lancer.
Envoie. Et observe.
Ce qui se passe ensuite
Claude Code se met au travail. Tu vas le voir réfléchir quelques secondes, puis te proposer de créer un premier fichier. Il te demande l'autorisation. Tu valides.
Il en propose un deuxième. Tu valides. Un troisième. Tu valides.
Au début, ce ballet de validations peut sembler fastidieux. C'est en fait une bonne nouvelle : Claude Code ne fait jamais rien sans te demander. Pas de fichier créé en douce, pas de modification appliquée à ton insu. À chaque étape, tu vois ce qu'il veut faire avant qu'il le fasse.
Cette logique d'autorisation, on va la retrouver tout au long du travail. C'est le contrat de base.
Pendant qu'il crée les fichiers, regarde l'arborescence à gauche. Tu vois les fichiers apparaître un par un dans ton dossier qui était vide il y a deux minutes. C'est satisfaisant à observer.
Ce que tu as maintenant sous les yeux
Une fois que Claude Code a fini, tu te retrouves avec un dossier qui contient une dizaine de fichiers. Un index.html à la racine, des dossiers css/, js/, data/, un README.md.
Tu ne sais probablement pas à quoi sert chacun. C'est normal, et c'est sans importance pour la suite.
Ce qu'il faut retenir à ce stade : tu as fabriqué ce projet. Pas en l'écrivant ligne par ligne, mais en formulant une intention claire que Claude Code a traduite en fichiers. Cette nuance compte. Le projet n'est pas une boîte noire qu'on t'a donnée. C'est quelque chose que tu as commandé, qu'il a livré, et que tu peux maintenant inspecter, modifier, casser si tu veux.
Lancer le projet pour vérifier
Avant d'aller plus loin, on vérifie que ce que Claude Code a créé fonctionne vraiment.
Tu n'as pas besoin de lancer quoi que ce soit toi-même. Demande-le simplement : "Lance le projet et montre-moi le résultat." Claude Code démarre le petit serveur nécessaire et ouvre un aperçu directement dans l'application, dans un panneau à côté de la conversation.
Tu devrais voir une page avec le titre "Daily Quote" en haut, une citation au milieu, un bouton en dessous. Clique sur le bouton : la citation change. C'est bon. Le projet fonctionne.
Si quelque chose cloche, reste dans la conversation et dis-le simplement : "Quand j'ouvre l'aperçu, je vois ceci à la place de ce que tu m'as décrit." Il corrigera.
La première modification : changer le titre
Maintenant qu'on a un projet qui tourne, on va le modifier. Pas pour ajouter une grosse fonctionnalité — pour changer une chose minuscule, mais visible.
J'aurais pu demander quelque chose d'ambitieux. Restructurer l'affichage, connecter le projet à une vraie API de citations, ajouter une fonction de partage. J'ai demandé de changer le titre.
Pas par manque d'ambition. Parce que c'est le bon choix pour une première modification. La modification idéale pour commencer remplit trois critères : elle est petite (quelques caractères suffisent), elle est visible (on peut la voir à l'écran sans avoir à chercher), elle est vérifiable (on sait immédiatement si ça a marché).
Changer un titre coche les trois cases. Modifier une couleur aussi. Ajouter un texte dans un pied de page, pareil. Ce que j'éviterais pour une première modification : tout ce qui touche à la logique interne, aux calculs, aux échanges avec d'autres outils. Pas parce que c'est impossible, mais parce que le résultat n'est pas visible directement à l'écran et que vérifier devient plus compliqué.
Comment formuler la demande
Voici exactement ce que j'écris dans la fenêtre de dialogue :
Le titre principal de la page affiche actuellement "Daily Quote". Je voudrais qu'il affiche "La citation du jour" à la place.
C'est tout. Pas de formule de politesse, pas de contexte technique, pas de précision sur le fichier concerné. Je décris ce que je vois et ce que je veux voir à la place.
Ce que je n'ai pas fait : chercher moi-même dans quel fichier se trouvait ce titre, ni essayer de comprendre comment le modifier. C'est précisément pour ça que Claude Code est là. Mon travail à ce moment-là, c'est de formuler clairement l'intention. Pas d'exécuter.
La frontière entre les deux, j'ai mis du temps à l'intégrer. L'intention, c'est mon territoire. L'exécution technique, c'est le sien.
Le diff : Claude Code ne fait pas, il propose
Quelques secondes après ma demande, Claude Code répond. Pas avec un long texte explicatif. Avec une proposition de modification.
Ce qu'on appelle un diff, c'est exactement ça : une proposition. Pas une action. Pas une décision. Une suggestion de changement que je peux accepter, refuser, ou renvoyer avec des précisions.
Visuellement, ça ressemble à ça :
- Daily Quote
+ La citation du jour
Ligne précédée d'un signe moins (souvent affichée en rouge) : ce qui va disparaître.
Ligne précédée d'un signe plus (souvent en vert) : ce qui va arriver à la place.
Ce qui frappe la première fois, ce n'est pas la complexité. C'est la lisibilité. Je ne comprenais pas tout le code qui entourait ces deux lignes, mais je comprenais parfaitement la proposition. "Daily Quote" remplacé par "La citation du jour". C'était écrit là, en clair, dans le diff.
Lire un diff n'exige pas de savoir coder. Ça exige de comprendre l'intention. Et l'intention, c'est mon terrain.
Valider, refuser, demander autrement
Face au diff, j'ai trois options.
Je valide : la modification est appliquée au fichier. L'application met à jour le fichier, et si je regarde l'aperçu, je verrai le nouveau titre.
Je refuse : rien ne change. Le fichier reste intact. Je peux reformuler ma demande, préciser ce que je voulais, ou passer à autre chose.
Je demande autrement : je réponds dans la fenêtre de dialogue pour corriger le tir. "En fait, je voudrais que ce soit en majuscules." ou "Le titre est au mauvais endroit, je voulais modifier l'autre." Claude Code reprend, propose un nouveau diff.
Ce va-et-vient, j'ai mis un moment à l'accepter comme normal. Au début, j'avais l'impression que si Claude Code ne faisait pas exactement ce que je voulais du premier coup, c'est que j'avais mal formulé ma demande. Que c'était ma faute. Que je devais mieux m'exprimer.
Ce n'est pas le bon cadre. Le va-et-vient n'est pas un échec. C'est le travail. On affine, on précise, on converge. Exactement comme avec un collaborateur à qui on explique ce qu'on veut.
Vérifier que ça marche vraiment
J'ai validé le diff. L'application a appliqué la modification. Le fichier a changé.
Et là, je fais quelque chose que je n'avais pas le réflexe de faire au début : je vérifie.
Pas supposé. Pas espéré. Vérifié.
Je regarde l'aperçu dans l'application (il est toujours ouvert, on ne l'a pas fermé). Je cherche le titre.
Il affiche "La citation du jour".
C'est tout. Pas besoin d'analyser le code, pas besoin de comprendre ce qui s'est passé en coulisses. La modification est visible, elle correspond à ce que j'ai demandé. C'est bon.
Ce réflexe de vérification, je ne l'avais pas naturellement. Pendant mes premières sessions, je validais les diffs et je passais à la suite en supposant que tout s'était bien passé. C'est une mauvaise habitude. Pas parce que Claude Code se trompe souvent, mais parce que vérifier prend dix secondes et évite de construire sur une base qui cloche. Si la modification n'avait pas marché, je l'aurais su immédiatement, et j'aurais pu corriger avant d'aller plus loin.
Le réflexe à acquérir : après chaque validation de diff, on regarde le résultat à l'écran. On cherche ce qu'on a demandé. On confirme que c'est là. Ensuite on continue.
Ce que cette session change
Avant cette première session, un projet dont je n'avais pas écrit le code était une boîte noire. Je pouvais l'utiliser, le montrer, en parler. Mais le modifier ? Hors de question. Je n'avais pas les clés.
Après, quelque chose a changé dans ma façon de regarder les fichiers sur mon écran.
Pas parce que j'ai appris à coder en une session. Je n'ai toujours pas appris à coder. Mais parce que j'ai compris deux choses.
D'abord, que créer un projet ne passe plus par l'écriture ligne à ligne. Ça passe par la formulation d'une intention dans une fenêtre de dialogue, et la validation des fichiers que Claude Code propose en retour.
Ensuite, que modifier un projet ne passe plus obligatoirement par la compréhension technique de chaque ligne. Ça passe par la capacité à lire une proposition et à décider si elle correspond à ce qu'on voulait.
Ce sont des compétences que j'ai. Que tu as probablement aussi.
Le fichier opaque n'a pas disparu. Il est toujours là, avec ses symboles et sa syntaxe que je ne lis pas couramment. Mais il est devenu quelque chose qu'on peut négocier. Un terrain de dialogue plutôt qu'une frontière.
C'est ça, le changement de posture. Pas la maîtrise technique. La capacité à entrer dans la conversation.