Sense of [AI]

C'est quoi un LLM, vraiment ? (l'IA expliquée simplement)

Wed, 08 Jul 2026 12:00:00 +0200

ChatGPT, Claude, Gemini, Copilot… derrière tous ces noms se cache la même bête : un LLM, pour Large Language Model — grand modèle de langage. On l’utilise tous les jours, on lui confie du code, des mails, des décisions. Mais au fond, qu’est-ce que c’est ? Une base de connaissances ? Un cerveau ? De la magie ?

Bonne nouvelle : le principe tient en une phrase, et une fois qu’on l’a compris, tout le reste — les hallucinations, le prix, les limites — devient évident. Vous allez voir : c’est pas sorcier.

L’image à garder en tête : une autocomplétion géante

Vous connaissez la suggestion de mot suivant sur le clavier de votre téléphone ? Vous tapez « Je rentre à la… » et il propose « maison ». Il ne comprend rien : il a juste vu des millions de phrases et sait quel mot vient souvent après.

Un LLM, c’est exactement ça — mais qui aurait lu presque tout ce que l’humanité a écrit. Des livres, du code, des forums, des articles. À cette échelle, deviner « le mot suivant » cesse d’être un gadget et se met à ressembler à de l’intelligence.

C’est toute l’idée. Le reste, ce sont les détails — et ils sont passionnants.

Au fond, ça fait quoi ? Il devine le token suivant

Donnez ce début à un modèle : « Le ciel est ». Il ne va pas « chercher » la réponse dans une base. Il va calculer, pour chaque mot possible, une probabilité d’être le suivant :

Le ciel est →   bleu   (72 %)
                gris   (11 %)
                dégagé  (6 %)
                …

Il choisit (souvent le plus probable), ajoute le mot, et recommence avec « Le ciel est bleu », puis encore, mot après mot — ou plus exactement token après token. C’est ça, la prédiction du token suivant.

Retenez bien ceci, car tout en découle : un LLM ne récite pas des faits, il calcule le texte le plus plausible. La plupart du temps, plausible = correct. Parfois, non — on y revient.

Comment il a « appris » ? L’entraînement

Un LLM est un réseau de neurones : un très gros programme rempli de milliards de petits réglages internes, appelés paramètres (ou poids).

Pendant l’entraînement, on lui montre des quantités colossales de texte en lui faisant jouer, encore et encore, au jeu du mot caché : « Le chat boit du ___ ». À chaque erreur, on ajuste très légèrement ses milliards de réglages pour qu’il se trompe un peu moins la fois suivante. Répétez des milliards de fois : il finit par « intérioriser » la grammaire, des faits, des styles, des raisonnements.

Deux choses essentielles à comprendre :

Il ne stocke pas les textes comme une bibliothèque. Il en garde une sorte d’intuition statistique diffuse dans ses paramètres. C’est pour ça qu’il peut écrire des phrases inédites — mais aussi pourquoi il ne « connaît » rien de précis à la virgule près.
Entraîner ≠ utiliser. L’entraînement est une phase unique, longue et hors de prix (des mois, des millions). Ensuite, chaque fois que vous lui parlez, c’est de l’inférence : on fait juste tourner le modèle déjà entraîné. Il n’apprend pas de votre conversation.

Pourquoi c’est bluffant… et pourquoi ça se trompe

À force d’échelle, des capacités émergent : traduire, résumer, coder, raisonner par étapes. Personne ne les a programmées explicitement — elles sont apparues en apprenant à prédire du texte. C’est ce qui rend les LLM si polyvalents.

Mais la même mécanique explique leurs travers :

Les hallucinations. Puisqu’il produit du texte plausible et non vérifié, un LLM peut inventer une citation, une fonction, une date — avec un aplomb total. Ce n’est pas un mensonge : c’est le mot le plus probable, tout simplement.
Une connaissance figée. Il ne sait que ce qu’il a vu à l’entraînement (sa date de coupure). Sans outil pour aller chercher l’info fraîche, il ignore ce qui s’est passé depuis.
Pas de vraie base de faits. Il n’a « ni Google, ni calculatrice » par défaut — juste ses intuitions. D’où l’intérêt de lui fournir le contexte (voir le RAG) plutôt que de compter sur sa mémoire.

Ce que ça change concrètement pour vous

Voir le LLM comme un moteur de texte probabiliste — et non comme un oracle — change tout de suite la façon de s’en servir :

Soyez précis. Le modèle complète ce que vous donnez : un prompt clair et contextualisé produit une bien meilleure suite.
Donnez-lui les faits. Pour une réponse fiable sur vos données, fournissez-les dans le contexte plutôt que d’espérer qu’il les « connaisse ».
Vérifiez ce qui compte. Sur un fait, un chiffre, un bout de code critique : contrôlez. Le plausible n’est pas le vrai.
Choisissez le bon réglage. Besoin de créativité ou de rigueur ? C’est le rôle de la température.

Le LLM en 5 idées

Idée	En clair
Ce qu’il fait	Il devine le token suivant, encore et encore — une autocomplétion géante
Comment il a appris	En ajustant des milliards de paramètres sur d’énormes textes (l’entraînement)
Ce qu’il garde	Une intuition statistique, pas une base de faits exacte
Pourquoi il se trompe	Il produit du plausible, pas du vérifié → hallucinations
Comment bien s’en servir	Être précis, fournir le contexte, vérifier l’important

En résumé

Un LLM n’est ni un cerveau, ni une encyclopédie, ni de la magie : c’est une autocomplétion extraordinairement douée, entraînée à deviner la suite d’un texte. Tout le génie — et tous les pièges — vient de là.

Gardez cette image en tête, et l’IA cesse d’être une boîte noire intimidante. Parce que, au fond… c’est pas sorcier.

Un mot vous échappe ? Le glossaire définit tous les termes IA, en clair.

What is an LLM, really? (AI explained simply)

Wed, 08 Jul 2026 12:00:00 +0200

ChatGPT, Claude, Gemini, Copilot… behind all those names hides the same beast: an LLM, for Large Language Model. We use one every day, we trust it with code, emails, decisions. But deep down, what is it? A knowledge base? A brain? Magic?

Good news: the core idea fits in one sentence, and once you get it, everything else — the hallucinations, the price, the limits — becomes obvious. You’ll see: it’s not rocket science.

The image to keep in mind: a giant autocomplete

You know the next-word suggestion on your phone keyboard? You type “I’m heading back ho…” and it offers “home”. It understands nothing: it has simply seen millions of sentences and knows which word often comes next.

An LLM is exactly that — but one that has read almost everything humanity has ever written. Books, code, forums, articles. At that scale, guessing “the next word” stops being a gimmick and starts to look like intelligence.

That’s the whole idea. The rest is detail — and the details are fascinating.

Deep down, what does it do? It guesses the next token

Give a model this beginning: “The sky is”. It won’t “look up” the answer in a database. It computes, for every possible word, a probability of being next:

The sky is →   blue    (72%)
               gray    (11%)
               clear    (6%)
               …

It picks one (often the most likely), appends the word, and starts over with “The sky is blue”, then again, word after word — or more precisely token after token. That’s next-token prediction.

Remember this, because everything follows from it: an LLM doesn’t recite facts, it computes the most plausible text. Most of the time, plausible = correct. Sometimes, not — we’ll get back to that.

How did it “learn”? Training

An LLM is a neural network: a very large program filled with billions of tiny internal settings, called parameters (or weights).

During training, it’s shown colossal amounts of text and made to play, over and over, a fill-in-the-blank game: “The cat drinks ___”. On every mistake, its billions of settings are nudged ever so slightly so it’s a little less wrong next time. Repeat billions of times, and it ends up “internalizing” grammar, facts, styles, reasoning.

Two essential things to understand:

It doesn’t store the texts like a library. It keeps a kind of diffuse statistical intuition spread across its parameters. That’s why it can write brand-new sentences — but also why it doesn’t “know” anything precisely, word for word.
Training ≠ using. Training is a one-off, long, wildly expensive phase (months, millions). After that, every time you talk to it is inference: you’re just running the already-trained model. It doesn’t learn from your conversation.

Why it’s stunning… and why it gets things wrong

At scale, capabilities emerge: translating, summarizing, coding, reasoning step by step. Nobody programmed them explicitly — they appeared while learning to predict text. That’s what makes LLMs so versatile.

But the same mechanism explains their flaws:

Hallucinations. Since it produces plausible text, not verified text, an LLM can invent a quote, a function, a date — with total confidence. It’s not lying: it’s simply the most probable word.
Frozen knowledge. It only knows what it saw during training (its cutoff date). Without a tool to fetch fresh information, it’s unaware of anything that happened since.
No real fact base. By default it has “neither Google nor a calculator” — just its intuitions. Hence the value of giving it the context (see RAG) rather than relying on its memory.

What this changes for you, concretely

Seeing the LLM as a probabilistic text engine — not an oracle — instantly changes how you use it:

Be specific. The model completes what you give it: a clear, contextualized prompt produces a far better continuation.
Give it the facts. For a reliable answer about your data, provide it in the context rather than hoping it “knows” it.
Verify what matters. For a fact, a number, a critical piece of code: check it. Plausible isn’t the same as true.
Pick the right dial. Need creativity or rigor? That’s what temperature is for.

The LLM in 5 ideas

Idea	In plain words
What it does	Guesses the next token, over and over — a giant autocomplete
How it learned	By tuning billions of parameters on enormous texts (training)
What it keeps	A statistical intuition, not an exact fact base
Why it errs	It produces plausible, not verified → hallucinations
How to use it well	Be specific, provide context, verify what matters

In a nutshell

An LLM is neither a brain, nor an encyclopedia, nor magic: it’s an extraordinarily gifted autocomplete, trained to guess how a text continues. All the genius — and all the traps — comes from that.

Keep that image in mind, and AI stops being an intimidating black box. Because, deep down… it’s not rocket science.

A word you don’t know? The glossary defines every AI term, in plain language.

Tokens envoyés, tokens sortis, tokens en cache… c'est pas sorcier !

Sun, 05 Jul 2026 12:00:00 +0200

Quand on commence à utiliser des modèles d’IA — que ce soit via une API, GitHub Copilot ou un chatbot — un mot revient partout : token. Sur votre facture, dans les limites (« context window »), dans les messages d’erreur (« trop de tokens »). Et on distingue même les tokens envoyés, les tokens de sortie et les tokens en cache, chacun à un prix différent.

Ça a l’air ésotérique. En réalité, une fois qu’on a la bonne image en tête, tout devient limpide. Allez, on démonte le compteur. Vous allez voir : c’est pas sorcier.

D’abord : c’est quoi un token ?

Un modèle de langage ne lit pas des mots, et pas non plus des lettres. Il lit des jetons — des tokens : des petits morceaux de texte. Avant de traiter votre phrase, le modèle la passe dans un hachoir (le tokenizer) qui la découpe en jetons.

Un token, ce n’est ni un mot, ni une lettre. C’est un morceau, souvent une syllabe ou un bout de mot fréquent. Règle de pouce en anglais : 1 token ≈ 4 caractères ≈ ¾ de mot. En français, comptez un peu plus (accents et mots longs se découpent davantage).

Le plus parlant, c’est de le voir. Voici de vrais découpages, avec le tokenizer des modèles GPT récents :

Texte	Nombre de tokens	Découpage
`Hello world`	2	`Hello` · `world`
`Bonjour le monde`	3	`Bonjour` · `le` · `monde`
`développeurs`	4	`dé` · `velop` · `pe` · `urs`
`anticonstitutionnellement`	5	`ant` · `icon` · `stitution` · `nel` · `lement`
`🎉` (emoji)	2 à 3	selon le modèle
` def hello():` (indenté)	4	l’indentation compte aussi

Trois enseignements sautent aux yeux :

Un mot courant comme world = 1 seul token, mais un mot rare ou long comme développeurs en vaut 4 à lui tout seul.
Le français coûte plus cher que l’anglais : les accents et les mots longs se fragmentent davantage.
Tout compte : les espaces, l’indentation du code, les emojis. Même un simple 🎉 pèse plusieurs tokens.

Le mieux, c’est d’essayer vous-même : collez n’importe quel texte sur tokenizer.openai.com et regardez-le se découper en direct. C’est le meilleur moyen de développer une intuition.

Les trois compteurs : envoyés, sortis, en cache

Maintenant que le hachoir tourne, il y a trois compteurs distincts — et c’est là que se joue votre facture.

1. Les tokens envoyés (entrée / input)

Ce sont tous les tokens que vous envoyez au modèle à chaque requête. Et attention, ce n’est pas seulement votre question du moment. C’est :

l’instruction système (le rôle, les consignes) ;
tout l’historique de la conversation jusqu’ici ;
votre message actuel ;
les définitions des outils disponibles (par exemple les schémas des serveurs MCP) ;
les documents ou le contexte que vous joignez.

