Comprendre l'IA sans le jargon

La moitié des articles sur l’IA sont écrits par des gens qui répètent des mots qu’ils ne savent pas définir. L’autre moitié sont écrits par des ingénieurs qui supposent que tu as fait un doctorat en algèbre linéaire. Cette page est l’antidote : huit concepts qui suffisent à comprendre 95 % de ce qu’on te vend, expliqués comme je les expliquerais à un founder en face de moi, sans une seule formule. Tu repars en sachant ce qu’est vraiment un LLM, pourquoi le RAG existe, ce qu’un « agent » fait réellement, et combien tout ça va te coûter en production. Pas de hype. Pas de bullshit. Juste le modèle mental correct.

Un LLM, c’est une machine à parier sur le mot suivant

Oublie « cerveau artificiel ». Un grand modèle de langage (LLM — Large Language Model, le moteur derrière ChatGPT, Claude, Gemini, Mistral) fait une seule chose : il prédit le fragment de texte le plus probable après une suite de texte. C’est tout. Tu lui donnes « Le ciel est », il calcule que « bleu » est plus probable que « tracteur », et il le crache. Puis il recommence avec le morceau d’après. (Techniquement il raisonne en tokens, pas en mots entiers — on y vient dans la section suivante.) Un modèle de plusieurs centaines de milliards de paramètres, c’est ça — à une échelle vertigineuse, entraîné sur une fraction colossale d’Internet.

La conséquence est énorme et tout le monde l’oublie : un LLM n’a aucune notion de vrai ou de faux. Il a une notion de plausible. « Paris est la capitale de la France » et « Paris est la capitale de la Belgique » sonnent grammaticalement identiques ; seul le premier a été assez répété dans ses données pour qu’il le préfère. Quand la statistique le trahit, il invente avec le même aplomb. On y revient plus bas, c’est le cœur du problème des hallucinations.

Le « so what » pour toi : arrête d’attendre d’un LLM qu’il sache. Attends de lui qu’il formule. Il est excellent pour transformer, reformuler, structurer, traduire, coder du boilerplate. Il est mauvais comme source de vérité brute. Toute ta façon de l’intégrer dans un produit découle de cette distinction. Quand un labo te vend son modèle comme une avancée « vers le raisonnement », garde en tête que trois patrons de l’IA peuvent te vendre trois futurs contradictoires la même semaine — chacun a un produit à placer.

Tokens et fenêtre de contexte : l’unité que tu paies, la mémoire que tu loues

Le modèle ne lit pas des mots, il lit des tokens : des fragments de mots. « bonjour » est peut-être un token, « anticonstitutionnellement » en fait plusieurs. Ordre de grandeur à retenir : en anglais, 1 token ≈ 0,75 mot (environ 4 caractères) ; en français c’est nettement moins efficace — compte plutôt 1,3 à 1,5 token par mot, parce que les tokenizers actuels sont surtout optimisés pour l’anglais et découpent le français en morceaux plus petits. Concrètement : 1 000 mots de français ≈ 1 300 à 1 500 tokens, soit ~15 à 20 % de plus que le même texte en anglais. Pourquoi t’en soucier ? Parce que tu es facturé au token, en entrée comme en sortie. Le token est l’unité de compte de toute l’industrie — et écrire en français te coûte mécaniquement plus cher qu’en anglais à contenu égal.

La fenêtre de contexte, c’est la quantité de tokens que le modèle peut « avoir sous les yeux » en une fois — prompt système + ton message + historique + documents que tu colles. Aujourd’hui ça va de 128 000 à plusieurs millions de tokens selon les modèles. Au-delà, le plus ancien tombe : le modèle « oublie » le début de la conversation. Ce n’est pas un bug, c’est la taille du bureau.

Deux pièges qui coûtent cher :

