Web2Rules

On nous le promet depuis plus de 10 ans… et le voilà qui arrive enfin dans sa phase de décollage : le web mobile est devenu un vrai marché qui ne va cesser de se renforcer et nous allons décrire ici pourquoi.

Le web mobile semble d’une certaine manière connaître la même histoire que le web de nos vieux desktops avec 10 à 15 ans de retard. Ce n’est bien entendu pas un hasard. En effet, pour qu’un nouveau canal d’information se popularise, plusieurs conditions doivent être remplies :

1 - Construire l’information pour ce canal doit être simple mais souple

Une des raisons du succès de HTML dans les années 90 tient à sa simplicité : il suffit d’écrire un document et d’ajouter quelques balises ici et là pour préciser sa structure. Le protocole Gopher - qui a préexisté au web - avait cette simplicité qui en a fait un des canaux d’information de référence des universités américaines du début des années 90… mais sans avoir la souplesse du couple HTTP/HTML qui l’a rapidement supplanté.

Dès lors, plus il a été simple (et fonctionnel) de créer de l’information sur HTML, plus la domination du web s’est renforcée : avec des outils de création (Front Page, Dreamweaver), des langages de programmation simples (en particulier PHP), les systèmes de gestion de contenus et de manière générale tous les systèmes qui ont abouti au Read/write web d’aujourd’hui… un canal sur lequel, construire l’information est la portée de n’importe qui.

Après quelques années de tâtonnements, le web mobile est en passe d’acquérir cette même qualité. Aux premières années du web mobile qui ont vu s’affronter plusieurs normes (HDML, WML, CHTML puis iMode), le (X)HTML (avec d’éventuelles petites variantes comme le Basic XHTML ou le XHTML mobile profile) impose ses qualités à l’univers smart phone. De plus le parc client a évolué de telle manière (nous y reviendrons) qu’il n’est plus aujourd’hui nécessaire de multiplier les adaptations pour obtenir une site web mobile compatible avec la majorité des clients potentiels.

Donc on peut le dire : produire de l’information pour le web mobile est désormais simple et souple, presque autant que sur le web classique.

2- Le réseau doit être efficace et bon marché

La progression continue de l’usage du web est indissociable de celle des réseaux. Pourrait-on aujourd’hui imaginer qu’il nous faille payer nos connexions internet à la minute de consommation (tout en occupant la ligne téléphonique !) pour des débits misérables ?
C’est pourtant ce qui était demandé il y a encore peu de temps dans l’Internet mobile. Depuis l’arrivée - attendue de longue date - des réseaux 3G, le web mobile connaît la même évolution que le web lors du passage progressif du RTC : la navigation se fait plus fluide et l’on peut flâner en ligne sans trop se poser de question grâce à des forfaits Internet mobile “illimité” abordables.

3- Les systèmes clients doivent être standardisés et répandus

L’évolution du prix et de la qualité des systèmes client (des PC) comptent pour beaucoup dans la consécration du web en tant que média. Pour rappel, un PC de milieu de gamme de 1994 (équipé d’un bon Pentium à 70MHz… alors largement suffisant pour faire fonctionner Mosaic) coûtait autour de ce qui seraient 3000 de nos euros d’aujourd’hui… de quoi réfréner bien des envies de surf sur la toile. Entre temps, les prix ont baissé de manière suffisamment vertigineuse (18% par an en moyenne) pour qu’aujourd’hui  plus de 2 foyers français sur 3 soient équipés d’un ordinateur personnel.

Les smartphones connaissent une trajectoire similaire : le taux d’équipement progresse rapidement grâce à une évolution spectaculaire du rapport performances/prix. Tous les smartphones vendus aujourd’hui disposent d’autre part de navigateurs web suffisamment performants pour gérer des interfaces évoluées (XHTML, multimedia, javascript avancé), ce qui renforce notre point 1 (plus haut) et le point 4 ci-dessous.

4- L’accès à l’information doit être intuitif

La toute-puissance de l’HTML est de mettre l’information souhaitée à la portée d’un clic. Mais l’outil n’aurait sans doute pas eu le même succès sans l’amélioration permanente de la vitesse d’accès à la bonne information : ergonomies améliorées, moteurs de recherche plus pertinents, navigateurs web plus efficaces.

De ce point de vue, l’iphone a incontestablement changé la façon de concevoir la navigation web sur un téléphone et il a probablement constitué le chainon qui manquait jusque là pour faire véritablement décoller le marché (et d’ailleurs 70% des visites web mobiles en France proviennent d’Iphone/Ipod Touch). La navigation tactile et la taille d’écran proposées constituent maintenant des standards pour les concurrents tels les systèmes compatibles Android et autre Winphones.

Le web mobile n’est encore peu de chose (2.5% des visites d’après StatCounter ) mais sa part de marché par rapport à l’ensemble des visites a été multiplié par 4 en un an et demi ! Et au regard des évolutions notées plus haut, ça n’a pas fini de grimper…

 Adam Smith disait en son temps : “À un certain niveau d’accumulation des dettes nationales, il n’y a guère d’exemple, je crois, qu’elles aient été loyalement et complètement payées”. L’histoire sur ce point comme sur bien d’autres n’a cessé de lui donner raison.

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…

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 ?