Point crucial : vous les payez à chaque tour. Plus la conversation grandit, plus l’entrée grossit — et plus chaque nouvelle requête coûte cher. C’est exactement pour ça que, dans mon article sur la personnalisation de GitHub Copilot, je soulignais qu’un gros fichier d’instructions ou trop de serveurs MCP « pèsent » : tout ça, ce sont des tokens envoyés à chaque appel.

2. Les tokens de sortie (sortie / output)

Ce sont les tokens que le modèle génère en réponse. Et voici la surprise : ils sont généralement plus chers — souvent 3 à 5 fois le prix d’un token d’entrée.

Pourquoi ? Parce que produire un token demande au modèle un vrai effort de calcul (il « réfléchit » un jeton à la fois), là où lire l’entrée est comparativement rapide. C’est aussi la raison du paramètre max_tokens : il plafonne la longueur de la réponse pour éviter les mauvaises surprises.

3. Les tokens en cache (prompt caching)

Voici l’astuce qui change tout. Si vous renvoyez le même début de prompt d’une requête à l’autre — un gros prompt système, un long document de référence — le fournisseur peut le garder en mémoire (le mettre en cache) et le relire sans tout recalculer.

Résultat : ces tokens-là sont facturés une fraction du prix normal (jusqu’à ~90 % moins cher) et la réponse arrive bien plus vite (jusqu’à ~80 % de latence en moins). Le modèle a « déjà mâché » ces jetons récemment, il ne repart pas de zéro.

La règle d’or pour en profiter : mettez le contenu stable au début (instructions, documents fixes) et le contenu variable à la fin (la question de l’utilisateur). Selon le fournisseur, le cache est automatique ou à activer explicitement — mais le principe est le même partout.

Chaque modèle a ses particularités

On parle des tokens comme d’une unité universelle. Ce n’est pas tout à fait vrai : chaque modèle a son propre hachoir et son propre bol.

Son propre hachoir (le tokenizer)

Chaque famille de modèles découpe le texte à sa façon. Les modèles GPT d’OpenAI utilisent la bibliothèque tiktoken, avec plusieurs encodages selon la génération (cl100k_base pour GPT-4, o200k_base pour les modèles plus récents). Claude, Gemini ou Llama ont chacun le leur.

Conséquence très concrète : le même texte ne fait pas le même nombre de tokens d’un modèle à l’autre. Notre emoji 🎉 vaut 2 tokens avec un encodage OpenAI récent, mais 3 avec l’ancien. Donc « ça fait 500 tokens » n’a de sens que pour un modèle donné. Pour un compte exact et une estimation de coût fiable, utilisez toujours le tokenizer du fournisseur que vous visez — et pour visualiser côté OpenAI, tokenizer.openai.com reste l’outil le plus parlant.

La taille de son bol (le context window)

Le context window, c’est la mémoire de travail maximale du modèle : le nombre total de tokens qu’il peut prendre en compte d’un coup — entrée et sortie réunies. C’est la taille du bol dans lequel on verse les jetons.

Cette taille varie énormément d’un modèle à l’autre : de l’ordre de 128 000 tokens pour certains, jusqu’à un million et plus pour d’autres (et ça évolue vite). Quand vous dépassez ce plafond, le modèle ne peut pas « tout garder en tête » : il faut tronquer ou résumer le contexte. C’est précisément ce qui se passe quand une très longue conversation ou un très gros fichier finit par « saturer ».

Un grand bol, c’est pratique, mais rappelez-vous les trois compteurs : plus vous remplissez le contexte, plus vous payez de tokens envoyés à chaque tour. La bonne taille de contexte, c’est la plus petite qui fait le travail.

Le tableau récap

Type de token	C’est quoi	Coût relatif	Comment l’alléger
Tokens envoyés (entrée)	Tout ce que vous envoyez : système, historique, message, outils, documents	💶 normal — payé à chaque tour	Contexte court, historique élagué, n’activez que les outils utiles
Tokens de sortie	Ce que le modèle rédige en réponse	💶💶💶 le plus cher (souvent 3–5×)	Demandez des réponses concises, bornez `max_tokens`
Tokens en cache	Le préfixe répété, déjà « mâché » récemment	💶 une fraction (jusqu’à ~90 % de remise)	Mettez le contenu stable en tête, le variable en fin

Et pour les particularités des modèles :

Notion	Ce qu’il faut retenir
Tokenizer	Chaque modèle découpe différemment → un même texte = un nombre de tokens différent. Comptez avec le tokenizer du bon fournisseur.
Context window	La mémoire de travail max (entrée + sortie). De ~128k à 1M+ selon les modèles. La dépasser force à tronquer/résumer.

Quelques réflexes pour alléger la facture

Mettez le stable au début. Instructions et documents fixes en tête → le cache fait le reste.
Soyez concis en sortie. C’est le token le plus cher : demandez des réponses courtes quand vous le pouvez.
Élaguez le contexte. L’historique et les gros documents sont renvoyés à chaque tour. Ne gardez que l’utile.
Coupez les outils inutiles. Les schémas d’outils / serveurs MCP inactifs occupent le contexte pour rien.
Attention au français. Il est plus « verbeux » en tokens que l’anglais — utile à savoir pour estimer un coût.
Choisissez la bonne taille de contexte. Un modèle à 1M de tokens est séduisant, mais un bol plus petit et mieux rempli coûte souvent moins cher.

En résumé

Le modèle lit et écrit en jetons (tokens), pas en mots. Un hachoir (le tokenizer) découpe tout d’abord.
Trois compteurs : les tokens envoyés (tout ce que vous fournissez, payé à chaque tour), les tokens de sortie (ce qu’il génère, le plus cher), les tokens en cache (le préfixe répété, à prix cassé).
Chaque modèle a son hachoir (des comptes différents pour le même texte) et son bol (le context window).

La prochaine fois que vous verrez « tokens » sur une facture ou dans une limite, vous saurez exactement ce qui se cache derrière. Et ça, franchement… c’est pas sorcier.

Input tokens, output tokens, cached tokens… it's not rocket science!

Sun, 05 Jul 2026 12:00:00 +0200

The moment you start using AI models — through an API, GitHub Copilot or a chatbot — one word is everywhere: token. On your bill, in the limits (“context window”), in the error messages (“too many tokens”). And there’s even a distinction between input tokens, output tokens and cached tokens, each at a different price.

It sounds arcane. In reality, once you have the right mental image, it all becomes clear. So let’s take the meter apart. You’ll see: it’s not rocket science.

First: what is a token?

A language model doesn’t read words, and it doesn’t read letters either. It reads tokens: small chunks of text. Before processing your sentence, the model runs it through a shredder (the tokenizer) that cuts it into tokens.

A token is neither a word nor a letter. It’s a chunk — often a syllable or a common piece of a word. Rule of thumb in English: 1 token ≈ 4 characters ≈ ¾ of a word. In other languages (French, for instance), expect a bit more (accents and long words split further).

The clearest way to get it is to see it. Here are real splits, using the tokenizer of the recent GPT models:

Text	Number of tokens	Split
`Hello world`	2	`Hello` · `world`
`Bonjour le monde`	3	`Bonjour` · `le` · `monde`
`développeurs` (French)	4	`dé` · `velop` · `pe` · `urs`
`anticonstitutionnellement`	5	`ant` · `icon` · `stitution` · `nel` · `lement`
`🎉` (emoji)	2 to 3	depending on the model
` def hello():` (indented)	4	indentation counts too

Three lessons jump out:

A common word like world = 1 single token, but a rare or long word like développeurs is worth 4 all by itself.
Non-English text costs more than English: accents and long words fragment more.
Everything counts: spaces, code indentation, emojis. Even a plain 🎉 weighs several tokens.

The best thing is to try it yourself: paste any text into tokenizer.openai.com and watch it split in real time. It’s the best way to build an intuition.

The three meters: input, output, cached

Now that the shredder is running, there are three separate meters — and that’s where your bill is decided.

1. Input tokens

These are all the tokens you send to the model on each request. And beware, it’s not just your current question. It’s:

the system instruction (the role, the guidelines);
the entire history of the conversation so far;
your current message;
the tool definitions available (for example the schemas of MCP servers);
the documents or context you attach.

Crucial point: you pay for them on every turn. The bigger the conversation gets, the bigger the input grows — and the more each new request costs. That’s exactly why, in my article on customizing GitHub Copilot, I stressed that a big instructions file or too many MCP servers “weigh”: all of that is input tokens, sent on every single call.

2. Output tokens

These are the tokens the model generates in response. And here’s the surprise: they’re usually more expensive — often 3 to 5 times the price of an input token.

Why? Because producing a token takes the model real compute (it “thinks” one token at a time), whereas reading the input is comparatively fast. It’s also the reason for the max_tokens parameter: it caps the length of the answer to avoid nasty surprises.

3. Cached tokens (prompt caching)

Here’s the trick that changes everything. If you resend the same prompt prefix from one request to the next — a big system prompt, a long reference document — the provider can keep it in memory (cache it) and reread it without recomputing everything.

The result: those tokens are billed at a fraction of the normal price (up to ~90% cheaper) and the answer arrives much faster (up to ~80% less latency). The model has “already chewed” those tokens recently, so it doesn’t start from scratch.

The golden rule to benefit from it: put the stable content at the beginning (instructions, fixed documents) and the variable content at the end (the user’s question). Depending on the provider, caching is automatic or has to be enabled explicitly — but the principle is the same everywhere.

Every model has its quirks

We talk about tokens as if they were a universal unit. That’s not quite true: every model has its own shredder and its own bowl.

Its own shredder (the tokenizer)

Each model family cuts text its own way. OpenAI’s GPT models use the tiktoken library, with several encodings depending on the generation (cl100k_base for GPT-4, o200k_base for the more recent models). Claude, Gemini and Llama each have their own.

Very concrete consequence: the same text is not the same number of tokens from one model to another. Our 🎉 emoji is 2 tokens with a recent OpenAI encoding, but 3 with the older one. So “that’s 500 tokens” only means something for a given model. For an exact count and a reliable cost estimate, always use the tokenizer of the provider you’re targeting — and to visualize it on the OpenAI side, tokenizer.openai.com remains the most telling tool.

The size of its bowl (the context window)

The context window is the model’s maximum working memory: the total number of tokens it can take into account at once — input and output combined. It’s the size of the bowl you pour the tokens into.

That size varies enormously from one model to another: on the order of 128,000 tokens for some, up to a million and beyond for others (and it’s evolving fast). When you exceed that ceiling, the model can’t “keep it all in mind”: you have to truncate or summarize the context. That’s precisely what happens when a very long conversation or a very large file eventually “saturates”.

A big bowl is handy, but remember the three meters: the more you fill the context, the more input tokens you pay on every turn. The right context size is the smallest one that gets the job done.

The recap table

Token type	What it is	Relative cost	How to trim it
Input tokens	Everything you send: system, history, message, tools, documents	💶 normal — paid on every turn	Short context, pruned history, only enable useful tools
Output tokens	What the model writes back	💶💶💶 the most expensive (often 3–5×)	Ask for concise answers, cap `max_tokens`
Cached tokens	The repeated prefix, “chewed” recently	💶 a fraction (up to ~90% off)	Put the stable content first, variable content last

And for the per-model quirks:

Concept	What to remember
Tokenizer	Every model splits differently → the same text = a different token count. Count with the right provider’s tokenizer.
Context window	The max working memory (input + output). From ~128k to 1M+ depending on the model. Exceeding it forces truncation/summarization.

A few reflexes to trim the bill

Put the stable stuff first. Instructions and fixed documents up front → the cache does the rest.
Be concise in output. It’s the priciest token: ask for short answers when you can.
Prune the context. History and large documents are resent on every turn. Keep only what’s useful.
Cut the useless tools. Inactive tool/MCP server schemas take up context for nothing.
Mind non-English text. It’s more “verbose” in tokens than English — handy to know when estimating a cost.
Pick the right context size. A 1M-token model is tempting, but a smaller, better-filled bowl often costs less.

In a nutshell

The model reads and writes in tokens, not words. A shredder (the tokenizer) cuts everything up first.
Three meters: input tokens (everything you provide, paid on every turn), output tokens (what it generates, the most expensive), cached tokens (the repeated prefix, at a slashed price).
Every model has its own shredder (different counts for the same text) and its own bowl (the context window).

Next time you see “tokens” on a bill or in a limit, you’ll know exactly what’s behind it. And honestly… that’s not rocket science.

GitHub Copilot : Skills, Instructions, Agents, MCP… c'est pas sorcier !

Thu, 02 Jul 2026 12:00:00 +0200

GitHub Copilot n’est plus le petit assistant qui complétait vos lignes de code. C’est devenu un véritable agent, capable de lire votre projet, lancer des commandes, appeler des outils externes et suivre vos règles. Le problème ? On peut désormais le personnaliser de cinq façons différentes — Instructions, Prompts, Skills, Agents, MCP — et tout le monde s’y perd.

