Chapitre 1 – Cadre du management de projet informatique

0. Projet, produit, processus

Projet :
— Idée, besoin ou objectif à atteindre, limité dans le temps (début/fin).
— En informatique : ensemble d’actions pour réaliser un produit selon une démarche méthodique et progressive.
Produit :
— Résultat concret du projet (logiciel, service, système, etc.).
— C’est la concrétisation de l’idée, la satisfaction du besoin exprimé dans le cahier des charges.
— Évalué par :
— le maître d’ouvrage (client, utilisateur final),
— le maître d’œuvre (réalisateur).
Processus du projet :
— Distance / temps entre le projet (idée) et le produit (résultat).

Schéma : Projet → Produit

Processus du projet
Projet (idée/besoin)
Produit (logiciel/service)

Maitre d’ouvrage / Maître d’œuvre (vue simple)

2. Management de projet (MPI) vs développement (DPI)
2.1 Management de Projet Informatique (MPI)
MPI :
— Gestion globale du projet : de l’idée à la clôture.
— Couvre : exploration, préparation, réalisation, maîtrise/suivi, clôture.
— Objectif : respecter la triple contrainte coût – délai – qualité.

Activités typiques MPI

— Analyse du besoin, rédaction du cahier des charges.
— Définition du périmètre, des objectifs, des livrables.
— Planification (planning, ressources, budget).
— Suivi/contrôle (Gantt, tableaux de bord, jalons).
— Gestion des risques, de la communication et des ressources humaines.

2.2 Développement de Projet Informatique (DPI)

DPI :
— Partie technique : analyse, conception, programmation, tests, déploiement, maintenance.
— C’est la 3e phase (réalisation) du cycle MPI.

Activités typiques DPI

— Analyse fonctionnelle et technique.
— Modélisation, architecture logicielle.
— Codage, intégration des composants.
— Tests (unitaires, intégration, validation).
— Déploiement et maintenance (corrective, adaptative, évolutive).

Tableau synthèse MPI vs DPI

Aspect MPI DPI

Rôle Organisation, pilotage du projet Réalisation technique du produit
Objectif Respect coût–délai–qualité Produit conforme au cahier des
charges
Activités Planification, coordination, com- Conception, codage, intégration,
munication, suivi, validation tests, déploiement
Profils Chef de projet, coordinateur, Développeurs, architectes, tes-
MOA, MOE teurs
Outils Gantt, PERT, outils de pilotage, IDE, systèmes de gestion de ver-
MS Project sions, outils de tests

2.3 Règle du triangle et des 3U

— Triangle Qualité – Coût – Délai autour de l’objectif.
— Règle des 3U :
— Utile : répond à un besoin réel.
— Utilisable : facile à utiliser (ergonomie).
— Utilisé : réellement adopté par les utilisateurs.

3. Projet vs opération
— Projet : activité temporaire, non répétitive, avec un changement ou une innovation.
— Opération : activité continue et répétitive, pour maintenir un système existant.

2
 Critère Projet Opération
Durée Temporaire (début/fin) Continue
Objectif Créer un livrable unique Assurer la continuité du service
Répétitivité Non répétitif Répétitif, cyclique
Changement Porteur de transformation Vise la stabilité
Exemple Développer une nouvelle applica- Maintenir l’application en produc-
tion tion

4. Cycle de vie de management d’un projet

4.1 Les 5 grandes phases
1. Exploration :
— Idée, opportunité, cohérence avec la stratégie.
— Cahier des charges initial, avant-projet, étude CQFD (Coût, Qualité, Fiabilité, Délai).
— Décision Go/NoGo (lancer ou abandonner).
2. Préparation :
— Constitution de l’équipe, définition des rôles.
— Spécifications des Besoins Matériels et Logiciels (SBML).
— Planification (PERT, Gantt), budget opérationnel.
3. Réalisation :
— Cycle de développement (cascade, V, agile, etc.).
— Conception, codage, tests.
4. Maîtrise et suivi :
— Vérification / validation par rapport au SBML.
— Déploiement, formation des utilisateurs, suivi qualité.
5. Clôture :
— Bilan du projet, retour d’expérience.
— Libération de l’équipe projet.

4.2 Schéma de cycle (simplifié)

Exploration
Préparation
Clôture
Maîtrise
Réalisation

4.3 Jalons (milestones)

