Migration d'un panneau SMS : du SaaS à l'auto-hébergé, pas à pas

Quitter un panneau SMS loué est un projet dont la forme est connue. Les points qui tournent mal sont toujours les mêmes : un sender ID enregistré au nom de l’éditeur, un nom d’hôte d’API que vos clients ont écrit en dur, un grand livre qui ne s’exporte pas, une bascule faite un vendredi. Voici la liste de contrôle de migration de panneau SMS que nous appliquons lorsque nous faisons passer un revendeur sur sa propre plateforme, rédigée pour que vous puissiez la suivre avec n’importe quelle plateforme auto-hébergée. Elle couvre le passage d’un panneau SaaS à l’auto-hébergé en sept étapes : l’inventaire, les exports, la nouvelle plateforme, les éléments qui ne voyagent pas, le fonctionnement en parallèle, la bascule et la fermeture de l’ancien panneau. Le comparatif des panneaux SaaS répond à la question de savoir s’il faut partir ; ce guide explique comment.

Étape 0 : caler le calendrier sur l’élément le plus lent

Avant de toucher aux données, dressez la liste de tout ce qui avance au rythme de quelqu’un d’autre : les réenregistrements de sender ID et de numéros courts au nom de votre propre société, les identités réglementaires (DLT en Inde, 10DLC aux États-Unis, et leurs équivalents), les approbations des opérateurs pour vos propres binds SMPP et, si vous ajoutez WhatsApp, la vérification d’entreprise de Meta. Chacune de ces démarches prend des semaines, pas des jours, et aucune ne peut être lancée trop tôt. Lancez-les toutes dès la première semaine, en parallèle de tout ce qui suit, et c’est le reste de la migration qui finira par les attendre, plutôt que l’inverse.

Étape 1 : l’inventaire de migration du panneau SMS

Notez, depuis la console d’administration du panneau, une ligne par élément :

• Clients : chaque compte, son mode de facturation (crédit prépayé, portefeuille, postpayé), son solde actuel, son plan tarifaire, son interlocuteur, et son mode d’intégration : console, API HTTP ou bind SMPP.
• Plans tarifaires et routes : chaque plan de prix, chaque ligne de destination, chaque route fournisseur avec ses identifiants et son coût.
• Sender ID et numéros : identifiants alphanumériques, numéros longs, numéros courts, et au nom de quelle entité chacun est enregistré auprès de chaque opérateur.
• Intégrations : chaque nom d’hôte que vos clients appellent (API, URL du panneau, points de terminaison webhook sur lesquels ils reçoivent les accusés), et s’il se trouve sur votre domaine ou sur celui de l’éditeur.
• Volumes de données : contacts, modèles, historique des campagnes, journaux de livraison, factures, mois par mois.
• Contrats : le préavis du panneau, et chaque contrat client qui mentionne le nom ou l’URL du panneau.

Cet inventaire est le plan de migration. Tout ce qui suit, c’est cet inventaire avec des dates.

Étape 2 : obtenir de vrais exports tant que vous êtes encore client

Demandez les exports maintenant, avant de donner votre préavis, car la réponse est plus aimable tant que vous payez. Demandez chaque élément de l’inventaire dans un format lisible par une machine (le CSV convient) et ouvrez chaque fichier : comparez le nombre de lignes avec la console, vérifiez que les preuves de consentement accompagnent bien les contacts, vérifiez que les journaux de livraison portent l’identifiant du message et le statut final, et pas seulement un total. « Nous prenons en charge l’export CSV » et « le fichier contient ce dont mes clients auraient besoin » sont deux phrases différentes.

Attendez-vous à ce que le grand livre soit la chose la moins portable de tout le système : les soldes et l’historique des factures s’exportent souvent en PDF, ou pas du tout. Dans ce cas, reconstituez les soldes à partir de vos propres registres (les factures que vous avez émises, les paiements que vous avez reçus, l’écran de solde actuel du panneau sur une capture datée) et convenez par écrit du solde d’ouverture avec chaque client au moment de la bascule. C’est un courriel d’une ligne par client, et il prévient tous les litiges que vous auriez sinon.

