Créer un chatbot WhatsApp : préparer la connexion du numéro

Vous voulez créer un chatbot WhatsApp sans perdre des jours sur des problèmes de numéro ? La bonne nouvelle, c'est que la préparation se résume à trois décisions : quel numéro, sous quel statut de propriété, et dans quel mode WhatsApp Business. La mauvaise, c'est que ces décisions conditionnent tout ce qui suit : reconnecter un numéro mal préparé coûte souvent plus cher que de repartir proprement.

Cet article couvre uniquement la préparation de la connexion du numéro, pas la conception du dialogue ni les modèles de messages. Nous verrons les prérequis, les trois modes officiels, la différence entre authentification de transport, autorisation du fournisseur et preuve d'opération, puis un plan de recette concret. Si vous partez ensuite vers l'agent lui-même, le guide sur l'agent IA WhatsApp pour les demandes clients prend le relais sur la partie conversation.

Pourquoi la préparation du numéro décide de tout le projet

Un chatbot WhatsApp n'est pas un script posé sur un téléphone. Il repose sur une connexion entre votre numéro et une couche technique qui envoie et reçoit des messages. Si cette connexion est mal préparée, les symptômes apparaissent plus tard : messages qui partent depuis un mauvais canal, impossibilité de tester, numéro bloqué par des tentatives de reconnexion hasardeuses.

La préparation répond à trois questions distinctes. Qui détient le numéro et le statut Business associé ? Quel mode officiel utilise-t-on ? Et qui peut, à quel niveau, authentifier la connexion et prouver qu'un message a bien circulé ? Ces trois questions sont indépendantes : les confondre peut conduire à un diagnostic erroné de la connexion.

Un point de cadrage utile : la connexion de transport, l'autorisation du fournisseur et la preuve d'opération sont trois choses différentes. Le transport, c'est le tuyau entre le numéro et la plateforme. L'autorisation, c'est le droit d'utiliser ce tuyau au nom de l'entreprise. La preuve, c'est un identifiant de message ou un accusé qui atteste qu'un envoi a eu lieu. Une connexion réussie ne prouve ni l'autorisation, ni l'opération.

Prérequis côté numéro et propriétaire

Avant toute manipulation technique, rassemblez les éléments administratifs. Ils déterminent ce que vous pourrez faire sans repasser par une migration douloureuse.

• Un numéro dédié si possible. Un numéro déjà utilisé par l'application WhatsApp grand public ou par l'application WhatsApp Business pose des contraintes : il ne peut pas servir simultanément à deux usages incompatibles, et certaines migrations sont irréversibles. Un numéro dédié au chatbot évite ces conflits.
• Un propriétaire identifié. Le compte Business appartient à une entité, pas à une personne de passage. Définissez qui est administrateur, qui peut révoquer, et qui reçoit les alertes. Un numéro dont le seul détenteur est un prestataire qui disparaît est un piège classique.
• Un nom d'affichage et une catégorie cohérents. Ils seront visibles par vos clients et participent à la confiance du canal.
• Une décision sur l'historique. Conserver les conversations existantes ou repartir de zéro : ce choix influence le mode de connexion possible.

Vérifiez aussi la conformité d'usage du canal : le cadre d'utilisation de WhatsApp Business fixe des obligations sur le consentement, la qualité des messages et les usages interdits. Ce n'est pas une formalité : un numéro signalé pour messages non sollicités voit sa qualité baisser, et la qualité conditionne ce que le canal vous laissera faire ensuite. Notre article sur l'automatisation WhatsApp Business, le consentement et les modèles détaille ce volet, qui doit être pensé avant la connexion, pas après.

Les trois modes : application, Platform, coexistence

WhatsApp propose plusieurs façons de connecter un numéro, et le choix n'est pas anodin.

L'application WhatsApp Business convient aux usages manuels : une ou deux personnes répondent, éventuellement aidées de réponses rapides. Elle ne fournit pas d'interface de programmation exploitable pour un chatbot. Si votre objectif est un agent qui répond automatiquement, ce mode n'est qu'une étape transitoire.

