L’OAuth trouve les SaaS auxquels vos équipes se connectent. Notre extension Chrome trouve le reste.

Pourquoi la découverte OAuth est la bonne fondation

Lutril découvre déjà les SaaS en lisant les autorisations OAuth de Google Workspace et de Microsoft Entra ID. Chaque fois qu’un collaborateur clique sur « Se connecter avec Google » ou « Se connecter avec Microsoft » pour commencer à utiliser un nouvel outil, le fournisseur d’identité enregistre une autorisation : quelle application a été autorisée, quels scopes lui ont été accordés, quel utilisateur a autorisé, et quand. Nous lisons ces autorisations par consentement administrateur et les transformons en inventaire vivant.

C’est une base solide, et nous voulons dire pourquoi. Elle n’exige aucun agent sur les postes. Elle repose sur un consentement administrateur, donc elle couvre toute l’organisation depuis une seule connexion, sans attendre qu’un logiciel atterrisse sur chaque ordinateur. Et elle est précise sur ce qui compte le plus pour le risque : les scopes. Pour chaque application découverte, vous voyez exactement ce qu’elle peut lire ou écrire (agenda, messagerie, fichiers, accès complet au Drive), qui a accordé cet accès, quand elle a été vue pour la première fois, et qui l’a autorisée en premier. C’est toute la différence entre savoir qu’une application existe et savoir ce qu’elle peut réellement faire de vos données.

Pour la plupart des équipes, connecter Google et Microsoft fait remonter plus d’applications en une heure que la dernière année passée à poser la question autour de soi. C’est peu contraignant, c’est exact, et cela devrait être la première chose que vous activez.

L’angle mort structurel

La découverte OAuth a une frontière, et il est important de la nommer précisément. Ce n’est pas un défaut de l’approche. C’est une limite de couverture qui découle directement de la façon dont la donnée est produite.

Une autorisation OAuth n’existe que si un collaborateur a autorisé une application via votre fournisseur d’identité. Si un outil propose « Se connecter avec Google », l’autorisation est créée et nous la voyons. Mais une part importante du SaaS ne s’adopte pas ainsi. Un collaborateur trouve un outil, s’inscrit avec son e-mail professionnel et un mot de passe, et s’en sert. Aucune poignée de main OAuth n’a lieu. Aucune autorisation n’est enregistrée. L’application est, par construction, invisible pour une découverte fondée sur les autorisations.

On peut combler une partie de cet écart avec des journaux réseau ou un proxy, mais ces approches sont lourdes : elles demandent des changements d’infrastructure, elles manquent souvent les appareils hors du réseau d’entreprise, et elles ont tendance à noyer les équipes sous du trafic brut sans rapport avec le SaaS. Nous voulions quelque chose de plus léger, de plus précis, et conçu pour ne remonter que l’usage de SaaS connus, rien d’autre.

Le lancement : une extension de navigateur Lutril

Nous lançons aujourd’hui une extension de navigateur Lutril, d’abord sur Chrome, Firefox ensuite. Elle comble l’écart de l’e-mail et du mot de passe en remontant les domaines de SaaS connus qu’un collaborateur visite. Si quelqu’un utilise un outil dans son navigateur, l’extension peut vous dire que l’outil est en usage, même si aucune autorisation OAuth n’a jamais été créée.

Parce qu’une extension de navigateur est la chose la plus sensible que l’on puisse déployer sur la machine d’un collaborateur, nous commencerons par la confidentialité, puisque c’est la première objection, et la plus légitime. Les choix de conception ci-dessous ne sont pas des options ajoutées. Ce sont le cœur du sujet.

Elle est installée d’office, et les collaborateurs n’ont rien à faire

L’extension est poussée vers les navigateurs gérés par votre MDM, la console d’administration Google Workspace ou Microsoft Intune. Aucune étape d’installation pour le collaborateur, aucune connexion, aucune fenêtre, aucun compte à créer. Les administrateurs génèrent un jeton d’enrôlement et le poussent par la configuration managée. Du côté du collaborateur, rien ne change dans sa façon de naviguer. C’est ce déploiement sans friction qui rend une couverture à l’échelle de l’organisation réaliste, plutôt qu’un projet de déploiement qui s’enlise à 30 pour cent.

Ce qu’elle envoie, et ce qu’elle ne voit jamais

La propriété la plus importante de l’extension est ce qu’elle ne transmet pas. Le filtrage se fait sur l’appareil, avant que quoi que ce soit ne le quitte.

Point par point, concrètement :

