← Retour aux articles
Défis

Au-delà du scaling : les nouveaux espaces d'optimisation pour le progrès IA

Par Marc Molas·26 mai 2026·9 min de lecture

Dans la Partie 1, on a couvert pourquoi le scaling n'est plus un axe de progrès fiable. Dans la Partie 2, on a parcouru les quatre leviers qui pilotent le vrai taux de rendement d'une unité de compute. La clôture naturelle de la série — et la partie de l'essai de Sara Hooker que j'ai trouvée la plus stimulante — est la question : où le champ devrait-il aller ensuite ?

La réponse de Hooker, c'est que nous entrons dans une ère d'espaces d'optimisation élargis. Les informaticiens avaient l'habitude d'avoir un grand levier (entraîner un modèle plus gros avec plus de données) et c'était à la fois libérateur et enfermant. Le nouveau paysage nous donne un éventail bien plus large de choses à optimiser, et beaucoup sont dramatiquement sous-explorées. Passons-les en revue, puis traitons deux clarifications importantes qu'elle apporte à la fin.

1. Exploration sans gradient : le compute à l'inférence comme levier de premier rang

Pendant les 30 dernières années, la façon de rendre un modèle meilleur a été de mettre à jour ses paramètres. Plus d'entraînement, plus de données, plus de poids. La rupture en cours, c'est que beaucoup de compute se dépense désormais à l'inférence, pas à l'entraînement — et, point crucial, une grande partie est sans gradient, c'est-à-dire que le modèle lui-même ne change pas.

Hooker regroupe cette famille de techniques dans les nouveaux espaces d'optimisation « compute léger » et « sans gradient » (sa Figure 5 les distingue explicitement) :

  • Best-of-N sampling. Échantillonner plusieurs complétions, les scorer, retourner la meilleure.
  • Search et planning sur les générations. Recherche en arbre, variantes de beam search, boucles agentiques qui explorent des alternatives.
  • Tool use. Un modèle qui peut appeler une calculette, une base de données, un interpréteur de code ou un autre modèle emprunte effectivement de la capacité qu'il n'a pas à mémoriser.
  • Retrieval-augmented generation. Déjà mentionné dans la Partie 2 — ça vit dans cette catégorie.
  • Essaims agentiques. Plusieurs instances de modèle qui se coordonnent pour résoudre un problème qu'une seule ne pourrait pas résoudre.
  • Model merging. Combiner les paramètres de plusieurs modèles fine-tunés sans entraînement supplémentaire.
  • Compute adaptatif. Dépenser plus de compute d'inférence sur les problèmes durs, moins sur les faciles.

L'estimation de Davidson et al. (2023) est le chiffre phare : les techniques à l'inférence peuvent livrer 5×–20× d'amélioration sur la performance de base post-entraînement, avec une empreinte minimale par rapport au coût du pré-entraînement. C'est un ratio de levier énorme, et il est capturé aujourd'hui par les équipes qui ont choisi d'investir cette couche plutôt que d'attendre la prochaine classe de taille de modèle.

L'implication stratégique est subtile mais importante. Les techniques à l'inférence, c'est de l'ingénierie, pas de l'entraînement. Elles récompensent les équipes qui savent livrer, instrumenter, évaluer et itérer vite. Le goulet d'étranglement se déplace de « as-tu assez de GPU pour entraîner » vers « as-tu assez de vélocité d'ingénierie pour composer, évaluer et livrer ». C'est une vraie bonne nouvelle pour les organisations qui ne sont pas assises sur une ligne de capex de la taille d'un hyperscaler — soit, encore, la plupart d'entre nous.

2. L'espace de données malléable

Le second nouvel espace d'optimisation de Hooker est ce qu'elle appelle l'espace de données malléable, et c'est peut-être le glissement le plus intéressant philosophiquement de tout l'essai.

Pendant la majeure partie de l'histoire de l'IA, les jeux de données étaient des artefacts figés — MNIST, ImageNet, SQuAD, C4. Vous en choisissiez un, vous entraîniez dessus, vous reportiez des chiffres. Le jeu de données était un snapshot du monde que vous aviez pu rassembler. L'hypothèse fondamentale du machine learning était IID — des échantillons tirés indépendamment et identiquement d'une distribution fixe. On acceptait ce que le monde nous donnait.

