La matrice MoSCoW : Comment nous livrons vos projets dans les temps (même quand tout change en cours de route)

Livrer un projet digital dans les délais sans sacrifier la qualité relève souvent du casse-tête. Trop de fonctionnalités, un budget figé, des délais serrés : la plupart des équipes s’épuisent à vouloir tout faire en même temps. Chez Agerix, nous avons trouvé la méthode qui transforme ce chaos en stratégie claire : la matrice MoSCoW. Cet outil de priorisation simple et redoutablement efficace nous permet de livrer des applications métier complexes dans les temps, même quand le périmètre évolue en cours de route.

Concrètement, MoSCoW oblige à distinguer l’essentiel du secondaire. C’est ce qui a permis à Travel-Safe de lancer son application malgré trois changements majeurs et l’arrivée du COVID, à EuropeanCancer de sauver son projet à deux semaines de la livraison, ou encore à Julie Pujols de générer des revenus dès le premier jour de sa V1. En priorisant ce qui compte vraiment, nous évitons les dérives budgétaires et assurons un retour sur investissement rapide.

Dans cet article, je vous montre comment nous utilisons MoSCoW au quotidien : pas la théorie académique, mais la pratique terrain qui nous a permis de livrer plus de 150 projets sans jamais perdre de vue l’essentiel.

Pourquoi tout ne peut pas être “priorité 1” (et comment MoSCoW règle ce problème)

Avant de vous expliquer comment nous utilisons MoSCoW chez Agerix, laissez-moi vous raconter ce qui se passe sans elle.

L’année dernière, un prospect est venu nous voir après avoir cramé 60% de son budget avec un autre prestataire. Son erreur ? Avoir validé un cahier des charges où chaque ligne commençait par “Critique” ou “Indispensable”. Résultat : l’équipe de développement s’est dispersée, a commencé 15 chantiers en parallèle, et au bout de 6 mois, rien n’était vraiment fonctionnel. Ils avaient 30% de tout au lieu de 100% de l’essentiel.

C’est exactement ce que MoSCoW empêche. Développée en 1994 par Dai Clegg chez Oracle UK, cette matrice force une conversation que personne n’a envie d’avoir mais que tout le monde doit avoir : “Si on ne peut pas tout faire, qu’est-ce qu’on fait en premier ?”

Les quatre catégories MoSCoW : traduction terrain

Oubliez les définitions académiques. Voici comment j’explique MoSCoW à mes clients lors de notre premier atelier de cadrage :

M - Must Have (Les fondations de votre maison)

"Sans ça, autant ne pas lancer le projet."

Quand nous avons développé le système de Julie Pujols, les Must Have étaient cristallins :

• Le système de paiement par abonnement (sans ça, pas de revenus)
• La protection des vidéos premium (son contenu, c’est son business)
• L’espace membre sécurisé (ses 15 000 abonnées doivent pouvoir se connecter)

Mon test infaillible : “Si cette fonctionnalité n’est pas là le jour J, est-ce que vous reportez le lancement ?” Si la réponse est oui, c’est un Must Have.

Pour l’Académie du 13ème, pouvoir inscrire un élève et l’affecter à un cours était Must Have. Le module de génération automatique des attestations ? Certainement pas - ils pouvaient continuer sur Word deux mois de plus.

S - Should Have (Les murs et le toit)

"Ça va faire mal si on ne l'a pas, mais on survivra."

Ce sont les fonctionnalités où vos équipes vont grogner, peut-être faire des heures sup’ pour compenser manuellement, mais le business continue de tourner.

Exemple concret : Pour European Cancer, l’affichage temps réel des données était Must Have pour la démo à Bruxelles. Mais le module d’export PDF personnalisé ? Should Have. Ils pouvaient faire des captures d’écran pour leurs rapports pendant quelques semaines, même si ce n’était pas idéal.

C - Could Have (La déco et le jardin)

"Ce serait vraiment chouette, mais franchement..."

