Guides

IA locale en 2026 : modèles, matériel, confidentialité et déploiement

Comprendre et déployer une IA locale en 2026 : choix du modèle, matériel, quantification, confidentialité, coûts, tests, sécurité et architecture hybride.

Promptique13 août 202620 min de lecture

Une IA locale exécute un modèle directement sur un ordinateur, un serveur privé ou un appareil mobile, sans envoyer chaque requête à une API distante. En 2026, cette approche n’est plus réservée aux laboratoires : des modèles ouverts plus compacts, la quantification et des outils comme Ollama ou llama.cpp permettent de construire des assistants utiles sur du matériel accessible. Elle ne garantit pourtant ni la confidentialité, ni la qualité, ni l’économie. Ces bénéfices dépendent de l’architecture, du modèle, des réglages et de l’exploitation.

Ce guide explique comment décider, dimensionner et déployer une IA locale de façon professionnelle. L’objectif n’est pas de désigner un modèle « meilleur » pour tout le monde, mais de donner une méthode durable : partir du besoin, mesurer les contraintes, tester plusieurs candidats et sécuriser tout le cycle de vie.

Vérifié le 13 août 2026 : les caractéristiques logicielles et les familles de modèles évoluent vite. Les principes d’architecture restent valables, mais les compatibilités, licences et performances doivent être vérifiées avant chaque déploiement.

L’essentiel en 60 secondes

Local décrit le lieu d’exécution, pas automatiquement le lieu de stockage de toutes les données ni l’absence de services externes.
Les gains principaux sont le contrôle des données, la disponibilité hors ligne, une latence prévisible et l’absence de facturation API variable par token.
Les contreparties sont le matériel, l’administration, la sécurité, les mises à jour et une qualité parfois inférieure à celle des meilleurs services cloud.
La mémoire disponible est le premier filtre : poids du modèle, cache de contexte et concurrence des utilisateurs doivent tenir ensemble.
La quantification réduit la mémoire et peut accélérer l’inférence, au prix d’une perte de qualité variable.
Un pilote sérieux compare qualité, latence, débit, consommation de mémoire, sécurité et coût total sur des cas réels.
Le modèle local peut être combiné avec un RAG, des outils ou un modèle cloud dans une architecture hybride.

Qu’est-ce qu’une IA locale ?

Une IA locale est un système dont l’inférence s’exécute sur une infrastructure contrôlée par l’utilisateur : ordinateur portable, poste de travail, téléphone, serveur interne ou cloud privé. Le fichier de poids du modèle est chargé dans la mémoire, le texte est transformé en tokens, puis le processeur, le GPU ou l’accélérateur produit la réponse token après token.

Le terme recouvre plusieurs réalités. Une application peut être totalement hors ligne, fonctionner sur le réseau interne, ou exécuter le modèle localement tout en utilisant une recherche web, une télémétrie ou une authentification distante. Il faut donc cartographier chaque flux au lieu de déduire la confidentialité du seul mot « local ».

Mode	Exécution	Données	Usage typique
Sur l’appareil	PC, mobile ou poste métier	Restent sur l’appareil si aucune fonction externe n’est appelée	Résumé, extraction, aide à la rédaction
Serveur interne	Machine partagée sur le réseau privé	Centralisées sous le contrôle de l’organisation	Assistant documentaire, support interne
Cloud privé	Infrastructure dédiée ou isolée	Soumises au contrat et à la configuration du cloud	Montée en charge et haute disponibilité
Hybride	Local pour certains cas, API pour d’autres	Routées selon leur sensibilité et la tâche	Compromis qualité, coût et confidentialité

Le lieu d’inférence ne suffit pas : journalisation, extensions et sauvegardes doivent aussi être examinées.

Modèle ouvert ne signifie pas toujours open source

De nombreux modèles sont distribués avec leurs poids, mais sous des licences qui ne correspondent pas nécessairement aux critères classiques du logiciel libre. Certaines autorisent largement l’usage commercial, d’autres ajoutent des conditions, des seuils ou des restrictions. Avant de choisir un modèle, vérifiez la licence de la version précise, la possibilité de créer des dérivés et les obligations de redistribution.

Quand faut-il choisir une IA locale ?

