IA de code en entreprise : protéger code propriétaire, NDA et secret industriel

#Le vrai risque : votre code part chez un tiers

Le code source n'est pas une donnée comme une autre. Il porte vos algorithmes, vos secrets de fabrication, vos clés d'API en dur (cela arrive), votre architecture de sécurité et, juridiquement, il est souvent couvert par une clause de cession de droits au profit d'un client. Un assistant de code cloud lit le contexte autour du curseur, parfois le dépôt entier pour l'indexation, et envoie ces fragments à un modèle distant. Le risque n'est pas théorique : il combine fuite de secret industriel, violation de NDA, et non-conformité RGPD dès qu'un commentaire contient une donnée personnelle.

Secret industriel

Un algorithme propriétaire exposé à un tiers perd sa qualification de secret (art. L151-1 du Code de commerce) : la protection juridique tombe.

Clause de cession

Pour du code livré à un client, le contrat interdit souvent toute communication à un sous-traitant non agréé. Un assistant cloud est un sous-traitant non déclaré.

NDA fournisseur

Vous travaillez sur le code d'un partenaire sous accord de confidentialité : l'envoyer à OpenAI ou Anthropic est une violation directe.

Données personnelles

Un jeu de test, un log inline ou un commentaire avec un email font basculer l'envoi sous le RGPD.

#Pourquoi Copilot et Cursor violent vos NDA

GitHub Copilot et Cursor sont d'excellents outils de productivité, mais leur modèle économique repose sur des LLM hébergés (Copilot sur l'infrastructure Azure/OpenAI, Cursor sur OpenAI et Anthropic). Même avec les offres Business ou Enterprise, votre code quitte le poste pour être complété côté serveur. Les options 'content exclusion' ou 'privacy mode' réduisent la rétention, mais le flux réseau vers un tiers demeure. Pour une clause de NDA qui interdit toute divulgation à un tiers non nommé, ce flux est une violation, indépendamment de la politique de rétention.

Copilot Business

Code envoyé à GitHub/Azure pour complétion. 'No training' activé par défaut, mais transfert hors UE et soumission au CLOUD Act.

Cursor (Privacy Mode)

Le mode privé empêche la rétention côté Cursor, mais les requêtes passent toujours par les API d'OpenAI et Anthropic.

Cursor sans Privacy Mode

Le code peut être conservé et utilisé pour améliorer le produit. Inacceptable sous NDA strict.

Limite contractuelle commune

Aucune de ces offres ne signe un DPA qui couvre une clause de cession de code client à un sous-traitant tiers spécifique.

#Ce qu'exigent RGPD et AI Act côté code source

Le RGPD ne parle pas de 'code source' mais de données à caractère personnel. Le code en contient plus souvent qu'on ne le croit : emails dans les commentaires, identifiants de tests, données de seed, traces de logs. Dès qu'un de ces éléments part vers un assistant cloud, vous réalisez un transfert de données, ce qui impose une base légale, un sous-traitant sous DPA (art. 28), et, hors UE, un mécanisme de transfert valide (clauses contractuelles types). L'AI Act, lui, classe la plupart des assistants de code en risque limité, avec surtout des obligations de transparence ; mais l'enjeu réel pour vous est en amont, dans la gouvernance des données d'entrée du modèle.

RGPD art. 28

Tout assistant cloud traitant vos données est un sous-traitant et exige un DPA signé. Beaucoup d'équipes l'utilisent sans contrat.

RGPD transfert hors UE

Sans hébergement UE, il faut des garanties (SCC) et une analyse de transfert. Le local supprime purement la question.

AI Act (transparence)

Risque limité pour l'assistant de code : informer que du contenu est généré par IA. Peu contraignant, mais à documenter.

Minimisation par conception

La voie la plus simple de conformité : ne pas transférer du tout. Une stack locale est nativement minimisée.

#La stack 100% locale : Ollama, Cline, Aider, Tabby

