Stratégie

7 formes de dette technologique qui freinent la transformation des entreprises

Plus complexe qu'il n'y parait, la dette technique peut prendre au moins 7 formes différentes. (Photo : Pixabay)

La dette technique ne concerne pas seulement l'infrastructure matérielle ou logicielle. Loin de là. L'accumulation historique de data, de procédures de sécurité, de développements d'IA et même d'une forme de culture d'entreprise peuvent aussi en faire partie. Les DSI devraient au moins être attentifs à 7 types de dette technique.

PublicitéLes DSI sont constamment confrontés aux risques, au coût et à la complexité de la dette technique. Et bien que son impact puisse être quantifié globalement, cette dernière s'insinue aussi de manière plus subtile dans l'écosystème IT, rendant en réalité difficile la prise en compte de tous les problèmes et risques associés.

Selon le cabinet d'analyse Forrester, près de 30% des responsables informatiques sont confrontés à des dettes élevées ou critiques, et 49 % à des niveaux modérés. Mais même un risque moins important (modéré à faible) peut se transformer en frein majeur s'il concerne une application clé, car il peut devenir un obstacle lorsque celle-ci doit être modernisée.

Selon Accenture, les trois principales sources de dette technique se trouvent dans les applications, l'IA et l'architecture d'entreprise. Des enjeux considérables, mais le sont-ils moins si on parle de données, de sécurité, de culture d'entreprise ou d'autres domaines pour lesquels les raccourcis d'hier, pris par la DSI, deviennent les dettes d'aujourd'hui ? Par ailleurs, une autre question se pose : qu'est-ce qui distingue une dette qui provient d'une 'réparation' opportuniste d'une dette critique qui pourrait paralyser l'entreprise ?

Pour faire face à ces enjeux, les DSI devraient considérer les sept formes de dette technique suivantes, comprendre pourquoi elles sont critiques et comment les traiter.

1. Quand la dette de données nuit à la prise de décision

On peut prendre l'exemple de cette entreprise qui a annoncé à son conseil d'administration une année rentable, pour découvrir au retour de vacances que des problèmes de qualité des données et des erreurs de calcul ont en réalité masqué des résultats déficitaires. Les DSI qui travaillent sur la transformation data driven de leur entreprise et s'appuient en particulier sur de la citizen data science sont les plus touchés par la dette de données, car une mauvaise interprétation ou un mauvais calcul de date, de montant ou de seuil peuvent conduire à de mauvaises décisions business. Les types de dettes de données incluent la dark data (inutilisée, inconnue ou inexploitée), les doublons et les données qui n'ont pas été intégrées dans le Master Data Management.

Et dans ce contexte, l'utilisation des données de l'entreprise pour entraîner des LLM ou pour exploiter des agents IA ou encore d'autres modèles d'IA générative crée encore plus de risques. Les biais, les lacunes dans la classification ou les politiques d'autorisation inadéquates peuvent tous entraîner de mauvaises prises de décision, des risques liés à la conformité et des problèmes avec un impact sur les clients.

PublicitéPour réduire cette dette data, les DSI peuvent assigner spécifiquement des responsabilités de gouvernance et d'analytique dans des équipes data agiles, via l'observabilité des données et la définition d'indicateurs de qualité.

2. Quand le data management limite les performances

La dette liée au data management peut survenir d'un seul coup ou, au contraire, s'accumuler au fil du temps, elle peut résulter d'un manque d'automatisation ou encore provenir d'une réponse à incident.

- La dette soudaine : les services informatiques qui procèdent à du lift-and-shift de volumineuses bases de data vers le cloud sans optimiser l'architecture de ces bases, peuvent tout à fait générer une forte augmentation de la dette en data management qu'il leur faudra bien réduire au fil du temps.

- La dette progressive : pour soutenir dans le temps l'augmentation continue de la taille, de la complexité et de l'utilisation de certaines bases, les DSI doivent en repenser le modèle et l'architecture.

- L'absence d'automatisation : les administrateurs de bases de données consacrent trop de temps à des procédures d'exploitation restées manuelles et qui devraient être automatisées. C'est le cas de la création de sauvegardes, de l'administration des privilèges, de la synchronisation des données entre systèmes ou des opérations liées au provisionnement de l'infrastructure.

- La réponse aux incidents : la lutte contre les problèmes quotidiens, le traitement d'incidents majeurs ou la recherche des causes profondes de ces problèmes empêchent les administrateurs de bases de données d'effectuer des tâches plus proactives.

