6.3 KiB
Veylant IA — Rétrospective Projet V1.0
Sprint 13 / Milestone 6 — 21 Juin 2026 Participants : David (CTO), Marie (CS), [équipe] Format : Start / Stop / Continue + Backlog V1.1
1. Ce qui a bien fonctionné (Continue)
Architecture & Code
Proxy Go + PII Python — bon découplage La séparation Go proxy / Python PII sidecar s'est révélée judicieuse. Les deux services évoluent indépendamment (versions, déploiements, équipes). Le gRPC local < 2ms a respecté le budget latence dans tous les sprints.
Chi router + middleware chain La composabilité des middlewares (Auth → RequestID → RateLimit → CORS → SecurityHeaders → RBAC → Handler) a permis d'ajouter des fonctionnalités de sécurité sans toucher aux handlers métier. Exemple : CORS ajouté en Sprint 12 en un seul fichier.
ClickHouse pour les audit logs Le choix de ClickHouse pour les logs immuables a été validé par les clients. L'append-only garantit la non-répudiation et le TTL est une alternative propre au DELETE RGPD sur des données à durée de vie limitée.
CI/CD robuste dès Sprint 2 Le pipeline (golangci-lint + Trivy + Semgrep + gitleaks + ZAP) a détecté 3 issues de sécurité en amont avant qu'elles n'atteignent staging. Le coverage threshold Go 80% / Python 75% a forcé une discipline de test bénéfique.
Blue/green deployment
Zéro downtime sur tous les déploiements staging depuis Sprint 9. Le script blue-green.sh avec le smoke test post-switch a donné confiance pour le lancement production.
Product & Customer
Feedback pilotes précoce (Sprint 12) Les 2 sessions pilotes client ont été décisives. Les bugs critiques (CORS, Retry-After, 403 opaque) ont été découverts avant la production — pas après. La méthodologie feedback → backlog MoSCoW → sprint a bien fonctionné.
Playground public La décision de faire un playground sans auth (Sprint 12) a immédiatement libéré les démos pour Sophie (DPO). Impact NPS attendu fort.
Documentation structurée Les guides (integration, admin, onboarding) produits en Sprint 11 ont réduit le temps de setup des clients pilotes de ~2h à ~30 min.
2. Ce qui aurait pu être mieux (Stop / Improve)
Terraform en retard
Problème : L'infrastructure as code (Terraform EKS) aurait dû être créé en Sprint 8 avec la définition du cluster staging. Il a été reporté au Sprint 13 (dernier sprint !), créant une dépendance critique sur le lancement production.
Impact : Le provisioning EKS production est dans le chemin critique du Go/No-Go Sprint 13.
Leçon : Infrastructure as Code = Sprint 1. Pas négociable pour le prochain produit.
Matériel commercial produit trop tard
Problème : One-pager, pitch deck, et battle card ont été produits au Sprint 13 — le sprint de lancement. Ils auraient dû être prêts au Sprint 8-9 pour qualifier le pipeline commercial en parallèle du développement.
Impact : 3 ESN potentiels ont été approchés sans matériel formalisé. Conversion probablement plus faible.
Leçon : Aligner les sprints produit et les sprints commerciaux dès la Phase 3.
Test de charge trop tardif
Problème : Le premier test de charge réel (k6) a été fait en Sprint 12. Des problèmes de performance auraient pu être détectés plus tôt.
Impact : Aucun problème majeur détecté — mais on a eu de la chance.
Leçon : k6 smoke test dans le CI dès Sprint 5 (benchmark de base).
Runbooks pas co-écrits avec les opérations
Problème : Les 5 runbooks opérationnels ont été écrits par le CTO en Sprint 13. Idéalement, ils auraient été co-écrits avec une simulation en staging (chaos engineering).
Leçon : Chaque runbook devrait être validé par un exercice de simulation avant la production.
3. Améliorer pour la prochaine fois (Start)
- Chaos engineering dès Phase 3 :
kubectl delete pod+ vérification HPA, circuit breaker test mensuel - Infrastructure as Code en Sprint 1 : Terraform VPC + EKS skeleton même si vide
- Commercial track en parallèle : One-pager = Sprint 3, pitch deck = Sprint 6
- Post-mortem blameless : Systématiser après chaque incident staging
4. Backlog V1.1 — Priorisé
Must (Q3 2026)
| Item | Valeur | Effort | Source |
|---|---|---|---|
| Webhook Slack sur alerte rate limit | Réduit friction monitoring client | 3 SP | Client B feedback |
| Export CSV < 1s pour 10k lignes | NPS Client B | 3 SP | Client B feedback |
| Indicateur de progression export CSV | UX amélioration | 2 SP | Client B feedback |
| Amélioration vitesse Playground (CDN local) | NPS Client A | 2 SP | Client A feedback |
Should (Q3-Q4 2026)
| Item | Valeur | Effort | Source |
|---|---|---|---|
| SDK Python natif Veylant | Réduit friction intégration | 13 SP | Multiple clients |
| SIEM integration (Splunk/Datadog webhook) | Segment enterprise | 8 SP | Pipeline commercial |
| Champ sous-traitants UE/hors-UE dans registre RGPD | DPO feedback | 3 SP | Client B DPO |
| Header Accept-Language sur messages d'erreur | UX internationalisation | 2 SP | Client A |
Could (V2 — 2027)
| Item | Valeur | Effort | Source |
|---|---|---|---|
| ML anomaly detection (Shadow AI proactif) | Différenciateur fort | 21 SP | Roadmap |
| Isolation physique multi-tenant | Segment banque/défense | 34 SP | Pipeline enterprise |
| SIEM intégrations natives (Splunk, Elastic) | Segment RSSI enterprise | 13 SP | Pipeline commercial |
| LLM validation layer PII (Layer 3) | Précision PII +15% | 8 SP | Product roadmap |
5. Métriques du Projet V1
| Métrique | Valeur |
|---|---|
| Durée du projet | 13 sprints (6 mois) |
| Story points livrés | ~320 SP (38 SP/sprint moyen) |
| Fichiers de code | ~150 fichiers |
| Coverage Go (internal) | ≥ 80% |
| Coverage Python (PII) | ≥ 75% |
| Clients pilotes actifs | 2 (70 utilisateurs) |
| NPS pilote objectif | ≥ 8/10 (vs. 6-7 avant Sprint 12) |
| Findings pentest Critical/High | 0 ouvert |
| Temps de déploiement (blue/green) | < 5 minutes |
| Uptime SLO staging | 99.7% (mesure Sprint 12-13) |
Rétrospective rédigée le 21 juin 2026 — Veylant Engineering Prochain point : Sprint 14 Planning — lancement V1.1