Lilapuce
 

supports (lundi 26 janvier 2009)

Page web : les technologies en jeux [2]

Résumé de l’épisode précédent : une des façons de présenter les innombrables technologies disponibles pour réaliser une page Web, consiste à identifier deux catégories de ressources nettement distinctes l’une de l’autre : d’une part, les ressources locales , gérées par le navigateur ou l’ordinateur de l’utilisateur (HTML+CSS, Javascript, formats pris en charge par des plugins) et, d’autre part, les ressources côté serveur telles que PHP-MySQL .

À propos des sites « dynamiques »

Nous avons vu que les technologies PHP-MySQL sont généralement définies comme permettant de créer des pages « dynamiques ». Le modèle classique alors étant le suivant : d’une part, on créé quelques gabarits (HTML-CSS) afin de constituer des « pages type » sous forme de modules (home page, page de contenu détaillé, bannière d’en-tête, menus, formulaires, etc.) et, d’autre part, les contenus proprement dits (textes, images, etc.) sont stockés dans une base de données (MySQL). Dans ce schéma, les instructions écrites en PHP sont programmées afin d’afficher « à la volée » chaque contenu dans le gabarit adapté.

Cette répartition des tâches entre différentes technologies permet de dissocier deux niveaux d’information qui étaient entremêlés dans les pages statiques : le contenu et la présentation graphique. À charge de la programmation PHP d’automatiser un certain nombre de routines afin de reconstruire de façon « dynamique » (et cohérente) les contenus proposés sur le site.

L’autre avantage, qui découle de cette répartition des tâches entre composants distincts les uns des autres, c’est qu’il devient beaucoup plus aisé d’effectuer les mise à jour : une fois que les site est programmé avec un certain nombre de procédures automatisées, il suffit d’actualiser les informations en chargeant de nouveaux contenus dans la base.

Généralement, les sites conçus de cette façon comportent un espace d’administration, accessible par mot de passe, permettant d’effectuer directement toutes les tâches de maintenance et de mise à jour par l’intermédiaire du navigateur.

Site dynamique = ressources serveur ?

Nous avions insisté sur le fait que PHP-MySQL correspondait à des « ressources serveur » afin de bien faire comprendre le rôle (limité) que joue le navigateur - à lui seul - dans la création des pages Web modernes.

Pour autant, il serait erroné de considérer que « dynamique » est obligatoirement synonyme de « ressource serveur ». Deux exemples significatifs peuvent être proposés pour illustrer comment des technologies de création de pages dites « dynamiques » peuvent totalement échapper aux ressources serveur :

Flash

Certains format de fichiers gérés par des plugins du navigateur, en particulier, Flash, permettent de réaliser de véritables programmes interactifs.

S’il est possible de relier ces programmes à des ressources serveur, rien n’empêche de faire appel au puissant langage de programmation de Flash (ActionScript ) afin de s’affranchir - justement - des ressources réseau (ce qui est très fréquent, pour ne pas dire le cas général).

Très souvent, l’animation Flash s’affiche dans la fenêtre du navigateur, comme s’il s’agissait de pages HTML « classiques » alors qu’en réalité tout « se joue » par le plugin, après téléchargement du fichier. Cette situation peut d’ailleurs entraîner certaines perturbations pour l’utilisateur : impossibilité d’enregistrer une image selon la procédure standard, non prise en charge du handicap visuel, etc.

Quoi qu’il en soit, Flash est certainement l’exemple le plus caractéristique d’un contenu pouvant être généré de façon totalement « dynamique » sans utiliser les ressources serveur. D’autres technologies, telles que les Applets Java correspondent à la même logique de traitement (même si ces technologies n’ont aucun rapport l’une avec l’autre) : après téléchargement, le fichier est pris en charge ( de façon plus ou plus transparente) par une ressource locale (la machine virtuelle Java, dans le cas d’une Applet).

Javascript-AJAX

Le cas de Javascript et, en particulier, comment ce langage est utilisé dans AJAX, représente un autre exemple de ressources « dynamiques » prises en charge « côté local ». Dans ce cas, le développeur du site conçoit des scripts (ou fait appel à des « bibliothèques ») permettant de charger « à la volée » des instructions traitées directement par le navigateur.

Dans le schéma général, tout l’intérêt d’AJAX, repose sur le fait qu’il est inutile de recharger la totalité d’une page depuis le serveur s’il ne s’agit que d’en actualiser juste une partie (par exemple, un menu déroulant). Ce sera donc uniquement le module à actualiser (après un clic sur le menu) qui sera chargé localement et interprété par le navigateur (via Javascript). On économise ainsi de la bande passante et la navigation semble plus fluide.

