Fuseau horaire, locale et langue dans les API du navigateur

Un navigateur peut formater une date avec une locale, déclarer une autre langue préférée, envoyer une troisième préférence linguistique à un serveur et utiliser un fuseau horaire sans rapport avec le proxy. BotBrowser permet de configurer le fuseau horaire, la locale et les langues, mais ne garantit pas la langue choisie par un site et ne prouve pas un emplacement physique. Configurez chaque champ à la couche qui le contrôle, puis inspectez les valeurs JavaScript et la réponse HTTP utiles au workflow.

La distinction essentielle oppose valeur par défaut et choix explicite. Intl.DateTimeFormat() sans argument utilise la locale et le fuseau par défaut de l'environnement. Fournir une locale ou un timeZone explicite ne change que cet appel de formatage ; cela ne réécrit ni navigator.language, ni Accept-Language, ni un cookie de site, ni le fuseau configuré du navigateur. Un contrôle régional doit donc nommer le signal mesuré, sans traiter « locale » comme un diagnostic complet.

TL;DR

• Un fuseau horaire présente les instants en heure civile locale ; un fuseau IANA n'est pas un décalage UTC fixe.
• Une locale contrôle les conventions de formatage, comme les séparateurs décimaux et les noms de mois ; elle ne choisit pas seule la langue d'un site.
• navigator.language et navigator.languages décrivent les préférences du navigateur. Accept-Language les propose au serveur, qui peut négocier une réponse ou les ignorer.
• Un site peut mémoriser sa langue dans un cookie ou un compte ; ce choix est distinct des préférences du navigateur et de la négociation HTTP.
• Pour chaque champ BotBrowser, une valeur CLI explicite prime sur configs du profil ; sans valeur concrète, auto dérive le réglage de la route proxy. --bot-location est un contrôle de géolocalisation distinct.

Sommaire

• Regarder la vidéo
• Nommer le signal avant de le modifier
• Valeurs par défaut et options Intl explicites
• Un fuseau horaire n'est pas un décalage
• Préférences linguistiques et négociation HTTP
• Cookies et langue de l'application
• Priorité BotBrowser par champ
• Table de décision pour la configuration
• Requête de diagnostic à copier
• Dépannage par couche observée
• Limites et interprétation prudente
• Conclusion pratique

Regarder la vidéo

Cette vidéo en anglais compare fuseau horaire, locale, préférences linguistiques et en-tête Accept-Language dans une démonstration contrôlée sur une page locale. Elle utilise des valeurs de test déclarées ; elle ne représente ni utilisateur réel, ni route proxy, ni résultat de géolocalisation.

Nommer le signal avant de le modifier

« Identité régionale » résume plusieurs notions, mais ne désigne pas une propriété unique du navigateur. Une page de test, une requête réseau, une page rendue côté serveur et un site après connexion peuvent exposer des décisions différentes. Si deux observations divergent, notez où chacune a été lue : environnement JavaScript, en-têtes de requête, en-têtes de réponse, stockage applicatif ou API soumise à permission. Cela évite de changer un flag de locale pour corriger un contenu choisi par cookie.

• Fuseau horaire : règles qui interprètent un instant en date et heure locales. JavaScript l'expose notamment avec Intl.DateTimeFormat().resolvedOptions().timeZone et les valeurs par défaut du formatage des dates.
• Locale : préférence de langue et de région BCP 47 utilisée par les API d'internationalisation pour formater ou comparer. en-GB et de-DE en sont des exemples ; une locale n'est ni une ville ni une coordonnée.
• Préférences linguistiques : liste ordonnée exposée par navigator.languages; navigator.language représente normalement la préférence principale. Elles orientent la négociation sans contraindre le serveur à choisir une traduction.
• Géolocalisation : résultat renvoyé après une demande à l'API Geolocation autorisée par le contexte. Elle ne découle pas du formatage Intl et ne se déduit pas d'un nom de fuseau.
• Langue du site : langue choisie par l'application pour son interface ou son contenu, selon la requête, l'URL, un cookie, le compte ou une politique serveur.

Une page peut appeler new Intl.NumberFormat('fr-FR') alors que la langue principale du navigateur reste en-US. Le serveur peut recevoir une préférence Accept-Language anglaise et répondre en français parce que l'URL est /fr/. Le site peut ensuite mémoriser le français dans un cookie. Aucune de ces observations ne prouve à elle seule qu'une autre couche est mal configurée.

