Guide D Audit Des Si v1-2

Guide pratique du CHAI
Guide
daudit des
systmes
dinformation
Parmi les thmes daudit abords dans ce guide :

Laudit des SI loccasion de missions gnralistes
p. 19
Laudit du pilotage des systmes dinformation
p. 37
Laudit de scurit
p. 43
Laudit de la production informatique
p. 51
Laudit des applications informatiques en service
p. 59
Laudit du support utilisateurs et de la gestion du parc
p. 67
Laudit de la fonction tude
p. 69
Laudit des projets
p. 73
Laudit des marchs spcifiques au domaine informatique p. 91
Version 1.0 juin 2014
Prcaution concernant lutilisation du prsent document
Le prsent guide a t labor par un groupe de travail interministriel, sous lgide du Comit dharmonisation de laudit interne (CHAI). Il est
le fruit de plusieurs mois de travaux collectifs, de partage d'expriences et de mise en commun des meilleures pratiques ayant cours dans les
corps de contrle ou les missions ministrielles daudit interne. Son objet est au premier chef de faciliter lharmonisation de la mthodologie
de travail des auditeurs internes et il se rapporte ce titre la partie dispositions recommandes du cadre de rfrence de laudit interne
de lEtat.
Ce document est une premire version, actuellement en cours dexprimentation par les praticiens de laudit interne en fonction dans les
diffrents ministres.
Lattention du lecteur est appele sur le fait que, mme une fois devenu dfinitif, le prsent guide ne pourra en aucun cas tre considr
comme le seul rfrentiel la lumire duquel les auditeurs auront former leur opinion globale et porter leur jugement professionnel dans le
domaine considr.
Ce document a t produit dans le cadre dun groupe de travail du Comit dharmonisation de laudit interne
(CHAI) anim par Marcel DAVID (CGA) compos de :
Anne AUBURTIN (IGAS),

Patrick BADARD (SAE),
Simon BARRY (CGEFI),
Philippe BELLOSTA (DGFIP),
Pierre BOURGEOIS (IGA),
Luc CHARRI (CHAI),
Jean-Pierre DALLE (IGA),
Nicole DARRAS (CGEDD),
Rmy MAZZOCCHI (DISIC),
Herv PEREZ (CHAI),
Philippe PERREY (IGAENR),
Jean-Franois PICQ (IGAENR),
Clment REMARS (CGA).
SOMMAIRE
Introduction ............................................................................................................................................................................................................... 5
1.
Les systmes informatiques : enjeux et risques ............................................................................................................................................. 7

1.1.
Le systme informatique .............................................................................................................................................................................................. 7
1.1.1.
1.1.1.1.
1.1.1.2.
1.2.
Les risques informatiques.......................................................................................................................................................................................... 13
1.2.1.
1.2.2.
2.
Gnralits .................................................................................................................................................................................................................................. 13
Les principaux risques informatiques ..................................................................................................................................................................................... 13
Approche de certains thmes daudit ............................................................................................................................................................ 19

2.1.
Laudit des SI loccasion de missions gnralistes ....................................................................................................................................... 19
2.1.1.
2.1.2.
2.1.3.
2.1.4.
2.1.5.
2.2.
Laudit dune organisation ....................................................................................................................................................................................................... 19

Les audits de processus ............................................................................................................................................................................................................. 21
Les audits de rgularit ............................................................................................................................................................................................................. 23
Les audits des fonctions externalises ..................................................................................................................................................................................... 25
Les audits de projets non SI ...................................................................................................................................................................................................... 27
Les missions daudit dont lobjet principal appartient au domaine des SI ..................................................................................................... 29
2.2.1.
2.2.2.
2.2.3.
2.2.4.
2.2.5.
3.
Dfinition ...................................................................................................................................................................................................................................... 7
La performance du SI de ltat ................................................................................................................................................................................................... 7
Les facteurs clefs dun SI performant ........................................................................................................................................................................................ 9
Les audits dapplication ............................................................................................................................................................................................................ 29

Les audits de projets informatiques ........................................................................................................................................................................................ 30
Les audits de scurit ................................................................................................................................................................................................................ 31
Les audits de qualit des donnes ........................................................................................................................................................................................... 32
Les audits de rgularit spcifiques ........................................................................................................................................................................................ 34
Approche thmatique et technique des principaux domaines daudit des SI .......................................................................................... 35

3.1.
Audit du pilotage des systmes dinformation...................................................................................................................................................... 37
3.2.
Audit de scurit .......................................................................................................................................................................................................... 43
3.3.
Audit de la production informatique ...................................................................................................................................................................... 51
3.4.
Audit des applications informatiques en service .................................................................................................................................................. 59
3.5.
Audit du support utilisateurs et de la gestion du parc ......................................................................................................................................... 67
3.6.
Audit de la fonction tude ......................................................................................................................................................................................... 69
3.7.
Audit des projets ......................................................................................................................................................................................................... 73
3.7.1.
3.7.2.
3.7.3.
3.7.4.
3.7.5.
3.7.6.
3.7.7.
3.7.8.
3.7.9.
3.7.10.
3.7.11.
3.7.12.
3.7.13.
3.7.14.
3.7.15.
3.8.
Audit des marchs spcifiques au domaine informatique .................................................................................................................................. 91
3.8.1.
3.8.2.
3.8.3.
3.8.4.
3.8.5.
4.
Objectifs et enjeux du projet ..................................................................................................................................................................................................... 73

tude dopportunit et expression des besoins ..................................................................................................................................................................... 74
Planification ................................................................................................................................................................................................................................ 75
Instances de pilotage ................................................................................................................................................................................................................. 76
Mthodes et outils ...................................................................................................................................................................................................................... 78
Plan assurance qualit ............................................................................................................................................................................................................... 79
Conception gnrale et analyse ................................................................................................................................................................................................ 80
Conception dtaille .................................................................................................................................................................................................................. 81
Dveloppement, ralisation ou paramtrage ......................................................................................................................................................................... 82
Qualification : test/recette ......................................................................................................................................................................................................... 83
Conduite du changement et mise en uvre........................................................................................................................................................................... 85
Documentation ........................................................................................................................................................................................................................... 87
Rles et responsabilits ............................................................................................................................................................................................................. 88
Gestion des volutions .............................................................................................................................................................................................................. 89
Mise en production .................................................................................................................................................................................................................... 90
tude des marchs dassistance technique ............................................................................................................................................................................. 92
tude des marchs dacquisition de prestations informatiques sur la base dun forfait ................................................................................................. 94
tude des marchs dacquisition de prestations informatiques sur la base dun forfait horaire .................................................................................... 95
tude des marchs dinfogrance ou de tierce maintenance applicative (TMA) .............................................................................................................. 96
tude des marchs ayant pour objet la fourniture dune application hberge ............................................................................................................... 97
Dictionnaire des expressions spcifiques et acronymes ............................................................................................................................. 99

4.1.
Dictionnaire des expressions spcifiques du domaine ........................................................................................................................................ 99

2
4.1.1.
4.1.2.
4.1.3.
4.1.4.
4.1.5.
4.1.6.
4.1.7.
4.1.8.
4.1.9.
4.1.10.
4.1.11.
4.1.12.
4.1.13.
4.1.14.
4.1.15.
4.1.16.
4.1.17.
4.2.
Gouvernance du SI .................................................................................................................................................................................................................... 99
Schma directeur et plan stratgique informatique .............................................................................................................................................................. 99
Plan doccupation des sols (POS) ............................................................................................................................................................................................. 99
Maitrise douvrage (MOA) et matrise duvre .................................................................................................................................................................. 100
Propritaire (business owner) dune application ou de donnes ......................................................................................................................................... 101
Base de donnes matresse ...................................................................................................................................................................................................... 101
Politique de scurit ................................................................................................................................................................................................................ 102
Charte dutilisation .................................................................................................................................................................................................................. 102
Environnements de dveloppement (tudes), dintgration et de production (exploitation)....................................................................................... 103
Recette........................................................................................................................................................................................................................................ 104
Convention et contrats de service (SLA / OLA) ................................................................................................................................................................... 104
Plan de continuit de lactivit et plan de reprise de lactivit .......................................................................................................................................... 104
Infogrance et outsourcing ..................................................................................................................................................................................................... 105
Informatique en nuage, ou Cloud Computing .................................................................................................................................................................... 105
Datacenter ................................................................................................................................................................................................................................. 106
Maintenance applicative ou corrective, TMA, TME ........................................................................................................................................................... 106
Progiciel de gestion intgre PGI (ERP) ............................................................................................................................................................................. 107
Dictionnaire des acronymes .................................................................................................................................................................................... 109
Fiche dvaluation du Guide daudit des systmes dinformation .............................................................................................................................. 111
INTRODUCTION
Lessentiel des travaux daudit relatifs au systme dinformation ne
ncessite pas de connaissances trs approfondies en informatique mais
une bonne matrise des pratiques daudit.
Ce guide sadresse toutefois des auditeurs a minima avertis, cest--dire
ayant suivi une session de sensibilisation ou ayant dj effectu une ou
deux missions daudit dans le domaine en compagnie dun auditeur
spcialis dans le domaine des SI. La sensibilisation pourra, notamment,
sappuyer sur des guides de formation mis disposition par le CHAI.
Il propose dans une premire partie une information gnrale sur les
facteurs cls permettant damliorer la performance de la fonction et du
systme informatique, en les articulant avec les principaux risques du
domaine.
Cependant, ce guide est orient vers laudit de structures de taille

consquente. Lauditeur devra videmment adapter son approche et ses
attentes la taille et aux moyens de lorganisation audite, en particulier
dans lutilisation de cette troisime partie.
Enfin, un dictionnaire permet de revenir sur certaines notions
frquemment rencontres lors dun audit SI. Il est tout particulirement
important de veiller la clart des termes et notions utiliss dans les
documents contractuels.
En complment de ce guide, il est noter que les auditeurs ministriels
peuvent sappuyer en matire daudit des SI sur la direction des systmes
dinformation et de communication de ltat (DISIC). La matrise des
risques qui sattachent au SI de ltat et ses grands projets
informatiques est, en effet, lune de ses missions essentielles.
Il dcrit en deuxime partie, dune part, la dimension informatique des

principaux audits gnralistes (audit en organisation, audits de processus,
etc.) et, dautre part, les aspects plus gnraux des audits visant
spcifiquement le domaine SI (audits dapplication, de la scurit
informatique, des projets, etc.).
Il prsente en troisime partie les points aborder en fonction de laspect
audit. Ainsi, pour chaque thme, lauditeur sera renvoy un tableau
identifiant les principaux points de contrle correspondant. Ce tableau
doit permettre un auditeur non spcialiste des SI de percevoir le
contenu dun thme daudit donn, et un auditeur spcialis de ne rien
oublier.
1. LES SYSTEMES INFORMATIQUES :

ENJEUX ET RISQUES
Un systme informatique est constitu de ressources matrielles et

logicielles organises pour collecter, stocker, traiter et communiquer les
informations. Les ressources humaines ncessaires son fonctionnement
(par exemple les administrateurs) sont parfois incluses dans ce primtre.
Le systme informatique, appel aussi systme dinformation, (not SI)

reprsente l'ensemble des logiciels et matriels participant au stockage,
la gestion, au traitement, au transport et la diffusion de l'information au
sein de l'organisation.
Le systme informatique ne doit pas tre conu comme une fin en soi : il
est lun des outils qui permet lorganisation datteindre ses objectifs. Il
ne se justifie quen tant quil soutient des processus mtier , sans
lesquels il na aucun sens. Il doit donc tre align avec les objectifs
stratgiques de lorganisation. Cet alignement stratgique est
fondamental : dsormais, un systme informatique est un facteur
dterminant de la performance (efficacit, efficience, matrise des
risques) dune organisation. Inversement, un systme informatique
inadapt ou mal matris peut tre une source inpuisable de difficults.
La fonction informatique vise fournir ces ressources lorganisation. Elle

comprend donc, outre le systme informatique, les personnes, processus,
ressources financires et informationnelles qui y contribuent.
Les dveloppements suivants exposent, de manire synthtique, les

principaux facteurs cls de la performance du SI et les risques spcifiques
qui psent sur son fonctionnement.
1.1.
LE SYSTEME INFORMATIQUE
1.1.1.
DEFINITION
Elle ne doit pas tre confondue avec la fonction dinformation, ensemble

organis de personnes, de procdures et dquipement qui a pour objet
de runir, de trier, danalyser, dvaluer et de distribuer, en temps utile,
de linformation pertinente et valide, provenant de sources internes et
externes lorganisation, afin que tous ceux qui ont prendre des
dcisions disposent des lments leur permettant de choisir laction la
plus approprie au moment adquat.
La fonction dinformation, qui doit tre pense comme telle et non
comme une manation de la fonction informatique, sappuie videmment
sur des ressources informatiques. En raison de la confusion frquente
entre ces notions, les commanditaires attendent parfois des auditeurs SI
un travail sur la fonction dinformation plus que sur le seul systme
informatique. Il convient donc dtre trs clair sur les attendus de laudit.
1.1.1.1. L A PERFORMANCE DU SI DE LTAT

Le dveloppement de services pertinents pour le citoyen et lentreprise, la
modernisation des outils mis disposition des agents, louverture des
donnes publiques au profit dune meilleure transparence et de
linnovation doivent sappuyer sur des systmes dinformation
performants. Cest pourquoi le Premier Ministre a valid et diffus par
circulaire, le 7 mars 2013, le cadre stratgique commun du systme
dinformation de ltat labor par la direction interministrielle des
systmes dinformation et de communication (DISIC).
Ce cadre stratgique commun du SI de ltat fixe une ambition commune

porte par les systmes dinformation ministriels et interministriels.
Cette ambition se dcline en trois axes stratgiques :
1. Le SI doit crer une valeur croissante pour ses utilisateurs. cet
effet, les directions mtiers doivent mieux sappuyer sur les
systmes dinformation pour optimiser les processus de
fonctionnement de ladministration, augmenter la performance
de celle-ci et la qualit du service rendu par les agents publics. Le
systme dinformation doit tre mieux structur et utilis pour
dvelopper les relations numriques entre les mtiers et les
usagers.
2. Le SI de ltat doit tre construit de faon efficiente.
Paralllement aux investissements dinnovation qui crent de la
valeur pour les utilisateurs du SI de ltat, les cots non justifis
des composantes de ce SI doivent tre rduits.
3. La fonction SI de ltat doit tre pilote. Les visions ministrielles
des SI, et particulirement leur alignement avec la stratgie des
mtiers, doivent sappuyer sur une vision transversale du systme
dinformation de ltat afin de concilier enjeux mtiers et enjeux
globaux des politiques publiques. En particulier, certains enjeux
dorganisation et de politique publique de long terme constituent
des chantiers essentiels pour la russite de lvolution du systme
dinformation de ltat, au-del de visions trop locales ou
ministrielles.
Lurbanisation du SI de ltat est loutil pour le pilotage du patrimoine SI
et une aide la dcision pour toutes les actions de transformation. Le
cadre commun durbanisation (CCU) du SI de ltat constitue un des
lments du corpus rglementaire applicable pour la construction, la
gestion, lexploitation et la transformation du SI de ltat, tous les
niveaux. Ce corpus se compose de documents de politique globale

applicables lensemble du SI de ltat :
le cadre stratgique, qui dfinit la stratgie de ltat en matire
de SI,
la politique de scurit, dfinissant les rgles gnrales de

scurit,
le cadre commun durbanisation dfinissant la dmarche

durbanisation,
le cadre commun dinteroprabilit.
Ce corpus comprend galement des documents rglementaires

techniques porte plus large (administrations de ltat, collectivits
territoriales, organismes de la sphre scurit et protection sociale),
dfinis par lordonnance n2005-1516 du 8 dcembre 2005 :
le rfrentiel gnral dinteroprabilit,
le rfrentiel gnral de scurit,
le rfrentiel gnral daccessibilit pour ladministration.
Il comprend galement des documents porte ministrielle :

un cadre stratgique ministriel (ou schma directeur), dclinant
le cadre stratgique du SI de ltat, dans le contexte mtier dun
ministre ;
un cadre de cohrence technique : normes, standards et rgles

darchitecture applicables localement ;
une mthode de conduite de projet qui dfinit et structure les

relations matrise douvrage (MOA) et matrise duvre (MOE) et
le pilotage des projets de transformation du SI pour un ministre
(ou une administration) ;
Il comprend ventuellement une charte durbanisation qui dcline

localement le cadre commun durbanisation, sans pour autant modifier
les principes, ou le cadre dactivit, mais uniquement en prcisant
lorganisation, les mthodes de travail et le fonctionnement local.
1.1.1.2. LES FACTEURS CLEFS D UN SI PERFORMANT

Un SI idal :
est en adquation avec la stratgie de lorganisation et les
objectifs des mtiers ;
quand il fait lobjet de marchs, est conforme aux bonnes

pratiques de la commande publique.
Les principaux facteurs clefs dun SI performant sont les suivants :
une forte implication de la direction dans la gestion du SI. Elle doit

notamment superviser la gestion du SI par la mise en place des
outils de pilotage suivants :
un schma directeur informatique (SDI), qui dfinit la
stratgie informatique pluriannuelle, dont la validation
par la direction entrine ladquation entre la stratgie
informatique et la stratgie de lentit ;
des documents dorganisation de la gouvernance du SI,

mis jour rgulirement ;
des comits de pilotage informatiques rguliers (suivi des

incidents, suivi des projets, suivi des budgets, etc.), au
sein desquels la direction doit tre reprsente bon
niveau ;
est en conformit avec les obligations lgales ;
est scuris ;
est facile utiliser ;
est fiable ;
des tableaux de bord de suivi de linformatique ;
est adaptatif ;
un portefeuille des projets SI et des analyses de la valeur

des systmes dinformation ;
est prenne ;
est disponible ;
une politique de scurit (voir ci-aprs), approuve au

plus haut niveau de la direction ;
est efficient ;
des comits de scurit rguliers, au sein desquels la

direction doit tre reprsente bon niveau ;
respecte le plan durbanisme ;
une cartographie des applications et systmes

informatiques jour, incluse dans une politique
9
durbanisme informatique. Cette cartographie est

fondamentale pour les auditeurs, les certificateurs ou
tout autre organisme de contrle.
une meilleure efficacit, cette charte devrait tre signe

par tous les agents et une communication rgulire sur le
sujet devrait tre mise en place avec le support de la
direction. Cette charte contiendrait par exemple les rgles
de scurit et de bon usage (protection du PC, mots de
passe, confidentialit, utilisation dInternet, de la
messagerie, protection du PC, etc.), les normes relatives
aux logiciels (installation, licences, etc.), une description
de la traabilit des actions sur le SI laquelle chaque
utilisateur est assujetti et les sanctions applicables en cas
de non-respect des rgles dcrites.
une politique de scurit, qui doit tre valide et soutenue par la

direction de lentit :
la politique de scurit des systmes dinformation (PSSI)
constitue le principal document de rfrence en matire
de scurit des systmes dinformation (SSI). Elle reflte
la vision stratgique de lentit et montre limportance
quaccorde la direction la scurit de son SI ;
elle se matrialise par un document prsentant, de

manire ordonne, les rgles de scurit appliquer et
respecter dans lorganisme. Ces rgles sont gnralement
issues dune tude des risques SSI ;
aprs validation, la PSSI doit tre diffuse lensemble
des acteurs du SI (utilisateurs, sous-traitants,
prestataires). Elle constitue alors un vritable outil de
communication sur lorganisation et les responsabilits
SSI, les risques SSI et les moyens disponibles pour sen
prmunir ;
la PSSI est un document vivant qui doit voluer afin de
prendre en compte les transformations du contexte de
lorganisme (changement dorganisation, de missions...)
et des risques (rvaluation de la menace, variation des
besoins de scurit, des contraintes et des enjeux) ;
idalement, il devrait exister une charte dutilisation du
systme dinformation, dans le but de sensibiliser les
utilisateurs la scurit informatique, informer les
utilisateurs des responsabilits qui leur incombent. Pour
le respect de la lgislation en matire de systme dinformation :

la lgislation ne peut tre apprcie en termes
uniquement de contrainte. La mise en conformit du SI
permet de garantir de faon raisonnable un
environnement de contrle satisfaisant de son SI ;
les principaux textes applicables sont la loi de scurit

financire (LSF), avec un volet informatique puisque
lobjectif est de renforcer la fiabilit des informations
financires des entreprises mais aussi le contrle interne
sur les aspects oprationnels (de mme que la loi
Sarbanes-Oxley aux tats-Unis mais uniquement sur les
aspects financiers) ;
en France, la loi de finances sur le contrle des

comptabilits informatises (vote en 1991 puis
complte en 1996 et 2006) contribue la justification
informatique de la piste daudit ;
10
la dclaration CNIL a, en revanche, un objectif diffrent

puisquelle sert protger les donnes personnelles des
individus, manipules dans les applications informatiques.
le respect des bonnes pratiques en matire de commande

publique :
lachat de prestations ou de logiciels est un acte
complexe, qui suppose une excellente coopration entre
les oprationnels et les services acheteurs. La possibilit
de recourir au sur-mesure , plus frquente que pour
dautres types dachats, impose en contrepartie une
rigueur particulire sagissant des spcifications, des
procdures de passation et de rception et du pilotage
des assistances la MOA ou la MOE ;
cette complexit rend dautant plus important le respect

du code des marchs publics et des guides de bonnes
pratiques rdigs par le SAE, et ce, quelle que soit la
mthode de dveloppement utilise. Contrairement ce
que lon entend parfois, les dispositions encadrant la
commande publique sont, en effet, adaptes au domaine
informatique, y compris la mthode agile, et leur
application rigoureuse et sincre peut viter nombre de
dconvenues.
un paramtrage correct des droits daccs aux applications

informatiques :
les droits daccs au SI doivent reflter les rgles de
sparation des tches telles que dfinies dans
lorganisation ;
au niveau informatique, les dveloppeurs ne peuvent pas

avoir accs lenvironnement de production et le
personnel dexploitation ne peut pas avoir accs
lenvironnement de dveloppement. Par ailleurs,
lattribution de droits trs levs ( administrateurs )
doit tre limite et toute action de ces profils
sensibles doit tre trace et revue rgulirement ;
au niveau des applications informatiques, les droits

daccs attribus doivent traduire de faon informatique
les rles de chacun dans lorganisation. Chaque agent na
accs quaux applications qui le concernent dans sa
fonction, et lintrieur des applications, il existe des
restrictions au niveau de chaque fonctionnalit, voire au
niveau des donnes ;
les droits daccs doivent faire lobjet dune gestion

rigoureuse, par un service ddi. Ainsi, les demandes
doctroi de droit daccs doivent tre formalises et
obligatoirement valides par les chefs de service. Les
dblocages en cas de perte de mot de passe doivent tre
organiss. Enfin, la liste des habilitations, application par
application, doit tre revue rgulirement, et les droits
daccs supprims en cas de dpart.
une bonne gestion des projets de dveloppements informatiques.

La russite dun projet informatique ncessite a minima les
lments suivants :
une vision claire de lobjectif et des rsultats attendus ;
limplication de la direction gnrale ;
11
une dfinition claire des responsabilits des parties

prenantes ;
limplication des utilisateurs ( bureaux mtiers ) ;
la constitution dune quipe projet ddie dirige par des

cadres expriments ;
des choix techniques prennes ;
une gestion rigoureuse et organise du projet ;
un dploiement chelonn ;
un suivi des risques ;
un accompagnement du changement.
une dmarche qualit informatique : la mise en place dune

dmarche qualit pour la gestion de la production et le
dveloppement
informatique
permet
damliorer
les
performances du systme dinformation, de normaliser les
procdures de gestion en fonction des rfrentiels existants et
damliorer les comptences des acteurs du systme
dinformation. Il existe en la matire de nombreux rfrentiels,
dont les principaux sont les suivants :
CMMI (Capability Maturity Model + Integration) pour les
dveloppements informatiques (avec plusieurs niveaux
de certification de 1 5) ;
ITIL (Information Technology Infrastructure Library) : plus

spcifique la gestion de la production informatique ;
COBIT (Control Objectives for Information and related

Technology) : est un rfrentiel en matire de
gouvernance informatique ;
ISO 27001 (auparavant la BS7799) : prsente les

exigences en matire de scurit informatique ;
le guide des bonnes pratiques des achats de services

informatiques du service des achats de ltat (SAE) ;
les guides et recommandations sectorielles publis par

lANSSI et la DISIC ;
par ailleurs, la piste daudit peut tre entirement

informatise.
le cadre stratgique commun du SI de ltat et le cadre

commun durbanisation ;
NB : Voir dans les risques informatiques, les progiciels de

gestion intgrs
mthode MAREVA 2 danalyse de la valeur des projets SI

(Forum de la performance).
un SI intgr :
un SI est dit intgr quand toutes les applications
communiquent entre elles de faon automatique laide
dinterfaces. Ainsi, les informations ne sont saisies quune
seule fois dans les systmes (notion de base de donnes
matresse) et les changes de donnes font lobjet de
contrles dintgrit automatiques. Laction humaine,
source potentielle derreurs ou de fraude, est donc trs
limite.
12
1.2.
LES RISQUES INFORMATIQUES
1.2.1.
GENERALITES
Les dveloppements ci-dessous dcrivent, pour chaque risque

informatique, les principaux facteurs de risque et les contrles ou
procdures qui doivent tre mis en place pour prvenir, rduire voire
supprimer ce risque.
Pour mmoire, lexternalisation dun service SI conduit transfrer les
risques, sans pour autant les couvrir de manire certaine. En matire
informatique, comme dans tous les autres domaines, lexternalisation
dun risque ne dispense ainsi pas une organisation de sassurer quil est
effectivement matris par son cocontractant et ne lexonre en rien de sa
responsabilit finale.
1.2.2.
INFORMATIQUES
Les principaux risques, facteurs de risques et dispositifs ou moyens de
contrles des risques informatiques sont les suivants :
Inadquation du SI avec la stratgie de lentit et les besoins des

utilisateurs
Facteurs de risque :
manque dimplication de la direction dans la
gestion de linformatique ;
Les principaux risques informatiques peuvent tre regroups en 3

domaines :
les risques oprationnels, qui sont les plus nombreux pour le sujet
trait ;
les risques financiers, puisque linformatique et linformation sont

des actifs ;
les risques lgaux de non-conformit, puisque les entits sont

soumises des normes internes et externes, certaines de porte
lgale, concernant la gestion du SI.
LES PRINCIPAUX RISQUES
absence de schma directeur ;
absence de gouvernance informatique ;
manque dimplication des utilisateurs ( bureaux

mtiers ) dans les projets informatiques ;
absence danalyse de la valeur des SI mis en

place.
Contrles ou procdures attendus :

supervision de linformatique par la direction de
lentit ;
existence dune stratgie en adquation avec la

stratgie de lorganisation, traduite par exemple
dans un schma directeur informatique ;
gouvernance informatique en place et valide par

la direction ;
13
analyse de la valeur (par exemple par MAREVA

2) ;
forte implication des utilisateurs ( bureaux
mtiers ) dans les projets informatiques.
Scurit du SI inadapte au niveau de risque identifi et accept

par la direction
Les facteurs de risque sont multiples car la scurit est
transversale tous les processus de linformatique :
scurit physique ;
Incapacit de lorganisation redmarrer les systmes

