Gouvernance IA : cartographie des flux et accès pour données sensibles

Table des matières :

La cartographie des flux IA, un prérequis dès que les données deviennent sensibles
Ce qu’il faut distinguer avant de dessiner : hébergement, juridiction, modèle, réversibilité
Partir du cas d’usage pour produire une cartographie exploitable (pas un schéma décoratif)
Cartographie des accès : du « qui utilise l’outil » au « qui peut techniquement voir la donnée »
Particularités IA générative : invites, RAG, réglage fin et journaux, quatre flux souvent oubliés
Transformer la cartographie en contrôles : indicateurs, tests, preuves et revues
Exemple réaliste : une ETI du BTP qui déploie un assistant IA, et ce que la cartographie révèle
Clauses et questions à rattacher directement à la cartographie (sans se perdre dans l’abstrait)
Prochaine étape concrète : un sprint de cartographie « flux + accès » en 10 jours

La cartographie des flux IA, un prérequis dès que les données deviennent sensibles

La gouvernance IA désigne l’ensemble des règles, rôles et contrôles qui encadrent l’usage de l’intelligence artificielle dans une organisation, depuis les données d’entrée jusqu’aux décisions et aux journaux techniques. Dès que l’on manipule des données sensibles (données personnelles, informations financières, secrets d’affaires, données de santé, plans d’infrastructure, etc.), la question n’est plus seulement « quel outil d’IA choisir ? », mais « où passent les données, qui y accède et pendant combien de temps ? ».

En pratique, « sensibles » ne signifie pas uniquement « données réglementées ». Cela inclut aussi des contenus qui deviennent sensibles par contexte : une note d’audit interne, une liste de sous-traitants, des conditions commerciales, un compte rendu d’incident, ou un export de tickets support contenant des identifiants et des traces techniques. Avec l’IA générative, ces contenus se retrouvent facilement dans des invites, des pièces jointes, des captures ou des copier-coller — parfois en dehors des circuits documentaires habituels (GED, ECM, dossiers projet).

La cartographie des flux est la représentation documentée des mouvements de données entre systèmes, applications et tiers, incluant les traitements (transformation, stockage, inférence, indexation). Elle sert à éviter deux angles morts fréquents : les transferts invisibles vers des sous-traitants (télémétrie, anti-fraude, support) et les copies locales non maîtrisées (exports, captures, connecteurs, extensions de navigateur). Dans un contexte IA, ces angles morts augmentent, car un assistant conversationnel ou un service d’inférence agrège souvent plusieurs briques techniques (API LLM, filtrage, modération, moteur RAG, stockage, observabilité, outils d’admin).

Deux rappels utiles pour ancrer cet exercice « gouvernance » dans du concret :

Une cartographie n’est pas un dessin : c’est une liste de flux (entrées/sorties) assortie de preuves (config, journaux, contrat, documentation fournisseur, captures d’écran d’admin) et d’un propriétaire par flux.
Si vous êtes soumis au RGPD, la cartographie des flux IA s’aligne naturellement avec les obligations d’accountability, notamment le registre des activités de traitement (article 30) et, selon les cas, l’analyse d’impact (article 35) : ce n’est pas du conseil juridique, mais un bon moyen d’éviter de multiplier les documents incohérents. Texte officiel : Règlement (UE) 2016/679 (RGPD) — EUR-Lex.

Enfin, la cartographie n’est pas un exercice de conformité « pour le dossier ». C’est un outil de pilotage : elle aide à arbitrer entre rapidité de déploiement, exposition des données et dépendance au fournisseur. Dans la pratique, un schéma clair des flux et des accès permet de décider quels cas d’usage peuvent partir sur un service externe, lesquels nécessitent un environnement isolé, et quels contrôles minimaux imposer avant l’ouverture à grande échelle.

Ce qu’il faut distinguer avant de dessiner : hébergement, juridiction, modèle, réversibilité

L’hébergement est le lieu technique où les données sont stockées et traitées (centre de données, région cloud, environnement interne). La juridiction applicable est l’ensemble des lois et tribunaux compétents qui peuvent s’appliquer au fournisseur et au contrat, indépendamment du lieu d’hébergement. Ces deux notions sont souvent confondues, alors qu’elles répondent à des risques différents : localisation opérationnelle d’un côté, cadre légal et demandes d’accès de l’autre.

