Expériences

Construire le parcours de retour en ligne

Du besoin à une solution réalisable

Carter-Cash souhaitait permettre à ses clients d’effectuer leurs retours en ligne. Le besoin initial définissait l’objectif et envisageait l’utilisation d’un outil logistique, mais le parcours, ses règles et sa faisabilité technique restaient encore à préciser.

En collaboration avec la cheffe de projet côté Carter-Cash, relais du métier et du service client, j’ai exploré l’API Woop et confronté les premières intentions aux contraintes du site. J’ai identifié ce qui était réalisable, proposé les adaptations nécessaires et complété les règles de gestion avant de concevoir et développer le parcours web.

Rendre simples des retours complexes

Dans le cadre d’un retour, une commande ne correspondait pas toujours à une seule livraison. Les produits pouvaient être expédiés séparément, reçus à des dates différentes ou répartis entre plusieurs colis. Les règles variaient également selon que le client souhaitait effectuer son retour à distance ou directement en magasin.

J’ai traduit ces situations en un parcours capable d’identifier les produits éligibles, de les regrouper selon leur livraison d’origine et de créer autant de retours et d’étiquettes que nécessaire. L’interface adapte chaque étape au choix du client : la sélection d’un magasin apparaît uniquement pour un retour en magasin, tandis que les contraintes liées aux livraisons partielles et aux commandes multi-colis restent prises en charge par le système.

Un même service, quel que soit le point d’entrée

Le parcours de retour en ligne ne pouvait pas répondre à toutes les situations. Un client pouvait rencontrer un problème sur le site ou avoir besoin d’être accompagné directement par le service client pour créer son retour.

Dans une évolution ultérieure, j’ai conçu des API dédiées à l’outil interne utilisé par les conseillers. Elles permettent de consulter les informations nécessaires et de créer un retour depuis leur propre interface, en réutilisant les services et les règles métier du parcours web. Client et conseiller suivent donc les mêmes règles, même si le retour n’est pas créé depuis la même interface.

Une responsabilité jusqu’en production

J’ai accompagné les évolutions du parcours de retour jusqu’à leur mise en service : préparation des jeux et cahiers de tests, recette côté client et service client, vérification des échanges avec les systèmes concernés et suivi de la mise en production.

Une fois la solution en ligne, les incidents et demandes d’évolution liés aux retours m’étaient systématiquement confiés. J’en analysais les causes, réalisais les corrections nécessaires et adaptais les règles en collaboration avec la gestion de projet Carter-Cash. Je suis ainsi resté le référent technique de ce périmètre jusqu’à mon départ.

Relier les commandes à Datahub

Transformer un besoin d’échange en solution technique

Carter-Cash souhaitait transmettre ses commandes à Datahub. Derrière cet objectif se trouvait un ensemble de données réparties dans le modèle existant : commande, expéditions, client, magasin, produits, tarifs, historique et modes de livraison.

J’ai analysé ces différentes sources, identifié les informations nécessaires et défini leur transformation vers le format attendu par Datahub. J’ai ensuite conçu le parcours complet de l’échange, depuis l’événement déclencheur dans la vie de la commande jusqu’à la construction et à l’envoi authentifié des données.

Faire circuler les données sans bloquer l’application

L’envoi vers Datahub ne devait pas être exécuté directement pendant une action utilisateur ou une transition métier importante. Une réponse lente ou une indisponibilité du service externe aurait alors pu bloquer inutilement le fonctionnement du site.

J’ai choisi une architecture asynchrone basée sur Symfony Messenger. Lorsqu’une commande atteint l’état concerné, un message est placé dans une file dédiée. Un worker le traite ensuite indépendamment, recharge les informations nécessaires et effectue l’envoi vers Datahub. L’action qui a déclenché l’échange peut donc se terminer normalement, même si le service externe répond lentement ou devient indisponible.

Ne jamais laisser un flux échouer silencieusement

Un envoi asynchrone vers Datahub peut échouer loin du parcours de commande qui l’a déclenché. Sans mécanisme dédié, les données d’une commande pourraient ne jamais parvenir au service sans que l’erreur soit immédiatement visible ou facilement reproductible.

J’ai mis en place un suivi persistant des échecs pour chaque expédition concernée : statut retourné, nombre de tentatives et date du dernier essai. Des logs dédiés conservent également l’origine du déclenchement et le contexte utile au diagnostic. Lorsqu’un nouvel envoi aboutit, l’échec précédemment enregistré est automatiquement levé.

Rendre les intégrations visibles et actionnables

Le suivi des envois vers Datahub ne pouvait pas reposer uniquement sur des logs : leur consultation serait restée réservée aux développeurs et les incidents auraient été difficiles à retrouver dans la durée. J’ai donc proposé une interface dédiée dans le back-office, où les traitements en échec deviennent directement visibles.

Cette vue rassemble les informations utiles au diagnostic : commande concernée, expédition, statut, nombre d’échecs et dernier essai. Une action permet de relancer manuellement l’envoi en réutilisant le même service que le traitement automatique. En cas de succès, l’erreur disparaît ; sinon, son suivi est actualisé.

Reprendre l’authentification et réconcilier les comptes

Devenir référent d’un système existant

Auth0 assurait déjà l’authentification des clients lorsque j’ai rejoint le projet. Je n’avais pas participé à sa mise en place initiale, mais les incidents liés aux comptes et à la connexion m’ont progressivement amené à intervenir régulièrement sur ce périmètre.

J’utilisais la console Auth0 pour examiner les identités, comprendre les blocages et débloquer les situations rencontrées par les utilisateurs. À force de prendre en charge ces demandes et de relier le comportement du service à celui de l’application Symfony, j’en suis devenu le référent opérationnel au sein de l’équipe.

Reprendre et finaliser l’intégration Symfony

À la suite de plusieurs sujets de sécurité, l’équipe avait décidé d’intégrer le bundle Symfony officiel d’Auth0. Un autre développeur avait commencé ce chantier, mais son départ a laissé une première version encore incomplète et partiellement adaptée au fonctionnement du site.

J’ai repris cette base, identifié les parcours et cas particuliers restant à traiter, puis adapté l’intégration au socle existant. J’ai complété les éléments manquants, supprimé les anciens mécanismes devenus inutiles et mené le chantier jusqu’à sa version finale, prête à être déployée.

Sécuriser la création et le cycle de vie des comptes

Ajouter une règle de sécurité à l’authentification ne concernait jamais uniquement la connexion. La validation des comptes, par exemple, pouvait affecter les clients historiques, le parcours après inscription, les messages d’erreur ou encore le renvoi des communications nécessaires.

J’ai étudié ces impacts et formalisé les décisions métier à prendre avant l’activation de nouvelles protections. J’ai ensuite développé les actions et triggers Auth0 ainsi que les points d’entrée Symfony nécessaires aux contrôles retenus lors de l’inscription. J’ai également adapté la gestion des sessions et de la déconnexion afin de conserver un cycle de vie cohérent entre Auth0 et l’application.

Réconcilier les identités sans perdre leur historique

L’évolution de l’authentification nécessitait de traiter des clients possédant plusieurs comptes pour une même identité. Une simple suppression aurait fait disparaître une partie de leur historique ou laissé des relations incohérentes entre l’application et Auth0.

J’ai conçu et développé un traitement capable de détecter les doublons, de sélectionner le compte principal selon son activité et d’y transférer les commandes, paniers, adresses, véhicules et préférences utiles. Les comptes devenus inutiles sont ensuite supprimés localement et dans Auth0 lorsque nécessaire. Des verrous, limites d’exécution, journaux dédiés et synthèses permettent de contrôler chaque fusion.

Retrouver son panier entre appareils

Retrouver son panier, quel que soit l’appareil

À l’origine, le panier reposait principalement sur la session du navigateur. Après une période d’inactivité, une reconnexion ou le passage sur un autre appareil, un client pouvait perdre son panier en cours et devoir recommencer son parcours.

J’ai refondu son initialisation afin de ne plus dépendre uniquement de cette session. Lorsqu’un client se connecte, le système peut retrouver son dernier panier encore valide dans la base de données et le réinjecter dans son parcours. Si aucun panier ne peut être repris, un nouveau panier est créé selon le contexte de l’utilisateur.

Réconcilier panier, identité et magasin

Lors d’une connexion, plusieurs états pouvaient se rencontrer : un panier anonyme déjà présent dans la session, un ancien panier encore actif dans la base de données ou un magasin différent de celui précédemment associé au client. Les comptes vendeurs nécessitaient également un comportement distinct de celui des clients classiques.

J’ai structuré les règles permettant d’arbitrer ces situations. Un panier anonyme peut être rattaché au client qui vient de se connecter ; en son absence, le dernier panier valide est recherché. Le magasin du panier et celui de la session sont ensuite synchronisés selon le contexte. Un client retrouve ainsi son environnement d’achat, tandis que les usages vendeurs restent isolés dans un panier dédié.

Comprendre les parcours entre appareils

La continuité du panier permettait au client de poursuivre son achat, mais elle ouvrait également une nouvelle question : comprendre comment un parcours commencé sur mobile, desktop ou tablette évoluait jusqu’à la commande.

