Comment vérifier qu’un numéro de téléphone est toujours attribué à la même personne grâce à l’API Lookup de Twilio

April 08, 2026
Rédigé par
Révisé par

En 2026, les fonctionnalités de l’API que nous allons découvrir dans ce tutoriel sont réservées aux États-Unis. Vous aimeriez pouvoir les utiliser dans d’autres pays ? N’hésitez pas à nous contacter pour nous faire part de vos besoins.

Aux États-Unis, la loi Telephone Consumer Protection Act (TCPA), encadre notamment les communications téléphoniques à caractère commercial et impose, dans les situations concernées, d’obtenir le consentement des personnes avant de les contacter. Pour respecter cette réglementation, il est donc essentiel de vous assurer que vous disposez bien des autorisations nécessaires pour joindre les destinataires de vos communications. Mais que se passe-t-il lorsqu’un numéro de téléphone change de titulaire ? C’est précisément l’une des difficultés auxquelles les entreprises peuvent être confrontées, avec un risque de non-conformité au TCPA. Imaginez qu’un client vous ait autorisé à le contacter, mais que son numéro de téléphone ait depuis été réattribué à une autre personne. Vous disposez toujours du consentement initial, mais celui-ci ne vous autorise pas pour autant à contacter le nouveau titulaire du numéro.

C’est là qu’intervient l’API Lookup de Twilio. En vous permettant de vérifier si un numéro de téléphone a été réattribué depuis l’obtention du consentement, elle vous aide à vous assurer que vos communications parviennent aux bons destinataires. Vous pouvez ainsi améliorer vos taux de contact, gagner en efficacité dans vos campagnes marketing et réduire les risques d’amendes liés au non-respect de la réglementation. Cette fonctionnalité s’avère particulièrement précieuse pour les entreprises qui souhaitent envoyer des notifications marketing tout en veillant à contacter les bons destinataires.

Comment tirer parti de l’API Lookup de Twilio pour vérifier si un numéro de téléphone a été réattribué

Avant de commencer à utiliser l’API Lookup, assurez-vous de disposer des éléments suivants :

  1. Un compte Twilio, que vous pouvez créer dès aujourd’hui si vous n’en possédez pas encore.
  2. Vos identifiants de test Twilio, retrouvez-les sur la page des jetons d'authentification de la Console.
  3. Si vous souhaitez ensuite exploiter cette fonctionnalité dans un environnement de production, une étape supplémentaire sera nécessaire : vous devrez demander l’autorisation d’accéder au package de données Reassigned Number. Cette procédure prend généralement entre deux et quatre jours ouvrés. Remarque : les les identifiants de test permettent néanmoins d’utiliser immédiatement l’API dans un environnement de développement, sans attendre cette autorisation.

Dans ce tutoriel, nous allons donc utiliser ces identifiants pour interroger l’API Lookup et obtenir une réponse prédéfinie et reproductible permettant de simuler la réattribution d’un numéro de téléphone.

En plus du numéro de téléphone concerné, chaque requête adressée à l’API doit comporter deux paramètres :

  1. Fields : reassigned_number. L’API Lookup propose plusieurs packages de données, dont la sélection s’effectue au moyen du paramètre Fields. Consultez les autres packages de données disponibles.
  2. LastVerifiedDate. Ce paramètre doit être renseigné au format AAAMMJJ. Il correspond à la date à laquelle le consentement de l’utilisateur final a été recueilli, à la date du dernier contact établi avec celui-ci ou à la date de sa dernière mise à jour du numéro de téléphone enregistré dans votre application.

Après avoir obtenu vos identifiants d’authentification de test, remplacez les valeurs d’identification fournies dans l’exemple de requête ci-dessous par vos propres identifiants. Pour connaître les modalités d’exécution de cette même requête avec Node.js, Python ou d’autres langages de programmation, reportez-vous à la documentation correspondante..

curl -X GET "https://lookups.twilio.com/v2/PhoneNumbers/12345678904?Fields=reassigned_number&LastVerifiedDate=20211227" \
-u $TWILIO_TEST_ACCOUNT_SID:$TWILIO_TEST_AUTH_TOKEN

