Le seuil
Nautes Logistics opérait sur un back-office écrit en 2014. La facturation tournait. Les rapports tournaient. Mais chaque modification métier prenait deux semaines de développement, et l'équipe opérations passait quatre heures par jour à recopier des données entre trois écrans.
Le client ne voulait pas reconstruire pour reconstruire. Il voulait que la même équipe traite trois fois le volume, sans embaucher.
L'approche
On a démarré par une lecture de code avec le CTO et la responsable opérations. Deux conclusions :
- Le moteur métier (calcul des tarifs, validation des bordereaux) était sain. Pas touche.
- La couche d'interface et le module d'intégration EDI étaient le point de douleur.
Décision : remplacer ces deux couches, garder le moteur, brancher dessus via une API interne stable.
Le travail
- Semaine 1–2. Cartographie des flux, contrat d'API entre l'ancien moteur et la nouvelle interface. Mise en place du double-run (l'ancien système continue, le nouveau lit en lecture seule).
- Semaine 3–4. Construction de la nouvelle interface (Next.js + Postgres en lecture). Adoption par un opérateur volontaire pendant 5 jours, retour quotidien, ajustements.
- Semaine 5. Bascule en écriture par lot — un type de bordereau à la fois, avec rollback prêt.
- Semaine 6. Décommissionnement de l'ancien front. Le moteur métier, lui, n'a pas bougé.
Ce qui a changé
"On savait qu'on devait moderniser. On ne savait pas qu'on pouvait le faire sans perdre une journée d'opérations." — Aïcha, responsable opérations
Le temps de saisie d'un bordereau est passé de 11 minutes à 3,5. Le volume traité par opérateur a triplé sans augmenter l'effectif. Aucune interruption métier pendant les 6 semaines.
→ TRANSFORMER, dans son intention exacte : franchir un seuil opérationnel sans casser ce qui fonctionne.