Plateforme IA locale et LLM open source : l'analyse d'un choix on-premise

Une plateforme IA locale bâtie sur un LLM open source : cette analyse examine ce que l'on-premise apporte réellement, ce qu'il demande en retour, et pourquoi le solde penche en sa faveur dès que la donnée compte. Chaque affirmation est vérifiée à la source.

Publié le 5 septembre 2026 · Mis à jour le 6 septembre 2026

Quels sont les quatre apports distincts de l'on-premise ?

Ce que l'on-premise apporte tient en quatre points distincts, qu'il vaut mieux examiner un par un puisqu'ils ne reposent pas sur les mêmes garanties :

• vos données ne quittent pas votre infrastructure ;
• personne ne peut retirer le modèle que vous utilisez ;
• vous gardez la main sur la version et sur le réglage ;
• votre facture cesse de dépendre d'un fournisseur.

Les trois premiers se vérifient sur votre propre installation, sans avoir à croire personne sur parole. Le quatrième dépend d'un volume, et c'est le seul qui demande un calcul.

La confidentialité, le point qui ne dépend de rien d'autre

La confidentialité est le point le plus solide de l'analyse, parce qu'il ne dépend ni d'une licence, ni d'un volume, ni de la bonne foi d'un tiers. Quand le modèle s'exécute sur votre matériel, les requêtes ne sortent pas de votre réseau, et cela se constate en observant le trafic sortant.

La différence avec une garantie contractuelle est de nature, pas de degré. Une clause de non-conservation engage la responsabilité d'un fournisseur ; une architecture locale supprime la question, puisqu'il n'y a rien à conserver ailleurs. C'est ce qui rend l'approche recevable pour un dossier médical, un secret d'affaires ou une pièce couverte par le secret professionnel.

Elle simplifie aussi le registre des traitements : sans transfert hors de l'Union européenne, les articles 44 à 49 du RGPD n'ont plus à être documentés pour ce traitement, et la question du sous-traitant ne se pose pas.

La permanence : personne ne peut retirer le modèle

La permanence est la deuxième garantie que l'on-premise apporte seul. Un modèle téléchargé reste utilisable si son éditeur le retire du catalogue, modifie ses conditions, change de tarif ou disparaît. Les poids sont sur vos disques, et ils y restent.

Ce point paraît théorique jusqu'au jour où il ne l'est plus. C'est l'argument qui pèse dans les secteurs régulés, où une application validée doit continuer de rendre le même résultat plusieurs années durant, et nous l'avons développé dans notre article sur le kill switch.

La maîtrise du modèle, concrètement

La maîtrise du modèle est la troisième garantie, et la plus mal comprise, parce qu'on la confond avec la liberté de réentraîner. Ce n'est pas cela : c'est la maîtrise de tout ce qui entoure le modèle et détermine son comportement.

• La version. Vous décidez du jour où vous changez de modèle, et vous pouvez revenir en arrière. Aucune mise à jour ne vous est imposée du jour au lendemain.
• Le format. Vous choisissez la quantification selon votre arbitrage entre qualité, mémoire et débit, et vous pouvez servir deux formats en parallèle.
• Le service. Le moteur d'inférence, la taille des lots, la fenêtre de contexte et le cache clé-valeur sont vos réglages, pas ceux d'un fournisseur.
• L'adaptation. Un réglage fin léger sur vos propres documents reste possible, ce qu'aucune interface au token ne permet.

Un praticien décrit, en mai 2026, la forme concrète que prend cette maîtrise. Sa plateforme locale assemble LiteLLM, Ollama, Qdrant, Redis et Langfuse, et le code applicatif n'y connaît qu'un alias, « coding » ou « reasoning » : changer de modèle revient à modifier une ligne de configuration, sans toucher une seule application, et chaque appel est tracé. C'est l'architecture que ce site décrit dans ses fiches, et elle tient en moins de mille lignes.

