Un projet de gouvernance des identités se joue moins sur des bonnes pratiques abstraites que sur quelques réflexes structurants pris au cadrage et dans les premiers mois. Ces réflexes ont un point commun : ils paraissent évidents au moment où ils se présentent, ils sont défendables avec de bons arguments, et ils sont parmi les voies les plus fiables vers l’échec d’un projet. Cet article en répertorie sept, parmi les plus mortels et les plus fréquents. À chacun correspond une posture qui les évite.

Attendre que la donnée soit propre

L’idée semble évidente : on ne peut pas gouverner les accès sans données fiables sur les identités et les habilitations. Conclusion logique : il faut nettoyer avant de démarrer le projet IGA.

C’est l’une des manières les plus régulières d’enterrer un projet. Le nettoyage des données RH et des habilitations est un travail continu, pas un préalable. Tant qu’on attend qu’il soit terminé, on n’avance pas — et il ne sera jamais terminé, parce que la donnée se dégrade en permanence sous l’effet des nouvelles arrivées, des mobilités non tracées, des applications qui évoluent. Le projet entre alors dans une phase de cadrage perpétuel, le sponsor métier décroche, et le projet s’éteint sans avoir produit de valeur.

La posture qui marche est inversée. On identifie un périmètre où la qualité est suffisante pour démarrer — typiquement, une ou deux populations homogènes sur quelques applications bien maîtrisées. On démarre dessus, et on traite le nettoyage en parallèle, comme une activité structurelle du projet et au-delà. La maturité monte par paliers, pas par sauts.

Croire qu’on finira le modèle de rôles

Un modèle de rôles est souvent présenté comme un livrable de projet — quelque chose qu’on construit, qu’on valide à un jalon, puis qu’on déploie. C’est faux et c’est piégeux.

Le modèle de rôles ne finit jamais. Les nouvelles arrivées créent des cas qui n’étaient pas prévus. Les campagnes de role mining font apparaître des rôles candidats au fil de l’analyse des habitudes d’usage. Les recertifications révèlent des rôles qui ne sont plus pertinents, ou trop larges, ou doublonnés. Les nouvelles applications nécessitent de nouveaux rôles ou de modifier les rôles existants. Un modèle qu’on prétend « finir » à un jalon dérive en quelques mois, parce que la gouvernance continue qui aurait dû l’entretenir n’a pas été prévue.

La posture qui marche est de cadrer dès le départ la gouvernance continue du modèle : qui détient les rôles, qui valide les modifications, à quelle cadence on régénère les analyses de role mining, comment les recertifications alimentent en retour la structure des rôles. Un modèle vivant exige une fonction qui le maintient — sans elle, l’outil IGA gouverne un modèle obsolète, ce qui revient à gouverner la fiction.

Penser que la « RH » est une source universelle

Deux pièges se confondent souvent dans cette catégorie, et il faut les traiter ensemble pour ne pas reconstruire l’un en évitant l’autre.

Le premier piège est de ne penser qu’aux salariés. Prestataires, intérimaires, alternants, stagiaires : autant de populations qui accèdent au système d’information, sont concernées par les enjeux de gestion des accès, et ne sont pas dans le flux RH des salariés. Un projet IGA qui ne couvre que les salariés laisse hors gouvernance les populations souvent les plus mouvantes — et donc les plus à risque côté accès résiduels. Cette question est traitée plus largement dans l’article sur le cycle de vie des identités (JML).

Le second piège est plus subtil : tout ce qui s’appelle « RH » n’est pas un SIRH. Un véritable système d’information RH connaît les fonctions, les rattachements organisationnels, les changements de poste — il peut servir de source d’autorité pour décider quels accès ouvrir ou retirer. Un système qui n’est qu’un SI de paie sait combien on paye qui, pas ce que la personne fait dans l’organisation. Confondre les deux conduit à bâtir un projet IGA sur une source qui ne porte pas l’information dont elle a besoin, et la dérive est rapide.

La posture qui marche est de traiter explicitement la question des sources d’autorité par population : quelle source pour les salariés, quelle source pour les prestataires (souvent un référentiel dédié, parfois à créer), quelle source pour les comptes techniques, etc. Et d’interroger la nature réelle de la source « RH » disponible, plutôt que de se contenter de son nom.

Recertifier tout, tous les ans, pour les audits

Le réflexe est compréhensible : un audit attend une revue régulière des accès, on planifie donc une campagne annuelle qui couvre tout le SI, et on coche la case. Sur le papier, la conformité est satisfaite.

En pratique, la campagne annuelle globale devient du spam organisationnel. Un manager qui reçoit des centaines de lignes à valider sans contexte, dans un délai contraint, ne traite plus — il valide en masse, ou trop rapidement, pour s’en débarrasser. L’indicateur d’audit est rempli, la sécurité du SI n’a pas progressé. Et cette pratique installe durablement le réflexe du tampon, qui contamine ensuite toutes les campagnes ultérieures, même mieux conçues.

La posture qui marche inverse la cadence : moins par campagne, plus de campagnes. Plutôt qu’une revue annuelle exhaustive, des campagnes régulières ciblées sur un applicatif et un droit spécifique. Le manager reçoit dix lignes contextualisées qu’il peut traiter sérieusement, plutôt que trois cents qu’il ne lit pas. Sur l’année, la couverture finit par être au moins équivalente, mais elle est traitée — c’est la seule différence qui compte. Ce mode opératoire est traité plus largement dans l’article dédié à la recertification.

Faire du pilote le réceptacle des attentes accumulées

