ous êtes encore nombreux à ne pas être vraiment convaincus de la nécessité de passer par la phase d'analyse avant de commencer réellement à coder. Peut-être est-ce due à cette impression qu'a souvent l'autodidacte (ou le débutant) que ce travail n'est pas réellement rentable. De même, un client (ou un patron) peut avoir le sentiment de jauger l'évolution d'un travail au nombre de lignes écrites, à la rapidité ou les pages lui sont fournies, et donc à ce qu'il voit. Après être revenus sur ces phénomènes très répandus, je vous présenterais une introduction à une analyse beaucoup plus conséquente, analyse qui a servie de base à un logiciel gérant la coupe du monde en France en 1998. Car quand les choses se compliquent un tout petit peu (et cela arrive très très vite, et de plus en plus couramment), il n'est plus question d'amateurisme sous peine de risquer, cette fois, le naufrage total...

"Vite ! Pas Chère ! Et tout de suite."

Comme tout un chacun, l'investisseur (client, directeur) raisonne très souvent à court terme et exige rapidement des preuves que l'argent qu'il investit est correctement utilisé, et que le temps de travail qu'il paye est rentabilisé au maximum. Lui expliquer que quelques jours ou quelques heures de réflexions sont parfois nécessaires pour l'analyse peut le plonger dans un état suspicieux, avec parfois même le sentiment d'être trompé sur le temps de travail facturé. Pourtant, cette phase préliminaire représente les fondations même de son projet : il vaut mieux qu'il ait son site quelques jours plus tard mais que celui-ci soit correctement pensé et développé de manière professionnelle. Ainsi, son bon fonctionnement, son évolutivité et sa maintenance rentabiliseront largement son très léger investissement.

"Analyser ? Réfléchir ?? Mais pour quoi faire ???"

Un autre phénomène très répandu est celui du "bidouilleur" : régulièrement autodidacte, et généralement brouillon, il pense être capable de tout faire en mettant lui-même la main à la pâte. Très souvent, il s'agit d'un commercial persuadé qu'il pourra faire seul ce qui lui semble long et cher sans raison. Dans un premier temps, il semblera y arriver, à force de persévérances et d'interventions qui lui paraîtront être de petites astuces très intelligentes et qu'il ajoutera ici et là, très content de lui-même et de son résultat immédiat. Mais cela se termine toujours de la même manière : son code et ses fichiers se révelent être devenus si foullis et si incompréhensibles qu'il finira par être incapable de faire fonctionner quoi que ce soit, et devra se résoudre à appeler au secours. Seulement, il est souvent trop tard, et la seule solution viable pour son site Web est de le re-développer entièrement et correctement. Et là, ça coûte beaucoup plus cher que quelques heures d'analyse ou les conseils d'un professionnel.

Improviser : élimination directe ?

Prenons un nouvel exemple un plus complexe : en 1998, a eu lieu en France la coupe du monde de Football. De très nombreux sites Web ont alors entamé des développements spécifiques, afin de présenter un certain nombre d'informations concernant la compétition aux internautes. Leur besoin a tout d'abord été de fournir à leurs journalistes des outils rédactionnels afin de leur permettre d'afficher en ligne les articles concernant la compétition. La plupart de ces sites étant déjà dotés d'interfaces de travail pour les autres secteurs d'actualités, cette tache s'est généralement révélée assez simple. Mais, pour ce qui concernait le stockage et la présentation des résultats et des statistiques, ce fut une tout autre histoire...

Extraits d'un petit briefing de l'équipe technique :

"Ecoute, le webmaster, vient voir : Là, il y a la coupe du monde qui commence la semaine prochaine. On va présenter les scores des matchs, et deux trois petits classements faciles. Tu nous fais un machin hyper-simple pour qu'on puisse faire un max d'audience avec tous les footeux. Tu vois, un petit programme où là, on rentre les buts et les cartons, et quand on clique ici, sur le site, on voit tout comme il faut. Comme ça, les journalistes, ils marquent dans une petite fenêtre que le match a eu lieu ici, avec les joueurs qui jouent, les buteurs qui marquent, les remplacés qui sortent et le type qui arbitre. Comme dans le journal, quoi.... Toi, tu leur fais gentiment une moulinette pour stocker tout ça et tout afficher tranquillement sur le site quand le surfeur il le demande. OK ? Ca va ? Tu vois, un truc comme ça, tranquille..."

