La tarification dynamique ne fonctionne que si vos partenaires en itinérance la voient vraiment

Vous avez mis en place la tarification dynamique. Votre plateforme augmente désormais le prix pendant les heures de pointe, le baisse la nuit, réagit à la demande comme prévu. Sur le papier, chaque session devrait être facturée exactement comme vous l'avez conçu.

Puis vous regardez les CDR de votre trafic en itinérance et une partie ne correspond manifestement pas. Une session qui aurait dû être facturée à votre tarif du soir s'est réglée sur ce qui ressemble à votre ancien tarif fixe. Personne n'a rien changé de votre côté. Rien ne s'est techniquement cassé. La mise à jour du prix n'est tout simplement jamais arrivée complètement là où elle devait aller.

C'est un problème plus discret que la plupart des discussions sur la tarification, car il ne se manifeste pas comme une erreur. Il se manifeste comme un chiffre d'affaires légèrement inférieur à ce que votre propre tableau de bord annonce, dilué sur suffisamment de sessions pour passer facilement pour du bruit.

Où se situe vraiment l'écart

Un tarif dynamique n'est pas une seule mise à jour, c'est une diffusion. Votre plateforme envoie le nouveau prix via OCPI (ou quel que soit votre protocole) vers chaque connexion censée le recevoir : intégrations eMSP directes, hubs d'itinérance, réseaux de cartes, partenaires applicatifs. Chacune de ces liaisons est une relation technique distincte, construite et maintenue par une partie différente, selon son propre cycle de publication.

La documentation publique sur l'intégration OCPI est assez franche à ce sujet : la gestion des tarifs est décrite comme l'une des parties les plus sensibles du protocole, précisément parce qu'une incohérence tarifaire signifie que le prix vu par le conducteur diffère du prix réellement facturé. Les incohérences de CDR sont également signalées comme l'une des causes les plus fréquentes de problèmes d'intégration OCPI, souvent liées à la manière dont la partie réceptrice a interprété ou mis en cache le tarif, et non à une erreur du côté émetteur. Le guide OCPI d'AMPECO et l'analyse du protocole de Codibly désignent tous deux ce point comme l'un des problèmes d'intégration les plus courants, pas un cas isolé.

En pratique, cela signifie que la mise à jour envoyée par votre plateforme ne se comporte jamais deux fois de la même façon. Un eMSP l'applique en moins d'une heure. Un hub met en cache l'ancien tarif plus longtemps que prévu. Une connexion en itinérance retombe sur un prix par défaut, simplement parce que son intégration a été conçue ainsi, quoi que vous envoyiez. Aucune de ces parties ne fait quoi que ce soit de mal selon ses propres critères. Elles ne sont simplement pas conçues pour un tarif qui change aussi souvent que le vôtre aujourd'hui.

Pourquoi c'est facile à manquer

Votre propre plateforme vous confirme que la mise à jour du tarif est partie. C'est vrai, et ce n'est pas non plus toute l'histoire, car "envoyé" et "reçu et appliqué" sont deux événements distincts, qui se produisent sur deux systèmes que vous ne contrôlez pas.

Le seul endroit où l'écart apparaît vraiment, c'est dans les CDR qui reviennent ensuite, et seulement si vous vérifiez le prix auquel une session s'est réellement réglée par rapport à ce que votre planning prévoyait à cette heure-là, sur ce connecteur, via cette route d'itinérance précise. La plupart des rapprochements de facturation vérifient si les totaux concordent, pas si chaque session a été tarifée selon le tarif prévu.

Les routes comptent plus qu'on ne le pense. Le hub ou l'eMSP par lequel transite une session en itinérance n'est pas fixe. Les partenaires migrent entre hubs, renégocient des connexions, ou modifient leur intégration à leur propre rythme, sans nécessairement en informer chaque CPO de l'autre côté. Une route qui captait fidèlement vos mises à jour tarifaires pendant des mois peut discrètement cesser de le faire après un changement de leur côté.

