Firebase : le nouveau Parse ?

De la base de données temps réel créée par une startup en 2012 à la galaxie de services développés par Google, Firebase a bien changé depuis son rachat en 2014. Nous vous proposons un petit tour d’horizon des différentes fonctionnalités sous l’angle du retour d’expérience ainsi qu’une petite analyse de la stratégie du géant du web vis-à-vis des outils de développement mobile.

Realtime database : un jeu d’enfant

Comme nous venons de l’évoquer en introduction, la fonctionnalité phare que Firebase offre est sa base de données dite “temps-réel”. Concrètement, cela se traduit par une structure de données au format json synchronisée de manière automatique et quasi instantanée avec en prime une gestion des interruptions réseau. Sa force réside principalement dans sa facilité de mise en oeuvre. En seulement quelques lignes de code et moins de temps qu’il ne faut pour lancer la compilation, le SDK est intégré, configuré et la première salve de données synchronisée. Un jeu d’enfant. Qui plus est, tous les services Firebase sont disponibles sur les deux plateformes mobiles principales (Android et iOS) ainsi que sur le web* via une API et un SDK Javascript. Si votre besoin est la mise en place d’un chat cross-platform, ce service va vous faire gagner beaucoup de temps. Mais les cas d’usages sont évidemment bien plus nombreux et variés. A Octo, nous avons par exemple réalisé une application de partage de photos en interne via une application mobile qui repose sur cette solution. Les photos en elles-mêmes sont stockées chez un hébergeur tiers mais toutes les informations relatives aux clichés sont persistées et synchronisées dans la base de données temps réel. Un autre avantage à son utilisation est la gestion de l’authentification et des droits d’accès aux données. En effet, si l’identification via le compte Google est sans effort, elle l’est tout autant via d’autres fournisseurs d’identités tels que Facebook, Twitter ou Github. Une version beta d’un module d’authentification unifiée sur mobile est même disponible sur Github. D’autre part, il est possible d’administrer les droits en écriture et lecture aux données depuis la console web grâce à un moteur de règles assez efficace.

* à l’exception du Crash Reporting et du Remote Config, inapplicables sur web

Analytics : la fin de la corvée de taggage

A côté de cette fonctionnalité historique s’ajoutent donc des services très importants pour les développeurs d’applications mobiles. La suivante est une des spécialités de Google et elle est au centre de la galaxie Firebase : l’analytics. En effet, s’il y a un domaine dans lequel le géant peut revendiquer une hégémonie, c’est dans l’analyse de trafic de sites web.

Dès que vous intégrez le SDK de Firebase, sans même ajouter une seule ligne de code, une masse assez importante de données concernant vos utilisateurs (âge, sexe, zone géographique par exemple) ainsi que leurs usages (rétention, désinstallation) remontent automatiquement. Ces données précieuses pour comprendre quels sont les points forts et faibles de votre application sont agrégées sous la forme de rapports explorables dans le temps. Vous pouvez par ailleurs définir des événements personnalisés afin de suivre l’évolution de tel ou tel comportement. A noter qu’il y a une distinction entre ces événements - l’ouverture de tel écran par exemple - et les “propriétés utilisateurs” qui regroupent les données concernant les caractéristiques d’une personne ayant installé votre application. La distinction a notamment pour conséquence de ne pas pouvoir suivre l’évolution de ces propriétés utilisateurs puisque celles-ci ne varient pas dans le temps. Par exemple, si vous souhaitez mesurer le nombre d’utilisateurs qui ont décidé de ne pas accepter la réception de notification, vous n’aurez pas l’évolution temporelle de ce ceux-ci mais seulement une photographie à l’instant T de la population. Si vous désirez ajouter la dimension temporelle à cette donnée tout en la recoupant avec d’autres informations, l’utilisation des événements est recommandée mais vous devrez faire appel à un service tiers de Google (Big Query). A noter que les données récoltées par Firebase sont exploitables dans un délai de 24 heures (certainement pour des raisons de consolidation). Enfin, il est intéressant de noter la possibilité de créer des cohortes d’utilisateurs afin de suivre des micro-tendances dans une population ou encore la possibilité de récolter celles concernant les achats in-app directement sur les stores respectifs (App Store compris).

Pour aller plus loin : https://medium.com/google-developer-experts/firebase-analytics-vs-google-analytics-b2010f34d2bb#.3q35ui3zk

Remote Config (ou l’A/B testing facile et rapide)