Alors on va démonter la mécanique, pièce par pièce. Et pour chacune, on répondra à la question qui fâche : à quel moment est-elle chargée, et qu’est-ce qui entre vraiment dans le contexte du modèle ? Parce que c’est ça, le vrai secret. Et vous allez voir : c’est pas sorcier.

Le fil rouge : imaginez un nouvel assistant surdoué

Pour comprendre les cinq mécanismes, une seule image suffit : Copilot, c’est un nouvel employé brillant mais amnésique.

Il code très bien, il apprend vite… mais à chaque matin il a tout oublié : vos conventions, vos outils, la façon dont vous aimez travailler. Votre job, c’est de l’équiper pour qu’il soit efficace sans que vous ayez à tout ré-expliquer à chaque fois.

Chaque fonctionnalité de personnalisation répond à un moment de cet accueil :

le livret d’accueil (Custom Instructions, et son cousin universel AGENTS.md),
les mémos prêts à l’emploi (Prompts),
les fiches savoir-faire rangées dans un classeur (Skills),
les casquettes de spécialiste (Agents),
et les badges d’accès vers vos outils maison (MCP).

Et pour chacune, on ajoutera un petit encadré ⚙️ qui dit quand elle est chargée et ce que le modèle voit réellement. Reprenons dans l’ordre.

Avant de démonter : le frontmatter, l’étiquette sur la fiche

Un dernier outil avant d’ouvrir le capot, parce qu’il revient dans presque tous les exemples qui suivent : le frontmatter.

L’analogie : c’est l’étiquette collée sur la fiche. Elle ne fait pas partie de la procédure elle-même — elle dit à qui la fiche s’adresse, quand la sortir et comment la ranger. On peut trier tout le classeur rien qu’en lisant les étiquettes, sans jamais ouvrir les fiches.

Concrètement : c’est un petit bloc YAML placé tout en haut d’un fichier Markdown, délimité par deux lignes --- :

---
name: deploiement-azure
description: Déploie l'app sur Azure App Service.
---

Ici commence le contenu Markdown normal…

Tout ce qui est entre les deux ---, ce sont des métadonnées sous forme de paires clé-valeur. Tout ce qui vient après, c’est le contenu proprement dit.

Et cette distinction n’est pas cosmétique — elle recoupe exactement notre question fétiche du « qui voit quoi » :

le frontmatter est lu par le harness (VS Code, Copilot CLI…) avant tout appel au modèle : c’est lui qui décide si le fichier s’applique, quand le charger et avec quels réglages ;
le corps est le texte destiné au modèle, chargé au moment prévu par le mécanisme.

Chaque mécanisme utilise ses propres clés, et vous les reconnaîtrez au fil de l’article :

Clé	Vue dans…	Elle sert à…
`applyTo`	`*.instructions.md`	Restreindre les règles aux fichiers qui matchent le motif glob
`mode`	`*.prompt.md`	Choisir le mode d’exécution du prompt (ex. `agent`)
`name` / `description`	`SKILL.md`, `*.agent.md`	Identifier la fiche — c’est la partie toujours visible du skill
`tools`	`*.agent.md`	Restreindre les outils exposés à l’agent
`model`	`*.agent.md`	Imposer le modèle à utiliser

Deux cas particuliers à noter : AGENTS.md n’a pas de frontmatter du tout (c’est justement sa promesse — du Markdown brut compris par tous les agents), et dans un SKILL.md, le frontmatter joue un rôle de premier plan : name et description sont la seule chose chargée en permanence — c’est l’étiquette que le modèle lit pour décider d’ouvrir la fiche.

Voilà, vous avez la clé de lecture. Maintenant, démontons.

1. Custom Instructions — le livret d’accueil

L’analogie : c’est le règlement intérieur affiché au mur. Votre assistant le lit à chaque tâche, sans qu’on lui demande. « Ici, on écrit en C#, on teste avec xUnit, et on répond en français. »

Concrètement : un fichier Markdown à la racine du dépôt qui donne à Copilot le contexte permanent du projet — la stack, les conventions, les préférences.

Le fichier principal vit dans .github/copilot-instructions.md :

# Contexte du projet

- API ASP.NET Core en C# (.NET 9).
- Utilise des `record` immuables pour les DTO.
- Écris les tests avec xUnit et FluentAssertions.
- Dans tes explications, réponds en français.

Besoin de règles ciblées sur certains fichiers ? On ajoute des fichiers *.instructions.md dans .github/instructions/, avec un en-tête applyTo qui utilise un motif glob :

---
applyTo: "**/*.test.ts"
---
- Utilise Vitest et Testing Library.
- Un bloc `describe` par composant.

Si le fichier correspond, ces règles s’ajoutent à celles de tout le projet.

⚙️ Chargé quand : à chaque requête, automatiquement. Le fichier racine s’applique toujours ; un *.instructions.md ne s’ajoute que si son motif applyTo correspond aux fichiers en jeu.

Ce qui entre dans le contexte : le texte intégral du fichier, injecté en tête de contexte comme une consigne système. Il est présent à chaque appel — d’où l’importance de le garder court et net.

Quand l’utiliser : toujours, et en premier. C’est le socle. Dès que vous vous surprenez à répéter « en C#, avec des records, en français… » à chaque conversation, c’est qu’il faut l’écrire une bonne fois ici.

Le cousin universel : `AGENTS.md`

.github/copilot-instructions.md est propre à Copilot. Mais si vous jonglez entre plusieurs agents (Copilot, mais aussi Cursor, Codex, Jules…), il existe un fichier standard et neutre : AGENTS.md, à la racine du dépôt.

C’est un simple Markdown — un « README pour les agents » — où l’on met ce qui encombrerait le README humain : commandes de build, façon de lancer les tests, conventions maison, pièges à éviter. Pas d’en-tête, pas de syntaxe particulière : du Markdown, point.

# AGENTS.md

## Build & tests
- Installer : `dotnet restore`
- Lancer les tests : `dotnet test`
- Ne jamais committer dans `main` directement.

## Conventions
- C# / .NET 9, DTO en `record` immuables.

Deux choses à retenir :

C’est un standard ouvert, piloté par l’Agentic AI Foundation (sous la Linux Foundation) et adopté par OpenAI Codex, Cursor, Jules (Google), Amp, Factory… et lu par l’agent de codage GitHub Copilot.
Le plus proche gagne. Vous pouvez poser un AGENTS.md à la racine et des AGENTS.md dans des sous-dossiers : l’agent lit le plus proche des fichiers sur lesquels il travaille. Chaque sous-projet peut ainsi avoir ses propres consignes.

⚙️ Chargé quand : automatiquement, comme les Custom Instructions. Celui de la racine s’applique toujours ; un AGENTS.md de sous-dossier prend le relais quand l’agent travaille dans ce dossier.

Ce qui entre dans le contexte : le texte du AGENTS.md le plus proche, injecté comme consigne. Bonus : l’agent de codage Copilot sait aussi lire .github/copilot-instructions.md, *.instructions.md, ainsi que CLAUDE.md et GEMINI.md — vous n’êtes pas obligé de tout dupliquer.

Instructions ou AGENTS.md ? Même idée (le « livret d’accueil »), deux portées : copilot-instructions.md si vous êtes 100 % Copilot, AGENTS.md si vous voulez un seul fichier compris par tous les agents.

2. Prompts — les mémos prêts à l’emploi

L’analogie : le post-it « Voici comment tu prépares une fiche de release » collé sur le bureau. Un raccourci pour une tâche que vous redemandez souvent, mot pour mot.

Concrètement : un prompt file, fichier .prompt.md rangé dans .github/prompts/, que vous déclenchez comme une commande avec un slash.

---
mode: agent
---
Prépare la description de la Pull Request à partir du diff courant :
un résumé en une phrase, la liste des changements, et les risques éventuels.

Enregistré sous pr.prompt.md, il s’appelle en tapant simplement /pr dans le chat. Fini le paragraphe d’instructions recopié à la main.

⚙️ Chargé quand : uniquement quand vous tapez /mon-prompt. Jamais tout seul.

Ce qui entre dans le contexte : le corps du prompt est inséré à ce moment-là comme (partie de) votre message, avec les fichiers qu’il référence. Le reste du temps, il n’occupe aucune place dans le contexte.

Le mot d’honnêteté : vous avez peut-être entendu que les prompt files sont « moins nécessaires » aujourd’hui. C’est vrai — et c’est assumé. Les Agents (qui embarquent déjà un rôle et des consignes) et les Skills (qui se déclenchent tout seuls) couvrent une bonne partie des besoins. Le prompt file reste néanmoins l’option la plus simple et rapide pour transformer un paragraphe récurrent en une commande d’un mot. Un couteau qui coupe encore très bien, même s’il existe désormais des robots de cuisine.

Quand l’utiliser : pour un raccourci simple et personnel, sans script ni outil particulier. Si votre besoin devient un vrai savoir-faire multi-étapes, passez aux Skills.

3. Skills — les fiches savoir-faire dans le classeur

L’analogie : un classeur de fiches procédure. Votre assistant ne les lit pas toutes en permanence — il en lit juste le titre, et quand une tâche correspond, il sort la bonne fiche et suit la procédure (qui peut même contenir des scripts et des exemples).

Concrètement : une Agent Skill est un dossier contenant un fichier SKILL.md (plus, éventuellement, des scripts, gabarits ou exemples).

.github/skills/
└── deploiement-azure/
    ├── SKILL.md
    ├── deploy.sh
    └── exemples/

Le SKILL.md commence par un en-tête qui décrit quand l’utiliser :

---
name: deploiement-azure
description: Déploie l'app sur Azure App Service et vérifie le health check.
---

1. Construire l'image avec `docker build ...`
2. Pousser vers le registre `az acr ...`
3. Déployer avec `az webapp up ...`
4. Vérifier `https://.../health` avant de confirmer.

⚙️ Chargé quand : en divulgation progressive, à l’initiative du modèle. Au départ, il ne « voit » que le name et la description. Il ne charge le corps du SKILL.md que si la tâche correspond (ou si vous l’invoquez), et n’ouvre les scripts que s’il en a besoin.

Ce qui entre dans le contexte : au repos, juste une ligne de description par skill. Puis, à la demande, le corps de la fiche, puis les ressources. C’est exactement pour ça qu’on peut en avoir des dizaines sans saturer le contexte.

Autre avantage : les Skills suivent un standard ouvert. La même fiche fonctionne dans Copilot sous VS Code, dans Copilot CLI et dans l’agent cloud — et même avec d’autres agents compatibles.

Quand l’utiliser : pour un savoir-faire réutilisable et multi-étapes, surtout s’il embarque des scripts ou des ressources. « Comment on déploie », « comment on écrit un test d’intégration maison » : ce sont des skills.

4. Agents — les casquettes de spécialiste

L’analogie : au lieu d’un assistant généraliste, vous convoquez le bon spécialiste : le relecteur tatillon, l’architecte, le rédacteur de docs. Chacun a son caractère, ses outils autorisés et sa manière de travailler.

Concrètement : un custom agent est un fichier *.agent.md (dans .github/agents/) qui définit une persona : son rôle, ses consignes, les outils qu’il a le droit d’utiliser, et même le modèle à employer.

---
name: relecteur
description: Relecteur de code senior, exigeant sur la sécurité et les tests.
tools: ['search', 'edit']
model: claude-sonnet-5
---
Tu es un relecteur senior. Concentre-toi sur :
les bugs, les failles de sécurité, les cas limites et les tests manquants.
Sois direct, propose des correctifs concrets, ne reformule pas le code qui va bien.

On bascule alors sur cet agent en un clic, plutôt que de ré-expliquer son rôle à chaque conversation. C’est aussi le principe de l’agent de codage (le coding agent) auquel vous pouvez carrément assigner une issue GitHub : il travaille en autonomie et ouvre une Pull Request.

⚙️ Chargé quand : quand vous activez l’agent (sélection dans l’interface, @mention, ou assignation d’une issue pour l’agent de codage).

Ce qui entre dans le contexte : ses consignes deviennent la consigne système active ; sa liste tools restreint les outils exposés par le harness ; son model choisit le modèle. Un agent ne fait pas qu’ajouter du texte : il reconfigure la session.

Quand l’utiliser : quand vous voulez un rôle spécialisé et récurrent, avec ses propres outils et garde-fous. Si vous jonglez entre « casquette dev » et « casquette relecture », faites-en deux agents.

5. MCP — les badges d’accès vers le monde extérieur

L’analogie : jusqu’ici, votre assistant ne connaît que votre code. MCP, ce sont les badges et les prises qui le branchent sur le reste de votre écosystème : la base de données, Jira, votre monitoring, un navigateur, votre CRM…

Concrètement : le Model Context Protocol est un standard ouvert pour connecter un agent IA à des outils et des données externes. Vous déclarez les serveurs MCP dans un fichier mcp.json (dans .vscode/mcp.json pour un projet) :

