Les développeurs ne coderont plus, c'est acté. Les scénarii de plateformes et de produits s'élaborent, se déclinent en user-stories, se valident en COPROJ et partent en BUILD, en itérations, en N-levels de staging, en démos plus ou moins réussies et dans une quantité impossible à calculer, en RUN si le produit arrive à se vendre.

Mais nous qui eûmes l'habitude de travailler au plus près des entrailles fonctionnelles de ces mécaniques modernes ne voyons ou ne verrons plus de code à très courte échéance.

Les agents s'en chargent, de façon plus ou moins organisée selon la qualification requise et les exigences du produit.

Cette question ou disons ce "sujet agentique", si elle peut faire débat sur ses modalités opérationnelles et le choix des acteurs qu'elle embarque, n'appartient ou ne devrait plutôt jamais être arbitrée à la main seule de l'équipe de développement. C'est pour ça que les RSSI, DSI, et autres capos finissants en "SI" existent et sont en responsabilité supposée.

Car on le sait, si gouverner c'est prévoir, décider c'est savoir et l'avenir immédiat n'a jamais été aussi incertain.

Pour contextualiser davantage et avancer sur la problématique des "clés", je vais établir le postulat suivant :

  • Toute structure qui se positionne sur un marché de service numérique doit intégrer l'IA dans ses processus pour rester concurrentielle.
  • Ce changement structurel ne peut se faire à l'échelle que par l'utilisation d'inférences de haute performance.
  • Le seul accès possible à ces inférences est la consommation de flux de production d'IA externalisées à des sociétés et infrastructures elles-mêmes soumises à une concurrence, une accélération technologique et à un contexte régulatoire hyper-soutenu.

C'est dans ce maelstrom que se posent impérieusement les deux questions qui vont structurer cette note :

  • Comment garantir que les chaînes de secrets sont conservées ?
  • Comment s'assurer que la propriété intellectuelle ne fuie pas à la discrétion d'un opérateur technique jusque dans les mains d'un concurrent ou d'un agent malveillant ?

L'essentiel en cinq points

  1. Le vrai sujet n'est pas le choix d'un modèle, mais la maîtrise de la frontière de confiance entre le SI et les fournisseurs d'inférence.
  2. Deux menaces distinctes doivent être traitées ensemble : la perte de contrôle des chaînes de secrets et la fuite du patrimoine informationnel.
  3. La réponse technique tient dans un point de contrôle unique, l'AI Privacy Gateway : classification, détection de secrets, DLP, politique, tokenisation, audit.
  4. La réponse organisationnelle tient dans la séparation de cinq responsabilités et dans une qualification contractuelle des fournisseurs au niveau d'un sous-traitant critique.
  5. Le critère de réussite n'est pas la détection, c'est la non-contournabilité : l'IA externe traite une représentation contrôlée de l'information, jamais la capacité de récupérer elle-même le secret réel.

Deux questions, un même point de rupture

Les deux questions n'ont pas le même objet. La première porte sur la conservation d'un pouvoir d'accès. La seconde porte sur la discrétion d'un patrimoine. Pourtant, toutes deux se décident au même endroit : le point où les outils internes envoient du contenu à un fournisseur d'inférence externe.

La première est une question de bastion. Qui détient les secrets, qui peut les reconstituer, selon quelles règles, avec quelles rotations et quelles traces. La chaîne est rompue dès qu'un seul maillon peut restituer une valeur sans contrôle : un fichier .env sur un poste, une variable d'environnement en clair dans une chaîne d'intégration, un mot de passe collé dans un prompt pour aller plus vite.

La seconde est une question de périmètre informationnel. Code propriétaire, architectures, données clients, méthodes, listes, grilles tarifaires. Le risque ne consiste pas en un accès illégitime, c'est la réutilisation : chez un concurrent, dans l'entraînement d'un modèle, ou par un sous-traitant qui n'était pas déclaré dans la chaîne contractuelle.

Ces deux questions se rejoignent sur un point : les outils d'IA génératifs, agents, environnements de développement et pipelines, sont devenus des sorties réseau qui écrivent vers l'extérieur, souvent avec l'autorisation implicite des équipes techniques. Le poste de développement est le nouveau périmètre de sécurité, et la clé d'API du fournisseur est le nouveau vecteur de contournement.

Pour un COMEX, l'arbitrage devient une décision d'architecture de confiance.

La méthode en quatre temps

