Or, après la crise immobilière, après la crise bancaire, après la crise économique, voici semble-t-il venu le temps de la crise de la dette publique. C’est aujourd’hui le cas grec qui fait la une, mais nombre d’états supposés plus respectables sont dans de bien pires situations : qui parlait de la dette islandaise avant que son château de cartes bancaire ne s’effondre, qui rappelle aujourd’hui que la dette publique japonaise représente plus de 2 fois son PIB, qui sera prêt demain à remettre en cause l’absurde note AAA de la dette américaine ?

Ce spectre de la dette qui pèse sur nous depuis si longtemps a pourtant plusieurs remèdes historiques, très rarement rappelés par les économistes, parmi lesquels il faudra choisir

1- L’inflation

Plus l’inflation s’élève, plus une dette contractée plus tôt devient simple à rembourser. Avec une inflation de 10%, des revenus de 1000€ passe à 1100€ et des dépenses de 900€ passent à 990€. Si vous deviez rembourser 100€ par mois à votre banque, il vous restera 10€, là où il nous vous restait rien auparavant.

Pour un état, c’est pareil : l’inflation diminue le poids relatif des dettes antérieures (ex : les Etats-Unis en 1947). Certaines politiques économiques et monétaires peuvent largement influer sur cette inflation. Plusieurs économistes comme Jean-Paul Fitoussi y pensent d’ailleurs de plus en plus fort.

Le problème de l’inflation, c’est quand on ne la maîtrise plus : les gens perdent confiance dans la valeur de la monnaie, ce qui transforme l’inflation en hyperinflation, ruine les épargnants et finit par bloquer complètement l’économie du pays (cf. Zimbabwe).

2- La planche à billets

C’est une solution simple : l’état fait imprimer les billets dont il a besoin pour payer ses créanciers. On parle de “monétisation” de la dette (la dette est remplacée par de la monnaie).

Plusieurs problèmes néanmoins à cette méthode radicale (mais utilisée en France pendant les 30 glorieuses) :

- créer de la monnaie sans création de valeur peut provoquer une accélération non maîtrisée de l’inflation (cf. plus haut les conséquences)

- si vous vous êtes endettés en dollars, imprimer des roubles ne vous servira à rien.

- les créanciers ont l’impression de se faire rouler, ils ont un peu raison

- cela dévalue mécaniquement la valeur de votre monnaie par rapport aux autres monnaies… pire, la valeur de votre monnaie peut devenir ridiculement basse sur les marchés internationaux parce qu’elle est alors attaquée par les investisseurs/spéculateurs qui perdent confiance dans votre manière de gérer votre monnaie.

- si vous êtes un pays de la zone euro, vous n’avez ni le pouvoir ni le droit de le faire

3- La renégociation de la dette

Cela consiste à aller voir ses créanciers et à leur expliquer que “bon voilà on ne pourra pas  payer, par contre comme on est sympa on veut bien payer une partie de ce qu’on doit”. Ca ressemble un peu à une faillite, ça ne fait pas plaisir aux créanciers en question, mais ça marche (cf. le cas argentin).

4- L’excédent budgétaire

Une des rares méthodes envisagées par les économistes médiatisés… Si l’état dépense moins qu’il ne gagne, sa dette diminue. Pour passer d’un état de déficit (qui est la règle actuelle pour la plupart des états) à un état d’excédent, il faut réduire les dépenses et/ou augmenter les impôts… ce qui provoque mécaniquement moins de croissance (puisque moins de dépenses) et souvent une rechute pour des pays en sortie de crise.

Autant le dire tout de suite, cette méthode seule n’a aucune chance de fonctionner étant donnée les niveaux d’endettement et de croissance de la plupart des pays occidentaux.

5-Le miracle

Il est possible que certains pays s’en sortent par des miracles plus ou moins provoqués : mettre la main sur des réserves de pétrole insoupçonnées (cf. Norvège, Canada), un miracle économique menant à un fort taux de croissance (diminuant le poids relatif de la dette), l’appropriation par l’état de ressources qui ne lui appartenaient pas jusque là (nationalisation forcée, guerre)…