Étape 3 : mettre en place la nouvelle plateforme sur votre propre domaine

Installez la plateforme sur votre propre serveur, sur votre propre domaine, avant qu’un seul client ne bouge. Deux règles du guide comparatif s’appliquent à partir de ce jour : le panneau et l’API vivent sur des noms d’hôte qui vous appartiennent (panel.votresociete.com, api.votresociete.com), et les sender ID et les identités réglementaires sont enregistrés au nom de votre société partout où le régulateur le permet. Ensuite :

1. Raccordez vos propres contrats opérateurs comme routes fournisseurs, et testez chacune avec de vrais téléphones dans chaque destination avant que le moindre trafic client ne l’emprunte.
2. Reconstruisez les plans tarifaires à partir de l’export, par destination et par niveau de client, et placez un plancher de marge sous chaque ligne (le guide de la facturation explique les trois modes de facturation et pourquoi le mode est choisi à la création du compte puis verrouillé : décidez-le donc maintenant).
3. Créez les comptes clients avec le bon mode de facturation, le bon plan tarifaire, les bons sender ID et les bons contacts, mais avec l’envoi désactivé et les soldes à zéro jusqu’à la bascule.
4. Importez les contacts, les preuves de consentement et les modèles. Un conseil que nous donnons à chaque acheteur : importez les preuves d’opt-in en même temps que les contacts, pour être conforme dès le premier jour au lieu de reconstruire les consentements plus tard.
5. Importez l’historique si vous le pouvez. L’historique des campagnes et les journaux de livraison valent la peine d’être transférés pour que les clients conservent leurs rapports ; sur Smppcube, c’est toute la différence entre l’Import standard (contacts, modèles, configuration des expéditeurs et des routes) et la Migration complète (tout cela, plus l’historique d’envois, les campagnes et les données de facturation) sur la page tarifs.
6. Configurez le serveur SMPP pour les clients qui se connectent en bind, avec des identifiants par compte, des plafonds de débit et des allowlists d’IP prêts à être remis ; sur Smppcube, le serveur SMPP et l’API HTTP font partie de la plateforme et ne sont pas une option supplémentaire.

Étape 4 : les éléments qui ne voyagent pas

Quatre éléments demandent leur propre plan, car aucun export ne les transporte.

Le nom d’hôte de l’API. Si vos clients appellent api.editeur.com, soit leur code doit changer, soit quelque chose doit répondre à la même interface. La meilleure option est une couche de compatibilité sur votre plateforme, qui accepte l’ancien format de requête et le fait correspondre à la nouvelle API, afin que l’intégration d’un client continue de fonctionner le jour où son trafic bascule ; il pourra ensuite migrer vers votre API native à son propre rythme. Si l’ancien nom d’hôte appartient à l’éditeur, vous ne pouvez pas l’emporter : la couche de compatibilité vit donc sur votre nom d’hôte, et chaque client modifie une seule ligne, celle de l’hôte.

Les webhooks. Les clients qui reçoivent leurs accusés de réception par webhook l’ont configuré sur l’ancien panneau. Recueillez dès maintenant l’URL de réception de chaque client et configurez-la sur la nouvelle plateforme avant la bascule, pour que le premier message qu’il envoie par votre intermédiaire produise un accusé là où il l’attend.

Sender ID, numéros courts, identités réglementaires. Réenregistrez-les au nom de votre société, opérateur par opérateur, pays par pays. Là où l’éditeur les détient et refuse de les libérer, le sender ID du client peut changer : c’est une conversation à avoir tôt et en toute franchise, avec la date à partir de laquelle ses messages porteront le nouveau.

Les binds SMPP. Chaque client connecté en bind a besoin d’un nouvel hôte, d’un nouveau port, d’un system_id, d’un mot de passe, d’IP autorisées et d’un plafond de débit, ainsi que d’une fenêtre de test sur votre route de test avant que son trafic réel ne bascule. Envoyez le dossier d’identifiants en un seul document et planifiez un test de 30 minutes avec son ingénieur.

