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 - 3.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, 3.0

Téléchargez le fichier PDF (224 Ko)

Table des matières

Note sur la terminologie

Addenda

1.0 Balisage, présentation et scripts

2.0 Accessibilité

3.0 Répertoires, fichiers et URL

4.0 Navigation, disposition et conception

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

Note sur la terminologie

Les définitions et les termes suivants, utilisés dans le présent document, sont directement adaptés du RFC 2119 :

  • DOIT et DOIVENT : Ces mots indiquent une exigence absolue.
  • NE DOIT PAS et NE DOIVENT PAS : Ces expressions indiquent une interdiction absolue.
  • PEUT et PEUVENT : Ces mots indiquent une mesure facultative qui est ni obligatoire, ni interdite.
  • DEVRAIT et DEVRAIENT : Ces mots indiquent une mesure recommandée qui peut être ignorée dans certaines circonstances et dont l'ensemble des répercussions doivent être comprises avant de procéder à la mise en œuvre de telles mesures.
  • NE DEVRAIT PAS et NE DEVRAIENT PAS : Ces expressions indiquent une mesure déconseillée, mais qui pourrait être permise dans certaines circonstances et dont l'ensemble des répercussions doivent être comprises avant de mettre en application ce genre de mesures.

Addenda

Addendum au paragraphe 1.6

Advenant qu'un script provenant d'une tierce partie ne puisse pas être facilement et discrètement mis en oeuvre, vous DEVEZ demander la permission au RCIP avant d'utiliser des scripts ou des éléments script incorporés.

1.0 Balisage, présentation et scripts

Technologies de base

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

XHTML 1.0 Strict
  • 1.1 Le produit et toutes ses pages DOIVENT utiliser XHTML 1.0 Strict pour le balisage sémantique et structurel du contenu des pages Web. Les variantes Frameset et Transitional de XHTML 1.0 NE DOIVENT PAS être utilisées.

    Nota : Il est important de comprendre les enjeux à servir des documents XHTML en tant que HTML (étiquetage MIME « text/html ») par opposition à XML (étiquetage MIME « application/xhtml+xml »). Pour plus de précisions sur ces enjeux, voir le document du W3C intitulé Les types de Media XHTML, ainsi que les tutoriaux W3C intitulés Ensembles de caractères et encodage en XHTML, HTML et CSS et Servir du XHTML 1.0. Les produits qui ne seront pas hébergés sur le serveur du RCIP PEUVENT servir les pages du produit comme « application/xhtml+xml » pour les agents utilisateurs compatibles. Cependant, le serveur du RCIP envoie tous les documents XHTML en tant que « text/html ».

  • 1.2 Le produit et toutes ses pages, y compris le balisage XHTML généré ou modifié de façon dynamique par les scripts DOM côté client, DOIVENT se valider par rapport à la définition de type de document (DTD) publiée par le W3C pour XHTML 1.0 Strict.
Feuilles de style en cascade (CSS)
  • 1.3 La présentation et le style (présentation visuelle et conception) DOIVENT s'appliquer à travers l'utilisation de Feuilles de style en cascade (CSS) valides.

    Nota : Les CSS1, CSS 2.1, et CSS3, pour lesquelles le W3C accorde une validation, 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 aucune CSS à certains navigateurs (p. ex. Netscape 4.x, Internet Explorer Win 4.x et Internet Explorer Mac 5.x).

  • 1.4 Les CSS DOIVENT être complètement séparées du contenu et de la structure des pages, et référencées en tant que fichiers externes dans la section head d'une page. Elles NE DOIVENT PAS être imbriquées ou incorporées.