Une fois que l’on a pris conscience de ces options et de leurs probabilités respectives, l’on comprend que les années qui viennent nous promettent bien plus de surprises encore que celles que nous venons de vivre. Mais j’y reviendrai probablement.

N’est pas geek qui veut. Je travaille au quotidien avec de véritables specimens de geek bien trempés, et je peux dire que, malheureusement, je ne suis pas l’un d’entre eux. Et je le dis d’autant plus sincèrement que j’ai une véritable admiration pour les talents des vrais spécialistes des techniques du web moderne.

Attention, je ne vous parle pas de passionnés de warcraft, de tweeter ou de facebook, je vous parle de ceux qui maîtrisent vraiment ces technos plus ou moins bancales qui composent la toile d’aujourd’hui. Parce que quand on y regarde de plus près, tout cela n’a pas la rationnalité à laquelle pourraient s’attendre les gens s’intéressant au web sans jamais y mettre vraiment les mains :

- HTML est un langage permissif, mal structuré, parfois incohérent : c’est pourtant bien sur cette base que sont construites toutes les pages web. Il m’arrive même de souhaiter l’arrivée de sa prochaine version.

- Javascript est un langage faiblement typé, qui ne connaît pas la notion de classe et qui n’est pas supporté de la même manière par tous les navigateurs… et pourtant, on se prend parfois à imaginer que c’est le nouveau langage de référence !

- Les CSS sont un véritable cauchemar dès lors que l’on souhaite faire fonctionner quelque chose correctement sur IE6 (voir à ce sujet un article de votre serviteur à paraître dans le prochain programmez… et attendant ce site qui peut s’avérer des plus utiles)

- L’administration système relève parfois de la magie noire, surtout quand on creuse un peu trop. Heureusement, Sébastien Le Ray, collègue qui se surnomme modestement “Dieu”, nous fait part du fruit de ses expériences à mi-chemin entre science et spiritisme. Au programme : administration Unix, Apache, PostgreSQL, MySQL et PHP.

A quel numéro de version pourra-t-on considérer le web comme étant stable ? Sûrement pas la 2.0…

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 !

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 ?

• 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 ?

• 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 !

- 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.

Toutes ces technos sont bien entendu une formidable opportunité pour les développeurs web mais elles sont autant de nouveaux casse-têtes à affronter : comment donner à nos utilisateurs ces possibilités d’offline au plus grand nombre sans attendre ? Sweetch est une bibliothèque Javascript open-source, s’appuyant sur Dojo, qui leur offre une solution élégante à ce problème : compatible avec l’immense majorité des configurations clientes tout en tirant partie au maximum des capacités de chacune d’entre elles, Sweetch rend possible maintenant ce qu’HTML5 promet pour dans 3 ans.

Et bien qu’encore en développement, Sweetch est d’ors et déjà téléchargeable et testable…

Laissez-nous vos impressions !

- Google Gears débarque sur la version mobile d’internet explorer… et étend ainsi le champ des possibles de l’offline mais aussi et surtout des application web mobiles

- Adobe sort enfin la version de Air qui nous était promise pour les plates-formes Linux

-  Internet Explorer 8 intègre le “Dom Storage” (les “supers-cookies” que Firefox 2 proposait déjà) selon la spécification HTML5

- Safari 3.1 embarque une base SQLite pour permettre du stockage hors ligne selon, là encore, la future norme HTML5.

- Des bruits circulent sur l’intégration d’un tel système au sein d’une future version de Silverlight 2

- Firefox 3, faute d’implémenter pour le moment l’API HTML5 de stockage SQL hors ligne qu’on pensait voir arriver rapidement, intègre par ailleurs de nombreuses caractéristiques du chapitre “offline applications” de la spécification.

- Google Docs se voit renforcé de possibilités offline grâce à Google Gears : ouf, on n’y croyait plus !

C’est désormais quasi-certain pour le web offline : 2007 était l’année des expérimentations, 2008 est celle du décollage, 2009 sera celle de la croissance et 2010, celle de la maturité. Entre temps, cela laisse pas mal de travail pour les développeurs et d’espoirs pour des utilisateurs qui devraient bientôt être enthousiastes !

- le futur de Javascript dans le numéro de mars (N°106)

- HTML5, le langage qui va changer le visage du web dans le numéro d’avril (N°107)