Push notifications iOS 17 : nouveaux pièges à éviter

Les notifications push, c'est le canal de réengagement le plus direct d'une app mobile, et le plus encadré par Apple. Mais ce canal n'existe que si l'utilisateur a dit oui : un push mal demandé, c'est un utilisateur perdu pour de bon. iOS 17 a durci les règles, et chacune impacte directement votre taux d'opt-in et l'engagement de l'app.

Pourquoi iOS 17 change la donne pour vos notifications#

Apple continue de durcir les conditions d'affichage des notifications, et le fait pour protéger l'utilisateur du spam. Pour une app, l'enjeu est concret : une mauvaise gestion fait chuter le taux d'opt-in, déclenche la livraison passive, et rend votre canal de réengagement invisible. Trois pièges concentrent l'essentiel du risque.

Demander la permission au bon moment#

Ce que ça change : demander la permission dès le premier lancement, avant que l'utilisateur ait vu la moindre valeur, c'est le meilleur moyen de se faire refuser. Et un refus sur iOS est quasi irréversible : il faut envoyer l'utilisateur dans les réglages système pour revenir en arrière, ce que personne ne fait. La bonne approche (le « permission ladder ») demande la permission après une première démonstration de valeur, avec un écran qui annonce ce que l'utilisateur recevra et à quelle fréquence.

// Mauvais : demander immédiatement au lancement
function App() {
  useEffect(() => {
    registerForPushNotifications() // trop tôt, valeur pas encore perçue
  }, [])
}
 
// Bon : demander après une étape d'onboarding qui montre la valeur
function OnboardingStep3() {
  const askPermission = async () => {
    await registerForPushNotifications()
  }
  return (
    <View>
      <Text>Activez les notifications pour ne rien manquer</Text>
      <Text>On vous envoie deux notifications par semaine, pas plus.</Text>
      <Button onPress={askPermission} title='Activer les notifications' />
      <Button onPress={skip} title='Plus tard' />
    </View>
  )
}

Éviter la livraison passive#

Ce que ça coûte : en mode livraison passive, vos notifications arrivent sans son, sans vibration et sans affichage en plein écran. Elles existent, mais personne ne les voit. Apple peut forcer ce mode si votre app affiche un faible taux d'interaction. Autrement dit, envoyer trop, ou au mauvais moment, finit par rendre tout votre canal silencieux.

Pour rester en livraison normale, trois règles tiennent l'essentiel :

• Pertinence : n'envoyez que des notifications réellement utiles à l'utilisateur.
• Timing : respectez les heures de sommeil et les fuseaux.
• Fréquence : restez raisonnable, quelques notifications par semaine, jamais le matraquage.

Choisir le bon niveau d'interruption#

Ce que ça change : iOS 17 laisse l'utilisateur filtrer finement les notifications via les Focus Modes. Vos messages peuvent être mis de côté sans que vous le sachiez. Le bon interruptionLevel détermine si une notification passe ou attend.

Le niveau active couvre la majorité des cas. Réservez timeSensitive aux vraies urgences : Apple peut révoquer ce niveau si vous en abusez.

await Notifications.scheduleNotificationAsync({
  content: {
    title: 'Nouveau message',
    body: content,
    // iOS 17 : passive, active, timeSensitive, critical
    interruptionLevel: 'active',
  },
  trigger: null,
})

Pour les synchronisations en arrière-plan, iOS 17 limite davantage le silent push. Pour les cas non urgents, planifiez les syncs en BGAppRefreshTask plutôt qu'en silent push, plus fiable et mieux toléré par le système.

Les métriques qui disent si ça marche#

Une stratégie de notifications se pilote avec des chiffres, pas au feeling. Sur nos projets d'app mobile, on suit systématiquement quatre indicateurs :

• Taux d'opt-in initial : combien d'utilisateurs acceptent la permission.
• Conversion de l'écran de permission : l'efficacité du moment et du message de demande.
• Taux de délivrance : livré sur envoyé, pour repérer la livraison passive.
• Taux d'ouverture par type : quelles notifications méritent d'exister.

Un taux d'opt-in nettement sous les 40 % pointe presque toujours vers un mauvais timing de la demande de permission, rarement vers le contenu.

La stratégie de notifications se conçoit avec l'app, pas après : c'est l'un des points qu'on cadre dans nos projets d'application mobile, aux côtés des patterns React Native et Expo qui structurent le reste de l'app. Et si vous hésitez encore sur la techno, voici pourquoi on choisit React Native.