À propos de la Cité du Train
La Cité du Train – Patrimoine SNCF est le premier musée ferroviaire d'Europe, à Mulhouse, en Alsace. Elle accueille environ 115 000 visiteurs par an sur 20 000 m² d'espaces couverts, au sein d'un site de 60 000 m², et sa fréquentation progresse.
Le musée est géré par une association privée indépendante, dont le conseil d'administration est placé sous la tutelle de la SNCF. Toute évolution significative doit être présentée et validée : un choix de plateforme doit donc être défendable et durable, et pas seulement fonctionnel.
Trois activités cohabitent : une billetterie sur place, un canal de vente en ligne et une boutique de plus de 1 000 SKU's. Trois postes de caisse à l'accueil — deux pour la billetterie, un pour la boutique — exploités par trois encadrants et cinq hôtes et hôtesses d'accueil, sans service informatique interne.
Comprendre les besoins métier
Ces trois activités reposaient sur deux systèmes qui ne communiquaient pas, imposant une réconciliation manuelle quotidienne et rendant l'affectation comptable du chiffre d'affaires difficile. La demande du musée était plus précise qu'« un nouveau logiciel ».
Centralisation — billetterie sur place, billetterie en ligne et boutique dans un système unique.
Une billetterie en ligne reliée au guichet, avec des billets scannables à l'arrivée.
Des caisses compatibles Windows 11 — exigence de sécurité après une intrusion — et la certification fiscale NF525
La gestion des jauges pour les activités à capacité limitée : visites guidées, escape game, expériences de cabine de conduite
Une grille tarifaire complète : plein, réduit, enfant, senior, famille, gratuité, groupes et billets combinés avec les musées voisins
Les billets partenaires — Museum Pass, entrées combinées — qui doivent rester scannables sur site
Un abonnement prévisible plutôt qu'une commission par billet, sur une plateforme prévue pour durer cinq à huit ans
Ce que le musée a écarté compte autant : pas de vente en ligne pour la boutique, ni tourniquets ni contrôle d'accès en temps réel, pas d'automatisation marketing à ce stade, et pas de refonte du site principal. La question portait sur le logiciel de billetterie, pas sur le site.
Odoo comme solution
Odoo couvre nativement les trois activités : Point de Vente, Website et e-commerce, Events, Ventes, Achats, Inventaire, Portail et Comptabilité relèvent du même produit, si bien que l'unification a d'abord été un travail de paramétrage avant d'être un travail de développement. La solution est certifiée NF525, la licence est un abonnement prévisible et non un prélèvement sur chaque billet vendu, et là où la réalité du musée s'écartait du produit, celui-ci pouvait être étendu proprement plutôt que dénaturé.
Deux partis pris ont structuré le projet. Le site principal du musée est resté en place, la partie billetterie étant reconstruite dans Odoo aux couleurs du musée, pour que le visiteur ne perçoive pas le passage de l'un à l'autre. Et les catalogues restent séparés — les postes billetterie ne vendent pas d'articles boutique, le poste boutique ne vend pas de billets — alors que toutes les transactions alimentent la même base. La séparation, c'est ce que voient les équipes ; la base commune, c'est ce qui met fin à la réconciliation.
Ce qui a été mis en œuvre
Le travail se partage entre ce qu'Odoo fait en standard et ce qu'il a fallu développer. Livré sur Odoo 19 Enterprise et 14 modules personnalisés.
Odoo standard, paramétré
Point de Vente sur trois postes, catégories de produits séparées et fonctionnement hors connexion qui permet de continuer à vendre en cas de coupure.
Achats et Inventaire sur plus de 1 000 boutique SKU's codes-barrées, migrées avec leurs codes fournisseurs, coûts et taxes.
Ventes et Portail pour les commandes groupes et CSE, ainsi que les bons cadeaux et invitations nominatives natifs.
Comptabilité en aval de tous les canaux, avec un chiffre d'affaires affecté directement plutôt que reconstitué après coup.
Events comme socle du parcours visiteur, et Knowledge comme backlog de support écrit tenu par le musée lui-même.
Des droits par rôle : un caissier voit l'écran de caisse, et rien d'autre.
Spécifique : l'application Events repensée autour des créneaux
L'application Events d'Odoo est conçue pour des conférences. Un musée n'est pas une conférence : les visiteurs arrivent par créneaux, toute la journée, tous les jours, et la capacité se mesure en personnes franchissant la porte. L'essentiel de la couche spécifique comble cet écart.
Une vraie jauge par créneau. Le nombre de places devient une valeur stockée et modifiable plutôt qu'un calcul issu de l'événement, et la jauge du créneau prime sur tout quota de billet : la salle est la contrainte dure.
Un calendrier dans la page, pas une pile de fenêtres. Le standard fait passer le visiteur par trois fenêtres successives, sans aucun total affiché. À la place : un calendrier intégré à la page événement — date, puis horaire, puis quantités, avec la disponibilité en direct et un total qui se met à jour. Semaine démarrant le lundi, jours passés grisés, et un message explicite quand un mois n'a rien à vendre.
Des créneaux du jour qui restent vendables. Le standard masque un créneau de 10 h une fois 14 h passée. Un musée vend aux retardataires toute la journée : les filtres sont passés de l'heure à la date.
La concurrence entre le web et le guichet. La disponibilité est revalidée côté serveur à la soumission, et les places sont rafraîchies en temps réel sur tous les postes ouverts dès qu'un billet se vend quelque part.
L'expiration des réservations. Chaque événement porte une durée de validité ; une tâche nocturne annule ce qui a expiré et libère les places.
Des questions qui valident. Le pays devient une liste de valeurs avec la France par défaut plutôt qu'un champ libre, et le code postal n'est exigé que des visiteurs français, contrôlé sur les plages métropolitaines et ultramarines.
Des événements privés pour les CSE. Un quatrième mode de visibilité piloté par étiquettes partenaires, appliqué en base, dans les listes et sur les URL directes.
Spécifique : compter des personnes, pas des billets
Un pass famille, une réservation de groupe, une visite guidée : chacun est une ligne de vente couvrant plusieurs visiteurs. La fréquentation est donc portée comme une valeur à part entière, du produit au billet, puis à l'inscription et jusqu'au total de l'événement — et seules les inscriptions confirmées ou présentes, payées ou gratuites, sont comptées, si bien qu'un panier abandonné ne gonfle jamais la fréquentation. Elle apparaît sur l'événement, en colonne sur la liste des inscriptions et comme mesure dans le tableau croisé des ventes.
Spécifique : billets, badges et contrôle d'accès
Chaque inscription porte un QR code de contrôle. Les acheteurs en ligne reçoivent leur badge par e-mail, scanné depuis le téléphone à l'entrée, y compris depuis un second point de contrôle déporté les jours d'affluence. Le badge est une carte de 80 × 50 mm, calibrée sur le rouleau thermique que le musée achète déjà pré-imprimé — le badge standard d'Odoo fait 82 × 96 mm et n'y entre pas — portant l'événement, le type de billet, le lieu, le participant, un QR code et un bloc de validité qui s'affiche de trois manières, son code-barres pivoté pour courir le long du bord.
Le matériel existant a autant pesé que le logiciel. Les caisses tournaient sous Windows 10 et ne pouvaient pas être certifiées pour Windows 11 ; les tiroirs-caisses sont intégrés à un mobilier sur mesure et ne peuvent pas être remplacés ; les rouleaux thermiques font 80 × 50 mm et sont déjà imprimés sur une face. Une visite sur site a débouché sur un plan de bascule poste par poste — la boutique d'abord, puis un poste billetterie en fonctionnement hybride aux côtés de l'ancien système, puis le second — avec câbles et connecteurs repérés par couleur pour chaque poste.
Spécifique : intégrations de paiement
Les paiements en ligne passent par Monetico, la passerelle du Crédit Mutuel / CIC, qu'Odoo ne prend pas en charge nativement. Chaque message renvoyé par la banque est re-scellé et rejeté si le sceau ne correspond pas, et la confirmation faisant foi arrive de serveur à serveur : la commande aboutit même si le navigateur de l'acheteur ne revient jamais sur le site.
Au guichet, la caisse pilote directement le terminal de paiement en Caisse-AP sur IP : le caissier ne ressaisit jamais le montant, et la réponse du terminal remonte directement dans l'écran de paiement. Les chèques-vacances font l'objet d'un traitement dédié, ces titres ne pouvant légalement pas être remboursés en espèces : la différence non rendue est comptabilisée en produit exceptionnel plutôt qu'affichée comme monnaie due, ce qui a mis fin aux écarts de caisse en fin de journée. Les remboursements se bouclent également dans Odoo : l'annulation d'une commande génère l'avoir, déclenche le remboursement et prévient le client.
Spécifique : un reporting exploitable
Deux analyses sont volontairement distinctes. Revenus compte l'argent à la date de transaction, par type de billet et par canal. Participants compte les personnes à la date de présence, qui n'est pas le même jour : on peut acheter aujourd'hui pour une visite le mois prochain.
Autour d'elles : une vue des inscriptions regroupée par créneau plutôt que par événement, pour planifier les équipes ; un vrai filtre prospectif « 30 prochains jours », là où les périodes relatives d'Odoo ne regardent que vers le passé ; un tableau croisé reliant les réponses des visiteurs à leur date de venue ; et un tableau de bord de provenance cartographiant pays et départements à partir des codes postaux saisis en caisse. L'arrondi de TVA a été ramené à la ligne de facture, pour que le montant affiché corresponde au montant imprimé.
Impact global sur l'activité
3 → 1
activités sur une base unique
115 000
visiteurs par an, correctement comptés
14
modules Odoo spécifiques livrés
1 000+
références boutique migrées
La réconciliation quotidienne entre systèmes a disparu, et le chiffre d'affaires s'affecte en comptabilité au lieu d'être reconstitué à partir de deux exports. La boutique fonctionne sur un catalogue unique et un stock unique. La direction dispose de chiffres de fréquentation défendables en conseil d'administration, parce que la fréquentation et les dates de présence sont modélisées et non estimées. Le guichet est plus rapide — moins d'écrans, aucun montant ressaisi, plus d'écart de caisse lié aux chèques-vacances — et il continue de vendre quand la connexion tombe.
Les questions de conformité qui ont déclenché le projet sont réglées : matériel compatible Windows 11, certification NF525, abonnement prévisible plutôt que prélèvement sur chaque billet. Et la plateforme devient l'endroit où se construit la suite plutôt qu'un système de plus à acheter : portails de prévente B2B, bons cadeaux, analyse de provenance et reporting financier quotidien consolidé reposent tous sur la même base.
Un projet similaire en réflexion ?
Chef Pixel est partenaire Odoo Ready Partner, spécialisé en point de vente, e-commerce, intégration matérielle et développement spécifique Odoo pour des organisations aux contraintes opérationnelles réelles.