Informatisation de projets

INFORMATISATION
DES
PROJETS
<<IP v3.1.9>>
AWOUZOUBA Esso-Essinam
Magister Informatica
Gran Guru Computador
Gr.nd D3ck H.cK3P
Togo 22890794666
cawouzouba@gmail.com
©~2017

1
Sécurité informatique/ Audit Informatique/ Gestion des projets /Management du Changement/ Contrôle de Qualité/Kaizen
Présentation de l’unité d’enseignement Pré-requis :
 Une connaissance acceptable de l’anglais serait un atout
 Une connaissance de Mathématiques
 Les notions de projet
 Une expérience professionnelle serait un atout
Objectif général
Ce cours permet à l’étudiant de se familiariser aux techniques de conception, de suivi et évaluation de projets
contraint par une prescription de qualité, de budget et de délai.
Objectifs spécifiques
L’étudiant, après avoir suivi ce cours, doit être capable de :
 Différencier les ressources, les outils, les aspects organisationnels et humains dans un projet
 Utiliser efficacement les différents outils et techniques de gestion de projet
 Vérifier la conformité d’un programme/projet par rapport aux spécifications.
 Démontrer la maîtrise de logiciels connaissances et les compétences de l'ingénierie et des questions
professionnelles nécessaires pour l'ingénierie des projets
 Discuter des principes de gestion de projet
 Décrire les modèles de cycle de vie d’un projet;
 Appliquer les principes de la modélisation au projet
 Identifier les principales activités et les principaux résultats d'un cycle de vie d’un projet
 Différencier et choisir et Appliquer une méthodologie de gestion de projets
 Appliquer les concepts de gestion de projet dans un environnement de développement durable
 Participer à titre individuel ou en groupe à un projet
Contenu de l’enseignement
 Unité 1: Introduction gouvernance d’entreprise
 Unité 2: urbanisation des Systèmes d’Information
 Unité 3: Audit des Systèmes d’Information / Projets de Développement durables
 Unité 4: MS Project : Logiciel de modélisation
 Unité 5: Maintenance des Projets
 Unité 6: Evaluation des Performance des Projets
 Unité 7: Mise en œuvre
 Unité 8: Gestion de projet leçons et perspectives
Evaluations
 40%(Devoirs surveillés) + 60%(Synthèse) et QCM
 0.20(DS1) + 0.20(DS2) + 0.60(Synthèse)
Méthodes d’enseignement
Cours magistral 30%+ Travaux Pratiques 50%+ Travaux de Maisons 20%

2
Résultats de l’apprentissage Séances
30h
Contenus Méthodes d’enseignement
 Unité 1:
o gouvernance d’entreprise
1h Cours magistral
Travaux de maisons
 Unité 2:
o urbanisation des
Systèmes d’information
1h Cours magistral
Travaux pratiques /labo
 Unité 3:
o Audit des Systèmes
d’Information
 Unité 4
o Maintenance
2h Cours magistral
Laboratoires
 Unité 5:
o Gestion de projet
o Théories analytiques
o Méthodologies
o Format et formalisme
5h Cours magistral
Travaux de maisons
 Unité 6
o Evaluation des
performances des Projets
2h Cours magistral
Travaux de maisons
 Unité 7: MS Projet
o Installation utilisation
o CPM
o Gantt
o Ressources
o Travail
o Cout
o Cas pratiques
14h Cours magistral
Travaux de maisons
 Unité 9:
o projet tutoré
6h Cours magistral
Travaux de maisons

3
I. LE GOUVERNEMENT D'ENTREPRISE
Introduction
Les problèmes liés à l’informatique sont essentiellement des problèmes de logiciel. La crise du logiciel
d’après travaux de Standish Group en 1995 permet de voir que sur 9380 projets étudiés, la situation est de
moins appréciables telle que exemplifiée par le tableau ci-dessus :
Projets succès Problématique (hors budget hors délais,
spécifications non fonctionnelles)
Echec /abandon
8380 16% 53% 31%
La gouvernance d'entreprise - ou « corporate governance » - désigne le système formé par l'ensemble
des processus1, réglementations, lois et institutions destinés à cadrer la manière dont l'entreprise est
dirigée, administrée et contrôlée.
En fonction des objectifs qui gouvernent l'entreprise, ce système est appelé à réguler les relations entre les
nombreux acteurs impliqués ou parties prenantes. ( : stakeholders).
Les acteurs clés sont les actionnaires qui élisent le Conseil d'administration, lequel mandate la Direction,
selon des modalités propres au régime juridique de ladite société. Les employés, les fournisseurs,
les clients, les banques ou autres prêteurs, le voisinage, l'environnement et les tiers sont les autres
stakeholders
1. Définition
La gouvernance du SI (SI :est un ensemble organisé de ressources (matériels, logiciels, personnel,
données et procédures) qui permet de collecter, regrouper, classifier, traiter et diffuser de l'information
dans un environnement donné) consiste d'abord à fixer au SI des objectifs liés à la stratégie de l'entreprise.
Cette démarche permet de définir la manière dont le SI permet à l’entreprise de créer de la valeur en
précisant le rôle des différents acteurs en tenant compte de leurs enjeux de pouvoir. Elle donne réponse à
des questions telles que : la Direction des SI est-elle responsable de la mise en œuvre du SI ou est-ce le
rôle des métiers ou des maîtrise d'ouvrage (MOA) ?
La gouvernance des SI ou gouvernance informatique (IT gouvernance) renvoie aux moyens de gestion et
de régulation des SI mis en place dans une organisation en vue d'atteindre ses objectifs.. Les
méthodes ITIL ( IT infrastructure library ) et COBIT sont par exemple des supports permettant de mettre un
SI sous contrôle et de le faire évoluer en fonction de la stratégie de l'organisation.
Les SI font 15 à 20 % du chiffre d'affaires des entreprises, soit 50 % de la valeur ajoutée générée par les
entreprises. Globalement, cela fait entre 20 à 25 mille milliards USD.
1
Le mot processus vient du latin pro (au sens de « vers l'avant ») et de cessus, cedere (« aller, marcher ») ie, avancer.
La procédure désigne plutôt la méthode d’organisation, la stratégie du changement.

4
Mais ce ne sont pas que des dépenses sans contreparties car une partie importante partie est constituée
par des investissements qui permettent de développer la capacité de l'entreprise à créer de la valeur. Le
développement des SI permet d'augmenter la valeur ajoutée créée par l'entreprise.
Le développement des SI représente des investissements conséquents qu'il faut gérer. Ce qui fait la
réussite des entreprises à dominante de SI. C'est le concept de Peter Drucker d'IBO, Information Based
Organization, utilisé par Google, Wall-Mart, Amazon, Dell, ....
2. Buts
La gouvernance des SI a pour but de définir les principaux objectifs, les fonctions et les tâches pour
alimenter la nouvelle fonction du management de l'information. Il est pour cela nécessaire d'étudier et de
proposer de nouvelles solutions, pour positionner cette nouvelle fonction dans l'architecture des modèles
d'organisation et notamment de mettre en place des tableaux de bord des SI
La gouvernance des SI a l’enjeu de développer la capacité de l'entreprise à créer de la valeur basée sur 4
axes :
 La création et le développement des services (e-commerce, e-storage, e-services)
 La création de nouveaux produits (voitures électroniques, hybriques, photocopieurs)
 L'amélioration des processus de l'entreprise (la gestion de la relation client, CRM ; gestion de la
logistique, SCM (supply chain management )
 Le développement des partenariats (clients, fournisseurs, concurrents)
3. Comment Gérer les investissements des SI ?
Les SI nécessitent des investissements dans plusieurs domaines :
 les infrastructures : serveurs, postes de travail, routeurs, etc.
 les applicatifs : logiciels de base, progiciels, applications spécifiques, etc.
 la mise en place du système : efforts sur la formation, capitalisation du savoir, etc.
 l'organisation et l'optimisation des processus existants.
4. Comment Piloter des SI?
 Un système d'information doit être piloté .Cela se fait sur la base de trois règles à savoir :
 Fixer des objectifs liés à la stratégie de l'entreprise,
 Lier les innovations permises par le SI en créant de nouveaux produits, des processus innovateurs
ou des services plus efficaces,
 Tenir compte de la valeur ajoutée créée par le système d'information par rapport aux dépenses
engendrées par la mise en place de celui-ci, ceci dans une optique de long terme.
Le modèle de Michael Porter ( les cinq forces)

5

6
II. URBANISATION DES SI
Introduction
L'urbanisation du SI d'une organisation consiste à faire évoluer le SI pour qu'il soutienne et accompagne
efficacement et avec efficience les missions de cette organisation et leurs transformations. L'urbanisation
du SI prend en compte l'existant et doit permettre de mieux anticiper les évolutions ou contraintes internes
et externes impactant le SI, et en s'appuyant le cas échéant sur des opportunités technologiques. Il y a
analogie entre l'urbanisation de l'habitat humain (organisation des villes, du territoire), et urbanisation
informatique.
L'urbanisation SI réingénierie du (SI) est l'action d'urbaniser le SI : cette démarche prévoit des principes et
règles ainsi qu'un cadre cohérent, stable et modulaire, auquel les différentes instances décisionnaires de
l'organisation peuvent se référer pour toute décision d'investissement relative au management du SI.
Les évolutions des stratégies d'entreprise (fusions, acquisitions, diversification des offres commerciales, e-
commerce, CRM, nouveaux modes ou canaux de distribution, partenariats, réorganisation, externalisation,
redéploiement des fonctions de back et front office, etc.) impliquent des changements structurels
importants et accroissent l’interdépendance (dépendance mutualisée) et l’imbrication
des applications informatiques avec le risque de renforcer l’effet « sac de nœud» du SI.
Cette complexité croissante a des conséquences sur les coûts, les durées et
les risques des projets d’évolution des SI. la démarche d’urbanisation des SI et par son prolongement au
niveau de l’architecture des SI est la réponse à la maitrise progressive de l’évolution des SI en vue de
réduire les coûts.
Cette démarche d'urbanisation vise un SI capable de soutenir et d’accompagner la stratégie
d'entreprise dans le meilleur rapport coûts/qualité/délais. Elle permet d’améliorer la réactivité et de
n’investir que dans les produits et services générateurs de valeur ajoutée, tout en maîtrisant les charges
informatiques et le retour sur investissement.
1. Principe de l'urbanisation du SI
L'urbanisation répond à deux règles de base :
 Une application doit appartenir-en cible- à un et un seul bloc (pour quelle raison ?).
 Les dépendances doivent respecter les notions de Cohérence Forte / Couplage Faible
 entre les applications,
 au sein d'une application : entre les différents modules,
 au sein d'un module : entre les différents composants.
Le terme -en cible- définit l'application que l'on cherche à avoir to be. Elle s'oppose à l'existant -la situation
actuelle- As is. La méthode pour passer du as-is actuel au to-be souhaité est appelé la ou feuille de route
La notion de Cohérence Forte / Couplage Faible indique que deux applications doivent communiquer entre
elles de façon simple et efficace, mais que la dépendance entre ces deux applications est minimale
(idéalement inexistante). Cela permet donc de retirer un bloc pour le remplacer sans perturber le reste du
SI.

7
Le SI est comparable au quartier d'une ville bien bâti et bien urbanisé, il est possible de raser un bâtiment
au cœur du quartier sans mettre en péril tout le secteur, et de le remplacer ou de reconstruire un autre
bâtiment, en raccordant ce nouveau bâtiment aux différents réseaux d'échanges : voirie d'accès, électricité,
évacuation des eaux usées, etc. L'urbanisation consiste donc à créer un SI agile, modulable et
évolutif.
2. Application des concepts d'urbanisation
L’urbanisation SI est une démarche d'aide à la transformation, rationalisation, simplification et amélioration
du SI. Certains auteurs comparent le SI à l’image d’une ville, c'est-à-dire réfléchie, structurée, durable.
Dans le prolongement de cette analogie - qui a toutefois des limites -, l'urbanisation du SI consiste à
planifier des refontes structurantes pour optimiser, les échanges, les services, la flexibilité, la modularité ...
et d'une façon plus générale à répondre à la stratégie SI de l'entreprise en parallèle de l'évolution du
métier.
a. Le plan d'urbanisme SI ou Plan d'Occupation des Sols (POS)
Pour faciliter les planifications face aux évolutions du SI, l'urbanisation s'appuie sur un plan d'urbanisme
appelé POS, en analogie avec l'urbanisme civil. Le POS consiste à représenter le SI en s’appuyant sur
une cartographie fonctionnelle du SI et un découpage en capacités autonomes,: les zones, les quartiers,
les îlots, ,briques
Le POS doit faciliter la construction d'une architecture optimisée du point de vue fonctionnel du SI qui est le
point de vue pivot entre le point de vue du métier et le point de vue informatique.
Plus particulièrement, l’urbanisation vise :
 à renforcer la capacité à construire et à intégrer des sous-systèmes d'origines diverses,
 à renforcer la capacité à faire interagir les sous-systèmes du SI et les faire interagir avec d’autres
SI (interopérabilité),
 à renforcer la capacité à pouvoir remplacer certains de ces sous-systèmes (interchangeabilité).
 favoriser son évolutivité, sa pérennité et son indépendance du SI,
 renforcer sa capacité à intégrer des solutions hétérogènes (progiciels, éléments de différentes
plates-formes).

8
b. Exemple de règles de découpage du SI
 Règle 1 : Séparation du Back-office du Front-office.
 Règle 2 : Découpage par processus et par métier. On crée ainsi les
zones Décisionnel, Support et Métier.( La zone Métier peut être découpée en plusieurs blocs.)
 Règle 3 : Séparation des canaux technologiques d'accès et de communication (site Web,
notification SMS, ...) des canaux du métier 'Relation Client' (CRM, Marketing). On inscrit deux
nouvelles zones dans le Front-Office : Acquisition/Restitution et Relation avec les tiers.
 Règle 4 : Il faut isoler ce qui est partagé par le Back-office et le Front-office ainsi que ce qui les
