Guide Professeur — Session 1 : Fondements : Transformers & Tokenisation

Programme : Applied AI — Niveau Intermédiaire Instructeur : Yann Isola Durée : 2 heures (120 minutes) Module couvert : Module 1 — Fondements

1. Vue d’ensemble de la session

Objectifs pédagogiques

À la fin de cette session, chaque participant doit être capable de :

Situer les transformers dans l’histoire de l’IA : expliquer le passage des systèmes à règles → apprentissage automatique classique → apprentissage profond → transformers (2017).
Expliquer la tokenisation : comprendre qu’un modèle lit des fragments de ~3-4 caractères (les « tokens »), et non des mots, et en déduire pourquoi certains échecs surprenants se produisent (ex. : compter les lettres d’un mot).
Décrire les embeddings : chaque token devient un vecteur ; les sens proches occupent des positions proches (« roi − homme + femme ≈ reine »).
Expliquer le mécanisme d’attention : chaque token évalue dynamiquement la pertinence de tous les autres tokens.
Décrire le pipeline d’entraînement : pré-entraînement (l’université) → post-entraînement / RLHF (l’école de finition) → fine-tuning (l’intégration en entreprise).
Distinguer entraînement et inférence : comprendre que la vitesse d’inférence est limitée par la bande passante mémoire, pas par la puissance de calcul.
Comprendre les lois d’échelle (scaling laws) : les gains de performance sont prévisibles avec plus de données, de calcul et de paramètres.

Prérequis

Aucune compétence en programmation requise.
Avoir déjà utilisé un assistant IA (ChatGPT, Claude, Gemini ou équivalent) au moins quelques fois.
Curiosité et volonté de comprendre « ce qui se passe sous le capot ».

Matériel nécessaire

Vidéoprojecteur + slides de la session (voir slides/slides.md).
Page web interactive (webpage/index.html) — fonctionne hors ligne, à ouvrir dans un navigateur moderne.
Idéalement : chaque participant avec un ordinateur portable ou smartphone pour les exercices pratiques.
Feuilles d’exercices imprimées ou partagées numériquement (exercises/exercises.md).
Quiz de fin de session (quiz/quiz.md).

Message central de la session

« Un modèle de langage n’est pas magique : c’est une machine statistique qui découpe le texte en fragments, les transforme en nombres, mesure les relations entre ces nombres, et prédit le fragment suivant. Comprendre ces quatre étapes, c’est comprendre 80 % des forces et des faiblesses de l’IA moderne. »

Répétez cette idée sous différentes formes tout au long de la session. C’est le fil rouge.

2. Déroulé minute par minute

Horaire	Durée	Séquence	Support
0:00 – 0:05	5 min	Accueil, objectifs, plan de la session	Slides 1–2
0:05 – 0:20	15 min	Partie A — Histoire : des règles aux transformers	Slides 3–7
0:20 – 0:40	20 min	Partie B — Tokenisation	Slides 8–12 + démo web
0:40 – 0:50	10 min	Exercice 1 : Exploration de la tokenisation	Feuille d’exercices
0:50 – 1:05	15 min	Partie C — Embeddings	Slides 13–16 + démo web
1:05 – 1:10	5 min	☕ Pause courte	—
1:10 – 1:25	15 min	Partie D — Attention	Slides 17–20 + démo web
1:25 – 1:33	8 min	Exercice 2 : Le jeu des analogies	Feuille d’exercices
1:33 – 1:48	15 min	Partie E — Pipeline d’entraînement & inférence	Slides 21–25
1:48 – 1:53	5 min	Partie F — Lois d’échelle	Slides 26–27
1:53 – 2:00	7 min	Quiz éclair + Exit Tickets + annonce Session 2	Slides 28–30

Note de flexibilité : si vous prenez du retard, l’Exercice 2 peut être raccourci à 5 minutes (faire seulement 2 analogies en collectif) et l’Exercice 3 devient un devoir à la maison. Ne sacrifiez JAMAIS la Partie E (pipeline d’entraînement) : c’est la partie la plus réutilisée dans les sessions suivantes.

3. Notes pédagogiques détaillées par séquence

0:00 – 0:05 | Accueil et cadrage

Quoi dire :

Souhaitez la bienvenue. Présentez le contrat de la session : « Dans 2 heures, vous saurez expliquer à un collègue comment fonctionne réellement un modèle de langage — sans magie, sans jargon inutile. »
Annoncez la règle d’or du cours : chaque acronyme sera expliqué. Si un participant entend un terme non expliqué, il a le droit (et le devoir) de lever la main.

