Glossaire ia : llm, tokens, prompt, outils et agents expliqués

À la base, il y a le LLM

LLM signifie « Large Language Model », ce qui se traduit en français par « grand modèle linguistique », ou simplement « grand modèle ». À l’heure actuelle, pratiquement tous les grands modèles sont entraînés à partir de l’architecture Transformer.

Cette architecture semble complexe, mais ne vous inquiétez pas : il est tout à fait normal que vous ne compreniez pas ce schéma pour l’instant, et nous n’avons pas l’intention de l’étudier aujourd’hui. Il vous suffit de savoir que c’est le moteur sous-jacent des grands modèles.

L’architecture Transformer a en fait été proposée pour la première fois par l’équipe de Google en 2017, dans un article intitulé Attention Is All You Need.

Vous vous souvenez sans doute tous de la fin de l’année 2022, lorsque GPT 3.5 a fait une entrée fracassante. Il s’agit sans doute du premier grand modèle à avoir véritablement atteint un niveau d’utilisabilité. Je suis sûr que ceux qui l’ont utilisé à l’époque ont pu constater sa puissance. Mais ce n’était pas tout : quelques mois plus tard seulement, en mars 2023, GPT 4 a été lancé, repoussant d’un coup le plafond des capacités de l’IA à un nouveau niveau.

Même aujourd’hui, la famille GPT reste très puissante ; par exemple, le GPT-5.4 actuel est l’une des références du secteur. Mais le domaine de l’IA n’est plus depuis longtemps le monopole d’OpenAI. D’excellents nouveaux venus, tels que Claude et Gemini, rivalisent avec lui dans leurs domaines de prédilection respectifs.

L’enchaînement des mots : prédiction et probabilités

Nous avons évoqué précédemment l’origine générale des grands modèles, mais comment fonctionnent-ils réellement ? En réalité, c’est très simple : il s’agit essentiellement d’une logique de chaînage de mots.

Prenons un exemple concret : supposons que vous posiez une question au grand modèle en lui demandant ce qu’il pense de cet article. Une fois cette phrase reçue, après une série de calculs internes, le modèle prédit le mot suivant ayant la probabilité la plus élevée, par exemple « particulièrement ».

C’est là que réside le point crucial : après avoir généré le mot « particulièrement », le modèle ne s’arrête pas. Il récupère ce mot qu’il vient de générer et l’ajoute à la fin de votre entrée initiale. Il utilise ensuite cette nouvelle entrée pour prédire le mot suivant, par exemple « intéressant ».

Il réinsère ensuite ce mot dans l’entrée, puis prédit le mot suivant, par exemple « et ». Il réinsère alors également ce mot dans l’entrée. À ce moment-là, le grand modèle se rend compte qu’il a déjà dit tout ce qu’il avait à dire.

Il émet alors un marqueur de fin spécial, et la réponse est ainsi définitivement terminée. Nous obtenons ainsi la réponse complète du grand modèle. C’est là le principe de génération fondamental du grand modèle.

Au-delà des mots : la mécanique interne

Comme je l’ai mentionné précédemment, lorsque l’utilisateur soumet une question au grand modèle, celui-ci génère un mot à la fois, mais il s’agit en réalité d’une simplification destinée à faciliter votre compréhension. En réalité, le grand modèle est essentiellement une fonction mathématique gigantesque qui effectue exclusivement des opérations matricielles.

Il est chargé de deux tâches : l’encodage et le décodage. L’encodage consiste à transformer les caractères en chiffres, tandis que le décodage consiste à reconstituer les caractères à partir des chiffres.

Le processus d’encodage

Reprenons l’exemple précédent : un utilisateur demande « Que pensez-vous de cet article » ? Cette phrase est d’abord transmise au Tokenizer, qui doit convertir ces caractères en chiffres. C’est là que le processus d’encodage entre en jeu.

