Faire coder un modèle local 12B : où ça casse vraiment

La question vient d’un client, et elle est parfaitement légitime : « Est-ce qu’on peut coder avec de l’IA sans qu’une seule ligne de notre code ne parte chez un tiers ? »

Réponse courte : oui, mais pas comme tu l’imagines. Voici ce qui se passe réellement quand tu montes un environnement de développement complet autour d’un modèle de 12 milliards de paramètres tournant en local, et que tu le lances sur un vrai projet, un mini clone de Slack en Convex, Tailwind et TypeScript.

Spoiler : le problème n’est presque jamais celui qu’on anticipe.

TL;DR

• Le modèle local sait écrire du code. Ce n’est pas là que ça casse.
• Ce qui casse, c’est tout le reste : initialiser un projet, gérer une commande qui attend une réponse dans le terminal, sortir d’une boucle, respecter une consigne d’ordre d’opérations.
• Parler à un 12B comme à un modèle frontière ne marche pas. Les prompts qui fonctionnent sur un gros modèle produisent de la dérive sur un petit.
• La compensation ne passe pas par le prompt mais par le harnais : des règles courtes, des phases explicites, et des hooks qui bloquent mécaniquement les erreurs.

Ce qui marche mieux que prévu

Commençons par le positif, parce qu’il est réel : sur une tâche bien cadrée et de périmètre restreint (écrire un schéma de base de données, créer une table d’authentification, produire un composant) un 12B local produit du code correct.

La génération pure n’est pas le facteur limitant. Sur des tâches unitaires, avec un contexte propre et une consigne précise, l’écart avec un modèle frontière est bien plus faible que ce que la différence de taille laisse supposer.

Le choix du modèle compte, en revanche. À taille comparable, tous ne se valent pas sur la capacité de raisonnement : c’est ce critère, plus que le score brut sur les classements, qui détermine si le modèle sait suivre un plan en plusieurs étapes plutôt que de réagir coup par coup.

Ce qui casse : cinq blocages, dont un seul est vraiment lié au modèle

1. Le shell non interactif : le vrai mur

C’est le blocage le plus sous-estimé, et il n’a rien à voir avec l’intelligence du modèle.

Beaucoup d’outils en ligne de commande posent des questions : « Voulez-vous installer les dépendances ? », « Quel framework ? », « Écraser le fichier existant ? ». Un humain répond et continue. Un agent, lui, envoie sa commande dans un shell non interactif : la question s’affiche, personne ne répond, et le processus reste suspendu jusqu’au timeout.

Le modèle ne comprend pas ce qui se passe. Il voit une commande qui ne rend pas la main, conclut à un échec, et relance, souvent la même commande, avec le même résultat.

Le contournement : interdire les commandes interactives et fournir systématiquement les équivalents non interactifs (les options de type --yes, --no-input, ou les fichiers de configuration passés en argument). Ce n’est pas une consigne à écrire dans le prompt : c’est une règle à faire appliquer par le harnais, parce que le modèle l’oubliera.

2. L’initialisation de projet

Créer un projet vierge est paradoxalement plus difficile que modifier un projet existant. Deux raisons :

• C’est un terrain de commandes interactives, précisément le point précédent.
• C’est le domaine où les versions changent vite. Le passage d’une version majeure à l’autre d’un outil de style comme Tailwind modifie la structure de configuration et le mode d’intégration ; un modèle dont les connaissances sont figées applique la procédure de l’ancienne version et produit un projet qui ne démarre pas. La documentation officielle de migration Tailwind détaille l’ampleur de ces changements.

Le contournement, et il est décisif : ne fais pas initialiser le projet par le modèle. Pars d’un boilerplate à jour, testé, versionné. Le modèle commence à travailler sur une base qui démarre. Tu supprimes ainsi la phase la plus casse-gueule, celle qui n’apporte aucune valeur intellectuelle.

3. Les boucles infinies

