Cinq services de livraison dans un seul plugin : SDEK, KIT, Business Lines, Russian Post, Boxberry

La semaine dernière, le propriétaire d'une boutique en ligne de lubrifiants industriels m'a écrit. Un homme vend des huiles, des fluides hydrauliques, de l'antigel - des marchandises lourdes et volumineuses qui doivent être livrées dans toute la Russie. Et voici ce qu’il a dit : il dispose de cinq plugins de livraison distincts sur son site Web. Un pour SDEK, un pour Boxberry, un pour les Business Lines, un autre pour la Poste Russe et le dernier pour KIT. Chaque plugin coûte de trois à dix mille roubles par an. Chacun est mis à jour selon son propre calendrier. Chacun a sa propre interface de paramètres. Alors il s'assoit et réfléchit : est-il vraiment impossible de tout faire fonctionner à partir d'un seul endroit ? Pour que l'acheteur au moment du paiement puisse voir toutes les options de livraison en même temps et sélectionner un point de retrait sur la carte, plutôt que d'avoir à fouiller dans d'interminables boutons radio ?

Je l'ai écouté et j'ai réalisé que ce n'était pas une situation unique. C'est une douleur à laquelle sont confrontés presque tous les propriétaires de magasins WooCommerce en Russie. Et plus le magasin est grand, plus cette douleur est aiguë. Parce que cinq plugins ne sont pas seulement cinq abonnements. Ce sont cinq points d’échec potentiels. Cinq équipes de développement différentes qui peuvent abandonner leur produit ou publier une mise à jour qui rompt la compatibilité avec la dernière version de WordPress. Il s'agit de cinq styles d'affichage différents à la caisse, qui sont incompatibles les uns avec les autres et donnent à l'acheteur le sentiment que le site est assemblé à partir de morceaux sur du ruban adhésif.

Lorsque nous avons conçu le module de livraison pour COS WP Woo, nous sommes partis d'une idée simple : un plugin - tous les transporteurs. Pas un agrégateur qui vous facture une commission pour chaque commande. Il ne s'agit pas d'un wrapper universel qui se brise à chaque fois que l'API de l'entreprise de transport change. Et une intégration directe à part entière avec l'API de chaque opérateur, réunie par une interface logicielle unique. Cela semble simple ? En pratique, cela signifie des mois de travail, des centaines d'heures de tests et des dizaines de nuances dont je souhaite parler.

Mais commençons non pas par les détails techniques, mais par l'économie. Car en fin de compte, le propriétaire du magasin ne s'intéresse pas à la beauté de l'architecture que nous avons conçue, mais à la quantité d'argent qu'il économisera et au nombre de problèmes qui disparaîtront de sa vie quotidienne.

L'arithmétique qui parle d'elle-même

Faisons le calcul. Plugin pour SDEK - à partir de cinq mille roubles par an pour la version normale avec prise en charge de l'API v2. Boxberry - à peu près la même chose, peut-être un peu moins cher, trois ou quatre mille. Business Lines - il y a moins d'options ici, les bons plugins commencent à partir de six mille. Poste russe - trois à cinq mille autres. KIT - très peu de gens le font, mais quand ils le font, ils en demandent cinq à sept mille, car le marché est petit et il n'y a presque pas de concurrence. Total - de quinze à cinquante mille roubles par an uniquement pour les plugins de livraison. Et cela sans compter le temps que votre technicien (ou vous-même) consacre à tout configurer, synchroniser et maintenir en état de fonctionnement.

Mais l'argent n'est pas la pire des choses. Le pire, ce sont les conflits. Je me souviens d'un cas où l'un de nos clients, après avoir mis à jour WordPress vers 6.5, deux plugins de livraison sur cinq ont cessé de fonctionner. Ils se sont juste arrêtés. Les développeurs de l’un ont répondu en une semaine, du second en trois semaines. Pendant tout ce temps, le magasin a travaillé avec des options de livraison limitées, a perdu des commandes et a reçu des critiques négatives. Parce que l'acheteur ne comprendra pas pourquoi son entreprise de transport préférée n'est pas à la caisse, il s'adressera simplement à un concurrent.

Il y a encore un point dont peu de gens parlent. Chaque plugin de livraison ajoute ses propres scripts et styles à la page de paiement. L'un connecte un widget jQuery pour une carte, un autre connecte son propre composant React, le troisième connecte autre chose. En conséquence, la page de paiement se charge en quatre à cinq secondes au lieu des deux requises, et le taux de conversion chute. Certaines études montrent que chaque seconde supplémentaire de chargement à la caisse réduit la conversion de sept à dix pour cent. Multipliez cela par votre facture moyenne et le nombre de commandes par mois : les chiffres sont impressionnants.

Lorsque tous les opérateurs travaillent à partir d'un seul plugin, il s'agit d'un téléchargement de script, d'une carte, d'une requête AJAX pour le calcul des coûts. Pas cinq requêtes adressées à cinq API différentes, mais une requête adressée à votre serveur, qui, sur le backend, interroge en parallèle toutes les API nécessaires et renvoie un résultat consolidé. La différence de vitesse est colossale.