Cette distinction circonscrit aussi les affirmations géographiques. Un fuseau couvre plusieurs lieux et un pays peut utiliser plusieurs fuseaux. Une locale n'encode pas un emplacement précis. La langue préférée peut être celle du travail plutôt que celle du pays du proxy. Traiter ces valeurs comme une chaîne stricte de correspondance entre pays produit de fausses alertes et des substitutions inutiles.

Valeurs par défaut et options Intl explicites

L'API Internationalization d'ECMAScript (Intl) fournit un formatage sensible à la locale. Sans option, le formateur utilise la valeur par défaut de l'environnement ; une locale fournie explicitement ne concerne que le formateur appelé. Cette distinction doit aussi apparaître dans les diagnostics :

const defaultDate = new Intl.DateTimeFormat().format(new Date());
const britishDate = new Intl.DateTimeFormat('en-GB').format(new Date());
const defaultNumber = new Intl.NumberFormat().format(1234567.89);
const frenchNumber = new Intl.NumberFormat('fr-FR').format(1234567.89);

Aucune sortie fixe n'est indiquée : les chaînes dépendent des données de locale de l'environnement, de l'instant et des options. Pour un contrôle reproductible, figez l'instant d'entrée et inspectez les options résolues et la chaîne visible. Le résultat ne décrit que cet environnement et cette entrée, pas tous les processus ou workers du navigateur.

resolvedOptions() indique les paramètres retenus pour cette instance. Pour un formateur par défaut, locale et timeZone décrivent les valeurs résolues de l'environnement. Pour un formateur créé avec 'en-GB', locale décrit cette demande après résolution. Cela ne rapporte ni navigator.language, ni la configuration du profil, ni la langue d'une requête HTTP ultérieure.

const defaultFormatter = new Intl.DateTimeFormat();
const explicitFormatter = new Intl.DateTimeFormat('en-GB', {
  timeZone: 'Europe/London',
  dateStyle: 'medium',
});

console.log(defaultFormatter.resolvedOptions());
console.log(explicitFormatter.resolvedOptions());

Forme illustrative uniquement : cet extrait n'a pas été exécuté ici ; l'environnement cible détermine les propriétés et valeurs exactes. La comparaison utile porte sur l'emploi d'un formateur par défaut ou d'options explicites locales. Si l'application fournit sa propre locale, changer la valeur par défaut du navigateur peut ne rien changer.

Une bibliothèque peut appeler Intl.DateTimeFormat() sans locale, fournir une locale fixe ou lire une préférence applicative. Examinez le code ou le point d'appel avant de modifier le navigateur. Le guide de formatage des dates et des heures distingue la politique de fuseau horaire de l'application des valeurs par défaut du navigateur.

La correspondance de locale ne traduit pas du texte arbitraire. Intl formate les données prises en charge, compare des chaînes ou choisit une locale parmi une liste demandée et les données disponibles. Il ne traduit pas une page, ne réécrit pas une URL et ne remplace pas la politique du site. Du texte anglais accompagné d'un formatage numérique allemand peut être le comportement voulu.

Un fuseau horaire n'est pas un décalage

Un instant est un point sur la chronologie UTC. Un fuseau nommé associe cet instant aux champs locaux et à un décalage selon ses règles. America/New_York peut avoir des décalages différents selon la date et les données de fuseau en vigueur. UTC-5 exprime un décalage fixe, pas le même ensemble de règles historiques et futures. Comparez le nom IANA si l'exigence porte sur les règles d'une région ; comparez le décalage si elle porte sur un instant donné.

Date.prototype.getTimezoneOffset() renvoie, en minutes et selon la convention de signe JavaScript, le décalage de la date représentée. Ce n'est pas un identifiant de région stable. Deux fuseaux peuvent partager un décalage à un instant et diverger à un autre. Une lecture ne prouve donc ni un fuseau particulier ni le comportement des transitions saisonnières.

const instant = new Date('2026-01-15T12:00:00Z');
const zone = new Intl.DateTimeFormat().resolvedOptions().timeZone;
const offsetMinutes = instant.getTimezoneOffset();

console.log({ zone, offsetMinutes });

