La dette technique, ce composant des SI que l’on camoufle

Dans les grands mystères du management du système d’information, s’il en est un qui revient régulièrement sur le devant de la scène, sans être jamais réglé, c’est bien celui de “la dette technique”. De quoi s’agit-il réellement ?

Les systèmes d’informations c’est comme les grandes métropoles. On inaugure en grande pompe la dernière médiathèque moderne aux normes environnementale, quand la majorité de la ville est composé de passoires thermiques. Il est toujours plus facile de mobiliser des moyens pour cette médiathèque sous les feux des caméras, que pour la remise aux normes des vieux bâtiments, voire parfois tout simplement leur entretien.

Comme les métropoles, les SI ont accumulé au cours des années la dette de la mise aux normes de tout ce qui a déjà été construit avant chaque norme.

Le dernier billet abordait la nouvelle posture de l’architecte du SI d’entreprise. Cette dernière évolue avec le digital qui pousse les frontières du SI traditionnel en dehors de sa zone de confort “régalienne”, en numérisant les relations numériques avec les clients et les partenaires. Et à la frontière du SI, on construit beaucoup de nouvelles applications “sur Internet” qui doivent s’interfacer avec le cœur du SI qui gère toujours les transactions de l’entreprise. Et c’est souvent là que ça coince. !

Plusieurs études font ressortir que cette intégration est l’un des freins à la transformation digitale et la raison principale est la fameuse dette technique. Ces applications ont été construites avant (ou après mais ont ignoré) les standards de sécurité et d’ouverture des SI sur Internet et demain de l’Internet des objets.

La réalité des systèmes d’information d’aujourd’hui est donc que la majorité des budgets et des efforts applicatifs sont consacrés à l’existant, à son maintien en conditions opérationnelles, et sans même gratter la dette technique qui s’accumule mécaniquement avec le temps.

La dette technique c’est ce concept inventé par Ward Cunningham en 1992, inspirée de la dette dans le domaine de la finance. On peut vivre avec des dettes mais un jour on doit les payer.

Appliqué au domaine du développement logiciel, un jour on doit faire cette montée de version de la base de données devenue obsolète ou remplacer ce composant qui n’est plus supporté alors qu’il contient des failles de sécurité connues de tous. Mais aller expliquer cela à des métiers à qui cela n’apporte rien de plus.

Dans les DSI qui ont un fort turnover (la durée moyenne en poste d’un DSI est de 3 ans) ou qui font tourner leurs grands fournisseurs, l’image de la dette représente aussi le fait que ce qui doit être remboursé aujourd’hui à été laissé par l’équipe précédente hier, et que les choix d’aujourd’hui seront assumé par la prochaine équipe. Cette dette devient générationnelle, et on pourrait dire que parfois on n’est peut-être pas totalement responsabilisé sur ce sujet…

Mais traiter la question de la dette technique n’est pas de faire d’un “grand soir” puis de se réveiller avec un SI tout neuf. Il est peut-être temps de quitter la métaphore Haussmannienne et d’en adopter une autre.

D’abord, c’est matériellement impossible sur le plan technique et financier. C’est pourtant ce qui régulièrement proposé, souvent inspiré, par des éditeurs en mal de nouveaux clients et d’extension de leur territoire dans le SI. Par exemple quand on veut remplacer un système ancien non maintenu (devenu “legacy”) par un nouveau système, comme si on rasait un ancien quartier. Bien sûr, dans ce cas, on rassure tout le monde en criant haut et fort que ce sera sans régression fonctionnelle (un autre grand mystère du management des SI pour GreenSI et traité en 2017 avec ce billet), ce qui n’aurait aucun intérêt.

Traiter la dette technique c’est gérer au quotidien le backlog des obsolescences, de cloisonner les systèmes pour les faire évoluer séparément, puis de les décloisonner avec des interfaces modernes. Bref, c’est un véritable travail d’architecte ! (CQFD)

C’est surtout un travail de tous les jours et une course sans fin, car la technologie évolue et le monde digital se complexifie sans cesse.

Mais il est vrai qu’entre les équipes projets mobilisées sur le neuf, et les équipes de maintenance mobilisées sur le support et l’urgence, peu de ressources ont cet objectif d’entretien au quotidien. C’était l’objet du billet précédent sur les architectes d’entreprise, de leur proposer de s’inspirer du re-factoring effectué par les développeurs en mode agile, pour avancer dans la complexité et l’incertitude d’une gestion de produit (tirés par les clients) plutôt que de reposer sur de la gestion de projet classique (tirée par les plans).

L’urbanisme des systèmes d’information est fortement inspiré par les villes et par le code de la construction, avec ses quartiers, ses plans d’occupation ou son concept de maîtrises d’ouvrage qui vient aussi du bâtiment. Mais n’est-ce pas une erreur aujourd’hui dans un monde en évolution rapide ?

Et si finalement il fallait plutôt s’inspirer des jardins et d’un manuel de jardinage, comme métaphore de gestion du SI ?

Cette image a été proposée ce mois-ci par Yves Caseau, le DSI Groupe de Michelin, lors de sa conférence sur le rôle l’architecte, dans le cadre du forum MarcusEvans sur l’évolution de l’architecture d’entreprise. GreenSI ne peut renier cette idée de verdir les SI, et c’est même l’origine de son nom choisi il y a 10 ans 😉

La question reste cependant entière de savoir comment, et à qui, confier les tâches de jardiniers, qui vont mettre un tuteur par-ci, de l’engrais par là, tailler un buisson ou complètement élaguer un arbre. Car c’est bien cela l’approche de la dette technique au quotidien, de permettre un travail de fond permanent sur la vitalité du SI.

Oubliez les grands projets de refonte, qui se font rarement, et adoptez plutôt l’œil du jardinier bienveillant :

• L’entretien n’est pas gratuit
  La “refactorisation” fait partie du plan de gestion du cycle de vie de l’application et donc doit avoir un budget consacré dans les projets. N’hésitez pas à annoncer 10% à 15% du total du développement, de coût annuel récurrent, pour que vos clients s’habituent dès le début des projets à l’idée de l’entretien de ce qu’il vont aller ajouter au patrimoine applicatif. Et qu’ils revoient leurs exigences à la baisse le cas échéant. 
• Connaissez votre jardin
  La dette est dans toutes les applications, mais il y a dette technique et dette technique. Il faut donc les caractériser en matière de risque, d’impact métier ou business et de coût de réhabilitation. Ceci permet de répondre à LA question brûlante : “Mais au fait, par où commencer ?“
  La mobilisation des responsables des applications peut aussi être organisée de cette façon, avec des “primes” (ou des malus) distribuées aux projets qui intègre les dettes techniques prioritaires dans leurs évolutions.
• Mettez la cabane à outils au milieu du jardin
  La boîte à outils pour évaluer, traiter, ignorer ou retarder la dette technique existe. Alors simplifiez vous la tâche et utilisez-la. Vous la trouverez sur le web et même auprès de ceux qui voulaient vous vendre des projets de refonte, mais méfiez-vous quand même qu’ils ne gardent pas cette idée derrière la tête 😉
• Mettez en valeur les vieux arbres
  La communication est essentielle, à la fois pour sécuriser la démarche mais aussi pour montrer son impact.
  On a souvent l’envie de mettre les vieux “legacy” sous le tapis et pourtant s’ils sont bien gérés il n’y a aucune raison de ne pas être fiers de son datawarehouse sur AS400, euh pardon System i5, ou de sa base SQL de 2To, toujours aux normes en terme de performance. 

Le digital, la complexité, l’agilité et la réduction des budgets nous obligent à changer notre regard sur les approches projets traditionnelles qui découpent le temps, l’espace et les ressources.

La perspective du jardin et de la dette technique peut nous aider à voir les choses différemment. Vous rencontrez rarement un jardinier qui veut tout raser, mais plutôt des jardiniers qui entretiennent tous les jours.