La sécurité du code propriétaire face à l'IA n'est plus un sujet pour votre RSSI dans six mois, c'est un sujet pour vous cette semaine. Sur une mission récente chez Extra Dev, on a vu un client perdre deux jours à retracer ce qu'un stagiaire avait collé dans un assistant IA grand public avant qu'on ne verrouille l'accès, pour un correctif qui en prenait normalement une heure.

  • 📊 Faille persistante, 45% du code généré par l'IA contient une vulnérabilité OWASP connue, même quand il compile du premier coup.
  • ⚠️ Fuite en 20 jours, des ingénieurs Samsung ont transmis du code source confidentiel à ChatGPT en 2023, sans retour possible.
  • 🔓 Obfuscation morte, Claude a désassemblé 5 Mo de son propre code minifié en 30 minutes, sans qu'on le lui demande deux fois.
  • 🛠️ Verdict opérationnel, ni blocage total ni accès libre : la passerelle contrôlée avec specs claires est la seule option qui tient.

Le réflexe le plus commun est de trancher dans le faux dilemme : bloquer tous les outils d'IA, ou laisser l'équipe faire ce qu'elle veut. Aucune des deux options ne protège votre code, et je vais vous montrer pourquoi avec des faits, pas des peurs.

Le vrai risque n'est pas le bug, c'est ce que votre dev colle dans le prompt

Un développeur qui bloque sur un incident en production pense à réparer vite, pas à la sécurité. Il ouvre un assistant IA et colle une trace d'erreur, un fichier de configuration, parfois un bout de code propriétaire entier. C'est le scénario que décrit une série de vidéos H2H Technology sur la gouvernance des assistants de code IA : la requête peut contenir des identifiants clients ou des clés d'API sans que le développeur s'en rende compte.

Ce n'est pas une hypothèse d'école. Selon webnet.fr, des ingénieurs Samsung ont transmis du code source confidentiel à ChatGPT en 20 jours, en 2023. Ces données ont nourri les serveurs d'OpenAI et sont devenues impossibles à récupérer. La même source avance que 38% des salariés partagent aujourd'hui des données confidentielles sans autorisation, un phénomène que le secteur appelle le "shadow AI" (l'usage non déclaré d'outils IA, hors du contrôle de la DSI).

Pourquoi le shadow AI échappe-t-il à votre DSI ?

Parce qu'il ne passe par aucune porte contrôlée. Une extension de navigateur, une clé API personnelle, un agent connecté en trente secondes : chaque interaction peut déplacer des données sensibles sans laisser de trace exploitable. Un ingénieur travaillant sur un système critique pour l'aérospatiale rencontre le même problème, documenté dans une vidéo dédiée aux secteurs réglementés : l'entrepreneur reste responsable de la manière dont l'information a été traitée, IA ou pas. Si votre entreprise traite des données clients sensibles, la question n'est plus "est-ce que ça arrive" mais "est-ce que ça vous arrive déjà", un sujet que je creuse côté équipes non-tech dans ce que ça coûte de déployer sans supervision technique.

Le code généré par l'IA compile presque toujours, mais reste vulnérable une fois sur deux

Là où beaucoup de dirigeants se rassurent à tort, c'est en confondant "ça marche" avec "c'est sûr". Une étude Veracode citée par kaspersky.fr a mesuré plus de 100 modèles IA populaires sur du code Java, Python, C# et JavaScript : le code produit compile avec succès dans 90% des cas aujourd'hui, contre moins de 20% il y a deux ans. La vitesse a explosé.

La sécurité, elle, n'a quasiment pas bougé. Toujours selon cette étude, 45% du code généré contient une vulnérabilité classique de la liste OWASP Top 10 (le classement de référence des failles de sécurité web), un chiffre stable depuis deux ans. Votre assistant IA livre un code qui tourne, mais une fonctionnalité sur deux embarque potentiellement une porte dérobée que personne n'a auditée.

Faut-il faire confiance au code que Claude ou Copilot vous livre ?

Non, pas sans relecture humaine ou automatisée. C'est le constat d'un thread du subreddit r/devops : une équipe SecOps y refuse de laisser des agents IA cloud scanner des dépôts propriétaires entiers, tout en admettant que l'écart de productivité devient difficile à ignorer. Leur compromis : cartographier l'arbre du dépôt en local, n'envoyer que des signatures de contexte ciblées, et exiger une approbation manuelle sur chaque modification écrite sur disque. Artisanal, mais je le vois reproduit sur presque toutes nos missions.

J'ai constaté le même pattern dans nos propres relectures : les projets qui traitent Claude Code ou Copilot comme un junior productif mais non fiable, avec revue systématique, s'en sortent bien mieux que ceux qui mergent directement la sortie de l'IA. Ce n'est pas une nuance de style, c'est la différence entre livrer vite et livrer une dette de sécurité découverte en audit.

