INTRODUCTION
Un sélecteur de calendrier peut répondre élégamment à la mauvaise question. Se souvenir d'une date de naissance, recopier une date sur un document et choisir un rendez-vous produisent des réponses qui ressemblent toutes à des dates. Pourtant, les tâches diffèrent. Les traiter comme une seule décision de composant oblige la personne à s'adapter à l'interface.
Avant de choisir un contrôle, tranchez trois décisions de produit : d'où vient la réponse, quelle précision est nécessaire et quel engagement en découle. Ces choix donnent un cadre commun au design et au développement. Ils révèlent aussi des questions qu'un beau calendrier ne résoudra pas.
Partir de l'origine de la réponse
Demandez-vous ce que la personne regarde lorsqu'elle arrive au champ. Elle connaît peut-être déjà la réponse, dispose d'un document ou doit examiner des possibilités. Une date mémorisée ne devrait pas imposer de parcourir des mois d'écrans. Pour un rendez-vous, voir les dates réellement disponibles facilite au contraire le choix.
Le modèle de dates de GOV.UK distingue ces tâches. Il conseille des champs de date pour les dates mémorisées et un format qui corresponde au document lorsqu'il faut le recopier. Voilà une raison concrète de définir la tâche avant d'uniformiser tous les champs.
Dans un service fictif de réparation d'équipements, la date d'achat et la date de collecte figurent sur le même formulaire. Le client recopie la première depuis un reçu et choisit la seconde parmi les visites disponibles. Un traitement visuel unique peut sembler cohérent tout en compliquant les deux tâches. La cohérence doit aider à comprendre l'interaction ; elle n'exige pas de rendre des questions différentes identiques.
Déterminer la certitude nécessaire
Exiger un jour, un mois et une année peut fabriquer une fausse précision. Si la personne ne se souvient que du mois, le jour obligatoire l'incite à deviner. Cette supposition risque ensuite de circuler dans les rapports comme un fait fiable. L'interface a discrètement changé le sens de l'information.
Demandez quelle décision ultérieure dépend du détail manquant. Si le mois suffit à orienter une demande, recueillez le mois. Si une date exacte est indispensable, expliquez où la trouver et quoi faire lorsqu'elle reste introuvable. Ne proposez pas une réponse approximative que le service ne sait pas traiter.
Reprenons la réparation. L'examen d'une garantie peut nécessiter une preuve d'achat, tandis qu'un premier contact demande seulement un ordre de grandeur de l'âge de l'objet. L'équipe produit doit clarifier cela avec le responsable du service. Rendre le champ facultatif en espérant que la suite s'arrangera ne règle pas la question.
Distinguer une date d'un rendez-vous
Une date peut désigner une journée sans définir un instant. Un rendez-vous ajoute une heure et un lieu ou un fuseau horaire. Confondre ces significations crée des surprises : le client pense avoir choisi l'heure de l'atelier, alors que la confirmation reprend le réglage de son appareil.
MDN précise que le champ natif datetime-local ne contient pas de fuseau horaire. Choisir ce contrôle ne termine donc pas la conception du rendez-vous. Le produit doit encore définir le fuseau concerné et rendre cette interprétation visible au bon endroit.
Pour notre service fictif, la confirmation pourrait indiquer explicitement la date, l'heure et le lieu de collecte. Une session à distance peut nécessiter un fuseau clairement nommé. Écrivez d'abord la confirmation, puis vérifiez que la saisie apporte tout ce qu'il faut pour rendre cette phrase exacte. Inutile d'ajouter des termes techniques à une simple question de date qui n'en a pas besoin.
Un formulaire plus simple peut mieux fonctionner
L'objection aux contrôles sur mesure est sérieuse : davantage de variantes signifie davantage de maintenance, de tests et de comportements potentiellement incohérents. Un petit produit n'a pas besoin d'une interface complexe de planification pour quelques dates.
Commencez par des contrôles natifs familiers et des libellés clairs lorsqu'ils servent la tâche. Ajoutez un calendrier quand la relation entre les dates aide à choisir. Cherchez un petit ensemble de modèles utiles, au sens documenté, plutôt qu'un composant inédit pour chaque écran.
La validation doit être aussi précise. Une date impossible, un rendez-vous indisponible et une réponse obligatoire manquante appellent des explications différentes. Préservez les éléments valides et indiquez ce qui peut être corrigé. Une bordure rouge autour de trois cases n'identifie guère le problème.
Examiner la réponse complète
Répétez trois parcours courts : une ancienne date connue, une date recopiée et un rendez-vous futur. Utilisez un téléphone et un clavier, puis examinez la page de vérification et la confirmation. Demandez à quelqu'un d'expliquer ce que le service pense avoir reçu, sans interpréter l'interface à sa place.
Avant la mise en ligne, écrivez une phrase par champ : « Nous avons besoin de cette date, issue de cette source, avec cette précision, pour cette décision. » Si la phrase reste floue, le composant n'est pas le problème restant. Retrouvez d'autres décisions concrètes de produit dans le journal Blanche.
Sources principales consultées le 10 novembre 2026. Les exemples sont hypothétiques ; cet article propose une méthode de conception, pas l'annonce d'un nouveau produit.