Español
English
Català
Deutsch
Português
Italiano
Nederlands
Polski
« Je veux une boutique en ligne faite de zéro » veut souvent dire « je veux une boutique qui fait ce que les modèles ne font pas ». Et ce que les modèles ne font pas est presque toujours la même chose : parler avec celui qui fabrique, celui qui expédie et celui qui encaisse, sans qu'une personne recopie des données d'un écran à l'autre. Cet article explique comment nous structurons ce travail en cinq couches, ce que contient chacune et dans quel ordre on les construit. Les exemples viennent de eclipseando.com, une boutique à nous en production, et des connecteurs de transporteur que nous avons publiés pour Odoo.
Idée clé : le front-end est la couche la plus visible et la moins risquée. L'argent se perd dans les trois du milieu : une caisse que l'on peut tromper, des données qui vivent à deux endroits et un fournisseur à qui l'on passe les commandes à la main. On construit de l'intérieur vers l'extérieur.
Les cinq couches d'une boutique
| Couche | Ce qu'elle contient | Erreur typique quand on la saute |
|---|---|---|
| 1 · Données | Catalogue, prix, stock, commandes, clients. Une seule source de vérité. | Le prix sur le site et le prix dans l'ERP divergent au bout de deux mois. |
| 2 · Caisse | Panier, calcul du prix et de l'expédition, passerelle de paiement, confirmation du paiement par webhook. | On fait confiance à la page de remerciement et on prépare une commande qui n'a jamais été payée. |
| 3 · Fournisseurs | Fabricant, entrepôt, transporteur : commande sortante, étiquette, suivi, incidents. | Le suivi est recopié à la main et arrive chez le client, s'il arrive, avec un jour de retard. |
| 4 · Tâches planifiées | Files d'attente, nouvelles tentatives, lecture de boîtes mail, synchronisation du stock, rappels. | Un e-mail qui échoue une nuit est perdu pour toujours. |
| 5 · Front-end | Pages, fiches, moteur de recherche, langues, vitesse, SEO. | On commence par là, on montre quelque chose de joli, et on improvise les quatre autres ensuite. |
Couche 1 : les données vivent à un seul endroit
Avant de dessiner un écran, il faut décider où vit le catalogue. Si le client a Odoo, la réponse est Odoo : produits, prix, stock et commandes y sont et le site les lit, il ne les copie pas. S'il n'en a pas, la boutique a besoin de sa propre base de données, et mieux vaut qu'elle soit petite et ennuyeuse. Sur eclipseando.com, c'est SQLite, dans un fichier, avec sauvegarde. Ce qui ne doit pas arriver, c'est que le prix soit sur le site, dans un tableur et dans l'ERP : au bout de deux mois, ce sont trois prix différents.
Couche 2 : la caisse ne se fie pas au navigateur
Deux règles que nous ne négocions pas. La première : le prix se calcule sur le serveur, avec le catalogue en vigueur, au moment de créer la session de paiement. Le navigateur peut garder le panier, mais il ne peut pas dire combien il vaut. La seconde : une commande est payée quand la passerelle la confirme par un webhook signé, pas quand le client atterrit sur la page de remerciement. Avec Stripe, c'est checkout.session.completed avec la signature vérifiée ; avec d'autres passerelles, cela porte un autre nom et repose sur la même idée. Et si l'étape suivante échoue à la réception du webhook, on répond par une erreur pour que la passerelle réessaie, et on conserve l'identifiant de session pour ne pas fabriquer deux fois.
Couche 3 : chaque fournisseur parle comme il peut
C'est ici que « l'intégration logistique » cesse d'être un mot et devient du travail. Un fournisseur avec API et webhook (une imprimerie à la demande, un grand transporteur) s'intègre dans les deux sens : on lui crée la commande au paiement et on écoute son avis « expédié » pour transmettre le suivi au client. Un fournisseur avec une API de dropshipping s'intègre dans un sens et se consulte dans l'autre : avant d'encaisser, la disponibilité réelle par pays ; après, la commande. Et un fournisseur sans API, il y en a beaucoup, s'intègre en ramenant le travail humain à un clic : le système produit exactement l'e-mail ou le CSV dont le fournisseur a besoin, et si ses colis partent avec un transporteur qui envoie des e-mails, ces e-mails sont lus et transformés en statuts.
Deux détails que l'on n'apprend qu'avec de vraies commandes. Un : le suivi se fait par expédition, pas par commande, parce qu'une commande avec deux produits de deux fournisseurs, ce sont deux colis. Deux : les délais indiqués dans la documentation du fournisseur ne sont pas ceux qu'il tient ; on les mesure en créant des commandes de test et en lisant ce qui revient, et ce sont ceux-là que l'on montre au client avant le paiement. Quand le fournisseur est un transporteur et que la boutique tourne sous Odoo, tout cela est déjà résolu dans les connecteurs de transporteur que nous publions : étiquette, suivi, manifeste et retour dans le bon de livraison.
Couche 4 : ce qui tourne seul et ce qui se réessaie
Une boutique a du travail qui ne peut pas dépendre de la mémoire de quelqu'un : vider la file d'e-mails, réessayer les commandes payées qui ne sont pas arrivées chez le fournisseur, lire la boîte mail du transporteur, synchroniser le stock avec les marketplaces. Chacun est une tâche planifiée avec un intervalle et un journal. La règle de conception est qu'aucune n'appelle un service externe dans le chemin d'une requête de l'utilisateur : la page lit ce que la tâche a laissé en cache. Ainsi, si le fournisseur tombe à trois heures du matin, la boutique continue de servir des pages et les commandes sont réessayées à son retour.
Couche 5 : le front-end, à la fin et rapide
Une fois les quatre couches du dessous résolues, le front-end est la partie la plus gratifiante. Nous préférons des sites statiques générés au build (Astro sur eclipseando.com) servis par nginx ou Caddy : ils se chargent en un instant, n'ont pas de base de données à attaquer et coûtent ce que coûte un petit serveur. Le dynamique (panier, paiement, état de la commande) passe par une API à part. Le multilingue se fait avec une URL par langue et des textes propres, pas avec un traducteur automatique par-dessus, et se vérifie avec des tests qui contrôlent que chaque modèle existe dans toutes les langues. Et la vitesse se mesure avant de publier : poids de la page, images à la taille où elles sont affichées, rien qui bloque le premier rendu.
L'ordre compte : de l'intérieur vers l'extérieur
L'erreur la plus coûteuse que nous voyons est de commencer par la couche 5. On montre un joli site à la deuxième semaine, le client s'enthousiasme, et les couches 1 à 4 sont improvisées en dessous, dans la précipitation. Le résultat fonctionne jusqu'à la première commande avec deux fournisseurs, ou jusqu'au premier webhook perdu. Nous construisons à l'envers : d'abord les données et la caisse avec leurs tests, ensuite les intégrations avec de vraies commandes de test, ensuite les tâches planifiées, et le front-end à la fin, quand on sait exactement ce qu'il doit montrer. Cela prend le même temps. On refait beaucoup moins.
Questions fréquentes
Quand est-il pertinent de faire la boutique de zéro plutôt que d'utiliser Shopify ou Odoo Website ?
Quand la valeur est dans ce que la plateforme n'apporte pas : un calcul propre, des intégrations avec des fournisseurs sans connecteur, un catalogue qui n'en est pas un. Si votre boutique est un catalogue normal avec un transporteur normal, une plateforme est moins chère et c'est la bonne réponse. Nous le développons dans quand faire le site sur Odoo Website et quand ne pas le faire.
Que se passe-t-il avec un fournisseur sans API ?
Il s'intègre quand même, par un autre canal : le système génère l'e-mail ou le CSV exact dont il a besoin, en un clic, et lit ce que le fournisseur ou son transporteur renvoient par e-mail. Ce n'est pas aussi propre qu'une API, mais cela supprime la copie manuelle, qui est l'endroit où se commettent les erreurs.
Et si j'ai déjà Odoo ?
Alors les couches 1, 3 et 4 existent déjà en grande partie : le catalogue et les commandes vivent dans Odoo, les transporteurs entrent par des connecteurs publiés et les tâches planifiées sont des crons de l'ERP lui-même. Ce que l'on construit, c'est le front-end et, si besoin, une caisse sur mesure connectée aux ventes.
Liens utiles chez FlexigoTech
Ce que nous faisons à ce sujet
Vous avez en tête une boutique qui ne tient pas dans un modèle ?
Dites-nous ce que vous vendez, qui le fabrique et qui l'expédie. Nous vous renvoyons les cinq couches avec ce qui va dans chacune et dans quel ordre. Écrivez à comercial@flexigobe.com ou appelez le +34 616 809 504.