Cette maîtrise a une conséquence pratique souvent décisive : le comportement du système est reproductible. À version, format et réglages identiques, la même question donne la même réponse, ce qui rend l'audit possible.

Elle a aussi une portée que l'on sous-estime, et un cas publié le 1^er septembre 2026 la mesure. Contrainte par des exigences de résidence des données, une entreprise a consolidé le trafic de plus de 200 applications internes sur un seul modèle auto-hébergé, adapté à partir de l'analyse des erreurs en production. Le résultat dépasse un modèle de référence sept fois plus gros sur leur arène interne, 69,6 contre 65,8, ainsi qu'en suivi d'instructions et en appel de fonctions, tout en absorbant la moitié du trafic de la plateforme, soit 116 millions de requêtes par mois, pour une fraction du coût de service. Un tel réglage sur son propre trafic n'est possible que si l'on tient le modèle.

Comment l'affinage, le harnais et la mémoire d'entreprise font-ils progresser le modèle ?

Détenir les poids ouvre trois leviers qu'une API fermée ne donne pas : affiner le modèle sur votre activité avec QLoRA sur une seule carte, choisir le harnais qui l'entoure, et lui construire une mémoire d'entreprise. Les mesures publiées montrent que chacun de ces leviers pèse autant que le choix du modèle.

Affiner sur son activité, sur une seule carte

La méthode QLoRA, publiée en mai 2023, affine un modèle de 65 milliards de paramètres sur un seul GPU de 48 Go en conservant la performance d'un affinage complet en 16 bits (arXiv:2305.14314). Le modèle Guanaco qui en résulte atteint 99,3 % du niveau de ChatGPT sur le banc Vicuna après 24 heures sur une seule carte, avec une réserve que les auteurs formulent eux-mêmes : les bancs de dialogue de l'époque ne sont pas fiables pour comparer des assistants. Trois années plus tard, les résultats métier sont plus parlants :

• Radiologie : l'affinage LoRA de Qwen2.5-3B et Qwen3-4B sur 162 000 exemples et neuf tâches améliore l'exactitude de 53 % à 89 % selon la tâche par rapport au modèle sans affinage, et les modèles tiennent ensuite en 1,8 à 2,4 Go sur un processeur ordinaire (arXiv:2605.00421).
• Vérification d'affirmations biomédicales : Mistral-7B affiné en QLoRA sur 1 008 exemples seulement dépasse GPT-4o et GPT-5, jusqu'à 12 points de F1, à une fraction du coût ; l'auteur signale lui-même un artefact du jeu de données qui gonfle les scores en domaine (arXiv:2606.12854).
• Contre-exemple utile : sur un système de questions juridiques en ouzbek, l'affinage QLoRA du générateur donne un résultat négatif, et les auteurs recommandent d'affiner le modèle d'embedding plutôt que le modèle de langue (arXiv:2608.29284). L'affinage se mesure, il ne se présume pas.

Ce qui plaide pour l'on-premise ici est simple : les poids affinés contiennent votre savoir-faire, et ils restent sur vos disques. Un modèle derrière une API fermée ne se ré-entraîne pas chez vous. L'étude sur une seule carte en périphérie, déjà citée (arXiv:2607.02523), montre que le cycle complet, données, affinage, service, tient dans le périmètre.

Le harnais pèse autant que les poids

Une étude d'août 2026 compare deux configurations du même harnais d'agent de code, à poids identiques, sur 169 tâches de SWE-bench Verified en fenêtre de 20 480 tokens : le taux de tests passés par tâche monte de 28 % à 49 %, et les solutions complètes de 43 à 72 (arXiv:2608.26218). Les auteurs concluent que modèle et harnais doivent être évalués ensemble, et précisent que l'écart se resserre en fenêtre large : le harnais compte surtout sous contrainte de contexte. Deux autres mesures vont dans le même sens :

