14 août 2026 · 15 min de lecture · Mise en œuvre

Ce qu'un modèle local sait faire — et ce qu'il ne sait pas faire

Mardi matin, salle de réunion. Karim fait la démonstration promise depuis trois semaines : un modèle d'IA installé sur un serveur de l'entreprise, sans aucune connexion vers l'extérieur.

Il dépose un contrat de quarante pages et pose une première question : « quel est le délai de préavis prévu ? »

Douze secondes. Réponse : trois mois, avec la page et le paragraphe. C'est exact. Autour de la table, on hoche la tête.

Deuxième question : « ce délai est-il conforme à la loi française ? »

La réponse arrive, sur le même ton assuré, et cite un article du Code du travail. Sauf que cet article ne dit pas ce qu'on lui fait dire. Personne ne s'en aperçoit sur le moment ; c'est la juriste qui le signalera le lendemain.

La différence entre les deux questions est toute simple. La première, la réponse était écrite dans le document. Le modèle a lu et recopié. La seconde, elle n'y était pas. Il a donc fallu qu'il aille chercher dans ce qu'il croit savoir — et là, il ne lit plus : il devine. Quand il ne sait pas, il ne dit pas « je ne sais pas ». Il fabrique une réponse qui a l'air juste.

Mais regardez ce qui a réellement sauvé la première réponse. Ce n'est pas qu'elle citait sa source : la seconde aussi citait un article précis, avec le même aplomb.

Car un modèle invente également ses renvois. Il peut annoncer « page 12, troisième paragraphe » pour une clause qui n'y figure pas. Ne comptez donc pas sur une distinction confortable entre un modèle honnête sur vos documents et menteur sur le reste : il se trompe des deux côtés, et de la même voix.

Ce qui change, c'est le prix de la vérification. Quand la réponse porte sur un texte que vous avez fourni, le référentiel est fini, il est là, et aller voir prend dix secondes — un renvoi inventé s'effondre immédiatement sous ce contrôle. Quand elle porte sur ce que le modèle croit savoir, le référentiel est le monde entier : vous ne l'avez pas sous la main, la vérification demande un spécialiste et un délai, et rien ne vous signale les réponses qui en ont besoin. Dans la salle de réunion, il a fallu une juriste et vingt-quatre heures.

Retenez donc la distinction sous sa forme utile, tout le reste en découle :

un modèle se trompe des deux côtés. Mais sur vos documents, l'erreur coûte dix secondes à débusquer ; sur sa mémoire, elle coûte un spécialiste et une journée.

La règle pratique n'est donc pas « on peut lui faire confiance sur nos documents ». C'est : exigez le renvoi, et allez le vérifier. Le renvoi ne vaut pas parce qu'il serait fiable — il vaut parce qu'il rend le contrôle instantané.

C'est pour cela qu'un modèle local n'est ni « suffisant » ni « insuffisant » dans l'absolu. Il est excellent sur certaines tâches, mauvais sur d'autres, et la frontière entre les deux n'est pas là où on l'imagine.

Voici où elle passe.

D'abord, deux mots de vocabulaire

Il existe deux familles de modèles d'IA, et la différence est simple.

Les modèles fermés appartiennent à leur éditeur et restent chez lui. ChatGPT, Gemini, Claude fonctionnent ainsi : vous envoyez votre question sur leurs serveurs, la réponse revient. Vous ne pouvez pas les installer sur vos propres machines.

Les modèles ouverts sont téléchargeables. Meta, Mistral, Alibaba, OpenAI et quelques autres publient certains de leurs modèles librement : vous récupérez un fichier, vous l'installez sur votre serveur, et il fonctionne sans plus jamais rien envoyer à personne.

C'est de cette seconde famille qu'on parle quand on dit « IA locale ». Et la question que tout le monde se pose, légitimement, c'est : est-ce que ceux-là valent les autres ?

Ce qu'on entend, et ce que disent les mesures

Deux phrases reviennent en permanence dans les réunions, et elles sont fausses toutes les deux — dans des directions opposées.

« Les modèles qu'on installe chez soi, ce sont des jouets. » C'est ce que dit souvent le DSI, ou le prestataire informatique en place. C'était vrai en 2023, ça ne l'est plus.

