Table des matières

CHAPITRE I : Découvrir les Concepts de gestion de projet .................................................................. 6

1. Concepts de gestion de projet ...................................................................................................... 6
a. Qu’est ce que la gestion de projet? .......................................................................................... 6
b. Définitions ............................................................................................................................... 6
2. Parties prenantes de projet ........................................................................................................... 7
a. Définition des parties prenantes d'un projet ............................................................................ 7
b. Acteurs externe : ...................................................................................................................... 8
c. Acteurs interne : ...................................................................................................................... 8
3. Principaux rôles dans un projet informatique .............................................................................. 8
a. Qu’est-ce qu’un Chef de projet informatique ? ....................................................................... 8
b. Quel est le rôle d’un chef de projet informatique ? ................................................................. 8
c. Matrice d’assignation des responsabilités (RACI) .................................................................. 9
4. Caractéristiques de base d’un projet ............................................................................................ 9
5. Contraintes dans la gestion d’un projet ..................................................................................... 10
a. Contraintes de délais : ........................................................................................................... 10
b. Contraintes dues aux clients .................................................................................................. 10
c. Contraintes de coûts : ............................................................................................................ 10
d. Contraintes de qualité : .......................................................................................................... 10
CHAPITRE II : Découvrir les différentes méthodes de gestion de projet ............................................ 10
1. Méthodes prévisibles (cascades, V, Y)...................................................................................... 10
a. Le modèle en cascade ............................................................................................................ 11
b. Le cycle en Y......................................................................................................................... 12
c. Le cycle en V......................................................................................................................... 13
2. Méthodes imprévisibles (Agile) ................................................................................................ 15
a. Signification d'Agile en gestion de projet ............................................................................. 15
b. Manifeste Agile, Les principes fondateurs ............................................................................ 15
3. Cycle en V vs. Méthodes agiles ................................................................................................ 16
CHAPITRE III : Analyser le cahier des charges ................................................................................... 17
1. Compréhension des besoins client............................................................................................. 17
a. Besoins explicites .................................................................................................................. 18
b. Besoins implicites.................................................................................................................. 18
2. Contexte du projet ..................................................................................................................... 18
3. Périmètre du projet .................................................................................................................... 19
4. Détection des risques liés à la nature du projet ......................................................................... 20
5. Proposition des solutions possibles ........................................................................................... 21
 a. Manque de visibilité sur le projet .......................................................................................... 21
b. Objectifs imprécis.................................................................................................................. 21
c. Planning sous-estimé ............................................................................................................. 21
d. Aucune visibilité sur la disponibilité des ressources ............................................................. 22
e. Mauvaise communication...................................................................................................... 22
CHAPITRE IV : Préparer le projet ....................................................................................................... 22
1. Répartition de l’ensemble des fonctionnalités en tâches ........................................................... 22
a. Organigramme des tâches du projet : exemple et modèle ..................................................... 23
b. Caractéristiques des tâches .................................................................................................... 23
2. Estimation de la durée de réalisation de chaque tâche .............................................................. 24
a. Données historiques (ou estimation analogue) ...................................................................... 24
b. Analyse statistique et mathématique (ou estimation paramétrique) ...................................... 24
c. Estimer une durée .................................................................................................................. 24
d. Durée ..................................................................................................................................... 24
3. Ordonnancement des tâches ...................................................................................................... 25
a. LA METHODE M.P.M (Méthode des Potentiels et antécédents Métra) .............................. 25
b. Le diagramme de GANTT..................................................................................................... 25
4. Chemin critique ......................................................................................................................... 27
5. Echéancier et la chronologie des tâches .................................................................................... 31
a. Énumérer les étapes du projet et définir clairement les échéances ........................................ 31
b. Ordonner vos tâches .............................................................................................................. 31
c. Partager votre échéancier ...................................................................................................... 32
d. Visualiser la progression du projet ........................................................................................ 32
6. Affectation des ressources aux tâches ....................................................................................... 32
7. Maîtrise des coûts ...................................................................................................................... 33
8. Détermination des points de validation ..................................................................................... 33
CHAPITRE V : Appréhender la méthodologie Agile Scrum................................................................ 35
1. Définition de la méthode Agile Scrum ...................................................................................... 35
2. Manifest Agile (valeurs et principes) ........................................................................................ 35
e. Les valeurs............................................................................................................................. 35
f. Les principes.......................................................................................................................... 36
3. Processus de la méthode Scrum ................................................................................................ 37
4. Rôles et responsabilités ............................................................................................................. 38
a. Le rôle du Scrum Master : le gourou ..................................................................................... 38
b. Le rôle du Product Owner ..................................................................................................... 38
c. L’équipe................................................................................................................................. 38
d. Stakeholders .......................................................................................................................... 38
 5. Evénements Scrum .................................................................................................................... 38
a. Étape 1 : Le Product Backlog ................................................................................................ 38
b. Étape 2 : Le sprint ................................................................................................................. 38
c. Étape 3 : Sprint Review ......................................................................................................... 39
d. Étape 4 : Sprint Retrospective (Rétrospective de Sprint) ...................................................... 39
6. Artéfacts Scrum ......................................................................................................................... 39
CHAPITRE VI : Manipuler l’outil de gestion de projet Agile (Scrum/Jira) ......................................... 40
1. Présentation de Jira .................................................................................................................... 40
a. C’est quoi Jira? ...................................................................................................................... 40
b. Quelles équipes utilisent Jira Software ? ............................................................................... 40
c. Pourquoi utiliser Jira Software quand on est une équipe de développement ? ...................... 40
d. Qu’est-ce qu’un ticket dans Jira ? ......................................................................................... 40
e. Qu’est-ce qu’un projet dans Jira ? ......................................................................................... 41
f. C’est quoi un Backlog ? ........................................................................................................ 41
2. Installation et configuration d’un compte Jira ........................................................................... 42
a. Installation de Jira ................................................................................................................. 42
b. Jira Desktop ........................................................................................................................... 42
c. Etapes pour la création compte Jira sur Jira cloud ................................................................ 42
3. Création de projet avec Jira ....................................................................................................... 43
4. Création d’un backlog product .................................................................................................. 44
5. Ajout des différents types de tickets .......................................................................................... 44
6. Planification d’un sprint ............................................................................................................ 46
7. Manipulation du tableau de bord de sprint ................................................................................ 49
8. Utilisation de la feuille de route (roadmap) ............................................................................... 49
9. Génération des rapports Agile ................................................................................................... 52
CHAPITRE VII : Manipuler les outils de gestion de versions (Git/Gitlab) .......................................... 55
1. Intérêt de la gestion de version .................................................................................................. 55
a. Gestion de versions locale ..................................................................................................... 55
b. Gestion de versions centralisée ............................................................................................. 55
c. Gestion de versions distribuée ou décentralisée .................................................................... 55
2. Présentation des outils existants de gestion de versions ............................................................ 56
3. Présentation de GIT ................................................................................................................... 57
a. C’est quoi git? ....................................................................................................................... 57
b. Les dépôts avec git : .............................................................................................................. 57
c. Principales commandes git .................................................................................................... 58
4. Présentation de Gitlab ............................................................................................................... 58
5. Comparaison Git vs Gitlab ........................................................................................................ 58
 a. Fonctionnalités : .................................................................................................................... 58
b. Convivialité : ......................................................................................................................... 59
c. Hébergement : ....................................................................................................................... 59
d. Coût : ..................................................................................................................................... 59
6. Création d’un compte Gitlab ..................................................................................................... 59
7. Présentation des fonctionnalités de Gitlab................................................................................. 60
8. Manipulation des dépôts avec Gitlab ........................................................................................ 61
9. Installation de Git ...................................................................................................................... 61
10. Manipulation de Git user interface (GUI) ............................................................................. 62
11. Manipulation des commandes de base de Git (Git bash) ...................................................... 62
12. Notion de branches avec Git.................................................................................................. 63
13. Création et manipulation des branches avec Git ................................................................... 63
14. Gestion des conflits de fusion avec Git ................................................................................. 64
CHAPITRE VIII : Manipuler l’outil de mesure de la qualité du code (SonarQube) ............................ 65
1. Notions des métriques de la qualité du code ............................................................................. 65
2. Présentation des outils existants de mesure de la qualité du code ............................................. 65
3. Présentation de SonarQube........................................................................................................ 66
4. Installation de SonarQube ......................................................................................................... 66
5. Intégration de SonarQubeavec les outils ALM ......................................................................... 66
6. Configuration de SonarQube : ................................................................................................... 67
Analyse de code source à travers la génération de rapports sur : ...................................................... 68
CHAPITRE IX : Introduire la chaîne DevOps ...................................................................................... 69
1. Introduction aux concepts DevOps ........................................................................................... 69
a. Définition............................................................................................................................... 69
b. Avantages .............................................................................................................................. 70
c. Outils ..................................................................................................................................... 70
2. Lien en l'agilité et devops .......................................................................................................... 70
3. Caractéristiques de la méthodologie DevOps (CALMS) : ........................................................ 71
4. Définition des notions : ............................................................................................................. 71
a. L'intégration continue ............................................................................................................ 71
b. Déploiement continue (livraison continue) ........................................................................... 72
CHAPITRE X : Mettre en place la CI/CD avec Gitlab ......................................................................... 73
1. Introduction : ............................................................................................................................. 73
2. Définition de GitLab CI : .......................................................................................................... 73
a. Principes de fonctionnement de Gitlab CI/CD : .................................................................... 73
3. Configuration de Git pour GitLab CI : ...................................................................................... 73
4. Intérêt d'un pipeline DevOps : ................................................................................................... 73
5. Architecture de base d'un pipeline CI/CD : ............................................................................... 74
6. Workflow du pipeline :.............................................................................................................. 74
7. Configuration du pipeline .......................................................................................................... 75
8. Manipulation d'un pipeline ........................................................................................................ 76
9. Configuration du CI/CD avec le fichier gitlab-ci.yml ............................................................... 76
Connaître les fondamentaux de la
gestion de projet
CHAPITRE I : Découvrir les Concepts de gestion de projet
1. Concepts de gestion de projet
a. Qu’est ce que la gestion de projet?
La gestion de projet, à bien organiser et coordonner toutes les étapes d'un projet pour réussir à créer
quelque chose de valeur. Cela se fait en utilisant des connaissances, des compétences, des outils et des
techniques spécifiques pour chaque projet. L'objectif est d'atteindre les buts fixés et d'obtenir les
avantages escomptés en créant quelque chose d'utile.
On peut la représenter en utilisant ce qu'on appelle le "triangle d'or" ou la "triple contrainte". Il met en
évidence les trois principaux points à surveiller dans la gestion de projet : la qualité, les coûts et les
délais.

b. Définitions
Un projet est une initiative temporaire visant à atteindre des objectifs spécifiques, avec un début et une
fin clairement définis. Il requiert l'utilisation de ressources telles que des personnes, des finances, des
équipements, et d'autres éléments essentiels pour accomplir la tâche. L'objectif principal d'un projet est
de créer un produit, un service ou un résultat unique tout en respectant les contraintes de temps, de coûts
et de qualité prédéfinies.
Une ressource est un élément nécessaire à la réalisation d'une tâche ou d'un projet. Une ressource peut
être une personne, une équipe, un outil, de la trésorerie ou du temps.
La plupart des projets nécessite de nombreuses ressources différentes pour se dérouler.
Les ressources doivent être estimées et affectées avant le début du projet. Leur mauvaise planification
peut entrainer un manque pendant le projet, des retards sur certaines échéances ou même la livraison
finale du projet.
Un livrable de projet Un livrable, qu'il s'agisse d'un produit, d'un résultat, ou d'une composante
spécifique, émerge au sein d'un projet et peut prendre diverses formes. Il constitue un élément tangible
qui peut être remis soit à la conclusion totale du projet, soit à la fin d'une étape particulière, en vue
d'atteindre les objectifs préétablis. Ces livrables revêtent fréquemment un rôle essentiel en tant que
repères permettant d'évaluer la progression du projet et de mesurer sa réussite.
Voici les livrables d'un projet informatique regroupés en plusieurs catégories :
Catégorie 1 : Services

• Version opérationnelle du logiciel ou de l'application

• Maintenance et support continus
• Formation des utilisateurs finaux
• Déploiement du produit dans l'environnement de production
Catégorie 2 : Documents

• Cahier des charges

• Spécifications de besoin
• Conception système
• Documentation utilisateur
• Rapport de projet
• Évaluation post-projet
Catégorie 3 : Développement et Tests

• Tests et résultats de validation

Catégorie 4 : Supports médiatiques

• Vidéos de formation ou de démonstration

Une charte de projet souvent appelée "charte de projet" ou "déclaration de projet", est un document
formel qui établit la base du projet dès son démarrage. Elle sert de référence claire et officielle pour le
projet et joue un rôle essentiel dans la gestion de projet.
La conduite d'un projet également connue sous le nom de gestion de projet, est le processus de
planification, d'organisation, d'exécution, de suivi et de contrôle des activités nécessaires pour atteindre
les objectifs d'un projet dans les limites de temps, de coûts, de qualité et de ressources prédéfinies.

2. Parties prenantes de projet

Pour atteindre les objectifs fixés, il est indispensable d'identifier les parties prenantes d'un projet, puis
d'analyser leurs attentes et besoins et enfin déclencher, le cas échéant, les actions de communication
adaptées.

a. Définition des parties prenantes d'un projet

Il s'agit de l'ensemble des personnes et des organisations qui ont quelque chose à voir avec le projet. Soit
elles sont directement impliquées dans la conduite des opérations, soit elles sont impactées par la
problématique de départ, par le choix ou la mise en œuvre des solutions. Certaines parties prenantes
peuvent exercer une influence à différents niveaux.
Ces acteurs clés se situent aussi bien en interne - à tout niveau de la hiérarchie de l'entreprise - qu'en
externe (un fournisseur concerné par de nouvelles méthodes d'approvisionnement d'un client, etc.)..

b. Acteurs externe :
Les clients : les premiers concernés en externe, impactés directement si leur rôle s'inscrit dans
l'utilisation du produit ou service livré par le projet - ou indirectement (par exemple dans le cas d'un
projet d'organisation destiné à améliorer la qualité d'un processus ) .
Les fournisseurs : de matière, de prestation, de main d' œuvre
Les diverses communautés d’utilisateurs, de fans … : Présentes sur les réseaux sociaux.
Les organismes privés : ce sont les associations diverses, ONG...
Les investisseurs et partenaires financiers : ils ont des exigences de rentabilité et de sécurisation des
ressources.

c. Acteurs interne :
Le commanditaire (ou demandeur, ou encore client interne) : C’est le premier concerné par le projet.
Le sponsor du projet : Le parrain du projet, le responsable du projet.
Les utilisateurs, les services impactés : Ceux qui sont concernés directement par les livrables (par
exemple la force de vente pour un nouveau logiciel de CRM). Les chefs de service comme les
collaborateurs sont à prendre en compte. Ces utilisateurs finaux tiennent une place centrale dans le
projet, car ils utiliseront directement le service, la nouvelle organisation ou le produit issu du projet.
La direction : représente le pouvoir décisionnel et de contrôle ultime
L'équipe projet : comprenant le chef de projet ainsi que les autres membres de l'équipe.
Les services supports impliqués : la comptabilité, la logistique, les ressources humaines,
l'informatique... qui apportent leur support dans le cadre des travaux d'analyse et de conception de
solutions.
Les actionnaires : ils sont en attente d’un résultat, d’une performance valorisant leur patrimoine.
Les autres experts : apportant leurs conseils ponctuellement (directeurs fonctionnels...).
Les syndicats et représentants du personnel : ces parties prenantes sont vigilantes quant à la défense
des intérêts des salariés.

3. Principaux rôles dans un projet informatique

a. Qu’est-ce qu’un Chef de projet informatique ?
Expert en informatique, le chef de projet informatique (CPI) peut également être appelé chef de projet
intégrateur, chef de projet applicatif, Project manager ou responsable de domaine. Il a sous son égide
plusieurs techniciens et ingénieurs qui ont chacun un rôle spécifique dans le traitement des demandes
de clients particuliers.
Garant de l’état d’avancement d’un projet informatique, le CPI doit ajuster les évolutions et les besoins
y afférents si cela s’avère nécessaire. Il doit également tenir compte des contraintes en termes de
financement et de délais. Il se doit donc de posséder de multiples capacités regroupant des compétences
techniques et managériales à la fois.

b. Quel est le rôle d’un chef de projet informatique ?

Rattaché à un directeur des systèmes d’information ou à un directeur des études, le chef de projet
informatique est à la tête d’un ou plusieurs services dans l’entreprise.
Accompagné par son équipe, le CPI a pour rôle principal de concevoir et d’intégrer un logiciel ou une
solution informatique spécifique. Ses tâches sont multiples et couvrent l’ensemble de toutes les étapes
du projet depuis le brief client (Le brief client, aussi appelé cahier des charges) jusqu’à la réception par
ce dernier ainsi qu’au suivi et maintenance.
La personne doit être capable de solutionner les différentes problématiques qui risqueraient de nuire au
projet. Elle doit avoir un esprit créatif pour pouvoir améliorer et sublimer sa création. Elle est amenée à
trouver des idées innovantes ainsi que des stratégies optimales qui seront bénéfiques pour l’entreprise.
Le chef de projet informatique est notamment spécialisé dans un langage informatique particulier.

c. Matrice d’assignation des responsabilités (RACI)

La Matrice d'Assignation des Responsabilités, souvent abrégée en RACI, est un outil de gestion de projet
qui vise à clarifier les rôles et les responsabilités des membres de l'équipe et des parties prenantes
impliquées dans un projet. L'acronyme RACI est dérivé des quatre principaux rôles ou responsabilités
qui peuvent être attribués à chaque personne ou groupe impliqué dans un projet :
❖ Responsable (R - Responsible) : La personne ou le groupe responsable est chargé de la
réalisation d'une tâche spécifique. Ils exécutent l'action nécessaire pour atteindre un objectif
particulier.
❖ Avisé (A – Accountable) : La personne ou le groupe responsable est celui ou celle qui prend la
décision finale et est ultimement responsable du résultat. Il ne peut y avoir qu’un seul « A » par
tâche ou activité.
❖ Consulté (C - Consulted) : Les personnes ou groupes consultés sont ceux qui fournissent des
informations, des conseils ou une expertise pertinente pour la tâche, mais n'ont pas
nécessairement le dernier mot dans la décision.
❖ Informé (I - Informed) : Les personnes ou groupes informés sont ceux qui doivent être tenus au
courant de l'avancement ou des décisions prises, mais qui n'ont pas de rôle actif dans l'exécution
de la tâche.

4. Caractéristiques de base d’un projet

Un projet est caractérisé par plusieurs éléments fondamentaux à savoir :
Objectifs : Les objectifs d'un projet sont les résultats spécifiques que l'on cherche à atteindre. Ils doivent
être clairs, mesurables, réalisables, pertinents et temporellement définis. Ces objectifs définissent la
raison d'être du projet et orientent toutes les activités qui en découlent.
Résultats ou Produits Attendus : Chaque projet vise à produire des résultats tangibles ou des produits
spécifiques. Ces résultats ou produits sont conçus pour satisfaire un besoin, résoudre un problème ou
créer de la valeur. Ils représentent la concrétisation des objectifs du projet.
Durée : La durée d'un projet correspond à la période pendant laquelle il est actif, de son début à sa fin.
La gestion du temps est cruciale, car elle définit les délais auxquels les objectifs doivent être atteints.
Une planification minutieuse du calendrier est essentielle pour respecter les contraintes temporelles du
projet.
Activités : Les activités du projet sont les tâches spécifiques et les étapes à suivre pour réaliser les
objectifs. Elles sont organisées de manière séquentielle ou parallèle et sont interdépendantes. La gestion
des activités implique la définition des priorités, la répartition des responsabilités et la coordination pour
assurer une exécution efficace.
Ressources : Les ressources du projet englobent tout ce qui est nécessaire pour mener à bien les activités
du projet. Cela inclut les compétences et les efforts des membres de l'équipe, les financements, les
équipements, les matériaux, et d'autres éléments nécessaires pour soutenir le travail du projet. Une
gestion efficace des ressources est cruciale pour respecter les contraintes de coûts et de délais du projet.
 5. Contraintes dans la gestion d’un projet
Définition : Les contraintes dans la gestion d'un projet informatique sont des limites ou des conditions
qui restreignent la manière dont le projet peut être planifié, exécuté et livré. Ces contraintes jouent un
rôle essentiel dans la définition du cadre du projet et ont un impact sur sa réussite.

