Créarègle
La refonte d’une boutique d’outils de traçage et de scrapbooking en architecture headless : storefront Next.js, backoffice métier sur mesure et backend Medusa, prête à remplacer WooCommerce sans perdre le référencement acquis.
- Année
- 2026 — bascule à venir
- Rôle
- Architecture, développement et infrastructure
- Périmètre
- Architecture headless · Storefront · Backoffice métier · Migration · Infrastructure
- Technologies
- Next.js · Medusa · PostgreSQL · Redis · Stripe · Docker · Playwright
Le contexte
Créarègle vend depuis Belz, en Morbihan, des règles de traçage et des outils d’encadrement et de scrapbooking conçus par Anne-Marie Gicquel. Une clientèle fidèle, un catalogue précis, et une boutique WooCommerce arrivée au bout de son modèle : lente, difficile à faire évoluer, et incapable d’exprimer les règles réelles de l’activité — livraison calculée au barème Colissimo, tarification B2B, vente continue avec des seuils de stock strictement internes.
Le choix a été de séparer les responsabilités. Un backend de commerce éprouvé pour les écritures, un storefront rendu côté serveur pour la vitesse et le référencement, et un backoffice développé sur mesure pour ce que le métier fait réellement au quotidien.
La contrainte non négociable : ne perdre ni référencement, ni commande, ni historique client pendant la bascule.
L’architecture
Le storefront est une application Next.js en rendu serveur et régénération incrémentale : boutique, compte client, tunnel de commande Stripe et métadonnées SEO. Toutes les écritures commerciales passent par les API du backend — aucune logique de prix ou de stock ne vit dans le front.
Le backoffice sur mesure regroupe ce qu’un back-office générique ne sait pas exprimer : retours, échanges et réclamations, incidents de paiement et d’emailing, journal de stock, réapprovisionnements et commandes manuelles. Il est protégé par mot de passe, limitation des tentatives et rôles distincts — un compte d’exploitation ne peut modifier ni les réglages, ni les produits, ni les utilisateurs.
Quatre automatisations opérationnelles tournent toutes les quinze minutes. Aucune ne déclenche de mutation commerciale silencieuse : elles créent des incidents traçables qu’un humain arbitre.
Ce que la refonte garantit
- Les anciennes URLs WooCommerce redirigées et vérifiées par des tests automatisés, pour préserver le référencement acquis.
- Deux migrations à blanc exigées avant la bascule réelle, avec restauration vérifiée et sauvegardes chiffrées verrouillées côté objet.
- Une accessibilité au niveau WCAG 2.2 AA couverte par des tests automatisés sur les parcours critiques, en mobile comme en bureau.
- Une mesure d’audience réellement consent-first : aucun identifiant analytics créé avant acceptation, achats enregistrés côté serveur et dédupliqués par commande.
L’infrastructure
L’ensemble tourne en conteneurs : PostgreSQL 17 derrière PgBouncer, Redis pour le cache et les files, et un reverse proxy qui termine le TLS. Base de données, cache et pool de connexions restent privés, jamais exposés.
Les sauvegardes partent vers un stockage objet chiffré, avec versioning, cycle de vie et verrouillage sur les archives critiques. La procédure de restauration est écrite et testée — c’est la seule manière de savoir qu’une sauvegarde existe vraiment.
Le déploiement en production est déclenché manuellement à partir d’une publication de version, après passage par un environnement de préproduction protégé par authentification.
Stellary
Un projet du même ordre à lancer ? Décrivez-nous le problème.
Parler de votre projet