Point d’attention : évaluez rapidement le niveau de la salle. Demandez à main levée : « Qui utilise un assistant IA au moins une fois par semaine ? » Cela vous permet de calibrer les exemples.

0:05 – 0:20 | Partie A — Histoire : des règles aux transformers

Concepts clés : systèmes à règles → ML (Machine Learning, apprentissage automatique) classique → deep learning (apprentissage profond) → transformers (2017).

Quoi dire — la trame narrative en 4 époques :

L’ère des règles (1950s–1990s). « On croyait qu’il suffisait d’écrire toutes les règles à la main. Exemple concret : un filtre anti-spam à règles — “si l’email contient le mot GRATUIT en majuscules, c’est du spam”. Problème : les spammeurs écrivent “GR4TUIT” et la règle échoue. Les règles écrites à la main ne passent pas à l’échelle. »
L’apprentissage automatique classique (1990s–2010s). « Changement de philosophie : au lieu d’écrire les règles, on montre des exemples et la machine découvre les règles elle-même. Le filtre anti-spam apprend sur 100 000 emails étiquetés “spam / pas spam”. Mais un humain doit encore choisir les caractéristiques à observer (fréquence des mots, présence de liens…). »
L’apprentissage profond (2012–2017). « Les réseaux de neurones profonds apprennent eux-mêmes quelles caractéristiques observer. 2012 : AlexNet écrase la compétition de reconnaissance d’images ImageNet. Mais pour le langage, un problème persiste : les réseaux de l’époque (RNN — Recurrent Neural Networks, réseaux de neurones récurrents) lisent le texte mot par mot, séquentiellement, et “oublient” le début des phrases longues. Et ils sont lents à entraîner, car impossible à paralléliser. »
Les transformers (2017). « Un article de recherche de Google intitulé Attention Is All You Need (“L’attention est tout ce dont vous avez besoin”) propose une architecture qui règle les deux problèmes d’un coup : (a) le mécanisme d’attention permet à chaque mot de “regarder” tous les autres mots de la phrase, même très éloignés — fini l’oubli ; (b) tout se calcule en parallèle — on peut exploiter des milliers de processeurs graphiques (GPU — Graphics Processing Unit, processeur graphique) en même temps. C’est cette parallélisation qui a permis l’explosion de la taille des modèles. »

À souligner (écrivez-le au tableau) :

Transformers = attention (mémoire longue) + parallélisme (passage à l’échelle matériel)

Question fréquente n°1 : « Pourquoi ça s’appelle “transformer” ? » Réponse : le nom vient de l’article de 2017 — l’architecture “transforme” une séquence d’entrée en séquence de sortie. Pas de lien avec les robots du film. Anecdote qui détend la salle.

Question fréquente n°2 : « ChatGPT, c’est un transformer ? » Réponse : oui. GPT signifie Generative Pre-trained Transformer (transformeur génératif pré-entraîné). Le “T” est dans le nom. Claude, Gemini, Llama, Mistral : tous des transformers, avec des variantes.

Transition vers la Partie B :

« Très bien, on sait maintenant quand et pourquoi les transformers sont arrivés. Mais concrètement, quand vous tapez une phrase dans ChatGPT, quelle est la toute première chose qui se passe ? Le modèle ne lit pas vos mots. Il ne lit même pas vos lettres. Il lit autre chose. C’est parti pour la tokenisation. »

0:20 – 0:40 | Partie B — Tokenisation

Concept clé : le modèle découpe le texte en tokens — des fragments d’environ 3 à 4 caractères en moyenne (⚠ moyenne indicative pour l’anglais ; en français, souvent un peu plus de tokens par mot). Ce ne sont ni des mots, ni des lettres.

Quoi dire :

