Synchronisation de données : votre automatisation lit-elle toutes les pages ?

Une liste de produits alimente votre site, un CRM fournit les dossiers à suivre, un outil de support transmet les demandes ouvertes. L'automatisation termine sans erreur, mais certaines fiches manquent. Avant de chercher un problème dans les données, vérifiez la pagination : l'application source renvoie peut-être seulement le premier lot de résultats.

Une API est l'interface par laquelle vos logiciels échangent. Pour certaines listes, elle répartit les réponses en plusieurs pages. Votre intégration doit savoir demander la suite et reconnaître la fin. Voici les vérifications à prévoir avec votre prestataire avant de considérer une synchronisation comme complète.

1. Définir la liste que l'on veut réellement récupérer

Commencez par écrire le périmètre métier : les produits actifs, les demandes ouvertes ou les contacts modifiés depuis une date précise. Indiquez le compte utilisé et les filtres appliqués. Une fiche absente parce qu'elle est archivée ou inaccessible à ce compte n'est pas nécessairement une erreur de pagination.

Préparez un petit jeu de données fictives dont vous connaissez les identifiants attendus. Il doit dépasser la taille d'une page. Un essai qui tient entièrement dans le premier lot ne permet pas de vérifier que l'intégration sait lire le suivant.

Conservez cette liste de référence pour la recette, c’est-à-dire les tests de validation avant la mise en service. Elle permettra de distinguer une récupération incomplète d'un filtre mal réglé ou d'un problème de droits.

2. Repérer comment l'API indique la suite

Il n'existe pas un réglage universel nommé « récupérer tout ». Selon le service, la suite peut être indiquée par un numéro de page, un curseur ou une URL fournie dans la réponse. Le curseur est un repère que le service utilise pour reprendre la lecture.

Deux exemples officiels montrent pourquoi il faut lire la documentation de l'API concernée :

• GitHub fournit les liens de pagination dans l'en-tête HTTP link. Le lien portant rel="next" désigne la page suivante. Tous les liens possibles, notamment celui de la dernière page, ne sont pas toujours présents. Documentation GitHub.
• Microsoft Graph utilise notamment la propriété @odata.nextLink. Sa documentation demande de réutiliser l'URL complète pour poursuivre la lecture, plutôt que d'en extraire un morceau pour reconstruire une autre requête. Documentation Microsoft Graph.

Demandez à votre intégrateur de noter le signal utilisé pour avancer et celui qui prouve que la lecture est terminée. Une réponse reçue avec succès prouve que cette requête a abouti, pas que toute la liste a été parcourue.

3. Ne pas confondre taille d'une page et exhaustivité

Augmenter le nombre d'éléments demandé peut réduire le nombre de requêtes. Cela ne remplace pas la lecture des pages suivantes. Le service peut aussi imposer un plafond propre à l'opération utilisée.

Microsoft Graph précise qu'une page peut contenir zéro ou plusieurs résultats. Il faut donc suivre la condition de fin documentée, et non supposer qu'une page vide signifie toujours que le parcours est terminé. Règles de pagination Microsoft Graph.

Dans n8n, le nœud HTTP Request propose une option de pagination. La documentation distingue notamment le suivi d'une URL présente dans la réponse et la mise à jour d'un paramètre à chaque requête. Le choix dépend du service interrogé et de la structure de ses réponses. Pagination du nœud HTTP Request.

Si vous utilisez un connecteur prêt à l'emploi, vérifiez son comportement pour l'opération choisie. Demandez une démonstration avec plusieurs pages plutôt que de déduire sa capacité du nom du connecteur.

4. Empêcher qu'une lecture partielle remplace une liste complète

Pour une synchronisation qui remplace un catalogue ou retire les fiches absentes de la source, nous recommandons de séparer la collecte et la mise à jour finale.

Le flux rassemble d'abord les données dans une zone temporaire. Il vérifie ensuite que le parcours a atteint sa fin normale. Ce n'est qu'après les contrôles prévus que la nouvelle liste peut remplacer l'ancienne.

Si une limite de durée ou de pages est atteinte, le résultat doit rester signalé comme incomplet. Cette limite protège contre une boucle sans fin ; elle ne constitue pas une preuve de réussite. De même, une interruption ne doit pas transformer les fiches non encore lues en fiches « supprimées ».

Cette organisation est une recommandation de conception, à adapter aux possibilités de vos outils. Pour une mise à jour fiche par fiche, précisez plutôt comment sont distinguées les fiches déjà traitées de celles qui restent à lire. Notre guide sur les doublons et reprises dans n8n traite ce second problème.

5. Tester la frontière entre deux pages

Dans un environnement isolé, sans emails ni modifications de production, demandez ces essais :

• Une liste plus petite qu'une page, puis une liste qui dépasse cette frontière : tous les identifiants attendus sont présents.
• Une liste dont la taille correspond exactement à une page : la fin est reconnue selon la règle du service.
• Une page vide qui fournit encore un lien vers la suite, si ce cas existe dans l’API : le flux poursuit la lecture conformément à sa documentation.
• Une interruption au milieu du parcours : le résultat est marqué incomplet et ne déclenche pas de suppression fondée sur les absences.
• Une réponse qui répète le même repère de pagination : le flux s'arrête avec une alerte, sans annoncer une réussite.
• Une modification de la source pendant la lecture : le comportement est observé et les limites sont documentées.

Sur ce dernier point, demandez si l'API offre une vue stable des données pendant le parcours. Si cette garantie n'est pas documentée, ne la présumez pas. Choisissez avec votre prestataire une méthode de rapprochement adaptée aux changements possibles pendant la collecte.

Comparez les identifiants, pas seulement le nombre de lignes : un doublon peut masquer une fiche manquante. En cas d'écart, cherchez les éléments absents, supplémentaires ou répétés avant de relancer une écriture.

La preuve à conserver après chaque collecte

Un journal utile indique le périmètre demandé, l'heure de début et de fin, le nombre de pages lues, le nombre d’identifiants uniques récupérés et la raison de l'arrêt. Évitez d'y recopier inutilement les fiches complètes ou les données d'authentification.

Pour la recette initiale, ajoutez la comparaison avec le jeu de test et le résultat attendu en cas d'interruption. La question à poser est simple : « Qu'est-ce qui prouve que nous avons lu toute la liste prévue ? »

Cette vérification vaut aussi lorsqu'une IA exploite ensuite les données. Avant de lui demander une synthèse des dossiers ouverts, assurez-vous que la collecte lui fournit le périmètre annoncé. Une analyse bien rédigée ne permet pas de détecter à elle seule les pages qui n'ont jamais été récupérées.

Documentation officielle consultée le 22 octobre 2026. Les modes de pagination et leurs limites doivent être vérifiés pour chaque opération et chaque version utilisée.