La pile LLM en 2026 : modèles, inférence, outils et compromis

Si vous développez de véritables produits d’IA en 2026, vous ne vous demandez plus simplement s’il faut utiliser OpenAI ou Anthropic. Cette manière de poser le problème est obsolète depuis deux ans. Vous prenez des dizaines de décisions dans une pile à plusieurs couches, et la plupart sont importantes.

Cet article présente le point de vue d’un architecte en activité sur la pile LLM en 2026 : le contenu de chaque couche, les compromis à effectuer et l’évolution du domaine. C’est l’article que nous aurions aimé lire avant de commettre toutes les erreurs évitables.

Les couches

La pile, approximativement :

┌────────────────────────────────────┐
│       Application Layer            │  Your product / agent / workflow
├────────────────────────────────────┤
│   Orchestration / Frameworks       │  LangGraph, CrewAI, custom, direct
├────────────────────────────────────┤
│   Prompt + Context Management      │  Prompt templates, context engineering
├────────────────────────────────────┤
│   Retrieval / Memory               │  RAG, vector stores, structured memory
├────────────────────────────────────┤
│   Tool / MCP Layer                 │  Tool calling, MCP servers, function APIs
├────────────────────────────────────┤
│   Model Layer                      │  Specific model selection, routing
├────────────────────────────────────┤
│   Inference Layer                  │  Hosted APIs, self-hosted, edge
├────────────────────────────────────┤
│   Observability / Evals            │  Logging, tracing, eval suites
└────────────────────────────────────┘

Chaque couche dispose de plusieurs options viables. Le choix à un niveau limite les options à d’autres. Les décisions prises en amont sont difficiles à modifier — le choix du modèle influence le choix de l’inférence, qui influence à son tour le choix de l’orchestration.

Nous aborderons chaque couche.

Couche 1 : La couche modèle

En 2026, les modèles se répartissent en grandes catégories, et le choix d’une catégorie pour chaque appel constitue l’une des décisions les plus importantes de votre système.

Modèles de raisonnement de pointe. Les modes de raisonnement des meilleurs modèles actuels — GPT-5.5 avec raisonnement, Claude Opus 4.8 avec raisonnement adaptatif et Gemini 3.1 Pro avec raisonnement — ainsi que les modèles spécialisés tels que DeepSeek R1. Ils excellent dans les problèmes en plusieurs étapes, les mathématiques, le code et les analyses complexes. Ils sont coûteux (3 à 30 dollars par million de jetons en entrée, bien davantage en sortie) et lents (5 à 60 secondes). Utilisez-les lorsque la qualité du raisonnement constitue le principal facteur limitant.

Modèles généralistes de pointe. GPT-5.5, Claude Sonnet 5 et Gemini 3.1 Pro. Excellents pour la plupart des tâches fondées sur les connaissances, rapides (2 à 5 secondes) et d’un coût modéré (2 à 5 dollars par million de jetons en entrée). Ils constituent le choix par défaut pour fournir des réponses de grande qualité aux utilisateurs.

Modèles intermédiaires. Claude Haiku 4.5, Gemini 3.5 Flash et la gamme intermédiaire d’OpenAI. Adaptés aux tâches simples à modérément complexes, ils sont rapides (1 à 2 secondes) et peu coûteux (1 à 2,50 dollars par million de jetons en entrée). Ils sont largement utilisés en production pour la classification, l’extraction et la génération simple.

Petits modèles économiques. Les gammes les plus compactes des fournisseurs (par exemple Gemini 3 Flash Preview) et les petits modèles open source. Ils suffisent aux tâches ciblées et structurées, sont très peu coûteux (0,50 à 1 dollar par million de jetons en entrée) et très rapides (moins d’une seconde). Utilisez-les pour le routage, la notation et le traitement par lots.

(Prix vérifiés le 7 juillet 2026 contre les pages de tarification des fournisseurs ; les niveaux évoluent — vérifiez avant de citer.)

