Nicolas Guillaume

Que fait Google avec le Native Client ?

Le Native Client de Google fait beaucoup parler de lui. Le sujet est complexe à appréhender et prompt à éveiller les polémiques. Frederic Cavazza en a fait les frais dans un récent billet. Pour avoir affirmé que le C++ était sur le retour, il s'est attiré les foudres de ses contempteurs.

La virulence de la polémique et le manque d'ouverture d'esprit de ses contradicteurs m'a surpris (et je ne suis pas le seul comme l'atteste cet autre billet d'une personne peu suspecte de son niveau de compréhension du C++).

Car il s'agit bien de cela, les arguments avancés ne relèvent pas de l'échange intellectuel entre personnes soutenant des opinions différentes mais plutôt de l'excommunication religieuse pour éteindre le débat dans le style "tu n'es pas qualifié pour parler de ces choses donc tu racontes n'importe quoi. Tu aurais mieux fait de ne jamais discuter de ces choses qui sont inaccessibles à ta compréhension".

Cela ne peut être ma conception du débat surtout en informatique où la multiplication des technologies crée potentiellement autant de chapelles où s'enfermer.

Revenons au fond du débat : quelles questions se pose t-on dans cette histoire ?

• Quelles sont les technologies utilisées par les développeurs et notamment quelle est l’importance du C++ ?
• Que peut-on faire avec du développement C++ natif dans un navigateur (c'est le concept du Native Client) ?

 

La question sur les technologies utilisées par les développeurs est probablement une des plus difficile à répondre et elle ne se réduit certainement pas à un simple tableau des citations des langages de développement sur internet.

La vraie question à se poser c'est quel type de développeur utilise quelle technologie pour quel type de développement ?

Je ne prétends pas répondre à cette question mais plutôt à essayer d'apporter des éléments de réponse :

• Les développeurs "traditionnels" sont employés par les éditeurs de progiciels, les SSII et les équipes internes de développement d'entreprise et utilisant des langages comme C++, C#/.NET ou Java.
• Le monde du développement C++ ce sont les applications clientes riches, un grand nombre de progiciels développés par des éditeurs, les applications embarquées, les applications 3D que ce soient la modélisation, la conception ou les jeux et de manière plus générale toutes les applications qui ont besoin de performances et j'en oublie probablement.
• Les applications métier spécifiques ou les progiciels de gestion et métier développés à partir de couches préexistantes constituent l'univers par excellence des langages ayant un plus haut niveau d'abstraction tel que .NET ou Java. On trouve aussi beaucoup d'applications clientes développées en .NET (ou en mix .NET/C++). Par contre Java est très peu utilisé sur les applications clientes "desktop" (par opposition au développement serveur).

A partir de là, les choses deviennent plus compliquées.

• Il a d'abord le modèle de développement web qui s'est généralisé et pas seulement dans les services grand public mais aussi comme couche de présentation des logiciels métier tant progicialisés que spécifiques. Ce modèle a été "assimilé" par les développeurs “traditionnels” mais il a aussi conduit au développement d'une nouvelle génération de développeurs. Celle à laquelle fait référence Frederic Cavazza. Des développeurs utilisant des langages de script (et non plus des langages objet) nécessitant des niveaux de compétences moindres tels que Php, Javascript, ASP, Perl,…Des développeurs présents dans les sociétés listées précédemment mais aussi dans les "web agencies", dans de nombreuses startups (et leurs écosystèmes comme par exemple Facebook) mais aussi dans les populations des développeurs professionnels individuels et des développeurs non ou semi/professionnels ou partiellement développeurs (par exemple un web designer qui fait du développement mais dont ce n'est pas l'activité première).
• En parallèle le "modèle de développement web" (si tant est qu'on peut l'appeler comme cela) s'est aussi développé parmi les applications d'entreprises non critiques (les applications "quick & dirty" pourrais-je dire) telles que les applications départementales, les applications collaboratives (formulaires, workflow simples, portails,…) et les applications web2.0 (orientées interactions avec les utilisateurs finaux, …) entrainant avec elles de nouvelles populations de développeurs.
• Il y a les "cross-over", les technologies qui cherchent à hybrider l'agilité du développement web et l'industrialisation du développement traditionnel . On parle ici à la fois de langage (Ruby, Python mais aussi .NET qui supporte le modèle Agile), de méthodes, de "lightweight framework", de composition de technologies au sien d'une même application…
• Et puis il y a les technologies RIA - Rich Internet Application - (Silverlight, Flex) qui renouvellent l'approche de la couche de présentation et de l'architecture des applications en profitant des avantages des modèles de développements traditionnels et du modèle web.
• Sans oublier, toutes les technologies "legacy" (Cobol et autres sur mainframe et mini), NSDK, Delphi, Visual Basic, etc… qui sont loin d'être négligeables (la population des développeurs Visual Basic est probablement une des plus importante).

Les technologies de développement ne sont pas exclusives entre elles mais ça ne marche pas dans tous les sens. Les développeurs C++ peuvent facilement utiliser des technologies de type web / RIA (comme c'est notamment le cas des développeurs java qui utilisent majoritairement Flex pour des développements d'interfaces riches) mais le contraire n'est pas vrai. Un développeur web aura du mal à passer au C++.

Au final, on peut s'avancer à affirmer que la population des développeurs C++ ne parait pas être la plus "leverageable" pour cibler le développement d'une nouvelle génération d'application dans le navigateur (c'était je pense ce que voulais dire Frederic Cavazza dans son billet).

