Aller au contenu principal

Synchronization Engine

Version : 1.0

Statut : Architecture cible

Décision : MOBILE-007

1. Objectif​

Le Synchronization Engine est responsable de maintenir une cohérence permanente entre le téléphone et la plateforme DMV.

Il constitue le lien entre :

  • le Cache Engine ;
  • les applications React ;
  • l'API Laravel.

Contrairement au Cache Engine, il ne conserve aucune donnée.

Son rôle est uniquement d'orchestrer les échanges entre le téléphone et le serveur.

État actuel​

Le code actuel ne présente pas encore un Synchronization Engine mobile centralisé. La synchronisation existe plutôt sous forme de comportements distribués :

  • appels API ou Supabase depuis les applications web ;
  • rafraîchissement des données par les couches front ;
  • invalidation ou relecture ponctuelle après certaines actions ;
  • cache serveur ou front selon les modules.

Cette situation est cohérente avec l'état actuel du projet, mais elle n'est pas encore la cible mobile.

Architecture cible​

Le Synchronization Engine orchestre les échanges entre le téléphone, le Cache Engine et l'API Laravel. Il ne décide pas du métier et ne conserve pas la vérité.

Il garantit l'ordre, la reprise, l'idempotence, l'absence de perte de brouillon et la convergence vers l'état serveur.

Migration​

La convergence consiste à :

  1. identifier les actions mobiles qui doivent être rejouables ;
  2. attribuer un identifiant stable aux brouillons et opérations locales ;
  3. rendre les endpoints Laravel compatibles avec les rejouements idempotents ;
  4. centraliser la file de synchronisation mobile ;
  5. connecter cette file au Cache Engine et aux événements réseau Capacitor.

2. Philosophie​

Le Synchronization Engine ne décide jamais.

Il applique.

Toutes les décisions métier restent prises par le serveur.

Le moteur garantit uniquement que :

  • les bonnes données sont envoyées ;
  • dans le bon ordre ;
  • au bon moment ;
  • sans perte.

3. Principes fondamentaux​

Le moteur repose sur six principes.

Le serveur reste prioritaire​

Le téléphone ne peut jamais imposer une vérité au serveur.

Toutes les validations sont réalisées côté Laravel.

Les synchronisations sont silencieuses​

L'utilisateur ne doit jamais avoir à lancer une synchronisation.

Elle est automatique.

Une seule synchronisation à la fois​

Les synchronisations sont séquentielles.

Deux synchronisations concurrentes sont interdites.

Reprise automatique​

Une coupure réseau ne doit jamais faire perdre un travail.

Le moteur reprend automatiquement lorsqu'une connexion revient.

Idempotence​

Une synchronisation peut être rejouée plusieurs fois.

Elle ne doit jamais créer :

  • deux publications ;
  • deux favoris ;
  • deux événements.

Chaque opération doit être idempotente.

Principe technique cible :

Client
  ↓
Draft UUID stable
  ↓
API Laravel
  ↓
UPSERT métier
  ↓
Contrainte UNIQUE
  ↓
Réponse unique et rejouable

Le client peut donc renvoyer la même opération après une coupure réseau. Laravel reconnaît l'identifiant fonctionnel, applique une création ou mise à jour contrôlée, puis retourne l'état serveur sans dupliquer la ressource.

Pas de conflit complexe​

L'architecture DMV préfère empêcher les conflits.

Plutôt que les résoudre.

4. Déclencheurs​

Une synchronisation peut être déclenchée par :

  • retour du réseau ;
  • ouverture de l'application ;
  • reprise après veille ;
  • reconnexion utilisateur ;
  • action utilisateur.

5. Types de synchronisation​

Toutes les données n'ont pas la même priorité.

Synchronisation critique​

Exemples :

  • authentification
  • session
  • permissions
  • sécurité

Toujours exécutée immédiatement.

Synchronisation utilisateur​

Exemples :

  • favoris
  • préférences
  • paramètres

Synchronisation contextuelle​

Exemples :

  • commune active
  • Mur
  • agenda
  • notifications

Synchronisation des brouillons​