Modèles spécialisés. Modèles de plongement, de reclassement, de vision, de voix ou spécialisés dans le code. Plus économiques que les modèles généralistes pour leurs tâches propres, ils sont généralement aussi plus performants. Envisagez-les systématiquement lorsque la tâche s’y prête.

Modèles open source de pointe. Llama 4, DeepSeek V3/R2, Qwen 3 et Mistral Large. Ils sont proposés par des fournisseurs d’inférence (Groq, Together, Fireworks) ou auto-hébergés. Leur prix et leur qualité rivalisent avec ceux des modèles propriétaires de pointe pour de nombreuses tâches, mais restent en retrait pour certaines, notamment le raisonnement à long terme.

Les implications :

• Un seul modèle ne convient pas à tous les appels dans votre système. Le routage est obligatoire pour les coûts (voir Couche 1).
• La frontière évolue chaque trimestre. Construisez pour remplacer les modèles, pas pour les verrouiller.
• L’open source est désormais viable pour de nombreux cas d’usage en production, et plus seulement pour les expérimentations.

Couche 2 : La couche d’inférence

Où s’exécute effectivement votre modèle ?

Fournisseurs d’API propriétaires — OpenAI, Anthropic et Google. C’est la voie la plus rapide vers la production, avec les meilleurs modèles et une grande fiabilité. En contrepartie, vous payez un supplément et acceptez leur modèle de traitement des données et de sécurité.

Fournisseurs d’inférence pour modèles open source — Groq, Together AI, Fireworks et Replicate. Ils exécutent des modèles open source avec différents réglages et sont souvent bien plus rapides que l’auto-hébergement, à des tarifs compétitifs. (Ce marché se concentre rapidement : plusieurs fournisseurs de 2024 n’existent plus ; vérifiez tout fournisseur avant de vous engager.)

Services natifs du cloud — AWS Bedrock, Azure OpenAI et Google Vertex. Ils intègrent des modèles propriétaires et open source à l’authentification, à la facturation et aux dispositifs de conformité de votre environnement cloud. Cette option est nécessaire dans de nombreux contextes d’entreprise.

Auto-hébergement — vLLM, TGI, SGLang ou LMDeploy sur vos propres GPU. Le coût par jeton est le plus faible à grande échelle, mais la complexité opérationnelle est la plus élevée. Cette option ne s’envisage généralement que lorsque les dépenses d’inférence atteignent plusieurs dizaines de milliers d’euros par mois (voir l’article qui compare l’auto-hébergement et l’hébergement pour les calculs de seuil).

En périphérie ou sur l’appareil — Apple Intelligence, MediaPipe, ONNX et modèles GGUF via Ollama ou llama.cpp. Le coût marginal par appel est nul, mais les capacités des modèles sont limitées. Cette option devient de plus en plus viable pour des cas d’usage ciblés.

Les compromis :

• La latence compte : les agents vocaux et les interfaces conversationnelles exigent une faible latence. Groq, Cerebras et l’exécution sur appareil excellent sur ce point.
• Débit compte pour les lots : si vous traitez des millions d’enregistrements, vous souhaitez un débit élevé, pas une latence faible.
• Conformité compte : le RGPD, le HIPAA, le SOC 2 dictent souvent les fournisseurs et les régions que vous pouvez utiliser.
• Le risque fournisseur compte : dépendre d’un seul fournisseur crée un point de défaillance unique. Une stratégie multifournisseur constitue une bonne pratique.

Une architecture courante en 2026 associe des modèles propriétaires hébergés pour les demandes exigeant une grande qualité, des modèles open source hébergés pour les tâches volumineuses et moins coûteuses, ainsi que des modèles sur appareil pour les fonctions sensibles à la latence. L’auto-hébergement n’intervient que lorsque l’échelle et les économies justifient la charge opérationnelle.

Couche 3 : Outils et MCP

Les LLM seuls ne peuvent pas faire beaucoup. Ils deviennent utiles lorsqu’ils peuvent appeler des outils — des fonctions que vous définissez qui leur donnent accès aux données, aux API et aux actions.

