On va se dire les vraies affaires : on envoie tous les jours des choses très personnelles à des IA dans le cloud. Des baux, des courriels, des propositions commerciales, des analyses financières. Des documents qu’on ne laisserait jamais traîner sur une table dans un café, mais qu’on balance sans trop y penser sur des serveurs à l’autre bout du continent.

Pour mes propres affaires, je l’assume. Pour les données de tiers et de clients, je suis beaucoup plus strict : ce qui ne m’appartient pas ne quitte pas ma machine sans une raison précise et un contrôle explicite. C’est exactement pour ces cas-là qu’un modèle qui tourne en local, sans connexion, sans télémétrie, prend tout son sens.

Ça m’a rattrapé un matin. Pas une fuite, pas un scandale. Juste une réalisation tranquille : toutes mes données professionnelles passent par des infrastructures que je ne contrôle pas. Et je paye un abonnement mensuel pour le privilège.

L’idée a germé : est-ce que je pourrais faire tourner un modèle d’IA directement sur mon ordinateur? Sans connexion internet ni abonnement, et avec la garantie qu’aucune ligne de texte ne quitte mon disque dur?

La réponse courte : oui. Et ça m’a pris une après-midi.

Petite note avant qu’on commence : j’utilise Claude au quotidien pour mes tâches complexes, et c’est avec Mistral Small que j’ai monté mon premier setup local. Ce que je raconte ici fonctionne aussi avec ChatGPT, Gemini, Llama ou n’importe quelle autre IA conversationnelle. La logique est la même, l’interface change.

Ce que ça prend (et ce que ça prend pas)

Première chose que j’ai apprise : faire tourner un modèle de langage en local, c’est pas réservé aux ingénieurs en apprentissage machine qui compilent leur propre noyau Linux le dimanche matin (même si je suis sûr qu’ils s’amusent bien).

Ce que ça prend pour vrai : un ordinateur avec du coffre. Dans mon cas, un MacBook Pro avec 32 Go de mémoire et une puce Apple Silicon. C’est la configuration qui permet de faire tourner confortablement des modèles de 25 à 30 milliards de paramètres. Avec 16 Go, c’est possible aussi, mais on parle de modèles plus petits, donc moins brillants.

Ce que ça prend pas : un diplôme en informatique, un serveur dans ton sous-sol, ou trois jours de configuration obscure.

Par contre, je vais être honnête (c’est un article de blog, pas une publicité) : quand j’ai lancé mes premiers gros modèles, j’ai entendu mon MacBook ventiler pour la première fois de sa vie. Le genre de bruit qui te fait lever les yeux de l’écran en te demandant si quelque chose brûle. Tout est normal, c’est juste le processeur qui travaille fort. Mais ça vaut la peine de le savoir avant de lancer une requête en plein appel Teams.

Le setup en une après-midi

L’outil qui rend tout ça accessible s’appelle Ollama. C’est un moteur open source qui permet de télécharger et faire tourner des modèles de langage sur ta machine, sans configuration serveur. Tu l’installes, tu télécharges un modèle, tu parles. C’est à peu près aussi simple que ça en a l’air.

Mon premier test : j’ai installé Mistral Small, un modèle de 24 milliards de paramètres qui pèse environ 14 Go. Un ollama pull mistral-small dans le terminal, quinze minutes de téléchargement, et je discutais avec un modèle qui tournait à 100% sur ma machine. Première impression : c’est pas aussi bon que Claude pour le raisonnement complexe, mais pour résumer un document, classifier de l’information ou rédiger un premier jet, c’est très solide.

Pour ceux qui préfèrent une interface graphique plutôt qu’un terminal noir, j’ai ajouté Open WebUI par-dessus. C’est une interface web locale (tout reste sur ton ordi, même l’interface) qui ressemble à ChatGPT. Tu ouvres ton navigateur, tu vas sur localhost:3000, et tu choisis ton modèle. C’est propre.

