Étude de cas · Développeur Go
Reconstruire en Go le service de codes promotionnels d'une plateforme e-commerce
Une ETI du e-commerce fait évoluer son backend vers des microservices et souhaite confier la gestion de ses codes promotionnels à un nouveau service écrit en Go. Nous avons présenté un développeur senior Go qui a conçu l'architecture du service, l'a développé jusqu'à la mise en production en parallèle de l'ancien système, et a livré à l'équipe backend un guide de bonnes pratiques et des bibliothèques partagées.
Par L'équipe Top Profil · Mis à jour le · 7 min de lecture
01
Le contexte
L'entreprise, une ETI du e-commerce, exploite une plateforme dont le backend historique, écrit en Python, est progressivement découpé en microservices. La gestion des codes promotionnels, de la création des campagnes à la validation au moment du panier, vivait encore dans le système existant. L'équipe backend souhaitait en faire un service autonome, écrit en Go, un langage que l'entreprise commençait à adopter sans disposer encore de conventions communes.
La commande portait sur un périmètre précis : concevoir et documenter l'architecture du service, le développer avec un code versionné et des tests unitaires, le rendre observable (métriques, traces, tableaux de bord, alertes), optimiser ses performances, puis livrer un guide de bonnes pratiques Go et animer des sessions de formation pour l'équipe backend.
Nous avons présenté un développeur senior Go, évalué sur ces sujets et sur son usage des assistants de code. La mission a démarré à temps plein, avec une période d'intégration dans les locaux de l'équipe, et se poursuit à ce jour.
02
Les enjeux
Technique : remplacer sans régression
Le service de codes promotionnels intervient au moment de la validation du panier : toute erreur de calcul de remise ou toute indisponibilité se voit immédiatement. Le nouveau service devait reproduire le comportement existant sans interruption pour les utilisateurs.
Organisationnel : installer Go dans l'équipe
Go était un langage encore récent dans l'entreprise. Au-delà du service, l'équipe attendait des conventions, une structure de projet et des bibliothèques réutilisables pour les services suivants.
Intégration : s'insérer dans l'écosystème existant
Le service devait dialoguer avec les services de gestion des commandes, le back-office et l'ancien système, par API et par événements, en respectant l'authentification entre services déjà en place.
Qualité : observabilité et traçabilité
Métriques, traces, journaux d'audit et alertes faisaient partie de la commande dès le départ, afin que le service soit exploitable par l'équipe sans dépendre du freelance.
03
La démarche
Six étapes, dans l'ordre de la mission.
- 01
Comprendre l'existant et poser les fondations
Les premières semaines ont été consacrées à la découverte des projets et des équipes, conclues par un rapport d'étonnement sur l'usage de Go dans l'entreprise. Le freelance a ensuite rédigé une documentation des bonnes pratiques Go nourrie de ces retours, puis conçu l'architecture hexagonale du service, avec injection de dépendances idiomatique et configuration gérée par Viper. Les mauvaises pratiques identifiées dans le code initial ont été corrigées dans la foulée.
- 02
Modèle de données et premières routes
Le modèle de données des codes promotionnels a été spécifié, y compris les codes de type bon d'achat, et les premières routes développées avec leur documentation API : mise à jour de campagne, création et listing de codes. Un middleware d'authentification extrait les données utilisateur d'un jeton JWT. L'outil Atlas a été évalué puis déployé pour gérer les schémas de base de données et générer les migrations.
- 03
Enrichir, fiabiliser, refactorer
Le service a gagné la création par lot, la modification de statut et la configuration. Les revues de code ont fait remonter des corrections : conditions de concurrence, problèmes d'authentification, champs superflus. Le service a été refactoré, avec suppression des routes de proxy inutilisées, refonte de l'authentification et unification du modèle de données. La création par lot a ensuite été optimisée pour réduire son temps de traitement, et la pagination refondue.
- 04
Événements asynchrones et traçabilité
Watermill et RabbitMQ ont été intégrés pour l'exécution de jobs asynchrones, puis un système de publication et de souscription d'événements fondé sur Kafka et le format CloudEvents a été mis en place, avec correction de la configuration OpenTelemetry pour propager les traces dans les événements. Des journaux d'audit couvrent l'ensemble des routes sensibles. Le framework Gin a été décommissionné. Ce travail a donné naissance à une bibliothèque Pub/Sub partagée, publiée dans une première version et réutilisable par les autres services.
- 05
Validation au panier et bascule progressive
L'API de validation de code promotionnel a été développée et mise en production, avec logique de panier, calcul de la remise, détail par ligne et intégration aux services de gestion des commandes, sous authentification entre services. Les codes existants ont été importés par lot depuis l'ancien système, puis les modifications propagées en continu vers celui-ci. Les métriques de l'ancien système ont été reprises et complétées pour comparer les deux implémentations pendant une période de double exécution, suivie sur un tableau de bord dédié.
- 06
Mise en production et transmission
La double exécution a été mise en production et surveillée, les écarts analysés et corrigés, y compris sur les codes de parrainage. En parallèle, le freelance a animé les échanges entre équipes sur la structure des projets Go, enrichi la documentation du service et de l'outil Atlas, ajouté des exemples à la bibliothèque Pub/Sub, puis entamé le portage en Go d'une bibliothèque de messagerie existante en Python.
04 · IA
L'IA dans la mission
L'IA a trouvé ici un usage précis : lors du refactoring de l'architecture et des tests, le freelance a rédigé des instructions de revue de code pour GitHub Copilot, afin que l'assistant applique les conventions du projet lors des revues de demandes de fusion.
Avant de le présenter, nous avions évalué ce profil sur sa pratique de l'IA, critère éliminatoire chez nous : les tâches qu'il confie à un assistant de code, la manière dont il les spécifie, et surtout ce qu'il vérifie et corrige dans ce qui est produit. Cette exigence de contrôle se retrouve dans la mission, où la revue de code humaine reste la règle.
05
Les résultats
- Le nouveau service de codes promotionnels est en production, en double exécution avec l'ancien système, avec un tableau de bord de comparaison et des alertes.
- L'API de validation au panier, avec calcul de la remise et détail par ligne, est intégrée aux services de gestion des commandes.
- Le service est observable de bout en bout : métriques, traces OpenTelemetry propagées dans les événements, journaux d'audit sur les routes sensibles.
- Une bibliothèque Pub/Sub partagée pour les événements Kafka au format CloudEvents, documentée avec des exemples, est réutilisable par les autres services Go de l'équipe.
- Les schémas de base de données sont gérés par Atlas, avec des migrations générées et documentées.
- L'équipe dispose d'un guide de bonnes pratiques Go, d'une structure de projet partagée entre équipes et d'une documentation à jour du service.
FAQ
Vos questions sur cette mission
Le choix de Go était celui du client, qui l'adoptait pour ses nouveaux services. Le risque ne tenait pas au langage mais à l'absence de conventions partagées. C'est pourquoi la commande incluait, au-delà du service, un guide de bonnes pratiques et des sessions de transmission à l'équipe.
Par une période de double exécution : le nouveau service traite les mêmes demandes que l'ancien, les métriques des deux sont comparées sur un tableau de bord, et chaque écart est analysé avant la bascule définitive. Cela suppose d'avoir importé les données existantes et de maintenir une synchronisation tant que les deux systèmes coexistent.
Un développeur senior Go à l'aise avec l'architecture hexagonale, l'observabilité (OpenTelemetry, métriques, traces) et la messagerie asynchrone (Kafka, RabbitMQ), capable d'écrire une documentation que l'équipe s'approprie. L'autonomie compte autant que la technique : sur cette mission, le freelance a porté la conception, la feuille de route du service et la transmission.
Sur cette mission à temps plein, l'API de validation est entrée en production en quelques mois et la double exécution complète a suivi avant la fin de la première année. Nous présentons 1 ou 2 profils évalués en moins de 48h ; le démarrage dépend ensuite de la disponibilité du freelance, en général de quelques jours à trois semaines.
Par un entretien technique sur des situations vécues : une décision d'architecture et ses compromis, un incident de production, une revue de code. Nous avons aussi examiné sa pratique de l'IA, en lui demandant de décrire une tâche confiée à un assistant, la façon dont il l'avait cadrée et ce qu'il avait dû corriger. Un seul interlocuteur porte ensuite le cadre contractuel et la facturation.
Étude rédigée par L'équipe Top Profil.
Publiée le , mise à jour le .
Un besoin proche de cette mission ?
Précisez votre contexte. Un expert Top Profil vous rappelle sous 1 jour ouvré.