Appel de fonctions natif. Chaque grand modèle prend en charge une API structurée d’appel de fonctions. Vous définissez les fonctions au moyen de schémas JSON ; le modèle décide quand les appeler ; votre système exécute l’appel, puis renvoie les résultats.

MCP (Model Context Protocol). Protocole standardisé pour les serveurs d’outils, introduit par Anthropic et désormais largement adopté, notamment par OpenAI et Cursor. Un serveur MCP expose des outils ; un client MCP, tel qu’un agent LLM, s’y connecte et les utilise. Le protocole découple ainsi l’implémentation des outils de tout modèle particulier.

Intégrations directes. Pour les cas d’utilisation à volume élevé spécifiques (par exemple, CRM spécifique, base de données spécifique), il est souvent plus facile d’écrire un adaptateur direct qu’un serveur MCP générique.

La tendance de 2026 est claire : MCP s’impose comme norme. La plupart des nouveaux outils devraient cibler MCP. Les intégrations directes restent utiles pour les parcours sensibles aux performances.

Quelques réalités d’implémentation :

• Les descriptions des outils comptent énormément. Un outil mal décrit ne sera pas utilisé correctement. Les descriptions de documentation des outils devraient être rédigées comme des prompts.
• Le nombre d’outils compte. Les modèles disposant de plus de 50 outils sont moins performants que ceux auxquels seuls 5 à 10 outils pertinents sont proposés. Sélectionnez-les activement.
• La gestion des erreurs compte. Les erreurs d’outils doivent être communiquées au modèle de manière structurée afin qu’il puisse s’adapter.
• L’autorisation est complexe. Un système multi-utilisateur dans lequel le LLM dispose d’autorisations différentes selon les utilisateurs n’est pas trivial. Ne laissez pas le LLM prendre les décisions d’autorisation ; appliquez-les dans l’adaptateur de l’outil.

Couche 4 : Récupération et mémoire

Les LLM ont besoin de données sur lesquelles ils n’ont pas été entraînés. C’est la couche de récupération.

Bases de données vectorielles. Pinecone, Weaviate, Qdrant, Chroma, PostgreSQL avec pgvector et Turbopuffer. Elles stockent des plongements et exécutent des requêtes de recherche des plus proches voisins. Ces technologies mûres et bien maîtrisées constituent la norme pour la recherche sémantique.

Recherche hybride. Elle associe la recherche vectorielle à la recherche traditionnelle par mots-clés avec BM25 et couvre ainsi les correspondances sémantiques comme lexicales. Utilisez la fusion réciproque des rangs pour combiner les résultats. Outils : Elasticsearch, OpenSearch et Vespa.

Graphes de connaissances. Neo4j, Memgraph et magasins de triplets personnalisés. Ils conviennent aux données riches en relations et aux architectures GraphRAG. Leur construction demande davantage de travail, mais produit souvent de meilleurs résultats dans les domaines fortement relationnels.

Plateformes RAG spécialisées. LlamaIndex (maintenant mûr), abstractions RAG de LangChain, Haystack. Cadres de niveau supérieur pour les schémas courants.

Reclassement. Cohere Rerank, Voyage et encodeurs croisés personnalisés. Après la recherche initiale, reclassez les meilleurs candidats avec un modèle plus coûteux afin d’améliorer la précision. Cette étape multiplie généralement la qualité de la recherche par deux ou trois.

Mémoire. Pour les agents et les conversations, des couches de mémoire structurée — Mem0, Letta (anciennement MemGPT), ou personnalisées. Distinguez la mémoire à court terme (conversation actuelle), la mémoire à moyen terme (sujets récents), la mémoire à long terme (faits durables sur l’utilisateur/compte).

La question architecturale : où se situe cette couche ?

• En application : l’appel LLM est enveloppé dans une logique de récupération écrite par votre équipe.
• À la couche MCP : la récupération exposée comme des outils.
• En tant que service : un service de récupération dédié que vos applications appellent.

Pour un système monolithique à produit unique, une intégration dans l’application est acceptable. Dans une organisation qui gère plusieurs produits, traiter la recherche comme un service doté de politiques et d’un niveau de qualité cohérents s’avère rentable.

