Des réponses aux questions que l’on nous pose le plus souvent

Le modèle hybride sépare le plan de contrôle managé de la partie qui exécute les connecteurs. Cette partie est un petit agent Python qui peut s’exécuter dans votre propre VPC ou sur votre infrastructure sur site. Le plan de contrôle prend en charge le modèle de gouvernance, la planification des tâches, la configuration, les tableaux de bord et le reporting. L’agent exécute les connecteurs dans votre réseau et récupère les secrets localement. Les identifiants des connecteurs restent dans votre VPC. Seuls la configuration et les résultats circulent entre l’agent et le plan de contrôle. Pour les connecteurs SaaS tels qu’Entra ID, Salesforce et les applications SCIM, le connecteur peut s’exécuter soit dans le plan de contrôle, soit via l’agent. Le modèle d’identité synchronisé est stocké dans le plan de contrôle managé hébergé dans l’UE. Vous choisissez le mode agent connecteur par connecteur, selon l’accès réseau et l’endroit où les identifiants doivent rester.

L’agent s’authentifie avec une paire de clés ECDSA P-256. Au premier démarrage, il génère la paire de clés sur votre hôte et enregistre la clé publique à l’aide d’un identifiant d’enrôlement à usage unique. Ensuite, il prouve son identité par un défi-réponse signé, vérifié au moyen de cette clé publique. La clé privée ne quitte jamais votre machine. Les sessions sont de courte durée et sont rétablies à partir de la paire de clés, il n’y a donc aucun secret partagé de longue durée. Les secrets des connecteurs en mode agent sont conservés dans un magasin chiffré sur l’hôte de l’agent et ne sont jamais envoyés au plan de contrôle. Les mises à jour automatiques sont vérifiées par signature, et une mise à jour dont la vérification échoue est refusée.

L’agent revient automatiquement à la version précédente. Il conserve la version en place avant d’appliquer une mise à jour automatique, et une nouvelle version n’est acceptée qu’une fois qu’elle a démarré et est restée active. Si la nouvelle version plante au démarrage, le démarrage suivant le détecte et exécute à nouveau la version précédente. Aucun opérateur n’a à intervenir, à condition que l’agent s’exécute sous un gestionnaire de services qui le redémarre. Les installations standard systemd et conteneur le font toutes deux.

Le plan de contrôle managé standard de RapidValue fonctionne chez Scaleway, un fournisseur cloud français, dans sa région d’Amsterdam, dans l’UE. Le cloud géré par le client et le déploiement sur site sont des modèles de déploiement alternatifs pour les cas où votre architecture ou votre politique exige une infrastructure que vous contrôlez. Les identifiants des connecteurs en mode agent restent dans votre propre réseau et n’atteignent jamais le plan de contrôle. Seuls la configuration et les résultats circulent entre les deux.

Oui, via un webhook sortant. Il n’existe pas de connecteur dédié pour Splunk, Sentinel ou QRadar. Vous configurez un point de terminaison HTTPS par tenant et RapidValue y envoie les événements par POST. Un préréglage « Événements de sécurité » active toute la catégorie sécurité en un clic : échecs de connexion, période de refroidissement anti-force brute, personne verrouillée puis déverrouillée, coupe-circuit d’identité machine enclenché puis relâché, activation d’urgence, révocation d’un accès break-glass, nouvelle violation SoD, score de risque passant au niveau critique, et synchronisation retenue par une limite de sécurité. Chaque POST porte le type d’événement dans un en-tête et, si vous définissez un secret de signature, une signature HMAC-SHA256 du corps. Chaque tentative est journalisée avec son statut, le code HTTP et un motif d’échec structuré, par exemple connexion refusée, délai dépassé, DNS, TLS, 4xx ou 5xx. Toute personne disposant de droits d’audit peut lire ce journal sans être administrateur, et le journal ne montre jamais le point de terminaison ni son secret. Il y a deux limites. Premièrement, il n’y a pas de nouvelle tentative automatique aujourd’hui. Un administrateur renvoie un envoi qui a échoué, et la nouvelle tentative est journalisée comme une nouvelle entrée à côté de celle qui a échoué. Deuxièmement, les seuls événements d’authentification du flux sont les échecs de connexion et le verrouillage qui s’ensuit. Il n’existe pas de flux pour les connexions réussies, la MFA ou les changements de mot de passe. Les charges utiles des échecs de connexion portent une classe de motif et omettent l’adresse qui a été essayée, de sorte que personne ne peut utiliser le flux pour énumérer vos utilisateurs.