Les brouillons possèdent leur propre file d'attente.

Ils ne sont jamais mélangés aux autres données.

6. File d'attente​

Toutes les opérations sont placées dans une queue.

Exemple :

Création brouillon

↓

Ajout file

↓

Connexion disponible

↓

Envoi API

↓

Validation Laravel

↓

Confirmation

↓

Suppression de la queue

Aucune opération n'est perdue.

7. Ordre des synchronisations​

L'ordre suivant est imposé.

1. Session

↓

2. Permissions

↓

3. Préférences

↓

4. Brouillons

↓

5. Contexte

↓

6. Cache secondaire

Cet ordre garantit une plateforme toujours cohérente.

8. Brouillons​

Les brouillons constituent le seul contenu métier pouvant être créé hors connexion.

Exemple :

Nouvelle publication

↓

Création locale

↓

Synchronisation

↓

Création brouillon serveur

↓

Publication manuelle

Aucune publication automatique.

9. Reprise après coupure​

Exemple :

Utilisateur

↓

Rédige une publication

↓

Perte réseau

↓

Brouillon local

↓

Retour réseau

↓

Synchronisation automatique

↓

Le brouillon apparaît dans le Workspace

10. Détection réseau​

Le moteur écoute en permanence :

  • perte réseau ;
  • retour réseau ;
  • changement Wi-Fi / 4G / 5G.

Une simple variation de qualité réseau ne déclenche pas une synchronisation.

11. Gestion des erreurs​

Une erreur n'interrompt jamais définitivement le moteur.

Exemple :

Erreur serveur

↓

Nouvelle tentative

↓

Succès

Les tentatives suivent une stratégie de backoff progressif.

12. Politique de Retry​

Exemple :

Tentative 1

↓

5 secondes

↓

Tentative 2

↓

30 secondes

↓

Tentative 3

↓

2 minutes

↓

Tentative 4

↓

10 minutes

↓

Puis reprise normale lors du retour réseau.

13. Déconnexion​

Lors d'une déconnexion :

Le moteur :

  • termine les opérations critiques ;
  • annule les synchronisations secondaires ;
  • vide les files temporaires ;
  • supprime les données utilisateur du cache.

14. Notifications Push​

Les notifications peuvent provoquer une synchronisation partielle.

Exemple :

Nouvelle publication

↓

Notification

↓

Téléchargement de la publication uniquement

Pas du Mur complet.

15. Économie de batterie​

Le moteur évite :

  • les réveils inutiles ;
  • les synchronisations permanentes ;
  • les téléchargements redondants.

Il privilégie des synchronisations regroupées.

16. Sécurité​

Toutes les communications utilisent :

HTTPS

JWT Supabase validé par Laravel

Token Sanctum pour les routes métier

API sécurisée

Aucune donnée sensible n'est synchronisée en clair.

17. Cas particuliers​

Modification impossible hors connexion​

Modification d'un acteur

↓

Connexion absente

↓

Action refusée

↓

Message utilisateur

Brouillon existant​

Le téléphone détecte qu'un brouillon existe déjà.

↓

Il met à jour le brouillon.

Jamais création d'un second brouillon.

18. ADR​

Alternatives étudiées​

Synchronisation permanente​

Rejetée.

Consommation excessive.

Synchronisation manuelle​

Rejetée.

Mauvaise UX.

Synchronisation automatique intelligente​

Retenue.

Simple.

Robuste.

Compatible avec Online First.

19. Décisions figées​

✅ Synchronisation automatique.

✅ Une seule synchronisation à la fois.

✅ Reprise automatique.

✅ Brouillons synchronisés.

✅ Publication uniquement en ligne.

✅ File d'attente centralisée.

✅ Serveur prioritaire.

✅ Opérations idempotentes.

20. Conclusion​

Le Synchronization Engine garantit que le téléphone reste synchronisé avec la plateforme DMV sans intervention de l'utilisateur.

Son objectif n'est pas de rendre le téléphone autonome.

Son objectif est de fournir une expérience fluide, fiable et robuste tout en conservant le serveur comme unique source de vérité.