TL;DR. Trois publications open-weight dans la semaine du 18 mai 2026 — la famille Ettin Reranker, Granite Embedding Multilingual R2 et l'Open Agent Leaderboard d'IBM Research — dessinent une carte précise : les couches embedding et reranking appartiennent désormais à l'open-weight sous 311M paramètres, tandis que l'orchestration d'agents accuse encore un retard de 18 à 29 points de pourcentage face aux modèles frontier fermés, selon le leaderboard.
Ce qui vient de changer dans l'assemblage des stacks RAG
Du 14 au 19 mai 2026, trois publications indépendantes ont remis en cause la logique d'assemblage des pipelines de récupération d'information en entreprise. IBM lance Granite Embedding Multilingual R2 avec un contexte de 32 768 tokens — contre 512 pour la génération R1. Tom Aarsen publie la famille Ettin, six rerankers sous licence Apache 2.0 de 17,6M à 1,04B de paramètres, distillés depuis un modèle à 1,54B. IBM Research inaugure simultanément l'Open Agent Leaderboard, qui évalue des systèmes agents complets — paire modèle + architecture d'agent — sur six benchmarks sans optimisation spécifique par benchmark, selon l'annonce d'IBM Research.
Ces trois publications, prises ensemble, imposent une réévaluation couche par couche. Ce n'est plus une question de modèle généraliste : c'est une question d'architecture stratifiée.
Où l'open-weight s'impose : embeddings et reranking
Granite Embedding R2 : le contexte long comme différenciateur
Le modèle 97M-r2 atteint 60,3 sur la tâche de récupération multilingue MTEB (18 langues), contre 52,7 pour multilingual-e5-base à 278M de paramètres — soit +7,6 points à trois fois moins de paramètres, selon les données publiées par IBM. Sur LongEmbed, le 311M-r2 prend la première place avec un score de 71,7, contre 64,9 pour harrier-oss-v1-270m et 37,7 pour Granite 278M-R1 — un écart intergénérationnel de +34 points sur la même famille. Le débit sur H100 atteint environ 1 800 documents par seconde pour le 311M-r2, soit 5,5 fois plus rapide que jina-embeddings-v5-text-nano, selon les mesures publiées par IBM.
La rupture tient à une seule variable : 512 tokens de contexte pour R1, 32 768 pour R2. Les contrats, rapports réglementaires et dossiers multi-pages qui dépassaient le seuil des générations précédentes entrent désormais dans le contexte en un seul passage, sans découpage artificiel.
Ettin Reranker : l'efficacité comme argument principal
La famille Ettin renverse les équilibres habituels entre taille et performance. Sur MTEB NDCG@10, ettin-32m (32,8M paramètres) score 0,5779 contre 0,5526 pour bge-reranker-v2-m3 à 568M de paramètres — +0,025 à 17 fois moins de poids, selon les résultats publiés. Le modèle ettin-1b (1B paramètres) atteint 0,6114, quasi identique à son modèle enseignant mxbai-rerank-large-v2 (1,54B, score 0,6115), tout en étant 54 % plus léger et 2,40 fois plus rapide sur H100. L'architecture ModernBERT avec attention non-paddée génère un gain de débit de 8,26 fois pour le modèle 1B par rapport à la baseline fp32+SDPA, selon les mesures publiées — un chiffre qui change les calculs d'infrastructure à volume élevé.
Où les modèles fermés tiennent encore : l'orchestration agent
L'Open Agent Leaderboard d'IBM Research, publié le 18 mai 2026, introduit une mesure structurante : les modèles open-weight testés — DeepSeek V3.2 et Kimi K2.5, ajoutés après le lancement — accusent un retard de 18 à 29 points de pourcentage en moyenne sur les six benchmarks, selon le leaderboard. Ce retard ne porte pas sur une tâche isolée : il mesure le système complet (modèle + orchestration + outils) sans optimisation spécifique, sur des tâches à haute complexité — SWE-Bench Verified, BrowseComp+, AppWorld et les environnements tau2-Bench Airline, Retail et Telecom.
La nuance opérationnelle est importante : selon IBM Research, le même modèle associé à des architectures d'agent différentes produit des résultats et des coûts distincts. L'architecture compte — mais elle ne compense pas encore l'écart de capacité entre open-weight et frontier sur les tâches complexes. À noter également : dans plusieurs cas, les agents généralistes testés sans optimisation benchmark ont égalé ou dépassé des systèmes construits spécifiquement pour ces tâches, selon la même source.
Implications tarifaires et opérationnelles
Les trois familles de modèles sont publiées sous licence Apache 2.0. Pour les équipes techniques, cela ouvre le déploiement on-premise ou sur cloud privé sans redevance par requête sur les couches embedding et reranking. La couche agent, si elle repose sur des modèles frontier fermés, conserve un coût à l'usage proportionnel au volume.
L'Open Agent Leaderboard introduit une variable rarement quantifiée dans les comparatifs : le coût des échecs. Les exécutions échouées coûtent 20 à 54 % de plus que les exécutions réussies, selon les données publiées par IBM Research. Une stack agent qui échoue régulièrement sur des tâches complexes n'est pas seulement moins performante — elle est structurellement plus chère à opérer. La sélection d'outils (tool shortlisting) a amélioré les performances sur chaque modèle testé et converti des configurations défaillantes en configurations viables, selon la même source.
Ce que cela implique pour une architecture multi-modèle
La carte de mai 2026 dessine une architecture à trois vitesses distinctes :
- Couche embedding : open-weight (Granite 97M-r2 ou 311M-r2) pour les corpus multilingues, les documents longs et les bases de code — déploiement on-premise viable sous Apache 2.0, avec un gain de contexte de 64 fois par rapport à la génération précédente.
- Couche reranking : open-weight (Ettin 32M à 400M selon la contrainte de latence) pour les pipelines à volume élevé — le rapport qualité/paramètres dépasse aujourd'hui les alternatives classiques de la génération précédente sur MTEB.
- Couche orchestration d'agents : modèles fermés (frontier) pour les tâches à haute complexité — tant que l'écart de 18 à 29 points reste documenté sur les benchmarks de référence.
Cette segmentation n'est pas théorique. L'Open Agent Leaderboard démontre que le choix du modèle reste le facteur dominant, mais que l'architecture d'agent produit une différence mesurable. Investir dans la couche orchestration — sélection d'outils, routing, gestion des échecs — est rentable indépendamment du modèle retenu.
Trois leviers à activer cette semaine
- Évaluer le contexte réel de vos corpus : si vos documents dépassent 4 096 tokens (contrats, rapports, dossiers réglementaires), la migration vers Granite R2 (32 768 tokens de contexte) élimine le découpage artificiel et améliore mécaniquement la précision de récupération sur les passages longs.
- Auditer la couche reranking de vos pipelines existants : comparer le score NDCG@10 actuel de votre reranker avec les données Ettin publiées sur MTEB. Ettin-150m (0,5994) dépasse Qwen3-Reranker-0.6B (0,5940) à quatre fois moins de paramètres — si votre pipeline utilise un modèle de la génération précédente, le gain est immédiat sans changement d'architecture.
- Quantifier le coût des échecs de vos agents : avant tout arbitrage open-weight versus fermé sur la couche orchestration, mesurer le taux d'échec et le surcoût associé sur vos tâches actuelles. Le chiffre de 20 à 54 % de surcoût par exécution échouée, documenté par IBM Research, est un plancher de comparaison exploitable dès cette semaine.
Quelle couche de votre pipeline RAG présente le plus grand écart entre la performance mesurée et le coût réel supporté — les embeddings, le reranking, ou l'orchestration agent ?
Si ce décryptage vous parle, je publie une analyse de ce calibre chaque jour sur l'innovation digitale et l'IA en entreprise. 👉 Recevez la prochaine directement dans votre boîte mail — l'inscription prend dix secondes, et chaque édition est lue avant 9h par des dirigeants de PME, d'ETI et d'institutions belges.