Qu’est-ce que le web ou l’internet? (ou l’Internet, avec une majuscule, comme le correcteur orthographique de Word tente toujours de me corriger; je pense qu’internet est suffisamment dans les usages et les esprits pour devenir un nom commun ne nécessitant pas de majuscule, si?)

Quelle est son utilisation actuelle?

Dans cette première partie relativement longue, je vais d’abord tenter de passer en revue ce qu’est internet, ses grandes évolutions et ses maux. Pour ensuite, dans un second temps, pouvoir vous parler de ce qu’internet est en train de devenir.

Je vais certainement passer en revue des notions bien connues de certains. Je suis désolé pour ceux qui connaissent déjà l’état de la conception de sites web mais je pense qu’il serait intéressant pour ceux qui ne sont pas professionnels du domaine de connaître les technologies qui se cachent derrière le bazar du web.

Pour le côté historique, j’ai sommairement constitué trois grandes phases très approximatives. Je ne citerai pas précisément des dates-clefs qui me permettraient de justifier ces périodes. La technique de mettre en avant les dates historiques pour rendre plus concrets les dates des périodes est difficilement applicable au sujet traité.

Il n’y a pas eu sur internet l’apparition de technologies qui ont tout bouleversé d’un coup et pour longtemps. Certaines technologies (notamment technologies côté-serveur) et une vraie adoption des techniques en place (CSS, XML, HTML, AAA, DOM…) ont beaucoup fait progresser internet. La délimitation des périodes utilisée se calque sur des dates simples assez vagues, comme l’est l’évolution d’internet.

1. Le web hier (1995-2000)

Nous connaissons bien maintenant le mail, les pages web, les connexions directes d’ordinateur à ordinateur (FTP, accès à distance…), le chat textuel, vidéo ou audio et depuis quelque temps déjà le téléchargement peer-to-peer (eDonkey/eMule, Limewire…)

Ces interfaces sont maintenant maîtrisées ou en tout cas connues de nous tous. Mais de nouveaux outils apparaissent et nous permettent de faire de nouvelles choses avec la structure en place (notamment le protocole HTTP qui est, plus qu’on ne le sait, une pièce maîtresse du web et qui est, comme le langage html, souvent très mal employé).

Pour voir où on en est, il faut regarder comment on en est arrivé là. Aux débuts de l’internet “public”, que nous aurons fixé à la moitié des années 90, c’était la jungle. Beaucoup de programmeurs de logiciels et pas mal d’entrepreneurs opportunistes ont peu à peu pris possession de ce terrain vierge. Ce n’est certainement pas de leur faute, mais, sans vraie maîtrise conceptuelle ou technique de ce nouvel objet, ni vues à long terme (personne n’avait idée de ce qu’internet allait devenir), chacun a investi le milieu à sa manière.

1.1 Internet Explorer… pfff…

Internet Explorer est certainement un des plus importants instruments du massacre du web. Internet Explorer est le plus mauvais navigateur de tous les temps et le plus utilisé, évidemment. IE, comme on l’appelle affectueusement, interprète le HTML et le CSS - pendant stylistique du html - de manière catastrophique. Depuis les années 2000 surtout (depuis que le CSS est revenu en force et que l’on a commencé à arrêter d’utiliser les tables pour la mise en page j’y reviens), les développeurs web se cognent quotidiennement la tête contre les murs à cause de l’interprétation barbare qu’IE fait du CSS.

L’ensemble des erreurs de jeunesse d’internet sont peu à peu corrigées. Microsoft va même offrir à ses pauvres clients un Internet Explorer 7 dans le courant de l’année. IE6 est sorti en 2001. 5 ans pour un navigateur internet, c’est long. Très long. Sachant que des navigateurs modernes tels que Firefox ou Safari sont sérieusement remis à jour beaucoup plus souvent.

