La dette technique, un levier d’écoconception ?
[article original écrit par Clément Cunin de la société D2SI, voir l’original]
Êtes-vous endetté techniquement ? Tout développement d’application générant nécessairement de la dette technique, volontaire ou involontaire, il y a fort à parier que votre code soit en dette. Toute la question est de savoir quel plan de remboursement vous envisagez.
Qu’est-ce que la dette technique ?
Lorsqu’on parle de dette technique dans le développement d’application, on fait référence à tout ce qu’on ne fait pas, ou mal, aujourd’hui, et qu’on devra payer plus tard, à un coût plus élevé. C’est en quelque sorte la somme de tous les petits problèmes qui font perdre du temps au quotidien dans la vie d’un développeur.
Quand on code au plus vite et de manière non optimale (« quick & dirty » disent les américains), on contracte une dette technique que l’on rembourse tout au long de la vie du projet sous forme de temps de développement de plus en plus long et de bugs de plus en plus fréquents.
Si la question de la dette technique n’est pas nouvelle, c’est l’émergence d’outils comme SonarQube permettant d’analyser la structure du code qui a permis de sensibiliser sur le sujet.
Source : Wikipedia SonarQube
Allo, la commission de surendettement ?
Comme une dette financière, la dette technique en soi n’est pas grave : on vit très bien avec un peu de dette, tant qu’on en a conscience, et qu’on sait l’évaluer. C’est le surendettement que l’on veut éviter.
L’accumulation de dette technique correspond à différentes phases du projet : en début de projet, les contraintes sont fortes, la nécessité d’avancer rapidement pour donner l’impulsion de départ oblige à laisser filer la dette technique. Ce phénomène est parfois accentué par l’utilisation de technologies nouvelles. Une fois que le projet est viable, que la pression se relâche, il est alors temps de se pencher sur la dette accumulée et la corriger. La seule exception à cette règle étant le cadre de certains projets open source, sans contraintes financières.
Le projet se déroule en cycles d’itérations de développement; en fin de chaque itération, on mènera une première action corrective sur la dette technique pour éviter de la laisser croître trop rapidement. Au delà d’un certain seuil, on prendra des mesures de correction plus radicales pour se ramener à un niveau de dette acceptable. Ce qui donne une évolution de la dette comme le montre le schéma ci-dessous :
Source : Good and Bad Technical Debt
Zéro dette technique, une illusion ?
A contrario, il est utopique et contre-productif de viser le « zéro dette technique » : non seulement le coût d’un projet exempt de dette technique sera élevé, mais les délais de livraisons seront fortement impactés. Accumuler de la dette technique est un moyen de livrer plus rapidement si on n’a pas la possibilité d’augmenter les ressources sur le projet : il s’agit alors d’un risque calculé.
En résumé, plutôt que de considérer la dette technique comme un travers à éviter absolument, on la traitera comme un levier de la gestion de projet. Selon la phase dans laquelle on se trouve, lancement, stabilisation, accélération du projet, on utilisera la dette comme un outil de management, de la même façon qu’on augmenterait les ressources humaines allouées au projet. Un levier, certes, mais à utiliser avec précaution.
La dette technique, source de gras numérique
Comme le montrent les retours d’expérience de LinkedIn et Microsoft notamment, la dette technique se traduit par un très gros impact environnemental. Dans le cas de Linkedin, le mauvais choix d’architecture (synchrone) et de technologie (Ruby on Rails) s’est traduit par 112 fois plus de serveurs nécessaires au fonctionnement de son site mobile. Dans le cas de Microsoft, la mauvaise quantification du besoin fonctionnel s’est traduite par 80 % de ressources serveurs en plus. Un peu de dette peut être acceptable, mais n’importe quelle dette, certaines étant plus toxiques que d’autres.
Dans un prochain article, nous verrons les différents types de dette technique, leurs origines et leurs solutions.
Source : http://blog.d2-si.fr/2014/04/25/la-dette-technique-un-levier-de-la-gestion-de-projet/, avec GreenIT.fr
Frédéric Bordage
Expert en green IT, sobriété numérique, numérique responsable, écoconception et slow.tech, j'ai créé le collectif Green IT en 2004. Je conseille des organisations privées et publiques, et anime GreenIT.fr, le Collectif Conception Numérique Responsable (@CNumR) et le Club Green IT.