informatiques en cas arrt ou destruction
absence de sauvegarde rgulire du SI
(sauvegardes externes) ;
scurit logique ;
scurit du rseau ;
scurit de lexploitation ;
absence de plan de secours ;
scurit des PC ;
absence de site de secours.
scurit des donnes ;
etc.

mise en place dun plan de secours (document,
mis jour lors de modifications majeures de
lenvironnement informatique, et test au moins
une fois par an) ;

politique de scurit en place, valide et
supporte par la direction de lentit ;
procdure de sauvegarde quotidienne

donnes et programmes critiques ;
des
outils de surveillance du systme informatique

(par exemple supervision) ;
stockage des sauvegardes lextrieur de

lentit ;
quipe scurit ddie recensant tous les

incidents relatifs la scurit et capable
dintervenir en cas dvnement de scurit.
les
sauvegardes
rgulirement ;
lorsquune activit est fortement dpendante de

linformatique, mise en place dun site de secours.
doivent
tre
testes
14
Accs aux donnes et aux applications par des personnes non

autorises
absence de politique de scurit ;
absence de gestion rigoureuse dattribution des

droits daccs ;
absence de gestion rigoureuse des points

daccs ;
systmes informatiques ne permettant pas une

gestion fine des droits daccs ;
gestion des mots de passe insuffisante.

politique de scurit valide par la direction de
lentit ;
supervision des profils sensibles allous au

personnel informatique ;
traabilit des accs et actions sensibles.
Applications informatiques non fiables

erreurs dans la programmation des applications
par rapport aux spcifications fonctionnelles ;
applications insuffisamment testes ;
utilisateurs insuffisamment impliqus dans les

phases de dveloppements de lapplication.

forte implication des utilisateurs dans les
dveloppements informatiques ;
politique de gestion des mots de passe efficace ;
bonne gestion de projet ;
gestion rigoureuse des droits daccs au systme

dinformation en cohrence avec la sparation
fonctionnelle des tches ;
veille environnementale ;
procdures de recensement des anomalies ;
revue rgulire de la liste des habilitations,

application par application ;
procdures de maintenances
adaptatives et volutives.
revue rgulire des points daccs ;
sparation des tches effective entre

fonctions dveloppements et exploitation ;
correctives,
les
15
Indisponibilit du systme informatique

mauvaise gestion de lenvironnement matriel du
SI (nergie, climatisation, protection physique,
etc.) ;
plans de continuit et de reprise de lactivit.
Mauvaise utilisation du SI par les utilisateurs

applications informatiques non conviviales ;
absence de convention de service ;
utilisateurs insuffisamment forms ;
absence doutil de surveillance de la disponibilit

du SI ;
documentation utilisateur insuffisante et pas mise

jour ;
absence
de
cellule
dindisponibilit ;
manque de contrles bloquants

applications informatiques.
ractive
en
cas
absence de contrat de maintenance des matriels

informatiques.

convention de service entre linformatique et les
utilisateurs, portant notamment sur des objectifs
de performance du SI, tels le niveau de
disponibilit des serveurs ;
support utilisateur performant ;
procdure de gestion des anomalies ;
procdure de maintenance
applications informatiques ;
corrective
contrats de maintenance
informatiques ;
des
environnement matriel adapt ;
des
dans
les

applications faciles dutilisation ;
formation initiale des utilisateurs ralise en

temps utile et complte par une formation au fil
de leau ;
documentation utilisateur complte et mise

jour rgulirement ;
contrles bloquants dans les applications ;
procdures de gestion des maintenances

volutives, adaptatives et correctives.
matriels
16
SI non conforme avec la lgislation

Les lois et dcrets portant sur le renforcement des
procdures de contrles internes concernent pour partie
linformatique. Les actions mettre en place font, pour la
plupart, partie des recommandations dj cites pour
couvrir certains risques informatiques comme :
la politique de scurit informatique ;
la documentation informatique jour ;
la scurit des dveloppements informatiques ;
la gestion rigoureuse des droits daccs au SI.
Sagissant des dclarations CNIL, il est recommand

quune personne soit spcifiquement dsigne dans
lorganisation pour grer ce sujet et lanticiper. Elle doit
notamment sensibiliser sur le sujet les services en charge
des dveloppements informatiques.
SI non prenne
utilisation de la sous-traitance informatique sans
transfert de comptence en interne ;
documentation informatique inexistante ou non

mise jour suite aux volutions du SI ;

le SI doit faire lobjet dun schma directeur
informatique ;
la documentation informatique doit tre

complte et jour, notamment dans un contexte
de forte utilisation de la sous-traitance ou
dapplications anciennes ;
des procdures de transfert de comptence entre

les sous-traitants et les quipes informatiques
internes doivent tre mises en place.
Les progiciels de gestion intgrs (PGI) constituent un cas particulier,

porteurs davantages, dinconvnients et de risques spcifiques.
Les PGI (Entreprise Ressource Planning (ERP) en anglais) prsentent
lavantage de couvrir plusieurs domaines mtiers dune entreprise en une
seule application par lintermdiaire de modules. Par exemple, le PGI le
plus connu ( SAP , sur lequel repose CHORUS) intgre sous forme de
modules les principales fonctions suivantes :
module FI (Financial) : comptabilit gnrale ;
module CO (Controlling) : contrle de gestion (comptabilit

auxiliaire) ;
module SD (Sales & Distribution) : administration des ventes ;
obsolescence de lapplication et/ou de la

technologie utilise ;
module MM (Material Management) : achat et gestion des

stocks ;
forte dpendance vis--vis de personnes cls qui

peuvent quitter lentit.
module PP (Production Planning) : gestion de la production ;
module RE (Real Estate) : gestion immobilire.

17
Les principaux avantages des PGI sont les suivants :

rduction des dlais administratifs ;
saisie unique dans le SI de lorganisation ;
disponibilit immdiate de linformation ;
piste daudit garantie en principe ;
Les risques lis aux PGI sont les suivants :

drapage des projets (dans le temps et dans les cots) compte
tenu de la complexit et des enjeux ;
les dveloppements de programmes spcifiques loignent

loutil du standard ce qui entrane des problmes de matrise du
PGI voire des problmes en termes dauditabilit (altration
possible de la piste daudit) ;
la rduction des cots informatiques est parfois mise en avant,

malgr un investissement initial lev.
une inadaptation in fine du PGI lorganisation dans le cas o la

refonte des processus na pas t pralablement conduite et
porte par la direction gnrale ;
En contrepartie, certaines exigences sont gnralement imposes par la

mise en place dun PGI :
mise en uvre rigoureuse et exigeante en matire dintgration,
de paramtrage et de dveloppements spcifiques
potentiellement coteux, y compris dans la dure ;
utilisateurs insuffisamment forms qui rejettent lapplication ;
forte dpendance vis--vis du sous-traitant et insuffisance de

transfert de comptence en interne sur le PGI ;
paramtrage des droits daccs et des profils utilisateurs souvent

galvaud lors de la phase de dveloppement.
revue de larchitecture technique pouvant conduire

remplacement des infrastructures matrielles et rseaux ;
une adquation des processus et de lorganisation au PGI pouvant

offrir une opportunit de transformation si cette dernire est
anticipe et pilote ou a contrario constituer un frein au projet si
elle nest pas souhaite et assume ;
partage de linformation pouvant entraner un rejet de la part de

certains acteurs ;
matrise globale de la solution dans le temps car des incidents

peuvent bloquer toute lentit.
au
Conformment aux pratiques de laudit, ces risques sont habituellement

analyss travers une matrice des risques spcifique.
18
2. APPROCHE DE CERTAINS
THEMES DAUDIT
Laudit des SI peut soit constituer un sous-domaine dun audit gnraliste
(organisation, processus, rgularit, etc.), soit tre lobjet principal de la
mission (application, projet, scurit, respect de la lgislation, etc.).
2.1.
LAUDIT DES SI A LOCCASION DE

MISSIONS GENERALISTES
La prsente partie a pour objectif de montrer en quoi des audits ayant a

priori peu voir avec linformatique doivent aborder a minima le domaine
SI.
Elle fournit une approche des implications SI de quelques missions-types
et dresse la liste des principaux enjeux et risques associs, acteurs
rencontrer, documents rcuprer et principales questions aborder.
Pour une approche plus spcifique, lauditeur pourra se rfrer la
troisime partie du prsent guide.
2.1.1.
Pourtant, les organisations nen ont pas toujours conscience. Celles qui
peroivent limportance de linformatique ne matrisent pas toujours les
arcanes de son pilotage, de sa conduite et de sa scurit. Enfin, quelles
disposent dune fonction informatique en leur sein ou sadressent des
prestataires internes ou extrieurs ladministration, elles sont parfois
peu ou mal organises pour tirer le meilleur de ces ressources.
Laudit dune organisation doit donc dsormais ncessairement inclure un
audit de sa relation au fait informatique. Comment dfinit-elle ses besoins
fonctionnels, comment alloue-t-elle ses ressources humaines et
financires en vue de les satisfaire, sest-elle organise et a-t-elle mis en
place les processus lui permettant de disposer dune informatique en
phase avec ses besoins (alignement fonctionnel), ractive, sre et
efficiente ?
Lauditeur devra donc, loccasion de laudit dune organisation :
tudier travers les documents dorganisation et financiers
les ressources organisationnelles (structures), humaines et
financires quelle consacre linformatique ;
tudier le fonctionnement de la comitologie associe au

pilotage des SI ;
se demander si ces ressources sont convenablement

dimensionnes en regard de ce que dautres organisations
quivalentes consacrent linformatique ;
tudier les processus stratgiques de lorganisation,

inventorier les SI qui les outillent, et vrifier que lentit sest
convenablement organise pour garantir leur pilotage au
juste niveau ;
LAUDIT DUNE ORGANISATION
Les organisations utilisent quotidiennement linformatique. Celle-ci peut

prendre la forme de simple bureautique, dapplications ddies, les
mettant, le cas chant, en relation avec leurs cocontractants ou usagers
via lInternet, voire de systmes informatiques plus complexes. Ces outils
informatiques sont, dsormais, indispensables au bon fonctionnement de
lorganisation. Ils sont parfois au cur de sa performance.
19
vrifier que lorganisation a mis en place le corpus minimal,

ou dcline convenablement celui fix par le niveau suprieur
(politique du SI, politique de scurit du SI, charte
dutilisation).
Si lentit possde une fonction informatique ddie (tudes, production,

etc.), lauditeur gnraliste devra si possible solliciter les spcialistes de
laudit des SI et pourra se rfrer la troisime partie du prsent guide.
Lauditeur devra rencontrer :
la direction gnrale pour mesurer son degr de sensibilisation au
fait informatique et lorganisation quelle a mise en place pour
piloter ses SI ;
une ou plusieurs directions fonctionnelles, le cas chant les

responsables de zones fonctionnelles, pour valuer lorganisation
quelles ont mise en place en vue de dfinir leurs besoins, de les
exprimer et de contribuer efficacement aux processus visant les
satisfaire ;
le cas chant, la direction charge des SI, pour valuer la
pertinence et les consquences de son positionnement dans
lorganisation et dans les processus de gouvernance ;
telles les comptences dacheteur ou de juriste spcialiss dans le

domaine SI) et des actions de formation dans le domaine.
Il devra se procurer :
les politiques SI et de scurit SI de lorganisation ;
le plan doccupation des sols (POS) du SI et la liste des

responsables de zones fonctionnelles ;
la charte de lutilisateur des SI laquelle sont soumis les membres

de lorganisation ;
la liste des processus de lorganisation incluant les SI qui les

supportent ;
les comptes-rendus des comits ou groupes de travail (GT)

consacrs pour tout ou partie aux SI ;
la liste et le poids financier des principaux marchs SI en cours ;
la politique RH et de formation.
le cas chant, la direction charge des achats, pour mesurer la

part des SI dans son activit et vrifier la bonne prise en compte
de leur spcificit ;
Au final, lauditeur devra porter une apprciation sur la capacit de

lorganisation piloter son informatique, apprcier ses enjeux
(notamment la valeur de son patrimoine numrique) et valuer les
risques qui psent sur eux. Il peut aussi, si ses diligences lui fournissent
une matire suffisante, valuer lalignement du SI sur les objectifs
stratgiques de lorganisation.
le cas chant, la direction charge des ressources humaines,

pour mesurer le poids des comptences SI (y compris indirectes,
Il lui appartient de formuler les recommandations utiles en la matire.

20
2.1.2.
LES AUDITS DE PROCESSUS
Les processus sont dsormais pour la plupart trs fortement dpendants

des outils informatiques. Dans le meilleur des cas, ils sappuient sur un
systme informatique rpondant leurs besoins. Souvent, ils sappuient
au fil de leur droulement sur des outils disparates, conus dans une
logique dorganisation et leur imposant des ruptures de charges. Ainsi, la
performance dun processus est intimement lie lalignement et la
qualit des systmes informatiques.
Dans une organisation pratiquant le pilotage par les processus (niveau de
maturit encore peu rpandu dans ladministration), les projets
informatiques devraient tre penss nativement dans une logique de
processus.
Laudit dun processus doit donc inclure un audit des outils informatiques
sur lesquels il sappuie. Cet audit doit inclure lexamen des donnes et
informations manipules au cours du droulement du processus, y
compris celles provenant dautres processus, des applications qui servent
ou automatisent tout ou partie des tches ou procdures qui le
composent, et des infrastructures informatiques de traitement et
communication quil utilise.
Lauditeur devra donc, loccasion de laudit dun processus :
tudier travers les documents dcrivant le processus et rendant
compte de son fonctionnement, les donnes et informations
manipules, et les applications et les infrastructures utilises.
dfaut, il devra lui-mme dcrire le processus avant didentifier
ces lments ;
vrifier que les instances de gouvernance qui pilotent ce

processus sont galement comptentes pour orienter les SI y
concourant ;
vrifier lalignement stratgique des outils informatiques et des

processus quils servent. Cette approche devra tre tendue aux
projets applicatifs ;
vrifier que la scurit physique et logique de ces donnes,

informations, applications et infrastructures est en cohrence
avec lanalyse des risques de ce processus. Il devra au pralable
vrifier la pertinence de cette analyse des risques, voire procder
sa propre analyse des risques ;
tudier le dispositif de contrle interne destin matriser ce

processus, vrifier sil existe quil est pertinent, et sassurer que
les outils informatiques y contribuent de manire efficace et
efficiente ;
vrifier que les infrastructures (particulirement rseaux et

serveurs) et les dispositifs dassistance aux usagers de ces
systmes sont suffisants pour rpondre aux besoins du processus.

la direction gnrale pour valuer dans quelle mesure
lorganisation pilote ses processus, voire pratique le pilotage par
les processus, mesurer son degr de sensibilisation au fait
informatique et vrifier que lorganisation quelle a mise en place
pour piloter ses SI est en cohrence avec celle mise en place pour
piloter les processus ;
la ou les directions concernes par le processus audit, pour

valuer le degr de maturit de leur approche du processus, et
tudier lorganisation quelles ont mise en place en vue de dfinir
et exprimer des besoins en matire informatique qui soient bien
aligns avec leurs processus ;
21
sils existent, le pilote du processus audit et la direction charge

du pilotage des processus ou du pilotage par les processus, pour
valuer leur degr de sensibilisation au fait informatique et la
qualit de leurs relations avec la direction charge des SI ;
la direction charge des SI, pour valuer la pertinence et les
consquences de son positionnement dans lorganisation et dans
les processus de gouvernance vis--vis du processus audit.
la liste des projets applicatifs en cours, principalement ceux qui

ont un impact sur le processus sils sont identifis selon cette cl.
Au final, lauditeur devra porter une apprciation sur ladaptation

(efficacit, efficience, scurit, rsilience) de linformatique aux besoins
du processus audit et sur sa contribution au dispositif de contrle
interne. Il pourra le cas chant se prononcer sur la pertinence des
projets informatiques en cours, voire recommander des volutions du
systme informatique.
la cartographie des processus de lorganisation ;
la description du processus audit, incluant linventaire des

donnes et informations manipules et des applications et
infrastructures utilises ;
les tableaux de bord rendant compte de son droulement et de sa

performance ;
la cartographie des donnes, informations et applications

informatiques de lorganisation ;
les politiques SI et de scurit SI de lorganisation, et, le cas

chant, leur dclinaison lgard du processus audit ;
la (ou les) charte(s) de lutilisateur des SI laquelle sont soumis

les acteurs du processus ;
le cas chant, les comptes-rendus des comits ou groupes de

travail consacrs pour tout ou partie au processus audit,
notamment lorsquils abordent le patrimoine informationnel quil
manipule et les outils informatiques qui le servent ;
22
2.1.3.
LES AUDITS DE REGULARITE
Les organisations sappuient de plus en plus sur des outils informatiques.

Cest travers eux quelles grent leur ressource humaine, quelles
excutent leur budget et tiennent leur comptabilit, quelles conservent
les donnes relatives leurs interlocuteurs et leurs administrs.
Leur fonctionnement rgulier est donc largement sous-tendu par la
conformit aux rgles de leurs systmes informatiques, quil sagisse
dinventaire des licences, de validit des rgles informatiques dexcution
budgtaire et de comptabilit, de respect des normes de conservation des
donnes personnelles, de la mise en uvre automatise des rgles
statutaires applicables la gestion de carrire ou au traitement des
agents, etc.
Laudit de la rgularit dune situation, quil sagisse de vrifier le
fonctionnement dune entit, le droulement dun processus ou, plus
gnralement, le respect dune norme ou dun corpus normatif, implique
donc le plus souvent laudit des ressources informatiques qui y
contribuent. Lauditeur cherchera vrifier que les activits portes par
les ressources informatiques sont en elles-mmes rgulires et mesurer
leur contribution au contrle interne de lentit ou du processus, par leur
architecture ou les rgles quelles portent.
Lauditeur devra donc, loccasion dun audit de rgularit :
identifier les ressources informatiques utilises dans le primtre
de son audit ;
vrifier que ces ressources sont en elles-mmes rgulires

(licences, respect des rgles de conservation des donnes
personnelles, respect des rgles de confidentialit, etc.) ;
vrifier que les traitements automatiques raliss par ces

ressources sont conformes au corpus normatif applicable, et
valuer leur fiabilit ;
vrifier que la scurit applique ces ressources, outre le

respect des rgles de confidentialit, garantit raisonnablement
quelles ne peuvent tre utilises des fins frauduleuses.
Lauditeur devra selon les cas rencontrer :

la direction gnrale du primtre auquel appartient le champ
audit, pour valuer dans quelle mesure elle est consciente de la
dimension informatique de lobligation de fonctionnement
rgulier qui pse sur elle, et savoir comment cette dimension est
prise en compte ;
les acteurs oprationnels de lentit ou du processus audit, pour

identifier les ressources informatiques (y compris de bureautique)
utilises ;
la direction charge des ressources informatiques utilises dans le

primtre audit, pour vrifier quelle connat, respecte, et fait
respecter les divers corpus normatifs applicables ;
la direction charge de la supervision du contrle interne, pour

vrifier quelle a bien pris en compte les ressources informatiques
dans le dispositif de contrle interne du primtre audit, voire
sappuie sur elles pour la ralisation de ses propres objectifs.
linventaire des ressources informatiques utilises dans le
primtre audit (notamment la cartographie des applications et
des systmes) ;
23
les contrats et inventaires de licences ;
les dclarations CNIL ;
la description du dispositif de contrle interne incluant la part

prise par lapplication des rgles informatiques ;
les rapports de vrifications issus du dispositif de contrle interne

et les bases de donnes rpertoriant les incidents dexploitation,
pour valuer la fiabilit des traitements informatiques ;
si ncessaire, les spcifications dtailles des applications

concourant la mise en uvre dun corpus normatif par un
traitement automatis.
Au final, lauditeur devra porter une apprciation la fois sur la valeur de

la contribution de linformatique la rgularit des oprations audites et
sur la rgularit des activits informatiques elles-mmes.
24
2.1.4.
LES AUDITS DES FONCTIONS
vrifier que le march dexternalisation traite convenablement

des aspects informatiques, notamment en ce quil prvoit bien
quelles sont les obligations des deux parties en matire de
manipulation et de conservation des ressources informationnelles
et matrielles, et quil organise de manire crdible la
rversibilit ;
vrifier quil existe une instance de gouvernance de la relation

entre lorganisation et son prestataire qui permette en cas de
besoin ladaptation de la relation contractuelle lvolution de
lenvironnement informatique.
EXTERNALISEES
Rares sont les fonctions externalises qui nont pas besoin dchanger
rgulirement des donnes avec lorganisation, ce qui suppose une
interconnexion entre systmes informatiques. Souvent, le bon
droulement de ces changes de donnes, en temps rel ou non,
constituent une partie des obligations des deux cocontractants. Ils sont
aussi le motif dune ouverture du systme informatique de lorganisation
vers lextrieur, parfois pour des actions aussi sensibles que de
ladministration de serveurs, de donnes ou dapplications.
Plus rares encore sont les fonctions externalises qui nont pas
manipuler des donnes ou informations appartenant au patrimoine de
lorganisation. Le cocontractant a alors la responsabilit de lintgrit, de
laccessibilit et de la protection des donnes.
Dans tous les cas, la dimension informatique de lexternalisation est au
cur de sa rversibilit. Elle peut tre la cause de son irrversibilit.
Laudit dune fonction externalise devra donc en aborder la dimension
informatique, tant pour lorganisation que pour son cocontractant.
Lauditeur devra donc, loccasion de laudit dune fonction externalise :
identifier les donnes et informations numriques changes
loccasion de lexcution de la prestation externalise ;
identifier les ressources informatiques matrielles (serveurs,

rseaux, etc.) et applicatives qui y contribuent, et le personnel
interne et extrieur qui les administrent et les utilisent ;
vrifier que le contrle interne (y compris la rsilience) appliqu

ces ressources est en cohrence avec leur importance pour
lorganisation ;
Lauditeur devra selon les cas rencontrer :

les acteurs oprationnels de lorganisation chargs des relations
courantes avec le prestataire, pour identifier les ressources
informatiques (informationnelles, matrielles et humaines)
concernes par la prestation externalise ;
la direction gnrale du primtre auquel appartient le champ

audit, pour valuer dans quelle mesure elle est consciente de la
dimension informatique de la prestation externalise ;
la direction charge des achats, pour examiner comment les

aspects informatiques ont t traits dans le march
dexternalisation. Dans lidal, ce march comportera une clause
daudit permettant lauditeur dexaminer les oprations
informatiques ralises par le prestataire loccasion de
lexcution du march ;
la direction charge des systmes informatiques, pour vrifier

quelle a valid les changes avec le prestataire, y compris le cas
chant les modalits dinterconnexion entre le systme
informatique de lorganisation et celui du prestataire ;
25
si le march le permet, le prestataire, pour examiner la sret, la

scurit, la rgularit et la conformit au march des oprations
informatiques quil effectue loccasion de la prestation ;
la direction charge de la supervision du contrle interne, pour

vrifier quelle a bien pris en compte lexistence dune
externalisation dans le dispositif de contrle interne appliqu aux
ressources informatiques.
le ou les march(s) organisant lexternalisation ;
la description des processus externaliss et de ceux impacts par

lexternalisation ;
linventaire des ressources informatiques utilises pour ou

impactes par lexcution de la prestation externalise
(notamment la cartographie des applications et des systmes) ;
les documents contractuels fournir par le prestataire assurant

de son respect des dispositions contractuelles et rglementaires
dans le domaine informatique ;
la description du dispositif de contrle interne prcisant la part

revenant au prestataire et celle supporte par les systmes
informatiques.
Au final, lauditeur devra porter une apprciation sur la qualit de la prise

en compte des problmatiques informatiques dans le cadre de
lexternalisation audite. Il devra se prononcer sur les fragilits
ventuelles rsultant de la dimension informatique de lexternalisation,
notamment en termes de rversibilit, de scurit et de contrle interne.
26
2.1.5.
LES AUDITS DE PROJETS NON SI
sagissant du projet, vrifier que les ressources mises disposition

de lquipe projet (matriels, applications, support) sont
adaptes, et que les rgles, notamment celles relatives la
scurit des systmes d'information (SSI), sont adaptes, connues
et appliques. Il lui faudra notamment vrifier quelle inclut des
personnes capables de traiter les enjeux informatiques de la cible
du projet ;
sagissant de la cible du projet, vrifier que la dimension

informatique des processus, organisation, etc. viss sont
convenablement inventoris et pris en compte de manire
raliste.
Au-del des projets spcifiquement informatiques (applications,

infrastructures, migrations de donnes, etc.) qui font lobjet de
dveloppements ultrieurs, la plupart des projets contiennent une
dimension informatique, qui concerne la fois la conduite du projet et la
cible vise.
Ainsi, les ressources informatiques mises la disposition de lquipe
projet doivent tre adaptes et utilises convenablement. Il sagit autant
dergonomie que de rsilience et de scurit, surtout pour un projet
stratgique ou sensible.
Par ailleurs, quel que soit le projet (organisationnel, industriel, RH,
cration dun nouveau service aux administrs, etc.), la cible finale
comportera trs certainement une dimension informatique. Il pourra par
exemple sagir de dvelopper les outils ncessaires un nouveau
processus, de dmnager des services avec leurs ressources
informatiques associes, sans rupture de la production, dassurer la
convergence entre les systmes informatiques de deux entits fusionnes
ou, au contraire, leur sparation lors dune scission.
Dans tous les cas, une mauvaise anticipation des oprations raliser sur
les outils informatiques est susceptible davoir un impact fortement
ngatif sur le droulement, voire la russite, du projet. Laudit dun projet
devra donc en identifier les enjeux informatiques et vrifier leur correcte
prise en compte.
Lauditeur devra donc, loccasion de laudit dun projet :

identifier prcisment le primtre informatique (matriels,
applications, donnes et ressources humaines) du projet, en
distinguant clairement le projet lui-mme et la cible vise ;

la direction du projet, pour sassurer quelle dispose des leviers
daction et des ressources ncessaires la bonne conduite du
projet, et pour vrifier quelle a suffisamment anticip limpact du
projet en matire SI, notamment en matire de conduite du
changement ;
la direction charge des systmes informatiques, pour vrifier

quelle est convenablement associe la dfinition des attendus
informatiques du projet.
le document de management du projet et les objectifs assigns au
projet ;
la description des processus cibles et de leur dimension

informatique ;
linventaire et la cartographie des donnes, applications et

systmes informatiques impacts ou mis en place par le projet ;
27
les comptes-rendus de la comitologie, notamment ceux qui

abordent les aspects informatiques.
Au final, lauditeur devra porter une apprciation sur la qualit de la prise

en compte des problmatiques informatiques dans le cadre du projet
audit. Il devra se prononcer sur les fragilits ventuelles rsultant de la
dimension informatique du projet, notamment en termes dalignement
stratgique de linformatique avec les objectifs du projet, de scurit
physique et logique, et de contrle interne.
28
2.2.
LES MISSIONS DAUDIT DONT LOBJET

PRINCIPAL APPARTIENT AU DOMAINE DES SI
Cette sous-partie a pour objectif de montrer en quoi des audits focaliss

sur linformatique doivent sextraire du strict primtre de linformatique
pour aborder des dimensions ayant un impact sur le SI. Elle ne dcrit bien
sr pas le cur de la mission daudit, objet de la troisime partie, mais
donne quelques pistes pour aller plus loin .
2.2.1.
Au-del, si la correction dune faiblesse de lapplication audite ncessite

la modification dun ou plusieurs lments de son environnement,
lauditeur doit recommander les volutions ncessaires.
Ainsi, laudit dune application, surtout sil est suscit par une situation
pathologique, peut entraner la remise en cause :
de lurbanisation du systme informatique ;
de la formation des utilisateurs, y compris le personnel de la

production informatique (administrateurs, soutien aux
utilisateurs, etc.) ;
de larticulation entre les fonctions tudes et production ;
du ou des processus au(x)quel(s) contribue lapplication, y

compris le dispositif de contrle interne mis en place pour en
matriser les risques ;
de lorganisation du soutien externalis de lapplication ;
de lorganisation de la gouvernance de la fonction informatique.
LES AUDITS DAPPLICATION
Une application nexiste que pour rpondre un besoin. Elle est conue,
ralise, paramtre, administre, entretenue et utilise par des agents
appartenant ou non lorganisation. Elle peut tre utile un ou plusieurs
processus, leur tre parfaitement adapte ou au contraire tre une
entrave leur bon droulement. Elle peut sinscrire dans une urbanisation
matrise ou contribuer lhtrognit, la duplication, voire au
dsordre du systme informatique. Elle peut donc tre une source de
force ou de vulnrabilit parfois les deux pour lorganisation.
Au-del des aspects classiques dun audit dapplication en production (cf.
chapitre 3), laudit dune application informatique peut donc ncessiter
lexamen de lurbanisation du systme informatique, de la cohrence
entre les logiciels et les matriels quils utilisent, de lalignement
stratgique du systme informatique sur les objectifs de lorganisation,
voire de la gouvernance du SI, en ce quelle explique pour une large part
les forces et faiblesses observes.
En effet, les recommandations mises au terme de laudit ne peuvent
faire abstraction de cet environnement. Tout cela suppose une
comprhension de la fonction informatique allant trs au-del du simple
objet audit.
Cela vient videmment en complment des aspects examiner proposs

en troisime partie du prsent guide.
Pour autant, le mandat de lauditeur dans le cas despce nest pas laudit
de la fonction informatique dans son ensemble mais celui dune
application bien dfinie. Il devra donc veiller constamment ce que ses
diligences et recommandations aient un lien avec lapplication audite.
29
des modalits dexpression et de recueil des besoins mtiers ;
Un projet informatique nexiste que pour rpondre un besoin. Il faut

donc sassurer, au-del du respect de la mthodologie de conduite du
projet, que le besoin existe, quil a t convenablement recueilli et
exprim, et quil nest pas perdu de vue. Lauditeur peut sappuyer pour
cela sur des outils danalyse de la valeur1.
du processus darbitrage entre projets concurrents ;
de lorganisation de passation des marchs avec les matres

duvres informatiques, voire avec les assistances matrise
douvrage ;
Lauditeur peut se retrouver face un projet qui, au lieu de respecter

lurbanisation en vigueur, contribue au contraire lhtrognit, voire
au dsordre du systme informatique. Cependant, l'irrespect du cadre
urbanistique par un projet ne doit pas entraner une condamnation
automatique, car cette incohrence peut rvler une urbanisation ou une
organisation urbanistique inadquates qui dans ce cas ne doivent pas
ncessairement prvaloir sur le projet et ses attendus.
de la gestion des processus au sein de lorganisation, notamment

du processus ayant suscit le projet audit ;
de lorganisation de ce processus ;
de lorganisation de la gouvernance de la fonction informatique ;
de lurbanisation du SI de lorganisation.
2.2.2.
LES AUDITS DE PROJETS INFORMATIQUES
Au-del des aspects classiques dun audit de projet (cf. chapitre 3),
lauditeur doit donc examiner la qualit de lexpression, du recueil et de la
traduction du besoin, lurbanisation du systme informatique, linscription
du projet dans cette urbanisation, voire la gouvernance du SI, en ce
quelle explique pour une large part les forces et faiblesses observes. En
effet, les recommandations mises au terme de laudit ne peuvent faire
abstraction de cet environnement. Tout cela suppose une comprhension
de la fonction informatique allant trs au-del du simple objet audit.

de la fonction informatique dans son ensemble mais celui dun projet
particulier. Il devra donc veiller constamment ce que ses diligences et
recommandations aient un lien avec ce projet.
Au-del, si la correction dune faiblesse du projet audit ncessite la

modification dun ou plusieurs lments de son environnement, lauditeur
doit recommander les volutions ncessaires.
Ainsi, laudit dun projet, surtout sil est suscit par une situation
1
Par exemple MAREVA 2, spcifiquement cr pour rendre compte de la

pertinence des projets SI
30
2.2.3.
LES AUDITS DE SECURITE
Un dispositif de scurit nest pas une fin en soi. Il nexiste que pour
protger des actifs. Il faut donc sassurer, au-del des aspects examins
habituellement dans le cadre de laudit de la scurit gnrale
informatique (cf. chapitre 3), que le dispositif de scurit est justifi et
quilibr.
La scurit informatique ne se rsume pas linformatique. Elle intgre
bien sr les scurits logique et physique de linformatique, y compris
dans leur dimension rsilience , frquemment oublies notamment
pour les systmes priphriques, comme les imprimantes ou tlphones
en rseau, le contrle des accs et temps de travail, linformatique
industrielle ou la gestion technique des btiments, mais stend bien audel. Elle sintgre dans un dispositif global de scurit, destin protger
tous les actifs de lorganisation et non seulement ses actifs informatiques
ou dmatrialiss, et doit tre en cohrence avec les efforts raliss en
dehors du domaine informatique.
Elle dcoule dune culture (ou inculture) de la scurit propre chaque
organisation. Elle procde dune identification et dune valuation de
limportance des actifs, dune analyse des menaces pesant sur eux et des
vulnrabilits de lorganisation, dune dcision quant laversion au
risque de lorganisation et aux modalits et dispositifs de scurit qui en
dcoulent. Elle doit aussi procder dune juste valuation des contraintes
normatives pesant sur lorganisation.
Au-del des aspects classiques dun audit de scurit informatique,
lauditeur doit donc examiner la qualit de linventaire des actifs, de
lvaluation des risques, du processus dcisionnel ayant conduit la
dfinition dun dispositif de scurit et de la pertinence et la qualit de ce
dispositif. En effet, les recommandations mises au terme dun audit de
scurit ne peuvent faire abstraction de ces aspects.
Au-del, si la correction dune faiblesse du dispositif de scurit audit

ncessite la modification dun ou plusieurs lments de son
environnement, lauditeur doit recommander les volutions ncessaires.
Ainsi, un audit de scurit, surtout sil est suscit par une situation
de linventaire et de lvaluation des actifs protgs par le
dispositif de scurit ;
de lanalyse des menaces pesant sur ces actifs et des

vulnrabilits devant tre corriges ;
de la gouvernance et de la culture de la scurit au sein de

lorganisation, le cas chant au-del du seul primtre
informatique ;
de lquilibre global dune part, entre les efforts consacrs la

scurit informatique et ceux consacrs la scurit en gnral
et, dautre part, entre la valeur des actifs protger ou les
normes qui leurs sont applicables et les efforts consacrs la
scurit informatique.

de la scurit dans son ensemble mais celui de la scurit informatique. Il
devra donc veiller constamment ce que ses diligences et
recommandations aient un lien avec cette dernire.
31
2.2.4.
LES AUDITS DE QUALITE DES DONNEES
Les donnes, surtout lorsquelles sont suffisamment importantes pour

susciter un audit, sont parmi les actifs les plus prcieux dune
organisation. La qualit des donnes est gnralement indispensable au
bon droulement des processus. Elle porte souvent un enjeu financier
(rfrences fournisseurs, lments de calcul de la paie, etc.), parfois vital
(sagissant par exemple des dossiers mdicaux informatiss).
La qualit de la donne est duale : elle est interne , sagissant par
exemple de lexactitude de la donne, mais aussi externe , notamment
les mtadonnes sy rapportant. En effet, la catgorisation dune donne
(identification de donnes comme tant sensibles, telle des coordonnes
bancaires ou des critures comptables, des donnes personnelles, ou
relevant du secret industriel, mdical, de la dfense nationale, etc. devant
ce titre tre protges), qui conditionne le rgime qui lui est applicable
(droits daccs et de modification), peut tre aussi importante que la
donne elle-mme.
De mme, la qualit des libells en plein texte ou le renseignement des
mots cl associs aux documents peuvent tre indispensables au bon
fonctionnement des fonctions de tri et des algorithmes de recherche
automatique.
De nombreux acteurs et processus produisent de la donne, et de
nombreux acteurs et processus peuvent tre impliqus dans la cration,
la mise jour et la destruction dune donne particulire ou de ses
mtadonnes. Cest pourquoi, toute donne devrait avoir un propritaire
explicitement dsign dans lorganisation, responsable sinon de sa
cration, de son entretien, de sa suppression, de sa protection, de son
intgrit, de sa disponibilit et de sa localisation, du moins de la dfinition
des droits et rgles applicables la totalit de ces dimensions et de la
vrification de leur attribution et de leur respect.
Par ailleurs, pour le fonctionnement dune organisation, la non

duplication (par exemple dans des fichiers bureautiques locaux) est un
enjeu au moins aussi important que la qualit interne ou externe dune
donne.
En effet, une donne prime conserve localement peut tre utilise en
lieu et place de la donne actualise conserve dans la base de donnes
adquate, et il est trs probable que la copie ne bnficiera pas des rgles
de gestion applicables loriginale.
Au-del de la vrification ponctuelle de la qualit interne dun ensemble
de donnes, lauditeur doit donc examiner leur qualit externe. Il devra
sintresser aux processus aboutissant une opration sur les donnes,
aux responsabilits relatives la dfinition des rgles applicables en la
matire et au respect de leur mise en uvre.
Ainsi, un audit de qualit des donnes peut entraner la remise en cause :
des rgles et processus applicables la gestion des donnes et
des mtadonnes ;
de lorganisation mise en place, si elle ne prvoit pas que chaque

donne ait un unique propritaire ayant autorit pour dfinir et
faire appliquer les rgles y relatives ;
de lurbanisation du SI, si des phnomnes de duplication des

donnes sont observs, ou si la mise en place dentrepts de
donnes savrait insuffisamment tudie ;
voire des PRI/PCI et PRA/PCA, sagissant de la disponibilit des

donnes (la rplication non matrise tant parfois une
garantie contre lindisponibilit).
32
Pour autant, le mandat de lauditeur dans le cas despce nest pas un

audit de lorganisation ou de la rsilience mais celui de la qualit des
donnes. Il devra donc veiller constamment ce que ses diligences et
recommandations aient un lien avec cette dernire.
33
2.2.5.
LES AUDITS DE REGULARITE SPECIFIQUES
La rgularit des oprations du domaine de linformatique rsulte la fois

dun corpus normatif interne lorganisation et de normes fixes par les
pouvoirs publics. Lauditeur doit valuer les carts entre les activits
informatiques et ces normes, impratives.
Toutefois, aucune norme, y compris publique, nest intangible.
Notamment, un auditeur agissant pour le compte dune organisation
tatique, a fortiori un auditeur appartenant un corps dinspection
gnrale tatique, doit recommander aux services audits de travailler
lvolution des normes nationales qui leurs sont applicables lorsquelles
sont inadaptes, plutt que de cder la facilit du contournement. Il
doit videmment recommander la modification dune norme interne
contre-productive.
Il appartient donc lauditeur ralisant un audit de rgularit
(informatique) de sassurer que les efforts fournir pour appliquer les
normes sont raisonnables au vu des contraintes et objectifs de
lorganisation concerne, voire de se prononcer sur leur (in)applicabilit.
Pour ce faire, il ne devra pas hsiter comparer la situation observe avec
celle prvalant dans des organisations quivalentes.
Par ailleurs, lauditeur ne devra pas se limiter la rgularit vis--vis de

lactivit informatique (CNIL, licences, scurit logique, etc.). Il lui
appartient galement de sassurer que les oprations ralises par le
systme informatique audit sont en elles-mmes rgulires. Par
exemple, un systme de traitement des donnes individuelles peut
satisfaire les normes de scurit informatique tout en appliquant des
rgles de gestion statutaires irrgulires.
Ainsi, un audit de rgularit, surtout sil est suscit par une situation
du corpus normatif interne lorganisation ;
du corpus normatif public applicable ;
de la rgularit des oprations mtier ralises au moyen du

systme informatique audit.
Face un cart en termes de rgularit, lauditeur doit recommander une

action de correction des pratiques ou de modification de la norme, voire
les deux, la correction de la norme apparaissant alors comme un objectif
de long terme tandis que la mise en conformit doit tre un objectif de
court terme.
Face une norme inapplicable, ou dont lapplication demanderait des
efforts draisonnables, lauditeur doit se prononcer sur les risques que
lirrgularit fait peser sur lorganisation, en veillant ne pas se limiter
aux risques juridiques : une norme tant rarement une fin en soi, sen
affranchir expose gnralement des risques oprationnels.
34
3. APPROCHE THEMATIQUE ET
TECHNIQUE DES PRINCIPAUX
DOMAINES DAUDIT DES
SI
Les deux premires fiches (3.1 et 3.2) sont transverses. Les fiches
suivantes doivent tre considres comme venant en complment
thmatique des problmatiques de gouvernance et de scurit.
Il est important de noter quelles prsentent des points de contrle
basiques caractre illustratif qui doivent tre adapts au contexte, aux
enjeux et aux risques propres laudit ralis. Ils ne doivent pas ainsi tre
considrs comme exhaustifs ou ncessairement suffisants aux travaux
daudit.
Sommaire des principaux domaines daudit tudis

3.1.
3.2.
3.3.
3.4.
3.5.
3.6.
3.7.
3.8.
AUDIT DU PILOTAGE DES SYSTEMES DINFORMATION

AUDIT DE SECURITE
AUDIT DE LA PRODUCTION INFORMATIQUE
AUDIT DES APPLICATIONS INFORMATIQUES EN SERVICE
AUDIT DU SUPPORT UTILISATEURS ET DE LA GESTION DU
PARC
AUDIT DE LA FONCTION TUDE
AUDIT DES PROJETS
AUDIT DES MARCHES SPECIFIQUES AU DOMAINE
INFORMATIQUE
p. 37
p. 43
p. 51
p. 59
p. 67
p. 69
p. 73
p. 91
Ils sont, en outre, adapts des organisations et des cycles de

dveloppement classiques (dits cycles en V). Ainsi, ils peuvent ne pas tre
totalement applicables et appropris pour les modes dorganisation et les
mthodes actuelles prnant le dcloisonnement des matrises douvrage
et duvre et les dveloppements en mode agile.
Par ailleurs, ces approches doivent tre appliques en subsidiarit des
ventuels rfrentiels officiels daudit et de contrle en vigueur au
moment des audits.
35
36
3.1.
AUDIT DU PILOTAGE DES SYSTEMES
DINFORMATION
La notion de maturit dune organisation dans le domaine des systmes
dinformation est une notion importante dans la comprhension et
lvaluation du rle et de la performance de linformatique dans
lorganisation. Cette maturit se dcline dabord sur les plans fonctionnel
et technologique, puis sur le plan organisationnel et managrial.
Lobjectif de laudit est dvaluer la maturit informatique de
lOrganisation et ladquation du rle, du positionnement et des objectifs
de la DSI avec les enjeux de lOrganisation.
1.3. valuer le degr dimplication et de matrise de la DG dans les

systmes dinformation de lOrganisation :
systmes dinformation et innovations technologiques
intgres dans le Projet de service ?
1.4. Vrifier quont t crs des Comits informatique (stratgique,

pilotage,..) regroupant les diffrentes directions de lOrganisation en
charge de recenser les besoins et les opportunits, grer les priorits
et suivre les projets :
Points de contrle
1. Rle et positionnement de l'informatique dans
l'organisation
1.1. La DSI est-elle rattache la DG et prsente au COMEX ?
1.2. Vrifier lexistence dune charte informatique ou de tout autre
document dfinissant le rle et le primtre de responsabilit de la DSI :
sassurer que la DSI est limite son rle de MOE (versus
MOA), comprenant notamment : la conception, ralisation,
mise en uvre et lexploitation des solutions, la
responsabilit des choix darchitecture et des solutions
techniques afin de garantir la cohrence densemble, la
(co)responsabilit des achats informatiques,
vrifier que la DSI est une force de proposition et de conseil

dans le domaine des technologies de linformation.
prendre connaissance des communications interne et

externe.
valuer le rle et le poids exacts de ce comit. Prendre

connaissance de ses objectifs, de sa composition et des
comptes-rendus de ses runions.
1.5. Vrifier que les mtiers assurent leur rle de MOA, en prenant en
charge des aspects suivants :
le pilotage du SI et des projets ainsi que la responsabilit des
budgets ;
la dfinition des processus et lanalyse des besoins,

notamment dans le domaine de la scurit (classification des
donnes en termes de disponibilit, dintgrit et de
confidentialit) ;
la gestion du changement, la gestion des volutions de

lapplication (gestion des demandes, arbitrages, priorits,
budget) et son administration ;
la validation des traitements et la recette des nouvelles

versions.
37
1.6. Vrifier en pratique que le leadership des grands projets :
notamment de la dlimitation des zones fonctionnelles ;
informatiques de lOrganisation est assur par une quipe

comptence sous le contrle et lautorit des directions
gnrales et mtiers et que le modle de coopration
matrise duvre / matrise douvrage est mature et oprant.
2. Planification stratgique
2.1. Primtre fonctionnel (couverture, ouverture et dpendance des SI).
2.2. Prendre connaissance du schma directeur de lOrganisation (ou de
ses axes stratgiques et ses grands projets) et analyser le plan
informatique et la feuille de route du SI ministriel :
analyse des processus dlaboration et de validation du plan

(contenant) ;
analyse de la pertinence du plan (contenu) et de son

alignement stratgique ;
analyse de ladquation des comptences et des ressources

aux objectifs du plan.
2.3. Analyse des procdures de pilotage et de mise jour du plan

informatique :
analyse des dispositifs de pilotage et de suivi de la ralisation

du plan ;
analyse du rle des comits et des procdures de mise jour

du plan (priodicit annuelle minimum).
2.4. Prendre connaissance des documents durbanisme de lOrganisation :
analyse des processus dlaboration et de validation du

document (contenant) ;
analyse
de
la
pertinence
du
document
(contenu),
analyse des schmas directeurs des zones fonctionnelles.
2.5 Analyse des procdures de pilotage et de mise jour du plan

doccupation des sols (POS) :
analyse des dispositifs de pilotage et de suivi de la ralisation
du plan ;
analyse du rle des comits et des procdures de mise jour

du plan (priodicit annuelle minimum) ;
analyse du positionnement dans lOrganisation et du rle des

responsables de zones fonctionnelles, de quartiers
fonctionnels et de blocs fonctionnels.
2.6. Cohrence & homognit des technologies (homognit des OS,

SGBD, postes de travail, langages, rationalisation des plateformes,
standardisation des configurations,).
2.7. Intgration et fiabilit des applications.
2.8. Unicit des rfrentiels (clients, fournisseurs, articles,) et des
saisies.
3. Budgets et cots informatiques

Prendre connaissance et valuer lorganisation et les processus :
analyse du processus dlaboration et de validation du
budget (qui, quand, comment) ;
analyse du primtre du budget (gographique et

organisationnel, charges et investissement,) et valuation
de son caractre exhaustif ;
analyse de lorganisation du contrle de gestion

informatique (existence dun contrleur de gestion ddi au
sein de la DSI ?) ;
38
analyse des outils et procdures de suivi analytique, de

contrle des cots, danalyse des carts et le cas chant de
refacturation des utilisateurs ;
analyse des tableaux de bord et des procdures de reporting
(cf. chapitre Mesure et suivi de la performance).
3.2. tablir des ratios et des lments de benchmark (interne et/ou

externe, ratio cots/CA, ). Attention : manier avec prcaution, les
ratios de cots IT ne sont quun lment dvaluation parmi dautres et
les benchmarks doivent tre fiables pour tre utiliss.
4. Mesure et suivi de la performance informatique

4.1. Des objectifs de court, moyen et long termes ont-ils t assigns la
DSI (approche BSC ?) et ces objectifs sont-ils dclins au sein des
organisations ?
4.2. Existe-t-il un comit informatique regroupant les diffrentes
directions de lorganisation et dont les principaux objectifs sont :
le recensement des opportunits, la gestion des priorits, la
validation des investissements et la politique de scurit
(stratgie) ;
le suivi et le contrle des performances, de la qualit de la

prestation et de latteinte des objectifs fixs (pilotage).
4.3. Vrifier lexistence et la couverture des engagements de service /

Service Level Agreement (SLA) par application. La qualit de service, pour
lutilisateur, se mesure sur les critres de :
disponibilit et continuit dexploitation (disponibilit
moyenne de lapplication, dure maximum dindisponibilit,
perte maximum de donnes,..) ;
performance (temps de rponse TP, traitement batch,
Interfaces) ;
support (help desk et assistance utilisateur : couverture

horaire et linguistique, dlais de rsolution des incidents,
formation.) ;
scurit
(confidentialit,
intgrit
authentification, non rpudiation,..) ;
des
cots
(cots
dvolution,
fonctionnement,).
rcurrents
cots
donnes,
de
4.4. valuer la pertinence des indicateurs de qualit et de performance

ainsi que les moyens et outils de mesure
4.5. La DSI tient-elle un tableau de bord (idalement de type BSC)
permettant un suivi consolid de la performance (oprationnelle et
financire) et de la qualit des prestations informatiques ?
suivi global de lavancement du plan informatique et suivi
dtaill projet par projet ;
suivi des indicateurs de performance (SLA) par application,

analyse des taux de conformit, suivi de lvolution de la
performance, etc. ;
suivi des cots (mois, YTD) rapprochs du budget ;
suivi dindicateurs internes (taux dutilisation des CPU,

espace disque, analyse du portefeuille des demandes
utilisateurs, productivit des tudes, formation et gestion
des comptences internes, etc.) ;
enqute priodique de satisfaction auprs des utilisateurs,

etc.
4.6. Est-il systmatiquement effectu un bilan aprs chaque projet et

notamment un bilan conomique (bilan rapproch des prvisions de
39
ltude pralable) ?
5. Organisation et structure de la DSI

5.1. Vrifier lexistence dun organigramme jour de la DSI.
5.2. Existe-il une dfinition de fonction et un partage clair des rles et des
responsabilits pour chaque poste figurant sur lorganigramme ?
5.3. Vrifier que lensemble des composantes dune fonction
informatique est convenablement pris en compte, notamment la veille
technologique, la scurit informatique, la fonction qualit & mthodes,
la gestion des ressources humaines, le contrle de gestion, le support
utilisateurs (de proximit et distance), ladministration des serveurs...
5.4. valuer ladquation des effectifs aux besoins et aux enjeux :
analyse de la couverture fonctionnelle et gographique de
linformatique ;
benchmarks internes et externes, ratios effectifs/CA et

Budget IT/CA,
analyse du recours la sous-traitance ;
analyse de la charge du personnel informatique : horaires

pratiqus, portefeuille des demandes utilisateurs, ...
5.5. valuer ladquation des qualifications du personnel avec les

fonctions quils occupent :
prendre en compte la stratgie de lorganisation, ainsi que le
march local de lemploi ;
remettre en perspective le rle, les objectifs et les attentes

vis--vis de linformatique ;
prendre en compte le niveau de risque (risque inhrent

lactivit, dpendance de lorganisation vis--vis de son
systme dinformation, ).
5.6. Lexpression des besoins, les spcifications fonctionnelles et la

recette des applications sont-elles effectues par les utilisateurs ?
5.7. Les tches, les locaux et les environnements relatifs aux fonctions
tudes et exploitation, quils soient assurs ou fournis en interne, ou
externaliss, sont-ils spars ?
Vrifier que les accs aux bibliothques de production
(donnes et programmes) sont interdits aux tudes (y
compris sous-traitants).
5.8. Vrifier lexistence dune procdure de mise en production :
valuer sa pertinence et son niveau dapplication.
5.9. Lorsque les organisations le permettent, vrifier que les diffrentes
tches d'administration des bases de donnes -DBA- sont spares entre
les tudes et lexploitation :
gestion du contenu : architecture des bases, dictionnaire de
donnes ;
gestion du contenant : gestion des configurations et des

performances.
5.10. La sparation des tches est-elle maintenue et assure lors de la

rotation des quipes, des vacances et du dpart d'un personnel ?
5.11. valuer le caractre raisonnable du turn-over de la DSI (5 15% /
an).
5.12. valuer la capacit de lOrganisation grer les carrires des
informaticiens :
prendre connaissance des volutions sur les trois dernires
annes.
40
5.13. Vrifier ladquation du niveau de rmunration du personnel

informatique et valuer le moral des quipes :
valuer les mesures prises par la DSI ou par les RH pour
sassurer de la cohrence vis--vis du march (tude
annuelle, benchmarking,).
5.14. valuer la dpendance de lOrganisation vis--vis dune ou plusieurs
personnes. lments prendre en compte :
dveloppements internes versus progiciel, ge des
applications et technologies mises en uvre, taille des
quipes, niveau de la documentation
5.15. Les contrats des informaticiens contiennent-ils des clauses
spcifiques de confidentialit et de non-concurrence ?
5.16. Les informaticiens sont-ils dispenss de pravis en cas de rupture
brutale du contrat de travail ?
5.17. Existe-il un plan de formation nominatif pour lensemble des
informaticiens ?
5.18. Leffort de formation est-il adapt, suffisant et sinscrit-il dans la
dure ?
5 10 jours par an, sur les trois dernires annes. Formation
individualise qui rpond aux souhaits de lemploy et aux
besoins de lorganisation.
(information, inventaire,).
6.2. Vrifier que la loi sur la fraude informatique est connue et que des
mesures prventives ont t prises :
les bannires daccueil aux routeurs et aux serveurs daccs
distant (de type Bienvenue.. , Welcome ,) sont-elles
bannies et remplaces par des messages davertissement ?
6.3. Vrifier que les lois sur lusage de moyens de chiffrement et de la

signature lectronique sont connues et, le cas chant, respectes.
6.4. Vrifier que la loi sur le contrle fiscal des comptabilits
informatises est connue et, dans la mesure du possible, respecte :
contrler les procdures annuelles de sauvegarde et
darchivage des donnes et des programmes des applications
concernes ;
vrifier lexistence de documentations tudes, exploitation,

utilisateurs et dune procdure de mise jour de cette
documentation ;
sassurer que ces obligations fiscales sont contractuellement

prises en compte avec les fournisseurs concerns : soustraitance dun dveloppement (documentation), ASP ou
infogrance (mise disposition de ladministration), ....
6. Cadre lgislatif et rglementaire Franais

6.1. Vrifier que les prescriptions lgales dcoulant de la loi
Informatique et Liberts sont connues (procdures de dclaration,
documentation, rgles de confidentialit) et respectes :
prendre connaissance et valuer la dmarche et les
procdures mises en uvre au sein de lorganisation
prendre connaissance de la nature et de la pertinence de la

communication interne sur le sujet.
6.5. Vrifier que la loi sur la proprit intellectuelle / logiciel pirate est
connue et rigoureusement respecte :
vrifier lexistence dun inventaire des configurations
logicielles ;
valuer/valider la procdure de mise jour de cet inventaire

41
(une procdure automatique doit tre privilgie) ;
effectuer des contrles sur un chantillon de postes de

travail ;
sur la base de linventaire fourni, contrler les justificatifs de

licences.
42
3.2.
AUDIT DE SECURITE
L'information est un actif prcieux de l'Organisation. ce titre, il faut la

protger contre la perte, l'altration et la divulgation. Les systmes qui la
supportent doivent quant eux tre protgs contre l'indisponibilit et
l'intrusion.
La scurit est une dmarche globale de lOrganisation organise autour
dune politique de scurit. Il faut donc considrer les systmes dans leur
globalit et lensemble des acteurs.
Points de contrle
1. Facteurs cls de succs
1.1. Une politique de scurit est dfinie et correspond l'activit de
l'Organisation.
1.2. Une dmarche de mise en uvre de la gestion de la scurit est
adopte et compatible avec la culture de l'Organisation.
1.3. La direction assure un soutien total et un engagement visible.
1.4. Les exigences de scurit et les risques sont compris et valus.
1.5. Lensemble des responsables et des employs sont sensibiliss et
informs.
1.6. Les lignes directrices de la politique de scurit et des normes de
scurit de l'information sont distribues tous les employs et tous les
fournisseurs.
1.7. Les acteurs de la scurit sont forms de manire approprie.
1.8. Un systme de mesure complet et mis en place afin d'valuer
l'efficacit de la gestion de la scurit de l'information et pour collecter
les suggestions d'amlioration.
2. Politique de scurit
2.1. Il existe une politique de scurit formalise avec une implication de
la direction gnrale et une dfinition claire des responsabilits.
2.2. La communication se fait tous les utilisateurs sous une forme
pertinente, accessible et comprhensible au lecteur.
2.3. Une revue rgulire de la politique est ralise afin de vrifier son
adquation avec :
les volutions des activits de l'organisation et donc des
risques ;
les changements technologiques ;

l'historique des incidents.
2.4. La dmarche de scurit inclut la totalit de linformatique et non les

seuls rseaux, serveurs et applications. Les imprimantes et tlphones
sous IP, linformatique technique et industrielle, linformatique de gestion
technique des btiments, celle de gestion des accs et temps de travail,
etc. bnficient sans exception ni zone dombre du dispositif de scurit.
3. Organisation de la scurit
3.1. Il existe une structure ddie la gestion de la scurit de
l'information : un comit scurit, un responsable de la scurit du
systme d'information (RSSI) et des correspondants scurit dans les
units.
3.2. Il y a une attribution claire des responsabilits.
3.3. Un propritaire est dsign, il est responsable de la mise en uvre et
du suivi des volutions apporter.
3.4. Il existe des procdures d'autorisation de nouveaux matriels ou
logiciels.
43
3.5. Il existe des procdures applicables l'accs aux informations de

l'organisation par des tiers :
les accs par des tiers aux infrastructures de traitement de
l'information sont contrls ;
une analyse des risques a t mene ;
des mesures de protection de l'information ont t tablies

et sont acceptes contractuellement par le tiers : clause de
confidentialit, transfert de proprit, responsabilits, rgles
d'accs physique et logique, restitution ou destruction de
l'information confie, remplacement de collaborateur....
3.6. En ce qui concerne les modalits de protection de l'information

confie des sous-traitants, il faut vrifier :
la prise en compte des exigences de scurit dans les
conditions contractuelles : mesures prises pour scuriser les
donnes pendant l'change et pendant la conservation par le
sous-traitant, modalit de restitution ou de destruction de
l'information confie, possibilit pour le sous-traitant de faire
appel de la sous-traitance, plan de continuit, clause
d'audit ;
le respect des lois pour les donnes personnelles et la

proprit intellectuelle.
3.7. Vrifier qu'il existe des modalits de raction aux incidents de

scurit et aux dfauts de fonctionnement :
signalement rapide des incidents de scurit ;
signalement des failles de scurit ;
signalement du fonctionnement dfectueux de logiciels ;
capitalisation sur la rsolution d'incidents ;
processus disciplinaire.
3.8. Il existe une revue rgulire de la scurit des audits aussi bien
internes qu'externes.
4. Classification et contrle des actifs

4.1. Vrifier que les actifs sont inventoris et hirarchiss par valeur pour
l'organisation.
4.2. Vrifier que pour tout actif important, un propritaire est dsign et
inform de ses responsabilits.
4.3. Vrifier qu'il existe un systme de classification qui dfinit un
ensemble appropri de niveaux de protection.
4.4. Vrifier que chaque actif a fait l'objet d'une tude visant dterminer
son niveau de classification.
5. Scurit du personnel
5.1. Vrifier que les postes et les ressources sont dfinis :
inclusion de la scurit dans les responsabilits des postes ;
slection du personnel et politique de recrutement ;
accords de confidentialit ;
5.2. Vrifier que les utilisateurs sont forms.
6. scurit : gestion des communications et des

oprations
6.1. Vrifier la documentation des procdures et les responsabilits
oprationnelles.
6.2. Contrler les modifications oprationnelles.
6.3. Vrifier l'tablissement de procdures de gestion des incidents.
6.4. Vrifier la sparation des fonctions et des infrastructures.
6.5. Vrifier l'tude de scurit en cas de gestion externe des
infrastructures.
44
6.6. Vrifier les mesures de protection contre les infections logiques.

6.7. Vrifier les sauvegardes des donnes :
ralisation rgulire des copies de sauvegarde des donnes,
des applications et des paramtres ;
distinguer sauvegarde et archivage ;
dterminer les priodes de conservation des donnes ;
conserver plusieurs gnrations de sauvegardes ;
stocker les sauvegarde en lieu sr ;
tester rgulirement les supports de sauvegarde ;

tester rgulirement les procdures de restauration.
6.8. Vrifier les modalits de gestion des supports de donnes :

tenir en lieu sr tous les supports amovibles ;
effacer de manire scurise le contenu des supports

rutiliser hors de l'organisation ;
tablir une procdure de mise au rebut des supports

prvoyant leur destruction ;
tablir des procdures de manipulation des supports

adaptes au niveau de sensibilit de l'information contenue.
6.9. Vrifier les mesures de scurisation des changes de donnes :

dfinition d'accords portant sur les changes d'informations
et de logiciels entre les organisations ;
scurit du courrier lectronique.
7. Conformit
7.1. Vrifier la conformit aux exigences lgales et rglementaires :
protection des donnes personnelles ;
respect de la proprit intellectuelle ;

conservation de l'information.
7.2. Effectuer des audits de scurit rguliers :

internes et externes ;
revue systmatique et tests empiriques (exemple : test

d'intrusion) ;
protection des outils d'audit des systmes ;
protection des rapports d'audit de scurit.
8. Gestion des identifiants et des mots de passe

8.1. Vrifier qu'il y a un seul utilisateur par identifiant.
8.2. Vrifier que les identifiants inutiliss pendant un certain dlai sont
rvoqus.
8.3. Vrifier que les rgles de bases sont connues et mises en place :
utilisation systmatique ;
le titulaire doit tre le seul connatre son mot de passe ;
changement priodique ;
rgles de composition ;
procdures en cas d'inactivation ou de perte.
9. Contrle des accs

9.1. Vrifier la dfinition et la documentation de la politique de contrle
d'accs :
exigences de scurit des applications individuelles de
l'organisation ;
politiques de dissmination de l'information et d'autorisation

d'accs ("besoin d'en savoir") ainsi que les niveaux de
45
scurit et la classification de l'information ;
obligations contractuelles concernant la protection de l'accs

aux donnes ;
profils d'accs standard des utilisateurs pour les catgories

communes de travail ;
distinction des rgles obligatoires et des recommandations

facultatives ;
tablissement de rgles "tout est interdit sauf" plutt que

"tout est permis sauf" ;
rgles devant tre valides par un responsable (sparation

des fonctions).
9.3. Vrifier l'utilisation de mots de passe et de systmes de dconnexion

automatique :
tout compte utilisateur doit tre protg par un mot de
passe ;
engagement des utilisateurs :

ne pas divulguer leur mot de passe ;
ne pas crire leur mot de passe de faon trop vidente ;
ne pas stocker leur mot de passe dans une procdure
automatique ;
changer leur mot de passe ds qu'ils le souponnent
d'tre compromis ;
contrler qu'un mot de passe temporaire est envoy pour la

premire utilisation et qu'il est bien chang par l'utilisateur
ds la premire utilisation ;
9.2. Vrifier la gestion des accs utilisateurs :

identification unique des utilisateurs (tous les utilisateurs) ;
vrification que l'utilisateur a t autoris par le propritaire

des informations ;
contrler que les mots de passe temporaires sont transmis

aux utilisateurs de manire sre ;
suppression des droits d'accs d'un utilisateur ayant chang

de poste ou quitt l'organisation ;
contrler que le systme impose un changement rgulier du

mot de passe ;
contrle priodique et suppression des codes d'identification

utilisateurs redondants et des comptes qui ne sont plus
utiliss ;
contrler que le systme impose le choix de mots de passe

robustes ;
discipline utilisateur pour la dconnexion ;
non-raffectation des codes d'identification ;
attribution des privilges aux individus sur la base de leurs

"besoins minimum" par rapport la fonction qu'ils
remplissent ;
la dconnexion doit tre automatique en cas d'inactivit

prolonge.
examen rgulier des droits d'accs utilisateur.
9.4. Vrifier le contrle des accs aux rseaux :

authentification des utilisateurs pour les connexions
externes ;
protection des ports de diagnostic distance et de

46
preuve) ;
tlmaintenance ;
contrle des flux (firewalls) ;

cloisonnement.
9.5. Vrifier le contrle de l'accs aux systmes d'exploitation :

identification / authentification des utilisateurs ;
9.8. Vrifier la gestion de l'informatique mobile :

contrle d'accs aux ordinateurs portables ;
protection des donnes stockes (chiffrement) ;
protection contre les virus ;
limitation du nombre de tentatives infructueuses ;
sauvegardes ;
enregistrement des tentatives infructueuses ;
connexions automatiques distance ;
limitation des jours et heures de connexion ;
affichage de la dernire connexion ;

protection de l'accs aux utilitaires.
sensibilisation du personnel dot d'ordinateurs portables :

confidentialit du travail dans les lieux publics ou
moyens de transport ;
surveillance du matriel contre le vol ;
espionnage industriel.
9.6. Vrifier le contrle de l'accs aux applications :

restriction des accs l'information ;
isolation des systmes critiques.
9.7. Vrifier la surveillance des accs aux systmes et leur utilisation :
consignation des vnements :
constitution des journaux d'audit :
qui, quand, quoi, d'o ;
surveillance de l'utilisation des systmes activits sensibles

(oprations privilgies, modification de la scurit) ;
alertes sur incident (violation, tentatives infructueuses,

notification de firewall ou de sdi) ;
utilisation anormale ou atypique des ressources ;
auditabilit des journaux ;
revue rgulire des journaux ;
synchronisation des horloges :

assure l'exactitude des journaux d'audit (lments de
9.9. Vrifier les suites donnes aux incidents :

vrifier les ractions des possesseurs des ordinateurs
incidents ;
vrifier les modalits effectives de remonte de linformation

sur lincident, ses dlais, son parcours, son format ;
vrifier les mesures disolement du ou des ordinateurs

incidents ;
vrifier leffectivit des mesures de communication dalerte ;
vrifier leffectivit des mesures denqute et de

lexploration mene pour identifier les failles du systme
ayant permis lincident.
vrifier les modalits et le contenu de la communication des

rappels vers les utilisateurs lissue de la crise, ou des
nouvelles consignes.
47
10. Dveloppement et maintenance des systmes

10.1. Exigences de scurit des systmes :
expression des besoins, contrle interne, piste d'audit,
scurit ;
spcification dtaille des besoins, contrle interne, piste

d'audit, scurit ;
audit des spcifications ;
recette des fonctionnalits de contrle interne, piste d'audit,

scurit ;
audit de la recette ;
audit "post mise en place".
sparation des fonctions dveloppement/exploitation ;
procdure de passage en production lors des maintenances

correctives urgentes (journalisation des actions).
10.4. Scurit des fichiers :

contrle des logiciels oprationnels : mise jour uniquement
par bibliothcaire, uniquement code excutable, journal
d'audit des versions ;
protection des donnes d'essai des systmes : banalisation

des donnes de production, garder une copie pour rejouer
les tests dans les mmes conditions ;
contrle de l'accs aux bibliothques de programmes

sources : hors de la production, accs rserv aux
dveloppeurs autoriss, gestion des versions et conservation
de l'historique des modifications.
10.2. Scurit des systmes d'application :

validation des donnes d'entre : type, limites de valeur, liste
de valeurs possibles ;
contrle des traitements : contrles

squentielles, totaux de contrle ;
exhaustivit des traitements ;
validation des donnes de sortie :

contrle de plausibilit, rapprochement.
de
Informations collecter
sessions
10.3. Protocole de recette :

tests systmatiques avant le passage en production ;
Organisation :
politique de scurit ;
normes et standards en vigueur ;
personnes et quipes impliques dans lexploitation du

rseau et du parc micro (administration, maintenance,
scurit, support utilisateur ; dfinition des responsabilits) ;
procdures appliques ou prvues (mode dgrad) ;
utilisation d'un environnement diffrent de l'environnement

de production ;
participation des utilisateurs la recette ;
plans (de sauvegarde, darchivage, de secours, de reprise,

etc.) ;
interlocuteurs pour laudit (informatique et utilisateurs).
documentation de la recette et archivage ;

48
Volumtrie :
nombre dutilisateurs ;
volumes de donnes transmises ;

taille des donnes sauvegardes.
Matriels :
serveurs ;
stations de travail ;
quipements rseau (commutateurs, routeurs), firewalls ;
matriel denvironnement (imprimantes,

photocopieurs en rseau, tlphones IP).
Logiciels :
scanner
et
systmes dexploitation ;
middleware ;
principales applications utilises.
Communications :
architecture du rseau (topologie) ;
plan de cblage ;
connexions avec lextrieur.
49
50
3.3.
AUDIT DE LA PRODUCTION
INFORMATIQUE
Un audit de la fonction production consiste analyser la capacit de
lorganisation exploiter les systmes dans des conditions rpondant aux
besoins oprationnels dfinis par les directions utilisatrices. Il sagit
danalyser ladquation des moyens humains, matriels, logiciels et
organisationnels (procdures dexploitation, de sauvegardes, ) mis en
uvre pour rpondre aux enjeux de lorganisation en termes de
disponibilit de ses applications, dintgrit et de confidentialit de ses
donnes et enfin de conformit aux besoins oprationnels des utilisateurs
(notion de qualit de service).
Les aspects relatifs la gouvernance et la scurit sont traits dans les
fiches 3.1 et 3.2. Les points de contrle proposs ci-dessous leur sont
complmentaires.
Points de contrle
1. Enjeux, engagements de service et suivi de la
performance
1.1. Sassurer que les niveaux de services sur lesquels sengage la
production sont en adquation avec les enjeux de disponibilit, dintgrit
et de confidentialit des diffrents systmes.
1.2. Sassurer que les moyens organisationnels (ex : escalade), humains
(ex : nombre et comptences des personnels dastreinte), et matriels
(ex : architecture redondante) permettent un respect des engagements
de service.
1.3. Vrifier que les niveaux de service assurs par la production font
lobjet de conventions de service comportant des indicateurs mesurables :

valider le contenu des conventions de services. Sassurer que les
principaux attributs de la prestation font lobjet dindicateurs de mesure
de la performance et dobjectifs quantifis. Juger la pertinence des
indicateurs et lambition des objectifs au regard des enjeux.
1.4. Sassurer que le suivi de la performance est un process continu :
demander les derniers comptes-rendus lattention des utilisateurs. En
cas de non-respect des objectifs de la convention de service, valider la
pertinence des actions correctives entreprises.
Vrifier que les tableaux de bords de production font lobjet dun suivi
adquat :
se faire communiquer les tableaux de bords de production et juger de leur
pertinence aussi bien que de leur compltude ;
sassurer de lexistence de procdures permettant lquipe de
production de remdier aux ventuels problmes identifis par
lintermdiaire des tableaux de bords.
2. Organisation de la fonction production

2.1. Sassurer que la ligne de partage entre tudes et production est
clairement dfinie et documente.
2.2. Vrifier que l'organisation de la production correspond une rponse
adapte aux besoins oprationnels de l'organisation :
comprendre la structuration du service production. Identifier
les modalits de dcoupage des rles et responsabilits
(dcoupage par application, par technologie, par niveau de
support ) et sassurer quils permettent de rpondre de
manire adquate aux enjeux de disponibilit, de scurit et
dintgrit ;
valider lindpendance de la production par rapport aux

tudes ;
vrifier lexistence de convention de service par application ;

51
vrifier lexistence de moyens de communication normaliss

entre production et autres acteurs de lorganisation ;
2.3. Vrifier que les technologies opres sont suffisamment matrises :

identifier les diffrentes technologies utilises, valider
lexistence pour chacune dentre elles des comptences
suffisantes tant dun point de vue qualitatif que quantitatif
et, si la taille du service de production le justifie, des grilles
croises comptences / individus ;
revoir les budgets formation et ladquation des formations

avec les technologies actuelles et celles induites par le
droulement du plan informatique.
2.4. Vrifier qu'il existe une bonne matrise des diffrentes missions de la
production :
identifier le primtre couvert par la production et en
driver les principales missions assumes ;
valider la couverture de ces diffrentes missions dans les

descriptions de postes ;
se focaliser sur les aspects autres que lopration des
systmes : ex : production dindicateurs de pilotage, capacity
planning, veille technologique, revue qualit, ....
3. Architectures matrielles et logicielles

3.1. Valider que performance et dimensionnement des composantes des
systmes de production font l'objet d'un suivi :
tudier les tableaux de bords techniques en se focalisant sur
les indicateurs de capacit rseau, CPU et mdia de stockage
ainsi que de temps de rponse. Couvrent-ils les
consommations moyennes et les pics dactivit ?
valider la connaissance et le suivi dans le temps du

droulement de la journe de production avec ses goulets
dtranglement et ses marges de scurit ;
les budgets refltent-ils des investissements ncessaires

laugmentation de la capacit de traitement des
architectures existantes ?
3.2. Valider lvolutivit des architectures prsentes. tudier :

la scalabilit des architectures ;
la modularit des architectures ;
le niveau de maturit/obsolescence des architectures

opres (date de fin de maintenance des systmes et
progiciels, versions des langages, ...).
3.3. Vrifier que le dimensionnement des architectures actuelles permet

de rpondre aux engagements de services (indicateurs de pilotage et de
mesure de la performance).
3.4. Vrifier que les infrastructures ne sont pas manifestement
surdimensionnes en regard des besoins actuels et prvisibles.
52
3.5. Vrifier que les configurations matrielles (redondance matrielle et

rseau, architecture disques, clustering CPU, mdia de sauvegarde, )
permettent de garantir le niveau de disponibilit sur lequel la production
sengage.
Type de questions :
les systmes de disques ou de stockage dinformation
(SAN, ) prmunissent-ils contre des pertes dinformation ?
les sauvegardes, leur primtre, et les temps de restauration

sont-ils adapts et en ligne avec les engagements de la
production ?
les accs rseaux sont-ils doubls et les architectures sontelles doubles ?
4. Livraisons en production
4.1. Vrifier les conditions et procdures de livraisons en production.
Valider la dmarche de contrle des livraisons en production et a minima
les points de contrles suivants :
recette fonctionnelle entre tudes et utilisateurs (PV de
recette) ;
ralisation de tests dintgration ;
test des procdures et des packages de livraisons, y compris

retour arrire ;
sauvegarde des environnements impacts avant livraison ;
livraison effectue un moment o un retour arrire est

possible sans impacter le service client (le soir, le weekend, ) ;
recette dexploitation entre tudes et production (PV de

recette).
4.2. Vrifier les conditions et procdures de livraisons en production.

Valider le niveau de responsabilit de la production par rapport aux
livraisons des tudes :
la production a-t-elle un pouvoir de veto si elle estime quil
ny a pas de garantie quant au risque relatif la livraison
(tests non effectus, sources non fournies, livraison non
package et non documente, ) ;
les tudes mettent-elles disposition dans un

environnement tanche les sources et la production prendelle le relais pour les oprations ultrieures (compilations,
paramtrage, ).
4.3. Vrifier la nature des tests effectus par la production. Sassurer que
les machines et les environnements disponibles permettent de raliser le
cas chant les tests suivants :
test de montes en charge (volumtrie pour du
transactionnel2 et exploitabilit pour des traitements
asynchrones) ;
intgration technique portant non seulement sur de

lintgration au niveau du systme mais aussi au niveau de
linteraction avec lordonnanceur de production et le
systme de remonte dalerte ;
tests dinterface avec dautres applications ;
intgration dans larchitecture rseau (filtrage de ports

TCP/IP par un firewall par exemple).
Traitement en temps rel

53
5. Exploitation et gestion des incidents

5.1. Vrifier le dcoupage de la journe de production en tches
clairement dlimites permettant la mise en uvre de points darrt.
Sassurer que les traitements sinscrivent dans la logique suivante :
tout traitement impactant des donnes sensibles peut faire
lobjet dun retour arrire (archivelog, sauvegarde, roll back3,
timestamp4) ;
un traitement modifiant des donnes commence par

analyser la validit des donnes (syntaxe, timeliness, )
avant deffectuer une mise jour et permet de rejeter selon
des rgles connues les transactions ou les lots comportant
des anomalies ;
derreurs exploitables (tracelog, ) ;
lordonnanceur de production ou les outils utiliss (batch

dexcution) permettent larrt du droulement des
traitements en cas derreur grave ;
le niveau dautomatisation de la production permet de

dcaler des jobs non critiques et de mesurer limpact sur le
chemin critique (i.e. le chemin critique de production et les
marges de scurit sont identifis) ;
tout rejet possible par le systme gnre une alerte et est

dment couvert par une procdure de recyclage ;
les outils systmes offrent des garanties comme intgrit et

timeliness des fichiers intermdiaires (puits de donnes -->
Cortex Sink) et capacit de retour arrire (Roll Back
automatique de SGBD) si non pris en compte dans le chemin
dexploitation (sauvegarde intermdiaire) ou dans les
traitements.
lchec dun traitement isol nempche pas de respecter les

dlais de droulement de la journe de production (temps
de ralisation dun traitement trs infrieur aux marges de
scurit).
5.3. Vrifier le patrimoine documentaire utilis par lexploitation :

existe-t-il des guides de production par application ?
le squencement des tches de production est-il
correctement document (dans le robot ou sur papier) ?
5.2. Vrifier la validit des assertions suivantes :

les alertes sont remontes en temps rel la console
dadministration (systme de gestion dalerte - pull et push :
la console vrifie le statut dun systme, un traitement peut
remonter une alerte) ;
les applications et les systmes oprs gnrent des fichiers
les diffrents points de reprise sont-ils clairement identifis ?
existe-t-il une main courante de production traant tout

vnement anormal intervenu et les actions correctives
entreprises ?
existe-t-il un rfrentiel listant typologies dincidents et

actions de rsolution entreprendre ? (aliment sur la base
des anomalies rsolues dans le pass).
Annulation dun ensemble de requtes ou transactions ralises sur une base

de donnes transactionnelle
4
Horodatage dune donne ou transaction
54
5.4. Analyser les procdures dexploitation :

existe-t-il une typologie claire de gravit dincident ?
6. Procdure de sauvegarde et de reprise

6.1. Identifier les diffrentes sauvegardes effectues et les croiser avec les
besoins existants. Valider que toute sauvegarde rpond un besoin prcis
et que tous les besoins sont couverts :
peut-on faire repartir lexploitation partir de sauvegarde
sur site avec des caractristiques de rechargement intgrant
des besoins de forte ractivit (mirroring5, dump (sauvegarde
en masse) de donnes, ) ?
existe-t-il
une
procdure
descalade
dcrivant
spcifiquement quels sont les moyens de rsolution des
problmes (troubleshooting) mettre en uvre par chaque
niveau et les dlais rgissant lescalade. La procdure
descalade permet-elle le respect des engagements de
disponibilit (SLA) ?
les actions entreprendre en fonction du type dincident

sont-elles documentes (ex : fermer le transactionnel, faire
une sauvegarde, gnrer un clich (snapshoot) sur un
environnement pour faire du dbogage, vrifier un certain
nombre dlments, ) ?
gre-t-on un archivage spcifique pour rpondre aux

obligations de la loi de finances pour 1990 sur les
comptabilits informatises ?
gre-t-on des sauvegardes externalises permettant de se

prmunir contre une perte de tout ou partie du SI ?
les astreintes sont-elles explicites ? Couvrent-elles

uniquement le support production ou incluent-elles les
tudes ? Sont-elles en adquation avec les engagements de
disponibilit ?
les primtres incorpors dans les sauvegardes permettent

une reconstruction complte dun systme (OS,
programmes, donnes).
les comptences disponibles au sein de la production

permettent-elles un support adquat de tous les
environnements ?
6.2. Valider que les lments suivants font partie intgrante des
procdures de sauvegarde :
plan de sauvegarde identifiant par serveur / application, le
primtre de sauvegarde (fichiers, programmes, paramtres,
os,..) et la cyclicit ;
acteurs (homme, systme de sauvegarde) en charge de la

ralisation et du contrle des sauvegardes ;
plannings prvisionnels de tests de restauration ;
clauses de rvision des procdures de sauvegardes et des
Rplication en temps rel des donnes sur deux disques durs miroirs
55
primtres (nouvelle
serveur, ) ;
livraison
applicative,
jour.
migration
rgle de remplacement et stockage des medias de

sauvegarde.
6.3. Vrifier le bon suivi des procdures de sauvegarde :

consulter les comptes rendus de sauvegardes et valider la
prise en compte de tout incident mentionn ;
7. La maintenance du matriel et du logiciel de base

7.1. Valider la complte couverture des matriels critiques et logiciels de
base par des contrats de maintenance adapts. Vrifier les engagements
de disponibilit et les contrats de maintenance hardware ainsi que les
clauses dexclusion de garantie :
est-ce que tous les serveurs critiques sont couverts ? Si non,
le fabriquant assure-t-il encore la maintenance de ce
matriel ?
vrifier les bordereaux dentre / sortie des media

supportant les sauvegardes externalises ;
sassurer que le dernier changement des media de

sauvegarde est en ligne avec ce que prconise la procdure ;
en est-il de mme pour les baies de disques et les lments

actifs de rseau ?
rapprocher le planning des livraisons en production et valider

que les ventuelles modifications de primtre ont bien t
incorpores dans les procdures.
les dlais contractuels dintervention et de rparation sontils en adquation avec les engagements de disponibilit ? Les
clauses de pnalits financires sont-elles ralistes et
applicables ?
les conditions physiques de stockage du matriel sont-elles

susceptibles de faire appliquer les clauses de dgagement de
responsabilit ? (temprature, poussire, hygromtrie,..) ?
6.4. Se focaliser sur les aspects de restauration :

sassurer quil existe des procdures de restauration
prcisant les modalits selon lesquelles on peut remonter
partiellement ou totalement un systme en partant des
sauvegardes.
6.5. Valider le suivi du planning prvisionnel de tests de restauration :
consulter les comptes rendus des derniers tests de
restauration ;
regarder leffectivit du plan daction droulant du rsultat

des tests de restauration ;
rapprocher le planning de livraison applicative avec les

procdures de restauration et valider que ces dernires sont
7.2. Vrifier les engagements de disponibilit et les contrats de

maintenance des logiciels de base ainsi que les clauses dexclusion des
garanties contractuelles :
est-ce que tous les OS utiliss sont couverts par un contrat
de maintenance ? Si non, lditeur assure-t-il encore la
maintenance de la version utilise et cette version est-elle
compatible avec dventuels upgrades matriels ?
en est-il de mme pour les SGBD, robot dexploitation et

autres outils dadministration (remonte dalerte,
56
administration rseau, )
les dlais contractuels dintervention et de rparation sontils en adquation avec les engagements de disponibilit ? Les
clauses de pnalit financire sont-elles ralistes et
applicables ?
57
58
3.4.
AUDIT DES APPLICATIONS
Points de contrle
INFORMATIQUES EN SERVICE
Une application informatique ( application software ) est un logiciel
accompagnant, automatisant, ou se substituant un processus ou une
partie de processus de lorganisation. Une application comprend des
programmes, des donnes, des paramtres, une documentation mais
aussi des habilitations pour grer les accs aux donnes et aux
transactions de l'application.
Laudit dune application peut avoir deux vises distinctes : laudit de
fiabilit et de scurit ou laudit d'efficacit et de performance. Un audit
complet couvrira ces deux primtres.
Laudit de fiabilit et de scurit a pour objectif dmettre une
apprciation motive sur la fiabilit de l'outil informatique, c'est-dire sur la qualit du contrle interne de l'application et la
validit des donnes traites et restitues. Ce type daudit
permettra de mettre en vidence d'ventuelles failles dans la
chane de contrle compose de contrles programms effectus
par la machine et de contrles manuels restant la charge des
utilisateurs.
Laudit defficacit et de performance a pour objectifs

dapprcier ladquation de lapplication aux besoins et aux
enjeux de lorganisation, dvaluer sa contribution la cration de
valeur, dvaluer sa performance et sa rentabilit et enfin
d'valuer sa prennit et sa capacit dvolution.

complmentaires.
1. Audit de la scurit et de la fiabilit : analyse des
risques associs l'organisation

1.1. Existe-t-il un comit informatique, prsid par la direction gnrale et
au sein duquel les directions utilisatrices sont reprsentes et influentes
(stratgie, contrle et pilotage,..) ?
1.2. Existe-il, au sein de lorganisation, une politique relative aux
applications, connue, partage et mise en uvre :
couvrant lensemble du cycle de vie de lapplication

(conception, exploitation) ;
favorisant la responsabilisation et lappropriation par les

utilisateurs de leur systme dinformation ? La notion de
proprit dapplication est-elle utilise ?
1.3. Le rle et les responsabilits des utilisateurs vis--vis de lapplication

sont-ils clairement identifis et couvrent-ils lanalyse des risques, la
dfinition des besoins de scurit, la gestion des changements et des
volutions, ladministration de lapplication ?
1.4. A-t-il t ralis une analyse des risques, spcifique lapplication,
qui a dbouch sur la dfinition des besoins de scurit (classification
formelle des donnes et des traitements en termes de disponibilit,
dintgrit et de confidentialit) ?
1.5. Dans le prolongement de lanalyse des risques et de lexpression des
besoins de scurit, a-t-il t mis en uvre un contrat de service (SLA)
entre linformatique et la direction utilisatrice ?
1.5. Indpendamment de lapplication :
prendre connaissance et analyser le niveau de contrle
59
interne et de sparation des tches au sein de la direction

utilisatrice ;
valuer le niveau de sensibilit des utilisateurs la scurit

ainsi que le niveau de maturit de lorganisation vis--vis
de ses systmes dinformation.
1.7. Existe-il un manuel dadministration de lapplication, jour et

matris, comprenant notamment : mode demploi du manuel,
prsentation du module dadministration de lapplication, droits daccs
type par poste, procdure de cration / modification / suppression de
droits daccs, responsabilit dautorisation, mode opratoire,
documentation des pistes daudit et nature des contrles raliser,
1.8. Vrifier lexistence de procdures formalises imposant laccord du
propritaire de lapplication pour tout changement sur :
les programmes de lapplication (maintenance corrective et

volutive) ;
la planification des traitements informatiques (batch,

clture, ) ;
lenvironnement technologique de lapplication ;
Vrifier que ladministration est bien assure par les utilisateurs.

1.9. Le propritaire dispose-t-il dun compte-rendu (reporting)
mensuel intelligible de la performance de lapplication, dans le respect
du contrat de service ?
1.10. Existe-il un guide utilisateurs / manuel de procdures, diffus, jour

et matris, comprenant notamment :
mode demploi du manuel, prsentation de lapplication,
mode opratoire, rgles de gestion, crans et zones de saisie,
liste des messages derreurs, tats de contrle et
dexception, documentation des pistes daudit ;
description des contrles programms et des contrles

manuels compensatoires chaque phase du traitement
(mode opratoire, procdure descalade et/ou de recyclage
des anomalies, dlais de mise en uvre, ).
2. Audit de la scurit et de la fiabilit : Analyse des

risques associs l'application
2.1. L'accs aux ressources de l'application (donnes et transactions) estil restreint par un systme de gestion d'accs ?
2.2. Existe-t-il une procdure de gestion des profils utilisateurs de
l'application place sous la responsabilit du propritaire de lapplication
(procdure de cration / modification et suppression des droits daccs) ?
Un dispositif de SSO est-il mis en uvre ?
2.3. Chaque utilisateur possde-t-il un identifiant qui lui est propre ?
Vrifier quil nexiste pas de compte gnrique et que linformatique
(chef de projet) na que des accs en lecture au mme titre que
dventuels sous-traitants et diteurs.
2.4. Le mot de passe associ l'identifiant permet-il d'assurer une
protection d'accs efficace (7 caractres minimum, gestion de lhistorique
des mots de passe sur 2 ans, contrle de trivialit , changement
trimestriel des mots de passe, etc.) ?
2.5. Les tentatives de connexions infructueuses l'application sont-elles
enregistres et contrles par le propritaire de lapplication? Sont-elles
limites ?
60
2.6. L'accs aux donnes et aux transactions de lapplication peut-il tre

correctement paramtr en fonction des tches des utilisateurs ou le
systme de confidentialit est-il bas sur le contrle daccs aux
donnes ?
2.7. La sparation des tches est-elle respecte dans le paramtrage des
profils ?
comparer les droits daccs avec les fonctions des
utilisateurs ;
vrifier ladquation entre les droits et les profils ;
vrifier que toutes les personnes ayant des droits daccs

sont toujours dans le service / lorganisation.
2.8. La piste daudit sur le systme dadministration de lapplication estelle assure et rgulirement contrle ?
2.9. Tous les documents servant de base la saisie sont-ils prpars,
prformats, complets et approuvs avant saisie ?
2.10. Les facilits de saisie, lergonomie de la saisie, les messages crans
et les contrles de format sur les donnes permettent-ils dviter puis de
filtrer les erreurs de premier niveau ? Y-a-t-il unicit de la saisie de
linformation ?
2.11. Les contrles de validation permettent-ils de dtecter les doubles
saisies, les saisies incompltes, les incohrences (contrle de
vraisemblance et de rapprochement avec dautres valeurs, contrle de
limite et dtendue,) et certaines erreurs de saisie (contrle de
sommation, totaux de contrle pour les saisies de masse) ?
2.12. Utilise-t-on des brouillards de saisie pour validation par
rconciliation avec les documents sources ? Cette validation est-elle
indpendante ?
2.13. Les saisies des donnes sensibles et notamment les donnes
permanentes et les paramtres de lapplication sont-elles autorises,
compltes et exactes ?
2.14. Les oprations effectues sur des donnes sensibles sont-elles

lobjet dune piste daudit suffisante et rgulirement analyse ?
identit de lauteur de lopration ;
entit / fichier /donne sur laquelle lopration a t

effectue ;
date et heure des vnements ;

valeur avant et aprs lopration.
Objectifs de contrle de la piste daudit :

valuation de la qualit
exploitabilit, ) ;
des
pistes
(couverture,
valuation de la scurit des pistes (scurit de ses

constituants : OS, SGBD, ...) ;
valuation de la gestion des pistes (procdures de contrle,

archivage, ).
2.15. Les procdures de transmission de fichiers en entre assurent-elles

l'exhaustivit et l'exactitude des informations transmises (contrles
systmes) ?
2.16. Les contrles mis en uvre lors de l'intgration des donnes par
fichiers l'application sont-ils suffisants et identiques ceux mis en
uvre dans le cadre dune saisie transactionnelle (contrles applicatifs) ?
2.17. Le systme prvoit-il de conserver toutes les donnes rejetes dans
un fichier d'anomalies protg et de les diter en vue d'un contrle et
d'un recyclage ?
2.18. Les donnes rejetes sont-elles analyses et corriges dans des
dlais raisonnables et compatibles avec les dlais de validation des
traitements ?
2.19. Les corrections des donnes rejetes subissent-elles les mmes
contrles que les donnes initiales, et jouissent-elles d'une piste d'audit
suffisante ?
61
2.20. Toutes les oprations de mise jour des donnes sensibles sontelles journalises (transactions, traitements batch) ?
2.21. Toutes les oprations de mise jour des donnes sensibles sontelles journalises (transactions, traitements batch) ?
2.21. Rapproche-t-on les totaux de contrle de fin de journe et la
diffrence est-elle analyse au travers des transactions journalises ?
2.22. Des contrles automatiques priodiques, notamment de
vraisemblance, sont-ils effectus afin de vrifier l'intgrit des montants
grs par l'application (niveau applicatif ou base de donnes) ?
2.23. La couverture, le contenu et la distribution des tats de sortie de
l'application sont-ils adapts aux enjeux et lorganisation de
lorganisation ?
2.24. Effectuer une revue dtaille des tats disponibles et de leur
destinataire et vrifier que chaque nouvel tat de sortie fait lobjet dune
procdure de recette.
2.25. Chaque utilisateur dispose-t-il du bon niveau dinformation et de
moyen de contrle adapt ?
2.26. La distribution des tats de sortie est-elle sous contrle (existence
dune procdure permettant lidentification et la validation formelle des
destinataires) et leur niveau de confidentialit assur ?
2.28. Les contrles utilisateurs des tats de sortie font-ils l'objet de
procdures formalises (guide de procdures), connues et appliques ?
2.29. Les procdures de validation des rsultats (Qui, Quand, Comment),
de classement et d'archivage des tats produits sont-elles adaptes,
formalises, connues et appliques ?
existence dune procdure, identification des responsables,
dlai de mise disposition des tats et dlai de validation,
procdures suivre en cas dincident.
2.30. Lorsque l'application est la juxtaposition de plusieurs modules,
l'homognisation des codifications et des rgles de gestion a-t-elle t
assure ?
2.31. L'intgrit et l'exhaustivit des donnes transmises entre les

diffrents modules de l'application et/ou des applications en aval sontelles assures ?
3. Audit de la scurit et de la fiabilit : analyse des

risques associs la fonction informatique
3.1. Au sein du service informatique, les tches relatives au
dveloppement et l'exploitation de l'application sont-elles spares ?
Prendre connaissance de lorganigramme de la DSI, des
descriptions de travaux (Job description) et de la procdure
de mise en production.
3.2. L'accs aux bibliothques de production (donnes et programmes)
est-il interdit aux analystes-programmeurs ?
Sans relle tanchit des environnements de
dveloppement et de production, la sparation des tches
reste toute thorique. Analyser les droits daccs. Un accs
en lecture pour les chefs de projets est gnralement admis.
3.3. La sparation des tches est-elle maintenue et assure en cas
dabsence dun salari (maladie, vacances,..) ?
3.4. L'quipe actuelle en charge de la maintenance (interne ou externe) at-elle une matrise suffisante de lapplication et les moyens de la faire
voluer ?
3.5. Existe-t-il une procdure formalise et standard de maintenance de
lapplication valide par l'informatique et la matrise douvrage
concerne ?
3.6. Les nouvelles versions (dveloppement interne, progiciel) sont-elles
systmatiquement testes puis recettes dans un environnement ddi
avant d'tre livres lexploitation ?
3.7. Existe-t-il une procdure formalise de transfert des programmes
entre les environnements de recette et d'exploitation ?
62
3.8. La documentation de l'application est-elle systmatiquement mise

jour aprs chaque intervention de maintenance ?
3.9. Les corrections effectues en urgence sur les programmes sont-elles
effectues dans un cadre bien dfini et formalis ? Font-elles l'objet d'un
rapport systmatiquement revu par la direction informatique ?
3.10. Un logiciel de contrle de programmes sources et de programmes
excutables est-il utilis pour identifier et tracer toute modification
effectue (piste d'audit) ?
3.11. Les travaux batch de l'application, qu'ils soient priodiques ou la
demande, sont-ils systmatiquement planifis et formellement valids
par le responsable d'exploitation et par le responsable utilisateur ?
3.12. Existe-t-il une procdure de contrle des traitements batch et
d'archivage des comptes-rendus d'excution ?
3.13. La gestion des incidents en gnral et les procdures d'urgence en
particulier sont-elles dfinies et correctement documentes ?
3.14. La documentation d'exploitation est-elle jour, duplique, protge
et inclut-elle les procdures de gestion des incidents et de reprise /
redmarrage ?
3.15. Vrifier lexistence et lapplication dun Contrat de Service (SLA)
pour lapplication :
vrifier que le SLA couvre les besoins de disponibilit,
dintgrit et de confidentialit de lapplication et de ses
donnes ;
valider que les engagements de service sont en adquation

avec lanalyse des risques.
3.16. Vrifier que les moyens organisationnels (ex : escalade, astreintes,

procdures et reporting, ...), humains (effectif, comptences des
personnels), matriels et logiciels (ex: architecture redondante, outil de
mesure, ...) permettent le respect des engagements de service et la
mesure rigoureuse du niveau de service.
3.17. valuer le niveau de service par lanalyse des tableaux de bord.
3.18. Les procdures de sauvegarde et de reprise de lapplication sontelles satisfaisantes et rpondent-elles aux enjeux de lapplication et aux
engagements de service de linformatique ?
3.19. Une partie des sauvegardes est-elle stocke l'extrieur de
l'organisation (banque, socit spcialise) selon une priodicit adapte
aux enjeux ?
3.20. En cas de sinistre grave, existe-t-il un plan de secours en adquation
avec les besoins et les enjeux (plan durgence, plan de repli, plan de
reprise) ?
vrifier le dimensionnement des moyens mis en place ;
dterminer les faiblesses du plan de secours existant (axes

danalyse : tude dimpact financier, sites de repli, plan de
secours informatique, plan de secours tlcom, sauvegardes
des documents, procdures, organisation, logistique).
3.21. Ce plan est-il priodiquement test et mis jour ?

3.22. Lorganisation dispose-t-elle dun responsable scurit et dune
politique formalise en matire de scurit informatique, conforme la
rglementation ? Cette politique couvre-t-elle la fonction informatique ?
3.23. Les accs aux commandes systme, aux bibliothques et bases de
donnes de production sont-ils protgs (logiciel de contrle) et limits
au personnel d'exploitation ?
3.24. Les accs aux logiciels de base et utilitaires sensibles sont-ils
contrls et systmatiquement "tracs" ?
3.25. Existe-t-il des procdures de contrle priodique des accs aux
ressources de l'application (analyse des logs6 par le responsable de la
scurit) ?
Historique dvnement, et par extension fichier contenant cet historique

63
4. Audit d'efficacit et de performance: adquation de

l'application aux besoins
4.1. Le projet sinscrit-il dans le schma-directeur du systme
dinformation et ce dernier est-il align avec le schma directeur de
lorganisation ?
4.2. valuation de lalignement stratgique de lapplication :
vrifier lexistence dune matrise douvrage forte et
implique ;
vrifier que la direction gnrale a particip ltude

pralable et a valid le projet et notamment lanalyse
cots/bnfices ;
direction gnrale.
4.3. Les utilisateurs ont-ils t suffisamment associs la dfinition des
spcifications ou au choix de la solution puis aux volutions successives ?
4.4. Les utilisateurs ralisent-ils toutes leurs tches dans lapplication
(valuation du taux dautomatisation des oprations) ?
4.5. Sinon, maintiennent-ils des systmes parallles (ancien systme,
tableurs) en dehors de lapplication ? Existe-t-il des saisies multiples ?
4.6. Adquation aux besoins des utilisateurs :
la totalit des fonctionnalits de lapplication est-elle utilise
et matrise par les utilisateurs ?
lergonomie de lapplication est-elle satisfaisante ? Par

exemple, la saisie dune transaction rcurrente est-elle
suffisamment productive (nombre dcrans optimis, saisie
assiste, temps de rponse acceptable, ) ?
les rapports issus du systme rpondent-ils convenablement

aux besoins des utilisateurs ? En particulier chaque niveau de
management dispose-t-il de linformation qui lui est
ncessaire (adquation lorganisation) ?
vrifier que le projet sintgre de faon satisfaisante dans le

systme dinformation existant (intgration technique et
fonctionnelle) et que lunicit des rfrentiels de
lorganisation est assure (bases clients, produits, entits,
fournisseurs, rfrentiel comptable, ) ;
le support utilisateur (technique et fonctionnel) est-il

satisfaisant et adapt aux utilisateurs et aux enjeux ?
la documentation utilisateur est-elle adapte, complte,

accessible et permet-elle une utilisation optimale de
lapplication ?
sur la base du bilan de projet (lorsque quil existe), vrifier

que le projet a atteint ses objectifs et couvre tous les aspects
du domaine fonctionnel ; le cas chant, analyser les carts
et vrifier quils ont t ports la connaissance de la
la formation des utilisateurs est-elle suffisante, adapte et

priodique, notamment pour une activit o le turn-over
est important ?
existe-t-il des enqutes priodiques de satisfaction auprs

des utilisateurs ? laide ou non de ces enqutes, valuer le
vrifier que le cahier des charges de lapplication prend en

compte tous les aspects du problme pos et du domaine
fonctionnel considr ; dans le cas contraire, vrifier que le
management avait connaissance de ces lacunes lors de la
validation des spcifications ; vrifier que les choix effectus
ne compromettent pas lintgration des fonctionnalits
complmentaires dans une phase ultrieure ;
64
niveau de satisfaction des utilisateurs (performance de

lapplication, appropriation et matrise, qualit de la
formation et du support, absence de phnomne de
rejet, ...) ?
5. Audit d'efficacit et de performance : analyse de la

performance et de la rentabilit
5.1. Une valuation de la rentabilit de linvestissement a-t-elle t
tablie pralablement au dveloppement ou lacquisition de
lapplication ?
5.2. Cette valuation a-t-elle intgr les cots de dploiement mais aussi
les cots dexploitation/charges rcurrentes ?
5.3. A-t-on tudi srieusement les offres du march (progiciel) avant de
se lancer dans un dveloppement spcifique ?
5.4. Les dlais de mise en uvre de lapplication sont-ils raisonnables
(impact dun ventuel effet tunnel ) et conformes au planning initial ?
5.5. Un bilan post-projet a-t-il t effectu afin de mesurer latteinte des
objectifs ?
5.6. La rduction des charges (notamment de personnel et dexploitation)
et/ou des dlais (dlais de traitements, dlais de clture, ) est-elle
conforme la rduction attendue lors de ltude pralable ?
5.7. A-t-on constat des amliorations non quantifiables, dfinies ou pas
lors de ltude pralable (amlioration de la scurit, du service
client, ...) ?
5.8. A-t-on ralis une ringnierie des processus (Business Process
Reengineering (BPR) ou une tude dorganisation pralablement la
rdaction du cahier des charges ?
5.9. Les processus mtiers sont-ils performants et optimiss (rechercher
toute source damlioration possible) ?
5.10. Les traitements sont-ils performants et les donnes cohrentes et
fiables (voir guide daudit Fiabilit et Scurit dune application ) ?
5.11. Larchitecture technique est-elle adapte et optimise, notamment

les bases de donnes (bon dimensionnement des configurations, gestion
des volutions techniques, personnalisation (tuning) des bases de
donnes, ) ?
5.12. A-t-on mis en place des indicateurs de performance et un contrat de
service adapts aux enjeux entre linformatique et les utilisateurs :
disponibilit de lapplication, le cas chant par plage
horaire ;
temps de rponse, le cas chant par transaction et

traitement sensibles ;
gestion des incidents et du support utilisateurs, fiabilit des

traitements par lots (batch) ;
gestion des demandes de maintenance et gestion des droits

daccs ;
continuit dexploitation et site de back-up.
5.13. Les outils de mesure de la performance et les tableaux de bord sontils adapts aux besoins et aux indicateurs, sans contestation possible ?
6. Audit d'efficacit et de performance : analyse de

l'volutivit/prennit de l'application
6.1. Les technologies utilises sont-elles conformes aux standards de
lorganisation ?
6.2. Le logiciel est-il de conception rcente et fond sur des technologies
portables, non obsoltes et volutives (matriel, OS, SGBD, outils de
dveloppements, ) ?
6.3. Les technologies utilises sont-elles matures et suffisamment
rpandues sur le march (Linux, J2EE, .net,..) ? Les comptences existentelles sur le march notamment dans le contexte dun dploiement
linternational ?
6.4. Les technologies utilises ont-elles suffisamment de marge pour faire
65
face un nombre croissant dutilisateurs et de transactions (cf. Business

Plan) ?
6.5. Lapplication est-elle techniquement et fonctionnellement intgre
dans le SI ?
6.6. Lapplication est-elle modulaire, paramtrable et conceptuellement
adapte aux ventuelles volutions de lactivit, notamment :
capacit dadaptation une internationalisation (multilingue,
multidevise et multiprotocole, ...)?
capacit dintgrer une nouvelle entit juridique, un nouveau

produit, un nouveau mtier, ?
capacit de filialiser un mtier de lOrganisation ou de

dcentraliser certaines activits ?
capacit dun dploiement massif (client lger versus client

lourd, ...) ?
6.13. A-t-on procd des dveloppements spcifiques limits qui ont

respect les points dinterface et les normes prconises par lditeur ?
En particulier, les sources du progiciel, nont-ils pas t modifis ?
6.14. Existe-il un club utilisateurs o lOrganisation est prsente et
influente ?
6.15. A-t-on souscrit un contrat de maintenance avec lditeur ?
6.16. Les redevances de maintenance sont-elles rgulirement payes ?
6.17. Le
contrat
prvoit-il
une
clause
dite
d Escrow
Agreement permettant de disposer des sources, auprs dun tiers de
confiance, en cas de dfaillance de lditeur ?
6.18. Les montes de versions sont-elles rgulirement effectues ?
6.19. Dispose-t-on dun engagement ou dune visibilit suffisante de la
prennit du progiciel (notamment en cas de gel des volutions ou de
ltat technique) ?
6.7. Lapplication volue-t-elle rgulirement par versions successives ?

6.8. Le volume des demandes de maintenance volutive est-il normal
(en fonction de lge de lapplication) et de maintenance corrective
raisonnable (20-25% max de la maintenance dans les 2 premires
annes) ?
6.9. Si lapplication est de conception ancienne, la structure en charge de
la maintenance (interne ou externe) offre-t-elle des garanties suffisantes
de prennit de lapplication (niveau de documentation, taille, anciennet
et comptence des quipes, solidit financire du sous-traitant, ...) ?
6.10. Le niveau de dpendance vis--vis de cette structure est-il
raisonnable ?
6.11. Lditeur a-t-il des rfrences significatives dans le mme secteur
dactivit et dans des organisations de taille et de complexit
quivalente ?
6.12. La version du progiciel installe dans lorganisation est-elle mature
et utilise dans un nombre significatif dorganisations ?
66
3.5.
AUDIT DU SUPPORT UTILISATEURS ET DE
LA GESTION DU PARC
La mission de la fonction support est oriente autour de deux axes :
fournir lassistance et le support aux utilisateurs des
systmes dinformation et amliorer en permanence leur
niveau de satisfaction ;
amliorer la performance globale des systmes.
La performance dun centre dassistance (help-desk) ainsi que ses

rpercussions sur la productivit des utilisateurs doivent tre valus. Elle
doit permettre d'identifier les domaines sur lesquels il semble possible
d'accrotre la productivit des utilisateurs, notamment les besoins en
formation.
Il est ncessaire que la fonction de support dune part anticipe ses besoins
et dimensionne convenablement ses quipes et, dautre part, contribue
la mise en place de rgles de gestion du matriel et des applications
informatiques de lorganisation en analysant le retour dexprience.
complmentaires.
Points de contrle
1. Fonction support : audit fiabilit et scurit
1.1. Quelle structure de centre dassistance (help-desk) (HD) est mise en
place ?
1.2. Existe-t-il une procdure de gestion des demandes, diffuse et
connue des utilisateurs ?
1.3. Quelle est la procdure d'escalade mise en place ?
1.4. Quelle est la couverture gographique du HD ?
1.5. Quelle est la couverture fonctionnelle du HD ?
1.6. Un outil est-il implment pour la prise d'appel et le suivi des tickets ?
1.7. Quelles sont les critres renseigner pour la qualification des
tickets ?
1.8. Existe-t-il une liste de questions drouler lors d'un appel afin
d'identifier au mieux la demande de l'utilisateur ?
1.9. Les problmes sont-ils grs ? Si oui quel est le processus ?
1.10. Les incidents de production de nuit sont-ils saisis aussi dans l'outil ?
1.11. Quels sont les comits mis en place pour suivre les incidents et leur
rsolution ? Qui participe ? Comment sont suivies les actions ?
1.12. Si le HD est externalis, existe-t-il un contrat de service ?
1.13. Quels sont les indicateurs pour suivre le contrat de service ?
1.14. Y-a-t-il un planning systmatique concernant les mises en
production ?
1.15. Interroger le DSI, le responsable HD, des utilisateurs, l'quipe HD si
possible, participer la vie du HD .
1.16. Demander des extractions de la base de ticket :
vrifier le nombre, la compltude des critres, l'adquation
de la qualification, la description de l'incident ;
67
analyser les dlais de clture ;

analyser la criticit moyenne des tickets.
1.17. Demander les reporting de suivi.
2. Fonction support : audit d'efficacit et de performance

2.1. Existe-t-il une aide la saisie pour la saisie des tickets ?
2.2. Existe-t-il des revues qualit pour la saisie des tickets ?
2.3. Quelle est la procdure de mise jour de la base de connaissance ?
2.4. Les appels sont-ils enregistrs ?
2.5. Des tudes de satisfaction sont-elles ralises auprs des utilisateurs
?
2.6. Existe-t-il une valuation de lquipe HD ? Notamment pour les
prestataires pour valuer leur niveau de connaissance ?
2.7. Les certifications (ITIL, ISO, COBIT) sont-elles encourages au sein de
la DSI, du HD en particulier ?
2.8. Interroger le DSI, le responsable HD, des utilisateurs, l'quipe HD si
possible, participer la vie du HD .
2.9. Demander la stratgie de formation des utilisateurs et de lquipe
Help-Desk.
2.10. Demander les reportings de suivi.
2.11. Demander les tudes de satisfaction.
3. Gestion du parc matriel et logiciel : audit fiabilit et

scurit
3.1. Quelle est la procdure de dploiement des mises jour, dun
nouveau logiciel ?
3.2. Quels sont les outils mis en place pour grer les versions des
logiciels ?
3.3. Quels sont les outils mis en place pour grer le matriel
informatique ?
3.4. L'installation des PC / portables est-elle faite partir d'un master

(configuration minimum et standardise) ?
3.5. Existe-t-il un processus spcifique pour le suivi des mises jour sur les
portables ?
3.6. Le dploiement de nouveaux logiciels ou mises jour est-il possible
distance ? (utile pour les utilisateurs nomades).
3.7. Est-il possible pour le HD de prendre la main distance ? Si oui, quelle
est la procdure ?
3.8. Comment est gr le parc informatique ? Quel type de machine ?
Quel outil ?
3.9. L'inventaire du parc informatique comprend-t-il la localisation des
machines ?
3.10. Les logiciels "non officiels" sont-ils rpertoris et suivis ?
3.11. Les utilisateurs sont-ils sensibiliss la scurit informatique,
notamment l'installation de logiciel "non officiel" ?
3.12. Faire des copies dcran ou dextraction des outils de suivi des mises
jour/dploiement.
Vrifier sur les postes utilisateurs les versions antivirus, firewall, version
Windows, version IE.
4. Gestion du parc matriel et logiciel : audit d'efficacit

et de performance
4.1. Comment est effectu l'inventaire des licences (logiciel, version, date
de mise en production, nombre d'utilisateurs) ?
4.2. Outils de type SAM (Software Asset Management) sont-ils dploys ?
4.3. Existe-t-il des revues rgulires des licences ?
4.4. Existe-t-il une base de donnes de gestion de configuration de type
CMDB (Configuration Management DataBase) ?
4.5. La DSI est-elle sensibilise aux enjeux de la matrise des licences ?
(notamment en cas de contrle) ?
4.6. Des audits sont-ils raliss ?
4.7. Une politique logicielle existe-t-elle ?
68
3.6.
AUDIT DE LA FONCTION TUDE
Les tudes sont une fonction sensible de la DSI, en charge du

dveloppement et de la maintenance des applications informatiques. La
fonction tude est en charge de la conception et de la ralisation des
applications, de leur test, de leur mise en uvre (avec la production) et
de leur maintenance (corrective, rglementaire et volutive).
Son audit consiste analyser sa capacit assurer la maintenance du
patrimoine applicatif existant, conduire ou accompagner les volutions
venir du systme dinformation conformment au plan ou au schma
directeur informatique. Il faut veiller ne pas confondre audit des tudes
avec audit de projet. Laudit dun projet sadresse une organisation
temporaire et sur mesure, tandis que laudit des tudes sadresse une
structure permanente de lOrganisation.
complmentaires.
Points de contrle
1. Activit de pilotage
1.1. La ligne de partage entre tudes et production est-elle clairement
dfinie et documente ?
1.2. Existe-t-il une cellule ddie en charge du suivi et du contrle des
projets et des ressources (gestion des plannings et des budgets, suivi des
temps et des cots) ?
1.3. Vrifier lexistence dune procdure de planification dtaille par
projet et/ou par ressource (en fonction des besoins et des enjeux : taille
des quipes, nombre et nature des projets) :
vrifier lexistence et lutilisation dun outil de gestion de
projet (PMW, Primavera, MS-Project) ;
vrifier lexistence dune mthode dvaluation des charges ;
vrifier ladquation des outils et procdures aux besoins et

enjeux ;
vrifier que la planification offre une visibilit suffisante de la

charge des tudes (12 mois) ;
vrifier que pour les nouveaux projets, la planification couvre

lensemble du projet, cest--dire que lon se place dans une
logique projet et non dans une simple logique doccupation
des ressources (gestion du chemin critique, engagement sur
une date butoir deadline , ...).
69
1.4. Vrifier que la procdure de planification est nominative et

suffisamment dtaille pour permettre une bonne visibilit du taux
prvisionnel doccupation des ressources :
vrifier que les projets/travaux sont dcoups en tches
lmentaires grables ;
vrifier la cohrence transversale de la planification en

fonction des ressources disponibles et sassurer que la
planification prend en compte les congs et la formation
(utilisation moyenne des ressources de lordre de 190-200
j/an) ;
vrifier tout particulirement lexistence de marges de
scurit sur le chemin critique.
1.5. Vrifier lexistence dune procdure priodique (hebdomadaire

mensuelle en fonction des enjeux), de suivi de lactivit et de mise jour
du planning, articule autour de :
lutilisation de time sheet nominatif (relev dactivit) ;
1.6. Vrifier lexistence dun tableau de bord mensuel de lactivit des

tudes offrant une bonne visibilit de lactivit actuelle et venir des
tudes :
situation du portefeuille des demandes de maintenance et

valuation de la charge globale prvisionnelle permettant
danticiper les besoins de sous-traitance ;
tats davancement des projets, nouveaux plannings et

analyse des risques ;
suivi budgtaire (mois et anne glissante (ytd)) couvrant les

ressources internes et la sous-traitance ;
taux doccupation des ressources, absentisme, volution de

la productivit, ;
suivi de lvolution des carts de charges de dveloppement

estimes / constates et suivi des engagements de mise
en production (dates), ...
la saisie des temps passs et du taux de ralisation par

tche afin didentifier le reste faire et danticiper toute
drive des projets (suivi du chemin critique) ;
1.8. Ce tableau de bord est-il communiqu et analys par le Comit

informatique ?
une procdure dalerte en cas de drapage du projet pour

prise de dcision (augmentation des dlais ou affectation de
ressources additionnelles ) ;
la diffusion de ltat davancement des travaux et du

nouveau planning des tudes.
2.1. Valider lexistence dune MOA forte et dune fonction tudes

limite la MOE :
- le rle et les responsabilits des tudes sont-ils dfinis dans la charte
informatique ou dans les plans dassurance qualit des projets ;
- existe-t-il des contrats de service entre les tudes et les utilisateurs ?
2.2. valuer le rle du Comit Informatique dans le contrle de lactivit
des tudes :
- gestion des priorits de dveloppement et arbitrages entre directions ;
- suivi des projets et de ltat davancement des travaux, suivi de la
performance.
1.6. Pour les travaux de maintenance, la charge de ralisation (en

jours/homme) est-elle systmatiquement rapproche de lestimation
initiale afin dune part, daffiner les mthodes dvaluation des demandes
et, dautre part, de mesurer la productivit relative des dveloppeurs ?
2. Activits oprationnelles
70
2.3. valuer la qualit du contre poids de la production et de

lquilibre entre ces deux fonctions de la DSI :
cet quilibre passe-t-il par une relle sparation des tches
et ltanchit des environnements, rendant la production
incontournable pour les mises en production ?
2.6. Existe-t-il une procdure standard et formalise de maintenance,

base sur :
un formulaire de demande de maintenance dment
complt (besoins, priorits, ...), valid par le propritaire
de lapplication et centralis par les tudes ?
2.4 Vrifier que l'quipe actuelle en charge de la maintenance (interne ou

externe) a la matrise suffisante des applications et les moyens de la
faire voluer :
comptences techniques adaptes (analyser les curriculum

vitae et les profils en fonction des technologies utilises,
vrifier la prsence des concepteurs, ...) ;
effectifs suffisants et motivs (analyser lhistorique de la DSI,
les rmunrations, le turn-over , analyser le portefeuille
des demandes de maintenance, ...) ;
existence des sources et des compilateurs et de la

documentation des applications ;
valuer le risque dune ventuelle dpendance vis--vis

dune ou plusieurs personnes.
2.5. Revoir les budgets formation/recrutement et leur adquation avec les

technologies actuelles et celles induites par le droulement du plan
informatique. Les profils et comptences existants, les budgets de
formation et les prvisions de recrutement sont-ils adapts aux enjeux et
lvolution des nouvelles technologies ?
une estimation des charges, une consolidation des demandes

puis une procdure formelle de validation des priorits
(implication ventuelle du comit informatique) ?
un retour vers lutilisateur des demandes valorises (temps,

cots) avec une date prvisionnelle de mise en uvre ?
une affectation
demandes ?
et
une
planification
dtailles
des
2.7. Pour la maintenance volutive, le versionning7 (2 3 par an) est-il

prfr la maintenance au fil de leau ? Approche plus efficace et
risque de rgression rduit.
2.8. Les nouveaux programmes/versions sont-ils systmatiquement tests
puis recetts dans un environnement ddi avant d'tre livrs
lexploitation ?
2.9. Vrifier lexistence dun bon niveau de sparation des tches et des
environnements entre les tudes et la production :
vrifier lexistence de job description et le niveau de
sparation des tches ;
vrifier que les tudes disposent de machines de

dveloppement et de test, ddies et scurises dont les
caractristiques et tats techniques sont similaires celles
des machines de production ;
Regroupement dune srie dvolutions mineures, permettant dviter des

modifications trop frquentes dune application.
71
vrifier lexistence dune procdure de recette entre les

tudes et lexploitation ;
vrifier lexistence et la qualit de la procdure de transfert

des programmes entre les environnements de
dveloppement et d'exploitation ;
vrifier que le niveau de sparation des tches nest pas

dgrad en cas dabsence de membres des tudes et/ou de
production (profil administrateur, mot de passe, ).
2.10. La documentation de l'application est-elle systmatiquement mise

jour aprs chaque intervention de maintenance ? Vrifier dans les
programmes lexistence dhistorique des modifications sous forme en
commentaires.
2.11. Les corrections urgentes (bug bloquant de gravit 1) sont-elles
traces (logs) et effectues dans un cadre bien dfini et font-elles l'objet
d'un rapport systmatique revu par la DSI (responsable des tudes,
production, assurance qualit, ) ?
2.12. Pour les environnements obsoltes, sassurer que les langages et
compilateurs sont toujours oprationnels et maintenus (assembleurs,
cobol, ).
2.13. Pour une application donne, rechercher de faon exhaustive les
ventuels programmes objets sans programmes sources correspondant.
3.3. Utilise-t-on un logiciel de gestion de version de programmes afin

didentifier et de tracer toute modification de programme et un outil de
gestion des configurations logicielles afin den matriser les volutions
(Rational Clearcase, ) ?
3.4. Utilise-t-on une dmarche standardise dassurance qualit couvrant
les aspects suivants : organisation, mthodes, outils et procdures de
dveloppement, gestion des livrables, plannings des projets, procdures
de suivi et de reporting, documentation ?
3.5. Existe-t-il une documentation tudes structure, claire, tenue
jour comportant un index de la documentation, une cartographie
gnrale et dtaille des applications, des spcifications dtailles par
application, des dossiers darchitecture technique par application (MCD,
tableaux croiss donnes/programmes, traitements de contrle des
interfaces) ?
3.6. Existe-t-il une documentation utilisateurs par application (incluse
dans la recette) comportant notamment le manuel dutilisation, la
description des donnes saisies et mises jour, les tats de contrle
disponibles, les contrles automatiques effectus, ...
3.7. En cas dutilisation de progiciels, vrifier lexistence des programmes
sources.
Si lorganisation ne dispose pas des sources, vrifier lexistence
contractuelle dun Escrow agreement .
3. Activits oprationnelles : le dveloppement des

spcifiques
3.1. Utilise-t-on des mthodes et outils de conception et de modlisation
dapplication ? (UML, Rational Case, ...). Ces outils et mthodes sont-ils
adapts, matriss et partags par lensemble des quipes concernes, la
formation est-elle adapte ?
3.2. Existe-t-il des normes de programmation et de codification dont les
rgles sont formalises dans un manuel l'attention des programmeurs ?
Vrifier lapplication de ces normes (revue de code).
72
3.7.
Points de contrle
AUDIT DES PROJETS

