Chapitre 4 — Déploiement : sécurité, gouvernance et conduite du changement

Les 6 étapes du déploiement IA souverain

Un déploiement IA souverain réussi suit une progression logique. Sauter des étapes est la principale cause d'échec des projets IA en entreprise — non pas parce que la technologie ne fonctionne pas, mais parce que l'organisation n'est pas prête à l'absorber.

Étape 1 : Audit de l'existant (semaines 1-3)

Avant de décider ce que vous allez déployer, vous devez savoir ce qui existe déjà. L'audit de l'existant couvre quatre dimensions :

Dimension 1 — Cartographie des outils IA en usage : Listez exhaustivement tous les outils IA utilisés dans l'organisation, qu'ils soient sanctionnés par la DSI ou non (Shadow IA). Méthodes : sondage auprès des directeurs métier, analyse du DNS et des logs proxy pour détecter les accès aux LLM publics, entretiens avec les équipes les plus susceptibles d'utiliser l'IA (développement, marketing, juridique, RH, finance).

Dimension 2 — Évaluation des risques actuels : Pour chaque outil identifié, évaluez : quelles données y sont saisies, quelle est l'exposition réglementaire (RGPD, AI Act), quel est le contrat en place (y a-t-il un DPA), quelles sont les clauses de traitement des données. Ce travail est souvent révélateur : la majorité des organisations découvrent à ce stade des violations RGPD en cours.

Dimension 3 — Évaluation de la maturité technique : Avez-vous les compétences internes pour opérer une infrastructure IA souveraine ? (MLOps, GPU admin, DevSecOps) Quelle est votre infrastructure actuelle (datacenter propre, colocation, cloud) ? Quels sont vos systèmes d'identité, de monitoring, de sécurité en place ? Voir notre grille d'évaluation de la maturité IA.

Dimension 4 — Identification des cas d'usage prioritaires : Quels sont les 3 à 5 cas d'usage IA qui apporteraient le plus de valeur à l'organisation ? Critères de priorisation : impact métier (ROI estimé), faisabilité technique (données disponibles et de qualité, cas d'usage clairement défini), acceptabilité réglementaire (niveau de risque AI Act, sensibilité des données), appétit de l'organisation (existe-t-il un sponsor métier enthousiaste pour ce cas d'usage).

Étape 2 : Cahier des charges et architecture (semaines 4-8)

Sur la base de l'audit, vous pouvez maintenant rédiger un cahier des charges pour votre déploiement IA souverain. Ce cahier des charges doit couvrir :

• Périmètre fonctionnel : Les 1 à 3 cas d'usage retenus pour le PoC, avec des critères de succès mesurables (ex : «Le système répond correctement à 90 % des questions sur nos contrats types dans un délai < 5 secondes»)
• Exigences de conformité : RGPD (base légale, AIPD, droits des personnes), AI Act (niveau de risque, obligations), NIS2 si applicable
• Exigences de sécurité : Chiffrement, contrôle d'accès, audit logs, isolement réseau, red teaming
• Exigences de performance : Latence maximale acceptable, débit (requêtes/minute), disponibilité (SLA)
• Exigences d'intégration : Systèmes existants à connecter, protocoles (SSO, API), formats de données
• Budget et ressources : Budget infrastructure, budget prestataires, ressources internes allouées
• Décision build/buy/hybrid : Voir notre guide de décision build vs buy

Étape 3 : Proof of Concept (semaines 9-16)

Le PoC est l'étape la plus critique et la plus souvent bâclée. Son objectif n'est pas de «montrer que l'IA fonctionne» — tout le monde sait que les LLM fonctionnent. Son objectif est de répondre à des questions spécifiques sur votre contexte :

• Ce modèle (ELODIE 32B, Mistral, etc.) répond-il à nos critères de performance sur nos données réelles ?
• L'architecture choisie (RAG, fine-tuning) est-elle viable techniquement dans notre environnement ?
• Les équipes métier sont-elles capables d'utiliser le système de façon productive ?
• Les processus de gouvernance (validation, audit) sont-ils praticables ?

Un PoC efficace dure 6 à 8 semaines, implique 5 à 20 utilisateurs réels (pas des développeurs, mais les futurs utilisateurs cibles), et se mesure avec des métriques prédéfinies. Évitez les PoC de 2 semaines avec des données fictives : ils ne prouvent rien.

Pour aller plus loin : notre guide complet pour réussir un PoC IA en entreprise.