C’est là que je sors souvent mon exemple préféré : Travel-Safe voulait absolument un chatbot IA pour répondre aux questions basiques des clients. Sympathique, moderne, vendeur… mais leurs 3 commerciaux géraient très bien les 20 demandes quotidiennes par email.

Les Could Have, c’est notre marge de manœuvre. Quand un Must Have s’avère plus complexe que prévu (et croyez-moi, ça arrive souvent 😉), c’est dans cette catégorie qu’on pioche pour récupérer du temps.

W - Won’t Have (Pas cette fois, désolé)

"On en reparle en V2."

J’insiste toujours pour remplir cette catégorie dès le début. Pourquoi ? Parce que ça évite les conversations gênantes trois semaines avant la livraison. “Ah mais je pensais qu’on aurait aussi…” Non. C’était marqué Won’t Have, on l’a validé ensemble.

Pour Julie Pujols, l’application mobile native était dans les Won’t Have. Elle la voulait, on la voulait, mais avec le budget et le délai, c’était elle ou le reste. Aujourd’hui, elle fait partie de la V3 en cours de développement.

Pilotez vos projets digitaux avec MoSCoW : une méthode de priorisation qui sécurise délais, budget et ROI stratégique.

Comment nous appliquons MoSCoW sur le terrain (et pourquoi ça marche)

L’atelier de lancement : 2 heures qui sauvent 6 mois

Quand un client signe avec Agerix, mon premier réflexe n’est pas d’ouvrir un Gantt ou de parler technologie. C’est de bloquer 2 heures dans leur agenda pour ce que j’appelle “l’atelier MoSCoW”.

Je me souviens de la tête du directeur d’une grosse société pour laquelle nous faisions notre premier développement quand je lui ai dit : “On va avoir besoin de vous, du responsable formation, du comptable et de deux utilisateurs terrain.” Sa réaction : “Betty, on n’a pas le temps pour des réunions, il faut qu’on avance !”

Ces 2 heures nous ont fait gagner 3 mois. Pourquoi ? Parce que le comptable a expliqué en direct au directeur que la génération automatique des factures était plus importante que le tableau de bord temps réel qu’il voulait absolument. Sans cette conversation, on aurait découvert ce besoin critique en phase de recette.

Mon processus en 5 étapes (celui qui a fait ses preuves sur 50+ projets)

1. La liste sans filtre (30 minutes)

Je demande à tout le monde de vider son sac. Post-it, tableau blanc, peu importe. Pour l’Académie du 13ème, on est partis de 82 “besoins”. Du système de réservation de salles à la sonnerie automatique en passant par l’envoi de SMS aux parents. Tout y passe, sans jugement.

Mon truc : je note qui demande quoi. Ça aide pour la suite.

2. Le premier tri brutal (20 minutes)

C’est là que je sors ma question préférée : “Le projet est livré demain. Vous ne pouvez garder que 10 fonctionnalités. Lesquelles ?”

Effet garanti. Soudain, le logo animé en page d’accueil devient beaucoup moins indispensable que la gestion des absences des professeurs. 😎

3. Le test de réalité (45 minutes)

Pour chaque élément de leur top 10, on applique le “test de l’annulation” :

• “Sans cette fonctionnalité, vous annulez le lancement ?” → Must Have
• “Sans cette fonctionnalité, quelqu’un fait des heures sup’ ?” → Should Have
• “Sans cette fonctionnalité, quelqu’un râle mais la vie continue ?” → Could Have

European Cancer était catégorique : sans l’affichage temps réel des données, ils annulaient la présentation à Bruxelles. Must Have validé. Par contre, le mode sombre pour l’interface ? Le CTO a admis en riant que c’était plus pour faire moderne…

4. La négociation budgétaire (15 minutes)

C’est mon moment préféré. Je sors mon tableau Excel (oui, je sais, très glamour 😆) avec les estimations en face de chaque catégorie :

• Must Have : 60% du budget
• Should Have : 20% du budget
• Could Have : 20% du budget

"Attendez Betty, nos Must Have représentent 95% du budget !"

