Quitter OneSignal ? 9 outils pour migrer un SDK push en toute sécurité dans une grande application

Dans une petite application, une migration du SDK OneSignal consiste à remplacer 1 appel d’initialisation et un gestionnaire de clic. Dans une grande application, OneSignal est présent à des dizaines d’endroits : des tags définis dans le module profil, un external user ID dans l’authentification, des gestionnaires de clic dans la navigation, des déclencheurs in-app quelque part dans le tunnel de commande.

Oubliez 1 seul de ces appels et rien ne plante. Les segments dérivent sans bruit, les deep links ouvrent l’écran d’accueil, et la notification push qui faisait revenir les utilisateurs n’arrive plus.

Ce guide présente 9 outils qui sécurisent la migration du SDK push, regroupés selon les 5 étapes d’une migration : cartographier, remplacer, tester, déployer et surveiller.

Pour la partie fournisseur, consultez notre guide complet de migration de OneSignal vers Pushwoosh.

Pourquoi les migrations de SDK push échouent dans les grandes applications

Un SDK push touche une plus grande partie du code que la plupart des bibliothèques tierces. 4 choses tournent généralement mal :

• Des appels dispersés. Tags, external user IDs et gestionnaires de clic vivent dans des modules différents, parfois dans des dépôts différents. Une recherche textuelle sur «OneSignal» trouve les appels évidents et passe à côté des wrappers.
• Des dépendances cachées. Événements analytics, deep links et tests A/B reposent souvent sur des callbacks du SDK. Supprimez le callback, et un tableau de bord en aval tombe à plat.
• 2 SDK, 1 build. 2 SDK push dans 1 même app se disputent les mêmes callbacks de notification. C’est pourquoi le guide de migration Pushwoosh recommande de retirer le SDK OneSignal dans la même version que celle qui ajoute le nouveau.
• Des échecs silencieux. Une notification push non délivrée ne déclenche aucune erreur. Les rapports de crash restent propres.

Le processus de migration, étape par étape

Chaque étape a son propre mode d’échec et ses propres outils.

9 outils pour une migration du SDK OneSignal en toute sécurité

Étape 1. Cartographier chaque appel OneSignal

1. CodeAlive : le meilleur pour cartographier les appels SDK dans les bases de code volumineuses et multi-dépôts

CodeAlive fournit aux agents IA de développement un contexte précis sur l’ensemble de la base de code et réduit les tokens qu’ils dépensent à le chercher. C’est un moteur de contexte conçu pour les bases de code de plus de 1 million de lignes : recherche sémantique et graphe de relations entre fichiers, symboles, appels, dépendances et tests, exposés via MCP et API.

Son rôle dans la migration : avant que quiconque ne modifie le code, vous demandez à CodeAlive où OneSignal est utilisé et ce qui en dépend. Le graphe de relations fait apparaître les appels au-delà des évidents : wrappers, callbacks sur lesquels reposent les analytics, tests qui simulent le SDK. Le même contexte est transmis à l’agent IA qui effectue le remplacement.

Fonctionnalités clés :

• Recherche hybride : recherche sémantique, correspondance lexicale et parcours de graphe en 1 seule requête
• Index mis à jour à chaque push, pour que la cartographie reste à jour pendant que la branche de migration évolue
• Outils MCP, dont semantic_search, grep_search et chat, pour Cursor, Claude Code, Codex, Windsurf, Zed, Continue et Cline
• Revue de pull requests par IA qui tient compte de l’ensemble du système
• Fournisseurs Git : GitHub, GitLab, Bitbucket, Azure DevOps, Gitea. IDE : VS Code et JetBrains

Points forts :

Étape 2. Remplacer le SDK et transférer l’audience

2. Pushwoosh : la meilleure plateforme cible avec import d’audience

Pushwoosh est une plateforme d’engagement client avec push, in-app, e-mail, SMS et WhatsApp. Lors d’une migration, l’équipe Pushwoosh importe votre audience pendant que vos développeurs livrent le nouveau SDK. Pour les éditeurs français et européens, la plateforme est conforme au RGPD et dispose de centres de données en UE et aux États-Unis, ce qui simplifie la conversation avec votre DPO au moment de changer de fournisseur.