Pour éviter les discussions abstraites, vous pouvez poser ces notions sous forme de questions vérifiables (avec le type de preuve attendu) :

Dimension	Question opérationnelle	Exemple de preuve utile
Hébergement	Dans quelle région sont traitées les invites, sorties, logs, index vectoriels ?	Paramètres d’admin (région), architecture, clauses d’hébergement
Juridiction	Quelle entité contracte, et quel droit/tribunal est prévu au contrat ?	Contrat, DPA, annexes, conditions de service
Modèle	Qui contrôle les versions, garde-fous, politiques d’usage, et comment le changement est notifié ?	Notes de version, politiques, options d’admin, journal des changements
Réversibilité	Qu’est-ce qui est exportable (données + config + preuves), dans quel format, et sous quel délai ?	Procédure d’export, formats, test d’export, engagement SLA

La maîtrise du modèle est la capacité à contrôler ce que fait le modèle d’IA (paramètres, versions, garde-fous, politiques d’entraînement, comportements), et à vérifier ce contrôle dans le temps. Elle n’est pas équivalente à l’hébergement : vous pouvez héberger un service près de vous tout en dépendant d’un modèle opaque, ou au contraire exécuter un modèle maîtrisé dans un cloud externe. En IA générative, cette maîtrise se joue aussi dans les réglages de sécurité (filtres, politiques de rétention, gestion des invites) et dans les mécanismes qui enrichissent le modèle (recherche documentaire, outils, connecteurs).

Un point souvent sous-estimé : la maîtrise se prouve aussi par la gestion du changement. Un assistant IA qui « fonctionnait bien » peut changer de comportement suite à :

une mise à jour de modèle (qualité, sécurité, biais),
une modification de la chaîne de traitement (nouveau filtre, nouveau connecteur),
un changement de politique de rétention ou d’options « d’amélioration du service »,
l’activation involontaire de logs plus détaillés côté observabilité.

La réversibilité est la capacité à sortir d’un fournisseur ou d’une architecture en récupérant les données, les configurations et les preuves (journaux, politiques, paramètres), dans des délais et coûts acceptables. Elle dépasse l’export « des fichiers » : pour un usage d’IA, il faut aussi pouvoir récupérer l’historique pertinent, les index (par exemple des embeddings), les règles d’accès, et les éléments nécessaires pour reconstruire un service équivalent ailleurs. Concrètement, une réversibilité « IA » crédible implique de savoir répondre à : qu’est-ce qui est indispensable au redémarrage ailleurs ? (données sources, index, prompts, politiques, clés, modèles de scoring, listes d’autorisations, etc.).

Partir du cas d’usage pour produire une cartographie exploitable (pas un schéma décoratif)

Une cartographie utile commence par un cas d’usage décrit en termes opérationnels : qui l’utilise, sur quelles données, pour produire quel résultat, avec quels impacts si le résultat fuit, est altéré ou indisponible. Exemple réaliste : « assistant IA pour répondre à des questions internes sur des procédures qualité », ou « synthèse automatique de comptes rendus d’intervention avec pièces jointes ». À ce stade, on qualifie les données (public, interne, confidentiel, réglementé) et on liste les contraintes : conservation, traçabilité, confidentialité, disponibilité.

Une bonne pratique consiste à formaliser trois impacts dès le départ, même en quelques lignes :

Confidentialité : que se passe-t-il si une invite / une réponse / un document indexé fuit ?
Intégrité : que se passe-t-il si l’IA répond avec une procédure obsolète, modifiée, ou inventée ?
Disponibilité : que se passe-t-il si le service est indisponible (chantier, astreinte, support client) ?

Ensuite, on produit un diagramme de flux de données (DFD) orienté sécurité. Il doit expliciter : sources (SI métier, messagerie, GED), points d’entrée (navigateur, application mobile, API), traitements (pré-traitement, anonymisation, extraction), destinations (stockages, journaux, outils tiers), et frontières de confiance (réseau interne, cloud, SaaS). L’objectif est de pouvoir répondre à des questions simples : « à quel moment une donnée quitte notre périmètre ? », « où est-elle stockée ? », « qui peut la lire en clair ? ».

