Skip to content

Mois : août 2009

Les perspectives de la réalité augmentée

Posted in perspectives

J’avais parlé dans ces billets (Quelques tendances IT pour 2009, La géolocalisation dans les navigateurs) des formidables opportunités de la géolocalisation dans les applications IT. Cette fonctionnalité est déjà largement exploitée dans les applications mobiles sur iPhone ou Android.
La réalité augmentée est probablement la prochaine étape vers des applications encore plus contextualisées et vers l’ubimedia.
Pour mémoire, on peut définir la réalité augmentée comme la superposition d’informations à l’environnement réel. L’exemple de plus classique d’une telle interface est la « vision tête haute » dans les cockpits d’avion de chasse : les pilotes voient en effet des informations de vol s’afficher en surimpression sur le paysage.

Typologies de réalité augmentée

Il me semble qu’on peut distinguer deux types de réalité augmentée :

  • la superposition d’information sur un fond d’images issues d’une base de données : c’est le cas de SkyMap et Street View sous Android.
  • la superposition d’information sur l’environnement réel, capté par la caméra de l’appareil mobile : c’est le cas de Layar et Wikitude sous Android.

Contraintes techniques

Pour proposer des fonctions de réalité augmentée, l’appareil mobile doit connaitre le contexte précis de l’utilisateur : où il se trouve, et dans quelle direction il regarde. L’appareil doit donc disposer d’un capteur GPS et d’une boussole numérique.
C’est le cas de tous les appareils sous Android, c’est pourquoi ce système propose de nombreuses applications de réalité augmentée.
Le dernier iPhone (le 3GS) est équipé d’une boussole numérique : on devrait donc voir apparaitre rapidement des applications similaires sur l’AppStore d’Apple. Des rumeurs disent même qu’Apple devrait sortir à l’automne une mise à jour de l’iPhone dédiée à la réalité augmentée.

Perspectives

Pour reprendre le parallèle avec la géolocalisation, je vous propose de parler de couches, ou layers en Anglais.
Les systèmes comme Google Maps ou Mappy permettent de présenter des informations (points de vente, embouteillages, etc.) sur fonds de carte. On utilise en général le format KML pour superposer ces données aux cartes.
De la même manière, les outils de réalité augmentée permettent de superposer une ou plusieurs couches : noms des monuments, noms des stations de métro, amis présents aux environs, etc.
C’est en fait l’objet de l’application Layar : le nom Layar vient de layers et AR (Augmented Reality). L’objectif de ses concepteurs est de proposer un système pour superposer des couches de réalité augmentée. Layar est donc une sorte de navigateur d’un nouveau type. Il pourrait constituer le navigateur 3D que j’avais évoqué dans ce billet : Liens entre le Web & les mondes 3D.
Ce nouveau type de navigateur fait émerger la question de l’interopérabilité : aurons nous un format universel et standard pour les couches de réalité augmentée? Une sorte de KML de la réalité augmentée? Ou bien Apple ne risque t’il pas de proposer un format propriétaire à l’automne? L’avenir nous le dira…

On peut dors et déjà imaginer que de nombreuses applications mobiles contextualisées offriront plusieurs modes d’affichage :

  • un mode textuel
  • un mode géolocalisé sur fond de carte
  • un mode réalité augmentée

Il se pourrait que ces 3 modes deviennent un standard.

Qu’en pensez vous?

Plateformes de Cloud Computing (4) : l’approche Microsoft

Posted in tendances

Ce billet constitue la quatrième et dernière partie de mon panorama estival des plateformes de Cloud Computing.

Microsoft a tiré les enseignements des plates-formes lancées avant la sienne : l’éditeur de Redmond propose ainsi un modèle à la croisée des chemins entre runtime .NET (à la Google Apps Engine) et machine virtuelle (à la Amazon Web Services).
L’offre Windows Azure se décompose en plusieurs couches :

  • Le service d’exécution de la plate-forme est basé sur le runtime .NET : la CLR (Common Language Runtime). Conformément à l’approche initiale de .NET, des langages non Microsoft comme PHP ou Ruby pourront être utilisés.
  • Windows Azure Storage et SQL Azure sont les services de persistance, accédés selon le style REST.
  • .NET Service Bus propose le service d’intégration.
  • L’authentification est assurée par la base de comptes Windows Live ID, ou par fédération d’identité au travers de Geneva.

