Ressource méthodologique · Version 1.0

Grille d'arbitrage IAM : conserver, compléter ou remplacer votre solution ?

Votre organisation dispose déjà d'une plateforme IAM. Elle gère des identités, des comptes, des habilitations ou des processus d'accès. Pourtant, de nouvelles demandes apparaissent : intégrer davantage d'applications, automatiser de nouveaux cycles de vie, renforcer les contrôles, structurer les responsabilités ou améliorer l'exploitation.

Faut-il exploiter davantage les capacités existantes, ajouter une solution spécialisée ou engager une migration ? Cette question ne peut pas être résolue par une simple comparaison fonctionnelle entre éditeurs. Une fonctionnalité annoncée n'est pas nécessairement exploitée, et une difficulté de gouvernance ne justifie pas systématiquement un changement de logiciel.

Ariovis propose une grille d'arbitrage organisée autour de 12 axes. Elle permet d'identifier les éléments à examiner, les preuves à réunir et les questions à résoudre avant de décider de l'avenir de votre architecture IAM.

Consulter les 12 axes

Ce que cette grille permet de décider

Une plateforme IAM doit être évaluée en fonction des besoins réels de l'organisation, des capacités effectivement exploitées et des contraintes de son système d'information. Le nombre de fonctionnalités proposées par un éditeur n'est qu'un élément parmi d'autres : la qualité des processus, des données, des interfaces et de l'exploitation détermine également la valeur obtenue.

La grille distingue trois trajectoires qui peuvent s'appliquer à des parties différentes d'une même architecture. Une organisation peut conserver sa plateforme IGA, revoir ses règles d'habilitation, ajouter un moteur d'autorisation fine et remplacer un composant devenu inadapté. La décision ne doit donc pas être artificiellement réduite à un choix binaire entre conserver ou migrer.

Conserver et optimiser

Cette trajectoire est pertinente lorsque les principales difficultés peuvent être traitées en améliorant les processus, les données, les configurations, la gouvernance ou l'exploitation. Elle suppose de vérifier que les capacités nécessaires sont réellement disponibles et peuvent être utilisées dans des conditions de maintenance satisfaisantes.

Compléter l'architecture

Cette trajectoire est pertinente lorsque le socle existant remplit correctement son rôle, mais que de nouveaux besoins relèvent d'autres domaines : Access Management, PAM, autorisation fine ou sécurité des identités. L'objectif est de conserver les composants utiles et d'ajouter des capacités spécialisées avec des responsabilités clairement définies.

Remplacer tout ou partie de la plateforme

Cette trajectoire mérite d'être étudiée lorsqu'un écart important et documenté subsiste entre les besoins prioritaires et les capacités réellement exploitables de la solution actuelle. L'arbitrage doit alors considérer les contraintes de migration, les coûts, les dépendances, les impacts opérationnels et l'exploitabilité future de la cible.

Aucune de ces trois trajectoires ne doit être retenue automatiquement à partir d'un score.

Comment utiliser la grille d'arbitrage IAM ?

Commencez par définir le périmètre étudié : populations, applications, environnements, organisations concernées et objectifs de transformation. Une même plateforme peut fonctionner correctement sur un périmètre et rencontrer des difficultés sur un autre. Sans cette clarification, les conclusions risquent de mélanger des situations différentes.

Pour chaque axe, examinez les capacités réellement utilisées, documentez les écarts et rassemblez des éléments vérifiables. Les déclarations des équipes, les fonctionnalités annoncées par l'éditeur et les comportements observés en production ne constituent pas le même niveau de preuve. La grille sert à rendre ces différences visibles, et non à établir une note globale.

États possibles pour chaque axe

Couvert et démontré
Le besoin est satisfait sur le périmètre étudié et des preuves permettent de le vérifier.
Partiellement couvert
Le besoin est satisfait en partie, avec des limites ou des exceptions identifiées.
Écart documenté
Un besoin prioritaire n'est pas satisfait et l'écart est étayé par des observations ou des éléments techniques.
Non évalué
Les informations disponibles ne permettent pas encore de conclure.
Hors périmètre
Le critère ne concerne pas le périmètre ou les objectifs de l'étude.