Le local devient pertinent lorsqu’une contrainte mesurable domine : données sensibles, fonctionnement hors connexion, volume régulier, intégration avec un système fermé ou besoin de maîtriser les versions. Il est moins pertinent lorsque l’équipe souhaite simplement accéder ponctuellement au meilleur modèle disponible sans administrer d’infrastructure.

Comparaison entre IA locale et API cloud
Critère	Local	API cloud
Contrôle technique	Élevé, avec responsabilité d’exploitation	Partagé avec le fournisseur
Démarrage	Installation et tests nécessaires	Rapide avec une clé API
Qualité maximale	Dépend du matériel et des modèles disponibles	Accès simple aux modèles les plus puissants
Coût	Investissement et coût fixe	Coût variable selon l’usage
Hors ligne	Possible	Généralement impossible
Mises à jour	À planifier et valider	Gérées par le fournisseur, parfois imposées
Données	Flux contrôlables de bout en bout	Dépend du contrat et de la région de traitement

Six signaux favorables au local

Les documents ne doivent pas quitter une zone maîtrisée.
Le service doit fonctionner sans Internet ou avec une connexion instable.
La charge est assez régulière pour amortir le matériel.
La tâche est étroite et un modèle compact atteint la qualité attendue.
La latence réseau est incompatible avec le processus.
L’organisation doit figer une version et reproduire les résultats.

Quatre signaux favorables au cloud

Le volume est faible ou très irrégulier.
La tâche exige les capacités de pointe d’un grand modèle.
L’équipe ne dispose pas de compétences d’exploitation.
Le produit doit monter en charge immédiatement dans plusieurs régions.

La décision peut également être prise tâche par tâche. Le comparatif des assistants IA aide à comprendre ce que proposent les services hébergés. Le local ne les remplace pas toujours : il élargit les options d’architecture.

Comment fonctionne une pile d’IA locale ?

Une solution fiable ne se résume pas au modèle. Elle combine plusieurs couches dont chacune peut limiter les performances ou introduire un risque.

Interface : chat, application métier, extension ou API.
Orchestrateur : prépare les messages, appelle les outils et applique les règles.
Moteur d’inférence : charge les poids, gère le contexte et produit les tokens.
Modèle : architecture, poids, tokenizer, format et quantification.
Données : documents, base vectorielle, historique et journaux.
Infrastructure : CPU, GPU, mémoire, stockage, réseau et supervision.

Pour connecter le système à des documents internes, on ajoute généralement une chaîne RAG : extraction, découpage, embeddings, index, recherche et insertion des passages dans le contexte. Cette méthode ne change pas les poids. Elle complète le modèle avec une information retrouvée au moment de la requête. Elle doit être évaluée séparément, car une mauvaise recherche produit une réponse mal fondée même si le modèle est compétent.

Pour déclencher des actions, le système expose des outils avec des schémas stricts et des permissions limitées. Le guide Agents IA et MCP détaille cette couche. Une exécution locale ne rend pas un agent inoffensif : un outil capable de modifier un fichier ou une base doit rester soumis à authentification, validation et journalisation.

Comment dimensionner le matériel ?

La mémoire est le premier ordre de grandeur. Un modèle dense de P paramètres stocké à b bits nécessite approximativement P × b / 8 octets pour ses poids, auxquels s’ajoutent les métadonnées, le cache KV, les buffers et le moteur. Un modèle de 8 milliards de paramètres en 4 bits représente donc environ 4 Go de poids théoriques, mais il faut prévoir davantage pour l’exécuter réellement.

Taille dense	Poids théoriques en 4 bits	Marge pratique indicative	Positionnement
3 à 4B	1,5 à 2 Go	4 à 8 Go disponibles	Mobile, bureautique ciblée, extraction
7 à 9B	3,5 à 4,5 Go	8 à 16 Go disponibles	Assistant général compact
12 à 14B	6 à 7 Go	12 à 24 Go disponibles	Qualité supérieure sur poste puissant
27 à 32B	13,5 à 16 Go	24 à 48 Go disponibles	Station de travail ou serveur
70B et plus	35 Go et plus	48 à 96 Go ou davantage	Serveur spécialisé, parfois multi-GPU