Quand un projet IGA démarre, il arrive souvent dans une organisation où le sujet est attendu depuis des années. Des demandes diverses se sont accumulées dans des équipes différentes : « on aimerait aussi que ça couvre tel cas d’usage », « depuis le temps qu’on attend cet outil, autant qu’il fasse aussi… », « si on intègre l’IGA, profitons-en pour traiter aussi tel sujet de rôles qu’on a en tête depuis 2019 ». Chaque demande, prise isolément, est légitime.

Leur accumulation dans le pilote est mortelle. Le périmètre grossit ; le nombre de composants à intégrer simultanément augmente ; la masse de tests explose ; et arrive le moment où, devant la quantité de choses qui peuvent casser, personne n’ose appuyer sur le bouton de mise en production. Le projet s’enlise dans des cycles de stabilisation interminables. Ou la mise en production a lieu, et son impact est trop large pour être absorbé proprement par l’organisation — incidents en chaîne, marche arrière, perte de confiance.

La posture qui marche demande une discipline socialement coûteuse : dire non aux ajouts pendant le cadrage du pilote, et réduire le périmètre dès qu’on voit qu’il dérive. Mieux vaut livrer plus tôt sur moins de périmètre — quitte à intégrer les demandes différées dans la suite — que tenter de tout couvrir au premier coup. Le pilote inverse, trop étroit pour être représentatif, existe aussi ; c’est un risque réel mais moins courant que le précédent, et il se règle en remontant d’un cran le périmètre, pas en l’élargissant à l’infini.

Laisser l’IT piloter seul

L’IGA est l’un des rares projets IT dont les bénéficiaires ne sont pas l’IT. Le manager qui demande un accès, le RH qui s’assure que les arrivées et départs sont correctement traités, le responsable applicatif qui veut savoir qui utilise son outil, la fonction conformité qui exige la traçabilité, la sécurité qui pilote le moindre privilège, la fonction lutte contre la fraude qui s’appuie sur la séparation des tâches : ce sont eux les clients du dispositif. L’IT est opérateur, pas commanditaire.

Cette inversion change tout. Un projet IGA piloté par l’IT seule, avec le métier en consultation ponctuelle, produit un projet conçu pour l’IT : modèle de rôles construit à partir des permissions techniques, vocabulaire propriétaire dans l’outil, workflows pensés depuis la logique du système plutôt que depuis la logique de la demande métier. L’outil sera utilisé… par l’IT. Le métier passera autour, en mode dégradé.

La posture qui marche tient à un test simple : le nouvel arrivant qui ouvre l’outil pour la première fois doit pouvoir l’utiliser seul, et comprendre ce qu’il lui demande. Si la demande affichée à un manager parle de « rôle technique APP-CRM-PROD-RW-2 » plutôt que d’« accès en consultation au CRM commercial », le test est raté. Cela impose trois principes : le self-service comme principe, pas comme fonctionnalité optionnelle ; un vocabulaire métier jusqu’au nom des rôles, des applications et des droits ; et un dialogue distinct avec chaque fonction partie prenante, parce que les attentes des RH, des responsables applicatifs et de la fonction fraude ne se confondent pas.

Mal contractualiser avec l’éditeur et l’intégrateur

Trois pièges contractuels se cumulent en pratique, et chacun mérite d’être traité pour soi.

Le contrat unique éditeur plus intégrateur est commercialement séduisant : un seul interlocuteur, une responsabilité globale, des prix souvent rognés. Opérationnellement, il enferme l’organisation. La capacité d’arbitrage disparaît — si l’éditeur livre mal son outil, l’intégrateur n’a pas intérêt à le dire ; si l’intégrateur prend du retard, la mise en concurrence n’est pas possible. La dissociation des expertises est aussi perdue, alors qu’un bon intégrateur n’est pas forcément le plus zélé promoteur d’un outil donné.

Choisir un intégrateur sur ses seules compétences techniques est le deuxième piège, et il est cohérent avec l’erreur précédente de laisser l’IT piloter. L’IGA est un projet de processus, d’organisation et d’outillage qui supporte le tout — dans cet ordre. L’intégrateur dont l’organisation a besoin doit savoir parler RH, responsables applicatifs, sécurité, fraude, conformité ; comprendre les processus métier avant de les outiller ; mener la conduite du changement. La technique est nécessaire, pas suffisante. Un intégrateur retenu pour sa seule maîtrise du produit livrera un outil qui fonctionne et que le métier n’utilisera pas.

Le cadre contractuel « agile, forfait, planning à livrables » est le troisième, et c’est celui qui finit le moins bien. Ces trois exigences sont contractuellement incompatibles entre elles : l’agile suppose qu’on découvre en chemin, donc qu’on adapte ; le forfait suppose qu’on a tout cadré au départ ; le planning à livrables suppose qu’on tient les engagements pris. Tenir les trois simultanément est impossible, et le résultat est connu — une machine à avenants où chaque écart au cadre initial devient une renégociation. Au bout d’un an, le client a payé bien davantage que le forfait initial, et l’intégrateur a perdu sa marge à se battre sur chaque virgule. Mieux vaut choisir un cadre cohérent — agile et facturation en régie maîtrisée, ou forfait avec un périmètre verrouillé et limité — que les empiler sans les concilier.

Conclusion

Ces sept réflexes ont un point commun : ils traitent l’IGA comme un projet technique. Or l’IGA est d’abord un projet de gouvernance et de processus, outillé par de la technique. La donnée se nettoie en avançant, le modèle de rôles vit dans la durée, les populations couvertes débordent du SIRH, la recertification sert le SI et pas seulement l’audit, le pilote impose une discipline d’arbitrage, l’IT opère pour le compte du métier, et le cadre contractuel doit servir la mécanique du projet plutôt que la rassurer faussement.

Démarrer un projet IGA en gardant cette priorité d’ordre — gouvernance, processus, outil — règle plus de la moitié des pièges avant même qu’ils se présentent.