Audit opérationnel De la mission d’audit à la réalisation

Présentation au sujet: "Audit opérationnel De la mission d’audit à la réalisation"— Transcription de la présentation:

1 Audit opérationnel De la mission d’audit à la réalisation
SIE 2 Audit opérationnel De la mission d’audit à la réalisation

2 Mission d’Audit : réalisation
Feuille de Couverture FdeC Phase de travail sur Terrain Phase de travail sur Terrain Phase de travail sur Terrain Papiers de Travail (PdeT) Feuille de Révélation et d’Analyse de Problème (FRAP) – 1 par section

3 Audit pour un schéma directeur
Document définissant les orientations fondamentales de l’évolution d’une entreprise, notamment en ce qui concerne sa stratégie d’expansion. Les prévisions et règles associées s'expriment aussi par des plans annuels ou pluriannuels au sein des grandes fonctions de l’entreprise

4 Audit pour un schéma Directeur : Étapes
Spécification des objectifs et de leurs pertinences sur la base de ces objectifs définis et formalisés : Définition des besoins [informatiques entre autres] en relation avec les objectifs à atteindre Diagnostic de l'existant de l'entreprise [biens et matériel, ressources humaines, finances] Détection des écarts [ce qu'il faut acquérir pour réaliser les actions et atteindre les objectifs] Planification des actions : ce qu'il faut faire [par ex. acquérir un matériel, faire les travaux nécessaires pour sa mise en œuvre, recruter des compétences ou les faire acquérir à des personnes déjà en poste, dégager les budgets nécessaires].

5 Schéma Directeur : Concepts
Concepts associés Mise en cohérence de l'architecture du SIE avec la stratégie de l'entreprise [architecture de télécommunications, répartition des puissances de calcul, outils de développement, etc.] Le schéma directeur, puis les plans [informatique entre autres] ont vocation à être constamment remis en cause et actualisés en fonction des évolutions environnementales La phase de réalisation correspond aux projets d’entreprises

6 Diagnostic initial Orientations STRATEGIQUES (OS) Vers lancement étude
Politique INFORMATIQUE (PI) Rapport du diagnostic Champs de l ’Etude (CE) Environnement externe (EEX) Points de contrôle de la DG Analyse interne (EIN) Validation orientations et points clés P.I

7 Lancement du projet Vers analyse de l’AUDIT de l’EXISTANT
Constitution du Comité de Pilotage (CP) Formation et Information des Participants Planning initial Organisation de l’étude Constitution du Comité de Projet (CPJ) Points de contrôle de la DG Validation des Comités et de démarche Les comités pouvant être déjà mis en place, ces étapes sont facultatives

8 Audit de l’existant Evaluation fonctionnelle des applications
Priorités fixées & orientations validées Evaluation fonctionnelle des applications Points de contrôle du CP Evaluation des applications automatisées Architecture logique du Système Existant Rapport sur l’existant Evaluation de l’organisation Recensement des Problèmes et Risques Evaluation de la communication Vers Analyse des Besoins Indicateurs existants et métrique associée Recensement des projets en cours Architecture matérielle du Système Existant

9 Audit des besoins scénarios Questionnaires & Interviews
Vers construction Classement et Pertinence Enjeux économiques Etudes des impacts Rapport sur l’existant Solutions de types O.F.OP* Points de contrôle du CP Impacts organisationnels O=Organisationnelles F=Fonctionnelles OP=Opérationnelles Priorités fixées Choix des moyens Arbitrage des conflits Matériels et Techniques Humains et Sociaux Financiers et Budgétaires

10 Constructions de Scénarios
Définition du Sous-Système étudié Etude économique Vers SD Ressources Configurations Migrations Scénarios Sous-Système Bilans économiques et qualitatifs Scénarios retenus Impact struct. d° changement attitude acteurs Actualisation Politique Info. Points de contrôle du CP Choix et priorités Etude structurelle

11 Plan d’actions sur SD ou PI
Etude détaillée du scénario retenu Planification initiale Plan d’équipement MAJ bilans Eco et Quali Plan de financement Spécification des procédures de SUIVI, BILAN et ACTUALISATION Validation Lancement Plan d’organisation Plan des RH SD ou PI finalisé & validé

12 Du problème à la solution
Tout problème peut disposer de plusieurs « solutions » … Une définition « pédagogique » d’un problème est : Question dont la réponse peut être trouvée par la combinaison pertinente de définitions et de principes antérieurement admis … On confond souvent le fait qu’un problème peut disposer d’une seule « réponse » ou « situation finale » avec le fait qu’il existe plusieurs « chemins » pour arriver à cette « situation finale » …

13 Du problème à la solution
Trouver une solution à un problème informatique va donc consister à trouver : La (ou les) réponse(s) Les moyens les plus efficaces et efficients d’y parvenir La méthode d’audit anglo-saxonne COBIT ajoute des critères de qualité et de fiduciaire : efficacité efficience conformité fiabilité efficace adj. Qui donne les résultats escomptés efficient adj. Anglicisme. Efficace. efficience n. fém. Capacité de produire un effet utile, un rendement important. L'efficience d'une méthode, d'une machine fiduciaire adj. et n.m. se dit de valeurs (données) fondées sur la confiance à celui qui les émet

14 Problème et informatique
Combinant plusieurs facteurs Techniques Organisationnels Financiers Temporels Géographiques Soumis à des contraintes : Humaines Relationnels Objectifs et réfléchis Emotifs et Subjectifs Rationnels et irrationnels Connaissance et méconnaissance Financières Temporelles Qualitatives Quantitatives Il peut paraître simple de résoudre un problème technique sous forme d’un algorithme, dès lors que l’on maîtrise les concepts, les techniques et les outils associés … Ceci n’est vrai qu’en dehors de tout contexte humain … Or ceci n’est jamais possible …

15 * Quel est ce « ON » ? le demandeur ? Ou le questionné ?
Les sous-entendus … Quelle heure est-il ? A priori … il n’y a pas de réponse unique à un tel problème. Il manque ici des informations que l’on sous-entend généralement … Il est sous-entendu généralement que l’on demande l’heure du lieu où l’ON* se trouve … est-ce vrai ? * Quel est ce « ON » ? le demandeur ? Ou le questionné ?

16 Les points de vue … Un distributeur de billets de banque ne fonctionne pas de la même manière et n’a pas la même forme quand : On est client : On retire de l’argent On est employé de la banque On y place de l’argent On est agent technique On en assure la maintenance On est commercial du fabriquant On le vend Etc.

17 Les mises en balance Une solution apporte : Une solution nécessite :
Avec une carte bancaire Je gagne la possibilité de retirer de l’argent partout (ou presque) la possibilité de retirer de l’argent n’importe quand (ou presque) de la sécurité (moins d’argent liquide sur soi, pas de chèque sur soi, le vol est réduit avec le code secret, etc.) Je perds de l’argent (coût de l’abonnement) de la lisibilité (je dois tenir mes comptes avec des facturettes) de la sécurité (n° transmis et utilisable en téléachat sans contrôle, etc.) Je risque De perdre ma carte D’oublier mon code Etc. Une solution apporte : Des gains Des pertes Des risques Une solution nécessite : Des moyens (RH-RM) Du temps Des finances Des validations Une solution entraîne Une période transitoire Une adaptation

18 Du problème à la solution
RH Moyens (Matériels et techniques) Sécurité BIG PROBLEM INFORMATIQUE THE VERY GOOD SOLUCE Organisation Budget Finances Juridique Législation THE REAL SOLUCE Temps Délais

19 Le QQOQCCP des solutions
QUOI : Technique informatique : matériel, logiciel, réseau, etc. QUI : Qui réalise, qui installe, qui forme, qui exploite, qui … QUAND : Quand débute-t-on, quand finit-on, quand teste-t-on, … POURQUOI : Quelles raisons aujourd’hui, quelles raisons demain, … COMMENT : Quelles méthodes, quels outils, quels techniques, … OU : Où préparer, où mettre en œuvre, …

20 Penser en contraintes Contraintes génériques Techniques
Juridiques  Preuve Fiduciaires  Preuve Financières Matérielles Humaines Sociales Ressources Logistiques Sécuritaires Légales Contraintes humaines Savoir Savoir-faire Faire savoir Adaptation Changement Acceptation Contraintes temporelles Historique Transition MeO Usage Maintenance Evolution

21 Penser en terme de bilan
Equilibre Pertes de … Gains de … Risques de … Droit de … (légalité …) Pouvoir de … (autorisation …) Confiance en … (fiducie…) Moyens de … (ressources …) Accord pour … Adhésion pour … et à… Acteurs Groupes – Hiérarchie – Social

22 Penser en terme de suivi (TdB)
Le facteur temps Demain Evolution et changement Maintenance Adaptation Transitoire Doublement Apprentissage Historique Accéder Utiliser

23 Analyse de la valeur Obligation de résultat : le triangle infernal
Qualité Délai Coût Une contrainte forte sur un axe doit réduire les contraintes sur les autres axes Mesure sur une tranche de référence ou un ensemble de tranches difficulté et risque de l’unicité de mesure « obligation » de définir des solutions de « secours » seuil de tolérance évitant les « dérapages » tant du concepteur-réalisateur que du client

24 Interviews et Réunions
Préparer Planifier Dialoguer Recueillir Vérifier Contrôler Dépouiller Comprendre Formaliser Clarifier etc.

25 Réalisation d’interview
Organisation Démarche Respect de la hiérarchie Intégration des « PIVOTS » décisionnels informatifs Ordre tel que Demandeur Direction CS (Chef service) / RS (Responsable secteur) RP (Responsable projet ou travaux) Utilisateurs / Informaticiens / Acteurs finaux 1 personne ou un petit groupe d’au maximum 3 1 date 1 heure de début et de fin (durée définie) 1 lieu au calme et isolé 1° rencontre : chez l’audité 2° rencontre : chez l’auditeur 3° rencontre : chez l’audité rencontres occasionnelles sur « le terrain »

26 Domaines de questions

27 Evaluation progressive
Niveau de responsabilité Entreprise / Service / Poste de travail / ... Stratégie et orientations Economie et organisation Social et implications Niveau d’ACTIONS Fonction occupée ou Rôle rempli Activité et responsabilités Origines et formations Fonctions contractuelles et réelles Niveau d’IMPLICATION Informatique (domaine audité spécifique) Stratégie et orientations Economie et organisation Social et implications Problèmes Besoins exprimés

28 Revue informatique Revue Assistée par l’Ordinateur
Revue à Travers l’Ordinateur Contraintes Outils

29 RAO Elle revêt 2 formes Celle de l’usage de logiciels prédéfinis (tels que des outils de cartographie réseau, des outils de Reverse Ingénierie, etc.) Celle de l’accès direct par l’auditeur pour des analyses ponctuelles soit sur le système, soit sur des logiciels : Requêtes sur base de données Contrôle des procédures informatisées Analyse de fichier Analyse de configuration Etc. Son objectif est de fournir des informations techniques et quantitatives.

30 Problématique documentaire
Les RAO posent les problèmes de la récupération des données et de leur contrôle. Toute analyse de données doit poser les questions suivantes : Quelle destination (échange) et quel usage (support, durée de vie, finalité) ? Quelle modalité de récupération (modalité d’accès, formalisme, droits d’usage, etc.) ? Quelle modalité d’exploitation (support matériel, support logiciel, accessibilité) ? Quels contrôles (intégrité, croisement, circuit, validité, sécurité, format, etc.) ?

31 Problématique technique
La RAO doit obligatoire est traitée à 2 niveaux : L’informatique est un outil : La RAO par sa rapidité va permettre de trouver plus facilement et de valider des points clefs de l’audit La RAO par son formalisme va permettre une mise en forme plus aisée des résultats contrôlés et leur analyse plus poussée (statistiques, croisement, etc.) L’informatique est un objet de l’audit : La RAO doit s’accompagner de mesures de contrôle (fiabilité, certification, etc.) d’une part de l’outil utilisé mais aussi des méthodes et logiciels  RISQUES liés aux erreurs de conception et de manipulation La RAO doit obligatoirement être traitée en mode REDONDANT (certitude de …)

32 Outils de cartographie
Analyse et surveillance d’évènements Cartographie ordinateurs, périphériques, connections, etc. Statistiques et analyses de données sur évènements quantifiés, etc.

33 Outils de Reverse Ingénierie
Analyse et modélisation de classe, de package, de composants, … Analyse de code source, Analyse de base de données, Etc.

34 Outils de performance logicielle

35 Outils journaux et observateurs syst.
Journaux (logs) d’évènements sur serveurs, sur base de données, etc. Observateurs d’évènements, analyseurs de performances systèmes, etc.