Gouvernance GenAI : ce qui manque dans la plupart des déploiements

GenAI
Gouvernance
Sécurité
Compliance
Cadre opérationnel complet pour un RSSI — politiques de données, identity management, approval process, behavioral analytics, monitoring continu, réponse aux incidents, due diligence vendors et checklist de déploiement.
Author

Sylvain Pham

Published

February 21, 2026

Sur plusieurs missions d’infrastructure et MLOps, j’ai vu le même scénario se répéter : un déploiement GenAI qui démarre vite, sans cadre formalisé, et qui crée des angles morts que personne ne voit jusqu’au moment où quelqu’un pose la mauvaise question. Qui est responsable si le modèle hallucine sur des données client ? Les logs de conversation, ils sont stockés où ? Votre provider IA, vous avez vérifié sa conformité GDPR ?

Ce document est le cadre que j’utilise comme référence opérationnelle. Il s’appuie sur la formation Implement GenAI Governance Step by Step (Dr. Amar Massoud) et sur les standards du secteur — NIST AI RMF, EU AI Act, ISO/IEC 38507. L’objectif : avoir quelque chose d’actionnable pour un RSSI, pas une liste de principes qui reste dans un tiroir.

1 Les cinq angles morts récurrents

WarningAngle mort 1 — Pas de politique de données formalisée

Les équipes savent intuitivement ce qui est “sensible”, mais il n’y a pas de définition écrite de qui peut accéder à quoi, sous quelles conditions, et pendant combien de temps. Quand un auditeur ou un partenaire demande la documentation, ça bloque.

WarningAngle mort 2 — Déploiement sans audit de risques

Le modèle est mis en prod parce qu’il “fonctionne en démo”. Personne n’a formellement évalué ce qui se passe si le modèle produit un output biaisé, si une API tombe, ou si les données d’entraînement sont corrompues.

WarningAngle mort 3 — Vendors IA sans due diligence

Le provider LLM a été choisi sur la qualité technique. Sa conformité GDPR, sa stabilité financière, sa politique de rétention des données — personne n’a vraiment regardé.

WarningAngle mort 4 — Logs et données PII mal protégés

Les logs de conversation entre utilisateurs et modèle contiennent souvent des données personnelles. Ils sont stockés en clair, accessibles trop largement, sans politique de rétention définie.

WarningAngle mort 5 — Pas de plan de réponse aux incidents testé

En cas de breach ou de comportement anormal du modèle, personne ne sait exactement quoi faire, dans quel ordre, et qui notifier. Le plan existe peut-être sur papier mais n’a jamais été simulé.

2 Périmètre : ce qu’une gouvernance GenAI doit couvrir

flowchart TD
    A[Gouvernance GenAI] --> B[Frameworks &\nPrincipes]
    A --> C[Politiques\nde données]
    A --> D[Sécurité &\nProtection]
    A --> E[Identity &\nAccess Management]
    A --> F[Risk\nManagement]
    A --> G[Regulatory\nCompliance]
    A --> H[Third-Party\nRisk]
    A --> I[Approval Process\n& Registry]
    A --> J[Behavioral\nAnalytics]
    A --> K[Monitoring\nContinu]
    A --> L[User Awareness\nTraining]

    style A fill:#1a1a2e,color:#fff

3 1. Frameworks de référence

Le cadre le plus opérationnel pour la gestion des risques IA. Quatre fonctions en boucle :