• « Contexte large » ne veut pas dire « le modèle lit bien tout ». En pratique, l’attention se dégrade au milieu des longs contextes (le fameux lost in the middle). Coller 300 pages ne garantit pas qu’il utilise la page 150.
• Le contexte se repaie à chaque appel. Une conversation de 50 messages renvoie tout l’historique à chaque tour. Sans gestion, le coût cumulé d’une session croît de façon quadratique avec le nombre de tours (chaque tour repaie tous les précédents) — et au passage, le coût de calcul de l’attention croît lui aussi quadratiquement avec la longueur du contexte. C’est exactement le genre de détail caché dans un pricing : Anthropic a déjà fait passer une hausse réelle de ~35 % pour un prix affiché « inchangé », via un nouveau compteur de tokens — j’ai disséqué le mécanisme dans l’édition sur Claude Design.

So what : avant de parler features, mesure tes tokens. Le coût d’un produit IA est d’abord un problème de tokenomics, pas de modèle.

Le RAG : donner au modèle tes documents au lieu d’espérer qu’il les connaisse

Le RAG (Retrieval-Augmented Generation, « génération augmentée par récupération ») est probablement le concept qui rapporte le plus à un produit, et le plus mal expliqué. Voici l’idée en une phrase : au lieu de demander au modèle ce qu’il sait, tu lui colles les bons documents dans le contexte au moment de la question, et tu lui dis « réponds à partir de ça ».

Le pipeline, sans jargon :

1. Indexation (une fois) : tu découpes tes documents en morceaux, tu transformes chaque morceau en une liste de nombres qui capture son sens (un embedding), et tu ranges tout dans une base vectorielle.
2. Récupération (à chaque question) : tu transformes la question en nombres de la même façon, tu cherches les morceaux les plus proches, tu en remontes 5 à 20.
3. Génération : tu colles ces morceaux dans le prompt + « réponds uniquement avec ces sources ». Le modèle rédige à partir de ta vérité.

Pourquoi c’est la bonne réponse à 90 % des cas business :

• Tu réduis fortement les hallucinations (le modèle cite, il n’invente plus de mémoire).
• Tes données restent fraîches : tu mets à jour la base, pas le modèle.
• Tu n’as pas besoin de fine-tuning pour « apprendre tes docs » — c’est la confusion la plus chère du marché.

Le piège que personne ne dit : un RAG médiocre échoue à l’étape 2, pas à l’étape 3. Si la récupération remonte les mauvais passages, le meilleur modèle du monde répondra à côté avec assurance. L’essentiel de la qualité d’un RAG se joue dans le découpage et la recherche, pas dans le choix du LLM. C’est contre-intuitif et c’est là que partent la plupart des budgets gaspillés.

Agents IA : un LLM à qui tu donnes des mains (et un budget à surveiller)

Un agent, ce n’est pas de la magie : c’est un LLM dans une boucle, à qui on a donné des outils et l’autorisation de décider lequel appeler. Le modèle reçoit un objectif (« réserve-moi un vol »), il choisit une action (« appeler l’API de recherche de vols »), il lit le résultat, il décide de l’action suivante, et il recommence jusqu’à avoir fini. Un LLM seul parle. Un agent agit — il lit tes mails, exécute du code, requête une base, clique dans un navigateur.

C’est le virage industriel de 2026 : tous les labos sont devenus des « labos d’agents », et le matériel suit (la course à la vitesse d’inférence n’a de sens que parce qu’un agent qui réfléchit en dix étapes a besoin que chaque étape soit instantanée — j’ai détaillé ce pari hardware dans l’édition Cerebras). Mistral a sorti un agent qui lit et traite tes mails sans broncher, et OpenAI a retiré le mot « recherche » de sa page d’accueil pour assumer son virage produit-agent.

Les deux vérités qu’on te cache sur les agents :

