Ward Cunningham introduisait en 1992 la métaphore de la dette technique faisant une analogie entre les coûts futurs liés aux choix de conception logicielle et une dette financière. Celle-ci introduisait la nécessité de mettre en application des Design Patterns permettant de mieux maitriser la dette technique.
En 2009, Ward Cunningham revenait lors d’une interview sur le fait que l’objectif premier n’était pas d’apurer totalement la dette technique mais de s’attacher à la maitriser dans le temps.
Pour illustration, l’éditeur CAST Software a publié un rapport qui évalue le montant moyen de la dette technique à 2,82$ par ligne de code. Le sujet de la dette technique n’est pas tant le montant que son échéance – date à laquelle il devient nécessaire d’apurer la dette technique - et ses intérêts – surcoûts liés à une conception technique peu flexible.
La dette technique désigne l’inadéquation technique d’un logiciel, qui peut être exigée par des demandes d’évolution futures. La nécessité de financer des évolutions de nos systèmes d’information peut provenir de bien d’autres sources :
Evolutions fonctionnelles demandées par les utilisateurs
IT refresh demandés par les éditeurs et les évolutions technologiques
Evolutions organisationnelles (fusion, acquisition, externalisation, …)
Evolution des paradigmes business (rollover market, multi-canal, servicing, …)
Evolutions réglementaires (comptable, autorité de supervision, …)
La dette technique n’est finalement qu’une partie de la dette du système d’information.
Dans un autre article, je tentais d’approximer le montant minimum de la dette du SI à 55% du montant initial du projet sur 3 ans.
La rationalisation du SI a été successivement associée à une réduction des coûts, puis à de la ré-urbanisation du SI et de plus en plus à du downsizing du SI. A ce titre, le principal levier de la maitrise de la dette du SI est la réduction de la taille du SI.
Les outils de la rationalisation du SI sont multiples :
Faire plus avec moins de lignes de code. Le rapport entre les technologies diffère fortement entre COBOL, C, Java, Ruby et .NET
Zone rationalisée/Zone Sandbox métier. Dans une UPSI, nous évoquions l’intérêt d’une zone du SI non rationalisée permettant le prototypage permanent
Minimiser les tailles des « socles » techniques plus difficiles à faire évoluer
Maximiser les investissements SI « rentables », c’est-à-dire à forte valeur d’usage
Pour maitriser la dette de nos systèmes d’information, il est nécessaire de rompre avec nos réflexes qui nous incitent à glorifier la complexité et l’optimisation des coûts passés. Mon intime conviction est que la maitrise de nos systèmes d’information passe par le développement d’une compétence « d’asset manager de l’information » permettant de reconnecter la valeur d’usage aux investissements.