Un petit modèle qui rencontre une erreur qu’il ne comprend pas a une tendance nette à répéter. Il relance la même commande, réécrit le même fichier, retente la même correction, parfois pendant plusieurs minutes.

Le mécanisme est identifiable : quand rien dans le contexte n’indique que l’approche est en échec, la continuation la plus probable est celle qui vient d’être produite. Le modèle n’a pas la capacité de prendre du recul et de dire « cette voie ne marche pas, essayons autre chose ».

Les contournements qui fonctionnent :

• Un compteur de répétition dans le harnais : au bout de N tentatives identiques, on interrompt et on force un changement d’approche.
• Une recherche web forcée en cas d’erreur inconnue, pour injecter de l’information nouvelle dans le contexte. Sans information nouvelle, il n’y a aucune raison que la réponse change.

4. Les skills et le contexte long

Une skill (un fichier d’instructions chargé quand une situation le justifie) fonctionne très bien avec un gros modèle : il la lit, la comprend, l’applique et revient à sa tâche.

Avec un 12B, le comportement est différent : plus le contexte s’allonge, plus le modèle perd le fil de sa tâche initiale. Une skill de deux pages injectée en cours de route peut littéralement lui faire oublier ce qu’il était en train de faire.

Le contournement : des instructions beaucoup plus courtes, chargées au bon moment, et surtout une seule à la fois. Le principe de divulgation progressive qui fonctionne si bien avec un modèle frontière doit devenir beaucoup plus strict ici.

5. Le respect de l’ordre des opérations

Une règle aussi simple que « lis le fichier avant de le modifier » n’est pas fiablement respectée. Le modèle propose une modification à partir de ce qu’il croit être le contenu du fichier, souvent ce qu’il a écrit lui-même vingt minutes plus tôt, sans tenir compte des changements intervenus depuis.

Le contournement est mécanique, pas conversationnel : un hook qui rejette toute écriture sur un fichier non lu dans le tour courant. Le modèle reçoit une erreur explicite, lit le fichier, puis réécrit. Ça fonctionne, mais attention à la mise au point : un hook trop strict provoque exactement la boucle qu’il devait prévenir.

La leçon centrale : on ne parle pas à un 12B comme à un modèle frontière

C’est le constat le plus contre-intuitif du test.

Un modèle frontière tolère un prompt long, nuancé, avec des conditions et des exceptions. Il en extrait l’intention. Un petit modèle traite ce même prompt comme une masse d’instructions concurrentes, et n’en retient qu’une partie, pas nécessairement la plus importante.

Ce qui change concrètement :

Avec un modèle frontière	Avec un 12B local
Instructions longues et nuancées	Instructions courtes, une idée par règle
« Fais attention à X »	Un hook qui bloque X
Plan implicite, le modèle s’organise	Phases explicites imposées
Grand contexte, il fait le tri	Contexte minimal, on fait le tri pour lui
Consigne de sécurité dans le prompt	Interdiction technique dans le harnais

Cette dernière ligne est la plus importante. Une consigne du type « ne supprime jamais de dossier » est une intention. Un hook qui refuse l’exécution d’une commande de suppression récursive est une garantie. Sur un petit modèle, seule la garantie tient.

L’architecture qui fonctionne : des phases explicites

Ce qui a le plus amélioré les résultats n’est ni le prompt ni le modèle : c’est le découpage explicite du travail en phases, avec un livrable écrit entre chacune.

1. Reconnaissance, le modèle explore le code existant et écrit ce qu’il a compris dans un fichier.
2. Plan, il propose une suite d’étapes, écrite, validée avant exécution.
3. Exécution, il applique le plan, une étape à la fois.

L’intérêt du fichier intermédiaire est double : il sert de mémoire externe quand le contexte se remplit, et il permet de repartir d’un état propre après une dérive, sans tout recommencer.

C’est la même logique de contrat explicite entre étapes qui rend le découpage déterministe/probabiliste opérationnel côté entreprise : on ne demande pas au modèle de tout tenir en tête, on matérialise l’état hors du modèle.

