Qu'est-ce que le Data Layer de Chift, et pourquoi votre SaaS devrait-il l'utiliser ?

Votre produit appelle une API comptable. Le système source est lent, limité en nombre de requêtes, ou tout simplement indisponible. Votre utilisateur attend. Votre intégration semble cassée.

C'est la limite du modèle traditionnel en requête directe. Plus vous montez en charge, plus il vous coûte cher. Le Data Layer de Chift a été conçu pour lever cette barrière.

L'API unifiée standard

Par défaut, chaque appel à un endpoint unifié Chift est transactionnel : Chift transmet la requête au système comptable tiers en temps réel, normalise la réponse, et vous la renvoie. Les données de votre client ne restent jamais chez Chift. Chaque lecture est un aller-retour en temps réel.

Pour la plupart des cas d'usage, c'est exactement ce que vous voulez : statut en temps réel, écritures en retour instantanées, l'état le plus frais d'un enregistrement.

Mais ce modèle a ses limites. Quand votre produit doit paginer à travers des années d'écritures comptables, extraire de grands volumes de factures réparties sur plusieurs dossiers, ou exécuter des requêtes analytiques à grande échelle, vous êtes soudain à la merci de la vitesse, de la disponibilité et des limites de requêtes de l'ERP source. Et peu importe la qualité de votre intégration, vous ne pouvez pas aller plus vite qu'un système en amont trop lent.

Qu'est-ce que le Data Layer de Chift ?

Le Data Layer de Chift est un mode de lecture alternatif pour l'API comptable unifiée. Au lieu d'interroger le système source en direct, les lectures sont servies depuis une copie des données que Chift maintient sur sa propre infrastructure et garde synchronisée avec la source en arrière-plan.

Le point essentiel : la surface de l'API reste exactement la même. Vous continuez d'appeler les mêmes endpoints Chift, avec les mêmes paramètres, et vous obtenez la même structure de réponse. Le seul changement tient à un en-tête de requête : x-chift-datalayer: true. Cet en-tête indique à Chift de servir la réponse depuis la base du Data Layer plutôt que depuis la source en direct.

Vous pouvez donc adopter le Data Layer sans réécrire une seule ligne de votre code d'intégration.

Comment fonctionne la synchronisation

Il y a deux niveaux ici, et il vaut la peine de bien les distinguer.

D'abord, Chift garde sa base du Data Layer synchronisée avec le système comptable source en arrière-plan, selon une cadence que nous configurons par connexion. Vous ne la gérez pas et vous ne la lancez pas. À la fin de chaque rafraîchissement, nous déclenchons le webhook account.datalayer.refresh_executed, pour que vous sachiez toujours à quel moment des données fraîches sont prêtes. Si tout ce dont vous avez besoin, ce sont des lectures rapides, vous vous arrêtez ici : appelez les mêmes endpoints avec x-chift-datalayer: true et c'est terminé.

Ensuite, si vous conservez votre propre copie des données, un entrepôt de reporting, une base analytique, un contexte pour l'IA, vous voudrez synchroniser cette copie depuis le Data Layer sans tout relire à chaque fois. Le Data Layer est fait pour ça, et la boucle est simple :

1. Chargement complet initial. La première fois, paginez chaque ressource sans filtre updated_after et faites un upsert de chaque enregistrement dans votre base. Cela initialise votre jeu de données.

2. Lectures incrémentales. À chaque cycle suivant, lisez chaque ressource avec updated_after réglé sur le début de votre récupération précédente. Vous ne récupérez que les enregistrements créés ou modifiés depuis, et vous en faites un upsert. Déclenchez cette étape depuis le webhook refresh_executed pour lire exactement au moment où il y a du nouveau.

3. Récupération complète périodique. Les lectures incrémentales ne peuvent pas faire remonter les suppressions : un enregistrement supprimé cesse simplement d'apparaître. Sur une cadence plus lente, une fois par semaine est une bonne valeur par défaut, faites une lecture complète sans filtre et réconciliez : tout ce qui figure dans votre base mais est absent du jeu complet a été supprimé à la source. Le webhook account.datalayer.data_deleted signale les suppressions en temps réel, et le passage hebdomadaire rattrape tout ce que vous auriez manqué.

Pourquoi utiliser le Data Layer : quatre bénéfices concrets

1. Une latence de lecture rapide et régulière

Les temps de réponse ne dépendent plus de la charge ou de la disponibilité du système comptable source. Que l'ERP soit lent, en maintenance, ou en train de limiter les requêtes, vos lectures reviennent à la même vitesse. C'est déterminant pour les tableaux de bord de reporting et les workflows pilotés par l'IA, qui ont besoin de performances prévisibles.

2. Conçu pour les gros volumes, le reporting et l'IA