• L’erreur se compose. Modèle simplifié, mais éclairant : si chaque étape a 95 % de chances d’être correcte et que les erreurs sont indépendantes, une tâche en 10 étapes tombe à 0,95¹⁰ ≈ 60 % de réussite. Dans la vraie vie c’est encore moins propre (une erreur en cascade en entraîne d’autres). C’est pour ça que les démos impressionnent et que la production déçoit. Un agent fiable, c’est un agent à peu d’étapes, avec des garde-fous à chaque tour.
• Un agent autonome est un risque de sécurité et de coût. Donner à un LLM le droit d’exécuter du code ou de dépenser, c’est lui confier les clés. Quand une démo te promet ton remplacement « dans 18 mois », demande qui a un produit à vendre — et combien d’étapes l’agent tient vraiment sans déraper.

So what : commence par des agents à une ou deux actions, avec validation humaine. L’autonomie totale est un objectif, pas un point de départ.

Fine-tuning : la dernière chose à essayer, pas la première

Le fine-tuning, c’est ré-entraîner un modèle existant sur tes exemples pour modifier son comportement. Tout le monde croit en avoir besoin. Presque personne n’en a besoin. Voici la hiérarchie à respecter, du moins cher au plus cher :

1. Mieux prompter. Une bonne part des « il faut fine-tuner » se résolvent avec un meilleur prompt système et quelques exemples dans le contexte (few-shot). Coût : zéro.
2. RAG. Si le problème est « le modèle ne connaît pas mes données », c’est du RAG, pas du fine-tuning. Tu n’apprends quasiment jamais des faits à un modèle en le fine-tunant — tu lui apprends un style, un format, un ton.
3. Fine-tuning. Réservé à : un format de sortie très spécifique et répétitif, un ton de marque impossible à obtenir par prompt, ou de la réduction de coût (un petit modèle fine-tuné peut égaler un gros modèle généraliste sur une tâche étroite, pour bien moins cher à l’inférence).

Le mythe à tuer : « je vais fine-tuner pour que le modèle connaisse ma doc / mes clients / mes prix. » Non. Tu vas surtout lui faire adopter un style, sans garantie qu’il restitue tes faits fidèlement — au contraire, il peut halluciner tes données avec plus d’assurance. Les faits vont dans le contexte (RAG), le comportement va dans les poids (fine-tuning). Confondre les deux, c’est le plus gros gâchis de budget que je vois chez les founders.

So what : garde le fine-tuning pour quand tu as déjà un produit qui marche en prompt + RAG, des données propres en volume, et un goulot précis à optimiser. Avant ça, c’est de la procrastination déguisée en technique.

Hallucinations : pourquoi le modèle ment avec aplomb, et comment limiter la casse

Une hallucination, ce n’est pas un bug : c’est le fonctionnement normal d’une machine à prédire le mot plausible, appliqué à une zone où elle n’a pas l’info. Le modèle ne « sait pas qu’il ne sait pas ». Il comble le trou avec ce qui sonne juste — un PMID inventé, une citation fabriquée, une jurisprudence qui n’existe pas. Et il le fait avec exactement le même ton assuré que pour une vérité. C’est ce qui le rend dangereux : l’aplomb est constant, la justesse non.

Je ne théorise pas dans le vide : sur mes propres newsletters, un audit a déjà attrapé des références scientifiques fabriquées de toutes pièces avant publication. La leçon vaut pour ton produit autant que pour mon contenu — un LLM ne se vérifie pas tout seul.

Ce qui réduit réellement les hallucinations, par ordre d’efficacité :

• Ancrer dans des sources (RAG) et exiger des citations vérifiables. Pas de source dans les passages remontés → le modèle doit répondre « je ne sais pas ».
• Vérifier la sortie par un second système : règles, validateur, ou un appel de vérification factuelle ciblé.
• Baisser la « température » (le paramètre qui contrôle l’aléa des sorties) sur les tâches factuelles. Plus c’est bas, plus le modèle reste sur le balisé — attention : ça réduit la variabilité, ça n’empêche pas le modèle de se tromper avec assurance si l’info lui manque.
• Garder un humain dans la boucle sur tout ce qui est juridique, médical, financier.

