De l’idée vers la réalisation versus la neutralité du NET

Supposons maintenant qu’une startup nommé toto (je vais l’appeler comme cela) arrive avec un idée super géniale, que tout le monde veut utiliser, mais qui bouffe vraiment beaucoup de bande passante. Son fournisseur coupe sa bande passante et lui empêche de bien réaliser son idée. (Et si on est parano, peut même lui voler son idée, on parlera pas de brevet ici)

Est-ce un vrai danger ou est-ce que je suis dans le domaine de la science fiction? Après, faut que quelqu’un paie pour la bande passante. Avoir beaucoup de bande passante c’est d’avoir la capacité de réaliser n’est-ce pas ? Une idée c’est bien beau, mais sans la capacité de réaliser ce n’est pas grand chose.

Donner une chance égale à tous au niveau des infrastructures pour avoir une meilleure capacité de réalisation et d’innovation, c’est je pense une chose importante.

Par contre est-ce qu’il faut aussi être capable d’empêcher ceux qui bouffent toute la bande passante sans innovation (je ne ferais pas de dessin ici) et qui par leur activité, diminuent la capacité d’innovation des autres?

En gros, en neutralité du NET, il y en aura pas de facile et les enjeux sont pas mal plus gros que le petit exemple généraliste et mal documenté que je viens d’énoncer.

Le vieux Web

Ça fait un bout de temps que je voulais écrire ce billet. Je sentais tranquillement pas vite qui IE 6 allait s’en aller. Ne vous détrompez pas, je suis tout aussi heureux et content que tous les autres développeurs Web qu’il tire finalement sa révérence. C’est juste qu’il me prend un petit coup de nostalgie, comme ça. Faut dire aussi que je travaille souvent pour des intranets avec des outils qui sont habitués de générer du code spécifiquement pour IE 6 que je risque d’avoir encore à supporter pendant quelques années. Je suis aussi de ceux qui ont supporté Netscape 4 un peu trop longtemps.

Comme je spécifiais dans mon dernier billet sur le sujet, arrêter de supporter IE6 veut aussi dire laisser tomber toute une catégorie de vieux ordinateurs (disons 10 ans et plus) qui dans plusieurs cas fonctionnent encore très bien. Je pense entre autres à mes deux Pentium et mon vieux Pentium II que j’utilise encore une fois de temps en temps.

Il est vrai que je n’utilise pas souvent ces machines, mais il m’arrive encore de jouer dessus à Baldur’s Gate et Icewind Dale (deux très bon jeux, ma blonde et moi jouions à ces jeux en réseaux quand elle était enceinte de notre fille, les premières chicanes de couples, qui allait avoir le trésor héhé… ma fille joue à ces jeux aujourd’hui et elle apprend l’anglais avec… désolé de cet aparté, je trouvais l’anecdote cute). Et c’est pratique de partir Internet Explorer 6 sur ces machines pour retrouver les walkthrough de ces vieux jeux qui fonctionnent encore sur les vieux navigateurs (peut-être même Netscape, je dois avoir Netscape 4 Communicator qui traîne quelque part sur cette machine, peut-être même Netscape 2 Gold et Netscape 3). C’est IE 6 qui marche le mieux sur ces vieux ordis, et cela me fait penser qu’il y a encore une tonne de vieux contenus sur le Web qui sont encore utilisables et qui s’adresse à ces temps pas si lointain que cela finalement. J’espère que ce vieux Web ne disparaîtra pas et j’espère que je pourrai continuer de naviguer cette section du Web avec mes vieux ordinateurs. Il y a toujours les archives Internet, mais c’est encore mieux si le contenu original existe encore. Ce genre de contenu, ce n’est pas à mon avis important de le mettre à jour pour les nouveaux navigateurs, parce que après tout, il y a de bonnes chances qu’un walkthrough sur un vieux jeu soit accédé par des machines de la même époque (ou des émulateurs).

Ceci dit, j’aimerais que vous me donniez dans les commentaires des exemples du vieux sites Web qui sont encore utiles et que vous aimeriez qui restent en ligne, et ce en HTML 3.2. Pour ma part, toutes les critiques et informations sur de vieux jeux sont encore utiles aujourd’hui. Il y a aussi de vieux sites sur des séries télévisées oubliées depuis longtemps qui contiennent des informations amusantes qu’on ne retrouve pas nécessairement sur wikipédia (d’ailleurs, celui-ci remplace un peu le vieux Web, c’est un autre exemple de site, qui devrait à mon avis continuer de supporter IE 6 pendant un bon bout de temps).

