veylant/docs/AI_Governance_Hub_Plan_Realisation.md

AI GOVERNANCE HUB

Plan de Réalisation Détaillé

De l’analyse critique du PRD au plan d’exécution étape par étape

CONFIDENTIEL — Février 2026

Guide d’exécution pour équipe technique — 164 tâches, 26 semaines

Partie A — Analyse critique du PRD

Avant de planifier l’exécution, une analyse honnête du PRD est nécessaire. Le document est solide sur la vision et l’architecture, mais plusieurs points nécessitent des corrections pour un plan d’exécution réaliste.

A.1 — Ce qui est bien fait dans le PRD

• Architecture monolithe modulaire : Choix parfaitement calibré pour l’équipe et le timeline. Pas de sur-ingénierie.

• Séparation Go (proxy) / Python (NLP) : Chaque langage est utilisé pour ses forces. Le surcoût ops de 2 runtimes est accepté car le gain en performance et écosystème est majeur.

• Pipeline PII hybride : L’approche regex + NER est le bon compromis latence/précision. Le tout-LLM serait trop lent et trop cher.

• ClickHouse pour les logs : Choix différenciant. La performance analytique permettra des dashboards impressionnants en démo.

• Pricing hybride : Le modèle user + tokens aligne la valeur. Le tier Enterprise à 40k€ MRR est réaliste pour un CAC 40.

• Scope MVP bien délimité : Le hors-scope est clairement défini. Pas de feature creep.

A.2 — Problèmes identifiés et corrections

Problème dans le PRD	Impact	Correction appliquée dans ce plan
Les durées par tâche sont optimistes. Beaucoup de tâches à « 1 semaine » qui en prendront 2 en réalité (intégration, tests, edge cases).	Haut — dérapage calendaire quasi certain	Ce plan ajoute 20% de buffer par sprint. Chaque tâche est décomposée en sous-tâches avec des critères d’acceptance précis.
La communication inter-modules Go ↔ Python n’est pas détaillée. Comment le proxy Go appelle-t-il le service PII Python ?	Haut — choix structurant	Le plan précise : le module PII tourne comme sidecar gRPC. Le proxy Go fait un appel gRPC local (<1ms overhead). Alternative : embedded Python via cgo (rejeté : trop fragile).
Le plan mois par mois ne précise pas les dépendances entre tâches. Certaines sont parallélisables, d’autres bloquantes.	Moyen — goulots d’étranglement	Ce plan inclut un graphe de dépendances et identifie le chemin critique.
Les tests ne sont prévus qu’au mois 5. C’est trop tard.	Haut — dette technique	Ce plan intègre les tests dès le sprint 1. Chaque module a ses tests unitaires et d’intégration en parallèle du développement.
Le frontend est sous-estimé. « 2 semaines setup + 3 semaines dashboard » pour un dashboard enterprise complet est irréaliste.	Moyen — UX insuffisante au lancement	Le plan alloue le frontend en continu dès le mois 2, avec des livrables incrémentaux chaque sprint.
Aucune mention du mode « playground » / démo intégrée pour les prospects.	Moyen — impact commercial	Ajout d’un playground intégré (prompt test avec visualisation PII) au sprint 8.
Le plan ne prévoit pas de gestion de la configuration des providers IA côté UI.	Moyen — onboarding complexe	Ajout d’un wizard de configuration des providers dans le dashboard admin.
Le PRD ne détaille pas la stratégie de migration/rollback des déploiements.	Moyen — risque production	Ce plan inclut blue/green deployment dès le mois 4 et des runbooks de rollback.

A.3 — Décisions techniques complémentaires

Ces décisions n’étaient pas dans le PRD mais sont indispensables pour l’exécution :

• Communication Go ↔ Python : gRPC avec Protocol Buffers. Le service PII Python est un sidecar dans le même pod Kubernetes. Latence mesurée : ~2ms aller-retour. Schema gRPC versionné dans un repo partagé (proto/).

• Stratégie de test : Pyramide classique : 70% unit (Go: testing + testify, Python: pytest), 20% intégration (testcontainers pour PG/CH/Redis), 10% E2E (Playwright pour le frontend, scripts curl/httpie pour l’API).

• Feature flags : Système de feature flags maison simple (table PostgreSQL + cache Redis, ~50 lignes de code). Permet de livrer du code en production sans l’activer. Critique pour la beta.

• Gestion des erreurs : Chaque module expose des erreurs typées (Go errors wrap). Le proxy retourne des erreurs structurées JSON compatibles OpenAI API format (type, message, code).

• Versionning API : Préfixe /v1/ dès le début. Pas de versionning par header (trop complexe pour les clients enterprise).

• Documentation : OpenAPI 3.1 généré automatiquement depuis les annotations Go (swaggo). Pas de doc manuelle qui diverge.

Partie B — Organisation et méthodologie

B.1 — Équipe et rôles

Rôle	Profil	Responsabilités principales	Charge
CTO / Lead Backend	Senior Go (7+ ans), expérience proxy/networking	Architecture, module Proxy, module Router, code reviews, décisions techniques	100%
Backend Senior	Go + Python, expérience NLP	Module PII (Python), module Logger, module Billing, adaptateurs IA	100%
Frontend Senior	React/TypeScript, expérience dashboard data-heavy	Dashboard, admin UI, playground, auth flow, UX	100%
DevOps / SRE	Kubernetes, AWS, CI/CD, sécurité	Infra, CI/CD, monitoring, sécurité, déploiements, Keycloak	100%
Product Manager	Expérience B2B SaaS enterprise, compréhension RGPD	Specs, priorisation, clients pilotes, documentation utilisateur, commercial	50%

B.2 — Méthodologie de travail

Sprints de 2 semaines, avec les rituels suivants :

Rituel	Fréquence	Durée	Contenu
Sprint Planning	Début de sprint	2h	Décomposition des stories, estimation, engagement
Daily Standup	Quotidien	15min	Blockers, progression, coordination
Sprint Review	Fin de sprint	1h	Démo du livrable, feedback
Sprint Retro	Fin de sprint	45min	Amélioration continue
Architecture Decision Record	Ad hoc	30min	Documentation des choix techniques clés
Security Review	Toutes les 2 semaines (dès M3)	1h	Revue sécurité des développements récents

B.3 — Gestion des repos et conventions

• Monorepo : Un seul repo GitLab contenant : /cmd/proxy (Go main), /internal/ (modules Go), /services/pii (Python), /web (React), /deploy (Helm charts), /proto (gRPC schemas), /docs.

• Branching : Trunk-based development. Feature branches courtes (<3 jours). Merge via MR avec 1 review obligatoire. CI passe avant merge.

• Commits : Conventional Commits (feat:, fix:, chore:). Changelog généré automatiquement.

• Environnements : dev (local docker-compose), staging (K8s cluster dédié, deploy auto sur merge to main), production (K8s, deploy manuel approuvé).

Partie C — Plan d’exécution sprint par sprint

Le plan est découpé en 13 sprints de 2 semaines (26 semaines = 6 mois). Chaque sprint a un objectif clair, des tâches décomposées, des critères d’acceptance, et des dépendances explicitées.

Légende priorités : BLOQUANT = sur le chemin critique, aucun retard acceptable. IMPORTANT = décalable d’1 sprint max. SOUHAITABLE = nice-to-have pour ce sprint.

PHASE 1 — Fondations (Sprints 1–4, Semaines 1–8)

Objectif de phase : Un proxy fonctionnel qui relaie des requêtes vers OpenAI avec authentification, et l’infrastructure complète pour développer efficacement.

Sprint 1 — Semaines 1–2 : Bootstrapping

Objectif : Toute l’équipe peut développer, tester et déployer. Le squelette applicatif compile et se déploie en staging.

#	Tâche	Responsable	Priorité	Critère d’acceptance
1.1	Création monorepo GitLab + structure de dossiers (/cmd, /internal, /services/pii, /web, /deploy, /proto, /docs)	DevOps	BLOQUANT	Repo accessible, README avec instructions de setup local
1.2	Pipeline CI/CD GitLab : build Go, build Python, build React, lint, tests unitaires, scan Trivy	DevOps	BLOQUANT	Pipeline green sur commit vide. Build < 5min
1.3	Docker Compose local : Go app + PostgreSQL 16 + ClickHouse + Redis 7 + Keycloak	DevOps	BLOQUANT	docker-compose up démarre tout en < 60s. Health checks OK
1.4	Cluster K8s staging (AWS EKS eu-west-3) + namespace + ingress Traefik	DevOps	BLOQUANT	kubectl get nodes retourne 3 nodes. Ingress accessible via HTTPS
1.5	Scaffolding Go : main.go, server HTTP (chi router), middleware chain vide, graceful shutdown, health endpoint	Lead Backend	BLOQUANT	GET /healthz retourne 200. Graceful shutdown fonctionne (SIGTERM)
1.6	Configuration management : Viper (Go) + fichier config.yaml + override par env vars	Lead Backend	IMPORTANT	Config chargée au démarrage. Pas de valeurs hardcodées
1.7	Modèle de données PostgreSQL v1 : tables tenants, users, api_keys + migrations (golang-migrate)	Backend Sr	IMPORTANT	Migrations up/down fonctionnent. Schema créé proprement
1.8	Setup Keycloak : realm par défaut, client OIDC, utilisateur test	DevOps	IMPORTANT	Login via Keycloak retourne un JWT valide
1.9	Définition des schemas gRPC (proto/) : PiiRequest, PiiResponse, PiiEntity	Lead Backend + Backend Sr	IMPORTANT	Proto compile sans erreur. Stubs Go et Python générés
1.10	Scaffolding service PII Python : FastAPI + endpoint gRPC + Dockerfile + pytest setup	Backend Sr	SOUHAITABLE	Service démarre, répond à un healthcheck gRPC

Dépendances : 1.5 dépend de 1.1. 1.4 dépend de 1.2. 1.7 dépend de 1.3. 1.8 dépend de 1.3. 1.9 dépend de 1.5 et 1.10.

Risque sprint : Setup EKS peut prendre plus longtemps que prévu (IAM, VPC, security groups). Mitigation : utiliser un module Terraform prouvé (terraform-aws-eks) ou Pulumi.

Sprint 2 — Semaines 3–4 : Proxy core + Auth

Objectif : Le proxy relaie des requêtes vers OpenAI (non-streaming ET streaming SSE) avec authentification JWT.