Parmi les autres services qui méritent notre attention, “Remote Config” est certainement le plus intéressant ensuite. En effet, il s’agit ici de définir un ensemble de clés / valeurs afin de rendre configurable à distance des fonctionnalités de votre application. Là encore, la force de la fonctionnalité réside dans sa simplicité de mise en oeuvre. Quelques lignes de code suffisent pour l’intégrer ainsi qu’un fichier de configuration où vous définissez les valeurs par défaut de vos paramètres. Et le tour est joué ! Libre à vous de modifier ensuite la valeur de ces paramètres dans l’interface web lorsque le besoin s’en fait sentir. Les modifications prendront effet dès l’expiration du cache que vous aurez éventuellement redéfini (12 heures par défaut). C’est un outil très utile pour ne pas avoir à maintenir et héberger des fichiers de configurations statiques ou pire encore : définir “en dur” la valeur de ces paramètres qui nécessitent une mise à jour de l’application à chaque modification. Enfin, il est intéressant de noter que les valeurs peuvent être conditionnées par des contraintes telles que la plateforme (iOS/Android), une version de l’application, la langue du téléphone ou encore un pourcentage déterminé de la population d’utilisateurs. Un outil qui peut donc servir pour vos campagnes d’A/B testing dès lors que vous le couplez à l’analytics ! Nous avons par exemple fait l’usage de cette fonctionnalité afin d’afficher deux versions différentes d’une incitation à l’abonnement dans l’application La Matinale du Monde : cela nous permet de mesurer quelle version de l’incitation va maximiser le taux de conversion. En effet, celle qui va conduire au plus grand nombre de nouveaux abonnés est ensuite diffusée à l’ensemble des utilisateurs. Plus d’infos sur le Remote Config ici.

Hébergement web : le déploiement en une ligne de commande

Deux autres services qui ne sont pas révolutionnaires mais fort appréciables sont aussi mis à disposition : l’hébergement de fichiers statiques et de fichiers volumineux. Le premier permettant d’y déployer en deux commandes (grâce à la Firebase CLI) des applications front (JS, HTML/CSS) sur le CDN de Google et le second d’y stocker vos assets v olumineux (ou ceux générés par vos utilisateurs).

Nous avons pu utiliser ces outils afin de mettre en place un “mock d’API” afin de réaliser des tests en conditions réelles sans pour autant dépendre du backend de production. Cela nous a fait gagner du temps et de la flexibilité. Plus d’infos sur l’hébergement ici et là.

Test Labs & Crash Reporting : adieu les bugs

Côté développeurs, on appréciera également la présence du Test Lab (bien que seulement accessible à partir du plan “Blaze”) ainsi que du Crash Monitoring qui permettent de détecter en amont et en aval les éventuels comportements anormaux de votre application.

Le premier grâce à une batterie de devices sur lesquels vont s'exécuter des tests d’interfaces (ou des Monkey Tests) puis vous générer un rapport avec des screenshots afin de comprendre les parcours effectués.

Le second se charge plus classiquement de remonter les stacktraces des plantages que vos utilisateurs ont pu subir avec les informations complémentaires telles que le modèle ou la version du système. On notera que ces deux services sont déjà présents dans la console d’administration du Play Store. L’avenir nous dira s’ils peuvent coexister ou si celui de Firebase va supplanter l’existant. Cependant, il est intéressant de noter que cette fonctionnalité vient en enrichir une autre que nous évoquions plus haut : l’analytics. Il est possible de segmenter votre population d’utilisateurs selon un critère bien particulier : “ont-ils été impacté ou non par un certain crash ?”. On pourrait ainsi imaginer définir une population d’utilisateurs victimes d’un bug et choisir ensuite de les cibler grâce à Remote Config afin de leur afficher un message d’explication, voire les inciter à mettre à jour leur application. On voit là toute la puissance des différents services dès lors qu’on les fait interagir.

Plus d’infos sur le Crash Reporting ici.

Dynamic Links & Push Notification : un seul système pour les relancer tous

Enfin, on peut citer les deux dernières fonctionnalités de Firebase que sont le Dynamic Links et le service de notifications. Nous ne nous attarderons pas sur ce dernier qui vient en remplacement du système actuel côté Android (Google Cloud Messaging devient Firebase Cloud Messaging) qui centralise et simplifie l’envoi de push sur une seule et même interface (aussi disponible pour iOS).

Quant au Dynamic Links, c’est là encore une manière d’unifier et centraliser les points d’entrée dans vos applications en créant des deep links communs. Les URLs générées sont “intelligentes” puisqu’elles redirigent les utilisateurs tantôt sur le store d’application de son téléphone (App Store ou Play Store) si l’application n’est pas installée tantôt directement dans l’application si celle-ci est déjà présente. Vous pouvez également définir des URLs web de fallback dans le cas où l'utilisateur tenterait d’ouvrir le lien dans un navigateur sur ordinateur.

