Comment le vibe coding complique la visibilité des équipes IT

Le développement assisté par l’IA modifie une condition fondamentale de la sécurité en entreprise : des logiciels peuvent désormais exister au sein d’une activité sans passer par les processus qui permettaient auparavant à l’IT de savoir qu’ils existaient. Des analystes financiers, des responsables des opérations commerciales et des agents de support peuvent utiliser des prompts pour créer des outils fonctionnels en parallèle de leurs tâches habituelles. Certains outils peuvent être créés « en un après-midi », si bien que la création d’une application ne génère plus nécessairement l’activité organisationnelle associée à un projet logiciel classique. La réponse en matière de sécurité consiste à déplacer les contrôles communs vers des couches partagées de plateforme et de données, tout en conservant de la visibilité sur les endroits où les employés développent.

Le développement assisté par l’IA efface la piste qui rendait autrefois les logiciels visibles

L’acquisition traditionnelle de logiciels créait de la visibilité presque par hasard, car l’achat d’une application générait généralement un contrat fournisseur, déclenchait une revue de sécurité ou créait une dépense que quelqu’un devait approuver. Ces événements donnaient aux équipes IT et sécurité des occasions de découvrir une application, de l’évaluer, de lui attribuer un responsable et de décider des accès qu’elle devait recevoir. L’approvisionnement faisait donc office à la fois de processus de découverte des applications et de moyen d’acquérir des logiciels.

Le développement assisté par l’IA peut faire disparaître une grande partie de cette piste, car un employé peut créer un logiciel en interne et de manière indépendante. Le vibe coding, où un utilisateur dirige un système d’IA à l’aide de prompts pour produire une application, réduit le travail de développement logiciel conventionnel demandé à cet utilisateur. L’outil qui en résulte peut néanmoins traiter des processus métier ou des informations de l’entreprise, même si son créateur occupe une autre fonction.

Dès lors que la création sort du cadre de l’approvisionnement, l’IT peut perdre un point de découverte avant même que ne se posent des questions sur la qualité du code généré par l’IA. L’acquisition de logiciels laissait auparavant des traces ailleurs dans l’organisation, alors qu’un employé peut désormais générer directement une application utile. Le problème immédiat de gouvernance est que l’organisation peut disposer de logiciels opérationnels dont l’existence, le propriétaire, les accès et l’usage des données sont inconnus des personnes chargées de les sécuriser.

Le déficit de visibilité s’accompagne déjà d’un déficit de gouvernance

Ce problème de découverte apparaît dans une enquête menée auprès de 307 DSI, CTO et CISO. Seuls 5 % ont déclaré être « très confiants » dans le fait d’avoir une visibilité complète sur tous les outils internes de leur organisation. La visibilité précède la gouvernance applicative classique, car une équipe de sécurité doit découvrir une application avant de pouvoir l’examiner, la surveiller ou lui attribuer une responsabilité.

Les résultats sur la gouvernance montrent une situation connexe. À peine 4 % des dirigeants ont déclaré disposer d’une gouvernance couvrant le code généré par l’IA, quelle que soit la manière dont il avait été écrit, tandis que 4 % supplémentaires ont indiqué que la question ne s’était pas encore posée. L’indicateur de visibilité mesure la connaissance des outils internes, tandis que l’indicateur de gouvernance mesure jusqu’où la gouvernance s’étend au code généré par l’IA. Les deux sont liés, car une découverte limitée réduit les occasions d’appliquer des règles dont la couverture est déjà limitée.

Le côté créateur aide à comprendre comment ce déficit de visibilité se développe. Soixante pour cent des créateurs auraient déclaré avoir construit quelque chose hors de la supervision de l’IT « au cours de l’année écoulée ». Ce comportement crée la situation mesurée du côté des dirigeants : des personnes dans toute l’entreprise peuvent créer des logiciels tout en contournant les processus par lesquels l’IT en prenait traditionnellement connaissance. Une création plus distribuée peut donc élargir la population que les équipes de sécurité sont censées gouverner.

Cette population plus large dissocie aussi ceux qui créent un risque de ceux qui devront finalement en répondre. Les créateurs et les utilisateurs peuvent résoudre des problèmes métier immédiats grâce au développement en self-service, tandis que les DSI, CTO, CISO et équipes IT conservent la responsabilité des incidents impliquant les systèmes et les informations de l’entreprise. Une gouvernance conçue autour d’une population connue d’applications et de développeurs devient moins fiable dès lors que la création de logiciels se diffuse dans toute l’entreprise.

