OFIBO passe au temps réel : les notifications push Firebase sont actives

17 septembre 2026

Le 17 septembre a été l’une de ces journées de développement où une fonctionnalité qui paraît simple à l’écran a demandé énormément de travail en coulisses.

Aujourd’hui, nous avons construit les fondations de véritables notifications push dans l’application mobile OFIBO, en reliant l’application Android, le backend Laravel, Firebase Cloud Messaging, les files d’attente en arrière-plan et notre serveur de production.

Le résultat est important : OFIBO peut maintenant notifier automatiquement les utilisateurs sur leur téléphone lorsqu’une activité pertinente se produit sur la plateforme.

Firebase est maintenant connecté à OFIBO

La partie la plus importante du travail d’aujourd’hui a été l’intégration de Firebase Cloud Messaging à OFIBO.

Nous avons configuré le projet Firebase ofibo-app et aligné l’application Android sur le package de production d’OFIBO :

com.ofibo

La configuration Firebase pour Android, la configuration Expo et le projet Android natif pointent désormais vers la même identité d’application de production.

Cela peut sembler être une petite modification de configuration, mais elle touche plusieurs couches d’une application Android React Native / Expo. Les identifiants de package, la configuration native Gradle, les packages Kotlin, la configuration Firebase et les identifiants EAS doivent tous correspondre.

Nous avons déplacé OFIBO vers la bonne identité Android de production

Une autre partie importante du travail a été de standardiser l’application mobile autour de com.ofibo.

Nous avons mis à jour la configuration Expo, le namespace Android, l’application ID et la structure des packages Kotlin natifs afin que le projet utilise une seule identité de production cohérente.

Nous avons également supprimé des artefacts Android obsolètes de compilation et de génération de code qui provenaient de l’ancienne structure de packages.

Après le nettoyage de ces références natives de compilation, la génération de code React Native a de nouveau pu s’exécuter correctement.

Tokens push Android natifs

OFIBO ne se contente pas d’envoyer une notification générique depuis le frontend. Chaque appareil mobile connecté possède maintenant son propre token Firebase Cloud Messaging.

Nous avons ajouté au backend la prise en charge de l’enregistrement de ces appareils dans OFIBO.

L’application mobile peut maintenant enregistrer son token FCM natif après l’authentification et le mettre à jour lorsque Firebase renouvelle ce token.

Lorsqu’un utilisateur se déconnecte, l’appareil peut aussi être désactivé afin qu’OFIBO ne continue pas d’envoyer des notifications authentifiées du compte à un appareil qui ne devrait plus les recevoir.

Un nouveau système d’appareils dans le backend Laravel

Dans le backend, nous avons introduit un registre d’appareils dédié aux notifications push.

OFIBO stocke maintenant les appareils des utilisateurs et indique si chacun est actuellement actif.

Nous avons ajouté des endpoints API authentifiés pour enregistrer et désactiver les appareils :

POST /api/push-devices
DELETE /api/push-devices

L’enregistrement des tokens a également été rendu sûr face aux conditions de concurrence grâce à un upsert atomique dans la base de données. C’est important car les applications mobiles peuvent déclencher l’enregistrement d’un appareil plusieurs fois pendant l’authentification, le renouvellement d’un token ou le démarrage de l’application.

Firebase HTTP v1 depuis Laravel

L’API Laravel d’OFIBO peut maintenant communiquer directement avec Firebase à l’aide de la moderne API HTTP v1 de Firebase Cloud Messaging.

Au lieu de placer des identifiants Firebase sensibles dans le dépôt de l’application ou dans le répertoire web public, les identifiants du compte de service Firebase de production sont stockés séparément sur le serveur.

Laravel utilise ces identifiants pour s’authentifier de manière sécurisée auprès de Firebase et envoyer des notifications aux appareils Android enregistrés.

Les abonnés peuvent être avertis des nouvelles sorties musicales

Le système de notifications est déjà connecté à l’une des relations les plus importantes d’une plateforme musicale : suivre des artistes.

Lorsqu’un artiste publie une nouvelle chanson publique, OFIBO peut identifier ses abonnés, trouver leurs appareils mobiles actifs et préparer des notifications à leur intention.

Nous avons relié ce comportement aussi bien au flux de téléversement d’Artist Studio qu’au flux administratif de téléversement de chansons. Le résultat ne dépend donc pas de l’interface OFIBO utilisée pour publier la piste.

La logique repose sur la publication d’une nouvelle chanson publique et non sur une catégorie musicale précise, ce qui permet à la fonctionnalité de rester flexible à mesure qu’OFIBO grandit.

Les nouveaux articles publiés peuvent également générer des notifications

La même infrastructure a été étendue au-delà de la musique.

Les nouveaux articles publiés sur OFIBO peuvent eux aussi être envoyés par le système de notifications push, ce qui nous fournit une base de notifications commune capable de prendre en charge de nombreux autres types d’activité de la plateforme à l’avenir.

Les notifications sont traitées par les files d’attente Laravel

Une décision architecturale importante a été de garder le travail Firebase en dehors de la requête de téléversement de l’utilisateur.