Une stack de copilote local repose sur deux couches : un serveur d'inférence qui fait tourner le modèle sur votre matériel, et des clients qui s'y branchent depuis l'IDE ou le terminal. Le serveur de référence est Ollama, qui expose une API HTTP locale et gère le téléchargement des modèles GGUF. Au-dessus, trois clients complémentaires couvrent les usages : Cline pour l'agent dans VS Code, Aider pour le pair-programming en terminal orienté commits Git, et Tabby pour l'autocomplétion à la Copilot, en mode serveur partagé pour toute l'équipe.

Ollama

Serveur d'inférence local (MIT). Sert les modèles via http://localhost:11434. Aucune télémétrie de code, aucun appel sortant pour l'inférence.

Cline

Extension VS Code (agent). Lit/écrit des fichiers, exécute des commandes, planifie des tâches multi-fichiers. Se branche sur Ollama en provider local.

Aider

CLI de pair-programming (Apache 2.0). Édite le code et fait les commits Git ; excellent pour le refactoring guidé. Pointe vers l'API Ollama.

Tabby

Serveur d'autocomplétion auto-hébergé (Apache 2.0). Remplace Copilot pour les suggestions inline ; idéal en mode serveur GPU mutualisé.

# Serveur d'inference local
curl -fsSL https://ollama.com/install.sh | sh

# Modele de code recommande pour 16-24 Go VRAM
ollama pull qwen2.5-coder:14b

# Verifier que l'API locale repond (aucun appel sortant)
curl http://localhost:11434/api/tags

pip install aider-install && aider-install

# Pointer Aider vers le serveur local, jamais vers une API cloud
export OLLAMA_API_BASE=http://127.0.0.1:11434
aider --model ollama_chat/qwen2.5-coder:14b

Pour Cline, dans VS Code, on sélectionne le provider 'Ollama' dans les réglages de l'extension et on renseigne l'URL du serveur (locale ou celle de votre serveur GPU interne). Aucune clé d'API cloud n'est saisie : c'est la garantie technique qu'aucun fragment ne part vers OpenAI ou Anthropic. Tabby, lui, se déploie en conteneur sur le serveur GPU et les postes pointent vers son endpoint interne.

#Architecture : poste isolé vs serveur GPU mutualisé

Deux topologies dominent. Le poste isolé fait tourner Ollama directement sur la machine du développeur (Mac M-series ou PC RTX) : le code ne quitte jamais le poste, idéal pour les NDA les plus stricts, mais limité par la VRAM individuelle et coûteux à équiper en masse. Le serveur GPU mutualisé centralise un ou plusieurs GPU dans le réseau interne ; les postes s'y connectent via l'API. On mutualise un modèle plus gros, on rationalise le matériel, et le flux reste strictement intra-réseau (LAN ou VPN d'entreprise).

#Quels modèles de code pour quelle VRAM

La qualité d'un copilote local dépend du modèle. Trois familles ouvertes dominent le code en 2026 : Qwen2.5-Coder (Alibaba, excellent rapport qualité/taille, du 1.5B au 32B), Devstral (Mistral, pensé pour l'usage agentique avec Cline et OpenHands), et DeepSeek-Coder (fort sur les langages systèmes). Le choix se cale sur la VRAM disponible et l'usage : un petit modèle rapide pour l'autocomplétion Tabby, un plus gros pour le raisonnement agentique de Cline.

#Politique 'provider local only'

Une stack locale ne protège que si elle est verrouillée par une politique. 'Provider local only' signifie qu'aucun outil de dev ne peut pointer vers une API d'IA cloud. Cela se décline en trois niveaux complémentaires : configuration des outils (pas de clé cloud), blocage réseau (les endpoints d'IA cloud sont inatteignables depuis les postes de dev), et règle organisationnelle (charte signée). C'est la combinaison des trois qui rend la politique réellement opposable lors d'un audit.

1. 01
   Interdire les clés d'API cloud

   Aucune variable OPENAI_API_KEY, ANTHROPIC_API_KEY ou équivalent sur les postes de dev. Cline et Aider sont configurés exclusivement sur l'endpoint Ollama interne.
2. 02
   Bloquer les endpoints au pare-feu

   Filtrer en sortie api.openai.com, api.anthropic.com, les domaines Copilot et Cursor. Les complétions ne peuvent alors physiquement plus sortir du réseau.
3. 03
   Figer la config des extensions

   Déployer les réglages VS Code/Cline par GPO ou MDM pour empêcher un dev de re-pointer vers un provider cloud.
4. 04
   Charte et formation

   Une charte signée rappelle l'interdiction de coller du code dans un chatbot cloud (le risque résiduel n'est pas technique mais humain).
