Introduction

Cet article est le deuxième 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.

1. Quel modèle de gouvernance pour un système mutualisé?

Notre expérience des systèmes mutualisés nous a conduit à deux constats.

Premièrement, nous avons remarqué que les Directions des Systèmes d’Information avaient beaucoup de mal à construire des systèmes multi-entités[1]****. Effectivement, beaucoup de nos clients qui se sont lancés sur cette voie ont rencontré de nombreuses difficultés et le ROI espéré n’était pas au rendez-vous. Malgré la diversité de ces clients en termes de secteurs et de tailles, ils partageaient le fait que, pour construire le système mutualisé, ils avaient adopté la même approche projet que pour les autres applicatifs de la DSI (qui ne sont pas multi-entités). Ce constat nous amène à penser que les modèles classiques de gouvernance des projets SI ne sont pas adaptés à un projet d’application multi-entités.

Deuxièmement, nous avons observé qu’un système mutualisé ressemble plus à un progiciel qu’à une application classique. En effet, comme un progiciel, un système mutualisé a vocation à être utilisé par plusieurs « clients internes »: filiales dans plusieurs pays, différentes directions métier… De plus, il doit gérer, en même temps, les fonctionnalités communes et les spécificités de chaque « client ».

Additionné au premier, ce dernier constat nous amène à la conclusion que la meilleure manière de construire un système mutualisé est d’adopter une posture d’éditeur ce que plusieurs expériences concrètes nous ont permis de vérifier.

Dans la suite de cet article, nous allons vous fournir plusieurs recommandations vous permettant d’aborder un projet de système mutualisé avec une posture éditeur. Ces recommandations sont tirées de nos retours d’expérience et des bonnes pratiques du monde de l’édition logicielle.

2. Qu’est-ce qu’une posture éditeur ?

Prendre une posture éditeur se traduit par adopter une approche « Produit » au lieu de l’approche « Ressources » habituellement appliquée dans les DSI.

En effet, avec une approche « Ressources », le premier rôle de la DSI est de mettre à disposition des ressources informatiques capables de mettre en œuvre les fonctionnalités demandées. Par conséquent, l’équipe projet possède un rôle assez « passif »  consistant à répondre de manière spécifique aux besoins exprimés du ou des clients (voir Figure 1). Par contre, dans l’approche « Produit », l’équipe projet doit avoir un rôle beaucoup plus « actif ». Ce rôle, consiste à définir elle-même des réponses cohérentes aux besoins des clients (voir Figure 2). Ces réponses peuvent prendre plusieurs formes :

• Une fonctionnalité qui répond de manière spécifique à un seul besoin exprimé
• Une fonctionnalité qui répond à plusieurs besoins similaires
• Une fonctionnalité qui répond à un besoin ressenti par l’équipe projet et non exprimé par les clients

Figure 1- Description d'une approche "Ressources"

Figure 2- Description d'une approche « Produit »

Le travers que nous avons observé de l’approche « Ressources » est que l’équipe projet subit la vision que se fait l’entité de l’application. En effet, le rôle de l’équipe projet se cantonne à la mise en œuvre. Lorsqu’il y a un seul client en face, ce travers peut s’avérer peu impactant. Par contre, lorsque l’équipe est confrontée à plusieurs clients, la vision de chacun a toutes les chances de diverger avec les autres. Et cette divergence risque de se traduire par un système mutualisé peu cohérent et juxtaposant une application spécifique à chaque entité. Un tel système ne peut être que très complexe à développer et à maintenir.

Par conséquent, dans les applications multi-entités, il est important de donner un rôle plus actif à l’équipe projet dans la définition de la vision du système final afin qu’elle puisse faire converger les visions des clients en amont et faciliter la tâche de mise en œuvre.

3. Comment adopter une approche produit ?

Les principales composantes à mettre en place pour adopter une approche « produit » sont une organisation orientée produit et une roadmap produit. Dans la suite, nous allons détailler chaque élément.

3.1. Comment mettre en place une organisation orientée produit ?

Dans notre approche, 3 points sont à adresser en priorité

• Construire et faire vivre une vision fonctionnelle et une stratégie d’évolution du produit
• Construire et faire vivre le cœur du système qui sera commun à toutes les entités
• Accompagner les entités dans l’intégration du système mutualisé dans leur SI (paramétrage, développements spécifiques…)

Pour traiter chaque point, nous allons nous inspirer des organisations des éditeurs logiciels et nous proposons la mise en place d’une organisation basée sur 3 composantes