Scripts côté client
  • 1.5 Les scripts côté client DOIVENT respecter le DOM du W3C (scripts DOM) et se conformer à la norme ECMAScript, version 3 (ECMA-262).

    Nota : La propriété innerHTML et l'objet XMLHttpRequest sont des exceptions à la règle susmentionnée et ils PEUVENT être utilisés.

  • 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 imbriqués ou incorporés.

    Nota : Les gestionnaires d'événements en ligne (p. ex. onclick, onfocus) dans la couche XHTML sont interdits. Les gestionnaires d'événements DOIVENT être écrits de façon dynamique dans le DOM à l'aide de techniques de scripts DOM valides et discrètes.

    ADDENDUM : Advenant qu'un script provenant d'une tierce partie ne puisse pas être facilement et discrètement mis en oeuvre, vous DEVEZ demander la permission au RCIP avant d'utiliser des scripts ou des éléments script incorporés.

  • 1.7 Les scripts côté client DOIVENT être mis à l'essai et exécutés en fonction du soutien de l'agent utilisateur pour les objets critiques du DOM mis en œuvre dans les scripts, contrairement à une mise à l'essai pour les chaînes de l'agent utilisateur ou autrement la « détection d'erreurs dans le navigateur ».

Encodage de caractères

  • 1.8 Chaque page du produit doit utiliser et indiquer la norme UTF-8 comme encodage de caractères.

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

Protocole Secure Sockets Layer (SSL)

  • 1.9 Le produit DOIT utiliser le protocole Secure Sockets Layer (SSL) lorsque l'utilisateur est tenu d'entrer un nom d'utilisateur et un mot de passe (p. ex., accès) ou 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) pour être stocké par le produit et conservé afin d'être utilisé par l'établissement responsable du produit.

    Nota : 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.

  • 1.10 Tous les hyperliens vers des pages n'utilisant pas le protocole SSL DOIVENT utiliser des URL absolus.

2.0 Accessibilité

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

S'assurer que le contenu et la fonctionnalité de base du produit soient accessibles au plus grand nombre possible de visiteurs :

  • 2.1 Le produit DOIT se conformer aux critères de réussite de niveau A et AA de la version 2.0 des Directives pour l'accessibilité aux contenus Web (WCAG), sauf pour les critères de réussite 1.2.4 (sous-titres pour les médias en direct) et 1.2.5 (exigence de descriptions audio).

    Nota : Conformément aux critères de réussite 1.2.1, 1.2.2, et 1.2.3 de niveau A, les séquences uniquement sonores DOIVENT avoir une transcription textuelle; les séquences uniquement vidéo DOIVENT avoir une transcription ou une piste sonore qui décrit l'information visuelle importante; et les séquences multimédias synchronisées DOIVENT inclure des sous-titres synchronisés, ainsi qu'une transcription en texte intégral ou une description sonore.

    Il est entendu qu'à compter du mois de novembre 2008, la version 2.0 des WCAG demeurera une recommandation possible du W3C. Cependant, cette version devrait devenir une recommandation officielle du W3C en 2009, car elle convient déjà mieux pour l'utilisation des technologies actuelles et elle contribuera à assurer l'accessibilité du produit pour l'avenir. Toute différence entre les versions actuelles et définitives de l'application 2.0 des WCAG sera sans doute mineure et d'incidence minimale.

Amélioration progressive

  • 2.2 Compte tenu de l'approche sur l'amélioration progressive de la conception Web, le premier format de contenu rencontré par un utilisateur DOIT être le format le plus accessible, sauf si la configuration du système de l'utilisateur est compatible avec un contenu présenté dans des formes rehaussées ou en mesure d'accepter ce genre de contenu.

    Nota : Par exemple, dans une situation d'entrevue entre deux (2) personnes, ce genre de contenu pourrait être présenté implicitement à tous les utilisateurs en tant qu'image fixe des deux personnes accessible, accompagnée d'une transcription en texte intégral; d'autre part, si JavaScript a été activé et Flash Player a été installé dans le navigateur d'un utilisateur, l'image implicite pourrait être remplacée de façon dynamique par une bande vidéo sous-titrée Flash de l'entrevue.

  • 2.3 La principale version du produit DOIT être accessible; autrement dit, l'accessibilité du site NE DOIT PAS être accommodée en fournissant une version secondaire du site (p. ex. texte seulement).