complmentaires.
3.7.1.
OBJECTIFS ET ENJEUX DU PROJET
Un projet est un ensemble de tches interdpendantes concourant la

ralisation dun objectif prdfini et mesurable, avec des spcifications,
des contraintes, des moyens humains, financiers et matriels, des dlais
(un dbut, une fin) et des risques.
Un projet informatique produit gnralement de nouvelles applications
et/ou maintien des applications existantes. Il peut aussi sagir dun
renouvellement matriel majeur.
La conduite de projet est un ensemble de processus permettant de
matriser la ralisation dun projet et de la mener terme.
Cette matrise passe par un dcoupage du projet en processus, tapes,
phases, activits et tches. Il est indispensable davoir une dfinition claire
des entres des processus, des phases et tapes, des productions
attendues et des conditions de passage dune phase lautre. Le rle et
les responsabilits des acteurs doivent tre clairement dfinis.
1. Objectifs et enjeux du projet

1.1 Une tude de la valeur (ex : MAREVA 2) et des tudes d'opportunit et
d'impacts ont t ralises.
1.2 Un bilan critique des processus existants a t effectu.
1.3 Le choix de recourir un nouveau systme est obtenu aprs
optimisation des processus concerns et vrification que cette
optimisation ne suffit pas apporter par elle-mme les gains de
performance attendus.
1.4 Les objectifs et primtres du projet sont dfinis, partags et
stabiliss.
1.5 Les principales orientations du systme cible ont t explicites.
1.6 Les principaux acteurs sont identifis.
1.7 Les cots sont valus.
1.8 Les liens et impacts avec des projets connexes et les infrastructures
(Datacenter, rseaux, etc.) sont pris en compte.
Documents rcuprer
tude de la valeur et d'opportunit ;
liste des processus impacts ;
manuel utilisateur ;
manuel d'exploitation ;
dossier d'organisation de la reprise des donnes ;
bilan de qualit logiciel ;
bilan de la satisfaction des utilisateurs.
73
3.7.2.
TUDE DOPPORTUNITE ET EXPRESSION
DES BESOINS
Ltude dopportunit et lexpression des besoins sont les deux premires