Couche 5 : Ingénierie du prompt et du contexte

En 2026, « l’ingénierie des prompts » est principalement synonyme de « l’ingénierie du contexte » — gérer ce qui entre dans la fenêtre de contexte pour chaque appel.

Les composants :

Prompts. Souvent modélisés avec des variables. Stockés dans le contrôle de version. Testés avec des ensembles d’évaluation. Traités comme du code.

Gestion des prompts. Outils tels que Promptfoo, Langfuse et PromptLayer, ou systèmes internes. Gestion des versions, tests A/B et retour à une version antérieure. (Helicone et les passerelles LLM similaires relèvent de la couche d’observabilité ci-dessous ; ces deux catégories sont faciles à confondre.)

Stratégie de contexte. Décisions sur ce qu’inclure dans chaque appel :

• Prompt système (stable, définit le comportement).
• Connaissance récupérée (dynamique, depuis RAG).
• Historique de la conversation (géré et souvent synthétisé).
• Exemples few-shot (sélectionnés dynamiquement en fonction de la requête).
• Descriptions d’outils (filtrées aux outils pertinents uniquement).
• La requête actuelle de l’utilisateur.

Compression du contexte. Lorsque le contexte devient long, le modèle se dégrade. Stratégies : résumer les anciens tours, extraire les faits clés vers une mémoire structurée, supprimer le contenu non pertinent. Zone de recherche active.

Utilisation du contexte long. Les fenêtres d’un million de jetons sont courantes sur les modèles actuels (Claude, GPT-5.5 et Gemini). Elles fonctionnent, mais la « dégradation du contexte » est réelle : la qualité baisse sur les entrées longues, même lorsque le modèle les prend techniquement en charge. Utilisez ces fenêtres avec discernement ; n’y déversez pas toutes vos données simplement parce que vous le pouvez.

Couche 6 : Orchestration

Comment coordonnez-vous les flux de travail LLM à plusieurs étapes et les agents ?

API directe. Écrivez simplement la boucle vous-même en Python ou TypeScript. Meilleure pour les cas simples et pour comprendre ce qui se passe réellement.

LangChain / LangGraph. Très utilisés. LangGraph (machine d’états pour les agents) a mûri considérablement. Abstractions lourdes, courbe d’apprentissage, mais puissantes.

CrewAI. Cadre multi-agents axé sur les agents basés sur des rôles. Plus facile à démarrer que LangGraph ; moins flexible.

Agents LlamaIndex. Particulièrement forts pour les flux de travail RAG-intensifs.

SDK des agents OpenAI. Plus simple, plus opiniâtre, optimisé pour les modèles OpenAI.

SDK Anthropic Claude. Similaire ; optimisé pour Claude.

Personnalisé. Pour les équipes matures déployant des agents en production, l’orchestration personnalisée est courante — les cadres imposent des coûts (taxe d’abstraction, complexité de débogage, changements de version) qui dépassent les bénéfices.

Un modèle de 2026 : prototyper dans un cadre ; réécrire en code personnalisé pour la production. Les cadres vous aident à découvrir les modèles ; une fois que vous les connaissez, le code direct est plus simple et plus fiable.

Couche 7 : Observabilité

Vous ne pouvez pas déployer des applications LLM sérieuses sans observabilité. Tout système en production a besoin de :

Traçage. Chaque appel LLM capturé : horodatage, modèle, entrée, sortie, latence, coût, succès/échec. Arbres pour les traces à plusieurs étapes.

Suivi des coûts. Par appel, par fonctionnalité, par utilisateur. Les coûts sont importants et non limités ; sans suivi, vous découvrez à la fin du mois.

Surveillance de la qualité. Vérifications de qualité automatisées sur un échantillon du trafic en production. Alertes en cas de baisse de qualité.

Capture des retours utilisateurs. Pouces vers le haut/bas, retours explicites, signaux implicites (taux de réessai, abandon).

Débogage. Lorsqu’une chose se brise, vous devez voir la chaîne complète d’appel. Un échec d’exécution d’agent a de nombreux points de défaillance possibles.

