Comprendre le modèle

Parcours 1 : Culture IA générative

Huit étapes pour comprendre ce que fait vraiment un modèle de langage : le texte, les jetons, les erreurs qui en découlent, la fenêtre de contexte, la manière de demander, l'agent, les boucles, les risques. Aucun outil à installer ; un outil d'IA au choix suffit pour les exercices. Environ deux heures et demie, à calibrer en séance.

Parcours pas encore éprouvé avec un groupe : les durées et les exercices sont des estimations de conception, à ajuster après une première séance.

1 · Le modèle
2 · Les jetons
3 · Les hallucinations
4 · Le contexte
5 · Le prompt
6 · L'agent
7 · Les boucles
8 · Risques

Étape 1

Ce qu'est un modèle de langage

Un outil qui prolonge un texte, pas une base de connaissances.

Un modèle de langage a lu une très grande quantité de textes et calcule, mot après mot, la suite la plus plausible de ce qu'on lui donne. Il ne consulte pas une base de faits : il produit du texte vraisemblable. De là viennent ses deux forces (rédiger, reformuler, transformer) et ses deux faiblesses (inventer, ignorer ce qui s'est passé après son entraînement).

À essayer avec l'outil de votre choix : posez trois fois exactement la même question ouverte (par exemple « propose-moi un plan pour présenter notre offre »). Comparez les trois réponses.

Ce qu'on observe

Les réponses diffèrent : le modèle tire sa suite parmi plusieurs possibles, il ne rejoue pas une réponse stockée. Pour une tâche qui doit être identique à chaque fois (un calcul, un contrôle), on ne s'en remet pas au texte du modèle : on utilise un programme, et le modèle ne fait que lire ou rédiger.

Étape 2

Les jetons

L'unité de texte que le modèle lit, écrit, et que l'on compte.

Le modèle ne lit pas des lettres ni des mots entiers : il découpe le texte en morceaux appelés jetons (tokens). Tout se mesure en jetons : la longueur de ce qu'il peut lire, la longueur de sa réponse, les limites d'usage et le coût d'un appel à l'API. Un texte plus long, ou une langue découpée plus finement, consomme plus de jetons.

Ce découpage a une conséquence importante : le modèle ne « comprend » pas une phrase puis répond. À chaque pas, il calcule une probabilité pour chaque jeton qui pourrait suivre, en tire un, l'ajoute, et recommence. Ce sont des statistiques sur des quantités énormes de texte, appliquées par des calculs mathématiques. Deux phrases possibles après « Il était une fois » : la plus probable n'est pas toujours tirée, d'où des réponses différentes à chaque essai.

Choisissez une phrase, déplacez la température, puis tirez 20 fois. Ensuite, estimez un de vos textes : le résultat est un ordre de grandeur, le vrai compte dépend du modèle et l'API propose un compteur exact (voir les sources).

Pour aller plus loin : d'où viennent les probabilités

Le modèle donne un score à chaque jeton possible. Une fonction appelée softmax transforme ces scores en probabilités qui font 100 % au total : probabilité = softmax(score ÷ température). Une température basse creuse les écarts (le premier jeton gagne presque toujours) ; une température haute les aplatit (les tirages varient plus).

Étape 3

Les hallucinations

Un texte faux dit avec assurance.

Puisque le modèle tire la suite la plus plausible, et non la plus vraie, il peut produire une affirmation fausse ou une source qui n'existe pas, avec le même ton que le vrai. On parle d'hallucination : c'est une conséquence directe de ce que vous venez de voir, pas un bogue rare. Aucune phrase magique ne la supprime : on la réduit par la manière de demander, puis on la contrôle.

Quatre leviers documentés :

Autoriser le « je ne sais pas » : dire explicitement qu'admettre l'incertitude est une bonne réponse.
Citer d'abord : sur un long document, demander les passages exacts avant l'analyse, puis ne raisonner que sur eux.
Exiger des citations pour chaque affirmation, et retirer celles qu'aucun passage ne soutient.
Limiter aux documents fournis : interdire de s'appuyer sur ses connaissances générales.