Décomposons le processus d’encodage pour l’examiner de plus près et comprendre comment il transforme exactement le texte en chiffres. Ce processus se déroule en deux étapes :

• Première étape : le découpage. Il prend la question de l’utilisateur et la décompose en fragments les plus petits possibles, appelés « tokens ».
• Deuxième étape : le mappage. Comme le modèle ne reconnaît que les chiffres, le tokenizer associe chaque token à un chiffre, appelé « token ID ». L’identifiant de token et le token sont liés de manière biunivoque : le token est du texte, l’identifiant de token est un chiffre.

Ces deux éléments ont en réalité la même signification, mais sont simplement exprimés différemment.

Au terme de ces deux étapes, la phrase d’origine se transforme en une liste composée d’une série d’identifiants de tokens. Le tokenizer transmet ensuite cette liste au modèle, qui effectue une série de calculs en interne avant de générer un identifiant de token.

Étape de décodage

C’est à ce moment-là que le Tokenizer entre à nouveau en scène pour traduire ce Token ID en Token : c’est le travail de l’étape de décodage. Le décodage ne comporte qu’une seule étape, à savoir le mappage, dont la direction est inverse à celle du codage : il s’agit de convertir les chiffres en texte.

L’étape de décodage ne nécessite pas de segmentation, car le modèle ne fournit qu’un seul Token à la fois, il n’y a donc rien à segmenter. Une fois le décodage terminé, nous obtenons le premier token généré par le grand modèle.

Si le modèle n’a pas encore fini, il génère un deuxième, puis un troisième token. Le processus qui suit est en fait identique, je ne le répéterai donc pas ici.

Les tokens et les mots ne sont pas en correspondance biunivoque

Revenons maintenant à l’exemple précédent : « Que penses-tu de l’article ? ». Il pourrait être segmenté en plusieurs tokens. Avez-vous remarqué que chaque token semble correspondre exactement à un mot ?

Vous pourriez donc penser : « Un token, c’est un mot, n’est-ce pas ? » Mais ce n’est pas forcément le cas. Il n’y a pas de correspondance biunivoque entre les tokens et les mots ; l’exemple précédent n’était qu’une coïncidence. Par exemple, le mot « helpful » est divisé en deux tokens : « help » et « ful ». Dans certains cas, un caractère peut même être divisé en plusieurs tokens. Prenons le caractère « ✓ » : il faut trois tokens pour le représenter.

• Résumons donc : il n’y a pas de correspondance biunivoque claire entre les mots et les tokens.
• Vous pouvez considérer les tokens comme un ensemble de règles de segmentation de texte que le modèle a lui-même apprises ; chaque segment ainsi créé correspond à la plus petite unité qu’il est capable de traiter à la fois.
• En moyenne, un token équivaut environ à 0,75 mot anglais, ou à 1,5 à 2 caractères dans des langues comme le chinois. Par exemple, 400 000 tokens correspondent à environ 600 000 à 800 000 caractères chinois, ou 300 000 mots anglais.

Mémoire et contexte : comment l’IA se souvient

Cela nous amène au concept de « Contexte »

Il représente l’ensemble des informations reçues par le grand modèle à chaque fois qu’il traite une tâche. Comme nous venons de le mentionner, la question de l’utilisateur et l’historique de la conversation font partie des messages reçus par le grand modèle ; ils font tous deux partie du Contexte.

Le « Contexte » contient bien d’autres informations. Par exemple, chaque token généré par le grand modèle est ajouté à cet ensemble. Il comprend également la liste des outils, le « System Prompt » et d’autres informations. Nous aborderons ces concepts un par un plus tard ; pour l’instant, vous n’avez pas besoin de vous en préoccuper.

Pour l’instant, retenez simplement ceci : le contexte correspond à l’ensemble des informations reçues par le grand modèle à chaque fois qu’il traite une tâche. D’une certaine manière, on peut le considérer comme une mémoire temporaire du grand modèle.