Outils : LangSmith, Helicone, Arize, Phoenix, Braintrust, Weights & Biases, Datadog LLM Observability. Chacun a des forces différentes ; choisissez un tôt et restez-y.

Pour les petites équipes : même une simple table Postgres avec une ligne par appel LLM vous donne 80 % de ce dont vous avez besoin. Passez à un outil lorsque l’échelle ou les besoins de fonctionnalité justifient cela.

Couche 8 : Évaluations

La couche la plus importante pour le travail en production sérieux.

Évaluations hors ligne. Un ensemble de données défini ; sorties attendues ; notation. Exécutées avant le déploiement des changements. Captent les régressions. (Nous avons abordé cela en détail au niveau intermédiaire.)

Évaluations en ligne. Un échantillon du trafic de production est noté automatiquement, par un LLM utilisé comme juge ou à partir de signaux des utilisateurs. Ces évaluations détectent les dérives.

Évaluations pré-déploiement. Avant que tout changement de prompt ou de modèle ne soit mis en production, l’ensemble d’évaluation s’exécute et est examiné. Devient partie du CI.

Taxonomie des évaluations. Différentes évaluations pour différentes préoccupations :

• Comportemental : fait-il ce que nous attendons ?
• Sécurité : refuse-t-il ce que nous souhaitons refuser ?
• Qualité : à quel point la sortie est-elle bonne ?
• Robustesse : comment gère-t-il les entrées adversaires ?
• Coût/latence : sommes-nous dans le budget ?

Outils : Promptfoo, Braintrust, LangSmith, ensembles personnalisés. Tous ont leur place ; Promptfoo est le point de départ le plus facile.

Couche 9 : La couche application

C’est là que vit votre produit spécifique. Les décisions ici :

Agent ou flux de travail. Les agents — un LLM exécuté en boucle avec des outils — sont puissants, mais plus difficiles à fiabiliser. Les flux de travail, qui suivent une séquence fixe d’appels LLM, sont plus simples et souvent suffisants. Privilégiez-les ; n’utilisez les agents qu’en cas de réel besoin.

Synchrone ou asynchrone. Interaction en temps réel avec l’utilisateur, tâche en arrière-plan ou diffusion en continu ? Ce choix influe sur le modèle, l’infrastructure et la conception de l’expérience utilisateur.

Locataire unique ou architecture mutualisée. Les exigences d’isolation des données propres à chaque client influencent de nombreuses décisions architecturales.

Sur site vs cloud. La conformité, la sécurité ou le coût peuvent vous pousser sur site. La complexité opérationnelle est bien plus élevée.

Cas limites. Hallucinations, injections de prompt, abus. Les systèmes en production ont besoin de garde-fous. Ne déployez pas sans eux.

Compromis qui comptent

Quelques compromis dignes d’être explicitement mentionnés :

Qualité vs coût vs latence

Le triangle fondamental. Vous pouvez généralement optimiser deux ; le troisième se détériore.

• Haute qualité + faible latence = coûteux.
• Faible coût + faible latence = qualité inférieure.
• Haute qualité + faible coût = haute latence (traitement en lots, ou modèles de raisonnement).

Choisissez vos priorités par tâche. Ne maximisez pas les trois ; cette voie mène à la médiocrité dans tous les cas.

Construire vs acheter

Pour chaque couche, vous pouvez construire ou acheter.

• Construire : plus de contrôle, plus d’entretien, plus de coût (temps d’ingénieur), capacités différenciantes.
• Acheter : départ plus rapide, moins de contrôle, risque continu de fournisseur, capacités non différenciantes externalisées.

Une bonne heuristique : achetez les couches de commodité (stockage vectoriel, observabilité de base), construisez les couches différenciantes (votre orchestration spécifique, vos prompts, vos évaluations). Inverser cela — acheter votre différenciation et construire votre infrastructure de commodité — est une erreur courante.

Open source vs fermé

