Il arrive un moment où un service d'IA cloud cesse d'être la bonne réponse. Vous devez analyser un contrat qui ne peut pas quitter le bureau. La connexion internet est coupée et le travail ne peut pas attendre. La facture mensuelle des appels d'API a discrètement triplé. L'IA locale, exécutant un modèle sur votre propre machine, répond à ces trois cas. Exécuter l'IA localement n'est pas une version réduite du cloud. C'est un problème d'ingénierie différent, gouverné par la mémoire, non par les fonctionnalités. La partie difficile n'est pas l'installation du logiciel. C'est de comprendre quel modèle votre matériel peut réellement exécuter à une vitesse utilisable.

Ce qu'est l'IA locale, et ce qu'elle n'est pas

Un système d'IA locale comporte quatre parties. Les poids du modèle sont les nombres qui définissent son comportement. Un moteur d'inférence charge ces poids et génère du texte, les plus courants étant llama.cpp et son enveloppe Ollama. Une interface utilisateur permet de dialoguer avec lui, Open WebUI étant la plus répandue. Des cadres agents optionnels lui permettent d'appeler des outils et de modifier des fichiers. Quatre dimensions décident si le local l'emporte sur l'hébergé. La vie privée signifie que vos données ne quittent jamais la machine, ce qui compte pour le travail juridique, médical et sur le code source. Le coût devient fixe après l'achat du matériel, sans facturation à jeton. La latence est prévisible car il n'y a pas d'aller retour réseau. La disponibilité résiste aux coupures internet. Le compromis porte sur la capacité et la vitesse : une carte graphique grand public ne peut pas égaler les plus grands modèles hébergés, ni leur débit. Une configuration hybride, local pour le travail sensible et cloud pour le raisonnement lourd, est souvent la réponse honnête.

Le nombre qui gouverne tout : la mémoire

L'inférence locale est d'abord un problème de mémoire. Les poids du modèle doivent tenir dans une mémoire rapide, généralement la mémoire de la carte graphique, sinon la génération devient douloureusement lente. Règle pratique simple : un modèle de sept milliards de paramètres en quantification quatre bits nécessite environ quatre gigaoctets pour les poids seuls. Doublez les paramètres, doublez la mémoire. Chaque bit de précision par poids coûte environ un octet par milliard de paramètres, donc un modèle huit bits de même taille nécessite deux fois plus de mémoire qu'un modèle quatre bits. La quantification échange une faible perte de qualité contre une forte réduction de mémoire, et quatre bits est, pour la plupart des usages pratiques, le point au delà duquel le compromis cesse d'être intéressant. En plus des poids, le cache clé valeur grandit avec la fenêtre de contexte, si bien qu'une longue conversation demande plus de mémoire que ce que suggère la fiche du modèle. Si les poids ne tiennent pas dans la mémoire graphique, les couches débordent vers la mémoire système puis vers le disque, et la vitesse chute de plusieurs ordres de grandeur. Avant d'acheter du matériel, estimez le plus grand modèle que vous voulez exécuter, multipliez son nombre de paramètres par les octets par poids de la quantification choisie, et laissez de la marge pour le cache. Une carte de milieu de gamme avec huit à douze gigaoctets exécute confortablement des modèles de sept à huit milliards de paramètres. Vingt quatre gigaoctets ouvrent l'accès aux modèles de soixante dix milliards de paramètres en quatre bits. Sans carte graphique discrète, l'inférence CPU fonctionne mais est lente, et Apple Silicon utilise une mémoire unifiée sous son moteur Metal, où les mêmes règles de mémoire s'appliquent avec un numérotage différent.

Une pile reproductible, étape par étape

Chaque commande ci dessous est sur sa propre ligne afin de pouvoir être sélectionnée et copiée. Sous Linux, installez Ollama, qui enveloppe llama.cpp et gère les téléchargements de modèles.

curl -fsSL https://ollama.com/install.sh | sh

