Modèles de maturité : un outil pour décrire le présent et prévoir le futur

Présentation de A à Z des modèles de maturité : différents niveaux, étapes à prendre en compte, exigences à respecter, principes de construction, conseils d’utilisation… On vous dit tout !

Un modèle de maturité propose différents niveaux de maturité, décrivant les étapes par lesquelles les systèmes doivent évoluer. Ce type de modèle permet aux entreprises d’identifier leurs forces et leurs faiblesses en termes de caractéristiques clés : interopérabilité, sécurité, agilité, etc. L’objectif est de prévoir et/ou de diagnostiquer les problèmes potentiels et de hiérarchiser les actions nécessaires pour les résoudre. Présentation globale du concept de modèle de maturité dans cet article.

Plus concrètement, les modèles de maturité sont généralement conçus pour évaluer une ou plusieurs caractéristiques clés. Ils proposent des niveaux qui décrivent les diverses étapes par lesquelles les systèmes devraient évoluer pour tendre vers l’excellence dans la réalisation d’un objectif donné.

qu’est ce qu’un modèle de maturité ?

Selon de Bruin et Becker, les modèles de maturité peuvent servir à trois fins différentes, comme décrit ci-dessous :

• Descriptive : compte tenu de l’objectif descriptif, des modèles de maturité sont utilisés pour évaluer l’état des systèmes concernés. Ils servent de base à l’analyse des capacités actuelles du système par rapport à un ensemble de critères prédéterminés. Un modèle descriptif peut être utilisé comme outil de diagnostic.
• Prescriptive : en ce qui concerne l’objectif prescriptif, des modèles sont utilisés pour identifier les étapes permettant d’atteindre un niveau de maturité plus élevé. Sur la base des résultats des évaluations, les modèles fournissent alors des conseils et des bonnes pratiques pour l’amélioration du système.
• Comparative : concernant la finalité comparative, un modèle de maturité sert à un benchmarking interne ou externe. Avec suffisamment de données historiques, les niveaux de maturité d’organisations similaires peuvent être comparés.

Concernant leur structure, les modèles incluent un nombre fixe de niveaux de maturité génériques, généralement autour de cinq. Chaque niveau de maturité est associé à plusieurs processus (également appelés pratiques) qui doivent être mis en œuvre.

Cependant, la plupart des modèles de maturité manquent de définition formelle de leurs critères et nécessitent un haut niveau d’expertise pour être appliqués dans un contexte industriel. Une manière de formaliser les frontières entre chaque niveau de maturité repose sur l’utilisation de mesures quantitatives (valeurs numériques caractérisant les interopérations entre systèmes).

La section suivante décrit la méthodologie de développement d’un modèle de maturité.

Une méthode de développement du modèle de maturité : domaine de l’informatique

Sur la base du Design Science Research (DSR), Becker définit une procédure de développement d’un un modèle de maturité axée sur la gestion informatique. Les auteurs ont également proposé huit exigences qui doivent être remplies pour réussir à construire un modèle de maturité.

Le tableau 1 présente les trois phases simplifiées du DSR. Le tableau 2 quant à lui liste les huit exigences proposées par Becker. Finalement, la figure 1 illustre les exigences liées à chaque phase du DSR.

Tableau 1. Phases de développement d’un modèle de maturité

Phase	Description
Conceptualisation	Définition du public concerné, de la couverture des zones d’interopérabilité, du type d’évaluation et des contextes applicatifs abordés. Une comparaison des modèles existants fait également partie de cette phase.
Développement	Définition des critères d’évaluation sur la base des exigences d’interopérabilité ; Définition des méthodes de notation, c’est-à-dire (a) les méthodes utilisées pour étayer la notation des critères ; (b) la méthode d’agrégation à utiliser lorsqu’il y a plus d’un évaluateur ; et (c) la méthode de détermination du niveau de maturité.
Application / Évaluation	Cela se fait en l’appliquant dans une étude de cas.

Exigence	Description
R1 (Comparaison avec les modèles de maturité existants)	La nécessité de développer un nouveau modèle de maturité doit être justifiée par une comparaison avec les modèles existants. Le nouveau modèle peut aussi n’être qu’une amélioration d’un modèle déjà existant.
R2 (Procédure itérative)	Les modèles de maturité doivent être développés de manière itérative, c’est-à-dire étape par étape.
R3 (Évaluation)	Tous les principes et prémisses pour l’élaboration d’un modèle de maturité, ainsi que l’utilité, la qualité et l’efficacité de l’artefact, doivent être évalués de manière itérative
R4 (Procédure multi-méthodologique)	Le développement de modèles de maturité fait appel à diverses méthodes de recherche, dont l’utilisation doit être fondée et finement cadrée.
R5 (Identification de la pertinence du problème)	La pertinence de la problématique-solution proposée par le modèle de maturité projetée pour les chercheurs et/ou praticiens doit être démontrée.
R6 (Définition du problème)	Le domaine d’application prospectif du modèle de maturité, ainsi que les conditions de son application et les bénéfices attendus, doivent être déterminés avant la conception.
R7 (Présentation ciblée des résultats)	La présentation du modèle de maturité doit être ciblée sur les conditions de son application et les besoins de ses utilisateurs.
R8 (Documentation scientifique)	Le processus de conception du modèle de maturité doit être documenté en détail, en tenant compte de chaque étape du processus, des parties impliquées, des méthodes appliquées et des résultats.

