Intégrations intranet : SSO, systèmes RH et Microsoft 365

Les collaborateurs ne devraient pas avoir à mettre à jour les mêmes coordonnées dans plusieurs systèmes ni à parcourir différentes applications simplement pour trouver un document. Des intégrations intranet bien conçues réduisent ces tâches répétitives, tout en laissant les décisions d’accès et les données dans les systèmes qui en sont responsables.

Open Intranet, développé par Droptica sur Drupal, peut servir de point d’entrée vers les outils de travail sans remplacer votre fournisseur d’identité, votre système RH ou votre plateforme documentaire. L’enjeu de la mise en œuvre consiste à décider quoi connecter, quelles données copier et où contrôler les autorisations.

Ce guide présente les modèles d’intégration à évaluer. Il distingue la configuration de Drupal, les modules communautaires et le développement de connecteurs sur mesure, en précisant les capacités qu’il faut vérifier dans votre installation.

Dans cet article :

• Comment concevoir la couche d’intégration ?
• Comment connecter le SSO et gérer l’accès aux comptes ?
• Comment Open Directory peut-il tenir à jour les profils, services et rôles des collaborateurs ?
• Comment présenter les contenus Microsoft 365 dans Open Intranet ?
• Comment connecter Google Workspace sans exposer de contenus privés ?
• Comment intégrer les tickets sans créer un second centre de support ?
• Comment préserver les droits sur les documents lors d’une intégration avec une GED ?
• Comment tester et maintenir les intégrations intranet ?

Comment concevoir la couche d’intégration ?

Commencez par les tâches des collaborateurs, pas par une liste d’API. « Trouver le service actuel d’un collègue » est une exigence que l’on peut tester. « Intégrer les RH » ne l’est pas.

Pour une première version, identifiez les parcours utiles les plus courts :

• Se connecter avec un compte d’entreprise existant.
• Trouver un collègue et ses coordonnées à jour.
• Ouvrir un document que le collaborateur est autorisé à consulter.
• Envoyer une demande d’assistance et vérifier son statut.

Dressez ensuite un inventaire des intégrations. Chaque connexion doit avoir une source de référence convenue, un responsable, une méthode d’authentification, un sens de lecture et d’écriture ainsi qu’une fréquence de mise à jour.

Il s’agit d’exemples pour la planification, et non d’un catalogue de connecteurs prêts à l’emploi.

Choisissez la connexion la plus simple qui permet d’accomplir la tâche. Un lien vers Teams peut suffire. Copier des contenus Teams dans l’intranet ajoute des contraintes d’autorisations, de stockage et de maintenance sans nécessairement aider les collaborateurs.

Une architecture de référence sépare trois responsabilités :

1. Fournisseur d’identité : authentifier les collaborateurs.
2. Open Directory : mapper et synchroniser les données utilisateur convenues.
3. Autres connecteurs : échanger des données avec les outils de productivité, de support et de gestion documentaire.

Placez la logique des connecteurs dans des services Drupal et, si nécessaire, dans des traitements en arrière-plan, plutôt que d’appeler des API distantes directement depuis les modèles de page.

Avant d’estimer les travaux, vérifiez la version de Drupal installée, les API prises en charge, les restrictions du tenant, les licences et les modules maintenus disponibles. Distinguez la configuration des fonctions existantes, l’installation de modules communautaires et le développement sur mesure. La base open source de Drupal permet des extensions, mais ne rend pas toutes les connexions externes disponibles immédiatement.

Comment connecter le SSO et gérer l’accès aux comptes ?

L’authentification unique réduit les difficultés liées aux mots de passe et permet à l’équipe chargée des identités d’appliquer des politiques d’accès centralisées. Microsoft Entra ID, Okta et Keycloak sont des options à évaluer selon l’infrastructure de votre organisation et ses exigences de protocole.

Pour la connexion aux applications web, les choix habituels sont :

• OpenID Connect : souvent adapté aux plateformes d’identité modernes, avec des attributs d’identité et des jetons.
• SAML : courant dans les environnements d’entreprise disposant de configurations de fédération établies.

Choisissez un module d’authentification Drupal maintenu, compatible avec votre version de Drupal et avec le mode d’association des comptes requis. Avant de vous engager, examinez la prise en charge des mises à jour de sécurité, l’activité des versions, la déconnexion et l’export de configuration.

Une configuration type suit ces étapes :

