Méthode de mesure éditoriale • Ariovis

Six indicateurs PAM pour mesurer autre chose que le nombre de comptes coffrés

Couverture testée, délai complet, reprises, exceptions et retrait effectif. Six mesures pour relier le déploiement à des décisions d’exploitation, sans inventer un score de conformité.

Six indicateurs pour mesurer la maîtrise des privilèges plutôt que l’activité du coffre-fort

Lien direct vers la figure

Les volumes d’activité et les contrôles vérifiés se complètent. Chaque résultat dépend de sa frontière, de ses preuves et de ses données manquantes. Figure originale — Mon Premier PAM / Ariovis, révision du 23 octobre 2026. Méthode éditoriale, aucune licence ouverte attribuée. Sources et hypothèses précisées ci-dessous.

Tableau pédagogique — chiffres entièrement fictifs

Septembre 2026 — jeu fictif. Vague fictive : 24 chemins critiques connus, 80 comptes éligibles ; zones non inventoriées suivies séparément. Ce jeu accompagne l’ETI fictive des guides précédents ; ce n’est pas un état réel de ses 210 serveurs ni un résultat client. Trois demandes sont encore ouvertes ; leurs délais ne sont pas inclus dans les dix acceptations.

Résultats fictifs — lire les composants du calcul
Indicateur	Données et résultat	Lecture à préserver
Couverture vérifiée des chemins critiques	18 / 24 × 100 = 75 %. Les deux chemins directs non autorisés sont des écarts distincts.	Les zones non inventoriées doivent rester affichées séparément. 100 % de 5 chemins ne signifie pas 100 % du SI.
Couverture opérationnelle des comptes privilégiés	56 / 80 × 100 = 70 % : 44 comptes opérationnels avec coffre et 12 avec un autre contrôle testé.	Un compte déclaré ou intégré ne suffit pas. Documenter exclusions, comptes retirés et contrôles alternatifs sans double comptage.
Délai complet d’onboarding	Durées : 4, 5, 5, 6, 6, 7, 8, 9, 11, 15 jours. Médiane = 6,5 jours, P90 = 11 jours (rang supérieur, n = 10).	Un ticket isolé n’est pas l’onboarding complet. Petit effectif : P90 descriptif peu stable. Les demandes ouvertes ne disparaissent pas du pilotage.
Demandes reprises pour informations manquantes	4 demandes distinctes reprises sur 10 = 40 %, indépendamment du nombre de retours.	Ne mesure pas tous les défauts de qualité. Une baisse due à un contrôle abandonné est trompeuse.
Exceptions PAM non maîtrisées	5 exceptions non maîtrisées sur 8 = 62,5 % ; le nombre absolu reste 5.	Un accès direct non autorisé est suivi comme écart distinct, pas rendu légitime par son inscription. Une exception n’est pas automatiquement un incident.
Révocation effective dans le délai de la politique	9 retraits prouvés dans le délai sur 12 événements = 75 % ; 2 preuves manquent et 1 retrait est tardif.	Un groupe retiré ne prouve pas qu’un jeton ou une session est invalidé ; vérifier selon les mécanismes du service. Aucun délai universel proposé.

Dix demandes acceptées — jours calendaires fictifs, phases disjointes
Demande	Attente information / validation	Configuration	Recette	Total	Retours données manquantes
DEM-FICTIVE-1	1	2	1	4	1
DEM-FICTIVE-2	2	2	1	5	2
DEM-FICTIVE-3	2	2	1	5	1
DEM-FICTIVE-4	3	2	1	6	2
DEM-FICTIVE-5	3	2	1	6	0
DEM-FICTIVE-6	4	2	1	7	0
DEM-FICTIVE-7	5	2	1	8	0
DEM-FICTIVE-8	6	2	1	9	0
DEM-FICTIVE-9	8	2	1	11	0
DEM-FICTIVE-10	12	2	1	15	0

Ces phases sont disjointes dans le jeu simplifié : le total est leur somme. Dans un workflow réel, des tâches peuvent se chevaucher : utiliser les horodatages pour le délai écoulé et ne pas additionner des temps parallèles. Le P90 est ici calculé au rang supérieur, explicitement pour illustrer la formule ; dix demandes ne constituent pas une base statistique robuste.

Le registre fictif comprend deux exceptions sans propriétaire, une sans justification, une sans validation et une dont le réexamen est dépassé, toutes distinctes ; trois autres sont autorisées et suivies. Dans un registre réel, une exception cumulant plusieurs défauts compte une fois. Les deux chemins directs interdits sont suivis hors de ce registre, sans les légitimer.

1. Couverture vérifiée des chemins critiques

Un chemin relie une identité et son terminal à une ressource par un protocole et des contrôles. Il est vérifié lorsque autorisation, refus des voies interdites et traces ont été testés.