Obfusquer votre code ne protège plus votre avantage concurrentiel

Voilà où la plupart des dirigeants qui misent sur "notre code est compilé, donc protégé" se trompent lourdement. Un article de korben.info documente comment le développeur Geoffrey Huntley a demandé à Claude d'Anthropic d'analyser le fichier cli.mjs de Claude Code lui-même, un fichier minifié de 5 Mo dont les symboles avaient été supprimés pour empêcher la rétro-ingénierie. Claude a produit un code lisible et fonctionnellement équivalent en 30 minutes.

La compilation et l'obfuscation (le brouillage volontaire du code pour empêcher qu'on le lise) ne sont plus une protection fiable de votre propriété intellectuelle. Un concurrent équipé d'un LLM avec une fenêtre de contexte suffisante (context window, la quantité de code que l'IA peut analyser en une seule fois) peut reconstruire votre logique produit sans copier une ligne, rendant la contrefaçon presque impossible à prouver. Les startups qui vendent des licences payantes sur du code "source available" (visible mais sous licence restrictive) sont les premières exposées : leur seule barrière technique vient de tomber.

Comment Claude a désassemblé son propre code en 30 minutes ?

En installant le paquet npm public de Claude Code, en repérant le fichier compilé qui constitue le cœur de l'application, puis en demandant au modèle de l'inspecter et de reconstruire une version lisible. Aucun outil de reverse engineering spécialisé n'a été nécessaire, juste un prompt bien formulé. Si un ingénieur isolé fait ça un soir, votre concurrent le mieux financé le fait à l'échelle.

À qui appartient le code que l'IA a écrit pour vous ?

C'est la question que trop d'entreprises ne se posent qu'après l'incident. Selon app.asso.fr, lorsqu'un LLM suggère du code, il pioche dans des bases d'entraînement contenant des milliards de lignes, dont certaines sous licence open source restrictive. Intégrer ce code sans vérifier sa licence peut constituer un acte de contrefaçon, et l'affaire GitHub Copilot en est l'illustration la plus citée.

Deuxième trou noir : votre logiciel garde-t-il sa protection par droit d'auteur s'il contient une part significative de code généré par IA ? La réponse dépend de l'originalité qu'il conserve, selon la même source, mais le sujet reste juridiquement mouvant. altij.fr rappelle qu'une proposition de loi visant à encadrer l'IA par le droit d'auteur a été déposée devant l'Assemblée Nationale, et que le Cyber Resilience Act européen impose depuis 2026 de nouvelles obligations de cybersécurité, avec une échéance au 11 septembre 2026 que peu d'éditeurs ont anticipée.

Si votre code contient des morceaux générés par IA sans traçabilité de leur origine, votre protection juridique est plus fragile que vous ne le pensez. C'est un point qu'on traite systématiquement dans nos contrats de mission, à distance en particulier : le sujet mérite un détour par les clauses contractuelles qui protègent réellement votre code.

Ce qui marche vraiment : la passerelle contrôlée plutôt que le blocage ou le laisser-faire

Après ces quatre constats, une évidence s'impose : bloquer l'IA sacrifie votre vélocité pour un risque qui migre vers le shadow AI non déclaré. Autoriser sans filtre cumule les quatre risques précédents d'un coup. Il existe une troisième voie, ni théorique ni coûteuse à mettre en place.