De fait, il s’agit bien d’un processus « dynamique » dans la mesure où les composants interactifs sont ajoutés par modules selon les événements provoqués par l’utilisateur, mais, contrairement aux instructions classiques PHP-MySQL, la reconstruction du contenu de la page est prise en charge localement sur le poste du visiteur, par ajouts successifs.

Il était nécessaire, à mon avis, d’apporter ces distinctions entre « ressources serveur » et « site dynamique » car, il est fréquent que les deux termes soient associés, ce qui peut entraîner quelques confusions.

Une confusion plus générale, d’ailleurs, se retrouve dans l’emploi d’expressions génériques telles que « Web 2,0 », « Réseaux sociaux » ou « Web participatif » qui ne recoupe réellement aucune technologie précise mais plus les usages.

Voilà pourquoi il nous faut, maintenant rentrer un peu plus dans le détail de notre présentation afin d’apporter quelques précisions essentielles sur ces technologies.

Complexité des technologies

Tel que je l’ai indiqué sur le précédent support, plus personne aujourd’hui n’envisage de monter son projet Web sur le modèle « site perso à papa » tel qu’on le faisait il y a dix ans, à base de pages statiques HTML. Nous avions vu également que l’apprentissage du HTML (ne s’agissant pas d’un langage de programmation) est relativement accessibles à un utilisateur non-informaticien.

Or, quel que soit le moyen utilisé (que nous verrons un peu plus loin), il faut bien prendre en compte que la totalité des solutions alternatives reposent sur des technologies complexes, dont la totale maîtrise - contrairement au HTML - exigent des connaissances en programmation qui ne s’improvisent pas.

Reprenons l’exemple PHP-MySQL : contrairement à ce qu’il est fréquent de trouver en quatrième de couverture des ouvrages de vulgarisation informatique ou nombre de sites Web, la création d’un site « dynamique » totalement personnalisé - c’est à dire, la réalisation des fichiers sources - (la distinction est importante, comme nous le verrons) écrit en PHP et conçu pour être interfacé avec une base de donnée MySQL exige un niveau de connaissance informatique qui s’avère extrêmement ardu, voire carrément impénétrable au « non informaticien ».

Bien entendu, cette appréciation peut sembler très subjective : un étudiant en mathématique ou en physique, habitué à manier couramment les abstractions algorithmiques pourra tout à fait trouver ses repères dans cet univers de programmation et développer assez rapidement son projet. De même, à force d’obstination, quelques vocations inattendues (plus ou moins forcées, plus ou moins laborieuses) pourront de révéler dans les profondeurs du code PHP.

Toutefois, il est indispensable de prendre en compte une réalité incontournable : PHP est un vrai langage de programmation. N’attendez pas de pouvoir rentrer dans ce langage par l’intermédiaire d’une quelconque interface qui vous éviterait d’en faire l’apprentissage. À mettre en ligne un site construit à base de sources bricolés que vous ne maîtrisez pas (copiés-collés depuis Internet), vous risquez de compromettre la sécurité de votre site, de vous « griller » vis à vis de votre hébergeur et de ruiner votre réputation.

Donc exit la solution directe PHP-MySQL pour les non-informaticiens.

Qu’en est-il des autres technologies abordées plus haut ?

Voici, quelques éléments de réponse :

Flash

Contrairement à PHP, cette technologie permet de s’affranchir (jusqu’à un certain point) de l’apprentissage de la programmation informatique. L’interface « Wysiwyg » peut sembler - de prime abord - relativement conviviale : une timeline représente l’échelle de temps sur laquelle on peut placer des « images clés » de façon à créer notamment des interpolations et diverses actions provoquées par l’utilisateur.

Contrairement à PHP, également, Flash n’est pas un logiciel libre. Édité par la société Adobe (après absorption de Macromedia, le précédent éditeur), Flash est fourni sous la forme de deux composants distincts :

- le plugin gratuit à installer sur le navigateur pour visualiser les animations au format .swf

- l’environnement de développement Flash, permettant de réaliser les dites animations (pour les insérer dans des pages HTML). Un programme payant (plusieurs centaines d’euros), résolument orienté « professionnel », ce qui explique en partie l’absence de ce programme sur les ordinateurs de la salle 301.

Il faut toutefois signaler que des solutions « libres » (plugin et environnement de développement) compatibles avec Flash sont disponibles. Le coût de Flash n’est donc pas la principale raison pour laquelle cette technologie n’est pas proposée dans notre atelier.

A l’usage (pour faire vite) la pratique de Flash s’avère beaucoup plus complexe qu’elle semble au premier abord (surtout pour réaliser un « vrai site »). L’apprentissage du langage de programmation ActionScript semble quasiment incontournable pour peu que l’on s’aventure à réaliser autre chose que de simples animations en boucle (bandeau de pub, par exemple).

Java

