Assistants de code IA : où va votre code, et comment le garder chez vous

Oui, votre code quitte l’entreprise dès qu’un développeur utilise un assistant de code IA : chaque requête envoie au modèle les fichiers ouverts, les extraits que l’outil juge utiles et, avec un agent, tout ce qu’il décide de lire pour faire la tâche. La question utile pour un DSI ou un RSSI porte sur la suite : le code est-il conservé, combien de temps, sert-il à entraîner les modèles, et où. Sur les offres entreprise des grands éditeurs, la réponse tient en une phrase : pas d’entraînement sur vos données, une rétention bornée ou nulle, des engagements écrits au contrat. Sur les offres grand public, chaque garantie dépend d’un réglage individuel que vous ne contrôlez pas.

Chez nos clients, le code fuit rarement par le contrat d’entreprise, et presque toujours par le compte personnel qu’un développeur a ouvert faute d’outil fourni, et qu’il utilise toujours.

Ce qui part à chaque requête, et où

Un assistant d’autocomplétion envoie le fichier en cours et quelques voisins. Un agent qui explore le repo pour corriger un bug envoie ce qu’il lit : le module, les tests, la configuration, et le fichier .env s’il traîne à la racine. Rien ne "télécharge le dépôt" d’un bloc, mais au fil des sessions une large part du code transite par l’API de l’éditeur.

Où transite-t-il ? Chez l’éditeur, le plus souvent sur une infrastructure américaine, sauf à passer par une offre hébergée dans votre propre cloud : Claude Code, par exemple, peut appeler les modèles via Amazon Bedrock, Google Vertex AI ou Microsoft Foundry, et les requêtes restent chez votre fournisseur cloud.

Entraînement et rétention : ce que les éditeurs écrivent aujourd’hui

Nous avons relu les pages officielles pour cet article ; relisez-les avant de signer, elles bougent. GitHub indique ne pas utiliser les données des clients Copilot Business et Enterprise pour entraîner ses modèles, alors que les abonnements individuels peuvent y servir sauf opposition de l’utilisateur. Anthropic applique la même frontière à Claude Code : sous conditions commerciales (API, Team, Enterprise), pas d’entraînement sur le code ni les prompts, et une rétention standard de 30 jours, avec une rétention zéro pour les comptes éligibles ; sur un compte grand public, l’entraînement dépend du choix de l’utilisateur et la rétention monte à cinq ans s’il l’autorise. OpenAI documente la même logique pour son API : pas d’entraînement par défaut, des journaux de surveillance des abus conservés jusqu’à 30 jours, rétention zéro sur approbation. Cursor conditionne tout à son mode privé : activé, l’éditeur n’entraîne pas sur vos données, et un administrateur peut l’activer pour toute l’équipe.

Le motif se répète : le niveau d’offre est la garantie, et le même modèle sur un autre type de compte change les trois réponses.

Ce qu’il faut lire dans le contrat et régler dans la configuration

Trois questions par outil, par écrit, au niveau d’offre que vous achetez : nos données servent-elles à entraîner, qu’est-ce qui est conservé et combien de temps, qui les traite et où. Les réponses figurent dans l’accord de traitement des données et la liste des sous-traitants, et non dans un mail du commercial. Si une rétention zéro existe, vérifiez qu’elle couvre l’outil que vos développeurs utilisent, et non la seule API.

Les garanties contractuelles ne valent que si les réglages suivent. Il faut un compte entreprise avec SSO, pour que le départ d’un développeur ferme l’accès, des réglages de confidentialité imposés au niveau de l’organisation, et la journalisation activée pour savoir qui a envoyé quoi. Le choix de l’outil dépend en partie de ce que ces réglages permettent.

Les règles côté équipe

• Aucun secret dans le repo, et un scan de secrets en pre-commit et en CI.
• Les dépôts exclus nommés (code sous NDA, modules sensibles), avec les exclusions configurées dans l’outil.
• Des comptes entreprise pour tous, achetés avant d’annoncer la politique.
• Des permissions d’agent qui interdisent les chemins et les commandes sensibles.
• Une page de politique qui dit quelles données vont vers quel outil.

Copilot propose par exemple une exclusion de contenu par fichier et par dépôt, que GitHub lui-même présente comme un complément aux droits d’accès. Interdire ou ne rien fournir déplace l’usage vers des comptes personnels aux garanties les plus faibles, hors de vue de la sécurité. Les licences entreprise coûtent une fraction d’un salaire d’ingénieur, ce qui en fait la mesure la moins chère de cette liste.

Quand le code contient des données personnelles

Un repo propre n’en contient pas. Beaucoup en contiennent : des fixtures copiées de la production, un dump SQL dans un dossier "tmp", des logs committés avec des emails dedans. Dès lors, l’éditeur de l’assistant devient un sous-traitant au sens du RGPD, ce qui impose un accord de traitement conforme à l’article 28, des garanties pour tout transfert hors Union européenne et une ligne dans le registre des traitements. La minimisation s’applique aussi : nettoyer les fixtures et interdire les exports de production dans le repo règle le problème à la source. Les équipes qui ont déjà construit une IA conforme au RGPD reconnaîtront la logique, l’architecture d’abord et le contrat ensuite.

Si votre DSI retient l’autorisation faute de cette revue, c’est par elle que nous commençons avec les équipes que nous accompagnons, avec un tableau par outil et par niveau d’offre, les clauses lues et les réglages posés avant la première licence.