Affaires étrangères, Commerce et Développement Canada
Symbole du gouvernement du Canada

Affaires étrangères, Commerce et Développement Canada

international.gc.ca

Document archivé

L'information archivée sur le Web est disponible à des fins de consultation, de recherche ou de tenue de dossiers seulement. Elle n’a été ni modifiée ni mise à jour depuis sa date d’archivage. Les pages archivées sur le Web ne sont pas assujetties aux normes Web du gouvernement du Canada. Conformément à la Politique de communication du gouvernement du Canada, vous pouvez obtenir cette information dans un format de rechange en communiquant avec nous.

Vérification de la gestion de l'intranet - AEC

(Janvier 2006)

Table des matières

Résumé

Conclusion

La vérification dont rendent compte les présentes a été approuvée par le Comité ministériel de la vérification et de l'évaluation pour l'année 2004-2005 et a été effectuée entre le 1er novembre 2004 et le 22 mars 2005. Au cours des consultations annuelles menées auprès des cadres supérieurs dans le contexte de l'exercice de planification des vérifications ministérielles, l'agent d'information en chef a déterminé que l'intranet était un secteur de préoccupation important pour la direction.

Dans l'ensemble, nous croyons que le présent rapport aidera la direction à mieux comprendre l'intranet et à mieux exploiter cet outil de communication ministériel. Ce rapport comporte des recommandations claires qui devront être prises en considération pour établir le montant des dépenses futures à engager pour l'intranet. De façon générale, la vérification nous a permis de constater qu'AEC ne tirait pas un rendement maximal de son investissement dans l'intranet.

La vérification a révélé que le cadre de gestion global appliqué à la gouvernance de l'intranet d'AEC n'avait pas d'orientation stratégique claire. La présence de contenu inexact et périmé dans certains sites internes d'AEC a miné la confiance des utilisateurs dans l'ensemble du contenu de l'intranet. Il faudra améliorer les processus et les contrôles de qualité pour la gestion, la maintenance et la suppression du contenu publié dans l'intranet d'AEC.

La vérification a également mis en lumière le fait que les utilisateurs n'étaient pas très au courant du contenu offert dans l'intranet d'AEC. De plus, nous avons constaté que beaucoup de sites intranet d'AEC n'étaient pas structurés et étaient difficiles à explorer. Les moteurs de recherche sont inefficaces et décevants, et la capacité utile du réseau dans certaines missions ne suffit pas à assurer l'accès à l'information. Quelques missions (mentionnons celles de Paris, de Londres et de Washington) possédaient des sites intranet non conformes à la politique en matière de langues officielles. La vérification a aussi soulevé des questions liées à la sécurité, à la consolidation des technologies et des applications intranet, ainsi qu'au suivi des coûts de propriété.

Par suite de la vérification, nous recommandons au Ministère de mettre sur pied une structure de gouvernance, d'arrêter une stratégie pour l'intranet, d'implanter des normes relatives au contenu et des contrôles de qualité connexes, d'améliorer la fonctionnalité de recherche, de veiller à ce que les missions disposent d'une capacité utile suffisante pour l'utilisation de l'intranet, et d'atténuer les risques de sécurité associés au contenu de l'intranet. Nous recommandons en outre que DMA confie à la Direction générale des communications (BCD) la responsabilité de gérer l'intranet. Pour donner suite à ces recommandations, nous privilégions la formation d'un comité directeur et d'un comité éditorial pour l'intranet. Les auteurs du rapport présument que le Bureau de l'agent d'information en chef (AIC) participera de façon continue à tous les aspects de la nouvelle structure de gouvernance de l'intranet.

Au cours des séances d'information sur la vérification, nous avons appris que le Ministère avait déjà pris des mesures concrètes pour définir un cadre qui permettra de mettre en oeuvre les principaux éléments du rapport. Compte tenu de l'envergure de l'entreprise, l'application des recommandations devra être progressive et adaptée aux contraintes opérationnelles des propriétaires de contenu.

Objectifs

La vérification avait les objectifs suivants :

  • Évaluer le cadre global de gestion pour la gouvernance de l'intranet;
  • Évaluer l'efficience et l'efficacité de l'intranet à répondre aux besoins des utilisateurs;
  • Évaluer le respect des normes et des politiques en matière de disponibilité et d'intégrité;
  • Déterminer et promouvoir les pratiques exemplaires observées.

Critères de vérification

La vérification a été faite en conformité avec la Politique sur la vérification interne du Conseil du Trésor ainsi que les exigences et les lignes directrices énoncées dans les Normes pour la pratique professionnelle de l'audit interne de l'Institut des vérificateurs internes (IVI).

Les critères de vérification étaient fondés sur les exigences pertinentes de COBIT Note 1, de même que les politiques et les procédures du Ministère et du Secrétariat du Conseil du Trésor. Les travaux de vérification réalisés sont suffisants et les éléments de preuve nécessaires ont été recueillis pour appuyer les conclusions exposées dans le présent rapport de vérification.

Principaux points soulevés

On peut regrouper les résultats de la vérification dans les catégories suivantes :

  1. Gouvernance et cadre de gestion global
  2. Efficience et efficacité de l'intranet
  3. Respect des normes en matière de disponibilité et d'intégrité
    • La vérification portait aussi sur les pratiques exemplaires et, plus particulièrement, sur les points forts qui pourraient être communiqués aux intervenants des deux ministères. De plus, les pratiques exemplaires de COBIT Note 2 et de la BITI Note 3 sont présentées à l'Annexe C.

Gouvernance et cadre de gestion

Rôles et responsabilités

  • Il n'existe pas de comité directeur, au niveau de la direction, qui soit explicitement chargé d'élaborer des stratégies et des politiques, et de veiller à ce que celles-ci soient mises en oeuvre. Par conséquent, les intervenants travaillent en vase clos et prennent des décisions qui ne tiennent pas compte de l'ensemble, ce qui entraîne une réduction globale de l'efficacité opérationnelle.
  • Aucune stratégie ne relie les objectifs globaux du Ministère aux objectifs concernant l'intranet, ni aux politiques de gestion du contenu de l'information et aux politiques relatives à l'infrastructure de l'intranet. Ce manque d'orientation est à l'origine de beaucoup d'autres problèmes relevés durant la vérification. Il complique de surcroît la résolution de ces problèmes par la structure de direction actuelle.
  • Le manque de clarté de l'objet et du rôle fondamentaux de l'intranet d'AEC se traduit par des conceptions et des interprétations divergentes par les cadres et le personnel, ce qui donne lieu à une mauvaise utilisation des ressources due à des activités redondantes et des conflits, et fait que les besoins des utilisateurs ne sont pas toujours comblés.
  • Afin de réagir concrètement aux principales constatations découlant de la vérification, le Ministère doit confier à la Direction générale des communications (BCD) la responsabilité de gérer le contenu de l'intranet. Pour donner suite aux recommandations formulées, le Ministère devra former un comité directeur, au niveau de la direction, ainsi qu'un comité éditorial, au niveau opérationnel. Les auteurs du présent rapport présument que le Bureau de l'agent d'information en chef (AIC) participera de façon continue à tous les aspects de la nouvelle structure de gouvernance de l'intranet.

Gestion du contenu

Le contenu de l'intranet d'AEC n'est régi par aucune ligne directrice ni aucun contrôle uniforme sur le plan opérationnel. Il existe des écarts importants entre les sites intranet et les environnements de développement, qui engendrent des inefficacités, irritent les utilisateurs et entraînent à la hausse les coûts de soutien.

Coût de propriété

Bien qu'on dispose de certains renseignements empiriques sur le suivi des coûts, il reste que, dans l'ensemble, le Ministère ne connaît pas les coûts liés à la gestion de l'intranet ainsi qu'à la publication, à la gestion et au retrait du contenu. Par conséquent, il s'avère que la gouvernance de l'intranet s'effectue en l'absence de renseignements clés à l'appui des décisions de gestion. La vérification a fait ressortir des secteurs où l'on pourrait réaliser des gains d'efficacité et réduire les coûts en harmonisant les technologies et les environnements de développement d'applications.

Efficience et efficacité de l'intranet

Mécontentement des utilisateurs

Les sites intranet d'AEC ne répondent pas aux besoins des utilisateurs, renferment du contenu peu fiable, sont privés de canaux de rétroaction et ont des apparences différentes et des dispositions inhabituelles. Dans l'ensemble, le contenu intranet d'AEC est très peu uniforme, et l'accès à ce contenu est inefficace. De nombreux utilisateurs se sont plaints et ont fait part de leur déconvenue.

Structure et utilisabilité du site Web Panorama

Sous sa forme actuelle, la page d'accueil principale d'AEC - celle du site Web Panorama - est généralement considérée comme étant mal structurée, difficile à parcourir et peu conviviale. De plus, son contenu fait double usage, en grande partie, avec les messages électroniques diffusés. Il s'agit d'un outil inefficient et inefficace pour accéder aux renseignements d'AEC.

Efficacité des moteurs de recherche

La configuration des moteurs de recherche de l'intranet est inefficace. L'intranet renferme plusieurs moteurs de recherche distincts, non intégrés, qui sont implantés de façon non uniforme. Il en résulte, pour les utilisateurs, un fonctionnement lent, des résultats inexacts et un sentiment général de frustration. Les utilisateurs sont dès lors enclins à utiliser des moyens moins efficaces pour trouver l'information dont ils ont besoin, par exemple à faire des recherches manuelles ou dans des ouvrages sur papier, ou encore à s'adresser à des personnes-ressources.

Technologies et environnements de développement d'applications intranet

Il peut être possible de réduire le coût du développement des applications intranet par l'harmonisation des technologies et des environnements de développement d'applications.

Disponibilité de l'intranet pour les missions

Dans certaines missions, les employés sont incapables de se servir des applications et des outils de travail de l'intranet qui sont destinés à accroître la productivité, à cause de la capacité utile restreinte du réseau. La capacité utile est fonction de la rapidité du lien avec le réseau, des applications employées, des habitudes d'utilisation et de la mise au point des applications et du réseau. Le rapport de vérification comprend des recommandations qui permettront de lever les obstacles à cet égard et de rehausser l'utilisation de l'intranet dans les missions sans entraîner de coûts supplémentaires liés à l'augmentation de la largeur de bande.

Sécurité de l'intranet

L'absence de contrôles de qualité appliqués au matériel publié dans l'intranet fait croire à la direction que des renseignements de nature délicate risquent d'avoir été diffusés dans l'intranet et de compromettre, individuellement ou collectivement, la sécurité.

Respect des normes en matière de disponibilité et d'intégrité

L'intégrité du contenu de certains sites Web examinés est faible, ce qui a pour effet d'exacerber les problèmes d'efficience et d'efficacité décrits ailleurs dans ce rapport. Le contenu inexact et périmé publié dans certains sites intranet d'AEC a contribué à créer chez le personnel un scepticisme généralisé quant à la fiabilité de tout le réseau intranet. L'accès au contenu de l'intranet a également souffert de l'absence de modèles pour la disposition de pages et de mécanismes de navigation largement acceptés, ainsi que des moteurs de recherche qui ne fonctionnent tout simplement pas.

Méthode de vérification