La réponse renvoyée par l’API indique que le numéro de téléphone concerné a fait l’objet d’une réattribution. Elle peut également contenir plusieurs autres champs, notamment sim_swap ou line_type_intelligence, dont les valeurs peuvent être définies sur null. En effet, l’API Lookup permet de solliciter simultanément plusieurs packages de données en les spécifiant dans le paramètre Fields. Indépendamment des packages de données demandés, l’API Lookup renvoie par défaut des informations relatives à la mise en forme et à la validation du numéro de téléphone.

{
 …
 // other data packages
 … 
 "reassigned_number": {
    "last_verified_date": "2021-12-27",
    "is_number_reassigned": "yes",
    "error_code": null
  },
  ...
}

Un point important à retenir : contrairement à ce que son nom pourrait laisser penser, le champ is_number_reassigned ne renvoie pas simplement une valeur booléenne indiquant si un numéro a été réattribué ou non. Il peut en réalité retourner trois réponses différentes, chacune ayant une signification particulière :

  1. yes (oui). le numéro a changé de titulaire depuis la dernière date de vérification. Vous ne devez donc pas considérer le consentement initial comme toujours valable. Il vous faudra trouver un autre moyen de joindre la personne concernée pour lui demander de confirmer son numéro de téléphone et d’autoriser à nouveau vos communications.
  2. no (non). Le numéro de téléphone est toujours attribué à la même personne. Si vous disposez également d’une preuve du consentement précédemment recueilli, cette réponse peut vous permettre de bénéficier d’une protection juridique particulière, appelée safe harbor, face à certains risques d’infraction au TCPA.
  3. no_data_available (aucune donnée disponible). L’API ne dispose pas des données nécessaires pour vous fournir une réponse concluante. Cette situation se présente généralement lorsque la date indiquée dans LastVerifiedDate est antérieure à janvier 2021. Il est alors préférable de demander à nouveau le consentement de votre destinataire avant de poursuivre vos communications.

Vous souhaitez explorer les différents résultats que peut renvoyer l’API ? Essayez d’autres numéros prédéfinis pour les tests, appelés Magic Numbers, afin de vous familiariser avec les réponses possibles..

Comprendre la base de données de la FCC et la protection juridique associée au safe harbor

Pour effectuer ses vérifications, Twilio s’appuie sur la base de données officielle de la Federal Communications Commission (FCC), l’organisme fédéral américain chargé de la réglementation des communications. Cette base est mise à jour chaque mois, le 16, afin de tenir compte des informations relatives à la réattribution des numéros. Pour les clients qui doivent vérifier si un numéro de téléphone a été réattribué plus d’une fois par mois, nous recommandons d’actualiser leur base de données le 17 de chaque mois. Les informations obtenues à cette date resteront valables jusqu’à la prochaine mise à jour de la base officielle, le 16 du mois suivant. Si un problème survient au niveau de cette base de données, la FCC précise que les entreprises à l’origine des appels peuvent, sous certaines conditions, bénéficier d’une protection juridique contre une éventuelle mise en cause de leur responsabilité, à condition de disposer des justificatifs nécessaires.

La règle du délai obligatoire de 45 jours avant réattribution

Afin de pallier les éventuels décalages dans la transmission des informations relatives aux résiliations, la FCC a instauré un délai minimal obligatoire de 45 jours avant toute réattribution. Les fournisseurs de services de télécommunications ne peuvent ainsi attribuer à un nouvel utilisateur un numéro définitivement désactivé avant l’expiration de cette période.

Les opérateurs étant tenus de déclarer les déconnexions définitives au plus tard le 15 de chaque mois, ce délai de 45 jours constitue une marge de sécurité pour les entreprises procédant à des vérifications avant de contacter les titulaires de numéros. Le mécanisme peut être illustré comme suit :

  • Jour 1 : un abonné procède à la résiliation de sa ligne.

  • Jour 15 : l’opérateur transmet les informations relatives à cette résiliation à la FCC.

  • Jour 16 : la base de données officielle fait l’objet d’une actualisation.

  • À compter du 45e jour : le numéro peut légalement être réattribué à un nouvel abonné, distinct de la personne initialement visée par les communications.