Son rôle dans la migration : les tokens push iOS, Android et Huawei sont importés et continuent de fonctionner, car ils appartiennent à votre app et à vos clés. Les abonnés e-mail et SMS sont également repris dans l’import. L’external_user_id est mappé sur le User ID Pushwoosh (demandez cette colonne dans votre export OneSignal, elle n’est pas dans l’export par défaut), et les tags sont recréés à partir de votre export. Le web push fait exception : aucun fournisseur ne peut transférer les abonnements navigateur, donc le Web SDK Pushwoosh réabonne les visiteurs de façon silencieuse.

Fonctionnalités clés :

• SDK pour iOS et Android, ainsi que React Native, Flutter, Unity, Capacitor, Cordova, MAUI, Expo et d’autres
• Import d’audience mené en parallèle de la sortie du SDK, pour que les appareils soient joignables avant même que les utilisateurs mettent l’app à jour
• Appareils de test pour prévisualiser les push sur un vrai appareil avant l’envoi

Points forts :

Tarifs : l’offre push-only coûte 7 $ pour 1 000 MAU, les 1 000 premiers MAU étant gratuits. Comparez avec votre facture actuelle grâce au calculateur de coûts OneSignal.

Étape 3. Tester l’enregistrement et la délivrance

3. Apple Push Notifications Console : le meilleur pour tester la délivrance iOS via APNs

La Push Notifications Console est l’outil web d’Apple pour envoyer des notifications de test via APNs. C’est un moyen rapide d’écarter le fournisseur quand une notification push iOS n’arrive pas.

Son rôle dans la migration : vous envoyez un push directement à un token d’appareil et vérifiez si APNs l’a accepté et délivré. S’il arrive par ce biais mais pas depuis votre nouveau fournisseur, vérifiez d’abord la configuration côté fournisseur.

Fonctionnalités clés :

• Notifications de test vers un appareil, avec renvoi après modification des attributs
• Logs de délivrance qui montrent le parcours d’une notification dans APNs, pour l’environnement de développement
• Validation de token pour un environnement et un type de push donnés
• Métriques de délivrance pour les notifications de test et de production

Points forts :

4. Firebase Cloud Messaging : le meilleur pour tester les push Android par token

Sur les appareils équipés des services Google Play, les push Android passent par Firebase Cloud Messaging (les appareils Huawei sans services Google utilisent HMS Push Kit). La console Firebase peut envoyer un message de test à 1 token d’enregistrement, ce qui en fait un outil simple pour tester les notifications push sur vos builds Android. Sur un marché comme la France, où iOS et Android se partagent les utilisateurs à peu près à parts égales, testez systématiquement les deux plateformes.

Son rôle dans la migration : une fois qu’un appareil est enregistré par le nouveau SDK, vous collez son token FCM dans la console et envoyez un test. S’il arrive, le token et la configuration Firebase sont corrects.

Fonctionnalités clés :

• Envoi d’un message de test à un token d’enregistrement FCM précis depuis la console
• Aucun code nécessaire pour une vérification rapide, à part la lecture du token sur l’appareil

Points forts :

5. Proxyman : le meilleur pour inspecter le trafic et les payloads du SDK

Proxyman est un proxy de débogage HTTP pour macOS, Windows et Linux. Il montre ce que le SDK push envoie réellement : appels d’enregistrement, mises à jour du user ID, requêtes de tags.

Son rôle dans la migration : vous lancez l’app avec le nouveau SDK et observez ses requêtes. Si un tag ne quitte jamais l’appareil, vous le voyez ici, bien avant qu’un segment ne ressorte vide.

Fonctionnalités clés :

• Capture du trafic HTTPS des apps sur appareils, simulateurs et émulateurs
• Capture en un clic sur le simulateur iOS et l’émulateur Android dans les offres payantes
• Breakpoints et Map Local/Remote pour modifier requêtes et réponses

Étape 4. Déployer par étapes

6. fastlane : le meilleur pour automatiser les déploiements progressifs

fastlane est une plateforme open source qui automatise le déploiement iOS et Android. Pour une migration, son intérêt tient à 2 paramètres que vous pouvez intégrer à votre lane de mise en production.

Son rôle dans la migration : upload_to_app_store accepte phased_release: true, qui déploie la mise à jour sur 7 jours. upload_to_play_store accepte une valeur rollout, la fraction d’utilisateurs qui reçoivent le build (0.1 pour 10 % ; 1 termine le déploiement). La version de migration suit ainsi le même chemin progressif à chaque fois, et personne n’oublie de cocher la case.

Fonctionnalités clés :

• deliver / upload_to_app_store avec phased_release
• supply / upload_to_play_store avec rollout et release_status (y compris halted)
• 1 seule lane pour les deux stores

