Comprendre l'agentique en profondeur

Pourquoi cet article existe.

Le manifeste Stella, la vision 2030 et la feuille de route sont écrits pour être lisibles par un comité de direction non-technique en moins de 15 minutes. Cela signifie qu'on a coupé la profondeur technique au profit de la clarté.

Mais quand on choisit l'infrastructure d'intelligence d'une organisation, à un moment donné, quelqu'un doit comprendre ce qu'on signe. Cet article s'adresse à cette personne — directeur technique, responsable SI, journaliste, dirigeant tech-curieux, autre acteur ESS-tech qui veut creuser. Tous les termes techniques retirés des pages principales sont ici, expliqués sans diluer ce qu'ils veulent dire.

On commence par la distinction qui change tout : un LLM n'est pas un agent.

LLM versus agent — la distinction qui multiplie tout par cent.

Un LLM (Large Language Model) — un grand modèle de langage, ChatGPT ou Claude dans leur forme la plus simple — est un système qui répond à une question. Vous envoyez un prompt, il renvoie une réponse. Un échange. Une requête, une sortie.

Un agent IA est autre chose. Un agent ne répond pas, il fait. Il perçoit une situation, il raisonne, il planifie, il appelle des outils, il observe les résultats, il ajuste, il recommence. Un agent tourne en boucle. Il prend une tâche — "organise ma semaine", "traite cette facture", "écris cet article en cherchant les sources" — et l'exécute jusqu'au bout, parfois sur plusieurs dizaines ou centaines d'étapes internes.

Cette différence est fondamentale. Là où un échange avec un chatbot consomme l'équivalent d'une recherche Google un peu plus gourmande, une tâche agentique peut consommer cinquante à deux cents fois plus. Parfois davantage. Chaque tour de boucle est un appel complet au modèle, avec un contexte qui grossit à chaque itération. Chaque outil invoqué est une transaction supplémentaire. Chaque agent qui en déclenche un autre — parce que l'orchestration multi-agents se généralise — multiplie encore la facture.

Quand vous lisez "consommation × 50 par rapport à un appel ChatGPT", c'est de cela qu'on parle.

Tokens, contexte, mémoire — la matière première qu'on facture.

Les modèles ne lisent pas des mots. Ils lisent des tokens — des fragments qui correspondent grossièrement à trois quarts d'un mot en français. "Construction" fait environ 3 tokens. "Anticonstitutionnellement" en fait 8. Une page de texte standard fait à peu près 500 tokens.

La facturation d'un modèle propriétaire (Claude, GPT, Gemini) se fait au token : on paye ce qu'on envoie (input) et ce qu'on reçoit (output). Les fournisseurs distinguent prix d'entrée et prix de sortie, le second étant souvent 3 à 5 fois plus cher.

Le contexte est l'ensemble du texte que le modèle a en tête à un moment donné : votre prompt initial, l'historique de la conversation, les documents fournis, les outils disponibles. Plus le contexte est long, plus chaque appel est cher — et plus le modèle peut perdre en précision.

Pour un agent qui boucle, le contexte croît à chaque tour. Un agent qui a fait dix étapes reçoit, à la onzième, l'historique des dix précédentes. Résultat : le nombre de tokens traités ne croît pas linéairement, mais quadratiquement avec la longueur de la tâche. Une tâche qui demande cinquante étapes ne coûte pas cinquante fois une requête simple. Elle coûte plusieurs centaines de fois plus.

La mémoire persistante est l'ensemble des informations que l'agent conserve d'une session à l'autre. Bien conçue, elle évite de re-charger tout le contexte à chaque conversation. Mal conçue, elle reproduit le contexte ad infinitum et fait exploser la consommation. Stella conçoit ses agents avec mémoire compressée hiérarchique : la conversation courante est en mémoire vive, les éléments structurants vont dans une base persistante, le bruit est jeté.

Le paysage 2026 — frontier, open source, local.

Trois familles de modèles cohabitent en 2026, avec des modèles économiques et énergétiques très différents.

Les modèles frontier propriétaires