Réécrivez cette demande avec au moins deux leviers :

Avant

Résume les risques juridiques de ce contrat et dis-moi ce qu'on doit négocier.

Une version possible

Voici le contrat entre <contrat> et </contrat> (ces balises de délimitation sont expliquées à l'étape 5).
1. Extrais d'abord les passages exacts qui parlent de responsabilité, de résiliation et de pénalités. Si tu n'en trouves pas, écris « aucun passage trouvé ».
2. Analyse les risques en citant le numéro de chaque passage. N'utilise rien d'autre que ce contrat.
3. Si un point te semble manquer, dis « je ne peux pas l'affirmer à partir du document ».

Ce que ça ne règle pas

Ces techniques réduisent les hallucinations, elles ne les suppriment pas. Pour une décision importante, une personne relit les passages cités dans le document d'origine. Un chiffre, une date, une référence légale ou une citation s'écrivent dans un texte seulement après vérification à la source.

Étape 4

La fenêtre de contexte

Tout ce que le modèle peut voir à un instant donné, et rien d'autre.

La fenêtre de contexte est la « mémoire de travail » du modèle : tout ce qu'il peut consulter pour répondre, sa réponse comprise. Elle contient bien plus que votre dernier message : consignes du système, fichiers d'instructions, définitions des outils, historique de la conversation, fichiers lus, résultats des outils. Le modèle n'a pas de mémoire en dehors de cette fenêtre : une nouvelle session repart de zéro.

Une fenêtre plus grande n'améliore pas la réponse : à mesure que le contexte grossit, la précision et le rappel peuvent baisser : c'est ce que la documentation appelle context rot. Choisir ce qui entre compte autant que la place disponible.

Regardez la fenêtre se remplir au fil d'une session d'agent, puis se compacter.

Étape 5

Le prompt engineering

Écrire pour un lecteur très compétent qui n'a aucun contexte.

Un prompt est un texte de travail : on le rédige comme une consigne à un collègue brillant qui arrive ce matin. La règle d'or de la documentation : montrez votre consigne à quelqu'un qui n'a pas le contexte et demandez-lui de l'exécuter. S'il hésite, le modèle hésitera aussi.

Être clair et direct : le résultat attendu, son format, ses contraintes, les étapes dans l'ordre quand l'ordre compte.
Donner le contexte et la raison : « pas de listes à puces, ce texte sera lu à voix haute » vaut mieux que « pas de listes ».
Donner des exemples : trois à cinq, proches de votre cas réel, variés, séparés des consignes par des balises.
Structurer avec des balises (<consignes>, <document>, <exemple>) quand le prompt mélange consignes, documents et exemples.
Donner un rôle en une phrase pour cadrer le ton et le point de vue.

Améliorez cette demande :

Avant

Fais-moi un mail de relance client.

Une version possible

Tu rédiges pour une ESN. Écris un e-mail de relance à un client dont la proposition est restée sans réponse depuis dix jours.
Contexte : première relance, ton cordial et direct, sans pression commerciale.
Format : objet, puis trois phrases au plus, une question fermée pour avancer.
<exemple>
Objet : Votre avis sur la proposition
Bonjour, je reviens vers vous au sujet de la proposition du 3. Avez-vous pu la relire ? Je peux répondre à vos questions cette semaine.
</exemple>

Pourquoi la seconde marche mieux

Elle dit pour qui on écrit, dans quelle situation, avec quel ton, quel format, et montre un exemple. Rien n'est laissé à deviner. Notez aussi ce qu'elle ne fait pas : elle n'empile pas vingt règles. Le but est le plus petit ensemble d'informations qui change vraiment le résultat.

Étape 6

De l'assistant à l'agent

Un modèle, des outils et une boucle.

Un assistant de conversation répond puis s'arrête. Un agent reçoit un objectif et boucle : il réfléchit, appelle un outil (lire un fichier, lancer une commande, chercher), lit le résultat qui entre dans son contexte, puis décide de continuer ou de s'arrêter. Tout ce que vous venez de voir (jetons, fenêtre, probabilités) se rejoue à chaque tour de cette boucle.

Deux familles de systèmes se distinguent : dans un workflow, le chemin est écrit à l'avance dans du code et le modèle remplit des étapes ; dans un agent, c'est le modèle qui décide des étapes et des outils. Le conseil constant de la documentation d'Anthropic : commencer par la solution la plus simple (un seul appel, bien contextualisé) et n'ajouter de l'autonomie que si la tâche l'exige, parce que l'autonomie coûte en latence, en argent et en risque d'erreurs qui s'accumulent.

Deux conséquences pour la suite. D'abord, chaque outil est une porte ouverte : lire un fichier est bénin, lancer une commande ou écrire dans une base ne l'est pas, d'où les permissions du parcours suivant. Ensuite, ce qui entre dans la boucle (pages web, fichiers, résultats d'outils) est du texte que le modèle lit : s'il est hostile, il peut tenter de détourner l'agent (étape 8).

