Malgré une prise de conscience de plus en plus importante dans les entreprises et administrations, les risques liés à l’obsolescence & modernisation des systèmes informatiques et digitaux sont encore trop souvent sous-estimés par des décideurs – et ce malgré les efforts des Directions informatiques.
Considérée comme couteuse, chronophage et dévoreuse de ressources, la gestion de l’obsolescence du système d’information (et des récents investissements digitaux !) est pourtant un enjeu majeur car elle permet de se prémunir contre des risques critiques (accès aux données, disponibilités des services, cybersécurité, etc.)
Il est donc primordial de piloter ce phénomène pour ne pas se retrouver à devoir gérer brutalement une dette importante.
Abordée avec méthode et régularité, cette démarche – complexe car elle demande une approche transversale de l’organisation – passe progressivement du statut de contrainte à habitude puis bonne pratique.
Comment définir l’obsolescence informatique ?
A l’origine utilisée plutôt dans le monde du logiciel (voir cet article de Wikipedia) pour évoquer l’évolution des différentes fonctionnalités et introduire des notions comme la rétrocompatibilité, l’obsolescence a peu à peu englobé l’ensemble des aspects d’un système d’information et est devenue une métaphore inspirée du concept de dette financière.
Elle est constituée de l’ensemble des actifs digitaux dont le maintien en opérations constituent un risque significatif ; son périmètre peut donc être très large, et toucher le matériel, le logiciel, le middleware, les supports de stockage (voir le Musée des supports obsolètes pour avoir aperçu de l’état d’obsolescence de chaque type de support d’enregistrement de l’information – quelle soit musicale, vidéo ou informatique), les méthodes / pratiques, les ressources humaines – voire la culture . Quelques exemples : perte de compétences, documentation non mise à jour, maintenance indisponible entraînant l’absence de correctifs, technologies en fin de vie, pratiques ou méthodes remplacées par d’autres plus répandues ou considérées comme plus efficaces.
Elle peut-être visible, voire choisie : on parle alors de dette « délibérée », « intentionnelle » ou « volontaire ». C’est-à-dire que l’organisation en a conscience et qu’elle est (plus ou moins) prête à en assumer les conséquences ultérieurement. Elle répond à un besoin présent, comme la rapidité ou les coûts ou la valeur produite. 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, ou dette involontaire est liée à des erreurs, un manque de connaissances, un facteur hors de contrôle ou une mauvaise conception. Son impact et les risques qui lui sont associés n’ont pas été anticipés.
Plus largement, nous évoquons l’obsolescence ou la dette technique lorsqu’une organisation rencontre des difficultés à faire évoluer naturellement les composants de son système d’information. Et comme une dette au sens financier, il va falloir la rembourser tôt ou tard ! une dette bien gérée ne pose pas de difficulté, au contraire d’une dette hors de contrôle qui peut mener à des graves difficultés.
Les organisation devant aujourd’hui rester en mouvement permanent, cela implique une mise à niveau très régulière de leur SI : plus l’environnement change, plus la dette arrive vite et pénalise ceux qui font le choix d’un rythme plus mesuré que leurs concurrents.
Quelles en sont les causes ?
Elles sont bien évidemment multiples, chacune contribuant à un degré divers et selon les organisations à faire grossir la dette. Pour une meilleure lisibilité, nous distinguons habituellement deux grandes types :
Les causes dites exogènes, car plutôt externes à l’organisation ; cela concerne :
- le passage du temps en lui-même : vieillissement des actifs et des ressources, usure, évaporation naturelle des connaissances. Inexorable mais anticipable !
- la politique commerciale et/ou industrielle des fournisseurs : arrêt ou évolutions de produits / services, rachats/ventes d’une activité, disparition. Des stratégies adaptées permettent de minimiser ces changements sur lesquels nous ne pouvons avoir de prise directe.
- l’évolutions des régulations, des normes pouvant rendre rapidement un système obsolète car compliqué à faire évoluer pour diverses raisons ; mais l’on rejoint ici des causes endogènes (architecture, choix technologiques, capacité des équipes, budget…) : voir ci-après.
- l’évolution des pratiques, des technologies, des menaces, des besoins clients ; ici, choisir de ne pas évoluer au même rythme signifie commencer à perdre du terrain – d’abord de manière peu visible ; le rattrapage nécessaire sera d’autant plus douloureux et couteux que les années sont passées.
Les causes endogènes, propres à des choix (ou non choix), qu’ils soient quotidiens/opérationnels ou stratégiques, délibérés ou non :
- prise de conscience insuffisante de l’impact à long terme de choix actuels ; l’obsolescence future est à la fois évoquée et pris en compte dans les décisions (cf l’argument souvent mis en avant de « l’évolutivité »), tout en étant finalement peu mise en œuvre opérationnellement ; l’évolutivité perçue peut même avoir un effet contre -productif en poussant à ne pas investir régulièrement, la solution étant évolutive (sans que personne ne sache véritablement ce que cela recouvre).
- un financement inapproprié – que ce soit en phase de build (provoquant donc des choix repoussant à « plus tard » des tâches ou livrables, et abaissant la qualité) ou en phase de run (diminuant les évolutions, la maintenance préventive, la surveillance) – a un impact direct à moyen terme. Il est tentant bien sûr, les gains espérés étant eux de court terme. Globalement, l’équilibre financier global de ce type de décision reste défavorable mais ce n’est pas souvent la priorité du moment (attention en particulier aux phases de cost-killing ou de vente d’une activité).
- des délais trop serrés peuvent aussi conduire à des raccourcis ou des quick-wins qui n’en sont en fait pas : conception incomplète, perte de qualité due à des tests trop rapides, documentation insuffisante, transferts de compétence bâclé ou absent : quelle que soit l’équipe, la pression va inciter à se diriger vers des solutions plus rapides ou plus faciles mais qui seront probablement moins poussées ; certes, la solution construite fonctionne mais qu’en sera t il dans 3 à 5 ans lorsque les équipes et la technologie auront changé ?
- compétences et organisation inadaptées : la dette peut aussi provenir des intervenants même du projet, avec un manque de savoir-faire et de compétences, la sélection des membres de l’équipe n’étant pas en adéquation avec le besoin du projet. Une organisation, des méthodes, des outils en décalage avec les besoins peuvent générer des zones d’ombre dans un projet, entraînant des difficultés menant à une obsolescence accélérée.
- Enfin il ne faut pas non plus sous-estimer la complexité d’un projet, d’une solution, d’une technologie – dans les deux sens : en définissant une solution d’architecture trop simple ou au contraire surévaluer un besoin (effet « usine à gaz »). Une connaissance approfondie et un challenge adapté des besoins permet de limiter ces halos.
- Adoption trop rapide ou trop lente de technologies nouvelles : dans un cas, elles peuvent ne pas délivrer toutes les promesses attendues (obsolescence ultra-rapide à la clé), dans l’autre être quasi obsolète lors de leur entrée dans l’organisation (avec un passage quasi immédiat en gestion d’obsolescence).
- La dépendance à des solutions insuffisamment répandues ou diversifiées (niveau de concurrence, choix technologiques alternatifs) est un accélérateur de la constitution de la dette et un frein à l’élaboration de scénarios de gestion. Ce type de choix ne fait sens que lorsque la valeur ajoutée produite est largement supérieure à la valeur actualisée des investissements à réaliser dans le futur pour changer cette solution.
Quels sont les domaines couverts par la gestion de l’obsolescence ?
Le pilotage de l’obsolescence représente l’ensemble des activités qui vont devoir être effectuées pour, dans un premier temps, identifier, remédier puis prévenir le vieillissement non maîtrisé.
Car, comme le temps, ce dernier est inéluctable : il demande donc de l’anticipation, en particulier dans un monde globalisé, interconnecté, et en perpétuelle évolution ; s’il pouvait être envisagé il y a encore quelques années, le « figeage » d’une partie significative d’un SI est devenu aujourd’hui quasi impossible : tout change en permanence et ne pas évoluer signifie être rapidement dépassé.
S’étant affranchie de son origine liée au développement applicatif, la notion de gestion de l’obsolescence doit être abordée de manière globale ; pour parler dette, il en existe de multiples facettes ; en voici quelques exemples :
- infrastructure (systèmes, réseaux, stockage, outils), qui génère des limites de performance, disponibilité, maintenance et sécurité. Sans compter une complexité grandissante, la difficulté de trouver des ressources compétentes sur des technologies anciennes, des coûts de support, d’exploitation ou de licences supplémentaires.
- applicative : applications abandonnées par leur éditeur, modèle économique freinant les montées de version (rachat de licences pour passer de la v1 à la v2 sans véritable besoin si ce n’est l’arrêt de la v1 par l’éditeur), applications « in-house » peu ou mal documentées, savoir-faire perdu.
- middleware : c’est probablement l’une des plus sournoises, car très enfouie (système de gestion de base de données, petits logiciels devenus indispensables, bus d’échanges de données critiques, systèmes d’échange avec l’extérieur, frameworks logiciels, etc.) ; ils fonctionnent le plus souvent sans être visibles, on les oublie donc alors que leur mise à jour peut être particulièrement complexe et leur arrêt perturber une partie importante de l’organisation.
- architecture : conceptions anciennes, peu modulaires, langages désuets, applications fortement couplées, etc… sont autant de sources de dégradation de fonctionnalités, de performances et de fiabilité.
- méthode / outils : l’emploi de méthodologies datées ou inadaptées (conception, gestion de projet, product design, opérations mais aussi gestion budgétaire et financière), renforcé par l’usage d’outils anciens peut mener à des lenteurs d’évolution et/ou des décisions prises trop tardivement ou à contre-sens. La qualité du code, documentation/spécifications, paramétrage/installations – en bref des livrables – est clé pour l’avenir : cela doit être vérifié par des tests réguliers, idéalement automatisés (code, pentests, …) pour pouvoir les jouer de manière systématique à chaque évolution – même mineure. La non détection (ou non traitement) de défauts alimente la dette technique.
- compétences : particulièrement dans le domaine informatique et digital, la gestion des compétences et des organisations est un domaine clé : identification et maintien des savoirs faires clés, acquisition et renouvellement des connaissances, mise à jour de la documentation, inventaire/sourcing des expertises, équilibre entre nouveauté et maturité, entre internalisation et externalisation, partage intergénérationnel (les collaborateurs les plus jeunes s’intéressant aux technologies matures, et inversement), place laissée aux formations (et surtout à l’auto-formation et à des labs pour ceux qui le souhaitent).
Quelles pratiques mettre en œuvre ?
Notre expérience du conseil technologique et organisation pour le compte de clients aux profils très variés (de la TPE au Grand compte, en passant les organisations gouvernementales ou des start-ups) a permis l’émergence au sein de notre Cabinet de bonnes pratiques que nous partageons ci-dessous ; ici, pas de recette magique ni de solution miracle ! il s’agit essentiellement d’un travail de fond, régulier, et méthodique – épaulé par l’allocation d’un niveau suffisant de compétences et ressources :
- simplicité : même si elle parfois nécessaire, la complexité doit être justifiée et son choix parfaitement éclairé. Il suffit parfois de supprimer ou limiter les ambitions d’un cahier des charges ou une expression de besoin pour réduire la grandement. Des mots d’ordre simples et appliqués avec discernement comme KISS (dans son interprétation « Keep It Super Simple »), ou l’application d’une méthode aussi fondamentale que « MoSCoW » (Must, Should, Could, Wish) permettent d’éviter des dérives préjudiciables et créatrices de dette.
- sobriété : nous l’avions évoqué dans notre ITx Café #7 intitulé « Pour un numérique plus sobre », l’usage mesuré des technologies digitales a aussi la vertu de limiter la complexité de leur évolution future et limiter leur vitesse d’obsolescence : moins entraîne plus, à savoir que la maîtrise d’un système sobre, donc souvent plus simple, entraîne une meilleure maîtrise par les équipes et des coûts de run mieux maîtrisés. Libérant ainsi des capacité des réinvestissement.
- visibilité : ce qui est visible peut être compris et piloté ; cela passe par un inventaire mis à jour en continue des actifs digitaux bien sûr, mais aussi des compétences et savoirs faires. Et par des modèles d’organisation favorisant le partage de l’information et la mise en lumière des difficultés autant que des succès.
- connaissance : halte à la documentation et au transfert de compétence pensés en phase projet comme une tâche parmi d’autres, plutôt logée à la fin et rapidement expédiée ! comme la cybersécurité, la documentation et l’engagement des futures équipes de run s’effectue au démarrage puis de manière continue ; une documentation est réalisée pendant le codage, la customisation ou le paramétrage et est mise à jour au fil du projet. L’apport d’outils simples à utiliser est clé dans l’appropriation par les équipes.
- culture : passer d’une réflexion « projet » à une réflexion « produit cycle de vie » introduit naturellement la notion de mises à jour et de fin de vie d’un système. La gestion d’obsolescence est alors naturellement intégrée et n’est plus un sujet à part, ce qui évite la concentration unique sur les nouveaux besoins au dépend de l’évolution de l’existant, au risque de son vieillissement.
- temporalité : comme il est illusoire de se dire qu’une organisation peut effacer sa dette technique en trois mois, la gestion de l’obsolescence doit être un effort continue : la diminution de la dette technique s’effectue progressivement (inventaire, évaluation des risques, plan de remédiation), et sa reconstitution – choisie – se gère aussi dans le temps.
- finances : plus technique, mais accessible à des curieux ou au contrôle de gestion IT : la comparaison entre les économies réalisées à court terme et la valeur actualisée nette estimée des réinvestissements à réaliser dans 3/5/10 ans permet un dialogue factuel sur les enjeux financiers réels.
La mise en place progressive de ces pratiques permet non seulement de ne plus faire grossir la montagne de dette devant nous, mais permet aussi de réduire la dette existante au fil du renouvellement des systèmes par des solutions ayant pris en compte nativement leur obsolescence.
Ultime bénéfice : le pilotage méthodique, régulier et préventif des facteurs endogènes permet de s’affranchir presque totalement d’une dette subie, ce qui permet de faire le choix éclairé d’une dette choisie/pilotée tout en se réservant des marges de manœuvre suffisantes pour absorber sereinement les événements exogènes à l’organisation. Le tout dans un contexte budgétaire et risques maîtrisé.
Pour poursuivre la réflexion :