# Connecteur Microsoft Entra ID (Azure AD)

> Import des utilisateurs d'un annuaire Microsoft Entra ID (Azure AD) dans Isi-APP
> via Microsoft Graph, avec revue avant application. Remplace l'ancien écran de
> synchronisation `/azure`.

## Ce que fait le connecteur

- Récupère les utilisateurs d'un tenant Azure AD via Microsoft Graph (`/users`).
- Compare l'annuaire à vos utilisateurs Isi-APP et propose des **créations**,
  **modifications** et **archivages**, à valider manuellement (rien n'est appliqué
  sans confirmation).
- Rattache automatiquement chaque utilisateur à une **entité** (et une **adresse**)
  par rapprochement société / bureau, modifiable à la validation.
- Remonte les utilisateurs **non traités** (Prénom/Nom absents, e-mail absent)
  dans un onglet dédié, avec le motif — pour ne pas laisser croire à un échec de synchro.
- Isole dans un onglet **À vérifier** les rares **incohérences** qui demandent votre
  arbitrage (compte archivé ici mais toujours actif dans l'annuaire, homonyme actif). Elles
  sont peu nombreuses face aux lignes inexploitables : mélangées à elles, personne ne les
  verrait.

## Pré-requis côté Microsoft (Azure / Entra ID)

- Un **Tenant ID** (identifiant d'annuaire).
- Une application Azure avec les permissions applicatives **User.Read.All** et
  **Directory.Read.All** (consentement administrateur).
- **Deux modes d'authentification (hybride)** :
  - **Application globale ISI** (par défaut) : vous ne fournissez que le Tenant ID, ISI
    fournit l'application. Onboarding immédiat.
  - **Votre propre application** : vous fournissez Tenant ID + Application (client) ID +
    Client Secret. Isolation totale ; recommandé si vous souhaitez maîtriser l'accès.

## Configuration de l'instance

Deux entrées équivalentes :

- **Configuration rapide** (modale, bouton « Configuration rapide » sur la page du
  connecteur) : Tenant ID requis, Application ID / Secret optionnels, **test de
  connexion** intégré.
- **Configuration complète** (page « Configuration ») : mêmes champs + planification.

Laisser Application ID / Secret vides ⇒ l'application globale ISI est utilisée. Les
renseigner n'a d'intérêt que si vous souhaitez **maîtriser votre propre application** Azure
(consentement et révocation de votre côté, indépendance vis-à-vis de l'application ISI).

Il n'y a **aucune URL à configurer** : l'adresse de Microsoft Graph est fixe et gérée par
Isi-APP. Le champ « URL de connexion » n'apparaît donc pas pour ce connecteur.

Il n'y a **pas non plus de flux de données à choisir** : le connecteur n'en propose qu'un
(« Utilisateurs »), sélectionné automatiquement dès l'installation. Enregistrer la
configuration rapide avec un Tenant ID exploitable **active l'instance** : elle apparaît
alors dans la sidebar et l'extraction devient possible. Aucune synchronisation ne part
pour autant toute seule — l'extraction reste déclenchée à la main.

### Reprendre un annuaire déjà déclaré

Les annuaires saisis dans **Paramètres DSI › Azure** sont proposés directement dans la liste
« Annuaire Azure » : les choisir renseigne le Tenant ID (et le nom de l'instance s'il est
vide), sans avoir à recopier l'identifiant. Un annuaire déjà rattaché à une autre instance
reste listé mais signalé « déjà rattaché » — utile pour voir, sur une entité multi-annuaires,
ce qu'il reste à brancher. « Saisir un autre annuaire… » rouvre la saisie libre.

Inversement, un annuaire configuré ici mais absent des Paramètres DSI y est **ajouté
automatiquement**, pour que l'ancien écran `/azure` et le tableau de bord restent cohérents
pendant la coexistence des deux systèmes. Le libellé déjà saisi en Paramètres DSI n'est
jamais écrasé.

Un bouton **« Gérer les annuaires déclarés »** ouvre directement le référentiel
(Paramètres DSI › Azure) dans un **nouvel onglet**, pour ne pas perdre la configuration en
cours de saisie. Quand aucun annuaire n'est encore déclaré, la liste « Annuaire Azure »
n'apparaît pas : le bouton devient alors **« Déclarer un annuaire »** et reste le seul chemin
visible vers l'écran qui débloque la situation.

Le bouton n'est présent que si vous avez effectivement accès aux Paramètres DSI et au module
Azure — inutile de proposer un lien qui se solderait par un refus. C'est la **même condition**
que celle qui fait apparaître la carte « Azure » dans les Paramètres DSI : les deux apparaissent
et disparaissent ensemble. Il figure aux deux emplacements de configuration (modale
**Configuration rapide** et page **Configuration**).

## Extraction & validation

1. Cliquez sur **« Extraire & comparer »** : l'extraction tourne en tâche de fond et
   alimente une liste de propositions.
   Des utilisateurs **non traités** ne sont pas un échec de synchronisation : l'extraction est
   rapportée comme réussie, et le compte des lignes concernées reste affiché dans son message.
   Seule une vraie panne (annuaire injoignable, réponse anormale) marque l'extraction en erreur.

2. Revoyez les onglets — **chacun rappelle son rôle en une phrase, en haut de sa liste**, y
   compris lorsqu'il est vide :
   - **Créations** — nouveaux utilisateurs. Une entité de rattachement est proposée par
     ligne ; une « entité par défaut » sert de repli pour les lignes non rattachées.
     Une ligne sans entité (aucune proposition, aucune entité par défaut choisie) n'est **pas
     créée** : elle reste dans l'onglet, un message vous invite à choisir une entité, et le
     reste de votre sélection s'applique normalement. Rien n'est perdu, vous rejouez la
     validation une fois l'entité choisie.
   - **Modifications** — utilisateurs existants dont le nom, prénom, e-mail ou téléphone
     a changé. Une différence de **casse, d'accent ou de mise en forme** n'est pas un
     changement : `0682336314`, `06 82 33 63 14` et `+33 (0)6 82 33 63 14` sont le même
     numéro, `Fanélie` et `Fanelie` la même personne. Ces écarts ne sont donc pas proposés — les appliquer
     appauvrirait votre fiche au lieu de l'enrichir.
     L'**ID Azure** manquant y est en revanche proposé au remplissage, sur les comptes créés
     avant le connecteur : c'est lui qui rattache la fiche à l'annuaire, et sans lui le départ
     de la personne ne pourra jamais être détecté. Un ID déjà renseigné n'est jamais remplacé.
     Si la personne a été **archivée entre l'extraction et votre validation** (départ acté
     entre-temps), la modification est **refusée** et la ligne passe en erreur avec son motif :
     l'appliquer réactiverait son compte et donc son accès, avec les droits qu'il avait avant.
     Si elle est réellement revenue, désarchivez-la à la main.
   - **Archivages** — utilisateurs absents de l'annuaire (compte archivé, réversible).
     Une personne dont le compte Azure a été **recréé** n'y figure pas : elle change
     d'identifiant côté Microsoft, mais reste présente dans l'annuaire, donc à son poste.
   - **À vérifier** — les deux **incohérences** qu'Isi-APP refuse de trancher seul : un
     compte archivé ici mais toujours actif dans l'annuaire, et un homonyme actif sur une
     ligne qui aurait sinon été créée. Ce ne sont pas des propositions — rien n'y est
     applicable, seul « Ignorer » y figure —, mais chacune demande une décision de votre part.
   - **Non traités** — utilisateurs qu'Isi-APP n'a pas pu exploiter du tout : e-mail absent,
     compte sans Prénom ni Nom. Il n'y a rien à décider, seulement à corriger côté Microsoft
     si la ligne devait être importée. C'est aussi là que remonte une ligne dont
     l'**écriture** a échoué, avec le message technique — mais pas une ligne simplement
     refusée faute d'entité de rattachement, qui reste dans « Créations » à votre main.
3. Appliquez unité par unité ou par sélection. Rien n'est écrit avant votre validation.

Les deux derniers onglets sont séparés parce que leurs volumes n'ont rien de comparable : sur
un annuaire de 4 200 comptes, on a relevé **1 584** lignes inexploitables (boîtes partagées,
listes de diffusion, comptes de service) pour **4** incohérences à arbitrer. Réunies, les
quatre étaient introuvables — et le geste naturel devant 1 500 rebuts, « tout sélectionner »
puis « Ignorer », les aurait fait taire définitivement.

### Utilisateur archivé mais toujours actif dans Azure

Si un utilisateur a été **archivé dans Isi-APP** alors que son compte est **encore actif dans
l'annuaire Azure**, il apparaît dans **« À vérifier »** avec ce motif. Ce n'est pas une
proposition : Isi-APP ne peut pas deviner laquelle des deux situations s'applique.

| Situation | Ce qu'il faut faire |
|---|---|
| La personne est **revenue** | La désarchiver dans Isi-APP (fiche utilisateur) |
| La personne est **partie** et son compte Azure n'a pas été désactivé | Désactiver le compte côté Microsoft |

Le connecteur ne fait ni l'un ni l'autre à votre place : désarchiver rendrait à la personne son
accès Isi-APP **et ses droits d'avant**, ce qui ne doit jamais être automatique.

Un compte désactivé des deux côtés est cohérent et n'apparaît pas. Si le signalement ne vous
concerne pas, le bouton **Ignorer** le fait disparaître durablement.

### Ce qu'affiche la fiche d'un utilisateur

Chaque proposition est présentée sous forme de fiche, présentée comme les fiches de
l'écran **OCS v3** pour que les deux écrans de revue se lisent de la même façon :

| | |
|---|---|
| **En-tête** | Nom, e-mail, et à droite l'état de la proposition (*Nouveau*, *Modifié*, *A archiver*, *À vérifier*, *Non traité*) |
| **Identité** | Nom complet Azure, **Fonction**, **Service** |
| **Rattachement** | **Entité** et **Adresse** proposées |
| **Contact** | **Téléphone**, **Portable**, Login |
| | Le **Téléphone** reprend le numéro professionnel Azure uniquement s'il s'agit d'une ligne fixe. Beaucoup d'annuaires y placent le mobile de la personne : dans ce cas il alimente le **Portable**, et votre numéro fixe est préservé. |
| | Le **Téléphone** est seulement **complété**, jamais remplacé : Azure ne le propose que si la fiche Isi-APP n'en porte aucun. Un numéro que vous avez saisi vous-même n'est donc jamais écrasé par l'annuaire, même s'il y figure différemment. Le **Portable**, lui, est mis à jour depuis Azure, qui en est la source de référence. |
| | Sur une proposition qui porte sur un compte existant (Modifications, Archivages, À vérifier), les numéros affichés sont **ceux de la fiche Isi-APP**, pas ceux de l'annuaire : le numéro proposé, lui, apparaît dans le bloc de comparaison. Une fiche sans fixe n'affiche donc pas de Téléphone, et seule la comparaison montre le numéro à venir. |
| **Supprimé ?** | État du compte **Isi-APP** rattaché : *Actif*, ou sa date d'archivage. Absent sur une création, qui n'a pas encore de compte Isi-APP. |
| **Détails Azure** | UPN, **ID Azure** et date de création du compte — repliés, à déplier au besoin |

Un liseré de couleur sur le bord gauche rappelle la nature de la proposition (ambre pour une
modification ou une incohérence à vérifier, rouge pour un archivage ou une ligne non traitée),
et la fiche s'entoure d'un liseré bleu quand vous la cochez.

Sur l'onglet **À vérifier**, l'**Entité** affichée est celle du compte Isi-APP concerné — le
compte archivé, ou l'homonyme déjà en base : c'est lui que vous devez identifier, pas un
rattachement à proposer.

Le bandeau de synchronisation, en haut de l'écran, reprend le même découpage : un badge
**« N à vérifier »** distinct du **« N non traité(s) »**, pour que les deux chiffres ne se
contredisent pas.

Les champs vides ne sont pas affichés : une fiche ne montre que ce qu'Azure renseigne
réellement pour cette personne.

Sur l'onglet **Modifications**, l'ancienne valeur apparaît barrée en rouge et la nouvelle en
vert, comme sur l'écran OCS.

**Pourquoi cette entité est-elle proposée ?** L'entité et l'adresse sont déduites des champs
**Société** et **Bureau** d'Azure, par rapprochement avec vos entités et adresses. La fiche
affiche donc la valeur Azure d'origine juste avant la proposition :

> Entité : *Isi GROUPE* → **ISI GROUPE SAS**

Vous voyez ainsi sur quoi le rapprochement s'est appuyé, et pouvez le corriger à la
validation. Si aucune entité ne correspond, la valeur Société reste affichée et la fiche
indique « à rattacher » à sa droite — c'est généralement cette valeur qui explique l'absence
de correspondance.

**Compte désactivé dans Azure.** Un badge orange **Désactivé** apparaît dans l'en-tête de la
fiche (survolez-le pour l'explication complète). L'importer créerait un accès Isi-APP pour
quelqu'un qui n'a plus d'accès Microsoft : à vérifier avant d'appliquer.

**Archivages.** La fiche décrit le compte Isi-APP visé (entité, login, téléphones) et non
seulement l'e-mail, afin que vous sachiez précisément quel compte va être archivé.

## Comptes qui ne sont pas des personnes

Dans Azure, le **Prénom** et le **Nom** ne sont renseignés que sur les comptes de
personnes. Une boîte partagée, une liste de diffusion ou un compte de service n'en a pas —
seul son **Nom complet** existe (par exemple « Isi-GROUPE - Service Compta »).

Ces comptes ne sont **jamais proposés en création**. Ils remontent dans l'onglet
**« Non traités »** avec le motif « probable boîte partagée, liste de diffusion ou compte
de service », afin que vous puissiez les vérifier. L'ancien écran les écartait sans rien
afficher : vous les voyez désormais, sans risquer de les importer comme des utilisateurs.

Sont également écartés de la synchronisation, sans apparaître du tout :

- les **comptes invités** (utilisateurs externes de votre annuaire) ;
- les comptes dont le Nom complet contient « admin » ;
- les adresses en `onmicrosoft.com`.

## Doublon probable : même personne, nouvelle adresse e-mail

Le rapprochement entre l'annuaire et vos fiches se fait sur l'**ID Azure**, puis sur
l'**adresse e-mail**. Si une personne change d'adresse — par exemple parce que votre
convention de nommage a évolué, `clelia.roux@` devenant `c.roux@` — aucun des deux ne
correspond, et sa fiche Azure ressemble alors à un nouvel arrivant.

Dans ce cas, si **un utilisateur actif porte déjà le même prénom et le même nom**, la ligne
n'est pas proposée en création : elle remonte dans **« À vérifier »** avec le motif
correspondant, et la fiche indique quel compte entre en collision (entité, login,
téléphones). À vous de trancher : soit c'est la même personne et son adresse doit être
corrigée sur sa fiche existante, soit ce sont deux homonymes et le nouveau compte est
légitime.

Le rapprochement lui-même n'utilise **jamais** le nom : deux personnes peuvent
légitimement porter le même. Le nom sert uniquement à vous alerter. Un homonyme dont le
compte est **archivé** ne déclenche pas ce signal — la création se fait normalement.

## Cohérence avec l'ancien écran

Les données remontées sont alignées sur celles de l'ancien écran `/azure` : mêmes comptes
retenus, **accents retirés** des nom, prénom et e-mail (« Fanélie Démo » → « Fanelie
DEMO »), et un seul compte conservé par adresse e-mail — le plus récemment créé — si votre
annuaire en contient plusieurs.

## Comportements importants

- **Rien n'est appliqué automatiquement** : toute création / modification / archivage
  passe par votre validation.
- **Archivage réversible** : un utilisateur retiré est archivé (soft delete + e-mail
  préfixé `_`), jamais supprimé définitivement.
- **Qui peut être proposé à l'archivage** : uniquement les utilisateurs déjà **rattachés à
  Azure**, y compris ceux importés autrefois par l'ancien écran. Un compte créé à la main
  dans Isi-APP n'est jamais proposé, même s'il est absent de votre annuaire — l'ancien écran
  le proposait, à tort.
- **Sécurité** : si l'annuaire Azure revient vide (incident côté Microsoft), aucun archivage
  n'est proposé et l'extraction le signale, plutôt que de vous proposer d'archiver tout le
  monde.
- **Comptes exclus** (ignorés, non remontés) : cf. « Comptes qui ne sont pas des
  personnes » ci-dessus.
- **Rattachement préservé** : l'entité / l'adresse d'un utilisateur existant ne sont pas
  réécrites par le rapprochement automatique à chaque synchro (modification manuelle
  respectée).

## Accès

Module **informatique** requis, réservé aux administrateurs (Store admin). L'ancien
écran `/azure` **reste accessible** en parallèle pour le moment : les deux modes de
synchronisation cohabitent le temps de la bascule.

Dans la sidebar, sous **Personnes**, les deux entrées sont donc distinguées par un badge,
comme les deux entrées OCS :

| Entrée | Badge | Destination |
|---|---|---|
| Azure | 🔴 **Ancien** | écran de synchronisation legacy `/azure` |
| Azure | 🟢 **Nouveau** | écran de revue du connecteur Store |

L'entrée « Nouveau » apparaît **dès que le connecteur est installé**, avant même d'être
configuré : c'est par elle qu'on atteint l'écran portant la « Configuration rapide ». L'entrée
« Ancien » n'apparaît qu'aux entités qui utilisaient déjà l'écran legacy : une entité qui
découvre Azure par le Store ne voit que l'entrée « Nouveau ».

Chaque instance porte par ailleurs un bouton **Synchronisation** sur sa carte, dans
« Mes connecteurs », qui mène directement à son écran de revue.

### Plusieurs annuaires Azure

Une entité peut avoir **plusieurs annuaires** Azure (plusieurs tenants Microsoft) : il faut
alors **installer une instance par annuaire** depuis la fiche du connecteur (bouton
« Nouvelle instance »), puis configurer le Tenant ID propre à chacune. Le lien
« Nouveau » mène alors à un **écran de sélection** listant vos annuaires, chacun avec son
état, sa dernière synchronisation et un bouton **Revue**.

Si vous n'avez qu'un seul annuaire — le cas de la grande majorité des entités — cet écran
ne s'affiche pas : vous arrivez directement sur son écran de revue.

> ⚠️ Avec **deux annuaires actifs ou plus**, la proposition d'**archivage** est restreinte :
> un utilisateur absent d'un annuaire peut être présent dans l'autre, et Isi-APP ne peut pas
> encore trancher pour les comptes rattachés à Azure avant la bascule. L'onglet Archivages
> reste donc vide, et l'écran de sélection vous le signale. Les créations et modifications
> ne sont pas concernées.

## Ignorer un utilisateur

Le bouton **Ignorer** des onglets de revue exclut **durablement** un utilisateur de la
synchronisation : il ne sera plus proposé en création, même s'il reste présent dans votre
annuaire Azure. C'est l'équivalent de la fonction « ignorer » de l'ancien écran.

L'onglet **Ignorés** liste ces exclusions (e-mail, date, auteur) et permet de les lever
avec **Ne plus ignorer**. L'utilisateur redevient alors proposable à la prochaine
synchronisation — rien n'est rejoué immédiatement, l'annuaire n'étant pas interrogé depuis
cet onglet.

Trois précisions utiles :

- L'exclusion porte sur l'**e-mail**, pas sur l'identifiant Azure. Un compte supprimé puis
  recréé dans votre annuaire reste donc ignoré.
- Elle vaut pour **toute votre entité**, et pas seulement pour le connecteur depuis lequel
  vous l'avez posée : si vous installez un second connecteur Azure, il respectera la même
  liste.
- Les utilisateurs déjà ignorés dans l'ancien écran ont été **repris automatiquement** :
  votre liste d'exclusions est conservée à l'identique dans le nouveau connecteur.

Une personne ignorée n'est jamais créée, modifiée **ni archivée** par la synchronisation :
elle sort entièrement du périmètre du connecteur.

## Limites

- Un utilisateur sans e-mail dans Azure ne peut pas être créé (remonté en « Non traités »).
- Le rapprochement entité/adresse est un **best-effort** (société ↔ entité, bureau ↔
  adresse) : à vérifier à la validation.