La WhatsApp Business Platform (anciennement Cloud API) est le mode adapté à la création d'un chatbot. Le numéro devient une ressource gérée via une interface de programmation, avec authentification par identifiants, webhooks pour recevoir les messages et appels pour en envoyer. C'est ce mode qui permet d'orchestrer un agent, de journaliser les échanges et d'intégrer vos outils métier.

La coexistence est un régime particulier : dans certains cas d'éligibilité, un numéro peut rester actif sur l'application tout en étant connecté à la Platform. Ne présumez pas que vous y avez droit : l'éligibilité dépend de l'état du numéro, de l'appareil et de l'historique d'usage, et elle est vérifiée par les mécanismes officiels, pas par votre souhait. En cas de doute, partez du principe qu'un numéro dédié à la Platform est le chemin le plus simple.

Situation de départ	Mode recommandé	Pourquoi
Numéro neuf, jamais utilisé sur WhatsApp	Business Platform	Aucun conflit d'usage, connexion propre
Application Business existante, réponses manuelles uniquement	Application Business	Pas besoin d'automatisation
Application Business, automatisation souhaitée	Migration vers Platform	L'application ne permet pas de chatbot
Numéro grand public avec historique à conserver	Étudier la coexistence si éligible	Sinon migration avec perte d'historique
Plusieurs équipes, plusieurs numéros	Platform par numéro dédié	Cloisonnement des permissions et des preuves

Authentification de transport, fournisseur et permissions : trois niveaux à distinguer

C'est ici que beaucoup de projets se trompent de preuve. Distinguez trois niveaux.

L'authentification de transport établit que votre système peut dialoguer avec la plateforme : identifiants, jetons, configuration du webhook. Elle répond à la question « le tuyau fonctionne-t-il ? ».

L'autorisation du fournisseur porte sur le compte Business lui-même : qui a le droit d'administrer le numéro, d'ajouter des destinataires de webhooks, de demander des modèles de messages. C'est un contrôle d'accès au niveau du compte, distinct du jeton technique. Un jeton peut être valide alors que la personne qui l'a obtenu n'a plus les droits nécessaires.

Les permissions opérationnelles déterminent ce que votre chatbot a le droit de faire une fois connecté : répondre à un message entrant, envoyer un modèle approuvé, accéder à un outil interne. C'est le même principe que pour n'importe quel agent connecté à vos outils : notre checklist des permissions d'un agent IA propose une grille de décision qui s'applique telle quelle ici. La leçon générale vaut pour tous les connecteurs : un libellé ou une case cochée n'est pas une frontière de permission ; ce sont les contrôles applicatifs qui limitent réellement le comportement.

Concrètement, notez pour chaque niveau : qui détient les identifiants, où ils sont stockés, qui peut les renouveler, et quel journal enregistre chaque envoi. Ces notes deviendront votre plan de reprise.

Ce que le QR code prouve — et ne prouve pas

Scannez un QR code et l'application affiche « appareil connecté ». Beaucoup en concluent que leur numéro est branché sur la Business Platform. C'est faux, et cette confusion coûte cher.

Le QR code associe votre numéro à un appareil ou un client dans l'écosystème applicatif. Il prouve une session active à ce niveau-là, rien de plus. Il ne prouve pas qu'une connexion officielle à la Business Platform existe, ne fournit aucun identifiant de message exploitable par votre chatbot, et ne donne aucun webhook. Un agent « branché » uniquement via un QR code n'a ni transport fiable pour un usage automatisé, ni preuve d'opération.

La preuve d'opération côté Platform, c'est autre chose : un identifiant de message renvoyé à l'envoi, des statuts de livraison reçus en webhook, un journal d'appels. Quand un client conteste un rendez-vous ou une confirmation, c'est cet identifiant qui fait foi, pas une capture d'écran de l'application. Exigez systématiquement cette preuve dans vos tests — nous y revenons dans le plan de recette.