Formule: Chemins critiques connus vérifiés / chemins critiques connus du périmètre × 100
Numérateur: Chemins critiques connus avec preuves de contrôles attendus.
Dénominateur: Tous les chemins critiques connus dans la frontière étudiée.
Données nécessaires: Frontière versionnée, chemins, criticité, tests, date et preuve.
Sources de collecte envisageables: Inventaire, règles réseau / cible, recette et journaux techniques.
Fréquence proposée: À chaque vague ou changement majeur ; revue périodique décidée par le RUN.
Interprétation: Mesure la couverture testée du périmètre connu, pas de toute l’entreprise.
Limites: Les zones non inventoriées doivent rester affichées séparément. 100 % de 5 chemins ne signifie pas 100 % du SI.
Décision opérationnelle: Traiter les chemins non vérifiés et planifier la découverte des zones inconnues.
Exemple fictif calculé: 18 / 24 × 100 = 75 %. Les deux chemins directs non autorisés sont des écarts distincts.

2. Couverture opérationnelle des comptes privilégiés

Un compte opérationnel possède les contrôles attendus déployés et testés. Le contrôle peut être un coffre, un chemin sécurisé, une suppression de droits ou un mécanisme natif adapté.

Formule: Comptes avec contrôles déployés et testés / comptes éligibles recensés × 100
Numérateur: Comptes du périmètre avec contrôles attendus testés, y compris hors coffre.
Dénominateur: Comptes recensés éligibles aux contrôles définis, dans ce même périmètre.
Données nécessaires: État découvert / déclaré / intégré / opérationnel ; contrôle alternatif ; preuves.
Sources de collecte envisageables: Inventaire, PAM, IAM, systèmes cibles et procès-verbal de recette.
Fréquence proposée: À l’acceptation de chaque vague ; revue RUN selon la politique.
Interprétation: Distingue configuration et fonctionnement accepté ; couverture en coffre suivie en parallèle.
Limites: Un compte déclaré ou intégré ne suffit pas. Documenter exclusions, comptes retirés et contrôles alternatifs sans double comptage.
Décision opérationnelle: Recetter les intégrations en attente et choisir le contrôle approprié, sans tout mettre en coffre.
Exemple fictif calculé: 56 / 80 × 100 = 70 % : 44 comptes opérationnels avec coffre et 12 avec un autre contrôle testé.

3. Délai complet d’onboarding

Durée écoulée de la demande initiale à l’acceptation opérationnelle ; médiane des demandes acceptées et P90 si le volume le justifie.

Formule: Médiane des durées (acceptation − demande initiale) ; P90 au rang supérieur
Numérateur: Sans objet : distribution de durées, pas un ratio.
Dénominateur: Sans objet ; indiquer l’effectif des demandes acceptées et les demandes encore ouvertes.
Données nécessaires: Horodatages initiaux et d’acceptation ; durée d’attente, configuration et recette.
Sources de collecte envisageables: Workflow ITSM relié à l’acceptation RUN ; pas seulement date de création du dernier ticket.
Fréquence proposée: Par période définie, par scénario et avec suivi de l’âge des demandes ouvertes.
Interprétation: Sépare le temps total de l’attente d’information / validation, de configuration et de recette.
Limites: Un ticket isolé n’est pas l’onboarding complet. Petit effectif : P90 descriptif peu stable. Les demandes ouvertes ne disparaissent pas du pilotage.
Décision opérationnelle: Réduire la cause d’attente dominante ; ne pas accélérer en sautant la recette.
Exemple fictif calculé: Durées : 4, 5, 5, 6, 6, 7, 8, 9, 11, 15 jours. Médiane = 6,5 jours, P90 = 11 jours (rang supérieur, n = 10).

4. Demandes reprises pour informations manquantes

Une reprise est au moins un retour motivé au demandeur pour une donnée obligatoire absente. Plusieurs retours comptent une seule demande.

Formule: Demandes avec au moins une reprise / demandes traitées sur la période × 100
Numérateur: Demandes distinctes avec au moins un retour pour données manquantes.
Dénominateur: Demandes distinctes traitées sur la période définie.
Données nécessaires: Identifiant, période, motif du retour et nombre de reprises.
Sources de collecte envisageables: Workflow et contrôles de complétude ; exclure les retours purement techniques.
Fréquence proposée: Par période cohérente avec le délai ; segmenter par scénario.
Interprétation: Rend visible le coût du cadrage incomplet et des consignes peu explicites.
Limites: Ne mesure pas tous les défauts de qualité. Une baisse due à un contrôle abandonné est trompeuse.
Décision opérationnelle: Clarifier les champs indispensables, former les demandeurs et revoir les motifs récurrents.
Exemple fictif calculé: 4 demandes distinctes reprises sur 10 = 40 %, indépendamment du nombre de retours.

