RNC-CNES-E-40-505-F

REFERENTIEL
NORMATIF du CNES
RNC-CNES-E-40-505
Référence :
Version 2
13 mars 2000
Méthode et Procédure
REGLES ET RECOMMANDATIONS
POUR LA REALISATION D'UN
SERVEUR WEB
APPROBATION
Président du CDN ;
date et nom :
METHODE ET PROCEDURE
_______
RNC-CNES-E-40-505
Page i.1
REGLES ET RECOMMANDATIONS POUR
LA REALISATION D'UN SERVEUR WEB
Version 2
13 mars 2000
PAGE D'ANALYSE DOCUMENTAIRE
TITRE
:
REGLES ET RECOMMANDATIONS POUR LA REALISATION D'UN
SERVEUR WEB
MOTS CLES : Internet; Web ; Serveur ; Règle ; Recommandation.
RESUME :
Ce document présente les règles et recommandations pour la réalisation de serveur
Web. Il est applicable à la spécification, au développement et à la maintenance de
serveur Web.
SITUATION DU DOCUMENT :
Ce document fait partie de la collection des Méthodes et Procédures associées au
Référentiel Normatif du CNES (ECSS et MP). Il appartient à la filiation Ingénierie des
Logiciels.
NOMBRE DE PAGES : 99
LANGUE : Française
Progiciels utilisés / version : Word 97
SERVICE GESTIONNAIRE : Délégation à l'Assurance de la Qualité du Centre Spatial de
Toulouse (DTS/AQ)
AUTEUR(S) :
DATE : 21/07/98
G. GUILLOT / C. JOUAN
RELECTURE / CONTROLE :
Pour ACCORD :
Le Président du Comité Technique de Normalisation :
© CNES 1998
Reproduction strictement réservée à l'usage privé du copiste, non destinée à une utilisation
collective (article 41-2 de la loi n°57-298 du 11 Mars 1957).
METHODE ET PROCEDURE
_______
RNC-CNES-E-40-505
Page i.2
REGLES ET RECOMMANDATIONS POUR
LA REALISATION D'UN SERVEUR WEB
Version 2
13 mars 2000
PAGES DES MODIFICATIONS
VERSION
DATE
PAGES MODIFIEES
OBSERVATIONS
0.0
28/07/97
Document initial (sans chartes)
0.1
19/09/97
Document entièrement refondu
(sans chartes)
Version non prise en compte
0.2
22/10/97
Prise en compte dans la version
0.0 de certaines évolutions de la
version 0.1
Version de base pour
l’introduction des chartes
0.3
17/11/97
Amélioration du document
Nouvelle version de base pour
l’introduction des chartes
PR.4
22/04/98
Refonte du document
Version complète
Introduction de l’analyse du
public, des informations et de la
technologie (§ 9)
Report dans une note technique
séparée des règles sur les chartes
0.1
21/07/98
Introduction des remarques suite
aux relectures
Version complète
Normalisation du document pour
soumission au CTN
2
Nouvelle codification
des documents
METHODE ET PROCEDURE
_______
REGLES ET RECOMMANDATIONS POUR
LA REALISATION D'UN SERVEUR WEB
RNC-CNES-E-40-505
Page i.3
Version 2
13 mars 2000
SOMMAIRE
1. INTRODUCTION ....................................................................................................... 1
2. OBJET DU DOCUMENT........................................................................................... 1
3. ORGANISATION DU DOCUMENT ........................................................................... 2
4. DOMAINE D’APPLICATION..................................................................................... 2
5. DOCUMENTS DE RÉFÉRENCE............................................................................... 3
6. DOCUMENTS APPLICABLES ................................................................................. 4
7. GLOSSAIRE - TERMINOLOGIE............................................................................... 5
7.1 ABREVIATIONS ........................................................................................................................................... 5
7.2 GLOSSAIRE................................................................................................................................................... 5
8. GUIDE DE LECTURE ............................................................................................. 10
8.1 INTRODUCTION ........................................................................................................................................ 10
8.2 PRESENTATION DES REGLES............................................................................................................... 10
8.2.1 STRUCTURE D’UNE REGLE .............................................................................................................. 10
8.2.2 TYPES DE REGLES .............................................................................................................................. 10
8.2.3 CODIFICATION D’UNE REGLE ......................................................................................................... 11
8.3 LES MODELES D’ARCHITECTURE...................................................................................................... 12
8.3.1 SERVEURS WEB STATIQUES............................................................................................................ 13
8.3.2 SERVEURS WEB DYNAMIQUES....................................................................................................... 16
8.3.3 SERVEURS WEB ETENDUS ............................................................................................................... 17
9. RÈGLES DE BASE ................................................................................................. 19
9.1 REGLES CONCERNANT L’ANALYSE DU PUBLIC............................................................................ 19
9.2 REGLES CONCERNANT L’ANALYSE DE L’INFORMATION ......................................................... 23
9.3 REGLES CONCERNANT L’ANALYSE DE LA TECHNOLOGIE ...................................................... 27
9.4 CHOIX D’UN TYPE DE SERVEUR ......................................................................................................... 33
METHODE ET PROCEDURE
_______
REGLES ET RECOMMANDATIONS POUR
LA REALISATION D'UN SERVEUR WEB
RNC-CNES-E-40-505
Page i.4
Version 2
13 mars 2000
10. RÈGLES COMMUNES ET APPLICABLES AUX SERVEURS STATIQUES ....... 34
10.1 REGLES GENERALES ............................................................................................................................ 34
10.2 REGLES APPLICABLES EN PHASE DE SPECIFICATION ............................................................. 40
10.3 REGLES APPLICABLES EN PHASE DE CONCEPTION ET DE REALISATION ........................ 45
10.4 REGLES APPLICABLES EN PHASE DE MAINTENANCE .............................................................. 74
11. RÈGLES APPLICABLES AUX SERVEURS WEB DYNAMIQUES ...................... 76
11.1 REGLES GENERALES ............................................................................................................................ 76
11.2 REGLES APPLICABLES EN PHASE DE SPECIFICATION ............................................................. 78
11.3 REGLES APPLICABLES EN PHASE DE CONCEPTION ET DE REALISATION ........................ 79
11.4 REGLES APPLICABLES EN PHASE DE MAINTENANCE .............................................................. 84
12. RÈGLES APPLICABLES AUX SERVEURS WEB ÉTENDUS ............................. 85
13. INDEX DES REGLES............................................................................................ 89
METHODE ET PROCEDURE
_______
RNC-CNES-E-40-505
REGLES ET RECOMMANDATIONS POUR
LA REALISATION D'UN SERVEUR WEB
Page 1
Version 2
13 mars 2000
1. INTRODUCTION
Le document "Règles et recommandations pour la réalisation d’un serveur Web" fait partie de la
collection des Méthodes et Procédures associées au Référentiel Normatif du CNES (ECSS et MP). Il
appartient à la filiation Ingénierie des Logiciels.
Ce document est complété par un document annexe « Règles pour la réalisation de chartes pour un
serveur Web » (DR11).
2. OBJET
DU DOCUMENT
La présente MP énonce :
• des règles de base, applicables en préalable à la réalisation de tout serveur Web
• des règles et des recommandations applicables aux phases de spécification, de conception et de
maintenance d’un serveur (et d’un site) Web,
• des règles et des recommandations générales associées à la réalisation d’un serveur Web.
Remarque : Ce document n’est pas un document de référence des techniques Web. Cependant, les
phases du cycle de vie de réalisation d'une architecture de serveur Web (spécification, conception et
maintenance) sont évoquées au travers des différents types de serveurs.
La classification retenue pour les différents types de serveurs Web est la suivante par ordre de
complexité :
• serveurs Web statiques,
• serveurs Web dynamiques,
• serveurs Web étendus.
Toutes les règles énoncées pour un type de serveur Web sont également à appliquer pour les types de
serveurs Web plus élaborés. Par exemple, toutes les règles applicables aux serveurs Web statiques le
sont également aux serveurs Web dynamiques.
Restrictions
Des règles de développement plus précises devront être déterminées pour la réalisation proprement dite
de l’application serveur et de l’application client, car elles dépendent de la technologie choisie.
En raison de l’évolution rapide des techniques liées à ce type de développement, ce document n’est en
aucun cas un « état de l’art » ou une liste exhaustive des outils et techniques disponibles sur le marché.
METHODE ET PROCEDURE
_______
REGLES ET RECOMMANDATIONS POUR
LA REALISATION D'UN SERVEUR WEB
3. ORGANISATION
RNC-CNES-E-40-505
Page 2
Version 2
13 mars 2000
DU DOCUMENT
Ce document a été structuré avec un découpage respectant les différents grands types d’architectures
afin de permettre à l’utilisateur de trouver rapidement les règles qui répondent à son besoin :
• la première partie décrit les types d’architecture du serveur Web,
• la deuxième partie décrit les analyses du public, de l’information et de la technologie à mener
avant le choix d’une architecture de serveur Web,
• la troisième partie est consacrée aux règles relatives à la totalité des serveurs Web, quel que soit
leur type, notamment les serveurs et sites Web statiques,
• la quatrième partie est consacrée aux règles relatives aux serveurs Web dynamiques,
• la cinquième partie est consacrée aux règles relatives aux serveurs Web étendus.
4. DOMAINE D’APPLICATION
Ce document vise plusieurs types d’utilisateurs :
• le chef de projet qui doit spécifier correctement le serveur (ou le site) à développer,
• le chef de projet et/ou l’ingénieur qualité qui doit valider les règles relatives à la réalisation,
extraire les recommandations pertinentes pour son projet et éventuellement adapter et compléter
les règles en fonction du contexte de réalisation,
• les personnes chargées de la réalisation du projet : elles doivent appliquer les règles et les
recommandations retenues pour chaque étape du cycle de vie du logiciel.
Du fait de ce triple objectif, ce document est donc une combinaison et parfois un compromis entre un
guide de spécification, un standard de conception, et un guide de développement de serveurs et de sites
Web.
METHODE ET PROCEDURE
_______
RNC-CNES-E-40-505
REGLES ET RECOMMANDATIONS POUR
LA REALISATION D'UN SERVEUR WEB
5. DOCUMENTS
Page 3
Version 2
13 mars 2000
DE RÉFÉRENCE
• (DR1) : Référentiel Normatif RNC-ECSS-E-40
Logiciels
• (DR2) : Règles et recommandations pour l’utilisation de la méthode OMT
(RNC-CNES-Q-80-525)
• (DR3) : Règles et recommandations pour l’utilisation du langage Java
(RNC-CNES-Q-80-527)
• (DR4) : Règles et recommandations d’ergonomie des interfaces Homme Machine
informatiques (RNC-CNES-E-40-504)
• (DR5) : Exigences de sécurité pour l’utilisation des serveurs et relais HTTP
(SSI-SB-21201-CN, Ed 1 Rév 4 du 08/08/95)
• (DR6) : Règles de sécurité pour les développements sous UNIX
(RNC-CNES-Q-80-523, version provisoire)
• (DR7) : Cahier de recette du serveur HTTP UNIX du CERN
(SSI-VR-21203-CN CN, Ed 1 Rév 3 du 20/11/95)
• (DR8) : Règles et recommandations pour l’utilisation du langage C (RNC-CNES-Q-80-506)
• (DR9) : P. Lynch, S. Horton, Yale C/AIM Web Style Guide
(http://info.med.yale.edu/caim/manual/)
• (DR10) : R. Levine (Sun Microsystems), Sun Guide to Web Style
(http://www.sun.com/styleguide/)
• (DR11) : Règles pour la réalisation de chartes pour un serveur Web
(RNC-CNES-E-40-505-A)
• (DR12) : RNC-ECSS-Q-80 Assurance Produit des Logiciels
• (DR13) : Manuel utilisateur des services applicatifs IW3
(IW3-MU-3500-037-CAP Ed 2 Rév 1 du 09/04/98)
• (DR14) : Manuel utilisateur des services d'exploitation IW3
(IW3-MU-3500-038-CAP Ed 2 Rév 1 du 09/04/98)
• (DR15) : Démarche d'ouverture d'un serveur WWW
(IW3-DT-4000-041-CAP Ed 1 Rév 1 du 02/12/97)
• (DR16) : Guide de Rédaction d'un Dossier Système de serveur WWW
(IW3-GR-4000-042-CAP Ed 1 rév 1 du 02/12/97)
METHODE ET PROCEDURE
_______
REGLES ET RECOMMANDATIONS POUR
LA REALISATION D'UN SERVEUR WEB
• (DR17) : Guide de Rédaction d'un Dossier d'exploitation de serveur WWW
(IW3-GR-4000-043-CAP Ed 1 Rév 2 du 28/05/98)
• (DR18) : RFC HyperText MarkUp Langage
http://www.w3.org/MarkUp/
6. DOCUMENTS
Néant.
APPLICABLES
RNC-CNES-E-40-505
Page 4
Version 2
13 mars 2000
METHODE ET PROCEDURE
_______
REGLES ET RECOMMANDATIONS POUR
LA REALISATION D'UN SERVEUR WEB
7. GLOSSAIRE -
RNC-CNES-E-40-505
Page 5
Version 2
13 mars 2000
TERMINOLOGIE
7.1 ABREVIATIONS
API
Application Program Interface
CGI
Common Gateway Interface
DNS
Data Name System
FTP
File Transfert Protocol
HTML
HyperText Markup Language
HTTP
HyperText Transfer Protocol
IIOP
Internet Inter-ORB Protocol
IP
Internet Protocol
ISAPI
Internet Server API
MIME
Multipurpose Internet Mail Extensions
MP
Méthode et Procédure
NSAPI
Netscape Server API
TCP
Transfert Communication Protocol.
URL
Uniform Resource Locator
WWW ou W3
World Wide Web
7.2 GLOSSAIRE
ActiveX
Technologie développée par Microsoft, issue des technologies COM et OLE,
permettant de définir des composants applicatifs, téléchargeables automatiquement et
exécutables par les navigateurs Web. Ces composants permettent d’inclure des
documents et des contrôles utilisateurs dans des pages HTML.
A la différence des composants Java, ActiveX n’est pas un langage, mais un ensemble
de règles que les composants doivent respecter.
API
Application Program Interface.
Ensemble de conventions définissant de quelle manière un service peut être joint par
un logiciel
METHODE ET PROCEDURE
_______
REGLES ET RECOMMANDATIONS POUR
LA REALISATION D'UN SERVEUR WEB
RNC-CNES-E-40-505
Page 6
Version 2
13 mars 2000
Applet
Composant applicatif téléchargeable, qui peut être inclus dans une page HTML. De
tels composants peuvent par exemple être des composants de l’interface utilisateur ou
bien des composants pouvant communiquer avec d’autres applications distantes. Les
applets sont essentiellement écrits en Java.
CGI
Common Gateway Interface.
Interface d’appel de programmes par un serveur Web. L’interface CGI permet
notamment la communication avec des bases de données.
Cookie
Information générée et utilisée par un serveur Web et stockée au niveau du poste de
travail sur lequel réside le navigateur Web. L’utilisation de cookies permet de stocker
des informations propres à un serveur Web au niveau du poste client, dont la durée de
vie peut être prolongée au-delà d’une session, telles que des informations sur les
préférences de l’utilisateur.
CORBA
"Common Object Request Broker Architecture" traduisible par "Architecture à objets
distribués ".
Norme définissant l'architecture que doivent adopter les applications, pour rendre
possible la communication entre des objets distribués sur des machines hétérogènes
interconnectées .
DNS
Serveur responsable de la correspondance entre un nom symbolique et une adresse
Internet. Base centrale contenant le nom et l’adresse IP des machines.
Extranet
Réseau collaboratif d’entreprise basé sur les technologies Internet dont l’accès est
également autorisé à certains partenaires extérieurs (fournisseurs, clients...).
Frame
Cellule
Technique qui permet de partager une fenêtre en plusieurs cellules.
FTP
Protocole d'échange de fichiers sur Internet. Par extension, FTP désigne aussi le client
Groupware
Technique dont l’objectif est de partager des informations communes entre plusieurs
intervenants.
Helper Application
(Modules d’aide)
Programme appelé par un navigateur Web pour afficher ou traiter de manière externe
les fichiers d’un type donné.
Le type d’un fichier, et donc le module d’aide à exécuter, est déterminé d’après son
type MIME ou bien d’après le suffixe de son nom.
HTML
HyperText Markup Language
Langage standard utilisé pour formater les documents publiés sur le Web. HTML
repose sur l’utilisation de "tags" ou balises de formatage permettant également
l’inclusion d’éléments externes tels que des images et des documents multimédia.
HTTP
HyperText Transfer Protocol.
Protocole de communication utilisé pour transporter des documents hypertextes et
d’autres documents, entre un serveur et un navigateur Web.
METHODE ET PROCEDURE
_______
REGLES ET RECOMMANDATIONS POUR
LA REALISATION D'UN SERVEUR WEB
RNC-CNES-E-40-505
Page 7
Version 2
13 mars 2000
IIOP
Internet Inter-ORB Protocol.
Protocole de communication développé par l’OMG (Object Management Group) pour
l’interaction entre plusieurs plates-formes CORBA. IIOP permet notamment
l’intégration de technologies Web avec CORBA. IIOP permet l’échange de données
complexes et structurées.
Image Map
Image incluse dans une page Web associant des liens hypertextes à des portions de
l’image. Les images maps sont habituellement utilisées pour créer des menus de
navigation sous forme graphique.
IP
Protocole permettant la communication entre machines distantes placées sur des
réseaux hétérogènes
Internet
Le réseau Internet est un ensemble mondial de réseaux interconnectés reposant sur le
protocole de communication TCP/IP. Ce réseau, tolérant aux pannes, permet le
routage dynamique des informations.
Le terme Internet est aussi fréquemment utilisé pour désigner les technologies
reposant sur TCP/IP, telles que le Web, le courrier électronique, les groupes de
communications...
Intranet
Réseau collaboratif basé sur les technologies Internet mais interne à une entreprise. Un
Intranet est généralement privé et protégé des accès extérieurs au moyen d’un firewall
(garde-barrière ou coupe-feu).
ISAPI
Internet Server API.
Interface permettant aux serveurs Web Microsoft Internet Information Server et aux
serveurs compatibles de communiquer avec des programmes externes. L’intégration
de tels programmes avec le serveur est plus forte qu’avec l’interface CGI, ce qui
permet des gains de performance importants.
IW3
Structure d'accueil sécurisée pour les serveurs WEB, composée d'un environnement
"chrooté" et de procédures d'administration du serveur.
Java
Langage de programmation, défini par Sun Microsystems, orienté - objet et
indépendant de la plate-forme matérielle et système. Java est à la base des applets
téléchargeables et exécutables dans les pages HTML.
LibWIndus
Librairie de fonctions "C sécurisé" utilisables par les cgi des serveurs WEB
(Sécurisation des cgi, gestion des messages applicatifs, gestion des paramètres
d'entrée, gestion de "templates")
Maquette
Application logicielle développée de façon succincte pour valider certains aspects de
la spécification (présentation, navigation, ...). Une maquette n’a aucune fonctionnalité
hors celles qu’on veut valider et n’est pas réutilisable pour le développement de
l’application réelle.
MIME
Multipurpose Internet Mail Extensions.
Spécification permettant de typer et de formater les documents transitant sur les
réseaux Internet. La majorité des navigateurs Web et des outils de messagerie reposent
notamment sur ce standard.
METHODE ET PROCEDURE
_______
REGLES ET RECOMMANDATIONS POUR
LA REALISATION D'UN SERVEUR WEB
RNC-CNES-E-40-505
Page 8
Version 2
13 mars 2000
Navigateur Web
Application utilisée pour localiser et afficher des pages HTML et permettant la
navigation de page en page en suivant les liens hypertextes.
NSAPI
Netscape Server API.
Interface permettant aux serveurs Web de Netscape et aux serveurs compatibles de
communiquer avec des programmes externes. L’intégration de tels programmes avec
le serveur est plus forte qu’avec l’interface CGI, ce qui permet des gains de
performance importants.
Page HTML
Unité cohérente d’affichage d’un navigateur Web codée en langage HTML et associée
à une URL qui permet son transfert du serveur Web vers le navigateur selon le
protocole HTTP.
Une page HTML ou page Web peut être décomposée en sous-pages possédant leur
propre URL.
Plug-in (Module
externe incorporé)
Module ajoutant des fonctions à un navigateur Web. Les modules externes incorporés
sont principalement utilisés dans les navigateurs Web pour inclure à l’intérieur d’une
page Web des documents nécessitant un programme spécial pour les afficher et gérer
l’interaction avec l’utilisateur.
Le module externe incorporé à exécuter est déterminé d’après le type MIME du
document.
Prototype
Application logicielle développée de façon partielle pour valider certains choix
techniques de la conception. Un prototype est développé de façon incrémentale (ajout
de fonctionnalités à chaque version) et est réutilisable totalement ou partiellement pour
le développement de l’application réelle.
Rubriquage
Il s’agit du résultat de la structuration de l’information. C’est une phase importante qui
consiste à organiser la connaissance qui sera délivré par le serveur.
Serveur Web
Application faisant office de serveur et proposant des services Web. Le rôle principal
d’un serveur Web est de retourner des pages Web en réponse aux requêtes des
navigateurs Web. Un serveur Web est implanté sur une machine Web.
Site Web
Ensemble d’applications de type serveur Web proposant des services sur un même
sujet et partageant des données communes.
Tag
Balise, marqueur
Elément du langage HTML servant à décrire la structure d'un document. Chaque
structure de texte est encadrée par une paire de balises qui se présentent sous la forme
suivante : <balise> texte affecté par la balise.</balise>
TCP
Protocole de communication fournissant une connexion fiable entre des machines
hétérogènes. Des protocoles comme FTP, HTTP, Gopher ou WAIS utilisent les
services de la connexion TCP.
METHODE ET PROCEDURE
_______
REGLES ET RECOMMANDATIONS POUR
LA REALISATION D'UN SERVEUR WEB
RNC-CNES-E-40-505
Page 9
Version 2
13 mars 2000
URL
Uniform Resource Locator.
Adresse d’un document, d’un élément inclus ou de toute autre ressource sur le Web.
L’URL est formée de plusieurs parties, précisant notamment le protocole utilisé,
l’adresse du serveur et la référence de l’élément sur ce serveur (par exemple,
http://www.company.com/home.html).
World Wide Web /
Web / WWW
Le World Wide Web est un réseau global d’informations hypertextes, partie intégrante
du réseau Internet. Le World Wide Web est composé de serveurs Web accédés par des
clients, les navigateurs Web.
METHODE ET PROCEDURE
_______
REGLES ET RECOMMANDATIONS POUR
LA REALISATION D'UN SERVEUR WEB
8. GUIDE
RNC-CNES-E-40-505
Page 10
Version 2
13 mars 2000
DE LECTURE
8.1 INTRODUCTION
Le but de ce chapitre est d’orienter l’utilisateur de ce document dans sa démarche de recherche des
recommandations et des règles.
Les règles pour la réalisation d’un serveur Web énoncées dans ce document sont présentées :
• en fonction du type de serveur choisi
• en fonction de la phase du cycle de vie considérée.
8.2 PRESENTATION DES REGLES
8.2.1 STRUCTURE D’UNE REGLE
Pour chaque règle, la description fait apparaître les rubriques suivantes :
• la référence de la règle,
• l’énoncé de la règle, consistant en une phrase synthétique,
• la description détaillée de la règle précisant les différentes circonstances d’application de la
règle,
• la justification de la règle présentant l’objectif de la règle, ses avantages et inconvénients ainsi
que des possibilités alternatives qui n’ont pas été retenues,
• un ou plusieurs exemple(s) (si nécessaire), pour illustrer les applications de la règle, sans que
cela constitue une manière obligatoire d’appliquer la règle, ainsi que des contre-exemples dans
le cas où ceux-ci présenteraient un intérêt.
8.2.2 TYPES DE REGLES
Il y a deux types de règles :
• les exigences (le défaut)
• les recommandations (comportant la mention (Recom) en dessous du nom de la règle).
Les exigences sont imposées par l’application de ce standard ; les recommandations sont conseillées.
METHODE ET PROCEDURE
_______
RNC-CNES-E-40-505
REGLES ET RECOMMANDATIONS POUR
LA REALISATION D'UN SERVEUR WEB
Page 11
Version 2
13 mars 2000
8.2.3 CODIFICATION D’UNE REGLE
La codification utilisée pour référencer les règles est la suivante :
<Domaine>.<SousDomaine>.<Thème>
avec :
<Domaine> est un terme abrégé :
AP
:
Analyse du Public
AI
:
Analyse de l’Information
AT
:
Analyse de la Technologie
SS
:
Serveur Web Statique
SD
:
Serveur Web Dynamique
SE
:
Serveur Web Etendu
<SousDomaine> est un terme non abrégé :
Conception
:
Règles sur la phase de conception du serveur ou du site Web
Configuration
:
Règles sur la configuration du serveur ou du site Web
Ergonomie
:
Règles sur l’ergonomie et la charte graphique du site
Formation
: Règles sur la formation des personnes impliquées dans la création du
serveur ou du site Web
HTML
:
Règles sur l’utilisation du langage HTML
Maintenance
:
Règles concernant la maintenance du serveur ou du site Web
Performance
:
Règles concernant les performances du serveur Web
Portabilité
:
Règles concernant la portabilité vis à vis des navigateurs Web
Processus
: Règles concernant l’enchaînement des tâches lors de la création du
serveur ou du site Web
Réalisation
:
Règles sur la phase de réalisation du serveur ou du site Web
Sécurité
:
Règles sur la sécurité du serveur ou du site Web
Spécification
:
Règles sur la phase de spécification du serveur ou du site Web
Structure
:
Règles concernant la structuration du serveur ou du site Web
Thème est le sujet traité par la règle.
METHODE ET PROCEDURE
_______
REGLES ET RECOMMANDATIONS POUR
LA REALISATION D'UN SERVEUR WEB
8.3
RNC-CNES-E-40-505
Page 12
Version 2
13 mars 2000
LES MODELES D’ARCHITECTURE
Le but de cette section est d’orienter l’utilisateur de ce document dans sa démarche de recherche et de
mise en place d’une architecture de serveur Web en lui proposant les recommandations et règles
appropriées.
Cette section apporte des éléments de réponses à des questions telles que :
• Quelles solutions peuvent être réalisées en utilisant telle architecture ?
• Quelle architecture est appropriée pour tel besoin ?
• Quelles sont les questions à se poser et quelles sont les étapes à suivre pour définir et réaliser un
serveur Web ?
Les solutions d’architectures décrites dans ce document définissent trois grands modèles d’architecture :
• Les serveurs Web statiques (Cf. chapitre 8.3.1) permettent la création de sites Web présentant
une information dont la structure et le contenu sont statiques. Les informations affichées peuvent
éventuellement être complexes grâce à l’utilisation de techniques additionnelles décrites dans ce
document.
Ces types de serveurs correspondent à des cas d’utilisation du type serveur institutionnel
(plaquette) ou présentation de produits (catalogue) ou d’activité.
• Les serveurs Web dynamiques (Cf. chapitre 8.3.2) ajoutent aux serveurs Web statiques des
possibilités de présenter des informations évolutives provenant de bases de données (qui peuvent
être mises à jour par d’autres applications) ou des informations générées par des applications
externes.
Les cas d’utilisation de ces serveurs sont très nombreux, et ils recouvrent en particulier les cas
de publications d’annuaires d’entreprise, de listes évolutives de produits, d’applications de type
"groupware" et plus généralement de type base d’informations.
• Les serveurs Web étendus (Cf. chapitre 8.3.3) ajoutent aux serveurs Web dynamiques la
possibilité de pouvoir engager une communication directe et complexe entre un poste client et
des applications serveurs autres que l’application d’origine. Une telle architecture combine les
fonctions de présentation et de modification d’informations d’un serveur Web dynamique avec
les fonctions classiques et générales d’applications distribuées.
Les cas d’utilisation de ces serveurs sont les plus larges, mais leur complexité aussi, ce qui les
rend applicables aux applications complexes allant au-delà des possibilités des serveurs Web
"classiques" en particulier, en s’affranchissant des limites du protocole HTTP et du langage
HTML.
Les sections suivantes décrivent sommairement chaque catégorie d’architecture de serveurs Web et les
principes techniques associés. Les règles propres à chaque catégorie sont décrites dans des chapitres
suivants de ce document.
Il est à noter que les règles présentées s’appliquent aussi bien à des serveurs Web simples qu’à des sites
Web comportant plusieurs serveurs Web interagissant sur les informations présentées par le site Web.
Dans la suite du document, le terme « serveur Web » s’appliquera aussi bien à un serveur Web qu’à un
site Web.
METHODE ET PROCEDURE
_______
RNC-CNES-E-40-505
Page 13
REGLES ET RECOMMANDATIONS POUR
LA REALISATION D'UN SERVEUR WEB
Version 2
13 mars 2000
8.3.1 SERVEURS WEB STATIQUES
8.3.1.1 DESCRIPTION
Les serveurs Web statiques sont les serveurs Web retournant une page prédéfinie statiquement en
réponse à une requête d’un navigateur Web. Cette catégorie d’architecture exclut toute interaction entre
le serveur Web et d’autres applications ou bases de données. Ainsi, le serveur Web se limite à retourner
des documents préexistants.
Les serveurs Web statiques reposent sur le protocole HTTP et retournent des pages HTML ou d’autres
documents, désignés grâce à leur URL.
Poste Client
Réseau
TCP/IP
Serveur
Pages HTML
Navigateur Web
(1) Requête HTTP (URL)
Serveur Web
(2)
(4)
(3) Page HTML
Figure 1 : Serveur Web statique
Les accès au serveur Web, à certaines pages ou à certains documents peuvent être sécurisés de 2
manières :
• Cryptage des informations dans les limites légales
• Accès confidentiel nécessitant la saisie d’un identifiant d’utilisateur et d’un mot de passe
correspondant
Les serveurs Web statiques utilisent également des techniques au niveau du poste client qui sont décrites
ci-après.
METHODE ET PROCEDURE
_______
RNC-CNES-E-40-505
Page 14
REGLES ET RECOMMANDATIONS POUR
LA REALISATION D'UN SERVEUR WEB
Version 2
13 mars 2000
En plus des documents HTML et des images qui peuvent être envoyés par un serveur Web à un
navigateur Web, d’autres types de documents peuvent être mis à disposition. Les documents nécessitant
un programme spécifique pour être affichés et pour gérer l’interaction utilisateur peuvent être utilisés au
niveau du poste client soit en lançant un module d’aide (helper application) à l’extérieur du navigateur
Web ou bien en lançant un module externe incorporé (plug-in), affichant le document à l’intérieur de
la page Web.
Pages HTML
Navigateur Web
(1) Requête HTTP (URL)
Serveur Web
(3) Document
(4)
(2)
Autres types
de documents
Module d'aide
Figure 2 : Modules d’aide (helper applications)
Pages HTML
Navigateur Web
(4)
Module externe
incorporé
(1) Requête HTTP (URL)
Serveur Web
(3) Document
(2)
Autres types
de documents
Figure 3 : Modules externes incorporés (plug-ins)
METHODE ET PROCEDURE
_______
RNC-CNES-E-40-505
Page 15
REGLES ET RECOMMANDATIONS POUR
LA REALISATION D'UN SERVEUR WEB
Version 2
13 mars 2000
Les pages HTML peuvent contenir, en plus des informations textuelles et de navigation, des scripts
client (par exemple, Javascript ou VBScript) qui sont utilisés et exécutés par le navigateur. Ces scripts
sont essentiellement destinés à améliorer et à contrôler l’interaction et le dialogue avec l’utilisateur (par
exemple, un contrôle de la validité des champs de saisie et l’affichage de messages d’erreur par le
navigateur sur le poste client).
En plus des divers types de documents affichés directement ou indirectement par le navigateur Web, des
composants exécutables peuvent être téléchargés pour être exécutés dans le navigateur Web. Ces
composants peuvent avoir une représentation graphique dans une page HTML ou bien s’exécuter de
manière non visible. Dans le cadre d’une architecture Web statique, seuls les composants agissant à
l’intérieur du poste client sont considérés, essentiellement des composants graphiques (par exemple, un
message déroulant, une image sensible à certains événements...). Les composants communiquant avec
des ressources distantes sont décrits dans le cadre d’architectures Web dynamiques étendues.
Pages HTML
Navigateur Web
(4)
(1) Requête HTTP (URL)
Serveur Web
(3) Composant
Composant
s'exécutant dans
le navigateur
(2)
Composants
Figure 4 : Composants graphiques
8.3.1.2 EXEMPLE
Pour livrer aux utilisateurs la télémesure d’un satellite avec un serveur de type statique, on peut :
• Décommuter la télémesure puis la mettre à disposition sur le serveur sous forme de pages
HTML que l’utilisateur pourra lire.
• Créer des pages permettant l’accès aux données brutes de télémesure que l’utilisateur pourra
télécharger chez lui et les analyser par ses propres moyens (à l’aide d’une application externe).
• Concevoir un module d’aide (helper application) ou un module externe incorporé (plug-in) que
l’utilisateur pourra télécharger puis installer chez lui afin que les fichiers de données brutes de
télémesure soient automatiquement analysés lors de leur téléchargement.
La limitation de ce système est que les fichiers de télémesure disponibles sont fixés par le responsable
du serveur : Si celui-ci décide qu’il y aura un fichier de télémesure brut pour la période du 1er au 15
Avril et un autre du 15 au 30 Avril, l’utilisateur intéressé par la période du 15 au 16 Avril devra
télécharger les 2 fichiers.
Dans le cadre de l'industrialisation des serveurs WWW, le CNES a fait développer le produit IW3
comprenant une structure d'accueil de serveur statique et les procédures d'exploitation associées ainsi
qu'une librairie de fonctions applicatives sécurisées.
METHODE ET PROCEDURE
_______
RNC-CNES-E-40-505
Page 16
REGLES ET RECOMMANDATIONS POUR
LA REALISATION D'UN SERVEUR WEB
Version 2
13 mars 2000
8.3.2 SERVEURS WEB DYNAMIQUES
8.3.2.1 DESCRIPTION
Les modèles de serveurs statiques décrits précédemment reposent sur une utilisation de pages et
d’éléments statiques, ne permettant notamment pas d’interagir avec un système d’information en temps
réel, ni de pouvoir instaurer un dialogue coopératif avec un utilisateur. Les serveurs Web offrant ces
fonctions définissent une nouvelle catégorie; les serveurs Web dynamiques. Dans ce modèle, le serveur
Web peut retourner soit des pages HTML statiques avec les mêmes fonctions que dans le cas des
serveurs Web statiques, soit des pages HTML résultant de l’exécution d’un programme extérieur :
Pages HTML statiques
Navigateur Web
(1) Requête HTTP (URL)
Serveur Web
(2) Appel à des ressources externes
(4) Page HTML
(3) Page HTML
résultante
Figure 5 : Serveur Web dynamique
Plusieurs interfaces de communication entre le serveur Web et les applications externes existent.
L’interface standard et originelle est l’interface CGI. En réponse à une requête nécessitant l’utilisation
d’une ressource externe, le serveur Web exécute l’application correspondante dans un nouveau
processus système. Les paramètres spécifiés dans la requête sont passés au programme appelé. En
retour, le programme génère une page Web qui est retournée au navigateur Web :
Pages HTML statiques
Navigateur Web
(1) Requête HTTP (URL)
Serveur Web
(4) Page HTML
(2) Appel CGI
(3) Page HTML
résultante
Script CGI
Accès à des
applications
ou bases de
données
externes
Fi
Figure 6 : Interface CGI (Common Gateway Interface)
METHODE ET PROCEDURE
_______
REGLES ET RECOMMANDATIONS POUR
LA REALISATION D'UN SERVEUR WEB
RNC-CNES-E-40-505
Page 17
Version 2
13 mars 2000
On peut noter également des extensions et des mécanismes voisins de ce modèle, tels que :
• Des interfaces propriétaires, spécifiques à un serveur Web (NSAPI de Netscape, ISAPI de
Microsoft, ...),
• Les serveurs dynamiques interprétés reposant sur des modèles de pages (Livewire de
Netscape, Active Server Pages de Microsoft, Cold Fusion d’Allaire, ...),
• Les serveurs statiques interprétés dont les pages sont générées à partir de modèles de pages
(NetObjects,...). Cette notion est liée à la fonctionnalité de SSI ( Server Side Include). Elle
permet au serveur de construire des documents à la volée par assemblage de "morceaux "
existants. La subtilité par rapport aux serveurs dynamiques, est que les "morceaux" en question
existent de façon statique. Les documents produits ne sont donc pas construits ex nihilo. De
plus, les éléments qui les composent sont éditables de façon statique comme les pages HTML
standards.
8.3.2.2 EXEMPLE
Pour livrer aux utilisateurs la télémesure du satellite avec un serveur de type dynamique, on peut, en
plus des possibilités offertes par les serveurs statiques :
• Donner à l’utilisateur la possibilité de définir les dates ou la télémesure l’intéressant et le format
d’affichage qu’il désire, puis ensuite, générer dynamiquement les pages HTML répondant à sa
requête (serveur dynamique).
8.3.3 SERVEURS WEB ETENDUS
8.3.3.1 DESCRIPTION
Les serveurs Web étendus constituent un modèle de serveur dans lequel aux fonctions des serveurs
statiques et dynamiques s’ajoutent des fonctions de communication directe entre le navigateur Web et
des applications externes. Cette communication est établie par des composants applicatifs (par exemple,
applets Java ou composants ActiveX) téléchargés dans le navigateur. Ce modèle combine à la fois les
possibilités des serveurs Web plus classiques décrits ci-dessus et celles, plus générales, des applications
distribuées :
METHODE ET PROCEDURE
_______
RNC-CNES-E-40-505
Page 18
REGLES ET RECOMMANDATIONS POUR
LA REALISATION D'UN SERVEUR WEB
Version 2
13 mars 2000
Pages HTML
Ressources
Externes
Navigateur Web
Serveur Web
Composant
s'exécutant dans
le navigateur
Composants
Applications
Externes
Figure 7: Serveurs Web étendus
8.3.3.2 EXEMPLE
Pour livrer aux utilisateurs la télémesure du satellite avec un serveur de type dynamique étendu, on peut,
en plus des possibilités offertes par les serveurs statiques et dynamiques :
• développer une application (en Java par exemple) qui, une fois téléchargée par l’utilisateur,
interrogera directement les fichiers de données brutes de télémesure présents sur un serveur
applicatif, les décommutera et les présentera en fonction des demandes de l’utilisateur.
METHODE ET PROCEDURE
_______
RNC-CNES-E-40-505
REGLES ET RECOMMANDATIONS POUR
LA REALISATION D'UN SERVEUR WEB
9. RÈGLES
Page 19
Version 2
13 mars 2000
DE BASE
9.1 REGLES CONCERNANT L’ANALYSE DU PUBLIC
Objectif
L'analyse du public permet de déterminer les attentes, les goûts, le niveau et le domaine de compétence
des utilisateurs du site Web.
Démarche
L'analyse du public comprend 4 études :
• l'identification du public
• l'évaluation de la connaissance du public quant au contenu de l'information
• l'évaluation de l'expérience du public quant à la technologie Web
• l'analyse des attentes du public
AP.Description
La nature du public visé doit être identifiée.
Description
Les éléments à identifier sont :
• l'âge
• la catégorie socio-professionnelle (profession, fonction ou activité)
• le profil type du public principal, du public secondaire (groupes)
• la langue usuelle du public
• le volume d'audience et les plages horaires de consultation
Justification
Les pages du site Web peuvent être consultées par différents publics : il est donc nécessaire de les
connaître pour adapter le contenu et la présentation des pages au public visé.
Exemple
Le public cible est le suivant :
•
Age : 20-60 ans
•
CSP : Ingénieurs, Techniciens
•
Langue : Français
•
Audience potentielle : 50 util./jour aux heures de bureau en France
METHODE ET PROCEDURE
_______
REGLES ET RECOMMANDATIONS POUR
LA REALISATION D'UN SERVEUR WEB
AP.Connaissance.Métier
RNC-CNES-E-40-505
Page 20
Version 2
13 mars 2000
La connaissance du public visé sur le sujet traité par le site doit
être identifiée
Description
Les différents niveaux de connaissance peuvent être classifiés en :
• expert
• familiarisé
• novice
• étranger au domaine
Justification
Afin d'obtenir une bonne fréquentation, le contenu des pages du site doit être adapté à la
connaissance préalable du public sur le sujet.
Exemple
Les profils visés sont :
•
Chefs de projet, développeurs pour les aider dans leurs choix (public
principal)
•
Ingénieurs spécialisés pour obtenir un retour d'expérience sur un
projet (public secondaire)
•
Toute personne de la société
METHODE ET PROCEDURE
_______
REGLES ET RECOMMANDATIONS POUR
LA REALISATION D'UN SERVEUR WEB
AP.Connaissance.Web
RNC-CNES-E-40-505
Page 21
Version 2
13 mars 2000
L’expérience du public visé quant à la technologie du Web doit
être identifiée.
Description
Les éléments à identifier sont :
• la maîtrise de l’utilisation d'un navigateur :
− sa manipulation,
− son paramétrage,
• la maîtrise de l’utilisation d’une fonction de recherche,
• la maîtrise de l’utilisation d’une messagerie électronique,
• ...
Justification
Plus le public visé est expert dans le maniement de la technologie Web, moins il est nécessaire de
"guider" la consultation des pages. Le contenu et la navigation dans le site devront donc tenir
compte de cette caractéristique du public.
Exemple
Le public cible est familiarisé avec l'utilisation d'un navigateur. Les
personnes concernées savent utiliser des fonctions de recherche lors de
l'utilisation d'une messagerie (cf. menu Outils/Rechercher d’Exchange).
METHODE ET PROCEDURE
_______
RNC-CNES-E-40-505
REGLES ET RECOMMANDATIONS POUR
LA REALISATION D'UN SERVEUR WEB
AP.Attentes
Page 22
Version 2
13 mars 2000
Les attentes du public visé doivent être identifiées.
Description
Les attentes d'un utilisateur consultant un site peuvent être par exemple :
• fournir ou se procurer des informations sur des produits
• acquérir de nouvelles connaissances ou compétences
• effectuer des recherches
• s’abonner à des forums
• partager une passion
Justification
Une bonne connaissance de l'attente du public cible permet d'adapter le contenu du site aux
attentes identifiés.
Exemple
Les attentes des personnes cibles sont les suivantes :
•
collecter des informations relatives aux méthodes, langages et
techniques de développement.
•
prendre contact pour obtenir le bilan et le retour d'expérience sur
un projet.
•
accéder à d'autres serveurs extérieurs sélectionnés traitant du sujet
demandé
METHODE ET PROCEDURE
_______
REGLES ET RECOMMANDATIONS POUR
LA REALISATION D'UN SERVEUR WEB
RNC-CNES-E-40-505
Page 23
Version 2
13 mars 2000
9.2 REGLES CONCERNANT L’ANALYSE DE L’INFORMATION
Objectif
L'analyse de l'information permet d'obtenir l'état du patrimoine documentaire (quelque en soit le
support) concerné par le site Web au moment de l'analyse.
Démarche
L'analyse de l'information passe par les étapes suivantes :
• identification des informations répondant aux attentes du public visé,
• évaluation de l'état actuel de l'information,
• identification des propriétaires de l'information,
• estimation de la fréquence de mise à jour et/ou révision nécessaires,
• estimation du volume d'information à mettre à disposition.
Les informations répondant aux attentes du public visé doivent
être identifiées.
AI.Attentes
Description
Les attentes en information sont identifiés en utilisant les résultats de la règle AP.Attentes.
Les éléments à identifier sont :
• les informations qui seront présentes systématiquement
• les informations à inclure
• les informations qui seront accessibles depuis d'autres sites
• la forme de l'information (texte, graphique, tableaux, …)
Justification
L’étude des attentes du public visé en information permet d'évaluer l'effort de développement
nécessaire.
Exemple
Les informations à inclure dans le site sont les suivantes :
•
la liste des activités
•
pour chaque activité :
• une description générale
• une description logistique :
• une description technique (facultative) :
•
les nouveautés du mois
METHODE ET PROCEDURE
_______
RNC-CNES-E-40-505
REGLES ET RECOMMANDATIONS POUR
LA REALISATION D'UN SERVEUR WEB
AI.Existant.Etat
Page 24
Version 2
13 mars 2000
L'état de l'information à introduire dans le site doit être évalué.
Description
L'information à introduire dans le site se répartit en deux catégories :
• l'information qui fait l'objet de documents pré-existants
• l'information qui n'est pas consignée dans un document
Pour les documents existants, les caractéristiques à identifier sont :
• la localisation des informations disponibles
• le support (papier, le format si informatique, audio, vidéo, …)
• la langue
• l'état d'avancement
• le volume
Pour l'information qui ne fait pas l'objet d'un document, les caractéristiques à identifier sont :
• la localisation et la forme de l'information
• l'évaluation du volume d'information à rédiger
Remarque : Le volume est une expression de la taille des informations et s'exprime en terme de
nombre de pages, de mots, d'images, d'illustrations...
Attention : Toutes les données concernant l'état de l'information sont valables au moment
où l'évaluation est réalisée, et de ce fait peuvent ne pas être figées. Il faut alors statuer sur les
évolutions potentielles.
Justification
L’étude de l'état de l'existant permet de définir les ressources (humaines et matérielles) à prévoir
pour la conception du site.
Le volume de l'information à mettre en ligne est déterminant quant au choix de la technologie
(selon sa fréquence de mise à jour et en terme d'hébergement).
Exemple
Les informations recensées comprennent :
•
des renseignements fournis oralement
•
des textes rédigés en français, fournis au format Word
•
50 documents photographiques sous forme papier ou numérique.
METHODE ET PROCEDURE
_______
REGLES ET RECOMMANDATIONS POUR
LA REALISATION D'UN SERVEUR WEB
AI.Existant.Adaptation
RNC-CNES-E-40-505
Page 25
Version 2
13 mars 2000
Les adaptations sur l'information actuelle doivent être identifiées.
Description
Les éléments à identifier sont :
• la restructuration de l'information pour l'adapter à la technologie Web par rapport aux chartes
graphiques et rédactionnelles
• les illustrations nécessaires à créer pour améliorer ou enrichir le contenu de l'information
• les travaux de traduction éventuels
• les travaux de conversion de format des documents (support informatique, audio, vidéo)
• les travaux de saisie (support papier)
Justification
L’étude des adaptations à réaliser permet d'évaluer une partie de l'effort de développement
nécessaire.
Exemple
Les renseignements oraux doivent être mis par écrits et rédigés sous
Word 97.
METHODE ET PROCEDURE
_______
RNC-CNES-E-40-505
REGLES ET RECOMMANDATIONS POUR
LA REALISATION D'UN SERVEUR WEB
AI.Propriété
Page 26
Version 2
13 mars 2000
Le propriétaire de l'information et les droits de diffusion doivent
être identifiés.
Description
Les éléments à identifier sont, pour chaque information :
• le propriétaire ou l'émetteur
• la durée de validité
• la confidentialité
Remarque : La loi n° 78-17 du 6 janvier 1978 communément dénommée "LOI INFORMATIQUE
ET LIBERTE" impose un certain nombre d'obligations relatives au traitement informatisé
d'informations nominatives permettant d'identifier une ou plusieurs personnes physiques par le
biais notamment de la constitution de fichiers.
Justification
La publication d'information est protégée par les droits d'auteurs. Avant toute publication, il faut
connaître le ou les auteur(s) de l'information afin de demander ou de faire figurer des réserves
quant au contenu de l'information.
Exemple
Toute photographie insérée dans le site doit être accompagnée du nom de
son propriétaire.
AI.Miseàjour
Les besoins de révision et de mises à jour doivent être identifiés.
Description
Les éléments à identifier sont :
• les informations qui devront être soumises à des révisions et des mises à jour
• les caractéristiques qui interviennent dans la pérennité de l'information (date, événement, …)
• les fréquences de mises à jours nécessaires
Justification
L'identification des besoins de révision et de mises à jour de l’information permet d’évaluer
l’effort d’exploitation.
Exemple
Les informations doivent être mises à jour :
• tous les mois pour les nouveautés
• tous les trimestres pour les activités
METHODE ET PROCEDURE
_______
RNC-CNES-E-40-505
REGLES ET RECOMMANDATIONS POUR
LA REALISATION D'UN SERVEUR WEB
Page 27
Version 2
13 mars 2000
9.3 REGLES CONCERNANT L’ANALYSE DE LA TECHNOLOGIE
Objectif
L'analyse de la technologie permet de déterminer :
• côté client, les installations nécessaires pour la consultation du site Web
• côté réalisation :
− les ressources matérielles et logicielles nécessaires au développement du site
− les compétences nécessaires (utilisation de ressources interne ou externe)
L'analyse technologique permet également de déterminer les contraintes en terme de sécurité et d'accès à
l'information.
Démarche
L'analyse de la technologie se divise en 3 études :
• la configuration nécessaire des installations du client
• les environnements de développement et d’exploitation nécessaires au niveau :
− des logiciels bureautique, PAO et multimédia
− des logiciels spécifiques Web
− du matériel du serveur
− des compétences
• les conditions de sécurité et de contrôle d'accès nécessaires
METHODE ET PROCEDURE
_______
RNC-CNES-E-40-505
REGLES ET RECOMMANDATIONS POUR
LA REALISATION D'UN SERVEUR WEB
AT.Config.Client
Page 28
Version 2
13 mars 2000
La configuration des installations du client doit être identifiée.
Description
Les éléments à identifier pour l'installation actuelle sont :
• le type de navigateurs le plus largement utilisé
• la ou les plates-formes utilisées
• le type de connexion utilisé par la majorité du public visé pour accéder au site : via une liaison
directe (connexion rapide) ou via une connexion commutée par l'intermédiaire d'un fournisseur
local d'accès à Internet (connexion lente)
• l'accès à une imprimante
Les éléments à identifier pour l'utilisation du site sont :
• les dispositifs supplémentaires pour l'affichage et les conditions d'utilisation
• les dispositifs supplémentaires pour profiter des informations audio et vidéo et les conditions
d'utilisation
Attention : Toutes les données concernant la configuration des installations du client sont
valables au moment où l'évaluation est réalisée, et de ce fait peuvent ne pas être figées. Il
faut alors statuer sur les évolutions potentielles.
Justification
L'utilisateur consultant le site doit disposer d'une configuration adaptée à la consultation du site,
en matière d'espace disque, de mémoire, d'écran, d'imprimante…
Il faut bien connaître la configuration du poste client pour proposer un site adapté et/ou l'informer
des ressources nécessaires impliquant des installations supplémentaires.
Exemple
Les utilisateurs utilisent Netscape version 4 avec le plug-in Acrobat
pour consulter le site.
METHODE ET PROCEDURE
_______
RNC-CNES-E-40-505
REGLES ET RECOMMANDATIONS POUR
LA REALISATION D'UN SERVEUR WEB
AT.Logiciels.géné
Page 29
Version 2
13 mars 2000
Les besoins en logiciels de bureautique, de PAO et de multimédia
nécessaires pour le développement du site Web doivent être
identifiés.
Description
Les éléments à identifier sont :
• logiciels graphiques nécessaires pour le traitement des images
• logiciels multimédia nécessaires pour les traitements des animations, des vidéos, du son
• outils de conversions de fichiers existants
• outils de compression d'image, de vidéo et d'audio
• éditeurs de texte
• …
Justification
L’objectif est de se doter des outils nécessaires ou de limiter les besoins à ce qu’on sait faire avec
les outils disponibles.
Exemple
Les besoins en logiciels de bureautique, de PAO et de multimédia pour le
développement du site Web sont :
Eléments à définir
Résultat
Logiciel de retouches d'images
Adobe Photoshop
Conversion de fichiers Word en HTML
Microsoft Word 97
Conversion de fichiers FrameMaker en HTML WebWorks Publisher
Conversion de fichiers graphiques
Paint Shop Pro
Création de GIF animés
Microsoft GIF
Animator
Création de graphiques 3D et animation
3D Studio MAX
Bibliothèques d'éléments graphiques
Adobe Galery Effects
METHODE ET PROCEDURE
_______
REGLES ET RECOMMANDATIONS POUR
LA REALISATION D'UN SERVEUR WEB
AT.Logiciels.Web
RNC-CNES-E-40-505
Page 30
Version 2
13 mars 2000
Les logiciels spécifiques Web nécessaires au développement et à
l’exploitation du site doivent être identifiés
Description
Les éléments à identifier sont :
• le logiciel serveur Web (HTTPD) pour le site à créer
• les services à implémenter sur le serveur (FTP, E-mail, DNS, …)
FTP : Il est quelquefois intéressant économiquement de proposer un service FTP pour les
fonctionnalités de téléchargement d'un contenu ou de programmes. Un service FTP est simple
à maintenir et se fait pratiquement sur tout système d'exploitation.
DNS : Un service DNS permet de disposer de noms de domaines personnalisés pour les
utilisateurs.
E-Mail : Un service E-mail permet de rendre vivant son site.
• le ou les outils d'édition de pages
• l'outil d'administration des pages du site
• les outils de tests, de validation de l'arborescence du site pour en assurer la cohérence
• les outils de programmation complémentaires indispensables pour les développements
spécifiques (scripts CGI, JavaScript, …) : ces outils dépendent de l'architecture du serveur
(serveur Web statique, serveur Web dynamique et serveur Web étendu).
• les outils d'indexation de l'information
• les outils d’analyse des logs
Justification
L'architecture Web repose sur une architecture Client/Serveur. Il existe plusieurs outils pour créer
et exploiter les informations (outils d'édition et d'administration de pages) . Les informations
peuvent être présentées de façon simple ou bien enrichies par des développements
complémentaires.
Exemple
Besoins logiciels spécifiques pour le développement et l’exploitation du
site Web :
Eléments à définir
Résultat
Système de la machine hôte
SOLARIS 2.4
Services Internet
CERN
Gestion de sécurité
Fonctionnalités de sécurité
offertes en standard par le
serveur CERN
Editeur de pages HTML
PageMill, Microsoft
FrontPage
Administration des pages du site
Microsoft FrontPage
Langage de scripts et de développement JavaScript et Java
Bases de données
Metaphase
METHODE ET PROCEDURE
_______
REGLES ET RECOMMANDATIONS POUR
LA REALISATION D'UN SERVEUR WEB
AT.Matériels
RNC-CNES-E-40-505
Page 31
Version 2
13 mars 2000
Les matériels nécessaires à la mise en place et l’exploitation du
site doivent être identifiés.
Description
La configuration minimale cible doit être identifiée en termes de :
• Plate-forme
• Système d'exploitation,
• Mémoire ram, mémoire disque
• Taille de l'écran
• Présence d'une carte vidéo, son
• Evolutions possibles
Justification
Cette étude permet de mettre en place les ressources matérielles nécessaires à la conception, au
développement et à l’exploitation du site Web.
Exemple
Le développement doit être réalisé sur un PC Pentium sous Windows 95
avec :
• 16 Mo RAM
• 1 Go disque
• un scanner pour intégrer photos et dessins
METHODE ET PROCEDURE
_______
REGLES ET RECOMMANDATIONS POUR
LA REALISATION D'UN SERVEUR WEB
AT.Compétence
RNC-CNES-E-40-505
Page 32
Version 2
13 mars 2000
Les compétences (ressources humaines) doivent être évaluées.
Description
Les compétences doivent être évaluées par domaine :
• graphisme (photographie, PAO, design, …)
• rédaction
• développement d'applications
• administration réseau
• audio
• vidéo
Remarque : Le support d'experts est préconisé.
Justification
Le développement d'un site Web fait intervenir plusieurs compétences. Les compétences
disponibles en interne ou complémentaire en externe doivent être évaluées pour faire face aux
nécessités du développement.
Exemple
Le développement doit être confié à une équipe possédant des compétences
dans les domaines suivants :
• graphisme
• rédaction
• développement d'application
• administration réseau
METHODE ET PROCEDURE
_______
RNC-CNES-E-40-505
Page 33
REGLES ET RECOMMANDATIONS POUR
LA REALISATION D'UN SERVEUR WEB
Version 2
13 mars 2000
9.4 CHOIX D’UN TYPE DE SERVEUR
Les serveurs Web permettent de répondre à de nombreux besoins de présentation d’informations,
d’interaction avec les utilisateurs et d’intégration avec des données et des systèmes existants. Le tableau
suivant résume la couverture de ces besoins par chacune des architectures de serveurs. Tout besoin
couvert par un type de serveur l’est également par un serveur de type plus élaboré. Afin de réduire la
complexité de la solution, il est préférable de choisir le type de serveur le plus simple (par exemple,
statique plutôt que dynamique) répondant à chacun des besoins :
Besoins
Serveurs
Web
statiques
Serveurs
Web
dynamiques
Serveurs
Web
étendus
Publication d’informations statiques
(institutionnelles, catalogue de services...)
999
9
9
Affichage de données complexes
(données autres que du texte ou des images
bitmap)
999
9
9
(plug-ins ou
composants)
(plug-ins ou
composants)
(plug-ins ou
composants)
Besoin d’interactions complexes avec
l’utilisateur
Récupération d’informations saisies par
l’utilisateur
(saisie de formulaires...)
Mise à jour des informations depuis des
bases de données ou des applications
Mise à jour des informations en temps réel
depuis des bases de données ou des
applications
Personnalisation des informations
présentées en fonction des utilisateurs
Besoins de communication directe entre un
poste client et une application
999
9
9
(plug-ins ou
composants)
(plug-ins ou
composants)
(plug-ins ou
composants)
999
9
(sauf statique
interprété)
999
9
999
9
(sauf statique
interprété)
999
9
(sauf statique
interprété)
999
METHODE ET PROCEDURE
_______
RNC-CNES-E-40-505
REGLES ET RECOMMANDATIONS POUR
LA REALISATION D'UN SERVEUR WEB
10. RÈGLES
Page 34
Version 2
13 mars 2000
COMMUNES ET APPLICABLES AUX SERVEURS STATIQUES
Les règles communes sont indépendantes de l’architecture choisie. Ce sont notamment celles qui sont
applicables aux serveurs statiques. Les règles sont présentées en fonction de la phase du cycle de vie.
10.1 REGLES GENERALES
SS.Processus.Analyses
Des analyses préalables doivent être réalisées (analyse du public,
de l’information et de la technologie).
Description
Les analyses à réaliser en préalable ou en début de phase de spécification sont :
• l'analyse du public,
• l'analyse de l'information,
• l'analyse de la technologie.
Remarque : Les règles applicables pour la réalisation de ces analyses font l'objet du chapitre 9.
Justification
Sans une étude de la cible visée par le serveur, ce dernier risque de n’être que très peu visité et
donc de passer à côté de sa mission. Un tel échec peut être dû :
• à des raisons techniques : l’utilisateur ne dispose pas d’une plate-forme adaptée au serveur (les
exigences imposées peuvent être trop contraignantes), le volume des informations à transférer
est trop important...
• au contenu du serveur : l’information présentée n’est pas compréhensible par tous les
utilisateurs ciblés ou bien l’utilisation du serveur est trop complexe.
Attention : Si le site vise plusieurs populations distinctes, chacune d’elles doit être identifiée,
de manière à pouvoir y rattacher si possible et/ou si nécessaire des sections différentes du
serveur.
Exemple
(cf doc DR11)
METHODE ET PROCEDURE
_______
RNC-CNES-E-40-505
REGLES ET RECOMMANDATIONS POUR
LA REALISATION D'UN SERVEUR WEB
SS.Processus.Développement
Page 35
Version 2
13 mars 2000
Le développement d’un serveur Web doit suivre un cycle de vie
adapté aux technologies web, avec les moyens de gestion associés.
Description
Comme tout projet informatique, le développement d’un serveur Web doit suivre un processus de
développement.
Cependant certaines particularités sont à prendre en compte :
• Au cours de la phase de spécification, il est possible d’envisager des développements itératifs
de maquette pour valider les aspects présentation, navigation, etc.
• Au cours de la phase de conception, il est recommandé de procéder à des développements
incrémentaux de prototypes pour valider certains choix techniques et des points délicats
(présentation, navigation, performance, robustesse, etc.).
• Le document de spécification doit contenir :
• la définition des utilisateurs visés et les contraintes en découlant,
• les exigences pour l’élaboration des chartes graphique, rédactionnelle et
navigationnelle,
• Les fichiers définissant le contenu d’un serveur Web et sa configuration doivent être gérés par
un système de gestion de configuration, dès la phase de développement et durant la phase
d’exploitation. Ceci concerne tous les fichiers, dont notamment :
• les pages HTML
• les fichiers téléchargeables
• les modèles de pages
• les programmes et les scripts éventuellement
• les fichiers de configuration du serveur Web
• la documentation
• les moyens de production
• Les fichiers utilisés par un serveur Web opérationnel ainsi que le serveur Web lui-même
(moteur, fichiers de configuration, adresse...) doivent être séparés de la version utilisée en
développement.
Justification
Le cycle de vie est un modèle qui permet de positionner et de suivre les activités d’un projet. Une
réalisation Web est un projet. Il doit suivre un cycle de vie pour éviter la dispersion.
Exemple
Sans objet
METHODE ET PROCEDURE
_______
REGLES ET RECOMMANDATIONS POUR
LA REALISATION D'UN SERVEUR WEB
SS.Processus.Tests
RNC-CNES-E-40-505
Page 36
Version 2
13 mars 2000
Tous les niveaux de tests doivent être réalisés pour le
développement d’un serveur Web.
Description
Comme tout projet informatique, le développement d’un serveur Web doit inclure des phases de
tests :
• tests unitaires de l’interface utilisateur et de la partie applicative,
• tests de validation de l’ensemble (en particulier tests d’environnement, de performance, de
sécurité),
• recette externe sur site précédée d’un bilan technique (BT) et suivie d’une commission de
revue des essais (CRE) comme décrit dans [DR1].
La documentation de tests doit être complète comme pour une application classique (dossiers de
tests, journal d’essais, trace du passage des tests, ...) et un cahier de recette est obligatoire.
Justification
Les tests sont des activités indispensables pour garantir un fonctionnement correct du serveur
développé, en conformité avec la spécification.
Exemple
Sans objet
SS.Documentation
La réalisation d’un serveur Web doit être documentée.
Description
Comme tout projet informatique, le développement d’un serveur Web doit inclure la rédaction de
la documentation soit :
• une documentation de spécification
• un dossier de conception avec un dossier d'architecture
• une documentation de tests complète avec un dossier de tests, journal d’essais, trace du
passage des tests, ... et un cahier de recette
• un dossier d'exploitation
En particulier, un dossier d'exploitation et un dossier d'architecture sont nécessaires pour l'obtention de
l'agrément sécurité d'un serveur WEB (Cf. [DR4] et [DR5]).
Justification
La documentation est un élément indispensable pour assurer un déroulement correct du
développement et de la maintenance du serveur.
Exemple : sans objet
METHODE ET PROCEDURE
_______
REGLES ET RECOMMANDATIONS POUR
LA REALISATION D'UN SERVEUR WEB
SS.Ergonomie.MP&IHM
RNC-CNES-E-40-505
Page 37
Version 2
13 mars 2000
Un ensemble de règles concernant l'interface homme machine du
serveur Web doit être appliqué.
Description
Il faut définir l’ensemble des règles concernant l’ergonomie. Pour cela, il faut désigner les règles
du document « Règles et recommandations d’ergonomie des interfaces Homme Machine
informatiques » (DR4), applicables dans le cas précis du serveur à réaliser.
Dans tous les cas, un sous-ensemble de ces règles est applicable à la réalisation des chartes ; ces
règles sont listées en annexe du document (DR11)
Justification
Afin d’assurer une bonne ergonomie, maniabilité et robustesse d’un serveur Web, il est vital de
respecter un ensemble de règles générales.
Un serveur Web, c’est surtout de l’IHM.
Exemple
Sans objet
METHODE ET PROCEDURE
_______
REGLES ET RECOMMANDATIONS POUR
LA REALISATION D'UN SERVEUR WEB
SS.Portabilité.Navigateur
RNC-CNES-E-40-505
Page 38
Version 2
13 mars 2000
Les dispositifs proposés par le site Web doivent pouvoir être mis
en oeuvre par tous les utilisateurs de la population cible.
Description
Les pages Web doivent pouvoir être visualisées correctement sur tous les navigateurs Web et
toutes les plates-formes (Windows 3.x/95/NT, Unix, MacOs, ...) utilisés par la population ciblée.
Il en est de même des mécanismes utilisés et il faut notamment veiller :
• au langage utilisé pour les scripts clients (JavaScript),
• à la disponibilité ou la possibilté de télécharger des plug-ins et des helpers sur les platesformes cibles,
• à l’environnement d’exécution des composants inclus (Java...)
Les contraintes imposées à l’environnement des utilisateurs peuvent éventuellement être plus
fortes dans le cas d’une utilisation par un groupe spécifique d’utilisateurs (Intranet).
Remarque : L'application de cette règle passe par la connaissance du matériel dont disposent les
utilisateurs appartenant à la population cible (cf chapitre 9).
Justification
Afin d’assurer l’utilisabilité d’un serveur Web, il est vital de respecter des critères de portabilité
de la solution choisie.
Exemple
Sans objet
METHODE ET PROCEDURE
_______
REGLES ET RECOMMANDATIONS POUR
LA REALISATION D'UN SERVEUR WEB
SS.Sécurité.MP&Sécurite
RNC-CNES-E-40-505
Page 39
Version 2
13 mars 2000
Les exigences du document " Exigences de sécurité pour
l’utilisation des serveurs et relais HTTP " (DR5) doivent être
appliquées, en particulier dans le cas d’un serveur Web accessible
depuis l’extérieur du CNES.
Description
Les règles générales de sécurité telles que décrites dans (DR5) doivent être appliquées sur un
projet de construction de serveur Web.
Dans le cas particulier d’un site Web accessible depuis l’extérieur du CNES, l’application de ces
règles est obligatoire et contrôlée au cours d’une recette « sécurité » (sanctionnée par un agrément
sécurité).
Remarque : Dans le cas d'un agrément sécurité, il est recommandé de développer un serveur le
plus simple possible.
A titre d’information complémentaire sur les exigences de sécurité d’un serveur Web, le
document Cahier de recette du serveur HTTP UNIX du CERN (DR7) peut être consulté.
Justification
Un serveur Web constitue un développement à part entière et de par l’ouverture au système
d’information qu’il propose, les règles de sécurité associées doivent être strictement respectées.
Exemple
Dans le cadre du produit IW3, ces règles sont mises en oeuvre au travers
de la structure d'accueil "chrootée" et de la sécurisation des
librairies applicatives.
METHODE ET PROCEDURE
_______
RNC-CNES-E-40-505
REGLES ET RECOMMANDATIONS POUR
LA REALISATION D'UN SERVEUR WEB
Page 40
Version 2
13 mars 2000
10.2 REGLES APPLICABLES EN PHASE DE SPECIFICATION
SS.Ergonomie.Charte
Une charte navigationnelle, une charte rédactionnelle et une charte
graphique doivent être spécifiées.
Description
Lors de la spécification, on doit définir les exigences à respecter pour réaliser :
• la charte graphique décrivant les règles de présentation (style, découpage, icônes,...) ; la
participation de graphistes professionnels est fortement recommandée
• la charte rédactionnelle contenant les règles de rédaction du contenu des pages,
• la charte navigationnelle, décrivant les règles de navigation entre les différentes pages du
serveur et vers d’autres serveurs.
L'ensemble des règles applicables pour la spécification de ces chartes est présenté dans le
document Règles pour la réalisation de chartes pour un serveur Web (DR11).
Justification
Sans charte graphique, les informations présentées par le serveur Web risquent de ne pas être
homogènes et de dérouter l’utilisateur. De plus, l’absence de charte graphique risque de multiplier
les retours sur la présentation, l’ergonomie des pages, ....
Sans charte rédactionnelle, les informations présentées par le serveur Web risquent de ne pas être
adaptées au public visé (non compréhensibles, pouvant prêter à confusion...). De plus, il est
important de respecter la forme du message société.
Sans charte de navigation, le serveur risque de ne pas être homogène et de dérouter l’utilisateur.
Exemple
(cf doc DR11)
METHODE ET PROCEDURE
_______
RNC-CNES-E-40-505
REGLES ET RECOMMANDATIONS POUR
LA REALISATION D'UN SERVEUR WEB
SS.Spécification.Formation
Page 41
Version 2
13 mars 2000
Les personnes qui spécifient un serveur Web doivent être formées
aux technologies Web.
Description
Lors de la spécification, la connaissance du besoin n’est pas suffisante. Il est nécessaire de
connaître les principes de fonctionnement d’un serveur Web et ses possibilités.
Le support d’un spécialiste des technologies Web est vivement recommandé lors de cette phase.
Au minimum, le spécifieur doit disposer (lui-même ou son support) des connaissances sur les
domaines suivants :
• les principes du protocole HTTP,
• le langage HTML, ses contraintes et limites, ses différentes versions,
• les formats graphiques, leurs contraintes et limites,
• le mode d’interaction des formulaires (FORM) et les conséquences des performances du réseau
sur le mode opératoire, à cause du protocole HTTP,
• les informations stockables dans le journal des accès et le journal des erreurs,
• l’appel aux applications CGI, les contraintes et limites.
Selon le cas, des notions sur les possibilités des points suivants peuvent être nécessaires :
• les scripts Javascript,
• les applets Java voire ActiveX,
• les extensions (plug-ins et helper applications),
• les formats audio et vidéo ainsi que les applications « au fil de l’eau » (streaming) comme la
téléconférence.
Justification
• La méconnaissance des technologies Web et de leurs possibilités risque de conduire à définir
une spécification mal adaptée aux serveurs Web, en particulier les échanges de données entre
l’utilisateur et le serveur sont très particuliers et sont difficilement comparables à un système
client - serveur classique.
• La découverte tardive des possibilités des serveurs Web risque de multiplier les demandes de
modifications de la spécification de départ.
METHODE ET PROCEDURE
_______
REGLES ET RECOMMANDATIONS POUR
LA REALISATION D'UN SERVEUR WEB
SS.Spécification.Evolution
RNC-CNES-E-40-505
Page 42
Version 2
13 mars 2000
Dès la spécification, il faut définir et caractériser les informations
évolutives du site qui seront mises en évidence.
Description
Les informations présentées par un site Web sont amenées à évoluer (informations nouvelles,
mises à jour des informations) et il est important d’en avertir l’utilisateur.
Il faut définir, dès la spécification du site, le type des informations du site susceptibles d’évoluer
(mise à jour ou création), de quelle façon (personnalisée ou non) et jusqu’à quel niveau de détail
on veut les indiquer à l’utilisateur.
Justification
La vocation essentielle d’un site Web est d’informer ses utilisateurs. Les utilisateurs étant en
général amenés à consulter le serveur de manière régulière, il est important pour capter leur
attention et afin d’assurer une bonne qualité de service de leur permettre un accès rapide aux
informations nouvelles.
Il existe de nombreuses solutions, de granularité différente, pour permettre à l’utilisateur
d’accéder aux informations nouvelles.
La prise en compte a posteriori de la fonction de mise en évidence des informations nouvelles
nécessite une modification du serveur qui peut être très coûteuse, surtout si elle doit être
automatique.
Exemple
Selon le besoin spécifié, la solution en conception s’appuiera sur un
serveur externe qui balaie régulièrement les pages statiques d’un
ensemble de sites, ou nécessitera une solution particulière, pour des
services basés sur des pages dynamiques ou des applications
spécialisées. Ainsi, cela peut se traduire de différentes façons :
1)Il est possible de prévoir une page contenant des liens vers les
nouvelles informations du serveur présentées par ordre chronologique
inverse. Il faut alors proposer un lien vers cette page depuis la
page d’accueil du serveur.
2)On peut ajouter un petit icône « new » après les informations
nouvelles (...du jour, de la semaine, du mois, selon la
spécification).
3)On peut également mettre en gras ou d’une couleur différente les liens
vers les pages contenant les nouveautés.
4)Sur un serveur dynamique, on peut stocker l’identité de l’utilisateur
et déterminer dynamiquement les pages du sites, nouvellement ajoutées
depuis sa dernière visite (du site, du thème, etc. à spécifier).
METHODE ET PROCEDURE
_______
REGLES ET RECOMMANDATIONS POUR
LA REALISATION D'UN SERVEUR WEB
SS.Spécification.FichierTrace
RNC-CNES-E-40-505
Page 43
Version 2
13 mars 2000
Dès la spécification, les besoins du site en matière d’analyse des
fichiers de trace des accès au serveur (log et erreur) doivent être
définis.
Description
L’analyse des fichiers de trace des accès au serveur est un moyen de surveillance du
fonctionnement du site Web. Cette analyse doit être spécifiée en terme de granularité, de
fréquence et d’outillage (outils disponibles ou spécifiques).
Dans le cas d’un site ouvert à l’extérieur du CNES et faisant l’objet d’un agrément sécurité, des
exigences spécifiques sont énoncées dans le document « Exigences de sécurité pour l’utilisation
des serveurs et relais HTTP » (DR5).
Justification
Les accès au serveur et les erreurs du serveur doivent être consignés dans un fichier afin de
permettre la surveillance de l’exploitation du site et le suivi de sa conformité aux objectifs
assignés, en utilisant les outils de trace disponibles.
Exemple
Voici quelques exemples d’opérations possibles avec l’analyse des
fichiers de trace des accès au serveur:
Juger de l’utilité de chaque service et page du site et décider des
modifications (la granularité de l’analyse est à spécifier),
Connaître les sites pointeurs d’origine des visiteurs,
Détecter les types de navigateur utilisés par les visiteurs et adapter
le contenu en conséquence,
Analyser les goulets d’étranglement dans les services et moyens de
support (réseau, base de données, processeurs applicatifs etc.),
Détecter rapidement les accès frauduleux et prendre les mesures
palliatives,
Tracer les erreurs internes pour les corriger.
METHODE ET PROCEDURE
_______
REGLES ET RECOMMANDATIONS POUR
LA REALISATION D'UN SERVEUR WEB
SS.Spécification.Serveur
RNC-CNES-E-40-505
Page 44
Version 2
13 mars 2000
Dès la spécification, il est recommandé de définir un dispositif de
remplacement du serveur Web pendant les phases de maintenance.
Description
Pendant les phases de maintenance du serveur Web (installation et recette d’une nouvelle version,
évolution de la structure de la base d’informations), il est conseillé d’interdire les accès au serveur
opérationnel et d’avertir les utilisateurs de l’indisponibilité du serveur.
Justification
Pendant les phases de maintenance, le fonctionnement du serveur peut être perturbé et certains
accès utilisateurs peuvent nuire au déroulement des opérations de maintenance.
Il est préférable alors d’arrêter le serveur et d’avertir les utilisateurs de son indisponibilité en
mettant à disposition un serveur alternatif affichant une page particulière.
Exemple
Pour le serveur ANDROMAQ, un serveur de maintenance est activé pendant
les phases de maintenance du serveur opérationnel. La page affichée
index.html ne donne accès à aucune fonctionnalité du serveur
opérationnel :
METHODE ET PROCEDURE
_______
REGLES ET RECOMMANDATIONS POUR
LA REALISATION D'UN SERVEUR WEB
RNC-CNES-E-40-505
Page 45
Version 2
13 mars 2000
10.3 REGLES APPLICABLES EN PHASE DE CONCEPTION ET DE REALISATION
SS.Conception.Résultat
La phase de conception doit déboucher sur un dossier de
conception comprenant des éléments spécifiques aux sites Web et
éventuellement un prototype ou une maquette.
Description
A la fin de la phase de conception, les questions suivantes doivent impérativement avoir trouvé
une réponse :
• Qui est visé par le serveur et quelles contraintes en découlent ?
• Comment l’information sera-t-elle structurée ? (rubriquage)
• A quoi ressemblera le résultat final ? (validé par une maquette ou un prototype)
• Quels choix graphiques ont été faits ? (charte graphique)
• Quels choix de rédaction ont été faits ? (charte rédactionnelle)
• Comment l’utilisateur final naviguera-t-il dans l’information ? (charte de navigation)
Le dossier de conception doit comprendre, en plus du contenu classique, les éléments suivants :
• un document d’architecture du site,
• un dossier justificatif des choix d’architecture,
• un document de rubriquage (structuration de l’information),
• les chartes graphique, rédactionnelle et navigationnelle
• les dispositions induites par le choix des utilisateurs cible,
• un document d’exploitation précisant les solutions retenues pour l’analyse des logs,
la mise en évidence des informations nouvelles, ....
Justification
Si les réponses à ces questions n’ont pas été trouvées en fin de conception, de mauvais choix
auront peut-être été faits et cela posera des problèmes bien plus importants par la suite.
Exemple
Sans objet.
METHODE ET PROCEDURE
_______
REGLES ET RECOMMANDATIONS POUR
LA REALISATION D'UN SERVEUR WEB
SS.Conception.Version
RNC-CNES-E-40-505
Page 46
Version 2
13 mars 2000
La date de dernière modification des pages statiques doit être
affichée.
Description
La date de dernière modification d’une page statique doit être affichée en bas de page.
Dans le cas de l’utilisation d’un sommaire plus particulièrement avec des frames, il peut être plus
judicieux d’afficher la date de modification dans le dit sommaire à côté des liens. Il faut toutefois
la mettre en commentaire dans le code HTML des pages ne l’affichant pas.
Justification
Les informations publiées sur un serveur Web étant gérées de manière centralisée, il est possible
de les mettre à jour relativement souvent. Ainsi, pour informer l’utilisateur de la fraîcheur des
informations proposées, il est recommandé de préciser la date, et donc l’âge de ces informations.
Exemple
Le code HTML suivant peut être utilisé en bas de page:
<CENTER><FONT SIZE="-1">Date de derniàre modification : 10
juillet 1997</FONT></CENTER>
Ou, en Javascript :
<SCRIPT>
document.write("This page updated on "+ document.lastModified)
</SCRIPT>
METHODE ET PROCEDURE
_______
RNC-CNES-E-40-505
REGLES ET RECOMMANDATIONS POUR
LA REALISATION D'UN SERVEUR WEB
SS.Conception.FichierTrace
Page 47
Version 2
13 mars 2000
Le mécanisme de trace des accès au serveur doit être mis en place
et paramétré.
Description
Les accès au serveur et les erreurs du serveur doivent être consignés dans des fichiers de log. Le
mécanisme de trace, spécifique du serveur utilisé, doit être paramétré en fonction des
spécifications d’analyse de ces fichiers de trace (cf. règle SE.Spécification.Méthode&Applet).
Dans le cas d’un site ouvert à l’extérieur du CNES et faisant l’objet d’un agrément sécurité, des
exigences spécifiques sur les fichiers de log sont énoncées dans le document « Exigences de
sécurité pour l’utilisation des serveurs et relais HTTP » (DR5).
Afin d’en faciliter l’exploitation ultérieure, il faut effectuer une rotation des fichiers de log à
intervalles réguliers, en fonction de la fréquence d’accès au serveur, et donc de la taille des
fichiers de log. La rotation des fichiers de log consiste à archiver les versions courantes.
Justification
L’objectif de cette règle est de répondre aux exigences de la règle Spécification
SS.Spécification.FichierTrace pour le suivi de l’exploitation du site.
Exemple
Sur le serveur httpd du CERN, on peut préciser dans le fichier de
configuration du serveur deux directives pour générer les traces d’accès
et les traces d’erreur:
AccessLog /absolute/path/logfile
ErrorLog /absolute/path/errorlog
Par contre, le paramétrage de la trace est limité à la désactivation de
la trace sur certaines adresses IP.
METHODE ET PROCEDURE
_______
REGLES ET RECOMMANDATIONS POUR
LA REALISATION D'UN SERVEUR WEB
SS.Configuration.MIME
(Recom)
RNC-CNES-E-40-505
Page 48
Version 2
13 mars 2000
Il est recommandé de définir les types MIME des documents
téléchargeables au niveau du serveur.
Description
Un document retourné par le serveur Web doit définir correctement son type MIME.
Les types MIME par défaut des documents téléchargeables doivent être définis dans la
configuration du serveur en fonction de l’extension du fichier ou de son type, propres au système
d’exploitation hébergeant le serveur Web.
Justification
Les documents retournés par un serveur Web à un navigateur Web respectent le format MIME. En
fonction du type du document ainsi défini par le serveur, le navigateur peut décider de l’action à
réaliser : affichage par le navigateur lui-même (HTML, images...), affichage par une application
externe. Le navigateur Web définit en standard de telles associations type/action, et la liste de ces
associations peut être étendue. Il est donc important que les types MIME des documents retournés
par un serveur Web soient standards, et notamment tels que définis dans les navigateurs.
Exemple
Pour trouver les types standards MIME reconnus par défaut par les
navigateurs Web, on peut consulter la liste des associations type/action
enregistrées par le navigateur (consulter la rubrique options ou
préférences).
La RFC 2046 définit la norme d’utilisation des types MIME. Cette RFC
peut être obtenue en recherchant des informations sur MIME à l’aide d’un
moteur de recherche Web. Un lien direct existant est
http://www.oac.uci.edu/indiv/ehood/MIME/rfc2046.html
METHODE ET PROCEDURE
_______
REGLES ET RECOMMANDATIONS POUR
LA REALISATION D'UN SERVEUR WEB
SS.Configuration.ErreurAccès
(Recom)
RNC-CNES-E-40-505
Page 49
Version 2
13 mars 2000
Il est recommandé de définir les pages affichées en cas d’erreur
d’accès au serveur.
Description
En cas d’erreur (erreur interne, page non trouvée, URL mal orthographié), la plupart des serveurs
Web permettent l’affichage d’une page spécifique à un type d’erreur. La page doit permettre à
l’utilisateur de comprendre l’erreur et de pouvoir reprendre son parcours sur le site et d’informer
l’administrateur du site, le cas échéant.
Justification
En l’absence de pages spécifiques, les serveurs du commerce émettent un en-tête HTTP avec le
code d’erreur et un texte explicatif simple en anglais. Les navigateurs du commerce, en recevant
cet en-tête, affichent une page en anglais avec le code, l’explication et un lien hypertexte vers la
page d’origine.
En créant systématiquement des pages d’erreur, on peut les personnaliser et assurer l’homogénéité
de la configuration du site selon les chartes graphique et rédactionnelle.
Exemple
La définition de la page à afficher en cas d’erreur interne au serveur
Netscape Enterprise est possible dans le fichier de configuration
obj.conf à l’aide de la directive :
Error code="500" fn="send-error" path="/chemin/serverr.html"
Avec le serveur httpd du CERN (depuis la version 3.0A), rajouter dans le
fichier de configuration les références relatives des pages
correspondant aux numéros d’erreurs :
ErrorUrl
403
<location>/mon-message-erreur-403
ErrorUrl
404
<location>/mon-message-erreur-404
Avec le serveur Apache, voici des exemples de directives d’affichage de
pages spécifiques d’erreur:
ErrorDocument 500 http://foo.example.com/cgi-bin/tester
ErrorDocument 404 /cgi-bin/bad_urls.pl
ErrorDocument 401 /subscription_info.html
ErrorDocument 403 "Sorry can’t allow you access today"
METHODE ET PROCEDURE
_______
RNC-CNES-E-40-505
REGLES ET RECOMMANDATIONS POUR
LA REALISATION D'UN SERVEUR WEB
SS.Ergonomie.Plugin
Page 50
Version 2
13 mars 2000
Les liens vers des documents nécessitant l’utilisation de
dispositifs particuliers doivent être accompagnés d’informations
sur la mise en oeuvre de ce dispositif.
Description
Une page HTML peut contenir des éléments qui peuvent être affichés à l’intérieur de la page
seulement si l’utilisateur dispose du module externe incorporé approprié (plug-in). La page
contenant ces éléments, et éventuellement les liens faisant référence à cette page doivent
mentionner la nécessité de disposer de ce module externe incorporé.
Afin de permettre aux utilisateurs de visualiser ces éléments, des informations sur le module
externe incorporé nécessaire doivent être affichées. De plus, si le module externe incorporé est
téléchargeable, un lien permettant de le télécharger et donnant des informations sur la procédure
d’installation doit être affiché.
Les liens pointant vers des documents affichables à l’aide d’un module d’aide (helper application)
doivent mentionner l’outil utilisé et sa version. Le cas échéant, des informations, voire un lien,
permettant de télécharger et d’installer le module peuvent être ajoutées.
Justification
Les utilisateurs ne disposant pas du module externe incorporé doivent pouvoir être guidés afin de
pouvoir le récupérer et l’installer.
Il ne faut faire aucune supposition sur les applications installées sur le poste de l’utilisateur. De
plus, le nommage des fichiers, et notamment leurs suffixes, ne permettent pas forcément
d’identifier leur format et l’outil à utiliser. Il est donc nécessaire de mentionner le format des
fichiers téléchargeables.
Il est à noter que les plug-ins et les helper applications, en tant qu’applications exécutables, sont
dépendantes de la plate-forme cliente cible (matériel et système d’exploitation). Ceci a donc un
impact sur l’étendue de la population visée par le serveur. Ne pas proposer de plug-in ou de helper
application pour une plate-forme donnée réduit intrinsèquement la cible pouvant potentiellement
utiliser l’information.
Exemple
Voici le code HTML correspondant à l’affichage du message :
Pour visualiser l’animation ci-dessous, vous devez télécharger et
installer le module incorporé XYZ.aaa.bbb
<BR>
Pour visualiser l’animation ci-dessous, vous devez <A
HREF="http://xyz">télécharger</A> et installer le module
incorporé XYZ.
<EMBED SRC="aaa.bbb">
Voici un lien permettant de télécharger le document Word6 proc.doc :
<A HREF="/downloads/proc.doc">proc.doc</A> (56Ko, Word 6.0)
METHODE ET PROCEDURE
_______
REGLES ET RECOMMANDATIONS POUR
LA REALISATION D'UN SERVEUR WEB
SS.Ergonomie.Lien
RNC-CNES-E-40-505
Page 51
Version 2
13 mars 2000
Les liens vers des documents téléchargeables volumineux (> 30
Ko) doivent être accompagnés d’une mention de leur taille.
Description
Un lien vers un document téléchargeable (page HTML, fichier...) doit être suivi de la taille du
document.
Il faut de plus justifier la pertinence de mise à disposition de documents particulièrement
volumineux (> 500 Ko).
Justification
La mention de la taille des documents permet de prévenir les utilisateurs du temps prévisible de
téléchargement (fonction de la bande passante de leur connexion au site et de la charge du réseau)
et de la taille nécessaire pour sauvegarder le document.
Exemple
<A HREF="http://xxx/yyy.doc">yyy.ps</A> (440 Ko; PostScript)
METHODE ET PROCEDURE
_______
REGLES ET RECOMMANDATIONS POUR
LA REALISATION D'UN SERVEUR WEB
SS.HTML.Norme
RNC-CNES-E-40-505
Page 52
Version 2
13 mars 2000
Les pages Web doivent être créées en respectant la norme HTML
définie par le W3C et supportée par les navigateurs ciblés.
Description
Les pages Web doivent respecter le standard HTML tel que défini par le W3C (World-Wide-Web
Consortium). La version du langage HTML à utiliser doit être celle la plus supportée par les
navigateurs Web ciblés. Dans le cas d’un serveur Web dédié à une population spécifique, on peut
se permettre d’utiliser un standard HTML plus récent, pourvu qu’il soit supporté par les
navigateurs Web dont disposent ces utilisateurs.
L’utilisation d’un outil ou d’un service de validation de code HTML conformément au standard
utilisé est préconisé.
Justification
Afin de permettre aux pages Web d’être consultées par les utilisateurs définis par la cible, il est
nécessaire de se conformer aux standards.
Ceci est d’autant plus nécessaire que plusieurs extensions propriétaires du langage HTML ont
existé ou existent encore.
Exemple
La liste des outils ou services de validation de pages HTML est longue.
Il est conseillé de se référer aux listes établies sur des sites tels
que :
• Le World Wide Web Consortium (www.w3c.org) qui liste des outils
relatifs au langage HTML (éditeurs, vérificateurs...)
• Les moteurs d’indexation des sites Internet, et notamment ceux
classifiant les sites en fonction de catégories, tels que Yahoo
(www.yahoo.com), et en recherchant la rubrique correspondant aux
vérificateurs de code HTML (par exemple la catégorie Computers and
Internet / Information and Documentation / Data Formats / HTML /
Validation and Checkers)
METHODE ET PROCEDURE
_______
RNC-CNES-E-40-505
Page 53
REGLES ET RECOMMANDATIONS POUR
LA REALISATION D'UN SERVEUR WEB
Version 2
13 mars 2000
Les caractères spéciaux doivent être spécifiés à l’aide du code
HTML correspondant.
SS.HTML.CarSpéciaux
Description
Les caractères spéciaux, dont les caractères accentués, doivent être écrits à l’aide du code HTML
correspondant : &code; .
Justification
Le code des caractères spéciaux est dépendant de la plate-forme et ces caractères doivent donc
être spécifiés dans un format indépendant.
Exemple
En HTML, écrire :
caractère au lieu de :
caractère
Une table de correspondance entre les caractères ISO 8859-1 (Latin 1) et
les noms HTML est donnée à :
http://www.uni-passau.de/~ramsch/iso8859-1.html
http://gotlib/INTERNET/DOC_WWW/DOC_HTML/accentuatio.html
Voici quelques codes HTML des caractères spéciaux les plus utilisés :
é
ù
"
ç
:
:
:
:
é
ù
"
ç
SS.HTML.MotsClés
è
ô
§
<
:
:
:
:
è
ô
§
<
ê
î
«
>
:
:
:
:
ê
î
«
>
à
ï
»
&
:
:
:
:
à
ï
»
&
Les mots-clés ou tags et les options du langage doivent être mis en
majuscules.
Description
Les mots-clés du langage HTML, nommés « tags » et encadrés des caractères < et >, ainsi que les
options du langage doivent être mis en majuscules.
Justification
Ceci permet de repérer rapidement les tags et options dans un fichier HTML.
Exemple
Voir exemple de la règle SS.HTML.Structure
METHODE ET PROCEDURE
_______
REGLES ET RECOMMANDATIONS POUR
LA REALISATION D'UN SERVEUR WEB
SS.HTML.Commentaires
RNC-CNES-E-40-505
Page 54
Version 2
13 mars 2000
Il est conseillé de mettre des commentaires dans un fichier
HTML.
Description
Il est conseillé de commenter le code d’un fichier HTML en ajoutant des lignes au format suivant
:
<!-- commentaire ... -->.
Justification
La présence de commentaires dans un fichier HTML permet d’expliquer son contenu et donc de
faciliter sa maintenance.
Exemple
Voir exemple de la règle SS.HTML.Structure
SS.HTML.Tags
A tout tag d’ouverture doit correspondre un tag de fermeture.
Description
Les instructions HTML sont délimitées par un tag d’ouverture (<TAG>) et un tag de fermeture
(</TAG>). A tout tag d’ouverture doit correspondre un tag de fermeture, excepté dans certains cas
pour les tags tels que <BR>, <HR>, <P>, ....
Justification
La présence du tag de fermeture, bien que, dans certains cas, facultatif en HTML, facilite la lisibilité.
Exemple
Voir exemple de la règle SS.HTML.Structure
METHODE ET PROCEDURE
_______
REGLES ET RECOMMANDATIONS POUR
LA REALISATION D'UN SERVEUR WEB
SS.HTML.Lisibilité
RNC-CNES-E-40-505
Page 55
Version 2
13 mars 2000
Les fichiers HTML doivent être structurés.
Description
Les fichiers HTML doivent être structurés en utilisant les caractères blancs (touche ESPACE) et
retour chariot (touche RETURN ou Entrée) qui ne sont pas interpretés par HTML. On peut ainsi :
• limiter la longueur des lignes,
• aérer le fichier en introduisant des lignes blanches,
• indenter les lignes de façon à mettre en évidence les tags structurants ou à représenter la forme
de la page telle qu’elle apparaît à l’écran, en particulier au niveau des listes.
De plus, lorsqu’un tag ne concerne qu’une phrase courte, on peut écrire sur la même ligne le tag
de début, la phrase et le tag de fin.
Justification
Le code HTML peut ainsi être présenté comme un code source classique en améliorant
considérablement sa lisibilité.
Exemple
Voir exemple de la règle SS.HTML.Structure
METHODE ET PROCEDURE
_______
RNC-CNES-E-40-505
Page 56
REGLES ET RECOMMANDATIONS POUR
LA REALISATION D'UN SERVEUR WEB
Version 2
13 mars 2000
Les fichiers HTML doivent respecter une trame minimum.
SS.HTML.Structure
Description
Les fichiers HTML doivent contenir un certain nombre de tags obligatoires aui constitue la trame
minimum suivante :
<HTML>
<HEAD>
</HEAD>
<BODY>
</BODY>
</HTML>
Justification
Le respect d’une trame permet de ne pas oublier des tags importants et d’obtenir une homogénéité
des fichiers HTML.
Exemple de page HTML simple
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=windows1252">
<META NAME="Generator" CONTENT="Microsoft Word 97">
<TITLE>Nouveautés d'ANDROMAQ</TITLE>
<!-- SCCS : @(#)nouveautes.html 1.2 -->
<!-- Modifié par Gérard Guillot le 30-Mars-1998 -->
</HEAD>
<BODY
BACKGROUND = "/Icones/fond.gif">
<CENTER><H1>Nouveautés d'ANDROMAQ</H1></CENTER>
<CENTER>en date du 30/03/1998</CENTER>
<P>
<P>
<P>La base d'informations ANDROMAQ continue de s'enrichir :
<P>
<DIR>
<IMG SRC="/Icones/balle-jaune" ALIGN=TOP> <B> de nouvelles fiches
sont disponibles</B>
<DIR>
<BR>
<IMG SRC="/Icones/balle-rouge" ALIGN=TOP>
Cooperation for Space Standardisation
<BR>
<IMG SRC="/Icones/balle-rouge" ALIGN=TOP>
Assurance Produit Logiciels
<BR>
</DIR>
ECSS - European
ECSS-Q-80 -
METHODE ET PROCEDURE
_______
REGLES ET RECOMMANDATIONS POUR
LA REALISATION D'UN SERVEUR WEB
RNC-CNES-E-40-505
Page 57
Version 2
13 mars 2000
<P>
<IMG SRC="/Icones/balle-jaune" ALIGN=TOP> <B> quelques fiches ont
été mises à jour</B>
<DIR>
<BR>
<IMG SRC="/Icones/balle-rouge" ALIGN=TOP> Ada_83 Langage de programmation Ada version 83
<BR>
<IMG SRC="/Icones/balle-rouge" ALIGN=TOP> Ada_95 Langage de programmation Ada version 95
<BR>
<IMG SRC="/Icones/balle-rouge" ALIGN=TOP> Java - Langage
de programmation orienté objet
<BR>
</DIR>
<P>
</DIR>
<P>
<IMG SRC="/Icones/statvis1.gif" ALT="ObjetGraphique Les 20 fiches
les plus visualiées" ALIGN=CENTER>
</P>
<P>
<P>Vous pouvez :
<P>
<DIR>
<IMG SRC="/Icones/balle-jaune" ALIGN=TOP> revenir à la
<B><A HREF="Welcome">page d'accueil</A></B>,
<P>
<IMG SRC="/Icones/balle-jaune" ALIGN=TOP> lancer une "<B><A
HREF="/CGI/Interroge">recherche et consultation</A></B>",
<P>
<IMG SRC="/Icones/balle-jaune" ALIGN=TOP> <B><A
HREF="/CGI/Maj/GestionFiches">proposer</A></B> une fiche.
</DIR>
</BODY>
</HTML>
METHODE ET PROCEDURE
_______
RNC-CNES-E-40-505
REGLES ET RECOMMANDATIONS POUR
LA REALISATION D'UN SERVEUR WEB
Page 58
Version 2
13 mars 2000
Exemple de page HTML avec frame
<HTML>
<META NAME="Author" CONTENT="Jean-Marc DELTRUEL">
<META NAME="Lastmodified" CONTENT="06/08/97">
<HEAD>
<TITLE>Serveur WWW de la division QL</TITLE>
</HEAD>
<FRAMESET COLS="15%,*" FRAMEBORDER="0" FRAMESPACING="0" BORDER="0">
<FRAME NAME="table_des_matieres" SRC="table_des_matieres.html"
MARGINWIDTH="2">
<FRAMESET ROWS="*,5%">
<FRAME NAME="page" SRC="page_de_garde.html"
MARGINWIDTH="10" MARGINHEIGTH="1">
<FRAME SCROLLING="no" NAME="bas_de_page"
SRC="bas_de_page.html">
</FRAMESET>
</FRAMESET>
<NOFRAMES>
Dommage, votre <EM>navigateur</EM> ne sait pas lire les
<EM>"frames"</EM> !.
</NOFRAME>
</HTML>
METHODE ET PROCEDURE
_______
REGLES ET RECOMMANDATIONS POUR
LA REALISATION D'UN SERVEUR WEB
SS.HTML.LienRelatif
RNC-CNES-E-40-505
Page 59
Version 2
13 mars 2000
Les liens internes au site doivent être définis de manière relative.
Description
Les liens hypertextes définis dans les pages HTML doivent faire référence à des URL relatives au
serveur, c’est à dire ne mentionnant pas le nom et le domaine de la machine hébergeant le serveur
Web.
Justification
Un navigateur Web interprète les liens relatifs en les faisant précéder de l’adresse de base du
serveur.
Au niveau du serveur, la gestion de liens relatifs allège la maintenance d’un site en permettant
notamment de pouvoir changer l’URL de base d’un serveur, ce qui permet à son tour de pouvoir
utiliser les mêmes pages sur les versions opérationnelle et de développement du site, voire même
sur une copie locale des fichiers HTML.
Exemple
Lien relatif :
<A HREF="/documents/bienvenue.html">
Lien absolu (A éviter) :
<A HREF="http://machine.du.domaine/documents/bienvenue.html">
METHODE ET PROCEDURE
_______
REGLES ET RECOMMANDATIONS POUR
LA REALISATION D'UN SERVEUR WEB
SS.HTML.Image
(Recom)
RNC-CNES-E-40-505
Page 60
Version 2
13 mars 2000
Les pages HTML doivent pouvoir être utilisées sans afficher les
images incorporées.
Description
Les pages HTML sont composées de texte et d’images. Les images doivent être utilisées dans un
but illustratif mais ne doivent pas être vitales pour la compréhension et la navigation. Une page
doit pouvoir être utilisée, c’est à dire être compréhensible et permettre les mêmes actions, que les
images incluses soient affichées ou non.
Il est possible de définir un texte alternatif à toute image incorporée qui est affiché si l’image n’est
pas chargée (paramètre ALT de l’adressage d’une image). Ce texte doit être utilisé pour décrire
brièvement l’image. De plus, afin de permettre au navigateur Web de positionner correctement les
autres éléments constituant la page, pendant le chargement de la page ou bien si les images ne
sont pas chargées, on peut indiquer la taille de l’image en pixels (paramètres HEIGHT et WIDTH
de la définition de l’adressage d’une image).
Enfin, si une image Map est utilisée (image et liens associés à des zones de l’image), des liens
textuels alternatifs doivent être proposés.
Une autre solution peut consister à proposer deux modes de navigation complémentaires, l’un
utilisant uniquement des informations textuelles, l’autre reposant sur l’utilisation d’images. Ceci
nécessite la création de deux structures parallèles pour le site Web.
Justification
L’affichage d’une page HTML contenant des images est en général réalisé par le navigateur Web
en affichant d’abord le texte de la page et le texte alternatif à la place des images. Si l’utilisateur a
configuré son navigateur Web dans ce sens, les images incluses sont ensuite chargées une à une.
Les utilisateurs connectés au serveur à l’aide d’une connexion à débit relativement faible seraient
pénalisés s’ils devaient attendre que toutes les informations soient chargées avant de pouvoir
comprendre et utiliser la page. De plus, certains de ces utilisateurs utilisent leur navigateur Web
en ne sélectionnant pas l’option d’affichage des images incluses.
Exemple
<IMG SRC="URL de l’image" ALT="Description de l’image" HEIGHT="20"
WIDTH="20">
Le tag « ALT » permet de définir le texte alternatif. Les tags HEIGHT et
WIDTH définissent la hauteur et la largeur de l’image.
METHODE ET PROCEDURE
_______
RNC-CNES-E-40-505
REGLES ET RECOMMANDATIONS POUR
LA REALISATION D'UN SERVEUR WEB
SS.HTML.ImageMap
Page 61
Version 2
13 mars 2000
Les images maps doivent être définies côté client plutôt que côté
serveur.
Description
Une image Map présentant une image utilisée pour représenter des liens de navigation doit être
définie au niveau du client plutôt qu’au niveau du serveur.
Justification
La navigation grâce à une image Map définie au niveau client est gérée par le navigateur. Les
images Map évitent ainsi une communication avec le serveur surtout depuis qu’elles sont
supportées par tous les navigateurs Web récents.
Il est de plus directement possible de voir, au niveau du navigateur, quelles zones de l’image sont
interactives et sur quelles destinations elles pointent.
Exemple
Une image Map côté client définit, en plus d’une image, des associations
entre des portions de celle-ci et des URL :
<img src="navigbar.gif" usemap="#imgmap" border=0 ismap>
<map name="imgmap">
<area shape="rect" coords="1,1,100,100" href="link1.htm">
<area shape="rect" coords="1,101,101,200" href="link2.htm">
<area shape="rect" coords="101,1,200,100" href="link3.htm">
<area shape="rect" coords="101,101,200,200" href="link4.htm">
</map>
METHODE ET PROCEDURE
_______
RNC-CNES-E-40-505
REGLES ET RECOMMANDATIONS POUR
LA REALISATION D'UN SERVEUR WEB
SS.HTML.EntêtePage
Page 62
Version 2
13 mars 2000
Les informations standards d’en-tête de page (tags TITLE et
META) doivent être définies.
Description
Le titre de toute page HTML statique ou générée, défini par le tag TITLE, doit être spécifique et
évocateur du contenu de la page.
De plus, certaines informations de l’entête de page (tag META) sont utilisées par des robots
d’indexation de serveurs ou par d’autres utilitaires. Il est donc nécessaire de les renseigner. En
particulier on renseignera :
• META HTTP-EQUIV="Expires" avec la date d’expiration de l’information contenue dans
la page
• META NAME="keywords" avec une liste de mots-clés sur la page
• META NAME="description" avec une description courte de la page
• META NAME="author" avec le nom de l’auteur
Dans la mesure du possible, les contenus des champs « TITLE » et « H1 » (titre affiché) doivent
être identiques (cf. CR.Structure.Titrage).
Justification
C’est le titre de la page qui est utilisé automatiquement par les navigateurs Web lorsque la
référence à la page est stockée (en tant que signet). C’est également ce nom qui est utilisé dans
l’historique des pages parcourues. Ce nom doit pouvoir permettre une identification immédiate de
la nature de la page par l’utilisateur.
De plus, pour qu’un site soit consulté, il est utile de l’indexer dans les bases d’indexation des sites
Web de la manière la plus appropriée. Ainsi, lister les mots-clés d’une page peut-être plus efficace
que de laisser le robot d’indexation se baser sur le contenu de la page.
Exemple
Titre logique
<HEAD>
⇓
<TITLE>CNES - Liste des sites</TITLE>
<META HTTP-EQUIV="Expires"
CONTENT="25-Dec-1998 12:00:00 GMT">
<META NAME="keywords" CONTENT="web development">
<META NAME="description" CONTENT="Liste des sites du CNES">
</HEAD>
Titre affiché
<BODY>
⇓
<H1> CNES - Liste des sites</H1>
...
METHODE ET PROCEDURE
_______
REGLES ET RECOMMANDATIONS POUR
LA REALISATION D'UN SERVEUR WEB
SS.HTML.NomURL
RNC-CNES-E-40-505
Page 63
Version 2
13 mars 2000
Les noms et formats d’URL doivent être homogènes et contrôlés.
Description
Les noms et formats des URL doivent être homogènes dans l’ensemble du serveur. En particulier
on veillera à :
• l’utilisation de caractères minuscules dans les URL
• ne pas utiliser de caractères spéciaux (caractères accentués...)
• l’utilisation de séparateurs / ou \
• aux suffixes des documents (htm ou html)
Justification
Certains éléments du nommage des URL sont liés à la plate-forme matérielle et système. Ainsi,
dans un souci d’homogénéité et afin de rendre une migration vers une autre plate-forme plus
aisée, les dépendances vers la plate-forme doivent être minimisées, et tout du moins clairement
identifiées.
Exemple
Sans objet
METHODE ET PROCEDURE
_______
REGLES ET RECOMMANDATIONS POUR
LA REALISATION D'UN SERVEUR WEB
SS.Performance.Volume
RNC-CNES-E-40-505
Page 64
Version 2
13 mars 2000
Le volume de transfert doit être limité afin d’augmenter les
performances apparentes du serveur.
Description
Avec HTTP, chaque image ou élément incorporé dans une page HTML provoque l’ouverture
d’une connexion TCP/IP. Il est donc recommandé de n’incorporer dans une page que le nombre
d’éléments strictement nécessaires à la fonction de la page. Il n’est cependant pas possible de fixer
une limite chiffrée étant donné la large variété des fonctions d’une page.
Cette règle est à moduler en fonction des contraintes techniques des utilisateurs ciblés (Intranet,
serveur externe, ...).
Justification
Le débit du réseau est un facteur limitant de la plupart des serveurs. On peut contourner cette
limitation en surveillant la taille des fichiers transférés.
Le volume de transfert d’une connexion HTTP est directement lié à la performance apparente du
serveur et doit donc être le plus faible possible. Les pages doivent donc être conçues pour ne pas
nécessiter le téléchargement d’informations trop volumineuses (la page elle-même et les éléments
incorporés).
Exemple
On peut limiter le volume d’une page trop grosse en la découpant en
pages plus petites. On peut également afficher des imagettes à la place
d’images complètes, ces imagettes pointant vers les images complètes.
A titre d’illustration, le tableau suivant donne des exemples de temps
de transfert en fonction de la bande passante de la connexion et de la
taille des informations chargées :
Modem
14.4K
Liaison
56K
Liaison
128K
Fichier de 10Ko
5,7s
1,4s
0,6s
Fichier de 25Ko
14,2s
3,6s
1,6s
Fichier de 50Ko
28,4s
7,1s
3,1s
Fichier de 100Ko
56,9s
14,3s
6,3s
Fichier de 500Ko
4,7min
71,4s
31,3s
Fichier de 2Mo
19,4min
4,8min
2,1min
METHODE ET PROCEDURE
_______
REGLES ET RECOMMANDATIONS POUR
LA REALISATION D'UN SERVEUR WEB
SS.HTML.LgTable (Recom)
RNC-CNES-E-40-505
Page 65
Version 2
13 mars 2000
L’utilisation de tables HTML longues doit être évitée.
Description
Il faut éviter :
• les tables contenant des informations de taille importante,
• les tables avec beaucoup de lignes (ce qui risque d’arriver, en l’absence de protection, dans des
pages HTML générées dynamiquement par interrogation de base de données),
• les tables contenant des tables en cascades excessives,
• les tables dont certaines cases contiennent des images incorporées sans indication de
dimensions (WIDTH et HEIGHT),
• ...
Justification
Les navigateurs Web se basent sur le contenu d’une table pour en définir la taille ainsi que celle
de ses constituants. Il faut donc attendre que toutes les informations aient été téléchargées avant
de voir le moindre affichage de la table.
En comparaison, les informations autres que les tables sont visualisées au fur et à mesure de leur
téléchargement. Ceci permet à un utilisateur de commencer à exploiter l’information avant son
chargement complet.
Exemple
Pour un serveur externe (Modem 14.4K), une simple table HTML de 10Ko met
5 a 6 secondes pour se charger et donc pour apparaître. Pendant ce
temps, il ne se passe rien et l’utilisateur peut être dérouté.
METHODE ET PROCEDURE
_______
REGLES ET RECOMMANDATIONS POUR
LA REALISATION D'UN SERVEUR WEB
SS.Réalisation.Script (Recom)
RNC-CNES-E-40-505
Page 66
Version 2
13 mars 2000
Le langage à utiliser pour les scripts client est le langage
Javascript.
Description
Lorsque des scripts client sont utilisés à l’intérieur d’une page HTML, on préférera le langage
Javascript, plus communément reconnu et interprété par les navigateurs Web.
Etant donné les légères modifications d’interprétation du langage Javascript d’un navigateur Web
à l’autre, il est cependant nécessaire de tester les pages et les scripts sur tous les navigateurs Web
ciblés.
Justification
Il est nécessaire de s’assurer que les pages Web sont lisibles et que les mécanismes associés sont
utilisables par les différentes plates-formes cibles. Le langage de script utilisé dans les pages
HTML et interprété par les navigateurs Web est un de ces mécanismes.
Il existe deux langages de script répandus qui sont JavaScript et VBScript. La recommandation de
JavaScript (quand l’utilité d’un script est démontrée pour la fonction d’une page) s’explique par
les raisons suivantes :
• le langage Javascript et sa normalisation en font le langage de script client le plus largement
reconnu,
• le langage VBScript n’est reconnu que par le navigateur de Microsoft,
• le langage VBScript incite fortement à utiliser des fonctions propriétaires Active Server Pages
de Microsoft, limitant la portabilité du serveur,
• le langage VBScript incite fortement à utiliser des extensions ActiveX propriétaires et
uniquement sur processeurs Intel (en septembre 1997), limitant la portabilité de la plate-forme
cliente.
Exemple
Sans objet.
METHODE ET PROCEDURE
_______
REGLES ET RECOMMANDATIONS POUR
LA REALISATION D'UN SERVEUR WEB
SS.Réalisation.Cookies
RNC-CNES-E-40-505
Page 67
Version 2
13 mars 2000
Si des cookies sont utilisés par un serveur Web, ils doivent être
déclarés avec une date d’expiration et leur domaine de visibilité
doit être local au serveur.
Description
Si le mécanisme de cookies est utilisé par un site Web, les dispositions suivantes seront prises :
• le lien sur la page appelant le cookie expliquera au visiteur potentiel pourquoi un cookie est
utilisé,
• la date d’expiration du cookie doit être positionnée en fonction de la durée de validité de
l’information. En particulier, on veillera à déclarer comme temporaires à la durée de
l’exécution du navigateur les cookies véhiculant de l’information propre à la session Web.
Ceci est particulièrement important si les cookies sont utilisés pour stocker des informations
confidentielles,
• le domaine de visibilité d’un cookie doit être restreint au domaine du serveur Web qui le crée
et le maintient.
Justification
Le mécanisme de cookies a été inventé par Netscape pour contourner l’absence de rémanence
d’informations d’un appel HTTP à un autre et permettre ainsi au serveur d’un site de mémoriser
l’historique d’un parcours de visiteur en vue de :
• interroger plusieurs fois une base de données sans répéter les opérations de mise en place de
contexte,
• décompter les choix d’articles le long d’un parcours pour effectuer en une seule fois une
opération globale (traitement, facturation, envoi).
Ce mécanisme consiste, pour le serveur Web, à envoyer une identification spécifique au serveur
(un cookie) qui est mémorisée par le client navigateur sur son disque dur.
Ceci permet à un serveur Web (à l’origine du cookie ou tout autre serveur) de récupérer
automatiquement ces informations lorsqu’il est accédé par un navigateur Web, et a priori, par
l’utilisateur du poste de travail sur lequel le navigateur Web s’exécute.
Afin d’éviter l’utilisation de ces informations à des fins illicites, celles-ci doivent être temporaires
(elles sont détruites à la fin d’exécution du navigateur Web) ou permanentes (stockées sur disque)
mais avec une durée de validité et n’être visibles que par le serveur Web qui les a créées.
Exemple
Les cookies sont propres à un poste client, celui-ci pouvant être
partagé par plusieurs utilisateurs. Ainsi tous les utilisateurs
exécutant un navigateur Web sur un poste partagé peuvent partager le
même cookie et donc les mêmes informations confidentielles. Il est donc
nécessaire de détruire le cookie dès que l’utilisateur quitte le
navigateur Web ou à la demande de l’utilisateur, dès que celui-ci veut
se "déconnecter".
METHODE ET PROCEDURE
_______
RNC-CNES-E-40-505
REGLES ET RECOMMANDATIONS POUR
LA REALISATION D'UN SERVEUR WEB
Page 68
Version 2
13 mars 2000
Un cookie est déclaré comme temporaire par le serveur le créant en ne
mentionnant pas de date d’expiration. Il faut de plus prévenir
l’utilisateur de la procédure à suivre pour que ces informations soient
effectivement détruites (comme par exemple, en quittant le navigateur
Web, ou bien en exécutant une action informant le serveur Web de
détruire les informations contenues dans le cookie
La spécification complète du mécanisme de cookie est sur :
http://www.internic.net/rfc/rfc2109.txt
METHODE ET PROCEDURE
_______
RNC-CNES-E-40-505
REGLES ET RECOMMANDATIONS POUR
LA REALISATION D'UN SERVEUR WEB
SS.Réalisation.ChampCaché
Page 69
Version 2
13 mars 2000
Les champs cachés des formulaires HTML ne doivent pas
contenir d’informations confidentielles.
Description
Les champs cachés dans les formulaires ne doivent pas être utilisés pour stocker des informations
qui ne doivent pas être consultées par un utilisateur.
Justification
La valeur de champs cachés dans un formulaire n’est pas affichée avec la page HTML mais peut
être facilement consultée en visualisant le code source de cette page.
Exemple
La valeur d’un champ caché peut facilement être consultée par un
utilisateur visualisant le source d’une page HTML :
<INPUT TYPE="HIDDEN" NAME="CODE_CARTE_BLEUE" VALUE="1234">
SS.Réalisation.Validation
Un serveur Web doit être validé à chaque livraison.
Description
Lors de chaque livraison, une phase de validation doit être effectuée.
Il s’agit comme pour un projet classique de jouer les scénarios de test créés lors de la phase de
spécification.
La seule particularité du Web est qu’il faut effectuer une revue complète des liens internes au
serveur.
Cette phase de validation doit être également effectuée lors de la livraison des différentes versions
de prototype, en cohérence avec les objectifs définis pour chacune des versions.
Justification
Suite à une modification de la structure du site ou à cause une erreur dans l’écriture d’un lien, les
liens internes peuvent devenir invalides.
Exemple
Il existe bon nombre d’outils automatisant la vérification de cohérence
des liens entre pages d’un site ainsi que vers les pages externes à un
site. Il est conseillé de se référer aux listes établies sur des sites
tels que :
•
Le World Wide Web Consortium (www.w3c.org) qui liste des outils
relatifs au langage HTML, dont des outils de vérification de liens.
•
Les moteurs d’indexation des sites Internet (cf. SS.HTML.Norme)
METHODE ET PROCEDURE
_______
RNC-CNES-E-40-505
REGLES ET RECOMMANDATIONS POUR
LA REALISATION D'UN SERVEUR WEB
SS.Structure.Répertoire
(Recom)
Page 70
Version 2
13 mars 2000
Il ne faut donner accès au listing d’un répertoire que si cela
correspond à un réel besoin.
Description
Le serveur Web doit être configuré pour que le contenu des répertoires contenant les fichiers
HTML et les autres documents ne soit pas directement consultable.
Il est nécessaire de créer une page spécifique listant les documents pour chaque répertoire
contenant des documents téléchargeables.
Utiliser dans la mesure du possible les fichiers index.html et welcome.html qui, sur certains
serveurs Web, donnent accès par défaut au contenu d’un répertoire.
Justification
Les serveurs Web statiques présentaient originellement essentiellement des informations statiques
qui étaient structurées à l’aide de répertoires. Certains serveurs Web proposent donc par défaut
d’afficher le contenu d’un répertoire en réponse à une requête qui peut se traduire en nom de
répertoire sur le serveur.
Par exemple, une URL telle que http://xxx.yyy/documents/procedure.doc peut être détournée par
un utilisateur en http://xxx.yyy/documents/ , qui résulterait en l’affichage du contenu du répertoire.
Cet affichage pourrait permettre un accès aisé à des documents non référencés dans les pages du
serveur et qui auraient dû être supprimés.
La création d’une page spécifique permet de plus de proposer un format de page respectant les
standards définis pour le site plutôt que de reposer sur les mécanismes internes du serveur Web.
Exemple
Sur le serveur Enterprise Server 3 de Netscape, le fichier de
configuration obf.conf du serveur doit contenir la directive suivante
pour retourner un message d’erreur "Not Found" en réponse à une requête
(URL) qui aurait dû résulter en l’affichage du contenu d’un répertoire :
Service fn="deny-existence" method="(GET|HEAD)" type="magnusinternal/directory"
Avec le serveur httpd du CERN, ajouter dans le fichier de configuration
du serveur la directive :
DirAccess On
pour autoriser l’accès direct au contenu des répertoires
DirAccess Off
pour interdire l’accès direct au contenu des répertoires
ou
DirAccess Selective
pour autoriser l’accès direct au contenu des seuls répertoires contenant
un fichier nommé .www_browsable
Avec le serveur Apache, on peut utiliser la directive suivante dans le
fichier de configuration pour ne pas autoriser l’accès direct au contenu
des répertoires :
METHODE ET PROCEDURE
_______
RNC-CNES-E-40-505
REGLES ET RECOMMANDATIONS POUR
LA REALISATION D'UN SERVEUR WEB
Page 71
Version 2
13 mars 2000
Options Indexes None
SS.Structure.Image
Une image utilisée dans plusieurs pages ne doit pas être dupliquée
au niveau du serveur.
Description
Les images et autres éléments inclus dans différentes pages Web doivent partager la même
représentation physique et ne doivent pas être dupliqués sur le serveur.
Les éléments susceptibles de mise en commun sont :
• les images, logos et éléments décoratifs d’habillement des pages,
• les éléments de texte inclus comme les en-têtes et pieds de page,
• les applets.
Justification
Les navigateurs stockent dans un cache les éléments accédés au cours des dernières navigations.
L’accès à un élément déjà stocké dans le cache est beaucoup plus rapide que son téléchargement.
Or, le stockage et la recherche d’éventuels éléments contenus dans le cache reposent sur leur
URL. Il est donc nécessaire de ne pas dupliquer l’information pour profiter au mieux des
informations contenues dans le cache.
La non-duplication simplifie aussi la maintenance :
• un schéma d’architecture peut évoluer, sa duplication obligerait à tracer tous les exemplaires,
• un texte inclus d’en-tête ou de pied de page peut contenir des liens, qui peuvent changer, leur
duplication obligerait à tracer les localisations à changer,
• ...
Exemple
La barre de séparation « barre_sep1.gif » ne doit être que dans
../Image/Bouton.
Le logo « Spot4.gif » ne doit être que dans ../Image/Logo.
METHODE ET PROCEDURE
_______
REGLES ET RECOMMANDATIONS POUR
LA REALISATION D'UN SERVEUR WEB
SS.Structure.Page
RNC-CNES-E-40-505
Page 72
Version 2
13 mars 2000
Les informations doivent être organisées dans une arborescence
de répertoires au niveau du serveur.
Description
Les pages, les éléments inclus ainsi que les scripts ou programmes appelés par le serveur doivent
être stockés dans des répertoires différents, en fonction de leur type.
De plus, la structure des répertoires doit correspondre à l’arborescence générale de navigation et
respecter les exigences énoncées dans le document « Exigences de sécurité pour l’utilisation des
serveurs et relais HTTP » (DR5).
Justification
Cette règle est nécessaire dans un but de meilleure maintenabilité ainsi que dans un but de
meilleure sécurité. En effet, l’accès à des scripts ayant une interaction avec des systèmes
d’information peut ainsi plus facilement être sécurisé.
Exemple
Un exemple de structure de site préconisée par le document « Cahier de
recette du serveur HTTP Unix du CERN: » (DR6).
• admin
• bin
• config
• dev
• etc
• logs
• cgi-bin
• administration
• consultation
• public
• prive
• serveur_files
• administration
• consultation
• public
• prive
• usr
• var
METHODE ET PROCEDURE
_______
REGLES ET RECOMMANDATIONS POUR
LA REALISATION D'UN SERVEUR WEB
SS.Outil.Recherche
RNC-CNES-E-40-505
Page 73
Version 2
13 mars 2000
Si un outil de recherche est utilisé, son utilisation doit être
précisée.
Description
La définition d'un outil de recherche est faite à travers le choix d'un moteur d’indexation. Celui-ci
permet d'effectuer des recherches sur le contenu du site au moyen de mots-clés. Un formulaire est
établi pour saisir le ou les mots-clés et éventuellement des options de recherche, puis lancer
l'exécution de la recherche.
Justification
L'utilisation d'un outil de recherche permet à l’utilisateur d'avoir un accès direct et personnalisé à
l’information..
Exemple
Le site doit être indexé au moyen du moteur d'indexation Fulcrum.
METHODE ET PROCEDURE
_______
REGLES ET RECOMMANDATIONS POUR
LA REALISATION D'UN SERVEUR WEB
RNC-CNES-E-40-505
Page 74
Version 2
13 mars 2000
10.4 REGLES APPLICABLES EN PHASE DE MAINTENANCE
SS.Maintenance.FichierTrace
Les procédures d’exploitation des fichiers de trace des accès au
serveur doivent être formalisées.
Description
Les fichiers de trace des accès au serveur et des erreurs retournées par le serveur doivent être
exploités selon des procédures formalisées dans un document d’exploitation du serveur, en
conformité avec les exigences énoncées dans la règle SS.Spécification.FichierTrace.
De plus, les procédures d’exploitation des fichiers de trace doivent respecter les exigences
énoncées dans le document « Exigences de sécurité pour l’utilisation des serveurs et relais
HTTP » (DR5).
Justification
L’exploitation des fichiers de trace (logs) constitue un élément essentiel permettant de garantir
une bonne utilisabilité du serveur et de se prémunir contre les accès frauduleux. Il est donc
important que les procédures d’exploitation soient formalisées et acceptées par tous les acteurs
(administrateur du serveur Web, administrateur de la machine hébergeant le serveur, responsable
sécurité).
Exemple
Il existe de nombreux outils d’analyse des logs générés par les serveurs
Web. Il est conseillé de se référer aux listes établies sur des sites
tels que :
• Le World Wide Web Consortium (www.w3c.org) qui liste des outils
relatifs au Web, dont des outils d’analyse de logs.
• Les moteurs d’indexation des sites Internet, et notamment ceux
classifiant les sites en fonction de catégories, tels que Yahoo
(www.yahoo.com), et en recherchant la rubrique correspondant aux
outils d’analyse de fichiers de log (par exemple la catégorie Top /
Computers and Internet / Software:Internet / World Wide Web / Servers
/ Log Analysis Tools)
Les procédures d'exploitation contenues dans le produit IW3 permettent
entre autre l'exploitation des fichiers logs au travers d'une interface
WWW.
METHODE ET PROCEDURE
_______
RNC-CNES-E-40-505
REGLES ET RECOMMANDATIONS POUR
LA REALISATION D'UN SERVEUR WEB
SS.Maintenance.Version
(Recom)
Page 75
Version 2
13 mars 2000
La date de dernière modification des pages doit être mise à jour.
Description
La date de dernière modification d’une page statique ou des informations présentées dans une
page générée dynamiquement doit être mise à jour.
Justification
La procédure de mise à jour de ces dates doit être définie dans le manuel d’exploitation du site.
Exemple
Sans objet
SS.Maintenance.Cohérence
La cohérence des liens externes doit être vérifiée.
Description
Les liens externes au serveur doivent être vérifiés régulièrement et la procédure de vérification
doit être formalisée dans le document d’exploitation du serveur. La vérification de la cohérence
doit porter sur l’existence des liens, et le maintien de leur pertinence.
Justification
Un utilisateur peut être dérouté ou tout du moins son appréciation sur la qualité du site peut être
diminuée si le site paraît mal maintenu et contrôlé. Il est donc nécessaire d’éviter les pages
d’erreur résultant de la non-disponibilité d’une page pointée par un lien.
Ainsi, les liens externes au serveur sont susceptibles de pointer sur des documents qui peuvent
évoluer et ne plus être disponibles ou valides. Il faut donc les vérifier régulièrement.
Exemple
Il existe de nombreux outils automatisant la vérification de cohérence
des liens vers les pages externes à un site. Il est conseillé de se
référer aux listes établies sur des sites tels que décrits dans
HTML(SS.HTML.LienRelatif).
METHODE ET PROCEDURE
_______
REGLES ET RECOMMANDATIONS POUR
LA REALISATION D'UN SERVEUR WEB
11. RÈGLES
APPLICABLES AUX SERVEURS
WEB
RNC-CNES-E-40-505
Page 76
Version 2
13 mars 2000
DYNAMIQUES
Outre les règles applicables aux serveurs statiques, les règles spécifiques aux serveurs dynamiques sont
présentées en fonction du cycle de vie.
11.1 REGLES GENERALES
SD.Sécurité.Unix
Si le serveur et les développements associés résident sur une plateforme de type UNIX, les exigences du document "Règles de
sécurité pour les développements sous UNIX " (DR6) doivent être
appliquées.
Description
Les règles générales de sécurité telles que décrites dans (DR6) doivent être appliquées sur un
projet de construction de serveur Web dynamique.
Justification
Un serveur Web constitue un développement à part entière, les règles de sécurité associées
doivent être strictement respectées.
Exemple
Sans objet.
METHODE ET PROCEDURE
_______
REGLES ET RECOMMANDATIONS POUR
LA REALISATION D'UN SERVEUR WEB
RNC-CNES-E-40-505
Page 77
Version 2
13 mars 2000
Le développement d’un serveur Web dynamique doit suivre un
cycle de vie adapté aux technologies Web, avec les moyens de
gestion associés et tous les niveaux de tests doivent être réalisés.
SD.Processus
Description
En complément des règles SS.Processus.Développement et SS.Processus.Tests applicables aux
serveurs statiques et dynamiques, il est nécessaire de préciser pour les serveurs dynamiques :
• les programmes CGI doivent être gérés en configuration,
• les tests unitaires et d’intégration de chaque CGI doivent être réalisés ainsi que
l’intégration des composants pour la partie applicative.
Justification
Sans objet
Exemple
Sans objet
SD.Processus.Prototype
(Recom)
La démarche de développement préconisée pour les CGI est le
prototypage.
Description
La démarche de développement préconisée pour les CGI s’apparente au RAD (Rapid Access
Developpent ). Elle consiste en une phase de prototypages successifs (trois versions maximum)
puis une phase de réalisation faisant évoluer le dernier prototype vers le produit final.
Les objectifs de chaque version du prototype doivent être définis clairement vis à vis des
spécifications du serveur et validés lors de sa livraison.
La validation devra identifier le niveau d’application des évolutions (évolutions de niveau
conception ou de niveau spécification).
Justification
Cette phase de prototypage permet de valider les solutions préconisées et éventuellement d’affiner
le besoin technique.
Exemple
Sans objet.
METHODE ET PROCEDURE
_______
REGLES ET RECOMMANDATIONS POUR
LA REALISATION D'UN SERVEUR WEB
RNC-CNES-E-40-505
Page 78
Version 2
13 mars 2000
11.2 REGLES APPLICABLES EN PHASE DE SPECIFICATION
SD.Spécification.Méthode
&CGI (Recom)
Pour le développement de la partie applicative (CGI), il est
conseillé d’utiliser une méthode de spécification.
Description
Pour la partie applicative (CGI), il est souhaitable lors de la spécification du serveur Web
d’utiliser (comme pour un développement classique) une méthode de spécification.
Justification
Le développement d’un serveur Web s’apparente au développement d’une application, et à ce
titre, les choix de spécification doivent être documentés.
La méthode OMT est la méthode orientée objet préconisée par le CNES, pour ce qui concerne la
phase d’analyse. Elle est particulièrement adaptée pour les applications de type client/serveur et
doit être utilisée en respectant les les Règles et recommandations pour l’utilisation de la méthode
OMT (DR2).
L’utilisation d’un outil support de la méthode OMT permet de faciliter sa mise en oeuvre.
Exemple
La spécification du projet SIPAD (Système d’Information, de Préservation
et d’Accès aux Données) du Centre de Données de la Physique des Plasmas
(CDPP) a été réalisée en appliquant la méthode OMT avec l’outil
ObjectPartner disponible sur la plate-forme de la division Qualité
Logiciel.
METHODE ET PROCEDURE
_______
REGLES ET RECOMMANDATIONS POUR
LA REALISATION D'UN SERVEUR WEB
RNC-CNES-E-40-505
Page 79
Version 2
13 mars 2000
11.3 REGLES APPLICABLES EN PHASE DE CONCEPTION ET DE REALISATION
SD.Conception.Méthode&CGI
(Recom)
Il est recommandé d’utiliser une méthode de conception pour le
développement de la partie applicative (CGI).
Description
Pour la partie applicative (CGI), il est souhaitable lors de la conception du serveur Web d’utiliser
une méthode de conception.
Justification
Le développement d’un serveur Web s’apparente au développement d’une application, et à ce
titre, les choix de conception doivent être documentés.
La méthode OMT est une des méthodes orientées objet préconisées par le CNES, pour ce qui
concerne la phase de conception. Elle est particulièrement adaptée pour les applications de type
client/serveur et doit être utilisée en respectant les Règles et recommandations pour l’utilisation
de la méthode OMT(DR2).
L’utilisation d’un outil support de la méthode OMT permet de faciliter sa mise en oeuvre et
éventuellement de générer le code.
Exemple
La conception préliminaire du projet
Préservation et d’Accès aux Données)
des Plasmas (CDPP) a été réalisée en
l’outil ObjectPartner disponible sur
Qualité Logiciel.
SD.Conception.IHM&CGI
SIPAD (Système d’Information, de
du Centre de Données de la Physique
appliquant la méthode OMT avec
la plate-forme de la division
Il faut, lors de la conception, séparer la partie IHM (HTML) de la
partie traitement.
Description
Comme pour un développement classique, il est souhaitable de bien séparer la partie IHM (ici
HTML) de la partie traitement proprement dit.
En particulier, les CGI générant dynamiquement des pages HTML doivent s’appuyer sur des
modèles.
Justification
Pour les évolutions et la maintenance, il est souvent très dommageable qu’une modification
« minime » de l’IHM entraîne une modification des traitements.
Exemple
L’utilisation de modèles de pages, d’une manière similaire aux serveurs
Web dynamiques interprétés est un moyen de parvenir à une meilleure
isolation entre la partie HTML et les traitements.
METHODE ET PROCEDURE
_______
REGLES ET RECOMMANDATIONS POUR
LA REALISATION D'UN SERVEUR WEB
SD.Conception.Saisies
RNC-CNES-E-40-505
Page 80
Version 2
13 mars 2000
Le serveur Web doit prévenir des modifications ou saisies
abusives de champs cachés ou à choix restreint d’un formulaire
HTML.
Description
Tout champ d’un formulaire HTML non modifiable (caché), ou à choix restreint (parmi une liste)
doit être contrôlé par le programme, au niveau du serveur Web, traitant le résultat du formulaire.
Justification
La valeur de tout champ d’un formulaire HTML, même non modifiable (caché), ou à choix
restreint (parmi une liste) peut être abusivement forcée à une valeur et retournée au serveur. Le
serveur doit donc s’assurer que les valeurs retournées sont valides.
Exemple
On doit tester que les valeurs saisies dans les champs sont des valeurs
valides, qui plus est, autorisées pour l’utilisateur.
SD.Conception.ScriptClient
Les scripts client ne doivent pas être utilisés pour décider de
l’affichage ou pas d’informations confidentielles.
Description
Un script client, s’exécutant au niveau du navigateur Web, ne doit pas être utilisé pour afficher ou
pas de l’information confidentielle. De tels contrôles doivent être réalisés au niveau du serveur.
Justification
Un utilisateur averti peut modifier une page HTML et les scripts clients inclus. Il ne faut donc pas
que cette page contiennent des informations confidentielles.
Exemple
Une telle portion de code :
<script language="JavaScript">
if (uid == 1)
document.writeln( "Welcome super user,<BR>");
</script>
peut facilement être modifiée par un utilisateur et être exécutée pour
détourner certains tests :
<script language="JavaScript">
document.writeln( "Welcome super user,<BR>");
</script>
METHODE ET PROCEDURE
_______
REGLES ET RECOMMANDATIONS POUR
LA REALISATION D'UN SERVEUR WEB
SD.Conception.UtilScript
RNC-CNES-E-40-505
Page 81
Version 2
13 mars 2000
L’identité d’un utilisateur d’un script ou programme à accès
restreint doit être vérifiée en début d’exécution.
Description
Par mesure de sécurité, il est recommandé de tester le bon fonctionnement du mécanisme
d’authentification en tête des scripts ou programmes nécessitant l’authentification de l’utilisateur.
Justification
Les mécanismes d’authentification des serveurs sont robustes, mais une erreur de configuration de
la sécurité est possible. La mesure décrite ici permet de renforcer les contrôles de sécurité.
Exemple
Par exemple, on peut, en utilisant le langage Perl, vérifier si un
script est bien exécuté au nom d’un utilisateur :
if ( $ENV{REMOTE_USER} ) {
...
} else {
# Erreur, pas de nom d’utilisateur, donc prévenir l’administrateur
# car problème d’authentification
}
La méthode proposée ci-dessus n’est cependant pas une garantie que
l’utilisateur s’est authentifié, mais elle permet d’effectuer un
contrôle simple et permet de prévenir l’administrateur du site d’un
problème du mécanisme d’authentification.
METHODE ET PROCEDURE
_______
REGLES ET RECOMMANDATIONS POUR
LA REALISATION D'UN SERVEUR WEB
SD.Conception.InfoConfident
RNC-CNES-E-40-505
Page 82
Version 2
13 mars 2000
Des paramètres transmis à l’intérieur d’une URL ne doivent pas
contenir d’informations confidentielles et doivent être testés par le
programme les utilisant.
Description
Les paramètres décrits dans une URL sont directement accessibles à un utilisateur et facilement
modifiables.
La modification de valeurs de tels paramètres ne doit pas porter atteinte à la sécurité. Elle ne doit
notamment pas permettre à un utilisateur d’accéder à des fonctions qui ne lui sont pas permises.
Les scripts et programmes doivent de plus être suffisamment robustes pour détecter les valeurs
erronées.
Il est de plus préconisé d’utiliser la méthode POST pour la soumission de formulaires pour éviter
que l’utilisateur ait un accès aisé aux informations et puisse les modifier facilement.
Justification
Les paramètres transmis dans une URL sont visibles et peuvent être modifiés par un utilisateur,
surtout si leur fonction est facilement interprétable. La fonction d’un script peut alors être
détournée.
La modification de valeurs de tels paramètres ne doit pas porter atteinte à la sécurité. Elle ne doit
notamment pas permettre à un utilisateur d’accéder à des fonctions qui ne lui sont pas permises.
Les scripts serveurs et programmes doivent de plus être suffisamment robustes pour détecter les
valeurs erronées.
La transmission d’un formulaire utilise deux méthodes :
• <FORM METHOD="GET" ACTION="/cgi-bin/(exécutable quelconque)"> envoie les
paramètres en clair, concaténés derrière l’URL de l’exécutable CGI qui sera appelé,
• <FORM METHOD="POST" ACTION="/cgi-bin/(exécutable quelconque)"> envoie les
paramètres par un fichier séparé qui est mis dans le fichier d’entrée standard stdin de
l’exécutable CGI qui sera appelé,
L’emploi de POST cache un peu plus les paramètres mais au prix d’une connexion
supplémentaire qui peut être préjudiciable aux performances
Exemple
Une URL contenant en paramètre des informations confidentielles peut
être facilement détournée :
http://site.domaine/cgi-bin/exec.cgi?command=list&user=staff
définissant les paramètres command et user peut être réécrite :
http://site.domaine/cgi-bin/exec.cgi?command=list&user=root
METHODE ET PROCEDURE
_______
REGLES ET RECOMMANDATIONS POUR
LA REALISATION D'UN SERVEUR WEB
SD.Réalisation.CGI
(Recom)
RNC-CNES-E-40-505
Page 83
Version 2
13 mars 2000
Le langage préconisé pour les CGI est le « C sécurisé ».
Description
Le langage préconisé pour le codage des CGI est le « C sécurisé » en conformité avec les Règles
de sécurité pour les développements sous UNIX . (DR6). Les Règles et recommandations pour
l’utilisation du langage C (DR8) doivent être appliquées.
Pour les serveurs non ouverts à l’extérieur, il est possible d’utiliser le Perl V5.03 ou plus, ou Java.
Si le langage Java est utilisé, les règles applicables aux applications standalone du document
Règles et recommandations pour l’utilisation du langage Java(DR3) doivent être appliquées.
Justification
Le langage « C sécurisé » offre toutes les garanties sur le respect des contraintes de sécurité.
Le langage interprété Perl est très adapté aux manipulations de texte.
Le langage Java est un langage orienté objet bien adapté au codage d’applications conçues avec
une méthode orientée objet (cf. règle SD.Conception.Méthode&CGI) et présentant un certain
nombre de garanties sur le respect des contraintes de sécurité.
Exemple
Sans objet.
METHODE ET PROCEDURE
_______
REGLES ET RECOMMANDATIONS POUR
LA REALISATION D'UN SERVEUR WEB
RNC-CNES-E-40-505
Page 84
Version 2
13 mars 2000
11.4 REGLES APPLICABLES EN PHASE DE MAINTENANCE
Les serveurs Web dynamiques n’induisent pas de règles supplémentaires par rapport aux serveurs
Web statiques.
METHODE ET PROCEDURE
_______
REGLES ET RECOMMANDATIONS POUR
LA REALISATION D'UN SERVEUR WEB
12. RÈGLES
APPLICABLES AUX SERVEURS
WEB
RNC-CNES-E-40-505
Page 85
Version 2
13 mars 2000
ÉTENDUS
Les serveurs Web de type étendu héritent des caractéristiques des serveurs dynamiques en se
rapprochant beaucoup plus des logiciels client - serveur classiques. De ce fait, les règles applicables sont
celles des serveurs dynamiques mais aussi celles d’un développement classique.
Certaines de ces règles doivent cependant être précisées.
Le développement d’un serveur Web étendu doit suivre un cycle
de vie adapté aux technologies Web, avec les moyens de gestion
associés et tous les niveaux de tests doivent être réalisés.
SE.Processus
Description
En complément de la règle SD.Processus applicable aux serveurs dynamiques, il est nécessaire de
préciser pour les serveurs étendus :
• les applets doivent être gérés en configuration,
• les tests unitaires et d’intégration de chaque applet doivent être réalisés ainsi que
l’intégration des composants pour la partie applicative.
Justification
Sans objet
Exemple
Sans objet
METHODE ET PROCEDURE
_______
REGLES ET RECOMMANDATIONS POUR
LA REALISATION D'UN SERVEUR WEB
SE.Spécification.Méthode&Ap
plet
RNC-CNES-E-40-505
Page 86
Version 2
13 mars 2000
Pour le développement de la partie applicative exécutée sur le
client (applet), une méthode de spécification doit être utilisée.
Description
Il est indispensable lors de la spécification de la partie applicative d’un serveur Web étendu
exécutée sur le client (applet) d’utiliser une méthode orientée objet.
Justification
Le développement de la partie applicative d’un serveur Web étendu exécutée sur le client (applet)
s’apparente au développement d’une application orientée objet, et à ce titre, la méthode de
spécification utilisée doit être orientée objet.
La méthode OMT est la méthode orientée objet préconisée par le CNES, pour ce qui concerne la
phase d’analyse. Elle est particulièrement adaptée pour les applications de type client/serveur et
doit être utilisée en respectant les Règles et recommandations pour l’utilisation de la méthode
OMT(DR2)..
L’utilisation d’un outil support de la méthode OMT permet de faciliter sa mise en oeuvre.
Exemple
Sans objet.
METHODE ET PROCEDURE
_______
REGLES ET RECOMMANDATIONS POUR
LA REALISATION D'UN SERVEUR WEB
RNC-CNES-E-40-505
Page 87
Version 2
13 mars 2000
SE.Conception.Méthode&Appl Pour le développement de la partie applicative exécutée sur le
client (applet), une méthode de conception doit être utilisée.
et
Description
Il est indispensable lors de la conception de la partie applicative d’un serveur Web étendu
exécutée sur le client (applet) d’utiliser une méthode orientée objet.
Justification
Le développement de la partie applicative d’un serveur Web étendu exécutée sur le client (applet)
s’apparente au développement d’une application orientée objet, et à ce titre, la méthode de
conception utilisée doit être orientée objet.
La méthode OMT est une des méthodes orientées objet préconisées par le CNES, pour ce qui
concerne la phase de conception. Elle est particulièrement adaptée pour les applications de type
client/serveur et doit être utilisée en respectant les Règles et recommandations pour l’utilisation
de la méthode OMT (DR2).
L’utilisation d’un outil support de la méthode OMT permet de faciliter sa mise en oeuvre et
éventuellement de générer le code.
Exemple
Sans objet.
SE.Réalisation.Applet
Le langage préconisé pour le développement de la partie
applicative d’un serveur Web étendu exécutée sur le client
(applet) est Java.
Description
Le langage Java est le langage préconisé pour le développement de composants téléchargeables
(applet).
Le document Règles et recommandations pour l’utilisation du langage Java (DR3) doit être
appliqué.
Justification
Le langage Java est le langage le plus couramment supporté par les navigateurs Web pour les
composants téléchargeables. L’indépendance du langage Java vis à vis de la plate-forme utilisée
est un autre facteur essentiel de sa préconisation.
De plus, les composants téléchargeables en Java, en général sur le modèle JavaBeans, sont
exécutés par une machine virtuelle Java dans le navigateur, machine qui est soumise à des
restrictions suivant un modèle de sécurité connu.
Exemple : sans objet.
METHODE ET PROCEDURE
_______
REGLES ET RECOMMANDATIONS POUR
LA REALISATION D'UN SERVEUR WEB
Page laissée intentionnellement blanche
RNC-CNES-E-40-505
Page 88
Version 2
13 mars 2000
METHODE ET PROCEDURE
_______
REGLES ET RECOMMANDATIONS POUR
LA REALISATION D'UN SERVEUR WEB
13. INDEX
RNC-CNES-E-40-505
Page 89
Version 2
13 mars 2000
DES REGLES
AI.Attentes
Page 23
AI.Existant.Adaptation
Page 25
AI.Existant.Etat
Page 24
AI.Miseàjour
Page 26
AI.Propriété
Page 26
AP.Attentes
Page 22
AP.Connaissance.Métier
Page 20
AP.Connaissance.Web
Page 21
AP.Description
Page 19
AT.Compétence
Page 32
AT.Config.Client
Page 28
AT.Logiciels.géné
Page 29
AT.Logiciels.Web
Page 30
AT.Matériels
Page 31
SD.Conception.IHM&CGI
Page 79
SD.Conception.InfoConfident
Page 82
SD.Conception.Méthode&CGI
(Recom)
Page 79
SD.Conception.Saisies
Page 80
SD.Conception.ScriptClient
Page 80
Les informations répondant aux attentes du public visé doivent être
identifiées
Les adaptations sur l'information actuelle doivent être identifiées
L'état de l'information à introduire dans le site doit être évalué
Les besoins de révision et de mises à jour doivent être identifiés
Le propriétaire de l'information et les droits de diffusion doivent être
identifiés
Les attentes du public visé doivent être identifiées
La connaissance du public visé sur le sujet traité par le site doit être
identifiée
L’expérience du public visé quant à la technologie du Web doit être
identifiée
La nature du public visé doit être identifiée
Les compétences (ressources humaines) doivent être évaluées
La configuration des installations du client doit être identifiée
Les besoins en logiciels de bureautique, de PAO et de multimédia
nécessaires pour le développement du site Web doivent être identifiés
Les logiciels spécifiques Web nécessaires au développement et à
l’exploitation du site doivent être identifiés
Les matériels nécessaires à la mise en place et l’exploitation du site
doivent être identifiés
Il faut, lors de la conception, séparer la partie IHM (HTML) de la partie
traitement.
Des paramètres transmis à l’intérieur d’une URL ne doivent pas contenir
d’informations confidentielles et doivent être testés par le programme les
utilisant.
Il est recommandé d’utiliser une méthode de conception
Le serveur Web doit prévenir des modifications ou saisies abusives de
champs cachés ou à choix restreint d’un formulaire HTML.
Les scripts client ne doivent pas être utilisés pour décider de l’affichage
ou pas d’informations confidentielles.
METHODE ET PROCEDURE
_______
RNC-CNES-E-40-505
REGLES ET RECOMMANDATIONS POUR
LA REALISATION D'UN SERVEUR WEB
SD.Conception.UtilScript
Page 81
SD.Processus
Page 77
SD.Processus.Prototype (Recom)
Page 77
SD.Réalisation.CGI (Recom)
Page 83
SD.Sécurité.Unix
Page 76
SD.Spécification.Méthode
& (Recom)
Page 78
SE.Conception.Méthode&Applet
Page 87
SE.Processus
Page 85
SE.Réalisation.Applet
Page 87
SE.Spécification.Méthode&Applet
Page 86
SS.Conception.FichierTrace
Page 47
SS.Conception.Résultat
Page 45
SS.Conception.Version
Page 46
SS.Configuration.ErreurAccès
(Recom)
Page 49
SS.Configuration.MIME (Recom)
Page 48
SS.Documentation
Page 90
Version 2
13 mars 2000
L’identité d’un utilisateur d’un script ou programme à accès restreint doit
être vérifiée en début d’exécution.
Le développement d’un serveur Web dynamique doit suivre un cycle de
vie adapté aux technologies Web, avec les moyens de gestion associés et
tous les niveaux de tests doivent être réalisés.
La démarche de développement préconisée pour les CGI est le
prototypage.
Le langage préconisé pour les CGI est le « C sécurisé ».
Si le serveur et les développements associés résident sur une plate-forme
de type UNIX, les exigences du document "Règles de sécurité pour les
développements sous UNIX " (DR6) doivent être appliquées.
Pour le développement de la partie applicative (CGI), il est conseillé
d’utiliser une méthode de spécification.
Pour le développement de la partie applicative exécutée sur le client
(applet), une méthode de conception doit être utilisée.
Le développement d’un serveur Web étendu doit suivre un cycle de vie
adapté aux technologies Web, avec les moyens de gestion associés et tous
les niveaux de tests doivent être réalisés.
Le langage préconisé pour le développement de la partie applicative d’un
serveur Web étendu exécutée sur le client (applet) est Java.
Pour le développement de la partie applicative exécutée sur le client
(applet), une méthode de spécification doit être utilisée.
Le mécanisme de trace des accès au serveur doit être mis en place et
paramétré.
La phase de conception doit déboucher sur un dossier de conception
comprenant des éléments spécifiques aux sites Web et éventuellement un
prototype ou une maquette.
La date de dernière modification des pages statiques doit être affichée.
Il est recommandé de définir les pages affichées en cas d’erreur d’accès
au serveur.
Il est recommandé de définir les types MIME des documents
téléchargeables au niveau du serveur.
La réalisation d’un serveur Web doit être documentée.
Page 36
SS.Ergonomie.Charte
Page 40
SS.Ergonomie.Lien
Page 51
SS.Ergonomie.MP&IHM
Page 37
SS.Ergonomie.Plugin
Page 50
Une charte navigationnelle, une charte rédactionnelle et une charte
graphique doivent être spécifiées.
Les liens vers des documents téléchargeables volumineux (> 30 Ko)
doivent être accompagnés d’une mention de leur taille.
Un ensemble de règles concernant l'interface homme machine du serveur
Web doit être appliqué.
Les liens vers des documents nécessitant l’utilisation de dispositifs
particuliers doivent être accompagnés d’informations sur la mise en
oeuvre de ce dispositif.
METHODE ET PROCEDURE
_______
RNC-CNES-E-40-505
REGLES ET RECOMMANDATIONS POUR
LA REALISATION D'UN SERVEUR WEB
SS.HTML.CarSpéciaux
Page 53
SS.HTML.Commentaires
Page 54
SS.HTML.EntêtePage
Page 62
SS.HTML.Image (Recom)
Page 60
SS.HTML.ImageMap
Page 61
SS.HTML.LgTable (Recom)
Page 65
SS.HTML.LienRelatif
Page 59
SS.HTML.Lisibilité
Page 55
SS.HTML.MotsClés
Page 53
SS.HTML.NomURL
Page 63
SS.HTML.Norme
Page 52
SS.HTML.Structure
Page 56
SS.HTML.Tags
Page 54
SS.Maintenance.Cohérence
Page 75
SS.Maintenance.FichierTrace
Page 74
SS.Maintenance.Version
Page 75
SS.Outil.Recherche
Page 73
SS.Performance.Volume
Page 64
SS.Portabilité.Navigateur
Page 38
SS.Processus.Analyses
Page 34
SS.Processus.Développement
Page 35
SS.Processus.Tests
Page 91
Version 2
13 mars 2000
Les caractères spéciaux doivent être spécifiés à l’aide du code HTML
correspondant.
Il est conseillé de mettre des commentaires dans un fichier HTML
Les informations standards d’en-tête de page (tags TITLE et META)
doivent être définies.
Les pages HTML doivent pouvoir être utilisées sans afficher les images
incorporées.
Les images maps doivent être définies côté client plutôt que côté serveur.
L’utilisation de tables HTML longues doit être évitée.
Les liens internes au site doivent être définis de manière relative.
Les fichiers HTML doivent être structurés
Les mots-clés ou tags et les options du langage doivent être mis en
majuscules
Les noms et formats d’URL doivent être homogènes et contrôlés.
Les pages Web doivent être créées en respectant la norme HTML définie
par le W3C et supportée par les navigateurs ciblés.
Les fichiers HTML doivent respecter une trame minimum
A tout tag d’ouverture doit correspondre un tag de fermeture
La cohérence des liens externes doit être vérifiée.
Les procédures d’exploitation des fichiers de trace des accès au serveur
doivent être formalisées.
La date de dernière modification des pages doit être mise à jour.
Si un outil de recherche est utilisé, son utilisation doit être précisée
Le volume de transfert doit être limité afin d’augmenter les performances
apparentes du serveur.
Les dispositifs proposés par le site Web doivent pouvoir être mis en
oeuvre par tous les utilisateurs de la population cible.
Des analyses préalables doivent être réalisées (analyse du public, de
l’information et de la technologie).
Le développement d’un serveur Web doit suivre un cycle de vie adapté
aux technologies web, avec les moyens de gestion associés.
Tous les niveaux de tests doivent être réalisés pour le développement
d’un serveur Web.
METHODE ET PROCEDURE
_______
RNC-CNES-E-40-505
REGLES ET RECOMMANDATIONS POUR
LA REALISATION D'UN SERVEUR WEB
Page 36
SS.Réalisation.ChampCaché
Page 69
SS.Réalisation.Cookies
Page 67
SS.Réalisation.Script (Recom)
Page 66
SS.Réalisation.Validation
Page 69
SS.Sécurité.MP&Sécurite
Page 39
SS.Spécification.Evolution
Page 42
SS.Spécification.FichierTrace
Page 43
SS.Spécification.Formation
Page 41
SS.Spécification.Serveur
Page 44
SS.Structure.Image
Page 71
SS.Structure.Page
Page 72
SS.Structure.Répertoire (Recom)
Page 70
Page 92
Version 2
13 mars 2000
Les champs cachés des formulaires HTML ne doivent pas contenir
d’informations confidentielles.
Si des cookies sont utilisés par un serveur Web, ils doivent être déclarés
avec une date d’expiration et leur domaine de visibilité doit être local au
serveur.
Le langage à utiliser pour les scripts client est le langage Javascript.
Un serveur Web doit être validé à chaque livraison.
Les exigences du document " Exigences de sécurité pour l’utilisation des
serveurs et relais HTTP " (DR5) doivent être appliquées, en particulier
dans le cas d’un serveur Web accessible depuis l’extérieur du CNES.
Dès la spécification, il faut définir et caractériser les informations
évolutives du site qui seront mises en évidence.
Dès la spécification, les besoins du site en matière d’analyse des fichiers
de trace des accès au serveur (log et erreur) doivent être définis.
Les personnes qui spécifient un serveur Web doivent être formées aux
technologies Web.
Dès la spécification, il est recommandé de définir un dispositif de
remplacement du serveur Web pendant les phases de maintenance.
Une image utilisée dans plusieurs pages ne doit pas être dupliquée au
niveau du serveur.
Les informations doivent être organisées dans une arborescence de
répertoires au niveau du serveur.
Il ne faut donner accès au listing d’un répertoire que si cela correspond à
un réel besoin.
REFERENTIEL NORMATIF REALISE PAR :
Centre Spatial de Toulouse
Délégation à l'Assurance de la Qualité
18 Avenue Edouard Belin
31401 TOULOUSE CEDEX 4
Tél : 05 61 27 31 31 - Fax : 05 61 27 31 79
CENTRE NATIONAL D'ETUDES SPATIALES
Siège social : 2 pl. Maurice Quentin 75039 Paris cedex 01 / Tel. (33) 01 44 76 75 00 / Fax : 01 44 46 76 76
RCS Paris B 775 665 912 / Siret : 775 665 912 00082 / Code APE 731Z