#	Tâche	Responsable	Priorité	Critère d’acceptance
2.1	Module Proxy — relay non-streaming : recevoir POST /v1/chat/completions, forwarder à OpenAI, retourner la réponse	Lead Backend	BLOQUANT	curl vers le proxy retourne la même réponse qu’un appel direct à OpenAI
2.2	Module Proxy — relay streaming SSE : support du paramètre stream:true, flush chunk par chunk au client	Lead Backend	BLOQUANT	Client reçoit les chunks en temps réel. Pas de buffering. Test avec curl --no-buffer
2.3	Middleware Auth : validation JWT (signature RS256, expiration, issuer Keycloak), extraction claims (user_id, tenant_id, roles)	Backend Sr	BLOQUANT	Requête sans JWT = 401. JWT expiré = 401. JWT valide = forward + contexte injecté
2.4	Middleware Request ID : génération UUID v7 par requête, propagation dans tous les headers et logs	Lead Backend	IMPORTANT	Chaque réponse contient X-Request-Id. Logs contiennent le même ID
2.5	Middleware Logging basique : log de chaque requête (méthode, path, status, durée) en JSON structuré (zerolog)	Lead Backend	IMPORTANT	Logs visibles dans stdout. Format JSON parseable
2.6	Tests unitaires proxy : 15+ tests couvrant les cas nominaux, erreurs OpenAI, timeouts, headers	Lead Backend	IMPORTANT	Coverage > 80% sur le module proxy. go test -race passe
2.7	Tests d’intégration auth : test avec Keycloak via testcontainers	Backend Sr	IMPORTANT	Test end-to-end : obtenir token Keycloak → appeler proxy → succès
2.8	Déploiement auto staging : merge to main déploie en staging via Helm	DevOps	IMPORTANT	Chaque merge déclenche un déploiement. Rollback possible en 1 commande
2.9	Prometheus metrics basiques : request_count, request_duration_seconds, request_errors_total	DevOps	SOUHAITABLE	Métriques visibles dans Grafana staging

Dépendances : 2.1–2.2 sont sur le chemin critique — tout le reste en dépend. 2.3 dépend de 1.8 (Keycloak). 2.8 dépend de 1.4 (K8s staging).

Risque sprint : Le streaming SSE est le point technique le plus délicat du projet. Le proxy doit flusher les chunks sans bufferiser. En Go, cela nécessite un Flusher HTTP custom et une gestion fine des goroutines. Prévoir 3-4 jours de debug.

Sprint 3 — Semaines 5–6 : Anonymisation PII v1

Objectif : Le pipeline PII détecte et anonymise les données sensibles dans les prompts avant envoi au LLM. Dé-pseudonymisation fonctionnelle.

#	Tâche	Responsable	Priorité	Critère d’acceptance
3.1	PII Couche 1 — Regex : patterns compilés pour IBAN FR/EU, emails, téléphones FR/intl, n° SS, cartes bancaires (Luhn)	Backend Sr	BLOQUANT	Jeu de tests de 100+ exemples positifs/négatifs. Precision > 99%, Recall > 95%
3.2	PII Couche 2 — NER : intégration Presidio avec modèle spaCy fr_core_news_lg. Détection noms, adresses, organisations	Backend Sr	BLOQUANT	Benchmark sur corpus français : F1-score > 0.90 sur les entités PER, LOC, ORG
3.3	Pipeline unifié : orchestration regex → NER, déduplication des détections, scoring de confiance unifié	Backend Sr	BLOQUANT	Un prompt contenant 5 types de PII différents les détecte tous. Latence < 50ms sur prompt de 500 tokens
3.4	Pseudonymisation : remplacement par tokens [PII:TYPE:UUID], stockage mapping dans Redis (AES-256-GCM, TTL configurable)	Backend Sr	BLOQUANT	Le prompt envoyé au LLM ne contient aucune PII en clair. Le mapping est chiffré dans Redis
3.5	Dé-pseudonymisation : réinjection des valeurs originales dans la réponse du LLM	Backend Sr	BLOQUANT	La réponse renvoyée à l’utilisateur contient les valeurs originales, pas les tokens
3.6	Intégration gRPC Proxy ↔ PII : le proxy Go appelle le service PII Python via gRPC avant chaque forward	Lead Backend	BLOQUANT	Le flux complet fonctionne : user → proxy → PII (gRPC) → LLM → PII (de-pseudo) → user
3.7	Benchmark latence : mesure p50, p95, p99 du pipeline PII sur 1000 requêtes variées	Backend Sr	IMPORTANT	p99 < 50ms pour prompts < 500 tokens. p99 < 100ms pour prompts < 2000 tokens
3.8	Tests unitaires PII : 50+ tests couvrant chaque type de PII, edge cases, texte multilangue	Backend Sr	IMPORTANT	pytest passe. Coverage > 85% sur le service PII

Chemin critique : Ce sprint est le plus risqué techniquement. Si le p99 dépasse 100ms, il faut envisager : (a) cache des patterns déjà vus, (b) mode « regex-only » pour les requêtes basse sensibilité, (c) préchargement du modèle spaCy en mémoire (pas de cold start).

Sprint 4 — Semaines 7–8 : Multi-modèle + RBAC

Objectif : Le proxy supporte 4+ fournisseurs IA. Le RBAC contrôle qui accède à quoi.

#	Tâche	Responsable	Priorité	Critère d’acceptance
4.1	Adapter OpenAI : normalisation du format de requête/réponse vers le schema interne unifié	Lead Backend	BLOQUANT	Requête interne → OpenAI → réponse interne. Streaming inclus
4.2	Adapter Anthropic : support Messages API, format claude-sonnet, streaming	Lead Backend	BLOQUANT	Même test que 4.1 avec Anthropic. Mapping system/user/assistant correct
4.3	Adapter Azure OpenAI : endpoint custom, API version, déploiement ID	Lead Backend	IMPORTANT	Fonctionne avec un déploiement Azure test
4.4	Adapter Ollama/vLLM : support modèles locaux via API OpenAI-compatible	Lead Backend	IMPORTANT	Fonctionne avec un Ollama local tournant Llama 3
4.5	Adapter Mistral : support API Mistral chat/completions	Lead Backend	SOUHAITABLE	Test fonctionnel avec mistral-small
4.6	Interface Adapter commune : trait/interface Go avec méthodes Send(), Stream(), Validate(), HealthCheck()	Lead Backend	BLOQUANT	Tous les adapters implémentent la même interface. Tests génériques passent
4.7	Module RBAC : modèle de données (roles, permissions, role_assignments), middleware d’autorisation	Backend Sr	BLOQUANT	User sans permission sur un modèle = 403. Admin = accès total. Auditor = read-only
4.8	RBAC intégration Keycloak : synchronisation des rôles depuis les groupes Keycloak	DevOps	IMPORTANT	Un user ajouté au groupe « admin » dans Keycloak obtient le rôle admin dans l’app
4.9	API tenant management : CRUD tenants, configuration de base (nom, providers autorisés, API keys encryptées)	Backend Sr	IMPORTANT	POST /v1/admin/tenants crée un tenant. Les API keys sont stockées chiffrées (pas en clair en DB)
4.10	Tests d’intégration multi-modèle : test automatisé qui envoie la même requête à chaque adapter et valide la réponse	Lead Backend	IMPORTANT	Test CI green pour OpenAI + Anthropic (les autres en mock si pas de clé dispo)