Bon, je pense que vous avez désormais une première idée de ce qu’est le contexte. Je vais maintenant vous poser une question : imaginez que vous disposiez d’un manuel de produits de plusieurs milliers de pages et que vous souhaitiez qu’un grand modèle réponde aux diverses questions des utilisateurs à partir de ce manuel.

L’art du Prompt : s’adresser à la machine

En français, « prompt » désigne l’instruction ou la question spécifique que reçoit le grand modèle. Par exemple, si vous demandez au grand modèle de vous écrire un poème, cette phrase est un « prompt ».

Exactement, ne considérez pas le « prompt » comme quelque chose de particulièrement complexe ou sophistiqué ; il s’agit simplement d’une question ou d’une instruction donnée au grand modèle. Ce n’est qu’après avoir reçu cette entrée que le grand modèle se met en marche et vous fournit une réponse correspondante.

Le souci, c’est que si vous vous contentez de dire simplement « Écris-moi un poème », le grand modèle pourrait vous proposer un poème classique, comme celui affiché à l’écran, mais il pourrait aussi vous proposer un poème moderne, voire un poème humoristique. Pourquoi ? Parce que votre « prompt » est trop vague : il ne sait pas exactement ce que vous voulez.

La manière dont vous rédigez votre prompt détermine donc directement la qualité du résultat produit par le grand modèle. Un bon prompt doit être clair, concret et précis. Vous pouvez par exemple écrire : « Aidez-moi à écrire un quatrain de cinq caractères sur le thème des feuilles mortes en automne, dans un style un peu mélancolique. » De cette façon, le grand modèle aura une vision beaucoup plus claire et le contenu qu’il générera correspondra davantage à vos attentes.

C’est pourquoi il existe un domaine spécifique appelé « Prompt Engineering », c’est-à-dire l’ingénierie des prompts. En clair, il s’agit d’étudier comment s’exprimer clairement afin que le grand modèle comprenne plus précisément votre intention.

Indiquer au grand modèle la tâche spécifique à accomplir

A ce stade, les concepts de base du « prompt » sont clairs, mais ce n’est pas tout. Mais parfois, nous devons non seulement indiquer au grand modèle la tâche spécifique à traiter, mais aussi lui définir son profil et ses règles de fonctionnement. Il s’agit de lui préciser qui il est et selon quelles règles il doit agir.

Cela nous amène donc à distinguer 2 types de prompts. Le « User Prompt » (prompt utilisateur), en français « prompt utilisateur », décrit la tâche spécifique et est saisi par l’utilisateur lui-même. Le « System Prompt » (prompt système), en français « prompt système », définit le profil et les règles de fonctionnement, et est configuré par le développeur en arrière-plan.

Prenons un exemple concret pour expliquer ces deux concepts. Imaginons que vous souhaitiez créer un robot de soutien scolaire en mathématiques. Vous souhaitez qu’il ne donne pas directement la réponse aux élèves, mais qu’il les guide dans leur réflexion. Dans ce cas, vous aurez besoin de deux types de prompts.

Le premier est le System Prompt, que vous configurez en arrière-plan comme suit : « Vous êtes un professeur de mathématiques patient. Lorsque les élèves vous posent des questions de mathématiques, ne donnez pas directement la réponse, mais guidez-les pas à pas dans leur réflexion pour les aider à comprendre la démarche de résolution. » Notez que ce texte est défini par vous, le développeur, en arrière-plan ; l’utilisateur ne le voit pas, mais il influence en permanence le comportement du grand modèle.

Ensuite, l’élève saisit dans la fenêtre de dialogue : « 3 plus 5, ça fait combien ? ». Il s’agit là du deuxième type de prompt, le « User Prompt » : la question que l’utilisateur saisit directement dans la fenêtre de dialogue.