Ordres de grandeur pour des modèles denses. Le contexte, l’architecture MoE et le moteur modifient fortement la mémoire réelle.

CPU, GPU et mémoire unifiée

Le CPU suffit pour des tests, de petits modèles ou une charge peu sensible à la latence. Le GPU accélère le calcul grâce à sa bande passante mémoire, mais sa VRAM limite la taille chargée. Les machines à mémoire unifiée permettent au CPU et au GPU de partager un même espace, ce qui simplifie certains déploiements. La capacité seule ne garantit cependant pas le débit : architecture, bande passante, backend et format comptent.

Le contexte consomme aussi de la mémoire

Le cache KV conserve des informations liées aux tokens déjà traités. Sa taille augmente avec la longueur de contexte, le nombre de sessions parallèles, l’architecture et la précision utilisée. Afficher « 128 000 tokens pris en charge » ne signifie donc pas que cette longueur sera rapide ou économique sur votre machine. Mesurez la longueur réellement nécessaire et limitez-la par défaut.

Comment choisir le bon modèle local ?

Commencez par un cahier de tests, pas par un classement général. Un petit modèle spécialisé peut dépasser un modèle plus gros sur une extraction structurée, tout en étant moins bon en rédaction longue. Constituez 30 à 100 cas représentatifs avec entrées, attentes et critères avant de télécharger plusieurs dizaines de gigaoctets.

Modalité : texte seul, image, audio ou combinaison.
Langues : qualité réelle en français et vocabulaire métier.
Taille : compatibilité avec la mémoire et le débit attendu.
Contexte : longueur utile, pas maximum marketing.
Sortie structurée : respect d’un schéma JSON ou d’une grammaire.
Outils : capacité et fiabilité des appels de fonctions.
Licence : usage commercial, redistribution et dérivés.
Traçabilité : carte du modèle, provenance et version.

Google présente par exemple sa famille Gemma comme une gamme de modèles ouverts de tailles et de modalités différentes, destinés à des appareils allant du mobile au serveur. Cette diversité illustre un principe important : choisir la plus petite variante qui atteint le niveau attendu, puis monter en taille uniquement si les tests l’exigent.

Que change la quantification ?

La quantification représente les poids avec moins de bits. Elle réduit la mémoire et peut accélérer l’inférence, mais introduit une approximation. La perte varie selon le modèle, la méthode, le niveau et la tâche. Une version 4 bits peut rester excellente pour un résumé et perdre davantage sur du raisonnement numérique ou une langue moins représentée.

Comparez au minimum une version de référence et une ou deux quantifications sur votre jeu de tests. Ne déduisez pas la qualité du seul nom Q4, Q5 ou Q8 : les formats comportent plusieurs variantes et les résultats dépendent du moteur.

Ollama, llama.cpp ou framework Python : que choisir ?

Comparaison des moteurs et frameworks d’inférence locale
Solution	Force	Limite	Bon usage
Ollama	Installation, catalogue, API et gestion simplifiées	Une abstraction de plus à configurer et sécuriser	Pilote, poste local, service interne simple
llama.cpp	Contrôle fin, GGUF, nombreux backends, serveur compatible API	Réglages techniques plus nombreux	Optimisation, intégration embarquée, infrastructure maîtrisée
Transformers	Écosystème Python, modèles et quantifications variés	Dépendances et exploitation plus complexes	Recherche, personnalisation, pipeline sur mesure
Framework natif appareil	Intégration OS, faible latence, expérience hors ligne	Compatibilité matérielle et API spécifiques	Application mobile ou desktop ciblée

Ollama indique que les requêtes et réponses restent invisibles pour son service lors d’une exécution locale, et propose un mode désactivant ses fonctions cloud. llama.cpp fournit un serveur HTTP compatible avec l’API OpenAI, des backends CPU et GPU, la contrainte par grammaire, les embeddings et le reranking. Apple expose de son côté un framework donnant accès à un modèle embarqué pour la compréhension du langage, les sorties structurées et les appels d’outils sur les appareils compatibles.

Attention : une API locale écoutant sur toutes les interfaces réseau sans authentification transforme rapidement un avantage de confidentialité en faille. Limitez l’écoute, ajoutez un proxy authentifié et filtrez les origines.

Déployer une IA locale pas à pas

