GESTION DE PROJET

SOMMAIRE

PARTIE 1 : INTRODUCTION À L'AGILITÉ

Aperçu rapide - Focus sur les bases

Le Manifeste Agile - Les 4 Valeurs

Pourquoi l'agilité ?

Dans les projets IT/cybersécurité/réseau, les besoins changent rapidement. L'agilité permet de s'adapter et de livrer de la valeur régulièrement, sprint après sprint, plutôt que d'attendre 6 mois pour une grosse livraison.

Autres Méthodes Agiles (Aperçu)

PARTIE 2 : SCRUM - LE CŒUR DU COURS

Qu'est-ce que Scrum ?

• Framework LÉGER pour développer des produits complexes
• Basé sur l'EMPIRISME : inspection, adaptation, transparence
• Travail par ITÉRATIONS (Sprints) de 1 à 4 semaines
• Équipes AUTO-ORGANISÉES
• Livraison CONTINUE de valeur

Les 3 Rôles Scrum

Le Product Owner (PO)

• RESPONSABLE du produit et de sa valeur
• Définit et priorise le Product Backlog
• Exprime les besoins sous forme de User Stories
• Décide ce qui sera fait dans chaque Sprint
• Valide le travail terminé lors de la Sprint Review
• Seule personne à modifier le Product Backlog

Le Scrum Master (SM)

• FACILITATEUR et COACH de l'équipe
• Anime les événements Scrum (Daily, Planning, Review, Rétro)
• Élimine les OBSTACLES qui bloquent l'équipe
• PROTÈGE l'équipe des interférences externes
• Veille au respect des pratiques Scrum
• Accompagne vers l'AUTO-ORGANISATION
• Crée un environnement de SÉCURITÉ PSYCHOLOGIQUE

Responsabilités du SM dans un projet AIS :

• S'assurer que les cérémonies Scrum sont respectées
• Identifier et supprimer les blocages (accès serveur, droits, validations...)
• Faciliter la communication entre équipe tech et parties prenantes
• Protéger l'équipe des demandes urgentes non planifiées
• Encourager l'amélioration continue via les rétrospectives

L'équipe de Développement

• TOUS ceux qui travaillent sur le produit
• Pour l'AIS : admins sys, admins réseau, ingénieurs cybersec, intégrateurs...
• AUTO-ORGANISÉE : l'équipe décide COMMENT faire le travail
• PLURIDISCIPLINAIRE : toutes les compétences nécessaires
• COLLECTIVE : toute l'équipe gagne ou perd ensemble
• Taille recommandée : 3 à 9 membres
• Pas de hiérarchie interne, pas de sous-équipes

Responsabilités de l'équipe :

S'engage sur la réalisation du Sprint Goal

Artefact 1 : Le Product Backlog

• Liste ORDONNÉE de tout ce qui doit être fait sur le produit
• Géré et priorisé UNIQUEMENT par le Product Owner
• Dynamique : évolue constamment
• Items en haut = détaillés / Items en bas = moins détaillés
• Contient : User Stories, bugs, améliorations techniques
• VISIBLE de tous à tout moment (transparence)

Exemple Product Backlog AIS

Projet : Sécurisation infrastructure réseau

• 1. Mise en place firewall périmétrique (13 SP)
• 2. Configuration IDS/IPS (8 SP)
• 3. Segmentation VLAN (5 SP)
• 4. Déploiement VPN site-à-site (13 SP)
• 5. Hardening serveurs critiques (8 SP)

(SP = Story Points)

Les User Stories

Format standard :

Exemples User Stories pour l'AIS :

• En tant qu'admin réseau, je veux un dashboard de supervision centralisé afin de détecter rapidement les anomalies
• En tant que RSSI, je veux des alertes automatiques sur les tentatives d'intrusion afin de réagir en temps réel
• En tant qu'admin système, je veux un système de sauvegarde automatisé afin de garantir la résilience des données
• En tant qu'utilisateur final, je veux un accès VPN sécurisé afin de travailler à distance en toute sécurité
• En tant que DSI, je veux des rapports de conformité RGPD afin de prouver notre conformité lors d'audits

