Provisioning automatique avec SCIM 2.0 Module

Vaks PM · Guide d'intégration · SCIM 2.0 · Juillet 2026

Ce que vous obtiendrez. Votre annuaire créant, mettant à jour et désactivant les comptes Vaks PM de lui-même, et maintenant les équipes alignées sur les groupes de l'annuaire — arrivées, mobilités et départs sont donc traités là où vous les traitez déjà. Ce guide couvre Microsoft Entra ID et Okta.

Mettez d'abord en place l'authentification unique. Les deux côtés rapprochent les comptes sur l'identifiant d'objet immuable de l'annuaire. Configurez et testez OIDC ou SAML avec un utilisateur pilote avant d'activer le provisioning, pour découvrir à ce moment-là plutôt qu'à grande échelle que l'identifiant est bien aligné. Les comptes provisionnés par SCIM sont en connexion fédérée seulement — ils n'ont pas de mot de passe, donc sans fédération opérationnelle personne ne peut les utiliser.

Ce que ça fait — et ce que ça ne fait pas

Vaks PM expose un point de terminaison SCIM 2.0 standard piloté par votre annuaire. Il prend en charge les utilisateurs et les groupes, avec la création, la lecture, la mise à jour, le patch et la suppression complets. Il n'y a pas de planificateur côté Vaks PM : chaque changement est poussé par votre annuaire sur son propre cycle, typiquement toutes les 40 minutes pour Entra.

Il provisionne des personnes, pas des droits. Les nouveaux comptes atterrissent sur le rôle membre standard. Les rôles viennent du mappage de groupes à la connexion, configuré dans les guides d'authentification unique, pas de SCIM.
Il ne supprime jamais définitivement. La désactivation suspend ; la suppression est logique. Les données sont préservées dans les deux cas.
Il ignore la plupart des attributs. Seuls l'email, le nom, l'état actif, l'identifiant externe et le numéro d'employé sont enregistrés. Fonction, service, manager, téléphone et le reste sont acceptés puis silencieusement écartés.
Les comptes agents lui sont invisibles. Les identités d'agents IA ne peuvent être ni lues ni gérées via SCIM.

Provisioning et sièges de licence

C'est le comportement le plus surprenant, il vaut donc la peine de l'énoncer clairement avant de commencer.

SCIM n'accorde jamais de siège de licence. Un utilisateur provisionné a un compte mais aucun accès au tableau de bord tant qu'un siège ne lui est pas accordé. C'est délibéré : votre annuaire peut pousser un millier de personnes sans consommer silencieusement un millier de licences, et le provisioning n'échoue jamais sur une erreur de quota. Mais cela signifie que, laissés tels quels, les utilisateurs fraîchement provisionnés se connectent à rien du tout.

Vous avez deux façons de combler cet écart :

Accorder les sièges à la main dans Admin → Utilisateurs — praticable quand les arrivées sont occasionnelles.
Utiliser une équipe à licence automatique — le schéma recommandé. Marquez une équipe comme licenciée automatiquement, puis pointez un groupe d'annuaire vers elle. Toute personne que l'annuaire ajoute à ce groupe reçoit un siège ; toute personne retirée le libère. Votre population licenciée suit alors un groupe que vous gérez dans l'annuaire.

Prérequis

Côté	Ce qu'il vous faut
Annuaire	Les droits de configurer le provisioning sur une enterprise application. Dans Entra, cela exige une licence Entra ID P1 ou P2 ; le provisioning automatique n'est pas disponible sur l'offre gratuite.
Vaks PM	Le droit `org:manage` — un administrateur d'organisation.
Licence	Une licence couvrant la fonctionnalité SCIM. Sans elle, le point de terminaison refuse chaque appel et les boutons de jeton sont masqués.
Authentification unique	Configurée et testée, conformément à l'avertissement ci-dessus.

Google Workspace ne peut pas piloter ceci. Son provisioning sortant est restreint aux applications du catalogue de Google et n'offre aucune configuration SCIM personnalisée : il ne peut donc pas provisionner une application auto-hébergée. Avec Google Workspace, utilisez l'authentification unique SAML avec création automatique du compte à la première connexion, et gérez les départs en suspendant le compte Google — la connexion fédérée s'arrête immédiatement, même si le compte Vaks PM reste actif tant que personne ne le désactive. Si vous avez besoin d'une véritable automatisation du cycle de vie, la réponse habituelle est un fournisseur d'identité intermédiaire qui, lui, prend en charge le SCIM sortant.

Étape 1 — Générer le jeton dans Vaks PM

Ouvrez Admin → Intégrations → Single sign-on et repérez la carte Provisioning SCIM sous la liste des fournisseurs. Elle vous donne les deux valeurs dont votre annuaire a besoin.

URL du tenant — cliquez pour copier :

https://<votre-hôte>/api/v1/scim/v2

Jeton secret — pressez Générer un jeton SCIM. Le secret est affiché une seule fois, sous la mention « Copiez ce jeton maintenant — il ne sera plus affiché. » Collez-le directement dans votre annuaire.

Le jeton expire, et le provisioning s'arrête net à ce moment-là. Une expiration est obligatoire et plafonnée à deux ans — il n'existe pas de jeton permanent. Vaks PM envoie un rappel par email 14 jours à l'avance, mais notez aussi la date dans votre propre agenda. Au moment de renouveler, sachez que Renouveler révoque immédiatement l'ancien jeton : mettez donc votre annuaire à jour dans la même fenêtre de maintenance.

Si vous exploitez plusieurs organisations sur des sous-domaines distincts, chacune a besoin de sa propre URL de tenant, de son propre jeton et de sa propre application de provisioning — le tenant est identifié par le nom d'hôte que vous appelez.

Si votre instance n'est pas joignable depuis Internet. Le provisioning, c'est l'annuaire qui vous appelle, pas l'inverse — une instance auto-hébergée publiée uniquement sur votre réseau interne est donc hors de portée d'un annuaire dans le cloud. Entra comme Okta résolvent cela par un agent léger installé à l'intérieur de votre réseau, qui n'établit que des connexions sortantes vers l'annuaire : aucun port entrant à ouvrir, aucune exposition publique de l'URL du tenant.

Entra — l'agent de provisioning, dans le cadre du provisioning d'applications on-premise. Exige une licence Entra ID P1 ou P2, comme le provisioning cloud.
Okta — On-Premises Provisioning (OPP), avec l'agent de provisioning Okta sur un hôte Windows ou Linux.

Tout le reste de ce guide est inchangé : même URL de tenant (une adresse interne dans ce cas), même jeton, mêmes mappages d'attributs. Seul le chemin réseau diffère. Installez et enregistrez l'agent en suivant la documentation de votre éditeur, puis revenez à l'étape 2.

Étape 2 — Dans Microsoft Entra ID

Rendez-vous dans Microsoft Entra admin center → Identity → Applications → Enterprise applications et ouvrez l'application créée pour l'authentification unique (ou créez une application hors galerie si le provisioning est tout ce dont vous avez besoin).
Ouvrez Provisioning → New configuration, ou réglez Provisioning Mode sur Automatic.
Collez l'URL du tenant et le Jeton secret de l'étape 1.
Pressez Test Connection. Le test doit réussir avant que vous puissiez enregistrer — il valide le jeton et le scope d'un seul coup.
Sous Users and groups, affectez les personnes et les groupes à provisionner. Sous Settings, réglez le périmètre de provisioning, puis passez Provisioning Status sur On.

Entra effectue un cycle complet initial, puis des cycles incrémentaux environ toutes les 40 minutes. Le premier cycle peut prendre un certain temps sur un annuaire volumineux.

Étape 2b — Dans Okta

Ouvrez votre application Vaks PM dans la console d'administration Okta, allez dans l'onglet Provisioning et choisissez Configure API Integration.
Cochez Enable API integration. Saisissez la Base URL (l'URL du tenant de l'étape 1) et l'API Token (le jeton secret).
Pressez Test API Credentials, puis enregistrez.
Sous To App, activez Create Users, Update User Attributes et Deactivate Users.
Affectez les utilisateurs et les groupes, et poussez explicitement les groupes si vous voulez que les équipes soient créées — Okta n'envoie que les groupes que vous avez ajoutés sous Push Groups.

Étape 3 — Mappages d'attributs

Seuls cinq attributs sont enregistrés. Tout le reste de ce que votre annuaire envoie est accepté puis écarté : élaguer la liste des mappages relève donc de la propreté, pas de la nécessité.