Pour rendre le DFD directement exploitable, vous pouvez ajouter (sans complexifier) deux notations :

Type de donnée sur chaque flèche (ex. : texte libre, PDF, image, métadonnées, logs).
Niveau de sensibilité (ex. : interne / confidentiel / réglementé) sur les principaux flux, plutôt que sur tous.

Enfin, on complète le schéma par une fiche « flux » exploitable par les achats, la sécurité et la DSI : nature des données, base contractuelle de sous-traitance (sans conseil juridique personnalisé), sous-traitants impliqués, politiques de rétention, chiffrement, et mécanismes de suppression. Cette fiche devient le pivot d’échanges avec le fournisseur.

Un format simple (1 flux = 1 bloc) suffit généralement :

Nom du flux : « Application mobile → API assistant IA »
Données transportées : invite + pièce jointe (PDF), identifiant utilisateur, métadonnées
Traitements : extraction texte, filtrage, inférence, post-traitement
Stockage : logs techniques (durée), conversation (durée), index (durée)
Chiffrement : en transit / au repos ; gestion des clés
Accès : rôles (client / fournisseur) et mécanismes (MFA, PAM, bastion)
Sous-traitants : liste et finalité (support, observabilité, etc.)
Suppression : procédure, délai, preuve possible (log, ticket, rapport)
Risque principal : fuite / altération / indisponibilité + mesure clé

Cartographie des accès : du « qui utilise l’outil » au « qui peut techniquement voir la donnée »

La cartographie des accès recense les identités (humaines et techniques) qui peuvent accéder aux données et aux composants IA, ainsi que les droits associés. Un contrôle d’accès est l’ensemble des mécanismes qui autorisent ou refusent une action (lecture, écriture, export, administration) selon une identité et un contexte. Dans les environnements IA, le piège est de s’arrêter à l’interface (les utilisateurs) et d’oublier les comptes de service, les opérateurs du fournisseur, ou les systèmes de support.

Pour être complète, la cartographie des accès doit typiquement couvrir :

Utilisateurs finaux (salariés, prestataires, comptes externes) : qui peut interroger, quels espaces, quelles sources documentaires.
Administrateurs côté client : qui configure les connecteurs, la rétention, les exports, les politiques de sécurité.
Comptes techniques : API keys, service principals, comptes d’intégration (ETL), comptes de synchronisation (SCIM), comptes RPA éventuels.
Accès fournisseur : support, SRE/ops, interventions sur incident, accès « break-glass » et conditions d’activation.
Accès outillage : SIEM/observabilité, ticketing, outils d’audit, sauvegardes.

On distingue généralement : RBAC (contrôle par rôles) pour attribuer des droits stables, ABAC (contrôle par attributs) pour des règles contextuelles (type de donnée, appareil, localisation, heure), et la gestion des comptes à privilèges (PAM) pour administrer sans exposition inutile. Dans une cartographie sérieuse, chaque accès est relié à une finalité (support, exploitation, amélioration du service), à un mécanisme de contrôle (authentification multifacteur, bastion, journalisation), et à un niveau de preuve (journaux accessibles, rapports d’audit, traces horodatées).

Un artefact très efficace (et rapide à produire) est une mini-matrice d’accès centrée sur les actions à risque :

Action	Qui peut le faire ?	Preuve attendue	Risque si abus
Exporter une conversation / un résultat	Rôle « Admin » uniquement	Log d’export + justification	Exfiltration
Ajouter un connecteur (GED, Drive, SharePoint…)	Admin + validation	Ticket + log d’admin	Sur-exposition
Modifier la rétention	Admin sécurité	Log + revue mensuelle	Conservation excessive
Lire les logs applicatifs détaillés	SRE / SecOps	Accès SIEM tracé	Données dans logs
Accéder à l’index vectoriel	Compte de service dédié	Journal requêtes	Extraction indirecte

La référence opérationnelle ici est l’approche « ne jamais faire confiance, toujours vérifier ». Le NIST résume le principe ainsi : « Never trust, always verify » (NIST SP 800-207, Zero Trust Architecture, août 2020, NIST SP 800-207 (PDF)). Sans adopter un modèle « zéro confiance » complet, vous pouvez en appliquer l’esprit : segmentation, droits minimaux, accès conditionnel, et surtout, vérification par la trace (qui a fait quoi, quand, depuis où).