intègre. On définit donc les zones Intégration et Données Partagées.
c. Les différents types de zones
En général, dans le découpage d'un SI on distingue différents types de zones :
 Les zones des échanges avec l’extérieur du SI : acquisition/émission de/vers
les partenaires : clients, fournisseurs,
 Les zones des activités opérationnelles : gestion des opérations bancaires, gestion des opérations
commerciales, gestion des opérations logistiques internes, etc. ;
 Les zones de gestion des données de référence communes à l'ensemble du SI :
les référentiels de données structurées (données clients, catalogue de produits et services, etc.) ;
 Les zones de gestion des gisements de données : ensemble des informations produites
quotidiennement, communes à l'ensemble du SI (données de production, etc.) ;
 Les zones des activités de support : comptabilité, ressources humaines, etc. ;
 Les zones des traitements pour l’aide à la décision et le pilotage : informatique décisionnelle.
L’urbanisation totale et efficace des grandes entreprises demande le découpage du SI de l'entreprise en
périmètres autonomes ; par exemple : par grandes directions. Sa zone d'échange gère les flux extra-
entreprises "SI ⇔ SI extérieurs" que les flux intra-entreprises "SI ⇔ autres SI de l'entreprise".
3. Comment urbaniser ?
La démarche d’urbanisation suppose 3 axes clés imbriquées (qui s’alimentent mutuellement) :
 la modélisation de la stratégie
 la cartographie des systèmes existants (métier, fonctionnels, applicatifs, techniques)
 la détermination des systèmes cibles (métier, fonctionnels, applicatifs, techniques)
La démarche d’urbanisation du SI consiste notamment à :
 définir un SI cible, aligné sur la stratégie de l’entreprise,
 déterminer la trajectoire à suivre pour atteindre ce SI cible.
Indépendamment des différentes approches qui, selon le contexte de l'entreprise et les options
méthodologiques, peuvent être préconisées les activités d'urbanisations se classent en cinq grands
domaines :
 Le "cœur" des processus d'urbanisme,

9
 Définir et maintenir le cadre d'urbanisme : plans d’urbanisme (cibles et scénarios de migration),
règles, ,
 Réaliser et maintenir l'infrastructure fonctionnelle du SI : référentiels d’entreprise, dispositifs
mutualisés d’échanges inter-applicatifs, …,
 Développer les relations avec les projets : cadrage, études amont, accompagnement des projets,
…
 Les processus de support : notamment « Maintenir et diffuser les cartographies ».
 Et les processus de pilotage de l'urbanisation et de participation à l'arbitrage des projets.

10
III. AUDIT
Introduction
L'audit informatique (ou IT Audit) permet l’identification et l’évaluation des risques (opérationnels,
financiers, de réputation notamment) associés aux activités informatiques d'une entreprise. L’audit se base
sur le cadre réglementaire du secteur d’activité du pays concerné (ie le CRBF 97-02 pour une banque
française), sur les référentiels de bonnes pratiques existants (ie le référentiel CobiT), sur les benchmarks à
disposition et sur l’expérience professionnelle des auditeurs impliqués.
Il existe deux grandes catégories d’audit : Les audits globaux d'entité (audits des activités ayant trait aux
systèmes d’informations et les audits thématiques, ayant pour objectif la revue d’un thème informatique
au sein d’une entité (la gestion de projet, la sécurité logique par exemple).
L’audit n’est pas l’activité de conseil qui vise à améliorer le fonctionnement et la performance d'une
organisation avec une éventuelle implication dans la mise en œuvre de cette amélioration.
1. Les concepts de base de l'audit informatique
L’audit informatique se base sur La notion de contrôle. L'objectif est de mettre en place des dispositifs de
contrôle efficaces et performants permettant de maîtriser l'activité informatique en vue de s’assurer de la
réalisation raisonnable des trois objectifs suivants :
 la conformité aux lois et aux règlements,
 la fiabilité des informations financières,
 la réalisation et l'optimisation des opérations (le champ de l’audit informatique).
La démarche d'audit informatique se définit à partir des préoccupations du demandeur d'audit (CEO, CFO,
CIO),… Il va pour cela mandater l'auditeur pour répondre à une liste de questions précises qui font, plus ou
moins implicitement, référence à l'état des bonnes pratiques connues dans ce domaine. Cela se traduit par
un document important : la lettre de mission qui précise le mandat à exécuter et qui donne les pouvoirs
nécessaires à l'auditeur.
L'auditeur informatique va se servir de référentiels d'audit informatique lui donnant l'état des bonnes
pratiques dans ce domaine. CobiT: Val IT, Risk IT, ISO 27002, CMMi, ITIL, …
2. Audit de sécurité
L'audit de sécurité d'un (SI) est une vue à un instant T de tout ou partie du SI, permettant de comparer
l'état du SI à un référentiel.
L'audit répertorie les points forts, et surtout les points faibles (vulnérabilités) de tout ou partie du système.
L'auditeur dresse également une série de recommandations pour supprimer les vulnérabilités découvertes.
L'audit est réalisé de pair avec une analyse de risques, et par rapport au référentiel. Le référentiel est
généralement constitué de :
 la politique de sécurité du système d'information (PSSI)
 la base documentaire du SI
 réglementations propre à l'entreprise

11
 textes de loi
 documents de référence dans le domaine de la sécurité informatique
3. Les buts de l’audit
 réagir à une attaque
 se faire une bonne idée du niveau de sécurité du SI
 tester la mise en place effective de la PSSI
 tester un nouvel équipement
 évaluer l'évolution de la sécurité (implique un audit périodique)
L’audit a pour but de vérifier la sécurité. Dans le cycle de sécurisation, la vérification intervient après la
réalisation d'une action. Par exemple, lors de la mise en place d'un nouveau composant dans le SI, il est
bon de tester sa sécurité après avoir intégré le composant dans un environnement de test, et avant sa
mise en œuvre effective. La roue de Deming illustre ce principe.( Plan Do Check Act)
Le résultat est le rapport d'audit qui donne la liste exhaustive des vulnérabilités recensées par l'auditeur sur
le système analysé et une liste de recommandations en vue de supprimer les vulnérabilités trouvées.
L'audit n’est pas l'analyse de risques. Il ne permet que de trouver les vulnérabilités, mais pas de déterminer
si celles-ci sont tolérables. Au contraire, l'analyse de risque permet de dire quels risques sont pris en
compte, ou acceptés pour le SI. L'auditeur dresse donc des recommandations, que le client suivra, ou pas.
Le client choisit les recommandations ou non à suivre, en se référant à la politique de sécurité.
4. Pratiques de l’audit :
Interviews – tests d’intrusion – relevés de configuration –audit du code
a. Interview
 Le directeur des SI (DSI)
 les responsables de la sécurité des SI (RSSI)
 Les administrateurs
 Les utilisateurs du SI, qu'ils aient un rôle dans la production de l'entreprise, dans la gestion, ou la
simple utilisation des moyens informatiques
 Tout autre rôle ayant un lien avec la sécurité
b. Les tests d'intrusion
Ils sont de 3 types : Les tests boîte blanche, les tests boîte grise et les tests dits boîte noire.
 Collecte d'informations publiques : pages web, informations sur les employés, entreprise ayant un
lien de confiance avec la cible.
 Identification des points de présence sur internet. et Ecoute du réseau.
c. Les relevés de configuration
 le chargeur de démarrage,