Les vérifications sont effectuées dans le but d'assurer la direction que les objectifs de contrôle sont atteints, de faire ressortir les faiblesses importantes sur le plan du contrôle, de quantifier les risques qui en découlent et de conseiller la direction quant aux mesures correctives qui s'imposent.

Contexte

L'intranet d'Affaires étrangères Canada (AEC) et de Commerce international Canada (CICan) est un outil ministériel destiné à diffuser par voie électronique les communications, les outils et les services ministériels à tous les employés de l'Administration centrale et des missions. L'intranet a été mis en place afin de créer un canal de communication interne rentable et convivial. À l'origine, le site intranet était développé par la Direction générale de la gestion de l'information et de la technologie. L'intranet sert à diffuser des documents, comme les manuels et directives des ministères, et les messages pour diffusion générale de Panorama, ainsi qu'à héberger les sites des directions. Il donne aussi accès à des outils tels que l'annuaire ministériel en ligne et à des services au moyen d'applications comme le système de gestion des ressources humaines (PeopleSoft). L'intranet est fondé sur des outils de type Internet (World Wide Web), mais il réside dans le réseau interne SIGNET.

Le contenu de l'intranet n'appartient pas à la Direction générale de la gestion de l'information et de la technologie, et l'instauration d'un site intranet n'est contrôlée par aucun organisme centralisé d'approbation au sein des ministères. Au cours des consultations annuelles menées auprès des cadres supérieurs, l'agent d'information en chef a déterminé que l'intranet était un secteur de préoccupation important pour la direction et, plus particulièrement, qu'il y avait des problèmes de gouvernance, d'exactitude ou d'actualité du contenu et de coûts permanents qui devraient être réglés. En outre, la séparation d'AEC et de CICan en deux ministères a mis au jour la nécessité d'entreprendre une vérification exhaustive de l'intranet.

1.1 Portée

La vérification concernait l'intranet d'AEC et celui de CICan. Elle a porté sur les domaines suivants :

  • Gouvernance et cadre de gestion global;
  • Satisfaction des utilisateurs et besoins opérationnels;
  • Coûts de propriété permanents;
  • Exactitude et actualité du contenu;
  • Disponibilité et intégrité des systèmes.

1.2 Méthodologie

La vérification comprenait les extrants et les activités principales ci-dessous :

  • Plan de projet : Plan de projet détaillé précisant les extrants, les jalons et l'utilisation des ressources
  • Sélection des entités vérifiées et coordination des entretiens : Entretiens prévus et menés avec 32 entités vérifiées
  • Établissement du programme de vérification : Élaboration et mise en application d'un guide de vérification associant les critères de vérification aux objectifs de la vérification
  • Conception des questions pour les entretiens : Élaboration et utilisation de questions fondées sur les objectifs et les critères de vérification
  • Entretiens avec les entités vérifiées : Tenue et documentation d'entretiens pour la vérification
  • Analyse technique : Utilisation d'un outil automatisé d'analyse de sites Web pour obtenir des données techniques précises et mesurer la performance de l'intranet
  • Séances d'information à l'intention de la direction : Présentation des résultats et des recommandations de la vérification et tenue de notes d'information
  • Rapport de vérification : Rédaction d'un rapport provisoire faisant état des secteurs de préoccupation et faisant ressortir clairement les liens entre les observations, les causes et leurs effets, et les recommandations formulées
  • Documents de travail : Rédaction et tenue de documents de travail, de notes sur les entretiens, et de documents d'analyse en format électronique

1.3 Technique d'échantillonnage et analyse technique

Nous avons opté pour une approche d'échantillonnage structurée afin de nous assurer que l'échantillon choisi soit réellement représentatif de l'ensemble des intervenants, des propriétaires de contenu, des utilisateurs et des techniciens. Bien que la vérification n'ait pas fait appel à un grand nombre de gestionnaires ou d'employés, nous avons complété les entretiens par l'utilisation d'outils électroniques qui nous ont permis de soumettre les sites intranet à des tests qu'il ne serait pas possible d'effectuer manuellement.

Nous avons utilisé le logiciel « Watchfire », un outil automatisé d'analyse de sites Web, pour obtenir certaines données techniques et mesurer la performance de l'intranet. Nous avons ainsi répertorié les liens morts et vérifié l'efficacité des moteurs de recherche. Des rapports détaillés de Watchfire ont été produits pour le serveur intranet principal; les résultats de cet examen sont présentés dans la section 3.0 du présent rapport.

Les 96 sites Web examinés au cours de la vérification résidaient dans les 8 serveurs de l'Administration centrale illustrés dans le diagramme général du réseau fourni ci-dessous :

Diagramme général des 8 serveurs de l'Administration centrale illustrés dans le diagramme général du réseau

1.4 Entretiens

Nous avons conduit des entretiens approfondis avec un échantillon de responsables, d'utilisateurs, de propriétaires de contenu, de webmestres et de cadres des directions et des ministères. Certaines personnes interrogées jouaient plusieurs rôles relativement à l'intranet (p. ex., webmestre et utilisateur), et elles ont donc été questionnées en fonction de ces rôles multiples.

La liste des personnes interrogées est reproduite à l'Annexe A.

Le serveur principal, lbpis02, renfermait la plupart des sites intranet vérifiés, y compris la page d'accueil du site Panorama, qui était (au moment de la vérification) le site intranet principal d'Affaires étrangères Canada. De nombreux sites intranet sont consultés à partir de liens figurant dans la page d'accueil du site Panorama, et certains de ces sites résident dans d'autres serveurs du réseau. Le serveur intranet principal (lbpis02) héberge en outre cinq sites de missions (Beyrouth, Bruxelles, Belgrade, Manille et Oslo). La vérification a aussi porté sur les sites de cinq autres missions hébergés dans différents serveurs (Tokyo, New Delhi, Washington, Londres et Paris), et deux autres sites hébergés dans deux autres serveurs de l'intranet.

Le tableau ci-dessous montre le nombre de sites vérifiés dans chacun des serveurs.

Tableau 1 : Le nombre de sites vérifiés dans chacun des serveurs
ServeurURLFonction principaleSites au total
Total96
lbpis02http://intranetPanorama ET autres sites70
lbpk01http://corpappsEQAMS, PubReg, annuaire3
160.106.180.189http://hrms-sgrh.dfait-maeci.gc.caPeopleSoft1
lbpcat01http://lbpcat01.cappsCATS, bibliothèque technique1
lbpk06http://notespub01.dfait-maeci.gc.caConcours, BDD sur les politiques d'achat2
albertprhttp://srdwebBiens, matériel, messagerie1
lbpkz02 (sur Internet)http://pubx.dfait-maeci.gc.caCatalogue des publications1
lbpis04http://intranetappsDiverses applications17

 

1.5 Planification et contrôle

Nous avons élaboré un plan de vérification exhaustif définissant toutes les activités de vérification, de même que le calendrier d'exécution. Le déroulement de la vérification a été suivi au moyen de réunions d'équipe hebdomadaires et de rapports d'étape diffusés toutes les deux semaines. Les réunions ont donné l'occasion à l'équipe de vérification de tirer parti des connaissances institutionnelles et des conseils de ZIV.

Résultats détaillés

1.1 Gouvernance de l'intranet

Il n'existe pas de comité directeur, au niveau de la direction, qui soit explicitement chargé d'élaborer des stratégies et des politiques, et de veiller à ce que celles-ci soient mises en oeuvre. Par conséquent, les intervenants travaillent en vase clos et prennent des décisions qui ne tiennent pas compte de l'ensemble, ce qui limite l'efficacité de l'intranet.

Aucune stratégie ne relie les objectifs globaux du Ministère aux objectifs concernant l'intranet, ni aux politiques de gestion du contenu de l'information et aux politiques relatives à l'infrastructure de l'intranet. Ce manque d'orientation est à l'origine de beaucoup d'autres problèmes relevés durant la vérification et complique la résolution de ces problèmes.

Le manque de clarté de l'objet et du rôle fondamentaux de l'intranet d'AEC se traduit par des conceptions et des interprétations divergentes par les cadres et le personnel, ce qui donne lieu à une mauvaise utilisation des ressources due à des activités redondantes et des conflits, et fait que les besoins des utilisateurs ne sont pas toujours comblés.

Bon nombre de propriétaires de contenu de l'intranet ont souligné la nécessité de constituer un comité directeur de l'intranet qui serait chargé de définir une vision et une stratégie pour l'intranet. On nous a suggéré que l'énoncé de la vision devrait préciser l'objet de l'intranet et décrire comment le contenu de l'intranet peut contribuer à l'atteinte des objectifs du Ministère.

La mauvaise compréhension du rôle et de l'objet de l'intranet d'AEC a eu pour effet de compliquer l'établissement des priorités, d'entraîner la prise de décisions inefficaces et de créer d'importants écarts dans la qualité du contenu de l'intranet d'AEC. Bien que l'infrastructure de l'intranet fonctionne efficacement, le contenu (matériel) n'est pas employé de façon efficace pour appuyer les communications internes.

Faute de rôle et d'objet définis, les décisions concernant l'intranet risquent d'être fondées sur des priorités floues, et des ressources risquent d'être consacrées à des initiatives qui n'auront pas pour effet d'accroître l'efficience et l'efficacité de l'intranet d'AEC à titre d'outil de communication ministériel. Cependant, le simple fait de définir le rôle et l'objet de l'intranet ne produira pas d'avantages si le rôle et l'objet ne sont pas communiqués clairement aux gestionnaires et aux employés qui effectuent des tâches liées à l'intranet.

Il faudra arrêter une stratégie générale qui définit clairement le rôle et l'objet de l'intranet à titre d'outil de communication ministériel. La communication pourra se faire entre personnes, entre ministères, entre les ministères et les personnes, entre les gestionnaires et le personnel, etc. La stratégie et la structure de gouvernance applicables à l'intranet doivent comporter les éléments suivants :

  • la vision ministérielle du rôle de l'intranet à titre d'outil de communication;
  • les rôles et les responsabilités associés à l'intranet et à son contenu, y compris les responsabilités relatives à l'infrastructure;
  • les politiques et les procédures concernant la publication, la maintenance et le retrait de contenu;
  • les normes et les lignes directrices en matière de conception pour l'intranet dans l'optique des objectifs de communication;
  • les priorités et l'importance relative des priorités techniques par rapport aux priorités concernant les utilisateurs et les communications;
  • les pratiques en matière de contrôle et d'assurance de la qualité (révisions, approbateurs, etc.).

La Direction générale des communications (BCD) gère actuellement le site Internet du Ministère. À l'instar du site Internet, l'intranet du Ministère devrait être géré par des spécialistes des communications d'AEC. Les auteurs du présent rapport présument que le Bureau de l'agent d'information en chef (AIC) participera de façon continue à tous les aspects de la nouvelle structure de gouvernance de l'intranet.

On a toutefois constaté que le rôle et l'objet du site intranet Horizons étaient clairement établis. Son mandat consiste à appuyer le personnel de CICan sur le terrain au moyen de contenu « utilisable et exploitable ». Ses politiques et ses normes sont définies par un comité d'intervenants, et des contrôles de qualité sont mis en oeuvre par l'équipe d'Horizons. La vérification nous a permis d'observer que le contenu du site Horizons était actuel, adapté aux besoins des utilisateurs et largement utilisé par les employés du Service des délégués commerciaux.