Une réponse crédible tient en quatre temps, chacun avec un livrable et une décision explicite. Un dispositif qui saute une étape produit soit un document sans effet, soit une barrière contournée en trois jours.

  1. Cartographier. Inventorier les outils et les agents qui parlent à des modèles externes, les points d'appel, les fournisseurs, les données réellement envoyées. Livrable : la cartographie des flux IA. Décision : le périmètre des usages autorisés.
  2. Classifier. Nommer les actifs. Secrets techniques, données à caractère personnel, données réglementées, code et savoir-faire. Définir ce qui est interdit de sortie, ce qui peut sortir pseudonymisé, ce qui peut sortir librement. Livrable : la nomenclature et la liste des données interdites de sortie. Décision : les seuils et les règles opposables.
  3. Interposer. Placer un point de contrôle unique entre les outils et les fournisseurs, séparer les responsabilités, tokeniser ce qui doit transiter. Livrable : l'architecture cible et la politique d'usage. Décision : le choix des briques et leur hébergement.
  4. Prouver. Tester les fuites de façon adversariale, journaliser, qualifier les fournisseurs, constituer un dossier d'audit. Livrable : des preuves reproductibles. Décision : l'autorisation de mise en production et les conditions de réversibilité.

Cinq responsabilités à ne pas confondre

La première erreur de conception consiste à demander à un coffre-fort de faire la police. Un gestionnaire de secrets conserve et restitue des valeurs. Il n'inspecte pas des flux, ne décide pas d'une sortie et ne remplace pas un dispositif de prévention des fuites. Confondre les deux crée un point de rupture unique : le jour où le coffre est mal configuré ou compromis, toute la chaîne de contrôle tombe avec lui.

Il faut donc séparer cinq fonctions, avec cinq propriétaires et cinq budgets.

  • Conserver : Secret Manager ou Vault. La fonction garantit que les secrets réels ne quittent jamais le périmètre de confiance.
  • Détecter : Secret Scanner et DLP. La fonction garantit qu'aucune valeur sensible ne franchit la frontière sans être vue.
  • Décider : Policy Engine. La fonction garantit que chaque flux reçoit une règle explicite : autoriser, tokeniser, masquer, bloquer, journaliser.
  • Transformer : tokenisation ou rédaction. La fonction garantit que le fournisseur reçoit une représentation utile mais non réelle.
  • Tracer : audit et SIEM. La fonction garantit que chaque franchissement est enregistré, attribuable et révisable.

Figure 1 - Cinq responsabilités, cinq composants, cinq propriétaires

Le pipeline qui en résulte est linéaire et lisible. L'outil de développement ou la chaîne d'intégration appelle le point de contrôle. La détection qualifie. La politique tranche. La transformation applique. L'appel externe part avec une représentation contrôlée. Le retour est contrôlé. Tout est journalisé. Chaque maillon peut être audité indépendamment des autres.

L'AI Privacy Gateway, point de contrôle