• Responsable produit (et son équipe) : cet acteur construit et fait vivre la vision permettant de définir la stratégie d’évolution du produit matérialisée par la roadmap produit. Il doit réaliser les arbitrages nécessaires permettant au produit d’évoluer sans perdre en cohérence. Le responsable produit doit avoir suffisamment  d’expertise métier et de légitimité pour être capable d’anticiper les besoins futurs des entités, de challenger les utilisateurs sur leurs besoins et d’être force de proposition. De plus, il doit être suffisamment proche des équipes de développement pour intégrer les contraintes et les possibilités techniques dans sa réflexion[2]
• Equipe de développement du cœur du système : cette équipe constituée de développeurs, d’architectes et d’analystes métier aura pour rôle de mettre en œuvre la roadmap définie par le responsable produit. Il est primordial que le niveau de compétence et d’expérience de cette équipe soit très élevé. En effet, un système mutualisé est un système plus complexe qu’une application classique. Par conséquent, la qualité du code et de l’architecture doivent être d’un niveau supérieur à la moyenne afin de ne pas hypothéquer la pérennité du produit
• Equipe de conseil et d’intégration : cette équipe aura pour rôle d’accompagner les entités dans la mise en place du produit. Son intervention se situe à deux niveaux dans le projet d’intégration
  • Elle intervient en amont du projet pour comprendre les objectifs et les contraintes du client afin d’être force de proposition en tant qu’expert sur la problématique adressée par l’application
  • Elle accompagne les équipes du client dans le paramétrage et dans le développement du code spécifique autour du cœur du produit

Cette équipe doit regrouper de bons experts du système. En effet, son rôle est primordial pour plusieurs raisons

• C’est de leur intervention que dépend le succès du projet. En effet, peu importe la qualité de développement du cœur du produit, un mauvais paramétrage ou un code spécifique dégradant les performances induiront une perception négative du produit par les utilisateurs et, éventuellement, son rejet
• Ils sont les garants du bon découplage entre le cœur commun de l’application et les développements spécifiques aux entités. Effectivement, un couplage fort entre le code commun et spécifique rendra les opérations de montée de version très douloureuses
• Ils sont en contact direct avec le terrain (les SI et les équipes des entités). Par conséquent, ils peuvent être une source très riche de bonnes idées aussi bien au niveau fonctionnel qu’au niveau technique

3.2. Comment définir sa roadmap produit ?

La roadmap produit matérialise la vision du système mutualisé. Elle consiste à définir la stratégie de construction et d’évolution de notre application. La figure 3 décrit notre vision d’une roadmap produit pour un système multi-entités.

Figure 3- Description d’une roadmap produit pour un système mutualisé

Dans cette roadmap, nous distinguons deux grandes phases : la phase d’initialisation du système et la phase de son évolution.

3.2.1. Initialisation du système mutualisé

En voulant construire leur produit, certains de nos clients ont voulu concevoir un système multi-entités dès le départ. Ceci conduit presque toujours à des projets trop complexes (contours flous, multiplication des intervenants …) victimes de coûteux effet tunnel.

Exemple : nous sommes intervenus chez un opérateur télécom pour le cadrage d’un projet d’une application de souscription multicanal qui devait être utilisée pour la vente par Internet, par téléphone et dans les boutiques. L’application devait être fonctionnelle pour les trois canaux dès la première mise en production. Ces canaux étant gérés par des départements différents, des représentants de chaque département sont intervenus dans le cadrage. Cette multiplication d’acteurs a rendu l’activité de cadrage très difficile et a induit des retards importants. En effet, chaque département avait ses contraintes propres et sa vision propre du processus de souscription qu’il voulait intégrer dans l’application. Par conséquent, chaque élément du cadrage donnait lieu à un long débat (chacun prêchant pour sa chapelle) qui se terminait invariablement par un consensus mou ne satisfaisant personne. A cause de cela, le cadrage s’est éternisé et le projet a fini par être abandonné.

Par conséquent, comme première étape, nous recommandons de commencer sur un périmètre restreint en se focalisant sur une seule entité pour construire une première application. Pour choisir ce partenaire, il convient de choisir celui ayant les processus métier les plus matures. A défaut, il est possible de choisir celui ayant le plus foi dans la vision du produit. Cependant le fait de se focaliser sur un seul partenaire ne doit pas nous pousser à mettre en place une architecture trop fermée qui serait un handicap pour les évolutions futures. Toute la difficulté de la définition de l’architecture dans cette première étape est de trouver le bon curseur entre une architecture trop spécifique au partenaire qui serait une limitation du système et une architecture trop « générique » qui serait trop complexe à construire et à maintenir.

