Les codeurs ont leur style mais comment les responsables sécurité gèrent la prolifération du code

Les codeurs ont leur style mais comment les responsables sécurité gèrent la prolifération du code

Des responsables de la sécurité de Datadog, Jamf et ASOS partagent leur analyse sur une crise de visibilité qui émerge doucement. L’intelligence artificielle met en effet la capacité d’écrire du code entre les mains de chaque employé.

Le modérateur déclara qu’il avait passé le week-end à consommer des crédits sur Claude, une activité qu’il trouvait plus amusante que de voir des amis. Les experts en sécurité sur le panel rirent, peut-être avec une pointe de nervosité. Ils comprennent l’attrait de l’IA pour créer des automatisations. Ils savent aussi ce qui arrive quand cette impulsion se répand dans une entreprise sans garde-fous.

Ce fut l’un des sujets centraux de Workflow, un événement virtuel organisé par la plateforme d’automatisation intelligente Tines. Le modérateur, Andrew Steele, un associé chez Activant Capital, investit depuis dix ans dans l’IA d’entreprise et sait où s’arrête l’expérimentation personnelle et où commence le risque professionnel. Pour les équipes informatiques et de sécurité, le problème est que de nombreux employés ne font pas cette distinction.

L’essor du code sauvage

La prolifération incontrôlée du code n’est pas un concept nouveau. Mais en 2026, elle devient endémique. Les équipes de sécurité et d’informatique évoquent ce code comme un jardinier parle de mauvaises herbes, qui se propagent vite et menacent d’étouffer leur environnement.

Un rapport de RedAccess quantifie le problème. En analysant des plateformes comme Lovable, Base44 et Netlify, les chercheurs ont découvert 380 000 ressources accessibles au public. Il s’agit d’applications, de bases de données et d’infrastructures connexes construites en dehors de tout processus de sécurité. Environ 5 000 contenaient des informations sensibles de l’entreprise.

Ces ressources proviennent de plusieurs sources. Il y a les fonctionnalités d’IA intégrées dans des outils SaaS approuvés mais activées sans contrôle informatique. Il y a aussi les scripts et automatisations développés hors des environnements autorisés. Enfin, des agents sont lancés par des équipes individuelles sans visibilité centrale.

Cette pratique n’est pas nécessairement malveillante. Elle est souvent bien intentionnée. Plutôt que de la tolérer, de nombreuses organisations l’encouragent activement. Des entreprises du Fortune 500 mentionnent désormais la « programmation à l’instinct » dans leurs descriptions de poste. Chaque employé qui répond à cette exigence devient une source potentielle de code non gouverné.

Pourquoi la politique seule est insuffisante

Matt Muller, directeur des opérations de sécurité chez Datadog, déclara que les employés qui veulent simplement faire leur travail sont de loin les menaces persistantes avancées les plus tenaces et efficaces. S’ils pensent qu’accéder au dernier modèle d’IA les aidera, ils trouveront un moyen, quitte à prendre des photos de leur écran avec leur téléphone pour transférer des données vers un compte personnel. Interdire les outils évidents déplace simplement le comportement vers des outils moins visibles, ce qui réduit la visibilité sans réduire l’exposition.

Indu Sajeev, ancienne directrice de la sécurité de l’information chez ASOS, fut claire sur les limites de la gouvernance traditionnelle. Elle estime qu’on ne peut pas se contenter d’une couche de gouvernance sur papier ou basée uniquement sur des politiques. Il faut quelque chose de codifié qui fonctionne en continu au niveau de l’infrastructure critique.

Les actions des responsables de la sécurité aujourd’hui

Commencer par la classification des données

Mario Villatoro, directeur de la sécurité de l’information chez Jamf, rappelle qu’avant toute approche sophistiquée, un travail de fond peu glamour est nécessaire. Il faut catégoriser correctement ses données. Parler de « données sensibles » n’est pas suffisant sans définition précise. L’étiquetage correct des données est critique. Sans cette fondation, tous les contrôles en aval, comme les permissions d’accès ou la gouvernance des agents, reposent sur du sable mouvant.

Devenir le centre névralgique, pas le gardien

