veylant/docs/AI_Governance_Hub_PRD.md

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.