Audit des projets informatiques

1

Système de développement d’application, acquisition,

implémentation et maintenance

Cycle de Préparation au C.I.S.A

Mohamed SAÂDI.T.M et consultant en Systèmes d’Information

2

SOMMAIRE

I- Développement d’applications informatiques Approche traditionnelle SDLC Rôles et responsabilités des groupes et des individus Risques associés au développement logiciel Utilisation des techniques d’analyse, de conception et de

développement Description des phases du SDLC Méthodologies de développement du logiciel

Systèmes de développement Orientés Objet Prototypage RAD AGILE Reengineering Reverse Engineering

II- Pratiques de maintenance des systèmes d’information Gestion du changement Management de la configuration Contrôle de la librairie logicielle

III- Pratiques de management des projets

3

SOMMAIRE

IV- Pratiques d’amélioration des processus de développement du logiciel

ISO 9126 SPICE CMM CMMI

V- Audit des systèmes de développement, de l’acquisition et de la maintenance

Gestion des projets Étude de faisabilité Expression des besoins Processus d’acquisition logiciel Étude détaillé et les phases de développement Phase de tests Phase implémentation Revue de l’implémentation Procédures de changement et processus de migration

4

Gérer c’est: Organiser Planifier Contrôler Coordonner Diriger Communiquer Décider Déléguer Négocier

I- La gestion de projets

5

Ensemble de processus permettant de maîtriser la réalisation d’un projet et de la mener à terme :

Découpage et description du projet en :processus,phases,étapes.

Définition claire des entrées des processus, des phases et étapes, des productions attendues et des conditions de passage d’une phase à l’autre.

Répartition claire du rôle et des responsabilités des acteurs

I- La gestion de projets

6

Caractéristiques d’un projet

Implique le changement. Possède un début et une fin. Requiert des activités. Implique des individus. Fait dans un but précis. Destiné à un ou plusieurs clients

7

Caractéristiques d’un projet

Gérer un projet: C'est gérer le changement

8

Facile ?

« Il n ’y a rien de plus risqué, de plus difficile à planifier et de plus dangereux à gérer que l’implantation d ’un nouveau système ! »

Résistance acharnée de tous ceux qui auraient quelque chose à perdre par l ’implantation du nouveau système

Soutien mitigé de tous ceux qui auraient quelque chose à gagner

9

Les différents points de vue

Différents besoins et points de vue : Le client, Les utilisateurs, L’équipe,

Le chef de projet doit les comprendre et essayer de les satisfaire

10


Client : Livraison rapide Peu coûteux Fonctions nécessaires

Utilisateurs : Beaucoup de fonctions Convivialité Fiabilité Performance

11


L’équipe : Les responsables :

haute qualitérespect des délaisrespect des budgetsaucune surprise

Les développeurs :travail motivantanalyse seulementplan de carrière

12


L’équipe : les opérateurs de maintenance :

facilité d’opération,facilité de maintenance,fiabilité,documentation,respect des standards.

13

La confrontation

Perceptions Attentes Réalités

14

Les principaux apports de la gestion de projets

Suivi de projets plus efficace Prise en compte des risques au plus tôt Mise en évidence des bénéfices Gestion des points en suspens Gestion des demandes de changement

15

Les enjeux de la gestion de projets

Le succès, l’échec d ’un projet repose sur : La compréhension des processus de l’activité Une définition claire du périmètre Un contrôle permanent des résultats attendus et une vision

globale du «comment le projet est réalisé» Une bonne anticipation et gestion des risques Une gestion rigoureuse des changements Une structure clairement définie : gestion, décision,

communication

16

Impacts

Les coûts Les délais La qualité L’image de l’Entreprise La compétitivité Les ressources humaines

17

Les processus et les Les processus et les activitésactivités

18

Processus de lancement Processus d’évolution du système d’information

Processus d’évolution du système informatique

1Organisation

2Opportunité

EtLancementDu projet

3Élaboration

D’une solution-Solution avec progiciel-Solution spécifique

Intégration etIndustrialisation

Du systèmeinformatique

4Mise en oeuvre

5 Conduite du changement

6 Management de l’équipe projet et Gestion de projet

7 Assurance et maîtrise de la Qualité

8 Urbanisme du Système d’Information

Les Processus

19

Activités supports

Suivi de projet : ensemble des moyens et des actions qui permettent de mesurer ce qui a été fait et d’évaluer ce qui reste à faire

Rédaction et suivi des contrats, relation avec les utilisateurs

Estimation des charges, planification Organisation des équipes

20

Activités supports

Gestion de la qualité : Spécifications des caractéristiques de qualité Dispositions préventives Procédures de contrôle

21

Activités supports

Gestion de la documentation : Conception et mise à jour des règles :

identificationstructuration

Production et diffusion.

Gestion de la configuration : Identification et gestion des composants et des

configurations :constitution de versions sur la base des composantsbibliothécaire de projet

Maîtrise des modifications

22

Activités supports

Vérification : Revue de fin de phase Tests d’intégration Inspection de code

Validation : Cycle de validation Recette définitive

23

Les projetsLes projets

24

Différentes tailles de projets

Petits projets : Quelques personnes Moins de 30 mois/homme Environnement familier

Moyens projets : 5 à 10 personnes en pointe De 30 à 100 mois/homme

25

Différentes tailles de projets

Grands projets : Plus d'une dizaine de personnes en pointe, Plus d’un niveau hiérarchique, Accent mis sur la gestion de projet, De 100 à 1000 mois/hommes.

Très gros projets : Au moins 40 personnes en pointe, Plus de 1000 mois/hommes, Accent mis sur l’assurance qualité, Plus le projet est important, plus les exigences en matière de

pilotage et de qualité seront fortes.

26

Différents types de projet

Projet de gestion Projet système Développement d’un progiciel Projet de maintenance…

27

Différents types de projet

Différences : Corps de métier Répartition du temps par phase Répartition des activités

Identique : Problèmes humains Processus supports

28

La maîtrise d’ouvrage

Donne son accord sur l’opportunité du projet, S'assure du financement du projet, Met en place les structures de pilotage, Définit les objectifs du projet et les besoins

fonctionnels en regard de ces objectifs, Fixe le cadre des travaux confiés au maître d'œuvre, Effectue la recette définitive des prestations fournies

par le maître d'œuvre

29

La maîtrise d’ouvrage

Pilote la conduite du changement : Organiser et suivre les actions de communication formation, et production de la documentation Et y participer le cas échéant

Pilote les actions de sous-traitance

NB : Certaines tâches peuvent être sous-traitées par la maîtrise d'ouvrage : aide à la rédaction de la définition des besoins et à la rédaction du cahier des charges; assistance à la réception du produit; pilotage des actions de conduite du changement, de communication et de formation

30

La maîtrise d’œuvre

Responsable de la réalisation des travaux qui lui ont été confiés par la maîtrise d ’ouvrage

31

La maîtrise d’œuvre

Constitue l’équipe projet et désigne le chef de projet, Assure la gestion de projet (ordonnancement,

estimation, planification des tâches, gestion des risques et suivi du projet)

Participe à la synthèse des besoins et réalise les travaux d'étude

Réalise l'intégration du système (tests unitaires et d'intégration),

Gère le contrôle qualité Rend compte à la maîtrise d'ouvrage de l'avancement

du projet et lui soumet les éléments de choix relevant de sa compétence

32

Points importantsPoints importants

33

La méthode

Tout développement de projet nécessite une méthode Le suivi opérationnel des projets s’appuie sur la

méthode

34

La méthode

Elle recouvre deux aspects : Une démarche de développement (cycle de vie et cycle de

décision) :phasesétapeslivrables

Une technique de conception.modélisation

35

La méthode

Trois grandes approches de développement: Une approche spécifique pour les développements sur

mesure Une approche progiciel comprenant deux étapes

successives:évaluation, sélection et conception de l'intégration dans

l'environnement fonctionnel et technique de l'entrepriseinstallation, adaptation, paramétrage, réalisation et mise en

œuvre Le développement itératif pour satisfaire un besoin mal

connu et/ou peu formalisé. Démarche cyclique de prototypage, validation et mise en œuvre

36

Panorama des méthodes

Exemples: Merise (Sema) Axial (IBM) RAD (James Martin) SDM/S (CEGELOG/AGS Management Systems Inc.) MCP (Warnier) Méthodes objets : UML

37

MERISE AXIAL SDM/S MCP

Schéma Directeur

Étude préalable

Étude détaillée

Étude technique

Réalisation

Mise en oeuvre

Diagnostic

Schéma directeur

Conception Fnelle

Conception Technique

Étude de migration

Plan de mise en oeuvre

Évaluation économique

Conception détaillée

Réalisation et tests

Mise en production

Détermination des besoins

Chois d’architecture système

Spécif Externes

Spécif Interne

Programmation

Tests

Intégration

Recette

Généralisation

Maintenance

Exp. Des besoins

Étude d’opportunité

Étude du S.I

Élaboration du C.des charges

Étude du S.I

Programmation et essais

Réception provisoire

Lancement sous contrôle

Évaluation de l’application

Évaluation du projet

Comparaison des phases selon les méthodes

38

Les méthodes: quelques recommandations

Adopter une démarche et s’y tenir : Choisir un cadre de référence (méthodes du marché et méthodes "maisons" Définir processus, activités, tâches, documentation,rôles et

acteurs Avoir la volonté d’appliquer la démarche

Pas de règle miracle : Pragmatisme Bon sens

39

Méthodes Méthodes d’estimation des d’estimation des

chargescharges

40

Estimation des charges

Répond à un besoin de prévision de durée, du coût et de la répartition de l’effort à fournir (j/h) et permet de :

Faire une estimation de la rentabilité de l’investissement Évaluer une durée vraisemblable du projet Prévoir l’ordonnancement des étapes Prévoir les ressources (affectation des personnes)

41

Estimation des charges

Besoins d’estimation à différents niveaux : Projet : durée, budget, rentabilité Phase : ajuster le découpage, décision de sous-

traiter,prévoir les délais, les ressources Étape : planification, suivi du projet pour surveiller les

écarts, affecter les ressources Tâche : planification fine pour suivre les équipes

42

Différentes Différentes méthodes méthodes

d’estimationd’estimation

43

Familles de méthodes

Il existe plusieurs familles de méthodes d'estimation: Modèles algorithmiques (coût fonction de variables) Jugement d'experts Analogie (référence à d'autres projets similaires) Estimation globale puis décomposition Décomposition (estimation individuelle détaillée puis

agrégation)

44

Estimations: Modèles algorithmiques

Principe Consiste à estimer à l'aide de fonctions mathématiques des

variables jugées significatives. Avantages :

Objectif, Reproductible, Simple, Expérimental.

Inconvénients : Entrées subjectives, Prise en compte des cas exceptionnels, Il existe de nombreux

Modèles, lequel choisir ?

45

Estimations: Jugement d’experts

Principe Estimation par des experts :

Soit individuellement,Soit en groupe avec une méthode de consensus.

Avantages : Prise en compte globale du contexte et des situations

exceptionnelles.

Inconvénients : Estimation subjective en fonction des experts, Non reproductible.

46

Estimations: Analogie

Principe : Basé sur les résultats de projets comparables Mise en évidence des différences Évaluation des écarts

47

Estimations: Analogie

Avantages : Capitalisation sur l'expérience Bonne prise en compte du contexte Réutilisation possible de composants

Inconvénients : Degré de signification des projets passés Prise en compte des situations exceptionnelles

48

Estimations: Globale

Principe : Estimation globale partir des propriétés globales du

processus et du produit Obtention d'une catégorie de projet parmi n à partir des

propriétés globales (Matrice des familles de projet en charge et délai)

Avantages : On n'oublie pas les éléments communs

Inconvénients : Ne met pas en évidence les problèmes de détail

49

Estimations: Décomposition

Principe de la décomposition analytique Estimation individuelle de chacun des éléments analytiques

(par activité et tâche) à partir de barèmes Agrégation et ajout des coûts communs

Avantages : Analyse plus approfondie Répartition des risques Permet l'itération

Inconvénients : Plus long, Ne regroupe pas les tâches similaires

50

Estimations: Décomposition

La décomposition nécessite des barèmes Exemples de barèmes:

Compte-rendu d'interview et vérifications : 0,5 personne-jour par interview

Interview: 0,5 personne-jour+déplacement Rédaction de rapport : 10 à 20 pages par personne - jour Codage et test unitaire d'un IHM simple : 0,5 personne-jour

51

Quelques principes

Pas de modèle universel. Mais nécessité d'une démarche formalisée. Analyser en priorité :

Les particularités du projet L’identification des tâches Les contraintes

Faire plusieurs estimations si nécessaire. Savoir justifier. Une bonne estimation repose sur la capitalisation.

52

Outils de gestion de Outils de gestion de projetsprojets

53

Outils de gestion de projets

Existence de nombreux logiciels de gestion de projet. Permettent de :

Planifier le projet, Créer des tâches, Affecter des ressources aux tâches, Indiquer le coût des ressources, Calculer le chemin critique, Faire des simulations (pour constater les impacts d'un retard

par exemple).

54


Composants essentiels : Réseau PERT :

se présente sous forme graphique et ressemble à un organigramme informatique horizontal montrant les liens entre les tâches

renseigne surtout sur le "chemin critique" Diagramme de GANTT :

orienté sur la gestion du tempsindique les dates de début et de fin des tâchespermet de planifier les tâches et réduire la date de fin du

projet

55


Il existe de nombreux progiciels (plus de 80 dans le catalogue du CXP)

Quelques exemples de produits: MS Project, PMW, PSN 8, On Target, Artemis, Primavera,

Plantrac TM, Harvard, Time Line, WINGS, Pertmaster, Etc...

56

Quelques produits

MS PROJECT pour Windows (Microsoft) Mise au point de planning, Présentations graphiques de PERT, GANTT et calendrier, Suivi des délais, gestion des coûts simple, Outil simple à manipuler, public non spécialiste de la gestion

de projet.

On Target (Symantec Corporation) Gère jusque 1500 tâches par projet, Gère un nombre illimité de ressources par tâche, Possibilité d'établir des liens graphiques temps/ressources

avec la souris, Utilisation facile

57

Quelques produits

PSN 8 (Scitor Corporation) Outil généraliste de planification de tâches et de gestion de

ressources (individuelles ou en groupes) au sein d'un département

Permet de réaliser des simulations en temps réel, des analyses et des synthèses

Sait gérer plusieurs projets Gère 2000 activités par projet et 500 ressources par table, Produit des états de taille réglable

PMW (ABT Corporation) Outil orienté gestion des ressources S'adresse à un public connaissant bien la gestion de projet

58

Constats générauxConstats généraux

59

Constats généraux

De nombreux projets «avortent». Retard dans la livraison. Dépassement de budget. Problèmes d’exploitation et de maintenance. Résistance aux changements. Manque de compétences des gestionnaires.

60

Lois, règles et légendes

L'effort nécessaire à fournir pour atteindre les objectifs prévus croît géométriquement avec le temps

Les projets progressent rapidement jusqu’à ce qu’ils soient terminés à 90% puis, restent à 90%

Lorsque les choses vont bien, quelque chose ne va pas

Lorsque les choses ne peuvent pas être pires, elles le deviendront encore davantage

61

Lois, règles et légendes

Si on tolère le changement, le rythme de changement dépassera le rythme de développement

En moyenne, les grands projets finissent un an en retard, coûtent deux fois plus que l’évaluation initiale

Un projet mal planifié prendra trois fois plus de temps à réaliser que prévu alors qu'un projet bien planifié ne prendra que deux fois plus de temps

Aucun grand projet informatique n'est achevé dans les délais, dans les limites budgétaires prévues à l'origine et avec les mêmes responsables qu'à son initialisation

62

Constats généraux: quelques statistiques

Dans la mesure où les dérives sur les projets de grande taille sont très fréquentes, il convient de ne pas sous-estimer les coûts, qui peuvent se révéler à terme beaucoup plus élevés

A titre d'information, quelques statistiques sur la tenue des délais dans des moyens (30 à 100 mois/hommes) et grands projets (100 à 1000 mois/hommes) (source Carper-Jones) :

Projets annulés : 13% Projets en retard de plus de 12 mois : 12% Projets en retard de plus de 6 mois : 35% Projets approximativement à l'heure : 37% Projets terminés plus tôt que prévu : 3%

63

Déroulement d’une Déroulement d’une mission d’auditmission d’audit

64

Déroulement d’une mission d’audit

5 phases : Lancement du projet et compréhension du contexte Recueil de l’existant Analyse de l'existant Recommandations Présentation finale

65

Phase de lancement : Précision du champ de la mission et définition des objectifs

associés :éléments à l ’origine de la mission justifiant son opportunité,

ses objectifs et les enjeux correspondantsdéfinition du champ de l ’étude et éventuellement des

ambiguïtés subsistant sur le champ de la missionidentification des différents services concernésévolutions prévisibles à prendre en compte


66

Phase de lancement : Organisation de la mission et planning :

identification nominative des intervenants et disponibilité requise

planning prévisionnelpremière convocation pour les entretiens


67

Recueil de l’existant : Description des structures existantes, Description des ressources logicielles et matérielles, Mise en évidence : objectifs,

problèmesbesoinsfacteurs clés de succès.


68

Analyse de l’existant : Analyse critique de l’existant sur les aspects

OrganisationnelsFonctionnelsTechniquesFinanciers


69

Recommandations : C’est à partir de l’analyse de l’existant que sont proposées

des solutions ou des préconisations visant à optimiser : le fonctionnement, les dépenses, la réponse aux besoins utilisateurs

Préconisations en terme de :sécuritéarchitecture informatiqueoutils de développementconduite de projetméthodologieorganisationrelation maîtrise d’ouvrage / maîtrise d'œuvre


70

Présentation finale : Présentation aux commanditaires de la mission, Synthèse avec :

rappel du contexteindication des modalités de déroulementexposé rapide de l’existantmise en évidence des points fortsmise en évidence des points faiblesdysfonctionnementsrecommandations classées par priorité

organisation, conduite du projet, ressources…


71

Quelques points de repères

Difficultés les plus courantes constatées dans la relation MOA/MOE:

Manque de confiance mutuelle Manque de transparence dans la stratégie et l’action Manque d’objectivité dans l’appréciation des problèmes Difficultés à prendre des décisions claires Lourdeur des structures de pilotage Résistance naturelle aux changements La MOE tend souvent à se substituer à la MOA sur des

sujets qui relèvent de la responsabilité de la MOA et réciproquement

Validations difficiles

72

Difficultés ressenties par la MOA : Difficultés à fixer des orientations politiques tranchées Manque de visibilité sur les travaux en cours Mauvaise compréhension et appréciation des évaluations de

charges et délais élevés fournies par la MOE


73

Difficultés perçues par la MOE : Manque de disponibilité de la MOA Besoins insuffisamment précis et stables Manque d’engagement de la MOA Difficulté à évaluer les charges et les délais et à les expliquer

à la MOA


74

Démarche d’audit Démarche d’audit de projetde projet

75

Audit de projet

L'audit de projet est présenté en trois volets : Une sensibilisation aux risques spécifiques de chaque type

de grand projet de système d'information Réf.: Guide d'Audit, "Audit des grands projets de systèmes

d'information : Évaluation des risques", IFACI) Une analyse générique des risques liés à la conduite de

projet Une analyse des risques spécifiques à chaque phase du

cycle de vie du projet

76

Les risques Les risques spécifiques de spécifiques de chaque type de chaque type de

grand projet de S.Igrand projet de S.I

77

Typologie de projets

Projet à niveau élevé d'engagements budgétaires Projet stratégique au niveau de l'entreprise Projet transverse Projet aux enjeux organisationnels forts (de type

"change management") Projet à base de technologies novatrices (exemples:

technologie objet, Internet, EDI,…) Système de gestion spécifique complexe ou peu

répandu Entreprise Ressource Planning (ERP) - Progiciel de

Gestion Intégré (PGI)

78

Typologie de projets

Outsourcing de l'informatique ou des systèmes d'information (total ou partiel)

Fusion et regroupement d'entreprises ou d'activités (entre plusieurs sociétés), acquisition, filialisation

Projet international d'unification de systèmes informatiques ou de systèmes d'information nationaux (exemple: un groupe avec ses filiales)

Fusion/regroupement de systèmes d'information ou de centres informatiques

Projet à délai imposé

79

Audit de projet

Projet à niveau élevé d'engagements budgétaires Motivations et raisons du choix de ce type de projet

Remplacement d'une application lourde nécessitant des équipes de conception-développement volumineuses

Déploiement d'équipements à grande échelle

80

Projet à niveau élevé d'engagements budgétaires Risques généraux

Dépassement budgétairePrésentation de coûts sous -estimés ou incompletsRecherche d'économies au détriment de la qualitéPhases aval du projet réalisées rapidement, pour rattraper

les dérives constatées sur les phases amontMéthodes de travail ne permettant pas de garder la maîtrise

du déroulement du projetArrêt du projet et dispersion de toutes les équipes après le

déploiementContractualisation avec les prestataires externes présentant

des points faibles ou des lacunes

Audit de projet

81

Projet stratégique au niveau de l'entreprise Motivations et raisons du choix de ce type de projet

Lancement d'un nouveau produit, d'une nouvelle prestation ou d'un nouveau métier

Mise en conformité avec une nouvelle réglementation Risques généraux

Manque d'implication des commanditaires / Commanditaires trop directifs

Déclinaison incorrecte des éléments du plan stratégiqueEssoufflement du projet avant son total déploiementDépassement de délai

La bonne fin d'un tel projet repose en grande partie sur l'Étude d'opportunité

Audit de projet

82

Projet transverse Motivations et raisons du choix de ce type de projet

Passage d'une gestion verticale à une approche par processus

Risques générauxAbsence de vision transversePilotage fort d'une fonction, au détriment des fonctions

connexesNon prise en compte de la culture d'entreprise

Audit de projet

83

Projet aux enjeux organisationnels forts (de type "change management")

Motivations et raisons du choix de ce type de projetBouleversement des conditions d'exercice du métierRepositionnement de l'entreprise sur son marché

Risques générauxManque d'implication de la Direction Générale jusqu'à la

bonne fin du projet de changementMauvaise intégration du volet socialManque d'homogénéité entre le projet SI et les choix

organisationnelsDépassement de délai

Audit de projet

84

Projet à base de technologies novatrices (Technologie objet, Internet, EDI,…)

Motivations et raisons du choix de ce type de projetRecherche d'un avantage concurrentielVitrine technologiqueRemplacement d'une technologie obsolète et mise en place

d'un socle technique évolutif et pérenne Risques généraux

Attrait de l'innovation pour elle-mêmeDépendance vis -à-vis des fournisseursMauvaise intégration dans le système d'information et

manque de coordination avec les projets des partenairesOubli des coûts

Audit de projet

85

Système de gestion spécifique complexe ou peu répandu

Motivations du choix de la DGCompte tenu du caractère spécifique, la seule solution

possible est faire des développements Risques associés

Spécifications fonctionnelles pointues et particulièresPerturbation des systèmes amont et aval et propagation des

dysfonctionnementsLa solution d'informatisation n'est pas nécessairement la

solution du problèmeDépassement de coûts : manque d'expérience par rapport à

des domaines plus standard

Audit de projet

86

Enterprise Ressource Planning (ERP) - Progiciel de Gestion Intégré (PGI)

Motivations du choix de la DGLes concurrents ont pris un ERP (effet de mode)Aller vite et avoir une couverture plus large des besoins

fonctionnelsDisposer d'une technologie plus avancéeSuppression des interfaces applicativesSolution plus souple et moins chère qu'un développement

maisonDiffusion d'un modèle d'organisation unique pour

l'ensemble des filialesMeilleure intégration et structuration des informations (une

base de données unique pour l'entreprise)Mise à disposition plus rapide et plus complète des

informations stratégiques (besoins de niveau DG)

Audit de projet

87


Risques générauxRésistance au changementForte intégration du systèmeComplexité du paramétrageDiversité de l'environnement techniqueRisques liés à la migration et les interfacesDes enjeux importants liés aux coûts et aux délaisInadéquation fonctionnelle ou couverture fonctionnelle

incomplète, ce qui va obliger à plus de développements spécifiques

Surdimensionnement fonctionnel, sous -utilisation des fonctions du produit

Audit de projet

88


Risques généraux (suite)Sous -estimation des coûts et des délais de mise en œuvreSous -estimation des impacts organisationnelsPerte de maîtrise de l'évolution de l'organisation et des

processus métierDiminution de l'avantage concurrentiel (alignement).Sécurité logique insuffisante

Audit de projet

89


Motivations et raisons du choix de ce type de projet:Se recentrer sur son métier de base, l'informatique étant une

activité de supportRéduire la taille et le coût des services centrauxAméliorer la qualité du service rendu aux utilisateursFaciliter les changements de structure de l'entreprise

Audit de projet

90


Risques générauxPerte de confidentialitéDégradation de la qualité de serviceInflation des coûtsMauvaise gestion des changementsDémotivation du personnel

Audit de projet

91

Fusion et regroupement d'entreprises ou d'activités (entre plusieurs sociétés), acquisition, filialisation

Motivations et raisons du choix de ce type de projetUne réduction des frais fixesUn développement du businessUne synergie commerciale et une amélioration des parts de

marché Risques généraux

Absence de questionnement sur le fait de garder ou non des S.I. différents (Convergence en matière de S.I. et architecture technique)

Réduction des avantages escomptés de l'opérationPerturbation de fonctionnementDérapage des coûts, des délais et de la qualité

Audit de projet

92


Motivations et raisons du choix de ce type de projetCentralisation du pilotageÉconomies de coûtsRationalisation et unification des pratiques de gestionConséquences attendues : installation du même « core

system » partoutGains escomptés : mise en cohérence des informations de

gestion et rapidité de consolidation, vision exacte des filiales

Audit de projet

93


Risques générauxErreur d'appréciation au départ : base réputée identique

partoutRéalité différente : analyse trop schématique, sous -

estimation des particularismes locauxDécouverte des problèmes après -coup, ce qui oblige à des

compléments d'étude et entraîne des dépassements de coûts

Non atteinte des performances attendues

Audit de projet

94

Fusion/regroupement de systèmes d'information ou de centres informatiques

Motivations et raisons du choix de ce type de projetRationalisation du fonctionnement, économies de coûts.

Risques générauxDérapage des délais, d'où dérapage des coûts.Impacts sur les clients, sur le personnel (pertes de

compétence : les meilleurs partent, démotivation du personnel : perte.

Non atteinte de la cible.Arrêt du projet.

Audit de projet

95

Fusion/regroupement de systèmes d'information ou de centres informatiques (suite)

1er cas : Risques déclinés en fonction du cas de regroupement

Le regroupement de centres informatiques peut se faire dans deux configurations possibles côté constructeur :

– même constructeur: il faut vérifier les économies et le fonctionnement

– constructeurs différents: la décision étant politique, un audit n'est pas nécessaire

Les risques portent principalement sur:– la migration des données– l'architecture du réseau– l'organisation de l'exploitation et du support– le projet RH

Audit de projet

96

Fusion/regroupement de systèmes d'information ou de centres informatiques (suite)

2ème cas : Risques en cas de fusion et de regroupement de SI:

L'existence d'une étude de benchmarking et de son application

La décision du choix du SI ou des applicatifs à retenir, la migration des données, le projet RH, la formation des utilisateurs, l'organisation des processus

L'existence d'un document de choix et d'un relevé de décisions, d'un plan de migration

La satisfaction des besoins de la maîtrise d'ouvrage, la manière dont est organisé leur suivi

Audit de projet

97

Projet à délai imposé Motivations de ce type de projet

En général, projets résultant de contraintes réglementaires, fiscales, etc

Maintien du bon fonctionnement de l'entreprise tout en intégrant les contraintes

Risques généraux : ils portent sur l'identification incomplète des domaines à couvrir, des problèmes à traiter; ou bien sur la non tenue du planning (préparation et réalisation). Il en découle :

Réparation à chaud sans ordre, ce qui engendre des risques aggravés et des coûts plus importants, une perte de clients, et des pertes d'exploitation

Absence de plan de secours avec arrêt potentiel de l'activité,Tests incomplets du plan de secours

Audit de projet

98

Projet à délai imposé (suite) Risques relatifs à l'organisation du projet

Affectation de ressources trop importantes sur le reporting par rapport aux forces vives nécessaires en traitement des problèmes,

Le reporting est en décalage avec la réalité du terrain (il nécessite d'être validé et affiné par des audits qualité),

Le schéma global de résolution de problèmes n'est pas réaliste,

La démarche n'est pas à l'état de l'art (cf. ISACA,…), n'est pas structurée ni exhaustive, n'est pas formalisée ni communiquée,

Toutes les compétences ne sont pas réunies ; l'appel à l'expertise externe nécessaire n'a pas été effectué,

Les solutions ne sont pas mutualisées (cf. Forum des compétences du secteur financier).

Audit de projet

99

Risques liés à la Risques liés à la conduite de projetconduite de projet

100

Les cinq questions clés

Existe-t-il un consensus sur les objectifs du projet ? Processus de décision/validation et suivi

d'application de ces décisions ? Qui fait quoi dans le projet ? Tous les acteurs disposent-ils des informations

nécessaires pour agir dans le sens du projet ? Quel est le niveau d'avancement du projet ?

101

Audit de projet

Les risques liés à la conduite de projet sont abordés selon les thèmes suivants

1) Objectifs du projet

2) Structure de projet

