React Native et tâches en arrière-plan : comment faire

La plupart des guides React Native s’arrêtent au moment où ça “marche sur l’émulateur”. Le problème, c’est qu’en production — sur un vrai téléphone, avec iOS qui gère agressivement la mémoire et Android qui varie selon le constructeur — vos tâches en arrière-plan s’arrêtent. Silencieusement. Sans log. Sans erreur visible.

Résultat : synchronisation de données qui ne se fait plus, notifications qui n’arrivent pas, fetch qui échoue après 3 jours d’utilisation. Et un utilisateur qui désinstalle.

Voici ce que 15 ans à construire des applications web et mobiles m’ont appris sur le sujet — et ce que la documentation officielle ne documente pas assez.

---

Pourquoi les tâches en arrière-plan échouent vraiment (et ce n’est pas votre code)

La première erreur que font la plupart des développeurs : chercher le bug dans leur code. Souvent, le code est correct. C’est le système d’exploitation qui travaille contre vous.

iOS et Android ont des philosophies radicalement opposées sur la gestion des processus en arrière-plan. iOS est draconien : l’application n’a aucune garantie d’exécution en dehors des fenêtres explicitement accordées par le système. Android est théoriquement plus permissif, mais les surcouches constructeurs (Samsung, Xiaomi, Huawei) ajoutent leurs propres couches d’optimisation batterie qui tuent les processus sans prévenir.

Ce qu’on voit concrètement chez nos clients qui développent des apps React Native :

• Une tâche BackgroundFetch qui fonctionne en développement, mais qui cesse après 72 heures en production sur iOS
• Un service de géolocalisation en arrière-plan qui s’arrête dès que l’utilisateur Xiaomi active le “mode économie d’énergie”
• Des workers qui tournent parfaitement sur un Pixel (Android pur), mais qui meurent sur un Galaxy S24

La documentation React Native mentionne ces contraintes. Elle ne vous dit pas comment les contourner de façon robuste.

---

Les trois approches — et pourquoi deux d’entre elles vous décevront

BackgroundFetch : utile, mais limité

react-native-background-fetch est la solution la plus documentée. Elle fonctionne sur iOS et Android, elle est simple à mettre en place, et elle vous donnera de faux espoirs.

Sur iOS, l’intervalle minimum est de 15 minutes — et c’est une suggestion, pas une garantie. Le système décide quand exécuter la tâche en fonction de l’historique d’utilisation de l’app, de la charge batterie, de la connexion réseau. En pratique, vos tâches s’exécutent entre 15 minutes et plusieurs heures après l’heure prévue.

Ce n’est pas un bug. C’est le comportement documenté d’iOS.

Pour des synchronisations non critiques (mise à jour de contenu, préchargement de données), c’est acceptable. Pour tout ce qui doit être ponctuel — paiement, alerte, mise à jour de stock — c’est insuffisant.

Les Headless JS Tasks sur Android : puissantes, fragiles

Android permet via HeadlessJS d’exécuter du JavaScript même quand l’app est en arrière-plan. C’est plus fiable que BackgroundFetch sur les appareils Android “purs”. Le problème arrive avec les surcouches constructeur.

Voici ce qu’on ne vous dit jamais en agence : les téléphones Xiaomi, Oppo et Huawei représentent une part non négligeable du marché français. Et tous ces constructeurs ont des systèmes de gestion batterie qui tuent les processus en arrière-plan, sauf si l’utilisateur va manuellement dans les paramètres décocher “optimisation batterie” pour votre app.

Combien d’utilisateurs font ça ? Très peu.

Les notifications push : la vraie solution pour le temps réel

Si votre besoin est de déclencher une action précise à un moment précis, arrêtez de lutter contre les limitations des tâches en arrière-plan. Utilisez les notifications push silencieuses.

Le principe : votre serveur envoie une notification push sans contenu visible (silent push notification). L’app se réveille, exécute sa tâche, se rendort. iOS garantit 30 secondes d’exécution. Android est plus généreux.

C’est l’architecture qu’utilisent WhatsApp, Slack, et la plupart des apps critiques. Pas parce que c’est élégant — parce que ça marche en production.

---

La stack qui fonctionne vraiment en production

Après avoir testé plusieurs approches sur des projets réels, voici ce qu’on recommande selon le cas d’usage.

Pour la synchronisation périodique non critique (mise à jour de contenu, stats, logs) : Utilisez react-native-background-fetch avec une stratégie de retry. N’assumez jamais que la tâche s’est exécutée. Vérifiez côté serveur, et re-synchronisez à l’ouverture de l’app si nécessaire.

Pour les actions déclenchées par le serveur (notifications, mises à jour de données critiques) : Silent push notifications via Firebase Cloud Messaging (FCM) sur Android, APNs sur iOS. Testez impérativement sur de vrais appareils, pas seulement sur simulateur.

Pour la géolocalisation continue : react-native-background-geolocation de Transistor Software est la référence. C’est payant (environ 400$/an pour une app commerciale). C’est aussi la seule lib qui gère correctement les edge cases iOS/Android en production. Si votre app dépend de la géoloc, c’est un investissement, pas un coût.

“La fiabilité d’une app mobile se mesure à ce qui se passe quand personne ne regarde — quand l’écran est éteint, la batterie à 15%, et l’utilisateur en zone de faible réseau.” — Principe qu’on applique systématiquement en audit mobile

---

Les erreurs de configuration qui coûtent cher

