Situations ordinaires de la dette technologique

« Bonjour, c’est Christine, de la Direction des Ressources Humaines. Nous avons une visio-conférence dans 10 mn avec un candidat pour le poste de Responsable de la Maintenance et Zoom me demande d’installer la dernière version et le processus de mise à jour ne va pas à son terme. Puis-je malgré tout utiliser Zoom ? »

« Bonjour, c’est Quentin, du contrôle de gestion. Je tente depuis plusieurs semaines de réaliser une extraction du journal des ventes sur plusieurs sociétés du Groupe et il semble qu’il manque des enregistrements concernant les ventes de certains produits. L’équipe Support de l’Editeur que j’ai contactée, me signale que nous ne disposons pas de la dernière version du logiciel qui apporte cette fonctionnalité d’extraction avancée.»

« Bonjour, je suis Isabelle, votre responsable commerciale du groupe Orange. Je vous contacte dans le cadre de l’opération en cours de démantèlement du réseau cuivre et le passage à la fibre. La ligne XX XX XX XX XX sera arrêtée en mai 2024 pour votre site situé à Feurs. Que souhaitez-vous faire pour les lignes téléphoniques existantes ?»

La technologie, rouage essentiel de l’activité des organisations

Ces 3 situations tirées de la vie quotidienne des organisations, illustre chacune à leur façon combien le bon fonctionnement technologique des systèmes d’information est essentiel aux activités des salariés et aux interactions des parties prenantes de l’organisation (clients, fournisseurs, partenaires, collectivités, Etat …).

La technologie est désormais partout : les Directions des Systèmes d’Information et les Directions Métiers doivent ainsi désormais composer et opérer avec une variété et une quantité considérable (et en croissance continue) de matériels, logiciels et services en ligne, sur des théâtres d’opération multiples (domicile, entreprise, partenaire, environnement urbain ou rural …).

Le rôle de la technologie ne cesse d’ailleurs de se renforcer pour deux raisons principales :

• Un besoin continu d’augmenter la fiabilité et l’efficacité des processus métier qui doivent maîtriser la manipulation (capture, stockage, traitement, diffusion) d’un volume croissant de données,
  
  
• Permettre des interactions avec des systèmes de plus en plus complexes, quelle que soit leur nature (technologie, environnement naturel, vie de la cité).
  
  La  complexité des systèmes est le résultat à la fois des révolutions industrielles et scientifiques (fin XIX et XXème siècle qui ont littéralement bouleversé notre compréhension et notre appréhension du monde dans toutes ses composantes) et des révolutions technologiques qui l’ont accompagné (et parfois aussi engendré).

La « pente » de cette accélération est d’ailleurs « indexée » sur la vitesse de numérisation du fonctionnement des organisations.

Cette vitesse de numérisation des activités soutenue par deux principes de l’économie des services :

• Le recueil et l’appropriation systématique de toutes les données,
• La mise en « algorithme » (le terme d’algorithmisation est aussi utilisé)  des interactions humaines et non-humaines (entre les machines, également nommé M2M).

Concrètement l’offre numérique disponible via des plates-formes de services n’a jamais été aussi prolifique et elle continuera à l’être, jalonnée par de courtes phases de consolidation intermédiaires.

Les organisations trouvent ainsi de nouvelles opportunités d’accélérer le time-to-market et s’en saisissent régulièrement, mais pas systématiquement dans une approche coordonnée et intégrée, de type architecture globale d’entreprise.

Cette situation paradoxale ouvre ainsi des opportunités de court-terme tout en augmentant les risques et le poids d’une dette qui existe déjà par sa propre nature technologique.

La dette technologique, l’histoire d’un sujet opérationnel et obscur qui devient un sujet essentiel à la stratégie des organisations 

L’histoire du « patrimoine » technologique d’une organisation ressemble en tout point à l’histoire de tout autre patrimoine de celle-ci (comme les bâtiments par exemple) : il a fait l’objet d’une acquisition et d’une mise en œuvre au fil des besoins et en vision « locale ».