Indépendance des scripts

  • 2.4 Le contenu et la fonctionnalité de base du produit DOIVENT être disponibles sans script côté client.

    Nota : Les améliorations de présentation ou de comportement mises en œuvre uniquement par l'entremise des scripts côté client sont permises, mais le contenu et la fonctionnalité de base du produit DOIVENT demeurer disponibles, même si les scripts côté client sont désactivés ou non pris en charge.

Indépendance des feuilles de style en cascade (CSS)

  • 2.5 Le contenu et la fonctionnalité de base du produit DOIVENT être disponibles sans feuille de style en cascade (CSS).

3.0 Répertoires, fichiers et URL

Structure des fichiers et des répertoires

  • 3.1 Les fichiers de produit comportant un important contenu commun pour toutes les versions linguistiques du produit (p. ex. documents XHTML, 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 ils NE DOIVENT PAS être dupliqués pour chaque version linguistique du produit.
  • 3.2 La navigation des répertoires DOIT être désactivée.

Noms de fichiers et de répertoires

  • 3.3 Les noms de fichiers et de répertoires accessibles au public DOIVENT utiliser uniquement les caractères suivants :
    • caractères alphabétiques en minuscules seulement (de a à z);
    • caractères numériques (de 0 à 9);
    • traits d'union (-);
    • traits de soulignement (_).

    Nota : Le trait d'union (-) est un caractère réservé qui NE DOIT PAS être utilisé, sauf comme séparateur entre des mots, phrases ou abréviations bilingues équivalents et le code à trois (3) chiffres ISO-639-2. Les traits d'union naturellement présents dans les mots ou les phrases DOIVENT être omis et l'espace résultante DOIT être supprimée (p. ex. « avant-garde » devient « avantgarde ». Les espaces naturellement présentes dans les phrases DOIVENT être remplacées par un trait de soulignement (_), p. ex. « nouveaux événements » devient « nouveaux_événements ».

  • 3.4 Les noms des répertoires dont le contenu est accessible au public DOIVENT comporter :
    • un mot, une phrase ou une abréviation en français, suivi(e) d'un trait d'union et d'un mot, d'une phrase ou d'une abréviation en anglais; ou
    • un mot ou une abréviation unique qui est identique dans les deux (2) langues officielles.

    Exemples :

    • /histoire-history/
    • /images/
    • /contes_aborigenes-native_stories/
    • /ca-ns/
  • 3.5 Les noms des fichiers dont le contenu est accessible au public DOIVENT comporter :
    • un mot, une phrase ou une abréviation en français, suivi(e) d'un trait d'union et d'un mot, une phrase ou une abréviation équivalent(e) en anglais, suivi(e) d'un trait d'union et du code à trois (3) chiffres ISO-639-2 (p. ex. « fra » et « eng ») pour refléter la version linguistique du fichier; ou
    • un mot ou une abréviation unique qui est identique dans les deux (2) langues officielles, suivi d'un trait d'union et du code à trois (3) chiffres ISO-639-2 (p. ex. « fra » et « eng ») pour refléter la version linguistique du fichier.

    Exemples :

    • index-fra.html
    • index-eng.html
    • entete-header-fra.swf
    • entete-header-eng.swf
    • logo-fra.jpg
    • logo-eng.jpg
    • liste_de_membres-members_list-fra.html
    • liste_de_membres-members_list-eng.html
    • lm-ml-fra.html
    • lm-ml-eng.html
  • 3.6 Les noms des fichiers dont le contenu accessible au public est identique dans les versions française et anglaise du produit (p. ex. certaines images et certains fichiers médiatiques, fichiers JS et CSS) DOIVENT comporter :
    • un mot, une phrase ou une abréviation en français suivi(e) d'un trait d'union et d'un mot, d'une phrase ou d'une abréviation équivalent(e) en anglais;
    • un mot ou une abréviation unique qui est identique dans les deux (2) langues officielles; ou
    • une chaîne numérique ou alphanumérique neutre pour les deux (2) langues officielles.

    Exemples :

    • ferme-farm.jpg
    • artefact.jpg
    • aaD77980017.jpg
    • couleur-colour.css
    • deroulant-pulldown.js
    • intro.swf
  • 3.7 Tous les fichiers XHTML statiques du produit DOIVENT utiliser le suffixe « .html » et ils NE DOIVENT PAS utiliser 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.1 et 4.2) NE DOIVENT INCLURE AUCUN paramètre d'URL (chaîne d'interrogation paire nom-valeur).
