Vos apps générées par IA se multiplient : qui a accès à quoi ?

Depuis quelques mois, le nombre d’applications internes à chaque entreprise a augmenté de manière exponentielle, l’impulsion étant le vibe coding évidemment. Pour cadrer cette démarche, nous décrivions qu’une charte structurant l’approche est un bon point de départ. Pour autant permettre le vibe coding à l’échelle en entreprise doit aller plus loin. L’élément logique qui vient ensuite est l’authentificaiton et les droits d’accès. C’est le point d’entrée de toutes les applications vibe codées à usage interne.

Le but est de répondre au besoin : qui a le droit d’y accéder, et pour y faire quoi ?. Les approches naïves que l’on constate sur les applications vibe codées sont par exemple :

• une liste d’e-mails admins codée en dur.
• une autre coche un booléen is_admin en base.
• une troisième laisse entrer tout le monde parce que « c’est interne, de toute façon ».

Chaque application re-invente la roue (de l’autorisation) , avec plus ou moins d’élégance et surtout dans son coin. La bonne approche est évidente : l’autorisation ne doit pas appartenir à chaque application. Elle doit venir d’une source de vérité unique, que vous possédez bien souvent déjà, par exemple vos groupes Google Workspace. Dans un souci de simplicité pour le reste de l’article, nous partirons du principe que c’est en tous cas Google Workspace que vous utilisez, néanmoins l’approche reste valable pour tout autre fournisseur d’identité d’entreprise, tel que Microsoft 365 ou Okta.

J’échangeais récemment avec Maxence Bruyas, CEO de Forest Admin, sur exactement ce sujet : eux aussi centralisent l’autorisation plutôt que de la disperser — avec, créditons-les, un cran d’avance dont nous reparlerons. Quoi qu’il en soit le constat est partagé : le sujet de l’autorisation est primordial aujourd’hui.

Authentification vs Autorisation : clarifier les concepts

Deux questions se cachent derrière « la connexion ». On les confond souvent, et c’est là que naît le désordre.

L’authentification répond à « qui es-tu ? ». Sur ce point, la plupart des apps internes vibe codées adoptent souvent le bon reflexe : elles délèguent à Google OAuth, restreint au domaine de l’entreprise.

L’autorisation répond à « qu’as-tu le droit de faire ? ». Là, chacun bricole. Malheureusement, c’est la partie qui engage : un droit d’écriture mal placé et vous avez un incident. Le RBAC — Role-Based Access Control — consiste à ne pas attribuer des droits individu par individu, mais à ranger les gens dans des rôles (admin, modérateur, lecteur) et à attacher les droits aux rôles. En entreprise il est souvent plus simple de raisonner en terme d’équipes et/ou fonctions plutôt que d’individus. Ainsi on pourra par exemple donner les droits d’administration à l’équipe direction et les droits de lecture à l’équipe support.

La tentation, quand on structure un RBAC, est de construire une base de rôles et une interface pour les gérer. C’est un projet en soi, avec sa propre dette et nécessité de maintenance. Sauf que pour beaucoup d’entreprises, cette source de vérité existe déjà dans votre organisation : ce sont vos groupes Google Workspace.

Ils ont trois propriétés qu’aucune table roles maison n’aura jamais :

• Ils sont déjà tenus à jour. Les groupes servent aux mailing-lists, au partage Drive, aux agendas. Ils vivent au rythme des arrivées et des départs, souvent pilotés par les RH ou l’office management. Le cycle de vie est déjà là.
• Ils sont uniques et transverses. Un seul endroit décrit qui est dans l’équipe ops, qui est manager, qui est dans le pôle data. Pas une copie par application.
• L’offboarding devient trivial. Retirer quelqu’un d’un groupe Google le sort, d’un coup, de toutes les apps qui s’appuient dessus. Fini la chasse aux accès résiduels.

Le principe est donc : on ne crée pas une nouvelle source de vérité, on branche les apps sur celle qui existe.

Notre implémentation : un service d’identité unique

Reste un problème pratique : interroger l’API Google Directory depuis chaque application, c’est distribuer des credentials sensibles partout, gérer des quotas, et retomber dans le travers du « chacun sa cuisine ». Nous avons donc posé, chez Dernier Cri, une brique unique : identity.derniercri.io.

Son rôle est volontairement minuscule. Il ne remplace pas l’authentification : chaque app garde son propre Google OAuth. Il ne fait qu’une chose — répondre à la question « à quels groupes appartient cet e-mail ? ». Une seule responsabilité, une seule brique à sécuriser, une seule source à interroger.

À ce stade, une objection pourrait être : pourquoi ne pas déployer un Keycloak ? Parce que nous n’avons pas de problème d’authentification à résoudre — Google le fait déjà — mais un problème de résolution de groupes. Keycloak est un serveur d’identité complet, taillé pour être la source de vérité : il faudrait soit y synchroniser Google Workspace via un connecteur à maintenir, soit y recréer les groupes à la main. Dans les deux cas, on introduit une seconde source de vérité et l’offboarding cesse d’être trivial. Sans compter le serveur à déployer, patcher et sauvegarder, pour un besoin qui tient en un appel HTTP. Keycloak reste pertinent le jour où l’on doit fédérer plusieurs fournisseurs d’identité ou ouvrir l’accès à des partenaires externes — ce n’est pas notre cas ici, avec un seul domaine Google et des apps internes.

Le contrat, en deux appels

L’API tient sur presque rien, et c’est voulu. Une application s’y authentifie avec une clé app dédiée (fournie par l’équipe ops), passée en Authorization: Bearer — jamais exposée côté navigateur. Deux endpoints suffisent.

Lister les groupes configurés, pour savoir sur quoi on peut s’appuyer :

GET /v1/groups → { "groups": [ { "slug": "ops", "label": "Ops" }, { "slug": "data", "label": "Data" } ] }

Et résoudre les groupes d’un utilisateur :

POST /v1/users/groups   { "email": "user@derniercri.io" } → { "email": "user@derniercri.io", "groups": ["ops"] }

C’est tout. Le service renvoie des groupes, pas des rôles. Un 400 si l’e-mail est hors du domaine autorisé, un 401 si la clé est invalide, un 429 en cas d’abus, un 502 si le lookup Google échoue. Cette pauvreté apparente est une qualité : le service reste une brique bête et fiable, sur laquelle on peut tout empiler.

La règle d’or : le service donne des groupes, l’app possède ses rôles

C’est le point qui évite de recréer un monolithe d’autorisation. Le service d’identité ne connaît que les groupes Google. La traduction en rôles applicatifs vit dans chaque application, localement.

Concrètement, un back-office décide chez lui que le groupe ops ouvre le rôle admin, et que data ouvre un accès en lecture. L’app d’à côté fera un mapping différent à partir des mêmes groupes. Le pattern tient en quelques lignes :

const ROLE_GROUPS = {  admin:  ['ops'],  member: ['data'],};const hasRole = (userGroups, role) =>  ROLE_GROUPS[role].some(g => userGroups.includes(g));

C’est une manière de faire très simple mais avant-tout pragmatique : la vérité sur “qui est qui” est centralisée ; la politique “qui peut quoi” reste au plus près du métier de chaque app. On ne demande jamais au service d’identité d’arbitrer une règle applicative — il ne saurait pas, et ce n’est pas son rôle.

C’est ici que se situe le cran d’avance de Forest Admin, évoqué en introduction. Dans notre approche, le contrôle s’applique au niveau de chaque application : c’est elle qui, à partir des groupes, décide quoi autoriser. C’est simple et robuste, mais cela suppose que chaque app fasse correctement son travail de vérification. Maxence Bruyas me décrivait leur pari inverse : appliquer la couche de RBAC directement au niveau de la source des données. L’avantage est réel — la règle ne dépend plus de la discipline de chaque client, elle est garantie au plus près de la donnée, quelle que soit l’app, l’agent ou le script qui l’interroge. C’est plus exigeant à mettre en place, mais c’est la barrière la plus difficile à contourner. Les deux logiques ne s’opposent pas : une source de vérité unique pour l’identité d’un côté, un point d’application le plus bas possible de l’autre — et l’idéal combine les deux.

Les non négociables

Un RBAC mal branché est dangereux et constitue une faille de sécurité. Nous avons donc posé, comme dans la charte, des lignes rouges — non négociables :

• La clé app reste côté serveur. Jamais dans un front, jamais dans une app mobile. Une clé dans le navigateur, c’est la porte ouverte à toute l’API d’annuaire.
• On n’interroge que l’e-mail de la session serveur. Jamais un e-mail fourni par le client sans validation : sinon n’importe qui demande les droits de n’importe qui.
• L’autorisation est vérifiée côté serveur, sur chaque route protégée. Un contrôle côté client n’est qu’un confort d’affichage, jamais une barrière.
• On ne cache pas les groupes côté client au-delà de quelques minutes. Un accès révoqué doit s’éteindre vite ; des droits mis en cache trop longtemps sont un accès fantôme.

Ces règles ne sont pas de la paperasse : ce sont exactement les réflexes de moindre privilège que nous demandons à un humain comme à un agent lorsqu’il vibe code.

Et les agents dans tout ça