Particularités IA générative : invites, RAG, réglage fin et journaux, quatre flux souvent oubliés

Une invite (prompt) est le texte ou les données envoyées au modèle pour obtenir une réponse. Une inférence est l’exécution du modèle pour produire une sortie à partir de l’entrée. Dans beaucoup d’organisations, les invites contiennent plus de données sensibles que prévu : extraits de contrats, incidents RH, verbatims clients, identifiants techniques copiés-collés. La cartographie doit donc considérer les invites et les sorties comme des données à part entière, avec leur propre cycle de vie (rétention, purge, export, reproduction dans les journaux).

Point d’attention concret : une invite « innocente » peut devenir sensible par agrégation, par exemple quand un utilisateur colle :

un extrait de tableur (avec noms + montants),
un ticket incident (avec IP, hostname, utilisateur),
un passage de procédure interne (non publique),
une photo (badge, plan, matériel, localisation).

Le second point est la RAG (génération augmentée par récupération), que l’on peut traduire par génération enrichie par recherche documentaire. Elle consiste à indexer des documents internes (souvent via des embeddings, c’est-à-dire des représentations vectorielles) puis à injecter des extraits dans le contexte du modèle. Ce mécanisme crée au moins deux nouveaux stockages : un index vectoriel et un stockage d’extraits ou de caches. La cartographie doit préciser : où sont stockés les embeddings, qui peut les requêter, comment les documents source sont synchronisés, et comment on supprime efficacement un document (suppression du fichier + réindexation + purge des caches).

À documenter explicitement (car ce sont des sources fréquentes de malentendus) :

Périmètre indexé : tout le site documentaire, ou seulement une bibliothèque validée ?
Stratégie d’extraction : PDF → texte ; images → OCR ; pièces jointes incluses ou non ?
Traçabilité : sait-on quels passages ont été injectés dans la réponse (citations, liens) ?
Suppression : la suppression d’un document déclenche-t-elle une réindexation et une purge des caches ?

Troisième zone : le réglage fin (fine-tuning) et l’amélioration continue. Même si vous n’entraînez pas le modèle, certains services proposent d’« améliorer » la qualité via les conversations, les évaluations ou les tickets support. Il faut documenter si les données peuvent servir à l’entraînement, dans quelles conditions et avec quelle option de refus. OWASP rappelle que l’exposition de données sensibles fait partie des risques centraux des applications LLM, notamment via les journaux, les connecteurs et les mécanismes d’extension (OWASP, Top 10 for LLM Applications, page projet mise à jour en continu, OWASP Top 10 for LLM Applications).

Quatrième flux souvent oublié : journaux, observabilité et “télémétrie produit”. Même si vos prompts ne sont pas « stockés comme des conversations », ils peuvent se retrouver partiellement dans :

des logs applicatifs (erreurs, timeouts, traces),
des outils APM/monitoring,
des métriques de qualité (ex. : exemples de requêtes pour comprendre les échecs),
des exports de support (tickets avec captures, diagnostics).

Dans la cartographie, il est utile de séparer :

logs techniques minimaux (nécessaires à l’exploitation),
logs détaillés (souvent optionnels, mais plus risqués),
données d’analytics (parfois envoyées à des tiers).

Enfin, si vous utilisez des assistants « agentiques » (appel d’outils / function calling), ajoutez les flux associés : chaque appel d’outil (recherche interne, ticketing, CRM, stockage) est un flux de données supplémentaire, avec son propre contrôle d’accès et ses propres logs.

Transformer la cartographie en contrôles : indicateurs, tests, preuves et revues

Une cartographie a de la valeur si elle déclenche des contrôles vérifiables. Concrètement, vous pouvez définir des points de contrôle par flux : chiffrement en transit (TLS), chiffrement au repos, gestion des clés (clés gérées par le fournisseur ou par le client), rétention maximale, purge vérifiable, et journalisation. Pour un usage IA, ajoutez des tests de non-régression : après mise à jour du modèle ou d’un connecteur, vérifiez que les flux n’ont pas changé (nouveau sous-traitant, nouvelle région, nouvelle télémétrie).

Pour éviter que cela reste théorique, voici un exemple de correspondance « flux → contrôle → preuve » (à adapter) :

