Migrer un numéro WhatsApp vers un BSP : runbook et retour arrière

Réponse courte

Réponse courte : une migration de numéro se prépare comme un changement critique : propriété, accès, dépendances, templates, webhooks, support, recette et plan de retour doivent être écrits avant la bascule.

La migration d’un numéro se pilote comme une continuité de service : chaque dépendance doit avoir un propriétaire, une preuve et un retour arrière clair.

La décision à prendre avant de configurer quoi que ce soit

Le document d’onboarding WhatsApp Business Platform rappelle le rôle du partenaire dans la mise en place et l’intégration. Le Developer Hub reste la référence pour les ressources techniques. Les étapes exactes dépendent du compte, du numéro et du prestataire : ce runbook organise la décision et les preuves, il ne remplace pas la procédure officielle applicable à votre configuration.

Un bon dispositif ne commence pas par le bouton d’une interface. Il commence par une décision observable : quelle donnée est autorisée, quelle action est permise, qui reprend la main, et comment l’équipe saura qu’un événement a été traité. Cette discipline évite de confondre une démonstration réussie avec une intégration exploitable en production.

1. Prouver la propriété

Avant de choisir un prestataire, identifiez l’organisation qui possède le compte, le numéro, les actifs et les accès. Un contrat commercial ne remplace pas une cartographie technique.

La fiche de propriété doit rester accessible même si le prestataire n’est plus disponible.

Contrôle concret

Pour prouver la propriété, écrivez un test avec une entrée valide, une entrée incomplète et une entrée contradictoire. Le résultat attendu doit être lisible par le métier et par la personne qui maintient l’intégration.

Exemple de terrain

Cas illustratif : l’équipe reçoit une demande liée à prouver la propriété. Elle note la source, choisit une seule règle, indique ce qui reste à confirmer et attribue la suite à un rôle nommé.

2. Inventorier les dépendances

Listez webhooks, templates, utilisateurs, CRM, numéros, sauvegardes, campagnes et procédures support.

Une migration est incomplète si l’équipe ne sait pas qui reçoit les erreurs après le changement.

Contrôle concret

Pour inventorier les dépendances, écrivez un test avec une entrée valide, une entrée incomplète et une entrée contradictoire. Le résultat attendu doit être lisible par le métier et par la personne qui maintient l’intégration.

Exemple de terrain

Cas illustratif : l’équipe reçoit une demande liée à inventorier les dépendances. Elle note la source, choisit une seule règle, indique ce qui reste à confirmer et attribue la suite à un rôle nommé.

3. Préparer une recette isolée

Testez les événements, l’envoi, la reprise et le support sur un environnement ou un périmètre contrôlé.

Un test avec des clients réels ne doit pas être le premier test.

Contrôle concret

Pour préparer une recette isolée, écrivez un test avec une entrée valide, une entrée incomplète et une entrée contradictoire. Le résultat attendu doit être lisible par le métier et par la personne qui maintient l’intégration.

Exemple de terrain

Cas illustratif : l’équipe reçoit une demande liée à préparer une recette isolée. Elle note la source, choisit une seule règle, indique ce qui reste à confirmer et attribue la suite à un rôle nommé.

4. Définir la bascule

Choisissez une fenêtre, un responsable, une communication interne et les critères d’arrêt.

Un plan de retour doit dire qui décide et quelle configuration est restaurée.

Contrôle concret

Pour définir la bascule, écrivez un test avec une entrée valide, une entrée incomplète et une entrée contradictoire. Le résultat attendu doit être lisible par le métier et par la personne qui maintient l’intégration.

Exemple de terrain

Cas illustratif : l’équipe reçoit une demande liée à définir la bascule. Elle note la source, choisit une seule règle, indique ce qui reste à confirmer et attribue la suite à un rôle nommé.

5. Vérifier la continuité

Après la bascule, testez réception, statut, template, CRM et reprise humaine.

Un seul message sortant ne prouve pas que tout le cycle fonctionne.

Contrôle concret

