Pourquoi la salutation à la mauvaise heure d'un robot brise l'illusion de réalité
Une salutation liée à l'heure ressemble à une simple courtoisie, mais elle formule aussi une affirmation factuelle : le système sait quelle heure il est là où la conversation a lieu. S'il dit « Bonjour » en pleine nuit, ce décalage peut donner l'impression que toute l'interaction est préfabriquée ou peu fiable. La solution pratique consiste à baser toute référence temporelle sur un horodatage actuel et un fuseau horaire explicite, à garder la salutation cohérente avec l'heure affichée ailleurs, et à tester les cas limites. Lorsque ce contexte fait défaut, un simple « Bonjour » ou « Salut » est plus fiable que de deviner le matin de quelqu'un.
Pourquoi une heure incorrecte ressemble à bien plus qu'une simple erreur de formulation
Une salutation telle que « Bonjour » est un indice social, mais elle véhicule aussi des informations. Un utilisateur peut la comparer avec l'horloge sur le même écran ou avec l'heure qu'il connaît localement. Lorsque les deux sont en conflit, l'incohérence est immédiatement visible et peut donner l'impression que la salutation est automatique. Il s'agit d'une déduction de conception issue d'une incohérence observable ; cela ne prouve pas que chaque utilisateur réagira de la même manière.
La recherche sur les agents conversationnels montre que les erreurs peuvent influencer la manière dont les gens perçoivent un agent, bien que les effets diffèrent selon le type d'erreur. Dans une étude portant sur un agent conversationnel incarné, les erreurs de prise de parole ont réduit l'appréciation, tandis que certaines erreurs de cohérence ont eu un effet différent. La leçon utile n'est pas qu'une salutation à la mauvaise heure provoquera toujours une réponse spécifique, mais que les erreurs d'interaction peuvent façonner les impressions au-delà du contenu immédiat. Adobe Research, « Conversational Error Analysis in Human-Agent Interaction »
Une salutation temporelle peut également sous-entendre une conscience que le système ne possède pas forcément. Connaître l'heure actuelle de l'horloge n'est pas la même chose que savoir quand une personne s'est réveillée, ce qu'elle fait ou quelle partie de sa journée elle considère comme le « matin ». Une mesure du temps fiable permet une formulation exacte ; elle n'établit pas une compréhension personnelle.
Commencez avec un horodatage et un fuseau horaire connu
Traitez l'heure actuelle et le fuseau horaire local de l'utilisateur comme des entrées distinctes. Un horodatage identifie un point sur la ligne du temps ; un fuseau horaire fournit les règles nécessaires pour exprimer cet instant sous forme d'heure locale. Les recommandations du W3C distinguent ces représentations temporelles et expliquent que les fuseaux horaires comprennent des règles pour les décalages et les passages à l'heure d'été. Elles recommandent d'utiliser un identifiant de fuseau horaire lorsqu'il est nécessaire de calculer l'heure locale. W3C, « Working with Time and Timezones »
Pour une salutation générée par un logiciel, une séquence robuste est la suivante :
Obtenir l'instant présent à partir d'une horloge système ou d'une autre source temporelle de confiance.
Obtenir un paramètre de fuseau horaire connu pour représenter l'utilisateur cible ou le contexte de la conversation.
Convertir l'instant dans ce fuseau à l'aide d'un formateur prenant en compte les fuseaux horaires.
Choisir la salutation à partir de l'heure locale convertie, ou omettre la référence temporelle si le contexte est indisponible ou obsolète.
En JavaScript, Intl.DateTimeFormat accepte une option timeZone pour formater une date. Si une application omet cette option, le fuseau horaire actuel de l'environnement hôte est utilisé, ce qui peut correspondre au fuseau du serveur ou de l'appareil plutôt qu'à celui de l'utilisateur. Le formateur peut également produire l'heure et la date affichées dans l'interface à partir du même instant. MDN, « Intl.DateTimeFormat »
Un décalage numérique seul peut ne pas suffire pour un comportement temporel futur ou récurrent. Un fuseau nommé tel que Europe/London représente un ensemble de règles régionales ; le décalage peut varier selon la date. L'IANA explique que sa base de données de fuseaux horaires est mise à jour pour refléter les modifications de frontières, les décalages UTC et les règles d'heure d'été. Les logiciels dépendent donc à la fois d'un fuseau approprié et de données de fuseau horaire raisonnablement à jour. IANA, « Time Zones »
Faites en sorte que la salutation et l'horloge visible partagent la même source
La salutation et l'horloge à l'écran doivent être dérivées du même horodatage et du même contexte de fuseau horaire. Si un composant utilise le fuseau local du navigateur et qu'un autre utilise une valeur par défaut du serveur, ils peuvent être en désaccord autour de minuit ou lorsqu'une personne voyage. Si l'interface affiche une date, vérifiez-la en même temps que la salutation : une date locale peut différer de la date à l'emplacement du serveur.
Une règle de mise en œuvre utile consiste à calculer l'heure locale une seule fois pour l'événement de conversation et à transmettre ce résultat à la fois à la logique de salutation et à l'affichage. Évitez de demander séparément à un modèle linguistique de déduire l'heure à partir du texte de la conversation, du contexte de l'appareil ou d'un planning mémorisé. Le modèle peut choisir la formulation à partir d'une valeur vérifiée, mais le calcul de l'horloge doit provenir de données temporelles.
Si un utilisateur n'a pas fourni de fuseau horaire et que le produit ne dispose d'aucun paramètre local fiable, évitez d'affirmer un moment précis de la journée. Un simple « Bonjour » reste exact quels que soient les fuseaux et les heures. Si un fuseau explicite est nécessaire pour une tâche, demandez-le de manière claire et fluide au lieu de considérer silencieusement le fuseau du serveur comme étant celui de l'utilisateur.
Définissez délibérément les limites des salutations
Il n'y a pas de frontière universelle et factuelle entre le matin, l'après-midi et le soir. Les équipes doivent définir des plages d'heures locales comme un choix rédactionnel du produit, puis vérifier que la formulation choisie correspond au ton souhaité. Gardez ces plages explicites dans la configuration ou le code afin que les relecteurs puissent voir ce qui se passe à chaque limite. Évitez les formules suggérant la connaissance d'une routine, telles que « Vous êtes matinal », à moins que l'utilisateur n'ait réellement fourni cette information et qu'elle soit pertinente.
La solution de repli sécurisée doit faire partie de la conception. Si l'horodatage est invalide, que l'identifiant du fuseau horaire est manquant ou non reconnu, ou que la conversion échoue, utilisez une salutation neutre. Ne substituez pas l'horloge du serveur sans rendre ce choix explicite. Si la lecture de l'horloge risque d'être retardée, un « Bonjour » plus général vieillira également mieux qu'une salutation qui devient fausse pendant qu'un message attend d'apparaître.
Testez les transitions et le contexte, pas seulement un après-midi typique
Un test du scénario idéal (happy path) à une heure locale ordinaire ne révélera pas beaucoup d'anomalies temporelles. Utilisez des horodatages fixes et des fuseaux explicites pour que les résultats soient reproductibles, et vérifiez des cas tels que :
Un moment juste avant et après chaque limite de salutation.
Minuit local, y compris un changement de date entre l'affichage local et le serveur.
Deux fuseaux qui ont des dates locales différentes au même instant.
Une transition vers l'heure d'été dans un fuseau qui l'applique.
Un fuseau avec un décalage d'une demi-heure ou d'un quart d'heure.
Un fuseau manquant ou invalide, où le résultat attendu est une salutation neutre.
Un message différé, en vérifiant si sa formulation est basée sur l'heure de génération ou l'heure d'affichage — et si ce choix est cohérent avec le comportement du produit.
Ces cas découlent de la manière dont les fuseaux horaires font correspondre les instants à l'heure locale et du fait que les règles régionales d'horloge peuvent changer. Une suite de tests doit rendre le comportement choisi visible plutôt que de s'en remettre à une valeur machine implicite par défaut. L'historique des versions de l'IANA documente les changements de règles réels, ce qui rappelle que les environnements de test et les données de fuseaux horaires déployées peuvent devenir obsolètes. IANA, « Time Zone Database Releases »
Une règle de décision pratique pour les équipes produit
N'utilisez une salutation liée à l'heure que lorsque trois éléments sont réunis : un instant présent digne de confiance, un fuseau horaire rattaché au contexte de la conversation, et un formatage cohérent entre la salutation et toute horloge visible. Si un élément est incertain, choisissez une formulation neutre. Si le système ne connaît que l'heure, il peut faire référence avec exactitude au moment de la journée ; il ne doit pas laisser entendre qu'il connaît l'emploi du temps, l'humeur ou l'activité de la personne.
Une salutation ne peut pas, à elle seule, donner l'impression qu'un assistant est attentif. Sa valeur dépend de la concordance de la petite affirmation qu'elle formule avec le reste de l'interface. Une formulation exacte et mesurée offre à l'interaction un point de départ cohérent tout en laissant le contexte personnel à la personne qui est véritablement en mesure de le fournir.