Migration BSP WhatsApp : le playbook complet sans downtime

Changer de BSP (Business Solution Provider) WhatsApp est une opération à haut risque : votre numéro business, vos templates approuvés, votre historique conversationnel et votre note qualité sont en jeu. Une migration ratée peut signifier des jours sans messagerie, des templates à refaire approuver, ou pire, un numéro perdu. Ce playbook complet, applicable au marché marocain, détaille chaque étape pour une migration sereine et sans downtime.

Pourquoi migrer de BSP

Les raisons légitimes de changer de BSP sont nombreuses :

• Tarifs : le BSP actuel facture 30 à 60 % au-dessus du marché.
• Support : temps de réponse trop long, pas d'interlocuteur francophone au Maroc.
• Fonctionnalités manquantes : absence de chatbot IA, pas de SMS fallback, pas de connecteur CRM natif.
• Stabilité technique : incidents fréquents, API instable, dashboard obsolète.
• Facturation opaque : factures illisibles, catégorisation des messages incorrecte.

Ce que Meta permet réellement

La migration technique s'appelle chez Meta le BSP Change Request. Elle permet de transférer votre numéro WhatsApp Business, votre WABA (WhatsApp Business Account), vos templates approuvés et votre historique qualité vers un nouveau BSP, sans changer votre numéro visible client. Meta impose des règles précises pour éviter les abus.

Étape 1 : audit préalable du BSP actuel

Avant de bouger, documenter précisément :

• Numéro(s) actif(s) et statut de vérification.
• Liste exhaustive des templates avec statut, langue, catégorie.
• Volumétrie mensuelle par catégorie.
• Note qualité actuelle (Green, Yellow, Red).
• Tier de messagerie (250, 1k, 10k, 100k, unlimited par jour).
• Webhooks configurés et endpoints actuels.
• Intégrations tierces (CRM, chatbot, analytics).

Étape 2 : sélection du nouveau BSP

Critères de choix à évaluer sur au moins 3 BSP concurrents :

• Statut officiel Meta Partner (indispensable).
• Présence locale au Maroc ou support francophone.
• Modèle tarifaire transparent (par message, par conversation, abonnement).
• Capacités techniques : API REST, webhooks, SDK, chatbot builder, SMS fallback.
• Références client dans votre secteur.
• SLA écrit avec pénalités.
• Politique de portabilité si vous devez repartir.

Étape 3 : dry run juridique

Vérifier le contrat actuel : préavis de résiliation (souvent 30 à 90 jours), engagement de volume résiduel, frais de sortie, clause de non-portabilité éventuelle. Documenter par écrit toute demande au BSP actuel.

Étape 4 : préparation du nouveau BSP

Créer le compte, valider l'entreprise (RC, patente, pièce d'identité du dirigeant), configurer les rôles utilisateurs. Cette étape prend en moyenne 3 à 7 jours.

Étape 5 : demander l'accès au Business Manager par le nouveau BSP

Dans votre Meta Business Manager, ajouter le nouveau BSP comme partenaire avec les autorisations sur votre WABA. Ne pas encore retirer le BSP actuel.

Étape 6 : réplication des templates

Le nouveau BSP doit créer les mêmes templates, avec exactement les mêmes noms, langues, catégories et variables. Meta les approuvera en général sous 24 à 48h car le contenu est identique. Vérifier que chaque template passe en statut APPROVED avant la migration.

Étape 7 : test parallèle

Pendant cette phase, envoyer une partie du trafic (par exemple 5 %) via le nouveau BSP et 95 % via l'ancien. Comparer :

• Taux de livraison.
• Temps de latence API.
• Fiabilité webhook.
• Cohérence de la facturation.

Étape 8 : préparation technique du switch

Côté application métier, préparer :

• Feature flag permettant de basculer 100 % du trafic d'un BSP à l'autre.
• Configuration double pour tokens et endpoints.
• Mise à jour des webhooks côté application pour accepter les deux formats si nécessaire.
• Plan de rollback documenté.