J’arrête de vous ennuyer avec Internet Explorer; vous vous en doutez certainement maintenant, je suis développeur web et ça fait quelques années que je me cogne quotidiennement la tête contre les murs à cause d’IE. Ca me tenait à cœur de dénoncer encore une fois ce programme monstrueux, désolé pour les fans de IE.

1.2 Et les autres

Il n’est pas le seul responsable. Le html entre 1995 et 2000 était encore assez jeune et n’est devenu mûr qu’à partir du tout début du troisième millénaire. Les interprétations du HTML étaient souvent approximatives et l’usabilité du web était encore à définir.

De plus les développeurs des grandes applications derrière les sites internet dictaient leur vision souvent trop mécanique et mercantile du web. Avec des langages de développement lourds tel que Java (ce n’est pas du tout une critique de Java à proprement parlé!!), les programmeurs ont souvent fait peu de cas du HTTP et de l’ordre que celui-ci était censé imposer aux transmissions de pages web.

2. Le web d’aujourd’hui

Pour continuer notre petite exploration du ouèbe, je vais vous parler des innovations qu’il a connues au XXIe siècle.

2.1 Les standards web

La constitution du web est, comme vous le savez certainement, essentiellement fait par le HTML. Mais il n’est pas le seul à entrer en jeu. Il existe d’autres langages qui permettent aux hommes et aux machines de communiquer, de se transmettre des données, de les afficher. Il y a notamment le javascript et le css qui interviennent surtout au niveau de l’affichage des pages web. Le javascript (aussi appelé ECMA script) permet de réaliser des actions sur une page web, “du côté client”. Le CSS est langage qui permet de mettre en page et de “décorer”. Il existe également, par exemple, le XML qui formate des fichiers RSS ou Atom pour la syndication (ces fichiers contiennent des informations que des ordinateurs peuvent lire et reformater ensuite selon leurs besoins); ou le SVG qui est un format d’image vectorielle en XML qui pourrait dans un probable futur faire des choses comparables à ce que fait actuelle flash.

2.2 Le W3C

Un organisme, le W3C (World Wide Web Consortium voir sur Wikipedia), publie des recommandations sur tous ces formats. Ce ne sont pas des lois mais des recommandations qui ont pour objectif d’harmoniser la communication sur le web. Voici le credo du W3C:

To lead the World Wide Web to its full potential by developing protocols and guidelines that ensure long-term growth for the Web.

(en français: Mener le World Wide Web à son plein potentiel en développant des protocoles et des directives qui assurent au web une croissance (ndt: sereine) sur le long terme).

Le W3C a été fondé en 1994 par Tim Berners-Lee. Tim Berners-Lee n’est autre que l’inventeur du World Wide Web. On peut se dire qu’il est probable qu’il a une assez bonne idée de comment gérer tout ça. Il le dirige depuis 1994. La gestion de cet organisme est assurée par les prestigieux MIT, ERCIM (Europe) et Université de Keio (Japon).

Les recommandations du W3C par leur utilisation universelle deviennent de fait des standards. Mais au départ du web, on l’aura compris, c’est la jungle. Et certaines entreprises qui ont eu un peu de pouvoir sur le web, non toutes, ont apporté leur grain de sel au problème (problèmes de différences sur les sites selon que vous utilisiez Netscape ou Internet Explorer, ça vous rappelle des choses: il s’agissait de problèmes d’interprétations différentes des standards et d’ajout de fonctions propriétaires). Alors vers le début du siècle, certains se sont dit qu’il serait peut-être plus intelligent de tous parler le même langage que de se disputer des parts de marché, ce qui ne faisait pas toujours avancer les choses dans le bon sens.

On s’est donc mis à écrire des sites en XHTML qui est plus strict que le HTML, qui permet moins de fantaisies et qui introduit dans les pages web un maximum de sémantique au niveau du balisage de la page. On a séparé des fichiers HTML et XHTML la mise en page et l’habillage que l’on fait grâce à des fichiers de style CSS (Cascading Style Sheets). On a tenté de rendre les sites plus accessibles (WAI: Web Accessibility Iniative) ; la structuration (la sémantisation) du contenu a rendu cela possible.