Nous recommandons :

1.1.1 Que DMA confie la gestion de l'intranet à BCD et reconnaisse ainsi que l'intranet est un outil de communication ministériel;

1.1.2 Que BCD constitue un comité directeur de l'intranet, formé d'intervenants de la direction et représentant tous les secteurs, qui sera chargé de définir :

  • le rôle et l'objet de l'intranet à titre d'outil de communication ministériel;
  • la politique relative à la gouvernance opérationnelle;
  • la politique relative à la gestion du contenu;
  • la politique relative aux normes de conception.

Mesures et délais d'exécution

1.1.1 DMA est d'accord. La responsabilité de gérer l'intranet a été confiée à BCD au cours de la réunion du Comité de gestion tenue le 20 avril 2005. Le Comité de gestion a également signifié son accord avec les points suivants :

  • la nécessité d'une stratégie pour l'intranet - et d'une structure de gouvernance;
  • la nécessité d'un comité directeur de l'intranet, au niveau de la direction;
  • la nécessité pour BCD de prendre le rôle de leader, plutôt que d'exploitant;
  • la nécessité d'un exercice de nettoyage, qui doit être entrepris rapidement et être mené en communiquant avec les utilisateurs, les propriétaires de contenu et les fournisseurs de technologie. La vérification a permis de déceler un certain nombre de sites orphelins. Avant de supprimer ceux-ci, et d'autres éléments de contenu, il faudra effectuer les analyses pertinentes sous la direction d'un comité éditorial.

Délai d'exécution : Le Comité de gestion a demandé au SCMA d'estimer globalement les ressources qui seraient nécessaires pour le remaniement de l'intranet.

Réaction de BCD : BCD a accepté de prendre la responsabilité de gérer l'intranet et le contenu d'AEC.

Délai d'exécution de BCD : Dépendra des ressources affectées.

1.1.2 Un comité directeur coprésidé par CICan et AEC a été formé et une ébauche de mandat a été rédigée. Les exigences supplémentaires relatives à la représentation seront déterminées de concert avec l'AIC après l'approbation du mandat.

Délai d'exécution : Mandat achevé le 15 décembre 2005.

1.2 Gestion du contenu de l'intranet

Le contenu de l'intranet d'AEC n'est régi par aucune orientation ni aucun contrôle uniforme sur le plan opérationnel, ce qui donne lieu à des écarts considérables entre les sites et les environnements de développement. Les écarts entre les sites entraînent l'inefficacité et le mécontentement des utilisateurs, tandis que la variété des environnements de développement donne lieu à des inefficacités économiques.

Le contrôle de la qualité a une portée limitée, et le respect des lignes directrices en vigueur pour la conception de sites Web est inégal. De ces deux facteurs découlent d'importants écarts entre les sites intranet. Par ailleurs, le manque de clarté des normes concernant la disposition et l'apparence des sites intranet d'AEC nuit à l'efficacité des utilisateurs, car ceux-ci perdent du temps à s'habituer aux modes de navigation, à l'organisation des sites et à l'apparence des pages, qui varient considérablement. Beaucoup d'utilisateurs ont suggéré qu'il faudrait appliquer une structure et une apparence communes à tous les sites de l'intranet d'AEC, dans le but d'aplanir la courbe d'apprentissage et de rehausser l'utilisabilité. L'efficacité des utilisateurs est atteinte quand ces derniers doivent se familiariser avec de nouvelles dispositions de sites. De même, les coûts de développement sont gonflés, car il faut consacrer du temps à la conception des nouvelles dispositions.

Les webmestres ne respectent pas les lignes directrices en vigueur en matière de style, car ils les considèrent inadéquates ou non conformes aux conventions courantes d'Internet. Cependant, on aurait raison de s'attendre à ce que les sites intranet des directions d'AEC suivent des normes quant à l'apparence. Voici un aperçu des écarts observés entre les sites intranet :

Aperçu des écarts observés entre les sites intranet

Le même degré de variation s'observe dans les sites intranet des missions, y compris les sites hébergés dans le serveur principal de l'intranet :

Variation ovserve dans les sites intranet des missions

Les critères et les contrôles de gestion appliqués à la publication de contenu dans l'intranet d'AEC sont inadéquats. De plus, les responsabilités concernant l'établissement des contrôles de gestion et la vérification de la conformité ne sont pas définis et mis en oeuvre de façon efficace. Sans critères et sans contrôles de gestion clairement définis pour régir la publication de contenu dans l'intranet, il est difficile de veiller à l'application uniforme des protocoles ministériels pertinents.

Le Ministère profiterait de la mise sur pied d'un comité éditorial chargé de l'intranet. Le mandat de ce comité consisterait :

  • à définir des politiques relatives à la gestion du contenu des sites intranet;
  • à établir des règles opérationnelles pour le contenu de l'intranet;
  • à veiller à la conformité avec les règles établies.

Ce comité serait constitué de webmestres et de propriétaires de contenu (ou de leurs représentants) provenant des directions qui possèdent beaucoup de contenu dans l'intranet d'AEC. Dans ses travaux d'élaboration et de mise en oeuvre de politiques et de normes, le comité éditorial devra tenir compte des contraintes de temps et de budget des propriétaires de contenu de l'intranet. Une mise en oeuvre progressive est à privilégier.

Nous recommandons :

1.2.1 Que BCD instaure un comité éditorial pour l'intranet.

Mesures et délais d'exécution

1.2.1 Le cadre régissant le comité éditorial de l'intranet est en cours de rédaction et sera présenté au comité directeur quand le mandat aura été accepté par BCD, CSM et l'AIC.

Délai d'exécution : Exécution en cours, sous réserve de l'approbation du mandat.

1.3 Coût de propriété

Le coût de propriété, qui découle de la gestion, de la publication, de la maintenance et du retrait de contenu dans l'intranet, ne fait l'objet d'aucun suivi. Par conséquent, la gouvernance de l'intranet est privée d'un élément d'information clé (les coûts de gestion du contenu) qui éclairerait les décisions de gestion.

La haute direction s'est dite intéressée à connaître les coûts de propriété de l'intranet, car ceux-ci l'aideraient à mieux justifier et optimiser l'utilisation des ressources. Toutefois, les entretiens réalisés dans le cadre de la vérification nous ont clairement montré qu'il n'existait aucun processus permettant de déterminer et de suivre le coût total de propriété de l'intranet. L'absence de données sur les coûts empêche le Ministère de calculer le rendement de son investissement et de comparer ses coûts avec ceux d'autres organisations, à long terme.

Les seuls renseignements sur le coût de propriété de l'intranet qui étaient disponibles au cours de la vérification étaient des estimations empiriques du coût associé à la partie de l'intranet que certains gestionnaires connaissaient le mieux. On connaît toutefois les coûts associés à l'intranet dans certains secteurs isolés, à savoir le coût de base budgétisé par SXED, le coût du développement d'applications à l'interne, suivi au moyen d'un programme de recouvrement des coûts (SXED), le coût des projets de développement d'applications ou de sites intranet confiés à des entrepreneurs, le coût des biens ministériels (matériel et logiciels) utilisés pour gérer l'intranet, ainsi que le personnel affecté au développement et à la maintenance de certains sites intranet, en équivalents temps plein (ETP). À titre d'exemple :

  • Le recouvrement des coûts pour le développement d'applications à SXED se limite aux ressources chargées du développement et de l'AQ affectées directement au projet de développement. Certains éléments, comme les conseils en matière d'infrastructure, le temps des gestionnaires et les frais généraux liés à l'infrastructure, ne sont pas facturés aux clients. Dans le budget 2004, les coûts de base de SXED étaient évalués à 2,1 millions de dollars, tandis que le budget de recouvrement des coûts était de 1,3 million de dollars.
  • Quelques-uns des gestionnaires qui ont fait affaire avec des entrepreneurs ont indiqué les frais qu'ils avaient payés pour faire concevoir et développer leur site intranet.
  • Les coûts de maintenance de l'intranet varient de deux ETP consacrant la moitié de leur temps à la maintenance du site intranet Horizons, à environ 20 % ou 25 % d'un ETP pour la maintenance d'un autre site.

La vérification a révélé que, dans le cas des projets dont les coûts étaient suivis, on omettait souvent de prendre en considération le coût de propriété réel (p. ex. : les coûts associés à la maintenance permanente du contenu, aux mises à niveau et au soutien technique).

Faute de mesure du coût de propriété du contenu de l'intranet, la direction doit définir ses priorités et affecter les ressources à des priorités concurrentes à partir de renseignements lacunaires.

Nous recommandons :

1.3.1 Que BCD, par l'intermédiaire du comité directeur de l'intranet, mette en place des processus pour enregistrer les coûts liés à la gestion du contenu de l'intranet.

1.3.2 Que BCD, par l'intermédiaire du comité directeur de l'intranet, suive et examine régulièrement les coûts liés à la gestion du contenu de l'intranet et en fasse rapport au Comité exécutif.

Mesures et délais d'exécution

1.3.1 BCD rendra compte des ressources et des dépenses engagées par la Direction générale des communications.

Délai d'exécution : Exécution en cours.

1.3.2 Le comité directeur fera le suivi des coûts imputés à la Direction générale des communications pour la gestion de l'intranet et en fera part à BCD et à l'AIC avant de les communiquer au Comité exécutif.

Délai d'exécution : Le premier rapport sera livré à BCD le 28 avril 2006.

Résumé des recommandations en matière de gestion :

Résumé des recommandations en matière de gestion

2.0 Efficience et efficacité de l'intranet

2.1 Efficacité du contenu de l'intranet

Les sites intranet d'AEC qui renferment du contenu inapproprié, qui ne contiennent pas de canal de rétroaction et qui ont une disposition inhabituelle nuisent à l'efficience et à l'efficacité des utilisateurs. Dans l'ensemble, l'accès au contenu intranet d'AEC est très inefficace, entraîne de nombreuses plaintes d'utilisateurs et provoque beaucoup de frustration.

Interrogées au sujet des facteurs qui limitaient l'efficience et l'efficacité et contribuaient au mécontentement des utilisateurs, les entités vérifiées ont mentionné les caractéristiques suivantes du contenu de l'intranet d'AEC :

  • Dans bien des cas, le contenu des sites intranet d'AEC ne tient pas compte des besoins des utilisateurs. Ces derniers voient beaucoup de sites d'AEC comme des dépôts d'information archivée, plutôt que des outils axés sur leurs besoins. Plusieurs entités vérifiées ont insisté sur l'importance de déterminer ce que les utilisateurs attendent de l'intranet, puis de vérifier si le contenu proposé répond effectivement aux attentes. Cependant, il n'existe pas de processus établi pour évaluer dans quelle mesure l'intranet d'AEC répond aux besoins des utilisateurs. Sans indice quant au niveau de satisfaction des utilisateurs, il est difficile pour les propriétaires de contenu de savoir avec quelle efficacité leur site intranet répond aux besoins. Parmi le contenu souhaité, on nous a fait savoir qu'il serait pertinent d'enrichir la rubrique Cycle de carrière qui, à l'heure actuelle, porte surtout sur le personnel permutant.