Pour vérifier la continuité, écrivez un test avec une entrée valide, une entrée incomplète et une entrée contradictoire. Le résultat attendu doit être lisible par le métier et par la personne qui maintient l’intégration.

Exemple de terrain

Cas illustratif : l’équipe reçoit une demande liée à vérifier la continuité. Elle note la source, choisit une seule règle, indique ce qui reste à confirmer et attribue la suite à un rôle nommé.

6. Clore proprement

Retirez les accès obsolètes, archivez les preuves et documentez les écarts.

La fin de la migration est un état vérifié, pas le moment où le prestataire dit “terminé”.

Contrôle concret

Pour clore proprement, écrivez un test avec une entrée valide, une entrée incomplète et une entrée contradictoire. Le résultat attendu doit être lisible par le métier et par la personne qui maintient l’intégration.

Exemple de terrain

Cas illustratif : l’équipe reçoit une demande liée à clore proprement. Elle note la source, choisit une seule règle, indique ce qui reste à confirmer et attribue la suite à un rôle nommé.

La méthode complète, étape par étape

La séquence ci-dessous est volontairement plus stricte qu’un simple tutoriel. Elle permet de prouver ce qui a été testé et de retrouver la cause d’un incident sans demander à une seule personne de se souvenir de toute l’histoire.

Étape 1 — Prouver la propriété

Documentez prouver la propriété dans un environnement contrôlé. Commencez par l’état initial, appliquez la règle, vérifiez la sortie et rejouez le cas après une interruption. Si le résultat diffère, ne le classez pas comme détail : recherchez quelle donnée, quelle version ou quel propriétaire a changé.

Preuve à conserver : la fiche de recette, la version de la règle et le résultat observé pour prouver la propriété.

Étape 2 — Inventorier les dépendances

Documentez inventorier les dépendances dans un environnement contrôlé. Commencez par l’état initial, appliquez la règle, vérifiez la sortie et rejouez le cas après une interruption. Si le résultat diffère, ne le classez pas comme détail : recherchez quelle donnée, quelle version ou quel propriétaire a changé.

Preuve à conserver : la fiche de recette, la version de la règle et le résultat observé pour inventorier les dépendances.

Étape 3 — Préparer une recette isolée

Documentez préparer une recette isolée dans un environnement contrôlé. Commencez par l’état initial, appliquez la règle, vérifiez la sortie et rejouez le cas après une interruption. Si le résultat diffère, ne le classez pas comme détail : recherchez quelle donnée, quelle version ou quel propriétaire a changé.

Preuve à conserver : la fiche de recette, la version de la règle et le résultat observé pour préparer une recette isolée.

Étape 4 — Définir la bascule

Documentez définir la bascule dans un environnement contrôlé. Commencez par l’état initial, appliquez la règle, vérifiez la sortie et rejouez le cas après une interruption. Si le résultat diffère, ne le classez pas comme détail : recherchez quelle donnée, quelle version ou quel propriétaire a changé.

Preuve à conserver : la fiche de recette, la version de la règle et le résultat observé pour définir la bascule.

Étape 5 — Vérifier la continuité

Documentez vérifier la continuité dans un environnement contrôlé. Commencez par l’état initial, appliquez la règle, vérifiez la sortie et rejouez le cas après une interruption. Si le résultat diffère, ne le classez pas comme détail : recherchez quelle donnée, quelle version ou quel propriétaire a changé.

Preuve à conserver : la fiche de recette, la version de la règle et le résultat observé pour vérifier la continuité.

Scénarios à jouer avant de considérer le flux fiable

Un scénario de recette décrit une entrée, une décision attendue et un effet de bord autorisé. Une capture d’écran seule ne suffit pas : notez aussi l’identifiant technique, l’heure du test, la réponse HTTP ou métier, la personne qui a validé et la correction appliquée en cas d’écart.

Scénario 1 — propriété non documentée

Entrée. un cas normal arrive dans le flux et contient uniquement les informations que le client ou le système a réellement fournies

Attendu. le système applique la règle prévue pour propriété non documentée, sans inventer la valeur manquante et sans déclencher deux fois la même action

