Qu'est-ce qu'un LLM ? Les fondamentaux pour les agents IA

Que signifie « le LLM comme moteur de raisonnement » ?

Un agent IA est plus qu'un chatbot : il poursuit un objectif sur plusieurs étapes, appelle des outils, observe les résultats et décide de la suite. Au cœur de cette boucle se trouve un grand modèle de langage (LLM) qui sert de moteur de raisonnement, c'est-à-dire l'instance qui planifie, pèse le pour et le contre, choisit les outils et interprète les résultats.

Une métaphore qui a marqué la pratique vient d'Andrej Karpathy (juin 2025) : le LLM est le CPU, la fenêtre de contexte la mémoire vive (RAM), et l'ingénieur joue le rôle du système d'exploitation, qui remplit cette mémoire à chaque étape avec les bonnes informations. D'où l'enseignement central pour 2026 : en production, les agents n'échouent presque jamais parce que le modèle est « trop petit ». Ils échouent parce que le contexte est mal construit. L'équipe Applied AI d'Anthropic présente le Context Engineering comme l'évolution naturelle du prompt engineering : la sélection des tokens qui atterrissent dans la fenêtre de contexte limitée. C'est de cette sélection que dépend la fiabilité d'un agent.

Si tu construis des agents, il te faut donc des bases solides sur quatre éléments : les tokens, la fenêtre de contexte, le Function Calling et le choix du modèle (open source ou propriétaire). Cette page de synthèse rassemble les fondamentaux ; les sujets approfondis (Context Engineering, RAG, FinOps, conformité) font chacun l'objet d'un module dédié.

Les tokens : unité de traitement et de coût

Les LLM ne traitent pas le texte sous forme de mots, mais de tokens, c'est-à-dire d'unités sous-lexicales qu'un tokeniseur produit à partir du texte. Les tokens sont aussi l'unité de facturation : les fournisseurs facturent séparément les tokens d'entrée et de sortie, le plus souvent par million de tokens.

Dans la région DACH (Allemagne, Autriche, Suisse), la tokenisation n'a rien d'un sujet secondaire : c'est un facteur de coût mesurable. Avec les tokeniseurs BPE courants, l'allemand génère 30 à 50 % de tokens de plus que l'anglais pour un contenu équivalent. Les causes :

• Noms composés : « Lebensversicherungsgesellschaftsangestellter » se décompose en une longue chaîne de sous-mots, alors que « life insurance company employee » se découpe en tokens de mots familiers.
• Flexion : les terminaisons casuelles et verbales de l'allemand produisent des variantes morphologiques qui sont traitées comme des sous-mots distincts.
• Biais du tokeniseur : les données d'entraînement des tokeniseurs courants sont dominées par l'anglais ; les sous-mots allemands rares sont découpés plus finement.

Il en découle trois conséquences pratiques. D'abord, les fenêtres de contexte effectives contiennent moins de contenu (une fenêtre de 200K n'accueille qu'autant de contenu allemand qu'en occuperaient environ 130K-150K tokens en anglais). Ensuite, les coûts par appel augmentent en conséquence de 30 à 50 %. Enfin, le prompt caching est encore plus rentable pour les charges de travail en allemand que pour les charges anglophones, car la remise s'applique à un nombre de tokens plus élevé.

Point important pour la migration de modèles : Claude Opus 4.7 a été livré avec un nouveau tokeniseur qui, pour de nombreuses entrées, génère jusqu'à 35 % de tokens de plus qu'Opus 4.6 ; à prix par token identiques, le coût effectif par requête peut donc augmenter du seul fait du changement de tokeniseur. Avant toute migration, fais un benchmark sur ton propre profil de charge de travail.

La fenêtre de contexte : nominale ou effective

La fenêtre de contexte est le nombre maximal de tokens qu'un modèle peut « voir » par requête : prompt système, définitions d'outils, contenus récupérés, historique de conversation et place réservée à la réponse, le tout réuni. En 2026, les fenêtres nominalement grandes sont la norme : Claude Opus 4.7 et Sonnet 4.6 prennent en charge 1M de tokens, Gemini 3.1 Pro aussi environ 1M.

Le point décisif, toutefois : capacité nominale ne veut pas dire capacité effective. L'étude « Context Rot » de Chroma (juillet 2025, 18 modèles frontier) a montré empiriquement que tous les modèles se dégradent à mesure que la longueur de l'entrée augmente. Trois mécanismes se renforcent mutuellement :

1. Lost-in-the-Middle : les modèles prêtent davantage attention au début et à la fin du contexte, moins au milieu.
2. Dilution de l'attention : la complexité quadratique de l'attention signifie qu'à 100K tokens, on compte déjà environ 10 milliards de relations par paires.
3. Interférence des distracteurs : des contenus sémantiquement proches mais non pertinents poussent activement à de mauvaises réponses.

Le constat dépend de la tâche : pour la simple récupération de faits, les modèles récents ont nettement rattrapé leur retard ; pour le raisonnement multi-hop, l'effet reste structurel. Heuristique pour la production : une capacité de travail effective de 30 à 50 % de la capacité nominale pour les tâches axées sur le raisonnement et de 60 à 80 % pour les tâches axées sur la récupération. Remplir entièrement une fenêtre de 1M, c'est du gaspillage, avec une perte de qualité en prime.