Un exemple réel d’un modèle de maturité 

Afin d’illustrer la conceptualisation d’un modèle de maturité, on présente dans cette section le Maturity Model For Enterprise Interoperability (MMEI).

De nombreux autres modèles sont présents dans la littérature et dans l’industrie avec pour caractéristiques l’interopérabilité, la durabilité, la sécurité, la gestion, etc. Cependant, nous avons décidé de prendre le modèle de maturité pour l’interopérabilité des entreprises MMEI⁴ comme modèle de référence. Pourquoi ? Parce qu’il :

1. Définit un cadre pour évaluer et mesurer la maturité potentielle de l’interopérabilité, tout en fournissant des informations sur l’état d’avancement d’une entreprise quant aux niveaux de maturité ciblés ;
2. Adopte une approche systémique et fournit une vision holistique en tenant compte des différents obstacles et préoccupations de l’interopérabilité basés sur le cadre d’interopérabilité des entreprises (FEI) ;
3. Est une norme internationale ISO 11354-1:2011 et aussi ISO-11354-2.

Pour les lecteurs curieux, vous trouverez d’autres modèles de maturité ci-dessous :

• Capability Maturity Model Integration (CMMI)
• Organizational Project Management Maturity Model (OPM3)
• Open Information Security Management Maturity Model (O-ISM3)

Conceptualisation du modèle

Ce processus concerne le périmètre du modèle. Selon la littérature sur le développement du modèle de maturité, il est nécessaire de définir :

• Le type d’application (c’est-à-dire intra ou niveau inter-organisationnel) ;
• L’objectif (c’est-à-dire quel domaine l’artefact va cibler : généraliste ou plus spécifique) ;
• Le problème abordé et la solution proposée ;
• Le public ;
• Le type de modèle.

Ci-dessous, le tableau 3 présente la conceptualisation de MMEI :

Phase	Description
Application	Intra et inter-organisation.
Objectif	Général : considère les multiples domaines liés à l’interopérabilité d’entreprise en réseau,
Problème à résoudre	Absence de modèle d’évaluation organisant et corrélant les différentes exigences d’interopérabilité des différents domaines d’interopérabilité qui peuvent être appliquées dans les contextes « a priori » et « a posteriori ».
Audience	Les parties prenantes (qui connaissent l’entreprise ou une partie de celle-ci), les décideurs (qui sont en position de responsabilité de prendre des décisions), les architectes et les ingénieurs des services aux entreprises.
Type	Descriptif : pour permettre aux entreprises d’évaluer leur état actuel, en ce qui concerne l’interopérabilité ; Prescriptif : permettant aux entreprises d’identifier les opportunités d’amélioration en fonction de leur état actuel et souhaité, en ce qui concerne l’interopérabilité ; Comparatif : pour permettre aux entreprises de comparer et d’identifier les obstacles potentiels entre les partenaires existants et potentiels.

Ce modèle décrit cinq niveaux de maturité (tableau 4). Chaque niveau est une instanciation des principaux éléments d’interopérabilité avec une évolution des éléments concernant le développement du niveau.

Niveau de maturité	Description
Niveau 4 – Adaptatif	Capacité de négocier et d’accommoder dynamiquement avec n’importe quel partenaire hétérogène.
Niveau 3 – Organisé	Capacité de méta-modélisation pour réaliser les mappages nécessaires à l’interopérabilité avec plusieurs partenaires hétérogènes.
Niveau 2 – Aligné	Capacité d’apporter les modifications nécessaires pour s’aligner sur des formats ou des normes communs.
Niveau 1 – Défini	Capacité de modélisation et de description correctes des systèmes pour préparer l’interopérabilité.
Niveau 0 – Non préparé	Capacités d’interopérabilité ad hoc ou absence de volonté d’interopérabilité.

Le cadre de développement du MMEI

Sur la base des dimensions FEI, il définit douze domaines d’interopérabilité. Ces zones représentent le croisement entre les barrières et les préoccupations en matière d’interopérabilité. Chacun des domaines d’interopérabilité contient les critères d’évaluation qui doivent être vérifiés lors de l’évaluation du niveau de maturité d’une entreprise.

