Si votre application mobile s’appuie sur Amazon Pinpoint pour le push et les messages in-app, une échéance ferme approche et la migration s’annonce compliquée. Le 30 octobre 2026, AWS met fin au support d’Amazon Pinpoint. Passé cette date, la console et tout ce que vous avez construit dedans — endpoints, segments, campagnes, journeys et analytics — devient inaccessible.
Pinpoint avait déjà cessé d’accepter de nouvelles inscriptions le 20 mai 2025 — le service est donc en sursis depuis un moment. AWS détaille le calendrier complet dans son guide officiel de fin de support.
L’arrêt en lui-même est simple à comprendre. Ce qui l’est moins, c’est vers où AWS vous redirige : il n’existe aucun produit de remplacement unique. Selon l’usage que vous faisiez de Pinpoint, votre charge se répartit sur 4 services AWS différents. Et pour les 2 canaux qui comptent le plus pour la majorité des équipes mobiles — le push et l’in-app — le chemin recommandé ne reprend pas les choses à l’identique.
Dans ce guide : ce qui s’arrête, où AWS oriente chaque brique et pourquoi ce n’est pas un remplacement à l’identique, un plan en 4 étapes pour transférer votre programme push et in-app vers Pushwoosh. Avec des chiffres réels, pour budgéter le changement sans mauvaise surprise.
Ce qui s’arrête vraiment
Les API des canaux de messagerie ne disparaissent pas. Ce qui disparaît, c’est la couche d’engagement, celle où vos équipes marketing et produit se connectaient au quotidien.
Après le 30 octobre 2026, vous perdez l’accès à vos ressources Pinpoint : les endpoints (vos fiches utilisateurs et appareils), les segments (audiences dynamiques), les campagnes (envois planifiés), les journeys (le builder d’automatisation multi-étapes) et les tableaux de bord analytics qui suivaient la délivrabilité, les ouvertures et l’engagement dans les journeys.
Ce qui survit, sous un autre nom, c’est la couche brute des canaux. SMS, voix, push mobile, OTP et validation de numéro de téléphone continuent de fonctionner via AWS End User Messaging, le nom qu’AWS a donné aux API de canaux de Pinpoint dès le T3 2024. Si vous n’avez jamais utilisé Pinpoint que comme un simple tuyau — votre propre backend porte la logique et appelle l’API pour déclencher un push ou un SMS transactionnel — vous avez peu de souci à vous faire. Vous repointez vos appels API et c’est réglé.
Mais si votre équipe a construit ses audiences, ses campagnes et ses journeys directement dans l’interface Pinpoint, c’est ce workflow-là qui casse. Le reconstruire dans AWS est là où le vrai travail commence.
Vers quoi AWS vous redirige, et pourquoi ce n’est pas un remplacement direct
Le guide de migration d’AWS ne propose pas un remplacement, mais 4, un par capacité :
- Engagement (endpoints, segments, campagnes, journeys) → Amazon Connect outbound campaigns + Customer Profiles
- Événements et analytics mobile → Amazon Kinesis
- E-mail → Amazon SES (Simple Email Service)
- SMS, push, voix, OTP → AWS End User Messaging
Un seul fournisseur, techniquement. Mais désormais 4 produits distincts, 4 consoles et 4 jeux de documentation pour remplacer le système unique que vous aviez. Pour une équipe sans cellule dédiée de platform engineering, c’est une charge bien plus lourde que ce que «migrer vers un nouvel outil» laisse d’ordinaire supposer.
Et pour les équipes mobiles, c’est justement cette destination «engagement» qui complique les choses. Amazon Connect présente des lacunes faciles à manquer tant qu’on n’est pas déjà en pleine migration.
- La messagerie in-app n’existe tout simplement pas dans Connect. AWS le précise noir sur blanc : la documentation de migration la liste parmi les fonctionnalités indisponibles. Si l’onboarding in-app, les prompts fonctionnalité ou les paywalls font partie du fonctionnement de votre application, il n’existe aucun foyer natif pour eux sur le chemin recommandé.
- Le push n’est pas un canal de campagne natif. Le push (GCM, APNS, Baidu et le reste) n’est pas pris en charge nativement dans les campagnes Connect. Le guide AWS indique que l’envoi reste possible, mais uniquement via un journey, avec une action Lambda branchée sur des templates push Connect. En pratique, cela signifie écrire et maintenir du code rien que pour reproduire ce que Pinpoint faisait nativement.
- Le Custom Channel n’est que partiellement disponible. Il existe dans les journeys mais pas dans les campagnes — une couture de plus dans une stack mobile que Connect vous laisse rapiécer vous-même.
- Les templates partagent un moteur, pas la syntaxe. Les templates Connect utilisent le même moteur de rendu Handlebars que Pinpoint, donc votre logique se transpose. Les placeholders d’attributs, eux, s’écrivent différemment : ce qui s’écrivait
{{User.UserAttributes.PurchaseHistory}}dans Pinpoint devient{{Attributes.Customer.Attributes.PurchaseHistory}}dans Connect. Chaque template doit être récupéré et réécrit à la main. - Migrer les endpoints est un travail de script. Pour transférer vos utilisateurs, AWS vous fait exporter un segment sans filtre vers S3, puis exécuter un script Python pour reformater ces endpoints en Customer Profiles, où un profil unique plafonne à 3 adresses e-mail et 4 numéros de téléphone. Ça fonctionne. C’est aussi du code que vous écrivez, testez et maintenez.
Rien de tout cela ne rend le chemin AWS mauvais en soi. Si vous êtes déjà pleinement investi dans Connect pour vos cas d’usage centre de contact, il peut être exactement adapté. Mais si le push et l’in-app sont la raison pour laquelle vous étiez sur Pinpoint au départ, la migration recommandée confie ces 2 canaux directement à vos développeurs, à charge pour eux de les reconstruire. C’est ce qu’il vaut mieux savoir avant de démarrer, pas 3 sprints plus tard.
Migrer votre programme push et in-app vers Pushwoosh en 4 étapes
Pushwoosh est une plateforme d’engagement client pensée mobile-first : le push, l’in-app et le web push sont les canaux principaux, avec l’e-mail et le SMS en complément. Plutôt que de répartir votre programme sur 4 services AWS, vous le reconstruisez une seule fois, au même endroit. Voici comment se déroule la migration.
-
Exportez vos données Pinpoint
Récupérez vos endpoints, segments, campagnes et définitions de journeys via les API d'AWS pendant que la console est encore active. Attendre l'approche de l'échéance ne fait que compliquer la récupération, et cet export vous servira quelle que soit la destination choisie — faites-le tôt.
-
Repointez vos SDK mobiles
Remplacez le SDK Pinpoint ou Amplify par le SDK Pushwoosh, puis vérifiez que les appareils s'enregistrent et que les événements remontent avant de basculer quoi que ce soit côté utilisateur. C'est l'étape qui reconnecte votre application à un backend de messagerie actif.
-
Reconstruisez segments et journeys
Importez vos utilisateurs, faites correspondre vos attributs Pinpoint au modèle de tags et de segmentation de Pushwoosh, et recréez vos automatisations dans le builder de journeys visuel. C'est un travail à l'identique : vous réimplémentez une logique déjà connue plutôt que de partir d'une page blanche. C'est exactement la brique qui, sur le chemin Connect, atterrirait sur le bureau de vos développeurs.
-
Reconnectez les événements, puis pilotez
Rebranchez vos événements personnalisés pour que les déclencheurs comportementaux fonctionnent, lancez un envoi pilote sur un petit segment pour vérifier la parité, et ne basculez le volume complet qu'ensuite. Gardez du temps calendaire réel pour l'authentification de domaine et l'enregistrement d'expéditeur : rien de tout cela n'accélère parce que l'échéance approche.
La différence avec la voie AWS se voit dans les détails les plus ingrats. Là où le guide AWS vous fait écrire et exécuter un script Python pour reformater vos endpoints en Customer Profiles, Pushwoosh importe vos utilisateurs via l’interface ou l’API, sans script à écrire ni maintenir. Là où Connect vous demande de router le push via un journey adossé à une Lambda, le push n’est qu’un canal que vous sélectionnez. L’ingénierie que vous auriez dû budgéter côté AWS s’évapore presque entièrement.
Combien ça coûte
La tarification est le point que la plupart des guides de migration laissent volontairement flou — la voici en clair. Pushwoosh facture au nombre d’utilisateurs actifs mensuels (MAU) — voir le détail complet des tarifs — et pour un usage push et in-app, le point d’entrée est délibérément bas :
- Push Only — 7 $ pour 1 000 MAU. Si le push et l’in-app constituent tout votre programme, c’est le palier qui vous correspond, sans surcoût omnicanal dont vous ne vous serviriez pas.
- Omnicanal — 13 $ pour 1 000 MAU. Ajoute l’e-mail, le SMS et le reste du mix de canaux quand vous voulez tout regrouper sous un même toit.
- Sur mesure — à partir de 2 000 $/mois. Tarification au volume, support dédié et conditions entreprise pour les gros volumes d’envoi.
Pour une équipe qui a surtout besoin de remplacer le push et l’in-app de Pinpoint, ces 7 $ d’entrée de gamme représentent bien moins de friction que de s’engager sur une suite de marketing automation complète — exactement l’arbitrage que vous impose la tranche tarifaire de Braze, Customer.io ou Iterable.
Une échéance qui tombe en pleine préparation du Black Friday
Le 30 octobre 2026 arrive à peu près 4 semaines avant le Black Friday et le Cyber Monday, en plein cœur de la période où les équipes e-commerce françaises calibrent leurs campagnes de fin d’année. Migrer votre programme push et in-app dans la panique fin octobre, au moment même où vous devriez calibrer vos scénarios de relance de panier pour les soldes, est le pire scénario possible. Les équipes qui exportent leurs données dès maintenant arrivent à novembre avec un programme déjà stabilisé plutôt qu’un chantier en cours.
N’attendez pas octobre
La migration elle-même est un exercice connu : exporter, repointer, reconstruire, tester. C’est le calendrier qui est la contrainte dure. Le 30 octobre 2026 est une échéance fixe, et les étapes qui consomment du temps calendaire réel (bascule SDK, mapping des événements, configuration de domaine et d’expéditeur) avancent à leur propre rythme, quelle que soit la proximité de la date.
Vous pouvez démarrer avec vos données réelles sur un palier gratuit de 1 000 MAU, suffisant pour importer un vrai segment, reconstruire un journey et lancer un envoi pilote afin de constater la parité par vous-même avant de vous engager sur une bascule complète. Notre conseil, après avoir vu suffisamment de ces migrations traîner en longueur : calibrez-la dès maintenant sur vos MAU réels et votre calendrier, pendant que la console Pinpoint est encore là pour exporter. Les équipes qui remettent ça à septembre sont celles qui découvrent les manques 3 semaines avant l’extinction.