Le contenu des sites intranet d'AEC

[Nos ministres et secrétaires d'État (avec mention de Bill Graham)]

  • Les utilisateurs doutent de la fiabilité du contenu de l'intranet d'AEC, car une partie du contenu est inexacte, périmée ou contradictoire. Nous avons observé de nombreux exemples de contenu périmé dans l'intranet d'AEC, notamment des sites qui faisaient référence à des directions qui n'existent plus, à des ministres qui ont été remplacés et à des employés qui ne font plus partie du Ministère.
  • Nombreux sont les sites intranet d'AEC privés d'un canal de rétroaction qui permettrait aux utilisateurs de poser des questions aux propriétaires de contenu. Dans beaucoup de cas, on ne dit pas clairement à qui s'adresser pour signaler des erreurs ou poser des questions.
  • Bien que tous les sites intranet de l'Administration centrale qui ont été vérifiés soient bilingues, nous avons constaté que certains sites intranet de missions n'étaient pas conformes à la politique en matière de langues officielles. Des exemples tirés des sites des missions de Paris, Londres et Washington sont fournis ci-dessous.

Des exemples tirés des sites intranet des missions de Paris, Londres et Washington

Le contenu inexact ou périmé risque d'induire les utilisateurs en erreur. Parce qu'ils entretiennent des doutes quant à la fiabilité des sites intranet d'AEC, les utilisateurs sont susceptibles de ne pas se fier aux sites qui contiennent des renseignements exacts. Quand les utilisateurs doivent « remonter à la source pour obtenir l'information la plus récente », on peut dire que l'intranet ne joue pas efficacement son rôle d'outil libre-service. Nous avons toutefois appris, au cours de la vérification, que le contenu de la page des nouveautés du site intranet de SMD est régi par une disposition visant à garantir la suppression rapide du contenu périmé.

La rétroaction des utilisateurs (suggestions, erreurs décelées, questions, etc.) risque d'être perdue si les propriétaires de contenu ne sont pas identifiés et si les sites ne comportent pas de canal de rétroaction.

Si des lignes directrices en matière d'apparence des sites doivent être adoptées pour l'intranet, de nombreux propriétaires de contenu souhaitent qu'elles ne soient pas trop prescriptives et leur laissent une certaine liberté quant à l'aspect du site. Les normes qui seront adoptées doivent renfermer des dispositions relatives à la gestion du contenu, au développement de sites et à la gestion de la qualité.

a) Gestion de contenu :

  • pertinence du sujet
  • apparence
  • coexistence avec les applications d'entreprise (c.-à-d., SGI et SGRH)
  • risque de double usage avec d'autres supports de communication du Ministère, tels que les messages à diffusion générale
  • examen régulier du contenu
  • suppression du contenu périmé

b) Développement de sites :

  • détermination des besoins opérationnels et des besoins des utilisateurs préalablement au développement du site
  • pratiques de développement exemplaires

c) Gestion de la qualité :

  • contrôle de la qualité
  • détermination et approbation des exceptions aux politiques
  • amélioration continue de la qualité
  • mécanismes de rétroaction à l'intention des utilisateurs et de mesure de la satisfaction

Nous recommandons :

2.1.1 Que BCD, par l'intermédiaire du comité éditorial de l'intranet, définisse des normes opérationnelles claires pour le contenu de l'intranet.

2.1.2 Que BCD, par l'intermédiaire du comité éditorial de l'intranet, amorce l'harmonisation des sites intranet déjà en place avec les nouvelles normes. Dans sa mise en oeuvre des nouvelles normes et politiques, le comité éditorial doit tenir compte des contraintes de temps et de budget des détenteurs de contenu. Une approche progressive est à privilégier.

Mesures et délais d'exécution

2.1.1 Le comité éditorial de l'intranet sera responsable de la création et de la diffusion aux propriétaires de sites de normes opérationnelles clairement définies en matière de contenu.

Délai d'exécution : Exécution en cours.

2.1.2 Le comité éditorial de l'intranet, de concert avec SXED, vérifiera le respect des normes relatives au contenu à mesure que ce dernier sera transféré dans l'intranet remanié. Des rapports sur les corrections à apporter aux sites seront examinés et remis aux propriétaires de contenu au besoin.

Délai d'exécution : 31 mars 2006.

2.2 Structure et utilisabilité du site Web Panorama

Sous sa forme actuelle, la page d'accueil principale d'AEC - celle du site Web Panorama, illustrée plus bas - est généralement considérée comme étant mal structurée, difficile à parcourir et peu conviviale. De plus, son contenu fait double usage, en grande partie, avec les messages électroniques diffusés. Il s'agit d'un outil inefficient et inefficace pour accéder aux renseignements d'AEC.

La page d'accueil principale d'AEC

Il est essentiel que la page d'accueil principale de l'intranet soit structurée de façon à permettre aux utilisateurs de trouver rapidement l'information dont ils ont besoin. Au moment de la vérification, la structure du site Panorama n'était pas conviviale et les utilisateurs considéraient que le site était difficile à parcourir. On nous a donné plusieurs exemples de situations où des utilisateurs avaient perdu du temps à chercher des liens ou des renseignements dans le site Panorama. On nous a aussi parlé du temps excessif qu'il fallait pour trouver des lignes directrices ministérielles. (Voir aussi la section 3.0, « Liens morts, pages orphelines et pages périmées »).

Des utilisateurs ont suggéré qu'il conviendrait de mieux définir les critères et les priorités applicables aux liens figurant dans la page d'accueil principale de l'intranet. Par exemple, on a remis en question la place dominante accordée au message à diffusion générale quotidien dans la page d'accueil du site Panorama, puisque cette information est répétée dans un courriel diffusé quotidiennement à tous les utilisateurs.

On nous a souvent répété que la page d'accueil du site Panorama n'avait pas une structure conviviale qui permettait aux utilisateurs de répondre aux questions qu'ils se posaient (p. ex. : combien y a-t-il d'employés dans une mission?). Le personnel souhaite avoir un intranet axé davantage sur la clientèle et moins sur l'organisation. À titre d'exemple, il serait souhaitable d'ajouter des rubriques dans le format « questions-réponses » qui fourniraient de l'information sur l'emplacement des applications et des formulaires de formation. À l'heure actuelle, la page d'accueil principale de l'intranet (Panorama) n'est qu'un répertoire de liens vers des sites indépendants peu intégrés et mal reliés.

Le site Panorama n'est pas conforme à certaines conventions courantes d'Internet, comme la barre de navigation à gauche et le soulignement des liens.