Étape 9 : le BSP Change Request Meta

Étape critique. Dans le Meta Business Manager, initier le transfert du numéro depuis le BSP actuel vers le nouveau. Meta envoie une notification aux deux BSP :

• Le BSP actuel doit approuver ou peut bloquer sous prétextes contractuels.
• Le nouveau BSP doit accepter.
• Validation Meta : quelques minutes à quelques heures selon la charge.

Pendant la fenêtre de transfert (généralement moins d'une heure), aucun message ne peut être envoyé. C'est le seul "downtime" réel, et il peut être planifié la nuit pour minimiser l'impact.

Étape 10 : basculement du trafic

Une fois le transfert Meta confirmé, basculer 100 % du trafic via le feature flag préparé. Surveiller en temps réel :

• Statuts sent/delivered/read/failed.
• Latence API.
• Erreurs 4xx et 5xx.
• Réception correcte des messages entrants clients.

Étape 11 : vérification post-migration

Dans les 24 à 72h suivantes :

• Contrôler que la note qualité reste stable (le transfert ne doit pas la dégrader).
• Vérifier que le tier de messagerie est maintenu (250, 1k, 10k, 100k, unlimited).
• Tester chaque template en production réelle.
• Valider la facturation du nouveau BSP.

Étape 12 : sortie propre de l'ancien BSP

Après une période d'observation de 2 à 4 semaines :

• Résilier officiellement le contrat de l'ancien BSP.
• Retirer ses permissions dans le Meta Business Manager.
• Récupérer les archives conversationnelles selon vos obligations conformité réglementaire.
• Confirmer la clôture de facturation.

Les erreurs classiques à éviter

• Migrer sans réplication de templates : downtime de plusieurs jours pour re-approbation.
• Sous-estimer le préavis contractuel : payer double pendant 60 jours par manque d'anticipation.
• Ne pas prévoir de feature flag : impossible de revenir en arrière rapidement en cas de problème.
• Migrer en pleine peak season : jamais en Black Friday, Ramadan, Aïd, rentrée scolaire.
• Ignorer les webhooks des deux BSP : perdre des messages entrants pendant la transition.

Cas particulier : perte de la note qualité

Rare mais documenté : après migration, la note qualité peut passer en YELLOW voire RED si le nouveau BSP a un profil moins établi ou si les templates sont interprétés différemment. Le retour à GREEN prend quelques jours de messagerie normale sans réclamation client. Réduire temporairement la volumétrie marketing en cas de dégradation.

Conformité conformité réglementaire pendant la migration

• Documenter la migration dans le registre des traitements.
• Informer les personnes concernées si le nouveau BSP change la localisation de l'hébergement.
• Mettre à jour la politique de confidentialité si un nouveau sous-traitant apparaît.
• Signer un nouveau contrat de sous-traitance conforme (DPA).

Coût typique d'une migration au Maroc

• Temps interne : 40 à 100 heures selon la complexité (audit, tests, coordination).
• Prestataire externe (si mobilisé) : 15 000 à 60 000 MAD.
• Frais de sortie ancien BSP : variables selon contrat.
• Setup nouveau BSP : souvent inclus ou modique.

Bénéfices attendus post-migration

Une migration bien conduite débloque typiquement :

• 10 à 30 % d'économies récurrentes sur le coût messagerie.
• Nouvelles fonctionnalités (chatbot IA, SMS fallback, CRM natif).
• Support de meilleure qualité et plus proche géographiquement.
• Reporting plus précis.

Conclusion

Migrer de BSP WhatsApp n'est pas une opération anodine mais reste parfaitement maîtrisable avec la bonne méthode. La clé est la préparation : audit exhaustif, réplication des templates, tests parallèles, feature flag, plan de rollback. Une migration bien exécutée débloque des économies substantielles et des capacités techniques nouvelles, sans impact perceptible pour vos clients finaux. Elle constitue un chantier stratégique à mener sereinement, souvent une fois tous les 2 à 4 ans, dans le cycle de vie d'une plateforme de communication mature.