Cédric BRASSEUR

Mis à jour le 30/12/2024

Cédric BRASSEUR

Et vous ?

• Nom, prénom
• Etudes réalisées 
• Connaissances sur la gestion de projet
• Autres infos appréciées

Plan du cours

• La définition d'un projet
• Le chef de projet, son rôle et ses qualités
• Le cycle de vie de projet traditionnel
• Les différentes méthodologies de gestion de projet
  • Cycle en V, W, Spirale, Cascade
• Les méthodologies agiles
  • Scrum
  • Kanban
• Expression des besoin
  • SMART
• Analyse fonctionnelle
  • PBS 
  • WBS
• Parties prenantes / Matrice RACI
• Analyse des risques / Matrice des risques
• Retroplanning / Diagramme de gantt
• Dossier projet dans son ensemble
• Budgétisation (simple) du projet
• Spécification technique du besoin
  • Justification du choix des technologies
  • Architecture logicielle de la solution

Gestion
Projet

Objectifs de la formation

• Connaitre les différentes méthodologies de gestion de projet

• Appréhender plus en détails les méthodes agiles

• Connaître les outils et techniques pour réaliser un dossier de projet

• Savoir comment répondre efficacement à un cahier des charges d'un client

• Spécifier le besoin du client

Un projet, c'est quoi ?

Approche par compétences

Approche par recherche

La liste des sujets se trouve sur la slide suivante...

Approche par recherche

• Les méthodologies agiles, le fonctionnement, les acteurs, les documents à fournir et les avantages / désavantages de la méthodologie,…
   
• La méthodologie cycle en V, le fonctionnement, les acteurs, les étapes, les documents à fournir les avantages / désavantages de la méthodologie,…
   
• Les autres méthodologies de gestion de projet (Cascade, W, Spirale,…), de manière générale + la méthode SMART + PBS & WBS
   
• L’analyse des risques : Que sont les risques, comment réaliser une analyse de risques, réaliser une matrice de risques + Exemple…
   
• La réalisation d’un diagramme de Gantt, l’analyse des écarts, le planning réel, le planning prévisionnel, outils, intérêts + Exemple (sur le projet que vous voulez)...
   
• Définir ce qu’est un projet, les tâches & responsabilités du responsable de projet, ses qualités, son quotidien, avec qui il communique, comment,…
   
• Les différents documents à mettre en place pour une gestion de projet et leurs contenus (Dossier de projet, cahier de tests et recettes, plan de déploiement, plan de sécurisation, …)

Quelques définitions...

• Projet informatique : C'est un ensemble d'actions organisées afin d'obtenir un résultat défini, connu et mesurable
   
• Gestion de projet : C'est un ensemble d'actions menées pour initialiseer, maintenir et réaliser le projet
   
• Maîtrise d'ouvrage (MOA) : Acheteur ou client du projet, il défini l'orientation du projet
   
• Maîtrise d'œuvre (MOE) : Personnes engagées par la MOA, qui réalisent le projet et s'assurent de son bon déroulement

Lors de la réflexion sur un projet, nous devons choisir deux des trois axes suivants : Coûts, Délai, Qualité.

Il ne sera possible d'en choisir que deux, car le troisième est obligatoirement impacté négativement par le choix des deux autres.

Le triangle d'or

Délai

Qualité

Coûts

Le rôle et les qualités d'un chef de projet

Les rôles du CDP

• Planification : Définir les objectifs, le calendrier, les livrables, et les jalons du projet.
• Communication : Servir de point de contact entre les parties prenantes (client, équipes techniques, direction).
• Gestion des ressources : Allouer efficacement les ressources humaines, financières et matérielles.
• Suivi de l’avancement : Superviser le déroulement des travaux, identifier les obstacles, et apporter des solutions.
• Assurance qualité : Veiller à ce que le produit respecte les standards techniques et les attentes fonctionnelles.

Les qualités du CDP

