Claude Code est un agent IA qui travaille dans le terminal de ton ordinateur : tu décris en langage courant ce que tu veux, et il lit les fichiers de ton projet, propose des modifications et exécute des commandes. Pour démarrer, il te faut un ordinateur sous Windows, macOS ou Linux, quelques outils de base comme Node.js et Git, et l'habitude de vérifier toi-même chaque résultat.
Cet article explique ce que cela signifie concrètement, comment se déroule une session de travail avec l'agent et à quoi tu reconnais qu'un résultat tient la route.
Qu'est-ce que Claude Code, et en quoi est-ce différent d'un chat ?
Dans un chat IA ordinaire, tu reçois du texte en retour. Tu le copies, tu le colles quelque part et tu espères qu'il convienne. Un agent comme Claude Code, lui, travaille directement dans le dossier de ton projet. Il voit quels fichiers existent, lit le code en place et le modifie.
Le terminal, c'est simplement la fenêtre de texte dans laquelle tu tapes des commandes. Au début, il paraît déroutant parce qu'il n'y a pas de boutons. Tu tapes une ligne, tu appuies sur Entrée et tu lis la réponse. Rien de plus.
D'où le point le plus important pour les débutants : l'agent modifie de vrais fichiers. C'est pratique, parce que tu avances vite. Mais cela t'oblige aussi à garder une vue d'ensemble sur ce qui a changé et à quel moment. Codex joue un rôle similaire. La manière de travailler décrite ici vaut pour les deux outils.
De quoi as-tu besoin avant le premier lancement ?
Avant d'appeler l'agent pour la première fois, ton environnement doit être prêt. Cette liste couvre l'essentiel :
- Un portable ou un ordinateur de bureau sous Windows, macOS ou Linux. Une tablette ne suffit pas, car tu dois installer des programmes et travailler dans le terminal.
- L'autorisation d'installer des programmes. Sur les appareils d'entreprise, c'est souvent bloqué. Clarifie ce point à l'avance avec ton service informatique.
- Node.js, version 20 ou plus récente. Beaucoup de projets web en ont besoin pour lancer l'application en local et exécuter les tests.
- Git. Il te permet d'enregistrer des états intermédiaires et de voir quels fichiers l'agent a modifiés.
- Ton propre accès à Claude Code ou à Codex. Les conditions applicables figurent sur les pages officielles du fournisseur concerné.
- Un peu de patience avec l'anglais. Le code et beaucoup de messages des outils sont en anglais, même si tu rédiges tes consignes en français.
Pour l'installation, le plus simple est de suivre le guide officiel du fournisseur. Ensuite, tu vérifies dans le terminal que tout est reconnu : Node.js, Git et l'agent doivent chacun afficher leur version. Si tu préfères une aide pas à pas, la mission 0 sur l'installation des outils, en libre accès et rédigée en allemand, est un bon point de départ.
À quoi ressemble une session de travail avec Claude Code ?
Une session typique est courte et se répète. Plus elle est petite, plus il est facile de trouver une erreur quand quelque chose tourne mal.
- Ouvrir le dossier du projet. Tu lances le terminal dans le dossier où se trouve ton application.
- Sauvegarder l'état actuel. Avec Git, tu enregistres à quoi ressemblait le projet avant la modification.
- Formuler la consigne. Tu décris une seule modification, bien délimitée.
- Lire la proposition. Avant d'accepter, tu regardes quels fichiers l'agent veut toucher et pourquoi.
- Lancer l'application et l'essayer. Tu parcours toi-même la nouvelle fonction en cliquant.
- Exécuter les tests. Si ton projet en a, ils te montrent si autre chose a été cassé.
- Enregistrer et noter. Tu sauvegardes le nouvel état et tu notes brièvement ce que l'IA a apporté et ce que tu as ajusté toi-même.
La dernière étape paraît tatillonne, mais elle est payante. Sans elle, au bout d'une semaine, tu ne sais plus pourquoi une certaine ligne se trouve dans le code.
Comment donner une consigne claire à l'agent ?
L'erreur la plus fréquente au début, c'est une consigne trop vaste et trop vague. « Construis-moi un gestionnaire de contacts » laisse à l'agent d'innombrables décisions. Il les prend alors lui-même, et après coup tu ne comprends pas ce qui a été créé.
Mieux vaut découper une tâche en étapes vérifiables et dire, pour chacune, à quoi tu reconnais qu'elle est terminée. Ces phrases de contrôle s'appellent des cas d'acceptation. Elles suivent le plus souvent le schéma : si je fais ceci, alors il se passe cela.
Un exemple tiré d'une application de contacts
Imaginons que ton application affiche déjà une liste de contacts. Chaque contact doit maintenant recevoir un statut. Une consigne claire pourrait ressembler à ceci :
Ajoute à chaque contact un champ Statut avec les valeurs « nouveau », « contacté » et « terminé ». Les nouveaux contacts commencent avec « nouveau ». Dans la vue détaillée, je peux changer le statut. Ne modifie rien à la présentation de la liste.
Cas d'acceptation : si je crée un nouveau contact, son statut est « nouveau ». Si je passe le statut à « contacté » dans la vue détaillée et que je recharge la page, il reste « contacté ».
L'agent sait maintenant ce qu'il doit faire, où le faire et ce à quoi il ne doit pas toucher. Et toi, tu sais comment vérifier le résultat.
Ce qui fait une bonne consigne
- Objectif : que doit pouvoir faire ensuite la personne qui utilise l'application ?
- Emplacement : quelle vue ou quelle partie de l'application est concernée ?
- Limites : qu'est-ce qui ne doit pas être modifié ?
- Cas d'acceptation : deux ou trois phrases que tu peux tester toi-même.
- Cas d'erreur : que doit-il se passer si une saisie est vide ou invalide ?
Comment vérifier ce que l'agent a construit ?
Un agent formule souvent ses réponses comme si tout était réglé. Cela ne veut pas encore dire que c'est vrai. Vérifier n'est donc pas de la méfiance, c'est une partie du travail. Cette liste de contrôle t'aide après chaque session :
- L'application démarre-t-elle encore ? Cela paraît banal, mais c'est la surprise la plus fréquente.
- Les cas d'acceptation sont-ils remplis ? Teste-les toi-même au lieu de te fier au résumé de l'agent.
- Que se passe-t-il dans les cas d'erreur ? Crée un contact sans nom, saisis une adresse e-mail incomplète, fixe un follow-up à une date absurde.
- Comment l'application réagit-elle à une interface externe ? Si des données viennent de l'extérieur, teste une réponse vide, un message d'erreur et un long temps d'attente. Avec une interface simulée, tu peux le faire sans risque.
- Y a-t-il des secrets dans le code ? Les clés d'accès et les mots de passe n'ont rien à faire dans des fichiers que tu partages.
- Des fichiers étrangers à la tâche ont-ils été modifiés ? Git te montre quels fichiers ont changé depuis le dernier état sauvegardé. Est-ce cohérent avec la consigne ?
- Peux-tu expliquer la modification ? Si tu arrives à dire en deux phrases ce qui est nouveau et pourquoi, tu as gardé le contrôle.
Si quelque chose tourne mal, tu reviens au dernier état sauvegardé et tu reformules la consigne de façon plus précise. C'est souvent plus rapide que de laisser l'agent corriger le tir en plusieurs sessions.
Quels sont les pièges de la première fois ?
Certains problèmes surgissent chez presque tous les débutants. Les connaître t'évite bien des frustrations.
Des messages d'erreur en anglais. Tu peux transmettre un message à l'agent et lui demander une explication. Lis-le quand même toi-même, car la cause se trouve souvent sur la première ou la dernière ligne.
Plusieurs modifications à la fois. Si tu demandes un filtre, un changement de statut et un export dans une seule consigne, il devient presque impossible d'attribuer une erreur à une cause. Une modification par session, c'est la règle la plus simple.
Les tests sont modifiés au lieu du code. Il peut arriver qu'un agent réécrive un test qui échoue pour qu'il passe. Sois donc attentif quand des fichiers de test changent alors que tu voulais seulement corriger une fonction.
Des données réelles dans le projet d'apprentissage. Pour les premiers essais, des données d'exemple suffisent. Une application qui enregistre ses données dans le navigateur n'est pas prévue pour de vraies données de clients.
Comment le cours Vibe Coding Foundation s'inscrit-il dans tes débuts ?
Le cours Vibe Coding Foundation de BUILT IN CLASS entraîne exactement cette manière de travailler sur un projet suivi du début à la fin : une application de contacts et de follow-up pour une petite entreprise, avec des données d'exemple. Tu travailles avec Claude Code ou Codex et tu as besoin pour cela de ton propre accès, dont les coûts s'ajoutent au prix du cours.
Les missions s'enchaînent. Après l'installation, tu transformes une idée en consigne claire, tu construis la liste de contacts et la vue détaillée, tu ajoutes la validation des saisies, le changement de statut et les filtres, puis tu relies l'application à une interface simulée qui renvoie des réponses vides, des erreurs et des temps d'attente. Ensuite, tu circonscris des erreurs préparées à l'avance, tu vérifies des cas d'accès de base et tu documentes ton projet pour que d'autres puissent le lancer. Dans la mission de transfert, tu exportes les follow-ups en retard dans un fichier CSV. Toutes les missions avec leur durée prévue figurent dans l'aperçu du cours.
Chaque mission comporte des critères sous forme de tests, que tu vérifies sur ton ordinateur avec une seule commande, ainsi que des indices sur trois niveaux. Le journal IA, qui apparaît dans cet article comme dernière étape de chaque session, tu le tiens tout au long du cours. La durée prévue est d'environ 30 heures, par exemple six semaines à raison d'environ cinq heures par semaine. Le déroulement de l'examen de projet écrit est décrit sur la page consacrée à l'examen. Si tu le réussis, tu obtiens un certificat privé de l'académie, pas un diplôme d'État. Le prix et les prestations sont indiqués sous Prix.