Gestion de l’obsolescence informatique : la dette IT doit être pilotée !
La dette des systèmes informatiques et des parcs informatiques est souvent sous-estimée ou tout simplement ignorée par les DSI et les entreprises. Pourtant la gestion de l’obsolescence du SI est un enjeu majeur dans un environnement en constante mutation. Il est donc primordial d’accompagner dans le temps ce phénomène pour ne pas se retrouver à devoir gérer une dette colossale. Les entreprises n’ont alors d’autres choix aujourd’hui que de rester en mouvement et de maintenir à niveau l’ensemble de leur SI. Mais c’est une démarche complexe car elle demande une approche transversale de l’entreprise. Remi Ruiz, consultant technique, nous brosse le portrait détaillé de cette dette technique, nous permettant ainsi de mieux appréhender les enjeux liés à la gestion de l’obsolescence du SI.
Pouvez-vous nous donner votre définition de la gestion de l’obsolescence ?
La dette technique, et l’obsolescence du SI en général, est une métaphore qui est inspirée du concept de la dette financière. Il a été appliqué au développement logiciel, puis à l’informatique en général. Elle représente un ensemble d’activités qui vont devoir être effectués pour compenser la mauvaise qualité des livrables, des choix techniques, et l’obsolescence du SI qui engendrent des risques et des coûts supplémentaires. Concrètement, nous parlons d’obsolescence ou de dette technique lorsqu’une entreprise rencontre des difficultés à faire évoluer les composants de son SI. Et à l’image d’une véritable dette au sens financier, il va être nécessaire de la rembourser à un moment ou un autre.
Quels sont les domaines couverts par cette gestion de l’obsolescence ?
Historiquement la notion de gestion de l’obsolescence était très orientée développement et code. Aujourd’hui elle est beaucoup plus globale et vise de nombreuses catégories. Il existe ainsi la dette d’infrastructure, c’est-à-dire des socles obsolescents qui gèrent des limites de maintenance, des coûts de support, d’exploitation ou de licences supplémentaires. Il y a également la dette d’architecture, c’est-à-dire de la structure et du design des plateformes avec des applications peu modulaires, fortement couplées avec des dégradations de performances et de fiabilité.
La dette technique est donc essentiellement technologique ?
Non elle n’est pas que « technologique » puisqu’elle inclut également la dette humaine, qui engendre des problèmes de compétence avec des connaissances non documentées, perdues, des expertises introuvables. Il faut aussi évoquer la dette du code, qui vise la qualité même du code à cause de mauvaises pratiques, ou des négligences comme l’oubli de revu de code par exemple. Enfin la dette qualité visant les tests qui touchent la qualité des livrables, avec des tests incomplets ou une mauvaise couverture du domaine fonctionnel. Ce qui va amener à ne pas détecter les défauts et à considérer à tort que les livrables sont fiables. Toutes ces catégories montrent que la gestion de l’obsolescence touche l’ensemble du SI.
La dette technique est-elle forcément « subie » ?
La dette technique peut être considérée comme visible, car connut des utilisateurs, des clients ou par l’entreprise en général. Elle peut également être invisible et fait référence à des problèmes inconnus. Dans le premier cas on parle alors de dette « délibérée », « intentionnelle » ou « volontaire ». C’est-à-dire que l’entreprise en a connaissance et qu’elle veut en assumer les conséquences ultérieurement. Elle répond à un besoin présent, comme la rapidité par exemple. Le fait d’en avoir conscience permet de limiter le risque de cette dette et de prévoir un remboursement de celle-ci. La dette invisible quant à elle, ou dette involontaire est liée à des erreurs, un manque de connaissances ou une mauvaise conception. Elle est accidentelle, et apparaît souvent à la fin d’un projet. Son impact et les risques qui lui sont associés n’ont pas été anticipés.
Quelles sont les causes de la dette technique ?
Elles peuvent être très nombreuses. Par exemple la cause peut être liée à un budget trop limité dans un projet, ou des pressions de la direction sur les dates car il faut livrer le produit rapidement. Mais elle peut être également liée aux équipes concernées. Qu’il s’agisse d’équipes d’architectes ou de développeurs, la pression va les obliger à se diriger vers des solutions plus rapides ou plus faciles, mais moins poussées en matière d’études. Elle engendre une vision à court terme avec une solution qui fonctionne certes mais sans réellement pousser la réflexion sur les conséquences futures. Le problème peut aussi provenir des intervenants même du projet, avec un manque de savoir et de compétences, la sélection des membres de l’équipe n’étant pas en adéquation avec le besoin du projet. Enfin il ne faut pas non plus sous-estimer la complexité d’un projet, en définissant une solution d’architecture trop simpliste par exemple. Ou au contraire sur évaluer un projet, en faisant une usine à gaz d’un projet dont le besoin initial était relativement simple.
Comment gérer l’obsolescence de son Système d’Information ?
Les entreprises ne doivent pas investir uniquement dans des nouveaux besoins sans se préoccuper de son SI. Il ne faut pas le laisser vieillir et oublier de pérenniser l’existant. Il est important de développer une véritable culture de la gestion de l’obsolescence au sein des processus de l’entreprise. Sans cela la dette technique ne fera que croitre. Et il est illusoire de se dire que la société va se donner 3 mois pour effacer sa dette technique, par exemple. La résolution de la dette technique doit se faire petit à petit, en faisant un listing de l’existant, en mettant en lumière ce qui ne va pas, et quels moyens dois-je mettre en œuvre pour mettre en place un plan de réduction de cette dette.
Il est important de développer une véritable culture de la gestion de l’obsolescence au sein des processus de l’entreprise
Vous souhaitez échanger avec nos experts autour de vos enjeux et de la gestion de l’obsolescence, c’est par ici !