• Leadership : Capacité à motiver et à guider une équipe vers un objectif commun.
• Organisation : Compétence dans la gestion simultanée de plusieurs tâches et priorités.
• Communication : Aptitude à expliquer des concepts techniques à des non-spécialistes et à écouter les besoins des parties prenantes.
• Résolution de problèmes : Réactivité et créativité pour surmonter les obstacles imprévus.
• Connaissances techniques (optionnelles): Compréhension des technologies et des processus de développement pour dialoguer avec les équipes techniques.
• Adaptabilité : Flexibilité pour s’ajuster aux changements de priorités ou de contexte.
• Vision stratégique : Capacité à aligner le projet sur les objectifs à long terme de l'organisation.

Le cycle de vie traditionnel & les cycles de vie de projet

Le cycle de vie d'un projet

• Décomposition d’un projet en un ensemble d’étapes nécessaires au déroulement de celui-ci
   
• Etapes de développement d’un produit de sa conception à sa finalisation
   
• Documentations & jalons (réunions) à mettre en place pour le bon déroulement du projet

Quels cycles de vie de projet connaissez-vous ?

Le cycle de vie traditionnel

Résumé schématique

Quelques précisions

Les différents cycles de vie de projet

Il existe de nombreuses adaptions au cycle de vie traditionnel d'un projet, en voici quelques unes...

• Cascade
• V
• W
• Spirale
• Agile
• ...

Le cycle en V

Un des cycle les plus connus est le cycle en V, chaque phase se suit et est toujours liée à une phase de tests associée. Le client est impliqué au début et à la fin pour des ajustements

Le cycle en W

Dérivé du cycle en W, le cycle en W fait intervenir le client au milieu du projet afin de faire une seconde itération en V et éviter l'effet tunnel (l'anticiper du moins)

Le cycle en cascade

Le cycle en cascade permet d'avancer de phase en phase séquentiellement avec la possibilité de revenir une phase précédente uniquement en cas de besoin (une seule phase)

Le cycle en spirale

Avec un fonctionnement itératif, on réalise les différentes phases d'un projet en continue jusqu'à ce que le projet soit terminé, déployé et testé.

L'agile

Même si pas vraiment considéré comme un cycle de vie traditionnel, l'agile est de plus en plus répandu pour gérer un projet (une partie dédiée suit celle ci concernant les méthodes agiles)

https://www.tuleap.org/fr/agile/comprendre-methode-agile-scrum-10-minutes

Les méthodologies agiles

L'intérêt des méthodes agiles

Comme on l'a vu précédemment, la plupart des cycles de vie de projet sont très linéaires et fermé. Le client est concerné en début et en fin de projet pour valider. Contrairement aux méthodes agiles où le client est impliqué régulièrement pour ajuster le tir en continue et répondre aux mieux à ses besoins.

Il existe de nombreux dérivés des méthodes agiles, nous allons aborder la méthode Scrum et le Kanban uniquement

Voici un lien vous permettant de voir d'autres dérivés

La méthode Scrum

Nous avons plusieurs notions à appréhender pour comprendre les méthodes agiles. Ici, ce qu'il faut retenir, c'est que l'on fonctionne en itérations et que le client est impliqué à chaque itération. 

https://www.tuleap.org/fr/agile/comprendre-methode-agile-scrum-10-minutes

Les acteurs

Plusieurs acteurs sont à définir lors d'un fonctionnement en méthode Scrum

• Product Owner (PO) : Responsable du backlog produit. Il priorise les fonctionnalités et s’assure que l’équipe comprend bien les besoins des parties prenantes.

• Scrum Master : Facilite la compréhension et l’application de Scrum par l’équipe. Il s'assure que les différents jalons sont respectés.

• Équipe de développement : Réalise les développements et s'assure de proposer une version du produit à chaque itération.

• Parties prenantes: Ils fournissent des retours sur les différentes versions livrés (la plupart du temps).