1. Définir une tâche et une cible

Écrivez une phrase testable : « extraire six champs de 500 factures françaises par jour avec 98 % de champs exacts et moins de cinq secondes par document ». Évitez « installer un chatbot interne », qui ne définit ni valeur ni seuil.

2. Classer les données

Identifiez données publiques, internes, confidentielles, personnelles et sensibles. Définissez les personnes autorisées, la durée des journaux et les sorties interdites. Pour un déploiement en entreprise, le guide IA générative, RGPD et AI Act fournit le cadre de gouvernance complémentaire.

3. Établir le jeu de tests

Incluez cas courants, cas limites, entrées malveillantes, documents incomplets et refus attendus. La méthode décrite dans Évaluer un prompt s’applique aussi à la comparaison des modèles.

4. Installer le moteur sur une machine isolée

Téléchargez depuis le site ou le dépôt officiel, vérifiez la signature ou la somme de contrôle lorsqu’elle existe, puis commencez avec une écoute limitée à l’hôte local. Notez la version du moteur, des pilotes et du modèle.

5. Tester le plus petit modèle plausible

Mesurez la qualité avant d’augmenter la taille. Testez ensuite une quantification différente, puis un modèle plus grand. Cette progression distingue les limites du prompt, du modèle et du matériel.

6. Encadrer les sorties

Pour une intégration métier, imposez un schéma ou une grammaire lorsque le moteur le permet. Validez toujours côté application : types, longueurs, valeurs autorisées et permissions. Un JSON syntaxiquement valide peut contenir une décision fausse.

7. Ajouter les documents ou outils progressivement

Commencez en lecture seule. Pour un RAG, exigez des citations vers les passages. Pour les outils, utilisez une liste blanche et une confirmation humaine avant les actions sensibles. La complexité doit être introduite après une base mesurée.

8. Organiser l’exploitation

Prévoyez supervision, quotas, sauvegarde des configurations, rotation des journaux, procédure de retour arrière et calendrier de correctifs. Une carte de service doit indiquer modèle, licence, version, propriétaire, données autorisées et tests réussis.

IA locale et confidentialité : quels contrôles appliquer ?

Le local réduit certains transferts, mais concentre des actifs sensibles : poids, index vectoriel, documents, historique et clés d’outils. Les risques principaux sont l’accès non autorisé, l’exposition de l’API, l’injection de prompt dans les documents, la fuite par les journaux et la chaîne d’approvisionnement logicielle.

Chiffrez les disques et les sauvegardes.
Segmentez le serveur et limitez les ports.
Authentifiez chaque client et appliquez le moindre privilège.
Désactivez la télémétrie et les fonctions cloud non nécessaires.
Évitez de journaliser les prompts bruts par défaut.
Analysez les modèles et dépendances avant déploiement.
Conservez une nomenclature des composants et des versions.
Testez l’injection, l’exfiltration et les abus d’outils.
Supprimez les données selon une durée définie.

La CNIL souligne que l’ouverture des modèles soulève aussi des questions de confidentialité des données d’apprentissage et de droits des personnes. Détenir les poids localement ne prouve donc pas qu’ils sont exempts de données mémorisées ni que leur usage est conforme. Étudiez la carte du modèle, son origine et son processus d’entraînement.

Attention aux hallucinations

Un modèle local reste un générateur probabiliste. Il peut inventer une source, une valeur ou une procédure avec assurance. L’article Hallucinations des IA génératives explique les mécanismes et les parades. Dans un processus à enjeu, une règle de validation et une source vérifiable doivent primer sur la fluidité du texte.

Comment évaluer un modèle local ?

Une démonstration convaincante n’est pas une évaluation. Mesurez au minimum cinq dimensions et conservez les entrées, paramètres, versions et sorties pour reproduire le test.

Dimensions à mesurer lors de l’évaluation locale
Dimension	Mesure possible	Question
Exactitude	Score par champ, réponse attendue, revue aveugle	La sortie est-elle correcte ?
Fidélité	Proportion d’affirmations soutenues par les sources	La réponse reste-t-elle fondée ?
Format	Taux de JSON valide et conforme au schéma	L’application peut-elle exploiter la sortie ?
Performance	Temps au premier token, tokens par seconde, p95	L’expérience est-elle acceptable ?
Robustesse	Cas limites, attaques, variations de formulation	Le système résiste-t-il hors scénario idéal ?
Coût	Énergie, matériel, temps d’exploitation	Le gain justifie-t-il la solution ?

