Évaluation d'une fonctionnalité de recherche
Comment évaluer une fonctionnalité de recherche : pertinence, classement, facettes et responsable de l'index. Les questions qui transforment la simple idée d'« ajouter une barre de recherche » en une véritable évaluation.
« Ajouter un champ de recherche » revient en fait à « choisir un moteur de recherche, élaborer un modèle de pertinence et détenir l’index pour toujours ».
La recherche comporte deux aspects que le ticket ne mentionne jamais. Le premier concerne la pertinence : qu’est-ce qui rend un résultat meilleur qu’un autre, et qui en décide ? Le second est d’ordre opérationnel : où se trouve l’index, comment reste-t-il synchronisé avec la source de vérité, et que se passe-t-il lorsqu’il prend du retard ? « Ajouter une recherche » implique un contrôle de l’interface utilisateur. Le travail porte sur le classement et l’index.
Une équipe ayant déjà mis en production un moteur de recherche sait que la réponse est rarement la même deux fois. La recherche en texte intégral de Postgres convient tant que personne ne demande de tolérance aux fautes de frappe. Elasticsearch est rapide, jusqu’à ce que vous deviez payer pour son utilisation le week-end. Algolia est simple à utiliser jusqu’à ce que vous ayez besoin d’un classement personnalisé. L’estimation dépend du compromis choisi par l’équipe, et cette décision n’a généralement pas encore été prise lorsque le ticket arrive en phase d’affinage.
Ce qui se dit dans la salle
Backend : « Postgres peut le faire avec
tsvector. »PM : « Faut-il quand même faire correspondre les fautes de frappe ? Et les pluriels ? »
Interface utilisateur : « Allons-nous mettre en place une fonction de saisie semi-automatique, ou simplement afficher les résultats après validation ? »
SRE : « Comment assurons-nous la synchronisation de l’index ? Par des déclencheurs ? Une tâche ? Un flux ? »
Chapeau : « À qui revient la pertinence lorsqu’une personne se plaint que la bonne réponse se trouve à la deuxième page ? »
Questions qu’il convient de se poser avant de voter
- De quel corpus s’agit-il ? Combien de documents contient-il, et à quelle fréquence sont-ils mis à jour ?
- Postgres FTS, un service de recherche dédié ou une solution hébergée (Algolia, Typesense) ?
- Tolérance aux fautes de frappe, dérivation, synonymes, pluriels : lesquels sont pris en compte ?
- Facettes et filtres, ou simplement une seule liste classée ?
- Comment l’index reste-t-il synchronisé — et quel est le « budget de désactualisation » ?
- Qui détient la pertinence à long terme, et comment l’ajuste-t-on ?
Si le choix de l’infrastructure n’est pas encore arrêté, cette décision constitue un spike, et non une feature — évaluez l’ampleur du spike et réévaluez le développement une fois qu’un responsable aura été désigné pour cette fonctionnalité.
Le champ de recherche correspond à une journée. La pertinence et l’index constituent la caractéristique — veuillez les estimer.
Consultez l’estimation d’une intégration de paiement pour découvrir le même schéma — une petite surface visible qui cache une longue traînée opérationnelle — ainsi que les autres exemples d’estimations concrètes. Ou lancez une session gratuite de « planning poker » dès qu’un responsable a été désigné pour la question de pertinence.