La réponse pratique au context rot n'est pas d'« en mettre plus », mais de faire le tri : mettre en cache les éléments stables, charger les contenus dynamiques de manière ciblée, élaguer les anciens contenus et compresser dès 70 à 85 % de remplissage (compaction). C'est l'objet du module Context Engineering.

Function Calling et tool use : le LLM passe à l'action

Pour qu'un LLM devienne le moteur d'un agent, il doit pouvoir agir, c'est-à-dire générer des appels structurés à des fonctions externes. Le Function Calling (ou tool use) est le mécanisme qui le permet : le modèle reçoit des définitions d'outils au format JSON Schema et renvoie au besoin un appel structuré avec des paramètres, que l'application exécute.

Le principal constat de terrain en 2026 : quand un agent agit mal, la cause se trouve rarement dans le modèle, mais le plus souvent dans la définition de l'outil. Anthropic formule la règle sans détour : si un ingénieur humain ne peut pas dire clairement quel outil utiliser dans une situation donnée, un agent ne le peut pas non plus. Conséquences concrètes :

• Nombre d'outils : l'optimum se situe à 3 à 7 outils chargés activement ; à partir d'environ 10 outils, une dégradation mesurable apparaît. Dans les évaluations MCP internes d'Anthropic, la précision de sélection des outils est passée, grâce à la recherche dynamique d'outils, de 49 % à 74 % (Opus 4) et de 79,5 % à 88,1 % (Opus 4.5).
• Le chevauchement d'outils est fatal : deux outils qui pourraient plausiblement répondre à la même requête constituent le seul problème qu'aucun prompt, aussi bon soit-il, ne résout. Une clause claire « quand ne pas l'utiliser » dans la description est le composant le plus efficace, et souvent oublié.
• Sorties structurées : pour les systèmes en aval, les sorties doivent être lisibles par machine de manière fiable. OpenAI Structured Outputs (disponible en GA depuis août 2024) atteint 100 % de conformité au schéma grâce au constrained decoding ; Anthropic obtient un résultat équivalent via le tool use avec JSON Schema, et les modèles open-weight via le grammar-constrained decoding (Outlines, jsonformer, vLLM).

En 2026, le standard pour connecter des outils est le Model Context Protocol (MCP), publié par Anthropic en novembre 2024 comme standard basé sur JSON-RPC. Selon des rapports sectoriels, les téléchargements du SDK sont passés d'environ 100 000 par mois (nov. 2024) à environ 97 millions par mois (mars 2026), avec une adoption par OpenAI, Google et Microsoft. (Ces chiffres de téléchargement proviennent de rapports de fournisseurs et du secteur et n'ont pas été validés de manière indépendante ; le schéma d'adoption lui-même est considéré comme incontestable.) Pour évaluer la qualité du tool calling, le Berkeley Function-Calling Leaderboard (BFCL) reste le benchmark le plus pertinent, avec une réserve : aucun modèle ne domine dans toutes les catégories, et les modèles closed-weight gardent l'avantage sur le tool use multi-tour complexe.

Open source ou propriétaire : le choix du modèle

Le choix du modèle de base est la décision stratégique la plus lourde de conséquences. En 2026, ce n'est plus une question binaire, mais une allocation de portefeuille. Commençons par clarifier les termes, car « ouvert » recouvre plusieurs dimensions :

• Fermé/propriétaire : uniquement via API, poids non disponibles (Claude, GPT-5.5, Gemini).
• Open-weight : poids téléchargeables, éventuellement sous des licences restrictives. Llama est open-weight, mais l'OSI et la FSF ne le classent expressément pas comme open source, notamment en raison d'un seuil de 700 millions de MAU et d'une restriction multimodale pour l'UE dans Llama 4.
• Open Source AI selon la définition de l'OSI (OSAID 1.0, oct. 2024) : exige en plus un code d'entraînement et d'inférence ouvert ainsi qu'une transparence suffisante sur les données d'entraînement. La plupart des modèles commercialisés comme « open source » n'atteignent pas ce seuil.

La tendance centrale : l'écart de capacités entre les meilleurs modèles open-weight (DeepSeek V4 Pro, Kimi K2.6, Mistral Large 3, Qwen 3.6, Llama 4 Maverick) et les modèles frontier fermés (en mai 2026 : Claude Opus 4.7, GPT-5.5 Pro, Gemini 3.1 Pro) s'est réduit de 12-18 mois (2024) à 3-6 mois (2026). Sur certaines charges de travail standard, comme le code de routine ou les problèmes de maths en dessous du niveau frontier, il est pratiquement nul. Ainsi, Kimi K2.6 (1 billion de paramètres, open-weight) se classe 4e de l'Artificial Analysis Intelligence Index (score de 54), juste derrière Anthropic, Google et OpenAI (57 chacun).