Eh ben c'était pas gagné...

Tacle en retard : carton Rouge !

Je ne sais pas si vous vous souvenez du spectacle alors offert par certains des sites Web concernés : joueurs ayant marqué 327 fois en 4 matchs, Barthez dans l'équipe du Brésil, Zidane finaliste en totalisant 23 minutes de jeux sur le terrain, résultats farfelus, quand résultats tout court il y eut. Car bien souvent, le développement se résuma en dernier ressort à afficher en catastrophe des pages statiques avec les feuilles de match, les classements et les résultats écrits directement en dur, dans des pages HTML fixes. Il y eu même des sites très connus (qu'on ne citera pas) qui furent totalement incapables de présenter le moindre résultat avant la fin de l'épreuve !

Pour ceux qui seraient interressés, j'ai concocté une petite analyse sur cette épreuve. Bien évidemment, selon les informations que l'on voudra stocker ou présenter, certaines modifications peuvent être apportées. Il ne faut pas perdre de vue que dans ce type d'analyse, il n'y a pas UNE mais bien souvent plusieurs solutions. Tout dépend de ce que l'on veut réellement faire. Néanmoins, cela devrait tout de même ressembler à cela :

Cliquez sur les schémas pour les agrandir :

MCD

MPD

Bien gérer les individualités

Un petit mot sur ce MCD et ce MPD :

• On remarque tout d'abord les cardinalités (1,1) mises entre parenthèses : elles décrivent ce que l'on appelle des entités dépendantes. En effet, une Equipe est liée à son Groupe, de même qu'un But et un TirsAuBut ne peuvent exister sans le Match lors duquel ils ont été marqués. Cela s'appelle un identifiant relatif. La conséquence d'un identifiant relatif est que la table générée par l'entité a comme double clé primaire son propre identifiant ainsi que l'indentifiant de l'entité dont elle dépend.



• Le champ NBPOINTS de la table EQUIPE : ce renseignement pourrait être retrouvé par une requête appropriée prenant en compte les résultats des matchs joués précédemments. Néanmoins, le nombre de points pouvant être modifié sur tapis vert, il est judicieux de prévoir qu'il puisse ne pas correspondre aux résultats précédents. Il ne s'agit donc pas d'une redondance, un facteur externe pouvant intervenir et modifier sa valeur. Cela implique tout de même que le développeur devra prévoir à la fois de le mettre à jour lors de la saisie des résultats (par procédures stockées ou par une fonction de son script), et une interface permettant d'y accéder et d'y écrire directement.



• le champ CODEPROLONGATION de la table MATCH sert à savoir si un match a eu ou non des prolongations, renseignements non indiqués par tous les score.



• Il y a une double relation 1,1 entre les entités Equipe et Pays. Normalement, cela voudrait dire que Pays est un argument de Equipe, et ne devrait pas devenir une table. Mais ici, Pays sert aussi pour les Arbitres, et est donc une entité reliée à Arbitre par une relation (1,1)-(0,n). Cette légère disgression se trouve donc justifiée par la liaison Pays-Arbitre.

Ne pas trop exagérer

Il conviendra tout de même de ne pas tomber dans l'excès inverse : l'analyse est là pour nous faire gagner du temps, pas pour nous en faire perdre. Merise, Gare Yourdon et les autres sont des méthodes très complètes qui peuvent néanmoins se révéler excessivement lourdes et contraignantes. Il n'est pas question ici d'utiliser au pied de la lettre ces procédés dans leur intégralité. Mais les techniques du Client/Serveur sont en train d'arriver sur le Web, les sites dynamiques se compliquent et se professionalisent. Et la méthode que je vous propose dans mes articles est simple, toujours vrai, rapide, efficace, et vous rendra donc de fiers services.

A bientôt...

Stéphane Lambert
www.vediovis.fr

Spécialisé dans le développement Web, Stéphane LAMBERT
a fondé VEDIOVIS PRODUCTIONS en Mai 2000.
Son expérience couvre essentiellement les sites à fortes audiences,
institutionnels ou audiovisuels.

Tous droits réservés - Reproduction même partielle interdite sans autorisation préalable