Le concept de la Dette technique provient du secteur du développement logiciel, et peut se résumer ainsi :
Sortir une première itération de code, c’est comme s’endetter. Une petite dette accélère le développement tant qu’elle est remboursée rapidement par une réécriture… Le danger survient lorsque la dette n’est pas remboursée. Chaque minute passée sur un code pas tout à fait correct compte comme un intérêt sur cette dette.
Ward Cunningham, 1992 (source)
Appliqué à la plupart des domaines de l’ingénierie, mon interprétation de ce concept désignerait une avancée technique qui serait:
- Non ou mal testée,
- Non ou mal validée,
- Non ou mal justifiée,
- Non ou mal inscrite dans les guidelines et bonnes pratiques,
- Non ou mal documentée.
De ce fait, une dette serait laissée aux ingénieurs suivants, qui auraient la charge de maintenir l’objet (produit ou autre) en question, ou de le faire évoluer sur des bases non-saines, induisant des intérêts à payer (temps, argent, énergie…) tant que les problématiques à la base n’ont pas été assainies.
Exemple: un produit physique qui présenterait un défaut qui n’a pas été identifié lors de sa conception (par manque de test, d’analyses = dette technique). Ledit défaut pourrait apparaitre longtemps après la conception du produit, alors que diverses évolutions du produits le rendent d’autant plus difficile à corriger. Cela peut conduire à un rappel auprés des clients, avec les nombreux coûts associés (= intérêts de la dette technique)
Notez qu’il peut être stratégiquement judicieux de contracter une dette technique (pour gagner du temps, remporter un marché…) si l’on a planifié de la rembourser proprement.
Crédits
- Image par Gustavo Fring
- Source : Cédric Compagnon
- Bibliographie : InfoQ
Soyez le premier à commenter