La définition par l’exemple. Projetez la démo web (onglet « Tokeniseur »). Tapez en direct : L'intelligence artificielle transforme nos métiers. Montrez le découpage coloré. Faites remarquer que « intelligence » est peut-être coupé en plusieurs morceaux, alors que « les » ou « nos » tiennent en un seul token.
Pourquoi des tokens et pas des mots ? « Deux raisons. Un : le vocabulaire. Il existe des millions de mots, de noms propres, de fautes de frappe, de mots inventés — impossible de tous les stocker. Avec ~100 000 fragments (⚠ ordre de grandeur, varie selon les modèles), on peut reconstruire n’importe quel texte, même “Schtroumpfissime” ou “COVID-19”. Deux : l’efficacité. Les mots fréquents deviennent un seul token, les mots rares sont assemblés à partir de fragments. C’est comme le Lego : peu de briques de base, constructions infinies. »
Pourquoi pas des lettres ? « Ce serait possible, mais les séquences deviendraient très longues (une phrase de 50 mots = ~300 lettres = ~300 étapes de calcul au lieu de ~70 tokens). Les tokens sont le compromis entre vocabulaire gérable et séquences courtes. »
Le point crucial — les échecs bizarres expliqués. C’est LE moment “aha” de la partie. « Demandez à un modèle : combien de “r” dans le mot “strawberry” ? Les modèles se trompent régulièrement. Pourquoi ? Parce que le modèle ne voit jamais s-t-r-a-w-b-e-r-r-y. Il voit peut-être [str][aw][berry] — trois blocs opaques. Lui demander de compter les lettres, c’est comme vous demander de compter les “r” dans un mot écrit en caractères chinois : vous voyez les blocs, pas les lettres internes. » Même logique pour : inverser un mot, jeux de mots lettre par lettre, arithmétique sur de longs nombres (découpés en tokens arbitraires).

Exemple supplémentaire à donner à l’oral : les dates. « 2024 » peut être un token unique, mais « 20241231 » sera découpé arbitrairement — d’où des erreurs surprenantes sur la manipulation de chaînes de chiffres.

Question fréquente n°3 : « Du coup, le modèle est nul en orthographe ? » Réponse : non — il a vu tellement de texte qu’il connaît statistiquement l’orthographe des mots. Mais les tâches qui exigent de voir les lettres individuellement (compter, inverser, épeler à l’envers) sont structurellement difficiles. Nuance importante : les modèles récents contournent parfois le problème en « raisonnant » étape par étape, en épelant d’abord le mot. La limitation structurelle demeure, les stratégies de contournement s’améliorent. (⚠ état des modèles susceptible d’évoluer)

Question fréquente n°4 : « Le français consomme-t-il plus de tokens que l’anglais ? » Réponse : oui, généralement — les tokeniseurs sont majoritairement optimisés sur l’anglais. Un même texte en français peut coûter ~1,2 à 2× plus de tokens (⚠ dépend du tokeniseur et évolue). Conséquence pratique : coût API et fenêtre de contexte consommés plus vite en français.

Transition vers l’Exercice 1 :

« Assez de théorie — vous allez maintenant jouer vous-mêmes avec un tokeniseur et constater ces bizarreries de vos propres yeux. »

0:40 – 0:50 | Exercice 1 — Exploration de la tokenisation

Voir la feuille d’exercices (exercises/exercises.md, Exercice 1). Les participants utilisent la démo web (onglet « Tokeniseur ») ou un tokeniseur en ligne.

Rôle de l’instructeur pendant l’exercice :

Circulez dans la salle. Les blocages typiques : « je ne vois pas de différence » → suggérez de tester des mots rares vs fréquents, des nombres, des mots avec fautes.
À 8 minutes, faites une mise en commun de 2 minutes : demandez à 2–3 participants leur découverte la plus surprenante.

Restitution attendue : les mots fréquents = 1 token ; les mots rares = plusieurs tokens ; les nombres et les fautes de frappe explosent le compte de tokens.

0:50 – 1:05 | Partie C — Embeddings

Concept clé : chaque token est converti en un vecteur (une liste de nombres). Les tokens de sens proche occupent des positions proches dans cet espace. Le sens devient de la géométrie.

Quoi dire :

Le problème à résoudre. « Les ordinateurs ne calculent pas avec des mots, seulement avec des nombres. Il faut donc convertir chaque token en nombres. Mais pas n’importe comment : on veut que la conversion préserve le sens. »
L’analogie de la carte. « Imaginez une carte de géographie où l’on placerait les mots au lieu des villes. “Chat” et “chien” seraient voisins, comme Lyon et Villeurbanne. “Chat” et “carburateur” seraient aux antipodes. Un embedding, c’est exactement ça : une adresse dans un espace de sens. Sauf que l’espace n’a pas 2 dimensions comme une carte, mais des centaines voire des milliers (⚠ ordre de grandeur selon les modèles). Chaque dimension capture une nuance : animé/inanimé, masculin/féminin, concret/abstrait, technique/quotidien… »
La démonstration célèbre : roi − homme + femme ≈ reine. « Comme ce sont des nombres, on peut faire de l’arithmétique sur le SENS. Prenez le vecteur de “roi”, retirez le vecteur de “homme”, ajoutez celui de “femme” : vous atterrissez près du vecteur de “reine”. La direction “masculin → féminin” est une flèche cohérente dans l’espace. Idem : Paris − France + Italie ≈ Rome. La relation “capitale de” est aussi une direction géométrique. » Insistez : ce résultat provient de travaux sur les embeddings de mots (word2vec, 2013) et illustre le principe général — dans les transformers modernes, les embeddings sont contextuels et plus riches, mais l’intuition reste valable.
Où viennent ces positions ? « Personne ne les a placées à la main. Elles émergent de l’entraînement : les mots qui apparaissent dans les mêmes contextes finissent voisins. “On reconnaît un mot à ses fréquentations” — c’est littéralement le principe (hypothèse distributionnelle en linguistique). »
Démo web. Ouvrez l’onglet « Espace d’embeddings » : montrez les trois nuages (animaux, couleurs, métiers). Faites glisser la vue, survolez les points. Faites remarquer que « vétérinaire » se situe entre le nuage des métiers et celui des animaux — les embeddings capturent les appartenances multiples.

Question fréquente n°5 : « C’est comme un dictionnaire de synonymes ? » Réponse : plus puissant. Un dictionnaire de synonymes est binaire (synonyme ou pas). L’espace d’embeddings est continu : il capture des degrés de proximité, des directions de sens (le genre, le temps, la taille…), et des relations qu’aucun dictionnaire ne liste (« Paris est à la France ce que Rome est à l’Italie »).

Application professionnelle à mentionner (prépare les sessions futures) : « La recherche sémantique en entreprise fonctionne ainsi : on convertit vos documents ET votre question en embeddings, puis on cherche les documents dont le vecteur est proche de celui de la question — même s’ils n’utilisent aucun mot en commun. Chercher “problème de facturation” retrouve un document qui dit “anomalie de paiement”. C’est la base du RAG (Retrieval-Augmented Generation, génération augmentée par récupération d’information), qu’on verra en détail dans une session dédiée. »

Transition vers la pause :

« Récapitulons : le texte est découpé en tokens, chaque token devient un point dans un espace de sens. Mais un point isolé ne suffit pas — “avocat” le fruit et “avocat” le métier, même mot, sens différents. Comment le modèle tranche-t-il ? Réponse dans 5 minutes, après la pause : c’est le mécanisme d’attention. »

1:10 – 1:25 | Partie D — Attention

Concept clé : chaque token évalue dynamiquement la pertinence de tous les autres tokens du contexte, et ajuste sa représentation en conséquence.

Quoi dire :

Le problème de l’ambiguïté. Écrivez au tableau : « L’avocat mange un avocat. » « Le mot “avocat” apparaît deux fois — un métier, un fruit. Comment le modèle sait-il ? Grâce au contexte : “mange” pointe vers le fruit pour le second, “L’” + position de sujet pointe vers la personne pour le premier. L’attention est le mécanisme qui formalise ce “regard vers le contexte”. »
La mécanique intuitive. « Pour chaque token, le modèle pose la question : quels autres tokens de la phrase m’aident à préciser mon sens ici, maintenant ? Chaque token distribue des “poids d’attention” — un pourcentage d’importance — sur tous les autres tokens. Puis il met à jour sa propre représentation en mélangeant les informations des tokens jugés pertinents. Et cela se fait en parallèle pour tous les tokens, sur des dizaines de couches successives. »
L’exemple du pronom. « Phrase : Le trophée ne rentre pas dans la valise parce qu’il est trop grand. — “il” désigne quoi ? Le trophée. Changez “grand” en “petite” : parce qu’elle est trop petite — maintenant c’est la valise. Résoudre “il/elle” exige de peser tout le contexte. C’est exactement ce que fait l’attention, et c’est ce que les architectures d’avant 2017 rataient sur les phrases longues. »
Démo web. Onglet « Attention » : montrez la carte de chaleur sur la phrase d’exemple. Faites remarquer les cases sombres : « il » attend fortement vers « trophée ». Cliquez sur différents mots pour visualiser leur distribution d’attention.
Reliez à la Partie A. « Souvenez-vous du tableau : attention = mémoire longue, parallélisme = échelle. Vous venez de voir la mémoire longue en action. Et comme chaque token calcule son attention indépendamment des autres, tout se fait en parallèle — d’où l’exploitation massive des GPU. La boucle est bouclée. »