1. Enregistrer Open Intranet comme application auprès du fournisseur d’identité.
2. Configurer les URL exactes de redirection pour OpenID Connect ou les URL du service de réception des assertions pour SAML.
3. Échanger les métadonnées, certificats ou identifiants client nécessaires.
4. Configurer la validation de l’émetteur attendu, de l’audience, des signatures et des protections propres au protocole.
5. Associer les attributs d’identité vérifiés aux comptes locaux.
6. Tester avec des utilisateurs autorisés et non autorisés.

Utilisez une clé d’identité stable pour associer les comptes lors de l’authentification. Pour OpenID Connect, la paire standard est l’émetteur et le sujet — issuer et subject — lorsque l’implémentation le permet. Une adresse e-mail peut changer ou être réattribuée : elle ne doit donc pas devenir automatiquement l’identifiant d’authentification permanent.

Cet usage est différent du rapprochement des profils pendant la synchronisation à partir d’une adresse e-mail professionnelle de confiance.

L’authentification, la création des comptes et la mise à jour des profils sont également des responsabilités distinctes. Une connexion d’entreprise réussie ne garantit pas que le service, le responsable hiérarchique ou le rôle intranet du collaborateur est à jour. Décidez si les comptes sont créés avant la première connexion, lors de celle-ci ou par un autre processus approuvé.

Les règles d’accès doivent préciser :

• Quels groupes du fournisseur d’identité peuvent accéder à l’intranet.
• Quels groupes approuvés correspondent à quels rôles Drupal locaux.
• Quelles politiques MFA le fournisseur d’identité applique.
• Combien de temps les sessions locales restent valides.
• Comment les comptes désactivés perdent leur accès intranet existant.

Ne supposez pas que désactiver un compte chez le fournisseur d’identité ferme immédiatement toutes les sessions Drupal locales. Définissez et testez l’invalidation des sessions, le blocage des comptes et toute période pendant laquelle un accès résiduel pourrait subsister.

Testez la déconnexion, les utilisateurs désactivés, les certificats expirés et les pannes du fournisseur d’identité. Si vous conservez un accès administrateur local d’urgence, limitez-le, protégez ses identifiants séparément et surveillez chaque utilisation.

Comment Open Directory peut-il tenir à jour les profils, services et rôles des collaborateurs ?

Open Directory peut mapper et actualiser les informations utilisateur dans Open Intranet à partir d’une source externe, notamment Active Directory, Keycloak ou une autre source de données utilisateur, lorsque la connexion requise est configurée.

Le bénéfice quotidien est simple : un changement de service ou de numéro de téléphone peut être répercuté dans l’intranet sans ressaisir la même information.

Si le SIRH est responsable des fiches des collaborateurs, décidez si Open Directory doit les recevoir directement ou via un annuaire approuvé qui reçoit déjà les mises à jour RH. Évitez deux flux concurrents pour un même champ.

Le processus est le suivant :

1. Connecter la source de données utilisateur de confiance.
2. Choisir comment les enregistrements source sont rapprochés des comptes intranet.
3. Mapper les champs requis et les rôles approuvés.
4. Définir les règles de remplacement, de suppression et d’exception.
5. Tester la synchronisation avec un petit groupe de collaborateurs.
6. Activer les mises à jour régulières avec les mécanismes pris en charge par l’implémentation installée.

Le tableau suivant illustre les décisions de mapping. Il ne prescrit pas les noms exacts des champs source.

Pour un rapprochement par e-mail, le processus trouve le compte intranet portant l’adresse professionnelle de confiance correspondante et met à jour ses champs de profil mappés. Les correspondances multiples doivent être signalées, pas résolues au hasard.

Lorsque c’est possible, conservez un identifiant source stable pour les rapprochements suivants afin qu’un changement d’adresse ne crée pas un second compte. Définissez le traitement d’une adresse réattribuée plus tard à un autre collaborateur.

Séparez les intitulés de poste des rôles qui accordent des autorisations. « Responsable des opérations » peut être une information de profil, tandis que « Éditeur de contenu » donne des capacités dans Drupal. Ne transformez pas un texte source quelconque en permissions et n’accordez pas de droits d’administration à partir d’une valeur de groupe non vérifiée.

Pour chaque champ mappé, documentez :

• Quel système contrôle sa valeur.
• Si les collaborateurs peuvent le modifier localement.
• Si la synchronisation remplace les modifications locales.
• Si une valeur source vide efface la destination.
• Ce qui se passe lorsqu’un service ou un responsable référencé est absent.

