Coder 100 % en local : souveraineté, machine et coût réel

« On ne peut pas envoyer notre code chez un tiers. » Cette phrase, prononcée par un client, n’est ni de la paranoïa ni un prétexte. Dans certains secteurs, c’est une clause contractuelle. Dans d’autres, c’est une obligation réglementaire. Et dans beaucoup de cas, c’est simplement que personne n’a jamais posé la question, jusqu’au jour où le service juridique la pose.

La bonne nouvelle : la réponse technique existe. La mauvaise : elle ne se résume pas à installer un modèle sur un poste.

TL;DR

• Trois motivations distinctes poussent au local, la conformité, le secret industriel, et le coût. Elles n’appellent pas les mêmes arbitrages.
• La machine n’est pas un serveur : une station de travail costaude suffit pour un modèle de taille moyenne. C’est le poste de développeur qui monte en gamme, pas le datacenter.
• L’économie ne se joue pas sur le matériel mais sur la régularité de l’usage. Une machine amortie sur trois ans qui sert deux heures par semaine coûte plus cher que l’API.
• Ce que tu perds est réel : autonomie sur les tâches ouvertes, capacité de raisonnement sur les problèmes difficiles, et du temps d’exploitation.

Trois raisons de passer en local, et elles ne se valent pas

Raison 1 : la conformité : non négociable

Le traitement de données personnelles ou de documents réglementés impose des obligations sur le lieu de traitement, la durée de conservation et l’identité du sous-traitant. Quand ces obligations ne peuvent pas être satisfaites par un fournisseur, la question du local ne se discute plus : c’est la seule option.

Le point important : cet arbitrage se pose au cadrage du projet, pas au moment de la mise en production. L’ANSSI rappelle dans ses règles d’or de la sécurité numérique que la maîtrise de la localisation et des accès fait partie du socle, pas des options.

Raison 2 : le secret industriel : un arbitrage, pas une règle

Ici il n’y a aucune obligation légale, seulement une décision d’entreprise : « notre code source, nos formules, nos plans ne sortent pas ».

C’est parfaitement légitime, et c’est un arbitrage à assumer explicitement, parce qu’il a un coût en capacité. Le piège classique est le double discours : interdire l’IA sur le code source pendant que les mêmes équipes collent des extraits dans un assistant grand public depuis leur navigateur. Une politique qui n’est pas outillée n’est pas une politique.

Raison 3 : le coût : souvent la plus mal calculée

C’est la motivation la plus fréquemment invoquée, et la plus souvent fausse. Elle mérite un calcul, pas une intuition.

Le calcul économique honnête

L’équation oppose un coût fixe (machine, installation, maintenance) à un coût variable (facturation à l’usage).

Côté matériel, l’ordre de grandeur constaté sur un test réel de développement assisté en local : un processeur de gamme haute, une carte graphique de milieu de gamme récente et 32 Go de RAM, dans les faits, une configuration i9 13900K / RTX 4070 / 32 Go. On parle d’un poste de travail costaud, pas d’une infrastructure serveur. C’est une bonne nouvelle : le ticket d’entrée est celui d’une machine de développeur bien équipée.

Côté variable, les repères de facturation à l’usage sont détaillés dans l’article sur le coût réel de l’IA en entreprise.

Les deux coûts que personne ne met dans le tableau :

1. Le temps d’installation et de mise au point. Ce n’est pas une après-midi. Entre le choix du modèle, les réglages, l’intégration à l’environnement de travail et les blocages à résoudre, compter plusieurs sessions, et ce temps est un coût salarial bien réel.
2. La maintenance. Les modèles évoluent, les outils changent, la configuration se dégrade. Quelqu’un doit s’en occuper. Si personne n’est nommé, l’installation sera abandonnée dans les six mois.

La règle de décision :

Situation	Recommandation
Contrainte de conformité réelle	Local, sans calcul de rentabilité
Usage quotidien et régulier, volume soutenu	Local rentable, faire le calcul
Usage épisodique ou exploratoire	API, sans hésiter
Traitement répétitif de gros volumes (transcription, OCR)	Local très pertinent
Tâches de raisonnement ouvertes et complexes	API, l’écart de capacité est réel

Ce que tu perds vraiment

Il faut être honnête sur le compromis, sinon la décision est prise sur une illusion.

L’autonomie sur les tâches ouvertes. Un modèle local de taille moyenne exécute très correctement une tâche cadrée. Il décroche sur une tâche large et ambiguë : conduire un projet du début à la fin, arbitrer entre plusieurs approches, se sortir seul d’une situation inattendue. Les blocages concrets (boucles, commandes bloquantes, dérive du contexte) sont détaillés dans l’article sur les limites réelles d’un modèle 12B.

La capacité de raisonnement sur les problèmes difficiles. Sur un bug complexe ou une conception d’architecture, l’écart avec un modèle frontière est net. Ce n’est pas une question de réglage.