Dans tous les modes de connecteur, le plan de contrôle reçoit et stocke le modèle d’identité synchronisé : identités, comptes, habilitations et attributions. La réconciliation, le calcul du score de risque, les certifications et l’audit s’y exécutent. L’agent RapidValue change l’endroit où les identifiants sont conservés et la manière dont votre réseau est atteint. Il ne change pas le flux de données. Les secrets des connecteurs sont récupérés localement sur l’agent et ne sont jamais envoyés au plan de contrôle. Vous décidez de la quantité de données importée : dans l’assistant d’intégration, vous sélectionnez, par objet et par attribut, exactement ce qui est importé. Le modèle importé est traité et stocké dans le plan de contrôle managé hébergé dans l’UE. Il peut être exporté au titre de l’article 20 du RGPD et effacé au titre de l’article 17, dans les limites de conservation légale indiquées.

Cela dépend du mode dans lequel le connecteur s’exécute, et il existe trois modes. En mode agent, l’identifiant (mot de passe de bind LDAP, compte de service AD, jeton d’API, secret client OAuth) est conservé dans un magasin chiffré sur l’hôte de l’agent, dans votre VPC. L’agent le récupère localement au moment de l’exécution, et il n’est jamais envoyé au plan de contrôle, pas même chiffré. En mode in-process, utilisé pour les cibles SaaS exposées à Internet, l’identifiant est conservé dans le coffre du plan de contrôle, ou dans votre propre coffre si vous en enregistrez un. Avec votre propre coffre, nous stockons une référence et vous conservez la valeur. En mode tunnel, l’identifiant est également conservé côté plan de contrôle, et l’agent ne fait qu’acheminer la requête à travers votre réseau. Vous choisissez, connecteur par connecteur, comment votre réseau est atteint et où l’identifiant est conservé. La CLI de gestion des identifiants restreint le magasin et sa clé maîtresse à des permissions réservées au propriétaire sur l’hôte lorsque des identifiants sont ajoutés. En production, il est courant de tirer la clé maîtresse d’un gestionnaire de secrets tel que HashiCorp Vault ou Azure Key Vault, et non d’un fichier local.

DORA (Digital Operational Resilience Act, règlement sur la résilience opérationnelle numérique) impose aux entités financières de surveiller et de gérer en continu les risques liés aux TIC, y compris les droits d’accès aux fonctions critiques. Les capacités suivantes de RapidValue répondent à des exigences de DORA. Réconciliation planifiée : une exécution quotidienne à l’échelle du tenant, un recalcul par identité après chaque import, et des exécutions à la demande. Chaque exécution est horodatée et conserve, par attribution, des preuves qui répondent à la question de savoir pourquoi l’accès existe. Séparation des tâches : vous déclarez une seule fois des règles SoD inter-systèmes, et RapidValue continue à détecter les violations partout où elles apparaissent. Gouvernance des identités non humaines : les comptes de service et les bots sont gouvernés selon leur raison d’être. Une personne déclare cette raison, RapidValue ne la déduit pas du type d’identité, et la propriété est suivie. Gouvernance des accès tiers : flux d’identités des prestataires et partenaires avec une date de fin des accès. Piste d’audit : un journal d’audit immuable par catégorie, que vous pouvez exporter pour un régulateur. Le pack sectoriel Services financiers contient des règles SoD référencées DORA (le cumul d’un accès développeur et d’un accès en production, par exemple, référencé à l’art. 8) et des règles d’approbation de référence : une chaîne de trois approbateurs sur les ressources à haut risque et le principe des quatre yeux sur les demandes privilégiées et d’urgence. Le moteur de posture de conformité évalue d’emblée votre environnement par rapport aux contrôles des art. 9 et 28 de DORA. Il calcule le score à partir de la couverture réelle des certifications, des accès privilégiés et de la propriété des identités machines. Il n’utilise pas de questionnaire.

Oui. NIS2 impose aux entités essentielles et importantes de mettre en œuvre des politiques de contrôle d’accès, l’authentification multifacteur et une surveillance continue des accès privilégiés. RapidValue y répond de quatre manières. Une certification continue des accès, déclenchée par des événements en plus du calendrier annuel. Une gouvernance des identités machines fondée sur une raison d’être déclarée, de sorte que les comptes de service critiques sont identifiés et ont un propriétaire. Un score de rayon d’impact pour les identités non humaines et les rôles, qui montre ce qu’une identité compromise pourrait atteindre. Des preuves prêtes pour l’audit pour chaque exécution de réconciliation, ce qui répond à l’exigence de supervision documentée des accès. Pour les secteurs d’infrastructures critiques, le pack Industrie contient une règle de référence à quatre yeux pour les accès OT/SCADA et le pack Secteur public contient une règle de référence d’approbation des agents IA. Toutes deux sont référencées NIS2. Le moteur de posture de conformité évalue d’emblée votre environnement par rapport aux contrôles de l’art. 21 de NIS2. L’authentification multifacteur et les accès privilégiés sont évalués comme deux contrôles distincts, car ce sont deux choses différentes. L’enregistrement MFA provient de ce que votre IdP rapporte par compte, et les accès privilégiés proviennent de votre couverture juste-à-temps. Lorsqu’un connecteur ne rapporte aucun état MFA, nous présentons ce contrôle comme une lacune non mesurée et nous l’excluons du score. Nous ne l’arrondissons ni à zéro ni à cent pour cent.