Étape 4 : Pilote production (mois 5-8)

Si le PoC conclut positivement, le pilote étend le déploiement à un groupe plus large d'utilisateurs (50 à 200) sur des données de production réelles. C'est à ce stade que :

• La gouvernance IA est formalisée (charte, comité, processus)
• La formation des utilisateurs est déployée à l'échelle du groupe pilote
• Le monitoring en production est mis en place
• Les premiers incidents sont gérés et documentés
• Le TCO réel commence à être mesuré (voir notre analyse TCO)

Étape 5 : Généralisation (mois 9-18)

La généralisation est l'extension du pilote à l'ensemble des utilisateurs cibles. Elle nécessite : un plan de formation structuré pour l'ensemble des populations, une infrastructure dimensionnée pour le pic de charge (et pas seulement pour la charge moyenne), un helpdesk IA formé pour répondre aux questions et incidents utilisateurs, une communication interne continue sur les usages acceptables et les interdictions.

Étape 6 : Industrialisation (mois 19+)

L'industrialisation transforme le projet IA en service permanent de l'organisation. Elle inclut : les processus MLOps (CI/CD pour les modèles, monitoring continu, gestion du drift), la gouvernance à l'échelle (comité de pilotage trimestriel, KPIs stratégiques, reporting COMEX), l'extension à de nouveaux cas d'usage (sur la base des apprentissages des premiers déploiements), et la mise à jour régulière des modèles. Le Chapitre 6 de ce Livre Blanc détaille l'industrialisation et le passage à l'échelle.

Sécurité by design pour les LLM souverains

Principes fondamentaux

La sécurité d'un système LLM souverain repose sur 5 principes :

Zero-trust pour l'accès au LLM : Aucun utilisateur, aucun service, aucune application n'est autorisé par défaut à accéder au LLM. Chaque accès doit être explicitement authentifié et autorisé. Cela implique : authentification forte (MFA) pour tous les utilisateurs, tokens d'API à durée de vie limitée pour les services applicatifs, rotation automatique des clés d'API, révocation immédiate des accès en cas de départ ou d'incident.

