Cadrage Phases : P3 Compétences : C1
Liste d’exigences MoSCoW
Définition
La méthode MoSCoW est un outil de priorisation des exigences en quatre catégories : Must have (indispensable, bloquant), Should have (important, sans alternative équivalente), Could have (souhaitable, ajoute de la valeur), Won’t have (explicitement exclu du périmètre actuel). Cette catégorisation force la discipline d’arbitrage entre exigences et structure les négociations avec les parties prenantes.
Pour l’AIBS, MoSCoW constitue l’outil de référence pour la priorisation des exigences en phase P3. Elle alimente la compétence C1 (relever et formuler les besoins et les exigences) en transformant le catalogue de besoins en liste d’exigences priorisées exploitable en phase P4.
La règle d’or de la méthode est la proportion : maximum 60% de l’effort en Must, 20% en Should, 20% en Could. Cette discipline force la hiérarchisation et préserve la capacité du projet à absorber les imprévus. Sans cette discipline, le piège classique est le « tout Must » qui rend la priorisation inopérante.
Quand l’utiliser
À utiliser en phase P3 après constitution du catalogue de besoins. Atelier collégial de priorisation avec les parties prenantes principales et le sponsor. Durée typique : 2 à 4 heures selon le volume d’exigences.
Mode d’emploi pas-à-pas
- Catégorisation des exigences en quatre niveaux : Must have (indispensable), Should have (important), Could have (souhaitable), Won’t have (exclu)
- Règle de proportions recommandée : maximum 60% en Must, 20% en Should, 20% en Could
- Validation collégiale de la priorisation avec le sponsor et les parties prenantes principales
- Documentation des exigences Won’t have pour les futurs cycles de projet
- Traçabilité vers les besoins source
Exemple visuel
Catégorisation MoSCoW — proportions cibles
MUST HAVE — 60% max
Indispensable, sans cette exigence le projet n’a pas de sens
Exemples : Données patient anonymisées, Conformité LPD, Supervision humaine
SHOULD HAVE — 20%
Important, sans alternative équivalente, à inclure si possible
Exemples : Multilingue FR/DE/IT, Intégration au CRM existant
COULD HAVE — 20%
Souhaitable, ajoute de la valeur, sera fait si capacité
Exemples : Personnalisation interface, Mode hors ligne, Statistiques avancées
WON’T HAVE — 0% (explicite)
Explicitement exclu de ce cycle, pour traçabilité
Exemples : Reconnaissance vocale, Export vers systèmes tiers, Mode multi-tenant
Exemple concret rempli
Exemple appliqué — EMS jurassien
Un EMS de 120 résidents priorise les exigences d’un projet d’assistant numérique pour la documentation des soins. Le catalogue compte 38 exigences techniques et fonctionnelles.
L’atelier MoSCoW rassemble la directrice, l’infirmière-cheffe, le médecin référent, le responsable IT et l’AIBS sur 3 heures.
Catégorisation finale :
MUST HAVE (21 exigences, 55% du total) : - Conformité LPD complète, hébergement Suisse - Conservation de toutes les données pendant 10 ans (exigence légale santé) - Supervision médicale obligatoire pour toute proposition diagnostique - Intégration avec le dossier patient existant (logiciel métier en place) - Authentification forte des soignants - Traçabilité complète de toutes les modifications - Disponibilité 99,5% sur les heures critiques - Interface tactile adaptée au format tablette - Saisie vocale pour les soignants en mouvement - Vocabulaire métier soins infirmiers et médecine gériatrique - Support FR (langue principale) et DE (10% des résidents) - Sauvegarde automatique toutes les 30 secondes - Mode dégradé en cas de panne réseau - Formation incluse pour 35 soignants - Documentation utilisateur en français - Support technique pendant les heures ouvrées - Procédure de récupération en cas d’incident - Validation par le médecin pour les actes engageants - Notification automatique pour les seuils d’alerte - Reporting mensuel pour la direction - Audit annuel de conformité
SHOULD HAVE (8 exigences, 21% du total) : - Reconnaissance d’écriture manuscrite pour annotations rapides - Intégration avec le système de pharmacie - Application mobile pour les médecins en garde - Tableau de bord temps réel des indicateurs qualité - Export pour audits cantonaux - Synchronisation avec le calendrier institutionnel - Personnalisation par soignant (préférences interface) - Suggestions automatiques de codification
COULD HAVE (7 exigences, 18% du total) : - Reconnaissance d’images (escarres, plaies) - Suggestions de plans de soins basés sur l’historique - Mode présentation pour discussions multidisciplinaires - Statistiques comparatives avec autres EMS du réseau - Application famille pour information aux proches - Mode formation pour nouveaux collaborateurs - Personnalisation de la charte graphique
WON’T HAVE (2 exigences, 6% du total) : - Télémédecine (hors périmètre actuel, projet distinct) - Génération automatique de transmissions interétablissements (complexité réglementaire trop élevée pour ce cycle)
Total : 38 exigences, proportions respectées (60/20/20 environ).
Le tableau MoSCoW alimente directement la conception en phase P4 : les Must constituent le périmètre obligatoire, les Should orientent les choix techniques (architecture extensible), les Could alimentent la roadmap post-MVP.
Variantes
Priorisation numérique 1-5 pour les contextes nécessitant une granularité plus fine. Méthode Kano (basique, performance, attractif). Priorisation par valeur économique pondérée pour les contextes financiers stricts.
⚠ Piège classique
Sur-représentation des Must par défaut (« tout est indispensable »), qui rend la priorisation inopérante. La discipline impose : un projet typique compte 15 à 30 Must, pas 80. Si tous les besoins sont en Must, l’arbitrage n’a pas eu lieu et il faut recommencer.
Clé de succès : Limiter les Must — sinon plus rien n’est prioritaire.
Boussole AIBS — Manuel méthodologique non officiel pour le brevet fédéral d’AI Business Specialist.
Sources : Profil de qualification AIBS v15.04.2025 · Annexe directives FAAIB v1.01 · Document modules FAAIB v2.0 · Règlement examen v3.0 (mars 2026)