Cas client : eclipseando.com, un site web et un backend e-commerce créés de zéro en 19 jours

Le 12 août 2026, une éclipse totale de soleil a traversé l'Espagne. Le 24 juillet, eclipseando.com n'existait pas : ni domaine, ni design, pas une ligne de code. Dix-neuf jours plus tard, le site était en ligne avec une page pour chaque commune d'Espagne, une boutique qui encaissait avec Stripe et une chaîne logistique qui passait commande auprès de quatre prestataires différents. Nous le racontons ici parce que c'est le projet qui montre le mieux comment nous travaillons quand la demande est « un site web et un backend de zéro », et parce que chaque élément est en production et peut être visité.

La commande : un site web avec une date limite

Le projet était le nôtre, pas celui d'un client, ce qui en fait un exemple plus honnête : pas de budget à étirer, pas de délai négociable. C'est le ciel qui fixait la date. Les exigences venaient d'une recherche préalable et étaient concrètes : répondre à « à quelle heure et dans quelle mesure verrai-je l'éclipse depuis mon village ? » pour n'importe quelle commune d'Espagne, vendre des lunettes certifiées et des souvenirs personnalisés par commune, et le faire aussi en catalan, anglais, allemand, français, italien et portugais, car une partie du public venait de l'étranger.

Nous avons écarté Shopify et WooCommerce avant de commencer. Pas pour une question de prix, mais parce que la difficulté du projet n'était pas la boutique : c'était les 8 132 pages calculées, la carte, la prévision des nuages et des intégrations logistiques qu'aucune plateforme ne propose en standard. Quand la valeur se trouve dans ce qui n'est pas fourni en standard, la plateforme gêne plus qu'elle n'aide. Nous appliquons le même critère quand un client nous demande s'il doit faire son site sur Odoo Website ou à part.

Ce qui a été construit, pièce par pièce

Le frontal : 8 132 pages calculées, pas écrites

Chaque commune d'Espagne a sa page avec l'heure de début, le maximum, la fin, le pourcentage d'occultation et, dans la bande de totalité, les secondes d'obscurité. Personne n'a écrit ces données : elles sont calculées au moment de générer le site à partir des éléments de l'éclipse et des coordonnées de chaque commune, et un test compare un échantillon de résultats à ceux que publie l'Institut géographique national. Si le calcul dévie, le site n'est pas publié. Outre l'Espagne, il existe des index pour le Portugal, la France, l'Italie, l'Allemagne, l'Irlande, l'Islande, le Groenland, le Maroc, les Pays-Bas et le Royaume-Uni.

Le multilingue est réel, pas une traduction automatique plaquée par-dessus : chaque langue a sa propre route (/ca/, /en/, /de/…), ses propres textes et ses propres pages de boutique, et des tests vérifient que les sept versions de chaque modèle existent et sont liées entre elles. C'est la même règle que nous appliquons sur flexigotech.com et sur pernocta.eu.

Le backend : une petite API qui fait office de caisse, d'entrepôt et de comptoir