Est-ce que ça vaut le coup ?

Ça dépend entièrement de ce que tu cherches.

Oui, si :

• La contrainte de confidentialité est réelle et non négociable.
• Le périmètre est cadré : modifier un projet existant, écrire des fonctions unitaires, produire des tests.
• Tu acceptes d’investir dans le harnais, les règles, les phases, les hooks. C’est là que se joue l’essentiel.

Non, si :

• Tu attends l’autonomie d’un modèle frontière sur une tâche ouverte.
• Tu veux initialiser des projets à partir de rien.
• Personne dans l’équipe n’a le temps de construire et maintenir l’environnement d’exécution.

Sur le plan économique, l’arbitrage rejoint celui du coût réel de l’IA en entreprise : une machine de travail costaude ne se rembourse que sur un usage régulier et soutenu. Pour un usage épisodique, l’API reste moins chère et infiniment moins pénible.

Checklist : monter un environnement de code local

• Je pars d’un boilerplate à jour et testé, le modèle n’initialise pas le projet.
• Toutes les commandes interactives sont interdites, avec leurs équivalents fournis.
• Un hook bloque les commandes destructrices, indépendamment du prompt.
• Un hook impose la lecture d’un fichier avant sa modification.
• Un compteur interrompt les répétitions identiques.
• Une recherche d’information est déclenchée sur erreur inconnue.
• Les instructions sont courtes, une idée par règle.
• Le travail est découpé en phases avec un livrable écrit entre chacune.
• J’ai testé le harnais sur une tâche réelle, pas sur un « hello world ».

FAQ

Quelle taille de modèle faut-il viser pour coder en local ?

La taille compte moins que la capacité de raisonnement du modèle et que la qualité du harnais autour. Un modèle de 12 milliards de paramètres bien encadré (phases explicites, hooks, contexte court) produit de meilleurs résultats qu’un modèle plus gros lancé sans garde-fous. Le facteur limitant observé n’est pas la génération de code, c’est la conduite du travail sur la durée.

Peut-on mélanger un modèle local et un modèle distant ?

Oui, et c’est souvent le meilleur compromis. Le modèle local traite le code (donc les données confidentielles) tandis qu’un modèle plus puissant sert à concevoir le harnais, écrire les règles et diagnostiquer les blocages, sur des informations qui ne sont pas sensibles. C’est exactement la démarche employée pendant le test : le gros modèle construit les garde-fous, le petit fait le travail.

Pourquoi le modèle ignore-t-il des consignes pourtant explicites ?

Parce qu’une consigne n’est qu’une information parmi d’autres dans le contexte, pas une contrainte d’exécution. Plus le contexte s’allonge, plus le poids relatif de chaque instruction diminue, et sur un petit modèle, la dégradation est rapide. C’est la raison pour laquelle les règles vraiment critiques ne doivent pas être écrites dans le prompt mais appliquées par le harnais, qui, lui, ne les oublie jamais.

Combien de temps faut-il pour rendre un environnement local utilisable ?

Compter plusieurs sessions de mise au point, et beaucoup plus de temps sur le harnais que sur le choix du modèle. La plupart des blocages ne se découvrent qu’en conditions réelles : le shell qui reste suspendu, la boucle sur une erreur de version, le hook trop strict qui bloque le travail. Le budget à prévoir n’est pas un budget d’installation, c’est un budget d’itération.

Conclusion

Coder en local avec un petit modèle est possible, mais ce n’est pas une question de modèle : c’est une question d’ingénierie autour du modèle.

Ce qui fait la différence tient en trois éléments : un point de départ propre, un travail découpé en phases avec des livrables écrits, et des règles critiques appliquées mécaniquement plutôt qu’espérées via le prompt.

Si tu envisages cette voie, commence par le harnais avant de comparer les modèles. C’est là que se trouve l’essentiel du résultat.

Ce test est détaillé dans le live consacré au développement avec un modèle local. Le prochain article détaille précisément la construction de ces hooks.