Recherche contextuelle et swipe : guide UX complet

Une app mobile se juge en secondes. Pas en features. Pas en nombre de boutons. En secondes — le temps qu'il te faut pour trouver ce que tu cherches et faire ce que tu veux faire. C'est la raison pour laquelle j'ai investi autant de temps sur la recherche contextuelle et la navigation par swipe dans TAMSIV.

Points clés à retenir :
- La recherche unifiée interroge simultanément tâches et mémos avec pondération par pertinence et récence.
- La recherche contextuelle priorise les résultats du contexte actuel (groupe, dossier) sans exclure les autres.
- Le swipe-to-dismiss avec un seuil de 100px est le sweet spot entre geste accidentel et intentionnel.
- La fluidité d'une app est la somme de centaines de micro-décisions UX invisibles.

Pourquoi la recherche est-elle le premier indicateur de qualité d'une app ?

Quand un utilisateur ouvre une app de productivité, il cherche quelque chose. Une tâche, un mémo, une information. Si la recherche est lente, mal ciblée ou absente, l'app entière semble cassée. C'est un fait que le Nielsen Norman Group documente depuis des années.

Dans TAMSIV, la recherche n'est pas un champ texte basique posé en haut de l'écran. C'est un système unifié qui interroge simultanément les tâches, les mémos et les événements calendrier, dans tous les contextes accessibles à l'utilisateur.

Le SearchService est un singleton qui centralise toutes les requêtes de recherche. Il utilise le full-text search de PostgreSQL via Supabase pour des résultats rapides et pertinents, même avec des milliers d'éléments.

Comment fonctionne la pondération des résultats de recherche ?

Tous les résultats ne se valent pas. Quand tu tapes "réunion", tu veux probablement la réunion de demain, pas celle d'il y a 3 mois. Le système de pondération prend en compte deux axes :

1. La pertinence textuelle : titre > contenu > checklists. Un match dans le titre vaut plus qu'un match dans le corps. PostgreSQL ts_rank gère ça nativement.
2. La récence : les éléments récemment créés ou modifiés sont boosté. Un coefficient décroissant basé sur la date de dernière modification pénalise les vieux résultats.

Ce double classement est crucial. Sans lui, une recherche sur "rapport" retournerait 200 résultats dans un ordre incompréhensible. Avec, les 3 premiers résultats sont presque toujours les bons.

J'ai optimisé ce système avec le cache de contenu pour éviter les requêtes coûteuses à chaque frappe de touche. Le debounce de 300ms combiné au cache mémoire rend la recherche quasi instantanée.

Qu'est-ce que la recherche contextuelle et pourquoi change-t-elle tout ?

La recherche "classique" traite tous les résultats de manière égale. Tu cherches "budget", tu obtiens tous les éléments contenant "budget" dans toute l'app. C'est correct mais inutile quand tu es en plein travail dans un groupe spécifique.

La recherche contextuelle de TAMSIV fonctionne différemment : elle priorise les résultats du contexte actuel sans exclure les autres. Si tu es dans un groupe "Marketing", les résultats de ce groupe apparaissent en premier, suivis des résultats personnels, puis des autres groupes.

Comment ça marche techniquement ?

• Le SearchService reçoit le contexte courant (groupe ID, type de vue) en paramètre
• La requête ajoute un boost de pertinence pour les éléments du contexte actuel
• Les résultats sont triés : contexte actuel → personnel → autres groupes
• Aucun résultat n'est filtré — seul l'ordre change

Ce comportement est inspiré de la FilterBar du système d'agenda qui applique le même principe de filtrage contextuel. L'utilisateur voit d'abord ce qui est pertinent dans son contexte de travail.

C'est une subtilité UX qui ne se remarque pas consciemment, mais qui fait toute la différence entre une app où tu trouves tout de suite et une app où tu galères.

Comment implémenter un swipe-to-dismiss fiable en React Native ?

Le swipe-to-dismiss est un pattern de navigation que les utilisateurs adorent — quand il marche bien. Le geste de swipe depuis le bord de l'écran pour revenir en arrière est devenu un réflexe sur mobile.

Dans TAMSIV, j'ai implémenté ce pattern sur tous les écrans de détail (tâche, mémo, événement) avec une stack technique précise :

• GestureDetector de react-native-gesture-handler pour la détection du geste
• Animated.View pour l'animation fluide du slide
• Un hook personnalisé useSwipeGesture qui encapsule toute la logique

Le point critique : le seuil de déclenchement. Trop bas (30px), le swipe se déclenche accidentellement en scrollant. Trop haut (200px), l'utilisateur doit forcer et l'expérience est pénible.

