ARCHIVÉ - Vérification avant la mise en oeuvre (NIP) - le 10 octobre 1984

Cette page a été archivée.

No. 1984-03
Date : 10-10-84 

Sujet : Vérification avant la mise en oeuvre

Pour toute question concernant cette notice, prière de s'adresser à la :

Politiques et projets spéciaux
Centre d'excellence en vérification interne
Direction générale de la fonction de contrôleur, SCT
(613) 957-2270

Objet et portée

La vérification interne d'aujourd'hui, telle que définie dans les Normes[1] vise deux objectifs principaux: 1) aider les gestionnaires à accroître la productivité de leurs opérations en cours (vérification de l'économie, de l'efficience et de l'efficacité); et 2) conseiller la direction sur l'élaboration d'une infrastructure importante, nouvelle ou modifiée, qui soit à la fois économique, efficace et efficiente (vérification avant la mise en oeuvre).

La présente Notice d'interprétation de la politique (NIP) a pour but de fournir aux vérificateurs internes quelques lignes directrices concernant la vérification avant la mise en oeuvre; elle complète la norme no 2, portant sur le « champ d'application » ainsi que les discussions connexes figurant au Chapitre deux, « Champ d'application et fréquence », ainsi qu'à l'annexe A, « Vérification des systèmes informatiques ».[1]

Questions a l'étude

1. Qu'est-ce qu'une vérification avant la mise en oeuvre?

Une vérification avant la mise en oeuvre est la vérification d'un système ministériel ou organisationnel effectuée pendant le processus de conception, de mise au point et d'installation du système plutôt qu'après sa livraison au client à des fins d'exploitation.

2. Quel est le champ d'application d'une vérification avant la mise en oeuvre?

Conformément aux Normes, le champ d'application d'une vérification avant la mise en oeuvre englobe tous les principaux systèmes en cours d'élaboration, dont les nouvelles lois, politiques et procédures, les nouveaux systèmes d'information (informatisés ou non) et les procédés de production.

La vérification avant la mise en oeuvre peut être formée de deux composantes:

1. la vérification du processus de gestion des projets ou d'élaboration des systèmes (dans le cas des systèmes informatisés, cela comprend le cycle entier d'élaboration des systèmes[2]);
2. la vérification du cadre de contrôle établi pour le système en cause.

3. Pourquoi effectuer une vérification avant la mise en oeuvre?

Un principe fondamental justifie l'utilité de la vérification avant la mise en oeuvre: il est plus rentable de remédier à des lacunes dans le cadre de contrôle pendant les travaux de conception, de mise au point et d'installation du système qu'après sa mise en oeuvre lorsqu'on a fait appel à une grande quantité de ressources et qu'on a manifesté un solide engagement envers l'entité en cours d'élaboration.

Ceci n'élimine pas la nécessité d'effectuer des vérifications après la mise en oeuvre, car rien ne garantit que le système conçu et installé a été tenu à jour et exploité comme prévu et que les besoins exprimés au départ continuent d'être valables.

4. Jusqu'où peut aller le vérificateur sans nuire à son indépendance?

Les vérificateurs risquent toujours de compromettre leur objectivité en essayant de comprendre la situation de l'entité vérifiée et d'être ouverts envers elle. Ceci est particulièrement vrai dans le cas de la vérification avant la mise en oeuvre. Ainsi, il y a fort à craindre que le vérificateur en vienne à prendre part effectivement à la conception des contrôles plutôt que de jouer simplement son rôle de « conseiller ». En outre, même s'il s'en tient à ce rôle limité, le vérificateur peut devenir trop engagé face à la configuration du système résultant pour pouvoir l'évaluer en toute impartialité après sa mise en oeuvre.

On considère toutefois que les avantages de ce type de vérification justifient amplement les risques éventuels et que, de toute façon, les possibilités d'un manque d'objectivité peuvent être minimisées par un contrôle judicieux de la nature et de la portée de la participation du vérificateur et par l'adoption d'une stratégie de mission appropriée.

Contexte de cette notice d'interprétation de la politique

La position de la présente NIP s'énonce comme suit: les vérifications avant la mise en oeuvre doivent être effectuées pour les principaux systèmes en cours d'élaboration dans les ministères et organismes; de plus, elles doivent se refléter dans les politiques et les plans de vérification interne des ministères et des organismes; enfin, la possibilité d'un manque d'objectivité de la part du vérificateur peut être minimisée par l'établissement d'un mandat approprié et d'une stratégie de mission adéquate.

