– Dettes techniques / Source : LMI –
Les dettes techniques ne concernent 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 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 entreprises devraient considérer les sept formes de dette technique suivantes, comprendre pourquoi elles sont critiques.
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.
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.
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.
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.
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 évolutions technologiques créent une dette d’architecture que tous les entreprises doivent gérer au fil du temps, s’ils ne veulent pas qu’elle devienne insoutenable.
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 ».
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 guider les employés dans l’utilisation de l’IA pour augmenter, et pas seulement automatiser leurs capacités…
Entreprises de Corrèze et de Nouvelle-Aquitaine, l’équipe de l’Entreprise Numérique se tient à votre écoute pour échanger sur vos projets d’infrastructure, d’organisation numérique et d’accompagnement de vos collaborateurs… Contactez-nous !
>> Retrouvez notre revue de presse dans la rubrique actualités <<