Le site créé est fractionné en deux zones : l'une publique accessible à l'ensemble des internautes ; l'autre privée, réservée aux élèves et enseignants, au moyen d'un accès restrictif (cf. Figure 4).

Figure 4 : Architecture globale du site

La partie publique correspond, en quelque sorte, à un site web classique : présentation de l'école, de ses activités, diffusion d'informations scolaires, extra-scolaires, municipales etc. Cette section présentant un intérêt moindre, nous avons donc choisi de ne pas la développer dans le cadre de ce projet.

La partie privée regroupe l'ensemble des outils développés spécifiquement pour les écoles. Elle est composée d'un ensemble de modules basés sur diverses technologies (DHTML, PHP, PERL, bases de données...) utilisant des ressources elles aussi diverses : texte, image etc. Ces modules ont été regroupés en trois sections - Jouer, Communiquer, Etudier - qui seront détaillées plus loin.

Une séparation entre partie publique et partie privée était nécessaire principalement pour trois raisons :

• protéger l'enfant et son image : la photo ou le nom d'un élève, par exemple, ne doivent pas sortir du cadre scolaire
• protéger la zone privée vis à vis des "attaques" extérieures : ici, il s'agit surtout d'éviter de rentrer en contact avec les enfants.
• instaurer une relation de confiance dans la partir privée autorisant une politique de sécurité plus laxiste (identification des élèves, contrôle des uploads)

Le contrôle d'accès en zone privée se fait par mot de passe (cf. Figure 5), ce dernier devant être connu uniquement des enseignants et des aides éducateurs. Une fois ce contrôle passé, l'élève s'identifie au moyen d'un formulaire associé à une base de données (cf. Figure 6). Cette opération aboutit à la création d'un cookie qui permet de l'identifier durant toute la durée de sa session pour que les diverses applications en tiennent compte.

Figure 5 : Mécanisme d'identification

Le cookie regroupe les informations suivantes :

• login : identifiant d'élève (clef primaire de la base de données)
• nom : nom
• prenom : prénom
• classe : niveau de l'élève CM1, CM2 etc.
• ecole : école à laquelle est rattachée l'enfant

Figure 6 : écran d'identification de l'élève

A la base, l'idée fût de concevoir quelques jeux d'éveil et de réflexion, en collaboration avec les enseignants. Dans le cadre du R.A.D., nous avons commencé par leur présenter un puzzle en DHTML trouvé sur le site webreference. Cette application présentait de nombreux avantages :

• le principe du puzzle est connu par tous les enfants
• le jeu n'est pas statique : on peut choisir l'image à reconstituer, le fractionnement
• visuellement l'application est légère et agréable : les pièces du puzzle semblant être véritablement éparpillées à l'écran

3.2.1  Choix technologiques

Ayant l'aval des enseignants, nous avons étudié cette application afin de la reproduire et l'étendre selon nos besoins. Ceci nous a permis d'apprendre le DHTML et de constater que cette technologie était particulièrement adaptée pour faire de façon relativement simple et efficace toutes sortes de jeux.

En effet, deux techniques semblaient possibles à l'origine :