a. Contraintes de délais :
- Les contraintes de délais fixent la période pendant laquelle le projet doit être achevé.
Exemple : dans un projet de développement de logiciel pour une entreprise de commerce
électronique, la contrainte de délai pourrait être la date de lancement prévue pour la saison des fêtes,
car le site doit être opérationnel avant cette période de forte demande.Contrainte externe absolue :
contraintes externes au projet qui s'imposent à tous. Si elle n'est pas respectée, le projet n'a plus de
sens.

b. Contraintes dues aux clients

- Les clients peuvent imposer des contraintes spécifiques sur les fonctionnalités ou les
caractéristiques du produit final.
Exemple : dans un projet de développement d'une application mobile pour un client du secteur de
la santé, le client peut exiger une conformité stricte aux réglementations en matière de protection
des données des patients, ce qui impose des contraintes de sécurité et de confidentialité..

c. Contraintes de coûts :
- Les contraintes de coûts limitent les ressources financières disponibles pour le projet.
Exemple : un projet visant à mettre à jour l'infrastructure informatique d'une petite entreprise peut
être soumis à la contrainte de coûts d'un budget limité, ce qui nécessite une gestion prudente des
dépenses.

d. Contraintes de qualité :
- Les contraintes de qualité définissent les normes ou les critères de qualité que le produit ou le
service final doit atteindre.
Exemple : Dans un projet de développement pour une application bancaire, des contraintes de
qualité peuvent inclure des niveaux de sécurité élevés pour protéger les données des clients et
garantir des transactions sans erreur.

CHAPITRE II : Découvrir les différentes méthodes de gestion de

projet
1. Méthodes prévisibles (cascades, V, Y)
Définitions
Cette catégorie regroupe les méthodes reposant sur une organisation stricte du travail et sur un
fonctionnement par étapes. Il n’y a ici aucune rétroactivité.
Dès que les contours du projet sont définis avec le client, le chef de projet se charge tout seul de veiller
à ce que chaque tâche soit accomplie au moment prévu et dans le respect des objectifs définis. C’est
seulement lorsqu’une tâche est bien exécutée que la phase suivante est lancée.
Ce type de management permet d’écarter tout risque en s’attachant strictement au respect des plans
préalablement établis.
 a. Le modèle en cascade
Le modèle en cascade, appelé Waterfall en anglais, tel qu’appliqué aux projets, est une approche linéaire
et séquentielle des différentes phases et activités du projet nécessaires à la livraison du ou des livrables.
La méthode en cascade est plus particulièrement utilisée aujourd'hui pour les projets dont la réalisation
de chaque étape dépend de l’étape précédente.
Exemple : Les projets de construction
✓ Construction des fondations d’une maison
✓ Construction des murs
✓ Le toit ne sera fabriqué que sur des murs solides
Un modèle en cascade générique ressemble à ceci :

1. Les avantages du modèle en cascade :

Avantage 1 - Structure et enchaînement logique
✓ Cette méthode se concentre sur un ensemble d’étapes définies en amont, réalisées dans un ordre
précis.
✓ Les équipes doivent terminer une phase entière avant de passer à la suivante.
Avantage 2 – Suivi simplifié
✓ Cette méthode permet de visualiser la progression du projet de manière claire et évidente.
✓ Aucune formation spécifique n’est requise au niveau de la gestion de projet.
Avantage 3 - Clarté des objectifs
✓ Les objectifs à atteindre sont claire dès le départ
✓ Cela donne aux équipes de la clarté et leur permet de travailler de manière ciblée, sans jamais
perdre l’objectif final de vue.
Avantage 4 – Traçabilité
✓ Il dispose de processus normalisés qui favorisent une communication efficace et précise des
informations.
✓ Pour le bon développement de chaque étape du projet, le transfert des informations doit être
effectué avec précision et de manière documentée.
2. Les inconvénients du modèle en cascade :
Inconvénient 1 – Complication des changements
✓ La méthode ne laisse pratiquement aucune place aux changements ou révisions inattendus
Inconvénient 2 – Exclusion du client ou utilisateur
✓ En tant que processus interne, la méthode s’intéresse très peu à l’utilisateur final ou au client
Inconvénient 3 – Les tests sont poussés à la fin
✓ Il est risqué de réserver la phase de test pour la dernière moitié d’un projet.

b. Le cycle en Y
Le cycle en Y est un modèle de gestion de projet qui comprend deux branches principales, chacune se
concentrant sur des aspects spécifiques du projet, avant de converger à nouveau.

i. En haut à gauche (Contraintes fonctionnelles) :

Capture des besoins fonctionnels : Dans cette première étape, l'accent est mis sur la compréhension
des besoins et des exigences fonctionnels du projet. Cela implique de recueillir des informations auprès
des parties prenantes pour comprendre ce que le produit final devra accomplir du point de vue des
fonctionnalités.
Analyse : Une fois les besoins fonctionnels capturés, une analyse détaillée est effectuée pour
comprendre en profondeur ces exigences. Cette phase consiste à examiner en détail les fonctionnalités
nécessaires, à identifier les dépendances et à créer une vision claire des attentes fonctionnelles du projet.
ii. En haut à droite (Contraintes techniques) :
Capture des besoins techniques : À l'opposé de la branche fonctionnelle, cette étape se concentre sur
les besoins techniques du projet. Il s'agit de définir les contraintes, les spécifications techniques et les
technologies nécessaires pour réaliser les fonctionnalités identifiées précédemment.
Conception générique : Une fois les besoins techniques capturés, on procède à une conception
générique. Cette phase consiste à élaborer une structure technique générale du projet, en identifiant les
composants majeurs et en déterminant comment ils interagiront pour répondre aux besoins techniques.
 iii. Convergence des branches :
Les deux branches se rejoignent à ce stade pour continuer ensemble :
Conception préliminaire : À partir des informations recueillies dans les phases précédentes, une
conception préliminaire est élaborée. Cela implique la création d'un plan global qui intègre à la fois les
aspects fonctionnels et techniques du projet.
Conception détaillée : consiste à élaborer un plan approfondi et complet du projet, en spécifiant en
détail les aspects fonctionnels et techniques, en créant une architecture système, en planifiant les
ressources et le temps, en générant de la documentation détaillée, et en intégrant les contraintes
identifiées, afin de guider efficacement l'implémentation du projet.
Codage et tests : Avec une conception détaillée en place, la phase de codage et de tests est lancée. Le
développement du logiciel ou de l'application commence, suivi de tests pour s'assurer que chaque
composant fonctionne correctement.
Recette : Enfin, une fois que le produit est développé et testé, il est soumis à une phase de recette, où il
est évalué pour s'assurer qu'il répond aux besoins et aux spécifications initiaux, à la fois d'un point de
vue fonctionnel et technique.

c. Le cycle en V
Le cycle en V en gestion de projet découle du modèle en cascade théorisé dans les années 1970, qui
permet de représenter des processus de développement de manière linéaire et en phases successives.
Le cycle en V se définit comme un modèle de gestion de projet composé d’une phase descendante, puis
d’une phase ascendante.
La lettre V fait référence à la vision schématique de ce cycle, qui prend la forme d’un V

1. Les principales caractéristiques de la méthode cycle en V

La méthode du cycle en V implique toutes les étapes du cycle de mise en œuvre d'un produit ou d'un
logiciel. Elle permet de définir le processus d'un projet en neuf étapes regroupées en trois phases : la
conception, la réalisation et la validation.
 La conception (la partie descendante) :
✓ L’expression des besoins et l’étude de faisabilité,
✓ La définition des spécifications et du cahier des charges fonctionnel,
✓ La conception générale/architecturale,
✓ La conception détaillée.
La mise en œuvre :
✓ Par exemple, la réalisation des composants automobiles ou le codage en informatique.
La validation (la partie ascendante) :
✓ Les tests unitaires, pour chaque composant ou fonctionnalité, cette étape fait écho à la
conception détaillée et lui fait face sur le schéma du V.
✓ L’intégration et les tests d’intégration, sur le produit fini, cette étape permet de vérifier le
fonctionnement du système défini à l’étape de conception générale
✓ La recette ou le test d’acceptation par le client, cette étape est la validation de la conformité face
à l’expression des besoins.
2. Les avantages du modèle cycle en V
Avantage 1
✓ Il apporte plus de précisions durant sa phase de test.
Avantage 2
✓ Il nécessite juste quelques réunions régulières pour le pilotage du projet et le suivi budgétaire.
Quant à la documentation, elle peut être créée à partir de templates déjà existants.
Avantage 3
✓ Il requiert moins de formation et de prérequis pour son application que d’autres méthodes telles
que Scrum.
3. Les inconvénients du modèle cycle en V
Inconvénient 1 – Il tolère mal les changements.
✓ Le retour en arrière est impossible. Pourtant, il n’est pas rare de rencontrer des problèmes
conceptuels lors de la phase de réalisation et de validation.
Inconvénient 2 – Il peut être long.
✓ Le risque que le produit dans sa version finale ne soit pas adapté aux évolutions apparues au
cours de sa conception. Faut-il alors reprendre le cycle depuis le début ?
Inconvénient 3 – Il s’adapte difficilement à certains types de projets.
✓ Le développement logiciel, par exemple, supporte difficilement le manque de réactivité et la
séparation entre la conception et la réalisation des activités.
 2. Méthodes imprévisibles (Agile)
a. Signification d'Agile en gestion de projet
Alors que les méthodes traditionnelles visent à traiter les différentes phases d'un projet d'une manière
séquentielle (que l'on nomme aussi cycle de développement en cascade ou encore cycle en V), le
principe des méthodes Agiles est de le découper en sous-parties (ou sous-projets) autonomes (on parle
également de développement itératif). Les parties (itérations) forment le projet dans sa globalité.

b. Manifeste Agile, Les principes fondateurs

Le Manifeste Agile est une déclaration rédigée par des experts en 2001 pour améliorer le développement
de logiciels
1. Les 4 valeurs agiles :
✓ Les individus et les interactions plus que les processus et les outils
✓ Des logiciels opérationnels plus qu’une documentation exhaustive
✓ La collaboration avec les clients plus que la négociation contractuelle
✓ L’adaptation au changement plus que le suivi d’un plan
2. Le Manifeste définit 12 principes :
✓ La priorité n°1 est d' obtenir la satisfaction client au plus tôt par la livraison rapide et régulière
de fonctionnalités attendues.
✓ Accepter les demandes de changement en cours de projet . Ce sont des opportunités pour donner
plus de valeur au projet et coller aux vrais besoins des clients.
✓ Mettre en œuvre des livraisons rapides reposant sur des cycles courts (quelques semaines). Ces
livrables doivent être opérationnels pour permettre des tests de validation des fonctionnalités
attendues.
✓ Coopération forte et continue entre les utilisateurs et le développement. A 'inverse des méthode
classiques où les rencontres entre les utilisateurs et la maîtrise d'oeuvre interviennent surtout en
début et en fin de projet.
✓ Donner de l'autonomie à des personnes impliquées et leur faire confiance.
✓ Privilégier le face à face comme canal de communication entre les parties. Les interactions sont
plus efficaces et plus riches. Tout va plus vite.
✓ L'important est d'avoir une application opérationnelle.
✓ Avancer avec un rythme constant compatible avec ce que peut produire l'ensemble des acteurs.
✓ Focus sur la qualité technique et la qualité de conception pour construire une base solide
renforçant l'agilité.
✓ Rester simple dans les méthodes de travail : ne faire que ce qui est nécessaire.
✓ Une équipe qui s'organise elle même produit de meilleurs résultats.
✓ En revoyant régulièrement ses pratiques, l'équipe adapte son comportement et ses outils pour
être plus efficace.
3. Méthodes Agiles
✓ La méthodologie Agile se base sur une idée simple. Planifier la totalité de votre projet dans les
moindres détails avant de le développer est contre-productif.
✓ Vous perdez du temps si vous organisez tous les aspects de votre projet en amont. Il est
effectivement rare que tout se passe exactement comme prévu. Souvent, des aléas surviennent
et vous forcent à revoir votre planification.
✓ La méthode Agile recommande de se fixer des objectifs à court terme. Le projet est donc divisé
en plusieurs sous-projets. Une fois l'objectif atteint, on passe au suivant, et ce jusqu'à
l'accomplissement de l'objectif final. Cette approche est plus flexible. Puisqu'il est impossible
de tout prévoir et de tout anticiper, elle laisse la place aux imprévus et aux changements.
4. La méthode Scrum et son fonctionnement en sprints
✓ La plus célèbre des méthodologies de gestion de projets déclinées de la méthode Agile relève
de la Scrum.
✓ Le responsable de projet s’appelle ainsi le SCRUM Master.
✓ Cette approche s’organise autour de cycles courts, qu’on appelle communément des itérations.
✓ En langage Scrum, une itération se nomme un sprint.
✓ À chaque nouveau sprint, l’équipe projet se rassemble pour lister les tâches à exécuter. Cette
liste s’appelle le sprint backlog.
✓ L’ensemble relève d’une logique de développement produit. C’est ce qui explique que la
méthodologie Scrum se déploie autour d’acteurs spécifiques, comme le Product Owner. Des
réunions Scrum ont d’ailleurs lieu quotidiennement. Il s’agit de courtes périodes d’échange,
pendant lesquelles les membres de l’équipe projet communiquent sur leurs avancées et leurs
difficultés.
5. Les autres méthodologies d’inspiration Agile
✓ Si Scrum reste la méthode Agile la plus utilisée, elle entre en compétition avec la méthode
Kanban pour ce qui relève du pilotage de projets dit mono- équipe.
✓ L’approche Kanban trouve son origine dans le mot japonais pour “panneau”. Elle nous vient
des procédures de production de Toyota, appliquées à l’univers de la programmation logiciel.
Cette approche consiste à croiser des tâches avec leurs états d’avancement, au sein d’une matrice
en colonnes.
✓ Le Lean Development est une méthode proche de Kanban. Il s’en différencie seulement par
deux objectifs : améliorer les apprentissages des participants et éviter le gaspillage de ressources

3. Cycle en V vs. Méthodes agiles

✓ De façon générale, l’on peut affirmer que le cycle en V se focalise sur le processus, tandis que
les méthodes agiles privilégient le produit.
✓ Dans le cadre des méthodes agiles (Scrum, XP, RAD, …), le projet s’affine par itérations , à
travers la répétition d’un cycle d’opérations (le sprint dans le cadre de la méthode Scrum ).
Comme nous l’avons vu, le cycle en V définit l’intégralité du produit final dès les premières
étapes, et ne laisse que peu de place à l’adaptation dans la suite du cycle.
✓ Ensuite, les méthodes agiles permettent d’élaborer le produit par incrémentation . On produit
un peu plus à chaque fois, morceau par morceau, pour aboutir au résultat final. Le cycle en V
concentre au contraire la réalisation de l’ensemble dans une seule phase, qui est intégralement
conçue en amont et vérifiée en aval.
✓ Ce manque d’adaptation et de flexibilité du cycle en V a précisément conduit à l’émergence des
méthodes agiles, en particulier dans le domaine du logiciel et du marketing, pour répondre aux
changements de plus en plus rapides des technologies et des demandes des consommateurs.
Planifier un projet
CHAPITRE III : Analyser le cahier des charges
1. Compréhension des besoins client
Idéalement, tout projet commence avec l'expression d'un ou de plusieurs besoins (qui seront formulés
en objectifs par la suite).
Selon qui exprime ce ou ces besoins et de quelle manière, vous (le chef de projet) allez devoir gérer des
scénarios potentiellement très différents. La première différenciation à faire est celle des projets internes
et externes.
Exemples :
Les exemples ci-dessous montrent comment la nature du besoin (interne ou externe) influence la manière
dont un chef de projet gère le projet, en prenant en compte les différentes parties prenantes, les exigences
spécifiques, et les objectifs à atteindre.
❖ Projet Interne : Imaginons que vous travaillez au sein d'une entreprise de fabrication de produits
électroniques. Votre équipe décide de développer une nouvelle version améliorée d'un produit
existant. Dans ce cas, le besoin provient de l'équipe interne de développement, car ils souhaitent
améliorer les performances du produit. Vous, en tant que chef de projet, devrez gérer ce projet
en collaboration avec vos collègues internes pour atteindre l'objectif de l'amélioration du
produit.
❖ Projet Externe : Maintenant, supposez que votre entreprise ait été contactée par un client externe
qui souhaite un produit personnalisé pour ses besoins spécifiques. Le besoin dans ce cas émane
du client externe qui exprime son désir d'obtenir un produit sur mesure. En tant que chef de
projet, vous devrez gérer ce projet en tenant compte des besoins spécifiques du client, des
contraintes de temps et de budget, ainsi que des attentes du client pour livrer un produit qui
réponde à ses exigences.
Tout projet commence avec une expression ou l'identification d'un besoin et celle-ci peut être plus ou
moins complète. Votre premier travail en tant que chef de projet, c'est donc d'analyser ce ou ces besoins,
les compléter si nécessaire et les reformuler sous forme d'objectifs et de livrables.
Besoin Livrable(s) potentiel(s)
Développer une présence en ligne Site vitrine, plan web marketing
Moderniser une image de marque Plateforme de marque avec charte graphique et logo
Permettre aux clients de réserver en ligne Système de réservation
A priori, nous avons là les livrables les plus évidents. Reste à savoir s'ils correspondent bien tous aux
attentes réelles du client et si celui-ci n'a pas oublié ou mal exprimé quelques besoins. Pour vous assurer
de formuler une proposition commerciale sur-mesure, ouvrez la communication et allez aux
informations. Pour ça, à vous de trouver le moyen le plus adéquat de le joindre, par téléphone, en
visioconférence, sur LinkedIn ou encore par mail.
Lors de vos échanges exploratoires, au-delà d'un relationnel irréprochable, vous allez porter une
attention particulière à 3 choses :
✓ les besoins explicites du client
✓ les besoins implicites du client
✓ les livrables potentiels
 a. Besoins explicites
Par "besoins explicites", comprenez les besoins exprimés clairement, sans ambiguïté et sur lesquels il y
a un consensus. Pour savoir si c'est le cas, essayez de les reformuler et analysez la réaction de votre
interlocuteur.
Dans notre exemple, le besoin de développer la présence en ligne de l'hôtel Paradis à travers la création
d'un site web est un besoin assez explicite.

b. Besoins implicites
La clientèle est principalement étrangère, le site devra donc impérativement être multilingue. Ce besoin,
en revanche, n'a pas été exprimé clairement par le client. On dira donc que c'est un besoin implicite et
une contrainte qui devra être prise en compte dès le lancement du projet.

Besoins explicites Besoins implicites Livrable(s) potentiel(s)

Développer la présence en ligne Rendre le site accessible dans 4 français, anglais, chinois et
langues : Site web (multilingue) russe.

Moderniser l'image de marque Conserver le nom et le logo de Adaptation de la charte

l'établissement graphique

Système de réservation Permettre au staff de l'hôtel de Système de réservation (et de

gérer ses prix et ses réservations gestion)
en back-office

2. Contexte du projet
Le contexte d'un projet englobe toutes les informations qui définissent et approfondissent le projet, y
compris son origine, les aspects réglementaires, culturels, économiques, concurrentiels et sociaux, ainsi
que son environnement de travail. Compte tenu de la complexité inhérente à l'environnement social,
économique et technique dans lequel un projet évolue, une analyse du contexte est essentielle pour un
chef de projet. Toutes ces données doivent être incluses dans la note de cadrage du projet, un document
de référence qui décrit l'étendue, les enjeux et les objectifs du projet. Il est crucial de fournir une base
solide pour la demande en exposant clairement le fondement de la demande, car cela facilite la
compréhension des besoins et des contraintes, tout en favorisant un dialogue efficace et en démontrant
la justification de la requête, même pour les développeurs qui attachent de l'importance à la finalité de
leur travail.
D’après la figure ci-dessus on peut extraire les éléments suivants :

• Environnement de Travail :
• Ressources :
• Références : Dans le cadre de la création d'une application de gestion de projet, des
références telles que des livres, des articles académiques ou des logiciels similaires
peuvent être consultées pour s'inspirer des meilleures pratiques.
• Techniques et Outils : L'utilisation de méthodologies de gestion de projet telles que la
méthode Agile ou la méthode en cascade peut être envisagée.
• Moyens de Communication : Les outils de communication tels que Slack, Microsoft
Teams ou des réunions régulières peuvent être utilisés pour coordonner l'équipe.
• Expériences Précédentes : Les expériences passées dans le développement de logiciels
similaires peuvent être examinées pour tirer des leçons et éviter les erreurs antérieures.
Exemple : L'équipe a accès à des documents de référence sur les meilleures pratiques en gestion de
projet, ainsi qu'à des outils de développement logiciel et à des réunions hebdomadaires pour la
communication.