Un critère non évalué ne doit jamais être considéré comme un échec de la plateforme. De même, une capacité non utilisée ne doit pas être déclarée absente du logiciel sans vérification.

Ces états servent à documenter le diagnostic. Ils ne déterminent pas à eux seuls la trajectoire à retenir.

IAM-01

Populations et sources de référence

Question centrale : Savons-nous quelles identités notre IAM doit gouverner et quelles sources font autorité ?

L'évaluation commence par l'identification des populations gérées : collaborateurs, prestataires, partenaires, identités techniques et autres catégories réellement concernées. Il faut déterminer quelles sources décrivent ces identités, comment elles sont rapprochées et quelles responsabilités sont associées à leur gestion. L'existence d'un référentiel central n'est pas suffisante si les identifiants, les règles de corrélation et les responsabilités ne sont pas maîtrisés.

Preuves attendues
cartographie des populations et des sources, règles de corrélation, identification des sources faisant autorité, conventions d'identifiants et responsabilités documentées.
Point d'arbitrage
distinguer les difficultés liées à la qualité et à la gouvernance des données de celles qui proviennent réellement des capacités de la plateforme.

IAM-02

Cycle de vie des identités

Question centrale : Les événements d'arrivée, de mobilité et de départ produisent-ils les effets attendus ?

Le fonctionnement du cycle de vie doit être examiné de bout en bout, depuis la réception d'un événement dans une source jusqu'à sa prise en compte dans les systèmes cibles. L'analyse doit notamment porter sur les changements de situation, les exceptions, les délais de traitement et la gestion des erreurs. Un workflow correctement configuré ne suffit pas si les événements de référence ne sont pas fiables ou si les systèmes cibles ne prennent pas en compte les modifications.

Preuves attendues
description des processus Joiner, Mover, Leaver, règles de gestion, exemples de traitements de bout en bout, journaux d'exécution et procédures de gestion des exceptions.
Point d'arbitrage
établir si les difficultés peuvent être corrigées dans les processus ou les intégrations existantes, ou si elles révèlent une contrainte structurelle.

IAM-03

Modèle d'habilitations

Question centrale : Les règles d'attribution des droits correspondent-elles aux responsabilités et aux besoins métiers ?

La gouvernance des habilitations doit permettre d'expliquer pourquoi une identité dispose d'un accès. L'évaluation porte sur les rôles métiers et techniques, les règles fondées sur les attributs, les droits exceptionnels et les mécanismes de délégation lorsqu'ils sont pertinents. Un catalogue de rôles trop complexe peut être aussi difficile à exploiter qu'un modèle insuffisamment structuré.

Preuves attendues
catalogue de rôles et d'habilitations, règles d'attribution, correspondances avec les ressources techniques, documentation des exceptions et identification des propriétaires des droits.
Point d'arbitrage
déterminer si les limites proviennent du modèle de droits, de son implémentation ou de la capacité de la solution à représenter les besoins.

IAM-04

Demandes d'accès et recertification

Question centrale : Les habilitations peuvent-elles être demandées, validées, réexaminées et justifiées ?

La gouvernance des accès doit permettre d'organiser des décisions compréhensibles pour les managers, les responsables applicatifs et les propriétaires des ressources. L'analyse porte sur les circuits de validation, les campagnes de recertification, les exceptions et la production de preuves d'audit. La qualité des informations présentées aux décideurs doit être évaluée au même titre que la disponibilité des workflows.

Preuves attendues
circuits d'approbation, exemples de demandes, comptes rendus de campagnes, décisions des responsables, preuves de traitement des révocations et documentation des exceptions.
Point d'arbitrage
identifier ce qui relève de l'organisation des validations, de la qualité du catalogue d'accès ou des capacités réellement exploitables de la plateforme.

IAM-05

Séparation des tâches et droits sensibles

Question centrale : Les incompatibilités d'habilitations et les droits sensibles sont-ils identifiés et maîtrisés ?

