Onze idées, une par écran. C'est la couche sur laquelle reposent Claude Code et toutes les autres applications. Chaque slide est un point d'appui pendant que vous expliquez : prenez les silences.
Quatre mouvements : faire l'appel, le rendre fiable, étendre sa portée, puis composer les pièces en systèmes.
Vous envoyez un modèle, une ligne système facultative, et toute la liste des messages. Elle répond une fois. Aucune mémoire : pour continuer, vous ajoutez la réponse et vous renvoyez le tout.
Une « conversation multi-tours » n'est que cette boucle faite à la main : le modèle ne retient rien entre deux appels, donc la liste messages[] qui s'allonge est la mémoire. Même clé, même structure, quel que soit le langage d'appel.
Concept cléRequête minimale = model + messages + max_tokens dans le corps, clé API dans les en-têtes. Gardez la clé dans une variable d'environnement / .env, jamais en dur. → notes formateur (dont web-app : la clé reste côté serveur).
On ne change pas de modèle pour changer le comportement. On tourne ces boutons.
Le system prompt fait le gros du travail : c'est là que vivent le rôle et les règles. La température échange la fiabilité contre la variété ; le streaming, c'est une question de ressenti ; la sortie structurée, c'est ainsi qu'on obtient des données qu'un programme peut vraiment utiliser.
Notion cléPour du JSON propre, sans prose à retirer, utilisez l'usage d'outil forcé (tool_choice) : définissez un outil dont le schéma est la forme voulue, puis relisez l'objet validé. → notes du formateur (préremplissage + séquences d'arrêt : l'alternative plus légère, pour du JSON plat).
Une eval, c'est une suite de tests pour vos prompts : un jeu de cas, exécuté automatiquement, noté, chiffré. Vous changez le prompt, vous relancez, vous regardez le chiffre bouger.
Deux façons de noter : par code pour tout ce qui est exact (est-ce du JSON valide ? contient-il la réponse ?), par modèle pour le jugement (est-ce diplomate ? est-ce dans le sujet ?) : vous demandez à un autre appel Claude de le noter selon une grille.
Concept cléLa boucle d'éval : construire des cas de test → Claude génère des réponses → les noter → score → affiner et relancer. L'étape après la génération, c'est la notation ; la notation par modèle utilise une autre IA pour juger. → notes du formateur.
Qu'est-ce qu'un « correcteur modèle » ? La moitié « par modèle » : un autre appel Claude qui note une sortie selon une grille. La solution quand « juste » relève du jugement (ton, pertinence, utilité), ce que le code ne peut pas vérifier exactement.
Jusqu'où lui faire confiance ? Écrivez une grille claire, faites-lui rendre une justification d'une ligne avec la note, et comparez-la à des notes humaines sur un échantillon avant de vous y fier sur des centaines de cas.
Quand le résultat est mauvais, il faut rarement un modèle plus puissant. Il faut un prompt plus clair. Utilisez ces leviers dans cet ordre.
Ce sont les exemples (few-shot) qui font le plus bouger la qualité : deux ou trois paires entrée→sortie traitées enseignent le format et les cas limites que des paragraphes de consignes n'atteignent pas. Les balises XML comptent parce que Claude est entraîné à les respecter : <document>…</document> se lit mieux que des guillemets.
Claude ne peut rien exécuter. Il peut seulement demander. Vous décrivez les outils ; il répond « appelle ceci, avec ces arguments » ; vous l'exécutez et lui rendez le résultat ; il continue.
La boucle peut se répéter : Claude peut appeler plusieurs tools sur plusieurs tours avant de répondre. C'est ce seul mécanisme qui sert de base à tous les agents : le modèle propose, votre environnement exécute, le résultat revient.
Donc un tool, c'est un endpoint Anthropic particulier ? Non. Il n'y a qu'un seul endpoint Messages. Un tool est une simple fonction dans votre propre code; Claude renvoie seulement une demande d'appel (nom + arguments) et attend votre résultat.
Est-ce un fichier de configuration qui règle le comportement de Claude ? Non. Un tool, c'est votre code, plus une déclaration (nom, description, schéma d'entrée) qui indique à Claude que la fonction est disponible , pas comment il doit se comporter.
La plupart des tools, c'est à vous de les implémenter. Quelques-uns sont livrés avec l'API : vous les activez et Anthropic les exécute côté serveur.
L'éditeur de texte et l'exécution de code sont exactement ce qui fait tourner Claude Code et les fonctions d'analyse. L'API Files permet à une requête de référencer des fichiers déjà envoyés (PDF, jeux de données) sans les renvoyer à chaque appel.
Notion cléLa limite principale de l'outil d'exécution de code : il exécute du Python dans un bac à sable isolé, sans accès réseau. L'API Files, c'est le stockage « on envoie une fois, on référence autant qu'on veut » qui fait aussi entrer les données et ressortir les résultats (graphiques). → notes du formateur.
Une base de connaissances entière ne tient pas dans un prompt. On l'indexe donc une fois, puis on ne récupère que les quelques passages utiles à chaque question et on les insère.
Les embeddings captent le sens (« voiture » trouve « véhicule ») ; BM25 capte les termes exacts (un code d'erreur, une référence pièce). Un pipeline multi-index fait tourner les deux et fusionne les résultats : c'est ce que fait un vrai RAG en production.
Quatre capacités s'ajoutent à la requête que vous connaissez déjà : deux changent ce qui entre, deux changent ce qui sort.
Le raisonnement étendu donne au modèle la place de traiter les problèmes difficiles avant de s'engager sur une réponse. Les citations transforment le « croyez-moi » en « voici le passage » : la colonne vertébrale de toute réponse qu'une entreprise doit assumer.
Notion cléPDF ou image : un PDF est lu comme texte et images (un bloc document , compatible avec les citations) ; une image passe par la vision seule. Le PDF coûte plus cher à la page, mais donne une compréhension plus riche et citable. → notes du formateur.
La plupart des prompts commencent par le même gros bloc : un system prompt, des définitions d'outils, un document. Mettez ce préfixe en cache et les appels suivants le lisent au lieu de le repayer.
La règle : seul un préfixe exact et inchangé est réutilisé. Mettez donc tout ce qui est stable en premier et la partie variable en dernier. La durée de vie du cache est courte (quelques minutes) : le gain se fait sur une série d'appels rapprochés, le cœur de toute application réactive à contexte répété.
Concept cléLe cache demande deux choses : marquer le bloc cache_control: ephemeral et atteindre la longueur minimale (~1 024 tokens sur Sonnet 4.x, ~4 096 sur Opus 4.5+). En dessous du minimum, l'appel passe sans cache, sans erreur. → notes du formateur.
Sans lui, chaque application câble chaque intégration à la main. Avec lui, un serveur expose ses capacités une fois et n'importe quel client s'y connecte.
Un serveur publie trois choses (tools, resources, prompts) et l'inspecteur vous permet de le tester avant de le brancher à un client. Vous construisez l'intégration une fois ; vous la branchez à Claude Code, à votre propre client, ou à celui de n'importe qui d'autre.
Exposer le contenu de documents ? C'est une resource : des données en lecture seule que Claude peut récupérer. Les actions qu'il effectue sont des tools ; les instructions pré-testées (un formateur, par exemple) sont des prompts.
Définir un tool en Python ? Le plus simple, c'est le décorateur @mcp.tool() (FastMCP). Le nom de la fonction, sa docstring et ses annotations de type deviennent le tool : aucun schéma à écrire à la main.
Comment client et serveur se parlent-ils en
développement ? Presque toujours en stdio : le client lance le serveur comme sous-processus via stdin/stdout. Pas de ports, pas d'authentification. HTTP, c'est pour le distant.
Pourquoi trois primitives, et pas une seule ? Des propriétaires différents. Le modèle choisit les outils, l' application charge les ressources, l' utilisateur invoque les prompts. Chacun est donc proposé de la bonne façon.
Les deux enchaînent des appels au LLM. La différence, c'est le contrôle : dans un workflow, vous câblez les étapes ; dans un agent, le modèle les choisit au fur et à mesure.
Choisissez selon la prévisibilité. Si vous pouvez dessiner les étapes à l'avance, un workflow coûte moins cher et reste plus fiable. Si le chemin dépend de ce que l'on trouve en route, il vous faut un agent ; Claude Code en est un. La plupart des systèmes en production mélangent les deux.
Vous voulez qu'il gère l'imprévu ? Donnez à l'agent quelques outils généraux et laissez-le choisir, pas un outil étroit par cas que vous aviez prévu. Les outils généraux se recombinent en chemins que vous n'avez jamais écrits.
Un long prompt qu'il n'applique qu'à moitié ? Enchaînez -le. Répartissez les règles sur quelques petites étapes, pour que chaque appel en porte moins, et vérifiez le résultat entre chacune.
L'unité, c'est une requête sans mémoire. Les évaluations et le prompting la rendent fiable ; les outils, le RAG et les capacités propres du modèle lui donnent de la portée ; MCP et le choix entre workflow et agent, c'est ainsi que vous construisez quelque chose de réel.
tutto.one/praxis · daniel@tutto.one