---
title: "Connecter le service de politiques et configurer les notifications automatiques"
description: "Configurez la connexion au service, le consentement administrateur, les canaux et les calendriers de campagne, puis vérifiez le fonctionnement en arrière-plan avec un pilote contrôlé."
url: https://vitextra.com/fr/support/kb/10525
language: fr
published: 2026-11-08
modified: 2026-11-08
products:
  - "Policy Acknowledgement"
author: "Lidija Reising"
tags: ["service de rappel de politiques", "notifications automatiques", "consentement administrateur", "escalade", "campagnes continues"]
---

# Connecter le service de politiques et configurer les notifications automatiques

Configurez la connexion au service, le consentement administrateur, les canaux et les calendriers de campagne, puis vérifiez le fonctionnement en arrière-plan avec un pilote contrôlé.

Les mises à jour automatiques du public, rappels planifiés et escalades nécessitent le composant de service distinct de Policy Acknowledgement. Policy Admin stocke les paramètres de connexion et de notification et peut interroger le service sur le consentement. Ces contrôles ne déploient pas le service et ne prouvent pas que toutes les tâches d’arrière-plan sont opérationnelles.

## Obtenir les prérequis du service

Utilisez un compte d’administrateur du produit et obtenez le point de terminaison et les instructions de déploiement auprès de l’organisation ou du fournisseur responsable du composant. Ne considérez pas une adresse d’exemple dans un champ comme un point de terminaison de locataire provisionné. Confirmez qui gère la disponibilité du service, les autorisations d’application et les problèmes de livraison.

L’approbation des autorisations d’API SPFx et le consentement administrateur du service sont deux étapes distinctes. Terminez d’abord les exigences d’installation du produit. Si le service n’a pas été fourni ou testé, documentez l’indisponibilité du fonctionnement planifié au lieu de décrire des paramètres de campagne enregistrés comme une automatisation active.

## Connecter et vérifier le consentement

1. Ouvrez Policy Admin et sélectionnez **Notifications**.
2. Renseignez **URL du service de rappel** avec l’URL de service fournie.
3. Sélectionnez **Ouvrir la page de consentement administrateur** et effectuez le processus de consentement du locataire avec un administrateur autorisé.
4. Revenez et sélectionnez **Vérifier le consentement**.
5. Examinez le résultat et enregistrez les paramètres.

Le client ouvre la route `/consent` du service avec l’identifiant du locataire et interroge `/api/status` pour son état. Il attend une réponse positive `consentGranted` et peut enregistrer une valeur `lastRun` signalée. Ce sont des attentes d’intégration visibles dans le client, pas la documentation d’une implémentation serveur vérifiée.