• Contraintes :
• Charges de Travail : Les membres de l'équipe travaillent à temps partiel sur le projet en raison
d'autres responsabilités au sein de l'entreprise.
• Directives et Règlements : Le projet doit respecter les normes de sécurité des données établies
par l'entreprise.
• Calendriers Prévisionnels : Le projet doit être achevé dans les six mois suivant le lancement.
• Coûts du Projet : Le budget alloué au projet est limité à 100 000 euros.
Exemple : En raison des charges de travail existantes des membres de l'équipe, le projet doit être planifié
avec soin pour optimiser le temps disponible.

• Organisation du Projet :
• Participants / Compétences / Appartenances : L'équipe de projet comprend un chef de projet,
un développeur, un concepteur UX/UI, et un testeur. Le développeur a des compétences en
Python et le testeur possède une certification en tests de logiciels.
• Tâches / Rôles : Le chef de projet est responsable de la planification et de la coordination, le
développeur gère la programmation, le concepteur UX/UI se concentre sur l'expérience
utilisateur, et le testeur vérifie la qualité du produit.
• Produit(s) : Le produit final est une application de gestion de projet conviviale destinée à
l'usage interne de l'entreprise.
• Objectif(s) : L'objectif principal du projet est de mettre en place un système de gestion de
projet qui améliore l'efficacité opérationnelle de l'entreprise.
Exemple : Le développeur, spécialisé en Python, est responsable du développement de l'application,
tandis que le concepteur UX/UI s'assure que l'interface utilisateur est conviviale pour les utilisateurs
finaux.

3. Périmètre du projet
Le périmètre du projet, ou scope du projet, est l'ensemble des éléments qui composent un projet. Le
périmètre du projet permet de limiter les dérives des objectifs, de s'assurer d'un travail de qualité, de
cadrer le projet, et de visualiser ce qui doit être réalisé afin d'atteindre l'objectif.
Le scope du projet permet ainsi de cadrer le projet, et de sécuriser sa réalisation, aussi bien pour le
commanditaire du projet que pour la maîtrise d’œuvre (celui qui réalise).
Comme chaque projet est unique et que vous ne disposez pas d'un budget illimité ni d'une équipe ad
vitam æternam, il est primordial de déterminer avec précision le travail à réaliser (le périmètre projet)
ainsi que ce qui n'est pas compris dans le projet (ce qui est hors périmètre). Sinon vous vous retrouveriez
avec un projet sans fin, dans lequel on vient rajouter toujours plus de fonctionnalités à développer et de
tâches à réaliser.
C'est sur la base du périmètre de projet que l'on estime la charge de travail nécessaire, et donc bâtir le
planning projet et le budget.
Enfin, le périmètre projet est également l'une des 3 composantes du triangle d'or de la gestion de projet,
avec les coûts et les délais
Exemple:
Vous devez faire un saut à l'épicerie pour acheter des œufs.
Sur le chemin du rayon des produits frais, vous vous souvenez que vous n'avez plus de céréales. Vous
prenez donc une boîte. OK, deux boîtes. Vous vous laissez alors distraire par un couvercle rempli de
bougies parfumées. Et si vous en preniez une ? Vous vous rendez alors compte que vous avez aussi
besoin de serviettes en papier.
À ce stade, coincer des articles sous votre menton et les faire tenir en équilibre précaire dans vos bras
ne fonctionne plus. Les objets tombent de partout, quelles que soient vos tentatives pour les maintenir
ensemble
Vous devez alors vous rendre tout honteux à l'avant du magasin pour prendre un chariot. Vous mettez
encore quelques achats dans le chariot et vous retournez au rayon des produits frais pour prendre les
œufs (vous avez failli les oublier, n'est-ce pas ?).
Avant même que vous ne réalisiez ce qui s'est passé, votre arrêt de cinq minutes à l'épicerie s'est
transformé en une heure de shopping. Et ce qui était censé vous coûter moins de 5 euros a fini par vous
coûter plus de 100 euros. Et franchement ? Aviez-vous réellement besoin d'une autre bougie ?
Dans le cadre des projets professionnels, on parlerait de « dérive des objectifs », ce qui montre bien que
la définition et la gestion du périmètre du projet valent la peine de dresser une liste à l'avance.
Oui, certaines personnes ne se laissent pas distraire par les serviettes en papier ou les bougies parfumées
parce ces articles ne faisaient pas partie de leur liste de courses initiale. Grâce à la gestion du périmètre
du projet, vous pouvez être ce genre de personne.

4. Détection des risques liés à la nature du projet

Les risques font partie des informations essentielles qu'un chef de projet doit connaître sur son projet.
Dès le démarrage du projet, vous devez dresser la liste la plus exhaustive possible de tous les événements
générateurs de risques. Pour cela, rassemblez votre équipe et lancez un brainstorming afin de répertorier
tous les dangers possibles.
On distingue différents types 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, 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…
Vous le savez, le risque fait partie intégrante de la gestion de projet. Il est donc essentiel de mettre en
place un plan de management des risques, et ce dès les premières étapes du lancement du projet. Cela
permet d'identifier, de prévenir et de limiter ces risques en anticipant leur traitement grâce à la mise en
œuvre d'actions préventives et correctrices.
C'est une phase essentielle qui vous permettra de minimiser les pertes de temps et d'argent, et vous
préparera à gérer efficacement le risque lorsqu'il surviendra.

5. Proposition des solutions possibles

En gestion de projet, personne n'est à l'abri d'un échec. Parfois, malgré l'investissement, les efforts et la
bonne volonté du chef de projet et de son équipe, il arrive qu'un projet échoue. L'une des premières
questions à se poser est de savoir quelle est la raison de cet échec.

a. Manque de visibilité sur le projet

Il arrive parfois que le chef de projet et son équipe pilotent leur projet sans aucune visibilité. La liste des
tâches et le planning ont été préalablement définis lors du lancement du projet, mais ils n'ont jamais été
mis à jour en fonction de sa progression. Les membres de l'équipe savent sur quelles tâches ils doivent
travailler, mais ils n'ont aucune idée des priorités.
Solution :
Si vous pilotez votre projet à l'aveugle, celui-ci est voué à l'échec. Le diagramme de Gantt est un outil
indispensable en gestion de projet car il permet de visualiser rapidement toutes les tâches planifiées, leur
progression et leur échéance. Ainsi, vous et votre équipe avez une visibilité complète sur l'avancement
du projet, les tâches en cours et celles à venir. Vous pouvez donc mieux gérer vos priorités, anticiper les
retards potentiels, etc.

b. Objectifs imprécis
Un projet dont les objectifs ne sont pas clairement définis a de grandes chances d'échouer.
Pour construire une maison, si vous n'avez pas de plans précis, il est fort probable que l'équipe de
construction ne sache pas par où commencer, que le chantier soit chaotique et que la maison s'effondre
avant même d'être achevée. Il en est de même pour un projet.
Solution :
Dès le lancement, définissez clairement et précisément les enjeux et les objectifs du projet. C'est le point
de départ essentiel à tous projets. Les objectifs doivent être précis et réalistes afin que vous et votre
équipe sachiez dans quelle direction vous allez. De plus, une vision claire de votre projet va susciter
l'adhésion, la loyauté et l'implication de votre équipe projet.

c. Planning sous-estimé
La sous-estimation du temps nécessaire à l'accomplissement de votre projet peut avoir des conséquences
plus graves que le seul fait de manquer la date butoir sur le calendrier. Vous allez dépasser votre budget
prévisionnel car vous devrez payer le temps supplémentaire effectué par vos collaborateurs et les autres
acteurs du projet. La livraison retardée du projet peut aussi faire manquer d'importants marchés à
l'entreprise.
Solution :
Il est essentiel de préparer et d'évaluer votre planning avec précision. Des problèmes peuvent survenir à
chaque étape du projet et le retarder. Vous devez donc mettre en place une gestion des risques efficace
et vous accordez une marge de manœuvre en cas de problème. Il est préférable d'avoir un planning plus
large et de terminer en avance, plutôt que l'inverse.

d. Aucune visibilité sur la disponibilité des ressources

Vous n'avez aucune idée de la disponibilité des membres de votre équipe. Vous ne savez pas lesquels
de vos collaborateurs sont surchargés de travail et ceux qui sont disponibles. Certaines tâches prennent
du retard alors que d'autres terminent en avance. Ce manque de visibilité sur la charge de travail de votre
équipe nuit au bon déroulement du projet.
Solution :
Vous devez utiliser les feuilles de temps. Cet outil est indispensable pour connaître les disponibilités des
membres de votre équipe, et ainsi mieux répartir la charge de travail. Allégez vos collaborateurs
débordés en demandant à des collègues plus disponibles de leur venir en aide. De plus, grâce aux feuilles
de temps, vous connaissez la quantité de temps déjà passée sur une tâche, ainsi que le temps restant
avant son échéance : un bon moyen pour anticiper les retards.

e. Mauvaise communication
Une mauvaise communication, voire l'absence totale de communication au sein de l'équipe est une des
principales causes d'échec du projet. Une équipe qui ne communique pas va s'enfermer et se replier sur
elle-même. L'ambiance de travail se dégrade, ce qui a des conséquences néfastes sur le déroulement et
la réussite du projet.
Solution :
Il est indispensable d'entretenir un dialogue constant et constructif entre l'équipe et le chef de projet,
mais aussi avec les autres acteurs impliqués. Cela améliore le travail en équipe et permet à chacun d'être
informé de l'évolution du projet en temps réel.
Favoriser la communication et les échanges rend votre équipe plus productive, développe la confiance
entre les membres, ainsi qu'un sentiment de loyauté. Instaurez un climat de confiance en étant à l'écoute
de votre équipe. Les réunions de suivi ainsi que les logiciels de gestion de projet collaboratifs permettent
de maintenir une bonne communication au sein de l'équipe.

CHAPITRE IV : Préparer le projet

1. Répartition de l’ensemble des fonctionnalités en tâches
Répartition de l’ensemble des fonctionnalités en tâches est une décomposition hiérarchique des travaux
nécessaires pour réaliser les objectifs d'un projet.
Elle a pour but d’aider à organiser le projet, en définissant la totalité de son contenu et en servant de
référence pour planifier les activités et établir le budget prévisionnel. Elle est également utilisée pour
guider la gestion des risques, ou identifier les acquisitions nécessaires. Elle permet également de
déléguer et de contractualiser la mission confiée à chaque acteur.
Il existe en principe trois modèles :
1. Approche descendante
Dans l’approche descendante, on part du résultat global et on décompose le projet en sous-projets de
plus en plus détaillés, puis en groupes de tâches. Cette approche convient tout particulièrement lorsque
l’on connaît les contenus du projet ou on dispose déjà d’une expérience dans des projets similaires.
2. Approche ascendante
Avec l’approche ascendante, vous suivez la direction inverse et commencez par le niveau le plus bas.
On note d’abord toutes les tâches qui nous viennent à l’esprit, on les regroupe en groupes de tâches, puis
on affecte ces derniers à des sous-projets. Cette approche est notamment pertinente lorsqu’un projet
nous amène à découvrir de nouveaux domaines.
3. Approche combinée
L’approche combinée est une combinaison des deux techniques précédentes. On procède ici par étapes
successives : dans un premier temps, on liste les tâches.
On note ensuite les sous-projets et on leur attribue les tâches précédemment listées. Finalement, on
énumère les autres choses à faire. Cette approche jongle ainsi avec les approches ascendante et
descendante, ce qui permet de profiter des avantages des deux méthodes. Dans ce cadre, il est impératif
de ne pas oublier ou répéter un élément.

a. Organigramme des tâches du projet : exemple et modèle

Si nous souhaitions créer un nouveau site Internet pour l’entreprise, un organigramme des tâches du
projet axé sur les phases ressemblerait dans les grandes lignes à ce qui suit

b. Caractéristiques des tâches

Les tâches peuvent être décrites dans un tableau grâce à différentes caractéristiques.
1. Caractéristiques intrinsèques :
ces caractéristiques peuvent être déterminées dès l'identification des tâches:

- Libellé de la tâche : titre court facilement manipulable

- Description : informations complémentaires au libellé si besoin
- Données d'entrée : éléments nécessaires à la réalisation de la tâche
- Données de sortie : produit de la tâche
- Compétences nécessaires : liste des compétences nécessaires à la réalisation de la tâche.
- Charge de travail : nombre de jours ou d'heures nécessaire à la réalisation de la tâche par une
personne compétente
- Contraintes : si une contrainte du projet a un impact direct sur la tâche
 2. Caractéristiques extrinsèques :
Ces caractéristiques pourront être déterminées après la constitution de l'équipe projet et la planification :

- Nom du responsable de la tâche : personne qui rendra compte de l'avancement de la tâche au

chef de projet
- Ressources humaines : avant la constitution de l'équipe, lister les personnes susceptibles d'être
affectées à la tâche. Une fois l'équipe constituée, on fera apparaître le nom de la (des)
personne(s) retenue(s).
- Ressources matérielles : matériel associé à la tâche
- Synchronisation : lister les liens (prédécesseur - suivant) avec les autres tâches
- Date de début programmée : ne pourra être rempli qu'après la planification de l'ensemble des
tâches
- Date de fin programmée : ne pourra être rempli qu'après la planification de l'ensemble des
tâches.

2. Estimation de la durée de réalisation de chaque tâche

a. Données historiques (ou estimation analogue)
Basez vos estimations sur les résultats d’un projet précédent. Si votre entreprise a déjà réalisé un projet
similaire et que vous pouvez accéder au temps passé pour une tâche similaire, cela vous donnera une
bonne idée de la durée de la même tâche.
Encore une fois, si vous n’avez pas ces informations en interne, vous pourrez sûrement vous appuyer
sur des entreprises partenaires ou des données publiées sur votre industrie.
Ce type d’estimation est rapide, mais vous n’obtiendrez pas de résultats extrêmement précis.

b. Analyse statistique et mathématique (ou estimation paramétrique)

Si les mathématiques ne faisaient pas partie de vos matières préférées à l’école, vous n’aimeriez pas
cette partie. Si la tâche que vous évaluez est relativement simple et répétitive, vous pouvez utiliser des
calculs simples pour calculer la durée globale de l’activité.
Exemple : s’il faut une heure à une personne pour creuser un trou et que vous avez besoin de dix trous,
cela prendra dix heures de travail. Si vous doublez les ressources et disposez de deux excavatrices, cela
ne prendra que cinq heures. Si vous apportez une machine qui fonctionne au double de la vitesse d’une
personne, cela ne prendra que deux heures et demie.
Pas toujours applicable mais efficace sur certaines tâches simples.

c. Estimer une durée

Pour chaque tâche, prenez les trois durées suivantes : optimiste (Do), pessimiste (Dp) et la plus probable
(Dc). Calculez (et utilisez alors) la durée moyenne (Dm) :

(𝐷𝑜 +4𝐷𝑐 + 𝐷𝑝 )
𝐷𝑚 =
6
L’unité de mesure doit être maniable et rester significative par rapport à la tâche.

d. Durée
À partir de la charge de travail nécessaire, calculer la durée de la tâche en fonction :
✓ Du nombre de personnes affectées à la tâche
✓ Du niveau de compétences des personnes
✓ De la disponibilité des personnes
✓ De la disponibilité des éventuelles ressources matérielles affectées à la tâche
 ✓ Le travail représente la charge (en heures, en jours...) de travail nécessaire à la réalisation de la
tâche par une seule personne occupée à 100% de son temps de travail sur la tâche. Le travail
s'exprime en "jour-homme", "heure-homme", "mois-homme", etc.
✓ Expliqué autrement, un "jour-homme" correspond au travail d'une personne pendant un jour.
Un projet présentant 10 jours-homme de travail peut être réalisé en 10 jours par 1 personne, en
1 jour par 10 personnes, en 20 jours par une personne disponible à 50%, etc.

3. Ordonnancement des tâches

Les méthodes d’ordonnancement permettent d’élaborer un graphe qui représente l’ensemble des tâches
composant le projet ainsi que les liens qui existent entre elles.
Sur le graphe, apparaissent également la durée de chaque tâche, la date à laquelle elle peut débuter au
plus tôt et au plus tard.

a. LA METHODE M.P.M (Méthode des Potentiels et antécédents Métra)

Principe de la méthode : Cette méthode permet de réduire la durée totale d'un projet. On étudie les
délais sans prendre en compte les charges et les moyens disponibles.
Notions de base : La méthode est une représentation graphique qui permet de bâtir un « réseau ». Ce
réseau est constitué par des tâches (ou étapes).

Liaison orientées : Elles représentent les contraintes d'antériorités des tâches.

Exemple du réseau :

La méthode MPM a pour but de planifier la durée d'un projet, aussi nous devons mener des calculs sur
le graphe afin d'en déduire des renseignements sur son excitabilité.
Méthodologie de construction d'un réseau MPM.
1. Établir la liste des tâches (faire le partitionnement des tâches en fonction des ressources).
2. Déterminer des antériorités : tâches immédiatement antérieures pour chaque tâche.
3. Déterminer les niveaux d'exécution ou rang des tâches (très facile avec cette méthode).
4. Construire le réseau MPM.
5. Calculer la durée du projet, les dates début et de fin des tâches. Déterminer le chemin critique.
Impossible ici de mettre en évidence les marges : voir diagramme de Gantt.

b. Le diagramme de GANTT
Le diagramme de GANTT est un graphique (chrono gramme) qui consiste à placer les tâches
chronologiquement en fonction des contraintes techniques de succession (contraintes d'antériorités).
L'axe horizontal des abscisses représente le temps et l'axe vertical des ordonnées les tâches.
On représente chaque tâche par un segment de droite dont la longueur est proportionnelle à sa durée.
L'origine du segment est calée sur la date de début au plus tôt de l'opération (« jalonnement au plus tôt
») et l'extrémité du segment représente la fin de la tâche.
Ce type de graphe présente l'avantage d'être très facile à lire, mais présente l'inconvénient de ne pas
représenter l'enchaînement des tâches. Cette méthode est généralement utilisée en complément du réseau
MPM. On trace le plus souvent le GANTT au plus tôt ou « jalonnement au plus tôt » et éventuellement
au plus tard « jalonnement au plus tard ».

Analyse (Diagramme de Gantt) :

 - Le projet est réalisable en 18 jours ouvrés. Ici, avec les fins de semaines non travaillées il faudra
3 semaines et 3 jours.
- Les tâches normales sont représentées en bleu.
- Les tâches critiques sont représentées en rouge : B, E, F, L, et M.
- On distingue les marges totales en noir, et les marges libres en vert. Les tâches C, G, J, et K font
apparaître de la Marge Libre.
Remarques :
Le diagramme de GANTT sera modifié au fur et à mesure de l'avancement du projet. Il faut mettre à
jour ce diagramme régulièrement. Le chemin critique peut évoluer en fonction de l'avancement, du
retard, ou de toute modification sur une tâche. Les chemins « sub-critiques » ou « presque critiques »
peuvent alors devenir critiques.
M.P.M. :
« Méthode des Potentiels Métra » = Planning sous forme de réseau représentant graphiquement
l'ordonnancement des opérations d'un projet.
Ordonnancement :
L'ordonnancement, c'est l'arrangement qui permet d'exécuter séquentiellement les tâches ou les ordres
de fabrication, de façon à ce que l'ensemble du projet ou de la production soit achevé dans le temps
imparti.

4. Chemin critique
La méthode du chemin critique (Critical Path Method, CPM) est un algorithme basé sur les
mathématiques pour programmer un ensemble d'activités relatives à un projet.
La technique principale pour utiliser le CPM consiste à construire un modèle du projet qui inclut les
éléments suivants :
Une liste de toutes les activités requises pour finaliser le projet,
Les dépendances entre les activités, et une estimation du temps (durée) nécessaire à la réalisation de
chaque activité.
À l'aide de ces valeurs, le CPM calcule habituellement le chemin le plus long des activités planifiées
jusqu'à la fin du projet et les dates de début et de fin au plus tôt et au plus tard que chaque activité peut
avoir sans prolonger le projet. Ce processus détermine les activités « critiques » (c'est-à-dire se trouvant
sur le chemin le plus long) et celles ayant une « marge totale » (c'est-à-dire pouvant être retardées sans
que le projet dure plus longtemps).
Les tâches du chemin critique sont parfois appelées “tâches critiques” car elles ont une marge nulle,
c’est-à-dire qu’elles ne peuvent pas subir de retard et si elles ont du retard, elles retardent l’intégralité
du projet.
Une tâche ou activité du chemin critique ne peut pas être débutée avant que l’activité qui la précède et
qui a un lien de dépendance avec elle, soit terminée.
Comment trouver le chemin critique en 4 étapes ?
Nous venons de voir que la méthode du chemin critique est une technique de gestion de projet qui permet
d’identifier étape par étape les activités qui ne permettent aucun retard de livraison.
Pour calculer le CPM (Critical Path Method), nous allons suivre ce processus de 4 étapes:
 ✓ Découper le projet en tâches et déterminer leurs dépendances
✓ Estimer la durée de chaque tâche
✓ Créer le réseau PMP ou PERT "Program Evaluation and Review Technic"
✓ Identifier les tâches critiques
Exemple
1. Découper le projet en tâches
Pour définir nos tâches, nous allons prendre un exemple de tâches hypothétiques de la phase de
démarrage d’un projet de réalisation d’un site web :
Tâche Nom de la tâche
A Analyse De L’existant
B Objectifs Du Nouveau Site

C Analyse De La Concurrence

D Architecture Du Site
E Charte Graphique

F Etude SEO

2. Estimer chaque tâche

Une fois que le projet a été divisé en tâches, la durée et le coût de chaque tâche doivent être estimés, en
se basant sur des projets précédents et l’expérience des membres de l’équipe, on obtient donc le tableau
suivant pour notre exemple :

Tâche Nom de la tâche Durée (par jour) Prédécesseur Successeur

A Analyse De L’existant 3 - B

B Objectifs Du Nouveau Site 2 A C,D

C Analyse De La Concurrence 4 B F
D Architecture Du Site 5 B E

E Charte Graphique 7 D -

F Etude SEO 4 C -

3. Créer le réseau de PERT

La méthode PERT, ou "Program Evaluation and Review Technique" en anglais, est une approche de
gestion de projet qui vise à planifier, organiser et contrôler les activités nécessaires à la réalisation d'un
projet.
Pour dessiner le réseau PERT, vous allez représenter les étapes du projet par des cercles, et les tâches
pour atteindre ces étapes par des flèches.
 ✓ Identifier le chemin critique
✓ Pour cela, il faudra d’abord identifier les tâches critiques.
✓ Ce sont celles qui ont la plus longue durée.
✓ Le CPM (Critical Path Method) dans cet exemple est donc A-B-D-E.
✓ Et la durée totale de ce projet revient à additionner les durées des tâches critiques.
✓ Ce qui nous donne finalement une durée de 17 jours.
Voici le chemin critique tracé sur le réseau PERT :

La méthode PERT repose sur les principes suivants :

✓ Décomposition des Tâches : Le projet est décomposé en une série de tâches ou d'activités
spécifiques. Chaque tâche doit être clairement définie et mesurable.
✓ Séquencement des Tâches : Les tâches sont ensuite séquencées dans un ordre logique, en
déterminant les dépendances entre elles. Certaines tâches doivent être accomplies avant que
d'autres ne puissent commencer.
✓ Estimation des Durées : Chaque tâche est estimée en termes de durée, en utilisant des données
historiques, l'expertise de l'équipe ou d'autres méthodes d'estimation.
✓ Calcul des Dates au Plus Tôt et au Plus Tard : PERT calcule les dates de début au plus tôt
(Earliest Start Time - EST) et au plus tard (Latest Start Time - LST) pour chaque tâche, en tenant
compte des dépendances entre elles.
✓ Identification du Chemin Critique : Le chemin critique est la séquence de tâches qui détermine
la durée minimale requise pour achever le projet. Tout retard dans une tâche du chemin critique
entraînera un retard dans le projet.
✓ Gestion des Marges : PERT permet de gérer les marges de liberté, c'est-à-dire la marge de temps
disponible pour certaines tâches sans affecter la date de fin du projet.
✓ Analyse des Risques : PERT prend en compte l'incertitude liée aux estimations de durée en
utilisant des valeurs optimistes, pessimistes et probables pour chaque tâche. Cela permet
d'identifier les tâches les plus critiques et les plus risquées.
Notions de base :

• Prédécesseurs : Les prédécesseurs sont des tâches ou des activités qui doivent être achevées
avant qu'une tâche spécifique puisse commencer. En d'autres termes, ce sont les activités qui
précèdent directement une autre activité dans la séquence logique du projet.
 • Successeurs : Les successeurs sont des tâches ou des activités qui suivent immédiatement une
autre tâche dans la séquence du projet. Ils dépendent du fait que les tâches prédécesseurs aient
été achevées avec succès. En d'autres termes, une tâche devient le prédécesseur d'autres tâches
qui dépendent de son achèvement.

D’après la figure ci-dessus :

o Le prédécesseur de la tâche C est la tâche A
o Le successeur de la tâche A est la tâche C
La représentation graphique des tâches
Les tâches dans un réseau PERT sont
représentées par des flèches et deux cercles. Le
cercle situé à l'origine de la flèche indique le
début de la tâche, tandis que la pointe de la
flèche marque sa fin. Chaque cercle comporte
deux dates : une date de début au plus tôt, ce qui
signifie que la tâche devrait idéalement
commencer à cette date prévue, et une date au
plus tard, qui indique la limite maximale pour le
début de la tâche en cas de retard. Cette
différence entre les deux dates permet de
calculer la marge de liberté.
Dans l'exemple ci-dessus, nous avons observé la présence de certaines tâches avec une durée nulle. À
quoi servent ces tâches ?
De même, pour le chemin souligné en rouge, possédant les marges de liberté nulles, pourquoi sont-elles
représentées de cette manière, et en quoi peuvent-elles être utiles ?
a. Les tâches observées précédemment sont appelées des tâches fictives.
Une tâche fictive, également connue sous le nom de "tâche factice" ou "tâche artificielle", est une tâche
qui n'a pas de durée ou de ressources réelles associées à elle dans la planification d'un projet. Elle est
souvent utilisée dans la méthode PERT et dans d'autres méthodes de gestion de projet pour représenter
des dépendances logiques entre les tâches sans ajouter de complexité inutile à la planification.
b. Le chemin souligné en rouge est appelé le chemin critique.
Le chemin critique, également connu sous le nom de chemin le plus long, est la séquence de tâches dans
un projet qui possède les marges de liberté les plus courtes ou nulles. En d'autres termes, c'est la série
de tâches qui, si elles sont retardées, entraîneraient un retard dans la date de fin du projet. Le chemin
critique est essentiel car il identifie les activités qui ne peuvent pas être retardées sans affecter la date de
fin globale du projet.

5. Echéancier et la chronologie des tâches

Mettre sur pied un échéancier de projet est essentiel pour garantir la réussite de votre équipe et le respect
des délais. Pour visualiser votre plan de projet ou votre processus de travail sous forme de chronologie,
suivez ces étapes :

a. Énumérer les étapes du projet et définir clairement les échéances

Commencez par diviser le travail en tâches et attribuer clairement les responsabilités. Ensuite, ajoutez
des dates de début et des échéances qui vous aideront à estimer le temps nécessaire à chaque étape.

b. Ordonner vos tâches

Quelles tâches doivent-elles être accomplies en premier ? Certaines dépendent-elles de l’achèvement
d’autres tâches ? Quelle sera la dernière étape? C’est en répondant à ces questions que vous parviendrez
à ordonner vos tâches.
 c. Partager votre échéancier
Partagez votre chronologie de projet avec vos collègues. Toute l’équipe est alors sur la même longueur
d’onde concernant le plan du projet et les responsabilités de chacun, ce qui favorise l’adhésion des
parties prenantes.

d. Visualiser la progression du projet

Suivez la progression de votre équipe et assurez-vous que chacun est sur la bonne voie pour atteindre
les objectifs fixés et respecter les délais. Sans oublier de publier des mises à jour de statut lorsque des
jalons sont atteints pour informer l’équipe des dernières évolutions et la prévenir de changements
éventuels.

6. Affectation des ressources aux tâches

Il s'agit du processus qui consiste à affecter et planifier les ressources disponibles de la manière la plus
efficace et la plus économique possible. Les ressources sont indispensables aux projets, mais elles se
font rares. Il appartient donc au chef de projet de planifier les ressources au bon moment en respectant
le calendrier du projet.
Les différents types de ressources d’un projet
Une ressource est une entité matérielle ou immatérielle exploitée pour la réalisation d’une tâche. Quelles
ressources participent à la mise en œuvre d’un projet ? On peut les répartir selon les catégories suivantes:
1. ressources humaines,
2. ressources matérielles,
3. ressources financières,
4. ressources en temps.
Créer un planning des ressources
Le planning représente visuellement l’organisation et vos besoins en ressources, qu’elles soient
humaines, matérielles ou financières, sur une période donnée.
Par exemple : vous pouvez utiliser le diagramme de Gantt pour planifier votre projet : vous visualisez
ainsi l’allocation des ressources en fonction des tâches et du temps imparti, et les éventuels conflits
d’utilisation dans l’affectation des ressources.
Effectuer un suivi des ressources
Pour évaluer une situation et prendre les décisions qui s’imposent, vous avez tout intérêt à utiliser des
indicateurs de performance ou KPI (Key Performance Indicators).
Comparez à l’aide de ces indicateurs le «prévisionnel» avec le «réalisé» sur plusieurs plans :
✓ Ressources humaines : quelle est la productivité des ressources ?
Exemple de calcul : nombre de JH (jours/homme) alloués à une tâche multiplié par le pourcentage de
la réalisation de cette tâche.
✓ Ressources matérielles : quelle est la disponibilité ou la capacité de tel équipement ?
Exemple de calcul : nombre d’heures de travail prévues sur un équipement par rapport au nombre
d’heures disponibles de ce dernier = charge équipement.
✓ Ressources financières : quel est le coût actuel de mon projet? Respecte-t-il le budget alloué ?
Exemple de calcul : addition de toutes les dépenses consacrées au projet jusqu’au moment T.
Comparez ensuite les résultats obtenus avec ce qui était initialement prévu et prenez les décisions
adéquates selon la situation, qu’il s’agisse de tenue des délais ou de consommation du budget.

7. Maîtrise des coûts

La maîtrise des coûts consiste à superviser et à gérer les dépenses du projet et à se préparer aux risques
financiers potentiels. Cette tâche est généralement du ressort du chef de projet.
La maîtrise des coûts implique non seulement la gestion du budget, mais aussi la planification et la
préparation aux risques potentiels. Les risques peuvent retarder les projets et parfois même entraîner des
dépenses imprévues. La préparation à ces revers peut permettre à votre équipe d'économiser du temps
et, potentiellement, de l'argent.
La maîtrise des coûts suppose une grande discipline et commence dès :
1. La phase de faisabilité du projet
Dans un premier temps, la technique utilisée est une estimation analogique, c'est à dire une estimation à
partir de projets analogues (combien coûte la construction d'une maison de 150 m² habitables ? Entre
150 K€ et 300 K€, soit 1000 à 2000 € le m²).
2. Dans la phase d'avant projet
Le projet est détaillé, des choix techniques sont arrêtés ou proposés, la méthode paramétrique sera
utilisée (maison de deux niveau, avec sous sol, deux salles de bain, matériaux nobles, isolation renforcée,
6 pièces, trois salles de bain, deux WC, ...... Le coût sera affiné avec un degré de précision plus grand
(la maison coûtera entre 240 et 280 K€). A la fin de la phase d'avant projet, les derniers choix techniques
doivent être confirmés (types d'équipements de la salle de bain et de la cuisine, nature des revêtements,
...).
3. Avant de démarrer le projet
Le chef de projet construira le budget initial détaillé, méthode analytique, en s'appuyant sur des devis
ou sur des estimations argumentées et précises. Ce budget servira de référence pour évaluer
ultérieurement les dérives éventuelles lors du suivi du projet. Il s'agit d'une estimation contractuelle qui
lie le chef de projet et le donneur d'ordre.
4. Tout au long de la réalisation
Le niveau des dépenses sera comparé au niveau prévu et quelques fois des actions correctives seront
proposées

8. Détermination des points de validation

La création du dossier de faisabilité

• Le dossier de faisabilité est un document descriptif abordant les aspects techniques, qualité,
financiers et calendaires d’un projet. Il doit permettre à toutes les personnes concernées
d’appréhender les objectifs et les enjeux du projet et de statuer sur sa validation finale.
• Un dossier de faisabilité doit être établi, quelle que soit la nature d’un projet : développement
d’un nouveau produit, service ou prestation, nouveau projet technique de construction, etc.
• Il a pour but de :
o Définir le programme complet du projet (cahier des charges : analyse fonctionnelle, en
définissant les caractéristiques principales et secondaires du projet)
o Justifier le projet en terme économique et/ou statistique et/ou stratégique, ou à l’aide
d’une Analyse SWOT (Strengh/Forces, Weakness/Faiblesses,
Opportunities/Opportunités, Threats/Menaces)
o Elaborer et justifier le budget nécessaire à sa réalisation,
o Evaluer le coût global du projet : coûts prévisionnels d’exploitation, de maintenance,
de stockage, des énergies nécessaires, etc.
o Identifier toutes les contraintes réglementaires et normes en initialisant une analyse de
risques projet
o Définir un planning d’étude, de réalisation et de mise en œuvre afin d’estimer toutes
les phases et durées du projet ( Planning de GANTT ou PERT)
o Apporter tous les éléments nécessaires permettant la bonne compréhension du projet
o Déterminer tous les impacts possibles sur l’organisation, les opérations et les
ressources
o Identifier et évaluer les risques
Adopter l’approche Agile dans gestion
de projet
CHAPITRE V : Appréhender la méthodologie Agile Scrum
1. Définition de la méthode Agile Scrum
Définition : L'approche SCRUM est une méthode agile consacrée à la gestion de projet.
✓ Son objectif phare est d’améliorer la productivité des équipes, tout en permettant une
optimisation du produit grâce à des feedbacks réguliers du marché.
✓ En parallèle, la méthode SCRUM permet d’avoir une vue d’ensemble du projet pour chacune
des parties prenantes.
✓ Et elle permet aussi la réduction des bugs et une mise à jour régulière des priorités.

2. Manifest Agile (valeurs et principes)

✓ La notion de manifeste agile sous-entend l’idée d’une déclaration formelle.
✓ On comprend qu’il s’agit de la représentation d'un idéal à atteindre.
✓ Il s'agit du fruit d’une rencontre entre développeurs logiciel qui se sont réunis dans l’intention
de partager leurs expériences.
✓ Son objectif est de cadrer la pratique agile avec 4 valeurs et 12 principes. Voyons chacun de ces
valeurs et principes agiles plus en détails.

e. Les valeurs
1) Les individus et les interactions plus que les processus et les outils
- Qui construit la valeur d’une entreprise, qui crée les produits ? Ce sont bien les équipes.
- Une entreprise avec des équipes passionnées sera une entreprise à succès.
- Encore plus si elle utilise de bons processus.
- Des équipes engagées et passionnées sauront créer un produit de valeur et le contenu pour
convaincre.
2) Des logiciels opérationnels plus qu’une documentation exhaustive
- Une équipe de développement devrait se concentrer sur la production de fonctionnalités et non
sur la rédaction de documents.
- Avec les méthodes de gestion de projet classiques, les chefs de projet peuvent passer des heures
à mettre à jour des présentations ou des calendriers.
- La méthode Agile permet d’avoir des modèles de documents, qui sont toujours les mêmes, qui
se complètent rapidement avec l’essentiel des informations.
 3) La collaboration avec les clients plus que la négociation contractuelle