Est-ce que tout s’est passé sans accroc? Non. Mon mot de passe Google contenait un espace insécable invisible (oui, ça existe) qui cassait la connexion. Docker ne démarrait pas parce que l’application n’était pas ouverte. Le fichier de configuration avait une adresse courriel avec une coquille. Le genre de bugs plates qui n’ont rien à voir avec l’IA et tout à voir avec le fait que les ordinateurs sont fondamentalement têtus. Mais c’est ça, un vrai parcours d’installation. Si quelqu’un te dit que ça s’est fait sans aucun problème du premier coup, il te ment ou il a oublié.

Le premier cas d’usage : un briefing courriel matinal

Avoir un modèle local qui répond à des questions, c’est le fun, mais c’est pas encore utile au quotidien. Le vrai moment où ça devient intéressant, c’est quand tu le branches sur tes propres données.

Mon premier projet concret : un script Python qui scanne mes boîtes de courriels Gmail (j’en ai quatre, pour différentes sphères de ma vie), récupère les non lus des dernières 24 heures, et les envoie au modèle local pour classification et résumé. Le matin, avant même d’ouvrir mes courriels, j’ai un briefing qui me dit : voici ce qui est urgent, voici ce qui peut attendre, voici ce qui est du spam promotionnel que tu peux ignorer.

Le script tourne automatiquement à 6h30 chaque matin. Si mon Mac dormait, il se lance dès que j’ouvre l’écran. Le résultat est sauvegardé en fichier markdown dans un dossier dédié.

La différence avec les outils cloud que j’utilise par ailleurs? Mes courriels ne quittent jamais ma machine. Le modèle les lit, les classifie, et les oublie. Aucun serveur externe n’a vu passer le contenu de mes boîtes. Pour quelqu’un qui gère de l’immobilier locatif (avec des données de locataires), des propositions commerciales et des documents financiers, c’est pas un détail.

Et le coût récurrent? Zéro. Le modèle est téléchargé une fois. L’électricité de mon Mac, c’est à peu près tout.

Ce que je n’ai pas encore fait (et pourquoi)

Il y a deux choses que je veux explorer mais que je n’ai pas encore mises en place.

La première, c’est le RAG (retrieval-augmented generation). L’idée : donner au modèle local accès à mes propres documents (propositions commerciales, baux, analyses), pour qu’il puisse chercher dedans avant de répondre. Open WebUI supporte ça nativement, avec des collections de documents qu’on peut activer par conversation. C’est mon prochain week-end projet.

La deuxième, c’est les agents locaux. L’idée, c’est de permettre au modèle de ne pas juste répondre à des questions, mais d’exécuter des actions : envoyer un message, modifier un fichier, lancer une commande. C’est puissant, mais c’est aussi donner un accès shell à une IA sur ta machine. Pour l’instant, je trouve le risque de sécurité trop élevé pour mon niveau de confort. J’aimerais sincèrement en discuter avec des gens qui l’ont fait, comprendre comment ils gèrent les permissions, le sandboxing, les gardes-fous. Si c’est ton cas, je veux t’entendre.

Ce que je crois par contre, c’est que les agents locaux vont devenir un outil central dans les prochaines années. Autant pour les individus qui veulent garder le contrôle de leurs données que pour les entreprises qui ont des obligations de souveraineté, de confidentialité, ou qui veulent simplement éviter d’envoyer leurs secrets commerciaux dans le cloud de quelqu’un d’autre. Au Québec, au Canada, cette question-là va prendre de plus en plus de place.

Le setup local n’est pas un remplacement du cloud. C’est un complément. J’utilise Claude pour la réflexion stratégique complexe, pour les tâches qui demandent un raisonnement long et nuancé. Et j’utilise mon modèle local pour tout ce qui touche à des données que je ne veux pas partager. Les deux coexistent, chacun dans sa zone.

Et toi, tu fais tourner quelque chose en local? Sur quoi tu l’utilises? Je suis curieux.

Outils mentionnés : Ollama (moteur LLM local), Open WebUI (interface graphique), Mistral Small (modèle 24B). Ces choix reflètent mon expérience au moment d’écrire, mais l’écosystème bouge vite. Des modèles comme Gemma 4, Qwen 2.5 ou Llama font aussi très bien le travail.