Début 2026, après avoir vu OpenAI intégrer de la publicité dans ChatGPT et Anthropic lever des fonds à des valorisations qui laissaient présager une tarification future agressive, j'ai décidé de mener une expérience. Pendant plusieurs semaines de travail sur des projets réels, j'ai abandonné ma configuration habituelle sous Claude Code pour un flux 100 % auto-hébergé sur mon MacBook M4 Pro Max de 2024. Aucune API cloud, aucune donnée ne quittant ma machine. Je voulais voir ce que donnait concrètement un développement IA en local d'abord. Pas en théorie, pas sur un benchmark d'un week-end, mais sur de vrais livrables.
Voici ce que j'en ai retiré : là où les modèles locaux m'ont surpris, là où ils ont montré leurs limites, et pourquoi la question de savoir qui contrôle vos outils d'IA compte plus que la plupart des développeurs ne l'imaginent.
Pourquoi c'est important maintenant
Les prix des API au token ont baissé au cours de l'année écoulée grâce à une concurrence féroce. Mais en prenant du recul, le tableau est différent. OpenAI prévoit 14 milliards de dollars de pertes pour 2026 et s'attend à brûler au total 115 milliards de dollars avant d'atteindre la rentabilité vers 2029 ou 2030. Anthropic, plus sobre, anticipe tout de même de brûler près de 20 milliards de dollars avant d'atteindre un flux de trésorerie positif.
L'argent doit bien venir de quelque part. La réponse d'OpenAI est arrivée en février 2026 : de la publicité dans ChatGPT. Les utilisateurs des offres gratuite et Go voient désormais des contenus sponsorisés en lien avec le sujet de leurs conversations, la personnalisation publicitaire étant activée par défaut. Anthropic s'est engagé à garder Claude sans publicité, mais son dernier tour de table a valorisé l'entreprise à 180 milliards de dollars. Une valorisation de cet ordre exige une croissance agressive du chiffre d'affaires.
Le schéma est bien connu d'autres cycles technologiques. Les prix chutent pour capter des parts de marché, l'argent du capital-risque subventionne la différence, et une fois le marché verrouillé, l'équation économique change. Gartner prévoit que d'ici 2026, le coût des services d'IA deviendra, pour la plupart des acheteurs, un facteur concurrentiel plus déterminant que la performance brute des modèles.
Si vous construisez votre flux de travail autour d'un modèle que vous ne contrôlez pas, vous bâtissez sur un terrain qui peut se dérober sous vos pieds à tout moment.
Considérations de sécurité et de contrôle
Le coût n'est qu'une dimension. Les risques de sécurité des outils d'IA tiers sont de plus en plus difficiles à balayer d'un revers de main. OpenClaw est l'exemple le plus clair de ce qui peut mal tourner.
OpenClaw a dépassé les 85 000 étoiles sur GitHub en quelques semaines. Il peut naviguer sur le web, lire et écrire des fichiers, envoyer des e-mails et contrôler des applications de bureau. Un audit de janvier 2026 a relevé 512 vulnérabilités, dont huit critiques, parmi lesquelles une exécution de code à distance en un clic. Des chercheurs ont trouvé plus de 135 000 instances exposées sur Internet, dont près d'un millier fonctionnant sans aucune authentification.
Le risque lié à la chaîne d'approvisionnement aggrave la situation. Des chercheurs ont identifié des utilisateurs publiant des « skills » malveillants sur ClawHub, la place de marché de plugins d'OpenClaw, dont un utilisateur ayant mis en ligne 354 paquets malveillants. Gartner a constaté que 22 % des clients entreprises comptent déjà des employés faisant tourner OpenClaw sur les réseaux de l'entreprise sans approbation officielle.
OpenClaw est un cas extrême, mais le schéma de fond s'applique à tout outil d'IA dont vous ne maîtrisez pas l'environnement d'exécution. Quand les modèles tournent en local, la surface d'attaque se réduit à votre propre machine et à votre propre réseau. Vous contrôlez les permissions, les intégrations et le cycle de mises à jour.
Souveraineté des données et conformité
La pression réglementaire va dans le même sens. L'EU AI Act entre en pleine application en août 2026, avec des sanctions pouvant atteindre 7 % du chiffre d'affaires annuel mondial. DORA exige la preuve que les organisations peuvent maintenir leur continuité opérationnelle même en cas de défaillance de prestataires tiers. L'EU Data Act interdit explicitement l'enfermement propriétaire pour le stockage des données.
Pour les développeurs qui manipulent du code client, des dossiers médicaux, des données financières ou tout ce qui relève de HIPAA, PCI-DSS ou RGPD, l'IA auto-hébergée est le chemin le plus court vers la conformité. Quand le modèle tourne sur votre propre matériel, chaque prompt et chaque réponse reste à l'intérieur de votre périmètre.
Gartner a forgé le terme « géopatriation » pour décrire la tendance à ramener les charges de travail vers des environnements locaux ou souverains, prévoyant que d'ici 2030, plus de 75 % des entreprises européennes et du Moyen-Orient géopatrieront leurs charges de travail virtuelles. Les charges de travail d'IA sont en tête de cette migration.
Là où les modèles locaux ouvrent de la flexibilité
Au-delà du coût et de la conformité, l'IA en local d'abord ouvre des possibilités de personnalisation que les API cloud n'offrent tout simplement pas.
Fine-tuning sur vos propres données.
Avec des outils comme Unsloth et QLoRA, vous pouvez affiner des modèles à poids ouverts sur votre base de code, votre documentation et les conventions de votre équipe. Les adaptateurs LoRA sont légers (souvent moins de 100 Mo) et peuvent être permutés selon le projet sur lequel vous travaillez.
Intégrations d'outils sur mesure.
Le système de providers d'OpenCode repose sur un format de configuration ouvert. Vous définissez exactement à quels outils le modèle a accès, comment il les appelle et quels garde-fous sont en place. Pas de place de marché de plugins tierce, aucun vecteur d'attaque via la chaîne d'approvisionnement au-delà de vos propres fichiers de configuration.
Distillation de modèles.
Vous pouvez utiliser un modèle de pointe pour générer des données d'entraînement synthétiques pour un flux de travail précis, puis affiner un modèle local plus petit afin de le reproduire pour une fraction de la latence et du coût.
Comportement déterministe.
Les modèles locaux produisent des sorties cohérentes lorsque vous contrôlez la température et la graine. Les API cloud peuvent modifier le comportement d'un modèle par des mises à jour silencieuses à tout moment. Si la reproductibilité compte, le local est la seule garantie.
Optimisation adaptée au matériel.
Le framework MLX d'Apple est conçu spécifiquement pour Apple Silicon. Sur un M4 Pro Max, GLM-4.7 Flash tourne à 60-85 tokens par seconde en quantification 4 bits. C'est assez rapide pour coder de manière interactive, sans dépendance au réseau.
Les outils que j'ai utilisés
GLM-4.7 Flash
Un modèle Mixture-of-Experts de 30 milliards de paramètres, avec ~3 milliards de paramètres actifs par passe avant. Il obtient 59,2 % sur SWE-bench Verified. Assez léger pour servir de modèle de planification, avec des réponses rapides et une faible empreinte mémoire.
Devstral Small 2
Le transformeur dense de 24 milliards de paramètres de Mistral, sous licence Apache 2.0. Il obtient 68,0 % sur SWE-bench Verified avec une fenêtre de contexte de 256K. Conçu spécifiquement pour le codage agentique : explorer des bases de code, éditer plusieurs fichiers, orchestrer des changements en plusieurs étapes.
OpenCode
Un agent de codage open source et indépendant du provider, avec plus de 100K étoiles sur GitHub. Deux agents intégrés, Plan (lecture seule) et Build (accès complet), que vous pouvez associer à des modèles différents. La clé de tout le flux de travail.
Comment le flux de travail a pris forme
La configuration à laquelle j'ai abouti utilise les deux modèles selon un schéma « planifier puis construire » via OpenCode. Ollama sert les modèles en local, et la configuration d'OpenCode vous permet de diriger chaque agent vers un modèle différent.
J'ai attribué GLM-4.7 Flash à l'agent Plan. Il est rapide, peu gourmand en ressources, et doué pour parcourir une base de code, esquisser une approche et proposer des stratégies de mise en œuvre. Comme le mode Plan est en lecture seule, aucun risque de modification prématurée. Je pouvais itérer rapidement sur l'approche avant de m'engager sur quoi que ce soit.
Pour l'agent Build, j'ai utilisé Devstral Small 2. Sa fenêtre de contexte plus large et ses capacités agentiques plus solides le rendaient bien adapté aux éditions multi-fichiers. Une fois un plan solide, je changeais d'agent et je laissais Devstral gérer la mise en œuvre.
Cette répartition n'a rien d'arbitraire. Utiliser un modèle léger pour la planification garde l'itération rapide, tandis que réserver le modèle plus lourd à l'exécution assure des modifications de code de meilleure qualité. Après la première semaine, le rythme est devenu naturel. Planifier vite, construire avec soin.
Il y a eu des frictions au début. La configuration initiale a demandé quelques heures de paramétrage et de dépannage. La gestion de la mémoire sur une machine de 32 Go exigeait de l'attention. Faire tourner les deux modèles en même temps créait de la pression, j'ai donc appris à laisser les modèles inactifs se décharger entre les tâches. Ce n'était pas aussi fluide que d'ouvrir un onglet de navigateur vers Claude. Mais une fois le flux de travail bien réglé, ces aspérités se sont estompées.
Bien travailler avec des modèles plus petits
Les petits modèles ne sont pas des modèles stupides, mais ils pardonnent moins les prompts bâclés. Les modèles de pointe dans le cloud s'accommodent d'instructions vagues. Les modèles locaux dans la plage de 3 à 24 milliards de paramètres actifs attendent que vous fassiez la moitié du chemin.
Soyez explicite sur le format de sortie.
Au lieu de « refactorise cette fonction », dites « refactorise pour utiliser des retours anticipés, garde la même signature et ajoute un commentaire JSDoc ». Les petits modèles suivent bien les instructions précises mais devinent mal quand les instructions sont ouvertes.
Placez le contexte important en tête.
Mettez le code le plus pertinent et les contraintes clés en haut de votre prompt. Repoussez les informations de contexte vers la fin. Les petits modèles ont une capacité d'attention effective plus courte, même quand la fenêtre de contexte est techniquement grande.
Utilisez des exemples one-shot.
Si vous voulez que le modèle suive un schéma précis, incluez un exemple concret. Les petits modèles imitent les exemples de façon plus fiable qu'ils n'interprètent des descriptions abstraites.
Découpez les tâches complexes en étapes.
Demandez d'abord à un petit modèle d'implémenter l'utilitaire JWT, vérifiez le résultat, puis passez à l'étape suivante. La séparation Plan/Build d'OpenCode soutient naturellement cette approche incrémentale.
Gardez le system prompt concis.
Chaque token du system prompt entre en concurrence avec votre tâche réelle pour le budget d'attention du modèle. Réduisez-le au rôle, aux contraintes et au format de sortie.
Précisez ce qu'il ne faut PAS faire.
Les petits modèles ont davantage tendance à surproduire. Si vous ne voulez pas que le modèle réécrive le code environnant ou ajoute des commentaires verbeux, dites-le explicitement.
Fixez les chemins de fichiers et les noms de fonctions.
Utilisez des chemins et des noms exacts plutôt que des descriptions comme « le gestionnaire d'authentification ». Les petits modèles lèvent l'ambiguïté de façon moins fiable, et des références précises éliminent les approximations.
Allégez le contexte entre les tâches.
Démarrez une nouvelle conversation plutôt que d'accumuler un contexte périmé quand vous changez de sujet. Les petits modèles se dégradent plus vite quand le contexte se remplit d'échanges précédents sans rapport.
Ce que j'ai perdu et ce que j'ai gagné
Je ne prétendrai pas que la configuration locale égale Claude Code ou Codex sur toutes les tâches. Les modèles de pointe restent meilleurs pour le raisonnement complexe en plusieurs étapes, les refactorisations à grande échelle couvrant des dizaines de fichiers, et les tâches qui exigent une connaissance approfondie de bibliothèques obscures. Quand je me heurtais à un mur sur quelque chose de vraiment difficile, je me tournais parfois vers une API cloud. Je ne vois pas là un échec de l'expérience. Savoir quand utiliser tel ou tel outil, c'est tout l'enjeu.
Mais pour 80 à 90 % de mon travail de codage quotidien, qu'il s'agisse d'implémenter des fonctionnalités à partir d'un plan clair, d'écrire des tests, de refactoriser dans une base de code bien maîtrisée ou d'explorer du code inconnu, la configuration locale était plus que suffisante. Les avantages se sont vite accumulés : zéro coût d'API, zéro latence réseau, zéro donnée quittant ma machine, un contrôle total du comportement du modèle, et aucun risque qu'un fournisseur change ses prix ou mette à jour le modèle en douce dans mon dos.
L'IA dans le cloud ne va pas disparaître, et c'est tant mieux. Pour les tâches qui exigent réellement un raisonnement à l'échelle des modèles de pointe, pour les équipes sans le matériel adéquat, ou pour les flux où la commodité l'emporte sur le contrôle, les modèles cloud restent le bon choix. L'objectif n'est pas de rejeter l'IA dans le cloud. C'est de cesser d'en dépendre par défaut.
La combinaison d'OpenCode, de GLM-4.7 Flash et de Devstral Small 2 n'est pas un compromis au rabais. C'est un autre jeu d'arbitrages, et pour les développeurs attachés à la souveraineté, à la prévisibilité des coûts et au contrôle, c'est de plus en plus le bon jeu d'arbitrages.
Si vous avez besoin d'aide pour mettre cela en place, n'hésitez pas à nous contacter.
Discuter avec Zach