Un rapport s’ouvre comme une vue paginée, triée et consultable par recherche. Le filtre qui a été appliqué est affiché à l’écran, et vous pouvez explorer le détail cellule par cellule. Le même filtre enregistré pilote l’export, de sorte que le fichier et l’écran montrent les mêmes données, masquage compris. Il n’y a pas de générateur de rapports en libre-service pour les utilisateurs finaux. Vous disposez du catalogue de rapports et des filtres enregistrés.

Oui. RapidValue prend en charge les exigences de contrôle d’accès de SOX, en particulier la section 404 sur le contrôle interne. Il propose des politiques de séparation des tâches avec détection automatisée des violations, des campagnes de certification des accès avec pistes d’approbation et horodatages, un journal d’audit immuable de toutes les décisions d’accès et de tous les résultats de certification, et un contrôle d’accès basé sur les rôles avec une justification enregistrée par attribution. Vous demandez quels accès la personne X détenait à l’instant Z, et RapidValue le reconstitue à partir de l’historique d’événements immuable. L’approbation et la justification de chaque attribution sont affichées à côté, dans la même piste d’audit, aucun ingénieur n’a donc à reconstituer la situation à la main. Il y a une limite que vous devez connaître. La reconstitution lit cet historique d’événements, et les accès qu’un import écrit directement dans une cible n’y passent pas encore. Sur un environnement fraîchement synchronisé, une reconstitution rapporte donc moins d’accès qu’il n’y en a, et elle liste ce dont elle ne peut pas rendre compte. RapidValue ne détient aucune certification SOX, ISO 27001 ou SOC 2, et un pack de preuves n’est pas une opinion d’audit. Nous livrons les preuves que votre auditeur demande, produites à partir de données réelles. L’opinion lui appartient.

Une seule ligne installe l’agent, et il apparaît en ligne dans votre tenant en 30 secondes environ. Le premier connecteur se synchronise dans la première heure. Vous voyez un premier résultat en une matinée : avant midi, vos données RH et une application sont connectées et les écarts sont à l’écran. Le POC suit la semaine d’après et vous donne un environnement de gouvernance opérationnel, y compris un premier role mining et une première campagne de certification. La durée d’un déploiement complet en production dépend du nombre de connecteurs et de la taille du modèle de rôles. Nous l’estimons avec vous une fois que le POC a montré ce que vos données demandent. Vous ne partez pas non plus d’un écran vide le premier après-midi. Quatre packs de démarrage (birthright, JML, revue d’accès, SoD) sont installés à l’état désactivé, de sorte que vous modifiez des règles de gouvernance existantes et n’avez pas à les rédiger de zéro.

Une fois par semaine, un bot se connecte sous six personas différents et ouvre chaque route que propose la navigation propre au persona. Il lit ces routes sur la page rendue, nous ne maintenons donc pas de liste. Sur chaque page, il vérifie quatre choses : la page se charge, la console est propre, aucune clé non traduite n’apparaît à l’écran, et une page proposée par la navigation ne répond pas par « pas d’accès ». Cela représente six personas et environ deux cents routes à chaque exécution. Le bot ne peut pas juger si un écran est réussi. Une personne doit toujours s’en charger, et le rapport de test le rappelle à la fin de chaque exécution.

Un POC type se déroule comme suit. Il prolonge la première matinée : l’agent, votre source RH et la première application sont déjà connectés, et Serge, le fondateur, travaille avec vous tout du long. Jour 1 : le Quick Scan s’exécute sur les données connectées, le role mining génère des propositions et un rapport à emporter est préparé pour votre RSSI. Le reste de la semaine : vous connectez d’autres systèmes cibles, exécutez une réconciliation complète et configurez une première campagne de certification. Fin de la semaine : un bilan avec votre équipe, une discussion tarifaire et un plan pour le passage en production. Vous n’avez aucune infrastructure à mettre en place au-delà de l’exécution de l’installateur en une ligne.

Non. L’agent est un fichier Python unique qui s’exécute sur n’importe quel hôte Linux, y compris WSL2 sous Windows. Il lui faut très peu : une petite VM avec 1 vCPU et 512 Mo de RAM suffit largement, et en pratique il consomme environ 200 Mo au repos. Il nécessite Python 3.12 ou une version plus récente et un accès HTTPS sortant vers le plan de contrôle. Pour les connecteurs en mode agent, il installe également quelques paquets pip (httpx, cryptography, ldap3 et similaires) et télécharge notre code de connecteur depuis le plan de contrôle, verrouillé en version par empreinte de contenu. « Un seul fichier » décrit donc ce que vous auditez, et l’installation complète est un peu plus volumineuse. Pour la production, nous recommandons une VM ou un conteneur dédié avec un stockage persistant pour les fichiers d’état et le coffre de l’agent. Le plan de contrôle est un SaaS managé par défaut. L’agent est facultatif et n’est nécessaire que pour les connecteurs qui atteignent des systèmes de votre propre réseau.

