Fiche de révision : Gestion de Projet et Analyse Fonctionnelle

📋 Plan du Cours

1. Fondamentaux de la gestion de projet
2. Planification, jalons et périmètre
3. Chemin critique et matrice RACI
4. Gestion des risques projet
5. Risques techniques et conformité
6. Besoins fonctionnels
7. Besoins non fonctionnels
8. Cas d'utilisation UML
9. Acteurs et frontière du système

📖 1. Fondamentaux de la gestion de projet

🔑 Notions clés & Définitions

• Projet : Un projet est une entreprise temporaire visant la création d’un produit, d’un service ou d’un résultat unique.
• Triple contrainte traditionnelle : La triple contrainte relie le périmètre, le temps et le coût, de sorte que changer un axe impacte les deux autres.
• SMART : SMART désigne des critères pour formuler un objectif clair, mesurable et réaliste avec un cadre temporel.
• Kick-off : Le kick-off est la réunion officielle qui réunit l’équipe et le client pour lancer la phase d’exécution.
• Objectif SMART : Un objectif SMART est formulé pour être spécifique, mesurable et réaliste, avec des critères permettant de vérifier l’atteinte.

📝 Points essentiels

• Un projet se distingue par sa durée limitée (début et fin) et son unicité de livrable.
• Dans la triple contrainte, toute modification de périmètre, temps ou coût influence automatiquement les deux autres axes.
• Les critères SMART assurent qu’un objectif est clair, quantifiable et réaliste.

💡 Astuce mémo

Triple contrainte = PTC : Périmètre, Temps, Coût, tout bouge quand on touche à un seul coin.

📖 2. Planification, jalons et périmètre

🔑 Notions clés & Définitions

• Jalon : Un jalon est un repère chronologique marquant la fin d’une étape clé, avec une durée de zéro.
• Périmètre : Le périmètre (scope) regroupe l’ensemble des travaux inclus (et exclus) nécessaires pour livrer le résultat requis.
• Planning d’un projet : Le planning d’un projet correspond à la représentation de l’enchaînement temporel des tâches et de leurs interdépendances.
• Diagramme de Gantt : Le diagramme de Gantt est un outil graphique standard pour visualiser le planning et les dépendances temporelles.

📝 Points essentiels

• Un jalon sert de repère du type « validation des spécifications » sans consommer de temps en lui-même.
• Le périmètre délimite strictement ce qui est compris dans les livrables du projet.
• Le diagramme de Gantt est utilisé pour suivre l’enchaînement temporel des tâches et leurs interdépendances.

💡 Astuce mémo

Jalon = « arrêt sur image » : événement important, durée nulle, repère dans le temps.

📖 3. Chemin critique et matrice RACI

🔑 Notions clés & Définitions

• Chemin critique : Le chemin critique est la séquence de tâches qui fixe la durée totale la plus courte du projet.
• Marge totale : La marge totale mesure le décalage possible sans affecter l’échéance globale du projet.
• Matrice RACI : La matrice RACI répartit les rôles et responsabilités : Réalisateur, Approbateur, Consulté et Informé.
• Livrable : Un livrable est un produit, un résultat ou une capacité unique et vérifiable permettant d’achever une phase ou un projet.

📝 Points essentiels

• Le chemin critique est caractérisé par l’absence de marge, donc tout retard y décale le projet.
• Si une tâche sur le chemin critique prend 3 jours de retard, le projet global prend aussi 3 jours de retard.
• Un rôle RACI permet d’éviter les confusions sur « qui fait quoi » dans le projet.
• Un livrable peut être tangible (rapport, code) ou intangible (capacité fournie) tant qu’il est vérifiable.

💡 Astuce mémo

Chemin critique = « marge zéro » : retarder = retarder tout le projet.

📖 4. Gestion des risques projet

🔑 Notions clés & Définitions

• Gestion des risques : La gestion des risques est un processus qui commence par l’identification des événements potentiels avant d’envisager l’analyse et le traitement.
• Identification des risques : L’identification des risques consiste à dresser la liste de ce qui pourrait survenir pour pouvoir ensuite analyser et traiter ces événements.
• Stratégie d’acceptation : L’acceptation consiste à ne pas modifier la probabilité ou l’impact du risque, en assumant ses effets.
• Stratégie de transfert : Le transfert consiste à déplacer la responsabilité financière ou l’exécution liée au risque vers une entité tierce.

📝 Points essentiels

