Plus nous développons, plus nous ajoutons de la complexité à un système. Logique ? Bien sûr mais l’un des effets pervers conduit à accroître la dette technique. Et à payer de plus en plus d’intérêt. Jusqu’à l’étranglement du système d’information…
Le terme de dette technique a été introduit en 1992, par Ward Cunningham pour décrire les coûts associés à la maintenance d’un développement logiciel. L’analogie avec la dette vient du fait qu’elle induit des intérêts à payer; les intérêts se traduisent par un effort supplémentaire à fournir pour la maintenance des applications, du fait de la complexité toujours croissante des systèmes, et également par le fait que l’évolution d’un système entraîne toujours une charge de refactoring (action sur le code à fonctionnalité équivalente) et de réécriture de certaines parties de ces systèmes. Cet effort est assimilable à des intérêts. Si l’on accumule trop de dettes, la majorité des efforts seront concentrés au service de la dette, intérêts et capital compris.
La dette est difficile à mesurer, puisque l’effort à payer est subrepticement noyé dans le coût total de maintenance, logiquement nécessaire pour faire évoluer les applications métiers. Pourtant, Gartner a évalué en 2010 le cout de cette dette à 500 millions de dollars au niveau mondial$, et ce montant pourrait doubler d’ici 2015. Cette somme peut paraitre énorme, et il ne s’agit évidemment pas d’un montant à rembourser à qui que ce soit. De fait, la métaphore de la dette s’arrête là, mais qui sont les créanciers ?
Il est intéressant de regarder de plus près où se cachent cette dette, et comment peut-on estimer qu’elle est importante ou pas ? Les principaux révélateurs de dettes sont les suivants :
• une évolutivité difficile
• une fiabilité faible
• une sécurité défectueuse
• des mauvaises performances
• un transfert difficile vers une autre équipe de développement
De façon plus pragmatique, pour estimer si le problème de la dette est important ou non, on peut repérer les phrases suivantes prononcées par vos développeurs :
“le code de mon prédécesseur est tellement compliqué, qu’il me faudra deux fois plus de temps que prévu pour implémenter cette nouvelle fonctionnalité” ;Si je touche à cette partie du code pour améliorer le système A, cela risque de provoquer des dysfonctionnements dans le système B” ;“J’ai du mal à identifier ce bogue, il y a trop d’imbrications de « if », je ne comprends plus la logique métier de ce code…” “Pour améliorer les performances de ce système, on doit le réécrire complètement”
Si ces questions sont récurrentes, vous avez, hélas, mis en évidence un problème de dette technique.
Indépendante du langage, la dette technique se cache pourtant dans le code, et dans toutes les lignes de code. Dans chaque ligne de code, il y a un bogueg potentiel, mais aussi et surtout une difficulté future à faire évoluer le logiciel avec une ligne de code supplémentaire.
Il est préférable de la traiter en amont, avant que les conséquences de la dette technique ne se manifestent. Car lorsqu’elle apparaît, il est déjà trop tard !. En effet, se trouver en défaut signifie être contraint de réécrire complètement les lignes de codes, ne serait-ce que parce que la maintenance de la version existante coûte plus cher que la réécriture complète du logiciel.
Diminuer sa dette technique passe par des bonnes pratiques de développement, notamment pour la conception, la lisibilité, les tests et l’intégration continue. Les bonnes pratiques existent, et font appel au bon sens. Retenons quatre pistes pertinentes qui permettent de limiter les dégâts : choisir la bonne architecture, accroître l’agilité, recourir au cloud computing et utiliser des outils logiciels adaptés.
Définir une bonne architecture
La bonne architecture vise à séparer les éléments techniques, qui varient peu, des éléments métiers, qui varient souvent. Par séparation, on vise un couplage faible, qui facilite l’évolution du métier sans remettre en cause les invariants techniques. Au-delà de cette séparation en couche, on évitera un typage fort qui amènera d’emblée une dépendance et qui, au final, coûtera cher à maintenir. Attention donc à ne pas faire intervenir le métier dans la construction des différentes interfaces entre les différentes pièces.
Pour cela, valoriser les bons développeurs, ceux qui savent élaborer une conception claire, et une architecture solide. A quoi reconnaît-on les bons développeurs ? Au fait qu’ils écrivent peu de code… Le rôle du développeur est trop souvent assimilé à l’écriture de code, c’est une erreur ! En invitant un développeur à écrire peu de code, et à rester concentrer sur la valeur métier de l’application qu’il développe, on peut considérablement réduire la dette technique… Tout simplement parce que les différentes pièces applicatives seront mieux organisées. Autrement dit, la réduction de code est la résultante de la mise en pratique de ces idées, et doit être un objectif.
Augmenter l’agilité, adopter une approche Lean
Les méthodes agiles sont aujourd’hui en vogue. Pourquoi ne pas en profiter et faire la promotion d’un travail collaboratif, d’un management responsabilisant et privilégier la communication, autant de de bonnes pratiques qui ont déjà fait leurs preuves.
Il est même possible d’aller plus loin, en adoptant une stratégie de création de valeur. En d’autres termes, il convient de séparer ce qui a de la valeur (pour les utilisateurs), de ce qui n’en a pas. Cela revient à éliminer les goulots d’étranglements, les contraintes, ainsi que toutes les barrières et les cloisonnements (techniques et intellectuels) qui briment l’utilisateur dans son métier.
Cela revient à améliorer l’expérience utilisateur et à trouver le bon compromis entre fiabilité/évolutivité/maintenance, en considérant la valeur apportée à l’utilisateur. Cette vision permet d’une part d’avoir une autre évaluation des différentes pièces d’un système d’information, et, d’autre part, de prioriser les éléments de valeur.
Cette approche permet d’améliorer la productivité en automatisant les processus de livraison et de déploiement ? Livrer tôt et livrer souvent (pourquoi pas tous les jours ?) constitue un levier incontournable pour accroître la productivité et éliminer la dette technique. Sans oublier toutes les tâches, même les plus simples, qui peuvent être automatisées. Une approche par la valeur permet de les identifier aisément.
Utiliser le cloud computing
Avec l’arrivée du cloud computing, c’est toute une partie visible de la dette technique, parce qu’elle a une existence physique (l’infrastructure des machines) qui est purement et simplement éliminée. Là où il fallait prévoir et budgéter l’achat d’infrastructures coûteuses, les coûts salariaux d’un administrateur système, qui créait de la dette, l’entreprise a aujourd’hui accès à une infrastructure infinie clé en main, et à un coût très compétitif.
En quelques clics, il est ainsi possible d’obtenir des serveurs Web et des serveurs de données, prêts à l’emploi, avec des engagements de services très élevé. La plate-forme cloud computing prenant tout en charge, on élimine ainsi les tâches liées au backup de données, aux mises à jour des logiciels ou à la gestion des patchs de sécurité. Avec le cloud computing, l’automatisation de la mise en production et de la maintenance se trouvent fortement accélérées avec des procédures extrêmement simples et peu couteuses.
S’équiper en logiciels
Combien d’entreprises ont-elles entrepris d’écrire leur socle technique pour optimiser les différentes fonctions communes des différentes applications ? Combien coûte la réalisation et la maintenance d’un tel socle ? Est-ce vraiment efficace ? Est-ce vraiment le métier de l’entreprise de consacrer de tels efforts pour construire des outils qui peuvent être proposé en tant que logiciels ?
L’achat de logiciels ou de frameworks, quand ils sont bien choisis, permet de déporter une bonne partie de la dette technique chez un fournisseur, qui pourra la mutualiser avec d’autres Clients. De fait, la mutualisation de cette dette fait qu’elle sera moins lourde à supporter. Et l’essor du cloud computing fait qu’il y a de plus en plus d’offres SaaS à forte valeur ajoutée. Pourquoi ne pas en profiter au lieu de réinventer la roue, pour un coût quasi équivalent ?
A retenir :
– L’évolution naturelle du développement logiciel engendre une complexité technique qui croît avec le temps.
– Cette croissance de la complexité s’accompagne d’une inévitable augmentation des coûts engendrés pour la maintenance du Système.
– Ce coût est assimilable à une dette qu’il faut rembourser.
- Il n’est pas raisonnable d’attendre que le poids de la dette soit fatal au système d’information.
– Quelques bonnes pratiques permettent de limiter les dégâts : choisir la bonne architecture, privilégier l’agilité, opter pour le cloud computing, et s’équiper de logiciels adaptés
– se poser la question suivante : combien un DSI est-il prêt à payer pour garantir une dette technique nulle ?
Cet article a été écrit par Nicolas Roux, CEO d’Aspectize.