La dette technique

La dette technique est une réalité qui désigne toutes les choses que l’on a pas ou mal faites dans l’élaboration d’un produit et qu’il faudra payer plus tard en correctifs et en patchs. Initialement développé en 1992 pour l’informatique, le concept de dette technique touche tous les domaines :mécanique, chimie, banque et aussi les start-ups.

Dans un rapport de 2013, le cabinet Deloitte estimait que chaque jour un Américain sollicitait treize fois un programme en COBOL, un langage informatique préhistorique datant de 1959 et dont le secteur bancaire est encore aujourd’hui très friand. Dans les domaines techniques, il reste encore bien du FORTRAN, un autre paleolangage pour lequel il faut laisser, dans ses versions d’avant 1990, 6 caractères blancs en début de ligne parce que cela correspond à la place pour la carte perforée!

En informatique, une estimation fréquente de la dette technique est de 2,67$ par ligne. Mais il en va de même pour tous les autres domaines industriels: documentation incomplète ou perdue, plans illisibles, sigles oubliés, indexes inconnus, expérimentations non faites, risques mal évalués, incertitudes de mesure non prise en compte, reproductibilité mal évaluée, normes ignorées ..

En fait, la dette technique, qui est une vraie dette au sens comptable, mais que l’on ignore le plus souvent, correspond au prix de tout le scotch que l’on a mis lors du développement du produit, pour le faire tenir en allant plus vite mais en le développant quand même.

En programmation, on trouve aussi des noms de variables qui ne veulent rien dire et dont on a oublié à quoi elles servent, quand elles n’ont pas été baptisées de noms loufoques, ou du fameux ‘foo’ ou ‘foobar’ (dérivé de l’argot militaire FUBAR : Fucked up beyond all repair c’est à dire bousillé au-delà de toute réparation possible).

La dette technique a probablement mis en faillite en juin 2017 le géant de l’automobile TAKATA, qui, selon son PDG, ignore toujours pourquoi ses airbags explosaient.

Pourquoi la dette technique prospère-t-elle?

La dette technique n’a pas été chassée par la norme qualité iso 9001. Elle prospère dans les start-ups et les bureaux d’études pour deux raisons:

  • Les porteurs d’intérêts (clients, financeurs publics, organisateurs de concours innovation… et bien sûr actionnaires) ne veulent voir que ce qui se voit. L’intérieur de la boite leur importe peu. Prenons un exemple: en analyse chimique, lorsqu’on fait une opération aussi simple qu’une pesée, le résultat doit être donné avec un calcul d’incertitude. Par exemple, je pèserai 10 grammes de sel plus ou moins 0,1 gramme, car c’est la précision de ma balance. Lorsque vous allez vous faire doser le cholestérol dans un laboratoire d’analyse médicale, avez-vous remarqué cela? Non, le résultat est donné avec deux chiffres après la virgule, par exemple 0,87 g/l. Si l’erreur est de plus ou moins 0,5, alors ce résultat ne veut pas dire grand-chose or, en tant que consommateur, vous n’en savez rien et cela ne vous intéresse pas. Autre cas extrême, l’ADE651 un faux détecteur d’explosif vendu partout et notamment en Irak. Personne n’a pensé à vérifier, alors qu’il était utilisé par des militaires qui disposaient d’explosif pour le faire, que l’appareil détectait quelque chose quand on le présentait devant une de leurs grenades.
  • Les mêmes porteurs s’intérêt sont pressés de voir des résultats, et les gens pressés mettent la pression. Les développeurs sont donc poussés à la faute avec bienveillance et inconscience. Il est très difficile pour eux de résister, d’autant que leurs explications sur la nécessité d’essais, d’expériences ou de validation ennuient rapidement tout le monde.

Comment réduire la dette technique?

Il y a des programmes de réduction de la dette technique existante, mais nous allons plutôt nous intéresser à éviter qu’elle s’accumule. Les grandes lignes de la méthodologie a été publié dans Recherche, Développement, Innovation en entreprise. Pour résister, il faut documenter et jalonner. Quelques outils:

  • Monitorer l’avancement par l’évaluation de la maturité technologique TRL (ISO 16290)
  • Avoir un plan de développement et un modèle système pour réduire l’incertitude
  • Avoir un référentiel métier
  • Inscrire dans ses processus l’obligation de documenter le travail fait (Procès-verbaux, notes techniques…) surtout si vous avez un turnover important

 

La dette technique est plus facile à endiguer qu’à résoudre une fois qu’elle s’est installée. Il ne faut donc jamais espérer qu’elle se résolve d’elle-même.

 

 

 

Télécharger cet article au format PDF ou ePub

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *