The Good Part

Introduction

Dans la livraison d’appareils électroménagers, le succès n’est pas quelque chose que le client remarque, mais plutôt l’absence d’échec. Un enregistrement en double, un chauffeur mal attribué, un horodatage désynchronisé avec la réalité : chacun représente une fenêtre manquée ou un deuxième déplacement. Les opérations de The Good Part avaient dépassé leur backend, et les failles commençaient à apparaître. Au cours de ce projet de développement logiciel, nous avons livré :

• Développement backend en Java 17
• Modélisation de base de données en PostgreSQL
• Développement piloté par les tests dans un environnement Dockerisé
• Développement d’API et intégration du déploiement

Défi

The Good Part s’est adressé à Redwerk avec un backend qui avait silencieusement pris du retard par rapport à ses opérations. À mesure que le volume des commandes augmentait, les frictions mineures dans le système interne sont devenues des ralentissements quotidiens pour les répartiteurs, le personnel d’entrepôt et les gestionnaires.

Des doublons de dossiers clients s’étaient accumulés, créant des incohérences entre les commandes et obligeant l’équipe à nettoyer les données manuellement. Les répartiteurs ne pouvaient pas savoir en temps réel quels chauffeurs étaient déjà occupés, ce qui ralentissait et rendait moins précise la planification des itinéraires. Les entrepôts et les filiales n’étaient pas formellement liés dans le modèle de données, de sorte que la coordination logistique reposait sur la mémoire et la communication hors canaux.

De plus, les horodatages n’étaient pas toujours précis, les statuts de commande devaient être mis à jour manuellement après les livraisons, et il n’y avait aucun moyen propre de valider ou de prévisualiser une commande avant de la soumettre au système. Chacun de ces problèmes était mineur en soi. Cependant, ensemble, ils signifiaient plus de travail manuel, des délais plus longs et moins de confiance dans les données. L’équipe avait besoin d’un engagement ciblé pour résoudre rapidement les problèmes les plus impactants sans reconstruire l’ensemble du système ni perturber les opérations quotidiennes.

Solution

Nous avons abordé un périmètre restreint et ciblé, et avons livré sept améliorations backend dans un délai serré. La base de code est écrite en Java 17, avec un style fonctionnel construit autour de la Stream API. Notre équipe de développement a respecté ce standard, sans exception, de sorte que le nouveau code s’intègre au reste du système au lieu de paraître comme le travail d’une autre personne.

Chaque fonctionnalité a été livrée avec ses propres tests unitaires et d’intégration afin de respecter les normes élevées du client en matière de développement piloté par les tests. Les tests s’exécutent dans un environnement Docker qui lance une instance PostgreSQL réelle, nous validons ainsi par rapport au moteur de base de données réel sur lequel le système fonctionne, et non une simulation. Les déploiements sont effectués via un pipeline GitHub Actions Build–Push–Deploy, avec des environnements de staging et de production comme cibles distinctes, ce qui maintient la rapidité et la prévisibilité des mises en production.

Voici ce que nous avons livré :

• Gestion des doublons de clients : Mise en place de la détection automatique des enregistrements clients dupliqués, d’un étiquetage clair dans l’interface utilisateur et d’un flux de résolution qui permet au personnel de fusionner ou de rejeter les doublons en quelques clics. Fini les nettoyages hebdomadaires.
• Gestion des entrepôts : Introduction d’une véritable entité d’entrepôt et modélisation des relations entre les entrepôts et les filiales, de sorte que la coordination logistique repose sur une structure réelle plutôt que sur des connaissances tacites.
• Disponibilité des chauffeurs pour l’affectation : Ajout d’indicateurs en temps réel montrant quels chauffeurs sont déjà occupés lors de la planification des itinéraires. Les répartiteurs peuvent désormais construire des itinéraires sans avoir à basculer entre les écrans ni à faire des suppositions.
• Automatisation du cycle de vie des commandes : Les livraisons complétées mettent désormais à jour leur statut automatiquement, supprimant une étape manuelle qui auparavant créait un goulot d’étranglement pour les rapports de fin de journée.
• Corrections de l’exactitude des horodatages : Recherche et correction des bugs d’horodatage qui rendaient le suivi des commandes peu fiable.
• Point d’API pour la prévisualisation des commandes : Ajout d’un point d’API backend qui permet à l’équipe d’examiner et de valider les données de commande avant qu’elles ne soient validées, de sorte que les erreurs soient détectées avant de devenir des problèmes pour les clients.
• Intégration du code et support des pull requests : Travail au sein du référentiel existant du client et de son processus de revue, de sorte que chaque modification a été fusionnée proprement sans surcharge d’intégration supplémentaire de leur côté.

Toutes les fonctionnalités ont été livrées entièrement testées et intégrées au système en cours de fonctionnement.