A la fin de l’étape précédente, nous avons un système qui marche, qui apporte de la valeur métier à la première entité et qui est montrable aux autres. Néanmoins, le produit n’a été conçu que pour un seul partenaire. Par la suite, ayant mis en place les bases fonctionnelles de notre système, le nouvel objectif consiste à trouver un deuxième partenaire avec qui mettre en œuvre l’aspect mutualisation.

Nos retours d’expérience nous amènent à préconiser de réaliser cette mise en œuvre en deux étapes

• Adapter et mettre en production le système initial pour le deuxième partenaire
• Réaliser une phase de convergence des deux systèmes afin
  • D’identifier les points de convergence et de divergence des processus des deux entités
  • D’identifier les fonctionnalités communes et faire converger le code correspondant dans un seul cœur commun
  • D’identifier les fonctionnalités spécifiques et séparer le code correspondant du cœur commun
  • De faire évoluer et adapter l’architecture logicielle aux contraintes de mutualisation

Cette démarche qui, à première vue, peut sembler lourde, s’avère la plus efficace. En effet, elle permet d’avoir de véritables retours terrain sur les points communs et spécifiques des entités (processus métier, fonctionnalités, architecture…). Ainsi, il est possible de définir et de mettre en place les patterns les plus adéquats pour chaque aspect.

3.2.2. Evolution du système mutualisé

Cette phase est plus étendue dans le temps que la première. Comme pour les logiciels des éditeurs, elle est jalonnée par la mise à disposition de nouvelles versions du système mutualisé. En abordant cette phase deux questions fortement liées se posent : à quel rythme livrer les versions et comment définir le périmètre fonctionnel de chacune d’elles ?

a. A quel rythme livrer les versions ?

Afin d’éviter l’effet tunnel et de pouvoir délivrer de la valeur rapidement, nous préconisons de structurer la roadmap sur des livraisons de « releases » régulières, rapprochées (l’idéal est tous les 3 mois) et selon un calendrier fixe et connu de tous. Cette cadence possède trois avantages principaux :

• Elle permet de donner de la visibilité aux utilisateurs et d’instaurer de la confiance entre les entités et l’équipe produit
• Elle permet de s’adapter rapidement aux nouvelles exigences des utilisateurs (anciens et nouveaux)
• Elle permet d’instaurer et de maintenir une dynamique du côté de l’équipe produit et des utilisateurs

Afin de respecter ce rythme, il est important d’être vigilant au niveau de la définition du périmètre fonctionnel de chaque version. Effectivement, un périmètre trop grand ou mal maîtrisé induira des retards de livraison et conduira à la perte des avantages cités précédemment.

Ceci nous amène à traiter la deuxième question.

b. Comment définir le périmètre fonctionnel des versions ?

La définition du périmètre d’une version induit deux activités assez classiques : le recueil des besoins et la délimitation du périmètre d’une version donnée. Dans ce qui suit, nous allons étayer quelques bonnes pratiques permettant de mener ces tâches à bien.

i. Recueillir les besoins au plus près des utilisateurs

Pour cette activité, les maître-mots sont proximité et échange. Effectivement, la proximité avec les utilisateurs (ou leurs représentants) est indispensable afin de cerner et comprendre leurs besoins. Quant aux échanges, il faut les développer entre l’éditeur et les utilisateurs et entre les utilisateurs eux-mêmes. Ceci aura pour but de favoriser le partage d’expérience et faire émerger de nouvelles idées d’évolution. Dans cette optique, voici quelques bonnes pratiques issues du monde des éditeurs logiciels.

• Créer un club utilisateur : ce club aura pour but de rassembler périodiquement (en général avant de fixer le périmètre fonctionnel d’une version) l’ensemble des utilisateurs clés afin d’échanger sur leurs expériences et leurs bonnes pratiques et de décider, collégialement, des grandes priorités d’évolutions du système. Ce club devra être animé par le responsable produit et il faut qu’au moins un représentant de chaque entité y participe
• Aller sur le terrain : hormis les rituels des rencontres du club utilisateurs, il est pertinent d’aller sur le terrain discuter avec ceux qui utilisent et exploitent au quotidien le produit. Ceci aura pour but d’approfondir certains aspects fonctionnels ou techniques afin d’avoir des retours à exploiter pour améliorer le système
• Donner ce rôle aux équipes de conseil et d’intégration : étant donné qu’ils côtoient au quotidien les « clients », ces équipes doivent être encouragées à jouer le rôle d’ambassadeur, d’yeux et d’oreilles pour le responsable produit

ii. Délimiter un périmètre d’une version cohérent avec la date de livraison

