Migrer d'OneSignal vers Pushwoosh

OneSignal impose désormais un plafond strict à son plan gratuit. Très bientôt, le push mobile et les messages in-app cesseront d’être gratuits au-delà de 1 000 utilisateurs actifs mensuels. Les nouveaux comptes atteignent la limite dès le 1ᵉʳ septembre 2026, les comptes existants le 1ᵉʳ octobre. Si votre application dépasse le millier d’utilisateurs actifs par mois, 3 options s’offrent à vous : rester et payer, réduire votre audience, ou migrer.

Ce qui change, et quand

Source: OneSignal

• Le plan gratuit continue de fonctionner sous 1 000 MAU. Au-delà, le push mobile et les messages in-app basculent vers un palier payant.
• Les dates : la limite s’applique aux nouveaux comptes à partir du 1ᵉʳ septembre 2026 et aux comptes existants à partir du 1ᵉʳ octobre 2026, selon la FAQ facturation d’OneSignal.
• Le seuil : moins de 1 000 MAU pour le push mobile et l’in-app. Au-delà, ces canaux cessent d’envoyer tant que vous n’êtes pas passé au plan payant.
• Ce qui ne change pas : le web push, l’e-mail et le SMS continuent de fonctionner dans les mêmes limites de plan qu’auparavant. Le changement ne concerne que le mobile.
• Les journeys sont également concernés : toute étape de journey qui envoie un push ou un message in-app ignore simplement les abonnements mobiles.
• Supprimer des abonnés n’est pas une échappatoire. Si vous supprimez des abonnements mobiles actifs au cours des 30 derniers jours, votre plan ne peut être réactivé que 30 jours après la suppression, et seulement si vous restez sous le plafond pendant toute cette période.

Comment se déroule la migration

Si vous avez décidé de migrer, voici ce qui change la façon de planifier : c’est nous qui menons la migration. Votre part du travail se limite à trois éléments : un fichier d’export, vos identifiants push, et le remplacement du SDK dans votre prochaine mise à jour de l’application. Tout le reste (nettoyer les données, faire correspondre les plateformes, recréer les tags, importer l’audience, vérifier la délivrabilité) est de notre côté.

Le changement se déroule sur deux fronts en parallèle. Un import unique transfère votre base existante, de sorte que votre audience reste joignable dès le premier jour, avant même qu’un seul utilisateur ait mis à jour l’application. Le SDK prend ensuite le relais sur chaque appareil au fur et à mesure que son propriétaire installe la nouvelle version. Les deux sont nécessaires, et aucun ne bloque l’autre.

1. Ce que nous pouvons migrer, et ce que nous ne pouvons pas

Vous n’avez pas à faire cet audit vous-même. Voici le tableau complet dès le départ, pour qu’aucune surprise ne survienne en cours de migration.

Combien de temps cela prend

Le remplacement du SDK et un envoi de test propre représentent une journée de travail pour un développeur. L’import se déroule en parallèle de notre côté, et c’est lui qui préserve votre portée dès le premier jour : les appareils importés sont joignables avant même qu’un utilisateur ait mis à jour l’application. L’audience de votre application bascule ensuite sur le SDK Pushwoosh au rythme où vos utilisateurs installent la nouvelle version, ce qui prend plusieurs semaines et n’atteint jamais tout à fait chaque appareil. C’est précisément pour cela que l’import existe.

L’ordre compte :

1. Exportez votre audience. Envoyez-nous votre app_id OneSignal et un App API key, et nous récupérons l’export nous-mêmes, ou exportez le CSV vous-même. Détails ci-dessous.
2. Envoyez-nous vos identifiants push. Les mêmes clés qu’OneSignal utilise déjà pour envoyer. Nous les téléversons avant l’import, afin que chaque appareil importé soit joignable.
3. Remplacez le SDK. Retirez le SDK OneSignal, ajoutez le SDK Pushwoosh, initialisez-le avec votre code d’application Pushwoosh et votre token API d’appareil. Les étapes par plateforme sont détaillées dans les versions A à C.
4. Vérifiez la délivrabilité. Enregistrez un appareil de test et envoyez-vous un push avant de toucher au trafic de production.
5. Validez la feuille de tags. Nous la construisons à partir de votre export ; vous barrez les tags inutilisés et signalez ceux à valeurs multiples. Nous importons et recréons vos segments.
6. Basculez l’envoi. Une fois la délivrabilité de test propre et l’import confirmé, redirigez vos campagnes vers Pushwoosh et arrêtez d’envoyer depuis OneSignal.

2. Exportez votre audience

Option A (recommandée) : nous nous en chargeons. Envoyez-nous votre app_id OneSignal et un App API key, et nous récupérons l’export nous-mêmes. Votre part s’arrête là.

Option B : vous le faites vous-même. Dans OneSignal, allez dans Audience > Subscriptions et exportez le CSV, ou appelez le endpoint d’export :

curl -X POST 'https://api.onesignal.com/players/csv_export?app_id=YOUR_APP_ID' \
  -H 'Authorization: Key YOUR_APP_API_KEY' \
  -H 'Content-Type: application/json' \
  -d '{"extra_fields":["external_user_id","timezone_id","notification_types"]}'

La réponse renvoie csv_file_url, un CSV compressé en gzip qui reste téléchargeable pendant trois jours.

Source: OneSignal

Ces colonnes doivent être présentes dans le fichier. Tout le reste est facultatif, nous l’ignorons.

Remarque : external_user_id et timezone_id ne font pas partie de l’export par défaut. Demandez-les explicitement via le paramètre extra_fields ci-dessus, ou le sélecteur de colonnes du tableau de bord.

3. Envoyez-nous vos identifiants push

Ce sont les mêmes identifiants qu’OneSignal utilise déjà pour envoyer en votre nom, donc rien de nouveau à créer. Nous ne pouvons pas les récupérer nous-mêmes depuis OneSignal : une clé téléversée n’est plus jamais téléchargeable, cette étape vous revient donc.

Nous téléversons les identifiants sur votre application Pushwoosh avant le démarrage de l’import. Cet ordre compte : un import sans identifiants produit une base pleine d’appareils auxquels rien ne peut être livré.

4. Passez en revue vos tags et segments

Source: OneSignal

Les tags sont migrés, et vous n’avez pas à en faire l’inventaire vous-même. Dans OneSignal, un tag est une simple chaîne clé/valeur sans type déclaré. Dans Pushwoosh, chaque tag est déclaré une fois par application avec un type (String, Integer, Boolean, Date, List ou Price), et ce n’est qu’ensuite qu’il porte des valeurs.

Dès que nous avons votre export, nous vous envoyons une feuille de révision des tags construite à partir du fichier lui-même. Elle liste chaque tag trouvé, avec les données déjà remplies : valeurs d’exemple, nombre d’appareils portant une valeur, et le type que nous proposons. Votre part se limite à deux colonnes : barrer les tags que vous n’utilisez plus, et signaler ceux qui peuvent porter plusieurs valeurs à la fois. Tout le reste est une proposition que vous pouvez approuver telle quelle.

Pourquoi nous demandons plutôt que de deviner : le type d’un tag est figé une fois créé, donc un tag à valeurs multiples que nous créerions en simple String devrait être supprimé et réimporté. Un tag qui semble n’avoir qu’une seule valeur dans l’export est exactement le cas que nous ne pouvons pas détecter à partir des données. Si nous n’obtenons pas de réponse, nous importons chaque tag avec le type que nous avons déduit, et nous vous indiquons ceux sur lesquels nous avons dû deviner.

Les segments sont reconstruits. L’API d’OneSignal peut filtrer un export par segment et lister les noms de vos segments, mais elle ne renvoie pas les filtres qui les définissent : il n’y a donc rien à importer. Deux options s’offrent à vous :

1. Reconstruire les conditions (recommandé). Envoyez-nous la liste de vos segments avec leurs filtres ; des captures d’écran suffisent. Nous les recréons à partir des tags importés. Les segments reconstruits sont dynamiques : ils continuent de se mettre à jour au fil des évolutions de votre audience.
2. Figer l’appartenance. Nous prenons un export par segment et marquons chaque fichier avec un tag repère, par exemple os_segment = vip_users. Rapide, mais le résultat est un instantané qui ne se met pas à jour automatiquement.

Les segments construits sur les données comportementales propres à OneSignal (nombre de sessions, temps de jeu, «Active Users», «Engaged Users») ne peuvent pas être reproduits au moment de l’import, car cet historique reste dans OneSignal. Leurs équivalents Pushwoosh commencent à se remplir dès que notre SDK est déployé dans votre application.