URL relatives
  • 3.9 Toute URL pour les pages et les ressources du produit DOIVENT être relatives (c.-à-d. non absolues), sauf pour les URL présentées dans les hyperliens reliant des pages utilisant le protocole SSL vers des pages n'utilisant pas le protocole SSL (voir le paragraphe 1.9).

4.0 Navigation, disposition et conception

Navigation

Navigation dans la version linguistique
  • 4.1 La page implicite dans le répertoire racine 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 (voir le paragraphe 4.2).
  • 4.2 Le produit DOIT comporter une page d'accueil unilingue pour chaque version linguistique du produit.
  • 4.3 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 il DOIT diriger l'utilisateur vers la même page dans l'autre langue.
Navigation dans la page d'accueil
  • 4.4 Chaque page du produit DOIT comprendre un hyperlien vers la page d'accueil unilingue, dans la langue pertinente.

Fenêtres secondaires/flash

  • 4.5 Le produit NE DOIT PAS ouvrir de liens dans de nouvelles fenêtres ou de nouveaux onglets, sauf dans les situations suivantes :
    • L'ouverture d'une page contenant de l'information de contexte délicat (p. ex. instructions d'aide) ou un moyen de rechange pour remplir un champ de formulaire (p. ex. un sélecteur de date basé sur un calendrier), dans la même fenêtre ou le même onglet, pourrait considérablement perturber le flux des travaux à plusieurs étapes (p. ex., remplir et présenter un formulaire).
    • L'ouverture d'une page hors d'une session sécurisée dans la même fenêtre ou le même onglet interromprait ou détruirait la session sécurisée en cours.

    Nota : L'utilisateur DOIT être averti, si un lien ouvre une nouvelle fenêtre ou un nouvel onglet.

Titre du produit

  • 4.6 Chaque page du produit DOIT inclure le titre principal du produit sous forme de texte en XHTML, afin d'identifier le contenu de la page comme faisant partie du produit.

    Nota : Les fichiers ou les images Flash PEUVENT être utilisés pour remplacer la version textuelle en format XHTML du titre principal du produit, mais ils NE DOIVENT PAS empêcher les technologies d'assistance d'accéder au texte remplacé.

Logo du MVC

  • 4.7 Le logo du MVC DOIT figurer dans le coin supérieur droit de chaque page du produit et sans aucune bordure d'image.

    Nota : Le RCIP fournira, sur demande, un exemplaire du logo du MVC. Différentes versions du logo sont disponibles pour assurer une meilleure compatibilité avec les diverses conceptions visuelles.

  • 4.8 Le logo du MVC DOIT être installé à l'aide du code XHTML suivant pour charger le logo et y établir un hyperlien :
    Anglais

    <a href="http://www.virtualmuseum.ca/English/"><img src="chemin/du/fichier/anglais" alt="Virtual Museum of Canada" /></a>

    Français

    <a href="http://www.museevirtuel.ca/Francais/" return false;"><img src="chemin/du/fichier/francais" alt="Musée virtuel du Canada" /></a>

    Nota : Remplacez l'attribut src du code susmentionné par la bon chemin d'accès du fichier pour l'image du logo utilisée dans le produit.

  • 4.9 L'image du logo du MVC NE DOIT PAS faire partie d'une carte-image côté client ou d'une image de fond CSS, sans l'autorisation expresse du RCIP.

Droit d'auteur

Navigation dans la version linguistique
  • 4.10 Le produit DOIT comporter, sous forme de page Web distincte pour chaque version linguistique, une page « Droit d'auteur » qui présente un énoncé de droit d'auteur intégral qui identifie tous les détenteurs de droits d'auteur.
  • 4.11 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.10 ci-dessus), par exemple :

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

    Nota : 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 unilingue dans chaque version linguistique.

