La TechnoPaul (v. 1.1)
Just another technology-related weblog

M6 a lancé depuis un mois M6Replay [fr], un service permettant de visionner en ligne les émissions et séries passées sur la chaîne plusieurs jours avant. Je ne peux pas vous parler des fonctionnalités du service (Arte a quelque de similaire, +7 [fr]), vu que l’accès au site a tout d’un parcours du combattant.

Pas Windows ? Revenez quand vous l’aurez !

Le service se fonde en effet sur la technologie DRM de Microsoft, et n’est donc (pour le moment, nous jure-t-on) qu’accessible à partir de Windows. Pour le moment, car le service est prévu pour être adapté à Mac. Notons qu’aucune date n’est avancée et que les utilisateurs de Linux peuvent clairement faire une croix sur le service. On ne peut pas utiliser du libre et avoir accès au propriétaire, voyons…

Pas la bonne config ? Revenez quand vous l’aurez !

Une fois qu’on est sous Windows, il faut encore utiliser Internet Explorer, avoir les DRM à jour (je ne sais pas ce que ça veut dire exactement, vous vous en doutez), JavaScript activé (ça, à la limite…)… Et puis si ça ne marche pas, eh bien on ne sait pas exactement pourquoi. Parfois sous Firefox il suffit d’ignorer l’avertissement d’incompatibilité pour que tout fonctionne. Parfois, ça rame (les serveurs ne tiennent pas forcément le coup, il faut dire que l’offre en ligne est ambitieuse : les programmes disponibles 1 h après leur diffusion et durant 7 à 15 jours). Parfois, on ne peut pas mettre pause, naviguer dans le fichier, parfois tout freeze…

Et les standards ?

En fait, il semblerait qu’ils n’aient jamais fait partie du cahier des charges. J’ai essayé de valider la seule page d’accessible, à savoir la page de test de compatibilité m’informant que je ne pouvais pas mettre les pieds sur le site… Le résultat est carrément catastrophique. Le test de validité ne peut même pas démarrer car le document n’est pas encodé correctement !

A tous les sceptiques de l’utilité des standards… Si M6 avait intégré la conformité aux normes dans son cahier des charges, l’interface [fr] ne serait certainement pas aussi belle, le tout ne ferait peut-être pas complètement « Web 2.0 » (comprenez dans ce contexte clinquant et dynamique, avec des vidéos qui bougent de partout), mais le service serait probablement accessible à plus de 50% des internautes, ce qui ne semble pas être le cas actuellement.

Actuellement en plein développement dans le cadre d’un projet universitaire, j’ai pour la première fois intégré le JS dans mon approche initiale. Jusqu’à présent, le JS était un outil que j’aimais très peu utiliser et que j’avais beaucoup de mal à maîtriser - le premier point ne facilitant pas le second -, donc que je m’efforçais d’éviter au maximum.

Il faut dire que les arguments contre l’utilisation du JS étaient légion. A l’époque où je me formais au développement web, beaucoup de sites utilisaient très mal le JS : recours aux pop-ups, scripts lourds fatiguant les petites configurations auxqueslles j’ai toujours été habitué, utilisation du JS pour mal faire ce qui pouvait être fait en PHP… Sans compter le fait que le JS pouvait masquer ou créer de gros problèmes d’accessibilité ou de normalisation : étant donné que c’est un langage côté client (c’est-à-dire que, contrairement au PHP, il ne nécessite pas un serveur pour être interprété), les modifications qu’il fait à la page (ajout de texte, changement d’apparence, etc.) ne sont pas répercutées dans le code source (code interprété transmis par le serveur au client). Lorsqu’on cherche à valider la page, ce qui apparaît valide ne l’est pas forcément.

Du coup, si j’ai jeté un oeil au JS, c’était à l’origine plus pour apporter de l’eau à mon moulin de critiques. Et honnêtement, le modèle objet de JS, c’est-à-dire la façon dont sont structurés tous les éléments d’une page, n’est pas ce qu’il y a de plus simple. Il est même plutôt compliqué, au point que les scripts JS manipulent rarement les objets en faisant référence à leur chemin complet, mais plutôt à leur nom (attribut name) ou à leur identifiant (attribut id).

Plus je développais, plus je prenais en compte des besoins que j’avais négligé dans mes premières réalisations, essentiellement concernant l’ergonomie de l’interface utilisateur d’un site web. La progression de l’interactivité entraîne en effet la multiplication des formulaires, outil très pratique pour transmettre de l’information du client vers le serveur. Or les formulaires, codés en (X)HTML, ont très peu de fonctionnalités et d’options par défaut. En fait, à part quelques options comme la taille, le style ou le nombre maximal d’informations acceptées, on ne peut rien paramétrer : pas de vérification des données, pas d’assistance dynamique à la saisie, sans nécessaire envoi au serveur et recours à un script PHP (généralement peu sympathique à développer).