- Avec les méthodes traditionnelles de gestion de projet, le moindre changement budgétaire,
fonctionnel ou dans les délais, nécessitent de revoir totalement le projet.
- Elles incitent à fortement négocier avec le client.
- Avec la méthode Agile, il est facile de faire des modifications dans un produit.
- La collaboration est simplifiée.
4) L’adaptation au changement plus que le suivi d’un plan
- La dernière valeur du manifeste agile est l'acceptation des demandes changements même tard
dans le développement du produit.
- Les approches agiles de planification et de hiérarchisation permettent aux équipes produit de
réagir rapidement au changement.
- La flexibilité des approches agiles augmente la stabilité du projet.
- En effet, le changement dans les produits agiles est prévisible.
- Si de nouveaux événements adviennent, l’équipe produit intègre ces modifications dans les
développements en cours.
- Tout nouvel élément devient une possibilité d’apporter une valeur ajoutée au lieu d’un obstacle
à éviter, donnant aux équipes de développement une plus grande chance de succès.

f. Les principes
En plus des 4 valeurs agiles fondamentales, le Manifeste Agile décrit 12 principes de l'agilité. Ils vont
nous offrir des exemples concrets de la manière dont un produit Agile doit se construire.
1) Livrer de la valeur au client
- Le fonctionnement en itérations permet de délivrer plus vite le produit aux utilisateurs.
2) Intégrer les demandes de changement
- Pour le Manifeste Agile, le changement n’est pas négatif. Il est même positif. Il vaut mieux se
tromper tôt et de réparer ses erreurs rapidement que de se rendre compte trop tard que le chemin
emprunté n’était pas le bon.
3) Livrer fréquemment une version opérationnelle
- Découper votre produit en petits morceaux et vos développements en itérations courtes de deux
à trois semaines.
- À la fin de chaque itération, livrez les nouvelles fonctionnalités développées et testez-les.
4) Assurer une coopération entre le client et l’équipe
- L'équipe et le client doivent s’entendre, échanger et travailler ensemble.
5) Réaliser les projets avec des personnes motivées
- La confiance mutuelle est un point essentiel du Manifeste Agile. En d’autres termes, le
management d’une équipe agile doit se baser sur la transparence. Le micro-management, ici, est
à bannir.
- Contrôler étroitement une équipe de développeur ne va ni les engager, ni les motiver.
6) Privilégier le dialogue en face à face
- Il n’y a rien de plus efficace que d’avoir une équipe travaillant sur le même produit dans un
même espace de travail.
- Les membres peuvent alors se poser directement les questions, obtenir les réponses dans la
seconde.
7) Mesurer l'avancement sur la base d'un produit opérationnel
- L’objectif du produit n’est pas le processus, c’est sa valeur. Le processus est ce qui vous permet
de l’atteindre.
8) Faire avancer le projet à un rythme soutenable et constant
- La raison de découper un produit en petites tâches est de garder vos équipes motivées.
- Si vous travaillez sur un projet pendant une longue période, vos équipes rencontreront une
lassitude.
 - Ne surchargez pas non plus l’équipe avec trop d’heures supplémentaires. Cela aura un impact
sur la qualité de votre projet.
9) Contrôler l’excellence technique et à la conception
- Que ce soit dans le code ou dans la méthodologie, la rigueur va favoriser la construction d’un
produit de valeur.
10) Minimiser la quantité de travail inutile
- Si votre objectif est de produire rapidement un produit fonctionnel, il faut veiller à ne pas se
noyer sous les tâches complexes et inutiles. Gardez vos documentations simples, ne vous
embarrassez pas de réunions parasites.
11) Construire le projet avec des équipes auto-organisées
- Donner aux équipes l’autonomie d’agir de manière indépendante. Ils pourront alors prendre des
décisions rapidement en cas d’imprévus.
- Une équipe responsabilisée est une équipe qui fera de son mieux pour atteindre son objectif.
12) Améliorer constamment l'efficacité de l'équipe
- Le dernier des 12 principes du manifeste agile est l'amélioration continue de l'efficacité.
- Ce dont vous avez besoin, c’est d’un groupe en constante évolution, constamment engagé et à
la recherche de moyens d’améliorer la productivité.

3. Processus de la méthode Scrum

Il existe 3 groupes de phases et de processus Scrum, à savoir pre-game, game, post-game. Donc nous
allons diviser cette activité en 3 phases :
1) Pre-Game (planification + architecture)
2) Game (Sprint + réunion Scrum)
3) Post-Game (démo + clôture)

1) La première phase est la phase pre-game qui traite de la planification et de l'architecture