Remerciements

  • 4.12 Le produit DOIT avoir une page de « Remerciements », pour laquelle il y a un hyperlien, tant à partir de la page introductive de la sélection linguistique et à chaque page d'accueil unilingue.
  • 4.13 La page des « Remerciements » DOIT reconnaître 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.14 La page des « Remerciements » DOIT nommer tous les partenaires institutionnels participant au produit et y mener par des hyperliens, s'ils sont disponibles.

Mécanisme de rétroaction

  • 4.15 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 une copie conforme 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.

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

  • 4.16 Le mécanisme de rétroaction du produit DOIT être relié à l'interface API anti-pollupostage du RCIP avant la transmission de tout message de rétroaction pour confirmer que ce dernier n'est pas un pourriel ou qu'il provient d'une source douteuse.

    Nota : Le RCIP fournira la documentation relative à son interface API anti-pollupostage aux candidats retenus. Si le produit utilise le formulaire de rétroaction du MVC, la fonctionnalité de l'interface API anti-pollupostage du RCIP y est implicitement incluse.

  • 4.17 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 de protection des renseignements personnels du RCIP pour obtenir 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.18 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.19 Le produit DOIT comprendre, sous forme de page Web distincte pour chaque version linguistique du produit, 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) comportant des hyperliens textuels, par opposition à des hyperliens graphiques ou à des boutons.

    Nota : Pour rehausser la capacité des moteurs de recherche à indexer toutes les pages du produit, il est fortement conseillé d'incorporer une Carte de site en format XML dans le produit.

  • 4.20 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.21 Chaque page du produit DOIT inclure dans sa section head un élément title contenant un titre significatif et riche en mots-clés qui comporte au maximum 60 caractères et qui est unique pour le contenu de cette page.

    Nota : En tant qu'élément de page le plus important d'une perspective d'optimisation de moteur de recherche (OMR), le contenu de l'élément title DEVRAIT être rédigé du plus spécifique au moins spécifique, le titre unique de page apparaissant en premier et le titre principal du produit en dernier (p. ex. « About Dr. Neville | Doctors in the North »).

Élément meta « description »

  • 4.22 Chaque page d'accueil unilingue DOIT inclure dans la section head un élément méta « description » contenant une description significative et riche en mots-clés comportant au maximum 150 caractères et qui décrit globalement le contenu du produit.

    Nota : Si d'autres pages du produit comprennent un élément méta « description », ce dernier DOIT être spécifique et unique pour le contenu de la page.

Élément meta « keywords »

  • 4.23 Les pages du produit PEUVENT, sans toutefois y être tenues, inclure dans la section head un élément méta « keywords » contenant une liste de mots clés et phrases clés qui DOIVENT être spécifiques et uniques pour le contenu de la page.

Bannières, en-têtes et bas de page

  • 4.24 Le produit NE DOIT PAS utiliser d'outils de navigation de sites Web corporatifs ou institutionnels, notamment les bannières, les en-têtes ou les bas de page, sans l'approbation expresse du RCIP.