12
 les mécanismes d'authentification (password power, système d’authentification :,..),
 le système de fichiers (droits d'accès, utilisation de chiffrement, WEP, RSA, SHA...),
 les services, la journalisation, la configuration réseau.
d. L'audit de code
L’audit de code est une pratique consistant à parcourir le code source d'un logiciel afin de s'assurer du
respect de règles précises. Notamment, les dépassements de tampon2 (buffer overflow), les bugs de
format, ou pour une application web, les vulnérabilités menant à des injections SQL...
e. Fuzzing
Pour les applications boite noire, où le code n'est pas disponible, il existe un pendant à l'analyse de code,
qui est le fuzzing. Cette technique consiste à analyser le comportement d'une application en injectant en
entrée des données plus ou moins aléatoires, avec des valeurs limites. Contrairement à l'audit de code qui
est une analyse structurelle, le fuzzing est une analyse comportementale d'une application.
5. Différents types d'audit informatique
La démarche d'audit informatique est générale et s'applique à différents domaines comme la fonction
informatique, les études informatiques, les projets informatiques, l'exploitation, la planification de
l'informatique, les réseaux et les télécom, la sécurité informatique, les achats informatiques, l'informatique
locale ou l'informatique décentralisée, la qualité de service, l'externalisation, la gestion de parc, les
applications opérationnelles… il existe les audits informatiques ci-après :
6. Audit de la fonction informatique
Le but de l'audit de la fonction informatique est de répondre aux préoccupations du (CEO, CIO) concernant
l'organisation de la fonction informatique, son pilotage, son positionnement dans la structure, ses relations
avec les utilisateurs, ses méthodes de travail…
7. Audit des études informatiques (AEI)
L'AEI est un sous-ensemble de l'audit de la fonction informatique. Le but de cet audit est de s'assurer que
son organisation et sa structure sont efficaces, que son pilotage est adapté, que ses différentes activités
sont maîtrisées, que ses relations avec les utilisateurs se déroulent normalement,…
Pour effectuer un audit des études informatiques on se base sur la connaissance des bonnes pratiques
recensées dans ce domaine. Parmi celles-ci on peut citer :
8. Audit de l'exploitation
L'audit de l'exploitation a pour but de s'assurer que les différents centres de production informatiques
fonctionnent efficacement et qu'ils sont correctement gérés. Il est pour cela nécessaire de mettre en œuvre
des outils de suivi de la production comme Openview d'HP, de Tivoli d'IBM, Nagios (GPL). Ce sont de SI
dédiés à l'exploitation.
2
une mémoire tampon, ou buffer, est une zone de la mémoire vive ou de disque utilisée pour entreposer temporairement
des données, notamment entre deux processus ou matériels ne travaillant pas au même rythme.

13
L’audit de l'exploitation s’appuie sur des bonnes pratiques concernant ce domaine :
 la clarté de l'organisation de la fonction notamment le découpage en équipes, la définition des
responsabilités,…
 l'existence d'un SI dédié à l'exploitation notamment pour suivre la gestion des incidents, la gestion
des ressources, la planification des travaux, les procédures d'exploitation,…
 la mesure de l'efficacité et de la qualité des services fournies par l'exploitation informatique.
 la qualité de la planification de la production,
 la gestion des ressources grâce à des outils de mesure de la charge, des simulations, le suivi des
performances,…
 l'existence de procédures permettant de faire fonctionner l'exploitation en mode dégradé de façon
à faire face à une indisponibilité totale ou partielle du site central ou du réseau,
 la gestion des incidents de façon à les repérer et le cas échéant d'empêcher qu'ils se renouvellent,
 les procédures de sécurité et de continuité de service qui doivent se traduire par un plan de
secours,
 la maîtrise des coûts de production grâce à une comptabilité analytique permettant de calculer les
coûts complets des produits ou des services fournis.
Ces objectifs de contrôle correspondent au processus DS 1, DS 3, DS 6, DS 12 et DS 13 de CobiT
 DS 1 "Définir et gérer les niveaux de services",
 DS 3 "Gérer la performance et la capacité",
 DS 6 "Identifier et imputer les coûts", DS 12 "Gérer l'environnement physique",
 DS 13 "Gérer l'exploitation".
9. Audit des projets informatiques
L'audit des projets informatiques a pour but de vérifier le déroulement normal et l'enchaînement des
opérations logiquement et efficacement en vue d’avoir de fortes chances d'arriver à la fin de la phase de
développement à une application qui sera performante et opérationnelle.
Les bonnes pratiques pour effectuer un audit d'un projet informatique sont nombreuses et connues par
tous les chefs de projets et de manière plus générale par tous professionnels concernés.
10. Audit des applications opérationnelles (AAO)
Il couvre un domaine plus large et s'intéresse au SI de l'entreprise. Ce peut être l'audit de l'application
comptable, de la paie, de la facturation,…. Mais, de plus en plus souvent, on s'intéresse à l'audit d'un
processus global de l'entreprise comme les ventes, la production, les achats, la logistique,…
L'auditeur va s'assurer du respect et de l'application des règles de contrôle interne. Il va en particulier
vérifier que :
 les contrôles en place sont opérationnels et sont suffisants,
 les données saisies, stockées ou produites par les traitements sont de bonnes qualités,
 les traitements sont efficaces et donnent les résultats attendus,
 l'application est correctement documentée,

14
 les procédures mises en œuvre dans le cadre de l'application sont à jour et adaptées,
 l'exploitation informatique de l'application se fait dans de bonnes conditions,
 la fonction ou le processus couvert par l'application est efficace et productif,
Très souvent on demande à l'auditeur d'évaluer la régularité, la conformité, la productivité, la pérennité de
l'application opérationnelle. Ce sont des questions délicates posées par le management à l'auditeur.
11. Audit de la sécurité informatique (ASI)
L'ASI a pour but de donner au management une assurance raisonnable du niveau de risque de l'entreprise
lié à des défauts de sécurité informatique. On constate actuellement une augmentation de ces risques liée
au développement d'Internet. Ils sont liés à la conjonction de quatre notions fondamentales :
 En permanence il existe des menaces significative concernant la sécurité informatique de
l'entreprise et notamment ses biens immatériels,
 le facteur de risque est une cause de vulnérabilité due à une faiblesse de l'organisation, des
méthodes, des techniques ou du système de contrôle,
 la manifestation du risque. Tôt ou tard le risque se manifeste. Il peut être physique (incendie,
inondation) mais en général, il est invisible et se traduit notamment par la destruction des données,
détournement de trafic, etc..
 la maîtrise du risque (mettre en place des mesures permettant de diminuer le niveau des risques
notamment en renforçant les contrôles d'accès, l'authentification des utilisateurs,…)
12. Démarche d'audit informatique
Une mission d'audit informatique se prépare par un pré-diagnostic afin de préciser les questions que cet
audit va traiter. Cela se traduit par l'établissement d'une lettre de mission détaillant les points à auditer.
Pour mener à bien l'audit informatique il est recommandé de suivre les six étapes ci-après :
 l'établissement de la lettre de mission faite par le demandeur d’audit et qui mandate l’auditeur.
 la planification de la mission permet de définir la démarche détaillée qui sera suivie.
 la collecte des faits, la réalisation de tests, …
 les entretiens avec les audités.
 la rédaction du rapport d'audit assorti des recommandations proposées,
 la présentation et la discussion du rapport d'audit au demandeur d'audit.
Il peut arriver qu'à la suite de la mission d'audit il soit demandé à l'auditeur d'établir le plan
d'action et éventuellement de mettre en place un suivi des recommandations.
13. Les référentiels d'audit informatique
Il existe différents référentiels comme :
 CobiT : C'est le principal référentiel des auditeurs informatiques,
 Val IT permet d'évaluer la création de valeur par projet ou par portefeuille de projets,
 Risk IT a pour but d'améliorer la maîtrise des risques liés à l'informatique
 CobiT and Applications Controls.

15
 ISO 27002, un code des bonnes pratiques en matière de management de la sécurité des SI,
 CMMi : Capability Maturity Model integration qui est une démarche d'évaluation de la qualité de la
gestion de projet informatique,
 ITIL3 . est un ensemble d'ouvrages recensant les bonnes pratiques du management du SI.
Rédigée à l'origine par des experts de l'Office public britannique du Commerce (OGC), la
bibliothèque ITIL a fait intervenir à partir de sa version 3 des experts issus de plusieurs entreprises
de services telles qu'Accenture, Ernst & Young, Hewlett-
Packard, Deloitte, BearingPoint ouPriceWaterhouseCoopers.
 C'est un référentiel très large qui aborde les sujets suivants :
 Comment organiser un système d'information ?
 Comment améliorer l'efficacité du système d'information ?
 Comment réduire les risques ?
 Comment augmenter la qualité des services informatiques ?
Le CobiT4 () est un outil fédérateur qui permet d'instaurer un langage commun pour parler de
la gouvernance des SI tout en tentant d'intégrer d'autres référentiels tels que ISO 9000, ITIL,
Le référentiel principal de gouvernance et d’audit des SI est le CobiT. En résumé le CobiT est un cadre de
référence pour maitriser la gouvernance des SI dans le temps.
Le CobiT a été développé en 1994 (et publié en 1996) par l’ISACA (Information Systems Audit and Control
Association). L’ISACA a été créé en 1967 et est représenté en France depuis 1982 par l’AFAI (Association
Française de l’Audit et du Conseil Informatiques). C'est un cadre de contrôle qui vise à aider le
management à gérer les risques (sécurité, fiabilité, conformité) et les investissements.
"Le CobiT" consiste à décomposer tout système informatique en :
 Planification et organisation
 Livraison et support
Planification et Organisation : dans ce domaine nous cherchons à savoir comment utiliser les techniques
informatiques afin que l’entreprise atteigne ses objectifs.
Livraison et Support : l’objectif est de garantir l’efficacité et l’efficience des systèmes technologiques en
action.
Le CobiT s’adresse à différents utilisateurs :
 Le management pour lequel il offre un moyen d’aide à la décision
 Les utilisateurs directs pour lesquels il permet d’apporter des garanties sur la sécurité et les
contrôles des services informatiques.
 Les auditeurs et les consultants auxquels il propose des moyens d’interventions reconnus
internationalement.
3
Information Technology Infrastructure Library pour « Bibliothèque pour l'infrastructure des technologies de l'information
4
en français Objectifs de contrôle de l’Information et des Technologies Associées

16
L’objectif est d’assurer l’adéquation durable entre les technologies, les processus métiers et la stratégie de
l’entreprise.
a.Critères de l'information
Cette rubrique va intéresser la direction générale en indiquant ce que l'implantation d'un processus donné
va apporter sur les informations (par exemple sur l'information décisionnelle). Ces critères sont :
 efficacité : qualité et pertinence de l’information, distribution cohérente
 efficience : rapidité de délivrance
 confidentialité : protection contre la divulgation
 intégrité : exactitude de l’information
 disponibilité : accessibilité à la demande et protection (sauvegarde)
 conformité : respect des règles et lois
 fiabilité : exactitudes des informations transmises par le management
En améliorant l'information selon ces critères, l'organisation pourra atteindre plus facilement ses objectifs,
cela ouvrira des nouvelles opportunités et améliorera la rentabilité.
b.Les ressources
Cette partie concerne plus le directeur des SI (DSI) ou responsable des SI (RSI), pour l'informer des
ressources qui vont être impactées par le processus. Les différentes ressources sont :
 les compétences : le personnel, efficacité des collaborateurs (internes et externes)
 les applications : ensemble des procédures de traitement
 l'infrastructure : ensemble des installations, Data Center…
 les données : informations au sens global (format, structure…)
 les techniques : équipement, logiciels, bases de données, réseaux…
c. Les processus
Destinés à l'attention du gestionnaire de processus, ils vont définir la structure des domaines, des
processus et des tâches. Il faut savoir qu’un processus se définit comme un ensemble de tâches. Par
exemple, le processus « comptable » intervient dans le domaine « administratif et financier » et se divise
en activités telles que « la saisie de factures, l’édition de balance… ». CobiT propose un modèle de
maturité pour chaque processus afin de le situer par rapport aux meilleures pratiques du marché. Le
modèle comprend 6 niveaux (0 à 5).
d.CobiT Quickstart

17
Cette version simplifiée de CobiT s’adresse principalement aux PME pour lesquelles les techniques
informatiques ne représentent pas un enjeu stratégique mais simplement un levier dans leur stratégie de
croissance.
Déterminer la cible avec la définition de l’activité, des contraintes légales, et de la dépendance de
l’entreprise vis-à-vis de la technologie ;
 Analyser les écarts par l’examen des pratiques de contrôle et des facteurs clés de succès ;
 Définir les projets d’amélioration des processus
 Élaborer un programme intégré de mise en place de la gouvernance en tenant compte des besoins
immédiats de l’entreprise, des interdépendances entre les projets et des ressources disponibles.
Limites du COBIT
Selon Georges Épinette, administrateur du CIGREF, la démarche d'appréhension de ce référentiel doit se
faire intelligemment, notamment lorsqu'il s'agit du cycle de vie de la relation client-fournisseur2. En effet,
CobiT présente une relative indigence en matière : d'alignement du SI ; de gestion des risques et
de sécurité

18
IV. GESTION DES PROJETS SI
En gestion de projets, il y a dix (10) fondamentaux qui sont :
1. Work breakdown structure (structure de découpage du projet)
2. Milestones (Point de marquage ou de référence)
3. Baselines (Canevas)
4. Triple constraint (Time, Cost Scope  Quality)
5. Project lifecycle (Initiation –> Initiale planification <–>Exécution contrôle <-> replanification-
>clôture)
6. Gantt Chart
7. Change control board (Comité de Contrôle)
8. Stakeholders( Parties Prenantes)
9. Change management (Gestion du Changement)(Who When Where Why)
10. Risk mitigation (Atténuation des risques)
La méthode traditionnelle identifie cinq éléments de développement d’un projet (4 étapes plus le contrôle):
initiation planification et design, exécution, contrôle finition
Figure 1 Project Lifecycle

19
Les phases de développement d’un projet
i. initiation
ii. planning :
i. Déterminer comment planifier (e.g. by level of detail or rolling wave);
ii. Définir le canevas;
iii. choisir l’équipe de planification;
iv. identifier les livrables et créer la segmentation du travail;
v. identifier les activités a réaliser pour faire des livrables en réseau séquentiel logique
vi. estimer les pré-requis en ressources pour les activités;
vii. estimer la durée et le coût des activités;
viii. élaborer le programme ;
ix. élaborer le budget;
x. gestion des risques;
xi. avoir le ok formel pour démarrer
xii. . planning for communications and for scope management,
xiii. Identifier les rôles et les responsabilités,
xiv. Déterminer quoi acheter pour le projet
xv. holding a kick-off meeting and design
xvi. exécution & construction
xvii. suivre & contrôler les systèmes
xviii. complétion
Chaque projet est caractéristique et spécifique et unique.

20
Agile management or gestion agile de projet est une méthode itérative et incrémentale de
gestion du des activités du design et en ingénierie, technologie de l’information, et développement de
nouveau produit ou service dans un environnement assez flexible, eg agile software développement.
Cela demande des professionnels des domaines concernés avec l’apport des fournisseurs et des clients.
Il existe des liens entre lean techniques, Kanban et Six Sigma. Les techniques Agile sont très utilisées
dans les petits projets ou partie d’un grand programme ou sur des projets trop complexes pour le client
pour qu’il puisse spécifier ses besoins avant le test du prototype.
C’est la seule technique qui implique activement le client (disponible) dans le développement du projet.
Le développement logiciel avec la méthode agile consiste en un ensemble de de
méthode de développement dans lesquelles les solutions et les prérequis suivent un schéma de
collaboration entre l’auto-organisation, les équipes transversales, .Agile promeut la planification adaptative
le développement évolutif, la livraison à temps l’amélioration continue et la réponse rapide et flexible aux
changements qui surviennent.
The Agile Manifesto, par en 2001 donne les traits du concept de développement Agile
Le Manifeste Agile
In February 2001, 17 software developpers met at the Snowbird resort in Utah to discuss lightweight
development methods. They published the Manifesto for Agile Software Development:
We are uncovering better ways of developing software by doing it and helping others do it. Through this
work we have come to value:
 Individuals and interactions over Processes and tools
 Working software over Comprehensive documentation
 Customer collaboration over Contract negotiation
 Responding to change over Following a plan
Voilà quelques cas de gestion agile
Scrum (software development) - A holistic approach to development that focuses on iterative goals set by
the Product Owner through a backlog, which is developed by the Delivery Team through the facilitation of
the Scrum Master.
Extreme Programming (XP) –or Pair Programming this method uses small groups and has a highly
prescriptive Test Driven Development (TDD) model.
(XM) - An agile methodology based on Scrum, Kanban and Kaizen that facilitates rapid engineering and
prototyping.
Crystal Clear (software development) - An agile or lightweight methodology that focuses on colocation and
osmotic communication.
Kanban (just in time) by Taiichi Ohno- for logistic control A lean framework for process improvement that
is frequently used to manage WIP within agile projects. The Kanban process improvement framework has
been specifically applied to software development, as Kanban (development).

21
PRINCE25: . Méthode très effective de gestion de projet initialement utilisée par the Central Computer and
Telecommunications Agency (now the Office of Government Commerce).
COCOMO6 est un modèle permettant de définir une estimation de l'effort à fournir dans un
développement logiciel et la durée que ce dernier prendra en fonction des ressources allouées.
FURPSE7 (fonctionnalité, utilisabilité, fiabilité, performance, aptitude au service, évolutivité), représentant
un modèle de gestion de projet de développement logiciel, défini par l'ISO 9126.
Work Breakdown Structure (WBS) ou (structure de découpage du projet – SDP); c’est une
décomposition hiérarchique, axée sur les tâches et les activités, du travail que l’équipe de projet doit
exécuter pour atteindre les objectifs du projet et produire les livrables voulus (définition du Project
Management Institute)
 La règle de 100%s'applique à tous les niveaux dans la hiérarchie : la somme des travaux au
niveau « enfant » doit être égale à 100 % du travail représenté par le « parent » et la WBS n'inclut
pas n'importe quel travail qui tombe en dehors de la portée réelle du projet, autrement dit, elle ne
peut pas inclure plus de 100 % du travail.
 Mutex: ( law of mutual exclusion) outre la règle des 100 %, il est important qu'il n'y ait pas de
chevauchement dans la définition de la portée entre les différents éléments d'une WBS.
 Pour les projets de développement de nouveaux produits, la technique la plus courante pour
s'assurer d'une WBS axée sur les résultats consiste à utiliser une structure de répartition des
constituants du produit. Les projets logiciels axés sur les fonctionnalités peuvent utiliser une
technique similaire qui consiste à employer une structure caractéristique des sous-fonctions.
Lorsqu'un projet consiste à fournir des services, une technique courante consiste à capturer tous
les livrables prévus pour créer une WBS axée sur les livrables
 Le RACI8 / Diagramme ou Matrice des Responsabilités
5
Projects in Controlled Environments
6
COnstructive COst MOdel
7
Fonctionnality, Usability, Reliability, Performance, Serviceability, Evolutivity
8
R : responsable.A : acteur.C : consulté.I : informé.

22
Figure 2 le modèle RACI pour l'équipe de production
In project management, the resource breakdown structure (RBS) is a hierarchical list of resources related by
function and resource type that is used to facilitate planning and controlling of project work.[1] The Resource
Breakdown Structure includes, at a minimum, the personnel resources needed for successful completion of a project,
and preferably contains all resources on which project funds will be spent, including personnel, tools, machinery,
materials, equipment and fees and licenses. Money is not considered a resource in the RBS; only those resources
that will cost money are included
Example
In common practice, only non-expendable (i.e., durable goods) resources are listed in an RBS. Example of
hierarchies of resources:
1. Engineering
1.1 Mr. Fred Jones, Manager
1.1.2 Ms. Jane Wagner, Architectural Lead
1.1.3 Software Design Team and Resources
1.1.3.1 Mr. Gary Neimi, Software Engineer
1.1.3.2 Ms. Jackie Toms, UI Designer
1.1.3.3 Standard Time® Timesheet (timesheet and project tracking software)
1.1.3.4 Microsoft Project® (project scheduling)
1.1.3.5 SQL Server (database)
1.1.4 Hardware Architecture Team and Resources
1.1.4.1 Ms. Korina Johannes, Resource Manager
1.1.4.2 Mr. Yan Xu, Testing Lead
1.1.4.3 Test Stand A
1.1.4.3.1 SAN Group A
1.1.4.3.2 Server A1
1.1.4.4 Test Stand B
1.1.4.4.1 SAN Group B
1.1.4.4.2 Server B1
Both human and physical resources, such as software and test instruments, are listed in the example above. The
nomenclature is a numbered, hierarchical list of indented layers, each level adds an additional digit representing. For
example, the numeric labels (1.1, 1.1.2) make each resource uniquely identifiable
he RBS (also known as the User Breakdown Structure) fields in a Project file are specifically coded by the
administrator of that project, usually the Project Manager
Le diagramme de Gantt9 est un outil utilisé (souvent en complément d'un réseau PERT)
en ordonnancement et en gestion de projet et permettant de visualiser dans le temps les diverses tâches
9
Harmonogram Adamieckiego
Release manager Project manager Developer Program Manager
planification I A R C
Développement Produit I I A R
Lancement Produit R A I I

23
composant un projet. Il s'agit d'une représentation d'un graphe connexe, valué et orienté, qui permet de
représenter graphiquement l'avancement du projet.
Le premier diagramme de ce type fut réalisé par l'ingénieur polonais Karol Adamiecki en 1896. Il l'a décrit
en 1931, mais la langue de publication n'a pas permis la reconnaissance internationale de son idée. Pour
cette raison, le concept a été nommé d'après Henry L. Gantt, ingénieur américain collaborateur
de Frederick Winslow Taylor, qui a publié la description du diagramme en 1910.
Cet outil répond à deux objectifs : planifier de façon optimale ainsi que communiquer sur le planning
établi et les choix qu'il impose. Le diagramme permet :
 de déterminer les dates de réalisation d'un projet ;
 d'identifier les marges existantes sur certaines tâches ;
 de visualiser d'un seul coup d'œil le retard ou l'avancement des travaux.
 priorité à la réalisation des fabrications dont la date de livraison est la plus rapprochée ;
 priorité à la première commande arrivée ;
 priorité aux fabrications dont la durée totale est la plus courte ;
 priorité aux fabrications qui utilisent au moins une ressource critique ;
 priorité aux fabrications qui disposent du minimum de marge globale.
La méthode PERT10 est une méthode conventionnelle utilisable en gestion de projet, développée aux
États-Unis dans les années 1950. Elle est censée fournir une méthodologie et des moyens pratiques pour
décrire, représenter, analyser et suivre de manière logique les tâches et le réseau des tâches à réaliser
dans le cadre d'une action à entreprendre ou à suivre.
Tâches et chemin critiques
Ces deux notions constituent l'apport le plus appréciable de la méthode : elles renseignent utilement et
précisément le pilote de projet sur les risques pesant sur son avancement. Grâce au suivi des tâches et du
10
Program Evaluation and Review Technique

24
chemin critique le pilote anticipe les conséquences futures du déroulement de son projet. En théorie on
peut examiner deux perspectives :
 le « pert time » qui exprime le chemin critique exprimé en termes de délais et de calendrier ;
 le « pert cost » qui exprime le chemin critique exprimé en termes de dépenses.
 temps optimiste: temps minimum réquis pour accomplir la tâche (o) or a path (O), assuming everything
proceeds better than is normally expected

25
 temps pessimiste : temps maximum requis pour accomplir l’ activité (p) or a path (P), assuming
everything goes wrong (but excluding major catastrophes).
 Temps moyen: meilleur temps estimative pour accomplir l’activité (m) or a path (M), assuming
everything proceeds as normal.
 Temps espéré: the best estimate of the time required to accomplish an activity (te) or a path (TE),
accounting for the fact that things don't always proceed as normal (the implication being that the
expected time is the average time the task would require if the task were repeated on a number of
occasions over an extended period of time).
 te = (o + 4m + p) ÷ 6
 Variance = ((p-o)/6)²
Figure 3 Cas 2 de CPM
Activité o m p te variance
A 1 2 3 2 0.11
B 2 3 4 3 0.11
C 1 2 3 2 0.11
D 2 4 6 4 0.44
E 1 4 7 4 1
F 1 2 9 3 1.78
G 3 4 11 5 1.78
H 1 2 3 3 0.11
Critical path is ACEGH
 Variance du projet = Variance ACEGH = 0.11+0.11+1+1.78+0.11=3.11
 Déviation standard = Math.sqrt(VarianceACEGH)= 1.76
PROJET : AIR
 Description : Installation d’un système de filtrage à Air
 Maitre d’ouvrage : EPA
 Maitre d’œuvre : Entreprise X
 Déviation Standard du Projet +/- 176 semaines
 (DLP)Durée de livraison du projet : 16 semaines
 (DP)Durée du projet : 15 semaines
 Taux de réussite du projet 78% d’après le Z-score
 Z-score = (DLP –DP)/Déviation standard = (16-15)/1.76 = .57
 (.57 veut dire que le projet aura 71.57% d’arriver à terme à la date de livraison)
On représentera les relations entre les tâches et les étapes par le diagramme ci-après :
 a. Étude, réalisation et acceptation des plans
 b. Préparation du terrain
 c. Commande des matériaux

26
 d. Creusement des fondations
 e. Commande portes et fenêtres
 f. Livraison des matériaux
 g. Construction des fondations
 h. Livraison des portes et fenêtres
 i. Construction des murs
 j. Mise en place des portes et fenêtres
Tableau des niveaux :
1. a b
2. c e d
3. f h
4. g
5. i
6. j
Le concept PERT perfectionne l'outil Diag. de Gantt (1910) et a suscité le développement de méthodes
équivalentes comme la « MPM » (ou méthode des potentiels et antécédents métra) développée par
Bernard Roy (1958).
Critical chain project management (CCPM) est une méthode de planification de gestion et d’exécution
de projet qui prend en compte les incertitudes inhérents aux gestions de projets, (physiques, humaines, et
aptitudes physiques aussi bien que la gestion et le support technique) nécessaire pour exécuter les projets

27
Figure 4 les activités du CPM n'ont pas de marge
Figure 5 un tableau montrant les liens entre les tâches
CCPM est une application de la théorie des contraintes (TOC11) de Goldratt aux projets. Appliquent les
trois premiers des pas du TOC la contrainte système pour tous les projets est identifié comme les
ressources. Exploiter les contraintes, les tâches sur le chemin critique est une priorité sur les autres
activités Finalement, les projets sont planifiés et gérés pour s’assurer de la disponibilité des ressources
quand doivent commencer les tâches critiques de la chaine, ce qui supplante les autres tâches de la
chaine critique
Le plan du projet plan doit subir le nivellement de ressources, et la plus longue chaine de séquence de
contraintes liée aux ressources doit être identifiée comme chemin critique
11
Theory Of Constraints :TOC , est un référentiel de connaissances, de méthodes et d’outils de management
interdisciplinaires des organisations

28
Lean project management ou la standardisation est l’introduction en gestion de projet des concepts comme
lean construction, lean manufacturing and lean. L’intérêt de lean management c’est la minimisation des
pertes en créant plus de la valeur.
Parenthèses des dysfonctionnements dans la gestion
 In its ornate spending, one county government is said to have paid $11,650 as consulting fee for
opening and maintaining the county government’s Facebook account while another county
purchased 10 wheelbarrows at $1,050 each.
 One ministry is implicated in buying a desktop computer $11,000 more than ten times the cost at
the swankiest electronic stores in Kenya.
 L’achat d’une télévision pour 17 600 US$(15 900 €) ou d’un simple stylo pour 85 US$(79 €).
 À peine 1% des dépenses du gouvernement kenyan répondent aux règles comptables
 Il a été acheté au Togo 5 motos pour 10 millions FCFA, 2 millions chacune (circa 2010)
 Le projet de faune classée (mauvaise approche pour identifier les parties prenantes.)

29
V. MAINTENANCE
La maintenance du logiciel (ou maintenance logicielle) désigne les modifications apportées à un logiciel,
après sa mise en œuvre, pour en corriger les fautes, en améliorer l'efficacité ou autres caractéristiques, ou
encore adapter celui-ci à un environnement modifié (ISO/IEC 14764).
Figure 6 En spirale
1. Processus
Cette norme internationale distingue six processus de maintenance logicielle : (L'implémentation ;
L'analyse et la résolution de problèmes ; La modification du logiciel ; L'acceptation de la modification par le
demandeur ; La migration et la mise à la retraite.)
la maintenance du logiciel, repose essentiellement un nombre de processus, d'activités et de règles :
 La transition : la passation coordonnée du logiciel, de l'équipe de développement à l'équipe de
maintenance ;
 Les ententes de services applicatives ;
 La priorisation des requêtes de modification et des rapports de problèmes ;
 L'acceptation ou le rejet d'une demande de modification selon le travail et la complexité plus ou
moins grandes qu'elle implique; son renvoi à l'équipe de développement.
Le maintenanceur ne fait pas que corriger des défauts (bugs). Pourtant des études et des enquêtes
indiquent depuis des années que plus de 80 % des efforts de maintenance sont consacrés à des
interventions autres que correctives (Pigosky 1997). Une notion perpétuée par des utilisateurs qui, en
réalité, ont affaire à des améliorations fonctionnelles du logiciel.

30
Poids de la Maitenance
Répartition effort développement. Origine erreurs Coût de la
maintenance
Définition des besoins 6% 56% 82%
conception 5% 27% 13%
codage 7% 7% 1%
Intégration Tests 15% 10% 4%
Maintenance 67% 10% 4%
Figure 7 Zeltowitz, De Marco
Les travaux du Dr.Meir Lehman de l'Imperial College de Londres, en 1969 aboutissent en 1997 à
la formulation de huit règles de l'évolution d'un logiciel (1997).
i. La modification continue –les logiciels doivent être continuellement adaptés ou il deviendra de
moins en moins satisfaisant
ii. La complexité croissante –comme le logiciel est modifié, il devient plus en plus complexe à moins
que le travail soit effectué pour réduire la complexité
iii. Relation de l'organisation –le logiciel existe dans un cadre de personnes, la gestion, règles et
objectifs de créer un système de vérifications et de balances qui formulent l'évolution du logiciel
iv. Les taux de travail invariant –au cours de la durée de vie d'un système, la quantité de travail est
exécutée.
v. La conservation de familiarité –les développeurs et les utilisateurs du logiciel doivent conserver la
maîtrise de son contenu afin d'utiliser et d'évoluer une croissance excessive réduit la maîtrise et
agit comme un frein
vi. La croissance continue –cette observation indique que la croissance supplémentaire est
également dictée par les contraintes de ressources qui est restreinte la portée originale du
système
vii. Diminution de qualité – la qualité du logiciel diminuera à moins que des mesures sont prises pour
le garder en accord avec les changements opérationnels
Le feedback système –l'évolution de la fonctionnalité et la complexité du logiciel est régie par multi-
boucle, multi-niveau, multiparti de feedback système et montrent que la maintenance est un processus
évolutif et que les logiciels évoluent avec le temps en devenant de plus en plus complexes à moins qu'une
action spécifique soit engagée pour en réduire la complexité.
E.B. Swanson a identifié trois catégories de maintenance : la corrective, l'adaptative et la perfective. Ces
catégories ont été mises à jour par l'équipe de ISO/IEC 14764,
 Maintenance corrective (palliative et curative) : modification d'un progiciel effectuée après livraison
afin de corriger les défauts rencontrés.
 Maintenance préventive (adaptative, perfective, conditionnelle) : modification en fonction de
l’environnement d’utilisation, de l’efficacité et pour prévenir les bugs
Pour l'AFNOR par contre, la maintenance consiste précisément à assurer qu'un bien continue de remplir sa
fonction correctement, non à l'améliorer.

31
2.Niveaux de maintenance
Les problèmes majeurs de la maintenance du logiciel sont d’ordre technique et managérial
 Les problèmes de gestion sont :
 l'alignement sur les priorités de la clientèle ; le choix des employés ;
 le choix de l'entité chargée de la maintenance ;
 la justification de la valeur ajoutée et des coûts de l'équipe.
 Les problèmes techniques sont liés à l'insuffisance
 de la compréhension du logiciel ; de la documentation ; des tests ;
 de la mesure de la maintenabilité.
 Les MM du savoir-faire visent spécifiquement la maintenance du logiciel sont :
 le modèle de maturité (MM) de la maintenance du logiciel S3M (avril 2006) ;
 le modèle de maturité (MM) de la maintenance corrective (Kajko-Mattsson 2001).
Il existe cinq niveaux de maintenance qui sont fonction (du lieu, du personnel, du type de travaux, des
travaux)

32
VI. GESTION DES RISQUES ET DES PERFORMANCES : VAL IT
Introduction
La gestion des risques IT est l’application de la gestion de risques aux IT. Le risque d’entreprise lié à
l’usage, à la possession, à l’opération ou l’implication ou l’influence et l’adoption de l’IT dans une
entreprise.
La mise en place, la maintenance et la mise à jour continue d’un ISMS est un indicateur fort qu’une
entreprise utilise une approche systématique pour l’identification, l’évaluation et la gestion des risques de
sécurité. Different methodologies have been proposed to manage IT risks, each of them divided in
processes and steps.
According to Risk IT, it encompasses not just only the negative impact of operations and service delivery
which can bring destruction or reduction of the value of the organization, but also the benefitvalue enabling
risk associated to missing opportunities to use technology to enable or enhance business or the IT project
management for aspects like overspending or late delivery with adverse business impact.
Generally speaking, risk is the product of likelihood times impact (Risk = Likelihood * Impact)
 The measure of an IT risk can be determined as a product of threat, vulnerability and asset values:
 Risk = Threat * Vulnerability * Asset (risque= menace*vulnérabilité*ressource)
 A more current Risk management framework for IT Risk would be the TIK framework: Risk =
((Vulnerability * Threat) / Counter Measure) * Asset Value at Risk IT Risk
L’environnement du risque
Cette étape est initiale dans la structure ISO ISO/IEC 27005 . Les activités élémentaires sont prévues
comme premier sous procédure de l’évaluation des risques selon NIST SP 800-30. Cette étape suppose
l’obtention de toutes les informations sur l’organisation et la détermination des critères de base, du but et
du canevas de la gestion des risques et l’organisation chargée de ces activités de gestion des risques. The
purpose is usually the compliance with legal requirements and provide evidence of due diligence
supporting an ISMS that can be certified. The scope can be an incident reporting plan, a business
continuity plan.
Another area of application can be the certification of a product.
Criteria include the risk evaluation, risk acceptance and impact evaluation criteria. These are conditioned
by:
 Cadre légal et cadre de régulation
 the strategic value for the business of information processes
 stakeholder expectations
 negative consequences for the reputation of the organization

33
Risk assessment
Risk Management is a recurrent activity that deals with the analysis, planning, implementation, control and
monitoring of implemented measurements and the enforced security policy. On the contrary, Risk
Assessment is executed at discrete time points (e.g. once a year, on demand, etc.) and – until the
performance of the next assessment - provides a temporary view of assessed risks and while
parameterizing the entire Risk Management process. This view of the relationship of Risk Management to
Risk Assessment is depicted in figure as adopted from OCTAVE.
Risk assessment is often conducted in more than one iteration, the first being a high-level assessment to
identify high risks, while the other iterations detailed the analysis of the major risks and other risks.
According to National Information Assurance Training and Education Center risk assessment in the IT is :
 A study of the vulnerabilities, threats, likelihood, loss or impact, and theoretical effectiveness of
security measures. Managers use the results of a risk assessment to develop security
requirements and specifications.
 Le processus de l'évaluation des menaces et des vulnérabilités, connues et hypothétiques, pour
déterminer la perte attendue et d'établir le degré d'acceptabilité pour les opérations du système.
 Une identification des actifs d'une installation spécifique ADP, les menaces qui pèsent sur ces
actifs, et la vulnérabilité de l'installation ADP à ces menaces.
 • Une analyse des actifs et des vulnérabilités système pour établir une perte attendue de certains
événements sur la base de probabilités estimées de la survenance de ces événements. Le but
d'une évaluation des risques est de déterminer si les contre-mesures sont adéquates pour réduire
la probabilité de perte ou de l'impact de la perte à un niveau acceptable.
 Un outil de gestion qui fournit une approche systématique pour déterminer la valeur relative et la
sensibilité des actifs d'installation de l'ordinateur, l'évaluation des vulnérabilités, l'évaluation des
niveaux d'exposition aux risques perçus espérance de perte ou, l'évaluation des fonctions de
protection existantes et alternatives de protection supplémentaires ou l'acceptation des risques et
la documentation des décisions de gestion. Les décisions de mise en œuvre des fonctions de
protection supplémentaires sont basés sur l'existence d'un ratio raisonnable entre le coût /
bénéfice de la sauvegarde et de la sensibilité / valeur des actifs à protéger
 ISO 27005 framework
Risk assessment receives as input the output of the previous step Context establishment; the output is the
list of assessed risks prioritized according to risk evaluation criteria. The process encompasses these
steps:
Risk analysis=Risk identification+Risk estimation+Risk evaluation
The ISO/IEC 27002:2005 Code of practice for information security management recommends the following
be examined during a risk assessment:
 politique de sécurité,
 • organisation de la sécurité de l'information, la gestion d'actifs,

34
 • la sécurité des ressources humaines,
 • la sécurité physique et environnementale,
 • communications et la gestion des opérations, le contrôle d'accès,
 • l'acquisition de systèmes d'information, le développement et la maintenance,
 • informations gestion des incidents de sécurité,
 • gestion de la continuité des affaires et
 • la conformité réglementaire.
 • L'identification des risques
L'identification des risques indique ce qui pourrait provoquer une perte potentielle; les
suivantes sont à identifier:
(1-assets, primary (i.e. Business processes and related information) and supporting (i.e. hardware,
software, personnel, site, organization structure) 2-threats 3 -existing and planned security measures 4-
vulnerabilities 5-consequences 6-related business processes)
The output of sub process is made up of:
 The list of asset and related business processes to be risk managed with associated list of threats,
existing and planned security measures
 list of vulnerabilities unrelated to any identified threats
 list of incident scenarios with their consequences.
Estimation du Risque
Il existe deux méthodes d’évaluation des risques en sécurité informatique : qualitative et quantitative.
Purely quantitative risk assessment is a mathematical calculation based on security metrics on
the asset (system or application). For each risk scenario, taking into consideration the different risk
factors a Single loss expectancy(SLE) is determined. Then, considering the probability of occurrence on a
given period basis, for example the annual rate of occurrence (ARO), the Annualized Loss Expectancy is
determined as the product of ARO X SLE. It is important to point out that the values of assets to be
considered are those of all involved assets, not only the value of the directly affected resource.
For example, if you consider the risk scenario of a Laptop theft threat, you should consider the value of the
data (a related asset) contained in the computer and the reputation and liability of the company (other
assets) deriving from the lost of availability and confidentiality of the data that could be involved. It is easy
to understand that intangible assets (data, reputation, liability) can be worth much more than physical
resources at risk (the laptop hardware in the example). Intangible asset value can be huge, but is not easy
to evaluate: this can be a consideration against a pure quantitative approach.
L’Atténuation des risques est une méthodologie systématique utilisée par la direction
pour réduire la survenance du risque
 Risk mitigation can be achieved through any of the following risk mitigation options:
 Risk Assumption. To accept the potential risk and continue operating the IT system or to implement
controls to lower the risk to an acceptable level

35
 Risk Avoidance. To avoid the risk by eliminating the risk cause and/or consequence (e.g., forgo
certain functions of the system or shut down the system when risks are identified)
 Risk Limitation. To limit the risk by implementing controls that minimize the adverse impact of a
threat’s exercising a vulnerability (e.g., use of supporting, preventive, detective controls)
 Risk Planning. To manage risk by developing a risk mitigation plan that prioritizes, implements, and
maintains controls
 Research and Acknowledgement. To lower the risk of loss by acknowledging the vulnerability or
flaw and researching controls to correct the vulnerability
 Risk Transference. Prendre une assurance pour compenser une perte éventuelle
 To transfer the risk by using other options to compensate for the loss, such as purchasing
insurance.
Le référentiel Val IT est un ensemble structuré de pratiques clés de management liées à la gouvernance
des SI. Cette dernière comporte deux volets : un aspect risques, qui conduit à des pratiques d'audit et à
des référentiels de bonnes pratiques comme CobiT. Et un aspect performance peu outillé au début des
années 2000.
Les concepteurs du référentiel CobiT (l'ISACA et son chapitre français l'AFAI), rapidement relayés par la
structure ITGI (IT Governance Institute, associée en France à l'IGSI ou Institut de Gouvernance du SI,
hébergé par le CIGREF) ont donc tenté de compléter leur approche initiale en proposant un cadre
d'analyse de la performance des investissements en technologies de l'information. Un volet consacré à la
sécurité et dénommé Risk IT est censé compléter le triptyque.
Val IT offre à la Direction de l'organisation un ensemble de préconisations lui permettant d'évaluer et
sélectionner les projets de développement du système d'information en fonction de leur valeur, d'une part,
d'anticiper puis de suivre leur cycle de vie du point de vue économique ensuite et, par retour d'expérience,
d'améliorer les méthodes employées pour l'évaluation a priori des nouveaux projets, dénommées dans ce
référentiel business cases.
Objectifs et développement du référentiel
Le concept Val IT prend racine dans les travaux de l'AFAI du début des années 2000 visant à adapter
certains concepts issus du tableau de bord prospectif (balanced Scorecard) à l'évaluation de la
performance des systèmes d'information et à leur apport à la création de valeur par l'entreprise. Le
problème de management à résoudre est le suivant :
Rapport du Standish Group, 50% des projets informatiques soit (4100) ne donnent pas les résultats
attendus en termes de délais, coûts et fonctionnalités, quand il ne s'agit pas d'échecs purs et simples.
Souvent, les justifications économiques (business cases) accompagnant un projet de développement du
SI, porté soit par une direction opérationnelle soit par le direction des SI, sont incomplètes voire
inexistantes.
Dans les grandes structures plus de 100 projets doivent être simultanément sélectionnés puis suivis ce qui,
en l'absence d'outils, limite l'efficacité du contrôle que devrait exercer la Direction Générale.

36
On parle de trois domaines et de processus au lieu de processus et des pratiques de la version 1. Les
pratiques sont prises comme sous-ensembles des nouveaux processus.
Les domaines du CoBIT
La gouvernance de la valeur ( GV ou Value Governance) a pour objectif de s'assurer que le concept de
valeur est présent dans les pratiques de management de façon à assurer la cohérence avec les pratiques
globales de gouvernance, à organiser le processus de décision, à fournir des directions et des indicateurs
de choix des projets en portefeuille et à assurer l'apprentissage organisationnel par la vérification de
l'atteinte des objectifs sur les projets terminés. Les processus de la version 2.0 sont :
i. VG1 : établir un leadership informé et impliqué,
ii. VG2 : définir et mettre en place les processus
iii. VG3 : définir les caractéristiques des différents portefeuilles de projets (composition, poids
relatifs...),
iv. VG4 : aligner et intégrer la gestion de la valeur dans la gestion financière de l'entreprise,
v. VG5 : établir une surveillance efficace de la gouvernance (et identifier les dérives),
vi. VG6 : mettre en place un processus d'amélioration continue des pratiques.
La gestion de portefeuille (GP, ou PM pour Portfolio Management) vise à optimiser la création de valeur à
travers la construction du portefeuille d'investissement. Il faut, notamment, identifier les ressources
nécessaires à chaque projet, définir les seuils d'investissement, évaluer, classer puis sélectionner (ou
rejeter) les projets à lancer, gérer globalement le portefeuille d'investissements en termes de risques et
rentabilité, surveiller les performances et en rendre-compte. Les processus composant GP sont :
i. PM1 : établir une stratégie claire et définir la structure de la cible en termes d'investissements,
ii. PM2 : déterminer les sources et la disponibilité des budgets,
iii. PM3 : gérer la disponibilité des ressources humaines,
iv. PM4 : évaluer et sélectionner les programmes à financer,
v. PM5 : monitorer et rendre compte de la performance des portefeuilles d'investissement,
vi. PM6 : optimiser la performance des portefeuilles par une revue régulière des opportunités et
risques.
Enfin, la gouvernance des investissements (GI ou IM pour Investment Management) vise à assurer la
rentabilité de chaque investissement ou "programme" lié aux technologies de l'information (IT
Enabled), pris isolément. Il s'agit d'améliorer les compétences des managers opérationnels dans : a)
l'identification des exigences de leur métier, b) la capacité d'apprécier les approches alternatives, c) la
définition, rédaction et maintien des business cases détaillés au long de la vie du projet, d) l'affectation des
responsabilités et de la propriété du projet, e) de la gestion du cycle de vie complet du programme, retrait
inclus, f) du suivi régulier de la performance et des comptes-rendus. On note :
i. IM1 : développer et évaluer le business case initial du programme,
ii. IM2 : comprendre les implications des candidats-programmes,
iii. IM3 : développer le plan du programme,
iv. IM4 : préparer le budget sur le cycle de vie complet,