5. 05
   Journaliser les accès au serveur d'inférence

   Les logs du serveur Ollama/Tabby prouvent que les complétions sont servies en interne. Pièce maîtresse de l'audit.

#Auditer la non-exfiltration

L'argument 'c'est local' ne vaut que s'il est prouvé. L'audit de non-exfiltration consiste à démontrer, traces à l'appui, qu'aucun fragment de code ne quitte le périmètre pendant l'usage du copilote. La méthode la plus convaincante est l'observation réseau : on capture le trafic d'un poste pendant une session de codage intensive et on vérifie qu'aucune connexion ne part vers un endpoint d'IA cloud. On complète par l'inspection de la configuration et des logs serveur.

# 1. Capturer le trafic du poste pendant une session de codage Cline/Aider
sudo tcpdump -i any -n 'tcp port 443' -w /tmp/session_code.pcap

# 2. Lister les IP/destinations contactees (hors reseau interne)
tcpdump -r /tmp/session_code.pcap -n | awk '{print $5}' | cut -d. -f1-4 | sort -u

# 3. Verifier qu'aucune resolution ne vise un endpoint d'IA cloud
grep -Ei 'openai|anthropic|githubcopilot|cursor' /var/log/dnsmasq.log || echo 'OK : aucune requete IA cloud'

Preuve réseau

Capture tcpdump/Wireshark : seules les IP du serveur interne et des dépôts Git internes apparaissent. Zéro endpoint d'IA cloud.

Preuve de configuration

Export des réglages Cline/Aider montrant le provider Ollama interne et l'absence de clé cloud.

Preuve de blocage

Test négatif : une tentative manuelle d'atteindre api.openai.com depuis un poste de dev échoue (pare-feu).

Preuve serveur

Logs Ollama/Tabby horodatés corrélant les complétions aux postes internes.

#Arbitrage honnête : local vs cloud

Soyons justes : le cloud reste devant sur la qualité brute des plus gros modèles et sur le zéro-effort d'infrastructure. Un assistant cloud propriétaire pourra, sur certaines tâches de raisonnement complexe, surpasser un Qwen2.5-Coder 32B local. Le local impose un investissement matériel, une équipe pour maintenir le serveur d'inférence, et une qualité légèrement en retrait sur les tâches les plus pointues. Le bon arbitrage n'est pas idéologique : il dépend de la sensibilité de votre code.

Choisissez le local si

Vous avez du code sous NDA, des clauses de cession, du secret industriel, ou des clients qui interdisent les sous-traitants tiers non agréés.

Le cloud peut suffire si

Votre code est open source, sans données personnelles, sans engagement contractuel de confidentialité envers un tiers.

Coût réel du local

Un serveur GPU (24-48 Go) amorti sur une équipe revient souvent moins cher que des licences cloud par siège sur 2-3 ans.

Le risque caché du cloud

Le coût d'une seule violation de NDA (perte de contrat, contentieux) dépasse des années de licences locales.

#Conclusion et mise en œuvre

Équiper une équipe de dev d'un copilote performant sans jamais exposer le code propriétaire est aujourd'hui réaliste : Ollama comme serveur d'inférence, Cline et Aider pour l'agent et le terminal, Tabby pour l'autocomplétion mutualisée, le tout sous une politique 'provider local only' et un audit de non-exfiltration reproductible. La conformité RGPD et AI Act se gagne par soustraction : pas de transfert, pas de sous-traitant, pas de question. Pour gagner du temps sur la mise en place, le guide payant « Copilote de code local » fournit un pack clé en main Ollama + Cline + Aider : configurations prêtes à l'emploi, choix de modèles par budget VRAM, politique réseau de blocage des endpoints cloud, et le script d'audit de non-exfiltration. De quoi déployer en quelques heures une stack défendable devant votre juridique et vos clients.