Secrétariat du Conseil du Trésor du Canada
Symbole du gouvernement du Canada

ARCHIVÉ - Systèmes en cours d'élaboration (Guide de verification) - le 1 mars 1991

Avertissement Cette page a été archivée.

Information archivée dans le Web

Information archivée dans le Web à  des fins de consultation, de recherche ou de tenue de documents. Cette dernière n’a aucunement été modifiée ni mise à  jour depuis sa date de mise en archive. Les pages archivées dans le Web ne sont pas assujetties aux normes qui s’appliquent aux sites Web du gouvernement du Canada. Conformément à  la Politique de communication du gouvernement du Canada, vous pouvez demander de recevoir cette information dans tout autre format de rechange à  la page « Contactez-nous Â».


Détail du Processus d'élaboration des systemes

Introduction

Ce chapitre décrit le cycle d'élaboration des systèmes, ainsi que les rôles joués dans ce cycle, de façon suffisamment détaillée pour permettre aux vérificateurs de procéder à une vérification de l'élaboration, à n'importe quelle étape du cycle d'élaboration (CES) telle qu'intégrée par un ministère à son propre processus d'élaboration des systèmes (PES). Cela signifie que le vérificateur devrait être en mesure d'évaluer les progrès du projet, de comparer les réalisations tangibles à celles jugées normales par le présent guide pour l'étape d'élaboration à l'étude. Ainsi, il devrait pouvoir situer le projet par rapport à la norme. Le vérificateur pourra alors choisir, parmi les objectifs de vérification donnés à ce stade du CES normal, les objectifs qui s'appliquent au projet donné.

Le cycle d'élaboration des systèmes

La politique sur la « Gestion des technologies de l'information » diffusée en juin 1990 par le Conseil du Trésor remplace le chapitre 440.3 (Appendice J du présent guide) du Manuel de la politique administrative du Conseil du Trésor (1978). Le chapitre 440 définissait le cycle d'élaboration des systèmes sur lequel se fondait le présent guide. Même si le Conseil du Trésor n'impose plus un CES en particulier, le présent guide demeure valable pour ce qui est de définir la vérification d'un CES conforme aux pratiques acceptées d'élaboration des systèmes.

Le but d'un CES est de permettre aux concepteurs et aux utilisateurs de produire un système contrôlé, économique, efficient et efficace. Les étapes du processus d'élaboration qui suivent ont été suggérées par le Conseil du Trésor (MPA, 1978, Ch. 440) :

  • Lancement d'un projet
  • Étude de faisabilité
  • Conception générale
  • Conception détaillée
  • Mise en oeuvre
  • Mise en place
  • Activités postérieures à la mise en place

Même si le CES conventionnel consiste en un cycle à sept étapes, les CES particuliers de ministères peuvent en comporter plus ou moins. Par contre, à partir du travail contenu dans chaque étape ou combinaison d'étapes d'un CES, on peut mesurer le progrès en établissant des liens avec la norme en matière de réalisation des sept étapes (voir la figure 3). Par conséquent, comme il a été mentionné précédemment, les objectifs et les critères de vérification présentés au chapitre 3 peuvent être choisis pour la vérification d'un système donné parmi les objectifs chronologiques du présent guide qui s'appliquent à la phase de vérification en question ou à des phases antérieures.

De même, une école de pensée veut actuellement que, à une époque de micro-ordinateurs, de création de prototypes ou de langages de la quatrième génération, les organismes ne puissent se permettre les contraintes d'une méthodologie officielle s'appliquant au cycle d'élaboration. Néanmoins, il incombe aux vérificateurs d'assurer l'existence de points valables pour le contrôle de la gestion, quel que soit le cycle particulier en place. A ces fins, le contenu ou les produits des étapes d'élaboration, qui devront avoir eu lieu dans la séquence logique du CES conventionnel, sont essentiels.

Création de prototypes

Avant que l'on procède à l'établissement d'un tableau comparatif du CES conventionnel et de le comparer à un autre exemple de terminologie, il convient d'examiner une technique d'élaboration récente.

