Gestion des commandes sur freitag.ch: enseignements

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.