Après avoir vu ces deux prompts, le grand modèle se dira : « Mon rôle est celui d’un professeur de mathématiques, je dois guider l’élève dans sa réflexion, je ne peux pas lui donner directement la réponse. Très bien, je vais donc répondre ainsi : « On peut voir les choses comme ça : tu as 3 pommes dans la main, puis tu en prends 5 autres. Combien en as-tu maintenant ? Tu peux les compter. »

Je pense que vous comprenez désormais la différence entre User Prompt et System Prompt. Grâce à leur combinaison, le grand modèle peut à la fois respecter les règles et répondre à vos besoins spécifiques.

Les outils : ouvrir l’IA sur le monde

Bon, nous en avons terminé avec les prompts. Passons maintenant au concept suivant : l’outil. Commençons par aborder une faiblesse des grands modèles : leur incapacité à percevoir l’environnement extérieur. Je vais vous donner un exemple.

Supposons que vous demandiez au grand modèle : « Quel temps fait-il aujourd’hui à Paris ? » Il pourrait répondre : « Désolé, je ne peux pas obtenir d’informations météorologiques en temps réel. Ma base de connaissances s’arrête à une certaine année et un certain mois, je ne peux donc pas fournir les données météorologiques du jour. »

Pourquoi ? Parce qu’un grand modèle n’est qu’un jeu de chaînage de mots : sa capacité consiste à prédire le mot suivant à partir des données d’entraînement, mais il n’a vraiment aucun moyen de consulter un site de prévisions météo pour obtenir des données météorologiques en temps réel. Que faire alors ? C’est là qu’intervient le « Tool ».

« Tool » se traduit par « outil ». Le mot « outil » n’est pas très facile à comprendre, alors remplaçons-le par un autre terme : « fonction ». Oui, c’est exact, un « Tool » est essentiellement une fonction : vous lui fournissez une entrée, et il vous donne une sortie.

Prenons l’exemple d’un outil de consultation météo : son entrée peut comporter deux paramètres, à savoir la ville et la date. Une fois ces données transmises, il effectue une série d’opérations en interne, par exemple en appelant l’interface du service météorologique. Quoi qu’il en soit, il vous fournit finalement un résultat qui vous indique les informations météorologiques correspondantes. Grâce à lui, le grand modèle peut répondre à des questions liées à la météo.

Le processus complet, de la question de l’utilisateur à la réponse du grand modèle

Voyons maintenant le processus complet, de la question de l’utilisateur à la réponse du grand modèle.

Les acteurs impliqués dans ce processus sont l’utilisateur, le grand modèle, l’outil de consultation météo et la plateforme. Vous vous demandez peut-être ce qu’est la plateforme : vous pouvez la considérer comme un relais.

Comme l’utilisateur, le grand modèle et l’outil de consultation météo ne peuvent pas communiquer directement entre eux, nous avons besoin de la plateforme pour assurer la transmission des informations. Il s’agit essentiellement d’un bout de code chargé de transmettre les informations. Vous êtes peut-être encore un peu perdu, mais ce n’est pas grave. Si vous ne comprenez pas tout maintenant, vous comprendrez après avoir lu le processus.

Au début du processus, la question de l’utilisateur est d’abord envoyée à la plateforme, qui la transmet ensuite au grand modèle. Cependant, ce n’est pas seulement la question de l’utilisateur qui est envoyée au grand modèle, mais aussi la liste des outils actuellement disponibles, tels que l’outil de consultation météo, la calculatrice, etc.

Une fois la question reçue, le grand modèle l’analyse : l’utilisateur souhaite connaître la météo, mais je ne dispose pas de données météorologiques en temps réel ; cependant, il existe un outil de consultation météo que je peux utiliser. Très bien, je vais donc faire appel à cet outil.

Une fois cette instruction reçue, la plateforme appelle réellement l’outil, ce qui revient en fait à appeler la fonction correspondante derrière cet outil. Une fois l’appel terminé, la plateforme récupère les informations météo correspondantes, qui ressemblent à peu près à ceci.