Comment nous avons abordé l'architecture : une interface - tous les opérateurs

Savez-vous ce qui distingue un bon système d'ingénierie d'un mauvais système ? Un bon système est conçu de manière à ce que l’ajout d’un nouvel élément ne brise pas ceux existants. Lorsque nous avons commencé à concevoir le module de livraison, la première chose que nous avons faite a été de définir un contrat commun à tous les transporteurs. En programmation, cela s'appelle une interface, et notre CarrierInterface décrit exactement quatre choses que chaque transporteur devrait être capable de faire : fournir son code et son nom, calculer le coût de livraison, renvoyer une liste de points de retrait et vérifier si les clés API sont configurées.

Pourquoi est-ce important pour vous en tant que propriétaire de magasin ? Car cela signifie que tous les transporteurs fonctionnent exactement de la même manière du point de vue du système. Lors du paiement, l'acheteur voit un tableau uniforme, où sont indiqués pour chaque transporteur le coût, le délai de livraison et si la livraison est disponible à la porte ou au point de retrait. Pas besoin de comprendre les différentes interfaces des différents plugins. Tout semble ne faire qu'un parce que c'est un.

Nous avons mis en place cinq transporteurs : SDEK, KIT, Business Lines, Russian Post et Boxberry. Chacun d'eux est une classe distincte qui implémente une interface commune. CdekCarrier fonctionne avec l'API SDEK version 2.0, utilise l'autorisation OAuth et prend en charge deux tarifs : livraison au point d'émission et livraison par coursier jusqu'à la porte. KitCarrier s'intègre à l'API KIT Auto, particulièrement pertinente pour le transport interurbain de marchandises lourdes et surdimensionnées. DellineCarrier travaille avec Business Lines, l'une des plus grandes sociétés de transport de Russie, ce qui est indispensable si vous envoyez des palettes ou des marchandises volumineuses. PostRussiaCarrier se connecte à l'API de la poste russe via otpravka-api.pochta.ru et calcule le coût des colis, des colis, du EMS et de la livraison par coursier. Enfin, BoxberryCarrier fonctionne avec l'API Boxberry, particulièrement appréciée dans le segment des colis de petite et moyenne taille.

C'est ici que je souhaite m'arrêter et expliquer pourquoi nous avons choisi l'intégration directe d'API plutôt qu'un agrégateur. Il existe des solutions sur le marché comme eShopLogistic, qui font office d'intermédiaire entre votre magasin et les sociétés de transport. L'idée est belle : vous connectez un service et avez accès à tous les opérateurs via une seule API. Nous avons nous-mêmes utilisé cette approche sur l'un des projets et avons rencontré un certain nombre de problèmes qui nous ont obligés à reconsidérer notre stratégie.

Le premier problème, et le plus évident, est un point de défaillance supplémentaire. Lorsqu'il existe un autre service entre votre magasin et SDEK, toute panne du côté de ce service signifie que tous vos transporteurs cessent de fonctionner en même temps. Nous avons rencontré cela deux fois en six mois : l'agrégateur est resté en panne pendant plusieurs heures et toute la caisse a été paralysée. Avec l'intégration directe, si l'API SDEK ne répond pas, tous les autres opérateurs continuent de fonctionner. L'acheteur ne verra tout simplement pas les options SDEK, mais pourra choisir Boxberry ou Business Lines.

Le deuxième problème est la vitesse. La requête via l'agrégateur se déroule comme ceci : votre serveur → agrégateur → API de l'opérateur → agrégateur → votre serveur. Cela représente cent à deux cents millisecondes supplémentaires pour chaque demande, ce qui ajoute à un délai notable au moment du paiement. Avec l'intégration directe, votre serveur accède directement à l'API de l'opérateur et la réponse est plus rapide.

Le troisième problème est la pertinence des données. Les agrégateurs ne captent pas toujours immédiatement les changements dans l'API des entreprises de transport. Lorsque SDEK a mis à jour son API vers la version 2.0, certains agrégateurs travaillaient encore pendant des mois sur l'ancienne version et renvoyaient des données inexactes sur les coûts et les conditions. Avec l'intégration directe, vous travaillez avec la dernière version de l'API et obtenez les calculs les plus précis.

Pour être honnête, l'intégration directe présente un inconvénient : elle est difficile à prendre en charge. Lorsque chaque opérateur met à jour son API, nous devons mettre à jour la classe correspondante dans notre plugin. Mais c’est exactement pour cela qu’il existe une seule CarrierInterface : les modifications apportées à un transporteur n’affectent pas les autres. Nous pouvons facilement mettre à jour CdekCarrier sans toucher à BoxberryCarrier, et tout continuera à fonctionner.

