Gouvernance
Dette technique ou patrimoine : une question d’équilibre avant tout
Par François Jeanne, publié le 25 octobre 2022
Un vrai enjeu de performances du SI
Positifs ou pas, évoquant les infrastructures ou le soft, les termes – dette technique, patrimoine applicatif ou encore legacy – ont beau varier, ils recouvrent une même réalité pour la quasi-totalité des DSI. Et elle est colossale ! La nouveauté, c’est de la voir mieux assumée, affrontée aussi, et avec toujours plus de méthode. Sur les axes organisationnels, économiques ou encore techniques, la gestion de la dette s’organise, pour trier le bon grain de l’ivraie. Et les DSI s’inscrivent désormais moins dans le rejet automatique de « l’ancien » que dans une réflexion permanente entre la nécessité d’innover et celle de préserver les investissements passés.
Est-ce une course perdue d’avance ? « La dette technique est inexorable, parce que le marché et les offres techniques évoluent plus vite que nous », résume Jean-Baptiste Courouble, DSI de l’Urssaf Caisse Nationale (voir encadré). « Il n’y a pas une seule entreprise, un seul client, qui n’ait à affronter des problèmes de legacy. Cela concerne bien sûr les environnements mainframes ou AS/400, mais aussi, désormais, les serveurs virtualisés et même la containerisation », renchérit Gabriel Ferreira, directeur technique France de l’éditeur de solutions de stockage Pure Storage.
Une dette inexorable, un nœud coulant
Chez BMC Software, Frédéric Le Saux, solution engineering SEMEA, donne dans l’image : « La dette technique, c’est un nœud coulant. Ce qui coûte cher, c’est de rénover le code, mais si on ne le fait pas, les frais de maintenance augmentent. Il faut donc trouver un juste équilibre entre stabilité et agilité. Mais d’une façon générale, les entreprises ne jettent pas assez, ni assez vite. »
C’est aussi parce que leurs applicatifs les plus anciens, potentiellement dans des environnements « historiques » également, ont accumulé, parfois dans le désordre, des quantités de règles métiers sur lesquelles il devient difficile d’intervenir sans menacer cette fameuse stabilité. « Nos applications ont beaucoup bougé avec le temps. Ce sont elles qui atteignent leurs limites plus que nos serveurs. Elles sont devenues des monstres logiciels coûteux à maintenir en l’état », confirme Fabrice Couvreux, directeur des Solutions Energy chez Bolloré Transport & Logistics (voir son témoignage dans le dossier). « Chaque pansement que l’on met sur l’existant crée aussi du legacy et de la dette future », complète Chad Routh, analyste principal chez Forrester.
De la méthode, oui, si on a le temps
À l’inverse, continue le consultant, les sociétés les plus matures enlèvent de la dette avec méthode. Bonne nouvelle au passage, il existe une véritable filière scientifique sur le sujet et le terme de dette technique, à l’occasion d’une recherche sur le site de l’IEEE par exemple, renvoie à de nombreux articles universitaires. On peut en retenir que la dette s’analyse sur 14 axes, pas un de moins. Et quelques maximes bien venues, à défaut d’être originales : « Pas de dette, c’est de l’immobilisme, il faut trouver le juste milieu et accepter d’en créer, à bon escient. »
Cela nous ramène généralement à deux conclusions : d’abord, il y a dette et dette (bonne ou mauvaise). La bonne dette s’appelle patrimoine. Et ensuite, ce patrimoine n’est pas dans les infrastructures, qui évoluent dans le temps, mais bien dans les applicatifs et dans les bases de données.
Trois axes de travail : organisationnel, économique et technique
Il faut donc d’abord connaître cet existant logiciel, avant d’envisager de le moderniser, sur place ou à emporter dans le cloud par exemple. « L’analyse devrait être permanente, conseille Laurent Coutellec, responsable du pôle Transformation SI de Hardis Group, éditeur de logiciels très connus dans le monde AS/400. Si ce n’est pas fait, il devient difficile de répondre à ceux, dans les directions métiers, qui exigent des changements, parfois inutiles. »
Un point fait consensus : la valeur est dans l’algorithmique fonctionnelle et dans la modélisation des données. Sans compter les architectures et autres socles techniques, après (re)urbanisation. « Puisque la dette est un sujet permanent, je dois m’interroger en permanence : ce que je laisse est-il durable ? », se questionne par exemple Olivier Biton, DSI de LCL.
Parmi les éléments de cette durabilité, la dépendance aux fournisseurs vient bien sûr en bonne position. Avec une dimension économique, mais pas seulement. « C’est plutôt un équilibre qu’il faut chercher, en gérant par exemple très finement les fins de support sur certaines versions de logiciels, grâce au CMDB. Si vous vous laissez surprendre, c’est un coût considérable. À l’inverse, si vous pouvez mener à bien une évolution applicative demandée par les métiers en changeant à l’occasion de version, c’est beaucoup plus positif. »
La même logique prévaut quant à la réécriture de parties du code. Il y a certes toujours des grandes migrations, mais certains projets-catastrophes (médiatisés) ont refroidi les ardeurs.
Des kpi orientés time-to-value ou time-to-react
L’heure serait plutôt à la recherche des justifications de l’action de la DSI sur son existant. Quel inventaire dresser quand on arrive en poste, pour ne pas se voir reprocher l’état du SI quelques mois plus tard ? Et surtout, comment mesurer objectivement le travail accompli et la performance du SI qui en découle ? Jean-Baptiste Courouble y réfléchit justement ces temps-ci, à l’occasion de son prochain schéma directeur : « En l’absence d’objectifs business dans notre activité, nous pouvons mettre en avant des KPI qui prennent en compte la vitesse de réaction de la DSI face aux demandes des métiers. Et démontrer qu’entre une dépense a minima et une dépense qui inclut des travaux de rénovation du patrimoine, ce KPI s’améliore. »
Sur le plan technique aussi, il faut s’organiser. Dans des mondes anciens où les approches agiles ou DevOps, et les technologies open source, voire l’hébergement dans le cloud (encore timide…) ont fini par avoir droit de cité, tout semble désormais possible. À condition de mettre en place une veille active pour saisir les opportunités. Gabriel Ferreira en est persuadé : « Les DSI sont dans des budgets contraints pour gérer leur patrimoine. Ils doivent être créatifs et se montrer disruptifs sur le plan technologique pour gagner la partie. »
Les acteurs de l’IT se font aussi les apôtres de ces nouvelles approches plus ouvertes. Tous intègrent des composants open source à leurs solutions et assurent de leur bonne foi. Finie l’obsolescence programmée des versions de logiciels auxquels on ne pouvait se soustraire. Les communautés open source sont là pour faire contrepoids. Sauf que, précise Christophe Negrier, VP Technology Oracle Europe du sud, « cette liberté a aussi besoin d’industrialisation, de passage à l’échelle, de sécurisation, de niveaux de service garantis ». Donc d’un éditeur, CQFD ?
Gestion de la dette et sobriété numérique, ils vont si bien ensemble
Il est en tous cas frappant d’entendre tous ces acteurs entonner le refrain de la sobriété numérique, expliquant que la pression des politiques RSE a fini par atteindre les DSI. « Il faut de l’écoconception pour éviter de jeter le matériel de stockage à chaque fois », dit Gabriel Ferreira. « Le numérique responsable progresse, renchérit Christophe Negrier. Les DSI sont revenus en grâce dans les Comex après les épisodes de confinement. Ils ont une fenêtre de tir pour travailler sur l’existant en ne cédant ni à l’immobilisme, ni aux sirènes du changement à tout prix. Mieux en ligne avec leurs métiers, ils peuvent partager avec eux sur la question de la durabilité des applications ou sur le cycle de vie des données. D’ailleurs, dans les entreprises les plus avancées, le cloud est un soutien à l’innovation plutôt qu’à la réduction des coûts. »
Chez Deloitte conseil, Eric Delgove, senior technology partner, abonde. « Les DSI acceptent de mieux en mieux l’idée de la simplification. Ils ont aussi démontré pendant la crise leur capacité de résilience. Cette assurance retrouvée leur permet d’aborder avec confiance des sujets comme la frugalité informatique. »
« Au final, conclut Chad Routh, il existe plusieurs façons d’envisager la dette technique, mais malgré tous les efforts, elle ne disparaîtra pas. » Il faut en revanche la traiter et « l’objectif de la DSI doit être de s’assurer que les plateformes technologiques soutiennent des organisations qui veulent pouvoir changer rapidement ». La question est donc moins de tout changer à tout moment, que de changer au bon moment, et ce qui doit l’être pour améliorer l’existant. En ce sens, le nouveau regard des DSI sur la dette informatique, qui métisse un activisme raisonnable, le respect des acquis et des notions plus subtiles de sobriété et de durabilité, change progressivement la donne. Cela prendra du temps, mais après tout, quand on dépense autant sur un tel sujet, il mérite bien qu’on en passe un peu dessus.
Quarante ans de réglementations dans le SNV2 des Urssaf
Cela fait près de quarante ans que le SNV2, application centrale des Urssaf, a été développé en Cobol et pour des environnements mainframes. « Mes prédécesseurs ont fait l’effort de bien isoler les accès aux bases de données et aux moniteurs transactionnels. Je les en remercie tous les jours », apprécie Jean-Baptiste Courouble, DSI de l’Urssaf Caisse Nationale. Car cette architecture agnostique a permis l’abandon ultérieur des mainframes pour passer d’abord à Unix, puis à Linux et aujourd’hui à des serveurs virtuels. Cela garantit aussi une grande liberté d’action avec les fournisseurs. « C’est important quand on a douze millions de lignes de code à gérer.
« Mes prédécesseurs ont fait l’effort de bien isoler les accès aux bases de données et aux moniteurs transactionnels. Je les en remercie tous les jours », apprécie Jean-Baptiste Courouble, DSI de l’Urssaf Caisse Nationale
Nous ne pouvons pas fiabiliser en dépendant sans cesse de nouvelles versions, de rachats, d’abandons de technologies. » Fiabiliser ne signifie pas immobilisme. Si l’application centrale contient 40 ans de réforme et ne peut être migrée en totalité, il y a sans cesse des morceaux de code à réécrire, une réflexion sur l’architecture, de nouvelles applications et services à lancer. « Les API nous donnent les accès au code bunkerisé et de l’interopérabilité. Et le recours à l’open source est devenu un standard de travail pour nos équipes. » Même si Jean-Baptiste Courouble fait particulièrement attention à la dynamique des communautés autour des composants retenus : « Je ne voudrais pas que mes successeurs me voient plus tard comme le créateur de la dette qu’ils auraient à gérer. »
Moderniser oui, mais pas sans réflexion
« J’ai pu avoir tendance à vouloir tout changer pour des technologies plus modernes quand j’arrivais dans de nouvelles sociétés avec des existants informatiques datés. » Florence Devambez, DSI chez le spécialiste de l’assurance pour les entreprises Albingia, le reconnaît volontiers, elle a évolué. « Lorsqu’un patrimoine est stable, mieux vaut le sécuriser et comprendre ce qui fait sa valeur. » Cela ne l’empêche pas de commencer, lorsqu’elle arrive dans une nouvelle entreprise, par un audit axé d’abord sur la sécurité. « Je passe ensuite aux infrastructures, aux applicatifs et enfin au ressenti des utilisateurs. Les alarmes qu’ils font remonter sont importantes. » Dans les environnements IBMi qu’elle doit gérer, il y a souvent des millions de lignes de code. Pas question de procéder à un rétro engineering de masse. Les opérations ciblées en revanche sont possibles : ainsi « nous changeons actuellement toute l’éditique, un sujet particulièrement important dans le monde de l’assurance ». Pas de dogmatisme donc. « Par exemple, pendant le confinement, un développeur a pris l’initiative de développer une GED maison en Visual Studio et C#. Quand je suis arrivée quelques mois plus tard, je me suis dit qu’il allait falloir la remplacer par une solution du marché. Mais après analyse du vécu des utilisateurs, j’ai préféré garder cette solution parfaitement adaptée, en la sécurisant sur le plan technique et en anticipant sur le prochain départ à la retraite de son concepteur. »
