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.
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écisionOn 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.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 performancesLa 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 devopsPour 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évitableMê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 legacyIl 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 inexplicableLa 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èmesDans 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.
En adoptant une approche méthodique du shadow IT et en identifiant clairement ses causes, les DSI peuvent réduire les risques inhérents à cette pratique. Cette dernière peut même devenir une source de bénéfices pour l’IT et pour l’entreprise.
Lorsqu’on parle shadow IT avec des responsables informatiques, la plupart évoquent les questions de sécurité, les risques opérationnels et les enjeux d’intégration. Mais pour certains, le développement de cette pratique révèle surtout l’incapacité de l’IT à répondre à certains besoins technologiques des métiers.Il ne s’agit pas de minimiser les risques inhérents au shadow IT. Selon un rapport de l’éditeur de solutions d’identité numérique Entrust, 77 % des professionnels de l’informatique sont en effet préoccupés par le sujet. Et pour cause, 41 % des employés achètent, modifient ou créent des outils pour combler leurs besoins sans en informer le service informatique. Enfin, selon une enquête de EY dans le monde entier, 52 % des personnes interrogées sur la gestion des risques ont subi une panne – et 38 % une violation de données – causée par des tiers au cours des deux dernières années.Reste que le shadow IT n’est pas une informatique malveillante, comme évoqué à l’occasion de l’événement Coffee with digital trailblazers (un café avec les pionniers de l’informatique), organisé par CIO. L’informatique malveillante se développe lorsque les dirigeants ne font pas confiance à la DSI, la contournent délibérément et dérogent aux règles de l’IT interne. Le shadow IT est, généralement, moins conflictuel, et découle davantage d’un manque d’informations sur la façon d’impliquer le service IT. Ou encore, comme l’explique Dinesh Varadharajan, directeur général de l’éditeur de solutions no code/low code Kissflow, « d’un manque de soutien et de bande passante de la DSI pour résoudre les défis spécifiques auxquels sont confrontés les métiers ».Une des stratégies face à cette situation consiste, non pas à la nier ou à la combattre, mais à en faire une opportunité d’améliorer la collaboration avec les équipes informatiques. Ce n’est une transformation ni rapide ni facile, car elle nécessite de traiter simultanément deux aspects de l’équation. D’une part, la manière dont la DSI gère les besoins technologiques des métiers et d’autre part, la façon dont ceux-ci sont étudiés et mis en regard de réponses technologiques. CIO a identifié sept étapes pour développer la démarche.
1. Développer la relation avec les métiers
« Une des façons de résoudre la question du shadow IT pour une entreprise, sans forcément l’éliminer, c’est de trouver des moyens d’intégrer les solutions choisies ou développées, mais non approuvées par les canaux officiels, en garantissant leur sécurité, leur conformité et une gestion efficace tout en conservant les capacités d’innovation et l’agilité qui ont conduit les employés à agir de cette façon », estime Brian Platz, PDG et cofondateur de l’éditeur de plateforme de données sécurisée Fluree.Mais, pour ce faire, les responsables informatiques doivent d’abord identifier ce qui se passe dans l’ombre en accroissant le nombre de managers avec lesquels ils collaborent, en augmentant la fréquence des échanges et en se plongeant davantage dans les workflows des métiers. Certaines grandes entreprises créent des fonctions de responsables des relations avec les métiers. Un rôle clé dans la compréhension et la traduction des besoins technologiques en business cases. Les PME peuvent, quant à elles, élaborer un programme de communication pour impliquer les métiers et les parties prenantes, avec un processus d’idéation comme le design thinking pour identifier les nouveaux besoins.
2. Définir une gouvernance et mettre l’accent sur la collaboration
Il faut également définir un modèle de gouvernance et de delivery pour l’évaluation, l’achat et la mise en oeuvre de solutions technologiques métier. Il est tout aussi important de communiquer sur la manière de prendre en compte les demandes technologiques, de partager la manière dont elles sont hiérarchisées, de documenter les responsabilités des différentes parties prenantes dans la recherche de solutions et de fournir un état des programmes en cours.C’est justement en l’absence d’un modèle de delivery et d’un plan de communication solide, que les utilisateurs sont susceptibles de se lancer dans du shadow IT. L’achat et la mise en oeuvre de solutions technologiques prennent du temps. Aussi, l’outil le plus simple dont dispose le DSI pour lutter contre ces pratiques est de donner aux métiers toute l’assurance que la collaboration va dans leur intérêt.« L’élément humain est le plus important, déclare Brian Suk, CTO du cabinet de conseil en cloud Sada. La plupart des employés sont d’accord pour se conformer aux politiques IT, mais si la DSI est trop stricte ou crée trop de frictions, elle provoque le shadow IT. Il faut communiquer clairement et fréquemment sur ces politiques IT, leur origine et leurs avantages, créer une culture du feed-back et de la collaboration, et être souple et adaptable en fonction de l’évolution des besoins des utilisateurs. »
3. Cartographier les risques et promouvoir les contrôles financiers
Le shadow IT donne l’occasion de réévaluer les stratégies IT en ce qui concerne les solutions métiers. Il faut identifier les applications de shadow IT déjà installées et les gérer, travailler en partenariat avec les équipes de l’entreprise sur des alternatives, améliorer et assurer le support des applications et des technologies en place, étendre leur utilisation et améliorer l’expérience des employés, et enfin mesurer et ainsi démontrer la valeur générée. Un processus de priorisation formalisé et transparent est également important. Les DSI doivent identifier des business cases simples et mesurer la valeur business pour prioriser les nouvelles opportunités. Sans oublier, avec les RSSI et les responsables de la conformité, d’établir un cadre de gestion des risques associés au shadow IT.Par ailleurs, se rapprocher des DAF permet aussi de mettre en lumière les coûts d’acquisition et les risques liés au shadow IT. Le point de vue de l’architecte d’entreprise permet, lui, d’éclairer l’organisation sur les capacités de réutilisation, levier essentiel pour garder les coûts sous contrôle. « Le shadow IT gaspille souvent les ressources, car les logiciels ne sont accompagnés d’aucune documentation qui faciliterait la réutilisation par d’autres, explique Anant Adya, vice-président exécutif de l’éditeur de solutions cloud Infosys Cobalt. Une gouvernance ambitieuse, ainsi qu’une documentation systématique des privilèges d’accès applicatifs découragent la pratique et contribue à la mise en place de modèles d’exploitation collaboratifs. »
4. Définir des modèles de gouvernance low-code et no-code
Les trois premières étapes de la démarche contribuent à réduire le shadow IT, mais elles ne tiennent pas compte du fait que les services informatiques disposent rarement du personnel, de l’expertise ou du budget suffisants pour mener à bien tous les programmes prioritaires.Pour pallier cette pénurie de ressources, les DSI peuvent encourager le citizen development et définir des modèles de gouvernance pour les solutions low code et no code. Ces modèles doivent couvrir l’examen des idées de nouvelles solutions, les rôles et responsabilités, l’intégration, la gestion des versions, la documentation et d’autres exigences visant à garantir la fiabilité et la sécurité des processus métier. Le no-code est efficace face au shadow IT, car il fait basculer la mise en oeuvre et le support du côté des métiers. Les utilisateurs vont, par exemple, convertir des feuilles de calcul en workflow, développer des bases de connaissances ou intégrer du SaaS.Toutefois, là-encore, la gouvernance est essentielle ainsi qu’un plan d’architecture de solutions pour accompagner la sélection de plateformes low code et no code. Sans oublier de répertorier les utilisations pertinentes de celles-ci, de décrire le cycle de vie de développement et d’assurer un support continu. « Les business cases doivent être organisés en fonction de trois critères : la complexité business, la complexité technique et les exigences de sécurité et de conformité, insiste Dinesh Varadharajan. Tout business case pour lequel l’un de ses critères est important doit passer par le service informatique, tandis que les autres peuvent être délégués aux entités opérationnelles. »
5. Développer la citizen data science et des fonctions en libre-service
Les DSI ont adopté la citizen data science parce que les outils de dataviz et autres plateformes BI en libre-service sont désormais faciles à utiliser par les métiers pour du reporting et des requêtes ad hoc que les services IT prenaient en charge jusque-là. Ces approches diminuent le shadow IT à condition que les DSI encouragent une gouvernance proactive des données et mettent en place des pratiques d’intégration, de catalogage et de qualité des données. Choisir des solutions solides pour gérer les data et des plateformes standards permettant aux employés des métiers, du Data Office et de la DSI d’exploiter les données dans leurs prises de décision contribue à réduire la prolifération des outils et le shadow IT.
6. Définir et partager une stratégie d’IA générative
Prochaine étape, sans aucun doute, la shadow IA. Les métiers explorent déjà l’IA générative et risquent d’exposer des informations propriétaires ou confidentielles. Des études récentes de la société de capital-risque Sequoia Capital montrent le nombre important d’outils d’IA générative qui arrivent sur le marché dans le domaine des ventes, du marketing, de la conception, de l’ingénierie logicielle, du support client, du juridique, etc.C’est un domaine idéal pour le shadow IT, car les dirigeants sont avides d’exploiter la technologie pour dégager de nouvelles sources d’efficacité. Rien n’empêche aujourd’hui un chef de service ou un employé d’essayer un nouvel outil et de lancer un autre shadow program. Lorsque la conformité réglementaire est assurée, les DSI ont tout intérêt à éviter de refuser une expérimentation d’IA générative. Des refus répétés menacent de provoquer une explosion des usages en shadow IA.Les DSI doivent plutôt définir, mettre à jour et partager une stratégie d’IA générative qui englobe à la fois les perspectives à court et à long terme. Les plans à court terme devraient préciser dans quels métiers expérimenter, vers quels résultats et opportunités d’affaires tendre, ainsi que les outils à utiliser, les données à exploiter ou les entraînements de modèles à expérimenter. Il leur faut aussi mettre à jour la stratégie de transformation digitale pour tenir compte de l’impact des LLM sur le secteur d’activité.
7- Favoriser une culture de la co-création
La dernière étape est probablement la plus importante et doit être gérée parallèlement aux six premières. Le shadow IT est plus qu’un risque ou une opportunité manquée, il traduit un fossé opérationnel et culturel entre les métiers et l’informatique que les DSI doivent s’efforcer de combler. Pour ce faire, il faut développer un sens du métier au sein de l’IT en établissant des relations avec les différentes parties prenantes de l’entreprise, en développant une forme d’empathie pour les besoins des clients et des employés et en améliorant la communication. Cela suppose également que les DSI opèrent un « shift left » (anticipation des problèmes en cours de développement), afin que les employés les plus à l’aise avec le numérique dans les fonctions commerciales, marketing, RH, etc. disposent d’outils approuvés et d’un processus sous contrôle pour répondre à leurs besoins technologiques en libre-service.Les DSI qui suivent ces sept étapes peuvent transformer le shadow IT en avantage concurrentiel en répondant à un plus grand nombre de besoins des métiers de leur organisation, en réduisant les risques liés à ces applications et en permettant à davantage de métiers de répondre en libre-service à leurs besoins propres, en matière de workflow et de données.