Les objectifs de performance «verticale » (perspective métier) ou « individuelle » (acteur de l’organisation) ont très souvent été atteints à travers une approche segmentée (on traite le besoin quand il se présente).

Puis progressivement, les directions financières, puis les Directions Métier et Systèmes d’information ont constaté aussi les limites de cette démarche segmentée :

• performance moyenne ou limitée de bout en bout des différents sous-systèmes informatiques,
• poids budgétaire du système d’information,
• performance des actifs du système d’information …).

Pour aboutir finalement à une situation d’intrication des systèmes informatiques qui génère une rigidité fonctionnelle et technique et une sédimentation progressive des systèmes d’information de l’organisation.

Le rôle central de la technologie revient donc sous les feux de projecteurs sous l’impératif de gérer l’obsolescence et la dette technique comme une composante désormais stratégique (et non plus seulement tactique) du système d’information. Cette situation et son évolution replace au centre des attentions la nécessité stratégique d’un pilotage de la dette et de l’obsolescence IT, en raison des défis et des risques auxquels elle expose toute organisation :

Dégradation des performances opérationnelles des services IT fournis :

• que ce soit aux utilisateurs comme aux clients.

Dégradation de la performance opérationnelle et financière :

• d’abord du système d’information et par induction, de l’entreprise.

Résilience sur incident majeur :

• notamment de type cybersécurité.

Contentieux et atteinte à l’image de marque :

• conséquence en cascade d’un cyberincident lié à une obsolescence, 
• mais aussi la génération de d’informations erronées liées à un composant obsolète.

Agilité organisationnelle :

• des entreprises et des organisations publiques ont expérimenté douloureusement durant la phase aïgue de la pandémie COVID 19.

Développement de l’offre de services :

• capacité des logiciels et plates-numériques à être en ligne avec le Time To MArket souhaité par les métiers.

Perte de compétences :

• les technologies obsolètes ou peu usitées disparaissant progressivement du périmètre des compétences disponibles sur le marché.

Dette technologique et obsolescence IT, de quoi parle-t-on ?

La dette technologique exprime l’idée qu’une obsolescence est constituée sur toute ou partie de l’ensemble du patrimoine numérique d’une organisation.

Cette notion a été exprimée explicitement pour la première fois en 1992, par Ward Cunningham , dans un article « The WyCash Portfolio Management System » qui retrace dans un format resserré, l’histoire du développement sur mesure d’un logiciel pour assurer la gestion des titres boursiers dont la société WyCash a la responsabilité (c2.com/doc/oopsla92.html).

Cette dette est la résultante d’arbitrages réalisés le plus souvent dans une perspective court terme afin de faciliter la mise en place de solutions, lesquelles, tout en constituant une certaine valeur à l’instant T pour les métiers, vous exposer par la suite à des contraintes et des risques qui devront être « remboursées » sous la forme de tâches d’ingénierie (évolutions, projets) et d’investissements financiers.

Cette dette technologique peut tout aussi être le résultat d’un décrochage plus insidieux, un long processus qui aboutit petit à petit à considérer qu’en l’état les choses fonctionnent et qu’il est possible de poursuivre une stratégie de non-investissement puisque les faits lui donnent raison. La dette technologique se matérialisera comme un écart entre un existant et une cible, sur 3 dimensions essentielles du système d’information :

La technique 

• Des infrastructures dont le support n’est plus assuré ou dont les versions des composants comportent des retards accumulés de mise à jour 

Les applications

• Des langages de développement qui ne sont plus maintenus, une architecture applicative incompatible avec des montées de version ou incompatible avec les flux d’informations à mettre en œuvre, un manque de compétences (DSI interne ou prestataire) 

Le fonctionnel

• Des fonctionnalités inutilisées ou en doublons (éparpillées sur plusieurs logiciels ou services en ligne) ou qui ne peuvent plus évoluer, des écarts de service (SLA) entre les fonctionnalités (rendant impossible la garantie du SLA global souhaité par le client). 

Cet écart se traduira sous forme de surcoût mesuré rapport à sa qualité, sa maintenance, son évolutivité et ce tout au long de sa durée de vie.  