Revenons sur le Native Client de Google.

Quel est le problème ?

• La stratégie de Google est axée sur le navigateur comme interface universelle d'accès aux informations et aux applications.
• Google a misé sur le javascript/ajax pour le développement de ses interfaces, choix logique dans le souci d'accessibilité et de simplicité que Google veut imposer à ses interfaces. Avec GWT (Google Web Toolkit qui permet de développer en java des applications javascript) Google a porté le modèle aussi loin qu'il pouvait l'être.
• Avec Gears, Google a introduit une technologie pour parer à un premier problème de l'utilisation en mode déconnecté (car la connexion généralisée et systématisée, on nous la promet depuis toujours, on continue de nous la promettre mais on l'attend toujours et on va l'attendre encore longtemps).
• Mais il y a un autre problème, c'est la limitation intrinsèque du modèle javascript/ajax pour développer des applications avancées, notamment dans leur composante graphique. Il y a une solution à cela; ce sont les technologies RIA telles que Silverlight de Microsoft ou Flash/Flex d'Adobe. Google ne s'est pas engagé dans cette voie jusqu'à présent considérant que le niveau de complexité de ses applications ne nécessitaient pas encore une évolution de ce type et ne voulant probablement pas se lier à une technologies maîtrisée par un tiers.

La voie qu'a choisi Google avec le Native Client est différente des RIA. Il s'agit de faire tourner des applicatives natives x86 (l’architecture d’Intel)développées et compilées en C++ directement dans le navigateur indépendamment de l'OS.

En quoi le Native Client est-il différent des RIA ?

• Le Native Client va à l'encontre des évolutions récentes vers des modèles de développement de plus en plus abstraits des couches basses (Silverlight, Flex) et des langages dynamiques (Ruby, Php, Python,…). Alors que les RIA évoluent vers la prise en compte des langages dynamiques (introduction d'une Dynamic Language Runtime dans Silverlight supportant Python et Ruby), Google prend le chemin inverse vers un langage plus proche des couches basses en profitant de la généralisation des architectures X86 (PC, Mac, Linux).
• La conséquence de cela, c'est que le cycle de développement ne bénéficie pas du niveau d'outillage (Visual Studio/Expression Blend, Flash/Flash Catalyst, XAML vs FXG/MXML) et de la productivité des développements offerts par les RIA.
• Les développeurs ciblés sont les développeurs C++ dont nous avons vu précédemment qu'ils ne constituaient pas l'écosystème le plus porteur pour développer les futures applications internet (à tout le moins en nombre).
• Le patrimoine applicatif réutilisable ne semble pas non plus aligné avec les objectifs recherchés. Autant il peut y en avoir dans la partie applicative, autant la partie interface client présente un faible potentiel. Le choix d'une démonstration de Quake est très parlant. Les développements 3D sont les seuls développements clients sur lesquels le C++ règne en maître (à aujourd'hui car les RIA (Silverlight et Flash) montent en puissance sur la 3D et l'accélération matérielle).

Au final, je ne vois pas très bien qu'elle est l'idée qu'à Google derrière la tête avec le Native Client et je partage la perplexité de nombreux commentateurs.

La seule application intéressante que j’entrevois serait de faire tourner nativement dans le navigateur Google Earth en 3D avec des applications tierces (développées en C++) orientées 3D/modélisation directement intégrées. Ce qui n'est déjà pas mal (aujourd'hui ce sont des pluggins non extensibles différents en fonction des navigateurs et OS).

