Corriger l'adresse – Exemples

Ce document décrit plusieurs scénarios concrets dans lesquels l'API Address Validation fournit des signaux de réponse qui peuvent justifier un comportement de correction de votre système. Pour plus de contexte, consultez les exemples de workflows dans Créer votre logique de validation.

Exemples courants : corriger

Cette section décrit des exemples courants dans lesquels l'API Address Validation fournit des signaux de réponse indiquant des informations d'adresse de qualité inférieure.

Ville et code postal manquants

Cet exemple illustre une entrée ne comportant que l'adresse de la rue, sans ville ni code postal.

Adresse saisie Région
21 45 40th street USA

Verdict pour la ville et le code postal manquants

L'exemple ci-dessous met en évidence les signaux importants de la réponse.

{
  "inputGranularity": "PREMISE",
  "validationGranularity": "OTHER",
  "geocodeGranularity": "OTHER",
  "hasUnconfirmedComponents": true,
  "possibleNextAction": "FIX"
}

L'icône possibleNextAction indique que l'adresse n'est peut-être pas valide. Les autres composants mis en évidence prennent également en charge cette possibilité. Vous pouvez donc interroger addressComponents pour en savoir plus :

{
  "componentName": {
    "text": "21",
    "languageCode": "en"
  },
  "componentType": "street_number",
  "confirmationLevel": "UNCONFIRMED_BUT_PLAUSIBLE"
},
{
  "componentName": {
    "text": "45 40th street",
    "languageCode": "en"
  },
  "componentType": "route",
  "confirmationLevel": "UNCONFIRMED_BUT_PLAUSIBLE"
},
{
  "componentName": {
    "text": "United States",
    "languageCode": "en"
  },
  "componentType": "country",
  "confirmationLevel": "CONFIRMED"
}

L'API Address Validation ne renvoie que le pays (États-Unis) sous la forme CONFIRMED. Il renvoie tous les autres composants d'adresse sous la forme UNCONFIRMED_BUT_PLAUSIBLE, avec quelques omissions importantes dans les données, telles que la localité et le code postal.

Numéro de rue manquant

Cet exemple montre un numéro de rue manquant.

Adresse saisie Région
Buckingham Palace Road, SW1W 9TQ Londres Royaume-Uni
Verdict pour un numéro de rue manquant
{
    "inputGranularity": "PREMISE_PROXIMITY",
    "validationGranularity": "ROUTE",
    "geocodeGranularity": "ROUTE",
    "possibleNextAction": "FIX"
}

Une fois encore, possibleNextAction indique initialement que l'adresse n'est peut-être pas desservie. De plus, validationGranularity est ROUTE, ce qui indique une correspondance avec la rue, mais pas assez d'informations pour accéder au bâtiment. De plus, la propriété addressComplete est manquante dans le verdict. Elle est donc false. Une autre requête de l'objet address révèle un type de composant manquant :

"missingComponentTypes": [
        "street_number"
      ]

Exemples de cas limites : correction

Dans certains cas, le choix entre corriger, confirmer ou accepter une adresse dépend de votre situation commerciale spécifique. Les exemples ci-dessous illustrent des scénarios qui ne relèvent pas forcément d'une catégorie de correction.

Numéro de rue non confirmé

Dans ce scénario, l'API Address Validation ne peut pas confirmer le numéro de rue fourni, mais indique que l'adresse est complète.

Adresse saisie Région
84 Buckingham Palace Road, SW1W 9TQ, Londres Royaume-Uni

Verdict pour un numéro de rue non confirmé

L'exemple ci-dessous met en évidence les signaux importants.

{
  "inputGranularity": "PREMISE",
  "validationGranularity": "PREMISE_PROXIMITY",
  "geocodeGranularity": "PREMISE_PROXIMITY",
  "addressComplete" : true,
  "hasUnconfirmedComponents": true,
  "possibleNextAction": "ACCEPT"
}

Il est intéressant d'étudier la combinaison d'une granularité de validation uniquement pour l'approximation au niveau des locaux avec des composants non confirmés. Une requête sur la propriété addressComponents affiche les componentType non confirmés suivants :

{
  "componentName": {
    "text": "84",
    "languageCode": "en"
  },
  "componentType": "street_number",
  "confirmationLevel": "UNCONFIRMED_BUT_PLAUSIBLE"
}

Ici, le confirmation_level de street_number est défini sur UNCONFIRMED_BUT_PLAUSIBLE. Non confirmé signifie que le service ne peut pas faire correspondre le numéro 84 dans son ensemble de données, et plausible signifie que les données des composants peuvent toujours être valides.

Sous-lieu manquant

Ce scénario décrit une adresse à laquelle il manque uniquement un sous-lieu, comme un numéro d'appartement ou de service. Sinon, l'API Address Validation peut valider complètement l'adresse. Comme c'est le cas lorsqu'un composant d'adresse est manquant, le addressComplete est false et n'est donc pas présent lors de l'inspection manuelle du verdict.

Par exemple, supposons qu'un client saisisse une adresse valide pour le bureau de l'évaluateur de la ville de San Francisco, mais qu'il oublie le numéro de la salle.

Adresse saisie Région
1 Doctor Carlton B Goodlett Place, San Francisco, CA 94102 USA

Verdict pour le sous-établissement manquant

Dans cet exemple, le verdict n'affiche pas la propriété addressComplete. Il est donc false. Vous savez donc qu'au moins un élément d'adresse est inattendu, non résolu ou manquant.

{
  "inputGranularity": "PREMISE",
  "validationGranularity": "PREMISE",
  "geocodeGranularity": "PREMISE",
  "hasInferredComponents": true,
  "possibleNextAction": "CONFIRM_ADD_SUBPREMISES"
}

Une requête address révèle les éléments suivants :

"missingComponentTypes": [
        "subpremise"
      ]

Après examen plus approfondi, les données USPS fournissent un code dpvConfirmation de D, qui indique également une sous-adresse manquante.