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.