648 lines
52 KiB
Markdown
648 lines
52 KiB
Markdown
**AI GOVERNANCE HUB**
|
||
|
||
Product Requirements Document & Technical Architecture
|
||
|
||
MVP Specification — Version 1.0
|
||
|
||
**CONFIDENTIEL — Février 2026**
|
||
|
||
Plateforme de gouvernance centralisée pour les flux IA en entreprise
|
||
|
||
|
||
# 1. Executive Summary
|
||
|
||
AI Governance Hub est une plateforme SaaS B2B qui agit comme proxy intelligent entre les utilisateurs d’une entreprise et l’ensemble de ses modèles IA (internes et externes). La plateforme répond à un besoin critique et immédiat des DSI, RSSI et responsables conformité : reprendre le contrôle sur les flux IA, éliminer le Shadow AI, et préparer la conformité au Règlement européen sur l’IA (AI Act) dont les premières obligations s’appliquent dès 2025.
|
||
|
||
## 1.1 Proposition de valeur
|
||
|
||
**Pour le DSI :** Visibilité complète sur les usages IA, maîtrise des coûts, rationalisation des fournisseurs.
|
||
|
||
**Pour le RSSI :** Prévention des fuites de données sensibles (PII), journalisation intégrale, détection d’anomalies, contrôle d’accès granulaire.
|
||
|
||
**Pour le DPO / Compliance :** Registre des traitements automatisé, rapports RGPD générés, classification des risques AI Act, traçabilité bout en bout.
|
||
|
||
**Pour les utilisateurs métier :** Accès unifié et transparent aux IA autorisées, sans friction ni changement d’habitudes majeur.
|
||
|
||
## 1.2 Marché et timing
|
||
|
||
Le marché de la gouvernance IA est estimé à plusieurs milliards d’euros d’ici 2028. L’entrée en vigueur progressive de l’AI Act européen (février 2025 pour les IA interdites, août 2025 pour les obligations générales, août 2026 pour les systèmes à haut risque) crée une urgence réglementaire qui accélère la demande. La fenêtre d’opportunité est ouverte maintenant.
|
||
|
||
# 2. Définition du MVP
|
||
|
||
## 2.1 Périmètre fonctionnel MVP (V1)
|
||
|
||
Le MVP se concentre sur les fonctionnalités strictement nécessaires pour démontrer la valeur auprès d’un premier client pilote et fermer un premier contrat enterprise.
|
||
|
||
| **Module** | **Fonctionnalité MVP** | **Priorité** |
|
||
|-------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------|----------------|
|
||
| AI Proxy / Gateway | Reverse proxy interceptant toutes les requêtes vers les LLMs (OpenAI, Anthropic, Azure OpenAI, Mistral). Support streaming SSE. | P0 — Critique |
|
||
| Routage intelligent | Règles statiques par département/sensibilité. Fallback automatique. Routing vers modèle on-prem ou cloud selon politique. | P0 — Critique |
|
||
| Anonymisation PII | Détection hybride (regex + NER Presidio). Redaction en temps réel dans les prompts. Pseudonymisation réversible avec mapping chiffré. | P0 — Critique |
|
||
| Journalisation | Logging structuré de chaque requête/réponse (métadonnées, hash du contenu, user, modèle, tokens, coût). Stockage chiffré AES-256. | P0 — Critique |
|
||
| RBAC | Gestion des rôles (Admin, Manager, User, Auditor). Contrôle d’accès par modèle et par département. Intégration SSO SAML 2.0. | P0 — Critique |
|
||
| Dashboard sécurité | Vue temps réel : volume de requêtes, PII détectées, coûts par modèle/département, alertes basiques. | P1 — Important |
|
||
| Rapports conformité | Export PDF/CSV du registre des traitements IA. Mapping articles RGPD. Classification risque AI Act basique (interdit/haut risque/limité/minimal). | P1 — Important |
|
||
| Monitoring tokens/coûts | Comptage tokens par requête, agrégation par utilisateur/département/modèle. Alertes de budget. | P1 — Important |
|
||
|
||
## 2.2 Hors scope MVP (V2+)
|
||
|
||
| **Fonctionnalité** | **Raison du report** | **Cible** |
|
||
|--------------------------------------------|---------------------------------------------------------------------------------------|------------|
|
||
| Détection d’anomalies ML | Trop complexe pour le MVP, nécessite données d’entraînement. | V2 (M7–M9) |
|
||
| Classification automatique des données | Requiert un modèle custom de classification de sensibilité. | V2 |
|
||
| Multi-tenant complet avec isolation réseau | Le MVP supporte le multi-tenant logique. L’isolation physique (dédiée) viendra en V2. | V2 |
|
||
| SDK natifs (Python, JS, Java) | Les intégrations se font via API REST + proxy HTTP au MVP. | V2 |
|
||
| Marketplace de politiques | Templates de politiques préconfigurées par industrie. | V3 |
|
||
| Agent de découverte Shadow AI | Scanner réseau pour détecter les appels IA non autorisés. | V2 |
|
||
| Intégration SIEM (Splunk, Sentinel) | Export syslog basique en MVP, connecteurs natifs en V2. | V2 |
|
||
|
||
## 2.3 Roadmap V1 → V2 → V3
|
||
|
||
| **Version** | **Timeline** | **Focus** |
|
||
|-------------|--------------|-------------------------------------------------------------------------------------------------|
|
||
| V1 (MVP) | M1–M6 | Proxy IA + Anonymisation + RBAC + Logging + Dashboard + Rapports conformité de base |
|
||
| V1.1 | M7–M8 | Stabilisation, feedback clients pilotes, amélioration UX, SDK Python |
|
||
| V2 | M9–M14 | Détection anomalies ML, Shadow AI discovery, isolation tenant physique, SIEM natif, SDK JS/Java |
|
||
| V3 | M15–M20 | Marketplace politiques, AI Act scoring automatisé, Data Lineage, certification ISO 27001 |
|
||
|
||
# 3. Architecture technique détaillée
|
||
|
||
## 3.1 Choix architectural : Modular Monolith
|
||
|
||
Pour le MVP, nous choisissons un monolithe modulaire plutôt que des microservices. Ce choix est délibéré et argumenté :
|
||
|
||
| **Critère** | **Monolithe modulaire** | **Microservices** |
|
||
|--------------------------|---------------------------------------------------------|---------------------------------------------------|
|
||
| Vitesse de développement | Rapide — un seul déploiement, debug simplifié | Lent — orchestration, service mesh, observabilité |
|
||
| Complexité ops | Faible — 1 conteneur principal + workers | Elevée — 10+ services, Kubernetes day-2 |
|
||
| Équipe nécessaire | 3–5 développeurs | 8–12 développeurs + SRE dédié |
|
||
| Scalabilité future | Extraction de modules en services possible sans refonte | Natif mais prématuré |
|
||
| Latence | Appels en mémoire entre modules | Latence réseau inter-services |
|
||
|
||
**Arbitrage :** Le monolithe modulaire permet de livrer en 6 mois avec une équipe de 4–5 personnes. Chaque module (proxy, anonymisation, logging, RBAC) est isolé dans son propre package/namespace avec des interfaces claires, ce qui permet une extraction future en microservice si nécessaire sans refonte.
|
||
|
||
## 3.2 Architecture high-level
|
||
|
||
L’architecture se décompose en couches fonctionnelles claires :
|
||
|
||
### Couche 1 — Point d’entrée
|
||
|
||
- **API Gateway (Kong / Traefik) :** Terminaison TLS, rate limiting, authentification JWT/SAML. Expose un endpoint unique de type OpenAI-compatible (/v1/chat/completions) pour faciliter l’adoption.
|
||
|
||
- **Load Balancer :** Cloud-native (ALB sur AWS, ou Traefik en on-prem).
|
||
|
||
### Couche 2 — Core Application (monolithe modulaire)
|
||
|
||
- **Module Auth :** Validation des tokens JWT, résolution RBAC, extraction du contexte utilisateur (département, rôle, politiques appliquées).
|
||
|
||
- **Module PII Redaction :** Pipeline de détection et anonymisation en temps réel (détaillé section 4).
|
||
|
||
- **Module Router :** Moteur de règles déterministe qui choisit le modèle cible selon les politiques (détaillé section 5).
|
||
|
||
- **Module Logger :** Capture structurée de chaque requête/réponse, écriture asynchrone (détaillé section 6).
|
||
|
||
- **Module Billing :** Comptage tokens, agrégation coûts, alertes budgétaires.
|
||
|
||
### Couche 3 — Connecteurs IA
|
||
|
||
- **Adapter Pattern :** Un adaptateur par fournisseur (OpenAI, Anthropic, Azure, Mistral, Ollama/vLLM pour on-prem). Chaque adaptateur normalise les formats de requête/réponse vers un schema interne unifié.
|
||
|
||
- **Connection Pool :** Gestion des connexions HTTP persistantes vers chaque fournisseur, avec circuit breaker intégré.
|
||
|
||
### Couche 4 — Stockage
|
||
|
||
- **PostgreSQL 16 :** Données relationnelles (utilisateurs, politiques, configuration, registre des traitements). Choix justifié : maturité, JSONB pour la flexibilité, Row-Level Security pour l’isolation multi-tenant, chiffrement natif.
|
||
|
||
- **ClickHouse :** Logs d’audit et analytics. Choix justifié : compression colonnes (10x), requêtes analytiques ultra-rapides sur des milliards de lignes, parfait pour les dashboards et exports.
|
||
|
||
- **Redis :** Cache de sessions, rate limiting, mapping PII temporaire, file d’attente légère.
|
||
|
||
### Couche 5 — Observabilité
|
||
|
||
- **Prometheus + Grafana :** Métriques techniques (latence proxy, débit, erreurs, santé des connecteurs).
|
||
|
||
- **OpenTelemetry :** Tracing distribué pour suivre chaque requête de bout en bout.
|
||
|
||
## 3.3 Multi-tenancy
|
||
|
||
Le MVP implémente un multi-tenant logique :
|
||
|
||
- **Isolation des données :** Chaque tenant a un tenant_id propagé dans toutes les tables. PostgreSQL Row-Level Security (RLS) empêche tout accès croisé.
|
||
|
||
- **Isolation des configurations :** Politiques de routage, seuils PII, et RBAC sont scopeés par tenant.
|
||
|
||
- **Isolation réseau (V2) :** Pour les clients les plus sensibles, un déploiement dédié (namespace Kubernetes isolé ou instance dédiée) sera proposé.
|
||
|
||
## 3.4 Compatibilité cloud + on-prem
|
||
|
||
L’application est conteneurisée (Docker) et déployable via Helm chart sur n’importe quel cluster Kubernetes. Trois modes de déploiement sont prévus :
|
||
|
||
| **Mode** | **Description** | **Cas d’usage** |
|
||
|-----------------|--------------------------------------------------------------------------------------------------------|----------------------------------------------------------|
|
||
| SaaS (cloud UE) | Hébergé par nous sur AWS eu-west-3 (Paris) ou OVHcloud. Mise à jour automatique. | PME, ETI, entreprises sans contrainte souveraineté forte |
|
||
| Hybrid | Control plane dans notre cloud, data plane chez le client. Les données ne quittent pas l’infra client. | Grandes entreprises avec données sensibles |
|
||
| On-prem (V2) | Déploiement intégral chez le client. Licence + support. | Défense, santé, secteur public |
|
||
|
||
# 4. Module d’anonymisation PII
|
||
|
||
## 4.1 Approche : Détection hybride multi-couches
|
||
|
||
L’anonymisation est le différenciateur clé du produit. Nous utilisons une approche hybride à trois couches pour maximiser la précision tout en minimisant la latence :
|
||
|
||
| **Couche** | **Technique** | **PII ciblées** | **Latence** | **Précision** |
|
||
|--------------------------------|--------------------------------------------|---------------------------------------------------|-------------|------------------------------|
|
||
| 1 — Regex deterministique | Patterns regex précompilés | IBAN, CB, SS, téléphone, email, numéros ID | \< 1 ms | 99%+ (faux positifs faibles) |
|
||
| 2 — NER (Presidio + spaCy) | Modèle NER multilangue (fr_core_news_lg) | Noms, adresses, organisations, dates de naissance | 5–15 ms | 92–96% |
|
||
| 3 — LLM local (optionnel V1.1) | Modèle léger (Phi-3 mini) pour cas ambigus | Contextes métiers spécifiques, données médicales | 50–100 ms | 97%+ |
|
||
|
||
## 4.2 Pipeline de traitement
|
||
|
||
Le pipeline s’exécute de manière synchrone avant chaque appel au modèle IA :
|
||
|
||
1. Réception du prompt utilisateur via le proxy.
|
||
|
||
2. Couche 1 — Regex : Scan rapide des patterns déterministes. Chaque match est remplacé par un token pseudonymisé de type \[PII:TYPE:UUID_COURT\] (ex: \[PII:IBAN:a3f2\]).
|
||
|
||
3. Couche 2 — NER : Le texte (déjà partiellement redacté) passe dans le modèle Presidio. Les entités détectées avec un score de confiance \> 0.85 sont pseudonymisées.
|
||
|
||
4. Couche 3 (optionnel) — Vérification LLM : En cas de doute (score entre 0.60 et 0.85), un modèle local valide.
|
||
|
||
5. Le prompt anonymisé est envoyé au modèle IA cible.
|
||
|
||
6. La réponse est reçue et les tokens PII sont ré-injectés (dé-pseudonymisation) avant renvoi à l’utilisateur.
|
||
|
||
## 4.3 Pseudonymisation réversible
|
||
|
||
**Mapping chiffré temporaire :** Chaque remplacement génère une entrée dans un store Redis chiffré (AES-256-GCM) avec un TTL configurable par le tenant (défaut : durée de la session + 1h, max 24h). Ce mapping permet la dé-pseudonymisation de la réponse.
|
||
|
||
**Après expiration :** Le mapping est supprimé automatiquement. Les logs d’audit ne conservent que le hash SHA-256 du prompt original et la version anonymisée, jamais les données PII en clair.
|
||
|
||
**Option « zero-retention » :** Pour les clients les plus exigeants, le mapping peut être purement en mémoire (non persisté même dans Redis), avec destruction à la fin de la requête. Contrepartie : la réponse IA ne sera pas dé-pseudonymisée si elle référence des PII.
|
||
|
||
## 4.4 Analyse de risque RGPD du module
|
||
|
||
| **Risque** | **Mitigation** | **Risque résiduel** |
|
||
|-----------------------------------------|-------------------------------------------------------------------------------|----------------------------------------------|
|
||
| Faux négatif : PII non détectée | Pipeline multi-couches + seuil configurable + monitoring du taux de détection | Modéré (mitigé par la couche LLM en V1.1) |
|
||
| Faux positif : donnée légitime redactée | Seuil de confiance ajustable + whitelist par tenant | Faible (impact fonctionnel, pas sécuritaire) |
|
||
| Mapping PII compromis | Chiffrement AES-256-GCM + TTL court + isolation par tenant | Faible |
|
||
| Données PII dans les logs | Seuls les hashs sont stockés + audit d’accès aux logs | Très faible |
|
||
|
||
# 5. Module de routage IA
|
||
|
||
## 5.1 Moteur de règles déterministe
|
||
|
||
Le routage utilise un moteur de règles évaluées par priorité (type firewall). Chaque règle est une combinaison de conditions → actions :
|
||
|
||
Conditions disponibles (MVP)
|
||
|
||
- **user.department :** Département de l’utilisateur (RH, Finance, Engineering, Legal, etc.)
|
||
|
||
- **user.role :** Rôle RBAC (admin, manager, user, auditor)
|
||
|
||
- **request.sensitivity :** Niveau de sensibilité déduit par le module PII (none, low, medium, high, critical)
|
||
|
||
- **request.use_case :** Tag de cas d’usage (code_generation, summarization, translation, analysis, creative)
|
||
|
||
- **request.token_estimate :** Estimation de la taille de la requête
|
||
|
||
Actions
|
||
|
||
- **route_to :** Modèle cible (ex: gpt-4o, claude-sonnet-4-5-20250929, mistral-local, llama-onprem)
|
||
|
||
- **block :** Requête refusée avec message configurable
|
||
|
||
- **require_approval :** Mise en attente pour validation manager (V1.1)
|
||
|
||
- **force_anonymize :** Force l’anonymisation même si le score PII est bas
|
||
|
||
## 5.2 Exemples de politiques
|
||
|
||
| **Règle** | **Condition** | **Action** |
|
||
|------------------------|---------------------------------------------------------|---------------------------------------------------------|
|
||
| R1 — Données critiques | sensitivity = critical | route_to: llama-onprem (IA locale uniquement) |
|
||
| R2 — RH | department = RH AND sensitivity \>= medium | route_to: mistral-local + force_anonymize |
|
||
| R3 — Engineering | department = Engineering AND use_case = code_generation | route_to: claude-sonnet-4-5-20250929 (performance code) |
|
||
| R4 — Budget dépassé | department.monthly_cost \> budget_limit | route_to: gpt-4o-mini (modèle économique) |
|
||
| R5 — Default | \* (catch-all) | route_to: gpt-4o |
|
||
|
||
## 5.3 Fallback automatique
|
||
|
||
En cas d’indisponibilité du modèle cible, le router applique une chaîne de fallback configurable par tenant :
|
||
|
||
1. Tentative sur le modèle primaire (timeout configurable, défaut 30s).
|
||
|
||
2. Si échec ou timeout : bascule vers le modèle secondaire défini dans la politique.
|
||
|
||
3. Si le secondaire échoue : bascule vers le modèle de fallback global (configuré au niveau tenant).
|
||
|
||
4. Si tout échoue : retour d’une erreur structurée avec code 503 et suggestion de réessai.
|
||
|
||
Un circuit breaker (pattern Hystrix) désactive automatiquement un modèle après N erreurs consécutives (configurable, défaut 5), évitant de saturer un provider défaillant.
|
||
|
||
# 6. Journalisation et audit trail
|
||
|
||
## 6.1 Structure des logs
|
||
|
||
Chaque interaction génère un enregistrement structuré immutable dans ClickHouse :
|
||
|
||
| **Champ** | **Type** | **Description** |
|
||
|-------------------|------------------|------------------------------------------------------|
|
||
| log_id | UUID v7 | Identifiant unique trié chronologiquement |
|
||
| tenant_id | UUID | Isolation multi-tenant |
|
||
| user_id | UUID | Identifiant utilisateur (lié au SSO) |
|
||
| department | String | Département de l’utilisateur |
|
||
| timestamp | DateTime64(3) | Horodatage précis au millisecondes |
|
||
| model_requested | String | Modèle demandé par l’utilisateur |
|
||
| model_actual | String | Modèle effectivement utilisé (après routage) |
|
||
| prompt_hash | SHA-256 | Hash du prompt original (jamais le contenu brut) |
|
||
| prompt_anonymized | String (chiffré) | Prompt après anonymisation (optionnel, configurable) |
|
||
| response_hash | SHA-256 | Hash de la réponse |
|
||
| tokens_input | UInt32 | Nombre de tokens en entrée |
|
||
| tokens_output | UInt32 | Nombre de tokens en sortie |
|
||
| cost_eur | Decimal(10,6) | Coût calculé de la requête |
|
||
| pii_detected | Array(String) | Types de PII détectées (\[IBAN, NOM, EMAIL\]) |
|
||
| pii_count | UInt16 | Nombre total de PII redactées |
|
||
| sensitivity_level | Enum | none / low / medium / high / critical |
|
||
| routing_rule_id | String | Règle de routage appliquée |
|
||
| latency_ms | UInt32 | Latence totale (proxy + modèle) |
|
||
| status | Enum | success / blocked / error / timeout / fallback |
|
||
| ip_address | String (hashé) | Adresse IP hashée de l’appelant |
|
||
|
||
## 6.2 Chiffrement et sécurité des logs
|
||
|
||
- **En transit :** TLS 1.3 entre l’application et ClickHouse.
|
||
|
||
- **At rest :** Chiffrement AES-256 au niveau volume (LUKS) + chiffrement applicatif des champs sensibles (prompt_anonymized).
|
||
|
||
- **Accès :** Seuls les rôles Admin et Auditor peuvent consulter les logs. Chaque accès aux logs est lui-même loggé (audit de l’audit).
|
||
|
||
- **Immutabilité :** Les logs sont en append-only. Aucune API de suppression individuelle. La purge respecte la politique de rétention configurée.
|
||
|
||
## 6.3 Rétention
|
||
|
||
| **Tier** | **Durée** | **Stockage** |
|
||
|--------------------|----------------------|---------------------------------------------------------|
|
||
| Hot (accès rapide) | 90 jours | ClickHouse SSD — requêtes \< 1s |
|
||
| Warm (archivage) | 1 an | ClickHouse HDD compressé — requêtes \< 10s |
|
||
| Cold (conformité) | 5 ans (configurable) | Object Storage (S3/MinIO) chiffré — export à la demande |
|
||
|
||
## 6.4 Dashboard RSSI
|
||
|
||
Le dashboard temps réel (React + recharts) présente :
|
||
|
||
- **Vue globale :** Volume de requêtes (24h, 7j, 30j), répartition par modèle, par département.
|
||
|
||
- **Sécurité :** Nombre de PII détectées/bloquées, requêtes bloquées par politique, tentatives d’accès non autorisées.
|
||
|
||
- **Coûts :** Dépense par modèle, par département, projection mensuelle, alertes de dépassement.
|
||
|
||
- **Alertes :** Pic d’utilisation anormal, tentatives d’exfiltration (volume PII élevé soudain), modèle en état dégradé.
|
||
|
||
## 6.5 Exports conformité
|
||
|
||
- **PDF :** Rapport mensuel généré automatiquement : synthèse des traitements IA, PII détectées, incidents, conformité RGPD.
|
||
|
||
- **CSV :** Export brut des logs (filtrés par date, département, modèle) pour intégration SIEM ou audit externe.
|
||
|
||
- **Syslog (V1.1) :** Export en temps réel au format CEF pour Splunk, Sentinel, QRadar.
|
||
|
||
# 7. Conformité RGPD et AI Act
|
||
|
||
## 7.1 Articles RGPD couverts par la plateforme
|
||
|
||
| **Article** | **Exigence** | **Couverture par AI Governance Hub** |
|
||
|--------------|------------------------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
|
||
| Art. 5(1)(a) | Licéité, loyauté, transparence | Journalisation complète de chaque traitement. Le registre documente la base légale configurée par le DPO pour chaque cas d’usage IA. |
|
||
| Art. 5(1)(c) | Minimisation des données | Le module PII anonymise automatiquement les données personnelles avant envoi aux LLMs externes, ne transmettant que le strict nécessaire. |
|
||
| Art. 5(1)(e) | Limitation de conservation | Politique de rétention configurable par tenant (hot/warm/cold). Purge automatique à expiration. |
|
||
| Art. 5(1)(f) | Intégrité et confidentialité | Chiffrement AES-256 at rest et TLS 1.3 en transit. RBAC strict. Audit d’accès. |
|
||
| Art. 13–14 | Information des personnes concernées | Documentation automatique des traitements IA avec finalités, destinataires, durées de conservation. Exportable pour intégration dans la politique de confidentialité du client. |
|
||
| Art. 15 | Droit d’accès | API de recherche par user_id permettant d’extraire l’ensemble des logs associés à un individu (version anonymisée). |
|
||
| Art. 17 | Droit à l’effacement | Endpoint de purge par user_id supprimant les logs et mappings PII associés, avec confirmation d’effacement loggée. |
|
||
| Art. 25 | Protection des données dès la conception | L’anonymisation par défaut (privacy by design) est le principe fondamental de l’architecture. |
|
||
| Art. 28 | Sous-traitant | Chaque fournisseur IA est documenté comme sous-traitant avec ses DPA. Le registre maintient la liste à jour. |
|
||
| Art. 30 | Registre des traitements | Génération automatique du registre au format Article 30, exportable PDF/CSV. |
|
||
| Art. 32 | Sécurité du traitement | Chiffrement, pseudonymisation, contrôle d’accès, audit continu, tests de résilience. |
|
||
| Art. 33–34 | Notification de violations | Détection d’incidents (fuite PII, accès non autorisé) avec alertes temps réel pour faciliter la notification dans les 72h. |
|
||
| Art. 35 | AIPD / DPIA | Template d’analyse d’impact pré-rempli pour chaque cas d’usage IA, avec évaluation des risques automatisée. |
|
||
|
||
## 7.2 Préparation AI Act européen
|
||
|
||
Le Règlement européen sur l’Intelligence Artificielle (Règlement (UE) 2024/1689) impose des obligations progressives. AI Governance Hub positionne ses clients en conformité anticipée :
|
||
|
||
Classification des risques (Article 6)
|
||
|
||
La plateforme intègre un moteur de classification assistée qui permet au DPO de qualifier chaque cas d’usage IA selon les quatre niveaux de risque de l’AI Act :
|
||
|
||
| **Niveau** | **Exemples** | **Obligations** | **Support plateforme** |
|
||
|--------------------------|----------------------------------------------------|---------------------------------|----------------------------------------------------------------------------------|
|
||
| Interdit (Art. 5) | Scoring social, manipulation subliminale | Usage prohibé | Blocage automatique si le cas d’usage est tagué interdit |
|
||
| Haut risque (Annexe III) | Recrutement IA, scoring crédit, diagnostic médical | Conformité complète (Art. 8–15) | Documentation automatisée, journalisation complète, traçabilité, contrôle humain |
|
||
| Risque limité (Art. 50) | Chatbots, génération de contenu | Obligations de transparence | Tag automatique des réponses générées par IA |
|
||
| Risque minimal | Filtres anti-spam, auto-complétion | Aucune obligation spécifique | Journalisation standard |
|
||
|
||
Obligations pour les « deployers » (Article 26)
|
||
|
||
AI Governance Hub aide les entreprises à remplir leurs obligations en tant que « déployeurs » de systèmes IA :
|
||
|
||
- **Supervision humaine (Art. 14) :** Le workflow d’approbation (V1.1) permet un contrôle humain sur les cas sensibles.
|
||
|
||
- **Journalisation automatique (Art. 12) :** Chaque utilisation d’un système à haut risque est traçée avec l’ensemble des métadonnées requises.
|
||
|
||
- **Information des personnes (Art. 13) :** Documentation automatique des finalités et des modèles utilisés.
|
||
|
||
- **DPIA (Art. 27) :** Analyse d’impact fondamentale prise en charge par la plateforme pour les systèmes à haut risque.
|
||
|
||
## 7.3 Documentation automatique
|
||
|
||
La plateforme génère automatiquement :
|
||
|
||
- **Registre Article 30 RGPD :** Liste complète des traitements IA avec finalités, bases légales, destinataires, durées, mesures de sécurité.
|
||
|
||
- **Fiche technique AI Act par système :** Description du modèle, classification de risque, mesures de mitigation, tests effectués.
|
||
|
||
- **Rapport d’incident :** Template pré-rempli en cas de détection d’anomalie PII, avec chronologie et impact estimé.
|
||
|
||
- **DPIA template :** Analyse d’impact pré-remplie pour chaque cas d’usage IA à haut risque.
|
||
|
||
# 8. Sécurité
|
||
|
||
## 8.1 Principes de sécurité
|
||
|
||
La sécurité est intégrée à chaque couche de l’architecture selon une approche defense-in-depth :
|
||
|
||
| **Couche** | **Mesure** | **Implémentation** |
|
||
|------------------|-----------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------|
|
||
| Réseau | Zero Trust Network | mTLS entre tous les composants internes. Aucune communication en clair même en réseau privé. Network policies Kubernetes restrictives (deny-all par défaut). |
|
||
| Transport | TLS 1.3 obligatoire | Certificats gérés par cert-manager (Let’s Encrypt) ou PKI client en on-prem. |
|
||
| Données au repos | AES-256-GCM | Chiffrement volume (LUKS/EBS encryption) + chiffrement applicatif des champs sensibles (clés envelopes via KMS). |
|
||
| Application | RBAC + ABAC | Contrôle d’accès par rôle et par attribut. Chaque endpoint est protégé par une politique d’autorisation. |
|
||
| Secrets | HashiCorp Vault | Rotation automatique des secrets (API keys LLM, credentials DB). Pas de secrets en variables d’env ou fichiers de config. |
|
||
| API | Rate limiting + WAF | Rate limiting par tenant/user (Kong). Protection OWASP Top 10 via ModSecurity/Cloud WAF. |
|
||
| Audit | Immutable audit trail | Tous les accès admin, modifications de politique, et consultations de logs sont eux-mêmes audités. |
|
||
|
||
## 8.2 Gestion des clés et secrets
|
||
|
||
Les clés API des fournisseurs IA (OpenAI, Anthropic, etc.) sont le secret le plus critique. Elles sont gérées selon les principes suivants :
|
||
|
||
- **Stockage :** HashiCorp Vault (ou AWS Secrets Manager en mode SaaS). Jamais en base de données ni en variable d’environnement.
|
||
|
||
- **Accès :** L’application récupère les clés via l’API Vault avec authentification par service account Kubernetes.
|
||
|
||
- **Rotation :** Rotation automatisée tous les 90 jours. Alerte si une clé n’a pas été tournée.
|
||
|
||
- **Isolation :** Chaque tenant a son propre path dans Vault. Un tenant ne peut jamais accéder aux secrets d’un autre.
|
||
|
||
## 8.3 Pentest readiness
|
||
|
||
La plateforme est conçue pour passer un audit de sécurité externe (type pentest black/grey box) dès le lancement. Mesures préparatoires :
|
||
|
||
- **SAST :** Analyse statique intégrée à la CI/CD (Semgrep pour le code, Trivy pour les images Docker).
|
||
|
||
- **DAST :** Scan OWASP ZAP automatisé en staging avant chaque release.
|
||
|
||
- **Dépendances :** Audit continu des dépendances (npm audit, pip audit, Snyk).
|
||
|
||
- **Bug bounty :** Programme prévu post-lancement (V1.1) via plateforme YesWeHack.
|
||
|
||
# 9. Business Model
|
||
|
||
## 9.1 Modèle de pricing hybride
|
||
|
||
Le pricing combine un abonnement par utilisateur (prévisibilité pour le client) et un composant volumique (tokens monitorisés) qui aligne la valeur perçue avec l’usage réel :
|
||
|
||
| | **Starter** | **Business** | **Enterprise** |
|
||
|---------------------------|--------------------------|-------------------------------------|---------------------------------------------|
|
||
| Cible | Startups, PME innovantes | ETI, départements de grands groupes | CAC 40, banques, assurances, secteur public |
|
||
| Utilisateurs inclus | Jusqu’à 50 | Jusqu’à 500 | Illimité |
|
||
| Prix / user / mois | 15 € | 25 € | Sur devis (35–55 €) |
|
||
| Tokens monitorisés inclus | 5M / mois | 50M / mois | Custom |
|
||
| Token supplémentaire | 0.50 € / 1M tokens | 0.30 € / 1M tokens | Négocié |
|
||
| Modèles IA connectés | 3 max | 10 max | Illimité |
|
||
| Anonymisation PII | Regex uniquement | Regex + NER | Regex + NER + LLM local |
|
||
| SSO / SAML | Non | Oui | Oui + custom IdP |
|
||
| Rapports conformité | Basique (CSV) | RGPD + AI Act (PDF) | Custom + DPIA + audit trail complet |
|
||
| Déploiement | SaaS uniquement | SaaS ou hybrid | SaaS, hybrid ou on-prem |
|
||
| Support | Email (48h) | Email + Slack (24h) | Dédié + CSM + SLA 4h |
|
||
| SLA | 99.5% | 99.9% | 99.95% + pénalités |
|
||
|
||
## 9.2 Estimation de revenus
|
||
|
||
Hypothèse Year 1 (prudente) : 5 clients Starter, 3 Business, 1 Enterprise.
|
||
|
||
| **Tier** | **Clients** | **Users moyens** | **MRR unitaire** | **MRR total** |
|
||
|------------|-------------|------------------|------------------|----------------------|
|
||
| Starter | 5 | 30 | 450 € | 2 250 € |
|
||
| Business | 3 | 200 | 5 000 € | 15 000 € |
|
||
| Enterprise | 1 | 1 000 | 40 000 € | 40 000 € |
|
||
| TOTAL | | | | 57 250 € (687k€ ARR) |
|
||
|
||
## 9.3 Stratégie go-to-market
|
||
|
||
Persona primaire : RSSI
|
||
|
||
Le RSSI est le champion interne. Le pitch principal est : « Reprenez le contrôle sur les flux IA avant qu’un incident ne vous y oblige. » L’angle sécurité (Shadow AI, fuite PII) résonne immédiatement.
|
||
|
||
Persona secondaire : DPO / Compliance
|
||
|
||
Le DPO est l’allié pour la décision. L’AI Act crée une urgence réglementaire dont la plateforme est la réponse directe.
|
||
|
||
Acheteur final : DSI
|
||
|
||
Le DSI signe le budget. Le pitch DSI combine TCO (rationalisation des abonnements IA), risque (conformité, audit) et efficacité (un point d’accès unique pour tous les LLMs).
|
||
|
||
Canaux
|
||
|
||
- **Inbound :** Content marketing (blog technique, whitepapers AI Act), webinaires conformité RGPD/IA, référencement sur comparateurs B2B (G2, Capterra).
|
||
|
||
- **Outbound :** Sales outreach ciblé sur les entreprises +500 employés ayant des usages IA documentés. Partenariats avec cabinets de conseil cyber et RGPD.
|
||
|
||
- **Communauté :** Open-sourcing du module PII Presidio custom pour construire la crédibilité technique.
|
||
|
||
# 10. Stack technique recommandée
|
||
|
||
| **Composant** | **Technologie** | **Justification** | **Alternative** |
|
||
|------------------------|---------------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-----------------------------------------------------------------------------------------|
|
||
| Backend — API | Go 1.22 | Performance native (proxy haute perf), faible empreinte mémoire, typage fort, excellent support concurrence (goroutines pour le streaming SSE). Go est le standard pour les reverse proxies (Traefik, Caddy). | Rust (plus complexe, recrutement difficile) ou Node.js (moins performant pour le proxy) |
|
||
| Backend — Workers | Python 3.12 | Ecosystème NLP/NER (spaCy, Presidio). Utilisé pour le pipeline d’anonymisation et les tâches async (génération rapports, purge). | Go (mais perte de l’écosystème NLP) |
|
||
| Frontend | React 18 + TypeScript + Vite | Ecosystème mature, composants shadcn/ui pour un design professionnel rapidement, recharts pour les dashboards. | Vue.js (viable mais écosystème composants enterprise moindre) |
|
||
| API Gateway | Kong Gateway (OSS) | Gestion des routes, rate limiting, auth plugins (JWT, SAML), logging. Configurable via API déclarative. Déjà éprouvé en production enterprise. | Traefik (plus léger mais moins de plugins enterprise) |
|
||
| Base relationnelle | PostgreSQL 16 | Row-Level Security pour multi-tenant, JSONB pour la flexibilité des politiques, maturité, performance, chiffrement natif. | CockroachDB (si distribution géo nécessaire V2) |
|
||
| Base analytique / Logs | ClickHouse | Compression 10x, requêtes analytiques ultra-rapides (agrégations, GROUP BY sur milliards de lignes), parfait pour dashboard temps réel et exports. | TimescaleDB (plus simple mais moins performant à l’échelle) |
|
||
| Cache / Queue | Redis 7 (Valkey) | Sessions, rate limiting, cache mapping PII, pub/sub pour notifications temps réel. | KeyDB (compatible Redis, multi-threadé) |
|
||
| File de messages | Redis Streams (MVP) → NATS (V2) | Redis Streams suffit au MVP pour les tâches async. NATS en V2 pour le découplage si extraction en microservices. | RabbitMQ (plus lourd pour le MVP) |
|
||
| IAM / Auth | Keycloak | SSO, SAML 2.0, OIDC, RBAC complet, multi-tenant, federation d’identité. Standard enterprise. Hébergeable en UE. | Auth0 (SaaS US, problème souveraineté) |
|
||
| Secrets | HashiCorp Vault | Gestion centralisée des secrets, rotation automatique, audit trail. Intégration native Kubernetes. | AWS Secrets Manager (si 100% AWS) |
|
||
| Conteneurs | Docker + Kubernetes (K8s) | Standard de déploiement. Helm charts pour reproductibilité. Compatible cloud et on-prem. | Docker Compose (dév uniquement) |
|
||
| CI/CD | GitLab CI | Pipeline intégré : build, test, SAST (Semgrep), scan images (Trivy), deploy. Hébergeable en UE. | GitHub Actions (SaaS US) |
|
||
| Monitoring | Prometheus + Grafana | Métriques (latence, débit, erreurs). Alerting via Alertmanager. Stack open-source, pas de lock-in. | Datadog (coût élevé en enterprise) |
|
||
| Tracing | OpenTelemetry + Jaeger | Tracing distribué pour suivre chaque requête de bout en bout à travers les modules. | Tempo (alternative Grafana) |
|
||
| NER / NLP | Microsoft Presidio + spaCy | Presidio est le standard open-source pour la détection PII. Extensible, multilangue, intégré à spaCy. | AWS Comprehend (coût + données hors UE) |
|
||
| Infra cloud | AWS eu-west-3 (Paris) | Certifié HDS, ISO 27001. Région UE. Compatibilité hébergement souverain (OVHcloud/Scaleway en fallback). | OVHcloud (moins de services managés) |
|
||
|
||
# 11. Plan de développement — 6 mois
|
||
|
||
**Équipe cible :** 1 CTO/Lead Backend (Go), 1 Backend Senior (Go/Python), 1 Frontend Senior (React), 1 DevOps/SRE, 1 Product Manager (0.5 ETP). Total : 4.5 ETP.
|
||
|
||
Mois 1 — Fondations et proxy de base
|
||
|
||
Objectifs
|
||
|
||
- Infrastructure de base opérationnelle (CI/CD, Kubernetes, monitoring)
|
||
|
||
- Reverse proxy fonctionnel capable de relayer des requêtes vers OpenAI
|
||
|
||
- Authentification basique (JWT)
|
||
|
||
Livrables
|
||
|
||
| **Tâche** | **Responsable** | **Durée** |
|
||
|----------------------------------------------------------------------------------|-----------------|------------|
|
||
| Setup GitLab, CI/CD pipeline, registre Docker, cluster K8s staging | DevOps | 1 semaine |
|
||
| Scaffolding monolithe Go : structure modulaire, routing HTTP, middleware chain | Lead Backend | 1 semaine |
|
||
| Module Proxy : relay transparent vers OpenAI API (non-streaming + streaming SSE) | Lead Backend | 2 semaines |
|
||
| Authentification JWT basique + middleware auth | Backend Sr | 1 semaine |
|
||
| Setup PostgreSQL + ClickHouse + Redis en Helm | DevOps | 1 semaine |
|
||
| Modèle de données initial (users, tenants, policies) + migrations | Backend Sr | 1 semaine |
|
||
| Setup Keycloak + intégration OIDC basique | DevOps | 1 semaine |
|
||
|
||
**Point critique :** Le proxy doit supporter le streaming SSE dès le début. C’est un choix technique structurant qui impacte toute l’architecture.
|
||
|
||
Mois 2 — Anonymisation PII et multi-modèle
|
||
|
||
Objectifs
|
||
|
||
- Pipeline PII fonctionnel (regex + NER Presidio)
|
||
|
||
- Support multi-modèle (Anthropic, Azure OpenAI, Mistral)
|
||
|
||
- RBAC fonctionnel
|
||
|
||
Livrables
|
||
|
||
| **Tâche** | **Responsable** | **Durée** |
|
||
|--------------------------------------------------------------|-----------------|------------|
|
||
| Module PII : couche 1 regex (IBAN, email, tél, CB, SS) | Backend Sr | 1 semaine |
|
||
| Module PII : intégration Presidio/spaCy (NER multilangue) | Backend Sr | 2 semaines |
|
||
| Pseudonymisation réversible + stockage mapping Redis chiffré | Backend Sr | 1 semaine |
|
||
| Adaptateurs multi-modèle (Anthropic, Azure, Mistral, Ollama) | Lead Backend | 2 semaines |
|
||
| Module RBAC : rôles, permissions, middleware d’autorisation | Lead Backend | 1 semaine |
|
||
| Intégration SAML 2.0 dans Keycloak + tests avec Azure AD | DevOps | 1 semaine |
|
||
| Setup frontend React : auth flow, layout, navigation | Frontend | 2 semaines |
|
||
|
||
**Risque technique :** La latence du pipeline PII doit rester \< 50ms pour ne pas dégrader l’expérience. Benchmark dès la semaine 2.
|
||
|
||
Mois 3 — Routage intelligent et journalisation
|
||
|
||
Objectifs
|
||
|
||
- Moteur de règles de routage fonctionnel
|
||
|
||
- Journalisation complète dans ClickHouse
|
||
|
||
- Dashboard MVP fonctionnel
|
||
|
||
Livrables
|
||
|
||
| **Tâche** | **Responsable** | **Durée** |
|
||
|---------------------------------------------------------------------------|-----------------|------------|
|
||
| Module Router : moteur de règles, évaluation par priorité, fallback chain | Lead Backend | 2 semaines |
|
||
| Module Router : circuit breaker, health check des providers | Lead Backend | 1 semaine |
|
||
| Module Logger : écriture async ClickHouse, structure complète des logs | Backend Sr | 2 semaines |
|
||
| Module Billing : comptage tokens, agrégation par user/dept/model | Backend Sr | 1 semaine |
|
||
| Dashboard frontend : overview (volume, coûts, PII), composants recharts | Frontend | 3 semaines |
|
||
| API admin : CRUD politiques de routage, gestion utilisateurs | Lead Backend | 1 semaine |
|
||
|
||
Mois 4 — Conformité et sécurité
|
||
|
||
Objectifs
|
||
|
||
- Rapports conformité RGPD et AI Act opérationnels
|
||
|
||
- Hardening sécurité complet
|
||
|
||
- Dashboard RSSI enrichi
|
||
|
||
Livrables
|
||
|
||
| **Tâche** | **Responsable** | **Durée** |
|
||
|-----------------------------------------------------------------------------|-----------------|------------|
|
||
| Module Compliance : registre Art. 30, génération PDF, classification AI Act | Backend Sr | 3 semaines |
|
||
| API droits RGPD : accès (Art. 15), effacement (Art. 17), export | Backend Sr | 1 semaine |
|
||
| Dashboard RSSI : alertes, détection pics, vue sécurité | Frontend | 2 semaines |
|
||
| Hardening : mTLS interne, network policies K8s, Vault intégration | DevOps | 2 semaines |
|
||
| SAST/DAST : Semgrep + Trivy + OWASP ZAP intégrés CI/CD | DevOps | 1 semaine |
|
||
| Chiffrement at-rest applicatif des champs sensibles | Lead Backend | 1 semaine |
|
||
| Tests de charge : benchmark proxy (cible : 1000 req/s, p99 \< 200ms) | DevOps + Lead | 1 semaine |
|
||
|
||
Mois 5 — Stabilisation et beta privée
|
||
|
||
Objectifs
|
||
|
||
- Beta privée avec 2–3 clients pilotes
|
||
|
||
- Tests end-to-end complets
|
||
|
||
- Documentation technique et utilisateur
|
||
|
||
Livrables
|
||
|
||
| **Tâche** | **Responsable** | **Durée** |
|
||
|-----------------------------------------------------------------------------------|-----------------|------------|
|
||
| Tests E2E automatisés : parcours complets proxy → PII → routing → log → dashboard | Tous | 2 semaines |
|
||
| Onboarding clients pilotes : configuration tenant, import users SSO | PM + DevOps | 2 semaines |
|
||
| Bug fixes et ajustements UX d’après feedback pilotes | Tous | 2 semaines |
|
||
| Documentation API (OpenAPI 3.1) + guide d’intégration | Lead Backend | 1 semaine |
|
||
| Documentation utilisateur + guide admin | PM + Frontend | 1 semaine |
|
||
| Optimisation performance d’après données réelles | Lead Backend | 1 semaine |
|
||
|
||
Mois 6 — Production et lancement
|
||
|
||
Objectifs
|
||
|
||
- Mise en production sur infra UE
|
||
|
||
- Premier contrat signé
|
||
|
||
- Pentest externe passé
|
||
|
||
Livrables
|
||
|
||
| **Tâche** | **Responsable** | **Durée** |
|
||
|-------------------------------------------------------------------|------------------|-------------|
|
||
| Déploiement production : cluster K8s EU (AWS eu-west-3), DR setup | DevOps | 1 semaine |
|
||
| Pentest externe (cabinet spécialisé, grey box) | Externe + DevOps | 2 semaines |
|
||
| Remédiation findings pentest | Tous | 1 semaine |
|
||
| Landing page, démo interactive, matériel commercial | PM + Frontend | 2 semaines |
|
||
| Onboarding premier client payant | PM + DevOps | 2 semaines |
|
||
| Monitoring production : alerting, on-call, runbooks | DevOps | 1 semaine |
|
||
| Rétro et planification V1.1 | Tous | 0.5 semaine |
|
||
|
||
## 11.7 Risques techniques et mitigations
|
||
|
||
| **Risque** | **Probabilité** | **Impact** | **Mitigation** |
|
||
|---------------------------------------------|-----------------|------------|-------------------------------------------------------------------------------------------------------------|
|
||
| Latence PII pipeline trop élevée | Moyenne | Haut | Benchmark dès M2. Option : désactiver NER pour les requêtes basse sensibilité. Cache des patterns déjà vus. |
|
||
| Intégration SSO complexe chez le client | Haute | Moyen | Keycloak supporte SAML/OIDC natif. Prévoir 1 semaine d’intégration par client. |
|
||
| Changements de format API des providers LLM | Moyenne | Moyen | Adapter pattern : les changements sont isolés dans un seul fichier par provider. |
|
||
| Faux négatifs PII en production | Moyenne | Haut | Mode audit (log sans bloquer) pendant 2 semaines de rodage. Feedback loop avec le client. |
|
||
| Difficulté de recrutement Go + NLP | Haute | Haut | Prévoir 1 mois de recrutement en amont. Alternative : consultants spécialisés pour le module PII Python. |
|
||
| Évolution rapide de l’AI Act | Moyenne | Moyen | Veille réglementaire continue. Le module compliance est configurable (règles non hardcodées). |
|
||
|
||
# 12. Synthèse des arbitrages clés
|
||
|
||
| **Décision** | **Choix retenu** | **Raison** |
|
||
|---------------|--------------------------|-----------------------------------------------------------------------|
|
||
| Architecture | Monolithe modulaire | Rapidité de livraison avec équipe réduite, extraction future possible |
|
||
| Langage proxy | Go | Performance native, streaming SSE, concurrence, faible mémoire |
|
||
| Langage NLP | Python (Presidio/spaCy) | Ecosystème NER mature, pas d’équivalent en Go |
|
||
| Base logs | ClickHouse | Performance analytique incomparable pour les dashboards et exports |
|
||
| IAM | Keycloak | SAML/OIDC natif, hébergeable UE, open-source |
|
||
| Multi-tenant | Logique (RLS PostgreSQL) | Suffisant pour le MVP, isolation physique en V2 |
|
||
| PII detection | Hybride regex + NER | Meilleur rapport précision/latence que le tout-LLM |
|
||
| Déploiement | SaaS EU + hybrid option | Couvre 90% du marché cible, on-prem en V2 |
|
||
| Pricing | Hybride (user + tokens) | Prévisible pour le client, scalable pour nous |
|
||
|
||
Ce document constitue la base technique et stratégique pour le démarrage du projet AI Governance Hub. Chaque choix a été fait en privilégiant la livraison rapide d’un produit commercialisable, sans compromettre la sécurité ni la conformité réglementaire. Les fondations sont conçues pour évoluer vers une architecture plus distribuée quand le produit et l’équipe le justifieront.
|