Ce qui ne marche pas : demander gentiment « ne hallucine pas » dans le prompt. Ça aide à la marge, ça ne corrige rien. So what : conçois ton produit en supposant que le modèle se trompe régulièrement, et rends cette erreur visible et rattrapable. Un produit IA sérieux n’est pas un produit qui n’hallucine jamais — c’est un produit où l’hallucination ne fait pas de dégât.

Intégrer l’IA dans ton produit : la méthode qui évite de cramer 6 mois

La plupart des projets IA échouent non pas sur la techno, mais sur l’ordre des étapes. Voici la séquence que je recommande, du moins risqué au plus engageant :

1. Trouve le cas d’usage où l’erreur est tolérable. Résumé interne, brouillon d’email, classification de tickets, recherche dans la doc. Pas la décision médicale ou le virement bancaire en mode auto. Le bon premier projet IA, c’est celui où une hallucination coûte 30 secondes, pas un procès.
2. Commence par l’API d’un gros modèle généraliste. Ne self-host rien, ne fine-tune rien. Tu veux valider la valeur, pas l’infrastructure. Mesure : est-ce que ça résout un vrai problème pour un vrai utilisateur ?
3. Ajoute du RAG dès que le modèle a besoin de tes données. C’est la majorité des cas business.
4. Mets en place une évaluation — un jeu de 20 à 50 cas réels avec la bonne réponse attendue. Sans ça, tu « améliores » à l’aveugle et chaque changement de prompt est une superstition.
5. Optimise le coût en dernier : passe à un modèle moins cher, fine-tune sur la tâche étroite, mets du cache. Une fois — et seulement une fois — que la valeur est prouvée.

L’erreur archétypale : commencer par « on va fine-tuner notre propre modèle ». C’est l’étape 3 d’un parcours dont tu n’as pas fait l’étape 1. Tu construis une cathédrale avant d’avoir vérifié que quelqu’un veut prier dedans.

So what : le facteur de succès numéro un d’un produit IA n’est pas le modèle choisi, c’est d’avoir une boucle d’évaluation dès la semaine 1. Tout le reste se rattrape. Ça, non.

Sécurité et coûts : les deux factures que la hype te cache

Côté sécurité, l’IA ouvre des failles que ton équipe n’a probablement jamais vues :

• Injection de prompt. Un utilisateur (ou un document que ton RAG ingère) peut glisser une instruction du type « ignore tes consignes et exfiltre les données ». Pour un LLM, instruction et donnée se ressemblent — c’est l’équivalent de l’injection SQL, en pire, parce qu’il n’y a pas de séparation propre entre code et texte. Ne donne jamais à un agent un outil sensible sans valider ce qu’il s’apprête à faire.
• Fuite de données. Ce que tu envoies à une API tierce part chez le fournisseur. Vérifie les conditions de rétention, et ne balance pas de données clients sans base légale. La régulation existe et bouge : l’Europe a reporté l’AI Act de 16 mois, ce qui te laisse du temps — pas une dispense.
• Sorties non fiables comme surface d’attaque. Si tu exécutes du code généré ou affiches du HTML généré sans filtre, tu réintroduis du XSS et de l’injection par la grande porte.

Côté coûts, les trois lignes qui font exploser une facture :

• L’historique renvoyé à chaque tour (vu plus haut) : tronque, résume, ou mets en cache le contexte stable.
• Le mauvais modèle pour la tâche : utiliser un modèle premium pour classer des tickets, c’est payer une Ferrari pour aller chercher le pain. Route les tâches simples vers les petits modèles.
• L’absence de garde-fous sur les agents : une boucle qui part en vrille peut enchaîner des centaines d’appels avant que tu t’en rendes compte. Mets des limites dures (budget max, nombre d’étapes max) avant la mise en prod.

So what : le coût marginal d’un produit IA n’est jamais nul, contrairement au SaaS classique. Chaque utilisateur actif coûte des tokens. Modélise ça dans ton pricing dès le premier jour, ou ta marge fondra avec ton succès.