Projet Site Maison Crosnier · 21 juillet 2026
Décision : le site est un injecteur de commandes et un moyen de paiement ; la caisse est propriétaire de tout l'état métier persistant. Conséquence : les « coutures » identifiées deviennent une liste d'exigences que l'API de caisse doit satisfaire. Ce document sert de checklist à confronter aux capacités réelles de la caisse (et à transmettre à son éditeur).
Chaque exigence est marquée Requis / Optionnel / À confirmer, avec le repli si la capacité est absente. Dépendance forte : la richesse fonctionnelle du site est conditionnée par ce que l'API expose.
Session et authentification web, panier (avant qu'il devienne une commande caisse), UX de choix date/créneau, CMS / SEO / médias, enrichissement produit (photos, textes), orchestration du paiement PayPlug. « Tout à la caisse » ne peut pas inclure ces éléments intrinsèquement web.
| Capacité attendue | Niveau | Repli si absent |
|---|---|---|
| Lister les produits avec leur structure (déclinaisons, options, formules, groupes de choix) | Requis | Cache manuel minimal ; modélisation dégradée |
| Prix de référence par produit / déclinaison | Requis | — (prix indispensable) |
| Familles et rattachement produit → famille | Requis | Config côté site |
| Politique de commande / délais par famille | À confirmer | Repli en paramétrage côté site (§8 synthèse) |
| Promotions et prix promotionnels | À confirmer | Gérées côté site (position actuelle ADR-020) |
| Capacité attendue | Niveau | Repli si absent |
|---|---|---|
| Recevoir une commande payée (lignes, quantités, déclinaisons/options, créneau, point de retrait, client, référence de paiement) | Requis | Aucun — sans cela, pas de vente en ligne (cohérent ADR-019) |
| Idempotence (rejouer une injection ne duplique pas) | Requis | Contrôle applicatif côté site |
| Notifier une annulation de commande | Optionnel | Traitement manuel en boutique |
| Capacité attendue | Niveau | Repli si absent |
|---|---|---|
| Créer un avoir (à l'annulation d'une commande en ligne) | Requis* | Pas d'émission d'avoir en ligne |
| Lire le solde d'un avoir par code | Requis* | Pas d'usage d'avoir en ligne |
| Imputer / décrémenter un avoir | Requis* | — |
| Code d'avoir scannable (EAN-13 / QR / alphanumérique) pour la boutique | Requis* | — |
*Requis uniquement si l'on veut des avoirs gérés par la caisse (choix ADR-022). Si l'API ne le permet pas, deux options : (a) reporter les avoirs après enrichissement de l'API ; (b) fallback temporaire « avoir côté site » (édition auto-décrémentante, ex-ADR-021) — mais cela réintroduit la dualité qu'on cherchait à éviter.
| Capacité attendue | Niveau | Repli si absent |
|---|---|---|
| Rapprocher / créer un client (par e-mail) | À confirmer | Compte web léger géré par le site |
| Historique unifié des achats (en ligne + boutique) | À confirmer | Historique limité aux commandes injectées via le site |
| Favoris | Optionnel | Gérés côté site (convenance web) |
Pas d'API dédiée : la disponibilité est calculée par le site à partir des délais par famille (issus de A). Aucune donnée de stock n'est requise (pas de gestion de stock automatique).