Captain Train + APIs = ❤
Ou comment les APIs structurent le service et le business model de Captain Train.
Lorsqu’une start-up s’attelle à son projet, il lui faut parfois suppléer à des manques. Par exemple, les services de réservation de billets de train ont un important travail d’agrégation de données à réaliser avant de proposer un premier trajet aux utilisateurs.
Des dizaines de transporteurs proposent des milliers de trajets en train avec une infinité de variations (horaires, étapes, cartes de réduction…). À moins de vouloir monter une agence de voyage (une requête → un interlocuteur dédié → n recherches successives sur n transporteurs → une réponse), une question se pose : Comment rendre interrogeable ces millions de données quasi instantanément ?
Mais avec les APIs bien sûr ! (Avouez, vous commencez à me connaître.)
Dans les paragraphes qui suivent, nous découvrirons ensemble le rôle essentiel des APIs dans la structuration du business model de Captain Train. Au cours de mon étude, j’ai eu le plaisir d’échanger avec Paul Bonaud, développeur back-end chez Captain Train. Paul tenait par ailleurs à préciser qu’il parle au nom de toute l’équipe.
C’est quoi Captain Train ?
Pour celles et ceux d’entre vous qui ont vécu dans un bunker ces dernières années, Captain Train vend des billets de train en France et en Allemagne.
Simplement, rapidement et avec beaucoup d’amour dedans.
Captain Train mise sur une interface réduite à la plus simple expression du service qu’il propose : vendre des billets de train. Le visiteur n’y trouve ni propositions de vols à destination de l’Europe, ni réductions pour un week-end à Berck-sur-Mer, ni croisières.
Captain Train centralise en revanche les données de nombreux transporteurs de tailles variées (nationaux et locaux). Le service applique un moteur d’itinéraires permettant de trouver le trajet le plus rapide et le moins cher.
Et ça vient d’où Captain Train ?
Avant de sauter dans le grand bain, retraçons un instant les grandes étapes de la start-up française.
Captain Train est crée en 2009 par Jean-Daniel Guyot, Martin Ottenwaelter et Valentin Surrel.
Captain Train ouvre pour la première fois sa bêta en 2011 à 22 000 utilisateurs.
La start-up réalise successivement trois levées de fonds auprès de cinq investisseurs (Alven Capital, CM-CIC Capital Prive, Index Ventures, Pierre Bonelli et Xavier Niel) :
- Septembre 2012 : 1,4 millions d’euros (Capital d’amorçage)
- Juin 2013 : 2,5 millions d’euros (Série A)
- Décembre 2014 : 5,5 millions d’euros (Série B)
En octobre 2012, Captain Train ouvre son service au grand public :
Après quelques années de travail dans l’ombre, de sueur et de lignes de code, nous avons décidé que le Captain Train avait désormais la qualité nécessaire pour accueillir tous ceux qui veulent acheter leurs billets de train plus simplement. Source : Ouverture
En octobre 2013 et mars 2014, sont respectivement lancées les applications Iphone et Android.
En 2015, le service propose une douzaine de transporteurs (et filiales) dont IDTGV, IDBus, Thello (trains de nuit), Ouigo (TGV low cost), Trenitalia, Deutsche Bahn, etc.
Le 14 mars 2016, le journal Les Échos, annonce le rachat de Captain Train par Trainline pour la somme de 200 millions d’euros.
Comment Captain Train utilise les APIs ?
Entretien avec Paul Bonaud, développeur back-end chez Captain Train
Rémi Mercier
“Bonjour Paul ! Première question : Quelles APIs consommez-vous chez Captain Train (VSCT, Eurostar, Stripe…) ?”
Paul Bonaud
Cette question est assez délicate car nous avons des contrats assez précis avec les transporteurs. Je ne vais donc pas pouvoir vous détailler précisément les APIs que nous consommons mais la règle générale est : « un acteur extérieur = une API ».
Un acteur extérieur pouvant être un transporteur ferroviaire ou un prestataire de paiement par exemple.
Rémi
“Quels sont les formats de sortie proposés par ces APIs ?”
Paul
Assez classiquement Text (oui oui), XML (SOAP) ou JSON.
Rémi
“Quand vous devez parser du .txt, les transporteurs vous fournissent au moins les modalités du contrat d’échange, ou c’est à vous de vous débrouiller ?”
Paul
J’ai parlé de ce format pour l’exhaustivité. Cela ne concerne pas un transporteur mais un prestataire de paiement. Bien sûr nous avons une documentation technique pour comprendre le format. (Dans notre cas sur cette seule API qui communique en « plain text » le format reste un simple listing de « clé=valeur »)
Rémi
“Y-a-t’il des transporteurs qui ne proposent pas d’APIs ?”
Paul
Principalement nous avons des APIs pour tous les « gros » transporteurs. Cependant il existe des petites lignes touristiques qui n’ont pas les moyens de fournir une API.
Rémi
“Si oui, utilisez-vous des alternatives ou vous ne proposez pas les informations de ce transporteur ?”
Paul
Il existe quelques exceptions cependant. Certains transporteurs proposent des données entièrement « offline » : c’est donc à nous de faire notre tambouille pour exposer une API en interne. La seule API qu’ils fournissent alors est pour la réservation de siège pour qu’ils puissent bien sûr gérer leur inventaire de réservation.
Rémi
“Offline, comme dans CD-Rom ?”
Paul
Exactement ! À partir d’une documentation et de fichiers de données donc zéro appel externe.
Rémi
“Lorsqu’un internaute requête votre base pour obtenir les meilleurs billets sur un trajet, votre algorithme tourne-t-il sur toutes les APIs simultanément ou repackagez-vous ces APIs via un proxy interne ?”
Paul
Notre architecture est divisée en plusieurs petits services donc lorsqu’un internaute requête nos serveurs pour trouver un billet de train la requête passe par plusieurs APIs internes. En effet chacun de nos services « repackage » un ensemble d’APIs pour proposer des APIs internes.
Rémi
“Est-il possible de préciser les différents services ou nous sommes sur de l’information confidentielle ? J’imagine que vous avez au moins une API de search, une API pour la réservation / le panier, l’API tierce de paiement…”
Paul
Je ne peux malheureusement pas vous décrire la structure complète de notre système.
En gros nos APIs internes ne sont pas séparées par fonctionnalité comme vous l’avez décrit mais par « métier ». Une pour le paiement, une pour le train…
Rémi
“Votre API interne, plutôt JSON ou XML ?”
Paul
Si vous regardez les communications entre votre navigateur et nos serveurs vous serez vite fixé. (Spoil : ça commence par un « J »).
Rémi
“Dans vos APIs internes, vous cherchez à vous rapprocher d’un paradigme REST ou ce n’est pas forcément utile pour vous ?”
Paul
Pour nos APIs internes nous essayons un maximum de garder des requêtes sans état. Nous utilisons beaucoup d’UUIDs [ndlr : Identifiants universels uniques] et essayons de communiquer l’état des objets à chaque échange requête/réponse. Comme vous pouvez imaginer, cela reste des APIs internes et il arrive que nous ne soyons pas 100 % rigoureux.
[ndlr : Paul et Cyril Mottier me précisent a posteriori l’équipe préfère une vision pragmatique vis à vis du paradigme REST.]
Rémi
“En septembre 2014, la commission était votre seul mode de rémunération. Avez-vous dans le futur l’intention de proposer des packages d’APIs monétisables (comme ce que fait Skyscanner par exemple) ?”
Paul
Nous allons y réfléchir. En attendant nous avons récemment lancé une nouvelle offre : « Captain Train for Business » pour proposer un outil clé en main pour les entreprises.
Rémi
“J’ai vu passer l’offre chez OpenDataSoft, je ne sais pas si nous y avons souscrit. Mais le service est pertinent et la monétisation intéressante (tant dans la forme de la monétisation que dans le tarif). Qu’est-ce qui a déterminé ce pricing ? Et vous espérez convertir combien d’entreprises en Europe ?”
Paul
Je n’ai pas fait parti des discussions sur la décision du pricing sur la version business de Captain Train. Principalement nous voulions un prix (très) raisonnable à comparer à ce qui peut se faire aujourd’hui dans l’industrie. Également, nous avons voulu un moyen simple pour comprendre le prix du service : un passager qui voyage = une unité de facturation.
Nous espérons convertir un maximum d’entreprises bien sûr. Nous croyons que la simplicité et l’efficacité de notre produit ne peuvent être que bénéfique pour des entreprises qui font souvent face à des produits vieillots / pas très agréable à utiliser.
Développer une API pour agréger et interroger des données disparates
Notons que les APIs — si elles sont sources de données pour certains transporteurs — sont surtout un outil interne à travers lequel Captain Train interroge sa base de données. Captain Train fournit un effort technique significatif pour centraliser une information disparate (différentes transporteurs) et hétérogène (formats, qualité…).
Ce surcoût technique permet à Captain Train de proposer un service de recherche au top : rapidité d’interrogation, pertinence des résultats et des prix.
Les APIs internes permettent de déployer ce service sur un ensemble de terminaux sans toucher à la technologie fondatrice : site web, applications Iphone et Android… Lorsqu’une donnée est modifiée, quel que soit le terminal sur lequel a lieu la requête, l’API reflète le changement sur l’ensemble du parc applicatif.
Les APIs comme vecteurs de nouveaux flux de revenus
Les APIs internes permettent également à Captain Train de décliner leur offre à coût marginal.
Le primo marché de Captain Train est un marché de masse : la personne physique. Pour chaque vente réalisée à travers Captain Train, la start-up touche une commission. La start-up vise donc l’augmentation de sa base utilisateurs. Plus il y a d’utilisateurs, plus il y a de commissions, plus le revenu est important. C’est pour ce primo marché que Captain Train a développé en premier lieu ses APIs internes.
En ajoutant des fonctionnalités ad hoc (centralisation de la facturation, tarifs préférentiels, etc), Captain Train propose désormais aux entreprises d’accéder à ce service en échange d’un abonnement peu coûteux (9€ par voyageur / mois). En captant un second marché — celui des personnes morales — la start-up ajoute un flux de revenu récurrent à son modèle à la commission.
Il est intéressant de noter que grâce aux APIs, Captain Train n’a eu “qu’à développer” un ensemble de fonctionnalités par dessus sa technologie centrale — les APIs — pour toucher un marché alternatif. Les APIs permettent de créer un effet de levier plus important pour l’exploration de nouveaux marchés, de nouveaux utilisateurs. On peut imaginer que les APIs Captain Train soient à terme partagées via un programme de partenaires.
Paul résume parfaitement le bénéfice à long terme des APIs :
Le travail en amont sur l’élaboration d’une api (qui est d’ailleurs faite pour être utilisable / partageable) peut sembler à première vue un surcoût à l’entreprise. C’est en fait un gros plus pour diversifier / maintenir son business.
En résumé
- Le vrai métier de Captain Train, ce ne sont pas les trains, mais les APIs.
- En développant une série d’APIs internes, Captain Train homogénéise de manière systémique des données hétérogènes.
- En développant différents ensembles de fonctionnalités autour de ses APIs, Captain Train touche différents marchés : B2C et B2B.
- Chaque marché apporte un flux de revenus complémentaire.
- Ces ensembles de fonctionnalités sont développés à coût moindre comparés à la technologie coeur (les APIs donc).
UN GRAND MERCI à Paul Bonaud, Cyril Mottier et l’équipe de Captain Train pour avoir pris le temps de satisfaire ma curiosité. 👍
Cet article vous a été utile ? Aidez les autres à comprendre les APIs en cliquant le ❤.
Cette série d’articles est une adaptation de mon mémoire de Master 2 Management et Entrepreneuriat de Projets Numériques (oui, tout ça). Vous voulez en recevoir le texte intégral ? Envoyez-moi votre email via LinkedIn.
Des feedbacks, une coquille repérée, des erreurs à corriger ? Pinguez-moi sur Twitter.
