Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: Ajout d'une page de recherche de Services et Structures par mots-clé #242

Merged
merged 1 commit into from
Feb 13, 2025

Conversation

jbuget
Copy link
Contributor

@jbuget jbuget commented Feb 11, 2025

🍣 Problème

Nous sommes souvent sollicités par nos utilisateurs qui nous demandent d'ajouter des possibilités de recherche textuelle sur la plateforme DORA.

Nous nous posons la question de savoir dans quelle mesure proposer de la recherche textuelle pour les Services ou les Structures à nos usagers Accompagnateurs leur permettrait de trouver plus vite, facilement et efficacement une solution adaptée à la situation du Bénéficiaire qu'ils aident.

Nous souhaitons mener une expérimentation à peu de frais (temps, argent, code, déploiement, énergie) pour évaluer cette hypothèse métier.

🍓 Solution

Ajouter une nouvelle page expérimentale – /recherche-textuelle – qui intègre un moteur de recherche de Google (Google Custom Search Engine), lequel s'appuie sur l'indexation et la recherche des structures et services référencés via Google Search (grâce au sitemap de DORA).

Pour des raisons pratiques et éthiques, nous ne souhaitons pas ancrer cette solution dans le long terme. Nous en faisons une décision technique et un moyen pragmatique et rapide d'évaluation d'un besoin + piste de solution. La solution technique n'a pas vocation à perdurer au-delà de quelques mois en production, le temps de recueillir suffisamment de résultats et d'enseignements utiles.

⚠️ Important ! ⚠️ Cette PR ajoute une nouvelle variable d'environnement statique publique côté front (donc du style VITE_XXX dans le fichier .env). Si cette variable n'est pas définie, alors la page n'affiche que l'encart pour indiquer qu'il s'agit d'une modalité en cours de test, sans rien d'autre.

image

🤖 Implémentation

1/ Déclaration et configuration d'un nouveau Programmable Search Engine dans le panneau de contrôle (https://programmablesearchengine.google.com/controlpanel/all) :

  • définition des URLs d'indexation dans lesquelles piocher pour proposer des résultats
  • définition des onglets (i.e. libellés) "Services" et "Structures"
  • définition du layout (searchbar et result list sur une même page)
  • définition des polices et couleurs (boutons et textes)
  • définition des paramètres d'URL (i.e. query params) de la page couplés aux composants de recherche du moteur (q)

À la fin, nous obtenons un identifiant de moteur (publique) ainsi qu'un snippet de code à intégrer dans notre application front-end / Sveltekit.

image

2/ Dans la mesure où il s'agit d'une expérimentation et que le code sera retirée et oublié dans quelques semaines, nous prenons le parti de ne pas over-engineerer la solution. Nous nous contentons d'intégrer le snippet de code directement dans la page /recherche-textuelle/+page.svelte. Pour cela, nous surchargeons l'en-tête de la page via le tag <svelte:head>.

Le composant fourni par Google se charge bien et les styles définis dans le panneau de contrôle sont bien appliqués.

Toutefois, il y a quelques éléments qui gâchent un peu le rendu d'un point de vue esthétique (un padding général autour des composants et des images "Impulsés / Optimisés par Google" de mauvais effet, malgré que nous ayons bien obtenu le droit auprès de Google de cacher la marque et activé l'option idoine). Nous sommes obligés de forcer du CSS dans l'en-tête (lorsque les styles sont définis en bas de page, le composant ne s'affichait plus).

Par défaut, le composant Google charge de nombreuses ressources sous-jacentes (images, scripts, etc.). Nous sommes obligés de les intégrer en partie dans nos CSP. Nous ignorons les ressources que nous estimons trop invasives, inutiles ou nocives pour les données et l'expérience Web de nos utilisateurs (ex : ce qui a trait au tracking ou à la publicité).

3/ Afin de recueillir des retours qualitatifs directement de la part de nos usagers, nous ajoutons un lien vers un formulaire (Tally).

4/ TODO : Lorsque la solution sera déployée, il faudra ajouter dans notre solution de suivi (Matomo) les bons tags & events.

☑️ Recette

  • Avoir une nouvelle page dans le site accessible à dora.xxx/recherche-textuelle
  • Voire le bon chemin dans le fil d'Ariane
  • Voir l'encadré (en-dessous du composant double Google) qui explique l'expérimentation (de type Notice / warning)
  • Avoir un lien vers le formulaire Tally de prise de feedbacks
  • Voir les éléments du composant Google CSE dans le style de DORA / des maquettes (sans les logos Google)
  • Pouvoir saisir des mots-clés de recherche textuelle dans une barre de saisie de texte (soumettable via le bouton "loupe" ou la touche clavier "entrée")
  • Voir les résultats proposés par Google, issus de l'indexation par Google Search Engine (exclusivement les Services et Structures dites DORA, i.e. saisis, gérés et publiés par les responsables de structures directement sur DORA)
  • Pouvoir accéder à une Fiche Service / Structure directement depuis l'un des résultats
  • Pouvoir revenir en arrière depuis une Fiche Service / Structure en ayant la recherche conservée…
  • … ainsi que l'onglet sélectionné ("Tous les résultats", "Services", "Structures")
  • Voir que l'URL se met à jour à chaque soumission de recherche ou retour dans l'historique

@jbuget jbuget marked this pull request as draft February 11, 2025 18:39
@jbuget jbuget force-pushed the feat/text-search branch 4 times, most recently from c84c9cb to d4b2e1c Compare February 13, 2025 09:58
@jbuget jbuget marked this pull request as ready for review February 13, 2025 09:58
@jbuget jbuget force-pushed the feat/text-search branch 2 times, most recently from 344ff75 to bbc01de Compare February 13, 2025 10:59
@ggounot ggounot self-requested a review February 13, 2025 14:26
Il s'agit d'un test produit, pour valider l'hypothèse selon laquelle la recherche textuelle permettrait aux accompagnateurs de trouver plus facilement et rapidement les services d'insertion pour la personne qu'ils accompagnent.

Plutôt que poser toute une architecture interne de moteur de recherche textuelle avancée, nous testons un prototype très rapide basé sur Google.

Celui-ci ne permet de rechercher et proposer seulement les services gérés dans DORA (donc, pas ceux de data•inclusion), référencés sur Google Search.

La fonctionnalité embarque :
* une nouvelle page à l'URL /recherche-textuelle
* cette page est non-SSR
* pour activer la fonctionnalité, il faut au prélable avoir définie la variable d'environnement VITE_GOOGLE_CSE_ID (fichier .env pour du localhost)
* les styles sont définis côté IHM d'admin de Google CSE (cse.google.com), sauf pour certains éléments spécifiques
* attention ! cette fonctionnalié oblige à ouvrir de nombreuses CSP et notamment autoriser le `unsafe-eval` pour le type "script-src"

Dans les prochains mois, une fois que l'expérience aura porté ses résultats et que l'hypothèse pourra être conclue (validée ou pas), ce code sera retiré.
Copy link
Contributor

@ggounot ggounot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM 🚀 Bravo pour les hacks de haut niveau !

@ggounot ggounot merged commit 957005f into main Feb 13, 2025
7 checks passed
@ggounot ggounot deleted the feat/text-search branch February 13, 2025 15:54
@service-dev-gip-inclusion

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants