Le contexte
Un opérateur de voyages avait besoin d’une plateforme couvrant l’ensemble de sa chaîne : préparer les séjours côté équipe, les distribuer aux voyageurs, et fournir sur place les documents nécessaires. Trois publics, trois interfaces, une seule source de vérité.
L’enjeu
Le point dur d’une application de voyage est évident dès qu’on y pense, et oublié dans neuf projets sur dix : le voyageur n’a pas de réseau au moment où il en a besoin.
Il consulte son programme dans un avion, cherche son billet dans un hall de gare saturé, vérifie une adresse à l’étranger sans forfait data. Une application qui suppose une connexion permanente est une application qui échoue exactement au moment qui compte.
Deuxième contrainte : le voyageur ne doit pas avoir à créer un compte. Un code d’accès doit suffire — sans pour autant qu’un code au hasard donne accès aux données de quelqu’un d’autre.
Ce que nous avons fait
- Une API Django REST comme socle métier unique, exposant les séjours, les participants et les documents associés.
- Une application voyageur en Flutter, entièrement utilisable hors ligne. Les données sont sérialisées et conservées localement : le programme, les informations pratiques et les documents restent consultables sans réseau, et se resynchronisent dès qu’une connexion revient.
- Un accès par code, sans création de compte, avec des règles de sécurité écrites pour que la lecture d’un séjour exige le bon code — et uniquement celui-là. Le confort d’un accès sans friction, sans ouvrir la porte aux données des autres voyageurs.
- Un back-office en Flutter pour les équipes internes, avec authentification distincte de celle des voyageurs.
- Génération de billets et documents PDF avec codes-barres, produits côté serveur pour rester identiques quel que soit l’appareil qui les affiche ou les imprime.
- Notifications push vers les voyageurs, et déploiement sur une infrastructure Apache avec certificats automatisés.
Le résultat
La plateforme est en service et continue d’évoluer. L’API et le back-office font l’objet de livraisons régulières depuis la mise en production.
La décision qui a le plus compté a été de traiter le hors-ligne comme une exigence de départ, pas comme une amélioration ultérieure. C’est un choix qui structure le stockage local, la synchronisation et le modèle de données — quasi impossible à rattraper après coup, et invisible quand il est bien fait.
Aperçus
Client couvert par un accord de confidentialité