[Interview] Chez Transilien, l’objectif d’un SI modulaire fait de « bulles autonomes » pour mieux gérer dette et legacy

>> Cet article est extrait du carnet à télécharger Dette technique et legacy : comment les DSI des grandes entreprises accélèrent ?

Au sein du groupe SNCF, le directeur des systèmes d’information de Transilien, Frédéric Novello, mène une transformation importante : il détaille à quel point un SI modulaire, constitué de bulles plus autonomes, est de nature à apporter des réponses aux préoccupations de legacy et de dette technique des entreprises.

Que retenez-vous de notre atelier consacré aux enjeux du legacy et de la dette technique dans les entreprises ?

J’ai été étonné de voir que la période de crise que nous avons tous traversée, a provoqué une sorte de ligne de démarcation entre les organisations. Pour certaines, la prise en compte de la dette technique a été plus importante et pour d’autres non. J’ai l’impression que beaucoup de groupes ont fait évoluer dans l’urgence leur système d’information fonctionnellement pour faire face à des besoins nouveaux, à l’image de la grande distribution par exemple.

Mon expérience personnelle est différente. Il n’y a pas eu de besoins nouveaux mais une prise de conscience : les infrastructures informatiques, nos applications, notre patrimoine numérique… étaient vraiment critiques pour les processus métiers au quotidien. La pression sur les budgets est réelle et bien sûr il faut trouver de nouveaux leviers de gains.

[bctt tweet= »« Mon plus grand défi est de faire bouger les lignes sur la logique de protection du SI autour des bulles. » » username= »Alliancy_lemag »]

Mais l’on a aussi aujourd’hui une conscience beaucoup plus aiguë des processus de l’entreprise. Sur le sujet du legacy, cette situation fait qu’il est devenu beaucoup plus facile de convaincre de la nécessité de moderniser. Avant, cette préoccupation arrivait toujours au second plan, derrière l’idée de développer de nouvelles fonctionnalités, quitte à provoquer des tensions entre IT et métiers. Pour moi, l’année écoulée a ramené au premier plan la question de la dette technique. D’autant plus que, de façon concomitante, le risque cyber explose ; les obsolescences sont de plus en plus vues comme des failles. Ce changement de perception a été très visible au sein des métiers et de la direction générale. Suffisamment pour créer un momentum de transformation.

Pour autant, vous épinglez aussi le fait que la gestion de la dette technique est trop souvent simplifiée ?

Je pense que tous les DSI recherchent toujours l’optimisation. Mais ce n’est pas simple de moderniser un système d’information. D’autant plus que les SI d’aujourd’hui connaissent une croissance soutenue. Dans ce cadre, le décommissionnement est trop souvent présenté comme un totem dans l’entreprise. Il persiste la croyance qu’il est possible de moderniser facilement le SI en identifiant les composants à décommissionner et que le reste viendra mécaniquement.

Or, cela revient à se tromper de combat. Le décommissionnement n’est pas le fait générateur ; il faut une vision cible de l’architecture SI, qui ensuite permettra de décommissionner.

[bctt tweet= »« Beaucoup d’organisations surfent sur l’idée de mettre le legacy d’un côté et le « moderne » de l’autre… cela revient à renoncer à avoir un programme de transformation des architectures pour aller vers une modernité globale du SI.» » username= »Alliancy_lemag »]

Cette vision cible doit permettre de sortir d’une stratégie qui se résume bien souvent à : il y a du legacy donc il faut décommissionner. Avec derrière l’ambition illusoire de parvenir à un état « zéro legacy » qui n’a pas beaucoup de sens. Dans le même ordre d’idée, beaucoup d’organisations surfent sur l’idée de mettre le legacy d’un côté et le « moderne » de l’autre, séparément. Alors oui, cela peut être obligatoire pour certains gros systèmes transactionnels bancaires, mais dans la plupart des cas, cela me paraît être surtout une solution de facilité et un renoncement. En effet, cela revient à renoncer à avoir un programme de transformation des architectures pour aller vers une modernité globale du SI, qui permettrait d’augmenter de façon exponentielle la capacité de résorption de la dette technique.

En soi, il faut reconnaître que les entreprises créent en permanence de la dette technique au fil de leurs développements et de leurs projets. Avec quelles conséquences ?

Il est acceptable de créer un peu de dette technique, le problème est d’en arriver à créer d’importants blocs de dette qui deviennent un poids sans que l’on ne sait pas gérer. Le sujet est celui du développement continu. Pour ne pas se laisser dépasser, il faut organiser le SI en une série de bulles autonomes, indépendantes les unes des autres, afin que leurs imperfections respectives ne se diffusent pas au reste du système. On mesure alors la dette au sein de chaque bulle, en étant prêt à en admettre un certain niveau, mais pas une augmentation continue. C’est une vision cible différente du SI.

Comment parvenir à cet objectif ?

Dans cette vision, il y a déjà un intérêt énorme à s’appuyer sur le cloud, car il force de facto à limiter l’obsolescence. Pour une raison simple : l’amélioration continue mise en œuvre par le cloudeur pousse l’entreprise. De plus, si on utilise le plus possible les fonctions PaaS du cloud, alors le bénéfice est clairement une plus grande résilience du SI.
Concrètement, je suis en train de devenir full cloud sur les SI que je gère dans ma branche. Et à l’intérieur de ce modèle, il y a des parties plutôt IaaS avec des produits déployés directement par mes équipes, plutôt que d’avoir retenu des OS ou du middleware proposé par le cloudeur. Cela implique un suivi beaucoup plus fort des versionning mis en œuvre. Il est vraiment nécessaire d’avoir une métrologie affirmée pour tenir cette transformation.

À quel point un SI sous forme de « bulles autonomes » comme vous le préconisez, peut devenir rapidement une réalité ?

Cette modularité est un objectif à atteindre absolument, mais ce n’est pas facile. Pour ma part, mon plus grand défi est de faire bouger les lignes sur la logique de protection du SI autour des bulles. Les préceptes de cloisonnement traditionnel, au niveau du réseau, ne sont pas adaptés. Il vaudrait mieux des cloisonnements de niveau 7, par filtrage web pour assurer la sécurité d’un SI modulaire. Il ne s’agit plus seulement d’interdire des ports d’accès. Il faut développer une approche holistique du système d’information, avec une défense en profondeur : du firewall, des sondes réseaux, de l’IA sur le comportement applicatif… Cela revient à regarder son système de la même façon que les hackers le regardent.

Quels sont vos prochains chantiers prioritaires ?

Au-delà de ce sujet de la cybersécurité, l’autre grand chantier est la maîtrise de l’agilité à l’échelle, en mode gestion de portfolio. Cela permet de faire évoluer le SI de façon rationnelle, en évolution continue, mais tout en restant dans l’optique d’une gestion de portefeuille. Comment concilier les deux ? La méthode Safe peut aider, mais elle a été inventée avant tout pour répondre aux besoins des géants du web, pas forcément pour d’autres types d’acteurs et de produits. Il est urgent d’inscrire l’agilité dans la réalité d’un environnement industriel comme le nôtre, avec toutes ses contraintes.