Points forts :

7. Phased release de l’App Store et staged rollouts de Google Play : le meilleur pour limiter l’impact d’un mauvais build

Les deux stores permettent de livrer une mise à jour d’abord à une partie de vos utilisateurs. Quel que soit votre outillage de mise en production, c’est le filet de sécurité d’un remplacement de SDK push.

Son rôle dans la migration : le nouveau build avec Pushwoosh atteint une petite part des utilisateurs. Si les délivrances ou le taux de crash semblent anormaux, vous arrêtez le déploiement avant qu’il n’atteigne tout le monde. Pendant ce temps, OneSignal continue d’envoyer aux utilisateurs qui n’ont pas mis à jour, et personne ne manque une campagne.

Fonctionnalités clés :

• App Store : déploiement sur 7 jours à 1 %, 2 %, 5 %, 10 %, 20 %, 50 %, puis 100 % des utilisateurs ayant activé les mises à jour automatiques. Vous pouvez mettre en pause jusqu’à 30 jours au total ou publier pour tous à tout moment
• Google Play : vous fixez le pourcentage et l’augmentez manuellement. Vous pouvez interrompre puis reprendre le déploiement, et les utilisateurs déjà à jour conservent le build
• Échantillonnage aléatoire des utilisateurs sur les deux stores

Points forts :

Étape 5. Surveiller les crashs et la délivrance

8. Firebase Crashlytics : le meilleur pour détecter les crashs après le remplacement

Firebase Crashlytics remonte les crashs et les erreurs non fatales des apps Android, Apple, Flutter et Unity. Gardez-le actif pendant tout le déploiement et comparez le nouveau build au précédent.

Son rôle dans la migration : un crash dans un gestionnaire de notification ou pendant l’initialisation du SDK apparaît ici en premier. Les événements non fatals aident à repérer les problèmes plus discrets : enregistrez un non-fatal quand l’enregistrement push échoue, et vous le verrez par build.

Fonctionnalités clés :

• Rapports de crash regroupés en issues, filtrables par build
• Événements non fatals, enregistrés sur l’appareil et envoyés au lancement suivant de l’app
• SDK officiels pour Android, Apple, Flutter et Unity

9. Statistiques de messages Pushwoosh : le meilleur pour repérer les baisses de délivrance silencieuses

Les rapports de crash ne vous diront pas que les push n’arrivent plus. Les statistiques push de Pushwoosh, si.

Son rôle dans la migration : pour chaque push, vous voyez l’entonnoir de l’audience à l’envoi, aux délivrances et aux ouvertures, par plateforme, plus un onglet dédié aux erreurs. Comparez les premières campagnes après le changement avec vos chiffres OneSignal d’avant. Si les délivrances iOS sont en retrait par rapport à Android, vérifiez les identifiants avant de vérifier le code.

Un plan de migration en 5 étapes pour les grandes applications

Inventoriez chaque appel OneSignal avant de toucher au code

Listez chaque appel SDK, wrapper, callback et test, dans tous les dépôts. Cette liste devient la checklist du remplacement et de la revue de code.

Regroupez le push derrière 1 interface interne

Faites passer chaque appel push par un service interne unique : login, logout, tags, gestion des notifications. La migration modifie alors 1 implémentation au lieu de 50 points d’appel, et le prochain changement de fournisseur devient lui aussi plus simple.

protocol PushService {
    func login(userId: String)
    func setTags(_ tags: [String: Any])
    func handleNotificationOpen(_ payload: [AnyHashable: Any])
}

Remplacez les SDK dans 1 seule version

Ajoutez le SDK Pushwoosh et retirez le SDK OneSignal dans le même build. 2 SDK push dans 1 même app se disputent les callbacks de notification. Pendant le déploiement du nouveau build, continuez d’envoyer depuis OneSignal aux utilisateurs restés sur l’ancienne version.

Déployez par étapes et comparez les métriques de délivrance

Commencez par une petite part des utilisateurs via le phased release ou le staged rollout. Surveillez les crashs dans Crashlytics et les délivrances dans les statistiques Pushwoosh, puis élargissez le déploiement.

N’arrêtez les envois OneSignal qu’une fois la délivrance vérifiée

Tant que vous n’avez pas arrêté les envois depuis OneSignal, revenir en arrière signifie simplement continuer à envoyer depuis OneSignal. Coupez-le une fois la délivrance Pushwoosh et l’import d’audience confirmés.

FAQ