Critères INVEST pour une bonne User Story :

• I - Indépendante : autonome, pas de dépendance
• N - Négociable : modifiable jusqu'à l'implémentation
• V - Valeur ajoutée : apporte de la valeur à l'utilisateur
• E - Estimable : l'équipe peut évaluer la difficulté
• S - Small (Petite) : réalisable en 1 Sprint
• T - Testable : critères de test clairs

Artefact 2 : Le Sprint Backlog

• Sous-ensemble du Product Backlog sélectionné pour le Sprint
• Contient les User Stories + les TÂCHES techniques
• Appartient à l'équipe de développement
• Visible sur le Scrum Board (tableau Kanban)
• Mis à jour quotidiennement lors du Daily Scrum
• Engagement : Sprint Goal (Objectif du Sprint)

Exemple Sprint Backlog AIS (Sprint 2 semaines) :

Artefact 3 : L'Incrément

• Somme de TOUTES les User Stories terminées durant le Sprint + valeur de tous les Sprints précédents
• Doit être dans un état UTILISABLE
• Doit respecter la Definition of Done
• Peut être livré

Definition of Done (DoD) - Exemple AIS :

• Configuration appliquée et testée
• Tests de sécurité passés (scan vulnérabilités, pentest basique)
• Documentation technique rédigée et à jour
• Sauvegarde de configuration effectuée
• Logs et monitoring configurés
• Validé par le Product Owner
• Déployé en environnement de production (ou pré-prod)
• Plan de rollback documenté

Artefact 4 : Le Produit (Nouveau 2025)

• Officialisé dans le Scrum Guide 2025 Expansion Pack
• Représente la VALEUR livrée aux utilisateurs
• Évolue à chaque Sprint via les Incréments
• Engagement : Definition of Outcome Done
• Focus sur les RÉSULTATS (Outcome) pas seulement les outputs

Événement 1 : Le Sprint

• Cœur de Scrum : CONTENEUR pour tous les autres événements
• Durée fixe : 1 à 4 semaines (généralement 2 semaines en 2025)
• Les Sprints s'enchaînent SANS PAUSE
• Pas de changement qui met en danger le Sprint Goal
• La qualité ne diminue JAMAIS
• Peut être annulé uniquement par le Product Owner (très rare)

Les 5 Événements Scrum

Tous les événements sont TIMEBOXÉS (durée maximale fixe). Ils créent de la régularité et minimisent les réunions non planifiées.

Durée recommandée pour l'AIS

2 semaines = durée idéale pour les projets infrastructure/sécurité. Assez long pour accomplir des tâches complexes, assez court pour rester agile.

Événement 2 : Le Sprint Planning

Lance le Sprint. Durée max : 8h pour 4 semaines (soit 2h/semaine)

Le Sprint Planning répond à 3 questions :

1. POURQUOI ce Sprint a-t-il de la valeur ? → Sprint Goal
2. QU'EST-CE QUI peut être fait ce Sprint ? → Sélection des User Stories
3. COMMENT le travail sera-t-il réalisé ? → Découpage en tâches

Participants : Toute l'équipe Scrum (PO + SM + Dev Team)

Résultat du Sprint Planning :

• Sprint Goal clairement défini
• Sprint Backlog créé avec User Stories sélectionnées
• Tâches techniques identifiées
• Engagement de l'équipe validé

Exemple Sprint Planning AIS

Sprint Goal : 'Sécuriser les accès distants'

User Stories sélectionnées :

• Déploiement VPN SSL (8 SP)
• Configuration MFA sur VPN (5 SP)
• Tests d'intrusion VPN (5 SP)

