Jusqu’où aller dans les mutualisations fonctionnelles du système d’information ?

A tout besoin d’un Métier de l’entreprise répond bien souvent une fonction SI qui possède des règles de gestion propres à ce besoin. Or un objectif de la conception informatique est de trouver des pistes de mutualisation pour réduire les coûts de développement en bénéficiant des infrastructures applicatives existantes.

L’architecte SI a pour mission d’identifier les mutualisations possibles. Mais il est confronté à des objectifs antinomiques : fondre des règles métier spécifiques dans un corpus de règles génériques. Cette quadrature du cercle est a priori sans issue. Mais vous trouverez toujours quelqu’un pour souffler la proposition : « Il n’y qu’à faire un méta-modèle ! ».

La solution : un méta-modèle ?

Un méta-système est un système paramétrable (c.-à-d. sans aucune ligne de code informatique dédiée à une règle précise) qui peut décrire tout et n’importe quoi.

Le méta-modèle est la martingale de certains architectes SI quand celle du concepteur d’application sera une application métier isolée du reste du SI pour de « bonnes » raisons : parce que le projet est spécifique, qu’il a un délai de mise en place très serré, etc.

Par expérience, et parce que moi aussi j’y ai cru, il me semble que la quête du méta-modèle est vaine, en tout cas pour une entreprise qui développe elle-même ses fonctions informatiques métier. Mais cela ne veut pas dire qu’il faut renoncer à l’objectif de mutualisation quand cela est possible. Il faut d'ailleurs noter que certaines technologies facilitent les mutualisations comme les moteurs de règles ou les moteurs de processus qui permettent de passer du code « en dur » à du paramétrage. Mais quand le paramétrage prend une forme de pseudo-code informatique - difficilement manipulable par les acteurs du Métier – la valeur ajoutée par rapport au code en dur peut être interrogée.

Mutualiser en respectant la démarcation entre les différents métiers de l'entreprise

Donc l’objectif de l’architecte SI sera de rechercher le niveau de mutualisation le plus élevé entre différentes fonctions métier, un peu comme la recherche du Plus grand diviseur commun (PGDC) en mathématiques. L’exercice peut être facile quand l’ensemble des fonctions métier sont connues… mais c’est une configuration qui se présente rarement ! En effet un SI croit par un bourgeonnement incessant de fonctions et services. Des rameaux apparaissent (évolutions, nouvelles applications) quand des branches entières disparaissent (décommissionnements, externalisations, etc.).

Prévoir un socle informatique fonctionnellement générique, fondé sur un paramétrage ad hoc, en pariant sur sa capacité à intégrer des règles métier futures, est une hypothèse risquée, source possible de désenchantement pour les commanditaires Métier. Cela est certainement dû à la fable souvent racontée sur le SI qu’il peut être construit comme une poupée gigogne où chaque poupée est une couche fonctionnelle qui vient enrichir les couches antérieures.

Mutualiser est pourtant un impératif, une préoccupation des architectes SI et de beaucoup de collaborateurs de la DSI.

Je suis souvent soumis au questionnement de deux types d’acteurs de la DSI :

1. Les concepteurs d’applications métier : « Quelles fonctions puis-je externaliser à une socle transverse du SI pour alléger la future application et son coût de BUILD, voire de RUN ? »
2. Les concepteurs des socles transverses (référentiel, BPM, fonctions digitales communes…) : « Quel service maximal rendre aux applications métier sans intégrer des règles de ces métiers ? »

Le débat n’est pas récent. Avec la SOA déjà, une telle question était posée : « Quel niveau de granularité donner à un service métier pour qu’une orchestration de services par un requérant (IHM, app, parcours…) ne relève que du métier de l’appelant et non du métier des services eux-mêmes ? ». C’est un véritable sujet d’architecture fonctionnelle qui vise à délimiter le périmètre naturel et légitime d’une application métier ou d’un socle applicatif.

Identifier les fonctions élémentaires transverses et les étendre à des cinématiques fonctionnelles génériques

Dans la démarche il faut commencer par identifier les fonctions transverses indépendantes d’un métier particulier.

La recherche de mutualisation commence ici. Ces fonctions offrent en général un service ciblé, par exemple : l’authentification forte, l’acquisition de signature électronique, la vérification d’un pièce administrative.

La DSI va être force de proposition pour mettre en place ces services communs et publics.

Une fois ces services publics établis, l’architecte SI étudie l’opportunité d’élargir leur valeur métier en les inscrivant dans des cinématiques plus larges, réutilisables au sein de cinématiques métier spécifiques.

Au plan métier, il s’agit d’établir des sous-processus qui peuvent être intégrés dans différents processus d’entreprise. L’architecte doit donc travailler en amont avec les Métiers et l’ensemble des parties prenantes des projets pour identifier des opportunités de mutualisation entre les cas d’usage métier de l’entreprise pour offrir un cas d’usage réutilisable. (Les termes « cas d'usage » et « processus » sont employés de la même façon dans cet article.)

Le risque à ce stade est d’aller trop loin dans la mutualisation et d’embarquer dans le cas d’usage transverse des règles et des données spécifiques à chaque métier utilisateur. Respecter ce principe fondamental de l’urbanisme (= attribuer à chaque métier un périmètre applicatif bien délimité) ne veut pas dire qu’il faut renoncer à spécifier un tel cas d’usage. Il faut simplement bien définir ce qui relève du cas d’usage métier et ce qui revient au cas d’usage générique.

D’une façon générale, si la cinématique applicative commune développée n’utilise que des données pivots du SI (contrat, personne, document, opération…) alors l’indépendance vis-à-vis de chaque applicatif métier semble assurée. Autre avantage.... sa maintenabilité, car sa structure est simple, lisible et robuste. L’écueil serait de céder aux sirènes du méta-modèle pour répondre à des Métiers qui veulent se « décharger applicativement » de certaines règles : la procédure générique deviendrait vite illisible, abstraite et difficilement évolutive.

Concrètement, il y a au moins 2 façons d’opérer la conception d’une telle procédure :

1. En amont, l’applicatif métier prend en charge la partie fonctionnelle de la procédure transverse qui exige des données métier spécifiques
2. La procédure générique peut appeler des API métier, sur la base d’un paramétrage simple, qui lui restitueront une information standardisée nécessaire aux fonctions qu’elle supporte

Le rôle de l’architecte SI est essentiel dans la conception des applicatifs mutualisés du SI mais ce travail est particulièrement délicat. Les pièges sont nombreux et les incertitudes élevées : céder à l’urgence des projets, l’agilité non maîtrisée, s’affranchir d’une approche conceptuelle pour une approche uniquement technique, croire en l’arlésienne du méta-système, les cas métier ne sont pas tous connus par avance, spécifications métier mal assurées, etc. Mais ne pas faire cet effort revient à accepter un SI en silos où des fonctions apparentées cohabitent, augurant d’un pilotage du SI de plus en plus complexe…

Nota : je restitue par ce billet mon expérience de la banque de détail. J’ai eu à relever de beaux challenges intellectuels dans différents domaines : les personnes en relation avec la banque (clients et intervenants indirects), pièces justificatives client spécifiques à chaque produit, offres bancaires combinées, relation distribution (1) – production (n), etc.