Sous Windows et macOS, téléchargez plutôt l'installateur depuis ollama.com. Vérifiez que le moteur détecte votre carte graphique.

ollama ps

Téléchargez et exécutez un premier modèle. L'exemple utilise un modèle de huit milliards de paramètres ; remplacez le nom par tout modèle de la bibliothèque Ollama.

ollama run llama3.1:8b

Pour une véritable interface de discussion, Open WebUI se connecte au moteur local et prend en charge plusieurs modèles, l'historique des conversations et le dépôt de documents. Avec Docker installé, une seule commande le démarre.

docker run -d -p 3000:8080 --add-host=host.docker.internal:host-gateway -v open-webui:/app/backend/data --name open-webui --restart always ghcr.io/open-webui/open-webui:main

Ouvrez localhost:3000 dans un navigateur, créez un compte administrateur, et le modèle local apparaît dans le sélecteur de modèles. Pour l'automatisation, Ollama expose une API compatible OpenAI sur le port 11434, si bien que tout outil écrit pour un point de terminaison cloud peut pointer vers localhost en modifiant une seule ligne de configuration. Fixez la version du moteur et notez le nom exact du modèle et sa quantification dans un fichier texte. Sans cela, une configuration qui fonctionne aujourd'hui se cassera silencieusement lorsque l'un ou l'autre sera mis à jour, et reproduire un résultat deviendra impossible.

Au delà du chat : récupération, agents de code et limites

Le chat est le point d'entrée, non la destination. La génération augmentée par récupération sur des fichiers locaux permet au modèle de répondre à partir de vos propres documents : les documents sont découpés en segments, convertis en plongements, stockés dans une base vectorielle locale, et les segments pertinents sont placés dans le contexte du modèle avant qu'il ne réponde. Fait localement, cela garde les documents confidentiels entièrement sur la machine. Les assistants de codage locaux connectent le même moteur à un éditeur ou un terminal, mais ils exigent une gestion du contexte plus fine, car une base de code réelle dépasse largement toute fenêtre de contexte. Les agents de codage autonomes ajoutent l'usage d'outils, et c'est ici que l'avantage local devient une exigence de sécurité : un agent capable de modifier des fichiers et d'exécuter des commandes shell doit tourner dans un bac à sable, avec des portes d'approbation pour toute action destructive et le moindre privilège sur chaque outil. La génération locale d'images, d'audio et de vidéo est possible mais bien plus exigeante. Les modèles de diffusion d'images tiennent sur des cartes de milieu de gamme. La génération vidéo n'y tient pas, sur du matériel grand public, en un temps raisonnable. Savoir où se trouve la frontière évite la déception la plus courante.

Quand c'est lent, trouver le vrai goulot d'étranglement

Deux nombres décrivent la performance. Le temps jusqu'au premier jeton mesure l'attente avant l'apparition de la première réponse. Les jetons par seconde mesurent la vitesse à laquelle la réponse s'écoule. Une longue attente suivie d'un texte rapide pointe vers une phase de pré remplissage lente, généralement causée par une grande invite ou par l'absence d'accélération graphique. Un premier jeton rapide suivi d'un texte lent pointe vers des poids ne tenant pas en mémoire. Les erreurs de mémoire insuffisante signifient que le modèle, le cache, ou les deux, dépassent la mémoire disponible, et le correctif est un modèle plus petit, une quantification inférieure ou une fenêtre de contexte plus courte. Diagnostiquez en séparant matériel, moteur, modèle et configuration, car chacun a un correctif différent, et modifier le mauvais fait perdre des jours. Effectuez vos propres mesures sur vos propres tâches, non sur des chiffres publiés, car vos documents et la longueur de votre contexte déterminent la performance réelle bien plus que tout test synthétique.

D'autres notes d'ingénierie de l'IA appliquée sont publiées sur le blog, et les questions d'installation peuvent être adressées via la page contact. La référence source est Hector L. Adler, Local AI on Your PC, 2026.