Cloisonnement réseau : Le serveur d'inférence LLM doit être sur un segment réseau isolé (VLAN dédié ou micro-segmentation). Les seuls flux autorisés sont : les requêtes provenant des applications autorisées (whitelist d'IP/FQDN), les connexions d'administration depuis le bastion/jump host, les flux de monitoring vers le système d'observabilité. Le LLM ne doit pas avoir accès à Internet (sauf si un accès web est explicitement requis pour un cas d'usage agent, et alors via un proxy avec whitelist de domaines).

Chiffrement bout en bout : Tous les échanges avec le LLM (prompts, contextes, réponses) doivent être chiffrés en transit (TLS 1.3 minimum). Les données stockées (logs, bases vectorielles, modèles) doivent être chiffrées au repos (AES-256). Les clés de chiffrement doivent être gérées dans un HSM ou un gestionnaire de secrets souverain (Vault, AWS KMS ne convient pas pour les données très sensibles).

Audit logs complets et immuables : Journalisez absolument tout : chaque requête (identifiant utilisateur, timestamp, IP source, modèle utilisé, tokens), chaque réponse (hash du contenu, latence), chaque anomalie détectée. Les logs doivent être stockés dans un système immuable (WORM — Write Once Read Many) et conservés selon les obligations réglementaires (1 an minimum pour RGPD, 3 ans pour NIS2, 5 ans pour DORA).

Red teaming et tests continus : Les LLM présentent des vulnérabilités spécifiques qui s'ajoutent aux vulnérabilités applicatives classiques. Planifiez des sessions régulières de red teaming IA :

• Prompt injection : Tentatives d'injecter des instructions malveillantes dans les données traitées par le LLM pour détourner son comportement
• Jailbreak : Tentatives de contourner les guardrails de sécurité du modèle
• Exfiltration d'information : Tentatives d'extraire via le LLM des informations présentes dans sa base de connaissances ou son contexte qui ne devraient pas être accessibles à l'utilisateur
• Data poisoning : Tentatives d'injecter des documents malveillants dans la base RAG pour influencer les réponses du LLM

Architecture de sécurité de référence

Voici les composants d'une architecture de sécurité LLM souverain de référence :

Internet / Utilisateurs
        |
[WAF + Rate Limiter] (protection DDoS, injection)
        |
[API Gateway + Auth] (SSO OIDC, RBAC, tokens)
        |
[Guardrails Layer] (PII detection, content filtering, prompt injection detection)
        |
[Load Balancer] (haute disponibilité, routage canary)
        |
[vLLM / TGI Server] (inférence LLM - réseau isolé)
   |
   ├── [LLM Model Store] (modèles chiffrés au repos)
   ├── [Vector DB] (Qdrant, chiffré, réseau isolé)
   └── [Cache] (Redis, résultats fréquents)
        |
[Audit Logger] (WORM, immuable)
        |
[SIEM / Monitoring] (Grafana, alerting)

Guardrails : contrôles de contenu et de comportement

Les guardrails sont des couches de contrôle qui s'interposent entre les utilisateurs et le LLM pour :

• Détection et masquage des PII : Scanner les prompts entrants et les réponses sortantes pour détecter et pseudonymiser les données personnelles avant de les logger (RGPD compliance)
• Filtrage de contenu : Bloquer les requêtes visant à générer du contenu illégal, des informations sensibles non autorisées, ou des contenus contraires à la politique de l'entreprise
• Détection de prompt injection : Identifier les patterns caractéristiques des attaques par injection de prompt dans les documents soumis au RAG
• Contrôle d'accès aux données : Dans un contexte multi-utilisateurs, s'assurer qu'un utilisateur ne peut pas, via le LLM, accéder à des documents appartenant à un autre département ou classifiés au-delà de son niveau de permission

Des solutions open source comme LLM Guard, NeMo Guardrails (NVIDIA), ou Guardrails AI permettent d'implémenter ces contrôles. Pour les secteurs très sensibles (santé, défense, finance systémique), des solutions commerciales de guardrails certifiées existent.

Gouvernance IA : comité, charte et processus

Le Comité de Gouvernance IA

La gouvernance IA ne peut pas être uniquement une responsabilité DSI. Elle requiert une représentation transverse de l'organisation. Composition recommandée du Comité de Gouvernance IA :

• Président : Le DSI ou le CDO (Chief Digital Officer)
• Membres permanents : DPO, RSSI, Directeur Juridique, représentant RH, représentant Finance
• Membres tournants : Représentants des directions métier ayant des projets IA en cours
• Fréquence : Mensuelle pendant les phases de déploiement actif, trimestrielle en régime de croisière

Missions du comité : valider les nouveaux cas d'usage IA avant déploiement, réviser les incidents IA significatifs, approuver les mises à jour de la charte IA, suivre les KPIs de conformité et d'adoption, arbitrer les conflits entre exigences métier et exigences de conformité.

La Charte IA de l'entreprise

La charte IA est le document fondateur de votre gouvernance. Elle doit être approuvée par la direction générale et communiquée à l'ensemble des collaborateurs. Elle couvre :

Section 1 — Principes directeurs : Les valeurs qui guident l'utilisation de l'IA dans l'organisation (transparence, responsabilité, équité, protection des données, humanité dans la boucle). Ce n'est pas du droit : c'est de la culture d'entreprise.

Section 2 — Outils autorisés et interdits : Liste précise des outils IA autorisés (avec les conditions d'usage), les outils en cours d'évaluation (usage en sandbox uniquement), et les outils explicitement interdits (avec la justification). Cette liste doit être maintenue à jour et communiquée à chaque mise à jour.

Section 3 — Données autorisées et interdites : Classification des données par niveau de sensibilité et règles pour chaque niveau. Exemple :

• Données publiques : peuvent être saisies dans tout outil autorisé
• Données internes non sensibles : uniquement dans les outils approuvés par la DSI
• Données personnelles clients/salariés : uniquement dans les outils souverains avec AIPD validée
• Données confidentielles (brevets, données financières non publiées) : uniquement dans les systèmes on-premise, jamais dans un LLM externe
• Données classifiées (défense, OIV) : interdites dans tout LLM sauf systèmes certifiés Diffusion Restreinte

Section 4 — Processus de validation des nouveaux usages : Formulaire de demande, critères d'évaluation (impact, risque, conformité), délais de traitement, processus d'appel. Sans ce processus, les métiers contournent la DSI.

Section 5 — Responsabilités et sanctions : Qui est responsable de quoi, que se passe-t-il en cas de violation de la charte (avertissement, sanctions disciplinaires pour les cas graves).

Le processus de validation des nouveaux usages IA

Un processus efficace de validation des nouveaux usages IA doit être suffisamment rigoureux pour protéger l'organisation, mais suffisamment rapide pour ne pas étouffer l'innovation. Voici un processus en 4 niveaux :

Niveau 1 — Usage standard (1 jour) : L'usage utilise un outil déjà approuvé avec des données déjà autorisées pour cet outil. Validation automatique par le système (pas de comité). Exemple : utiliser ELODIE pour rédiger un e-mail interne.

Niveau 2 — Usage étendu (5 jours ouvrés) : L'usage utilise un outil approuvé mais avec un type de données ou une finalité non encore autorisée. Validation par le DPO et le DSI. Peut nécessiter une AIPD simplifiée.

Niveau 3 — Nouveau projet IA (4 à 6 semaines) : Déploiement d'un nouveau système IA (nouveau modèle, nouvelle architecture, nouveau cas d'usage structurant). Validation par le Comité de Gouvernance IA, AIPD complète, revue architecture sécurité.

Niveau 4 — Système à haut risque AI Act (2 à 3 mois) : Déploiement d'un système classé haut risque par l'AI Act (RH, crédit, santé, infrastructure). Validation Comité + Conseil d'Administration si impact significatif, AIPD complète, documentation technique AI Act, tests de biais et de robustesse.

Gestion des données dans un projet IA souverain

Cartographie des données

Avant tout déploiement IA, cartographiez les données qui seront traitées par le système. Cette cartographie doit couvrir :

• Nature des données (personnelles/non personnelles, catégories spéciales, données confidentielles)
• Origine des données (systèmes sources, format, fréquence de mise à jour)
• Propriétaire des données (quelle direction métier est responsable de la qualité)
• Niveau de classification (public, interne, confidentiel, secret)
• Obligations de rétention (légale, contractuelle, opérationnelle)

Classification et accès différencié

Toutes les données ne doivent pas être accessibles à tous les utilisateurs du LLM. Implémentez une couche de contrôle d'accès aux données dans votre architecture RAG :

• Taggez chaque document dans votre base vectorielle avec ses métadonnées de classification et ses permissions d'accès
• Filtrez les résultats de retrieval selon les permissions de l'utilisateur authentifié avant de les injecter dans le contexte du LLM
• Auditez les tentatives d'accès à des documents au-delà des permissions de l'utilisateur

Droit à l'effacement et IA

Le droit à l'effacement (art. 17 RGPD) crée une obligation technique complexe pour les systèmes IA. Pour chaque type de données dans votre système IA, définissez à l'avance la procédure d'effacement :

• Données dans la base RAG : Suppression du document source + regénération des embeddings correspondants. Délai : typiquement < 24 heures avec un pipeline automatisé.
• Données dans les logs d'audit : Pseudonymisation (remplacement des identifiants par des hashes) plutôt que suppression complète (les logs sont nécessaires pour la conformité NIS2/DORA). Délai : < 72 heures.
• Données dans un modèle fine-tuné : Cas le plus complexe. Si les données d'une personne ont été utilisées pour le fine-tuning, l'effacement complet nécessite de réentraîner le modèle sans ces données. C'est la raison principale pour laquelle nous recommandons de ne pas fine-tuner sur des données personnelles.

Formation et adoption : transformer les utilisateurs en alliés

Profils cibles et besoins de formation

La formation IA ne peut pas être générique. Identifiez 4 profils cibles avec des besoins distincts :

Profil 1 — Utilisateurs finaux (80 % de la population) : Ont besoin de savoir comment utiliser le LLM efficacement pour leurs tâches quotidiennes, ce qu'ils peuvent et ne peuvent pas saisir, et comment interpréter les sorties du LLM (vérification des faits, limites du modèle). Formation : 2 heures, e-learning + atelier pratique sur leurs cas d'usage réels.

Profil 2 — Power users / Champions IA (10 % de la population) : Capables de construire des prompts avancés, d'utiliser les fonctionnalités avancées (agents, intégrations API), de former leurs collègues. Formation : 1 à 2 jours, atelier intensif, accès à un environnement de sandbox.

Profil 3 — Équipes DSI / développeurs (5 %) : Doivent comprendre l'architecture, les APIs, l'intégration avec le SI, les bonnes pratiques de prompt engineering et de RAG. Formation : 3 à 5 jours, formation technique approfondie, certification si disponible.

Profil 4 — Management et COMEX (5 %) : Ont besoin de comprendre les enjeux stratégiques, les risques, et les KPIs — pas les détails techniques. Formation : 3 heures, séance de sensibilisation + simulation de cas d'usage stratégiques.

KPIs d'adoption

Mesurez l'adoption avec des indicateurs concrets :

• Taux d'activation : % des utilisateurs ayant effectué au moins 5 requêtes dans le mois suivant leur formation
• Utilisation régulière : % des utilisateurs actifs mensuellement (MAU) / hebdomadairement (WAU)
• Volume de requêtes par utilisateur actif : Indicateur de l'intensité d'usage
• NPS interne : Satisfaction des utilisateurs vis-à-vis de l'outil (sondage mensuel)
• Taux de déflexion des outils non autorisés : Baisse des accès aux LLM non approuvés (mesurable via les logs proxy)

Gestion de la résistance au changement

Les freins à l'adoption d'un LLM souverain sont souvent émotionnels et culturels plus que techniques :

«Le nouveau LLM est moins bon que ChatGPT» : Souvent vrai pour des tâches génériques ; faux pour des tâches métier spécialisées. Réponse : démontrer par les faits sur les cas d'usage réels de l'équipe, pas sur des benchmarks génériques.

«L'IA va remplacer mon travail» : Anxiété légitime qui doit être traitée ouvertement. Réponse : framing explicite «l'IA comme assistant, pas comme remplaçant», et démonstration concrète que l'IA libère du temps pour les tâches à plus haute valeur ajoutée.

«Je ne vois pas l'intérêt pour mon travail spécifique» : Problème de pertinence. Réponse : atelier de découverte co-animé avec un champion métier qui identifie les cas d'usage pertinents pour l'équipe, puis prototype rapide (2 heures) d'un assistant adapté.

Gestion des incidents IA

Taxonomie des incidents IA

Les incidents liés aux systèmes IA se classent en 5 catégories :

• Incident de disponibilité : Le LLM ne répond pas ou répond lentement. Traitement : standard IT (monitoring, SLA, escalade).
• Incident de qualité : Le LLM produit des réponses incorrectes, biaisées ou inadaptées de façon systématique. Traitement : analyse des cas, évaluation de la dégradation du modèle, mise à jour ou rollback.
• Incident de sécurité : Tentative ou succès d'attaque (prompt injection, exfiltration). Traitement : procédure de réponse à incident cybersécurité classique + spécificités IA.
• Incident de données : Accès non autorisé à des données via le LLM, ou fuite de données dans les sorties du LLM. Traitement : qualification RGPD (violation notifiable à la CNIL ?), isolation du système, investigation.
• Incident réglementaire : Décision automatisée non conforme AI Act, utilisation non documentée d'un système haut risque. Traitement : rapport interne, évaluation de la notification aux autorités, remédiation.

Playbook d'incident IA (résumé)

Détection : Les alertes de monitoring (latence, erreurs, anomalies de pattern) ou un signalement utilisateur déclenchent l'incident. Un astreinte IA (distinct de l'astreinte IT classique si le système est critique) est contactée.