Dans ce genre de situations, assez nombreuses, une utilisation mesurée du JS prend tout son sens et permet d’accroître le confort d’utilisation. On peut ainsi, assez facilement, vérifier avant l’envoi du formulaire que tous les champs exigés sont remplis, s’assurer lors de la frappe que les informations saisies sont valides (pour une adresse e-mail, par exemple, ou un numéro de téléphone), rendre le formulaire dynamique en affichant/masquant des champs en fonction des réponses fournies… Ceci ne dispense évidemment pas de fournir une alternative au JS (via la balise noscript), ni de développer un script de traitement en PHP (ne serait-ce que pour des raisons de sécurité).

Comme toujours, le tout est de savoir utiliser le JS à bon escient. Trop souvent, on voit des sites où le recours au JS n’est là que par souci du webmaster d’utiliser toutes ses compétences ou de valoriser ses derniers apprentissages. Ce n’est clairement pas un comportement correct pour un développeur, qui doit à mon avis avoir deux préoccupations primordiales :

• l’optimisation de l’interface d’utilisation, c’est-à-dire la simplification constante de la prise en main de sa réalisation par l’utilisateur ;
• le respect des standards gouvernant les technologies utilisées.

Pour le JS comme pour toute autre technologie, un bon développeur saura faire les choix qui respecteront strictement ces deux contraintes. Il ne subordonnera pas le résultat aux moyens utilisés, mais saura choisir les technologies en fonction d’un cahier des charges précis.

Le Web se développe, le Web se démocratise, s’ouvre à des contributions de plus en plus nombreuses, permet des applications dont la variété est impressionnante. Comme toute « technologie », le Web est régi par des normes, des standards, censés permettre à tout acteur désireux de s’aventurer sur la Toile de parler le même langage que les autres et d’assurer une interopérabilité maximale. L’organisme principal chargé de gérer ces standards est le W3C [E.N.], créé par l’inventeur du Web en personne, Tim Berners-Lee (c’est dire le poids que devrait avoir le W3C en matière de standards, et l’importance que revêtent les normes aux yeux du père du Web). Le W3C est géré par des centres de recherche et associe des entreprises à sa démarche, pour assurer que les standards définis soient le plus largement diffusés.

Cependant, la normalisation, bien que théoriquement claire - il suffit de développer selon les standards -, a eu beaucoup de mal à se diffuser dans la pratique. Et pour cause : pour des raisons stratégiques, les deux grands navigateurs des débuts du Web, Netscape Navigator et Internet Explorer, se livrèrent à une guerre du langage HTML, chacun interprétant son propre HTML afin de créer un verrou des consommateurs : un site développé pour IE avait peu de chances de bien rendre sous Netscape, et vice-versa. Il s’agissait alors de s’assurer que le plus grand nombre d’entreprises utiliseraient sa version du langage pour inciter indirectement les utilisateurs à utiliser son navigateur. On sait que Microsoft a fini par gagner, puisque Netscape a longtemps périclité et est actuellement en fin de vie (AOL, qui avait racheté Netscape, a annoncé la fin de la prise en charge du navigateur [E.N.]). Il faut noter que cette victoire n’est que relative, puisque de Netscape découle directement Mozilla Firefox, utilisé par environ 17% des internautes actuellement.

Cette situation confuse n’a pas servi les intérêts de la normalisation : le HTML d’IE n’était pas conforme aux standards de plus en plus rigoureux définis par le W3C. La création du XHTML marque implicitement l’échec du HTML comme standard reconnu et diffusé. Le XHTML repart presque à zéro, implémente le XML comme base du XHTML, pour plus de rigueur dans le balisage des pages. Un grand nombre de balises sont supprimées, quelques nouveaux éléments font leur apparition… L’idée essentielle est d’assurer la séparation du fond (codé en XHTML) et de la forme (écrite généralement en CSS). Ainsi, on permet à l’information d’être indépendante de sa présentation. Les utilisateurs « minoritaires », comme les navigateurs textuels, qui ne présentent que l’information sans design, ou les personnes handicapées visuelles, qui peuvent utiliser un rendu leur facilitant l’accès à l’information, mais aussi les terminaux mobiles, dont l’écran est nettement plus petit, ne sont donc plus lésées.