• Filtrage sur l’appareil. L’extension embarque un catalogue constitué de domaines SaaS connus. Elle ne transmet un nom d’hôte que si ce domaine y figure. Une visite sur votre banque, votre messagerie personnelle, un wiki interne ou un site d’actualités ne correspond à rien et ne quitte jamais la machine. Il n’existe aucun journal de navigation générale, ni sur vos serveurs ni sur les nôtres.
• Noms d’hôtes uniquement. Quand un domaine SaaS connu correspond, l’extension remonte le nom d’hôte, par exemple notion.so, et rien de plus. Pas d’URL complète, pas de chemin, pas de paramètre de requête, pas de contenu de page. Le signal est « cette personne utilise Notion », pas « voici la page où elle se trouvait ».
• Permissions minimales. L’extension observe les navigations de premier niveau pour savoir quel site s’est chargé. Elle ne demande pas la permission de lire le contenu des pages, et n’extrait rien. La surface de permissions est délibérément réduite, pour qu’un relecteur en sécurité puisse la comprendre vite.
• Jetons d’enrôlement par appareil. Chaque installation s’enrôle avec un jeton propre à l’appareil, révocable individuellement : vous pouvez couper un poste sans toucher au reste du parc.
• Mode anonymisé facultatif. Si vous opérez dans un contexte de comité social et économique ou de RGPD où l’attribution nominative est sensible, vous pouvez faire tourner l’extension en mode anonymisé, qui remonte l’usage des applications au niveau de l’organisation sans l’attribuer à des individus. Vous voyez toujours quels outils sont utilisés, sans nommer qui les utilise.

Un seul inventaire, deux points de vue

Les applications découvertes par l’extension n’atterrissent pas dans un rapport séparé. Elles alimentent le même inventaire de shadow IT que vos applications découvertes par OAuth, avec une source « Extension de navigateur ». Lutril corrèle ensuite les deux signaux par éditeur, et c’est là que le tableau devient utile.

• Une application vue à la fois par le SSO et par l’extension affiche les deux sources. C’est votre inventaire à haute confiance, réellement utilisé : autorisé via votre IdP et observé en usage.
• Une application vue par OAuth seul a été autorisée en SSO. Vous disposez des scopes et de l’autorisateur, ce qui est la bonne vue pour le risque de portée et d’accès.
• Une application vue par l’extension seule est le shadow IT en e-mail et mot de passe, que la découverte par autorisations ne pouvait pas faire remonter. C’est la catégorie qui était jusqu’ici invisible.

L’attribution par utilisateur montre qui a utilisé quoi, pour qu’un constat devienne actionnable plutôt qu’un simple décompte. Voici un aperçu de la façon dont les deux sources se résolvent dans un inventaire unique :

Ce sont les lignes « Extension » qui comptent pour ce lancement. Linear et Typeform ont été adoptés avec un e-mail professionnel et un mot de passe. Aucune autorisation OAuth n’existe pour l’un ni pour l’autre, donc aucun des deux ne serait apparu dans un inventaire fondé sur les autorisations. C’est l’extension qui les rend visibles, et l’attribution par utilisateur vous dit exactement quelles sont les neuf personnes présentes dans cet espace Linear.

Le déploiement en pratique

Tout le déploiement est une tâche d’administration. On ne demande jamais rien aux collaborateurs. En version courte :

1. Connectez Google et Microsoft. Cela active la base OAuth et vous donne immédiatement l’inventaire des applications autorisées en SSO, avec leurs scopes.
2. Générez le jeton d’enrôlement de l’extension. Dans les paramètres, créez le jeton que Lutril utilise pour associer les installations à votre espace de travail.
3. Poussez l’extension par votre MDM. Installez-la d’office via la console Google Workspace ou Microsoft Intune, et joignez la configuration managée : le jeton d’enrôlement, l’identifiant de votre espace de travail, et l’e-mail de l’utilisateur (substitué par appareil par le MDM, pour que chaque installation remonte la bonne personne).
4. Regardez l’inventaire se remplir. Les domaines découverts remontent automatiquement dans le même inventaire de shadow IT, étiquetés par source et corrélés à vos autorisations OAuth.

Quand utiliser quoi

Ce ne sont pas des approches concurrentes. Elles couvrent des surfaces différentes, et la valeur vient de les faire tourner toutes les deux. En version courte, voici où chacune gagne sa place :

L’OAuth vous dit ce qu’une application a le droit de faire de vos données. L’extension vous dit que l’application est utilisée, tout court. Aucune ne remplace l’autre. Faites tourner la base OAuth pour le risque de portée, ajoutez l’extension pour la longue traîne des inscriptions par e-mail et le signal d’usage, et l’inventaire du shadow IT cesse d’être une estimation pour devenir un relevé.

Si vous avez déjà connecté Google et Microsoft, générer le jeton de l’extension et la pousser par votre MDM est l’affaire d’un après-midi, et cela fait remonter une catégorie de shadow IT que vous n’aviez jamais pu voir. Si vous n’avez pas encore connecté de fournisseur d’identité, commencez par là : c’est la base sur laquelle tout le reste se construit.