4.2 Les dépenses de l'informatique, en 1982-1983, étaient de l'ordre de $ 610 millions et avaient très peu augmenté, en dollars constants, au cours des cinq dernières années.
4.3 La plupart des systèmes informatiques du gouvernement s'appuient sur la technologie conventionnelle des années 70. Nous avons examiné ces activités informatiques conventionnelles pour déterminer si elles permettraient au gouvernement d'utiliser de façon sélective et appropriée la nouvelle technologie informatique des années 80, basée sur les microprocesseurs et les télécommunications.
4.4 Tous les aspects des activités informatiques du gouvernement que nous avons examinés pouvaient faire l'objet d'améliorations. En outre, dans l'optique des perspectives d'avenir, certains signes nous laissaient douter de la capacité du gouvernement de tirer rapidement et entièrement partie de la technologie de pointe.
4.5 Le nombre d'experts pour la réalisation de nouveaux systèmes est restreint par la nécessité d'affecter un nombre sans cesse croissant - maintenant près de 70 p. 100 - des employés professionnels actuels au maintien et à l'amélioration de la grande quantité d'applications existantes. La pénurie de spécialistes d'expérience en informatique, manifeste jusqu'à l'an dernier, est susceptible de se reproduire. De nombreux ministères accusent un arriéré de trois à quatre ans dans la réalisation de nouveaux systèmes.
4.6 La plupart des ministères possèdent de bonnes méthodologies pour la réalisation des systèmes, mais, souvent, ne les suivent pas. Nous avons relevé certains dépassements dans les coûts de réalisation et de nombreux retards de livraison. Les contrôles de gestion exercés sur la réalisation des systèmes, telle la comptabilité de prix de revient des projets, doivent être améliorés.
4.7 Il semble qu'en matière de réalisation des systèmes il soit tout particulièrement difficile de déterminer les besoins des utilisateurs et d'arrêter un cahier des charges définitif, surtout dans les petits ministères ou dans ceux dont l'expérience en informatique n'est pas très poussée. Ainsi, il faudrait que les ministères améliorent leur façon de déterminer les besoins en matériel informatique pour leurs programmes et d'établir l'ordre des priorités pour répondre à ces besoins. Ces deux problèmes se rattachent à la nécessité plus fondamentale d'une planification stratégique de l'informatique. La planification stratégique est essentielle à cause des longs délais que comporte l'acquisition de matériel informatique, mais peu de ministères ont pu prévoir leurs besoins assez longtemps d'avance pour effectuer efficacement une telle planification.
4.8 À quelques exceptions prés, les ministères ne peuvent pas avoir accès à des systèmes informatiques de secours si l'ordinateur principal est inutilisable pendant une période prolongée.
4.9 Les politiques et lignes directrices du Conseil du Trésor sur la gestion de l'informatique conventionnelle semblent offrir un cadre suffisant pour contrôler et orienter les activités informatiques actuelles, mais elles devront peut-être être revues et élargies pour répondre aux besoins des prochaines années.
4.11 Le Conseil du Trésor estime que les dépenses consacrées à l'informatique au gouvernement fédéral durant l'exercice 1982-1983 se chiffrent à environ $ 610 millions et que le nombre d'années-personnes affectées surtout à l'informatique s'élève à près de 10 000. Cependant, ces chiffres, et d'autres chiffres du genre mentionnés ailleurs dans le chapitre, ne tiennent compte que des applications d'ordre général et ne comprennent ni les applications particulières pour les expériences scientifiques ni les cas où l'ordinateur est entièrement intégré à d'autre matériel, par exemple les systèmes d'armement militaire et le contrôle de la circulation aérienne. En outre, ces chiffres n'indiquent pas toute l'importance de l'informatique dans les activités du gouvernement. De nos jours, la vaste majorité des fonctionnaires manipulent, dans leur travail quotidien, des données traitées par ordinateur.
4.12 L'ampleur et les ramifications des activités informatiques du gouvernement justifient intrinsèquement que l'on en fasse l'examen. De plus, un certain nombre de développements récents dans le domaine de l'informatique retiennent plus particulièrement l'attention ces derniers temps. Grâce aux progrès presque quotidiens de la microélectronique, la vitesse et la fiabilité du matériel informatique augmentent et les coûts en diminuent.
4.13 D'une part, on peut maintenant acheter des ordinateurs "personnels" pour quelques milliers de dollars; d'autre part, les gros ordinateurs peuvent effectuer des millions d'opération à la seconde pour des coûts unitaires sans cesse décroissants. Les nouveaux dispositifs et les nouveaux logiciels permettent de raccorder les terminaux et les micro- ordinateurs les uns aux autres et de les raccorder aux ordinateurs centraux. On réalise des progrès dans la gestion des fichiers informatiques de grande taille et dans leur accessibilité. On assiste à la création de nouveaux langages de programmation qui facilitent la définition et la programmation de nouvelles applications. Nous semblons être à la veille d'une nouvelle vague d'applications informatiques, dont l'automatisation des procédés de bureau si essentiels à l'appareil gouvernemental. Cette nouvelle technologie offre de réelles possibilités d'améliorer l'efficience des activités du gouvernement et de mieux servir le public. Il s'agit fondamentalement de savoir si l'état actuel de l'informatique au gouvernement et les initiatives qui y sont prises permettront à l'État de tirer pleinement avantage de la technologie de pointe.
4.14 Les données du Conseil du Trésor sur les dépenses du gouvernement dans le domaine nous donnent une bonne indication des progrès de l'informatique au gouvernement, même si cette indication n'est pas nécessairement concluante. La représentation graphique de ces données, en dollars courants et en dollars constants, constitue la pièce 4.1.
La pièce n'est pas disponible
4.15 Cette pièce montre en outre que, vers la fin des années 60 et au début des années 70, les dépenses d'informatique du gouvernement fédéral, en dollars courants, croisaient à un taux annuel d'environ 20 p. 100. Vers la fin des années 70, ce taux avait toutefois baissé à environ 8 p. 100. Donc, une fois l'inflation prise en considération, le taux réel de croissance était infime ou même, pour une année donnée, négatif. Bien que de récentes données laissent présager que le taux réel de croissance puisse redevenir positif cette année, il semble, dans l'ensemble, que la fraction du budget total du gouvernement consacrée aux services informatiques internes se soit stabilisée.
4.16 Certains gouvernements provinciaux - notamment celui de l'Ontario - semblent augmenter leur budget informatique à un rythme beaucoup plus rapide que celui du gouvernement fédéral. Bien entendu, cela pourrait simplement vouloir dire que l'instauration de l'informatique au fédéral est plus avancée que chez les provinces; il se peut que de nouvelles applications importantes, d'un type réalisé par le gouvernement fédéral il y a des années, soient seulement en voie de mise en place au niveau provincial. Pour vérifier cette hypothèse, il nous aurait fallu effectuer une analyse des activités provinciales en informatique beaucoup plus poussée qu'il ne nous était possible de le faire.
4.17 Pris isolément, le taux de croissance des dépenses d'informatique ne constitue pas une preuve catégorique que l'informatisation est en voie de ralentissement au gouvernement fédéral alors qu'elle s'accélérerait ailleurs. Un volume impressionnant de projets sont toujours en voie de réalisation. Cependant, presque tous les gestionnaires interrogés nous ont déclaré qu'un nombre important et croissant d'employés passaient de la réalisation des systèmes informatiques à leur entretien. Aussi, les principaux projets que nous avons examinés semblaient être des ajouts aux systèmes existants plutôt que de nouvelles conceptions ou des remplacements complets. Pour ce qui est de la bureautique, par ailleurs, les initiatives du gouvernement sont encore préliminaires et expérimentales; elles n'entraînent pas encore de fortes dépenses. En règle générale, les gestionnaires de l'informatique semblent utiliser leurs ressources pour consolider les systèmes existants, plutôt que pour exploiter la technologie de pointe. En ce faisant, il se peut qu'ils agissent avec sagesse, mais nous croyons néanmoins qu'il faut faire attention de ne pas couper le gouvernement des possibilités que peut lui offrir la nouvelle technologie.
4.18 Certains signes tendent donc à prouver que, malgré la très grande diminution du coût du matériel informatique, comme le démontre la pièce 4.2, l'informatisation de l'appareil gouvernemental sera peut-être bientôt limitée, par des contraintes financières, à un rythme de réalisation inférieur à ceux que connaissent les entreprises privées, voire d'autres administrations gouvernementales. Il n'est pas de notre ressort de recommander l'augmentation des dépenses dans le secteur informatique, puisque l'ordre des priorités peut en décider autrement. On pourrait atténuer le manque de fonds et d'expertise en réaffectant les ressources dont disposent les ministères ou, dans certains cas, les services informatiques mêmes. De toutes façons, nous croyons qu'il est bon de signaler au Parlement et au public certaines des répercussions qu'il y a à laisser l'informatique du gouvernement plus ou moins telle quelle. Selon nous, notre étude démontre que ces répercussions pourraient être graves;, bien entendu, le problème découle en partie du manque de ressources.
La pièce n'est pas disponible
4.20 L'objectif premier de la présente étude est, par conséquent, de déterminer dans quelle mesure le gouvernement fédéral fait preuve d'économie et d'efficience en s'assurant de pouvoir recourir comme il se doit à la nouvelle technologie informatique des années 80 et 90. Plus précisément, notre étude s'intéresse à l'avancement actuel de l'informatique au gouvernement et tente de déterminer si l'on a respecté certaines conditions préalables à tout programme réaliste visant l'utilisation la plus efficace possible de la technologie des 10 à 15 prochaines années.
4.21 Quelles sont ces conditions préalables? On pourrait en citer plusieurs, mais nous sommes d'avis que tout programme soutenu d'informatisation, dans la présente décennie, devrait s'appuyer au moins sur les paramètres suivants, que l'on pourrait raisonnablement s'attendre à trouver déjà en place:
4.23 Aux fins de l'étude, nous nous sommes penchés sur un échantillon de ministères du gouvernement dans chacun des domaines qui nous intéressaient. Nos constatations découlent en grande partie d'entrevues avec les gestionnaires utilisateurs et les gestionnaires de l'informatique, entrevues auxquelles nous avons ajouté, lorsque l'envergure de l'étude nous le permettait, des examens de la documentation disponible. Pour retenir les ministères à interroger sur chaque sujet, nous avons essayé de faire un choix équilibré en fonction de variables comme la taille et la nature des activités informatiques du ministère, leur répartition géographique et le niveau de centralisation de la structure de l'informatique. Le nom des ministères retenus, ainsi que les thèmes étudiés, sont donnés à la pièce 4.3. Nous avons en outre puisé dans les constatations des vérifications intégrées des ministères, tant de cette année que des dernières années. Nous avons aussi visité les organismes centraux qui s'occupent de l'informatique.
La pièce n'est pas disponible
4.25 Nous nous sommes attardés à trois aspects importants du processus de réalisation des systèmes informatiques au gouvernement:
4.27 Gestion du Processus de réalisation des systèmes. Les lignes directrices du Conseil du Trésor prescrivent des procédés de gestion des projets passablement détaillés et la documentation informatique est assez abondante dans ce domaine. La plupart des ministères que nous avons visités avaient effectivement adopté une "méthodologie" officielle pour la réalisation des systèmes. Toute méthodologie de ce genre prescrit des pratiques normalisées et strictes pour la gestion des projets. Elle impose à l'équipe de projet une démarche disciplinée, étape par étape, grâce à des phases bien définies pour le déroulement du projet et exige des examens rigoureux à certaines étapes précises pour s'assurer que ce qui devait être livré à cette étape l'a été. Jumelée à des normes sévères sur la documentation - des programmes, une telle méthodologie aidera beaucoup à améliorer le contrôle que la direction doit exercer sur la réalisation des systèmes.
4.28 En réalité, toutefois, nous avons constaté, chez les équipes de réalisation, de grandes différences dans le niveau d'observation de la méthodologie. Bon nombre de problèmes relevés ne se seraient pas produits ou auraient été grandement atténués si le ministère avait suivi sa propre méthodologie. Pourquoi, alors, ne la suivait-on pas, nous sommes-nous demandé? Nous avons cru pouvoir élucider la question en examinant certains des problèmes fondamentaux auxquels font face, dans le cadre de projets particuliers, les chefs de projets en réalisation de systèmes informatiques. Dans les 10 ministères que nous avons visités pour cet aspect de notre enquête, nous avons essayé de savoir comment les chefs de projets réglaient effectivement ces problèmes.
4.30 Il n'y a pas de solution facile à ces problèmes. Les utilisateurs peuvent facilement soutenir que l'évolution rapide des politiques et pratiques ministérielles n'aide pas à arrêter un modèle "définitif". Pour sa part, la direction de l'informatique, même si elle aimerait bien voir les utilisateurs paver leurs "caprices". n'est pas prête à laisser le contrôle des fonds de réalisation aux utilisateurs et à dépendre d'eux de ce fait.
4.32 Les gestionnaires que nous avons interrogés estiment ce travail très difficile. La plupart des projets que nous avons examinés étaient dotés de plans insatisfaisants, peu détaillés et depuis longtemps périmés; de toute évidence, la direction ne se servait pas des plans pour contrôler les projets. Les responsables ne semblaient pas pouvoir replanifier rapidement et efficacement pour ce qui est de reporter les modifications au cahier des charges et les changements au plan original dans le calendrier et les dépenses. Les outils de planification disponibles ne permettaient tout simplement pas de réaliser la planification itérative - planification et replanification - nécessaire pour contrôler les projets dans une situation en pleine évolution.
4.33 Nous croyons néanmoins que si la réalisation des systèmes était beaucoup plus "visible" pour la haute direction qu'elle ne l'est aujourd'hui, cela inciterait les chefs de projets à mettre au point les outils dont ils ont besoin pour faire la replanification itérative nécessaire. Une entreprise privée qui développe des logiciels est forcée d'avoir recours à de tels outils pour respecter ses contrats et ne pas faire faillite. Les recommandations que nous formulons plus loin cherchent à susciter, pour les projets de logiciels internes du gouvernement, un climat relativement semblable et, parallèlement, un plus grand désir de planifier - incitation qui fait habituellement défaut aujourd'hui.
4.34 Même s'ils ont effectué une bonne planification, les chefs de projet doivent quand même pouvoir compter sur un système fiable de contrôle des projets qui leur indique s'ils atteignent leurs objectifs à temps, conformément au cahier des charges et aux contraintes budgétaires. Le problème 2 nous amène donc à aborder les problèmes 3 et 4.
4.36 En revanche, dans le secteur public, on ne retrouve pas souvent un tel processus en deux étapes, ni de processus qui s'y apparente. La lourdeur et la lenteur du processus d'approbation découragent une telle approche. Puisque les services informatiques des divers ministères ne possèdent habituellement pas de fonds discrétionnaires leur permettant de souscrire à une importante étude technique, la direction doit prendre ses décisions à partir d'études préliminaires incomplètes et, parallèlement, en fonction d'estimations de coût incertaines. Lorsque l'approbation est donnée sur la foi de ces estimations, le plan complet démontre souvent par la suite que le système coûtera beaucoup plus qu'on ne l'avait d'abord prévu. C'était le cas de plusieurs projets que nous avons examinés. Rendu là, on avait déjà trop dépensé d'argent pour annuler le projet. On le divisait alors en modules et on le prolongeait indéfiniment. Il est encourageant de constater qu'une récente circulaire du Conseil du Trésor (juin 1983) exige que l'on ait désormais recours au processus d'approbation en deux étapes pour les projets informatiques de plus de $ 1 million. Il semble bien que cette directive réglera certains des problèmes que nous venons de décrire.
4.37 Si les gestionnaires arrivent à surmonter leurs difficultés dans l'établissement de plans et de budgets, ils devront ensuite trouver moyen de contrôler les progrès et les coûts réels. Toutefois, l'état actuel de la comptabilité de projet au gouvernement n'aide guère la situation. On trouve un cadre pour la gestion des projets dans le Manuel de la politique administrative du Conseil du Trésor et le Bureau du contrôleur général a publié des lignes directrices sur la façon de surveiller les projets et d'en rendre compte, mais, parmi les projets que nous avons examinés, nous avons trouvé peu de systèmes de contrôle et de comptabilité de prix de revient qui se rapprochaient des prescriptions énoncées dans ces lignes directrices.
4.38 Quels que soient les doutes que l'on puisse entretenir au sujet des ressources "internes" consacrées aux projets (heures-personnes, temps d'ordinateur interne, etc.), les ministères contrôlent habituellement bien les dépenses engagées pour les contrats extérieurs. Ce phénomène semble militer en faveur de la sous-traitance des travaux de réalisation, mais cet argument n'est cependant pas concluant. En règle générale, les gestionnaires de l'informatique préfèrent contrôler eux-mêmes la réalisation des systèmes en la confiant à un chef de projet de leur service. Ils estiment en effet que la sous-traitance de projets à des sociétés de services et de conseil en informatique est mal avisée parce qu'ils ne reçoivent aucune assurance que le système, une fois livré, fera l'objet d'un suivi continu et parce qu'en outre aucun de leurs informaticiens ne connaîtra le système aussi bien que le constructeur.
4.39 Donc, si la réalisation est effectuée par les services du ministère, il manque aux chefs de projets de l'informatique un instrument de gestion fondamental. Il leur est impossible de savoir combien les projets ont coûté jusque-là, sauf par un calcul approximatif du nombre de personnes affectées aux projets et du nombre d'heures qu'elles y ont consacrées.
4.41 Presque toutes les méthodologies demandent un examen après la mise en oeuvre du projet, avec la participation de tous les intéressés, pour déterminer si le système fait ce qu'il est censé faire et pour profiter de l'expérience acquise pendant sa réalisation. Les ministères que nous avons visités ont reconnu la valeur possible de ces examens, mais rares sont ceux qui en ont effectués.
4.42 Puisque le gouvernement ne possède aucune norme généralisée pour la tenue de registres détaillés sur les projets, nous avons éprouvé beaucoup de difficultés à reconstituer le déroulement des projets que nous avons examinés. Cependant, nous croyons être en mesure de déclarer ce qui suit:
4.44 La capacité du gouvernement fédéral d'intégrer les progrès technologiques rapides des années 80 devrait toutefois être un réel sujet d'inquiétude. La plupart des ministères depuis longtemps rompus à l'informatique signalent qu'ils utilisent maintenant de 60 à 70 p. 100 de leurs employés professionnels uniquement à l'entretien et à l'amélioration des systèmes existants. Les gestionnaires de l'informatique nous ont souligné que ce rapport a systématiquement augmenté ces dernières années, à mesure que de nouveaux systèmes étaient mis en service et devaient par la suite être entretenus et modifiés. Les chiffres du secteur privé sont comparables. Toutefois, puisque le gouvernement tend à maintenir au même niveau les années-personnes affectées aux services informatiques, l'aptitude de ces services à réaliser de nouveaux systèmes diminue avec l'instauration de chaque nouvelle application informatique. Si rien ne vient remédier à la situation, tôt ou tard, il faudra presque mettre fin à la réalisation des systèmes. Dans de nombreux ministères, nous avons également constaté que le personnel en place avait déjà son travail tracé, approuvé et en attente pour les trois ou quatre années à venir. Après cette liste d'attente vient une liste semble-t-il infinie de souhaits des utilisateurs.
4.45 Puisqu'une bonne partie de ses ressources est affectée au maintien e à l'amélioration des systèmes conventionnels déjà existants, le service informatique moyen a beaucoup de difficultés à dégager ses techniciens pour leur permettre de s'informer des nouvelles réalisations technologiques et d'en faire l'expérience Il faut donc prévoir l'élargissement du fossé entre l'avancement technologique à l'intérieur et à l'extérieur du gouvernement. On dispose de divers moyens pour remédier à la situation et certains devraient, du moins dans une certaine mesure, l'alléger. De nouveaux langages "à la portée de l'usager", des systèmes de programmation simplifiés qui permettent aux utilisateurs de faire leur propre programmation, des micro-ordinateurs - tout cela peut contribuer à cette amélioration. Mais on ne peut indéfiniment reporter la réaffectation en profondeur d'années-personnes et de fonds au sein des services de réalisation des systèmes mêmes et à partir d'autres budgets du ministère, si l'on veut profiter pleinement de la nouvelle technologie.
4.46 Que faut-il faire? Si la haute direction des ministères pouvait voir plus clair dans le processus de réalisation des systèmes (parfois même obscur aux yeux des chefs de projets), nous croyons que la gestion des projets s'améliorerait grandement. Pour atteindre cette "visibilité", il faut, selon nous, que l'on respecte les exigences minimales ci-dessous.
4.47 Il faudrait définir l'ensemble du projet et ses phases c'est-à-dire qu'il devrait toujours être possible de préciser ce qui doit être livré, à quelle date et à quel coût. Cette définition est l'équivalent du contrat qui, s'il est bien rédigé et tenu à jour, définit les intentions, les droits et les obligations du constructeur de systèmes du secteur privé et ceux de son client, le futur utilisateur des systèmes. Les livraisons faites en fonction de ce "contrat" devraient être vérifiées au moyen d'une procédure qui établit que l'utilisateur a reçu ce qu'il a demandé et qui dispense le réalisateur de toute autre responsabilité concernant la livraison. Conformément à ce que prescrit la méthodologie, on effectue également une étude après la mise en place des systèmes.
4.48 Il faudrait que tous les coûts du projet soient déterminés et inscrits dans des comptes qui serviraient à prévenir les gestionnaires, de tous les niveaux, des dépassements de coûts et de dates d'échéance Ces comptes ne comprendraient pas uniquement des données financières mais seraient aussi des "journaux" dans lesquels seraient consigné la nature et le coût estimatif des modifications à la conception du système, ainsi qu'un relevé général des décisions prises, à savoir par qui, quand et pourquoi.
4.49 Pour être efficaces et objectifs, les documents et comptes rendus exigés par ces recommandations doivent faire partie des archives officielles du ministère et faire l'objet d'une vérification interne et externe. Il ne suffit pas qu'on les retrouve simplement comme documents de travail du service informatique.
4.50 Pour faire en sorte que le système de comptabilité des projets soit complet et intègre et que tous les fonds consacrés à la réalisation d'un système y soient imputés, nous croyons qu'il est important que le système comptable des projets soit entièrement concilié avec les comptes réguliers du ministère. Sinon, on aura tendance à "enterrer" les dépenses imputables au projet dans des comptes qui seront examinés de moins près. Pour le même motif, le système comptable des projets devrait, dans ses aspects financiers, être administré non pas par les gestionnaires de l'informatique, mais par les agents financiers du ministère, et il devrait s'appuyer sur le système comptable du ministère et y être concilié.
4.51 Nous ne croyons pas faire une suggestion qui ne soit pas déjà prévue dans la plupart des "méthodologies". Le système comptable des projets que nous envisageons ne s'écarte en rien des lignes directrices publiées par le Bureau du contrôleur général sur la surveillance des projets et la façon d'en rendre compte. En outre, nous n'avons certainement pas l'impression que les chefs de projets veulent cacher des choses. Au contraire, l'absence d'un bon système de surveillance des projets les prive d'un outil de gestion essentiel.
4.52 En résumé, nous recommandons que les ministères:
4.55 Détermination des besoins et établissement de l'ordre des priorités. Il n'y a pas désaccord quant aux grands principes à appliquer pour déterminer les besoins en informatique; ils peuvent se résumer comme ils l'ont été dans le paragraphe 2.61 de notre Rapport annuel de 1980:
4.57 Au coeur du problème institutionnel, on retrouve l'impossibilité pour les gestionnaires de programmes, qui sont les utilisateurs finals des services informatiques, d'agir en entrepreneurs. Ils doivent offrir certains programmes au public en tenant compte de l'économie et de l'efficience, mais il ne sont pas habitués de s'inquiéter de l'effet qu'aura un nouvel ordinateur sur l'état des profits et pertes. Ils sont toutefois en concurrence avec les gestionnaires d'autres programmes pour les services informatiques. Cette concurrence au niveau des ressources se distingue de celle du marché; il s'agit plutôt d'une surenchère dans laquelle les joueurs sont tentés d'exagérer leurs besoins afin de protéger leurs intérêts dans l'affectation finale des ressources disponibles.
4.58 Même sans cette tendance à exagérer, le problème de la détermination des besoins est encore très difficile. Le cas le plus simple est celui d'un seul ordinateur ou complexe informatique qui dessert un seul programme. Il devrait, au moins dans ce cas-là, être possible de montrer que la dépense de fonds supplémentaires améliorera la livraison du programme. Or, les grands centres informatiques des ministères sont des bureaux de services internes qui répondent aux besoins de nombreux programmes et d'une multitude de "clients". Les gestionnaires de ces bureaux de services internes n'ont ni les pouvoirs ni les ressources nécessaires pour effectuer l'analyse continue des besoins de tous ces clients. Donc, en pratique, les bureaux de services internes tendent à fonder leur demande de matériel supplémentaire sur des projections du volume de travail futur; le calcul de ces projections se base sur le volume de travail et le taux de croissance actuels.
4.59 Ce genre de justification n'est pas suffisant parce qu'il n'indique pas la répartition des services informatiques entre les divers programmes du ministère. Pour répondre à cette objection, certains ministères utilisent un "programme de comptabilité" dans le système d'exploitation informatique pour tenir compte minutieusement des ressources informatiques utilisées pour chaque travail exécuté par l'ordinateur. Les utilisateurs peuvent ainsi être "facturés" pour l'utilisation qu'ils en font. Cela permet au bureau des services internes d'indiquer comment son ordinateur soutient les programmes du ministère. Que cette utilisation tienne compte de l'économie et de l'efficience est toutefois une question que le chef du bureau doit laisser à l'utilisateur. Puisque les utilisateurs sont nombreux et les utilisations complexes, nous avons constaté que peu de bureaux de services internes sont disposés à pousser leur étude des besoins jusqu'au niveau des utilisateurs.
4.60 Le problème le plus aigu que pose la détermination des besoins se retrouve probablement chez les ministères dont les activités informatiques sont géographiquement dispersées et organisationnellement décentralisées. Il s'agit de situations courantes chez les ministères chargés de programmes de recherche scientifique importants. Obtenir une idée claire, à jour et fiable des besoins complexes de ses nombreux clients constitue un défi pour le coordonnateur des services informatiques de ces organismes.
4.61 Nous avons constaté que la qualité de l'analyse des besoins laissait à désirer à un niveau purement technique, même en tenant bien compte de ces contraintes institutionnelles. Ici non plus on ne peut faire abstraction des problèmes que l'on rencontre. Par exemple:
4.63 Pour obtenir une proposition valable, il faut reprendre le cycle des études techniques à plusieurs reprises, en augmentant chaque fois le niveau de détail et de complexité technique. Ce travail est exigeant, car il demande une très grande compétence professionnelle et des efforts soutenus. À l'heure actuelle, il existe, au gouvernement, très peu de normes à ce sujet et la tâche d'effectuer ces études n'est attribuée, dans le secteur professionnel, à aucun domaine spécialisé reconnu. Cette situation est très malheureuse puisqu'on ne peut s'attendre à ce que la haute direction révise des études techniques de ce genre; or, elle doit, en établissant l'ordre des priorités dont nous reparlerons plus loin, pouvoir se fier entièrement à leur exactitude et à leur exhaustivité. Nous sommes convaincus qu'il y a des professionnels, aussi bien dans la fonction publique que dans le secteur privé, qui possèdent les compétences techniques voulues pour faire ce travail. Mais il leur faut, pour ce faire, des normes ou des modèles qui définissent le contenu des études techniques et leur mode de présentation.
4.64 Le Conseil du Trésor et les ministères devraient prendre des mesures pour assurer la haute direction de la qualité du travail technique effectué pour étayer les propositions d'acquisition de matériel informatique; plus précisément, le Conseil du Trésor devrait commander la préparation d'études types de nature à appuyer les propositions d'acquisition à chaque étape du processus décisionnel et, le cas échéant, publier un guide pour la préparation de chaque catégorie d'études.
4.65 Le fait de déterminer les besoins informatiques d'un programme et de traduire ces besoins en systèmes et en installations ne constitue qu'une partie du problème. De fait, les ressources disponibles ne permettent jamais de fournir aux programmes tout l'apport informatique qui leur serait utile. Il faut pourtant établir l'ordre des priorités pour répondre aux besoins informatiques. Pour éviter que les responsables de l'informatique soient forcés de faire un choix parmi leurs "clients", nombre de ministères de notre échantillon ont créé des comités directeurs de l'informatique, constitués de représentants des principaux utilisateurs, dans le but d'établir l'ordre de ces priorités. Ces comités n'y parviendront que si leurs membres sont de niveaux hiérarchiques suffisamment élevés pour prendre des engagements au nom de l'organisation qu'ils représentent. Si cela est le cas, l'idée de comités directeurs pourrait être appliquée de façon avantageuse dans les ministères qui n'en n'ont pas. Il faudra probablement, de plus en plus, que les ministères établissent leur ordre de priorités puisque tous semblent convenir qu'il sera de plus en plus difficile d'obtenir de "nouveaux fonds". Les décisions en la matière seront difficiles à prendre parce qu'il faudra "voler l'un pour vêtir l'autre". Face à cette situation:
4.66 Lorsqu'ils ne l'ont déjà fait, les ministères possédant plusieurs services qui utilisent l'informatique, devraient établir des comités directeurs de l'informatique qui représentent les principaux utilisateurs. Les membres de ces comités devraient occuper un poste suffisamment élevé pour que leur appréciation de l'importance relative des divers programmes du ministère reflète celle de la haute direction.
4.67 Pour prendre des décisions dans le domaine informatique, la haute direction des ministères devra montrer plus d'intérêt et de connaissances en la matière qu'elle ne semble en manifester aujourd'hui. Il lui faudra non pas une connaissance technique, mais plutôt une aptitude à déceler les propositions qui, bien que techniquement saines, sont très risquées, ou celles dont la portée et les conséquences sur les activités du ministère dépassent le seuil de tolérance permis. Le Bureau du contrôleur général a déjà commencé à définir des lignes directrices qui répondront à ce besoin.
4.68 Le Conseil du Trésor devrait établir des lignes directrices que les hauts fonctionnaires pourront consulter lorsqu'ils doivent approuver des propositions de projets informatiques et qui les aideront à dépister les projets très risqués, ceux où l'on n'a pas pris les mesures appropriées pour en assurer la solidité technique et ceux dont on n'a pas bien évalué l'incidence sur les activités du ministère.
4.69 Décision de fabriquer ou d'acheter. Seuls les ministères qui ont peu d'activités informatiques dépendent toujours des bureaux de services du secteur privé, bien que la plupart des ministères complètent leurs propres services par le recours occasionnel aux installations du secteur privé. Il semble y avoir une nette préférence pour les services et installations internes, comme le confirment les données de la Revue annuelle de l'informatique publiée par le Conseil du Trésor: les services de traitement mécanisé achetés au secteur privé constituaient, en moyenne, 14,1 p. 100 du coût informatique annuel au cours de la période de quatre ans se terminant en 1978 et 14,8 p. 100 au cours des quatre années se terminant en 1981; ce pourcentage est resté relativement stable dans l'intervalle.
4.70 Approbation du Conseil du Trésor. Il nous a généralement été impossible de repérer des preuves écrites des observations exactes présentées à la haute direction au moment des grandes acquisitions de matériel. Les documents les plus accessibles étaient les présentations au Conseil du Trésor. Ces documents et les autres à l'appui n'étaient, en règle générale, que des plaidoyers en faveur de la solution avancée par les gestionnaires de l'informatique, mais qui ne faisaient aucune mention des solutions de rechange possibles, sinon pour les rejeter. Il est clair qu'on ne demandait pas à la haute direction de choisir parmi une liste l'option pouvant le mieux répondre à un besoin informatique; on cherchait plutôt la ratification d'une décision qu'on avait déjà prise.
4.71 Nous avons vite constaté que le Secrétariat du Conseil du Trésor ne possédait pas le personnel nécessaire pour soumettre les propositions d'acquisition à une étude technique sérieuse. Le groupe de Gestion de l'information du Secrétariat est chargé de mettre en oeuvre des politiques dans différents domaines, comme l'informatique et les télécommunications, et cette responsabilité l'amène à examiner tous les plans annuels et toutes les présentations spéciales qui se rapportent à ces domaines. Le simple fait que le groupe ne compte que cinq agents nous permet de comprendre qu'il ne peut saisir que les cas extrêmes où les ministères présentent des propositions tout à fait indéfendables.
4.72 Un fait important et assez récent a fait évoluer le rôle du Conseil du Trésor dans le processus d'acquisition. Dans au moins deux cas, le Conseil a estimé qu'il pouvait approuver l'adoption par un ministère d'une "technologie commune". Autrement dit, les ordinateurs centraux des ministères utiliseront dorénavant la technologie IBM ou d'une des sociétés dont la "configuration" informatique est compatible avec celle d'IBM. Si les autres fournisseurs veulent faire des soumissions de matériel (dérouleurs de bande magnétique, disques magnétiques, télécommunications, par exemple), ils doivent le rendre compatible avec l'unité centrale de technologie IBM.
4.73 Il n'est pas facile pour un gouvernement d'annoncer une politique de "technologie commune" parce qu'elle tend à exclure les offres de gros fournisseurs d'unités centrales, même s'ils peuvent toujours faire des offres à l'égard d'ordinateurs satellites compatibles avec le matériel IBM s'ils le désirent. Une fois adoptée, toutefois, la politique de "technologie commune" permet d'adresser les appels d'offres à un assez large éventail d'entreprises fabriquant des accessoires compatibles avec le matériel IBM. La politique ne favorise pas nécessairement IBM puisque cette firme fait face à autant, sinon plus, de concurrence sur le marché de la "technologie commune" qu'à l'extérieur du dit marché, même pour ce qui est des unités centrales.
4.74 Appels d'offres. Il n'est pas absolument nécessaire de procéder par appel d'offres, mais cela devrait être la norme pour les acquisitions importantes. En pratique, cette procédure se heurte au fait que la plupart des gros établissements informatiques sont fermement rattachés à un seul fournisseur d'unités centrales. Cette situation ne découle à de l'inertie des ministères ni de machinations de la part des fournisseurs, mais plutôt des investissements énormes et sans cesse croissants des ministères dans le logiciel d'application qu'ils intègrent ensuite au matériel de leur fournisseur. S'ils décident d'acheter leur matériel à un autre fournisseur, ils devront adapter leur logiciel d'application. L'avènement des bases de données en direct et des systèmes basés sur les télécommunications a resserré la dépendance entre le logiciel d'application et le matériel auquel il est adapté. Par conséquent, il est très rare aujourd'hui que l'on procède par appel d'offres pour remplacer une unité centrale existante: dans les six ministères visités, nous n'avons eu connaissance que d'un seul cas et ce cas unique présentait des caractéristiques tout à fait exceptionnelles.
4.75 En règle générale, on n'a donc recours aux appels d'offres que pour adapter des applications entièrement nouvelles à du matériel indépendant des systèmes existants ou pour acheter des appareils périphériques.
4.76 C'est dans ce contexte que la décision prise par certains ministères d'adopter une "technologie commune" prend toute son importance. En ce faisant, un ministère qui utilise des unités centrales de trois fournisseurs, par exemple, doit encore convertir le logiciel des unités centrales des deux fournisseurs qui seront abandonnés. Il s'agit d'un processus long et dispendieux qui peut prendre jusqu'à cinq ans. Cependant, cette technologie commune permet de procéder efficacement par appel d'offres pour l'achat de toute sorte de matériel, ce qui devrait être à l'avantage du contribuable.
4.77 En revanche, la politique de la "technologie commune" reconnaît de fait la technologie IBM comme étant la norme de l'industrie et, en pratique sinon en principe, elle exclut certains gros fournisseurs d'unités centrales des appels d'offres. Il sera très intéressant de voir si d'autres ministères, dont la technologie principale n'est pas celle d'IBM, trouveront la stratégie de la "technologie commune" assez avantageuse pour effectuer le changement.
4.79 Pourquoi? Manque de fonds. Il est très dispendieux de prévoir des plans de récupération "fiables" en cas de désastre. Les ministères ont découvert que le Conseil du Trésor ne leur donne pas de fonds supplémentaires à cette fin et ils ne sont pas disposés à absorber des coûts aussi considérables dans leurs budgets réguliers. Si un désastre spectaculaire avait lieu, les responsables de l'informatique pourraient plus facilement obtenir des fonds de leur ministère pour se prémunir contre de telles éventualités. Or, au Canada, aucune catastrophe du genre n'a retenu l'attention populaire depuis les événements survenus à l'Université Sir George Williams en 1969. Les chances qu'un tel incident se reproduise semblent minces et les ministères acceptent habituellement le risque du statu quo.
4.80 Sur les huit ministères que nous avons interrogés à cet égard, un seul avait dressé des plans réalistes et détaillés prévoyant l'utilisation d'un autre emplacement au cas où les installations centrales resteraient hors d'usage pendant longtemps. Ce ministère possède plusieurs ordinateurs du même genre, répartis dans diverses régions. Dans de telles circonstances, un plan qui suggère, en cas de catastrophe, d'effectuer le travail à l'un des emplacements régionaux est réaliste. Il faut toutefois faire une répétition de ce plan tous les deux ou trois mois parce que les programmes informatiques et le matériel qu'on utilise sont en constante évolution. Nous ne connaissons qu'un ministère qui met à exécution un programme soutenu de telles "répétitions", ce qui lui coûte cher et perturbe ses activités courantes.
4.81 Nous avons constaté que les responsables de l'informatique s'occupaient consciencieusement des questions de sécurité matérielle qui n'entraînent aucune dépense majeure. Par exemple, les recommandations de l'Équipe d'inspection et d'évaluation de la sécurité (EIES) de la GRC étaient habituellement mises en oeuvre, lorsque des mesures pouvaient être prises par les effectifs locaux. (L'EIES est un service central auquel peuvent recourir les ministères pour faire évaluer leur situation en matière de sécurité informatique.) De même, nous avons constaté que presque tous les ministères interrogés conservaient des doubles de leurs données et programmes critiques en un endroit distinct de leurs centres informatiques.
4.82 Le problème majeur est ce qu'il en coûterait pour que d'autres installations situées ailleurs possèdent la capacité excédentaire nécessaire pour poursuivre les activités essentielles lors d'une catastrophe. Quelle capacité supplémentaire faut-il et pendant combien de temps après le désastre? Ces deux facteurs dépendent de l'importance du maintien des services au public. Un seul des huit ministères examinés avait effectué une véritable enquête pour déterminer sa période maximale de tolérance d'un arrêt informatique complet.
4.83 Il était souvent clair que les ministères éprouvaient de la difficulté à évaluer l'importance de l'ordinateur dans leurs activités. S'ils réussissaient à s'occuper des programmes de paiement de transfert et des chèques de paye des militaires et des civils, plusieurs ministères semblaient croire qu'ils pourraient longtemps se passer de l'ordinateur. Dans une telle perspective, il ne semblait pas prioritaire de dépenser beaucoup d'argent, cette denrée rare, pour un centre informatique de secours.
4.84 Afin de vérifier si la situation était semblable dans le secteur privé, nous avons interrogé quelques entreprises. Effectivement, la situation n'y est pas très différente. La plupart des sociétés privées ne disposaient d'aucun plan de récupération réaliste en cas d'urgence. Il y avait évidemment des exceptions: une ou deux grandes institutions, ayant reconnu leur dépendance totale à l'égard des bases de données centralisées, avaient construit des forteresses ultra-sécuritaires pour les protéger. D'autres avaient cherché à réduire les coûts d'un centre de secours en se regroupant pour construire un local possédant toutes les caractéristiques d'un centre informatique, avec air conditionné, plancher surélevé, etc., mais sans matériel, puisque les membres du "club" utilisaient des appareils de types différents. Cette solution n'est utile que dans la mesure où le matériel informatique de la société peut être remplacé dans un délai tolérable après un désastre.
4.85 La question de récupération en cas d'urgence semble toujours sans issue. Des propositions d'installations de secours présentées par trois ministères ont récemment été rejetées par le Conseil du Trésor, bien que ce dernier, dans chacun des cas, ait invité les ministères à présenter de nouvelles propositions plus détaillées. Les ministères pourraient peut-être mieux affronter le problème de récupération ensemble, plutôt que séparément, surtout si un centre de secours commun pouvait répondre à leurs besoins, mais, autant que nous le sachions, aucune initiative conjointe en ce sens n'a été amorcée.
4.86 Bien que la décision d'accepter le risque de se passer d'installations de secours puisse se défendre dans certains cas, nous croyons qu'elle ne doit pas être prise par défaut. Nous recommandons donc ce qui suit:
4.87 Les ministères devraient évaluer formellement le délai durant lequel leurs programmes peuvent tolérer une interruption des services informatiques et la capacité informatique dont ils auraient besoin par la suite pour fournir un service de secours jusqu'à ce que les services informatiques perturbés par une catastrophe puissent être rétablis.
4.88 Les ministères devraient explorer, en consultation avec le Secrétariat du Conseil du Trésor, la possibilité d'une entreprise conjointe qui offrirait une solution économique au problème de récupération des services en cas d'urgence.
4.89 Quelles que soient les solutions finalement retenues, la haute direction des ministères devrait les enregistrer officiellement et ce compte rendu devrait préciser les risques qu'il faut minimiser et les risques qu'il faut accepter.
4.91 Ces nettes fluctuations dans la demande d'informaticiens se sont également fait sentir dans les services informatiques du gouvernement fédéral. Les rapports informatiques annuels que les ministères présentent au Conseil du Trésor - surtout ceux de 1981 - contiennent de nombreuses plaintes quant aux difficultés d'obtenir et de retenir des spécialistes des systèmes informatiques (CS). Le Comité consultatif des systèmes d'information (CCSI), un comité interministériel supérieur qui avise le Conseil du Trésor en matière d'informatique, a fait observer en 1981 que la pénurie de spécialistes de l'informatique (CS) constituait un problème de gestion extrêmement grave. D'autre part, vers la fin de 1982, les ministères signalaient un assez grand nombre de candidats à ces postes, du moins aux niveaux inférieurs. Il était encore difficile, disait-on, d'obtenir les services de spécialistes d'expérience en logiciel et en gestion de projets. Lorsque nous avons visité les ministères, au début de 1983, l'amélioration de la situation économique se faisait déjà sentir; le Conseil de placement professionnel déclarait la première augmentation de postes vacants d'informaticiens depuis 21 mois; certains gestionnaires interrogés prévoyaient qu'ils connaîtraient à nouveau une pénurie de personnel qualifié, peut-être encore plus prononcée.
4.92 Puisqu'il dépend de l'informatique pour administrer ses programmes, le gouvernement fédéral doit pouvoir obtenir, former et retenir les informaticiens (CS) dont il a besoin à cette fin. Nous avons donc décidé d'examiner de plus près le groupe des CS pour établir l'importance de la pénurie survenue entre 1978 et 1982, pour déterminer son incidence sur un certain nombre de ministères et pour voir comment ils y ont réagi. Nous avons essayé de voir quels obstacles empêchaient les ministères de recruter et de garder des informaticiens compétents et nous avons tenté, dans nos recommandations, de prévoir le cas où il surviendrait d'autres périodes de forte demande.
4.93 Importance de la pénurie. Le nombre de CS au gouvernement fédéral a augmenté d'environ 11 p. 100 de janvier 1978 à décembre 1981; à la fin de cette période, le gouvernement employait 2 460 informaticiens. Cette croissance n'a pas été facile. En 1976, le gouvernement a perdu environ 6,9 p. 100 de l'ensemble de ses CS. En 1981, ce taux d'attrition annuelle avait presque atteint 13 p. 100. Dans le contexte de ce taux de roulement croissant et de cette pénurie d'informaticiens compétents, le recrutement de nouveaux spécialistes en informatique provenant d'autres groupes professionnels et de sources extérieures au gouvernement fédéral a augmenté de 84 p. 100 par rapport à l'effectif de 1977.
4.94 Les pertes d'informaticiens subies par le gouvernement durant cette période ne semblent pas extrêmes si on les compare à celles du secteur privé dont le taux de roulement annuel pouvait atteindre de 20 à 40 p. 100. Les pertes globales d'informaticiens qu'a subies le gouvernement fédéral ne traduisent cependant pas toute la réalité. Les différents gestionnaires de l'informatique perdaient aussi des informaticiens au profit d'autres ministères ou d'autres services de leur propre ministère. Les données de la Commission de la Fonction publique sur les mutations et promotions interministérielles confirment des pertes de 10 à 36 p. 100 annuellement. Donc, du point de vue du gestionnaire, les conséquences de la pénurie et ses contre-coups sur la dotation ne semblaient pas tellement différents de ce qu'ont connu les gestionnaires du secteur privé.
4.95 Ces pertes subites n'ont pas semblé produire de réduction à long terme de l'effectif du groupe CS; les postes vacants ont en effet été comblés, mais les nouveaux titulaires possèdent beaucoup moins de connaissances et d'expérience que leur prédécesseurs.
4.96 Incidence de la pénurie sur les services informatiques des ministères. Dans notre échantillon, seuls Statistique Canada et Approvisionnements et Services Canada - ministères dont le nombre de CS dépasse 200 - ont réussi à éviter un roulement massif de leurs CS d'année en année. Les ministères possédant un petit nombre de CS semblent avoir été les plus durement touchés. Statistique Canada accusait un taux d'attrition inférieur à 20 p. 100 au cours de ces années, sauf en 1981; les ministères des Communications et du Travail, toutefois, ont tous deux subi des pertes dépassant 20 p. 100 de 1977 à 1981, sauf une année.
4.97 Les gestionnaires des ministères comptant moins de 100 CS ont indiqué qu'ils se sont sentis particulièrement vulnérables au cours de cette pénurie. Ils avaient l'impression qu'en raison de la petite taille de leurs organisations leur personnel Pouvait acquérir une expérience plus vaste t être ainsi plus en demande. Selon eux, la perte de 2 ou 3 informaticiens était beaucoup plus difficile à absorber dans une équipe de 10 environ que dans une organisation plus grande.
4.98 Les gestionnaires interrogés étaient conscients des dommages que le roulement a infligés à leurs services. Ils ont dû consacrer beaucoup plus de temps à la dotation en personnel à un moment où la pénurie d'informaticiens et le recrutement de nouveaux employés rendaient très exigeante la tâche de diriger leurs équipes. Les effectifs qui partaient étaient les employés expérimentés; ceux qui arrivaient provenaient directement des collèges communautaires et des universités. (Cette donnée est confirmée par la Commission de la Fonction publique qui signale que, chaque année de 1977 à 1980, les départs de CS-2 pour l'ensemble du gouvernement dépassaient les arrivées de ce niveau provenant du secteur privé. La situation au niveau CS-3 était encore pire.) En somme, selon les gestionnaires, ce fort taux de roulement les a privés des services de leurs meilleurs informaticiens - les plus doués, les plus brillants et les plus motivés.
4.99 Efforts des ministères pour atténuer les effets de la pénurie. Étant donné le tableau plutôt sombre de l'incidence d'un tel roulement que nous ont brossé les gestionnaires concernés, nous avons été surpris de constater combien les ministères avaient peu modifié leurs méthodes traditionnelles de recrutement et de formation pour corriger la situation. Les ministères pourvoient habituellement à leurs postes vacants un par un et ne semblent guère coordonner leur travail de manière à intégrer les fonctions de dotation, de formation, de planification professionnelle et autres pour l'ensemble du service informatique.
4.100 Nous n'avons guère vu de plans concrets de recyclage des employés par une série de projets visant leur perfectionnement. De même, bien qu'il y ait des programmes de formation, surtout dans les ministères possédant beaucoup d'employés du groupe CS, les contraintes financières et les impératifs d'exploitation dictaient qu'ils servent à répondre aux besoins immédiats d'exploitation plutôt qu'à constituer un groupe d'experts en informatique pour les besoins à long terme. Peu de ministères visités faisaient de planification des ressources humaines afin de déterminer leurs besoins futurs en informatique en ce qui a trait au nombre de CS, à leurs niveaux et à leurs aptitudes. On ne semblait ni s'occuper du perfectionnement du personnel déjà à l'effectif, ni effectuer de planification de la relève pour les postes critiques.
4.101 Cependant, pour être justes envers les gestionnaires, nous devons reconnaître que la planification de la relève ne leur semblait pas facilement conciliable avec le principe du mérite et le système de nomination à un poste précis qui ont cours dans la Fonction publique; préparer M. A. pour le poste X pouvait, à leur avis, être interprété comme une façon "d'arranger" le concours éventuel pour ce poste. Néanmoins, nous croyons qu'il est habituellement possible aux gestionnaires de tracer, pour leurs employés, des avenues de perfectionnement personnel parmi lesquelles ceux-ci pourront choisir.
4.102 La Commission de la Fonction publique et la direction de la Politique du personnel du Secrétariat du Conseil du Trésor n'ont pas reconnu avant 1981 la demande croissante d'informaticiens qui avait commencé à se faire sentir en 1978. Pour des raisons qui nous échappent, la pression exercée sur les services de dotation en personnel des ministères pour obtenir des informaticiens (CS) ne s'est pas fait sentir à la Commission avant cette date. Un comité de travail du Comité consultatif des systèmes d'information a fini par démontrer aux responsables de la Commission que leur perception du taux de roulement des CS devait être revue. Ainsi, ce n'est que vers la fin de 1981 que la Commission a commencé à corriger la situation.
4.103 À sa décharge, la Commission, en reconnaissant les problèmes décelés par le CCSI, a répondu plus rapidement aux différentes demandes de dotation et, à l'occasion de conférences traitant de l'informatique, a institué des foires de l'emploi dans le but de permettre aux ministères de trouver et de recruter des informaticiens compétents dans un minimum de temps. Malheureusement, pour de nombreux ministères, la pénurie avait déjà gravement épuisé leur bassin d'informaticiens d'expérience et les dégâts avaient déjà eu lieu. À la même époque, la récession économique commençait et la pénurie s'estompait.
4.104 C'est au Secrétariat du Conseil du Trésor qu'incombe la responsabilité première d'effectuer, dans l'ensemble du gouvernement, la planification des ressources humaines dans les groupes professionnels critiques. Le groupe des Ressources humaines du Secrétariat n'a d'abord pas cru que la pénurie de CS était grave et n'a pris aucune mesure pour pallier les difficultés des ministères. L'absence de réponse semble confirmer l'observation faite dans le paragraphe 3.35 de notre Rapport annuel 1981, à savoir que le Secrétariat "ne s'est pas acquitté de ses obligations globales relatives à la planification des ressources humaines pour l'ensemble de la Fonction publique". En notant que le Secrétariat avait répondu aux problèmes des groupes professionnels lorsqu'ils devenaient urgents plutôt que de prévoir les pénuries et d'élaborer des plans appropriés, le paragraphe 3.37 du Rapport de 1981 recommandait ce qui suit: "Le Secrétariat du Conseil du Trésor devrait évaluer régulièrement les besoins en ressources humaines dans la Fonction publique, déterminer les groupes professionnels essentiels à l'égard desquels les organismes centraux devraient procéder à une planification des ressources humaines et faire en sorte que les mesures voulues soient prises." Malheureusement, ces mécanismes n'étaient pas en place lorsqu'est survenue la pénurie de CS.
4.105 Contraintes imposées aux gestionnaires de l'informatique en matière e personnel. Puisque la présente étude porte sur la gestion de l'informatique, elle ne concerne pas les méthodes générales de classification et de dotation dans la Fonction publique ni les problèmes de la négociation collective. Or, aux yeux des gestionnaires que nous avons interrogés, ces questions sont d'une importance capitale pour expliquer les contraintes qui ont limité leurs possibilités de répondre à la pénurie de CS. Nous croyons donc devoir rendre compte de ces opinions, sans toutefois affirmer que le tableau ainsi constitué est complet ou équilibré.
4.106 Donc, du point de vue des gestionnaires, le processus de recrutement et de dotation était lui-même un des obstacles majeurs. Les gestionnaires ont souligné qu'il était souvent nécessaire de réagir rapidement lorsque se présentait un candidat intéressant, avant qu'il ne passe à un autre service. Ils se sentaient particulièrement vulnérables lorsqu'ils avaient à concurrencer les employeurs du secteur privé. Ils mentionnaient le nombre excessif d'étapes, la paperasserie et la bureaucratie entourant le mécanisme de dotation pour expliquer la lenteur de l'engagement d'informaticiens qui, à leur avis, pouvait prendre de quatre à six mois, même lorsqu'il existait des descriptions et des classifications à jour des postes à pourvoir.
4.107 Une évaluation des mesures de dotation prises par quelques-uns des ministères visés par notre étude a confirmé que les déclarations des gestionnaires n'étaient pas toujours exagérées. Par exemple, les données établies par la direction de l'Administration du personnel de l'un des ministères indiquent que le délai moyen total requis, en 1980-1981, pour combler des postes vacants de CS (autres que les CS-1) par voie de concours public, était de 146 jours civils. S'il s'agissait d'un concours restreint interministériel, il fallait 193 jours; s'il s'agissait d'un concours restreint intra-ministériel, il en fallait 245. (Les fonctionnaires de la Commission de la Fonction publique nous ont signalé que le délai de dotation peut être beaucoup plus court si le ministère fait connaître ses besoins à la Commission assez tôt pour qu'elle puisse dresser un répertoire de candidats.)
4.108 En outre, la Commission de la Fonction publique notait dans sa revue Dialogue de février 1981 qu'il fallait en moyenne 50 jours ouvrables pour doter un poste suite à l'annonce publique d'un concours "restreint" (réservé à la Fonction publique). Cette moyenne était calculée d'après les concours relatifs à tous les groupes professionnels, pas seulement le groupe des CS. Il fallait compter 21 jours supplémentaires pour régler diverses questions administratives comme les examens d'aptitudes linguistiques et la vérification des listes de priorités (par exemple, employés surnuméraires ou employés en disponibilité). D'autres articles de la même publication ont par la suite signalé que trois grosses sociétés canadiennes ayant des activités nationales et multinationales pouvaient effectuer une dotation semblable en 17 jours ouvrables en moyenne. Dialogue soulignait que les ministères du gouvernement fédéral sont tenus par la Loi sur l'emploi dans la Fonction publique de suivre une méthode précise, ce qui explique, en bonne partie, le temps requis pour doter un poste vacant.
4.109 Enfin, certains gestionnaires de l'informatique se sont dits inquiets de l'insuffisance de la formation qu'il leur était possible d'offrir à leur personnel de l'informatique. Les restrictions sur la proportion de fonds ministériels affectés à la formation les forçaient - selon leurs dires - à favoriser les cours qui traitaient du matériel ou des logiciels particuliers que l'informaticien devait utiliser pour ses différents travaux.
4.110 Le contrôle strict des années-personnes, la pénurie d'informaticiens sur le marché et la difficulté de doter les postes CS permanents expliquent facilement la croissance de la demande d'employés à contrat. Le ministère des Approvisionnements et Services (MAS) administre des offres permanentes principales et régionales (OPPR) portant sur de tels services; il s'agit d'une série de contrats entre le MAS et les entrepreneurs en informatique participants en vue de répondre à la demande de personnel compétent, en fonction des besoins et selon des taux quotidiens déjà convenus. Les ministères qui désirent obtenir les services offerts par les OPPR n'ont qu'à en faire la demande à un fournisseur en précisant leurs besoins. Au total, la valeur réelle des contrats pour la période de 12 mois commençant en octobre 1981 en vertu des OPPR était d'environ $ 19,5 millions.
4.111 En 1981, nous estimons que le taux quotidien moyen versé à ces entrepreneurs était de $ 300 à $ 320; selon nos calculs, ils ont travaillé quelque 62 000 journées-personnes, soit environ 275 années-personnes. Puisqu'à ce moment-là, la catégorie des CS comptait quelque 2460 employés, les entrepreneurs OPPR équivalaient à un ajout de 11 ou 12 p. 100 aux effectifs internes déjà disponibles.
4.112 Ces chiffres laissent fortement présager que certains gestionnaires ont pu atténuer leurs problèmes de dotation en personnel pour leurs services informatiques en ayant recours à des contractuels. En effet, certains des ministères que nous avons visités dépendent de toute évidence de ces services.
4.113 Conclusions concernant la gestion du personnel de l'informatique. Il semble maintenant que la récession économique du Canada tire à sa fin. Comme nous le mentionnions plus haut, cette reprise est accompagnée d'une demande accrue de spécialistes en informatique. Les prévisions récentes de la demande dans ce secteur pour les années 1983 et 1984 oscillent entre une croissance lente et prudente et un retour à la pénurie aiguë d'il y a quelques années. Présentement, les ministères et organismes de notre échantillon semblent aussi mal préparés à affronter une pénurie qu'en 1978.
4.114 Des fonctionnaires de la Commission de la Fonction publique et du Secrétariat du Conseil du Trésor nous ont déclaré qu'on avait prévu, sous réserve de l'approbation ministérielle, la mise en oeuvre d'un Système de gestion des ressources humaines en 1985 et que ce système pourrait peut-être résoudre plusieurs des questions que nous avons soulevées. À l'heure actuelle, toutefois, l'appareil des organismes centraux destiné à résoudre les problèmes de pénurie ne semble pas être beaucoup mieux rodé qu'en 1978. Aucun des ministères visités ne semble d'ailleurs avoir profité de l'expérience acquise de 1978 à 1981 pour élaborer une stratégie lui permettant de retenir ses CS actuels. La capacité des ministères pour ce qui est de recruter, de former et de perfectionner des spécialistes en informatique de façon systématique et coordonnée ne semble pas s'être accrue. On peut donc prévoir que les difficultés à conserver un personnel compétent et expérimenté se poursuivront.
4.115 En résumé, nous avons constaté que les gestionnaires de l'informatique avaient dû, de 1977 à 1981, faire face à toute une gamme de problèmes excessivement complexes à cause d'une demande à la hausse en informaticiens. La pénurie dans ce secteur d'emploi a produit un fort taux de roulement dans les postes de CS et a entraîné chez les ministères de lourdes pertes au niveau des spécialistes d'expérience en systèmes informatiques. Bien entendu, les postes vacants ont depuis été comblés, mais le niveau d'expérience, tout au moins dans certaines organisations, en a souffert de façon permanente.
4.116 La pénurie n'a pas épargné le secteur privé, mais ses répercussions ont été décuplées dans le milieu informatique gouvernemental, du moins selon les gestionnaires touchés, par les contraintes institutionnelles qui les ont empêchés de prendre des mesures rigoureuses, appropriées et opportunes pour contrer les pires effets des pertes subies en personnel d'expérience.
4.117 Nous ne croyons pas qu'il faille accepter les déclarations des gestionnaires à cet égard sans réserves aucunes. Toutefois, nous croyons que les opinions qu'ils nous ont exprimées étaient tellement généralisées qu'elles méritent que l'on s'y attarde. Comme nous l'avons signalé, la dépendance du gouvernement à l'égard de l'informatique est très forte et ne cesse de croître; en fin de compte, cette dépendance repose grandement sur l'expertise du milieu des CS. Nous croyons qu'il est raisonnable de prévoir une nouvelle hausse de la demande chez les CS de niveaux supérieurs au niveau de recrutement et qu'il devrait être possible de trouver des moyens d'augmenter l'aptitude du gouvernement à recruter et à garder ces employés, même face à un tel marché.
4.118 En collaboration avec les ministères, le Secrétariat du Conseil du Trésor et la Commission de la Fonction publique devraient:
4.120 L'absence de ces plans nous a intrigués parce que nous ne pouvions imaginer comment un établissement informatique moderne pouvait s'en passer. Les délais requis pour obtenir du matériel informatique et pour mettre au point des logiciels d'application - et aussi pour recruter et former le personnel technique nécessaire - sont désormais si longs qu'un gestionnaire doit travailler en fonction d'un horizon de planification de trois à six ans. Par ailleurs, la planification à long terme offre une chance inouïe d'amener la haute direction à comprendre la fonction informatique et à la favoriser. Si les avantages de la planification informatique à long terme sont si évidents, pourquoi les plans étaient-ils si peu nombreux?
4.121 Mais d'abord, les plans étaient-ils aussi rares que notre première impression l'indiquait? Parmi les 10 ministères de notre échantillon, nous avons constaté que les plans et méthodes de planification officiels étaient effectivement peu nombreux, bien qu'un ou deux d'entre eux aient depuis effectué beaucoup de planification. La plupart des ministères (7 sur 10) se sont engagés à produire désormais un plan officiel, mais le contenu d'un tel plan ne fait pas l'unanimité. Nous croyons que le Conseil du Trésor devrait aider les ministères à cet égard en préparant un ou plusieurs plans types pour en illustrer le contenu.
4.122 Toutefois, nous avons souvent trouvé des plans et processus de planification officieux qui pourraient répondre en grande partie à ces besoins. Dans de nombreux ministères, les gestionnaires supérieurs de l'informatique semblaient avoir une très bonne idée de ce qu'ils voulaient faire au cours des prochaines années. Pourquoi, nous sommes- nous demandés, retrouvons-nous ce genre de planification officieuse dans certains ministères et pas dans d'autres? Et lorsqu'elle existe, cette planification officieuse répond-elle aux besoins?
4.123 Nous avons trouvé les plans officieux les mieux élaborés dans les ministères dont les services informatiques sont importants et fortement centralisés. On y retrouve habituellement un volume de travail informatique imposant et stable. Ce volume de travail peut très bien faire l'objet de prévisions parce qu'il est fort peu probable qu'il change soudainement à cause d'un changement d'orientation et de politique du ministère. Ainsi, les gestionnaires de l'informatique possèdent une assise raisonnablement solide pour la planification. Les ministères dotés de petits services informatiques récemment mis sur pied n'avaient habituellement pas ce même genre de volume de travail; ils semblaient éprouver de graves difficultés à planifier à long terme, même lorsque l'informatique relevait d'une administration centralisée.
4.124 Lorsque les services informatiques sont géographiquement dispersés dans de petits centres, il n'y a habituellement aucune autorité unique pour contrôler l'ensemble des activités, de sorte que le coordonnateur de l'informatique du ministère peut difficilement suivre l'évolution de l'informatique au ministère, même après le fait.
4.125 Bien sûr, le problème de la planification officieuse réside dans le fait que les plans produits peuvent ne pas recevoir l'entière approbation et le plein soutien de la haute direction du ministère et qu'il est difficile de s'assurer que les fonctionnaires qui devraient participer à la planification le font effectivement. Plusieurs gestionnaires de l'informatique sont très conscients de cette faille et peuvent signaler une foule de tentatives visant à faire approuver officiellement leurs plans. Il s'est toutefois révélé impossible, en règle générale, d'obtenir un assentiment sur autre chose que des généralités, surtout dans les ministères qui sont réellement des fédérations peu structurées de directions semi-autonomes. Le manque de planification officielle représente un danger en ce que les plans informatiques du ministère risquent d'avoir très peu de rapport avec les plans intégrés de l'ensemble du ministère.
4.126 En l'absence de processus de planification officielle, il y a danger que les progrès technologiques rapides fassent que les systèmes informatiques soient déjà désuets au moment de leur mise en service. Pour pousser les choses à l'extrême, on pourrait entreprendre un projet de réalisation dans le cadre de la technologie courante et se rendre compte, plusieurs années plus tard, après avoir dépensé des millions, que l'on a réalisé un système dont personne ne peut se servir parce qu'il est inefficient et dépassé dans un milieu informatique qui a évolué de façon dramatique dans l'intervalle. (Nous n'avons relevé aucun cas de ce genre dans notre échantillon, mais nous avons eu connaissance d'un système complexe s'appuyant sur une base de données centrale, sur des procédés centraux et sur l'intégration d'une gamme variée de fonctions, le tout étant la caractéristique marquante de la technologie du début des années 70, au moment où la décision de réalisation avait été prise. Cette réalisation de système s'est poursuivie sur cette base pendant près de 10 ans et, bien que l'organisation ait par la suite eu recours à la technologie fondée sur les microprocesseurs et les télécommunications dans d'autres services, l'application de cette nouvelle technologie au système informatique principal fut limitée à cause du choix initial.)
4.127 Si difficile qu'elle puisse être à éviter en planification, la myopie peut avoir de graves conséquences. L'un des ministères de notre échantillon a constaté, en 1976, que son fournisseur d'ordinateurs, en fermant son commerce, passait ses clients à un autre fournisseur qui, pendant un certain temps, assurerait l'entretien du matériel et du logiciel. Pour cette raison, et parce qu'il leur fallait traiter un volume de travail accru, les informaticiens du ministère savaient qu'ils devraient bientôt changer d'appareil. Or, malgré qu'on se soit entendu dès 1977 sur ce qu'il fallait faire, presque rien n'a été fait jusqu'en 1980 alors qu'une étude commandée par le groupe de la vérification interne a révélé que le projet de remplacement des appareils accusait de sérieux retards par rapport; au calendrier de travail. À peu près au même moment, le fournisseur successeur a avisé qu'il cesserait sous peu l'entretien du vieil ordinateur. La date d'arrêt de ce service était alors si proche que le ministère ne pouvait lancer un appel d'offres à tous les fournisseurs parce que si le candidat retenu n'était pas le "fournisseur successeur", il aurait fallu convertir le logiciel d'application existant. Le ministère a donc dirigé son appel d'offres au seul fournisseur - le "fournisseur successeur" susmentionné - dont le matériel était compatible avec le logiciel d'application sans conversion majeure. On peut s'attendre à ce que les problèmes de planification de ce genre se multiplient à mesure que les ministères tenteront de se servir de la nouvelle technologie microélectronique des années 80.
4.128 Il semble clair que si les ministères veulent faire une utilisation sélective et efficace de cette nouvelle technologie, ils devront planifier leurs services informatiques sur une échelle parfois difficile à imaginer aujourd'hui. Les systèmes de l'avenir feront partie intégrante de la vie quotidienne, voire horaire, de presque chaque fonctionnaire; ils seront accessibles en direct toute la journée et il faudra des années, et plusieurs millions de dollars, pour les mettre en place.
4.129 Les ministères devraient:
4.132 En pratique, le Conseil utilise ce mandat de façon assez parcimonieuse et il n'est pas certain qu'il veuille intervenir davantage dans le domaine informatique. De plus, le nombre de fonctionnaires s'occupant de la politique informatique au Secrétariat ne permet pas d'élargir considérablement le champ d'activités. Il convient donc d'examiner le rôle actuel du Conseil du Trésor en matière d'informatique avant de faire quelque suggestion que ce soit visant à le modifier. Nous nous concentrerons sur les fonctions qu'exerce la direction de la Politique administrative du Secrétariat (DPA) dans le domaine informatique. Celle-ci:
4.134 Les gestionnaires de la DPA ne croient pas qu'il entre dans leurs attributions de s'assurer que les ministères se conforment aux politiques que la DPA élabore et promulgue au nom du Conseil du Trésor. Ils estiment que cette fonction appartient plutôt aux responsables de la vérification interne de chaque ministère. Notre position est toujours celle que nous énoncions au paragraphe 3.22 de notre Rapport de 1981:
Il faut contrôler la mise en oeuvre des politiques et des systèmes afin de s'assurer qu'ils sont respectés, et évaluer leur efficacité.
- Il faut instaurer des systèmes permettant de vérifier que les ministères et les organismes se conforment aux politiques et aux systèmes, et d'évaluer dans quelle mesure les résultats souhaités sont atteints de manière rentable.
- Les résultats du contrôle et de l'évaluation doivent servir à la révision et à l'élaboration des politiques et des systèmes.4.135 Les deux positions sont conciliables dans la mesure où les services de vérification interne des ministères peuvent effectuer une vérification efficace du respect des politiques du domaine informatique, question que nous examinerons dans de futurs rapports.
4.136 Au cours de nos entrevues avec les représentants du Secrétariat du Conseil du Trésor, nous avons décelé chez eux une réticence compréhensible à jouer un rôle plus accusé de chef de file dans l'introduction de la nouvelle technologie au gouvernement. Le Secrétariat a certainement raison de penser que les besoins des ministères sont trop variés et que l'entreprise est trop vaste pour qu'il puisse justifier l'introduction de la bureautique "par le centre". Il est clair que les ministères doivent eux-mêmes faire le gros de la planification et de l'administration. Or, nous savons aussi que l'activité des ministères que nous avons visités visant à promouvoir la bureautique est marquée par la fragmentation, l'absence de coordination et le manque de ressources. Il est difficile de voir comment la situation peut évoluer sans l'impulsion du Conseil du Trésor.
4.137 Étude des plans et des présentations. Les fonctionnaires de la DPA semblent reconnaître la disparité entre leurs ressources actuelles et la tâche énorme que constituerait toute étude complète des plans et présentations sur l'informatique. Ils tendent donc à se concentrer sur quelques cas où des développements inhabituels se produisent ou sont prévus.
4.138 À cet égard, nous croyons que nos recommandations versant à accroître la "visibilité" du processus de réalisation des systèmes, si elles étaient mises en oeuvre, aideraient la DPA à s'acquitter de cette partie de ses fonctions. Bien que l'état actuel de l'informatique au gouvernement puisse à peine justifier le démantèlement des mécanismes dont dispose le Conseil du Trésor pour son contrôle, il est évident que certains ministères pourraient devenir un peu plus autonomes en démontrant leur compétence à gérer leurs propres activités informatiques. Toutefois, la "visibilité" que nous avons recommandée serait évidemment une condition préalable à cette autonomie. Nous ne suggérons pas d'exempter ces ministères des présentations et des rapports; nous croyons plutôt que la mise en oeuvre de ces recommandations permettrait aux fonctionnaires du Conseil du Trésor de déterminer quels ministères leur font parvenir les propositions informatiques les plus fiables. La DPA pourrait ainsi accorder plus de temps aux propositions des ministères qui n'ont pas atteint le même niveau de maturité en informatique.
4.139 Besoins futurs en matière de politiques - un exemple. Bien que nous soyons d'accord avec les fonctionnaires du Secrétariat interrogés, qui sont d'avis que le Conseil ne doit pas tenter de gérer l'informatique dans tous ses détails et dans tout le gouvernement, nous croyons qu'à mesure que les ministères commenceront à ressentir les effets de certaines des réalisations technologiques actuelles, le Conseil devra intervenir au niveau des politiques.
4.140 Un exemple illustrera ce pont. En 1982, nous estimons que le gouvernement avait adjugé environ $ 27,5 millions en contrats d'achat ou de location de matériel de traitement de texte de la catégorie administrée par le groupe des Systèmes de bureautique qui relève de MAS-Approvisionnements. Il ne s'agit nullement des dépenses totales en machines de traitement de texte, mais seulement en unités autonomes, habituellement exclues du matériel informatique bien qu'elles comportent un microprocesseur. Il semble qu'on ait acquis environ 2 100 postes de travail de ce genre en 1982 (le montant exact n'est pas connu; nos chiffres sont basés sur certains dossiers du MAS).
4.141 Jusqu'à récemment, l'acquisition de machines de traitement de texte de ce genre relevait d'un service du MAS distinct de celui chargé de l'achat du matériel informatique. Dans plusieurs des ministères que nous avons visités, ces acquisitions ont été traitées normalement par les services administratifs, à peu près de la même façon que l'achat d'une machine à écrire. Les services informatiques de certains ministères exercent un certain contrôle en signant l'autorisation finale pour ces acquisitions, mais il ne s'agit pas là de la majorité. On saisit toute l'importance du phénomène lorsqu'on se rend compte qu'environ 26 p. 100 de ces unités comportent du matériel permettant de les relier à un autre ordinateur par télécommunications. On prévoit que cette proportion s'accroîtra sensiblement au cours des prochaines années. Il n'existe toutefois encore aucune interface normalisée entre les ordinateurs pour l'ensemble de l'industrie au niveau des télécommunications; ainsi, toute organisation qui veut que ses ordinateurs puissent se "parler" devra s'assurer de leur compatibilité avant de les acheter. À l'heure actuelle, nous ne connaissons qu'un seul ministère doté de plusieurs types d'appareils qui possède une norme d'intercommunication.
4.142 Nous courons le risque d'une "tour de Babel" dès que les utilisateurs du matériel découvriront ses possibilités de communication avec d'autres ordinateurs et d'accès aux grosses bases de données du ministère. À l'heure actuelle, la confusion est aggravée par le fuit que l'industrie informatique même procède de façon très graduelle et pas très rigoureuse pour produire des normes générales d'intercommunication.
4.143 Dans ce cadre plutôt chaotique, le milieu informatique du gouvernement est en pleine polémique. Les gestionnaires des grands services informatiques croient que le matériel incompatible connaîtra une prolifération incontrôlée et prévoient que les utilisateurs autodidactes d'ordinateurs personnels feront pression pour avoir accès aux bases de données intégrées et communes de sorte que l'intégrité de ces dernières pourrait être menacée.
4.144 Les utilisateurs de l'informatique, en revanche, sont portés à croire que le microprocesseur les libérera de la frustration d'être à la merci des grands centres informatiques des ministères. Enfin, ils pourront réaliser eux-mêmes leurs systèmes, selon leurs propres méthodes et leur propre échéancier, sans voir leurs projets passer des années dans les files d'attente des services informatiques. Ces utilisateurs sont portés à voir, dans le désir de la direction de l'informatique de contrôler la gestion des microprocesseurs, une forme d'impérialisme. Ils rejettent l'argument de la compatibilité en disant que le matériel tombe en désuétude si rapidement que les acquisitions actuelles devront être remplacées avant que le problème de l'intercommunication surgisse.
4.145 Certains ministères tentent de résoudre ce problème, d'autres pas. Il est difficile de voir comment le Conseil du Trésor peut longtemps demeurer à l'écart puisque d'habitude la haute direction des ministères n'a pas le bagage technique nécessaire pour arbitrer les litiges entre les gestionnaires de l'informatique et les utilisateurs actuels et éventuels de microprocesseurs. Tôt ou tard, il faudra établir des politiques et normes quelconques pour l'ensemble du gouvernement.
4.146 Le Conseil du Trésor devrait revoir, clarifier et, au besoin, renforcer son rôle dans la gestion de la technologie de l'information afin que les ministères sachent ce qu'ils peuvent attendre comme directives et orientation du Conseil et ce qu'ils peuvent décider par eux-mêmes.
4.147 Le Conseil du Trésor devrait surtout réviser sa définition de l'informatique pour qu'elle englobe tous les aspects de la manutention de l'information électronique sur lesquels il veut des comptes rendus particuliers ou désire exercer un contrôle spécial.
4.148 Le Conseil du Trésor devrait préciser comment il entend surveiller le respect de ses politiques par les ministères; il devrait aussi indiquer clairement comment il se propose de recueillir les réactions des ministères pour évaluer l'efficacité de ses politiques.
4.149 Si le Conseil du Trésor entend plutôt laisser aux services de vérification des ministères le soin de surveiller le respect de ses politiques, il devrait veiller à ce que ses services comprennent suffisamment bien l'informatique pour assumer une telle fonction.
4.150 Si le Conseil entend jouer un rôle de chef de file en encourageant et en facilitant l'introduction de la nouvelle technologie de l'information, qu'il le dise. Il devrait alors prendre l'initiative, c'est-à-dire:
Lors de la rédaction du présent chapitre, nous avons été informés par les représentants du Secrétariat de la création officielle, par le Conseil du Trésor, le 7 juillet 1983, d'un Groupe de travail chargé de l'informatique dont les activités s'échelonneront sur les prochains 12 à 18 mois. Le mandat du groupe de travail semble porter sur des préoccupations semblables à bon nombre de questions soulevées dans le présent chapitre et semble signifier que le Conseil du Trésor a l'intention de jouer le rôle de chef de file dans le développement de tout le secteur du traitement de l'information du gouvernement fédéral.