La dette technique peut être définie de plusieurs façons, selon le point de vue : code, logiciel, infrastructure ou le SI en général. Dans cet article, nous allons faire un focus sur la dette technique dans le SI, ses impacts et comment la traiter.
Une définition plus détaillée avec les typologies de dette est bien expliquée dans cet article du blog octo.
La dette technique dans le SI
Dans un SI, la dette technique constitue l’écart entre l'existant et l’état de l’art des composants du SI (code, logiciel, infrastructure…)
Le remboursement de la dette d’un SI constitue l’investissement mis en oeuvre pour permettre au système d’information d’être dans l’état de l’art. Traiter la dette technique d’un SI revient à :
Faire évoluer les composants du SI vers une cible plus récente: traiter l’obsolescence, mise à niveau des composants, etc.
La revue du code incompatible avec les standards et les pratiques de développement (coût de non qualité)
Mettre à niveau les équipes techniques tout le long du cycle de vie du SI
La dette est inévitable...
Fred Brooks a introduit dans son papier “No Silver Bullet” les notions de complexité essentielle et de complexité accidentelle. La première est celle liée au problème à résoudre et elle ne peut pas être évitée. La seconde n’est pas liée au problème, mais introduite par effet de bord à cause d’une analyse non approfondie du problème : sa conséquence est que le logiciel, et par conséquent le SI, devient plus compliqué à maintenir. Les deux situations engendrent une augmentation de la dette.
Qu’elle soit volontaire ou non, la dette technique augmente avec le temps.
Sur plan organisationnel, la perte de connaissance technique constitue une source de l’augmentation de la complexité. Lorsqu’on veut faire évoluer un composant, des fois on peut se confronter à une méconnaissance des règles métier ou du besoin originel. Sur un plan technique, un composant applicatif doit évoluer, et son évolution est moins rapide que les frameworks, les outils et l’infrastructure qui l'héberge, et ce, indépendamment de la qualité du code et des logiciels qui forment le système d’information.
Ce qui nous conduit au constat suivant : Même un composant applicatif de qualité génère de la dette s’il n’est pas maintenu pour être en tout temps en phase avec les standards du marché et les bonnes pratiques de développement.
Le remboursement de la dette constitue un effort, donc un budget. Si cet effort n’est pas prévu en amont, l’écart augmente et le SI deviendra de plus en plus endetté.
La dette est inévitable.
Pour donner quelques exemples concrets…
Quand on utilise un framework, celui-ci évolue avec le temps, des versions supérieures sortent. Le code en place va générer de la dette qui devra être traitée un jour. Plus le temps passe, plus la dette augmente et sera difficile à rembourser.
Quand on met en place un outil ou framework en version X, le fait que l’outil évolue en version supérieure X+1, X+2,... et qu’il est, en général, impossible de suivre les mises à niveau au fur à mesure, fait que l’on cumule de la dette qu’il faut un jour payer, à travers des mises à niveaux. Et si ce n’est pas fait dans les temps, le prix sera le paiement du support étendu, le recrutement de l’expertise…
Si le code n’est pas implémenté en suivants les bonnes pratiques de développement : couplage fort entre composants, nommage incompréhensible, code non homogène,... cela engendre un cumul de la dette au fil du temps.
Et si on parlait impacts de la dette non traitée sur le SI…
Sur l’humain : quand on cumule de la dette, on obtient un SI contenant des composants applicatifs ou infrastructure d’un autre temps. Un des impacts concret de ce type de dette est la perte de l’expertise. Les experts deviennent plus rares, et donc plus chers (exemple des experts Cobol, Mainframe…).
Sur l’environnement technique : on maintient dans le SI des infrastructures “anciennes” avec du support étendu voire obsolète des fois. On continue à utiliser des solutions ou des frameworks non supportés par des éditeurs ou la communauté (si open source). On continue à exécuter un code difficilement maintenable.
Sur le process : quand on hérite d’un SI dont les composants générent des dysfonctionnements, on rentre dans des cycles maintenance assez fastidieux, du code non testable, voire des cas extrêmes tels que l’impossibilité de déploiement de nouvelles versions.
Sur l’organisation : dans un monde qui se veut agile, avec des composants de plus en plus interconnectés, une organisation en silo est peu adaptée. Une telle organisation ne favorise pas la communication, l’échange entre équipes… et donc constitue un frein lorsqu’on veut faire évoluer le SI. Ce qui peut avoir un impact sur le traitement de la dette.
Mais quels actions pourrait-on mettre en place ?
Actions correctives
Si nous sommes dans le cas où notre SI présente une dette technique à gérer, comment faire ?
Voici quelques pistes pour résorber la dette d’un SI:
Analyser l’ensemble des composants : selon la complexité du SI, considérer l’intérêt d’utiliser un outil de type APM (Application Portfolio Management) pour assurer à la fois la cohérence du SI et le suivi de la dette technique de l’ensemble des composants du SI.
Analyser l’impact fonctionnel (s’il existe) sur les composants à modifier : la résolution de la dette peut engendrer un impact fonctionnel, certain outils ou frameworks apportent de nouvelles fonctionnalités ou des modifications impactants le métier.
Analyser l’impact sur les liens avec des composants externes.
Etudier le traitement de la dette en implémentant un des trois scénarios : mise à niveau, migration et refonte (les trois scénarios sont explicités en bas).
Planifier une stratégie de gestion de la dette, et commencer à la traiter. Comme dit le proverbe chinois : “Le meilleur moment pour planter un arbre, c’était il y a 20 ans. Le second meilleur moment, c’est maintenant.” Il n’y a pas de temps à perdre !
Revenons aux trois scénarios cités plus haut.
La mise à niveau d’un composant applicatif ou d’infrastructure consiste à le faire évoluer d’une version à une autre supérieure, avec d’éventuels impacts sur le code. Dans certains cas, la mise à niveau, surtout si elle arrive au bout de plusieurs années, peut avoir des impacts importants sur le SI, du simple fait qu’une version récente peut apporter des nouvelles fonctionnalités, voire casser des fonctionnalités existantes de la version en cours.
La migration d’un composant consiste à son remplacement par un autre, du même ou d’un autre éditeur. L’étude de la migration doit contenir une analyse détaillée des fonctionnalités utilisées, leurs équivalents dans la nouvelle solution, les éventuels impacts techniques mais aussi sur le quotidien des utilisateurs de la solution.
La refonte est essentiellement applicable sur le code d’un composant applicatif ou les composants auxquels la brique est connectée. La refonte peut être complète ou partielle. Dans tous les cas, il faut assurer la non-régression, l’intégration du nouveau code et la mise en oeuvre des bonnes pratiques liées au processus de développement et au code. Chez OCTO Technology, nous savons auditer les pratiques de développement, qualifier un code à travers certaines métriques telles quel : clarté/simplicité, réutilisabilité, maintenabilité, application des principes SOLID,...
Les actions préventives
La dette étant inévitable l’objectif est d’avoir deux axes pour la traiter en amont et dans le temps.
En amont, à travers:
La mise en place des bonnes pratiques de développement dans le code et dans les processus (principes SOLID, revue de code, TDD, DDD, pair programming…)
L’utilisation des outils éprouvés et dans l’état de l’art du marché
Dans le temps, en réservant du budget pour le traitement de la dette : Ce qui consiste à estimer les coûts de mises à niveau, migration et/ou refonte dans le temps. Comme les composants du SI évoluent et au lieu de subir cette évolution, la solution la plus adéquate est de réserver systématiquement un budget pour le traitement de la dette.
Takeaways…
La dette fait partie du SI. Elle a des impacts sur l’humain, l’environnement technique, le process et l’organisation. Le traitement de la dette doit être prévu et budgétisé au risque de voir son coût augmenter avec le temps.
Deux points importants à retenir :
La dette est inévitable, elle fait partie du SI.
La dette se traite en amont mais aussi tout au long du cycle de vie d’un logiciel.