Exactement. C’est pour ça qu’on va reprendre la liste et être honnêtes sur ce qui est vraiment “Must”.

5. La contractualisation (10 minutes)

On termine toujours par écrire noir sur blanc ce qui est dans chaque catégorie. Pas de “on verra”, pas de “si on a le temps”. Chaque fonctionnalité a sa place, et on signe.

Pour Julie Pujols, ça nous a sauvés quand, à J-20, l’idée d’un système de gamification a été émise. J’ai sorti le document MoSCoW signé : “C’est une super idée pour la V2, mais là on reste sur le plan.”

Quand tout change en cours de route (spoiler : ça arrive toujours)

Il y a 6 mois, autre client. On est à 3 semaines de la livraison, tout roule. Et là, coup de fil paniqué : “Betty, nouvelle directive européenne, on doit intégrer un module de conformité RGPD renforcé sinon on ne peut pas opérer.”

Sans MoSCoW, c’est la panique. Avec MoSCoW, c’est une discussion rationnelle :

1. Le module RGPD devient Must Have (pas le choix)
2. On estime : 2 semaines de dev
3. On regarde nos Could Have : 3 semaines de dev disponibles
4. On négocie : “OK pour le module RGPD, mais l’interface d’administration avancée passe en V2”
5. Deal accepté, projet livré à temps

La règle des 60% que je ne négocie jamais

Après 5 ans de gestion de projet chez Agerix, j’ai une règle d’or : jamais plus de 60% de l’effort total sur les Must Have.

"Mais Betty, tout est critique !"

Non. Si tout est critique, c’est que vous n’avez pas vraiment réfléchi. Quand l’Académie du 13ème me soutenait que les 47 fonctionnalités initiales étaient toutes indispensables, je leur ai proposé un exercice simple : “Vous ouvrez demain avec juste la gestion papier actuelle. Qu’est-ce qui vous empêche vraiment de fonctionner ?”

Réponse : l’inscription des élèves et la planification des cours. Le reste ? C’est du confort, de l’optimisation, de l’amélioration. Indispensable à terme, mais pas pour démarrer.

Pourquoi MoSCoW est notre arme secrète (et pourquoi vos projets en ont besoin)

La réalité d’un bureau d’études : jongler avec l’impossible

Permettez-moi d’être directe : en tant que bureau d’études spécialisé en développement sur mesure, nous sommes payés pour réussir là où les solutions toutes faites échouent. Nos clients ne viennent pas chez Agerix pour un WordPress amélioré. Ils viennent parce que leur métier est unique, complexe, et qu’ils ont besoin d’un outil qui épouse parfaitement leurs processus.

Le problème ? Quand tout est sur mesure, tout devient possible. Et “tout est possible” est la phrase la plus dangereuse en gestion de projet.

MoSCoW pour le développement sur mesure : domestiquer la complexité

Prenons le cas de Julie Pujols. Son business model est unique : des cours de Pilates en ligne, des box mensuelles, du coaching personnalisé, une boutique, le tout interconnecté avec des parcours clients sophistiqués. Aucun outil du marché ne fait ça.

Sans MoSCoW, on aurait pu partir dans 15 directions différentes pendant 18 mois. Avec MoSCoW, on a livré une V1 fonctionnelle en 8 mois, qui génère du chiffre d’affaires depuis le jour 1.

La clé ? Avoir forcé la conversation sur ce qui fait vraiment tourner son business :

• Must Have : Encaisser les abonnements et protéger le contenu premium
• Should Have : Les parcours personnalisés automatiques
• Could Have : L’intégration Instagram avancée
• Won’t Have : L’app mobile native (pour l’instant)

Résultat : Julie a pu lancer avec un outil qui couvre 100% de ses besoins critiques, pas 30% de tous ses rêves.

La carte “expertise externe” : pourquoi ils nous écoutent

Soyons honnêtes : quand un client a une idée en tête depuis 6 mois, c’est dur de lui dire que c’est un Could Have. Sauf que c’est exactement pour ça qu’ils nous paient.