Jalon : point dans le temps où l’on fait un bilan et où l’on décide de la suite.
— Jalon de début de projet : Ordre de Service (ODS).
— Jalons inter-phases : passage d’une phase à l’autre.
— Jalons contractuels : réunions MOA/MOE pour valider l’avancement.
— Jalons Go/NoGo : arrêt possible si opportunité ou faisabilité non prouvée.
— Jalon de fin de projet : déploiement + formation utilisateurs.

5. Acteurs d’un projet informatique

5.1 Principaux rôles
— Commanditaire / Maître d’ouvrage (MOA) :
— Porte le projet au niveau stratégique, finance.
— Définit les grandes orientations, valide les décisions clés.
— Chef de projet / Maître d’œuvre (MOE) :
— Planifie, coordonne, pilote les travaux.
— Gère délai, coût, qualité, risques, communication.
— Rôle : leader (vision), manager (organisation), coach (accompagnement).

3
— Comité de pilotage :
— Organe de gouvernance (MOA, MOE, métiers, experts).
— Suit l’avancement, arbitre les décisions stratégiques.
— Utilisateurs clés :
— Exprimant les besoins métier, participent aux tests de recette.
— Facilitent l’appropriation du système par les utilisateurs finaux.
— Équipe de réalisation :
— Développeurs, analystes, architectes, intégrateurs, testeurs.
— Implémente la solution technique.
— Responsable qualité :
— Met en place le Plan Assurance Qualité (PAQ).
— Veille à la conformité aux normes (ex. ISO/IEC 25010, 12207, 29119).
— Responsable sécurité :
— S’assure que le projet respecte les normes de sécurité et les contraintes légales (protection des données,
etc.).
— Gestionnaire du changement :
— Prépare les utilisateurs (communication, formation, support).
— Facilite l’acceptation du nouveau système.

5.2 Organisation de l’équipe

Principes d’une équipe performante
— Ambition du projet.
— Motivation de chaque membre.
— Planification claire (dates début/fin, tâches).
— Transparence sur objectifs, rôles, responsabilités.
— Rigueur des règles, mesures de performance.
— Esprit d’initiative encouragé.

Cycle de vie d’une équipe (Tuckman + valorisation)

— Forming : constitution, chacun cherche sa place.
— Storming : tensions, conflits, affirmation des positions.
— Norming : clarification des rôles, stabilisation.
— Performing : équipe opérationnelle, coopération efficace.
— Adjourning : bilan, retour d’expérience, dissolution.

6. Typologie des projets informatiques (vue rapide)

6.1 Selon la finalité
— Développement logiciel : applications web/mobile, systèmes métier, etc.
— Intégration de systèmes : ERP, CRM, ajout de modules à un SI existant.
— Infrastructure : réseaux, serveurs, stockage.
— Transformation digitale : dématérialisation, GED, refonte de processus.
— Cybersécurité : contrôle d’accès, IDS/IPS, politiques de sécurité.
— Migration/Évolution : remplacement d’un ancien système, changement de technologie.
— Maintenance évolutive / corrective / perfective.

6.2 Selon l’envergure et le contexte

— Stratégiques : portés par la direction générale, fort impact long terme.
— Tactiques : portés par une direction métier (RH, marketing, etc.).
— Opérationnels : impact local, risques limités.

4
— Internes : pour l’organisation elle-même.
— Externes : pour des clients (contrats, SLA, etc.).

6.3 Selon technologies et conduite

— Technologies :
— Cloud (SaaS, PaaS, IaaS).
— Data/IA (big data, ML, DL).
— Web et mobile.
— Méthodes de conduite :
— Traditionnelles : cascade, V, spirale.
— Agiles : Scrum, XP, Kanban.
— Hybrides : mélange classique + agile.

7. Contraintes et risques des projets informatiques

7.1 Contraintes principales
— Temps : pression sur les délais.
— Budget : ressources financières limitées.
— Qualité : exigences fonctionnelles + non-fonctionnelles.
— Techniques : choix de technologies, compatibilité, performance.
— Organisationnelles : disponibilité des ressources, coordination d’équipes.
— Réglementaires / contractuelles : lois, normes, contrats.
— Fonctionnelles : besoins des utilisateurs, parfois flous ou évolutifs.

7.2 Grandes familles de risques

a) Cahier des charges
— Besoins mal exprimés, incomplets, ambigus, instables.
— Conséquences : fonctionnalités inutiles, refontes, utilisateur insatisfait.

