Pourquoi je fais tourner mes agents IA à 100 % en local

Depuis un peu plus d'un an, aucun de mes agents IA ne parle au cloud. Tout tourne sur mon Mac, derrière mon pare-feu, sur mes fichiers. Ce n'est pas une posture idéologique : c'est devenu le choix le plus rationnel que j'aie fait sur mon poste de travail.

On me pose souvent la question avec un sourcil levé : « Tu fais tourner tes modèles en local ? Pourquoi te compliquer la vie alors qu'une clé API et trois lignes de code suffisent ? » La réponse tient en une phrase, puis mérite tout un article : parce que je refuse que mes données soient la contrepartie invisible d'un service que je paie déjà.

Le vrai sujet, ce n'est pas la performance, c'est la propriété

Quand j'envoie un document à une API distante, je perds le contrôle sur trois choses à la fois : où il est stocké, combien de temps, et ce qu'il devient. Les conditions d'utilisation changent, les politiques de rétention aussi, et « nous n'entraînons pas sur vos données » est une promesse contractuelle, pas une garantie technique. En local, la question ne se pose même pas. Le modèle lit le fichier, produit sa réponse, et rien ne quitte la machine. Je n'ai pas à faire confiance : l'architecture rend la fuite impossible.

C'est une différence de nature, pas de degré. Le chiffrement en transit protège les données pendant le trajet ; le local supprime le trajet. Pour beaucoup de mes usages, c'est exactement ce qu'il faut.

Apple Silicon a rendu tout ça sérieux

Il y a trois ans, « l'IA locale » voulait dire des modèles poussifs et des réponses décevantes. Ce n'est plus vrai. La mémoire unifiée d'Apple Silicon change la donne : le processeur graphique et les cœurs de calcul partagent la même RAM, donc un modèle de plusieurs milliards de paramètres tient en mémoire sans les acrobaties habituelles. Avec MLX, le cadre de calcul d'Apple pensé pour cette architecture, je charge un modèle quantifié et j'obtiens des vitesses très correctes pour du travail interactif.

Ma pile est volontairement banale, et c'est un compliment :

• Ollama ou MLX pour servir le modèle localement ;
• MCP (Model Context Protocol) pour brancher mes agents sur mes fichiers, mon calendrier, mes dépôts, sans passerelle externe ;
• du Python pour l'orchestration, et du Rust avec Tauri quand je veux une vraie application de bureau légère.

# Récupérer un modèle et discuter avec, sans quitter la machine
ollama pull qwen2.5-coder:14b
ollama run qwen2.5-coder:14b "Résume ce fichier de log"

Rien d'exotique. C'est justement l'intérêt : l'outillage local est devenu assez mûr pour disparaître.

Ce que ça change concrètement, au quotidien

Le premier bénéfice est mental. Je ne me demande plus « est-ce que ce document a le droit de partir sur un serveur ? » avant chaque requête. Je copie-colle un contrat, un extrait de code propriétaire, des notes personnelles, sans arbitrage. Cette absence de friction fait que j'utilise mes agents beaucoup plus.

Le deuxième, c'est l'autonomie réelle. Dans le train, dans un avion, chez un client au réseau capricieux : mes agents fonctionnent. Pas de dépendance à une disponibilité tierce, pas de panne d'API qui bloque ma journée, pas de limite de requêtes qui tombe au pire moment.

Le troisième est financier, mais discret. Je ne compte pas les tokens. Je peux lancer un agent qui reformule cinquante fichiers en boucle sans surveiller un compteur qui monte. Le coût est fixe : c'est ma machine, déjà achetée.

Le local ne rend pas l'IA gratuite. Il rend son coût prévisible — et déplace la dépense du variable anxiogène vers le fixe assumé.

Les compromis, sans les cacher

Je serais malhonnête de vendre ça comme une solution sans revers. Il y en a, et ils sont réels.

La taille des modèles. Un modèle qui tient sur mon Mac n'égale pas les plus gros modèles propriétaires du marché sur les tâches de raisonnement les plus exigeantes. Pour du code, de la synthèse, de l'extraction, de la classification, l'écart s'est effondré et ne se voit plus vraiment. Pour un raisonnement long et retors, le cloud garde l'avantage. Je le sais, et je choisis en conséquence.

La latence et le débit. Sur les gros contextes, mon poste chauffe et ralentit. Ce n'est pas un centre de données. J'ai appris à découper mes tâches, à privilégier des modèles spécialisés plus petits plutôt qu'un généraliste énorme.

L'ergonomie. Il faut gérer ses modèles, sa mémoire, ses mises à jour. Moins qu'avant, mais plus qu'un simple appel réseau. C'est un coût d'entrée que tout le monde n'a pas envie de payer.

Mon compromis assumé : le local par défaut, le cloud en exception consciente, jamais l'inverse.

Pour qui c'est un avantage décisif, pas un caprice

Pour un particulier curieux, le local est un confort. Pour certains métiers, c'est une condition d'existence. Je pense aux données qui, légalement ou déontologiquement, ne peuvent pas aller dans le cloud :

• la santé, où le moindre dossier patient est encadré et où « on verra plus tard pour la conformité » n'est pas une option ;
• le juridique, où le secret professionnel interdit d'exposer une pièce à un tiers, fût-il américain et rassurant ;
• la R&D et l'industrie, où un brevet en préparation ou un code source stratégique n'a rien à faire sur une infrastructure qu'on ne maîtrise pas.

Pour ces domaines, le local n'est pas « plus privé » : c'est la seule manière d'utiliser un agent IA sans enfreindre une règle. Et c'est là que mon petit choix de confort personnel rejoint une vraie nécessité professionnelle.

Je ne pense pas que tout le monde doive débrancher le cloud demain matin. Mais je constate une chose : à chaque fois que j'ai basculé un usage en local, je ne suis jamais revenu en arrière. Le jour où faire tourner un bon modèle chez soi deviendra aussi banal qu'ouvrir un tableur, la vraie question ne sera plus « pourquoi en local ? » mais « pourquoi diable envoyer ça ailleurs ? ».