{
  "servers": {
    "github": {
      "type": "http",
      "url": "https://api.githubcopilot.com/mcp"
    },
    "playwright": {
      "command": "npx",
      "args": ["-y", "@microsoft/mcp-server-playwright"]
    }
  }
}

Une fois branché, Copilot peut lire vos issues GitHub, piloter un navigateur, interroger une base… selon les outils que le serveur expose.

⚙️ Chargé quand : dès qu’un serveur est activé, le harness charge la description des outils qu’il expose (nom, rôle, schéma d’entrée) — même si vous ne les appelez jamais. Les résultats, eux, n’arrivent que lorsqu’un outil est réellement appelé.

Ce qui entre dans le contexte : les définitions d’outils (en permanence, tant que le serveur est actif) puis les résultats d’appels (à la demande). Conséquence très concrète : trop de serveurs MCP = un contexte encombré rien que par les schémas. D’où l’intérêt de désactiver ceux qu’on n’utilise pas.

Attention au badge d’accès : un serveur MCP, c’est du code tiers à qui vous donnez les clés. VS Code vous demande de confirmer votre confiance avant de le démarrer, et permet de mettre les serveurs locaux dans un bac à sable (accès fichiers/réseau restreint). Ne branchez que ce que vous connaissez — j’en parlais déjà dans mon article sur la sécurisation des serveurs MCP.

Quand l’utiliser : dès que Copilot a besoin de données ou d’actions qui vivent en dehors de votre code. Pour tout ce qui est purement « connaissances et conventions du projet », les Instructions et les Skills suffisent.

Le tableau récap : quand utiliser quoi — et quand c’est chargé ?

Élément	Ça sert à…	Où ça vit	Chargé dans le contexte	Quand l’utiliser
Custom Instructions	Contexte et conventions permanents du projet	`.github/copilot-instructions.md`, `*.instructions.md`	Toujours — texte intégral, à chaque requête	Dès que vous répétez les mêmes règles
`AGENTS.md`	Les mêmes consignes, mais pour tous les agents	`AGENTS.md` (racine + sous-dossiers)	Toujours — le fichier le plus proche l’emporte	Vous utilisez plusieurs agents, pas que Copilot
Prompts	Rejouer un prompt récurrent en `/commande`	`*.prompt.md` dans `.github/prompts/`	À l’invocation manuelle uniquement	Un raccourci simple et personnel, sans script
Skills	Un savoir-faire multi-étapes (+ scripts)	Dossier `SKILL.md` dans `.github/skills/`	À la demande — nom + description, puis le reste	Une procédure réutilisable (« comment on déploie »)
Agents	Un rôle dédié, avec ses outils et son modèle	`*.agent.md` dans `.github/agents/`	À l’activation — devient la consigne système	Un profil récurrent (relecteur, architecte…)
MCP	Brancher Copilot sur des outils/données externes	`mcp.json` (ex. `.vscode/mcp.json`)	Schémas dès l’activation, résultats à l’appel	Besoin d’agir hors du code (BDD, Jira, navigateur…)

🎁 L’astuce de départ : faites écrire le livret d’accueil… par l’assistant lui-même

Vous êtes convaincu par le AGENTS.md, mais la page blanche vous freine ? Bonne nouvelle : il existe un skill dont le seul métier est de générer votre AGENTS.md. Oui, vous avez bien lu — on utilise une fiche savoir-faire (mécanisme n° 3) pour fabriquer le livret d’accueil (mécanisme n° 1). C’est un peu de l’inception, et c’est surtout de l’auto-apprentissage : l’assistant explore votre dépôt et rédige lui-même le document qui lui servira de mémoire à chaque session.

Le skill s’appelle create-agentsmd et vient du dépôt officiel awesome-copilot de GitHub. Une commande suffit :

npx skills add https://github.com/github/awesome-copilot --skill create-agentsmd

Ensuite, demandez simplement à Copilot de « créer le AGENTS.md du projet » : le skill se déclenche, analyse votre dépôt (stack, commandes de build, façon de lancer les tests, conventions, structure — monorepos compris) et produit un AGENTS.md conforme au standard ouvert, prêt à être relu et committé.

Et c’est là que la boucle se referme : au prochain démarrage, votre employé amnésique lira le livret qu’il a écrit lui-même la veille. Relisez-le, corrigez ce qui manque, committez — et vous venez de faire le premier pas concret pour aider votre agent à garder son contexte d’une session à l’autre.

La règle simple à retenir

Si vous ne deviez retenir qu’une chose : commencez par les Instructions, ajoutez le reste seulement quand un besoin revient.

Vous répétez des règles ? → Instructions (ou AGENTS.md si plusieurs agents).
Vous répétez un prompt ? → Prompt file.
Vous répétez une procédure ? → Skill.
Vous répétez un rôle ? → Agent.
Vous répétez un branchement vers un outil externe ? → MCP.

Et si vous ne deviez en retenir deux, ajoutez le réflexe contexte : ce qui est « toujours chargé » (Instructions, AGENTS.md, schémas MCP) doit rester léger, car vous le payez à chaque requête ; ce qui est « à la demande » (Prompts, Skills, résultats d’outils) peut être plus riche, car il ne coûte que lorsqu’on s’en sert.

Vous voyez la logique ? À chaque fois que vous vous entendez dire « je l’ai déjà expliqué la semaine dernière… », c’est le signal qu’un de ces mécanismes attend d’être utilisé.

Et ça, mine de rien… c’est pas sorcier.

GitHub Copilot: Skills, Instructions, Agents, MCP… it's not rocket science!

Thu, 02 Jul 2026 12:00:00 +0200

GitHub Copilot is no longer the little assistant that finished your lines of code. It has become a real agent, able to read your project, run commands, call external tools and follow your rules. The catch? You can now customize it in five different ways — Instructions, Prompts, Skills, Agents, MCP — and everyone gets lost.

So let’s take the machine apart, piece by piece. And for each one, we’ll answer the awkward question: when does it get loaded, and what actually enters the model’s context? Because that’s the real secret. And you’ll see: it’s not rocket science.

The through-line: picture a brilliant new assistant

To understand all five mechanisms, one image is enough: Copilot is a brilliant but amnesiac new hire.

It codes very well, it learns fast… but every morning it has forgotten everything: your conventions, your tools, the way you like to work. Your job is to equip it so that it’s productive without you having to re-explain everything every single time.

Each customization feature answers a moment in that onboarding:

the welcome handbook (Custom Instructions, and its universal cousin AGENTS.md),
the ready-made memos (Prompts),
the know-how sheets filed in a binder (Skills),
the specialist hats (Agents),
and the access badges to your in-house tools (MCP).

And for each one, we’ll add a little ⚙️ box that says when it’s loaded and what the model actually sees. Let’s take them in order.

Before we take it apart: frontmatter, the label on the sheet

One last tool before we open the hood, because it shows up in almost every example that follows: frontmatter.

The analogy: it’s the label stuck on the sheet. It’s not part of the procedure itself — it says who the sheet is for, when to pull it out and how to file it. You can sort the whole binder just by reading the labels, without ever opening the sheets.

Concretely: it’s a small YAML block at the very top of a Markdown file, delimited by two --- lines:

---
name: azure-deploy
description: Deploy the app to Azure App Service.
---

The normal Markdown content starts here…

Everything between the two --- lines is metadata, as key-value pairs. Everything after is the actual content.

And that distinction is not cosmetic — it maps exactly onto our favorite question of “who sees what”:

the frontmatter is read by the harness (VS Code, Copilot CLI…) before any call to the model: it’s what decides whether the file applies, when to load it and with which settings;
the body is the text meant for the model, loaded at the moment the mechanism dictates.

Each mechanism uses its own keys, and you’ll recognize them throughout the article:

Key	Seen in…	It’s used to…
`applyTo`	`*.instructions.md`	Restrict the rules to files matching the glob pattern
`mode`	`*.prompt.md`	Pick the prompt’s execution mode (e.g. `agent`)
`name` / `description`	`SKILL.md`, `*.agent.md`	Identify the sheet — the always-visible part of a skill
`tools`	`*.agent.md`	Restrict the tools exposed to the agent
`model`	`*.agent.md`	Force which model to use

Two special cases worth noting: AGENTS.md has no frontmatter at all (that’s precisely its promise — plain Markdown understood by every agent), and in a SKILL.md the frontmatter plays a starring role: name and description are the only thing loaded permanently — the label the model reads to decide whether to open the sheet.

There’s your reading key. Now, let’s take it apart.

1. Custom Instructions — the welcome handbook

The analogy: it’s the house rules pinned to the wall. Your assistant reads them on every task, without being asked. “Here, we write C#, we test with xUnit, and we answer in English.”

Concretely: a Markdown file at the root of the repository that gives Copilot the project’s permanent context — the stack, the conventions, the preferences.

The main file lives in .github/copilot-instructions.md:

# Project context

- ASP.NET Core API in C# (.NET 9).
- Use immutable `record` types for DTOs.
- Write tests with xUnit and FluentAssertions.
- In your explanations, answer in English.

Need rules targeted at certain files? Add *.instructions.md files under .github/instructions/, with an applyTo header that uses a glob pattern:

---
applyTo: "**/*.test.ts"
---
- Use Vitest and Testing Library.
- One `describe` block per component.

If the file matches, those rules are added on top of the project-wide ones.

⚙️ Loaded when: on every request, automatically. The root file always applies; a *.instructions.md is only added when its applyTo pattern matches the files in play.

What enters the context: the full text of the file, injected at the top of the context like a system instruction. It’s there on every call — which is why you keep it short and sharp.

When to use it: always, and first. It’s the foundation. The moment you catch yourself repeating “in C#, with records, in English…” in every conversation, it’s time to write it down here once and for all.

The universal cousin: `AGENTS.md`

.github/copilot-instructions.md is Copilot-specific. But if you juggle several agents (Copilot, but also Cursor, Codex, Jules…), there’s a standard, tool-agnostic file: AGENTS.md, at the root of the repository.

It’s a plain Markdown file — a “README for agents” — where you put what would clutter the human README: build commands, how to run the tests, house conventions, gotchas to avoid. No frontmatter, no special syntax: just Markdown.

# AGENTS.md

## Build & tests
- Install: `dotnet restore`
- Run tests: `dotnet test`
- Never commit to `main` directly.

## Conventions
- C# / .NET 9, DTOs as immutable `record` types.

Two things to remember:

It’s an open standard, stewarded by the Agentic AI Foundation (under the Linux Foundation) and adopted by OpenAI Codex, Cursor, Jules (Google), Amp, Factory… and read by the GitHub Copilot coding agent.
Nearest wins. You can drop an AGENTS.md at the root and AGENTS.md files in subfolders: the agent reads the nearest one to the files it’s working on. Every subproject can have its own instructions.

⚙️ Loaded when: automatically, just like Custom Instructions. The root one always applies; a subfolder AGENTS.md takes over when the agent works in that folder.

What enters the context: the text of the nearest AGENTS.md, injected as an instruction. Bonus: the Copilot coding agent also reads .github/copilot-instructions.md, *.instructions.md, as well as CLAUDE.md and GEMINI.md — you don’t have to duplicate everything.

Instructions or AGENTS.md? Same idea (the “welcome handbook”), two scopes: copilot-instructions.md if you’re 100% Copilot, AGENTS.md if you want a single file understood by every agent.

2. Prompts — the ready-made memos

The analogy: the sticky note “here’s how you prepare a release sheet” stuck on the desk. A shortcut for a task you keep asking for, word for word.

Concretely: a prompt file, a .prompt.md file filed under .github/prompts/, that you trigger like a slash command.

---
mode: agent
---
Prepare the Pull Request description from the current diff:
a one-sentence summary, the list of changes, and any risks.

Saved as pr.prompt.md, it’s invoked by simply typing /pr in chat. No more re-typing the same paragraph of instructions.

⚙️ Loaded when: only when you type /my-prompt. Never on its own.

What enters the context: the prompt body is inserted at that moment as (part of) your message, along with the files it references. The rest of the time, it takes up no space in the context.

A word of honesty: you may have heard that prompt files are “less necessary” today. That’s true — and it’s fair. Agents (which already carry a role and instructions) and Skills (which trigger on their own) cover a good chunk of the need. Still, the prompt file remains the simplest and fastest option to turn a recurring paragraph into a one-word command. A knife that still cuts very well, even though food processors now exist.

When to use it: for a simple, personal shortcut, with no script or special tool. If your need grows into a real multi-step know-how, move up to Skills.

3. Skills — the know-how sheets in the binder

The analogy: a binder of procedure sheets. Your assistant doesn’t read them all the time — it just reads the title, and when a task matches, it pulls out the right sheet and follows the procedure (which can even contain scripts and examples).

Concretely: an Agent Skill is a folder containing a SKILL.md file (plus, optionally, scripts, templates or examples).

.github/skills/
└── azure-deploy/
    ├── SKILL.md
    ├── deploy.sh
    └── examples/