L’interrupteur de pause se compose de trois interrupteurs indépendants, pour la synchronisation, la réconciliation et le provisioning. Chacun arrête le moteur concerné sur l’ensemble du tenant. Les interrupteurs restent en place après un redémarrage et sont visibles par tous les administrateurs. C’est important parce que les moteurs IGA s’exécutent selon un calendrier. Si vous découvrez une erreur dans le modèle de rôles à 23 h, vous devez arrêter le bon moteur, ou les trois, pendant votre investigation, sans toucher aux fichiers de configuration ni tuer de processus. Un interrupteur de pause le fait en un clic. Un motif est enregistré à côté de l’état de pause, avec l’auteur de la pause et son heure, et chaque administrateur le voit jusqu’à la reprise du moteur.

Le role mining analyse vos données d’accès existantes pour trouver des regroupements naturels : des ensembles d’habilitations partagés par des personnes occupant des rôles similaires. RapidValue exécute 8 algorithmes en parallèle (par attributs, organisationnel, par fonction, regroupement de permissions, contextuel, entre autres). L’étape de déduplication résout un problème IGA courant. Le même rôle réel, par exemple « Responsable financier au sein du département IT », est proposé plusieurs fois par différents algorithmes à partir de différents systèmes sources. Sans déduplication, vous recevriez 7 propositions qui disent toutes la même chose. RapidValue détecte les propositions qui se recouvrent (ensembles d’habilitations similaires, groupes de membres similaires) et les fusionne en une seule proposition accompagnée d’une explication de la fusion. Vous examinez une seule proposition et vous voyez d’où elle vient.

Chaque identité non humaine (compte de service, agent IA, bot, appareil IoT, charge de travail cloud) reçoit un facteur de cycle de vie lors de son enregistrement. Le facteur indique pourquoi l’identité existe, et RapidValue ne le déduit pas du type d’identité. Il existe quatre facteurs. Lié au changement : rattaché à un déploiement de code ou à un changement de configuration, comme un compte de service CI/CD ou un identifiant de pipeline. Lié à l’exécution : existe parce que quelque chose s’exécute en ce moment, comme une tâche planifiée ou une identité de charge de travail. Lié à un actif : rattaché à un élément d’infrastructure, comme un appareil ou un certificat. Lié à une finalité : existe pour une raison métier déclarée qui survit à tout système particulier, comme une intégration ou un flux de données. Une personne déclare le facteur lors de l’enregistrement. Une valeur que RapidValue se contente de suggérer à partir du type d’identité ne clôt jamais un constat de gouvernance. Les agents IA ont en outre une seconde propriété : un niveau d’autonomie (assisté, supervisé, autonome) qui fixe la fréquence à laquelle l’agent est réattesté. Elle est distincte du facteur de cycle de vie, qui répond à la question de savoir pourquoi l’identité existe. La couverture de propriété (le pourcentage d’identités machines ayant un propriétaire nommé) est un KPI de premier plan du tableau de bord de gouvernance dès le premier jour.

RapidValue se traite lui-même comme un système connecté. Chaque utilisateur pouvant se connecter est adossé à une identité de votre annuaire. Les rôles de la plateforme (admin, auditeur, helpdesk, …) sont des appartenances à des groupes qui apparaissent dans le même modèle de sécurité que tout autre accès. Lorsque vous invitez un collègue avec un rôle, RapidValue crée une véritable attribution gouvernée, qui apparaît dans la réconciliation et les revues d’accès. Des garde-fous vous empêchent de vous bloquer vous-même l’accès. L’automatisation ne peut jamais désactiver ni rétrograder le dernier administrateur actif, et l’appartenance au rôle d’un administrateur actif est protégée contre une révocation par un connecteur. Le verrouillage d’urgence d’un administrateur compromis retire malgré tout l’ensemble de ses accès immédiatement.

Oui, comme fonctionnalité standard. Les profils break-glass associent les personnes éligibles aux habilitations d’urgence de vos systèmes critiques. La couverture est suivie, et le nombre de systèmes sans chemin d’urgence est un KPI. L’activation se fait en un clic et est limitée dans le temps : elle expire automatiquement et l’accès est révoqué à l’expiration. Chaque activation est inscrite dans la piste d’audit immuable avec une gravité critique et reste signalée jusqu’au dépôt d’une justification. La règle de revue des événements lance ensuite une revue de ce qui a précisément été utilisé.

