L’IA locale n’a pas besoin de battre les modèles géants pour bouleverser leur économie
Les modèles 8B–30B deviennent assez capables pour déplacer une partie du code, de la synthèse et de l’automatisation hors du cloud. Le vrai enjeu n’est pas de battre le frontier, mais de savoir quelles requêtes méritent encore un datacenter.
Il y a quelque chose d’étrange dans l’industrie de l’intelligence artificielle en 2026.
Amazon prévoit environ 220 milliards de dollars de dépenses d’investissement en cash cette année, notamment pour développer son infrastructure cloud et IA, et affirme malgré cela ne pas disposer d’assez de capacité pour satisfaire toute la demande. Dans le même temps, son CEO Andy Jassy explique publiquement qu’il s’attend à voir les entreprises techniquement compétentes construire non pas leurs propres modèles frontier géants, mais des modèles plus petits exploitant leurs données propriétaires.
Et ces petits modèles commencent à devenir sérieusement difficiles à ignorer.
Alibaba a publié en août Qwen3.8-27B, un modèle multimodal à poids ouverts sous licence Apache 2.0, avec seulement 27 milliards de paramètres. OpenAI propose de son côté gpt-oss-20b, 20,9 milliards de paramètres au total mais seulement 3,6 milliards activés par token, dont le checkpoint occupe 12,8 Gio et qui peut fonctionner dans environ 16 Go de mémoire. Google avait déjà montré qu’une version quantifiée de Gemma 3 27B pouvait tenir sur une RTX 3090 grand public.
Cela ne signifie pas qu’un PC vient de rattraper les meilleurs systèmes d’OpenAI, Anthropic ou Google.
Cela suggère quelque chose de potentiellement plus important économiquement : il n’a peut-être pas besoin de les rattraper.
Si un modèle beaucoup plus petit est suffisamment bon pour reformuler un texte, analyser un document, extraire des données, traduire, classer des e-mails, interroger des fichiers privés ou résoudre une grande partie des problèmes de programmation ordinaires, envoyer chacune de ces tâches vers un modèle frontier situé à plusieurs centaines de kilomètres commence à ressembler à l’utilisation d’un supercalculateur pour ouvrir une calculatrice.
La bataille pourrait donc ne pas opposer « petits » et « grands » modèles.
Elle pourrait déterminer quelles tâches méritent encore d’utiliser un grand modèle.
Un 27B n’est plus un « petit chatbot médiocre »
Les paramètres constituent une très mauvaise unité pour mesurer directement l’intelligence d’un modèle, mais une excellente manière de comprendre pourquoi le paysage change.
Pendant longtemps, réduire fortement la taille signifiait accepter une dégradation spectaculaire des capacités. Ce compromis s’est déplacé grâce au meilleur entraînement, à la distillation, aux données synthétiques, aux architectures Mixture-of-Experts, au raisonnement durant l’inférence et à des méthodes de quantification beaucoup plus agressives.
Qwen3.8-27B en donne une illustration frappante.
Dans les résultats publiés par Alibaba, le modèle atteint 89,2 % sur GPQA Diamond, 61,7 % sur SWE-bench Pro et 70,7 sur son benchmark de travail bureautique long CoWorkBench. Certaines comparaisons du constructeur le placent même devant des modèles propriétaires beaucoup plus gros sur certaines évaluations de code. Ces chiffres doivent toutefois être maniés avec précaution : plusieurs tests sont internes, les harness ne sont pas toujours identiques et certaines valeurs concurrentes proviennent de méthodologies différentes.
Une évaluation indépendante d’Artificial Analysis rend la situation plus claire. Son Intelligence Index donne actuellement 34 à Qwen3.8-27B en effort xhigh contre 51 à Claude Opus 5 en effort maximal. Sur Humanity’s Last Exam, l’écart est de 34 % contre 55 % ; sur certaines tâches terminales agentiques, il devient beaucoup plus important.
Le petit modèle n’a donc pas gagné.
Mais il n’est plus dans une catégorie où la comparaison serait absurde.
Et surtout, la plupart des utilisateurs ne passent pas leur journée sur Humanity’s Last Exam.
Ils demandent à une IA de résumer huit pages, produire du JSON, expliquer une fonction, rechercher un élément dans une documentation, corriger un e-mail, traduire un paragraphe, classer des documents ou générer du code relativement conventionnel.
C’est ici que le mot « assez bon » devient plus important que « meilleur ».
Toutes les requêtes n’ont pas la même valeur intellectuelle
Imaginons cinq utilisations.
Un système doit déterminer si un ticket client concerne la facturation, un bug ou une résiliation. Un modèle 8B convenablement adapté peut être amplement suffisant.
Un assistant doit reformuler un texte, produire un résumé et en extraire trois dates. Aucun raisonnement scientifique de pointe n’est nécessaire.
Un développeur veut générer une fonction CRUD standard ou poser des questions sur une petite base de code. Un 20B–30B compétent peut déjà être parfaitement utilisable.
À l’inverse, demander à un agent de diagnostiquer une régression répartie sur cinquante fichiers, utiliser plusieurs outils pendant deux heures, comparer des hypothèses et modifier proprement un dépôt entier augmente brutalement le bénéfice d’un modèle frontier.
Et démontrer une conjecture, conduire une recherche complexe ou prendre une décision à fort enjeu pousse encore davantage vers le modèle le plus fiable disponible.
Le problème économique apparaît alors clairement : utiliser le même modèle pour ces cinq tâches est rarement optimal.
| Usage | Petit modèle local | Frontier cloud |
|---|---|---|
| Classification, extraction, JSON | Très adapté | Généralement surdimensionné |
| Réécriture, traduction, résumé courant | Souvent adapté | Utile si difficulté élevée |
| Recherche dans des documents privés | Très intéressant | Plus puissant mais données externalisées |
| Code conventionnel et assistance locale | De plus en plus crédible | Meilleur sur problèmes complexes |
| Agents longs multi-outils | Encore fragile | Avantage important |
| Raisonnement scientifique difficile | Écart encore substantiel | Préférable |
| Très grands contextes et multimodal lourd | Contraint par le matériel | Nettement plus pratique |
| Informations fraîches du Web | Nécessite des outils externes | Souvent intégré nativement |
Cela conduit à une architecture beaucoup plus intéressante qu’un simple remplacement du cloud : le routage.
La machine traite localement ce qu’elle sait résoudre. Lorsqu’elle détecte une tâche difficile, une incertitude élevée ou un besoin d’outils distants, elle escalade vers un modèle plus puissant.
Le modèle frontier cesse alors d’être le moteur par défaut.
Il devient le moteur de recours.
Combien de mémoire faut-il vraiment ?
Un modèle dense stocké avec 16 bits par paramètre nécessite approximativement deux octets par paramètre rien que pour ses poids. Un 30B approcherait donc 60 Go avant même de compter le cache KV et le reste du runtime.
La quantification change radicalement l’équation en représentant les poids avec moins de bits.
À quatre bits, l’ordre de grandeur théorique devient :
| Modèle | Poids bruts théoriques en 4 bits | Configuration locale réaliste |
|---|---|---|
| 8B | ~4 Go | 6–8 Go disponibles |
| 14B | ~7 Go | 10–12 Go |
| 20B | ~10 Go | 16 Go environ selon architecture |
| 27B | ~13,5 Go | 20–24 Go confortables |
| 30B | ~15 Go | 24 Go ou davantage recommandés |
Ce tableau n’est volontairement qu’un ordre de grandeur. Les formats de quantification ajoutent des métadonnées, certains poids peuvent rester à une précision supérieure et surtout le cache KV, utilisé pour conserver le contexte de la conversation, peut consommer plusieurs gigaoctets supplémentaires.
Le cas de gpt-oss-20b est instructif. OpenAI utilise une architecture Mixture-of-Experts et une quantification MXFP4 à environ 4,25 bits pour la majorité de ses poids. Le checkpoint fait officiellement 12,8 Gio et l’entreprise annonce un fonctionnement sur des systèmes disposant d’environ 16 Go de mémoire.
Nous sommes donc déjà dans une zone accessible à des machines personnelles haut de gamme et parfois à des ordinateurs portables utilisant de la mémoire unifiée.
Le processeur seul peut également exécuter beaucoup de ces modèles. Mais « pouvoir charger le modèle » et « obtenir une expérience agréable » sont deux problèmes différents : l’inférence est extrêmement dépendante de la bande passante mémoire.
C’est pourquoi les GPU, APU à grande mémoire unifiée et accélérateurs spécialisés comptent autant que la quantité brute de RAM.
Le plus gros obstacle à l’IA locale est peut-être… le cloud bon marché
On pourrait penser que posséder le matériel rend automatiquement l’inférence locale moins chère.
C’est faux.
Les datacenters ont un avantage extraordinaire : la mutualisation. Un GPU coûteux peut travailler presque continuellement pour des milliers de clients alors qu’une carte graphique personnelle reste inactive une grande partie de la journée.
Et les prix des petits modèles cloud sont devenus dérisoires.
Google facture actuellement Gemini 3.1 Flash-Lite 0,25 par million de tokens de sortie. Gemini 3.8 Flash, nettement plus ambitieux, est proposé jusqu’au 31 décembre 2026 à 0,75 respectivement. Claude Opus 5 coûte de son côté 5 .
Prenons une requête arbitraire mais raisonnable de 2 000 tokens d’entrée et 500 tokens de sortie.
Son coût brut est d’environ :
| Modèle cloud | Coût de la requête |
|---|---|
| Gemini 3.1 Flash-Lite | 0,00125 $ |
| Gemini 3.8 Flash | 0,00338 $ |
| Claude Opus 5 | 0,0225 $ |
Autrement dit, environ huit cents requêtes de ce type sur Flash-Lite coûtent un dollar.
Comparons maintenant avec une station locale dont **2 000 par mois.
Sans même compter l’électricité :
| Utilisation locale | Amortissement matériel par tâche |
|---|---|
| 1 000 tâches/mois | 0,0556 $ |
| 10 000 tâches/mois | 0,00556 $ |
| 100 000 tâches/mois | 0,000556 $ |
Dans ce scénario volontairement simplifié, il faudrait environ 2 470 tâches par mois pour égaler le seul coût token d’Opus 5, environ 16 500 pour Gemini 3.8 Flash et plus de 44 000 pour Flash-Lite.
Cela change complètement la conclusion.
Pour une personne qui pose cent questions par jour, acheter un GPU uniquement dans l’espoir d’économiser sur des API extrêmement bon marché peut être une mauvaise opération.
Pour une entreprise exécutant plusieurs millions de classifications, extractions ou traitements répétitifs chaque mois, le calcul devient tout autre.
Et pour quelqu’un qui possède déjà le matériel, le coût marginal change encore : l’investissement est déjà effectué et il reste essentiellement l’électricité, l’usure et l’administration.
Surtout, cette comparaison suppose à tort que les modèles produisent la même qualité.
Le véritable indicateur n’est pas le coût par token.
C’est le coût par tâche réussie.
Un modèle local quatre fois moins cher qui doit recommencer trois fois, être vérifié manuellement ou escalader régulièrement vers un modèle frontier peut perdre une grande partie de son avantage.
L’énergie ne suit pas simplement le nombre de paramètres
Le raisonnement intuitif « petit modèle = moins d’électricité » est généralement directionnellement correct, mais trop simple.
Une étude de Nidhal Jegham et ses coauteurs a construit un modèle d’estimation tenant compte du matériel, de l’infrastructure et du datacenter pour comparer l’inférence de plusieurs LLM. Dans sa version la plus récente, elle estime environ 0,443 Wh pour un long prompt avec Llama 3.1 8B, contre environ 29 Wh pour DeepSeek-R1 dans une de ses configurations un écart supérieur à 60 fois.
Il ne faut pas interpréter ces nombres comme des mesures universelles prises à la prise électrique. Le papier doit inférer une partie du matériel utilisé par les services propriétaires et modéliser certains paramètres d’infrastructure.
Mais l’un de ses résultats les plus intéressants est justement que le modèle ne suffit pas à prédire la consommation.
La même famille peut être radicalement plus efficace selon l’accélérateur, le taux d’utilisation, le batching, le refroidissement ou le datacenter utilisé. L’étude estime par exemple une forte différence pour DeepSeek-R1 selon l’infrastructure d’hébergement.
Le local possède donc deux effets opposés.
Il évite une partie des infrastructures réseau et peut exécuter un modèle beaucoup plus petit. Mais un GPU personnel sous-utilisé est moins efficacement mutualisé qu’un accélérateur de datacenter traitant continuellement des lots de requêtes.
Là encore, le volume est décisif.
Un modèle 8B utilisé toute la journée pour automatiser une charge de travail précise peut être extrêmement rationnel. Acheter une machine de 500 watts qui reste allumée pour traiter trois prompts quotidiens l’est beaucoup moins.
La latence est l’avantage que les benchmarks mesurent mal
Une requête cloud doit quitter l’appareil, traverser le réseau, être authentifiée, éventuellement attendre dans une file, être exécutée puis revenir.
Un modèle déjà chargé dans la mémoire de la machine supprime une grande partie de cette chaîne.
Il n’est pas nécessairement plus rapide en débit : un datacenter peut disposer d’accélérateurs incomparablement plus puissants. Mais la latence devient locale, prédictible et indépendante de la connexion Internet.
Cette propriété est particulièrement importante pour les logiciels où l’IA doit être presque invisible : autocomplétion, commandes vocales, correction instantanée, recherche dans des fichiers, classification en arrière-plan ou automatisations déclenchées des centaines de fois par heure.
Une réponse à 500 millisecondes utilisée vingt fois par jour et une décision à 500 millisecondes exécutée dix mille fois au milieu d’une interface n’ont pas la même valeur.
Le futur de l’IA locale pourrait donc être beaucoup moins spectaculaire qu’un chatbot géant fonctionnant hors ligne.
Il pourrait simplement s’agir de milliers de petites inférences que l’utilisateur ne remarque même plus.
La confidentialité change encore le calcul
Il existe également une dimension impossible à réduire au prix du token.
Lorsqu’un modèle fonctionne entièrement sur la machine et que le logiciel n’envoie aucune donnée vers des services externes, un document peut être analysé sans quitter l’ordinateur ou le réseau local.
Pour du code propriétaire, des contrats, des dossiers clients, des notes internes ou certains traitements industriels, cela possède une valeur économique propre.
OpenAI présente précisément la possibilité d’exécuter gpt-oss sur une infrastructure contrôlée par l’utilisateur comme un moyen de conserver la résidence des données et de déployer le modèle sur site ou dans un cloud privé.
Mais « local » n’est pas synonyme de « privé » par magie.
Une application locale peut conserver des logs, utiliser une télémétrie distante, appeler un moteur de recherche, télécharger des embeddings ou laisser des fichiers sensibles dans un répertoire mal protégé. Les poids eux-mêmes constituent également une nouvelle dépendance de supply chain.
La vraie garantie est donc architecturale : quelles données sortent réellement de la machine, vers quel service et à quel moment ?
Un modèle local entièrement hors ligne offre une réponse très forte.
Un logiciel « local » qui appelle six API derrière l’interface, beaucoup moins.
Supposons maintenant que 80 % des tâches deviennent locales
Il faut être précis ici : aucune donnée sérieuse ne démontre qu’un modèle 8B–30B est actuellement suffisant pour 80 % de toutes les tâches IA.
« 80 % » est un scénario économique.
Et c’est précisément ce qui le rend intéressant.
Supposons qu’aujourd’hui 100 tâches soient toutes exécutées dans un datacenter. Demain, les appareils ou petits serveurs locaux en absorbent 80 %.
Il n’en reste que 20 pour le cloud.
À usage constant, la demande distante est divisée par cinq.
À première vue, ce serait catastrophique pour une industrie qui engage des centaines de milliards de dollars dans des infrastructures.
Mais il suffit alors que le nombre total de tâches IA soit multiplié par cinq pour que le cloud retrouve exactement ses 100 tâches initiales :
500 tâches × 20 % dans le cloud = 100 tâches cloud
Et si l’usage global était multiplié par dix :
1 000 × 20 % = 200
Le nombre absolu d’appels cloud aurait doublé, alors même que 80 % des tâches seraient devenues locales.
C’est le paradoxe central.
Les petits modèles peuvent capturer l’immense majorité des requêtes et les datacenters peuvent simultanément continuer à croître.
Les deux affirmations ne sont pas contradictoires.
Le vrai danger est la banalisation du token ordinaire
La conséquence économique devient alors plus subtile.
Si un 20B ou un 27B gratuit à télécharger suffit pour extraire une facture, résumer une réunion ou corriger une fonction, il devient difficile de conserver une forte marge sur ces tâches.
Le token générique devient une commodité.
Le fournisseur frontier doit alors gagner de l’argent ailleurs : sur les problèmes les plus difficiles, les grands agents, la recherche Web, la génération vidéo, les énormes contextes, les outils intégrés, la disponibilité industrielle, la sécurité, la gestion des accès, la conformité, l’entraînement et les services managés.
Autrement dit, les petits modèles menacent plus directement la marge de l’inférence ordinaire que l’existence des datacenters eux-mêmes.
Même les hyperscalers peuvent parfaitement héberger des modèles ouverts. Si une entreprise préfère ne pas acheter ses propres GPU, AWS, Azure ou Google Cloud peuvent lui vendre précisément l’infrastructure nécessaire pour exécuter son 27B.
Amazon l’a parfaitement compris : Jassy prédit simultanément la multiplication de modèles d’entreprise plus petits fondés sur des données propriétaires et une expansion massive d’AWS.
Ce n’est pas incohérent.
Le fournisseur de cloud n’a pas besoin que chaque client utilise le plus gros modèle de la planète.
Il a besoin que le client utilise son infrastructure.
Les modèles géants conservent trois forteresses
La première est l’entraînement.
Même si l’inférence se décentralise, fabriquer les meilleurs modèles continue de nécessiter des infrastructures considérables. L’ordinateur personnel peut exécuter les poids ; il ne peut pas reproduire leur entraînement.
La deuxième est la demande de pointe mutualisée.
Une entreprise peut avoir besoin de cent GPU pendant quatre heures et d’aucun le lendemain. Acheter son propre cluster est alors absurde. Le cloud existe précisément pour transformer un investissement fixe en ressource élastique.
La troisième est la frontière des capacités.
Les évaluations indépendantes de 2026 montrent encore une différence réelle entre un 27B moderne et les meilleurs modèles frontier, particulièrement sur le raisonnement difficile et certaines tâches agentiques longues.
Et l’écart importe énormément lorsqu’une erreur vaut plus cher que l’inférence.
Faire économiser vingt centimes d’IA à une entreprise n’a aucun intérêt si le résultat lui coûte ensuite deux heures d’ingénieur.
L’architecture la plus probable ressemble à une pyramide
Le futur le plus économiquement cohérent n’est donc ni « tout local », ni « tout dans un datacenter ».
À la base, des modèles très petits tournent directement sur le téléphone, le PC, la voiture ou l’équipement industriel pour les actions rapides et privées.
Au-dessus, des modèles de l’ordre de 8B à 30B prennent en charge des tâches personnelles ou professionnelles plus sérieuses, éventuellement sur une station de travail ou un petit serveur d’entreprise.
Des modèles ouverts plus importants peuvent vivre sur des serveurs privés ou chez un fournisseur spécialisé.
Et tout en haut restent quelques systèmes frontier extrêmement coûteux, appelés uniquement lorsque leur supériorité justifie réellement leur prix.
Le logiciel peut même cacher cette architecture.
L’utilisateur ne sélectionnerait plus « Qwen », « Claude » ou « GPT ». Un routeur estimerait la difficulté, la sensibilité des données, le coût acceptable et la confiance nécessaire avant de choisir automatiquement le moteur.
Une extraction de date : local.
Un résumé confidentiel : local.
Une question factuelle complexe nécessitant le Web : cloud.
Un bug obscur dans un projet critique : frontier.
Une requête qui échoue localement : escalade automatique.
Cette approche transforme l’intelligence en hiérarchie de ressources, comme l’informatique possède déjà ses caches, sa RAM, son SSD, son réseau local et ses services distants.
On n’envoie pas chaque octet sur le stockage le plus lent et le plus cher.
Pourquoi ferait-on cela avec chaque pensée artificielle ?
Le pari de plusieurs centaines de milliards n’est donc pas forcément mauvais mais il change
Les investissements actuels reposent notamment sur l’idée que l’usage de l’IA va croître extraordinairement vite. Amazon affirme déjà que ses capacités resteront contraintes malgré environ 220 milliards de dollars de CapEx cash prévus en 2026 et dit observer de la demande jusque dans 2028.
Les petits modèles ne suffisent pas à invalider ce scénario.
Ils introduisent toutefois un risque rarement formulé correctement : une partie croissante de la demande future pourrait ne jamais atteindre le datacenter.
Si les performances locales progressent plus vite que la complexité moyenne des tâches, les hyperscalers ne pourront plus compter sur chaque nouvelle utilisation de l’IA comme une nouvelle requête distante.
En revanche, si la baisse des coûts provoque une explosion de l’usage supérieure à cinq fois, un monde où 80 % des tâches sont locales peut encore produire davantage d’inférence cloud qu’aujourd’hui.
C’est peut-être là que se joue le véritable pari.
Pas sur la question de savoir si les petits modèles vont devenir excellents. Ils le deviennent déjà.
Mais sur la vitesse à laquelle l’humanité trouvera de nouvelles choses suffisamment difficiles pour continuer à remplir les datacenters.
Le modèle géant ne disparaîtrait alors pas.
Il cesserait simplement d’être l’électricité que l’on gaspille pour chaque ampoule, pour devenir la centrale que l’on appelle lorsque le réseau local ne suffit plus.
Et si cette transition a réellement lieu, le gagnant de l’IA ne sera peut-être pas celui qui possède uniquement le modèle le plus intelligent.
Ce sera celui qui saura ne l’utiliser que lorsqu’il en a réellement besoin.