Chaque prompt que tu écris dans ChatGPT voyage vers un serveur que tu ne contrôles pas, te coûte de l'argent (directement ou non) et cesse de fonctionner dès que tu n'as plus internet. Pendant des années, c'était la seule façon d'utiliser une IA correcte. Plus maintenant.
En 2026, télécharger un modèle de langage et le faire tourner sur ta propre machine est une affaire de minutes et de quelques gigas de RAM. Ce n'est pas un truc de geeks du terminal : il existe des apps avec interface qui rendent ça aussi simple qu'installer Spotify. Ce guide t'emmène du "je n'y connais rien" au "j'ai un modèle qui me répond hors ligne", en comprenant chaque décision au passage.
Note
"IA en local" ne veut pas dire entraîner ton propre modèle depuis zéro —ça demande des centres de données—. Ça veut dire télécharger un modèle déjà entraîné et l'exécuter (inférence) sur ta machine. C'est ce que fait 99 % des gens qui disent "j'utilise l'IA en local".
Pourquoi exécuter l'IA en local
Il y a trois raisons qui tiennent debout toutes seules, et le reste n'est que nuances.
Confidentialité réelle. Tes prompts et les réponses ne quittent jamais ta machine. Pas de logs sur un serveur étranger, pas de "nous pouvons consulter tes conversations", pas de fuites à cause d'une brèche dans le cloud. Si tu travailles avec des données clients, des brouillons juridiques, des informations médicales ou tout ce que tu ne veux pas confier à un tiers, ça change les règles du jeu.
Coût zéro à l'usage. Tu paies une fois —le matériel que tu as déjà— et ensuite tu génères tout ce que tu veux sans compteur de tokens qui tourne. Si tu fais du volume (classer des milliers de textes, résumer en boucle, prototyper à coups d'essai-erreur), la différence face à une API payante est énorme.
Ça marche hors ligne. Pas d'internet, pas de panne de service, pas de "le modèle est saturé, réessaie plus tard". Dans un avion, dans une zone sans couverture ou le jour où le fournisseur a un incident, ton IA est toujours là.
En échange, tu renonces à quelque chose : le plafond de qualité. On en parlera à la fin, mais voici d'emblée la conclusion honnête : pour la plupart des tâches quotidiennes, un bon modèle local de 2026 te suffit largement.
Le flux, en un coup d'œil
Avant de toucher à quoi que ce soit, mieux vaut avoir la carte mentale. Utiliser l'IA en local, c'est toujours les mêmes quatre décisions enchaînées :
De zéro à un modèle qui tourne en local
Choisir le modèle
Tu choisis un modèle open source selon ton usage (chat général, code, raisonnement) et ton matériel. Pour démarrer, un modèle de 7-8B paramètres est l'équilibre parfait.
Choisir la quantification (GGUF)
Tu décides à quel point compresser le modèle. Le format, c'est GGUF ; le niveau, en général Q4_K_M. Ça détermine la mémoire occupée et la vitesse.
Choisir l'outil
Tu installes le programme qui charge et exécute le modèle : LM Studio ou Jan si tu veux une interface, Ollama si tu veux le terminal et une API. Tous lisent le GGUF.
Exécuter et intégrer
Tu télécharges le modèle depuis l'outil lui-même, tu le charges et tu discutes. Si tu programmes, tu le connectes à tes apps via l'API locale.
Si tu comprends ces quatre étapes, tu comprends 90 % du sujet. Le reste, c'est bien choisir à l'intérieur de chacune.
Configuration matérielle requise (la question que tout le monde pose)
Le doute numéro un, c'est "est-ce que ma machine va tenir ?". La réponse dépend de la taille du modèle et de la quantification, mais il y a des règles pratiques claires.
Ce qui commande, c'est la mémoire : combien de RAM (si tu tournes en CPU) ou de VRAM (si tu as un GPU dédié) tu as de libre pour charger le modèle. À titre de repère, avec une quantification en 4 bits (Q4_K_M) :
- Modèles de 7-8B paramètres → environ 5 Go de fichier, tournent avec 8 Go de RAM/VRAM. C'est le point de départ recommandé.
- Modèles de 13-14B → demandent autour de 16 Go.
- Modèles de 70B → tournent autour de 40 Go ; territoire des machines puissantes ou de plusieurs GPU.
Trois précisions importantes :
- Sans GPU, ça marche aussi. N'importe quel portable moderne fait tourner un 7B en CPU ; ce sera plus lent (quelques mots par seconde) mais ça fonctionne. Avec un GPU dédié de 8 Go et plus, ça vole.
- Le Mac Apple Silicon joue avec un avantage. Les puces M partagent la mémoire entre le CPU et le GPU (mémoire unifiée), donc un Mac avec 16 Go fait tourner des modèles qui, sur PC, exigeraient une carte graphique dédiée. En prime, en 2026, les outils utilisent le moteur MLX natif d'Apple, plus rapide et plus économe.
- Garde de la marge. Le modèle n'est pas le seul à occuper la mémoire : la fenêtre de contexte (le KV cache), le système d'exploitation et le reste des programmes tirent dessus aussi. Règle saine : ne remplis pas la mémoire à 100 %, laisse 10-15 % d'air.
Astuce
Avant de télécharger quoi que ce soit, regarde combien de RAM/VRAM libre tu as. LM Studio te prévient même avec un code couleur si ta machine peut encaisser chaque modèle avant de le télécharger. Commence toujours par un 7-8B Q4_K_M : si ça tourne bien, tu monteras ensuite.
Quantification et GGUF, sans jargon
C'est la pièce qui fait le plus peur et la plus facile à comprendre avec une analogie. Un modèle "original" garde chacun de ses milliards de paramètres avec beaucoup de précision (16 bits). Quantifier, c'est arrondir ces nombres à moins de bits —8, 5 ou 4— pour que le fichier occupe beaucoup moins et aille plus vite. C'est comme passer d'un WAV non compressé à un MP3 de bonne qualité : ça occupe une fraction et, en pratique, tu ne remarques presque pas la différence.
GGUF est simplement le format de fichier standard pour ça en local : un fichier unique qui empaquette les poids, le tokenizeur et les métadonnées. Quand tu chercheras des modèles, tu verras des noms comme modele-7B-Q4_K_M.gguf. Ce suffixe, c'est le niveau de quantification, et voici la seule chose à retenir :
- Q4_K_M → le point d'équilibre. Réduit la taille de ~75 % avec à peine 3-5 % de perte de qualité. Dans le doute, celui-là.
- Q5_K_M / Q6_K → un poil plus gros et meilleurs ; utiles pour le code ou le raisonnement s'il te reste de la mémoire.
- Q8_0 → presque identique à l'original ; seulement si tu es large en RAM/VRAM.
- Q3_K_M / Q2_K → pour quand tu es très juste en mémoire ; la perte se remarque davantage.
Le "K_M" signifie qu'il répartit mieux les bits sur les couches qui comptent le plus pour la qualité. C'est pour ça qu'un Q4_K_M vaut presque toujours mieux qu'un Q4 tout court.
Note
Règle d'or : utilise la quantification la plus haute qui tienne en gardant 10 % de marge. Avec 8-12 Go → Q4_K_M. Avec 12-16 Go → Q5_K_M ou Q6_K. Avec 16-24 Go → Q8_0.
Quel outil choisir (et pour qui)
Tous les outils sérieux lisent le GGUF et utilisent en dessous le même moteur (llama.cpp ou, sur Mac, MLX), donc la vitesse entre eux est quasi identique. Tu choisis selon l'interface et selon ce que tu vas faire, pas selon les performances.
Avantages
- Confidentialité totale : rien ne sort de ta machine.
- Coût zéro par token après l'investissement initial dans le matériel.
- Fonctionne sans internet, sans pannes ni limites de service.
- Contrôle absolu : tu choisis le modèle, la version et la configuration.
Inconvénients
- Plus de qualité et de raisonnement sur les tâches exigeantes.
- Zéro installation : tu ouvres le navigateur et c'est parti.
- Accès à des modèles énormes qui ne tiennent pas sur ta machine.
- Contexte très long et multimodalité soignée sans te battre avec le matériel.
Voici le guide rapide selon ton profil :
- LM Studio — pour démarrer sans te compliquer. App de bureau à l'interface soignée : tu cherches le modèle par son nom, tu vois combien de RAM il demande et si ta machine tient, tu cliques sur télécharger et tu discutes. Zéro terminal, zéro fichier de configuration. Si tu n'as jamais touché à ça, commence ici.
- Jan — pour qui privilégie confidentialité et open source. Hors ligne par défaut et code entièrement auditable. Il embarque sa propre interface de chat et la philosophie "tes données t'appartiennent". Le choix si l'ouverture n'est pas négociable.
- Ollama — pour programmer et intégrer. Il fonctionne en ligne de commande et, surtout, il lève une API locale compatible OpenAI. Ça veut dire que tu peux connecter ton modèle local à n'importe quelle app ou script qui utilisait déjà l'API d'OpenAI en changeant juste l'URL. C'est la pièce pour construire des choses. On a un guide dédié à Ollama.
- llama.cpp — pour presser le matériel. Ce n'est pas une app avec interface : c'est le moteur qui anime les autres. Tu ne descends ici que si tu veux optimiser au millimètre. Pour démarrer, ignore-le.
Pas à pas : ton premier modèle en local
On passe au chemin le plus rapide vers un résultat. Je le présente avec Ollama parce qu'il laisse l'API prête à intégrer, mais avec LM Studio ce serait littéralement "chercher → télécharger → discuter" depuis l'interface.
1. Installe Ollama. Télécharge-le depuis son site (macOS, Windows et Linux) et installe-le comme n'importe quel programme. Sur Mac et Windows, il vient avec une app de bureau ; sur Linux, ça passe par le terminal.
2. Télécharge et lance ton premier modèle. Une seule commande télécharge le modèle quantifié et le démarre :
# Lance un modèle de 8B (il le télécharge la première fois)
ollama run llama3.1:8b
# À partir de là, tu écris et tu converses dans le terminal.
# Pour sortir : /byeLa première fois, ça prend le temps que pèse le fichier (quelques Go). Les suivantes, le modèle est déjà sur le disque et démarre instantanément.
3. Vérifie ce que tu as installé. Utile quand tu accumules plusieurs modèles :
# Liste les modèles que tu as téléchargés
ollama list
# Teste un petit modèle rapide pour les tâches légères
ollama run llama3.2:3b
# Supprime-en un que tu n'utilises plus pour libérer du disque
ollama rm llama3.1:8b4. Intègre-le à tes apps (optionnel). C'est là qu'est la magie pour qui programme. Ollama expose une API locale sur localhost:11434 compatible avec le format d'OpenAI :
curl http://localhost:11434/v1/chat/completions \
-H "Content-Type: application/json" \
-d '{
"model": "llama3.1:8b",
"messages": [{"role": "user", "content": "Résume ceci en une phrase : ..."}]
}'En changeant l'URL de base de ton code de api.openai.com vers localhost:11434, n'importe quelle app qui utilisait OpenAI se met à tourner contre ton modèle local. Sans coût, sans rien envoyer dehors.
Astuce
Commence avec un modèle de 7-8B pour l'usage général et garde sous la main un modèle de 3B pour les tâches rapides (classer, extraire, réponses courtes) : il consomme moins et répond quasi instantanément. Changer de modèle, c'est juste changer le nom dans la commande.
Les limites (pour éviter les mauvaises surprises)
Aucune review honnête ne cache les petites lignes, alors voilà :
- Qualité plafonnée. Un 7-14B local ne raisonne pas comme GPT ou Claude sur les problèmes complexes, le code difficile ou les longues chaînes de logique. Pour ça, le cloud gagne encore.
- Contexte plus court. Les fenêtres de contexte géantes consomment beaucoup de mémoire en local. Si tu dois ingérer des documents énormes d'un coup, tu vas souffrir.
- Le matériel est la limite. Tu ne peux pas faire tourner un modèle de 70B sur un portable de 8 Go, même en le quantifiant à fond. La mémoire commande.
- Vitesse variable. En CPU pur, un 7B crache quelques mots par seconde. C'est utilisable, mais n'attends pas la fluidité d'un service cloud avec des GPU dédiés.
Aucun de ces points n'est un défaut : c'est le prix d'avoir l'IA chez toi. Les connaître à l'avance évite la déception de demander à un modèle local quelque chose pour quoi il n'est pas fait.
Pour qui est l'IA en local ?
Elle t'intéresse si : tu travailles avec des données sensibles que tu ne veux pas mettre dans le cloud, tu fais du volume et le coût par token te fait mal, tu as besoin que ça fonctionne hors ligne, ou tu veux simplement apprendre comment l'IA marche de l'intérieur sans dépendre de personne. Aussi si tu es développeur et que tu veux prototyper et intégrer sans dépenser en API à chaque test.
Elle ne t'intéresse pas si : tu n'utilises l'IA que ponctuellement et la qualité maximale te compte plus que la confidentialité ou le coût, ta machine est très juste en mémoire, ou tu ne veux pas passer dix minutes à installer quoi que ce soit. Dans ce cas, une IA dans le cloud —ou une intermédiaire comme OpenRouter, qui te donne plein de modèles via une seule API— colle mieux.
La question honnête n'est pas "l'IA locale est-elle meilleure que ChatGPT ?". Elle ne l'est pas au plafond, et ne le prétend pas. La question est "combien vaut pour moi que mes données ne quittent pas ma machine, ne pas payer à chaque usage et pouvoir travailler sans internet ?". Si la réponse est "pas mal", en 2026, le monter te coûte dix minutes et quelques gigas de disque. Ça n'a jamais été aussi facile d'avoir ta propre IA, vraiment à toi.
