Remettre en production un tunnel de réservation bloqué

Situation initiale

Un distributeur souhaitait proposer des réservations de transport depuis son propre parcours client. Un premier développement avait été commencé autour d’une plateforme de réservation tierce, mais il n’avait jamais atteint la production.

Le code avait été regroupé dans un fichier principal, avec peu de séparation entre l’interface, les appels API et les règles métier. Chaque correction risquait d’en casser une autre. Le projet semblait proche de la fin visuellement, mais il n’était ni maintenable ni déployable de manière fiable.

Précision sur la référence

La plateforme de transport était un service intégré au projet. Elle n’était pas notre client. Le donneur d’ordre reste volontairement anonyme.

Les risques identifiés

• appels API difficiles à isoler et à tester ;
• gestion d’erreurs insuffisante pour un tunnel de réservation ;
• code fortement couplé ;
• absence de procédure de déploiement reproductible ;
• comportement incertain en cas d’indisponibilité du fournisseur ;
• manque de visibilité sur les étapes réellement terminées.

Notre méthode

Audit avant modification

Nous avons relu le parcours complet, inventorié les appels externes et distingué les défauts bloquant la mise en production des améliorations pouvant attendre.

Refactoring ciblé

Le code a été séparé par responsabilité : accès au fournisseur, règles de réservation, présentation et traitement des erreurs. Le but n’était pas de réécrire pour obtenir une architecture idéale, mais de rendre les changements vérifiables.

Sécurisation du tunnel

Les retours incomplets, délais de réponse et erreurs du service tiers ont été traités explicitement. Les données nécessaires au diagnostic d’un incident ont été journalisées sans exposer d’informations sensibles.

Préparation de la production

La configuration, les secrets et les étapes de déploiement ont été sortis du poste du développeur. Une procédure de mise en ligne et de vérification a été définie, accompagnée d’un suivi du run après déploiement.

Résultat

Le client a récupéré une base de code structurée, un tunnel pouvant être déployé et une méthode pour suivre les erreurs d’intégration. Le projet a quitté l’état de développement inachevé pour entrer dans une logique de production et de maintenance.

Nous ne publions ni volume de réservations, ni taux de conversion, ni disponibilité contractuelle : ces informations ne nous ont pas été autorisées.

Enseignement

Un projet bloqué à quelques semaines de la mise en ligne n’est pas forcément « presque fini ». La qualité des appels externes, la gestion des erreurs et le déploiement font partie du produit.

Notre offre de reprise commence par vérifier ce qui peut être conservé. Un diagnostic IT permet ensuite de décider entre correction, refactoring ciblé ou remplacement.