Cet article fait partie d’une série de trois articles, dans laquelle nous allons définir ce qu’est un système mutualisé, expliquer les enjeux d’un tel système et nos recommandations pour démarrer sa construction, le pérenniser et en assurer la gouvernance. Nous nous attacherons à étayer nos explications de retours d’expériences.

• Les systèmes mutualisés : enjeux et risques
• Les systèmes mutualisés : comment réaliser une gouvernance efficace
• Les systèmes mutualisés : démarrer et ne pas se perdre

Evaluer l’opportunité de lancer un projet de mutualisation et définir le périmètre d’un tel système n’est pas simple et doit faire l’objet d’une analyse en amont qui prend en compte plusieurs variables comme la valeur métier/sectorielle, l’homogénéité des processus dans les entités, etc. Dans ce contexte, l’article part de l’hypothèse que l’opportunité de mutualiser les processus de plusieurs entités de l’entreprise a été identifiée et que la décision de construire un système mutualisé est prise.

Pour réussir à mettre en place un système mutualisé, il faut non seulement réfléchir aux contraintes intrinsèques de la solution mutualisé mais aussi à celles liées au contexte de l’entreprise et à son organisation. Ceci dans le but de concevoir une solution unique faisant converger les processus tout en offrant suffisamment de souplesse pour permettre la subsidiarité nécessaire à chaque entité.

La construction d’un tel système représente un vrai challenge et un jeu de forces qui n’est pas simple à gérer. Néanmoins le projet peut être mieux maitrisé si dès le démarrage nous prenons en compte les éléments suivants :

• Définir le modèle de production et développement
• Définir la frontière entre le cœur et le spécifique
• Définir le niveau de mutualisation
• Concevoir un produit adapté pour maitriser la part du spécifique
• Assurer l’intégration dans des environnements divers
• Adopter une démarche itérative et incrémentale

Définir le modèle de production et développement

Notre expérience des systèmes mutualisés nous a montré l’importance d’avoir un modèle de production et développement pour éviter de perdre la cohérence du système dans le temps et d’assurer la qualité et l’évolution des fonctionnalités. On propose trois modèles :

Tracer la frontière entre le cœur et le spécifique

Lors de nos expériences dans des systèmes multi-entités, on a pu constater que la définition du périmètre fonctionnel du cœur commun induit une complexité plus forte à cause du niveau d’hétérogénéité entre entités et qu’en absence de la définition claire d’une frontière cœur-spécifique pour que chaque partie ait une évolution et une gouvernance appropriée, les entreprises se sont retrouvées avec des versions très hétérogènes de la même application. En conséquence, l’enjeu de mutualisation[1] n’est pas accompli et l’application est difficilement gouvernable et couteuse à maintenir et à faire évoluer.

Pour tracer la frontière, au moment de la conception respectant l'approche bottom-up décrit par l'article précèdent [2] il faudra catégoriser toutes les fonctionnalités dans le Cahier de Charges en « communes aux entités », « communes avec subsidiarité » et « spécifiques » tout en respectant les limites définies (ex. spécifique < 20%). Les deux premières catégories feront parti du cœur commun et la dernière sera la partie spécifique à l’entité.

Définir le niveau de mutualisation

En complément de la gestion des fonctionnalités, on doit aussi définir le niveau de mutualisation de ressources pour l’intégration, l’adaptation et le déploiement dans les entités. En fonction de l’homogénéité et le niveau de centralisation cible, on peut définir plusieurs niveaux de mutualisation de l’application:

• Niveau 1 : Ce niveau est le niveau plus haut de mutualisation dans le quelle tous les entités utilisent la même instance du logicielle. L’hébergement et toute évolution du cœur et du spécifique par entité sont gérés en central. Ce niveau est conseillé pour des applications très homogènes à travers les filiales qui n’ont besoin que de très peu de spécifique et que la connexion des utilisateurs à l’application peut être assuré.
• Niveau 2 : Le progiciel/logicielle est packagé ou construit au niveau groupe. Il existe un « cœur commun » de l’application développé qui est maintenu en central, cependant la partie spécifique est gérée par l’entité qui devra aussi héberger et maintenir une instance locale. Ce niveau donne plus de subsidiarité à l’entité et le groupe garde la maitrise du cœur de l’application. Ce niveau de mutualisation est conseillé pour les applications qui ont besoin de plus de subsidiarité ou qui doivent être installées localement pour garantir l’accès (ex. Sites isolés).
• Niveau 3 : C’est le niveau de mutualisation le plus faible. Les différentes entités utilisent la même application mais il n’existe pas le découpage entre le cœur et la partie spécifique car l’application est déployée indépendamment dans chaque entité et son paramétrage et son cycle de vie restent complètement indépendants entre les différentes entités. Dans ce cas on ne cible pas forcement l’homogénéisation des entités mais à faire des économies d’échelle dans l’achat des licences au niveau groupe

Concevoir un produit adapté pour maitriser la part du spécifique

Le système multi-entité devra être conçu avec des principes qui permettront de préserver la cohérence du cœur entre entités en permettant la gestion facile de la part du spécifique de chaque entité. Les mécanismes qu’on a pu recenser sont :

