Sécuriser un déploiement d'IA générative en production en 2026 nécessite une discipline méthodique que cette checklist couvre en 80 points organisés en 8 phases : gouvernance, threat model, architecture & infra, guardrails input/output, identity & access, observability & monitoring, tests & audits, conformité & documentation. Cible : ≥ 90% ✓ pour go production sereine, 10 points bloqueurs dont un seul ✗ = no-go absolu (AI Officer identifié, DPIA, classification données, system prompt sans secrets, input classifier, output filter, rate limit, MFA, logs structurés, plan incident response). Cet article documente la checklist complète actionnable, les modalités d'utilisation (workflow J-30/J-7/post), l'adaptation par taille d'entreprise (PME 30 points MVP, ETI 50-60, GE 80), la maintenance dans le temps (cadence trimestrielle, versioning git, CI/CD intégré), et la stratégie evidence-driven pour audits externes (ISO 42001, SOC 2, EU AI Act conformity assessment). Cible : RSSI / AI Officer / lead AppSec préparant un go-live IA, équipes audit interne, auditeurs externes traversant un dossier.
Pour la roadmap démarrage projet : mon entreprise veut déployer un LLM, par où commencer côté sécurité. Pour la conformité réglementaire : audit conformité IA NIST/ISO/EU AI Act.
Comment utiliser cette checklist
Workflow recommandé
[J-30] Phase scoping
Parcours équipe (AI Officer + AI eng + AppSec + DPO + métier)
Pour chaque point : ✓ / ⚠ / ✗ + commentaire + owner + deadline
│
▼
[J-30 → J-7] Phase remédiation
Traiter ✗ critiques (bloqueurs)
Plan pour ⚠ (mitigation explicite)
│
▼
[J-7] Go/No-Go meeting
Scoring final
≥ 90% ✓ : GO sereine
75-90% ✓ : GO avec mitigations explicites des gaps documentées
< 75% ✓ : NO-GO, retour remédiation
│
▼
[Post-déploiement]
Re-eval trimestrielle + après changements majeurs
Versioning git de la checklist
Owner explicite responsable du suivi
Format
Tableau Excel / Notion / Confluence partagé, structure :
| # | Point | Phase | Status | Owner | Deadline | Commentaire | Preuve |
|---|---|---|---|---|---|---|---|
| 1 | AI Officer nommé | Gouvernance | ✓ | RSSI | J-60 | Marie Dupont mandatée 2026-02 | [lien charte] |
| 2 | DPIA réalisée | Gouvernance | ⚠ | DPO | J-15 | En cours rédaction | [draft] |
| ... | ... | ... | ... | ... | ... | ... | ... |
Phase 1, Gouvernance (10 points)
- [ ] 1.1 AI Officer ou responsable IA nommé avec mandat écrit signé direction
- [ ] 1.2 Politique d'usage IA pour employés rédigée, validée Legal/RH, signée par employés
- [ ] 1.3 Inventaire des cas d'usage IA prévus avec classification (Public / Internal / Confidential / Sensitive / High-risk)
- [ ] 1.4 DPIA réalisée si traitement données personnelles (validée DPO)
- [ ] 1.5 Identification régulations applicables (RGPD, EU AI Act haut risque ?, sectoriel : HDS, PCI-DSS)
- [ ] 1.6 Classification des données qui transitent dans les prompts définie et formalisée
- [ ] 1.7 Outil officiel IA d'entreprise déployé pour employés (anti-shadow AI : Copilot M365 / ChatGPT Enterprise / Mistral / etc.)
- [ ] 1.8 Comité IA défini avec cadence (réunion mensuelle ou trimestrielle minimum)
- [ ] 1.9 Plan formation interne défini (employés, AI eng, AppSec, AI Officer)
- [ ] 1.10 Budget AI Security formalisé an 1 + an 2-3 prévisionnelBloqueurs cette phase : 1.1, 1.4, 1.6, 1.7
Phase 2, Threat Model (8 points)
- [ ] 2.1 Data Flow Diagram (DFD) niveau 1 documenté (vue d'ensemble système)
- [ ] 2.2 DFD niveau 2 sur composants critiques (LLM call, RAG, agent tools)
- [ ] 2.3 Trust boundaries identifiées et formalisées (edge, frontend/backend, app/LLM, agent/tools)
- [ ] 2.4 Analyse STRIDE-PMCB par élément du DFD (10 catégories : STRIDE + Prompt injection / Model extraction / Cost / Blind trust)
- [ ] 2.5 Threat library priorisée DREAD ou matrice 2D (top 10-30 menaces)
- [ ] 2.6 Mapping OWASP LLM Top 10 v2 + MITRE ATLAS pour chaque menace
- [ ] 2.7 Mitigation plan par menace top 10 avec owner et deadline
- [ ] 2.8 Cadence de re-threat-modeling définie (annuel + déclencheurs ad hoc)Bloqueurs : 2.1, 2.5, 2.7
Phase 3, Architecture & Infrastructure (12 points)
- [ ] 3.1 Choix fournisseur LLM justifié par matrice pondérée critères (souveraineté, qualité, coût, conformité)
- [ ] 3.2 DPA (Data Processing Agreement) signé avec fournisseur si applicable
- [ ] 3.3 Architecture sécurité documentée (DFD + diagram réseau)
- [ ] 3.4 Network segmentation (VPC/VLAN dédié workloads IA, NetworkPolicies K8s deny-all + allow explicites)
- [ ] 3.5 Encryption in transit (TLS 1.3 partout, pas TLS 1.2 sur nouveaux services)
- [ ] 3.6 Encryption at rest (KMS pour secrets, modèles weights, embeddings, conversation memory)
- [ ] 3.7 Secrets management (HashiCorp Vault / AWS Secrets Manager / Azure Key Vault, pas de secrets en config map)
- [ ] 3.8 Workload identity (SPIFFE/SPIRE ou service mesh mTLS, pas d'API keys partagées)
- [ ] 3.9 GPU isolation si on-premise (taints/tolerations K8s, MIG, pas de mix workloads tiers)
- [ ] 3.10 Supply chain modèles : signature Sigstore, format safetensors, SBOM ML
- [ ] 3.11 Confidential Computing si menace insider crédible (Intel TDX / AMD SEV-SNP / NVIDIA H100 TEE)
- [ ] 3.12 Plan disaster recovery + multi-vendor failover si critiqueBloqueurs : 3.5, 3.6, 3.7
Phase 4, Guardrails Input/Output (12 points)
- [ ] 4.1 System prompt durci avec instruction hierarchy explicite
- [ ] 4.2 System prompt SANS aucun secret (codes, URLs admin, credentials)
- [ ] 4.3 Input classifier déployé (Lakera Guard / Llama Guard 3 / Rebuff / classifier maison fine-tuné HackAPrompt)
- [ ] 4.4 Score classifier monitoring (taux blocage, faux positifs)
- [ ] 4.5 Output filter PII redaction (Presidio ou équivalent)
- [ ] 4.6 Output sanitization HTML/markdown si rendu rich (bleach)
- [ ] 4.7 Output URL allowlist (anti-exfiltration, pas de markdown image vers domaines externes)
- [ ] 4.8 LLM-as-judge sur cas sensibles (volume faible, escalade conditionnelle)
- [ ] 4.9 RAG ingestion avec modération automatique (anti-RAG poisoning)
- [ ] 4.10 RAG filtrage tenant_id immutable côté serveur (pas dans prompt)
- [ ] 4.11 Si multimodal : OCR pre-check sur images (anti-Goodside-style injection)
- [ ] 4.12 Tests réguliers du couple input/output : taux succès attaque < 5% sur top 100 HackAPromptBloqueurs : 4.1, 4.2, 4.3, 4.5
Phase 5, Identity & Access (10 points)
- [ ] 5.1 Auth utilisateur : MFA obligatoire sur comptes ayant accès à app IA
- [ ] 5.2 OAuth on-behalf-of pour propagation identité utilisateur vers tools
- [ ] 5.3 Capability tokens scopés par requête (pas de service account broad)
- [ ] 5.4 RBAC fine-grained par feature / data
- [ ] 5.5 Si DB connectée : Row-Level Security (RLS) PostgreSQL/MySQL forcée
- [ ] 5.6 Si DB connectée : read-only role minimum (pas de DDL/DML write par défaut)
- [ ] 5.7 HaveIBeenPwned check au login (anti credential stuffing)
- [ ] 5.8 Session security standard (httpOnly cookies, CSRF, short TTL)
- [ ] 5.9 Token rotation automatique (TTL court 15min-1h)
- [ ] 5.10 Tests cross-user / cross-tenant : utilisateur A ne peut PAS accéder data utilisateur BBloqueurs : 5.1, 5.2, 5.10 (si multi-tenant)
Phase 6, Observability & Monitoring (10 points)
- [ ] 6.1 OpenTelemetry SDK instrumenté avec semantic conventions GenAI (gen_ai.* attributes)
- [ ] 6.2 Tracing distribué sur tous les agent steps (multi-LLM-call workflows)
- [ ] 6.3 Logs structurés JSON avec schéma versionné (request_id, user_id_hash, tokens, cost, etc.)
- [ ] 6.4 PII redaction automatique au log (Presidio sur prompt + response avant écriture)
- [ ] 6.5 Pseudonymisation user_id (HMAC SHA-256 avec sel env-specific)
- [ ] 6.6 Métriques Prometheus : llm_requests_total, llm_tokens_total, llm_cost_usd_total, llm_duration_seconds
- [ ] 6.7 Dashboards Grafana : Cost & Usage, Performance, Security, Quality (sample-based)
- [ ] 6.8 Alertmanager rules : cost anomaly per user/org, recursive loops, error rate spike
- [ ] 6.9 SIEM intégration (Splunk / Sentinel / Elastic) avec format OCSF + MITRE ATLAS tagging
- [ ] 6.10 UI prompts dédiée (Langfuse / Arize Phoenix) pour debug qualitatifBloqueurs : 6.3, 6.4, 6.6 (au moins cost), 6.8
Phase 7, Tests & Audits (10 points)
- [ ] 7.1 Test corpus métier construit (200-500 logs anonymisés + top 100 HackAPrompt + scenarios métier + adversarial generation)
- [ ] 7.2 Promptfoo intégré CI/CD : red team config sur chaque PR touchant prompts/modèle/tools
- [ ] 7.3 Garak scan automatisé mensuel sur l'app complète
- [ ] 7.4 PyRIT campagne trimestrielle (Crescendo + TAP + custom orchestrators)
- [ ] 7.5 Red team humain trimestriel (2 jours minimum sur top 10 menaces threat library)
- [ ] 7.6 Audit externe annuel (consultance ou red team indépendant)
- [ ] 7.7 Bug bounty interne ou externe sur app IA (pour critique)
- [ ] 7.8 Tests cross-user / cross-tenant automatisés en CI
- [ ] 7.9 Tests confused deputy pour agents (si applicable)
- [ ] 7.10 Cible mesurée : taux succès attaque < 5% sur corpus standard, < 15% sur multi-turn CrescendoBloqueurs : 7.1, 7.2 (au minimum)
Phase 8, Conformité & Documentation (8 points)
- [ ] 8.1 RGPD : DPIA archivée, mention info utilisateur (chatbot IA), droit erasure implémenté
- [ ] 8.2 EU AI Act : classification risque déterminée (high-risk Annex III ou non), obligations identifiées
- [ ] 8.3 Documentation technique (Art. 11 EU AI Act) : DFD + threat model + SBOM ML + system architecture
- [ ] 8.4 Logs conformes obligations (Art. 12 EU AI Act, RGPD) : structure + rétention + chiffrement
- [ ] 8.5 Plan incident response documenté : runbooks par type incident, on-call rotation, escalade
- [ ] 8.6 Communication crise prête : template communication interne, externe (clients, presse, autorités)
- [ ] 8.7 Conformité sectorielle si applicable (HDS santé, PCI-DSS finance, secret défense, etc.)
- [ ] 8.8 Politique de retention et destruction des données (logs, conversations, fine-tuning datasets)Bloqueurs : 8.1, 8.5
Les 10 points absolument bloqueurs (récap)
Si un seul est ✗, ne pas mettre en production :
- AI Officer / responsable identifié (1.1)
- DPIA réalisée si données personnelles (1.4)
- Classification données effectuée (1.6)
- System prompt sans secrets (4.2)
- Input classifier déployé (4.3)
- Output filter PII redaction (4.5)
- Rate limiting & token budget (3 + 6.8)
- MFA sur comptes sensibles (5.1)
- Logs structurés avec audit trail (6.3)
- Plan incident response (8.5)
En-dessous de ces 10 = théâtre de sécurité, déploiement irresponsable.
Adaptation par taille d'entreprise
PME (< 500 employés), MVP
Focus 10 bloqueurs + ~20 points complémentaires choisis selon cas d'usage.
Sélection MVP :
- Phase 1 : 1.1, 1.2, 1.4, 1.6, 1.7
- Phase 2 : 2.1, 2.5, 2.7
- Phase 3 : 3.5, 3.6, 3.7
- Phase 4 : 4.1, 4.2, 4.3, 4.5, 4.7
- Phase 5 : 5.1, 5.2, 5.10
- Phase 6 : 6.3, 6.4, 6.6, 6.8
- Phase 7 : 7.1, 7.2, 7.3
- Phase 8 : 8.1, 8.5
Total : ~30 points pour MVP. Étendre vers 50+ à 12 mois.
Profil équipe : 0.5-1 ETP AI Security (RSSI étendu), pas d'AI Officer dédié.
ETI (500-5000 employés)
50-60 points couverts avec rigueur, AI Officer dédié, audit externe annuel obligatoire.
Atteindre :
- 100% phases 1, 4, 5
- 80% phases 2, 3, 6, 7
- 60% phase 8 (selon régulations applicables)
Total : 60+ points effectifs.
Grande entreprise (5000+)
100% des 80 points, équipe AI Security dédiée, governance committee, conformité multi-juridictions.
Cible : 95%+ ✓ avec preuves complètes.
Startup IA pure
Focus produit + sécurité élémentaire (10 bloqueurs) + audit avant levée série A/B.
Pragmatique : viser 30 points solides, démontrer maturité plutôt qu'épaisseur.
Secteur régulé (santé, finance, défense)
100% peu importe la taille + exigences sectorielles supplémentaires :
- Santé : HDS, ISO 27001, anonymisation médicale stricte
- Finance : PCI-DSS, conformité ACPR, MAS
- Défense : secret défense, certifications, on-premise air-gap
- Public sector EU : souveraineté EU stricte (Mistral / on-premise prioritaire)
Maintenance dans le temps
Cadence revue
| Cadence | Action |
|---|---|
| Continu (CI/CD) | Points automatisables vérifiés (Promptfoo CI vert, secrets scan vert) |
| Mensuel | Review bloqueurs + points critical avec owner |
| Trimestriel | Revue complète checklist par AI Officer + équipe |
| Annuel | Refresh complet incluant évolution standards (OWASP version, EU AI Act) |
| Ad hoc | Après changement majeur, incident, nouvelle menace |
Versioning
# La checklist vit dans un repo
git/
├── checklist/
│ ├── current.md # version courante
│ ├── v1.md # archives versions
│ ├── v2.md
│ └── changelog.mdChaque modification commitée avec rationale. Permet d'auditer évolution.
Intégration CI/CD
Certains points automatisables :
# .github/workflows/security-checklist-validation.yml
name: Security Checklist Automated Checks
on:
pull_request:
schedule:
- cron: '0 6 * * 1' # Lundi 6h
jobs:
validate:
runs-on: ubuntu-latest
steps:
# 4.12, Tests red team passants
- name: Promptfoo redteam
run: promptfoo redteam run --config redteam.yaml
# 7.3, Garak scan
- name: Garak scan
run: |
garak --config garak-config.json
# Fail si nouvelles vulns critiques détectées
# 3.7, Pas de secrets en clair
- name: Secret scan
run: |
gitleaks detect
trufflehog filesystem .
# 6.6, Métriques Prometheus exposées
- name: Verify Prometheus endpoints
run: |
curl -f https://app.prod/metrics
# Vérifier que les métriques attendues existent
# Autres checks automatisables...Réduit charge revue manuelle. Ne remplace pas la revue humaine pour points complexes.
Stratégie evidence-driven pour audits
Pour chaque point ✓, garder preuve
### Point 4.3, Input classifier déployé
**Status** : ✓
**Owner** : Marie Dupont (AI Officer)
**Date évaluation** : 2026-04-15
**Preuves** :
- [Code] PR #1247, déploiement Lakera Guard middleware
https://github.com/zerodaysupport/chatbot/pull/1247
- [Config] `infra/k8s/llm-prod/lakera-config.yaml` (versionné)
- [Logs] Dashboard Grafana `Guardrails Performance`
https://grafana.internal/d/guardrails-perf/
- [Tests] Rapport Promptfoo dernier run vert
https://promptfoo.internal/runs/2026-04-15
- [Mesure] FPR < 0.5%, taux blocage attaques connues > 95%
**Validé par** : Jean Martin (RSSI), 2026-04-16
**Re-évaluation** : Q3 2026Base de preuves Notion/Confluence
Workspace AI Security
├── Checklist 80 points
│ ├── Phase 1 Gouvernance
│ │ ├── 1.1 AI Officer ↳ [doc charte] [signature]
│ │ ├── 1.2 Politique usage IA ↳ [doc] [signatures employés]
│ │ └── ...
│ ├── Phase 2 Threat Model
│ │ ├── 2.1 DFD ↳ [diagram] [version 2.3]
│ │ └── ...
│ └── ...
└── Évidences par point
└── (pour chaque point, page dédiée avec preuves listées)
Auditeur traverse rapidement, perd peu de temps à chercher.
Pour certifications
ISO 42001, SOC 2 type 2, EU AI Act conformity assessment : la checklist + preuves = base directe du dossier audit. Économise 50-70% du temps.
Cycle recommandé :
[Audit interne 6 mois avant]
Identifier gaps
│
▼
[Remédiation]
Fixer les gaps identifiés
│
▼
[Audit externe / certification]
Pas de surprise, auditeur ne voit que des points ✓ avec preuves
Critères de qualité de la checklist
Une bonne checklist a
- Owner explicite : 1 personne responsable maintenance
- Cadence revue : trimestrielle minimum
- Versioning git : traçabilité évolution
- Integration CI/CD : automatisation où possible
- Preuves attachées : pas juste "✓", mais "✓ + preuve"
- Adaptation contexte : pas 80 points pour une PME MVP
- Évolution avec standards : suit OWASP versions, EU AI Act phases
Une mauvaise checklist a
- Document orphelin sans owner
- "One-shot" au lancement, jamais re-revue
- Tous les points ✓ sans preuve (théâtre)
- Identique pour PME et grande entreprise (incohérent)
- Pas mis à jour avec OWASP v2 ou EU AI Act
- Stockée dans email / sharepoint perdu
Erreurs récurrentes en utilisant cette checklist
Erreur 1, Cocher sans preuve
"4.3 ✓" sans rien derrière. Inacceptable. Toujours preuve attachée.
Erreur 2, Ne pas adapter à la taille
PME qui essaie 80 points = paralysie. MVP 30 points solides, étendre ensuite.
Erreur 3, Pas d'owner
Document collectif → personne ne maintient. Owner explicite.
Erreur 4, Pas de cadence
Audit lancement, plus rien. Revue trimestrielle minimum.
Erreur 5, Pas d'évolution
Checklist 2024 toujours utilisée en 2026 sans update. Suivre standards (OWASP v2, EU AI Act, etc.).
Erreur 6, Bloqueurs ignorés
"On verra plus tard pour MFA". Non. Bloqueurs sont bloqueurs.
Erreur 7, Pas d'automatisation
Tout en revue manuelle = charge ingérable. CI/CD pour points automatisables.
Ce que vous devriez retenir
- 80 points en 8 phases : gouvernance, threat model, archi, guardrails, identity, observability, tests, conformité
- 10 bloqueurs : un seul ✗ = no-go production
- Cible : ≥ 90% ✓ pour go sereine
- Adaptation taille : PME 30 points MVP, ETI 50-60, GE 80
- Workflow : J-30 scoping → J-7 go/no-go → trimestriel post-déploiement
- Evidence-driven : chaque ✓ a une preuve vérifiable
- Maintenance : owner + cadence + versioning git + CI/CD
- Évolution : suivre OWASP versions, EU AI Act, standards émergents
Cette checklist n'est pas un document statique. C'est un outil de pilotage actif qui orchestre la sécurité IA de l'organisation. Bien utilisée, elle économise des mois de remédiation post-incident et facilite massivement les audits / certifications.
Pour aller plus loin : si vous attaquez un projet IA depuis zéro, démarrer avec par où je commence côté sécurité. Si vous avez une app en place et voulez auditer : aide-moi à auditer la sécurité de mon chatbot d'entreprise. Pour la base théorique OWASP : article suivant du cluster.