Cybermétrie

  • 4.25 Si le produit ne sera pas hébergé sur le serveur du RCIP, chaque page du produit DOIT inclure un fichier spécial JavaScript et un élément noscript fournis par le RCIP et développés pour recueillir les statistiques de visiteur pour le produit.

    Nota : Le RCIP fournira, aux candidats retenus, le fichier JavaScript spécifique au produit, le code pour l’élément noscript, ainsi que des instructions explicites pour leur implémentation. Si le produit sera hébergé sur le serveur du RCIP, la collecte des statistiques de visiteur pour le produit sera implicitement activée et aucun fichier supplémentaire JavaScript, ni élément noscript, ne sera exigé.

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.1Le module ou le logiciel spécialisé pour présenter le contenu DOIT être librement accessible et pouvoir être installé sur n'importe quelle plateforme (p. ex. Windows, Mac et Linux).

    Nota : Par exemple, étant donné que Windows Media Player 10 ne fonctionne pas naturellement sur les plateformes Mac ou Linux, des instructions supplémentaires sont fournies pour le téléchargement d'un diffuseur de médias équivalent pour les plateformes Mac et Linux ou un module d'extension et un logiciel spécialisé qui sont compatibles avec les trois (3) plateformes sont suggérés, p. ex. VLC.

  • 5.2 Le contenu nécessitant un module d'extension ou un logiciel spécialisé DOIT être accompagné d'une indication textuelle du format, du type de fichier et de la taille du fichier.
  • 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 Tout le contenu textuel DOIT être présenté principalement en tant que texte dans la variante XHTML 1.0 Strict.

    Nota: Bien que tout contenu textuel DOIT être affiché en format XHTML, pareil contenu PEUT également être élaboré dans un format breveté pour visualisation ou impression au moyen d'un module d'extension librement accessible à l'aide de toutes les plateformes. 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, et qui est disponible pour toutes les plateformes.

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 :
    • Les graphiques vectoriels DOIVENT utiliser les formats GIF ou PNG.
    • Les photographies, la haute résolution et les images en demi-teintes DOIVENT utiliser le format JPEG (à 24 bits).

    Nota: 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 à 100 Ko DOIT être accompagné d'une indication textuelle précisant la taille des fichiers afin d'alerter les utilisateurs.
  • 5.7 Les pages du produit NE DOIVENT PAS initier le téléchargement de fichiers d'images pleine taille, sauf si l'utilisateur le demande expressément.

    Nota: Cette exigence vise à limiter la création de pages comportant des vignettes et d'autres versions pleine taille associées qui sont camouflées par les feuilles CSS jusqu'à ce que l'utilisateur mette au point la vignette. Ces pages sont habituellement de très grande taille et elles exigent une plus grande largeur de bande, ce qui oblige l'utilisateur à télécharger du contenu pour lequel il n'a pas nécessairement exprimé d'intérêt.

Vidéos/images mobiles

  • 5.8 La taille d'un fichier vidéo NE DOIT PAS excéder 4 Mo.
  • 5.9 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.

    Nota: 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 obtenir de plus amples renseignements, veuillez communiquer avec le RCIP.

  • 5.10 Les fichiers vidéo 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 la vidéo.
  • 5.11 Les fichiers de diffusion vidéo non séquentielle qui sont chargés dans un lecteur intégré à un navigateur DOIVENT être accompagnés d'un hyperlien direct aux fichiers vidéo comme tels, permettant ainsi aux utilisateurs d'y avoir accès, sans avoir à compter sur le lecteur intégré à un navigateur.
  • 5.12 Tout hyperlien vers de gros fichiers vidéo transmis en continu DOIT être accompagné d'une étiquette indiquant la durée du fichier en continu.
  • 5.13 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. En plus, un hyperlien vers le codec DOIT être fourni aux utilisateurs.

Fichiers audio ou sonores

  • 5.14 La taille d'un fichier audio NE DOIT PAS excéder 4 Mo.
  • 5.15 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.

    Nota: 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 obtenir de plus amples renseignements, veuillez communiquer avec le RCIP.

  • 5.16 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.17 Les fichiers de diffusion vidéo non séquentielle qui sont chargés dans un lecteur intégré à un navigateur DOIVENT être accompagnés d'un hyperlien direct aux fichiers vidéo comme tels, permettant ainsi aux utilisateurs d'y avoir accès, sans avoir à compter sur le lecteur intégré à un navigateur.
  • 5.18 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.19 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 ont besoin de le télécharger et de l'installer. En plus, un hyperlien vers le codec DOIT être fourni aux utilisateurs.

