86 lines
3.2 KiB
Markdown
86 lines
3.2 KiB
Markdown
# Roadmap officielle — 3 phases
|
|
|
|
Cette roadmap aligne les travaux backend + frontend avec l'état réel du projet.
|
|
|
|
## Cadre temporel (échelle relative)
|
|
|
|
- `duration+` = court
|
|
- `duration++` = moyen
|
|
- `duration+++` = long
|
|
|
|
## Owners nominaux par phase
|
|
|
|
| Phase | Durée relative | Owner nominal | Co-owners |
|
|
|---|---|---|---|
|
|
| Phase 1 — MVP fonctionnel | `duration++` | `@BE-Core` | `@FE-Lead`, `@PO` |
|
|
| Phase 2 — Hardening | `duration+` | `@DevOps` | `@Security`, `@BE-Platform`, `@QA` |
|
|
| Phase 3 — Différenciation | `duration+++` | `@PO` | `@BE-Integrations`, `@FE-Lead` |
|
|
|
|
## Phase 1 — MVP fonctionnel (priorité immédiate, `duration++`)
|
|
|
|
### Objectif
|
|
|
|
Rendre Ultimail utilisable de bout en bout avec un backend réel (plus de mock pour les parcours mail critiques).
|
|
|
|
### Livrables
|
|
|
|
- Corriger les blocants backend mail (ownership endpoints, bug outbox planifié, provisioning user OIDC).
|
|
- Finaliser pipeline IMAP/SMTP minimum viable (sync inbox, envoi immédiat, envoi planifié cohérent).
|
|
- Câbler rules + webhooks dans le flux de réception.
|
|
- Exposer endpoints manquants MVP (brouillons, pièces jointes, labels/dossiers de base).
|
|
- Brancher frontend mail sur API backend (lecture, actions, compose, recherche backend).
|
|
- Brancher multi-comptes réel côté frontend.
|
|
|
|
### Critères de sortie
|
|
|
|
- Parcours validés: connexion -> sync inbox -> lecture -> envoi immédiat -> planifié/replanifié/send-now.
|
|
- Règle simple + webhook exécutés réellement sur mail entrant.
|
|
- Frontend principal mail ne dépend plus des mocks pour ces parcours.
|
|
|
|
## Phase 2 — Hardening (production-ready, `duration+`)
|
|
|
|
### Objectif
|
|
|
|
Sécuriser, fiabiliser et observer la plateforme pour exploitation continue.
|
|
|
|
### Livrables
|
|
|
|
- Chiffrement credentials au repos, validation inputs stricte, RBAC admin.
|
|
- WS sécurisé par token (suppression `user_id` en query).
|
|
- Retries/backoff + DLQ pour outbox et webhooks.
|
|
- Observabilité complète (request-id, métriques, dashboards, alerting).
|
|
- Normalisation erreurs API + pagination cross endpoints.
|
|
- Couverture tests backend/CI (intégration handlers, workers, migrations) + tests e2e front parcours critiques.
|
|
|
|
### Critères de sortie
|
|
|
|
- SLO minimaux atteints en staging.
|
|
- CI bloque les regressions sur flux critiques.
|
|
- Aucun secret sensible en clair en base.
|
|
|
|
## Phase 3 — Différenciation (IA + automatisations avancées, `duration+++`)
|
|
|
|
### Objectif
|
|
|
|
Dépasser la parité Gmail/Google par les fonctions différenciantes Ulti Suite.
|
|
|
|
### Livrables
|
|
|
|
- Rules engine avancé (simulation, priorités, conflits, actions composables).
|
|
- Webhooks templates versionnés (preview, signature HMAC, retries et observabilité fine).
|
|
- Tri IA configurable par règle (provider, prompt, garde-fous coût/latence).
|
|
- Recherche globale multi-services (mail + contacts + agenda + drive).
|
|
- APIs fine-grained pour agents externes (tokens/scopes).
|
|
|
|
### Critères de sortie
|
|
|
|
- Un utilisateur peut configurer automatisations et IA sans code.
|
|
- Résultats traçables et monitorés en production.
|
|
- Recherche cross-services opérationnelle avec pertinence acceptable.
|
|
|
|
## Règle de priorisation
|
|
|
|
1. Corriger ce qui casse le produit (blocants/sécurité/cohérence).
|
|
2. Stabiliser le coeur Ultimail en réel.
|
|
3. Étendre puis différencier.
|