Google Eddystone : révolution ou pétard mouillé ?

Google Eddystone : révolution ou pétard mouillé ?

Google vient de publier sous licence libre les spécifications d’Eddystone, un nouveau format de Beacon BLE qui permettrait de bypasser la couche applicative mobile habituelle. Petit point sur les différences avec les spécifications iBeacon et état des lieux du marché et des enjeux, car ne vous y trompez pas, nous sommes là au coeur de la lutte sans merci entre Apple et Google.

L’Eddystone beacon, Comment ça marche ?

L’Eddystone beacon est un émetteur qui, comme l’iBeacon, utilise  le protocole BLE pour déclencher des interactions avec les appareils mobiles Android et iOS alentours. Ce qui le différencie principalement de l’iBeacon, en revanche, c’est le format de ses données, une différence qui a des conséquences importantes, comme on le verra plus loin.

Concrètement, au lieu d’envoyer un seul « cadre » de données, il en envoie 3 différentes :

  • l’Eddystone-UID : l’identifiant unique qui permet d’identifier le beacon et donc de déclencher les notifications ou les actions mobiles qui lui sont associées,
  • l’Eddystone-URL : vous l’aurez compris, c’est le concept hérité des URIbeacon, qui permet de déclencher l’affichage d’une url sur les appareils mobiles alentours compatibles, on y revient plus bas en détail,
  • l’Eddystone-TLM : il s’agit de l’ensemble des données télémétriques complémentaires que peut envoyer le beacon grâce aux capteurs auxquels il est éventuellement relié et qui dépendent bien entendu du constructeur, à titre d’exemple la température du beacon, son niveau de batterie, l’humidité de l’air…

Autre différence de taille, les informations d’identification ne se déclinent pas sur le mode UUID/major/minor mais sous la forme d’un identifiant unique. Car, et c’est bien là l’enjeu de ce nouveau format dans la bataille du mobile contextuel, il devrait permettre d’interagir avec un mobile en natif, sans aucune couche applicative spécifique, grâce à l’Eddystone-URL, du coup plus besoin d’un UUID pour accrocher la bonne application. Je dis « devrait permettre » car pour le moment ce système fonctionne avec les mobiles Android uniquement grâce à l’intervention providentielle de l’application Physical Web et sur les appareils iOS grâce à Chrome pour qui Google a procédé dans l’urgence à une mise à jour spéciale. Le fonctionnement en natif sur Android devrait arriver avec la prochaine version de l’OS et sur les mobiles Apple il a tout de même peu de chance d’être un jour implémenté.

Enfin, rappelons que la spécification Eddystone est publiée sous licence libre (Apache v2.0 pour être précise) contrairement à la spécification iBeacon qui est, elle, propriétaire. Sa grande force est donc d’être clairement extensible et pensée pour l’être, laissant la possibilité aux développeurs créatifs de rajouter au besoin des cadres de données supplémentaires.

Autre atout extrêmement valorisable, les Eddystone beacons permettent de fonctionner en background sur Android, même s’il ne peuvent pas en faire autant sous iOS, l’inverse des iBeacons en somme. Même s’il faut du coup choisir, l’arrivée de ce nouvel acteur ouvre donc le champ de possibilités très attendues.

Comment Google a intelligemment avancé ses pions

Même si on peut s’interroger sur le pourquoi du moment et sur la pertinence du nom de cette nouvelle initiative, force est de reconnaitre qu’après des mois d’errance opaque sur le sujet, Google a finalement plutôt bien réussi son entrée sur l’échiquier des beacons, privilégiant manifestement l’effet de surprise bien minuté.

Car cela fait déjà quelques temps que la firme travaille dans l’ombre avec les plus gros fabricants de beacons – Kontakt.io, Accent, Estimote, Radius… – pour faire en sorte que le jour J, abracadabra, tous soient au garde à vous pour fournir une mise à jour de leur firmware – permettant ainsi de transformer n’importe quel iBeacon en Eddystone beacon. Faisant cela, Google sous-traite astucieusement sa campagne de lancement à des fabricants extatiques et légèrement amnésiques, eux-même légitimement ravis d’avoir de nouvelles choses à offrir et surtout à vendre. Une manœuvre bien évidemment pratique lui permettant d’avoir « son » produit immédiatement disponible sur le marché au lancement des spécifications, contrairement à Apple à l’époque. Mais surtout une habile manœuvre de communication franchement efficace qui a permis d’inonder tous les blogs de constructeurs d’informations concernant le lancement d’Eddystone, d’occuper ainsi massivement la scène et de donner à une avancée technique relativement limitée le visage d’un tsunami technologique. Démesurément repris sur tous les blogs hightech et marketing de la blogosphère, sans mentionner le flots continue sur Twitter, la news a même permis à Google d’accéder aux rivages enviés de certains gros media online comme Forbes avec une news franchement pas grand public.

