Votre boîte ADV continue à recevoir des demandes de devis, mais certaines n’apparaissent plus dans le CRM. Le service de notification Microsoft Graph a été rétabli et les nouveaux messages reviennent. Les demandes reçues pendant l’interruption restent pourtant absentes. Le commercial découvre le problème lorsqu’un client relance, alors que le tableau de supervision affiche déjà un abonnement actif.
Un abonnement autorisé permet de recevoir des notifications ; il ne prouve pas que les changements manqués ont été rapprochés du CRM. Une lecture de rattrapage peut, elle aussi, terminer correctement sans que l’application métier ait accepté toutes les demandes. Ces trois frontières doivent rester visibles : notification, observation des messages et rattachement aux dossiers commerciaux.
En pratique, la reprise doit conserver un état de lecture par dossier Outlook et une trace durable des messages restant à traiter. Vous pourrez identifier la cause de l’arrêt, décider entre renouvellement et recréation, puis vérifier le rattrapage après une page interrompue. Paradoxalement, recréer l’abonnement peut rendre le flux rassurant tout en laissant son ancienne période de silence inexpliquée.
Notre accompagnement en intégration API examine ce parcours jusqu’à l’application qui reçoit les demandes. Le raccordement Microsoft Graph à votre logiciel métier doit permettre à l’ADV de retrouver les mails concernés, les lectures effectuées et les dossiers finalement reconnus, avec un responsable pour les situations qui restent incertaines.
Pour qui : une boîte active et des demandes absentes du CRM
Partir du message que l’équipe commerciale recherche
Le cas concerne les éditeurs de CRM, les portails de devis et les applications qui utilisent Outlook comme point d’entrée. L’équipe constate une rupture entre la réception du mail et le dossier commercial. Avant de relancer tous les traitements, choisissez un message réellement reçu, sa boîte, son dossier Outlook au moment du contrôle et la demande attendue dans le logiciel métier.
Relevez les dates de réception, de dernière lecture confirmée et de rattachement éventuel. Un message peut être présent dans la boîte sans avoir été observé par le connecteur ; il peut aussi avoir été observé sans avoir rejoint le CRM. La reprise commence à la première frontière manquante. Une recherche sur le seul sujet du mail risque de réunir une nouvelle demande et la relance d’un ancien devis.
Distinguer silence normal, permission perdue et collecte incomplète
Une boîte peu sollicitée peut rester silencieuse sans incident. À l’inverse, un webhook qui répond correctement peut ne plus recevoir de notifications parce que son abonnement a expiré. Le contrôle rapproche l’activité source et les états du connecteur. Il doit décrire ce qu’il a effectivement observé, au lieu de déduire la santé du parcours du seul dernier code HTTP reçu.
Si le problème porte uniquement sur un mail déplacé qui crée un deuxième dossier, l’enquête concerne d’abord les correspondances d’identité. Si les notifications circulent et que les lectures aboutissent, mais que le CRM refuse un champ obligatoire, la cause se situe en aval. Ces incidents peuvent coexister ; leur file de travail doit néanmoins conserver une action et une preuve différentes.
Anatomie du flux : abonnement, dossiers Outlook et demandes commerciales
Conserver le périmètre auquel chaque état appartient
Le registre d’abonnement conserve tenant, boîte, ressource surveillée, types de changements, identifiant d’abonnement et expiration observée. Le registre de lecture conserve, en plus, le dossier concerné et son état delta. Le registre commercial relie l’identité du message à un dossier CRM ou à une demande de rattachement encore en attente. Un seul champ intitulé Synchronisé ne décrit pas correctement ces trois objets.
Le périmètre de notification peut couvrir une boîte entière tandis que la lecture delta des messages s’effectue par dossier. Cette différence commande votre inventaire. Une règle Outlook qui classe rapidement les mails dans « Devis à traiter » peut rendre une collecte limitée à la boîte de réception insuffisante. Le responsable ADV indique les dossiers participant au parcours et les règles de classement à prendre en compte.
| Frontière | État à conserver | Ce qu’il permet de conclure |
|---|---|---|
| Abonnement Graph | Ressource, autorisation, expiration et dernière gestion réussie | Le canal de notification est configuré dans ce périmètre |
| Lecture d’un dossier | Continuation en cours ou dernier delta terminé | Une lecture source a progressé ou terminé son cycle |
| Traitement local | Observation durable et opération métier préparée | Le message ne dépend plus d’un simple traitement en mémoire |
| Rattachement CRM | Réponse attribuée et identifiant du dossier retrouvé | L’application commerciale a confirmé l’effet attendu |
Éviter un changement de configuration invisible pendant la reprise
Versionnez la sélection de dossiers et les propriétés effectivement lues. Une modification du filtre ou du mapping pendant l’incident peut changer la population à rapprocher. Le support doit retrouver la configuration employée avant l’arrêt et celle utilisée pour le rattrapage. Un ancien curseur ne doit pas être réaffecté silencieusement à une autre boîte ou à une autre définition de lecture.
Conservez également le format d’identifiant de message retenu. Microsoft documente les identifiants immuables pour Outlook, avec une préférence à porter dans les appels compatibles et lors de la création des abonnements. Leur portée reste celle de la boîte. La migration des anciennes correspondances constitue un travail distinct ; le rattrapage ne doit pas mélanger deux formats sans reconnaître les relations déjà stockées.
Décision : renouveler, réautoriser ou recréer l’abonnement
Traiter l’événement reçu sans inventer une opération équivalente
La documentation des événements de cycle de vie distingue reauthorizationRequired, subscriptionRemoved et missed, pris en charge pour les messages Outlook. Ils portent l’état de l’abonnement, sans décrire un mail particulier. Votre traitement identifie l’abonnement et son périmètre avant de choisir l’action correspondante.
La méthode de réautorisation répond à une demande de réautorisation. Le renouvellement de l’abonnement étend son expiration. Ces décisions ne remplacent pas le rapprochement des changements manqués. L’application conserve le résultat de la gestion du canal, puis suit séparément la reprise de la lecture source.
| Observation | Action à qualifier | Contrôle de reprise |
|---|---|---|
| Réautorisation demandée | Retrouver les droits et réautoriser selon le contrat Microsoft | Vérifier séparément expiration et lecture des changements |
| Abonnement supprimé | Recréer le canal dans le périmètre autorisé | Rapprocher la période d’interruption |
| Notifications manquées | Déclencher une synchronisation des données concernées | Retrouver les messages et les opérations CRM encore attendues |
| Canal actif, CRM incomplet | Examiner lecture source et file métier | Ne pas recréer le canal comme seule correction |
Surveiller l’échéance réellement renvoyée par Graph
La ressource subscription publie des durées maximales différentes selon le type de notification : 10 080 minutes pour les ressources Outlook concernées, avec une durée limitée à 1 440 minutes pour les abonnements incluant les données de ressource. Le planificateur utilise l’expiration obtenue et une marge de renouvellement, plutôt qu’une date copiée depuis un autre connecteur.
Les événements de cycle de vie nécessitent une URL déclarée à la création. Microsoft indique qu’on ne peut pas ajouter cette propriété à un abonnement existant par simple mise à jour. Une évolution du connecteur doit donc prévoir la recréation concernée et le suivi du rattrapage. L’ancien état de lecture est conservé ; changer de canal ne justifie pas de perdre la mémoire des demandes reconnues.
Recevoir rapidement sans déclarer le CRM déjà traité
Accuser réception après validation et mise en file durable
La documentation actuelle de livraison par webhook demande une réponse dans la fenêtre de trois secondes. Si le traitement ne peut pas terminer dans ce délai, elle recommande de valider et conserver la notification en file, puis de répondre 202 Accepted. Un accusé de réception rapide ne signifie donc pas que le devis existe déjà dans le CRM.
Le point d’entrée valide la notification selon son type, rapproche l’abonnement attendu et applique ses contrôles d’authenticité, dont le clientState lorsque le contrat le prévoit. Une notification rejetée ne déclenche pas une lecture arbitraire d’une autre boîte. Les notifications contenant des données de ressource ont des exigences supplémentaires de validation et de déchiffrement ; elles ne doivent pas être traitées comme une simple variante du payload minimal.
Regrouper les demandes de lecture du même périmètre
Plusieurs notifications peuvent demander la reprise d’un même dossier Outlook. Le middleware peut les rapprocher dans une intention de lecture, avec un traitement unique du curseur concerné. Il conserve la trace de réception nécessaire au diagnostic, mais ne crée pas une demande commerciale pour chaque signal. La lecture des données et la règle de rattachement décident ensuite quels messages portent un effet métier encore attendu.
La file expose son ancienneté et ses reprises, avec une stratégie de backoff pour les appels différés. Le monitoring distingue notification reçue, lecture demandée et message restant sans dossier CRM. Un endpoint qui répond vite tandis que la file vieillit signale une autre frontière en panne. Ajouter des accusés de réception ne réduit pas cette dette ; il faut retrouver l’exécuteur et les refus de l’application aval.
Reprendre le delta du bon dossier sans reconstruire ses liens
Distinguer une page intermédiaire d’un cycle de lecture terminé
Le suivi delta des messages s’effectue par dossier. Une réponse fournit un @odata.nextLink pour poursuivre le cycle ou un @odata.deltaLink pour reprendre lors du cycle suivant. Les liens et leurs jetons sont opaques : conservez l’URL obtenue et son contexte, sans reconstruire les paramètres à partir de votre dernière date de lecture.
Le connecteur sépare le lien durable du cycle précédent et la continuation en cours. Lorsqu’une page contient des messages et un lien suivant, il conserve ses observations avant d’avancer. Un redémarrage retrouve alors la page restant à lire, ou peut reprendre la dernière étape conservée selon sa conception. L’absence de messages sur une page ne permet pas de conclure qu’il n’existe aucune page suivante.
Ne pas remplacer le rattrapage par une recherche temporelle approximative
Une recherche des mails reçus « depuis hier » ne reproduit pas nécessairement les changements suivis. Elle peut ignorer un message plus ancien modifié ou déplacé dans le parcours. La configuration delta possède aussi ses propres limites de filtrage. Choisissez les propriétés et les types de changements nécessaires à votre application, puis vérifiez le périmètre de lecture avec un message représentatif de chaque dossier surveillé.
Dans un scénario fictif, une boîte ADV possède trois dossiers participant à la préparation des devis. La collecte de la seule boîte de réception laisse les deux autres hors contrôle, même si son cycle delta termine. Le responsable commercial doit d’abord confirmer ce périmètre. Le registre garde un curseur et une progression par dossier ; un total global de messages collectés ne masque pas celui qui n’a pas été relu.
Lier les observations au curseur, puis confirmer l’effet dans le CRM
Enregistrer les demandes locales avant d’avancer la lecture
Une stratégie possible conserve, dans la même transaction locale, les observations utiles à la création ou au rattachement et la prochaine continuation. Une table outbox représente les opérations à remettre au CRM après ce commit. Ce choix rend le résultat indépendant de la mémoire du worker. La transaction locale ne s’étend pas magiquement au CRM distant ; la confirmation aval conserve donc son propre état.
Le contrat de journalisation précise les entrées observées, la sortie métier préparée et les responsabilités de confirmation. Une page dont l’enregistrement échoue reste à reprendre depuis le curseur conservé. Une opération déjà préparée reste identifiable lors du rejeu. Le mapping protège tenant, boîte et message, avec le format d’identité qualifié ; les reprises ne recherchent pas un compte client sur le seul nom de l’expéditeur.
Garder deux clôtures au lieu d’un statut terminé ambigu
Un cycle delta terminé signifie que la lecture a atteint sa continuation finale dans le périmètre choisi. Le CRM peut encore refuser une société manquante, une règle de devis ou un champ obligatoire. La file métier conserve ces opérations et leur prochaine décision. Le responsable ADV doit pouvoir retrouver le mail observé même lorsque la demande commerciale n’est pas encore enregistrée.
Dans un second scénario fictif, le rattrapage observe six messages, dont deux sont déjà associés à un dossier et un reste refusé par le CRM. Le succès de la lecture ne justifie pas de fermer ce dernier. L’équipe doit ensuite retrouver les rattachements existants, qualifier les autres demandes et attribuer le refus restant. Cette lecture empêche de présenter six messages observés comme six devis effectivement créés.
Atelier SQLite : une page interrompue et deux rattachements en attente
Éprouver le checkpoint et la file dans leur périmètre local
Le programme de reprise SQLite utilise une base temporaire sur disque et des identités fictives déjà supposées qualifiées. Il ne contacte ni Microsoft Graph ni un CRM. Les jetons représentés par des libellés opaques servent uniquement au test du checkpoint ; ce ne sont pas des URLs Graph à employer dans une intégration.
Exécutez python3 mail_inventory.py avec Python 3.8 ou supérieur et son module SQLite standard. Huit scénarios totalisent dix-sept contrôles. Une première page conserve le message A et la continuation. Une erreur injectée pendant la page suivante annule ses ajouts et préserve le curseur précédent. Le redémarrage retrouve cet état sur disque, puis la reprise prépare B sans ajouter une deuxième demande pour A.
Page initiale : A conservé ; continuation suivante enregistrée.
Page suivante interrompue : transaction annulée ; ancien curseur intact.
Redémarrage : A et le curseur précédent retrouvés dans SQLite.
Reprise : A reconnu ; B préparé ; cycle source terminé.
File commerciale : deux demandes locales encore non confirmées.Lire les refus autant que le parcours qui réussit
Le banc refuse une ancienne page dont le jeton ne correspond plus au checkpoint, un dossier inconnu et une réponse représentant simultanément deux types de continuation. Un marqueur de resynchronisation conserve enfin les observations déjà préparées. Le seuil d’acceptation de cette démonstration est l’égalité des états avant et après les échecs injectés, ainsi que la présence des deux demandes encore en attente.
Ce programme isole le premier rattachement d’un message. Il ne traite pas ses mises à jour ultérieures, ses pièces jointes ni toutes les règles de suppression. Il ne vérifie pas non plus les droits Graph ou l’idempotence d’une création CRM réelle. La recette du connecteur doit compléter ces frontières, notamment une réponse CRM perdue après écriture et un changement de dossier survenu pendant le rattrapage.
Quand le curseur n’est plus utilisable, conserver la mémoire commerciale
Réinitialiser une lecture sans repartir avec un CRM vide
La présentation générale du delta prévoit des rejouements et des situations de réinitialisation de synchronisation, notamment une réponse 410 Gone. Pour Outlook, la durée de validité du jeton n’est pas une garantie fixe de sept jours : elle dépend du cache interne documenté. Le connecteur doit traiter la réponse effectivement reçue, sans inventer sa propre validité serveur.
Une reprise complète retrouve les messages dans son périmètre puis les rapproche des correspondances conservées. Le changement de stratégie de lecture n’autorise pas à effacer les dossiers CRM ou à recréer toutes les demandes. Une opération non confirmée garde aussi son statut. La nouvelle collecte peut apporter une observation supplémentaire ; elle ne remplace pas la preuve attendue pour fermer une création déjà engagée.
Qualifier les accès et les sorties de périmètre
La documentation Outlook sur les notifications distingue permissions déléguées et applicatives. Les abonnements visant des dossiers partagés ou délégués exigent les permissions applicatives correspondantes ; les permissions de partage comme Mail.Read.Shared ne constituent pas ce contrat d’abonnement. L’administrateur Microsoft 365 qualifie le cas réel avant une recréation du canal.
Un mail supprimé ou sorti du périmètre accessible peut ne plus fournir les données nécessaires au rattrapage. Conservez cette limite dans le dossier d’incident. L’absence de résultat n’autorise ni une fausse confirmation CRM ni une recherche sur une boîte différente. Le plan de reprise prévoit les pièces conservées, les observations encore disponibles et la décision humaine nécessaire lorsque le contenu ne peut plus être retrouvé.
Erreurs fréquentes : refermer l’alerte avant de retrouver les devis
Avancer le curseur sur une page restée en mémoire
La première erreur enregistre la continuation puis traite les messages uniquement en mémoire. Un arrêt peut perdre les demandes à préparer tout en laissant le lecteur poursuivre après elles. La deuxième partage un curseur entre plusieurs dossiers. La troisième reconstruit le lien delta avec un filtre récent qui change la population. Dans chaque cas, un statut technique peut devenir vert tandis que des mails restent absents du CRM.
Une autre erreur suppose que les notifications fournissent un historique intégral et durable. Le rattrapage doit lire les données encore disponibles, avec leur état actuel et les limites du périmètre. La conservation des références et des décisions CRM protège les effets déjà engagés ; elle ne permet pas de reconstituer automatiquement tous les contenus supprimés pendant l’interruption.
Confondre absence de doublon et absence de perte
Un connecteur peut ne créer aucun doublon parce qu’il abandonne toutes les demandes incertaines. Cela ne constitue pas une reprise correcte. Un premier signal faible apparaît quand l’activité Outlook reprend mais que l’âge des opérations CRM refusées augmente. Un second apparaît quand les curseurs progressent sans nouvelles observations durables correspondant au périmètre commercial attendu.
Le coût caché comprend la recherche du mail, la relance du client et le rapprochement du dossier par l’ADV. Mesurez ces tâches réellement observées et les demandes restées sans responsable. Les indicateurs utiles portent sur le dernier cycle source terminé, la file métier non confirmée et l’ancienneté de ses refus. Le nombre de webhooks reçus donne une information de transport, mais pas le nombre de devis effectivement pris en charge.
Plan d’action : reprendre une boîte ADV avec une preuve de clôture
Réunir l’équipe métier, l’administrateur et le mainteneur
Choisissez une boîte autorisée et une période d’incident connue. L’ADV décrit les dossiers et le résultat attendu dans le CRM. L’administrateur Microsoft 365 vérifie permissions, ressource surveillée et expiration. Le mainteneur fournit le registre d’abonnement, les continuations conservées, les observations et les réponses CRM. Dawap peut rapprocher ces éléments pour déterminer la première frontière à corriger sans lancer une collecte globale non qualifiée.
Le runbook relie journalisation, file de reprise et repli par boîte. Il distingue gestion de l’abonnement, lecture delta et confirmation commerciale. Les erreurs d’accès gardent leur responsable ; les opérations métier refusées gardent leur contenu utile au diagnostic, avec un accès adapté. La suspension d’un périmètre ne remet pas les autres curseurs à zéro et ne supprime pas les demandes déjà préparées.
Tester l’interruption à chaque frontière avant l’extension
La recette éprouve une expiration d’abonnement, une notification de perte, plusieurs dossiers, une page interrompue et une réponse CRM incertaine. L’équipe contrôle le redémarrage à partir du stockage conservé, puis recherche les demandes dans les deux sens : depuis le mail vers le dossier et depuis le dossier vers sa source. Une quantité de messages retrouvés ne remplace pas ces correspondances.
Le seuil d’arrêt du pilote est atteint dès qu’un curseur avance sans observation conservée, qu’une boîte reçoit l’état d’une autre ou qu’une création incertaine perd sa trace. Le monitoring garde ces dossiers dans une file à examiner ; le repli suspend les nouvelles opérations commerciales du périmètre affecté. L’extension aux autres boîtes suit la preuve d’une reprise que le remplaçant sait exécuter, avec ses droits et ses limites.
- À retrouver d’abord : l’abonnement, ses droits, les dossiers surveillés et leurs dernières continuations.
- À conserver : les correspondances CRM et les demandes préparées avant l’arrêt.
- À refuser : une clôture fondée sur le seul retour des notifications.
- À valider ensuite : les demandes rattachées, les refus restants et la prochaine action attribuée à chacun.
La passation présente séparément la période relue et les effets commerciaux confirmés. Une demande introuvable reste une limite explicitée, avec les recherches effectuées et son responsable. Le livrable de reprise doit permettre à l’ADV de répondre au client sans demander au développeur de reconstituer chaque fois l’historique du worker.
Lectures complémentaires : identités, recette et autorisations
Préserver le dossier commercial pendant les observations répétées
Le diagnostic Microsoft Graph : le mail déplacé recrée un dossier dans le CRM traite la continuité d’identité. Il complète le rattrapage lorsque le message retrouvé possède une référence que votre application ne rapproche plus de son ancien dossier.
La recette de webhooks en production organise les scénarios d’authenticité, de doublon et de reprise. Pour Outlook, ces contrôles se combinent avec les événements d’abonnement et les curseurs par dossier, sans attribuer au webhook la preuve d’un effet CRM déjà terminé.
Préparer une passation et un périmètre d’accès exploitables
Le runbook d’incident API aide à construire la procédure de diagnostic et de suspension. Les étapes propres à Graph doivent pointer vers l’abonnement et les lectures concernées, puis vers les demandes commerciales encore non confirmées.
Le dossier sur les scopes OAuth adaptés à l’opération nécessaire précise le cadrage des accès. Il complète la vérification Microsoft 365 lorsque l’application consulte une boîte partagée ou que plusieurs équipes se partagent la gestion du connecteur.
Conclusion : rétablir les notifications puis retrouver les demandes manquées
Le retour des notifications rétablit un canal ; il ne ferme pas la période pendant laquelle le CRM a cessé de recevoir certaines demandes. La reprise retrouve le périmètre Outlook, lit les changements disponibles et conserve les opérations commerciales encore attendues. Le dossier d’incident garde une preuve pour chacune de ces frontières.
Un curseur appartient à une lecture précise et à son dossier. Son avancement doit rester lié aux observations conservées. La file métier peut encore contenir des refus après la fin du cycle source ; ces demandes ne disparaissent pas derrière un statut de synchronisation réussi.
Les huit scénarios SQLite éprouvent localement cette conservation et ses refus, avec dix-sept contrôles et aucun appel distant. La recette réelle doit encore vérifier les autorisations, les identités et les confirmations du CRM. Les limites d’accès ou les messages devenus introuvables restent explicites au lieu de recevoir une confirmation fabriquée.
Dawap vous accompagne dans le raccordement de vos échanges API entre Microsoft 365 et votre application métier. Nous partons d’une boîte ADV et des demandes identifiées pour cadrer abonnement, rattrapage, journal et procédure de reprise, jusqu’aux dossiers que votre équipe commerciale peut effectivement retrouver.