L'université Stanford publie chaque année le rapport de référence sur le sujet. Son édition 2026 mesure l'écart entre le meilleur modèle fermé du monde et le meilleur modèle téléchargeable : 3,3 % (Stanford AI Index 2026). L'institut de recherche Epoch AI exprime la même chose en temps : depuis janvier 2026, les modèles téléchargeables ont en moyenne quatre mois de retard sur ce qui se fait de mieux (Epoch AI).

Quatre mois de retard sur le sommet mondial. Pour la quasi-totalité de ce que fait une entreprise au quotidien, cet écart ne se voit pas.

« Puisque c'est équivalent, autant tout rapatrier chez nous. » Celle-là vient plutôt du dirigeant, souvent juste après avoir lu un article enthousiaste. Les mêmes sources la contredisent.

L'écart de 3,3 % est en train de se creuser : il n'était que de 0,5 % en août 2024. Et six des dix meilleurs modèles du classement de référence sont aujourd'hui des modèles fermés.

En clair : les modèles téléchargeables ont rattrapé énormément de terrain, mais le rattrapage s'est arrêté. Cela ne change rien pour la plupart des usages professionnels. Cela compte pour ceux qui ont besoin du tout meilleur.

Ce qu'un modèle local fait très bien

Il existe une famille de tâches où un modèle installé en interne rend un excellent service, et où l'écart avec les meilleurs modèles du marché est imperceptible pour l'utilisateur.

Reformuler, synthétiser, structurer. Transformer des notes brutes en compte rendu, condenser un fil de courriels, produire un résumé exécutif. C'est la tâche la plus fréquente en entreprise, et c'est celle où les modèles ouverts sont le plus proches du sommet.

Extraire de l'information d'un document que vous lui donnez. Retrouver les dates, les montants, les parties, les échéances dans un contrat ou un devis. La différence avec la question qui a piégé Karim est décisive : ici, la réponse est dans le document, et vous pouvez exiger qu'il dise où. Il n'est pas infaillible pour autant — il lui arrive de fusionner deux clauses voisines, d'attribuer un engagement à la mauvaise partie, ou de renvoyer à une page où rien ne correspond. Mais chacune de ces erreurs se voit en ouvrant le document à l'endroit indiqué.

Classer et router. Trier des demandes entrantes, qualifier des tickets, repérer les courriels qui appellent une réponse urgente. Des modèles de quelques milliards de paramètres, qui tournent sur un matériel modeste, suffisent largement.

Traduire et adapter le registre. Faire passer un texte du technique au commercial, du brouillon au présentable.

Aider à écrire du code courant. Générer une fonction, expliquer un script existant, produire des tests. Les variantes spécialisées sont solides dans ce domaine. C'est l'exception de cette liste : ici, le modèle puise bel et bien dans sa mémoire, et il lui arrive d'appeler une fonction qui n'existe pas. Mais la vérification reste bon marché — le code s'exécute, ou il ne s'exécute pas.

Répondre sur vos propres documents. C'est l'usage qui justifie à lui seul beaucoup d'installations locales : brancher le modèle sur vos procédures, vos comptes rendus, votre base documentaire, et permettre à chacun de poser une question en français plutôt que de fouiller dans une arborescence. La qualité tient alors moins au modèle qu'à la préparation de la base documentaire et au cloisonnement des accès — ce dernier point est repris plus bas.

Le point commun de cette liste : le modèle travaille sur une matière que vous lui fournissez, et dont vous disposez pour le contrôler — ou, dans le cas du code, sur une matière dont la machine vérifie le résultat à votre place. Dans les deux cas, l'erreur ne coûte pas cher à trouver. C'est le régime dans lequel il est le plus fiable.

Ce qu'il fait mal, ou pas du tout

Passons à l'autre versant, celui dont on parle beaucoup moins dans les démonstrations commerciales.

Il invente, avec aplomb

C'est le piège de la scène d'ouverture, et aucun modèle — local ou distant, ouvert ou fermé — n'en est exempt.

Rien, dans le ton d'une réponse, ne distingue une information exacte d'une information fabriquée. Pas d'hésitation, pas de nuance, pas de signal. C'est la caractéristique la plus dangereuse de ces outils, et elle est structurelle : le modèle ne cherche pas à dire vrai, il produit la suite de mots la plus vraisemblable.

