API et connexion des outils voyage d'affaires
Dans l'écosystème du voyage d'affaires, les données circulent entre de multiples systèmes : le SBT (self-booking tool) pour les réservations, le GDS (global distribution system) pour l'accès à l'inventaire des compagnies, le TMC pour le service et le conseil, le SIRH pour les données collaborateurs, l'ERP pour la comptabilité, l'outil de notes de frais pour le remboursement et la plateforme de duty of care pour la sécurité des voyageurs. Sans connexion entre ces systèmes, les données doivent être saisies manuellement à chaque étape, générant des erreurs, des retards et des incohérences. Les API (Application Programming Interfaces) sont la clé de cette interconnexion. Cet article explique comment elles fonctionnent, quelles connexions sont prioritaires et comment un DSI ou un travel manager peut structurer le projet.
Qu'est-ce qu'une API et pourquoi est-ce important pour le voyage d'affaires ?
Une API est une interface de programmation qui permet à deux logiciels de communiquer entre eux de manière automatisée et standardisée. Concrètement, une API permet à votre outil de notes de frais de récupérer automatiquement les données de réservation depuis votre TMC, sans qu'aucun humain n'ait à ressaisir les informations (date, montant, destination, motif).
Dans le voyage d'affaires, les API sont essentielles pour trois raisons fondamentales.
L'élimination de la double saisie. Sans API, les mêmes informations (nom du voyageur, centre de coûts, destination, dates) sont saisies dans le SBT, retranscrites dans la note de frais, vérifiées manuellement par la comptabilité et re-saisies dans l'ERP. Chaque saisie est une source potentielle d'erreur. Les API suppriment ces redondances en faisant circuler les données automatiquement d'un système à l'autre.
La vision consolidée. Un DAF ou un travel manager a besoin d'une vision unifiée de l'ensemble des dépenses de déplacement : transport, hébergement, repas, frais annexes. Sans API, ces données sont dispersées dans des systèmes différents et leur consolidation nécessite un travail d'extraction et de rapprochement manuel. Avec des API bien configurées, un tableau de bord unique agrège en temps réel l'ensemble des données.
L'automatisation des processus. Les workflows d'approbation, le rapprochement factures/commandes, la récupération de TVA, le calcul des émissions carbone, la détection des anomalies — tous ces processus peuvent être automatisés grâce aux échanges de données inter-systèmes via API.
Les connexions prioritaires dans l'écosystème voyage
TMC ↔ SIRH : la base du système
La connexion entre le TMC (ou le SBT) et le SIRH est la fondation de tout écosystème voyage connecté. Elle permet de synchroniser automatiquement les données collaborateurs : identité, poste, rattachement hiérarchique, centre de coûts, numéro de passeport, carte de fidélité, préférences de voyage. Sans cette connexion, chaque nouveau collaborateur doit être créé manuellement dans le SBT, chaque changement de poste ou de département doit être répercuté manuellement, et les erreurs d'imputation budgétaire sont fréquentes.
L'API entre le SIRH et le SBT doit être bidirectionnelle : le SIRH pousse les données RH vers le SBT (création de compte, mise à jour du profil) et le SBT peut remonter au SIRH des informations agrégées (nombre de déplacements par collaborateur, jours d'absence pour cause de voyage).
TMC ↔ Outil de notes de frais : la fin de la saisie manuelle
Cette connexion est celle dont le retour sur investissement est le plus immédiat et le plus mesurable. Lorsque le TMC transmet automatiquement les données de réservation (prestations, montants, dates, justificatifs) à l'outil de notes de frais, le collaborateur n'a plus qu'à compléter les dépenses non couvertes (repas, taxis) et à valider. Le temps de constitution d'une note de frais passe de 25 minutes à 5 minutes. Le taux d'erreur chute de 19 % à moins de 3 %.
Les standards de données les plus courants pour cette connexion sont les fichiers XML/JSON structurés selon la norme OTA (OpenTravel Alliance) ou des formats propriétaires convertis via des connecteurs middleware.
TMC ↔ ERP : le rapprochement comptable automatisé
La connexion TMC-ERP permet d'automatiser le rapprochement entre les factures du TMC, les réservations effectuées et les budgets départementaux. Les écritures comptables sont générées automatiquement, les imputations par centre de coûts sont correctes dès l'origine et le closing mensuel est accéléré.
Cette connexion est plus complexe à mettre en place car elle implique de mapper les structures de données du TMC (segments aériens, nuitées hôtelières, locations de véhicules) avec les comptes analytiques et les centres de coûts de l'ERP. Un travail de paramétrage initial de 2 à 4 semaines est généralement nécessaire, mais le gain en temps de traitement comptable est considérable.
TMC ↔ Plateforme de duty of care : la sécurité en temps réel
La connexion entre le TMC et la plateforme de sécurité des voyageurs (International SOS, Healix, Riskline, ou solution interne) permet de localiser automatiquement les collaborateurs en déplacement et de croiser leur position avec les alertes de sécurité en temps réel. En cas de crise, le temps de réaction passe de plusieurs heures (identification manuelle des voyageurs concernés) à quelques minutes (alerte automatique aux personnes dans la zone impactée).
Architecture technique : les approches possibles
Trois architectures techniques sont envisageables pour connecter vos outils voyage.
Le point à point. Chaque système est connecté directement aux autres via des API bilatérales. Cette approche est simple pour 2-3 connexions mais devient rapidement ingérable lorsque le nombre de systèmes augmente (avec N systèmes, il faut potentiellement N×(N-1)/2 connexions). Elle est adaptée aux PME avec un écosystème limité.
Le middleware (ESB/iPaaS). Un middleware central (Enterprise Service Bus ou Integration Platform as a Service, comme MuleSoft, Dell Boomi ou Zapier) sert de hub entre tous les systèmes. Chaque système ne doit se connecter qu'au middleware, qui se charge de transformer et de router les données vers les destinataires appropriés. Cette approche est recommandée pour les ETI et les grandes entreprises.
L'API management platform. Les TMC les plus avancés exposent leurs données via une API management platform qui standardise les interfaces, gère l'authentification, contrôle les débits et monitore les échanges. CTA Business Travel propose une plateforme de ce type dans son offre Business Connect, permettant aux clients de connecter facilement leurs systèmes internes.
Étude de cas : un laboratoire pharmaceutique connecte son écosystème voyage
Un laboratoire pharmaceutique français de 3 000 collaborateurs, dont 500 voyageurs réguliers, utilisait 5 systèmes distincts pour gérer ses déplacements : un SBT pour les réservations, un outil de notes de frais (SAP Concur), un ERP (SAP), un SIRH (Workday) et une plateforme de duty of care (International SOS). Aucun de ces systèmes n'était connecté aux autres.
La conséquence était une débauche de travail administratif. Les assistantes saisissaient les données de réservation dans le SBT puis re-saisissaient les mêmes informations dans SAP Concur. Le service comptable rapprochait manuellement les factures du TMC avec les écritures SAP. Les mises à jour de profils voyageurs (changement de département, nouveau passeport) devaient être effectuées dans 3 systèmes différents. En cas d'alerte sécurité, le responsable duty of care devait croiser manuellement la liste des voyageurs du TMC avec les alertes International SOS.
Le projet de connexion, mené avec CTA Business Travel et un intégrateur spécialisé, a duré 4 mois. Quatre connecteurs API ont été déployés : Workday → SBT (synchronisation des profils), SBT → SAP Concur (transfert automatique des réservations), SBT → SAP (écritures comptables automatisées) et SBT → International SOS (localisation temps réel).
Résultats à 12 mois : le temps de traitement d'une note de frais a été réduit de 65 % (de 25 à 9 minutes en moyenne). Les erreurs d'imputation comptable ont chuté de 78 %. Le temps de closing mensuel lié aux déplacements a été divisé par trois. La capacité de localisation des voyageurs est passée de « 2 heures en mobilisation de crise » à « instantanée ». L'économie annuelle en temps administratif est estimée à 120 000 euros.
Les défis de l'intégration API
La standardisation des données. Chaque éditeur a ses propres formats et structures de données. Le mapping entre les champs d'un système et ceux d'un autre nécessite un travail de spécification précis. Les standards sectoriels (NDC pour l'aérien, HTNG pour l'hôtellerie) progressent mais ne couvrent pas encore tous les cas d'usage.
La sécurité. Les données de voyage sont des données personnelles sensibles (localisation, habitudes de déplacement). Les connexions API doivent être sécurisées (HTTPS, authentification OAuth 2.0, chiffrement des données en transit et au repos) et conformes au RGPD.
La maintenance. Les API évoluent : les éditeurs publient de nouvelles versions, dépréciées d'anciennes fonctionnalités, modifient leurs structures de données. Un plan de maintenance et de mise à jour des connecteurs est indispensable.
Conclusion
La connexion des outils voyage via API n'est plus un luxe réservé aux grands groupes. Les solutions cloud et les plateformes d'intégration low-code rendent ces projets accessibles aux ETI et aux grosses PME. Le retour sur investissement, principalement en gain de temps administratif et en qualité de données, justifie largement l'investissement. Le conseil clé : commencez par les deux connexions les plus impactantes (TMC-notes de frais et TMC-SIRH), démontrez le ROI, puis élargissez progressivement.