5. Ce que nous faisons de notre côté

1. Créer et configurer votre application Pushwoosh, et téléverser les identifiants de l’étape 3.
2. Nettoyer l’export : supprimer les lignes désabonnées et celles au token vide, faire correspondre les codes de plateforme OneSignal aux nôtres, convertir les tags, et faire correspondre votre external_user_id à notre User ID.
3. Créer le schéma de tags, puis importer l’audience par lots, en vérifiant chaque lot.
4. Envoyer un push de test à un petit groupe témoin et comparer le résultat à ce qui est attendu.
5. Vous faire un retour : combien d’abonnements étaient dans le fichier, combien ont été importés, et la raison de chaque ligne ignorée.

6. Déployez le SDK Pushwoosh dans votre prochaine mise à jour

L’import rend votre audience existante joignable immédiatement, mais c’est un pont, pas la destination finale. Seul le SDK Pushwoosh intégré à votre application peut récupérer un nouveau token quand l’OS le renouvelle (réinstallation, restauration, mise à jour de l’OS), enregistrer les utilisateurs qui installent l’application après la migration, et rapporter les ouvertures, messages in-app et désinstallations.

Retirez le SDK OneSignal dans la même mise à jour. Deux SDK push dans un même build entrent en concurrence sur les mêmes callbacks de notification, et nous ne testons pas cette combinaison. Garder OneSignal actif pour l’envoi pendant le déploiement de la nouvelle version est normal et attendu ; garder les deux SDK dans un même build ne l’est pas. Les étapes par plateforme sont détaillées dans les versions A à C ci-dessous.

7. Web push : comment vos abonnés reviennent

Le web push ne s’importe pas, et c’est une limite technique stricte, pas un choix de Pushwoosh. Un abonnement web push est signé avec la paire de clés VAPID de celui qui l’a créé, et la clé privée d’OneSignal ne quitte jamais OneSignal — leur propre documentation indique que les clés d’abonnement web sont réservées aux SDK OneSignal. Aucun fournisseur ne peut importer les abonnements web d’un autre fournisseur. Ce qui fonctionne à la place, c’est le réabonnement silencieux :

1. Retirez le snippet OneSignal et désenregistrez explicitement son service worker. Laisser l’ancien worker en place fait entrer en concurrence deux workers sur le même domaine.
2. Installez le SDK Pushwoosh Web Push, avec notre service worker à la racine de votre domaine.
3. Initialisez-le avec votre code d’application et votre token API d’appareil (apiToken), puis activez l’abonnement automatique (autoSubscribe: true, ou appelez Pushwoosh.subscribe()). Sans le token, les appels du SDK renvoient une erreur 401.

Un visiteur qui revient est alors réabonné silencieusement. La permission de notification stockée par le navigateur appartient à votre domaine, pas à votre ancien fournisseur, donc aucune seconde invite n’apparaît et l’utilisateur ne remarque rien. La rapidité avec laquelle votre base se rétablit dépend de la rapidité avec laquelle les visiteurs reviennent : la majorité de l’audience revient généralement en une semaine, avec une traîne s’étalant sur le mois suivant.

Trois cas à garder en tête :

• Les visiteurs ayant bloqué les notifications ne peuvent pas être réabonnés. Le navigateur refuse et ne les sollicitera plus. Ils restent en dehors, ce qui est le résultat correct.
• Les visiteurs qui se sont désabonnés sur votre site tout en gardant la permission navigateur accordée seraient réabonnés silencieusement. Techniquement valide, mais cela ramène des personnes qui sont parties délibérément. Si vous disposez d’une liste de suppression (par votre propre user id ou par e-mail), envoyez-la-nous et nous excluons ces utilisateurs de chaque campagne. Si ce n’est pas le cas, nous recommandons un abonnement sur clic explicite (une cloche ou une invite) plutôt qu’automatique.
• Si votre web push fonctionnait sur un sous-domaine fourni par votre ancien prestataire plutôt que sur votre propre domaine, la permission appartient à ce sous-domaine. Ces abonnés ne peuvent pas être récupérés et doivent se réinscrire sur votre site. Vérifiez quelle configuration vous utilisez avant de planifier le changement.

8. À quoi s’attendre après l’import