La règle pratique qui en découle tient en une phrase : faites-lui traiter de l'information, pas produire de la connaissance. Un modèle local qui résume votre contrat se trompe parfois, mais ses erreurs se rattrapent en ouvrant le contrat. Le même modèle interrogé sur le droit applicable produit des erreurs qui, elles, ne se rattrapent pas toutes seules — il n'a pas de base juridique à jour, seulement des souvenirs statistiques de textes vus pendant son entraînement.

Il se perd dans les tâches longues

C'est la limite la moins connue, et l'une de celles qui font échouer le plus de projets.

Un modèle ne garde pas de mémoire d'une fois sur l'autre. À chaque question, on lui renvoie tout : la consigne de départ, le document, et l'intégralité de ce qui s'est dit depuis le début de l'échange. Cette pile de texte qu'il relit à chaque fois porte un nom, le contexte, et elle a une taille maximale.

Les éditeurs annoncent aujourd'hui des contextes énormes — l'équivalent de plusieurs centaines de pages. C'est vrai, et c'est trompeur. Pouvoir tout garder ne veut pas dire tout traiter correctement. Plus la pile grossit, plus le modèle devient distrait : il oublie la consigne du début, se fixe sur un détail, repart en arrière. Le phénomène a désormais un nom, la « pourriture du contexte », et un banc d'essai dédié (LOCA-bench, arXiv, février 2026).

Les mesures sont brutales. Mêmes tâches, même information disponible, seule la longueur de l'historique change : Claude 4.5 Opus passe de 96 % de réussite à 14,7 %, DeepSeek de 78,7 % à 6,7 %, Kimi K2 de 74,7 % à 2,7 %. D'un modèle qui réussit presque toujours à un modèle qui échoue presque toujours. L'information dont il a besoin est pourtant toujours là, sous ses yeux. Il ne la retrouve plus, perd de vue son objectif et se met à tourner en rond.

Et ce n'est pas un défaut des petits modèles installés en entreprise : les plus grands services commerciaux échouent pareillement. Sur un test consistant à mener une tâche longue à travers 32 applications différentes, le meilleur modèle évalué n'aboutit que dans 38,6 % des cas (Tool Decathlon, arXiv).

Le laboratoire METR prend la même limite par un autre bout : non plus la longueur de l'historique, mais la durée de la tâche. Sur des travaux de génie logiciel, il mesure le temps qu'une tâche prendrait à un humain expérimenté et à partir duquel le modèle échoue une fois sur deux. En mars 2025, ce seuil était d'environ cinquante minutes. Le chiffre a vieilli — METR observe qu'il double tous les sept mois environ — mais c'est la tendance qui compte : la limite recule vite, et elle existe toujours (METR, arXiv 2503.14499).

Ce qu'il faut en retenir pour vos projets : découpez. Une suite de petites étapes, chacune vérifiée par quelqu'un, fonctionne très bien. « Traite-moi ce dossier de A à Z tout seul » ne fonctionne pas — et pas seulement en local. C'est la limite de la technologie en 2026 ; elle apparaît simplement un peu plus tôt sur un petit modèle.

Il n'est pas forcément rapide

Les grands services en ligne tournent sur des fermes de cartes graphiques mutualisées entre des millions d'utilisateurs. Votre serveur, non. À qualité de réponse comparable, un modèle local est souvent plus lent — parfois nettement, si le matériel est juste dimensionné ou si plusieurs personnes s'en servent en même temps.

Sur une reformulation courte, la différence ne se remarque pas. Sur un document de cinquante pages, elle se compte en dizaines de secondes, parfois en minutes, le temps que le modèle lise l'ensemble avant de commencer à répondre. Et ce délai s'allonge mécaniquement avec le nombre d'utilisateurs simultanés.

Ce n'est pas rédhibitoire, c'est un paramètre de conception. C'est en revanche l'un des motifs d'abandon les plus souvent rapportés sur ce type de projet : un outil qui fait attendre finit par ne plus être ouvert — et les équipes retournent alors à leur téléphone personnel, ce que l'installation cherchait précisément à éviter. Mieux vaut viser un modèle un peu moins savant et confortable à l'usage qu'un modèle impressionnant sur le papier que personne n'a la patience d'utiliser.