3) Instances de pilotage et de suivi

4) Méthode et outils

5) Planification

6) Contrôle du projet

7) Qualité

102

1) Objectifs du projet

Concernant l'intégration du projet dans l'entreprise, s'assurer des points suivants :

Existence d'une définition claire du projet, de son périmètre, Existence d'un projet en accord avec la stratégie de

l'entreprise et sa culture, Existence d'un plan de communication

103

Objectifs du projet

Les objectifs et les besoins Les objectifs du projet sont-ils définis et connus des MOA et

MOE ? Les besoins sont-ils clairement définis ? Le périmètre est-il défini et stabilisé ? Les interactions et leurs impacts avec d'autres projets ont-

ils été identifiés ?

Les risques A t-on identifié et formalisé les risques potentiels ?

104

2) Structure de projet

Vérifier l'existence d'une structure de projet : assurer l'organisation du projet

Vérifier l'existence d'un chef de projet (MOE et MOA) S'assurer de la constitution d'une équipe de projet

Remarque : la structure d'un projet n'est pas nécessairement figée. Selon la nature et l'importance du projet, elle peut évoluer dans le temps

105

Structure de projet

Vérifier la participation de tous les acteurs au projet : Propriétaire du projet clairement identifié Maîtrise d'ouvrage :

Liste des intervenantsRôle et responsabilités

