Ministère du Patrimoine canadien
Symbol of the Government of Canada
Skip to content | Skip to institutional links

Liens de la barre de menu commune

Accueil du RCIP > Financement > Programme d'investissement pour des expositions virtuelles > Gérer les investissements > Exigences techniques > Archive > Annexe II - 2.0

Liens institutionnels

rcip.gc.ca

Musée virtuel du Canada (MVC) Programme d'investissement pour des expositions virtuelles


Annexe II - Exigences techniques pour le développement des expositions et jeux du MVC, 2.0 (juin 2007)

Téléchargez le PDF

Table des matières

1.0 Balisage, présentation et scripts

2.0 Accessibilité

3.0 Répertoires, fichiers et URL

4.0 Navigation et éléments de page obligatoires

5.0 Types et formats de contenu

6.0 Métadonnées Dublin Core (DC)

7.0 Spécifications techniques de serveur et de base de données du RCIP

1.0 Balisage, présentation et scripts

Technologies de base

Pour s'assurer que le contenu du produit est accessible au plus grand nombre de visiteurs, quelle que soit la configuration technique de leur système ou dispositif :

XHTML 1.0 Strict
Feuilles de style en cascade (CSS)
  • 1.3 Présentation et style (présentation visuelle et conception) doivent s'appliquer à travers l'utilisation de Feuilles de style en cascade (CSS) valides.

    Note: Les feuilles de style CSS 1.0 et CSS 2.1 peuvent être utilisées. Il n'est pas obligatoire que chaque navigateur affiche la même présentation CSS de contenu du produit. Dans certains cas, il peut être préférable de n'envoyer à certains navigateurs, p. ex. IE/Win 4.x et IE/Mac 5.x, absolument aucune feuille de style CSS.

  • 1.4 Les feuilles de style CSS doivent être complètement séparées du contenu et de la structure des pages et référencées dans la section <head> d'une page, en tant que fichiers externes. Elles ne doivent pas être imbriquées ni incorporées.
ECMAScript (JavaScript)
  • 1.5 Les scripts côté client doivent respecter le DOM du W3C (scripts DOM) et être conformes à la norme ECMAScript, version 3 (ECMA-262).
  • 1.6 Les scripts côté client doivent être complètement séparés du contenu et de la structure des pages et référencés dans la section <head> d'une page, en tant que fichiers externes. Ils ne doivent pas être imbriqués ni incorporés.

    Note: Même si les gestionnaires d'événements en-ligne (p. ex. « onclick », « onfocus ») appelant les fonctions de script côté client sont autorisés, il est préférable de les écrire de façon dynamique dans le DOM à l'aide de techniques de scripts DOM valides et discrètes.

Encodage de caractères

  • 1.7 Chaque page du produit doit utiliser et indiquer la norme UTF-8 ou ISO-8859-1 comme encodage de caractères.

    Note: Pour une discussion des enjeux touchant l'encodage de caractères et le fait de servir des documents XHTML, voir le tutoriel W3C, Character sets & encodings in XHTML, HTML and CSS.

Protocole Secure Sockets Layer (SSL)

  • 1.8 Le produit doit utiliser le protocole Secure Sockets Layer (SSL) lorsque tout renseignement personnel (y compris, mais sans s'y restreindre, le nom, l'adresse, l'âge, l'adresse de courriel, le numéro de téléphone et le numéro de carte de crédit) est exigé d'un utilisateur pour être stocké dans le produit et gardé afin d'être utilisé par l'établissement.

    Note: Tous les hyperliens vers des pages n'utilisant pas le protocole SSL doivent utiliser des URL absolus. Il n'est pas nécessaire d'utiliser le protocole SSL lorsqu'on recueille de l'information sur un formulaire de commentaires par courriel ou qu'on demande le sobriquet d'un utilisateur seulement, par exemple, pour conserver un score élevé dans un jeu en ligne.

Élément <iframe>

  • 1.9 L'utilisation de l'élément <iframe>, c'est-à-dire la trame en-ligne, n'est pas autorisée sans l'approbation expresse du RCIP.

2.0 Accessibilité