Dans le même temps, sur les charges de travail premium (codage agentique de pointe, maths de niveau frontier, contexte long, multimodal premium), les modèles frontier fermés restent réellement supérieurs. Dans de nombreuses entreprises, seule une petite partie du volume de tokens relève de cette catégorie premium, mais elle concentre une grande partie de la valeur stratégique. L'approche hybride devient donc une nécessité économique.

Prix selon les grilles publiques des fournisseurs, état avril-mai 2026 ; vérifie-les avant tout engagement pluriannuel.

Une logique de décision pragmatique repose sur quatre dimensions : contrôle des poids (qui peut fournir le modèle, quand et à quelles conditions ?), souveraineté de l'hébergement (à quelle juridiction la stack est-elle soumise ?), voie de personnalisation (prêt à l'emploi, prompt, RAG, LoRA, fine-tuning complet) et profil de coûts (paiement au token ou amortissement de l'auto-hébergement). Pour la plupart des charges de travail standard (classification, extraction, assistants de connaissances basés sur le RAG, workflows en langue allemande), la prime des modèles frontier fermés n'est plus économiquement indispensable.

Spécificités DACH : souveraineté et conformité

Dans la région DACH, trois facteurs pèsent en plus sur le choix du modèle. Premièrement, le sentiment de souveraineté : selon Bitkom (étude Digitale Souveränität 2025, 603 entreprises), 89 % des entreprises importatrices de technologies numériques se considèrent comme dépendantes ; dans le sondage auprès de la population (semaines 8 à 11 de 2026), 72 % jugent l'Allemagne trop dépendante des États-Unis en matière d'IA, et 67 % aimeraient utiliser une IA allemande. Mistral propose une option souveraine européenne commercialement crédible. Une deuxième pourrait naître de Cohere et d'Aleph Alpha : les deux entreprises ont scellé par contrat en septembre 2026 la fusion annoncée en avril 2026. Au moment de l'annonce, la valorisation s'élevait à environ 20 milliards de dollars selon la presse. La puissance de calcul doit être fournie par le groupe Schwarz via STACKIT. En septembre 2026, la finalisation restait soumise aux autorisations réglementaires. L'entité fusionnée doit opérer sous le nom de Cohere, avec un double siège à Toronto et à Berlin. Il s'agit donc d'une option canado-allemande, et non purement européenne.

Deuxièmement, une région UE chez un hyperscaler américain (par exemple Claude sur AWS Bedrock à Francfort) réduit la latence et les frictions liées au RGPD, mais n'élimine pas la juridiction américaine (CLOUD Act). Une véritable souveraineté suppose une stack souveraine européenne (STACKIT, OVHcloud, T-Systems, IONOS) ou une solution on-premise.

Troisièmement, quelques repères réglementaires (à titre informatif, sans valeur de conseil juridique) : les modèles fermés accessibles par API sont des modèles d'IA à usage général (GPAI) de leurs fournisseurs ; le déployeur assume les obligations de déployeur. Si tu fais un fine-tuning substantiel d'un modèle open-weight, tu peux toi-même devenir fournisseur de GPAI ; les lignes directrices du Bureau de l'IA de l'UE (juillet 2025) indiquent un seuil indicatif et non contraignant de >1/3 du calcul de pré-entraînement du modèle de base (par défaut 3,33 × 10²² FLOPs s'il est inconnu). LoRA/QLoRA restent en général nettement en dessous, le pré-entraînement continu au-dessus. Les obligations des fournisseurs de GPAI s'appliquent depuis le 2 août 2025. Depuis le 2 août 2026, la Commission européenne (Bureau de l'IA) peut aussi les faire respecter au moyen d'amendes (art. 101 et art. 113 du règlement sur l'IA). S'y ajoutent les obligations du RGPD qui pèsent sur le pipeline d'entraînement en cas de fine-tuning sur des données personnelles. Ces points sont approfondis dans les modules conformité correspondants.

Perspectives et conseil pratique

Les fondamentaux des LLM ne s'apprennent pas une fois pour toutes : c'est une cible mouvante. Les tokeniseurs changent, les fenêtres de contexte s'agrandissent, de nouveaux modèles sortent chaque mois et les scores des benchmarks varient de 5 à 10 points de pourcentage selon le test harness. Trois questions ouvertes méritent une attention particulière pour 2026/2027 : l'écart de capacités entre modèles ouverts et fermés va-t-il continuer à se réduire, les longues fenêtres de contexte vont-elles tenir la promesse du « tout mettre dedans » (pour l'instant : non, le Context Engineering reste nécessaire), et l'infrastructure souveraine européenne atteindra-t-elle la parité d'échelle avec les hyperscalers américains ?

En pratique, une discipline simple s'impose donc : ne choisis pas sur la foi d'un billet de blog marketing, mesure sur ton propre jeu d'évaluation. Si tu valides le choix du modèle, le budget de contexte et la conception des outils sur des traces réelles plutôt qu'à l'intuition, tu construis des agents qui tiennent en production et tu gardes la flexibilité stratégique de changer de fournisseur en cas d'évolution des prix, des licences ou des capacités, sans repartir de zéro.