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 cles a retenir :
- La recherche unifiee interroge simultanement taches et memos avec ponderation par pertinence et recence.
- La recherche contextuelle priorise les resultats 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 fluidite d'une app est la somme de centaines de micro-decisions UX invisibles.

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

Quand un utilisateur ouvre une app de productivite, il cherche quelque chose. Une tache, un memo, une information. Si la recherche est lente, mal ciblee ou absente, l'app entiere semble cassee. C'est un fait que le Nielsen Norman Group documente depuis des annees.

Dans TAMSIV, la recherche n'est pas un champ texte basique pose en haut de l'ecran. C'est un systeme unifie qui interroge simultanement les taches, les memos et les evenements calendrier, dans tous les contextes accessibles a l'utilisateur.

Le SearchService est un singleton qui centralise toutes les requetes de recherche. Il utilise le full-text search de PostgreSQL via Supabase pour des resultats rapides et pertinents, meme avec des milliers d'elements.

Comment fonctionne la ponderation des resultats de recherche ?

Tous les resultats ne se valent pas. Quand tu tapes "reunion", tu veux probablement la reunion de demain, pas celle d'il y a 3 mois. Le systeme de ponderation 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 gere ca nativement.
2. La recence : les elements recemment crees ou modifies sont booste. Un coefficient decroissant base sur la date de derniere modification penalise les vieux resultats.

Ce double classement est crucial. Sans lui, une recherche sur "rapport" retournerait 200 resultats dans un ordre incomprehensible. Avec, les 3 premiers resultats sont presque toujours les bons.

J'ai optimise ce systeme avec le cache de contenu pour eviter les requetes couteuses a chaque frappe de touche. Le debounce de 300ms combine au cache memoire rend la recherche quasi instantanee.

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

La recherche "classique" traite tous les resultats de maniere egale. Tu cherches "budget", tu obtiens tous les elements contenant "budget" dans toute l'app. C'est correct mais inutile quand tu es en plein travail dans un groupe specifique.

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

Comment ca marche techniquement ?

• Le SearchService recoit le contexte courant (groupe ID, type de vue) en parametre
• La requete ajoute un boost de pertinence pour les elements du contexte actuel
• Les resultats sont tries : contexte actuel → personnel → autres groupes
• Aucun resultat n'est filtre — seul l'ordre change

Ce comportement est inspire de la FilterBar du systeme d'agenda qui applique le meme principe de filtrage contextuel. L'utilisateur voit d'abord ce qui est pertinent dans son contexte de travail.

C'est une subtilite UX qui ne se remarque pas consciemment, mais qui fait toute la difference entre une app ou tu trouves tout de suite et une app ou tu galeres.

Comment implementer 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'ecran pour revenir en arriere est devenu un reflexe sur mobile.

Dans TAMSIV, j'ai implemente ce pattern sur tous les ecrans de detail (tache, memo, evenement) avec une stack technique precise :

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

Le point critique : le seuil de declenchement. Trop bas (30px), le swipe se declenche accidentellement en scrollant. Trop haut (200px), l'utilisateur doit forcer et l'experience est penible.

Apres des dizaines de tests, j'ai calibre le seuil a 100 pixels. C'est le sweet spot — suffisamment haut pour eviter les faux positifs, suffisamment bas pour etre naturel. Ce seuil est combine avec une velocite minimale : un swipe lent meme au-dela de 100px ne declenche pas le retour.

Un piege 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 decouvert a la dure et documente dans les conventions du projet.

Quelles micro-decisions UX separent un prototype d'un produit ?

La fluidite d'une app n'est pas une feature. C'est la somme de centaines de micro-decisions. Chacune est invisible individuellement. Ensemble, elles font la difference entre "cette app est bien" et "cette app est geniale".

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

1. Le debounce de recherche a 300ms : pas de requete a chaque touche. L'utilisateur finit de taper, puis la recherche se lance. Imperceptible, mais ca divise par 10 le nombre de requetes.
2. Les resultats persistants pendant le chargement : quand tu modifies ta requete, les anciens resultats restent visibles jusqu'a ce que les nouveaux arrivent. Pas de flash blanc.
3. L'animation de transition a 250ms : le sweet spot pour les transitions d'ecran. Plus rapide semble bacle, plus lent semble lent. Material Design confirme cette plage.
4. Le feedback haptique sur swipe : une vibration legere quand le seuil est atteint confirme l'action sans regarder l'ecran.
5. Le scroll inertiel preserve : quand tu reviens en arriere par swipe, la liste est a la meme position qu'avant. Pas de retour en haut.

Chacune de ces decisions 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 fluidite d'une application mobile ?

La fluidite ne se mesure pas uniquement en FPS. Voici les metriques que je surveille dans TAMSIV :

• Time-to-first-result : le temps entre la premiere lettre tapee et l'affichage du premier resultat de recherche. Objectif : < 200ms.
• Gesture recognition rate : le pourcentage de swipes detectes correctement vs les faux positifs. Objectif : > 98%.
• Navigation depth : le nombre de taps necessaires pour atteindre n'importe quel contenu. Objectif : 3 taps maximum.
• Perceived performance : la sensation de rapidite, independamment des metriques brutes. Les animations et le design des interactions jouent un role majeur.

Le dashboard admin me permet de suivre ces metriques en temps reel et de detecter les regressions 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'equation. Avec le dictaphone integre, TAMSIV offre une alternative encore plus rapide : la recherche vocale implicite.

Quand tu dis "ou est le rapport marketing de la semaine derniere ?", l'IA ne se contente pas de creer un element — elle recherche dans tes donnees existantes et te repond. C'est le pipeline vocal qui traite cette requete, pas le SearchService, mais le resultat est le meme : tu trouves ce que tu cherches sans taper.

La combinaison recherche textuelle + recherche vocale + navigation par swipe cree une experience ou l'app s'efface derriere l'action. Tu ne penses plus a l'interface — tu fais ce que tu as a faire.

FAQ

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

La recherche utilise un cache memoire local qui conserve les derniers resultats et les elements frequemment accedes. Pour une recherche complete avec resultats a jour, une connexion est necessaire car le full-text search est execute cote serveur via Supabase.

Peut-on rechercher dans les checklists et les pieces jointes ?

Oui, la recherche couvre les titres, le contenu des taches et memos, ainsi que les elements de checklists. Les noms de fichiers joints sont aussi indexes. Le systeme pondre les resultats pour privilegier 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 ecrans de detail : detail de tache, detail de memo, detail d'evenement calendrier. Il n'est pas actif sur les ecrans principaux de navigation (onglets) pour eviter les conflits avec le swipe de changement d'onglet.

Comment la recherche gere-t-elle les groupes prives vs partages ?

La recherche respecte strictement les politiques RLS de Supabase. Tu ne vois que les resultats auxquels tu as acces : tes elements personnels et les elements des groupes dont tu es membre. La contextualisation n'affecte que l'ordre, jamais les permissions.