Maîtrise d'œuvre :Liste des intervenantsRôle et responsabilités

S'assurer que les rôles et les responsabilités de la maîtrise d'ouvrage et de la maîtrise d'œuvre sont formellement identifiés

106

Les moyens : Moyens humains :

Organiser en fonction des besoinsÉquilibre entre l'expérience et le potentiel

Moyens techniques :Environnement de développement efficaceOutils de développementAménagement de l'environnement physique

Structure de projet

107

Direction de projet Évaluer les compétences de la direction de projet, Vérifier la motivation des équipes, Sonder la maîtrise d'ouvrage :

besoins,craintes,communication,

Le but est d ’obtenir le meilleur rendement possible des équipes en place.

Les principaux atouts appartiennent au domaine des relations humaines motivation esprit d ’équipe leadership, délégation... :

Évaluer la résistance au changement.

Structure de projet

108

Existence d'un groupe projet : Membres permanents Rôles et responsabilités Réunions périodiques

Vérifier l'échange d'informations entre la direction de projet et le groupe projet

Structure de projet

109

Les acteurs : Identification claire des fournisseurs :

Rôle et responsabilitésRésultats attendusDélai

Acteurs externes :Obligations légales (ex: fiscal, CNIL…)Résultats à fournirDélai

Structure de projet

110

3) Instances de pilotage et de suivi

Le mode de pilotage, les processus de décision/validation

La structure de pilotage est-elle définie ?La structure de pilotage est -elle adaptée ?La structure de pilotage est -elle formalisée et connue de

tous les acteurs ?Les différentes instances de pilotage connaissent -elles

leurs "niveaux de délégation" ?Les objectifs de délégations sont -ils atteints ?

Vérifier l'existence d'un comité de pilotage Vérifier l'existence d'un comité de projet Vérifier l'existence d'un comité des utilisateurs. Étudier la pertinence des participants présents au comité de

projet et au comité de pilotage.

111

Instance de pilotage et de suivi

Les attributions respectives des instances de projet sont les suivantes :

Comité de pilotage :Instance de décision et de pilotage stratégique du projet

(lancement, développement de la solution, conduite du changement et mise en œuvre, management du projet)

Comité de projet : Instance de pilotage opérationnel du projet agissant pour le

compte du comité de pilotage, comprenant des représentants de la maîtrise d'œuvre

Comité des utilisateurs :Instance chargée de l'expression détaillée des besoins et des

règles de gestion; de la validation des dossiers de conception présentés par l'équipe projet; de la participation aux tests du système, à l'élaboration de la documentation utilisateurs, aux actions de formation ; de la réception définitive du logiciel

112


Le mode de pilotage, les processus de décision/validation

Les comités de pilotage et de projet sont-ils adaptés et efficaces ?

Les participants aux différents comités sont-ils représentatifs , ont-ils le bon niveau de décision ?

Les utilisateurs sont-ils représentés dans les comités de pilotage ?

Les gestionnaires et la production ont-ils été intégrés dans les structures de pilotage ?

Les participants ne sont-ils pas trop nombreux ?La fréquence des comités est-elle correcte ?Qui prépare, anime, fait le compte-rendu des comités de

pilotage ? Et dans quel délai ?Existe-t-il une revue de projet ? (réunion MOA-MOE

périodique pour suivre l'avancement du projet)

113


Le reporting Les indicateurs de suivi sont-ils définis ?

Les indicateurs de suivi sont-ils adaptés en fonction de l'étape ?

Les indicateurs de suivi sont-ils mis à jour ?Les indicateurs de suivi sont-ils pertinents par rapport aux

objectifs du projet (contraintes de délais, de qualité, de coût,…)

Existe-t-il un formalisme de reporting ?Le reporting se fait-il sous forme de tableau de bord ?Le reporting est-il conjoint et unique MOA-MOE ?

Quelle est la fréquence du reporting ? est-t-elle adaptée au suivi?

114


La gestion des changements (évolutions de périmètre)

Les demandes d'évolutions de périmètre sont-elles formalisées?

Les évolutions de périmètre sont-elles fréquentes ? Si oui, combien y en a-t-il eu ?

La gestion des évolutions de périmètre est-elle bien maîtrisée ?

Existe-t-il une procédure de gestion des évolutions de périmètre ?

Les décisions sont-elles prises ?Les mesures d'impact sont-elles faites ?Y a t-il une gestion des versions ?

115


Les décisions Les décisions sont-elles prises ? Avec un délai satisfaisant?

Sur la base d'un niveau d'information pertinent ? Les points de décision sont-ils respectés (exemple: réunion

et note de lancement, décision d'opportunité) ?

116

4) Méthodes et outils

S’assurer de l'existence d'une méthode : Vérifier qu'elle est bien appliquée Identifier les points pouvant être bloquants tels que :

Outils associés à la méthodeFormation à la méthode et aux outilsCas de dérogation d'utilisation

Vérifier la mise en œuvre d'outils

117

5) Planification

Vérification d'un point de vue général : Existe-t-il un planning directeur commun à tout le projet ? La planification s'effectue du général au particulier et l'on

procède par itération :Existence d'un plan de projet initialCe plan de projet a-t-il été révisé et pourquoi ?Existence de plans détaillés initiauxRévision des plans détaillés ?Gestion des ressources

118

Planification

Définition des produits à développer : Notions de projet, sous-projet, lots Identifications des phases et étapes :

ContraintesDates limites

119

Estimation des charges : Utilisation d'une méthode d'estimation :

Vérifier son applicationVérifier la cohérence d'ensemble