Ces standards ont été avancés par le W3C mais leur utilisation n’a été possible qu’avec l’effort de certains développeurs web consciencieux. Aux États-Unis, il y a notamment A List Apart , un collectif; en Europe OpenWeb, un organisme; en France encore Alsacréations , un développeur seul ou Pompage, un collectif.

2.3 Services web et rss: accès à l’information pure

Les services web (les “web services”) permettent à des ordinateurs de communiquer entre eux et de s'’échanger des informations. Le RSS permet à des ordinateurs d’accéder à des informations fixes.

Un service web offre des outils (les APIs, utilisables par des programmeurs, qui permettent de récupérer des information du site hébergeant ce service. Par exemple Google permet d'exécuter des recherches sur ses bases de données et retourner un résultat de recherche. L’ordinateur qui fait une telle demande à Google reçoit des données qu’il peut formater et utiliser selon ses besoins.

Un flux RSS (ou Atom) est en fait un fichier accessible à l’instar d’un fichier HTML. Il peut être mis à jour fréquemment et gagne par là son intérêt. Tout ordinateur relié au net pourra accéder à ce fichier et en tirer ses informations et le formater comme un service web. Il pourra vérifier ce fichier de manière récurrente, pour voir s’il a changé. Nous utilisons le RSS pour voir si un site (souvent un blog) a été mis à jour sans à avoir à aller le visiter ou pour obtenir la dernière émission de son podcast préféré.

Il y a donc pour le RSS et le service web des usages différents et deux possibilités différentes pour accéder à des informations. Le RSS transmet des informations qu’un site veut partager et le Service web donne accès à un ensemble plus conséquent d’informations dont on pourra tirer l’information souhaitée. Avec le RSS on aura également une notion de temporalité et pas avec un service web. Les outils sont différents mais permettent tous deux à des ordinateurs de se transmettre, entre eux, dynamiquement des informations.

2.4 Flash

Flash, voilà un sujet polémique! Je dois l’annoncer tout de suite, je ne suis pas un fervent partisan de flash. Mais cela ne veut pas dire que je n’y vois pas d’intérêt. Dans certains domaines, Flash a son utilité. Vraiment. Mais l’utilisation qui en est faite est souvent désagréable ou dangereuse.

Par exemple, une “intro flash” sur un site, c’est rarement l’idéal. Surtout quand elle est longue, pas géniale et qu’il n’y a pas de lien “Sauter l’intro”. La possibilité d’avoir sur un site une présentation (souvent interactive) d’un produit ou de l’entreprise est très utile et agréable mais peut-être pas toujours en “intro”. Certains sites artistiques, personnels… peuvent aussi très bien être en flash.

Mais pour beaucoup de sites, flash comporte des désavantages rebutants:

• Accessibilité zéro ou proche de zéro: Macromédia a inséré dans Flash pas mal d’accessibilité mais son implémentation est rare (et souvent peu ergonomique); elle est faite sur les bons sites en flash qui veulent être accessibles
• Développement lourd: Une programmation peu souple notamment pour l’affichage et l'accès à des bases de données. Changer quelque chose prend du temps. Mise à jour plus rares.
• Accès difficile de certains éléments: La lecture d’un long texte sur flash est souvent affreuse car on ne peut souvent pas faire défiler de manière aisée le texte (clavier inopérant et curseurs de défilement aux formes variés)
• Google ne peut pas atteindre les données à l’intérieur d’un flash: c’est un problème disqualifiant pour pas mal de sites…

Flash a son utilité mais ne constitue pas pour le moment un outil suffisant pour révolutionner l’internet dans les années à venir. Je tends à croire que si Macromédia (qui appartient à Adobe maintenant!) se décide à rendre son produit génial maintenant en se calquant sur les méthodes développement modernes, flash pourrait prendre de l’importance. Mais bon. Macromedia. Adobe. Je ne suis pas sûr qu’il y ait encore une révolution intra-entreprise.

3 Le web demain

3.1 Web 0.2

Certains ont peut-être entendu parler d’un certain “Web 2.0”. Ce terme est apparu récemment et tourne pas mal dans le milieu du développement web. On trouve nombre d’articles “sérieux” et même de conférences portant ce doux nom. Ce terme est une aberration sémiologique amenée par quelques entrepreneurs zélés et maintes fois réutilisé dans des articles de journalistes moyennement informés qui pensent pouvoir mettre là-dessous toutes les innovations d’internet du moment. Une des “technologies” couramment mises sous cette appellation est Ajax, sur lequel nous reviendront plus tard. Utiliser maintenant le mot Ajax n’est plus très grave mais s’en servir n’importe comment rend ce qu’il représente désuet avant de vraiment exister. On peut aussi utiliser “Web 2.0” mais, comment dire… difficilement.

Pour cette période nous allons amener 2 nouveaux termes. On parlera de

• côté client: pour ce qui est exécuté sur l’ordinateur de l’internaute, à même son navigateur. L'exécution d’un code (du javascript généralement) modifie les pages une fois chargées, selon ce que fait l’utilisateur.
• côté serveur: pour ce qui est exécuté sur les serveurs qui envoient les pages web en particulier. Ce sont les scripts et les programmes qui permettent de créer dynamiquement des pages web à partir de données diverses.

Nous allons donc regarder ce qui se fait de nouveau des deux côtés du réseau.

3.2 Côté-client: Ajax

Dans le domaine de l’interactivé côté client, je vous ai parlé de flash qui est le roi des animations. Pour “animer”, donner un peu de vies aux pages, on a vu quelque chose apparaître fin 20e, le dHTML, pour dynamic-HTML. Il s’agissait d’un HTML agrémenté de javascript, de “layers” à la mode Dreamweaver et de iFrames. Là encore ce qui primait c’était l’incompatibilité. Le début d’internet était une bataille à qui ferait le site le plus incompatible possible. La plupart du temps c’était développé pour un IE et c’était incompatible avec les autres navigateurs et même parfois avec les autres IEs.

Depuis 1 an il y a une nouvelle solution qui doucement apparaît comme étant viable: le moyennement nommé “Ajax”. Ajax tient pour “Asynchronous/JAvascript/Xml” et a été amené par un article de Jesse James Garrett de la célèbre entreprise de consultants internet Adaptive Path. Mais qu’est-ce donc que l’Ajax? On pense rapidement à de la lessive… mais non. Il s’agit d’une technique permettant aux pages web de se mettre à jour sans avoir à se recharger complètement. Si on charge moins de donnée, on charge plus vite. Cette technique permet aussi de faire des réponses quasi instantanées à des requêtes de recherche notamment (voir Google Suggest ou testez la recherche sur ce site

Propositions de Google Suggest pour “cuk”

L’utilisation de cette technique ne s’applique pas à tous les contenus web mais est vraiment utile pour les “applications web” tel le Webmail de Google, qui a mis cette technologie au goût du jour. En effet l’Ajax a ses limites. Attention il a aussi son utilité! Mais remarquons qu’avec l’Ajax:

• on ne peut pas retranscrire dans la barre d’adresse la position de l’internaute sur le site
• Google ne peut pas explorer les données amenées par de l’Ajax

Rapidement je vous explique en quoi consiste la technique: lors d’une action déclenchée par l’internaute ou de manière automatique (par exemple un minuteur qui va déclencher une action toutes les x secondes) le javascript va faire une requête HTTP (comme si on demandait un nouvelle page) au serveur qui va lui retourner des données formatée en XML. Tout bête. En réalité on n’est pas obligé de faire retourner du XML par le serveur et à la place on peut transférer n’importe quelle donnée, par exemple un morceau de HTML. Le terme d’asynchronous vient du fait qu’on fait une requête et que la réponse vient après par une autre connexion HTTP. On pourrait faire du “synchronous” mais alors la connexion resterait ouverte jusqu’à la réponse du serveur et bloquerait la page: l’internaute ne pourrait plus rien faire pendant ce temps. La requête classique de pages entières est par exemple synchrone. C’est un sujet un peu compliqué, passons.

Schéma des requêtes synchrone et asynchrone

Enfin, sous le terme d’Ajax on a aussi mis les animations javascript. Si vous entendez parler d’Ajax vous avez parfois affaire avec un site qui ne fait pas de requêtes HTTP asynchrones mais qui fait de jolies animations grâce à du javascript. Ca marche plutôt bien et ça peut être vraiment utile. En revanche ça ne marche que sur les navigateurs récents (Safari/navigateurs Gecko: Firefox, Mozilla, Camino/IE5 et 6/...) et l’interprétation différente du javascript selon le navigateur rend son utilisation parfois très fastidieuse. Vous pouvez voir un peu de ce que l’on peut faire en visitant le site d’une des plus importantes bibliothèques Ajax actuellement: l’excellent Script.aculo.us.

3.3 Côté serveur: adoption du libre (PHP, MySQL, Apache, linux) et nouveaux langages

Du côté serveur les choses évoluent aussi. Le PHP a pris beaucoup d’importance. C’est un langage interprété (qui ne se compile pas) relativement facile à apprendre et que l’on peut facilement héberger. Avec sa dernière version, PHP 5, il s’est étoffé d’une capacité de programmation objet. Le PHP fait partie d’un petit groupe que l’on a doucement rapproché: LAMP, pour Linux, Apache, MySQL et donc PHP (ou parfois Perl et Python). Ce petit groupe règne actuellement sur le développement web de petite et moyenne envergure. Une communauté libre importante qui améliore tout ça constamment.

Mais ce qui est vraiment intéressant aujourd’hui c’est les nouveaux langages du web. Rien de tout à fait nouveau: Python date de 1990 et Ruby de 1995. Mais leur utilisation sur le web est relativement récente (enfin beaucoup plus récente pour Ruby que pour Python et de manière importante pour Python depuis moins longtemps que le PHP).

Ces deux langages ont pour avantage premier d’être interprétés et, surtout, modernes. Non que les autres langages soient trop vieux et bons à la casse mais que ceux-ci s’adaptent bien à la logique de programmation web. Ils sont très “objet”, au risque de déplaire aux “anti-programmation-objet”, et ça marche bien sur le web (même si ce n’est pas l’idéal ailleurs).

Puisque la suite de cet article traite de Ruby on Rails, vous vous en doutez, je parlerais certainement davantage de Ruby, qui est devenue depuis quelque temps mon plaisir quotidien. Je ne suis pas un as de la programmation en général et pas encore très bon en Ruby. Mais c’est le premier langage avec lequel je me sente vraiment à l’aise. Je veux juste préciser ce point avant de continuer: j’ai surtout travaillé du côté graphisme, html et mise en page jusqu’ici.

Pour finir cette longue partie je vais juste vous présenter les deux frameworks respectifs aux deux langages présentés et qui sont actuellement considérés comme les stars du développement web. Un framework, pour ceux qui ne savent pas, est un ensemble de “fonctions” pré-programmées construites pour épargner aux développeurs finaux certains travaux fastidieux (excusez ma définition sommaire, j’essaie de faire simple).

3.4 Django: Python

Le projet DjangoDjango]] a été commencé il y a 2 ans par deux camarades américains de la petite ville de Lawrence qui ont voulu faire un site culturel pour leur ville. Il se trouve qu’ils ont voulu mettre beaucoup de choses sur leur site, une quantité impressionnante d’information. Le site n’a jamais arrêté d’évoluer et cela de manière très rapide, au grès des besoins et des envies. Programmeurs de PHP et de Java, ils se sont rendus compte que ces langages très puissants étaient également très lourds. Et s’étant mis à Python et ayant trouvé goût à ce langage, ils ont décidé de construire un framework dessus.

