Sommaire
Au moment d’envisager sa refonte plateforme digitale tourisme, un acteur majeur présent sur plusieurs marques et destinations est venu voir ACSEO avec une question simple en apparence : « faut-il refaire notre site ? ». Notre réponse a été différente de celle attendue, et c’est cette trajectoire que l’on détaille ici, sans chiffres ni noms, mais avec tout le raisonnement.
Le contexte : plusieurs marques, plusieurs sites, zéro vision d’ensemble
Comme beaucoup de groupes construits par croissance successive, cet acteur du tourisme opère plusieurs marques et destinations, chacune avec son propre site. Ces sites ont été développés au fil du temps, par des équipes différentes, à des périodes différentes, sans architecture commune pensée dès le départ.
Résultat : une duplication permanente des efforts. Un nouveau besoin (ajouter une fonctionnalité de recherche plus pertinente, un espace compte client et un nouveau tunnel de vente) doit être pensé, développé et maintenu séparément sur chaque site. Les expériences utilisateurs divergent d’une marque à l’autre sans raison métier valable. Et surtout, impossible de capitaliser : chaque site est une fondation reconstruite, jamais un socle commun qu’on enrichit.
C’est un symptôme que l’on retrouve chez beaucoup de groupes multi-marques, bien au-delà du tourisme.
Le diagnostic : 4 signaux d’alerte qui parleront à d’autres DSI
Avant de proposer une solution, on a posé un diagnostic. Quatre signaux revenaient, et ils ne sont pas spécifiques à ce client (vous les reconnaîtrez peut-être).
Une application vieillissante et monolithique
Chaque évolution devient lente et risquée. La moindre modification impose de tester l’ensemble de l’application, pas seulement la fonctionnalité touchée. La dette technique s’accumule plus vite qu’elle ne se résorbe, et les équipes internes passent une part croissante de leur temps à maintenir l’existant plutôt qu’à innover.
Des enjeux de performance
Le socle technique n’a pas été pensé pour l’échelle actuelle, en particulier les pics de trafic saisonniers très marqués dans le secteur du tourisme, où une recherche de disponibilités doit rester rapide même en pleine période de réservation. Des Core Web Vitals dégradés pénalisent à la fois le référencement naturel et le taux de conversion : un double coût, silencieux mais réel.
Des couplages forts à des éditeurs externes
Une partie de la logique métier et de l’expérience utilisateur est verrouillée dans les choix techniques d’un ou plusieurs éditeurs. Conséquence directe : impossible de faire évoluer un composant sans repasser par une demande externe, ce qui freine l’autonomie et ralentit l’innovation au rythme d’un tiers plutôt qu’au rythme du métier.
Des sites en silos
Chaque marque ou destination possède son propre site, sans tronc commun, parfois jusqu’à sa propre gestion de l’inventaire des hébergements (PMS) et sa propre synchronisation des disponibilités avec les canaux de vente externes (OTA). Lancer un nouveau site revient à reconstruire une fondation déjà bâtie N fois ailleurs dans le groupe avec le même effort, les mêmes risques, et aucune capitalisation sur ce qui a déjà été fait.
Pris isolément, chacun de ces signaux est gérable. Ensemble, ils dessinent un système qui freine structurellement le business, quelle que soit la qualité des équipes qui le font tourner.
La rupture à anticiper : l’IA et le commerce agentique
Au-delà de la dette déjà accumulée, un autre facteur a pesé dans la décision : la manière dont les clients vont chercher et réserver un séjour est en train de changer. Agents IA capables de comparer et réserver pour le compte d’un utilisateur, recherche conversationnelle, nouveaux canaux de découverte qui ne passent plus uniquement par un moteur de recherche classique ou une page d’accueil.
Une architecture fermée et monolithique ne peut pas exposer facilement ses données et ses parcours à ces nouveaux canaux : chaque intégration devient un projet à part entière, lourd et spécifique. Une architecture API-first et composable, elle, expose nativement ce dont ces nouveaux usages ont besoin, parce que l’API n’a jamais été pensée comme un sous-produit du site web, mais comme le véritable point d’accès à la donnée et aux règles métier.
C’est un argument qui dépasse le confort technique : c’est une condition pour rester visible et vendable sur les canaux de demain.
La solution proposée : une Plateforme et des Fronts pensés pour durer 10 ans
Plutôt qu’une refonte classique (un nouveau site, construit comme une nouvelle version du même monolithe) on a proposé une bascule de modèle : une Plateforme commune (PIM, moteur de recherche, CMS, gestion des identités, flux de données, API de façade) qui porte la donnée et les règles métier, et des sites Front indépendants, un par marque ou destination, qui consomment cette Plateforme via ses API.
Concrètement, cela change la nature même d’un projet de lancement de site. Un nouveau Front devient un projet de quelques semaines, qui réutilise tout ce que la Plateforme offre déjà : recherche, gestion du catalogue, identité client et tunnel de vente, plutôt qu’un nouveau monolithe à concevoir, sécuriser et maintenir de zéro.
C’est le modèle que l’on détaille plus en profondeur dans l’article sur la plateforme multi-sites, et dont on pose la logique d’ensemble dans notre article de synthèse sur l’architecture MACH.
La méthode de delivery, un facteur de réassurance autant que la solution elle-même
Un changement d’architecture de cette ampleur inquiète légitimement une direction : nouveau socle, nouvelles équipes, nouveau fournisseur, autant de raisons de craindre une dépendance supplémentaire plutôt qu’un gain d’autonomie. On a construit la méthode de delivery pour répondre précisément à cette crainte.
Un CTO ou Lead Dev dédié accompagne le programme de bout en bout, garant des choix d’architecture et de la cohérence technique dans la durée. Le mentorat des équipes internes est intégré dès le départ, pas ajouté en fin de projet : l’objectif est que le client reste, à terme, pleinement maître de sa plateforme, sans dépendance artificielle envers le prestataire. Une méthodologie augmentée à l’IA permet de tenir des délais courts sans sacrifier la qualité du code ni la couverture de tests. Et une Factory interne transforme une maquette Figma validée en composant testé, documenté et déployé en quelques minutes. La preuve concrète que la vitesse et la rigueur ne s’opposent pas.
Cette méthode est démontrée en détail, avec un exemple réel de déploiement bloqué puis corrigé par les contrôles qualité automatisés, dans notre article sur la Factory Figma vers production.
Les bénéfices attendus, formulés pour un comité de direction
Ramenés à un niveau de décision, les bénéfices de cette trajectoire tiennent en quatre points :
- Recentrer les équipes internes sur la valeur métier, plutôt que sur le Build et le Run technique récurrent qui absorbe aujourd’hui une part disproportionnée de leur temps ;
- Clarifier la gouvernance delivery : qui fait quoi, entre équipes internes et partenaire externe, pour sortir du flou des responsabilités partagées qui ralentit chaque décision ;
- Sécuriser un socle robuste et performant pour les dix prochaines années d’expériences client, plutôt qu’un rafistolage qui ne tiendra que quelques saisons ;
- Être prêt pour les canaux de demain : agents IA, recherche conversationnelle, nouveaux points de découverte, sans avoir besoin d’une nouvelle refonte complète dans trois ans.
Pourquoi ACSEO
Ce type de programme demande trois choses rarement réunies chez un seul partenaire : une expertise réelle sur l’architecture composable et son pilotage multi-projets, une capacité à industrialiser le passage de la conception au code en production (et pas seulement à en parler), et une posture de partenaire qui transfère la compétence plutôt que de créer une nouvelle dépendance.
C’est l’approche qu’ACSEO porte depuis 17 ans, sur plus de 600 projets digitaux livrés et une durée de collaboration moyenne de 7 ans avec ses clients : une expertise technique exigeante, une proximité réelle avec les équipes client, et un principe simple — vous rendre plus autonome à la sortie du projet qu’à son entrée.
Vous vous reconnaissez dans cette situation ? Échangeons ensemble !