Les "modèles frontier" désignent les plus avancés du moment. En avril 2026, ce sont essentiellement OpenAI (GPT-5 et variantes), Anthropic (Claude 4 Opus / Sonnet / Haiku), Google (Gemini 3 Pro), plus quelques challengers comme xAI (Grok). Ils sont dits "propriétaires" parce que leurs poids ne sont pas publics, et qu'on y accède uniquement par API en payant au token. Hébergés majoritairement aux États-Unis. Excellents sur le raisonnement complexe, le code avancé, les tâches multilingues nuancées.

L'open source qui a rattrapé

Cinq familles ont atteint le niveau frontier en 2026, toutes avec poids librement téléchargeables :

• DeepSeek V4 (sortie 24 avril 2026, MIT) — 1,6 trillion de paramètres totaux dont 49 milliards activés à la fois (architecture MoE — voir glossaire), 1 million de tokens de contexte. Score MMLU 88,4%. Entraîné pour 5,6 millions de dollars.
• Qwen 3.5 (Alibaba) — versions 7B à 397B, raisonnement compétitif.
• Kimi K2.6 (Moonshot AI) — 1,1 trillion paramètres, scores de premier plan.
• GLM-5.1 (Zhipu AI) — dépasse GPT-5.4 et Claude Opus 4.6 sur SWE-Bench Pro (benchmark de code), un événement majeur de 2026.
• Mistral Large 3 — européen, conformité RGPD facilitée.

Le retard de l'open source sur le frontier est passé de 18-24 mois en 2024 à 3-6 mois en avril 2026. Sur certaines tâches (code, multilingue, multimodal léger), il n'y a plus de retard — l'open source dépasse.

Le local — exécution sur votre matériel

Distincte des deux précédentes : la possibilité de faire tourner des modèles directement sur l'appareil de l'utilisateur, sans connexion à un serveur distant.

• Apple Intelligence — modèle 3 milliards de paramètres on-device, quantization 2-bit, 30 tokens/seconde sur iPhone 15 Pro, latence 0,6 ms par token de prompt.
• Phi-4 SambaY (Microsoft) — architecture hybride combinant State Space Models et attention classique. 10× le débit d'un transformer classique.
• BitNet (Microsoft, MIT) — modèles quantizés à 1-bit, taille 2-8 milliards de paramètres. Ouvre une porte vers des modèles 8× plus rapides en consommant 5× moins de mémoire.
• PrismML Bonsai 8B (mars 2026) — premier 1-bit commercialement viable, 1,15 GB en mémoire, qualité GPT-4-class de 2024.

Conséquence concrète : un MacBook Air M4 fait tourner en local un modèle qui aurait nécessité un cluster GPU il y a deux ans. Un iPhone 17 Pro exécute des agents simples sans sortir de l'appareil.

Stella oriente progressivement les tâches simples vers le local, les tâches lourdes vers l'open source en cloud privé européen, et réserve le frontier propriétaire au raisonnement complexe.

Comprendre les benchmarks — MMLU, SWE-Bench, et leurs limites.

Les benchmarks sont des tests standardisés qui permettent de comparer les modèles. Les principaux en 2026 :

• MMLU (Massive Multitask Language Understanding) — 15 000 questions à choix multiples couvrant 57 domaines (médecine, droit, mathématiques, histoire). Score sur 100. Un humain expert plafonne autour de 90%. Les meilleurs modèles 2026 sont à 88-92%.
• SWE-Bench Pro — 2 294 issues réelles tirées de GitHub que le modèle doit résoudre en proposant un patch fonctionnel. Évalue la capacité de programmation réelle. GLM-5.1 : 58,4%. Claude Opus 4.6 : 57,3%.
• Humanities-X — benchmark introduit en 2025 pour tester le raisonnement humaniste, philosophique, littéraire — les domaines où MMLU est insuffisant.
• HumanEval — 164 problèmes de programmation Python. Plus simple que SWE-Bench. Saturé : la plupart des modèles dépassent 90%.
• Arena Elo (LMSYS) — classement basé sur des préférences humaines en duel aveugle. Plus représentatif de l'usage réel.

Limites importantes :

• Les benchmarks peuvent être contaminés — leurs questions retrouvées dans les données d'entraînement, gonflant artificiellement les scores.
• Un score MMLU de 88% ne dit rien de la fiabilité du modèle sur votre domaine spécifique.
• Aucun benchmark ne mesure les qualités qui comptent pour Stella : alignement éthique, respect du refus, traçabilité des décisions.

C'est pour cela que nous évaluons les modèles sur les tâches réelles de nos clients, pas sur les benchmarks marketing.