Django a donc été créé par passion et sur le tas, face à un problème concret: un site culturel avec beaucoup de contenu et beaucoup de liens entre les contenus (tel bar, qui a telle boisson spéciale, tel soir, programme tel groupe, qui contient tel bassiste, qui lui est bassiste dans tel autre groupe, qui joue souvent dans tel autre bar, qui a telle boisson spéciale… un vrai cercle infernal). Django a donc rapidement été orienté vers le site web de contenu important. Et le point fort de Django est d’ailleurs son interface d’administration: il suffit de décrire les bases de données du site sous Django en python pour que le framework construise toute l’interface d’administration avec gestion d’accès et de complétition correcte des formulaires.

Django en est à la v0.91 et la v1.0 ne devrait pas tarder. La communauté autour de Django commence à devenir vraiment importante.

3.5 Ruby on Rails: Ruby

Ruby on Rails a pour sa part été développé essentiellement par un danois, David Heinemeier Hansson. Ce petit danois, pendant la première année de développement a été seul à inventer et créer le premier framework complet en Ruby. Pari assez audacieux car s’il avait déjà existé des semblants de développement web en Ruby, aucun framework complet n’avait été fait. Et quel framework! Pour son travail, David (on raccourcira…) a reçu en 2005 le titre de meilleur Hacker de l’année par O’Reilly et Google (je rappelle qu’un hacker, c’est un gars bien, c’est un passionné d’informatique qui fait des exploits informatiques, ce n’est pas un Cracker qui ennuie les pauvres windowsiens).