flowchart LR
    G[GOVERN\nPolitiques, rôles\nresponsabilités] --> M[MAP\nIdentifier et\ncatégoriser les risques]
    M --> ME[MEASURE\nÉvaluer\nl'impact potentiel]
    ME --> MA[MANAGE\nMitigations et\nmonitoring continu]
    MA --> G

Ce que ça implique concrètement : nommer un AI Owner avec des responsabilités écrites, définir la fréquence des revues de risques (trimestrielle minimum), documenter chaque décision de déploiement. Sans rôles explicitement nommés, la gouvernance reste théorique.

Classification des systèmes IA par niveau de risque — avec des obligations proportionnelles :

flowchart TD
    UA["Risque inacceptable\nInterdit\nEx: social scoring, manipulation"] --> HR["Risque élevé\nAudit obligatoire, transparence\nsupervision humaine\nEx: RH, crédit, santé, justice"]
    HR --> LR["Risque limité\nObligations de transparence\nEx: chatbots, deepfakes"]
    LR --> MR["Risque minimal\nPas d'exigence spécifique\nEx: filtres spam, jeux"]

    style UA fill:#cc0000,color:#fff
    style HR fill:#ff6600,color:#fff
    style LR fill:#ffaa00
    style MR fill:#006600,color:#fff

Important

Si votre GenAI prend des décisions qui affectent des personnes (recrutement, crédit, santé, accès aux services), vous êtes en zone risque élevé — supervision humaine obligatoire, documentation complète, audit avant déploiement, conformité continue.

ISO/IEC 38507 — gouvernance de l’IA au niveau organisationnel : engagement du top management, politiques IA intégrées à la gouvernance IT globale, évaluation continue des performances et de la conformité.

ISO/IEC 38505 — gouvernance des données : accountability, transparence, usage éthique. Référentiel utilisé pour aligner les pratiques avec les standards internationaux.

OECD AI Principles — inclusivité (l’IA bénéficie à tous), valeurs centrées sur l’humain, transparence et explicabilité, robustesse et sécurité.

DAMA / COBIT / CMMI — frameworks de gouvernance des données complémentaires : DAMA pour la gestion globale des données, COBIT pour l’alignement avec les objectifs organisationnels et la gestion des risques, CMMI pour l’amélioration continue des capacités.

flowchart LR
    ORG[Votre système GenAI] --> GDPR[GDPR\nDonnées personnelles EU\nNotification breach 72h]
    ORG --> CCPA[CCPA\nCalifornie\nDroits consommateurs]
    ORG --> HIPAA[HIPAA\nSanté — USA]
    ORG --> EUAI[EU AI Act\nSystèmes IA à risque]
    ORG --> SECT[Réglementations\nsectorielles\nFinance, santé, énergie...]

4 2. Politiques de données — ce qu’il faut formaliser

Quatorze politiques couvrent le périmètre complet. En pratique, toutes ne sont pas également urgentes.

4.1 Priorité 1 — Avant tout déploiement en production

Important

Ces quatre politiques couvrent les risques les plus immédiats. Leur absence expose l’organisation à des risques juridiques et opérationnels non documentés.

Data Privacy Policy — définit comment les données personnelles sont collectées, traitées, stockées et supprimées. Inclut les droits des personnes concernées (accès, rectification, suppression, portabilité).

Warning

Piège fréquent : la politique couvre la production mais oublie les environnements de test — qui contiennent souvent les mêmes données réelles.

Data Security Policy — mesures techniques et organisationnelles pour prévenir les accès non autorisés. Chiffrement, contrôles d’accès, gestion des clés, procédures de patch.

Warning

Piège fréquent : chiffrement en base de données, mais les dumps de backup stockés en clair sur un bucket S3 mal configuré. La politique doit couvrir tous les emplacements de données.

Data Access Policy — qui peut accéder à quoi, sous quelles conditions. RBAC défini, documenté et révisable.

Warning

Piège fréquent : le RBAC est configuré au lancement, jamais révisé. 18 mois plus tard, des personnes ayant changé de poste conservent leurs anciens accès.

Data Incident Response Policy — que faire en cas de breach, dans quel ordre, qui notifier, dans quel délai (72h RGPD).

Warning

Piège fréquent : le plan existe sur papier mais n’a jamais été simulé. La première fois qu’il sert, c’est en condition réelle.

4.2 Priorité 2 — Dans les 90 jours suivant le déploiement

Data Classification Policy — niveaux de sensibilité des données. Sans cette classification, les mesures de protection sont appliquées de façon uniforme là où elles devraient être proportionnelles.

Exemple de niveaux :

Niveau Type de données Mesures
4 — Critique PII, données santé, secrets commerciaux, données financières Chiffrement fort, accès minimal, audit continu
3 — Confidentiel Données internes sensibles, logs avec PII Chiffrement, RBAC strict, rétention limitée
2 — Interne Données opérationnelles, logs système Contrôles d’accès standards
1 — Public Données publiées, documentation ouverte Pas de restriction spécifique

Data Retention Policy — durée de conservation et conditions de suppression. Impacte la compliance RGPD et les coûts de stockage. Pour les logs de conversation GenAI : définir explicitement la durée de rétention et les conditions d’accès.

Data Quality Policy — standards minimaux pour les données qui entrent dans le système. Critique pour les pipelines RAG : la qualité des outputs dépend directement de la qualité des données d’indexation. Garbage in, garbage out.

Data Usage Policy — usages autorisés et interdits. Qui peut utiliser les outputs du modèle, dans quel cadre, pour quelles décisions. Quelles décisions ne peuvent pas être déléguées au modèle sans supervision humaine.

4.3 Priorité 3 — Politiques de structure

Data Governance Framework Policy — rôles et instances de décision. Qui est AI Owner, qui est Data Steward, qui valide les politiques.

Data Sharing Policy — conditions de partage interne et externe. Clauses contractuelles à inclure avec les partenaires.

Data Ownership Policy — responsabilités de stewardship. Qui est accountable pour chaque dataset.

Data Audit Policy — fréquence et périmètre des revues. Audit interne trimestriel, audit externe annuel.

Data Ethics Policy — usage éthique, prévention des biais, fairness. Processus de revue des décisions algorithmiques.

Data Integration Policy — conditions pour combiner des sources de données. Maintien de la qualité et de la cohérence lors des intégrations.

5 3. Sécurité technique — Protection des données

5.1 Chiffrement

flowchart TD
    DATA[Données sensibles] --> REST["At Rest\nBDD, fichiers, backups, exports\nAES-256"]
    DATA --> TRANSIT["In Transit\nAPI, réseau interne/externe\nTLS 1.3 / VPN"]
    REST --> KM["Key Management\nGénération, distribution\nRotation périodique\nStockage sécurisé (HSM)\nAccès restreint et audité"]
    TRANSIT --> KM

Exigences minimales : - AES-256 pour les données au repos - TLS 1.3 pour les données en transit - Rotation des clés planifiée et automatisée - HSM (Hardware Security Module) pour les clés critiques - Accès aux clés tracé et audité - Mise à jour régulière des protocoles de chiffrement à mesure que de nouvelles vulnérabilités sont découvertes

5.2 Data Masking — Environnements non-prod

Le masquage remplace les données réelles par des données fictives structurellement cohérentes dans les environnements de développement et de test.

Static Data Masking (SDM) — transformation avant export vers dev/test. Les données originales restent intactes en production.

Dynamic Data Masking (DDM) — masquage en temps réel selon les droits de l’utilisateur. Les données originales restent intactes en base, seul l’affichage est masqué selon le profil.

Exemples de techniques par type de donnée :

Type de donnée Technique Exemple
Nom/prénom Substitution Alex Smith → John Doe
Numéro carte bancaire Masquage partiel → ****1234
SSN Tokenisation 123-456-789 → TKN987654321
Email Anonymisation user@example.com → aXX@masked.com
Téléphone Masquage partiel 0612345678 → 06XXXXXX78
Adresse Généralisation 123 rue de la Paix → XXX rue, ville
Dossier médical Rédaction “diabète” → “condition chronique”
Compte bancaire Chiffrement 1234567890 → g5h8k7L3
Date de naissance Format-preserving 01/01/1990 → ##/##/1990
Salaire Shuffle 75 000€ → 82 000€ (valeur d’un autre employé)
Tip

Le masquage doit conserver la structure et les relations des données. Un client masqué doit toujours avoir ses commandes liées — sinon les tests ne sont pas représentatifs de la réalité.

5.3 Points de fuite à auditer

flowchart TD
    DL[Points de fuite GenAI] --> I1["User Input\nPII dans les prompts\nDonnées financières, médicales"]
    DL --> I2["API Integrations\nEndpoints non sécurisés\nAuthentification insuffisante"]
    DL --> I3["Stockage\nBuckets cloud mal configurés\nPermissions trop larges"]
    DL --> I4["Logs de conversation\nDonnées PII en clair\nRétention non définie\nAccès trop large"]
    DL --> I5["Backups\nNon chiffrés\nStockés en lieu non sécurisé"]
    DL --> I6["Third-party vendors\nSans audit sécurité\nDonnées partagées sans DPA"]
    DL --> I7["Endpoints utilisateurs\nLaptops, mobiles, USB\nNon chiffrés, non managés"]
    DL --> I8["Email & messaging\nPartage non sécurisé\nAbsence de DLP"]
    DL --> I9["Sécurité physique\nAccès datacenter\nDocuments physiques"]
    DL --> I10["Vulnérabilités applicatives\nCode non audité\nBibliothèques non mises à jour"]

    style I4 fill:#cc3300,color:#fff
    style I5 fill:#cc3300,color:#fff

WarningPoint critique : les logs de conversation GenAI

Si votre système trace les échanges utilisateur/modèle — pour du debugging, de l’analytics ou de l’amélioration continue — ces logs contiennent potentiellement des données sensibles saisies par les utilisateurs. Politique de rétention, chiffrement et accès restreint sont obligatoires sous RGPD. Ce n’est pas négociable.

6 4. Identity & Access Management

6.1 Cycle de vie des identités

flowchart LR
    CREATE["Création\nIdentité unique\nCréation des credentials\nAssignation du rôle"] --> ASSIGN["Attribution des droits\nRBAC selon le poste\nPrincipe du moindre privilège"]
    ASSIGN --> MONITOR["Monitoring continu\nActivités tracées\nAnomalies détectées"]
    MONITOR --> AUDIT["Audit périodique\nRevue des droits\nDésactivation des comptes inactifs"]
    AUDIT --> UPDATE["Mise à jour\nChangement de poste\nNouvelles responsabilités"]
    UPDATE --> DEPROV["Déprovisionnement\nDépart de l'organisation\nRévocation immédiate"]
    DEPROV --> MONITOR

Important

Quand un employé quitte l’organisation ou change de poste, ses accès doivent être révoqués ou mis à jour immédiatement. Les comptes orphelins sont l’une des sources les plus fréquentes de violations de données internes.

6.2 RBAC vs ABAC

flowchart TD
    subgraph RBAC["RBAC — Role-Based Access Control"]
        direction LR
        R1["Rôle : Développeur IA\n→ Accès : dépôts code, environnements dev"]
        R2["Rôle : Data Scientist\n→ Accès : datasets, outils analytics"]
        R3["Rôle : Admin Système\n→ Accès complet avec audit renforcé"]
        R4["Rôle : Utilisateur Final\n→ Accès : interface uniquement"]
    end

    subgraph ABAC["ABAC — Attribute-Based Access Control"]
        direction LR
        A1["Attributs : poste + heure + localisation + projet + clearance"] --> D1{"Évaluation\nde la politique"}
        D1 -->|"Tous les critères remplis"| OK["✓ Accès accordé"]
        D1 -->|"Condition non remplie"| NOK["✗ Accès refusé"]
    end

Principe du moindre privilège — chaque utilisateur dispose uniquement des accès strictement nécessaires à ses fonctions. Réduire la surface d’attaque en cas de compromission de compte.

En pratique pour un déploiement GenAI :

  • RBAC comme base : définir les rôles (développeur, data scientist, utilisateur métier, admin, auditeur)
  • ABAC pour les ressources sensibles : accès aux données PII uniquement depuis le réseau interne, en heures ouvrées, pour les membres du projet concerné
  • Révision des droits à chaque changement de poste et au minimum tous les 6 mois
  • Comptes de service avec droits minimaux, jamais de credentials partagés

6.3 Méthodes d’authentification

Multi-Factor Authentication : combinaison d’au moins deux facteurs. - Quelque chose que l’utilisateur sait : mot de passe - Quelque chose que l’utilisateur possède : token hardware, application TOTP, SMS - Quelque chose que l’utilisateur est : empreinte digitale, reconnaissance faciale

MFA obligatoire pour tous les accès aux systèmes GenAI et aux données sensibles. Réduit drastiquement le risque d’accès non autorisé même en cas de compromission d’un facteur.

Vérification basée sur des traits biologiques uniques : empreintes digitales, reconnaissance faciale, iris. Difficile à répliquer ou voler. Particulièrement adapté pour les accès aux systèmes critiques.

Génération d’un token unique par session après authentification réussie. Token chiffré, à durée de vie limitée. Évite la réauthentification répétée tout en maintenant la sécurité.

Single Sign-On : un seul ensemble de credentials pour accéder à plusieurs applications. Améliore l’expérience utilisateur, centralise la gestion de l’authentification, facilite l’application des politiques de sécurité et le monitoring.

Public Key Infrastructure : paires de clés cryptographiques émises par une autorité de certification. Clé privée gardée secrète, clé publique partagée. Signature numérique vérifiable. Utilisé pour les accès très sensibles et les communications inter-systèmes.

Authentification continue basée sur les patterns comportementaux : rythme de frappe, mouvements de souris, habitudes de navigation. Détecte les déviations qui pourraient indiquer un compte compromis même après authentification initiale réussie.

Évaluation du contexte de chaque tentative d’authentification : localisation, appareil utilisé, heure d’accès. Si le contexte dévie des habituelles (ex : connexion depuis un nouveau pays), des étapes de vérification supplémentaires sont déclenchées.

6.4 Bonnes pratiques IAM pour GenAI

  • Audit trail complet : chaque accès aux données et aux modèles est loggé avec user, timestamp, ressource, action
  • Revue d’accès régulière : audit des permissions tous les 6 mois minimum, revue immédiate après changement organisationnel
  • Comptes de service : credentials dédiés par service, rotation automatique, jamais de credentials partagés entre services
  • Séparation des environnements : comptes et credentials différents entre dev, staging et prod
  • Formation : sensibilisation aux mots de passe forts, au phishing, aux bonnes pratiques d’authentification

7 5. Approval Process & Registry des applications

Toute application GenAI doit passer par un processus formel d’approbation avant déploiement. L’absence de ce processus est l’une des causes principales d’exposition non documentée.

7.1 Processus d’approbation

flowchart TD
    START["Demande de déploiement\nd'une application GenAI"] --> ASSESS["1. Évaluation initiale\nObjectifs, périmètre\nAlignement stratégique\nCritères d'évaluation définis"]
    ASSESS --> TECH["2. Évaluation technique\nArchitecture du modèle\nSources de données\nAlgorithmes utilisés\nPerformances (accuracy, F1, MSE...)"]
    TECH --> PILOT["3. Phase pilote\nEnvironnement contrôlé\nSimulation conditions réelles\nCollecte des retours utilisateurs\nIdentification des problèmes"]
    PILOT --> SEC["4. Audit sécurité & compliance\nConformité réglementaire (GDPR, HIPAA...)\nContrôles d'accès\nProtection des données\nTest de pénétration si pertinent"]
    SEC --> UAT["5. User Acceptance Testing\nTests par les utilisateurs finaux\nValidation de l'ergonomie\nVérification des cas d'usage réels"]
    UAT --> DOC["6. Revue de la documentation\nManuels utilisateurs\nSpécifications techniques\nGuides opérationnels\nPolitiques applicables"]
    DOC --> MEETING["7. Réunion d'approbation formelle\nParties prenantes : tech, métier\ncompliance, RSSI, DPO\nDécision collégiale documentée"]
    MEETING --> GO{"Décision"}
    GO -->|"Approuvé"| DEPLOY["8. Déploiement\nConfiguration finale\nMise en place du monitoring\nFormation des utilisateurs\nAjout au registry"]
    GO -->|"Refusé / Conditions"| REWORK["Retour en développement\nCorrections requises\ndocumentées"]
    REWORK --> TECH

7.2 Registry des applications approuvées

Le registry est un référentiel centralisé de toutes les applications GenAI déployées. C’est un outil de gouvernance, pas une formalité administrative.

Ce que le registry doit contenir pour chaque application :

Champ Description
Nom & version Identifiant unique, numéro de version
Objectif Description fonctionnelle, cas d’usage
Niveau de risque EU AI Act Inacceptable / Élevé / Limité / Minimal
Données traitées Types, classification, volumétrie
Périmètre réglementaire GDPR, HIPAA, CCPA, sectoriels
AI Owner Responsable désigné
Date d’approbation Et durée de validité de l’approbation
Conditions d’approbation Contraintes, restrictions d’usage
Vendors & dépendances Providers LLM, APIs externes, datasets
Historique des versions Mises à jour, modifications majeures
Date de décommissionnement Prévue ou réelle
Statut En production / En test / Décommissionné

Gouvernance du registry :

  • Accès en écriture restreint aux personnes autorisées (RSSI, AI Owner, compliance)
  • Audit log des modifications
  • Revue trimestrielle pour vérifier l’exactitude des entrées
  • Alertes automatiques pour les applications dont l’approbation arrive à expiration
  • Processus de décommissionnement documenté : que devient la donnée quand l’application est retirée ?
Important

Le registry n’est utile que s’il est maintenu à jour en temps réel. Une entrée obsolète est pire qu’une entrée absente : elle crée une fausse impression de contrôle.

7.3 Évaluation des applications GenAI — Critères

Pour chaque application soumise à approbation, évaluer systématiquement :

Performance du modèle : - Accuracy, precision, recall, F1 score pour les modèles de classification - MSE, R² pour les modèles de régression - Évaluation sur des datasets représentatifs des conditions réelles

Qualité des données : - Exactitude, complétude, représentativité - Détection de biais dans les données d’entraînement - Traçabilité des sources de données

Scalabilité & robustesse : - Comportement sous charge (stress testing) - Résilience aux données bruitées ou incomplètes - Maintien des performances avec des volumes croissants

Sécurité & compliance : - Conformité aux réglementations applicables - Mesures de sécurité implémentées - Résultats des audits de sécurité

Éthique & biais : - Absence de discrimination dans les outputs - Transparence des décisions - Mécanisme de supervision humaine si nécessaire

8 6. Risk Management

8.1 Matrice de risques — Systèmes GenAI

quadrantChart
    title Priorités de risques — Sévérité × Probabilité
    x-axis Probabilité faible --> Probabilité élevée
    y-axis Sévérité faible --> Sévérité élevée
    quadrant-1 Action immédiate
    quadrant-2 Surveiller
    quadrant-3 Acceptable
    quadrant-4 À planifier
    Accès non autorisé données: [0.5, 0.9]
    Exploitation vulnérabilités: [0.75, 0.9]
    Biais modèle IA: [0.5, 0.85]
    Vol propriété intellectuelle: [0.5, 0.88]
    Dégradation perf. haute charge: [0.75, 0.55]
    Non-conformité GDPR: [0.5, 0.55]
    Pannes système: [0.25, 0.85]
    Menaces internes: [0.5, 0.5]
    Risques vendeurs tiers: [0.5, 0.5]
    Intégrité des données: [0.25, 0.45]

8.2 Techniques d’évaluation des risques

Qualitative — catégorisation sévérité/probabilité par jugement expert. Point d’entrée pour la plupart des organisations. Rapide à mettre en place, utile pour prioriser les actions.

Quantitative — analyse numérique avec modèles statistiques et données historiques. Permet d’estimer l’impact financier d’un incident. Plus précis, plus coûteux à produire.

Scenario Analysis — création de scénarios hypothétiques pour explorer les conséquences de chaque événement de risque. Aide à préparer des réponses adaptées.

FMEA (Failure Modes and Effects Analysis) — analyse systématique de chaque composant du système et de ses modes de défaillance possibles. Identifie les points de fragilité avant qu’ils ne se manifestent.

Bowtie Analysis — vue combinée des causes (fault tree) et des effets (event tree) autour d’un événement central. Permet de visualiser simultanément les mesures préventives et réactives.

Monte Carlo — simulation probabiliste des impacts par échantillonnage aléatoire. Fournit une distribution des scénarios possibles plutôt qu’un point unique.

Sensitivity Analysis — identification des variables qui ont le plus d’influence sur les niveaux de risque. Aide à concentrer les efforts sur les leviers les plus critiques.

Risk Matrix — visualisation bidimensionnelle probabilité × impact. Outil de communication efficace pour les parties prenantes non techniques.

8.3 Stratégies de mitigation

Risque Sévérité Probabilité Mitigation
Accès non autorisé aux données Élevée Moyenne Chiffrement AES-256 + RBAC strict + audit trails + MFA
Exploitation de vulnérabilités Élevée Élevée Patch management + audits sécurité + pen tests réguliers
Biais IA Élevée Moyenne Bias audits périodiques + mise à jour données d’entraînement + supervision humaine
Vol de propriété intellectuelle Élevée Moyenne DRM + protections légales + monitoring distribution
Pannes système Élevée Faible Redondance + mécanismes de failover + tests de basculement
Menaces internes Moyenne Moyenne Contrôles d’accès stricts + monitoring comportemental + principe du moindre privilège
Non-conformité RGPD Moyenne Moyenne Revues compliance régulières + formation + DPO impliqué
Dégradation performance Moyenne Élevée Load balancing + performance testing + scaling automatique
Risques vendeurs tiers Moyenne Moyenne Due diligence + évaluations contractuelles annuelles + clauses de sortie
Intégrité des données Moyenne Faible Validation des données d’entrée + procédures de backup + checksums

9 7. Third-Party Risk — Due Diligence Vendors IA

9.1 Les cinq axes d’évaluation

flowchart LR
    DD[Due Diligence\nVendeur IA] --> FIN["Financier\nBilan, P&L, cash flow\nstabilité long terme\nrisque de défaillance"]
    DD --> LEGAL["Légal & Compliance\nLicences en règle\nLitiges passés\nSOC 2, ISO 27001\nDPA signable ?"]
    DD --> OPS["Opérationnel\nUptime SLA\nTemps de réponse\nStack tech & IP\nPlan de continuité"]
    DD --> HR["Organisation\nTurnover\nCulture sécurité\nCompétences clés\nDépendance aux personnes"]
    DD --> MARKET["Position marché\nBase clients\nCroissance\nRisque de rachat\nRisque de pivot produit"]

9.2 Questions à poser à chaque vendor IA

Sur les données :

  • Quelle est votre politique de rétention des prompts et des outputs ?
  • Les données que nous vous envoyons servent-elles à entraîner vos modèles ?
  • Où sont physiquement stockées les données ? Dans quelle juridiction ?
  • Avez-vous une option zero data retention ? À quel coût ?
  • Comment gérez-vous les demandes de suppression (droit à l’oubli RGPD) ?
  • Qui a accès à nos données au sein de votre organisation ?

Sur la compliance :

  • Êtes-vous certifié SOC 2 Type II ? ISO 27001 ? Quand a eu lieu le dernier audit ?
  • Avez-vous signé des DPA (Data Processing Agreements) avec des clients EU ?
  • Comment gérez-vous les sous-traitants qui ont accès à nos données ?
  • Quelle est votre politique en cas de breach affectant nos données ?

Sur la stabilité et la continuité :

  • Quelle est votre procédure de continuité de service en cas de défaillance majeure ?
  • Que se passe-t-il pour nos données si vous êtes rachetés ou si vous cessez votre activité ?
  • Quelle est votre clause de sortie ? Comment récupère-t-on nos données ?
  • Quel est le SLA garanti ? Quelle compensation en cas de non-respect ?
Tip

Intégrer ces questions dans un questionnaire standardisé à envoyer à chaque nouveau vendor avant contractualisation. Refaire l’exercice annuellement pour les vendors critiques. Documenter les réponses dans le registry.

9.3 Gestion contractuelle des vendors

Le contrat est le seul levier de protection légale si un vendor faillit à ses obligations. Il doit couvrir explicitement :

  • Scope : périmètre exact des services, données concernées, livrables attendus
  • SLAs : uptime, temps de réponse, pénalités en cas de non-respect
  • Data Protection : conformité GDPR/CCPA, localisation des données, rétention, suppression
  • Confidentialité : clauses NDA, protection des données propriétaires
  • IP : propriété des modèles développés, des données d’entraînement, des outputs
  • Amendments : processus de modification documenté et signé par les deux parties
  • Audit rights : droit d’auditer le vendor ou d’exiger un rapport d’audit tiers
  • Exit strategy : procédure de sortie, délais, format de restitution des données, destruction certifiée

Monitoring continu des vendors :

  • Rapports de performance mensuels
  • Audits de conformité trimestriels
  • Revue contractuelle annuelle
  • Alertes en cas de changements majeurs chez le vendor (rachat, incident sécurité, changement de politique)

10 8. Behavioral Analytics & User Monitoring

Le monitoring comportemental est la couche de détection qui permet d’identifier des menaces que les contrôles d’accès seuls ne voient pas — notamment les menaces internes et les comptes compromis.

10.1 Principe de fonctionnement

flowchart LR
    COLLECT["Collecte des données\nLogin times\nLocations d'accès\nRessources consultées\nVolumes téléchargés\nActions réalisées"] --> BASELINE["Établissement\nd'une baseline\nComportement normal\npar utilisateur et par rôle"]
    BASELINE --> ANALYZE["Analyse continue\nAlgorithmes ML\nDétection de patterns\nComparaison à la baseline"]
    ANALYZE --> ALERT["Alertes en temps réel\nDéviation détectée\nÉquipe sécurité notifiée"]
    ALERT --> INVESTIGATE["Investigation\nContextualisation\nFaux positifs filtrés\nIncident confirmé ou clôturé"]
    INVESTIGATE --> UPDATE["Mise à jour\ndes modèles\nMensuelle minimum\nNouvelles menaces intégrées"]
    UPDATE --> COLLECT

10.2 Signaux d’alerte à surveiller pour les systèmes GenAI

Accès inhabituels : - Connexion en dehors des heures de travail habituelles (ex : 2h du matin) - Connexion depuis une localisation inhabituelle ou un pays non prévu - Connexion depuis un appareil non reconnu ou non référencé

Volumes anormaux : - Téléchargement massif de données en peu de temps - Nombre de requêtes au modèle inhabituellement élevé - Accès à des fichiers ou datasets jamais consultés auparavant

Comportements suspects : - Accès répétés à des fichiers sensibles sans justification métier apparente - Tentatives d’accès à des ressources non autorisées - Utilisation du modèle pour des requêtes très différentes du cas d’usage prévu

Indicateurs spécifiques GenAI : - Prompts contenant des patterns d’injection ou de jailbreak - Exfiltration de données via le modèle (demandes de résumés de documents confidentiels) - Utilisation du modèle en dehors du périmètre applicatif défini

10.3 Outils de monitoring comportemental

Outils cités dans la formation ou couramment utilisés : TensorFlow (ML pour détection d’anomalies), Python ML libraries, Datadog, Splunk, AWS CloudWatch.

Tip

Mettre à jour les modèles comportementaux au minimum mensuellement. Le comportement utilisateur évolue, les nouvelles menaces aussi. Un modèle figé devient rapidement inefficace.

11 9. Monitoring Continu & Audit

Le monitoring n’est pas une option — c’est ce qui permet de détecter les dérives avant qu’elles ne deviennent des incidents.

11.1 Framework de monitoring

flowchart TD
    KPI["Définir les KPIs\net métriques\nUptime, accuracy\ntemps de réponse\nconformité GDPR"] --> TOOLS["Déployer les outils\nDatadog, Splunk\nAWS CloudWatch\nArize, MLflow"]
    TOOLS --> RT["Monitoring temps réel\nCollecte automatique\nAnalyse continue\nAlertes sur déviations"]
    RT --> AUDIT["Audits réguliers\nSécurité : trimestriel\nPerformance : mensuel\nCompliance : semestriel"]
    AUDIT --> INCIDENT["Gestion des incidents\nPlan d'action prédéfini\nDiagnostic, mitigation\nPrévention des récurrences"]
    INCIDENT --> LOG["Logs & traçabilité\nJournal de toutes les\nopérations et modifications\nAudit trail complet"]
    LOG --> REPORT["Reporting\nManagement mensuel\nRégulateurs si requis\nParties prenantes"]
    REPORT --> IMPROVE["Amélioration continue\nAnalyse des tendances\nMise à jour des modèles\nRévision des politiques"]
    IMPROVE --> KPI

11.2 KPIs à monitorer pour un système GenAI

Performance système : - Uptime (SLA cible : 99.9%) - Temps de réponse moyen (ex : < 200ms) - Taux d’erreur des API

Qualité du modèle : - Accuracy, F1 score sur des datasets de référence - Taux de refus inappropriés - Taux de réponses biaisées ou problématiques (nécessite une évaluation humaine)

Sécurité : - Tentatives d’accès non autorisées - Anomalies comportementales détectées - Vulnérabilités identifiées et délai de remédiation

Compliance : - Conformité GDPR : taux de traitement des demandes de droits dans les délais - Couverture des audits planifiés vs. réalisés - Nombre d’incidents de compliance

11.3 Processus d’audit

Audit interne trimestriel : 1. Définir le scope et les objectifs de l’audit 2. Collecter les logs, configurations, journaux d’accès 3. Interviewer les équipes impliquées 4. Évaluer la conformité aux politiques et réglementations 5. Documenter les findings et recommandations 6. Partager le rapport avec le management et les régulateurs si nécessaire 7. Suivre la mise en œuvre des recommandations

Audit externe annuel : - Évaluation objective par un tiers - Scope plus large que l’audit interne - Rapport partagé avec les régulateurs si requis - Certification (ISO 27001, SOC 2) si pertinent

Warning

Les logs doivent être conservés dans un système séparé du système audité, avec des droits d’accès distincts. Des logs stockés sur le même système que celui qu’ils tracent peuvent être falsifiés ou supprimés en cas d’incident.

12 10. Incident Response — Plan de réponse

12.1 Processus de réponse aux incidents

flowchart TD
    DETECT["1. Détection\nMonitoring automatique\nAlerte utilisateur\nRapport tiers"] --> CONTAIN["2. Confinement\nIsoler les systèmes affectés\nPrévenir la propagation\nPréserver les preuves"]
    CONTAIN --> ASSESS["3. Évaluation\nScope de l'incident\nDonnées compromises ?\nSystèmes affectés ?\nImpact métier ?"]
    ASSESS --> NOTIFY["4. Notification\nÉquipe sécurité\nManagement\nDPO / RSSI\nRégulateurs (72h RGPD si données perso)\nPersonnes concernées si requis"]
    NOTIFY --> ERADICATE["5. Éradication\nSupprimer le code malveillant\nFermer les vulnérabilités\nRévoquer les accès compromis"]
    ERADICATE --> RECOVER["6. Restauration\nRestaurer depuis backups sains\nVérifier l'intégrité\nRetour progressif en production"]
    RECOVER --> POSTMORTEM["7. Post-incident\nAnalyse des causes racines\nMise à jour du plan\nAmélioration des contrôles\nDocumentation complète"]

12.2 Types d’incidents spécifiques GenAI

Breach de données via le modèle : - Un utilisateur a réussi à extraire des données confidentielles via des prompts - Action : isoler le système, identifier les données exfiltrées, notifier si données personnelles

Comportement anormal du modèle : - Outputs biaisés, discriminatoires ou dangereux - Action : désactiver temporairement le système, analyser les logs de requêtes, identifier la cause (données d’entraînement ? prompt injection ?)

Compromission d’un compte d’accès : - Credential d’un utilisateur ou d’un service compromis - Action : révoquer immédiatement, analyser les actions effectuées avec ce compte, évaluer l’exposition

Incident chez un vendor IA : - Le provider LLM a subi une breach ou a modifié ses conditions de rétention des données - Action : évaluer l’impact sur vos données, activer les clauses contractuelles, envisager la migration

12.3 Simulation obligatoire

Important

Un plan de réponse aux incidents qui n’a jamais été testé n’est pas un plan — c’est un document. Simuler au minimum une fois par an un scénario de breach réaliste pour votre contexte. Documenter les gaps identifiés et les corriger.

13 11. Compliance réglementaire — Processus continu

flowchart LR
    KNOW["Identifier le\npérimètre réglementaire"] --> IMPL["Implémenter politiques\net procédures"]
    IMPL --> TRAIN["Former\nles équipes"]
    TRAIN --> AUDIT["Audits internes\net externes"]
    AUDIT --> RIGHTS["Gérer les droits\ndes personnes concernées"]
    RIGHTS --> INCIDENT["Plan de réponse\naux incidents"]
    INCIDENT --> DOC["Documentation\net traçabilité"]
    DOC --> KNOW

13.1 Exigences spécifiques aux systèmes GenAI

Data privacy — protection GDPR/CCPA, chiffrement, contrôles d’accès, minimisation des données collectées.

Transparence algorithmique — les décisions assistées par le modèle doivent être auditables et explicables. Un utilisateur affecté par une décision IA doit pouvoir en comprendre la logique.

Bias & fairness — processus formel pour identifier et corriger les biais dans les outputs. Revue périodique des décisions du modèle par des humains.

Accountability — rôles clairs pour chaque outcome IA. Qui est responsable si le modèle produit un output problématique ?

Human oversight — pour les décisions à fort impact sur des personnes, un humain doit pouvoir valider ou annuler la décision du modèle.

Consent management — consentement explicite pour la collecte et l’usage des données dans le système IA. Processus de révocation du consentement.

Data anonymization — techniques de dépersonnalisation là où la collecte de données identifiantes n’est pas nécessaire.

Documentation — traçabilité complète du cycle de vie du modèle : données d’entraînement, décisions de conception, versions, modifications.

14 12. User Awareness Training

La sécurité technique ne suffit pas si les utilisateurs ne comprennent pas les risques. La formation est un contrôle de sécurité à part entière.

14.1 Programmes de formation par profil

GenAI Fundamentals — comprendre ce qu’est un LLM, ses capacités et ses limites. Savoir que le modèle peut halluciner, qu’il ne doit pas être utilisé pour des décisions critiques sans vérification humaine.

Security Awareness — reconnaître les tentatives de phishing et d’ingénierie sociale. Comprendre pourquoi on ne colle pas de données sensibles dans un prompt. Savoir quoi faire en cas de suspicion d’incident.

Ethical AI Practices — comprendre les biais dans les systèmes IA et leur impact. Importance de la transparence dans l’utilisation de l’IA. Responsabilité individuelle dans les décisions assistées par IA.

Data Handling & Privacy — techniques de chiffrement et de masquage. Contrôles d’accès et principe du moindre privilège. Anonymisation et pseudonymisation. Gestion sécurisée des credentials et des secrets.

Advanced AI Techniques — architectures de modèles, fine-tuning, évaluation de performances. Détection de biais dans les données d’entraînement. Sécurité des pipelines MLOps.

Troubleshooting & Support — diagnostic des problèmes courants. Procédures d’escalade. Documentation des incidents.

Regulatory Compliance — GDPR, CCPA, HIPAA et réglementations sectorielles. Droits des personnes concernées et obligations de l’organisation. Notification des breaches, délais légaux.

AI Governance — frameworks de gouvernance (NIST AI RMF, EU AI Act). Processus d’approbation et de décommissionnement. Responsabilités dans la chaîne de gouvernance.

14.2 Principes d’une formation efficace

  • Mix de méthodes : cours magistraux, labs pratiques, simulations de phishing, exercices de cas
  • Feedback et évaluation : tests de validation des acquis, métriques de complétion
  • Mise à jour continue : le paysage réglementaire et les menaces évoluent, la formation aussi
  • Fréquence : formation initiale à l’intégration + rappels annuels + alertes ad hoc sur les nouvelles menaces
  • Collaboration : partage des retours d’expérience entre équipes, culture de la sécurité collective
Tip

Mesurer l’efficacité de la formation avec des indicateurs concrets : taux de détection lors de simulations de phishing, nombre d’incidents causés par erreur humaine, taux de complétion des formations obligatoires.

15 Checklist opérationnelle complète

15.1 Cadrage initial

15.2 Politiques de données

15.3 Sécurité technique

15.4 Identity & Access Management

15.5 Approval Process & Registry

15.6 Risk Assessment

15.7 Behavioral Analytics & Monitoring

15.8 Third-Party & Vendors

15.9 Compliance & Audit

15.10 Incident Response

15.11 Formation & Sensibilisation

16 Ce que ce cadre ne remplace pas

Ce document couvre la gouvernance — le quoi encadrer, pourquoi et comment. Il ne remplace pas l’implémentation technique spécifique à votre stack : monitoring IA avec des outils comme Arize ou MLflow, implémentation RBAC dans AWS IAM ou Azure RBAC, détection de biais avec Fairlearn ou AI Fairness 360, pipelines MLOps pour la traçabilité des modèles.

Si vous voulez discuter de l’application de ce cadre à votre contexte, les coordonnées sont sur ce blog.