L’avantage d’être externe ? Je n’ai pas d’affect avec leur feature préférée. Quand le directeur de European Cancer voulait absolument 15 types de visualisations différentes pour sa carte, j’ai pu lui dire objectivement : “3 visualisations bien faites valent mieux que 15 bâclées. Les 12 autres, on les garde pour impressionner Bruxelles l’année prochaine.”

Un chef de projet interne n’aurait pas pu avoir cette conversation. Moi, si. C’est mon job.

Le paradoxe de la flexibilité : être rigide pour rester agile

Voici ce que nos clients ne comprennent pas toujours au début : MoSCoW n’est pas une contrainte, c’est une libération.

LCDJ en est l’exemple parfait. Leur projet initial était un monstre tentaculaire de 120 fonctionnalités “indispensables”. On a appliqué MoSCoW, réduit à 35 Must Have. Résultat ? On a livré 2 mois plus tôt, et avec le budget économisé, on a pu faire une V2 six mois après avec 20 Should Have devenus Must Have entre temps.

Sans MoSCoW, ils seraient encore en train de développer leur V1 parfaite qui serait obsolète avant même d’être livrée.

L’effet MoSCoW sur nos équipes : du chaos à la sérénité

Côté Agerix, MoSCoW a transformé notre quotidien. Avant, nos développeurs jonglaient entre les “urgent” du client, les “critique” du commercial, et les “prioritaire” du chef de projet. Maintenant ?

Quand notre lead dev me demande “Betty, le client veut qu’on ajoute X, je fais quoi ?”, ma réponse est simple : “C’est dans quelle catégorie MoSCoW ?” S’il n’y est pas, la conversation est terminée. S’il y est, on sait exactement quelle priorité lui donner.

Pour la SNIPF, ça nous a permis de gérer 3 changements majeurs de scope sans une seule heure supplémentaire de stress. Les Won’t Have de la V1 sont devenus les Must Have de la V2, et tout le monde savait depuis le début que c’était le plan.

Le ROI invisible : les projets qu’on ne foire pas

Je vais vous confier un secret : notre meilleur argument commercial, ce ne sont pas les projets qu’on réussit. Ce sont ceux qu’on ne foire pas.

Dans notre industrie, 70% des projets de développement sur mesure dépassent les délais ou le budget. Chez Agerix ? On est à moins de 15%. La différence ? MoSCoW.

Quand LCDJ est venue nous voir, ils sortaient d’un échec cuisant avec un autre prestataire. 150K€ partis en fumée, rien de livré. Leur erreur ? Avoir voulu tout faire en même temps. Notre approche ? MoSCoW dès le jour 1. Résultat : application livrée en 5 mois, budget respecté, et ils utilisent l’outil tous les jours depuis 3 ans.

Mon conseil aux décideurs : posez-vous les vraies questions

Si vous lisez cet article en vous demandant si vous devriez externaliser votre gestion de projet ou nous confier votre développement, voici mon test :

1. Pouvez-vous me dire, là maintenant, quelles sont vos 10 fonctionnalités vraiment indispensables ?
2. Si je vous dis qu’on ne peut en faire que 5, lesquelles choisissez-vous ?
3. Êtes-vous prêt à signer un document qui dit “ça, on ne le fait pas en V1” ?

Si vous avez hésité, vous avez besoin de MoSCoW. Et probablement de quelqu’un comme nous pour l’appliquer.

L’épilogue qui fait réfléchir

Le mois dernier un client m’appelle : “Betty, tu te souviens de l’app mobile qu’on avait mise en Won’t Have il y a 18 mois ? On vient de la lancer. 50K téléchargements en 3 jours.”

Si on avait voulu tout faire en V1, son app mobile serait sortie en même temps que le reste… c’est-à-dire jamais, parce que le projet aurait explosé en vol.

MoSCoW, ce n'est pas dire non. C'est dire "pas maintenant" pour pouvoir dire "oui, et en mieux" plus tard.

FAQ sur la méthode MoSCoW et la gestion de projet