• Client/Utilisateur final : Leurs besoins et retours influencent directement les priorités et les développements futurs à chaque itération.

Les réunions

Différentes réunions permettent le bon fonctionnement et l'agilité induite par la méthodologie Scrum. En général, c'est le scrum master qui s'assure que ses réunions sont respectées et planifiées.

https://www.tuleap.org/fr/agile/comprendre-methode-agile-scrum-10-minutes

Les réunions

• Daily Scrum

  • Réunion quotidienne de l’équipe Scrum (15 minutes maximum).

  • Permet de synchroniser le travail des membres.

  • Chaque participant répond à 3 questions :

    • Qu’ai-je fait hier pour atteindre l’objectif du sprint ?

    • Que vais-je faire aujourd’hui ?

    • Quels problèmes rencontrons nous ?
       

• Planification de Sprint

  • Réunion au début du sprint pour définir le travail à accomplir.

  • L’équipe Scrum décide :

    • Quel objectif atteindre durant le sprint.

    • Quels éléments du backlog seront développés.

Les réunions

• Revue de Sprint

  • Réunion à la fin du sprint.

  • L’équipe présente les éléments développés à l’ensemble des parties prenantes.

  • Permet de recueillir des feedbacks pour ajuster le backlog du produit.
     

• Rétrospective de Sprint

  • Réunion à la fin du sprint pour analyser le fonctionnement de l’équipe.

  • Objectif : Identifier ce qui a bien fonctionné et ce qui peut être amélioré.

  • Définition d'actions concrètes pour améliorer les futurs sprints.

Les réunions

• Product Backlog

  • Liste priorisée des besoins du produit.
  • Évolue en fonction des retours et priorités.

• Sprint

  • Cycle court (1 à 4 semaines) pour livrer un incrément fonctionnel.
  • Comprend planification, développement, et révisions.

• Release

  • ​Livraison d’une version utilisable du produit.
  • Peut inclure plusieurs sprints.

• ​​User Stories

  • Descriptions simples des fonctionnalités souhaitées.
  • Écrites du point de vue de l’utilisateur.

La méthode Kanban

• La méthode Kanban fonctionne autour d’une méthodologie de classement de cartes (ou de « User Stories » si appliqué aux méthodes agiles). Ces cartes correspondent aux tâches à réaliser. La méthode Kanban prône l’amélioration en continue d’un produit.
• Elles sont souvent classés par catégories
  • A faire
  • En cours
  • A tester
  • A déployer
  • Terminé
• Chaque carte contient plusieurs informations 
  • Description de la tâche
  • Contenu utile à la réalisation de la tâche (liens, modèles,…)
  • Les commentaires de l’équipe projet
  • Les sous-tâches à accomplir

Les outils Kanban

Les différents outils Kanban :

• plane.so (Très recommandé)
• Trello
• Jira
• Monday (vue Kanban disponible, mais pas que)
• Asana,
• Un tableau avec des posts-it
• …

Exemple de Kanban

Un exemple parmi tant d'autres de tableau Kanban

Expression des besoins

L'expression de besoin

Cette partie est assez simple, elle résume ce qu'a compris la MOE du sujet proposé par la MOA.

C'est lors de cette étape que l'on s'assure de bien avoir compris les besoin du client, quitte à poser des questions au client afin de clarifier certains points.

Vous pouvez y réaliser :

• Un résumé du cahier des charges
• Ce qui concerne le projet (aussi appelé périmètre du projet)
• Parfois, on défini également ce qui ne sera pas couvert par le projet réalisé afin d'être le plus clair possible

L'expression de besoin

• Démarche visant à contrôler si le projet est réalisable ou non
  • Facteurs économiques et financiers
    • Moyens déployés et gains envisageables – rentabilité
• Facteurs technologiques
  • Quelle technologie est présente au sein de l’organisation
    • Faudra t-il l’adapter ou en acquérir une nouvelle?