• ARC-AGI-2 : le raffinement publié par Poetiq fait passer Gemini 3 Pro de 31 % à 0,81 $ par tâche à 54 % pour environ 31 $ par tâche, sans changer le modèle ; ARC Prize note que ces harnais de raffinement restent spécifiques à un domaine (ARC Prize 2025, analyse des résultats).
• SWE-bench Verified : coupler planification et mémoire épisodique dans l'agent résout en moyenne 25 cas de plus, soit 5,0 points, qu'une base à harnais égal, et réduit les actions répétées en échec et l'épuisement de la fenêtre de contexte (arXiv:2608.06811).

Le banc DeepSWE cité plus haut fixe d'ailleurs le harnais pour tous les modèles, précisément parce qu'il change le résultat. En local, ce harnais est à vous : la boucle d'exécution, les outils exposés, les règles d'approbation et la gestion du contexte se règlent sur place, comme le décrit notre fiche harnais d'agent.

Une mémoire d'entreprise autour du modèle

Le banc LongMemEval mesure une chute de 30 % de l'exactitude des assistants commerciaux et des modèles à long contexte quand il faut retenir une information sur des interactions prolongées (arXiv:2410.10813). Une couche de mémoire corrige cela, et les mesures publiées donnent l'ordre de grandeur :

• Mémoire d'agent : sur le banc LOCOMO, Mem0 gagne 26 % en relatif au jugement par modèle par rapport à la mémoire d'OpenAI, avec une latence p95 réduite de 91 % et plus de 90 % de tokens économisés par rapport au contexte complet ; c'est un papier d'éditeur, à lire comme tel (arXiv:2504.19413).
• La recherche compte plus que la structure : une simple recherche lexicale pilotée par l'agent sur les journaux bruts atteint 58,2 de moyenne sur MemoryAgentBench, devant HippoRAG 2 à 53,2, à modèle égal (arXiv:2608.12888). Indexer vos propres journaux, sur place, est le premier pas.
• Retour de praticien : « en RAG simple, une mauvaise récupération abîme un tour ; en mémoire apprise à l'exécution, une mauvaise écriture change beaucoup de tours futurs », et la mémoire est « d'abord un gain d'économie et de continuité » (M. Lanham, Medium, avril 2026). Ses chiffres de seconde main ne sont pas repris ici.

Cette mémoire, base vectorielle, graphe de relations, wiki de faits, est la partie la plus spécifique à l'entreprise de toute la plateforme, et donc celle qui a le moins de raisons de sortir. Notre fiche mémoire à trois couches détaille une mise en œuvre où l'embedder et le reranker s'exécutent sur le GPU local.

Ces quatre chiffres viennent de quatre bancs différents et ne s'additionnent pas ; ils disent seulement que chaque levier, pris seul, déplace le résultat de manière mesurable.

Premier point de vigilance : lire la licence

Le premier point à vérifier est la licence, car le terme « open source » recouvre des réalités assez différentes selon les éditeurs. En interrogeant l'API de Hugging Face le 5 septembre 2026 sur neuf modèles à poids ouverts parmi les plus téléchargés, quatre portent une licence libre reconnue et cinq une licence rédigée par leur éditeur.

La bonne nouvelle est que le choix ne manque pas : Apache 2.0 et MIT couvrent quatre des neuf modèles du tableau, dont les plus téléchargés, et ces deux licences autorisent l'usage commercial sans condition particulière. Il suffit de vérifier avant de s'engager, comme pour n'importe quelle dépendance logicielle.

Les licences maison ne sont pas pour autant fermées, elles posent des conditions qu'il faut connaître. La Mistral Research License demande une autorisation pour tout usage non expressément prévu. La licence Llama 4 s'applique librement en dessous de 700 millions d'utilisateurs actifs mensuels, seuil qu'une entreprise française atteint rarement, et demande d'afficher la mention « Built with Llama ». Google publie ses propres conditions pour Gemma.