C’est un véritable « langage de programmation objet », avec environnement de développement et compilateur. Java, contrairement à Flash, est un logiciel libre (édité par la Sun MicroSystem) ce qui le rend d’ailleurs assez populaire auprès des programmeurs.

Contrairement à PHP (par exemple) Java n’est pas uniquement orienté vers des applications Web. Avec ce langage, on peut programmer n’importe quelle application à installer sur l’ordinateur (et même un système d’exploitation). J’ai déjà évoqué le fait que Java était connu pour ces fameuses Applets (je féminise toujours ce mot, car je trouve que c’est beaucoup plus joli ainsi) ; je rappelle qu’il s’agit de petits programmes exécutés, après téléchargement, par la machine virtuelle installée sur l’ordinateur.

Le grand intérêt de ce langage réside dans sa portabilité : le même code (Bytecode) de l’Applet est interprété localement, quel que soit le système d’exploitation (Mac, Windows, Linux, etc.), pour peu que l’ordinateur soit équipé d’une machine virtuelle Java (ce qui est peu ou prou le cas général, malgré quelques tentatives d’obstruction de la part de Microsoft). Une particularité qui fait de ce langage une solution particulièrement adaptée au réseaux pour transmettre des données sous forme de programmes (les Applets, donc). Néanmoins, il serait très réducteur de considérer que les solutions Web de Java se limitent aux Applets (qui se jouent « côté local ») : Java est également très utilisé en tant que ressources serveur (Servlets), notamment pour de grosses applications en ligne professionnelles.

Même s’il est possible de récupérer quelques petits modules Java prêt à l’emploi sur Internet , ce langage s’avère être aussi compliqué (si ce n’est beaucoup moins abordable) que le PHP.

Javascript - AJAX

Javascript, est souvent considéré comme « plus abordable » que, par exemple, le PHP ou Perl (un autre langage permettant de commander des ressources serveur).

Force est de constater que le but de ce langage ne consiste, la plupart du temps, « qu’à » intervenir sur divers objets constituant l’environnement local du visiteur de site web : par exemple, l’imprimante, la souris, mais surtout le navigateur et tous les éléments affichés à l’intérieur du navigateur (les fenêtres et chaque objet HTML de la page). Comme nous l’avons déjà observé, Javascript n’est pas prévu, par exemple, pour manipuler des instructions ayant un rapport avec une base de données pas plus qu’il n’est capable de s’interfacer avec une ressource en ligne, tel que le fait, par exemple le PHP pour afficher de façon dynamique un nouveau contenu depuis le serveur. Ce sont des particularité qui limitent la portée, donc, dans une certaine mesure la complexité de ce langage (bien que la syntaxe de ce langage s’apparente totalement à celle d’un « vrai » langage de programmation).

Une autre raison, peut-être moins avouable, de la « simplicité » de ce langage réside dans le fait que le web regorge de scripts prêts à l’emploi : par copier-coller il est possible d’incorporer une multitude d’effets à ses pages (certains, tels que les traces sur le mouvement de souris étant à la limite du gadget). Le problème c’est que beaucoup de ces utilisateurs de scripts prêts à l’emploi s’étonnent, après coup, que leur pages soient mal référencées par les moteurs. La présence d’un code Javascript prêt à l’emploi et non optimisé, directement intégré dans le source HTML, peut être l’une des cause de ce déficit de visibilité : généralement placé dans l’en-tête du source, ce code apparaît au robot du moteur comme une véritable barrière qui l’empêche d’accéder au contenu réel de la page (ce qui est pris en compte dans l’index du moteur).

Quant à AJAX, bon courage : de solides connaissance en HTML-CSS (voir supports), la maîtrise de Javascript (en particulier XMLHttpRequest de façon à pouvoir charger depuis le serveur certains composants qui viennent s’intégrer dans la page), la connaissance du DOM (pour manipuler indépendamment chaque objet du document) et du XML (langage à balise, considéré comme le successeur du HTML, dont le champ d’action va bien au-delà des pages Web) … Telles sont les connaissances qu’il faut intégrer pour aborder cette méthode de traitement dynamique des pages « côté local ».

Autan dire qu’il est préférable de ne pas commencer sa première expérience de codage Web avec AJAX.

Je ne passerai pas en revue les autres technologies ou langages de programmation utilisables pour créer un site Web ; citons, toutefois, à titre d’exemple : le concept même de Framework (tel que Ruby on Rails), Xul, Python,, Flex, .Net...

Mais, encore une fois, dans tous les cas, nous avons affaire à des technologies extrêmement sophistiquées, complexes et spécialisées qui nécessitent un savoir-faire de programmation qui, si ce n’est pas obligatoirement celui d’un professionnel, correspond au moins à l’approche d’un amateur éclairé de la programmation ; voire, d’un individu franchement allumé, qui s’épanouit par l’immersion dans le code informatique : bref, un hacker. Il serait totalement illusoire et trompeur de prétendre autre chose.