À vérifier. la trace permet de relier l’entrée, la décision, la sortie et le responsable de la vérification.

Scénario 2 — accès administrateur

Entrée. un cas incomplet ou contradictoire arrive dans le flux et contient uniquement les informations que le client ou le système a réellement fournies

Attendu. le système applique la règle prévue pour accès administrateur, sans inventer la valeur manquante et sans déclencher deux fois la même action

À vérifier. la trace permet de relier l’entrée, la décision, la sortie et le responsable de la vérification.

Scénario 3 — template manquant

Entrée. un cas normal arrive dans le flux et contient uniquement les informations que le client ou le système a réellement fournies

Attendu. le système applique la règle prévue pour template manquant, sans inventer la valeur manquante et sans déclencher deux fois la même action

À vérifier. la trace permet de relier l’entrée, la décision, la sortie et le responsable de la vérification.

Scénario 4 — webhook à basculer

Entrée. un cas incomplet ou contradictoire arrive dans le flux et contient uniquement les informations que le client ou le système a réellement fournies

Attendu. le système applique la règle prévue pour webhook à basculer, sans inventer la valeur manquante et sans déclencher deux fois la même action

À vérifier. la trace permet de relier l’entrée, la décision, la sortie et le responsable de la vérification.

Scénario 5 — support indisponible

Entrée. un cas normal arrive dans le flux et contient uniquement les informations que le client ou le système a réellement fournies

Attendu. le système applique la règle prévue pour support indisponible, sans inventer la valeur manquante et sans déclencher deux fois la même action

À vérifier. la trace permet de relier l’entrée, la décision, la sortie et le responsable de la vérification.

Scénario 6 — retour arrière

Entrée. un cas incomplet ou contradictoire arrive dans le flux et contient uniquement les informations que le client ou le système a réellement fournies

Attendu. le système applique la règle prévue pour retour arrière, sans inventer la valeur manquante et sans déclencher deux fois la même action

À vérifier. la trace permet de relier l’entrée, la décision, la sortie et le responsable de la vérification.

Tableau de contrôle réutilisable

| Point de contrôle | Question à poser | Résultat attendu | Responsable | |---|---|---|---| | Entrée | Quelle donnée déclenche la règle ? | Entrée identifiée | Ops | | Décision | Quelle règle s’applique ? | Décision explicable | Métier | | Trace | Comment retrouver la preuve ? | Identifiant et date | Responsable | | Exception | Quand faut-il arrêter ? | Sortie documentée | Supervision | | Revue | Qui valide l’évolution ? | Version attribuée | Propriétaire |

Ce tableau doit vivre dans l’espace où l’équipe travaille réellement. Une procédure introuvable au moment d’un incident n’est pas une procédure opérationnelle. Versionnez le document, indiquez sa date de revue et rendez visible la personne qui peut l’approuver ou le corriger.

Erreurs fréquentes et corrections propres

1. Automatiser avant de définir la sortie

Décrivez d’abord le résultat attendu et le cas où l’équipe reprend.

2. Confondre donnée absente et donnée fausse

Conservez un état explicite “inconnu” ou “à confirmer”.

3. Mesurer seulement le volume

Ajoutez qualité, reprise, réouverture et erreurs.

4. Copier une règle voisine

Adaptez le contrôle à la source et à l’action propre au scénario.

Limites à expliquer honnêtement

Ce guide décrit une méthode de conception et de contrôle. Les capacités, interfaces, délais et règles de la plateforme peuvent changer. Vérifiez la documentation applicable à votre compte et ne présentez pas un test local, une réponse automatique ou une synchronisation partielle comme une garantie de continuité.

Une automatisation peut accélérer une décision répétitive ; elle ne transforme pas une donnée périmée en vérité, une autorisation ambiguë en consentement, ni une intégration non testée en garantie de continuité. Quand l’information manque, la bonne sortie est souvent une demande de précision ou une reprise humaine, pas une réponse plus affirmative.

Questions fréquentes