Mesures

Nous avons l'intention de prendre une ou plusieurs des mesures suivantes, selon la nature des retours d'information que nous recevrons des vérifi- cateurs internes :

1. Rédiger un chapitre sur la vérification avant la mise en oeuvre, qui sera intégré au Volume II du Manuel de vérification interne du CCIVI.
2. Préparer un guide sur la vérification avant la mise en oeuvre, qui sera intégré au Volume III du Manuel.
3. Intégrer les lignes directrices sur la vérification avant la mise en oeuvre dans les chapitres existants du Manuel.
4. Préparer les modifications à apporter aux sections pertinentes des Normes lors de leur prochaine révision.

Les vérificateurs internes sont invités à faire part à la DESEVI de leurs commentaires sur le document de travail ci-joint. On en tiendra compte lors de l'établissement du contenu et de la disposition des lignes directrices à venir concernant cette importante question.

Introduction

Ce document de travail a pour but d'explorer divers aspects de la participation des vérificateurs à l'élaboration des systèmes, que nous désignerons fréquemment ci-après par l'expression « vérification avant la mise en oeuvre ».

Nous exposerons plus précisément ici les antécédents de ce type de vérification, sa définition, son champ d'application, son objet, ses répercussions sur d'autres aspects de la fonction de vérification et des moyens possibles de la mettre en pratique.

Antécédents

Plusieurs facteurs incitent les vérificateurs internes à participer à des projets d'élaboration de systèmes: en effet, l'élaboration de systèmes est reconnue comme occasionnant des dépassements de coûts ou de délais; les systèmes ainsi mis en oeuvre ne répondent pas toujours, loin de là, aux besoins des utilisateurs; les cadres de contrôle des systèmes, en particulier des systèmes informatisés, ne sont souvent pas suffisamment élaborés; et les récents programmes de réduction des coûts, résultat d'une économie récessionnaire et des lourds déficits, ont fait ressortir le besoin d'accroître la productivité et l'efficacité de tous les processus. Le processus d'élaboration des systèmes fait donc l'objet d'un intérêt tout particulier en raison des effets néfastes et fort coûteux pouvant découler d'une conception et d'une mise en oeuvre inadéquates.

La plupart des ouvrages portant sur la vérification ont reconnu l'utilité éventuelle de la vérification avant la mise en oeuvre; mais leurs auteurs ne faisaient pratiquement référence qu'aux systèmes d'information du TED. Cette approche comporte toutefois deux limites: d'une part, les systèmes ne sont pas tous des systèmes « d'information » et, d'autre part, le TED n'est qu'un des moyens possibles de mettre les systèmes en oeuvre. Dans les pages qui suivent, nous envisagerons donc les systèmes dans une perspective plus vaste.1

Plusieurs passages des Normes de vérification interne2 reflètent l'utilité de la vérification avant la mise en oeuvre :

1. la norme 2, portant sur le champ d'application, stipule que « Le champ d'application de la vérification interne doit comprendre tous les aspects du fonctionnement d'un ministère. Le vérificateur doit, après évaluation, se prononcer sur:
   1. la conception, l'élaboration, la mise en place et le fonctionnement de tous les systèmes, procédures, processus et contrôles, y compris les systèmes informatiques; » ...
2. la norme 3, portant sur la fréquence, ajoute que « Tous les principaux systèmes, fonctions et unités organisationnels exécutant des tâches d'une certaine importance devraient être examinés sur une période ne dépassant pas trois à cinq ans. »
   1. Un système s'entend d'un ensemble d'éléments interreliés suivant une structure cohérente. Si les éléments sont importants, ce sont les liens ou les rapports entre ces éléments, définis en termes d'objectif commun, qui permettent de circonscrire un système. - Extrait de Managing Public Systems: Analytic Techniques for Public Administration, par Michael J. White, Clayton Ross, Robert Myrtle, Gilbert Siegel et Aaron Rose.
   2. Conseil du Trésor du Canada, contrôleur général, Normes de vérification interne dans le gouvernement du Canada.
3. le Chapitre deux qui élabore sur les normes 2 et 3, révèle clairement que la vérification avant la mise en oeuvre doit s'occuper des nouvelles lois, des nouvelles ententes et des contrats passés par le ministère concerné.