Mise en adéquation des moyens :HumainsTechniques

Planification

120

Avancement du projet (points en suspens) Le planning général du projet est-il représentatif de la

réalité?Les acteurs se sont-ils engagés à respecter le planning

général du projet ?Les lots sont-ils bien identifiés et suivis dans le planning ?Le chemin critique est-il identifié ?

La mesure de l'avancement du projet est-elle réalisée ?La notion de reste à faire est-elle comprise par tous les

acteurs ?La réestimation périodique et en commun des reste-à-faire

est-elle faite ?Existe-t-il des "capteurs" d'alertes ?Existe-t-il des procédures pour traiter les alertes

« urgentes » ?

Planification

121

Évaluer la prise en compte des risques : Par rapport :

à la technologie utiliséeaux projets en coursaux délaisà la synchronisation des activités

Planification

122

6) Contrôle du projet

Le contrôle du projet est directement lié à la planification

Il permet de vérifier : Avancement des travaux Contrôle des livrables Contrôle de la qualité

123

Vérifications nécessaires : A-t-on mis l'accent sur les écarts et la recherche de

solutions ? A-t-on pris en compte des demandes de changement après

évaluation? Les demandes d'évolutions de périmètre sont-elles

formalisées ? Les évolutions de périmètre sont-elles fréquentes ? Si oui,

combien y en a-t-il eu ? La gestion des évolutions de périmètre est-elle maîtrisée ? Existe-t-il une procédure de gestion des évolutions de

périmètre ? Les décisions sont-elles prises ? Les mesures d'impacts sont-

elles faites ? Y-a-il une gestion des versions ? A-t-on pris en compte les points en suspens ?

Contrôle du projet

124

Point essentiel: le suivi périodique de l’état d’avancement du projet

Le reporting Les indicateurs de suivi sont-ils définis ?

Les indicateurs de suivi sont-ils mis à jour ?Les indicateurs de suivi sont-ils pertinents par rapport aux

objectifs du projet (contrainte de délais, contrainte de qualité, contrainte de coût,…) ?

Existe-t-il un formalisme de reporting ?Le reporting se fait-il sous forme de tableau de bord ?Le reporting est-il conjoint et unique MOE-MOA ?

Contrôle du projet

125

Point essentiel : Le suivi périodique de l'état d'avancement du projet

Efficacité du processus de décision/validation effectué par les instances de pilotage

Contrôle du projet

126

Vérifications nécessaires : Application du MAQ et PAQ s'ils existent (cf. partie Qualité) Existence des revues (techniques, livrables) Circuit d'approbation des livrables Graduation des livraisons Documentation produite

Contrôle du projet

127

7) Qualité

Quelques définitions (AFNOR) L ’assurance qualité est la mise en œuvre d ’un ensemble

approprié de dispositions préétablies et systématiques destinées à donner confiance en l ’obtention de la qualité requise.

La qualité est ce que le client souhaite explicitement ou implicitement

La qualité du logiciel est son aptitude à satisfaire les besoins des utilisateurs

128

Qualité

Les objectifs qualité ont-ils été formalisés ? Existe-t-il des moyens pour s'assurer de la qualité ?

Existence d'un manuel d'assurance qualité de l'entreprise Existence d'un plan d'assurance qualité du projet

129

Le manuel d’Assurance Qualité

Dispositions générales prises par l ’Entreprise pour obtenir la qualité de ses produits et services.

Contient : Les règles de gestion de la qualité Les règles et procédures de gestion de l’Entreprise Les plans types de documentation L’organisation associée

130

Le plan d’Assurance Qualité

Établi à partir du MAQ Décrit les procédures, les règles, les méthodes

applicables au projet Fixe aux différents acteurs du projet leurs droits mais

aussi leurs devoirs en matière de qualité L’élaboration du PAQ est du ressort du Responsable

Assurance Qualité du projet

131

Exemple de PAQ

Introduction : Contexte, périmètre, procédures associées au PAQ.

Glossaire et abréviations. Organisation :

Rôle des intervenants et des structures de pilotage.

Plan de développement : Démarche, activités, livrables…

132

Exemple de PAQ

Documentation : Identification, contenu, validation

Procédures diverses : Gestion des fournisseurs, gestion des configurations,

gestion des modifications Gestion des points en suspens, gestion des risques, gestion

de la recette

Reproduction, protection, livraison Suivi de l’application du Plan d’Assurance Qualité

133

Qualité

A t-on formalisé les objectifs de qualité du produit (Plan Qualité Projet)?

Les utilisateurs ont -ils été impliqués dans la définition du niveau de qualité du produit ?

A-t-on formalisé les objectifs de qualité de service attendue ?

Les utilisateurs ont -ils été impliqués dans la définition du niveau de qualité attendue ?

134

La revue des points La revue des points clés de chaque clés de chaque

phasephase

135

Les grandes phases de conduite de projet

Étude d'opportunité/Lancement Conception générale/Analyse Conception détaillée Développement/Réalisation ou Paramétrage

(progiciel) Qualification : Tests/Recettes Mise en œuvre/Conduite du changement

136

Étude d’opportunité/Lancement

Vérifier l'existence d'une expression détaillée et formalisée des besoins dans un cahier des charges fait par la MOA Document contractuel : justification du projet

S'assurer que l'étude d'opportunité comprend : Les objectifs du projet L'analyse des déficiences des systèmes existants Les enjeux du projet Les bénéfices attendus Les contraintes relatives au projet Les acteurs concernés

137


S'assurer de l'intégration du projet au schéma directeur ou plan directeur

Cohérence du projet dans le plan directeur informatique, Cohérence du projet dans le système d'information actuel ou

futur, S'assurer de la participation de la direction du département

utilisateur concerné dans la phase d'initialisation. S'assurer de la participation au projet des acteurs

concernés : pertinence de l'équipe de projet Identifier les acteurs de l'équipe de projet et leurs

responsabilités, Évaluer l'adéquation entre les qualifications des personnes

impliquées et leurs tâches, Vérifier la participation des principaux utilisateurs à l'équipe

de projet.

138


Vérifier la formalisation de l'approbation du projet :

Validation de l'étude d'opportunité. S'assurer que l'étude d'opportunité a été revue par les

directions des départements utilisateurs concernés et par la direction informatique

Vérifier que l'approbation a été formalisée par écrit Vérifier la qualité de la personne qui a autorisé la poursuite

du projet

139

Conception générale/Analyse

S'assurer de l'existence d'une analyse comparative des scénarios possibles : contrôle de la pertinence de la solution de développement retenue.

Vérifier l'exhaustivité des scénarios proposés, y compris celui de ne rien faire.

Vérifier la qualité de l'analyse technologique de chaque alternative.

Besoins/disponibilités de matériels et de logicielsBesoins en formationBesoins/disponibilités de ressources humainesFaisabilité opérationnelleImplication du responsable techniqueContraintes juridiques/réglementaires

140


S'assurer de l'existence d'une analyse comparative des scénarios possibles : contrôle de la pertinence de la solution de développement retenue

Vérifier la qualité de l'analyse économique de chaque alternative

Coûts de développementCoûts de formationCoûts de maintenance/exploitationCoûts de conversion/migration/paramétrageCoûts annexesBénéfices attendusCoûts de fonctionnementImplication du responsable utilisateur

141


S'assurer de l'existence d'une analyse comparative des scénarios possibles : contrôle de la pertinence de la solution de développement retenue

Vérifier l'existence d'une analyse des risques pour chaque alternative

Valeur et sensibilité des informations traitéesVulnérabilitésBesoins correspondant en matière de contrôles internesImplication du responsable sécurité

S'assurer de l'existence de critères d'évaluation pour réaliser l'analyse comparative en toute objectivité

142


Vérifier la prise en compte des aspects de contrôle interne et de sécurité dans l'élaboration du cahier des charges afin d'assurer la sécurité du futur développement

S'assurer que la conception générale du futur système s'inscrit dans les objectifs généraux de contrôle en vigueur dans l'environnement.

S'assurer que les contrôles d'exploitation ont été identifiés. S'assurer de la prise en considération des besoins

spécifiques en matière de contrôles. S'assurer de l'identification et de la description des besoins

en matière de contrôles programmés.

143


Vérifier la formalisation de la poursuite du projet : validation de la conception générale et choix de la solution de développement

S'assurer que les études de faisabilité proposées ont été revues par les membres du Comité du Projet

S'assurer de la présentation des différentes solutions possibles au Comité de Pilotage

Vérifier la qualité de la personne qui a autorisé la poursuite du projet

Vérifier l'existence d'une approbation écrite

144


S'assurer de l'utilisation d'une méthode d'analyse et de conception: qualité de la phase de conception.

Vérifier l'existence d'une méthode d'analyse/de conception S'assurer que cette méthode est correctement utilisée Evaluer la maîtrise de cette méthode

Vérifier la conformité des spécifications détaillées au cahier des charges : correcte interprétation des besoins exprimés.

Vérifier l'exhaustivité des spécifications détaillées par rapport à la conception générale

Evaluer la définition et la documentation des spécifications.

145


Vérifier la qualité des contrôles programmés Vérifier l'existence de contrôles adaptés à chaque point

critique du systèmeContrôles préventifsVérifier l'existence et la pertinence des contrôles correctifs