Ce qu'exige la définition de référence

La définition de référence mérite d'être connue pour employer les bons mots. L'Open Source Initiative, sous le nom OSAID 1.0, demande trois composants : les paramètres, le code d'entraînement et d'exécution, et une information sur les données permettant de reconstruire un système équivalent.

Publier les poids satisfait le premier de ces trois composants. C'est pourquoi le terme exact est « poids ouverts », et c'est celui que ce site emploie. Cela ne retire rien aux garanties décrites plus haut, qui tiennent aux poids eux-mêmes et non à la publication du code d'entraînement.

Second point de vigilance : le coût change de nature

Le second point à vérifier est le coût, qui ne disparaît pas mais change de nature. Le local remplace une dépense proportionnelle à l'usage par une dépense fixe, ce qui devient un avantage à partir d'un certain volume et le reste ensuite.

Les hypothèses publiées sur ce site donnent l'ordre de grandeur, reprises à l'identique de nos autres articles : un poste DGX Spark à 4 875 € hors taxes, une station DGX à 95 000 € hors taxes, une électricité à 0,1624 €/kWh hors taxes au tarif professionnel.

Le seuil que nous publions se situe autour de 55 utilisateurs agentiques, ou 309 utilisateurs occasionnels, au tarif heures pleines de DeepSeek V4 Flash. Au-delà, l'écart se creuse en faveur du local, et il devient prévisible puisque le matériel est amorti. Le calcul complet figure dans notre article sur site ou API.

Ce raisonnement par seuil n'est pas propre à ce site. Une analyse coût-bénéfice publiée sur arXiv en août 2025 construit le même cadre, en confrontant le coût total d'un déploiement local de modèles ouverts aux abonnements des grands fournisseurs, et conclut à un point d'équilibre qui dépend du niveau d'usage et des besoins de performance. Nos chiffres sont les nôtres ; la méthode, elle, fait consensus.

Reste un poste que les comparatifs oublient et qu'il vaut mieux prévoir : le temps d'ingénierie. Un modèle local se met à jour, se surveille et se redimensionne. C'est le prix de la maîtrise, et il se réduit nettement quand la plateforme est industrialisée dès le départ.

Ce que valent les modèles ouverts, mesuré

Ce que valent les modèles ouverts se mesure désormais sur des bancs d'essai sans contamination, et le résultat est net : ils occupent les premières places. Le banc DeepSWE de Datacurve évalue 113 tâches d'ingénierie logicielle originales, réparties sur 91 dépôts et cinq langages, avec des vérificateurs écrits à la main.

Deux enseignements en sortent. D'abord, des modèles que vous pouvez télécharger et exécuter chez vous se classent sixième et septième d'un banc conçu pour départager les agents de code de premier plan. L'écart avec les modèles fermés s'est refermé au point de ne plus commander le choix.

Ensuite, le rapport entre résultat et coût penche franchement du côté ouvert. GLM 5.3 Flash obtient 63 % pour 0,24 $ par tâche, soit seize fois moins que GLM 5.3 pour six points de moins. C'est exactement le profil qu'on cherche pour un usage interne à fort volume.

Sur quelle machine concrètement faire tourner ces modèles ?

Sur quelle machine faire tourner ces modèles se décide couple par couple, et le site publie une page par modèle et par matériel plutôt qu'une estimation générale.

Un exemple donne l'ordre de grandeur : GLM, avec ses 744 milliards de paramètres, occupe environ 428 Go en NVFP4, ce qui tient sur les 748 Go d'une DGX Station comme sur les 768 Go d'un serveur RTX PRO 6000, mais pas dans un format plus précis.

Ce tableau est un calcul, pas une mesure : il confronte le poids publié de chaque modèle à la mémoire de chaque machine, « tient juste » signifiant que la marge restante se consomme vite dès que le contexte s'allonge. Chaque case renvoie à une page de dimensionnement qui détaille la marge et les formats possibles, et notre calculateur de mémoire ajoute le cache clé-valeur selon votre contexte et votre concurrence.