Qualification (30 minutes) : L'astreinte détermine la catégorie d'incident, son périmètre (combien d'utilisateurs, quelles données, depuis combien de temps), et son niveau de criticité. Les incidents de données déclenchent immédiatement l'implication du DPO.

Containment (2 heures) : Selon la nature : isolation du modèle affecté (basculement sur une version précédente), blocage des requêtes d'un utilisateur compromis, isolation de la base RAG si compromission suspectée.

Investigation et remédiation (24 à 72 heures) : Analyse forensique des logs, identification de la cause racine, correction, tests avant remise en service.

Post-mortem (1 semaine) : Rapport écrit : chronologie, impact, cause racine, actions correctives, mesures préventives. Présentation au Comité de Gouvernance IA.

KPIs de déploiement IA souverain

Mesurez le succès de votre déploiement sur 4 dimensions :

Questions fréquentes

Conclusion

Le déploiement d'une IA souveraine est autant un projet managérial qu'un projet technique. La sécurité by design, la gouvernance formalisée, et la conduite du changement structurée sont les trois piliers qui distinguent les déploiements réussis des projets qui s'enlisent.

Pour construire le business case de votre projet auprès du COMEX, le Chapitre 5 de ce Livre Blanc fournit une méthode complète de calcul du ROI avec des chiffres sectoriels réels.