S'assurer de l'implication du responsable de la sécurité Vérifier l'existence de pistes d'audit permettant de suivre la

totalité des transactions de leur point d'origine jusqu'aux totalisations de contrôle correspondantes et vice-versa

146


S'assurer de l'implication suffisante des acteurs concernés (utilisateurs, administrateurs de données, responsable sécurité,…)

Vérifier la formalisation de la validation de la conception détaillée

S'assurer que la conception détaillée préparée a été revue par les membres du Comité de Projet

S'assurer que le document a été présenté au Comité de Projet

Vérifier la qualité de la personne qui a autorisé la poursuite du Projet

Vérifier l'existence d'une approbation écrite

147

Recommandations en matière de spécification

Pour assurer que la réalisation du logiciel correspond aux besoins, au minimum, les documents suivants doivent exister:

Spécifications externes (ou spécifications fonctionnelles)Ce document décrit, précisément et clairement, toutes les

caractéristiques du logiciel à réaliser (fonctions, contraintes, règles de calcul) ainsi que toutes les interfaces externes. Une fois approuvé par le utilisateurs, il constitue le document de référence. Toutes les caractéristiques seront décrites de façon à ce qu'il soit possible d'en vérifier objectivement la réalisation

Spécifications internes (ou spécifications organiques globales)Ce document décrit tous les éléments d'architecture du système,

c'est-à-dire, les sous -ensembles à réaliser en précisant leurs fonctions, et tous les éléments communs (modules de service, fichiers, tables, bases de données, interfaces,…)

148

Développement/Réalisation

S'assurer de l'utilisation d'une méthode de développement (pérennité et fiabilité des traitements)

Vérifier l'existence d'une méthode de développement S'assurer que cette méthode est correctement utilisée Évaluer la maîtrise de cette méthode par les développeurs

Vérifier le respect des normes de documentation et de vérification

Étudier la pertinence des normes en vigueur Vérifier l'application de ces normes par les développeurs Apprécier la qualité de la documentation S'assurer de la revue par le responsable du services études

de la documentation constituée

149


Vérifier la formalisation d'un programme général de tests

Vérifier l'existence d'un plan de mise en place. Vérifier l'existence et la pertinence du plan de mise en place Vérifier l'approbation et la diffusion du plan de mise en place S'assurer que le plan de mise en place définit au minimum :

La nature des travaux à réaliser et leur ordonnancementLes charges de travail correspondantes et la durée des

travauxLes acteurs concernésLeurs rôles et responsabilités

150


Vérifier l'existence de procédures de contrôle et de sécurité lors de la migration : assurer la réussite du projet de conversion

Vérifier l'existence et la pertinence du plan du plan de migration

S'assurer du respect des normes de développement et de vérification du programme de conversion

S'assurer du respect des procédures de contrôles en matière de passage en production

Vérifier l'existence d'une image des systèmes et des données avant et après conversion

Vérifier l'implication du responsable assurance qualité dans le processus de conversion

S'assurer de la formalisation de l'examen et de l'approbation des résultats du processus de conversion par les directions concernées

151


Objectif : Personnaliser le progiciel pour répondre aux besoins exprimés par les utilisateurs

Définir et enregistrer les paramètres de configuration pour adapter le progiciel au contexte organisationnel et technique cible

Faire réaliser les adaptations spécifiques nécessaires pour satisfaire les besoins non couverts

152

Paramétrage (Solution Progiciel)

Vérifier l'existence du dossier de spécification du paramétrage

Le dossier doit consigner les options retenues sur le produit (approche itérative en partant des options les plus structurantes)

La démarche constitué par l'éditeur peut constituer le fil conducteur pour le travail de paramétrage

Vérifier qu'un prototype représentatif a été réalisé (implication des utilisateurs)

153

Qualification: tests/Recettes

Les tests représentent le vecteur principal de l’amélioration de la qualité de l’application

Cependant, tester reste une des activités les moins populaires chez les développeurs d’applications. En effet, contrairement à la conception ou à la production de code, le test ne génère que des fiches d’anomalies

De plus, étant réalisés en fin de processus de développement, les tests ont tendance à être limités, voire « oubliés », du fait des retards déjà accumulés et de la pression pouvant être exercée sur l’équipe de projet.

154

Tests/Recettes

La phase de tests constitue néanmoins une activité centrale puisqu’elle assure la qualité absolument nécessaire qui n’est fournie ni par les logiciels de conception, ni par les outils de développements

Les conséquences économiques et financières démontrent la nécessité de tester les applications en cours de développement ; néanmoins, il est impossible de tester l'application entièrement

Une partie importante des problèmes d’exploitation résulte de défaillances de tests

155

Tests/Recettes

S'assurer du respect des normes de recette finale : Procès-verbal (PV) de recette

Vérifier l'existence et la pertinence d'une procédure formalisée de recette finale destinée à accepter formellement l’application

Vérifier la participation active des acteurs concernés S'assurer de la maîtrise suffisante du système par les

personnes impliquées dans la recette Vérifier la pertinence des jeux d'essais et s'assurer de

l'étendue des tests S'assurer que les tests de performances sont réalisés dans

les futures conditions d'exploitation du système S'assurer de la formalisation des résultats des jeux d'essais

et de la recette finale par la direction du département utilisateur

156

Conduite du changement

Enjeu capital dans la réussite ou l’échec d’un projet, le changement vécu par les organisations lors d’une évolution du système d’information doit être maîtrisé et géré comme un processus à part entière.

Ce processus doit aboutir à une réelle appropriation du nouveau système d’information par tous les utilisateurs dès la phase de démarrage.

La démarche de la conduite du changement est structurée en 6 phases :

Identification et évaluation des changements, Plan de communication, Plan de formation, Élaboration définitive de la documentation, Organisation du soutien, Reprise des données.

157


Identification et évaluation des changements Existe-t-il une synthèse de l'évaluation des changements ? L'évaluation a t-elle été validée ? S'assurer que les entretiens réalisés sont représentatifs ? Les utilisateurs participent-ils à l'évaluation des

changements ?

158


Plan de communication Existe-t-il un plan de communication ? Est-il complet ? Les messages sont-ils clairs et simples ? Y-a-t-il une progressivité de la communication par rapport au

développement du projet ? Existe-t-il un soutien fort de la Maîtrise d'Ouvrage ?

159


Plan de formation Vérifier l'existence d'un plan de formation des utilisateurs et

des opérateurs. La hiérarchie des personnes à former est-elle impliquée ? Vérifier l'identification des profils types des personnes à

former. Vérifier la pertinence de la population à former. Les objectifs de chaque formation sont-ils identifiés et

affichés? Evaluer les cessions et apporter les éventuelles adaptions.

160


Plan de formation (suite) Vérifier l'adéquation du planning de formation au planning

du projet. Vérifier la pertinence de la durée du programme de

formation. S'assurer de la qualité pédagogique des formateurs et du

contenu de la formation. Vérifier l'existence d'une procédure d'évaluation des formés

et des formateurs.

161


Élaboration de la documentation Vérifier l'existence d'un manuel d'utilisation, d'un aide

mémoire, d'un guide utilisateurs, d'une aide en ligne. S'assurer de la bonne répartition entre documentation en

ligne et documentation papier. Les accès à la documentation répondent-ils en priorité aux

besoins des utilisateurs ?

162


Vérifier l'existence d'un manuel utilisateurs Vérifier que le manuel utilisateurs est conforme aux normes

en vigueur. S'assurer de sa disponibilité et de sa compréhension par

l'ensemble des utilisateurs. Vérifier qu'il comprend au minimum :

les objets du système et la description des dessins d'écran et des commandes disponibles,

les responsabilités concernant le redressement des erreurs ou anomalies,.

La description des sorties et leur mode de diffusion,Les responsabilités en matière de

sauvegarde/archivage/purge. S'assurer qu'il fait l'objet d'une procédure de mise à jour.

163


Vérifier l'existence d'un manuel d'exploitation. Vérifier que le manuel d'exploitation est conforme aux normes en

vigueur. S'assurer de son accessibilité et de sa compréhension par les

opérateurs. S'assurer qu'il a été testé lors des tests finaux. Vérifier qu'il comprend au minimum :

la fonction des programmes,le libellé exact des fichiers concernés,la liste des messages opérateurs et les réponses attendues,les actions à suivre en cas d'anomalies,la liste des états générés et leurs destinations,les procédures de reprise,les responsabilités de l'exploitation en matière de contrôles

globaux. S'assurer qu'il fait l'objet d'une procédure de mise à jour.

164


Organisation du soutien Une organisation d'assistance aux utilisateurs a-t-elle été

mise en place dans la phase d'exploitation du nouveau système ?

Son organisation générale a-t-elle été bien anticipée ? S'assurer de la disponibilité réelle d'une formation et d'une

expertise. Les différents niveaux de soutien sont-ils coordonnés et

cohérents ?

165


Reprise des données Existe-t-il un dossier d'organisation de la reprise des

données ? Le niveau de qualité des données d'origine est-il bien

maîtrisé ? S'assurer de la mise en place de contrôles automatiques de

la qualité des données obtenues après reprise. S'assurer de la mobilisation le plus tôt possible des