Élément cartographié	Contrôle attendu	Test simple	Preuve
Prompt et réponse	Rétention limitée + export contrôlé	Vérifier la durée de conservation dans l’admin	Capture d’écran + politique interne
Index vectoriel	Accès par compte de service dédié	Tentative d’accès hors rôle doit échouer	Logs d’accès + RBAC
Connecteur GED	Périmètre restreint (dossiers autorisés)	Essayer une requête sur un dossier hors périmètre	Paramétrage connecteur
Logs/observabilité	Masquage / minimisation	Forcer une erreur et inspecter la trace	Extrait de logs (sans données sensibles)
Support fournisseur	Accès conditionnel + traçable	Procédure d’escalade avec approbation	Ticket + journal PAM

Côté pilotage, adoptez un petit jeu d’indicateurs utiles aux décideurs : nombre de flux externes identifiés, part des usages IA couverts par une cartographie à jour, délai moyen de révocation d’un accès à privilèges, pourcentage de conversations conservées au-delà de la politique interne, ou taux de requêtes bloquées par des règles de prévention de fuite. L’idée n’est pas de tout mesurer, mais de pouvoir prouver que les contrôles existent et s’améliorent.

Deux rituels simples améliorent beaucoup la robustesse :

Revue de cartographie à chaque changement significatif (nouveau connecteur, nouvelle source documentaire, nouvelle version modèle, nouveau sous-traitant).
Échantillonnage mensuel (30 minutes) : vérifier 3 flux « à risque » et 3 accès « à privilèges » avec des preuves (logs, paramétrage, tickets).

Pour ancrer cette démarche dans un cadre reconnu, le NIST AI Risk Management Framework insiste sur la nécessité de « cartographier » le contexte et les impacts avant de gérer les risques. Le document structure la démarche en fonctions, dont MAP (cartographier) et GOV (gouverner) (NIST, AI RMF 1.0, janvier 2023, NIST AI RMF 1.0 (PDF)). Sans le reprendre mot pour mot, vous pouvez l’utiliser comme grille : contexte, parties prenantes, impacts, et mécanismes de gouvernance associés.

Exemple réaliste : une ETI du BTP qui déploie un assistant IA, et ce que la cartographie révèle

Prenons une ETI (300 à 800 personnes) qui souhaite un assistant IA pour répondre aux questions des chefs de chantier à partir de procédures internes. Le premier schéma « naïf » ressemble à : mobile → application → IA. La cartographie détaillée met souvent au jour 8 à 15 flux distincts : authentification via un fournisseur d’identité, stockage des documents dans une GED, index vectoriel hébergé séparément, service d’inférence, service de modération, journalisation centralisée, outil de support, et parfois un service d’analytique produit.

Sur le terrain, la cartographie fait aussi émerger des contraintes très concrètes qui changent les décisions :

Connectivité variable sur chantier : pousse parfois à mettre en cache des documents ou des réponses (ce qui crée un stockage local à gouverner).
Équipements hétérogènes (téléphones perso/pro, tablettes partagées) : rend l’accès conditionnel et la séparation des sessions plus critiques.
Photos et pièces jointes (avant/après, réserves, non-conformités) : déclenchent des flux de traitement (OCR, extraction, stockage temporaire) souvent invisibles dans un simple schéma.

Les arbitrages deviennent alors tangibles. Si les documents incluent des plans, des photos et des comptes rendus d’incident, l’organisation peut décider de garder l’index et les documents sur un stockage interne, tout en utilisant un service d’inférence externe avec des invites minimisées (par exemple : ne transmettre que les extraits strictement nécessaires, pas le document entier). À l’inverse, si l’enjeu principal est la disponibilité et la rapidité, elle peut accepter plus de flux externes mais renforcer l’anonymisation, l’accès conditionnel et la rétention courte.

La cartographie des accès, elle, révèle souvent un problème d’organisation : des comptes partagés « pour aller vite », des droits d’administration trop larges, ou l’absence de séparation entre environnements (test et production). Un cas fréquent : un connecteur de test pointant vers la bibliothèque documentaire de production « temporairement », puis oublié. Dans un projet IA, ces écarts coûtent cher plus tard, car les flux se multiplient au fil des connecteurs. Le gain immédiat d’une cartographie sérieuse est de réduire le périmètre des données exposées et d’accélérer les validations sécurité, parce que les questions deviennent factuelles.