Total : 18 SP (vélocité moyenne de l'équipe)

Objectif :

Inspecter les progrès vers le Sprint Goal et adapter

Format classique (3 questions) :

• Qu'ai-je fait HIER pour aider à atteindre le Sprint Goal ?
• Que vais-je faire AUJOURD'HUI pour aider à atteindre le Sprint Goal ?
• Est-ce que je vois des OBSTACLES qui empêchent l'équipe ?

Bonnes pratiques :

• Rester FACTUEL et concis
• Ne PAS résoudre les problèmes (le faire après)
• Ce n'est PAS un reporting au SM ou PO
• Se concentrer sur l'objectif du Sprint
• Identifier les blocages rapidement

Variante : Walk the Board

Passer en revue les tâches de DROITE à la GAUCHE (Done → To Do). Focus : finir ce qui est commencé avant d'en commencer de nouvelles !

Objectifs :

Présenter l'Incrément aux stakeholders

Présenter l'Incrément aux stakeholders

Présenter l'Incrément aux stakeholders

Présenter l'incrément aux stakeholders

Présenter l'incrément aux stakeholders

Le contenu de la page 11 semble incomplet dans le PDF original. Voici ce qui est présent :

Recueillir du FEEDBACK utilisateur

Adapter le Product Backlog selon les retours

Discuter de ce qui a changé dans l'environnement

Calculer la vélocité (Story Points terminés)

Participants : Équipe Scrum + Stakeholders (clients, utilisateurs, RSSI, DSI...)

Format de la Sprint Review :

1. Le PO présente le Sprint Goal et ce qui a été fait
2. L'équipe fait la DÉMO des User Stories finies (respectant la DoD)
3. Les stakeholders posent des questions et donnent leur feedback
4. Discussion sur le Product Backlog : ajouts, modifications, priorisations
5. Projection : prochaines fonctionnalités, timeline, capacité

Exemple Sprint Review AIS :

Sprint terminé : 'Sécurisation périmètre réseau'

DÉMO :

• Firewall configuré avec règles de filtrage actives
• IDS/IPS Snort opérationnel avec alertes en temps réel
• Dashboard Grafana montrant le trafic réseau

FEEDBACK RSSI :

• 'Excellent ! Pouvez-vous ajouter des règles pour bloquer les pays à risque ?'
• 'J'aimerais des rapports hebdomadaires automatiques'

ADAPTATION Product Backlog :

• Nouvelle US ajoutée : Géo-blocking pays sensibles (5 SP)
• Nouvelle US ajoutée : Rapports automatisés (3 SP)

Événement 5 : La Sprint Rétrospective

Après la Review. Durée max : 3h pour 4 semaines (soit 45min/semaine)

Format standard (5 étapes) :

1. Préparer le terrain : créer une atmosphère de confiance
2. Rassembler les données : qu'est-ce qui s'est passé ?
3. Générer des insights : pourquoi cela s'est produit ?
4. Décider quoi faire : 1-3 actions concrètes pour le prochain Sprint
5. Clôturer : valider les actions et remercier l'équipe

Techniques populaires de rétrospective :

• Start / Stop / Continue : ce qu'on commence, arrête, continue
• Glad / Sad / Mad : émotions par rapport aux événements
• Speed Boat : ancres (freins), vent (accélérateurs), île (objectifs)
• Timeline : événements marquants du Sprint sur une ligne de temps
• 5 Pourquoi : creuser la cause racine d'un problème

Exemple Rétrospective AIS :

Technique utilisée : Start / Stop / Continue

Revues de code systématiques

ACTIONS pour le prochain Sprint :

1. Créer un checklist de tests de sécurité
2. Impliquer le RSSI dès le Sprint Planning
3. Bloquer 30 min/jour pour la documentation

Planification et Estimation Agile

Les Story Points

• Unité de mesure RELATIVE (pas en heures !)
• Mesure : Complexité + Quantité de travail + Risque + Incertitude
• Ne dépend PAS de qui fait le travail
• Suite de Fibonacci modifiée : 0, 1, 2, 3, 5, 8, 13, 20, 40, 100, ?, ∞

Exemples Story Points AIS :

• 1 SP : Changer un mot de passe admin (trivial)
• 2 SP : Créer une règle firewall simple
• 3 SP : Configurer un VLAN basique
• 5 SP : Installer et configurer un serveur DNS

• 8 SP : Déployer un système IDS/IPS
• 13 SP : Migration serveur vers le cloud
• 20 SP : Refonte complète architecture réseau
• 40 SP : Projet de certification ISO 27001 (TROP GROS → découper !)

Le Planning Poker

Technique d'estimation la plus populaire en Scrum (Durant la réunion Sprint planning)

Déroulement :

1. Choisir une User Story de RÉFÉRENCE (généralement 2 ou 3 SP)
2. Le PO présente une User Story à estimer
3. L'équipe pose des questions pour clarifier
4. Chaque membre choisit une carte SECRÈTEMENT
5. Tout le monde révèle sa carte EN MÊME TEMPS
6. En cas de désaccord : les extrêmes expliquent leur choix
7. Nouvelle estimation jusqu'au consensus
8. Répéter pour toutes les stories du Sprint

Signification des cartes spéciales :

• ? → Besoin de plus d'informations / Je ne sais pas
• ∞ (Infini) → Story TROP GROSSE, il faut la découper
• ● → Besoin d'une pause !

La Vélocité

• Somme des Story Points des User Stories COMPLÈTEMENT FINIES durant un Sprint
• Mesure la CAPACITÉ réelle de l'équipe
• Se stabilise après 3-5 Sprints
• Utilisée pour faire des PROJECTIONS
• N'est PAS un objectif à maximiser !

Exemple Vélocité AIS :

Équipe de 5 personnes (3 admins sys, 1 admin réseau, 1 expert sécu)

• Sprint 1 : 12 SP (découverte, mise en place)
• Sprint 2 : 18 SP (équipe monte en compétence)
• Sprint 3 : 20 SP (rythme de croisière)
• Sprint 4 : 19 SP (stable)
• Sprint 5 : 21 SP (stable)

→ Vélocité moyenne stabilisée : ~20 SP par Sprint de 2 semaines

PARTIE 3 : SCRUM POUR Cybersécurité

Exemples Concrets et Cas Pratiques

Exemple : Projet Cybersécurité - Mise en place SOC

Équipe Scrum :

• Product Owner : RSSI (Responsable Sécurité des Systèmes d'Information)
• Scrum Master : Chef de projet sécurité
• Dev Team : 2 analystes SOC, 1 expert SIEM, 1 ingénieur réseau, 1 pentester

Product Backlog (extrait) :

• US#1 : Déploiement SIEM centralisé (Splunk/ELK) - 20 SP
• US#2 : Configuration collecte logs serveurs critiques - 8 SP
• US#3 : Création règles de corrélation pour détection intrusions - 13 SP
• US#4 : Intégration flux threat intelligence - 8 SP
• US#5 : Dashboard temps réel pour analystes SOC - 5 SP

Sprint 1 (2 semaines) - Sprint Goal : 'SOC opérationnel avec détection basique'

Sprint Backlog :

• US#1 : Déploiement SIEM (20 SP)
• US#2 : Collecte logs (8 SP)

Total : 28 SP (première estimation, équipe teste sa capacité)

Definition of Done :

• ✓ SIEM installé et accessible
• ✓ Logs de 10+ serveurs centralisés
• ✓ Dashboard basique fonctionnel
• ✓ Documentation technique
• ✓ Tests de bon fonctionnement

Sprint Review Résultats :

DÉMO : SIEM opérationnel, logs collectés en temps réel, alertes basiques fonctionnelles

FEEDBACK RSSI : 'Excellent ! Priorisons les règles de détection d'intrusion pour le prochain Sprint'

VÉLOCITÉ : 28 SP terminés → première vélocité de référence

PARTIE 4 : MODÈLES SCRUM PRÊTS À UTILISER

Template 1 : Product Backlog

Modèle de Product Backlog pour vos projets AIS

ID	User Story	Priorité	Story Points	Sprint	Statut
US-001	Déployer firewall périmétrique	1-Critique	13	Sprint 1	Done
US-002	Configuration IDS/IPS	1-Critique	8	Sprint 1	Done
US-003	Segmentation VLAN	2-Important	5	Sprint 2	In Progress
US-004	VPN site-to-site	2-Important	13	Sprint 2	To Do

Template 2 : User Story Détaillée

Champ	Valeur
ID	US-003
Titre	Segmentation réseau par VLAN
User Story	En tant qu'admin réseau, je veux segmenter le réseau en VLANs afin d'isoler les services critiques et améliorer la sécurité
Priorité	2 - Important
Story Points	5
Sprint	Sprint 2
Critères d'Acceptation	✓ 5 VLANs créés (Admin, Prod, DMZ, Users, IoT) ✓ Routage inter-VLAN configuré ✓ ACLs appliquées entre VLANs ✓ Tests de connectivité réussis
Tâches Techniques	• Planification IP par VLAN (2h) • Configuration switches (8h) • Tests et validation (4h) • Documentation (2h)
Definition of Done	✓ Config appliquée sur tous les switches ✓ Tests de sécurité passés ✓ Documentation technique ✓ Validé par le PO
Dépendances	Aucune
Notes	Coordonner avec l'équipe sécurité pour les ACLs

Definition of Done Template (Liste de vérification)

• Configuration/Code écrit et déployé
• Tests unitaires écrits et passants
• Tests d'intégration réussis
• Tests de sécurité effectués (scan vulnérabilités)
• Code review / Peer review effectué
• Documentation technique rédigée et à jour
• Logs et monitoring configurés
• Sauvegarde de configuration effectuée
• Plan de rollback documenté
• Validé par le Product Owner
• Déployé en environnement de production (ou pré-prod)
• Aucun bug bloquant

Template 3 : Scrum Board Visuel

PARTIE 5 : ATELIER PRATIQUE FINAL

Mini-Projet Scrum : Déploiement Sécurisé d'une Infrastructure

Contexte du Projet

Vous êtes une équipe d'administrateurs infrastructures sécurisées (AIS) dans une PME de 150 employés. La direction vous confie un projet critique :

Le site distant doit :

• Être connecté au siège de manière sécurisée (VPN)
• Héberger 30 postes utilisateurs + 3 serveurs locaux
• Respecter les normes de sécurité de l'entreprise

Étape 1 : Constitution de l'Équipe Scrum

Formez une équipe de 4-6 personnes et attribuez les rôles :

Étape 2 : Création du Product Backlog (30 min)

Avec toute l'équipe, créez le Product Backlog du projet :

Suggestions de User Stories (à compléter et prioriser) :

1. US#1 : Déployer architecture réseau site distant (routeur, switches, WiFi)
2. US#2 : Configurer VPN site-to-site sécurisé
3. US#3 : Installer et configurer firewall local
4. US#4 : Déployer serveurs Windows Server (AD, DNS, DHCP)
5. US#5 : Configurer système de sauvegarde automatique
6. US#6 : Mettre en place supervision réseau (PRTG/Zabbix)
7. US#7 : Implémenter politique de sécurité (GPO, antivirus)
8. US#8 : Tests de sécurité et pentest
9. US#9 : Formation utilisateurs et admins locaux
10. US#10 : Documentation complète infrastructure

Travail à faire :

1. Écrire chaque User Story au format : 'En tant que... je veux... afin de...'
2. Prioriser par VALEUR (1=Critique, 2=Important, 3=Normal)
3. Estimer en Story Points avec Planning Poker
4. Définir une Definition of Done commune

Étape 3 : Sprint Planning du Sprint 1 (30 min)

Planifiez votre premier Sprint de 2 semaines :

1. Définir le Sprint Goal

2. Sélectionner les User Stories du Sprint

• → En fonction de votre vélocité estimée (20-25 SP pour débuter)
• → Prioriser les US qui permettent d'atteindre le Sprint Goal

3. Découper les User Stories en tâches techniques

Exemple US#2 (VPN site-to-site) :

• Tâche 1 : Choisir solution VPN (IPsec/OpenVPN) - 2h
• Tâche 2 : Commander équipement si nécessaire - 4h
• Tâche 3 : Configurer VPN côté siège - 8h
• Tâche 4 : Configurer VPN côté site distant - 8h
• Tâche 5 : Tests de connectivité et sécurité - 4h
• Tâche 6 : Documentation - 2h

4. Créer votre Sprint Backlog et Scrum Board

Étape 4 : Simulation d'un Sprint (45 min)

Simulez le déroulement d'un Sprint complet :

Jour 1-2 : Démarrage du Sprint

• → Chaque membre prend des tâches du Sprint Backlog
• → Commencez à travailler (simulation : discutez de COMMENT vous feriez)

Jour 3 : Premier Daily Scrum (5 min)

• → Chacun répond aux 3 questions
• → Identifiez les blocages éventuels
• → Mettez à jour le Scrum Board

Jour 5 : Obstacle rencontré !

Jour 7 : Daily Scrum (5 min)

• Point d'avancement
• Le Sprint Goal est-il toujours atteignable ?

Jour 10 : Fin du Sprint

• Quelles User Stories sont FINIES (DoD respectée) ?
• Quelles User Stories retournent au Product Backlog ?

Étape 5 : Sprint Review (20 min)

Présentez le travail accompli :

1. Le PO présente le Sprint Goal et rappelle ce qui était prévu

2. L'équipe fait la DÉMO des User Stories finies

• → Expliquez ce qui a été fait techniquement
• → Montrez les résultats (même si simulation)

3. Recueillez le feedback (formateur = stakeholder)

• → Qu'est-ce qui fonctionne bien ?
• → Que faudrait-il ajouter/modifier ?

4. Calculez la VÉLOCITÉ

• → Somme des Story Points des US terminées
• → Cette vélocité servira pour planifier le Sprint 2

5. Adaptez le Product Backlog si nécessaire

Étape 6 : Sprint Retrospective (20 min)

Réfléchissez à l'amélioration du processus :

Technique recommandée : Start / Stop / Continue

ACTIONS pour le prochain Sprint :

• → Sélectionnez 1 à 3 actions d'amélioration CONCRÈTES
• → Assignez un responsable pour chaque action
• → Vérifiez lors de la prochaine rétro si elles ont été appliquées

Livrables Attendus de l'Atelier

• Product Backlog complet (10+ User Stories)
• 3 User Stories détaillées avec critères d'acceptation
• Definition of Done de votre équipe
• Sprint Backlog du Sprint 1 avec tâches techniques
• Sprint Goal clairement formulé
• Scrum Board avec état d'avancement
• Compte-rendu de Sprint Review
• Actions d'amélioration de la Rétrospective

Évaluation

Cet atelier sera évalué sur :

• Compréhension des rôles Scrum (20%)
• Qualité du Product Backlog et User Stories (25%)
• Respect des événements Scrum (25%)
• Collaboration et communication d'équipe (20%)
• Livrables produits (10%)

CONCLUSION

Ce que vous avez appris :

• ✓ Les fondamentaux de l'agilité et le Manifeste Agile
• ✓ Le framework Scrum complet : rôles, artefacts, événements
• ✓ Comment planifier et estimer avec les Story Points et Planning Poker
• ✓ Comment appliquer Scrum à des projets concrets d'infrastructure, réseau et cybersécurité
• ✓ Les modèles et templates prêts à utiliser dans vos projets

Prochaines étapes :

1. Appliquez Scrum dans vos projets de formation et stages
2. Entraînez-vous avec votre équipe sur des mini-projets
3. Participez à des rétrospectives pour améliorer continuellement
4. Considérez une certification Scrum (PSM I, CSM) pour valoriser vos compétences
5. Rejoignez des communautés agiles pour échanger avec d'autres praticiens

Ressources complémentaires :

• Scrum Guide 2025 Expansion Pack (scrumexpansion.org)
• Scrum Guide officiel 2020 (scrumguides.org)
• Manifeste Agile (agilemanifesto.org)
• Certifications : Scrum.org (PSM), Scrum Alliance (CSM)
• Livre recommandé : "Scrum : Le guide pratique" - Claude Aubry

Spécialisation AIS :

Pour les projets d'infrastructure et sécurité :

• Intégrez la sécurité dès la conception (Security by Design)
• Documentez systématiquement (configurations, procédures)
• Automatisez les tests de sécurité dans votre DoD
• Collaborez étroitement avec les équipes sécurité (RSSI, SOC)
• Maintenez une veille technologique continue