« J'ai 32 Go de RAM, ça devrait passer. » Cette phrase revient dans presque toutes les discussions sur l'IA locale, et elle est fausse — pas approximative, fausse.
Quatre contraintes décident de ce qui tourne chez vous, et la première surprise est qu'aucune n'est la puissance de calcul. Voici les quatre murs, dans l'ordre où vous les rencontrerez.
Le poste de coût principal est le matériel, très loin devant tout le reste.
La confidentialité est la seule raison qui rend une exécution locale structurellement supérieure. Les autres sont des arbitrages réversibles.
À budget matériel réaliste, un modèle qui tourne chez vous sera plus petit que les plus gros modèles en ligne, donc moins capable sur les tâches difficiles. C'est une conséquence physique, pas un défaut de configuration.
« Poids ouverts » ne veut pas dire « open source ». Certaines licences interdisent l'usage commercial au-delà d'un seuil d'utilisateurs.
Le modèle en une image
Avant les murs, un rappel de ce qui se passe quand vous posez une question. Tout ce qui suit en découle.
Ce qui se passe entre votre question et sa réponse
Trois choses à retenir de ce schéma, et elles suffisent pour lire la suite.
Un modèle est un fichier de nombres — des milliards de paramètres ajustés automatiquement, enregistrés dans un fichier. Il ne contient aucun de vos documents, aucune base de données.
Ce fichier est relu à chaque token produit — en tout ou en partie selon l'architecture, on y revient. Le modèle ne sort pas une réponse, il sort un fragment de mot, puis recommence depuis le début avec ce fragment en plus.
Et tout ce que vous lui donnez à lire — instruction, historique, documents joints — occupe de la mémoire en plus du modèle lui-même.
Cet article suppose ces trois notions acquises. Si vous voulez la mécanique complète — ce qu'est un poids, comment un texte devient des tokens, d'où vient exactement le coût du contexte — tout est expliqué dans le livre blanc joint en fin d'article, avec les définitions officielles publiées au Journal officiel.
Le livre blanc explique comment ça marche. Cet article dit ce que ça autorise.
Premier mur : la mémoire
L'intuition commune veut qu'une IA locale demande de la puissance de calcul. C'est faux, ou du moins secondaire.
Une machine dispose de deux mémoires distinctes, et elles ne sont pas interchangeables.
La RAM est la mémoire du système. Elle est posée sur la carte mère, à côté du processeur, et sert à tout — votre navigateur, votre tableur, votre système d'exploitation. La VRAM est la mémoire de la carte graphique. Elle est soudée à quelques millimètres du processeur graphique, et ne sert qu'à lui.
Cette proximité physique n'est pas un détail, c'est toute la différence. Un processeur graphique ne travaille à pleine vitesse que sur ce qui se trouve dans sa mémoire.
Ce qui est ailleurs doit transiter par un lien bien plus étroit que les deux mémoires — ou être traité par le processeur central, beaucoup moins doué pour ce type de calcul.
D'où la hiérarchie, et elle est brutale. C'est la VRAM qui décide de ce qui tient. La RAM ne décide que d'une chose : si le débordement sera lent ou insupportable.
| Critère | Mémoire graphique (VRAM) | Mémoire système (RAM) |
|---|---|---|
| Capacité | 8 à 32 Go sur cartes grand public | 16 à 128 Go |
| Vitesse | Très rapide | Lente |
| Prix au giga-octet | Élevé | Faible |
| Le modèle peut-il y tourner ? | Oui, à pleine vitesse | Oui, mais très lentement |
Le modèle doit se trouver là où le calcul a lieu. Raff et ses coauteurs, à propos de la construction des modèles, posent une hiérarchie qui vaut tout autant à l'usage : la mémoire est le facteur le plus critique, parce qu'elle détermine le nombre de processeurs graphiques nécessaires.
Ajouter de la RAM ne compense pas un manque de VRAM.
Ce sont deux mémoires distinctes, sur deux circuits distincts, à deux vitesses distinctes. Passer de 32 à 64 Go de mémoire système ne fera pas tenir un modèle dans une carte graphique de 8 Go.
C'est l'erreur d'achat la plus fréquente sur ce sujet, et elle se chiffre en centaines d'euros dépensés sans effet.
Deuxième mur : la bande passante
Voici le point le plus contre-intuitif de tout l'article. L'inférence n'est pas limitée par la vitesse à laquelle les poids sont multipliés, mais par la vitesse à laquelle ils sont lus.
Reprenez le schéma : le fichier de poids est relu pour chaque token produit. Sur une architecture dense — celle de la majorité des modèles — c'est le fichier entier. Un modèle de 14 Go, ce sont donc 14 Go à faire transiter de la mémoire vers le calcul, à chaque fragment de mot.
La vitesse de production est alors, en première approximation, la bande passante mémoire divisée par la taille du modèle.
| Type de mémoire | Bande passante | Modèle dense de 14 Go |
|---|---|---|
| Carte graphique haut de gamme | ~1 790 Go/s | ~128 tokens/s |
| Carte graphique milieu de gamme | ~450 Go/s | ~32 tokens/s |
| Mémoire système DDR5 double canal | 80 à 110 Go/s | ~7 tokens/s |
Les bandes passantes sont des spécifications constructeurs relevées en août 2026 sur la génération de cartes en vente. La colonne de droite est en revanche un calcul de ma part : le débit divisé par la taille du modèle.
C'est un plafond théorique, pas une mesure. Le débit réel est inférieur — le calcul lui-même prend du temps, et le cache de contexte consomme de la bande passante en plus des poids.
Ces chiffres vieilliront à chaque génération de cartes. Le rapport entre les deux mémoires, lui, restera. Les mesures réelles feront l'objet du volet suivant de cette série.
L'écart entre les deux mémoires va donc d'environ 4 à plus de 20 selon les configurations comparées.
Ces débits sont annoncés en Go/s, avec un o minuscule — en octets. Une fiche qui affiche des Gb/s parle de bits : divisez par huit avant de comparer.
Un facteur 8 d'écart sur une fiche technique, c'est la différence entre un achat réussi et un achat regretté.
La règle à retenir est brutale et rarement dite. Quand une partie du modèle déborde en mémoire système, c'est la partie lente qui dicte le rythme, pas la moyenne.
Un modèle qui tient à 90 % en mémoire graphique ne tourne pas à 90 % de la vitesse. Il tourne beaucoup plus lentement que cela.
Comment on abaisse ces deux murs
Les deux contraintes précédentes ont la même cause : la taille du fichier. Il existe donc deux façons de la contourner.
Compresser : la quantization
Réduire le nombre de bits utilisés pour représenter chaque paramètre. Dhamani et Engler en donnent la définition la plus économe : cela réduit la taille du modèle et son empreinte mémoire en diminuant le nombre de bits de précision.
L'arithmétique est immédiate.
| Précision | Octets par paramètre | Modèle 7 milliards | Modèle 70 milliards |
|---|---|---|---|
| 16 bits (float16) | 2 | 14 Go | 140 Go |
| 8 bits (int8) | 1 | 7 Go | 70 Go |
| 4 bits | 0,5 | 3,5 Go | 35 Go |
Le mécanisme, décrit par François Chollet et Matthew Watson, est plus élégant qu'on ne l'imagine. On met les poids à l'échelle pour qu'ils tiennent dans la plage utile d'un entier 8 bits, on calcule en entiers — nettement plus rapide — puis on remet le résultat à l'échelle en sortie.
Comme la multiplication de matrices est linéaire, les deux mises à l'échelle s'annulent : la seule perte de précision vient de l'arrondi. L'esprit est celui du JPEG — la structure préservée, le détail arrondi — même si le procédé diffère.
Les mêmes auteurs chiffrent le résultat : un modèle quantifié en 8 bits est quatre fois plus petit qu'en 32 bits — soit deux fois moins que la ligne 16 bits du tableau ci-dessus — tout en restant proche de la précision d'origine.
La perte reste faible jusqu'à un certain seuil, puis devient brutale.
Où se situe ce seuil, avec quelles variantes de format et quelles dégradations mesurées, c'est le sujet du volet suivant de cette série — avec des chiffres relevés sur une machine réelle.
Activer moins : le mélange d'experts
Deux architectures se partagent le paysage, et la différence est mal comprise.
Architecture dense
- Tous les paramètres sont traversés à chaque token
- Encombrement mémoire = taille totale
- Volume de lecture = taille totale, à chaque token
- Vitesse limitée par la taille complète
Mélange d'experts
- Une fraction seulement est activée par token
- Encombrement mémoire = taille totale malgré tout
- Volume de lecture = fraction activée seulement
- Beaucoup plus rapide à encombrement égal
Le point est énoncé noir sur blanc par Dhamani et Engler : les paramètres inactifs occupent quand même de la place en mémoire.
Le mélange d'experts n'économise donc pas de la place, il économise de la lecture — et c'est la lecture qui dicte la vitesse. Il abaisse le deuxième mur, pas le premier.
N'imaginez pas un expert Python, un expert juridique, un expert comptabilité.
Les mêmes auteurs sont explicites : ces spécialisations ne s'alignent généralement pas sur des domaines d'expertise humaine. Un expert pourrait se spécialiser dans la ponctuation, un autre dans certaines catégories grammaticales.
La spécialisation est statistique et largement illisible. Le routage se refait à chaque token, et rien ne garantit qu'un même sujet emprunte deux fois le même chemin.
Ce qui entoure le modèle : la pile
On parle beaucoup des modèles, rarement de ce qu'il y a autour — et c'est pourtant là que se prennent les décisions qui durent.
J'ai vérifié le 3 août 2026 : il n'existe aucune taxonomie canonique de la « pile IA locale ». Les découpages publiés diffèrent d'une source à l'autre.
Ce qui suit est donc ma grille de lecture, pas une norme. Elle a l'avantage de séparer proprement deux choses que la plupart des découpages mélangent.
La pile d’exécution d’une IA locale
Le matériel fournit la mémoire et le calcul. Le moteur d'inférence charge les poids, gère le cache et produit les tokens un par un.
Le fichier de modèle contient les poids et leur configuration. L'application cliente est ce que l'utilisateur voit.
À part, deux propriétés du fichier régulièrement présentées à tort comme des couches : l'architecture — dense ou mélange d'experts — et la quantization. Ce sont des caractéristiques du fichier, pas des étages.
Un point souvent mal compris : le moteur n'apporte aucune connaissance. Il exécute des poids qu'il n'a pas fabriqués. Changer de moteur change surtout la vitesse et l'ergonomie — les sorties peuvent varier à la marge, parce que le moteur décide de détails comme les réglages d'échantillonnage par défaut, mais aucun moteur ne rendra un modèle plus savant.
La couche « fichier de modèle » est la seule qui se périme en quelques mois. Les trois autres tiennent des années.
Conséquence pratique : choisissez votre modèle en dernier, derrière une interface standardisée, de façon à pouvoir en changer sans toucher au reste.
Si vos intégrations métier sont attachées à un modèle précis, elles se périmeront avec lui. C'est le principal risque d'architecture de ce sujet, et il est entièrement évitable.
Troisième mur : la licence
Voici une distinction que presque personne ne fait, et qui a des conséquences contractuelles réelles.
Dhamani et Engler la posent sur le terrain de la licence : certains modèles sont diffusés sous une licence autorisant l'usage, la modification et la redistribution complets, quand beaucoup d'autres relèvent de licences dites communautaires, plus restrictives.
L'usage professionnel ajoute une seconde dimension, qui n'est pas dans le livre : on parle de modèles à poids ouverts quand les paramètres sont partagés mais que les données d'entraînement et les méthodes restent fermées.
Ce n'est pas une querelle de vocabulaire. Les licences réellement ouvertes sont Apache 2.0 et MIT, sans restriction significative.
À l'inverse, plusieurs des modèles les plus performants relèvent de licences communautaires qui restreignent l'usage, l'ajustement ou la redistribution — certaines interdisant l'usage commercial au-delà d'un seuil d'utilisateurs, ou l'entraînement d'un modèle concurrent.
Ce sont exactement les deux clauses qui piègent une PME découvrant le sujet six mois après avoir construit son produit dessus.
Ce que « poids ouverts » ne garantit pas
- Le droit d'usage commercial sans condition
- L'absence de seuil d'utilisateurs
- Le droit d'entraîner un autre modèle à partir des sorties
- L'accès aux données d'entraînement
- La reproductibilité de l'entraînement
Je ne nommerai aucun modèle avec sa licence : c'est la couche la plus volatile du sujet, et une information juste aujourd'hui sera fausse dans six mois. Lisez la licence du modèle que vous envisagez, à la date où vous l'envisagez.
Une nuance d'honnêteté pour finir : plusieurs diffusions ouvertes notables ont été construites avec l'aide de systèmes fermés, ce qui brouille la frontière. J'ai développé cette tension dans mon analyse des quatre mécanismes par lesquels l'IA peut fragiliser l'open source.
Quatrième mur : la fiabilité
Le modèle seul ne suffit jamais. Deux briques s'ajoutent, et chacune traîne son lot de malentendus.
Le RAG n'est pas une case à cocher
D'après Raff, Farris et Biderman, ch. 5. Ce terme n'a pas de définition officielle au Journal officiel, contrairement à ceux du livre blanc ; l'administration française emploie aussi « génération augmentée de récupération ».
Notez que cette définition décrit un objectif, pas un procédé — et qu'elle dit « réduire », pas « supprimer ». Le reste de cette section découle de ces deux mots.
Le procédé, lui, tient en trois temps : on calcule des vecteurs pour ses documents, on les range dans une base, et à chaque question on va y chercher les passages les plus proches pour les glisser dans le contexte avant que le modèle ne réponde.
Ce que le RAG ne fait pas
- Il ne rend pas le modèle plus intelligent — il lui donne de la matière, pas des capacités
- Il ne supprime pas les erreurs, il les réduit : le modèle peut encore inventer, pour du contenu introuvable
- Il ne coûte rien — chaque passage inséré consomme du contexte, donc de la mémoire, en plus du modèle
Raff et ses coauteurs livrent la formule qui devrait figurer en tête de tout projet : si vous ne savez pas construire un moteur de recherche efficace pour votre problème, vous ne saurez pas construire un RAG efficace.
Freed, Jacobs et Rózsa détaillent ce que le mot recouvre en production : convertir les PDF en texte, transformer les tableaux en énoncés exploitables, enrichir les métadonnées, découper en unités sémantiques cohérentes, puis seulement calculer les vecteurs.
L'essentiel du travail est en amont du modèle, et c'est du traitement documentaire classique.
Les appels d'outils déraillent, mais pas pour la raison qu'on croit
Un modèle qui appelle des fonctions, consulte une base, déclenche une action : le principe est plus simple qu'il n'y paraît. Les tokens produits sont mis en correspondance avec un ensemble d'actions disponibles.
On lit souvent que les petits modèles échouent sur les appels d'outils parce qu'ils sont petits.
Raff, Farris et Biderman pointent autre chose : l'efficacité de l'usage d'un outil dépend de la variété des exemples d'usage de cet outil dans les données d'entraînement. Un outil rare dans les données sera mal utilisé, quelle que soit la taille du modèle.
Ils ajoutent qu'adosser un outil formellement vérifiable ne garantit pas que la séquence entière sera exécutée correctement. On peut brancher une calculatrice parfaite sur un modèle qui l'appellera au mauvais moment.
Avant de reprocher à un modèle sa taille, regardez si l'outil que vous lui donnez ressemble à quelque chose qu'il a déjà vu.
Le respect strict du format d'appel est le prérequis de toute chaîne automatisée. C'est le point de rupture le plus fréquent des projets qui vont trop vite vers l'agentique.
Alors, local ou pas ?
Quatre motivations mènent à quatre montages différents. Ne pas trancher revient à monter une infrastructure sans savoir pourquoi, puis à la démonter un an plus tard.
La confidentialité est la seule raison structurellement irréversible. Les trois autres sont des arbitrages économiques qui peuvent basculer si les prix changent.
Sur ce point, l'argument le plus solide n'est pas le mien : c'est celui des fournisseurs. Leurs propres consignes demandent de ne pas saisir d'information confidentielle dans les conversations — l'un précise même qu'il ne peut pas supprimer une requête isolée de l'historique.
Le cas d'école est connu : en avril 2023, des ingénieurs collent du code propriétaire et des comptes rendus de réunion dans un assistant en ligne ; dans les mois qui suivent, plusieurs grands groupes interdisent formellement la pratique.
Amit Bahree fait le même constat côté architecture : pour les applications qui ne peuvent être connectées au nuage pour des raisons réglementaires ou de politique interne, les petits modèles se déploient plus facilement sur site. La contrainte de conformité pousse donc vers des modèles plus modestes.
Sur le coût, un argument est presque toujours oublié. Dhamani et Engler décrivent une économie fragile : beaucoup d'éditeurs opèrent à perte, soutenus par le capital-risque. Si la monétisation ne suit pas les charges, préviennent-ils, les tarifs et les conditions d'accès pourraient évoluer significativement.
Autrement dit : le local est une couverture contre le risque tarifaire, pas seulement une économie immédiate.
Une exécution locale exige plus d'expertise, plus d'infrastructure et plus de surveillance qu'une interface en ligne. C'est ce temps d'intégration et de maintien en condition qui constitue le second poste de coût, après le matériel.
L'alignement varie fortement d'un modèle ouvert à l'autre. Certains embarquent des garde-fous documentés ; d'autres versions dérivées les retirent délibérément. Vous êtes responsable de ce que vous déployez.
Et un modèle local se trompe avec exactement la même assurance qu'un modèle en ligne — sans le filet du fournisseur.
Ce qui tient sur une machine de bureau
Avant le tableau, le critère de tri. Il vient de Raff, Farris et Biderman : si la moindre erreur est inacceptable dans votre système, vous ne devriez pas utiliser d'apprentissage automatique, et encore moins un modèle de langage.
Ces modèles fonctionnent au mieux sur des problèmes flous, où ce qui est correct est difficile à décrire, et sur des situations répétitives. Appliquez ces deux critères, le tri se fait presque seul.
| Tâche | Sur une machine de bureau | Pourquoi |
|---|---|---|
| Autocomplétion de code | ✅ Réaliste | Contexte court, tolérance à l'erreur, tâche répétitive |
| Question sur un fragment de code | ✅ Réaliste | Périmètre borné, vérification immédiate |
| Code répétitif, boilerplate | ✅ Réaliste | Formulaire par nature |
| Extraction structurée depuis un document | ✅ Réaliste | Tâche fermée, sortie vérifiable |
| Classification, tri, étiquetage | ✅ Réaliste | Sortie contrainte, volume élevé |
| Recherche sémantique interne | ✅ Réaliste | Peu coûteux, données sensibles |
| Assistant de code multi-fichiers | ❌ Hors de portée | Exige un contexte long, donc beaucoup de mémoire |
| Rédaction longue structurée | ❌ Hors de portée | La cohérence sur la longueur décroche |
| Chaînes agentiques fiables | ❌ Hors de portée | Le respect du format d'appel n'est pas acquis |
| Tout ce qui n'admet aucune erreur | ❌ Hors de portée | Ce n'est pas un problème de taille de modèle |
Comme la grille de lecture de la pile plus haut, ce classement est le mien. Il découle des deux critères de Raff, Farris et Biderman et de ce que j'ai vu en mission — pas d'un banc d'essai.
« Machine de bureau » y désigne un poste équipé d'une carte graphique grand public, faisant tourner un modèle compressé de l'ordre de sept à quatorze milliards de paramètres. Changez l'une de ces trois variables et certaines lignes basculent.
Le volet suivant de cette série remplacera ces verdicts par des mesures.
À la colonne de gauche, ajoutez une catégorie transversale : tout ce qui touche à des données qui ne doivent pas sortir. C'est le cas d'usage où le local n'a pas de concurrent.
Un chiffre de réalisme pour finir : Dhamani et Engler citent un rapport du MIT de 2025 selon lequel 95 % des projets pilotes d'IA générative en entreprise n'ont produit aucun retour mesurable. Un avertissement sur le cadrage, pas une condamnation de la technologie.
Ce n'est pas un choix binaire
Le local vient en complément, pas en remplacement. Le montage raisonnable est mixte : ce qui est confidentiel reste chez vous, le reste va là où c'est le plus efficace.
C'est cohérent avec ma façon de travailler en général, détaillée dans mes raisons de privilégier l'open source par défaut. Quant aux usages métier de ces modèles en contexte professionnel réel, c'est le sujet d'un autre article.
Coût — le poste principal est le matériel : plusieurs centaines à plusieurs milliers d'euros de machine, selon la mémoire graphique visée. Le second poste est le temps d'intégration et de maintien en condition, largement sous-estimé.
Risque — un modèle local se trompe avec la même assurance qu'un modèle en ligne, sans garde-fou fournisseur. La couche modèle se périme en quelques mois ; si vos intégrations lui sont attachées, elles se périment avec elle.
Bénéfice — un seul est structurel : les données ne sortent pas. Tout le reste est un arbitrage économique réversible.
Ce qu'il faut retenir
Quatre murs. La mémoire décide de ce qui tient. La bande passante décide de la vitesse. La licence décide de ce que vous avez le droit d'en faire si vous construisez un produit. Et la fiabilité des appels d'outils décide de ce qui peut être automatisé.
La puissance de calcul, celle à laquelle tout le monde pense en premier, ne décide de rien.
Avant de choisir une machine ou un modèle, trois questions dans cet ordre.
Quelles données ne doivent pas sortir ?
"S'il n'y en a aucune, l'API l'emporte presque toujours. C'est la seule question dont la réponse est irréversible."
Quelle tâche, et quelle taille de modèle exige-t-elle ?
"C'est la taille qui décide de la mémoire nécessaire et de la vitesse obtenue. Le plus petit modèle qui fait le travail est toujours le bon."
Combien de texte d'un seul tenant ?
"Le contexte se paie en mémoire, en plus du modèle. Vérifiez ce qu'il reste une fois le modèle chargé."
Ces trois questions se répondent sur un coin de table, avant tout devis. Elles éliminent la majorité des mauvais montages.
Ce qui vieillira dans cet article, ce sont les noms de produits — je les ai donc évités. Les contraintes physiques, elles, tiendront. La formule qui résume tout tient en cinq mots : une IA locale ne se choisit pas, elle se dimensionne.
Le volet suivant passera à la pratique — installation réelle, mesures, débits observés.
Ouvrages
- Raff E., Farris D., Biderman S. (2025), *How Large Language Models Work*, Manning : www.manning.com ↗
- Dhamani N., Engler M. (2026), *Introduction to Generative AI*, 2e édition, Manning : www.manning.com ↗
- Chollet F., Watson M. (2026), *Deep Learning with Python*, 3e édition, Manning : www.manning.com ↗
- Bahree A. (2024), *Generative AI in Action*, Manning : www.manning.com ↗
- Freed G., Jacobs T., Rózsa M. (2025), *Effective Conversational AI*, Manning : www.manning.com ↗
Matériel
- NVIDIA — spécifications de bande passante mémoire des générations de cartes citées : www.nvidia.com ↗