• Facteurs opérationnels et organisationnels
  • Quels sont les moyens opérationnels à votre disposition.?
  • Avez-vous toutes les compétences nécessaires en interne ou externe
  • Organisations et processus généraux sont ils adaptés?
• Facteurs juridiques
  • Confrontés à des réglementations particulières (ex : RGPD)
• Facteurs commerciaux
  • Identifiez les opportunités du marché, les évolutions à venir, les clients…

Lors de cette étape, on réalise également l'étude de marché et l'étude de faisabilité.

Méthode SMART

La méthode SMART est mise en place pour définir les objectifs du projet et s'assurer que l'on a bien pris en compte la faisabilité et la durée du projet pour la réussite de celui-ci.

• Enoncer les objectifs
• Fixer une date limite d’atteinte
• Identifier les obstacles
• Enumérer les avantages de la réalisation des objectifs
• Enumérer les compétences nécessaires
• Elaborer un plan pour les atteindre 

Méthode SMART

Spécifique

• l’E-book va porter sur un thème précis (Intelligence Artificielle) et va comporter un nombre de mots fixé au préalable

Mesurable

• l’E-book sera rédigé en 50 000 mots                                                       

Atteignable

• si les équipes de rédaction rédigent 2 000 mots par jour, la mission sera terminée avant les délais impartis

Réaliste

• l’E-book portera sur un thème qui intéresse les clients cible          

Temporel

• Le projet a un délai fixe de deux mois                                                      

Exemple : Rédiger un e-book

Méthode SMART

Réaliser le SMART pour les deux sujets suivants :

• Je souhaite réaliser un semi-marathon en Mars 2026. La distance à parcourir est de 21 km, sans dénivelé. Actuellement, je cours le 10km en 1 heure (nous sommes en Octobre 2025).
   
• Mon objectif est qu'à la fin d'année 2026, j'ai 25 jours de formation (formateur) supplémentaires. En 2025, je fais 100 jours de formation dans l'année.

Exercice

Méthode SMART

Réaliser le SMART pour votre sujet de projet fil rouge.

Projet fil rouge

Analyse fonctionnelle
& modélisation

Analyse fonctionnelle

L'analyse fonctionnelle a pour objectif de s'assurer que l'on va bien respecter les résultats attendus du projet pour le client.

Pour cela, on va mettre en place :

• Mise en place du PBS et WBS (ils sont demandés pour votre projet)
• Les KPI de suivi de projet
• Les KPI de réussite de projet

PBS & WBS

• Work Breakdown Structure
• Répond au comment, quelles tâches seront réalisées
• Concerne le travail à réaliser
• Inclus toutes les phases du projet
• Inclus les éléments du PBS
• Doit être le plus précis possible !
• Est un prérequis pour pouvoir réaliser une planification / estimation du budget claire

Ce sont deux organigrammes ayant chacun un objectif différent mais qui sont complémentaires, l'un concerne le visuel (PBS) et l'autre les tâches à réaliser pour atteindre l'objectif (WBS)

PBS

• Product Breakdown Structure
• Répond au quoi, à quoi ressemblera le produit
• Concerne le visuel du projet
• C'est comme une pré-maquette du projet sous forme d'organigramme
• Inutile d'aller trop dans le détails, même si l'on doit y voir apparaître toutes les pages du projet, inutile d'y mettre tous les champs d'un formulaire par exemple

WBS

PBS

Un exemple simple pour un vélo. On décompose le vélo en grandes parties (vertes) puis en sous partie (blanches). L'exemple n'est pas complet.

PBS

Autre exemple non terminé avec le site slides (sur lequel nous sommes actuellement)

PBS

Autre exemple, celui-ci est plus complet et est en deux parties, même s'il pourrait et devrait totalement être en un seul organigramme.
La partie produit a été mise à l'écart car elle est conséquente. C'est une possibilité, mais pas une obligation.

WBS