Attribut SCIM	Devient	Remarques
`userName`	L'adresse email du compte	Obligatoire. Enregistré en minuscules. Mappez-le sur l'user principal name ou sur le mail à votre convenance, mais gardez-le cohérent avec ce que présentera l'authentification unique.
`externalId`	La clé de compte	Mappez-le sur l'object ID, pas sur la valeur par défaut d'Entra. Voir l'avertissement ci-dessous.
`active`	Statut du compte	`false` suspend le compte et libère son siège.
`name.formatted` ou `displayName`	Nom affiché	Repli sur prénom + nom, puis sur l'email. Les prénom et nom ne sont pas enregistrés séparément.
`employeeNumber` optionnel	Identifiant d'employé	Issu de l'extension entreprise. Non envoyé par défaut — ajoutez le mappage explicitement si vous le voulez. Doit être unique dans l'organisation.

Changez le mappage externalId par défaut. Entra le mappe d'origine sur mailNickname, qui change quand un utilisateur est renommé — et quand il change, l'annuaire cesse de reconnaître le compte qu'il a créé, puis tente d'en créer un doublon et obtient un conflit. Mappez plutôt externalId sur objectId. C'est aussi la valeur sur laquelle l'authentification unique fait le rapprochement : les deux intégrations convergent ainsi sur le même compte.

Attributs de rapprochement — ce sur quoi on peut filtrer

Avant de créer qui que ce soit, votre annuaire demande si le compte existe déjà, en interrogeant cet endpoint avec un filtre. Entra vous laisse choisir l'attribut de rapprochement (Faire correspondre les objets à l'aide de cet attribut) ; Okta se rapproche toujours sur userName, sans option. Si Entra pointe sur un attribut impossible à filtrer, toutes les recherches échouent.

Ressource	Filtres acceptés
Utilisateurs	`userName eq "…"` · `externalId eq "…"` · `emails[type eq "work"].value eq "…"` · `id eq "…"`
Groupes	`displayName eq "…"` · `externalId eq "…"` · `id eq "…"`

Seule l'égalité sur un attribut unique est gérée. Les filtres composés (and, or), les autres opérateurs de comparaison (ne, co, sw, gt…) et les tests de présence (pr) sont refusés par un 400. Les noms d'attributs peuvent porter leur préfixe de schéma (urn:ietf:params:scim:schemas:core:2.0:User:userName) et la casse est indifférente.

Ne définissez qu'un seul attribut de rapprochement dans Entra. En laisser plusieurs actifs fait interroger Entra sur chacun à son tour, et le premier que cet endpoint ne sait pas filtrer fait échouer le cycle. Gardez userName (ou externalId) et videz les autres.

Étape 4 — Groupes et équipes

Un groupe d'annuaire devient une équipe Vaks PM : le nom affiché du groupe devient le nom de l'équipe, et ses membres en deviennent les membres. Les équipes créées ainsi sont rapprochées sur l'identifiant externe du groupe : renommer le groupe dans l'annuaire renomme donc l'équipe au lieu d'en créer une seconde.

Deux comportements déclenchent régulièrement un ticket de support qui s'avère normal :

Un groupe fraîchement créé arrive souvent vide, et se remplit à un cycle ultérieur. L'annuaire crée le groupe avant d'avoir provisionné tous les membres, et les membres qu'il référence sans qu'ils existent encore sont écartés plutôt que rejetés. Cela se répare tout seul. Si un groupe ne se remplit jamais, la cause est le périmètre de provisioning — les membres ne sont pas affectés à l'application.
Le libellé d'affichage local d'une équipe n'est jamais écrasé par l'annuaire. Seul le nom sous-jacent suit le groupe : un libellé défini dans Vaks PM survit donc.

Retirer un groupe de l'annuaire supprime logiquement l'équipe ; ses membres conservent leurs comptes. Si l'équipe avait la licence automatique activée, ses membres perdent leurs sièges à moins qu'une autre équipe à licence automatique ne les couvre.

Étape 5 — Vérifier

Une fois le premier cycle terminé, vérifiez trois choses :

Dans le journal de provisioning de votre annuaire — les utilisateurs créés, aucune erreur récurrente. Le journal d'Entra nomme chaque utilisateur et le résultat.
Dans Admin → Utilisateurs — les personnes attendues sont présentes. Rappelez-vous qu'elles n'auront pas encore de siège, sauf si une équipe à licence automatique les couvre.
De bout en bout — faites connecter un utilisateur pilote via l'authentification unique. Cela prouve que l'identifiant d'objet est aligné entre le provisioning et la fédération, ce qui est la seule chose la plus susceptible d'être erronée.

Testez ensuite un départ : désactivez l'utilisateur pilote dans l'annuaire, attendez un cycle, et vérifiez que son compte Vaks PM apparaît comme suspendu et que ses sessions ont disparu.

Désactivation et suppression