FAQ

Faut-il traiter tous les cas automatiquement pour que migrer un numéro whatsapp vers un bsp : runbook et retour arrière soit utile ?

Non. Un système fiable sait dire qu’il ne sait pas, demander une précision et transmettre un contexte exploitable.

Quelle donnée doit être la source de vérité ?

Celle qui est officiellement responsable de l’état dont dépend l’action. Documentez-la et prévoyez une réconciliation si elle peut être indisponible.

Comment tester sans exposer de données réelles ?

Utilisez des identifiants fictifs, minimisez les copies et contrôlez les journaux. Réservez les tests réels à une étape validée et observée.

Que faire lorsqu’un opérateur corrige souvent la sortie ?

Mesurez la correction, identifiez la règle qui manque et mettez à jour le scénario. Ne masquez pas l’écart en supprimant la trace.

Un outil peut-il garantir la conformité ?

Non. Il peut appliquer des contrôles ; l’organisation reste responsable du cadre, des données, des accès et de la décision.

Quand demander un cadrage humain ?

Dès qu’une décision engage le client, l’entreprise, un droit d’accès, une promesse de disponibilité ou une donnée incertaine.

Annexe opérationnelle — de la propriété du numéro au plan de retour

[object Object]

Table de bascule d’un numéro vers un BSP

Observation 1

Dans ce scénario, prenez un inventaire de numéro, un basculement de webhook ou une anomalie de réception et traitez-le comme étape de migration. Avant toute automatisation, vérifiez l’état avant bascule, le contact propriétaire et le point de retour. Le résultat attendu n’est pas un écran rassurant : il doit permettre à le pilote de migration de relire le choix sans interpréter les intentions de quelqu’un d’autre. Testez aussi un cas où la donnée arrive en retard ou se contredit. Le risque concret à éviter est une conversation sans routage connu au moment de la bascule. Lorsque la preuve ne suffit pas, la conduite prévue est de arrêter la transition et appliquer le scénario de retour. Conservez alors le journal de bascule et le procès-verbal de recette; cette pièce relie le test, le propriétaire et la décision qui a réellement été prise.

Décision 2

Dans ce scénario, prenez un inventaire de numéro, un basculement de webhook ou une anomalie de réception et traitez-le comme étape de migration. Avant toute automatisation, vérifiez l’état avant bascule, le contact propriétaire et le point de retour. Le résultat attendu n’est pas un écran rassurant : il doit permettre à le pilote de migration de relire le choix sans interpréter les intentions de quelqu’un d’autre. Testez aussi un cas où la donnée arrive en retard ou se contredit. Le risque concret à éviter est une conversation sans routage connu au moment de la bascule. Lorsque la preuve ne suffit pas, la conduite prévue est de arrêter la transition et appliquer le scénario de retour. Conservez alors le journal de bascule et le procès-verbal de recette; cette pièce relie le test, le propriétaire et la décision qui a réellement été prise.

Preuve 3

Dans ce scénario, prenez un inventaire de numéro, un basculement de webhook ou une anomalie de réception et traitez-le comme étape de migration. Avant toute automatisation, vérifiez l’état avant bascule, le contact propriétaire et le point de retour. Le résultat attendu n’est pas un écran rassurant : il doit permettre à le pilote de migration de relire le choix sans interpréter les intentions de quelqu’un d’autre. Testez aussi un cas où la donnée arrive en retard ou se contredit. Le risque concret à éviter est une conversation sans routage connu au moment de la bascule. Lorsque la preuve ne suffit pas, la conduite prévue est de arrêter la transition et appliquer le scénario de retour. Conservez alors le journal de bascule et le procès-verbal de recette; cette pièce relie le test, le propriétaire et la décision qui a réellement été prise.

Exception 4

