Ce moment où ton IA locale te pourrit la vie pour une raison ridicule

Tu connais cette sensation ? Tu regardes un système intelligent se planter pour une raison absolument stupide. Ça m'est arrivé il y a peu en bidouillant des agents de coding IA en local. Un sujet qui prend de l'ampleur, entre les modèles open-weight qui s'améliorent et cette envie croissante de bosser sans tout envoyer sur les serveurs de quelqu'un d'autre.

L'expérience

Le concept : faire construire un jeu fonctionnel à un agent de coding qui tourne entièrement en local. Pas un truc bidon pour impressionner, non — un vrai jeu avec de la gestion d'état, du rendu, de la gestion des inputs, une interface jouable. Le verdict après pas mal de cheveux arrachés : oui, c'est possible. Mais le chemin pour y arriver a révélé tout un tas de galères que l'écosystème des outils IA ne gère pas super bien.

La stack qui aurait dû marcher

Trois composants, trois piliers du dev IA local actuel : une CLI d'agent de coding provider-agnostic, Ollama qui sert une API compatible OpenAI depuis localhost, et Qwen3.8 27B qui tourne sur ma machine. Pas un config de低收入 pour situer : le modèle 27B à 17 Go rentre nickel dans les 32 Go de mémoire unifiée et supporte le tool calling avec des capacités de raisonnement correctes.

Les premiers résultats donnaient envie d'y croire. En quinze minutes chrono, l'agent avait pondu une structure HTML complète et presque 200 lignes de CSS façon NES avec du biseau et une palette de couleurs calée. Plus flippant encore : l'agent a repéré sa propre erreur en cours de route. Il a écrit un fichier, relu ce qui était sortit, vu que ça correspondait pas à ce qu'il voulait, et corrigé le tir tout seul. Du vrai comportement agentique. Le modèle semblait taillé pour la tâche.

Puis l'agent a essayé d'écrire le fichier de logique du jeu, et là... stop complet.

La spirale infernale

Ce qui a suivi, tout développeur qui a galéré avec des outils IA reconnaîtra. Treize tentatives successives pour écrire le fichier du moteur de jeu. Treize fois où le stream s'est interrompu en cours de génération. Zéro erreur. Zéro explication. Zéro output exploitable.

Le pire dans tout ça ? Regarder le processus de raisonnement de l'agent. Comme chaque tentative repartait de zéro, le modèle redérivait les mêmes choix de design from scratch, et tombait sur des tables de score et des approches d'implémentation différentes à chaque fois. Trois essais = trois réponses différentes à la même question d'architecture. L'agent passait une heure à réfléchir et ne livrait rien.

Le suspect évident : la mémoire. J'ai fermé des onglets de navigateur, libéré plusieurs Go de RAM, et les choses se sont légèrement améliorées.诊断 confirmée, apparemment. Sauf que c'était la mauvaise leçon à retenir.

Ce que les logs ont vraiment révélé

En reregardant les logs serveur, c'est une autre histoire. Pas une seule erreur out-of-memory nulle part. La mémoire libre tournait entre 21 et 27 Go tout du long, pour un modèle de 17 Go. La RAM, c'était pas le problème.

Le vrai bug : un mismatch de configuration qui produisait zéro erreur visible. Le config de l'agent annonçait une fenêtre de contexte de 32 768 tokens. Mais le serveur Ollama avait été redémarré avec un plafond à 8 192 tokens, et cette différence passait inaperçue. L'agent planifiait joyeusement un fichier de 800 lignes à générer d'un coup, parce que selon lui, il avait 32k de marge. Quand la génération tapait le mur des 8k en plein tool-call, la connexion était coupée sans aucun message d'erreur que l'agent pouvait analyser.

Il y avait aussi un problème secondaire qui se cachait dans les logs de démarrage : Ollama avait lancé avec le context-shifting activé, ce qui aurait permis à la fenêtre de glisser quand elle dépassait, en sacrifiant les anciens tokens pour faire de la place. Mais l'architecture du modèle supportait pas cette feature, donc elle était désactivée en silence. Ce qui aurait dû être une limite soft est devenu un mur dur.

Le DevOps, cette discipline que le dev IA local te force à maîtriser

Cette expérience a cristallisé un truc essentiel sur le dev IA local que l'enthousiasme autour des modèles open-weight a tendance à masquer. Quand tu fais tourner des modèles sur ton propre matériel, tu fais pas juste du code — tu gères de l'infrastructure. Et l'infrastructure, ça demande la même discipline de diagnostic, la même gestion de configuration, la même attention aux paramètres opérationnels qu'un système en prod.

Les fenêtres de contexte, c'est pas des propriétés abstraites de modèle à setter et oublier. Ce sont des paramètres opérationnels qui interagissent avec ta chaîne d'outils de façon pas évidente. Quand le contexte configuré de l'agent correspond pas au plafond réel du serveur, t'as pas d'avertissement — tu as des silent failures qui ressemblent à de l'incompétence du modèle alors que c'est de la mauvaise config opérationnelle.

La leçon pratique pour les développeurs qui explorent les agents de coding IA en local : valide ton environnement aussi soigneusement qu'un déploiement en prod. Vérifie que la config de ton agent correspond aux paramètres de ton runtime. Lis les logs serveur, pas juste la sortie de l'agent. Comprends quelles features ton architecture de modèle supporte vraiment versus ce que le tooling essaie d'activer.

Les modèles s'améliorent. Les outils murissent. Mais le fossé entre "ça marche en démo" et "ça marche de façon fiable au quotidien" requiert toujours un jugement humain pour le combler — et ce jugement ressemble énormément à de la discipline DevOps traditionnelle appliquée à une nouvelle classe d'infrastructure.

Le build Tetris a fini par marcher. Quatre heures et demie sur deux jours, du code propre sur trois fichiers, et ça fonctionne correctement. Mais les leçons sont venues pas de la réussite, mais de la compréhension de pourquoi les échecs se sont produits — et de la reconnaissance que parfois, les problèmes les plus coûteux n'ont rien à voir avec l'intelligence.