[Interview] La DSI de la Maif trouve son propre équilibre « agile et cloud » face à la dette technique

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

Nicolas Siegler, directeur général adjoint en charge des systèmes d’information du groupe Maif, décrit comment utilisateurs et équipes IT ont vu leur perception des systèmes d’information évoluer ces derniers mois. Il revient également sur l’importance de gérer le flux continu de développement qui amène la dette technique dans les organisations.

Pourquoi le sujet « legacy et dette technique » que nous avons animé lors de notre atelier, a-t-il retenu votre attention ?

En soi, le sujet n’est pas révolutionnaire. Il y aura toujours du legacy dans les organisations. Et quoi qu’on en dise, nous sommes tous finalement bien contents d’hériter de ces capacités… même si ce n’est pas exactement ce que l’on aurait voulu dans le meilleur des mondes. Lors de l’atelier, on a d’ailleurs fini par évoquer beaucoup de sujets d’actualité corollaires : cloud, API, agilité, télétravail… Mais tout cela renvoie à une question intéressante : à quel point, en tant que DSI, est-on capable d’avoir une réflexion originale et différente quand il est question de dette technique dans l’entreprise ?

Diriez-vous que le rapport de la Maif avec son legacy a évolué ces dernières années ?

Si je prends le point de vue des utilisateurs, le sentiment que j’ai est qu’ils ont été amenés à passer beaucoup plus de temps à travailler à distance et que cela a changé leur perception de beaucoup d’outils existants. Quand ils étaient au bureau, ils utilisaient souvent le système d’information de façon mécanique ; depuis la crise, l’usage a changé. Cela a été l’occasion d’un regard renouvelé et souvent plus élogieux sur ce qui existait. Il faut dire que quand on regarde le chemin parcouru depuis des années dans l’entreprise, nous avons rénové beaucoup d’aspects du SI : interface « webisées », meilleure ergonomie… Cela nous a sauvé la mise quand il a fallu permettre aux collaborateurs d’être beaucoup plus autonomes.

[bctt tweet= »« Pour bien profiter du cloud, il faut entretenir sa maison fréquemment. » » username= »Alliancy_lemag »]

Le second constat, c’est que beaucoup d’utilisateurs se sont rendu compte qu’ils n’étaient pas allés au bout de beaucoup de leurs usages sur le SI. Et donc, plutôt que de demander encore du neuf, ils ont pondéré la nécessité de transformation à grande vitesse pour mieux s’emparer de l’existant. Avec un peu de recul, on se rend compte qu’en matière de legacy, les utilisateurs poussent au changement avant tout en termes d’UX et d’IHM, pas forcément sur des sujets plus profonds pour les outils. Ces différents facteurs réunis, nous avons pu constater que l’appréciation du legacy et la qualité des services augmentaient ces derniers mois.

Et du côté des équipes IT en tant que telles ?

Nous avons globalement changé notre rapport aux progiciels ces dernières années. Historiquement, la Maif aimait bien tout faire elle-même. Aujourd’hui, deux tendances émergent. D’abord, si nous continuons avec ces développements en propre, c’est en adoptant une approche compatible avec les technologies modernes, c’est-à-dire en microservices APIsés, qui ouvre des perspectives en termes d’agilité. Ensuite, nous nous sommes aussi ouverts à des solutions complémentaires en mode SaaS, mais peu sur notre cœur de métier.

Vous avez souligné dans le débat que la dette technique est à la fois un stock et un flux : comment adresser l’un et l’autre efficacement ?

La réalité, c’est qu’au-delà de ce que l’entreprise a déjà derrière elle, le stock, elle crée du legacy dès qu’elle développe quelque chose. C’est un flux permanent. Donc, la question est : comment faire en sorte de bien maintenir dans la durée ce que l’on a créé ? C’est quand on se laisse dépasser que l’on crée une dette technique qui devient contraignante. Nous assumons le fait qu’à chaque fois que nous faisons un choix sur un logiciel ou une couche technique, nous allons devoir prendre en compte cette notion de dette technique sur le long terme. Chaque technologie va vieillir, parfois rapidement, et il faudra la maintenir, tout en se disant qu’aucun choix ne sera vraiment définitif.

Le changement, aujourd’hui, vient concrètement des fonctionnements agiles. L’une de leurs vertus est de pouvoir responsabiliser une petite équipe à la fois sur le « change » et sur le « run ». Lancer de nouveaux projets, va donc de pair avec la prise en charge du patrimoine. Le principe de la responsabilisation, c’est que chaque équipe va devoir choisir comment elle investit son temps entre ces deux aspects. Quand on est clair avec les règles du jeu, c’est très positif de voir les équipes penser la problématique dans sa globalité : la qualité initiale, mais aussi le cycle de vie.

