Le problème what3words apparaît quand une adresse en 3 mots devient une preuve terrain, alors que l'équipe traite encore la conversion comme un widget sympa à brancher dans un formulaire.
Le vrai enjeu n'est pas de transformer des mots en coordonnées. Il est de décider quelle suggestion est validée, quelle langue a été utilisée, quel carré a été retourné, quel quota protège le parcours et quelle preuve reste lisible par le support.
Vous allez comprendre comment décider, corriger et industrialiser `convert-to-3wa`, `convert-to-coordinates`, `autosuggest`, `grid-section`, `available-languages`, API key, `X-API-KEY`, `focus`, `clip-to-country`, `clip-to-circle`, `clip-to-bounding-box`, `clip-to-polygon`, `language`, `locale`, `BadWords`, `HTTP 402` et `HTTP 429`.
Contrairement à ce que laisse croire une démo fluide, le risque est de remplacer un problème d'adresse par un problème de preuve: trois mots mal entendus, mal saisis ou mal confirmés peuvent déplacer la décision terrain.
Pour cadrer cette architecture, notre accompagnement en intégration API aide à relier what3words, CRM, OMS, TMS, WMS, application terrain, portail client, support, observabilité et runbook. Le sujet se rattache aussi au guide API cartographie et géolocalisation, à la landing API cartographie et géolocalisation et à la page intégrateur what3words.
Pour qui what3words mérite une intégration dédiée
Identifier les usages vraiment adaptés
L'API what3words mérite une intégration dédiée pour la livraison terrain, les interventions en zones rurales, l'événementiel, les accès de chantier, les points de rendez-vous temporaires et les lieux difficiles à décrire par adresse classique.
Le cas typique n'est pas de remplacer toute adresse postale. C'est d'ajouter une précision de point quand une rue, un bâtiment, un parking, une entrée ou une zone ouverte reste ambiguë.
Le signal de priorité est simple: si une adresse 3 mots modifie une tournée, une intervention, un rendez-vous ou une promesse de service, alors le flux mérite un contrat de run complet.
Le point souvent sous-estimé concerne la pédagogie utilisateur. Une personne peut retenir trois mots, mais elle doit encore comprendre qu'une seule lettre, un pluriel ou un ordre différent peut changer la position.
Séparer aide à la localisation et preuve métier
L'API what3words sert à encoder ou décoder une position, pas à prouver seule qu'un client, un livreur ou un technicien est au bon endroit. La confirmation métier reste indispensable.
Une application robuste peut afficher la carte, le carré, le nearestPlace, les coordonnées et un message de confirmation. Elle ne doit pas écrire silencieusement une position critique après une suggestion non relue.
Le coût caché apparaît quand cette frontière manque. Le support traite alors une erreur de saisie comme une erreur de livraison, alors que le problème initial venait d'une validation trop faible.
En pratique, what3words est utile pour préciser un point. Il doit rester relié à une adresse, un contact, une consigne ou une photo quand le risque opérationnel dépasse une simple aide à l'orientation.
1. Comprendre API key, formats et erreurs
Protéger la clé API et les wrappers
L'API officielle demande une clé API valide, passée en paramètre `key` ou dans l'en-tête `X-API-KEY` selon les endpoints. Cette clé ne doit pas être exposée sans contrôle dans tous les écrans.
La plateforme what3words fournit aussi des wrappers pour JavaScript, Android, Java, Python, PHP, Swift et Objective-C. Le choix entre wrapper et REST direct doit dépendre du contexte d'exécution, pas d'une préférence isolée.
Le proxy interne peut porter OAuth2, JWT, IAM, rate limit, circuit breaker et journalisation. what3words reste concentré sur la conversion, tandis que le middleware porte sécurité, contrats et responsabilités.
Une rotation de clé doit être prévue avant incident. Le runbook doit dire quel secret changer, quels services redémarrer, quelles queues rejouer et quel owner valide la reprise.
Choisir JSON ou GeoJSON selon le consommateur
Les conversions peuvent répondre en `json` ou `geojson` selon le paramètre `format`. Le format JSON suffit souvent au SI, tandis que GeoJSON simplifie l'affichage cartographique.
Le modèle interne ne doit pas laisser chaque écran choisir son format. Il doit exposer un payload stable avec mots, coordonnées, carré, pays, nearestPlace, langue, locale et lien carte.
Le contrat REST interne peut être documenté dans OpenAPI et rejoué dans Postman ou Insomnia avec de vrais payloads. Cette preuve évite de confondre succès HTTP et validation terrain.
Cette couche contract-first évite aussi les divergences entre application mobile et back-office. Le même carré doit produire le même statut métier, quel que soit le canal de saisie.
Traduire les erreurs en décisions exploitables
La documentation décrit des erreurs comme `BadWords`, `BadCoordinates`, `BadLanguage`, `BadFormat`, `BadClipToPolygon`, `MissingWords`, `MissingInput`, `MissingBoundingBox`, `DuplicateParameter`, `MissingKey` ou `InvalidKey`, chacune à traduire côté métier responsable.
Le code HTTP seul ne suffit pas. Une erreur `400` peut venir d'un paramètre, d'une adresse inexistante ou d'une polygon trop grande, tandis qu'une erreur `401`, `402` ou `429` demande une réponse différente.
Si 2 % des saisies retournent `BadWords` pendant 7 jours, alors le seuil de décision doit améliorer AutoSuggest, l'aide de saisie ou le support vocal avant d'élargir le parcours.
Le support doit lire une phrase métier: adresse 3 mots invalide, clé manquante, quota dépassé, plan insuffisant, rate limit atteint ou zone de clipping impossible. Un code brut ne suffit pas.
2. Cadrer les deux conversions what3words
Utiliser `convert-to-3wa` pour encoder une coordonnée
L'endpoint `convert-to-3wa` transforme une latitude longitude WGS-84 en adresse 3 mots. Il accepte `coordinates`, `language`, `format` et `locale`, puis retourne notamment `country`, `square`, `nearestPlace`, `coordinates`, `words`, `language`, `locale` et `map`.
Ce flux convient quand l'application connaît déjà la position GPS ou cartographique et veut produire une adresse plus mémorisable. Il doit conserver les coordonnées d'origine et la réponse what3words.
Le bon modèle garde aussi le carré retourné, avec southwest et northeast. Cette preuve montre la zone concernée et évite de réduire le résultat à une chaîne de mots.
Si la position vient d'un mobile avec précision incertaine, alors le connecteur doit enregistrer la précision GPS ou demander une confirmation carte. Les mots ne corrigent pas un point mal capturé.
Utiliser `convert-to-coordinates` pour décoder une adresse
L'endpoint `convert-to-coordinates` transforme une adresse 3 mots en latitude longitude. Le paramètre `words` est requis, avec trois mots séparés par un caractère de type point et éventuellement préfixés par `///`.
La documentation mentionne plusieurs caractères de séparation acceptés et des règles particulières pour certaines langues comme le vietnamien. Le middleware doit donc normaliser sans détruire le sens.
Le résultat doit être relié à l'objet métier: commande, intervention, rendez-vous, billet événementiel ou fiche client. Une adresse 3 mots isolée dans les logs ne suffit pas à expliquer une action.
Le signal faible se voit quand le support recopie les trois mots à la main dans un autre outil. À ce moment, la conversion existe, mais la preuve n'est pas encore intégrée au SI.
Préserver langue, locale et pays dans la décision
Le paramètre `language` permet de demander une adresse 3 mots dans une langue supportée, tandis que `locale` précise certaines variantes comme cyrillique, latin, chinois traditionnel ou chinois simplifié.
Le pays retourné et le nearestPlace ne doivent pas être décoratifs. Ils aident l'utilisateur et le support à vérifier que les mots pointent vers la bonne zone avant toute décision terrain.
Le bon arbitrage consiste à accepter une adresse 3 mots seulement si mots, coordonnées, pays, nearestPlace, langue et objet métier sont cohérents. Une conversion isolée reste trop faible.
Une règle de mapping doit dire quelle langue afficher au client, quelle langue conserver en preuve et quelle locale utiliser dans les pays où plusieurs écritures sont possibles.
3. Industrialiser AutoSuggest, focus et clipping
Traiter AutoSuggest comme une aide, pas comme une validation
AutoSuggest prend une adresse complète ou partielle et propose des adresses 3 mots valides. Il corrige fautes de frappe, fautes d'orthographe, mots mal mémorisés et mots dans le mauvais ordre.
La documentation précise qu'une saisie partielle doit contenir au minimum les deux premiers mots complets et le premier caractère du troisième. Une saisie plus courte ne doit pas déclencher de promesse utilisateur.
Le produit doit afficher les suggestions comme des candidats. La validation finale doit enregistrer la suggestion retenue, son rang, sa langue, son pays, son nearestPlace et la décision utilisateur.
Si le rang 1 est souvent corrigé par le support, alors le problème vient du contexte fourni à AutoSuggest. Il faut revoir focus, clipping, message de confirmation ou parcours vocal.
Utiliser focus pour pondérer sans enfermer
Le paramètre `focus` pondère les résultats autour d'une coordonnée. Il ne remplace pas une restriction stricte et doit rester visible dans les logs pour expliquer le tri des suggestions.
AutoSuggest retourne notamment `distanceToFocusKm` et `rank` dans les suggestions. Ces champs doivent être conservés quand l'ordre influence une décision métier ou une correction support.
Contrairement à ce que l'on croit, plus de contexte ne veut pas toujours dire plus de vérité. Un focus mal positionné peut faire remonter une suggestion proche mais incorrecte.
Si le p95 AutoSuggest dépasse 800 ms pendant 30 minutes, alors le proxy doit réduire le volume de requêtes, renforcer le cache ou désactiver des aides secondaires avant que la conversion ne baisse.
Cadrer clipping pays, cercle, bounding box et polygone
AutoSuggest peut restreindre les résultats avec `clip-to-country`, `clip-to-circle`, `clip-to-bounding-box` ou `clip-to-polygon`. Plusieurs politiques peuvent se combiner, mais pas deux fois le même type.
La documentation indique qu'un code pays invalide ne produit pas forcément une erreur et peut simplement retourner zéro résultat. Le support doit donc distinguer absence réelle et mauvais clipping.
Le paramètre `clip-to-polygon` demande un polygone fermé et accepte jusqu'à 25 paires de coordonnées. Cette limite doit être validée avant de brancher des zones commerciales complexes.
Par exemple, si une zone de tournée exclut 4 % de suggestions valides sur 7 jours, alors le seuil doit suspendre ce clipping et déclencher une revue cartographique avant extension.
4. Utiliser grille, langues et locales
Afficher `grid-section` sans surcharger la carte
L'endpoint `grid-section` retourne une section de la grille what3words pour une bounding box. La documentation indique que la boîte demandée ne doit pas dépasser 4 km de coin à coin.
Le format GeoJSON rend l'affichage cartographique simple, mais il ne doit pas être appelé à chaque mouvement de carte sans cache. Une grille trop bavarde peut saturer l'expérience.
Le proxy doit limiter zoom, bounding box, fréquence et usage. Une carte support peut afficher la grille pour vérifier, mais un écran client n'a pas toujours besoin de toutes les lignes.
Si un utilisateur voit la grille, l'affichage doit rester clair: elle représente des carrés de 3m x 3m, pas une propriété, une adresse postale ou une zone administrative.
Synchroniser `available-languages` avec le produit
L'endpoint `available-languages` retourne les langues disponibles, avec code, nom anglais et nom natif. Cette liste doit alimenter les interfaces plutôt que rester copiée dans une constante oubliée.
La documentation cite des locales spécifiques pour certaines langues, comme `oo_cy`, `oo_la`, `kk_cy`, `kk_la`, `mn_cy`, `mn_la`, `zh_tr` ou `zh_si`, à conserver dans le modèle.
Une application internationale doit décider si elle laisse l'utilisateur choisir la langue des mots, si elle impose la langue du pays, ou si elle garde une langue unique pour le support.
La synchronisation doit être surveillée. Si une langue disparaît ou change de locale affichée, le support doit voir la date de mise à jour et la règle de repli.
Gérer voix, texte et variantes de saisie
AutoSuggest propose des modes liés à la voix, dont generic voice et certains formats Cerence. Pour la saisie vocale, la documentation recommande de définir la langue.
Le produit doit éviter de demander à l'utilisateur de prononcer "dot" entre les mots. Les flux vocaux et texte ne se normalisent pas de la même façon, surtout selon les langues.
Une transcription vocale doit rester auditable: texte reconnu, langue, suggestion retenue, rang, distance au focus et confirmation humaine. Cette preuve protège les équipes terrain.
Le signal faible apparaît quand les mêmes mots sont confondus à l'oral sans alerte produit. À ce moment, il faut améliorer le parcours vocal plutôt que multiplier les conversions.
5. Relier what3words au parcours métier
Ne pas remplacer l'adresse classique sans filet
L'adresse 3 mots apporte une précision utile, mais l'adresse classique, les coordonnées GPS, les consignes d'accès et le contact restent souvent nécessaires. Le SI doit garder ces informations ensemble.
Une livraison peut accepter trois mots pour l'entrée exacte, tout en conservant rue, ville, téléphone et note livreur. Le carré ne remplace pas toute la promesse logistique.
Le bon modèle distingue aide de localisation, preuve de rendez-vous et règle de livraison. Ces trois usages n'ont pas le même niveau de validation ni le même fallback.
Le risque est de croire qu'une adresse 3 mots supprime toute ambiguïté. En réalité, la saisie, la langue, le contexte et la confirmation restent des parties du run.
Brancher le flux au CRM, OMS, TMS et WMS
Le middleware doit décider quels systèmes consomment les mots, lesquels consomment les coordonnées et lesquels voient seulement un statut validé. Tous les outils n'ont pas besoin du même détail.
Le CRM peut garder la preuve client, l'OMS peut porter la décision de commande, le TMS peut exploiter les coordonnées et le WMS peut seulement afficher une consigne d'accès.
Le payload interne doit préciser entrées, sorties, responsabilités, owner, idempotence, schema et versioning. Cette discipline rend le connecteur testable avant l'ouverture aux équipes terrain.
Le middleware peut émettre un event interne après validation. what3words ne fournit pas un webhook métier de décision; c'est au SI de notifier ERP, CRM, OMS ou TMS.
Traduire chaque état en action support
Le support doit voir des statuts lisibles: mots valides, mots invalides, suggestion à confirmer, quota dépassé, rate limit atteint, plan insuffisant, carré affiché ou localisation à reprendre.
Chaque statut doit avoir une action autorisée. Corriger une faute, demander confirmation, revenir à une adresse classique ou escalader au terrain ne sont pas des gestes équivalents.
Si 5 pays ou zones concentrent 60 % des corrections, la priorité est à l'aide utilisateur locale plutôt qu'à une refonte API globale. Le diagnostic doit rester proche du parcours.
La fiche support doit aussi conserver le lien carte, quand il est utile, mais elle ne doit pas dépendre seulement d'une navigation externe pour prouver la décision interne.
6. Piloter quotas, plans et rate limits
Comprendre ce que le plan autorise vraiment
La documentation indique que le plan gratuit a accès à AutoSuggest et `available-languages`, mais pas aux conversions. Les conversions deviennent donc un sujet de plan et de quota, pas seulement de code.
Les comptes Business ont un quota de `convert-to-coordinates` sur la période de facturation. En cas de dépassement, les requêtes suivantes peuvent recevoir une réponse `HTTP 402`.
Le produit doit donc distinguer expérimentation, mise en production et montée en charge. Un prototype AutoSuggest gratuit ne prouve pas que la conversion terrain est prête à tenir le volume.
Si 80 % du quota de période est consommé par un seul flux, alors le seuil doit déclencher cache, priorisation ou évolution de plan avant que les opérations ne soient bloquées.
Prévenir les `HTTP 429` sur les parcours critiques
L'API what3words applique des rate limits par fonction. La documentation indique 10 requêtes par seconde pour AutoSuggest en plan gratuit et 200 requêtes par seconde sur les plans payants listés.
Un `HTTP 429` signifie que le rythme doit baisser. Le connecteur doit appliquer throttle, debounce, queue, retry avec backoff et circuit breaker plutôt que relancer immédiatement.
Le tableau de bord doit séparer AutoSuggest, conversions, grid-section et available-languages. Sans cette séparation, l'équipe ne sait pas quel écran consomme le rate limit.
Par exemple, si le p95 d'AutoSuggest dépasse 800 ms et que les `429` montent pendant 30 minutes, alors le proxy doit réduire la fréquence de saisie et protéger les conversions validées.
Mettre en cache sans figer une mauvaise décision
Le cache peut réduire les appels sur conversions déjà validées, langues disponibles et sections de grille. Il doit conserver date, endpoint, paramètres, plan, statut et décision métier.
Une suggestion AutoSuggest ne doit pas être cachée comme une décision finale. Le cache de saisie, le cache de conversion et le cache de support ont des durées et risques différents.
La file de retry doit rester idempotente. Si une conversion a déjà produit une position confirmée, une reprise ne doit pas créer une seconde position concurrente dans le TMS.
Le bon arbitrage consiste à cacher ce qui est validé, mais à demander confirmation dès qu'un changement modifie une tournée, une intervention ou une promesse client.
7. Modéliser what3words dans le SI
Construire un objet localisation interne
L'objet interne doit séparer mots, coordonnées, carré, pays, nearestPlace, langue, locale, map URL, source de saisie, endpoint, statut métier, date de validation et système propriétaire.
Cette normalisation évite de laisser chaque application interpréter what3words à sa manière. Le front, le support, le TMS et le datawarehouse consomment alors un contrat cohérent.
Le payload interne doit préciser ses entrées, ses sorties, son owner, ses responsabilités, son schema et son versioning. Cette discipline rend le middleware testable et maintenable.
Une évolution de schema doit rester rétrocompatible ou clairement versionnée. Le mobile peut afficher les mots, tandis que le datawarehouse a besoin de coordonnées et d'un statut durable.
Tracer acceptation, rejet et correction
Une saisie peut être invalide, ambiguë, corrigée par AutoSuggest ou validée par l'utilisateur. Le modèle doit garder la proposition acceptée et les candidats refusés quand la décision est critique.
Le signal faible se voit quand les mêmes lieux reviennent en correction manuelle sans panne API. À ce moment, le problème vient souvent de l'aide de saisie ou du message de confirmation.
Le reporting doit suivre les corrections par pays, langue, mode de saisie et écran. Si la voix concentre les erreurs, corriger l'interface texte ne changera presque rien.
La revue doit distinguer erreur utilisateur, suggestion non confirmée, quota dépassé et règle interne trop permissive. Ces causes ne se corrigent pas au même endroit.
Émettre des événements internes après validation
L'événement interne doit être émis seulement après acceptation métier. Il doit porter ancienne position, nouvelle position, mots, coordonnées, objet lié, utilisateur, horodatage et clé de corrélation.
Cet event permet à CRM, OMS, TMS ou WMS de se synchroniser sans relire what3words eux-mêmes. La réconciliation devient possible quand une position est contestée.
Sans cette trace, une correction de 3 mots peut se propager dans plusieurs outils sans explication. Le support voit le changement, mais ne sait plus qui l'a validé.
L'événement doit être idempotent. Si le même carré est validé deux fois, les systèmes aval doivent reconnaître la même décision plutôt que créer deux versions concurrentes.
8. Plan d'action what3words
Prioriser le premier parcours utile
Le premier périmètre doit être court: saisie d'une adresse 3 mots, conversion en coordonnées, affichage carte, confirmation utilisateur et transfert vers un outil opérationnel.
L'équipe doit écrire ce qui sera accepté, rejeté, mis en attente ou corrigé. Cette grille pilote ensuite endpoint, format, cache, erreurs, quota, support et règles de synchronisation.
Un seuil de sortie simple aide le lancement: 100 positions réelles rejouées, moins de 2 % de suggestions non classées, zéro écriture sans confirmation et une fiche support lisible par un non-développeur.
Le premier périmètre doit aussi avoir un owner métier. Sans owner, chaque arbitrage entre adresse classique, coordonnées GPS et 3 mots remonte trop tard à l'équipe technique.
Prototyper avec vrais usages terrain
Le prototype doit inclure zones rurales, entrées multiples, parkings, événements, lieux temporaires, saisie vocale, mots mal orthographiés et positions proches d'une frontière ou de la mer.
Cette étape compare AutoSuggest, conversion directe, clipping, focus, langue et confirmation carte sur les mêmes objets métier. Le résultat attendu est une décision, pas seulement une coordonnée.
Si les tests échouent surtout sur la voix ou la pédagogie, augmenter le quota ne corrigera pas la racine. Il faut revoir le parcours utilisateur et les messages de confirmation.
Les jeux de tests doivent être conservés comme des fixtures. Ils serviront aux non-régressions quand un pays, une langue ou un canal de saisie sera ajouté.
Développer proxy, cache et observabilité
Le proxy doit imposer endpoints autorisés, paramètres acceptés, timeout, cache, rate limit et traduction d'erreur. Il doit aussi empêcher un écran public de consommer tout le quota.
Les logs doivent raconter une histoire complète: endpoint, paramètres, durée, plan, quota, cache hit, suggestion acceptée, suggestion refusée, statut métier, objet lié et action support.
Une alerte utile inclut un seuil et une décision. Par exemple, plus de 4 % de `BadWords` pendant 24 heures doit bloquer l'élargissement et déclencher une revue d'interface.
Le monitoring doit aussi suivre les erreurs `402` et `429`. Un quota dépassé, un plan insuffisant et un débit trop élevé ne demandent pas le même rollback.
Écrire runbook, rollback et contrat support
Le runbook doit dire quoi faire si la clé est invalide, si le quota est dépassé, si AutoSuggest retourne zéro résultat, si le clipping est trop strict ou si la conversion est contestée.
Le rollback peut revenir à l'adresse classique, bloquer la saisie 3 mots, garder seulement les positions déjà validées, désactiver grid-section ou passer les cas douteux en revue support.
Cette préparation évite le faux choix entre tout couper et tout laisser passer. Les positions fiables restent ouvertes, tandis que les saisies ambiguës attendent une confirmation.
Le rollback doit être testé avant mise en ligne. Si revenir à l'adresse classique prend plus de 20 minutes en recette, l'équipe sera trop lente pendant un incident réel.
Préparer l'extension sans refaire le projet
L'extension doit venir après les preuves de run. Un second pays, un second canal ou un second outil opérationnel doit réutiliser le même modèle, les mêmes statuts et les mêmes seuils.
Le comité de suivi doit rester court: erreurs récurrentes, consommation de quota, corrections support, stabilité des caches, dette de mapping et décision sur les nouvelles demandes.
Si les questions support baissent de 30 % après 30 jours et que les seuils restent stables, alors l'élargissement devient défendable. Sinon, il faut corriger avant d'ajouter des usages.
L'extension doit rester mesurable. Chaque nouveau parcours doit préciser quel indicateur de qualité prouvera que what3words améliore le run au lieu d'élargir la dette.
9. Erreurs fréquentes avec what3words
Les pièges qui cassent la localisation
- Remplacer l'adresse classique par trois mots sans confirmation carte, consigne terrain, coordonnées et preuve support exploitable.
- Traiter AutoSuggest comme une validation finale, alors qu'il propose seulement des candidats à confirmer.
- Exposer la clé API dans plusieurs fronts sans proxy, quota, rate limit, owner et stratégie de rotation.
- Ignorer `HTTP 402` et `HTTP 429`, puis découvrir trop tard que le plan ou le débit bloque le parcours critique.
- Ne pas conserver langue, locale, pays, nearestPlace, carré et suggestion retenue dans l'objet métier.
Ces erreurs restent discrètes au prototype, car la conversion répond vite sur un exemple connu. Elles deviennent visibles quand plusieurs pays, langues, supports et équipes exploitent le même flux.
Le bon arbitrage consiste à refuser une nouvelle famille d'appels tant que endpoint, quota, cache, owner, statut, rollback et preuve ne sont pas écrits dans le contrat interne.
Cette rigueur protège aussi les équipes terrain. Une mauvaise intégration peut faire croire que what3words est imprécis, alors que le problème vient souvent d'une saisie non confirmée ou d'un contexte absent.
Le piège le plus courant est d'ajouter des suggestions pour compenser une décision floue. En réalité, il faut d'abord dire quelle preuve terrain est acceptable, puis seulement ajuster AutoSuggest.
Reconnaître les limites d'un adressage en mots
Une adresse 3 mots peut être pratique à transmettre, mais elle reste sensible à la langue, à la mémoire, à la saisie, à la voix et au contexte géographique.
Au départ, ces limites ressemblent à de petits écarts de saisie, mais elles deviennent visibles quand un livreur, un technicien ou un client conteste le point exact.
Si plus de 3 % des positions critiques demandent une correction manuelle sur 14 jours, alors le parcours doit sortir de l'automatisation complète jusqu'à revue du modèle.
Une limite assumée vaut mieux qu'une promesse globale fragile. Le back-office peut indiquer "confirmation terrain requise" plutôt que publier une position qui sera contestée plus tard.
10. Recette, rollback et support what3words
Tester les familles d'appels avant ouverture
La recette doit couvrir conversion vers coordonnées, conversion vers 3 mots, AutoSuggest, focus, clipping pays, clipping cercle, grid-section, langues disponibles, clé invalide, quota dépassé et rate limit.
Chaque cas doit produire une preuve: endpoint, paramètres, statut HTTP, durée, cache, words, coordonnées, carré, pays, nearestPlace, suggestion retenue, statut métier et objet interne lié.
Un seuil de sortie protège le lancement: 100 % des appels critiques traçables, moins de 2 % de suggestions non classées, zéro écriture sans confirmation et fallback documenté pour chaque parcours.
La recette doit être exécutable par le support avec une collection Postman, des cas sandbox et des réponses attendues. Cette autonomie révèle les zones encore trop dépendantes des développeurs.
Préparer un rollback sans perdre la localisation
Le rollback ne doit pas supprimer toute la localisation. Il peut revenir à l'adresse classique, garder le cache validé, désactiver AutoSuggest vocal ou bloquer les conversions non confirmées.
Si 3 incidents critiques touchent le même endpoint en 24 heures, si le quota est consommé trop tôt, ou si plus de 5 % des positions changent après correction, le mode contrôlé doit s'activer.
Cette approche garde les usages fiables ouverts. Elle évite le faux choix entre couper toute la localisation et laisser une saisie incertaine alimenter silencieusement plusieurs systèmes.
Le mode contrôlé doit être visible dans les applications. Un utilisateur doit comprendre qu'une position est en validation, plutôt que croire que le système a oublié ses trois mots.
Donner au support une lecture actionnable
La fiche support doit traduire what3words en statuts lisibles: mots confirmés, mots invalides, suggestion ambiguë, quota atteint, plan insuffisant, rate limit actif, clipping trop strict ou position à confirmer.
Le support doit pouvoir répondre à quatre questions: quels mots ont été saisis, quelles coordonnées ont été retenues, pourquoi la suggestion a été acceptée et quelle correction est autorisée.
Si une personne qui n'a pas participé au projet ne peut pas expliquer un cas simple en moins de 15 minutes, alors l'intégration fonctionne techniquement mais n'est pas prête pour un run autonome.
La fiche support doit inclure exemples acceptés et refusés: mots mal orthographiés, mauvais pays, focus absent, clipping trop strict, quota dépassé et position contestée sur carte.
Mesurer la stabilité après mise en production
Les 30 premiers jours doivent suivre par parcours: appels, quota, latence, erreurs, cache hit, `BadWords`, `402`, `429`, corrections manuelles, tickets support et écarts entre systèmes.
Cette mesure décide les extensions. Un parcours stable peut être élargi, tandis qu'un parcours ambigu doit être limité, corrigé ou déplacé vers validation humaine avant de toucher plus d'utilisateurs.
Le bon résultat n'est pas seulement une position trouvée. Le bon résultat est une décision terrain traçable, conforme aux limites du plan, compréhensible par le support et soutenable dans le temps.
Après ce premier mois, l'équipe doit savoir quels pays sont stables, quels écrans consomment trop de quota et quelles corrections doivent devenir des règles plutôt que rester des gestes support.
Questions fréquentes what3words
À quoi sert l'API what3words ? L'API what3words sert à convertir coordonnées et adresses 3 mots dans les deux sens, proposer des corrections avec AutoSuggest, afficher une section de grille et récupérer les langues disponibles.
Quand utiliser AutoSuggest et que permet le plan gratuit ? AutoSuggest convient quand l'utilisateur saisit, dicte ou corrige les mots et que le produit doit proposer des candidats avant validation. La documentation indique aussi que le plan gratuit donne accès à AutoSuggest et `available-languages`, tandis que les conversions et leurs quotas dépendent des plans Business.
Dawap peut-il accompagner une intégration what3words ? Oui. Dawap accompagne le cadrage, le développement et l'industrialisation de flux what3words pour conversions, AutoSuggest, quotas, proxy, cache, observabilité, support et rollback.
Que faut-il stocker après validation ? Il faut conserver mots, coordonnées, carré, pays, nearestPlace, langue, locale, endpoint, statut, objet métier lié et preuve de confirmation pour relire une contestation.
Guides complémentaires après what3words
La ressource API Pelias complète what3words avec un angle utile sur géocodage ouvert, AutoSuggest, GeoJSON, index, sources géographiques et contrôle des résultats dans un SI.
La ressource API Nominatim prolonge what3words avec une lecture centrée sur search, reverse, OpenStreetMap, cache, attribution, usage responsable, politiques d'usage et limites d'une instance publique.
La ressource rate limiting API aide à cadrer quotas, 402, 429, throttles, queues, retries et arbitrages de priorité quand what3words alimente plusieurs parcours critiques.
La landing API cartographie et géolocalisation permet de relier ce sujet à l'offre métier correspondante, tandis que la page intégrateur what3words précise l'accompagnement possible pour une localisation en 3 mots maîtrisée.
Conclusion opérationnelle what3words
Une intégration what3words réussie ne se mesure pas au premier point affiché. Elle se mesure à la capacité de l'équipe à expliquer mots, coordonnées, carré, pays, quota, erreur et décision métier.
Le bon ordre reste stable: cadrer le parcours, protéger la clé API, choisir les endpoints, versionner le mapping, suivre 402 et 429, préparer le rollback et donner au support une preuve lisible.
La différence se voit surtout après la mise en production. Un flux what3words bien intégré permet de corriger une position, retrouver sa source, rejouer une synchronisation et expliquer une décision sans relancer une enquête technique. Le support voit la suggestion retenue, le terrain voit la position, et le SI conserve une décision réconciliable avec adresse, commande, tournée ou intervention.
Si vous devez brancher what3words dans une architecture métier robuste, notre accompagnement en intégration API peut cadrer conversions, AutoSuggest, quotas, cache, observabilité et support sans déplacer la dette vers les équipes terrain.