• le couple Java-applet (application au sein d'un navigateur web)
• le DHTML (HTML dynamique)

La première solution permet de disposer de toute la puissance de Java, de sa portabilité et de ses nombreuses APIs qui permettent de tout faire ou presque. Mais cette puissance a un prix : un code certes clair mais néanmoins important et surtout une lenteur de chargement et d'exécution dès l'instant où l'on a recours à des primitives graphiques.

La seconde solution qui consiste en fait à manipuler des objets du DOM (Document Object Model) au moyen de routines JavaScript, permet de créer des applications graphiques interactives relativement facilement. Le code correspondant est certes moins élégant que du 100% objet mais il a l'avantage d'être concis et surtout d'être exécuté rapidement. Enfin, le DHTML permet de gérer facilement et efficacement le drag and drop, manipulation que l'on trouve à la base de nombreux jeux.

La rapidité de chargement et d'exécution fût déterminante dans le choix de DHTML. En effet, l'utilisateur lambda n'aime pas attendre et les enfants encore moins ! Le temps de chargement d'une applet couplé à celui d'une image aurait été simplement rédhibitoire pour obtenir au final une application d'apparence simple.

C'est donc ainsi que le DHTML a été retenu pour développer des applications ßimples" (i.e. des jeux à un joueur), les applications "complexes" (i.e. des jeux multi-joueurs à travers le réseau) nécessitant une architecture client/serveur que n'offrent évidemment pas DHTML et JavaScript.

L'ensemble des applications DHTML développées pour ce projet fonctionne exclusivement sous le navigateur Internet Explorer (à partir de la version 4 et de façon optimale sous sa version 5). C'est un choix délibéré. En effet, c'est le navigateur qui exploite au mieux le DHTML : code concis, machine graphique performante etc. Il est possible de transformer ces applications dédiées en applications cross-browsing (i.e. fonctionnant sur tous les navigateurs) moyennant un code de taille double (au minimum) chaque navigateur ayant ses propres noms d'objets, de méthodes et des fonctions plus ou moins puissantes. Ceci n'étant pas l'objectif du projet et sachant que les écoles partenaires étaient toutes équipées d'IE5 nous avons donc décidé, dans un premier temps, de développer ces applications exclusivement pour IE5.

3.2.2  Principes généraux

Quatre jeux ont été créés :

• Puzzle : un puzzle "classique"
• Anagramme : retrouver un mot à partir de ses lettres
• Symboles : associer des symboles identiques
• Symétrie : reconstituer un motif selon un axe de symétrie

Dans un souci de clarté, chaque jeu se compose de deux pages HTML consécutives : la première permet de le paramètrer et éventuellement de l'administrer, la seconde correspond au jeu proprement dit.

Le paramétrage

Ces différents jeux s'adressant à un large public, aussi bien des maternelles que des primaires, il est donc indispensable de pouvoir paramètrer leur difficulté de façon à les adapter au niveau du joueur.

Ce paramétrage de la difficulté du jeu permet non seulement de l'adapter au joueur mais aussi d'augmenter sa durée de vie. Il incite également le joueur à progresser en choisissant un niveau toujours plus difficile.

Certains jeux offrent la possibilité de choisir les ressources à utiliser (choix de l'image pour le Puzzle ou choix des pièces dans Symboles) au moyen d'un formulaire.

L'administration

Afin de maintenir un intérêt aux jeux, nous avons vu qu'il était impératif que ceux-ci soient renouvelés : il est hors de question de proposer un puzzle avec cinq images ou trois motifs différents à reproduire.

Pour palier à ce problème de durée de vie nous avons opté pour deux solutions :

• Si le jeu le permet, le contenu est renouvelé automatiquement par génération aléatoire,
• sinon les enseignants ou même les élèves peuvent enrichir le jeu avec leurs propres ressources.

C'est ainsi que, par exemple, on peut ajouter des nouvelles images pour le puzzle ou que le jeu Symétrie propose à chaque fois un nouveau motif généré aléatoirement.

Le plus simple pour ajouter des ressources aux différents jeux aurait été de demander aux utilisateurs d'utiliser un client FTP afin d'uploader leurs fichiers sur le serveur du site. Cette solution a été rejetée en raison du cahier des charges : pour un non informaticien, uploader un fichier n'est pas chose facile. En effet, il faut utiliser une nouvelle application, connaître l'adresse du serveur, éventuellement un mot de passe, savoir où mettre le fichier etc.

Pour que l'ajout de ressource se fasse simplement, il fallait arriver à masquer toute cette partie technique et se contenter d'indiquer le fichier à ajouter. Pour ce faire, nous avons conçu un formulaire d'administration propre à chaque jeu, permettant de l'enrichir de façon totalement transparente. Un ensemble de fonctions PHP se chargent ainsi d'ajouter ou supprimer des ressources sur le serveur.

Le déroulement du jeu

Tous les jeux DHTML sont basés sur le trio HTML, CSS, JavaScript.

Le DHTML (Dynamic HTML) permet de réaliser des pages HTML animées et interactives réagissant à des événements souris ou clavier.

Les CSS (Cascading Style Sheet) ou feuilles de style permettent de définir des classes d'objets et de les doter d'attributs : couleur du texte, position, visibilité, z-index etc.

Le JavaScript est un langage de script offrant une vision orientée objet du document et toutes les structures d'un langage de programmation. Il permet en particulier de manipuler les objets constituant la page HTML que l'on a défini dans la feuille de style.

Les différents jeux sont très proches techniquement et reprennent donc un grand nombre de fonctions. En effet, tous (jeu des symétries excepté) consistent à déplacer par drag and drop des composants dynamiques (pièces) pour les replacer correctement. Pour faciliter l'évaluation et la correction, chaque jeu dispose d'une zone graphique sensitive dite "zone de correction". C'est dans cette zone que les pièces doivent être disposées.

Les paramètres du jeu fixés à la première page sont enregistrés dans un cookie, la seconde page de jeu est composé de façon dynamique par une fonction JavaScript init() appelée lors du chargement de la page grâce au tag < BODY ... onLoad="init()" > .

Cette fonction init() initialise l'ensemble des paramètres et du jeu génère les divisions HTML adéquates : les composants dynamiques et la zone de correction.

L'exemple ci-dessous correspond à la création des divisions pour le jeu du Puzzle. Une pièce du puzzle correspond à une division, la variable puzzPieces au nombre total de pièces à créer.

// Creation des divisions des pieces du puzzle :
for (i=1; i<=puzzPieces; i++) {
  divStr = "<DIV ID=PIECE"+i+" CLASS=clPiece>";
  divStr+= "<IMG name=imPiece" +i+"></DIV>";
  document.body.insertAdjacentHTML("BeforeEnd", divStr);
  eval("PIECE"+i).style.pixelLeft = origineX;
  eval("PIECE"+i).style.pixelTop  = origineY;
}

Une fois la page et ses composants générés, il faut implémenter des fonctions pour prendre une division (function grabEl(e)), la déplacer (function moveEl(e)) et la relâcher (function dropEl(e)).

Les fonctions grabEl(e) et moveEl(e) sont quasiment identiques pour tous les jeux et sont relativement simples.

La fonction dropEl(e) est par contre plus complexe puisqu'elle correspond, en quelque sorte, à la fin d'un tour de jeu. Tout d'abord, il faut détecter si la pièce manipulée est lâchée au-dessus de la zone de correction. Si oui, il faut ensuite placer automatiquement la pièce par "magnétisation" (on ne demande pas au joueur d'ajuster la pièce au pixel près mais simplement de la lâcher au-dessus d'un quadrillage "virtuel" ) mais avant, il faut vérifier qu'il n'y a pas déjà une pièce en dessous afin de ne pas masquer celle-ci. Si tel est le cas, la pièce est rejetée sur le côté. Enfin, une fois la pièce placée, il faut encore évaluer la nouvelle configuration du jeu : Est-ce fini ? ... et dans l'affirmative, est-ce gagnant ?

L'évaluation

Nous nous sommes rapidement aperçus qu'un système d'évaluation se contentant de comparer la configuration proposée dans la zone de correction avec la configuration gagnante et, en cas d'adéquation, de signaler au joueur qu'il a gagné, était insuffisant. En effet, face à un tel ßilence", le joueur se sent vite seul et son intérêt pour le jeu décline rapidement.

Devant ce problème, nous avons réfléchi à une fonction d'évaluation qui, après chaque coup joué (i.e. un composant placé sur la zone de correction), calcule le pourcentage de pièces bien placées et détermine le niveau d'avancement de la configuration courante du jeu par rapport à la solution. En fonction du niveau atteint, on génère un commentaire adapté : "c'est un bon début", "déjà une moitié de faite", etc.

En plus de cette détection de progression, on va également détecter les erreurs pour encourager le joueur en cas d'échecs successifs.

Pour ce faire, on fixe ün taux d'erreur acceptable" fixant le nombre de coups incorrects pouvant être joués à la suite et on compte le nombre de coups incorrects consécutifs. Dès que cette variable dépasse le taux d'erreur : on génère un commentaire de type Ättention, concentre-toi un peu plus !". Dès qu'un coup est correct, un message d'encouragement le signale au joueur et le compteur d'erreurs est réinitialisé.

Cette méthode est plus agréable et plus pédagogique qu'une analyse mécanique signalant systématiquement "coup incorrect" à chaque erreur. En effet, il vaut mieux laisser le joueur constater ses erreurs et l'encourager lorsqu'il les résout.

Cette évaluation automatique est composée de deux fonctions :

• function nbOK() qui retourne le nombre de pièces bien placées
• function evalGame () qui évalue et commente le jeu après chaque coup

La fonction init() appelée au chargement de la page HTML se charge de fixer les paliers d'avancement ainsi que le taux d'erreur acceptable. Après chaque coup evalGame() grâce à nbOK() détermine le niveau d'avancement du jeu et génère un commentaire adéquat.

La correction

Il est impératif d'aider un élève en difficulté pour éviter qu'il se sente dans une impasse. Plutôt que d'afficher directement la solution, nous préférons lui offrir la possibilité de repartir sur de bonnes bases. Tout les jeux proposent donc une fonction de correction qui, à son appel, se charge d'annuler tous les coups incorrects.

3.2.3  Le jeu du Puzzle

Ce jeu est un puzzle "classique" : il s'agit de reconstituer une image préalablement éclatée. L'écran de paramétrage (cf. Figure 7) permet de choisir l'image à reconstituer ainsi que le fractionnement horizontal et vertical.

Figure 7 : paramétrage du Puzzle

Grâce au formulaire d'administration (cf. Figure 8), le puzzle peut être enrichi en ajoutant de nouvelles images. Il est également possible de supprimer une image. Actuellement, la taille des images doit être fixée à 300x300 pixels. Cette contrainte peut être abolie mais il faut impérativement contrôler la taille des images proposées de façon à éviter un puzzle avec une image en 800x600 (problèmes de temps de chargement et de mise en page !).

Figure 8 : administration du Puzzle

Une fois les paramètres fixés, le joueur arrive sur l'écran de jeu (cf. Figure 9) où il peut voir l'image à reconstituer. Un clic sur le bouton Mélanger provoque son éclatement. Les pièces du puzzle peuvent être manipulées par drag and drop ; celles-ci doivent être placées sur la zone de correction qui donne le gabarit de l'image. A tout moment le joueur peut afficher l'image à recomposer en cliquant sur le bouton Modèle.

Figure 9 : écran de jeu du Puzzle

Au fur et à mesure du jeu, la fonction évalue la reconstitution de l'image et génère un commentaire adéquat.

En cliquant sur Correction, l'application nettoie la zone de correction en ne conservant que les pièces bien placées.

3.2.4  Le jeu des Anagrammes

Anagramme consiste à retrouver un mot dont les lettres ont été mélangées. Pour faciliter le jeu, le joueur choisit au départ une liste de mots de même longueur dans laquelle le mot à retrouver sera choisit aléatoirement (cf. Figure 10).

Comme pour le puzzle, Anagramme dispose d'une fonction d'administration (cf. Figure 11) similaire où l'on peut saisir ses propres listes de mots. Ici, la seule contrainte est de rentrer, pour une même liste, des mots de même longueur.

Figures 10 et 11 : paramétrage et administration d'Anagramme

Une fois la liste choisie, le joueur arrive sur l'écran de jeu (cf. Figure 12) où sont éparpillées les lettres d'un mot choisit aléatoirement dans la liste. Ces lettres, semblables à des pièces de Scrabble, se manipulent par drag and drop de la même façon que pour le puzzle. Là aussi la magnétisation des pièces pour faciliter leur disposition ainsi que le recouvrement.

En bas de l'écran, s'affiche la liste précédemment choisie afin de permettre de retrouver le mot plus facilement.

Figure 12 : écran de jeu d'Anagramme

Après chaque coup, evalGame() compare la chaîne de caractères proposée dans la zone de correction avec le mot à retrouver et génère un commentaire en fonction du nombre de lettres bien placées.

Un clic sur le bouton Correction rejette les lettres incorrectes, un clic sur le bouton Nouveau permet de rejouer avec un nouveau mot tiré dans la même liste.

3.2.5  Le jeu des Symboles

Le jeu des Symboles est basé sur le principes des associations. Le programme tire aléatoirement une série de symboles dans une liste fixée par le joueur ensuite, le joueur doit associer les symboles par paire afin de reproduire la même séquence.

Ce jeu doit permettre d'aider les élèves à distinguer des formes symétriquement proches pour éviter de confondre ainsi les lettres dont la graphie est semblable : b et d, p et q etc.

Dix huit symboles différents sont disponibles, de forme plus ou moins complexe. L'écran de paramétrage (cf. Figure 13) permet de choisir avec lesquels on veut jouer ainsi que la longueur de la séquence à reproduire.

Figure 13 : paramétrage des Symboles

L'écran de jeu (cf. Figure 14) propose la séquence à reproduire ainsi que le jeu de symboles que l'on a fixé à l'écran précédent. Les pièces se manipulent également par drag and drop et doivent être disposées sur la zone de correction placée sous la séquence à reproduire.

Figure 14 : écran de jeu des Symboles

Après chaque coup, evalGame() compare les symboles deux à deux et génère un commentaire en fonction du nombre de couples corrects.

Un clic sur le bouton Correction rejette les symboles mal associés, un clic sur le bouton Nouveau permet de retirer une nouvelle séquence.

3.2.6   Le jeu des Symétries

Le jeu des Symétries est sensiblement différents des jeux précédents. En effet, celui-ci ne propose pas de composants à manipuler. Ici, il s'agit de reproduire un motif (damier) généré aléatoirement selon un axe de symétrie.

L'écran de paramétrage permet de fixer le complexité du motif (nombre de lignes et de colonnes) ainsi que l'axe de symétrie (horizontal ou vertical). Il n'y a pas de formulaire d'administration la ressource du jeu étant générée aléatoirement.

L'écran de jeu (cf. Figure 15) propose donc deux damiers, l'un correspond au motif généré aléatoirement l'autre, vierge, correspond à la zone de jeu.

Figure 15 : écran de jeu des Symétries

Le jeu consiste donc à reproduire le motif sur le damier vierge selon l'axe de symétrie fixé. Pour ce faire, le joueur, clique sur les cases du damier vierge afin d'en modifier la couleur.

Comme pour les jeux précédents, l'évaluation et le commentaire du jeu se fait au moyen de la fonction evalGame() qui, après chaque coup génère un commentaire en fonction de l'état du jeu.

On retrouve là aussi les boutons Correction et Nouveau.

Dès le début de ce projet, nous souhaitions faire bénéficier les écoles de tous les moyens d'expression et de communication offerts par Internet. Très tôt, nous nous sommes aperçus que les deux écoles souhaitaient communiquer entre elles pour favoriser la réalisation de projets pédagogiques communs, mais aussi pour correspondre avec toute autre école connectée.

De même que dans la vie courante, la communication via le web se fait essentiellement selon deux modes :

• lecture et envoie de messages sur un serveur (analogie avec le courrier)
• échanges de données en temps réel (analogie avec le téléphone)

La diffusion simple ne nous intéresse pas (dans un seul sens, de type télévison ou radio)

Dans les deux cas, les informations transmises peuvent être adressées soit à une communauté (correspondance publique), soit à une personne en particulier (correspondance privée)

Nous avons vu en introduction que les écoles étaient susceptibles d'utiliser ces deux modes de transmission (correspondance d'élève à élève, d'école à école) sous réserve de disposer d'outils correspondant à leurs besoins et adaptés aux enfants.

Plusieurs applications de communication ont donc été développées dans ce sens :

• Forums
• Chambres de discussion
• Messageries

3.3.1  Choix technologiques

La communication est rendue possible grâce à l'emploi d'un serveur permettant de relier les utilisateurs entre eux. De ce fait les applications sont toujours développées côté serveur.

Communication en mode connecté

La discussion en direct (temps réel) nécessite une application adoptant une architecture client/serveur, afin de gérer plusieurs utilisateurs interconnectés via le serveur. Une telle application nécessite l'emploi d'un langage de programmation autorisant les sessions.

Pour ce type d'application, l'emploi de Java apparaît évident, surtout en raisons des contraintes côté client. Java permet en effet de réaliser des clients sous forme de mini-applications (applets) pouvant être intégrées au sein de pages HTML.

Communication en mode non connecté

Dans ce mode, il n'y a pas d'interactions directes entre les intervenants. Les actions sont ätomiques" : soit on poste un message, soit on consulte des messages précédemment envoyés.

Ce sont donc des applications mono-utilisateurs qui se contentent de répondre à une requête (äffiche-moi ce message !").

L'emploi de scripts côté serveur correspond tout à fait à ces besoins.

Deux technologies présentant sensiblement les mêmes fonctionnalités s'offrent à nous :

• Les scripts CGI (Common Gateway Interface) utilisant une interface normalisée pour exécuter des programmes sur la machine serveur. Ils peuvent être écrits en C, Shell, VB... mais surtout en Perl
• Les pages äctives" qui sont des pages HTML dotées d'instructions exécutées par le serveur HTTP. Elles peuvent être écrites en ASP (Active Server Pages - technologie Microsoft) ou en PHP (Professional Home Pages - technologie Unix)

Structures de données

Un autre choix se pose concernant les formats des ressources sur le serveur. En effet, les messages peuvent être enregistrés :

• dans des fichiers textes
• dans des bases de données

Le format texte a l'avantage d'être simple et universel et de ne pas nécessite une infrastructure logicielle particulière. C'est en plus un format de base couramment utilisé par de nombreuses applications.

Les bases de données permettent de disposer de fonctionnalités de traitement avancées. Elles offrent une grande souplesse d'utilisation tout en allégeant la charge de développement.

L'inconvénient du texte découle de son avantage. C'est tellement basique qu'il est nécessaire de développer toutes les routines d'exactions de données. Les bases de données procurent en standard tous ces services sous réserve de disposer d'un SGBD.

3.3.2  Le Livre d'Or

La première application développée fut un Livre d'Or. Ce service très répandu sur les sites web offre la possibilité aux internautes de laisser leurs impressions et de consulter les messages déposés par d'autres visiteurs.

Le Livre d'Or fait exception, car cette application trouve sa place dans la partie publique du site des écoles. Il peut être employé par toute personne visitant le site et non uniquement par les enfants.

Cette application est basée sur un CGI-Perl exploitant un fichier texte contenant les paramètres et les messages. Ce choix technologique est arbitraire, l'emploi de PHP ou d'une base de données aurait aussi bien pu faire l'affaire.

Cette application présente les caractéristiques suivantes :

• le même script peut servir à une infinité de livres d'or, chacun possédant son fichier de ressources avec ses propres préférences.
• son interface est totalement paramétrable, point souvent négligé
• elle offre des fonctions d'administration (informations, suppression de messages) et de suivi (notification par e-mail)

3.3.3  Les forums thématiques

L'idée du forum est de proposer un espace ouvert où tout le monde peut s'exprimer autour d'un thème précis.

Nous proposons en fait une version simplifiée des forums traditionnels en réutilisant le principe du livre d'or pour un usage interne. Cette version offre la possibilité aux enseignants de créer (et supprimer) eux-mêmes différents forums thématiques.

Une fois le forum créé, les élèves peuvent ensuite y déposer et lire leurs messages (cf. Figures 16 et 17). Ce forum simplifié affiche et gère les messages de manière séquentielle. On ne propose pas ici un affichage arborescent des messages qui permettrait un meilleur suivi des débats (fils de discussion).

Figure 16 : ajout d'un nouveau message dans le forum

Figure 17 : consultation des messages d'un forum

3.3.4  La discussion en direct

La discussion en direct de type IRC (Internet Relay Chat) est un autre grand classique.

Nous proposons ici une version restreinte de cette technologie permettant aux enfants de se retrouver dans un espace privé pour discuter en temps réel.

Cette application (cf. Figure 18) développée par d'autres membres de l'association Jalix a simplement été intégrée à ce projet.

Figure 18 : interface du client de discussion en direct

Elle est basée sur une architecture client-serveur propriétaire (elle définit son propre protocole). L'ensemble de l'application a été développé en Java, le client est sous forme d'applet autorisant ainsi son intégration au sein d'une page HTML.

Un serveur dédié tourne la machine hébergeant le site. L'application étant téléchargeable sur le site de l'association, il nous a semblé indispensable d'ajouter un contrôle d'accès par mot de passe pour assurer la protection du channel utilisé par les enfants. Ce contrôle ainsi permet d'éviter toute intrusion extérieure.

3.3.5  La messagerie électronique

Le courrier électronique est sans doute la fonctionnalité la plus employée sur le net. Il semblait donc indispensable d'en faire bénéficier les enfants.

Bien évidement, avec leur abonnement Internet, les écoles disposent d'un client mail commercial ainsi que de quelques adresses électroniques. Ceci est insuffisant et inadapté à une utilisation par les élèves.

Choix technologiques

Il semble indispensable d'attribuer un compte mail à chaque enfant et de fournir un client mail approprié proposant une interface simplifiée et intuitive. La gestion des comptes est à la charge de l'association Jalix ; le client mail a été développé dans le cadre de ce projet.

Pour conserver un ensemble cohérent, nous avons bien évidemment choisi de réaliser une interface web pour ce programme. L'emploi de scripts CGI permet de rendre toutes les fonctionnalités transparentes pour les élèves.

Une telle interface autorise souplesse et convivialité et ne perturbe pas les jeunes utilisateurs déjà habitués à manipuler pages et formulaires HTML.

On souhaite ici disposer d'un outil permettant la gestion de dossiers et non d'un simple lecteur de boîtes aux lettres POP. Ceci nous permet de satisfaire une de nos exigences : conserver une copie des messages envoyés par l'utilisateur dans son dossier (afin d'assurer un meilleur suivi des correspondances).

Les messages reçus sont donc transférés de la boîte POP vers le dossier de l'utilisateur. Pour stocker ces messages, nous avons choisi d'employer un fichier texte par dossier. Cette méthode standardisée est celle employée par de nombreux clients mails. Nos dossiers sont ainsi totalement compatibles avec d'autres applications telles que Netscape Messenger, Kmail...

Caractéristiques

Lorsqu'un utilisateur accède au client mail, nous connaissons son nom et son login grâce au cookie d'identification. Nous pouvons ainsi directement afficher le contenu de son dossier. Chaque utilisateur ne dispose pour le moment que d'un seul dossier. A terme ce système pourra évoluer pour en gérer plusieurs (déplacement et classement de messages).

L'écran principal (cf. Figure 19) affiche la liste des en-têtes des messages contenus dans le dossier. Cette liste peut être triée selon ses différents champs (expéditeur, destinataire, intitulé, date).

Figure 19 : l'écran principal du client de messagerie

La lecture d'un message se fait en cliquant sur son intitulé, ce qui provoque son affichage dans une nouvelle fenêtre. (cf. Figure 20)

Sur la gauche de cet écran, on trouve une série d'icônes correspondant aux opérations suivantes :

• réception des nouveaux messages présents dans la boîte
• suppression des messages sélectionnés
• composition d'un nouveau message à expédier (cf. Figure 21)

Figures 20 et 21 : fenêtres de lecture et de composition

Fonctionnalités avancées

Les adresses électroniques posent certaines difficultés. Elles ne sont pas toujours simples à retenir et une erreur de syntaxe est préjudiciable. Le message serait alors expédié à n'importe qui ou perdu.

Pour résoudre ces problèmes, nous utilisons tout d'abord le cookie de l'élève afin qu'il n'ait jamais à taper son adresse (il est signé automatiquement). Ensuite nous instaurons un système de carnet d'adresses pour le choix du destinataire. Ce carnet est commun à toute la classe et administrable par l'enseignant, qui peut ainsi contrôler les contacts de ses élèves.

Une extension particulièrement intéressante pour les écoles consiste à supporter les mails au format MIME afin d'envoyer et recevoir toute sorte de documents en pièces jointes (des images principalement).

Cette fonctionnalité plus délicate à implémenter est en cours de développement. Elle nécessite l'emploi de modules Perl spécialisés pour parser et créer du MIME, rendant l'application plus complexe.

Après le développement de ces applications ludiques et de communication, nous avons demandé aux enseignants s'ils avaient des besoins pour faire du travail de groupes.

De ces entretiens plusieurs idées sont apparues dont deux majeures. La première consistait à travailler conjointement sur un même texte mais à des niveaux différents. En effet, de nombreux documents pédagogiques sont trop denses pour être exploités complètement par une seule classe. D'où l'idée de faire ce travail à plusieurs, chacun selon son niveau, tout en ayant la possibilité de profiter du travail des autres.

La seconde était basée sur "Le Défi Lecture". Cette opération consiste, pour deux classes de niveau différent, à lire une série de livres puis de se rencontrer au cours d'un rallye culturel portant sur l'ensemble de ces lectures. L'idée était de recueillir les avis des élèves sur leurs lectures respectives afin de constituer une base de données relative à cette manifestation, cette base pouvant ensuite être enrichie par des avis portant sur d'autres lectures.

Un tel outil présente de nombreux avantages :

• les données sont mémorisées, structurées et peuvent être traitées facilement
• il encourage les élèves a développer un certain sens critique ainsi que son esprit d'initiative
• en permettant à un élève de consulter la base de données pour repérer les oeuvres les plus appréciées et noter leurs références, un tel outil favorise un usage actif de la bibliothèque

Faute de temps, nous avons uniquement implémenté cette dernière application que nous allons maintenant détailler.

3.4.1  Choix technologique

L'application développée, baptisée "La Tribune des lecteurs", est fondée sur le couple MySQL - PHP.

MySQL est un serveur de base de données SQL (Structured Query Language). Il a l'avantage d'être gratuit, robuste et performant.

PHP (Professional Home Pages) est un langage interprété, intégré dans des pages HTML. Contrairement au JavaScript par exemple, un script PHP est interprété par le serveur HTML avant d'être envoyé au client. Grâce à de nombreuses fonctions, PHP peut s'interfacer facilement avec un grand nombre de SGBD (en particulier MySQL), avec des serveurs de messagerie ou encore générer des images et graphiques GIF à la volée etc. Enfin, il a lui aussi l'avantage d'être distribué gratuitement et librement sous la licence GNU GPL.

L'intégration des scripts PHP au sein de pages HTML "classiques" permet de générer un frontal graphique manipulant la base de données MySQL. Toutes les opérations possibles se font au moyen de ce frontal graphique ce qui permet de disposer de toute la puissance d'un SGBD tout en offrant une interface adaptée au niveau de l'utilisateur toutes les requêtes SQL étant masquées derrières des formulaires.

On distingue quatre grandes fonctionnalités :

• Enregistrer : saisie de donnée au moyen d'un formulaire vierge puis sauvegarde dans la base de données. Cette opération se fait en deux temps : saisie des données dans un formulaire HTML puis appel (utilisation de du formulaire) d'un fichier php3 qui va réaliser l'enregistrement proprement dit.



• Rechercher : recherche de n-upplets répondant à un ensemble de critères. Pour cette opération, on utilise un formulaire HTML pour la saisie de critères de recherche qui appelle ensuite (l'attribut action) une page php3 générant la requête SQL correspondante et affichant le résultat.



• Visualiser : liste de tous les n-upplets d'une table. Pour cette opération simple (select * from maTable), un unique fichier php3 suffit pour générer la requête et afficher le résultat.



• Modifier : modification d'un n-upplet. Ce type de requête s'effectue en deux temps : on commence par lister les enregistrements de la table concernée, on sélectionne le n-upplet à modifier. Les valeurs de ses attributs sont ensuite affichées dans un formulaire où elles peuvent être modifiées. Une fois les valeurs modifiées, on génère une requête SQL de type update qui va mettre à jour la base de données.

Tous les fichiers constituants l'application sont de type php3 (i.e. ils contiennent tous des échappements PHP). Chaque fichier est basé sur le même principe de fonctionnement :

1. connexion à la base de données
2. construction (statique ou dynamique) de la requête SQL, transmission au SGBD
3. évaluation de la requête par le SGBD (MySQL)
4. interprétation des résultats et génération de la page HTML

La connexion se fait au moyen de la fonction mysql_connect($host, $user, $pwd). Cette fonction prend trois paramètres : l'hôte sur lequel est hébergée la base de données, l'utilisateur et son mot de passe.

La requête est une chaîne de caractères qui peut éventuellement être construite de façon dynamique : $statement = ßelect * from livres"

La transmission de la requête au SGBD se fait en employant la fonction mysql_query($statement).

Les n-upplets résultats peuvent être ventilés dans un tableau associatif au moyen de la fonction mysql_fetch_array($result). C'est ce tableau qui est ensuite parcouru pour générer la page HTML présentant le résultat de la requête.

3.4.2  Schéma relationnel

Un livre est identifié par son code bibliothèque, il possède un titre, un auteur (nom, prénom). Il peut être de quatre genres différents : roman, bandes dessinées, poésie ou document (livres d'images, d'éveil etc.). Enfin, une pastille de couleur détermine le niveau de difficulté de l'ouvrage.

LIVRE (idf, titre, auteur, genre, niveau)

Un élève est identifié par son login. En plus de cette clef on ajoute, son nom, son prénom, son école, sa classe. Notons que cette table n'est pas uniquement dédiée à cette application. En effet, elle est aussi utilisée pour construire le cookie qui permet d'identifier l'utilisateur du site et qui sert pour de nombreuses autres applications (livre d'or, client mail etc.). C'est pourquoi on trouve également dans cette table, le mot de passe attribué à chaque élève lui permettant d'accéder à son compte mail.

ELEVE (login, password, prenom, nom, classe, ecole, annee)

L'avis d'un élève sur un livre est identifié par un entier auto-incrémenté. A cette clef, on associe le code du livre, le texte de l'élève, la note attribuée (très bien, bien etc.) ainsi que des informations sur l'auteur de l'avis : son login, son, école, sa classe, l'année. L'ajout de ces informations est nécessaire car au fil des années un élève va changer de classe et d'école mais son login sera conservé. Ainsi, si l'on se contente d'une simple jointure sur le login de l'élève entre les tables avis et eleve, on ne saura pas, par exemple, quelle était la classe de l'enfant au moment où il a déposé sa critique.

AVIS (num, idf-livre, texte, note, eleve, classe, ecole, annee)

3.4.3  La Tribune des lecteurs

La Tribune des Lecteurs est donc une base de données stockant les opinions des élèves sur leurs lectures et offrant toutes les fonctionnalités mentionnées plus haut.

Les écrans sont construits sous le même modèle :

• A gauche de l'écran : une barre de navigation permettant de passer d'un module à l'autre. Cinq modules sont disponibles : le Kiosque, le Top, la Recherche, le Dépôt d'avis, l'Administration
• Au centre de l'écran, on trouve le module sélectionné

Le Kiosque

L'écran initial, baptisé "Le Kiosque" (cf. Figure 22), est semblable à la page d'accueil d'un portail. Il permet d'accéder aux différentes catégories d'ouvrage (roman, BD, poésie et document) selon deux entrées :

• titres : qui liste l'ensemble des livres de la catégorie
• avis : qui liste l'ensemble des avis portant sur les livres de la catégorie.

Figure 22 : le Kiosque

Derrières ces écrans se cachent des requêtes de visualisation qui listent des n-upplets. Ces requêtes sont présentées sous forme de tableaux HTML. On génère également des liens hyper-textes qui permettent de passer facilement d'un écran à l'autre.

Ainsi, lorsque que l'on clique sur un titre par exemple, on obtient la liste de l'ensemble des opinions émises sur ce livre.

Le Top

Le second module, baptisé "Le Top" (cf. Figure 23), permet d'afficher les titres les plus appréciés toutes catégories confondues. Pour ce faire, la requête correspondante calcule la moyenne des notes attribuées. Là aussi, la sélection d'un titre entraîne l'affichage de l'ensemble des opinions émises sur ce livre.

Figure 23 : le Top

La Recherche

Le module de recherche permet de rechercher un livre enregistré dans la base de données (cf. Figure 24).

Figure 24 : la Recherche

Cette opération se fait facilement grâce à l'emploi d'un formulaire où l'on fixe les valeurs des attributs sur lesquels on souhaite effectuer l'opération de sélection.

Les résultats de la recherche s'inscrivent à la suite du formulaire, comme pour un moteur de recherche classique.

Le Dépôt d'avis

Le module de dépôt d'avis permet d'enrichir la base de données (cf. Figure 25). C'est grâce à lui qu'un élève peut donner son opinion sur ses les lectures. Pour ce faire, il doit d'abord indiquer sur quel livre porte sa critique. Afin d'éviter les inévitables fautes de frappes et autres erreurs risquant de nuire à l'intégrité de la base, nous avons opté pour une solution 100% clic (sauf pour la saisie de la critique évidement). Tout se fait à partir de listes de choix construites dynamiquement en fonction des valeurs fixées dans les listes précédentes.

Figure 25 : le Dépôt d'avis

Prenons l'exemple d'un élève voulant donner son avis sur "Le tour du monde en 80 jours" de Jules Vernes. La sélection de cette oeuvre se fait en 3 étapes consécutives :

1. Dans la liste Genres, il choisit "roman", ce choix provoque le rechargement de la page et la modification des les valeurs des listes Auteurs.
2. Il choisit ensuite "Vernes, J" dans la liste Auteurs qui propose désormais uniquement les auteurs de romans. Ce choix provoque à nouveau le rechargement de la page et la reconstruction des listes en conséquence.
3. Il choisit enfin "Le tour du monde en 80 jours" dans la liste Titres qui propose alors uniquement les romans de Jules Vernes.

Cette méthode permet ainsi d'obtenir à coup sûr l'identifiant (code bibliothèque) du livre critiqué et ce, de manière transparente pour l'utilisateur.

Il ne reste plus qu'alors à donner une note et de rédiger un petit commentaire avant de valider la critique. L'avis est ensuite ajouté dans la table correspondante et signé automatiquement grâce aux valeurs que l'on a pris soin d'enregistrer dans le cookie lorsque l'élève s'est connecté sur le site.

L'administration

Le module d'administration est réservé aux enseignants (cf. Figure 26). C'est par son intermédiaire que l'on peut enregistrer des nouveaux titres, modifier des enregistrements etc.

Figure 26 : L'administration

Ce module présente la liste des titres, ainsi qu'un formulaire d'ajout. S'il l'on souhaite modifier l'enregistrement relatif à un titre, il suffit de cliquer dessus pour que le formulaire de modification apparaisse. Ce formulaire composé de champs input permet de modifier n'importe quel attribut du n-upplet sélectionné. Un clic sur le bouton Valider entraîne la modification de la base de données via une requête SQL de type update.