Question fréquente n°6 : « C’est de la compréhension ou du calcul ? » Réponse honnête à donner : « C’est du calcul — des multiplications de matrices — dont le résultat ressemble fonctionnellement à de la compréhension contextuelle. Le cours ne tranchera pas le débat philosophique ; ce qui compte pour nous : le mécanisme est puissant, mesurable, et explique les capacités ET les limites. »

Piège pédagogique à éviter : ne rentrez PAS dans les détails Query/Key/Value (requête/clé/valeur) à ce niveau. Si un participant avancé pose la question, répondez : « Excellente question — techniquement, chaque token émet une “requête” et des “clés”, et leur compatibilité donne les poids d’attention. Voyez-moi à la pause pour les détails, ou consultez l’annexe. » Ne perdez pas les 90 % restants de la salle.

Transition vers l’Exercice 2 :

« Petit jeu avant de passer à l’entraînement des modèles : vous allez manipuler vous-mêmes l’arithmétique du sens. »

1:25 – 1:33 | Exercice 2 — Le jeu des analogies

Voir feuille d’exercices, Exercice 2. En binômes, 6 minutes + 2 minutes de correction collective.

Rôle de l’instructeur : lancez le chrono, puis corrigez en collectif en demandant aux binômes d’expliquer pourquoi l’analogie fonctionne géométriquement (quelle « direction » de sens est en jeu).

1:33 – 1:48 | Partie E — Pipeline d’entraînement & inférence

Concepts clés : pré-entraînement → post-entraînement (dont RLHF) → fine-tuning ; puis distinction entraînement/inférence ; l’inférence est limitée par la bande passante mémoire.

Quoi dire — l’analogie filée de la formation d’un professionnel :

Pré-entraînement = l’université. « On fait lire au modèle une immense partie du texte disponible : des milliers de milliards de tokens (⚠ ordres de grandeur en croissance constante). La tâche est d’une simplicité désarmante : prédire le token suivant. “Le chat dort sur le ___” → “canapé”. En s’exerçant des milliards de fois, le modèle est forcé d’absorber la grammaire, les faits, les styles, des rudiments de raisonnement — car tout cela aide à mieux prédire. Résultat : un modèle très savant mais brut de décoffrage — comme un diplômé brillant qui n’a jamais parlé à un client. Il complète du texte, il ne “répond” pas. Coût : des dizaines à des centaines de millions de dollars de calcul pour les plus gros modèles (⚠ chiffres évoluant rapidement). »
Post-entraînement / RLHF = l’école de finition. « RLHF : Reinforcement Learning from Human Feedback, c’est-à-dire apprentissage par renforcement à partir de retours humains. Des annotateurs comparent des paires de réponses (“laquelle est la plus utile, la plus honnête, la moins dangereuse ?”) et le modèle est ajusté pour produire davantage de réponses du type préféré. C’est ce qui transforme un moteur de complétion en assistant : ton, format, refus des demandes dangereuses, capacité à suivre des instructions. Analogie : l’école de finition — le savoir est déjà là, on apprend les manières, le format, la déontologie. »
Fine-tuning = l’intégration en entreprise. « Ajustement supplémentaire sur un domaine ou une tâche : vocabulaire juridique de VOTRE cabinet, ton de VOTRE marque, format de VOS rapports. Comme un nouvel embauché brillant qu’on forme aux procédures internes pendant son onboarding. Beaucoup moins coûteux que le pré-entraînement — on part d’un modèle déjà formé. »

Tableau récapitulatif à projeter (slide 23) :

Étape	Analogie	Ce qu’on apprend	Ordre de coût
Pré-entraînement	Université	Langue, faits, raisonnement	Très élevé ⚠
Post-entraînement (RLHF)	École de finition	Utilité, ton, sécurité	Moyen ⚠
Fine-tuning	Onboarding en entreprise	Spécialisation métier	Faible ⚠