Transparence : je dirige Extra Dev, où on livre avec des développeurs seniors (huit ans d'expérience minimum, jamais moins) augmentés par l'IA sur des dépôts propriétaires de clients. Ça biaise forcément mon regard, mais ça vient avec un protocole rodé sur des dizaines de missions plutôt qu'un argumentaire abstrait.

Ce protocole tient en trois règles. Des spécifications précises avant toute session de code assisté (je pense qu'un bon projet IA part de critères d'acceptation clairs, jamais d'un prompt vague). Un découpage en blocs courts et testables, revus avant merge, jamais un agent qui touche à la production sans validation humaine. Et aucun secret en dur dans le code ni dans les prompts : les clés d'API transitent par un gestionnaire de secrets, jamais par une conversation avec un assistant.

Un projet open source repéré sur r/regolo_ai formalise une variante industrielle de cette logique : une boucle qui audite le code (scan SAST/AST, l'analyse statique qui détecte les failles sans l'exécuter), mémorise les contraintes architecturales, exige une approbation humaine avant tout patch, puis revalide en zero-trust (aucune confiance par défaut) avant fusion. Même esprit côté passerelles commerciales comme Tutela, qui inspectent le trafic vers les assistants IA et appliquent une politique (masquer une donnée sensible, avertir, bloquer) avant que la requête n'atteigne le modèle.

Quel protocole minimal avant d'autoriser un agent sur un repo propriétaire ?

Trois vérifications suffisent pour démarrer. Un, vérifiez que votre offre IA d'entreprise garantit contractuellement la non-rétention des données (zero data retention), pas seulement une promesse marketing. Deux, imposez la revue humaine sur tout code touchant à l'authentification, aux paiements ou aux données personnelles, là où le taux de vulnérabilité OWASP mesuré par Veracode pèse le plus lourd. Trois, interdisez le copier-coller de traces d'erreur brutes dans un outil grand public, en formant vos équipes sur des cas concrets plutôt que sur une charte qu'elles ne liront jamais.

Stratégie d'accès IA Risque de fuite Vélocité de livraison Coût de mise en place Tendance
Blocage total des outils IA Faible en surface, fort en shadow IA non déclaré Ralentie, retour aux méthodes manuelles Nul en outillage, fort en frustration équipe ↓ abandon progressif
Accès libre sans filtre Élevé, exposition directe des secrets et du code Maximale à court terme Nul, mais coût caché en incident ↓ risque croissant
Passerelle contrôlée + specs claires Réduit, données sensibles filtrées avant l'IA Élevée, comparable à l'accès libre Modéré, outillage + process ↑ adoption entreprise

SOURCE : Vidéos H2H Technology, transcripts cités, Kaspersky/Veracode · MAJ 08/2026

« Le vrai sujet avec un agent IA n'est pas son intelligence, c'est sa fiabilité opérationnelle : qui approuve quoi, où vont les secrets, et ce qui se passe quand ça plante. »

Vincent, Août 2026

Un dev senior qui pilote une équipe augmentée par l'IA vaut souvent mieux qu'une équipe classique plus nombreuse, à condition de savoir exactement quoi laisser faire à l'agent et quoi garder sous contrôle humain, un sujet que je développe dans le développeur augmenté et ce qu'il change pour un budget de mission.

Le verdict : ne bloquez pas, encadrez

La réponse à "faut-il autoriser l'IA sur du code propriétaire" est oui, mais jamais sans passerelle de contrôle. Bloquer déplace le risque vers le shadow AI que vous ne verrez jamais venir. Laisser faire sans filtre cumule les quatre risques détaillés plus haut : fuite par prompt, code vulnérable une fois sur deux, obfuscation qui ne protège plus rien, statut juridique incertain.

Le critère de décision est simple : si votre équipe traite des données clients sensibles ou du code à forte valeur concurrentielle, mettez en place une passerelle contrôlée et une revue humaine avant la fin du trimestre, pas après le premier incident. Si votre exposition est faible, un cadrage plus léger avec formation des équipes suffit. Dans les deux cas, le secret n'est plus une stratégie viable : c'est le processus qui protège votre code, pas la compilation.

Foire aux questions

Peut-on empêcher totalement une fuite de code propriétaire vers un assistant IA ?

Non, pas à 100%, mais une passerelle qui inspecte le trafic avant qu'il n'atteigne le modèle et filtre les identifiants réduit drastiquement le risque. Le blocage total pousse simplement l'usage vers des outils non déclarés, pire que l'absence de contrôle.

Le code généré par une IA comme Copilot ou Claude Code peut-il être protégé par le droit d'auteur ?

Ça dépend de l'originalité que conserve le logiciel final : un logiciel qui reste "original" garde sa protection même s'il contient du code assisté par IA. Le flou juridique porte surtout sur la part générée automatiquement et sur le respect des licences des sources d'entraînement du modèle.

L'obfuscation du code sert-elle encore à quelque chose face à des LLM récents ?

Elle ralentit un attaquant humain isolé, mais ne protège plus contre un LLM avec une fenêtre de contexte suffisante, capable de désassembler du code minifié en quelques dizaines de minutes. Votre vraie protection vient du contrat et du contrôle d'accès, pas du secret technique seul.

Faut-il interdire Claude Code ou Copilot à ses développeurs par précaution ?

Non, l'écart de productivité est trop coûteux à laisser filer et l'interdiction déplace simplement l'usage vers du shadow AI incontrôlé. Autorisez ces outils via un canal surveillé, avec des règles claires sur ce qui transite dans un prompt et une revue humaine sur le code sensible.

Quel est le coût réel d'un incident de fuite de code propriétaire via l'IA ?

Il dépend du secteur, mais l'exemple Samsung montre qu'une fuite peut devenir irrécupérable en quelques semaines, sans compter le temps d'investigation interne. Le coût d'une passerelle de contrôle reste généralement inférieur au coût d'un seul incident sérieux.

Sources