Gestion des commandes sur freitag.ch: enseignements

  • Tonio Zemp

Depuis fĂ©vrier 2021, le nouveau site freitag.ch est en ligne. Il est le fruit d’un vaste projet de mise Ă  niveau de Drupal, qui a impliquĂ© de nombreux changements sous-jacents.

En savoir plus sur le service DĂ©veloppement sur-mesure de notre agence digitale.

Ensemble, nous avons profitĂ© de l’occasion pour tirer des enseignements des cinq derniĂšres annĂ©es. L’occasion Ă©galement pour Freitag de promouvoir la durabilitĂ© au travers d’investissements digitaux. Et pour nos deux sociĂ©tĂ©s d’entretenir des relations pĂ©rennes. Focus sur la gestion des commandes, qui Ă©tait l’un des Ă©lĂ©ments essentiels de la refonte.

Freitag vend des sacs en bĂąches de camion usagĂ©es. Tous les produits sont donc pour ainsi dire des piĂšces uniques. Celles-ci nĂ©cessitent une unitĂ© de gestion des stocks (SKU ou « stock keeping unit ») individuelle et qui ne soit disponible qu’en un seul exemplaire dans les stocks de Freitag. Une fois un produit vendu, il ne peut plus ĂȘtre produit Ă  nouveau. Un vrai dĂ©fi pour la boutique en ligne ! Cette particularitĂ© exige non seulement des solutions qui s'Ă©cartent des meilleures pratiques UX ou technologiques, mais aussi un taux d'erreur extrĂȘmement bas dans la gestion des commandes. En cas de dĂ©faillance au moment du check-out, de l’exĂ©cution de la commande ou de l’expĂ©dition, un seul et mĂȘme produit a toutes les chances d’ĂȘtre commandĂ© par deux personnes diffĂ©rentes, ce qui serait fĂącheux.

En arriĂšre-plan : les systĂšmes

A part quelques micro-services, deux systĂšmes sont essentiellement Ă  la base du workflow :

  1. Drupal (panier, check-out, passation de commande, modification de commande, annulation, communication avec les client∙e∙s, communication entre magasins, gestion des promotions et bons d’achat)
  2. L’ERP de Freitag (gestion des stocks, exĂ©cution des commandes, expĂ©dition, contrĂŽle, retours).

Freitag souhaite que ses client∙e∙s aient toujours la possibilitĂ© d’acheter, mĂȘme quand l’ERP n’est pas disponible (en raison d’une maintenance par exemple). Drupal gĂšre par ailleurs d’autres systĂšmes et use cases, et a donc besoin d’une base de donnĂ©es Ă©largie en matiĂšre de commandes. Lors du lancement du site en 2016 comme lors de sa refonte en 2021, c’est une solution duale avec diffĂ©rents systĂšmes qui a promis le meilleur retour sur investissement (ROI). Du fait des exigences spĂ©cifiques de Freitag, une rĂ©partition plus ciblĂ©e en micro-services aurait impliquĂ© des frais nettement supĂ©rieurs pour des avantages en dĂ©finitive minimes.

Premier enseignement : répartition claire des tùches

Le mode opĂ©ratoire indĂ©pendant souhaitĂ© et les nombreuses fonctions originales des deux systĂšmes ont donnĂ© lieu Ă  des doublons qui risquaient d’entraĂźner des dysfonctionnements. Les deux systĂšmes pouvaient par exemple attribuer certains statuts de commande. De mĂȘme, les calculs de rabais et les clĂ©s de rĂ©partition pour les remboursements via plusieurs moyens de paiement Ă©taient en partie gĂ©rĂ©s par les deux systĂšmes. Une mise Ă  jour de l’interface ERP permet Ă  prĂ©sent une communication bidirectionnelle. Au lieu des innombrables requĂȘtes Ă©mises auparavant, l’ERP communique dĂ©sormais directement avec Drupal. C’est l’un des aspects qui ont permis de mieux rĂ©partir les tĂąches.

