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.
Le bundle que vous chargez
Section intitulée « Le bundle que vous chargez »<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éponse | Cache-Control |
|---|---|
/widget/widget.js — 302 vers la version courante | public, max-age=300, must-revalidate |
/widget/widget.<hash>.js — le fichier lui-même | public, 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.
La version que vous exécutez
Section intitulée « La version que vous exécutez »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.
Ce qu’une mise à jour peut modifier
Section intitulée « Ce qu’une mise à jour peut modifier »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.statuscomme un ensemble fermé : de nouvelles valeurs sont ajoutées.
Ce qu’une mise à jour ne modifiera pas
Section intitulée « Ce qu’une mise à jour ne modifiera pas »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.
Noms retirés
Section intitulée « Noms retirés »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.
Si une rupture devenait nécessaire
Section intitulée « Si une rupture devenait nécessaire »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.