37
v. IM5 : construire le business case complet, détaillé,
vi. IM6 : lancer le programme et gérer sa vie,
vii. IM7 : mettre à jour les portefeuilles opérationnels,
viii. IM8 : mettre à jour le business case à mesure de l'acquisition d'informations nouvelles,
ix. IM9 : monitorer le programme et rendre-compte,
x. IM10 : procéder au retrait du programme en fin de vie.
Le business case
i. Quatre questions guident la construction du business case (4 Ares en anglais):
ii. Faisons-nous les choses appropriées (are right things) ?
iii. Faisons-nous les choses de façon appropriée (are the right way) ?
iv. Les tâches sont-elles effectuées correctement (are done well) ? Planification, budgets...
v. En tirons-nous les bénéfices attendus ?
Le business case contient donc des éléments sur les résultats attendus (outcomes), aussi bien immédiats
que différés, sur les actions (initiatives) et leurs impacts directs sur les résultats, les contributions ou
impacts indirects croisés entre actions et résultats de nature différente et, enfin, les hypothèses sous-
jacentes aux points précédents et qui permettent d'évaluer le risque du programme. La construction
du business case comporte 8 phases dont 4 peuvent être menées en parallèle :
 Collation de toutes les informations jugées pertinentes sur le programme,
 Analyse de l'alignement stratégique (objectifs du programme rapportés à la stratégie de