Fichers d'animation

  • 5.20 La taille d'un fichier d'animation (p. ex. animation Flash) NE DOIT PAS excéder 4 Mo.
  • 5.21 Tout hyperlien vers un gros fichier d'animation (p. ex. animation Flash) de taille supérieure à 100 Ko DOIT être accompagné d'une étiquette indiquant la taille du fichier.
  • 5.22 Tous les fichiers d'animation (p. ex., animations Flash) qui comptent plus de 25 Ko, tandis qu'ils se téléchargent dans l'application client (p. ex., Flash Player), DOIVENT être dotés d'un indicateur d'avancement qui est continuellement mis à jour (« préchargeur »), et qui affiche le degré auquel le fichier a été téléchargé.

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, 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 :
    • les pages d'accueil unilingues du produit;
    • la page principale de chaque section majeure du produit;
    • la page principale de chaque section majeure du produit
    • les pages qui mettent en vedette des ressources de contexte et sens suffisant et qui méritent d'être énumérées dans un moteur de recherche.

    Le contenu des métadonnées DC pour les pages ou ressources anglaises DOIT être en anglais et le contenu des métadonnées pour les pages françaises DOIT être en français.

Mise en place des métadonnées DC

Métadonnées DC uniques

  • 6.3 Chaque page décrite par des métadonnées DC DOIT mettre en évidence un ensemble unique de métadonnées.

    Nota: La pratique de copier et coller le même contenu de métadonnées est inacceptable. Deux (2) pages Web ne devraient jamais avoir le même identificateur, titre ou objet.

7.0 Spécifications techniques de serveur et de la 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 DOIVENTutiliser le suffixe « .html ».
    CGI et PERL
    • Les scripts CGI DOIVENT utiliser 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 DOIVENT par la notation « shebang » suivante :

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

    PHP
    • PHP 5.2.2 est activée.
    • Les scripts PHP DOIVENT utiliser le suffixe « .php ».
    • Les scripts PHP PEUVENT être situés n'importe où dans la structure de répertoires du projet.
    • La ligne register_globals est réglée à « OFF » (désactivée)
    • 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)
    • Toute page XHTML ayant le suffixe « .html » et le 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 interdit 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.

    Nota: Tout produit qui ne sera pas hébergé sur le serveur du RCIP DEVRAIT être développé conformément aux spécifications d'environnement du serveur du RCIP, car le produit pourrait en bout de ligne y être hébergé.

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 constraints DOIVENT être validés pour garantir que leurs valeurs se situent dans ces ensembles constraints.
    • 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 générés de façon dynamique NE DOIVENT CONTENIR AUCUNE apostrophe non échappée.
    • 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.

    Nota: 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 des 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 une fois seulement dans un fichier à l'extérieur du répertoire racine du produit auquel le serveur Web n'a pas accès.
SGBD
  • 7.4 Pour tout produit qui emploie une base de données et qui 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.

    Nota: 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 Pour tout produit qui emploie une base de données et qui 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'un tableau relationnel particulière DOIVENT dépendre fonctionnellement de la clé principale.

    Nota: Dans le modèle de données logiques, une clé candidate formée d'attributs réels DEVRAIT 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 tableaux PEUVENT être dénormalisés en modèles de données physiques pour des raisons de rendement, mais ces exceptions DOIVENT être justifiées par des preuves quantitatives (p. ex. Dans quelle mesure la structure dénormalisée est-elle plus rapide?).

Normes de dénomination
  • 7.6 Pour tout produit qui emploie une base de données et qui doit être hébergé sur le serveur du RCIP, les normes de dénomination de base de données suivantes DOIVENT être observées :
    • Les bases de données DOIVENT avoir tant un nom descriptif qu'une abréviation assez courte (maximum de 5 caractères).
    • Les tableaux DOIVENT avoir tant un nom descriptif préfixé avec l'abréviation de leur base de données qu'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 tableau.
    • 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 du tableau, puis du nom de chaque champ participant à l'index.
    • Les noms des déclencheurs DOIVENT commencer par un « T », suivi d'un « B » (avant) ou d'un « A » (après) pour indiquer le temps, puis d'un « D » (supprimer), d'un « I » (insérer) ou d'un « U » (mettre à jour) pour indiquer l'événement de déclenchement, et enfin du nom du tableau.
Dictionnaire de données
  • 7.7 Pour tout produit qui emploie une base de données et qui doit être hébergé sur le serveur du RCIP, tous les éléments de la base de données (base de données, tableau, 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 implicite.

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

  • 7.8 Pour tout produit qui emploie une base de données et qui 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