Directives pour l'accessibilité aux contenus Web (version 1.0) du W3C

S'assurer que le contenu et la fonctionnalité de base du produit sont accessibles à tous les Canadiens, indépendamment de leurs déficiences physiques :

  • 2.1 Le produit doit se conformer aux points de contrôle de Priorité 1 et de Priorité 2 (niveau de conformité « Double A ») des Directives pour l'accessibilité aux contenus Web (WCAG), version 1.0.

    Note: Conformément aux points de contrôle 1.1, 1.3 et 1.4 de Priorité 1, les clips audio autonome doivent avoir une transcription textuelle; les clips vidéo doivent inclurent des sous-titres synchronisés, des descriptions audio de toutes actions significatives durant le vidéo et être accompagné d'une description textuelle complète clip du vidéo.

  • 2.2 Le produit doit également se conformer au point de contrôle 2.2 de Priorité 3 des WCAG, où le contraste des couleurs du texte et de l'arrière-plan est en jeu.

3.0 Répertoires, fichiers et URL

Structure des fichiers et des répertoires

  • 3.1 Le répertoire supérieur ou racine du produit, ainsi que tous les répertoires contenant une ou plusieurs pages Web, doit inclure une page implicite (p. ex., index.html, default.html, index.php) qui sert de page principale pour ce répertoire. Voir la section « Navigation », à la rubrique4.0 Navigation et éléments de page obligatoires pour connaître la structure navigationnelle que ces pages doivent incorporer.
  • 3.2 Le produit doit inclure, dans son répertoire supérieur ou racine, des répertoires distincts pour chaque version linguistique du produit. Voir la section « Navigation », à la rubrique4.0 Navigation et éléments de page obligatoires pour connaître la structure navigationnelle que ces pages doivent incorporer.
  • 3.3 Les fichiers de produit contenant un important contenu commun à toutes les versions linguistiques du produit (p. ex., images, CSS, JavaScript) doivent être placés dans des répertoires uniques situés dans le répertoire supérieur ou racine du produit, et ne doivent pas être dupliqués.
  • 3.4 Les fichiers de produit propres à une version linguistique particulière du produit doivent être situés dans le répertoire de cette version linguistique (voir le paragraphe 3.2 ci-dessus).

Noms de fichiers et de répertoires

  • 3.5 Les noms de fichiers et de répertoires ne doivent inclure aucun trait de soulignement ni espace et ne peuvent utiliser que les caractères suivants :
    • caractères alphabétiques en minuscules seulement (de a à z)
    • caractères numériques (de 0 à 9)
    • traits d'union (-)
    • points (.)
  • 3.6 Les noms de fichiers et de répertoires doivent donner le même traitement aux deux langues officielles (français et anglais) en utilisant uniformément l'une des approches ci-dessous :
    • propre à la langue (p. ex. un répertoire appelé « /manitobahistory/ » et un fichier appelé « history.html » pour la version anglaise, « /histoiremanitoba/ » et « histoire.html » pour la version française) ;
    • mot épelé de la même façon dans les deux langues officielles (p. ex. un répertoire appelé « /options/ » ou un fichier appelé « menu.html ») ;
    • indifférente à la langue, comme des chiffres (p. ex. un répertoire appelé « /100/ » ou un fichier appelé « 123.html ») ; des caractères alphabétiques (p. ex. un répertoire appelé « /aaa/ » ou un fichier appelé « abc.html »); ou une combinaison alphanumérique (p. ex. un répertoire appelé « /10aa1/ » ou un fichier appelé « 34de1.html »).
  • 3.7 Tous les fichiers XHTML statiques du produit doivent utiliser le suffixe « .html » et non pas le suffixe « .htm ».

URL

URL de pages d'accueil
  • 3.8 Les URL pour les pages d'accueil unilingues et la page introductive de la sélection linguistique du produit (voir les paragraphes 4.5 and 4.6) ne doivent inclure aucun paramètre d'URL (paire nom-valeur).
