Comment les apps de tâches comprennent « demain à 9 h »

Tapez « E-mail à Sam demain à 9 h » dans une bonne app de tâches et l’une de deux choses devrait se passer. Soit vous obtenez la tâche comme un objet propre avec le titre « E-mail à Sam » et une date d’échéance fixée à 9 h 00 le lendemain, soit l’app ne fait rien et vous devez remplir un sélecteur de date. La différence entre ces deux résultats est ce qui détermine si vous utilisez vraiment l’app.

La reconnaissance de dates en langage naturel existe depuis des décennies. Elle alimentait Quicksilver. Elle alimentait Fantastical. Aujourd’hui elle alimente pratiquement toutes les apps de productivité qui valent la peine d’être livrées. Mais la façon dont ça fonctionne sous le capot a changé de façon intéressante au cours des deux ou trois dernières années, et le résultat est que 2026 est la première année où cette technologie est genuinement résolue pour l’anglais dans la plupart des apps et commence à bien fonctionner dans d’autres langues.

Cet article présente comment ça fonctionne.

La forme de base du problème

Un utilisateur tape une phrase. L’app doit :

1. Décider si la phrase contient même une date.
2. Si oui, trouver quelle partie du texte fait référence à la date.
3. Résoudre cette partie en une date et heure absolues.
4. Supprimer la partie date de la phrase pour que le texte restant soit juste le titre de la tâche.

Chacune de ces étapes a ses propres modes d’échec. La plupart des implémentations précoces étaient fragiles à l’étape un, générant des faux positifs. « Récupérer les 15 rapports » ne devrait pas obtenir une date d’échéance au 15 du mois. « Acheter 3 pommes » ne devrait pas être interprété comme un quelconque trois-quelque-chose. « E-mail à Sam chez IBM » ne fixe probablement pas l’heure à « chez I.B.M. »

La stratégie classique est les expressions régulières. Elles sont étonnamment bonnes pour ça. Une poignée de motifs soigneusement rédigés peuvent reconnaître plus de 90 % des phrases de date que les gens tapent vraiment dans les apps de tâches :

• \bin\s+(a|an|\d+|some|several)\s+(min|minute|minutes|hour|hours|hr|hrs|day|days|week|weeks|month|months)\b
• \b\d{1,2}(:\d{2})?\s*(am|pm)\b
• \b(tomorrow|today|tonight|noon|midnight)\b
• \b(monday|tuesday|wednesday|thursday|friday|saturday|sunday)\b

Combinez quinze ou vingt de ces motifs et vous couvrez la longue traîne. Ensuite vous assemblez les correspondances : un mot de jour plus un mot d’heure devient un instant spécifique. Un nom de jour de la semaine sans qualificatif signifie « la prochaine occurrence de ce jour de la semaine ». Un mot d’heure seul sans jour signifie aujourd’hui.

Où les regex échouent

Les regex butent sur trois types de saisies :

1. Les phrases vagues. « Quelque part la semaine prochaine » est une date mais pas une spécifique.
2. L’ambiguïté. « Vendredi après-midi » pourrait être 14 h ou 16 h selon la convention.
3. Les fautes d’orthographe et l’argot. « tmrw at 9p » est analysable par un humain mais pas par une regex stricte sans beaucoup de variantes.

Pendant longtemps, les apps de tâches haussaient simplement les épaules face à ces cas. Si vous tapiez « tmrw at 9p » vous n’obteniez rien. Si vous tapiez « first thing tomorrow » vous n’obteniez rien. L’utilisateur apprenait à taper la version formelle.

Le développement intéressant de la dernière année est que les modèles de langage sur l’appareil peuvent maintenant gérer ces cas sans rien envoyer sur le réseau. Le framework Foundation Models d’Apple, disponible depuis macOS 26, livre un modèle qui fonctionne localement et est suffisamment rapide pour être utilisé comme repli quand les regex ratent. Google a une offre similaire sur Android. Le motif résultant ressemble à ceci :

Le chemin rapide couvre 90 % des cas. Le modèle gère le reste. Ni l’une ni l’autre étape n’envoie le texte de l’utilisateur sur le réseau. La confidentialité et la vitesse sont toutes deux préservées.

Pourquoi « dans 2 heures » est plus difficile qu’il n’y paraît