Une organisation doit pouvoir définir les combinaisons de droits incompatibles avec ses règles de contrôle, détecter les situations concernées et traiter les exceptions. La séparation des tâches ne se réduit pas à l'existence d'un moteur de règles : elle suppose des responsabilités, des arbitrages et des preuves de décision. Les droits sensibles nécessitent également une attention adaptée à leur impact opérationnel.

Preuves attendues
règles de séparation des tâches, catalogue de droits sensibles, résultats de contrôles, décisions de traitement et justification des exceptions.
Point d'arbitrage
vérifier si les mécanismes disponibles permettent de mettre en œuvre les règles réellement nécessaires, sans confondre difficultés de définition métier et limites du logiciel.

IAM-06

Connecteurs et intégration applicative

Question centrale : La plateforme peut-elle être intégrée durablement au système d'information réel ?

L'évaluation doit couvrir les applications déjà raccordées, les nouvelles cibles, les interfaces disponibles et les traitements nécessaires au provisioning et à la réconciliation. Les API, SCIM, annuaires, fichiers structurés, bases de données et traitements historiques constituent des possibilités d'intégration qui doivent être examinées selon les applications concernées. Le fonctionnement des reprises sur erreur et la maintenance des connecteurs sont aussi importants que leur développement initial.

Preuves attendues
cartographie des connecteurs, description des flux, spécifications d'interface, journaux d'exécution, gestion des erreurs, documentation des développements spécifiques et procédures de maintenance.
Point d'arbitrage
comparer la possibilité de fiabiliser ou développer les interfaces existantes avec les efforts qu'impliquerait une nouvelle architecture.

IAM-07

Qualité des données et réconciliation

Question centrale : La plateforme permet-elle de relier les identités, les comptes et les habilitations avec un niveau de fiabilité exploitable ?

La qualité du référentiel conditionne la pertinence des automatisations et des contrôles. Il faut examiner les identifiants, les doublons, les comptes orphelins, les écarts entre les droits attendus et constatés, ainsi que les mécanismes permettant de traiter ces anomalies. La réconciliation doit être considérée comme un processus de contrôle durable, et non comme une opération ponctuelle précédant une migration.

Preuves attendues
rapports de qualité des données, règles de rapprochement, résultats de réconciliation, listes d'écarts documentés et historique des corrections.
Point d'arbitrage
séparer les insuffisances du patrimoine de données des limitations éventuelles des outils chargés de le gouverner.

IAM-08

Architecture et répartition des contrôles

Question centrale : Chaque composant de l'architecture IAM remplit-il une fonction clairement définie ?

La gouvernance des identités, l'authentification, la gestion des privilèges et l'autorisation fine répondent à des besoins différents. L'analyse doit préciser quelle plateforme porte les processus d'identité et les droits gouvernés, quels composants sécurisent l'authentification et les sessions, lesquels contrôlent les accès privilégiés et où les décisions d'autorisation sont appliquées. La cohérence de cette répartition importe davantage que la concentration des fonctionnalités dans une seule solution.

Preuves attendues
cartographie d'architecture, répartition des responsabilités entre composants, description des flux d'authentification et d'autorisation, règles de gouvernance et dépendances entre plateformes.
Point d'arbitrage
déterminer si un besoin doit être traité dans la plateforme actuelle ou confié à un composant spécialisé.

IAM-09

Exploitation et maintien en condition opérationnelle

Question centrale : La plateforme peut-elle être exploitée, surveillée et maintenue de façon durable ?

Un IAM en production dépend de la supervision de ses traitements, de la gestion des incidents, de la maintenance des connecteurs et de la capacité à faire évoluer les configurations. Les procédures de reprise, les environnements de test, les mises à jour et le traitement du backlog doivent également être examinés. Une plateforme fonctionnellement adaptée peut devenir difficile à exploiter lorsque ces activités ne sont pas suffisamment organisées.

Preuves attendues
procédures d'exploitation, journaux et dispositifs de supervision, historique des incidents, documentation de maintenance, suivi des versions et backlog d'amélioration.
Point d'arbitrage
distinguer les problèmes que peut résoudre une organisation RUN mieux structurée des contraintes techniques qui nécessitent une évolution de plateforme.