Ruby on Rails a été écrit, comme Django, grâce à un problème concret. En effet, David et 2 graphistes ont développé pour 37 signals, une prestigieuse (petite) entreprise de web design américaine, Basecamp en Ruby. En 3 mois. Sur le côté. Le développeur au Danemark et les graphistes à Chicago. Base Camp est une “application web” d’organisation de projet très différente de ce qui est en place.

Je ne développerai davantage ni sur Basecamp ni sur Rails puisque je compte le faire dans ma seconde partie. Il y a beaucoup à dire…

Conclusion

Vous avez peut-être pu trouver que je n’ai pas été très clair dans ce que sera le web de demain mais c’est normal: je ne sais pas ce que sera le web demain. J’ai bien des idées, mais il s’agit de beaucoup de suppositions. Je voulais d’abord vous présenter ce qu’a été le web jusqu’ici, dans ses moyens et ses techniques, ce qui reste du web de la première heure et les nouveaux outils qui vont nous permettre de bâtir le web de demain.

Le web de demain, c’est peut-être, vous l’aurez compris, des applications web, des applications pour lesquelles nous avions l’habitude d’avoir un programme sur notre ordinateur. En tout cas, internet, avec ces nouvelles possibilités gagne en modularité et en indépendance (plus besoin de respecter la dictature des grosses entreprises du web); les deux framework que je vous ai présenté permettent une chose essentielle: un développement plus engageant, plus rapide et plus réactif.

Si nous envisageons de vrais programmes sur le net, les web designer ont encore bien du travail car ce sont les questions sur le GUI et l’ergonomie, posées dans les années 70 et 80, qu’il faut se poser à nouveau aujourd’hui.

Beaucoup de choses à venir, et beaucoup de choses passionnantes. Je tenterais de vous présenter de temps à autre les nouveautés dans le domaine des applications web; peut-être même faire des tests comparables aux tests d’applications lourdes faites sur Cuk!

Enfin, pour ceux qui se sentent le cœur d’explorer les coulisses du sujet, retrouvez-moi en deuxième partie, dans quelques jours, pour une présentation de Ruby on Rails qui va certainement être un acteur important du nouveau web qui se prépare.