Et si on le regardait sous un autre angle ? Imaginez que demain une nouvelle entreprise de transport apparaisse sur le marché et propose d'excellents tarifs à votre région. Avec notre architecture, ajouter un nouveau transporteur revient à créer une nouvelle classe qui implémente la même interface. Aucune modification du code existant, aucun risque de casser quoi que ce soit. Nous avons créé une classe, l'avons enregistrée dans le système - et elle est déjà apparue à la caisse à côté des autres. Essayez d'y parvenir avec cinq plugins distincts provenant de développeurs différents.

FIAS, adresses et pourquoi la recherche par chaîne est un chemin qui ne mène nulle part

Il existe un sujet sur lequel les développeurs de plugins de livraison restent généralement timidement silencieux. Il s'agit d'un problème de détermination de la ville destinataire. Il semblerait qu'il n'y ait rien de compliqué ici - l'acheteur est entré dans la ville, le système l'a transféré à la société de transport et ils ont reçu un calcul. Mais en pratique, tout est bien plus amusant.

Essayez de saisir « Chelyabinsk » dans différentes API - tout fonctionnera bien. Essayez maintenant Nijni Tagil. Ou « Naberejnye Tchelny ». Ou "Rostov-sur-le-Don". Chaque entreprise de transport possède son propre répertoire de villes, son propre format de nom et ses propres codes. SDEK utilise ses propres codes de ville internes. Boxberry - le nôtre. Business Lines - vos propres terminaux. La poste russe fonctionne selon les codes postaux. Et maintenant, vous écrivez des convertisseurs d'un format à un autre, en gérant les différences d'orthographe (avec ou sans trait d'union, dans quel ordre les mots apparaissent), et cela se transforme en un cauchemar de support sans fin.

Nous avons résolu ce problème fondamentalement. Au lieu de faire correspondre les noms de villes en chaîne entre différentes API, nous utilisons FIAS - Federal Information Address System. Il s'agit du classificateur d'adresses officiel de la Fédération de Russie, où chaque localité se voit attribuer un identifiant unique - GUID. Cet identifiant ne dépend pas de la façon dont vous écrivez le nom de la ville - cyrillique, latin, avec ou sans faute de frappe.

Dans notre système, chaque classe d'expédition dans WooCommerce est liée au code FIAS de la ville d'expédition. Cela signifie que lorsqu'un produit est envoyé depuis un certain entrepôt, le système sait exactement de quelle ville il est envoyé - non pas par son nom de chaîne, mais par un identifiant unique dans l'annuaire fédéral. Pour la ville du destinataire, nous utilisons une combinaison de méthodes : code FIAS, si disponible, ou code postal pour la poste russe, ou code de ville interne pour les transporteurs qui fournissent une API de recherche de ville.

Je me demande depuis longtemps pourquoi les autres développeurs n'utilisent pas cette approche. La réponse, comme d’habitude, est simple : elle est plus difficile à mettre en œuvre. La recherche de chaîne est une ligne de code. L'intégration FIAS est une classe ShippingFias distincte qui ajoute une colonne de code FIAS aux paramètres de classe d'expédition WooCommerce, stocke ces codes dans les métadonnées de taxonomie et les fournit lors du calcul de l'expédition. Mais le résultat en vaut la peine : le calcul fonctionne correctement pour n'importe quelle ville de Russie, sans erreurs dues aux différences dans l'orthographe des noms.

Voici un exemple précis issu de notre pratique. L'un des clients vendait des huiles dans toute la Russie et était confronté au fait que lors de l'envoi à la ville de Noyabrsk, l'ancien plugin SDEK ne pouvait pas trouver cette ville, car dans son annuaire interne, la ville était enregistrée comme « Noyabrsk (région de Tioumen) », et l'acheteur avait simplement saisi « Noyabrsk ». La commande est restée bloquée, le responsable a appelé le client, a clarifié l'adresse et a créé manuellement une application sur le site SDEK. Multipliez cela par vingt à trente cas de ce type par mois et vous comprendrez l'ampleur du problème. Avec FIAS, ce problème n'existe tout simplement pas, car Noyabrsk n'a qu'un et un seul GUID dans le répertoire fédéral, et c'est exactement ce que tous les transporteurs reçoivent.

Il existe un autre aspect du travail avec des adresses qui mérite d'être mentionné : le regroupement des marchandises par entrepôts d'expédition. Dans les affaires réelles, notamment dans le segment B2B, les marchandises sont souvent stockées dans différents entrepôts. L'un de nos clients possédait des huiles Shell dans un entrepôt à Chelyabinsk, des huiles Lukoil dans un entrepôt à Nerson et des fluides hydrauliques dans un entrepôt de commercialisation situé à un autre endroit. Chaque entrepôt est sa propre classe de livraison dans WooCommerce avec un code FIAS associé. Lorsqu'un acheteur ajoute au panier des articles provenant de différents entrepôts, notre système les regroupe automatiquement et calcule les frais d'expédition séparément pour chaque groupe. L'acheteur voit que la livraison coûte tellement cher pour les huiles Shell, et tellement pour les huiles Lukoil, et le coût total est le suivant. Transparent, compréhensible, sans surprises cachées.

Caisse dont vous pouvez être fier : matrice de livraison et plan des points de retrait

Parlons maintenant de ce que voit l'acheteur. Parce que vous pouvez créer l’architecture parfaite sur le backend, mais si à la caisse tout ressemble à une feuille de calcul Excel de 1998, personne ne s’en portera mieux.

Nous avons construit une matrice de livraison - un tableau dans lequel l'acheteur voit toutes les options disponibles auprès de tous les transporteurs connectés. Pour chaque option, le nom du transporteur, le type de livraison (à domicile ou au point de retrait), le coût et le délai estimé sont indiqués. L'acheteur sélectionne l'option appropriée en un seul clic. S'il a choisi la livraison en point relais, une carte s'ouvre avec les points repérés du transporteur qu'il a choisi. Sur la carte, vous pouvez trouver le point de retrait le plus proche, voir son adresse et ses horaires d'ouverture.

Vous savez ce qui m'a toujours ennuyé dans les plugins de livraison existants ? Ils affichent les options de manière séquentielle - d'abord toutes les options SDEK, puis toutes les options Boxberry, puis toutes les options de la poste russe. Et l'acheteur lui-même doit parcourir cette liste interminable, en comparant les prix et les conditions. Tout est clair dans notre matrice - tous les transporteurs sont à proximité, comparez et choisissez. Je pense que cela affecte considérablement la conversion, même si nous n'avons pas encore effectué de tests A/B précis pour cet élément particulier. Mais la logique veut : plus il est facile pour une personne de prendre une décision, plus vite elle passera une commande.

Il convient de mentionner séparément la mise en œuvre technique de la matrice lors du paiement. WooCommerce fournit un mécanisme de méthodes d'expédition standard et notre module enregistre une seule méthode d'expédition avec l'ID wpaic_shipping. Une méthode, pas cinq différentes. Cela signifie que tous les transporteurs fonctionnent selon la même méthode d'expédition WooCommerce, s'intègrent correctement aux zones d'expédition WooCommerce et n'entrent pas en conflit avec d'autres méthodes d'expédition que vous pouvez utiliser (par exemple, le retrait en bordure de rue ou la livraison gratuite au-delà d'un certain montant de commande).