Cette mise en œuvre de l’agilité est un état d’esprit plutôt qu’une méthodologie à suivre à la lettre. Nous nous sommes beaucoup inspirés de ce qu’ont fait les pionniers comme Spotify, mais selon les besoins, nous ne nous limitons pas au « scrum », nous avons aussi du « kanban », du « lean »… L’agile master adapte les méthodes selon les besoins. Je pense que quand on a un legacy important, il n’est pas sain de vouloir jouer à la start-up qui fait de la méthode agile au pied de la lettre. Nous sommes contraints par des technologies anciennes et notre système est très intégré, avec beaucoup de flux croisés entre les composants : cette adhérence fait que la question de la synchronisation entre squads prend une dimension très importante pour nous.

Le cloud change-t-il la donne d’une façon ou d’une autre ?

Je ferais une distinction entre les différents types de clouds. Le IaaS n’a pas beaucoup d’impact : avoir des systèmes chez un provider ou chez nous ne change pas grand-chose. Concernant le SaaS, les changements sont plus importants. Pour les nouveaux outils, nous apprécions évidemment la vitesse de mise en œuvre. Mais à côté de ça, pour nos progiciels historiques, nous subissons le plus souvent le SaaS, car le marché ne bouge que dans ce sens : les montées de version des éditeurs nous laissent de moins en moins le choix. Cela amène une nouvelle réflexion sur l’intégration, car en SaaS, si l’on déporte une part de la maintenance chez l’éditeur, on gagne aussi en contraintes. Un progiciel ne vit en effet pas dans sa bulle et l’on doit en permanence vérifier que ses liens avec le reste du SI demeurent cohérents.

Sur le PaaS, c’est différent et nous sommes beaucoup plus volontaristes : nous profitons notamment des possibilités offertes sur les couches basses pour assembler des briques de socle « prêtes à l’emploi », par exemple des bases de données.

[bctt tweet= »« C’est très positif de voir les équipes penser la problématique dans sa globalité : la qualité initiale, mais aussi le cycle de vie. » » username= »Alliancy_lemag »]

La promesse du cloud sur la simplification de l’évolution et des montées de version – qui ne sont pas gratuites ! – est réelle, mais je dirais qu’elle n’est pas non plus encore complètement assumée. Aucun système ne fonctionne en stand alone. Or, c’est bien la DSI à la fin qui se retrouve à devoir assurer la cohérence globale, que certains aspects soient externalisés ou non.

Toutefois, il faut reconnaître que ces nouvelles contraintes poussent à s’occuper du sujet legacy beaucoup plus régulièrement. Pour bien profiter du cloud, il faut entretenir sa maison fréquemment. En particulier, cela permet de se rendre compte quand on est trop dépendant à certaines briques technologiques. Le bon exemple ces dernières années a été l’OS Windows : quand on est passé de changements tous les cinq ans à des évolutions tous les six mois, il a forcément fallu faire en sorte que les applicatifs soient moins adhérents au poste de travail : passer en mode client léger, être agnostique vis-à-vis du système… Ce sont des gros paliers à franchir mais qui changent le rapport au legacy pour mieux l’assumer au final. Ce découplage du legacy se pense plus largement quand on rénove dans une logique de microservice. À chaque fois qu’on le fait, on redonne de l’autonomie à nos équipes et donc de la puissance à l’agile.

Quels sont pour vous les autres défis prioritaires à relever sur le sujet aujourd’hui ?

Nous nous questionnons beaucoup sur la dépendance vis-à-vis des éditeurs. Souvent ils offrent d’excellents produits mais la relation s’est tendue avec beaucoup d’acteurs ces dernières années, du fait sans doute de la compétition grandissante, et peut-être de la facilité d’abuser d’un état de faible réversibilité au niveau technologique. Cela nous a amenés à développer un intérêt grandissant pour l’open source : aujourd’hui nous y venons de manière proactive pour ne pas nous retrouver dans des relations de dépendance excessive, et par ailleurs nous libérons en open source des briques logiciels « maison » pour contribuer au bien commun.

Le cloud est aussi un défi très intéressant car il nous pousse à monter en agilité et à nous orienter vers un SI plus modulaire. Nous sommes en train de revoir par exemple toute notre chaîne de développement pour aller soit en interne vers de la conteneurisation, soit avec le PaaS pour bénéficier des automatismes cloud sur les couches d’exploitation et d’administration. L’effort principal est alors d’investir sur les acteurs du cloud qui nous donnent la capacité à choisir et à rendre réversible ces choix. C’est un surinvestissement pour les mois à venir qui accompagne la construction de ces nouveaux socles, la montée en compétence associée et le fait d’aller chercher de nouvelles fonctionnalités en tant que telles. Point important : quand on fait le choix d’aller sur le cloud public, il faut se fixer des règles.

À la Maif, nous avons mis en place une exigence de réversibilité : on va utiliser dans les clouds publics uniquement des fonctionnalités non propriétaires, qui ne créent pas d’adhérence. C’est une discipline à avoir pour l’entreprise. Il faut faire l’exercice dès les premiers POC, essayer d’éviter les fonctionnalités « propriétaires » proposées par le provider et voir comment on peut les recréer de façon autonome. Cette réversibilité n’est jamais simple ni automatique. C’est un défi à part entière pour demain : amener beaucoup plus de standardisation et de normes communes sur le marché pour la faciliter. C’est d’ailleurs ce que des initiatives comme Gaïa-X cherchent à rendre possible.