Prenons l’exemple du statut des commandes : il existe toujours deux reprĂ©sentations d’une commande, l’une dans l’ERP, l’autre dans Drupal. Dans Drupal, le processus dĂ©bute plus tĂŽt (panier et check-out) et finit plus tard (omni-channel, retrait en magasin, etc.). DorĂ©navant, , l’ERP dĂ©tient le contrĂŽle exclusif du statut de la commande pendant toute sa phase de traitement (exĂ©cution et expĂ©dition). NĂ©anmoins, comme les commandes peuvent ĂȘtre modifiĂ©es ou annulĂ©es pendant cette phase, Drupal peut envoyer des demandes de modification et d’annulation. Mais c’est toujours l’ERP qui dĂ©clenche le changement de statut auprĂšs de Drupal.

Prenons l’exemple des remboursements : pour les paiements par carte de crĂ©dit, bons d’achat et codes promotionnels, Drupal se connecte aux systĂšmes concernĂ©s. En cas de remboursement par le biais de plusieurs moyens de paiement, Drupal dĂ©cidait des montants qui devaient ĂȘtre crĂ©ditĂ©s sur chacun de ces modes de paiement. Mais la base comptable de ce calcul Ă©tait toujours l’ERP. MĂȘme si a priori, les deux systĂšmes utilisaient les mĂȘmes rĂšgles, il pouvait y avoir certains Ă©carts. DĂ©sormais, seul l’ERP fait foi et il communique Ă  Drupal via une interface les montants Ă  rembourser sur les diffĂ©rents moyens de paiement.

Partout oĂč cela a Ă©tĂ© possible sans frais dĂ©mesurĂ©s, nous avons attribuĂ© une souverainetĂ© claire Ă  l’un ou l’autre des systĂšmes dans le cadre de processus intermĂ©diaires. Au terme de quelques mois, nous ne disposons pas encore de suffisamment de recul pour Ă©valuer la stabilitĂ© Ă  long terme du workflow. Jusqu’à prĂ©sent, les premiĂšres expĂ©riences sont nĂ©anmoins positives.

DeuxiÚme enseignement : détermination automatique des stocks disponibles

Le niveau de stock de la quasi-totalitĂ© des produits est systĂ©matiquement de 1 ou 0, et les systĂšmes doivent fonctionner de maniĂšre autonome : deux contraintes qui ne vont pas sans quelques difficultĂ©s. Lorsque des commandes sont modifiĂ©es en dehors du cadre de la procĂ©dure standard, ou lorsqu’elles passent Ă  un traitement manuel, il ne faut pas qu’un produit commandĂ© se retrouve Ă  nouveau disponible en ligne. De la mĂȘme maniĂšre, la « remise en ligne » du produit le cas Ă©chĂ©ant ne doit pas non plus faire l’objet d’une intervention manuelle. Car cela impliquerait trop de personnel.

Nous avions jusqu’à prĂ©sent un niveau de stock physique (celui de l’ERP) et un autre, virtuel. Ce dernier servait Ă  s’affranchir de phases pendant lesquelles l’ERP Ă©tait indisponible ou indiquait un niveau qui n’était plus d’actualitĂ©. Cette solution fonctionnait dans bien plus de 99 % des cas. Dans de rares cas, mais nĂ©anmoins rĂ©currents, elle donnait en revanche lieu Ă  un niveau de stock de « -1 » ou « +2 ». En raison de la complexitĂ© de la configuration, l’origine de ces quelques incohĂ©rences Ă©tait difficile Ă  identifier.

Dans le cadre de la refonte, nous avons conservĂ© cette double gestion des stocks. Mais nous avons aussi introduit un principe important pour simplifier le tout : « l’ERP a toujours raison ». Principe qui s’accompagne nĂ©anmoins d’une architecture plus complexe avec un autre layer, pour les rĂ©servations. Parce que l’ERP n’a en rĂ©alitĂ© pas toujours raison, les rĂ©servations sont un rempart supplĂ©mentaire Ă  la double vente involontaire d’un mĂȘme produit. GrĂące Ă  la simplification de la logique de stock et au principe de rĂ©servations via Drupal exclusivement, il est dĂ©sormais beaucoup plus facile, en cas de problĂšme, d’identifier ce qui s’est passĂ© dans chacun des systĂšmes. Un avantage trĂšs utile notamment pendant ces premiers mois.

 TroisiÚme enseignement : numéro de suivi

