Technologies

Comment l'IA peut alourdir la dette technologique de la DSI

Comment l'IA peut alourdir la dette technologique de la DSI
Attention à l’empilement d’agents et à la multiplication des projets pilotes qui, invariablement, alourdiront la dette technologique de la DSI. (Photo : Mina FC/Unsplash)

Le code généré par IA et les expérimentations effrénées de la technologie peuvent engendrer des systèmes coûteux et difficiles à maintenir. Notamment lorsque la rapidité prime et que le manque de supervision devient la norme.

PublicitéCertains défenseurs de l'IA présentent cette technologie comme une solution pour éliminer une dette technique coûteuse, mais les DSI constatent aussi qu'un nombre excessif de projets pilotes ou une dépendance excessive au code généré par l'IA peuvent engendrer leurs propres problèmes.

Les outils d'IA peuvent être utilisés pour nettoyer le code ancien et alléger des applications volumineuses, réduisant ainsi une forme de dette technologique. En septembre, par exemple, Microsoft a annoncé une nouvelle suite d'agents IA autonomes conçus pour moderniser automatiquement les applications Java et .NET existantes. Parallèlement, les responsables IT perçoivent les effets pervers de l'IA, susceptible d'aggraver leur dette technologique, car trop de projets IA s'appuient sur des modèles ou des agents coûteux à déployer et à maintenir, et les assistants de développement à base d'IA génèrent plus de lignes de code que nécessaire.

Sans feuille de route pour l'IA, les organisations risquent de s'égarer dans des déploiements hasardeux, susceptibles d'entraîner des problèmes de qualité et de maintenance à long terme, explique Simon Wallace, directeur technique et cofondateur de la plateforme d'action civique en ligne Suffrago. « Sans stratégie claire de mise en oeuvre de l'IA, ni idée fondamentale des raisons pour lesquelles vous l'utilisez, vous vous retrouverez avec une multitude d'outils qui prennent la poussière numérique, explique-t-il. Nous l'avons constaté avec les microservices et le cloud : des outils ont été utilisés pour pitcher lors de présentations, mais n'ont jamais vu le jour. »

Les risques de la rapidité à tout prix

Simon Wallace se souvient avoir développé des outils pour des projets pilotes de machine learning, puis les avoir vus déployés dans le cloud sans jamais être utilisés. « Vous vous retrouvez alors avec un outil obsolète, qui a peut-être trois ou quatre versions de retard par rapport au modèle et utilise des connecteurs obsolètes », précise-t-il.

De plus, qu'il s'agisse d'expérimentation ou de production, de nombreuses organisations privilégient la rapidité d'exécution pour leurs projets d'IA, une recette classique pour accumuler les problèmes de maintenance et de nettoyage, des problèmes qui finiront inéluctablement par se poser, même pour les implémentations réussies.

Paralysie des pilotes

Les projets pilotes d'IA interminables engendrent également leur propre forme de dette technologique, ajoute Ryan Achterberg, directeur technique du cabinet de conseil informatique Resultant. Cette « paralysie des pilotes », où les organisations lancent des dizaines de PoC qui ne sont jamais déployés à grande échelle, peut épuiser les ressources informatiques, précise-t-il. « Chaque expérimentation débouche sur un coût récurrent, précise Ryan Achterberg. Même si un modèle n'est jamais déployé à grande échelle, il laisse des artefacts qui nécessitent maintenance et surveillance de la sécurité. »

PublicitéUne partie du problème réside dans le fait que les fondements data de l'IA restent fragiles, même si les ambitions des organisations concernant la technologie sont élevées, ajoute-t-il. « Cela signifie que la plupart des pilotes démarrent déjà sur des bases fragiles, ce qui les rend plus susceptibles de stagner ou d'échouer, précise le directeur technique. Pourtant, une fois ces pilotes lancés, les DSI doivent en gérer le risque. »

Initiatives dispersées dans les métiers

Ryan Achterberg conseille aux organisations qui expérimentent l'IA de procéder à des revues de code rigoureuses, d'utiliser un pipeline de déploiement continu et de documenter sans relâche leurs projets. « Des dizaines de petits projets pilotes d'IA non coordonnés peuvent gonfler la dette technologique autant que des systèmes Legacy vieux de plusieurs décennies, prévient-il. Sans gouvernance ni priorisation rigoureuse, les organisations finissent par payer le prix fort pour maintenir des expérimentations coûteuses et sans valeur ajoutée.»

