cet article du blog octo.
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 à :
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.
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.
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.
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:
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,...
La dette étant inévitable l’objectif est d’avoir deux axes pour la traiter en amont et dans le temps.
En amont, à travers:
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.
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 :