Définition

Comme nous l'avons indiqué plus haut, nous appellerons « vérification avant la mise en oeuvre » la participation du vérificateur à l'élaboration des systèmes et nous considérerons le mot « système » dans son sens le plus large qui englobe tous les principaux mécanismes infrastructurels d'une organisation, notamment: les lois, les politiques et les procédures; les systèmes d'information (informatisés ou autres); les systèmes et processus de production; les ententes et les contrats; et les structures organiques. La figure 1 présente une infrastructure type ainsi que les rapports qu'elle suppose.

Champ d'application et objet de la vérification avant la mise en oeuvre

Le champ d'application d'une vérification avant la mise en oeuvre comporte deux facettes. La première touche les entités sujettes à ce type de vérification: elles ont déjà été définies plus haut comme regroupant les principaux nouveaux systèmes (l'infrastructure) et doivent englober les travaux importants de remodelage des systèmes existants.

La deuxième facette concerne le type de participation qui doit être envisagé. Il en existe deux :

1. la vérification du processus de gestion des projets et d'élaboration des systèmes;
2. la vérification du cadre de contrôle, qui est conçu parallèlement au système en cours d'élaboration ou qui en constitue une partie intégrante.

Le premier type de vérification a pour but d'assurer à la direction que le processus d'élaboration adhère aux politiques et pratiques prescrites (par les organismes centraux) ou généralement acceptées, qui font en sorte que des systèmes valables sont conçus, élaborés et mis en place et que le processus d'élaboration est économique, efficient et efficace. Le second type de vérification assure à la direction que des contrôles adéquats de gestion et d'exploitation sont conçus, élaborés et mis en place et, par le fait même, que les opérateurs, les gestionnaires et les utilisateurs d'un système seront en mesure d'en évaluer le fonctionnement. Infrastructure

Une même justification, en deux volets, sous-tend les deux types de vérification. Tout d'abord, il est plus facile et moins coûteux d'assurer dès le départ la conception adéquate d'un système que d'y apporter des modifications après sa mise en oeuvre; ensuite, les systèmes qui seront utilisés de façon répétée doivent être conçus et gérés avec plus de soin dès le lancement du projet pertinent en raison des effets négatifs que pourrait avoir sur l'efficacité et l'efficience de l'exploitation un processus de conception et d'élaboration inadéquat.

La vérification avant la mise en oeuvre permet, en outre, de mieux percevoir le rôle de contrôle confié à chacun des participants (gestionnaires, utilisateurs, concepteurs de systèmes, et le reste).

Répercussions de la vérification avant la mise en oeuvre sur d'autres aspects de la fonction de vérification

Il faut ici considérer deux aspects: les répercussions sur les autres types de vérification et celles sur l'indépendance de la fonction de vérification.

Une vérification effectuée avant la mise en oeuvre devrait permettre de réduire le nombre de résultats orientés vers les systèmes que le groupe de vérification relèvera subséquemment, sans toutefois les supprimer complètement. Il y a trois raisons à cela; il est fort improbable que la conception d'un système soit parfaite dès le départ; et, même si elle l'était, il est fort improbable que le système soit mis en oeuvre, tenu à jour et exploité exactement comme prévu; enfin, il est fort improbable aussi que les conditions ou exigences originales du milieu se maintiennent pendant toute la vie du système.

L'indépendance est un aspect difficile à traiter en raison de sa nature très subjective. Chaque vérificateur et chaque gestionnaire perçoivent souvent à leur façon l'indépendance et les facteurs qui la compromettent. Dans ce contexte, les lignes directrices suivantes pourraient s'avérer utiles :

1. éviter de participer à la conception proprement dite (ceci rejoint la règle voulant que les vérificateurs ne prennent pas part à des opérations qu'ils auront par la suite à vérifier);
2. indiquer si des « contrôles clés » sont nécessaires sans toutefois en préciser la forme (c'est-à-dire indiquer le « quoi » mais non le « comment »);
3. négocier bien à l'avance les règles de base de la participation afin que toutes les parties comprennent et acceptent leurs rôles respectifs --l'indépendance et l'objectivité peuvent ici être citées comme des buts à atteindre (par exemple, préciser que les gestionnaires utilisateurs doivent fournir les objectifs de contrôle, que les concepteurs de systèmes doivent élaborer les contrôles et que les vérificateurs doivent en juger l'à-propos);
4. s'assurer que le vérificateur qui participe à la vérification d'un système avant sa mise en oeuvre ne sera pas chargé par la suite d'évaluer ledit système une fois qu'il sera en opération.

Les possibilités d'une certaine forme de subjectivité au cours de l'exécution de ce type de vérification ne peuvent être supprimées complètement; elles peuvent néanmoins être limitées. Un contrôle judicieux du degré de participation du vérificateur peut minimiser à la fois l'existence et l'apparition d'un manque d'objectivité.

Moyens possibles de mettre en pratique la vérification avant la mise en oeuvre

L'on suppose au départ que tous les plans et politiques de vérification interne des ministères et des organismes prévoient une vérification avant la mise en oeuvre conformément aux dispositions des Normes.

Parmi les autres conditions essentielles au succès de la mise en oeuvre de telles vérifications, citons: l'obligation (établie dans les politiques ou les directives du ministère ou de l'organisme) pour les gestionnaires de faire part au responsable de la vérification interne de tous les principaux projets d'élaboration de systèmes (ce qui n'empêche pas le groupe de la vérification interne d'exercer sa propre forme de surveillance par l'examen des plans et de toute autre documentation pertinente et par des contacts directs avec les gestionnnaires); l'obligation pour les gestionnaires ou les chefs de projets d'inviter le groupe de vérification interne à participer à toutes les activités importantes d'élaboration de systèmes (y compris une participation aux travaux des équipes d'élaboration de systèmes, des comités directeurs d'élaboration des systèmes, etc.); un appui concret de la haute direction à une telle participation; et l'affectation d'un nombre suffisant de vérificateurs supérieurs qualifiés qui, par leur participation, donneront une note de crédibilité aux systèmes ainsi élaborés et à la vérification interne elle-même (on pourra engager des vérificateurs de l'extérieur à contrat si les budgets alloués le permettent).