Une application fantôme peut passer des données d’entreprise à une exposition publique avant même que l’IT sache qu’elle existe

Un scénario illustratif rend ce problème de découverte concret. Un responsable commercial exporte des données clients de Salesforce dans un fichier CSV, s’inscrit sur une plateforme de vibe coding via un compte personnel, puis crée une application de visualisation. Le responsable publie ensuite l’application à une URL publique. Salesforce est le système connu dans cette séquence ; le changement de sécurité intervient lorsque l’employé déplace des données d’entreprise vers un outil créé de manière indépendante.

Une fois l’application publique, Google l’indexe « en quelques jours », avant que l’IT ne découvre l’existence de l’outil. Le calendrier est illustratif, et Google est le mécanisme par lequel la page publique devient découvrable. C’est la séquence organisationnelle qui crée l’exposition : des informations d’entreprise quittent un système connu, entrent dans un outil créé via un service personnel et deviennent accessibles publiquement sans passer par les processus habituels de l’entreprise en matière de logiciels et de sécurité.

Cette séquence transforme un inventaire incomplet en enjeu de sécurité, car une application inconnue peut créer un risque potentiel d’exposition de données, de conformité ou d’interruption. Les personnes responsables de ces domaines n’ont peut-être eu aucune possibilité d’évaluer la manière dont l’application stocke les informations, qui peut y accéder ou de quoi elle dépend. Un seul workflow en self-service peut ainsi contourner l’approvisionnement, la supervision de l’IT et la revue de sécurité.

La sécurité application par application cesse d’être scalable lorsque chaque employé peut devenir créateur

Le scénario Salesforce met en évidence un problème plus large de passage à l’échelle lorsqu’il s’agit de sécuriser chaque application individuellement. Ce modèle suppose que chaque créateur sait quels contrôles configurer et les configure correctement à chaque fois, ce qui est difficile même lorsque le créateur développe des logiciels à plein temps. Cette hypothèse devient encore plus difficile à tenir lorsque des employés dans toute l’entreprise créent des applications pour accomplir leur travail dans la finance, les opérations commerciales, le support ou une autre fonction principale.

Un CISO d’entreprise non nommé a décrit ce changement ainsi : « Les outils sont créés en quelques heures, parfois en quelques minutes, et ils ne ressemblent pas à des “systèmes” pour les personnes qui les créent. » Le délai cité est une observation plutôt qu’un benchmark mesuré de développement, mais il décrit aussi la manière dont les créateurs peuvent classifier ce qu’ils produisent. Un employé qui voit un petit outil comme un moyen rapide de résoudre une tâche peut ne jamais le considérer comme un système nécessitant un propriétaire, une politique de sécurité, un processus de revue et une responsabilité continue.

Cette classification compte lorsque les contrôles résident dans chaque application, car l’IA peut accroître la dépendance de l’organisation au jugement individuel. Dans un modèle au niveau de l’application, une IA qui écrit une application peut aussi produire ses règles de sécurité, de sorte que l’application des contrôles dépend de ce qui a été généré et de la manière dont le créateur l’a sollicitée, revue et configurée. Chaque créateur supplémentaire ajoute alors un point de plus où l’organisation doit s’assurer que les bonnes décisions de sécurité sont prises.

Le problème de passage à l’échelle déplace la question de la gouvernance : il ne s’agit plus de savoir comment former chaque créateur, mais où l’entreprise peut appliquer les politiques de manière cohérente. La création peut rester distribuée dans toute l’entreprise, tandis que les équipes responsables des accès, de la protection des données, de la conformité et des incidents conservent une responsabilité centralisée en matière de sécurité. Un environnement gouverné peut alors réduire le nombre de décisions de sécurité que chaque créateur individuel doit reproduire.

Déplacez le point de contrôle de sécurité vers la plateforme et la couche de données

Cet environnement gouverné modifie l’endroit où les décisions de sécurité sont appliquées en plaçant les politiques autour des ressources et des données d’entreprise utilisées par les applications. Lorsque les interactions entre applications et données passent par des points d’application partagés, des contrôles communs peuvent s’appliquer avant qu’une application ne reçoive ou ne modifie des informations. L’application reste une partie du modèle de sécurité, mais sa configuration n’a plus à porter seule l’ensemble des contrôles.