Question

Dans l'exemple, qu'est-ce qui décide que la boucle s'arrête ? Aucun compteur : le modèle juge que le test est vert. D'où l'intérêt de lui donner un contrôle qu'il peut lancer, plutôt que de lui faire confiance sur parole (parcours Harness).

Étape 7

Les boucles d'agents

Relancer un agent jusqu'à une condition : utile, à condition de savoir quand il s'arrête.

Le mot loop revient partout sur les réseaux, pour désigner des choses différentes. Il y a trois étages, du plus petit au plus grand.

Boucle	Ce qu'elle relance	Qui l'arrête
La boucle de l'agent (étape 6)	Un tour : réfléchir, appeler un outil, lire le résultat	Le modèle, quand sa réponse ne demande plus d'outil
La boucle autour de l'agent	Toute la session, avec le même prompt, tant qu'une condition n'est pas remplie	Un critère écrit à l'avance, ou un nombre maximal de tours
La tâche planifiée	Une session à intervalle fixe ou sur un événement	Une date d'expiration, ou vous

À retenir pour la suite : une boucle n'est utile que si une commande peut dire quand c'est fini (des tests qui passent), et elle doit avoir un plafond de tours.

Pour aller plus loin : les outils de boucle, un par un

« Ralph » : une technique popularisée par un développeur, qui la résume à une ligne de shell : while :; do cat PROMPT.md | claude-code ; done. L'agent repart du même prompt à chaque tour, et ce qu'il a écrit dans les fichiers sert de mémoire. Le plugin officiel ralph-wiggum de Claude Code en fait une commande, /ralph-loop, qui s'arrête quand l'agent écrit une phrase convenue (--completion-promise) ou après un nombre de tours (--max-iterations, illimité par défaut : la documentation recommande de toujours le fixer).
Le hook Stop, le mécanisme qui rend cela possible : quand l'agent veut s'arrêter, un hook peut répondre « bloquer » avec une raison, et l'agent continue. Claude Code limite ces relances à huit d'affilée par défaut, et le champ stop_hook_active permet au hook de savoir qu'il a déjà relancé.
/goal <condition> dans Claude Code : la boucle autour de l'agent, prête à l'emploi. Après chaque tour, un petit modèle juge la condition d'après la conversation (il ne lance aucune commande) ; tant qu'elle n'est pas remplie, Claude repart. Bornez-le dans la condition (« ou arrête après 20 tours »). C'est un hook Stop à prompt, fourni par Claude Code.
/loop dans Claude Code : relance un prompt à intervalle (/loop 5m …), ou laisse Claude choisir l'attente. Ces tâches vivent dans la session ouverte et expirent après sept jours.
Les routines (/schedule) tournent dans le cloud d'Anthropic, sur un horaire, un appel d'API ou un événement GitHub, même ordinateur éteint, et sans demande d'autorisation pendant l'exécution. Une GitHub Action (claude-code-action) peut faire de même sur un cron.
Les limites intégrées : claude -p --max-turns 3 ou --max-budget-usd en ligne de commande, maxTurns et maxBudgetUsd dans l'Agent SDK. Sans elles, il n'y a pas de limite.