L’approche de Matt Muller chez Datadog consiste à positionner l’équipe de sécurité comme un fournisseur d’outils, et non comme un policier. Il fut très efficace de servir de plaque tournante centralisée pour les outils qui permettent l’activité. L’équipe rend des compétences pour Claude disponibles sur un marché interne. La seule demande aux équipes d’ingénierie est de donner un retour d’expérience pour améliorer ces compétences.

Cette approche fonctionne quand le constructeur est un ingénieur. Mais la prolifération du code dépasse le domaine de l’ingénierie et touche des fonctions comme les ressources humaines, le marketing ou la finance, où la sensibilisation à la sécurité n’est pas une exigence du poste.

Le principe fondamental reste le même. Il faut rendre la voie gouvernée plus attractive que la voie sauvage. Muller veut que tout le monde passe par un seul entonnoir pour l’usage de l’IA. Ainsi, même si l’activité ne lui plaît pas, il peut au moins la voir, au lieu de forcer les gens vers des canaux clandestins.

Construire un registre des cas d’usage

Chez ASOS, Indu Sajeev a abordé le problème de visibilité avec un registre des cas d’usage. Cette méthode traite les agents d’IA comme des actifs d’infrastructure, et non comme de simples fonctionnalités logicielles.

Ce registre permet de suivre la transition naturelle vers une création pour un cas spécifique et d’identifier l’identité humaine derrière l’agent. Il ne s’agit pas d’un simple inventaire. Il rend la responsabilité traçable. Quand un problème survient, on peut remonter le fil jusqu’à une personne et un objectif. Cette approche révèle aussi les problèmes sous-jacents des données, qui restent souvent cachés jusqu’à ce qu’un incident les expose. Sajeev souligne qu’il faut un niveau de maturité très élevé dans son infrastructure de données pour que les fonctions agentiques ou d’IA fonctionnent correctement.

Investir dans l’autonomisation

Chez Jamf, l’approche de Mario Villatoro privilégie l’autonomisation plutôt que la restriction. L’idée est de fournir aux employés les bons outils, la formation et les politiques d’utilisation acceptable avant qu’ils ne cherchent leurs propres solutions.

S’ils travaillent sur la partie autonomisation, il est beaucoup plus facile d’empêcher le code sauvage de se répandre partout. Mais s’ils n’autonomisent pas les employés, ces derniers chercheront des moyens de le faire eux-mêmes, et c’est ce qui conduit aux problèmes.

Les problèmes qui restent à résoudre

Les agents d’IA aux comportements inattendus

Matt Muller affirme la nécessité d’observer et de contenir les comportements inattendus de l’IA avant qu’ils ne deviennent un problème. Il cite un scénario où Claude Code, lorsqu’il ne peut pas accéder à quelque chose, peut tenter de construire son propre logiciel malveillant pour exfiltrer les identifiants dont il a besoin. Plutôt qu’une politique interdisant de telles actions avec Claude Code, il estime plus précieux d’investir dans des contrôles techniques qui empêchent l’accès à ces identifiants en premier lieu.

Le fossé des permissions

Même quand les organisations prennent des décisions délibérées sur l’usage des outils d’IA, les contrôles disponibles sont souvent trop larges pour être significatifs. Muller explique qu’on peut approuver la connexion de Claude à Gmail, mais ce qu’il souhaiterait, c’est pouvoir dire qu’il est à l’aise avec son assistant lisant uniquement les emails étiquetés avec un certain libellé, et aucun autre. Cette granularité n’est pas exprimable aujourd’hui.

Indu Sajeev pointe un fossé plus profond dans les cadres de sécurité existants. Le zéro trust fonctionne bien sur les identités humaines, mais il présente encore des lacunes partout ailleurs, alors que les écosystèmes se multiplient. Les organisations dépendent largement des fournisseurs dont les contrôles peuvent manquer de finesse. Muller lance un appel direct en déclarant que si quelqu’un de Google regarde, des permissions OAuth plus granulaires seraient les bienvenues.

La voie à suivre

Les responsables de la sécurité qui réussiront à maîtriser la prolifération du code ne seront pas ceux qui auront tenté d’empêcher les employés de construire. Ce seront ceux qui auront rendu la voie gouvernée la plus attractive, assez sûre pour être utilisée ouvertement, et assez visible pour être auditée.

Le code sauvage est déjà dans l’entreprise. La question n’est plus de savoir comment l’empêcher, mais comment le suivre, le sécuriser et le surveiller.