Une configuration centralisée permet à ces points d’application de couvrir une population plus large de créateurs. Les équipes de sécurité peuvent établir des politiques d’identité, d’autorisation, d’accès aux données et de journalisation au niveau de couches partagées, et les applications qui y opèrent héritent des restrictions qui en résultent. Une application codée à la main, une application générée par l’IA et une application entièrement créée en vibe coding peuvent alors rencontrer les mêmes contrôles lorsqu’elles demandent la même ressource gouvernée.

Le single sign-on, ou SSO, fournit une partie de cette frontière d’identité partagée en reliant l’accès aux applications au système d’authentification de l’organisation. SCIM, la norme System for Cross-domain Identity Management, prend en charge le provisioning et le déprovisioning centralisés des identités utilisateurs. Ensemble, ces mécanismes permettent aux accès de suivre un état d’identité géré de manière centralisée lorsque des employés changent de poste ou quittent l’entreprise, réduisant ainsi l’état d’identité intégré indépendamment dans les applications créées par les employés.

Cette identité centrale peut alimenter un contrôle d’accès basé sur les rôles et sur les groupes, ou RBAC, qui attribue les permissions selon des groupes et des rôles organisationnels. Une entreprise peut définir ces groupes et ces rôles de manière centralisée et appliquer leurs permissions à l’ensemble des applications via l’environnement gouverné. Pour une entreprise comptant de nombreux créateurs occasionnels, l’autorisation peut alors dépendre de l’appartenance d’un utilisateur à un groupe approuvé, tandis que les spécialistes de la sécurité maintiennent le modèle d’accès de l’entreprise.

Les contrôles de données peuvent affiner davantage ces décisions d’autorisation. Les contrôles au niveau des lignes déterminent quels enregistrements un utilisateur peut consulter, tandis que les contrôles au niveau des colonnes déterminent quels champs sont disponibles. Les contrôles au niveau des ressources peuvent gouverner l’accès aux ressources partagées, et les contrôles au niveau des données peuvent appliquer les politiques au plus près de l’information elle-même. Une application peut ainsi hériter de restrictions sur des enregistrements ou des champs sensibles sans obliger son créateur à concevoir chaque restriction à partir de zéro.

Ces restrictions sur les données nécessitent un enregistrement correspondant de la manière dont les informations gouvernées sont utilisées, ce que peut fournir une journalisation d’audit au niveau des requêtes. Une journalisation au niveau des requêtes donne à l’organisation un point commun pour observer les demandes à travers plusieurs outils, réduisant sa dépendance aux choix de journalisation de chaque application. À mesure que le nombre d’applications augmente, cet enregistrement partagé aide à préserver la responsabilité malgré les différences entre les personnes qui ont créé chaque outil et le niveau de sophistication de son implémentation interne.

Ensemble, ces contrôles expliquent concrètement sur le plan opérationnel ce que signifie « la sécurité comme propriété de la plateforme ». L’organisation doit d’abord disposer d’une visibilité et d’une responsabilité suffisantes pour faire entrer les applications et l’accès aux données d’entreprise dans un parcours gouverné. Elle peut ensuite appliquer une identité commune, des autorisations, des restrictions sur les données et de l’audit aux interactions partagées entre applications, en déplaçant davantage de décisions de sécurité vers les points d’application de la plateforme et des données.

Ce déplacement devient plus important à mesure que la création de logiciels se diffuse, car sinon chaque nouveau créateur ajoute un nouvel ensemble indépendant de décisions de sécurité. Exiger des analystes financiers, des responsables des opérations commerciales, des agents de support et des développeurs professionnels qu’ils reproduisent ces décisions dans chaque application crée un problème croissant de coordination. Les contrôles hérités permettent au contraire aux spécialistes responsables de la sécurité de l’entreprise d’établir des politiques à des points d’application partagés et de les appliquer de façon répétée dans l’environnement gouverné.

