L’index documentaire de votre application métier ne retrouve plus les nouveaux fichiers SharePoint. Le connecteur répond, son authentification fonctionne et les anciens liens restent visibles. Pourtant, Microsoft Graph refuse le curseur de synchronisation avec un 410 Gone. Relancer le même appel ne suffit plus : il faut reconstruire ce que le connecteur croit connaître.
La vraie question est de savoir quand le nouvel inventaire peut remplacer l’ancien. Une reprise qui efface les données locales avant de finir la pagination peut faire disparaître des documents encore présents. Une reprise qui demande seulement les changements futurs laisse les suppressions et déplacements manqués hors de son champ de vision.
Nous allons suivre un index fictif de quatre éléments, une page vide avec continuation et un document déplacé pendant la reconstruction. Un exercice SQLite reproduit les interruptions et la promotion du nouvel état. Le périmètre est volontairement précis : des métadonnées lues depuis un drive, sans écriture vers Microsoft 365 et sans suppression de fichiers réels.
Une intégration API entre vos logiciels doit garder cette frontière entre observation technique et décision métier. Pour les usages documentaires, le raccordement Microsoft Graph à votre SI doit prévoir le périmètre lu, la reprise après rupture et la conservation des dossiers métier qui référencent encore un document disparu de l’index.
Pour qui : un index de fichiers intégré à une application métier
Le cas concerne une application qui référence les documents d’un drive SharePoint ou OneDrive : portail fournisseur, suivi de dossier, recherche interne ou espace documentaire lié au CRM. Microsoft 365 fait foi pour les métadonnées observées. L’application conserve ses propres commentaires, validations et références métier dans un stockage distinct.
Qualifier le sens de synchronisation avant de reconstruire
Dans un miroir en lecture, le connecteur n’a pas à téléverser une modification locale vers le drive. Cette hypothèse simplifie la reprise, mais elle doit être vérifiée dans le produit réel. Un outil qui permet de renommer, remplacer ou modifier des fichiers hors ligne possède des conflits supplémentaires ; la procédure présentée ne les résout pas.
Le responsable métier doit identifier ce qui appartient à l’index et ce qui constitue un dossier de travail. Retirer une ligne de métadonnées obsolète ne doit pas supprimer une validation contractuelle, un commentaire ou un historique de commande. La dépendance peut rester visible comme référence indisponible, avec une décision de suivi adaptée.
Distinguer ce diagnostic des notifications Outlook
Le suivi des messages possède d’autres frontières : boîtes, dossiers de messagerie et rattachement commercial. Le dossier sur les notifications Graph et les demandes absentes du CRM traite cette chaîne. Ici, le risque central porte sur la reconstruction d’une hiérarchie documentaire et la fermeture de son inventaire.
Un signal faible apparaît lorsque le nombre total d’éléments semble stable tandis que les utilisateurs signalent des liens anciens. Quatre éléments avant et quatre après ne prouvent pas que ce sont les mêmes. Demandez une liste d’identités et de parents, puis rapprochez un document renommé, un document déplacé et une référence réellement retirée.
Lire le 410 sans le confondre avec un problème d’authentification
La référence driveItem delta prévoit un 410 Gone lorsque le service ne peut plus fournir les changements associés au jeton. La réponse peut fournir une nouvelle énumération via l’en-tête Location. Le code de resynchronisation précise ensuite la manière de rapprocher les états.
Conserver le code détaillé et la ressource concernée
Une erreur HTTP seule ne décrit pas tout le contrat de reprise. Enregistrez la ressource demandée, le code Graph et l’identifiant de requête utile au support, sans diffuser les liens de continuation ni les données documentaires dans les journaux généraux. La personne d’astreinte doit pouvoir distinguer une rupture de suivi d’une indisponibilité temporaire.
La référence des erreurs Microsoft Graph distingue notamment authentification invalide en 401, accès refusé en 403 et limitation en 429. Renouveler un jeton OAuth 2.0 peut répondre à une question d’accès ; cela ne reconstitue pas les changements qu’un ancien état delta ne permet plus de lire.
Ne pas importer une durée d’expiration depuis une autre API
Le fonctionnement général des requêtes delta varie selon les ressources. Les durées documentées pour les objets d’annuaire ou les messages Outlook ne constituent pas une garantie identique pour tous les fichiers. La reprise doit réagir au contrat et à l’erreur observés, pas à une règle universelle supposée de sept jours.
Un incident peut aussi survenir alors que le connecteur n’est pas resté longtemps arrêté. Évitez donc une alerte limitée à l’âge du dernier passage. Le monitoring suit la dernière lecture terminée, le dernier curseur reçu et les réponses de réinitialisation ; un processus actif qui tourne en boucle sur le même état reste en incident.
Choisir la reconstruction adaptée au mode de resynchronisation
Microsoft distingue resyncChangesApplyDifferences et resyncChangesUploadDifferences. Le premier demande un rapprochement avec l’état serveur sous condition de connaître les changements locaux déjà transmis. Le second prévoit des envois de différences locales et la préservation des versions incertaines. Une seule commande « vider puis recopier » ne peut pas représenter ces deux situations.
| Situation | Décision proposée | Preuve nécessaire |
|---|---|---|
| Miroir en lecture | Reconstruire une génération séparée. | Périmètre et cycle complet reçus. |
| Écritures locales | Ouvrir une conciliation dédiée. | Origine et version de chaque modification. |
| Accès refusé | Suspendre la publication de l’inventaire. | Accès requalifié, sans inventer des suppressions. |
| Cycle ouvert | Conserver la préparation en cours. | Continuation finale encore attendue. |
Notre exercice accepte uniquement le premier mode, pour un miroir sans écriture locale vers Microsoft 365. Il refuse explicitement le mode nécessitant des téléversements. Ce refus est une limite fonctionnelle du démonstrateur, pas une recommandation de supprimer ou d’ignorer les modifications d’un véritable client de synchronisation.
Le périmètre de reprise associe tenant, drive et configuration de lecture. Dans un système réel, ajoutez les propriétés demandées et les conditions d’accès pertinentes. Changer de drive ou réduire les droits pendant l’opération invalide la comparaison avec l’ancien inventaire ; la disparition d’une ligne peut alors refléter une perte de visibilité.
Exemple concret : quatre éléments avant et après, mais un autre état
L’index initial fictif contient le dossier F0, nommé « Ancien », le document A dans F0, puis B et C à la racine. A s’appelle contrat-v1.pdf, B tarifs.xlsx et C obsolete.pdf. Une note contractuelle liée à C existe dans une table métier indépendante et doit être conservée pendant toute la reprise.
Lire les trois pages sans publier la première
La première page de reconstruction annonce F1, nouveau dossier « Référentiel », une suppression de F0 et une occurrence provisoire d’A encore rattachée à F0. Elle renvoie une continuation vers la deuxième page. À ce stade, la préparation contient une relation qui ne peut pas être considérée comme la hiérarchie finale.
La deuxième page ne contient aucun élément mais indique une troisième page. Celle-ci renvoie A sous son nom final contrat-final.pdf, désormais dans F1, B renommé tarifs-2026.xlsx et le nouveau document D, notice.pdf, également dans F1. Elle termine le cycle avec un nouveau lien delta.
Comparer les identités et leurs relations, pas les compteurs seuls
La génération reçue contient F1, A, B et D : toujours quatre éléments. F0 a disparu après le déplacement d’A, C n’appartient plus à l’inventaire complet et D vient d’entrer. Un contrôle qui n’observe que le total quatre donnerait un résultat rassurant avant même d’avoir vérifié une seule de ces transitions.
La note contractuelle de C reste présente. Le mapping conserve la référence C ; l’application doit signaler son indisponibilité plutôt que rattacher silencieusement cette note au nouveau document D. Le scénario ne prétend pas retrouver le contenu du fichier ni déterminer sa durée de conservation légale. Il démontre une séparation de responsabilités : le miroir reflète les documents observés dans son périmètre, tandis que les données métier gardent leur propre cycle de vie et leurs propres autorisations.
Suivre les continuations jusqu’à la fermeture du cycle
Le parcours delta distingue @odata.nextLink, qui prolonge la lecture, de @odata.deltaLink, qui permet le cycle suivant. La documentation générale précise qu’une page vide peut encore porter une continuation. Pour notre deuxième page, le test de fin doit donc regarder le lien renvoyé, pas seulement la longueur du tableau.
Conserver les liens opaques avec leur contexte
Les paramètres du parcours sont transportés dans les liens fournis par Graph. Ne reconstruisez pas une URL en extrayant un morceau de jeton puis en ajoutant le filtre du jour. Le connecteur conserve la continuation dans un stockage protégé, liée à sa génération de lecture et au périmètre qui l’a produite.
La journalisation peut exposer un identifiant interne de génération et une empreinte de continuation pour rapprocher les événements. Elle n’a pas besoin de recopier l’URL complète dans chaque trace accessible au support. Les entrées, la configuration et la sortie doivent rester retrouvables sans transformer les logs en copie non maîtrisée des références de synchronisation.
Réessayer la lecture sans faire passer une préparation pour un résultat
Une interruption après la première page laisse l’ancien index et son ancien curseur associés. Dans le démonstrateur, la tentative suivante recommence toute la génération préparatoire. Cette solution simple rend la preuve lisible ; elle ne prétend pas être optimale pour un drive très volumineux ni imposer un redémarrage intégral après chaque coupure réseau.
Une reprise persistante au milieu des pages demande davantage de garanties : sauvegarde durable des effets de page, continuation correspondante, exclusion de deux travailleurs concurrents et gestion d’une nouvelle réinitialisation. La pagination peut avancer seulement lorsque sa préparation est enregistrée. Le choix entre reprise intermédiaire et nouveau cycle doit rester explicite dans le contrat d’exploitation.
Résoudre les éléments répétés et les dossiers supprimés en fin de parcours
Pour driveItem, Microsoft recommande de conserver la dernière occurrence d’un élément présent plusieurs fois dans le flux, et de suivre son identité plutôt que son chemin. Un renommage de dossier ne provoque pas nécessairement le renvoi de tous ses descendants. Notre clé de travail associe donc le périmètre du drive à l’identifiant de l’élément.
Ne pas laisser la première occurrence figer une relation périmée
Dans l’exercice, conserver la première occurrence d’A laisserait le document sous F0 alors que sa dernière occurrence le rattache à F1. La déduplication par « premier identifiant rencontré » serait stable et reproductible, mais incorrecte pour ce contrat. La recette doit vérifier le parent final, pas seulement l’absence de ligne en double.
Les objets du script contiennent volontairement tous les champs nécessaires au modèle local : nom, parent et nature dossier ou fichier. Une réponse réelle peut demander des lectures complémentaires pour obtenir les propriétés utiles. Ne copiez pas le remplacement simplifié d’une ligne SQLite vers un modèle documentaire riche sans qualifier les champs absents et leurs règles de conservation.
Attendre la hiérarchie complète avant de retirer un dossier
La documentation driveItem demande de ne supprimer localement un dossier qu’une fois vide après synchronisation des changements. Ici, F0 ne peut être retiré de façon cohérente qu’après le rattachement final d’A à F1. L’ordre d’arrivée ne doit pas devenir une autorisation de supprimer récursivement tous les descendants.
Le contrôle final du démonstrateur vérifie que chaque parent, hors racine conventionnelle, existe encore comme dossier. Un témoin remet volontairement A sous F0 : la promotion est alors refusée et l’ancien index reste intact. Ce garde-fou détecte une hiérarchie incohérente ; il ne remplace pas les règles de déplacement et d’accès d’un produit réel.
Promouvoir ensemble l’index reçu et son nouveau curseur
Le script reconstruction delta avec SQLite crée deux tables de métadonnées en mémoire : l’une sert de référence active, l’autre reçoit la préparation. Une transaction remplace la référence active et enregistre le nouveau curseur. Une panne simulée entre ces opérations provoque leur annulation commune.
Exécutez python3 reconstruction_delta.py avec Python 3 et sa bibliothèque standard. Les 21 contrôles couvrent les arrêts, les éléments répétés, la page vide, le changement de périmètre, le mode refusé et l’historique métier. Le rejeu complet conserve exactement la même sortie : cette idempotence locale porte sur l’index, le curseur et les notes. Aucun appel Graph, aucun stockage Microsoft 365 et aucun fichier documentaire réel ne sont modifiés.
Le contrat local exige une sortie cohérente : nouvel inventaire avec nouveau curseur, ou ancien inventaire avec ancien curseur. L’instrumentation peut ensuite annoncer quelle génération est publiée. Cette atomicité SQLite ne prouve pas une transaction distribuée avec un moteur de recherche externe, un cache ou un ERP ; ces destinations nécessitent une réception supplémentaire.
Pour un index externe, une stratégie possible consiste à construire une version séparée, vérifier sa réception puis déplacer un pointeur de lecture. Il faut alors décrire le repli et les effets déjà consommés par les autres applications. Un rollback de métadonnées ne révoque pas automatiquement une notification métier ni une extraction documentaire déjà produite.
Ne pas interpréter une visibilité réduite comme une disparition métier
Les recommandations Microsoft pour découvrir les fichiers distinguent notamment les permissions applicatives et les permissions déléguées. Dans le second cas, la visibilité dépend de l’utilisateur connecté. Reprendre sous une autre identité peut donc modifier l’inventaire sans déplacement ni suppression de document.
Le test local refuse un identifiant de périmètre différent et une erreur 403 simulée. Ce contrôle de configuration ne prouve pas, à lui seul, que les permissions du tenant sont restées identiques. En production, l’administrateur Microsoft 365 doit qualifier les droits attendus et les changements intervenus avant que l’application traite les absences comme des retraits de son miroir.
Conserver l’ancien index pour diagnostiquer ne donne pas le droit de servir des documents devenus inaccessibles. Le parcours utilisateur doit appliquer les autorisations nécessaires, afficher l’état dégradé et éviter qu’un cache de métadonnées soit pris pour une preuve d’accès actuelle. L’historique opérationnel et l’accès au contenu sont deux responsabilités distinctes.
Si des droits ou le périmètre ont changé pendant la reprise, suspendez l’interprétation des absences et ouvrez une conciliation. Les références métier restent disponibles aux personnes autorisées pour l’enquête, sans recréer automatiquement le fichier distant. Cette distinction protège à la fois la continuité des dossiers et la frontière d’accès fixée par l’organisation.
Erreurs fréquentes : retrouver un voyant vert sans reconstruire l’état
Demander seulement les changements futurs après la rupture
Le paramètre token=latest permet d’obtenir un état de suivi sans énumérer les éléments existants. Il convient à un besoin qui commence maintenant ; il ne remplit pas les trous d’un miroir ancien. Dans notre scénario, remplacer seulement le curseur laisserait F0 et C présents, D absent et A sous son ancienne relation.
Paradoxalement, le connecteur pourrait ensuite traiter correctement les nouveaux événements tout en restant faux sur le stock conservé. Le contre-test compare donc les identités et les métadonnées finales à la référence attendue. Un prochain appel réussi ne clôture pas l’incident tant que l’inventaire laissé par la rupture n’a pas été rapproché.
Multiplier les relances et confondre état courant avec historique complet
La gestion des limitations Microsoft Graph recommande de respecter Retry-After en cas de 429 et d’utiliser un délai croissant lorsque cet en-tête manque. Ajouter des travailleurs qui relisent simultanément le même drive peut accroître les appels sans rapprocher la décision de publication.
Le delta décrit un état à synchroniser, pas chaque geste utilisateur dans l’ordre où il a eu lieu. L’exercice montre deux occurrences d’A, sans prétendre reconstituer tous ses renommages intermédiaires. Un besoin d’audit des actions ou de conservation probante demande une autre source et un autre contrat ; la reconstruction du miroir ne remplit pas cette fonction.
Plan d’action : recevoir une reconstruction avant d’étendre le connecteur
Fixer la frontière documentaire et la référence attendue
Choisissez un drive pilote avec l’administrateur et le responsable métier. Écrivez si l’application lit seulement des métadonnées ou si elle modifie aussi des fichiers. Identifiez les données qui doivent survivre à une disparition du miroir : références de commande, notes, validations ou traces de support. Attribuez la responsabilité de chaque catégorie avant de décider ce qu’une absence autorise.
Préparez une petite hiérarchie avec un dossier supprimé après déplacement, un nom modifié et un élément nouveau. Gardez un résultat attendu indépendant du connecteur. Le protocole doit permettre de distinguer erreur d’identité, parent périmé et document hors périmètre. Une capture d’écran montrant le bon nombre de fichiers n’est pas assez précise pour recevoir ces transitions.
Éprouver les interruptions sans réduire la recette à un succès HTTP
Interrompez la collecte après une page puis la promotion au milieu de sa transaction. Vérifiez ensemble les données actives et le curseur conservé. Introduisez une page vide avec continuation, deux occurrences du même élément et un refus d’accès. Les entrées restent celles du test annoncé ; ne modifiez pas le résultat attendu pour valider un comportement plus facile à obtenir.
Le runbook décrit les sorties possibles : reprise de préparation, reconstruction complète, attente d’autorisation ou conciliation des modifications locales. La journalisation relie chaque décision à sa génération et à son périmètre. Mesurez la durée de reconstruction sur votre volume et le temps nécessaire pour expliquer un refus ; les trois pages fictives ne fournissent aucune capacité ou latence de production.
Décider l’ouverture depuis les preuves de cohérence et d’accès
Le pilote peut être étendu lorsque les scénarios reçus restent compréhensibles par le support. Le seuil de réussite porte sur l’absence de transition inexpliquée dans le jeu convenu, pas sur un pourcentage universel de documents synchronisés. Un seul parent invalide sur une pièce essentielle peut justifier le gel, même si le total général paraît presque complet.
- Ouvrir le parcours lorsque l’inventaire complet, son curseur et les autorisations attendues ont été reçus ensemble.
- Conserver le pilote lorsque la collecte fonctionne mais que le diagnostic des interruptions reste difficile à reproduire.
- Refuser la promotion lorsqu’un parent manque, que le périmètre a changé ou que des modifications locales restent à concilier.
Définissez enfin qui ferme l’incident : le mainteneur confirme la cohérence technique, l’administrateur qualifie les accès et le métier retrouve ses références. Cette fermeture commune évite qu’un curseur neuf soit présenté comme une reprise terminée alors que des documents ou des dossiers restent encore incompréhensibles pour les utilisateurs.
Contenus liés pour préserver les identités et les effets métier
Les usages de messagerie prolongent ces questions avec leurs propres objets. Le diagnostic sur les mails déplacés et les dossiers CRM explique pourquoi l’identité technique ne doit pas recréer une demande commerciale. Le suivi des notifications et de la reprise Outlook distingue ensuite lecture reçue et effet métier confirmé.
Pour cadrer un raccordement plus large, le panorama des échanges Microsoft Graph entre outils collaboratifs aide à qualifier les ressources et les droits. La méthode de passage d’un connecteur pilote à plusieurs clients prolonge ce travail vers les configurations et responsabilités propres à chaque installation.
Conclusion : reconstruire le miroir sans perdre la mémoire métier
La reprise n’est pas prouvée par un nouveau curseur ni par un nombre d’éléments identique. Dans l’exercice, quatre lignes correctes remplacent quatre lignes devenues anciennes, tandis que la note liée au document retiré subsiste. L’identité, le parent et la génération publiée expliquent ce que le simple compteur ne montre pas.
Une préparation séparée donne le temps de terminer la lecture et de vérifier la hiérarchie. La promotion atomique garde l’index et son état de suivi cohérents. Les accès et les effets dans les autres logiciels conservent leurs propres preuves ; le démonstrateur local ne prétend pas les certifier à leur place.
Un accompagnement d’intégration Microsoft Graph peut partir d’une rupture réelle pour qualifier le drive, les identités et les règles de reprise. Il permet de distinguer ce qui doit être relu, conservé, rapproché ou soumis à une décision métier avant de réouvrir le parcours.
Dawap conçoit des intégrations API adaptées aux logiciels et aux usages de votre entreprise. Nous pouvons cadrer le pilote, éprouver les interruptions et organiser la réception avec vos équipes afin que la synchronisation reste explicable lorsque le fonctionnement nominal ne suffit plus.