La création de prototypes appliqués est définie dans le présent guide comme un modèle visuel dynamique qui constitue un instrument de communication pour les utilisateurs ou les responsables de l'élaboration des systèmes, d'une efficacité supérieure à celle de la simple prose ou des modèles visuels statiques lorsqu'il s'agit de décrire la fonctionnalité. Il s'agit d'une approche qui doit simuler le système final et cette technique vient s'ajouter à une méthodologie de gestion, qu'elle ne remplace pas. S'il a été clairement décidé d'adopter cette technique, la création de prototypes doit être utilisée lors des étapes de faisabilité et de conception générale afin de déterminer les exigences fonctionnelles et les exigences en matière de données, en permettant la participation des utilisateurs par une expérience pratique aussitôt que possible dans le cycle. Le vérificateur doit, aux étapes de faisabilité et de conception générale, examiner la décision de l'équipe de projets et le contrôle s'appliquant à la création de prototypes, dans le cas où cette technique a été retenue.

Le vérificateur doit veiller à ne pas confondre les prototypes et les essais pilotes. Dans le premier cas, un prototype peut avoir été créé à partir d'un logiciel non productif et, par conséquent, ne jamais devenir opérationnel. L'essai pilote, pour sa part, est conçu pour devenir opérationnel.

Le vérificateur doit veiller à ce que l'équipe comprenne bien la différence entre le prototype et l'essai pilote ou à ce que des décisions officielles aient été prises par les détenteurs du pouvoir d'approbation pour que le prototype puisse passer l'étape de conception générale (ou une étape équivalente).

Gestion des données

Le vérificateur doit être conscient du fait que les ministères ont tendance à gérer leurs données de façon formelle. Il doit également être conscient des répercussions sur l'élaboration des systèmes que peuvent entraîner, dans leur environnement, l'administration des données et l'administration des bases de données. Il pourra consulter comme référence le « Rapport sur la stratégie de gestion de l'information pour les services communs » publié en 1989 par le Comité consultatif sur la gestion de l'information du SCT.

La Figure 2 ci-après illustre un exemple de méthodologie d'élaboration, sous forme d'un graphique de cheminement, pour un environnement qui fait appel à la gestion des données et à des techniques de conception structurées. Il ne s'agit pas de la méthode proposée pour le CES conventionnel, mais la plupart des termes et des produits des étapes sont semblables à ceux utilisés pour le CES conventionnel. En comparant les produits des étapes normalisées aux produits du système en cours d'élaboration qui fait l'objet de la vérification, le vérificateur sera en mesure de choisir, dans le présent guide, les objectifs équivalents de l'étape normalisée. Il disposera donc d'une série d'objectifs, qu'il pourra augmenter selon la nature du système donné, qui lui permettront d'assurer une vérification optimale pendant l'élaboration, quels que soient le CES particulier et les caractéristiques particulières du système.

La Figure 3 (ci-dessous, après la figure 2) présente les produits attendus pour chacune des étapes du CES conventionnel.

Figure 2 : Exemple de cycle d'élaboration des systemes non conventionnel

Exemple de cycle d'élaboration des systemes non conventionnel

Note 1 : Le dictionnaire de données actif permet à l'ordinateur un plus grand contrôle des méta-données (données sur les données dans le système) que le dictionnaire passif.

Figure 3 : CES conventionnel - Produits attendus par étape

Étape Activité Produit
Lancement
  • Demandes de filtrage
  • Détails des documents
  • Planification et approbation
  • Rapport de lancement
  • Définition des problèmes
  • Approche
  • Rôles/Plan du projet
Faisabilité
  • Recueil des données
  • Analyse des données
  • Élaboration de solutions de rechange
  • Évaluation du design conceptuel
  • Rédaction du rapport
  • Rapport de faisabilité
  • Besoins de l'utilisateur
  • Évaluation des systèmes de rechange
  • Design conceptuel
  • Concept
  • Plan du projet
  • Recommandations
Conception générale
  • Recueil des données
  • Analyse
  • Esquisse du système
  • Esquisse des contrôles
  • Assurance qualitative, objectif performance / secondaire
  • Objectifs en matière de sécurité
  • Validation des besoins de l'utilisateur
  • Planification et approbation
  • Rapport de conception générale
  • Coûts/Avantages révisés
  • Spécifications fonctionnelles
  • Contrôles
  • Exigences techniques révisées
  • Plan du projet révisé
  • Plan de conception détaillée
Conception détaillée
  • Conception des sous-systèmes
  • Création des sous-systèmes
  • Conception des aides à l'utilisateur
  • Conception des tests pour le système
  • Conception de la conversion
  • Préparation du rapport
  • Planification et approbation
  • Rapport de conception détaillée
  • Coûts/Avantages révisés
  • Exigences techniques révisées
  • Description du système
  • Procédures pour l'utilisateur
  • Plan du projet révisé
  • Plans de mise en oeuvre et de mise en place
  • Plan de formation
