L’avenir de la recherche en IA : de la recette au kit repas

Résumé essentiel (TL;DR)

• Explosion des articles en IA = progrès + en même temps “Noise Tax”

  • 2013 → 2023, articles annuels en IA : ~102,000 → ~242,000
  • Sur la même période, part de l’IA dans les articles en informatique : 21.6% → 41.8%

• Plus les articles se multiplient, plus les coûts de sélection / reproduction / exploitation explosent

  • On lit davantage, mais les produits sont moins stables
  • Plus on poursuit le SOTA, plus la reproductibilité et l’opérabilité baissent

• Quand on met un article en production, 4 modes d’échec apparaissent presque toujours

• Voilà pourquoi le signal pour 2026 est simple :
  DIY (implémenter la recette) ↓ / Packaging (kit repas) ↑

  • Mieux vaut une unité directement déployable que “lire l’article puis implémenter”
  • Des packagings comme NVIDIA NIM / SLM / Ollama créent un mouvement de standardisation

---

Définition du problème : les articles d’IA sont des « recettes Michelin »

L’auteur compare les articles de recherche en IA à des recettes de chefs étoilés Michelin.
Le problème n’est pas la recette en elle-même. C’est juste que notre cuisine n’est pas la même.

Les articles sont élaborés dans une cuisine parfaite.

• Cluster de H100
• Jeux de données propres et soigneusement nettoyés
• Astuces cachées optimisées pour l’environnement expérimental

Puis, quand cette recette descend sur le terrain (on-prem, legacy, conformité, exploitation), le même phénomène se répète.

---

De l’article à la production : 4 modes d’échec

1) Broken Utensils (infrastructure)

• Les résultats des articles sont obtenus avec des milliers de H100

• Dans la réalité, on a de petits GPU / une VRAM limitée / un réseau contraint

• Le problème n’est pas “les performances baissent un peu”
  → le phénomène lui-même n’apparaît pas

• Symptômes fréquents :

  • « Ça tourne, mais il n’y a pas le comportement attendu »
  • Le pipeline se termine, mais le promised behavior n’apparaît pas

2) Spoiled Ingredients (données)

• Les articles supposent des données nettoyées

• Les données réelles, ce sont :

  • des logs, des PDF scannés, des documents legacy, des changements de schéma, des sources floues

• En RAG / raisonnement, dès que la structure, les fondements ou la cohérence se brisent, on bascule vite dans l’hallucination

• Ce qui est encore plus dangereux :

  • c’est fluide, donc on y croit davantage
  • le plus coûteux, c’est quand « ça a l’air correct, mais c’est faux »

3) Missing Salt (détails d’ingénierie)

• La partie “Season to taste” est la plus importante

• Le vrai terrain de jeu, c’est :

  • l’initialisation / le scheduler / le tuning au millième près / les templates de prompt

• Tout cela ne tient pas dans 8 pages d’article

• En pratique, c’est là que tout se joue :

  • ce n’est pas la recette, mais l’assaisonnement secret (les conditions de reproductibilité) qui détermine le résultat

4) Responsibility Gap (responsabilité)

• En cas d’échec, la conclusion ressemble à ceci :

  • « Les maths sont justes. C’est votre environnement le problème. »

• La responsabilité de l’écart est repoussée vers l’aval
  → au final, c’est la personne qui a lu l’article et l’a recommandé qui prend le retour de flamme.

• Quand il y a un incident ou un audit, cela devient « le système que nous avons construit »

---

Deux limites structurelles : pourquoi on finit par renoncer au DIY

A) Paper Explosion = Noise Tax

Plus les articles se multiplient, plus le coût de sélection explose.

• On lit davantage, mais les produits sont moins stables
• Plus on poursuit le SOTA, plus l’opérabilité baisse
• Ce n’est pas une “abondance de connaissances”, c’est un “coût du choix”

B) Changement de direction du capital : des « articles » vers l’« exploitation »

L’argent se déplace des nouvelles recettes vers des packages exploitables en conditions réelles.
Les questions d’investissement ont changé.

• Est-ce une démo ou est-ce exploitable ?
• Est-ce que ça tient en coût / latence / observabilité / audit ?

Les risques d’exploitation se résument en général à ces 3 points :

• Risque de coût : le PoC fonctionne, mais ça casse en production
• Risque de confiance : si les fondements / sources se dégradent, une réponse plausible reste dangereuse
• Risque de responsabilité : en cas d’incident ou d’audit, cela devient notre responsabilité

---

Le signal le plus fort pour 2026 : le Packaging

AI Meal Kit = prêt à déployer + unité de déploiement avec une frontière claire de responsabilité en cas d’échec

Autrement dit, la conclusion pour 2026 est la suivante :

Packaging beats ingenuity.

4 signaux du marché

Signal n°1) NVIDIA NIMs

• La configuration du modèle, les dépendances et les optimisations sont figées dans un conteneur
• Il y a moins de place pour les conjectures sur la toolchain
• L’assaisonnement secret est déjà inclus.
• Message : “Tune less. Run more.”

Signal n°2) SLMs

• Les « recettes adaptées à la cuisine » se multiplient
• Les possibilités d’exploitation en local / à l’edge augmentent
• Direction : bounded / predictable / cheaper to operate

Signal n°3) AI in a Box

• Les serveurs ne se vendent plus comme des « composants », mais comme des « produits finis »
• Avec RAG / sécurité / configuration de base inclus
• Effet : on trace une frontière sur qui porte la responsabilité du gap

Signal n°4) Ollama / LM Studio

• La difficulté de configuration chute fortement
• Le nombre d’opérateurs augmente
• Et quand le nombre d’opérateurs augmente, le marché évolue toujours ainsi : la standardisation s’accélère

---

Point de vue opérationnel : les indicateurs à regarder tout de suite

• Compute Fit : les performances visées sont-elles reproductibles sur « nos GPU / notre VRAM » ?
• Data Fit : les données d’entrée conservent-elles la « structure / les fondements / les sources » ?
• Hidden Salt : les scripts / prompts / valeurs de tuning nécessaires à la reproduction sont-ils figés par version ?
• Owner : en cas d’échec, où se situe la surface de responsabilité ? (nous ? le fournisseur ? le package ?)
• Ops : observabilité (logs / métriques), rollback, plafond de coût, audit : tout cela est-il intégré dans la conception ?

---

Conclusion

En 2026, plus qu’un « modèle plus intelligent »,
ce sont les « unités de déploiement qui cassent moins » qui l’emporteront.

Les articles continueront de sortir, mais le marché achètera de l’intelligence emballée.
Les équipes aussi devront choisir.

• continuer à implémenter des recettes
• ou packager / exploiter au niveau d’un kit repas

One-liner

« Les articles vendent des idées, le marché achète de l’exploitation. »

[cgl00]

Mais, dans le business, il y avait vraiment déjà des cas où l’on lisait un article de recherche pour l’implémenter soi-même et l’utiliser directement… ?

[flamehaven01]

C’est vrai. Mais dans la plupart des cas, plutôt que de tout construire à partir de zéro en lisant un article de recherche, on part souvent d’une implémentation de référence open source. Ces derniers temps, dès qu’un article fait le buzz dans l’IA, des POC fleurissent immédiatement partout, mais une fois en production, à cause des données, de l’infrastructure et du tuning, on a souvent quelque chose qui « tourne, oui, mais sans le goût attendu ». Du coup, j’ai l’impression qu’en ce moment, on se tourne de plus en plus vers des stacks packagées comme vLLM ou Ollama.