Innover en mettant les freins
Pourtant, le principe est sain : plus vite vous abordez et résolvez les problèmes, plus la complexité et le coût sont faibles. Une correction de bogue au début d'un trajet coûte par exemple 10 % d'une correction de bogue à la fin du trajet. Ou, inversement, plus longtemps vous continuez à reporter certains problèmes, plus leur complexité augmente (facteur exponentiel 2.1) et plus leur coût est élevé. Peut-être arriverez-vous même à un point d'insolubilité, comme dans Tetris. De cette manière, la dette technique freine les progrès, et c’est une chose qu’il faut à tout moment essayer d’éviter. Surtout à une époque où la digitalisation et la modernisation sont une condition de survie.
Une entreprise qui consacre plus de la moitié de son budget IT à des intégrations et à la « réparation » de systèmes hérités tombera probablement, en raison de cette héritage IT du passé, dans une spirale de dettes techniques dans laquelle elle ne paie que des intérêts. Là où une entreprise qui opère sur une pile IT moderne et a peu de dettes techniques peut concentrer presque tous ses investissements technologiques sur des solutions orientées vers l’avenir et l’innovation stratégique, et ainsi créer de la valeur ajoutée pour l’ensemble de l’organisation. La plupart des entreprises se situent entre ces deux extrêmes. L’objectif est de concilier à court et à long terme - running the business et changing the business – dans un Flow Digital positif.
Attention à l’éléphant dans la pièce
Il faut le dire, la dette technique n’est pas nécessairement une mauvaise chose. Vous ne pouvez d’ailleurs jamais exclure ou éviter totalement la dette technique. Les projets doivent pouvoir progresser et vous devez respecter certaines échéances ou limitations temporaires, ce qui vous oblige à changer de mode de fonctionnement et parfois à prendre cette voie plus rapide
Il est toutefois important, pour chaque choix dans le processus de développement, que vous soyez conscient de la dette technique que vous constituez et que vous envisagiez d'en tirer profit. Ainsi, le niveau de la dette technique reste acceptable et la solution à court terme ou raccourci peut être converti dans un délai raisonnable en une solution structurelle. La dette technique ne peut pas devenir une tache aveugle ou l’éléphant dans la pièce que personne ne veut voir.
Pourtant, il y a encore souvent un décalage entre conscience et dynamisme effectif. Une étude de McKinsey1 montre en effet que les CIO sont bien conscients de l’existence d’une dette technique au sein de leur organisation et que celle-ci est en augmentation. Dans la pratique, ils y consacrent en fait peu ou pas de budget pour y remédier effectivement. Ils font ainsi peser sur l’organisation un héritage technologique qui peut parfois être très important pour être éliminé. L’étude montre également que si un budget est tout de même dépensé en dette technique, il sera plutôt consacré à de nouveaux projets afin de ne pas laisser s'accumuler la dette technique et moins à des applications héritées plus anciennes.
D’où provient la dette technique ?
L’apparition de la dette technique peut se situer à différents niveaux : stratégie, architecture, talent et processus. Un moteur au niveau stratégique peut par exemple être que la stratégie commerciale d’une entreprise n’est pas claire, de sorte que le département IT ne sait pas non plus très bien comment y faire face ou anticiper. L’IT et la stratégie ne sont peut-être pas suffisamment alignés, de sorte que l’accent est mis sur les mauvaises initiatives IT. Ou il y a un décalage entre financement et stratégie, en ce sens que l’on souhaite agir, mais qu’il n'y a pas d’argent en contrepartie. Les acquisitions et reprises stratégiques peuvent également accroître la complexité du paysage IT et des processus, avec tous les risques de dette technique que cela implique.
Sur le front architectural, il y a également des paramètres qui jouent un rôle et qui peuvent générer une dette technique. 70 % des systèmes IT fonctionneraient encore sur des technologies obsolètes. En d’autres termes, il y a encore pas mal de systèmes hérités dans le paysage applicatif d’une organisation moyenne qui continuent, quoi qu’il en soit, à générer des coûts pour le business. Un lourd travail sur mesure et des blocs monolithiques de code peuvent également favoriser la dette technique, tout comme des modèles et une qualité de données médiocres ou la non-utilisation de normes et d’API.
En outre, les logiciels sont toujours principalement fabriqués par des hommes et des femmes. Le manque de connaissances, de savoir-faire, voire de motivation peut également être à l’origine d’une dette technique. Les équipes qui n'interagissent pas ou pas suffisamment, de sorte qu’une équipe crée une dette technique pour l’autre.
Enfin, vous avez également les processus internes qui peuvent être à l’origine de la dette technique. Mauvaise priorisation des évolutions nécessaires, mauvais processus de développement et de maintenance qui altèrent la qualité du code. Par exemple, il y a peu d’automatisation, de sorte qu’il faut réaliser un grand nombre de tests manuellement, ce qui augmente le risque d’erreurs. Des opérations IT instables, une mauvaise récupération après sinistre, un manque de monitoring et une documentation conflictuelle ou manquante peuvent également forcer les équipes IT à travailler à l’aveugle et génèrent ainsi une dette technique.
