Migrer une automatisation Zapier ou Make vers un nouvel hôte de géocodage
Les automatisations sans code construites autour d'une étape de géocodage demandent une autre approche de migration que le code sur mesure. Voici comment gérer ce changement.
Quitter une intégration de saisie semi-automatique Google Places
La saisie semi-automatique est un type d'intégration différent d'un simple appel de géocodage. Elle se déclenche à presque chaque frappe de l'utilisateur dans un champ d'adresse, dépend chez certains fournisseurs d'une tarification ou d'un regroupement par session, et la réponse doit revenir assez vite pour qu'aucun délai ne soit perceptible par la personne qui tape. Migrer cette partie comporte plus de risques pour l'expérience utilisateur qu'une tâche de géocodage par lots, précisément parce que les utilisateurs interagissent avec elle directement et en temps réel.
Google Places Autocomplete renvoie une liste de prédictions, chacune avec une chaîne description et un place_id utilisé dans un appel de détails ultérieur pour récupérer l'adresse complète et les coordonnées. Ce schéma en deux étapes, les prédictions d'abord, les détails ensuite, est un modèle d'interaction spécifique qui façonne une grande partie du code front-end construit autour de lui, y compris le délai d'anti-rebond et la façon dont les résultats sélectionnés s'affichent avant que l'appel de détails n'aboutisse.
C'est un cas où il importe de décrire honnêtement les capacités. My Geocode propose la saisie semi-automatique d'adresses dans le cadre de ses endpoints de recherche, avec une requête et une réponse dont la forme est documentée sur /docs/address-autocomplete/, mais le comportement spécifique de tout endpoint de saisie semi-automatique, y compris le regroupement par session et le classement des résultats, mérite d'être testé directement sur vos propres données d'adresses et habitudes d'utilisateurs plutôt que de supposer une correspondance exacte avec le modèle en deux étapes de Google. Les fournisseurs structurent différemment le passage de la suggestion au détail, et cette différence structurelle constitue généralement la plus grosse tâche réelle de la migration ici, davantage que n'importe quel nom de champ.
Étapes pratiques pour cette migration :
- Déterminez si votre implémentation actuelle a besoin du schéma en deux étapes, prédictions puis détails, ou si un endpoint de suggestion en un seul appel simplifierait en réalité votre code front-end
- Testez les réglages d'anti-rebond et de nombre minimal de caractères avec les temps de réponse réels du nouvel endpoint dans vos propres conditions réseau, plutôt que de réutiliser des valeurs ajustées pour l'infrastructure de Google
- Vérifiez comment votre interface gère une liste de prédictions vide ou ne contenant qu'un seul résultat, car le comportement de classement diffère sensiblement d'un fournisseur à l'autre et votre expérience de repli ne devrait pas dépendre de la réception de plusieurs suggestions
L'authentification du nouvel endpoint fonctionne avec une clé via un en-tête X-API-Key, Authorization: Bearer, l'authentification HTTP Basic ou un paramètre de requête. Il y a 2 500 requêtes gratuites par jour sans aucune clé, et 2 500 de plus gratuites par clé et par jour, comptées par réseau, au-delà desquelles la tarification repose sur du crédit prépayé à 0,0001 € par requête ou une clé Unlimited à 50 € par mois, au même tarif que tous les autres endpoints.
Comme les appels de saisie semi-automatique peuvent atteindre un volume élevé par rapport aux appels de géocodage proprement dits, puisque la plupart des frappes génèrent une requête, il vaut la peine d'estimer le volume quotidien attendu par rapport au quota gratuit et au tarif par requête avant de fixer une date de lancement, afin d'éviter toute surprise lors de la première semaine de trafic réel.