Analyse & cadrage
Périmètre et priorisation
Décidez ce qui relève de la phase 1 et ce qui passe en phase 2 ou plus tard. MoSCoW avec une ambition réaliste pour livrer quelque chose au lieu de tout faire à moitié.
Mis à jour le 23 janv. 2026
Découverte · 3.7
Pourquoi en premier
La principale cause d’échec : vouloir trop en phase 1. La phase 1 doit être courte (8 à 12 semaines), fonctionner de façon démontrable et instaurer la confiance. Ensuite seulement vous passez en phase 2. Une discussion serrée du périmètre maintenant = quelque chose en production dans le trimestre au lieu d’un « pré-go-live sans fin ».
Que livrez-vous ?
Tableau MoSCoW
Must / Should / Could / Won't, rempli avec les éléments de la liste des points de douleur et des opportunités.
Feuille de route par phase
Phase 1, 2, 3, avec périmètre, objectifs et critères de succès par phase.
Vérification de capacité
Avons-nous les personnes pour le faire ? Qui, combien de jours, quand.
Parking
Ce que nous ne faisons pas en phase 1, avec une date et un responsable pour le réexamen.
Les 4 catégories MoSCoW
Must
Sans cela, la phase 1 a échoué
Environ 40 % du périmètre. Processus critiques, principaux points de douleur, questions de conformité.
Should
Important, non critique
Environ 30 % du périmètre. Fait si la capacité le permet. Pas bloquant en cas de report.
Could
Nice-to-have
Environ 20 % du périmètre. Gains rapides qui peaufinent le résultat. Premiers à sauter sous pression.
Won't
Délibérément exclu
Notez explicitement ce qui n'est pas dans la phase 1. Évite la dérive du périmètre en chemin.
Étapes
- 1Regroupez les entrées, principaux points de douleur (3.3), processus (3.2), catalogue de services (3.5), actions de benchmark (3.6).
- 2Atelier comité de pilotage, séance de 2 heures. Placez chaque élément sur le tableau MoSCoW. Vote ou consensus.
- 3Forcez 40/30/20/10, si tout est « Must », choisissez à nouveau. Discipline plutôt que complaisance.
- 4Vérification de capacité, pouvons-nous vraiment atteindre les éléments Must ? Combien de jours-personne, quand disponibles ?
- 5Définissez des critères de succès, par phase : qu'est-ce qui doit fonctionner de manière démontrable ? KPI concrets issus de 3.3.
- 6Documentez Won't explicitement, ne restez pas silencieux sur ce que vous ne faites pas, notez-le avec une date de réexamen.
- 7Validation du sponsor, le sponsor signe le périmètre. Modifications après ce point = demande de changement formelle.
Modèle, tableau MoSCoW
| Élément | Catégorie | Score (issu de 3.3) | Effort | Phase | Responsable |
|---|---|---|---|---|---|
| Portail de tickets en libre-service | Must | 20 | M | 1 | Responsable Facility |
| Add-in Outlook pour les réservations | Must | 15 | S | 1 | PM |
| Restauration automatique pour réunions > 90 min | Should | 12 | S | 2 | Restauration |
| Agent IA pour les tickets IT | Could | 9 | L | 2/3 | Responsable IT |
| App mobile pour responsables incendie | Won't | 6 | M | — | Réexamen T1 2027 |
Modèle, feuille de route par phase
Phase 1, 8 à 12 semaines
Fondations + principaux points de douleur
Données de référence + 1 à 2 modules. Résolution démontrable du top 3 des points de douleur.
Critère de succès : KPI de 3.3 améliorés dans les 3 mois suivant le go-live.
Phase 2, 2 à 3 mois plus tard
Élargir et approfondir
Éléments Should, modules supplémentaires, intégrations non critiques.
Critère de succès : taux d'adoption > 70 % parmi les utilisateurs finaux.
Phase 3, ensuite
Optimiser et IA
Éléments Could, agents IA, reporting avancé, parking réexaminé.
Critère de succès : gains de productivité mesurables, volumes de tickets en baisse.
Bonnes pratiques
→ Petites victoires
Une phase 1 qui fonctionne avec 5 fonctionnalités > une phase 1 bloquée avec 25 fonctionnalités.
→ Décidez sur effort + score
Score élevé + effort faible = gain rapide, à prendre. Score faible + effort élevé = parking.
→ Écrivez Won't explicitement
« Nous ne faisons pas X en phase 1 » évite les questions sans fin « et X ? ».
→ Repriorisez sous pression
Phase 1 qui dérape ? Coupez Could+Should, pas Must. N'allongez pas la phase.