Une réalité de 2026 : les modèles open source sont compétitifs pour de nombreuses tâches et, pour certaines, meilleurs, plus rapides ou moins chers. Pour d’autres, comme le raisonnement à long terme, les modèles propriétaires de pointe conservent l’avantage.

Les facteurs de décision :

• Exigences de qualité. Pour atteindre les meilleures performances possibles, les modèles propriétaires restent souvent en tête.
• Coût à grande échelle. L’auto-hébergement de modèles open source devient économique à très grande échelle.
• Confidentialité/conformité. L’auto-hébergé sur votre infrastructure est souvent requis pour les données sensibles.
• Personnalisation. L’ajustement fin et l’entraînement personnalisé exigent généralement des modèles open source.
• Capacité opérationnelle. Les API propriétaires sont simples à exploiter ; l’auto-hébergement demande un effort considérable.

La plupart des systèmes en production en 2026 sont hybrides — fermés pour certains appels, ouverts pour d’autres, selon le calcul par appel.

Latence vs profondeur de raisonnement

Les niveaux de raisonnement (GPT-5.5 thinking, Claude avec raisonnement adaptatif) échangent la latence contre la qualité sur les problèmes difficiles. Parfois cela en vaut la peine ; parfois l’utilisateur ne peut pas attendre 30 secondes.

Un modèle : routez les requêtes simples vers des modèles rapides, les requêtes difficiles vers des modèles de raisonnement. Utilisez un routeur (petit modèle ou heuristique) pour décider.

Contexte long vs RAG

Vous pouvez placer toutes les données dans le contexte du modèle, au moyen d’une fenêtre d’un million de jetons, ou rechercher uniquement les passages pertinents avec un système RAG.

• Contexte long : plus simple, pas d’infrastructure de récupération, mais coûteux par appel et la « dégradation du contexte » est réelle.
• RAG : moins coûteux par appel, plus de configuration, la qualité de la récupération est un problème d’ingénierie à part entière.

La réponse pragmatique en 2026 consiste généralement à utiliser le RAG en production, et le contexte long pour le prototypage, les tâches ponctuelles particulières ou les cas où une recherche de mauvaise qualité compromettrait le résultat.

Agents ou flux de travail

Comme indiqué plus haut, privilégiez les flux de travail et n’utilisez des agents que si leur flexibilité est réellement nécessaire. De nombreux systèmes présentés comme « agentiques » devraient être de simples flux de travail.

Une architecture de référence de 2026

Pour rendre tout cela concret, voici à quoi ressemble un système de production typique pour un produit SaaS de taille moyenne avec des fonctionnalités d’IA :

User → Application (React/Next.js)
    ↓
API gateway / auth
    ↓
LLM Service (your wrapper)
    ↓
  Router (small model or heuristic)
    ├→ Simple tasks: a mid-tier model (Claude Haiku 4.5 class)
    ├→ Standard tasks: Claude Sonnet 5 or GPT-5.5
    ├→ Hard tasks: Claude Opus 4.8 or a reasoning tier
    └→ Special: vision/voice/embedding specialists
    ↓
Tool layer (MCP servers + direct integrations)
    ↓
Retrieval layer (Pinecone + hybrid + reranker)
    ↓
Observability (Helicone or LangSmith)
    ↓
Eval suite (Promptfoo, runs in CI)

Coût par utilisateur actif/mois : généralement 1 à 10 euros selon l’intensité d’utilisation. Effort d’ingénierie pour construire : 6 à 12 semaines pour une équipe expérimentée. Coût opérationnel : faible à modéré selon le trafic.

Ce qui se passe souvent de mal

Schémas de défaillance récurrents dans les piles LLM en production :

Schéma 1 : Un seul modèle pour tout. Dépassements de coûts, problèmes de qualité. Solution : routage.

Schéma 2 : Aucune observabilité. Impossible de déboguer, mesurer, améliorer. Solution : instrumentez tôt.

Schéma 3 : Aucune évaluation. La qualité dérive sans être remarquée. Solution : des évaluations dès le départ.