Quand devrait-on laisser complètement tomber Internet Explorer 6 et pourquoi ?

Avec l’annonce que Youtube va bientôt ne plus supporter Internet Explorer 6 (cf http://www.techcrunch.com/2009/07/14/youtube-will-be-next-to-kiss-ie6-support-goodbye/ ), nous pouvons que nous réjouir du fait que pour bientôt, nous non plus, dans nos développement Web, n’aurons plus à faire des entourloupettes dans notre code pour satisfaire ce dinosaure.

Nous ne sommes toutefois pas tous des Youtube et notre clientèle n’est pas nécessairement encore prête au Web 2.0 et au vidéo en ligne. En effet, couper Internet Explorer 6 coupe aussi toute une génération de vieux ordinateurs, qui fonctionnent encore bien et peuvent très bien aussi naviguer sur le Web pour le contenu statique et le HTML 3.2. Je pense en particulier à mon Pentium II que j’ai acheté en 1996, pour qui Firefox et même Opera sont plus lourd que Internet Explorer. Il y a certainement des personnes qui ne peuvent se permettre d’acheter une machine plus récente et pour qui Internet Explorer 6 est la meilleure solution puisque c’est ce qui est le plus performant. Toutes ces machines peuvent aussi être recyclées et être réutilisables par des gens moins fortunés. Internet Explorer 6 est encore ce qu’il y a de plus performant pour eux (pour les pages simples on s’entends). N’allez pas me dire de mettre Ubuntu et Firefox sur ces machines, je suis presque prêt à parier que ce sera beaucoup moins performant pour les sites simples.

Il y a aussi tout ces pauvres gens qui en entreprise sont encore obligés d’utiliser de vieilles applications d’entreprise (en fait même des nouvelles) qui ne fonctionnent que sur Internet Explorer 6.

Si ces deux publics font partis de votre public cible, il n’est malheureusement pas le temps pour vous de laisser tomber IE6. Youtube est un cas spécial : Il est habituellement bloqué en entreprise (la plus grande partie des IE6) et ses vidéos sont trop lourds pour les vieilles machines.

Il y a aussi des sites dont la clientèle risque d’utiliser Internet Explorer 6 plus longtemps. En premier les moteurs de recherches, les sites de résultats de loteries, météo, nouvelles, peut-être aussi les petits sites de commerces et les sites dont le sujet est technologiquement vieux (je vais vous en parler dans un autre billets).

Pour un site de nouvelles, j’aurais tendance à proposer une page simple sans visuel, avec quelques grands titres. Il est peut probable que les utilisateurs en veulent plus. Un site comme par exemple celui des résultats de Loto-Québec diffusion.loto-quebec.com(*), est un bon exemple de site devrait marcher pour des vieux navigateurs. Étant donné le Web 2.0, il y a plusieurs manières de diffuser son contenu, mais le cœur de ce celui-ci devrait fonctionner pour le plus grand nombre de personnes possibles, et cela veux dire supporter les très vieux navigateur. Il y a 3 ou 4 ans, ça voulait dire supporter IE5 et IE5.5, il y 8-9 ans, c’était Netscape 4, et aujourd’hui et pour encore 3 4 ans, ce sera Internet Explorer 6. Comme j’ai toujours conseillé de faire un site accessible au Web mobile et aux personnes handicapé (je n’utilise pas encore le bon terme, désolé), je vais conseiller de faire des sites qui peuvent fonctionner minimalement avec les vieilles plate-formes. On pourra mettre dans ce coffre bientôt le vénérable, mais détesté Internet Explorer 6. Le grand champion de la guerre des navigateurs se retire tranquillement. Nous pourrons faire maintenant des applications plus évolués plus facilement. Avec probablement un petit if IE 6 5.5 5 +N4 un petit bloc de HTML 3.2 avec le contenu de base pour les quelques anachroniques.

L’autre gros bloc qui ne pourra pas laisser tomber IE 6 pour un bout de temps ce sont les applications d’entreprises. Les Webpshere Portal, Sharepoint, SAP et autre ERP et Portails de ce monde. Tout ce qui utilise JSF 1.1, .NET 1 et 2. Les vieux contrôle ActiveX et tout le tralala.

Vous travaillez dans un intranet pour une grande entreprise : prenez votre mal en patience. Vous voulez que votre application s’intègre à ces systèmes, IE 6 (et peut être IE7) est votre plus important client. (En fait dans une situation comme cela, Silverlight risque d’être votre sauveur plus qu’autre chose). Vous voulez faire les mêmes applications Entreprise 2.0 sous ces plates-formes, vous allez souffrir. Personnellement, je pense qu’en entreprise, Silverlight va prendre une bonne partie du marché Web 2.0esque, il marchera dans IE6 (activex les amis) et va être plus facile à programmer pour et visuellement ce sera beau comme du Flash. Qu’est-ce que vous voulez de plus.

Pour les autres, je pense que ce sera le temps de regarder dans vos logs et d’attendre le moment fatidique du 2-3% d’utilisateurs. Si votre site est suffisamment statique, un support de type dégradation harmonieuse est de mise. Pour les sites dynamique, les fonctions plus avancés ne seront plus disponibles aux vieux navigateurs, pour les même raisons que Youtube. Il suffira pour vous de décider du quel côté de la barrière votre site se situe. Web 2.0, Web statique ou Entreprise 2.0 (grosse ou PME ou startup).

Pour un site comme le mien… je dirais que je vais m’assurer que le minimum marche avec IE6, mais sans plus. C’est ce que je fais depuis…offf 2006…

Disclaimer : J’ai déjà travaillé sur le site des résultats de Loto-Québec, et j’en étais même l’un des développeurs principaux il y a de ça un bon 8-9 ans, avant que je me mette vraiment au standards Web. Au moment d’écrire ces lignes, c’est le plus vieux site sur lequel j’ai travaillé qui est encore en ligne, le cœur de ce site n’a pas vraiment changé depuis circa 2001, 2002, quoi ? ce site marche et il n’est pas tuable (sauf peut-être par un gros Flash, mais bon. Je suis fier de ce site pareil… le HTML n’est plus vraiment le même par contre.

De la problématique des codecs supportés ou encouragés par HTML 5

Parfois nous avons des opinions arrêtés qui à première vue semble être dans l’intérêt du Web, de son ouverture et de son interopérabilité, mais qui après réflexion pourraient en réalité causer le contraire.

En fait, je crois que la plus grande problématique pour supporter ogg theora dans les navigateurs est le fait qu’il n’est pas supporté au niveau du matériel des cartes graphiques. En effet, la plupart des cartes graphiques de NVIDIA et AMD supportent le H.264 de façon native. Ce qui ferait par exemple qu’un vidéo nécessitera beaucoup moins de puissance machine s’il utilise H.264 que s’il utilise ogg theora. Je suis loin de bien connaître les codecs vidéos; je n’ai aucune idée s’il serait simple d’implémenter ogg theora nativement au niveau du matériel, et encore moins combien de temps cela prendrait (et au niveau technique, et au niveau légal, j’ai peur que ce dernier serait encore plus long).

En fait, la problématique est encore pire pour les téléphones cellulaires qui sont limités en puissance. Aussi, imaginons un instant que nous regardions un vidéo en streaming haute définition sur disons un Mac Mini (je le prends en exemple, puisque j’en ai un plogué sur ma télé, avec lequel j’écoute des émissions en 720p (oui oui, légalement)). Nous utilisons un site avec Safari et H.264 et tout est rapide, avec un autre Firefox et ogg theora. Devinez avec lequel « l’expérience » sera la meilleure? La conséquence de tout cela serait un renforcement de H.264 et de Safari dans l’industrie. Les opérateurs de site Web choisiraient H.264 puisque c’est plus performant et les utilisateurs finaux Safari (dans le cas d’un Mac) pour les mêmes raisons. On revient à pire que la case départ et personne ne supporte le standard.

Est-ce que des solutions existent ? D’un côté, encourager fortement les revendeurs de matériel graphique à supporter ogg theora, de l’autre encourager les consortiums derrière H.264 d’offrir une licence ouverte ou libre aux revendeurs de navigateurs.

Si HTML 5 impose ogg theora comme codec de base pour la balise video, est-ce que cela encouragera à ce que celui-ci soit bien supporté (matériel et logiciel) ou est-ce que cela pourrait avoir l’effet contraire et isoler les standards ouverts et les navigateurs ouverts / libre / de petit marché ? Est-ce que de ne rien faire est mieux ? Qu’en pensez-vous ? Par principe, HTML 5 devrait imposer un standard ouvert et libre pour la vidéo, par contre si les conséquences vont à l’encontre de l’ouverture, nous ne sommes pas plus avancés.

Est-ce que dans cette situation, l’utilisation de Flash est la meilleure solution ? En fait le plugiciel Flash ne favorisera pas aucun navigateur en particulier, et potentiellement aucune plate forme (quoi que en ce moment, Flash marche mieux sur Windows, ensuite Mac et pour finir GNU/Linux). Il pourra utiliser l’accélération matérielle et payer pour les brevets de codecs. Est-ce que, dans le fond, pour les vidéos, l’utilisation de plugiciel et la solution la plus interopérable et même éventuellement (lorsque les brevets seront échus) la plus libre ? Il aurait peut-être fallu améliorer la balise object plutôt que de créer d’autres balises. En fait, une des orientations du passé aurait été de faire disparaître les balises img, iframe, et d’utiliser object à la place. Peu importe comment on la regarde, la situation actuelle n’est pas intéressante pour les formats libres. J’ai l’impression toutefois que beaucoup de gens vont travailler pour améliorer les choses. Est-ce chiâler de notre côté peut aider un peu ? Peut-être, mais pas trop en lutin grognon (troll) par contre 🙂

Quelques commandes rake pour Ruby On Rails : Parce que je m’en rappelle jamais

Les Parce que je m’en rappelle jamais sont une série sur mon blogue qui se veut un hommage au manque de mémoire et au déficit d’attention. Vous n’y trouverez pas des bonnes pratiques, mais simplement des exemples de commandes que j’ai eu besoin de faire un moment donné.

Sans plus tarder, quelque commandes rake pour Ruby on Rails :

Rouler les tests :
rake test
Mettre à jour la bd avec la dernière migration :
rake db:migrate
Mettre à jour la bd avec une version spécifique des migration:
rake db:migrate VERSION=30
Créer une migration :
./script/generate migration le_nom_de_la_migration
Revenir à la plus vieille version de la BD :
rake db:migrate VERSION=0
Détruire la BD :
rake db:drop
Créer la BD (sans le schema) :
rake db:create
Charger les tables dans le schema (sans les migration) :
rake db:schema:load

HTML 5 : Pourquoi les balises video et audio ne seront pas aussi intéressantes qu’elles pourraient l’être ?

Cette fois-ci je vais essayer d’être un peu moins négatif que la dernière fois, mais il faut quand regarder les choses en face : les balises audio et video ne vont pas simplifier le développement Web lorsqu’on travaille directement en HTML. La simplification, la centralisation et la réutilisation et l’utilisation d’une API sont hypothétiques et ne pourront se produire qui si plusieurs étoiles (dont celles de Microsoft et Apple) s’alignent dans le ciel. Peu probable…

Je m’explique :

En ce moment, en général, sauf peut-être pour les puristes, nous aurons une balise object, un balise embed et le plugiciel flash et un encodage audio – video supporté et payé par Adobe.

Avec video et audio, dans un monde idéal nous aurions un format audio et video ouvert et libre, le même pour tout le monde et une seule balise video / audio dont le visuel et les fonctionnalités sont contrôlés par le css / canvas et javascript. Beaucoup plus simple, mais problématique.

  1. Le support d’un format vidéo audio libre par tous est improbable : ce n’est ni dans l’intérêt de Apple (qui fait de l’argent avec aac et Quicktime), ni dans l’intérêt de Microsoft qui préfère wmv et Silverlight. Le seul format libre et sans brevet est ogg vorbis et theora. On parle de brevets inconnus pour expliquer qu’on ne le supporte pas mais faut pas être dupes, il peut y avoir des brevets sous marins sur à peu près n’importe quoi qu’on utilise en informatique, y compris l’air qu’on respire. Faites-moi pas brailler. Le pire, c’est qu’il semble (pour l’instant) que le Working Group HTML ne mettra pas ses culottes pour imposer un format libre.
  2. Le support même des balises videos et audios va à l’encontre des intérêts de Microsoft, c’est très peu probable que Internet Explorer la supporte un jour. Microsoft préfère Silverlight et je les comprends.

Pour empirer les choses, il y a aura des plates formes qui ne supporteront pas Flash et Silverlight et qui nécessiterons les balises video (je pense au iPhone en particulier, dont l’utilisation en peut plus être ignorée).

Pour être optimal et supporter tout le monde, cela nous prendra une balise video / audio avec Quicktime pour le iPhone, une autre balise video / audio avec ogg pour Linux et les plate formes libres, un object Flash pour Internet Explorer et un embed Flash pour les vieilles plate formes. Un paquet de Javascript pour que ce soit cohérent et je ne parle pas encore d’accessibilité ici qu’il faudra répéter pour chacune des plate formes s’il reste de l’argent. Avec l’historique d’écoute des spécialistes en accessibilité dans le Working Group HTML, je ne sais pas ce qu’il va se passer au niveau de l’accessibilité des balises video et audio… Le pire, ce ne sera pas possible de revenir à l’unique solution Flash puisque ça me surprendrait que Flash soit supporté sur toutes les plates-formes mobile. Avec Microsoft qui pousse très fort Silverlight, on risque d’avoir une plate forme de plus à supporter. Donc je récapitule : Deux video, deux object et deux embed. Oui, on peut générer le tout avec une librairie javascript, mais avouez que ça ne change pas grand chose pour les développeurs.

Dans les intranets se sera probablement plus simple : Silverlight seulement. En effet, Silverlight sera supporté par pas mal tout ce qui peut naviguer sur un intranet, sauf le iPhone, mais celui-ci ne sera probablement pas très conseillé en entreprise. Gageons que les plate formes mobiles d’entreprise (Blackberry et Windows Mobile) vont finir par supporter Silverlight.

Un dernier point : une autre raison que les balises video et audio ne seront pas populaires partout c’est qu’elle faciliterons les téléchargements des vidéos et des audios. Certains sites Web voulant protéger leurs propriétés intellectuelles voudront rendre cette activité plus difficile et je ne crois pas que videos et audio offres des capacités en ce sens. Probablement que c’est possible de coder le tout en javascript avec des clés uniques dans le temps et du streaming, mais je crois qu’il sera plus simple d’utiliser les solutions actuelles en Flash qui seront plus faciles à intégrer (juste d’avoir le vidéo dans le Flash rend invisible le url dans la source HTML, ce qui empêche au moins une partie des téléchargements).

Il faut aussi se poser la question : lorsqu’on ajoute une nouvelle fonctionnalité dans un langage, est-ce qu’on rend possible quelque chose qui n’était pas possible avant ou est-ce que la nouvelle manière est tellement plus simple que l’ancienne manière sera vite abandonnée ? Dans ce cadre, ce n’est pas pour tout de suite que le balise video et audio vont améliorer les choses!

En regardant tout cela, si on était cynique, on pourrait en arriver à la conclusion que la seule raison valable d’avoir les balises videos et audio est pour que Apple, dans sa magnanime et contrôlante personnalité, n’ait pas à supporter Flash dans le iPhone. Si on parle du dernier point que j’ai amené sur le téléchargement mondain, on pourrait parier que le développeurs aient à faire générer les balises videos et audios côté serveur seulement lorsque l’agent utilisateur est Safari de iPhone… facile à contourner, mais bon. Je fais du Web depuis 1996, j’en ai vu des pires…

N’hésitez-pas à complètement détruire les arguments ci-haut. En fait je ne demanderais que cela 😉 (J’aime bien me l’avocat du diable une fois de temps en temps, ce n’est pas mauvais pour la discussion, après tout!)

Petit changement d’orientation (pour l’instant) sur mon blogue

Ceux qui ont lu les quelques derniers billets de mon blogue ont peut-être remarqué un changement de ton un peu. Disons que je me suis rendu compte que quand je faisais trop attention à ce que j’écrivais (trop de relecture, autocensure d’opinions) je finissais par ne plus rien publier. Il faut que j’apprenne à assumer mes opinions, même si parfois elles ne sont pas toujours 100% positives. Alors j’expérimente un peu, je veux voir jusqu’où peux aller dans cet optique. Malheureusement, cela veut peut-être dire un style d’écriture plus difficile à lire, avec plus de fautes de frappes. Au moins le output devrait être plus élévé et il y a plus de chances que la qualité s’améliore un peu avec le temps. Enfin je l’espère.

Le danger des écosystèmes profonds et souterrains ou Internet Explorer 6 / Windows XP / Word 43VER

Personne à l’intérieur d’un bon esprit va vouloir réécrire son système ERP. Et pourtant, il y a de bonnes chances que les interfaces utilisateurs de type Web (mon côté puriste ne les appelleraient pas comme cela, mais bon) soient codées en dur pour Internet Explorer 6. Quand on a un grand succès et qu’on veut empêcher d’autres de coper notre succès par des moyens techniques, lorsqu’on voudra changer de technologie on va tomber sur plein de petits problèmes assez sournois merci au niveau de la rétrocompatibilité. Et on devient son propre pire compétiteur…

Et ce n’est pas que Internet Explorer 6. En fait pas tellement Internet Explorer 6, le vrai centre où tout est relié est Word et Excel (ou Office, mais surtout Word et Excel). Pour la plupart des gens qui travaillent avec un ordinateur, le logiciel le plus souvent utilisé n’est pas un navigateur Web, c’est Word et Excel. Et tout s’y intègre, tout est plogué sur Word et Excel, même la gestion de contenu Web. Le copy paste Word / Web qui amène avec lui la problématique ISO-8859-1 vs Windows 1252. Heureusement que WordPress transforme les guillemets en &8217;, parce que je suis coupable moi même d’utiliser Word pour écrire des articles. C’est beaucoup plus convivial qu’un textarea dans un gestionnaire de contenu, même pour WordPress.

Imaginez que vous voudriez supprimer Word au nom des standards ouverts, vous tomberiez sur plein de problèmes : tout est plogué sur Word. Ton lecteur d’écran ? Marche juste avec Word. Ton outil de gestion de finance, exporte en Excel. Les standards ouverts ne servent à rien s’ils ne sont pas implémentés. J’aurais tendance à dire que pour une moyenne à grosse entreprise, la plupart des systèmes informatiques sont plogués à Word et que si vous enlevez Word, ils ne fonctionneront plus. OpenOffice n’a certainement pas les mêmes API, et les reverse enginerer est sûrement épouvantable, au moins autant que le format .doc lui-même. (Quoique Alfresco essai de le faire pour Sharepoint).

De cette manière, je n’ai pas beaucoup de difficulté à dire que Office a un écosystème aussi gros que le Web, du moins en entreprise. Vous pourriez faire supporter par OpenOffice les standards d’accessibilité pour les connecter au système de texte à voix, ce dernier va probablement mieux marcher avec Word et Windows, qui ont leur propre standard. (Remarque, j’ai peut-être tort et je n’ai pas vérifié, je suis blogueur, pas journaliste, mais j’expose ceci pour faire suivre un raisonnement, pas représenter la réalité dans ses détails). À la maison, moins de choses nous obligent à utiliser Word. À part échanger des documents avec le bureau. C’est un format d’échange de documents passablement utilisés. Mais on peut utiliser autre chose, OpenOffice, ou des documents purement Web, dans certains cas éloignés des PDFs.

Office a été choisi par beaucoup de monde et je suis pas mal certains que nous sommes avec pendant assez longtemps encore. (Ça ne change pas qu’au niveau interface, il est certainement très correct et encore pas mal mieux que Google docs, qui lui a son propre écosystème).

Quand vous choisissez un produit, une solution, vous vous ploguez sur son écosystème. Il est fort possible que plein d’autres décisions soient influencées par cet écosystème. Si, par exemple, tous les éléments de cet écosystème rendent plus complexe et plus coûteuse vos opérations au jour le jour et que venu le jour où les limites de votre patience sont dépassés vous risquez de souffrir (votre portefeuille et votre mental probablement aussi). Placer une entreprise dans un écosystème, c’est comme de mettre une grenouille dans l’eau et de la chauffer tranquillement. Il vaut mieux s’assurer que la température cible ne soit pas fatale.

C’est la grosse question, l’éléphant dans la salle de réunion, pour les outils du cloud computing aussi. Les gens ont encore peur de cet écosystème par contre, et il n’est pas tout à fait évolué, trop Mammouth encore. Mais quand tout le monde va avoir donné ses données à un fournisseur (probablement qu’il y en aura un qui sortira du lot, comme Microsoft l’a fait auparavant), ce sera difficile de se sortir de son pouvoir.

En gros, si les morceaux de l’écosystème ne sont pas déploguables et ne respectent pas des standard ouvert, vous aurez des problèmes lors des mises à niveau et des remplacements. Les coûts risquent d’être élevés. Mais vous avez le choix, je ne les comprends pas encore, mais il doit y avoir des avantages à choisir des standards opaques. En fait oui, il y a des avantages : un certain nombre de choses fonctionnent out of the box. Vous ne partez pas de rien.

Mais toute cette intégration va à l’encontre de la compartimentation des outils logiciels, fondement des architecture orientés services. Quand on réussit à avoir une vraie architecture orientée services (ou plutôt dans le cas des contenus standardisé (ouvertement) une architecture orientée ressources, c’est plus facile de choisir une composant qui respecte le standard et choisir celui qui est le meilleur et non celui-qui vient avec la solution ou un de ceux qui fonctionne avec l’écosystème et qui est fortement intégré lui aussi. Les interfaces utilisateurs des outils se ventant d’être des architectures orientés services ont tendances à ne pas respecter la philosophie de base, mais bon je sors du sujet (il y en avait un ?)

On ne choisi pas le meilleur produit, on choisi le meilleur qui s’intègre avec notre architecture. Par contre, si on suivait des standards ouverts simples (je dis simples, parce qu’il y a des standards ouverts foutaisement compliqués), on aurait plus de choix. (Des fois trop c’est comme pas assez, mais bon…)

Personnellement, je pense que le HTML (même le 5) est trop mal foutu pour créer une base à un nouvel écosystème. Par contre je pense que les navigateurs sont la base de l’écosystème du cloud computing (côté client en tout cas, regardez, je parlais de Word, un logiciel client, c’est pourtant probablement l’outil qui a le plus d’impact sur les architectures d’entreprise et ça me surprendrait qu’ils soient présent dans les graphiques d’architecture, remarquez, moi non plus je ne le mets pas, il est comme on peut dire implicite). Non, je retire ce que j’ai dit, HTML est assez mal foutu pour faire parti d’un écosystème complexe, .doc a bien réussi, c’est clair que HTML peut le faire aussi. Il faut juste bien définir tous ses quirks et tous ses bogues et ses mauvaises manières de faire et on pourra bâtir n’importe quoi dessus, y compris des patentes mal faites et épouvantables, mais qui vont fonctionner suffisamment bien pour nous faire sauver plus de temps qu’il nous en fait perdre. Mouaip, c’est bien ce que HTML 5 est en train de faire hein? Là voilà la recette secrète de Google, définir les bogues pour pouvoir bien construire par dessus!

C’est drôle, parce qu’il faut regarder la fondamentale inertie des systèmes informatiques pour bien comprendre toute l’affaire.

J’ai un pool énorme de documents mal foutu (en .doc ou .html) et je veux les garder utilisables dans le futur (pérennité), et je veux même en créer d’autres de la même manière parce que j’y suis habitué. Je veux aussi créer un paquet de trucs qui les utilise parce que les contenus de tous ces documents sont la source de l’intelligence que je veux utiliser.

En fait, ce qui fait qu’il est difficile de ne plus utiliser l’écosystème Word, ce n’est pas ou peu le format .doc, mais bien les couches applicatives par dessus. De la même manière, on pourrait utiliser un format libre et ouvert (mettons comme le HTML) le rendre suffisamment moche pour avoir besoin de créer des couches par dessus pour faire du vrai travail et ensuite c’est cette couche sur lequel un écosystème se créer et qui ensuite peut forcer à utiliser certains produits faisant parti de cet écosystème. Il faudrait que cette couche par dessus soit aussi ouverte et standardisée que celle en dessous et n’appartienne à aucun revendeur. En fait, lorsqu’on travaille avec des outils de portail, c’est un peu aussi ce qui se passe. Pour être capable de faire fonctionner la personnalisation (comme exemple les boîtes minimisables dans un portail) on ajoute un paquet de javascript dont l’utilisation se fait par génération (outils de portlets de base, JSF sur les portails Java, ou encore du .net comme les Web parts de Sharepoint).

Ces morceaux s’intégrent mal au concept de flux de documents et sont difficilement personnalisables (je parle en termes de programmation CSS) et il faut utiliser les outils des revendeurs au lieu des standards HTML et CSS que l’on serait supposé utiliser normalement. Et je ne parle pas des problèmes que cela cause aux outils d’accessibilité, parce que ceux-ci sont plogués sur le standard de la technologie de base et non pas celle de la couche au dessus. Quoique cela pourrait changer. En fait j’imagine un jour ou l’on pourrait ploguer une technologie d’assistance à l’une de ces couches applicatives au lieu de HTML et rendre cette couche plus accessible que le HTML lui même. Ce serait vraiment Mal de faire cela et j’espère n’avoir donné l’idée à personne. Par contre, j’ai l’impression que ce serait pour le moins très compliqué…

Les outils de portails n’ont pas tellement bien fonctionné en industrie sauf dans les cas où l’on met l’effort nécessaire (c’est pourquoi ceux qui comprennent que mettre beaucoup d’énergie et de gouvernance dans un projet portail d’entreprise (et de comprendre leurs limitations et leurs forcent) finissent par réussir à avoir qqch de fonctionnel et qui réponds aux besoins, je le sais j’ai réussi deux fois dans ma carrière à contribuer à faire marcher Websphere Portal, et là je vais peut-être m’attaquer à Sharepoint – watch this space).

Pour dire que si l’on veut gagner les coeurs de tout le monde, pas juste les architectes d’entreprise, il va falloir trouver une couche applicative par dessus le HTML qui est intéressante pour les développeurs autant pour les technos propriétaires que libres. Attention, la techno elle-même pourrait être libre et ça ne changerait rien, si elle se plogue super facilement aux services de qqun (du cloud computing tiens!) et qu’elle facilite l’appropriation des données (et c’est là le champs de bataille) on va tous être pris à utiliser cet écosystème dans le futur. Dans un autre ordre d’idée, même si tout le monde pourrait revendre par exemple JBoss, personne le fait parce que l’expertise du produit appartient à une seule compagnie. Si la création elle même de la couche applicative est suffisamment complexe, pas personne d’autres que son créateur va pouvoir se l’approprier. Pour qu’elle soit complexe, cela va prendre une couche de base moche et mal foutue, c’est-à-dire HTML + CSS + Javascript + DOM.

Cette pattente là super compliqué, mais facile à utiliser sera accessible par trois morceaux de technologies : les navigateurs (équivalent de Word), les moteurs de recherches (le système d’exploitation) et les outil de cloud computing (l’équivalent de toutes les applications qui font parti de l’écosystème). (Bon ok, ma comparaison est bouetteuse, mais bon… je voulais montrer un point). Cette couche applicative devra être aussi facile d’utilisation que Visual Basic si on veut qu’elle réussisse (je pense que Visual Basic est l’une des raisons pourquoi l’écosystème Word est si grand en ce moment, mettons que c’est .NET maintenant, une très bonne évolution).

La même raison pourquoi le format .doc est si mal foutu, accable le HTML, le don’t break the Web, ou en français la rétrocompatibilité. Aussi le pave the cowpath, ou encore en français, le continuer à faire les mêmes erreurs parce que c’est plus facile. (Bon, je l’ai dit ce que je pensais des orientations du WG de HTML et pourquoi je ne me sens pas capable d’y participer intelligemment et positivement).

XHTML a essayé de briser ce cercle vicieux et à échoué lamentablement, je dirais qu’à cause de manque de support de application/xml+xhtml des outils de l’écosystème Word (les gestionnaires de contenus où le copy paste Word est mandaté, à commencer par Frontpage). Ben oui, encore Word, on est chanceux que l’encodage de base du Web ne soit pas Windows-1252.

Il faudrait donc, que quelqu’un crée cette couche avant qu’un revendeur le fasse, la rende facilement utilisable avec un support génial chez tous les éléments de l’écosystème et out-Microsfter Microsoft et Google. Je pensais que HTML5 serait cette technologie et qu’on aurait pas besoin de créer une couche applicative je suis de moins en moins certain que c’est possible. Je pense que HTML 5 + CSS 4 + Javascript x devraient avoir des composants natifs qui font la même chose qu’un GWT, un JSF ou un ASP.NET et standards + un mapping avec un langage côté serveur qui remplacerait la partie vue des JSP, ASP et PHP de ce monde. (Imaginez, le langage de vue, (dans le sens modèle vue contrôleur) serait le même que vous travailliez en Java, en PHP, en C# ou en Ruby… ça ça serait cool! Pour voir à quoi je pense que ce langage devrait ressembler, regarder la technologie Facelets (ça se plogue avec JSF). Mais pour faire cela, ça prendrait de la vision et beaucoup beaucoup beaucoup d’énergie et d’argent, du genre à ce qui a servi à créer Java dans les années 90s.

Tout ça aussi pour dire que pour sortir IE 6 des entreprises (et par conséquent Windows XP) va falloir beaucoup d’effort encore et que cela va prendre du temps! et que pour faire mieux que HTML 5 faudrait encore plus d’efforts et de temps (et probablement une vision moins fermée du Web que celle des revendeurs de navigateur Web) ! Finalement Karl a raison, nous sommes tous dans nos grottes.