Requête illustrative, pas un résultat BotBrowser enregistré. Le décalage est calculé pour cette date dans le fuseau par défaut de l'environnement. Pour comparer deux dates, examinez-en une de chaque côté de la transition pertinente ; ne présumez ni sa date ni son résultat sans vérifier les règles actuelles de la région. Les bases de fuseaux et les règles légales peuvent changer indépendamment du code.

Locale et fuseau sont indépendants. Un formatage en-GB avec l'heure de America/New_York peut être intentionnel, par exemple pour consulter le calendrier d'un bureau new-yorkais. Un site peut aussi afficher un événement dans son fuseau tout en utilisant la langue du navigateur pour le texte. La relation appropriée dépend du sens applicatif, pas d'une règle « même pays ».

Les dates seules demandent de la prudence. 2026-10-18 peut être interprété autrement par les bibliothèques et API qu'un instant tel que 2026-10-18T09:00:00Z. Convertir une date métier en instant peut déplacer le jour affiché dans un autre fuseau. Pour « la réunion commence à cet instant », conservez un instant et formatez-le dans le fuseau choisi. Pour « le bureau est fermé à cette date locale », conservez une date de calendrier sans conversion qui en changerait le sens.

Préférences linguistiques et négociation HTTP

navigator.language et navigator.languages décrivent les langues préférées de l'environnement ; la première est la principale, la seconde est la liste ordonnée lorsqu'elle est disponible. Le navigateur peut envoyer Accept-Language, souvent avec des coefficients de qualité. Cet en-tête est une entrée de négociation, pas la garantie que la réponse adoptera la première langue ou même une langue de la liste.

Un serveur HTTP peut utiliser Accept-Language, mais le résultat dépend aussi de l'URL, des valeurs applicatives, des traductions disponibles, de l'authentification ou des règles produit. Content-Language peut renseigner sur la représentation sans nécessairement décrire chaque texte d'une page complexe. Vérifiez la requête et la réponse associées à la route examinée.

GET /account/ HTTP/1.1
Accept-Language: fr-CA,fr;q=0.9,en;q=0.8

Requête illustrative ; aucune requête réseau n'a été faite pour cet article. La liste peut aider un serveur à choisir une représentation française s'il la prend en charge. Il peut plutôt rediriger, suivre la locale de l'URL, demander un choix ou appliquer une autre politique. La référence MDN sur Accept-Language décrit cet en-tête et son rôle.

Ne confondez pas langue du navigateur, formatage de locale et langue HTTP. de-DE peut formater nombres et dates selon les conventions allemandes alors que la liste est en-US,en. Une requête peut exprimer une préférence anglaise alors qu'une page appelle Intl.NumberFormat('de-DE'). Chaque valeur répond à une question différente : formatage, préférence du navigateur ou proposition de la requête au serveur.

Le choix peut varier selon la ressource : une route de document négocie du HTML tandis qu'une API renvoie du JSON sans langue ; scripts et images peuvent suivre une autre logique que la page. Comparez des requêtes équivalentes : méthode, URL, redirections, en-têtes, réponse et authentification doivent correspondre avant d'attribuer l'écart à la liste de langues.

La documentation proxy et géolocalisation décrit les valeurs régionales dérivées du proxy et les substitutions. Un contrôle web suit une préférence depuis les propriétés du navigateur jusqu'à la requête, puis la compare à la représentation choisie par le serveur. La route peut influer sur auto, mais ne supprime pas la décision indépendante du serveur.

Cookies et langue de l'application

Un site peut mémoriser la langue dans un cookie, le stockage local, un compte ou une URL. Il peut ensuite conserver ce choix malgré une autre valeur Accept-Language. Un sélecteur traduit souvent une préférence applicative explicite qui prime raisonnablement sur la négociation automatique. Effacer les préférences du navigateur ou modifier --bot-languages ne réinitialise pas sûrement un réglage de compte côté serveur.

Comparez une session vierge à l'existante seulement si le workflow l'autorise. Notez un préfixe comme /fr/, les redirections, le cookie linguistique et la locale enregistrée dans le compte. Ne supprimez pas des cookies ou données sans rapport : cela peut effacer des éléments diagnostiques ou modifier l'authentification et le consentement.

Si une page conserve la « mauvaise » langue :

