Rechercher un indicatif avec le lookup JSON
Le point d’accès lookup reçoit un code composé de chiffres et renvoie la destination canonique ainsi que le ou les résultats associés.
Tester une réponse
Chargement de l’exemple +212…
Le résultat indique un pays, plusieurs territoires partageant le même code ou un service international. La propriété canonical pointe vers la page éditoriale qui explique l’ambiguïté.
Interpréter le JSON
| Champ | Rôle |
|---|---|
query | Code numérique recherché |
canonical | Page de référence correspondant au résultat |
results | Liste des pays, zones ou services possibles |
limitation | Précaution d’interprétation |
data_last_verified | Date de vérification du jeu de données |
Codes partagés et recherche complète
Un code ne désigne pas toujours un seul pays. +1 appartient au plan nord-américain ; +44 couvre aussi plusieurs dépendances ; +262 est utilisé par La Réunion et Mayotte. Dans ce cas, le lookup conserve plusieurs résultats et laisse la page canonique expliquer les chiffres nécessaires pour aller plus loin.
Pour analyser un numéro complet, commencez par supprimer uniquement les séparateurs visuels, puis recherchez le préfixe international le plus long connu. Ne déduisez jamais une identité ou une localisation exacte du seul numéro affiché : la portabilité, la VoIP et l’usurpation de l’identifiant d’appel restent possibles.
Erreurs et intégration
Un code absent produit une réponse introuvable ; l’application cliente doit gérer ce cas sans choisir le pays « le plus probable ». Pour un grand nombre de requêtes, chargez plutôt l’export JSON complet et mettez-le en cache. Vérifiez également la méthode de mise à jour.
Limites et erreurs du lookup
Le lookup identifie un code documenté, une zone ou un service. Il ne valide pas un numéro complet, ne calcule pas son tarif et ne permet pas d’identifier son titulaire.
Une réponse vide reste vide ; une réponse partagée conserve toutes les destinations et l’URL canonique d’explication.
Pour une validation de longueur ou une conversion, utilisez les champs de l’export pays ou le point d’accès de formatage. Le lookup répond à une question d’attribution ; il ne remplace pas ces contrôles.
Réponse minimale exploitable
{
"query": "212",
"canonical": "https://www.indicatifs.com/indicatif/212/",
"results": ["plusieurs destinations possibles"]
}Le client doit suivre l’URL canonique pour afficher l’explication et ne doit pas réduire le tableau à sa première ligne.
Pays, codes partagés et zones +1
code=33 renvoie la France. code=212 renvoie la page partagée entre le Maroc et le Sahara occidental. code=1-212 ouvre la zone de Manhattan, tandis que code=1-284 précise les Îles Vierges britanniques.
| Pays ou service | Code E.164 simple, par exemple 33 ou 800. |
| Destination du plan +1 | Code composite 1 suivi de la zone, par exemple 1284. |
| Numéro complet | Normaliser puis rechercher le code et la zone les plus longs documentés. |
Une absence de résultat ne doit jamais être remplacée par la première destination partageant le même code.
Cache, version et reproductibilité
Une application qui met les réponses en cache doit enregistrer la clé demandée, l’URL canonique, la version du jeu et la date de contrôle. Ainsi, un passage d’un code partagé à une zone documentée peut être expliqué sans modifier silencieusement un historique.
Testez au minimum 212, 1-212, 1-284, 800 et un code absent. Le premier doit rester partagé, les deux suivants doivent préciser une zone, le quatrième doit rester un service international et le dernier doit produire une absence explicite.
La même recherche est disponible pour un utilisateur sur le moteur d’identification. Pour traiter le numéro après résolution du pays, consultez la méthode de formatage.
Sources complémentaires : Métadonnées techniques libphonenumber. Ces références sont utilisées selon leur périmètre respectif.
Référence officielle : liste officielle UIT des indicatifs E.164, pour l’attribution des codes internationaux. Consultation éditoriale : 26 août 2026.
Traiter une réponse ambiguë sans inventer
Le client doit distinguer trois états : résultat unique, plusieurs destinations possibles et absence de correspondance. Une liste de plusieurs résultats n’est pas une erreur technique ; elle signifie que le code demandé n’est pas assez précis.
- Conserver la valeur réellement saisie, y compris le séparateur d’une zone +1.
- Afficher toutes les correspondances renvoyées, sans les classer comme probabilités.
- Proposer l’URL canonique pour lire les règles propres au code.
- Demander davantage de chiffres lorsque le plan le permet, puis relancer le lookup.
Pour les journaux applicatifs, stockez aussi la version des données. Vous pourrez ainsi expliquer pourquoi un résultat a changé après une nouvelle attribution officielle.
Normalisez les variantes 1-212, +1 212 et 001 212 vers une même clé seulement après avoir préservé la saisie brute. Cette trace permet de distinguer une erreur utilisateur d’une erreur de résolution.