The SKILL.md starts with a header describing when to use it:

---
name: azure-deploy
description: Deploy the app to Azure App Service and check the health endpoint.
---

1. Build the image with `docker build ...`
2. Push to the registry with `az acr ...`
3. Deploy with `az webapp up ...`
4. Check `https://.../health` before confirming.

⚙️ Loaded when: through progressive disclosure, decided by the model. At first it only “sees” the name and the description. It loads the body of the SKILL.md only if the task matches (or if you invoke it), and opens the scripts only if it needs them.

What enters the context: at rest, just a one-line description per skill. Then, on demand, the body of the sheet, then the resources. That’s exactly why you can have dozens of them without saturating the context.

Another upside: Skills follow an open standard. The same sheet works in Copilot inside VS Code, in Copilot CLI and in the cloud agent — and even with other compatible agents.

When to use it: for a reusable, multi-step know-how, especially if it bundles scripts or resources. “How we deploy”, “how we write an in-house integration test”: those are skills.

4. Agents — the specialist hats

The analogy: instead of a generalist assistant, you summon the right specialist: the nitpicky reviewer, the architect, the docs writer. Each one has its own character, its allowed tools and its way of working.

Concretely: a custom agent is a *.agent.md file (under .github/agents/) that defines a persona: its role, its instructions, the tools it’s allowed to use, and even the model to run.

---
name: reviewer
description: Senior code reviewer, demanding about security and tests.
tools: ['search', 'edit']
model: claude-sonnet-5
---
You are a senior reviewer. Focus on:
bugs, security flaws, edge cases and missing tests.
Be direct, propose concrete fixes, don't reword code that's already fine.

You then switch to that agent in one click, instead of re-explaining its role in every conversation. It’s also the principle behind the coding agent, which you can outright assign a GitHub issue to: it works autonomously and opens a Pull Request.

⚙️ Loaded when: when you activate the agent (selecting it in the UI, an @mention, or assigning it an issue for the coding agent).

What enters the context: its instructions become the active system prompt; its tools list restricts which tools the harness exposes; its model picks the model. An agent doesn’t just add text: it reconfigures the session.

When to use it: when you want a specialized, recurring role, with its own tools and guardrails. If you juggle between “dev hat” and “review hat”, make two agents.

5. MCP — the access badges to the outside world

The analogy: so far, your assistant only knows your code. MCP is the badges and sockets that plug it into the rest of your ecosystem: the database, Jira, your monitoring, a browser, your CRM…

Concretely: the Model Context Protocol is an open standard for connecting an AI agent to external tools and data. You declare MCP servers in an mcp.json file (in .vscode/mcp.json for a project):

{
  "servers": {
    "github": {
      "type": "http",
      "url": "https://api.githubcopilot.com/mcp"
    },
    "playwright": {
      "command": "npx",
      "args": ["-y", "@microsoft/mcp-server-playwright"]
    }
  }
}

Once plugged in, Copilot can read your GitHub issues, drive a browser, query a database… depending on the tools the server exposes.

⚙️ Loaded when: as soon as a server is enabled, the harness loads the descriptions of the tools it exposes (name, role, input schema) — even if you never call them. The results, on the other hand, only arrive when a tool is actually called.

What enters the context: the tool definitions (permanently, as long as the server is active) then the call results (on demand). A very concrete consequence: too many MCP servers means a context cluttered by schemas alone. Hence the value of disabling the ones you don’t use.

Mind the access badge: an MCP server is third-party code you’re handing the keys to. VS Code asks you to confirm your trust before starting it, and lets you sandbox local servers (restricted file/network access). Only plug in what you know — I already wrote about this in my article on securing MCP servers.

When to use it: whenever Copilot needs data or actions that live outside your code. For anything that’s purely “project knowledge and conventions”, Instructions and Skills are enough.

The recap table: when to use what — and when it’s loaded?

Element	It’s for…	Where it lives	Loaded into the context	When to use it
Custom Instructions	Permanent project context and conventions	`.github/copilot-instructions.md`, `*.instructions.md`	Always — full text, on every request	As soon as you repeat the same rules
`AGENTS.md`	The same guidance, but for every agent	`AGENTS.md` (root + subfolders)	Always — the nearest file wins	You use several agents, not just Copilot
Prompts	Replaying a recurring prompt as a `/command`	`*.prompt.md` in `.github/prompts/`	On manual invocation only	A simple, personal shortcut, no script
Skills	A multi-step know-how (+ scripts)	`SKILL.md` folder in `.github/skills/`	On demand — name + description, then the rest	A reusable procedure (“how we deploy”)
Agents	A dedicated role, with its own tools and model	`*.agent.md` in `.github/agents/`	On activation — becomes the system prompt	A recurring profile (reviewer, architect…)
MCP	Plugging Copilot into external tools/data	`mcp.json` (e.g. `.vscode/mcp.json`)	Schemas on enable, results on call	Need to act outside the code (DB, Jira, browser…)

🎁 The starter tip: have the assistant write its own welcome handbook