du projet :
- La planification se fait avec la création du backlog et de la liste des activités qui doivent être
effectuées pour décomposer les épics en user stories plus petites afin de constituer le backlog
du produit. De plus, les user stories sont transformées en tâches dans la phase de backlog de
sprint.
- Il vient ensuite l'architecture ou la conception de haut niveau. Ici, la plupart du travail réel dans
le backlog de sprint est décidé. Le travail accompli est de savoir comment travailler sur les
tâches, apporter des modifications si nécessaire, affiner les tâches, effectuer des analyses et
résoudre les problèmes qui apparaissent dans les processus.
2) La phase de game est la deuxième phase des phases de mêlée :
- C'est là que le travail proprement dit est accompli. Ici, chaque tâche affectée à la ressource est
démarrée et terminée avec la définition de terminé. Il y a 4 étapes pour accomplir les tâches,
o Développer le backlog de sprint, puis démarrer le développement, tester et documenter
les changements, etc.
o Fermer le statut de travail
o Mener des réunions d'examen
o Effectuez les modifications nécessaires à la définition du fait.
- Ici, dans cette phase au début, il y aura une réunion debout et chaque membre de l'équipe doit
assister à cette réunion. Après la phase de planification, lorsque le développement commence,
il peut y avoir des problèmes qui doivent être résolus, où alors le scrum master ou le propriétaire
du produit arrêtera le sprint et s'adaptera aux changements, puis redémarrera le sprint à nouveau.
Pour en savoir plus et explorer davantage.
- Les membres de l'équipe à la fin de chaque sprint doivent faire ce qui suit,
o Actualiser un burndown chart
 o Participer à la réunion de revue de sprint
o Enfin, participez à la réunion rétrospective
3) La phase post-game est la dernière des phases de mêlée :
- La phase de développement est terminée et les produits sont préparés pour la sortie. Toutes les
étapes nécessaires telles que les tests, l'intégration, la formation, la documentation utilisateur et
les supports marketing sont publiées.

4. Rôles et responsabilités
La Méthode Scrum : qui fait quoi ?

a. Le rôle du Scrum Master : le gourou

- Le Scrum Master est le guide de l'avancement du projet, celui qui s’assure que les principes et
les valeurs du Scrum sont respectés. C’est le coordinateur des équipes qui vérifie que la
communication est au top. Il améliore aussi la productivité et il lève les obstacles.

b. Le rôle du Product Owner

Lui c’est l’expert qui collabore avec le client. Souvent le fondateur ou le boss.

- Il définit à la suite des feedbacks clients les spécificités fonctionnelles du produit.

- Il les priorise ensuite avec l’équipe.
- Il valide les fonctionnalités développées.
- Il endosse le rôle du client auprès de l’équipe.

c. L’équipe
- Elle est constituée des développeurs. Dans la méthode SCRUM, il n’est pas censé y avoir de
hiérarchie entre eux, quand bien même leur savoirfaire et compétence seraient différents.
Idéalement une équipe contient 6 à 10 personnes pour être la plus efficace possible.

d. Stakeholders
- Dans Scrum, une partie prenante (Stakeholder) est toute personne ayant un intérêt direct dans le
produit qui ne fait pas partie de l'équipe Scrum. En tant que Product Owner, vous pouvez
considérer les parties prenantes comme toute personne ayant un intérêt ou une influence sur le
produit. Ce sont les personnes qui vous aideront à découvrir, développer, publier, soutenir et
promouvoir le produit

5. Evénements Scrum
Les grandes étapes de la méthode agile (ou méthode SCRUM)

a. Étape 1 : Le Product Backlog

- Dans cette phase, le Product Owner rencontre le client et analyse son besoin. Il identifie toutes
les fonctionnalités dont le produit devra être composé (les user stories) dans ce qui s’appelle le
Product Backlog.
- Ce “ cahier des charges “ n’est pas fixé pour toujours, et pourra évoluer en fonction des besoins
du client et l'avancement du projet. L’équipe décide de ce qu’elle peut faire et dans quel ordre
le faire.

b. Étape 2 : Le sprint
- La méthode SCRUM se caractérise par une répartition de chacune des tâches à faire. L’équipe
trie les fonctionnalités et tâches qu’elle répartit dans des Sprint (durée de cycle de deux
semaines).
- Et pendant ce cycle, l’équipe s’occupera par exemple uniquement de coder une fonctionnalité
du produit qu’elle devra livrer à la fin de cette phase.
1) Le sprint planning meeting : on organise avant chaque sprint une réunion de planification.
 - C’est une sorte de négociation entre le product owner et l’équipe technique : le sprint planning
meeting. Cette réunion permet de sélectionner dans le product backlog les exigences les plus
prioritaires pour le client.
- Le product owner propose des user stories. L’équipe technique analyse les user stories, les
traduit en tâches techniques, et regarde en combien de temps chacune des user stories pourra
être réalisée. Après négociation et décision concernant les choses à faire, les tâches constituent
le sprint backlog.
2) Le Daily SCRUM : la mêlée quotidienne
- Dans l’optique de respecter la méthode SCRUM, chaque matin, quand l’équipe est au complet
on réalise le daily scrum : une réunion de 5–10 minutes, qui se fait debout (pour aller plus vite
!) où l’on parle de trois choses :
o Ce qu’on a fait hier ?
o Quels problèmes on a rencontrés ?
o Que va-t-on faire aujourd’hui ?
- Cette réunion permet de motiver et stimuler les équipes et sans cesse se reposer la question du
sens de ses actions …
3) Et concrètement : comment on s’organise dans le sprint ?
- Pour les ingrédients, vous pouvez vous équiper avant le sprint : d’un tableau velleda aimanté et
de post-it de couleurs.
- Le tableau est divisé en trois colonnes : à faire, en cours, réalisé.
- En début de sprint, on recense chacune des petites tâches qui seront nécessaires pour réaliser la
fonctionnalité en question du produit. On représente chaque tâche par un post-it de couleur.
Elles se trouvent dans la première colonne : à faire.
- Au fur et à mesure qu’elles seront réalisées, elles seront bougées vers la droite. L’équipe a établi
combien de temps prendrait chaque tâche. Il est ainsi facile de voir pendant un sprint si l’équipe
tiendra ses timings et ces objectifs. Cela force à tendre vers l’efficacité plus que la perfection.

c. Étape 3 : Sprint Review

- Tous les vendredis qui closent un sprint on teste les bénéfices de la fonctionnalité avec le
Product Owner.
- On fait une démo de ce qui a été créé. Puis le destinataire de la fonctionnalité (le client par
exemple) confirme ou non si la fonctionnalité marche comme il le souhaitait. La boucle est
bouclée !

d. Étape 4 : Sprint Retrospective (Rétrospective de Sprint)

- Venant immédiatement après la revue de Sprint, il s'agit d'un bilan dont l'objectif est
l'amélioration continue des pratiques. L'équipe échange sur les réussites, les difficultés, relève
ce qui a fonctionné ou non. Avec toujours des leçons à tirer pour les prochains Sprints.

6. Artéfacts Scrum
Comprenant des entrants et sortants du processus, appelés "artéfacts".

- Le mot artefact désigne un produit ayant subi une transformation, même minime, par l'homme.
- Les artefacts SCRUM sont au nombre de 3 :
1) Product Backlog :
- liste des fonctionnalités du produit.
- Au démarrage du développement d’un produit agile, le MVP va être découpé en petites
fonctionnalités ou tâches à réaliser pour faciliter sa construction.
- Le Product Backlog est une sorte de réservoir regroupant l’ensemble des fonctionnalités du
produit. Les tâches doivent y être ordonnées avec discernement en fonction de la priorité dans
laquelle elles doivent être réalisées.
 2) Sprint Backlog :
- Planification des éléments du Product Backlog à mettre en oeuvre lors du Sprint pour livrer
l'incrément de produit doté des fonctionnalités requises pour cette étape.
- Le cadre méthodologique SCRUM divise le calendrier d’une équipe en cycles qui se répètent,
nommés Sprint.
- Le Sprint Backlog est une vue en temps-réel, très visible du travail que l’Équipe planifie
d’accomplir durant le Sprint et il appartient uniquement à l’Équipe de Développement.
3) L'incrément de produit :
- Durant chaque Sprint, l’équipe de développement réalise un incrément de produit.
- Un Sprint démarre lorsque le précédent est terminé. Il s'agit d'un processus incrémental.

CHAPITRE VI : Manipuler l’outil de gestion de projet Agile

(Scrum/Jira)
1. Présentation de Jira
a. C’est quoi Jira?

Jira Software est une solution de gestion de projet éditée par l’entreprise Atlassian Elle permet aux
équipes de s’organiser efficacement, d’établir une communication durable et de visualiser le projet en
un coup d’œil grâce à ses tableaux de bord personnalisés. Cet outil est reconnu comme la solution la
plus utilisée par les équipes de développement logiciel. Jira Software permet également de :

- Travailler en méthode agile grâce aux tableaux Kanban et Scrum.

- Accélérer la livraison des projets
- Améliorer en continu des projets
- Faciliter le travail des équipes

b. Quelles équipes utilisent Jira Software ?

Jira s’adapte aux différentes équipes d’une entreprise.

- Jira Work Management pour les équipes métier (Marketing/RH/Finance…),

- Jira Service Management pour les équipes de support (DevOps),
- Jira Software pour les équipes de développement de logiciel (Équipe Agile) ou pour de la
gestion de projet complexe.

c. Pourquoi utiliser Jira Software quand on est une équipe de développement ?

Pour pouvoir l’intégrer avec un dépôt Git (Bitbucket, Github, Gitlab…)

- Pour avoir un suivi visuel des tâches : backlog, tableau de bord, tableau agile,
- Pour gérer l’avancée du projet à l’aide d’un reporting,
- Pour travailler à distance grâce à l’application mobile Jira Software Cloud.

d. Qu’est-ce qu’un ticket dans Jira ?

 - Un ticket est une tâche à effectuer, c’est un élément de travail.
- Un ticket suit plusieurs étapes : à faire, puis en cours, puis terminé, et on peut ajouter
d’autres selon le type du projet (exemple :recette ,en attente..).
- On peut dire que le ticket passe dans chaque étape du workflow (flux de travail).
- Les tickets dans Jira peuvent être de plusieurs types. Dans un projet de développement logiciel,
on retrouve les types de ticket suivants :
o Une épic (épopée) :est considérée comme un grand objectif ou une grosse fonctionnalité
devant être simplifié et divisé en plusieurs tâches afin d’organiser le travail des équipes
agiles,
o Une story : représente une fonctionnalité à réaliser,
o Une tâche : est généralement une tâche technique à effectuer,
o Un bug : désigne un problème à corriger
Une epic peut contenir :soit epic ou tâche ou story
Une tâche peut contenir des sous-tâches(ticket)

e. Qu’est-ce qu’un projet dans Jira ?

- Un projet Jira regroupe des tickets afin de réaliser un objectif.
- Dans Jira , vous avez différentes façons de construire un projet : vous pouvez en créer un par
équipe ou par produit. Cela dépend de votre vision du projet et de l’organisation de vos équipes.
- Chaque projet Jira possède une clé unique. Par exemple, pour un projet web, la clé pourra être
WEB. Cela aura un impact sur les identifiants de chaque ticket : le premier ticket créé sera
WEB-1, le deuxième ticket WEB-2, etc.
- L’organisation des projets est importante car les droits d’accès sont gérés par projet : cela permet
de garantir la confidentialité des informations. Votre collègue des ressources humaines n’aura
pas accès aux projets de développement logiciel ; et inversement, les développeurs ne verront
pas les tickets de RH ou Marketing par exemple.

f. C’est quoi un Backlog ?

- Un Backlog est une liste de fonctionnalités ou d’éléments de travail. Ça peut être des tâches
techniques ou des exigences non fonctionnelles.
- En Jira ,Un backlog contient la liste des épics ou tâches avec leurs tickets et leurs prépositions
(durées ou points) et la personne assignée de faire le ticket.
- Un ensemble de tickets appartient à un tableau sprint.
 2. Installation et configuration d’un compte Jira
a. Installation de Jira
- Il existe deux possibilités pour utiliser Jira gratuitement :
o Télécharger la version gratuite du logiciel sur :
https://www.atlassian.com/fr/software/Jira/download-journey
o Utiliser la version Jira cloud free online : via
https://www.atlassian.com/fr/software/Jira/free
- Puisque les deux versions nécessitent une connexion internet en veut suggérer d’utiliser la
version Jira Cloud.

b. Jira Desktop
Lorsque vous installer la version desktop de Jira vous aurez l’accès au logiciel via le navigateur sur le
lien : http://localhost:8080/secure/SetupMode!default.jspa
Et vous suivez les mêmes étapes pour créer un projet Jira dans le cloud (page suivante).

c. Etapes pour la création compte Jira sur Jira cloud

- On se connecte sur https://id.atlassian.com/login
- On se connecte avec un compte mail ou on crée un nouveau compte.
 - Après confirmation du compte : on se connecte pour créer un projet agile Scrum.

3. Création de projet avec Jira

Pour créer un projet Scrum Jira, on se rend au menu en haut projets, ensuite on clique sur créer un projet.

Sur la fenêtre qui s'ouvre cliquez sur Développement logiciel Scrum, ensuite cliquez sur suivant

Cliquer sur sélectionner

Renseigner le nom du projet, le champ clé se remplira automatiquement, puis cliquer sur Envoyer.

Enfin le projet est créé avec succès

 4. Création d’un backlog product
Après la création du projet, un backlog vide est créé automatiquement, il suffit de cliquer dans le menu
latéral pour y’accéder :

5. Ajout des différents types de tickets

Dans notre Backlog, On commence à créer les types des tickets en cliquant sur créer au niveau de la
barre de navigation :

Puis, on choisit un type du ticket : Epic, tâche, Story ou Bug, dans cet exemple on a choisi Epic
On donne à notre ticket un nom, on peut ajouter une description du ticket

En cliquant sur créer le premier ticket sera créé avec le nom : FS-1, dans ce cas nous avons créé un ticket
du type epic, pour visualiser les tickets, on clique sur le ticket qui apparaît dans le menu à gauche, on
peut aussi créer d'autres tickets en cliquant sur Créer un ticket.
Un champ apparaît pour saisir le titre du ticket, on peut même modifier le type du ticket en cliquant sur
la petite icone en bas à gauche

6. Planification d’un sprint

Pour créer un sprint, il faut accéder au backlog (voir capture ci-dessous) puis on clique sur le bouton
créer un sprint.
Un nouveau tableau de sprint se crée automatiquement, pour pouvoir ajouter un nouveau titre au sprint
ainsi que des dates on clique sur ajouter des dates :

Ensuite, une nouvelle fenêtre apparaît pour finaliser la planification du sprint. Cette étape nécessite de
définir clairement les objectifs du sprint ainsi que la date de début et la durée du sprint. Il est
recommandé de déterminer la durée du sprint avant de fixer la date de fin.
Pour enregistrer la modification on clique sur mettre à jour.
Le sprint est correctement configuré à ce stade, mais il est nécessaire d'ajouter des tâches à ce sprint
pour le démarrer. Pour ce faire, il suffit de faire glisser les tâches depuis le backlog vers le sprint.
 7. Manipulation du tableau de bord de sprint

Lorsque le sprint démarre, une

fenêtre pop-up apparaît pour
permettre la mise à jour des dates et
de la durée. Après le démarrage du
sprint, le tableau des sprints actifs
affiche les informations de la
manière suivante.

La colonne "A faire" rassemble toutes les tâches ou tickets qui n'ont pas encore été traités, la colonne
"En cours" regroupe ceux sur lesquels on travaille actuellement, tandis que la colonne "Terminé"
contient les tâches ou tickets qui ont été clôturés.
Afin de suivre l'avancement de réalisation des tâches, il suffit de faire glisser chaque ticket vers la
colonne correspondante en fonction de son état. Cela permet une meilleure visualisation et manipulation
des tickets.

8. Utilisation de la feuille de route (roadmap)

Les roadmaps sur Jira offrent plusieurs avantages, notamment :

• Visualisation claire de la progression : Les roadmaps permettent de visualiser clairement la

progression des tâches et des projets en cours, ainsi que les jalons importants à venir. Cela
permet aux équipes de mieux comprendre où en est le projet et de se concentrer sur les tâches
les plus importantes.
• Planification efficace : Les roadmaps de Jira permettent de planifier les tâches de manière
efficace en définissant les priorités et les dépendances entre les différentes tâches. Les équipes
peuvent également utiliser les roadmaps pour définir des dates limites et des délais réalistes pour
chaque tâche.
• Collaboration en temps réel : Les roadmaps de Jira permettent une collaboration en temps réel
entre les membres de l'équipe, en permettant à tous de visualiser les mises à jour et les
changements en temps réel. Cela facilite la communication et la collaboration entre les membres
de l'équipe.
 • Alignement des objectifs : Les roadmaps de Jira permettent de s'assurer que tous les membres
de l'équipe sont alignés sur les objectifs du projet. Les équipes peuvent utiliser les roadmaps
pour communiquer les objectifs du projet et les résultats attendus, ce qui aide à maintenir un
objectif commun.
En résumé, les roadmaps sur Jira offrent un moyen efficace de planifier, suivre et communiquer les
progrès d'un projet, tout en facilitant la collaboration et l'alignement des objectifs entre les membres de
l'équipe.
Pour accéder aux feuilles de temps, il faut
cliquer sur l'option "Feuilles de temps" du menu
situé à gauche.

Examinons l'interface des feuilles de temps ci-dessous.

Les feuilles de temps présentent un calendrier affichant les dates en haut de la page, ainsi qu'un visuel
des sprints. La roadmap propose trois modes d'affichage des dates : par semaine, mois ou trimestre, et
inclut également un bouton "Aujourd'hui" pour retourner rapidement à la date actuelle. Une ligne
verticale orange marque la date actuelle et se déplace au fil du temps pour rester synchronisée avec la
date courante. La roadmap nous permet également de créer des epics. Maintenant, nous allons ajouter
des épics pour travailler avec les roadmaps.
Pour commencer, nous allons créer les épics.
Puis, nous ajouterons des tâches pour chaque epic en cliquant sur le bouton plus qui s'affiche à côté de
l'épic.

Les tâches sont ajoutées automatiquement avec le statut "à faire".

Ensuite, nous allons fixer des dates pour chaque epic en positionnant le curseur sur la ligne de l'épic
dans l'agenda. Une barre apparaîtra, et nous cliquerons dessus pour créer d'abord la barre de progression
correspondant à l'épic concerné. Ensuite, nous modifierons les dates de début et de fin de cette barre.
Pour ajuster la durée de l'événement, il est possible de modifier la barre de progression située à
l'extrémité. Il est alors possible soit d'augmenter, soit de diminuer la taille de cette barre afin de
déterminer les dates de début et de fin correspondantes.

Si une liaison existe entre des événements, il est également possible de les relier entre eux.

9. Génération des rapports Agile