![Connecter le service et examiner les paramètres de notification](https://static.vitextra.com/articles/10525/service-settings-fr.png)
*Connecter le service et examiner les paramètres de notification*

## Configurer les canaux et les calendriers

Examinez **Courrier électronique**, **Microsoft Teams (flux d'activité et bot)**, **Début de la plage sans notifications (heure)**, **Fin de la plage sans notifications (heure)** et **Adresse électronique de l’expéditeur**. Les heures utilisent une plage de 0 à 23 ; le comportement prévu des heures de silence dépend du service. Vérifiez sa gestion des fuseaux horaires au lieu de supposer que le paramètre du navigateur bloque lui-même les envois.

Pour chaque campagne, examinez la notification lors de l’attribution, les jours avant l’échéance, la notification à l’échéance, les rappels répétés de retard et les seuils d’escalade. Les composants WebPart stockent ces valeurs. Les horaires réels, la prévention des répétitions et les destinataires d’escalade doivent être vérifiés auprès du service qui les exécute.

Si une livraison Teams est nécessaire, déployez l’application requise et vérifiez le composant de livraison. Le commutateur **L'application Teams a été ajoutée au locataire** est un indicateur enregistré, pas une action d’installation ni la preuve qu’un bot existe. Consultez [KB10511. Ajouter My Policies à Microsoft Teams](https://vitextra.com/fr/support/kb/10511). Les e-mails manuels de Team Compliance sont distincts et ne suivent pas ces commutateurs de service ; consultez [KB10524. Envoyer des rappels manuels de politiques à votre équipe](https://vitextra.com/fr/support/kb/10524).

## Choisir le mode d’enregistrement des confirmations

Définissez **Qui enregistre les confirmations de lecture** indépendamment de la configuration des canaux. Lors du passage au mode Service, vérifiez que le service peut enregistrer une confirmation pilote, puis réappliquez les autorisations des rôles depuis **Rôles** avec **Enregistrer et appliquer les autorisations**. Enregistrer le mode seul ne synchronise pas les autorisations. Consultez [KB10509. Stockage des données Policy Acknowledgement : modes Direct et Service](https://vitextra.com/fr/support/kb/10509) avant de vous fier au modèle de protection.

## Distinguer les preuves de configuration des preuves opérationnelles

Le client peut montrer que les paramètres ont été enregistrés et que le point de terminaison d’état a répondu. Ces observations répondent à des questions plus étroites que « le service fonctionne ». Convenez avec le responsable des tâches déployées, des comptes ou autorisations d’application utilisés et du lieu de diagnostic d’une exécution échouée. L’interface WebPart ne fournit pas tous ces détails serveur.

| Observation | Ce qu’elle appuie | Ce qui reste à tester |
|---|---|---|
| Point de terminaison enregistré | Le client dispose d’une adresse à appeler. | Disponibilité, authentification et opération demandée. |
| Consentement signalé comme accordé | La réponse d’état signale le consentement. | Réussite de l’écriture et exécution des tâches requises. |
| Dernière exécution affichée | Le service a fourni une valeur liée à une exécution. | Quelle tâche a tourné, quelle campagne elle a traitée et son résultat. |
| Préférence de notification activée | Le canal demandé est configuré. | Livraison réelle au destinataire prévu. |
| Attribution créée | Une tâche employé existe dans le hub. | Si une notification a été envoyée et reçue. |

Conservez un petit dossier d’acceptation pour chaque fonction requise. Par exemple, un reçu employé teste le parcours de confirmation, tandis qu’un rappel planifié teste une autre opération. La réussite d’un parcours ne doit pas valider un autre sans preuve.

## Tester délibérément un changement ultérieur du public

Pour un scénario continu, terminez et vérifiez d’abord le lancement initial. Organisez ensuite un changement contrôlé d’appartenance pour un employé test admissible et demandez au responsable du service d’identifier l’exécution censée le détecter. Vérifiez version de politique, compte et échéance de l’attribution créée, et si une attribution existante de même version devait empêcher un doublon.

C’est une procédure d’acceptation de déploiement, pas l’affirmation que le client exécute un planificateur d’appartenance. Si aucune attribution n’apparaît, distinguez « la tâche n’a pas tourné », « l’utilisateur a été exclu » et « un doublon a été correctement ignoré ». Examinez les données pertinentes avant de recréer répétitivement la campagne.

Utilisez la même démarche pour les notifications : documentez canal, destinataire et calendrier attendus, puis comparez exécution du service et résultats de livraison. Les rappels manuels envoyés depuis une boîte utilisateur sont un parcours distinct et ne prouvent pas le fonctionnement de la configuration automatique.

## Effectuer les contrôles d’acceptation

Testez une petite campagne avec des destinataires connus. Vérifiez une attribution initiale, un rappel planifié, un ajout contrôlé au public si un fonctionnement continu est requis et une escalade de retard si utilisée. Notez l’heure attendue, le résultat réel et les informations d’exécution signalées par le service. Testez séparément les e-mails et Teams.

❗ **Important**  
Un contrôle de consentement réussi ne prouve pas le bon fonctionnement du planificateur, la livraison des messages ni la protection des preuves. Une valeur de dernière exécution absente ou ancienne doit également être interprétée par le responsable du service. L’implémentation serveur distincte n’était pas disponible dans le projet WebPart ; ses autorisations, sa planification et sa reprise après échec doivent donc être vérifiées dans le déploiement.

Si les contrôles échouent, conservez la configuration et les détails des erreurs et contactez le responsable du service. Ne modifiez pas à répétition le consentement, le mode d’enregistrement ou les autorisations sans identifier l’opération défaillante. Utilisez [KB10538. Dépanner les confirmations en échec et les notifications manquantes](https://vitextra.com/fr/support/kb/10538) pour distinguer les échecs d’enregistrement des échecs de notification.