Aller au contenu

Versions et compatibilité

Le widget est livré depuis une adresse unique et se met à jour sans action de votre part. Cette page indique ce que cette mise à jour peut modifier.

<script src="https://app.useservice.app/widget/widget.js" async></script>

Cette adresse est stable. Elle redirige vers un fichier dont le nom contient une empreinte du contenu :

RéponseCache-Control
/widget/widget.js — 302 vers la version courantepublic, max-age=300, must-revalidate
/widget/widget.<hash>.js — le fichier lui-mêmepublic, max-age=31536000, immutable

Le navigateur revérifie donc l’adresse stable toutes les cinq minutes et conserve le fichier reçu pendant un an. Une nouvelle version atteint vos visiteurs quelques minutes après sa publication.

Copier l’URL avec empreinte dans votre page, héberger le fichier vous-même, ou laisser un plugin de cache réécrire l’adresse vous fige sur une version. Vous ne recevrez plus les correctifs, y compris de sécurité. Chargez l’adresse stable.

ServiceWidget.version; // "2.8.0"

Il s’agit de la version de l’API JavaScript — les options, méthodes et événements décrits sur ce site — et non du parcours vu par le client. Indiquez-la lors d’un signalement.

Tout ce que le client voit. La mise en page, les textes, les étapes, le style, des champs ajoutés, une formulation différente, de nouveaux états de réservation. Le parcours nous appartient et il évolue souvent.

Écrivez votre intégration sans dépendre du fonctionnement interne du widget :

  • N’interrogez pas le DOM du widget, son shadow root, ni aucun nom de classe.
  • Ne dépendez pas du nombre ni de l’ordre des étapes du parcours.
  • Ne considérez pas reservation.status comme un ensemble fermé : de nouvelles valeurs sont ajoutées.

L’API décrite sur ce site est ce sur quoi vous construisez, et nous ne la cassons pas :

  • Les options acceptées par ServiceWidget.create().
  • Les méthodes de l’instance et leur comportement.
  • Les noms d’événements et les champs déjà présents dans leurs charges utiles.
  • Les noms d’indices acceptés par setContext() et par les paramètres d’URL.
  • Le format du jeton, le nom de ses claims et la signification de locked.
  • Les paramètres ajoutés à votre return_url.

Les charges utiles gagnent des champs. Une nouvelle clé dans un événement ou dans une réponse n’est pas une rupture de compatibilité : lisez les champs dont vous avez besoin plutôt que de contrôler l’objet entier.

data-mode="manual" était le nom donné à popover par la balise de script, et ServiceWidget.open({ slug }) ouvrait un widget créé à la demande par l’objet global. Les deux ont été retirés le 6 août 2026. data-mode="manual" se comporte désormais comme toute valeur non reconnue et retombe sur inline ; open() ne prend plus d’argument et pilote le widget monté par la balise de script.

Une version antérieure de cette page annonçait les deux comme « acceptés indéfiniment » et présents sur des sites de restaurants qui ne seraient jamais modifiés. C’était une supposition, pas un constat : Service publie l’intégralité des extraits d’intégration utilisés, et le back-office émet désormais data-mode="popover". Les retirer n’a rien coûté et supprime un second nom pour une même chose.

Une conséquence mérite d’être énoncée clairement : une balise de script pilote un seul restaurant. Un déclencheur [data-service-widget-open] portant son propre data-slug obtenait auparavant son propre widget. Ce n’est plus le cas : il est ignoré, avec une explication en console, plutôt que d’ouvrir en silence le restaurant servi par la balise de script. Pour plusieurs restaurants sur une même page, appelez create() par restaurant et conservez les identifiants retournés.

Il n’y a pas de calendrier de dépréciation ici, parce que rien n’est déprécié. Si cela changeait, une rupture de compatibilité serait annoncée sur cette page avant sa mise en production, l’ancien comportement étant conservé pendant la durée annoncée. D’ici là, la garantie ci-dessus constitue toute la politique.