Par exemple, un collaborateur passe des ventes aux opérations. La prochaine synchronisation réussie met à jour son service et n’applique que les ajouts et retraits de rôles explicitement configurés. Les autres champs de profil restent inchangés.

Vérifiez les déclencheurs ou calendriers de mise à jour pris en charge par l’implémentation Open Directory installée avant de rédiger des instructions de configuration ou de promettre des mises à jour en temps réel. D’autres sources de données utilisateur peuvent nécessiter un adaptateur ou des travaux d’intégration supplémentaires.

Testez les arrivées, changements de service et d’adresse e-mail, retraits de rôles, enregistrements manquants et départs. Une réponse source en erreur ou incomplète ne doit pas déclencher une désactivation massive des comptes. Traitez les départs dans un processus explicite, distinct du rafraîchissement courant des profils.

Excluez les données de paie, les informations médicales et les autres champs sensibles inutiles. Limitez l’accès du connecteur aux enregistrements et attributs nécessaires et évitez de consigner des valeurs sensibles dans les journaux.

Comment présenter les contenus Microsoft 365 dans Open Intranet ?

Partez de ce que le collaborateur doit faire, puis choisissez la méthode de connexion à Microsoft 365.

Le SSO Microsoft 365 et l’autorisation Microsoft Graph nécessitent des configurations distinctes, même s’ils utilisent le même tenant d’identité. Se connecter à Open Intranet ne l’autorise pas automatiquement à lire les calendriers ou les documents.

Pour l’accès Graph, distinguez :

• Les autorisations déléguées : les requêtes s’exécutent dans le contexte d’un utilisateur connecté, dans les limites des scopes accordés et des droits de cet utilisateur.
• Les autorisations d’application : des tâches d’arrière-plan approuvées s’exécutent sans utilisateur connecté. Elles peuvent donner accès à davantage de données et nécessitent un contrôle plus strict.

Utilisez l’accès délégué pour les composants propres à chaque collaborateur lorsque le service le permet. N’utilisez les autorisations d’application que si un besoin d’arrière-plan le justifie, avec des restrictions de ressources lorsque c’est possible. Une réponse obtenue dans le seul contexte de l’application ne prouve pas que le visiteur actuel de l’intranet peut en voir le contenu.

La mise en œuvre comprend généralement l’enregistrement de l’application, les permissions API minimales, les consentements requis, le stockage protégé des jetons et identifiants côté serveur, ainsi qu’un processus de renouvellement des jetons. Prévoyez le traitement des consentements révoqués et des identifiants expirés comme des cas d’échec attendus.

Vérifiez la méthode d’intégration embarquée prise en charge par chaque service. Les pages SharePoint, documents Office et autres ressources Microsoft 365 ne se comportent pas tous de la même façon dans les cadres. Les paramètres du tenant, politiques de cadres, restrictions de cookies du navigateur et compte Microsoft actif du collaborateur peuvent influencer le résultat.

Les contenus personnalisés exigent aussi un cache tenant compte des autorisations. Dans Drupal, configurez les contextes, balises et durées maximales du cache afin que le calendrier ou la liste de documents d’une personne ne soit jamais servi à une autre. Si vous ne pouvez pas garantir une séparation sûre des variantes du cache, n’incluez pas cette réponse dans le contenu de page mis en cache pour plusieurs utilisateurs.

Respectez les consignes de limitation des appels API, notamment les délais de nouvelle tentative lorsqu’ils sont fournis. Chargez les composants optionnels indépendamment afin qu’une panne du calendrier ne ralentisse pas la page d’accueil. Prévoyez un lien de repli clair vers l’application source.

Validez les licences, les points de terminaison pris en charge, les consentements et les accès avec des comptes représentatifs avant de vous engager sur une fonctionnalité.

Comment connecter Google Workspace sans exposer de contenus privés ?

Google Workspace suit le même principe : montrer aux collaborateurs ce qu’ils sont autorisés à consulter sans élargir l’audience de la ressource.

Utilisez des liens Drive lorsque le but est simplement d’ouvrir un fichier. Évaluez les intégrations embarquées Docs ou Calendar prises en charge pour une consultation dans la page. Utilisez des composants reposant sur les API lorsqu’une liste filtrée ou une autre interaction contextuelle est nécessaire.

La connexion avec l’identité Google et l’autorisation OAuth pour les données Workspace sont distinctes. Un collaborateur authentifié par Google n’a pas forcément autorisé Open Intranet à lire ses fichiers Drive ou son calendrier.

Avant la mise en œuvre :

