Une erreur de détection du hub et un message d’accès refusé ont des causes différentes. Commencez par déterminer si le composant WebPart peut localiser le hub, si le compte connecté peut lire ses données et si l’application peut résoudre le rôle requis. Recréer le hub n’est pas la première étape de diagnostic.
Consigner le symptôme
Notez l’URL de page, le composant WebPart, le compte connecté, l’URL de hub attendue et le message exact. Vérifiez si le problème touche tous les utilisateurs, un rôle ou une seule page. La réussite d’un administrateur sur une page ne prouve pas que les employés possèdent les mêmes autorisations de liste ou de source.
Si l’interface signale explicitement une licence expirée, transmettez ce problème à l’administrateur responsable de la licence du produit. Ne le considérez pas comme la preuve que les listes de politiques ont disparu. Conservez le message avant de modifier la configuration.
Vérifier la connexion au hub
- Modifiez la page concernée et examinez Site central des politiques dans les propriétés du composant WebPart.
- Comparez-la au site hub SharePoint prévu, et non à l’URL d’une politique ou d’un document individuel.
- Ouvrez directement le site prévu avec le compte concerné.
- Demandez à un administrateur de vérifier la présence de la liste de paramètres et des listes attendues du produit.
- Enregistrez toute correction de connexion et rechargez la page avant de tester à nouveau.
Le mécanisme de résolution considère le site configuré, le site actuel et l’emplacement par défaut /sites/VitextraPolicies. Il utilise la présence de la liste de paramètres pour identifier un hub et met en cache la connexion résolue. Une page peut donc pointer vers un autre hub disponible que celui attendu ; comparez les données réelles ainsi que la valeur de propriété.

Vérifier séparément la structure et les autorisations
Le contrôle de préparation de l’installation attend 11 listes et bibliothèques du produit. La présence de tous les noms attendus ne prouve pas que chaque autorisation et paramètre soit correct. Si la structure est incomplète, demandez à un administrateur d’examiner le hub existant et d’ajouter les composants manquants par le processus d’installation pris en charge ; ne supprimez pas les enregistrements existants pour relancer l’installation.
Vérifiez ensuite le rôle produit attribué au compte concerné et son accès SharePoint réel. Les composants administratifs et de rapport nécessitent le rôle approprié, tandis que les listes sous-jacentes et documents source possèdent leurs propres autorisations. Une page visible n’accorde pas d’accès à ses données ou documents.
La résolution des rôles dépend aussi des informations d’annuaire et de groupes. L’échec d’une recherche d’appartenance peut laisser l’application sans le rôle attendu même si l’administrateur pense que l’utilisateur appartient au groupe. Vérifiez les erreurs signalées par le navigateur et l’accès à l’annuaire avant de modifier les attributions de rôles à l’aveugle.
❗ Important
Appliquer la matrice d’autorisations du produit modifie les autorisations des listes du produit. Examinez les rôles prévus et préservez l’accès administrateur avant de sélectionner Enregistrer et appliquer les autorisations. Les rôles du produit et le filtrage d’interface par propriétaire ne remplacent pas l’examen des autorisations SharePoint effectives.
Réduire le périmètre de l’échec avec une matrice comparative
Comparez la même opération entre comptes et pages avant de modifier les autorisations. Cela révèle si le problème suit la personne, la connexion de page ou le hub sous-jacent. Utilisez un compte représentatif plutôt que de supposer que la réussite d’un administrateur démontre l’accès ordinaire.
| Comparaison | Zone probable à examiner ensuite |
|---|---|
| Le même utilisateur réussit sur une autre page connectée au hub prévu | Propriétés de connexion et navigation de la page défaillante. |
| L’administrateur réussit mais l’employé échoue sur la même page | Résolution des rôles, droits effectifs des listes et accès source de l’employé. |
| Le site s’ouvre mais les données de politiques ne chargent pas | Listes du produit, autorisations et hub résolu. |
| La fiche charge mais le document est refusé | Accès au document source plutôt que seule découverte du hub. |
| Plusieurs rôles échouent après une modification de configuration | Paramètres de hub, rôle ou autorisation modifiés et synchronisation partielle éventuelle. |
Ces comparaisons orientent l’investigation sans prouver une cause unique. Un échec de recherche de groupe peut ressembler à une appartenance de rôle manquante, tandis qu’une page pointant vers un autre hub valide peut montrer d’autres enregistrements sans message de hub introuvable. Préservez l’erreur exacte et le contexte réel des données résolues.
Éviter les changements larges pendant l’identification de la cause
Ne créez pas un hub de remplacement simplement parce qu’une page échoue. Établissez d’abord si les données originales sont présentes et accessibles à l’administrateur responsable. Un deuxième hub peut diviser la navigation et donner l’impression que les employés ont des tâches différentes selon les pages.
De même, n’ajoutez pas tout le monde à un groupe administratif pour tester l’accès ordinaire. Cela contourne la condition à vérifier. Corrigez le problème identifié de connexion ou d’autorisation, rechargez et répétez la même opération avec le compte initialement affecté.
Si l’application des autorisations a échoué en cours de route, examinez les listes concernées plutôt que de supposer une annulation complète de la matrice. L’opération applique les autorisations à plusieurs listes. Notez l’étape d’échec, préservez l’accès administrateur et vérifiez ensuite la configuration terminée. Utilisez KB10500. Configurer les rôles et les autorisations de Policy Acknowledgement pour un test représentatif et KB10536. Dépanner les politiques, employés et attributions manquants si l’accès fonctionne mais que les enregistrements attendus restent absents.
Vérifier la réparation
Rechargez la page concernée avec le compte concerné. Confirmez l’apparition des politiques attendues et la réussite d’une action autorisée. Testez séparément le document source. Si une seule page échoue, comparez ses propriétés de hub et de page du lecteur à celles d’une page fonctionnelle plutôt que de modifier les accès à l’échelle du locataire.
Pour une escalade, fournissez les URL du hub et de la page, le compte, le rôle, le message, l’heure et le résultat de l’accès direct au site. Incluez les détails d’erreur pertinents sans jetons d’authentification ni enregistrements sensibles d’employés. Consultez KB10496. Policy Acknowledgement : guide de démarrage rapide pour le modèle de stockage et de connexion et KB10500. Configurer les rôles et les autorisations de Policy Acknowledgement pour les rôles et autorisations.