Les modèles compacts changent l'échelle du problème. Un banc énergétique publié en juin 2026 mesure neuf modèles ouverts de 1 à 7 milliards de paramètres sur une simple carte grand public, une RTX 4060 Ti de 16 Go, en relevant la puissance par nvidia-smi à 2 Hz. Les plus sobres consomment 0,56 et 0,65 joule par token produit, et les auteurs constatent que l'architecture et la quantification pèsent davantage que le nombre de paramètres.

Un second travail, publié en août 2026, évalue trois modèles ouverts de moins de cinq milliards de paramètres en local sur du raisonnement mathématique, avec protocole fixe, mesure des ressources par question et tests statistiques appariés. Un troisième, en mai 2026, montre le réglage fin d'un modèle sur une seule carte de classe périphérique, pour du dépannage de réseau télécom où la souveraineté des données et la latence sont des exigences opérationnelles, avec l'étude des compromis de rang LoRA, de longueur de séquence et de cache clé-valeur. La littérature documente donc ce que le local rend possible, et pas seulement ce qu'il coûte.

Pour choisir votre couple modèle et machine, notre section dimensionnement confronte chaque modèle à chaque matériel, mémoire occupée et marge comprises.

L'hybride : comment router sans choisir entre local et API ?

Le débat « local ou API » suppose un choix binaire qui n'a pas lieu d'être, car une architecture hybride laisse les deux coexister. Un routeur sémantique classe chaque requête avant tout appel de modèle, puis l'oriente vers le modèle local ou vers un modèle externe selon ce qu'elle contient.

La classification ne repose pas sur des mots-clés mais sur la similarité d'embeddings, donc sur le sens du texte. Une demande qui touche un dossier client, un contrat ou une donnée de santé part vers le modèle souverain ; une reformulation générique ou une traduction de documentation publique peut aller vers une interface au token, moins chère à faible volume.

Cette bascule change la nature de l'arbitrage exposé plus haut. Vous n'avez plus à atteindre le seuil de 55 utilisateurs pour justifier le local, puisque le local ne traite que ce qui l'exige. Et vous n'exposez plus la donnée sensible pour bénéficier du prix d'une API, puisque le tri se fait avant l'appel.

Trois conditions rendent le dispositif tenable. Le routeur doit être placé en amont de la passerelle, pas après, sinon la requête a déjà quitté le périmètre. Sa décision doit être journalisée, faute de quoi elle n'est pas auditable. Et le comportement par défaut doit être le local, pour qu'une classification incertaine échoue du bon côté.

Un praticien a mesuré, en juillet 2026, ce qui arrive quand on ne route pas. Il a rejoué 27 tâches réelles de son assistant personnel, un agent doté d'environ 90 outils, sur qwen3-coder:30b servi par une RTX 3090, contre les réponses historiques de Claude sur les mêmes tâches. Le coût, mesuré sur la consommation électrique réelle de la carte, tombe à 0,00015 $ par tâche contre 0,763 $, soit un rapport de 5 150. Mais la qualité jugée tombe aussi, de 89,4 à 22,8 sur 100, et le même modèle, qui avait réussi 100 % d'un banc de 17 tâches cadrées, se dégrade nettement dans un environnement à 90 outils. Sa conclusion rejoint la nôtre : ne pas demander au modèle local de tout faire, mais lui confier les tranches où il est proche, en gardant le modèle de tête là où la surface d'outils compte. C'est exactement ce qu'un routeur décide, requête par requête.

Notre fiche routeur sémantique détaille la classification par embeddings, la prévention de fuite et le placement en amont de LiteLLM.

Comment décider, concrètement

