Comment fonctionne la synchronisation

SyncEngine

SyncEngine est le composant central de l'architecture hors ligne d'tikento. Il est responsable de :

• La sauvegarde des modifications dans la base de données locale (IndexedDB via Dexie.js)
• Le suivi des modifications en attente de synchronisation (pendingSync=true)
• L'envoi des modifications au serveur lors du rétablissement de la connexion
• La réception des mises à jour depuis le serveur (delta sync)
• La déduplication pour éviter les doublons

Cycle de vie d'une modification

1. Création de la modification

Lorsque vous effectuez une action (par exemple le check-in d'un participant), SyncEngine :

1. Enregistre la modification dans IndexedDB avec le drapeau pendingSync=true
2. Attribue un horodatage clientTs (heure actuelle de l'appareil)
3. Incrémente le compteur des modifications en attente dans l'indicateur
4. Reflète immédiatement la modification dans l'interface (mise à jour optimiste)

2. Envoi au serveur

Lorsqu'une connexion est disponible, SyncEngine :

1. Extrait tous les enregistrements avec pendingSync=true
2. Les trie par clientTs (du plus ancien au plus récent)
3. Les envoie par lot au serveur
4. Attend la confirmation du serveur

3. Confirmation

Après une réponse réussie du serveur :

1. Le drapeau pendingSync est retiré (false) pour chaque enregistrement envoyé
2. Le compteur des modifications en attente diminue
3. Si toutes les modifications ont été envoyées, l'indicateur passe au vert

4. Gestion des erreurs

En cas d'erreur d'envoi :

1. Les modifications conservent pendingSync=true
2. Une nouvelle tentative est effectuée après 30 secondes
3. Maximum 5 tentatives, après quoi l'utilisateur est notifié

Delta sync

Le delta sync permet de recevoir du serveur uniquement les données qui ont changé depuis la dernière synchronisation, au lieu de télécharger l'ensemble des données.

Comment ça fonctionne

1. SyncEngine stocke l'horodatage de la dernière synchronisation réussie dans la table meta.
2. Lors de la synchronisation, une requête est envoyée avec le paramètre since :

GET /sync/delta?since=2026-07-15T10:30:00Z&entities=registrations,payments

3. Le serveur renvoie uniquement les enregistrements modifiés après l'heure indiquée.
4. SyncEngine met à jour la base de données locale et sauvegarde le nouvel horodatage.

Paramètres de la requête

Avantages

• Économie de bande passante. Seules les modifications sont transmises, pas toutes les données
• Rapidité. La synchronisation prend des secondes, pas des minutes
• Fiabilité. Si la synchronisation est interrompue, la tentative suivante reprend au même since

Synchronisation automatique

SyncEngine surveille l'état du réseau et lance automatiquement la synchronisation dans les cas suivants :

Au rétablissement de la connexion

Lorsque l'appareil passe de hors ligne à en ligne :

1. L'événement online est détecté (Network Information API)
2. SyncEngine vérifie la disponibilité du serveur (ping)
3. Les modifications en attente sont envoyées (upload)
4. Les mises à jour du serveur sont demandées (download via delta sync)

Synchronisation périodique

En mode en ligne, SyncEngine vérifie périodiquement la présence de mises à jour sur le serveur afin que les données restent à jour (par exemple, si un autre membre de l'équipe a effectué un check-in depuis un autre appareil).

Déduplication

Pour éviter la duplication des modifications, une clé composite est utilisée :

clientTs + userId

Chaque modification est identifiée de manière unique par la combinaison de l'horodatage de création côté client et de l'identifiant de l'utilisateur. Si une même modification est envoyée à nouveau (par exemple à cause d'un timeout réseau), le serveur reconnaît le doublon par cette clé et renvoie une confirmation sans appliquer la modification une seconde fois.

Cela garantit l'idempotence -- le renvoi d'un même ensemble de modifications ne provoque ni erreurs ni doublons de données.

Ordre de synchronisation

Les modifications sont envoyées strictement dans l'ordre chronologique par clientTs. C'est essentiel pour la cohérence :

• Le check-in d'un participant à 10:05 ne peut pas être écrasé par une annulation de check-in à 10:03
• La validation manuelle de paiement à 11:00 est appliquée après le changement de statut à 10:55

Si l'horloge de l'appareil diffère de l'heure du serveur, SyncEngine compense la différence lors de la première synchronisation réussie.

Volume du stockage local

La base de données locale IndexedDB a des limites qui dépendent du navigateur et de l'appareil :

Pour un événement typique (jusqu'à 2 000 participants), le volume de données est de 5 à 20 Mo, bien en dessous des limites de tout navigateur.

Lorsque la limite de stockage approche, SyncEngine affiche un avertissement et propose de nettoyer les données des événements terminés.