Retool propose une mise en œuvre commerciale de cette approche et présente son offre comme une « solution sécurisée de vibe coding ». Dans le modèle de Retool, les contrôles d’accès résident au niveau des ressources et des données, où les applications peuvent en hériter, tandis que la journalisation d’audit au niveau des requêtes fonctionne à travers les applications et que les contrôles au niveau des lignes et des colonnes gouvernent les données auxquelles les utilisateurs peuvent accéder. Retool indique également que SSO, SCIM et le RBAC basé sur les groupes s’appliquent de manière cohérente aux applications codées à la main, générées par l’IA et entièrement créées en vibe coding.

La mise en œuvre de Retool importe ici parce que les contrôles se situent à des points partagés entre différentes méthodes de création. Les politiques d’identité et de données peuvent donc s’appliquer à l’ensemble des applications au lieu d’être reconstruites séparément pour chaque outil généré. Retool a un intérêt commercial à ce que les entreprises adoptent cette conception ; ces affirmations de mise en œuvre décrivent donc la manière dont l’entreprise positionne et fournit sa propre plateforme. Le mécanisme architectural plus large reste l’application centralisée des contrôles lorsque les applications accèdent aux ressources d’entreprise via des points de contrôle communs.

Les contrôles centralisés ont toujours besoin de visibilité et d’un parcours gouverné

Les points d’application partagés définissent aussi la limite de ce modèle, comme le montre clairement le scénario du responsable commercial. Si un employé exporte un CSV, ouvre un compte personnel sur un service externe et publie de manière indépendante une application à une URL publique, l’activité reste en dehors du parcours d’application des contrôles de la plateforme d’entreprise. Les contrôles centralisés passent à l’échelle à l’intérieur de l’environnement par lequel l’organisation peut les appliquer.

Cette limite signifie que le problème de visibilité demeure même après qu’une entreprise a adopté des contrôles plus solides au niveau de la plateforme et de la couche de données. Les dirigeants doivent savoir où les employés développent et établir un parcours gouverné que les personnes utilisent réellement ; dans ce parcours, les contrôles peuvent s’appliquer que le créateur soit un ingénieur ou un employé créant un outil en parallèle d’un autre poste. L’adoption de la plateforme, la visibilité et la responsabilité déterminent quelle part de l’activité atteint les points d’application partagés et peut y être gouvernée.

Points clés

• Rétablir la visibilité sur les logiciels créés par les employés : Le développement assisté par l’IA permet aux employés de créer des applications fonctionnelles sans passer par l’approvisionnement, la revue de sécurité ou d’autres processus qui alertaient traditionnellement l’IT. Les équipes de sécurité ont besoin de mécanismes de découverte et de responsabilité couvrant les logiciels créés dans toute l’entreprise.
• Combler le déficit de gouvernance autour du code généré par l’IA : Seuls 5 % des responsables technologiques interrogés étaient très confiants dans leur capacité à voir tous les outils internes, tandis que 4 % ont déclaré disposer d’une gouvernance couvrant le code généré par l’IA, quelle que soit la manière dont il avait été écrit. Les entreprises ont besoin d’une gouvernance qui suive les logiciels à travers les différentes méthodes de création.
• Maintenir les données d’entreprise sur des parcours gouvernés : Les employés peuvent déplacer des données de l’entreprise vers des applications créées de manière indépendante et les exposer publiquement avant que l’IT ne les découvre. Les organisations ont besoin de contrôles qui identifient où les données sensibles se déplacent et quelles applications peuvent y accéder.
• Faire évoluer la sécurité au-delà de la configuration de chaque application : Le vibe coding étend la création de logiciels à des employés qui peuvent construire des outils en quelques heures sans jamais les considérer comme des systèmes d’entreprise. Les organisations de sécurité peuvent réduire leur dépendance au jugement de chaque créateur en centralisant les décisions de sécurité communes.
• Appliquer les contrôles à des couches partagées de plateforme et de données : SSO, SCIM, RBAC, les contrôles au niveau des lignes et des colonnes, ainsi que la journalisation d’audit au niveau des requêtes, peuvent appliquer des politiques cohérentes à travers les applications codées à la main et générées par l’IA. Les équipes plateforme et sécurité doivent placer ces contrôles à des points d’application partagés que les applications utilisent pour accéder aux ressources d’entreprise.
• Étendre le parcours gouverné aux endroits où les employés développent : Les contrôles centralisés ne protègent que l’activité qui passe par l’environnement où ils sont appliqués. Les équipes IT et sécurité ont besoin de visibilité sur le développement en dehors des plateformes approuvées et d’un parcours gouverné que les employés utiliseront.