J’ai conçu un suivi des appareils utilisés aux moments clés du panier : création, changement d’appareil, entrée dans le paiement et finalisation. Des règles garantissent que seules les transitions cohérentes sont conservées, puis une vue agrégée permet d’analyser les principaux parcours entre appareils. J’ai accompagné cette fonctionnalité jusqu’à sa mise en production.

Faire évoluer la recherche et la disponibilité

Aider le client à trouver le bon produit

Choisir un pneu ne repose pas uniquement sur ses dimensions. Les indices de charge et de vitesse, la saison ou encore la technologie Runflat déterminent les produits compatibles, avec des règles différentes entre pneus été, hiver et quatre saisons.

Dans le cadre d’une évolution menée en équipe, j’ai contribué à traduire ces règles en filtres Algolia : comparaison des indices, adaptation des critères selon la saison et gestion des produits compatibles malgré certaines différences avec la recherche initiale. J’ai également travaillé sur les informations affichées pour expliquer ces écarts, puis vérifié la cohérence des résultats à l’aide de requêtes Algolia et d’un cahier de tests fonctionnels.

Afficher une disponibilité cohérente

Sur un site relié à des magasins et à plusieurs sources d’approvisionnement, la disponibilité ne se résume pas à une quantité en stock. Elle dépend notamment du magasin sélectionné, des possibilités de commande, des caractéristiques du produit et du choix entre retrait et livraison.

J’ai contribué à faire évoluer ces règles et leur affichage dans les différentes étapes du parcours. J’ai adapté l’utilisation des nouvelles données de stock, de prix et de disponibilité fournies par Algolia. Sur une évolution ultérieure, j’ai également centralisé dans un service Symfony les modes de livraison réellement autorisés et ajouté leur validation côté serveur, afin de conserver des choix cohérents jusqu’au panier.

Faire évoluer un catalogue historique

Le catalogue s’était construit au fil des années autour de plusieurs sources. Selon le type de produit, le pays ou l’écran consulté, les informations pouvaient provenir d’Algolia, de services catalogue externes ou de la base de données. Une évolution d’attribut pouvait donc affecter la recherche, les prix, la disponibilité, le suivi analytique ou l’affichage final.

Mes interventions consistaient souvent à reprendre une évolution déjà engagée, identifier ses répercussions dans le code et adapter les différentes couches concernées. J’ai notamment travaillé sur de nouveaux attributs Algolia, les comportements propres aux différents pays, les tris et la pagination, les messages de disponibilité et les valeurs de repli lorsque certaines données manquaient. Chaque modification demandait donc de vérifier plusieurs sources et plusieurs écrans, pas seulement l’endroit où le besoin avait été signalé.

Anticiper les problèmes de fiabilité

Anticiper un risque avant qu’il ne devienne un incident

Les références des commandes, expéditions et produits reposaient sur une portion d’identifiants globaux. Avec l’augmentation du volume, ce mécanisme pouvait réutiliser une ancienne valeur et provoquer une collision. Un correctif temporaire avait repoussé le problème sans supprimer sa cause.

À partir d’une question soulevée en daily, j’ai analysé le fonctionnement existant et les nombreuses briques dépendantes de ces références. J’ai comparé plusieurs stratégies, présenté leurs compromis puis recommandé une architecture fondée sur des compteurs dédiés par magasin, usage et période. Après validation, j’ai réalisé la solution retenue avec les protections nécessaires contre les créations concurrentes.

Entretenir les données avant qu’elles ne s’accumulent

J’ai constaté que de nombreux paniers devenus inutiles restaient durablement en base de données. J’ai fait remonter ce constat puis proposé et conçu leur nettoyage, sans demande initiale du client. J’ai ensuite conçu un dispositif comparable pour traiter un besoin récurrent concernant les anciennes redirections.

Les deux traitements distinguent les données encore utiles de celles qui peuvent être supprimées, puis interviennent par lots afin de limiter leur impact. Verrous, durées maximales, logs, historiques et synthèses par email permettent de suivre chaque exécution, tandis qu’une planification automatise leur entretien dans la durée.

Faire de la non-régression une responsabilité

Sur une plateforme e-commerce, une régression peut empêcher une recherche, une connexion ou une commande d’aboutir. Les règles étant nombreuses et souvent liées entre elles, la vérification du comportement faisait partie intégrante de mes développements.

Je préparais des cahiers de tests détaillés, réalisais les recettes fonctionnelles et ajoutais des tests PHPUnit sur les services et règles métier sensibles. Avec Vincent, j’ai également participé à la création d’un projet Cypress couvrant de nombreux parcours end-to-end. Cette expérimentation était lancée manuellement selon les besoins ; elle ne constituait pas encore une chaîne de tests systématique ou entièrement automatisée.