La philosophie d’Azure avec le développement .NET est de permettre aux développeurs de retrouver des langages/environnements connus. Cependant, cette cohérence peut être trompeuse car les applications doivent être aménagées : l’architecture est contrainte comme avec la PaaS GAE.
L’objectif de Microsoft est aussi d’offrir le maximum de souplesse aux entreprises. Ainsi, Azure pourra à terme exécuter du code natif (C++), et il sera possible de déployer ses propres machines virtuelles, selon la pratique proposée par Amazon. Microsoft veut ainsi satisfaire tous les acteurs de l’entreprise :

  • Les maîtrises d’ouvrage qui souhaitent un développement agile pourront utiliser .NET. La plate-forme sera alors abstraite et exploitée par Microsoft, comme chez Google.
  • Les profils techniques qui souhaitent maîtriser leur architecture logicielle de bout en bout pourront construire eux-mêmes leur machine virtuelle et la gérer, comme chez Amazon.

On retrouve ici une approche générale chez l’éditeur de Redmond : proposer aux entreprises un maximum d’options ou de scénarios possibles, plutôt que d’avoir une approche tranchée, un parti pris fort, comme chez Amazon, Salesforce ou Google.

Plateformes de Cloud Computing (3) : l’approche Google

Posted in tendances

Ce billet constitue la troisième partie de mon panorama estival des plateformes de Cloud Computing.

L’offre Google App Engine se décompose selon les couches :

  • Le service d’exécution de la plate-forme est basé sur un runtime Java ou Python. Les entreprises préfèreront le développement Java, plus proche de leurs standards. Ce développement est assez contraint afin de préserver la performance de la plateforme. De fait, GAE ne supporte qu’une partie de la norme JEE.
  • DataStore est le service de persistance. C’est une base de données, accédée par un langage de requêtage de haut niveau : GQL, Google Query Langage.
  • En termes d’intégration, la PaaS offre Secure Data Connect (SDC). SDC prend la forme d’un tunnel SSL entre GAE et le Système d’Information. SDC permet d’exposer les bases de données d’entreprise sous forme de services. Ce n’est pas un bus d’intégration à proprement parler.
  • pour l’authentification, Google propose l’intégration avec les comptes Google Apps, ou la fédération d’identité au travers de sa SSO API.

La philosophie de Google App Engine consiste à proposer une plate-forme offrant une grande puissance de traitement et une grande capacité de stockage : il s’agit de mettre les gigantesques capacités des datacenters Google à la disposition des entreprises. Ces dernières pourront donc lui confier leurs applications à très forte charge ou celles qui nécessitent beaucoup d’espace de stockage.
La contrepartie de cette promesse de puissance est une architecture Java assez contrainte. Néanmoins, Google propose un langage de programmation complet et non un environnement RAD comme force.com : les entreprises utilisatrices ont donc une plus grande marge de manœuvre qu’avec Apex.
Enfin, une des grandes forces d’App Engine est son intégration avec Google Apps : Google propose ainsi un environnement unique et cohérent pour son offre SaaS et les applications développées par les entreprises sur sa plate-forme PaaS.

Plateformes de Cloud Computing (2) : l’approche SalesForce

Posted in tendances

Ce billet constitue la seconde partie de mon panorama estival des plateformes de Cloud Computing.

L’offre PaaS de SalesForce s’intitule force.com. Elle se décompose en plusieurs couches :

  • Le service d’exécution de la plate-forme est basé sur Apex, un langage de haut niveau qui permet de créer rapidement des applications d’informatique de gestion : il n’est pas adapté à la création d’autres types d’applications. Ce langage est comparable à un RAD comme PowerBuilder ou Oracle Forms. Cependant, il n’est pas obligatoire de coder en Apex : il est souvent suffisant de customiser une application existante par simple paramétrage.
  • Force.com Database est le service de persistance. C’est une base de données, accédée par un langage de requêtage de haut niveau : SOQL, Salesforce Object Query Langage.
  • Force.com Connect est le service d’intégration. Il propose des connecteurs natifs pour Lotus, SAP et Oracle Business ; il supporte l’intégration web services, REST, JEE et .NET.
  • force.com propose l’authentification via sa propre base de comptes ou bien la fédération d’identité au travers du service SXIP.

