Bilan de la mise à jour 02. Date du rapport: 17-08-2026
La priorité a changé.
Le système s’est adapté.
iaci.tech peut désormais publier des travaux repriorisés en dehors de la séquence de sprints planifiée, sans réécrire la feuille de route. [IW-302]
- Séquence préservée.
- Décision documentée.
- Historique fidèle à la réalité.
83SP
Livré
Sprint 18 / IW-302 · sur 4 jours
23
Cas de régression
Collection Postman réutilisable, UAT & PROD
16
Défauts détectés et corrigés
14 sur 16 détectés avant la production
2
Parcours de publication
Séquentiel + Priorisé, maintenus séparés
Feuille de route planifiée (séquentielle)
▲ Priorité modifiée — S17 repriorisé et livré en avance
Livraison réelle
En cours
À venir
À venir
✓ Priorisé · Terminé
✓ Priorisé · Terminé
★ LA VALEUR
- La séquence planifiée est préservée.
- La priorisation est visible.
- Les décisions sont documentées.
- 2e livraison hors séquence dans l’historique du programme — désormais une capacité prise en charge, et non plus un contournement répété.
Deux réalités. Un historique des livraisons fiable.
DU CONTOURNEMENT À LA CAPACITÉ
Capacité ajoutée
| Avant IW-302 | Avec IW-302 |
|---|---|
| La publication supposait une livraison séquentielle. | Livraisons séquentielle et priorisée prises en charge |
| La repriorisation n’existait que dans Jira / le backlog. | Repriorisation visible dans l’historique du produit |
| La publication hors séquence nécessitait une intervention manuelle. | Parcours de publication ad hoc dédié |
| Modifier l’ordre de livraison risquait de brouiller la progression planifiée. | Séquence planifiée préservée |
| Régression API largement manuelle / spécifique à la fonctionnalité. | Capacité de régression Postman réutilisable |
Deux parcours. Un historique des livraisons fiable.
Modèle opérationnel
Parcours séquentiel.
- Progression planifiée
- Avancement du cycle de vie
- Integrité de la feuille de route préservée
Parcours priorisé
- Priorité modifiée
- Séquence préservée
- Décision documentée
Décision d’architecture
Pourquoi ne pas modifier l’API existante ?
Considéré : modifier l’API séquentielle
- Ajoute des cas d’exception à un parcours établi en production
- Augmente le risque de régression sur une capacité existante
- Fusionne deux responsabilités distinctes dans un même workflow
Choisi : parcours ad hoc distinct
- Isole la repriorisation de la progression séquentielle
- Préserve intact le comportement établi de l’API séquentielle
- Maintient clairement la responsabilité de chaque workflow
Des tests qui ont changé le résultat
Preuves de qualité
🛡
Répartition par sévérité (16 défauts)
La décision fait désormais partie des preuves
Preuves de Product Management
S14→S15→S16→S17→S18
Feuille de route initiale
S17 repriorisé pour être livré en avance
Pourquoi : valeur et impact produit
S17 ▲ ✓ Priorisé · Terminé
Visible dans l’historique des livraisons
Affinés au fil des tests : mise à jour de l’API Spec à mesure que les défauts étaient détectés ; Test Strategy exécutée sur cette base
Limites connues
- Les sprints priorisés ne changent pas encore automatiquement de statut (À venir/En couts → Terminé) — le statut est actuellement défini manuellement.
- Vérification formelle de l’accessibilité des éléments visuels de ce rapport — pas encore effectuée.
Leçons
Et ensuite — deux parcours, une seule feuille de route
Séquence planifiée : Sprint 14 — L’IA comme système, outil et accélérateur d’apprentissage.
Pipeline priorisé : Dictionnaire du Product Management, Framework de Product Management.
L’un ou l’autre parcours peut avancer lorsque la valeur produit le justifie — sans réécrire la feuille de route pour donner à l’historique une apparence linéaire.