1. Confirmez l'URL et son préfixe de locale.
2. Inspectez Accept-Language dans la requête.
3. Examinez les redirections et les en-têtes linguistiques de la réponse finale.
4. Vérifiez le sélecteur du site, le cookie et la préférence du compte.
5. Comparez un contexte vierge autorisé à l'original en ne changeant qu'une entrée à la fois.

C'est une méthode de diagnostic, pas la promesse que chaque site expose sa décision. L'application peut mélanger les langues, omettre Content-Language ou conserver la préférence côté serveur. Si les éléments manquent, indiquez la couche comme inconnue au lieu de la déduire d'une étiquette visible.

Priorité BotBrowser par champ

Les contrôles du fuseau, de la locale et des langues sont distincts : --bot-timezone, --bot-locale et --bot-languages. Pour une valeur concrète, l'ordre documenté est flag CLI, configs du profil sélectionné, puis sélection automatique. Une valeur n'oblige pas à remplacer les autres champs.

Champ	Flag CLI	Champ configs du profil	Sélection automatique	Première observation utile
Fuseau horaire	--bot-timezone	timezone	auto	Intl.DateTimeFormat().resolvedOptions().timeZone
Locale	--bot-locale	locale	auto	Intl.NumberFormat().resolvedOptions().locale
Langues	--bot-languages	languages	auto	navigator.language, navigator.languages, en-tête de requête

Évaluez chaque champ séparément. --bot-locale=en-GB peut coexister avec un fuseau du profil et une sélection automatique des langues. Cette combinaison peut être voulue ; consignez pourquoi la locale est fixée afin qu'un changement ultérieur de profil ou de route ne semble pas sans effet. Si un champ doit suivre la route, supprimez les anciennes valeurs explicites au lancement et dans le profil au lieu d'ajouter une substitution.

auto signifie déléguer ce champ à la sélection automatique ; ce n'est pas un tag de locale, fuseau ou langue. La documentation indique qu'une valeur CLI concrète prime sur le profil et décrit auto comme une sélection automatique. Elle ne définit pas le conflit entre auto explicite au CLI et valeur concrète dans le profil. Traitez-le comme non résolu tant que la version concernée n'a pas été vérifiée ; ne déduisez pas le gagnant du nom du flag.

La géolocalisation est distincte. --bot-location configure un résultat pour les pages qui demandent l'API dans un contexte autorisé. Les coordonnées ne découlent pas d'un fuseau et celui-ci ne les prouve pas. La documentation proxy/géolocalisation décrit les entrées IP et les limites de résolution ; n'affirmez pas une précision à l'échelle d'une ville ou des coordonnées exactes sans source propre à cette configuration. Aucun appariement garanti entre coordonnées et IP de sortie n'est affirmé ici.

Le guide de cohérence proxy explique comment examiner ensemble routage proxy et signaux d'identité réseau. Considérez cette relation comme contexte et non comme égalité stricte : la route peut influer sur auto, tandis que des réglages explicites et la politique de l'application peuvent produire des exceptions valides.

Table de décision pour la configuration

Choisissez le plus petit ensemble de valeurs explicites répondant au besoin de l'application. Les valeurs sont des exemples, non des recommandations universelles.

Besoin	Fuseau horaire	Locale	Langues	Vérification suivante
Laisser la route définir les valeurs régionales par défaut	Garder la sélection automatique	Garder la sélection automatique	Garder la sélection automatique	Lire les valeurs sélectionnées et la route affectée à ce contexte
Stabiliser le formatage des nombres entre les routes	Garder l'automatique sauf nécessité	Définir --bot-locale ou locale dans le profil	Garder l'automatique sauf si la langue du contenu doit aussi être fixe	Examiner un appel Intl.NumberFormat explicite et un appel par défaut
Stabiliser la préférence d'interface malgré le changement de route	Garder l'automatique sauf nécessité	Choisir seulement si le formatage doit aussi rester fixe	Définir --bot-languages ou languages dans le profil	Examiner séparément les préférences d'exécution, l'en-tête de requête et le choix du site
Afficher un événement selon l'heure civile de son lieu	Définir le fuseau IANA de l'événement dans la couche propriétaire	Choisir indépendamment pour le formatage environnant	Choisir indépendamment pour la négociation du contenu	Formater le même instant avec une option timeZone explicite
Examiner un choix de langue persistant du site	Ne pas modifier sans preuve	Ne pas supposer que la locale choisit le texte de la page	Comparer la liste du navigateur à la requête	Vérifier URL, redirections, cookies et préférences du compte