• La première étape de la gestion des risques est l’identification des risques.
• En souscrivant à une assurance pour un risque négatif, on applique une stratégie de transfert.
• La logique du processus impose d’abord lister les risques avant de pouvoir les analyser ou les traiter.

💡 Astuce mémo

On ne traite pas un risque qu’on n’a pas trouvé : d’abord identifier, ensuite seulement agir.

📖 5. Risques techniques et conformité

🔑 Notions clés & Définitions

• Risque technique : Un risque technique concerne la faisabilité et les performances de la solution, notamment via la technologie choisie et l’architecture.
• Dette technique : La dette technique désigne le coût futur créé par des solutions rapides à court terme qui rendent la maintenance plus complexe et coûteuse.
• RGPD : Le RGPD impose des exigences de sécurité « by design » et impose d’identifier dès le cadrage les risques réglementaires liés aux données.
• Haute Disponibilité : La haute disponibilité est une approche d’architecture visant à éviter l’interruption d’un service critique en cas de panne.

📝 Points essentiels

• Un risque technique informatique est lié à l’adoption d’une technologie, à l’architecture ou aux performances des serveurs.
• La criticité d’un risque informatique s’évalue par la formule $C = P \times I$ (probabilité multipliée par impact).
• La dette technique vient de « développer vite et mal », ce qui oblige ensuite à refactoriser le code plus tard.
• En cas de RGPD, le risque majeur à identifier dès le cadrage est la fuite ou la compromission de données personnelles ou sensibles.
• Pour une panne d’un serveur critique, une architecture redondante (haute disponibilité) réduit l’impact en assurant la reprise immédiate du service.

💡 Astuce mémo

Dette technique = « dette » à rembourser plus tard par refactorisation.

📖 6. Besoins fonctionnels

🔑 Notions clés & Définitions

• Besoin fonctionnel : Un besoin fonctionnel décrit ce que le système doit faire pour répondre aux attentes de l’utilisateur.
• Fonctionnalité métier : Une fonctionnalité métier est une action offerte par le produit destinée à l’utilisateur final (par exemple une réinitialisation ou un export).
• User Story : Une user story (histoires utilisateurs) est un format Agile qui décrit le besoin par rôle, action et bénéfice.

📝 Points essentiels

• Un besoin fonctionnel correspond aux fonctionnalités du logiciel, c’est-à-dire aux actions et comportements attendus.
• Un exemple de besoin fonctionnel est « l’utilisateur doit pouvoir réinitialiser son mot de passe en cliquant sur Mot de passe oublié ».
• En Agile, les besoins fonctionnels sont généralement traduits en user stories au format « En tant que [rôle], je veux [action] afin de [bénéfice] ».
• Un « export de facture en PDF » est classé comme besoin fonctionnel.

💡 Astuce mémo

Fonctionnel = « l’utilisateur peut faire X ».

📖 7. Besoins non fonctionnels

🔑 Notions clés & Définitions

• Besoin non fonctionnel : Un besoin non fonctionnel précise les critères de qualité, sécurité, performance ou contraintes techniques du système.
• Performance système : La performance système correspond aux exigences de temps de réponse ou de rapidité de traitement attendues pour le logiciel.
• Disponibilité : La disponibilité est un critère de service continu, exprimé par un taux et une durée d’accès au système.
• Responsive Design : Le responsive design est un besoin non fonctionnel d’utilisabilité/adaptabilité quand l’interface doit s’ajuster à différents écrans.

📝 Points essentiels

• Un besoin non fonctionnel spécifie comment le système doit agir (robustesse, rapidité, sécurité, etc.).
• Un critère de sécurité comme le chiffrement des données au repos et en transit (PCI-DSS) relève des besoins non fonctionnels.
• Une phrase « afficher les résultats de la recherche en moins de 2 secondes » est un besoin non fonctionnel de performance/temps de réponse.
• « Disponible 24h/24 et 7j/7 avec 99,9 % » correspond à un besoin non fonctionnel de disponibilité (SLA).
• Le respect du RGPD pour le traitement des données est un besoin non fonctionnel de conformité (compliance) ou légal.

💡 Astuce mémo

Non fonctionnel = « contraintes de qualité » (sécurité, performance, disponibilité, conformité).

📖 8. Cas d'utilisation UML

🔑 Notions clés & Définitions