Dans ce scénario, prenez un inventaire de numéro, un basculement de webhook ou une anomalie de réception et traitez-le comme étape de migration. Avant toute automatisation, vérifiez l’état avant bascule, le contact propriétaire et le point de retour. Le résultat attendu n’est pas un écran rassurant : il doit permettre à le pilote de migration de relire le choix sans interpréter les intentions de quelqu’un d’autre. Testez aussi un cas où la donnée arrive en retard ou se contredit. Le risque concret à éviter est une conversation sans routage connu au moment de la bascule. Lorsque la preuve ne suffit pas, la conduite prévue est de arrêter la transition et appliquer le scénario de retour. Conservez alors le journal de bascule et le procès-verbal de recette; cette pièce relie le test, le propriétaire et la décision qui a réellement été prise.

Reprise 5

Dans ce scénario, prenez un inventaire de numéro, un basculement de webhook ou une anomalie de réception et traitez-le comme étape de migration. Avant toute automatisation, vérifiez l’état avant bascule, le contact propriétaire et le point de retour. Le résultat attendu n’est pas un écran rassurant : il doit permettre à le pilote de migration de relire le choix sans interpréter les intentions de quelqu’un d’autre. Testez aussi un cas où la donnée arrive en retard ou se contredit. Le risque concret à éviter est une conversation sans routage connu au moment de la bascule. Lorsque la preuve ne suffit pas, la conduite prévue est de arrêter la transition et appliquer le scénario de retour. Conservez alors le journal de bascule et le procès-verbal de recette; cette pièce relie le test, le propriétaire et la décision qui a réellement été prise.

Revue 6

Dans ce scénario, prenez un inventaire de numéro, un basculement de webhook ou une anomalie de réception et traitez-le comme étape de migration. Avant toute automatisation, vérifiez l’état avant bascule, le contact propriétaire et le point de retour. Le résultat attendu n’est pas un écran rassurant : il doit permettre à le pilote de migration de relire le choix sans interpréter les intentions de quelqu’un d’autre. Testez aussi un cas où la donnée arrive en retard ou se contredit. Le risque concret à éviter est une conversation sans routage connu au moment de la bascule. Lorsque la preuve ne suffit pas, la conduite prévue est de arrêter la transition et appliquer le scénario de retour. Conservez alors le journal de bascule et le procès-verbal de recette; cette pièce relie le test, le propriétaire et la décision qui a réellement été prise.

Transmission 7

Dans ce scénario, prenez un inventaire de numéro, un basculement de webhook ou une anomalie de réception et traitez-le comme étape de migration. Avant toute automatisation, vérifiez l’état avant bascule, le contact propriétaire et le point de retour. Le résultat attendu n’est pas un écran rassurant : il doit permettre à le pilote de migration de relire le choix sans interpréter les intentions de quelqu’un d’autre. Testez aussi un cas où la donnée arrive en retard ou se contredit. Le risque concret à éviter est une conversation sans routage connu au moment de la bascule. Lorsque la preuve ne suffit pas, la conduite prévue est de arrêter la transition et appliquer le scénario de retour. Conservez alors le journal de bascule et le procès-verbal de recette; cette pièce relie le test, le propriétaire et la décision qui a réellement été prise.

Contradiction 8

Dans ce scénario, prenez un inventaire de numéro, un basculement de webhook ou une anomalie de réception et traitez-le comme étape de migration. Avant toute automatisation, vérifiez l’état avant bascule, le contact propriétaire et le point de retour. Le résultat attendu n’est pas un écran rassurant : il doit permettre à le pilote de migration de relire le choix sans interpréter les intentions de quelqu’un d’autre. Testez aussi un cas où la donnée arrive en retard ou se contredit. Le risque concret à éviter est une conversation sans routage connu au moment de la bascule. Lorsque la preuve ne suffit pas, la conduite prévue est de arrêter la transition et appliquer le scénario de retour. Conservez alors le journal de bascule et le procès-verbal de recette; cette pièce relie le test, le propriétaire et la décision qui a réellement été prise.

Traçabilité 9

