150 lines
6.9 KiB
Markdown
150 lines
6.9 KiB
Markdown
# Jour 1 — Ta première conversation avec Claude Code
|
|
|
|
[Retour au Jour 0 (configuration)](../day0/README.md)
|
|
|
|
---
|
|
|
|
Tu as installé Claude Code. Et maintenant ? Ce guide te présente trois niveaux d'utilisation — chacun te donne plus de contrôle sur **comment** Claude fait son travail.
|
|
|
|
Pense à ça comme à l'embauche de quelqu'un :
|
|
1. **Prompting** = demander ton chemin à un inconnu dans la rue
|
|
2. **Agents** = engager un spécialiste qui fait toujours les choses d'une certaine manière
|
|
3. **Skills** = ce spécialiste a reçu une formation spécifique pour des tâches précises
|
|
|
|
---
|
|
|
|
## Niveau 1 : Prompting (demande simplement)
|
|
|
|
> 🧠 **Pense à ça comme** envoyer un message à un ami qui sait beaucoup de choses. Tu demandes « quelle est la météo à Karachi ? » et il te donnera *une* réponse — mais tu ne sais pas s'il a consulté une app météo, regardé par la fenêtre ou deviné depuis sa mémoire.
|
|
|
|
Ouvre ton terminal et tape `claude`. Tu es maintenant dans une conversation. Essaie de taper :
|
|
|
|
```
|
|
what is the weather in Karachi?
|
|
```
|
|
|
|
Claude répondra — mais **comment** il répond est imprévisible. Il pourrait :
|
|
- S'appuyer sur ses données d'entraînement (qui peuvent être obsolètes)
|
|
- Chercher sur le web (si des outils web sont disponibles)
|
|
- Donner une réponse générale plutôt que des données temps réel
|
|
|
|
C'est parfaitement acceptable pour les questions rapides ! Mais si tu as besoin de **résultats cohérents et fiables**, le prompting seul ne suffit pas.
|
|
|
|
### Quand le prompting fonctionne très bien
|
|
|
|
- Poser des questions sur ta codebase (« que fait ce fichier ? »)
|
|
- Rédiger ou modifier des documents (« réécris cet email pour qu'il soit plus professionnel »)
|
|
- Brainstormer des idées (« donne-moi 5 objets pour cette campagne »)
|
|
- Expliquer des choses (« explique ce message d'erreur comme si je n'étais pas développeur »)
|
|
|
|
### La limite
|
|
|
|
Chaque fois que tu demandes « quelle est la météo ? », Claude peut récupérer les données différemment — ou ne pas récupérer de vraies données du tout. Rien ne garantit qu'il utilise deux fois la même source ou la même méthode.
|
|
|
|
---
|
|
|
|
## Niveau 2 : Agents (le spécialiste)
|
|
|
|
Un **agent** est Claude qui joue un rôle spécifique — comme attribuer un intitulé de poste.
|
|
|
|
> 🧠 **Pense à ça comme** une cuisine de restaurant. Sans agent, tu entres dans une cuisine au hasard et tu cries « fais-moi des pâtes ! » — la personne qui t'entend peut faire bouillir des nouilles instantanées ou préparer un menu italien en cinq services. Avec un agent, tu engages un **chef pasta** dont la fiche de poste dit : *« utilise toujours des ingrédients frais, cuis toujours al dente, présente toujours de la même façon. »* Maintenant tu sais exactement ce que tu obtiens, à chaque fois.
|
|
|
|
Voici la même idée appliquée à Claude :
|
|
|
|
> **Sans agent :** tu demandes à Claude « What's the weather in Dubai? »
|
|
> Il peut consulter ses données d'entraînement, chercher sur le web ou faire une meilleure estimation. Tu ne sais pas ce qu'il va faire.
|
|
>
|
|
> **Avec agent :** un `weather-agent` a une fiche de poste claire :
|
|
> *« Toujours consulter l'API Open-Meteo pour Dubaï. Toujours retourner la température dans un format précis. »*
|
|
> Même question, même approche, à chaque fois.
|
|
|
|
### Exemple réel depuis ce repo
|
|
|
|
Ce repo contient un `weather-agent` — son unique travail est de récupérer la température à Dubaï. Voici ce qui le distingue du simple prompting :
|
|
|
|
| | Prompting | Agent |
|
|
|---|---|---|
|
|
| **Source** | Pourrait être n'importe où | Toujours API Open-Meteo |
|
|
| **Lieu** | Ce que Claude choisit | Toujours Dubaï (lat: 25.2, lon: 55.3) |
|
|
| **Format** | Paragraphe aléatoire | Température + unité propres |
|
|
| **Cohérence** | Différent à chaque fois | Même méthode, à chaque fois |
|
|
|
|
### À retenir
|
|
|
|
Les agents te donnent de la **prédictibilité**. Même question → même approche → même qualité. C'est l'avantage — non pas que les agents soient plus intelligents, mais qu'ils soient **cohérents**.
|
|
|
|
---
|
|
|
|
## Niveau 3 : Skills (la formation)
|
|
|
|
Un **skill** est une capacité spécifique qu'un agent (ou Claude lui-même) peut utiliser.
|
|
|
|
> 🧠 **Pense à ça comme** le manuel de formation d'un nouvel employé. Quand quelqu'un rejoint ton équipe, il a un rôle (agent), mais il suit aussi des modules de formation spécifiques — comment utiliser le CRM, comment écrire une proposition, comment animer un standup. Chaque module de formation est un **skill**. Le rôle dit *ce qu'il est* ; les skills disent *comment* faire des choses précises.
|
|
|
|
Maintenant pense à une vraie personne :
|
|
|
|
> **Shayan** a beaucoup de skills :
|
|
> - Skill d'ingénierie — peut écrire du code
|
|
> - Skill de jeu — connaît les mécaniques de jeu
|
|
> - Skill de lecture — peut digérer et résumer de longs documents
|
|
>
|
|
> Chaque skill a ses propres connaissances et méthodes. Shayan utilise le bon skill pour la bonne tâche.
|
|
|
|
Claude fonctionne de la même façon. Le `weather-agent` a un skill appelé `weather-fetcher` :
|
|
|
|
- L'**agent** (`weather-agent`) = la personne avec l'intitulé "Weather Reporter"
|
|
- Le **skill** (`weather-fetcher`) = la formation spécifique sur *comment* récupérer des données météo
|
|
|
|
Le skill contient des instructions exactes :
|
|
1. Appeler cette URL d'API précise
|
|
2. Extraire la température depuis ce champ précis de la réponse
|
|
3. La retourner dans ce format précis
|
|
|
|
### Pourquoi séparer agents et skills ?
|
|
|
|
Parce qu'**un agent peut avoir plusieurs skills**, et **un skill peut être utilisé par plusieurs agents**.
|
|
|
|
Par exemple, imagine que tu crées :
|
|
- Un `daily-report-agent` qui résume ta journée
|
|
- Il pourrait utiliser un skill `weather-fetcher` (pour la météo) + un skill `calendar-reader` (pour les réunions) + un skill `email-summarizer` (pour les points clés des emails)
|
|
|
|
Les skills sont des briques réutilisables. Les agents sont les personnes qui les utilisent.
|
|
|
|
---
|
|
|
|
## Tout assembler
|
|
|
|
Voici l'image complète :
|
|
|
|
```
|
|
Niveau 1 : PROMPTING
|
|
Toi → "What's the weather?" → Claude trouve comme il peut
|
|
(méthode imprévisible)
|
|
|
|
Niveau 2 : AGENTS
|
|
Toi → Weather Agent → Utilise toujours la même approche
|
|
(méthode prévisible)
|
|
|
|
Niveau 3 : SKILLS
|
|
Toi → Weather Agent → Utilise le skill weather-fetcher
|
|
(méthode prévisible avec instructions spécifiques)
|
|
```
|
|
|
|
Chaque niveau ajoute plus de contrôle :
|
|
|
|
| Niveau | Ce que tu contrôles | Idéal pour |
|
|
|--------|---------------------|------------|
|
|
| **Prompting** | La question | Questions rapides et ponctuelles |
|
|
| **Agents** | La question + qui répond | Tâches répétables |
|
|
| **Skills** | La question + qui répond + comment il le fait | Workflows critiques |
|
|
|
|
---
|
|
|
|
## Et ensuite ?
|
|
|
|
Pour l'instant, passe du temps au **niveau 1** — prompt simplement. Habitue-toi à poser des questions à Claude dans le terminal. Plus tu l'utiliseras, plus tu remarqueras les tâches qui bénéficieraient d'un agent.
|
|
|
|
---
|
|
|
|
[Retour au Jour 0 (configuration)](../day0/README.md)
|