Sync PDV legacy sans arrêter l’exploitation
Dans cet article
Une brasserie devait afficher le classement de consommation sur la TV du bar. Les données venaient du PDV — l’ancien système du local. L’équipement était une TV Box Android 24/7 ; l’internet coupait ; le PDV redémarrait chaque jour. Tout arrêter pour migrer était risqué : le bar ne pouvait pas fermer.
Ce post décrit ce que j’ai fait sur Batalha dos Barris : au lieu de remplacer le système d’un coup, j’ai changé les parties petit à petit, avec un agent de synchronisation séparé.
Contexte
- Origine des données : MySQL du PDV (système legacy ; nous ne contrôlons pas le deploy).
- Destination : PostgreSQL + API Flask + player Angular (PWA) sur la TV Box.
- Attente métier : classement mis à jour régulièrement, sans qu’on touche au code sur la TV.
Si la sync s’arrête, le classement se fige — et les clients du bar le voient.
Architecture
textMySQL PDV → Agent Python (SSH) → PostgreSQL → API Flask → App Angular sur TV Box
- Le player sur la TV n’accède pas directement au MySQL legacy.
- L’agent gère SSH, les redémarrages du PDV et le point où la sync s’est arrêtée.
- L’API utilise un cache pour ne pas saturer le player de requêtes.
Nous avons choisi une sync par intervalles plutôt qu’une connexion en direct (websocket). Sur une TV Box avec internet instable, c’est plus simple et plus fiable.
Problèmes rencontrés
Internet coupe sur l’agent : la sync doit reprendre au dernier ID ou horodatage confirmé — sans tout retraiter ni sauter des ventes.
PDV redémarre : l’agent reconnecte et valide le point de reprise ; le player affiche le dernier snapshot en cache.
Délai sur les données : aujourd’hui on le voit dans les logs ; si je recommençais, j’ajouterais des alertes quand le délai dépasse un seuil acceptable.
Leçons pour d’autres projets
- Reprendre où on s’est arrêté doit être un besoin dès le départ.
- Sync incrémentale avec un intervalle qui tolère les courts échecs réseau.
- Isoler les pannes : legacy, agent, API et player ne doivent pas tout faire tomber.
- Prochaine étape : mesurer le délai et les échecs par étape.
Lecture associée
Commentaires
Connectez-vous avec votre compte GitHub pour commenter. Les commentaires sont publics et stockés comme Discussions sur le dépôt de commentaires du blog.