Une fois que la plateforme a obtenu le résultat de l’appel de l’outil, elle renvoie ces informations au grand modèle. Après avoir reçu ce résultat, le grand modèle le reformule en une phrase en langage naturel qu’il renvoie à la plateforme, par exemple : « Aujourd’hui, à Paris , le temps est beau, avec un ciel dégagé et des températures comprises entre 15 et 25 degrés », etc. La plateforme transmet ensuite cette phrase à l’utilisateur, qui peut ainsi consulter le résultat.

On constate que dans ce processus, chaque acteur a ses propres responsabilités

• Le grand modèle a deux rôles : le premier consiste à sélectionner les outils, c’est-à-dire à choisir les outils à appeler et à générer les paramètres correspondants.
• Le second est de synthétiser les résultats, c’est-à-dire qu’après avoir reçu les résultats d’exécution des outils, le modèle doit les synthétiser.

Le rôle de l’outil est d’effectuer la requête météo. Quant à la plateforme, elle est chargée de coordonner l’ensemble du processus, par exemple en indiquant au modèle quels outils sont disponibles, en appelant les outils selon les instructions du modèle, etc.

Ce que fait chaque rôle

Certains pourraient penser que c’est le modèle qui appelle les outils, et les débutants ont particulièrement tendance à le croire. Mais le modèle ne peut que générer un texte indiquant à la plateforme quel outil il souhaite appeler ; c’est finalement à la plateforme qu’il revient d’effectuer l’appel.

Pour résumer, l’essence même d’un Tool consiste à fournir au grand modèle un ensemble de capacités externes qu’il peut appeler, lui permettant ainsi de percevoir et d’influencer l’environnement externe.

Le MCP : un standard pour l’intégration

Bon, nous en avons terminé avec le concept de Tool. Passons maintenant au concept suivant : le MCP.

Nous venons d’évoquer le processus complet d’utilisation des outils, mais il y a là un problème technique majeur. Regardez ces deux points : premièrement, la plateforme doit transmettre la liste des outils au modèle ; deuxièmement, elle doit être capable d’appeler les outils.

Pour y parvenir, nous devons d’abord intégrer les outils à la plateforme, afin que celle-ci connaisse la liste des outils disponibles, ainsi que l’utilité, les paramètres et la méthode d’appel de chaque outil, etc. Mais voilà le problème : les spécifications d’intégration varient d’une plateforme à l’autre.

⇒ A lire sur notre blog : Alors que le MCP semblait s’imposer comme le standard universel, une tendance silencieuse bouleverse les développeurs : le retour aux CLI

1. Si vous utilisez ChatGPT, vous devez intégrer les outils selon les spécifications d’OpenAI et écrire un ensemble de code d’intégration.
2. Si vous utilisez Claude, vous devez suivre les spécifications d’Anthropic pour l’intégration, puis écrire un autre code d’intégration.
3. Si vous utilisez Gemini, vous devez suivre les spécifications de Google pour l’intégration, puis en écrire un autre.

C’est ainsi qu’est né le MCP

Le MCP est cette norme d’intégration unifiée. Son nom complet est Model Context Protocol, ce qui signifie « protocole de contexte de modèle ». Ce nom est un peu technique et difficile à comprendre, mais vous pouvez simplement le considérer comme une norme d’intégration unifiée pour les outils.

Grâce au MCP, les développeurs d’outils n’ont plus qu’à développer leur outil une seule fois selon les spécifications du MCP pour que celui-ci puisse être utilisé sur toutes les plateformes prenant en charge le MCP. C’est un peu comme si tous les téléphones utilisaient une prise Type-C : une norme unifiée facilite grandement la vie de tout le monde.

L’Agent : vers une autonomie réelle

Nous savons désormais que les grands modèles peuvent percevoir le monde extérieur à l’aide d’outils, et que ces outils peuvent utiliser le MCP pour une connexion unifiée. En théorie, avec ces deux éléments, les grands modèles devraient être très puissants, mais en réalité, il manque encore un petit quelque chose.