Tout le statique est servi par nginx. Le dynamique dépend de /api/* et c'est une application FastAPI avec l'état dans SQLite. Cela paraît modeste, et c'est voulu : une seule personne la maintient, elle tourne sur un serveur à quelques euros et a encaissé le pic du jour de l'éclipse sans rien changer. Les décisions qui comptent sont à l'intérieur :

• Le panier est valorisé côté serveur. Le navigateur conserve les lignes, mais chaque prix est recalculé par rapport au catalogue en vigueur lors de la création de la session de paiement. Sinon, n'importe qui ouvre la console et s'achète un sweat pour un euro.
• Le webhook de Stripe fait foi. Un paiement est considéré comme encaissé quand Stripe le confirme avec une signature vérifiée, pas quand le navigateur revient sur la page de remerciement. Si la commande au fournisseur échoue lors de l'encaissement, l'API renvoie une erreur pour que Stripe réessaie, et une table avec l'identifiant de session évite de fabriquer deux fois.
• Le produit numérique est remis via un lien signé (HMAC, expire au bout de 72 heures, cinq téléchargements au maximum) et la case de renonciation au droit de rétractation est exigée avant l'encaissement : l'API rejette le checkout du kit si elle n'est pas cochée.
• Les e-mails ne se perdent pas. Chaque confirmation part par Brevo ; si Brevo ne répond pas, elle reste dans une file d'attente SQLite qu'un minuteur vide toutes les quinze minutes. Un acheteur sans e-mail de confirmation, c'est une réclamation : cette règle n'admet aucune exception.

Les interfaces logistiques : quatre prestataires, quatre façons de communiquer

C'est la partie qui ressemble le plus à ce que nous demandent les clients. La boutique vendait des produits expédiés depuis des endroits différents, et chacun communiquait à sa manière :

• Une imprimerie avec API et webhook. À l'encaissement, l'API génère le fichier d'impression (un modèle SVG avec le nom de la commune, l'heure et la durée, rastérisé à 300 ppp), crée la commande et attend le webhook « expédié » pour envoyer à l'acheteur son suivi.
• Une seconde imprimerie avec une usine à Barcelone pour les vêtements, car la première ne fabriquait pas de vêtements en Espagne et le délai ne suivait pas. Nous avons mesuré les deux API avec de vraies commandes avant de décider ; la tasse est restée chez la première car celle-ci était bien fabriquée ici.
• Un fabricant de lunettes avec API de dropshipping qui expédie vers l'Espagne, la France, l'Allemagne, le Royaume-Uni et le Portugal. La commande est créée automatiquement à l'encaissement, et avant d'encaisser, on consulte sa disponibilité réelle par pays.
• Un distributeur sans API. Il expédie les lunettes en 24-48 heures dans la Péninsule et les Baléares, mais la commande lui est transmise par e-mail. Le panneau produit en un clic exactement ce dont il a besoin : destinataire, adresse, téléphone, article et quantité, sous forme de texte et de CSV joint. Et comme ses envois partent avec GLS, l'API lit la boîte mail toutes les dix minutes, classe les e-mails du transporteur (en route, en point relais avec date limite, destinataire absent) et prévient l'acheteur pour chacun.

Une conséquence qui semble minime et ne l'est pas : une commande avec des lunettes et un T-shirt, ce sont deux colis de deux fournisseurs. C'est pourquoi le suivi existe par expédition et non par commande, avec une ligne pour chaque couple commande-fournisseur. Un seul champ « numéro de suivi » aurait fonctionné jusqu'au premier client qui achèterait les deux.

Les délais se mesurent, ils ne se promettent pas

L'API de cotation de l'imprimerie répondait « livraison standard, 5-10 jours » pour tout, y compris pour des produits qu'elle refusait ensuite lors d'une vraie commande. Nous l'avons découvert avec une vente qui n'a pas pu être livrée. Depuis, un minuteur crée chaque nuit une commande brouillon pour chaque combinaison produit-pays, lit le transporteur et les jours réels renvoyés par l'imprimerie, puis la supprime. Ce sont ces chiffres, et non ceux de la documentation, que voit l'acheteur sur la fiche avant de payer. C'est la même leçon que nous appliquons aux connecteurs Odoo : un test au vert contre un mock ne prouve rien ; il faut mesurer face au système réel.

Ce qui tourne tout seul

Sept unités systemd font ce que, dans une petite boutique, une personne fait d'ordinaire à la main : lire la boîte mail du transporteur toutes les dix minutes, vider les files d'e-mails et relancer toutes les quinze minutes les commandes encaissées mais non fabriquées, actualiser toutes les trois heures la prévision de nuages de l'AEMET pour les communes les plus consultées et mesurer chaque jour les délais de l'imprimerie. Aucune n'appelle un service externe dans le chemin d'une requête web : les pages lisent le cache, et un test le garantit.

Ce qui, dans tout cela, sert à votre boutique

Presque tout, en remplaçant l'éclipse par votre catalogue. Quand un client nous dit « je veux un site e-commerce de zéro », il demande exactement cette liste : un frontal rapide et multilingue, une caisse impossible à tromper, des intégrations avec celui qui fabrique et celui qui expédie, un suivi qui arrive au client sans que personne le recopie à la main, et des tâches qui tournent seules. Quand le client a déjà Odoo, cette API est remplacée par l'ERP lui-même et les intégrations sont des connecteurs de transporteur dans Odoo ; quand il n'en a pas, ou que son activité ne tient pas dans un ERP, on construit comme ici.

Questions fréquentes

Liens utiles chez FlexigoTech

Ce que nous faisons à ce sujet