Si la région change mais que seule une langue fixe est requise, remplacer simultanément fuseau, locale, langues et coordonnées crée quatre voies de substitution à maintenir. Préférez le champ explicitement requis. Si les trois réglages pris en charge doivent suivre le proxy, gardez-les automatiques et contrôlez l'affectation de route. Validez séparément les contextes qui utilisent volontairement des routes différentes.

Tenez une fiche avec une ligne par champ : valeur, couche source (CLI, profil ou automatique), responsable et justification. N'y stockez pas d'identifiants. Elle rend la priorité visible et distingue une valeur fournie par le profil d'une valeur choisie par la route. Supprimez une substitution devenue inutile au lieu de garder un doublon « au cas où ».

Requête de diagnostic à copier

Cette requête dans le navigateur recueille un instantané compact. Elle sépare valeurs par défaut et formatage explicite, sans charger de page ni demander la géolocalisation. Exécutez-la uniquement dans un contexte que vous êtes autorisé à inspecter. Le résultat est illustratif et marqué not_run, pas une observation enregistrée.

function inspectRegionalDefaults() {
  const defaultDate = new Intl.DateTimeFormat();
  const explicitDate = new Intl.DateTimeFormat('en-GB', {
    timeZone: 'Europe/London',
    dateStyle: 'medium',
  });

  return {
    navigatorLanguage: navigator.language,
    navigatorLanguages: [...navigator.languages],
    defaultDateOptions: defaultDate.resolvedOptions(),
    explicitDateOptions: explicitDate.resolvedOptions(),
    defaultNumberLocale: new Intl.NumberFormat().resolvedOptions().locale,
    explicitNumberLocale: new Intl.NumberFormat('de-DE').resolvedOptions().locale,
    note: 'illustrative query; not_run',
  };
}

console.log(inspectRegionalDefaults());

Les valeurs explicites diffèrent volontairement des valeurs par défaut : cela illustre les options de l'appel, pas une erreur de configuration. Pour lire Accept-Language, capturez une requête dans une application de test autorisée ou utilisez ses outils réseau ; JavaScript ne fournit pas d'API générale pour lire les en-têtes sortants. Ne mettez ni identifiants proxy ni données de compte privées dans un artefact public.

Pour comparer le serveur, capturez uniquement URL, redirections, Accept-Language, statut et en-têtes de réponse linguistiques. Masquez les cookies. Si le site propose un sélecteur, notez l'action et la persistance de la préférence dans un nouveau contexte. Ces éléments sont plus utiles qu'une capture de toute une page authentifiée.

Dépannage par couche observée

Observation	Couche probable à examiner	Vérification permettant de trancher
Le format de date par défaut diffère, mais le formateur explicite correspond	Valeur par défaut de l'environnement ou choix du formateur applicatif	Comparer resolvedOptions() aux options explicites du formateur
resolvedOptions().timeZone diffère du fuseau attendu	Sélection du fuseau par CLI, profil ou automatisation	Vérifier --bot-timezone, timezone dans le profil, puis l'affectation de route
navigator.languages est attendu, mais pas la page serveur	Négociation HTTP ou état du site	Examiner l'en-tête, la redirection, la locale d'URL, le cookie et la préférence du compte
Les séparateurs numériques diffèrent alors que la langue du texte convient	Formatage de locale, pas négociation linguistique	Examiner les arguments exacts du constructeur Intl.NumberFormat
Un contexte diffère d'un autre	Profil, flags, route ou état applicatif propre au contexte	Comparer les deux contextes champ par champ et en créer un nouveau après modification
Les coordonnées ne correspondent pas à une ville déduite du fuseau	Configuration de géolocalisation ou permissions de l'application	Vérifier si la géolocalisation a été demandée et quelle valeur --bot-location s'applique

Ne changez qu'une couche à la fois. Si un champ CLI explicite est présent, modifier le profil ne prouve pas que celui-ci fournissait la valeur effective. Si le champ est automatique, changer un cookie ne prouve pas que la route proxy a changé. Notez la source de chaque champ, puis répétez la même action dans un nouveau contexte pour que l'ancien état de page ne masque pas le résultat.

