Que mettre dans le cahier des charges ?
Cahier des charges IAM : le plan type d’un premier projet
Un cahier des charges IAM utile décrit cinq choses : pourquoi et pour qui, comment les identités naissent et disparaissent, quels droits et contrôles, quelles contraintes techniques et de reprise, comment le service vivra après la mise en service. Les 20 rubriques ci-dessous disent quoi écrire, donnent un exemple et signalent le piège courant.
Avant les 20 rubriques
Un premier besoin se décrit en six points
Pas besoin d’un document de grand projet pour démarrer. Répondre à ces six questions suffit à préparer une discussion avec votre équipe, un éditeur ou un intégrateur ; les rubriques détaillées servent ensuite à préciser ce qui compte pour votre premier lot.
Partez d’un problème déjà décrit : les arrivées, les départs ou les prestataires. Pour le vocabulaire (source, règle, exécution, contrôle), voyez comment ça marche.
- Le problème
Qu’est-ce qui ne va pas aujourd’hui ? Arrivées trop manuelles, comptes actifs après un départ, accès prestataires mal suivis.
Rubriques : Contexte, Objectifs
- Le périmètre initial
Quelles populations, quels événements RH, quels annuaires et quelles applications ?
Rubriques : Périmètre, Populations, Cibles
- Les règles de gestion
Qui déclenche, qui autorise, quels droits sont standard, quels cas demandent une validation ?
Rubriques : Droits, Demandes, Validations
- Les exigences techniques
Quelles sources sont disponibles, quels systèmes connecter, quelles contraintes d’intégration vérifier ?
Rubriques : Sources, Intégrations, Exigences techniques
- Les contrôles attendus
Comment vérifier qu’un compte a été créé, modifié ou désactivé correctement ? Qui traite les erreurs et exceptions, que doit-on tracer ?
Rubriques : Création et retrait, Traçabilité
- Les critères de réussite
Quels résultats concrets diront que le premier lot est opérationnel ?
Rubriques : Critères de recette, Déploiement progressif
Indispensable au premier lot, ou utile plus tard
Deux erreurs coûtent cher : oublier un besoin critique, découvert en recette, et surdimensionner le projet avec des fonctions qui ne répondent encore à aucun problème identifié. Le périmètre se choisit avant d’écrire : voyez par quoi commencer, puis ce que chaque exigence implique dans le budget.
Indispensable au premier lot
- La source de référence et l’identifiant qui permet de rapprocher les comptes.
- Le retrait des accès au départ, pas seulement la création à l’arrivée.
- Le comportement en cas d’erreur ou de donnée manquante.
- Les accès techniques aux systèmes connectés et leur propriétaire.
- La reprise des comptes existants du périmètre.
- Des scénarios de recette sur de vrais mouvements.
Pertinent lors d’une extension
- Un modèle de rôles couvrant toute l’organisation.
- Les revues d’accès périodiques, une fois les données rapprochées.
- La séparation des tâches entre droits incompatibles.
- Un portail de demandes pour toutes les applications.
- Le raccordement des applications à faible volume de mouvements.
20/20 rubriques retenues pour votre trame. Décochez ce qui ne concerne pas votre premier lot.
Trame de cahier des charges IAM — Mon premier IAM
Pourquoi et pour qui
Organisation, effectifs, entités, outils actuels, ce qui a déclenché le projet.
Exemple : « 1 SIRH, 1 AD synchronisé avec Entra, comptes créés par tickets. »
Piège : Raconter l’historique au lieu de décrire l’état actuel.
Deux ou trois résultats observables, avec l’indicateur qui le prouvera.
Exemple : « Un arrivant a son compte et sa messagerie le jour J, sans ticket. »
Piège : Des objectifs génériques (« améliorer la sécurité ») impossibles à recetter.
Ce qui est inclus et, explicitement, ce qui ne l’est pas.
Exemple : « Hors lot 1 : prestataires, revues d’accès, application X. »
Piège : Tout mettre en lot 1 : le chiffrage devient inexploitable.
Salariés, intérimaires, prestataires, stagiaires : volume et source de chacune.
Exemple : « Prestataires : ~80, aucune source, déclarés par mail. »
Piège : Oublier les populations sans source RH.
Identités et cycle de vie
Système, format d’échange, fréquence, champs disponibles, identifiant unique.
Exemple : « Export quotidien CSV, matricule stable, manager renseigné à 90 % » — chiffre à mesurer chez vous.
Piège : Supposer que le fichier RH est prêt sans l’avoir ouvert.
Arrivée, mobilité, départ, retour, absence longue : ce qui doit se passer, quand.
Exemple : « Départ : désactivation le soir du dernier jour, suppression à J+90. »
Piège : Décrire l’arrivée et oublier la mobilité.
Annuaires et applications à alimenter, avec mode d’accès (API, LDAP, base, aucun).
Exemple : « Application RH métier : pas d’API, tâche manuelle générée. »
Piège : Promettre un connecteur sans connaître l’interface.
Règles de nommage, groupes par défaut, délais, comportement en cas d’erreur.
Exemple : « prenom.nom, doublon : ajout d’un chiffre. »
Piège : Ne rien dire du retrait, qui est pourtant le premier gain de sécurité.
Droits et contrôles
Accès standards par profil fréquent ; le reste sur demande.
Exemple : « Tout comptable : groupe Compta + dossier partagé + appli X. »
Piège : Exiger un modèle de rôles complet avant d’avoir un flux qui marche.
Qui demande, pour qui, par quel canal, avec quel délai.
Exemple : « Le manager demande depuis le portail ; délai cible 1 jour ouvré. »
Piège : Multiplier les circuits dès le départ.
Qui valide quoi ; ce qui se passe en cas d’absence.
Exemple : « Manager puis propriétaire applicatif pour les droits sensibles. »
Piège : Des validations à trois niveaux pour tout.
Si incluses : périmètre, fréquence, qui relit. Sinon, le dire.
Exemple : « Hors lot 1, prévu après stabilisation. »
Piège : Lancer une revue sur des données non réconciliées.
Ce qu’il faut pouvoir retrouver : qui, quoi, quand, pourquoi, et pendant combien de temps.
Exemple : « Historique des créations et retraits exportable pour l’audit. »
Piège : Demander « des logs » sans dire quelle question ils doivent permettre de répondre.
Technique et reprise
Hébergement (SaaS ou sur site), authentification des administrateurs, sauvegarde, réversibilité.
Exemple : « Hébergement en France ou UE requis. »
Piège : Copier une liste d’exigences générique non vérifiable.
Liste des systèmes avec version, propriétaire, accès disponible.
Exemple : « AD 2019, compte de service à créer par l’équipe système. »
Piège : Découvrir pendant le projet qu’aucun accès technique n’est possible.
Comptes historiques à rapprocher, orphelins, ancien outil à remplacer, coexistence, retour arrière.
Exemple : « Rapprochement des comptes AD par matricule, revue manuelle des non-rapprochés. »
Piège : Ignorer la reprise : c’est souvent le poste qui dérape.
Mise en service et durée
Qui exploite, qui ajoute une application, quel support, quels engagements.
Exemple : « L’équipe IT ajoute une application standard sans prestataire. »
Piège : Ne chiffrer que le projet et découvrir le coût du RUN ensuite.
Ce qui revient à vous, au fournisseur, à l’intégrateur : données, accès, recette.
Exemple : « La RH corrige les données ; l’intégrateur signale les anomalies. »
Piège : Laisser la qualité des données sans responsable.
Scénarios concrets : une arrivée, une mobilité, un départ, un cas d’erreur.
Exemple : « Un départ saisi en RH désactive le compte AD le soir même. »
Piège : Recetter des écrans au lieu de recetter des mouvements.
Ordre des lots, condition pour passer au suivant, possibilité de rester au lot 1.
Exemple : « Lot 2 seulement après un mois sans incident sur le lot 1. »
Piège : Un planning qui impose tous les lots d’avance.
Votre sélection reste dans ce navigateur ; rien n’est transmis.
Questions fréquentes
Existe-t-il un modèle de cahier des charges IAM ?
La trame de cette page en est un : 20 rubriques groupées en cinq parties. Cochez celles qui s’appliquent à votre premier lot puis imprimez ou enregistrez en PDF ; chaque rubrique rappelle ce qu’il faut écrire.
Cahier des charges ou RFP : quelle différence ?
Le cahier des charges décrit votre besoin. La RFP (ou appel d’offres) est la consultation qui l’envoie à plusieurs fournisseurs avec un format de réponse et des critères. Le second s’appuie sur le premier.
Quels critères pour choisir une solution IAM ?
Les plus discriminants pour un premier projet : capacité à raccorder vos sources et cibles réelles, effort pour ajouter une application, autonomie de votre équipe en exploitation, coût total sur plusieurs années, et qualité de l’accompagnement en français.
Quelle longueur pour un cahier des charges IAM ?
Assez pour qu’un fournisseur chiffre sans hypothèse majeure. Pour un premier lot, une quinzaine de pages précises valent mieux qu’un document exhaustif sur un périmètre que vous ne livrerez pas.