Le calcul des coûts s'effectue en temps réel via l'API de chaque transporteur. Lorsque l'acheteur saisit son adresse lors du paiement, notre plugin envoie les paramètres de la commande (poids, dimensions, valeur déclarée, ville destinataire) à chaque API connectée et récupère en retour le coût et le délai de livraison. Les résultats sont mis en cache pendant dix minutes (il s'agit d'un paramètre configurable) pour éviter de surcharger l'API avec des requêtes redondantes si un client actualise la page ou modifie le nombre d'articles dans le panier.

Je souhaite ici parler d'une nuance technique qui peut paraître triviale, mais en pratique cela nous a coûté plusieurs jours de débogage. Dans WooCommerce, les données de session sont des chaînes. Lorsque vous obtenez le poids d'un élément d'une session, vous obtenez la chaîne « 1,5 » plutôt que le nombre 1,5. Et si vous transmettez cette chaîne à la fonction round() dans PHP 8.x sans la convertir explicitement en float, vous obtiendrez une erreur. Cela semble trivial, mais imaginez que vous ayez cinq opérateurs et que chacun d'eux reçoive les données de la session - si au moins un développeur oublie la conversion de type, le calcul des coûts sera interrompu. Dans notre code, chaque valeur numérique des paramètres est explicitement convertie en flottant avant les opérations mathématiques. Bagatelle? Oui. Mais ce sont précisément ces petites choses qui constituent un travail stable.

Et voici un autre point qui me semble fondamentalement important. Les calculs de livraison sont rendus via le hook woocommerce_review_order_before_payment, et non via before_order_review, comme le conseillent de nombreux guides. Pourquoi? Car before_order_review ne fonctionne pas correctement avec les thèmes WordPress en bloc, qui deviennent un standard. Nous avons passé beaucoup de temps à comprendre pourquoi la matrice de livraison n'apparaissait tout simplement pas sur l'un de nos sites de test avec le thème Twenty Twenty-Five jusqu'à ce que nous découvrions que le hook before_order_review dans les thèmes de bloc était déclenché avant que le formulaire de paiement ne soit entièrement rendu. Le passage à before_payment a résolu le problème. Il existe des dizaines de nuances de ce type, et c’est ce qui distingue un plugin qui « semble fonctionner » d’un plugin qui fonctionne de manière fiable.

Suivi : de la création de la commande à la livraison du colis

La livraison ne consiste pas seulement à calculer le coût et à choisir un transporteur au moment du paiement. C'est également ce qui se passe après avoir passé une commande. L'acheteur veut savoir où se trouve son colis, quand il arrivera et que faire en cas de problème. C'est là que le chaos commence pour la plupart des magasins WooCommerce.