phases dun projet. Elles font merger les motivations et les raisons de la
mise en uvre du projet. Ltude dopportunit est gnralement suivie
dune tude dimpacts.
Il sagit danalyser les dysfonctionnements du systme actuel pour, au
final, disposer dune description unique et partage par tous, de la
description de lensemble des besoins satisfaire (volutions de lexistant
ou nouveaux besoins). Les diffrents scnarios de solution ainsi que des
fourchettes de cots associs doivent tre labors.
Points de contrle
2. tude d'opportunit et expression des besoins
2.1 L'expression dtaille des besoins est formalise dans un cahier des
charges fait par la MOA.
2.2 Le cahier des charges prconise une solution fonctionnellement et
techniquement pertinente au regard des besoins exprims.
2.3 Les exigences utilisateurs, les populations cibles, les options et
principes de gestion retenus sont prciss et prioriss.
2.4 Le projet est cohrent avec le plan directeur informatique.
2.5 Le projet est cohrent avec le SI actuel ou futur.
2.6 La direction est bien implique dans le projet.
2.7 Les acteurs de l'quipe projet et leurs responsabilits sont bien
identifis.
2.8 Les comptences du personnel sont en adquation avec les tches.
2.9 Une tude d'opportunit est valide.
2.10 Ce document comprend les objectifs du projet.
2.11 Ce document comprend l'analyse des dficiences des systmes
existants.
2.12 Ce document comprend les enjeux et la faisabilit du projet.
2.13 Ce document comprend les bnfices attendus et la rentabilit
conomique du projet.
2.14 Ce document comprend les contraintes relatives au projet.
2.15 Ce document comprend la liste des acteurs concerns.
2.16 L'tude d'opportunit a t revue par les directions utilisatrices et
par la direction informatique.
2.17 L'approbation de l'tude d'opportunit a t formalise par crit par
une personne ayant autorit pour le faire.
74
Points de contrle
3.7.3.
PLANIFICATION
Lorganisation doit tre en mesure dvaluer, dorganiser et de planifier la

ralisation des travaux venir. La mutualisation des ressources, tant au
sein de la DSI que pour les entits mtiers, est devenue une ncessit.
Il est ncessaire de contrler si lorganisation est en mesure de planifier
de manire cohrente lutilisation de ses ressources.
3. Planification
3.1 Il existe un planning directeur commun tout le projet.
3.2 Il existe un plan de projet initial.
3.3 Ce plan de projet a t rvis.
3.4 Il existe des plans dtaills.
3.5 Ces plans ont t rviss.
3.6 Les plans intgrent une gestion optimale des ressources.
3.7 Il existe une valuation des risques lis la nature du projet.
3.8 Il existe une valuation des risques lis la technologie utilise.
3.9 Il existe une valuation des risques lis aux projets en cours.
3.10 Il existe une valuation des risques lis aux dlais.
3.11 Il existe une valuation des risques lis la synchronisation des
activits.
3.12 Les acteurs se sont engags respecter le planning gnral du projet.
3.13 Les lots sont bien identifis et suivis dans le planning.
3.14 La notion de reste faire est bien comprise par tous les acteurs.
3.15 Une estimation priodique du reste faire est effectue.
3.16 Il existe des "capteurs" d'alerte.
3.17 Il existe des procdures pour traiter les alertes urgentes.
3.18 Un mthode d'estimation des charges est applique.
3.19 Cette mthode est cohrente.
3.20 La mise en adquation des moyens humains est cohrente.
3.21 La mise en adquation des moyens techniques est cohrente.
Documents rcuprer
macro planning du projet ;
plan de projet dtaill ;

documents de suivi des risques.
75
3.7.4.
INSTANCES DE PILOTAGE
Diffrentes instances de pilotage sont mises en place pour accompagner

un projet. Le choix des indicateurs et le formalisme du reporting jouent un
rle important lors des prises de dcision. Les comits de suivi de projet
sont gnralement au nombre de trois comits :
Comit de pilotage (parfois appel comit directeur) :

Instance de dcision et de pilotage stratgique du projet
(lancement, suivi du dveloppement de la solution,
conduite du changement et mise en uvre, management
du projet, arbitrage, allocation de ressources) ;
Comit de projet (parfois appel comit de pilotage) :

Instance de pilotage oprationnel du projet agissant pour
le compte du comit de pilotage, comprenant des
reprsentants de la matrise d'uvre (y compris
prestataires) ;
Comit des utilisateurs :

instance charge de l'expression dtaille des besoins et
des rgles de gestion ;
de la validation des dossiers de conception prsents par

l'quipe projet ;
de la participation aux tests du systme, l'laboration de

la documentation utilisateurs , aux actions de
formation ;
de la rception dfinitive du logiciel.
Points de contrle
4. Les instances de pilotage
4.1 La structure de pilotage est formalise et connue de tous les acteurs.
4.2 Les diffrentes instances de pilotage connaissent leurs niveaux de
dlgation.
4.3 Les objectifs des dlgations sont atteints.
4.4 Il existe un comit de pilotage.
4.5 Il existe un comit de projet.
4.6 Il existe un comit des utilisateurs ou, a minima, une participation des
utilisateurs.
4.7 Les participants aux diffrents comits sont reprsentatifs et ont le
bon niveau de dcision.
4.8 Les participants ne sont pas trop nombreux.
4.9 Les gestionnaires de la production sont intgrs dans les structures de
pilotage.
4.10 La frquence des comits est approprie.
4.11 Il existe une runion priodique de revue du projet pour suivre son
avancement.
4.12 La traabilit des volutions de primtre, cot et dlai est assure.
4.13 Il existe des indicateurs de suivi du projet.
4.14 Les indicateurs sont adapts l'tape en cours.
4.15 Les indicateurs sont mis jour.
4.16 Les indicateurs sont pertinents par rapport aux objectifs du projet
(contraintes de dlais, de qualit, de cot, ).
4.17 Il existe un formalisme de reporting (tableau de bord par exemple).
4.18 La frquence du reporting est correcte.
Documents rcuprer
liste des instances de pilotage ;

76
liste des participants avec leurs fonctions ;
comptes-rendus des derniers COPIL / COPROJ ;

tableaux de bord ou indicateurs du projet.
77
3.7.5.
METHODES ET OUTILS
Points de contrle
5. Mthodes et outils
Lutilisation dune mthode prcise, connue et partage impose un

dcoupage du processus de dveloppement en sous-ensembles
matrisables, identifie les tches et produits associs ainsi que les points
de contrle et, enfin, fournit un vocabulaire commun pour lensemble des
parties prenantes.
Lauditeur doit veiller lutilisation par lquipe projet dun cadre de
rfrence mthodologique. Les principales difficults rencontres sont le
manque dhomognit des livrables, la difficult dutilisation de la
mthode et lincompatibilit des outils en place avec la mthode.
5.1 Il existe une mthode de conduite de projet et celle-ci est applique.

5.2 La mthode repose sur un dcoupage des projets en tches.
5.3 La mthode repose sur une attribution formelle des responsabilits
par tche.
5.4 La mthode repose sur une identification prcise des points de
contrle et des livrables.
5.5 La mthode repose sur un reporting des temps travers une feuille de
temps.
5.6 La mthode repose sur un outil de planification.
5.7 La mthode repose sur des outils.
5.8 Les outils de suivi des dlais et des cots sont adapts.
5.9 La plan gnral du projet est suffisamment prcis.
5.10 Les tches identifies constituent des units grables.
5.11 Les membres de l'quipe projet ont t forms la mthode et aux
outils.
Documents rcuprer
manuel de la mthode applique ;
liste des outils utiliss.
78
3.7.6.
PLAN ASSURANCE QUALITE
Le plan assurance qualit (PAQ) est un document dcrivant les

dispositions spcifiques prises en matire dassurance de la qualit par un
organisme pour rpondre aux exigences relatives un produit et/ou
service particulier.
Points de contrle
6. Qualit
6.1 Il existe un dispositif d'assurance qualit document.
6.2 Il existe un manuel d'assurance qualit de l'entit.
6.3 Il existe un plan d'assurance qualit du projet.
6.4 Les objectifs qualit du produit sont formaliss.
6.5 Les objectifs qualit du service attendu sont formaliss.
6.6 Le groupe assurance qualit est indpendant des quipes de
dveloppement du projet.
6.7 Une procdure de suivi des revues d'assurance qualit est formalise.
6.8 Les conclusions des revues d'assurance qualit sont prises en compte
par l'quipe projet.
6.9 Il existe un circuit d'approbation des livrables.
6.10 Ce circuit d'approbation est pertinent.
6.11 Il existe un audit de la qualit du projet par une personne extrieure.
Documents rcuprer
manuel dassurance qualit ;
plan dassurance qualit ;
procdure de suivi des revues qualit.
79
3.7.7.
CONCEPTION GENERALE ET ANALYSE
Le dossier de conception gnrale informatique dfinit les scnarios

dvolution du systme dinformation avec :
une description gnrale de la solution conceptuelle des
flux/traitement et des donnes ;
une description gnrale de la solution organisationnelle ;
une description gnrale de larchitecture technique de la

solution (centralis, dcentralis, ) ;
et une orientation gnrale des actions de conduite du

changement et de mise en uvre.
Il fournit les lments ncessaires la prise de dcision en termes

darchitecture, de lotissement, de cots, de risques et de dlais.
7.4 Une analyse conomique (bnfices attendus, cots de

dveloppement, de formation, de maintenance, ) a t intgre au
choix de la solution.
7.5 Une analyse des risques a t mise en place pour chaque alternative.
7.6 Le choix de la solution a t fait en toute objectivit en se basant sur
des critres d'valuation pertinents.
7.7 Les aspects de contrle interne et de scurit ont t pris en compte
dans le cahier des charges.
7.8 Les contrles d'exploitation ont t identifis.
7.9 La conception gnrale du futur systme s'inscrit dans les objectifs
gnraux de contrle en vigueur, dans l'environnement.
7.10 Les besoins spcifiques en matire de contrles ont t pris en
considration.
7.11 Les besoins en matire de contrles programms ont t identifis et
dcrits.
7.12 Les tudes de faisabilit ont t revues par les membres du comit
adquat.
7.13 Les diffrentes solutions possibles ont t prsentes au comit
adquat.
7.14 La poursuite du projet a t approuve par crit par une personne
comptente.
Points de contrle
7. Conception gnrale et analyse
7.1 Il existe une analyse des diffrents scnarios possibles en termes de
solution retenue.
7.2 Tous les scnarios ont t envisags, mme celui de ne rien faire.
7.3 Les contraintes lies aux technologies (besoins en matriels, en
formation, en RH, contraintes juridiques, faisabilit oprationnelle, ) ont
t prises en compte.
Documents rcuprer
comparaison des diffrentes solutions ;

liste des contrles d'exploitation.
80
3.7.8.
CONCEPTION DETAILLEE
Points de contrle
8. Conception dtaille
La phase de conception dtaille est ponctue par un dossier de

conception dtaille informatique. Ce dossier spcifie de faon dtaille
(architecture et modles informatiques) les composants logiciels mettre
en uvre ainsi que les interfaces, selon le scnario, les modalits et la
route de dveloppement retenus.
8.1 Il existe une mthode d'analyse et de conception.

8.2 Cette mthode est correctement utilise.
8.3 Cette mthode est matrise par l'quipe projet.
8.4 Les spcifications dtailles sont exhaustives par rapport au cahier des
charges.
8.5 Il existe des contrles adapts chaque point critique du systme
(prventifs et correctifs).
8.6 Le responsable de la scurit est impliqu dans le projet.
8.7 Il existe des pistes d'audit permettant de suivre la totalit des
transactions.
8.8 Les acteurs concerns sont impliqus dans le projet (utilisateurs,
administrateurs de donnes, responsable scurit, ).
8.9 La conception dtaille a t revue par les membres du COPROJ.
8.10 La poursuite du projet a t approuve par crit par une personne
comptente.
Documents rcuprer
dossier de spcifications dtailles (ou de conception dtaille) ;

81
3.7.9.
DEVELOPPEMENT , REALISATION OU
PARAMETRAGE
La phase de ralisation consiste produire un ensemble de codes

excutables (programmes) structur et document correspondant aux
spcifications et respectant les dispositions du plan dassurance qualit
partir du dossier de spcifications dtailles et des normes et standards
de production du logiciel.
Cette phase inclut le dveloppement des interfaces internes et externes,
la spcification des tests et llaboration des scnarios de reprise des
donnes.
On distingue deux cas de figure lors de la phase de ralisation : soit il
existe dj sur le march une solution rpondant au besoin (progiciel)
quil faut alors paramtrer, soit il faut dvelopper une solution sur
mesure. Paramtrer consiste adapter un progiciel au contexte
organisationnel et technique cible pour rpondre aux besoins exprims
par les utilisateurs.
9.7 La documentation est revue par le responsable du service des tudes.

9.8 Il existe un programme gnral de tests formalis.
9.9 Il existe un plan de mise en place.
9.10 Le plan de mise en place dfinit la nature des travaux raliser et
leur ordonnancement.
9.11 Le plan de mise en place dfinit les charges de travail
correspondantes et la dure de travaux.
9.12 Le plan de mise en place dfinit les acteurs concerns.
9.13 Le plan de mise en place dfinit les rles et les responsabilits des
acteurs.
9.14 Le plan de mise en place est approuv et diffus.
9.15 Il existe un plan de migration.
9.16 Les normes de dveloppement et de vrification du programme de
conversion sont respectes.
9.17 Les procdures de contrle en matire de passage en production
sont respectes.
9.18 Il existe une image des systmes et des donnes avant et aprs
conversion.
9.19 Les rsultats du processus de conversion sont approuvs par crit
par les directions concernes.
9.20 Il existe un dossier de spcification de paramtrage.
9.21 Ce dossier consigne les options retenues sur le produit.
Points de contrle
9. Dveloppement, ralisation ou paramtrage
9.1 Il existe une mthode de dveloppement.
9.2 Cette mthode est correctement utilise.
9.3 Cette mthode est parfaitement matrise par les dveloppeurs.
9.4 Il existe des normes de documentation.
9.5 Ces normes sont appliques par les dveloppeurs.
9.6 Les dveloppements sont bien documents.
Documents rcuprer
programme gnral de tests ;
plan de mise en place des tests ;
plan de migration/reprise des donnes ;
dossier de spcification de paramtrage.
82
3.7.10.
QUALIFICATION : TEST/RECETTE
Toute application informatique doit tre teste avant de passer en

