Cours/Saison C1
Saison C14 modules

Saison C1. Gestion de projet et Analyse de Risque

Modules

C101️ C101. Les Fondamentaux de la Gestion de ProjetC102C102. Agilité, Scrum & Outils ProjetC103C103. Gestion des risquesC104️ C104. Sécurité et continuité d'activité

Le Contexte : En tant que professionnels de l'IT, nous ne faisons pas que de la technique pure. Nous devons répondre à des besoins précis, dans des délais donnés et avec un budget limité. Cette saison couvre l'organisation du travail (comment on mène un projet de A à Z) et la sécurité organisationnelle (comment on gère les risques et la continuité d'activité).

Au programme de la saison :

  • Méthodologies : Cycle en V, Agile, Scrum.
  • Pilotage : Planification et suivi.
  • Analyse de Risques : Menaces, vulnérabilités et gestion du risque.
  • Continuité : PCA (Continuité) et PRA (Reprise d'activité).

🏗️ C101. Les Fondamentaux de la Gestion de Projet

Objectif : Comprendre ce qu'est un projet, pourquoi il faut le gérer rigoureusement, et découvrir les méthodologies classiques comme le Cycle en V, adaptées aux projets d'infrastructure stable.

1. Qu'est-ce qu'un Projet ?

Un projet se définit par son caractère temporaire et unique. Ce n'est pas une opération courante (run), mais une entreprise avec un début et une fin précise pour créer un produit ou service unique.

  • Caractéristiques clés : Un objectif précis, des ressources limitées (budget, temps, humains), et un résultat unique (produit ou service).
  • Exemples IT : Déploiement de la fibre, migration vers le Cloud (ex: Netflix vers AWS), mise en place d'un ERP.
  • Contraintes : Elles sont techniques, humaines, financières, sécuritaires et liées à l'exploitation.

2. La Gestion de Projet & Le Triangle d'Or (Qualité - Coûts - Délais)

Gérer un projet, c'est maintenir l'équilibre permanent entre trois contraintes antagonistes (le "Triangle de la gestion de projet") :

  1. Qualité (Le résultat répond-il au besoin ?)
  2. Coûts (Budget respecté ?)
  3. Délais (Temps respecté ?)

Règle d'or : Toucher à l'un impacte les autres. Si vous réduisez le délai, vous devrez augmenter le coût (plus de ressources) ou réduire la qualité (moins de fonctionnalités).

3. La Matrice RACI (Qui fait quoi ?)

Pour éviter le flou artistique dans les responsabilités, on utilise la matrice RACI. Elle définit le rôle de chaque acteur pour chaque tâche du projet :

LettreRôle (Anglais)Rôle (Français)Description
RResponsibleRéalisateurCelui qui fait le travail. Il "tient le stylo". (Il faut au moins 1 R).
AAccountableApprobateurLe chef. Celui qui valide et qui est responsable du résultat final (celui qui "va en prison" si ça rate). Il n'y a qu'un seul A par tâche.
CConsultedConsultéL'expert qu'on interroge pour avoir des infos avant de décider (communication bidirectionnelle).
IInformedInforméCelui qu'on met en copie (CC) une fois la tâche finie ou la décision prise (communication unidirectionnelle).

4. Les Méthodologies (Cycle de vie)

Il existe plusieurs façons de piloter un projet, du plus rigide au plus souple :

  • Cascade (Waterfall) : Séquentiel. On ne revient jamais en arrière. Trop rigide pour l'IT moderne.
  • Cycle en V : Amélioration de la cascade. Chaque phase de conception a sa phase de validation associée. Très structuré.
  • Agile / Scrum : Itératif. On livre petit à petit pour s'adapter aux changements.
  • DevOps : Fusion Développement + Opérations pour automatiser et livrer en continu.

5. Focus : Le Cycle en V

C'est le modèle classique pour les projets d'infrastructure lourds où l'erreur coûte cher (ex: refonte d'un réseau physique).

Le principe : Une phase descendante de conception, suivie d'une phase remontante de tests.

  • Phase Descendante (Conception) :

    1. Analyse des besoins : Comprendre ce que veut le client.
    2. Spécifications : Définir fonctionnellement ce qu'on va faire.
    3. Conception Générale & Détaillée : Comment on va le faire techniquement (Architecture).
    4. Réalisation : On construit !

  • Phase Ascendante (Validation) :

    1. Tests Unitaires : Vérifier chaque petit bout de code/config isolé.
    2. Tests d'Intégration : Vérifier que les bouts fonctionnent ensemble.
    3. Tests de Validation : Vérifier que ça répond aux spécifications.
    4. Recette : Le client valide que c'est ce qu'il voulait (VABF/VSR).

Bilan du Cycle en V :

  • ✅ Avantages : Prévisible, documenté, rassurant, idéal quand le besoin est clair et stable.
  • ❌ Inconvénients : "Effet tunnel" (on ne voit le résultat qu'à la fin), peu flexible, lourd en documentation.

cycleV

Challenge C101 : Effectuer la note de cadrage d'un projet.

📚 Ressources :

Retour en haut

🏃 C102. Agilité, Scrum & Outils Projet

Objectif : Comprendre la philosophie Agile (née en réaction aux échecs des méthodes traditionnelles), maîtriser le framework Scrum (le plus utilisé) et découvrir les outils concrets pour structurer et suivre un projet.

1. La Philosophie Agile

L'Agile n'est pas une "méthode" stricte, c'est une approche et une philosophie née du Manifeste Agile (2001).

  • Le Constat : Les projets classiques (Cycle en V) échouent souvent car ils sont trop rigides face aux changements.

  • Les Principes :

    • Forte implication du client.
    • Développement itératif (cycles courts) et incrémental (on livre petit à petit).
    • Adaptation continue au changement.

  • Quand l'utiliser ? Quand le besoin est flou ou changeant, ou pour innover.

  • Agile en Infra ? Ça fonctionne pour le Cloud, l'automatisation ou la supervision (livraison progressive). Ça fonctionne mal pour les migrations lourdes "One-shot" (ex: déménagement physique de Datacenter).

Manifeste

2. Le Framework Scrum

Scrum est le cadre Agile le plus populaire. Il organise le travail en cycles courts appelés Sprints (1 à 4 semaines max).

A. Les 3 Rôles (La Scrum Team)
  1. Product Owner (PO) : La voix du client. Il définit "Quoi" faire (gère le Backlog). Il est responsable de la valeur métier.
  2. Scrum Master : Le coach / facilitateur. Il s'assure que la méthode est respectée et protège l'équipe des perturbations externes (Servant Leader).
  3. L'Équipe de Développement : Ceux qui font ("Comment"). Elle est auto-organisée et pluridisciplinaire (Dev, Ops, Test...).
B. Les Artefacts (Les documents)
  • Product Backlog : La liste ordonnée de tout ce qu'il y a à faire (les besoins). Géré par le PO.
  • Sprint Backlog : La liste des tâches sélectionnées pour le Sprint en cours.
  • Incrément : Le livrable utilisable fourni à la fin du Sprint.
C. Les Cérémonies (Les rituels)
  • Sprint Planning : On décide ce qu'on va faire dans le Sprint.
  • Daily Scrum : Mêlée quotidienne de 15 min. (Qu'ai-je fait hier ? Que fais-je aujourd'hui ? Ai-je un blocage ?).
  • Sprint Review : Démonstration du travail fini aux parties prenantes (Feedback).
  • Sprint Retrospective : L'équipe analyse son fonctionnement pour s'améliorer au prochain Sprint.

scrum

3. Outils de Structuration & Planification

Pour qu'un projet n'aille pas dans le mur, il faut le découper et le suivre.

A. Structurer (Découper)
  • PBS (Product Breakdown Structure) : Découpage graphique du produit en composants. (Ex: Pour une infra -> Réseau, Serveurs, Stockage, OS).
  • WBS (Work Breakdown Structure) : Découpage des tâches nécessaires. (Ex: Installer l'OS, Configurer l'IP, etc). En français, on dit souvent SDP – Structure de Découpage du Projet.
B. Planifier & Suivre
  • Gantt : Idéal pour le Cycle en V. Visualise le temps, les jalons et les dépendances (chemin critique).
  • Kanban : Idéal pour l'Agile/Run. Visualise le flux de travail (To Do / Doing / Done). Permet de limiter le travail en cours (WIP) pour fluidifier la prod.

4. La Communication Projet

Un projet réussit grâce à la technique, mais échoue souvent à cause de la communication.

  • Identifier les acteurs : Sponsor, MOA (Métier), MOE (Tech), Utilisateurs finaux, Prestataires.
  • Adapter le message : On ne parle pas technique au Directeur Financier, on ne parle pas budget aux techniciens.
  • Transparence : Partager les succès mais aussi les risques et les difficultés.

En résumé 💡

  • Agile = Philosophie d'adaptation.
  • Scrum = Cadre de travail avec des Rôles (PO, SM, Dev), des Rituels (Daily, Review...) et des Sprints.
  • PBS/WBS = Pour savoir quoi faire.
  • Gantt/Kanban = Pour savoir quand et comment le suivre.

Challenge C102 : Créer le WBS, matrice RACI et diagramme Gantt.

📚 Ressources :

Retour en haut

🎲 C103. Gestion des risques

Objectif : Un projet informatique ne se déroule jamais exactement comme prévu. Ce cours apprend à anticiper les imprévus (risques) pour ne pas les subir. On y aborde la méthodologie classique (PMI/ISO) et la méthode spécifique française EBIOS RM.

1. Comprendre le Risque

Un risque n'est pas un problème avéré, c'est une potentialité.

  • Définition : C'est un événement incertain qui, s'il survient, aura un effet négatif sur les objectifs du projet (Planning, Budget, Qualité, Sécurité).

  • Les 3 Composantes :

    1. La Cause : L'origine (ex: Matériel vieillissant).
    2. L'Événement : Ce qui se produit (ex: Panne du serveur).
    3. La Conséquence : L'impact (ex: Interruption de service, retard).

  • Typologie : Les risques peuvent être Techniques (panne, bug), Humains (départ d'un expert, erreur), Organisationnels, Juridiques ou Externes (météo, fournisseur).

2. Identification et Évaluation

Avant de traiter, il faut trouver les risques et les classer.

  • Identification : On utilise des méthodes comme le Brainstorming, l'analyse SWOT (Forces/Faiblesses), les Checklists ou le diagramme d'Ishikawa (Causes/Effets).

  • Évaluation (La Criticité) : Chaque risque est noté sur deux axes :

    • Probabilité : Est-ce que ça risque vraiment d'arriver ? (Échelle 1 à 3 ou 1 à 5).
    • Impact : Si ça arrive, est-ce grave ? (Échelle 1 à 3 ou 1 à 5).

  • Formule : Criticité = Probabilité x Impact.

  • La Matrice des Risques (Heatmap) : On place les risques sur un graphique.

    • 🟥 Zone Rouge : Risques critiques (Action immédiate).
    • 🟧 Zone Orange : À surveiller.
    • 🟩 Zone Verte : Acceptable.

3. Documentation et Stratégies de Traitement

Une fois les risques identifiés, on les consigne dans un Registre des Risques (document vivant du projet) et on décide quoi faire.

Il existe 4 stratégies pour traiter un risque :

  1. L'Évitement (Refus) : On change le plan pour supprimer le risque totalement (ex: renoncer à une techno trop récente).
  2. L'Atténuation (Réduction) : On baisse la probabilité ou l'impact (ex: mettre des backups pour réduire l'impact d'une panne). C'est la stratégie la plus courante.
  3. Le Transfert (Partage) : On déplace le risque sur un tiers (ex: prendre une assurance, sous-traiter).
  4. L'Acceptation : Le risque est faible ou trop coûteux à traiter. On l'accepte et on assume les conséquences s'il survient.

4. La Méthode EBIOS RM

EBIOS Risk Manager est la méthode de référence en France (créée par l'ANSSI) pour la cybersécurité. Contrairement à une analyse de risque projet classique (focalisée sur le délai/budget), EBIOS se focalise sur la sécurité de l'information.

Elle se déroule en 5 Ateliers :

  1. Cadrage & Socle : Quoi protéger ? Quel est le contexte ? (Le périmètre).
  2. Sources de risques : Qui sont les attaquants ? (Cybercriminels, concurrents, étatiques...).
  3. Scénarios Stratégiques : Comment l'attaquant pourrait atteindre ses objectifs au niveau "haut" ? (ex: compromettre un prestataire).
  4. Scénarios Opérationnels : Comment cela se passe techniquement ? (Le chemin d'attaque).
  5. Traitement du risque : Quelles mesures de sécurité mettre en place ?

Quand l'utiliser en projet ? Pour les projets sensibles, impliquant des données critiques (RGPD), ou des changements majeurs d'infrastructure. Elle est trop lourde pour des petits projets simples.

💡 En résumé

  • Risque = Événement incertain avec impact négatif.
  • Criticité = Probabilité × Impact.
  • Traitement = Éviter, Atténuer, Transférer ou Accepter.
  • EBIOS RM = La méthode ANSSI pour les risques Cyber (5 ateliers).

Challenge C103 : Analyser les risques pour notre projet.

📚 Ressources :

Retour en haut

🛡️ C104. Sécurité et continuité d'activité

Objectif : Comprendre que la sécurité n'est pas une option à ajouter à la fin, mais une fondation ("Security by Design"). Apprendre à différencier la continuité (ne pas s'arrêter) de la reprise (redémarrer après la panne) et maîtriser les métriques critiques RTO/RPO.

1. La Sécurité des Systèmes d'Information (SSI)

La sécurité vise à protéger le patrimoine informationnel de l'entreprise. Elle repose sur le trépied DIC (ou CID) :

  • Disponibilité : Le système doit fonctionner quand on en a besoin.
  • Intégrité : Les données ne doivent pas être modifiées par erreur ou malveillance.
  • Confidentialité : Seules les personnes autorisées ont accès aux données.
  • (On ajoute souvent la Traçabilité ou Preuve pour savoir "qui a fait quoi").

Le Mécanisme du Risque : Pour qu'il y ait un problème de sécurité, il faut la rencontre de trois éléments :

  1. Un Bien (Asset) : Ce qui a de la valeur (Serveur, Donnée client).
  2. Une Vulnérabilité (Faille) : Une faiblesse dans le bien (ex: Windows pas à jour).
  3. Une Menace (Threat) : Ce qui va exploiter la faille (ex: Virus, Hacker, Incendie).

Risque = Menace × Vulnérabilité

Les Bonnes Pratiques (Défense en profondeur) :

  • Prévention : Empêcher l'attaque (Pare-feu, Mises à jour, Moindre privilège).
  • Protection : Limiter les dégâts (Chiffrement, Segmentation réseau).
  • Détection : Voir l'attaque (Logs, IDS/IPS, Supervision).
  • Récupération : Revenir à la normale (Sauvegardes).

2. PCA vs PRA : Quelle différence ?

Ces deux plans répondent à la question : "Que fait-on si le datacenter brûle ?".

  • PCA (Plan de Continuité d'Activité) :

    • But : Assurer la survie de l'entreprise PENDANT le sinistre.
    • Principe : On fonctionne en "mode dégradé" mais on ne s'arrête pas.
    • Exemple : Bascule automatique sur un serveur de secours, télétravail si les bureaux sont inaccessibles.

  • PRA (Plan de Reprise d'Activité) :

    • But : Redémarrer l'activité informatique APRÈS un arrêt complet.
    • Principe : On remonte les infrastructures, on restaure les sauvegardes et on relance les applis.
    • Exemple : Réinstaller les serveurs après un crash disque et restaurer la base de données.

3. Les Métriques Critiques : RTO & RPO

Ce sont les deux indicateurs que vous devez définir avec le métier (le client) avant de concevoir votre architecture de sauvegarde.

  • RTO (Recovery Time Objective) : Durée maximale d'interruption admissible.

    • Question : "Combien de temps pouvons-nous rester en panne sans couler ?"
    • Exemple : RTO = 4h (Le service doit être rétabli en 4h max).

  • RPO (Recovery Point Objective) : Perte de données maximale admissible.

    • Question : "Jusqu'à quand accepte-t-on de perdre des données ?"
    • Exemple : RPO = 24h (On accepte de perdre le travail de la journée -> Sauvegarde nocturne suffisante). Si RPO = 0, il faut de la réplication synchrone temps réel.

4. Les Solutions Techniques

Pour respecter le RTO et le RPO, on utilise trois leviers :

  • A. La Redondance (Haute Disponibilité)

    • Pour un RTO proche de 0 (pas de coupure).
    • Actif/Actif (Load Balancing) : Plusieurs serveurs travaillent en même temps. Si l'un tombe, les autres continuent.
    • Actif/Passif (Failover) : Un serveur travaille, l'autre dort. Si le premier tombe, le second prend le relais.

  • B. Les Sauvegardes (Backup)

    • Indispensable contre l'effacement accidentel ou les ransomwares (là où la redondance ne sert à rien car elle réplique l'erreur !).
    • Règle du 3-2-1 :
      • 3 copies des données.
      • Sur 2 supports différents (Disque + Bande/Cloud).
      • Dont 1 copie hors site (en cas d'incendie).

  • C. La Supervision

    • C'est les yeux de l'admin. Elle permet de passer d'une gestion réactive ("C'est cassé") à proactive ("Le disque va bientôt être plein").

💡 En résumé

  • Sécurité = Disponibilité + Intégrité + Confidentialité.
  • PCA = On continue (Redondance).
  • PRA = On repart (Sauvegardes).
  • RTO = Temps max de panne.
  • RPO = Perte max de données.
  • Redondance ≠ Sauvegarde (Il faut les deux !).

Challenge C104 : Définir un scénario d’incident majeur et les mesures, procédures, PRA-PCA type.

📚 Ressources :

Retour en haut

Précédent

📜 Scripting

Suivant

☁ Cloud