La démarche stratégique : piloter plutôt que gérer la dette technologique

Clairement, le sujet de la dette technologique est plutôt rébarbatif et met les DSI en situation défensive pour justifier la plupart du temps une situation qui résulte d’une dynamique organisationnelle dont les leviers de commande leur échappent.

De plus, à l’exception de quelques chantiers d’ampleur, pour l’essentiel poussés par la contrainte de la date de fin de maintenance et qui justifieront le déblocage de budgets exceptionnels, il n’existe pas de démarche systémique qui prenne en compte dans toutes ses dimensions, la dette technologique.

Cette situation, de loin la plus fréquente dans les organisations, conduit à des déséquilibres fonctionnels tels que les gains obtenus dans une partie des activités d’un processus métier se trouvent souvent réduits sensiblement (voire réduits à néant) par les limitations fonctionnelles liées à l’obsolescence technologique présente dans d’autres activités du même processus.

Même l’approche fonctionnelle intégrée (progiciel multi-activités, ERP) ne répond pas à la problématique de la dette technologique, déplaçant la problématique sur les satellites (développements spécifiques) et la dorsale de la donnée (bus applicatif, référentiel de données …).

La seule option qui nous paraisse opérante est de considérer que la dette technologique doit créer de la valeur, ou autrement dit, passer d’une posture de gestionnaire (c’est mon sujet par défaut) à une posture de pilote (c’est un sujet collectif de l’organisation, qui s’appuie sur une gouvernance et une démarche d’amélioration continue).

La posture « pilote »  implique de facto de considérer que la dette technologique sera traitée sur principalement sous le prisme de la valeur et de façon dynamique ; ce que l’organisation « cède » sur l’autel de la vitesse (nécessité de répondre au court-terme) est mesuré en valeur et remis en perspective sur la feuille de route de traitement de la dette (réduction et maîtrise de la valeur sur le long-terme).

Cette approche de nature stratégique ne peut se concevoir dans une tour d’ivoire en pensant d’abord la stratégie pour ensuite la remettre aux équipes opérationnelles pour application ; elle nécessite dans son élaboration et sa conduite, un mouvement continu de va et vient entre les opérations et la gouvernance.

Passer de la posture stratégique à la démarche opérationnelle  

La démarche de pilotage de la dette technologique technologique vise à donner :

• une vision globale de l’état d’obsolescence de l’ensemble du SI,
• identifier les technologies cibles (à la fois pérennes et alignées avec les enjeux et besoins métiers)
• et construire à la fois une feuille de route et les processus de gestion nécessaires à une gouvernance qui inclura direction, métier et DSI.

4 cibles majeures guident le pilotage de la dette technologique :

• Rationnaliser et pérenniser le SI,
• évoluer au bon rythme vers l’architecture cible,
• réduire les risques,
• réduire les coûts de fonctionnement du SI.

Dans sa conception, le pilotage de la dette technologique s’appuiera sur les deux dimensions principales qui concourent à la création et l’alimentation de celle-ci :

• La technologie
• La gouvernance

Comme il s’agit de conduire une démarche systémique, il s’agira de comprendre les mécanismes de rétroaction qui alimentent chacune des dimensions et leurs interactions :

• Par exemple, en l’absence d’une gouvernance, il n’existe peut-être pas de roadmap technologique ni même de mécanisme d’arbitrage métier et DSI sur le choix de solutions ce qui alimente la dette technologique,
  
  
• Inversement, si la gestion du parc informatique ou la gestion des changements ne fait pas partie des processus de la DSI, une dette technologique va s’installer, alimentant les métiers dans la démarche de recherche de solutions par leurs propres moyens.

Ces deux dimensions comportent les composantes opérationnelles suivantes :

Sur le plan technologique :

1. La mesure de la dette technologique ;

• Recenser les composantes infrastructures, applicatives, services 
• Construire une grille de référence pour définir les critères d’obsolescence
• Formaliser la cartographie de la dette technologique

2. Les compétences nécessaires ;

• Internes ou externes
• Les risques