L'investissement du Ministère dans l'intranet d'AEC a été marginalisé par la faible connaissance qu'ont les utilisateurs du contenu et des sites offerts. Les utilisateurs ne tirent pas tous les avantages (sur le plan de l'efficacité) qu'ils pourraient tirer de l'intranet d'AEC. De plus, nous avons noté qu'il n'existait aucun plan de communication global établissant une stratégie pour promouvoir le contenu de l'intranet d'AEC auprès des utilisateurs.

De l'avis général, la disposition du site Horizons était considérée comme étant efficiente et efficace. Ce site est structuré en fonction de l'usage qui sera fait de l'information, plutôt qu'en fonction de la structure organisationnelle.

À titre d'exemple, le menu d'ouverture est axé sur les « clients », pas sur les secteurs d'activité.

Exemple du menu d'ouverture axé sur les « clients », pas sur les secteurs d'activité sur le site Horizons

Voici un autre site intranet bien structuré qui a été cité en exemple au cours de la vérification :

Exemple du site intranet SXD, un site bien structuré

Nous recommandons :

2.2.1 Que DMA désigne BCD à titre de propriétaire de la page d'accueil principale de l'intranet.

2.2.2 Que BCD, par l'intermédiaire du comité directeur de l'intranet, désigne des propriétaires pour tous les autres sites intranet.

2.2.3 Que BCD, par l'intermédiaire du comité directeur de l'intranet, amorce un examen (et un remaniement, au besoin) de tous les sites intranet, dans le but d'assurer le respect des nouvelles normes.

Mesures et délais d'exécution

2.2.1 DMA est d'accord. BCD deviendra propriétaire de la page d'accueil principale de l'intranet dès que les ressources nécessaires auront été mises en place.

Délai d'exécution : Achevé en septembre 2005.

BCD est d'accord et a implanté la mesure.

Délai d'exécution de BCD : DMA a confié à BCD la propriété de la page d'accueil principale de l'intranet. BCP gère à présent la page principale de l'intranet.

2.2.2 SXEO a fourni la liste à jour des propriétaires d'applications et de contenu dans l'intranet.

Délai d'exécution : Achevé en novembre 2005.

2.2.3 Conformément à la recommandation 2.1.2, le comité éditorial de l'intranet et SXED vérifieront la conformité avec les normes de tous les sites intranet, lorsque ces derniers seront transférés dans le nouvel intranet remanié. Des rapports sur les corrections à apporter aux sites seront examinés et transmis aux propriétaires de contenu au besoin.

Délai d'exécution : Avril 2006.

2.3 Efficacité des moteurs de recherche

La configuration des moteurs de recherche de l'intranet est inefficace. L'intranet renferme plusieurs moteurs de recherche distincts, non intégrés, qui sont implantés de façon non uniforme. Il en résulte, pour les utilisateurs, un fonctionnement lent, des résultats inexacts et un sentiment général de frustration. Les utilisateurs sont dès lors enclins à utiliser des moyens moins efficaces pour trouver l'information dont ils ont besoin, par exemple à faire des recherches manuelles ou dans des ouvrages sur papier, ou encore à s'adresser à des personnes-ressources. On risque donc de voir des décisions se prendre sur la foi de renseignements incomplets ou contradictoires, à cause de résultats de recherche inexacts.

Les personnes interrogées ont insisté sur le fait que l'utilisabilité du contenu de l'intranet était grandement limitée par les moteurs de recherche qui produisent des résultats inexacts. On nous a signalé qu'il arrive souvent que les moteurs de recherche ne produisent aucun résultat alors que l'on sait qu'il devrait y en avoir, et que les recherches ne portent pas sur tous les sites intranet. Dans l'exemple ci-dessous, il a été impossible de trouver le formulaire de demande de remboursement de frais de déplacement, même si ce formulaire est accessible dans l'intranet.

Exemple de résultat de recherche inefficace

[Exemple de résultat de recherche inefficace]

Parmi les facteurs qui contribuent à l'inefficacité des moteurs de recherche dans l'intranet, mentionnons les suivants :

  • une partie considérable du contenu de l'intranet se trouve hors de la portée des moteurs de recherche;
  • les systèmes de recherche ne sont pas gérés de façon efficace;
  • l'architecture de l'intranet n'est pas documentée.

Une importante partie du contenu de l'intranet n'est pas utilisée parce que les utilisateurs n'arrivent pas à la trouver à l'aide du moteur de recherche. On trouvera une description complète de la cause de ce problème dans la section 3.0 de ce rapport (« Liens morts, pages orphelines et pages périmées »).

Pour contourner la fonctionnalité limitée des moteurs de recherche, on a implanté dans le site intranet Horizons un index de mots clés. Bien que cette solution ne soit pas à même de remplacer un moteur de recherche efficace, elle a tout de même rehaussé la capacité de rechercher du contenu.

Nous recommandons :

2.3.1 Que BCD, par l'intermédiaire du comité directeur de l'intranet, confie à SXE la responsabilité du ou des moteurs de recherche communs de l'intranet.

2.3.2 Que SXE définisse, planifie et implante les améliorations requises en matière de moteurs de recherche.

2.3.3 Que BCD, par l'intermédiaire du comité éditorial de l'intranet, veille à ce que les nouveaux sites intranet répondent aux exigences dans le domaine du soutien de la recherche.

2.3.4 Que BCD, par l'intermédiaire du comité éditorial de l'intranet, amorce un exercice de documentation et de maintenance de l'architecture du contenu de l'intranet.

Mesures et délais d'exécution

2.3.1 BCP, au nom de BCD, a fait savoir à SXE qu'il faudrait un nouveau moteur de recherche.

Délai d'exécution : Octobre 2005

2.3.2 Dans le cadre de l'implantation du nouveau Système de gestion du contenu Web (SGCW) standard du gouvernement du Canada, SXE est en train d'élaborer une solution fondée sur le logiciel de Verity.

Délai d'exécution : Exercice 2006-2007.

2.3.3 BCD, en conformité avec les exigences qui seront énoncées par SXE une fois que le nouveau moteur de recherche aura été choisi, veillera à ce que tous les nouveaux sites intranet respectent les besoins en matière de soutien de la recherche.

Délai d'exécution : Exécution en cours, exercice 2006-2007.

2.3.4 BCD veillera à la documentation et à la maintenance de l'architecture de l'information de l'intranet. SXE sera responsable de la maintenance de l'architecture technique de l'intranet.

Délai d'exécution : 31 mars 2006

2.4 Technologies et environnements de développement d'applications intranet

Il serait possible de réduire les coûts de développement, de maintenance et de soutien des applications intranet en harmonisant les technologies, les plateformes et les environnements de développement d'applications. Par exemple, on supporte actuellement la machine Java de Microsoft et celle de Sun, qui sont pourtant très similaires.

Plusieurs applications intranet reproduisent des fonctionnalités qui sont déjà offertes ailleurs dans l'intranet. À titre d'exemple, les entités vérifiées nous ont signalé que le Ministère possédait de nombreuses applications liées aux subventions et contributions (certaines basées sur le Web, d'autres sur le langage SQL). De plus, on dénombre plusieurs systèmes de gestion des contacts (Outlook, Contacts Plus, Act 2000, Maximizer, un système géré par CICan, et des systèmes propres à certaines directions). Avant de procéder au développement de nouvelles applications intranet, il faudra étudier l'utilisation des applications existantes afin de favoriser une baisse des coûts généraux de développement d'applications et de soutien, et de réduire le nombre d'applications redondantes dans l'intranet.

Les exigences standard et les lignes directrices relatives aux technologies utilisées dans les applications intranet n'ont pas été respectées, en particulier dans le cas des applications développées à l'extérieur du Ministère.

Les entités vérifiées ont souligné qu'il serait possible d'intensifier la collaboration entre les directions. Le but visé était de cerner les pratiques exemplaires, de favoriser la réutilisation des applications existantes et de réduire les occasions où l'on réinvente la roue au sein du Ministère.

Nous recommandons :

2.4.1 Que SXD étudie et rationalise les plateformes et les environnements utilisés pour le développement et l'exploitation de l'intranet.

2.4.2 Que SXD documente et communique les normes applicables aux applications et aux sites intranet développés à l'extérieur.

Mesures et délais d'exécution

2.4.1 SXD transférera toute l'exploitation de l'intranet dans un environnement SIGNET-3 hébergé par une plateforme matérielle conforme aux normes SIGNET-3 courantes. La plateforme mise à niveau sera configurée de façon à isoler les activités de développement, d'assurance de la qualité et de production, comme le recommandent les pratiques exemplaires en vigueur.

Délai d'exécution : Avril 2006.

2.4.2 Pour donner suite à la recommandation 2.1.1, SXD développera des normes opérationnelles et appuiera les propriétaires de contenu en communiquant ces normes aux entrepreneurs externes. Il faudra déterminer les ressources requises en ETP.

Délai d'exécution : Exercice 2006-2007.

2.5 Disponibilité de l'intranet pour les missions

Dans certaines missions, les utilisateurs ont un accès inadéquat une partie du contenu de l'intranet en raison d'une capacité utile limitée.

La capacité utile est fonction de la rapidité du lien avec le réseau, des applications employées, des habitudes d'utilisation et de la mise au point des applications et du réseau. Les contraintes de capacité ont rendu très inefficace l'accès à l'intranet et à ses applications dans certaines missions.

Les délais de réponse élevés de l'intranet limitent l'utilisation de certains outils destinés à accroître la productivité. Au moment de la vérification, les employés de la mission de Buenos Aires affirmaient que pratiquement toutes les applications intranet étaient « extrêmement lentes, au point où l'on évite complètement de les utiliser. Quand on essaie de s'en servir, le temps de traitement est tellement long qu'il dépasse le délai d'inactivité, les applications refusent de fonctionner même pour les utilisateurs les plus persévérants, ou le délai d'exécution est si long qu'il a une incidence énorme sur la productivité ». Par exemple, accéder à un formulaire de demande de remboursement de frais de déplacement au moyen de l'application Formulaires@MAECI peut prendre jusqu'à 15 minutes. Le Ministère a pris des mesures pour alléger les difficultés ressenties à Buenos Aires; mais l'expérience risque d'être similaire avec d'autres applications et dans d'autres missions.

À l'ambassade de Vienne, en Autriche, un utilisateur a essayé de diffuser un message de 15 lignes au « Réseau d'échange de pratiques » des agents consulaires de la mission, exploité par SXKL à l'aide du logiciel de Tomoye. Il a finalement abandonné, après avoir attendu 35 minutes que le message soit téléchargé. Les réseaux d'échange de pratiques ont été créés pour permettre aux employés de partager de l'information et d'obtenir l'appui de leurs pairs, mais certaines missions ne peuvent pas y participer en raison des délais de réponse trop longs du réseau.

Parmi les facteurs qui allongent les délais de réponse de l'intranet, mentionnons les suivants :

  • la capacité utile, dans certaines missions, est insuffisante pour l'exploitation efficace d'applications intranet;
  • la mise en cache, dans certaines missions, est configurée de façon sous-optimale (c'est le cas en particulier pour les formulaires);
  • les applications, les fichiers et les formulaires sont parfois inutilement volumineux.

Dans les missions qui n'ont qu'un accès limité à l'intranet et à ses applications, les utilisateurs risquent d'éviter de se servir de l'intranet ou de recommencer à utiliser des solutions non approuvées (p. ex. : employer des versions de documents téléchargées localement, ou encore des renseignements périmés).

Nous recommandons :

2.5.1 Que BCD, par l'intermédiaire du comité directeur de l'intranet, définisse des normes de rendement pour l'ensemble des applications et des sites de l'intranet (p. ex. : des délais de réponse maximum).

2.5.2 Que SXD examine les applications et les sites intranet existants afin de trouver des moyens de réduire le nombre de transferts de fichiers et de formulaires volumineux (mise en cache, réduction de la taille des fichiers, etc.).

Mesures et délais d'exécution

2.5.1 Réaction de BCD : BCD n'accepte pas d'être chargée d'établir des normes techniques de rendement. C'est SXE qui, en simulant des conditions de faible bande passante, devrait définir les normes minimales qui s'appliqueront à l'ensemble des applications et du contenu de l'intranet.

Délai d'exécution : S/O.

Remarques de ZIV : Cette réaction suggère que la recommandation est interprétée comme une recommandation technique. Cependant, la recommandation vise à établir des normes ou des besoins pour les utilisateurs, qui permettraient à ces derniers de définir le niveau de rendement auquel ils s'attendent. Cette responsabilité revient à BCD, et, plus précisément, au comité directeur. Il incombe à SXE de fournir des systèmes et des applications dont le rendement répondra aux normes définies par les utilisateurs.

Cette remarque a pour but d'éclaircir la question afin d'accélérer la diffusion définitive du rapport.

2.5.2 Réaction de SXD : Les nouvelles procédures opérationnelles qui accompagneront le nouvel intranet remanié auront notamment comme objectif de réduire le nombre de transferts de fichiers volumineux. Elles seront appuyées par le nouveau Système de gestion du contenu Web (qui devrait réduire le nombre de transferts requis) et des améliorations du réseau (qui devraient alléger les contraintes imposées aux transferts).

Délai d'exécution : Exercice 2006-2007.

2.6 Sécurité de l'intranet

L'absence de contrôle appliqué au matériel publié dans l'intranet fait craindre à la direction que des renseignements de nature délicate soient diffusés dans l'intranet et compromettent, individuellement ou collectivement, la sécurité.

Au cours des entretiens menés dans le cadre de la vérification, on a soulevé le fait que du personnel embauché localement et qui possède une habilitation de sécurité limitée pouvait accéder via l'intranet à des données comme des renseignements personnels et des descriptions de propriétés qui, collectivement, peuvent être de nature délicate. La vérification a révélé qu'aucun processus de contrôle de la qualité n'était appliqué au contenu de l'intranet pour classifier ce contenu préalablement à sa publication afin d'assurer qu'il ne compromet pas la sécurité. Bien que les employés soient dans l'ensemble au fait de l'importance de la sécurité, il faudra renforcer la sécurité en ce qui concerne le contenu de l'intranet.

Aucun contrôle de qualité relatif à la publication dans l'intranet, ni aucune procédure de classification du contenu, n'a été défini ou mis en oeuvre. Le Ministère devra déterminer qui sera chargé de former les éditeurs de contenu intranet au sujet des politiques et des procédures relatives à la sécurité du contenu.

La vérification nous a permis de découvrir des solutions de rechange pour la diffusion de renseignements de nature potentiellement délicate. Par exemple, certaines directions utilisent des dossiers partagés au lieu de l'intranet pour conserver et diffuser de façon sûre des renseignements potentiellement délicats. Les dossiers partagés permettent de contrôler l'accès aux renseignements de nature délicate mieux que l'intranet.

Nous recommandons :

2.6.1 Que BCD, de concert avec IST, identifie les politiques et les procédures de sécurité applicables au contenu de l'intranet et en évalue la pertinence.

2.6.2 Que ZIV soumette le contenu de l'intranet à une vérification de sécurité complémentaire dans six mois pour déceler les risques de sécurité qui seront toujours présents.

2.6.3 Que BCD, de concert avec IST, forme les éditeurs de contenu intranet au sujet des politiques et procédures de sécurité, ainsi que des mesures de contrôle de qualité.

Mesures et délais d'exécution

2.6.1 BCD travaillera avec IST pour évaluer les politiques et procédures de sécurité applicables au contenu de l'intranet.

Délai d'exécution : 31 mars 2006.

2.6.2 La vérification recommandée a été amorcée par ZIV le 30 novembre 2005 et s'achèvera d'ici le 31 mars 2006.

Délai d'exécution : Exécution en cours.

2.6.3 BCD communiquera avec tous les éditeurs de contenu intranet pour s'assurer que les politiques et procédures de sécurité, de même que les mesures de contrôle de la qualité, sont bien comprises.

Délai d'exécution : 28 avril 2006.

Résumé des recommandations en matière d'efficience et d'efficacité :

Résumé des recommandations en matière d'efficience et d'efficacité

3.0 Respect des normes en matière de disponibilité et d'intégrité

3.1 Liens morts, pages orphelines et pages périmées

L'intégrité du contenu de certains sites Web examinés est faible, ce qui a pour effet d'exacerber les problèmes d'efficience et d'efficacité décrits ailleurs dans ce rapport.

Cette situation indique habituellement qu'un site n'a pas été tenu à jour, et elle se caractérise par les facteurs suivants :

Liens morts - Il s'agit d'un hyperlien qui mène à une page qui n'existe plus. Cela se produit quand la page de destination a été supprimée ou déplacée et que l'hyperlien qui y fait référence (à partir d'une autre page ou d'un autre site) n'a pas été actualisé. Les liens morts font perdre du temps aux utilisateurs qui cherchent à suivre le déroulement logique des rubriques et des liens.

On trouve des exemples de liens morts à seulement deux sauts de la page principale du site Panorama :

Il s'agit de cliquer sur http://intranet/menu-e.asp, puis sur Other Directories et, enfin, sur Listing of Mission Security Officers. Ce lien fait afficher le message d'erreur « 404 - Page introuvable », illustré ci-dessous.

Exemples de liens morts à seulement deux sauts de la page principale du site Panorama

  • Pages orphelines - Il s'agit de pages HTML qui sont enregistrées dans un serveur, mais auxquelles aucun hyperlien du site Web ne fait référence. Par conséquent, la seule façon d'y accéder consiste à taper expressément l'URL (adresse de l'hyperlien) correspondant dans la barre d'adresse, ou encore à trouver la page dans le moteur de recherche du site, s'il y en a un. Une page orpheline est créée quand le webmestre conçoit une page, mais ne fait aucune référence à celle-ci dans d'autres pages. Les pages orphelines engendrent des problèmes de maintenance et de gestion de la configuration (contrôle des versions).
  • Watchfire, l'outil d'analyse de sites Web automatisé, nous a fait découvrir plus de 100 000 pages orphelines. Nous savons toutefois qu'un bon nombre de ces pages sont des fichiers valides utilisés ou générés par les serveurs Web et utilisés par ceux-ci pour l'exécution de leurs activités normales. Il est cependant probable que beaucoup de ces fichiers soient des versions de travail périmées (c.-à-d., des versions incomplètes de fichiers en cours d'édition), et qu'un grand nombre d'entre eux puisse être supprimé. Cela simplifiera la maintenance du contenu et permettra aux outils tels que Watchfire de produire des résultats plus significatifs qui orienteront mieux les activités de nettoyage.

Voici quelques exemples de fichiers orphelins :

http://intranet.dfait-maeci.gc.ca/0616-HRD-NewStructure1.BK1
http://intranet.dfait-maeci.gc.ca/about/descript/menu2-en.asp
http://intranet.dfait-maeci.gc.ca/about/descript/menu2-fr.asp

  • Contenu inexact - Il s'agit d'information erronée figurant dans une page Web. Le contenu peut être inexact parce que l'information a changé, mais qu'on ne l'a pas mise à jour, ou encore parce qu'on a omis de la valider en y faisant référence. Le contenu inexact rend la consultation de l'intranet inefficace et irritante pour les utilisateurs. Il a pour effet d'ébranler la confiance des utilisateurs et d'inciter ces derniers à chercher à obtenir leur information par d'autres moyens. Le diagramme ci-dessous illustre la proportion des pages orphelines résidant dans le serveur principal de l'intranet (lbpis02). Le contenu inexact peut être attribuable à un manque de communication entre le propriétaire du contenu et l'éditeur du site Web ou le fournisseur de l'application, soit parce que les changements n'ont pas été communiqués à l'éditeur, soit parce qu'on a fourni à ce dernier de l'information erronée.

Illustration d'une charte du Contenu inexact des pages web et de l'information erronée tel que des liens rompues

Pages dans le serveur intranet principal(lbpis02)

L'illustration ci-dessous montre une page qui a été publiée en 1997 et qui n'a jamais été modifiée par la suite.

Illustration d' une page qui a été publiée en 1997 et qui n'a jamais été modifiée par la suite

Dans le diagramme ci-dessous, les 123 705 pages répertoriées dans le serveur principal de l'intranet (lbpis02) sont réparties en fonction de leur date. Cette répartition nous révèle que plus de la moitié des pages datent de trois ans ou plus. Bien que certaines pages de l'intranet soient conservées à des fins historiques ou à d'autres fins légitimes, il est probable qu'un grand nombre des anciennes pages soient effectivement inexactes et périmées.

Illustration d'une charte des  anciennes pages qui sont effectivement inexactes et périmées

*123 705 pages dans le serveur principal de l'intranet (lbpis02)

Nous recommandons :

3.1.1 Que SXE examine toutes les pages hébergées dans les principaux serveurs de l'intranet et supprime l'ensemble des liens morts et des pages orphelines.

3.1.2 Que BCD amorce un examen de l'actualité et de l'exactitude de tout le contenu par les propriétaires de sites.

3.1.3 Que SXE, de concert avec les propriétaires de contenu, passe en revue périodiquement tous les sites afin d'éliminer les liens morts, les pages orphelines et le contenu périmé.

Mesures et délais d'exécution

3.1.1 SXE a repéré les liens morts et les pages orphelines dans le site intranet courant. Conformément à la recommandation 2.1.2, seul le contenu réutilisable, c'est-à-dire conforme aux normes, sera transféré dans le nouvel intranet remanié.

Délai d'exécution : Avril 2006.

3.1.2 BCD entreprendra un examen de tout le contenu de l'intranet et transmettra aux propriétaires de contenu les résultats de l'examen de leur contenu ainsi qu'un plan d'action recommandé. La question des ressources requises pour cette tâche a été traitée dans le cadre du Projet de refonte de l'intranet.

Délai d'exécution : 28 février 2006.

3.1.3 SXE offre ce service aux propriétaires de contenu qui en font la demande. La migration vers le nouveau site intranet remanié éliminera les problèmes courants. L'implantation de nouvelles normes et de nouveaux processus, appuyés par le Système de gestion du contenu Web, devrait simplifier la tâche que représente pour les propriétaires de contenu le fait de tenir le contenu à jour et d'assurer son exactitude.

Délai d'exécution : Exercice 2006-2007.

Résumé des recommandations en matière de disponibilité et d'intégrité :

Diargam d'un Résumé des recommandations

4.0 Pratiques exemplaires

On trouvera dans cette section les pratiques que ZIV considère comme étant des pratiques exemplaires.

4.1 Pratiques de COBIT et de la BITI pour la gestion des technologies de l'information

L'intranet devrait être considéré comme étant un autre service de technologie de l'information (TI) et, par conséquent, être géré conformément aux pratiques exemplaires en matière de gestion des TI. Les objectifs de contrôle pour les technologies de l'information (Control Objectives for Information Technology ou COBIT) constituent une norme généralement applicable et reconnue en matière de pratiques de contrôle des TI. La méthodologie COBIT s'appuie sur les objectifs de contrôle courants de l'Information Systems Audit and Control Foundation (ISACF), auxquels s'ajoutent des normes internationales, en vigueur et en émergence, propres aux domaines technique, professionnel, réglementaire et industriel. On trouvera des exemples de pratiques exemplaires et davantage de renseignements sur la méthodologie COBIT dans l'Annexe C. La BITI (Bibliothèque de l'infrastructure de la technologie de l'information) est une approche généralement reconnue en matière de gestion de services de TI.

4.2 Conformité avec la politique en matière de langues officielles

Les sites intranet de l'Administration centrale que nous avons vérifiés étaient conformes à la politique en matière de langues officielles. Les infractions à la politique en matière de langues officielles sont circonscrites à certains sites de missions.

4.3 Site intranet Horizons

Le cadre de gestion du site intranet Horizons incarne plusieurs pratiques recommandées dans ce rapport de vérification. Par exemple, on a clairement indiqué que l'objet du site Horizons était d'appuyer le personnel de CICan sur le terrain à l'aide de contenu « utilisable et exploitable ». Le site intranet Horizons a été conçu en fonction d'une analyse complète des besoins des utilisateurs, et le comité consultatif responsable étudie régulièrement les statistiques sur son rendement. Le nom d'une personne-ressource est indiqué sur chaque site de l'intranet Horizons, de façon à ce que les utilisateurs puissent facilement poser des questions ou transmettre leur rétroaction. Des processus ont été mis en place pour assurer la gestion continue du contenu nouveau et courant, et des groupes de travail opérationnels gèrent activement le contenu pour qu'il soit toujours utilisable et exact. L'inauguration du site intranet Horizons a été accompagnée de beaucoup de publicité et d'instruction. Le fait que les utilisateurs soient bien au fait du contenu accroît la probabilité que le matériel publié soit effectivement utilisé, ce qui améliore le rendement de l'investissement réalisé dans l'intranet.

Annexe A

Participants à la vérification

Des entretiens officiels ont eu lieu avec les participants suivants dans le cadre de la vérification Note 4 :

Tableau 2 : Des Entretiens Officiels
PosteOrganisation
Chef, Services de publication et webmestre de l'intranetSXE
Délégué commercial, Opérations à l'étrangerTCS
Directeur adjoint, Services d'organisation et d'élimination de l'informationSXKI
Stratège des communications, Bureau du SMA des Ressources humainesMSV
Gestionnaire de comptes, Relations avec les clients et partenariatSXEC
Analyste principal des ressources de la GITSXM
Webmestre de l'ICSECFSM
Conseiller en technologie de l'information, Direction des services de gestionXDM
Chef d'équipe (Bureau de service SGA)SXEO
Analyste principal des systèmes Web Internet/intranet 
AIC intérimaire et DG, Direction générale de la gestion de l'information et de la technologieSXD
Directeur, Direction des services de communication 
SXE - Services à la clientèleSXEP
Directeur adjoint intérimaire, Exploitation des applicationsSXEO
Directeur adjoint, Développement des applicationsSXED
Directeur adjoint, Gestion moderneDMAX
Directeur adjointSXTM
Directeur adjoint, Opérations à l'étrangerTCS
Gestionnaire de la production WebSXEO
Coordonnateur Web et gestionnaire du contenu InternetPEP
Sous-ministre déléguéDMA
Chargé de projet principalIBOC
Système de gestion des ressources humaines et services de rémunérationSMD
Directeur adjoint, Direction des communications sur la politique étrangère et des communications ministériellesBCF
Directeur adjoint, Bureau Innovation et excellenceDMAX
Directeur, Direction des programmes de sensibilisation et des communications électroniquesBCP
Directeur adjoint, Système de gestion des ressources humaines et services de rémunérationSMSH
Directeur adjoint, Direction de la sécurité ministérielleISC
Directeur régional des cyber-services, Direction du développement des exportationsTCE
Adjoint exécutif, Direction générale de l'Administration centraleSPD
Agent de programme, Direction de la consolidation de la paix et de la sécurité humaineAGP
Conseiller en politiques, Direction de la promotion des intérêts canadiens aux États-Unis et de la liaison avec les missionsNUR
Administrateur de systèmes, Direction de l'exploitation des applicationsSXEO
Directeur général, Direction générale des communicationsBCD
Gestionnaire, Développement des applications et maintienSRBI

 

Annexe B - Serveurs et sites vérifiés

Tableau 3 : Serveurs et sites vérifiés

Sites :
ServeurURLRôle principalAccueilPano-ramaCouleurTitreDifférentIntrouvableTotal
Total        96
lpbis02http://intranetPanorama ET autres sites 423416570
lbpk01http://corpappsEQAMS, PubReg, annuaire  1 2 3
 http://hrms-sgrh.dfait-maeci.gc.caPeopleSoft    1 1
lbpcat01http://lbpcat01.cappsCATS, bibliothèque technique    1 1
lbpk06http://notespub01.dfait-maeci.gc.caConcours, BDD sur les politiques d'achat    2 2
albertprhttp://srdwebBiens, matériel, messagerie   1  1
lbpkz02 (sur Internet)http://pubx.dfait-maeci.gc.caCatalogue des publications  1    
lpbis04http://intranetappsDiverses applications302 10217

 

Schéma des serveurs intranet :

Schéma des serveurs intranet

Annexe C - Objectifs de contrôle pour les technologies de l'information et les technologies connexes (méthodologie COBIT)

Les objectifs de contrôle pour les technologies de l'information et les technologies connexes (Control Objectives for Information and Related Technology ou COBIT) constituent une norme généralement applicable et reconnue, destinée à assurer que les TI soient régies par un cadre de contrôle de gestion efficace et répondent aux attentes des clients et des gestionnaires. La méthodologie COBIT comprend des normes internationales en vigueur propres aux domaines technique, professionnel, réglementaire et industriel, et est désormais reconnue par le Secrétariat du Conseil du Trésor à titre de cadre applicable à l'examen et à la vérification des systèmes d'information au gouvernement du Canada.

Illustraion des objectifs de contrôle pour les technologies connexes (méthodologie COBIT)

La méthodologie COBIT est conçue pour être employée par trois groupes distincts :

  • Gestionnaires : Aide à peser les risques et à contrôler les investissements dans un environnement de technologie de l'information souvent imprévisible. Les gestionnaires ont besoin de pratiques de gouvernance et de contrôle des TI généralement reconnues pour étalonner l'environnement de TI en place et prévu. La méthodologie COBIT est un outil qui permet aux gestionnaires de communiquer les exigences divergentes et de faire le pont entre les exigences de contrôle, les questions techniques et les risques opérationnels.
  • Utilisateurs (c.-à-d. : responsables de processus opérationnels) : Sert à obtenir une assurance quant à la sécurité et au contrôle des services de technologie de l'information assurés par des fournisseurs internes ou externes.
  • Vérificateurs de systèmes d'information : Permet de corroborer les opinions sur les contrôles internes formulées à l'intention des gestionnaires.

La méthodologie COBIT avance qu'il existe plusieurs processus différents comprenant chacun de nombreux contrôles et décrit une façon systématique d'évaluer ces contrôles.

Cette méthodologie se compose d'un cadre pour le contrôle des TI fondé sur des critères relatifs aux renseignements opérationnels et documenté au moyen d'objectifs de contrôle répartis en fonction de domaines, de processus et d'activités liés aux TI. Pour chacun de ces secteurs, la méthodologie fournit, outre un ensemble d'objectifs de contrôle, une définition et un motif de contrôle.

L'orientation opérationnelle est le thème central de la méthodologie COBIT. Celle-ci est conçue non seulement à l'intention des utilisateurs et des vérificateurs, mais aussi - et surtout - afin de servir de liste de vérification complète pour les responsables de processus opérationnels. Les pratiques opérationnelles exigent que l'on habilite pleinement les responsables de processus opérationnels, de sorte qu'ils aient l'entière responsabilité de tous les aspects du processus opérationnel. Cette habilitation passe notamment par la communication de contrôles adéquats. La méthodologie COBIT est un outil qui aide les responsables de processus opérationnels à s'acquitter de leurs responsabilités.

Le cadre de COBIT part d'un postulat simple : Afin de fournir les renseignements dont l'organisation a besoin pour atteindre des objectifs, les ressources de TI doivent être régies par un ensemble de processus regroupés de façon naturelle. Les différents domaines sont désignés par des termes que les gestionnaires utiliseraient normalement dans les activités quotidiennes de l'organisation.

  • Planification et organisation - Ce domaine couvre la stratégie et les tactiques qui permettent de déterminer de quelle façon la technologie de l'information pourra le mieux contribuer à l'atteinte des objectifs opérationnels.
  • Acquisition et implantation- Pour concrétiser la stratégie en matière de TI, il faut identifier, développer ou acquérir, et implanter des solutions de TI et intégrer celles-ci au processus opérationnel.
  • Prestation et soutien - Ce domaine concerne la prestation des services requis, des activités conventionnelles à la sécurité, en passant par les questions de continuité des opérations et la formation. Les processus de soutien requis doivent être établis pour permettre la prestation des services.
  • Surveillance - Tous les processus de TI doivent faire l'objet d'examens réguliers portant sur leur qualité et leur conformité avec les exigences de contrôle.

Pour obtenir de plus amples renseignements sur la méthodologie COBIT, veuillez consulter le site suivant : À propos de l'ISACA.

Tableau 4: Stastiques COBIT

Secteurs visés par la vérification :
Gouvernance et cadre de gestion globalRespect des besoins des utilisateurs et de l'organisationCoûts permanents de propriétéExactitude et actualité du contenuDisponibilité et intégrité des systèmes
Explication de la méthodologie COBIT :
La gouvernance des TI repose sur une structure de liens et de processus qui permet de diriger et de contrôler l'entreprise pour atteindre les buts de cette dernière, tout en ajoutant de la valeur et en équilibrant le risque et les résultats dans le domaine des TI et des processus connexes.La satisfaction des utilisateurs se mesure en fonction des facteurs suivants :
  • Efficacité
  • Efficience
  • Confidentialité
  • Intégrité
  • Disponibilité
  • Conformité
  • Fiabilité de l'information

Par « besoins de l'organisation », on fait référence au niveau de conformité avec les paramètres et les spécifications énoncés ou sous-entendus.

Il s'agit de déterminer comment les coûts de propriété sont suivis et de comparer les coûts réels aux coûts budgétisés.Il s'agit de déterminer si l'information est exacte et à jour.Il s'agit de déterminer si l'information est utilisable à la demande à l'appui des fonctions opérationnelles, et si elle est exacte et complète.

 

Annexe D - Glossaire

Adresse IP

Une adresse IP (Internet Protocol) est un identificateur numérique désignant un hôte. Exemple : 293.26.1.19.

Application

Application intégrée au contenu d'un site Web et produite dynamiquement par une technologie d'application logée dans un serveur (à ne pas confondre avec un serveur d'applications). Du point de vue de la sécurité, toute page générée dynamiquement est considérée comme étant une application. Signalons que les applications peuvent aussi être imbriquées. À titre d'exemple, on peut considérer que l'ensemble des pages ASP qui composent WebXM constituent l'application « WebXM ».

Authentificateur

Dans le cas de l'authentification basée sur un formulaire, l'authentificateur est l'application qui valide les données d'identification d'un utilisateur. Les protocoles HTTP et NTLM, de même que la méthode de validation basée sur un certificat, utilisent tous des authentificateurs rattachés au serveur Web.

Autorité de certification

Une autorité de certification (AC) est une autorité, dans un réseau, qui délivre et gère les données d'identification cryptographiques et les clés publiques pour le chiffrement des messages. Elle fait partie de l'infrastructure à clé publique (ICP).

Certificat

Un certificat est une « carte de crédit » électronique qui établit votre identité lorsque vous faites des affaires ou d'autres transactions sur le Web. Il s'agit d'une clé publique signée (au moyen d'une signature numérique) par une autorité de certification (AC). Les certificats contiennent également des attributs secondaires, comme le nom, le numéro de série et une date d'expiration.

Clé

Dans le domaine de la cryptographie, une clé est une valeur constante qui est appliquée à une chaîne ou à un bloc de texte, au moyen d'un algorithme, pour produire des données chiffrées ou pour déchiffrer des données. Bien qu'il existe des milliards de clés, un élément de données chiffré à l'aide d'une clé précise ne pourra être déchiffré qu'au moyen de la même clé (ou d'une clé connexe).

Clé privée

Une clé privée est une clé de chiffrement qui est connue exclusivement d'un groupe limité de clients. Les clés publiques peuvent être employées avec une clé publique connexe (on dit alors que les clés publique et privée sont asymétriques) ou seules (on les dit alors symétriques) pour chiffrer efficacement des messages et des signatures numériques.

Clé publique

Une clé publique est la partie d'une paire de clés publique-privée qui est mise à la disposition de tous pour valider les données chiffrées au moyen de la clé privée. Étant donné que les clés publiques font toujours partie d'une paire de clés, elles sont naturellement asymétriques.

Clé symétrique

Clé utilisée dans les méthodes de chiffrement où la même clé doit être employée pour chiffrer et pour déchiffrer les données.

Contexte

De nombreux rapports comprennent de l'information contextuelle sur les problèmes décelés au cours d'une vérification. Le contexte est l'information sur un problème qui est repéré pendant une vérification. Par exemple, dans l'ancre HTML <A HREF="brokenlink.htm">Broken Link</A>, le contexte est le texte compris entre les balises <A> et </A>. Un lien pourrait aussi avoir pour contexte un élément JavaScript ou Flash, une image cliquable, une image, une feuille de style ou du contenu RealMedia.

Description d'image

Description du contenu d'une image, à l'usage des personnes qui ne peuvent pas voir ou traiter cette image. Si l'image est également décrite dans le texte qui l'accompagne, ou s'il s'agit d'une simple icône représentée adéquatement par du texte de remplacement (balise ALT), la description distincte est facultative.

Disponibilité

Qualité de l'information auquel le processus opérationnel peut accéder au besoin, à l'heure actuelle et dans l'avenir. La disponibilité concerne également la conservation des ressources nécessaires et des fonctionnalités connexes.

Document

Fichier qui renferme du contenu pertinent pour les objectifs d'un site Web.

Domaine

Le domaine est la partie de l'URL (identificateur de ressource uniforme) qui désigne une organisation ou une entité sur Internet. Exemple : www.watchfire.com.

Domaine externe

Les domaines externes sont les domaines dont l'URL (jusqu'à la première barre oblique inverse) est différent de l'URL du site faisant l'objet de l'examen. Si www.watchfire.com est examiné, les domaines comme www.products.watchfire.com seront considérés comme des domaines externes dans les rapports. Cette distinction s'applique aussi aux rapports de tiers; les domaines tiers seront considérés comme étant externes à l'examen.

Domaine interne

Domaine inclus dans l'examen du contenu et qui figure dans la liste des URL de départ.

Efficacité

Qualité de l'information qui est pertinente pour le processus opérationnel, fournie en temps voulu, exacte, cohérente et utilisable.

Efficience

Communication de l'information au moyen de l'utilisation optimale (c.-à-d., la plus productive et économique possible) des ressources.

Expression booléenne

On utilise souvent les expressions booléennes pour faire des recherches sur le Web. Dans la recherche booléenne, on peut employer l'opérateur AND entre deux mots pour trouver les documents qui renferment ces deux mots, ou encore l'opérateur OR pour trouver des documents qui renferment l'un ou l'autre des mots.

Feuille de style

Ensemble de commandes de mise en forme ou de style enregistrées dans un fichier distinct du contenu réel d'une page Web. Les feuilles de style facilitent la mise en forme, car elles peuvent être définies de façon centralisée plutôt qu'être redéfinies chaque fois qu'un élément donné se présente.

Fiabilité

Qualité du contenu qui donne aux gestionnaires des renseignements pertinents qui les aident à exploiter l'entité et à assumer leurs responsabilités en matière de rapports sur les finances et la conformité.

Fichier

Tout élément enregistré sur un disque que le système d'exploitation hébergeant le disque considère comme un fichier.

Hôte

Ordinateur dans un réseau. Chaque hôte peut être localisé au moyen de son adresse IP ou d'un nom de domaine complet. Quand on fait référence à un hôte par son nom d'hôte, ce nom doit d'abord être converti en adresse IP par un serveur de noms de domaines avant que le serveur puisse être joint.

Infrastructure à clé publique

Une infrastructure à clé publique (ICP) permet aux utilisateurs d'un réseau public fondamentalement non sécurisé, tel qu'Internet, d'échanger des données et de l'argent de façon sécurisée et privée au moyen d'une paire de clés publique-privée qui est obtenue et partagée par l'intermédiaire d'une autorité de confiance.

Intégrité

Qualité de l'information qui est exacte et complète, en plus d'être valide au regard des valeurs et des attentes de l'organisation.

Lien

Élément du langage HTML qui permet à un agent utilisateur de naviguer de son emplacement courant à un autre URL. Les liens sont des URL sur lesquels on peut cliquer.

Longueur de clé

La longueur de clé mesure le volume des données qui composent une clé et, par conséquent, le degré de protection assuré par cette clé. Les clés les plus longues, comme les clés à 128 bits, sont généralement considérées comme étant plus difficiles à casser que les clés plus courtes (par exemple, à 48 bits).

Méthode de chiffrement

Processus par lequel les données sont chiffrées et déchiffrées. Par exemple, la « norme de chiffrage des données » (Data Encryption Standard ou DES) est une méthode de chiffrement.

Méthode de serveur Web

Façon dont un serveur Web peut manipuler de l'information. Certaines méthodes présentent un danger, car elles permettent à des utilisateurs éloignés de modifier des données dans le serveur Web.

Nom de domaine

Nom qui identifie une ou plusieurs adresses IP et qui se compose d'au moins une partie générique, telle que .com, .gov, .edu ou .net, et une partie secondaire, comme Watchfire ou Microsoft. Un troisième, un quatrième ou plusieurs autres éléments peuvent s'y ajouter (par exemple : support.company.com).

Nom d'hôte

Nom d'un hôte à l'intérieur de son intranet. Par rapport à un extranet, un hôte est désigné par son nom de domaine complet.

Page

Document Web que peut consulter un utilisateur. Une page peut être un fichier HTML, Active Server Pages, Java Server Pages, Microsoft Office, Adobe Acrobat (.pdf), RealNetworks Streaming Media, Windows Media Player , XML, Macromedia Flash ou Javascript.

Piste de navigation (« Your are here »)

La piste de navigation, annoncée par la mention « You are here », montre le chemin que vous avez parcouru dans WebXM Control Center pour atteindre l'emplacement où vous vous trouvez. S'il n'y a pas assez d'espace pour montrer le chemin d'accès complet, des points de suspension figureront au début de la piste de navigation.

Point d'authentification

Élément de contenu qui comprend un authentificateur (dans le cas de l'authentification basée sur un formulaire) ou auquel on accède au moyen d'un authentificateur.

Port

Emplacement numérique, dans un hôte, où le serveur attend des requêtes. Par exemple, un hôte peut recevoir des requêtes dans les ports 80 et 443. Si un serveur Web logé dans cet hôte attend des requêtes dans le port 80, et que le serveur d'applications attend des requêtes dans le port 443, les requêtes transmises à ces ports seront acheminées au serveur pertinent. Les requêtes transmises à des ports qui ne correspondent pas à un serveur ne seront pas prises en considération.

Protocole d'échange de clés

Protocole régissant la façon dont deux parties échangent les clés à utiliser pour sécuriser une transaction. Une fois que les clés ont été échangées, les données peuvent être chiffrées par l'expéditeur (au moyen de la méthode de chiffrement convenue) et déchiffrées par le récepteur.

Protocole Secure Sockets Layer

Le protocole Secure Sockets Layer (SSL) est un protocole qui est couramment utilisé pour sécuriser la transmission de messages via Internet et qui a été remplacé par le protocole Transport Layer Security (TLS). Le protocole SSL fait appel à une couche de programme située entre les protocoles Hypertext Transfer Protocol (HTTP) et Transport Control Protocol (TCP) d'Internet. Il est intégré aux navigateurs de Microsoft et de Netscape, de même qu'à la plupart des serveurs Web. Élaboré par Netscape, le protocole SSL a obtenu le soutien de Microsoft et d'autres développeurs de clients et de serveurs pour Internet, et il est devenu la norme de facto avant d'évoluer pour devenir le protocole appelé Transport Layer Security. Le mot « sockets », dans le nom du protocole, fait référence à la méthode dite d'« interface de connexion », qui sert à transmettre des données entre un client et un serveur dans un réseau, ou entre différentes couches de programme dans un même ordinateur. Le protocole SSL recourt au système de chiffrement de RSA par paire de clés publique-privée, qui comprend également l'utilisation d'un certificat numérique.

Protocole Transport Layer Security

Le protocole Transport Layer Security (TLS) est un protocole qui assure la confidentialité des données transmises entre des applications communicantes et leurs utilisateurs. Ce protocole est le successeur du protocole Secure Sockets Layer (SSL). Quand un serveur et un client communiquent, le protocole TLS fait en sorte qu'aucun tiers ne peut lire secrètement ou altérer les messages.

Publication d'un sondage

Quand un sondage de rétroaction est publié sur un site Web, des pages HTML et .jsp sont générées et enregistrées dans le serveur de rétroaction. De plus, le sondage passe à l'état actif, ce qui signifie qu'il est accessible aux utilisateurs du site Web.

Serveur

Programme résidant dans un hôte qui attend et traite des requêtes provenant d'autres hôtes. Les serveurs reçoivent des requêtes par l'intermédiaire d'un ou de plusieurs ports d'un hôte.

Serveur d'applications

Serveur qui attend divers types de requêtes (selon le type de serveur d'applications) et qui fournit la logique opérationnelle requise pour traiter ces requêtes.

Serveur de noms de domaines

Un serveur de noms de domaines (DNS) convertit les noms de domaines en adresses IP correspondantes.

Serveur Secure Sockets Layer

Serveur qui traite les requêtes HTTP faites au moyen du protocole SSL.

Serveur Web

Serveur qui attend des requêtes du protocole Hypertext Transfer Protocol (HTTP) et transmet des réponses dans le format prévu par ce protocole.

Signature numérique

Une signature numérique est une signature dérivée du contenu d'un message qui peut être employée pour prouver l'intégrité et l'origine de ce message.

Tableau de bord

Un tableau de bord est un ensemble de propriétés qui définit l'apparence et le fonctionnement de My Watchfire et de My Watchfire Classic. Dans le cas de My Watchfire, ces propriétés déterminent quels problèmes sont présentés, comment les problèmes sont regroupés et nommés, comment les pointages sont présentés visuellement et comment les rapports fonctionnent. En ce qui concerne My Watchfire Classic, les propriétés déterminent quels problèmes sont présentés et comment les pointages sont calculés.

Technologie d'application du côté serveur

Technologie destinée à s'exécuter dans un serveur Web, comme Active Server Pages (ASP), Java Server Pages (JSP) ou PHP. Les technologies d'application du côté serveur produisent du contenu Web dynamique, que l'on considère comme étant des applications.

Technologie de site Web

Biens technologiques, comme un système de gestion du contenu, qui servent à établir et à gérer le contenu d'un site Web.

Types d'erreur engendrés par les liens morts

Le rapport sur les liens morts comprend les types d'erreur suivants :

  • File Not Found (Fichier introuvable) : Ce type d'erreur se produit quand un URL renvoie à un fichier qui n'existe pas se produit généralement quand l'URL contient une coquille ou quand le fichier cible a été supprimé ou renommé.
  • Cannot Connect (Connexion impossible) : Ce type d'erreur se produit quand le serveur cible ne répond pas à la requête du navigateur et est généralement attribuable à un serveur en panne ou trop sollicité.
  • Host Not Found (Hôte introuvable) : Ce type d'erreur se produit quand un URL renvoie à un serveur qui n'existe pas.
  • Time-out (Délai échu) : Ce type d'erreur se produit quand un serveur répond à une requête, mais ne transmet pas les données demandées assez rapidement, c'est-à-dire avant l'échéance du délai d'inactivité du navigateur.
  • Other (Autre) : Ce type d'erreur se produit dans le cas d'un accès non autorisé ou quand un utilisateur est incapable d'ouvrir un fichier. Quand une erreur ne correspond pas à l'un des autres types identifiés, elle est incluse dans la catégorie Autre du rapport.

Type d'utilisateur

Un type d'utilisateur (il y en a quatre), décrit les droits d'accès aux fonctionnalités d'un utilisateur donné dans WebXM Control Center. Ces droits d'accès peuvent toutefois être complétés à l'aide du ou des rôles qui sont attribués aux utilisateurs dans les espaces Web. Les quatre types d'utilisateur sont : Standard User (utilisateur normal), System Administrator (administrateur de système), No Access (utilisateur sans accès) et Webspace Creator (créateur d'espace Web).

URL

Un URL, ou identificateur de ressource uniforme (Unique Resource Locator), est une façon d'indiquer l'emplacement d'un élément dans le cyberespace.

Vérification d'accessibilité

Une vérification d'accessibilité est un test que l'on effectue pour déterminer la conformité d'une page Web avec un élément de référence. Chaque élément de référence peut servir à tester plus d'un point de conformité.


Notes:

1  Control Objectives for Information and Related Technology, Information Systems Audit and Control Association. Voir l'Annexe C.

2  Control Objectives for Information and Related Technology : document dont se sert le Secrétariat du Conseil du Trésor pour l'exécution de missions de certification concernant les technologies de l'information.

3  Bibliothèque de l'infrastructure des technologies de l'information : La BITI est devenue la norme internationale de facto pour la gestion des services.

4  Conformément aux dispositions de la Loi sur la protection des renseignements personnels, nous avons retiré de la version définitive du rapport le nom des participants.

Bureau de l'inspecteur général

Pied de page

Date de modification :
2012-10-05