Aller au contenu
← Retour au blog

Également disponible en English

Dans les coulisses

Lire un e-mail de réservation revendeur, un problème qui ne reste jamais réglé

Par ParkAgenda Team
L'ecran d'un portable qui eclaire un bureau plonge dans le noir, tard le soir.

La capture automatique des réservations se vend comme une intégration. C'est surtout du traitement de texte, et le traitement de texte cesse de fonctionner le jour où un revendeur modifie son propre modèle de confirmation.

Ce n'est un reproche adressé à personne. C'est la forme du problème. La seule vraie décision de conception, c'est ce que fait le système le matin où il ne comprend plus un e-mail qu'il comprenait la veille : deviner en silence, ou refuser bruyamment.

Ce qui arrive vraiment dans la boîte

Dans la plupart des relations revendeur, rien n'arrive par un flux. Un e-mail arrive.

Un client réserve en juin sur un comparateur. Le système de ce comparateur envoie une confirmation au parking, mise en page comme ce système met en page, depuis l'adresse que ce système utilise. Pas de schéma, pas de numéro de version, pas de contrat technique. Un objet, un corps de message, et l'idée que quelqu'un se fait d'une date.

Certains canaux font mieux. Parkos expose une API que nous interrogeons par curseur, marchand par marchand, avec une fenêtre de recouvrement pour ne pas rater une réservation modifiée pendant la synchronisation. Solution Park passe par un pont de scrutation qui s'authentifie encore sur un formulaire de connexion HTML, reste derrière un drapeau désactivé par défaut, et est documenté en interne comme à retirer. C'est la description honnête d'une intégration héritée qui fonctionne. Le reste, c'est de l'e-mail, plus un CSV nocturne quand un revendeur accepte d'en produire un.

Quatre chemins, une seule fiche

Quel que soit le chemin, le résultat doit être identique. Une réservation captée par e-mail, tirée d'une API, importée d'un CSV ou saisie au comptoir doit produire la même fiche, avec les mêmes champs, attribuée à sa source.

Ce point compte plus qu'il n'en a l'air. Le taux de commission est porté par le couple parking et canal. C'est donc l'attribution de source qui donne un sens au chiffre d'affaires par canal, six mois plus tard. Une ingestion propre rend l'analyse gratuite. Une ingestion approximative fait porter la même erreur à tous les chiffres en aval.

La fiche doit porter la plaque, le modèle, la couleur, le vol aller et le vol retour, le nombre de passagers, le montant déjà payé, le reste à payer sur place et les options vendues par le revendeur. Pas par gourmandise : le chauffeur de 5 h a besoin de la couleur, et le comptoir de 22 h a besoin du solde.

Six pièges, et aucun n'est théorique

L'expéditeur. Une liste blanche d'adresses exactes, pas de domaines. Les revendeurs envoient leurs messages transactionnels via des plateformes d'emailing, donc l'adresse réelle est souvent un sous-domaine dont personne ne vous a parlé, et une règle au niveau du domaine est assez large pour laisser passer une fausse confirmation. Les adresses exactes sont plus pénibles, et c'est le bon choix.

La référence. Insertion ou mise à jour idempotente sur le triplet parking, source, numéro de référence. La même réservation sera livrée deux fois. Elle sera aussi relivrée, modifiée, trois semaines plus tard, et la modification arrive parfois avant l'original parce qu'un relais a retenu l'un des deux.

La plaque. La même semaine, le même canal envoie AB-123-CD, AB123CD et ab 123 cd, et parfois un ancien format 1234 AB 75. On conserve ce qui est arrivé, on normalise ce qu'on indexe, et on ne confond jamais les deux. L'agent qui cherche une plaque à la barrière ne tapera pas les tirets.

Le nom, et les accents. Jean-Philippe Bérard arrive en BERARD JEAN PHILIPPE, en J.P. Berard et en Jean Philippe Berard, sur trois messages du même compte. Pire : quand le message est encodé en ISO-8859-1 et lu comme de l'UTF-8, Bérard devient Bérard, et ce nom-là finit imprimé sur la fiche que le voiturier pose sur le tableau de bord. On ne rapproche donc jamais deux réservations sur un nom. C'est aussi pour ça qu'une caméra ne règle rien : la LAPI lit la plaque parfaitement et ne sait toujours pas laquelle de ces trois orthographes a réservé.

Les dates. Heure locale sans fuseau, c'est ce que presque tous les revendeurs envoient. 03/04, c'est le 3 avril ici et le 4 mars pour un analyseur écrit ailleurs. Un séjour qui enjambe le dernier dimanche d'octobre dure une heure de plus qu'une simple soustraction, et ce dimanche-là est aussi le plus gros week-end de retour de l'automne.

Le doublon. Déduplication sur l'identifiant de message d'abord, sur une empreinte du corps ensuite. La deuxième règle existe parce qu'une copie transférée a un identifiant différent et un contenu identique, et parce que certains expéditeurs réessaient avec un identifiant neuf après un délai dépassé.

Refuser coûte moins cher que deviner : le calcul

Chiffres d'exemple. Parking de 400 places, 900 réservations par mois, 60 % via des revendeurs, dont 300 pour un seul d'entre eux. Un mardi, ce revendeur remplace dans son modèle le libellé Immatriculation par Plaque du véhicule. Personne ne prévient, parce que de leur côté il ne s'est rien passé.

L'analyseur qui devine. Il enregistre la réservation avec une plaque vide. Les réservations arrivent en moyenne 21 jours avant le séjour, donc le premier symptôme est une voiture au comptoir dont la fiche n'a pas de plaque, trois semaines plus tard. Environ 210 réservations ont le même trou, et quelqu'un passe une journée à ressaisir 210 plaques dans 210 e-mails archivés, en pleines vacances.