Schéma 4 : Verrouillage dans un cadre. Le débogage de LangChain ou de CrewAI devient un travail à temps plein. Solution : n’utilisez pas de cadres sauf s’ils sauvent plus qu’ils ne coûtent. Réécrivez en code direct lorsque les modèles sont clairs.

Schéma 5 : Construire une infrastructure qui devrait être achetée. Base de données vectorielle personnalisée ? Probablement du temps perdu. Observabilité personnalisée ? Probablement du temps perdu. Achetez les couches de commodité.

Schéma 6 : Acheter ce qui devrait être construit. Externaliser vos prompts ou vos évaluations auprès d’un tiers revient à céder des éléments qui constituent votre avantage concurrentiel. Gardez-en la maîtrise.

Schéma 7 : Ignorer l’injection de prompt. Système en production sans nettoyage d’entrée pour le contenu fourni par l’utilisateur. Grand risque ; atténuez tôt.

Schéma 8 : Faire confiance aux agents dans les flux à risque élevé. Un agent LangGraph qui autorise des remboursements sans revue humaine. Cela finira par se produire. Ajoutez une intervention humaine pour les actions importantes.

Schéma 9 : Optimiser pour la mauvaise chose. Optimiser le coût d’inférence alors que le coût total est dominé par le temps d’ingénierie. Ou optimiser la latence alors que les utilisateurs ne le remarquent pas. Mesurez ce qui compte vraiment.

Schéma 10 : Aucune stratégie multifournisseur. Lorsque votre fournisseur principal subira une panne — et non pas s’il en subit une — votre service sera indisponible. Configurez une solution de secours.

Trois paris, datés (revenez en milieu 2027)

Les prédictions sont bon marché ; les prédictions datées et falsifiables ne le sont pas. Trois sur lesquels nous sommes prêts à être erronés publiquement :

1. L’inférence hébergée en Europe atteint une parité pratique de prix pour les modèles intermédiaires d’ici milieu 2027. La capacité européenne souveraine arrive rapidement, et la prime par rapport aux endpoints des États-Unis diminue. Si la parité se réalise, notre recommandation par défaut pour les charges de travail sensibles au RGPD passe de « hybride avec suppression » à « hébergée en Europe par défaut ». Confiance : modérée.

2. La couche des cadres continue de se concentrer, tandis que celle des protocoles progresse. Au cours des 18 derniers mois, Microsoft a fusionné ses deux cadres d’agents et OpenAI a intégré son agent web autonome à ChatGPT, tandis que MCP est passé du stade de l’annonce à celui de norme multifournisseur. Nous concentrons donc les efforts d’intégration sur les protocoles (MCP, sorties structurées) et veillons à ce que le cadre d’orchestration reste remplaçable. Confiance : élevée.

3. Le routage vers de petits modèles cesse d’être une optimisation et devient l’architecture par défaut. Si les prix des modèles de pointe restent stables tandis que les petites gammes continuent de progresser, « un modèle de pointe pour tout » paraîtra aussi incongru à un ingénieur cloud que « du bare metal pour tout ». Confiance : élevée pour les PME attentives aux coûts.

Ce que nous ne prédisons pas délibérément : les classements des modèles. Tout classement spécifique imprimé ici serait obsolète avant la prochaine date de révision de cette page.

Obtenez l’architecture correcte

La pile LLM de 2026 est réelle, en couches, et les choix comptent. Les équipes qui gagnent sont celles qui :

• Comprennent toute la pile, pas seulement les parties qu’elles touchent.
• Font des compromis explicites entre qualité, coût et latence pour chaque appel.
• Construisent les parties qui différencient ; achètent les parties qui ne le font pas.
• Instrumentent dès le départ (observabilité, évaluations).
• Restent agiles, avec des modèles remplaçables et une stratégie multifournisseur.

Les équipes qui perdent sont celles qui ont choisi un seul fournisseur, codé son API de manière fixe, n’ont jamais instrumenté, jamais mesuré, et se retrouvent maintenant avec un système coûteux, fragile et impossible à améliorer.

Obtenez l’architecture correcte. Tout le reste devient plus simple.