Web2Rules

Dans ce blog, à la ligne éditoriale assez singulière, il est question pour l’essentiel de technologies web (on y traduisait par exemple “What is web 2.0″ en décembre 2005) et d’économie (on y annonçait le scénario de la crise actuelle dès février 2007). Rares sont les moments où ces deux sujets s’entrechoquent comme dans le post d’aujourd’hui.

L’open-source est un mouvement définitivement lié à l’histoire du web. Le principe est simple : en mettant à disposition des logiciels dont le code source est ouvert et librement redistribuable, on crée un écosystème bien plus riche en innovation qu’avec des logiciels fermés. En effet, tout comme dans le monde scientifique, il est possible aux développeurs de s’appuyer directement sur les travaux de leurs confrères pour créer de nouvelles briques logicielles ou pour améliorer celles qui existent. Ce processus fait potentiellement d’eux -selon l’adage de Newton- “des nains sur des épaules de géants”.

Les technologies web fondatrices (HTTP, HTML) sont ouvertes, et pour cause, elles viennent du CERN, un des temples de la science moderne. Et depuis son acte de naissance, le web n’a cessé de se développer, en largant ses concurrents fermés les uns après les autres, à l’aide de technologies toutes aussi ouvertes : Linux, BSD, Apache, MySQL, PHP, Perl sont autant d’exemples de logiciels qui ont imposé leur empreinte sur le web et contribué à son essor. Un rapide coup d’oeil sur les enquêtes Netcraft montre que c’est toujours le cas.

A l’heure de la crise, le mouvement open-money propose une approche au moins aussi stimulante de l’économie que l’open-source l’est pour le monde du logiciel. L’open money, c’est la “libération” des moyens de paiement. Nos monnaies actuelles sont en effet en un sens des systèmes propriétaires : l’euro et le dollar sont gérés par des banques centrales qui décident de leur mode d’émission tout en se faisant rémunérer pour leur mise à disposition aux banques commerciales. Ces dernières redistribuent ces liquidités (avec effet de levier grâce aux mécanismes de l’argent scriptural et des taux de réserves obligatoires) aux agents économiques. Deux agents économiques voulant commercer avec de l’euro ou du dollar doivent donc nécessairement faire appel à un système commercial extérieur sur lequel ils n’ont aucun contrôle. Par ailleurs, le monopole -de l’euro par exemple- d’une monnaie sur une zone donnée oblige les agents économiques à l’utiliser de fait…à moins de faire du troc !

Le système monétaire classique est donc bel et bien verrouillé comme l’est, dans un autre genre, un logiciel propriétaire. Partant de ce constat, l’open money reprend l’héritage des LETS (Local Exchange Trading Systems, en français SEL pour Systèmes d’échanges locaux) pour proposer des circuits monétaires alternatifs “libres” : il s’agit d’implanter au sein d’une communauté donnée une ou plusieurs monnaies que les membres gèrent directement. Les échanges entre membres ne sont dès lors plus soumis à des conditions extérieures à la communauté telle que la quantité et la qualité de la monnaie en circulation.

Bien entendu, tout comme le développement open-source exige certaines bonnes pratiques pour être efficient, il est nécessaire que ces “monnaies libres” ainsi que les communautés qui les utilisent aient des règles de fonctionnement efficaces. Or, comme le montre le faible développement des LETS jusqu’à présent (malgré un certain âge et un nombre d’initiatives assez important), ces règles sont très loin d’aller de soi… d’où la pertinence des recherches menées par les membres de l’open money sur le sujet !

Le 12 janvier a vu la parution d’un document qui vaut le coup d’oeil et même un peu plus : “les 25 erreurs de programmation les plus dangereuses” qu’on ne trouve pour le moment qu’en VO.

On y trouve en particulier les 3 failles majeures d’un très grand nombre d’applications web :

- Vulnérabilité aux injections SQL

- Vulnérabilité aux attaques de type “Cross Site Request Forgery”

- Vulnérabilité au Cross Site Scripting (attaques XSS)

A l’occasion d’une petite discussion avec François Tonic (rédac chef du magazine Programmez) et quelques collègues sur ce sujet, plusieurs réflexions sur la place de la sécurité dans les projets web nous sont apparues d’une actualité criante :

- les développeurs sont, de manière générale, assez inconscients des problématiques de sécurité posées par leurs applications

- les chefs de projet ayant un profil insuffisamment technique (chose plus que courante sur les projets web…) sont au mieux incapables de contrôler le boulot des développeurs, au pire complètement ignorants de la problématique de la sécurité.

- les clients sont, eux aussi, insuffisamment sensibilisés à la question et tombent souvent des nues quand ils voient apparaître un budget “sécurité” conséquent dans une proposition commerciale

