Le nouveau risque de l'IA se cache dans le code

L'IA transforme le développement logiciel, mais le shadow AI coding crée de nouveaux risques. L'IA-BOM et la réglementation européenne renforcent la visibilité et la gouvernance.

La course à la performance a pour effet de placer l’innovation en valeur suprême, sans s’interroger sur l’impératif d’un cadre déontologique. Le shadow AI coding ou le recours à des outils d’IA en dehors des procédures validées par les directions SI pour générer, modifier, tester ou analyser du code en est une parfaite illustration. Maintenant que le régulateur européen a inscrit à sa feuille de route la gouvernance par le risque, les entreprises sont confrontées à une équation stratégique délicate : tirer parti des outils d’intelligence artificielle pour préserver leur compétitivité, tout en maîtrisant les risques liés à la robustesse, aux droits d’accès et aux mécanismes de contrôle...

Le Shadow IA s’installe à bas bruit dans le code

"Le code propriétaire écrit par les humains n’est plus la norme", peut-on entendre dans les conversations entre développeurs. L’utilisation de systèmes agentiques pour écrire du code devient progressivement une pratique intégrée aux processus métiers, portée par les gains de productivité attendus. Selon leur configuration, ces agents peuvent opérer sous leur propre identité, accéder directement aux systèmes et exécuter des actions sans intervention humaine. S’il est trop tard pour arrêter cette évolution, il devient urgent d’en organiser la maîtrise par une gouvernance et des outils d’analyse et de surveillance adaptés.

Plus diffus que le shadow IT, le shadow AI coding est déjà une réalité opérationnelle qui déplace le risque au cœur du développement, parfois à l’insu des fonctions de sécurité et de gouvernance. En France, 75 % des RSSI considèrent le shadow AI comme un risque, tandis que seuls 16 % des entreprises ayant recours à l’IA ont déployé une stratégie pour l’encadrer, selon la 11e édition du Baromètre CESIN-OpinionWay. Ces chiffres illustrent un décalage entre la vitesse d’adoption de l’IA et la capacité des organisations à en assurer la visibilité et la traçabilité. Les outils traditionnels, comme le Software Bill of Materials (SBOM), qui cartographie les composants d’une application, ne suffisent plus à représenter toute la complexité d’un logiciel intégrant des modèles, des agents ou des composants IA. D’autant qu’une part croissante du code mis en production est générée par l’IA ou issue de l’Open Source.

Les principes historiques de la sécurité applicative — visibilité, maîtrise, responsabilité et contrôle — doivent donc être étendus à ces nouveaux composants. Le risque est d’autant plus important que des agents IA peuvent, selon leur configuration, accéder à des systèmes internes et à des données sensibles, s’identifier de manière autonome ou exécuter des actions à privilèges. Dès lors, comment classifier, documenter et superviser des systèmes dont les directions ignorent parfois le déploiement et les conditions d’utilisation ? L’enjeu n’est pas d’abandonner les modèles existants, mais de les compléter pour intégrer les modèles, agents, données et dépendances propres à l’IA et ainsi rétablir une visibilité suffisante sur la chaîne logicielle.

L’IA-BOM comme levier de maîtrise

Les entreprises font aujourd’hui face à un décalage croissant entre la vitesse d’adoption des nouveaux usages technologiques et la capacité des directions à les encadrer. Plutôt que de condamner les usages non autorisés, il faut en comprendre les ressorts et adapter les mécanismes de surveillance des logiciels. Le SBOM montre ici ses limites : face à l’IA, il ne suffit pas à identifier les fuites potentielles de données, les manipulations de prompts ou les actions exécutées de manière autonome par un agent. Les méthodes d’analyse doivent donc évoluer. Ce mouvement est déjà engagé, notamment sous l’impulsion des autorités de cybersécurité des pays du G7, dont l’ANSSI, qui ont défini un socle commun d’informations minimales pour l’élaboration d’un SBOM appliqué aux systèmes d’IA. C’est dans ce contexte qu’émerge l’IA-BOM, un inventaire conçu pour documenter les différents éléments d’un système d’IA : modèles, données, composants logiciels, infrastructures et dépendances. Le SPDX 3.0 fournit, de son côté, un langage et un cadre pour décrire ces éléments et leurs relations. Mais établir cet inventaire ne constitue qu’un premier niveau de réponse. Identifier un modèle, un agent ou une dépendance ne suffit pas : encore faut-il savoir s’il est autorisé, mesurer son exposition, détecter les comportements à risque et, si nécessaire, agir. La gouvernance de l’IA doit ainsi passer de la découverte à une capacité continue de prévention, de détection, de remédiation et de pilotage.

Le shadow AI coding reste donc un point de vigilance. Les travaux du G7 constituent des recommandations communes, et non une norme juridiquement contraignante. Ils participent néanmoins à la formalisation et à l’harmonisation des approches autour de l’IA-BOM, dont la structuration était déjà engagée depuis 2024. L’enjeu n’est pas de créer un nouvel inventaire qui remplacerait le SBOM, mais de construire une vision suffisamment complète de la chaîne logicielle pour comprendre où l’IA intervient, avec quelles autorisations, quelles dépendances et quels niveaux de privilèges. La transformation viendra finalement moins de l’initiative isolée des équipes opérationnelles que de la capacité des réglementations européennes à faire évoluer les exigences de gouvernance et, par ricochet, les pratiques internes des entreprises.

Bruxelles, moteur d’une nouvelle gouvernance ?

"La gouvernance par le risque" a pu sembler abstraite lorsqu’elle a été formulée. Elle prend désormais une dimension très concrète avec les nouveaux règlements européens. L’AI Act organise ainsi les obligations applicables aux systèmes d’IA en fonction de leur niveau de risque, avec des exigences graduées en matière de transparence, de traçabilité et de supervision. Sans cibler explicitement le shadow AI coding, il renforce, pour les systèmes concernés, les obligations de documentation, de gestion des risques et de supervision humaine. Or, une organisation ne peut maîtriser ce qu’elle ne voit pas. Lorsque des outils d’IA sont utilisés pour coder en dehors des processus établis, la DSI et les fonctions de conformité peuvent perdre de vue les usages réels, créant un écart entre les pratiques et les exigences auxquelles l’entreprise doit répondre. Pour les systèmes à haut risque, l’article 26 prévoit notamment des mesures techniques et organisationnelles, une supervision humaine et, dans certaines situations, la conservation des journaux générés par le système. Le Cyber Resilience Act (CRA) complète cette approche en renforçant les exigences de sécurité applicables aux produits numériques et à leurs composants. Lorsqu’un code généré ou suggéré par une IA est intégré à un produit, son fabricant reste responsable de sa sécurité et de la gestion de ses vulnérabilités. Là où l’AI Act encadre les risques liés aux systèmes d’IA, leur transparence et leur supervision, le CRA porte sur la sécurité du produit numérique et de sa chaîne de composants. La question n’est donc plus seulement de savoir si l’IA intervient dans le code, mais si l’organisation est en mesure de le savoir, d’en comprendre les implications et d’en maîtriser les risques.

De ces constats se dégage une interrogation centrale : quelles mesures engager ? Il appartient à chaque organisation d’apporter une réponse proportionnée à son exposition. La démarche viserait à évaluer non seulement le coût de l’action, mais aussi celui de l’inaction. Car le véritable enjeu du shadow AI coding n’est finalement pas l’adoption de l’IA par les développeurs. C’est l’écart qui peut se créer entre la vitesse à laquelle elle s’intègre au code et la capacité de l’organisation à savoir où elle se trouve, ce qu’elle peut faire et sous quelles règles elle opère.