Dans ce scénario, prenez un inventaire de numéro, un basculement de webhook ou une anomalie de réception et traitez-le comme étape de migration. Avant toute automatisation, vérifiez l’état avant bascule, le contact propriétaire et le point de retour. Le résultat attendu n’est pas un écran rassurant : il doit permettre à le pilote de migration de relire le choix sans interpréter les intentions de quelqu’un d’autre. Testez aussi un cas où la donnée arrive en retard ou se contredit. Le risque concret à éviter est une conversation sans routage connu au moment de la bascule. Lorsque la preuve ne suffit pas, la conduite prévue est de arrêter la transition et appliquer le scénario de retour. Conservez alors le journal de bascule et le procès-verbal de recette; cette pièce relie le test, le propriétaire et la décision qui a réellement été prise.

Responsabilité 10

Dans ce scénario, prenez un inventaire de numéro, un basculement de webhook ou une anomalie de réception et traitez-le comme étape de migration. Avant toute automatisation, vérifiez l’état avant bascule, le contact propriétaire et le point de retour. Le résultat attendu n’est pas un écran rassurant : il doit permettre à le pilote de migration de relire le choix sans interpréter les intentions de quelqu’un d’autre. Testez aussi un cas où la donnée arrive en retard ou se contredit. Le risque concret à éviter est une conversation sans routage connu au moment de la bascule. Lorsque la preuve ne suffit pas, la conduite prévue est de arrêter la transition et appliquer le scénario de retour. Conservez alors le journal de bascule et le procès-verbal de recette; cette pièce relie le test, le propriétaire et la décision qui a réellement été prise.

Limite 11

Dans ce scénario, prenez un inventaire de numéro, un basculement de webhook ou une anomalie de réception et traitez-le comme étape de migration. Avant toute automatisation, vérifiez l’état avant bascule, le contact propriétaire et le point de retour. Le résultat attendu n’est pas un écran rassurant : il doit permettre à le pilote de migration de relire le choix sans interpréter les intentions de quelqu’un d’autre. Testez aussi un cas où la donnée arrive en retard ou se contredit. Le risque concret à éviter est une conversation sans routage connu au moment de la bascule. Lorsque la preuve ne suffit pas, la conduite prévue est de arrêter la transition et appliquer le scénario de retour. Conservez alors le journal de bascule et le procès-verbal de recette; cette pièce relie le test, le propriétaire et la décision qui a réellement été prise.

Clôture 12

Dans ce scénario, prenez un inventaire de numéro, un basculement de webhook ou une anomalie de réception et traitez-le comme étape de migration. Avant toute automatisation, vérifiez l’état avant bascule, le contact propriétaire et le point de retour. Le résultat attendu n’est pas un écran rassurant : il doit permettre à le pilote de migration de relire le choix sans interpréter les intentions de quelqu’un d’autre. Testez aussi un cas où la donnée arrive en retard ou se contredit. Le risque concret à éviter est une conversation sans routage connu au moment de la bascule. Lorsque la preuve ne suffit pas, la conduite prévue est de arrêter la transition et appliquer le scénario de retour. Conservez alors le journal de bascule et le procès-verbal de recette; cette pièce relie le test, le propriétaire et la décision qui a réellement été prise.

Pour aller plus loin sur agentic-whatsup.com

Pour le niveau supérieur, consultez Guide général WhatsApp Business, Supervision humaine agent IA WhatsApp. Ces pages n’ont pas le même rôle : l’une traite le cadre général, l’autre approfondit une intégration ou un contrôle voisin.

Si votre équipe veut vérifier le flux sur son cas réel, utilisez le contact de cadrage et décrivez le canal, la source de données, le propriétaire de la reprise et le test qui échoue. La demande porte sur le cadrage du processus ; aucun résultat de classement, de délivrabilité ou de conversion ne doit être promis avant mesure.

Sources vérifiées

WhatsApp Developer Hub · Meta Business Messaging Policy · Meta — guide d’onboarding WhatsApp

Les sources ci-dessus établissent les règles ou les capacités documentées. Les matrices, exemples, critères de décision et contrôles proposés dans cet article sont une méthode éditoriale adaptée au cas d’usage ; ils ne constituent pas une certification de la plateforme ni un avis juridique.