En fonction de la configuration, mĂȘme la mise en place d’un numĂ©ro de suivi peut se rĂ©vĂ©ler dĂ©licate. Freitag livre ses produits Ă  l’international et fait appel Ă  diffĂ©rents prestataires. Ceux-ci n’ont pas tous les mĂȘmes mĂ©thodes de fonctionnement. Des des numĂ©ros de suivi ne sont pas toujours gĂ©nĂ©rĂ©s, ou pas toujours au mĂȘme moment, et ils ne sont pas non plus consultables Ă  partir du mĂȘme moment. Or la possibilitĂ© de consulter un numĂ©ro de suivi est prĂ©cisĂ©ment l’état souhaitĂ© lors de l’envoi d’une confirmation d’expĂ©dition. Jusque-lĂ , la logique en place essayait tant bien que mal de prendre en compte ces diffĂ©rents scĂ©narios pour Ă©tablir la date d’envoi du mail de confirmation d’expĂ©dition. Cela Ă©tait fait en interrogeant l’ERP et en fonction du type de commande, du mode de livraison, des champs renseignĂ©s et du dĂ©lai d’attente. Mais il arrivait malgrĂ© tout trop souvent que des confirmations d’expĂ©dition soient envoyĂ©es trop tĂŽt ou trop tard. Et les tentatives d’amĂ©lioration des rĂšgles de calcul se sont souvent soldĂ©es par des problĂšmes. Il fallait donc trouver une solution.

Lors de la refonte, nous avons introduit dans la gestion des commandes un nouveau statut : « emballĂ© ». Dans cet Ă©tat, la commande est bel et bien emballĂ©e, peut-ĂȘtre mĂȘme en cours d’acheminement, mais le numĂ©ro de suivi n’est pas encore connu ou consultable. Lorsqu’il est gĂ©nĂ©rĂ©, l’ERP dĂ©clenche le statut « envoyĂ© ». DĂšs que ce statut est activĂ©, Drupal gĂ©nĂšre la confirmation d’expĂ©dition, avec ou sans numĂ©ro de suivi. Les tĂąches sont ainsi clairement rĂ©parties et en cas de problĂšme, il est bien plus facile d’identifier l’origine de l’erreur et de la rĂ©soudre. L’ERP peut Ă©valuer plus simplement l’état du numĂ©ro de suivi et Drupal s’affranchit de quelques rĂšgles. Cette Ă©volution a dĂ©jĂ  fait ses preuves : elle est manifestement trĂšs efficace.

Bilan : simplifier grùce à la complexité

Chez Liip, notre instinct nous guide toujours vers la simplicitĂ©. Car nous savons par expĂ©rience qu’elle permet de minimiser les difficultĂ©s, tant lors du dĂ©veloppement que de l’exploitation. Les prĂ©cĂ©dents exemples montrent cependant que la simplification peut aussi conduire en apparence Ă  davantage de complexitĂ©. Car en dĂ©finitive, nous avons installĂ© de nouvelles interfaces, des layers supplĂ©mentaires et un nouveau statut de commande. Mais ces trois mesures rendent le systĂšme nettement plus solide. En cas de dysfonctionnement, elles permettent aussi de trouver l’erreur plus rapidement. Dans le cadre de l’activitĂ© courante, cela est essentiel pour les investissements dans les dĂ©veloppements ultĂ©rieurs. . Et telle est prĂ©cisĂ©ment notre ambition : aider nos client∙e∙s Ă  dĂ©velopper leurs produits et solutions, sans nous contenter d’entretenir leur systĂšme.


Qu’en penses-tu?