Le confort d’exploitation. Une API fonctionne. Une installation locale demande de l’attention : pilotes, mémoire vidéo, versions, compatibilité. C’est une charge d’exploitation, faible mais permanente.

L’architecture qui règle le compromis : la séparation des rôles

L’approche la plus efficace n’est pas le tout-local, c’est la séparation par sensibilité.

• Le modèle local traite ce qui ne doit pas sortir : le code source, les documents confidentiels, les données clients.
• Un modèle distant traite ce qui peut sortir : la conception du harnais, la rédaction des règles, le diagnostic d’un blocage, la documentation, autant de sujets qui ne contiennent aucune donnée sensible.

C’est exactement la démarche employée pendant le test : le modèle puissant sert à construire les garde-fous et à comprendre les erreurs, le modèle local fait le travail sur le code. Chacun sur son terrain, et la contrainte de confidentialité reste satisfaite.

Cette séparation est le pendant technique du découpage entre ce qui exige des garanties et ce qui exige de la compréhension, décrit dans l’article sur le déterminisme et le probabiliste.

Comment choisir le modèle local

Un critère domine tous les autres : la capacité de raisonnement en plusieurs étapes, pas le score brut sur un classement.

Un modèle qui produit un excellent code sur une demande unitaire mais qui ne sait pas suivre un plan de trois étapes sera pénible au quotidien. À taille comparable, les écarts sur ce point sont importants d’une famille de modèles à l’autre : c’est ce qui doit guider le choix, et cela se teste en une demi-journée sur tes propres tâches.

Le protocole de test recommandé : prends cinq tâches réelles de ton quotidien, fais-les traiter par deux ou trois modèles candidats dans des conditions identiques, et compare non pas la qualité du code produit mais le nombre d’interventions humaines nécessaires pour arriver au résultat. C’est ce chiffre qui prédit le confort d’usage.

Checklist : décider et cadrer un passage au local

• J’ai identifié laquelle des trois motivations s’applique : conformité, secret, ou coût.
• S’il s’agit du coût, j’ai fait le calcul avec le temps d’installation et de maintenance.
• J’ai vérifié la régularité réelle de l’usage prévu, pas l’usage espéré.
• Une personne est nommée responsable de la maintenance de l’installation.
• J’ai testé les modèles candidats sur cinq tâches réelles, pas sur des exemples.
• Le critère de comparaison est le nombre d’interventions humaines, pas la qualité perçue.
• J’ai défini ce qui reste traité en local et ce qui peut passer par une API.
• La politique est outillée, pas seulement écrite dans une charte.

FAQ

Une machine de développeur suffit-elle vraiment ?

Pour un modèle de taille moyenne, oui : la configuration utilisée lors du test (processeur haut de gamme, carte graphique récente de milieu de gamme, 32 Go de RAM) permet de travailler sans frustration. La contrainte principale est la mémoire de la carte graphique, qui détermine la taille de modèle que tu peux charger. Passer à des modèles nettement plus gros change de catégorie de matériel, et souvent d’ordre de grandeur budgétaire.

Peut-on mutualiser une machine pour toute l’équipe ?

Techniquement oui, en exposant le modèle sur le réseau interne. C’est souvent le meilleur rapport coût/bénéfice : une seule machine bien équipée sert plusieurs développeurs. Deux points à traiter : la contention quand plusieurs requêtes arrivent en même temps, et la traçabilité des accès, une machine partagée reste un traitement de données qui doit être encadré comme tel.

Le local garantit-il la conformité au RGPD ?

Non. Il supprime la question du transfert vers un tiers, ce qui est un point important, mais toutes les autres obligations demeurent : base légale du traitement, information des personnes, durée de conservation, sécurité des accès, traçabilité. Une IA locale mal encadrée peut être tout aussi problématique qu’un service externe : le lieu du traitement n’est qu’un critère parmi plusieurs.

Que faire si le modèle local n’est pas au niveau sur une tâche donnée ?

Découper la tâche. Beaucoup de demandes qui échouent en un seul bloc réussissent en trois étapes explicites, avec un livrable écrit entre chacune. Si le découpage ne suffit pas, la tâche relève probablement du modèle distant, à condition qu’elle ne manipule pas de données sensibles. C’est précisément le rôle de la séparation par sensibilité : savoir à l’avance ce qui bascule d’un côté ou de l’autre.

Conclusion

Coder en local n’est ni un choix idéologique ni un gadget : c’est une réponse à une contrainte, et cette contrainte doit être nommée avant de commencer.

Si elle est réglementaire, le calcul de rentabilité ne se pose pas. Si elle est économique, fais le calcul complet (temps de mise au point et maintenance inclus) avant d’acheter la machine. Et dans tous les cas, garde la séparation par sensibilité en tête : le tout-local coûte cher en capacité, alors que très peu de tâches l’exigent réellement.

Ce retour d’expérience provient du live consacré au développement avec un modèle local, monté autour d’une demande client de confidentialité totale.