Firebase : le nouveau Parse ?

Bien que leurs ambitions semblent différentes et que les fonctionnalités divergent, un point commun nous fait inévitablement penser au “backend-mobile-as-a-service” Parse. Une question que l’on est en droit de se poser quand on connaît son destin funeste : Firebase peut-elle subir le même sort ? Il existe au passage une documentation pour migrer d’une implémentation de Parse à l’utilisation de Firebase (guide iOS et Android).

La réponse la plus probable est non. Pour plusieurs raisons.

La plus évidente étant que, s’ils tentent tous les deux de simplifier le travail des développeurs mobiles en leur fournissant une solution clé en main pour leur backend, c’est bien là leur seul point commun. En effet, Firebase est plus un ensemble de services regroupés sous la même bannière plutôt qu’un “simple” serveur pour applications mobiles. Il est donc possible qu’un jour, certains services soient dépréciés s’ils sont jugés dépassés par Google mais ils seront certainement remplacés par de nouveaux produits qui viendront compenser leur disparition. Car c’est là aussi que réside la force de la franchise Firebase : elle va très certainement s’enrichir de nouveaux services dans le futur. Vous pouvez d’ailleurs vous-même faire la demande de nouvelles fonctionnalités grâce à ce formulaire mis à disposition par Google : https://firebase.google.com/support/contact/bugs-features/

Un service de Mobile Application Management à venir ?

Personnellement, je ne serais pas surpris de voir, par exemple, un MAM faire son apparition dans la liste des produits à moyen ou long terme. En effet, Firebase et le Play Store ne sont finalement que deux facettes différentes d'une seule et même pièce : l'une à destination des développeurs, l'autre du reste du monde. On a vu qu’il y avait parfois dans l’offre de Google une certaine redondance (le Cloud Test Lab ou encore l’analytics par exemple).

Ce qui peut nous faire croire qu’un MAM pourrait être dans les cartons de Google c'est que ce qui transpire de la stratégie Firebase c'est une tendance à l’unification des offres en proposant systématiquement les services en cross-platform. Ils pourraient donc proposer cette solution de MAM à travers Firebase en y mettant à disposition les SDKs nécessaires à l'intégration de la solution tout en gardant l'interface de gestion indépendante dans une sorte de store privé unifié qui s'appuierait en partie sur le Play Store existant pour Android ainsi qu'une solution spécifique développée pour iOS. Tout cela n’est que spéculation mais seul l’avenir nous dira quelle direction Firebase va pouvoir prendre dans le futur.

Conclusion

En conclusion, la volonté de Google est bien de fournir tous les services web nécessaires au bon fonctionnement d'applications mobiles et habituellement développés en interne ou servis par de nombreux tiers (dont la qualité et la facilité d'intégration sont très variables). Nous pourrions, en théorie, dans les applications où nous l’avons intégré, nous séparer d’au moins deux services fournis par des tiers (sans compter la solution de publicité que nous n’avons pas testée) et donc d’autant de SDKs peu satisfaisants. La qualité globale de nos applications ne peut donc qu’être meilleure en utilisant des services Firebase.

Attention tout de même aux tarifs ! Car si le fair-use est largement suffisant pour une utilisation restreinte, la facture peut devenir salée si votre application doit en faire un usage intensif. Et c’est bien là que réside une partie de la stratégie de Google : un bon nombre de services que nous avons cités dans cet article sont “gratuits” et servent en fait de produits d’appel pour d’autres produits dont les tarifs sont, certes adaptatifs, mais pas forcément compétitifs. C’est là certainement le prix de la simplicité de mise en oeuvre. Mais il faut aussi garder à l’esprit que le fonds de commerce initial de Google réside dans la data. Et plus précisément dans l’accumulation de celle-ci puis son analyse statistique à des fins publicitaires. On est donc en droit de se demander si derrière les produits d’appel “gratuits” que nous avons évoqués, nous ne passons pas à la caisse une seconde fois en partageant des données sur les utilisateurs de nos applications ainsi que sur leurs usages. Le véritable enjeu pour Google est bien sûr de conserver la main sur les données générées par les applications mobiles et leurs utilisateurs grâce à une facilité d'intégration inégalée sur le marché.

Au final, les produits estampillés Firebase sont puissants et faciles à mettre en oeuvre mais il faut veiller à ne pas devenir totalement dépendant d’un seul acteur qui a, d’une manière générale, tendance à vouloir se rendre indispensable.