Cas d'usage · Transformation et RUN
Faire évoluer ou remplacer un IAM existant
Votre organisation dispose déjà d'une solution de gestion des identités et des accès. Elle a été choisie pour répondre à des besoins identifiés : automatiser les arrivées et les départs, gérer des comptes, raccorder des applications ou commencer à structurer les habilitations. Ces premiers usages ont permis de construire un socle sur lequel d'autres exigences peuvent désormais s'appuyer.
Les organisations évoluent, et les besoins IAM évoluent avec elles. De nouvelles entités apparaissent, les applications se multiplient, les processus métiers se complexifient et les exigences de contrôle deviennent plus importantes. La question n'est pas de considérer votre plateforme comme obsolète, mais de déterminer si elle reste adaptée à vos objectifs et à vos capacités d'exploitation.
Vous reconnaissez cette situation ?
Votre IAM fonctionne et remplit une partie de ses objectifs, mais de nouvelles attentes apparaissent. Certaines concernent les opérations quotidiennes, d'autres la gouvernance des habilitations ou la capacité à intégrer de nouvelles applications.
Les situations que nous rencontrons peuvent notamment prendre les formes suivantes :
- Votre entreprise se développe, intègre de nouvelles filiales ou doit gérer des populations dont les cycles de vie diffèrent.
- Les demandes d'accès, les exceptions et les modèles de droits deviennent plus complexes à gouverner.
- De nouvelles exigences de conformité nécessitent des contrôles d'habilitations, des validations et des preuves exploitables.
- Les applications à raccorder présentent des interfaces hétérogènes et nécessitent des intégrations ou des traitements spécifiques.
- Les équipes informatiques consacrent une part importante de leur effort au maintien du fonctionnement existant, au détriment des évolutions demandées par les métiers.
- Votre contrat, votre architecture ou votre organisation vous amène à réévaluer la pertinence de la plateforme en place.
Ces situations ne signifient pas nécessairement que votre logiciel est inadapté. Elles justifient d'examiner son usage réel, ses possibilités d'évolution et les différentes trajectoires envisageables.
Trois trajectoires possibles pour votre IAM
1. Conserver et optimiser la plateforme existante
Lorsque la solution en place couvre les besoins de l'organisation, son remplacement peut créer davantage de complexité qu'il n'en résout. Les difficultés peuvent provenir de données de référence insuffisamment fiables, de processus incomplets, de règles de gestion mal définies ou de fonctionnalités déjà disponibles mais encore peu exploitées.
La trajectoire consiste alors à améliorer la qualité des sources, revoir les responsabilités, compléter les processus manquants, fiabiliser les connecteurs et renforcer l'exploitation. La valeur provient d'une meilleure utilisation de l'architecture actuelle, sans introduire une nouvelle plateforme lorsque celle-ci n'est pas nécessaire.
Point de décision
Vérifier les capacités réellement disponibles et les efforts nécessaires pour les exploiter avant d'envisager un remplacement.
2. Compléter l'IAM avec des capacités spécialisées
Une plateforme de gouvernance des identités n'a pas nécessairement vocation à prendre en charge tous les mécanismes de sécurité des accès. Une organisation peut conserver son socle IGA et lui associer des composants spécialisés pour répondre à de nouveaux usages.
La gouvernance des identités structure les cycles de vie, les habilitations et les contrôles. L'Access Management prend en charge l'authentification, la fédération et les parcours d'accès. Le PAM protège les usages privilégiés, tandis que l'autorisation fine permet de prendre des décisions contextuelles au moment de l'action. Ces capacités peuvent travailler ensemble, avec des responsabilités clairement réparties.
Cette trajectoire convient lorsqu'une partie de l'architecture fonctionne et qu'un besoin nouveau peut être traité sans remettre en cause l'ensemble du dispositif.
Point de décision
Déterminer si le besoin relève réellement de l'IGA existante ou d'un autre domaine de l'IAM.
3. Remplacer la plateforme et reconstruire une trajectoire adaptée
Le remplacement devient une option lorsque l'écart entre les besoins et les capacités exploitables de la plateforme ne peut plus être résorbé dans des conditions satisfaisantes. Les contraintes d'intégration, d'exploitation, de maintenance et de coût total doivent entrer dans cette décision, au même titre que les fonctionnalités attendues.
Une migration IAM ne consiste pas à rechercher une correspondance exacte entre les objets techniques de deux logiciels. Les identités, règles métier, habilitations, applications et processus doivent être compris pour déterminer comment ils seront pris en charge dans l'architecture cible. Cette décision doit également intégrer la continuité des opérations et les moyens dont dispose l'organisation pour exploiter le nouveau dispositif.
Le choix d'une plateforme intervient donc après la clarification des objectifs et des contraintes, avec une trajectoire adaptée au système d'information réel.
Point de décision
Justifier le remplacement par des besoins et des contraintes documentés, et non par une comparaison exhaustive de cases fonctionnelles.
Comment déterminer la trajectoire adaptée ?
Une décision de conservation, d'extension ou de remplacement doit s'appuyer sur des éléments observables. Le nombre de fonctionnalités annoncées par un éditeur ne suffit pas à déterminer la pertinence d'une architecture.
Nous proposons de commencer par quatre questions structurantes.
- 01
Quels processus et quelles identités devons-nous gouverner ?
Il faut identifier les populations, les événements de cycle de vie, les sources de référence, les responsabilités métier et les règles qui déterminent les accès. Cet état des lieux permet de distinguer les besoins réellement nouveaux des problèmes qui existaient déjà dans l'organisation.
- 02
Quelles sont les capacités réellement utilisées ?
L'analyse doit porter sur le fonctionnement effectif de la plateforme : applications raccordées, workflows exploités, règles d'habilitation, qualité des rapprochements, contrôles disponibles et conditions d'administration. Une fonctionnalité inscrite dans une documentation produit n'apporte pas de valeur tant qu'elle n'est pas correctement intégrée aux processus concernés.
- 03
Quelles contraintes limitent les évolutions ?
Les interfaces, les développements spécifiques, la documentation, les dépendances aux prestataires et la capacité des équipes internes doivent être évalués. Une architecture cible ne peut pas être jugée uniquement sur son périmètre fonctionnel ; elle doit aussi pouvoir être maintenue et faire l'objet d'évolutions.
- 04
Quel scénario apporte le meilleur équilibre ?
L'arbitrage doit confronter plusieurs trajectoires réalistes, avec leurs prérequis, leurs risques, leur impact sur les utilisateurs et leurs coûts de mise en œuvre et d'exploitation. Le résultat attendu est une décision argumentée et une première étape opérationnelle, pas nécessairement un projet de migration.
Les capacités Ariovis à mobiliser
Stratégie IAM et Zero Trust
Analyser les capacités de l'existant, les besoins métier, les responsabilités et les contraintes pour construire plusieurs scénarios d'évolution. Le cadrage doit permettre de décider ce qu'il faut conserver, compléter ou remplacer.
Gouvernance des identités
Structurer les cycles de vie, les habilitations, les règles d'attribution, les demandes d'accès, les campagnes de recertification et les contrôles de séparation des tâches en fonction des besoins réellement identifiés.
Intégrateur IAM
Concevoir et mettre en œuvre les évolutions retenues, depuis l'intégration des sources et des applications jusqu'à la configuration, la recette et la mise en production. Le périmètre peut concerner une plateforme existante, une nouvelle solution ou plusieurs composants complémentaires.
RUN IAM
Assurer l'exploitation du dispositif, le suivi des flux et des connecteurs, la maintenance, le traitement des incidents et les évolutions. La continuité entre le projet et le RUN permet de prendre en compte les contraintes d'exploitation dès la conception.
Des décisions IAM différentes selon les organisations
Secteur : Secteur bancaire
Réévaluer une architecture déjà déployée
Une organisation bancaire disposait d'une première architecture d'identité conçue pour un usage orienté partenaires. Le dispositif était globalement robuste, mais les choix initiaux limitaient sa capacité à accueillir de nouveaux usages et sa documentation ne permettait pas une maîtrise suffisante de l'ensemble.
Ariovis a étudié le fonctionnement de cette architecture, les modèles d'autorisation, les processus d'identité, les développements et les responsabilités. L'intervention a produit un diagnostic argumenté et plusieurs scénarios d'évolution, permettant d'identifier les éléments à conserver et ceux qui pourraient nécessiter une nouvelle conception.
Ce que cette référence démontre : Une plateforme opérationnelle peut nécessiter une réévaluation architecturale sans que la décision de remplacement soit prise à l'avance.
Lire la référence : Réévaluer une architecture déjà déployée
Secteur : Retail
Faire progresser le service IAM existant
Une entreprise du retail rencontrait des difficultés de pilotage de son service identité : faible vélocité, demandes métier insuffisamment traitées, absence de priorités partagées et dérives dans l'exploitation. Le dispositif nécessitait une remise en ordre de sa gouvernance et de son fonctionnement.
Ariovis a contribué à restructurer la feuille de route, clarifier les responsabilités et reconnecter le programme aux besoins métier. Les travaux ont permis de retrouver une organisation plus cohérente, d'améliorer le traitement des demandes et de stabiliser le RUN.
Ce que cette référence démontre : Une évolution IAM peut d'abord concerner le pilotage, les processus et l'exploitation plutôt qu'un changement de produit.
Lire la référence : Faire progresser le service IAM existant
Secteur : Organisation à but non lucratif
Rationaliser et remplacer certaines briques
Une organisation à but non lucratif exploitait plusieurs composants IAM, IGA, CIAM et PAM, dans un environnement hétérogène. L'évolution de sa stratégie Microsoft et les conditions économiques associées rendaient pertinente une réévaluation de cette architecture.
Ariovis a accompagné la stratégie d'identité, la feuille de route et les migrations associées. Le programme a notamment conduit au décommissionnement de la plateforme IGA existante et à la migration d'ADFS vers Microsoft Entra ID, dans une logique de rationalisation de l'environnement.
Ce que cette référence démontre : Lorsque les conditions fonctionnelles, économiques et organisationnelles le justifient, une architecture plus cohérente peut passer par le remplacement ou la suppression de composants existants.
Lire la référence : Rationaliser et remplacer certaines briques
Approfondir votre réflexion
Grille d'arbitrage IAM
Examinez 12 dimensions de votre IAM existant, identifiez les preuves à réunir et préparez une décision argumentée entre conservation, extension et remplacement de votre plateforme.
Reprendre un programme IAM à l'arrêt
Lorsque la difficulté principale ne concerne plus l'adéquation de la plateforme mais la gouvernance du programme, la capacité de livraison ou la perte de maîtrise du backlog, cette situation nécessite une démarche de reprise spécifique.
Explorer ce cas d'usage : Reprendre un programme IAM à l'arrêt
Stabiliser une plateforme IAM et passer au RUN
Lorsque la plateforme répond aux besoins mais que les incidents, les connecteurs, la maintenance et l'organisation du support posent problème, le chantier prioritaire peut porter sur l'exploitation.
Explorer ce cas d'usage : Stabiliser une plateforme IAM et passer au RUN
Migrer depuis SAP IDM
Les organisations qui exploitent SAP Identity Management disposent déjà d'un cas d'usage spécialisé, consacré à la préparation de la sortie de cette plateforme et à l'évaluation des architectures cibles.
Vous utilisez Youzer ?
Votre entreprise a déjà automatisé une partie de ses identités et de ses accès avec Youzer. Découvrez comment évaluer de nouveaux besoins de gouvernance et préparer, si nécessaire, une évolution ou une migration de votre IAM.
Faire évoluer mon IAM depuis Youzer : Vous utilisez Youzer ?
Comprendre les concepts
Votre IAM doit-il évoluer ?
Pour identifier une trajectoire pertinente, nous commençons par comprendre la plateforme actuelle, les processus réellement couverts, les besoins non satisfaits et les contraintes de votre organisation. Ce premier échange permet de déterminer les éléments à approfondir avant de choisir entre optimisation, extension ou migration.