Clauses et questions à rattacher directement à la cartographie (sans se perdre dans l’abstrait)

Une fois les flux et les accès posés, vous pouvez traduire chaque point en exigence contractuelle ou technique. Exemples : liste des sous-traitants par flux, notification en cas de changement, régions d’hébergement utilisées, politique de rétention des invites et des sorties, conditions d’accès des opérateurs (support), et engagement de fournir des journaux ou rapports d’audit. L’objectif est d’aligner le contrat sur votre schéma réel, pas sur une promesse marketing.

Pour garder la discussion « collée » à la cartographie, reliez chaque clause à une flèche précise, par exemple :

Flux « application → service IA » : quelles données transitent et sont-elles journalisées ?
Flux « service IA → observabilité » : quels champs partent (ex. prompt complet vs hash / longueur / code erreur) ?
Flux « index vectoriel → recherche » : qui peut requêter et comment prouver l’usage ?

Sur la sécurité des accès, des questions simples sont très discriminantes : authentification multifacteur obligatoire ? gestion des comptes à privilèges ? séparation des rôles (administration, support, exploitation) ? traçabilité consultable par le client ? procédures de révocation et délais ? Ces points sont plus actionnables que des débats généraux sur la « souveraineté », parce qu’ils se mesurent et se testent.

Sur la rétention, faites préciser trois durées distinctes (souvent mélangées dans les discours) :

durée de conservation des conversations (si la fonctionnalité existe),
durée de conservation des logs techniques,
durée de conservation des données d’analytics.

Sur la réversibilité, rattachez l’exigence à des objets précis : export des conversations (avec métadonnées), export de l’index (embeddings + mapping), export des politiques d’accès, et récupération des paramètres de filtrage. Demandez un scénario de sortie testé (au moins sur un périmètre) et une estimation des délais. La réversibilité n’est crédible que si elle est planifiée pendant le déploiement, pas au moment du départ.

Enfin, si votre cas d’usage touche des données soumises à des exigences sectorielles (ex. données de santé), intégrez-le comme contrainte de conception dans la cartographie (hébergement, certification, sous-traitants, localisation des traitements) plutôt que comme une « annexe » tardive : cela évite de refaire l’architecture une fois le pilote validé.

Prochaine étape concrète : un sprint de cartographie « flux + accès » en 10 jours

Action recommandée (effort : moyen) : organisez un sprint court, avec un binôme DSI/RSSI et un référent métier, pour produire une cartographie exploitable sur un cas d’usage prioritaire. Jour 1-2 : cadrage du cas d’usage et classification des données. Jour 3-5 : diagramme de flux (DFD) + inventaire des sous-traitants et stockages. Jour 6-8 : cartographie des accès (humains et techniques) + exigences de journalisation. Jour 9-10 : revue, arbitrages (ce qui sort, ce qui reste), et plan de remédiation.

Pour que le sprint aboutisse à des décisions (et pas seulement à des documents), verrouillez dès le départ :

Un périmètre unique (un cas d’usage, une population pilote, une source documentaire principale).
Un format de preuve (captures d’admin, exports de configuration, exemples de logs, annexes contractuelles).
Un « point d’arrêt » : si un flux critique n’est pas clarifié (rétention inconnue, sous-traitant non listé, accès support non cadré), le pilote reste limité à des données non sensibles.

Livrables attendus : un schéma de flux versionné, une matrice d’accès (rôles, droits, preuves), une fiche par flux (données, stockage, rétention, chiffrement, sous-traitants), et une liste priorisée de mesures (par exemple : désactiver la conservation des conversations, imposer l’authentification multifacteur, isoler l’index vectoriel, réduire les droits d’administration). Ce jeu de livrables suffit généralement à sécuriser un pilote sans figer l’innovation.

Si vous devez engager un fournisseur, utilisez la cartographie comme support d’échange et de négociation : chaque flèche du schéma doit avoir un responsable, un mécanisme de contrôle et un engagement vérifiable. Une gouvernance IA efficace commence rarement par des outils : elle commence par une cartographie exacte de ce qui circule, et de qui peut y toucher.