Comparez plusieurs configurations avec la même température, la même limite de sortie et le même jeu de tests. Ajoutez une référence humaine ou cloud lorsque cela est licite. Pour la rédaction, utilisez une grille : exactitude, complétude, style, citations, sécurité et temps de correction.

Combien coûte réellement une IA locale ?

L’absence de facture par token ne signifie pas gratuité. Le coût total comprend matériel, électricité, stockage, temps d’installation, supervision, correctifs, indisponibilité et renouvellement. Il faut le comparer au coût cloud pour un volume et un niveau de service identiques.

Exemple simplifié : une station à 3 000 € amortie sur trois ans représente 83 € par mois avant énergie. Ajoutez 20 € d’électricité, 150 € de temps d’exploitation et 40 € de sauvegarde : environ 293 € mensuels. Si l’alternative API coûte 120 €, le local n’est pas moins cher, même s’il peut rester préférable pour la confidentialité. À 1 000 € d’API mensuels et charge stable, l’équation change.

Postes de coût d’une solution locale ou cloud
Poste	Local	Cloud
Calcul	Achat ou location du matériel	Tokens, requêtes ou capacité réservée
Exploitation	Interne	Partagée avec le fournisseur
Montée en charge	Capacité à prévoir	Souvent élastique
Évolution du modèle	Migration à organiser	Accès rapide, avec dépendance fournisseur
Risque d’inactivité	Matériel sous-utilisé	Coût souvent proportionnel à l’usage

Pourquoi une architecture hybride est souvent meilleure

Une architecture hybride route chaque requête selon sa sensibilité, sa difficulté et son coût. Un petit modèle local peut classer, anonymiser ou extraire. Un modèle cloud traite uniquement les demandes complexes et non sensibles. Un modèle local plus grand intervient lorsque la connexion est absente.

Route sensible : local uniquement.
Route simple : petit modèle local rapide.
Route complexe : modèle cloud après filtrage.
Route critique : réponse préparée par l’IA puis validation humaine.
Secours : bascule locale lorsque le fournisseur est indisponible.

Le routeur doit être déterministe autant que possible. Classez les données avant l’appel, imposez des règles et journalisez la décision sans enregistrer inutilement le contenu. Évaluez aussi le routeur : une erreur de classification peut envoyer une donnée sensible vers le mauvais environnement.

Quels cas d’usage conviennent au local ?

Assistant documentaire interne

Un serveur indexe procédures, contrats et documentation, puis répond avec citations. Le local permet de limiter les transferts. La qualité dépend davantage de l’extraction, des permissions et de la recherche que de la seule taille du modèle.

Extraction structurée

Factures, comptes rendus ou formulaires peuvent être transformés en JSON validé. C’est un excellent premier projet : métrique claire, volume connu et possibilité de revue humaine pour les cas incertains.

Aide à la rédaction hors ligne

Un modèle compact peut reformuler, résumer et créer des plans sans connexion. La méthode de prompt engineering reste utile : contraintes, exemples et format influencent fortement un petit modèle.

Classification et routage

Le système classe un ticket, détecte une langue, évalue une priorité ou masque des données avant une étape suivante. Un modèle réduit suffit souvent, mais une règle classique peut être plus fiable pour les cas simples. Comparez toujours avec une baseline non générative.

Checklist de mise en production

Le cas d’usage et le seuil de réussite sont écrits.
Les données sont classées et le fondement juridique est documenté.
La licence du modèle précis a été relue.
Le jeu de tests couvre cas normaux, limites et malveillants.
Le modèle tient en mémoire avec la concurrence et le contexte prévus.
La version quantifiée a été comparée à une référence.
L’API n’est pas exposée sans authentification.
Les sorties sont validées côté application.
Les outils utilisent une liste blanche et le moindre privilège.
Les journaux excluent les contenus inutiles.
La supervision mesure latence, erreurs, mémoire et saturation.
Une procédure de mise à jour et de retour arrière existe.
Le coût total est comparé à une solution cloud équivalente.
Un responsable métier et un responsable technique sont identifiés.