3. L’élaboration de la feuille de route technologique ;

• La stratégie métier
• Les services SI à délivrer pour soutenir l’opérationnel et l’évolution de l’organisation
• Les briques technologiques et leur orchestration pour concilier triple rationalisation, performance, sécurité et finances

Sur le plan gouvernance :

1. Le recensement des besoins métier ;

• Les dysfonctionnements constatés

• Les évolutions qui ne peuvent aboutir
• La maîtrise des coûts

2. La sensibilisation de la Direction Générale et des directions métier

3. La définition de cibles communes métier et IT pour réduire la dette

4. Le partage des responsabilités

5. La définition d’un budget sanctuarisé pour traiter la dette technologique ;

• Ce budget permet de conduire les évolutions indispensables à conserver la réactivité attendue par les métiers, selon les objectifs de réduction de dette fixés d’un commun accord et réévalués périodiquement.
• Il est le complément indispensable aux grands chantiers de refonte technologique et fonctionnelle qui ponctuent régulièrement la vie du système d’information.

Ces composantes opérationnelles seront à construire progressivement et confronter à la réalité de l’organisation, à sa capacité opérationnelle de mise en œuvre, à sa progression dans la maturité sur ce sujet.

Quid de l’outillage dans la démarche opérationnelle ?

 

Les outillages pour adresser la dette technologique relèvent de trois catégories principales :

• Les référentiels de bonnes pratiques
• Les outils techniques
• L’accompagnement au changement

Dans les référentiels de bonnes pratiques, on trouve des corpus consolidant un ensemble de principes qui peuvent servir d’inspiration pour être déclinés de façon plus ou moins complète :

• ITIL : conception, implémentation et évolution des services IT
• CMMI : conduite des projets informatiques
• COBIT : gouvernance du système d’information (stratégie de services, rôles et responsabilités, mesure de la performance …)
• TOGAF : urbanisation du système d’information (Processus, fonction, application, données, infrastructure),
• EBIOS RM : identification et traitements des risques numériques.

Aborder en détail les différents processus/pratiques/principes de ces référentiels demanderait un article pour chacun. Retenons notamment :

• Pour ITIL :  la gestion des configurations, la gestion des changements, la gestion financière, la gestion des incidents et la gestion de la capacité,
• Pour CMMI : la gestion des exigences, la planification de projet, le suivi de projet, la gestion des fournisseurs, l’assurance qualité et la gestion de configuration.
• Pour COBIT : la définition du schéma directeur stratégique informatique, la gestion des risques, la gestion de la relation client
• Pour TOGAF : la formalisation du paysage architectural actuel, la définition d’une vision (points de vue et objectifs), la définition d’une architecture cible, définition de la feuille de route
• Pour EBIOS RM : le recensement des fonctions vitales, des sources de risques et leur priorisation.

Dans la gestion financière, la sanctuarisation d’un budget dédié au traitement continu de la dette technologique, est un marqueur fort de la volonté de considérer ce sujet comme stratégique. Selon Gartner, il serait souhaitable de consacrer environ 15% du budget IT (nous parlons ici d’OPEX) au traitement de la dette technologique.

Obtenir cette sanctuarisation est un exercice difficile ; en effet, il est souvent objecté que le traitement de la dette technologique fait partie des pratiques professionnelles à observer régulièrement donc à inclure dans les différentes activités. Le risque et donc l’écueil à éviter serait de considérer que dans chaque projet ou initiative de la DSI, ce sujet étant par principe abordé, il n’est pas nécessaire de sanctuariser en plus un autre budget.

Cette objection se heurte à une réalité : la dette évolue plus vite que le remplacement des actifs qui intervient par phases relativement bien ciblées. Il est donc nécessaire d’agir à la fois par phase, par initiative spécifique mais aussi de façon plus générique de façon à réduire les coûts globaux de l’IT et dégager à moyen terme de nouvelles marges de manœuvre.

Dans les outils techniques, la gestion des actifs informatiques est un incontournable. Elle renvoie à la constitution et le maintien de la CMDB.