Les évaluateurs délèguent leur file d’attente pour une période donnée, soit pour une absence, soit de manière permanente. Les décisions prises au nom d’une autre personne portent la mention « au nom de » et peuvent être auditées séparément. La chaîne d’approbation continue d’avancer pendant qu’une personne est absente, et la piste d’audit montre toujours qui a décidé. Une file d’attente en retard relance aussi automatiquement son propriétaire, la délégation n’est donc nécessaire qu’en cas d’absence.

L’approbateur reçoit d’abord un e-mail. Celui-ci est envoyé à l’approbateur de l’étape qui lui revient. L’e-mail peut contenir un seul lien vers la page de décision. Il n’affiche jamais Approuver à côté de Rejeter. Le lien désigne l’élément et le destinataire et ne contient pas la décision, l’ouvrir deux fois ne décide donc de rien. La décision elle-même se prend sur une page qui affiche les avertissements SoD et haut risque, et un rejet exige toujours un motif écrit. Ce réglage se fait par tenant et reste désactivé tant que vous ne l’activez pas. Le même e-mail et le même lien unique couvrent désormais aussi les cycles de certification. Une nouvelle revue s’annonce d’elle-même, et le rappel d’échéance proche est un message distinct.

Non. L’approbateur de l’étape en attente reçoit un e-mail. Une tâche planifiée envoie des relances à intervalles réguliers pour une décision en retard, et une vue permanente montre ce qui attend depuis le plus longtemps et chez qui. Vous voyez également un délai mesuré « généralement approuvé en ». Il s’agit de la médiane des quatre-vingt-dix derniers jours de ce tenant, et aucun chiffre n’est affiché lorsqu’il y a trop peu de données. Vous êtes informé lorsque le résultat est connu, y compris par un message « votre accès est actif », envoyé une fois le provisioning terminé.

Les agents hébergés sur Microsoft Entra Agent ID (y compris les agents créés dans Copilot Studio et AI Foundry), Amazon Bedrock et AgentCore, Google Vertex AI Agent Engine et Agentspace, Salesforce Agentforce, les agents IA ServiceNow et GitHub Apps. Sur AWS et Google Cloud, vous pouvez également étiqueter des utilisateurs IAM ou déclarer des comptes de service comme agents. La découverte GitHub reste désactivée tant qu’un propriétaire de l’organisation ne l’a pas activée. Les agents auto-hébergés sont enregistrés par un sponsor nommé, via la procédure d’admission. Lorsque la plateforme enregistre un sponsor, RapidValue l’importe comme propriétaire. Ces agents IA sont autre chose que l’agent RapidValue, qui est l’environnement d’exécution des connecteurs propre à RapidValue.

Cela dépend de la plateforme, et RapidValue vous dit ce qu’il a fait. Dans Entra, il désactive l’agent. Sur AWS, il attache une politique de refus total (deny-all) et la relit, et un rôle partagé avec d’autres charges de travail est signalé comme partagé. Sur Google Cloud, il désactive un compte de service géré par l’utilisateur et refuse les comptes gérés par Google. Pour les GitHub Apps, il verrouille l’agent dans RapidValue et indique que GitHub ne peut pas être arrêté à partir de là. Dans tous les cas, l’identité est verrouillée dans RapidValue, les identifiants émis par RapidValue sont révoqués, un motif saisi est exigé et l’action est auditée. Relâcher le coupe-circuit ne réémet pas les identifiants révoqués.

Oui. Le serveur MCP de RapidValue permet à vos assistants IA de poser des questions, de demander un accès et de décider les tâches de leur utilisateur, avec seulement ce que cet utilisateur peut voir. Chaque assistant connecté est gouverné comme un agent IA, avec un propriétaire et un coupe-circuit. En accès anticipé : la passerelle de RapidValue devant vos serveurs MCP et vos API internes. Chaque outil devient un droit qui passe par la demande, l’approbation, la certification et le contrôle de la séparation des tâches, et la passerelle décide chaque appel et bloque ce qui n’est pas autorisé. Elle garde l’identifiant du système pour que l’agent ne le voie jamais, et chaque système démarre en mode observation. Une passerelle que vous utilisez déjà peut demander la même décision à RapidValue au format OpenID AuthZEN. Les décisions sont scellées toutes les heures. Un modèle n’obtient jamais d’accès direct à un connecteur.