FAQ sur l’IA locale

Peut-on utiliser une IA locale sans GPU ?

Oui. De petits modèles quantifiés fonctionnent sur CPU, mais le débit peut être inférieur. Le résultat dépend de la mémoire, de la bande passante, du modèle et du moteur. Testez la latence sur la machine cible.

Combien de RAM faut-il ?

Il faut contenir les poids, le cache de contexte, les buffers et les autres applications. Pour un modèle 7 à 9B quantifié en 4 bits, 8 Go disponibles constituent un plancher fréquent, tandis que 16 Go offrent davantage de marge. Ce n’est pas une garantie de performance.

Une IA locale est-elle totalement privée ?

Seulement si tous les flux le sont. Recherche web, télémétrie, extensions, sauvegardes et journaux peuvent transmettre ou conserver des données. Cartographiez et testez le système complet.

Quel est le meilleur modèle local ?

Il n’existe pas de gagnant universel. Le meilleur est le plus petit modèle qui atteint vos seuils sur vos données, votre langue, votre matériel et votre licence.

Qu’est-ce qu’un fichier GGUF ?

GGUF est un format utilisé par l’écosystème ggml et llama.cpp pour stocker modèles et métadonnées, souvent avec quantification. Il facilite l’exécution sur plusieurs backends, mais la compatibilité dépend de l’architecture et de la version du moteur.

La quantification détruit-elle la qualité ?

Elle peut la réduire, mais l’ampleur varie. Des quantifications modérées restent souvent proches de la référence sur certaines tâches. Il faut mesurer les erreurs métier, pas seulement une moyenne de benchmark.

Faut-il fine-tuner un modèle local ?

Pas au départ. Essayez d’abord prompt, exemples, sortie structurée et RAG. Le fine-tuning devient pertinent pour modifier un comportement stable sur un grand volume de cas, avec un dataset et une évaluation solides.

Peut-on connecter une IA locale à Internet ?

Oui, via un outil de recherche contrôlé. Cela rompt toutefois le caractère entièrement hors ligne et ajoute des risques de contenu non fiable, d’injection et de fuite. Isolez l’outil et filtrez ses entrées et sorties.

Une IA locale est-elle moins chère ?

Pas nécessairement. Elle devient compétitive lorsque le volume est régulier et le matériel bien utilisé. Pour un usage faible, l’API est souvent moins coûteuse. Incluez le temps d’exploitation dans le calcul.

Comment mettre à jour sans casser le service ?

Figez les versions, testez la nouvelle combinaison moteur-modèle sur le jeu de non-régression, déployez progressivement et conservez l’ancienne version pour revenir en arrière.

Ce qu’il faut retenir

L’IA locale est devenue une option crédible pour des assistants privés, des traitements hors ligne et des tâches répétitives. Sa valeur vient moins de l’installation d’un modèle que de la maîtrise de l’ensemble : données, évaluation, matériel, réseau, mises à jour et gouvernance.

Le chemin le plus sûr consiste à commencer petit : une tâche mesurable, un modèle compact, une machine isolée et un jeu de tests. Ajoutez ensuite RAG, outils, utilisateurs et haute disponibilité seulement lorsque chaque couche a démontré sa qualité. Dans beaucoup d’organisations, le meilleur résultat sera hybride : local lorsque le contrôle prime, cloud lorsque la capacité de pointe est décisive.

Sources primaires et documentation officielle

llama.cpp, dépôt officiel : backends, serveur, GGUF, embeddings et grammaires.
Ollama, FAQ officielle : exécution locale, données et mode sans fonctions cloud.
Google AI for Developers, démarrer avec Gemma : choix des tailles, plateformes et personnalisation.
Google AI for Developers, exécuter Gemma : matériel et quantification.
Hugging Face Transformers, concepts de quantification.
Apple Developer, Foundation Models : modèle embarqué, sortie structurée et outils.
CNIL, pratiques open source en intelligence artificielle : bénéfices, risques et données personnelles.

Ce contenu est pédagogique. Une architecture traitant des données personnelles, confidentielles ou réglementées doit être validée avec les responsables sécurité, juridique et protection des données de l’organisation.