Une page de test n'est pas un oracle universel. Une page minimale révèle des valeurs par défaut, pas les en-têtes exacts de toutes les requêtes. Une capture réseau montre une requête, pas ce que l'application mémorise ensuite. Une page rendue montre le résultat visible, pas la source du choix. Combinez le minimum d'observations utile et laissez les signaux sans rapport hors du compte rendu.

Limites et interprétation prudente

La documentation publique BotBrowser décrit la priorité de configuration et les contrôles visibles du navigateur. La destination prend ses propres décisions : un serveur peut ignorer les préférences, une application JavaScript fournir des options Intl explicites et un site mémoriser le choix utilisateur. La lecture d'une page ne prouve pas que toutes les routes, frames, workers et requêtes futures partagent les mêmes valeurs.

Le comportement du fuseau dépend des données de la zone et de la date formatée. Un contrôle à la date du jour ne garantit pas les transitions d'heure d'été ni toutes les versions des données système. Utilisez un fuseau IANA pour les règles régionales, testez des dates représentatives pour l'application et indiquez l'environnement et la date examinés. Aucune exécution BotBrowser n'est rapportée ici : il s'agit de limites documentées, pas de compatibilité mesurée.

La géolocalisation automatique dépend des entrées configurées et du service de résolution disponible ; un fuseau ne donne ni latitude ni longitude. Aucun résultat à l'échelle d'une ville ni appariement à une base IP n'est garanti. Les sites peuvent ne pas demander ou utiliser la géolocalisation ; permissions et traitement applicatif restent distincts.

Ces propriétés servent aux tests de compatibilité autorisés, à la recherche sur la confidentialité et au débogage. Elles ne prouvent ni l'identité ni la présence physique. Utilisez des comptes et routes autorisés, limitez la collecte au besoin et signalez l'inconnu comme tel au lieu de transformer une corrélation plausible en fait.

FAQ

Changer une locale Intl modifie-t-il navigator.language ?

Non. Une locale fournie à un constructeur Intl change la résolution de ce formateur, pas les préférences du navigateur ni les en-têtes réseau. Si l'application fournit des options explicites, inspectez les arguments avant de changer la configuration linguistique du navigateur.

Accept-Language oblige-t-il le site à afficher cette langue ?

Non. C'est une préférence que le serveur peut utiliser pour négocier le contenu. L'application peut privilégier l'URL, un cookie, un compte ou une valeur produit par défaut. Inspectez requête et état du site séparément ; l'en-tête n'est pas nécessairement la décision finale.

Le fuseau et la locale doivent-ils toujours désigner le même pays ?

Non. Ils ont des fonctions différentes et peuvent diverger intentionnellement. Une locale peut servir au formatage tandis qu'un calendrier suit le fuseau d'une autre région. Choisissez selon le besoin applicatif et contrôlez affichage et comportement réseau.

Quelle valeur gagne si les réglages CLI et profil divergent ?

Pour chaque champ, une valeur CLI concrète prime sur configs du profil, puis vient la sélection automatique. La documentation ne précise pas si un auto explicite au CLI remplace une valeur concrète du profil. Résolvez séparément fuseau, locale et langues ; un flag ne remplace pas forcément tout le groupe.

Un fuseau suffit-il pour déduire des coordonnées ?

Non. Un fuseau est un ensemble de règles partagé, pas une coordonnée. La géolocalisation est un résultat distinct soumis à configuration et permission. Utilisez le contrôle documenté et inspectez le résultat de l'application autorisée si les coordonnées sont requises.

Sources

• BotBrowser : Fuseau horaire, locale et langue
• BotBrowser : Proxy et géolocalisation
• MDN : Intl
• MDN : Intl.DateTimeFormat
• MDN : Accept-Language
• MDN : Date
• ECMA-402 : spécification de l'API Internationalization

Conclusion pratique

Traitez fuseau horaire, locale de formatage, préférences du navigateur, négociation HTTP et langue mémorisée par le site comme des entrées distinctes. Identifiez l'observation incorrecte, puis remontez à la couche qui possède ce champ : CLI, profil, sélection automatique par proxy, code applicatif ou état du site. Ne gardez que les substitutions requises ; répétez le contrôle autorisé dans un nouveau contexte et décrivez l'observation sans la généraliser à tous les workers, dates, routes ou coordonnées.