Cette deuxième activité est délicate car elle induit généralement plusieurs arbitrages et la négociation de compromis avec les entités. En effet, chez nos clients nous avons été souvent confrontés au syndrome de « la lettre au père noël ». Ce phénomène se matérialise par une liste sans fin de besoins (plus ou moins importants) que les utilisateurs souhaitent voir apparaître dans la version suivante.

Pour lutter contre ce syndrome, nous conseillons la mise en application de 2 bonnes pratiques de l’Agile qui sont

• Négocier le périmètre fonctionnel livré et non la date de livraison : il est important de rester ferme sur la date de livraison et savoir dire « non » aux entités. Sinon, les décalages de livraison deviendront chroniques et nous allons perdre les avantages d’un rythme de livraison court et régulier décrits précédemment
• Traiter les besoins par ordre de priorité métier : pour réaliser les arbitrages, le critère que la méthodologie Agile recommande d’utilise est la criticité métier. En effet, c’est ce critère qui permet de mesurer la vraie valeur ajoutée de l’application

Dans les arbitrages et les négociations précédemment cités, le responsable produit doit avoir un rôle prépondérant. Effectivement, c’est lui qui est le garant de la vision du produit et de la cohérence fonctionnelle et technique du système multi-entités.

4. Comment gérer les risques d’un système mutualisé?

A travers les missions réalisées chez nos clients, nous avons identifié deux grandes catégories de risques qui peuvent mettre en péril un système multi-entités : un risque organisationnel et un risque d’explosion de la complexité de l’application.

Dans la suite, nous allons décrire chaque catégorie de risque et présenter plusieurs recommandations permettant de les mitiger.

4.1. Comment gérer le risque organisationnel ?

Lors de la définition de la roadmap, nous avons souvent observé une lutte d’influence entre les entités afin de faire concorder la roadmap avec leurs intérêts propres. Au cours de nos missions, nous avons rencontré de nombreux projets de systèmes mutualisés qui ont échoué car l’équipe projet n’avait pas un poids suffisant par rapport à une ou plusieurs entités. Par conséquent, la roadmap leur a été imposée et ils ont perdu la maîtrise de leur produit. Il peut alors en résulter un éclatement du produit, par la création de branches qui (faut-il le préciser ?) risquent de ne jamais se rejoindre. Il peut également se produire un effondrement du produit sous son propre poids, car devenu trop complexe, trop riche pour être maîtrisé.

Exemple : nous sommes intervenus chez un acteur Internet pour auditer un portail de services multi-pays. Cette plateforme était utilisée par les différentes filiales régionales pour offrir des services en ligne à leurs clients (Webmail, partage de photos, stockage en ligne …). L’audit a été commandité car, d’une part, les coûts de maintenance croissaient de manière exponentielle et, d’autre part, le délai de déploiement d’un nouveau service d’un pays à un autre devenait trop important. Il s’est avéré que l’équipe responsable de la plateforme était toujours en position de faiblesse par rapport aux filiales qui multipliaient les demandes urgentes. Par conséquent, pour répondre aux demandes dans le temps imparti, l’équipe avait créé plusieurs branches dans l’application. Au début, ces branches étaient supposées être temporaires et l’équipe devait prendre le temps de les faire converger. Malheureusement, les demandes se succédant, le temps n’avait pas été pris et les branches sont restées. Au final, si un bug était détecté sur une branche, il fallait reporter le correctif sur toutes les autres branches et chaque nouveau service devait être mis en place sur chaque branche de manière séparée. D’où l’explosion des coûts et des délais.

Pour lutter contre ce phénomène, voici quelques préconisations permettant de rester maître de sa trajectoire d’évolution.

Mettre en place une structure de gouvernance indépendante

Il est important que la structure de gouvernance du produit soit la plus indépendante possible de toutes les entités. En effet, si cette structure est rattachée à une entité, ceci pose problème à deux niveaux. D’une part, les arbitrages que cette structure réalisera ne peuvent pas être complètement neutres vues les relations hiérarchiques en place. D’autre part, les autres entités risquent de ne pas vouloir collaborer à ce projet en le considérant comme partisan et ne servant pas leurs intérêts.

Par exemple, dans le cas d’un système ciblant des départements d’une organisation centralisée (ex. département vente par Internet et vente par boutiques) cette structure peut être rattachée à la DSI qui est transverse. Dans le cas d’un système ciblant une organisation décentralisée (organisme régionales, pays …) la structure peut être rattachée à une DSI groupe.

Mettre en place un modèle économique équilibrant les pouvoirs