Par actif, s’étend tout composant qui entre dans le cycle de vie des services IT :

• Poste travail et périphériques,
• Éléments actifs et infrastructure réseaux (LAN, WAN, WLAN, LoRa …),
• Capteurs,
• Téléphonie fixe et mobile,
• Environnements d’exploitation (physiques, virtuels),
• Services numériques cloud,
• Logiciels,
• Contrats de services.

L’initialisation et le maintien de la CMDB ne doit pas être sous-estimée en matière de temps à y consacrer d’autant que le recensement automatique ne s’applique, en raison de limites diverses (techniques, sécurité …) qu’à une partie du patrimoine SI.

On pourra initier cette démarche en essayant de capitaliser au maximum sur un existant dans les équipes informatiques (fichier Excel, base de données) qu’il faudra nécessairement revisiter à l’aune d’un inventaire.

Les CMDB sont des composantes techniques intrinsèques aux outils ITSM et elles doivent, dans tous les cas, être considérée comme un élément différentiateur dans le choix de l’outil.

Dans les outils techniques, les outils de cartographie du SI (en appui de méthodologie BPMN et TOGAF) du type Modélio, vont structurer la compréhension et la représentation du patrimoine SI. C’est clairement un outil indispensable en appui du processus « Gestion des changements » prôné par ITIL et de façon plus générale en appui de toute démarche d’analyse d’impact.

A titre d’exemple, l’absence ou l’existence d’un tel outil dans le panorama d’une DSI a conduit à une différence notable de réactivité dans les épisodes de cyberattaque de type Log4J.

Enfin, dans l’outillage, nous citerons également :

• les outils de gestion des configurations (très utiles pour gérer les différentes versions de logiciels spécifiques en fonction des contextes d’exploitation),
• les outils d’actualisation des configurations adressant un socle générique de l’environnement de travail (comme SSCM et InTune par exemple),
• les services de recyclage des matériels (qui peuvent être appréhendés par uniquement comme la gestion de la fin de vie mais de plus en plus comme des services de retrofit pour donner une nouvelle jeunesse),
• les technologies Low Code/ Nocode qui permettront à la marge de décommissionner une partie des fonctionnalités applicatives de façon à répondre plus efficacement aux objectifs de time to market. Attention, cette approche provoque assez fréquemment un empilement des coûts puisque le décommissionnement applicatif est rarement possible suivant une couture aussi précise que la fonctionnalité adressée par Low Code. Autrement dit, soit je décommissionne un module applicatif, soit l’application en elle-même ! On ne travaille pas sur les mêmes granularités….

En synthèse, vous remarquerez la grande variété des méthodes et outils disponibles mais aussi l’absence d’une grille de référence technologique (ou matrice d’obsolescence) globale disponible à la demande sur le marché. La constitution d’une telle grille de référence est une étape cruciale et aussi un processus continu dans le pilotage de la dette technologique ; chaque organisation pourra s’appuyer sur ce qui est disponible publiquement à travers les communications réalisées par les fournisseurs et compléter nécessairement avec ses critères d’acceptabilité de la dette.

La variation d’activité guide le pilotage de la dette technologique

Pendant la phase de confinement du COVID 19, les travaux de renouvellement du parc informatique (et aussi logiciel) ont connu une accélération sans précédent (dans sa vitesse et son ampleur).

La mise à disposition de PC portables, d’accès VPN (ou de portails d’accès distant sécurisés) et d’applications collaboratives (comme Microsoft 365) ont entraîné un vieillissement accéléré des autres composantes du système d’information.

Non pas que ces composantes soient toutes devenues intrinsèquement obsolètes, mais plutôt en raison de la différence de connectivité (d’interfaces d’échanges de données), d’expérience utilisateur et aussi de maintenabilité pour les DSI entre ces nouveaux composants et les composants non renouvelés.

Dans d’autres cas, la baisse d’activité a conduit à une réduction, voire à un arrêt, des investissements, donc une dépriorisation des projets.

La dynamique d’actualisation de la carte globale du SI doit donc suivre l’activité de l’entreprise et faire l’objet le cas échéant, d’une fréquence de mise à jour adaptée.

