Quelle place pour l’usager internaute ?
Connaissez-vous l’architecture client/serveur ?
Alors, pour faire vite il existe deux grands type d’architecture informatique :
a) Le Mainframe associé à un client léger :
Voici le Mainframe |
Et voici le client léger, par exemple un Minitel : |
Dans ce cas tout est dans l’ordinateur (de calcul) et les données (ici de vieilles bandes magnétiques) sont sur le serveur mainframe (ici un IBM 3420/3803), le client léger se contente d’afficher les réponses que le serveur lui a envoyé.
b) L’architecture Client/serveur. Cette fois-ci le serveur ne fournit que les données et le client (en général un PC) effectue les calculs. Par exemple quand vous interrogez un serveur Web, vous entrez l’adresse dans votre navigateur, des paquets IP traversent le réseau jusqu’au serveur, le serveur répond en renvoyant d’autres paquets IP qui contiennent les données de la page et votre ordinateur « calcule » les données pour les produire dans l’interface du navigateur. Le but de cette architecture est de faire en sorte que le moins de données possibles aient à circuler sur le réseau, ce qui implique que le poste client remplisse sa part du boulot et donc qu’il soit doté d’un processeur et d’une carte graphique, etc..
Notez que l’architecture client/serveur se joue en local dans n’importe quel PC entre les données inscrites sur les disques durs et les applications. Détail qui a sont importance, un serveur digne de ce nom est capable de servir plusieurs milliers de clients simultanément, alors que votre PC n’est configuré que pour répondre à seul client.
Comme la puissance des ordinateurs individuels a considérablement augmenté en 20 ans, aujourd’hui on se retrouve face à un réseau de machines où il y a d’un côté des serveurs Web (de simples PC équipés d’un logiciel serveur (Apache par exemple) auquel on retire l’écran et le clavier et que l’on administre à distance) et de l’autre des PC (qui sont donc aussi des serveurs). La question est donc quel rôle on attribue à chaque machine : effectuer des requêtes ou répondre à ces requêtes.
Le Web 1.0 se présente comme un ping-pong. Le PC fait un ping, le serveur répond : pong. On clique sur un lien, ping, une nouvelle page s’affiche, pong. C’est un peu lassant, et certains se sont dits que c’étaient trop contraignant, d’où l’idée d’effectuer un certain nombre de choses en local.
Par exemple quand vous postez sur un forum ou quand vous écrivez un mail sur une messagerie Web. Tant que vous n’avez pas cliqué sur envoyer, tout se passe en local, or pourtant vous êtes dans le navigateur Web comme si vous étiez sur le Web, et vous êtes sur le Web puisque les données que vous voyez ne sont pas sur votre machine mais sur le serveur Web, à cela près que les mots que vous êtes en train de taper ne sont nulle part ni sur votre machine, ni sur le serveur Web, elles sont à proprement parler virtuelles. (Pour être précis, elles ne sont encore écrites nulle part, elles flottent).
Vous êtes exactement dans la même situation que l’utilisateur de Mosaic ou de Netscape 2.0 en 1993/94 qui détient les droits de la page et qui la met à jour.
Aujourd’hui le Web 2.0 pousse cette logique de (re)localisation des applications plus loin. L’idée est de rendre le contrôle à l’utilisateur des scripts/langages de programmation qui sont généralement contenus à l’intérieur du serveur.
Il y a deux manières de procéder. La bonne et la mauvaise. Commençons par la mauvaise pour l’utilisateur lambda : il devient développeur Web. Ça lui prendra beaucoup de temps, et il n’aura un usage pertinent de ses nouvelles compétences que dans un cadre professionnel. La bonne, on lui met à disposition des applications à travers le navigateur Web.
Un exemple tout simple : www.netvibes.com (On y va et on joue avec les fenêtres).
On retrouve Tariq en images :