La migration échoue sur les éléments que personne n’a exportés, pas sur ceux que tout le monde a exportés. Noms d’hôte, webhooks, sender ID et binds forment le plan ; les fichiers CSV sont la partie facile.

Étape 5 : le fonctionnement en parallèle

Gardez l’ancien panneau actif et payé pendant 60 à 90 jours après que la nouvelle plateforme est prête. Déplacez d’abord un client bienveillant à faible volume, idéalement quelqu’un qui vous dira la vérité. Son trafic passe par votre plateforme, vos routes, votre grand livre ; l’ancien panneau reste en solution de repli. Rapprochez chaque jour les messages envoyés, les accusés appariés et les mouvements de solde avec ce que voit le client. Quand une semaine passe sans rien à expliquer, déplacez le client suivant, puis le suivant. Déplacez le plus gros client en dernier, une fois que les petits ont permis de trouver tous les problèmes ordinaires.

Pendant cette période, trois contrôles figurent sur la liste quotidienne : la latence des accusés par route (un bind opérateur plus lent sur votre plateforme que sur le panneau relève généralement d’un réglage de fenêtre ou de throttling), la marge par client face au prix combiné de l’ancien panneau (c’est là que vous voyez disparaître la taxe sur la marge), et les tickets de support par catégorie (un pic de « où est mon accusé » désigne un webhook, pas une route).

Étape 6 : la bascule, client par client

Pour chaque client, la bascule est une liste de contrôle datée : solde convenu par écrit, sender ID actifs au nom de votre société, intégration testée (couche de compatibilité API ou nouveaux identifiants, webhook qui reçoit les accusés, bind SMPP testé sur la route de test), envoi activé, première campagne suivie de bout en bout, compte sur l’ancien panneau passé en réception seule ou désactivé. Faites-le un mardi matin, avec l’interlocuteur du client joignable, jamais un vendredi.

La communication représente l’essentiel du travail. Une courte note à chaque client un mois avant (« nous passons sur notre propre plateforme, voici ce qui change pour vous, voici ce qui ne change pas »), un rappel une semaine avant avec sa date précise, et une confirmation le jour même. Les clients partent à cause des surprises, pas à cause des changements.

Étape 7 : fermer correctement l’ancien panneau

Quand le dernier client a été déplacé et que le fonctionnement en parallèle est resté calme pendant un mois : faites un dernier export complet, conservez-le dans vos archives avec la date, révoquez chaque clé API et chaque intégration que détenait le panneau, retirez les IP du panneau des allowlists de vos opérateurs, donnez votre préavis conformément au contrat, et faites confirmer par écrit que vos données ont été supprimées de leurs systèmes. Fermez ensuite le compte. Le double paiement s’arrête ici et, à partir de maintenant, chaque mois, les frais de plateforme qui augmentaient avec votre trafic deviennent de la marge dans votre propre grand livre.

Ce que cela coûte, et ce que cela vaut

Budgétez la migration honnêtement : de deux à six semaines de calendrier, l’essentiel passé à attendre les opérateurs, plus 60 à 90 jours de double paiement, plus ce que la nouvelle plateforme facture pour l’import. Aux volumes où partir a du sens, ce total est inférieur à un ou deux mois des frais de plateforme au message que vous laissez derrière vous et, contrairement à ces frais, il se paie une seule fois. Sur Smppcube, la migration des utilisateurs, des routes, des grilles tarifaires et des soldes est une étape cadrée et standard du déploiement, et les options Import standard et Migration complète sont tarifées sur la page tarifs plutôt que de faire l’objet d’un devis surprise. Quelle que soit la plateforme choisie, les règles qui rendent la sortie bon marché sont les deux mêmes que vous auriez dû appliquer dès votre premier jour : votre domaine, vos enregistrements.