utilisateurs devant participer à la reprise des données.

166


Le bilan qualité comporte deux parties : Le bilan qualité élaboré en référence au PAQ, Le bilan qualité exprimé par les utilisateurs.

167

Bilan Qualité

Bilan de la qualité du logiciel élaboré en référence au PAQ : Réalisé en prenant comme référence les exigences qualité fixées

par la maîtrise d’ouvrage, traduites par le maître d’œuvre en objectifs et critères à respecter par le logiciel.

Exigences fixées par les utilisateurs au niveau du système:Conformité : conformité aux besoins fonctionnels et techniques

exprimés par le cahier des charges fonctionnel et technique ;Performance : temps de traitement des échanges courants au

niveau des serveurs doit être inférieur à trois secondes dans au moins 95% des cas d’utilisations de ces échanges, sur une journée, pour environ 200 échanges par minute ;

Sécurité : système disponible et intègre. Système disponible pour les utilisateurs, tous les jours ouvrés, pour l’ensemble des traitements, avec une indisponibilité maximale acceptée inférieure à deux heures par semaine

Convivialité : système facile d’exploitation sans aucune installation de logiciel sur le poste client.

168

Bilan Qualité

Bilan qualité exprimé par les utilisateurs Il est fortement recommandé d’élaborer un bilan en prenant

l’avis direct des utilisateurs. Cette appréciation peut se recueillir à l’aide d’un

questionnaire qui doit passer en revue tous les aspects du logiciel.

Critères d’appréciation de la qualité d’un logiciel :Complétude et qualité des fonctionnalités présentes,Ergonomie,Performance,Qualité de la documentation,Robustesse et fiabilité,Formation reçue,Qualité et efficacité de l’assistance et du soutien.

169

Exemples de Exemples de missionsmissions

170

Mission n°1: Contexte et objectifs

Avant de lancer la réalisation d'un nouveau système destiné à remplacer les outils actuels de gestion administrative, physique et douanière des marchandises, une société a souhaité évaluer les risques liés au projet et étudier l'opportunité d'une solution alternative de type logiciel intégré.

Cette société travaille avec un prestataire informatique spécialisé dans le domaine.

Phase d'intervention de la mission: Définition des Besoins du Système (Cahier des charges en

cours de rédaction)

171

Mission n°1: Contexte et objectifs

Thèmes examinés : Existence d'une solution satisfaisante "logiciel/progiciel

intégré" unique Modernité et pertinence technique du projet Modernité et pertinence fonctionnelle du projet Montage projet pour la rédaction du cahier des charges et

pour la réalisation du système Montage contractuel pour la réalisation du système

172

Mission n°1: Personnes rencontrées

Personnes rencontrées Directeur général adjoint, DSI client, Chef de projet EDI client, Chef de projet client, Directeur technique prestataire, Chef de projet prestataire.

173

Mission n°1: Principaux constats

Les solutions "logiciel intégré" La mise en place d'un logiciel/progiciel intégré unique pour

la gestion des moyens de transport et des marchandises ne semble pas appropriée (faible intérêt fonctionnel).

Risques humains et sociaux importants dans le contexte de la ville.

Pas d'offre sur le marché des logiciels/progiciels intégrés spécifiques pour une gestion globale de ce genre d'activité. Une solution de ce type unique serait donc coûteuse.

174


Principaux constats (suite) Modernité et pertinence technique du produit

envisagé La méthode qui a été adoptée pour définir l'architecture

technique cible dans le cahier des charges est satisfaisante. Globalement, les exigences essentielles ont été posées dans

le cahier des charges pour un réseau de communication sécurisé appuyé sur des bases de données relationnelles.

Le cahier des charges présente les besoins techniques et les contraintes à respecter. A ce titre, il est une base pour les propositions des prestataires.

175


Modernité et pertinence fonctionnelle du produit envisagé

La description des nouvelles fonctionnalités doit être complétée :

Les fonctionnalités détaillées sont très proches de celles existantes ;

Les nouvelles fonctionnalités sont peu explicites. Absence d'une réelle étude des besoins

176


Montage du projet pour la rédaction du cahier des charges Des difficultés ont été rencontrées dans le cadre de la rédaction

du cahier des charges. Manque de clarté dans la définition des rôles et responsabilités

des différents acteurs de la gestion du projet : le chef de projet utilisateurs (maîtrise d'ouvrage) n'a pas été formellement identifié.

Absence d'axe directeur donné au projet qui nuit à la pertinence et à la cohérence des travaux des responsables de projet informatiques et explique les différences de points de vue entre parties à la rédaction du cahier des charges.

Manque de disponibilité de ressources dédiées qui explique la dérive dans les délais initialement prévus.

177


Montage projet pour la réalisation du système Risques importants de dysfonctionnement liés à la structure

pressentie pour la réalisation du système. Origine de ces risques : la confusion des rôles entre maîtrise

d'œuvre et maîtrise d'ouvrage.Une des causes majeures de l'échec des grands projets (*).La MOE tend à se substituer à la MOA sur des sujets qui

relèvent de la responsabilité de la MOA ;La réciproque étant vraie (ex : une MOA raisonnant en

termes de solutions). (*) Projets mobilisant plus d'une dizaine de personnes en pointe,

plus d'un niveau hiérarchique, avec un accent mis sur la gestion de projet.

178


Montage du projet pour la réalisation du système Les structures pressenties ne permettent pas de garantir

totalement :L'adéquation des fonctionnalités du système réalisé avec

les besoins exprimés,La livraison d'un outil techniquement performant,La réalisation et la mise en œuvre du système dans des

délais raisonnables. Montage contractuel pour la réalisation du système

La question n'a pas été abordée

179

Mission n°1: Recommandations

Recommandations générales Il semble souhaitable de continuer le projet et pour qu'il se

déroule dans les meilleures conditions possibles, de :Nommer un chef de projet utilisateurs ;Créer les conditions d'association d'une SSII expérimentée à

la société informatique spécialisée pour la réalisation du système ;

Approfondir les possibilités de contractualisation dans le cadre d'une mise en concurrence pour la réalisation du système. La mobilisation d'une expertise juridique sur ce sujet est conseillée.

180


Pertinence technique du produit La définition de l'architecture technique cible dans le cahier

des charges est satisfaisante

Pertinence fonctionnelle du produit : L'absence réelle d’étude des besoins est un handicap

important. Le caractère novateur du système peut être un atout

concurrentiel important de la société face à ses clients. D’où la nécessité de vérifier rapidement les évolutions prévisibles dans ce domaine :

Auprès de quelques grandes sociétés de transport ;Auprès de la société la plus avancée sur le plan mondial

dans le domaine de l'informatisation logistique.

181


Montage du projet pour la rédaction du cahier des charges

Désigner un chef de projet utilisateur pour fixer les orientations générales à donner au projet.

Montage du projet pour la réalisation du système Même si des procédures adéquates d'arbitrage et de gestion

des relations entre les partenaires ont été prévues dans le projet de convention pour la réalisation du système ;

Il conviendra de clarifier les rôles de chacun et de réfléchir à l'opportunité de s'associer les compétences d'un prestataire informatique expérimenté.

182


Montage contractuel Nécessité de choisir une procédure. Les instances appropriées devront se prononcer sur le choix

d'une procédure pour le montage contractuel (appel d'offre ouvert, appel d'offre restreint, marché négocié avec ou sans compétition). Trois modèles de montages contractuels sont possibles :

Sous-traitance totale de l'informatique : appel d’offre,Parrainage par une société chargée de l'exploitation du

système (situation actuelle). La solution " marché négocié sans mise en concurrence"

entre le maître d'ouvrage et le maître d'œuvre présenterait des risques financiers et juridiques qu'il conviendra d'analyser.

183

Chiffrage du projet Le chiffrage actuel ne tient pas suffisamment compte de

l'existant, des projet précédents et de la connaissance du métier et des outils des partenaires.

Le chiffrage du projet pourrait être revu à la baisse sur la base d'une version validée du cahier des charges.

On peut noter que lorsqu'une entreprise lance un appel d'offres pour choisir un prestataire, elle demande une évaluation du coût du projet.

Toutefois, dans la mesure où les dérives sur les projets de cette taille sont très fréquentes, il convient de ne pas sous-estimer les coûts, qui peuvent se révéler à terme beaucoup plus élevés.

184

Mission n° 2: Contexte et objectifs

L'objectif de notre intervention consiste, dans le cadre d'une acquisition potentielle, à dresser une revue générale de l'informatique pour le compte du repreneur de la société.

Pour ce faire, notre champ d'étude couvre cinq domaines :

l’organisation de la fonction informatique, l’architecture technique, une revue des applications existantes, la sécurité du système d'information (sécurité logique et

physique, plan de continuité des opérations, procédures de développement et de maintenance, etc.),

les contrats de prestations de services.

185


Et essentiellement une prise de connaissance du projet de migration informatique sur le nouveau progiciel, y compris les chantiers Euro et An 2000. A ce titre, nous avons étudié :

Les modalités de choix du progiciel, L’organisation du projet et son degré d'avancement, Ainsi que la nature et l’évaluation globale des travaux

restant à réaliser.

Phase d'intervention: Migration du système d’information vers un progiciel

