Une boîte à outils, c’est une idée. Une tour de contrôle, c’est mieux.
Nous défendons l’idée qu’un premier IAM doit commencer par un périmètre raisonnable. Cela ne signifie pas qu’il faut choisir un outil incapable d’aller plus loin.
La distinction est importante. On peut automatiser quelques créations de comptes, synchroniser deux annuaires ou déclencher des actions à partir d’un événement RH avec des scripts, des workflows ou des outils spécialisés. Pour un besoin précis, cela peut parfaitement fonctionner. Mais automatiser quelques tâches et construire un système de gestion des identités sont deux ambitions différentes.
Nous préférons démarrer petit avec un vrai IAM plutôt que démarrer vite avec un outil dont nous connaissons déjà les limites.
Une Clio, oui. Un monocycle, non.
En France, on entend souvent la même objection lorsqu’un projet IAM commence à prendre de l’ampleur : « Nous n’avons pas besoin d’une Rolls-Royce, une Clio suffit. »
Nous sommes plutôt d’accord. Une PME ou une ETI n’a aucune raison d’acheter la complexité d’un grand groupe si elle n’en a pas besoin. Le problème commence lorsque la prétendue Clio n’a ni coffre, ni banquette arrière et qu’il faut pédaler pour avancer.
Un outil peut être très efficace sur un cas d’usage étroit et devenir contraignant dès que l’entreprise veut ajouter une application, introduire une validation métier, mieux gérer les exceptions ou simplement comprendre plus finement qui possède quoi. Ce qui semblait simple au départ produit alors de nouveaux contournements.
La simplicité utile consiste à ne déployer que ce dont on a besoin. Elle ne consiste pas à choisir une architecture qui interdit le reste.
Une collection d’automatismes n’est pas encore une tour de contrôle
Un script peut créer un compte. Un workflow peut transmettre une information. Une automatisation peut éviter une tâche au support. Ces briques ont de la valeur, mais elles répondent d’abord à la question : « quelle action faut-il exécuter ? »
Un IAM doit permettre d’aller plus loin. Il relie ces actions au cycle de vie d’une identité, aux règles qui s’appliquent, aux décisions humaines nécessaires et à ce qui s’est réellement passé. L’enjeu n’est plus seulement de lancer correctement plusieurs automatismes, mais de disposer d’un endroit depuis lequel le processus peut être compris et piloté.
C’est ce que nous appelons une tour de contrôle. Elle n’a pas besoin de tout gouverner dès le premier jour, mais elle doit permettre de voir le système comme un ensemble plutôt que comme une accumulation de recettes techniques.
Le prix d’un outil trop limité apparaît rarement au début
Les premières semaines favorisent naturellement l’outil le plus simple. Il traite le besoin immédiat, demande peu de paramétrage et donne rapidement l’impression que le problème est réglé.
La difficulté apparaît avec la demande suivante. Une nouvelle application doit entrer dans le périmètre. Les RH veulent distinguer plusieurs populations. Les managers doivent intervenir dans certaines décisions. Une exception métier devient récurrente. L’entreprise veut davantage de traçabilité ou souhaite étendre ce qu’elle a déjà automatisé.
Si chaque nouveau besoin oblige à ajouter un autre mécanisme, contourner une limitation ou reconstruire ailleurs une partie du processus, la rapidité initiale commence à coûter cher. L’équipe informatique récupère la complexité que l’outil était justement censé supprimer et les métiers découvrent progressivement ce qu’ils ne peuvent pas faire.
C’est cette frustration que nous cherchons à éviter. Un premier IAM doit donner envie d’étendre ce qui fonctionne, pas obliger l’entreprise à recommencer lorsqu’elle devient plus mature.
La bonne réponse, ce sont les paliers
Choisir une plateforme capable d’aller loin ne signifie pas tout déployer immédiatement. Nous préférons précisément l’approche inverse : une plateforme suffisamment structurante, utilisée par paliers.
Le premier palier peut se concentrer sur la source RH, les arrivées et les départs, quelques comptes essentiels et des règles simples. Si cela suffit durablement à l’organisation, il n’y a aucune raison de compliquer le dispositif.
Si les besoins progressent, le périmètre peut progresser avec eux : davantage d’applications, des workflows plus riches, plus de décisions métiers, davantage de contrôle ou une gouvernance plus avancée. La maturité n’est pas une obligation contractuelle ; elle doit rester une possibilité.
Cette logique permet aussi d’accepter qu’un vrai programme IAM prenne parfois un peu plus de temps qu’un assemblage d’automatismes. Le sujet n’est pas d’obtenir le maximum de fonctionnalités dès le départ, mais de s’assurer que ce que l’on construit aujourd’hui ne devienne pas l’obstacle de demain.
Monter en maturité devrait être une bonne nouvelle
Nous ne voulons pas enfermer une entreprise dans un niveau de sophistication qu’elle n’a pas demandé. Nous ne voulons pas davantage l’enfermer dans un outil qu’elle devra remplacer précisément parce que son premier projet IAM a réussi.
Si quelques flux bien maîtrisés suffisent, très bien. Si leur succès fait apparaître de nouveaux besoins, c’est encore mieux : l’organisation a gagné en maturité et peut passer au palier suivant lorsqu’elle en perçoit la valeur.
C’est aussi pour cette raison que nous distinguons le périmètre du projet de la capacité de la plateforme. Le premier doit rester raisonnable. La seconde doit laisser de la place.
Chez Mon premier IAM, nous croyons donc aux projets progressifs, mais pas aux impasses progressives. Commencer simplement est une stratégie. Être condamné à rester simple est une limitation.