État à la fin de Phase 1 : Le proxy intercepte les requêtes, authentifie via JWT/Keycloak, anonymise les PII, route vers le bon modèle IA (OpenAI, Anthropic, Azure, local), et renvoie la réponse dé-pseudonymisée. C’est déjà démontrable à un prospect via curl.

PHASE 2 — Intelligence et visibilité (Sprints 5–8, Semaines 9–16)

Objectif de phase : Routage intelligent, journalisation complète, dashboard fonctionnel, et début du module conformité. Le produit devient démontrable avec UI.

Sprint 5 — Semaines 9–10 : Moteur de routage

Objectif : Les requêtes sont routées automatiquement selon des politiques configurables par tenant.

#	Tâche	Responsable	Priorité	Critère d’acceptance
5.1	Modèle de données politiques : table routing_rules (conditions JSONB, action, priority, tenant_id)	Backend Sr	BLOQUANT	Migration appliquée. CRUD fonctionnel via API interne
5.2	Moteur de règles : évaluateur de conditions (user.department, request.sensitivity, etc.) par priorité décroissante	Lead Backend	BLOQUANT	10 règles évaluées en < 1ms. Règle la plus prioritaire gagne. Catch-all fonctionne
5.3	Intégration sensitivity scoring : le score PII détermine le sensitivity_level utilisé dans le routage	Lead Backend	BLOQUANT	Prompt avec PII critique → sensitivity=critical → route vers modèle local
5.4	Fallback chain : si le modèle primaire échoue, bascule vers secondaire puis global	Lead Backend	IMPORTANT	Test : mock un provider en erreur 500, vérifier le fallback. Log de fallback généré
5.5	Circuit breaker : désactivation automatique d’un provider après 5 erreurs consécutives. Réactivation après 60s	Lead Backend	IMPORTANT	Test : envoyer 6 requêtes à un provider mock KO → les 5 dernières sont redirigées
5.6	Cache des règles : les politiques sont cachées en mémoire (refresh toutes les 30s ou sur event)	Lead Backend	IMPORTANT	Modification d’une règle visible en < 30s sans redémarrage
5.7	API admin politiques : CRUD /v1/admin/policies avec validation des conditions	Backend Sr	IMPORTANT	Création d’une politique via API. Validation des champs (pas de condition invalide)
5.8	Tests moteur de règles : 30+ tests couvrant combinaisons de conditions, priorités, conflits	Lead Backend	IMPORTANT	go test passe. 100% des cas de conditions documentés testés

Sprint 6 — Semaines 11–12 : Journalisation + Tokens

Objectif : Chaque requête est loggée dans ClickHouse avec tous les champs définis dans le PRD. Comptage des tokens fonctionnel.

#	Tâche	Responsable	Priorité	Critère d’acceptance
6.1	Schema ClickHouse : table audit_logs avec tous les 20 champs du PRD, partitionnement par mois, TTL 90j pour hot tier	Backend Sr	BLOQUANT	Table créée. INSERT fonctionne. SELECT avec GROUP BY sur 100k lignes < 500ms
6.2	Module Logger Go : collecte asynchrone des métadonnées de chaque requête, batch insert ClickHouse (toutes les 1s ou 100 logs)	Backend Sr	BLOQUANT	Aucun log perdu sous charge (1000 req/s). Insert async ne bloque pas le proxy
6.3	Hash SHA-256 du prompt et de la réponse (pas le contenu brut dans les logs)	Backend Sr	BLOQUANT	Les logs ne contiennent aucun contenu en clair. Hash vérifiable
6.4	Chiffrement applicatif du champ prompt_anonymized (AES-256-GCM, clé dérivée par tenant via KMS)	Backend Sr	IMPORTANT	Le champ est illisible en DB sans la clé. Déchiffrement fonctionne via l’API
6.5	Module Billing : comptage tokens (tiktoken pour OpenAI, approximation pour les autres), agrégation par user/dept/model	Backend Sr	IMPORTANT	Comptage OpenAI = ±5% du comptage officiel. Agrégation par dept fonctionne
6.6	API de consultation des logs : GET /v1/admin/logs avec filtres (date, user, model, status) et pagination	Backend Sr	IMPORTANT	Requête filtrée retourne en < 2s sur 1M de logs
6.7	API coûts : GET /v1/admin/costs avec agrégation par période/model/dept	Backend Sr	SOUHAITABLE	Dashboard data endpoint fonctionnel

Sprint 7 — Semaines 13–14 : Dashboard frontend v1

Objectif : Première version du dashboard avec authentification, vue d’ensemble, et gestion des politiques.