Essayons par exemple de demander au grand modèle de résoudre un problème plus complexe : quel temps fait-il aujourd’hui chez moi ? S’il pleut, aide-moi à trouver un magasin vendant des parapluies à proximité.

Supposons que les outils suivants soient disponibles : tout d’abord, un outil de localisation, chargé de déterminer les coordonnées géographiques de l’utilisateur ; ensuite, un outil météo, qui sert à récupérer les informations météorologiques en fonction des coordonnées ; et enfin, un outil de recherche de magasins, qui permet de trouver les commerces à proximité à partir des coordonnées.

Je pense que certains d’entre vous l’ont déjà compris : pour résoudre ce problème, nous devons faire appel à plusieurs outils. Du point de vue du grand modèle, le processus devrait se dérouler ainsi :

Tout d’abord, le grand modèle réfléchit : l’utilisateur demande la météo, donc pour obtenir ces informations, il faut forcément connaître sa position actuelle. Il se trouve justement qu’il y a un outil de localisation, je vais demander à l’utiliser. Le grand modèle envoie alors une instruction d’appel d’outil à la plateforme pour qu’elle utilise l’outil de localisation et récupère les coordonnées géographiques de l’utilisateur.

Après avoir utilisé l’outil, la plateforme renvoie le résultat : La longitude est de -74° et la latitude de 40°. Le modèle réfléchit à nouveau : « Bon, j’ai la position. L’étape suivante consiste à consulter la météo pour cet endroit. Voyons voir… Ah, il y a un outil météo disponible, je vais l’appeler. » Le grand modèle envoie à nouveau une instruction à la plateforme pour appeler l’outil météo, avec les paramètres suivants : longitude -74° et latitude 40°.

La plateforme renvoie le résultat après avoir appelé l’outil : il pleut. Le modèle réfléchit à nouveau : « Il pleut. Conformément à la demande de l’utilisateur, s’il pleut, je dois également l’aider à trouver un magasin vendant des parapluies. Il y a ici un outil de recherche de magasins que je peux appeler. » Le grand modèle envoie à nouveau une instruction à la plateforme pour appeler l’outil de recherche de magasins et rechercher des parapluies.

Après avoir appelé l’outil, la plateforme renvoie le résultat suivant : il y a un magasin FamilyMart vendant des parapluies à moins de 100 mètres. Le grand modèle synthétise toutes les informations et se dit : « Tous les objectifs ont été atteints, je peux donner la réponse finale à l’utilisateur. » Le grand modèle fournit alors la réponse finale, et l’échange est terminé.

Nous appelons « agent » ce type de système capable de planifier et d’appeler des outils de manière autonome jusqu’à ce que la tâche de l’utilisateur soit accomplie. Il existe actuellement de nombreux produits de ce type sur le marché, parmi lesquels les plus populaires sont notamment Claude Code, Codex et Gemini CLI. Personnellement j’adore opencode. Les modèles de construction d’agents utilisés sont très variés, les plus classiques étant ReAct, Plan and Execute, etc.

Personnaliser l’Agent : Les compétences (Skills)

Nous savons que les agents sont capables de planifier de manière autonome, d’utiliser des outils et de travailler sans relâche jusqu’à ce que la tâche soit accomplie. Cela semble déjà parfait, n’est-ce pas ? Mais lors d’une utilisation intensive, vous allez rapidement rencontrer un nouveau problème.

Prenons un exemple : supposons que vous souhaitiez que le grand modèle devienne votre petit assistant avant de sortir, qu’il vérifie la météo à chaque fois et vous rappelle de prendre vos affaires. Vous avez certainement vos propres habitudes lorsque vous sortez, par exemple prendre un parapluie s’il pleut, un chapeau si le soleil tape fort, un masque si l’air est mauvais, une veste coupe-vent s’il y a du vent, et dans tous les cas, votre téléphone portable est indispensable.