b) Planning et délais
— Sous-estimation du temps, imprévus techniques/humains.
— Renfort tardif de l’équipe augmente les canaux de communication et complique la gestion.

c) Budget
— Dépassement de coût : réduction du périmètre, baisse de qualité, retards, tensions, risque d’abandon.
— Prévention : budget prévisionnel + réserve (provision pour aléas) + suivi régulier.

d) Techniques
— Mauvais choix technologique, intégration complexe, bugs graves.
— Dépendances externes (bibliothèques, API, services cloud).
— Problèmes de performance, architecture fragile, différences entre environnements.

e) Sécurité et confidentialité
— Fuite de données, contrôles d’accès insuffisants, failles applicatives.
— Non-conformité RGPD et autres règles.
— Erreurs humaines (mots de passe faibles, envoi de données sensibles).

f ) Changements et périmètre
— Évolution non maîtrisée du périmètre (scope creep).
— Exigences instables, changements stratégiques, changement de technologie en cours.
— Turn-over dans l’équipe.

5
g) Risques externes
— Dépendance à des fournisseurs, évolutions technologiques, changements de lois.
— Contexte économique, crises sanitaires ou politiques, cybercriminalité.

7.3 Matrice impact / probabilité (courbe de criticité)

— Impact : de négligeable (1) à critique (5).
— Probabilité : de très improbable (0) à fréquente (1).
— Niveau de risque C = P robabilit × Impact.

Impact

5 A (critique)

1
B (faible)
Probabilité
1 2 3 4 5

7.4 Traitement des risques (5 stratégies)

— Refuser : abandonner le projet ou la partie trop risquée.
— Supprimer : éliminer la cause (changer un composant, une techno).
— Transférer : confier le risque à un tiers (contrat, assurance, outsourcing).
— Réduire : diminuer probabilité et/ou impact (tests, redondance, sécurité).
— Accepter : si le risque est mineur et maîtrisable.

8. Méthodologies, approches et architectures (vue d’ensemble)

8.1 Quatre notions à ne pas confondre
Élément Ce que c’est / exemples
Approche de Manière d’écrire le code : impérative, objet, fonctionnelle, logique,
programmation événementielle, réactive.
Modèle de déve- Organisation des phases (analyse, conception, codage, tests, dé-
loppement ploiement, maintenance) : cascade, V, itératif/incrémental, spi-
rale, agile (Scrum, XP), RUP.
Architecture lo- Structure du système : monolithique, 2-tiers / n-tiers, client-
gicielle serveur, microservices, SOA, etc.
Méthode de dé- Ensemble de pratiques, outils, rôles, principes : Merise, SADT,
veloppement OOSE, RUP, Scrum, XP, DevOps, Lean Software Development.

8.2 MDA / MDD (développement dirigé par les modèles)

— Approche d’ingénierie logicielle centrée sur les modèles.
— Modèles abstraits PIM (Platform Independent Model) transformés en PSM (Platform Specific Model), puis
en code.
— Compatible avec plusieurs modèles de développement, surtout itératifs.

À retenir pour l’examen (Chapitre 1)

— Différence Projet vs Produit vs Processus + rôle MOA / MOE.
— Définitions de projet (ISO 21500, PMI) : unique, temporaire, objectif clair.

6
— Spécificités d’un projet informatique : immatériel, long cycle de vie, forte complexité, techno évolutives.
— MPI vs DPI : qui fait quoi, triple contrainte coût–délai–qualité, règle des 3U.
— Cycle de vie en 5 phases + jalons (Go/NoGo, début/fin, contractuels).
— Acteurs : commanditaire, chef de projet, comité de pilotage, utilisateurs clés, équipe de dev, qualité, sécurité,
changement.
— Typologie des projets : par finalité (dev, intégration, infra, migration, etc.), envergure (stratégique/tactique/opérationnel),
contexte (interne/externe), technologies, méthodes.
— Contraintes et risques : surtout cahier des charges, délais, budget, risques techniques, sécurité, changements
de périmètre, risques externes.
— Matrice impact–probabilité, stratégies de traitement des risques (refuser, supprimer, transférer, réduire, ac-
cepter).
— 4 notions à distinguer : approche de programmation, modèle de développement, architecture logicielle, mé-
thode de développement (+ MDA/MDD).