Dans mon post précédent, je propose une nouvelle définition :

La dette technique, c’est un état de l’art qui se désaligne.

C’est à dire ?

Voici un exemple

Vers la fin des années 80 une application est née qui rassemble trois acteurs :

  • Métier : une enseigne commerciale
  • Management : une société de service spécialisée dans les réseaux à valeur ajoutée
  • Technique : des développeurs spécialistes de ce type de systèmes

Elle a pour vocation la vente de produits sur le réseau Minitel

L’état de l’art :

  • un serveur videotex PC servant les pages accessibles aux usagers
  • une liaison PC / Unix
  • une machine unix accueillant l’application spécifique de gestion de la vente
  • l’application, écrite en C, utilisant une librairie de gestion de fichiers en accés séquentiel indexé (ISAM)
  • gestion des sources, tests et déploiement par procédures manuelles

Juin 94 : l’application est un succès, à la fois pour le client et la SSII. Depuis déjà plusieurs comités mensuels, l’équipe technique attire l’attention du groupe sur une action de maintenance évolutive importante qu’elle a analysée et chiffrée : remplacer la librairie ISAM par un SGBDR afin de rationaliser la gestion des données.

Le débat est animé :

Pour le Métier, cette évolution coûte trop cher et ne présente pas de valeur ajoutée. Pour ce qu’il en perçoit la gestion des données de l’application est satisfaisante.

Pour le Management, la gestion des données pose un problème de sécurité et de fiabilité. Elle est prise en charge par les développeurs, via un mode opératoire fragile et sujet à erreur :

  1. export des fichiers ISAM concernés vers des fichiers “plats”
  2. création/modification/suppression à l’aide d’un éditeur de texte
  3. import à nouveau des fichiers texte vers les fichiers ISAM

Pour l’acteur Technique, le projet a une technologie de retard. Il stagne, alors que le fournisseur de la librairie qu’ils utilisent distribue commercialement depuis déjà 5 ans un SGBDR complet. Cela les pousse à rechercher des missions dans lesquelles ils pourront à la fois disposer d’outils plus efficaces et étendre leur compétence en SQL, un langage d’avenir.

Pour le Management, ces départs potentiels ajoutent à l’insécurité de la solution actuelle.

Pour le Métier, il y a là une sorte de chantage à la technologie.

Comme on le voit, la dette technique nous parle “technique” et nous invite à penser en termes financiers, mais le creuset où elle se forme n’est pas seulement technique ou financier, loin de là. Tout l’enjeu réside dans la réponse à ces questions :

Quel problème voulons nous résoudre ensemble ?

Quels sont nos objectifs et nos contraintes ?

Comment doit évoluer notre état de l’art ?

La difficulté, la complexité même de l’entreprise, ce n’est pas tant de faire marcher la technologie, ou bien d’aller plus vite : c’est de préserver la cohérence de l’état de l’art qui guide la résolution du problème.

Stay Tuned !

publié sur Linked In le 09/02/2023