Paginer à travers des années d'écritures comptables, extraire des centaines de factures en une seule session, calculer sur de longues fenêtres historiques : ces usages mettent une vraie pression sur les API en direct. Le Data Layer est fait pour eux. Filtrage intensif, plages de dates, requêtes multi-dossiers, tout est servi depuis une base optimisée pour la lecture. C'est exactement ce dont les outils de reporting, les produits d'analyse financière et les agents IA ont besoin : la densité de données et la régularité de réponse pour travailler sur de gros volumes sans surcharger la source.

3. Découplé des limites de requêtes du système source

Les systèmes comptables source peuvent imposer des limites de requêtes. Plus vous ajoutez d'utilisateurs, plus vous faites d'appels, plus vous risquez de les atteindre. Avec le Data Layer, votre trafic de lecture est découplé de la source. Seule la synchronisation touche le système source à chaque cadence, pas chaque requête utilisateur.

4. Soyez notifié dès que de nouvelles données arrivent

Vous n'avez pas à interroger le Data Layer en boucle pour savoir quand quelque chose a changé. Quatre webhooks se déclenchent autour de chaque rafraîchissement :

• account.datalayer.refresh_initiated quand un rafraîchissement démarre.
• account.datalayer.refresh_executed quand il se termine, qu'il ait réussi ou échoué.
• account.datalayer.data_changed qui vous indique quelles ressources ont changé lors de ce rafraîchissement.
• account.datalayer.data_deleted qui vous indique quels enregistrements ont été supprimés.

API en direct ou Data Layer ? Utilisez les deux.

Les deux modes ne s'excluent pas. Comme le choix se fait par requête via un en-tête, une même connexion peut servir des lectures en direct et des lectures Data Layer côte à côte.

Unified API (default)

• Source des lectures: En direct, depuis le système source
• Fraîcheur: Toujours la plus récente
• Temps de réponse: Dépend du connecteur
• Requêtes lourdes / historique: Limité par la source
• Écritures: Vont directement à la source

Data Layer (x-chift-datalayer: true)

• Source des lectures: La base du Data Layer de Chift
• Fraîcheur: À la date de la dernière synchronisation
• Temps de réponse: Rapide et régulier
• Requêtes lourdes / historique: Conçu pour ça
• Écritures: Vont toujours directement à la source, mais avec une cohérence à terme dans la base

Pensé pour ces produits

Utilisez l'API en direct pour les flux écriture-puis-lecture, où des données à jour sont cruciales, et pour les recherches d'un enregistrement unique. Utilisez le Data Layer pour l'analyse, le reporting, la pagination historique et le traitement de données piloté par l'IA.

Le Data Layer s'adresse à tout produit qui doit lire beaucoup de données financières, vite et de façon fiable. Quelques exemples :

Outils de reporting et d'analyse. Les tableaux de bord qui calculent sur des mois ou des années de données comptables ont besoin de temps de réponse prévisibles et de pouvoir paginer à travers de grands volumes sans heurter les limites de requêtes de la source. C'est le cas d'usage central pour lequel le Data Layer a été conçu.

Banques, néobanques et prêteurs. Les produits qui évaluent la santé financière d'une entreprise ont besoin d'un accès large et fiable à l'historique comptable, pour les contrôles de solvabilité, le scoring de risque, les décisions de crédit ou le suivi continu. Lire beaucoup d'historique d'un coup, à la demande, c'est précisément là qu'un système source en direct devient un goulot d'étranglement. Le Data Layer le supprime.

Outils de gestion financière et de trésorerie. Tout ce qui agrège et analyse l'ensemble du tableau financier d'un client tire parti d'une base optimisée pour les lectures lourdes, plutôt que de faire un aller-retour en direct vers la source à chaque requête.

Produits et agents pilotés par l'IA. Les agents qui raisonnent sur des données financières ont besoin d'un contexte historique dense, servi vite et de façon régulière. Le Data Layer leur apporte cette profondeur sans surcharger la source, ce qui en fait un choix naturel pour l'IA, même si c'est loin d'être son seul usage.

Si votre produit lit des données financières à grande échelle, et surtout si des systèmes source lents ou limités en requêtes vous freinent, le Data Layer est fait pour vous.

Ce qui est couvert aujourd'hui

Le Data Layer couvre actuellement l'API unifiée Comptabilité, d'autres verticales comme la banque et le POS seront bientôt disponibles. Les ressources disponibles incluent : dossiers, plan comptable, journaux, écritures comptables (avec lignes), factures (avec lignes et paiements), partenaires, codes de TVA et exercices comptables.

Démarrez avec le Data Layer de Chift

• Même surface d'API, aucune refonte de l'intégration nécessaire
• Activation par requête via un seul en-tête
• Cadence de synchronisation configurable par connexion
• Événements webhook pour réagir à chaque rafraîchissement
• Isolation multi-tenant avec sécurité au niveau des lignes
• Conçu pour le reporting, l'analyse et les agents IA

Curieux de voir comment le Data Layer peut s'intégrer à votre produit ? Lisez la documentation complète ou réservez une démo avec notre équipe.