Action dans l'annuaire	Effet dans Vaks PM
Utilisateur désactivé (`active: false`) ou désaffecté de l'application	Compte suspendu, siège de licence libéré, et toutes les sessions actives révoquées immédiatement. Données et historique préservés.
Utilisateur réactivé	Compte de nouveau actif, mais le siège n'est pas restauré automatiquement — accordez-le à nouveau, ou appuyez-vous sur une équipe à licence automatique.
Utilisateur supprimé	Suppression logique : le compte est suspendu et masqué, ses données conservées.
Une personne précédemment supprimée est provisionnée à nouveau	Le compte d'origine est restauré en place, avec son historique, ses saisies de temps et ses commentaires intacts. Pratique pour un salarié qui revient ; bon à savoir avant de re-provisionner quelqu'un par accident.

Pour effacer les données personnelles d'une personne plutôt que la suspendre, utilisez la fonction d'anonymisation du panneau d'administration — le provisioning n'a pas d'équivalent, par conception.

Dépannage

Les détails d'erreur renvoyés à votre annuaire sont toujours en anglais, quelle que soit la langue de votre interface — l'appelant est une machine et le texte atterrit dans son journal de provisioning. Ils y apparaissent mot pour mot.

Symptôme	Cause & correctif
Le test de connexion échoue · Missing SCIM token	Aucun en-tête d'autorisation exploitable n'est arrivé. Recollez le jeton ; guettez un espace ou un saut de ligne parasite.
Le test de connexion échoue · Invalid or revoked SCIM token	Le jeton est inconnu, révoqué ou expiré. Générez-en un nouveau. Vérifiez aussi que vous appelez le bon nom d'hôte — un jeton d'une organisation ne fonctionne pas sur le sous-domaine d'une autre.
Token lacks the scim:provision scope	Une clé API ordinaire a été utilisée. Utilisez le bouton Générer un jeton SCIM, qui règle le scope pour vous.
403 · This feature ("scim") requires an active license	La licence ne couvre pas SCIM. Importez-en une dans Admin → Organisation → Licence.
400 · Filtering on '…' is not supported	L'annuaire a recherché les comptes par un attribut que cet endpoint ne sait pas filtrer. Dans Entra, ne posez Faire correspondre les objets à l'aide de cet attribut que sur `userName` ou `externalId`, et videz-le partout ailleurs. Voir attributs de rapprochement pour la liste acceptée.
400 · The operator '…' is not supported	Le filtre utilisait autre chose qu'une simple comparaison `eq`. Même correctif : simplifiez la configuration de rapprochement. Des échecs répétés placent le travail de provisioning Entra en quarantaine ; il repart de lui-même une fois la configuration corrigée.
409 · User already exists	Un compte porte déjà cet email ou cet identifiant externe. Généralement, le mappage `externalId` a été changé après le premier cycle : l'annuaire ne reconnaît donc plus les comptes qu'il a créés. Rétablissez le mappage sur `objectId`.
409 · userName (email) already used by another account	Un renommage entrerait en collision avec un autre compte. Résolvez le doublon dans l'annuaire.
409 sur un nom d'équipe	Une équipe de ce nom existe déjà mais n'a pas été créée par le provisioning. Renommez l'une des deux.
Le provisioning fonctionnait, puis s'est complètement arrêté	Le jeton a expiré. Il n'y a pas de période de grâce.
Les utilisateurs sont provisionnés mais ne voient rien	Pas de siège de licence. C'est attendu — voir provisioning et sièges.
Les groupes arrivent sans membres	Normal au premier cycle. Si cela persiste, les membres ne sont pas dans le périmètre de provisioning.
L'annuaire n'arrête pas de créer des doublons	Il ne retrouve pas les comptes existants. Vérifiez que `externalId` est bien mappé sur `objectId` et que le provisioning n'a pas été reconfiguré de zéro, ce qui réinitialise les liens internes de l'annuaire.

Ce qui est journalisé

Chaque écriture de provisioning est auditée, attribuée à l'administrateur qui a généré le jeton, et visible sous Admin → Sécurité & Conformité → Journal d'audit : création de compte (signalée lorsqu'elle a restauré un compte précédemment supprimé), suspension, réactivation, suppression, et changements d'appartenance aux équipes. Les entrées d'appartenance consignent quels membres ont été demandés, lesquels ont été ajoutés, et lesquels ont été écartés faute d'exister encore — l'endroit fiable pour confirmer que le comportement de groupe vide décrit plus haut est bénin.