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 dans le navigateur. 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'écran.

Et surtout, en le créant nous-mêmes, on comprend tout de suite quelque chose d'important : Claude Code voit exactement ce que je vois dans Cursor. 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.

Ouvrir Cursor pour la première fois

Quand tu lances Cursor, une fenêtre "New Agent" s'ouvre par défaut. Ferme-la. On n'en a pas besoin pour l'instant, et la garder ouverte va juste ajouter du bruit visuel.

Une fois cette fenêtre fermée, tu te retrouves face à ce qui ressemble à un éditeur de texte classique. C'est normal. Cursor, fondamentalement, c'est ça : un éditeur de texte augmenté.

Créer un dossier pour le projet

Va dans le menu File → Open Folder. Crée un nouveau dossier sur ton bureau (ou ailleurs si tu préfères, du moment que tu sauras le retrouver), appelle-le generateur-de-citations, et ouvre-le dans Cursor.

À gauche de l'écran, tu vois maintenant ton dossier. Vide. Pas un fichier dedans. C'est exactement ce qu'on veut.

Ouvrir le terminal

En bas de la fenêtre, on va ouvrir un terminal. Dans le menu : Terminal → New Terminal. Une fenêtre noire avec un curseur qui clignote apparaît en bas de Cursor.

Cette fenêtre noire a une réputation. Elle évoque les films où un personnage tape furieusement sur un clavier et fait tomber des serveurs. Pour l'instant, on va juste y taper un mot.

Tape claude et appuie sur Entrée.

Claude Code démarre. Tu vois apparaître une fenêtre de dialogue, un peu comme un chat. C'est là qu'on va parler.

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 web autoportant qui affiche une citation aléatoire à chaque rechargement de la page. Stack minimale : HTML, CSS, JavaScript vanilla. Pas de framework, pas de build, pas de dépendances. Le projet doit fonctionner via un petit serveur local Python (python -m http.server). 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.

Dans le terminal en bas (le même que tout à l'heure, ou un nouveau si tu préfères), tape :

python -m http.server

Si tu n'as jamais ouvert un terminal de ta vie, cette étape peut sembler intimidante. Elle l'est un peu, la première fois. Mais tu n'as rien à inventer : tu copies la commande, tu appuies sur Entrée.

Le terminal te dit qu'un petit serveur est lancé sur ta machine, à une adresse qui ressemble à http://localhost:8000. Ouvre cette adresse dans ton navigateur.

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, retourne dans Claude Code et dis-le-lui simplement. "Quand je lance le serveur et j'ouvre la page, 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.

La première fois que j'ai vu ça, j'ai eu un moment de surprise. Pas parce que c'était compliqué. Parce que c'était lisible. 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.

C'est le moment où j'ai réalisé que 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. Cursor met à jour le code, le fichier est modifié, et si je rafraîchis la page dans mon navigateur, 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. Cursor 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 retourne dans le navigateur, je rafraîchis la page (le serveur tourne toujours en arrière-plan dans le terminal, on ne l'a pas arrêté). 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.