En cela, Google surpasse Apple sur son terrain de prédilection : si la marque à la pomme à l’habitude d’utiliser ses fans développeurs, utilisateurs, constructeurs… comme agence de relations publiques, elle a peut-être commis la faute avec l’iBeacon de les avoir ensuite laissés un peu trop livrés à eux-mêmes, libres mais un tantinet orphelins. Un impair que Google n’a pas l’intention de commettre puisqu’il comble désormais même l’espace laissé vacant par Apple.

Car, malgré de nombreuses limites sur lesquels nous reviendrons plus tard, Google, comme il l’explique si bien dans le post de lancement d’Eddystone sur son Developper blog, a su très bien identifier les limites actuelles de l’iBeacon pour mieux les dépasser et mettre en valeur les avancées de sa déclinaison personnelle :

  • plus besoin d’application pour envoyer des messages, le graal…
  • des données télémétriques pour une meilleure gestion hardware des flottes de beacons, le bonheur…
  • le tout adossé sur pas moins de 3 API Google – Nearby, Proximity Beacon et Places for Android pour les plus ambitieux – qui promettent aux développeurs de belles heures d’expérimentation et aux utilisateurs des applications puissantes – si on met de côté les habituels problèmes de tracking généralisé, bien évidemment…

Des casseroles encore lourdes à trainer

Pour commencer, il convient de relativiser la révolution technologique à l’œuvre ici.

Loin d’avoir envie de choisir un camp dans cette histoire, on ne peut s’empêcher de rappeler que la paternité du concept revient tout de même à Apple, même si certains constructeurs semblent l’avoir déjà oublié. Les modifications apportées ici par Google, si elles sont pour certaines très intelligentes et encore mieux vendues, représentent une évolution assez peu ébouriffante des spécifications de base de l’iBeacon :

  • 3 paquets de données au lieu d’un qui promettent de vider les batteries au moins un peu plus vite
  • un format d’identification moins extensible qui oblige les développeurs à embarquer en dur toutes les ID des beacons liés à une application et promet ainsi des lendemains douloureux en terme d’évolutivité,
  • des données télémétriques plus ou moins utiles et que de nombreux fabricants d’iBeacon embarquaient de toutes façons déjà…

Cette nouvelle spécification pose en outre quelques challenges pour les marketeurs comme pour les utilisateurs et les développeurs, en voici quelques-uns.

L’absence d’application, une fausse bonne idée ?

Pour commencer, l’évident côté obscur du contournement de la couche applicative. Passée la promesse superbement démocratique de pouvoir diffuser sans application, laissant entrevoir aux petites structures des opportunités décoiffantes et aux marketeurs fous des opérations de communication proches de l’hystérie digitale, on commence à distinguer un problème de taille – que les constructeurs s’emploient unanimement à minimiser afin d’assurer les arrières de leur nouvelle poule aux oeufs d’or.

D’autant que tous avouent ne pas savoir encore très bien à quoi va ressembler le workflow définitif d’une communication via Eddystone-URL, sur iOS comme sur Android d’ailleurs – ce qui laisse à penser que ce lancement a tout de même été un chouillat précipité… Car pour le moment sur l’un comme sur l’autre, on est loin du fonctionnement d’un iBeacon avec des notifications classiques : Google semble avoir opté pour des notifications muettes qui, soit s’affichent sans son sur Android, soit qu’il faut aller chercher volontairement dans le centre de notification pour iOS !

