Quel Reporting — Choix de logiciels

ERP et connexions

Synchroniser une API : comment retrouver aussi les lignes supprimées ?

Pour qui : Acheteur qui veut remplacer un export complet par des mises à jour incrémentales.

2026-11-08

Notre avis

Exiger la preuve des suppressions et des corrections avant d’accepter une extraction « nouveaux et modifiés ».

Avant de choisir une extraction incrémentale, nous demanderions comment elle retire de la BI une ligne supprimée dans la source. Une API qui liste les nouveaux enregistrements et les modifications ne démontre pas, par cette seule fonction, qu’elle signale aussi les disparitions.

Dans l’ordre

  1. Mécanisme documenté de changement
  2. Cas suppression et modification historique
  3. Réconciliation et reprise

Pourquoi

  • Une ligne supprimée peut ne plus apparaître dans la liste courante.
  • Un marqueur de date ne décrit pas nécessairement une suppression.

Ce qui change le choix

Un rechargement complet périodique peut rester la méthode la plus simple pour un petit volume et une fenêtre suffisante.

Un enregistrement peut disparaître sans nouvelle date à lire

Exemple fictif : la BI possède les identifiants A et B. La source corrige A, crée C et supprime B. Si l’extraction ne renvoie que A et C, la BI doit encore savoir que B n’existe plus ; sinon elle garde trois objets lorsque la source n’en compte que deux. Ce n’est pas le problème d’une correction historique située hors de la fenêtre d’actualisation. Même une fenêtre très large ne retrouve pas nécessairement un objet qui a disparu de la liste courante.

Exiger un mécanisme, pas le mot « synchronisation »

Microsoft Graph offre un exemple documenté : pour les ressources prises en charge, delta query décrit créations, modifications et suppressions ; les objets retirés portent un identifiant et un marqueur @removed. Ce fonctionnement ne peut pas être attribué à une API ERP ou à un connecteur qui ne le documente pas. Demandez le mécanisme exact : journal de changements, indicateur de suppression, liste exhaustive de clés à rapprocher ou rechargement complet.

La fin d’une page n’est pas la fin du cycle

Dans Graph, la documentation demande de poursuivre les nextLink jusqu’au deltaLink, et une même entité peut apparaître plusieurs fois. La méthode à réceptionner doit donc expliquer quand le cycle est considéré complet et comment une reprise évite doublons et pertes. Pour une autre API, utilisez ses propres règles de pagination et de conservation des marqueurs : ne recopiez pas les noms de paramètres de Graph comme s’ils étaient universels.

La preuve tient dans cinq états

Faites partir la recette d’un état initial connu. Appliquez une création, une correction ancienne et une suppression autorisées dans un environnement de test, puis interrompez une extraction entre deux pages. Après reprise, rapprochez clés présentes, absentes et montants. Dans le scénario fictif, l’état attendu est A corrigé + C, sans B. Pour un petit volume, un rechargement complet contrôlé peut être plus simple et plus fiable qu’un suivi incrémental mal maîtrisé. Aucune de ces opérations n’a été exécutée pour cet article.

Limites

Analyse de documents publics et méthode éditoriale. Aucun compte ou logiciel testé ; exemples explicitement fictifs. Les paramètres et engagements propres à votre environnement restent à faire confirmer.

Prochaine action

Faites documenter le signal de suppression et réceptionnez A corrigé + C, sans B, après une interruption du cycle.

Preuves et sources

Faits lus, déclarations d’éditeurs, méthodes et avis restent distincts. Notre méthode.

  • Fait lu. Pour ses ressources prises en charge, Microsoft Graph delta query décrit créations, modifications et suppressions ; les objets retirés utilisent id et @removed, et les pages doivent être suivies jusqu’au deltaLink.

    Daté du 8 novembre 2026. Portée : Microsoft Graph uniquement, capacités des API et connecteurs tiers non déduites

    Contexte : FR pour lecteur ; documentation officielle EN ou FR citée

    Réserve : Lecture documentaire du périmètre cité ; aucun compte, test produit, contrat client ou performance mesurée.

    Microsoft — Use delta query to track changes in Microsoft Graph data

    Lu le 8 novembre 2026. Documentation primaire lue.

    Portée : Use delta query to track changes in Microsoft Graph data

    Exemple Microsoft Graph seulement : pas une capacité générique des API ERP ni de tous les connecteurs Power BI.

  • Notre calcul ou déduction. Scénario fictif : état initial {A, B}, événements A modifié, C créé et B supprimé ; état attendu {A modifié, C}, sans conservation de B. Aucun appel API exécuté.

    Daté du 8 novembre 2026. Portée : Scénario fictif explicitement décrit ; calcul ou déduction éditoriale

    Contexte : FR

    Unité : Identifiants fictifs, aucun appel API effectué

    Réserve : Aucune consommation, facture ou expérience client observée ; exemple illustratif uniquement.

  • Notre méthode. Exiger la preuve des suppressions et des corrections avant d’accepter une extraction « nouveaux et modifiés ». Le protocole proposé est notre méthode de réception.

    Daté du 8 novembre 2026. Portée : Acheteur qui veut remplacer un export complet par des mises à jour incrémentales.

    Contexte : FR

    Réserve : Avis conditionnel et méthode éditoriale ; ne vaut pas test, validation juridique ou résultat garanti.