Dans une transformation de système d’information, il est nécessaire de savoir ce que l’on veut apporter pour suivre le cap, mais aussi de savoir ce que l’on veut garder pour arriver à bon port.
Qu’est-ce qu’un invariant de transformation ?
Appelons invariant ce qui ne doit pas changer dans le processus transformation. L’invariant peut avoir une cause interne : défendre un code de conduite, renforcer une règle de fonctionnement, maintenir une interface fixe entre des systèmes, maintenir l’expérience des utilisateurs, adresser une contrainte d’infrastructure… L’invariant peut aussi venir de l’extérieur : le respect d’une réglementation, la conformité à un contrat, le branchement à une interface à la main d’un partenaire, … L’invariant peut être vu de façon positive comme un principe structurant avec la valeur attachée, ou comme une contrainte, donc de façon plus négative.
Peut-on se passer de traiter les invariants ?
Les invariants de la transformation sont là et existent d’une façon ou de l’autre. S’ils n’ont pas été explicités, alors ils vont venir de façon implicite ! Par exemple, on peut avoir des attentes cachées comme la rétrocompatibilité ou la reprise de l’existant. Les invariants implicites posent problème dans le pilotage de projet . Ils sont hors du radar, n’étant pas dans l’espace du problème. N’étant pas ou peu spécifiés, il est difficile de connaître le niveau d’atteinte. L’attente d’iso-fonctionnalité est un bon exemple de ces invariants implicites. Si elle peut être formulée clairement et rapidement, elle demeure implicite dans la mesure où elle est rarement spécifiée. Un invariant implicite n’est pas une exigence. Cela pose des difficultés dans la phase de qualification.
De façon encore plus problématique, ces « invariants implicites » peuvent aller contre les objectifs de la transformation en forçant en refaire l’existant en mieux (plus moderne, plus esthétique, …) sans apporter une valeur durable. Il faut bien se demander en quoi refaire l’ancien va avoir un vrai impact. La sortie d’obsolescence est plus une migration qu’une transformation. Donc, au lieu d’ignorer et subir les invariants pour se retrouver face aux « mauvais » à la fin, ne vaut-il pas mieux expliciter et protéger les « bons » invariants au début ? Par « bon » invariant, on entend celui qui préserve la proposition de valeur de la transformation et par « mauvais », celui qui la dessert.
Pourquoi en parle-t-on aussi peu, au final ?
Les invariants de la transformation devraient vite faire l’objet d’attention dans le programme de transformation. D’une part, on a plus de temps pour les identifier et mettre en place les mesures pour les protéger au tout début quand vers la fin, où sous la pression de l’échéance, il faut faire « atterrir » le programme, « quoi qu’il en coûte ». D’autre part, ils posent des questions difficiles qui amènent à s’interroger sur des ambiguïtés de l’organisation. Comme disait le cardinal de Retz, on ne sort de l’ambiguïté qu’à ses dépens. Ces questions auront forcément des réponses lors de la mise en production, mais pas forcément, celles que l’on souhaite ! Qu’elles sont donc ces questions délicates? Garde-t-on en l’état le processus métier ou alors le décidons-nous de le faire évoluer ? Conserve-t-on l’organisation, ses règles de fonctionnement et les pouvoirs existants ? Avons-nous établi le périmètre impacté et le partagé à les parties prenantes concernées ? Avons-nous un dispositif et un budget de fonctionnement capable de poursuivre le projet au-delà de sa mise en production ? Avons-nous pris en compte les parties du SI à défaire suite au programme ? A ce moment-là, il peut arriver que l’on identifie des contraintes tellement importantes que la transformation peut sembler impossible ou sans apport de valeur. Si nous n’avons pas « négocier » les invariants pour les mettre en accord avec la transformation, alors ces invariants se rappelleront à notre bon souvenir lors de la mise en production, jusqu’à éventuellement la bloquer. On peut certes avoir un « agenda caché » et mettre les parties prenantes devant le fait accompli. Mais une telle démarche n’est pas propice à la coopération et sans coopération, il est difficile de faire une transformation !
Pourtant, malgré leur importance, on parle rarement des invariants dans les programmes de transformation. Le focus porte sur la nouveauté qui arrive. Quand la bascule est vue comme une affaire de seconde zone ou de fin de chantier, alors la situation suivante arrive souvent: la nouvelle solution est prête à être intégrée dans le SI et le SI n’y a pas été préparé. Comme pour une opération de greffe, une certaine compatibilité entre le greffon et le receveur est nécessaire au succès de l’opération. Si le receveur, le SI, n’est pas préparé, alors la greffe avec la solution, va être difficile. On peut même assister à des « rejets de greffe », dans les cas les plus difficiles. Ce phénomène de greffe difficile se produit régulièrement quand la bascule n’a pas été imaginés dès les phases amont. La séparation entre les équipes en charge du programme et celles du SI existant une situation propice à une concurrence malsaine. Si en plus il existe une séparation entre l’équipe de fabrication et l’équipe de maintenance du programme, alors les risques d’atterrissage difficile se multiplient.
Transformer le système socio-technique
Transformer un SI, c’est aussi transformer une organisation car la digitalisation a fait de l’organisation un système socio-technique, là où avant les deux systèmes, humain, et informatique, fonctionnaient de façon autonome. Ce n’est donc pas une simple affaire de code. L’impact se fait sentir déjà dans les équipes de la DSI : de nouvelles compétences techniques, une accélération du rythme des évolutions, de nouvelles méthodes de management et d’organisation, une dette technique qui pèse de plus en plus, … Puis l’impact se propage encore plus fort, sur le métier qui va logiquement s’emparer des apports du SI pour dérouler sa stratégie et améliorer sa performance. Derrière ses mots angéliques, il y a de dures réalités avec des postes qui disparaissent et des personnes qui vivent des changements difficiles. C’est à se demander parfois pourquoi le métier n’est pas toujours demandeur de transformation de son SI !
Donner-moi un point fixe et un levier et je soulèverai le … SI
Pour appliquer une transformation sur un système, nous avons besoin d’un pivot. N’est-ce pas un certain Archimède qui prétendait soulever le monde à condition de lui fournir un point fixe et un levier ? Et bien, toutes proportions gardées, c’est la même chose pour le SI. Il nous faut un point fixe, les invariants, et un levier, le modèle opérationnel de la bascule pour appliquer la transformation avec fluidité et maîtrise !
Surfer sur les vagues
La maîtrise des invariants permet de contrôler l’impact de la transformation du SI sur l’existant mais aussi de faire la chasse aux coûts cachés. Tout changement va amener sa complexité. Chaque lot va créer une vague de complexité. La contrainte est de maîtriser la complexité totale du SI pendant l’opération et ne pas aller dans la zone chaotique. Il faut donc rationaliser après chaque lot. La fin de chantier de la transformation est une étape importante pour que la promesse de valeur de la transformation ne soit pas contrarié par l’entropie pouvant rester après le projet.
Pour bien surfer sur la transformation du SI, ayant à l’œil les bons invariants !