Voici où ça devient intéressant — et où la plupart des projets déraillent.

Oublier les capabilities iOS

Sur iOS, chaque type de tâche en arrière-plan doit être déclaré dans Info.plist et activé dans les Capabilities Xcode. Background Fetch, Remote Notifications, Background Processing — si vous oubliez un de ces flags, la tâche s’exécute en développement (où les restrictions sont allégées) et échoue en production.

C’est une des causes les plus fréquentes de “ça marchait avant la mise en production”.

Ignorer les Doze Mode et App Standby sur Android

Android 6+ introduit le “Doze Mode” : quand l’appareil est inactif, les jobs en arrière-plan sont regroupés et différés. Android 8+ ajoute des restrictions encore plus sévères sur les services en arrière-plan.

La solution officielle : utiliser WorkManager via une lib native. react-native-background-fetch le fait sous le capot depuis sa version 4. Si vous utilisez une version antérieure ou une lib non maintenue, vous êtes exposé.

Vérifiez vos dépendances. Un npm outdated rapide peut révéler des surprises.

Ne pas gérer les timeouts

iOS vous donne 30 secondes. Android est variable. Si votre tâche dépasse ce délai — fetch réseau lent, traitement lourd, base de données SQLite qui rame — le système la tue. Sans exception. Sans log propre.

La règle : toute tâche en arrière-plan doit avoir un timeout explicite. Si elle n’a pas terminé en 25 secondes, elle doit se terminer proprement elle-même, sauvegarder son état, et reprendre au prochain cycle.

---

Tester en conditions réelles : le protocole qu’on utilise

Les émulateurs ne reproduisent pas les comportements en arrière-plan. Point. Vous devez tester sur de vrais appareils, avec de vraies contraintes.

Notre protocole minimal avant de shipper une feature de background processing :

Appareil 1 — Android pur : Un Pixel ou un appareil Android One. Valide que votre code fonctionne sans surcouche constructeur.

Appareil 2 — Samsung Galaxy : Teste le comportement avec la surcouche Samsung, qui est la plus répandue en France.

Appareil 3 — iPhone avec iOS récent : Valide les restrictions Apple, qui évoluent à chaque version majeure.

Pour chaque appareil, le scénario de test :

1. Lancer l’app, mettre en arrière-plan
2. Éteindre l’écran, attendre 30 minutes
3. Vérifier si la tâche s’est exécutée
4. Répéter avec batterie à moins de 20%
5. Répéter avec le mode économie d’énergie activé

C’est fastidieux. C’est ce qui sépare une app qui tient en production d’une app qui génère des tickets de support à 3h du matin.

---

La stratégie de résilience : ne jamais supposer que la tâche s’est exécutée

Voici le changement de mindset le plus important : concevez votre app comme si les tâches en arrière-plan pouvaient ne jamais s’exécuter.

Cela implique :

Une synchronisation au premier plan en fallback. À chaque ouverture de l’app, vérifiez si des données doivent être synchronisées. Si la tâche en arrière-plan a raté, le premier plan rattrape le retard.

Un timestamp de dernière exécution. Stockez localement quand la tâche s’est exécutée pour la dernière fois. Si le délai est anormal, déclenchez une resync immédiate.

Des indicateurs côté serveur. Ne faites pas confiance uniquement au client. Votre serveur doit savoir si un appareil est “en retard” et adapter ses réponses en conséquence.

Ce n’est pas de la sur-ingénierie. C’est ce que font toutes les apps mobiles critiques. Gmail, Notion, Slack — tous ont une logique de rattrapage au premier plan parce que tous savent que le background processing n’est pas fiable à 100%.

“Un système robuste n’est pas celui qui ne tombe jamais. C’est celui qui se relève tout seul.”

---

Ce que ça change concrètement pour votre projet

Si vous développez une app React Native avec des besoins en arrière-plan, voici les trois points actionnables à retenir :

1. Choisissez votre stack selon votre cas d’usage réel, pas selon le premier tutoriel Medium que vous avez lu. BackgroundFetch pour le non-critique, silent push pour le temps réel, libs spécialisées pour la géoloc.

2. Testez sur de vrais appareils, avec de vraies contraintes. Émulateur = fausse sécurité. Un Samsung en mode économie d’énergie vous révélera plus de bugs en 30 minutes que 10 heures sur simulateur.

3. Concevez pour l’échec. Votre tâche en arrière-plan va rater. Pas toujours, pas sur tous les appareils, mais elle va rater. Votre architecture doit l’anticiper.

---

Conclusion : la fiabilité, ça se construit, ça ne se suppose pas

Le background processing en React Native n’est pas un problème de code. C’est un problème d’architecture, de configuration, et de test en conditions réelles.

Les tutoriels de base vous montrent comment faire tourner une tâche. Ils ne vous montrent pas comment faire tourner une tâche de façon fiable, sur tous les appareils, pendant 18 mois de production. C’est là que la différence se fait entre une app que les utilisateurs gardent et une app qu’ils désinstallent.

Chez GDM-Pixel, quand on intervient en audit sur une app mobile qui “ne fonctionne plus comme avant”, les tâches en arrière-plan sont dans les trois premières choses qu’on vérifie. Parce qu’on sait que c’est là que les bugs silencieux vivent.

Votre app React Native a des comportements erratiques en production ? On fait des audits techniques mobiles — diagnostic honnête, recommandations actionnables, sans vous vendre une réécriture si ce n’est pas nécessaire. Contactez-nous pour en parler.