Tu utilises ChatGPT tous les jours pour debugger ton code, mais tu sais vraiment ce qui se passe sous le capot ? Tokens, embeddings, RAG, température : il est temps de comprendre ce que tu manipules avant de passer pour une truffe en réunion.
Tu utilises ChatGPT pour debugger un bug venu de l'espace et auquel tu ne comprends rien ? Tu lui demandes de générer des DTOs, de refactoriser des Controllers, d'expliquer pourquoi ton ORM t'insulte dans une Exception en te parlant de Lazy ? Mais concrètement, tu ne sais pas vraiment comment ça marche sous le capot.
C'est quoi un token ? Pourquoi des fois ça répond n'importe quoi ? Et c'est quoi cette histoire de "température" qui n'a rien à voir avec ton radiateur ?
Si tu veux comprendre ce que tu manipules vraiment au lieu de juste copier-coller des prompts trouvés sur Reddit ou Stack Overflow, c'est maintenant. Parce que dire "j'ai configuré mon embedding avec un RAG sur MCP" en réunion, ça va mieux en sachant de quoi tu parles.
Quand tu tapes une question à ChatGPT, tu ne discutes pas avec une intelligence consciente qui réfléchit comme toi. Tu interroges un Large Language Model (LLM), un modèle de langage entraîné sur des milliards de mots pour prédire la suite la plus probable d'une séquence de texte.
C'est un peu comme l'autocomplétion de ton IDE, mais en beaucoup, beaucoup plus sophistiqué.
Le LLM a ingéré tellement de code, de documentations, de Stack Overflow et de Reddit qu'il a appris des patterns statistiques sur comment le langage fonctionne — et c'est tout ! Pas de conscience. Pas de compréhension. Juste des stats. Pas de Deus ex silicium comme veulent nous le faire croire toutes les publicités qui ajoutent de l'IA dans leur produit.
L'architecture qui fait ça ? Un Transformer. Google, 2017. Merci les gars.
Sans rentrer dans les équations mathématiques, l'idée géniale c'est le mécanisme d'attention. Ça permet au modèle de comprendre les relations entre les mots. Quand tu écris "Le développeur ouvre son IDE et il commence à coder", le Transformer comprend que "il" fait référence au "développeur" et pas à "l'IDE", même si ce dernier est plus proche.
C'est ce qui permet aux LLMs de maintenir une cohérence sur des textes longs et de capter le contexte. Enfin, la plupart du temps. Parce que des fois, ça part quand même en vrille.
Les LLMs fonctionnent de manière auto-régressive. Ils génèrent un mot à la fois (enfin, un token, on y vient après), en se basant sur tous les mots précédents. C'est pour ça que tu vois l'effet "machine à écrire" quand tu utilises ChatGPT. Chaque mot généré influence le suivant.
Le modèle calcule une distribution de probabilités sur tous les mots possibles du vocabulaire, puis en choisit un selon certains paramètres. D'où l'impression parfois d'une réponse qui part dans une direction bizarre — c'est juste que statistiquement, ça semblait être une bonne idée au modèle. (Dans les films de SF, c'est toujours comme ça que les ennuis commencent.)
Ce qui est important de comprendre en tant que dev : les LLMs n'ont pas de "connaissance" au sens où on l'entend. Ils n'ont pas accès à une base de données de faits vérifiés. Ils ont des patterns statistiques encodés dans des milliards de paramètres (les "poids" du réseau de neurones).
Quand GPT-4 te dit quelque chose, il ne "sait" pas si c'est vrai. Il prédit juste que cette suite de mots est statistiquement cohérente avec son entraînement. C'est pour ça qu'il peut halluciner des noms de fonctions PHP qui n'existent pas, mais qui sonnent bien. Genre secureHash() ou validateEmail() avec des paramètres inventés.
Ça a l'air crédible, mais tu viens de laisser une IA créer une Exception — et ça, c'est beau.
Parlons de ce qui te coûte vraiment de l'argent quand tu utilises une API d'IA : les tokens. Pas les NFT douteux, les vrais.
Un token, c'est l'unité de base qu'un LLM traite. C'est ni exactement un mot, ni exactement un caractère. C'est entre les deux. Genre le café dosette : ni du vrai café, ni de l'eau chaude, mais ça fait le taf.
La tokenisation découpe ton texte en morceaux que le modèle peut comprendre.
Imagine : tu codes en PHP depuis des années, tu ne lis plus lettre par lettre. Tu reconnais des patterns : "function", "public", "return". Pareil pour les LLMs, sauf qu'ils ont appris leurs propres découpages.
Le mot "tokenization" sera découpé différemment selon le modèle. Pour GPT-4, ça pourrait être ["token", "ization"] ou ["token", "iz", "ation"]. Les mots fréquents comme "the" ou "function" sont souvent un seul token. Les mots rares ou les mots composés sont découpés en plusieurs.
Tu veux rire ? Les mots français se font latter. On est plus verbeux que les anglophones, donc plus de tokens, donc plus cher. Pas merci Molière !
Un token représente environ 0,75 mot en anglais. En français, compte plutôt 0,6. Donc quand tu envoies une requête de 100 mots, tu consommes environ 130-170 tokens.
Et quand l'API te facture "$0.01 par 1K tokens", tu paies pour l'entrée ET la sortie.
Si tu demandes à GPT-4 de te pondre un article de 2 000 mots sur les design patterns en PHP, tu paies pour :
Ça paraît rien. Mais ça monte vite. Genre vraiment vite. Surtout si tu veux générer des descriptions de produit pour 10 000 articles. Là, tu commences à transpirer et à voir tes billets s'envoler.
Les limites de tokens sont vicieuses. Si ton modèle a une fenêtre de contexte limitée et que tu essaies de lui envoyer toute ta documentation Symfony, il va juste couper le début de ta requête. Pouf. Disparu. Tout ce qui dépasse la limite est perdu dans les limbes.
C'est pour ça que quand tu essaies de faire analyser un gros fichier à ChatGPT et qu'il te répond des choses qui n'ont rien à voir avec ce que tu lui as envoyé, c'est souvent qu'il n'a pas vraiment "vu" ton code. Il a juste vu la fin. Et il a halluciné le reste en mode "ça devrait ressembler à ça".
Concrètement, tu dois être conscient de cette contrainte. Avant d'envoyer ton code à analyser, découpe-le intelligemment. Ne balance pas 10 000 lignes d'un coup. Prépare des extraits pertinents.
Pense aux tokens comme à de la RAM très limitée — chaque caractère compte et te coûte de l'argent.
Les embeddings (ou vectorisation), c'est un concept qui paraît abstrait mais qui est fondamental pour plein d'usages avancés de l'IA. L'idée de base : transformer du texte en vecteur de nombres.
Pourquoi ? Parce que les ordinateurs adorent les nombres et détestent le texte. Un vecteur d'embedding, c'est comme des coordonnées GPS pour le sens d'un mot ou d'une phrase.
Les mots "Symfony" et "Laravel" ont des embeddings proches dans l'espace vectoriel, parce qu'ils apparaissent dans des contextes similaires (frameworks PHP, architecture MVC, routing, etc.). À l'inverse, "Symfony" et "poney" ont des embeddings très éloignés. (Sauf si tu développes un site d'aquaponey avec Symfony, mais là c'est un autre délire.)
Mathématiquement, on mesure cette proximité avec des calculs comme la similarité cosinus ou la distance euclidienne. Plus deux vecteurs sont proches, plus les concepts sont sémantiquement liés.
Un embedding typique pour un modèle moderne, c'est un vecteur de 768, 1024 ou 1536 dimensions. Oui, tu as bien lu. 1536 dimensions. Ton simple mot "PHP" devient une liste de 1536 nombres à virgule flottante.
Chaque dimension capture un aspect abstrait du sens. On ne peut pas vraiment dire "la dimension 42 représente la couleur rouge" — c'est plus subtil que ça. Ces dimensions sont apprises automatiquement pendant l'entraînement du modèle.
Parce que ça permet la recherche sémantique.
Imagine : tu as toute la documentation Symfony transformée en embeddings et stockée dans une base. Quand un utilisateur demande "comment gérer les formulaires avec validation", tu transformes sa question en embedding, tu cherches les documents les plus proches dans l'espace vectoriel, et tu récupères les pages de doc pertinentes.
C'est beaucoup plus puissant qu'une recherche par mots-clés classique, parce que "gérer les formulaires" va matcher avec "Form component" même si les mots sont différents. La machine comprend le sens. Enfin, elle fait semblant de comprendre. Mais ça marche.
C'est la base du RAG, dont on va parler juste après. Les embeddings, c'est le langage commun entre ton texte et le machine learning. Sans ça, l'IA est aveugle.
Le prompt, c'est la requête que tu envoies à un LLM. Ça paraît simple — tu poses une question, tu obtiens une réponse.
Sauf que la qualité de la réponse dépend massivement de la qualité du prompt. C'est un peu comme SQL : tu peux écrire une requête pourrie qui fonctionne, ou une requête optimisée qui te donne exactement ce que tu veux. Le prompt engineering, c'est l'art de formuler tes instructions pour obtenir les meilleurs résultats.
Il existe deux types de prompts fondamentaux.
Le system prompt définit le comportement général du modèle pour toute la conversation. C'est là que tu dis "Tu es un expert Symfony avec 10 ans d'expérience" ou "Réponds toujours en JSON valide". Ce prompt reste en mémoire pour toute la session.
Le user prompt, c'est ta requête spécifique à chaque tour : "Explique-moi les Value Objects" ou "Génère un controller CRUD pour l'entité Product".
Un mauvais prompt : "Explique PHP".
Un bon prompt : "Explique le concept de dependency injection en PHP 8.2 avec un exemple concret utilisant l'autowiring de Symfony. Cible : développeur junior qui connaît les bases de l'orienté objet. Format : 200 mots maximum avec un bloc de code commenté".
Tu vois la différence ? Le deuxième donne un contexte, définit les contraintes, précise l'audience et le format. L'IA sait où elle va. Le premier, c'est la roulette russe.
Zero-shot : "fait-moi ça" sans exemple — tu comptes sur la connaissance préexistante du modèle.
Few-shot : tu donnes quelques exemples de ce que tu veux.
Input: 'utilisateur' → Output: 'User'
Input: 'produit' → Output: 'Product'
Input: 'commande' → Output: ?
Le modèle apprend le pattern et le reproduit.
Chain-of-thought : "résous ce problème étape par étape" — tu forces le modèle à raisonner explicitement, ce qui améliore drastiquement les résultats sur les problèmes complexes. Genre de 30 à 60% de gain sur certains benchmarks. Pas négligeable.
Un piège classique : l'hallucination. Le LLM invente des trucs. Il va te dire avec assurance qu'il existe une fonction secureHash() en PHP alors qu'elle n'existe pas.
Pour mitiger ça, tu peux être explicite : "Utilise UNIQUEMENT les fonctions de la documentation PHP 8.2 fournie ci-dessous. Si tu n'es pas sûr, dis-le."
Fournir le contexte exact (une technique appelée grounding) réduit considérablement les hallucinations. C'est pour ça que le RAG est si utile.
Pense à tes prompts comme à des fonctions : entrées bien définies, contraintes claires, sorties prévisibles. C'est du code. Ça se teste. Ça s'optimise.
Quand un LLM génère du texte, il ne choisit pas systématiquement le mot le plus probable — sinon toutes les réponses seraient identiques et prévisibles. Il y a un élément de sampling (échantillonnage) contrôlé par plusieurs paramètres.
Le plus connu, c'est la température. Et non, ça n'a rien à voir avec ton radiateur ou ton four.
La température, c'est un nombre entre 0 et 1 (ou parfois 2) qui contrôle le côté aléatoire des réponses.
Temperature = 0 : déterministe. Le modèle choisit toujours le token le plus probable. Si tu demandes "Quelle est la capitale de la France ?" avec temperature=0, tu auras "Paris" à chaque fois. Parfait pour les tâches factuelles, le code, les traductions. Tout ce qui doit être précis.
Temperature = 1 : créatif, varié, mais aussi potentiellement incohérent. Le modèle explore davantage l'espace des possibles. Utile pour du brainstorming, de la génération d'idées, du contenu marketing. Ou pour obtenir des réponses totalement barrées si tu pousses trop loin.
Entre les deux (0.5-0.7) : c'est le sweet spot pour un équilibre entre précision et variété.
Techniquement, la température modifie la distribution de probabilités des tokens. Une température basse "aplatit" la distribution — les tokens très probables deviennent encore plus probables. Une température haute "lisse" la distribution — même les tokens moins probables ont leur chance.
Top-p (nucleus sampling) dit au modèle "choisis parmi les tokens dont la probabilité cumulée atteint p". Par exemple, top_p=0.9 signifie "considère seulement les tokens les plus probables qui représentent 90% de la masse de probabilité".
Max_tokens limite la longueur de la réponse — crucial pour éviter que le modèle génère un roman quand tu veux trois lignes. Et pour éviter de te ruiner en tokens.
Frequency_penalty et presence_penalty pénalisent la répétition — utile quand le modèle a tendance à radoter.
Le context window (fenêtre de contexte), c'est la quantité de texte qu'un LLM peut "voir" en même temps.
Imagine la RAM de ton serveur : tout ce qui ne tient pas dedans n'existe pas pour le programme. Pareil pour les LLMs. Si ton context window est de 8K tokens et que tu envoies 10K tokens, les 2K premiers disparaissent dans le vide. Pouf.
Les modèles récents ont des context windows de plus en plus grands :
Ces chiffres évoluent constamment, mais la tendance est claire : les context windows explosent. C'est le nerf de la guerre.
Parce que tout compte dans cette fenêtre.
Le system prompt (souvent 100-500 tokens), l'historique de conversation (qui s'accumule), ta question actuelle, ET la réponse générée. Si tu fais un chatbot avec 20 échanges de conversation, chaque échange consomme des tokens.
Arrivé à la limite, soit tu tronques l'historique (le modèle "oublie" le début), soit tu résumes les échanges précédents (ce que fait ChatGPT en coulisses), soit tu paies pour un modèle avec un plus gros context window.
Des études montrent que les LLMs sont moins performants sur les informations au milieu du contexte. Ils se souviennent bien du début (primacy effect) et de la fin (recency effect), mais le milieu a tendance à être négligé.
Si tu dois passer un document important de 20 pages à analyser, mieux vaut mettre les infos critiques au début et répéter les points-clés à la fin. Le sandwich de l'information.
Pense toujours tokens : chaque prompt, chaque réponse, chaque bout de contexte consomme ta fenêtre. C'est une ressource limitée. Gère-la comme un chef.
Le Retrieval-Augmented Generation (RAG), c'est la solution au problème fondamental des LLMs : leur connaissance est figée à leur date d'entraînement, et ils inventent quand ils ne savent pas.
Le RAG combine la puissance génératrice d'un LLM avec la capacité à rechercher dans une base de données externe. C'est comme donner un accès Google + Stack Overflow à ton modèle avant qu'il réponde.
1. Indexation (faite une fois) :
text-embedding-3-small d'OpenAI)2. Lors d'une requête utilisateur :
3. Recherche :
4. Génération :
Tu as un chatbot pour la documentation Symfony. L'utilisateur demande "Comment configurer le cache HTTP dans Symfony 7 ?"
Sans RAG : GPT-4 va te sortir une réponse générique, potentiellement obsolète, basée sur sa connaissance de 2023. Genre des trucs qui ne marchent plus depuis Symfony 6.
Avec RAG :
Fraîcheur des données : ta base vectorielle peut être mise à jour quotidiennement sans réentraîner le modèle. C'est du cron, pas du deep learning.
Traçabilité : tu peux citer tes sources puisque tu sais quels chunks ont été utilisés. Fini le "je l'ai lu quelque part je sais plus où".
Domaines spécialisés : injecte tes propres données métier que le modèle n'a jamais vues. Ta doc interne, tes processus, tes specs.
Réduction des hallucinations : grounding sur des faits vérifiables. Le modèle peut toujours halluciner, mais beaucoup moins.
Et le coût est raisonnable comparé au fine-tuning. On parle de quelques dollars pour indexer ta doc, versus des milliers pour fine-tuner un modèle.
Le Model Context Protocol (MCP) est un protocole ouvert qui standardise la façon dont les LLMs accèdent aux outils et aux données externes. Annoncé par Anthropic en novembre 2024, il a été rapidement adopté par les gros players.
Si tu veux une analogie, MCP c'est l'USB-C de l'IA : un connecteur universel qui permet à n'importe quelle application d'IA de parler à n'importe quelle source de données via un protocole unique.
Avant MCP, c'était l'enfer de l'intégration. Si tu avais M applications d'IA et N outils/sources de données, tu devais construire M×N intégrations custom. GitHub, Google Drive, Slack, Postgres — chaque combo nécessitait son connecteur spécifique.
Avec MCP, tu transformes le problème en M+N : chaque application implémente le client MCP une fois, chaque outil implémente le serveur MCP une fois, et tout fonctionne ensemble.
Tools : des fonctions exécutables que l'IA peut appeler (search_database, create_file, send_email)
Resources : des sources de données en lecture (contenu de fichiers, documentation, résultats d'API)
Prompts : des templates réutilisables qui guident l'utilisation des tools et resources
MCP est encore jeune mais l'adoption est explosive. C'est un standard ouvert, soutenu par les gros players, avec des SDKs officiels en Python, TypeScript, Java, Kotlin, Ruby, et PHP.
Si tu construis une application d'IA en 2025, ignorer MCP serait comme ignorer REST en 2010. C'est la couche de connectivité standard qui émerge.
Tu peux déjà consommer plus de 1000 serveurs MCP existants pour donner des capacités étendues à ton IA : accès à Linear, Stripe, Slack, Notion, etc. Sans écrire une ligne de code d'intégration.
Deux patterns avancés méritent d'être mentionnés parce qu'ils changent vraiment la donne.
Le chain-of-thought prompting force le modèle à raisonner explicitement étape par étape avant de répondre.
Plutôt que de demander directement "Quel est le résultat ?", tu ajoutes "Réfléchis étape par étape" ou tu fournis des exemples montrant le raisonnement intermédiaire.
Exemple :
Q: Roger a 5 balles de tennis. Il achète 2 boîtes de 3 balles chacune.
Combien a-t-il de balles ?
A: Roger a démarré avec 5 balles.
2 boîtes × 3 balles = 6 balles.
5 + 6 = 11.
Réponse: 11.
Le CoT améliore drastiquement les performances sur les tâches de raisonnement complexe. On parle de gains de 30 à 60% sur certains benchmarks.
C'est particulièrement utile pour du debugging, de l'analyse de code, ou de la résolution de problèmes multi-étapes.
Le function calling, c'est la capacité d'un LLM à invoquer intelligemment des fonctions externes.
Tu définis un ensemble de fonctions avec leurs signatures JSON Schema, tu les passes au modèle, et quand l'utilisateur pose une question nécessitant ces fonctions, le modèle répond avec un appel de fonction structuré que tu exécutes dans ton code.
Exemple : tu définis get_weather(location: string) et send_email(to: string, subject: string). L'utilisateur dit "Envoie-moi la météo de Paris par email".
Le LLM génère deux appels :
get_weather("Paris")send_email("user@example.com", "Météo Paris", contenu)Ces patterns sont la différence entre "poser des questions à ChatGPT" et "construire des systèmes autonomes". Tu passes d'un assistant passif à un agent actif capable d'interagir avec le monde réel.
Si t'as tenu jusqu'ici, bravo. Tu sais maintenant ce qui se passe vraiment quand tu appuies sur Entrée.
Tu sais qu'un token n'est pas un mot. Qu'un embedding, ce sont des coordonnées GPS pour le sens. Que le RAG est ta bouée de sauvetage contre les hallucinations. Que MCP est le futur standard. Et que la température contrôle si ton IA délire ou pas.
Tu n'es plus le dev qui appuie sur Entrée en croisant les doigts. Tu es celui qui comprend les leviers. Celui qui sait pourquoi ça merde. Et surtout, celui qui peut expliquer pourquoi en réunion sans passer pour un imposteur.
L'IA générative, ce n'est pas de la magie. C'est des stats avancées, des modèles probabilistes, des vecteurs à plusieurs dimensions, et du prompt engineering méthodique.
Ça se debugge. Ça s'optimise. Ça se monitor. Comme ton code PHP.
La seule différence : ton code est déterministe, l'IA est probabiliste. Tu dois apprendre à penser en distributions de probabilités plutôt qu'en if/else. En "ça devrait marcher 95% du temps" plutôt qu'en "ça marche toujours".
Ce site utilise Umami pour analyser le trafic de manière anonyme. Acceptez-vous la collecte de données anonymes ?