Le WBS est plus difficile à réaliser, il nécessite de bien réfléchir à toutes les phases du projet ainsi que toutes les tâches à réaliser (de l'avant projet à la clôture en passant par les développements)

WBS

Pensez bien à toutes les étapes du projet, n'oubliez pas que l'objectif est de réaliser un diagramme de gantt et une estimation des charges la plus précise possible

Ceci n'est qu'un exemple incomplet de WBS pour un projet de développement, vous devez aussi prendre en compte la sécurité, le déploiement, etc... 

WBS

Exemple plus complet, mais pas totalement (je vais pas faire tout le travail pour vous quand même 😊)

PBS & WBS

Réaliser les PBS et WBS du projet suivant :

• Les PBS et WBS du projet envoyé qui a été généré par chatGPT. (Vous pouvez utiliser l’outil qui vous semble le plus pertinent, draw.io est une solution en ligne simple et efficace pour ce type de diagrammes simples)
  
  Pour le WBS, faites uniquement la partie développement.
  

Exercice

Modélisation

MERISE & UML

MERISE

UML

Les modélisation MERISE & UML se trouvent également dans cette partie (bien que MPD et diagramme de classes / composants pourraient être dans l'analyse technique)

Modélisation de la base de données

Voir slides

Analyse du besoin et du projet, lisible par le client

Voir slides

Parties prenantes &

Matrice RACI

Les parties prenantes

• Identifier les acteurs (qui fait quoi, qui est responsable de quoi, qui doit être informé de quoi)?
  • Quels sont les membres de l’équipe projet?
  • Qui est en charge de chaque domaine?
  • Qui participe aux réunions de pilotage?
  • Quelles sont les autres parties prenantes?
  • Qui sont les experts?
  • Qui sont les utilisateurs clés?
  • Qui valide les livrables?
    

Les parties prenantes d'un projet sont toutes les personnes, équipes ou organismes étant concernés de près ou de loin par le projet.

Exemples de parties prenantes

• Commanditaire
• Sponsor du projet
• Utilisateurs, services impactés
• Direction
• Equipe projet
• Services supports impliqués
• Actionnaires
• Autres experts (sécurité,...)
• Syndicats, représentants du personnel
• ...

En interne

• Clients
• Fournisseurs
• Organismes publics, privés
• Investisseurs, partenaires financiers
• Communautés d’utilisateurs
• ...

En externe

Organigramme des PP

On va en général réaliser un organigramme des parties prenantes afin de définir qui communique avec qui.

Voici un exemple pour un projet de développement :

Exercice

Identifiez les parties prenantes du projet proposé lors du dernier exercice

La matrice RACI

• Outil pour l’affectation des rôles et des responsabilités
  • R => Réalise
  • A => Approuve
  • C => Est consulté
  • I => Est informé.
• Utilisé en phase de planification
• Complété à partir du WBS (diagramme des tâches)
• On liste les tâches en ligne, et les parties prenantes en colonnes afin de savoir quels liens chaque partie prenante à avec la tâche

L'identification des parties prenantes mène à la réalisation d'une matrice RACI, cette dernière permet de savoir qui est impacté par quelle tâche du projet (Démarre donc du WBS !)

La matrice RACI

Les différentes responsabilités

La matrice RACI

Analyser sa matrice RACI

Grâce à RACI, on peut rapidement identifier :

• S'il y a bien une personne qui approuve et qui réalise chaque tâche (un R et un A par tâche !)
• Si certaines personnes ont trop de charges (trop de R)
• Il peut y avoir plusieurs lettres dans une seule case

La matrice RACI

Exemple de matrice RACI

Cette matrice RACI contient quelques erreurs et n'est pas complète (il manque des tâches en bas)

Quelle erreur majeure pouvez vous trouver ?

Celle-ci reste une très bonne base pour vous inspirer et réaliser la vôtre

Matrice RACI

Envoyer le fichier
Exemple_Matrice_RACI_A_Rendre_Plus_Beau.xlsx

Autre exemple de matrice RACI

Comme marqué dans le nom du fichier, vous devez rendre votre matrice RACI plus jolie, avec des couleurs, comme sur l'exemple précédent.
De plus, celle-ci n'est pas totalement complète pour les tâches à réaliser.

Exercice

Réaliser la matrice RACI du projet utilisé pour les exercices WBS et identification des parties prenantes.

Vous avez toutes les infos, il suffit de réaliser un tableau avec en ligne les tâches du WBS et en colonne les parties prenantes.

Puis réfléchir à chaque responsabilités.

Analyse des risques &

Matrice des risques

L'analyse de risques

• Anticiper pour mieux gérer
   
• Initiée au début du projet
   
• A suivre et mettre à jour la tendance du risque en continue durant le projet
   
• Un risque est aussi bien un danger potentiel qu’une opportunité extérieure pouvant affecter le projet

L'analyse de risque est réalisée afin d'anticiper les différents problèmes qui peuvent empêcher la réussite du projet.
Ils sont de plusieurs types que l'on verra dans la slide suivante.

L'analyse de risques

• Financiers
  • Coût supérieur à l'estimation, manque de budget, etc.
• Humains
  • Manque de compétences, absentéisme, démission au cours du projet, conflits au sein de l'équipe, etc.
• Temporels
  • Retards des sous-traitants ou des fournisseurs, mauvaise estimation des délais, etc.
• Techniques
  • Logiciel inadapté, pannes, matériel obsolète, faille de sécurité, etc.
• Juridiques
  • Réglementations et lois à respecter, faillite d'un fournisseur, etc.
• Environnementaux
  • Impacts négatifs du projet sur l'environnement, ou environnement ayant un impact sur le projet (inondation, sécheresse, tempête...).
• Organisationnels
  • Changement dans la politique de l'entreprise, changements économiques, etc.

Les types de risques

L'analyse de risques

Quelques exemples généraux

L'analyse de risques

• Identifiant du risque
• Description du risque (la plus claire et complète possible)
• Type de risques (voir deux slides précédentes)
• Evaluer les impacts : En général sur une échelle de 1 à 4
• Evaluer la probabilité : En général sur une échelle de 1 à 4
• Criticité (optionnelle) : Multiplication de l'impact et la probabilité
• Tendance du risque : Suivi du risque et sa probabilité d'arriver
• Conséquence si avéré
• Action préventive
• Action corrective

Pour réaliser une analyse de risque, la plupart du temps, on réalise ça en réunion en brainstorming (chacun dit ce qu'il pense, émet des hypothèses, propose des solutions, ...)

Pour l'analyse de risque on réalise un registre de risques comprenant les colonnes suivantes :

La méthodologie

L'analyse de risques

Exemple de registre de risque

Pour votre projet, essayez d'avoir AU MOINS 8-10 risques au total dans votre registre de risque.
Quelque soit le type de risque (pas 10 par type, 10 en tout)

L'analyse de risques

La matrice de risque

On peut considérer la matrice de risque comme un résumé visuel du registre des risques permettant d'identifier rapidement quels risques sont les plus probables et critiques.

L'analyse de risques

Exemple de registre et matrice

Cet exemple est à rendre plus joli avec des couleurs et il y a intentionnellement que quelques risques listés, à vous de trouver d'autres risques !

Envoyer Exemple_Risques_A_Finaliser_Et_Adapter.xlsx

L'analyse de risques

Exercice

Identifier 10 risques sur le projet utilisé jusqu'à présent pour les différents exercices.

Réalisez :

• Le registre de risques
• La matrice de risques

(Ceci ne sera pas perdu, car la plupart des risques pourront être applicables à votre projet fil rouge !)

Retroplanning &

Diagramme de Gantt

Le diagramme de Gantt

• Place dans le temps les grandes étapes de la démarche mis en œuvre.
• Double intérêt 
  • Fixer un horizon temporel
  • Donner une vue du déroulement des opérations
    • Quelles sont les étapes et dates clés?
    • Quels sont les principaux jalons?
    • Quelles sont les principales échéances?
    • Quand doit démarrer le projet?
    • Quand doit il se terminer au plus tard?

Le but du diagramme de Gantt est de pouvoir estimer quand les tâches seront terminées afin d'avoir une vue sur la date de rendu potentielle du projet

A cette étape, nous avons déjà quasiment tout réalisé pour faire notre diagramme de Gantt (WBS, RACI)

Le diagramme de Gantt

Les prérequis

Déjà fait

Déjà fait

A faire, via le planning poker

Voir slide suivante

Voir slide suivante

Voir slide suivante

Le diagramme de Gantt

Le diagramme de PERT

Le diagramme de PERT permet d'identifier quelles tâches dépendent de quelles autres tâches.

Ceci permettant donc de définir ce que l'on appelle le chemin critique (durée indivisible du projet)

Le diagramme de PERT n'est pas demandé pour votre projet, vous devez uniquement définir les tâches interdépendantes

Le diagramme de Gantt

• MS Project (souvent utilisé) 
• Monday (Outil complet, mais payant pour une utilisation complète)
• Instagantt
• Ganttplaner
• Excel
• Lucidchart
  

Différents outils existent pour créer votre diagramme de Gantt

Le diagramme de Gantt

Exemple de diagramme de Gantt

Pensez à assigner les personnes pour chaque tâche !

Exercice

Réalisez le diagramme de Gantt du projet utilisé jusqu'à maintenant pour les différents exercices précédents

Le diagramme de Gantt

Les spécifications techniques du besoin

L'analyse technique

• Choix des technologies : Front, back, base de données (MySQL / SQL Server,...) et type de base de données (Relationnelle, NoSQL,...)
  • La justification est OBLIGATOIRE : Souvent sous forme de tableau comparatif des technologies possibles pour le projet
     
• Utilisation de frameworks et justification de leurs avantages (documentation, sécurité,...)
   
• Architecture logicielle du projet : MVC, Micro Services, Oignon, DDD,...
   
• Infrastructure du projet : les serveurs nécessaires, les ports ouverts,...

L'analyse technique d'un projet a pour objectif de définir techniquement la réponse au projet et d'anticiper les besoins potentiels (licences, serveurs, ...)

L'analyse technique

Vous devez choisir judicieusement vos technologies afin de pouvoir réaliser le projet dans son ensemble via ces technologies.

La justification doit avoir du sens :

• Les technologies mise en oppositions sont récentes et adaptées au projet
• N'utilisez pas vos connaissances comme étant un argument de choix
• Réaliser un tableau comparatif et mettez des couleurs pour chaque technologie comparée
• Choisissez les éléments de comparaisons concernant votre projet : Adaptable à l'embarqué, documentation fournie, pérennité, courbe d'apprentissage, sécurité,...

Choix des technologies et justifications

L'analyse technique

Si vous utilisez des frameworks, comme Symfony ou Laravel, vous devez justifier :

• Les raisons de son utilisation (simplicité, adapté au projet, etc...)
   
• Les avantages du framework (sécurité, MVC intégré,...)
   
• Et surtout vous assurer qu'il réponde à TOUS vos besoins en terme de développement, car le framework sera pas mis à jour pour vous, c'est vous qui dépendez du framework 😉

Utilisation de Frameworks

L'analyse technique

Dans cette analyse technique, vous devez également expliquer votre architecture logicielle.

Si vous faites du MVC, il faut expliquer ce qu'est le MVC et en définir les avantages que ça vous apporte (modularité du code, séparation des responsabilités, simplicité à identifier les erreurs, facilité à séparer les tâches selon les compétences de l'équipe, etc...)

Quelque soit votre choix d'architecture logicielle, vous devez l'expliquer et la justifier ici

Architecture logicielle

L'analyse technique

Cette partie est sûrement la plus tricky...

Vous devez anticiper l'infrastructure nécessaire pour faire tourner votre projet, cette année, il ne vous ai pas demandé d'estimer les charges (RAM, mémoire, etc...) sur vos serveurs.

Mais, vous devez définir votre infrastructure serveurs :

• Le nombre de serveurs nécessaires (BDD, front, back,...)
• Les ports qui seront ouverts
• Les protocoles d'échanges entre vos serveurs
• Le type de serveur ou les services qui vont vous donner accès à des serveurs cloud (OVH, AWS,...)

Infrastructure du projet

L'analyse technique

Un petit exemple intentionnellement pas complet et pas très réfléchi d'infrastructure pour un projet classique

(Je vous guiderai par rapport à vos propositions, ne vous en faites pas)

Infrastructure du projet

La budgétisation simple d'un projet

Budgétisation

La budgétisation de votre projet concerne deux aspects majeurs :

• La prise en compte du salaire des personnes qui réalisent (MOE) par rôle (Dev front, Dev back, DevOps, CDP,...) ainsi que leur temps de travail sur le projet
   
• Le coût de l'infrastructure serveur définie dans la partie précédente (n'oubliez pas le / les noms de domaines)

La budgétisation d'un projet est une étape complexe pour tout projet. Mais vous n'avez qu'une budgétisation simple à réaliser et nous avons quasiment tous les éléments nécessaires déjà.

Budgétisation

• Faire un tableau
• Définir le tarif horaire ou journalier de chaque rôle (Back, front,...)
• Cumuler les temps passés sur le projet par type de rôle
• Multiplier ces deux valeurs pour chaque rôle
• Cumuler en total les multiplications par rôle
  • Exemple : CDP, 60h, 80€ / h = 4800€

Grâce à la matrice RACI et votre diagramme de Gantt, vous savez exactement le nombre d'heures travaillées prévues pour chaque rôle. Vous devez donc :

Salaire et temps de travail

Budgétisation

• Définir si vous achetez des serveurs adaptés à vos besoins (attention, habituellement, il y a tout un PCA / PRA à mettre en place et donc souvent pas qu'un seul serveur, mais ça n'est pas demandé pour votre projet)
  • Leur puissance (RAM, mémoire,...) 
  • Leur prix unitaire
• Définir si vous louez des serveurs
  • Leur puissance 
  • Leur tarif mensuel

L'infrastructure serveur a été définie dans l'étape précédente, ce qui va vous permettre de facilement savoir le tarif de votre infrastructure

Infrastructure serveur

Budgétisation

Vous vous en doutez, mais la finalité de la budgétisation est de donner un (ou deux) chiffres aux clients

• Le coût total du projet pour sa réalisation complète (avec salaire + infrastructure)
• Le second chiffre potentiel est le coût par mois des serveurs et des noms de domaines si vous louez vos serveurs via des services tels que OVH. Sinon, si vous décidez de passer par l'achat direct de serveurs, ce second chiffre n'a pas lieu d'être et fait parti intégrante du coût total du projet pour le client

Finalité

Le contenu d'un dossier de projet

Le contenu du dossier

Vous pouvez bien évidemment adapter ces parties à votre convenance.

Voir ContenuDossierLot1.md

Le contenu du dossier

Cette seconde partie est à rendre quelques semaines avant la fin du projet, une date vous sera fournie sur Classroom.

• Plan de sécurisation (https://slides.com/cedricbrasseur/application-security#/7)
• Le cahier de tests et recettes (https://slides.com/cedricbrasseur/tests-recettes#/4) 
• Le dossier d’exploitation ou plan de déploiement (https://slides.com/cedricbrasseur/git-ci-cd#/8)

Evaluation

Evaluation

Cette évaluation sera au format papier et sera un QCM à choix multiples concernant ce que nous avons vu sur la gestion de projet