Décider revient à répondre à quatre questions dans l'ordre, et la première tranche à elle seule la plupart des cas, ce qui évite de comparer des coûts pour rien :

1. Vos données interdisent-elles la sortie du périmètre ? Si oui, le débat est clos : l'on-premise s'impose quel que soit le coût.
2. Votre volume dépasse-t-il le seuil d'amortissement, autour de 55 utilisateurs agentiques ? Si oui, l'on-premise est rentable en plus d'être maîtrisé. Comparez au seuil, pas à votre effectif total.
3. Vos flux mélangent-ils du sensible et du générique ? Si non, tout est générique et sous le seuil : une API au token convient, avec bascule vers le local dès que la sensibilité ou le volume monte.
4. Avez-vous le temps d'ingénierie pour deux chemins et un routeur ? Si oui, l'hybride avec routeur sémantique prend le meilleur des deux. Sinon, séparez à la main dans l'application : le sensible en local, le générique en API, et le routeur viendra ensuite.

Quel que soit le chemin, lisez la licence du modèle retenu, ou les conditions de l'API, pour votre usage précis, commercial compris : c'est un choix de modèle, pas un choix d'hébergement, et il se fait après.

Pour le choix du modèle, notre comparatif des LLM open source détaille tailles, empreintes mémoire et usages. Pour la mise en œuvre, voyez installer un LLM local en entreprise. Pour le matériel, notre guide des prix d'un serveur IA.

Pour aller plus loin sur le blog

Cet article traite l'arbitrage ; les autres articles du blog traitent chacun une étape, et se lisent dans cet ordre selon l'endroit où vous en êtes :

• Quel modèle open source choisir : tailles, empreintes mémoire, licences et usages.
• Quel serveur pour l'IA, et à quel prix : fourchettes par gamme, du poste au rack.
• Sur site ou API : le calcul du seuil, ses hypothèses et ses réserves de capacité.
• Comparateur de coût API au token ou serveur sur site : le même calcul, avec vos propres effectifs, tarifs et machine.
• Calculateur de mémoire : poids, cache clé-valeur et contexte maximal sur les huit machines, avec vos propres valeurs.
• Installer un LLM local en entreprise : modèle, matériel, runtime, passerelle, sécurité.
• Prefill, decode et cache clé-valeur : ce qui fixe vraiment le matériel nécessaire.
• RAG en entreprise : brancher le modèle sur vos documents sans les exposer.
• IA générative et RGPD : ce que recommande la CNIL et le risque extraterritorial.
• Kill switch et LLM local : pourquoi la permanence est un argument de conformité.

Sources

Licences déclarées : API Hugging Face, relevées le 5 septembre 2026. Définition : Open Source AI Definition 1.0, Open Source Initiative. Texte de la licence Mistral : Mistral AI Research License. Texte de la licence Llama 4 : dépôt meta-llama. Banc de code : DeepSWE, Datacurve, classement relevé le 6 septembre 2026. Énergie en local : arXiv:2608.00008. Modèles compacts en local : arXiv:2608.22048. Modèle auto-hébergé sur trafic de production : arXiv:2609.01572. Réglage fin sur une seule carte : arXiv:2607.02523. Cadre coût-bénéfice : arXiv:2509.18101. Témoignages de praticiens, cités comme tels : A. Apostolov, Medium, juillet 2026 ; A. Mahajan, Medium, mai 2026. Affinage QLoRA : arXiv:2305.14314, arXiv:2605.00421, arXiv:2606.12854, résultat négatif arXiv:2608.29284. Effet du harnais : arXiv:2608.26218, arXiv:2608.06811, ARC Prize 2025. Mémoire : arXiv:2410.10813, arXiv:2504.19413 (papier d'éditeur), arXiv:2608.12888 ; M. Lanham, Medium, avril 2026, cité pour son analyse seulement. Hypothèses de coût : identiques à celles de nos autres articles, détaillées dans le guide des prix.