Secrets, licences et conformité code

Pourquoi ce chapitre compte

Un assistant IAintelligence artificielleIAEnsemble des techniques permettant à un programme d'accomplir une tâche qui demanderait de l'intelligence humaine. Le terme couvre aussi bien les systèmes à règles écrites que ceux qui apprennent de données.Voir dans le glossaire intégré à l'environnement de développement n'est pas un outil isolé : c'est un canal de sortie vers un tiers. Chaque promptpromptIAConsigne ou contexte fourni à un modèle de langage pour orienter sa réponse. La qualité du prompt conditionne souvent la qualité du résultat.Voir dans le glossaire envoyé, chaque fichier collé pour obtenir de l'aide, chaque extrait de code généré transite par une infrastructure qui n'appartient pas à l'entreprise. Deux familles de risques en découlent, distinctes mais souvent confondues : la fuite d'informations sensibles — secrets techniques, donnéesdonnéesIAEnsemble d'informations structurées ou non utilisées pour entraîner, évaluer ou alimenter un modèle. La qualité, la quantité et la représentativité des données sont les facteurs décisifs pour les performances en apprentissage automatique.Voir dans le glossaire clients, code propriétaire — et la contamination par des licences incompatibles, lorsque le code produit reproduit, sciemment ou non, des fragments protégés par une licence copyleft.

Ce chapitre ne traite pas de sécurité applicative au sens large. Il traite spécifiquement de ce qui se joue entre le clavier du développeur et le modèle : ce qui part, ce qui revient, et ce qui reste tracé quelque part sur des serveurs qu'on ne contrôle pas.

Un secret collé dans un prompt a quitté le périmètre de l'entreprise au moment de l'envoi, indépendamment de ce que devient la réponse. La rotation de la clé n'est pas une option parmi d'autres après un tel incident : c'est la seule réponse qui neutralise réellement le risque.

Ce qui part réellement dans un prompt

Secrets techniques

La fuite la plus fréquente est aussi la plus banale : un développeur colle un extrait de fichier de configuration pour demander de l'aide sur une erreur de connexion, et ce fichier contient une clé d'API, un mot de passe de base de données ou un tokentokenIAFragment de texte manipulé par un modèle de langage, généralement plus court qu'un mot — trois à quatre caractères en français. La tarification et la limite de contexte se comptent en tokens.Voir dans le glossaire d'accès resté en clair. Le même scénario se reproduit avec les traces d'erreur (stack traces) qui embarquent parfois des identifiants de session, ou avec des captures d'écran de terminal partagées dans le chat d'un assistant pour illustrer un bug.

Ce n'est pas un problème de discipline individuelle uniquement. C'est un problème d'ergonomie : demander de l'aide sur un bug de connexion pousse naturellement à fournir le contextefenêtre de contexteIAQuantité de texte qu'un modèle peut prendre en compte simultanément : question, documents fournis et historique. Au-delà, les éléments les plus anciens sortent du champ.Voir dans le glossaire complet, y compris les identifiants, parce que c'est ce qui rend le problème reproductible. L'assistant ne signale presque jamais qu'une valeur ressemble à un secret ; il traite le prompt comme un tout homogène.

Code propriétaire et données métier

Le second cas de figure est plus insidieux parce qu'il ne concerne pas un identifiant isolé mais un bloc de logique métier entier. Un développeur qui demande à un assistant de refactoriser un algorithme de tarification, un moteur de scoring interne ou une logique de matching propriétaire transmet, de fait, un savoir-faire qui peut constituer un avantage concurrentiel. Rien de "secret" au sens technique du terme — pas de clé, pas de mot de passe — mais une information dont la valeur tient précisément à sa confidentialité.

La plupart des fournisseurs conservent les requêtes API pendant une durée définie contractuellement — souvent 30 jours par défaut — pour la modération d'abus et le support technique. Cela signifie qu'un secret envoyé une seule fois reste lisible par des tiers humains (équipes support, sous-traitants) pendant cette fenêtre, même si le produit final ne l'exploite jamais.

Le cas particulier des agents autonomes

Les agentsagentIASystème qui enchaîne des appels d'outils de façon autonome pour atteindre un objectif : il planifie, agit, observe, recommence. Sa fiabilité décroît exponentiellement avec le nombre d'étapes.Voir dans le glossaire de code qui lisent et modifient des fichiers de façon autonome élargissent la surface de risque, car ils n'attendent pas qu'un humain sélectionne un extrait pertinent : ils parcourent l'arborescence du projet et peuvent inclure dans leur contexte des fichiers .env, des clés SSHSSHRéseauxProtocole sécurisé d'accès distant à un serveur, chiffrant session et authentification (clé ou mot de passe).Voir dans le glossaire stockées localement ou des dumps de base de données de test laissés par mégarde dans le dépôt. Un agent configuré avec un accès large au système de fichiers et sans liste d'exclusion explicite est structurellement plus dangereux qu'un assistant de complétion classique.

