Plan de déploiement progressif
Génère un plan de déploiement structuré suivant le cadre Idira : inférer les signaux du PRD, classifier la voie, cartographier les anneaux, construire le plan de cohortes R3 et fournir les étapes de configuration de LaunchDarkly.
Étape 1 — Lire et déduire du PRD
Lisez l'intégralité du PRD. Déduisez chaque signal ci-dessous à partir du contenu. Ne demandez rien au chef de produit que vous pouvez déterminer par vous-même.
| Signal | Que chercher |
|---|---|
| NFI | Libellé "NFI", "nouvelle fonctionnalité", "non disponible auparavant", capacité entièrement nouvelle sans version antérieure |
| Impact | Périmètre des utilisateurs/locataires concernés, langage "chemin critique" / "flux de travail principal", sensibilité des données, risque de perte de données ou de perturbation du service |
| Complexité du rollback | Migrations de schéma, écritures de données, dépendances tierces, communications clients requises, état irréversible → Coordonné ou Irréversible. Simple bascule de drapeau → Facile. Si non mentionné → doit demander |
| Contraintes régionales | RGPD, FedRAMP, résidence des données, exigences géographiques spécifiques, "en commençant par [région]", "[région] uniquement", "[région] d'abord", "limité à [région]" |
| Contraintes de service | Services, intégrations ou composants nommés dont dépend ou que modifie la fonctionnalité |
| Disponibilité pour les testeurs précoces | "prêt pour la QA", dates d'achèvement de sprint, dates alpha/bêta — quand la fonctionnalité est suffisamment stable pour une première exposition externe |
| GA cible | Date de lancement engagée, échéance OKR, jalon de publication |
Après lecture, présentez vos déductions — ne posez pas de questions ouvertes. Pour tout signal non trouvé dans le PRD, marquez-le comme ❓ et posez une question ciblée à la fin :
Sur la base du PRD, voici comment j'ai interprété cette version :
- NFI : [Oui / Non — raison] ou ❓ Pas clair dans le PRD
- Impact : [Élevé / Moyen / Faible — raison] ou ❓ Pas clair dans le PRD
- Rollback : [Facile / Coordonné / Irréversible — raison] ou ❓ Non mentionné
- Contraintes régionales :[Aucune / liste — raison] ou ❓ Non mentionné
- Contraintes de service :[Aucune / liste — raison] ou ❓ Non mentionné
- Prêt pour les testeurs précoces : [date — raison] ou ❓ Non trouvé dans le PRD
- GA cible : [date — raison] ou ❓ Non trouvé dans le PRD
Puis posez uniquement les questions ❓, en utilisant ces formulations exactes :
- Rollback non mentionné → "Un plan de rollback est-il en place ? Options : (1) Facile — simple bascule de drapeau, restauration instantanée. (2) Coordonné — nécessite migration de données, script ou communications clients. (3) Pas encore défini — la stratégie de rollback reste à concevoir."
- Impact pas clair → "Comment décririez-vous l'impact client en cas de problème ? Élevé (affecte les flux de travail principaux ou de nombreux locataires), Moyen (limité à un service ou sous-ensemble spécifique) ou Faible (cosmétique / facilement réversible) ?"
- Disponibilité pour testeurs précoces non trouvée → "Quand la fonctionnalité sera-t-elle prête pour que les testeurs précoces commencent à valider ?"
- GA cible non trouvée → "Quelle est la date ou la période cible de la GA ?"
- Région non mentionnée → "Y a-t-il des contraintes régionales ? Par exemple, commencer par une région spécifique (EMEA, US, APAC) avant de s'étendre mondialement ?"
Ne supposez aucune valeur. Ne posez pas de questions sur les signaux que vous avez déjà résolus à partir du PRD.
Étape 2 — Classifier la voie de publication
NFI = Oui → HAUTE-TOUCHE
OU Impact = Élevé
OU Rollback = Irréversible
Impact = Moyen → STANDARD
OU Rollback = Coordonné
Tous les autres → LÉGER
Étape 3 — Cartographier les anneaux requis
| Voie | Anneaux obligatoires | R&D possède | PM possède |
|---|---|---|---|
| LÉGER | R0 → R4 | R0 | R4 |
| STANDARD | R0 → R3 → R4 | R0 | R3, R4 |
| HAUTE-TOUCHE | R0 → R1 → R2 → R3 → R4 | R0, R1 | R2, R3, R4 |
- R0 QA interne — environnements d'ingénierie/QA
- R1 Client zéro / Dogfooding — équipes internes
- R2 Client Un — clients Early Access sélectionnés (via processus NFI)
- R3 Canari de production — Locataires de test → cohortes en direct via les drapeaux LaunchDarkly
- R4 Disponibilité générale — tous les locataires de production éligibles
Étape 4 — Construire le plan de cohortes R3 (Standard et Haute-Touche uniquement)
R3 commence toujours par les Locataires de test en premier. Ensuite, séquencez les locataires en direct par ARR :
| Vague | % cumulé | Ciblage |
|---|---|---|
| 0 | — | Locataires de test (sandboxes achetés par les clients) |
| 1 | 5 % | ARR le plus bas, petit nombre de locataires |
| 2 | 15 % | ARR faible à moyen |
| 3 | 35 % | ARR moyen |
| 4 | 65 % | ARR moyen à élevé |
| 5 | 100 % | Tous les locataires éligibles restants |
Ajustements :
- Contraintes de service → ajouter un ciblage par filtre de service par vague
- Contraintes régionales → ajouter un filtre régional aux premières vagues, supprimer pour les vagues 4-5
- Calendrier court → fusionner les vagues (par exemple 5 % → 35 % → 100 %)
- Sensibilité ARR élevée → conserver les locataires à ARR élevé pour la vague 4 avec un temps de cuisson prolongé
Pour chaque vague, incluez : %, description de la cohorte, porte go/no-go (métrique + temps de cuisson), propriétaire. Les portes go/no-go sont obligatoires — ne les omettez jamais. Si le PRD définit des métriques de succès, utilisez-les. Sinon, appliquez les valeurs par défaut : taux de succès de la signature/fonctionnalité ≥99,5 %, delta du taux d'erreur <0,1 %, régression de latence p99 <5 %, pic de tickets de support <3 pour 1 000 locataires, temps de cuisson minimum de 48 h pour les premières vagues et d'1 semaine pour les vagues à ARR élevé.
Étape 5 — Générer le plan de publication complet
Produisez le plan en utilisant ce modèle :
# Plan de déploiement progressif — [Nom de la fonctionnalité]
**Voie de publication :** [LÉGER / STANDARD / HAUTE-TOUCHE]
**Début au plus tôt :** [date] | **GA cible :** [date]
---
## Comment j'ai interprété cette version
| Signal | Valeur | Raisonnement |
|--------|--------|--------------|
| NFI | Oui/Non | [une ligne] |
| Impact | Élevé/Moyen/Faible | [une ligne] |
| Rollback | Facile/Coordonné/Irréversible | [une ligne] |
| Contraintes régionales | Aucune / [liste] | [une ligne] |
| Contraintes de service | Aucune / [liste] | [une ligne] |
---
## Anneaux requis
| Anneau | Étape | Propriétaire | Porte d'entrée | Porte de sortie |
|--------|-------|--------------|----------------|-----------------|
| R0 | QA interne | R&D | Fusion dans main | Validation QA |
| R1 | Dogfooding | R&D | R0 terminé | Validation interne *(Haute-Touche uniquement)* |
| R2 | Client Un | PM | Processus NFI terminé | Retour client examiné *(Haute-Touche uniquement)* |
| R3 | Canari de production | PM | R2 terminé | Vague 100 % stable |
| R4 | Disponibilité générale | PM | Vague R3 100 % terminée | Décision PM go/no-go |
*(Inclure uniquement les anneaux requis pour la voie choisie)*
---
## Plan de cohortes R3
**D'abord :** Locataires de test — confirmer une activation sécurisée avant tout locataire en direct.
| Vague | % | Qui | Ciblage | Porte Go/No-Go |
|-------|---|-----|---------|----------------|
| 0 | — | Locataires de test | Locataires de test externes | Aucun incident pendant 48 h |
| 1 | 5 % | ARR faible | [critères] | [métrique] stable pendant [temps de cuisson] |
| 2 | 15 % | ARR faible-moyen | [critères] | [métrique] stable pendant [temps de cuisson] |
| 3 | 35 % | ARR moyen | [critères] | [métrique] stable pendant [temps de cuisson] |
| 4 | 65 % | ARR moyen-élevé | [critères] | [métrique] stable pendant [temps de cuisson] — prolongé |
| 5 | 100 % | Tous éligibles | Supprimer les filtres | [métrique] stable pendant [temps de cuisson] |
---
## Configuration LaunchDarkly
**1. Créer le drapeau de fonctionnalité**
- Clé de drapeau : `[nom-fonctionnalité]-deploiement` (minuscules, traits d'union)
- Type : Booléen
- Par défaut (désactivé) : false pour tous les environnements
**2. Configurer les environnements**
- `internal-qa` → R0 : activer pour l'équipe QA R&D
- `dogfooding` → R1 : activer pour les locataires employés internes *(Haute-Touche uniquement)*
- `early-access` → R2 : activer pour les locataires Client Un nommés *(Haute-Touche uniquement)*
- `production` → R3 : règles de ciblage ci-dessous
**3. Règles de ciblage de production (vagues R3)**
Vague 0 — Locataires de test :
- Règle : `tenant_type = "test"` → servir vrai
Vague 1 — 5 % :
- Règle : `tenant_type = "live" AND arr_tier = "low"` → servir vrai pour 5 % de déploiement
Vague 2 à 5 : Incrémenter le pourcentage de déploiement et élargir le filtre `arr_tier` par vague.
Supprimer entièrement le filtre `arr_tier` à la vague 5 (100 %).
Si des contraintes de service s'appliquent :
- Ajouter `AND deployed_services CONTAINS "[nom-service]"` à chaque règle.
Si des contraintes régionales s'appliquent :
- Ajouter `AND region IN ["[région]"]` aux premières vagues ; supprimer pour les vagues 4-5.
**4. Portes entre les vagues**
- Surveiller le taux d'erreur, la latence (p99) et les tickets de support pendant la période de cuisson.
- N'étendre à la vague suivante qu'après avoir satisfait aux critères go/no-go.
- Pour suspendre ou annuler : définir le drapeau de production sur false — tous les locataires reviennent immédiatement.
**5. Bascule unique**
- R&D doit implémenter une clé de drapeau unique dans tous les composants concernés.
- Confirmer avec R&D que tous les composants lisent le même drapeau avant le début de R3.
---
## Propriétaires et responsabilités
- **R&D** — Implémente le drapeau, possède R0–R1, valide la couverture de bascule unique
- **PM** — Possède l'exposition client (R2–R4), signe chaque porte de vague, met à jour le plan de cohortes
- **Product Ops** — Examine le plan par rapport aux directives obligatoires avant le début de R3
## Questions ouvertes / Hypothèses
- [Liste des faits supposés ou encore à confirmer avec R&D / BI]
Exemple
Voir reference.md pour un exemple concret (NFI, Impact élevé, GA cible à 3 mois) montrant un plan complet avec un tableau de cohortes rempli et des règles LaunchDarkly.