Quantization, BitNet, on-device — la course à la compression.

La quantization est la technique qui consiste à réduire la précision avec laquelle les paramètres d'un modèle sont stockés. Un modèle non quantizé utilise 16 bits par paramètre (FP16). Le quantizé peut descendre à 8, 4, 2, voire 1 bit (BitNet). Plus le nombre de bits est faible, plus le modèle est compact, rapide, et consomme peu — au prix d'une légère perte de qualité, qu'on cherche à minimiser.

BitNet (Microsoft, MIT) pousse l'idée à l'extrême : un seul bit par paramètre. Cela paraissait impossible il y a deux ans. En 2026, BitNet scale jusqu'à 8 milliards de paramètres avec une qualité étonnamment bonne. PrismML Bonsai 8B est le premier modèle 1-bit commercialement viable : 1,15 GB en mémoire, 8× plus rapide que son équivalent FP16.

FP8 natif est devenu le standard pour les GPU récents (Hopper, Blackwell). Compromis entre qualité et performance. Probablement la quantization de production dominante en 2027.

On-device signifie "qui s'exécute directement sur l'appareil de l'utilisateur" (téléphone, ordinateur, embarqué) sans envoyer de données à un serveur distant. Apple Intelligence est l'exemple le plus déployé. Stella considère le on-device comme la cible long terme pour les tâches simples (classification, extraction, brouillon) — pas pour le raisonnement profond, qui restera en cloud à moyen terme.

Architecture agnostique, lock-in, où vivent les données.

Le lock-in (verrouillage) désigne la situation dans laquelle un client devient si dépendant d'un fournisseur qu'en sortir devient prohibitivement coûteux. Dans l'agentique, le lock-in se construit subrepticement : prompts système formattés au standard d'un fournisseur, mémoire stockée dans un format propriétaire, intégrations métier câblées via leur API spécifique, équipe formée à leur outil spécifique. Au bout de deux ans, sortir de l'écosystème = refaire l'intégralité de l'infrastructure.

Une architecture agnostique évite le lock-in en assurant que chaque brique du système soit remplaçable :

• Le modèle de langage est appelé via une couche d'abstraction qui peut basculer Claude → DeepSeek → Mistral sans réécrire le code.
• La mémoire est stockée dans un format ouvert (JSON, Markdown), pas dans une base de données propriétaire.
• Les outils sont câblés via des standards (MCP, OpenAPI), pas via des SDK spécifiques.
• Les prompts système sont versionnés en Markdown, lisibles, portables.

Où vivent les données. Dans une architecture Stella, les données opérationnelles du client (fichiers, e-mails, CRM, logiciels métier) restent chez le client. L'agent y accède en lecture via des connexions sécurisées. Les seules données qui transitent par les API des modèles propriétaires sont les fragments nécessaires à la tâche en cours (prompt + contexte limité), et uniquement pour les modèles propriétaires — le reste tourne en cloud privé européen ou en local.

RGPD et hébergement européen. Pour les structures soumises à des obligations strictes (collectivités, mutuelles, professions réglementées), Stella propose une configuration tout-européen : Mistral Large 3 ou DeepSeek V4 hébergés sur Scaleway, OVH ou Outscale. Aucun token n'atteint un serveur américain. Stella peut aussi proposer un hébergement à LAOM, en cloud privé en écolieu, pour les structures qui veulent ce niveau d'autonomie.

Empreinte écologique — ce qu'on mesure vraiment.

Mesurer l'empreinte d'une infrastructure agentique est techniquement non trivial. Voici la méthode Stella, simplifiée :

1. Tokens consommés par tâche. Chaque appel à un modèle est journalisé : nombre de tokens en entrée, en sortie, modèle utilisé, durée d'exécution.

2. Conversion en énergie. Pour chaque modèle, nous appliquons un facteur Wh/token estimé à partir de la littérature scientifique (papers Hugging Face, EpochAI, AI Energy Score). Un appel sur Claude Opus 4.7 consomme environ 2-3 Wh pour 1 000 tokens en sortie. Un appel sur DeepSeek V4 Flash consomme environ 0,3-0,5 Wh. Un appel local sur Bonsai 8B consomme environ 0,05 Wh.