bancaire dans le cadre de la mise en place d’un schéma directeur.

186

Mission n° 2: Personnes rencontrées

Directeur informatique et Directeur adjoint, Responsable Réseau/Micro, Directeur de l’Organisation, Directeur de l'Agence Centrale, Direction Commerciale, Secrétariat Crédits, Direction des Opérations, Département Etranger, Département Comptabilité, Manager d'un cabinet de conseil et d'audit

(Maîtrise d'ouvrage déléguée du projet de migration vers le nouveau progiciel).

187

Mission n° 2: Principaux constats sur le projet de migration

De nombreux chantiers ne sont pas encore stabilisés, le maintien d'un démarrage prévu dans les deux mois à venir présente des risques importants :

Risques d'insuffisance des tests compte tenu des délais restants,

États de gestion internes ne répondant que partiellement aux besoins de la société,

Absence de maîtrise des processus complets d’exploitation, Risque d'une solution dégradée au démarrage pour

plusieurs applicatifs.

188


Les risques potentiels associés au projet de migration ont un impact fort sur le plan :

De la continuité de l’activitéAbsence de solution de secours sur le système cible.

Des coûts de mise en placeLe budget de vingt millions de francs initialement alloué au

projet de migration est largement dépassé. Le non-respect des délais fixés est susceptible de générer un surcoût important (assistance supplémentaire de prestataires...).

De la continuité de l’exploitationPerturbations organisationnelles et fonctionnelles,Insuffisance de tests compte tenu des délais fixés,Maîtrise partielle ou insuffisante de l’enchaînement des

processus d’exploitation.

189


Les risques potentiels associés au projet de migration ont un impact fort sur le plan (suite) :

Du respect des exigences réglementaires et interbancaires De la solution de secours

Faible visibilité à ce jour sur la pertinence des solutions minimales requises.

De la forte dépendance de l’établissement vis-à-vis de l’éditeur du logiciel,

De la motivation des équipes dédiées au projetLeur mobilisation est une condition indispensable au

succès de la migration. Le maintien d'un démarrage dans les deux mois à venir présente

des risques de perturbations importants et/ou de blocages non maîtrisés,

190

Mission n° 2: Recommandations

Compte tenu des risques évoqués, nous recommandons de ne pas faire l'acquisition de l'institution financière avant la migration vers le progiciel

Un audit approfondi devrait être effectué après cette migration n Nous recommandons de prendre en compte les risques relatifs à une éventuelle rupture des contrats informatiques en cours et le cas échéant procéder à une analyse approfondie des contrats par un juriste spécialisé.

191


Notre mission consiste à effectuer une revue d’un dispositif téléindicateur pour le compte d’une grande entreprise de transport.

La Maîtrise d’œuvre est assurée par une PME spécialisée dans le développement de ce type de produit.

Phase d'intervention : Qualification/homologation du système : tests et recettes.

192

Mission n° 3: Personnes rencontrées

Personnes rencontrées Au niveau du maître d'œuvre :

Président Directeur Général de l'entreprise, Directeur Commercial, Chef de Projet.

Au niveau de l'entreprise de transport : Représentant des utilisateurs, Commanditaire du système, Chargé de la maintenance du système sur site.

193

Mission n° 3: Principaux constats

Diagnostic général La réception définitive du système n’est pas prononcée

(portefeuille de bogues important) ; Le projet a engagé à ce jour des charges significativement

supérieures aux coûts prévus et n’est pas économiquement en mesure, de prendre toutes les initiatives qui pourraient être nécessaires ;

La maîtrise technique du système est concentrée sur une seule personne. Cette situation est fragilisante pour le client.

194


Le projet Pas de méthode de conduite de projet, Modifications effectuées pendant les développements sans

mise à jour de la documentation, Peu de suivi de projet (planification et suivi d'avancement), Manque de procédures, Documentation inexistante ou inexploitable, Formation des utilisateurs très insuffisante,

195


Plate-forme de tests et qualification insuffisantes, Procédure de gestion des anomalies trop peu

rigoureuse, Contribution insuffisante de la maîtrise d'ouvrage

dans les phases de tests, Aucun plan d'acceptation du système fourni par la maîtrise

d'ouvrage, Manque de communication entre maîtrise d'œuvre et la

maîtrise d'ouvrage, Relations conflictuelles entre la MOA et MOE.

196


Le logiciel Points faibles:

Produit incomplet, Ne peut fournir le service attendu sans incidents, Niveau de maintenabilité très insuffisant.

Point fort: Caractère évolutif du produit

197


Organisation du projet : Nécessité de mettre en place une nouvelle équipe de projet

et de prévoir une période de transition, Formaliser une procédure précisant les modalités de

collaboration entre les utilisateurs et la fonction informatique : confusion MOA/MOE,

Préciser les responsabilités de la MOE et de la MOA.

198


Contrôle du projet : Continuer de stabiliser l'existant i.e. les demandes

d'évolution doivent rester gelées Envisager l'acquisition d'outils performants de

développements pour améliorer la qualité du logiciel, Nécessité de gérer la configuration et les versions du

logiciel, Nécessité de mettre en œuvre une gestion rigoureuse des

anomalies, Suivre une démarche de mise au point et de qualification du

logiciel en mettant en œuvre des procédures de tests, La mise en place d'un site pilote est indispensable dans la

procédure de qualification.

199


Documentation : Nécessité de constituer une documentation du système en

précisant :Les spécifications externes ou fonctionnelles,Les spécifications internes ou organiques globales,L'architecture technique globale et l'architecture modulaire

détaillée (les documents sont manuscrits),

200


Documentation (suite) : Le plan de développement : document contenant les

informations de planification liées au développement du logiciel.

Le découpage du projet en tâches élémentaires et l’estimation de la charge de réalisation de chaque tâche en précisant la compétence choisie et le temps requis ;

La planification des tâches et la consommation induite des ressources

Les événements clés permettant de contrôler l’avancement. On pourra ainsi mesurer le suivi d’avancement du projet en

comparant ressources consommées/résultats obtenus d’une part et délais prévisionnels/délais réels d’autre part.

201


Documentation : Nécessité de constituer un dossier « Utilisateurs »

comportant :Le manuel utilisateurLe guide de maintenance

202


Communication : Implication de la direction générale dans la gestion des

projets, Raisonner en terme de structure et non en terme de

personnes, Respecter les rôles et responsabilités de chacun, Compréhension du logiciel par les utilisateurs, Participation importante des utilisateurs.

203

ConclusionConclusion

204

Les causes principales de dysfonctionnement sont:

Une mauvaise prévision : mauvaise prévision des tâches à effectuer, mauvaise prévision des conséquences de la mise en place du nouveau système

Une mauvaise organisation : partage des rôles entre les intervenants imprécis, fonctions non identifiées, taux de participation trop flou

Une mauvaise communication : contexte et objectifs du projet méconnus, validations implicites, interlocuteurs concernés non impliqués, compte-rendu insuffisant du maître d'œuvre au directeur de projet

205

Des engagements contractuels mal définis entre la maîtrise d'ouvrage et la maîtrise d'œuvre.

Les conséquences de ces dysfonctionnements peuvent être un surcroît de charges, un allongement

des délais, une mauvaise qualité du logiciel ou des services offerts aux utilisateurs pouvant aller même jusqu'au rejet de l'application.

Les causes principales de dysfonctionnement sont:

206

Maîtriser le développement du projet

Au plan de l'organisation : Une implication forte de la hiérarchie ; Des représentants maîtrise d'ouvrage et maîtrise d'œuvre

désignés ; Des structures de travail (groupes utilisateurs, de pilotage)

et de décision (comité directeur, comité exécutif) équilibrées, effectives et représentatives ;

Des rôles bien définis pour chaque participant

207


Au plan de l'organisation (suite): Un document de départ à l'intention de la maîtrise d'œuvre

définissant clairement les objectifs du projet, les contraintes et les résultats attendus, les exigences de qualité et les travaux préalables ;

Un calendrier et un budget prévoyant à l'avance les tâches à effectuer et leur durée ;

Un tableau de bord et des procédures de contrôle de l'avancement ;

Des procédures de validation et de recette ; Un plan d'actions pour la maîtrise d'ouvrage.

208


Au plan des méthodes et des outils : Une démarche : succession de tâches à assumer et de

résultats à produire ; Une méthode d'évaluation des charges ; Une méthode de planification et de suivi de l'avancement

permettant d'avoir en permanence une bonne visibilité sur 'avancement du projet ;

Un plan d'assurance qualité ; Des outils : atelier de génie logiciel, outil de conduite de

projet, etc.

209


Toutes ces dispositions préétablies et systématiques destinées à donner confiance en l'obtention de la qualité requise doivent être consignées dans un plan d'assurance qualité (PAQ).

Ce plan doit être spécifique à chaque projet et établi en fonction des exigences qualité formulées par la maîtrise d'ouvrage.

Les exigences qualité doivent être traduites en facteurs qualité ou en critères qualité véritables.

210

[email protected]

Viser à l’ensemble, et se mettre à l’œuvre

par les détails (Proverbe chinois)

Mohamed SAÂD

Audit des projets informatiques

Technology

Transcript of Audit des projets informatiques