Ce qui cloche de votre côté (le CPMS)

Une partie de l'écart commence avant même que la mise à jour ne quitte votre plateforme :

• Un envoi de tarif qui se déclenche une seule fois à l'enregistrement, sans nouvelle tentative automatique si une connexion au hub était temporairement coupée à ce moment-là.
• Des profils ou versions de tarifs qui se chevauchent sur un même connecteur, rendant ambigu celui que la partie réceptrice est censée appliquer.
• Aucune alerte lorsqu'un envoi OCPI vers une route précise échoue ou est rejeté : il n'arrive tout simplement pas, en silence, et rien dans votre propre système ne le signale.
• Des mises à jour tarifaires groupées ou planifiées plutôt qu'envoyées en temps réel, ce qui ouvre une fenêtre de retard supplémentaire par-dessus celle qui existe déjà en aval.
• Des identifiants ou modèles de tarifs incohérents entre connecteurs et hubs, hérités d'anciennes intégrations jamais entièrement standardisées.

Rien de tout cela n'est exotique. Ce sont le genre de choses qui s'accumulent discrètement dans tout CPMS ayant construit ses intégrations d'itinérance connexion par connexion.

Ce qui cloche de l'autre côté (les MSP et les hubs)

Le reste de l'écart se trouve chez des parties que vous ne contrôlez pas du tout :

• Des hubs ou eMSP qui mettent un tarif en cache plus longtemps que votre fréquence de mise à jour, parce que leurs systèmes ont été conçus pour des tarifs qui changent occasionnellement, pas quotidiennement ou toutes les heures.
• Des intégrations partenaires conçues pour l'interrogation périodique plutôt que pour des mises à jour push, si bien qu'un changement de prix attend simplement le prochain cycle d'interrogation.
• Un repli silencieux vers un tarif par défaut ou le dernier connu, quand un système récepteur échoue à analyser ou valider le nouvel objet tarifaire.
• Des réseaux de cartes et intégrations d'applications plus anciennes sans réel moyen d'afficher ou de facturer un tarif dynamique.
• Des changements de routage : un partenaire migre vers un autre hub ou renégocie une connexion, et la route qui captait fidèlement vos mises à jour cesse de le faire, sans que personne ne vous prévienne.

Rien de tout cela ne signifie que la tarification dynamique ne vaut pas la peine. Cela signifie que sa valeur n'apparaît que sur le trafic qui reçoit réellement votre prix, et à l'heure actuelle, pour la plupart des exploitants, personne ne surveille toute la chaîne d'assez près pour savoir de quel trafic il s'agit.

Pourquoi cela reste non résolu pour la plupart des exploitants

Ce n'est pas un problème que l'on règle une fois pour toutes. Les problèmes côté CPMS et côté MSP continuent tous deux de réapparaître à mesure que les partenaires modifient leurs intégrations, que les hubs migrent, et que de nouvelles connexions d'itinérance s'ajoutent. Le suivre correctement signifie rapprocher en continu les CDR de votre planning tarifaire, par route plutôt que par partenaire, et le faire assez vite pour que cela ne grignote pas discrètement le chiffre d'affaires d'un trimestre avant que quiconque ne le remarque.

C'est exactement l'écart que Proxilink a été conçu pour combler. Nous avons développé un système qui surveille en continu la synchronisation tarifaire entre le CPMS et les connexions d'itinérance pour nos clients, en repérant les routes où un prix dynamique n'arrive pas réellement, avant que cela ne se transforme en mauvaise surprise sur le chiffre d'affaires trois mois plus tard. Il tourne aujourd'hui en direct pour des exploitants.

Si cela ressemble à quelque chose que vous n'avez jamais vraiment vérifié sur votre propre réseau, nous serons ravis de vous montrer à quoi cela ressemblerait pour votre configuration.