Ces domaines sont nommés d’après leur obstacle et leur préoccupation associés. Par exemple : Business-Conceptuel et Service-Technologique. Le tableau 5 présente les différents domaines d’interopérabilité.

	Conceptuel	Technologique	Organisation
Business	Modèles d’affaires pour les partenariats multiples et l’entreprise collaborative	Infrastructure informatique ouverte	Structure organisationnelle flexible
Processus	Méta-modélisation pour plusieurs mappages de modèles	Plateformes et outils pour l’exécution collaborative des processus	Collaboration inter-entreprises Gestion des processus
Service	Méta-modélisation pour plusieurs mappages de modèles	Découverte et composition automatisées des services, applications partagées	Services collaboratifs et gestion des applications
Données	Méta-modélisation pour plusieurs mappages de modèles	Accès à distance aux bases de données possible pour les applications, données partagées	Gestion personnalisée des données pour différents partenaires

Le MMEI propose un critère pour chaque zone d’interopérabilité et pour chaque niveau de maturité, totalisant ainsi 48 critères d’interopérabilité. De plus, le MMEI propose 126 bonnes pratiques.

Chaque pratique est associée à un critère d’interopérabilité. Ces pratiques décrivent « ce qui » devrait être fait pour améliorer la situation actuelle en termes d’interopérabilité. Le tableau 6 présente un exemple de critère d’évaluation.

Critère	Dispositifs de stockage de données connectables, échange électronique simple possible
Niveau de maturité	Niveau 1
Zone de l’IE	Données – Technologique (DT1)
Objectif	L’objectif de la zone d’interopérabilité DT1 est de vérifier si les périphériques de stockage de données d’entreprise sont connectables et si le simple échange électronique de données est possible. Note 1 : le stockage de données comprend une base de données, des fichiers de données, etc. Note 2 : un « dispositif de stockage de données » est connectable, ce qui signifie qu’il est configuré pour recevoir une demande d’information d’un appareil électronique (par exemple : un PC) ou d’un serveur de stockage distant. Note 3 : à ce niveau, l’échange d’informations est généralement limité à de simples formats de données homogènes (texte, Jpeg, etc.).
Bonnes pratiques	DT1.1. : identifier les données qui peuvent faire l’objet d’une future interopérabilité. DT1.2. : configurer les périphériques de stockage de données afin qu’ils soient connectables. DT1.3. : mettre en place des actifs techniques prenant en charge l’échange de données au sein de l’entreprise. DT1.4. : définir des protocoles pouvant être utilisés pour l’interopérabilité de l’échange de données.

Pour évaluer ces critères, le modèle adopte un mécanisme de mesure qualitative. Cela signifie que l’évaluateur peut évaluer chaque critère à l’aide de quatre variables linguistiques :

• Non atteint (NA) ;
• Partiellement atteint (PA) ;
• Largement atteint (LA) ;
• Entièrement atteint (EA).

Lorsqu’il y a plus d’un évaluateur, la cote finale d’un critère est calculée en agrégeant les cotes fournies par tous les évaluateurs concernés. Un mécanisme de mesure quantitative, basé sur la théorie des ensembles flous et sur l’opérateur d’agrégation de la Moyenne Pondérée Ordonnée (OWA), est fourni pour traduire les valeurs linguistiques en valeurs numériques.
Objectif : calculer, agréger et calculer les notations finales des critères, et par conséquent, le niveau de maturité. La figure 2 illustre la méthode de notation.

L’application du MMEI à un cas réel

Le cas d’utilisation démontré dans cette partie afin d’évaluer la contribution proposée est le suivant : il s’agit d’une multinationale, qu’on appellera « CarPartsCo », spécialisée dans la construction automobile, intégrant les systèmes de faisceaux de câblage, les intérieurs exclusifs et les composants électriques. CarPartsCo a l’intention de devenir plus agile et flexible pour améliorer sa réponse aux nouvelles opportunités commerciales.

Pour assurer ses fonctions et atteindre ses objectifs, l’entreprise doit interagir avec de nombreux partenaires, y compris son siège. Cependant, certains défis concernant l’interopérabilité entre CarPartsCo et ses partenaires commerciaux entravent leur collaboration efficace.

Ainsi, le modèle MMEI est appliqué pour identifier les obstacles à l’interopérabilité, existants et potentiels, qui peuvent avoir une incidence sur l’ensemble des systèmes. Deux phases ont été utilisées pour mener les évaluations afin d’obtenir des résultats précieux.

La première a été la phase de préparation au cours de laquelle des entretiens et des ateliers ont été menés avec les employés clés de CarPartsCo. L’idée était de recueillir des données pertinentes concernant leur mode de fonctionnement, leurs tâches collaboratives, et les problèmes et risques perçus. De plus, dans cette phase, une analyse des données collectées nous a permis de concevoir la situation telle qu’elle est (principaux processus, ressources, infrastructure IT, etc.).