Sold on AGENTS.md, but stuck on the blank page? Good news: there’s a skill whose only job is to generate your AGENTS.md. Yes, you read that right — you use a know-how sheet (mechanism #3) to produce the welcome handbook (mechanism #1). It’s a bit of inception, and above all it’s self-teaching: the assistant explores your repository and writes, by itself, the document that will serve as its memory in every session.

The skill is called create-agentsmd and comes from GitHub’s official awesome-copilot repository. One command is all it takes:

npx skills add https://github.com/github/awesome-copilot --skill create-agentsmd

Then simply ask Copilot to “create the AGENTS.md for the project”: the skill kicks in, analyzes your repository (stack, build commands, how to run the tests, conventions, structure — monorepos included) and produces an AGENTS.md that follows the open standard, ready to be reviewed and committed.

And that’s where the loop closes: on the next start, your amnesiac hire reads the handbook it wrote itself the day before. Review it, fix what’s missing, commit it — and you’ve just taken the first concrete step to help your agent keep its context from one session to the next.

The simple rule to remember

If you only take away one thing: start with Instructions, add the rest only when a need keeps coming back.

Repeating rules? → Instructions (or AGENTS.md if several agents).
Repeating a prompt? → Prompt file.
Repeating a procedure? → Skill.
Repeating a role? → Agent.
Repeating a connection to an external tool? → MCP.

And if you take away two things, add the context reflex: whatever is “always loaded” (Instructions, AGENTS.md, MCP schemas) must stay lightweight, because you pay for it on every request; whatever is “on demand” (Prompts, Skills, tool results) can be richer, because it only costs you when it’s actually used.

See the logic? Every time you hear yourself say “I already explained this last week…”, that’s the signal that one of these mechanisms is waiting to be used.

And that, when you get down to it… is not rocket science.

Le « harnais » de l'IA : comment un modèle devient un agent — c'est pas sorcier !

Wed, 01 Jul 2026 12:00:00 +0200

Tout le monde parle du « modèle » : GPT, Claude, Gemini… Comme si toute la magie tenait dans le cerveau. Pourtant, un modèle tout seul ne sait rien faire : il ne voit pas votre code, ne lance aucune commande, oublie tout d’une phrase à l’autre. Ce qui transforme ce cerveau en véritable agent, c’est une pièce dont on parle beaucoup moins : le harnais (le harness).

Alors on va ouvrir le capot et regarder cette mécanique de près. Et vous allez voir : c’est pas sorcier.

Le fil rouge : un cheval de trait surpuissant

Imaginez un cheval de trait d’exception. Une force brute phénoménale. Mais lâché seul dans un pré, cette puissance ne laboure aucun champ et ne tire aucune charrette. Elle tourne en rond.

Pour en faire un travail utile, il faut un harnais : les œillères qui canalisent l’attention, les rênes qui donnent la direction, et l’attelage qui relie enfin le cheval à la charrue.

Un modèle d’IA, c’est exactement ce cheval. Le harnais, c’est tout le logiciel qu’on met autour pour transformer sa puissance brute en actions concrètes : lire un fichier, modifier du code, lancer un test, appeler un outil. Le mot n’est pas de moi — c’est le terme que tout le milieu utilise. GitHub Copilot, Claude Code, Cursor… ce sont des harnais. Le modèle est interchangeable ; le harnais, lui, fait toute la différence entre un joli chatbot et un collègue qui abat le travail.

D’abord, un modèle tout seul : que sait-il faire ?

Réponse honnête : du texte, et rien d’autre.

Un grand modèle de langage (LLM), c’est une fonction. Vous lui donnez du texte en entrée, il vous rend du texte en sortie. C’est prodigieux… mais c’est tout. En l’état, il souffre de trois handicaps :

Il est aveugle et manchot. Il ne peut ni ouvrir un fichier, ni exécuter une commande. Il ne peut que décrire ce qu’il ferait.
Il est amnésique. À chaque appel, il repart de zéro. Il n’a aucun souvenir de la phrase précédente, sauf si on la lui redonne à chaque fois.
Il ne fait qu’un pas. Une question, une réponse. Il ne sait pas enchaîner « je regarde → je corrige → je vérifie ».

Le harnais est là pour compenser ces trois handicaps. Regardons ses pièces une par une.

L’anatomie d’un harnais, pièce par pièce

1. La boucle agentique — le cœur qui bat

L’analogie : c’est le contremaître qui fait tourner le chantier. Il transmet une consigne au cheval, regarde le résultat, décide de la suite, recommence — jusqu’à ce que le travail soit fait.

C’est la pièce maîtresse. Un chatbot classique fait un aller-retour : question → réponse, terminé. Un agent, lui, boucle :

Le harnais envoie au modèle tout le contexte connu.
Le modèle répond… mais au lieu d’une simple phrase, il peut demander : « lance tel outil ».
Le harnais exécute l’outil et réinjecte le résultat dans la conversation.
On recommence — jusqu’à ce que le modèle déclare : « c’est bon, j’ai fini ».

Cette boucle « penser → agir → observer → recommencer », c’est ce qui transforme une réponse unique en une suite d’actions autonome. Sans elle, pas d’agent.

2. Les outils — les mains et les yeux

L’analogie : on donne enfin au cerveau des mains pour agir et des yeux pour voir.

Un outil, c’est une fonction que le harnais met à disposition du modèle, avec une description précise : son nom, ce qu’elle fait, les paramètres attendus. Par exemple :

read_file(chemin) — lire un fichier,
edit(chemin, modif) — modifier du code,
run_terminal(commande) — lancer une commande,
search(requête) — chercher dans le projet.

Le modèle ne fait pas l’action lui-même : il demande au harnais de la faire, sous forme d’un petit message structuré (« appelle run_terminal avec dotnet test »). Le harnais l’exécute pour de vrai et lui rapporte le résultat. C’est la différence entre un modèle qui raconte qu’il lancerait les tests… et un agent qui les lance vraiment.

3. Les consignes système — le règlement affiché au mur

L’analogie : le règlement intérieur que le cheval « lit » avant chaque tâche. Qui il est, comment il travaille, ce qu’il a le droit de faire.

Le system prompt est un bloc de texte que le harnais place en tête de chaque conversation, avant même votre demande. Il définit la personnalité de l’agent, ses règles, le catalogue d’outils disponibles, le format attendu. C’est invisible pour vous, mais c’est ce qui fait qu’un même modèle se comporte en « assistant de code prudent » plutôt qu’en poète bavard.

4. La gestion du contexte — un bureau trop petit

L’analogie : le modèle travaille sur un bureau minuscule. Impossible d’y étaler tout le projet à la fois. Le harnais est le documentaliste qui choisit quelles feuilles poser sur le bureau à chaque instant.

Le modèle a une fenêtre de contexte limitée : une quantité maximale de texte qu’il peut « voir » d’un coup. Un vrai projet n’y tient jamais entièrement. Le harnais doit donc :

sélectionner ce qui est pertinent (les bons fichiers, les bons extraits) ;
résumer ou compacter l’historique quand la conversation devient trop longue ;
jeter ce qui ne sert plus.

C’est un art délicat : trop peu de contexte, le modèle travaille à l’aveugle ; trop de contexte, il se noie et coûte cher. La qualité d’un harnais se joue beaucoup ici.

5. Les garde-fous — le frein à main

L’analogie : on ne laisse pas le cheval partir au galop vers la falaise. Il y a des rênes, un frein, et parfois un enclos.

Un agent qui peut lancer des commandes et modifier des fichiers, c’est puissant… et potentiellement dangereux. Le harnais ajoute des garde-fous :

la confirmation : demander votre feu vert avant une action sensible (supprimer, exécuter, pousser) ;
les listes d’autorisation : dotnet test passe tout seul, rm -rf demande validation ;
le bac à sable : restreindre l’accès aux fichiers et au réseau.

Sans garde-fous, un agent est une tronçonneuse sans carter. Avec, il devient un outil de chantier sûr.

Et le modèle, dans tout ça ?

Le modèle reste le cheval : la source de puissance. Mais dans un bon harnais, il est interchangeable. Le même harnais peut atteler un GPT, un Claude ou un Gemini, selon la tâche, le budget ou vos préférences. La force change ; l’attelage reste.

Deep-dive : le harnais à l’œuvre dans GitHub Copilot

Assez de théorie. Ouvrons un vrai harnais et regardons ses rouages. GitHub Copilot est un excellent cas d’école, parce qu’il expose toutes les pièces qu’on vient de décrire — et qu’il les décline en plusieurs « carrosseries ».

Le cerveau interchangeable : le sélecteur de modèle

Copilot n’est pas marié à un seul modèle. Un sélecteur vous laisse choisir la monture : les modèles d’OpenAI (famille GPT et modèles de raisonnement), d’Anthropic (Claude Sonnet, Claude Opus), de Google (Gemini)… Le harnais, lui, ne change pas : c’est toujours la même boucle, les mêmes outils. Vous changez seulement le cheval sous le harnais — un modèle rapide pour les petites tâches, un modèle de raisonnement pour les gros morceaux. Quant à savoir quel cheval atteler, c’est justement le sujet de mon article sur le choix du modèle.

Le mode agent : la boucle en action

Le mode agent de Copilot (dans VS Code, Visual Studio ou JetBrains), c’est la boucle agentique à l’état pur. Vous donnez un objectif de haut niveau ; l’agent planifie, modifie plusieurs fichiers, lance des commandes au terminal, lit les erreurs, se corrige, et recommence jusqu’à atteindre le but. Il ne s’arrête pas à la première réponse : il itère.

Voici à quoi ressemble, de l’intérieur, un seul objectif qui déroule la boucle :

Vous : « Ajoute un endpoint /health et son test. »

┌─ Tour 1
│  🧠 Modèle : je dois d'abord comprendre la structure.
│  🔧 Outil  : search("Program.cs")            → 1 résultat
├─ Tour 2
│  🧠 Modèle : j'ajoute la route de santé.
│  🔧 Outil  : edit(Program.cs, +8 lignes)
├─ Tour 3
│  🧠 Modèle : j'écris le test associé.
│  🔧 Outil  : edit(HealthTests.cs, nouveau fichier)
├─ Tour 4
│  🧠 Modèle : je vérifie que tout passe.
│  🔧 Outil  : runInTerminal("dotnet test")     → ❌ 1 échec
├─ Tour 5
│  🧠 Modèle : un `using` manque, je corrige.
│  🔧 Outil  : edit(HealthTests.cs, +1 ligne)
│  🔧 Outil  : runInTerminal("dotnet test")     → ✅ 12 réussis
└─ ✅ Terminé.

Regardez le tour 4 → tour 5 : l’agent lance les tests, voit un échec, comprend la cause et se corrige tout seul. Cette capacité à observer un résultat et rebondir, c’est toute la valeur de la boucle. Un simple assistant se serait arrêté au tour 3 en disant « voici le code, à vous de tester ».

Les outils intégrés — les mains de Copilot

En mode agent, Copilot dispose d’une trousse d’outils prêts à l’emploi. Sans être exhaustif :

explorer et chercher dans le code (l’index du workspace) ;
lire et éditer des fichiers, sur plusieurs endroits à la fois ;
lancer des commandes au terminal ;
exécuter les tests et lire les erreurs (les problems) ;
aller chercher une page web pour une doc externe.

Et surtout, cette trousse est extensible via MCP (Model Context Protocol) : vous branchez vos propres outils maison — base de données, Jira, monitoring, navigateur… — et ils viennent s’ajouter au catalogue que le modèle peut appeler. Le harnais ne se limite plus à votre code : il touche tout votre écosystème.

Comment Copilot remplit le bureau — le contexte

Souvenez-vous du bureau trop petit. Copilot le garnit de plusieurs façons :

automatiquement : les fichiers ouverts, la sélection courante, un index du dépôt qui permet de retrouver le bon extrait sans tout charger ;
à la demande, quand vous pointez du doigt avec les #-références (#file, #selection, #codebase…) ou les @-participants (@workspace, @terminal) ;
en permanence, via vos fichiers d’instructions (.github/copilot-instructions.md), qui rappellent à chaque tour vos conventions.

C’est précisément le rôle du documentaliste : décider ce qui mérite une place sur le bureau. Et c’est là que vos personnalisations entrent en jeu — un sujet que j’ai détaillé dans Skills, Instructions, Agents, MCP… c’est pas sorcier !. Ces fichiers ne sont, au fond, que des manières de mieux garnir le harnais.

Les garde-fous — Copilot ne part pas au galop

Copilot applique tous les freins qu’on a vus. Avant de lancer une commande au terminal, il demande confirmation. Vous pouvez définir des listes d’autorisation (les commandes de confiance passent sans interruption, les autres non) et bac-à-sabler les serveurs MCP locaux pour restreindre leurs accès. Le principe : l’agent propose, mais vous gardez la main sur ce qui touche vraiment à votre machine.

Un seul harnais, trois carrosseries

Le point le plus élégant : c’est la même mécanique qui se décline sous trois formes, selon l’endroit où vous travaillez.

Carrosserie	Où ça tourne	Pour quoi faire
Dans l’IDE	VS Code, Visual Studio, JetBrains	Complétion, chat et mode agent, à côté de votre code
En ligne de commande	Copilot CLI, dans le terminal	Piloter l’agent au clavier, sans quitter le shell
Dans le cloud	Coding agent, sur GitHub Actions	On lui assigne une issue : il travaille seul et ouvre une Pull Request

Le coding agent est le plus spectaculaire : vous lui confiez un ticket GitHub, il démarre un environnement éphémère, déroule exactement la même boucle « penser → agir → observer », et vous livre une PR à relire. Même harnais, même boucle, même outils — simplement débranché de votre écran et rebranché sur un serveur.

Le récap : les pièces du harnais

Pièce	L’image	Son rôle
La boucle	Le contremaître	Enchaîner penser → agir → observer jusqu’au but
Les outils	Les mains et les yeux	Lire, éditer, exécuter, chercher — agir pour de vrai
Les consignes	Le règlement au mur	Définir qui est l’agent et ses règles
Le contexte	Le documentaliste	Choisir quoi poser sur un bureau trop petit
Les garde-fous	Le frein à main	Confirmer, autoriser, mettre en bac à sable
Le modèle	Le cheval de trait	La puissance brute — interchangeable

La morale de l’histoire

La prochaine fois qu’on vous vantera « le nouveau modèle qui change tout », rappelez-vous du cheval de trait. La puissance brute compte, bien sûr. Mais ce qui transforme cette puissance en travail réel — lire, corriger, tester, livrer — c’est le harnais.

Et comprendre le harnais, ça change votre regard : quand vous ajoutez des instructions, une skill, un agent ou un serveur MCP, vous n’êtes pas en train de « configurer un chatbot ». Vous êtes en train d’ajuster l’attelage pour que le cheval tire droit.

Vous voyez la mécanique, maintenant ? Le cerveau, la boucle, les outils, le contexte, les freins…

Et ça, mine de rien… c’est pas sorcier.

The AI "harness": how a model becomes an agent — it's not rocket science!

Wed, 01 Jul 2026 12:00:00 +0200

Everyone talks about “the model”: GPT, Claude, Gemini… as if all the magic lived in the brain. Yet a model on its own can’t do anything: it can’t see your code, it can’t run a command, it forgets everything from one sentence to the next. What turns that brain into a real agent is a part we talk about far less: the harness.

So let’s pop the hood and look closely at the machinery. And you’ll see: it’s not rocket science.

The through-line: an over-powered draft horse

Picture an exceptional draft horse. Phenomenal raw strength. But turned loose alone in a field, that power ploughs no furrow and pulls no cart. It just goes in circles.

To turn it into useful work, you need a harness: the blinkers that channel its focus, the reins that give it direction, and the hitch that finally connects the horse to the plough.

An AI model is exactly that horse. The harness is all the software we wrap around it to turn its raw power into concrete action: read a file, edit code, run a test, call a tool. The word isn’t mine — it’s the term the whole field uses. GitHub Copilot, Claude Code, Cursor… these are harnesses. The model is swappable; the harness is what separates a pretty chatbot from a colleague who actually gets work done.

First, a model on its own: what can it do?

Honest answer: text, and nothing else.

A large language model (LLM) is a function. You give it text in, it gives you text out. It’s astonishing… but that’s all. As it stands, it suffers from three handicaps:

It’s blind and handless. It can’t open a file or run a command. It can only describe what it would do.
It’s amnesiac. Every call starts from scratch. It has no memory of the previous sentence unless you feed it back in every time.
It takes only one step. One question, one answer. It can’t chain “I look → I fix → I check”.

The harness exists to compensate for those three handicaps. Let’s take its parts one by one.

The anatomy of a harness, part by part

1. The agent loop — the beating heart

The analogy: it’s the foreman running the job site. He hands the horse an instruction, watches the result, decides what’s next, and starts again — until the work is done.

This is the central piece. A classic chatbot does one round trip: question → answer, done. An agent loops:

The harness sends the model all the context it knows.
The model replies… but instead of a plain sentence, it can ask: “run this tool”.
The harness executes the tool and feeds the result back into the conversation.
Repeat — until the model declares: “done, I’ve finished”.

That “think → act → observe → repeat” loop is what turns a single reply into an autonomous sequence of actions. Without it, there is no agent.

2. The tools — the hands and the eyes

The analogy: we finally give the brain hands to act and eyes to see.

A tool is a function the harness exposes to the model, with a precise description: its name, what it does, the expected parameters. For example:

read_file(path) — read a file,
edit(path, change) — modify code,
run_terminal(command) — run a command,
search(query) — search the project.

The model doesn’t perform the action itself: it asks the harness to do it, as a small structured message (“call run_terminal with dotnet test”). The harness runs it for real and reports back the result. That’s the difference between a model that says it would run the tests… and an agent that actually runs them.

3. The system prompt — the house rules on the wall

The analogy: the house rules the horse “reads” before every task. Who it is, how it works, what it’s allowed to do.

The system prompt is a block of text the harness places at the head of every conversation, before your request even starts. It defines the agent’s personality, its rules, the catalogue of available tools, the expected format. It’s invisible to you, but it’s what makes one and the same model behave like a “careful coding assistant” rather than a chatty poet.

4. Context management — a desk that’s too small

The analogy: the model works on a tiny desk. You can’t spread the whole project on it at once. The harness is the librarian who decides which sheets to put on the desk at any given moment.

The model has a limited context window: a maximum amount of text it can “see” at once. A real project never fits entirely. So the harness has to:

select what’s relevant (the right files, the right excerpts);
summarize or compact the history when the conversation grows too long;
discard what’s no longer useful.

It’s a delicate art: too little context and the model works blind; too much and it drowns — and costs a fortune. A harness’s quality is largely decided here.

5. The guardrails — the handbrake

The analogy: you don’t let the horse bolt toward the cliff. There are reins, a brake, and sometimes a fenced paddock.

An agent that can run commands and edit files is powerful… and potentially dangerous. The harness adds guardrails:

confirmation: ask for your go-ahead before a sensitive action (delete, execute, push);
allow-lists: dotnet test goes through on its own, rm -rf needs approval;
sandboxing: restrict access to files and the network.

Without guardrails, an agent is a chainsaw with no guard. With them, it becomes a safe power tool.

And the model, in all this?

The model stays the horse: the source of power. But in a good harness it’s swappable. The same harness can hitch a GPT, a Claude or a Gemini, depending on the task, the budget or your preferences. The strength changes; the hitch stays.

Deep-dive: the harness at work inside GitHub Copilot

Enough theory. Let’s open a real harness and look at its gears. GitHub Copilot is a great case study, because it exposes every part we just described — and offers them in several “body shapes”.

The swappable brain: the model picker

Copilot isn’t married to a single model. A picker lets you choose your mount: OpenAI’s models (the GPT family and reasoning models), Anthropic’s (Claude Sonnet, Claude Opus), Google’s (Gemini)… The harness itself doesn’t change: it’s always the same loop, the same tools. You’re only swapping the horse under the harness — a fast model for small chores, a reasoning model for the heavy lifting. As for which horse to hitch, that’s exactly the topic of my article on choosing the model.

Agent mode: the loop in action

Copilot’s agent mode (in VS Code, Visual Studio or JetBrains) is the agent loop in its purest form. You give a high-level goal; the agent plans, edits multiple files, runs terminal commands, reads the errors, corrects itself, and starts over until it reaches the goal. It doesn’t stop at the first answer: it iterates.

Here’s what a single goal looks like from the inside as it unspools the loop:

You: "Add a /health endpoint and its test."

┌─ Turn 1
│  🧠 Model : first I need to understand the structure.
│  🔧 Tool  : search("Program.cs")            → 1 result
├─ Turn 2
│  🧠 Model : I add the health route.
│  🔧 Tool  : edit(Program.cs, +8 lines)
├─ Turn 3
│  🧠 Model : I write the matching test.
│  🔧 Tool  : edit(HealthTests.cs, new file)
├─ Turn 4
│  🧠 Model : I check that everything passes.
│  🔧 Tool  : runInTerminal("dotnet test")     → ❌ 1 failed
├─ Turn 5
│  🧠 Model : a `using` is missing, I fix it.
│  🔧 Tool  : edit(HealthTests.cs, +1 line)
│  🔧 Tool  : runInTerminal("dotnet test")     → ✅ 12 passed
└─ ✅ Done.

Look at turn 4 → turn 5: the agent runs the tests, sees a failure, understands the cause and fixes it on its own. That ability to observe a result and bounce back is the whole value of the loop. A plain assistant would have stopped at turn 3 with “here’s the code, test it yourself”.

The built-in tools — Copilot’s hands

In agent mode, Copilot ships with a ready-made toolkit. Without being exhaustive:

explore and search the code (the workspace index);
read and edit files, in several places at once;
run commands in the terminal;
run the tests and read the errors (the problems);
fetch a web page for external docs.

And above all, this toolkit is extensible via MCP (Model Context Protocol): you plug in your own in-house tools — database, Jira, monitoring, browser… — and they join the catalogue the model can call. The harness is no longer limited to your code: it reaches your whole ecosystem.

How Copilot fills the desk — context

Remember the too-small desk. Copilot furnishes it in several ways:

automatically: the open files, the current selection, a repository index that lets it retrieve the right excerpt without loading everything;
on demand, when you point at things with #-references (#file, #selection, #codebase…) or @-participants (@workspace, @terminal);
permanently, via your instructions files (.github/copilot-instructions.md), which restate your conventions on every turn.

That’s exactly the librarian’s job: deciding what deserves a spot on the desk. And this is where your customizations come in — a topic I covered in detail in Skills, Instructions, Agents, MCP… it’s not rocket science!. Those files are, at heart, just better ways to pack the harness.

The guardrails — Copilot doesn’t bolt off

Copilot applies every brake we’ve seen. Before running a terminal command, it asks for confirmation. You can define allow-lists (trusted commands go through without interruption, the rest don’t) and sandbox local MCP servers to restrict their access. The principle: the agent proposes, but you keep control of anything that really touches your machine.

One harness, three body shapes

The most elegant part: it’s the same machinery offered in three forms, depending on where you work.

Body shape	Where it runs	What it’s for
In the IDE	VS Code, Visual Studio, JetBrains	Completion, chat and agent mode, right next to your code
On the command line	Copilot CLI, in the terminal	Drive the agent from the keyboard, without leaving the shell
In the cloud	Coding agent, on GitHub Actions	You assign it an issue: it works alone and opens a Pull Request

The coding agent is the most spectacular: you hand it a GitHub ticket, it spins up an ephemeral environment, runs the exact same “think → act → observe” loop, and delivers a PR for you to review. Same harness, same loop, same tools — simply unplugged from your screen and plugged into a server.

The recap: the parts of the harness

Part	The image	Its role
The loop	The foreman	Chain think → act → observe until the goal
The tools	The hands and eyes	Read, edit, execute, search — act for real
The system prompt	The rules on the wall	Define who the agent is and its rules
The context	The librarian	Choose what to put on a too-small desk
The guardrails	The handbrake	Confirm, allow-list, sandbox
The model	The draft horse	The raw power — swappable

The moral of the story

Next time someone sells you “the new model that changes everything”, remember the draft horse. Raw power matters, of course. But what turns that power into real work — reading, fixing, testing, shipping — is the harness.

And understanding the harness changes how you see things: when you add instructions, a skill, an agent or an MCP server, you’re not “configuring a chatbot”. You’re adjusting the hitch so the horse pulls straight.

See the machinery now? The brain, the loop, the tools, the context, the brakes…

And that, when you get down to it… is not rocket science.

GPT, Claude, Gemini… quel modèle choisir dans GitHub Copilot ? C'est pas sorcier !

Thu, 25 Jun 2026 12:00:00 +0200

Vous ouvrez le sélecteur de modèles de GitHub Copilot et vous tombez sur une carte des vins : GPT-5.5, Claude Opus 4.8, Gemini 3.5 Flash, Haiku, Sonnet, mini, nano, Codex… Lequel prendre ? Le plus récent ? Le plus cher ? Celui avec le plus grand numéro ?

Spoiler : la question « quel est le meilleur modèle ? » est mal posée. La bonne question, c’est « le meilleur pour quoi faire ? ». On va démonter la mécanique — pourquoi un modèle n’est pas l’autre — puis je vous donne une méthode toute simple pour trouver le vôtre, chiffres à l’appui. Et vous allez voir : c’est pas sorcier.

Le fil rouge : personne ne demande « quel est le meilleur véhicule ? »

Imaginez la question posée dans un garage : « quel est le meilleur véhicule ? » Le vendeur vous regarderait bizarrement. Le meilleur… pour quoi ? Aller chercher le pain ? La citadine. Déménager un piano ? Le camion. Rouler tous les jours ? La berline polyvalente.

Un modèle d’IA, c’est un véhicule. Il y a des citadines nerveuses, des berlines fiables, des semi-remorques capables de tracter l’impossible — mais lents et gourmands. Et comme au garage, tout se joue sur une poignée de caractéristiques mesurables. Regardons lesquelles.

Pourquoi un modèle n’est pas l’autre : les 5 différences qui comptent

1. La cylindrée — la taille du modèle

Un modèle, c’est un moteur fait de milliards de « réglages » internes (les paramètres). Plus il y en a, plus le modèle capte de nuances… mais plus chaque mot généré coûte du calcul. C’est physique : chaque mot de la réponse doit traverser tout le moteur.

D’où les gammes que vous voyez partout : nano, mini, Flash, Haiku d’un côté (petites cylindrées, réponses quasi instantanées), Opus ou les gros GPT de l’autre (grosses cylindrées, plus futées mais plus lentes et plus chères).

2. Le vécu du conducteur — l’entraînement

Deux véhicules identiques ne se conduisent pas pareil selon qui est au volant. Deux modèles de taille comparable ne « pensent » pas pareil non plus : tout dépend de ce qu’on leur a appris, et de comment.

C’est pour ça que certains modèles du sélecteur sont des spécialistes du code : GPT-5.3-Codex, Raptor mini (un GPT-5 mini ré-entraîné spécialement pour la complétion), Kimi-K2.7-Code… À taille égale, un modèle spécialisé bat souvent un généraliste sur son terrain. Comme un chauffeur-livreur connaît mieux les ruelles qu’un pilote de F1.

3. L’arrêt carte routière — le raisonnement

Certains modèles répondent au fil de la plume. D’autres — les modèles « de raisonnement » — s’arrêtent d’abord sur le bas-côté pour étudier la carte : ils produisent un brouillon interne, explorent des pistes, se corrigent, puis seulement répondent.

Sur un problème retors (un bug vicieux, une architecture à repenser), cet arrêt change tout. Pour renommer une variable ? C’est payer un détour d’autoroute pour aller au bout de la rue. Le raisonnement est un super-pouvoir facturé : du temps et des tokens en plus.

4. La taille du coffre — la fenêtre de contexte

Chaque modèle a une limite de texte qu’il peut « voir » d’un coup : sa fenêtre de contexte. Petite fenêtre : quelques fichiers. Grande fenêtre : certains modèles montent aujourd’hui à un million de tokens (dans VS Code et Copilot CLI), de quoi embarquer une grosse partie du projet.

Mais attention au réflexe « plus grand = mieux » : un grand coffre ne sert que si vous avez des bagages. Pour une question de syntaxe, il ne vous apporte rien — et le remplir coûte de l’argent, on y vient.

5. La consommation — le coût

Depuis le 1ᵉʳ juin 2026, Copilot est passé à la facturation à l’usage : chaque échange consomme des AI Credits (1 crédit = 0,01 $) selon les tokens envoyés au modèle, générés par lui, et mis en cache. Trois choses à savoir, ordres de grandeur au moment où j’écris (tarifs officiels) :

L’écart entre gammes est énorme : ~0,20 à 0,50 $ le million de tokens d’entrée pour les légers, ~2 à 2,50 $ pour les polyvalents, 4 à 10 $ pour les puissants. Du simple au vingtuple.
La sortie coûte 4 à 10× plus cher que l’entrée : un modèle bavard se paie.
Le cache réduit l’entrée d’environ 90 % : rester dans la même conversation bien contextée coûte moins cher que tout renvoyer à chaque fois.

Un exemple pour fixer les idées : un aller-retour qui envoie ~50 000 tokens de contexte et en génère 5 000 coûte grosso modo 2 crédits sur une citadine… et 40 à 50 sur un semi-remorque. Même conversation, facture ×20. Voilà pourquoi « je mets le plus gros modèle partout » est une stratégie de millionnaire.

Le parking Copilot en juin 2026

Voici la gamme actuelle, rangée par vocation. La liste bouge tous les mois (des nouveaux comme Claude Fable 5 arrivent, d’autres partent à la retraite) : la référence reste la liste officielle et le comparatif officiel.

La gamme	Les modèles (extraits)	Taillés pour
Les citadines — légers, vifs, sobres	Claude Haiku 4.5, Gemini 3.5 Flash, GPT-5 mini / 5.4 nano	Questions rapides, petites retouches, prototypage léger
Les berlines — les polyvalents du quotidien	Claude Sonnet 5 (et 4.6), GPT-5.4, MAI-Code-1-Flash	Le gros du travail : coder, expliquer, tester
Les semi-remorques — raisonnement profond	Claude Opus 4.8, GPT-5.5, Gemini 3.1 Pro	Refactorings multi-fichiers, debug retors, décisions d’architecture
Les utilitaires spécialisés — fine-tunés code	GPT-5.3-Codex, Raptor mini, Kimi-K2.7-Code	Tâches d’ingénierie pures, complétion affûtée

Bonus : certains modèles acceptent aussi les images (GPT-5 mini, Claude Sonnet 4.6, Gemini 3.1 Pro) — pratique pour partir d’une capture d’écran ou d’une maquette.

Le banc d’essai maison : trouvez VOTRE modèle en une heure

Les classements publics ne répondent pas à la seule question qui compte : le meilleur pour vos tâches à vous, votre codebase, vos habitudes. La bonne nouvelle : faire votre propre essai routier est à la portée de tout le monde. Cinq étapes.

Étape 1 — Choisissez vos 3 trajets types

Prenez trois tâches réelles et récentes de votre quotidien — pas des exercices inventés. Par exemple :

une course : corriger un test cassé, écrire une petite fonction ;
un trajet quotidien : ajouter une fonctionnalité de taille moyenne ;
un déménagement : un refactoring multi-fichiers ou une question d’architecture.

Étape 2 — Sélectionnez 3 candidats

Un par gamme suffit pour commencer : une citadine, une berline, un semi-remorque. Inutile de tester douze modèles — vous comparez des gammes, pas des étiquettes.

Étape 3 — Roulez proprement

C’est l’étape que tout le monde rate. Pour que la comparaison vaille quelque chose :

même prompt, copié-collé à l’identique ;
même contexte (mêmes fichiers ouverts, mêmes #-références) ;
conversation neuve à chaque essai — un historique pollué fausse tout ;
deux passages par modèle : une seule réponse ne prouve rien, les modèles ont de la variance.

Étape 4 — Notez sur une grille

Quatre colonnes, pas plus :

Qualité (le résultat est-il juste, complet, idiomatique ?) — sur 5 ;
Allers-retours nécessaires avant un résultat acceptable ;
Temps ressenti ;
Crédits consommés (visibles sur la page d’usage de votre compte GitHub).

Voici à quoi ça peut ressembler — chiffres fictifs, pour l’exemple :

Tâche	Citadine (Haiku 4.5)	Berline (Sonnet 5)	Semi (Opus 4.8)
Corriger un test cassé	4/5 · 1 échange · ~2 crédits	5/5 · 1 échange · ~8 crédits	5/5 · 1 échange · ~40 crédits
Ajouter une fonctionnalité	2/5 · 4 échanges · ~10 crédits	4/5 · 2 échanges · ~20 crédits	5/5 · 1 échange · ~45 crédits
Question d’architecture	1/5 · abandonné	3/5 · 3 échanges · ~30 crédits	5/5 · 1 échange · ~60 crédits

Étape 5 — Le verdict… par type de tâche

Lisez la grille ligne par ligne, jamais en score global. Dans l’exemple ci-dessus, le verdict n’est pas « Opus gagne » : c’est « Haiku suffit largement pour les courses (20× moins cher !), Sonnet est ma berline, et Opus vaut chaque centime sur l’architecture — et uniquement là ».

Refaites l’exercice tous les deux ou trois mois : les modèles changent vite, votre classement aussi.

Les 4 pièges du comparateur amateur

L’effet démo. Une réponse assurée et bien rédigée n’est pas une réponse juste. Vérifiez le fond (lancez les tests !), pas le style.
Le jugement sur un seul essai. La variance existe. Deux passages minimum avant de conclure.
L’historique qui triche. Si le modèle B passe après le modèle A dans la même conversation, il hérite de ses indices. Conversation neuve, toujours.
Oublier la colonne coût. Une réponse 5 % meilleure pour 20× le prix, c’est rarement une bonne affaire — sauf le jour du déménagement.

La règle simple à retenir

Par défaut : la berline. Un polyvalent couvre 80 % de vos journées.
Pour les courses : la citadine. Question rapide, petite retouche → modèle léger, réponse immédiate, coût dérisoire.
Quand ça coince : le semi-remorque. Deux allers-retours sans progrès sur un problème complexe ? Montez en gamme, posez le problème une bonne fois. Puis redescendez.
Si votre quotidien est du code pur : essayez un utilitaire spécialisé.

Et surtout : ne croyez ni les benchmarks, ni les influenceurs, ni moi. Croyez votre grille. Trois tâches, trois modèles, une heure d’essai routier — c’est tout ce qu’il faut pour savoir ce qui roule le mieux chez vous.

Un modèle n’est pas l’autre : pas parce que le marketing le dit, mais parce que la cylindrée, l’entraînement, le raisonnement, le coffre et la consommation diffèrent — et maintenant, vous savez lire la fiche technique.

Et ça, mine de rien… c’est pas sorcier.

GPT, Claude, Gemini… which model should you pick in GitHub Copilot? It's not rocket science!

Thu, 25 Jun 2026 12:00:00 +0200

You open GitHub Copilot’s model picker and land on a wine list: GPT-5.5, Claude Opus 4.8, Gemini 3.5 Flash, Haiku, Sonnet, mini, nano, Codex… Which one do you take? The newest? The priciest? The one with the biggest number?

Spoiler: the question “which model is the best?” is the wrong question. The right one is “the best for what?”. We’re going to take the machinery apart — why one model is not another — and then I’ll give you a dead-simple method to find yours, numbers included. And you’ll see: it’s not rocket science.

The through-line: nobody asks “what’s the best vehicle?”

Picture the question asked at a car dealership: “what’s the best vehicle?” The salesman would give you a strange look. The best… for what? Picking up bread? The city car. Moving a piano? The truck. Daily commuting? The all-round sedan.

An AI model is a vehicle. There are nimble city cars, dependable sedans, and semi-trailers that can tow the impossible — but slow and thirsty. And just like at the dealership, everything comes down to a handful of measurable characteristics. Let’s look at them.

Why one model is not another: the 5 differences that matter

1. Engine size — the model’s size

A model is an engine made of billions of internal “dials” (the parameters). More dials means the model picks up more nuance… but every generated word costs more compute. It’s physics: each word of the answer has to travel through the whole engine.

Hence the ranges you see everywhere: nano, mini, Flash, Haiku on one side (small engines, near-instant answers), Opus and the big GPTs on the other (big engines, smarter but slower and pricier).

2. The driver’s experience — the training

Two identical vehicles don’t drive the same depending on who’s behind the wheel. Two models of comparable size don’t “think” the same either: it all depends on what they were taught, and how.

That’s why some models in the picker are code specialists: GPT-5.3-Codex, Raptor mini (a GPT-5 mini re-trained specifically for completion), Kimi-K2.7-Code… At equal size, a specialist often beats a generalist on its home turf. Just like a delivery driver knows the back alleys better than an F1 pilot.

3. The roadmap stop — reasoning

Some models answer straight off the pen. Others — the “reasoning” models — pull over first to study the map: they produce an internal draft, explore leads, correct themselves, and only then answer.

On a thorny problem (a vicious bug, an architecture to rethink), that stop changes everything. To rename a variable? It’s paying a highway detour to reach the end of your street. Reasoning is a billed super-power: extra time and extra tokens.

4. Trunk size — the context window

Every model has a limit on the text it can “see” at once: its context window. Small window: a few files. Large window: some models now reach one million tokens (in VS Code and Copilot CLI), enough to carry a big chunk of the project.

But beware the “bigger = better” reflex: a big trunk only helps if you have luggage. For a syntax question it brings you nothing — and filling it costs money, as we’re about to see.

5. Fuel consumption — the cost

Since June 1, 2026, Copilot has moved to usage-based billing: every exchange consumes AI Credits (1 credit = $0.01) based on the tokens sent to the model, generated by it, and cached. Three things to know, orders of magnitude as I write (official pricing):

The gap between ranges is huge: ~$0.20–0.50 per million input tokens for the light models, ~$2–2.50 for the versatile ones, $4–10 for the powerful ones. A factor of twenty.
Output costs 4–10× more than input: a chatty model comes at a price.
Caching cuts input cost by about 90%: staying in one well-set-up conversation is cheaper than resending everything each time.

One example to make it concrete: a round trip that sends ~50,000 tokens of context and generates 5,000 costs roughly 2 credits on a city car… and 40–50 on a semi-trailer. Same conversation, 20× the bill. That’s why “I’ll just use the biggest model everywhere” is a millionaire’s strategy.

The Copilot parking lot, June 2026

Here is the current lineup, sorted by vocation. The list moves every month (newcomers like Claude Fable 5 arrive, others retire): the reference remains the official list and the official comparison.

The range	The models (excerpt)	Built for
The city cars — light, quick, frugal	Claude Haiku 4.5, Gemini 3.5 Flash, GPT-5 mini / 5.4 nano	Quick questions, small edits, lightweight prototyping
The sedans — the everyday all-rounders	Claude Sonnet 5 (and 4.6), GPT-5.4, MAI-Code-1-Flash	The bulk of the work: coding, explaining, testing
The semi-trailers — deep reasoning	Claude Opus 4.8, GPT-5.5, Gemini 3.1 Pro	Multi-file refactorings, gnarly debugging, architecture decisions
The specialized vans — fine-tuned for code	GPT-5.3-Codex, Raptor mini, Kimi-K2.7-Code	Pure engineering tasks, razor-sharp completion

Bonus: some models also accept images (GPT-5 mini, Claude Sonnet 4.6, Gemini 3.1 Pro) — handy for starting from a screenshot or a mockup.

The home test bench: find YOUR model in an hour

Public leaderboards don’t answer the only question that matters: the best for your own tasks, your codebase, your habits. The good news: running your own road test is within everyone’s reach. Five steps.

Step 1 — Pick your 3 typical trips

Take three real, recent tasks from your daily work — not made-up exercises. For example:

an errand: fix a broken test, write a small function;
a daily commute: add a medium-sized feature;
a house move: a multi-file refactoring or an architecture question.

Step 2 — Select 3 candidates

One per range is enough to start: a city car, a sedan, a semi-trailer. No need to test twelve models — you’re comparing ranges, not badges.

Step 3 — Drive clean

This is the step everyone gets wrong. For the comparison to be worth anything:

same prompt, copy-pasted identically;
same context (same open files, same #-references);
fresh conversation for every run — a polluted history skews everything;
two runs per model: a single answer proves nothing, models have variance.

Step 4 — Score on a grid

Four columns, no more:

Quality (is the result correct, complete, idiomatic?) — out of 5;
Round trips needed to reach an acceptable result;
Time as experienced;
Credits consumed (visible on your GitHub account’s usage page).

Here’s what it can look like — fictional numbers, for the sake of the example:

Task	City car (Haiku 4.5)	Sedan (Sonnet 5)	Semi (Opus 4.8)
Fix a broken test	4/5 · 1 exchange · ~2 credits	5/5 · 1 exchange · ~8 credits	5/5 · 1 exchange · ~40 credits
Add a feature	2/5 · 4 exchanges · ~10 credits	4/5 · 2 exchanges · ~20 credits	5/5 · 1 exchange · ~45 credits
Architecture question	1/5 · gave up	3/5 · 3 exchanges · ~30 credits	5/5 · 1 exchange · ~60 credits

Step 5 — The verdict… per task type

Read the grid row by row, never as a global score. In the example above, the verdict is not “Opus wins”: it’s “Haiku is plenty for errands (20× cheaper!), Sonnet is my sedan, and Opus is worth every cent on architecture — and only there”.

Redo the exercise every two or three months: models change fast, and so will your ranking.

The 4 traps of the amateur comparer

The demo effect. A confident, well-written answer is not a correct answer. Check the substance (run the tests!), not the style.
Judging on a single run. Variance is real. Two runs minimum before concluding.
The cheating history. If model B runs after model A in the same conversation, it inherits its clues. Fresh conversation, always.
Forgetting the cost column. An answer that’s 5% better for 20× the price is rarely a good deal — except on moving day.

The simple rule to remember

By default: the sedan. An all-rounder covers 80% of your days.
For errands: the city car. Quick question, small edit → light model, instant answer, negligible cost.
When you’re stuck: the semi-trailer. Two round trips with no progress on a complex problem? Move up a range, state the problem properly once. Then come back down.
If your daily work is pure code: try a specialized van.

And above all: don’t trust the benchmarks, the influencers, or me. Trust your grid. Three tasks, three models, one hour of road testing — that’s all it takes to know what drives best at your place.

One model is not another: not because marketing says so, but because the engine size, the training, the reasoning, the trunk and the fuel consumption differ — and now you know how to read the spec sheet.

And that, when you get down to it… is not rocket science.

Sense of [AI]

C'est quoi un LLM, vraiment ? (l'IA expliquée simplement)

L’image à garder en tête : une autocomplétion géante

Au fond, ça fait quoi ? Il devine le token suivant

Comment il a « appris » ? L’entraînement

Pourquoi c’est bluffant… et pourquoi ça se trompe

Ce que ça change concrètement pour vous

Le LLM en 5 idées

En résumé

What is an LLM, really? (AI explained simply)

The image to keep in mind: a giant autocomplete

Deep down, what does it do? It guesses the next token

How did it “learn”? Training

Why it’s stunning… and why it gets things wrong

What this changes for you, concretely

The LLM in 5 ideas

In a nutshell

Tokens envoyés, tokens sortis, tokens en cache… c'est pas sorcier !

D’abord : c’est quoi un token ?

Les trois compteurs : envoyés, sortis, en cache

1. Les tokens envoyés (entrée / input)

2. Les tokens de sortie (sortie / output)

3. Les tokens en cache (prompt caching)

Chaque modèle a ses particularités

Son propre hachoir (le tokenizer)

La taille de son bol (le context window)

Le tableau récap

Quelques réflexes pour alléger la facture

En résumé

Input tokens, output tokens, cached tokens… it's not rocket science!

First: what is a token?

The three meters: input, output, cached

1. Input tokens

2. Output tokens

3. Cached tokens (prompt caching)

Every model has its quirks

Its own shredder (the tokenizer)

The size of its bowl (the context window)

The recap table

A few reflexes to trim the bill

In a nutshell

GitHub Copilot : Skills, Instructions, Agents, MCP… c'est pas sorcier !

Le fil rouge : imaginez un nouvel assistant surdoué

Avant de démonter : le frontmatter, l’étiquette sur la fiche

1. Custom Instructions — le livret d’accueil

Le cousin universel : AGENTS.md

2. Prompts — les mémos prêts à l’emploi

3. Skills — les fiches savoir-faire dans le classeur

4. Agents — les casquettes de spécialiste

5. MCP — les badges d’accès vers le monde extérieur

Le tableau récap : quand utiliser quoi — et quand c’est chargé ?

🎁 L’astuce de départ : faites écrire le livret d’accueil… par l’assistant lui-même

La règle simple à retenir

GitHub Copilot: Skills, Instructions, Agents, MCP… it's not rocket science!

The through-line: picture a brilliant new assistant

Before we take it apart: frontmatter, the label on the sheet

1. Custom Instructions — the welcome handbook

The universal cousin: AGENTS.md

2. Prompts — the ready-made memos

3. Skills — the know-how sheets in the binder

4. Agents — the specialist hats

5. MCP — the access badges to the outside world

The recap table: when to use what — and when it’s loaded?

🎁 The starter tip: have the assistant write its own welcome handbook

The simple rule to remember

Le « harnais » de l'IA : comment un modèle devient un agent — c'est pas sorcier !

Le fil rouge : un cheval de trait surpuissant

D’abord, un modèle tout seul : que sait-il faire ?

L’anatomie d’un harnais, pièce par pièce

1. La boucle agentique — le cœur qui bat

2. Les outils — les mains et les yeux

3. Les consignes système — le règlement affiché au mur

4. La gestion du contexte — un bureau trop petit

5. Les garde-fous — le frein à main

Et le modèle, dans tout ça ?

Deep-dive : le harnais à l’œuvre dans GitHub Copilot

Le cerveau interchangeable : le sélecteur de modèle

Le mode agent : la boucle en action

Les outils intégrés — les mains de Copilot

Comment Copilot remplit le bureau — le contexte

Le cousin universel : `AGENTS.md`

The universal cousin: `AGENTS.md`