• Ne demandez que les scopes nécessaires à la fonctionnalité.
• Vérifiez les contrôles administrateur et les restrictions sur les applications externes.
• Confirmez les exigences de consentement et, le cas échéant, de vérification.
• Testez avec des ressources privées et des utilisateurs disposant de droits de partage différents.
• Vérifiez quel compte le navigateur utilise pour le contenu embarqué.

Ne rendez pas publics des documents ou calendriers privés pour faire fonctionner une intégration embarquée. Cela modifie les limites d’accès au lieu de corriger l’intégration.

Les comptes de service et la délégation à l’échelle du domaine sont des choix de conception distincts, qui impliquent des privilèges élevés. Ce ne sont pas les options par défaut pour les vues propres à un utilisateur. Si la délégation à l’échelle du domaine est nécessaire, documentez les scopes, les règles d’action au nom des utilisateurs, les administrateurs responsables et la procédure de révocation.

Lorsque les restrictions du navigateur ou le contexte du compte empêchent le chargement, affichez un lien « Ouvrir dans Google Workspace ». Un accès fiable à la source est plus utile qu’un composant vide ou un contournement dangereux des règles de partage.

Comment intégrer les tickets sans créer un second centre de support ?

Un intranet peut faciliter l’accès à l’assistance tout en laissant la gestion opérationnelle dans la plateforme de tickets.

Pour Jira Service Management, ServiceNow ou un centre de support interne compatible, privilégiez :

• Un formulaire de soumission des demandes.
• Une liste personnelle des demandes de l’utilisateur.
• Des résumés de statut et des liens vers les tickets source.

Laissez la responsabilité des workflows, les règles d’affectation, l’escalade et les objectifs de service dans la plateforme de services. Ne mappez que les champs nécessaires à l’expérience intranet, comme le type de demande, la description, le demandeur et les pièces jointes autorisées.

Utilisez des API prises en charge pour soumettre les demandes. Recevez les changements de statut par des webhooks compatibles ou interrogez le système à un intervalle convenu si aucun webhook n’est disponible.

Associez côté serveur le collaborateur connecté à la bonne identité de demandeur. Ne faites jamais confiance à un identifiant de demandeur fourni par le navigateur sans le valider. Vérifiez les autorisations avant d’afficher les détails ou pièces jointes, y compris pour les demandes dont la visibilité a changé depuis leur création.

Les nouvelles tentatives doivent être protégées contre les doublons. Créez un identifiant de soumission stable et utilisez les mécanismes d’idempotence de la plateforme lorsqu’ils existent. Sinon, concevez soigneusement la déduplication et le rapprochement côté connecteur. Si une requête dépasse le délai d’attente alors que la plateforme a pu l’accepter, vérifiez son résultat avant de la renvoyer à l’aveugle.

Affichez des états explicites :

• En attente : la demande n’a pas encore été confirmée.
• Soumise : la plateforme de services a renvoyé une référence confirmée.
• En échec : la demande n’a pas pu aboutir et nécessite une prochaine action définie.

Authentifiez les événements webhook à l’aide du mécanisme pris en charge par la plateforme, rejetez les événements rejoués lorsque c’est possible et traitez les doublons de manière sûre. Les notifications générales de l’intranet doivent signaler qu’une demande a changé, sans révéler son contenu sensible à un public plus large.

Comment préserver les droits sur les documents lors d’une intégration avec une GED ?

La gestion électronique des documents doit rester le système de référence pour les versions, la conservation et l’état d’approbation. L’intranet doit aider les collaborateurs à trouver et ouvrir les documents, pas créer discrètement des copies non gérées.

Choisissez délibérément le niveau de présentation :

Utilisez des identifiants de documents stables si la GED les prend en charge. Les chemins et noms de fichiers peuvent changer. Définissez comment le connecteur retrouve les fichiers déplacés, traite les enregistrements supprimés et réagit aux changements de partage.

L’indexation pour la recherche nécessite une conception de sécurité spécifique. Décidez :

1. Quelles métadonnées ou quels contenus entrent dans l’index.
2. Comment les règles d’accès aux documents sont représentées.
3. Comment sont déterminées les appartenances des utilisateurs aux groupes.
4. À quelle vitesse les modifications d’autorisations se propagent.
5. Ce qui se passe lorsque les informations d’accès sont périmées ou indisponibles.

Ne comptez pas sur le lien final vers le document pour assurer toute la sécurité. Un titre confidentiel ou un extrait de recherche peut révéler des informations avant même le clic.