Après des dizaines de tests, j'ai calibré le seuil à 100 pixels. C'est le sweet spot — suffisamment haut pour éviter les faux positifs, suffisamment bas pour être naturel. Ce seuil est combiné avec une vélocité minimale : un swipe lent même au-delà de 100px ne déclenche pas le retour.

Un piège classique en React Native : il faut toujours utiliser les composants de react-native-gesture-handler (TouchableOpacity, FlatList, ScrollView) dans les zones de GestureDetector, jamais ceux de react-native. Sinon, les gestes entrent en conflit et le swipe ne fonctionne plus. C'est un gotcha que j'ai découvert à la dure et documenté dans les conventions du projet.

Quelles micro-décisions UX séparent un prototype d'un produit ?

La fluidité d'une app n'est pas une feature. C'est la somme de centaines de micro-décisions. Chacune est invisible individuellement. Ensemble, elles font la différence entre "cette app est bien" et "cette app est géniale".

Voici les micro-décisions qui ont le plus d'impact dans TAMSIV :

1. Le debounce de recherche à 300ms : pas de requête à chaque touche. L'utilisateur finit de taper, puis la recherche se lance. Imperceptible, mais ça divise par 10 le nombre de requêtes.
2. Les résultats persistants pendant le chargement : quand tu modifies ta requête, les anciens résultats restent visibles jusqu'à ce que les nouveaux arrivent. Pas de flash blanc.
3. L'animation de transition à 250ms : le sweet spot pour les transitions d'écran. Plus rapide semble bâclé, plus lent semble lent. Material Design confirme cette plage.
4. Le feedback haptique sur swipe : une vibration légère quand le seuil est atteint confirme l'action sans regarder l'écran.
5. Le scroll inertiel préservé : quand tu reviens en arrière par swipe, la liste est à la même position qu'avant. Pas de retour en haut.

Chacune de ces décisions a pris du temps de refactoring. Mais c'est exactement ce qui transforme une app fonctionnelle en une app que les gens utilisent chaque jour.

Comment mesurer la fluidité d'une application mobile ?

La fluidité ne se mesure pas uniquement en FPS. Voici les métriques que je surveille dans TAMSIV :

• Time-to-first-result : le temps entre la première lettre tapée et l'affichage du premier résultat de recherche. Objectif : < 200ms.
• Gesture recognition rate : le pourcentage de swipes détectés correctement vs les faux positifs. Objectif : > 98%.
• Navigation depth : le nombre de taps nécessaires pour atteindre n'importe quel contenu. Objectif : 3 taps maximum.
• Perceived performance : la sensation de rapidité, indépendamment des métriques brutes. Les animations et le design des interactions jouent un rôle majeur.

Le dashboard admin me permet de suivre ces métriques en temps réel et de détecter les régressions avant que les utilisateurs ne les signalent.

Quel est l'impact de la recherche vocale sur la navigation ?

La recherche textuelle n'est qu'une partie de l'équation. Avec le dictaphone intégré, TAMSIV offre une alternative encore plus rapide : la recherche vocale implicite.

Quand tu dis "où est le rapport marketing de la semaine dernière ?", l'IA ne se contente pas de créer un élément — elle recherche dans tes données existantes et te répond. C'est le pipeline vocal qui traite cette requête, pas le SearchService, mais le résultat est le même : tu trouves ce que tu cherches sans taper.

La combinaison recherche textuelle + recherche vocale + navigation par swipe crée une expérience où l'app s'efface derrière l'action. Tu ne penses plus à l'interface — tu fais ce que tu as à faire.

FAQ

La recherche de TAMSIV fonctionne-t-elle hors connexion ?

La recherche utilise un cache mémoire local qui conserve les derniers résultats et les éléments fréquemment accédés. Pour une recherche complète avec résultats à jour, une connexion est nécessaire car le full-text search est exécuté côté serveur via Supabase.

Peut-on rechercher dans les checklists et les pièces jointes ?

Oui, la recherche couvre les titres, le contenu des tâches et mémos, ainsi que les éléments de checklists. Les noms de fichiers joints sont aussi indexés. Le système pondre les résultats pour privilégier les correspondances dans les titres.

Le swipe-to-dismiss fonctionne-t-il partout dans l'app ?

Le swipe-to-dismiss est actif sur tous les écrans de détail : détail de tâche, détail de mémo, détail d'événement calendrier. Il n'est pas actif sur les écrans principaux de navigation (onglets) pour éviter les conflits avec le swipe de changement d'onglet.

Comment la recherche gère-t-elle les groupes privés vs partagés ?

La recherche respecte strictement les politiques RLS de Supabase. Tu ne vois que les résultats auxquels tu as accès : tes éléments personnels et les éléments des groupes dont tu es membre. La contextualisation n'affecte que l'ordre, jamais les permissions.