l'organisation), en parallèle avec la détermination des bénéfices financiers, des bénéfices non
financiers (image...) et une analyse des risques du projet.
 Approbation des éléments et optimisation en termes rendement - risques.
 Enregistrement des résultats d'analyse et rédaction de la documentation du cas.
 Revue régulière du cas pendant toute l'exécution du programme, en tenant compte de tous ses
impacts, y compris retardés.
Les quatre questions à se poser lors de sa création du SI
Les questions fondamentales
1. La question stratégique : Faisons-nous ce qu’il faut ?
2. L’investissement : 1- se conformer à notre vision, 2-correspondre aux enjeux métier, 3-contribuer à
l’atteinte des objectifs stratégiques 4 créer la valeur optimale à moindre coût avec peu de risques
3. La question architecture : Le faisons-nous comme il faut ?
4. L’investissement : 1-doit être conforme à architecture, 2-correspondre aux principes d’architecture,
3-contribuer valoriser notre architecture 4 être conforme aux architectures
À propos de la valeur fournie par les SI
 La question de la réalisation : Le faisons-nous faire comme il faut ?
Disposons-nous :
 D’un management efficace et rigoureux

38
 De processus de gestion des réalisations et des modifications efficace
 De moyen techniques et métier suffisants et disponibles pour proposer les compléments
