Architecture

Cette page explique l'architecture technique de WCPOS pour les développeurs et les utilisateurs avancés.

Système en Deux Parties

WCPOS est conçu comme un système en deux parties :

1. Plugin PHP : Hébergé sur votre serveur, c'est un plugin relativement petit qui étend l'API REST de WooCommerce avec des points de terminaison spécifiques au POS.

2. Client JavaScript : Celui-ci fonctionne localement dans votre navigateur, dans l'application de bureau ou dans les applications iOS/Android.

Vous pouvez le considérer comme deux mondes séparés :

• Le monde PHP est celui où la gestion des données se fait à l'aide de WordPress et WooCommerce.
• Le monde JavaScript conserve une copie locale, utilisable hors connexion, des données de boutique dont vos caisses ont besoin, optimisée pour une recherche rapide et une réponse instantanée.

Synchronisation des Données

Modifié dans la v1.10.0

La v1.10.0 remplace la précédente couche de réplication par un moteur de synchronisation dédié. Le résumé ci-dessous en est la version courte — l'explication complète se trouve dans Fonctionnement du moteur de synchronisation.

Le client fonctionne en mode local-first : chaque écran lit et écrit dans la base de données locale de l'appareil, et un moteur de synchronisation en arrière-plan fait converger cette base de données et WooCommerce. Le moteur ne reproduit pas aveuglément l'intégralité de votre boutique — il part de ce dont vos écrans ont réellement besoin :

• Détection des changements : le PDV interroge un journal des changements léger au moyen de requêtes conditionnelles ; une boutique inactive répond par un unique 304 sans corps.
• Besoin déclaré : un écran déclare ce qu'il affiche, et le moteur décide si cela nécessite une requête ou si la réponse existe déjà localement.
• Amorçages et voies : un amorçage borné du catalogue, une fenêtre de commandes récentes et des voies de maintenance exécutées pendant les temps morts remplissent et vérifient les données locales selon des planifications réglables par appareil.
• Écritures durables : les ventes et les modifications sont mises en file d'attente localement puis envoyées à WooCommerce, avec une récupération visible pour tout ce que le serveur refuse.

Ce qui est synchronisé : les produits et variations, les catégories/étiquettes/marques, les clients, les taux de taxe, les coupons (Pro) et les commandes. Les passerelles de paiement sont récupérées au moment de l'encaissement.

Avantages et Inconvénients de l'Architecture

Bon 😊	Mauvais 😟
La recherche de données locales est instantanée	Maintenir les données synchronisées est un défi
Les données mises en cache sont disponibles hors ligne	Limité par l'API REST de WooCommerce
Capacité à créer de meilleures applications natives pour bureau, iOS et Android	Les thèmes et hooks WordPress ne peuvent pas personnaliser l'application POS

Base de Données Locale

Le client stocke les données dans une base de données locale sur chaque appareil — les applications web et de bureau utilisent un stockage OPFS (Origin Private File System) exécuté dans un worker, et les applications mobiles utilisent le même format sur disque via un moteur de système de fichiers. Toutes les plateformes partagent un format de stockage et des outils de récupération uniques. Cela fournit :

• Persistance : Les données survivent aux redémarrages du navigateur et de l'appareil
• Performance : Des requêtes rapides sans latence réseau — le filtrage, le tri et la pagination s'exécutent dans la couche de stockage, de sorte que seule la page de lignes visible parvient à l'interface
• Navigation hors ligne : Les données mises en cache restent accessibles sans internet

Chaque combinaison site + boutique + caissier dispose de sa propre base de données locale : les caissiers et les boutiques ne partagent jamais de données locales sur un même appareil. Les mises à jour ne migrent jamais une base de données locale sur place — l'application retélécharge depuis le serveur, qui reste toujours la copie de référence.

Architecture de Paiement

Le processus de paiement utilise un iframe/webview qui charge la page de paiement de commande WooCommerce. Cette approche :

• Tire parti des passerelles de paiement existantes : Toute passerelle de paiement WooCommerce peut fonctionner dans le POS
• Maintient la sécurité : Le traitement des paiements se fait via l'infrastructure sécurisée de WooCommerce
• Réduit la complexité : Pas besoin de réimplémenter les intégrations des passerelles de paiement

Extensions API

Le plugin PHP étend l'API REST de WooCommerce avec des points de terminaison supplémentaires pour des fonctionnalités spécifiques au POS, enregistrés sous les espaces de noms dédiés wcpos/v1 et wcpos/v2 — wcpos/v2 porte la surface de synchronisation de la v1.10.0, ce qui explique que les versions de l'application et du plugin soient livrées de pair. Consultez l'API REST de WooCommerce pour une introduction.