L’idée reçue veut qu’il faille passer par un revendeur — un BSP — pour accéder à l’API WhatsApp. C’est faux. Meta laisse n’importe quelle entreprise s’inscrire en direct, gratuitement, et envoyer son premier message en quelques minutes via un numéro de test. Ce tutoriel vous mène de zéro jusqu’au premier message envoyé, puis jusqu’à un numéro de production avec un jeton permanent — sans intermédiaire, en gardant le contrôle total.
C’est le premier satellite du cluster WhatsApp Cloud API en 2026, qui pose l’architecture d’ensemble. Les étapes décrites suivent le parcours officiel de Meta for Developers.
Ce qu’il faut avant de commencer
Trois prérequis, pas un de plus. Un compte Meta (le même qu’un compte Facebook) pour accéder au tableau de bord développeur. Un numéro de téléphone dédié pour la production : il ne doit pas être déjà actif sur l’application WhatsApp ou WhatsApp Business — sinon, il faudra d’abord supprimer ce compte. Et les informations de votre entreprise (nom légal, site, secteur), qui serviront à la vérification commerciale par Meta. Pour la phase de test, en revanche, aucun numéro n’est nécessaire : Meta en fournit un.
Un mot sur le choix du numéro de production : une carte SIM neuve, un numéro virtuel ou même une ligne fixe capable de recevoir un appel font l’affaire, du moment qu’ils peuvent encaisser le code de vérification et ne sont pas déjà liés à un compte WhatsApp. Beaucoup d’entreprises dédient un numéro spécifique à leur canal API, distinct de leur standard — plus propre à gérer, et sans conflit avec un usage personnel.
Dernier conseil avant de se lancer : gardez ouverts, dans des onglets séparés, le tableau de bord Meta for Developers et le Business Manager. Le parcours fait des allers-retours entre les deux — l’un pour l’application et l’API, l’autre pour la vérification d’entreprise et l’utilisateur système — et les avoir sous la main fait gagner un temps précieux.
Étape 1 — Créer une application Meta
Tout part du tableau de bord Meta for Developers. On y crée une nouvelle application de type « Business », puis on lui ajoute le produit WhatsApp. Cette opération génère automatiquement deux choses essentielles : un WhatsApp Business Account (le WABA, qui regroupera vos numéros et vos templates) et un numéro de test prêt à l’emploi. Vous voilà avec un bac à sable fonctionnel, sans avoir fourni le moindre numéro.
Étape 2 — Le numéro de test et le jeton temporaire
Dans l’écran de configuration de l’API, Meta affiche le numéro de test, le Phone Number ID associé (l’identifiant technique qu’on placera dans l’URL des requêtes) et un jeton d’accès temporaire, valable environ 24 heures. Ce trio suffit pour tout tester.
Une contrainte du bac à sable : on ne peut écrire qu’à des numéros explicitement autorisés. On ajoute donc, dans la liste des destinataires, son propre numéro personnel — qui recevra un code de confirmation à saisir une fois.
Étape 3 — Envoyer son premier message
Tout est en place pour le moment de vérité. Avec le Phone Number ID et le jeton temporaire, une seule requête envoie un message vers votre numéro personnel :
curl -X POST 'https://graph.facebook.com/v23.0/<PHONE_NUMBER_ID>/messages' -H 'Authorization: Bearer <ACCESS_TOKEN>' -H 'Content-Type: application/json' -d '{
"messaging_product": "whatsapp",
"to": "221770000000",
"type": "template",
"template": { "name": "hello_world", "language": { "code": "en_US" } }
}'Pour ce tout premier envoi, on utilise le template pré-approuvé hello_world que Meta fournit d’office — pratique, car en dehors d’une fenêtre de conversation ouverte, seuls les templates approuvés passent (la fameuse règle des 24 heures, détaillée dans le pilier). Quelques secondes plus tard, le message arrive sur votre WhatsApp. Vous venez d’utiliser l’API en production, sans BSP, sans serveur.
Un réflexe à prendre dès ce premier envoi : la réponse de l’API ne confirme pas la remise, seulement l’acceptation de la requête. Le statut réel — remis, lu, ou en échec — vous parviendra par webhook (ou se lit, à ce stade, dans le suivi du tableau de bord). Prenez l’habitude de distinguer « l’API a accepté ma requête » de « le client a bien reçu le message » : confondre les deux est la première source de fausses certitudes en production.
À noter : le numéro destinataire (to) s’écrit au format international, indicatif compris ; ici 221 pour le Sénégal. Et la version de l’API (v23.0) évolue : adoptez la version courante de l’API Graph.
Étape 4 — Passer en production avec son vrai numéro
Le numéro de test a ses limites (destinataires restreints, plafond bas). Pour servir de vrais clients, on enregistre son propre numéro. Dans la configuration du WABA, on ajoute le numéro dédié, on choisit un nom d’affichage (le nom qui apparaîtra à vos clients, soumis à validation Meta) et on confirme la propriété du numéro par un code reçu par SMS ou appel.
S’ajoute la vérification de l’entreprise (Business Verification) dans le Business Manager : Meta demande des justificatifs d’existence légale. C’est cette vérification qui débloque les volumes d’envoi supérieurs et le plein usage de la plateforme. Comptez quelques jours pour son traitement — autant l’enclencher tôt.
Étape 5 — Un jeton permanent pour la production
Le jeton temporaire expire en 24 heures : impensable pour une application qui tourne en continu. La solution officielle passe par un utilisateur système (system user), créé dans les paramètres du Business Manager. On lui attribue les permissions WhatsApp nécessaires, puis on génère pour lui un jeton permanent — qui, lui, ne périme pas.
Ce jeton est une clé sensible : il autorise l’envoi de messages en votre nom. Il vit exclusivement côté serveur, dans une variable d’environnement ou un coffre à secrets, jamais dans un dépôt Git ni un front-end. Un jeton fuité, c’est votre numéro détourné pour du spam — et votre note de qualité ruinée.
Concrètement, l’utilisateur système a besoin de deux permissions sur votre WABA : whatsapp_business_messaging (envoyer et recevoir des messages) et whatsapp_business_management (gérer les templates, les numéros et la configuration). On lui accorde ces deux droits, et rien de plus — le principe du moindre privilège vaut ici comme ailleurs. Le jeton généré hérite de ces permissions et reste valide tant que vous ne le révoquez pas.
Étape 6 — Brancher les webhooks
Envoyer, c’est fait. Pour recevoir les messages de vos clients, il reste à déclarer une URL de webhook dans la configuration de l’application, avec un jeton de vérification que vous choisissez. C’est l’étape qui transforme un émetteur en véritable assistant conversationnel — elle a son propre tutoriel : recevoir les webhooks avec Node.js et Express.
Sécuriser le jeton dès le départ
Un jeton WhatsApp permet d’envoyer des messages au nom de votre entreprise : il se traite comme un mot de passe de production. Trois règles simples. Il vit dans une variable d’environnement ou un coffre à secrets, lu par le serveur au démarrage — jamais en dur dans le code, jamais commité. On limite ses permissions au strict nécessaire (les deux scopes WhatsApp). Et l’on prévoit sa rotation : un jeton suspecté de fuite se révoque depuis le Business Manager et se régénère, sans interruption si la lecture passe par une variable d’environnement. Ce réflexe coûte moins cher mis en place dès le premier jour qu’après le premier incident.
Le nom d’affichage et la confiance
Le nom d’affichage n’est pas cosmétique : c’est ce que voit le client quand votre message arrive. Meta impose qu’il reflète réellement votre entreprise — pas de nom trompeur, pas de mots-clés marketing déguisés. Une fois un volume et une qualité suffisants atteints, vous pouvez viser le statut de compte professionnel officiel (la pastille verte), qui renforce la confiance et donc les taux de réponse. Pour une PME qui démarche par WhatsApp, ce gage d’authenticité fait une vraie différence : on répond plus volontiers à une entreprise identifiée qu’à un numéro inconnu.
Numéro de test ou vrai numéro : quand basculer
Bonne nouvelle pour le développement : presque toute l’intégration se bâtit sur le numéro de test. Envoi de templates, réception de webhooks, logique de chatbot — tout se code et se valide dans le bac à sable, sans risquer la note de qualité d’un vrai numéro ni dépenser le moindre franc. On ne bascule sur le numéro de production qu’au moment de servir de vrais clients, une fois l’intégration éprouvée. Cette discipline — développer sur le test, ne mettre en production que le validé — évite la plupart des mauvaises surprises.
Et le coût ?
L’accès à la Cloud API est gratuit : Meta ne facture ni l’API, ni le numéro de test, ni les outils. Vous ne payez que les messages, selon des règles qui dépendent de leur catégorie et de la fenêtre d’envoi — avec, depuis juillet 2025, beaucoup de réponses de service gratuites. Le détail du modèle et son optimisation font l’objet d’un satellite dédié : maîtriser le pricing 2026.
Pourquoi se passer d’un BSP
Un BSP (Business Solution Provider) revend un accès packagé, souvent avec une interface clé en main. C’est confortable, mais cela a un coût et un prix caché : la dépendance. En vous inscrivant en direct, vous gardez le contrôle de votre WABA, de vos numéros et de vos données ; vous ne payez que les messages, au tarif Meta, sans marge intermédiaire ; et vous restez libre d’architecturer votre intégration comme vous le souhaitez.
Quand un BSP se justifie-t-il malgré tout ? Si vous voulez une interface de gestion sans rien développer, un support dédié, ou des fonctionnalités à valeur ajoutée (CRM intégré, analytics avancés). Pour une équipe technique qui sait coder une intégration — le public de ce cluster — la voie directe est presque toujours la bonne : moins chère, plus souple, sans verrou propriétaire.
Il existe une voie hybride : démarrer en direct pour apprendre et garder la main, puis déléguer plus tard certaines briques à un prestataire si le besoin émerge. Mais commencer en direct, c’est s’assurer de comprendre ce qui se passe sous le capot — et cette compréhension reste un atout même si l’outillage change par la suite.
Pièges courants
- Numéro déjà sur WhatsApp. Un numéro encore actif sur l’app WhatsApp classique sera refusé par l’API. Supprimez d’abord le compte associé, ou utilisez un numéro neuf.
- Rester sur le jeton temporaire. Mettre en production avec le jeton de 24 heures, c’est une panne garantie le lendemain. Le jeton permanent via utilisateur système est obligatoire.
- Oublier la vérification d’entreprise. Sans elle, les volumes restent bridés. On la lance tôt, car son traitement prend du temps.
- Écrire à un numéro non autorisé en test. Le bac à sable n’envoie qu’aux destinataires ajoutés à la liste blanche ; tout autre numéro échoue silencieusement.
Le parcours en une checklist
- Créer une application Meta de type Business et y ajouter le produit WhatsApp.
- Noter le Phone Number ID du numéro de test et copier le jeton temporaire.
- Ajouter son numéro personnel à la liste des destinataires autorisés.
- Envoyer le template
hello_worldet vérifier la réception. - Enregistrer son numéro de production, choisir un nom d’affichage, vérifier par SMS ou appel.
- Lancer la vérification d’entreprise dans le Business Manager.
- Créer un utilisateur système, lui accorder les deux permissions WhatsApp, générer un jeton permanent.
- Stocker ce jeton en variable d’environnement et configurer le webhook.
Cette séquence, suivie dans l’ordre, mène d’un compte vide à une intégration prête pour la production — sans jamais dépendre d’un tiers.
En résumé
- On crée une application Meta de type Business avec le produit WhatsApp ; Meta fournit un numéro de test et un jeton temporaire.
- Le premier message part en une requête
POST /messagesavec le templatehello_world, vers un numéro autorisé. - Pour la production : enregistrer son numéro dédié, choisir un nom d’affichage, vérifier l’entreprise, et générer un jeton permanent via un utilisateur système.
- La voie directe (sans BSP) donne le contrôle, le meilleur prix et la liberté d’architecture — le bon choix pour une équipe technique.
Aucun commentaire pour l'instant — lancez la discussion !