#	Tâche	Responsable	Priorité	Critère d’acceptance
7.1	Setup React + TypeScript + Vite + TailwindCSS + shadcn/ui. Structure de pages, routing (react-router)	Frontend	BLOQUANT	npm run dev lance l’app. Build < 30s. Pas d’erreur TypeScript
7.2	Auth flow : login via Keycloak (OIDC PKCE), gestion des tokens, refresh, logout, redirect	Frontend	BLOQUANT	Login → redirect Keycloak → retour sur le dashboard avec session active. Refresh automatique
7.3	Page Overview : cartes KPI (requêtes 24h, PII détectées, coût total, modèle le plus utilisé)	Frontend	BLOQUANT	Données réelles depuis l’API. Mise à jour toutes les 30s
7.4	Graphique volume de requêtes (recharts) : line chart 7j/30j, breakdown par modèle ou département	Frontend	IMPORTANT	Chart interactif avec tooltip. Changement de période fonctionne
7.5	Page Politiques : liste des règles de routage, création/édition via formulaire, activation/désactivation	Frontend	IMPORTANT	CRUD complet sur les politiques depuis l’UI. Validation côté client
7.6	Page Utilisateurs : liste des users, attribution de rôles, filtrage par département	Frontend	IMPORTANT	Admin peut changer le rôle d’un user. Changement immédiatement effectif
7.7	Layout général : sidebar navigation, header avec tenant name, responsive design	Frontend	IMPORTANT	Navigation fluide. Pas de scroll horizontal sur 1280px
7.8	Guards de permission : les pages admin ne sont pas accessibles aux rôles User. Auditor = read-only	Frontend	IMPORTANT	User rôle « user » ne voit pas les pages admin. Auditor ne peut pas modifier

Sprint 8 — Semaines 15–16 : Dashboard sécurité + Playground

Objectif : Le dashboard inclut la vue sécurité RSSI et un playground démonstratif.

#	Tâche	Responsable	Priorité	Critère d’acceptance
8.1	Page Sécurité : volume PII par type (bar chart), requêtes bloquées, top users PII, timeline des incidents	Frontend	BLOQUANT	Données réelles. Filtrage par période. Export CSV
8.2	Page Coûts : breakdown par modèle (pie chart), par département, tendance mensuelle, alerte budget	Frontend	BLOQUANT	Projection du coût mensuel visible. Alerte si > 80% du budget
8.3	Playground (killer feature démo) : zone de texte où on tape un prompt, visualisation en temps réel des PII détectées (highlight coloré), choix du modèle, envoi et réponse	Frontend + Lead	IMPORTANT	Taper un IBAN dans le prompt le highlight en rouge. Envoi au LLM montre le prompt anonymisé
8.4	Page Logs (Audit Trail) : tableau paginable des logs, filtres (date, user, model, status, sensitivity), détail expand	Frontend	IMPORTANT	Pagination fluide sur 100k+ logs. Filtres combinent correctement
8.5	Alertes basiques : notification in-app quand un seuil est dépassé (PII/h, coût/j, erreurs/h)	Frontend + Backend Sr	IMPORTANT	Configuration des seuils par l’admin. Notification visible dans le dashboard
8.6	Wizard configuration provider : formulaire guidé pour ajouter un nouveau provider IA (API key, endpoint, modèle par défaut)	Frontend	SOUHAITABLE	Ajout d’un provider en 3 étapes. Test de connexion intégré

État à la fin de Phase 2 : Le produit est démontrable en intégralité via l’UI. Proxy + PII + Routage + Logs + Dashboard + RBAC fonctionnent ensemble. Le playground permet une démo impressionnante en 5 minutes. On peut commencer à démarcher des clients pilotes.

PHASE 3 — Conformité et hardening (Sprints 9–10, Semaines 17–20)

Objectif de phase : Rapports conformité RGPD et AI Act, hardening sécurité, préparation au pentest.

Sprint 9 — Semaines 17–18 : Module conformité

#	Tâche	Responsable	Priorité	Critère d’acceptance
9.1	Modèle de données registre des traitements : table processing_registry (finalité, base légale, destinataires, durée, mesures sécurité, tenant_id)	Backend Sr	BLOQUANT	CRUD fonctionnel. Chaque cas d’usage IA est documentable
9.2	Classification risque AI Act : enum (forbidden, high_risk, limited_risk, minimal_risk) par cas d’usage, avec questionnaire guidé	Backend Sr	BLOQUANT	Un admin peut classifier chaque usage. La classification est stockée et exportée
9.3	Génération rapport PDF Article 30 RGPD (via go-pdf ou WeasyPrint) : registre complet avec tous les champs obligatoires	Backend Sr	BLOQUANT	GET /v1/admin/compliance/report?format=pdf retourne un PDF lisible, complet, daté
9.4	Génération rapport AI Act : fiche par système IA (modèle, classification, mesures, logs)	Backend Sr	IMPORTANT	PDF contient classification, mesures de mitigation, stats d’usage
9.5	API droits RGPD — accès (Art. 15) : export de toutes les données liées à un user_id	Backend Sr	IMPORTANT	GET /v1/admin/gdpr/access/{user_id} retourne JSON avec tous les logs associés
9.6	API droits RGPD — effacement (Art. 17) : suppression des logs et mappings PII d’un user	Backend Sr	IMPORTANT	DELETE /v1/admin/gdpr/erase/{user_id} supprime et loggue la suppression
9.7	Page Conformité frontend : registre des traitements, classification AI Act, génération rapports	Frontend	IMPORTANT	Formulaire de saisie intuitif. Bouton « Générer rapport » télécharge le PDF

Sprint 10 — Semaines 19–20 : Hardening sécurité