Un scénario typique ressemble à ceci : un responsable place un envoi sur le site Internet de l'entreprise de transport, obtient le numéro de suivi, le copie, le colle dans le bon de commande dans WooCommerce, et peut-être - peut-être ! — envoie à l'acheteur un email avec ce numéro. L'acheteur reçoit une lettre, se rend sur le site Internet du transporteur, saisit le numéro de suivi et vérifie l'état. Si le transporteur est différent, il doit savoir sur quel site se renseigner. Si la commande contient des marchandises provenant de plusieurs transporteurs (vous souvenez-vous du regroupement par entrepôts ?), l'acheteur doit suivre plusieurs numéros de piste sur différents sites Internet.

Nous avons intégré le suivi des expéditions directement dans le système. Lorsque le responsable saisit le numéro de piste sur la fiche de commande, l'acheteur le voit dans son compte personnel sur le site du magasin. Plus besoin de se rendre sur des sites tiers, plus besoin de se rappeler quel transporteur livre quelle partie de la commande. Tout est au même endroit : nom du transporteur, numéro de piste, statut actuel. Lorsque le statut de l'expédition change, l'acheteur reçoit une notification par e-mail.

J'entends souvent la question : « Pourquoi faire cela dans un plugin si l'acheteur peut déjà vérifier le suivi sur le site du transporteur ? La réponse est simple : il s’agit d’expérience client. Un magasin dans lequel toutes les informations sont disponibles en un seul endroit - dans votre compte personnel - est perçu comme plus professionnel et fiable. L’acheteur ne pense pas « J’ai commandé sur un site Web, mais c’est livré par SDEK ». Il pense : « J'ai commandé dans ce magasin et ils se sont assurés qu'il me serait facile de suivre la livraison. » Ce sont les petites choses qui fidélisent.

Parlons maintenant du côté du vendeur. Si vous possédez une boutique en ligne avec des dizaines de commandes par jour, gérer la livraison devient une corvée. Suivez les numéros, les statuts, les notifications - tout cela doit être contrôlé. Notre module de livraison s'intègre au module 1C, qui fait également partie de COS WP Woo. Cela signifie que les statuts des expéditions peuvent être synchronisés avec votre système comptable. Le responsable en 1C voit que la commande a été envoyée, quel est son numéro de piste, quel est le transporteur, quel est l'état actuel. Pas besoin de basculer entre plusieurs systèmes : tout est synchronisé.

Je sais que beaucoup de gens sont sceptiques quant à l'idée du "plugin tout-en-un". Et je comprends ce scepticisme. Les solutions universelles sont souvent inférieures aux solutions spécialisées en termes d’élaboration. Mais il y a ici une nuance importante : nous ne créons pas un seul plugin pour tout. Nous créons un plugin pour l'écosystème de la boutique WooCommerce, où tous les modules fonctionnent ensemble et échangent des données. Le module de livraison connaît le module 1C. Le module 1C connaît le module B2B. Le module B2B connaît le module de notifications par e-mail. Il ne s'agit pas d'un ensemble de fonctions disparates regroupées dans un seul fichier ZIP : il s'agit d'un système intégré, dans lequel chaque module améliore les autres.

La Poste Russe est un transporteur qui s'est toujours démarqué

Je souhaite parler de la poste russe séparément, car son intégration est une histoire à part, pleine de douleur et de joie à la fois. La Poste russe constitue le plus grand réseau logistique du pays. Plus de quarante-deux mille succursales. Livraison dans toutes les localités, y compris les villages et les villes, où aucun transporteur commercial ne se rendra. Pour de nombreux magasins, la Poste russe est le seul moyen de livrer des marchandises dans les régions éloignées.

Dans le même temps, l'API de la poste russe est, pour le moins, une chose particulière. Ils disposent de deux API : un calculateur de tarif (public, sans autorisation) et une API d'envoi (avec autorisation via un token et login). Le calculateur de tarif fonctionne par code postal - vous transmettez l'indice d'envoi, l'indice de réception, le poids, le type d'article et la valeur déclarée, et obtenez le coût. Cela semble simple, mais, comme toujours, le diable se cache dans les détails.

Le type de répartition est quelque chose qui déroute la plupart des développeurs. Colis, colis postaux, EMS, livraison par coursier - chaque type a son propre code, ses propres restrictions de poids et de dimensions et sa propre grille tarifaire. Notre PostRussiaCarrier détermine automatiquement le type d'envoi optimal en fonction du poids et de la valeur déclarée de la commande. Si le colis est léger, il est calculé comme un colis postal (c'est moins cher). Si c’est lourd, c’est comme un colis standard. Si l'acheteur souhaite plus rapide, il propose la livraison EMS ou par coursier. L'acheteur voit toutes les options disponibles avec les prix et les conditions et choisit ce qui lui convient.

La gestion des erreurs est une autre histoire. L'API de la poste russe peut renvoyer une erreur pour une raison totalement non évidente, par exemple parce que le code postal fait référence à une unité militaire ou à une entité territoriale fermée. Dans de tels cas, notre plugin n'affiche pas à l'acheteur un message d'erreur cryptographique, mais n'affiche tout simplement pas les options de la poste russe, laissant d'autres transporteurs disponibles. Cela semble être une petite chose, mais pour l'acheteur, il y a une énorme différence - entre « Erreur dans le calcul de la livraison, réessayez plus tard » et une caisse fonctionnant normalement, où l'une des options n'est tout simplement pas disponible.