Ce RBAC n’est pas qu’une affaire d’humains. Nous l’avons dit à propos du platform engineering à l’ère des agents : l’IA est un acteur du système de permissions comme les autres. Un agent qui agit via un MCP branché sur vos apps internes doit, lui aussi, se voir attribuer une identité et un périmètre — pas les droits d’un super-admin par défaut.

Le même socle sert alors des deux côtés : les scripts et systèmes automatisés interrogent l’identité avec leur propre clé et un accès en lecture seule ; les actions humaines qui engagent des droits passent par un OAuth où l’on sait toujours qui agit vraiment.

Changer de réflexe

Le vibe coding va continuer de multiplier les apps internes. C’est une bonne nouvelle : on n’a jamais construit aussi vite. Mais chaque nouvel outil pose la même question d’accès, et y répondre à la main, app par app, c’est reconstituer patiemment le chaos qu’on cherchait à éviter. L’urbanisation des systèmes d’informations est à nouveau un sujet d’actualité et cette couche, centrale, en fait dorénavant partie intégrante.

Questions fréquentes

Quelle est la différence entre authentification et autorisation ?

L'authentification vérifie l'identité — « qui es-tu ? » —, c'est l'étape de connexion, généralement déléguée à un fournisseur comme Google OAuth. L'autorisation détermine les droits — « qu'as-tu le droit de faire ? » —, c'est-à-dire quelles ressources un utilisateur peut consulter ou modifier une fois connecté. Les deux sont distinctes : on peut être authentifié sans être autorisé à une action donnée. Confondre les deux est l'une des sources les plus fréquentes de failles d'accès dans les applications internes.

Qu'est-ce que le RBAC (Role-Based Access Control) et à quoi sert-il ?

Le RBAC, ou contrôle d'accès basé sur les rôles, est un modèle d'autorisation où l'on n'attribue pas les droits individu par individu : on définit des rôles (`admin`, `éditeur`, `lecteur`) auxquels on rattache des permissions, puis on affecte les utilisateurs à ces rôles. Il simplifie la gestion des accès à l'échelle, car on raisonne par équipe ou par fonction plutôt qu'utilisateur par utilisateur — par exemple accès administrateur pour la direction et lecture seule pour le support.

Comment centraliser la gestion des droits d'accès de plusieurs applications internes ?

Pour éviter que chaque application réinvente sa propre logique d'autorisation, les droits doivent reposer sur une source de vérité unique plutôt que d'être dispersés. En pratique, on s'appuie sur l'annuaire d'identité que l'entreprise possède déjà (groupes Google Workspace, Microsoft 365, Okta…), exposé via un petit service qui répond à une seule question : « à quels groupes appartient cet utilisateur ? ». Chaque application interroge ce service, puis traduit localement ces groupes en rôles applicatifs. On centralise ainsi « qui est qui » sans imposer une politique de droits unique à toutes les apps.

Comment utiliser les groupes Google Workspace pour gérer les accès à une application ?

C'est souvent le choix le plus pragmatique quand l'entreprise utilise déjà Google Workspace. Les groupes offrent trois avantages qu'une table de rôles maison n'aura jamais : ils sont déjà tenus à jour au fil des arrivées et des départs (mailing-lists, partage Drive, agendas) ; ils sont uniques et transverses, un seul endroit décrit qui appartient à quelle équipe ; et ils rendent l'offboarding trivial, puisque retirer une personne d'un groupe la sort d'un coup de toutes les applications qui s'y appuient. On ne crée pas une nouvelle source de vérité, on branche les applications sur celle qui existe.

Faut-il déployer un Keycloak pour gérer les accès aux applications internes ?

Pas nécessairement. Keycloak est un serveur d'identité complet, pertinent lorsqu'il faut fédérer plusieurs fournisseurs d'identité ou ouvrir l'accès à des partenaires externes. Mais si l'authentification est déjà assurée (par Google OAuth, par exemple) et que le seul besoin est de savoir à quels groupes appartient un utilisateur, Keycloak est surdimensionné : il faudrait y synchroniser ou y recréer les groupes, ce qui introduit une seconde source de vérité à maintenir et fait perdre la simplicité de l'offboarding. Pour un seul domaine et des applications internes, un simple service de résolution de groupes suffit.

Comment gérer les droits d'accès d'un agent IA en toute sécurité ?

Un agent IA doit être traité comme un acteur du système de permissions à part entière : on lui attribue une identité propre et un périmètre limité, jamais des droits de super-administrateur par défaut. Concrètement, cela signifie un accès en lecture seule et une clé dédiée pour les scripts et systèmes automatisés, aucun accès direct aux bases de production, et une approbation humaine sur les actions sensibles. Le principe de moindre privilège qui s'applique aux humains vaut tout autant pour les agents.

‍

‍

‍