Cela dit, la lenteur ne pose problème que si quelqu'un attend devant son écran. Beaucoup de tâches n'ont aucune raison d'être traitées en direct : classer les courriels de la journée, indexer les documents déposés cette semaine, produire les résumés de tous les comptes rendus du mois. Ces travaux-là peuvent tourner la nuit, sur une machine qui ne fait rien d'autre, et les résultats attendent tranquillement le matin.

C'est même un avantage propre au local : sur un service en ligne, chaque document traité est facturé, ce qui incite à en traiter le moins possible. Sur votre serveur, une fois le matériel payé, faire tourner la machine huit heures pendant que personne ne travaille ne coûte que de l'électricité. Vous pouvez lui confier des volumes qu'aucun budget ne justifierait ailleurs.

Il décroche sur le raisonnement difficile

C'est là que l'écart entre modèles ouverts et fermés cesse d'être théorique. Sur les questions vraiment difficiles — un raisonnement scientifique pointu, une analyse juridique fine, un problème de mathématiques complexe —, les meilleurs modèles fermés gardent une avance réelle. Et il faut ajouter une couche : le modèle que vous ferez tourner sur votre serveur ne sera pas le meilleur modèle téléchargeable du monde, mais celui que votre machine peut faire tenir.

C'est un arbitrage, pas un défaut. Encore faut-il le faire en connaissance de cause.

Il se débrouille mal quand il doit commander autre chose

Deux mots à poser avant d'expliquer, parce qu'ils reviennent partout dès qu'on parle d'IA locale.

La taille d'un modèle se mesure en « paramètres », et vous verrez toujours ce chiffre dans son nom : 7B, 14B, 32B — B pour milliards. C'est en gros son volume de cerveau. Plus le chiffre est grand, plus le modèle est capable, et plus il faut de machine pour le faire tourner.

La compression est l'opération qui permet de faire tenir ce cerveau dans une machine plus modeste. On réduit la précision des calculs, un peu comme on réduit la qualité d'une photo pour l'envoyer par courriel : le fichier est bien plus léger, l'image reste reconnaissable, mais on a perdu quelque chose. Presque tous les modèles installés en entreprise sont compressés, c'est normal et souvent indispensable.

Venons-en au problème. Tant que le modèle se contente d'écrire du texte, ces deux réglages se voient peu. Mais dès qu'on veut qu'il déclenche une action — aller chercher une fiche client dans votre base, créer un ticket, lancer une recherche —, il doit produire une commande parfaitement formée, à la virgule près. Un texte à peu près juste reste utile ; une commande à peu près juste ne fonctionne pas du tout.

C'est aussi la famille de tâches où l'écart entre modèles ouverts et fermés cesse d'être anecdotique. Sur le test des 32 applications cité plus haut, le meilleur modèle fermé atteint 38,6 % de réussite ; le meilleur modèle ouvert, 20,1 %. Ce n'est plus 3,3 % d'écart, c'est un facteur deux.

Deux pièges, donc.

Un modèle trop petit se trompe souvent dans ces commandes. En dessous d'environ 7 milliards de paramètres, sauf modèle spécialement entraîné pour ça, le taux d'échec devient rédhibitoire.

Un modèle trop compressé aussi — et c'est le piège vicieux : la compression casse la fiabilité des commandes avant de dégrader visiblement la qualité du texte. En discutant avec lui, tout semble parfait. Et pourtant les automatismes branchés derrière tombent en panne régulièrement, sans qu'on comprenne pourquoi.

Concrètement : si votre projet se limite à écrire, résumer et répondre, un petit modèle bien compressé fera parfaitement l'affaire. S'il doit piloter des actions dans vos outils, il faut viser plus grand et compresser moins — donc prévoir la machine qui va avec.

Il ne sait rien de ce qui s'est passé après son entraînement

Évident, et pourtant régulièrement oublié : un modèle installé chez vous ne connaît pas l'actualité, votre dernier tarif, ni le règlement paru le mois dernier. Sans branchement sur vos sources, c'est un expert compétent revenu d'une longue absence, qui l'ignore.

La question du matériel, sans enrobage

Pour fonctionner, un modèle doit tenir entier en mémoire. C'est cette contrainte, et pas la marque du modèle, qui détermine ce que vous pourrez faire.