La chaîne de risque : où vont les données

Le schéma ci-dessous résume le trajet d'un prompt depuis le poste du développeur jusqu'aux systèmes du fournisseur, et situe les points où une politique de gouvernance peut intercepter le risque avant qu'il ne se matérialise.

Quatre leviers reviennent systématiquement dans les dispositifs de mitigation efficaces : un scanner de secrets qui bloque le commit avant même que le code n'atteigne un dépôt partagé, un contrat de rétention zéro négocié avec le fournisseur, un filtrage de licence sur le code généré avant fusion, et une politique d'usage qui définit noir sur blanc quels outilstool callingIACapacité d'un agent ou d'un LLM à invoquer des outils externes (API, calcul, recherche) pendant le raisonnement.Voir dans le glossaire sont autorisés sur quel type de données.

Licences et code généré par IA

Le risque de copyleft

Les modèles de génération de code sont entraînés sur de très larges corpus incluant du code open source sous des licences très diverses : permissives (MIT, Apache 2.0, BSD), qui autorisent une réutilisation quasiment sans contrainte, et copyleft (GPL, AGPL, LGPL), qui imposent que tout logiciel dérivé soit lui-même distribué sous les mêmes termes. La AGPL va plus loin encore : elle étend cette obligation aux services accessibles par réseau, sans même nécessiter de distribution du binaire.

Le problème pour une entreprise qui développe un produit propriétaire est direct : si un assistant reproduit, même partiellement, un fragment de code issu d'un projet sous licence copyleft, ce fragment peut légalement engager l'obligation de publier le code source du produit qui l'intègre. Le raisonnement juridique exact varie selon les juridictions et fait encore l'objet de débats devant les tribunaux, mais le risque contractuel et réputationnel, lui, est réel dès aujourd'hui.

Un développeur demande à un assistant d'implémenter un algorithme de tri spécifique peu commun. Le modèle produit une fonction qui correspond presque trait pour trait à une implémentation existante d'un dépôt GitHub sous licence GPL, y compris les noms de variables et la structure des commentaires. Ce n'est pas une hypothèse : ce type de correspondance a été documenté dans plusieurs analyses publiques de sorties de modèles de code, en particulier sur des algorithmes classiques ou peu réécrits dans le corpus d'entraînement.

Pourquoi ce risque est difficile à détecter à l'œil

La reproduction verbatim est rare mais pas nulle, et surtout, elle est indétectable par une simple relecture humaine : un développeur qui reçoit une fonction fonctionnelle n'a aucun moyen de savoir, en la lisant, si elle constitue une paraphrase originale ou une copie quasi identique d'un fragment protégé. Le style de code produit par un modèle est délibérément "générique" — conventions de nommage standard, structure classique — ce qui rend la ressemblance avec du code existant à la fois plus probable statistiquement et plus difficile à repérer visuellement.

Provenance et attribution

Au-delà du risque de copie exacte, se pose une question plus large de provenance : un code généré n'a, par construction, aucune métadonnée d'attribution. Impossible de savoir a priori de quel corpus il dérivedériveIADégradation progressive des performances d'un modèle après son déploiement, causée par l'évolution des comportements ou du contexte. Elle impose surveillance et réentraînement.Voir dans le glossaire, sous quelle licence ce corpus était publié, ni si l'auteur original aurait consenti à cet usage. Certaines entreprises considèrent que cette absence de traçabilité est en soi un motif suffisant pour exclure le code généré par IA de certains modules sensibles — cœur de produit, composants soumis à un audit de sécurité contractuel avec un client, ou briques destinées à être elles-mêmes commercialisées sous licence.

Les conditions d'utilisation d'un fournisseur d'IA précisent en général que le client reste responsable de la conformité du code produit à ses propres obligations légales. Autrement dit, le fournisseur ne garantit pas l'absence de contamination par une licence tierce : la responsabilité de vérification reste entièrement du côté de l'entreprise qui déploie le code.

Contrats fournisseurs et rétention des données

La négociation contractuelle avec un fournisseur d'IA est le levier le plus structurant, parce qu'il agit en amont de tout usage individuel. Trois clauses méritent une attentionattentionIAMécanisme par lequel un modèle pondère l'importance de chaque token du contexte lorsqu'il en traite un autre, quelle que soit la distance qui les sépare.Voir dans le glossaire particulière avant toute généralisation d'un outil dans une équipe :