Pour réduire la dette de data management, les DSI peuvent commencer par mesurer le temps que les administrateurs de bases de données consacrent aux procédures d'exploitation manuelles et à la réponse aux incidents afin d'évaluer cette dette. Pour la réduire, ils peuvent automatiser les tâches, entamer la migration vers des offres de base de données as-a-service (DBaaS) et procéder à l'archivage des anciens data sets.

3. Quand la dette de dépendance à l'Open Source pèse sur le devops

Pour un développeur, il semble plus facile d'écrire du code que de revoir celui de quelqu'un d'autre et de comprendre comment il fonctionne. Et il lui semble souvent encore plus facile chercher et d'intégrer des bibliothèques et des composants Open Source, car le support à long terme du logiciel n'est pas sa préoccupation première lorsqu'il est contraint par les délais et des déploiements fréquents.

De nombreuses équipes laissent ainsi s'accumuler des composants Open Source obsolètes, redondants ou non pris en charge, comme l'explique Mitchell Johnson, chief product development officer de l'éditeur d'outils de gestion de la supply chain logicielle Sonatype. « Une application moyenne contient 180 composants, et ne pas les mettre à jour génère un code volumineux, des failles de sécurité et une dette technique croissante ». Selon le rapport 2025 Open Source security and risk analysis de l'éditeur d'AST (application security testing) Black Duck, 81% des codes analysés contiennent des vulnérabilités à risque élevé ou critique, et 90% des composants sont en retard de plus de 10 versions par rapport à la mouture la plus récente.

Pour traiter la question, les DSI doivent notamment rechercher la fréquence des mises à jour de code perturbant les systèmes, l'augmentation des alertes de sécurité ou le temps consacré à la résolution des conflits de dépendance. Pour réduire cette forme de dette, ils peuvent former les équipes DevOps spécifiques sur les risques de sécurité Open Source, établir des politiques de gouvernance sur l'évaluation et l'approbation des packages, et utiliser les outils SAST pour trouver les vulnérabilités de code.

4. Quand la dette de l'IA se révèle inévitable

Même si les DSI définissent une gouvernance pour la GenAI, l'évolution rapide des modèles, des réglementations associées et du potentiel de l'IA agentique vont forcément leur apporter des problèmes de dette liée à l'IA. La dette technique dans les systèmes d'IA se manifeste différemment de la dette IT traditionnelle, car il ne s'agit pas seulement de maintenir le code, mais aussi l'ensemble du cycle de vie de la gouvernance des données et des modèles, selon Eric Johnson, DSI de l'éditeur de gestion d'incidents dans le cloud PagerDuty. « Les entreprises qui développent des solutions d'IA personnalisées risquent de créer de nouvelles formes de dette technique plus coûteuses et complexes à dénouer que les défis architecturaux habituels. La clé est d'établir des bases solides de gouvernance de la data et d'infrastructure avant de se lancer ».

Alors que de nombreuses formes de dette technique entraînent des problèmes continus de maintenance, la dérive d'un modèle d'IA est un exemple de dette incrémentale. Et une partie de cette dette pourrait même contraindre les DSI à démanteler et remplacer certaines IA lorsque les nouveaux modèles présentent des améliorations importantes en matière de précision, de performance ou de coût, rendant les modèles précédents obsolètes. Une autre inquiétude provient de la possibilité de voir les réglementations demander un réentraînement holistique des modèles, ce qui obligerait les DSI à se tourner vers d'autres solutions pour rester conformes.

Face à cette forme de dette, les DSI peuvent investir dans des tests de régression et des méthodes de gestion du changement associées aux workflows augmentés à grande échelle par l'IA.

5. Quand la dette d'architecture s'érode et crée du legacy

Il est possible de remédier à certaines formes de dette applicative en modernisant les applications, en les faisant migrer vers de nouvelles plateformes ou en utilisant des outils d'IA pour documenter et expliquer le code existant. Parmi les sources les plus importantes de dette architecturale, on peut citer :

- une forte personnalisation du code dans les ERP ou autres systèmes d'entreprise ;
- l'intégration de systèmes point à point sans data fabric ou plateforme d'intégration ;
- les microservices et les API déployés sans normes de sécurité, de test, de versioning ni standards d'observabilité ;
- les architectures multicloud configurées pour un déploiement précoce, et dont la maintenance engendre des coûts, du temps et un fort besoin d'expertise ;