L'architecture de référence interpose une passerelle, l'AI Privacy Gateway, entre les outils internes (environnements de développement, agents, scripts, pipelines d'intégration) et les fournisseurs d'IA. Elle porte six capacités : classification, détection de secrets, prévention des fuites, moteur de politique, tokenisation, audit. Le gestionnaire de secrets reste le coffre-fort. Le SIEM reçoit les traces. Le principe directeur est simple : aucune donnée classifiée comme interdite ne franchit la frontière de confiance, et les secrets réels restent dans le SI maîtrisé.

Figure 2 - Frontière de confiance : la passerelle contrôle ce qui sort, le coffre conserve ce qui ne sort pas

Dans la version cible d'un poste de développement, l'assistant de code ne parle plus directement au fournisseur. Il s'adresse à un point d'appel local ou maîtrisé, la passerelle décide, et seule la représentation autorisée sort. La production ajoute une règle réseau : l'accès direct aux points d'appel des fournisseurs est interdit depuis les postes et depuis la chaîne d'intégration.

Une politique de sécurité qui dépend uniquement de la bonne volonté du développeur ou de la configuration de son outil n'est pas une politique. C'est une recommandation.

Pseudonymiser plutôt que renoncer

La technique centrale est la tokenisation réversible. Les valeurs sensibles sont remplacées par des jetons, le fournisseur raisonne sur les jetons, et la table de correspondance reste dans le périmètre de confiance. La variante déterministe est particulièrement utile : la même valeur produit le même jeton, si bien que le modèle peut raisonner sur la cohérence des données sans jamais connaître leur contenu.

Un fichier de configuration contenant un hôte, un utilisateur et un mot de passe part ainsi sous une forme abstraite :

  • DB_HOST=10.20.15.42 devient DB_HOST=<DB_HOST_001>
  • DB_USER=application_prod devient DB_USER=<DB_USER_002>
  • DB_PASSWORD=xxxxxxxxxxxxxxxx devient DB_PASSWORD=<DB_PASSWORD_003>

La correspondance reste locale : <DB_HOST_001> vers la valeur réelle, <DB_USER_002> vers la valeur réelle, <DB_PASSWORD_003> vers la valeur réelle. La ré-identification demeure locale et contrôlée. Elle n'est jamais déléguée au modèle.

Skyflow documente cette architecture : détection, remplacement par des jetons déterministes, traitement par le modèle, puis ré-identification contrôlée. Protegrity documente également des mécanismes de protection par tokenisation destinés aux usages avec des agents IA. Ces briques ne dispensent pas d'un principe de réalité. Tokeniser les secrets ne rend pas le contexte métier anonyme : le contenu reste exploitable, parfois sensible. D'où la nécessité d'une défense en profondeur, qui combine le coffre, la tokenisation, la prévention des fuites, la politique, le contrôle réseau, la journalisation et la revue humaine.

Quatre familles d'acteurs, aucune solution unique

Le marché fournit déjà les briques. Quatre familles suffisent à structurer une comparaison.

  • Skyflow : Privacy Vault, tokenisation et mécanismes de désidentification et de ré-identification contrôlée pour les usages LLM.
  • Protegrity : protection industrielle des données et tokenisation à l'échelle du pipeline.
  • Nightfall AI : prévention des fuites et de l'exfiltration, avec une orientation agents IA et agents de code.
  • Cloudflare AI Gateway : médiation, observabilité, contrôle des flux et prévention des fuites, avec une documentation explicite de l'intégration des agents de code.

Figure 3 - Quatre familles de briques, quatre périmètres de responsabilité

Deux pièges doivent être connus. D'abord, une passerelle en mode service hébergé ne constitue pas automatiquement une frontière de confiance locale. Pour un système fortement régulé, il faut examiner précisément le traitement des données, la juridiction, la rétention et la chaîne des sous-traitants. Ensuite, la nationalité d'un fournisseur ne renseigne pas, à elle seule, sur le niveau de risque. Elle ne dit rien des infrastructures réellement utilisées, des sous-traitants mobilisés ni des flux techniques. Un fournisseur français ne signifie pas un risque maîtrisé par défaut.

Qualifier le fournisseur comme un sous-traitant critique

Le dispositif technique ne tient pas sans dispositif contractuel. Pour chaque fournisseur d'IA, la fiche de qualification doit établir au minimum douze points : juridiction, localisation des traitements, sous-traitants, transferts internationaux, rétention, réutilisation des prompts, entraînement sur les données, logs, accès humain, suppression, notification d'incident et réversibilité.

Figure 4 - Douze points à établir pour chaque fournisseur d'IA

Ces points deviennent des clauses opposables et des critères de revue. La réversibilité mérite une attention particulière : sans plan de sortie documenté et testé, la dépendance à un fournisseur devient un risque de gouvernance, et plus seulement un risque technique. La qualification n'est d'ailleurs pas un document signé une fois pour toutes. Elle se révise à chaque changement d'offre, de sous-traitant ou de régime juridique.

Dernier point de calendrier, et il élargit la portée de tout ce qui précède. À partir du 9 décembre 2026, la directive (UE) 2024/2853 sur la responsabilité du fait des produits défectueux intègre explicitement le logiciel dans la définition du produit, quelle que soit sa forme de fourniture : installé, accessible par réseau, hébergé dans le cloud ou proposé en SaaS. Le fournisseur d'un système d'IA au sens du règlement européen est traité comme un fabricant, et seuls les logiciels libres développés hors de toute activité commerciale restent exclus.

Un produit qui apprend ou acquiert de nouvelles fonctionnalités après sa mise sur le marché pourra être déclaré défectueux pour des comportements postérieurs à la commercialisation. L'absence d'une mise à jour de sécurité restée sous le contrôle du fabricant pourra constituer un défaut. Une vulnérabilité de cybersécurité pourra suffire, à elle seule, à engager la responsabilité civile. Le fabricant répond également des composants tiers qu'il intègre ou présente comme partie de son produit, et la victime pourra rechercher simultanément le fabricant, le fabricant du composant, l'importateur, le mandataire ou le prestataire d'exécution.

La transposition française n'était pas publiée à l'été 2026 et le régime de 1985 continue de s'appliquer, mais le sens de la réforme est fixé, et la franchise de 500 euros disparaîtra, avec notamment un délai butoir de 25 ans pour certains dommages corporels tardifs. Pour la gouvernance décrite dans cette note, la conséquence est directe : la fiche de qualification fournisseur cesse d'être un document de conformité et devient une pièce de défense contractuelle. Entre professionnels, la directive ne couvre pas les pertes économiques pures : c'est le contrat qui répartira le risque, et ce sont donc les garanties de sécurité, les obligations de correction des vulnérabilités, la durée du support, la notification d'incident, l'accès aux informations techniques et les plafonds de responsabilité qu'il faut écrire dès maintenant.

Prouver par les tests

Un dispositif non testé est une hypothèse, pas une protection. La batterie adversariale minimale couvre douze familles : clé d'API, mot de passe, clé privée, jeton JWT, fichier .env, identifiants cloud, données personnelles, code propriétaire, tentative d'exfiltration par le prompt, tentative de ré-identification, secret généré dans la réponse du modèle et secret présent dans un appel d'outil.

Figure 5 - Batterie minimale de douze tests adversariaux, du staging à la production

Le staging se conduit avec de faux secrets et de vrais dépôts de test. La préproduction introduit les environnements et les politiques définitives, avec une revue documentée des faux positifs. La production applique la règle réseau. Deux critères président à la décision de mise en production. Premier critère : à aucun moment le fournisseur externe ne reçoit une donnée classifiée comme secrète.

Un développeur ne doit pas pouvoir contourner la passerelle simplement parce qu'il possède une clé d'API du fournisseur. C'est ce second point qui transforme un bricolage de sécurité en architecture de sécurité.

Trajectoire et portes de décision

Pour une PME ou une organisation régulée, la trajectoire réaliste tient en quatre étapes : POC, staging, préproduction, production. Le POC n'exige pas une plateforme complète. Un poste, une passerelle locale, un coffre, un point d'appel compatible et une batterie de tests suffisent à démontrer la valeur. Cette démonstration porte sur la chaîne entière : détection, décision, transformation, appel externe, contrôle du retour, audit.

Chaque étape se franchit sur critères. Détection conforme sur les douze familles de tests. Zéro secret franchissant la frontière en configuration de test. Non-contournabilité démontrée, y compris avec une clé d'API valide. Journaux exploitables. Faux positifs revus et documentés. Fiche de qualification signée. Plan de sortie disponible. Une étape franchie sans preuve n'est pas franchie.

Ce que le COMEX doit trancher

Les choix techniques sont cadrés. Les décisions qui restent sont des décisions de direction :

  1. Périmètre : quels usages d'IA externe sont autorisés, pour quels métiers, avec quels outils.
  2. Architecture : point de contrôle unique obligatoire, et interdiction des appels directs aux fournisseurs depuis les postes et la chaîne d'intégration.
  3. Données et secrets : classification officielle, liste des interdits de sortie, tokenisation par défaut, coffre de référence unique.
  4. Fournisseurs : grille de qualification obligatoire, revue périodique, clauses de réversibilité.
  5. Preuve : journalisation, tests adversariaux récurrents, dossier d'audit tenu à jour.
  6. Responsabilités : un propriétaire par fonction, un comité de revue, une politique d'usage opposable.
  7. Budget et trajectoire : financer les briques, le POC et la sortie, pas seulement l'abonnement au modèle.

Aucune de ces décisions n'exige d'attendre le prochain cycle technologique. Toutes sont exécutables avec les briques disponibles aujourd'hui.

Réponses aux deux questions

Conserver les chaînes de secrets. En traitant le bastion des secrets comme une architecture, pas comme une discipline individuelle. Un coffre de référence unique. Aucun secret en clair dans les dépôts, les configurations ou les prompts. Tokenisation de tout ce qui doit transiter. Rotations tracées. Journalisation des accès. La chaîne est conservée tant qu'aucun maillon ne peut reconstituer seul la valeur réelle.

Empêcher la fuite du patrimoine informationnel. En réduisant la surface de sortie à une représentation contrôlée. Classification, prévention des fuites, politique, tokenisation, qualification contractuelle des fournisseurs, tests adversariaux, journalisation et revue humaine. L'IA externe ne reçoit jamais la capacité de récupérer elle-même le secret réel, et le contournement est rendu impossible par le réseau et par la politique, pas par la seule bonne volonté. La fuite devient alors un événement détectable, traçable et imputable.

La question n'est plus de savoir si nos équipes utiliseront des IA externes. Elles les utilisent déjà. La question est de savoir si l'organisation reprend la main sur la frontière de confiance, ou si elle laisse la frontière décider à sa place.

Sources et références