• Diagramme de cas d’utilisation : Le diagramme de cas d’utilisation modélise les besoins fonctionnels du système vus du point de vue des utilisateurs.
• Cas d’utilisation : Un cas d’utilisation représente une fonctionnalité globale disponible pour les utilisateurs et décrit ce que le système fournit.
• Verbe à l’infinitif : La nomination des cas d’utilisation utilise typiquement un libellé qui exprime une fonctionnalité, souvent avec une forme verbale à l’infinitif.

📝 Points essentiels

• Le diagramme de cas d’utilisation sert de passerelle entre la vision métier des utilisateurs et l’équipe technique.
• Un diagramme de cas d’utilisation représente les fonctionnalités globales disponibles, pas l’ordre chronologique d’exécution.

💡 Astuce mémo

Cas d’utilisation = « Quoi » le système fait, pas « Dans quel ordre » il le fait.

📖 9. Acteurs et frontière du système

🔑 Notions clés & Définitions

• Acteur UML : Un acteur est une entité externe au système (personne, autre système, périphérique) qui interagit directement avec lui.
• Frontière du système : La frontière du système délimite visuellement le périmètre de l’application, les acteurs restant à l’extérieur du cadre.
• Acteur passif (secondaire) : Un acteur secondaire est un acteur externe sollicité pour exécuter un processus, souvent représenté à droite du diagramme.
• Généralisation d’acteurs : La généralisation d’acteurs permet à un acteur (ex. Administrateur) d’hériter des cas d’utilisation communs à un autre (ex. Utilisateur connecté), plus des cas spécifiques.

📝 Points essentiels

• Un acteur UML est extérieur à la frontière du système et peut être un humain ou une autre application.
• La frontière du système est un cadre qui encadre les cas d’utilisation afin de délimiter ce qui est développé à l’intérieur du logiciel.
• Un système externe recevant des données (ex. une API de paiement) est modélisé comme un acteur secondaire passif.
• Le piège classique est de modéliser l’enchaînement séquentiel des tâches avec un diagramme de cas d’utilisation au lieu des cas disponibles.

💡 Astuce mémo

Acteurs dehors, frontière dedans : ça te force à cadrer « ce que le système offre ».

📊 Tableaux de synthèse

Fonctionnels vs non fonctionnels

⚠️ Pièges & confusions fréquents

1. Confondre le périmètre avec la durée ou le budget : le périmètre délimite les travaux inclus et exclus dans les livrables.
2. Croire qu’un jalon consomme du temps de projet : un jalon a une durée de zéro.
3. Penser qu’un retard sur une tâche critique peut être compensé : sur le chemin critique, la marge totale est nulle.
4. Mélanger risque technique et malentendu client : le risque technique concerne faisabilité, architecture et performances.
5. Classer une exigence de conformité (RGPD) comme fonctionnelle : la conformité est un besoin non fonctionnel.
6. Utiliser un diagramme de cas d’utilisation pour montrer l’ordre chronologique d’exécution des étapes : il montre des fonctionnalités disponibles.
7. Mettre des acteurs à l’intérieur de la frontière du système : ils doivent rester externes au cadre UML.

✅ Checklist Examen

1. Définir ce qu’est un projet (temporaire et unique) et citer la triple contrainte (périmètre, temps, coût).
2. Reconnaître les critères SMART (spécifique, mesurable, atteignable/réaliste, et temporel) et relier SMART à l’objectif clair et quantifiable.
3. Définir un jalon et expliquer qu’il marque une étape clé avec une durée nulle.
4. Définir le périmètre (scope) comme ce qui est inclus et exclu dans les livrables.
5. Identifier le diagramme de Gantt comme outil courant pour visualiser le planning et les dépendances.
6. Expliquer ce qu’est le chemin critique et conclure que tout retard sur ce chemin retarde la durée globale.
7. Calculer/justifier l’impact d’un retard sur une tâche critique via la notion de marge totale égale à zéro.
8. Décrire ce que couvre la matrice RACI (R, A, C, I) et son rôle de clarification des responsabilités.
9. Définir un livrable et distinguer tangible et intangible si nécessaire.
10. Décrire la première étape de la gestion des risques comme l’identification des risques.
11. Relier « souscrire une assurance » à la stratégie de transfert pour un risque négatif.
12. Donner la définition du risque technique et citer des exemples (technologie, architecture, performance).
13. Utiliser la formule $C = P \times I$ pour la criticité d’un risque informatique.
14. Définir la dette technique et expliquer pourquoi elle augmente le coût futur via la maintenance/refactorisation.