#	Tâche	Responsable	Priorité	Critère d’acceptance
10.1	mTLS entre tous les composants internes (proxy ↔ PII, proxy ↔ DB, proxy ↔ ClickHouse) via cert-manager + Istio/linkerd	DevOps	BLOQUANT	Wireshark sur le réseau interne ne montre que du trafic chiffré. Pas de communication en clair
10.2	Network policies Kubernetes : deny-all par défaut, whitelist explicite pour chaque communication	DevOps	BLOQUANT	Un pod ne peut pas contacter un service non autorisé. Test : curl depuis un pod aléatoire échoue
10.3	Intégration HashiCorp Vault : stockage des API keys LLM, credentials DB, clés de chiffrement. Accès via service account K8s	DevOps	BLOQUANT	Aucun secret en variable d’environnement ou en ConfigMap. Vault audit log actif
10.4	SAST intégré CI : Semgrep avec rulesets Go + Python + React. Bloque le merge si finding critique	DevOps	IMPORTANT	Pipeline bloque sur un code avec SQL injection. Zero critical finding sur le code actuel
10.5	Scan images Docker : Trivy en CI. Bloque si vulnérabilité critique non patchée	DevOps	IMPORTANT	Toutes les images de base sont pinned (sha256). Zero CVE critique
10.6	DAST : OWASP ZAP automatisé sur staging. Rapport généré à chaque déploiement	DevOps	IMPORTANT	Rapport ZAP sans finding critique (Medium accepté si justifié)
10.7	Audit logging : toutes les actions admin (modification politique, accès logs, modification RBAC) sont loggées dans une table admin_audit_logs	Backend Sr	IMPORTANT	Toute modification par un admin est traçable avec timestamp, user, before/after
10.8	Rate limiting par tenant et par user : configuration via Kong (ou middleware Go)	Lead Backend	IMPORTANT	Un user dépassant sa limite reçoit 429. Configurable par tenant
10.9	Tests de charge : k6 ou vegeta, cible 1000 req/s soutenues pendant 10 min, p99 < 300ms	DevOps + Lead	IMPORTANT	Rapport de charge validé. Pas d’OOM, pas de goroutine leak, pas de connexion DB saturante

État à la fin de Phase 3 : Le produit est sécurisé, conforme, et prêt pour un audit externe. Les rapports RGPD et AI Act sont générables en 1 clic. Toutes les communications internes sont chiffrées. Aucun secret en clair.

PHASE 4 — Beta, polish et lancement (Sprints 11–13, Semaines 21–26)

Objectif de phase : Beta privée avec 2–3 clients pilotes, remédiation, pentest, lancement production.

Sprint 11 — Semaines 21–22 : Beta privée

#	Tâche	Responsable	Priorité	Critère d’acceptance
11.1	Tests E2E automatisés : 20+ scénarios couvrant le parcours complet (login → config provider → envoi prompt → vérif PII → log → rapport)	Tous	BLOQUANT	Suite E2E green en CI. Temps d’exécution < 10min
11.2	Documentation API complète : OpenAPI 3.1 généré (swaggo), publiée sur /docs	Lead Backend	BLOQUANT	Swagger UI accessible. Tous les endpoints documentés avec exemples
11.3	Guide d’intégration : comment configurer son application pour utiliser le proxy (changement d’URL base, headers auth)	Lead Backend	BLOQUANT	Un dev externe peut intégrer en < 30 min en suivant le guide
11.4	Onboarding client pilote #1 : création tenant, configuration SSO (SAML/OIDC), import users, setup providers	PM + DevOps	BLOQUANT	Client opérationnel en < 1 journée. Premières requêtes relayées avec succès
11.5	Onboarding client pilote #2	PM + DevOps	IMPORTANT	Idem #1. Vérifie que le processus est reproductible
11.6	Guide utilisateur admin : PDF/web expliquant chaque fonctionnalité du dashboard	PM	IMPORTANT	Relu par un non-technique. Captures d’écran à jour
11.7	Feature flags : désactivation possible de chaque module (PII, routing, billing) par tenant	Lead Backend	IMPORTANT	Toggle via API admin. Effet immédiat sans redémarrage

Sprint 12 — Semaines 23–24 : Feedback + Pentest

#	Tâche	Responsable	Priorité	Critère d’acceptance
12.1	Collecte et tri du feedback clients pilotes : bugs, améliorations UX, features manquantes	PM	BLOQUANT	Backlog priorisé avec les retours classés (bug / UX / feature)
12.2	Bug fixes critiques identifiés par les pilotes	Tous	BLOQUANT	Zero bug bloquant restant. Bugs medium avec workaround documenté
12.3	Améliorations UX prioritaires (top 5 retours)	Frontend	IMPORTANT	Les 5 points UX les plus remontés sont corrigés
12.4	Pentest externe (cabinet spécialisé, grey box) : scope = API + dashboard + infra	Externe + DevOps	BLOQUANT	Pentest démarré, périmètre validé, accès fournis. Rapport attendu S24-S25
12.5	Optimisation performance : analyse des bottlenecks identifiés en production beta	Lead Backend	IMPORTANT	p99 proxy amélioré si problème identifié. Pas de requête > 5s
12.6	Blue/green deployment setup : déploiement sans downtime, rollback en 1 commande	DevOps	IMPORTANT	Déploiement de staging testé en blue/green. Rollback < 30s

Sprint 13 — Semaines 25–26 : Lancement production