URL relatives
  • 3.9 Tout URL pour les pages et ressources du produit doivent être relatives, à l'exception des URL des pages utilisant le protocole SSL vers des pages n'utilisant pas le protocole SSL (voir la paragraphe 1.8).

4.0 Navigation et éléments de page obligatoires

Titre du produit

  • 4.1 Chaque page du produit doit inclure le titre du produit, afin d'identifier le contenu de la page comme faisant partie du produit.

Logo du MVC

  • 4.2 Le logo du MVC, qui sera fourni par le RCIP, doit figurer dans le coin supérieur droit de chaque page du produit et sans aucune bordure d'image.
  • 4.3 Les références JavaScript et le code XHTML qui suivent doivent être incorporés tels quels dans le produit. Tout d'abord, l'élément <head> de chaque page du produit doit contenir les références suivantes à un fichier source en JavaScript :
    Anglais

    <script type="text/javascript" src="http://www.virtualmuseum.ca/Logo_Script/english.js">
    </script>

    Français

    <script type="text/javascript" src="http://www.virtualmuseum.ca/Logo_Script/francais.js">
    </script>

    Ensuite, le code XHTML suivant doit être utilisé pour charger et le logo et y établir un hyperlien :

    Anglais

    <a href="http://www.virtualmuseum.ca/English/" onclick="gotoVirtualMuseumofCanada(); return false;"><img src="Images/vmcLogo.gif" alt="Virtual Museum of Canada" /></a>

    Français

    <a href="http://www.museevirtuel.ca/Francais/" onclick="gotoVirtualMuseumofCanada(); return false;"><img src="Images/vmcLogo.gif" alt="Musée virtuel du Canada" /></a>

    Note: Remplacez « Images/vmcLogo.gif » dans le code ci-dessus par le nom et l'emplacement appropriés du fichier image du logo utilisé dans le produit.

    Idéalement, le gestionnaire d'événements « onclick », situé dans l'ancre du logo du MVC, doit être ajouté de façon dynamique, dès que le DOM de la page a été chargé. Cependant, pour éviter d'éventuels conflits avec les propres scripts DOM du produit, utilisez un gestionnaire en ligne « onclick ».

  • 4.4 L'image du logo du MVC ne peut faire partie d'une carte-image côté client, sans l'autorisation expresse du RCIP.

Navigation

Navigation dans la version linguistique
  • 4.5 La page implicite (p. ex., index.html, default.html, index.php) dans le répertoire supérieur du produit doit servir de page introductive de la sélection linguistique du produit et inclure un hyperlien vers la page d'accueil unilingue de chaque version linguistique du produit.
  • 4.6 La page implicite (p. ex., index.html, default.html, index.php) dans le répertoire principal de chaque version linguistique du produit doit servir de page d'accueil unilingue pour cette version linguistique.
  • 4.7 Chaque page du produit doit comprendre un hyperlien vers l'autre version linguistique ou les autres versions linguistiques du produit. Ce lien doit être visible sans défilement de la page, avec une résolution d'écran de 1024 x 768 pixels, et diriger l'utilisateur vers la même page dans l'autre langue ou vers la page d'accueil unilingue du produit dans l'autre langue.
Navigation vers les pages d'accueil
  • 4.8 Chaque page du produit doit comprendre un hyperlien vers la page d'accueil unilingue, dans la langue pertinente.

Droit d'auteur

  • 4.9 Le produit doit inclure un énoncé de droit d’auteur intégral qui identifie tous les détenteurs de droits d’auteur. Cette page doit être présentée dans chaque version linguistique.
  • 4.10 Le symbole de copyright, ©, le détenteur du droit d'auteur et l'année au cours de laquelle le produit a été lancé doivent apparaître sur chaque page du produit et mener à l'énoncé de droit d'auteur intégral (voir le paragraphe 4.9 ci-dessus), par exemple :

    © Musée d'histoire 2005. Tous droits réservés.

    Note: Si l'établissement qui détient le droit d'auteur est officiellement bilingue, utilisez le nom anglais de l'établissement dans la version anglaise du produit, et son nom français, dans la version française. Si l'établissement est unilingue, utilisez le même nom dans chaque version linguistique.