La philosophie de force.com est d’offrir une plate-forme de développement rapide pour des applications de gestion. L’accent est donc mis sur la simplicité du développement et non sur la compréhension de l’architecture sous-jacente, ce qui est cohérent avec l’idée que l’architecture logicielle de la PaaS est du ressort de l’opérateur, non de l’entreprise utilisatrice. Salesforce a fait des efforts importants pour permettre une intégration facile avec l’existant de l’entreprise (délégation d’authentification à l’annuaire d’entreprise, connecteurs SAP, API Java et .NET, etc.).
Cette intégration ne nécessite pas un effort de développement important.
Cette approche est radicalement différente de celle d’Amazon, beaucoup plus axée sur une architecture totalement maîtrisée par les équipes techniques. Force.com plaira aux maîtrises d’ouvrages par sa proposition d’agilité et de délégation des tâches techniques. Tandis qu’AWS plaira aux équipes techniques qui souhaitent comprendre et maîtriser la plate-forme.

Plateformes de Cloud Computing (1) : l’approche Amazon

Posted in tendances

Grâce à la magie de la publication programmée, je vous propose une série de billets présentant les 4 principales plateformes de Cloud Computing (Amazon Web Services, force.com, Google App Engine, Azure) pendant mes congés estivaux. L’idée est de présenter les différences d’approche, de « philosophie » entre ces plateformes. Ces textes sont extrait de mon ouvrage « Cloud Computing & SaaS« , édité chez Dunod.

L’offre Amazon Web Services se décompose en plusieurs couches :

  • EC2, Elastic Cloud Computing, est le service d’exécution de la plate-forme. Il est basé sur la virtualisation par hyperviseur.
  • SimpleDB et S3, Simple Storage Service, sont les services de persistance. SimpleDB est un service de base de données, tandis que S3 permet le stockage de fichiers. Ces services sont accédés selon le style REST.
  • SQS, Simple Queue Service est le service d’intégration. Il permet l’échange de messages entre AWS et d’autres infrastructures.
  • AWS ne propose pas de service d’authentification

La philosophie d’AWS consiste à donner aux équipes informatiques une maîtrise complète de leur architecture logicielle. L’offre est destinée à des profils très techniques, qui souhaitent gérer leur application à bas niveau. Les utilisateurs d’AWS peuvent gérer eux-mêmes leurs sauvegardes, ce qui va à l’encontre de l’idée selon laquelle l’opérateur PaaS s’occupe de l’exploitation.
La seule abstraction proposée par AWS concerne la partie matérielle : lorsqu’on utilise la plate-forme, on n’a pas connaissance des machines ou disques utilisés ; en revanche, on connaît toutes les couches de son architecture logicielle. Cette approche est différente de celle de Salesforce, Google, Microsoft, où une partie de la plate-forme logicielle est abstraite.
Le gros avantage de l’approche AWS est que l’équipe d’exploitation a la possibilité d’utiliser les mêmes technologies de virtualisation sur la plate-forme d’entreprise et sur la plate-forme Amazon. Ainsi, il est possible de basculer les machines virtuelles d’une plate-forme vers l’autre, si nécessaire. Cette approche est particulièrement pertinente dans le cas suivant : lorsqu’un site web connaît une forte charge seulement un mois par an, on peut l’exploiter pendant onze mois sur la plate-forme d’entreprise, et le basculer pendant le mois de forte charge sur la plate-forme AWS, afin de profiter de sa puissance.
Cette approche donne une grande souplesse aux équipes techniques. De plus, elle leur donne la satisfaction de comprendre et maîtriser la plate-forme PaaS, ce qui, répétons-le encore, va à l’encontre de l’idée de déporter complètement l’exploitation vers un tiers.

BDUWSEZQMY7D