Les DSI à la tête d'architectures tentaculaires doivent envisager des simplifications et l'établissement de pratiques d'observabilité de l'architecture. Ils doivent notamment créer des indicateurs de performance de l'architecture et de la plateforme en agrégeant le monitoring applicatif, l'observabilité, la qualité du code, le TCO, les temps de cycle DevOps et les mesures relatives aux incidents, afin d'évaluer l'impact complet de l'architecture sur l'activité de l'entreprise.

Les évolutions technologiques créent une dette d'architecture que tous les DSI doivent gérer au fil du temps, s'ils ne veulent pas qu'elle devienne insoutenable. L'un des domaines qu'ils peuvent maîtriser, c'est le niveau de personnalisation des applications pour éviter la complexité des règles métier gravées dans le code. Ils peuvent aussi repenser les règles d'architecture, en indiquant clairement la répartition du pouvoir de décision en la matière entre les équipes de développement agiles et les architectes d'entreprise.

6. Quand la dette de sécurité dans les implémentations d'IA est inexplicable

La dette de sécurité se présente sous de nombreuses formes, telles que l'absence de politiques applicables, l'inadéquation de la formation des utilisateurs finaux et l'incapacité à modifier les pratiques de sécurité en shift left dans les pratiques DevOps. Les RSSI doivent alors gérer des cycles sans fin de rattrapage de failles, tout en s'occupant des menaces en cours.

Mais avec les modèles d'IA, la question est encore moins simple. Bien que les organisations puissent prendre des mesures pour empêcher l'utilisation d'informations confidentielles pour les entraîner, il est difficile de savoir quelles informations privées se trouvent dans le modèle ou s'il existe des options pour les supprimer. Les modèles d'IA générative peuvent introduire des vulnérabilités dans le modèle lui-même, renfermer des violations de données ou être sensibles à des adversarial attacks (manipulations du modèle pour le pousser à l'erreur) qui peuvent s'accumuler.

Giovanni Lanzani, directeur data de la SSII Xebia, donne l'exemple d'un chatbot bancaire pour les clients. « Il faudrait un framework de GenAI à grande échelle pour cette instance afin de mettre en oeuvre de solides garde-fous contre les injections de prompts et d'éviter de donner de mauvais conseils financiers ou de dénigrer la banque, par exemple. Ce framework devrait aussi s'occuper d'anonymiser toutes les informations personnelles identifiables afin que le chatbot hébergé dans le cloud ne puisse pas être alimenté par ce type de données ».

Les DSI devraient être plus attentifs à la gouvernance de la sécurité de l'IA. Les pratiques DevSecOps ont, en effet, longtemps été à la traîne dans les chaînes automatisées de CI/CD (intégration continue/distribution continue), alors que les entreprises ont rapidement adopté la citizen Data Science, laissant ainsi de côté d'indispensables pratiques de gouvernance data. Or, lorsqu'il s'agit d'IA, cela peut entraîner des risques inacceptables, d'autant que les agents d'IA sont déployés dans des applications d'entreprise ou mis en contact direct des clients.

7. Quand la dette culturelle accentue les problèmes

Dans une démarche de transformation numérique, le plus difficile est d'embarquer des 'early adopters', de favoriser la gestion du changement et de faire face aux réticences des détracteurs. La GenAI vient alourdir la dette culturelle des organisations à mesure que les experts métiers quittent le marché du travail et transmettent insuffisamment de savoir aux employés susceptibles d'assumer leurs responsabilités. La dette culturelle peut aussi avoir des impacts négatifs spécifiquement liés à l'IA, comme l'absence de pratiques d'ingénierie adaptées, la résistance à l'innovation, le manque de partage des connaissances tacites et l'incapacité à adopter des pratiques modernes.

Les DSI qui ne veulent pas utiliser l'IA comme un simple moteur de productivité, mais comme un outil de transformation, doivent aussi reconnaître l'importance des craintes de perte d'emploi associées à cette technologie, et guider les employés dans l'utilisation de l'IA pour augmenter, et pas seulement automatiser, leurs capacités.

De façon générale, alors que les DSI sont sous pression pour accélérer la mise en oeuvre de l'IA, laisser derrière soi une dette technique trop importante peut devenir un frein à l'innovation et à la transformation.