L’acceptation de ce nouveau standard se heurtait à plusieurs difficultés.
La première, de taille, était que les développeurs habitués à l’HTML devaient changer leurs habitudes. Et même les personnes apprenant à développer après la création de ce standard n’étaient pas toutes formées au XHTML ! Question d’habitude, qui prend généralement beaucoup de temps à être changée.
D’autre part, le navigateur utilisé par une immense majorité des internautes, IE, a longtemps interprété les pages Web résolument différemment. Se posait alors un dilemme pour le développeur consciencieux : produire un code valide, standard, normé, mais mal lu par IE, ou produire un code adapté à IE et non valide. Sans compter les contraintes économiques pesant sur les développeurs salariés… Comment prendre le temps de coder proprement dans ces conditions ?
Enfin, l’ouverture du Web et sa démocratisation eut pour inconvénient d’ouvrir la création de contenu à des gens non initiés à la programmation Web… Comment s’assurer alors que l’information produite l’était respectueusement des standards ?

Aujourd’hui, l’évolution va dans le bon sens, et on ne peut que s’en féliciter. Ainsi, la nouvelle version d’IE, IE7, fait un grand pas en avant en termes de respect des standards. IE8, la version en développement, semble plus prometteuse encore. Les états d’esprit changent… Même si seuls 30% des utilisateurs d’IE6 sont passés à la version 7, ce qui relativise le progrès accompli.
D’autre part, les bonnes habitudes - les plus dures à prendre - commencent à rentrer. Le développement Web se fait de plus en plus proprement, avec une considération des standards. Preuve s’il en faut, le W3C travaille actuellement sur une version 5 de HTML, alors que la version 4 date de 1998-1999, et que le XHTML 2.0 est en travaux depuis environ 7 ans… Bref, alors que le W3C était très peu dynamique, l’activité a nettement repris ces derniers temps.
Enfin, les systèmes de gestion de contenu (CMS), qui sont l’interface privilégiée de publication de contenu pour les non développeurs, évoluent, se complexifient, et s’améliorent, pour s’assurer que l’information publiée est standardisée.

Finalement, le Web est de plus en plus propre, et c’est tant mieux. Il reste cependant beaucoup de travail à faire, et il faut rester vigilant concernant les technologies avancées de développement Web, comme l’AJAX, qui peuvent troubler les standards en utilisant des entités étrangères aux recommandations du W3C, ou en masquant des irrégularités par l’actualisation du contenu côté client… Espérons que le W3C prenne ces évolutions en compte et sache adapter ses standards rapidement.

Depuis quelques jours, suite à la diffusion de la décision de plusieurs pays, la normalisation du format de Microsoft Office OpenXML ne fait plus aucun doute. La France, pour sa part, a changé son vote [F.R.] d’un Non avec commentaires à une Abstention argumentée ce lundi 31 mars. Ce changement, même s’il ne semble pas avoir eu d’influence sur le résultat final au niveau international, a quand même provoqué de nombreuses réactions. En effet, l’AFNOR semble avoir changé de position dans le week-end précédent sa décision… Cet article de ZDnet.fr [F.R.] (relevé par Tristan Nitot [F.R.]) explique le tout en détails.

Ce qui m’intéresse plus particulièrement, outre tout ce que les weblogueurs et les journalistes relèvent et critiquent sur la forme et le fond, c’est qu’on a l’impression que le monde de l’entreprise - ou tout du moins d’un certain type d’entreprise axé sur le propriétaire et les stratégies monopolistiques - cherche à accentuer les préjugés et a priori négatifs qu’un grand nombre de gens peuvent avoir.

Je suis le dernier à rejeter en bloc le monde de l’entreprise. En soi, la logique de profit décriée par certains me semble essentielle, nécessaire dans le monde dans lequel nous vivons. Et mieux vaut l’accepter et en jouer le jeu, puisque libéralisme et capitalisme sont deux paradigmes économiques actuels, que de la rejeter en bloc et de tenter de trouver une alternative viable. Ainsi, de nombreuses SSII occupent intelligemment le domaine du libre, en offrant, plutôt que le logiciel en lui-même, les prestations périphériques. J’y reviendrai. De nombreuses entreprises, plus généralement, savent jouer le jeu de la concurrence, au grand avantage du consommateur.

Mais un - relativement - petit nombre d’entreprises s’obstine dans la voie du verrouillage, du monopole et de la propriétarisation. Petit nombre, certes, mais d’importance vu la taille des entreprises en question. Il est triste de voir que ces entreprises, qui peuvent proposer des produits intéressants, savent très bien se faire détester d’une part croissante de la population par leurs politiques de commerce et de communication inégales et parfois abusives. Que peut faire le monde du libre face aux pressions lobbyistes de grandes firmes bien implantées et aux vastes connexions ?

Cette mauvaise image s’étend malheureusement au monde de l’entreprise de manière générale, ce qui entraîne des réactions primaires regrettables des deux côtés. Une sorte de cercle vicieux. Plutôt que de faire persister et d’aggraver la fracture propriétaire/libre, une troisième voie semble plus appréciable. Les SSII implantées dans le libre sont un exemple. Les tentatives lobbyistes d’associations libristes un autre. Il ne faut pas tomber dans le piège de la condamnation généraliste. Luttons à armes égales