Inférence — et le goulot d’étranglement mémoire. « Une fois entraîné, utiliser le modèle s’appelle l’inférence : votre prompt entre, les tokens sortent un par un. Point contre-intuitif : ce qui limite la vitesse, ce n’est pas la puissance de calcul, c’est la bande passante mémoire. Pourquoi ? Pour générer CHAQUE token, il faut faire transiter l’ensemble des paramètres du modèle — des dizaines ou centaines de gigaoctets — depuis la mémoire vers les unités de calcul. Le calcul lui-même est rapide ; c’est le déménagement des données qui prend du temps. Analogie : un chef étoilé (le calcul) qui doit aller chercher chaque ingrédient dans un entrepôt à l’autre bout de la ville (la mémoire). Le chef n’est jamais le problème ; la navette, si. » Conséquence pratique à donner : « c’est pourquoi les fabricants de puces se battent sur la bande passante mémoire (HBM — High Bandwidth Memory, mémoire à haute bande passante), et pourquoi les petits modèles répondent plus vite : moins de paramètres à déménager par token. »

Question fréquente n°7 : « Le modèle apprend-il de mes conversations ? » Réponse : « Pas pendant l’inférence — les paramètres sont figés. Votre conversation tient dans la fenêtre de contexte, une mémoire de travail temporaire. Selon les fournisseurs et vos réglages, vos conversations peuvent en revanche être collectées pour de FUTURS entraînements (⚠ politiques variables selon fournisseurs et offres — point important en entreprise, on y reviendra dans la session gouvernance/sécurité). »

Transition vers la Partie F :

« Dernière pièce du puzzle : pourquoi les modèles deviennent-ils meilleurs d’année en année ? Est-ce de la chance ? Non — c’est prévisible. Littéralement. »

1:48 – 1:53 | Partie F — Lois d’échelle (scaling laws)

Concept clé : la performance des modèles s’améliore de façon régulière et prévisible quand on augmente trois ingrédients : les données, le calcul, les paramètres.

Quoi dire :

« Découverte remarquable des années 2020 : si vous tracez la performance d’un modèle en fonction de sa taille (paramètres), de la quantité de données d’entraînement et du calcul investi, vous obtenez des courbes régulières. On peut prédire la performance d’un modèle 10× plus gros avant de l’entraîner. C’est ce qui a donné aux laboratoires la confiance d’investir des milliards : ils ne parient pas à l’aveugle, ils extrapolent une courbe. »
Analogie : « C’est comme la construction de ponts : on ne construit pas un pont de 2 km en espérant qu’il tienne — les équations de résistance des matériaux le prédisent. Les lois d’échelle sont les équations de résistance de l’IA. »
Nuances à donner (honnêteté intellectuelle) : « Trois précisions. Un : les courbes prédisent une métrique statistique (la qualité de prédiction du token suivant), pas directement l’apparition de capacités précises — certaines capacités semblent émerger par paliers. Deux : les trois ingrédients doivent croître ensemble — un modèle géant sous-alimenté en données est du gaspillage (c’est la leçon dite “Chinchilla”, du nom d’un modèle de recherche de 2022). Trois : le débat reste ouvert sur la poursuite indéfinie de ces courbes, et l’industrie explore d’autres axes, comme le calcul au moment de l’inférence (⚠ paysage en évolution rapide). »

Question fréquente n°8 : « Donc plus gros = toujours mieux ? » Réponse : « Mieux sur les benchmarks (bancs d’essai), oui, en tendance. Mais pas toujours pertinent : un modèle 10× plus gros est plus lent et plus cher à l’inférence — rappelez-vous la bande passante mémoire. En entreprise, le bon modèle est le plus petit qui atteint le niveau de qualité requis pour la tâche. »

1:53 – 2:00 | Clôture : Quiz éclair, Exit Tickets, teaser

Distribuez ou projetez le quiz (quiz/quiz.md) — en session, sélectionnez 4–5 questions à faire à main levée ; le quiz complet peut être fait en autonomie.
Faites remplir les Exit Tickets (ci-dessous) sur papier ou formulaire — 3 minutes.
Teaser Session 2 : « Vous savez maintenant COMMENT la machine fonctionne. La prochaine fois : comment lui PARLER pour en tirer le maximum — l’art et la science du prompting. »

4. Exit Tickets (5 questions de vérification)

À faire remplir individuellement en fin de session. Objectif : vérifier les acquis clés et détecter les incompréhensions avant la session 2.

ET-1. Expliquez en une ou deux phrases pourquoi un modèle de langage peut se tromper en comptant les lettres d’un mot.

