Après avoir étudié les différentes solutions techniques proposées par les constructeurs, les impacts sur l’ergonomie des applications, nous allons nous intéresser aux difficultés que doivent traiter les développeurs d’applications.

Impact sur le développement

Pour le moment, les constructeurs réalisent les applications majeures (email, Facebook, Twitter) et négocient avec différents fournisseurs de services (Pages Jaunes, Coyote, etc.) pour la réalisation d’applications spécifiques à leurs technologies. Les fournisseurs indépendants n’ont pas toujours accès aux différents SDK. Cela viendra sous peu.

Apple ne semble pas vouloir proposer un OS spécialisé véhicule. Les constructeurs désireront certainement une version spécifique de l’OS, ce qui semble incompatible avec les pratiques de l’entreprise.

Microsoft se positionne sur ce marché avec Windows Embedded Automotive (Nissan, Kia, Ford, FIAT). L’approche est essentiellement basée sur une déclinaison de Silverlight. Les constructeurs peuvent alors proposer des interfaces riches pour les services de bases. Cette solution ne permet pas, à ce jour, d’ajouter des applications complémentaires.

Le système d’exploitation Android est également privilégié. En effet, ce dernier peut être facilement adapté pour une utilisation dans un véhicule. Une place de marché applicative peut être proposée. Cela permet également de s’appuyer sur des développeurs de plus en plus nombreux maîtrisant cette technologie.

Mais n’allez pas croire qu’une application classique peut être utilisée directement dans un véhicule. L’ergonomie doit être revue de fond en comble. Pour des contraintes d’usages, mais également pour respecter le cahier des charges imposé par les constructeurs.

En théorie, il est possible de proposer une application HTML5 adaptée aux différentes marques de véhicules. Nous pensons que les performances actuelles de ces systèmes ne permettent pas d’utiliser cette approche. Il faut alors réaliser une application spécifique pour chaque solution.

Gestion de la mémoire

Dans un téléphone, seule la réception d’un appel est prioritaire. Pour une voiture, de nombreuses applications privilégiées sont maintenues en vie. Cela limite fortement la mémoire disponible pour les autres applications. De plus, le solde doit être partagé par toutes les autres. Il est donc difficile de maintenir des services en tâche de fond, alors que c’est justement un besoin applicatif fort dans un véhicule. Une application trop gourmande sera sacrifiée par le système d’exploitation.

Nous pensons que les applications majeures en véhicule doivent analyser le comportement du conducteur, pour lui proposer des services sans qu’il ait besoin de le demander. Cela nécessite des traitements en tâche de fond, souvent incompatibles avec les architectures et la mémoire disponible dans ces systèmes. L’analyse des comportements des conducteurs, ou d’un groupe de véhicules, permettra de nouveaux usages. Les technologies Big Data seront alors sollicitées.

Utilisation des API

D’autres difficultés peuvent complexifier les applications. Par exemple, il est courant d’utiliser le protocole OAuth dans une application pour demander à l’utilisateur, l’autorisation d’exploiter son compte Facebook, Google ou Twitter. Ce mécanisme est bien maîtrisé via Internet ou via les mobiles pour exploiter les différentes API Web, mais il ne peut être utilisé dans un véhicule. En effet, OAuth retourne une page Web qui doit être présenté à l’utilisateur pour lui demander de saisir ses identifiants, avant d’accorder ou non certains privilèges à l’application. Cette dernière n’a pas la maîtrise de ce dialogue d’authentification. Mais, dans un véhicule, comme nous l’avons vu précédemment, l’ergonomie est différente. Les pages Web retournées par Facebook, Twitter ou Google ne sont pas compatibles avec le véhicule. Les boutons sont trop petits, le formulaire est difficile à remplir, etc.

Parfois, le fournisseur de service propose une API permettant de livrer l’identifiant et le mot de passe de l’utilisateur. Pour des raisons évidentes de sécurité, c’est rare. Il faut montrer patte blanche, et demander des privilèges particuliers à négocier avec le fournisseur. C’est possible avec Twitter, après la phase de développement du projet, mais pas avec Facebook.

OAuth2 permet les mêmes services que OAuth, mais sans imposer de page Web pour l’authentification. Il faudrait une généralisation de cette technologie dans les APIs WEB des réseaux sociaux pour régler la difficulté. Commencez dès à présent à migrer vers OAuth2 pour vos API !

Une astuce consiste à simuler la connexion par programme, avec une Webview invisible et l’injection de script. Mais rien ne garantit que cela fonctionne toujours dans 2 ans : on ne met pas à jour une application dans un véhicule aussi facilement que sur un téléphone.

Exploitation du réseau

Pour l’utilisation du réseau, plusieurs approches sont proposées par les constructeurs. Certains demandent un abonnement 3G supplémentaire d’une centaine d’euros, payable à l’année, d’autres proposent gratuitement une connexion 2G+, qu’il est possible d’étendre avec une connexion 3G via un smartphone ou une clef. Enfin, certains ne peuvent accéder au réseau qu’avec l’aide d’un smartphone ou d’une clef 3G.

Dans le modèle 2G+, c’est le constructeur qui paye le trafic au volume. Il est alors important pour lui de le limiter au maximum.

Il faut savoir que les connexions IP à base de sockets ne sont pas capables de faire de Roaming entre plusieurs antennes. La socket est perdu si le véhicule avance au point de changer d’antenne relais. Il faut alors se reconnecter, ou essayer de le faire avant la perte de la prochaine antenne. Il est donc difficile de maintenir un flux en fonctionnement lorsque le conducteur parcourt la campagne. De plus, lorsqu’il est nécessaire de changer de technologie, lors d’un passage UMTS à 2G ou 4G, cela demande un bon moment au terminal pour essayer les différentes pistes. À cela s’ajoutent les trames à échanger pour ouvrir une connexion chiffrée.