RapidValue enregistre les métadonnées des identifiants et jamais le secret lui-même. Les métadonnées proviennent des enregistrements d’applications Entra (secrets et certificats), des clés d’accès AWS IAM, des clés de comptes de service Google Cloud, des mots de passe d’application Google Workspace et d’Active Directory (âge du mot de passe comme rotation, dernière connexion comme utilisation), ainsi que des identifiants d’API émis par RapidValue. Les identifiants sans expiration, les identifiants expirant dans les 30 jours, les identifiants d’API inutilisés et les rotations en retard deviennent des constats. Lorsqu’une source ne rapporte pas l’utilisation, l’identifiant est affiché comme « non rapporté ». Il n’est pas affiché comme « jamais utilisé ».

IVIP signifie Identity Visibility & Intelligence Platform. C’est la couche d’analyse et de risque intégrée à RapidValue : un score de risque stocké par identité, la détection SoD inter-systèmes, la détection des attributions dormantes, la détection des valeurs aberrantes par groupe de pairs et des instantanés quotidiens de tendance du risque. C’est important parce que cela vous montre où regarder en premier. L’IVIP répond à la question « quelles 5 identités dois-je examiner maintenant ? » avec un score calculé par des règles fixes et décomposé en ses composantes. Il n’utilise aucun LLM, et vous pouvez voir comment chaque score a été calculé. C’est aussi ce qui permet d’observer avant de gouverner. Vous pouvez garder n’importe quel système ou objet en lecture seule, obtenir la vue complète des risques et les recommandations dès le premier jour, et activer le provisioning système par système une fois que vous en avez vu la valeur.

Oui, il est entièrement déterministe et n’utilise aucun apprentissage automatique. Le score est une somme pondérée de 0 à 100 sur 18 composantes déclarées, dont 16 contribuent au score. Elles comprennent : les attributions dormantes, les attributions privilégiées dormantes étant pondérées séparément ; les violations SoD inter-systèmes, aux niveaux avertissement et critique ; l’accès fantôme, c’est-à-dire les permissions héritées via des groupes imbriqués ; les valeurs aberrantes par groupe de pairs, c’est-à-dire plus d’accès que des collègues statistiquement comparables ; les attributions actives sur une identité ayant quitté l’organisation ; les accès privilégiés sans certification récente ; les identités non humaines sans propriétaire ; les éléments de revue ouverts et les avertissements d’identité, par gravité ; et les constats ouverts du Platform Advisor, par gravité. Chaque composante a un poids configurable. La décomposition est affichée dans le panneau de l’identité, vous pouvez donc toujours voir pourquoi un score a la valeur qu’il a.

C’est un détecteur planifié qui signale les attributions d’habilitations que leur titulaire n’a pas utilisées depuis N jours. L’« utilisation » est déduite des données d’usage de chaque système cible, comme les journaux de connexion, le nombre d’appels d’API et les horodatages de dernière activité. Le détecteur ne juge que ce qu’il peut observer. Une attribution ne peut être signalée comme dormante que sur un connecteur qui rapporte l’usage. Sur un système où RapidValue ne voit pas l’activité, la dormance est affichée comme inconnue, de sorte qu’une liste d’attributions dormantes ne contient jamais d’attributions qui sont simplement non suivies. Les attributions dormantes augmentent le score de risque du titulaire et apparaissent comme recommandations du Platform Advisor, par exemple « Révoquer 23 attributions dormantes sur 4 systèmes. Impact estimé : 0 utilisateur. » Vous cliquez pour valider et révoquer, à l’unité ou en masse. La révocation est toujours une action explicite d’un administrateur. Il n’y a pas de révocation automatique, car retirer un accès a un impact important et c’est à une personne d’en décider. Moins d’attributions dormantes signifie des économies directes de licences et une surface d’attaque réduite.

Les identités sont regroupées par département et par fonction. Le détecteur signale les identités dont les accès se situent bien au-dessus de la médiane de leur groupe. Il utilise la médiane, de sorte qu’une seule valeur aberrante ne peut pas déplacer la référence. Un constat typique est « Bob a 3× plus d’accès que son groupe de pairs ». Une valeur aberrante devient candidate à l’une de trois actions. Une certification ciblée, où le manager confirme que l’accès supplémentaire est justifié. Une revue d’appartenance à un rôle, où l’accès supplémentaire de Bob correspond à un rôle qu’il devrait formellement avoir. Ou un ajustement des droits, où Bob a accumulé ces accès lors de postes précédents et où ils sont nettoyés. Le résultat est déterministe, et la décomposition montre quelles habilitations précises causent l’écart.

Ce sont deux mots pour le même moteur. Une règle SoD est la manière dont vous déclarez une combinaison toxique : deux conditions inter-systèmes, comme « maintenance des fournisseurs dans Workday » et « approbation des paiements dans SAP », qu’aucune personne ne devrait détenir ensemble. Le moteur d’évaluation s’exécute en continu et signale chaque identité qui détient les deux côtés, quelle que soit la façon dont elle les a obtenus : via des rôles différents, des systèmes différents ou des attributions que personne n’avait l’intention de combiner. Les violations apparaissent à trois endroits et proviennent de la même source : l’espace de travail SoD (avec les deux côtés nommés par personne), la vue de posture de conformité (comme constats de combinaisons toxiques) et le score de risque d’identité (pondéré selon la gravité de la règle, critique ou avertissement). Nous avons choisi un seul moteur à dessein, car deux détecteurs séparés vous donneraient deux réponses qui se contredisent.