#	Tâche	Responsable	Priorité	Critère d’acceptance
13.1	Remédiation findings pentest : corriger tous les findings Critical et High, documenter l’acceptation des Medium	Tous	BLOQUANT	Zero finding Critical/High ouvert. Rapport de remédiation produit
13.2	Déploiement cluster production : AWS eu-west-3, 3 AZ, autoscaling, backup quotidien PostgreSQL, replication ClickHouse	DevOps	BLOQUANT	Cluster production opérationnel. DR testé (restauration backup < 1h)
13.3	Monitoring production : Grafana dashboards (proxy latency, error rate, PII volume, DB connections), alertes PagerDuty/Slack	DevOps	BLOQUANT	Alerte test reçue en < 5min. Dashboard affiche les métriques production
13.4	Runbooks opérationnels : procédures pour incidents courants (provider down, DB full, cert expiré, traffic spike)	DevOps	IMPORTANT	5+ runbooks rédigés. Chaque runbook testé en staging
13.5	Landing page + démo interactive (vidéo 3min ou playground public)	PM + Frontend	IMPORTANT	Page live. Formulaire de contact fonctionnel. Démo convaincante en < 3min
13.6	Migration clients pilotes vers production	PM + DevOps	BLOQUANT	Clients opérationnels en production. Données migrées si applicable
13.7	Matériel commercial : one-pager PDF, deck 10 slides, battle card RSSI/DSI/DPO	PM	IMPORTANT	Validé par au moins 1 prospect. Pas de jargon technique excessif
13.8	Rétrospective projet + planification V1.1	Tous	SOUHAITABLE	Retro documentée. Backlog V1.1 priorisé

Partie D — Chemin critique et dépendances

D.1 — Chemin critique (tâches qui, si retardées, retardent tout)

Sprint	Tâches critiques	Raison
S1	1.1 Monorepo + 1.3 Docker Compose + 1.4 K8s staging	Sans infra, personne ne peut travailler
S2	2.1–2.2 Proxy non-streaming + streaming SSE	Le proxy est le cœur. Tout en dépend.
S3	3.1–3.6 Pipeline PII complet + intégration gRPC	L’anonymisation est le différenciateur. Si la latence est trop haute, le produit est inutilisable
S5	5.2 Moteur de règles	Le routage est la valeur ajoutée pour le DSI
S6	6.1–6.2 Journalisation ClickHouse	Sans logs, pas de dashboard ni de conformité
S9	9.3 Génération rapport RGPD	Sans rapport, pas de vente au DPO
S10	10.1–10.3 mTLS + Network policies + Vault	Sans sécurité, pas de vente enterprise
S12	12.4 Pentest	Le pentest doit être commandé au plus tard S10 (délai 2-3 semaines pour un cabinet)
S13	13.1–13.2 Remédiation + Production	Le lancement ne peut pas être retardé au-delà de S13 sans impact commercial

D.2 — Actions à lancer en avance

Certaines actions doivent être initiées bien avant leur sprint cible :

Action	Démarrer à	Nécessaire pour	Responsable
Identifier et contacter 5 prospects pilotes	Semaine 1	S11 (onboarding beta)	PM
Négocier accès Azure AD test pour intégration SAML	Semaine 2	S4 (RBAC Keycloak)	PM + DevOps
Rédiger cahier des charges pentest + contacter 3 cabinets	Semaine 12	S12 (pentest)	PM + DevOps
Signer DPA avec les providers IA (OpenAI, Anthropic, etc.)	Semaine 4	S9 (conformité)	PM + Légal
Obtenir un avis juridique sur la conformité RGPD de l’architecture	Semaine 8	S9 (rapports conformité)	PM + Légal
Commander les certificats SSL production + domaine	Semaine 18	S13 (production)	DevOps
Créer le compte AWS production + setup Organization + billing alerts	Semaine 16	S13 (production)	DevOps

Partie E — Métriques de suivi et gates de qualité

E.1 — Quality Gates par phase

Chaque phase a des critères de passage obligatoires. Si un gate n’est pas passé, on ne passe pas à la phase suivante.

Phase	Gate	Critère de passage
Phase 1 → Phase 2	Proxy + PII + Auth fonctionnels	Démo en live : envoyer un prompt avec PII via le proxy, montrer l’anonymisation et la réponse dé-pseudonymisée. < 300ms total.
Phase 2 → Phase 3	Dashboard démontrable	Démo complète en live : login → dashboard → playground → politiques → logs. Toutes les données sont réelles (pas de mocks).
Phase 3 → Phase 4	Sécurité validée	Zero finding critique SAST/DAST. mTLS actif. Vault intégré. Rapport RGPD générable. Test de charge passé.
Phase 4 → Lancement	Production ready	Pentest passé (zero critical). Monitoring opérationnel. Au moins 1 client pilote satisfait. Runbooks rédigés.

E.2 — KPIs techniques à suivre chaque sprint

KPI	Cible	Mesure
Test coverage (Go)	> 75%	go test -cover. Vérifié en CI
Test coverage (Python)	> 85%	pytest --cov. Vérifié en CI
Latence proxy p99 (sans PII)	< 50ms	Prometheus histogram
Latence proxy p99 (avec PII)	< 150ms	Prometheus histogram
Uptime staging	> 99%	Healthcheck monitoring
Build time CI	< 8 min	GitLab CI metrics
Déploiement staging	< 5 min	Helm upgrade timing
CVE critiques non patchées	0	Trivy + Snyk
Findings SAST critiques	0	Semgrep
Nombre de secrets en clair	0	gitleaks en CI
Taux de détection PII (F1-score)	> 0.92	Benchmark sur corpus de test

Partie F — Gestion des risques projet