- trop souvent, la sécurité est vue comme une question annexe qui pourra être réglée après coup à l’aide d’un audit et de quelques patches… ce qui est en réalité un très mauvais calcul : la sécurité doit être une problématique quotidienne pour les développeurs, le contrôle a posteriori est moins efficace et plus coûteux

Pas convaincus ? Regardez donc ces quelques exemples :

Une belle attaque CSRF sur le site d’une banque permettant à un attaquant de faire des transferts sur des comptes qui ne lui appartiennent pas

Une petite injection SQL pour hacker un site d’un éditeur d’antivirus

Une faille XSS qui ouvre la voie à une belle opération de phishing sur un système de paiement sécurisé

Toujours pas convaincus ?

Je ne vais pas en rajouter sur ce que chacun pourra constater de lui-même sur Google Chrome, je me contenterai de dire qu’il est désormais mon navigateur par défaut (hors développement). Je ne vais pas non plus parler de la stratégie de Google : la société l’explique assez clairement et j’ai pour ma part la naïveté de la croire.

Je veux vous parler de ce que Chrome a dans le ventre et de pourquoi ça marche si bien… et surtout si vite. Un navigateur web, c’est essentiellement 4 choses :

• un moteur de rendu HTML pour afficher les pages, 
• un moteur d’exécution Javascript,
• une interface utilisateur pour permettre l’accès aux fonctionnalités du navigateur
• une architecture qui fasse tenir le tout debout (y compris les plugins, comme Flash, qui s’y rattachent).

Or, sur chacun de ces points, Google a fait ce qu’il fallait, en appliquant simplement des recettes connues par à peu près tous les développeurs s’intéressant de près aux navigateurs. 

Le moteur HTML utilisé par Google n’est autre que Webkit (bon, le moteur en lui-même s’appelle “Webcore”, mais comme tout le monde dit “Webkit”, je vais pas me la jouer puriste…) . C’est le moteur de rendu de Safari, de l’iPhone, d’Android et de nombreux navigateurs pour mobile. Webkit est simple, rapide et léger : précisément ce que cherchait Google. 

Le moteur Javascript, V8, est lui une nouveauté : son principal atout est la reprise de l’idée de compilation juste-à-temps de Tracemonkey, le moteur utilisé par le futur Firefox 3.1. En d’autres termes, il a une longueur d’avance sur tous les autres (même si avec Brendan Eich, le concepteur de Javascript, chez Mozilla, la partie risque d’être serrée) ! En générant des pseudo-classes pour mieux mutualiser les comportements des objets et en mettant ou point un ramasse-miette efficace, les concepteurs de V8 ont dégagé de nouvelles marges de manoeuvre pour larguer la concurrence dans la course à la performance. 

L’interface utilisateur est dépouillée au maximum, ce qui limite bien entendu la consommation de ressources. De plus, Google a réalisé un kit graphique sur mesure afin de maitriser au mieux cet aspect (plutôt que d’en laisser la responsabilité à Windows ou à un kit graphique tiers comme le fait la majorité la majorité des applications). 

L’architecture qui tient le tout a un principe directeur : compartimentation ! Ce qui dans la BD de présentation de Chrome aux journalistes est résumé sous l’expression “un onglet, un processus” est en réalité plus complexe comme le montre le schéma ci-dessous : 

Pour faire “simple” : un processus-maître coordonne des processus de rendu propre, chacun de ces processus étant lui-même multi-threads.  Cette architecture segmente parfaitement les responsabilités et évite qu’un problème ne bloque l’ensemble de l’application. Elle permet également de paralléliser les traitements ce qui peut s’avérer plus efficace dans certaines configurations.  

Ce même principe de compartimentation est appliqué en matière de plug-in : en utilisant astucieusement le motif de conception “proxy”, Chrome parvient à isoler les plug-ins en dehors des processus de rendu de la page web. Une source de crashes et de ralentissement des plus importantes se trouve fixé par ce tour de passe-passe qui, espérons le, sera repris par la concurrence.

Pour aller plus loin, je vous recommande l’excellente documentation de Chromium (le projet libre derrière Chrome) ou encore un article de votre serviteur à paraître dans le numéro de Programmez qui sortira à la fin du mois… D’ici là, des questions ?

Après quelques mois d’activité intense mais sans publication, ce billet est l’occasion de prendre un peu de recul sur l’actualité de cette belle industrie qu’est le web… recul certainement salvateur à l’heure de proférer analyses et prédictions que les faits prendront, quoi qu’il arrive, un malin plaisir à contredire.Au niveau de l’innovation, qu’a-t-on vu de franchement renversant depuis avril ? Pas grand-chose de mon point de vue, si ce n’est :