Quand c'est utile, et ce que ça coûte

Une boucle vaut la peine quand le résultat se vérifie par une machine : des tests qui passent, une compilation sans erreur, une migration de code fichier par fichier. Elle est risquée quand « terminé » est une affaire de jugement. Les risques sont ceux que la documentation d'Anthropic associe à l'autonomie : un coût qui grandit à chaque tour, des erreurs qui s'accumulent d'un tour à l'autre, et une boucle qui ne s'arrête pas faute de critère.

Avant de lancer une boucle	Avec Kwa
Un critère d'arrêt qu'une commande peut contrôler	Les critères de réussite de l'issue, et les commandes `verify` de la politique
Un plafond de tours ou de budget	À fixer vous-même : Kwa n'en pose pas
Des actions dangereuses bloquées, sans personne pour approuver	Les gardes (pas de push sur `main`, pas de secret écrit) tournent à chaque tour
Une preuve à la fin, pas une affirmation	Pas de fusion sans preuve sur la PR

Question

Vous lancez /ralph-loop avec « corrige les tests, écris FINI quand c'est vert », sans --max-iterations. Que peut-il se passer ? L'agent peut tourner indéfiniment si un test ne peut pas passer, ou écrire « FINI » sans que les tests soient verts : la phrase est un critère que le modèle déclare, pas une commande qui vérifie. Fixez un plafond, et faites vérifier le résultat par les tests eux-mêmes.

Étape 8

Risques et usages responsables

Ce qu'on n'envoie pas, ce qu'on vérifie, qui décide.

Données : ne pas coller de données personnelles, de secrets ni de données client réelles dans un outil que l'on ne maîtrise pas. Anonymiser ou fabriquer des exemples.
Vérification : relire, contrôler les chiffres, les références et les citations à la source.
Responsabilité : la décision et la signature restent humaines. Le modèle propose, la personne répond du résultat.
Calcul : un montant, un total ou un contrôle s'obtiennent par un tableur ou un script vérifiable. Le modèle lit et rédige autour.
Injection de prompt : un texte lu par l'agent (page web, README, ticket, résultat d'un outil) peut contenir des instructions cachées qui cherchent à détourner son comportement. Le modèle ne distingue pas toujours ce qui vient de vous de ce qui vient du contenu qu'il lit.

Réflexe	Pourquoi
Relire les commandes avant de les approuver	C'est le dernier filet quand le contenu lu est hostile
Ne pas passer de contenu non fiable directement à l'agent	Un fichier téléchargé, un e-mail ou un ticket externe sont des entrées, pas des consignes
Limiter les permissions et isoler (bac à sable, machine virtuelle)	Un agent détourné ne peut faire que ce qu'on lui a permis
Ne brancher que des serveurs MCP de confiance	Ils agissent avec vos droits et renvoient du texte que l'agent lira

Ces réflexes figurent dans la documentation de sécurité de Claude Code, qui ajoute qu'aucune protection n'est complète. Un exemple concret au parcours suivant : les documentations et les pages web que l'agent consulte avec Context7 ou Playwright sont aussi des entrées non fiables.

Prochaine étape : passer d'un prompt isolé à un contexte entretenu, avec des fichiers, des skills et des outils. C'est le parcours suivant.

Vous avez compris si vous savez

dire pourquoi un modèle produit du texte plausible sans consulter une base de faits ;
estimer les jetons d'un texte et lister ce qui occupe une fenêtre de contexte ;
expliquer pourquoi remplir la fenêtre ne rend pas la réponse meilleure ;
réécrire une demande pour réduire le risque d'hallucination, puis vérifier à la source ;
décrire la boucle d'un agent, et nommer l'injection de prompt et deux parades ;
dire ce qui arrête une boucle d'agents, et pourquoi un plafond de tours est nécessaire ;
écrire une consigne qu'un collègue sans contexte pourrait exécuter.

Sources

Les documentations officielles font foi. Les noms de réglages et les limites évoluent avec les versions : vérifiez avant une séance.