nécessaires
 La question de la valeur, les bénéfices sont :
 Une compréhension claire et partagée des bénéfices attendus
 Des responsabilités « métier » clairement établies pour la réalisation des bénéfices
 Des métriques pertinentes
 Un processus de réalisation de bénéfices efficaces
Limites
Enfin, L'éditeur Microsoft a récemment publié un comparatif de son propre référentiel MOF (Microsoft
Operations Framework) avec le couple CobiT / Val IT : on y détaille l'impact des deux approches sur le
succès des projets de développement en termes de gouvernance, maîtrise des risques et conformité.

39
VII. BENCHMARKING DE LA GOUVERNANCE SI
 La mise en œuvre de la gouvernance des SI repose sur l'application d'un certain nombre de
bonnes pratiques réparties en 04 domaines comme suit :
 La conception, Le fonctionnement et le pilotage des SI,
 Le pilotage des évolutions des SI, L'évolution des SI.
Ces bonnes pratiques sont par exemple :
 Un SI conçu par un professionnel (architecte ou un maître d'ouvrage). C'est un travail de
conception ou de re-conception de l'organisation.
 Un SI doit permettre d’augmenter les volumes traités et de réduire les coûts unitaires des
opérations.
 Un SI doit être piloté par un responsable qui doit avoir une autorité suffisante pour prendre les
mesures qui s'imposent. C'est particulièrement le cas d'un SI concernant un processus.
 Chaque SI doit disposer d'un tableau de bord permettant de suivre les évolutions et le cas échéant
de prendre des mesures correctrices.
Un suivi des anomalies constatées dans le cadre de l'utilisation normale du SI doit permettre de répertorier
les dysfonctionnements et de les corriger en appliquant des règles de contrôle interne.
 Piloter les évolutions du SI et les planifier dans le temps pour éviter des changements difficiles à
gérer.
 La connaissance de ces bonnes pratiques permet d'évaluer le degré de maturité d'un système
d'information et d'établir un plan d'action adapté. Cette démarche repose sur les étapes suivantes :
 Effectuer un audit du système d'information.
 Identifier les actions possibles. Déterminer les priorités.
 Fixer les responsabilités et les budgets d’investissement

40
VIII. GESTION DE LA PERFORMANCE
Introduction
La gestion de la performance permet aussi aux organisations de mieux communiquer leurs buts communs
et opérationnels. En effet, lorsque la performance atteint son plus haut niveau, l’entreprise peut bénéficier
d’une panoplie d’avantages tels qu’une augmentation du revenu de l’organisation, une amélioration des
liens interpersonnels entre les membres ainsi que la simplification des tâches des dirigeants en implantant
un système de contrôle. De plus lorsqu'une entreprise réalise une augmentation importante de ses
revenus, il est évident que tous ses membres peuvent y bénéficier.
 Le lien entre la performance de l’organisation et la performance individuelle est crucial.
 Prenez l’autoroute de l’exécution du haut vers le bas et du bas vers le haut.
 L’histoire de l'exécution de la stratégie ne finit jamais.
 Faites votre stratégie facile à retenir ... et à communiquer!
 Le manager, un vrai héro de la performance
Figure 8 Top trois des objectifs sont liés aux priorités des clients des entreprises performantes
Figure 9top three objectives are related to customers priorities of the high performers
Figure 10 les entreprises les plus performantes sont en transition du cloud privé et public

41

42
IX. La sécurité des SI (SSI)
C’est l’ensemble des moyens techniques, organisationnels, juridiques et humains nécessaire et mis en
place pour conserver, rétablir, et garantir la sécurité du SI, une activité qui incombe au management du SI
Enjeux de la sécurité des SI
« Le SI représente un patrimoine essentiel de l'organisation, qu'il convient de protéger. La sécurité
informatique consiste à garantir que les ressources matérielles ou logicielles d'une organisation sont
uniquement utilisées dans le cadre prévu "
Plusieurs types d'enjeux doivent être maîtrisés :
 L'intégrité : Les données ne doivent pas être altérées de façon fortuite, illicite ou malveillante.
 La confidentialité : Seule les personnes autorisées ont accès aux informations
 La disponibilité : Le système doit fonctionner sans faille durant les plages d'utilisation prévues,
garantir l'accès aux services et ressources installées avec le temps de réponse attendu.
 La non-répudiation et l'imputation : Aucun utilisateur ne doit pouvoir contester les opérations qu'il a
réalisées dans le cadre de ses actions autorisées, et aucun tiers ne doit pouvoir s'attribuer les
actions d'un autre utilisateur.
 L'authentification : L'identification des utilisateurs est fondamentale pour gérer les accès aux
espaces de travail pertinents et maintenir la confiance dans les relations d'échange.
La sécurité informatique est un défi d'ensemble qui concerne une chaîne d'éléments : les infrastructures
matérielles de traitement ou de communication, les logiciels (systèmes d'exploitation ou applicatifs), les
données, le comportement des utilisateurs. Le niveau global de sécurité est fonction du niveau de sécurité
du maillon le plus faible, les précautions et contre-mesures doivent être envisagées en fonction des
vulnérabilités propres au contexte auquel le SI est censé apporter service et appui.
Deux types de dommages peuvent affecter le SI d'une organisation:
Les dommages financiers directs (reconstitution des bases de données qui ont disparu, reconfigurer un
parc de postes informatiques, réécrire une application) ou indirects (par exemple, le dédommagement des
victimes d'un piratage, le vol d'un secret de fabrication ou la perte de marchés commerciaux. Un Exemple
concret (relativement difficile de les estimer), des sommes de l'ordre de plusieurs milliards USD ont été
avancées suite à des dommages causés par des programmes malveillants comme le ver Code Red..
La perte ou la baisse de l'image de marque. Perte directe par la publicité négative faite autour d'une
sécurité insuffisante (cas de l'hameçonnage par exemple) ou perte indirecte par la baisse de confiance du
public dans une société. Par exemple, les techniques répandues de dé-facement (une refonte d'un site
web) permettent à une personne mal intentionnée de mettre en évidence des failles de sécurité sur un
serveur web.
Les conséquences peuvent aussi concerner la vie privée d'une ou plusieurs personnes, (ses coordonnées
bancaires, photos, ses codes confidentiels). De manière générale, la préservation des données relatives
aux personnes fait l'objet d'obligations légales régies par la Loi Informatique et Libertés.

43
Pour parer ces éventualités, les responsables de SI se préoccupent depuis longtemps de sécuriser les
données. Le cas le plus répandu, et sans aucun doute précurseur en matière de sécurité de l'information,
reste la sécurisation de l'information stratégique et militaire : Le DoD12 des États-Unis est à l'origine
du TCSEC, ouvrage de référence en la matière. De même, le principe de sécurité multi-niveau trouve ses
origines dans les recherches de résolution des problèmes de sécurité de l'information militaire.
Démarche générale
Pour sécuriser les systèmes d'information, la démarche consiste à :
 évaluer les risques et leur criticité : quels risques et quelles menaces, sur quelle donnée et quelle
activité, avec quelles conséquences ?
 On parle de « cartographie des risques ». De la qualité de cette cartographie dépend la qualité de
la sécurité qui va être mise en œuvre.
 rechercher et sélectionner les parades : que va-t-on sécuriser, quand et comment ?
 Etape difficile des choix de sécurité : dans un contexte de ressources limitées
 mettre en œuvre les protections, et vérifier leur efficacité.
Méthodes d'attaque portant atteinte à la sécurité du SI
 Destruction de matériels ou de supports
 Sabotage : Rayonnements électromagnétiques
 Brouillage : Écoute passive
 Vol de matériels : Analyse de supports recyclés ou mis au rebut : ".Divulgation
 Hameçonnage ou filoutage (Phishing) : désigne l'obtention d'information confidentielle en
prétextant une fausse demande ou en faisant miroiter un pseudo-avantage auprès d'un utilisateur
ciblé.
 Chantage : menace exercée vis-à-vis d'une personne privée ou d'une organisation en vue
d'extorquer une information "sensible".
 Émission d'une information sans garantie d'origine, Canular (Hoax)
 Bombe : Programme dormant dont l'exécution est conditionné par l'occurrence d'un trigger ou date
 Virus : Programme malicieux capable de faire fonctionner des actions nuisibles pour le SI , et
éventuellement de se répandre par réplication à l'intérieur d'un SI.
 Ver : pour perturber et saturer les réseaux
 Piégeage du logiciel : Des fonctions cachées sont introduites à l'insu des utilisateurs à l'occasion
de la conception, fabrication, transport ou maintenance du SI
 Exploitation d'un défaut (bug) : Les logiciels - en particulier les logiciels standards les plus
répandus- comportent des failles de sécurité qui constituent autant d'opportunité d'intrusion
indésirables
 Cheval de Troie : C'est un programme ou un fichier introduit dans un SI et comportant une
fonctionnalité cachée connue seulement de l'agresseur.
12
Department of Defense

44
 Réseau de robots logiciels (Botnet) : Les robots (nombreux) se connectent sur des serveurs IRC
(Internet Relay chat) au travers desquels ils peuvent recevoir des instructions de mise en œuvre
de fonctions non désirées.( envoi de spams, vol d'information, participation à des attaques de
saturation ...)
 Logiciel espion (spyware): est installé sur une machine dans le but de collecter et de transmettre à
un tiers des informations sans que l'utilisateur en ait connaissance.
 facticiel: logiciel factice disposant de fonctions cachées
 Saturation du Système informatique
 Perturbation : Vise à fausser le comportement du SI ou à l'empêcher de fonctionner comme prévu
(saturation, dégradation du temps de réponse, génération d'erreurs)
 Saturation : Attaque contre la disponibilité visant à provoquer un déni de service (remplissage forcé
d'une zone de stockage ou d'un canal de communication)
 Pourriel (spam) : Envoi massif d'un message non sollicité vers des utilisateurs n'ayant pas
demandé à recevoir cette information. Cet usage contribue cependant à la pollution et à la
saturation des systèmes de messagerie.
 Faufilement : Cas particulier où une personne non autorisée franchit un contrôle d'accès en même
temps qu'une personne autorisée.
Évaluation des risques
Tenter de sécuriser un SI revient à essayer de se protéger contre les menaces intentionnelles et d'une manière plus
générale contre tous les risques pouvant avoir un impact sur la sécurité de celui-ci, ou des informations qu'il traite.
Méthodes d'analyse de risque
Différentes méthodes d'analyse des risques sur le SI existent. Voici les trois principales méthodes
d'évaluation disponibles sur le marché français :
 la méthode EBIOS (Expression des besoins et identification des objectifs de sécurité), développée
 par l'Agence nationale de la sécurité des systèmes d'information (ANSSI) ;
 la méthode MEHARI (Méthode harmonisée d'analyse des risques), développée par le CLUSIF ;
 la méthode OCTAVE (Operationally Critical Threat, Asset, and Vulnerability Evaluation),
développée par l'Université de Carnegie Mellon (USA).
Informations sensibles
Avant de tenter de se protéger, il convient de déterminer quelles sont les informations sensibles de
l'entreprise, qui peuvent être des données, ou plus généralement des actifs représentés par des données.
Chaque élément pourra avoir une sensibilité différente.
Les actifs contiennent aussi et surtout le capital intellectuel de l'entreprise, qui constitue un patrimoine
informationnel à protéger. Il faut évaluer les menaces et déterminer les vulnérabilités pour ces éléments
sensibles.
Critères de sécurité

45
La sécurité peut s'évaluer suivant plusieurs critères :
 Disponibilité : garantie d’accessibilité des données par les personnes autorisées.
 Intégrité : garantie que les éléments considérés sont exacts et complets.
 Confidentialité : garantie que seules les personnes autorisées ont accès aux éléments
considérés.
 Traçabilité (ou « Preuve ») : garantie que les accès et tentatives d'accès aux éléments considérés
sont tracés et que ces traces sont conservées et exploitables.
 Une fois les éléments sensibles déterminés, les risques sur chacun de ces éléments peuvent être
estimés en fonction des menaces qui pèsent sur les éléments à protéger. Il faut pour cela estimer :
 la gravité des impacts au cas où les risques se réaliseraient,
 la vraisemblance des risques (ou leur potentialité, ou encore leur probabilité d'occurrence).
 Dans la méthode EBIOS, ces deux niveaux représentent le niveau de chaque risque qui permet de
les évaluer (les comparer).
 Dans la méthode MEHARI, le produit de l'impact et de la potentialité est appelé « gravité ».
D'autres méthodes utilisent la notion de « niveau de risque » ou de « degré de risque ».
i. Menaces
Les principales menaces auxquelles un SI peut être confronté sont :
 un utilisateur du système /personne malveillante
 un programme malveillant :
 un sinistre (vol, incendie, dégât des eaux)
ii. Objectifs
Une fois les risques énoncés, il est souhaitable de déterminer des objectifs de sécurité. Ces objectifs sont
l'expression de l'intention de contrer des risques identifiés et/ou de satisfaire à des politiques de sécurité
organisationnelle. Un objectif peut porter sur le système cible, sur son environnement de développement
ou sur son environnement opérationnel. Ces objectifs pourront ensuite être déclinés en fonctions de
sécurité, qui sera implémentée sur SI.
Moyens de sécurisation d'un système
 Conception globale
La sécurité d'un SI peut être comparée à une chaîne de maillons plus ou moins résistants. Elle est alors caractérisée
par le niveau de sécurité du maillon le plus faible et repose sur :
 la sensibilisation des utilisateurs aux problématiques de sécurité, (en awareness) ;
 la sécurité de l'information ;
 la sécurité des données (très fondamentale), (d’interopérabilité, cohérence des données en univers
réparti ;)

46
 la sécurité des réseaux ; des systèmes d'exploitation , des télécommunications
 la sécurité des applications (dépassement de tampon),
 la sécurité physique, soit la sécurité au niveau des infrastructures matérielles
 Politique de sécurité.
La sécurité des SI se cantonne généralement à garantir les droits d'accès aux données et ressources d'un
système, en mettant en place des mécanismes d'authentification et de contrôle. Ces mécanismes
permettent d'assurer que les utilisateurs des dites ressources possèdent uniquement les droits qui leur ont
été octroyés.
La sécurité informatique permet aux utilisateurs d’être à l’aise cela présuppose une politique de sécurité,
ie :
 élaborer des règles et des procédures, installer des outils techniques dans les différents services
de l'organisation (autour de l'informatique) ;
 définir les actions à entreprendre et les personnes à contacter en cas de détection d'une intrusion ;
 sensibiliser les utilisateurs aux problèmes liés à la sécurité des systèmes d'informations ;
 préciser les rôles et responsabilités.
La politique de sécurité est donc l'ensemble des orientations suivies par une entité en matière de sécurité
élaborée au niveau de la direction de l'organisation concernée, car elle concerne tous les utilisateurs du
système.
 Responsable de la sécurité du SI
En France, ce sont les grandes sociétés, entreprises du secteur public et administrations qui ont désigné et
emploient, des « responsables de la sécurité des SI ». Peu à peu, le management de la sécurité
informatique s'organise en domaines ou sous-domaines des services informatiques ou d'état-major ; ils
sont dotés de moyens financiers et humains et intègrent les contrats de plan ou de programmes de
l'entreprise.
 Modèles formels de sécurité
Afin d'atteindre une cible d'évaluation avec un bon degré de confiance (niveau E4 de TCSEC au minimum),
nous définissons formellement le concept de sécurité dans un modèle dont les objectifs sont les suivants :
 exprimer les besoins de sécurités intégrées dans un contexte informatique,
 fournir des moyens pour justifier que le modèle est cohérent,
 fournir des moyens permettant de convaincre que les besoins sont satisfaits,
 fournir des méthodes permettant de concevoir et d'implanter le système.
 Il existe plusieurs modèles formels de sécurité :

Informatisation de projets

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à Informatisation de projets

Similaire à Informatisation de projets (20)

Dernier

Dernier (19)

Informatisation de projets