API · intégrations · données
API et intégrations : sortir de la double saisie
Ce qu'une API de VRMS permet réellement, ce qu'elle ne permet pas, et les questions à poser avant de lancer une intégration.
La double saisie est le symptôme le plus visible d’un système d’information mal articulé. Un bien créé dans le VRMS, ressaisi dans le site web, ressaisi dans la comptabilité, ressaisi dans le tableur de suivi. À chaque copie, une occasion de divergence.
Les API existent pour ça. Encore faut-il savoir ce qu’on peut en attendre.
Ce que les API de VRMS permettent généralement
La plupart des éditeurs sérieux exposent, sous une forme ou une autre :
- la lecture du catalogue de biens, avec leurs attributs et leurs médias ;
- la lecture des disponibilités et des tarifs ;
- la lecture des réservations, avec leur statut ;
- des notifications d’événement — création, modification, annulation.
Cela suffit à alimenter un site web, un tableau de bord, un CRM ou une chaîne d’attribution. C’est déjà l’essentiel des besoins d’une agence.
Ce sur quoi il faut se renseigner avant de s’engager
L’écriture. Lire est presque toujours possible. Écrire — créer un bien, modifier un tarif, poser une réservation — l’est beaucoup moins souvent, et parfois sous conditions. Vérifiez avant de concevoir.
Les quotas. Le nombre d’appels autorisés par minute ou par jour détermine votre architecture. Une synchronisation temps réel et une synchronisation nocturne ne demandent pas le même travail.
La fraîcheur. Certaines données sont mises en cache côté éditeur. Un tarif lu par API peut avoir quelques minutes de retard : acceptable pour un tableau de bord, problématique pour un moteur de réservation.
Les webhooks. Leur présence change tout. Sans eux, il faut interroger en boucle, ce qui consomme du quota et introduit de la latence.
L’erreur d’architecture la plus fréquente
Connecter chaque outil à chaque outil. Avec cinq systèmes, on peut créer jusqu’à vingt liaisons, chacune à maintenir, chacune susceptible de casser à la prochaine mise à jour.
L’alternative tient en une phrase : le VRMS reste la source de vérité pour les biens, les disponibilités et les réservations ; tout le reste s’y branche, jamais l’inverse. Les flux partent du VRMS vers un point de collecte unique, et les autres outils lisent depuis ce point.
Cette discipline coûte un peu plus cher au départ. Elle évite la réécriture complète au bout de deux ans.
Les quatre questions à poser avant de démarrer
- Quelle donnée fait autorité, et qui a le droit de la modifier ?
- Que se passe-t-il si le flux s’interrompt trois jours — quelqu’un s’en aperçoit-il ?
- Combien de temps faut-il pour rejouer un historique après une panne ?
- Qui reprend la main si l’intégrateur n’est plus disponible ?
La quatrième est la plus importante et la plus souvent oubliée. Une intégration que personne ne sait reprendre est une dette, pas un actif. Documentation, accès et code doivent rester chez vous.