L'analyseur qui refuse. Il ne peut pas remplir un champ obligatoire, donc il n'applique pas la réservation. Quatorze fiches de contrôle apparaissent le matin même, chacune avec l'e-mail brut et le motif. Quelqu'un en ouvre une, voit le libellé, l'adaptateur change d'une ligne, et les quatorze sont retraitées avant midi. Rien n'est entré dans la file d'exploitation dans un état que quiconque aurait dû croire.

Même bug, même jour, deux matinées différentes. C'est tout l'argument.

La file de contrôle, et les quatre gestes qui la vident

Ce qui ne peut pas être appliqué sans risque est retenu, pas jeté. C'est la partie d'une chaîne de capture qu'il faut regarder, parce qu'elle n'existe que si quelqu'un a décidé qu'elle devait exister.

Une fiche de contrôle conserve le message brut et le motif de l'échec. Une personne a quatre gestes :

  • Promouvoir la fiche en réservation, une fois l'élément manquant fourni.
  • Retraiter, ce qu'on fait après avoir corrigé l'adaptateur, pour que les échecs d'hier soient rejoués contre le code d'aujourd'hui.
  • Autoriser l'expéditeur, la réponse quand un revendeur a changé d'adresse d'envoi.
  • Écarter, la réponse pour un message publicitaire tombé sur l'adresse d'intégration.

Rien ne disparaît en silence et rien n'entre dans la journée par supposition. Une réservation dont le système n'est pas sûr vaut moins que pas de réservation du tout, parce qu'un chauffeur va agir dessus.

Pourquoi la liste des canaux nommés est courte

Chaque canal nommé est un analyseur que quelqu'un maintient. Un analyseur maintenu est un engagement avec un nom en face, pas une case cochée.

Un canal déclare son format d'intégration, et un adaptateur traduit ce format en une intégration analysée. Ajouter un canal, c'est écrire un adaptateur, le tester contre de vrais messages de ce canal, et le reprendre la prochaine fois que le canal change quelque chose. C'est comme ça que Parkos et Solution Park ont été ajoutés, et c'est la réponse honnête à la question « est-ce que vous intégrez X ». Oui, après ce travail-là, mené avec votre canal, et voici ce qu'il représente.

La chaîne d'intégration, les adaptateurs et la file de contrôle ont été construits par l'équipe d'ingénierie de JADEV, le groupe auquel ParkAgenda appartient. C'est aussi pour cette raison que ces décisions sont écrites quelque part plutôt que retenues de mémoire.

Ce que ce n'est pas

À dire clairement, sinon la démonstration se termine sur une question à propos du catalogue de connecteurs.

Il n'y a pas de programme d'API publique ou partenaire. Pas de clés d'API, pas d'identifiants applicatifs, pas d'intégration en libre-service : tout appelant a besoin d'une identité dans le locataire ParkAgenda. Il n'y a pas non plus de webhooks sortants, donc rien n'est poussé nulle part. Et la synchronisation est à sens unique : ParkAgenda lit une source par curseur et n'y écrit jamais, ce qui veut dire qu'une annulation faite chez vous n'annule rien chez le revendeur.

Il existe bien une API REST documentée, décrite en OpenAPI. C'est contre elle qu'un connecteur sur mesure se construit, par notre équipe, avec votre prestataire.

Cinq questions à poser à un éditeur

  • Quels canaux sont nommés, et chacun est-il un analyseur maintenu ou un logo sur une page ?
  • Que devient une réservation que le système n'arrive pas à rapprocher ? Où va-t-elle, qui la voit, combien de temps y reste-t-elle ?
  • Puis-je ouvrir une réservation et voir le message brut qui l'a produite ?
  • Que coûte l'ajout de mon quatrième revendeur, en délai et en argent, et qui l'écrit ?
  • Est-ce que quelque chose est réécrit chez le revendeur ?

Questions fréquentes

Pouvez-vous lire le format de notre revendeur sans rien lui demander ?

C'est le principe. Le revendeur continue d'envoyer ce qu'il envoie déjà, et un adaptateur le traduit chez nous. Demander à un canal qui sert des milliers de parkings de modifier son modèle pour un seul d'entre eux n'est pas un plan.

En combien de temps une réservation non rapprochée arrive-t-elle devant une personne ?

Elle apparaît dans la file de contrôle au moment du traitement du message, avec l'e-mail brut joint. Il n'y a pas de fenêtre de traitement à attendre. Ce qui varie, c'est le délai avant que quelqu'un regarde, et cela relève du planning, pas du logiciel.

ParkAgenda renvoie-t-il quelque chose au revendeur ?

Non. L'intégration est à sens unique. Il n'y a pas de webhooks sortants et rien n'est réécrit dans une source.

La suite

Si vous comparez des logiciels, emportez ces cinq questions en démonstration et demandez à voir la file de contrôle à l'écran. Un éditeur qui en a construit une vous montrera une file avec de vrais échecs dedans, parce qu'une chaîne qui n'échoue jamais est une chaîne qui devine.

Sur le même sujet : ce qu'un système de réservation doit faire quand vous ne possédez pas le canal de vente, ce que veut dire intégrer un parking, et qui fait le câblage, et la page fonctionnalités pour la file elle-même.

Cet article vous a plu ?

Prêt à voir ParkAgenda en action ?

Discutons de comment ParkAgenda peut transformer vos opérations de parking.

  • Mise en service en 24 heures

    Parkings, sources et opérateurs configurés avec vous.
  • Vos données restent les vôtres

    Exportez n’importe quelle vue en CSV ou PDF, quand vous voulez.
  • Support FR et EN

    Par des gens qui ont tenu un comptoir de parking.