IAM-10

Évolutivité et changements organisationnels

Question centrale : L'architecture peut-elle accompagner les transformations de l'organisation sans multiplier les adaptations fragiles ?

Les fusions, nouvelles entités, évolutions des processus RH et nouveaux besoins applicatifs peuvent modifier profondément les attentes vis-à-vis de l'IAM. L'analyse doit mesurer la capacité de l'organisation à intégrer ces changements, adapter les règles et étendre les processus. Une attention particulière doit être portée aux développements spécifiques, à leurs dépendances et à leurs conséquences sur les évolutions futures.

Preuves attendues
historique des évolutions, architecture des personnalisations, documentation des changements, backlog, dépendances techniques et retours d'expérience sur l'intégration de nouveaux périmètres.
Point d'arbitrage
apprécier si les changements peuvent être absorbés par l'architecture actuelle ou si les adaptations nécessaires remettent en cause sa pertinence.

IAM-11

Autonomie et compétences des équipes

Question centrale : L'organisation maîtrise-t-elle suffisamment son IAM pour en assurer le fonctionnement et les évolutions ?

La pérennité d'une plateforme dépend de sa documentation, de la compréhension de ses règles et de la capacité des équipes à prendre des décisions. L'évaluation doit porter sur les compétences internes, les responsabilités, les procédures d'administration, le support disponible et les dépendances aux prestataires. L'autonomie ne signifie pas nécessairement tout internaliser, mais disposer d'une maîtrise suffisante pour gouverner la plateforme et ses évolutions.

Preuves attendues
documentation fonctionnelle et technique, procédures d'administration, répartition des responsabilités, dispositifs de formation, modalités de support et dépendances contractuelles.
Point d'arbitrage
vérifier si un transfert de compétences, une réorganisation ou un accompagnement expert peut résoudre les difficultés avant de les attribuer à la plateforme.

IAM-12

Coût total et soutenabilité de la trajectoire

Question centrale : Quel scénario présente le meilleur équilibre entre les résultats attendus, les risques et les ressources mobilisées ?

L'arbitrage économique doit comparer les coûts de conservation, d'extension et de remplacement sur un horizon identique. Il doit intégrer les licences, l'intégration, les développements spécifiques, la maintenance, l'exploitation, les compétences nécessaires et les éventuels coûts de transition. Les bénéfices attendus doivent être documentés avec leurs hypothèses, sans attribuer artificiellement une valeur financière à des gains non démontrés.

Preuves attendues
contrats, coûts de licences et de services, charges d'exploitation, estimations d'intégration, hypothèses de migration, contraintes budgétaires et éléments permettant de comparer plusieurs trajectoires.
Point d'arbitrage
retenir une trajectoire économiquement soutenable en tenant compte de ses résultats attendus et de ses risques, et non du seul prix d'acquisition des logiciels.

Comparer les trajectoires sans attribuer un score artificiel

Les résultats de la grille doivent permettre de constituer un dossier d'arbitrage. Un écart sur un processus critique peut avoir davantage d'impact que plusieurs limitations secondaires. La décision doit donc examiner la priorité des besoins, la capacité à traiter les écarts, les risques et les dépendances plutôt que compter le nombre de critères satisfaits.

L'organisation doit également distinguer ce qui provient du fonctionnement de sa plateforme, de ses processus métier, de ses données ou de ses compétences. Remplacer un logiciel ne corrige pas automatiquement une source RH incohérente, un modèle de droits mal défini ou une absence de responsabilité sur les habilitations.

Conserver et optimiser

Les besoins prioritaires peuvent-ils être couverts ?
Par les capacités actuelles, après amélioration
Quels travaux sont nécessaires ?
Processus, données, configuration, intégration, RUN
Quelles dépendances faut-il examiner ?
Dette existante, compétences et maintenabilité
Quels coûts faut-il documenter ?
Remise à niveau et exploitation future
Quelle preuve doit justifier le choix ?
Capacité vérifiée à atteindre les objectifs avec l'existant

Compléter