Deux façons de le loger. Sur une carte graphique, c'est la solution rapide : ces cartes sont conçues pour ce type de calcul, mais leur mémoire est chère et limitée. Ou sur le processeur et la mémoire vive de la machine, comme n'importe quel logiciel : beaucoup moins cher, beaucoup plus lent — comptez, en pratique, un facteur cinq à dix. C'est parfaitement viable pour de petits modèles, ou pour des traitements de nuit où personne n'attend la réponse.

Les ordres de grandeur, sans prix précis : ils bougent vite, et le marché de la mémoire est particulièrement tendu en 2026.

• Petits modèles (1 à 8 milliards de paramètres) : quelques gigaoctets. Un ordinateur récent, même sans carte graphique dédiée, peut suffire. De quoi classer, trier, reformuler, pour une ou deux personnes.
• Milieu de gamme (14 à 32 milliards) : c'est là qu'un modèle local devient franchement utile. Une carte graphique de 24 Go y suffit généralement. C'est le point d'équilibre de la plupart des installations d'entreprise.
• Grands modèles (70 milliards et au-delà) : plusieurs dizaines de gigaoctets, matériel professionnel ou plusieurs cartes, budget d'un autre ordre.

Deux avertissements que l'on vous donnera rarement.

Le nombre d'utilisateurs simultanés compte autant que la taille du modèle. Une configuration confortable pour trois personnes s'effondre à trente. C'est un dimensionnement, pas un achat.

Un modèle plus gros que ce que votre machine encaisse est pire qu'un modèle plus petit. Il déborde en mémoire lente, et vous obtenez des réponses justes à une vitesse qui décourage l'usage. Mieux vaut un modèle modeste qui répond en quelques secondes qu'un grand modèle qui répond en deux minutes : le premier sera utilisé, le second sera abandonné au bout d'une semaine.

Le piège des licences : « gratuit » ne veut pas dire « vous en faites ce que vous voulez »

Sujet aride, conséquences très concrètes.

Quand un éditeur publie un modèle, il livre le fichier — pas la recette. Vous obtenez le résultat de l'entraînement, sans les données ni la méthode qui permettraient de le refabriquer. C'est amplement suffisant pour l'utiliser, mais cela veut dire que vous ne saurez jamais exactement avec quoi il a appris. Et la tendance ne va pas dans le bon sens : l'indice de transparence des éditeurs, après être monté de 37 à 58 entre 2023 et 2024, est retombé à 40 en 2025 (Stanford AI Index 2026, chapitre Responsible AI).

Surtout, chaque modèle est livré avec un contrat d'utilisation, et ces contrats ne se ressemblent pas.

Certains sont totalement permissifs : usage commercial libre, aucune redevance, aucune condition. C'est le cas des modèles publiés par Mistral, Alibaba, DeepSeek ou OpenAI sous les licences dites Apache 2.0 et MIT — les deux noms à repérer.

D'autres ne le sont pas. Meta diffuse ses modèles Llama sous sa propre licence maison, qui pose des conditions : au-delà d'un très grand nombre d'utilisateurs, il faut un accord séparé avec Meta. Le seuil ne concernera jamais une PME, mais le principe est là — ce n'est pas un modèle que vous pouvez utiliser sans lire ce que vous signez.

Une seule règle à retenir : le contrat est attaché au modèle, pas à la marque.

Le même éditeur publie un modèle librement et garde le suivant pour lui. Vérifiez donc la fiche du modèle exact que vous installez, et pas la réputation de celui qui l'a produit.

Comment décider, concrètement

Quelques questions dans l'ordre, qui évitent l'essentiel des déceptions.

Le modèle travaille-t-il sur vos documents, ou sur ses souvenirs ? Première catégorie : allez-y, à condition d'exiger les renvois et d'aller en contrôler quelques-uns au hasard, de temps en temps. Seconde : prévoyez une vérification humaine systématique, par quelqu'un qui a la source sous les yeux, ou renoncez.

Combien d'étapes la tâche demande-t-elle, et quelqu'un les regarde-t-il ? Deux ou trois étapes, avec un relecteur au bout : le modèle s'en sortira très bien. « Reçois la commande, vérifie le stock, crée la facture, envoie le courriel, mets à jour le tableau de suivi » sans personne pour contrôler : aucun modèle ne fera cela de façon fiable aujourd'hui, ni le vôtre ni celui d'un géant du numérique. Plus la chaîne est longue et moins elle est surveillée, plus la probabilité que tout aille jusqu'au bout s'effondre.