Vous l’aurez compris, le codage de sources de « sites dynamiques » n’est pas au programme de cet atelier : je n’ai pas la compétence ni la volonté de m’engager pour l’instant sur ce terrain.

Alors, faut-il prendre les jambes à son cou ?

Le plateformes de type Blog

Non, vous participez bien à un atelier « Blog-pages web » et l’objet de cet atelier du lundi consiste toujours à vous permettre de construire votre projet, en essayant de vous présenter de façon un peu plus précises les solutions qui sont à votre disposition.

Il existe, fort heureusement, de nombreuses alternatives à la programmation de sites dynamiques. Vous en avez déjà eut un aperçu au travers de plateforme de blog en ligne - très connues du public - telles que Blogger, CanalBlog, Skyblog, Myspace, voire même FaceBook. Sur ces plateformes, il est très facile de mettre en ligne un contenu sans avoir à insérer le moindre code informatique ni se soucier des composants qui interviennent en arrière plan.

Vous savez désormais quels types de ressources sont utilisées sur ces plateformes, : il s’agit d’une façon ou d’une autre, des technologies abordées sur le présent support.

Première caractéristique de ces blog, en ligne ainsi que des autres solutions que nous verrons plus tard dans cet atelier : nous avons affaire à des sites dynamiques, reposant, comme nous l’avons vu, sur la séparation des niveaux de traitement : stockage de données dans une base, modules de présentation disponibles sous la forme d’un certain nombre de templates et, enfin, programme chargés d’exécuter un certain nombre de routines.

A cela vient s’ajouter encore un autre niveau de séparation : le gestionnaire du site n’est désormais plus obligé d’être peu ou prou technicien informatique. Les niveaux de compétences sont clairement délimités : gestion des contenu pour l’un, gestion de procédures techniques pour l’autre. Peu importe qu’on nomme untel webmaster, administrateur ou rédacteur : chacun peu s’attacher à sa spécialité, ce qui n’était pas aussi clairement défini avec les technologies plus anciennes.

Par l’intermédiaire d’interface conviviales et intuitives, il est donc possible de faire appel à des technologies très spécialisées sans avoir à rentrer de façon intime avec le code informatique nécessaire à leur mise en action.

Gérer son blog est une opération guère plus compliquée que traiter sa messagerie sur Gmail ou Yahoo. La comparaison vaut d’ailleurs d’être retenue : qu’il s’agisse d’un Webmail ou d’une plateforme de blog, dans un cas comme dans l’autre, il s’agit d’applications en ligne, avec accès privé.

Dans le cas du blog, toutefois, nous avons une configuration spéciale, avec deux espaces distincts, que nous retrouverons quelle que soit la solution abordée :

- le FrontOffice ou « site public », visible par le monde entier

- le backoffice ou « site privé », accessible au(x) seul(s) gestionnaire du site

Ces plateformes proposent des fonctionnalités plus ou moins étendues, mais vous remarquerez que, dans tous les cas, il existe des contraintes infranchissables.

Sur Blogger, par exemple, s’il est possible de personnaliser l’apparence des pages (couleurs, logo dans l’en-tête, disposition des éléments, utilisation de templates, etc.) il est quasiment impossible de créer une arborescence de contenu en rubriques et sous-rubriques.

Si cette possibilité est donnée, par exemple, sur une autre plateforme, telle que CanaBlog, on se rend compte, que néanmoins, d’autres limites apparaissent (par exemple, l’impossibilité d’utiliser en même temps, deux templates différents, chacun correspondant à des types ou niveaux distincts de contenu.

Voilà encore une autre particularité à laquelle il va falloir s’habituer : ce que nous gagnons en facilité d’accès, nous le perdons en rigidité, au détriment de notre capacité à personnaliser notre projet.

Pour fonctionner, ces plate-formes doivent mettre en place un certain nombre de procédures automatisées, exactement comme dans le schéma présenté ci-dessus d’un site dynamique construit en PHP-MySQL. La seule différence, c’est qu’au lieu de définir la liste de procédures automatisées en fonction d’un projet particulier (ce qui est le cas, par exemple, dans le cade d’une prestation d’un développeur Web), les plateformes définissent un certain nombre de routines applicables à tous les projets qu’elles hébergent.

Qui dit automatisation dit systématisation, donc tendance à ne pouvoir gérer « le cas particulier ».

Nous verrons, qu’il existe encore d’autres possibilités que les blogs en ligne : les CMS. Ces applications qui ont précédés les Blogs et qui restent encore largement d’actualité, permettent - sous certaines conditions - de créer de véritables projets Web, avec beaucoup plus de souplesse que l’offrent généralement les blogs en ligne.

Mais de cela, nous l’évoquerons donc sur le prochain support.