La question du financement est une question importante. Effectivement, un modèle mal pensé peut donner un pouvoir trop important à une entité qui risque d’imposer la roadmap qui sert le plus ses intérêts. Le modèle économique idéal n’existe probablement pas. Cependant, le tableau ci-dessous présente les modèles possibles pour le financement des coûts de « build »[3] du produit avec une liste d’avantages et d’inconvénients pour chacun d’eux.

• Fond commun financé par les entités
  • Description :  toutes les entités (ex. pays, départements métier…) participent annuellement à un fond commun proportionnellement à un critère donné (nombre d’utilisateurs, CA …)
  • Avantages :
    • Mise à disposition d’un financement important dès le début du projet
    • La première entité n’aura pas à supporter le coût initial de construction du projet
    • Incitation à participer au projet car chacun paye même s’il ne s’en sert pas
  • Inconvénients :
    • Toutes les entités participant au fond voudront avoir un retour rapide de leur investissement ce qui peut complexifier les arbitrages et la gouvernance du projet
    • L’entité la plus importante (nombre d’utilisateurs, CA …) risque d’imposer sa loi en tant que contributeur financier majoritaire du système
    • Les entités les plus importantes (nombre, d’utilisateurs, CA …) peuvent avoir un sentiment d’injustice dans le sens où elles paient pour les entités les moins développées
• Ticket d’entrée + coûts de maintenance (ou modèle à base de licence récurrente)
  • Description : l’entité paie les coûts d’entrée pour pouvoir utiliser le système. Ce coût peut être fixe ou proportionnel à l’utilisation du système (ex. nombre d’utilisateurs effectifs). Ensuite, chaque année, l’entité doit payer une redevance pour bénéficier du support et des nouvelles versions
  • Avantages :
    • Financement progressif accompagnant une évolution et une montée en puissance progressive du système
    • Système plus juste dans laquelle chaque entité paye par rapport à ses besoins et à la taille de son projet
  • Inconvénients :
    • La première entité risque de supporter une grande partie du coût initial de construction du projet
    • Pas d’incitation des autres entités à utiliser le système mutualisé

A ces modèles, nous pouvons ajouter le principe du « pollueur-payeur ». Ce principe impose aux entités qui réalisent des demandes très spécifiques de payer les coûts associés. Ainsi, cette contrepartie financière poussera les entités à vérifier la pertinence de leurs demandes spécifiques.

4.2. Comment gérer le risque d’explosion de la complexité ?

Tous les experts informatiques s’accordent à dire que plus un système est complexe plus il est difficile à construire et à maintenir. Par conséquent, si nous manquons de vigilance sur cet aspect, notre système mutualisé peut devenir tellement complexe, qu’il n’est plus possible de le faire évoluer avec des coûts et des délais raisonnables.

Nos missions nous ont appris que l’un des facteurs qui impacte le plus la complexité d’une application mutualisée est l’accroissement de la dette technique. En effet, avec la vie du produit, il est inévitable de voir apparaître de la dette technique : obsolescence de technologies, erreurs de conceptions, erreurs de codage, atteinte des limites de l’architecture… Or avec l’augmentation de la dette technique la difficulté de maintenance et d’évolution du système mutualisé augmente. En conséquence, le responsable produit doit résister à la tentation d’allouer toute la charge de l’équipe au développement de nouvelles fonctionnalités et doit accorder du temps pour faire du « refactoring » et des évolutions techniques. D’une manière empirique, nous avons remarqué qu’il fallait accorder 10 à 20% de la charge de l’équipe afin de gérer efficacement la dette technique.

Conclusion

Un système mutualisé est un système très complexe qui doit intégrer les besoins communs et spécifiques de plusieurs clients. Ce type d’application nécessite une gouvernance adaptée qui doit s’inspirer des spécialistes du sujet que sont les éditeurs logiciels. Ceci implique d’adopter une démarche orientée produit : une organisation spécifique, une roadmap et un processus de livraison itératif et incrémental

Cependant pour mener à bien ce genre de projet, il faut accompagner la gouvernance par des pratiques d’architecture et de développement adaptées aux particularités d’un système multi-entités. Cet aspect fera l’objet du dernier article de la série.

[1] Dans cet article, les termes système mutualisé et système multi-entités seront utilisés comme étant des synonymes

[2] Pour plus de détails sur le rôle du responsable produit vous pouvez lire le livre « The Art of Product Management : Lessons from a Silicon Valley Innovator», Rich Mironov

[3] Nous n’allons pas aborder dans cet article la question du financement du « run ». En effet, nous supposons que chaque entité supporte ses propres coûts de « run ».