Elaboration
  • Codage des logiciels
  • Tests du système et des unités
  • Production d'aides à l'utilisateur
  • Planification et approbation
  • Rapport de mise en oeuvre
  • Programmes documentés
  • Manuel de prodécure pour l'utilisateur
  • Manuels de formation et d'opérations
Mise en oeuvre
  • Installation des équipements
  • Tests pour les accepter
  • Formation et conversion
  • Opération et approbation
  • Achèvement du projet
  • Avis d'approbation
Activités postérieures à la mise en place
  • Rajustements apportés au système
  • Recueil des données sur  les activités postérieures
  • à la mise en place
  • Rapport d'évaluation

Description des étapes

1. Étape de lancement d'un projet

Les activités exécutées à cette étape doivent être la définition formelle du mandat du projet et l'établissement de ses paramètres de contrôle.

Les procédures à l'égard d'un projet comportent un examen préliminaire du système existant (s'il en existe un) afin d'évaluer la nécessité de changements et la nature de ces derniers. On doit donc définir le « problème ». Une solution potentielle doit être conceptualisée pour servir de référence pendant l'étape d'étude de faisabilité. La solution ne doit pas être décrite trop en détail, cela pouvant nuire aux solutions de rechange examinées lors de l'étude de faisabilité.

A ce moment, on doit déterminer toutes les contraintes externes et internes (coût, temps, législation, lignes directrices du ministère, besoins de l'utilisateur, etc.), et évaluer leur incidence sur le problème et sur la solution qui aura été retenue. On doit également évaluer lors de cette étape la question de la sécurité, y compris les exigences concernant la relance informatique à la suite d'un sinistre, ainsi que les points se rapportant à la protection des renseignements personnels.

Le produit obtenu lors de cette étape consiste en un rapport de lancement du projet.

2. Étape de faisabilité

A la fin de cette étape, on devrait avoir déterminé une solution convenant au problème ainsi qu'un plan préliminaire pour sa mise en oeuvre.

Les exigences de l'utilisateur, qui peuvent être documentées ou établies par la création de prototypes, servent de fondement à la solution retenue.

Il est de la plus grande importance d'étudier suffisamment d'autres approches possibles. Une analyse détaillée des différentes solutions de rechange, au niveau conceptuel, doit appuyer le choix officiel de la solution proposée. Cette analyse doit comporter une analyse coûts/avantages (ou des techniques semblables) et envisager les contrôles financiers et opérationnels, de même que la compatibilité organisationnelle. Comme à l'étape de lancement du projet, on doit s'assurer que les évaluations sont objectives et complètes, et qu'elles ne favorisent pas une solution particulière.

On doit préciser les exigences en matière de ressources pour le reste du projet et procéder à une évaluation du temps et du coût nécessaires, pour leur approbation par la gestion. L'énoncé des exigences réparties entre chacune des étapes du projet, servira à contrôler son élaboration.

Les éléments qui précèdent doivent être documentés dans un rapport de faisabilité.

3. Étape de conception générale

Le travail accompli lors de cette étape transposera la solution conceptuelle proposée, qui aura été déterminée pendant l'étude de faisabilité, en une solution pratique se prêtant à la conception détaillée et à la mise en oeuvre.

Ce travail exigera :

  • la préparation d'une esquisse du système, y compris les graphiques de cheminement, les critères de performance du système, ainsi que la spécification, la définition et le formatage préliminaire de toutes les entrées et sorties, et de tous les fichiers utilisés ou produits par le système; (cela demandera des contacts intensifs avec les utilisateurs.)
  • une vue d'ensemble du cadre de contrôle interne et des procédures de fonctionnement pour que l'on puisse s'assurer qu'elles répondent aux objectifs du système en cours d'élaboration, (le système proposé doit satisfaire à toutes les exigences de l'utilisateur.)
  • la sélection d'installations et de descriptions de tâches pour les fournisseurs ou les façonniers;
  • une esquisse de toutes les spécifications fonctionnelles permettant de s'assurer que la conception générale répond à tous les objectifs du système déterminés.
  • les coûts révisés, les évaluations de temps et les autres critères se rapportant aux étapes à venir, pour leur approbation par la gestion.

La documentation de l'information recueillie lors de cette étape sera normalement incluse dans un rapport sur la conception générale. Il est possible que certains ministères préfèrent préparer deux rapports, dont un pour mettre en évidence la conception du système de gestion lui- même. Dans tous les cas, ces éléments doivent être clairement documentés.

4. Étape de conception détaillée

Des procédures détaillées et des spécifications informatiques sont produites à partir des spécifications fonctionnelles énoncées lors de l'étape de conception générale. Tous les contrôles, procédures, cheminements du travail, documents des entrées et des sorties, logiques de traitement, dispositions des fichiers et des bases de données, ainsi que les éléments de données seront complètement mis au point.

L'approbation de cette étape de conception par la gestion et les utilisateurs est d'une importance capitale. Par conséquent, le produit final de cette étape, le rapport de conception détaillée, doit contenir, outre les spécifications des programmes et les cheminements du travail détaillés, etc., une description non technique de tout le système, qui comprendra :

  • une description du système, des objectifs, des entrées et des sorties;
  • un graphique de cheminement, indiquant le design conceptuel.

Les cadres de gestion concernés doivent examiner les spécifications détaillées, ainsi que les exigences techniques.

On doit également produire, lors de cette étape, des plans documentés d'essai des systèmes, ainsi que des plans de mise en oeuvre et de conversion. En outre, on produira un plan portant sur la façon dont seront coordonnées les activités des étapes de mise en oeuvre et de mise en place, ce qui comportera la préparation de manuels d'instruction (pour les utilisateurs et les opérateurs). On devra également définir les procédures de formation, de sécurité, de sauvegarde et de conversion.

5. Étape de mise en oeuvre

Les activités de cette étape aboutiront à la création de tous les programmes, formules, manuels et documents de formation pour l'informatique nécessaires à un système opérationnel.

Une logique de programmation détaillée sera conçue et des logiciels d'application seront codés.

Les manuels se rapportant à l'utilisation, aux opérations et à la formation seront mis au point et devront, le cas échéant, couvrir les points suivants :

  • la saisie des données
  • la validation des données
  • les pistes de vérification et les mécanismes de contrôle du système
  • la vérification des rapports d'analyse
  • les consignes d'exploitation de l'ordinateur
  • les procédures de sauvegarde et de réexécution
  • les procédures de sécurité

Tous les aspects du système, y compris la logique des programmes et les procédures opérationnelles, doivent être complètement mis à l'essai. De même, toutes les procédures nécessaires à la mise en place du système doivent être définies et faire l'objet d'un calendrier.

6. Étape de mise en place

Lors de cette étape, le système est rendu opérationnel. Le travail comportera la conversion des fichiers existants (s'il y en a) ou la création de la base d'information initiale, la formation convenable du personnel participant au système (utilisateur et informatique), ainsi que l'établissement de procédures de contrôle ou de procédures opérationnelles, par une gradation d'opérations pilotes ou parallèles. Toute la documentation provenant des étapes antérieures doit être finalisée. Les procédures de conversion et de mise en place doivent faire l'objet d'un examen et d'essais. Le gestionnaire de projets doit alors présenter un avis formel d'achèvement du projet pour qu'il soit approuvé.

7. Étape d'activités postérieures à la mise en place

Le travail effectué lors de cette étape consiste en un examen de la performance du projet et de la performance du système par rapport à la documentation de projet originale sur les coûts/avantages du système, ainsi qu'avec le coût du projet et les calendriers.

Un certain délai est normalement alloué entre la mise en place et la vérification postérieure à celle-ci. L'équipe de vérification peut alors être également changée pour maximiser l'objectivité, ce qui réduira par contre l'efficacité de la vérification.

Ainsi, les examens du projet peu de temps après la mise en place d'un système sont importants afin d'évaluer le succès du processus d'élaboration des systèmes et de relever toute différence entre la conception des contrôles et leur fonctionnement.

Conclusion de la description des étapes

Comme on l'a indiqué précédemment, il doit exister des normes adéquates dans les ministères, qui doivent être suivies pour chaque étape de CES afin d'assurer un contrôle cohérent et complet de la gestion sur la mise en oeuvre. Toutefois, il peut être approprié que le ministère ait défini et approuvé un ensemble distinct d'activités de CES se fondant sur le genre de projet qui est en cours (c.-à-d. l'élaboration des systèmes majeurs ou mineurs). Il est normal de documenter l'approbation que la gestion a apportée à toute déviation vis-à-vis des normes du ministère.

Dans de nombreux cas d'élaboration par l'utilisateur final de micro ou de mini-ordinateurs, un examen de l'importance revêtue par les données ou par l'information pour l'organisation peut justifier une partie ou la totalité des points de CES se rapportant aux contrôles.

En évaluant si l'élaboration ou la modification d'un système est assez minime pour justifier le regroupement ou l'élimination de quelques-unes des étapes de CES, le vérificateur doit garder présent à l'esprit le fait que certains changements relativement mineurs peuvent revêtir une importance très grande du point de vue des contrôles.

Rôles

Les descriptions typiques qui suivent illustrent comment chaque étape du modèle de CES fournit à la gestion une assurance de contrôle, d'économie, d'efficacité et d'efficience. Il s'agit de descriptions élémentaires; les vérificateurs peuvent néanmoins s'attendre à rencontrer de telles personnes ou de telles activités dans un environnement contrôlé. Ces rôles, ou leur équivalent, et d'autres rôles figurent à l'appendice A comme des personnes à qui poser les questions liées aux objectifs et critères proposés pour chaque étape de vérification.

Gestion

La gestion doit jouer un rôle d'examen pour assurer que le système élaboré réponde aux objectifs de l'organisme. La gestion assigne des priorités aux projets, aux budgets et aux échéanciers. C'est la gestion qui établit les politiques et les normes du ministère pour l'élaboration des systèmes, puis qui exerce son contrôle sur le processus d'élaboration en s'assurant qu'un CES soit en place et fonctionne d'après son analyse.

La gestion a une responsabilité majeure, soit de décider l'importance du risque pouvant être toléré dans un projet.

Il est possible que la gestion ait besoin de l'aide technique de tiers pour l'aider à assurer ses responsabilités.

Comité directeur ou personnes dotées du pouvoir d'approbation

Chaque organisme gouvernemental nomme en général une personne dotée du pouvoir d'approbation pour chaque étape du processus d'élaboration. Ensemble, ces personnes représentent le pouvoir d'approbation. Certains ministères ont un comité directeur de l'informatique au niveau du SM chargé d'examiner tous les rapports de vérification des systèmes. Ce comité dispose parfois de l'approbation finale. Le point clé dans la vérification interne est de s'assurer qu'il existe sur place la preuve d'un processus d'approbation formel, avec pouvoir de signature à l'échelon des cadres supérieurs.

Concepteur/analyste

Le concepteur/analyste reprend les exigences de l'utilisateur pour élaborer un système répondant aux objectifs et aux besoins de celui-ci. Le concepteur s'assure que toutes les exigences et tous les besoins ont été recueillis, et que l'analyse du système est fonctionnelle. Le concepteur/analyste a également la responsabilité d'un contrôle général du système sur les données qui dépassent ou intègrent les contrôles de programme individuels, et doit choisir la solution d'analyse technique optimale convenant au système. Le vérificateur doit s'assurer que le rôle de contrôle de l'analyste n'est pas compromis par le gestionnaire de projet ou toute autre personne.

Programmeur

Le programmeur est responsable de la création d'un programme efficace et efficient à partir d'une spécification du programme reçue de l'analyste ou du représentant fonctionnel. Le programme peut être un dialogue ou un module du système global et les contrôles figurant dans la spécification doivent permettre de s'assurer que les données conservent leur intégrité tout le long du processus de traitement. Le programmeur voit à mettre en place les contrôles sur les données dans le processus de mise en forme des entrées, dans le traitement informatique interne des programmes, ainsi que dans les sorties affichées, communiquées ou imprimées.

Utilisateurs

C'est l'utilisateur qui doit clairement définir et appuyer les objectifs, les exigences et les besoins auxquels le système doit satisfaire dans les étapes initiales d'élaboration. Il est également de sa responsabilité d'établir les exigences en matière de contrôle technique non informatique et de s'assurer que le système qui en résulte réalise le contrôle demandé. L'utilisateur peut avoir besoin de l'aide technique de tiers pour s'assurer que le contrôle voulu soit en place.

Processus de sécurité dans le ministère

Le chapitre 440 du Manuel de la politique administrative du Conseil du Trésor indique les responsabilités, en matière de sécurité du ministère, de la GRC, du ministère des Approvisionnements et Services, du ministère des Communications, du ministère des Travaux publics et de l'Équipe d'inspection et d'évaluation de la sécurité en informatique. En outre, ce chapitre indique brièvement le rôle de l'agent de sécurité du ministère et du Comité consultatif de la sécurité, dans le cadre des deux activités de coordination et d'administration de la sécurité. Chaque ministère doit fournir, directement ou en consultant l'Équipe d'inspection et d'évaluation de la sécurité en informatique de la GRC, des conseils, des normes et une évaluation des contrôles physiques (et non logiques) nécessaires dans ce ministère pour les données, l'information et les actifs matériels. La délégation de signature, émanant de l'autorité d'approbation, doit être en évidence à chaque étape du projet d'élaboration des systèmes.

Le point 12 de l'appendice J contient d'autres références concernant la sécurité.

Gestionnaire ou administrateur des données dans le ministère

La gestion des données et de l'information acquiert dans de nombreux ministères une importance renouvelée du fait qu'elle constitue un élément d'actif critique. On peut décrire l'administration des données comme regroupant les fonctions de planification, d'administration et de contrôle des données se rapportant aux activités d'un organisme. Le personnel provenant du secteur de la gestion ou de l'administration des données doit être considéré comme membre clé de l'équipe de projet.

Administrateur de la base de données du ministère

L'administration de la base de données regroupe la planification, les décisions, le contrôle et toute autre fonction menant directement aux bases de données opérationnelles, ou ayant une incidence directe sur celles-ci.

Là où il existe une distinction, dans le domaine technique, entre l'analyste et l'administrateur de la base de données, le vérificateur doit s'assurer que ce dernier fait partie de l'équipe de projet.

Vérificateurs internes

Les vérificateurs internes doivent examiner et évaluer les contrôles de gestion utilisés dans l'élaboration de nouveaux systèmes d'application ou d'améliorations importantes. Ils chercheront des preuves d'une participation réelle de l'utilisateur dans l'analyse et l'acceptation du système; ils chercheront également des preuves d'une attention réelle portée à l'analyse détaillée du système et des procédures pour apporter un contrôle général et un contrôle dans l'application.

Le degré exact de participation des vérificateurs à l'élaboration des systèmes est déterminé par le risque encouru par l'organisme pour l'activité d'élaboration. Ce risque se compose des éléments de coûts d'élaboration, de coût opérationnel et de la dépendance de l'organisme vis-à-vis de l'information traitée. L'activité d'analyse et d'élaboration des systèmes représente aujourd'hui une part croissante du temps et des dépenses des organismes, et ces derniers sont plus dépendants que jamais vis-à-vis du fonctionnement continu de leurs systèmes informatiques. Le vérificateur doit, tout comme il établit l'importance relative de leurs constatations, donner les raisons pour lesquelles il a préféré certains critères à d'autres pendant l'étape de planification de la vérification. Pour ce faire, il détermine quel serait le risque pour le ministère si un contrôle de gestion particulier était mal exercé. Dans certains cas, cette approche permet de traiter de vastes projets d'élaboration des systèmes avec très peu de vérificateurs.

Il est possible que le vérificateur découvre des documents très complexes que l'on juge nécessaires pour expliquer la relation existant, dans le rôle de l'élaboration des systèmes, entre les gestionnaires de produits, les concepteurs des systèmes de communication, les administrateurs de bases de données, les détenteurs de données, les utilisateurs, les clients et de nombreux autres termes qui ont fait leur apparition pour traiter du monde plus complexe de l'informatique décrit au chapitre 1.

Sauf en ce qui concerne l'élaboration des exigences à l'égard des systèmes à l'intention du groupe de vérification, en tant qu'utilisateur du système, le vérificateur ne doit jamais être directement tenu responsable d'une activité de projet. Il se situe « en dehors » de l'équipe du projet même s'il peut lui offrir des conseils sur le contrôle, que ce soit par des lettres ou par des rapports. Il doit, dans toutes les étapes d'élaboration qui ont été décrites, vérifier que tous les points et les concepts touchant les rôles ou la présentation de rapports soient bien documentés.

Dans toutes leurs activités d'examen d'élaboration des systèmes, les vérificateurs doivent s'assurer que leur indépendance n'est pas compromise, en vue d'examens ultérieurs des systèmes en cours. On obtient normalement ce résultat en affectant des vérificateurs différents après que le système a été mis en place, lequel dépend aussi de la façon dont le vérificateur d'élaboration des systèmes observe les faiblesses de contrôle et recommande des améliorations à leur égard. Le vérificateur doit toujours s'opposer à participer à l'analyse même du système.