5. Exceptions PAM non maîtrisées

Exception ouverte à laquelle manque propriétaire, justification, validation ou échéance de réexamen ; une échéance dépassée reste à traiter.

Formule: Nombre non maîtrisé ; éventuellement non maîtrisées / exceptions ouvertes × 100
Numérateur: Exceptions ouvertes avec un champ de gouvernance manquant ou un réexamen dépassé.
Dénominateur: Exceptions ouvertes à la date de mesure pour la proportion ; sans objet pour le nombre absolu.
Données nécessaires: Statut, propriétaire, justification, validation, date de réexamen et décision.
Sources de collecte envisageables: Registre d’exceptions, ITSM et contrôles des chemins directs.
Fréquence proposée: À date de revue et à l’échéance prévue pour chaque exception.
Interprétation: Sépare exception autorisée et suivie, exception expirée et risque résiduel formellement accepté.
Limites: Un accès direct non autorisé est suivi comme écart distinct, pas rendu légitime par son inscription. Une exception n’est pas automatiquement un incident.
Décision opérationnelle: Attribuer, faire décider et revoir les exceptions ; traiter les accès interdits séparément.
Exemple fictif calculé: 5 exceptions non maîtrisées sur 8 = 62,5 % ; le nombre absolu reste 5.

6. Révocation effective dans le délai de la politique

Événements nécessitant un retrait dont l’application technique est prouvée dans le délai propre à l’organisation.

Formule: Événements avec retrait vérifié dans le délai / événements de révocation du périmètre × 100
Numérateur: Retraits vérifiés dans le délai applicable à l’événement.
Dénominateur: Tous les événements nécessitant révocation sur la période et le périmètre.
Données nécessaires: Départ, fin de mission, retrait d’habilitation, expiration temporaire ou compte inutile ; délai applicable et preuve.
Sources de collecte envisageables: RH / IAM, ITSM, PAM, journaux de la cible et mécanismes natifs de sessions / jetons.
Fréquence proposée: À chaque événement ; synthèse périodique par type de retrait.
Interprétation: Mesure l’application du retrait, pas la clôture administrative d’un ticket.
Limites: Un groupe retiré ne prouve pas qu’un jeton ou une session est invalidé ; vérifier selon les mécanismes du service. Aucun délai universel proposé.
Décision opérationnelle: Corriger les étapes de retrait non appliquées et les preuves manquantes, puis retester.
Exemple fictif calculé: 9 retraits prouvés dans le délai sur 12 événements = 75 % ; 2 preuves manquent et 1 retrait est tardif.

En exploitation

La première mise en production ne clôt pas le programme

Scénario pédagogique

Un premier lot PAM est déclaré opérationnel. Pourtant, de nouveaux serveurs arrivent, des applications changent de responsable, des connexions échouent et des demandes d'habilitation sont traitées au fil de l'eau. Sans parcours d'exploitation, chaque nouvelle cible redevient un mini-projet et les exceptions s'accumulent.

Lire la démarche et les vérifications à réaliser

Le passage au RUN se prépare avant la réception : responsable de la plateforme, procédures de demande et d'incident, supervision, gestion des comptes en erreur, parcours de mise à jour, reprise d'activité et indicateurs. L'équipe choisit des mesures qui l'aident à décider : taux de comptes avec propriétaire, cibles couvertes, demandes incomplètes, échecs de rotation, écarts de chemins d'administration, comptes en exception.

À vérifier : une nouvelle cible représentative est ajoutée avec la procédure rédigée ; une panne courante peut être diagnostiquée ; une exception dispose d'un responsable et d'une échéance. La réussite du projet se confirme dans l'exploitation, pas seulement au comité de clôture.

Sources et statut de la méthode

Les procédures, figures, formules et répartitions de responsabilités sont des propositions éditoriales Mon Premier PAM / Ariovis. Les situations et calculs sont fictifs ; aucun gain client ni résultat de terrain n’est revendiqué. Sources publiques vérifiées le 23 octobre 2026.

Microsoft recommande d’attribuer un propriétaire aux comptes de service, de documenter leur usage, leurs ressources et leurs permissions et de suivre leurs activités. Ces recommandations ne prouvent pas qu’une rotation ou une suppression est sans impact. NIST propose des contrôles de gestion des comptes et de retrait d’autorisation à adapter, pas une prescription de produit ni une certification PAM.

PAM FastTrack et CyberArk Blueprint sont des références conceptuelles du cadrage fourni ; les supports propriétaires n’ont pas été consultés directement ici. Aucun document client confidentiel n’a été utilisé pour publier des détails opérationnels ou des retours d’expérience. Pour reproduire ou adapter une figure, demander une autorisation conformément aux mentions légales.