Les rapports sur Jira offrent plusieurs avantages, notamment :
1. Visualisation claire de l'état du projet : Les rapports permettent de visualiser rapidement l'état
d'avancement d'un projet en fournissant des indicateurs clés tels que le nombre de tickets
ouverts, résolus, en attente, etc.
2. Analyse des tendances : Les rapports permettent de suivre l'évolution d'un projet sur une période
donnée, ce qui permet d'analyser les tendances et d'identifier les problèmes potentiels.
3. Facilité de collaboration : Les rapports peuvent être partagés facilement avec d'autres membres
de l'équipe, ce qui favorise la collaboration et la prise de décisions en temps réel.
4. Amélioration de la prise de décision : Les rapports fournissent des données concrètes et
objectives qui peuvent aider les responsables de projet à prendre des décisions éclairées et à
ajuster la stratégie en conséquence.
5. Personnalisation : Les rapports sur Jira peuvent être personnalisés en fonction des besoins de
chaque projet, ce qui permet d'obtenir des données pertinentes et spécifiques à chaque situation.
Exemple de Rapport généré par jira :
Un Burndown chart (ou graphique de consommation) en Jira est un type de rapport qui permet de
visualiser l'avancement d'un projet agile. Il s'agit d'un graphique qui montre l'estimation de l'effort
restant (en heures, en points de complexité ou en toute autre unité d'estimation) à réaliser sur les tâches
du projet par rapport au temps écoulé.
Le Burndown chart Jira peut être utilisé pour visualiser la progression de l'équipe de développement sur
un sprint ou sur l'ensemble du projet. Il permet également de déterminer si le projet est en avance, à
l'heure ou en retard par rapport au plan initial.
Le graphique est composé de deux axes : l'axe horizontal représente le temps, tandis que l'axe vertical
représente l'effort restant à réaliser. Le Burndown chart peut être utilisé pour identifier les problèmes et
les retards éventuels, pour ajuster les plans de projet en conséquence et pour encourager l'équipe de
développement à travailler efficacement pour atteindre les objectifs du projet.
Pour accéder aux rapports sur Jira, il suffit de cliquer sur le menu "Rapport" qui est affiché à gauche.

Après cela, Jira proposera un ensemble de rapports permettant de générer automatiquement un

rapport de type choisi en un seul clic.
Mettre en œuvre des outils de gestion de versions et de
mesure de la qualité du code

CHAPITRE VII : Manipuler les outils de gestion de versions

(Git/Gitlab)
1. Intérêt de la gestion de version
La gestion de versions également appelé historique de versions ou contrôle de versions (en anglais
version control system (VCS)) se réfère, dans le milieu numérique, au stockage de plusieurs versions de
fichier(s) afin de pouvoir tracer l'évolution chronologique à travers les changements apportés d'une
version à l'autre.
Elle peut s'appliquer à un fichier individuel (exemple : un document texte) ou à plusieurs fichiers d'un
projet; elle peut se faire au niveau individuel ou dans des groupes.
La gestion de versions se fait aussi à la base de plateformes collaboratives privées ou open source,
comme par exemple GitHub ou GitLab.
On peut diviser les systèmes de gestion de versions en trois catégories :

a. Gestion de versions locale

Dans un système de gestion de versions locale,
le dépôt (code ou code de source) avec les
changements se trouve physiquement sur la
même machine qui stocke les fichiers tracés

b. Gestion de versions centralisée

Dans la gestion de versions centralisée, le dépôt
qui contient les informations sur les
changements se trouve sur une autre machine
par rapport aux fichiers de travail. Le cas de
figure le plus commun consiste à garder le dépôt
des changements sur un serveur centralisé,
tandis que les différents ordinateurs individuels
des personnes qui participent au projet ne
gardent que la dernière version des fichiers de
travail

c. Gestion de versions distribuée ou décentralisée

La gestion de versions distribuée combine la cloud comme GitHub ou GitLab, qui s'occupe
gestion de version locale et centralisée en créant de centraliser les changements.
deux dépôts des changements :
1.Le premier se trouve sur la même machine des
fichiers de travail
2.Le deuxième se trouve dans une autre
machine, souvent un serveur ou une plateforme
La gestion distribuée est notamment l'une des éléments principaux des projets open source
La gestion de versions décentralisée consiste à voir l'outil de gestion de versions comme un outil
permettant à chacun de travailler à son rythme, de façon désynchronisée des autres, puis d'offrir un
moyen à ces développeurs de s'échanger leur travaux respectifs. De ce fait, il existe plusieurs dépôts
pour un même logiciel.
Ce système est très utilisé par les logiciels libres.
La gestion distribuée est notamment l'une des éléments principaux des projets open source
La gestion de versions décentralisée consiste à voir l'outil de gestion de versions comme un outil
permettant à chacun de travailler à son rythme, de façon désynchronisée des autres, puis d'offrir un
moyen à ces développeurs de s'échanger leur travaux respectifs. De ce fait, il existe plusieurs dépôts
pour un même logiciel.
Ce système est très utilisé par les logiciels libres.
Par exemple, GNU Arch et Git sont des logiciels de gestion de versions décentralisée.
Dans ce schéma qui utilise Git et GitHub comme exemple (le même principe peut-être appliqué à
d'autres systèmes), le dépôt local se trouve dans un dossier .git sur l'ordinateur d'une personne. Ce dépôt
local est partagé en open source à travers un dépôt central qui se trouve sur la plateforme cloud GitHub.
Ce dépôt central peut être utilisé par plusieurs personnes pour :
• Contribuer au même projet: envoyer des changements qui sont ensuite incorporés dans le dépôt
central et peuvent donc être ensuite propagés à tout dépôt local connecté,
• Utiliser ce dépôt central comme base pour un autre projet.

2. Présentation des outils existants de gestion de versions

Wiki : appelée dans ce contexte souvent historique des versions, est l'une des fonctionnalités principales
caractérisant tout système qui s'inspire du principe wiki. Des systèmes de ce type peuvent se trouver à
plusieurs endroits, avec des fonctionnalités légèrement différentes, comme par exemple dans :
✓ Moodle : une plateforme pédagogique très utilisée dans la formation et l'enseignement,
✓ GitHub : dans lequel le wiki est souvent utilisé comme documentation ou moyen d'organisation
entre collaborateurs,
 ✓ Tous les sites qui sont basés sur un moteur wiki, comme par exemple MediaWiki, le logiciel
open-source à la base de Wikipédia et également de EduTech Wiki.
Logiciels de traitement de texte : plusieurs logiciels de traitement de texte, surtout dans les versions
en ligne et collaboratives, permettent de retracer l'historique des versions : OFFICE ,GOOGLE DOCS..
CVS (Concurrent Versioning System) : fonctionne sur un principe centralisé, de même que son
successeur SVN (Subversion).
Logiciels de SCM décentralisés : sont apparus plus récemment : Mercurial et surtout Git, que nous
utiliserons dans la suite de ce chapitre. Ce sont également des logiciels libres.
TFS (Team Foundation Server) de Microsft : TFS est une solution payante qui fonctionne de manière
centralisée.

3. Présentation de GIT
a. C’est quoi git?
Git est un système de contrôle de version distribué qui permet de suivre les changements apportés à un
ensemble de fichiers au fil du temps. Il est largement utilisé dans le développement de logiciels pour
faciliter la collaboration entre les membres de l'équipe et le suivi des modifications apportées au code
source.
Git rassemble dans un dépôt (repository ou repo) l'ensemble des données associées au projet. Il
fonctionne de manière décentralisée: tout dépôt Git contient l’intégralité des données (code source,
historique, versions, etc).
Chaque participant au projet travaille à son rythme sur son dépôt local. Il existe donc autant de dépôts
que de participants.
Git offre des mécanismes permettant de synchroniser les modifications entre tous les dépôts.

b. Les dépôts avec git :

Version : contenu du projet à un moment de son cycle de vie.
Dépôt(repository) : l’historique du projet, contenant toutes ses versions.
Branche (branch) = variante d’un projet.
Un dépôt Git correspond physiquement à un ensemble de fichiers rassemblés dans un répertoire .git.
Sauf cas particulier, il n'est pas nécessaire d'intervenir manuellement dans ce répertoire.
Lorsqu'on travaille avec Git, il est essentiel de faire la distinction entre trois zones :
Le répertoire de travail (working directory) : correspond aux fichiers actuellement sauvegardés
localement.
L'index ou staging area est un espace de transit.
HEAD : correspond aux derniers fichiers ajoutés au dépôt.

c. Principales commandes git

git init : crée un nouveau dépôt vide à l'emplacement courant.
git status : affiche les différences entre le répertoire de travail, l'index et HEAD.
git add : ajoute des fichiers depuis le répertoire de travail vers l'index.
git commit : ajoute des fichiers depuis l'index vers HEAD.
git clone : clone un dépôt existant local ou distant.
git pull : récupère des modifications depuis un dépôt distant vers HEAD.
git push : publie des modifications depuis HEAD vers un dépôt distant.

4. Présentation de Gitlab
GitLab est une plateforme de gestion de code source collaboratif basée sur Git. Elle permet aux
développeurs de travailler ensemble sur des projets, de partager du code, de collaborer sur des
problèmes, de gérer des versions et de suivre les modifications de code. GitLab propose également des
fonctionnalités de CI/CD (Intégration continue / Livraison continue) pour automatiser les processus de
construction, de test et de déploiement.
GitLab est disponible en deux versions : la version communautaire gratuite et open source, et la version
entreprise qui propose des fonctionnalités avancées, une assistance technique et des options
d'hébergement. GitLab peut être auto-hébergé ou utilisé en tant que service cloud.
GitLab est populaire auprès des équipes de développement en raison de sa facilité d'utilisation, de son
interface utilisateur intuitive et de sa capacité à gérer efficacement des projets de toute taille.

5. Comparaison Git vs Gitlab

Git et GitLab sont deux outils de gestion de code source qui ont des similitudes, mais aussi des
différences importantes. Voici une comparaison entre les deux :

a. Fonctionnalités :
Git est un système de contrôle de version décentralisé qui permet aux développeurs de gérer et de suivre
les modifications du code source au fil du temps. Il est principalement utilisé pour la gestion de versions
de code source.
GitLab, quant à lui, est une plateforme de gestion de code source basée sur le web qui offre des
fonctionnalités supplémentaires en plus de Git. Ces fonctionnalités incluent la gestion de projet, la
gestion des tickets, l'intégration continue, le déploiement, la collaboration, la révision de code, etc.

b. Convivialité :
Git est un outil en ligne de commande qui peut être difficile à utiliser pour les débutants ou ceux qui ne
sont pas à l'aise avec les commandes en ligne de commande. Cependant, il existe de nombreuses
interfaces graphiques utilisateur (GUI) pour Git qui simplifient l'interaction avec Git.
GitLab, en revanche, est une plateforme basée sur le web qui peut être utilisée via une interface
graphique utilisateur intuitive. Cela facilite grandement la collaboration entre les membres de l'équipe
et la gestion des projets.

c. Hébergement :
Git est une solution de gestion de code source qui peut être utilisée sur une variété de plates-formes
d'hébergement telles que GitHub, Bitbucket, etc. Il est également possible de créer un dépôt Git sur votre
propre serveur.
GitLab, quant à lui, est une plateforme de gestion de code source autonome qui peut être installée sur
votre propre serveur ou hébergée sur le cloud par GitLab.

d. Coût :
Git est un logiciel libre et open source qui est gratuit à utiliser.
GitLab propose une version open source gratuite et une version entreprise payante avec des
fonctionnalités plus avancées et un support technique.
En résumé, Git est principalement un système de contrôle de version de code source, tandis que GitLab
est une plateforme plus complète qui offre des fonctionnalités de gestion de projet, de collaboration et
de révision de code. Git est plus facile à utiliser pour les développeurs expérimentés, tandis que GitLab
offre une interface utilisateur plus conviviale pour les débutants.

6. Création d’un compte Gitlab

Voici les étapes pour créer un compte GitLab :
1. Accédez à la page d'accueil de GitLab : https://gitlab.com/
2. Cliquez sur le bouton "S'inscrire" dans le coin supérieur droit de la page.

3. Sur la page d'inscription, vous pouvez choisir de vous inscrire avec une adresse e-mail ou avec
un compte Google, GitHub ou Twitter.
 4. Si vous choisissez de vous inscrire avec une adresse e-mail, remplissez le formulaire
d'inscription en indiquant votre nom, votre adresse e-mail et un mot de passe.
5. Si vous choisissez de vous inscrire avec un compte Google, GitHub ou Twitter, suivez les
instructions pour vous connecter à votre compte et autoriser l'accès à GitLab.
6. Après avoir rempli les informations nécessaires, cliquez sur le bouton "S'inscrire" en bas de la
page.
7. Vous devrez ensuite confirmer votre adresse e-mail en cliquant sur le lien de confirmation qui
vous sera envoyé par e-mail.
8. Une fois que vous avez confirmé votre adresse e-mail, vous pouvez vous connecter à votre
compte GitLab et commencer à utiliser la plateforme pour gérer vos projets de développement.

7. Présentation des fonctionnalités de Gitlab

GitLab est une plateforme de gestion de code source, qui propose de nombreuses fonctionnalités pour
faciliter la collaboration entre les développeurs. Voici quelques-unes de ses principales fonctionnalités
:
1. Gestion de profil : GitLab permet aux utilisateurs de gérer leur profil personnel, y compris leur
nom, leur adresse e-mail, leur photo de profil et leurs préférences de notification.
2. Tableau de bord : Le tableau de bord de GitLab fournit un aperçu rapide des activités les plus
récentes dans les projets, ainsi que des notifications et des rappels pour les tâches en attente.
3. Repository : GitLab permet de créer et de gérer des référentiels de code source Git, qui peuvent
être publics ou privés. Les utilisateurs peuvent collaborer sur les référentiels, créer des branches,
des étiquettes, des commits, et plus encore.
4. Pull request : Les pull requests sont une fonctionnalité clé de GitLab, qui permettent aux
utilisateurs de proposer des modifications à un référentiel et de demander une revue avant de
les fusionner. Les pull requests facilitent la collaboration entre les développeurs et permettent
de maintenir un code de qualité.
5. Intégration continue : GitLab propose des fonctionnalités d'intégration continue pour
automatiser les tests et les déploiements à chaque fois que du code est poussé vers le référentiel.
 6. Wiki : GitLab offre la possibilité de créer des wikis pour stocker la documentation et les
informations de projet.
7. Issue tracking : GitLab propose un système de suivi des problèmes pour suivre les bugs, les
demandes de fonctionnalités et les autres problèmes liés au projet.
8. Analytics : GitLab fournit des outils d'analyse pour suivre les performances du projet, comme
le temps moyen de résolution des problèmes, le temps moyen entre les demandes de fusion, etc.
9. CI/CD : GitLab offre des fonctionnalités de CI/CD (Continuous Integration/Continuous
Deployment) pour automatiser les tests et les déploiements à chaque fois que du code est poussé
vers le référentiel.
10. Code review : GitLab propose des outils pour faciliter les revues de code, comme la possibilité
de commenter les lignes de code spécifiques et de discuter des changements proposés.
Ces fonctionnalités font de GitLab une plateforme de développement de choix pour les équipes de
développement cherchant à collaborer efficacement sur des projets de logiciels.

8. Manipulation des dépôts avec Gitlab

Voici les étapes pour la manipulation des dépôts avec Gitlab :
1. Accédez à votre compte Gitlab et cliquez sur le bouton "Créer un projet" pour créer un nouveau
dépôt.
2. Donnez un nom et une description à votre dépôt, choisissez la visibilité du projet et ajoutez des
membres si nécessaire.
3. Si vous avez déjà un dépôt local sur votre ordinateur, utilisez la commande "git remote add
origin url_du_depot" pour lier votre dépôt local au dépôt distant Gitlab.
4. Si vous n'avez pas encore de dépôt local, utilisez la commande "git clone url_du_depot" pour
cloner le dépôt distant sur votre ordinateur.
5. Utilisez Git bash ou un client Git GUI pour effectuer des modifications dans votre dépôt local.
6. Utilisez la commande "git add nom_du_fichier_modifie" pour ajouter les modifications à
l'index.
7. Utilisez la commande "git commit -m 'message_de_commit'" pour créer un nouveau commit
avec les modifications ajoutées à l'index.
8. Utilisez la commande "git push origin nom_de_la_branche" pour pousser le nouveau commit
vers le dépôt distant sur Gitlab.
9. Si vous travaillez avec des branches, utilisez la commande "git branch nom_de_la_branche"
pour créer une nouvelle branche et "git checkout nom_de_la_branche" pour basculer sur la
nouvelle branche.
10. Utilisez la commande "git merge nom_de_la_branche" pour fusionner les modifications
apportées dans la nouvelle branche avec la branche principale.
11. Si des conflits de fusion surviennent, résolvez-les manuellement en modifiant le fichier en
conflit, en enregistrant les modifications, en ajoutant le fichier modifié à l'index et en créant un
nouveau commit pour la résolution du conflit.
12. Utilisez la commande "git pull origin nom_de_la_branche" pour récupérer les dernières
modifications apportées au dépôt distant et fusionner ces modifications avec votre dépôt local.
13. Répétez les étapes 5 à 12 jusqu'à ce que les modifications soient finalisées et le code prêt pour
le déploiement.

9. Installation de Git
Voici les étapes pour installer Git :
1. Rendez-vous sur le site officiel de Git : https://git-scm.com/downloads
2. Choisissez le système d'exploitation sur lequel vous souhaitez installer Git (Windows, macOS,
Linux, etc.) en cliquant sur le bouton correspondant.
3. Téléchargez le programme d'installation pour le système d'exploitation choisi.
 4. Double-cliquez sur le fichier d'installation pour lancer le processus d'installation.
5. Suivez les instructions à l'écran pour installer Git en sélectionnant les options par défaut ou en
choisissant des options personnalisées selon vos besoins.
6. Si vous installez Git sur Windows, sélectionnez l'option pour ajouter Git au chemin système
pour pouvoir utiliser Git à partir de la ligne de commande.
7. Une fois l'installation terminée, ouvrez la ligne de commande (Git bash pour Windows,
Terminal pour macOS ou Linux) et entrez la commande "git --version" pour vérifier que Git est
bien installé et fonctionne correctement.
8. Une fois que Git est installé, vous pouvez commencer à l'utiliser pour le contrôle de version et
la gestion de code source.

10. Manipulation de Git user interface (GUI)

La manipulation de Git en interface graphique utilisateur (GUI) peut se faire via divers outils. Voici les
étapes pour utiliser l'outil Git GUI :
1. Assurez-vous d'avoir installé Git sur votre ordinateur.
2. Ouvrez l'outil Git GUI. Sur Windows, cela peut se faire en cherchant "Git GUI" dans le menu
Démarrer. Sur Mac ou Linux, ouvrez Terminal et tapez "git gui".
3. Sélectionnez le dossier de votre projet en cliquant sur "Open Existing Repository".
4. Vous verrez une liste de fichiers dans votre projet. Cochez les fichiers que vous souhaitez inclure
dans votre prochaine validation (commit).
5. Ajoutez un message de commit qui décrit les modifications apportées.
6. Cliquez sur "Commit" pour enregistrer les modifications dans la branche actuelle.
7. Vous pouvez également créer une nouvelle branche en cliquant sur "Branch" dans la barre de
menu et en entrant un nom de branche.
8. Pour fusionner des branches, cliquez sur "Merge" dans la barre de menu et sélectionnez les
branches que vous souhaitez fusionner.
9. Si vous rencontrez des conflits de fusion, Git GUI vous permettra de résoudre les conflits à
l'aide de son outil de fusion visuel.
10. Une fois que vous avez terminé, vous pouvez pousser (push) vos modifications vers votre dépôt
distant en cliquant sur "Push" dans la barre de menu.
Notez que l'utilisation de l'interface graphique peut varier en fonction de l'outil que vous utilisez.

11. Manipulation des commandes de base de Git (Git bash)

La manipulation des commandes de base de Git via Git bash peut se faire via les étapes suivantes :
1. Assurez-vous d'avoir installé Git sur votre ordinateur.
2. Ouvrez Git bash. Sur Windows, cela peut se faire en cherchant "Git bash" dans le menu
Démarrer. Sur Mac ou Linux, ouvrez Terminal et tapez "git" pour vérifier que Git est installé.
3. Allez dans le dossier de votre projet en utilisant la commande "cd". Par exemple, "cd
Documents/mon_projet" pour aller dans le dossier "mon_projet" dans le dossier "Documents".
4. Utilisez la commande "git init" pour initialiser un dépôt Git dans le dossier de votre projet. Cela
crée un dossier caché ".git" qui stocke les informations de suivi de version.
5. Utilisez la commande "git add" pour ajouter des fichiers à l'index Git. Par exemple, "git add
index.html" pour ajouter le fichier "index.html" à l'index.
6. Utilisez la commande "git commit" pour enregistrer les modifications dans l'historique Git. Par
exemple, "git commit -m 'Ajout de la page d'accueil'" pour enregistrer les modifications avec
un message de commit explicatif.
7. Utilisez la commande "git status" pour vérifier l'état des fichiers dans votre dépôt Git. Cette
commande vous indiquera quels fichiers ont été modifiés, ajoutés ou supprimés depuis le dernier
commit.
 8. Utilisez la commande "git log" pour afficher l'historique des commits dans votre dépôt Git.
Cette commande vous montrera les messages de commit, les auteurs et les horodatages pour
chaque commit.
9. Utilisez la commande "git branch" pour afficher les branches dans votre dépôt Git. Cette
commande vous montrera les noms des branches et la branche actuelle.
10. Utilisez la commande "git checkout" pour basculer entre les branches. Par exemple, "git
checkout ma_branche" pour passer à la branche "ma_branche".
11. Utilisez la commande "git merge" pour fusionner des branches. Par exemple, "git merge
ma_branche" pour fusionner la branche "ma_branche" dans la branche actuelle.
12. Utilisez la commande "git push" pour pousser vos modifications vers votre dépôt distant. Par
exemple, "git push origin ma_branche" pour pousser la branche "ma_branche" vers le dépôt
distant appelé "origin".
Notez que la manipulation des commandes de base de Git peut varier en fonction de votre projet et de
votre flux de travail.

12. Notion de branches avec Git

Une branche git est simplement une copie d'un ensemble de fichiers et de l'historique des modifications
de ces fichiers dans un dépôt Git. Les branches permettent à plusieurs personnes de travailler sur des
fonctionnalités distinctes d'un même projet en parallèle, sans affecter le code de la branche principale.
Par exemple, imaginons que vous travaillez sur un projet de développement de logiciels avec votre
équipe. Vous pouvez créer une branche pour travailler sur une nouvelle fonctionnalité sans affecter le
code de la branche principale. Vous pouvez nommer cette branche "nouvelle-fonctionnalité"

13. Création et manipulation des branches avec Git

