Dans le cadre d’une mission chez l’un de nos clients, un grand groupe du luxe, ServiceNow joue un rôle central dans les opérations quotidiennes. La plateforme supporte la gestion des services IT à travers plusieurs marques, régions et entités métiers, et alimente les reportings liés à la résolution d’incidents, à la gestion des changements, aux risques opérationnels et à la performance des services.

Dans ce contexte, l’exhaustivité et la fiabilité des données sont non négociables.

Notre client s’appuyait sur des pipelines automatisés Airbyte pour ingérer les données ServiceNow vers sa plateforme analytique, avec l’hypothèse que des pipelines “en succès” garantissaient des données fiables.

Un incident de perte de données expliqué par une interaction système cachée

Malgré des pipelines stables et aucune erreur d’ingestion signalée, le nombre d’enregistrements ingérés par Airbyte était inférieur au nombre d’enregistrements visibles dans ServiceNow.

Cela créait un risque métier sérieux :

  • Reporting exécutif basé sur des données incomplètes
  • Perte de confiance dans les indicateurs de performance IT
  • Risques en matière de gouvernance et d’audit

L’aspect le plus préoccupant était le caractère silencieux du problème.
Aucune alerte, aucun échec technique apparent — simplement des données manquantes.

Cause racine : une interaction cachée entre la sécurité ServiceNow et la logique d’ingestion par défaut d’Airbyte

ServiceNow utilise des ACL (Access Control Lists) pour gérer l’accès aux enregistrements.

Dans les grandes organisations, ces ACL fonctionnent comme une sécurité au niveau des lignes : elles permettent à un utilisateur de voir certains enregistrements tout en filtrant silencieusement les autres selon ses rôles, des conditions ou la propriété des données.

Effet secondaire important :
des enregistrements peuvent exister dans le système mais être invisibles pour le compte technique utilisé via API, sans qu’aucune indication explicite de filtrage ne soit fournie dans la réponse API.

Le nombre total retourné dans les en-têtes peut être trompeur, car il peut inclure des enregistrements non accessibles à cause des ACL.

En parallèle, Airbyte utilisait une pagination standard basée sur un offset, avec l’hypothèse suivante :
Si le nombre d’enregistrements retournés est inférieur à la taille de page définie, alors il n’y a plus de données à récupérer.

Comment fonctionne habituellement la pagination

Cette hypothèse est valable pour de nombreuses API, mais pas dans les environnements où des enregistrements peuvent être dynamiquement masqués.

Ce qui se passe avec ServiceNow lorsqu’il y a des contrôles d’accès

Dans le scénario illustré, la page 3 retourne seulement 7 enregistrements alors que la taille de page est de 10, car 3 enregistrements sont masqués par les ACL.

Pourquoi ?

Lorsqu’une requête API est faite avec une limite (ex : 10 enregistrements), ServiceNow :

  1. Identifie d’abord la « fenêtre » de 10 enregistrements dans la base
  2. Applique ensuite les filtres de sécurité ACL

Si le compte technique n’a pas accès à 3 enregistrements dans cette fenêtre, ServiceNow les exclut simplement de la réponse — sans aller chercher les enregistrements suivants pour compléter la page.

Résultat :
une page « incomplète » (7 au lieu de 10), qu’Airbyte interprète comme une fin de données.

La pagination s’arrête trop tôt, alors que d’autres enregistrements visibles existent dans les pages suivantes.

Conséquence : perte silencieuse de données.

Une stratégie de pagination pour prévenir la perte de données

La solution consiste à mettre en place une pagination personnalisée, plus robuste.

Au lieu d’arrêter l’extraction dès qu’une page vide ou partielle est retournée, le pipeline :

  • Continue la pagination malgré des « trous » temporaires
  • S’arrête uniquement après plusieurs pages vides consécutives

Cela rend l’ingestion résiliente aux filtrages liés aux ACL, sans modifier les règles de sécurité ServiceNow.

Vue simplifiée de la solution

On adopte un modèle d’ingestion plus défensif et fiable, garantissant que tous les enregistrements visibles sont capturés.

Implémentation dans Airbyte

La solution nécessite :

Le changement clé :
continuer à paginer au-delà des « trous » et s’arrêter seulement après N pages vides consécutives définies par l’utilisateur, tout en incrémentant l’offset de la taille de page demandée.

Comment choisir N ?

Cela dépend :

  • De la densité des enregistrements masqués
  • Du coût des requêtes supplémentaires

Bonne pratique :

  • Définir N pour couvrir une fenêtre de « trou » raisonnable
  • Comparer les volumes entre API et interface source
  • Ajuster N jusqu’à stabilisation

Dans les tables à fort churn, commencer avec un N élevé puis l’affiner.

Objectif : éviter les arrêts prématurés sans multiplier inutilement les requêtes vides.

Ci-dessous le pseudocode implémenté :

initialize empty_pages = 0

generate next offset on each response:
visible_count = count(extracted_records)
if visible_count == 0:
empty_pages += 1
else:
empty_pages = 0
if empty_pages >= N:
stop pagination
next_offset = last_offset + page_size
continue

Arbitrages et considérations de coûts

Cette approche augmente le nombre d’appels API.

L’impact reste généralement modéré si N est correctement paramétré.

Arbitrage principal :
exhaustivité des données vs nombre de requêtes supplémentaires

Impact coût dépend du modèle tarifaire :

  • API facturée à la requête → possible hausse des coûts
  • API facturée au volume de données → impact faible

Dans le cas du client :

  • Ingestion ServiceNow → Google Cloud Storage
  • ServiceNow est généralement licencié par instance ou utilisateur
  • L’impact concerne surtout les rate limits et le temps d’exécution
  • Pas d’augmentation significative des coûts de stockage GCS

Le principal risque porte sur les limites d’API, pas sur le stockage.

Application à d’autres API critiques

Cette stratégie dépasse le cas ServiceNow.

Elle s’applique lorsque :

  • Pagination basée sur offset (offset + limit)
  • Données potentiellement masquées par ACL, politiques ou sécurité ligne
  • Pages vides/partielles ≠ fin réelle des données
  • Absence de métriques fiables côté source pour validation

Autres cas possibles :

  • Plateformes ITSM
  • API SAP avec filtrage par rôle
  • Systèmes avec soft delete
  • Suppression conditionnelle sans signal explicite

Des données fiables avec un impact métier direct

Bénéfices immédiats :

  • Jeux de données ServiceNow complets
  • Restauration de la confiance dans les KPI exécutifs
  • Réduction des risques opérationnels et de gouvernance
  • Auditabilité renforcée

Plus largement, cette mission met en lumière un problème courant :
la perte silencieuse de données peut compromettre la prise de décision avant même d’être détectée.

La pagination personnalisée renforce les pipelines sans complexité excessive.

Utilisée à bon escient, elle constitue un mécanisme ciblé et robuste qui :

  • Préserve le fonctionnement existant
  • Gère correctement les trous liés aux restrictions
  • Renforce la confiance dans les analyses en aval