Les besoins prioritaires peuvent-ils être couverts ?
Par les capacités actuelles associées à un autre composant
Quels travaux sont nécessaires ?
Architecture, interfaces, gouvernance entre composants
Quelles dépendances faut-il examiner ?
Cohérence des responsabilités, interfaces et exploitation
Quels coûts faut-il documenter ?
Intégration du complément et exploitation de l'ensemble
Quelle preuve doit justifier le choix ?
Couverture du besoin sans dupliquer inutilement les responsabilités

Remplacer

Les besoins prioritaires peuvent-ils être couverts ?
Par une nouvelle plateforme ou architecture
Quels travaux sont nécessaires ?
Cadrage de la cible, reprise, intégration, recette et bascule
Quelles dépendances faut-il examiner ?
Sources, connecteurs, règles métier et continuité de service
Quels coûts faut-il documenter ?
Projet de transition et exploitation de la cible
Quelle preuve doit justifier le choix ?
Écart durable documenté et pertinence démontrée de la cible

Ce tableau présente les questions et types de travaux à examiner. Il ne constitue pas un classement des solutions.

Une décision IAM peut aussi être différée

Lorsque les preuves sont insuffisantes, la prochaine action utile consiste à qualifier les inconnues. Un test de connecteur, une revue de règles d'habilitation, une analyse de la qualité des données ou un atelier d'architecture peuvent permettre de trancher une question avant de lancer un projet plus important.

Une décision différée faute d'informations n'est pas un échec de la méthode : elle évite de transformer une hypothèse en engagement technique ou financier.

Méthode, périmètre et sources

Cette grille est une ressource d'aide à la décision publiée par Ariovis à partir de son approche des projets IAM : comprendre les processus, qualifier les capacités existantes, examiner les contraintes d'architecture et d'exploitation, puis comparer les trajectoires possibles.

Les 12 axes ne constituent ni une norme, ni un audit certifiant, ni une liste exhaustive des exigences applicables à toutes les organisations. Ils servent à structurer une discussion entre les responsables IAM, les équipes techniques, les métiers, les responsables de la sécurité et les décideurs.

Plusieurs référentiels publics permettent d'approfondir les contrôles concernés. Ils éclairent certains concepts de la grille sans constituer une validation externe de la méthode Ariovis.

  • NIST — Cybersecurity Framework 2.0

    Ce référentiel propose des résultats de cybersécurité permettant notamment de structurer la gestion des identités, des accès, des autorisations et des risques. La famille PR.AA concerne la gestion des identités, l'authentification et le contrôle d'accès.

  • NIST — SP 800-207, Zero Trust Architecture

    Cette publication décrit les principes d'architecture Zero Trust et le rôle des décisions d'accès dans la protection des ressources. Elle est pertinente pour comprendre la séparation des responsabilités au sein d'une architecture IAM.

  • IETF — RFC 7644, SCIM Protocol

    Cette spécification décrit le protocole SCIM utilisé pour le provisioning et la gestion des ressources d'identité. Elle constitue une référence technique utile pour les questions d'interopérabilité et de connecteurs.

Sources Ariovis

Comprendre les concepts

Référence éditoriale

Titre de référence :
Grille d'arbitrage IAM — Conserver, compléter ou remplacer une plateforme existante
Éditeur :
Ariovis
Type de ressource :
Grille d'aide à la décision
Version initiale :
1.0
Date de publication :
Première publication publique à venir
URL de référence :
https://ariovis.fr/ressources/grille-arbitrage-iam

Faire examiner votre trajectoire IAM

Cette grille permet de documenter les questions essentielles, mais elle ne remplace pas l'analyse des processus, des contraintes techniques et des priorités propres à votre organisation. Les résultats peuvent servir de base à un atelier de cadrage pour examiner les écarts, les scénarios d'évolution et les conditions dans lesquelles un projet pourrait être engagé.

Ariovis peut intervenir de façon agnostique pour analyser l'existant, construire des scénarios et définir une trajectoire. Lorsque des changements sont retenus, nos équipes peuvent également accompagner leur intégration, leur mise en production et leur exploitation.