SIE 2

1. 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 Rapport du diagnostic Politique INFORMATIQUE (PI) 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 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 Scénarios retenus Bilans économiques et qualitatifs 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 SD ou PI finalisé & validé Plan des RH

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’auditanglo-saxonne COBITajoute des critèresde 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 fiduciaireadj. et n.m. se dit de valeurs (données) fondées sur la confiance à celui qui les émet

14. 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 … Problème et informatique

15. 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. 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 Les mises en balance

18. Du problème à la solution Moyens (Matériels et techniques) RH Sécurité BIG PROBLEM INFORMATIQUE THE VERY GOOD SOLUCE Organisation BudgetFinances JuridiqueLégislation THE REAL SOLUCE TempsDé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. 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 Penser en contraintes

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 • Adaptation • 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. 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 » 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 Réalisation d’interview Démarche Organisation

26. Domaines de questions

27. Entreprise / Service / Poste de travail / ... Niveau de responsabilité • 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 Evaluation progressive

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.