Voici les principales commandes pour créer et manipuler des branches avec Git :
1. Créer une nouvelle branche :
git branch nom-de-la-branche
Cette commande crée une nouvelle branche nommée "nom-de-la-branche" à partir de l'état actuel de la
branche courante.
2. Basculer sur une branche existante :
git checkout nom-de-la-branche
Cette commande bascule l'état de Git sur la branche "nom-de-la-branche".
3. Créer et basculer sur une nouvelle branche :
git checkout -b nom-de-la-branche
Cette commande combine les deux étapes précédentes en une seule. Elle crée une nouvelle branche
nommée "nom-de-la-branche" à partir de l'état actuel de la branche courante, puis bascule sur cette
nouvelle branche.
4. Voir la liste des branches existantes :
git branch
Cette commande affiche une liste de toutes les branches existantes et indique la branche courante avec
une étoile (*).
5. Supprimer une branche :
git branch -d nom-de-la-branche
Cette commande supprime la branche "nom-de-la-branche". Attention, cette commande ne peut être
exécutée que si vous n'êtes pas sur la branche que vous souhaitez supprimer.

14. Gestion des conflits de fusion avec Git

Lorsque vous fusionnez deux branches avec Git, il peut arriver que des conflits surviennent. Les conflits
de fusion se produisent lorsque Git n'est pas en mesure de fusionner automatiquement les modifications
apportées à un même fichier sur différentes branches. Dans ce cas, Git demande à l'utilisateur de
résoudre manuellement les conflits. Voici les étapes à suivre pour gérer les conflits de fusion avec Git :
1. Faites une sauvegarde de votre travail actuel en cas de besoin.
2. Utilisez la commande 'git merge' pour fusionner la branche :
git merge nom-de-la-branche
3. Si des conflits de fusion sont détectés, Git vous avertira et vous indiquera quels fichiers sont
concernés.
4. Ouvrez les fichiers concernés dans un éditeur de texte. Vous verrez les différences entre les
versions du fichier sur les deux branches, avec des marqueurs indiquant les sections
conflictuelles.
5. Résolvez les conflits en modifiant les fichiers pour inclure les modifications nécessaires. Vous
pouvez garder les deux versions du code en utilisant la syntaxe suivante :

<<<<<<< HEAD
Code de la branche courante
=======
Code de la branche fusionnée
>>>>>>> nom-de-la-branche

Vous pouvez également choisir de supprimer une des deux versions et de garder seulement celle qui
vous convient.
6. Après avoir résolu tous les conflits, utilisez la commande 'git add' pour marquer les fichiers
comme étant résolus :
git add nom-du-fichier
Vous pouvez aussi utiliser git 'add .' pour ajouter tous les fichiers modifiés.
7. Finalement, utilisez la commande 'git commit' pour valider la fusion :
git commit -m "Message de validation"
Il est important de noter que la résolution des conflits peut être complexe, en particulier si plusieurs
personnes ont travaillé sur les mêmes fichiers. Il est donc recommandé de travailler avec des branches
distinctes et de les fusionner régulièrement pour éviter les conflits majeurs.
De plus la création et la manipulation de branches avec Git peuvent être très puissantes, mais aussi
potentiellement risquées. Il est recommandé de créer des branches pour tester des fonctionnalités
expérimentales, mais aussi de les fusionner avec précaution pour éviter des conflits avec les autres
branches existantes.
CHAPITRE VIII : Manipuler l’outil de mesure de la qualité du
code (SonarQube)
1. Notions des métriques de la qualité du code
Les métriques de la qualité du code sont des indicateurs qui permettent d'évaluer la qualité du code d'un
projet. Les métriques sont utilisées pour mesurer différentes caractéristiques du code, telles que la
maintenabilité, la fiabilité, la sécurité, la performance et l'efficacité.
Voici quelques-unes des métriques les plus courantes utilisées pour évaluer la qualité du code :
1. La couverture de code : mesure le pourcentage de lignes de code couvertes par des tests
automatisés.
2. La complexité cyclomatique : mesure la complexité du code en comptant le nombre de chemins
d'exécution possibles dans une fonction.
3. La taille du code : mesure la quantité de code écrite pour un projet.
4. La duplication de code : mesure la quantité de code en double dans le projet.
5. Les violations de règles : détecte les violations des règles de codage et fournit des avertissements
pour aider à éviter les problèmes de qualité.
6. La lisibilité du code : mesure la lisibilité du code pour faciliter la maintenance du code.
7. Les bugs : détecte les erreurs dans le code et propose des suggestions pour les corriger.
8. Les vulnérabilités de sécurité : détecte les vulnérabilités de sécurité potentielles dans le code et
fournit des suggestions pour les corriger.
Ces métriques aident les développeurs à comprendre la qualité de leur code, à identifier les problèmes
de qualité et à prendre des mesures pour améliorer la qualité du code. Les développeurs peuvent utiliser
ces informations pour apporter des améliorations à leur code et pour maintenir une base de code solide
et de qualité.

2. Présentation des outils existants de mesure de la qualité du code

Il existe plusieurs outils de mesure de la qualité du code disponibles sur le marché. Voici une liste non
exhaustive de certains des outils les plus populaires :
1. PMD : PMD est un outil open source pour l'analyse statique du code Java qui détecte les
problèmes de qualité du code tels que les bugs, les violations de règles de codage, les
duplications de code et la complexité.
2. Checkstyle : Checkstyle est un outil open source pour l'analyse statique du code Java qui vérifie
que le code source respecte les règles de codage définies.
3. FindBugs : FindBugs est un outil open source pour l'analyse statique du code Java qui détecte
les bugs de programmation courants tels que les fuites de mémoire, les variables inutilisées et
les boucles infinies.
4. ESLint : ESLint est un outil open source pour l'analyse statique du code JavaScript qui détecte
les erreurs de programmation courantes et fournit des suggestions pour les corriger.
5. ReSharper : ReSharper est un outil commercial pour l'analyse statique du code .NET qui fournit
des suggestions pour améliorer la qualité du code, détecte les erreurs de programmation
courantes et fournit des fonctionnalités pour refactoriser le code.
Ces outils d'analyse statique du code permettent de détecter les problèmes de qualité du code tels que
les bugs, les violations de règles de codage, les duplications de code et la complexité. En utilisant ces
outils, les développeurs peuvent améliorer la qualité du code de leur projet et réduire les coûts liés à la
maintenance du code.
 3. Présentation de SonarQube
SonarQube est une plateforme open source de gestion de la qualité du code, développée par
SonarSource. Elle fournit une analyse statique du code source pour détecter les problèmes de qualité, de
sécurité et de conformité. SonarQube permet de mesurer la qualité du code en analysant des indicateurs
tels que la couverture de code, la complexité, la duplication de code, les violations de règles et les bugs.
SonarQube est compatible avec de nombreux langages de programmation, tels que Java, C++, C#,
JavaScript, PHP, Python, Ruby et bien d'autres encore. Elle est facilement extensible grâce à une large
bibliothèque de plugins, qui permettent d'ajouter des fonctionnalités supplémentaires pour répondre aux
besoins spécifiques d'un projet.
Les principales fonctionnalités de SonarQube sont :
1. L'analyse statique du code : SonarQube analyse le code source pour détecter les problèmes de
qualité tels que les bugs, les violations de règles, les duplications de code et la complexité.
2. Les mesures de qualité : SonarQube fournit des mesures de qualité du code pour aider les
développeurs à comprendre la qualité de leur code et à identifier les problèmes de qualité.
3. La gestion des bugs : SonarQube détecte les erreurs dans le code et propose des suggestions
pour les corriger.
4. La gestion des vulnérabilités de sécurité : SonarQube détecte les vulnérabilités de sécurité
potentielles dans le code et fournit des suggestions pour les corriger.
5. Les tableaux de bord et les rapports : SonarQube fournit des tableaux de bord et des rapports
pour visualiser les mesures de qualité du code et suivre les progrès dans l'amélioration de la
qualité du code.
En somme, SonarQube est un outil puissant pour améliorer la qualité du code d'un projet et faciliter sa
maintenance. Il permet aux développeurs de comprendre la qualité de leur code, de détecter les
problèmes de qualité et de prendre des mesures pour améliorer la qualité du code.

4. Installation de SonarQube
Voici les étapes pour installer SonarQube sur un système Windows :
1. Télécharger la dernière version de SonarQube à partir du site officiel de SonarQube.
2. Extraire l'archive téléchargée dans un répertoire sur votre système.
3. Télécharger et installer Java JDK si ce n'est pas déjà fait. Vous pouvez vérifier si Java est installé
en exécutant la commande 'java –version' dans l'invite de commande. Si Java n'est pas installé,
téléchargez et installez Java JDK à partir du site officiel de Java.
4. Modifier le fichier 'sonar.properties' situé dans le répertoire 'conf' de SonarQube pour
configurer les paramètres de base de SonarQube, tels que l'adresse IP et le port de l'application,
les informations de connexion à la base de données, etc.
5. Exécuter le script 'StartSonar.bat' situé dans le répertoire 'bin' de SonarQube pour lancer
l'application SonarQube.
Une fois que l'application est lancée, vous pouvez y accéder en utilisant votre navigateur web préféré en
entrant l'adresse IP et le port de l'application que vous avez configurés dans le fichier 'sonar.properties'.
Il convient de noter que ces étapes sont générales et peuvent varier en fonction de la version de
SonarQube et du système d'exploitation utilisé. Il est donc important de se référer à la documentation
officielle de SonarQube pour des instructions d'installation détaillées et précises.

5. Intégration de SonarQubeavec les outils ALM

SonarQube peut être intégré avec plusieurs outils ALM (Application Life Cycle Management) pour
faciliter l'analyse de la qualité du code tout au long du cycle de vie du logiciel. Voici quelques-unes des
intégrations les plus courantes :
 1. Intégration avec les IDE : SonarQube peut être intégré avec de nombreux environnements de
développement intégrés (IDE), tels que Eclipse, IntelliJ IDEA et Visual Studio. Cette intégration
permet aux développeurs de recevoir des commentaires instantanés sur la qualité du code
pendant le développement.
2. Intégration avec les outils de gestion de versions : SonarQube peut être intégré avec des outils
de gestion de versions tels que Git, SVN, TFS, Mercurial, etc. Cette intégration permet de suivre
les métriques de qualité du code à mesure que le code est modifié dans le référentiel.
3. Intégration avec les outils de build : SonarQube peut être intégré avec des outils de build tels
que Maven, Ant, Gradle, MSBuild, etc. Cette intégration permet de lancer une analyse de qualité
du code lors de la construction du projet et de fournir des commentaires sur la qualité du code.
4. Intégration avec les outils de suivi des bugs : SonarQube peut être intégré avec des outils de
suivi des bugs tels que JIRA, Redmine, Bugzilla, etc. Cette intégration permet de suivre les
métriques de qualité du code associées à des problèmes spécifiques et de prendre des mesures
pour résoudre les problèmes de qualité.
5. Intégration avec les outils de gestion de projet : SonarQube peut être intégré avec des outils de
gestion de projet tels que Jenkins, Bamboo, TeamCity, etc. Cette intégration permet de
déclencher des analyses de qualité du code à partir de ces outils et de fournir des commentaires
sur la qualité du code dans les rapports de projet.
En somme, l'intégration de SonarQube avec les outils ALM permet de suivre la qualité du code à travers
tout le cycle de vie du logiciel et de prendre des mesures pour améliorer la qualité du code.

6. Configuration de SonarQube :
SonarQube est une plateforme de gestion de la qualité du code qui permet aux développeurs de surveiller
et d'améliorer la qualité de leur code. Pour configurer SonarQube, voici les étapes à suivre :
1. Installation de SonarQube : Tout d'abord, vous devez télécharger SonarQube et l'installer sur
votre ordinateur ou votre serveur. La documentation officielle de SonarQube fournit des
instructions détaillées pour l'installation.
2. Configuration de la base de données : SonarQube nécessite une base de données pour stocker
les données d'analyse de code. Vous devez configurer une base de données compatible (par
exemple, PostgreSQL, MySQL, Oracle, SQL Server) et créer un utilisateur avec les
autorisations appropriées.
3. Configuration du fichier de propriétés : Vous devez configurer les propriétés de SonarQube en
modifiant le fichier sonar.properties, qui est généralement situé dans le dossier conf/ à
l'emplacement d'installation de SonarQube. Les propriétés importantes à configurer sont :

sonar.jdbc.url : l'URL de connexion à la base de données

sonar.jdbc.username : le nom d'utilisateur de la base de données
sonar.jdbc.password : le mot de passe de la base de données
sonar.web.host : l'adresse IP ou le nom d'hôte du serveur SonarQube
sonar.web.port : le port sur lequel SonarQube doit écouter les connexions

4. Configuration des projets : Vous devez créer des projets dans SonarQube et configurer les
paramètres d'analyse pour chaque projet. Les paramètres importants à configurer sont :

sonar.projectKey : une clé unique pour identifier le projet

sonar.projectName : le nom du projet
sonar.sources : le chemin vers le code source à analyser
 sonar.exclusions : les fichiers ou les répertoires à exclure de l'analyse

5. Lancement d'une analyse de code : Une fois que tout est configuré, vous pouvez lancer une
analyse de code en utilisant l'un des nombreux plugins de SonarQube pour votre environnement
de développement. Les plugins sont disponibles pour des environnements tels que IntelliJ
IDEA, Eclipse, Visual Studio, Jenkins, Maven, Gradle, etc.
En suivant ces étapes, vous pouvez configurer SonarQube pour votre environnement de développement
et commencer à surveiller et à améliorer la qualité de votre code.

Analyse de code source à travers la génération de rapports sur :

SonarQube est une plateforme d'analyse statique de code open source qui permet de générer des rapports
détaillés sur la qualité du code source d'une application. Elle est capable de mesurer un grand nombre
de métriques, parmi lesquelles :
1. Identification des duplications de code : SonarQube détecte automatiquement les duplications
de code et génère des rapports détaillés sur les fichiers et les lignes de code concernées. Elle
permet également d'identifier les causes sous-jacentes des duplications et propose des solutions
pour les éviter.
2. Mesure du niveau de documentation : SonarQube mesure le niveau de documentation du code
source en analysant les commentaires et la documentation inline. Elle permet de générer des
rapports détaillés sur le pourcentage de code documenté, les fichiers les plus documentés et les
moins documentés, etc.
3. Respect des règles de programmation : SonarQube permet de configurer des règles de qualité
de code et de détecter les violations automatiquement. Elle propose également des outils pour
aider les développeurs à corriger les violations rapidement, comme des commentaires, des liens
vers des articles de documentation, etc.
4. Détection des bugs potentiels : SonarQube utilise des règles d'analyse statique de code pour
détecter les bugs potentiels dans le code source. Elle génère des rapports détaillés sur les erreurs
détectées, y compris les fichiers, les lignes et les types d'erreurs.
5. Evaluation de la couverture de code par les tests unitaires : SonarQube intègre des outils pour
évaluer la couverture de code par les tests unitaires. Elle permet de mesurer la couverture de
code pour chaque fichier et chaque classe, ainsi que pour l'ensemble de l'application.
6. Analyse du design et de l'architecture d'une application : SonarQube propose des outils pour
analyser le design et l'architecture d'une application. Elle permet de détecter les dépendances
cycliques, les violations des principes SOLID, les problèmes d'encapsulation, etc. Elle génère
des rapports détaillés sur les problèmes détectés, ainsi que des suggestions pour les résoudre.
En résumé, SonarQube est une plateforme d'analyse statique de code qui permet de générer des rapports
détaillés sur la qualité du code source d'une application. Elle est capable de mesurer un grand nombre
de métriques, notamment l'identification des duplications de code, la mesure du niveau de
documentation, le respect des règles de programmation, la détection des bugs potentiels, l'évaluation de
la couverture de code par les tests unitaires et l'analyse du design et de l'architecture d'une application.
Ces rapports peuvent aider les développeurs à améliorer la qualité de leur code source et à maintenir une
base de code saine et de qualité.
Mettre en œuvre les outils de la chaîne du DevOps
CHAPITRE IX : Introduire la chaîne DevOps
1. Introduction aux concepts DevOps
a. Définition
DevOps est une méthodologie de développement de logiciels qui vise à améliorer l'efficacité et la qualité
des logiciels en permettant une livraison plus rapide, plus fiable et plus sécurisée. DevOps repose sur la
collaboration étroite entre les équipes de développement et d'opérations, l'automatisation des processus
et l'amélioration continue.

Dans DevOps, les points suivants sont des étapes importantes du cycle de vie du logiciel :
Code : Cette étape implique la création du code source pour une application ou un service. Les
développeurs écrivent et modifient le code en utilisant un langage de programmation spécifique pour
répondre aux besoins fonctionnels et techniques de l'application.
Build : Une fois le code écrit, il doit être compilé et construit dans un format exécutable qui peut être
utilisé pour l'exécution. La construction peut également inclure la génération d'images Docker ou la
création de packages d'installation pour une installation facile.
Test : Avant la mise en production, il est important de tester le logiciel pour s'assurer qu'il fonctionne
correctement. Les tests peuvent inclure des tests unitaires, des tests d'intégration, des tests de validation
fonctionnelle et des tests de performance pour vérifier que l'application répond aux exigences du client.
Release : Une fois que le logiciel a été testé et que toutes les erreurs ont été corrigées, il est prêt à être
mis en production. La mise en production peut impliquer la publication d'une nouvelle version de
l'application ou la mise à jour d'une version existante.
Deploy : La mise en production implique le déploiement du code sur les serveurs qui exécutent
l'application. Le déploiement peut être effectué manuellement ou de manière automatisée, en utilisant
des outils de déploiement tels que Kubernetes ou Terraform.
Operate : Une fois que l'application est en production, il est important de surveiller son état et de prendre
des mesures pour garantir son bon fonctionnement. Les tâches d'exploitation comprennent la gestion des
incidents, la gestion de la capacité, la gestion des changements et la gestion de la sécurité.
Monitor : La surveillance est une partie importante de l'exploitation de l'application en production. La
surveillance peut inclure la surveillance des performances, la surveillance des erreurs, la surveillance
des journaux et la surveillance des indicateurs de performance clés (KPI).
Plan : La planification est importante pour gérer efficacement le cycle de vie du logiciel. La planification
comprend la planification des sprints, la planification de la capacité, la planification de la sécurité et la
planification de la continuité des activités (PCA).

b. Avantages
Les avantages de DevOps sont nombreux. Voici une liste non exhaustive des avantages les plus courants
1. Une livraison plus rapide : En automatisant les processus de déploiement et de test, DevOps
permet de livrer les logiciels plus rapidement, ce qui réduit le time-to-market.
2. Une meilleure qualité : En intégrant les tests et la surveillance tout au long du cycle de vie du
logiciel, DevOps permet de détecter les problèmes plus tôt, ce qui améliore la qualité du logiciel.
3. Une meilleure collaboration : En réunissant les équipes de développement et d'opérations,
DevOps favorise la collaboration et la communication, ce qui permet de résoudre les problèmes
plus rapidement et efficacement.
4. Une plus grande efficacité : En automatisant les processus et en réduisant les tâches manuelles,
DevOps permet de réduire les coûts et d'augmenter l'efficacité des équipes.
5. Une sécurité renforcée : En incluant la sécurité dès le début du processus de développement,
DevOps permet de réduire les risques de sécurité.
6. Une amélioration continue : En utilisant des outils de surveillance et d'analyse, DevOps permet
de mesurer les performances du logiciel en production et d'apporter des améliorations continues.
7. Une flexibilité accrue : En permettant des déploiements plus fréquents et des mises à jour plus
rapides, DevOps permet aux organisations de s'adapter plus rapidement aux changements du
marché et des besoins des utilisateurs.
En somme, les avantages de DevOps sont nombreux et peuvent avoir un impact significatif sur la qualité,
la vitesse, la sécurité et la rentabilité du développement de logiciels.

c. Outils
Les outils DevOps sont nombreux et couvrent différents aspects du développement de logiciels. Voici
une liste non exhaustive des outils DevOps les plus couramment utilisés :
1. Gestion de code source : Git, Subversion, Mercurial
2. Automatisation de la construction : Jenkins, Travis CI, CircleCI
3. Automatisation des tests : Selenium, JUnit, Cucumber
4. Configuration et déploiement d'infrastructure : Puppet, Chef, Ansible
5. Automatisation du déploiement : Docker, Kubernetes
6. Monitoring et logging : Nagios, Zabbix, ELK Stack
7. Gestion de la collaboration et des projets : Jira, Trello, Asana
Ces outils permettent de couvrir l'ensemble du cycle de vie du logiciel, de la gestion du code source à la
mise en production en passant par les tests, la configuration et le déploiement d'infrastructure, le
monitoring et la gestion de projet. Ils sont essentiels pour mettre en place une approche DevOps efficace
et automatisée, et pour permettre aux équipes de développement et d'opérations de travailler ensemble
de manière transparente et coordonnée.