Même si le présent document ne constitue pas un guide détaillé de la vérification avant la mise en oeuvre, voici certaines suggestions qui méritent d'être étudiées de près.

1. Bien qu'il soit souhaitable que le vérificateur connaisse le domaine du système proposé (par exemple: finances, personnel, activité ou programme particulier) ainsi que les techniques qui seront utilisées pour la conception du mode d'exploitation (par exemple: le TED, la micrographie), il faut se rappeler que le vérificateur interne doit avant tout jouer le rôle de contrôleur, sans nécessairement être un spécialiste du domaine traité.
2. Il faut se rappeler aussi que la principale différence entre la vérification effectuée avant la mise en oeuvre et celle effectuée après, c'est le moment où l'une et l'autre ont lieu. Les méthodes et techniques utilisées, elles, ne varient pas beaucoup.

   Ainsi, les critères régissant la vérification du processus d'élaboration des systèmes comprennent ceux qui ont été établis pour la gestion des projets, la passation des marchés et les systèmes de TED dans le Manuel de la politique administrative et dans le Guide d'administration financière. On consultera également les guides pertinents du CCIVI (par exemple, ceux qui portent sur le TED).

   La vérification avant la mise en oeuvre du cadre de contrôle établi « à l'intérieur » ou « autour » du système en cours d'élaboration s'effectuera à partir d'un modèle de contrôle normatif prédéterminé, comme pour toute autre vérification, sauf qu'on n'aura ici qu'une représentation sur papier d'un cadre de contrôle réel pour établir une comparaison, plutôt qu'un cadre concret comme celui qui existe pour la vérification effectuée après la mise en oeuvre du système.

3. La vérification avant la mise en oeuvre repose sur deux principes fondamentaux :
   1. chaque système doit contenir en lui-même les moyens permettant à l'opérateur et au gestionnaire responsable de déterminer s'il fonctionne comme prévu, c'est-à-dire qu'il doit englober des contrôles;
   2. si le vérificateur prend part à la vérification avant la mise en oeuvre d'un seul élément de l'infrastructure (voir la figure 1), il lui faut être très conscient de sa position et de son rôle dans la hiérarchie établie. On ne peut pas raisonnablement s'attendre à retrouver à chaque niveau le même degré de spécificité et de précision dans la détermination des objectifs, des critères, etc., et des contrôles associés. Ainsi, au niveau le plus élevé (celui des lois), on ne peut s'attendre que les concepteurs incorporent des procédures de mise en application et des critères de performance aussi détaillés qu'au niveau des systèmes et des procédures. On ne peut s'attendre qu'à une élaboration progressive de haut en bas de la hiérarchie, ainsi qu'à un certain degré d'uniformité et de continuité entre les niveaux.

      En général, lorsqu'un vérificateur prend part à une vérification avant la mise en oeuvre à un niveau intermédiaire de la hiérarchie, il importe qu'il soit au courant du rôle des éléments adjacents (niveaux supérieurs, inférieurs et similaires) à l'intérieur de la structure afin d'être en mesure d'évaluer le degré d'uniformité et de continuité.