Une autre constatation qui apparait en contrepoint, c'est l'échec de Java comme technologie de développement universelle (que n’utilise pas Google) :

• Java n'est pas utilisé pour les applications clientes riches (elles sont développées en C++ ou en .NET)
• Java n'est pas une technologie RIA (les développeurs java qui développent des RIA utilisent Flex et non pas Java FX dont le niveau de maturité est bien inférieur)
• Java ne couvre pas bien les développements "lightweight"
• Java couvre bien les applications mobiles "de bas de gamme" (je qualifie ainsi les terminaux à petits écrans et faibles puissances de traitement) notamment pour les jeux mais il n'a pas permis de résoudre le problème de l'hétérogénéité des terminaux et il est en perte de vitesse sur les applications mobiles "haut de gamme" (terminaux à grands écrans et grande puissance de traitement s’apparentant à des ordinateurs tels que l'iPhone, l'HTC HD ou le Google G1 – le meilleur est à venir dans ce domaine).

A contrario :

• .NET est utilisé pour le développement des applications clientes riches
• Il est aussi utilisé pour les développements server comme Java
• Il est adapté pour les développements "lightweight" où l'approche de plateforme applicative intégrée de Microsoft le complète parfaitement
• Avec Silverlight, il couvre les RIA
• Avec Windows Mobile (.NET Compact Framework) et Silverlight Mobile, il couvre les applications mobiles "haut de gamme" qui vont se développer.

Mais je comprends que ces arguments ne soient pas très entendus par Google…

Important mais non urgent

Gabor Cselle est l’ancien Vice-President Engineering de Xobni. La startup qui développe une extension Outlook permettant d’avoir une vision centrée sur l’individu de sa messagerie (c’est à dire d’avoir la photo –extraite de Linkedin- de son correspondant, des statistiques sur l’activité que l’on a avec lui, les messages et pièces-jointes que l’on a échangé avec lui, etc). Xobni continue, avec succès, de développer son service qui permet maintenant d’avoir cette vision de ses communications mails avec ses correspondants de manière transversale à Outlook et Yahoo!Mail avec des données de Facebook et de la base d’entreprises Hoover (www.xobni.com).

 

Gabor vient de lancer sa nouvelle startup, toujours dans le même domaine, et j’attends avec impatience de voir ce qui va en sortir.

Il a publié un billet des plus intéressant sur les modèles de gestion du mail.

Le modèle le plus répandu est la matrice Importante / Urgence avec comme règle : faites d’abord ce qui est important et urgent !

Ce qui n’est pas important est en fait relativement facile à gérer car il suffit d’identifier que ce n’est pas important (notamment par rapport à l’expéditeur) et de les router vers des containeurs ou des vues que l’on pourra consulter lorsque l’on disposera du temps ou de l’envie de le faire.

Le vrai problème, comme l’écrit Gabor, c’est de gérer ce qui est important et non urgent. Pourquoi ? Parce que l’inflation des mails rend très difficile de prioriser et gérer a posteriori un point important mais non urgent. D’ailleurs, la manière de résoudre ce problème la plus communément adoptée, c’est de considérer tout ce qui est important comme urgent et devant être traité sur le champ. Car nous savons bien que ce qui n’est pas traité immédiatement, a beaucoup de chance de ne jamais l’être….jusqu’à ce que l’on reçoive un mail de rappel (car la signification du mail a changée comme je l’ai expliqué dans un précédent billet, l’envoi d’un mail ne vaut plus acquittement).

Une règle de bonne gestion du mail était de ne pas traiter ses messages au fil de l’eau pour ne pas être esclave de l’immédiateté et se laisser le temps de la réflexion. Elle n’est plus d’actualité. Ce qui n’est pas traité, n’est jamais traité et n’est plus maîtrisé par le destinataire du mail. Seul un nouveau rappel de l’expéditeur réintroduit dans le fil de l’eau peut réinitialiser le traitement.

Les outils de mails ne permettent pas de conserver des points important en attente, de tracer des points à suivre, ni de gérer des étapes d’avancement (des workflows unitaires ou multiples regroupant les messages liées à une même activité).

En même temps, je continue à penser, comme je l’ai écrit précédemment, que ce problème n’est pas perçu par le management ou du moins pas perçu comme un problème de management, qu’il ressort plutôt de la sphère de l’organisation individuelle et que l’entreprise n’a pas à s’en préoccuper.

On disait cela de la gestion de la relation client avant d’en comprendre les enjeux pour l’entreprise….