**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.