#	Risque	Probabilité	Impact	Détection	Plan de mitigation	Plan de contingence (si le risque se matérialise)
R1	Latence PII > 100ms rendant le produit inutilisable	Moyenne	Critique	Benchmark S3	Cache des patterns, préchargement spaCy, mode regex-only pour les requêtes basse sensibilité	Basculer sur regex-only pour le MVP. Reporter NER en V1.1. Impact : précision réduite mais produit livrable
R2	Streaming SSE incompatible avec le pipeline PII (on ne peut pas anonymiser un stream)	Haute	Haut	Sprint 3	En streaming, les PII sont détectées sur le prompt AVANT envoi (pas sur la réponse streamée). La réponse streamée n’est pas anonymisée (le prompt l’a déjà été).	Si nécessaire : bufferiser la réponse complète avant anonymisation, au prix de la latence perçue. Feature flag par tenant.
R3	Départ d’un développeur clé en cours de projet	Moyenne	Critique	Continu	Documentation systématique (ADR, README par module). Code reviews croisées pour que chacun connaisse 2+ modules	Recrutement d’un consultant senior en urgence (via Malt/Toptal). Accepter un retard de 2-4 semaines.
R4	Client pilote indisponible ou non engagé	Haute	Haut	Semaine 8	Identifier 5 prospects dès S1. Signer un LOI (Letter of Intent) dès S6	Utiliser le produit en interne comme premier client. Démo sur données synthétiques pour les prospects.
R5	ClickHouse trop complexe à opérer pour l’équipe	Moyenne	Moyen	Sprint 6	Utiliser ClickHouse Cloud (managé) plutôt que self-hosted. Ou démarrer avec TimescaleDB et migrer en V1.1	Fallback sur PostgreSQL + partitionnement temporel pour le MVP. Moins performant mais opérable.
R6	L’AI Act évolue et invalide notre classification	Basse	Moyen	Continu	Veille réglementaire mensuelle. Classification configurable (pas hardcodée)	Mise à jour de la classification en 1-2 semaines (c’est de la config, pas du code).

Partie G — Budget estimatif sur 6 mois

Poste	Détail	Coût mensuel	Coût 6 mois
Équipe (salaires/TJM)	4 ETP seniors (TJM moyen 650€) + 0.5 PM (TJM 550€)	~60 000 €	~360 000 €
Infra cloud (staging + prod)	EKS (3 nodes m5.xlarge), RDS PostgreSQL, ClickHouse Cloud, Redis, S3	~3 500 €	~21 000 €
Services SaaS	GitLab Premium, Vault Cloud, monitoring, domaines	~800 €	~4 800 €
API IA (dév/test)	OpenAI, Anthropic, Mistral pour tests d’intégration	~500 €	~3 000 €
Pentest externe	Cabinet spécialisé, grey box, 5 jours	Ponctuel	~12 000 €
Juridique (DPA, CGV, RGPD)	Avocat spécialisé tech/RGPD	Ponctuel	~8 000 €
Divers (licences, formations)	Conférences, tools individuels	~300 €	~1 800 €
TOTAL			~410 000 €

Note : Ce budget suppose une équipe en freelance/CDI. Si l’équipe est déjà en place, le coût se réduit à ~50k€ (infra + pentest + juridique). Le point mort est atteignable avec 1 client Enterprise (40k€ MRR) dès le mois 7.

Partie H — Checklist de lancement (Go/No-Go)

Cette checklist doit être validée à 100% avant le passage en production. Chaque item est un Go/No-Go.

Catégorie	Item	Critère
Fonctionnel	Proxy relay fonctionne pour les 4 providers (OpenAI, Anthropic, Azure, Ollama)	Test E2E green
Fonctionnel	Anonymisation PII fonctionne sur les 6 types de PII (IBAN, email, tél, nom, adresse, SS)	Test E2E green + benchmark F1 > 0.92
Fonctionnel	Streaming SSE fonctionne avec anonymisation du prompt	Démo live
Fonctionnel	Routage intelligent fonctionne avec 5+ règles simultanées	Test E2E green
Fonctionnel	Dashboard affiche données réelles (pas de mock)	Vérification visuelle
Fonctionnel	Rapport RGPD Article 30 générable en PDF	PDF téléchargeable et lisible
Sécurité	Pentest : 0 finding Critical, 0 finding High ouvert	Rapport pentest validé
Sécurité	mTLS actif entre tous les composants	Wireshark test
Sécurité	Vault intégré, 0 secret en clair	Audit Vault + gitleaks
Sécurité	SAST/DAST : 0 finding critique	Rapport Semgrep + ZAP
Performance	Proxy p99 < 300ms sous 500 req/s	Rapport k6
Performance	Dashboard charge en < 3s	Lighthouse score > 70
Ops	Monitoring production opérationnel (Grafana + alertes)	Alerte test reçue
Ops	Backup PostgreSQL automatisé + test de restauration	Restauration en < 1h
Ops	Blue/green deployment fonctionnel	Déploiement testé
Ops	5+ runbooks rédigés et testés	Revue par l’équipe
Commercial	Au moins 1 client pilote satisfait (NPS > 7)	Feedback documenté
Commercial	Landing page + matériel commercial prêt	Page live, démo fonctionnelle
Légal	CGV/CGU rédigées et validées par un avocat	Document signé
Légal	DPA avec les providers IA signés	Documents archivés

Si un item « No-Go » persiste à S25, une décision explicite doit être prise : corriger avant lancement (retard), accepter le risque (documenté), ou retirer la feature (scope cut).

Synthèse

Ce plan transforme le PRD en 13 sprints exécutables contenant 113 tâches décomposées, chacune avec un responsable, une priorité, et un critère d’acceptance mesurable.

Les corrections clés apportées par rapport au PRD :

• Communication Go ↔ Python explicitée (gRPC sidecar)

• Tests intégrés dès le sprint 1 (pas repoussés au mois 5)

• Playground démo ajouté (killer feature pour la vente)

• Buffer de 20% intégré dans chaque estimation

• Chemin critique et dépendances explicités

• Actions à lancer en avance identifiées

• Quality gates entre chaque phase

• Checklist Go/No-Go avant lancement

• Budget réaliste chiffré (~410k€)

Prochaine étape immédiate : Recruter l’équipe (ou confirmer la disponibilité), commander le setup GitLab + AWS, et identifier les 5 premiers prospects pilotes. Le sprint 1 peut démarrer dès que 3 des 4 développeurs sont en place.