production, dans un premier temps par la matrise duvre, puis par la
matrise douvrage (test utilisateur).
Une procdure formalise encadre lacceptation ou le rejet dune
livraison.
Un procs-verbal doit systmatiquement tre dress en fin de recette
(priode de test).
La qualit de la reprise des donnes peut tre incluse dans cette phase de
test.
Points de contrle
10. Tests et recettes
10.1 La MOE ralise des tests.
10.2 La MOE s'assure que chacun des composants de l'application
fonctionne tel qu'il a t dcrit dans le dossier de spcifications.
10.3 La MOE ralise des tests sur l'ensemble des composants de
l'application sur le plan fonctionnel et technique.
10.4 La MOE ralise des tests sur les interfaces de l'application dans le SI.
10.5 Des tests utilisateurs sont raliss.
10.6 Les tests portent sur l'adquation de l'application livre par la MOE
avec les besoins exprims par la MOA.
10.7 Les tests portent sur l'acceptation technique du systme (ergonomie,
performance, qualit des entres/sorties,).
10.8 Il existe des tests de pr-exploitation.

10.9 Ces tests s'assurent de la bonne intgration de l'application dans
l'environnement de production.
10.10 L'application est recette.
10.11 L'application s'intgre bien dans l'ensemble du SI.
10.12 Il existe une procdure formalise de recette finale destine
accepter formellement l'application.
10.13 Tous les acteurs concerns participent activement la phase de
recette.
10.14 Les personnes impliques dans la recette ont une matrise
suffisante du systme.
10.15 Les jeux d'essais sont pertinents et assurent l'tendue des tests.
10.16 Les rsultats des jeux d'essais et de la recette finale sont formaliss
par la direction du dpartement utilisateur.
10.17 Il existe un dossier d'organisation de la reprise des donnes.
10.18 Le niveau de qualit des donnes d'origine est bien matris.
10.19 Il existe des contrles automatiques de la qualit des donnes
obtenues aprs reprise (exhaustivit et exactitude).
10.20 Les utilisateurs devant participer la reprise des donnes ont t
mobiliss le plus tt possible.
10.21 Il existe un bilan de qualit du logiciel.
10.22 Le bilan de qualit prend comme rfrence les exigences qualit
fixes par la MOA et traduites par la MOE en objectifs et critres
respecter.
10.23 Le logiciel est conforme aux besoins fonctionnels exprims par le
cahier des charges.
10.24 Le logiciel est conforme au niveau de performance attendu.
10.25 Le logiciel est conforme au niveau de scurit attendu.
10.26 Le logiciel est conforme au niveau de convivialit attendu.
10.27 L'apprciation du logiciel est exprime par les utilisateurs travers
un questionnaire.
83
Documents rcuprer
plan de tests ;
comptes-rendus des tests ;
plan de recettes ;
comptes-rendus des recettes ;
84
3.7.11.
CONDUITE DU CHANGEMENT ET MISE EN
UVRE
Enjeu capital dans la russite ou lchec dun projet, le changement vcu
par les organisations lors dune volution du systme dinformation doit
tre matris et gr comme un processus part entire.
Il sagit de lensemble de moyens, ressources, mthodes pour transfrer
la connaissance de lapplication de lquipe projet vers les utilisateurs et
les exploitants de lapplication.
Ce processus doit aboutir une relle appropriation du nouveau systme
dinformation par tous les utilisateurs ds la phase de dmarrage. La
dmarche de conduite du changement/mise en uvre est habituellement
structure en 6 phases :
identification et valuation des changements ;
plan de communication ;
plan de formation ;
laboration dfinitive de la documentation ;
organisation du soutien ;
dans les cas simples, la reprise des donnes peut tre incluse dans
cette phase.
Points de contrle
11. Conduite du changement et mise en uvre
11.1 Il existe une synthse de l'valuation des changements.
11.2 L'valuation des changements a t valide.
11.3 Les entretiens raliss sont reprsentatifs.
11.4 Les utilisateurs participent l'valuation des changements.
11.5 Il existe un plan de communication complet.
11.6 Les messages sont clairs et simples.
11.7 La communication volue et progresse par rapport au
dveloppement du projet.
11.8 La communication est fortement soutenue par la MOA.
11.9 Il existe un plan de formation.
11.10 La hirarchie des personnes former est implique.
11.11 Les profils types des personnes former sont identifis.
11.12 La population former est pertinente.
11.13 Les objectifs de chaque formation sont identifis et affichs.
11.14 Les sessions de formations sont values et repenses selon
l'valuation.
11.15 Le planning de formation est cohrent avec le planning du projet.
11.16 La dure du programme de formation est pertinente.
11.17 Les formateurs et le contenu de la formation sont de qualit.
11.18 Il existe une procdure d'valuation des forms et des formateurs.
11.19 Une organisation de soutien aux utilisateurs a t mise en place
dans la phase d'exploitation du nouveau systme.
11.20 Son organisation gnrale est bien anticipe.
11.21 Les diffrents niveaux de soutien sont coordonns et cohrents.
11.22 Il existe un dossier d'organisation de la reprise des donnes.
11.23 Le niveau de qualit des donnes d'origine est bien matris.
11.24 Il existe des contrles automatiques de la qualit des donnes
85
obtenues aprs reprise (exhaustivit et exactitude).

11.25 Les utilisateurs devant participer la reprise des donnes ont t
mobiliss le plus tt possible.
Documents rcuprer
plan de communication ;
plan de formation ;
planning de formation avec liste des forms ;
comptes-rendus des valuations des forms et des formateurs.
86
3.7.12.
DOCUMENTATION
Pour que lapplication soit prenne et puisse voluer, il est important de

produire de la documentation. Ces documents contribuent la
transmission du savoir pour maintenir, faire voluer et utiliser
lapplication.
Points de contrle
12. Documentation
12.1 Il existe un manuel d'utilisation.
12.2 Le manuel utilisateur est conforme aux normes en vigueur.
12.3 Le manuel utilisateur est disponible et comprhensible par
l'ensemble des utilisateurs.
12.4 Le manuel utilisateur comprend les objets du systme et la
description des dessins d'cran et des commandes disponibles.
12.5 Le manuel utilisateur comprend les responsables concernant le
redressement des erreurs ou anomalies.
12.6 Le manuel utilisateur comprend la description des sorties et leur
mode de diffusion.
12.7 Le manuel utilisateur comprend les responsabilits en matire de
sauvegarde/archivage/purge.
12.8 La manuel utilisateur fait l'objet d'une procdure de mise jour.
12.9 Il existe un manuel d'exploitation.
12.10 Le manuel d'exploitation est accessible et comprhensible pour les
oprateurs.
12.11 Le manuel d'exploitation a t test lors des tests finaux.
12.12 Le manuel d'exploitation comprend la fonction des programmes.
12.13 Le manuel d'exploitation comprend le libell exact des fichiers
concerns.
12.14 Le manuel d'exploitation comprend la liste des messages

oprateurs et les rponses attendues.
12.15 Le manuel d'exploitation comprend les actions suivre en cas
d'anomalies.
12.16 Le manuel d'exploitation comprend la liste des tats gnrs et
leurs destinations.
12.17 Le manuel d'exploitation comprend les procdures de reprise.
12.18 Le manuel d'exploitation comprend les responsabilits de
l'exploitation en matire de contrles gnraux.
12.19 Le manuel d'exploitation fait l'objet d'une procdure de mise jour.
Documents rcuprer
liste des indicateurs ;
tableau de bord ;

87
3.7.13.
ROLES ET RESPONSABILITES
Il est important de dfinir les rles et les responsabilits de lensemble

des parties prenantes lors de la conduite dun projet, et ce, pour
lensemble des phases de son existence (de ltude dopportunit au
retrait de service).
Points de contrle
13. Structures mises en place l'occasion du projet
13.1 Les rles et les responsabilits respectifs de la MOA et de la MOE
sont clairement dfinis.
13.2 Les prrogatives du chef de projet sont clairement dfinies.
13.3 Le chef de projet dispose de l'autorit suffisante pour rsoudre les
ventuels conflits.
13.4 La MOA et la MOE disposent des comptences et des ressources
managriales, techniques et fonctionnelles suffisantes.
13.5 Les principales dcisions et orientations du projet sont prises par le
niveau de management adquat.
13.6 Les principaux intervenants sur le projet sont 100% ddis au projet
avec suppression, pendant la dure du projet, des anciens liens
hirarchiques.
13.7 La MOA ou la MOE ont bnfici d'une assistance extrieure au
cours du projet.
13.8 La consultation et l'implication des utilisateurs a t suffisante au
cours des diffrentes phases du projet.
13.9 Il existe un contrat de prestation entre la MOA et la MOE.
13.10 Si oui, il existe un engagement de rsultat.
Documents rcuprer
organigramme du projet avec dfinition des fonctions ;

contrats d'assistance, de sous-traitance, d'infogrance,
88
3.7.14.
GESTION DES EVOLUTIONS
Le terme volution dsigne les modifications apportes un systme

aprs sa mise en service. La gestion des volutions doit faire lobjet dune
organisation et de procdures clairement dfinies.
14.15 Lvolution est conforme au niveau de performance attendu.

14.16 Lvolution est conforme au niveau de scurit attendu.
14.17 Lvolution est conforme au niveau de convivialit attendu.
14.18 L'apprciation de lvolution est exprime par les utilisateurs
travers un questionnaire.
Documents rcuprer
Points de contrle
14. Gestion des volutions
14.1 Les demandes d'volution du primtre sont frquentes.
14.2 Les demandes d'volutions sont formalises.
14.3 Il existe une procdure de gestion des volutions du primtre.
14.4 Une mesure d'impact est effectue.
14.5 Il existe une gestion des versions.
14.6 Les dcisions sont prises avec un dlai satisfaisant.
14.7 Les dcisions sont prises sur la base d'un niveau d'information
pertinent.
14.8 Le manuel utilisateur fait l'objet d'une procdure de mise jour.
14.9 Le manuel d'exploitation fait l'objet d'une procdure de mise jour.
14.10 Lorganisation de soutien aux utilisateurs est informe des
volutions et les a anticipes.
14.11 Les diffrents niveaux de soutien restent coordonns et cohrents.
14.12 Il existe un bilan de qualit de lvolution.
14.13 Le bilan de qualit prend comme rfrence les exigences qualit
fixes par la MOA et traduites par la MOE en objectifs et critres
respecter.
14.14 Lvolution est conforme aux besoins fonctionnels exprims par le
cahier des charges.
procdure de demande d'volution du primtre ;
liste des demandes d'volution ;
89
3.7.15.
MISE EN PRODUCTION
La phase de mise en production est celle de la mise disposition des

utilisateurs. Elle doit se faire de manire ordonne, en respectant
strictement les procdures internes lors de la bascule de responsabilit
entre la direction charge des projets et la direction charge de la
production.
Cette tape soulve souvent des problmes que les environnements de
tests nont pas pu simuler. Il est donc primordial dassurer la reprise
dactivit le plus rapidement possible aprs la mise en production de
lapplication, pour ne pas gaspiller la priode de garantie.
Points de contrle
15. Mise en production
15.1 Les responsabilits respectives des directions des projets et de la
production sont clairement tablies et les primtres dcrits respectent
les principes de sparation des tches.
15.2 Il existe un document dcrivant les responsabilits respectives des
projets et de la production lors dune mise en production.
15.3 Les quipes projet et de production connaissent et respectent ce
document.
15.4 Les oprations de mise en production sont traces et conformes.
15.5 Les obligations respectives de lorganisation et de ses fournisseurs
lors de la mise en production sont clairement indiques dans les
documents contractuels.
15.6 Les membres de lorganisation et les fournisseurs respectent leurs
obligations lors de la mise en production.
15.7 La bascule de la garantie vers la maintenance est organise travers
des documents contractuels clairs.
Documents rcuprer
dossier d'organisation de la direction informatique ;

procdure de mise en production.
90
3.8.
AUDIT DES MARCHES SPECIFIQUES AU
DOMAINE INFORMATIQUE
Ce paragraphe est consacr aux marchs spcifiques au domaine
informatique. Il a vocation complter le guide des bonnes pratiques des
achats de services informatiques du service des achats de ltat (SAE), qui
reste la rfrence.
Les risques propres ces marchs sont notamment :
limprcision des responsabilits des acteurs tatiques et privs,
en raison de lutilisation dans les marchs des notions de MOA,
MOE, AMOA, etc. sans accord explicites des parties sur la porte
de ces notions ;
la complexit oprationnelle et juridique des prestations,

notamment pour les fonctions partiellement externalises ;
la nature des prestations, qui peuvent aisment driver vers un

positionnement illicite des agents du prestataire vis--vis de
ladministration ;
linsuffisante dfinition des livrables et limprcision voire

linexistence des critres dvaluation permettant dattester
objectivement la ralit du service fait.
91
3.8.1.
TUDE DES MARCHES DASSISTANCE
TECHNIQUE
L'assistance technique (qui se retrouve frquemment en conduite de
projets sous la forme dAMOA) est un besoin pour les services du
ministre qui ne disposent pas de toutes les comptences pour mener
bien toutes les missions qui leur sont confies. Nanmoins, les marchs
passs dans ces domaines prsentent diffrents risques :
risque de perte de comptence pour les services ;
risque de cot prohibitif pour les finances publiques ;
risque pnal car ces marchs, s'ils sont mal rdigs, mal passs ou
mal excuts, courent le risque d'tre requalifis, par le juge, en
prt illgal de main d'uvre ou en dlit de marchandage.
Points de contrle
1. Marchs dAMOA
1.1 Les responsabilits respectives de ladministration et du titulaire sont
clairement tablies et le march ou un document qui lui est annex les
prcise.
1.2 Les quipes du titulaire et les reprsentants de ladministration
connaissent et respectent ce document.
1.3 Lobjet du march est rgulier :
la prestation, objet du march, nest pas irrgulire par nature
(liquidation de factures, rdaction de marchs, ) ;
le march na pas pour seul objet le prt de main d'uvre (ex :
prix calcul selon un montant exprim en hommes/jour).

1.4 Les obligations des parties sont conformes au droit :
les pices du march (CCTP, acte dengagement) font apparatre
des obligations de rsultats du titulaire et non des obligations de
moyens (ex : pas de jalons, pas ou peu de livrables, aucun rsultat
rellement exig).
1.5 Les documents du march ne montrent pas que le service a voulu
sattacher une personne prcise (CV, nom de lintervenant cit, ).
1.6 Lexcution du march ne fait pas apparatre une rupture du lien
hirarchique entre l'employ et sa hirarchie :
les agents du titulaire ne sont pas intgrs dans les quipes de
ladministration ;
les agents du titulaire ne reoivent pas leurs ordres de la

hirarchie du service prescripteur.
1.7 Lexcution du march ne fait pas apparatre une intgration des

agents du titulaire au sein de ladministration :
les agents du titulaire napparaissent pas nominativement dans
les documents de ladministration (organigrammes, annuaires, PV
de runions, ) ;
les agents du titulaire nutilisent pas abusivement les moyens de
ladministration (accs au restaurant de ladministration au tarif
"usager", utilisation dune adresse de messagerie de
ladministration, accs aux rseaux de ladministration, ) ;
les agents du titulaire ne sont pas rpartis dans les locaux des
services de ladministration sans sparation manifeste et
identification prcise (absence de badges et de locaux
particuliers) ;
les agents du prestataire ne sont pas en poste depuis plus de 3
92
ans (dure indicative).
93
3.8.2.
TUDE DES MARCHES DACQUISITION DE

PRESTATIONS INFORMATIQUES SUR LA BASE DUN
FORFAIT
Le march peut avoir pour objet la prestation de services dont le prix est
fix forfaitairement, la date de conclusion du contrat. Mme dans le
cadre dun forfait, le contrat peut dtailler les sommes alloues au titre
des redevances de licences, de maintenance, ou du prix de la formation
ventuelle, des dveloppements spcifiques
Si le client a lavantage de bnficier dun prix forfaitaire, il faut tenir
compte dun certain nombre de risques. Par exemple, le calendrier peut
driver, la charge de travail du prestataire peut tre sous-value, ou le
rfrentiel trop imprcis peut enfermer ladministration dans un
primtre excessivement restreint.
Points de contrle
2. Marchs de prestation sur la base dun forfait
2.1 Sagissant des licences, le march prvoit les droits concds par
lditeur et les conditions daccs au code source en cas de rsiliation.
2.2 Le contrat prcise quels documents constituent le rfrentiel des
spcifications afin de dterminer le champ des prestations entrant dans le
montant du march fix forfaitairement.
2.3 Le march distingue le traitement des volutions qui pourront
entraner une facturation complmentaire, dans des conditions prvues
entre les parties, et celles, simples prcisions ou adaptations, qui
resteront incluses dans le prix tabli forfaitairement.
2.4 Un mcanisme de pnalits de retard sanctionne le non-respect du
calendrier (y compris les jalons intermdiaires), ou un bonus est prvu si
le prestataire atteint ses objectifs dans des dlais plus courts que prvu.
2.5 Les jalons intermdiaires ne sont pas artificiels.
2.6 Le march prcise bien quels sont les prrequis (disponibilit du
personnel du client, configuration matrielle, ).
94
3.8.3.
TUDE DES MARCHES DACQUISITION DE

PRESTATIONS INFORMATIQUES SUR LA BASE DUN
FORFAIT HORAIRE
Le march peut avoir pour objet la prestation de services caractre

informatique dont la rmunration est calcule sur la base dun forfait
horaire ou journalier. Cette formule prsente lavantage de la souplesse
et de la simplicit mais elle est risque, notamment sur le plan juridique
(sanctions pnales et requalification du contrat).
Ladministration peut, en effet, perdre le contrle du cot final de
lopration : la rmunration au temps pass fait supporter par le seul
client le risque conomique de lopration.
Le march peut tre requalifi en prt illicite de main-duvre (article
L.125-3 du Code du travail) ou marchandage (article L.125-1 du Code du
travail). Sont alors pnalement responsables autant lauteur du prt
illicite de main-duvre (la SSII) que son bnficiaire (ladministration). De
plus, la relation entre lemploy de la SSII et le client peut tre requalifie
en contrat de travail (avec les consquences fiscales et sociales trs
lourdes induites).
Bien que ntant pas a priori irrgulier, ce mode de contractualisation est
trs dconseill et doit chaque fois que possible tre remplac par un
march forfait.
Points de contrle
3. Marchs de prestation sur la base dun forfait horaire
3.1 La nature de la mission confie au prestataire est matrialise et
dfinie prcisment. Le recours des personnes extrieures (expertise
particulire par exemple) est justifi.
3.2 Le march attribue explicitement la responsabilit de lexcution des
travaux incombant au prestataire et prcise que le lien de subordination
du personnel nest en rien transfr ladministration. Les relations sont
formalises dans les pices constitutives du march.
3.3 La dure du march est clairement limite la mission dcrite dans
lobjet du contrat, ou un terme prcisment fix dans le temps est prvu.
3.4 Les clauses du march prvoient (et lexcution montre) que lorsque
le personnel de la SSII intervient dans les locaux de ladministration, il doit
respecter les rgles dhygine et de scurit ainsi que les rgles gnrales
et permanentes relatives la discipline, issues du rglement intrieur du
client (il nest toutefois pas soumis aux mmes contraintes horaires et de
congs).
3.5. Le prestataire est, dans la mesure du possible, isol dans un local qui
lui est confi pendant la dure de la prestation (rdaction dun protocole).
Cette disposition peut tre contraire lobjet mme du march,
notamment dans le cas dune plateforme commune au cur de la
mthode AGILE. Dans ce cas, lattention doit tre porte sur la stricte
limitation des ressources accessibles aux agents du prestataire.
95
3.8.4.
TUDE DES MARCHES DINFOGERANCE
OU DE TIERCE MAINTENANCE APPLICATIVE
(TMA)
La norme AFNOR Z67 801-1 dfinit linfogrance comme tant un service
dfini comme le rsultat de lintgration dun ensemble de ressources
lmentaires, visant confier un prestataire informatique tout ou partie
du systme dinformation du client dans le cadre dun contrat pluriannuel,
base forfaitaire, avec un niveau de service et une dure dfinis.
Une TMA consiste, comme pour le SaaS, en lexternalisation dune
infrastructure et/ou dune application. Il ne sagit pas de lexternalisation
dun processus (BPO, pour Business Process Outsourcing, en anglais).
Ainsi, dans une TMA, lutilisateur tatique demeure responsable de
lutilisation qui est faite des matriels et logiciels externaliss, et du
rsultat de leur emploi.
Aux intrts stratgiques (optimiser la gestion de son systme
dinformation, rduire les cots, gagner du temps) rpond le risque de
dpendance vis--vis du prestataire.
Points de contrle
4. Marchs dinfogrance ou de TMA
4.1 Le march notifi prcise convenablement lopration projete et sa
dlimitation. Un audit technique et juridique des caractristiques des
applications de lentreprise cliente pourra avoir t ralis en phase
pralable.
4.2 Le march inclut un engagement du prestataire sur des performances
et une qualit du service. Une clause du CCAP fixe les indicateurs de
qualit, par exemple par une rfrence un PAQ (qui peut tre le premier
livrable du march) ou loffre du fournisseur, avec des pnalits
associes en cas de non-respect.
4.3 Le march prvoit lobligation pour le prestataire, quelle que soit la
cause du terme du contrat, de prendre toutes les dispositions utiles ou
dapporter son client son concours pour assurer la rversibilit de la
mise en infogrance de son systme informatique (soit parce quil
souhaite lexploiter lui-mme, soit parce quil souhaite en confier
lexploitation un tiers de son choix). Le contrat prcise les conditions
dapplication et les modalits pratiques de cette rversibilit.
4.4 Les dispositions du march organisant la rversibilit sont mises en
uvre de manire dmontrable, la fois par le prestataire et par les
services de ladministration qui en sont bnficiaires.
4.5 La TMA ne camoufle pas du dveloppement.
96
3.8.5.
TUDE DES MARCHES AYANT POUR

OBJET LA FOURNITURE DUNE APPLICATION
HEBERGEE
Le principe dun FAH (fournisseur dapplication hberge, ou en anglais

ASP pour Application Service Provider), consiste proposer un client
daccder aux fonctionnalits de son choix et/ou des services associs.
Un contrat de fourniture dapplication hberge peut tre scind en deux
parties, un volet forfaitaire correspondant un droit dentre ou daccs,
et une autre partie proportionnelle lutilisation.
loptimisation du prix (notamment slection des seules fonctionnalits
ncessaires) et lvolutivit associe des fonctionnalits choisies, sajoute
pour le client lavantage de disposer dun interlocuteur unique.
Il faut, cependant, veiller bien cerner les besoins et le prix payer et,
comme pour tout contrat informatique, bien dfinir les niveaux de
service attendus.
Points de contrle
5. Marchs FAH
5.1 Le march prvoit lobligation, pour le prestataire, dassurer la
scurit des donnes traites, et ce dautant plus si celles-ci sont sensibles
(donnes comptables, fiscales, sociales ou de paie notamment). Cette
obligation de scurit concerne tant le traitement de donnes que leur
conservation, voire leur archivage.
5.2 Sagissant des licences, le march prvoit les droits concds par
lditeur et les conditions daccs au code source en cas de rsiliation. Il
prvoit galement la possibilit de transfrer le savoir-faire du prestataire
relatif un produit, qui est galement une condition de la rversibilit.
5.3 Le contrat prvoit ltendue des prestations fournies par le prestataire
(les conditions daccs aux services, les niveaux du service et les causes
dexclusion du service).
5.4 Le contrat prcise les niveaux de service attendus par le client tant en
termes de performances quen termes de disponibilit des applications.
97
98
4. DICTIONNAIRE DES
EXPRESSIONS SPECIFIQUES ET
ACRONYMES
4.1.
DICTIONNAIRE DES EXPRESSIONS
SPECIFIQUES DU DOMAINE
Ces dfinitions rapides doivent permettre aux auditeurs de vrifier quils
partagent avec les audits une mme comprhension de certaines
notions spcifiques et complexes. Cette vrification est particulirement
ncessaire lorsquune tierce partie un prestataire est implique, par
exemple lors de lexamen des conditions de ralisation dun march.
4.1.2.
STRATEGIQUE INFORMATIQUE
Le schma directeur est un plan stratgique destin piloter le
dveloppement de l'informatique dans l'organisation, en cohrence avec
sa stratgie gnrale.
Un schma directeur informatique dcrit le systme informatique actuel
et futur, dans une logique dobjectifs et de services attendus. Il offre donc
une vue globale de ltat prsent du systme, un inventaire et une
spcification des besoins et dfinit des orientations.
Il est approuv par le plus haut niveau de lorganisation. Il doit faire
lobjet darbitrages clairs portant sur les finalits vises, les adaptations de
processus oprationnels, les ressources humaines et financires affectes
et les tapes et le calendrier de ralisation.
Sa dure de vie est gnralement comprise entre deux et six ans.
4.1.3.
4.1.1.
GOUVERNANCE DU SI
La Gouvernance des Systmes d'Information ou Gouvernance

informatique dsigne le dispositif mis en place par une organisation
pour contrler et rguler son SI. ce titre, la gouvernance du SI fait partie
intgrante de la gouvernance de lorganisation et consiste d'abord fixer
au SI des objectifs dcoulant de la stratgie de l'organisation.
Les rfrentiels et fournissent des lments permettant de mettre un
systme d'information sous contrle et de le faire voluer en fonction de
la stratgie de lorganisation
SCHEMA DIRECTEUR ET PLAN
PLAN DOCCUPATION DES SOLS (POS)
La multiplication des applications prsentant des recoupements

fonctionnels a conduit la notion durbanisation du systme
dinformation.
Il sagit, par analogie avec les outils du dveloppement urbain, de fixer
des rgles rgissant le dveloppement applicatif pour amliorer la
couverture fonctionnelle de certaines activits de lorganisation, viter la
duplication des outils informatiques, fournir une vision prospective de
lvolution du patrimoine applicatif, etc.
Le patrimoine applicatif est ainsi rparti sur un plan doccupation des sols,
en zones, quartiers, ilots et blocs fonctionnels. Les applications actuelles
et futures sont censes tre rparties entre chacune des subdivisions. En
99
pratique, ce dcoupage nest pas toujours ais, ce qui peut amener la

cration de zones fonctionnelles dites transverses et laffectation dune
application la zone correspondant sa fonction principale, voire
historique , au dtriment parfois dune vision densemble des services
quelle rend.
Cette dmarche durbanisation encourage le dveloppement dun SI
constitu de modules fonctionnels lchelle de lorganisation. Il faut
alors porter une attention particulire au socle technique commun (la pile
logicielle) et la gestion des nombreuses interfaces et des donnes de
rfrences.
Chaque subdivision du plan doccupation des sols doit possder un
responsable effectif charg de son pilotage, de son interaction avec les
autres zones (change de donnes, interfaces applicatifs, etc.) et de
lentretien dune vision prospective, gnralement sous la forme dun
schma directeur. Faire vivre lurbanisme du SI est un dfi pour toute
organisation, quelle que soit sa taille.
4.1.4.
MAITRISE DOUVRAGE (MOA) ET

