55 KiB
55 KiB
Veylant IA — Plan Agile Scrum Détaillé
Scrum Master Document — Version 1.0 — Février 2026 Confidentiel — Usage interne équipe
Sommaire
- Cadre Scrum
- Product Backlog — Epics et Stories
- Release Plan — Vision 6 mois
- Sprints Détaillés
- Chemin Critique et Dépendances
- Registre des Risques Scrum
- Métriques et KPIs Scrum
- Actions à Lancer Immédiatement
1. Cadre Scrum
1.1 Équipe Scrum
| Rôle | Personne | Charge | Responsabilité |
|---|---|---|---|
| Product Owner | PM | 50% | Backlog, priorisation, stakeholders, clients pilotes |
| Scrum Master | CTO / Lead Backend | ~10% | Cérémonies, impediments, amélioration continue |
| Dev Team — Backend Go | CTO / Lead Backend | 90% | Proxy, Router, Adapters, API admin |
| Dev Team — Backend Python | Backend Senior | 100% | PII service, Logger, Billing, Compliance |
| Dev Team — Frontend | Frontend Senior | 100% | Dashboard React, Auth flow, UX |
| Dev Team — DevOps/SRE | DevOps | 100% | Infra, CI/CD, Sécurité, Monitoring |
Règle d'or : Le PO est disponible pour des questions bloquantes sous 2h maximum. Tout impediment non résolu en 24h est escaladé en Daily Standup.
1.2 Cérémonies
| Cérémonie | Fréquence | Durée max | Participants | Livrable |
|---|---|---|---|---|
| Sprint Planning | J1 du sprint | 3h | Toute l'équipe | Sprint Backlog validé + Sprint Goal |
| Daily Standup | Quotidien 9h30 | 15 min | Dev Team | Liste d'impediments |
| Backlog Refinement | J6 du sprint | 1h30 | PO + Dev Team | 2 sprints de backlog affinés et estimés |
| Sprint Review | J10 du sprint | 1h | Toute l'équipe + invités | Démo du livrable + feedback |
| Sprint Retrospective | J10 du sprint | 1h | Toute l'équipe | 1-3 actions d'amélioration concrètes |
| Security Review | Toutes les 4 sem. | 1h | Dev Team | Rapport sécurité sprint |
Format Daily Standup (timeboxé 15 min) :
- Ce que j'ai accompli hier (30s/pers)
- Ce que je fais aujourd'hui (30s/pers)
- Mes blockers (durée variable — les résoudre APRÈS le standup)
Format Sprint Review :
- Rappel du Sprint Goal (2 min)
- Démo des stories complétées (30 min) — toujours sur l'environnement staging, jamais en mockup
- Stories non complétées + raison (5 min)
- Feedback PO / invités (15 min)
- Mise à jour du backlog (8 min)
1.3 Definition of Done (DoD)
Une story est Done uniquement si tous ces critères sont remplis :
- Code reviewé et approuvé par au moins 1 autre développeur
- Tests unitaires écrits et verts (coverage > cible du module)
- Tests d'intégration mis à jour si applicable
- Pipeline CI/CD vert (build, lint, test, sécurité, scan)
- Critères d'acceptance validés par le PO ou son délégué
- Documentation technique inline à jour (commentaires, README module)
- Pas de secret ou credential hardcodé (gitleaks passe)
- Pas de CVE critique introduit (Trivy passe)
- Déployé et testé en staging
Une story à 95% n'est pas Done. Partiel = non livré.
1.4 Definition of Ready (DoR)
Une story peut entrer en Sprint Planning uniquement si :
- User Story rédigée (format : En tant que... je veux... afin de...)
- Critères d'acceptance explicites et testables
- Story estimée en Story Points par toute l'équipe
- Dépendances identifiées (et résolues, ou planifiées dans le même sprint)
- Aucun blocker connu non adressé
- Maquettes/specs techniques disponibles si applicable
- Taille ≤ 8 SP (sinon à décomposer)
1.5 Vélocité et Capacité
Capacité brute par sprint :
- 4 développeurs × 10 jours ouvrés × 6h de dev effectif = 240 h/sprint
- Cérémonies : ~5h/pers (planning 3h + daily 2.5h + review 1h + retro 1h = 7.5h → 2 × 3.75h = 7.5h /2 sem) → retrait de ~7h/pers
- Capacité nette : ~212 h/sprint
Échelle Story Points :
| SP | Durée estimée | Exemple |
|---|---|---|
| 1 | < 2h | Modification de config, ajout d'un endpoint trivial |
| 2 | ~demi-journée | Middleware simple, modèle de données basique |
| 3 | ~1 jour | Module simple avec tests |
| 5 | ~2-3 jours | Feature complète avec intégration |
| 8 | ~4-5 jours | Module complexe ou spike technique |
| 13 | > 1 semaine | À décomposer obligatoirement |
Vélocité cible :
| Sprint | Vélocité Cible | Justification |
|---|---|---|
| S1-S2 | 38-40 SP | Ramp-up équipe, setup infra imprévisible |
| S3-S6 | 44-48 SP | Équipe en rythme, domaine complexe |
| S7-S10 | 48-52 SP | Vélocité de croisière |
| S11-S13 | 38-42 SP | Tests E2E, feedback, remédiation |
Total projet estimé : ~580 SP
2. Product Backlog — Epics et Stories
Organisation des Epics
E1 — Infrastructure & DevOps [~70 SP]
E2 — AI Proxy Core [~65 SP]
E3 — Authentification & RBAC [~55 SP]
E4 — Anonymisation PII [~75 SP]
E5 — Multi-provider IA [~40 SP]
E6 — Moteur de Routage [~50 SP]
E7 — Journalisation & Audit [~55 SP]
E8 — Dashboard & Frontend [~85 SP]
E9 — Conformité RGPD & AI Act [~50 SP]
E10 — Sécurité & Hardening [~55 SP]
E11 — Beta, Tests & Lancement [~80 SP]
─────────
TOTAL ESTIMÉ ~680 SP
Note : 680 SP estimés pour ~580 SP de capacité → 15% de buffer naturel. Le delta sera géré par priorisation stricte du backlog.
Stories clés par Epic (format ID — Titre — SP)
Epic 1 — Infrastructure & DevOps
E1-01 — Monorepo GitLab + structure dossiers — 2 SP
E1-02 — Pipeline CI/CD (build Go + Python + React + lint + tests) — 8 SP
E1-03 — Docker Compose local complet (Go + PG + CH + Redis + Keycloak) — 5 SP
E1-04 — Cluster K8s staging AWS EKS eu-west-3 — 8 SP
E1-05 — Helm chart déploiement de l'application — 5 SP
E1-06 — Déploiement automatique staging sur merge to main — 3 SP
E1-07 — Prometheus + Grafana staging — 5 SP
E1-08 — OpenTelemetry + Jaeger — 5 SP
E1-09 — Blue/green deployment production — 8 SP
E1-10 — Cluster K8s production (3 AZ, autoscaling, backup) — 8 SP
E1-11 — Alerting production (PagerDuty/Slack) — 5 SP
E1-12 — Runbooks opérationnels (5+) — 5 SP
E1-13 — Terraform/Pulumi infra-as-code — 3 SP (en parallèle S1)
Epic 2 — AI Proxy Core
E2-01 — Scaffolding Go (chi router, middleware chain, graceful shutdown, /healthz) — 3 SP
E2-02 — Gestion de config (Viper, config.yaml, override env vars) — 2 SP
E2-03 — Proxy relay non-streaming (POST /v1/chat/completions → OpenAI) — 5 SP
E2-04 — Proxy relay streaming SSE (flush chunk par chunk, Flusher HTTP) — 8 SP [SPIKE]
E2-05 — Middleware Request ID (UUID v7, propagation headers/logs) — 2 SP
E2-06 — Middleware error handling (erreurs typées JSON format OpenAI) — 3 SP
E2-07 — Middleware rate limiting (par tenant, par user) — 5 SP
E2-08 — Connection pool HTTP (persistant, timeout configurable) — 3 SP
E2-09 — Circuit breaker (N erreurs → désactivation, réactivation auto) — 5 SP
E2-10 — Health check providers IA (ping cyclique, état dans métriques) — 3 SP
E2-11 — Tests unitaires proxy complets (coverage > 80%, go test -race) — 5 SP
E2-12 — Tests de charge proxy (k6, 1000 req/s, p99 < 300ms) — 8 SP
Epic 3 — Authentification & RBAC
E3-01 — Modèle de données : users, tenants, roles, permissions — 3 SP
E3-02 — Setup Keycloak (realm, client OIDC, utilisateurs test) — 5 SP
E3-03 — Middleware Auth JWT (RS256, expiration, issuer, extraction claims) — 5 SP
E3-04 — RBAC middleware (rôles : Admin, Manager, User, Auditor) — 5 SP
E3-05 — Intégration SAML 2.0 Keycloak (federation Azure AD / Okta) — 8 SP
E3-06 — Synchronisation rôles Keycloak → app — 3 SP
E3-07 — API tenant management (CRUD tenants, providers autorisés, API keys chiffrées) — 5 SP
E3-08 — API user management (CRUD users, attribution rôles, dept) — 5 SP
E3-09 — Feature flags système (table PG + cache Redis) — 3 SP
E3-10 — Tests intégration Auth E2E (Keycloak via testcontainers) — 5 SP
Epic 4 — Anonymisation PII
E4-01 — Schemas gRPC PII (PiiRequest, PiiResponse, PiiEntity, proto v1) — 3 SP
E4-02 — Scaffolding service Python (FastAPI, gRPC server, Dockerfile, pytest) — 3 SP
E4-03 — Couche 1 Regex : IBAN FR/EU, email, tél FR/intl, SS, CB (Luhn) — 5 SP
E4-04 — Tests regex (100+ cas positifs/négatifs, precision > 99%) — 3 SP
E4-05 — Couche 2 NER : Presidio + spaCy fr_core_news_lg (PER, LOC, ORG) — 8 SP
E4-06 — Benchmark NER (F1-score > 0.90, corpus français) — 3 SP
E4-07 — Pipeline unifié (regex → NER, déduplication, scoring confiance) — 5 SP
E4-08 — Pseudonymisation (tokens [PII:TYPE:UUID], mapping Redis AES-256-GCM, TTL) — 5 SP
E4-09 — Dé-pseudonymisation (réinjection valeurs dans réponse LLM) — 5 SP
E4-10 — Intégration gRPC Proxy Go ↔ PII Python — 5 SP
E4-11 — Benchmark latence (p99 < 50ms / 500 tokens, < 100ms / 2000 tokens) — 3 SP
E4-12 — Mode zero-retention (mapping mémoire uniquement, pas Redis) — 3 SP
E4-13 — Tests unitaires PII (50+ cas, multilangue, edge cases) — 5 SP
E4-14 — Option regex-only (feature flag, pour requêtes basse sensibilité) — 3 SP
Epic 5 — Multi-provider IA
E5-01 — Interface Adapter Go (Send(), Stream(), Validate(), HealthCheck()) — 3 SP
E5-02 — Adapter OpenAI (format unifié, streaming SSE) — 5 SP
E5-03 — Adapter Anthropic (Messages API, system/user/assistant, streaming) — 5 SP
E5-04 — Adapter Azure OpenAI (endpoint custom, API version, deployment ID) — 5 SP
E5-05 — Adapter Mistral (chat/completions, modèles small/medium/large) — 3 SP
E5-06 — Adapter Ollama / vLLM (OpenAI-compatible, modèles locaux) — 5 SP
E5-07 — Wizard UI configuration provider (3 étapes, test de connexion) — 5 SP
E5-08 — Tests intégration multi-adapter (mock si pas de clé dispo) — 5 SP
Epic 6 — Moteur de Routage
E6-01 — Modèle de données règles (routing_rules : conditions JSONB, action, priority) — 3 SP
E6-02 — Évaluateur de conditions (department, role, sensitivity, use_case, tokens) — 8 SP
E6-03 — Sensitivity scoring (score PII → sensitivity_level pour le routage) — 3 SP
E6-04 — Fallback chain configurable (primaire → secondaire → global) — 5 SP
E6-05 — Cache des règles (mémoire, refresh 30s ou sur event) — 3 SP
E6-06 — API admin politiques (CRUD /v1/admin/policies, validation) — 5 SP
E6-07 — Tests moteur de règles (30+ cas, priorités, conflits, catch-all) — 5 SP
E6-08 — Exemples de règles préconfigurées (RH, Finance, Engineering) — 3 SP
Epic 7 — Journalisation & Audit
E7-01 — Schéma ClickHouse (audit_logs, 20 champs, partitionnement mensuel, TTL) — 5 SP
E7-02 — Module Logger Go (collecte async, batch insert 1s/100 logs) — 8 SP
E7-03 — Hash SHA-256 prompt/réponse (pas de contenu brut dans les logs) — 2 SP
E7-04 — Chiffrement applicatif champ prompt_anonymized (AES-256-GCM) — 5 SP
E7-05 — Module Billing (comptage tokens tiktoken, agrégation user/dept/model) — 5 SP
E7-06 — API consultation logs (GET /v1/admin/logs, filtres, pagination, < 2s) — 5 SP
E7-07 — API coûts (GET /v1/admin/costs, agrégation période/model/dept) — 3 SP
E7-08 — API alertes budget (seuils configurables par tenant, notification) — 5 SP
E7-09 — Audit de l'audit (log des accès admin_audit_logs) — 3 SP
E7-10 — Export CSV logs filtrés — 3 SP
E7-11 — Tests Logger (1000 req/s sans perte, insert async non bloquant) — 5 SP
Epic 8 — Dashboard & Frontend
E8-01 — Setup React + TypeScript + Vite + TailwindCSS + shadcn/ui — 3 SP
E8-02 — Auth flow frontend (OIDC PKCE, refresh token, logout, redirect) — 5 SP
E8-03 — Layout général (sidebar, header tenant, responsive 1280px) — 3 SP
E8-04 — Route guards (admin/auditor/user permissions, pages protégées) — 3 SP
E8-05 — Page Overview (KPI cards : requêtes, PII, coût, modèle top) — 5 SP
E8-06 — Graphique volume requêtes (recharts line, 7j/30j, breakdown) — 5 SP
E8-07 — Page Politiques (liste règles, CRUD, activation/désactivation) — 8 SP
E8-08 — Page Utilisateurs (liste, attribution rôles, filtrage dept) — 5 SP
E8-09 — Page Sécurité RSSI (PII par type, requêtes bloquées, top users PII) — 8 SP
E8-10 — Page Coûts (breakdown modèle/dept, projection mensuelle, alerte) — 5 SP
E8-11 — Playground PII (highlight temps réel, choix modèle, envoi, réponse) — 8 SP [killer feature]
E8-12 — Page Logs Audit Trail (tableau paginé, filtres combinés, expand) — 8 SP
E8-13 — Alertes in-app (seuils configurables, notification dashboard) — 5 SP
E8-14 — Page Conformité (registre, classification AI Act, génération rapports) — 8 SP
E8-15 — Landing page + démo interactive — 5 SP
Epic 9 — Conformité RGPD & AI Act
E9-01 — Modèle données registre traitements (processing_registry) — 3 SP
E9-02 — Classification risque AI Act (enum + questionnaire guidé) — 5 SP
E9-03 — Génération rapport PDF Article 30 RGPD (go-pdf / WeasyPrint) — 8 SP
E9-04 — Génération rapport AI Act (fiche par système IA) — 5 SP
E9-05 — API droit d'accès Art. 15 (export données user_id) — 3 SP
E9-06 — API droit d'effacement Art. 17 (purge logs + mappings PII) — 5 SP
E9-07 — Template DPIA pré-rempli — 5 SP
E9-08 — Génération rapport incident (template avec chronologie) — 3 SP
E9-09 — Documentation DPA fournisseurs IA (OpenAI, Anthropic, etc.) — 3 SP
Epic 10 — Sécurité & Hardening
E10-01 — mTLS entre composants internes (cert-manager, Istio/Linkerd) — 8 SP
E10-02 — Network policies K8s (deny-all, whitelist explicite) — 5 SP
E10-03 — Intégration HashiCorp Vault (API keys, credentials, clés chiffrement) — 8 SP
E10-04 — SAST Semgrep en CI (Go + Python + React, bloque si critical) — 3 SP
E10-05 — Scan images Trivy en CI (bloque si CVE critique) — 2 SP
E10-06 — DAST OWASP ZAP automatisé sur staging — 5 SP
E10-07 — gitleaks en CI (détection secrets) — 2 SP
E10-08 — Rotation automatique API keys (90 jours, alertes) — 5 SP
E10-09 — Rate limiting par tenant/user (Kong ou middleware Go) — 5 SP
E10-10 — Tests de charge k6 (1000 req/s, 10 min, p99 < 300ms) — 8 SP
Epic 11 — Beta, Tests & Lancement
E11-01 — Tests E2E automatisés (20+ scénarios complets, < 10 min CI) — 13 SP [décomposer]
E11-02 — Documentation API OpenAPI 3.1 (swaggo, /docs, exemples) — 5 SP
E11-03 — Guide d'intégration dev (intégration en < 30 min) — 3 SP
E11-04 — Onboarding client pilote #1 (tenant, SSO, users, providers) — 5 SP
E11-05 — Onboarding client pilote #2 — 5 SP
E11-06 — Guide utilisateur admin (PDF/web, captures) — 5 SP
E11-07 — Feature flags par module (PII, routing, billing) — 3 SP
E11-08 — Collecte et tri feedback pilotes — 3 SP
E11-09 — Bug fixes critiques post-pilote — 8 SP [buffer]
E11-10 — Améliorations UX top-5 — 5 SP
E11-11 — Pentest externe grey box (périmètre + accès + suivi) — 5 SP [coordination]
E11-12 — Remédiation pentest Critical + High — 8 SP [buffer]
E11-13 — Migration clients pilotes vers production — 5 SP
E11-14 — Matériel commercial (one-pager, deck 10 slides, battle card) — 5 SP
3. Release Plan — Vision 6 mois
Jalons clés
S1 (01/03) ──► Bootstrapping : dev env + squelette
S4 (29/03) ──► MILESTONE 1 : Proxy + PII + Auth ← Démo interne/prospects
S8 (28/04) ──► MILESTONE 2 : Dashboard + Playground ← Démo externe complète
S10 (10/05) ──► MILESTONE 3 : Conformité + Sécurité ← Prêt pour audit
S11 (24/05) ──► MILESTONE 4 : Beta privée — 2 clients pilotes connectés
S12 (07/06) ──► MILESTONE 5 : Pentest démarré + feedback intégré
S13 (21/06) ──► MILESTONE 6 : Lancement Production ← Go/No-Go
Burn-up cumulatif cible
| Sprint | SP livrés cumul | % du backlog MVP |
|---|---|---|
| S1 | 38 | 7% |
| S2 | 78 | 14% |
| S3 | 124 | 22% |
| S4 | 170 | 30% |
| S5 | 218 | 38% |
| S6 | 265 | 47% |
| S7 | 315 | 56% |
| S8 | 365 | 65% |
| S9 | 410 | 73% |
| S10 | 458 | 82% |
| S11 | 498 | 89% |
| S12 | 533 | 95% |
| S13 | 563 | 100% |
4. Sprints Détaillés
PHASE 1 — Fondations (S1–S4)
Objectif de Phase : Un proxy fonctionnel, authentifié, qui anonymise les PII et supporte 4 fournisseurs IA. Démontrable via curl. Quality Gate : démo live < 300ms total.
Sprint 1 — Bootstrapping (Semaines 1–2)
Sprint Goal : "L'ensemble de l'équipe peut développer, tester et déployer de façon autonome. Le squelette applicatif compile et se déploie en staging en moins de 5 minutes."
Capacité : 38 SP (ramp-up, setup réseau/AWS imprévisible)
| ID | Story | Assigné | SP | Priorité |
|---|---|---|---|---|
| E1-01 | Monorepo GitLab + structure /cmd, /internal, /services/pii, /web, /deploy, /proto, /docs |
DevOps | 2 | BLOQUANT |
| E1-02 | Pipeline CI/CD : build Go + Python + React, lint (golangci-lint, black, eslint), tests unitaires, scan Trivy, gitleaks | DevOps | 8 | BLOQUANT |
| E1-03 | Docker Compose local : Go app + PostgreSQL 16 + ClickHouse + Redis 7 + Keycloak. docker-compose up < 60s |
DevOps | 5 | BLOQUANT |
| E1-04 | Cluster K8s staging AWS EKS eu-west-3, 3 nodes, ingress Traefik, HTTPS | DevOps | 8 | BLOQUANT |
| E2-01 | Scaffolding Go : main.go, chi router, middleware chain vide, graceful shutdown (SIGTERM), /healthz retourne 200 |
Lead Backend | 3 | BLOQUANT |
| E2-02 | Gestion config Viper : config.yaml + override env vars. Pas de valeur hardcodée | Lead Backend | 2 | IMPORTANT |
| E3-01 | Modèle de données PG v1 : tables tenants, users, api_keys + migrations golang-migrate |
Backend Sr | 3 | IMPORTANT |
| E3-02 | Setup Keycloak : realm, client OIDC, utilisateur test, retourne JWT valide | DevOps | 5 | IMPORTANT |
| E4-01 | Schemas gRPC : PiiRequest, PiiResponse, PiiEntity → stubs Go + Python générés |
Lead + Backend Sr | 2 | IMPORTANT |
| Spike | Investigation Terraform vs Pulumi pour infra-as-code (timebox 4h, sortie : ADR) | DevOps | — | IMPORTANT |
Total : 38 SP
Critères d'acceptance sprint :
docker-compose updémarre tout en < 60s, healthchecks OKkubectl get nodes→ 3 nodes Ready sur EKS eu-west-3- Pipeline CI vert sur commit vide, build < 8 min
GET /healthz→ 200. Graceful shutdown fonctionne en staging
Démo Sprint Review :
Montrer :
docker-compose up→ tous les services green →curl /healthz→ 200. Déclencher un commit → montrer le pipeline CI vert en < 8 min → voir le déploiement automatique en staging.
Risques S1 :
- Setup EKS + VPC + IAM peut prendre 3+ jours → Mitigation : utiliser le module Terraform
terraform-aws-eksversion stable. Si bloqué > 2 jours → passer en EKS via eksctl pour débloquer, IaC en parallèle. - Incompatibilités version ClickHouse/Keycloak en Docker Compose → Mitigation : épingler les versions (SHA256 des images).
Sprint 2 — Proxy Core + Auth JWT (Semaines 3–4)
Sprint Goal : "Un développeur peut envoyer un prompt via le proxy Veylant IA et recevoir la réponse d'OpenAI, avec streaming temps réel et authentification JWT. Démontrable avec curl."
Capacité : 40 SP
| ID | Story | Assigné | SP | Priorité |
|---|---|---|---|---|
| E2-03 | Proxy relay non-streaming : POST /v1/chat/completions → OpenAI → réponse. Même résultat qu'un appel direct. |
Lead Backend | 5 | BLOQUANT |
| E2-04 | Proxy relay streaming SSE : stream:true, flush chunk par chunk, pas de buffering. curl --no-buffer reçoit les chunks en temps réel. |
Lead Backend | 8 | BLOQUANT |
| E3-03 | Middleware Auth JWT : RS256, expiration, issuer Keycloak. Sans JWT → 401. JWT expiré → 401. JWT valide → forward + contexte injecté (user_id, tenant_id, roles). | Backend Sr | 5 | BLOQUANT |
| E2-05 | Middleware Request ID : UUID v7 par requête, propagation headers (X-Request-Id) et logs |
Lead Backend | 2 | IMPORTANT |
| E2-06 | Middleware error handling : erreurs typées JSON format OpenAI (type, message, code) |
Lead Backend | 3 | IMPORTANT |
| E2-08 | Connection pool HTTP : connexions persistantes vers providers, timeout configurable | Lead Backend | 3 | IMPORTANT |
| E2-11 | Tests unitaires proxy : 15+ tests, cas nominaux/erreurs OpenAI/timeouts/headers. Coverage > 80%. go test -race passe. |
Lead Backend | 5 | IMPORTANT |
| E3-10 | Tests intégration Auth : E2E avec Keycloak via testcontainers (obtenir token → appeler proxy → succès) | Backend Sr | 3 | IMPORTANT |
| E1-06 | Déploiement auto staging : merge to main → Helm upgrade auto. Rollback en 1 commande. | DevOps | 3 | IMPORTANT |
| E1-07 | Métriques Prometheus basiques : request_count, request_duration_seconds, request_errors_total visibles dans Grafana |
DevOps | 3 | SOUHAITABLE |
Total : 40 SP
Critères d'acceptance sprint :
curl -H "Authorization: Bearer <JWT>" -X POST /v1/chat/completions -d '{"model":"gpt-4o","messages":[...]}'→ réponse identique à OpenAI directcurl --no-buffer ... stream:true→ chunks reçus en temps réel (latence perçue identique à OpenAI direct)- Requête sans JWT → 401 en < 10ms
Démo Sprint Review :
Montrer en live : (1) Appel direct à OpenAI avec streaming. (2) Même appel via le proxy → même résultat, même latence perçue. (3) Appel sans JWT → 401. (4) Métriques Grafana montrant le request count.
Risques S2 :
- Le streaming SSE est le point technique le plus délicat du projet. En Go, le
http.Flusherdoit être appelé après chaque chunk. Si OpenAI change son format SSE → l'adapter est localisé dansE5-02. Prévoir 3-4 jours de debug. Si bloqué → implémenter le mode non-streaming parfait d'abord, streaming en S3 avec 1 SP de retard accepté.
Sprint 3 — Pipeline PII v1 (Semaines 5–6)
Sprint Goal : "Le proxy anonymise automatiquement les données personnelles avant tout envoi à un LLM externe. Le token IBAN d'un prompt n'atteint jamais OpenAI. Démontrable via les logs."
Capacité : 44 SP (équipe en rythme)
| ID | Story | Assigné | SP | Priorité |
|---|---|---|---|---|
| E4-02 | Scaffolding service PII Python : FastAPI, gRPC server, Dockerfile, pytest setup. Healthcheck gRPC répond. | Backend Sr | 3 | BLOQUANT |
| E4-03 | Couche 1 Regex : IBAN FR/EU, email, tél FR/intl, n° SS, CB (validation Luhn). Jeu de 100+ tests. Precision > 99%, Recall > 95%. | Backend Sr | 5 | BLOQUANT |
| E4-05 | Couche 2 NER : Presidio + spaCy fr_core_news_lg. Détection PER, LOC, ORG. F1-score > 0.90 sur corpus français. |
Backend Sr | 8 | BLOQUANT |
| E4-07 | Pipeline unifié : orchestration regex → NER, déduplication, scoring confiance. 5 types de PII détectés dans un prompt. Latence < 50ms / 500 tokens. | Backend Sr | 5 | BLOQUANT |
| E4-08 | Pseudonymisation : remplacement par [PII:TYPE:UUID], mapping Redis AES-256-GCM, TTL configurable. Prompt envoyé au LLM sans PII en clair. |
Backend Sr | 5 | BLOQUANT |
| E4-09 | Dé-pseudonymisation : réinjection valeurs originales dans réponse LLM avant renvoi à l'user | Backend Sr | 5 | BLOQUANT |
| E4-10 | Intégration gRPC Proxy ↔ PII : proxy Go appelle service Python via gRPC avant chaque forward. Flux complet fonctionne bout en bout. | Lead Backend | 5 | BLOQUANT |
| E4-11 | Benchmark latence : mesure p50/p95/p99 sur 1000 requêtes variées. p99 < 50ms / 500 tokens, < 100ms / 2000 tokens. | Backend Sr | 3 | IMPORTANT |
| E4-13 | Tests unitaires PII : 50+ cas, multilangue, edge cases (texte mixte FR/EN, données dans URL, dans JSON). Coverage > 85%. | Backend Sr | 5 | IMPORTANT |
Total : 44 SP
⚠️ Sprint le plus risqué techniquement du projet.
Critères d'acceptance sprint :
- Envoyer un prompt contenant [IBAN, email, nom, téléphone, adresse] → les 5 types sont pseudonymisés
- Le prompt reçu par OpenAI (visible dans les logs) ne contient aucune donnée en clair
- La réponse renvoyée à l'utilisateur contient les vraies valeurs (dé-pseudonymisées)
- p99 < 50ms mesuré avec le script benchmark sur 1000 requêtes
Démo Sprint Review :
Ouvrir le playground (mode minimal). Taper : "Bonjour, je suis Jean Dupont, mon IBAN est FR76 3000 6000 0112 3456 7890 189, contactez-moi au 06 12 34 56 78." → Montrer dans les logs : (1) prompt original côté proxy, (2) prompt pseudonymisé envoyé à OpenAI, (3) réponse dé-pseudonymisée côté utilisateur.
Risques S3 :
- Latence NER > 100ms → Actions immédiates : (a) vérifier que
fr_core_news_lgest préchargé en mémoire au démarrage (pas de cold start), (b) activer le mode regex-only via feature flag pour les requêtes basse sensibilité (E4-14 en S4). - Faux positifs élevés → Ajuster le seuil de confiance Presidio (0.85 par défaut, testable dès 0.75). Whitelist configurable par tenant.
Decision Point post-S3 : Si le p99 NER > 80ms, décision explicite du PO : (a) reporter NER en V1.1 → MVP en regex-only, (b) allouer 1 sprint de spike optimisation, (c) accepter la latence avec UX appropriée. Cette décision ne peut pas être repoussée au-delà de S4.
Sprint 4 — Multi-provider + RBAC (Semaines 7–8)
Sprint Goal : "Veylant IA route les requêtes vers 4 fournisseurs IA selon le rôle et le département de l'utilisateur. Un admin voit tout, un User ne peut accéder qu'à son modèle autorisé."
Capacité : 46 SP
| ID | Story | Assigné | SP | Priorité |
|---|---|---|---|---|
| E5-01 | Interface Adapter Go : trait/interface avec Send(), Stream(), Validate(), HealthCheck(). Tests génériques passent pour tous les adapters. |
Lead Backend | 3 | BLOQUANT |
| E5-02 | Adapter OpenAI : normalisation format requête/réponse, streaming SSE (déjà testé en S2, ici normalisation du schema interne) | Lead Backend | 3 | BLOQUANT |
| E5-03 | Adapter Anthropic : Messages API, system/user/assistant, streaming. Même test qu'OpenAI. | Lead Backend | 5 | BLOQUANT |
| E5-04 | Adapter Azure OpenAI : endpoint custom, API version, deployment ID | Lead Backend | 5 | IMPORTANT |
| E5-06 | Adapter Ollama/vLLM : API OpenAI-compatible, test avec Llama 3 local | Lead Backend | 5 | IMPORTANT |
| E5-05 | Adapter Mistral : chat/completions, mistral-small | Lead Backend | 3 | SOUHAITABLE |
| E3-04 | RBAC middleware : rôles Admin/Manager/User/Auditor. User sans permission → 403. Admin → accès total. Auditor → read-only. | Backend Sr | 5 | BLOQUANT |
| E3-05 | Intégration SAML 2.0 Keycloak : federation Azure AD test. User ajouté dans groupe Keycloak → rôle dans l'app. | DevOps | 8 | IMPORTANT |
| E3-07 | API tenant management : CRUD tenants. API keys stockées chiffrées (pas en clair en DB). | Backend Sr | 5 | IMPORTANT |
| E5-08 | Tests intégration multi-adapter : test automatisé même requête → chaque adapter, validation réponse. CI green pour OpenAI + Anthropic. | Lead Backend | 5 | IMPORTANT |
Total : 47 SP → accepté (vélocité légèrement au-dessus de la cible grâce au rythme S3)
✅ QUALITY GATE PHASE 1 — à valider en fin de S4 :
Démo live sans mockup : (1) envoyer un prompt avec 3 PII via curl, (2) montrer l'anonymisation, (3) le routage vers OpenAI vs Anthropic selon le rôle de l'utilisateur, (4) la réponse dé-pseudonymisée. Latence totale < 300ms. Proxy + PII + Auth + RBAC + Multi-provider fonctionnent ensemble.
PHASE 2 — Intelligence et Visibilité (S5–S8)
Objectif de Phase : Le produit est démontrable avec une UI complète. Routage intelligent, logs, dashboard, playground. Quality Gate : démo complète sans mockup, données réelles.
Sprint 5 — Moteur de Routage (Semaines 9–10)
Sprint Goal : "Les requêtes sont routées automatiquement selon des politiques configurées par l'admin. Un prompt contenant des données critiques va systématiquement vers le modèle on-prem sans intervention humaine."
Capacité : 46 SP
| ID | Story | Assigné | SP | Priorité |
|---|---|---|---|---|
| E6-01 | Modèle de données politiques : table routing_rules (conditions JSONB, action, priority, tenant_id, enabled). Migration. CRUD interne. |
Backend Sr | 3 | BLOQUANT |
| E6-02 | Moteur de règles : évaluation par priorité décroissante, conditions (user.department, user.role, request.sensitivity, request.use_case, request.token_estimate), catch-all. 10 règles évaluées < 1ms. | Lead Backend | 8 | BLOQUANT |
| E6-03 | Sensitivity scoring → routage : le score PII (niveau none/low/medium/high/critical) alimente le moteur de règles. Prompt critique → route vers modèle local. | Lead Backend | 3 | BLOQUANT |
| E6-04 | Fallback chain : si provider primaire fail → secondaire → global. Log de fallback généré. Test : mock provider en 500 → vérifier basculement. | Lead Backend | 5 | IMPORTANT |
| E6-05 | Cache des règles : cache mémoire, refresh 30s ou sur invalidation event. Modification visible < 30s sans restart. | Lead Backend | 3 | IMPORTANT |
| E6-06 | API admin politiques : CRUD /v1/admin/policies. Validation des conditions (pas d'opérateur invalide). |
Backend Sr | 5 | IMPORTANT |
| E4-14 | Mode regex-only : feature flag par tenant pour désactiver NER sur requêtes basse sensibilité. | Backend Sr | 3 | IMPORTANT |
| E6-07 | Tests moteur de règles : 30+ tests (combinaisons conditions, priorités, conflits, départements). 100% des cas documentés testés. | Lead Backend | 5 | IMPORTANT |
| E6-08 | Règles préconfigurées : templates RH, Finance, Engineering, catch-all. Activables en 1 clic. | Backend Sr | 3 | SOUHAITABLE |
| E3-09 | Feature flags système : table PG + cache Redis. Toggle via API admin, effet immédiat. | Backend Sr | 3 | SOUHAITABLE |
Total : 41 SP (sprint focus technique, volume réduit intentionnellement)
Sprint 6 — Journalisation + Billing (Semaines 11–12)
Sprint Goal : "Chaque requête passant par Veylant IA est immortalisée dans un log immuable avec 20 champs, chiffré, sans contenu personnel en clair. Le coût de chaque département est comptabilisé en temps réel."
Capacité : 48 SP
| ID | Story | Assigné | SP | Priorité |
|---|---|---|---|---|
| E7-01 | Schéma ClickHouse : table audit_logs (20 champs du PRD), partitionnement mensuel, TTL 90j hot. SELECT GROUP BY sur 100k lignes < 500ms. |
Backend Sr | 5 | BLOQUANT |
| E7-02 | Module Logger Go : collecte async des métadonnées, batch insert ClickHouse (toutes les 1s ou 100 logs). Aucun log perdu sous 1000 req/s. | Backend Sr | 8 | BLOQUANT |
| E7-03 | Hash SHA-256 : prompt et réponse hashés. Les logs ne contiennent aucun contenu en clair. Hash vérifiable. | Backend Sr | 2 | BLOQUANT |
| E7-04 | Chiffrement applicatif : prompt_anonymized chiffré AES-256-GCM, clé par tenant. Illisible en DB sans la clé. |
Backend Sr | 5 | IMPORTANT |
| E7-05 | Module Billing : tiktoken pour OpenAI, approximation token pour les autres. Agrégation user/dept/model. Comptage ±5% du comptage officiel. | Backend Sr | 5 | IMPORTANT |
| E7-06 | API consultation logs : GET /v1/admin/logs filtres (date, user, model, status, sensitivity_level), pagination. Requête filtrée < 2s sur 1M logs. |
Backend Sr | 5 | IMPORTANT |
| E7-07 | API coûts : GET /v1/admin/costs agrégation par période/model/dept |
Backend Sr | 3 | IMPORTANT |
| E7-09 | Audit de l'audit : table admin_audit_logs. Toute action admin (modif politique, accès log, modif RBAC) tracée avec timestamp, user, before/after. |
Backend Sr | 3 | IMPORTANT |
| E7-11 | Tests Logger : test sous 1000 req/s sans perte. Insert async non bloquant pour le proxy. | Backend Sr | 5 | IMPORTANT |
| E1-08 | OpenTelemetry + Jaeger : tracing distribué, chaque requête tracée de bout en bout (proxy → PII → LLM) | DevOps | 5 | SOUHAITABLE |
Total : 46 SP
Sprint 7 — Dashboard Frontend v1 (Semaines 13–14)
Sprint Goal : "Un RSSI peut se connecter au dashboard Veylant IA, visualiser le volume des requêtes, gérer les politiques de routage, et voir qui a accès à quoi. Aucun mockup — données réelles de staging."
Capacité : 50 SP
| ID | Story | Assigné | SP | Priorité |
|---|---|---|---|---|
| E8-01 | Setup React + TypeScript + Vite + TailwindCSS + shadcn/ui. Structure pages, react-router. Build < 30s. Zéro erreur TypeScript. | Frontend | 3 | BLOQUANT |
| E8-02 | Auth flow frontend : login OIDC PKCE via Keycloak, refresh automatique, logout, redirect. Session active après login. | Frontend | 5 | BLOQUANT |
| E8-03 | Layout général : sidebar navigation, header (tenant name, user, logout), responsive 1280px. Navigation fluide. | Frontend | 3 | BLOQUANT |
| E8-04 | Route guards : pages admin inaccessibles au rôle User. Auditor = read-only partout. | Frontend | 3 | BLOQUANT |
| E8-05 | Page Overview : 4 KPI cards (requêtes 24h/7j, PII détectées, coût total, modèle top). Données réelles. Refresh 30s. | Frontend | 5 | BLOQUANT |
| E8-06 | Graphique volume requêtes : recharts line chart, changement période 7j/30j, breakdown par modèle ou dept. Tooltip interactif. | Frontend | 5 | IMPORTANT |
| E8-07 | Page Politiques : liste des règles (priorité, condition, action, statut), création/édition formulaire, activation/désactivation toggle. CRUD complet. | Frontend | 8 | IMPORTANT |
| E8-08 | Page Utilisateurs : liste users (nom, rôle, dept, last_seen), attribution rôles par admin, filtrage. Changement rôle effectif immédiatement. | Frontend | 5 | IMPORTANT |
| E5-07 | Wizard configuration provider : formulaire 3 étapes (type, credentials, test connexion). Test de connexion intégré. | Frontend | 5 | IMPORTANT |
| E7-08 | API alertes budget : seuils configurables par tenant (tokens/h, coût/j, erreurs/h). Notification in-app si dépassement. | Backend Sr + Frontend | 5 | SOUHAITABLE |
Total : 47 SP
Sprint 8 — Dashboard Sécurité + Playground (Semaines 15–16)
Sprint Goal : "Le RSSI a sa vue sécurité complète. Un prospect peut taper un texte dans le playground et voir en temps réel ses données personnelles surlignées avant qu'elles n'atteignent l'IA. C'est la démo qui signe les contrats."
Capacité : 50 SP
| ID | Story | Assigné | SP | Priorité |
|---|---|---|---|---|
| E8-09 | Page Sécurité RSSI : PII par type (bar chart), requêtes bloquées (timeline), top users PII, incidents détectés. Filtrage par période. Export CSV. | Frontend | 8 | BLOQUANT |
| E8-10 | Page Coûts : pie chart par modèle, breakdown par dept, tendance mensuelle, projection fin de mois, alerte si > 80% budget. | Frontend | 5 | BLOQUANT |
| E8-11 | 🎯 Playground PII : zone de texte, highlight coloré temps réel (IBAN = rouge, nom = orange, etc.), choix modèle, bouton envoyer, affichage prompt anonymisé + réponse dé-pseudonymisée. | Frontend + Lead Backend | 8 | BLOQUANT |
| E8-12 | Page Logs Audit Trail : tableau paginé (50 logs/page), filtres combinés (date, user, model, status, sensitivity), expand pour détail. Pagination fluide sur 100k+ logs. | Frontend | 8 | IMPORTANT |
| E8-13 | Alertes in-app : configuration seuils par admin, notification dans le header (badge), détail dans la page alertes. | Frontend + Backend Sr | 5 | IMPORTANT |
| E2-09 | Circuit breaker : désactivation auto après 5 erreurs consécutives, réactivation après 60s. Visible dans le dashboard (statut provider). | Lead Backend | 5 | IMPORTANT |
| E2-10 | Health check providers : ping cyclique, statut visible dans le wizard provider et dans une page statut. | Lead Backend | 3 | SOUHAITABLE |
| E3-08 | API user management : CRUD complet /v1/admin/users. |
Backend Sr | 5 | SOUHAITABLE |
Total : 47 SP
✅ QUALITY GATE PHASE 2 — à valider en fin de S8 :
Démo complète en live (25 min max) : login → overview avec données réelles → playground (taper IBAN + nom → highlight → envoi → réponse) → page sécurité → logs → politiques (créer une règle RH). Zéro mockup, zéro données synthétiques.
PHASE 3 — Conformité et Hardening (S9–S10)
Objectif de Phase : Rapports RGPD et AI Act générables en 1 clic. Toutes les communications internes chiffrées. Aucun secret en clair. Prêt pour audit externe.
Sprint 9 — Module Conformité (Semaines 17–18)
Sprint Goal : "Un DPO peut générer le registre Article 30 RGPD de l'entreprise en PDF depuis Veylant IA, et consulter la classification AI Act de chaque cas d'usage IA. C'est ce qui déclenche la décision d'achat chez les clients réglementés."
Capacité : 48 SP
| ID | Story | Assigné | SP | Priorité |
|---|---|---|---|---|
| E9-01 | Modèle données registre traitements : table processing_registry (finalité, base légale, destinataires, durée, mesures sécurité, tenant_id). CRUD. |
Backend Sr | 3 | BLOQUANT |
| E9-02 | Classification risque AI Act : enum (forbidden/high_risk/limited_risk/minimal_risk) par cas d'usage, questionnaire guidé 5 questions. Stockée et exportable. | Backend Sr | 5 | BLOQUANT |
| E9-03 | Génération PDF Article 30 RGPD : tous les champs obligatoires, daté, signé, exportable. GET /v1/admin/compliance/report?format=pdf → PDF valide. |
Backend Sr | 8 | BLOQUANT |
| E9-04 | Rapport AI Act : fiche par système IA (modèle, classification, mesures, stats usage 30j). Export PDF. | Backend Sr | 5 | IMPORTANT |
| E9-05 | API Art. 15 (accès) : GET /v1/admin/gdpr/access/{user_id} → JSON avec tous les logs du user (anonymisés). |
Backend Sr | 3 | IMPORTANT |
| E9-06 | API Art. 17 (effacement) : DELETE /v1/admin/gdpr/erase/{user_id} → purge logs + mappings PII + log de la suppression. |
Backend Sr | 5 | IMPORTANT |
| E8-14 | Page Conformité frontend : registre des traitements (formulaire saisie), classification AI Act (questionnaire), boutons génération rapport. Téléchargement PDF en 1 clic. | Frontend | 8 | IMPORTANT |
| E9-07 | Template DPIA : template pré-rempli pour cas d'usage haut risque AI Act. Exportable Word/PDF. | Backend Sr | 5 | SOUHAITABLE |
| E7-10 | Export CSV logs : export filtré par date/dept/model. Téléchargement < 5s pour 30j de logs. | Backend Sr | 3 | SOUHAITABLE |
Total : 45 SP
Sprint 10 — Hardening Sécurité (Semaines 19–20)
Sprint Goal : "Veylant IA résiste à un audit de sécurité. Aucun secret n'est accessible en clair. Toutes les communications internes sont chiffrées. Le pipeline SAST/DAST ne remonte aucun finding critique."
Capacité : 48 SP
| ID | Story | Assigné | SP | Priorité |
|---|---|---|---|---|
| E10-01 | mTLS interne : cert-manager + Istio/Linkerd. Proxy ↔ PII, proxy ↔ DB, proxy ↔ ClickHouse. Wireshark → trafic chiffré uniquement. | DevOps | 8 | BLOQUANT |
| E10-02 | Network policies K8s : deny-all par défaut, whitelist explicite par service. curl depuis un pod aléatoire → échec. |
DevOps | 5 | BLOQUANT |
| E10-03 | HashiCorp Vault : API keys LLM, credentials DB, clés chiffrement. Accès via service account K8s. Zéro secret en env var ou ConfigMap. | DevOps | 8 | BLOQUANT |
| E10-04 | Semgrep SAST : rulesets Go + Python + React en CI. Bloque merge si finding critical. Zéro finding critical sur code actuel. | DevOps | 3 | IMPORTANT |
| E10-05 | Trivy scan images : bases images pinned (sha256). Bloque CI si CVE critique. | DevOps | 2 | IMPORTANT |
| E10-06 | OWASP ZAP DAST : scan automatisé sur staging à chaque déploiement. Rapport sans finding critique. | DevOps | 5 | IMPORTANT |
| E10-07 | gitleaks en CI : détection secrets dans les commits. | DevOps | 2 | IMPORTANT |
| E10-09 | Rate limiting : par tenant et par user. 429 si dépassement. Configurable par tenant via API admin. | Lead Backend | 5 | IMPORTANT |
| E10-10 | Tests de charge k6 : 1000 req/s pendant 10 min. p99 < 300ms. Zéro OOM, zéro goroutine leak, connexions DB stables. | DevOps + Lead Backend | 8 | IMPORTANT |
| E4-12 | Mode zero-retention : mapping PII en mémoire uniquement, TTL = durée de la requête. Feature flag par tenant. | Backend Sr | 3 | SOUHAITABLE |
Total : 49 SP
✅ QUALITY GATE PHASE 3 — à valider en fin de S10 :
(1) Zéro finding SAST/DAST critique. (2) mTLS actif et vérifié. (3) Vault intégré, zéro secret en clair. (4) Rapport RGPD PDF générable en 1 clic. (5) Test de charge passé (rapport k6 validé). Si un seul item manque : PAS de passage en Phase 4 sans décision explicite du PO + CTO.
PHASE 4 — Beta, Polish et Lancement (S11–S13)
Objectif de Phase : 2 clients pilotes connectés, pentest passé, lancement production. Quality Gate : checklist Go/No-Go complète à 100%.
Sprint 11 — Tests E2E + Beta Privée (Semaines 21–22)
Sprint Goal : "Deux clients pilotes utilisent Veylant IA en production staging. Les tests E2E automatisés couvrent tous les parcours critiques et s'exécutent en CI en moins de 10 minutes."
Capacité : 45 SP
| ID | Story | Assigné | SP | Priorité |
|---|---|---|---|---|
| E11-01a | Tests E2E batch 1 (10 scénarios) : login → config provider → envoi prompt avec PII → vérif anonymisation → vérif log → déconnexion | Tous | 8 | BLOQUANT |
| E11-01b | Tests E2E batch 2 (10 scénarios) : routage selon politique → fallback → dashboard données → génération rapport PDF → effacement RGPD | Tous | 8 | BLOQUANT |
| E11-02 | Documentation API OpenAPI 3.1 : swaggo auto-généré. /docs accessible. Tous endpoints documentés avec exemples de requêtes/réponses. |
Lead Backend | 5 | BLOQUANT |
| E11-03 | Guide d'intégration : comment changer l'URL de base d'une app existante vers Veylant IA. Suivi par un dev externe en < 30 min. | Lead Backend | 3 | BLOQUANT |
| E11-04 | Onboarding client pilote #1 : création tenant, configuration SSO (SAML/OIDC avec leur AD), import users, setup providers. Opérationnel < 1 journée. | PM + DevOps | 5 | BLOQUANT |
| E11-05 | Onboarding client pilote #2 | PM + DevOps | 5 | IMPORTANT |
| E11-06 | Guide utilisateur admin : documentation des fonctionnalités dashboard, relu par un non-technique, captures à jour. | PM | 5 | IMPORTANT |
| E11-07 | Feature flags par module : toggle PII on/off, routing on/off, billing on/off par tenant. Via API admin. Effet immédiat. | Lead Backend | 3 | IMPORTANT |
Total : 42 SP
⚠️ Action préalable (à lancer en S7 au plus tard) : Contacter le cabinet pentest, rédiger le cahier des charges, signer le bon de commande. Le pentest doit être planifié pour démarrer en S12.
Sprint 12 — Feedback Pilotes + Pentest (Semaines 23–24)
Sprint Goal : "Les bugs critiques remontés par les clients pilotes sont corrigés. Le pentest est en cours. Veylant IA est stable, performant, et les clients pilotes sont satisfaits (NPS > 7)."
Capacité : 40 SP (pentest prend du temps de coordination)
| ID | Story | Assigné | SP | Priorité |
|---|---|---|---|---|
| E11-08 | Collecte et tri feedback : sessions avec clients pilotes, backlog priorisé (bug / UX / feature), classement MoSCoW | PM | 3 | BLOQUANT |
| E11-09 | Bug fixes critiques (buffer) : selon feedback pilotes. Zéro bug bloquant restant. | Tous | 8 | BLOQUANT |
| E11-10 | Améliorations UX top-5 : les 5 points UX les plus remontés. Chacun validé par le pilote concerné. | Frontend | 5 | IMPORTANT |
| E11-11 | Pentest coordination : fourniture des accès (staging grey box), périmètre validé, suivi cabinet. | PM + DevOps | 3 | BLOQUANT |
| E2-12 | Tests de charge proxy : analyse des bottlenecks identifiés en production beta. p99 amélioré si problème. | Lead Backend | 5 | IMPORTANT |
| E1-09 | Blue/green deployment : déploiement sans downtime testé. Rollback < 30s démontré. | DevOps | 8 | IMPORTANT |
| E8-15 | Landing page + démo interactive : formulaire de contact fonctionnel, vidéo démo 3 min ou playground public. | PM + Frontend | 5 | IMPORTANT |
Total : 37 SP (intentionnellement bas : buffer pour bugs critiques imprévus)
Sprint 13 — Lancement Production (Semaines 25–26)
Sprint Goal : "Veylant IA est en production sur AWS eu-west-3. Les clients pilotes sont migrés. Le pentest est passé (zéro finding Critical/High). Le premier contrat entreprise peut être signé."
Capacité : 38 SP (remédiation pentest imprévisible)
| ID | Story | Assigné | SP | Priorité |
|---|---|---|---|---|
| E11-12 | Remédiation pentest : corriger TOUS Critical + High. Documenter acceptation des Medium avec justification. Rapport de remédiation produit. | Tous | 8 | BLOQUANT |
| E1-10 | Cluster K8s production : AWS eu-west-3, 3 AZ, autoscaling HPA, backup PG quotidien, réplication ClickHouse. DR testé (restauration < 1h). | DevOps | 8 | BLOQUANT |
| E1-11 | Monitoring production : Grafana dashboards (proxy latency, error rate, PII volume, DB connections), alertes PagerDuty/Slack. Alerte test reçue < 5 min. | DevOps | 5 | BLOQUANT |
| E11-13 | Migration clients pilotes vers production : données migrées, SSO reconfiguré sur prod, tests de bon fonctionnement. | PM + DevOps | 5 | BLOQUANT |
| E1-12 | Runbooks opérationnels : 5+ procédures (provider down, DB full, cert expiré, traffic spike, breach PII). Chacun testé en staging. | DevOps | 5 | IMPORTANT |
| E11-14 | Matériel commercial : one-pager PDF, deck 10 slides, battle card RSSI/DSI/DPO. Validé par 1 prospect. | PM | 5 | IMPORTANT |
| — | Rétrospective projet : retro documentée. Backlog V1.1 priorisé. | Tous | 2 | SOUHAITABLE |
Total : 38 SP
✅ QUALITY GATE PHASE 4 — Checklist Go/No-Go complète avant déploiement production. (Voir Section 8 de ce document)
5. Chemin Critique et Dépendances
5.1 Graphe de dépendances (tâches BLOQUANTES)
S1: Monorepo + Docker Compose + K8s staging
└──► S2: Proxy non-streaming + streaming SSE ⚡ (point le plus risqué)
└──► S3: PII Pipeline (regex + NER + gRPC) ⚡ (point le plus complexe)
└──► S4: Multi-provider + RBAC
└──► S5: Moteur de routage
└──► S6: Journalisation ClickHouse
└──► S7: Dashboard v1
└──► S8: Playground + Sécurité RSSI
└──► S9: Conformité PDF
└──► S10: mTLS + Vault + Hardening
└──► S11: Tests E2E + Beta
└──► S12: Pentest (commandé en S10)
└──► S13: Production
5.2 Actions à lancer en avance (hors sprints)
| Action | Démarrer | Nécessaire pour | Responsable |
|---|---|---|---|
| Identifier 5 prospects pilotes et signer LOI | S1 | S11 onboarding | PM |
| Négocier accès Azure AD test pour SAML | S2 | S4 Keycloak SAML | PM + DevOps |
| Signer DPA avec OpenAI, Anthropic, Mistral, Azure | S4 | S9 conformité | PM + Légal |
| Avis juridique architecture RGPD | S6-S7 | S9 rapports | PM + Légal |
| Rédiger cahier des charges pentest + contacter 3 cabinets | S7 | S12 pentest | PM + DevOps |
| Signer bon de commande pentest | S10 | S12 pentest | PM |
| Commander certificats SSL production + domaine | S10 | S13 production | DevOps |
| Créer compte AWS production + billing alerts | S8 | S13 production | DevOps |
| Rédiger CGV/CGU | S8 | S13 lancement | PM + Légal |
6. Registre des Risques Scrum
| # | Risque | Proba | Impact | Sprint détection | Mitigation | Contingence | Owner |
|---|---|---|---|---|---|---|---|
| R1 | Latence PII > 100ms | M | CRITIQUE | S3 (benchmark) | Cache patterns, préchargement spaCy, regex-only via feature flag | Reporter NER en V1.1, MVP en regex uniquement | Lead + Backend Sr |
| R2 | Streaming SSE + PII incompatibles | H | HAUT | S3 | PII sur le prompt AVANT envoi (pas sur la réponse streamée) | Bufferiser réponse complète + feature flag, impact latence perçue | Lead Backend |
| R3 | Départ développeur clé | M | CRITIQUE | Continu | Documentation ADR par module, cross-reviews (chacun connaît 2+ modules) | Consultant senior Malt/Toptal, retard 2-4 semaines accepté | CTO |
| R4 | Client pilote indisponible/non engagé | H | HAUT | S8 | Identifier 5 prospects dès S1, LOI signé dès S6 | Utiliser le produit en interne, démo sur données synthétiques | PM |
| R5 | ClickHouse trop complexe à opérer | M | MOYEN | S6 | Utiliser ClickHouse Cloud (managé) plutôt que self-hosted | Fallback TimescaleDB + PG pour le MVP (migration V1.1) | DevOps |
| R6 | Scope creep (features non planifiées) | H | MOYEN | Continu | PO dit NON explicitement à toute feature hors backlog validé | Créer ticket V1.1, pas de livraison S-sprint courant | PM |
| R7 | Findings pentest critiques nombreux | M | HAUT | S12-S13 | SAST/DAST dès S10, hardening proactif | Buffer 8 SP S13 alloué remédiation. Si > 3 Critical : report de 2 semaines | Tous |
| R8 | EKS setup > 3 jours | M | MOYEN | S1 | Module Terraform stable (terraform-aws-eks) | Passer en eksctl pour débloquer, IaC en parallèle S2 | DevOps |
| R9 | Format API provider LLM change | M | MOYEN | Continu | Adapter pattern : changements isolés dans 1 fichier/provider | Rollback adapter, alerte monitoring sur erreur format | Lead Backend |
| R10 | Difficultés recrutement Go/NLP | H | HAUT | Pré-S1 | Démarrer recrutement 4 semaines avant S1. Alternative : Malt/Toptal. | Consultants spécialisés pour module PII Python | PM + CTO |
7. Métriques et KPIs Scrum
7.1 Métriques suivies chaque sprint
| Métrique | Cible | Outil | Responsable |
|---|---|---|---|
| Vélocité livrée (SP Done) | Voir Release Plan | GitLab boards | Scrum Master |
| Stories Done / Stories engagées | 100% (idéal) | GitLab boards | Scrum Master |
| Coverage Go (unit tests) | > 75% | go test -cover en CI | Lead Backend |
| Coverage Python (PII service) | > 85% | pytest --cov en CI | Backend Sr |
| Latence proxy p99 (sans PII) | < 50ms | Prometheus histogram | DevOps |
| Latence proxy p99 (avec PII) | < 150ms | Prometheus histogram | DevOps |
| F1-score détection PII | > 0.92 | Benchmark corpus test | Backend Sr |
| Build time CI | < 8 min | GitLab CI metrics | DevOps |
| CVE critiques non patchées | 0 | Trivy + Snyk | DevOps |
| Findings SAST critiques | 0 | Semgrep | DevOps |
| Secrets en clair détectés | 0 | gitleaks en CI | DevOps |
| Uptime staging | > 99% | Prometheus uptime | DevOps |
7.2 Métriques business (suivies par PM)
| Métrique | Cible | Moment |
|---|---|---|
| Prospects identifiés | 5 | Fin S2 |
| LOI signés | 2 | Fin S6 |
| Clients pilotes connectés | 2 | Fin S11 |
| NPS clients pilotes | > 7 | Fin S12 |
| Bugs bloquants ouverts | 0 | Fin S12 |
| Premier contrat signé | 1 | Fin S13 |
7.3 Indicateurs d'alerte (impediments à escalader immédiatement)
- 1 story BLOQUANT non terminée à J8 du sprint → escalade immédiate
- Vélocité < 70% de la cible 2 sprints consécutifs → session de réajustement scope
- p99 PII > 80ms en staging → décision PO requis (régression scope ou optimisation)
- Finding SAST/DAST Critical non résolu en 48h → blocage du déploiement staging
8. Actions à Lancer Immédiatement
Avant le Sprint 1, les actions suivantes doivent être initiées maintenant :
Semaine -2 (dès aujourd'hui) :
- Confirmer la disponibilité des 4 développeurs (date de démarrage S1)
- Créer le compte AWS (eu-west-3), configurer l'organization, billing alerts
- Créer le compte GitLab (ou activer la licence Premium)
- Réserver le domaine (ex: veylant.ai, veylant.io)
- Identifier les 5 premiers prospects pilotes cibles → PM prend contact cette semaine
Semaine -1 (avant S1) :
- PM rédige les 10 premières User Stories du backlog (E1 + E2) → format DoR atteint
- CTO valide les choix techniques (Terraform vs Pulumi, Istio vs Linkerd) → ADR rédigés
- Setup des accès AWS pour le DevOps
- Sprint 0 (kick-off, 1 journée) :
- Team building + working agreement signé
- Definition of Done validée collectivement
- Sprint 1 planifié (stories prêtes, estimées, backlog S1 verrouillé)
- Outils configurés (GitLab, Slack, Jira/Linear, Notion)
Annexe — Checklist Go/No-Go Production (S13)
Chaque item doit être ✅ avant le déploiement production. Un ❌ = No-Go sauf décision explicite documentée.
| Catégorie | Item | Critère |
|---|---|---|
| Fonctionnel | Proxy relay 4 providers (OpenAI, Anthropic, Azure, Ollama) | Tests E2E green |
| Fonctionnel | Anonymisation 6 types PII (IBAN, email, tél, nom, adresse, SS) | Tests E2E green + F1 > 0.92 |
| Fonctionnel | Streaming SSE avec anonymisation du prompt | Démo live |
| Fonctionnel | Routage intelligent avec 5+ règles simultanées | Tests E2E green |
| Fonctionnel | Dashboard données réelles (pas de mock) | Vérification visuelle |
| Fonctionnel | Rapport RGPD Article 30 PDF générable | PDF téléchargeable et lisible |
| Sécurité | Pentest : 0 finding Critical, 0 finding High ouvert | Rapport pentest + lettre de remédiation |
| Sécurité | mTLS actif entre tous les composants | Wireshark capture staging |
| Sécurité | Vault intégré, 0 secret en clair | Audit Vault + gitleaks CI green |
| Sécurité | SAST/DAST : 0 finding critique | Rapports Semgrep + ZAP |
| Performance | Proxy p99 < 300ms sous 500 req/s | Rapport k6 |
| Performance | Dashboard load < 3s | Lighthouse score > 70 |
| Ops | Monitoring prod opérationnel (Grafana + alertes) | Alerte test reçue < 5 min |
| Ops | Backup PostgreSQL auto + test restauration | Restauration en < 1h testée |
| Ops | Blue/green deployment fonctionnel | Déploiement staging testé |
| Ops | 5+ runbooks rédigés et testés en staging | Revue par l'équipe |
| Commercial | 1 client pilote satisfait (NPS > 7) | Feedback documenté |
| Commercial | Landing page + matériel commercial prêt | Page live, formulaire contact OK |
| Légal | CGV/CGU rédigées et validées avocat | Document signé |
| Légal | DPA providers IA (OpenAI, Anthropic, Mistral, Azure) signés | Documents archivés |
Document maintenu par le Scrum Master — mis à jour à chaque Sprint Review. Prochaine révision : fin Sprint 2 (ajustement vélocité réelle vs cible).