Dans de nombreuses organisations, le développement de l'IA engendre une dette technologique lorsque de nombreux projets surgissent dans différentes entités opérationnelles, ajoute Kurt Muehmel, responsable de la stratégie IA au sein de l'éditeur Dataiku, plateforme de développement de projets data et IA. Dans certaines entreprises, les collaborateurs chargés de lancer des projets d'IA ne sont pas directement rattachés à un DSI ou à un autre responsable IT senior, remarque-t-il. « On peut imaginer un scénario où certains de vos data scientists commencent probablement à configurer des serveurs MCP, explique-t-il. Ils utilisent ensuite ces outils pour développer rapidement des agents, mais la surveillance n'est pas forcément intégrée nativement à ces systèmes. »

Du code peu optimisé

Outre la dette technologique engendrée par la multiplication des projets pilotes, les assistants de codage peuvent, sans supervision adéquate, créer leurs propres problèmes, ajoute Jaideep Vijay Dhok, directeur des opérations technologiques chez Persistent Systems, fournisseur d'ingénierie numérique. Dans certains cas, ces assistants génèrent plus de lignes de code que ce que le développeur a demandé, explique-t-il : « si, en tant que développeur, je ne suis pas rigoureux sur ce que j'accepte de l'outil, cela génère du code superflu. « Les modèles ont une tendance intrinsèque à surcharger » le code.

De plus, si tous les membres d'une équipe de développement logiciel, y compris les testeurs, les chefs de produit et les ingénieurs en charge du release management, n'utilisent pas les mêmes outils de codage IA, les résultats peuvent être désalignés, ajoute Jaideep Vijay Dhok. A l'inverse, « lorsque l'utilisation de l'IA générative est transférée d'un individu à une équipe, avec une approche collective, le risque de création d'une dette technologique applicative diminue », indique-t-il.

Supervision des projets d'IA

Kurt Muehmel recommande aux organisations d'utiliser des outils de gouvernance qui permettent non seulement de suivre les problèmes de sécurité et de conformité des données, mais aussi de surveiller les dépenses et les indicateurs des projets d'IA. Et suggère que le DSI ou un autre responsable informatique senior soit responsable de cette supervision.

Selon lui, ces outils de gouvernance sont essentiels pour garantir que les projets d'IA atteignent des indicateurs réalistes. « La gouvernance est un sujet récurrent dans toutes mes discussions avec un DSI ou toute personne qui réfléchit stratégiquement aux agents. Ces profils veulent s'assurer de maîtriser tout ce qui est en cours de développement, explique Kurt Muehmel. Il existe une réelle crainte de voir apparaître des agents fantômes, créés par des personnes intelligentes au sein de l'organisation qui prennent des initiatives non entièrement maîtrisées. »

Eviter la défiance des utilisateurs

Les responsables IT et métier qui supervisent les projets d'IA doivent également s'assurer que les agents, en particulier, sont étroitement liés aux processus métier, ajoute-t-il. Les agents pirates qui ne s'intègrent pas aux processus métier peuvent, en effet, susciter la méfiance des utilisateurs. « Ce qui distingue les agents, c'est qu'ils sont censés être, d'une certaine manière, de nouveaux collègues ou collaborateurs pour les équipes marketing, financières et opérationnelles, détaille Kurt Muehmel. Si ces personnes ne peuvent pas se fier à leurs performances, un réel déficit de confiance va en résulter, ce qui peut entraîner la création de nombreux outils que les utilisateurs hésitent à utiliser. »

Les DSI doivent constamment évaluer les projets d'IA de leur organisation et ne pas craindre d'en acter rapidement l'échec, que ce soit lors des premières phases de développement ou de déploiement, ajoute-t-il. « Dans cette approche 'fail fast', il est aussi essentiel que tous ceux qui participent à la création et au déploiement des agents comprennent parfaitement que le processus ne peut s'arrêter à sa construction, précise Kurt Muehmel. L'environnement est amené à évoluer, car les objectifs métier peuvent se modifier. Il est donc essentiel d'anticiper ce processus d'adaptation continue du fonctionnement de l'agent. »

Partager cet article

Commentaire

Avatar
Envoyer
Ecrire un commentaire...

INFORMATION

Vous devez être connecté à votre compte CIO pour poster un commentaire.

Cliquez ici pour vous connecter
Pas encore inscrit ? s'inscrire

    Publicité

    Abonnez-vous à la newsletter CIO

    Recevez notre newsletter tous les lundis et jeudis