Stella & Suzie

Le contexte

Stella & Suzie est une enseigne de prêt-à-porter qui opère un réseau de boutiques physiques, un site e-commerce Shopify et une ouverture internationale via Global-E. Le catalogue tourne autour de vingt mille références, avec ce que cela implique en variantes de taille et de coloris.

Le back-office est un Odoo 17 Enterprise hébergé sur Odoo.sh. Entre les deux, un connecteur sur mesure, écrit et repris par plusieurs prestataires successifs au fil des années.

À mon arrivée, ce connecteur faisait environ 90 000 lignes de Python que plus personne dans l’entreprise ne savait lire.

Le vrai problème : un système qui ne dit pas qu’il va mal

Un connecteur qui plante est un problème facile. Un connecteur qui dérive silencieusement est un problème coûteux, parce qu’on le découvre par la comptabilité, des semaines plus tard.

Ce que l’audit a mis au jour :

• Du chiffre d’affaires non comptabilisé : les écritures ne se généraient plus sur une partie des flux, et rien ne le signalait.
• Plus de onze mille alertes d’anomalie accumulées, très majoritairement fausses. Le bruit avait tué le signal : plus personne ne les ouvrait, donc les vraies anomalies passaient avec.
• Des webhooks Shopify tombés dont l’échec ne déclenchait aucune alerte et n’était jamais rejoué.
• Un fond de caisse gonflé par des sessions de point de vente mal rapprochées.

La cause commune n’est pas technique, elle est architecturale : le système n’était pas observable. Il produisait des effets sans produire de preuves.

Le périmètre de la mission

1. Audit de production, en lecture seule

Lecture du code, de la base et des volumes réels, sans jamais écrire en production. Sortie : un diagnostic écrit, hiérarchisé par impact financier, avec pour chaque point la preuve dans le code ou dans les données.

2. Remise en état

Traitée par ordre de gravité, pas par ordre de facilité : d’abord la comptabilité, puis les webhooks et leur rejeu, puis la caisse, puis le nettoyage des fausses anomalies pour redonner du sens aux alertes.

Le socle technique posé au passage :

• 35 topics de webhooks Shopify pris en charge, avec validation HMAC, déduplication par identifiant d’événement et file d’échecs.
• 34 tâches planifiées de synchronisation, qui rattrapent ce que l’événementiel a perdu, parce que les webhooks tombent, toujours.
• 264 tests anti-régression, dont une suite de vérification rapide exécutable après chaque déploiement.
• 31 migrations versionnées, pour que chaque changement de schéma soit rejouable et réversible.

3. Passage à l’échelle

Deux optimisations ont changé la nature du système :

• La résolution des clients traitait les enregistrements un par un et saturait les quotas de l’API Shopify. Réécrite en lots de cinquante en GraphQL, elle est passée de plus de quatre heures à une quinzaine de minutes sur trente mille clients.
• L’ajout de dix index sur les champs Shopify critiques a rendu instantanées des recherches qui ramaient sur plus de cent mille enregistrements.

4. Extension : un PLM pour la mode

Une marque de prêt-à-porter ne gère pas des produits, elle gère des collections : des saisons, des déclinaisons, des fournisseurs, des certifications matière, des visuels à décliner. Odoo ne couvre pas nativement ce cycle.

D’où un module PLM sur mesure, branché sur le référentiel produit, qui gère le cycle de vie d’une collection et s’interface avec les outils réellement utilisés par les équipes : le stockage documentaire de l’entreprise via l’API Microsoft Graph, la génération de déclinaisons visuelles via l’API Adobe Photoshop, et la signature électronique pour les certifications fournisseur.

5. Extension : l’inventaire au scan, depuis un téléphone

Les inventaires en boutique se faisaient sur papier puis se ressaisissaient. Le module d’inventaire mobile transforme n’importe quel téléphone connecté à Odoo en scanette : lecture de codes-barres EAN-13, EAN-8, Code 128, Code 39 et UPC directement dans le navigateur, avec repli sur une bibliothèque de décodage quand l’API native n’est pas disponible, et prise en charge des scanettes Bluetooth pour les gros volumes. La génération de codes-barres respecte le standard GS1, clé de contrôle comprise.

Ce que ça donne

• Un connecteur observable : les écarts réels remontent, le bruit a disparu.
• Une comptabilité française qui tombe juste, positions fiscales et TVA cross-border comprises.
• Des traitements lourds passés à l’échelle, sans toucher aux quotas de l’API.
• Un PLM et un inventaire mobile en production, sur un socle testé et migrable.

La mission se poursuit. C’est le genre d’architecture qui ne se termine pas : elle se maintient.

Ce que ce cas illustre

Reprendre du code hérité est le contraire d’un travail glamour, et c’est souvent le plus rentable. La tentation est toujours de tout réécrire. La bonne approche est de rendre le système lisible d’abord (tests, observabilité, migrations) puis de ne réécrire que ce qui le mérite.

Si votre connecteur vous inquiète sans que vous sachiez le prouver, l’audit est fait pour ça.

« Notre POS retail était un casse-tête. Nareh a tout connecté à Odoo proprement, formé l'équipe, et la caisse réconcilie sans intervention quotidienne. »