3. Conversion en CO2. On multiplie par le facteur d'émission de la zone où tourne le modèle. France : 50 gCO2/kWh (très bas grâce au nucléaire). Allemagne : 350 gCO2/kWh. Texas : 450 gCO2/kWh. Un modèle hébergé en France émet 8 à 10 fois moins par tâche qu'un modèle hébergé au Texas.

4. Conversion en eau. Les datacenters consomment de l'eau pour le refroidissement, en quantité variable selon le PUE et la technologie. Estimation moyenne : 0,5 mL d'eau par 1 000 tokens en sortie.

5. Affichage agrégé. Le dashboard Stella affiche jour, semaine, mois : tokens consommés, Wh, gCO2, eau. Comparaison avec un benchmark "agentique propriétaire 100% Claude/GPT" pour mesurer l'écart.

Le paradoxe de Jevons. William Stanley Jevons a observé au XIXᵉ siècle que les gains d'efficacité énergétique du charbon n'avaient pas réduit la consommation totale, au contraire — ils l'avaient amplifiée par usage accru. L'agentique suit le même pattern. Plus les modèles deviennent efficaces, plus on en déploie, plus la conso totale grimpe. Aucune optimisation seule ne sortira de cette équation. Il faut une discipline architecturale (ne pas déployer un agent là où une fonction simple suffit), pas seulement une optimisation technique.

Source IEA 2026 : la consommation mondiale des datacenters atteindra 945 TWh en 2030, soit 3% de l'électricité mondiale, en doublement depuis 2024. Les serveurs orientés IA tripleront d'ici 2030. Aux États-Unis seulement, les datacenters ont consommé 17 milliards de gallons d'eau en 2023.

Glossaire — les termes en une ligne.

• Agent — système qui boucle : perçoit, raisonne, agit, observe, ajuste, recommence.
• Agnostique (architecture) — architecture où chaque brique est remplaçable, aucun fournisseur n'est verrouillé.
• API — interface programmatique pour appeler un service à distance.
• BitNet — famille de modèles à 1 bit par paramètre, ultra-compacts.
• Cloud privé européen — infrastructure d'hébergement en UE, RGPD-compatible (Scaleway, OVH, Outscale).
• Contexte — l'ensemble du texte dont le modèle dispose au moment d'un appel.
• FP16 / FP8 / FP4 — précision en bits utilisée pour stocker les paramètres d'un modèle.
• Frontier (modèle frontier) — les modèles les plus avancés du moment, généralement propriétaires.
• HumanEval — benchmark de programmation Python, désormais saturé.
• Inference — l'action d'utiliser un modèle déjà entraîné, par opposition à l'entraînement.
• LLM — Large Language Model, grand modèle de langage.
• Local (on-device) — exécution sur l'appareil de l'utilisateur, sans connexion serveur.
• Lock-in — verrouillage par dépendance technique à un fournisseur.
• MCP — Model Context Protocol, standard ouvert pour connecter des outils à un agent.
• MMLU — Massive Multitask Language Understanding, benchmark de connaissances multidomaines.
• MoE (Mixture of Experts) — architecture où seule une fraction des paramètres s'active par requête, économisant calcul.
• Open weights — modèle dont les paramètres sont publics et téléchargeables.
• Output (prix d'output) — facturation des tokens générés par le modèle, généralement 3-5× le prix d'input.
• PARA — méthode d'organisation de l'information en Projets / Areas / Resources / Archives.
• Paradoxe de Jevons — phénomène par lequel les gains d'efficacité augmentent la consommation totale par usage accru.
• Prompt — instruction donnée au modèle.
• PUE — Power Usage Effectiveness, ratio d'efficacité énergétique d'un datacenter.
• Quantization — technique de réduction de la précision des paramètres pour compresser un modèle.
• Skill — capacité d'agent codifiée pour un usage métier (ex. "rédiger compte-rendu", "classer mail").
• SOTA (state-of-the-art) — niveau de performance le plus élevé du moment.
• SWE-Bench — benchmark de programmation issu d'issues GitHub réelles.
• Token — fragment de texte (~3/4 d'un mot français) traité par le modèle.
• TWh — térawattheure, unité d'énergie. 1 TWh = 1 milliard de kWh = ~consommation annuelle d'une ville de 200 000 habitants.
• Wh / kWh — wattheure / kilowattheure, unités de mesure d'énergie consommée.