Quelque part dans la fiche d’un client, au milieu d’une note ordinaire sur un appel ordinaire, il y a une phrase comme celle-ci : « Le budget est serré en ce moment, on est convenus de les recontacter dans deux mois pour refaire le point. »
Écrite une fois. Jamais relue. Pas parce que quelqu’un aurait oublié que c’était important, mais parce que rien dedans ne ressemblait à une tâche. Ce n’était pas une entrée d’agenda. Ce n’était pas un rappel. C’était juste une phrase, qui faisait ce que les phrases dans les notes font : rester là, techniquement vraie, fonctionnellement invisible.
On voulait savoir si le système pouvait repérer ce genre de chose tout seul, sans que personne n’ait à se souvenir de revenir transformer une phrase en tâche à la main.
Ce qu’on a vraiment construit, et ce qu’on n’a délibérément pas fait
Le réflexe avec une fonctionnalité comme celle-ci, c’est de laisser l’IA gérer tout le processus — lire la note, déterminer la date, décider que c’est en retard, voire rédiger la relance. On a délibérément séparé les rôles.
Le seul travail du modèle, c’est la compréhension du langage : lire les notes récentes d’un client et reconnaître un engagement tourné vers l’avenir, du genre « on refait le point dans deux mois » ou « on recontacte après leur conseil d’administration ». Il estime le délai implicite en langage courant. C’est tout. Tout calcul de date proprement dit — l’échéance, si aujourd’hui la dépasse ou non — se fait ensuite dans du code ordinaire et déterministe. Le modèle ne fait jamais de calcul et ne décide jamais lui-même de ce qui est en retard. Il lit. Le code décide.
Cette séparation compte plus qu’il n’y paraît. La compréhension du langage est exactement le genre de tâche floue, dépendante du contexte, dans laquelle un modèle excelle. Le calcul de dates est exactement le genre de tâche où on ne veut pas qu’un modèle improvise, même un tout petit peu.
Le vrai test
On n’a pas juste vérifié que l’endpoint renvoyait quelque chose qui avait l’air raisonnable. On a écrit une vraie note sur une vraie fiche client : « …convenus de les recontacter dans 2 mois pour refaire le point sur le budget. » On a appelé l’endpoint. Il a correctement extrait l’engagement, calculé un délai implicite de 60 jours, et abouti à une échéance exactement 60 jours après l’horodatage réel de la note, correctement signalée comme pas encore en retard.
Un test modeste, et c’est bien tout l’intérêt. Le système n’avait pas besoin qu’on lui dise qu’il y avait un engagement à trouver. Il a lu une phrase qu’une personne avait écrite pour elle-même, pas pour un formulaire, et en a tiré une vraie échéance.
La partie facile à manquer
Les notes dans Craft11 sont en ajout seul. Personne ne les modifie, personne ne les supprime, pas même Stark. C’est le même principe qui garde honnête le côté brut de chaque fiche : ce que vous avez réellement écrit reste exactement tel que vous l’avez écrit. Quand on a dû retirer la note de test ensuite, il n’y avait pas de bouton supprimer à actionner, parce qu’il n’est pas censé y en avoir. Il a fallu une opération directe sur la base de données, confirmée d’abord, puis annulée immédiatement après.
C’est un petit désagrément pour nous pendant les tests. C’est exactement pour cette raison que la détection d’engagements est digne de confiance en premier lieu : elle lit de l’écriture humaine réelle, non modifiée, non nettoyée, pas une version assainie.
Pourquoi ça vaut le coup, tout court
Rien de tout ça ne remplace un gestionnaire de tâches. Ça remplace ce mode d’échec précis et silencieux où la seule trace d’une promesse est une phrase que personne ne relira jamais. Le système n’a pas besoin que vous écriviez différemment, que vous structuriez vos notes, ou que vous vous souveniez de marquer quoi que ce soit. Il a juste besoin que vous écriviez ce qui s’est vraiment passé, comme vous l’écririez pour vous-même, et c’est lui qui s’occupe de le remarquer.