De plus, vous êtes peut-être un peu maniaque et vous souhaitez que ses réponses ne soient pas trop verbeuses, mais qu’elles respectent un format précis, par exemple en commençant par un résumé, puis en énumérant la liste des objets à emporter. Si, sans aucune configuration préalable, vous posez simplement la question suivante : « Je vais sortir tout de suite, que dois-je emporter ? »

Imaginez devoir taper un si long texte d’exigences à chaque fois que vous sortez : n’est-ce pas tout à fait contre-intuitif ? Ne vous inquiétez pas, c’est là qu’Agent Skill entre en scène.

Agent Skill est essentiellement un document d’instructions que vous rédigez à l’avance et que vous transmettez à Agent. Par exemple, pour le scénario de sortie évoqué précédemment, nous pouvons créer un Agent Skill comme celui-ci. On constate qu’il s’agit essentiellement d’un document Markdown, dont la structure globale se divise en deux parties.

La partie supérieure correspond à la couche de métadonnées

La partie supérieure correspond à la couche de métadonnées, qui équivaut à la couverture de ce document d’instructions. Elle indique à l’Agent le nom de cette compétence et ce dont elle est chargée.

Cette partie doit comporter au moins deux attributs : Name et Description. Name représente le nom de cette compétence d’Agent. Par exemple, notre compétence d’Agent s’appelle « Go out checklist », c’est-à-dire « liste de contrôle pour sortir » en anglais. Le reste, Description, correspond à la description.

La partie inférieure correspond à la couche d’instructions

La partie inférieure, qui commence par l’objectif et s’étend jusqu’à la fin de ce document de description, est appelée « couche d’instructions ». Il n’y a pas d’exigences spécifiques concernant le format de cette couche ; il suffit que les instructions soient claires pour l’Agent, et vous pouvez choisir le format qui vous convient.

Par exemple, j’ai indiqué ici l’objectif à atteindre, les étapes d’exécution, les règles de décision, le format de sortie ainsi qu’un exemple. Comme vous pouvez le voir dans les étapes d’exécution, nous indiquons à l’Agent qu’il doit d’abord utiliser l’outil de localisation pour obtenir les coordonnées géographiques, puis utiliser l’outil météo pour obtenir les informations météorologiques.

Une fois les informations météorologiques obtenues, il faut, en fonction des résultats, organiser les objets à emporter en suivant les règles de décision ci-dessous. Ces règles de décision sont décrites ici. Enfin, le résultat final doit être présenté à l’utilisateur en respectant strictement le format de sortie ci-dessous. Nous indiquons ce format ici ; il faut au total afficher deux phrases.

À la fin de la couche d’instructions, nous avons également fourni un exemple. Dans cet exemple, nous supposons que la question de l’utilisateur est la suivante : « Je vais bientôt sortir, aide-moi à voir ce que je dois emporter aujourd’hui. » Nous supposons ensuite que la réponse de l’outil se présente ainsi : l’outil de localisation renvoie telle réponse, l’outil météo renvoie telle réponse. Dans ce cas, l’Agent doit générer un résultat de ce type.

Voici la structure globale de l’Agent Skill dont nous avons besoin. Une fois définie, nous devons l’enregistrer à l’emplacement spécifié sur le disque dur. Prenons l’exemple de Claude Code : vous devez trouver le dossier .claude/skills dans le répertoire utilisateur.

Il y a deux règles à respecter pour l’enregistrement

• Premièrement, nous devons créer un nouveau dossier dans ce répertoire, et le nom de ce dossier doit correspondre exactement au nom de l’Agent Skill. Notre Agent Skill s’appelle go-out-checklist, donc notre dossier doit également porter ce nom.
• Deuxièmement, une fois dans ce dossier, nous devons créer un nouveau fichier et y coller tout le contenu précédent. Attention, le nom de ce fichier doit être SKILL.md, avec SKILL en majuscules. Il s’agit d’une règle stricte pour les Agent Skills, une sorte de mot de passe. Si vous choisissez un nom au hasard, le système ne le reconnaîtra absolument pas.