4. Les vérificateurs assignés aux vérifications avant la mise en oeuvre doivent être les vérificateurs supérieurs du groupe, du niveau de compétence le plus élevé. Cela est essentiel en raison de la nature particulière (répercussions descendantes) de l'entité vérifiée.
5. Le début de la participation du vérificateur coïncidera idéalement avec la formation initiale de l'équipe d'élaboration du système, mais ne sera pas ultérieure à l'énoncé des besoins des utilisateurs.
6. Le plus souvent, la participation des vérificateurs à une vérification avant la mise en oeuvre ne se fera pas à temps plein, mais plutôt à certains points précis au cours du processus d'élaboration (par exemple, pendant ou juste avant la transmission des spécifications des utilisateurs au concepteur du système; l'acheminement de la conception du système au programmeur ou au rédacteur des procédures; la mise au point finale du système et son acceptation par l'utilisateur). Ce type de participation par étape peut rendre difficile le processus d'affectation des ressources; toutefois, une collaboration étroite entre le gestionnaire responsable et le chef du projet d'élaboration du système pourra minimiser ce problème.
7. La première vérification après la mise en oeuvre d'un nouveau système, ou d'un changement majeur à un système, devra avoir lieu au plus tôt six mois après sa remise entre les mains des utilisateurs ou opérateurs, c.-à-d. après qu'il soit passé d'un état transitoire à un état relativement stable.

Conclusions

La vérification avant la mise en oeuvre est un outil de gestion valable. Son utilité est reconnue dans les ouvrages portant sur la vérification et se reflète dans les Normes.

Ce type de vérification s'applique à toutes les principales infrastructures (systèmes) en cours d'élaboration. Elle comporte deux activités distinctes: la vérification du processus d'élaboration et la vérification du cadre de contrôle établi.

Les méthodes et techniques de vérification avant la mise en oeuvre ne diffèrent guère de celles de la vérification effectuée après la mise en oeuvre. Toutefois, le vérificateur qui les applique doit faire preuve de très grandes aptitudes en raison des répercussions descendantes d'une telle activité.

Bibliographie

1. Lambrix, Robert J. et Singhui, Surendra S. "Preapproval Audits of Capital Projects", in Harvard Business Review (mars-avril 1984).
2. Moser, J.W. "Évaluation des contrôles d'un système informatique pendant la phase de conception", in Communiqué V.I. (février l983), Conseil du Trésor du Canada, Bureau du contrôleur général, Division des études spéciales et de la vérification interne.
3. Rittenberg, Larry E. Auditor Independence and Systems Design, The Institute of Internal Auditors, Inc., Altamonte Springs (Florida), U.S.A., 1977.
4. Stidwell, Joanne. "Improving the System Development Life Cycle", in C.A. Magazine (édité par Donald A. Brown).
5. The Institute of Internal Auditors. Standards for the Professional Practice of Internal Auditing. The Institute of Internal Auditors, Inc., Altamonte Springs (Florida), U.S.A., 1978 (dernière réimpression, février 1984).
6. Le Conseil du Trésor du Canada (Bureau du contrôleur général). Normes de vérification interne dans le gouvernement du Canada, Conseil du Trésor du Canada, 1982.
7. Le Conseil du Trésor du Canada. Manuel de la politique administrative, Conseil du Trésor du Canada.
8. Wysong, Jr., Dr. Earl M. "Using the Internal Auditor for Systems Design Projects", in Journal of Systems Management (juillet 1983). Association for Systems Management, Cleveland, (Ohio), U.S.A.

Notes en fin de texte

1. Voir les Normes de vérification interne dans le Governement du Canada. 

2. Voir le Chapitre 440 du Manuel de la politique administrative.