• Un appareil peut apparaître en double pendant un moment. L’enregistrement importé porte l’identifiant OneSignal ; une fois que notre SDK tourne sur le même appareil, il s’enregistre avec son propre identifiant. L’enregistrement obsolète est supprimé par le suivi des désinstallations ou le nettoyage automatique après 90 jours d’inactivité. Fournir external_user_id maintient les deux enregistrements sous un seul profil utilisateur entre-temps.
• Les tokens morts disparaissent dès votre première campagne. Apple et Google ne révèlent qu’un token est invalide qu’au moment où un message est effectivement envoyé, donc le premier envoi après la migration nettoie aussi votre base.
• Votre nombre importé sera inférieur à votre compteur OneSignal. Les lignes désabonnées, celles au token vide et les lignes web push sont exclues par conception. Notre rapport vous indique exactement combien sont tombées dans chaque catégorie.

9. Où cliquer

Les chemins exacts pour les éléments qui vous reviennent, pour que personne n’ait à fouiller dans les tableaux de bord.

Checklist avant le 1ᵉʳ octobre

Gardez cette liste ouverte au fil de votre avancée. Rien ici ne nécessite de formulaire à télécharger.

Version A : iOS et Android natifs

iOS. Ajoutez le SDK iOS Pushwoosh, puis définissez deux clés dans Info.plist : Pushwoosh_APPID avec votre code d’application Pushwoosh, et PW_API_TOKEN avec votre token API d’appareil. Appelez registerForPushNotifications() là où vous déclenchez actuellement l’invite OneSignal, et suivez le quick start iOS pour le snippet d’initialisation exact selon votre version de SDK. Retirez le SDK OneSignal et son appel d’enregistrement, pour que les deux ne demandent pas de tokens en même temps.

Android. Ajoutez la dépendance com.pushwoosh:pushwoosh-firebase, puis ajoutez deux entrées meta-data dans la balise <application> de AndroidManifest.xml : com.pushwoosh.appid avec votre code d’application, et com.pushwoosh.apitoken avec votre token API d’appareil. Appelez Pushwoosh.getInstance().registerForPushNotifications() dans votre logique d’initialisation. Votre configuration Firebase reste inchangée, avec google-services.json dans le projet ; les identifiants FCM se renseignent dans le Control Panel, dans la configuration de votre plateforme Android.

Définissez vos tags avec setTags() et votre identifiant utilisateur avec setUserId() aux mêmes endroits où vous appeliez les équivalents OneSignal, afin que la segmentation continue de fonctionner après le remplacement.

Version B : Flutter et FlutterFlow

FlutterFlow encapsule le SDK Flutter Pushwoosh, donc la migration relève surtout de la configuration plutôt que du code.

1. Ajoutez le package Flutter Pushwoosh comme dépendance personnalisée dans votre projet.
2. Dans une custom action, initialisez le SDK avec votre code d’application et enregistrez-vous pour les notifications push, en suivant le quick start Flutter pour l’API d’initialisation actuelle.
3. Définissez les identifiants natifs comme le ferait n’importe quelle application Flutter : Pushwoosh_APPID et PW_API_TOKEN dans Info.plist pour iOS, com.pushwoosh.appid et com.pushwoosh.apitoken dans AndroidManifest.xml pour Android.
4. Retirez l’intégration OneSignal pour que les deux SDK ne s’enregistrent pas en même temps.
5. Faites correspondre les tags et l’user id avec setTags() et setUserId() dans vos custom actions.

Version C : React Native

1. Installez le plugin : npm install pushwoosh-react-native-plugin --save, puis pod install pour iOS.
2. Initialisez et enregistrez dans votre composant racine :

import Pushwoosh from 'pushwoosh-react-native-plugin';

Pushwoosh.init({ pw_appid: "YOUR_APPLICATION_CODE" });
Pushwoosh.register();

3. Ajoutez le token API d’appareil nativement : PW_API_TOKEN dans Info.plist pour iOS, com.pushwoosh.apitoken en meta-data dans AndroidManifest.xml pour Android. Sur Android, gardez google-services.json dans le projet — les identifiants FCM eux-mêmes se trouvent dans le Control Panel.
4. Retirez le package React Native OneSignal et son appel d’initialisation.
5. Transférez vos tags et votre user id avec setTags() et setUserId() depuis l’API du plugin.

FAQ

Pour toute question, contactez votre interlocuteur onboarding chez Pushwoosh. Nous préférons répondre avant l’import plutôt que faire coïncider les chiffres après coup.