Qu'est-ce qui change quand la génération de données synthétiques devient assez bon marché pour traiter la donnée elle-même comme quelque chose qu'on optimise ?

  • Vous pouvez orienter la distribution vers ce que vous voulez réellement — capacités, langues, cas limites, équilibre démographique — plutôt que d'accepter ce que le corpus contient.
  • Vous pouvez cibler la longue traîne directement. Si votre modèle est faible sur une catégorie spécifique, vous pouvez générer ou synthétiser des exemples pour elle au lieu d'espérer que le prochain scrape en contienne davantage.
  • Vous pouvez réduire l'écart entre distribution à l'entraînement et à l'inférence. Historiquement, il y a eu un mismatch chronique : la donnée d'entraînement était déterminée par ce que vous pouviez collecter ; les inputs à l'inférence sont déterminés par ce que les utilisateurs font réellement. La donnée synthétique peut combler ce gap délibérément.
  • Vous pouvez rendre visibles les populations invisibles. La lignée de travaux Aya (Aryabumi et al. 2024 ; Üstün et al. 2024 ; Dang et al. 2024b) consiste largement à utiliser la donnée synthétique et la traduction pour offrir une couverture multilingue que le web ouvert ne fournit pas.

C'est une rupture nette avec les « échantillons IID tirés de la nature ». Nous sommes désormais capables d'incliner intentionnellement la distribution vers ce que nous espérons représenter, au lieu d'accepter un échantillon aléatoire de ce qui est. C'est à la fois une énorme capacité et une énorme responsabilité — la donnée synthétique mal faite cumule le biais plutôt que de le corriger.

Pour les équipes produit, la leçon pratique, c'est que vous devriez traiter votre donnée d'entraînement/fine-tuning comme une chose que vous concevez, pas une chose que vous récoltez. Si votre modèle est faible sur une tranche qui compte, vous avez un levier qui n'existait pas il y a cinq ans.

3. Design et interface

Le troisième espace d'optimisation que Hooker met en avant est celui pour lequel la plupart des informaticiens sont les moins armés : comment le système interagit avec le monde.

Le système le plus intelligent sera de plus en plus défini par la construction d'un algorithme capable d'interagir avec le monde. Cela signifie que, pour la première fois, les chercheurs qui se soucient d'intelligence doivent aussi être obsédés par la façon dont un modèle interagit. Ce qui était auparavant le terrain étroit des UX designers, des artistes et des spécialistes de l'interaction homme-machine devrait désormais intéresser au plus haut point tous les informaticiens.

Ça frappe fort parce que ça inverse une hypothèse culturelle de longue date. Le progrès IA a historiquement été gating par l'algorithme, et l'interface était traitée comme un wrapper. Hooker dit que l'interface devient partie de l'algorithme — et que les systèmes les plus capables seront des systèmes multi-composants dont l'intelligence émerge de la composition des composants et de la façon dont ils touchent le monde, pas d'un seul modèle qui grossit.

Ça s'imbrique avec la vague des systèmes agentiques mais la recadre. Les systèmes agentiques intéressants ne sont pas « plus gros modèle + outils ». Ce sont des surfaces d'interaction soigneusement conçues : où le modèle obtient de l'information, où il peut agir, ce qui est montré à l'humain, ce que l'humain approuve, comment le feedback remonte. C'est de l'HCI, du design produit, de l'ingénierie système — et c'est exactement le type de travail historiquement sous-valorisé dans les labs IA.

Pour quiconque livre des fonctionnalités IA en produit, c'est une bonne nouvelle. La discipline que vous avez déjà en UX, en revue trust-and-safety, en design de workflow, en architecture human-in-the-loop — c'est désormais du travail IA de premier rang. Ce n'est plus un wrapper autour de la « vraie » capacité.

Ce que ça ne signifie pas : la clarification environnementale

Hooker prend soin de couper court à une mauvaise lecture spécifique de l'essai, et je veux la répéter parce qu'elle est importante. La mort lente du scaling du compute d'entraînement ne signifie pas que l'empreinte environnementale de l'IA rétrécit. L'inverse :

La majorité des besoins énergétiques des charges IA n'est pas dans l'entraînement, mais dans le coût de productionnaliser une charge ML et de la servir à des milliards d'utilisateurs. Même si la taille des modèles tend à diminuer, l'adoption massive de l'IA fait que les besoins énergétiques globaux continueront probablement de monter.