Remerciements

  • 4.11 Le produit doit avoir une page de « Remerciements » qui est reliée à la fois à la page introductive de la sélection linguistique et à chaque page d'accueil unilingue, et qui reconnaît la participation financière du Gouvernement du Canada comme ci-dessous :
    Anglais

    The [Name of Institution] gratefully acknowledges the financial investment by the Department of Canadian Heritage in the creation of this online presentation for the Virtual Museum of Canada.

    Français

    Le [Nom de l'établissement] exprime sa reconnaissance au ministère du Patrimoine canadien pour son investissement financier dans la création de cette présentation en ligne dans le cadre du Musée virtuel du Canada.

  • 4.12 La page des « Remerciements » doit nommer tous les partenaires institutionnels participant au produit et y mener par des hyperliens.

Mécanisme de rétroaction

  • 4.13 Chaque page du produit doit inclure un hyperlien donnant accès à un simple formulaire en XHTML où le public peut indiquer ses messages de rétroaction. Ce formulaire doit être configuré pour permettre également l'envoi d'un courriel à l'établissement responsable du produit et au RCIP (à vmccc@virtualmuseum.ca, pour la version anglaise, ou à mvccc@museevirtuel.ca, pour la version française), accompagné d'une identification nette du produit sur la ligne de l'objet.

    Note: Le RCIP fournira, sur demande, un URL personnalisé pour le formulaire de rétroaction du MVC, à utiliser dans le cadre du mécanisme de rétroaction.

  • 4.14 Les utilisateurs doivent également être avisés que leurs messages de rétroaction sont également transmis au RCIP, et doivent avoir accès à un hyperlien vers la Politique de protection des renseignements personnels du RCIP (voir l'exemple ci-dessous). Sinon, l'information qui identifie l'utilisateur pourrait être retirée de la rétroaction.
    Exemple du message en anglais

    Your comments will also be forwarded to the Canadian Heritage Information Network (CHIN), which has overall responsibility for the Virtual Museum of Canada, to be used as part of its audience research. Please see the CHIN Privacy Policy for more information.

    Exemple du message en français

    Vos commentaires seront également acheminés au Réseau canadien d'information sur le patrimoine (RCIP), qui a la responsabilité globale du Musée virtuel du Canada. Ils seront utilisés à des fins de recherche sur le public. Veuillez consulter la Politique du RCIP sur la protection des renseignements personnels pour de plus amples renseignements.

    URL de la Politique de protection des renseignements personnels du RCIP — en anglais

    http://www.virtualmuseum.ca/English/
    Common/copyright.html#privacy

    URL de la Politique de protection des renseignements personnels du RCIP — en français

    http://www.museevirtuel.ca/Francais/
    Common/copyright.html#privacy

  • 4.15 Les utilisateurs doivent être avisés des problèmes de confidentialité associés à l'envoi de messages de rétroaction par courriel en recevant l'avis suivant :
    Anglais

    The Internet is a public forum and electronic information can be intercepted. For reasons of security and privacy, we ask that you not send us any personal or confidential information, such as your Social Insurance Number (SIN), home or business address.

    Français

    Internet est un forum public et l'information électronique peut être interceptée. Pour des raisons de sécurité et de respect de la vie privée, nous vous demandons de ne pas nous faire parvenir de renseignements personnels ou confidentiels, tels votre numéro d'assurance sociale, l'adresse de votre domicile ou de votre bureau.

Carte de site

  • 4.16 Le produit doit comprendre une carte du site (p. ex., une hiérarchie organisée par liste d’hyperliens à toutes les principales sections et pages du produit, à au moins deux niveaux de répertoire), pour chaque version linguistique du produit, à l’aide d’hyperliens textuels, par opposition à des hyperliens graphiques ou à des boutons.
  • 4.17 Chaque page du produit doit inclure un hyperlien texte vers la carte de site dans la langue appropriée, afin que les utilisateurs humains et les moteurs de recherche puissent trouver chaque page du produit.

Élément <title>

  • 4.18 Chaque page du produit doit inclure dans sa section <head> un élément <title> contenant un titre significatif et riche en mots-clés pour le contenu de cette page. Chaque page doit donc avoir un élément <title> unique à cette page.

Élément <meta> « description »

  • 4.19 Chaque page d'accueil unilingue doit inclure dans la section <head> un élément <meta> « description » contenant une description significative et riche en mots-clés du contenu de cette page. Chaque page d'accueil unilingue doit donc avoir un élément <meta> « description » unique à cette page.

Indication de la langue du contenu

  • 4.20 Chaque page du produit doit indiquer la langue principale de la page en intégrant les attributs « lang » et « xml:lang » dans l'élément <html>.
  • 4.21 La langue du contenu d'une page qui n'est pas dans la langue principale de cette page doit être indiquée en intégrant les attributs « lang » et « xml:lang » dans l'élément XHTML qui inclut le contenu.

En-têtes et bas de page navigationnels

  • 4.22 L'utilisation d'outils de navigation de sites Web corporatifs ou institutionnels, notamment les bannières, les en-têtes ou les bas de page, n'est pas autorisée sans l'approbation expresse du RCIP.

5.0 Types et formats de contenu

Modules d'extension et logiciels spécialisés

Si un contenu du produit nécessite un module d'extension ou un logiciel spécialisé pour pouvoir s'afficher :

  • 5.1 Le module ou le logiciel spécialisé doit être librement accessible et pouvoir être installé sur n'importe quelle plateforme.
  • 5.2 Les hyperliens vers un contenu nécessitant un module d'extension ou un logiciel spécialisé doivent être accompagnés de l'indication, sous forme de texte, du format, du type de fichier et de la taille du contenu.
  • 5.3 Un hyperlien vers la source du module d'extension ou du logiciel spécialisé pertinent doit être fourni sur chaque page qui a besoin de ce module ou de ce logiciel pour donner accès au contenu.

Texte

  • 5.4 Le contenu textuel doit être développé pour fins d'exécution sur un navigateur Web dans la variante XHTML 1.0 Strict.

    Note: Bien que tout contenu textuel doive être affiché en tant que XHTML, pareil contenu peut également être élaboré dans un format breveté pour visualisation ou impression au moyen d'un logiciel enfichable librement accessible sur Internet. L'exemple de ce type de format est PDF d'Adobe, qui exige l'utilisation d'Adobe Reader, le visualiseur de fichiers PDF d'Adobe.

    Le contenu textuel peut également être exécuté en formats RTF ou ASCII, ou à titre de fichier de texte délimité. Le contenu produit selon pareils formats est acceptable si les fichiers sont destinés à un téléchargement, un entreposage ou un traitement par des utilisateurs provenant de l'extérieur de l'environnement du navigateur, et s'ils ne sont pas destinés à se substituer au contenu créé en XHTML.

Images fixes

  • 5.5 Tous les graphiques composés d'images fixes doivent être optimisés et améliorés pour le Web afin de réduire la taille des fichiers et la durée du téléchargement :
    • L'utilisation des formats GIF ou PNG est obligatoire pour les graphiques vectoriels.
    • L'utilisation du format JPEG (à 24 bits) est obligatoire pour les photographies, la haute résolution et les images en demi-teintes.

    Note: Des exemptions à ce critère peuvent être accordées par le RCIP dans certains cas où l'utilisation de solutions brevetées est nécessaire pour atteindre les objectifs du projet.

  • 5.6 Tout hyperlien vers des gros fichiers d'images de taille supérieure à 80 Ko doit comprendre une étiquette indiquant la taille des fichiers afin d'alerter les utilisateurs.
  • 5.7 Si une image miniature est utilisée en tant qu’hyperlien à une image de plus grande taille, l’image miniature doit représenter une version distincte de l’image plus grande, redimensionnée à une échelle appropriée. Une image pleine taille ne peut pas être redimensionnée par le biais des attributs d’image, en vue de créer une image miniature.

Vidéos/images mobiles

  • 5.8 Un vidéo peut être diffusé en continu ou acheminé sous forme de fichier à télécharger. Si un fichier vidéo est préparé pour être exécuté dans un environnement à large bande passante, une autre version à bande passante réduite doit également être préparée et fournie aux utilisateurs.

    Note: Certains systèmes de diffusion en continu permettent aux réalisateurs de préparer un fichier vidéo unique qui peut être lu aux diverses vitesses de diffusion qui correspondent aux différentes vitesses d'accès à Internet. Lorsque ces systèmes sont utilisés, une version unique d'un fichier vidéo suffit.

    Le RCIP retient régulièrement à contrat les services de diffusion de médias en continu auprès d'Akamai. Si le produit doit utiliser de la vidéo, il lui est possible d'utiliser ce service. Pour de plus amples renseignements, communiquez avec le RCIP.

  • 5.9 Les fichiers vidéo diffusés en continu, qui sont chargés dans un lecteur intégré à un navigateur, ne doivent pas démarrer automatiquement, et le lecteur doit inclure des contrôles de lancement et d'arrêt du vidéo.
  • 5.10 Tout hyperlien vers de gros fichiers vidéo non transmis en continu doit être accompagné d'une étiquette indiquant la durée du fichier.
  • 5.11 Lorsqu'un codec est utilisé pour comprimer le contenu de fichiers vidéo, il doit être inclus dans une plateforme ou un progiciel standard ou être librement accessible aux utilisateurs qui ont besoin de le télécharger et de l'installer.

Fichier audio ou sonores

  • 5.12 Les éléments audio peuvent être diffusés en continu ou acheminés comme fichier à télécharger. Si un fichier audio est préparé pour être exécuté dans un environnement à large bande passante, une autre version à bande passante réduite doit également être préparée et fournie aux utilisateurs.

    Note: Certains systèmes de diffusion en continu permettent aux réalisateurs de préparer un fichier audio unique qui peut être lu aux diverses vitesses de diffusion qui correspondent aux différentes vitesses d'accès à Internet. Lorsque ces systèmes sont utilisés, une version unique d'un fichier audio suffit.

    Le RCIP retient régulièrement à contrat les services de diffusion de médias en continu auprès d'Akamai. Si le produit doit utiliser de l'audio, il lui est possible d'utiliser ce service. Pour de plus amples renseignements, communiquez avec le RCIP.

  • 5.13 Les fichiers audio diffusés en continu, qui sont chargés dans un lecteur intégré à un navigateur, ne doivent pas démarrer automatiquement, et le lecteur doit inclure des contrôles de lancement et d'arrêt de l'audio.
  • 5.14 Tous les hyperliens vers des fichiers audio transmis en continu doivent être accompagnés d'une étiquette indiquant la durée du fichier transmis en continu.
  • 5.15 Lorsqu'un codec est utilisé pour comprimer le contenu de fichiers audio, il doit être inclus dans une plateforme ou un progiciel standard ou être librement accessible aux utilisateurs qui veulent l'installer. Un hyperlien vers le codec doit être fourni aux utilisateurs qui ont besoin de le télécharger et de l'installer.

Fichers d'animation

  • 5.16 Tout hyperlien vers de gros fichiers d'animation supérieurs à 80 Ko doit être accompagné d'une étiquette indiquant la taille du fichier.

6.0 Métadonnées Dublin Core (DC)

Éléments de métadonnées DC

  • 6.1 Les éléments de métadonnées Title, Creator, Subject, Description, Date, Identifier, and Language de l'Ensemble d'éléments de métadonnées du Dublin Core, Version 1.1 doivent être inclus dans chacune des pages suivantes :
    • la page introductive de la sélection linguistique du produit
    • les pages d'accueil unilingues
    • la page principale de chaque section majeure du produit
    • toutes les pages à contenu unique, comme du texte, des images ou d’autres ressources

    Notes: Le contenu des métadonnées DC pour les pages ou ressources anglaises doit être en anglais, pendant que le contenu des métadonnées pour les pages françaises doit être en français.

    Les pages ayant été créées pour la présentation d’objets ou d’images pleine taille, où aucun nouveau contenu n’a été fourni, n’ont pas nécessairement à contenir des éléments de métadonnées.

Mise en oeuvre de métadonnées DC

  • 6.2 Toutes les métadonnées du produit doivent être exprimées d'une manière uniformisée qui peut être lue, interrogée et échangée par des systèmes informatiques.

    Note: Les métadonnées peuvent être exprimées en XHTML ou RDF/XML (Resource Description Framework/Extensible Markup Language). Les métadonnées simples, comme les éléments non qualifiés du Dublin Core, peuvent être facilement exprimées en XHTML. Les métadonnées plus complexes, comme les éléments qualifiés du Dublin Core, peuvent être exprimées en XHTML, mais avec des restrictions. RDF/XML a été utilisé avec plus de succès pour les métadonnées complexes, hautement structurées.

7.0 Spécifications techniques de serveur et de base de données du RCIP

Environnement du serveur du RCIP

  • 7.1 Les produits à héberger sur le serveur du RCIP doivent être élaborés conformément aux spécifications d'environnements suivantes :
    Serveur
    • UNIX — Sun Solaris 10
    • Apache 2.2.4
    • Les pages statiques XHTML requièrent le suffixe « .html ».
    CGI et PERL
    • Les scripts CGI requièrent le suffixe « .cgi » et peuvent être situés n'importe où dans la structure de répertoires du projet.
    • PERL 5.8.8 est activée.
    • La plupart des modules standard de PERL sont disponibles, par exemple, CGI, DBI.
    • Les scripts PERL et CGI requièrent la notation « shebang » suivante :

      #!/usr/local/bin/perl
      use strict;

    PHP
    • PHP 5.2.2 est activéeser le suffixe « .php ».
    • Les scripts PHP doivent utiliser les suffixes « .php » ou « inc ».
    • La ligne register_globals doit être réglée à « OFF » (désactivée).
    • Le recours à des variables plus longues telles que ($HTTP_POST_VARS) est interdit. Des variables plus courtes comme ($_POST) peuvent être utilisées.
    • Les scripts PHP peuvent être situés n'importe où dans la structure de répertoires du projet.
    • L'accès PHP à MySQL est activé.
    • Le soutien PHP de XML est activé.
    • Le RCIP décidera de l'ajout d’extension PHP, au cas par cas. Si vous souhaitez utiliser une extension PHP particulière, renseignez-vous auprès du RCIP.
    Inclusions côté serveur (SSI)

    Note: Toute page XHTML ayant le suffixe « .html » et le de bit d'exécution activé sera analysée pour SSI.

    Base de données
    • MySQL 5.0.41
    • L'accès direct au système de gestion de bases de données (SGBD) MySQL ne sera accordé que sur autorisation spéciale. Si l'autorisation est donnée, l'accès sera possible par l'intermédiaire d'une interface SSH/ligne de commande.
    • La politique réseau du ministère du Patrimoine canadien n'autorise pas l'utilisation d'interfaces graphiques pour établir un lien avec le serveur de bases de données à partir de l'extérieur du réseau ministériel.
    • Pour créer la structure d'une base de données ou charger les données d'un tableau, un fichier SQL conforme à la procédure MySQL peut être envoyé au RCIP à des fins de chargement dans le SGBD.

Validation des scripts

  • 7.2 Si le produit doit être hébergé sur le serveur du RCIP, les scripts PHP et PERL doivent respecter les règles de validation suivantes :
    • Tous les paramètres intégrés aux scripts doivent être validés avant d'être utilisés.
    • Toutes les variables locales doivent être explicitement initialisées avant d'être utilisées.
    • Les paramètres qui peuvent contenir seulement des valeurs provenant des ensembles contraints doivent être validés pour garantir que leurs valeurs se situent dans ces ensembles contraints.
    • Les paramètres doivent être validés pour garantir que leurs valeurs sont du type prévu. Par exemple, si un paramètre doit contenir seulement des chiffres, la valeur intégrée doit être validée en tant que chaîne numérique.
    • Les paramètres utilisés comme critères pour les énoncés SQL produits automatiquement doivent être protégés (en utilisant une barre oblique inverse) avant d'être utilisés dans un énoncé SQL.
    • Les fichiers inclus/requis doivent être validés pour garantir que leurs chemins d'accès existent sur le serveur hôte.
    • Les fichiers inclus/requis doivent être validés pour garantir qu'ils sont bel et bien des fichiers.

    Note: Voir « CGI et PERL » et « PHP » au paragraphe 7.1 pour obtenir les dernières versions de PERL et de PHP utilisées sur le serveur du RCIP.

Conception de bases de données

Chaînes de connexion
  • 7.3 Toutes les chaînes de connexion à une base de données doivent être extraites du produit et placées dans un fichier « config.php » stocké dans un répertoire auquel le serveur Web n'a pas accès, c'est-à-dire un répertoire d'un niveau au-dessus du répertoire racine du produit.
SGBD
  • 7.4 Si le produit emploie une base de données et doit être hébergé sur le serveur du RCIP, la base de données doit utiliser le système SGBD du serveur de la base de données MySQL.

    Note: Voir « Base de données » au paragraphe 7.1 pour obtenir la dernière version de MySQL utilisée par le serveur du RCIP.

Normalisation
  • 7.5 Si le produit emploie une base de données et doit être hébergé sur le serveur du RCIP, les modèles de données logiques doivent être en troisième forme normale (3FN), ce qui veut dire que tous les attributs d'une table relationnelle particulière doivent dépendre fonctionnellement de la clé principale.

    Note: Dans le modèle de données logiques, une clé candidate formée d'attributs réels doit servir de clé principale. Une autoincrémentation, ou une autre forme de clé artificielle, peut être utilisée dans le modèle de données physiques. Les tables peuvent être dénormalisées en modèles de données physiques pour des raisons de rendement, mais ces exceptions doivent être justifiées par des preuves quantitative (p. ex. dans quelle mesure la structure dénormalisée est-elle plus rapide?).

Normes de dénomination
  • 7.6 Si le produit emploie une base de données et doit être hébergé sur le serveur du RCIP, il faut suivre les normes de dénomination de base de données suivantes :
    • Les bases de données doivent avoir un nom descriptif et une abréviation assez courte (maximum de 5 caractères).
    • Les tables doivent avoir un nom descriptif préfixé avec l'abréviation de leur base de données et une abréviation assez courte (maximum de 5 caractères).
    • Les champs doivent avoir un nom descriptif préfixé avec l'abréviation de leur table.
    • Les vues doivent avoir un nom descriptif préfixé avec l'abréviation de leur base de données.
    • Les noms des index doivent commencer par un « U » pour index uniques, ou un « S » pour index non uniques, et être suivis de l'abréviation de la table, puis du nom de chaque champ participant à l'index.
    • Les noms des déclencheurs doivent commencer par « TD » (lors d'un DELETE), « TI » (lors d'un INSERT) ou « TU » (lors d'un UPDATE) et être suivis du nom de la table. Pour les SGBDR dont les déclencheurs agissent au niveau du champ plutôt qu'au niveau de la table, le nom de la table doit être remplacé par l'abréviation de la table et le nom du champ.
Dictionnaire de données
  • 7.7 Si le produit emploie une base de données et doit être hébergé sur le serveur du RCIP, tous les éléments de la base de données (base de données, table, champ, index, vue, déclencheur, etc.) doivent avoir un nom, un titre et une description. Les champs doivent également contenir de l'information sur le type de données et leur valeur par défaut.

    Note: La description des vues doit inclure la définition de la vue et la description des déclencheurs doit contenir le code source annoté.

  • 7.8 Si le produit emploie une base de données et doit être hébergé sur le serveur du RCIP, toute information qui est stockée dans la base de données et qui indique l'utilisation du produit doit avoir une valeur d'horodateur associée à des fins de suivi et de vérification.

Footer Links

Apprenez-en davantage sur nos établissements membres

Inscription au(x) bulletin(s) électronique(s)

  • Amis du MVC
  • Centre des enseignants du MVC
  • RCIP
S'abonner

Date de modification : 2009-11-07

Haut de la page

Avis importants

© RCIP 2009. Tous droits réservés. | v2.0