Sur le côté opérationnel, le traitement de la dette technologique sera nécessairement impacté par la fluctuation de l’activité : il est même indispensable d’en tenir compte.

Concrètement, en période de réduction budgétaire, l’attention des entreprises et organisations publiques va se tourner naturellement vers toutes les opérations qui concourent au maintien en condition opérationnelle.

Mais ces périodes plus tendues sur la trésorerie peuvent être aussi une opportunité pour reconsidérer de façon plus robuste des investissements longtemps différés et générateurs d’une valeur ajoutée forte : ainsi en est-il de la rationalisation du SI métier à travers des projets de fusion des SI au profit d’une solution unique et intégrée.

Il n’y a donc aucune règle automatique ; le contexte de chaque organisation pilote l’évolution de la dette technologique. Ce qui fait la différence, c’est précisément la volonté de la piloter en définissant une cible, une organisation et des objectifs qu’il faudra constamment revisiter à l’aune des résultats obtenus et de l’activité opérationnelle de l’organisation.

L’avenir de la dette technologique au sein des organisations

L’urbanisme constitue un domaine stratégique (et politique) pour les pouvoirs publics car il ouvre la capacité à mieux concevoir et mettre en œuvre des usages et des flux dans une cohérence d’ensemble qui serve au plus près possible le projet de vie des territoires.

Cette prise de conscience du rôle stratégique s’est d’abord construite par une nécessité opérationnelle, à l’aune des expérimentations sur le terrain pour coller au plus près des conditions environnementales (et des ressources nécessaires pour vivre) et aussi des aléas de l’histoire (guerres, pandémies …).

Finalement, pour ce qui relève de l’informatique, la situation de la dette technologique se trouve dans une étonnante similarité avec la gestion de l’urbanisme dans une collectivité; d’une nécessité opérationnelle, gérée quasi-exclusivement par les techniciens, elle se déplace vers un rôle stratégique.

Ainsi le contexte global des affaires (incertain, volatile, complexe et ambiguë) qui s’impose aux organisations change le paradigme en matière de gestion des risques créant ainsi l’opportunité de reconsidérer la dette technologique différemment, pour en faire une démarche au service d’un mieux-vivre numérique au sein de l’organisation.

En particulier, les incidents à répétition de nature cybersécurité ont créé une brèche dans la perception de l’IT au sein des organisations et corollaire, dans la sensibilité des dirigeants à ce qui peut exposer l’organisation à des risques nouveaux qui aujourd’hui mettent directement en jeu la survie de l’activité et parfois la santé des salariés.

A cette prise de conscience interne aux organisations, des opportunités externes se présentent pour mieux appréhender et piloter la dette technologique.

Ainsi en est-il de la montée en puissance inexorable des services Cloud qui représentent indiscutablement une opportunité de réduire et maîtriser la dette technologique si et seulement ce « move to cloud » est inscrit dans le schéma de pilotage décrit plus haut. En effet, la règle reste inchangée : on n’externalise que ce que l’on en est mesure de piloter efficacement …

Effet rétroactif de la progression des services Cloud, la diffusion accélérée des bonnes pratiques d’urbanisation et de maintien en condition opérationnelle. En effet, plus ces services sont utilisés, plus l’organisation doit assumer sa responsabilité de définir et piloter sa trajectoire en matière d’architecture. Il n’est plus possible de se remettre exclusivement aux fournisseurs, lesquels ont bien entendu un devoir de conseil (et des obligations de résultats), mais certainement pas la légitimité à décider des choix d’architecture de l’organisation.

Dans un double mouvement souhaité par les organisations, à la fois de retour à plus de simplicité dans le fonctionnement interne et aussi  d’évolution vers une capacité renforcée à adresser la complexité des interactions (conséquence des révolutions technologiques, environnementales et sociétales), nous voyons clairement que le pilotage du cycle de vie des technologies (donc de la dette technologique) au plus haut niveau et dans une approche collégiale, répond à ces enjeux, constitutifs de l’avenir des organisations.