2. Lien en l'agilité et devops

L'agilité et DevOps sont deux approches complémentaires qui partagent des objectifs communs en
matière de développement de logiciels.
L'approche agile se concentre sur la collaboration et l'itération rapide pour produire des logiciels de
haute qualité qui répondent aux besoins des utilisateurs. Elle met l'accent sur l'implication des parties
prenantes, la communication et la flexibilité.
DevOps, quant à lui, se concentre sur l'automatisation et la collaboration entre les équipes de
développement et d'opérations pour livrer des logiciels plus rapidement, plus fréquemment et de manière
plus fiable. Elle met l'accent sur la livraison continue, la surveillance et l'optimisation des performances.
Les deux approches se complètent pour permettre aux équipes de développement de produire des
logiciels de haute qualité en utilisant des processus automatisés et des méthodes agiles de gestion de
projet. La collaboration entre les équipes de développement et d'opérations est essentielle pour garantir
une livraison continue, une qualité élevée et une rapidité d'exécution. Les équipes peuvent ainsi s'adapter
plus rapidement aux changements du marché et aux besoins des utilisateurs.
En somme, l'agilité et DevOps sont deux approches complémentaires qui permettent de produire des
logiciels de haute qualité, en utilisant des méthodes flexibles, des processus automatisés et une
collaboration efficace entre les équipes de développement et d'opérations.

3. Caractéristiques de la méthodologie DevOps (CALMS) :

La méthodologie DevOps repose sur un ensemble de pratiques, de processus et d'outils qui visent à
améliorer la collaboration et la communication entre les équipes de développement et d'opérations.
CALMS est un acronyme qui représente les cinq caractéristiques clés de la méthodologie DevOps :
1. Culture : La culture est l'un des aspects les plus importants de DevOps. Elle implique une
mentalité de collaboration, de responsabilité partagée et de confiance entre les équipes de
développement et d'opérations. La culture DevOps encourage également l'innovation, la prise
de risque et l'apprentissage continu.
2. Automatisation : L'automatisation est essentielle pour permettre une livraison rapide, continue
et fiable de logiciels. Elle concerne l'ensemble du processus de développement, depuis la
compilation et les tests jusqu'à la mise en production.
3. Lean : Le concept de Lean, qui vise à minimiser les gaspillages et à maximiser la valeur pour le
client, est également appliqué dans la méthodologie DevOps. Cela implique de réduire les
retards, les temps d'attente et les processus manuels.
4. Mesure : La mesure est importante pour comprendre les performances et l'efficacité des
processus DevOps. Les indicateurs de performance clés (KPI) tels que le temps de déploiement,
la fréquence des déploiements, la stabilité du système et la satisfaction des utilisateurs sont
mesurés pour identifier les points à améliorer.
5. Share : Le partage d'informations et de connaissances est essentiel pour une collaboration
efficace entre les équipes de développement et d'opérations. Les équipes doivent partager les
informations sur les processus, les outils et les meilleures pratiques pour améliorer la qualité et
la rapidité de la livraison de logiciels.
En somme, la méthodologie DevOps repose sur les caractéristiques CALMS pour améliorer la
collaboration, la rapidité, la qualité et la fiabilité du développement et de la livraison de logiciels.

4. Définition des notions :

a. L'intégration continue
L'intégration continue (Continuous Integration ou CI en anglais) est une pratique clé de la méthodologie
DevOps. Elle consiste à intégrer régulièrement les modifications de code apportées par les développeurs
dans une base de code partagée. Cette intégration régulière est effectuée à l'aide d'un processus
automatisé qui compile, teste et déploie automatiquement les modifications de code.
Les avantages de l'intégration continue sont multiples :
 1. Réduction des conflits de code : L'intégration régulière permet de détecter rapidement les
conflits de code entre les développeurs et de les résoudre avant qu'ils ne causent des problèmes
majeurs.
2. Détection précoce des bugs : La compilation et les tests automatisés effectués lors de
l'intégration continue permettent de détecter rapidement les erreurs de code et les bugs, ce qui
facilite leur résolution avant que les modifications de code ne soient intégrées dans la version
principale.
3. Livraison rapide et fiable de logiciels : L'intégration continue permet de livrer rapidement et
régulièrement des versions de logiciels testées et validées, ce qui réduit les risques de problèmes
de production.
4. Amélioration de la collaboration : L'intégration continue encourage la collaboration entre les
développeurs et les équipes d'opérations, ce qui favorise une meilleure compréhension des
besoins et des défis de chacun.
Pour mettre en œuvre l'intégration continue, il est nécessaire d'utiliser des outils de gestion de code
source tels que Git ou SVN, des outils d'automatisation de construction comme Jenkins ou Travis CI,
des outils de test automatisés comme JUnit ou NUnit, ainsi que des outils de déploiement continu comme
Ansible ou Puppet.

b. Déploiement continue (livraison continue)

La Livraison continue (Continuous Delivery) et le Déploiement continue (Continuous Deployment) sont
deux pratiques de DevOps qui permettent d'automatiser le processus de mise en production des
applications.
La Livraison continue consiste à automatiser le processus de livraison d'une application à un
environnement de test ou de pré-production, de sorte que chaque fois qu'un développeur valide une
fonctionnalité, l'application est automatiquement construite, testée et livrée dans l'environnement de test
ou de pré-production. Cette pratique permet de réduire les risques d'erreurs humaines et de raccourcir le
temps de mise sur le marché.
Le Déploiement continue, quant à lui, va un peu plus loin que la Livraison continue en automatisant
également le déploiement de l'application en production après avoir passé avec succès les tests de pré-
production. Cette pratique permet d'accélérer le processus de mise en production tout en assurant une
plus grande fiabilité et une meilleure qualité de l'application.
Pour mettre en place la Livraison continue et le Déploiement continue, il est nécessaire d'automatiser
les différentes étapes du processus de mise en production, depuis la compilation et les tests jusqu'à la
livraison et le déploiement de l'application. Cela nécessite l'utilisation d'outils tels que Jenkins, GitLab,
Travis CI, CircleCI, Ansible, Chef, Puppet, Docker, Kubernetes, etc.
Il est également important de mettre en place des mécanismes de surveillance et de feedback pour suivre
les performances de l'application en production et pour pouvoir apporter rapidement des corrections en
cas de dysfonctionnement.
CHAPITRE X : Mettre en place la CI/CD avec Gitlab
1. Introduction :
Dans un environnement DevOps, l'intégration continue (CI) et la livraison continue (CD) sont des
pratiques clés pour automatiser le processus de livraison de logiciels. GitLab CI est un outil qui permet
d'automatiser le processus de construction, de test, de distribution et de déploiement de logiciels.

2. Définition de GitLab CI :
GitLab CI est un outil open source intégré à GitLab qui permet d'automatiser le processus de livraison
de logiciels. Il permet de créer des pipelines CI/CD pour automatiser les différentes étapes du processus
de livraison, telles que la compilation, les tests, la distribution et le déploiement.

a. Principes de fonctionnement de Gitlab CI/CD :

Les pipelines : Les pipelines sont le cœur de GitLab CI/CD. Un pipeline est un ensemble de tâches ou
de jobs qui sont exécutées dans un ordre spécifique pour construire, tester et déployer une application.
Chaque pipeline est déclenché par un événement de Git, tel que le push d'un nouveau code source.
Le Runner : Le Runner est un agent qui permet l'exécution des tâches de pipeline. Il peut être installé
sur une machine virtuelle ou un serveur, ou être exécuté dans un conteneur Docker. Il est utilisé pour
exécuter des tâches spécifiques du pipeline sur une plateforme spécifique, telle que Windows, Linux ou
MacOS.
Les tâches (Jobs) : Les tâches ou jobs sont des étapes individuelles dans un pipeline. Chaque job est
défini dans le fichier YAML du pipeline, et spécifie les étapes nécessaires pour effectuer une tâche
spécifique, comme la compilation, les tests, la construction de conteneurs, etc. Chaque job peut
également spécifier les conditions qui doivent être remplies pour que la tâche soit exécutée.
Les étapes (stages) : Les étapes ou stages sont des groupes de tâches similaires dans un pipeline. Les
stages permettent de regrouper les tâches en fonction de leur but, comme la construction, les tests, le
déploiement, etc. Les étapes sont définies dans le fichier YAML du pipeline et sont exécutées dans
l'ordre spécifié.
Les artefacts : Les artefacts sont des fichiers ou des données générées par les tâches d'un pipeline et qui
peuvent être utilisés par les tâches suivantes. Les artefacts peuvent être des fichiers binaires, des fichiers
de configuration, des rapports de test, des fichiers de log, etc. Les artefacts sont stockés sur le serveur
GitLab et peuvent être utilisés pour effectuer des opérations ultérieures.
Les tags : Les tags sont des étiquettes qui sont appliquées aux builds ou aux versions spécifiques d'une
application. Les tags peuvent être utilisés pour marquer les versions stables de l'application, pour suivre
les versions qui ont été déployées sur l'environnement de production, etc. Les tags peuvent également
être utilisés pour déclencher des actions spécifiques, telles que la notification de l'équipe de
développement ou le déploiement automatique sur l'environnement de production.

3. Configuration de Git pour GitLab CI :

Pour utiliser GitLab CI, il est nécessaire de configurer Git pour se connecter à GitLab. Pour cela, il suffit
de générer une paire de clés SSH et de l'ajouter à votre compte GitLab. Ensuite, vous devez cloner votre
référentiel GitLab sur votre machine locale.

4. Intérêt d'un pipeline DevOps :

Le pipeline DevOps est une approche pour automatiser les différentes étapes du processus de livraison
de logiciels. Il permet d'accélérer le cycle de développement et de réduire le temps nécessaire pour
mettre une nouvelle version en production. En automatisant les étapes de livraison, le pipeline DevOps
permet de réduire les erreurs humaines et d'améliorer la qualité des livraisons.
 5. Architecture de base d'un pipeline CI/CD :

Un pipeline de livraison continue typique comprend plusieurs étapes, chacune définissant une tâche
spécifique à effectuer dans le processus de développement et de déploiement de logiciels. Voici les
étapes typiques d'un pipeline de livraison continue :
1. Compilation : Cette étape consiste à compiler le code source pour créer un package exécutable
qui peut être déployé sur une infrastructure cible.
2. Tests unitaires : Cette étape consiste à exécuter des tests unitaires pour s'assurer que le code
fonctionne correctement.
3. Tests d'intégration : Cette étape consiste à exécuter des tests d'intégration pour s'assurer que le
code s'intègre correctement avec d'autres composants du système.
4. Analyse de code : Cette étape consiste à exécuter des outils d'analyse de code pour détecter les
erreurs et les vulnérabilités potentielles.
5. Packaging : Cette étape consiste à créer des packages d'application à partir du code compilé, des
dépendances et des configurations.
6. Déploiement : Cette étape consiste à déployer les packages d'application sur l'infrastructure
cible.
7. Tests de non-régression : Cette étape consiste à exécuter des tests de non-régression pour
s'assurer que les modifications apportées à l'application n'ont pas introduit de régressions.
8. Validation de la qualité : Cette étape consiste à valider la qualité de l'application à l'aide de
diverses mesures de qualité telles que la couverture de code, la sécurité, les performances, etc.
9. Mise en production : Cette étape consiste à mettre en production l'application une fois que toutes
les étapes précédentes ont été effectuées avec succès.
L'architecture d'un pipeline peut varier en fonction des besoins et des spécifications de chaque projet.
Cependant, l'objectif est d'automatiser le plus possible ces étapes pour garantir une livraison rapide,
fiable et cohérente des logiciels.

6. Workflow du pipeline :
Le workflow typique d'un pipeline de livraison continue qui comprend les phases de
création/construction, de test, de distribution et de déploiement :
1. Phase de création/construction de l'application : Cette phase consiste à récupérer le code source
à partir d'un référentiel de code source et à le compiler pour créer un package exécutable. Cette
phase comprend également la génération de la documentation, la création des artefacts et la mise
à disposition des ressources nécessaires pour les étapes suivantes.
 2. Phase de test : Cette phase consiste à exécuter des tests pour s'assurer que l'application
fonctionne correctement. Les tests peuvent être des tests unitaires, des tests d'intégration, des
tests de performance, des tests de sécurité, etc. Cette phase inclut également l'analyse du code
et la détection des erreurs potentielles.
3. Phase de distribution : Cette phase consiste à préparer les packages d'application pour la
distribution en les empaquetant et en les enregistrant dans un référentiel de packages. Cette
phase peut également inclure la création de fichiers de configuration pour les différents
environnements de déploiement.
4. Phase de déploiement : Cette phase consiste à déployer l'application sur l'infrastructure cible.
Cette phase peut inclure des étapes telles que la configuration de l'infrastructure, la validation
de la qualité, le contrôle de la version, la gestion des erreurs, etc. Cette phase peut également
inclure la mise à jour de la documentation et la communication de la mise à disposition de la
nouvelle version de l'application.
Le workflow d'un pipeline de livraison continue peut être automatisé à l'aide d'outils tels que GitLab CI,
Jenkins, CircleCI, Travis CI, etc. Ces outils permettent de définir les différentes étapes du pipeline et de
les exécuter automatiquement dès que des modifications sont apportées au référentiel de code source.

7. Configuration du pipeline
La configuration d'un pipeline de livraison continue comprend deux éléments principaux : les jobs et les
stages.
1. Jobs : Les jobs sont les tâches à exécuter dans le pipeline. Chaque job est une étape spécifique
dans le processus de livraison continue, telle que la compilation, les tests, le déploiement, etc.
Les jobs sont définis dans le fichier de configuration du pipeline (par exemple, .gitlab-ci.yml
pour GitLab CI) et peuvent être exécutés séquentiellement ou parallèlement. Les jobs peuvent
également avoir des dépendances entre eux, ce qui signifie qu'un job ne sera exécuté que si tous
les jobs précédents ont réussi.
2. Stages : Les stages définissent le moment d'exécution des jobs. Les stages sont des étapes
logiques du pipeline et définissent la progression de la livraison continue. Les stages sont
également définis dans le fichier de configuration du pipeline et peuvent être exécutés dans un
ordre spécifique. Les stages sont souvent utilisés pour définir la progression du pipeline, tels
que la phase de compilation, la phase de tests, la phase de déploiement, etc. Les jobs sont
associés à un stage et sont exécutés dans l'ordre défini par le stage.
Par exemple, voici un exemple de configuration de pipeline pour GitLab CI :

stages:
- build
- test
- deploy

build:
stage: build
script:
- echo "Compiling code..."
- mvn compile
test:
stage: test
script:
- echo "Running unit tests..."
- mvn test

deploy:
stage: deploy
script:
- echo "Deploying application to production..."
- ssh user@server "sudo systemctl stop my-app"
- scp target/my-app.jar user@server:/opt/my-app/
- ssh user@server "sudo systemctl start my-app"

Dans cet exemple, le pipeline est composé de trois stages : build, test et deploy. Les jobs sont associés
à chaque stage. Le premier job est chargé de compiler le code source, le deuxième job est chargé
d'exécuter les tests unitaires, et le troisième job est chargé de déployer l'application sur l'infrastructure
cible.

8. Manipulation d'un pipeline

Pour manipuler un pipeline de livraison continue, vous devez généralement utiliser l'interface utilisateur
de votre outil d'intégration et de livraison continues. Dans le cas de GitLab CI, voici comment vous
pouvez manipuler un pipeline :
1. Démarrage : Un pipeline est déclenché automatiquement lorsqu'un développeur pousse du code
vers une branche du référentiel configuré pour être surveillé par GitLab CI. Vous pouvez
également démarrer manuellement un pipeline en utilisant l'interface utilisateur de GitLab CI.
Pour cela, accédez à la page du projet et cliquez sur l'onglet CI/CD. Vous verrez une liste de
tous les pipelines précédemment exécutés. Cliquez sur le bouton "Run Pipeline" pour lancer
manuellement un pipeline.
2. Arrêt : Il n'y a généralement pas de raison d'arrêter un pipeline en cours d'exécution. Si vous
avez besoin d'interrompre un pipeline en cours, vous pouvez le faire en annulant la tâche en
cours d'exécution (par exemple, en appuyant sur Ctrl+C si vous exécutez le pipeline
localement).
3. Suppression : Vous pouvez supprimer un pipeline en utilisant l'interface utilisateur de GitLab
CI. Accédez à la page du projet et cliquez sur l'onglet CI/CD. Vous verrez une liste de tous les
pipelines précédemment exécutés. Cliquez sur le bouton "Delete" pour supprimer un pipeline
spécifique.

9. Configuration du CI/CD avec le fichier gitlab-ci.yml

La configuration du CI/CD dans GitLab se fait principalement à travers un fichier nommé .gitlab-ci.yml.
Ce fichier est généralement situé à la racine du projet et il contient les instructions pour configurer le
pipeline de livraison continue. Voici les étapes pour configurer le pipeline avec le fichier gitlab-ci.yml
:
1. Créez un fichier .gitlab-ci.yml à la racine de votre projet.
2. Ouvrez le fichier gitlab-ci.yml dans un éditeur de texte.
3. La première étape consiste à définir les étapes (stages) que vous souhaitez exécuter. Les étapes
sont généralement organisées par ordre chronologique et elles peuvent inclure des tâches (jobs)
liées à la création, aux tests, à la distribution et au déploiement de votre application.
4. Ensuite, vous pouvez ajouter des tâches (jobs) à chaque étape. Chaque tâche représente une
action spécifique que vous souhaitez effectuer, comme la compilation du code, les tests
unitaires, les tests d'intégration, la construction d'images Docker, la publication de packages,
etc.
5. Les tâches peuvent être configurées pour être exécutées sur différentes plateformes, telles que
Linux, macOS ou Windows, en utilisant des runners GitLab. Vous pouvez spécifier un runner
spécifique pour chaque tâche en utilisant des tags.
6. Enfin, vous pouvez configurer des actions supplémentaires pour chaque tâche, telles que
l'archivage des artefacts, la notification par e-mail ou la mise à jour des tickets de suivi.
7. Une fois que vous avez terminé de configurer votre pipeline, enregistrez le fichier gitlab-ci.yml
et poussez-le sur GitLab. Le pipeline sera automatiquement déclenché à chaque fois qu'un
développeur poussera du code vers le référentiel configuré pour être surveillé par GitLab CI.
En résumé, pour configurer le CI/CD avec le fichier gitlab-ci.yml, vous devez définir les étapes et les
tâches que vous souhaitez exécuter, configurer les runners GitLab pour exécuter les tâches sur
différentes plateformes, et configurer des actions supplémentaires pour chaque tâche si nécessaire. Une
fois que vous avez terminé la configuration, poussez le fichier gitlab-ci.yml sur GitLab et le pipeline
sera automatiquement déclenché à chaque fois qu'un développeur poussera du code vers le référentiel.
Voici un exemple simple de fichier .gitlab-ci.yml qui peut être utilisé pour un pipeline de livraison
continue :

image: docker:stable

stages:
- build
- test
- deploy

variables:
DOCKER_DRIVER: overlay2
DOCKER_TLS_CERTDIR: ""

before_script:
- docker info
build:
stage: build
script:
- docker build -t my-app .

test:
stage: test
script:
- docker run my-app npm test

deploy:
stage: deploy
script:
- docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY
- docker push my-app
only:
- master

Dans cet exemple, nous avons défini trois étapes (build, test et deploy) qui seront exécutées dans cet
ordre. La première étape (build) construira l'image Docker pour notre application, la deuxième étape
(test) exécutera les tests unitaires sur l'image construite, et la troisième étape (deploy) déploiera l'image
sur un registre Docker en utilisant les informations d'authentification configurées sur GitLab.
La configuration de chaque étape est définie en utilisant la clé script, qui contient une liste de
commandes à exécuter pour cette étape. Nous avons également utilisé la clé only pour spécifier que la
dernière étape (deploy) ne sera exécutée que si le code a été poussé sur la branche master.
Enfin, nous avons également configuré la variable d'environnement CI_REGISTRY_USER et
CI_REGISTRY_PASSWORD pour stocker les informations d'authentification du registre Docker.
Ces variables sont généralement stockées dans GitLab en tant que variables de pipeline protégées.
Cet exemple est très simple, mais il montre comment vous pouvez définir un pipeline de livraison
continue en utilisant le fichier .gitlab-ci.yml. Vous pouvez ajouter d'autres étapes et tâches pour
répondre à vos besoins spécifiques.