• Faciliter l’instanciation des classes : Pour faciliter les développements et la cohérence des parties spécifiques avec le cœur du système, il faut recourir au mécanisme d’héritage et utiliser des patterns d’instanciation de classes (factory, builder…). Ces mécanismes nous permettent d’étendre et de spécialiser les services proposés par le système sans toucher son noyau dont l’« équipe produit » aura le contrôle absolu.
• Cloisonner : A fin de préserver le cœur et de maitriser son évolution, il faut absolument séparer les développements spécifiques et le cœur du produit en cloisonnant les deux typologies de code dans des packages distincts.
• Limiter le nombre de branches dans le code : Il faut faire attention à ne pas multiplier le nombre de branches dans le code. La situation extrême étant de créer une branche pour chaque entité. L’idéal serait de limiter les branches à 2 : une branche de la dernière release stable du système et une branche de développement pour la release suivante.
• Respecter un déploiement strict des versions : La discipline sur la migration est essentielle et pour éviter les écarts entre les versions des entités. Nous recommandons de ne pas dépasser la limite d’une release de décalage entre la version actuelle du cœur et celle déployés dans les entités. L’idéal étant que toutes les entités aient en production la même version.
• Définir des paramètres système : Ils facilitent la customisation de l’application sans avoir besoin de modifier le code. Ex : Pays, langue, taux d’intérêt, coût d’une prestation entre autres. Il faut être vigilant pour maitriser cet aspect en documentant tous les paramètres (fonction, impacts), en traçant les changements et en mettant en place des tests automatisés qui puissent être joués pour l’ensemble des paramètres supportés. Il devient difficile de gérer une application si le nombre de fonctionnalités paramétrables explose, particulièrement en l’absence de recette automatisée.
• Utiliser les tables de paramétrage de règles de gestion: Ces tables sont similaires aux paramètres système mais elles permettent de customiser des règles de gestion sans modifier le code.
• Prévoir des appels à des scripts externes au cœur : Dans le cœur du système on peut prévoir des appels à des méthodes implémentés toujours dans la partie spécifique du code. Ce pattern est valable pour certaines fonctionnalités identifiées comme étant toujours propres aux entités. Cependant il faut prendre des précautions en recourant à ce pattern car le code commun devient dépendant d’un code externe au système.

Assurer l’intégration dans des environnements divers

Un système qui est censé cohabiter avec des systèmes diverses dans des environnements hétérogènes, doit être conçu avant tout comme un système facilement intégrable pour assurer sa permanence et son adoption. Souvent on dépense beaucoup des efforts dans la transformation des données, la standardisation des flux et l’interdépendance entre systèmes, pour cela il faut toujours concevoir dès le début un système qui respect les principes de:

• Modularité : Les systèmes mutualisés à déployer dans les entités doivent être des systèmes avec des couplages faibles et disposant d’une autonomie d’exploitation et d’utilisation à fin de faciliter son intégration et de lui donner une étanchéité vis-à-vis des évolutions dans les environnements des entités, de limiter les déploiements des systèmes annexes nécessaires et l’usage des données externes au système.
• Cohérence : Il faudra utiliser un dictionnaire de données commun aux entités. Elles définissent ensemble et acceptent un format pivot qui doit être utilisé en priorité lors des échanges de données dans le SI.
• Compatibilité : Les échanges du système mutualisé devront se faire en priorité via une infrastructure d’échange commune. En absence de cela, le système devra être en mesure de mettre en place des échanges via de services contractualisés basés sur des standards à la fois fonctionnels et techniques.
• Décommissionnement du système remplacé : Toute projet de mise en place du système multi-entité doit porter le décommissionnement des systèmes qu’il remplace. Le non décommissionnement d’un système ne doit se justifier qu’en regard de la non reprise totale de fonctionnalités par le nouveau système.

Adopter une démarche itérative et incrémentale

OCTO préconise toujours l’adoption d’une méthodologie agile où la construction se fait avec une démarche itérative et incrémentale[3] avec la mise en place de tests automatisés[4]. Dans le cadre des projets multi-entités, ils s’avère nécessaire pour maitriser le risque et la complexité qui est plus présente que dans de projets mono-entité, pour maitriser tous les changements de paramétrage et assurer la non régression avec les évolutions spécifiques.

En conclusion

Les systèmes multi-entités sont porteurs de bénéfices pour le business (homogénéiser les pratiques et réduire les coûts) mais ils ne devront pas être traités comme des systèmes conventionnels. Il faudra toujours considérer les risques spécifiques à ce type de démarche[5], mettre en place une gouvernance appropriée[6] inspiré des éditeurs logiciels en adoptant une démarche orientée produit  et on devra concevoir le système avec des pratiques d’architecture et de développement adaptées aux particularités d’un tel système pour qu’il puisse vraiment aider répondre aux attentes business sans bouleverser le fonctionnement de l’organisation et du systèmes d’information des entités cibles.

[1] https://blog.octo.com/les-systemes-mutualises-enjeux-et-risques/

[2] https://blog.octo.com/les-systemes-mutualises-comment-realiser-une-gouvernance-efficace/

[3]  http://en.wikipedia.org/wiki/Agile_software_development

[4] https://blog.octo.com/tag/tests/

http://en.wikipedia.org/wiki/Test_automation

[5] https://blog.octo.com/les-systemes-mutualises-enjeux-et-risques/

[6] https://blog.octo.com/les-systemes-mutualises-comment-realiser-une-gouvernance-efficace/