Réponse modèle : Le modèle ne voit pas les lettres : le texte est découpé en tokens (fragments de ~3-4 caractères en moyenne) qui sont pour lui des blocs opaques. Compter des lettres exige un accès aux caractères individuels que sa représentation interne ne fournit pas directement.

ET-2. Que signifie « roi − homme + femme ≈ reine » et qu’est-ce que cela nous apprend sur les embeddings ?

Réponse modèle : Les mots sont représentés par des vecteurs (listes de nombres) ; on peut donc faire de l’arithmétique dessus. Cette équation montre que des relations de sens (ici masculin→féminin) correspondent à des directions cohérentes dans l’espace des embeddings : le sens est encodé géométriquement.

ET-3. Citez les deux problèmes des architectures pré-2017 que les transformers ont résolus, et par quel moyen.

Réponse modèle : (1) L’oubli des dépendances à longue distance dans les phrases → résolu par le mécanisme d’attention, où chaque token pèse la pertinence de tous les autres. (2) L’impossibilité de paralléliser l’entraînement (traitement séquentiel mot à mot) → résolu par une architecture entièrement parallélisable, permettant d’exploiter massivement les GPU.

ET-4. Associez chaque étape du pipeline à son analogie et à sa fonction : pré-entraînement, post-entraînement/RLHF, fine-tuning.

Réponse modèle : Pré-entraînement = université : acquisition massive du langage et des connaissances par prédiction du token suivant. Post-entraînement/RLHF (apprentissage par renforcement à partir de retours humains) = école de finition : transformation en assistant utile, poli et sûr grâce aux préférences humaines. Fine-tuning = onboarding en entreprise : spécialisation sur un domaine ou un format précis.

ET-5. Vrai ou faux, et justifiez : « Pour accélérer l’inférence d’un modèle, il faut surtout des processeurs plus puissants en calcul. »

Réponse modèle : Faux. L’inférence est principalement limitée par la bande passante mémoire : à chaque token généré, l’ensemble des paramètres doit transiter de la mémoire vers les unités de calcul. C’est ce transfert, et non le calcul, qui constitue le goulot d’étranglement — d’où l’importance de la mémoire rapide (HBM) et l’avantage de vitesse des petits modèles.

5. Conseils à l’instructeur

Le moment “strawberry” est votre meilleur allié. L’échec du comptage de lettres est contre-intuitif et mémorable — c’est l’accroche émotionnelle de la session. Si possible, faites la démonstration EN DIRECT avec un modèle (préparez une capture d’écran de secours au cas où le modèle réussirait : les modèles récents réussissent de plus en plus souvent ⚠ — dans ce cas, expliquez que le modèle a appris à contourner en épelant, la limite structurelle demeurant).
Filez les analogies, ne les multipliez pas. Une analogie par concept, tenue de bout en bout : carte de géographie (embeddings), université/finition/onboarding (pipeline), chef et entrepôt (bande passante). Trop d’analogies concurrentes brouillent la mémorisation.
Marquez physiquement le fil rouge. À chaque fin de partie, revenez au schéma : texte → tokens → vecteurs → attention → prédiction du token suivant. À la fin de la session, la salle doit pouvoir réciter cette chaîne.
Gérez les profils techniques. Il y aura peut-être un développeur qui veut parler de softmax et de multi-head attention. Formule magique : « Excellente question, elle dépasse le cadre de cette session — venez me voir à la pause. » Protégez le rythme du groupe.
Les nombres datent, les structures durent. Chaque fois que vous citez un chiffre (taille de vocabulaire, coût d’entraînement, ratio de tokens FR/EN), signalez oralement qu’il s’agit d’un ordre de grandeur daté (les ⚠ des slides sont là pour ça). En revanche, martelez que les mécanismes (tokenisation, embeddings, attention, pipeline) sont stables : c’est l’investissement durable des participants.
Minutez la démo web. La page interactive est captivante — c’est un risque. Fixez-vous 3 minutes max par onglet en démonstration plénière ; le temps d’exploration libre appartient aux exercices.
Anticipez la question métier. Quelqu’un demandera « à quoi ça me sert concrètement ? ». Réponse préparée : « Trois retombées immédiates : (1) vous saurez pourquoi l’IA échoue sur certaines tâches et comment reformuler ; (2) vous comprendrez la facturation au token et la consommation de la fenêtre de contexte ; (3) vous saurez lire les annonces des fournisseurs — taille de modèle, fine-tuning, vitesse d’inférence — sans vous faire éblouir par le marketing. »