Les packs d’audit sont des ensembles de preuves préconstruits et mis en correspondance avec un référentiel. Vous choisissez une période et cliquez sur « Générer + télécharger ». Vous obtenez un ZIP contenant un index HTML qui porte la référence au contrôle du référentiel pour chaque section, un fichier de données JSONL par section, et un manifeste indiquant la période et le nombre de lignes par section. Il existe dix modèles aujourd’hui. Voici ceux qui sont mis en correspondance avec un référentiel. SOX § Access Management : provisioning, modification et revue des accès, mis en correspondance avec les objectifs de contrôle de la norme PCAOB AS 2201, avec la référence au référentiel sous-jacent. ISO 27001 contrôle d’accès (annexe A.9 dans l’édition 2013) : enregistrement des accès utilisateurs, gestion des privilèges et revue des droits d’accès. HIPAA § 164.312 Technical Safeguards : contrôle d’accès, contrôles d’audit, intégrité, authentification des personnes/entités et sécurité des transmissions, à destination des covered entities et business associates qui exploitent des systèmes contenant des PHI. RGPD art. 32 Sécurité du traitement : mesures techniques et organisationnelles appropriées afin de garantir un niveau de sécurité adapté au risque. DORA art. 9, NIS2 art. 21 et SOC 2 CC6. AI Act de l’UE / ISO 42001 gouvernance des agents : le registre des agents, l’historique de responsabilité et d’attestation, avec sa propre déclaration de ce qu’il ne revendique pas. Il existe aussi deux packs opérationnels : les preuves du cycle de vie arrivées/mobilités/départs, et les accès privilégiés/juste-à-temps. Les packs contiennent ce que votre auditeur demande, vous pouvez donc les apporter à la réunion de lancement de l’audit. Un pack est un ensemble d’enregistrements tirés de la piste d’audit chaînée par hachage, qui ne peut pas être modifiée dans la base de données. Son manifeste contient un hachage de chaque fichier du pack et reprend ce que le pack affirme, comme la référence et le nombre de lignes de chaque section, de sorte qu’un fichier ou une étiquette modifiés font échouer la vérification. Le manifeste porte une seule signature Ed25519 avec une clé par tenant, dont nous publions la partie publique. Votre auditeur peut donc vérifier le pack sans nous, avec le vérificateur autonome inclus dans chaque pack ou avec OpenSSL seul. Votre auditeur prend la clé publique parmi vos clés de signature publiées, pas dans le pack lui-même, et n’a besoin de rien d’autre de notre part. Les packs signés avant octobre 2026 restent vérifiables. L’export brut du journal d’audit porte lui aussi une signature Ed25519.

Les nouveaux connecteurs démarrent avec le provisioning activé, mais chaque nouvelle attribution est retenue dans un lot. Les modifications d’accès sortantes attendent votre approbation explicite jusqu’à ce que vous retiriez les petites roues, système par système. Pour être précis : le verrou couvre aujourd’hui la création et l’attribution. Les révocations et les réécritures d’attributs sont régies par leur propre politique par connecteur, et le verrou par lots ne les couvre pas. Les identités, les comptes et les habilitations sont synchronisés dès la première exécution, et la vue IVIP complète (score de risque, SoD, réconciliation, advisor) est disponible immédiatement. Résultat : une nouvelle cible est intégrée en quelques minutes, et vous voyez ce que RapidValue trouve dans vos accès avant que quoi que ce soit ne change dans la cible. Si vous voulez observer avant de gouverner, vous pouvez aussi mettre n’importe quel objet en lecture seule (un indicateur write_enabled par objet) et le lire sans configurer la moindre réécriture. Le parcours est le suivant : connecter avec le verrou activé, extraire les rôles et définir les politiques, puis retirer le verrou pour les cibles à forte valeur (généralement AD en premier) une fois que les preuves de réconciliation vous ont convaincu.