Copions-collons tout, puis enregistrons et fermons le fichier. Une fois enregistré, notre Agent Skill est créé. Ensuite, choisissons n’importe quel dossier vide et lançons Claude Code.

Au cours du lancement Claude Code, vous remarquerez qu’un Agent Skill nommé go-out-checklist s’est ajouté au dossier skills. Il va alors lire les métadonnées contenues dans le fichier SKILL.md correspondant, à savoir le nom et la description. Pour l’instant, il ne lit pas la couche de commandes, car son contenu peut être assez volumineux.

Ainsi, Claude Code ne lira la couche de commandes correspondante que lorsque la question de l’utilisateur est en rapport avec le nom et la description de l’Agent Skill. Soit dit en passant, cet Agent Skill nécessite explicitement les deux outils « localisation » et « météo » ; je les ai déjà importés sous forme d’outils MCP dans Claude Code.

Saisissons maintenant la question suivante : « Je sors, dis-moi ce que je dois emporter. » Valider. On peut voir que Claude Code s’est mis au travail, attendons un instant.

Il détecte d’abord que cette question est liée à l’Agent Skill « go-out-checklist » et lit donc le contenu complet de l’Agent Skill. Il s’agit principalement de la couche d’instructions, car la couche de métadonnées a déjà été chargée lors du démarrage de Claude Code.

Après avoir lu l’intégralité du contenu de l’Agent Skill, Claude Code commence à agir conformément aux exigences de l’Agent Skill. Il demande d’abord à utiliser l’outil de localisation, ce que nous acceptons. Il fait ensuite appel à l’outil météo, ce que nous acceptons également.

Une fois toutes les informations nécessaires obtenues, Claude Code nous fournit la réponse sous le format requis par l’Agent Skill. En effet, le fonctionnement de base de l’Agent Skill est aussi simple que cela : il s’agit d’un document, un guide d’utilisation destiné à l’Agent.

Synthèse : L’écosystème complet

Bien, nous avons maintenant abordé tous les concepts. Revenons sur ce système.

LLM signifie « grand modèle » ; il s’agit du cœur de toutes les technologies d’IA. Le token est l’unité la plus élémentaire avec laquelle le grand modèle traite les données. Le contexte (Context) correspond à l’ensemble des informations reçues par le grand modèle à chaque fois qu’il traite une tâche. Vous pouvez le considérer comme la mémoire temporaire du grand modèle, qui contient l’historique, les règles du système, les entrées actuelles, etc. Les tokens constituent l’unité de base de ces données.

La fenêtre de contexte (Context Window) représente quant à elle le nombre maximal de tokens que le contexte du grand modèle peut contenir. Une « prompt » est une instruction ou une question spécifique que l’utilisateur ou le système adresse au grand modèle ; elle se divise en deux grandes catégories : la « prompt utilisateur » et la « prompt système ».

La « prompt utilisateur » représente l’entrée fournie par l’utilisateur au modèle, tandis que la « prompt système » correspond à la personnalité et aux règles de fonctionnement du grand modèle configurées par le développeur en arrière-plan. Un « outil » est une fonction utilisée par le grand modèle pour percevoir et influencer l’environnement externe. Le MCP est un protocole standard qui unifie le format d’intégration des outils. Grâce au MCP, les développeurs n’ont plus qu’à créer des outils selon une seule norme, sans avoir à les adapter pour chaque fabricant de grands modèles.

Un Agent est un programme capable de planifier et d’utiliser des outils de manière autonome, et de fonctionner en continu jusqu’à ce que le problème de l’utilisateur soit résolu. L’Agent Skill est un document d’instructions destiné à l’Agent, principalement utilisé pour définir les étapes et les règles d’exécution. Voilà en gros ce qu’il en est.

Bibliographie & Sources