• Zero data retention (ZDR) — le fournisseur s'engage contractuellement à ne pas conserver le contenu des requêtes au-delà du traitement immédiat, ou à les supprimer sous un délai très court (24 à 48 heures typiquement), sans les rendre accessibles au support.
• Opt-out training — garantie explicite que les prompts et réponses ne seront jamais utilisés pour ré-entraîner ou affiner un modèle, y compris pour un usage futur du même fournisseur. Cette clause est distincte de la rétention : un fournisseur peut supprimer les logs après 30 jours tout en ayant déjà utilisé les données pour de l'entraînement dans l'intervalle.
• Localisation et sous-traitance — savoir sur quelle infrastructure (région, sous-traitant technique) transitent les données, en particulier pour les entreprises soumises à des contraintes réglementaires sectorielles (santé, finance, défense).

Ces clauses existent presque toujours dans les offres destinées aux entreprises, mais rarement par défaut dans les offres grand public ou les niveaux d'abonnement individuels. C'est un point de vigilance concret : un développeur qui utilise un compte personnel plutôt que le compte professionnel négocié par l'entreprise se retrouve, souvent sans le savoir, hors du périmètre contractuel censé le protéger.

Politiques et gouvernance en entreprise

Une politique d'usage IA efficace ne se limite pas à une liste d'interdictions. Elle doit répondre à quatre questions opérationnelles :

La première erreur courante est de publier une politique restrictive sans alternative outillée : interdire tout assistant IA sans fournir de solution conforme pousse les équipes vers un usage "gris", via des comptes personnels non déclarés, ce qui aggrave le risque au lieu de le réduire. La politique la plus efficace observée en pratique associe systématiquement une interdiction à une alternative validée.

Plutôt que d'autoriser ou interdire un outil dans son ensemble, il est souvent plus opérationnel de segmenter par type de code : un assistant peut être pleinement autorisé sur des modules déjà open source ou génériques, et restreint ou interdit sur les modules qualifiés de propriétaires critiques. Cette granularité évite de sacrifier la productivité sur l'ensemble du code pour protéger une fraction seulement.

Outils de détection et prévention

La gouvernance déclarative ne suffit pas sans outillage technique qui l'applique automatiquement. Trois catégories d'outils couvrent l'essentiel du périmètre :

• Scanners de secrets (gitleaks, trufflehog, detect-secrets) — s'exécutent en pre-commit ou en pipeline CI, et bloquent l'intégration d'un fichier contenant un motif reconnu comme une clé, un token ou un mot de passe. Ils ne détectent pas les fuites qui se produisent au niveau du prompt lui-même, seulement celles qui atterrissent dans le code versionné.
• Outils de Software Composition Analysis (SCA) — comparent le code du dépôt à des bases de fragments open source connus pour repérer une correspondance suspecte avec du code sous licence copyleft. Certains fournisseurs d'assistants IA intègrent désormais ce filtrage directement dans l'outil de génération, en bloquant ou signalant les suggestions qui correspondent trop étroitement à une source identifiée.
• Proxies et passerelles IA d'entreprise — interceptent les requêtes sortantes vers les fournisseurs d'IA pour appliquer une politique de filtrage centralisée (blocage de motifs sensibles, journalisation, restriction par équipe), indépendamment de la discipline individuelle de chaque développeur.

Aucun de ces outils n'est suffisant isolément. Un scanner de secrets pre-commit n'empêche pas la fuite qui s'est déjà produite au moment du prompt ; un filtrage SCA sur le dépôt n'empêche pas un développeur de coller du code propriétaire dans un chat externe. La combinaison des trois, articulée avec une politique claire, réduit la surface de risque sans dépendre uniquement de la vigilance individuelle.

Checklist avant déploiement

Avant de généraliser un assistant IA à une équipe de développement, les points suivants méritent une vérification explicite :

1. Le contrat avec le fournisseur inclut-il une clause de rétention zéro et d'opt-out training ?
2. Un scanner de secrets est-il actif en pre-commit et en CI sur l'ensemble des dépôts concernés ?
3. Une politique écrite précise-t-elle quels types de code et de données peuvent être soumis à l'assistant ?
4. Les comptes utilisés sont-ils des comptes professionnels sous contrat négocié, et non des comptes personnels ?
5. Un outil de SCA ou un filtrage de licence est-il en place pour le code généré avant fusion ?
6. Une procédure de rotation de secrets existe-t-elle et est-elle connue de l'équipe en cas de fuite avérée ?
7. Les modules qualifiés de critiques ou soumis à des accords de confidentialité tiers sont-ils explicitement exclus du périmètre d'usage de l'assistant ?

Cette liste n'a pas vocation à être exhaustive pour toutes les organisations : sa valeur est de servir de filtre minimal avant tout déploiement à l'échelle, pas de remplacer une analyse de risque adaptée au contexte réglementaire et contractuel spécifique de l'entreprise.