Et c'est là que le plaisir commence d'un point de vue architectural. Vous vous souvenez quand j'ai parlé de la CarrierInterface unique ? Chaque transporteur de la méthode calculate() renvoie un résultat standardisé : statut de réussite, prix, date limite, texte d'erreur (le cas échéant) et code du transporteur. Cela signifie que le système de traitement des résultats est absolument le même pour tous les transporteurs. Si SDEK renvoie une erreur, nous affichons le reste. Si la poste russe renvoie une erreur, nous affichons le reste. Si tout le monde a renvoyé un résultat positif, nous montrons la matrice complète. La logique est simple et fiable, car elle ne dépend pas des spécificités d'un transporteur particulier.

SDEK et Boxberry sont deux géants qui devraient être amis

SDEK et Boxberry sont peut-être les deux opérateurs de boutiques en ligne les plus populaires en Russie. SDEK dispose d'un vaste réseau de points de livraison - plus de quatre mille à travers le pays. Le Boxberry a ses propres atouts, notamment sur le segment des petites parcelles et dans les régions où le SDEK est peu représenté. De nombreux magasins connectent les deux services pour offrir à l'acheteur un maximum de choix.

SDEK est passé à l'API v2.0, qui utilise l'autorisation OAuth. Cela signifie que pour accéder à l'API, vous devez d'abord obtenir un jeton d'accès en échangeant client_id et client_secret contre un jeton de support temporaire. Notre CdekCarrier gère cela automatiquement : il reçoit le jeton, le met en cache dans les transitoires WordPress et le met automatiquement à jour lorsqu'il expire. Pour vous en tant qu'utilisateur, cela signifie que vous entrez une fois client_id et client_secret dans les paramètres du plugin et que vous n'y pensez plus jamais.

La situation avec Boxberry est plus simple : ils disposent d'une autorisation via un jeton, qui est transmis en tant que paramètre de requête. Mais Boxberry a ses propres difficultés à définir une ville. Boxberry utilise son propre annuaire de ville interne avec ses propres codes. Notre BoxberryCarrier résout d'abord la ville de l'acheteur - trouve son code dans l'annuaire Boxberry par nom et code postal - et calcule ensuite seulement les frais de livraison. Si la ville n'est pas trouvée (ce qui arrive dans les petites villes), Boxberry n'apparaît tout simplement pas dans la matrice de livraison, et l'acheteur peut choisir un autre transporteur.

Une chose intéressante que j'ai remarquée au fil des années de travail dans le domaine de la livraison est que les clients sont très fidèles à « leur » transporteur. Certaines personnes choisissent par principe uniquement SDEK, car il existe un point de retrait pratique à proximité de leur domicile. Certaines personnes préfèrent Boxberry car elles livrent plus rapidement dans leur région. Certaines personnes aiment les Business Lines car elles livrent de lourdes charges de manière fiable. Et la tâche du magasin n’est pas d’imposer un transporteur spécifique à l’acheteur, mais de lui donner le choix. Plus il y a d'options, plus il y a de chances que l'acheteur trouve ce qui lui convient et finalise la commande.

Mais il y a un autre revers à la médaille. Chaque opérateur supplémentaire signifie des clés API supplémentaires qui doivent être obtenues et configurées. Pour SDEK, vous devez enregistrer un accord et accéder à l'API. Pour Boxberry, obtenez un jeton. Pour les Business Lines - concluez un accord et recevez une clé API. Pour la poste russe, inscrivez-vous sur otpravka.pochta.ru et recevez un jeton d'autorisation. Pour KIT c’est pareil. Nous ne pouvons pas faire cette partie pour vous – c'est un processus entre vous et la compagnie maritime. Mais nous pouvons – et nous le faisons – fournir des instructions claires dans les paramètres du plugin sur où et comment obtenir chaque clé, avec des liens directs vers les pages d'enregistrement.

Savez-vous quelle est la meilleure partie ? La méthode is_configured() dans chaque opérateur vérifie si les clés API sont configurées. Dans le cas contraire, le transporteur ne participe tout simplement pas au calcul. Cela signifie que vous pouvez d'abord connecter uniquement SDEK et Boxberry, puis, lorsque vous êtes d'accord avec Business Lines et KIT, les ajouter en entrant simplement les clés dans les paramètres. Pas de reconfigurations, pas de tests répétés. Le système sélectionnera automatiquement les nouveaux transporteurs et commencera à les afficher à la caisse.

KIT et Business Lines - pour ceux qui transportent des marchandises sérieuses