Quel est le coût d'une erreur ? Une reformulation ratée se voit et se corrige. Une clause juridique inventée dans un contrat signé, non. C'est ce critère, et non la performance brute, qui doit décider du niveau de contrôle.

Combien de personnes, en même temps ? C'est cette réponse qui dimensionne le matériel.

Testez sur vos vrais documents. Les classements publics mesurent des tâches génériques en anglais. Ils ne disent rien de la qualité sur vos comptes rendus, votre vocabulaire métier, vos formulaires. Une semaine d'essai sur vos propres fichiers vaut tous les bancs d'essai.

Ce que le local règle — et ce qu'il ne règle pas

Il règle la question de la confidentialité, et c'est sa raison d'être principale : rien ne sort, donc rien ne circule, rien n'est réutilisé pour entraîner un tiers, et rien ne dépend d'une politique de rétention étrangère. Il autorise aussi l'usage massif, sans le réflexe de compter ce que coûte chaque requête.

Il rend la dépense prévisible, avec une nuance. Une fois le matériel amorti, le coût marginal se réduit à l'électricité — mais un serveur qui consomme en continu pour cinquante requêtes par jour revient cher à la requête. L'économie apparaît quand la machine est remplie, d'où l'intérêt des traitements de nuit évoqués plus haut.

Il ne règle pas la conformité. L'AI Act se déclenche sur la mise en service d'un système dans l'Union européenne, sans considération de connectivité : un outil de tri de candidatures installé en local reste un système de recrutement, avec les obligations correspondantes. Le RGPD non plus ne s'évapore pas — base légale, information des personnes, durées de conservation restent entières, simplement traitées en interne.

Il ne règle pas vos droits d'accès. Un modèle branché sur une base documentaire mal cloisonnée répondra à tout le monde ce que seuls certains devaient savoir. Le cloisonnement reste votre travail, et le modèle le rendra visible.

Il ne se maintient pas tout seul. Quelqu'un doit appliquer les correctifs, surveiller la machine et décider quand changer de modèle — car le paysage bouge tous les quelques mois, et vous venez de lire qu'un modèle ouvert accuse environ quatre mois de retard sur le sommet. Dans une entreprise sans informaticien, c'est souvent l'obstacle réel, bien avant le prix de la carte graphique. Cela se sous-traite ; cela ne se supprime pas.

Il ne remplace pas tout. Pour le raisonnement le plus exigeant, les meilleurs modèles du marché gardent une avance mesurable. La bonne question n'est pas « local ou pas », mais « quelles tâches en local, lesquelles ailleurs, et lesquelles pas du tout ».

Pour finir

La démonstration de Karim n'était pas un échec. Elle a montré exactement ce qu'il fallait voir : un outil remarquable quand il lit, hasardeux quand il devine.

Le réflexe, après ce genre de séance, est souvent d'abandonner. C'est dommage, parce que la première réponse — le bon délai, la bonne page, en douze secondes — était bien réelle. Et c'est l'essentiel de ce dont une entreprise a besoin au quotidien.

Un modèle local n'est pas un collègue omniscient. C'est un très bon lecteur, très rapide, qui ne sort jamais du bâtiment.

Employé pour lire, il fait gagner un temps considérable. Employé comme un oracle, il citera, avec une belle assurance, des articles de loi qui n'existent pas.

Sources

• Stanford HAI — AI Index 2026, chapitre Performance technique (écart ouvert/fermé) et chapitre Responsible AI (indice de transparence)
• Epoch AI — Open models lag state-of-the-art closed models by 4 months, mai 2026
• LOCA-bench — Benchmarking Language Agents Under Controllable and Extreme Context Growth, arXiv, février 2026
• Tool Decathlon — Benchmarking Language Agents for Diverse, Realistic, and Long-Horizon Task Execution, arXiv, 2025
• METR — Measuring AI Ability to Complete Long Tasks, arXiv 2503.14499, mars 2025

Article à jour au 14 août 2026. Le domaine évolue vite : les ordres de grandeur donnés ici valent pour l'été 2026 et méritent d'être revérifiés avant toute décision d'investissement.