Publier une chanson ne devrait pas devenir lent simplement parce que des centaines ou des milliers d’abonnés doivent recevoir une notification.

À la place, OFIBO crée une tâche dans une file d’attente en arrière-plan.

Le téléversement se termine normalement et le travail de notification est traité séparément.

Cela signifie aussi qu’un problème temporaire avec Firebase ne peut pas empêcher un artiste de publier correctement une chanson.

Nous avons mis le worker de file d’attente en production

Créer des tâches de file d’attente localement n’est que la moitié du travail. Quelque chose doit continuer à les traiter en permanence en production.

Aujourd’hui, nous avons configuré Supervisor pour exécuter en permanence le worker de la file de base de données Laravel d’OFIBO sur le serveur de production.

Cela signifie que les notifications ne dépendent plus de l’exécution manuelle de :

php artisan queue:work

Le worker reste actif et traite automatiquement les nouvelles tâches de notification à mesure qu’elles arrivent dans la file.

Nous avons trouvé un véritable problème de permissions en production

Pendant les tests en production, nous avons rencontré l’un des problèmes les plus intéressants de la journée.

Firebase semblait correctement configuré lorsque les commandes étaient exécutées avec l’utilisateur root du serveur, mais le worker permanent de Supervisor continuait d’indiquer que Firebase n’était pas configuré.

La cause n’était finalement pas Firebase lui-même.

Le répertoire contenant les identifiants Firebase avait des permissions de système de fichiers qui permettaient à root d’y accéder, mais empêchaient l’utilisateur www, qui exécutait le worker de file d’attente, de traverser le chemin et de lire les identifiants.

Une fois les permissions de groupe et d’accès du répertoire correctement configurées, le worker Laravel de longue durée a pu s’authentifier correctement auprès de Firebase.

Cette correction de production était importante car elle démontrait que le système de notifications fonctionnait avec le véritable utilisateur et le véritable processus serveur chargés de délivrer les notifications au quotidien.

Nous avons ensuite testé toute la chaîne

Une fois toutes les pièces connectées, nous avons réalisé le test qui compte vraiment.

Nous avons publié une véritable chanson publique.

La chaîne complète était la suivante :

Nouvelle chanson → Laravel → tâche de file → Supervisor → Firebase → appareil Android → notification

Et cela a fonctionné.

Plus important encore, la notification suivante a fonctionné automatiquement via Supervisor sans démarrer manuellement un worker de file d’attente.

Cela a confirmé qu’il ne s’agissait pas simplement d’un test de développement réussi. La chaîne de notifications de production elle-même fonctionnait.

Préparer OFIBO pour les builds Android de production

Nous avons également poursuivi la préparation de l’application Android pour son véritable canal de build de production via Expo Application Services.

Le projet EAS d’OFIBO est connecté à l’application de production et utilise maintenant com.ofibo comme package Android.

Nous avons vérifié la configuration Firebase avec ce package et contrôlé les identifiants de signature Android stockés par EAS.

Le profil de build de production est configuré pour créer un Android App Bundle et utiliser l’incrémentation automatique distante de version, ce qui correspond à la direction nécessaire pour les futures versions de production.

Expo Doctor s’est également terminé avec succès avec 21 vérifications réussies, nous offrant une base beaucoup plus propre pour le prochain build mobile de production.

Bien plus qu’une fenêtre de notification

Du point de vue de l’utilisateur, le travail d’aujourd’hui finit par apparaître comme quelque chose de très simple : une notification arrive sur le téléphone.

Derrière cette notification se trouve désormais toute une infrastructure OFIBO :

• Firebase Cloud Messaging
• Authentification Firebase HTTP v1
• Tokens FCM Android natifs
• Enregistrement des appareils utilisateur
• Gestion du renouvellement des tokens
• Désactivation des appareils à la déconnexion
• Découverte des abonnés
• Événements de publication de chansons
• Notifications de publication d’articles
• Tâches de file d’attente Laravel
• Worker Supervisor permanent
• Gestion des identifiants de production
• Migration du package Android vers com.ofibo
• Configuration de production Expo et EAS

Une énorme étape pour OFIBO Mobile

Le 17 septembre ne consistait pas à ajouter un bouton ou modifier une page.

Nous avons connecté plusieurs systèmes indépendants et réussi à les faire fonctionner ensemble comme une seule chaîne de production.

OFIBO dispose maintenant des fondations techniques permettant une communication en temps réel entre la plateforme et ses utilisateurs mobiles.

Aujourd’hui, le système peut informer les abonnés qu’un artiste a publié une nouvelle chanson. La même infrastructure pourra avec le temps alimenter de nombreux autres événements importants d’OFIBO sans avoir à reconstruire le système de notifications depuis zéro.

Il s’agissait d’une énorme quantité de travail invisible, mais cela a considérablement rapproché OFIBO du comportement d’une plateforme musicale native complète plutôt que d’un simple site web intégré dans une application mobile.

17 septembre 2026 : Firebase, Android et le backend OFIBO ont enfin commencé à communiquer ensemble en production.