Régime de protection juridique (safe harbor)

Une réponse négative obtenue auprès de l’API Lookup, dans le cadre de la vérification des numéros réattribués, peut contribuer à établir le respect des obligations applicables au titre du TCPA et à justifier l’application du régime de protection juridique (safe harbor) défini par la FCC. Elle constitue notamment un élément de preuve relatif aux conditions 2 et 3 détaillées ci-après.

Pour bénéficier de l'exonération de responsabilité prévue par le dispositif de protection juridique du TCPA, la personne ou l’entité à l’origine de l’appel doit être en mesure d’établir les trois éléments suivants : (1) Elle a préalablement obtenu le consentement du destinataire auquel l’appel était destiné. ; (2) Avant d’effectuer l’appel, elle-même ou son mandataire dûment habilité a interrogé la base de données officielle afin de vérifier que le numéro concerné n’avait pas fait l’objet d’une déconnexion définitive ou d’une réattribution postérieure à la date d’obtention du consentement. ; (3) 1. La consultation de la base de données a donné lieu à une réponse négative (no) qui s’est avérée erronée.

La Federal Communications Commission (FCC) reconnaît qu’aucune base de données ne peut refléter les changements de situation en temps réel. Le dispositif de protection juridique Safe Harbor vise donc à protéger les entreprises qui ont fait preuve de la diligence nécessaire en consultant la source officielle avant de contacter un destinataire. Notez toutefois que vous restez tenu de pouvoir prouver que la personne que vous souhaitiez appeler avait bien donné son consentement.

Identification et résolution des codes d’erreur courants

Lorsque l’API rencontre une erreur, le code correspondant apparaît dans le champ reassigned_number. La réponse HTTP peut néanmoins afficher un code d’état 200, car une même requête peut porter sur plusieurs packages de données Lookup, dont certains peuvent avoir été traités avec succès malgré l’échec d’un autre.

{
 ...
 "reassigned_number": {
    "error_code": 60606,
    "last_verified_date": null,
    "is_number_reassigned": null,
  },
  ...
}

Voici quatre erreurs courantes que vous pourriez rencontrer :

Mise en production de la fonctionnalité de détection des numéros réattribués

Pour vos campagnes marketing, le respect de la réglementation est indispensable. En vérifiant que les numéros de téléphone de vos destinataires n’ont pas été réattribués, vous pouvez limiter les risques d’amendes et renforcer la fiabilité de vos communications. Notez que Twilio ne gère pas de liste d’opposition au démarchage téléphonique. Nous vous recommandons donc d’utiliser la fonctionnalité de détection des numéros réattribués de l’API Lookup conjointement avec le registre national américain d’opposition au démarchage téléphonique (National Do Not Call List), afin de mieux déterminer les personnes que vous êtes autorisé à contacter parmi vos utilisateurs. Avant de procéder au déploiement de votre application dans un environnement de production, veillez à disposer des autorisations requises auprès des opérateurs de télécommunications. Vous pourrez ensuite effectuer vos requêtes en utilisant vos clés API de production en remplacement des identifiants d’authentification de test.

Maintenant que votre application est capable de détecter les numéros réattribués, vous pouvez découvrir d’autres possibilités offertes par l’API Lookup grâce aux exemples de Code Exchange. Essayez notamment Line Type Intelligence pour repérer les numéros VoIP, ou exploitez la détection des changements de carte SIM (SIM swapped) pour vérifier un numéro avant d’envoyer un code d’authentification à deux facteurs (2FA) par SMS. Vous pourrez ensuite intégrer l’Verify API afin de vérifier que l’utilisateur dispose effectivement du numéro de téléphone indiqué et de mener à bien l’ensemble du processus de vérification de son identité. Il ne vous reste plus qu’à passer à la pratique, j’ai hâte de voir ce que vous allez imaginer, développer et sécuriser !