Le catalogue contient 20 connecteurs aujourd’hui : 14 modèles d’éditeurs plus six moteurs génériques. Microsoft Entra ID (Azure AD), avec une intégration complète de l’API Graph. Exchange Online, pour la gouvernance des boîtes aux lettres et des groupes de distribution. Google Workspace, avec l’annuaire Admin SDK et un scan des données non structurées de Drive. Active Directory et LDAP générique, qui couvrent AD, OpenLDAP et IBM/Oracle Directory. ServiceNow, dans les deux sens : il provisionne et il crée des tickets pour les tâches manuelles. Salesforce, pour la gouvernance des profils et des ensembles d’autorisations. Workday, comme source RH. SAP SuccessFactors, comme source RH. Box, avec un scan des dossiers et des collaborations (données non structurées). AFAS, TOPdesk, Nmbrs, Atlassian et GitHub, comme modèles d’éditeurs pour les organisations néerlandaises et belges de taille moyenne. Partages de fichiers SMB/NTFS, avec un scan des données non structurées par l’agent derrière le pare-feu. SCIM 2.0 générique, pour toute cible compatible SCIM (Slack, GitHub Enterprise, Atlassian, …). REST générique, pour toute API JSON, y compris les flux RH CSV/JSON. SQL générique, pour les bases de données applicatives Postgres, MySQL et MSSQL. SFTP-CSV, pour les flux RH en fichiers plats via SFTP/HTTPS. Les scans de données non structurées (Google Drive, Box, SharePoint, SMB/NTFS) sont en préversion. Ils sont désactivés par défaut et activés par tenant sur demande, car ils n’ont pas encore été éprouvés dans l’environnement réel d’un client. Nmbrs (Visma) est un modèle. Le consentement OAuth unique s’effectue dans l’assistant : vous enregistrez l’application dans votre portail développeur Nmbrs, cliquez sur Connecter et vous connectez une fois. Il fonctionne ensuite sans intervention grâce à son jeton d’actualisation. C’est aussi le seul connecteur que nous n’avons pas construit nous-mêmes. Il nous a été fourni sous forme de package développé avec notre SDK de modèles, ce qui montre que les connecteurs moins courants n’ont pas à attendre notre feuille de route. SOAP / WS-* est signalé comme bientôt disponible et ne fait pas partie des vingt. Les connecteurs personnalisés se construisent avec l’assistant guidé, à partir de points de terminaison REST, LDAP ou SCIM. La découverte en direct de l’assistant remplit l’essentiel de la configuration du mapping, vous vérifiez donc des suggestions et n’avez pas à rédiger le mapping de zéro.

Avec l’assistant, une cible REST ou SCIM standard est connectée en 15 minutes environ. Vous pointez l’assistant vers le point de terminaison de découverte de la cible, il renvoie une suggestion de mapping, et vous vérifiez environ 10 champs là où vous en définiriez sinon 100 de zéro. Pour les cibles complexes (authentification en plusieurs étapes, schémas non standard, API SOAP héritées), le développement de connecteurs personnalisés est proposé en tant que service. Il faut alors généralement 3–5 jours pour un connecteur de niveau production.

Cela dépend de ce que vous migrez. Connecteurs : l’assistant reconstruit les configurations de connecteurs à partir de la découverte en direct, ce qui est généralement plus simple que de migrer le XML ou la configuration des connecteurs de l’ancien outil. Modèle de rôles : le role mining le dérive à nouveau de vos données d’accès actuelles. Vous n’avez donc pas à importer les définitions de rôles accumulées dans l’ancien outil, et chaque proposition est accompagnée de preuves. Historique des certifications : vous conservez les exports de preuves de votre ancien outil pendant la durée de conservation, et RapidValue démarre une nouvelle piste de preuves immuable dès le premier jour. Workflows et politiques : vous déclarez à nouveau les règles SoD dans l’éditeur de règles et reconstruisez les règles d’approbation dans le constructeur visuel. Nous estimons une migration depuis un outil existant avec vous après la première matinée sur vos propres données, et les déploiements très personnalisés au cas par cas.

Vous pouvez tout exporter vous-même, à tout moment. Un export complet par tenant (RGPD, art. 20) produit une copie lisible par machine de toutes vos données : identités, comptes, habilitations, configuration et historique d’audit complet. Vous obtenez un tar.gz contenant un fichier JSONL par table, derrière un lien signé valable 24 heures. C’est un bouton pour les administrateurs du tenant, dans vos propres paramètres, vous n’avez donc pas besoin de ticket et n’avez pas à nous attendre. À la résiliation, nous clôturons votre tenant en deux étapes. Il est d’abord placé dans un état de clôture (offboarding), dans lequel rien de nouveau ne se produit et tout reste exportable. La suppression définitive ne s’exécute qu’après une confirmation explicite saisie au clavier, et jamais comme une étape automatique en arrière-plan. Le code impose un délai de grâce de 30 jours entre les deux étapes. Avant son expiration, la suppression est refusée. Y déroger plus tôt est une action d’administrateur qui inscrit son propre événement d’audit. Le journal d’audit immuable est la seule chose conservée après la suppression, sur le fondement de conservation légale du RGPD, art. 17, par. 3, b). Pour les connecteurs en mode agent, vos identifiants n’ont de toute façon jamais quitté votre réseau, et il vous appartient de détruire le coffre local de l’agent.