Même vigilance côté outils d'intégration : un catalogue d'actions disponibles dépend de l'outil utilisé et du compte connecté. Ce qui apparaît dans une liste d'outils n'est pas pour autant actif, autorisé ou testé sur votre numéro. Vérifiez toujours sur votre propre environnement.

Procédure de préparation, étape par étape

Voici une procédure de préparation que vous pouvez suivre dans l'ordre. Elle suppose que vous visez la Business Platform.

1. Inventoriez le numéro. Où est-il utilisé aujourd'hui ? Qui reçoit les SMS de vérification ? Y a-t-il des conversations à préserver ? Consignez les réponses par écrit.
2. Désignez le propriétaire et les rôles. Un administrateur de compte Business, un responsable technique, un destinataire des alertes. Trois personnes peuvent être la même, mais le rôle doit être nommé.
3. Choisissez le mode. Application, Platform, ou coexistence si l'éligibilité est confirmée par les mécanismes officiels. En cas de doute, Platform avec numéro dédié.
4. Préparez la réception des messages. Configurez un point de réception (webhook) accessible, et vérifiez qu'il répond correctement avant de connecter le numéro.
5. Connectez le numéro et authentifiez le transport. Générez les identifiants, stockez-les dans un gestionnaire de secrets, notez leur date d'expiration.
6. Vérifiez l'autorisation fournisseur. Confirmez que le compte Business affiche le bon propriétaire et que les rôles correspondent à l'étape 2.
7. Effectuez un envoi de test avec preuve. Envoyez un message, récupérez l'identifiant de message et le statut de livraison. Archivez-les.
8. Documentez la reconnexion. Écrivez la marche à suivre en cas de perte de session, et qui est autorisé à la faire.

Cette procédure ne remplace pas la documentation officielle de votre fournisseur ; elle la structure et la rend vérifiable.

Exemple principal : la clinique Santé-Plus (scénario fictif)

Prenons un cas fictif pour illustrer les décisions. La clinique Santé-Plus, deux sites, veut un chatbot WhatsApp qui confirme les rendez-vous et répond aux questions pratiques. Trois numéros existent : le numéro grand public du secrétariat, utilisé depuis des années ; un numéro de l'application WhatsApp Business installé sur le téléphone d'une assistante ; et un numéro de fax devenu inutile.

Le piège aurait été de brancher le numéro du secrétariat « vite fait » via un QR code. À la première panne du téléphone de l'assistante, le chatbot tombe, et personne ne sait rétablir la connexion. À la place, voici les décisions :

• Le numéro de fax devient le numéro dédié du chatbot : aucune conversation à préserver, aucun conflit d'usage.
• La directrice est propriétaire du compte Business ; la responsable technique détient les identifiants ; l'assistante reçoit les alertes de qualité.
• Le mode choisi est la Business Platform, avec webhook vers le système de gestion des rendez-vous.
• Chaque confirmation de rendez-vous envoie un message dont l'identifiant est enregistré dans le dossier patient interne. En cas de contestation, la clinique prouve l'envoi sans dépendre d'un téléphone.

Le point à retenir : la décision structurante n'a pas été technique mais organisationnelle — séparer le numéro du chatbot du numéro humain. Les conversations sensibles restent entre les mains du secrétariat, et l'automatisation opère sur un canal qu'on peut réinitialiser sans perturber les équipes. Pour la suite du projet — trier les demandes entrantes, escalader vers un humain — le guide sur l'organisation des demandes clients par un agent IA WhatsApp prolonge naturellement cet exemple.

Reconnexion, révocation et plan de recette

Une connexion vit : sessions expirées, changement de téléphone, rotation des identifiants, départ d'un prestataire. Préparez ces événements avant qu'ils n'arrivent.

Reconnexion. Documentez la procédure de rétablissement avec les mêmes exigences que la connexion initiale : vérification du propriétaire, authentification de transport, envoi de test avec preuve. Une reconnexion sans envoi de test n'est pas une reconnexion réussie.

Révocation. Définissez qui peut révoquer un accès, dans quel cas (départ, incident, suspicion de compromission), et comment les identifiants sont remplacés. La révocation doit pouvoir se faire sans réinstaller quoi que ce soit côté clients.

