La demande tient souvent en une ligne dans un document soumis au conseil d’administration : élaborer un modèle de maturité pour nos partenaires. Une personne du secrétariat ouvre un tableur, saisit cinq intitulés, de « Débutant » à « Excellent », puis commence à remplir les cellules. Quelques semaines plus tard, lors de la réunion des membres, personne ne parle de gouvernance ni de compétences numériques. La discussion porte sur la question de savoir si un membre est « bon » ou « très bon », et sur qui en a décidé.
Le problème vient rarement de l’effort fourni, mais plutôt de l’ordre dans lequel les décisions sont prises. Ce guide explique comment créer un modèle de maturité pour un réseau de partenaires en huit étapes, de la définition de son objectif à sa première révision, avec un modèle gratuit de quatre pages, un exemple rempli pour une fédération fictive et les erreurs que j’éviterais.
Qu’est-ce qu’un modèle de maturité et d’où vient cette idée ?
En novembre 1986, le Software Engineering Institute de l’université Carnegie Mellon a commencé à élaborer un cadre de maturité des processus, en réponse à une demande visant à donner au gouvernement fédéral américain un moyen d’évaluer les capacités de ses prestataires de services logiciels. En 1993, ce cadre est devenu le Capability Maturity Model for Software, dont les cinq niveaux de maturité, selon les termes du SEI, « définissent une échelle ordinale » [1].
La structure est restée la même : une succession de niveaux décrivant un parcours de développement anticipé, souhaité ou typique, organisé en étapes distinctes [2]. Chaque niveau précise ce qui doit être vrai pour l’atteindre. L’évaluation situe ainsi une organisation sur le parcours et indique l’étape suivante. En 2005, il existait plus de 150 modèles de maturité, dans des domaines allant des services informatiques à la gestion des connaissances [3]. Pourtant, lorsque Becker, Knackstedt et Pöppelbuß en ont examiné 51, seuls neuf documentaient en détail leur processus de conception [2]. Voici la méthode issue de ces travaux, adaptée aux équipes de programme.
Comment créer un modèle de maturité en huit étapes
Ces étapes suivent les phases proposées par de Bruin, Rosemann, Freeze et Kulkarni pour élaborer tout modèle de maturité : définir le périmètre, concevoir, renseigner, tester, déployer et maintenir [3]. Chaque décision encadre la suivante, et le projet pilote vous amènera à réécrire les critères au moins une fois.
1. Définir l’objectif du modèle
Avant de définir le moindre niveau, notez les décisions que le modèle éclairera. Les travaux distinguent trois utilisations [3][4] : un modèle descriptif indique où en est chaque partenaire aujourd’hui ; un modèle prescriptif indique aussi ce qu’il faut faire ensuite ; un modèle comparatif établit des comparaisons entre partenaires ou régions, ce qui exige de nombreuses évaluations et des critères très stables. La plupart des réseaux de partenaires ont besoin des deux premières fonctions.
Sur la même page, précisez qui le renseigne (le partenaire seul, avec vous ou avec votre validation), à quelle fréquence, et ce à quoi il ne servira jamais. D’après mon expérience, cette dernière précision favorise davantage la sincérité des réponses que n’importe quelle consigne. Si les membres pensent que le modèle déterminera leur adhésion ou l’octroi d’une subvention, ils s’attribueront une note élevée, et le modèle décrira un réseau qui n’existe pas.
2. Choisir les dimensions
Les dimensions sont les thèmes couverts par le modèle : gouvernance, finances, compétences numériques, protection, participation des jeunes. Limitez-en le nombre afin de réduire la complexité et de les rendre indépendantes (les deux modèles de de Bruin et ses collègues comptaient respectivement six et quatre composantes principales). Faites en sorte qu’elles soient mutuellement exclusives et collectivement exhaustives [3] : aucune preuve ne doit compter deux fois, et rien de nécessaire à votre objectif ne doit manquer. Je vise quatre à sept dimensions, subdivisées en deux ou trois sous-dimensions lorsque le thème est vaste.
Avant de créer votre propre modèle, examinez ceux qui existent : Becker et ses collègues font de la comparaison avec les modèles existants la première condition à remplir pour en créer un nouveau [2]. Pour le renforcement des capacités, les sept éléments de la grille élaborée par McKinsey en 2001 pour Venture Philanthropy Partners constituent un bon point de départ [5], tout comme les six domaines présentés dans notre guide d’évaluation des capacités des partenaires.
3. Choisir quatre ou cinq niveaux
Le CMM comporte cinq niveaux [1] ; la grille McKinsey en compte quatre [5]. Le nombre importe moins que l’exigence formulée par de Bruin et ses collègues : des étapes distinctes et bien définies, qui suivent une progression logique et portent chacune un intitulé court évocateur de leur objectif [3].
| Quatre niveaux | Cinq niveaux | |
|---|---|---|
| Intitulés types | Découverte, Développement, Intégration, Leadership | Initial, Reproductible, Défini, Maîtrisé, Optimisé (ceux du CMM) [1] |
| À privilégier lorsque | Vous pouvez démontrer l’existence de quatre états distincts, des premiers pas à la capacité de guider les autres | Vous pouvez démontrer la différence entre bien faire les choses et les améliorer de manière systématique |
| Points de vigilance | Deux états différents regroupés dans un même niveau, où les partenaires risquent de rester pendant des années | Un niveau supérieur que personne n’atteint et des niveaux intermédiaires que les évaluateurs ne parviennent pas à distinguer |
Ma règle vient de mes travaux de recherche opérationnelle : un niveau ne mérite sa place que si vous pouvez le décrire à l’aide de preuves et le distinguer des niveaux voisins. Comptez les états que vous pouvez réellement observer dans votre réseau, puis arrêtez-vous là. Le nombre peut aussi augmenter : Becker et ses collègues ont commencé leur modèle de performance informatique avec quatre étapes, puis, après avoir interrogé des responsables informatiques, ils sont passés à six, de « inexistant » à « optimisé », afin de distinguer les situations les plus faibles [2]. Enfin, présentez le niveau le plus bas comme un point de départ, pas comme un verdict : « Découverte » ouvre la conversation ; « Défaillant » y met fin.
4. Décrire chaque niveau comme un état observable
C’est à cette étape que la plupart des modèles échouent. Un critère correspond au texte inscrit dans une cellule de la grille. Pöppelbuß et Röglinger comptent les critères vérifiables de manière intersubjective parmi les principes de conception d’un modèle de maturité utile : les descriptions doivent être assez précises et claires pour distinguer un niveau du suivant [4]. En termes simples, deux personnes observant le même partenaire devraient choisir la même cellule.
| Critère vague | Critère observable | Preuves |
|---|---|---|
| Bonne protection des données | Une personne est désignée responsable des données ; les règles de consentement et de conservation sont écrites et appliquées | Politique de gestion des données, formulaire de consentement, règle de conservation |
| Leadership numérique fort | Le conseil d’administration a approuvé un plan numérique assorti d’un budget et confié à une personne responsable | Procès-verbal du conseil, budget |
| Rapports adéquats | Une deuxième personne vérifie les indicateurs clés, qui sont communiqués dans les délais | Tableau des indicateurs, deux derniers rapports |
| Mobilise les jeunes en ligne | Les jeunes co-créent des contenus et la portée est mesurée chaque trimestre | Calendrier éditorial, chiffres trimestriels de portée |
Trois habitudes sont utiles :
- Nommez quelque chose que vous pouvez voir ou tenir en main : un document, une pratique régulière, un rôle, un chiffre. Bannissez « bon », « fort », « adéquat » et « efficace ».
- Ne faites évoluer qu’un seul élément à la fois. Si le niveau 3 ajoute simultanément un budget, une personne responsable et une revue annuelle, un partenaire qui remplit deux de ces trois critères ne saura pas où se situer.
- Faites en sorte que les niveaux soient cumulatifs. Chaque étape doit inclure les exigences des étapes précédentes [3]. Un test tiré de mes années de recherche opérationnelle : imaginez un partenaire qui répond aux critères du niveau 3, mais pas à ceux du niveau 2. Si cela vous semble possible, l’ordre n’est pas bon ou la cellule relève d’une autre dimension.
5. Définir les preuves associées à chaque niveau
Pour chaque cellule, précisez ce qui permettrait de le démontrer : une politique, un procès-verbal, un rapport, un chiffre. Demandez peu de preuves aux niveaux inférieurs et davantage aux niveaux supérieurs, où les exigences sont plus fortes ; indiquez aussi qui les fournit et qui les valide. Ne demandez jamais des preuves que personne ne consultera : chaque document prend du temps à votre partenaire, au détriment de ses activités.
6. Valider le modèle avec les partenaires
Présentez le projet aux personnes qui devront vivre avec le modèle. De Bruin et ses collègues ont utilisé la méthode Delphi et des groupes de discussion pour élaborer et vérifier leurs modèles [3] ; McKinsey a testé sa grille auprès de près d’une douzaine de directeurs généraux d’organismes sans but lucratif [5] ; la version 1.1 du CMM a été publiée après les retours d’un atelier consacré à la version 1.0, auquel ont participé environ 200 professionnels du logiciel [1]. Pour un réseau de partenaires, commencez par un atelier de deux heures réunissant huit à dix partenaires aux profils variés. Demandez-leur : Vous reconnaissez-vous dans le modèle ? Est-ce le langage que vous utilisez ? Qu’est-ce qui manque ? Y a-t-il des éléments humiliants ?
7. Tester le modèle et l’étalonner
Testez le modèle avec trois à cinq partenaires dans des conditions réelles. De Bruin et ses collègues insistent sur la nécessité de vérifier la validité et la fiabilité de l’outil, afin d’obtenir des résultats exacts et reproductibles [3]. Concrètement, deux personnes évaluent indépendamment le même partenaire ; chaque désaccord révèle un critère à reformuler. Si tous les partenaires du projet pilote se retrouvent au niveau 2, vos niveaux ne permettent pas de les distinguer ; si personne ne s’imagine atteindre le niveau 4, il s’agit d’une liste de souhaits. Une échelle qui place tout le monde dans la même case ne fournit aucune information.
8. Encadrer les modifications et réévaluer
Becker et ses collègues soulignent que tout modèle de maturité vieillit à mesure que les conditions, la technologie et les connaissances évoluent, et que les changements nécessaires doivent figurer dans une nouvelle version du modèle [2]. Traitez le vôtre comme une norme : attribuez-lui un numéro de version, prévoyez une seule période de révision par an, tenez un journal des modifications indiquant ce qui a changé et pourquoi, et ne modifiez rien au milieu d’un cycle d’évaluation. Lorsque la version 1.1 modifie une cellule, précisez comment les évaluations de la version 1.0 sont reprises, afin qu’aucun partenaire ne perde un niveau à cause de la reformulation d’une phrase. Réévaluez ensuite tous les 6 à 12 mois. Notre guide d’évaluation des capacités des partenaires explique comment mener ces cycles et pourquoi il ne faut jamais convertir les niveaux en une note unique en en faisant la moyenne.
Le modèle de maturité des partenaires (téléchargement gratuit)
Ce modèle transforme les huit étapes en quatre pages A4 : objectif et périmètre ; dimensions et niveaux ; grille des critères, avec un test des critères et des notes d’étalonnage ; plan des preuves, plan de validation et journal des versions.
Télécharger le modèle de création d’un modèle de maturité (PDF, 4 pages). Imprimez-le pour un atelier de conception ou copiez-en les sections.
Prêt à transformer la grille en un programme sur lequel vos partenaires peuvent travailler ? Dans Advancer.World, vos dimensions deviennent des sujets, vos niveaux des étapes et chaque critère une cellule, avec les demandes de preuves dans les étapes permettant de passer au niveau suivant. Chaque partenaire voit où il en est. L’inscription est gratuite.
Exemple : le parcours de maturité numérique des membres d’une fédération
Voici le modèle rempli pour la Meridian Youth Federation, une fédération fictive regroupant 26 organisations membres nationales.
Télécharger l’exemple rempli (PDF, 4 pages). Quatre choix méritent d’être repris :
- L’objectif exclut certains usages. Le modèle aide à déterminer quels membres bénéficieront en priorité d’un accompagnement entre pairs et quelles dépenses seront couvertes par le fonds de soutien numérique ; il ne sert jamais à établir le statut de membre ni à classer les membres.
- Quatre niveaux après en avoir testé cinq. Personne n’a pu démontrer de différence entre les deux niveaux intermédiaires du premier projet ; le cinquième niveau a donc été supprimé.
- Six domaines répartis en trois thèmes. Un membre peut être au niveau Leadership pour la mobilisation en ligne et au niveau Découverte pour la protection des données ; c’est précisément ce profil que la fédération doit pouvoir observer.
- Le projet pilote a fait évoluer les formulations. Deux évaluateurs ont interprété « publie régulièrement » comme une fois par semaine pour l’un et une fois par mois pour l’autre ; le niveau 2 de la mobilisation en ligne est donc devenu « un calendrier éditorial avec des canaux adaptés à chaque public ».
Erreurs fréquentes lors de la création d’un modèle de maturité
- Définir les niveaux avant l’objectif. Sans décision à éclairer, le modèle dérive vers un classement, que les partenaires finissent par considérer comme tel.
- Confondre le questionnaire avec le modèle. Le SEI a lui-même rencontré ce problème avec son questionnaire de maturité de 1987, que beaucoup ont pris à tort pour le modèle lui-même [1]. Le modèle décrit le parcours ; le questionnaire est l’un des moyens de le mesurer.
- Utiliser des adjectifs plutôt que décrire des états observables. « Adéquat » n’a pas le même sens pour tous les évaluateurs.
- Multiplier les dimensions. Quarante indicateurs produisent un modèle que personne ne va jusqu’au bout.
- Concevoir le modèle pour les partenaires plutôt qu’avec eux. Un niveau 1 formulé comme une liste de lacunes incite les partenaires à dissimuler leurs difficultés.
- Modifier le modèle au milieu d’un cycle. La modification d’un seul critère suffit à empêcher la comparaison entre ce cycle et le précédent.
Créer votre modèle de maturité dans Advancer.World
Advancer.World est né de la transformation numérique des programmes au sein d’organisations telles que UNICEF et Airbus. Dans la plateforme, un programme s’articule comme un modèle de maturité : les étapes correspondent à vos niveaux, les sujets et sous-sujets à vos dimensions, et chaque cellule contient un critère.
Les étapes entre les cellules indiquent ce dont un partenaire a besoin pour progresser : demandes de dépôt de documents justificatifs, questionnaires, initiatives et demandes de signature électronique. Pour chaque programme, vous choisissez comment les partenaires avancent : par autoévaluation, automatiquement à la fin de l’étape précédente ou uniquement après validation de votre équipe. Votre équipe peut modifier la conception ensemble, en temps réel. Les partenaires voient où ils en sont et ce que demande le niveau suivant, dans l’une des 22 langues, et ne voient jamais les données des autres partenaires. Des instantanés quotidiens conservent l’historique ; les rapports montrent ainsi l’évolution du réseau d’un cycle à l’autre.
FAQ
Combien de niveaux un modèle de maturité doit-il comporter ?
Quatre ou cinq pour la plupart des réseaux de partenaires. L’essentiel est que chaque niveau soit distinct, clairement défini et constitue une progression logique par rapport au niveau inférieur [3]. Si les évaluateurs ne parviennent pas à distinguer deux niveaux lors du projet pilote, fusionnez-les.
Combien de temps faut-il pour élaborer un modèle de maturité ?
Prévoyez deux à trois mois pour une première version : quelques semaines pour définir l’objectif, les dimensions et les niveaux, quelques semaines de plus pour rédiger les descriptions et définir les preuves attendues, puis organiser un atelier avec les partenaires et mener un projet pilote. Les raccourcis se paient par une deuxième version que personne n’avait budgétée.
Pouvons-nous adapter un modèle de maturité existant plutôt que d’en créer un ?
Souvent, oui, et c’est par là qu’il convient de commencer [2]. Vérifiez la licence, conservez la structure si elle répond à votre objectif et reformulez les descriptions dans le langage de votre réseau.
Un partenaire peut-il se situer à des niveaux différents selon les dimensions ?
Oui, et c’est généralement le cas ; ce profil est le résultat le plus utile du modèle. En revanche, un partenaire ne devrait pas sauter de niveaux au sein d’une même dimension, comme l’ont souligné les auteurs du CMM à propos de leurs propres niveaux [1].
Commencez par définir l’objectif, pas les niveaux
Si vous ne deviez retenir qu’une chose de ce guide, retenez l’ordre des étapes. Définissez l’objectif sur une page, mettez-vous d’accord avec quelques partenaires, puis seulement, ouvrez la grille. Un modèle conçu de cette manière prend plus de temps à démarrer, mais beaucoup moins à défendre.
Créez votre modèle de maturité une seule fois, puis utilisez-le avec chacun de vos partenaires. Concevez la grille avec votre équipe, invitez vos partenaires et suivez la situation de chacun, d’un cycle à l’autre. Commencez gratuitement.
Références
- Mark C. Paulk, Bill Curtis, Mary Beth Chrissis et Charles V. Weber, Software Engineering Institute, Carnegie Mellon University, « Capability Maturity Model for Software, Version 1.1 » (CMU/SEI-93-TR-024), février 1993, https://www.sei.cmu.edu/library/capability-maturity-model-for-software-version-11/ (consulté en octobre 2026).
- Jörg Becker, Ralf Knackstedt et Jens Pöppelbuß, « Developing Maturity Models for IT Management: A Procedure Model and its Application », Business & Information Systems Engineering, 1(3), 2009, p. 213-222, https://doi.org/10.1007/s12599-009-0044-5 (consulté en octobre 2026).
- Tonia de Bruin, Michael Rosemann, Ronald Freeze et Uday Kulkarni, « Understanding the Main Phases of Developing a Maturity Assessment Model », 16th Australasian Conference on Information Systems (ACIS), Sydney, 2005, https://aisel.aisnet.org/acis2005/109 (consulté en octobre 2026).
- Jens Pöppelbuß et Maximilian Röglinger, « What Makes a Useful Maturity Model? A Framework of General Design Principles for Maturity Models and its Demonstration in Business Process Management », Proceedings of the 19th European Conference on Information Systems (ECIS 2011), juin 2011, https://aisel.aisnet.org/ecis2011/28/ (consulté en octobre 2026).
- McKinsey & Company pour Venture Philanthropy Partners, « Effective Capacity Building in Nonprofit Organizations », 2001, https://www.bridgespan.org/getmedia/ef1ff943-173b-48ec-843a-b5ce85c6c807/effective-capacity-building-VPP.pdf (consulté en octobre 2026).
© 2026 Mourinho Solutions. Tous droits réservés.