Il existe un segment de marché que SDEK et Boxberry ne desservent pas très bien : il s'agit des marchandises volumineuses et lourdes. Un bidon de 20 litres d'huile moteur pèse environ 18 kilogrammes. Un baril de 200 litres pèse déjà environ 200 kilogrammes. Palette d'huiles - 500-800 kilogrammes. Ce type de fret nécessite des transporteurs spécialisés dans le fret groupé et disposant de terminaux pour recevoir les gros envois.

KIT (Entreprise Industrielle de Transport) est l'un des leaders sur le segment du transport routier interurbain de marchandises. Ils disposent de plus de cinq cents terminaux dans toute la Russie et traitent bien des marchandises de 20 à 20 000 kilogrammes. Pour nos clients qui vendent des huiles et lubrifiants industriels, KIT s’avère souvent être le meilleur choix en termes de rapport prix/vitesse pour les expéditions interurbaines.

Business Lines est un autre acteur majeur sur ce segment, avec plus d'un millier de terminaux et succursales dans toute la Russie. Leur API permet de calculer le coût de livraison aussi bien au terminal qu'à la porte du destinataire, en tenant compte des prestations complémentaires - assurance, emballage rigide, levage au sol.

Lorsque nous avons intégré KIT et Business Lines, nous avons été confrontés au fait que leurs API sont structurées complètement différemment de celles de SDEK ou Boxberry. Ils ont un modèle d'autorisation différent, un format de demande et de réponse différent et une logique différente pour déterminer les terminaux. Mais c’est précisément la valeur d’une interface unique : toutes ces différences sont cachées au sein de classes d’opérateurs spécifiques. De l'extérieur, pour le système de calcul des livraisons, tous les transporteurs se ressemblent : on appelle calculate(), on obtient le prix et le délai. Nous appelons get_terminals() et obtenons une liste des points de retrait. Tout est uniforme, tout est prévisible.

Pour un propriétaire de magasin qui vend des produits lourds, la présence de KIT et Business Lines dans le même plugin où SDEK et Boxberry sont déjà installés n'est pas seulement pratique. Il s’agit d’une expansion de la zone géographique de livraison et d’une réduction des coûts pour l’acheteur final. Parce que pour envoyer une commande de 100 kilogrammes via SDEK, le coût peut être de dix mille roubles et via KIT - trois mille. Et lorsque l'acheteur voit les deux options côte à côte lors du paiement, il fait un choix éclairé et n'a pas l'impression que le magasin essaie de gagner de l'argent sur la livraison.

J'entends souvent des commerçants : "Pourquoi ai-je besoin de KIT ou de Business Lines ? J'ai des petits produits, SDEK et Boxberry suffisent." Et dans la plupart des cas, c’est vrai. Mais voici ce que j'ai remarqué : dès que le magasin commence à s'agrandir et à élargir son assortiment, tôt ou tard apparaissent des produits pour lesquels SDEK et Boxberry ne sont pas le meilleur choix. Et si à ce moment vous disposez déjà d'un plugin prenant en charge KIT et Business Lines, il vous suffit d'obtenir les clés API et de les saisir dans les paramètres. Sinon, vous devez rechercher un nouveau plugin, l’acheter, le configurer, le tester et espérer qu’il n’entrera pas en conflit avec ceux existants.

Mise en cache et performances : faire fonctionner le paiement

J'ai déjà mentionné la mise en cache, mais je souhaite y entrer plus en détail car c'est un sujet critique pour toute boutique en ligne. Chaque requête adressée à l'API d'un opérateur est une requête réseau qui prend entre deux cents millisecondes et deux secondes, selon l'opérateur et l'occupation de ses serveurs. Si vous avez cinq transporteurs connectés et que pour chacun vous devez calculer deux options (coursier et point de retrait), cela fait dix demandes de réseau. De manière cohérente, cela représente dix à vingt secondes d'attente à la caisse. En parallèle, cela prend deux à trois secondes, mais la charge sur votre serveur reste importante.

Notre approche consiste à mettre en cache les résultats des calculs pendant dix minutes (paramètre configurable cache_ttl). La clé du cache est constituée des paramètres de la commande : ville d'expédition, ville de réception, poids, valeur déclarée. Si l'acheteur actualise la page ou passe à nouveau à la caisse avec le même ensemble de produits, les résultats du calcul sont instantanément renvoyés du cache. S'il modifie la quantité de marchandise ou l'adresse de livraison, le cache est invalidé et le calcul est refait.

Dix minutes constituent un compromis raisonnable entre la pertinence des données et les performances. Les tarifs des entreprises de transport ne changent pas à chaque minute. Ils peuvent changer une fois par jour, une fois par semaine ou une fois par mois. Un cache de dix minutes garantit que l'acheteur reçoit le prix actuel, mais le paiement ne sera pas ralenti en raison de requêtes redondantes adressées à l'API.

