Dans le transport et la travel tech, on ne part presque jamais d’une page blanche. Vous exploitez déjà une plateforme qui vend des billets, planifie des itinéraires ou relie des réservations, et c’est elle qui rapporte l’argent. Le défi n’est donc pas d’écrire une application de zéro mais d’assurer un développement d’applications de transport qui tourne jour et nuit tout en gagnant de nouvelles fonctionnalités chaque trimestre. Si vous êtes CTO, responsable de plateforme ou directeur IT, vous connaissez la tension : le métier veut aller plus vite, pendant que la dette technique et le risque de panne tirent dans l’autre sens.
D’après notre expérience, le plus difficile est de préserver la continuité - ajouter de la valeur sans faire tomber ce qui fonctionne déjà. Pour un fournisseur de technologies pour l’aviation et le voyage, nous faisons exactement cela : nous développons de nouvelles fonctionnalités de ses applications existantes, nous maintenons les systèmes et nous menons des migrations cloud-to-cloud sur Java, microservices et GCP. Voici le détail.
Pourquoi le développement et la maintenance d’applications de transport sont-ils une seule et même chose ?
Parce que dans un produit qui vit des années, on ne peut pas les séparer sans perdre quelque chose. Une équipe qui ne fait qu’« éteindre des incendies » ne saisit jamais vers où va l’architecture. Une équipe qui ne livre que des nouveautés et ignore l’existant vous laisse, un an plus tard, avec une plateforme que personne ne veut toucher.
Nous traitons donc cela comme un seul flux de travail : le développement de nouvelles fonctionnalités et la maintenance des systèmes passent par la même équipe, qui connaît le code, les dépendances et l’histoire des décisions passées. Chaque nouvelle fonctionnalité se branche alors sur l’architecture existante de façon délibérée plutôt qu’en pièce rapportée, et les petites corrections de maintenance deviennent des occasions de rembourser de la dette technique. Dans le transport, où les intégrations avec des systèmes externes sont partout, cette continuité a une valeur particulière.
Comment ajoutons-nous de nouvelles fonctionnalités aux systèmes de transport existants ?
Nous ne réécrivons pas le produit - nous le faisons croître par incréments. Nous entrons dans un code qui tourne, nous en lisons la logique et nous ajoutons des fonctionnalités pour que le reste de la plateforme continue de tourner.
- nous lisons l’architecture et les dépendances existantes avant de changer quoi que ce soit,
- nous concevons chaque nouvelle fonctionnalité comme une partie d’un ensemble plus large, pas comme une île,
- nous protégeons le changement par des tests pour que les régressions ne tuent pas l’existant,
- nous déployons par petits pas, avec la possibilité de revenir en arrière.
Cette approche convient aux produits qui gèrent un trafic réel de passagers ou de réservations et ne peuvent pas être arrêtés une semaine « à cause d’une refonte ».
Comment construisons-nous le backend dans le transport : Java, Spring et microservices ?
Le cœur de la plupart des plateformes de transport est un backend Java. Nous le bâtissons sur Spring et le découpons en microservices, parce que dans ce secteur les différentes parties du système évoluent à des vitesses différentes : le moteur de recherche de correspondances change à un autre rythme que le module de paiement ou l’intégration d’un fournisseur.
Ce découpage nous donne des déploiements indépendants par service, des frontières de responsabilité claires et la capacité de ne faire monter en charge que ce qui est réellement sollicité. Au-dessus se place la couche de données : nous concevons et maintenons les processus ETL/ELT qui alimentent le reporting, l’analytique et les intégrations. Dans le transport, les données sur les itinéraires, les prix et les disponibilités sont un produit en soi ; nous traitons donc leur circulation aussi sérieusement que la logique applicative.
À quoi ressemble un frontend de transport en React et Angular ?
Côté utilisateur, nous travaillons principalement en React et Angular. Le choix dépend du langage dans lequel le produit existant est écrit - nous nous adaptons à la stack du client au lieu d’imposer la nôtre.
Nous développons des interfaces qui doivent porter une vraie complexité : recherche de correspondances, calendriers de disponibilité, panneaux de réservation et vues opérationnelles. Nous veillons à ce que le frontend ne s’effondre pas sous un empilement croissant de fonctionnalités - nous gardons les composants propres, nous surveillons la performance de rendu et nous tenons la cohérence avec le reste de l’écosystème. Ici, une seule équipe s’occupe du frontend comme du backend, si bien qu’une nouvelle fonctionnalité se construit de l’API à l’écran sans renvoi de responsabilité entre prestataires.
Quand recourons-nous à des composants C++ dans le transport ?
Quand c’est la performance brute qui compte. Certains systèmes de transport comportent des parties où les millisecondes et l’usage mémoire font la différence - traitement de gros volumes de données, algorithmes lourds en calcul, composants proches du matériel ou de l’infrastructure. C’est là que nous recourons au C++, en standard C++17.
Ce n’est pas notre choix par défaut pour une application entière, mais un outil pour des éléments précis, critiques en performance, que nous branchons ensuite sur le reste de la plateforme en Java et microservices. Le produit gagne en performance exactement là où il en a besoin, sans compliquer tout le reste.
Comment menons-nous la migration d’applications de transport vers le cloud (GCP, cloud-to-cloud) ?
Nous traitons une migration cloud comme une opération sur un organisme vivant, pas comme un « déplacement de fichiers » ponctuel. Pour le fournisseur de technologies pour l’aviation et le voyage, nous menons des migrations cloud-to-cloud vers GCP, en déplaçant des systèmes en production entre environnements cloud sans que le métier ne le ressente.
- nous conteneurisons les applications (Docker) et les orchestrons dans Kubernetes,
- nous décrivons l’infrastructure comme du code dans Terraform, pour des environnements reproductibles,
- nous automatisons les déploiements avec de la CI/CD sur Jenkins,
- nous migrons par étapes, en maîtrisant ce qui bascule et quand.
Cette infrastructure apporte ensuite ce pour quoi on migre : des déploiements plus rapides et plus sûrs, des environnements prévisibles et une montée en charge au niveau du trafic réel.
Comment assurons-nous la qualité : QA et automatisation des tests ?
Dans un système qui change en permanence, les tests manuels ne peuvent pas suivre. Nous automatisons donc tout ce que nous pouvons. Nous construisons des tests end-to-end d’interface en Selenium et des tests d’API en REST Assured, et nous les branchons sur le pipeline CI/CD pour que chaque changement soit vérifié avant d’avancer.
Du coup, développer de nouvelles fonctionnalités ne signifie plus un risque de régression permanent - l’équipe peut ajouter de la valeur plus vite parce que le filet de tests attrape les bugs tôt. C’est l’une des conditions pour mener développement et maintenance en parallèle plutôt qu’à tour de rôle.
Quelles compétences apportons-nous à un projet de transport ?
Nous façonnons l’équipe autour du système précis et de l’étape où il se trouve, pas à partir d’un modèle figé. Nous combinons généralement plusieurs rôles :
- des développeurs backend (Java/Spring) qui développent les microservices et la logique métier,
- des développeurs frontend (React/Angular) responsables des interfaces,
- des ingénieurs C++ là où la performance compte,
- des ingénieurs DevOps / cloud qui mènent la conteneurisation, Kubernetes, Terraform et la CI/CD,
- des ingénieurs QA qui construisent l’automatisation des tests,
- des spécialistes data qui maintiennent les processus ETL/ELT.
Nous ne pourvoyons pas tous ces rôles au cas où - nous mobilisons ceux dont le projet a réellement besoin.
Comment procédons-nous chez RITS ?
Nous le faisons en partenaire nearshore depuis la Pologne, avec une expérience réelle dans le transport et la travel tech. Pour un fournisseur de technologies pour l’aviation et le voyage, nous développons, maintenons et migrons vers le cloud ses applications : nous ajoutons de nouvelles fonctionnalités aux systèmes existants, nous les maintenons en service et nous menons des migrations cloud-to-cloud vers GCP.
En dessous tourne une stack cohérente : Java, Spring et microservices côté backend, React et Angular côté frontend, C++17 dans les composants critiques en performance, plus Docker, Kubernetes, Terraform et Jenkins dans la couche cloud et Selenium et REST Assured dans l’automatisation des tests. Une telle équipe traite le développement et la maintenance comme un seul métier, si bien que la plateforme grandit au lieu de s’effriter.
Par où commencer avec le développement et la migration d’applications de transport ?
Commencez par une carte honnête de ce que vous avez : quels systèmes apportent de la valeur, où se loge la dette technique et ce qui vous empêche d’ajouter de nouvelles fonctionnalités. C’est la seule chose qui vous dira si le développement, la maintenance ou une migration cloud est la démarche la plus urgente - et quelles compétences il vous faut. Nous avons traité les différences entre modèles de collaboration dans notre article sur les modèles de collaboration IT.
Vous construisez, maintenez ou migrez vers le cloud des applications de transport ? Parlons-en - nous ajusterons une équipe et une stack à votre système.
Construisez, maintenez et migrez vos applications de transport avec nous