La deuxième a été la phase d’évaluation au cours de laquelle deux évaluateurs ont évalué l’interopérabilité de l’entreprise. L’évaluation a été réalisée afin de mettre en évidence sa capacité à être interopérable avec son environnement et en soulignant les problèmes potentiels peuvant influencer l’interopérabilité.

Le tableau 7 suivant présente le résumé de l’évaluation de CarPartsCo en tenant compte de chaque domaine d’interopérabilité.

Zone	ID	Note	Zone	ID	Note	Zone	ID	Note	Zone	ID	Note
BC	BC1	EA	PC	PC1	EA	SC	SC1	EA	DC	DC1	EA
BC2	LA	PC2	LA	SC2	LA	DC2	EA
BC3	LA	PC3	NA	SC3	NA	DC3	NA
BC4	LA	PC4	PA	SC4	LA	DC4	NA
BT	BT1	EA	PT	PT1	EA	ST	ST1	EA	DT	DT1	EA
BT2	EA	PT2	LA	ST2	LA	DT2	LA
BT3	LA	PT3	LA	ST3	LA	DT3	LA
BT4	PA	PT4	LA	ST4	PA	DT4	NA
BO	BO1	EA	PO	PO1	EA	SO	SO1	EA	DO	DO1	EA
BO2	EA	PO2	LA	SO2	LA	DO2	LA
BO3	LA	PO3	LA	SO3	LA	DO3	NA
BO4	LA	PO4	LA	SO4	NA	DO4	NA

BC = Business-Conceptuel, PO = Process-Organisationnel, DT = Data-Technologique, etc.

EA= Entièrement atteint, etc.

En considérant le mécanisme de mesure MMEI, CarPartsCo a obtenu une maturité égale au Niveau 2 – Aligné : capacité d’apporter les modifications nécessaires pour s’aligner sur des formats ou des normes communes.

Conclusion

Dans cet article, nous avons parlé des modèles de maturité. Ce sont des instruments précieux pour les responsables informatiques car ils permettent d’évaluer la situation actuelle d’une entreprise et d’identifier des mesures d’amélioration raisonnables.

De même, nous avons présenté comment cadrer et développer un modèle de maturité, ainsi que les différentes phases à prendre en compte et les exigences à respecter. Nous avons également décortiqué le standard ISO Maturity Model for Enterprise Interoperability, ce qui nous a permis d’appréhender la construction d’un tel modèle. Enfin, nous avons présenté une application de MMEI afin de démontrer l’utilisation d’un modèle de maturité.

Sources 

1. (de Bruin et al. 2005) De Bruin, T., Freeze, R., Kaulkarni, U., Rosemann, M., 2005. Understanding the Main Phases of Developing a Maturity Assessment Model, in: Campbell, B., Underwood, J., Bunker, D. (Eds.), Australasian Conference on Information Systems (ACIS). Australasian Chapter of the Association for Information Systems, Sydney, New South Wales, Australia, pp. 8–19.
2. (Becker et al. 2009) Becker, J., Knackstedt, R., & Pöppelbuß, J. (2009). Developing maturity models for IT management. Business & Information Systems Engineering, 1(3), 213-222. https://doi.org/10.1007/s12599-009-0044-5
3. (Ford et al., 2007) Ford, T., Colombi, J., Graham, J., Jacques, D. The Interoperability Score. In: Proceedings of the 5th Annual Conference on Systems Engineering Research. Hoboken, N.J., (2007)
4. (Guédria et al., 2015) Guedria, W., Naudet, Y., Chen, D. Maturity model for enterprise interoperability, In Enterprise Information Systems, vol. 9, issue 1, pp. 1-18. (2015) https://doi.org/10.1080/17517575.2013.805246
5. ISO 11354-1, 2011. ISO 11354-1:2011 Advanced automation technologies and their applications — Requirements for establishing manufacturing enterprise process interoperability — Part 1:Framework for enterprise interoperability. ISO/TC 184/SC 5.
6. ISO 11354-2, 2015. ISO 11354-2:2015 – Advanced automation technologies and their applications — Requirements for establishing manufacturing enterprise process interoperability — Part 2:Maturity model for assessing enterprise interoperability. ISO/TC 184/SC 5.
7. (Yager, 1988) Yager, R.R., 1988. On ordered weighted averaging aggregation operators in multicriteria decisionmaking. IEEE Transactions on Systems, Man, and Cybernetics 18, 183–190. https://doi.org/10.1109/21.87068
8. (da Silva 2020) Leal, G. S., Guédria, W., & Panetto, H. (2020). Enterprise interoperability assessment: a requirements engineering approach. International Journal of Computer Integrated Manufacturing, 33(3), 265-286. https://doi.org/10.1080/0951192X.2020.1736636

Vous avez aimé cet article ?
Partagez-le et laissez vos commentaires 😉