Il existe un autre aspect lié à la performance auquel peu de gens pensent. Lorsque vous utilisez cinq plugins de livraison distincts, chacun d'eux inclut ses propres classes PHP, ses propres hooks WordPress, ses propres gestionnaires AJAX. Il s'agit d'une charge supplémentaire sur le serveur à chaque demande, même si l'acheteur n'est pas sur la page de paiement. Dans notre plugin, tous les transporteurs sont des classes PHP légères qui sont chargées et initialisées uniquement lorsqu'elles sont réellement nécessaires, c'est-à-dire lors du calcul de la livraison. Ils n'ajoutent pas de hooks à chaque page du site, ni n'incluent de scripts sur les pages où la livraison n'est pas nécessaire.

Qu'est-ce que tout cela signifie pour votre entreprise ?

J'ai commencé cet article par l'histoire d'un propriétaire de magasin de lubrifiants et je souhaite y revenir. Après être passé de cinq plugins distincts à notre module de livraison, plusieurs choses se sont produites. Les économies sur les abonnements s'élevaient à environ trente mille roubles par an. Le temps de chargement de la caisse a été réduit de cinq secondes à une heure et demie. Le nombre d'appels d'assistance concernant la livraison a diminué de quarante pour cent. Et - peut-être plus important encore - il ne craint plus les mises à jour de WordPress, car il dispose désormais d'un plugin au lieu de cinq, et une seule équipe est responsable de sa compatibilité, au lieu de cinq développeurs différents.

Mais je ne veux pas donner l'impression que notre solution est parfaite pour tout le monde. Si vous avez un petit magasin avec une vingtaine de commandes par mois et que le seul transporteur est SDEK, un plugin gratuit pour SDEK vous suffira probablement. Notre module de livraison prend tout son sens lorsque vous avez plusieurs transporteurs, plusieurs entrepôts d'expédition, lorsque la rapidité d'encaissement et l'uniformité de l'expérience client sont importantes pour vous. Lorsque vous avez besoin d'une intégration avec 1C pour synchroniser les statuts. Lorsque vous vendez à la fois des produits légers (SDEK, Boxberry, Russian Post) et des produits lourds (KIT, Business Lines) - et que vous souhaitez que tout fonctionne comme un mécanisme unique.

Il y a un autre argument auquel j'ai réfléchi récemment. Le marché des services de transport en Russie est en train de changer. De nouveaux transporteurs apparaissent, d'anciens changent de conditions, certains quittent certaines régions. Lorsque vous disposez d’une architecture d’interface à opérateur unique, l’adaptation à ces changements est rapide et simple. Besoin d'ajouter un nouveau transporteur ? Créez une nouvelle classe qui implémente CarrierInterface. Besoin de désactiver l'opérateur ? Nous supprimons ses clés API des paramètres et elles cessent simplement d'être affichées à la caisse. Besoin de mettre à jour votre intégration avec un opérateur qui a modifié son API ? Nous mettons à jour une classe et laissons le reste tranquille. C'est une flexibilité que vous ne pouvez pas obtenir avec un tas de plugins disparates.

J'ai longuement débattu de l'opportunité d'écrire cet article car le sujet de la livraison me semble ennuyeux. Il ne s’agit pas d’intelligence artificielle, ni de blockchain, ni d’une technologie sophistiquée. Mais vous savez quoi : la livraison affecte directement l’argent. Pour la conversion en caisse, pour les coûts de support, pour la fidélisation des clients, pour l'évolutivité de l'entreprise. Et lorsque vous trouvez une solution qui rend la livraison plus facile, plus rapide et moins chère, cela peut ne pas paraître si agréable lors d'une conférence, mais c'est exactement ce dont les vraies entreprises ont besoin.

Nous continuons à développer le module de livraison. Les plans incluent l'élargissement de la liste des transporteurs, une intégration plus approfondie avec l'API pour la création automatique de demandes et une carte interactive avec un affichage visuel de tous les points de retrait à la caisse. Mais déjà, ce dont nous disposons - cinq transporteurs, une interface unique, des adresses FIAS, une matrice de paiement, un suivi et une intégration avec 1C - couvre les besoins de la grande majorité des magasins WooCommerce en Russie.

Une dernière chose. On me dit souvent : « Tout en un, ça veut dire que si le plugin casse, tout casse. » Une préoccupation légitime. Mais soyons honnêtes : si vous disposez de cinq plugins distincts et que l’un d’eux est en panne, une partie de votre paiement est également en panne. Et si deux sur cinq sont cassés, vous cherchez toujours frénétiquement une solution. La différence est qu’avec un plugin, vous disposez d’une équipe d’assistance, d’un canal de commentaires et d’un processus de mise à jour. Et si quelque chose ne va pas, vous savez vers qui vous tourner. Au lieu de déterminer lequel des cinq plugins est responsable du conflit, vous nous écrivez et nous résoudrons le problème. Ce n’est pas un monde parfait, mais c’est un monde où les problèmes sont résolus plus rapidement.

Essayez COS WP Woo - 14 jours gratuits. Un plugin au lieu de cinq pour la livraison, plus une quarantaine de modules supplémentaires pour votre boutique WooCommerce. Connectez SDEK, Boxberry, Business Lines, Russian Post et KIT en une soirée, pas en une semaine. Installez-le une fois et oubliez le casse-tête de la livraison.