Définissez un délai acceptable de révocation des accès. Si les règles ne peuvent pas être reproduites de manière fiable dans l’index, envisagez une autorisation au moment de la requête ou une intégration plus limitée. Refusez l’accès lorsqu’il est impossible de confirmer les droits.

Protégez les caches d’aperçu et de téléchargement aussi soigneusement que les documents originaux. Orientez les collaborateurs vers la version actuelle dans le système source, plutôt que de maintenir dans l’intranet une copie oubliée qui pourrait ignorer des modifications ultérieures ou des mesures de conservation.

Comment tester et maintenir les intégrations intranet ?

Un connecteur n’est pas terminé lorsque sa première requête réussit. Il est prêt lorsque l’équipe sait détecter un échec, en limiter l’impact et rétablir le fonctionnement sans improviser.

Séparez la logique des connecteurs des composants de présentation. Documentez les versions d’API, mappings de champs, flux d’authentification, permissions requises, dépendances de modules et emplacements des identifiants. Stockez les secrets dans un coffre approuvé, pas dans la configuration Drupal exportée ni dans le dépôt de code.

Utilisez des environnements de test et des identités de service séparés. Appliquez le principe du moindre privilège et définissez des procédures de rotation des identifiants, jetons et certificats.

Construisez une matrice de tests centrée sur les pannes et les limites d’accès :

Pour Open Directory, testez particulièrement le rapprochement par e-mail, les changements d’adresse, les services renommés, l’attribution et le retrait des rôles approuvés ainsi que l’absence de liens vers les responsables hiérarchiques. Après une panne de la source, vérifiez qu’une mise à jour réussie rétablit l’état attendu sans créer de comptes en double.

Appliquez des délais d’expiration et un nombre limité de nouvelles tentatives. Réessayez les erreurs temporaires avec des intervalles croissants, mais ne répétez pas indéfiniment les échecs d’autorisation ou de validation. Placez les éléments de file qui échouent à répétition dans un état d’erreur consultable, avec une procédure documentée de retraitement.

Les composants distants optionnels doivent se charger indépendamment et avoir leur propre comportement de repli. L’indisponibilité d’un service ne doit pas bloquer la page d’accueil de l’intranet.

Surveillez les indicateurs opérationnels sans stocker le contenu sensible des échanges :

• Échecs d’authentification.
• Temps écoulé depuis la dernière synchronisation réussie.
• Enregistrements en échec ou ignorés.
• Retard accumulé dans la file de traitement.
• Erreurs et limitations de l’API amont.
• Certificats et identifiants proches de leur expiration.

Les indicateurs utiles au lancement comprennent le taux de connexion réussie, le délai d’actualisation de l’annuaire, les soumissions confirmées et les parcours réussis d’ouverture de documents. Établissez une référence pendant le pilote et convenez des seuils d’alerte avec les équipes qui devront intervenir.

Planifiez les mises à jour de Drupal et des connecteurs en parallèle des retraits de versions d’API, renouvellements de certificats et changements de politiques du tenant. Le code sur mesure a besoin de tests de régression, tout comme les modules communautaires nécessitent un contrôle de compatibilité et de sécurité.

Avant le lancement, confirmez ces fondamentaux :

• Tests d’autorisations : ils prouvent que les utilisateurs non autorisés ne voient ni contenus protégés ni métadonnées.
• Rapprochement des données : il compare les enregistrements source et destination pour détecter les mises à jour manquées.
• Alertes : elles dirigent les erreurs vers une personne capable d’agir.
• Responsables nommés : chaque connexion a un responsable technique et un responsable métier des données.
• Instructions de rétablissement : elles expliquent comment suspendre, réessayer, retraiter ou reconstruire en toute sécurité.

Par où commencer ?

Apportez à Droptica un inventaire de votre fournisseur d’identité, de votre source de données utilisateur, de votre SIRH, de votre tenant Microsoft 365 ou Google Workspace, de votre plateforme de tickets et de votre GED.

Incluez un échantillon des champs collaborateurs, de la structure des services et des mappings de rôles qu’Open Directory doit maintenir, en utilisant si possible des données anonymisées. Ajoutez les tâches des collaborateurs que vous souhaitez faciliter ainsi que les restrictions de licences, d’hébergement ou d’accès.

Échangez avec Droptica pour valider les méthodes de connexion, les limites d’accès et l’effort de mise en œuvre d’Open Intranet. L’étape suivante consiste à déterminer ce que la configuration peut couvrir, quels modules maintenus conviennent et où un connecteur sur mesure est nécessaire.