Il faut alors utiliser plusieurs stratégies pour optimiser l’utilisation du réseau. La première idée est d’utiliser des formats de messages très compacts, comme le propose Protobuf de Google. C’est un format binaire compact, bien plus concis que XML ou JSON.

Pour la lecture des données, plusieurs stratégies doivent être utilisées simultanément. Les données doivent être cachées pour éviter de répéter les mêmes requêtes. Il est également important de profiter d’une connexion pour récupérer par avance le maximum de données potentiellement utiles. Si, pendant la lecture de dix enregistrements, la connexion est perdue après 3,5 enregistrements, il est bon de garder les trois données valides plutôt que d’ignorer complètement le résultat.

Ces stratégies sont souvent incompatibles avec l’économie de bande passante nécessaire suivant les forfaits.

Pour réduire le trafic, une application Web peut servir de relais vers les données à exploiter dans le véhicule. Elle permet de réduire la taille des images, de compresser les flux, de supprimer les pièces attachées, etc.

Il faut prévoir dès le début de sauver toutes les modifications des données dans le terminal, pour attendre un moment propice pour envoyer un mail, un Tweet ou un post Facebook. Un service en tâche de fond doit s’occuper intégralement de gérer les échecs de connexions. Mais en même temps, le terminal peut décider de tuer votre application car elle n’est pas compatible avec le mode conduite ! Il faut intégrer cela dans des transactions pour ne perdre aucun message, ou découper l’application en deux. Une partie s’occupe de l’interface utilisateur et peut être interrompue lors d’un mouvement du véhicule. L’autre partie s’occupe uniquement du réseau.

Il faut trouver un équilibre entre le pré-chargement des données, le volume à rapatrier qui doit être faible, la tolérance à la perte du réseau pendant les requêtes et l’optimisation du format des données.

Une autre approche consiste à fonctionner en mode push. Les données du SI arrivent de façon asynchrone, lorsque le réseau est disponible. Les requêtes sont déposées sur le serveur sans en attendre de réponse. Les données arrivent lorsqu’elles le peuvent.

De plus, l’accès à Internet n’est pas toujours possible. En effet, pour des raisons de sécurité, les constructeurs imposent parfois le passage par un proxy possédant une liste blanche de serveurs cibles, et/ou l’interdiction d’utiliser d’autres protocoles que HTTP. Ouvrir une connexion LDAP, POP3, IMAP ou SMTP devient difficile. Il faut alors s’appuyer sur un serveur intermédiaire, mais cela rompt la chaîne de chiffrement. Il y a deux flux chiffrés : celui du véhicule vers le serveur, puis du serveur vers la cible utilisant un protocole exotique.

Ces difficultés sont maintrisables, si elles sont prises en comptes dès le début du projet.

Sécurité

Comme ces technologies peuvent être connectées au bus du véhicule, il ne faut pas qu’elles puissent y injecter des données. Pour le moment, seule la lecture est envisageable. Il faut contrôler les applications acceptables dans le système. Les constructeurs doivent alors renforcer la sécurité du système et auditer les applications avant de les publier sur leur place de marché. Ils s’y emploient autant que possible.

Les pirates ne se sont pas encore beaucoup intéressés à ces technologies, mais les dégâts risquent d’être importants. Les constructeurs sont alors frileux à ouvrir leurs places de marchés. Ils envisagent de contrôler tous les flux réseaux, pour pouvoir réagir en cas d'alerte.

Les mises à jour des applications ou des OS ne sont pas aussi faciles qu’avec un téléphone mobile. Et la durée de vie des voitures est bien supérieure à la durée de vie d’un smartphone. Que deviendront ces systèmes dans dix ans ? Comment réinitialiser le système lors de la revente ? Est-ce que l’ancien propriétaire pourra laisser des portes dérobées ? Un vrai challenge à relever.

Backup

Un véhicule part chez le garagiste, qui ne connaît rien à l’informatique. S’il y a un bug, il risque de changer l’intégralité du terminal, perdant ainsi tous les paramètres et les applications. Il faut prévoir un mécanisme de backup sur le Cloud. Google propose cela dans Android, mais les constructeurs n’ont pas toujours implémenté ce service. Le SAV risque d’être difficile.

Publication

Pour le moment, il y a très peu de communication sur la possibilité de publier une application sur les différentes places de marchés. Certaines sont très ouvertes comme Parrot, d’autre plus fermées comme Renault. Il ne faut pas oublier que la responsabilité du constructeur peut être engagée en cas d’accident. Il est alors prudent de se renseigner avant d’envisager de réaliser une application pour ces environnements.

Dès à présent, en séparant parfaitement les couches logicielles entre les couches présentations, métier et réseau, il devrait être relativement facile de porter une application Android pour différentes cibles.

Est-ce que l’effort est compatible avec la taille du marché ? Cela reste à prouver. En même temps, les belles places sont à prendre maintenant, pour un investissement raisonnable.

Conclusion

L’accès au bus de donnée du véhicule ouvre la porte à des nouveaux usages. Une compagnie d’assurance peut proposer un contrat qui s’adapte au mode de conduite constaté par le véhicule. Un tweet peut signaler automatiquement un retard, avec une prévision de l’heure d’arrivée selon les bouchons. Le flux musical peut suivre le conducteur lorsqu’il entre ou sort du véhicule.

Après la télévision, le PC, le smartphone, la tablette, il semble évident que le cinquième écran sera présent dans les véhicules.

PS : Pour terminer, pour avoir une application en mode portrait et non paysage, la voiture doit faire un tonneau !!!

Philippe PRADOS