La phrase « dans 2 heures » semble facile. Elle ne l’est pas.

L’utilisateur pourrait vouloir dire n’importe lequel des éléments suivants :

• 2 heures à partir de maintenant, à la minute près.
• 2 heures à partir de maintenant, arrondi aux 15 minutes les plus proches pour la propreté.
• 2 heures à partir de maintenant, mais si ça tombe pendant les heures de sommeil marquées de l’utilisateur, le lendemain matin.
• 2 heures à partir du début de la prochaine heure (« dans 2 heures » dit à 13 h 55 pourrait signifier 16 h 00, pas 15 h 55).

La plupart des apps font un choix et s’y tiennent. Le plus courant est « 2 heures à partir de maintenant, à la minute près », ce qui échange l’élégance contre la prévisibilité. Un utilisateur qui a tapé « dans 2 heures » à 13 h 23 reçoit une notification à 15 h 23. Il apprend à taper des nombres entiers quand il veut des heures rondes.

Pourquoi « demain » correspond par défaut à 9 h

Quand vous tapez « demain » sans heure, une app doit choisir une heure. La convention a convergé vers 9 h 00 dans presque toutes les apps du marché. Pourquoi ?

Parce que le coût de se tromper est asymétrique. Si l’app choisit 9 h et que vous vouliez 11 h, vous pouvez vous ajuster rapidement quand vous le remarquez. Si l’app choisit minuit ou une autre heure quelconque, vous recevez une notification pendant que vous dormez ou vous la ratez entièrement. 9 h est le défaut sûr pour presque tous les types de tâches professionnelles.

Quelques apps choisissent par défaut 8 h. Quelques-unes utilisent l’heure de la journée à laquelle vous avez tapé la tâche (« vous l’avez dit à 14 h, donc probablement vous voulez dire 14 h »). Cette dernière est intelligente mais peu fiable, parce que la plupart des personnes qui tapent une tâche à 14 h le font pendant la journée de travail pour des tâches qu’elles veulent faire pendant une future journée de travail, pas exactement à 14 h le lendemain.

À quoi ça ressemble dans TodoBar

TodoBar utilise le pipeline en deux étapes décrit ci-dessus. Tapez n’importe quelle tâche avec une phrase temporelle et la couche regex se déclenche d’abord, en moins d’une milliseconde. Si elle trouve une date, la tâche apparaît dans votre liste avec la bonne heure d’échéance attachée. Si la couche regex ne peut pas résoudre la phrase, le classificateur Foundation Models sur l’appareil tente sa chance, avec une latence typique d’environ 50 millisecondes. Dans les deux cas, aucun texte ne quitte votre Mac.

Les motifs que la couche regex reconnaît sont documentés sur la page d’assistance. Pour référence rapide, tout ceci fonctionne :

• « dans 30 minutes »
• « dans 2 heures »
• « dans quelques heures »
• « demain »
• « demain à 9 h »
• « ce soir »
• « ce soir à 20 h »
• « vendredi prochain »
• « vendredi à 17 h »
• « 12 mai »
• « 12 mai à 14 h »
• « le 15 »
• « dans 3 jours »
• « dans 1 semaine »
• « demain matin en premier »

Si vous tapez quelque chose que l’analyseur ne peut pas gérer, la tâche est quand même ajoutée sans date d’échéance, et vous pouvez en attacher une manuellement depuis le bouton cloche de la ligne. Le mode d’échec de l’analyseur est « pas de date attachée », pas « tâche perdue ».

Où tout ça va

La prochaine frontière intéressante est l’analyse multilingue. Des phrases espagnoles comme « mañana a las 9 » devraient fonctionner aussi bien que l’équivalent anglais, et de plus en plus dans les apps qui prennent la localisation au sérieux. Le modèle sur l’appareil d’Apple gère bien l’espagnol dans nos tests internes. La même approche fonctionnera pour le français, l’allemand, le japonais, et probablement la plupart des langues principales dans l’année à venir.

Les pièces sont toutes là. Ce qui était autrefois un aller-retour cloud coûteux est maintenant un appel de fonction local qui prend 50 millisecondes. Le fait qu’une app de tâches indépendante puisse livrer ça, gratuitement, sans facture d’inférence par utilisateur, est la vraie histoire.