MAITRISE DUVRE
La matrise douvrage est le commanditaire du projet informatique. Il

sagit soit dune direction mtier, lorigine du besoin fonctionnel et
sponsor du projet, soit (par exemple au ministre de la dfense) dune
direction gnrale spcialise dans le co-pilotage (avec les directions
fonctionnelles) et la conduite des projets.
La MOA :
constitue une quipe projet adapte et disposant des moyens
financiers, humains et techniques ncessaires ;
spcifie les besoins fonctionnels et tablit le cahier des charges ;
dfinit les moyens et les contraintes (dlais, cots, qualit, ...) ;
dfinit et fait vivre le portefeuille des risques du projet ;
slectionne la MOE et rdige ; notifie et pilote les marchs

correspondants ;
pilote la MOE par une comitologie adapte aux enjeux et

mthodes retenues (ex : AGILE) ;
valide les solutions proposes par la MOE et suit leur ralisation ;
rceptionne lapplication conformment aux besoins exprims ;
administre lapplication jusqu son retrait.
Lassistance matrise douvrage (AMOA) soulage le travail de la MOA en

la dchargeant des tches de pilotage de nature technique (assistance la
spcification, assistance la slection de la MOE et la contractualisation
de la prestation, secrtariat de la comitologie, etc.). Les principaux
dfauts observs sont :
AMOA remplaant dans les faits la MOA, ce qui conduit
rapidement un dfaut de matrise du projet par le
commanditaire, avec toutes les drives associes ;
AMOA palliant les lacunes de lquipe projet au lieu de lassister ;
AMOA mal slectionne et manquant dindpendance vis--vis de

la MOE, ce qui peut, par exemple, avoir un impact sur le contenu
de la spcification et la conduite de lappel doffres ;
AMOA ne pouvant tre remise en concurrence en raison de son

emprise sur le projet.
100
La partie tudes de la direction informatique joue frquemment le

rle de MOA dlgue. Ce schma, qui permet de faire piloter lAMOA ou
la MOE par des spcialistes des projets informatiques, nexonre pas la
direction mtier de ses responsabilits de MOA.
La matrise duvre est le garant technique du bon droulement dun
projet.
La MOE :
propose des solutions techniques sur la base des besoins, moyens
et contraintes dfinis par la MOA ;
assure ou supervise le dveloppement de lapplication ;
contrle et teste le rsultat (tests unitaires et tests dintgration) ;
livre lapplication pour la recette puis, le cas chant, lexploite.
Il est responsable vis--vis deux de la correcte prise en compte de

lensemble de ces problmatiques. Il veille ce que les utilisateurs
bnficient dune formation et dun soutien adquats.
Cette fonction ne doit pas tre confondue avec celle de responsable
dapplication(s), qui dsigne gnralement celui qui, au sein de la DSI, est
charg de la gestion du portefeuille applicatif de lorganisation.
Un propritaire de donnes est responsable vis--vis de la direction, des
processus oprationnels et des utilisateurs de la qualit, de lintgrit, de
la scurit et de la disponibilit dun ensemble de donnes. Notamment, il
attribue et surveille les droits de cration, de modification, de lecture et
de suppression des donnes. Il est galement responsable, autant que
possible, de lunicit des donns, cest--dire de leur non rplication,
notamment locale, par les utilisateurs. Cette fonction de propritaire de
donnes est dautant plus importante que les donnes sont sensibles et
transverses.
Un propritaire dapplication ou de donnes est un responsable
oprationnel.
4.1.5.
PROPRIETAIRE (BUSINESS OWNER ) DUNE
APPLICATION OU DE DONNEES
Un propritaire dapplication est charg de veiller la bonne adaptation
dune application ou dun portefeuille dapplications aux besoins du
mtier (notion dalignement stratgique) et son environnement logiciel
et matriel.
Il est, ce titre, linterlocuteur du responsable des processus et mtiers
utilisant lapplication, de lurbaniste du systme informatique, du
gestionnaire des budgets informatiques (maintenance, volution et
nouveaux projets), du responsable de la scurit informatique et du
responsable des plans de continuit et de reprise de lactivit de
lorganisation.
Au sein dune organisation, chaque application et chaque donne devrait

avoir un propritaire dsign, y compris pour les applications et processus
externaliss.
4.1.6.
BASE DE DONNEES MAITRESSE
Lorsque des donnes sont partages entre plusieurs acteurs (directions

fonctionnelles, applications informatiques, etc.) au sein dune
organisation, il faut mettre en place un dispositif visant garantir
lexistence, pour chacune de ces donnes, dune rfrence incontestable.
La base de donnes matresse est cette rfrence. Elle peut tre
duplique en des bases de donnes rparties, cres pour rpondre un
101
besoin de proximit gographique ou fonctionnelle. Par exemple, les

coordonnes clients ou la liste des agents identifis dans le SI sont des
informations sensibles utilises par de nombreuses applications : leur
exactitude, leur mise jour et surtout leur unicit doivent tre garanties.
Lune des tches importantes dun propritaire de donnes est de veiller
la qualit des processus de rplication entre les bases de donnes
matresse et rparties.
4.1.7.
4.1.8.
CHARTE DUTILISATION
Une charte dutilisation est un document valid par la direction gnrale

de lorganisation, dclinant aux utilisateurs la politique de scurit du SI.
Elle est obligatoirement signe par tous les utilisateurs des ressources
informatiques.
Elle peut tre tablie sur le modle suivant :
les modalits dutilisation des moyens informatiques et de
tlcommunications mis disposition. Par exemple :
POLITIQUE DE SECURITE
Elle couvre l'ensemble des orientations suivies par une entit en matire
de scurit. la lumire des rsultats de l'analyse de risques, elle :
dfinit le cadre d'utilisation des ressources du SI ;
le poste de travail ;
les quipements nomades ;
lespace de stockage individuel ;
prcise les rles et responsabilits en la matire ;
o
identifie les techniques de scurisation mettre en uvre dans
les diffrents services de l'organisation ;
le rseau local ;
internet ;
sensibilise les utilisateurs la scurit informatique.
la messagerie lectronique ;
le tlphone.
La scurit informatique rsulte dun compromis entre la protection des

actifs numriques et informatiques et la possibilit pour les utilisateurs de
dvelopper les usages lgitimes qui leur sont ncessaires. ce titre, la
politique de scurit informatique relve de la responsabilit de la
direction de l'organisation concerne.
les rgles de scurit auxquelles se conformer, ce qui peut inclure

par exemple :
o
les moyens dauthentification ;
les modalits dintervention du service de linformatique

interne ;
102
signaler au service informatique interne toute violation

ou tentative de violation suspecte de son compte
informatique
et
de
manire
gnrale
tout
dysfonctionnement ;
de ne jamais confier son identifiant/mot de passe un

tiers ;
de ne pas modifier les paramtrages du poste de travail ;
de ne pas installer, copier, modifier, dtruire des logiciels

sans autorisation ;
de verrouiller son ordinateur ds que lon quitte son

poste de travail ;
de ne pas accder, tenter daccder, ou supprimer des

informations qui ne relvent pas des tches incombant
lutilisateur ;
les modalits de copie de donnes sur un support

externe.
les conditions dadministration du SI et lexistence, le cas

chant, de systmes automatiques de filtrage ou de traabilit ;
les responsabilits et sanctions encourues en cas de non-respect

de la charte.
4.1.9.
ENVIRONNEMENTS DE DEVELOPPEMENT
(ETUDES ), DINTEGRATION ET DE PRODUCTION
(EXPLOITATION)
La sgrgation des environnements et des fonctions de dveloppement et
de production informatique est un lment essentiel de la scurit
informatique et de la lutte anti-fraude. Elle joue en matire informatique
un rle quivalent la sparation entre ordonnateurs et comptables en
matire de dpense publique, et revt la mme sensibilit.
Toute modification des applications informatiques, depuis les grands
projets applicatifs jusqu la mise jour dune composante du systme
dexploitation, doit respecter cette sgrgation. Elle est dveloppe sur
un environnement SI spcifique (qui peut tre celui dun prestataire), sur
lequel elle est teste une premire fois.
Elle est ensuite qualifie par les quipes de la production, dans un
environnement
distinct
de
lenvironnement
de
production
(lenvironnement accessible aux utilisateurs, sur lequel sont ralises les
activits relles de lorganisation) mais aussi reprsentatif que possible de
ce dernier.
Cette qualification inclut les tests de bon fonctionnement, mais aussi la
revue du code (ou, dfaut, des spcifications dtailles) et de la
documentation.
Cette acceptation par la production est un prrequis indispensable au
transfert de la modification sur lenvironnement de production.
Les interventions directe des tudes sur lenvironnement de production
doivent tre limites au strict minimum et parfaitement traces et
encadres.
103
4.1.10.
RECETTE
En informatique, la recette (ou test d'acceptation) est une phase du projet

visant assurer formellement que le produit est conforme aux
spcifications.
Elle s'inscrit dans les activits plus gnrales de qualification. Cette tape
implique le droulement rigoureux de procdures de tests pralablement
dcrits, et l'identification de tout cart fonctionnel ou technique. Dans ses
phases de tests fonctionnels, elle ncessite une forte disponibilit des
utilisateurs (directions mtiers).
Ce terme renvoie des notions diffrentes dans les marchs : vrification
de bon fonctionnement, vrification de fonctionnement rgulier, service
fait. Dans le cas dun march informatique, les parties doivent saccorder
sur la porte de ces expressions, ce qui peut ncessiter leur explicitation.
4.1.11.
CONVENTION ET CONTRATS DE SERVICE
(SLA / OLA)
Le contrat de service, appel aussi convention de service, souvent dsign
par lacronyme anglais SLA (pour service level agreement) , est un
document qui dfinit la requise entre un prestataire dun service
informatique et les usagers de ce service, ou clients .
Un SLA est la formalisation dun accord ngoci entre deux parties. Il met
donc par crit un niveau de service, exprim par lattente des parties sur
le contenu des prestations, leurs modalits d'excution, les
responsabilits des parties, et des garanties, notamment en termes de
continuit ou de rtablissement de service.
Par exemple, le SLA peut spcifier les niveaux de disponibilit ou de

performance dun service informatique (matriel, y compris rseau,
logiciel, soutien utilisateurs, dlais dintervention, etc.).
Tout engagement quantitatif doit tre mesurable, effectivement mesur,
et faire lobjet dun dialogue de gestion.
4.1.12.
PLAN DE CONTINUITE DE LACTIVITE ET

PLAN DE REPRISE DE L ACTIVITE
Ces deux notions sont distinctes.
Un Plan de Reprise dActivits (PRA) est un ensemble de mesures

qui permettraient une organisation de reprendre son activit
aprs un sinistre, par exemple une panne qui paralyserait son SI
au-del du supportable.
Un Plan de Continuit dActivit (PCA) est un ensemble de

mesures qui permettraient une organisation de poursuivre son
activit pendant un sinistre. La diffrence est notable car, dans ce
dernier cas, lactivit ne cesse pas. Lorganisation est donc
contrainte, pour la totalit ou pour une partie de son activit, de
faire travailler diffremment de son fonctionnement habituel.
Les PRA et PCA vont trs au-del de la seule informatique. Ils sont donc un
dispositif cl de lorganisation, qui conditionne sa capacit agir en
situation de crise interne ou externe, et doivent, ce titre, faire partie de
sa stratgie de scurit. Ils doivent toujours tre en conditions
oprationnelles, ce qui implique de mettre en place une politique de tests
rguliers.
104
En raison de la forte dpendance des organisations vis--vis de leur SI, les

PCA et PRA doivent voluer de pair avec le SI. Ils peuvent ou non se
dcliner dans une notion connexe, limite linformatique : les plans de
reprise informatique (PCI) ou de continuit informatique (PRI).
4.1.13.
INFOGERANCE ET OUTSOURCING
Linfogrance consiste dlguer un ou plusieurs prestataire(s)

informatique(s) tout ou partie de la gestion de son systme dinformation.
Les prestations correspondantes et le niveau de service attendu sont
formaliss dans un cadre contractuel ou par un march.
Cela peut concerner des lments dinfrastructure (mise en place et
exploitation de serveurs ou de systmes de sauvegarde, supervision de
services rseau ou de tlphonie) et/ou des aspects logiciels
(dveloppement, maintenance).
En infogrance dite totale , l'organisation confie l'intgralit de la
gestion de son SI une entreprise tierce, de la conception la
maintenance, en passant par lexploitation.
La sensibilit stratgique du SI et des actifs numriques, la qualit de la
prestation et sa rversibilit sont des lments de dcision essentiels.
Les mcanismes dinfogrance et doutsourcing connaissent un fort regain
dactualit li lmergence du concept de cloud computing.
4.1.14.
INFORMATIQUE EN NUAGE , OU CLOUD
COMPUTING
Linformatique en nuage est une technologie qui consiste sappuyer sur
les capacits des rseaux pour mettre la disposition des utilisateurs
finaux un service, fourni par des logiciels et une infrastructure
informatique souvent distants.
Le plus souvent, ces utilisateurs nont pas connaissance de la localisation

prcise des matriels, logiciels et donnes auxquels ils accdent par
lintermdiaire dun rseau public ou priv. Le service peut tre lui-mme
fourni par une entit publique, voire tatique (on parle alors parfois de
cloud souverain ) ou par un oprateur priv.
Linformatique en nuage permet de concentrer des matriels techniques
et des logiciels dans des installations ( datacenters ) de plus grandes
dimensions en nombre limit, ce qui vite de multiplier les installations
locales, de petites dimensions et de standards matriels ou logiciels
disparates. Cela permet la concentration des ressources humaines
comptentes, une conomie dchelle, facilite la maintenance et amliore
les scurits physique et logique.
Il sagit donc dune disposition technique et organisationnelle, dont les
consquences juridiques et oprationnelles doivent tre examines au cas
par cas par les responsables oprationnels. Notamment, les
infrastructures informatiques (serveurs applicatifs et de bases de
donnes) peuvent tre situes ltranger, ce qui pose des questions en
matire de protection des informations sensibles et de droit applicable,
par exemple aux donnes personnelles.
Lutilisateur peut gnralement bnficier des niveaux de services
suivants :
le niveau IaaS (Infrastructure as a Service). Ce service consiste
offrir un accs un parc informatique mutualis. Il permet donc
laccs une infrastructure matrielle sur laquelle lusager peut
installer ses machines virtuelles et leur environnement
informatique dexploitation. Cest un service dhbergement qui
permet de mutualiser les quipements ;
105
le niveau PaaS (Platform as a Service). Ce service met disposition

de lusager des machines virtuelles et leur environnement
informatique dexploitation dont lusager na plus assurer le
fonctionnement. Lusager installe sur ces machines virtuelles ses
propres applications et ses outils. Cest un service qui permet de
mutualiser les systmes informatiques ;
le niveau SaaS (Software as a Service). Dans ce type de service, les

applications sont mises la disposition des usagers qui nont pas
se soucier de les installer, deffectuer les mises jour, dajouter
des patches de scurit et dassurer la disponibilit du service.
Ltablissement qui fait appel ce service nachte plus de licence
logicielle mais sabonne ce logiciel. Lapplication est directement
utilisable via le navigateur web.
Le cloud computing peut donc aller du trs basique au trs complet (IaaS,
PaaS, SaaS, etc., le contenu prcis de chacune de ces notions tant en
dbat). Les offres IaaS et PaaS sadressent aux services informatiques. Les
offres SaaS sadressent directement aux utilisateurs des applications.
4.1.15.
DATACENTER
Un datacenter, ou centre de traitement des donnes , est un lieu

spcialis contenant des serveurs de gestion de base de donnes (SGBD),
des serveurs de fichiers et des serveurs applicatifs. Il peut tre propre
une organisation, ou au contraire externalis ou mutualis (logique de
linformatique en nuage).
Il offre gnralement des niveaux de services graduels, allant de la seule
fourniture de lenvironnement (le bnficiaire amne ses propres
serveurs) ladministration complte dun ensemble applicatif. Il hberge
gnralement, et de plus en plus, les actifs les plus prcieux dune
organisation.
Ces centres se caractrisent normalement par un environnement

(nergie, climatisation, protection physique et logique, virtualisation,
accs aux rseaux, outils dadministration et de supervision) trs soign,
destin garantir un trs haut niveau de disponibilit, dintgrit et de
confidentialit. Il sagit, avec la mutualisation entre tous les utilisateurs du
cot financier et humain dun tel environnement, de leur principal atout.
Linsertion dun tel centre dans une chane nergtique vertueuse doit
aussi favoriser latteinte des objectifs environnementaux de lorganisation
(notion dinformatique verte, ou green computing).
Les deux principaux enjeux actuels sont leur localisation, pour des raisons
de confidentialit et de rgime juridique, et la chasse aux multiples petits
datacenters historiques (parfois un simple PC dans un bureau), qui
offrent gnralement un environnement trs loign des meilleures
pratiques.
4.1.16.
MAINTENANCE APPLICATIVE OU
CORRECTIVE, TMA, TME
La maintenance dune application est une activit indispensable qui

consiste adapter en continu une application lvolution de son
environnement technique, logiciel et de scurit. Un renouvellement de
matriel ncessite, en effet, le recours de nouveaux pilotes, une
modification de pile logicielle (ensemble des outils informatiques qui
permettent le fonctionnement de lapplication, par exemple le systme
dexploitation) doit tre prise en compte par les applications et la
dcouverte dune faille de scurit implique la mise en place dune
protection.
Gnralement, cette maintenance cote annuellement le cinquime du
prix initial de lapplication. Sa bonne excution est de la responsabilit du
propritaire de lapplication. Son suivi est le plus souvent confi la DSI,
gnralement par la partie tudes . La maintenance applicative est
106
parfois dsigne par les sigles MCO (maintien en

oprationnelle) et MCS (maintien en condition de scurit).
condition
La maintenance applicative diffre de la maintenance volutive en ce que

la premire napporte aucune volution fonctionnelle. Au contraire, la
seconde ajoute des fonctionnalits, gnralement de faible ampleur. Pour
les volutions fonctionnelles plus profondes, on parle davantage de
nouvelle version applicative, voire de nouveau projet.
La TMA, ou tierce maintenance applicative, consiste externaliser la
maintenance applicative et/ou volutive un tiers.
Pour tre qualifi de progiciel de gestion intgr , une solution

logicielle doit couvrir au moins deux domaines fonctionnels diffrents de
lentreprise (par exemple, RH et finance, ou encore finance et achats).
Un PGI peut constituer le socle du SI de lentreprise sil couvre la quasitotalit des processus fonctionnels cls de celle-ci.
Un ERP peut, dans certaines limites, tre paramtr pour sadapter
lorganisation. Dans la pratique, cest surtout lorganisation qui doit
sadapter lERP. Sa mise en place ncessitera donc une refonte parfois
substantielle des processus et, dans tous les cas, un fort investissement
initial.
La TME, ou tierce maintenance dexploitation, consiste en supplment

externaliser tout ou partie de linfrastructure (y compris son volution) et
des fonctions dadministration et de support aux utilisateurs.
Il existe un continuum entre lexternalisation de la maintenance
applicative et lexternalisation complte dun processus, chaque situation
constituant un cas despce rgi par des dispositions contractuelles
spcifiques.
4.1.17.
PROGICIEL DE GESTION INTEGREE PGI
(ERP)
Un PGI (progiciel de gestion intgr) ou ERP (Enterprise Resources
Planning) est un progiciel qui intgre les principales composantes
fonctionnelles de l'entreprise : gestion de production, gestion
commerciale, logistique, ressources humaines, comptabilit, contrle de
gestion. l'aide de ce systme unifi, les utilisateurs de diffrents mtiers
travaillent dans un environnement applicatif identique qui repose sur une
base de donnes unique. Ce modle permet d'assurer lintgrit des
donnes, la non-redondance de l'information, ainsi que la rduction des
temps de traitement.
107
108
4.2.
DICTIONNAIRE DES ACRONYMES
Les acronymes ci-dessous sont ceux qui, cits dans le document, nont pas
t dfinis ou explicits par ailleurs.
GB : Help desk
IaaS
Service dinfrastructure (dans le cadre dune informatique en

nuage)
GB : Infrastructure as a service
Batch
BPR
BSC
Squence de traitement automatique, galement appele

traitement par lots , gnralement ralise en temps
diffr
ITIL
Ringnierie des processus
MCD
Modle conceptuel de donnes
GB : Business Process Reengineering
OS
Systme dexploitation (GB : Operating system)
Tableau de bord prospectif
PaaS
Service dhbergement
Rfrentiel pour la production informatique

GB : Information Technology Infrastructure Library
GB : Platform as a Service
GB : Balanced score card

Rfrentiel de contrle interne informatique
PCA/PRA Plan de continuit de lactivit/Plan de reprise de lactivit
GB : Control Objectives for Information and related

Technology
PCI/PRI
Plan de continuit de linformatique/Plan de reprise de

linformatique
COMEX
Comit excutif
SaaS
Logiciel en tant que service (dans le cadre dune informatique

en nuage)
CPU
Core processing unit (processeur)
DBA
Administration de base de donnes
COBIT
GB : Software as a service
SAN
Rseau de stockage de donnes
GB : Database administration
GB : Storage Area Network
HD
Plateau dassistance (technique)

SGBD
Serveur de gestion de base de donnes

109
SSO
Identifiant unique (GB : Single sign-On)
TP
Traitement en temps rel, aussi appel Traitement

transactionnel
GB : Transaction Processing
UML
Langage de modlisation unifi

GB : Unified Modeling Language
YTD
Anne glissante
GB : Year to date
110
SECRETARIAT GENERAL
FICHE DEVALUATION DU GUIDE DAUDIT DES

SYSTEMES DINFORMATION
Nous vous remercions davoir utilis cette premire version du
Guide daudit des Systmes dInformation.
Afin de pouvoir lamliorer et laborer dautres documents
lintention des auditeurs internes de lEtat, nous vous demandons
de prendre quelques minutes pour remplir la prsente fiche
dvaluation.
1. A quelle occasion avez-vous utilis ce guide ?
2. Aviez-vous dj une exprience de laudit des Systmes

dinformation ?
Oui :
..
Non :.
.
3. Aviez-vous dj t form
laudit des Systmes
dinformation?
Oui :
..
Non :.
..
4. Globalement, ce guide vous a-t-il apport laide dont vous aviez
besoin ?
Oui :
..
Non :.
..
5. Lavez-vous trouv facile dutilisation ?
Oui :
..
Non :.
111
..
6. Le niveau de dtail abord vous a-t-il sembl adquat ?
Oui :
..
Non :.
..
7. Le cas chant, quels aspects auriez-vous souhait voir plus
dvelopps ? Quels aspects vous ont-ils parus trop dvelopps ?
Pas assez dvelopps :
..
..
..
Trop dvelopps :
..
..
8. Pouvez-vous valuer lutilit de ce guide sur une chelle de 1
(peu utile) 5 (extrmement utile) ?
1. Peu utile
2. Assez utile
3. Utile
4. Trs utile
5. Extrmement utile
9. Souhaitez-vous
suggestions ?
formuler
dautres
*
* *
Vous pouvez galement tlcharger ce formulaire au format
lectronique ladresse suivante :
http://www.action-publique.gouv.fr/files/questionnaire_guide_si.doc
Formulaire renvoyer :
a) par voie lectronique : sec-gen.chai@finances.gouv.fr ;
b) ou voie postale :
Secrtariat gnral du CHAI - Tldoc 659
139 rue de Bercy
75572 Paris Cedex 12
commentaires ou
112

Guide D Audit Des Si v1-2

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Guide D Audit Des Si v1-2

Încărcat de

Drepturi de autor:

Formate disponibile

Guide pratique du CHAI

Parmi les thmes daudit abords dans ce guide :

Laudit du pilotage des systmes dinformation

Laudit de la production informatique

Laudit des applications informatiques en service

Laudit du support utilisateurs et de la gestion du parc

Laudit de la fonction tude

Laudit des projets

Laudit des marchs spcifiques au domaine informatique p. 91

Version 1.0 juin 2014

Prcaution concernant lutilisation du prsent document

Anne AUBURTIN (IGAS),

Les systmes informatiques : enjeux et risques ............................................................................................................................................. 7

Le systme informatique .............................................................................................................................................................................................. 7

Les risques informatiques.......................................................................................................................................................................................... 13

Approche de certains thmes daudit ............................................................................................................................................................ 19

Laudit des SI loccasion de missions gnralistes ....................................................................................................................................... 19

Laudit dune organisation ....................................................................................................................................................................................................... 19

Les audits dapplication ............................................................................................................................................................................................................ 29

Approche thmatique et technique des principaux domaines daudit des SI .......................................................................................... 35

Audit du pilotage des systmes dinformation...................................................................................................................................................... 37

Audit de scurit .......................................................................................................................................................................................................... 43

Audit de la production informatique ...................................................................................................................................................................... 51

Audit des applications informatiques en service .................................................................................................................................................. 59

Audit du support utilisateurs et de la gestion du parc ......................................................................................................................................... 67

Audit de la fonction tude ......................................................................................................................................................................................... 69

Audit des projets ......................................................................................................................................................................................................... 73

Audit des marchs spcifiques au domaine informatique .................................................................................................................................. 91

Objectifs et enjeux du projet ..................................................................................................................................................................................................... 73

Dictionnaire des expressions spcifiques et acronymes ............................................................................................................................. 99

Dictionnaire des expressions spcifiques du domaine ........................................................................................................................................ 99

Dictionnaire des acronymes .................................................................................................................................................................................... 109

Fiche dvaluation du Guide daudit des systmes dinformation .............................................................................................................................. 111

Cependant, ce guide est orient vers laudit de structures de taille

Il dcrit en deuxime partie, dune part, la dimension informatique des

1. LES SYSTEMES INFORMATIQUES :

Un systme informatique est constitu de ressources matrielles et

Le systme informatique, appel aussi systme dinformation, (not SI)

La fonction informatique vise fournir ces ressources lorganisation. Elle

Les dveloppements suivants exposent, de manire synthtique, les

Elle ne doit pas tre confondue avec la fonction dinformation, ensemble

1.1.1.1. L A PERFORMANCE DU SI DE LTAT

Ce cadre stratgique commun du SI de ltat fixe une ambition commune

niveaux. Ce corpus se compose de documents de politique globale

la politique de scurit, dfinissant les rgles gnrales de

le cadre commun durbanisation dfinissant la dmarche

le cadre commun dinteroprabilit.

Ce corpus comprend galement des documents rglementaires

le rfrentiel gnral de scurit,

le rfrentiel gnral daccessibilit pour ladministration.

Il comprend galement des documents porte ministrielle :

un cadre de cohrence technique : normes, standards et rgles

une mthode de conduite de projet qui dfinit et structure les

Il comprend ventuellement une charte durbanisation qui dcline

1.1.1.2. LES FACTEURS CLEFS D UN SI PERFORMANT

quand il fait lobjet de marchs, est conforme aux bonnes

Les principaux facteurs clefs dun SI performant sont les suivants :

une forte implication de la direction dans la gestion du SI. Elle doit

des documents dorganisation de la gouvernance du SI,

des comits de pilotage informatiques rguliers (suivi des

est en conformit avec les obligations lgales ;

est facile utiliser ;

des tableaux de bord de suivi de linformatique ;