Autrement dit : des modèles plus petits et plus performants sont déployés dans vastement plus d'endroits, donc l'empreinte agrégée en énergie et en eau de l'IA continue de croître même si le coût d'entraînement par modèle plafonne potentiellement. Les lignées de travaux de Strubell et al. (2019a), Patterson et al. (2021), Luccioni et al. (2025) et Wu et al. (2022) restent porteuses. Si quelque chose, le futur inference-heavy que décrit Hooker rend l'efficacité de service, l'utilisation matérielle et le déploiement carbon-aware plus importants, pas moins.

J'ai déjà écrit sur les régions opérationnelles souveraines faisables sur cette tension précise — que l'histoire des coûts de l'IA est de plus en plus déterminée par l'infrastructure de service, pas par l'entraînement. Le cadrage de Hooker le renforce.

Reviendra-t-on un jour au scaling ?

La réponse de Hooker ici est mesurée et mérite d'être citée :

Tant qu'on est coincés avec les transformers comme architecture, ça n'a pas de sens de continuer à scaler le compute. Notre architecture actuelle montre tous les signes d'un plateau dans les rendements du compute supplémentaire. Si le progrès a tourné autour des réseaux de neurones profonds la dernière décennie, beaucoup de signaux suggèrent que la prochaine avancée significative demandera une architecture entièrement différente.

L'implication, c'est que le scaling reviendra quand arrivera une nouvelle architecture qui casse la courbe de rendement actuelle et en ouvre une nouvelle — exactement comme les transformers l'ont fait en 2017. Mais scaler l'architecture actuelle est, de plus en plus, du capex qui poursuit des rendements décroissants. Les labs frontière qui mèneront la prochaine vague ne seront pas ceux qui auront scalé le plus fort. Ce seront ceux qui auront parié sur un changement de paradigme.

Ce que je retiens de toute la série

Trois fils tirés de l'essai de Hooker qui comptent le plus, à mon sens, pour quiconque livre de l'IA en 2026 :

  1. Le travail intéressant est revenu entre les mains des ingénieurs. Pendant une décennie, le progrès IA a été une histoire de qui pouvait s'offrir le plus de compute. Le glissement vers la technique algorithmique, le design de données, le compute à l'inférence et l'interface signifie que la différenciation intéressante repose à nouveau sur le jugement d'ingénierie — choix d'architecture de retrieval, curation des données d'entraînement, design de boucles d'agents, structure du human-in-the-loop. C'est un territoire récupérable pour les équipes qui n'ont pas un budget d'entraînement de 100 M$.

  2. Les hypothèses dominantes de politique publique et de capex vieillissent vite. Les seuils de compute dans la législation, les cadres de « responsible scaling », les roadmaps vendeur fondées sur « l'an prochain, plus grand » — ce sont tous des artefacts d'une hypothèse aujourd'hui empiriquement faible. Tout plan qui en dépend mérite un nouveau regard.

  3. La prochaine architecture est le prix. L'oubli catastrophique, l'inefficacité d'échantillonnage, l'incapacité à spécialiser des zones de connaissance — ce sont les problèmes durs que l'architecture actuelle ne sait pas résoudre. Qui les résout réinitialise le champ. C'est un pari bien plus intéressant que « plus de paramètres ».

Hooker clôt l'essai avec une citation de Turing qui colle au moment : « Nous ne voyons qu'à courte distance devant nous, mais il y a beaucoup à y faire. » Ce qui résonne, c'est que, pendant une longue période, l'informatique a eu le sentiment de ne pas avoir grand-chose à faire — elle avait une seule chose à faire, très chèrement. Nous sommes enfin de l'autre côté. La vue d'ici est plus incertaine, mais le travail est redevenu plus intéressant.


C'est le dernier billet de la série. La Partie 1 couvrait pourquoi plus grand n'est plus toujours mieux. La Partie 2 parcourait ce qui détermine vraiment le taux de rendement du compute.

Référence : Sara Hooker, On the slow death of scaling, 2025.

Prêt à construire votre équipe d'ingénierie ?

Parlez à un partenaire technique et déployez des développeurs validés par des CTOs en 72 heures.