Aller au contenu principal
TL
Illustration du portail de commandes B2B

Portail de commandes B2B

Sortir les commandes d'un Excel interne pour en ouvrir la saisie aux clients.

Rôle

Lead technique

Période

Stack technique
  • React
  • TypeScript
  • NestJS
  • MySQL
  • TypeORM
  • TanStack Query
  • Azure
commandes par campagne
1 000+
utilisateurs
~100
jusqu'à la v1.0
5 mois
01

Le contexte

  • L'équipe interne gère seule les engagements de campagne, les commandes et le planning de livraison, dans Excel.
  • Ses données commerciales vivent déjà dans un ERP, qu'il n'est pas question de remplacer.
  • Le portail ouvre la saisie à plus de cent clients, qui n'accèdent qu'à leurs propres données.
02

Ma mission

  • Choix de la stack et conception des besoins d'infrastructure sur Azure.
  • Rédaction du dossier d'architecture technique.
  • Implémentation de l'intégralité du backend.
  • Chaîne de livraison sur Azure DevOps : build, quality gate SonarQube et absence de vulnérabilité critique conditionnent le déploiement.
  • Encadrement du développeur frontend et définition des conventions communes aux deux applications.
  • Interlocuteur technique du client : alignement des spécifications et chiffrage des évolutions.
03

Décisions et arbitrages

  1. 01

    Livrer par incréments plutôt qu'en une fois

    Problème

    Le client attend un produit abouti et fait évoluer ses demandes en continu, pendant que la synchronisation ERP prend du retard.

    Solution

    Redécoupage du backlog pour mettre en production les fonctionnalités déjà prêtes.

    Pourquoi ce choix

    Les demandes ne se stabilisent qu'à partir du moment où le client utilise le produit.

  2. 02

    Développer la synchronisation avant l'API

    Problème

    L'API de l'équipe ERP arrive avec deux mois de retard. La synchronisation en dépend, avec sa logique de transaction et de résolution des conflits.

    Solution

    Développement et tests contre le contrat d'interface, avec des jeux de données produits pour l'occasion. La fonctionnalité reste désactivée en production jusqu'à la livraison de l'API.

    Pourquoi ce choix

    Le contrat est disponible et figé. Attendre immobilise la partie la plus complexe du backend sur une dépendance externe.

  3. 03

    Une reprise pilotée plutôt qu'automatique

    Problème

    La synchronisation échoue de deux façons : la récupération des données depuis l'ERP, et l'envoi vers l'ERP qui expire quand celui-ci met trop de temps à répondre.

    Solution

    En entrée, aucun retry automatique : l'administrateur voit le statut par catégorie et relance seulement celle qui a échoué. En sortie, une icône signale l'échec et une file interne rejoue une fois les envois expirés.

    Pourquoi ce choix

    L'administrateur relance quand il a besoin de données à jour, là où un retry aveugle resynchroniserait sans qu'on l'ait demandé. Sur les envois, un seul rejeu absorbe environ 90 % des erreurs rencontrées.

  4. 04

    Écarter Next.js au profit d'un backend autonome

    Problème

    L'équipe maintient du Go, du C# et du JavaScript. Le choix doit rester tenable par elle sur la durée. Next.js est proposé pour couvrir le front et le back d'un seul tenant.

    Solution

    Front React séparé, backend NestJS autonome.

    Pourquoi ce choix

    La synchronisation ERP repose sur un cron porté par l'application, et une évolution prévue demande des websockets tenus dans la même instance. Le modèle d'exécution de Next.js suppose des requêtes ponctuelles, pas ce type de traitement continu. Un backend autonome rend ce cycle de vie explicite, sans dépendre des contraintes d'une plateforme d'hébergement.

  5. 05

    Une architecture identique sur les deux applications

    Problème

    Deux applications pour un même produit, développées par des personnes différentes.

    Solution

    Même découpage en tranches fonctionnelles des deux côtés. Côté front, cela revient à sortir la logique des composants dans des hooks et à confier l'état serveur à React Query.

    Pourquoi ce choix

    Le périmètre métier se lit dans l'arborescence, et un développeur passe d'une application à l'autre sans se réorienter. Le coût tient dans une montée en compétences du développeur front, sur des pratiques React courantes.

04

Ce que ce projet m'a apporté

  • Encadrement technique d'un développeur sur un projet client, après plusieurs projets internes.
  • Recadrage de la méthode de livraison : passage du déroulé en cascade attendu à des livraisons courtes et incrémentales, face à un besoin mal défini et des requirements mouvants.
  • Gestion d'une dépendance externe bloquante, l'API de l'équipe ERP étant arrivée tard et ayant décalé le planning.
  • Reprise d'un projet chiffré par un tiers, avec l'écart entre l'estimation initiale et le besoin réel.
  • Rédaction de documentation d'architecture à un niveau au-dessus du code.
  • Chiffrage des évolutions, qui impose d'évaluer l'impact de chaque demande sur l'ensemble du projet.
05

Avec le recul

  • Mettre en place une première chaîne de déploiement et une tranche fonctionnelle minimale dès le démarrage, afin de confronter rapidement le produit à son environnement réel.
  • Passer par une séance de maquettage interactif avec un client pour capter le besoin avant le cadrage, plutôt que sur spécification.
Voir d'autres projets