Gestion de Projet & Approche Agile (M110)
Dernière mise à jour : Novembre 2025
Parcours d'apprentissage
Partie 1 : Fondamentaux & Méthodologies
Partie 1 : Fondamentaux et Méthodologies de Projet
Chapitre 1 : Définitions et Concepts Clés
1.1 Qu'est-ce qu'un Projet ?
Selon le PMI (Project Management Institute), un projet est une entreprise temporaire initiée dans le but de fournir un produit, un service ou un résultat unique.
Temporaire
Tout projet a un début et une fin définis. Il n'est pas une activité continue (comme la maintenance ou la production).
Unique
Le résultat final est spécifique et nouveau (ex: un nouveau logiciel, une migration de base de données).
Progressif
Un projet s'élabore par étapes. On part d'une idée vague pour arriver à des spécifications précises.
1.2 La Gestion de Projet (Project Management)
C'est l'application de connaissances, de compétences, d'outils et de techniques aux activités du projet afin d'en respecter les exigences. Elle vise à équilibrer les contraintes concurrentes du projet (Qualité, Coût, Délai).
1.3 Spécificités de la Gestion de Projet Informatique
Les projets IT se distinguent par :
- L'immatérialité : Le produit (logiciel) est abstrait, difficile à visualiser avant la fin.
- La complexité technologique : Évolution rapide des langages et outils.
- L'incertitude : Il est souvent difficile de définir parfaitement le besoin au début (d'où l'essor de l'Agile).
Chapitre 2 : Acteurs, Rôles et Responsabilités
2.1 Les Parties Prenantes (Stakeholders)
Ce sont tous les individus ou organisations activement impliqués dans le projet ou dont les intérêts peuvent être affectés positivement ou négativement par l'exécution du projet.
Acteurs Internes
- Le Sponsor : La personne qui finance le projet et le défend politiquement.
- L'Équipe Projet : Développeurs, designers, architectes.
- La Direction : Valide la stratégie.
Acteurs Externes
- Clients / Utilisateurs finaux : Ceux qui utiliseront le produit.
- Fournisseurs : Prestataires, hébergeurs, vendeurs de licences.
- Régulateurs : Organismes imposant des lois (ex: CNDP pour les données au Maroc).
2.2 La distinction MOA / MOE
| Maîtrise d'Ouvrage (MOA) - Le Client | Maîtrise d'Œuvre (MOE) - Le Réalisateur |
|---|---|
|
|
2.3 La Matrice RACI (Assignation des responsabilités)
Outil indispensable pour éviter les conflits et les "trous dans la raquette". Pour chaque tâche, on définit :
- R - Responsible (Réalisateur) : Celui qui fait le travail. (Le développeur).
- A - Accountable (Responsable/Approbateur) : Celui qui a l'autorité finale et qui rend des comptes. Il n'y en a qu'un seul par tâche (souvent le Chef de Projet).
- C - Consulted (Consulté) : Expert qu'on consulte avant de décider (ex: un Architecte DB). Communication bidirectionnelle.
- I - Informed (Informé) : Personne tenue au courant de l'avancement. Communication unidirectionnelle.
Chapitre 3 : Caractéristiques et Contraintes
Caractéristiques de base
- ➤ Objectif SMART : Spécifique, Mesurable, Atteignable, Réaliste, Temporellement défini.
- ➤ Cycle de vie : Découpage en phases (Cadrage, Conception, Réalisation, Clôture).
- ➤ Irréversibilité : Certaines décisions (choix technologiques) sont difficiles à changer plus tard.
Le Triangle d'Or (Q-C-D)
La gestion de projet est un art de l'équilibre entre trois contraintes interdépendantes :
1. Qualité / Périmètre (Scope) : Ce qu'il faut faire.
2. Coût (Cost) : Le budget et les ressources humaines.
3. Délai (Time) : Le temps imparti.
Règle : Si on modifie l'un des côtés, au moins un des autres doit changer (ex: réduire le délai = augmenter le coût ou réduire la qualité).
Chapitre 4 : Méthodologies Prévisibles (Classiques)
Ces méthodes reposent sur l'idée que l'on peut tout planifier à l'avance. Elles sont séquentielles.
4.1 La Méthode en Cascade (Waterfall)
Le modèle historique. Chaque phase doit être validée et terminée avant de passer à la suivante. Le flux descend comme une chute d'eau.
Étapes : Exigences -> Analyse -> Conception -> Implémentation -> Test -> Maintenance.
4.2 Le Cycle en V
Une amélioration de la cascade. Le principe est d'associer chaque phase de conception (branche descendante) à une phase de validation/test correspondante (branche montante).
- Spécifications Fonctionnelles ↔ Tests de Recette (Acceptation)
- Conception Globale ↔ Tests d'Intégration
- Conception Détaillée ↔ Tests Unitaires
4.3 Le Cycle en Y (2TUP - 2 Track Unified Process)
Utilisé pour les projets complexes. Il sépare le projet en deux branches (formant un Y) qui avancent en parallèle avant de fusionner :
Fonctionnel
(Ce que le système doit faire)
Technique
(Comment le système sera construit, Architecture)
Réalisation & Intégration
Chapitre 5 : Méthodologies Non Prévisibles (Agiles)
L'Agile n'est pas une méthode, c'est une philosophie (Mindset) née pour répondre à l'imprévisibilité des projets IT.
5.1 Le Manifeste Agile (2001)
4 valeurs fondamentales qui privilégient :
- 1. Les individus et leurs interactions plus que les processus et les outils.
- 2. Des logiciels opérationnels plus qu’une documentation exhaustive.
- 3. La collaboration avec les clients plus que la négociation contractuelle.
- 4. L’ adaptation au changement plus que le suivi d’un plan.
5.2 Agile vs Waterfall (Comparaison)
| Critère | Waterfall (Cascade) | Agile |
|---|---|---|
| Approche | Séquentielle, Linéaire. | Itérative, Incrémentale. |
| Flexibilité | Faible. Le changement coûte cher. | Élevée. Le changement est bienvenu. |
| Livraison | Unique, en fin de projet (Big Bang). | Fréquente, par petits morceaux utilisables. |
| Client | Impliqué au début et à la fin. | Impliqué tout au long du projet. |
La Méthode Scrum
Framework agile le plus populaire. Repose sur des cycles courts (Sprints) et des rôles définis (PO, Scrum Master, Team). (Détaillé en Partie 3).
La Méthode Kanban
Inspiré de Toyota. Système visuel (étiquettes) pour gérer le flux de travail. Pas de sprints fixes, mais un flux continu. Limite le travail en cours (WIP).
La Méthode Lean
Philosophie visant à maximiser la valeur client en éliminant tout gaspillage (réunions inutiles, fonctionnalités superflues, attente).
Chapitre 6 : Les Étapes de Cadrage d'un Projet
Avant de lancer le développement (Coding), il faut une phase cruciale de préparation.
Compréhension des besoins client
Il faut distinguer le Besoin Explicite (ce que le client demande) du Besoin Implicite (ce dont il a réellement besoin mais qu'il ne formule pas). L'écoute active et la reformulation sont clés.
Contexte du projet
Pourquoi lance-t-on ce projet maintenant ? (Ex: Obsolescence technique, nouvelle loi, concurrence, opportunité commerciale). C'est la justification stratégique.
Périmètre du projet (Scope)
Définir ce qui est IN (inclus dans le projet) et ce qui est OUT (hors périmètre). Cela évite la dérive des objectifs (Scope Creep).
Détection des risques
Identifier ce qui pourrait mal se passer.
Exemples : Risque technique (technologie non maîtrisée), Risque humain (départ d'un expert), Risque planning (délais irréalistes).
Proposition des solutions
Sur la base de l'analyse, proposer une ou plusieurs solutions techniques et fonctionnelles (Faisabilité, Budget estimatif, Planning macro).
Partie 2 : Planifier un Projet
Introduction : La planification ne consiste pas seulement à mettre des dates sur un calendrier. C'est un processus complexe qui vise à transformer un besoin abstrait en un plan d'action concret, chiffré et ordonnancé.
Chapitre 1 : Analyse du Cahier des Charges
1.1 La Typologie des Besoins
Le point de départ de tout projet est l'expression du besoin. Un bon Chef de Projet (CP) ne se contente pas d'écouter, il analyse.
Besoins Explicites
Ce sont les besoins clairement exprimés par le client. Ils sont écrits dans le cahier des charges.
Exemple : "Je veux que le site soit accessible en trois langues."
Besoins Implicites
Ce sont les besoins non-dits, car ils semblent "évidents" pour le client, mais qui sont cruciaux. Si vous les ignorez, le projet échouera.
Exemple : "Le site doit être sécurisé et rapide" (même si le client ne l'a pas précisé).
1.2 La Gestion du Périmètre (Scope)
Le périmètre définit les frontières du projet : ce qui est inclus et ce qui est exclu.
Attention à la "Dérive des Objectifs" (Scope Creep)
C'est l'ajout incontrôlé de fonctionnalités en cours de projet sans ajustement du budget ou des délais.
Analogie : Aller au supermarché pour acheter du lait et ressortir avec un chariot plein. En gestion de projet, cela tue la rentabilité.
1.3 Identification des Risques
Un risque est un événement incertain qui, s'il se produit, a un effet négatif sur le projet. On doit les identifier tôt.
- ⚠️ Risques Humains : Départ d'un expert, conflit dans l'équipe, maladie.
- ⚠️ Risques Techniques : Obsolescence, panne serveur, complexité sous-estimée.
- ⚠️ Risques Financiers : Coupe budgétaire, faillite d'un fournisseur.
- ⚠️ Risques Juridiques : Changement de loi (ex: RGPD), propriété intellectuelle.
Chapitre 2 : Découpage et Estimation (WBS & PERT)
2.1 Le WBS (Work Breakdown Structure)
Appelé OT (Organigramme des Tâches) en français. C'est la décomposition hiérarchique du travail à exécuter.
Approche Descendante (Top-Down)
On part du projet global et on divise en sous-projets, puis en tâches. Idéal quand on connaît bien le produit final.
Approche Ascendante (Bottom-Up)
On liste toutes les petites tâches et on les regroupe. Idéal pour les projets innovants ou flous.
2.2 Distinction Clé : Charge vs Durée
Confusion fréquente chez les débutants !
La Charge (Work)
C'est la quantité de travail nécessaire. Elle s'exprime en Jours-Homme (J/H).
Exemple : Peindre un mur demande 2 jours de travail (2 J/H).
La Durée (Duration)
C'est le temps calendaire qui s'écoule. Elle dépend des ressources.
Exemple : Si j'ai 1 peintre, durée = 2 jours. Si j'ai 2 peintres, durée = 1 jour.
2.3 Techniques d'Estimation : La méthode PERT
Comment estimer la durée d'une tâche quand on n'est pas sûr ? On utilise l'estimation à 3 points (PERT) pour pondérer l'incertitude.
- Optimiste (Do) : Tout se passe à merveille.
- Pessimiste (Dp) : Tout va mal (bugs, retards).
- Plus Probable (Dc) : Scénario réaliste standard.
Cette formule donne plus de poids à la probabilité réaliste tout en considérant les risques extrêmes.
Chapitre 3 : Ordonnancement et Chemin Critique
3.1 Le Réseau PERT (Logique)
Le diagramme de PERT représente les tâches sous forme de réseau pour visualiser les dépendances (qu'est-ce qui doit être fini avant de commencer la suite ?).
- 🔵 Tâche : Représentée par une flèche ou une boite.
- ⚫ Étape : Début ou fin d'une tâche.
- 🔴 Dépendance : Lien obligatoire (ex: On ne peut pas monter le toit avant les murs).
3.2 Le Chemin Critique (CPM)
C'est le concept le plus important en planification. Dans un réseau de tâches, il existe plusieurs chemins pour aller du début à la fin.
Définition :
Le Chemin Critique est la séquence de tâches la plus longue qui détermine la durée totale minimale du projet.
- Les tâches sur ce chemin sont dites critiques.
- Elles ont une marge nulle (Marge Totale = 0).
- Conséquence : Tout retard sur une tâche critique retarde la date de fin du projet entier.
3.3 Le Diagramme de GANTT (Visuel)
C'est l'outil de communication par excellence. Il traduit le réseau logique (PERT) en calendrier visuel.
Utilité :
- Visualiser le planning dans le temps.
- Suivre l'avancement (Barres de progression).
- Voir qui fait quoi (Ressources).
Limites :
- Devient illisible sur les très gros projets.
- Demande une mise à jour constante.
Chapitre 4 : Pilotage des Ressources et Coûts
4.1 L'Affectation des Ressources (Lissage)
Une fois le planning théorique établi, il faut affecter les humains. Problème : on ne peut pas faire travailler une personne 20h par jour.
On doit donc procéder au Lissage ou au Nivellement des ressources : décaler certaines tâches non critiques (qui ont de la marge) pour éviter la surcharge de travail des équipes.
4.2 La Maîtrise des Coûts
Le budget se construit en plusieurs étapes de précision :
- Estimation Analogique (Faisabilité) : Basée sur des projets similaires passés (peu précis : -25% à +75%).
- Estimation Paramétrique (Avant-Projet) : Utilisation de statistiques et ratios (ex: coût au m² de code).
- Estimation Analytique (Détaillée) : Somme du coût de chaque tâche unitaire (très précis : -5% à +10%). C'est le budget de référence.
Partie 3 : L'Approche Agile Scrum en Profondeur
Objectif du Master : Ne pas seulement apprendre le vocabulaire, mais comprendre comment piloter un projet complexe dans un environnement incertain grâce à l'empirisme.
Chapitre 1 : Théorie, Valeurs et Rôles
1.1 L'Empirisme : Le cœur du réacteur
Scrum n'est pas une méthodologie rigide, c'est un cadre de travail (framework) empirique. Cela signifie que la connaissance vient de l'expérience et que les décisions sont basées sur ce qui est observé.
- 1. Transparence : Les aspects significatifs du processus doivent être visibles pour ceux qui sont responsables du résultat. (Ex: Le tableau Jira est à jour).
- 2. Inspection : Les utilisateurs Scrum doivent inspecter fréquemment les artefacts et l'état d'avancement pour détecter les écarts indésirables.
- 3. Adaptation : Si une dérive est constatée, le processus ou le matériel doit être ajusté le plus vite possible.
1.2 La Scrum Team : 3 Rôles, 0 Hiérarchie
Dans Scrum, il n'y a pas de chef de projet traditionnel. La responsabilité est partagée.
Le Product Owner (PO) - "La Voix du Client"
Il est responsable de maximiser la valeur du produit.
- Gère le Product Backlog (Carnet de produit).
- Définit les priorités (Quoi faire et dans quel ordre).
- Accepte ou rejette les User Stories (livrables).
- Ce qu'il n'est pas : Un manager qui dicte "comment" coder.
Le Scrum Master (SM) - "Le Leader Serviteur"
Il est responsable de la promotion et du support de Scrum.
- Coach l'équipe (aide à l'auto-organisation).
- Protège l'équipe des interférences extérieures.
- Facilite les événements (réunions).
- Supprime les obstacles (impediments).
- Ce qu'il n'est pas : Un chef d'équipe ou une secrétaire.
Les Developers (L'Équipe) - "Les Réalisateurs"
Pluridisciplinaires, ils font tout le travail nécessaire pour livrer l'incrément.
- Estiment la complexité des tâches.
- S'engagent sur la quantité de travail pour le Sprint.
- Assurent la qualité (Definition of Done).
Chapitre 2 : La Mécanique du Sprint (Artefacts & Événements)
📚 Étude de Cas Fil Rouge : "MarketPlace Bio"
Nous développons une application de vente de légumes bio.
Contexte : Le client veut lancer une première version rapidement pour tester le marché.
2.1 Le Product Backlog (Carnet de Produit)
Liste ordonnée et vivante de tout ce qui est nécessaire au produit.
Exemple pour "MarketPlace Bio" (Priorisé) :
- En tant que client, je veux voir la liste des légumes (Priorité Haute)
- En tant que client, je veux ajouter un panier (Priorité Haute)
- En tant que client, je veux payer par carte (Priorité Moyenne)
- En tant que client, je veux noter le producteur (Priorité Basse - Future Release)
2.2 Le Cycle de Vie d'un Sprint
Un sprint dure généralement entre 2 et 4 semaines. C'est un bloc de temps fixe (Timebox).
Sprint Planning (Début)
Qui : Toute l'équipe.
Quoi : Le PO présente le "Quoi", l'équipe décide du "Comment" et s'engage sur une quantité de travail.
Outil : Planning Poker (pour estimer la complexité en Story Points).
Daily Scrum (Tous les jours)
Durée : 15 min max, debout.
Objectif : Synchronisation. Pas de reporting hiérarchique !
Sprint Review (Fin)
Quoi : Démonstration du logiciel fonctionnel (L'Incrément) aux parties prenantes (Clients). On inspecte le résultat.
Sprint Retrospective (Fin)
Quoi : L'équipe s'inspecte elle-même. Qu'est-ce qui a marché ? Qu'est-ce qu'on doit améliorer dans nos processus ?
Concept Clé : Definition of Done (DoD)
Quand est-ce qu'une tâche est vraiment "finie" ?
- Le code est écrit.
- Les tests unitaires passent.
- La documentation est à jour.
- Le code est déployé sur l'environnement de test.
Sans DoD, on ne peut pas clôturer une User Story.
Chapitre 3 : Pilotage avec Jira et Indicateurs
3.1 Le Tableau Scrum (Kanban board)
Visualisation du flux de travail en temps réel.
3.2 La Vélocité
C'est la quantité de travail (en points) que l'équipe est capable de livrer en un Sprint.
Exemple : Sprint 1 = 20 pts, Sprint 2 = 22 pts, Sprint 3 = 18 pts.
Vélocité moyenne = 20 pts. Cela permet au PO de prédire les dates de livraison futures.
3.3 Le Burndown Chart
Graphique qui montre le travail restant jour après jour.
- Axe X : Jours du sprint.
- Axe Y : Points d'effort restants.
- Courbe idéale : Diagonale descendante parfaite.
- Courbe réelle : Si elle est au-dessus de l'idéale, on est en retard. En dessous, on est en avance.
Chapitre 4 : Exercices Pratiques et Corrigés
Exercice 1 : Qui fait quoi ? (Rôles)
Dans le projet "MarketPlace Bio", identifiez qui doit prendre la décision dans les situations suivantes :
- Le client demande d'ajouter une fonction "Paiement par Bitcoin" en plein milieu du Sprint.
- L'équipe se rend compte qu'elle ne pourra pas finir la page "Panier" avant la fin du Sprint.
- Deux développeurs se disputent sur le choix de la base de données (SQL vs NoSQL).
- L'équipe a besoin d'un nouveau serveur de test, mais la DSI bloque la demande.
Exercice 2 : Calcul de Vélocité & Planification
L'équipe "Alpha" a réalisé les scores suivants sur les 3 derniers sprints : 24 pts, 26 pts, 22 pts.
Le Product Backlog restant contient 120 points.
Question : Combien de Sprints faudra-t-il (environ) pour tout finir ?
Exercice 3 : Analyse de Burndown Chart
Vous êtes Scrum Master. Au milieu du sprint (jour 5 sur 10), vous regardez le Burndown Chart. La courbe réelle est horizontale (plate) depuis 3 jours et reste très au-dessus de la courbe idéale.
Que se passe-t-il ? Que faites-vous ?
Conclusion & Perspectives Professionnelles
Félicitations pour ce parcours ! 🚀
Vous venez de franchir une étape décisive. Vous ne regarderez plus jamais un projet informatique de la même façon. Vous possédez désormais la double compétence technique et méthodologique, un atout rare et précieux sur le marché du travail actuel.
Cadrage Stratégique
Vous savez transformer un besoin flou en un cahier des charges précis, identifier les risques et définir le périmètre (Scope).
Rigueur Classique
WBS, PERT, Gantt... Vous maîtrisez les outils fondamentaux pour structurer l'effort, le temps et les coûts sur des projets prédictifs.
Mindset Agile
Vous êtes prêts à intégrer une équipe Scrum, à travailler par itérations et à utiliser Jira pour livrer de la valeur en continu.
"La gestion de projet n'est pas qu'une affaire d'outils, c'est avant tout une aventure humaine. Gardez l'esprit agile !"