ETQ compétence voirie, je souhaite pouvoir entrer une adresse avec de l'aide à la saisie afin de limiter les erreurs

[mmarchois]

User story

En tant que compétence voirie, je souhaite pouvoir saisir une localisation avec de l'aide à la saisie afin de limiter les erreurs de saisie

Critères d'acceptation

• (Must have) Toggle "toute la commune"
• (Must have) Champs adresse (ville + voie) en autocomplete.

Design

TODO par @aureliebaton ou @astranchet pour maquetter (notamment le toggle)

Implémentation

Spécification du champ d'adresse en autocomplete :

• Si j'ai coché "toute la commune", je dois utiliser le type "commune" de l'api adresse
• Si je n'ai pas coché "toute la commune", je dois utiliser le type "rue" de l'api adresse

• Endpoint d'API servant de proxy avec l'API Adresse
• Adapter le formulaire : un seul champ "adresse"
• Ajouter l'autocomplétion sur le champ adresse add address autocomplete #255

Solution technique d'autocomplétion

Réutiliser le code de stimulus-autocomplete directement dans le repo, en l'adaptant au besoin

Notamment:

• On pourra adapter les styles pour utiliser ceux du DSFR (le code utilise bootstrap par défaut)
• D'après Accessibility afcapel/stimulus-autocomplete#120 qui renvoie vers https://www.w3.org/WAI/ARIA/apg/patterns/combobox/examples/combobox-autocomplete-list/#rps_label il y aura quelques ajustements d'accessibilité à faire (éventuellement à contribuer en retour par la suite)

Inspirations

• Exemple accessible gov.uk

Solutions rejetées

• Symfony a un bundle symfony/ux-autocomplete. Mais il semble y avoir des styles inclus et un comportement plutôt "multiselect autocomplete" par défaut (plutôt qu'un autocomplete sur un <input />, bien que ça semble possible)

Contexte supplémentaire

https://adresse.data.gouv.fr/api-doc/adresse

[mmarchois]

Cette issue permettra de résoudre :

• Les numéros de début et de fin devraient être optionnels #175
• Affinage UX des erreurs géocodage #101

[florimondmanca]

Proposition d'UX et réalisation basée sur un seul champ "adresse" et de deux champs "Numéro de début" et "Numéro de fin"

Voir discussion des différentes options : https://pad.incubateur.net/5lDle3AERgiosMbDQyRMnA?both#2023-04-03---D%C3%A9veloppement-autocompl%C3%A9tion

• Le champ "Adresse" est un texte simple combinant Nom de la rue + Ville + CP. Par exemple "Rue Colbert 76300 Sotteville-lèz-Rouen". Elle est stockée en BDD comme un seul champ texte. Cela permet de traiter l'API Adresse comme une source de vérité, car celle-ci traite des adresses sous ce format texte simple.
• Peut-on faire un pré-remplissage à partir de CP/ville paramétré dans l’organisation ? Oui, on pourrait les passer en paramètres à l’API Adresse qui ne renverrait alors que les rues correspondantes. NB : dès lors, on n'aura pas de résultats en dehors de la ville. Pour une orga sans ville paramétrée (ex : EPCI), on continuerait alors à avoir des résultats sans limitation de ville.
• Interaction entre le champ "Adresse" et l'option "Toute la ville" : on propose qu'il contrôle le "mode de recherche" du champ adresse : mode "rue" ou mode "ville".
  • Techniquement, cela jouerait sur le paramètre type de l'API Adresse : mode "rue" = type: street (les résultats de recherche sont des rues), mode "ville" = type: municipality (les résultats de recherche sont des villes).
  • Ainsi, quand on active "Toute la ville", les résultats de recherche montreront des villes.
  • Que se passe-t-il si on active "Toute la ville" alors que le champ "Adresse" contenait déjà une valeur, par exemple "Rue Colbert 76300 Sotteville-lèz-Rouen" suite à une précédente recherche ? 2 possibilités : 1) la valeur ne change pas, 2) La valeur change et est remplacée par la ville uniquement. On propose l'option 1) par simplicité d'implémentation. En effet l'option 2 rajouterait un peu de code côté navigateur, mais si l'intérêt UX le justifie on peut envisager. Dans le cas de l'option 1, en cas de besoin, le serveur pourra refaire un appel à l'API Adresse en mode municipality pour récupérer le nom de la ville à partir de la valeur du champ adresse. Cela peut servir par exemple à requêter le polygône GPS de la ville pour l'indiquer dans l'export DATEX.
• Rues présentes dans de nombreuses villes : le problème ne se pose pas si la ville est pré-paramétrée au niveau de l’organisation (puisque la recherche d'adresse se fera dans la ville souhaitée). Le problème est moindre pour les EPCI qui vont de toute façon souvent devoir préciser la ville.
• Numéros de rue : au lieu de calculer leurs coordonnées GPS avec l'API Adresse, on propose de les stocker comme de simples champs textes non-validés et stockés tels quels dans DATEX. À l'avenir une solution qui combinerait UX claire et stockage de coordonnées GPS serait un composant carte. En l'absence de ce composant, l'UX pour faire remonter les erreurs de géocodage à cause d'un mauvais numéro de rue n'est pas très sympa.

Niveau archi on continuerait de faire office de proxy entre le navigateur et l'API Adresse, avec probablement un cache sur le terme de recherche pour éviter de surcharger l'API Adresse et de lui faire des appels HTTP inutiles :

TODO : discussions avec le design

[florimondmanca]

@aureliebaton @astranchet Voici un aperçu de ce que ça donnerait

[aureliebaton]

@florimondmanca petits détails :

• Est-ce qu'il y aurait moyen de mettre les champs "numéro" comme sur la maquette, l'un à côté de l'autre ? Comme ce sera court au niveau du nombre de caractères.
• Pour la lisibilité, est-ce qu'on peut avoir une virgule après la rue, comme dans Maps et autres :

[florimondmanca]

@aureliebaton Oui, on va prendre ça en compte