Plan de recette. Avant de dire que le chatbot est connecté, exécutez une liste de vérifications écrites :

• un message entrant déclenche bien le webhook, avec un accusé de réception de votre système ;
• un message sortant renvoie un identifiant de message exploitable ;
• un statut de livraison est reçu et journalisé ;
• la révocation d'un identifiant bloque effectivement les envois ;
• la procédure de reconnexion a été rejouée par une personne qui n'a pas écrit la documentation.

Le dernier point est le plus souvent négligé. Notre article sur le développement de chatbot, de la recette à la livraison insiste sur ce principe : une recette n'a de valeur que si elle est rejouable par quelqu'un d'autre que son auteur.

Limites, erreurs fréquentes et conduite à tenir

Trois erreurs reviennent, et chacune a une parade simple.

Confondre session et connexion. Une session active dans l'application n'est pas une connexion Platform. Conduite à tenir : n'acceptez comme preuve que des identifiants de message et des webhooks, jamais un écran de l'application. Présumer des fonctionnalités. Coexistence, flux interactifs, catalogues : toutes ne sont pas disponibles dans tous les cas. Conduite à tenir : vérifier l'éligibilité réelle de votre numéro avant de bâtir le projet dessus, et prévoir un plan B sans la fonctionnalité. Négliger la sortie du canal. Prévoyez dès le départ comment un client sort du canal automatisé : message d'un humain, désinscription, escalade. Le cadre d'usage de WhatsApp Business et les grands principes de protection des données — finalité, minimisation, droits des personnes — s'appliquent aux conversations traitées par votre agent. Ces rappels sont des repères de conception, pas des preuves de conformité : faites valider votre traitement par les personnes compétentes dans votre organisation.

Enfin, sur le coût : la tarification de la Business Platform dépend du marché et de la catégorie de message, et tous les messages ne sont pas payants de la même façon. Ne bâtissez pas un modèle économique sur un tarif entendu ici ou là ; consultez la page de tarification officielle de la plateforme et projetez vos propres volumes, y compris le scénario où les conversations entrantes réouvrent des fenêtres de service.

Si vous souhaitez cadrer la connexion de votre numéro puis construire l'agent qui va avec, vous pouvez définir une mission sur la page offres d'Edeverse.

Questions fréquentes

Puis-je utiliser mon numéro actuel de WhatsApp Business pour un chatbot ?

C'est possible dans certains cas, mais cela implique généralement une migration vers la Platform, avec des contraintes selon l'historique du numéro. La voie la plus simple reste un numéro dédié. Évaluez ce que vous perdriez si l'historique de conversations ne pouvait pas être conservé.

Le QR code suffit-il pour brancher mon chatbot ?

Non. Le QR code établit une session applicative, pas une connexion officielle à la Business Platform. Sans identifiants de message ni webhooks, votre agent n'a ni transport fiable ni preuve d'opération. Exigez ces éléments avant de considérer la connexion comme établie.

Que faire si la connexion tombe un week-end ?

C'est exactement le rôle de la documentation de reconnexion écrite à l'avance : qui intervient, avec quels accès, et quel test valide le rétablissement. Ajoutez un message de secours côté humain pour prévenir les clients pendant l'interruption.

Comment prouver qu'un message a bien été envoyé à un client ?

Par l'identifiant de message renvoyé lors de l'envoi et les statuts de livraison reçus en webhook, archivés dans votre système. Une capture d'écran de l'application ne constitue pas une preuve exploitable, car elle ne rattache pas l'envoi à votre compte Business de manière vérifiable.

Faut-il un numéro par chatbot ou peut-on mutualiser ?

Un numéro par usage automatisé est plus sûr : cloisonnement des permissions, des preuves et de la qualité d'envoi. Mutualiser un numéro entre réponses humaines et agent est possible dans certains régimes de coexistence, sous réserve d'éligibilité officielle, mais cela complique la reconnexion et l'attribution des responsabilités.