• L’accélération de la maturation du web mobile avec bien entendu du nouvel iPhone, mais aussi la multiplication d’offres 3G qui deviennent peu à peu abordables. C’est là un terrain, qui sans être vierge, offre une myriade de surprises fonctionnelles, techniques, dans les usages et les enjeux économiques… de quoi faire retrouver une nouvelle jeunesse au web tant les concepts du web 2.0 (qui n’étaient pourtant pas du buzz) ont été usés et abusés depuis près de 4 ans.
• La redécouverte d’un hack Javascript qui peut s’avérer bien pratique : “window.name”

Au niveau de l’économie et des trop funestes prévisions de votre serviteur, le bilan est là aussi contrasté :

• Comme annoncé en avril, l’inévitable rechute de l’action Google s’est produite, malgré des résultats que beaucoup pourraient envier.
• Les résultats de l’économie américaine prennent une tournure de plus en plus compliquée à analyser : on nous annonce que le PIB a décru au dernier trimestre 2007 (chiffre revu à -0,2% contre +0,6% annoncés initialement) mais que le second trimestre 2008 fait ressortir une belle croissance (+1,9%) alors que l’industrie est au plus bas, que la crise financière est loin d’être finie, que le chômage grimpe encore et que l’immobilier n’a pas encore touché le fond… difficile à comprendre ! Faut-il y voir l’effet des chèques Bush ?

Le constat peut donc paraître morose, mais les temps qui viennent s’annoncent quant à eux passionnants… car lorsqu’une ère semble s’achever, c’est à coup sûr qu’une autre est sur le point de naître !

Le fait marquant du jour, dans notre petite bulle 2.0, est probablement le “gap” de l’action Google qui grimpe de près de 20% suite à des résultats supérieurs aux attentes pour un premier trimestre que l’on prédit difficile pour l’économie américaine. Nous voilà donc maintenant à près de $540, soit loin de ma prédiction de la fourchette 400-450 pour décembre 2008… et malgré cela je persiste dans mes prévisions ! Simple mauvaise foi ? Pas seulement, explications.

- Les fondamentaux de l’action Google restent les mêmes : une action qui ne vaut rien en termes de droits de vote (ce qui devrait entrainer une décote de 20% à 40% par rapport à une action classique), et une action qui ne vaut rien en dividende. Tout ce qu’on peut faire à l’heure sur l’action Google, c’est spéculer sur la croissance de la société et des dividendes qu’elle offrira à l’avenir… alors spéculons !

- Le PER de 2008 d’après les données actuelles seraient de 539,9 (valeur de l’action le 19/04) sur 19,90 (prévision de bénéfice net par action 2008 réajustée d’UBS) soit : 27,1. Ce n’est certes pas aussi monstrueux que les niveaux touchés dans le délire de l’été 2007, mais ça reste très important. Et c’est surtout trop, étant donné les fondamentaux exposés plus haut. A moins que…

- …à moins que la croissance de la société et de ses bénéfices soient plus qu’exceptionnels. Exceptionnels, les résultats et la croissance de Google le sont, c’est incontestable. Mais est-ce assez pour justifier un tel PER ? Observons donc la croissance de Google et essayons d’en tirer quelques prévisions raisonnables à 3 ans.

Commençons par les revenus de Google, leur progression depuis 2002 forme une figure remarquable : en passant de 409% à 42% de croissance annuelle, ils montrent un relatif ralentissement même si ce chiffre reste excellent… si l’on développe un peu la courbe de l’évolution des revenus selon la tendance qui se dessine depuis quelques années, on obtiendrait pour 2011 environ 40 milliards de dollars. Le bénéfice net de Google semblant se stabiliser au fil des années à 25% des revenus, on obtiendrait donc 10 milliard de dollars à partager entre 330 millions d’actions (hytpothèse moyenne : on en est aujourd’hui à 315) soit environ $30 par action. En distribuant alors 25% des bénéfices (cas courant dans le secteur IT), le dividende par action serait de $7,5. Avec un cours compris entre 400 et 600, le rendement de l’action serait alors quelque part entre 1,25% et 1,88%. Quand on sait qu’IBM est à 1,28, Microsoft à 1,56 ou Intel à 2,12, c’est bien quelque part dans cette zone que nous devrions être.

L’achat Google est donc un pari très risqué à moyen terme pour un acheteur américain… mais c’est encore plus catastrophique pour l’investisseur européen ! En effet, ramenée en euros la croissance de Google n’a plus du tout le même aspect.

Conclusion : même si Google peut devenir un jour une valeur défensive intéressante dans une économie américaine où un grand nombre de valeurs risquent de beaucoup souffrir, le cours reste encore très supérieur aux fondamentaux de l’action. Autant de raison de maintenir mon pronostic (fait alors que le cours était à 702) de 400-450 pour décembre.