On voit bien comment la promesse d’une vraie démocratisation est franchement surévaluée : en pouvant s’adresser à n’importe quel appareil mobile alentours, un annonceur s’adresse du coup à un public non qualifié, la micro-localisation ne pouvant décemment par suffire à qualifier qualitativement un prospect. Soit cette annonce arrive sous la forme d’une notification « intrusive » et porte le risque d’être franchement répulsive auprès d’un public qui n’a pas fait la démarche d’installer une application dédiée, soit elle est discrète pour ne pas prendre ce risque et elle est du coup susceptible de passer facilement à la trappe contextuellement parlant, le contexte étant ici de plus le seul critère de qualification… Le risque est donc soit d’être assailli de notifications agressives que l’on a jamais demandé à recevoir, soit de ne remarquer les notifications qu’une fois rentré chez soi hors contexte et donc sans pertinence… Des notifications qui de plus, rappelons-le, n’aurons  pas de message personnalisé mais simplement le titre de la page web vers laquelle elle renvoie, un autre point noir actuel de ce dispositif.

Dans tous les cas la plus-value face aux iBeacons reste moindre que celle annoncée et dans le pire des cas, on peut même  craindre un sévère effet répulsif de la part d’un public exigeant voire déjà réfractaire envers toute la communauté du beacon qui peine déjà parfois à en étendre l’adoption. Certes le modèle d’Apple a de lourdes limites puisqu’il nécessite une application – problème qui pouvait cependant être facilement contourné grâce à de nombreuses plateformes marketing proposant des applications génériques – mais il privilégiait l’utilisateur final avant tout, ce qui ne peut être que l’unique bon choix.

Des mises à jour plus complexes

Autre problème non négligeable dans l’utilisation de l’URL sans application mobile : la mise à jour de cette URL ! Le système d’Apple permet en effet de paramétrer cette information via un modèle cloud sans avoir besoin d’aucune proximité avec le beacon. Avec le système de Google, une connexion directe au beacon est nécessaire pour faire évoluer cette information, facile d’imaginer le casse-tête avec une flotte de plusieurs dizaines ou même centaines de beacons ! Bien sûr, certains constructeurs comme Onyx ou Kontakt.io proposent des solutions autorisant le paramétrage à distance mais elles sont loin d’être universellement répandues…

Des fonctionnalités de tracking réduites

Autre bémol, en se passant d’application, on perd également tout le tracking possible avant l’action d’ouverture de la notification. Concrètement, avec une application iBeacon, il est aisé de récupérer des données sur la quantité de mobiles passant à proximité d’un beacon, sur la quantité de mobiles recevant des notifications et enfin ceux ouvrant ces mêmes notifications. Avec les Eddystone-URL vous ne pouvez logiquement avoir que la dernière donnée, de quoi calmer les ardeurs des marketeurs zélés…

Enfin, et ce n’est pas le plus grave mais c’est à noter, Eddystone ne permet pour le moment que de gérer une seule zone et non plus trois comme avec les iBeacons.

Quels enjeux pour les beacons ?

Soyons clairs, Google n’en est ici qu’à ses débuts, et certaines évolutions nécessaires au développement de son système ne devraient pas tarder. Elles sont d’ailleurs déjà annoncées plus ou moins en filigrane par les constructeurs, désormais transformés en ambassadeurs à plein temps de Google. Par ailleurs, si le choix des notifications non intrusives est confirmé, ce système serait moins efficace dans un cadre commercial mais beaucoup plus adapté à des applications culturelles ou touristiques, un moyen de rentrer sur le marché par une porte encore sous-exploitée…

Comme on pouvait le prévoir depuis déjà quelques temps, on risque donc d’avoir rapidement 2 solutions tout à fait excellentes et concurrentes, avec un niveau de maturité équivalent – puisqu’Eddystone a pris le train en marche – avec chacune ses points faibles et ses points forts. Et avec aucune raison particulière que l’une s’impose face à l’autre puisque chacune couvrira des besoins différents. Si Google a délibérément créé son format de beacon, ce n’est certainement pas pour pouvoir rajouter quelques fonctionnalités mineures, mais bien pour reprendre la main sur le secteur. Or quel intérêt aurait Apple de son côté à adopter le format Eddystone, clairement avantageux pour Google et incompatible avec celui de l’iBeacon.

En tous les cas, ce qui est sûr c’est que le beacon a de beaux jours devant lui tant il semble concentrer les convoitises. Au 1er rang du phénomène, les fabricants de balises qui se retrouvent du jour au lendemain avec un catalogue doublé, et ce pour quasiment pas un kopeck. Et c’est surement là la plus belle victoire de Google, avoir su mettre les constructeurs dans son camp. Comme d’habitude ce sont les développeurs qui vont s’arracher les cheveux…

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *


un × 4 =

Vous pouvez utiliser ces balises et attributs HTML : <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>