Année Académique : 2024- 2025 2 ème Année BTS IDA Ecole : IES LE CAMPUS COCODY

Table des matières

Partie 1 - Comprendre les deux grandes familles de méthodologies de projet

1. Cadrez un projet avec un cahier des charges …………………………………………………………………………………………………………………………………………….3
a) Cahier de charges……………………………………………………………………………………………………………………………………………………………3
b) Pourquoi planifier un projet ?.............................................................................................................................................................4
c) Quelle méthode utilisée pour cette planification ?.......................................................................................................................5
2. Utilisez des méthodologies séquentielles ……………………………………………………………………………………………………………………………………………………5
a) Etape 1 : Définition du projet………………………………………………………………………………………………………………………………………… …5
b) Etape 2 : Conception de
l‟ architecture…………………………………………………………………………………………………………………………..6
c) Etape 3 : Ecriture du code………………………………………………………………………………………………………………………………………………6
d) Etape4 : Recette………………………………………………………………………………………………………………………………………………………………6
e) Qu‟ est ce qu‟ un test
unitaire…………………………………………………………………………………………………………………………………………..7
f) Qu‟ est ce qu‟ une fonctionnalité ?
…………………………………………………………………………………………………………………………………..7
3. Entrez dans le monde des méthodologies agiles ……………………………………………………………………………………………………………………………………….7
a) Une approche itérative et incrémentale (et adaptative)……………………………………………………………………………………..8
1) Itératif………………………………………………………………………………………………………………………………………………………………..8
2) Incrémental………………………………………………………………………………………………………………………………………………………8
3) Adaptatif……………………………………………………………………………………………………………………………………………………………8
b) Des équipes responsabilisées…………………………………………………………………………………………………………………………9
c) Des utilisateurs aux besoins changeants……………………………………………………………………………………………………….9

Partie 2 - Appliquer les méthodologies séquentielles

I. Etape 1 : définissez le projet………………………………………………………………………………………………………………………………10
a) Présentation……………………………………………………………………………………………………………………………………………………10
b) Contenu……………………………………………………………………………………………………………………………………………………….. 10-11
c) Conseils de rédaction…………………………………………………………………………………………………………………………………….. 12
1. Adaptez-vous à votre
audience………………………………………………………………………………………………………………..12
2. Soyez
drôle………………………………………………………………………………………………………………………………………………..12
3. Soyez flexible et incluez vos
collaborateurs…………………………………………………………………………………………..12
II. Etape 2 : concevez l'architecture du programme……………………………………………………………………………………………13
a) Architecture technique générale………………………………………………………………………………………………………………………….13
b) Description des données………………………………………………………………………………………………………………………………………. 14
c) Description du code………………………………………………………………………………………………………………………………………………. 14
d) Plateforme matérielle……………………………………………………………………………………………………………………………………………14
III. Etapes 3 et 4 : développez et testez…………………………………………………………………………………………………………………15
Support : Cours de gestion de projet informatique Professeur : M. Abou Jean-Baptiste : Ing Informaticien
1
 Année Académique : 2024- 2025 2 ème Année BTS IDA Ecole : IES LE CAMPUS COCODY

1. Développement………………………………………………………………………………………………………………………………………………15
2. Collaborer……………………………………………………………………………………………………………………………………………………….15
3. Recette……………………………………………………………………………………………………………………………………………………………16
4. Tests unitaires………………………………………………………………………………………………………………………………………………. 16
5. Test
d‟ intégration………………………………………………………………………………………………………………………………………….. 16
6. Livraison…………………………………………………………………………………………………………………………………………………………17

Partie 3 - Appliquer les méthodologies agiles

1. Découvrez les origines des méthodologies
agiles…………………………………………………………………………………………………………………………………….18
a. Un manifeste pour une nouvelle approche……………………………………………………………………………………………………………………………………18
b. Les valeurs………………………………………………………………………………………………………………………………………………………………………………………….19
c. Les principes………………………………………………………………………………………………………………………………………………………………….......19
d. Les pratiques……………………………………………………………………………………………………………………………………………………………………….19
e. Users Stories……………………………………………………………………………………………………………………………………………………………………..19
f. Continuous Integration (intégration continue) …………………………………………………………………………………………………………………19
g. Acceptance Testing (tests d‟ acceptation) ……………………………………………………………………………………………………………………….20
h. Daily Stand-up…………………………………………………………………………………………………………………………………………………………………….20
2. Appliquez Scrum, la méthodologie la plus populaire…………………………………………………………………………………………………………………………..21
a. Présentation………………………………………………………………………………………………………………………………………………………………………….21
b. Rôles………………………………………………………………………………………………………………………………………………………………………………………21
c. Product Owner……………………………………………………………………………………………………………………………………………………………………..22
d. Le Scrum Master………………………………………………………………………………………………………………………………………………………………….22
e. L‟ équipe…………………………………………………………………………………………………………………………………………………………………………………2
3
f. Débuter un projet : sprint 0…………………………………………………………………………………………………………………………………………………23
g. Visions…………………………………………………………………………………………………………………………………………………………………………………..23
h. Utilisateurs…………………………………………………………………………………………………………………………………………………………………………..23
3. Sprintez !.............................................................................................................................................................................................................................25
a. De la fonctionnalité à la tâche…………………………………………………………………………………………………………………………………………….25
b. Les Stories…………………………………………………………………………………………………………………………………………………………………………..25
c. Écrire une User Story………………………………………………………………………………………………………………………………………………………….26
d. Définir un planning………………………………………………………………………………………………………………………………………………………………..27
e. Découper en tâches……………………………………………………………………………………………………………………………………………………………..27
f. Développer une story………………………………………………………………………………………………………………………………………………… ………….27
g. Les tests de confirmation…………………………………………………………………………………………………………………………………………………….27
h. La story est morte, vive la story ! ………………………………………………………………………………………………………………………………………28

Support : Cours de gestion de projet informatique Professeur : M. Abou Jean-Baptiste : Ing Informaticien
2
 Année Académique : 2024- 2025 2 ème Année BTS IDA Ecole : IES LE CAMPUS COCODY

Partie 1 - Comprendre les deux grandes familles de méthodologies de projet

1. Cadrez un projet avec un cahier des charges

a) Le cahier des charges

Un cahier des charges est un document qui explique les besoins et les attentes du client. Ce dernier le rédige et l‟ envoie à
la personne qui réalisera le projet : prestataire externe, agence ou développeur en interne. Le plus souvent, le prestataire
externe questionne le client sur le cahier des charges pour être sûr d‟ avoir bien compris les attentes de son client. Le
cahier des charges peut être modifié en conséquence afin d‟ y indiquer le budget, les contraintes éventuelles et les
deadlines.
Quand les deux parties sont d‟ accord sur le contenu, elles signent un contrat qui se base sur le cahier des charges. C‟ est
pourquoi un cahier des charges est dit contractuel. Le client peut se retourner contre le prestataire si ce dernier n‟ a pas
réalisé ses engagements. À l‟ inverse, le prestataire peut poursuivre le client s‟ il ne respecte pas les conditions de
paiement.
Le cahier des charges : un socle !
Prenons un exemple. Disons que vous et moi travaillons dans une agence spécialisée dans les projets digitaux, Miroir Noir. La
startup Pur Beurre vient de nous contacter :
De : colette@[Link]
A : hey@[Link]
Objet : Plateforme pour amateurs de Nutella
Bonjour,
Nous sommes une jeune startup et nous aimerions réaliser une plateforme web pour nos clients. Ils viennent régulièrement
dans le restaurant que nous avons fondé il y a quelques années, à Montmartre, et nous aimerions leur proposer un service
Support : Cours de gestion de projet informatique Professeur : M. Abou Jean-Baptiste : Ing Informaticien
3
 Année Académique : 2024- 2025 2 ème Année BTS IDA Ecole : IES LE CAMPUS COCODY

complémentaire : Pur Beurre. Cette plateforme permettra à nos clients de manger mieux en leur proposant un substitut plus
sain à l‟ aliment qu‟ ils auront proposé. Autrement dit, quand Jean-Philippe entrera “Nutella”, notre gentil robot lui proposera
une “pâte aux noisettes et au sucre de Cannes”.
Vous trouverez plus de détails dans le cahier des charges en pièce-jointe.
Je reste à votre disposition pour de plus amples détails.
Cordialement,
Colette Tatou
Ce cahier des charges est assez succinct mais ce n'est pas toujours le cas. Les plus grands projets font l‟ objet d‟ un cahier
des charges bien plus détaillé et approfondi, notamment lorsqu‟ il s‟ agit d‟ une entreprise publique qui est soumise aux
appels d‟ offres. Dans le cahier des charges d‟ un grand projet, nous retrouvons en général ces quatre parties :
• Contexte. Genèse du projet, objectifs, responsables. Procédures de validation, … Besoins fonctionnels,
techniques et organisationnels, ainsi que les contraintes.
• Prestations et livrables attendus.
• Contexte de la réponse. Planning de l‟ appel d‟ offres, règles de sélection, … C‟ est surtout important dans le
cadre d‟ un appel d‟ offres.
Le cahier des charges peut également inclure les spécifications fonctionnelles et techniques (dont nous parlerons dans le
prochain chapitre). Cela dépend des projets !
Après un premier rendez-vous fructueux, nous nous sommes mis d‟ accord sur un budget et avons signé le cahier des
charges. Il est temps de passer à l‟ étape suivante : la planification du projet !

b) Pourquoi planifier un projet ?

C‟ est vrai ça, pourquoi ne pas se mettre à coder tout de suite ? Après tout nous avons déjà les esquisses, la deadline et la
charte graphique. Pourquoi perdre du temps à organiser le projet ?
• Communication. Avant tout, car cela vous permet d‟ aller dans le détail du programme demandé. Avant de
planifier, il faut en effet aller plus loin que le cahier des charges et approfondir les fonctionnalités. Nous allons donc
engager un dialogue avec le client en amont afin de valider avec lui que nous allons bien réaliser ce qu‟ il souhaite.
Vous vous rendrez vite compte que cela vous fera gagner du temps (et éviter les cheveux blancs).
• Sérénité. Que vous travailliez seul ou en équipe, planifier un projet vous aide également à vous concentrer sur
l‟ essentiel pendant la phase de production. Vous n‟ avez pas envie de vous demander tous les matins : “que
manquet-il à mon programme ?”, n‟ est-ce pas ?
• Qualité. Enfin, vos développeurs produiront du code de meilleure qualité car leur coordination sera facilitée.

Support : Cours de gestion de projet informatique Professeur : M. Abou Jean-Baptiste : Ing Informaticien
4
 Année Académique : 2024- 2025 2 ème Année BTS IDA Ecole : IES LE CAMPUS COCODY

Planifier un projet a beaucoup d'avantages !

Cela fait beaucoup de points positifs ! Planifions notre projet Pur Beurre alors !

C) Quelle méthode utiliser pour cette planification ?

Il existe deux grandes familles de méthodologies de projet : celles dites séquentielles et les méthodes agiles. Découvronsles
rapidement dans les deux prochains chapitres !

Support : Cours de gestion de projet informatique Professeur : M. Abou Jean-Baptiste : Ing Informaticien
5
 Année Académique : 2024- 2025 2 ème Année BTS IDA Ecole : IES LE CAMPUS COCODY

2. Utilisez des méthodologies séquentielles

Un projet informatique est développé conjointement par deux équipes : la maîtrise d‟ ouvrage et la maîtrise d‟ oeuvre.
• La maîtrise d’ouvrage (MOA) est le client ou le représentant des utilisateurs. Si nous faisons un parallèle avec une
maison, ce serait la personne qui passe commande. « Je veux une maison jaune avec un toit rouge et un lutin qui
hoche la tête béatement ».
• La maîtrise d’œuvre (MOE) sera l‟ équipe chargée de réaliser la vision de la maîtrise d‟ ouvrage. Face à la
demande précédente, elle répondra certainement « Nous utiliserons de la brique et une dalle en béton. La peinture
sera sans ammoniaque. Quant au lutin… Ce n‟ est pas vraiment de notre domaine, désolé ».
Il arrive parfois que le client ne soit pas formé en gestion de projet et qu‟ il fasse appel à des prestataires dont c‟ est le
métier. Nous parlons alors d‟ assistance à maîtrise d’ouvrage (AMOA).
Bien. Nous savons un peu mieux qui intervient sur le projet. Voyons maintenant les différentes phases et les documents
produits.

a) Etape 1 : définition du projet

La maîtrise d‟ ouvrage écrit les spécifications fonctionnelles (“requirements” en anglais). Il s‟ agit d‟ un (long) document
détaillant point par point tous les comportements de l’application. Nous pouvons le voir comme la Bible du projet :
développeurs, chefs de projet, rédacteurs, bref, tout le monde y aura recours en cas de doute. Il faut le peaufiner !
Nous les verrons en détail un peu plus tard dans la partie suivante.
Dans le cas de Pur Beurre, les spécifications fonctionnelles détailleront, par exemple, comment un utilisateur
cherche un aliment. “L‟ utilisateur arrive sur la page d‟ accueil. Il tape Nutella dans le formulaire qui s‟ affiche et
appuie sur entrée. Une nouvelle page s‟ affiche avec le résultat de sa recherche.”

b) Etape 2 : conception de l’architecture

Support : Cours de gestion de projet informatique Professeur : M. Abou Jean-Baptiste : Ing Informaticien
6
 Année Académique : 2024- 2025 2 ème Année BTS IDA Ecole : IES LE CAMPUS COCODY

Une fois que les spécifications fonctionnelles sont écrites, la maîtrise d‟ oeuvre écrit les spécifications techniques et
conçoit l‟ architecture globale de l‟ application.
À la différence des spécifications fonctionnelles, qui se concentrent sur l‟ utilisation de l‟ application, les spécifications
techniques ont pour objectif de définir le cadre technique du projet. Plus ou moins poussées, elles seront une base de
travail solide pour les développeurs.
Dans le cas de Pur Beurre, les spécifications techniques auront, par exemple, une partie sur la recherche. “La
recherche se fera via l‟ API Open Food Facts qui renvoie des réponses en JSON. La documentation de l‟ API est disponible
à cette adresse.”
En parallèle, le chef de projet technique conçoit l‟ architecture en s‟ aidant de diagrammes UML. Une validation est réalisée
par le client et le chef de projet fonctionnel.

c) Etape 3 : écriture du code

C‟ est au tour des développeurs d‟ entrer sur la scène ! Ils se basent sur les spécifications et sur le diagramme pour
produire le code demandé.

d) Etape 4 : recette
La dernière phase a pour objectif de vérifier que l’application fonctionne comme il se doit. Des tests manuels peuvent être
effectués mais, en règle générale, nous préférons utiliser les pouvoirs de l‟ informatique pour automatiser au maximum ces
vérifications. Nous utilisons notamment des tests unitaires.

e)Qu'est-ce qu'un test unitaire ?

Support : Cours de gestion de projet informatique Professeur : M. Abou Jean-Baptiste : Ing Informaticien
7
 Année Académique : 2024- 2025 2 ème Année BTS IDA Ecole : IES LE CAMPUS COCODY

Chaque test unitaire a pour but de vérifier qu‟ une partie de l‟ application produit bien le résultat attendu quand un
certain événement a lieu. Nous pouvons vérifier, par exemple, que le formulaire n‟ est pas envoyé si l‟ utilisateur n‟ a pas
renseigné son prénom. Automatiser les tests fait gagner beaucoup de temps !

Puis le maître d‟ ouvrage réalise des tests de recette, c‟ est-à-dire qu‟ il va tester manuellement que l‟ application
correspond à ce qui a été demandé.
Une méthodologie de projet séquentielle permet de réaliser ces phases les unes après les autres dans un ordre
chronologique. L‟ objectif de chaque phase est avant tout un document à remettre, plus que des fonctionnalités. Le logiciel
n‟ est testé qu‟ à la fin et le client commence à voir les résultats du travail de préparation parfois plusieurs mois après le
démarrage du projet.
Un projet séquentiel est à suivre point par point !

f) Qu’est-ce qu’une fonctionnalité ?

Il s‟ agit d‟ une petite partie d‟ un programme qui répond au besoin de l‟ utilisateur. Voici quelques exemples de
fonctionnalités :
- Paiement par Paypal
- Compte utilisateur
- Carte affichant les maisons qui ont un toit orange
Suivre cette approche séquentielle à la lettre signifie avoir :
100% des spécifications fonctionnelles avant de commencer la conception,
100% des spécifications techniques avant de commencer le code,
100% du code avant de commencer les tests.
Pas évident, dans ce cas, de modifier des éléments en cours de route ! C‟ est un modèle idéal mais irréaliste. Dans la réalité,
on revient souvent aux phases précédentes, notamment pendant la phase de test qui implique de réécrire du code pour
corriger des défauts, donc de retravailler la conception et par conséquent de modifier les spécifications fonctionnelles.
De plus, les contrôles tout au long du projet sont difficiles à faire car ils portent sur une multitude de documents qui peuvent
devenir très vite assommants. Les développeurs peuvent manquer de motivation, la déprime s‟ installe. Bref, tout va mal ma
bonne dame.
Que faire, mais que faire ? Est-on condamné à cette approche ?

Non, bien entendu, mais vous le saviez déjà ! Les méthodologies de projet agiles sont justement apparues pour résoudre
ces problèmes.

3. Entrez dans le monde des méthodologies agiles

Les méthodes agiles ont commencé leur apparition dans les usines Toyota, dans les années 50, à travers le Lean
Software (d‟ où vient le Kanban). Vous voyez, ce n‟ est pas tout récent !

Une méthode agile est une approche itérative et incrémentale pour le développement de logiciel, réalisé de manière très
collaborative par des équipes responsabilisées appliquant un cérémonial minimal qui produisent, dans un délai contraint,
un logiciel de grande qualité répondant aux besoins changeants des utilisateurs.

a)Une approche itérative et incrémentale (et adaptative)

Support : Cours de gestion de projet informatique Professeur : M. Abou Jean-Baptiste : Ing Informaticien
8
 Année Académique : 2024- 2025 2 ème Année BTS IDA Ecole : IES LE CAMPUS COCODY

1) Itératif
L‟ itération est le principe de répéter un processus plusieurs fois dans le but d’améliorer un résultat.
Prenons un exemple concret !

Lorsque vous apprenez à faire du vélo, vous commencez par rouler avec les petites roues. Vous savez donc pédaler
seule, c‟ est bien, mais vous prenez de la place et vous n‟ êtes pas très rapide. Vous avez d‟ ailleurs fait un croche-
pattes malheureux à la pauvre Hind en passant près d‟ elle. Vous avez beau lui expliquer que ce n‟ est pas de votre faute
(« ce sont les petites roues ! »), elle vous en veut.
Vos parents vous disent alors que vous feriez moins de malheureux et que vous iriez plus vite sans les petites roues.
Vous recommencez alors avec une seule petite roue. Vous n‟ allez toujours pas assez vite mais, au moins, vous prenez
moins de place en largeur.
Vous tombez, vous vous faites mal mais, quelques écorchures plus tard, vous enlevez l‟ autre petite roue. Le résultat est
presque satisfaisant. Vous continuez le même processus jusqu‟ à être capable de poursuivre les pigeons dans les rues
d‟ Aix en Provence. Ah, la belle vie ! Objectif atteint !
Dans le monde du développement, nous utilisons cette approche pour améliorer une fonctionnalité. Nous sommes
pragmatiques et nous savons bien que rien n‟ est parfait la première fois. Une fonctionnalité a besoin d‟ être testée dans des
conditions réelles pour s‟ adapter à ses utilisateurs et pour révéler des bugs éventuels (la case à cocher n‟ apparaît pas sur
Internet Explorer 5 par exemple ).

2) Incrémental
Adjectif. Qui travaille par incréments ou par comptage d‟ impulsions. (Petit Larousse)
Un processus incrémental permet de construire un produit petit à petit en le découpant en pièces détachées. Elles sont le
plus souvent indépendantes les unes des autres mais ont pour caractéristiques d‟ améliorer le produit.
Reprenons l‟ exemple du vélo. À quoi sert-il ? À se déplacer. Nous pouvons par conséquent découper la conception du vélo en
plusieurs sous-produits :
• Un monocycle. L‟ utilisateur se déplace mais n‟ a pas une grande maîtrise de la direction.
• Un monocycle avec une roue avant. L‟ utilisateur a une meilleure maîtrise de la direction mais l‟ objet est
encombrant et peu maniable.
• Un vélo avec guidon. L‟ utilisateur maîtrise la direction et l‟ objet est plus compact mais il est plus difficile de
s‟ arrêter car nous sommes penchés en avant.
• Un vélo avec des freins. L‟ utilisateur se déplace avec aisance et peut s‟ arrêter en cas de danger. Objectif
atteint ! Adaptée à l‟ informatique, cette approche incrémentale incite les responsables de produit à se concentrer
sur les fonctionnalités essentielles et les développeurs à mettre en production régulièrement.

3) Adaptatif
Suivre une approche incrémentale et itérative suppose une grande communication avec ses utilisateurs et une certaine
humilité. Votre produit sera d‟ abord très minimaliste et s‟ améliorera en fonction des retours. Puis vous ajouterez de
nouvelles fonctionnalités qui, à chaque étape, feront l‟ objet de modifications.
Une méthode incrémentale et itérative mettra en œuvre les quatre phases vues plus haut (définition, conception, code et
test) pour chaque incrément, donc pour chaque nouvelle fonctionnalité. Le responsable du produit communiquera alors
avec les utilisateurs pour connaître les modifications éventuelles à apporter lors d‟ une itération ultérieure.
Support : Cours de gestion de projet informatique Professeur : M. Abou Jean-Baptiste : Ing Informaticien
9
 Année Académique : 2024- 2025 2 ème Année BTS IDA Ecole : IES LE CAMPUS COCODY

Les intérêts sont multiples. Outre le fait que vous communiquez régulièrement avec vos utilisateurs, vous avez un réel
sentiment de satisfaction. Votre produit s‟ améliore au jour le jour, concrètement, et vous avez l‟ impression de passer
moins de temps à écrire de la paperasse.

b) Des équipes responsabilisées

Un des principes des méthodes agiles, sur lesquels nous reviendrons plus tard, est le rôle actif de l’équipe produit. Les
membres sont choisis avec soin pour leur complémentarité et leur motivation. Les méthodologies agiles prônent le

Pragmatisme, la simplicité et l‟ efficacité. C‟ est pourquoi chaque membre de l‟ équipe choisit lui-même la tâche sur laquelle
il souhaite travailler et doit être capable de communiquer sur son travail.

Support : Cours de gestion de projet informatique Professeur : M. Abou Jean-Baptiste : Ing Informaticien
1
0
 Année Académique : 2024- 2025 2 ème Année BTS IDA Ecole : IES LE CAMPUS COCODY

Un cérémonial minimal
L‟ accent est mis sur le produit avant tout et non sur les réunions : un produit bancal qui a pourtant des spécifications
parfaites n‟ en restera pas moins un produit inutilisable.
Produire des fonctionnalités, oui, mais de bonne qualité. C‟ est pourquoi les méthodes agiles insistent sur la collaboration
entre les différentes parties prenantes du projet. Les réunions sont conservées mais tout est mis en œuvre pour qu‟ elles
soient le plus efficaces possible. De même, la collaboration entre développeurs est grandement recommandée à travers de la
programmation en binôme par exemple (“pair programming” en anglais).

c) Des utilisateurs aux besoins changeants

Ceci est peut-être le point le plus révolutionnaire : le projet est complètement centré sur l’utilisateur ! L‟ objectif n‟ est
plus de produire des documents qui aideront le projet à avancer mais bien de produire les fonctionnalités que l‟ utilisateur
attend au plus vite et le plus qualitativement possible. L‟ utilisateur évolue et notre service doit refléter ses usages

Jim Highsmith, un des signataires du Manifeste Agile (que nous verrons en détail plus tard), définit d‟ ailleurs l‟ agilité par
rapport au changement :

L„agilité est la capacité à favoriser le changement et à y répondre en vue de s‟ adapter au mieux à un environnement
turbulent.
Attention, cela ne veut pas dire qu‟ une équipe agile dira oui à tout le monde et implémentera toutes les fonctionnalités ! Mais
il lui sera plus facile d‟ intégrer des changements et de modifier l‟ ordre de priorité des tâches que dans une équipe qui suit
une approche séquentielle.
Bien ! Vous avez désormais un bon aperçu des deux approches. Entrons maintenant dans le détail ! Nous allons commencer
par les méthodologies de projet séquentielles car les méthodes agiles leurs empruntent certains concepts.

Support : Cours de gestion de projet informatique Professeur : M. Abou Jean-Baptiste : Ing Informaticien
1
1
 Année Académique : 2024- 2025 2 ème Année BTS IDA Ecole : IES LE CAMPUS COCODY

Partie 2 - Appliquer les méthodologies séquentielles

1. Etape 1 : définissez le projet

Nous avons vu qu‟ une approche séquentielle supposait produire en amont tous les documents nécessaires au
développement d‟ un projet. Pour rappel, voici les différentes phases suivies :
• Définition du projet : production des spécifications fonctionnelles
• Conception de l’architecture : production des spécifications techniques
• Codage : création du produit demandé
• Recette : tests (automatiques et manuels)
Commençons par réfléchir, avec notre cliente Colette Tatou, aux spécifications fonctionnelles.

a) Présentation
Une spécification fonctionnelle décrit la manière dont un produit fonctionnera, entièrement du point de vue de l‟ utilisateur.
Ici nous ne parlons pas de technique mais bien de fonctionnalités.
Quel menu ?
Quel écran s‟ affiche lorsque notre utilisateur entre “Nutella” dans le champ de recherche ?
Elle précise également quels sont les acteurs impliqués dans le projet et leur champ de responsabilité.

b) Contenu
Au même titre qu‟ un cahier des charges, le contenu des spécifications fonctionnelles dépend en grande partie de l‟ auteur.
Néanmoins, toute spécification fonctionnelle devrait contenir les champs suivants :
Un auteur (de préférence unique, le chef de projet de la maîtrise d‟ ouvrage)
Des scénarios utilisateurs,
• Un aperçu sous forme de diagramme,
• Des détails concernant chaque scénario utilisateur.

Support : Cours de gestion de projet informatique Professeur : M. Abou Jean-Baptiste : Ing Informaticien
1
2
 Année Académique : 2024- 2025 2 ème Année BTS IDA Ecole : IES LE CAMPUS COCODY

Pour Joël Spolsky, le fondateur de Trello et de StackOverFlow (entre autres), les spécifications fonctionnelles sont avant
tout un outil d‟ aide à la décision. Elles doivent décrire tous les scénarios utilisateurs (que se passe-t-il si l‟ utilisateur
oublie son mot de passe ? Ou si la recherche ne donne aucun résultat ?) Afin d‟ aider le plus possible les développeurs. Ces
derniers ne devraient pas se poser de questions sur les fonctionnalités mais se concentrer sur les problématiques
techniques. Cela les aide à être plus performants et allège les allers-retours avec le client.
C‟ est pourquoi Joël ajoute quelques éléments à ses spécifications fonctionnelles :
• Une décharge disant que ce n‟ est pas la version finale de la spec, qu‟ elle évoluera. En effet, il préconise une
évolution constante du document qui suit l‟ avancée du projet. Il s‟ agit d‟ un parti pris qui peut être très
intéressant dans le cadre de projets impliquant peu d‟ intervenants (une dizaine de développeurs).
• Des non-buts : non, nous n‟ allons pas développer cette fonctionnalité. Cela permet de prévenir, en amont,
certaines questions.
• Des questions en suspens : les spécifications étant vues par Joël comme un outil d‟ aide à la décision, il est
important d‟ y inclure les points restés sans réponse ou à tester.
• Des annotations pour certaines équipes : elles seront lues par certaines personnes et ignorées par d‟ autres.
Cela permet de centraliser les questions éventuelles. Par exemple, certaines notes concerneront les rédacteurs de
la documentation ou les développeurs.
À l‟ inverse, les spécifications fonctionnelles des très gros projets seront conséquentes et moins flexibles.
Exemple de Pur Beurre : le cahier des charges contient une partie de ce qui est demandé dans les spécifications
fonctionnelles mais il manque les scénarios utilisateurs et le diagramme. Les spécifications fonctionnelles contiendraient
probablement :
• la présentation du cahier des charges,
les esquisses,
• les maquettes réalisées par un graphiste,
• un diagramme : accueil, mon compte, mes aliments favoris, contact
• des scenarios utilisateurs : Lily met un aliment en favoris, Lily fait une recherche, Lily se connecte à son compte,
Lily se déconnecte, Lily oublie son mot de passe, ...

c) Conseils de rédaction
1. Adaptez-vous à votre audience
Cela peut paraître évident mais vous ne rédigerez pas les mêmes spécifications si votre équipe est composée de 40
développeurs travaillant pour le ministère des finances que si vous officiez chez Google. Ils auront d‟ ailleurs très
certainement un premier document de travail sur lequel vous pourrez vous appuyer.
Votre audience a beau être intelligente, elle n‟ aime pas se poser des questions en lisant vos specs. Pour être efficace,
utilisez des phrases courtes qui représentent véritablement votre propos. Évitez les longs paragraphes et, dès que
vous le pouvez, préférez un schéma explicatif à une grande description. Tout est plus simple en image !
2. Soyez drôle
Dans la mesure du raisonnable et en fonction de votre audience, écrivez des specs agréables à lire. En effet, un des grands
arguments à l‟ encontre des specs est que personne ne veut les lire et que, par conséquent, elles ne servent à rien. Mais
imaginez si en place et lieu de “l‟ utilisateur X” vous parlez de Jocelyne Zgara, 20 ans, habitante du merveilleux village
Mouilleron-le-captif dans la Loire ? Cela donne tout de suite plus envie de se plonger dans un document de 100 pages,
n‟ estce pas ?

Support : Cours de gestion de projet informatique Professeur : M. Abou Jean-Baptiste : Ing Informaticien
1
3
 Année Académique : 2024- 2025 2 ème Année BTS IDA Ecole : IES LE CAMPUS COCODY

3. Soyez flexible et incluez vos collaborateurs

Dans la mesure du possible, soyez conscient que vos spécifications peuvent évoluer en fonction des retours de votre client et
des équipes techniques. Incluez vos collaborateurs pendant le processus de rédaction en leur demandant leur avis et en
prenant en compte leurs retours éventuels. Cela les impliquera dans le projet et les motivera pour la suite, tout en vous
aidant à améliorer de manière significative vos spécifications.
Quand les spécifications fonctionnelles sont rédigées et validées par le client, il est temps de créer les spécifications
techniques et de concevoir l‟ architecture !

2. Etape 2 : concevez l'architecture du programme

Le document 'Spécifications techniques' du Conseil d'Europe n'est plus disponible sur leur site, mais vous trouverez bien
d'autres exemples en ligne !
Les spécifications techniques décrivent l‟ implémentation du programme.
Quelle va être la base de données ?
Son organisation ?
Quel langage va-t-on choisir, quel Framework ?
L‟ objectif de ce document est de préparer en amont tous les éléments techniques dont les développeurs auront besoin
pour coder.
Lorsque le projet suppose la création, à partir de zéro, d‟ un nouveau programme, les spécifications techniques se
concentrent sur tous les éléments nécessaires à cette mise en place.
Mais parfois ce nouveau programme s‟ inscrit dans un système qui existe déjà. Par exemple, ajouter l‟ inscription à une
newsletter sur le site des impôts. Dans ce cas, les spécifications techniques font également lieu de documentation : elles
expliquent comment fonctionne le système actuel et comment les développeurs peuvent interagir avec l‟ existant.
Dans tous les cas, la première partie est, en général, dédiée à l‟ architecture générale du projet. Nous y retrouvons
notamment le schéma d‟ architecture, c‟ est à dire l‟ organisation des serveurs qui permettra aux utilisateurs d‟ accéder
aux données. Les parties suivantes entrent dans le détail et varient selon la taille du projet.
a)Architecture technique générale
Si vous ouvrez le modèle de spécifications techniques dont je vous ai donné lien quelques lignes plus haut, vous y retrouverez
une présentation générale du projet et un schéma d‟ architecture (page 6).
Nous pourrions également y lire un éventuel schéma UML (pour la base de données) et toute information qui s‟ appliquerait
au projet de manière globale (les langages choisis par exemple).
Batch / Interfaces
Un batch est un “traitement par lots”. C‟ est un bien grand mot pour désigner une tâche qui est effectuée automatiquement
sur un ensemble de données. Par exemple, envoyer un mail à tous les étudiants de votre promo pour les informer de la
prochaine soirée “Video killed the radio star” !

Support : Cours de gestion de projet informatique Professeur : M. Abou Jean-Baptiste : Ing Informaticien
1
4
 Année Académique : 2024- 2025 2 ème Année BTS IDA Ecole : IES LE CAMPUS COCODY

Ici

L‟ auteur spécifie, notamment, les traitements éventuels des données entrantes (les mails dans notre exemple) et des
données sortantes (les messages envoyés).

Exemple de Pur Beurre : nous pourrions détailler ici l‟ utilisation de l‟ API Open Food Facts (la manière dont nous
récupérons les données).

b) Description des données

Ici nous détaillons la manière dont nous allons utiliser les données.
Par exemple, comment modifie-t-on le nom d‟ un aliment ?
Sous quel format ?
Comment Nadine met-elle un aliment en favoris ?
Exemple de Pur Beurre : nous pourrions spécifier ici tous les attributs d'un aliment. Par exemple, dire qu'un aliment a
un identifiant, un nom et une description. Nous pourrions dire également qu'un utilisateur a plusieurs aliments et qu'un
aliment "appartient" à plusieurs utilisateurs.
c) Description du code
Nous voyons dans cette section notamment la version du langage utilisé, du framework et des guides de style (quelle est
la règle pour écrire une variable, déclarer une nouvelle fonction, …).
Exemple de Pur Beurre : le langage est Python 3 et nous utilisons le framework Django. La PEP 8 doit être respectée.
d) Plateforme matérielle
Cette section se concentre sur l‟ aspect matériel (hardware) du projet. Attend-on beaucoup de trafic et, par conséquent,
doit-on prévoir des performances élevées ? Va-t-il y avoir beaucoup de calculs à traiter ? Quelle mémoire vive est
nécessaire ? Etc.
Exemple de Pur Beurre : Un serveur web et un serveur base de données pour le moment. Note : nous pouvons prévoir
deux serveurs web dans quelques mois, quand le trafic sera plus élevé, avec un load balancer.
Notre projet étant maintenant bien détaillé, nous pouvons passer le relais aux développeurs qui vont se mettre à coder.

Support : Cours de gestion de projet informatique Professeur : M. Abou Jean-Baptiste : Ing Informaticien
1
5
 Année Académique : 2024- 2025 2 ème Année BTS IDA Ecole : IES LE CAMPUS COCODY

3. Etapes 3 et 4 : développez et testez

Nos développeurs sont sur les starting blocks, les doigts sur leurs claviers, les yeux rivés sur vous ! Vous donnez le top du
départ. Prêtes ? … Partez !
2. Développement
3. Collaborer
Contrairement au mythe, les développeurs (ses) travaillent rarement seules au fond d‟ une cave, entourés de cadavres.
Mais comment collaborer quand on travaille sur un projet partagé par toute une équipe ? Et comment le développeur peut-il
être certain que le code sur lequel il travaille est bien la dernière version disponible ?
Finalement, nous avons tous connu ce problème. Nous accumulons les versions de différents documents (“Mémoire [Link],
Mémoire v1 [Link], Mémoire def [Link]” etc) pour garder une copie de l‟ ancien, en attendant que notre document soit
corrigé ou tout simplement “au cas où”.

Les développeurs étant également des êtres pragmatiques, ils ont inventé Git, un outil de gestion de versions. Concrètement,
Git vous permet de revenir à une version précédente si vous le souhaitez ainsi que de voir l‟ auteur de toute modification.
Très pratique quand on travaille en équipe !

Support : Cours de gestion de projet informatique Professeur : M. Abou Jean-Baptiste : Ing Informaticien
1
6
 Année Académique : 2024- 2025 2 ème Année BTS IDA Ecole : IES LE CAMPUS COCODY

Bon à savoir : on dit qu‟ un développeur

travaille en
local
il travaille sur son ordinateur. Il récupère une version du code partagé par l‟ équipe, le modifie sur son ordinateur et le
quand

renvoie à l‟ équipe.
Le miroir de la réalité
Quand un développeur a terminé de développer une fonctionnalité il l‟ envoie sur un serveur de test (parfois appelé
“staging” ou “préprod” pour les intimes). Il s‟ agit d‟ un environnement qui ressemble à 100% à celui de production.
Wait, déjà c‟ est quoi un serveur ?
Un serveur est simplement un ordinateur sur lequel un logiciel a été installé. Ce logiciel permet aux langages de
programmation de fonctionner. Vous pouvez "transformer" votre propre ordinateur en serveur ou bien vous connecter à un
autre via internet. C'est ainsi que fonctionnent les hébergeurs !
Utiliser un serveur de pré-production vous permet de tester que les fonctionnalités que vous avez développées ne
buggent pas dans les conditions réelles d’utilisation. En effet, la configuration peut être très différente entre l‟ ordinateur
d‟ un développeur et celui sur lequel se connectent nos utilisateurs.
Quand toutes les fonctionnalités ont été implémentées dans le serveur de pré production, il est temps de tester que le code
fonctionne !
4. Recette
La période de recette peut être assez longue pour les projets fonctionnant en séquentiel. En effet, il faut tester toutes les
fonctionnalités dans les moindres détails ! Elles doivent correspondre point pour point aux spécifications fonctionnelles et
techniques qui ont été signées précédemment.

Les acteurs qui interviennent pendant cette étape s‟ appellent les responsables qualité (ou QA managers). Ils sont
responsables de la vérification.
Contrairement à ce que nous pourrions imaginer, la majorité des tests est automatique, effectuée par un robot (mais
codée par un humain !). Il existe deux sortes de tests : les tests unitaires et les tests d’intégration.

Support : Cours de gestion de projet informatique Professeur : M. Abou Jean-Baptiste : Ing Informaticien
1
7
 Année Académique : 2024- 2025 2 ème Année BTS IDA Ecole : IES LE CAMPUS COCODY

5. Tests unitaires
Les tests unitaires vérifient qu‟ une petite partie d’une fonctionnalité est bien implémentée. Par exemple, nous pouvons
vérifier qu‟ un numéro de téléphone sous la forme “0000000000” sera bien refusé par le système et ne sera pas enregistré
dans la base de données.
Exemple Pur Beurre : un test unitaire pourrait vérifier qu'un aliment sans titre ne s'enregistre pas dans la base de
données, ou qu'une recherche vide renvoie bien le résultat "aucun résultat" !

6. Tests d’intégration
Les tests d‟ intégration ont pour but de vérifier que les fonctionnalités sont bien interconnectées et que l‟ ensemble est
homogène. Chaque fonctionnalité ayant probablement été développée par un développeur différent, il est nécessaire de
vérifier qu‟ elles communiquent bien entre elles et qu‟ il n‟ y a pas de bug.
Si notre programme s‟ insère dans un autre système, les tests d‟ intégration vont également

Vérifier que l‟ un et l‟ autre s‟ agencent harmonieusement et que notre programme ne crée pas de troubles dans l‟ ancien
système.
Prenons un exemple. Imaginons que nous ajoutons une boutique sur le site de la NASA. C‟ est une révolution : vous pouvez
désormais réserver un aller pour la Lune (personne ne parle du retour…) et payer en ligne.
Nous commençons par tester que l‟ utilisateur ne peut pas rentrer un faux numéro de carte bleue. Il s‟ agit d‟ un test
unitaire.
Puis nous vérifions que la fonctionnalité “ajouter un produit dans le panier” interagit bien avec la fonctionnalité “payer via
Paypal”. Nous faisons cela via les tests fonctionnels.
Enfin, nous vérifions que notre nouvelle boutique est bien intégrée au site officiel et qu‟ elle ne génère pas de nouveaux bugs.
Ceci est également fait via des tests fonctionnels.
Certaines équipes font également des tests manuels, c‟ est-à-dire qu‟ ils vont exécuter eux-mêmes les scénarios
utilisateurs. Par exemple, la personne effectuant la recette va ajouter “voyage sur la lune” au panier, cliquer sur ce dernier,
payer en carte bancaire et quitter le site.
Ces tests sont assez rares néanmoins car ils prennent beaucoup de temps.

Support : Cours de gestion de projet informatique Professeur : M. Abou Jean-Baptiste : Ing Informaticien
1
8
 Année Académique : 2024- 2025 2 ème Année BTS IDA Ecole : IES LE CAMPUS COCODY

7. Livraison
Quand tous les tests sont positifs, on livre le projet au client. C‟ est ensuite à lui de décider s‟ il met en ligne lui-même ou
s‟ il fait appel à la même équipe.
Cette partie du projet devrait être la plus valorisante. Pourtant, c‟ est assez rarement le cas lorsque notre projet s‟ organise
autour de méthodologies séquentielles. En effet, notre client découvre le rendu à la toute fin et souvent après une longue
période de temps. Ses idées ont pu changer, il ne pensait pas que ce qu‟ il avait imaginé ressemblerait à ça dans la vraie vie
du monde véritable.
De plus, les fonctionnalités peuvent être plus ou moins bien écrites et, par conséquent, applicables. Suivre les spécifications
à la lettre peut créer des programmes bancals, d‟ autant plus si aucune personne technique n‟ a été consultée.
Alors comment intégrer les retours du client au fur et à mesure ? Vous connaissez déjà la réponse. Hé oui, souhaitons la
bienvenue aux méthodologies agiles

Partie 3 - Appliquer les méthodologies agiles

1. Découvrez les origines des méthodologies agiles

Support : Cours de gestion de projet informatique Professeur : M. Abou Jean-Baptiste : Ing Informaticien
1
9
 Année Académique : 2024- 2025 2 ème Année BTS IDA Ecole : IES LE CAMPUS COCODY

a. Un manifeste pour une nouvelle approche

Nous l‟ avons vu précédemment, les méthodologies dites “agiles” existaient déjà bien avant l‟ apparition d‟ Internet pour le
grand public : les usines Toyota utilisaient déjà la méthode Kanban pour optimiser la production de voitures. Plus tard, lorsque
les projets informatiques se sont densifiés et ont accumulé les ralentissements, certains gestionnaires de projets ont adapté
des méthodes utilisées par l‟ industrie à leur secteur. D‟ autres ont inventé les leurs, mettant le produit et l‟ interaction avec
le client au centre de la planification.
Des débats ont émergé sur la pertinence des méthodologies séquentielles, perçues comme lourdes et poussiéreuses, face
à d‟ autres pratiques qui commençaient à émerger.

Ces discussions ont débouché sur la rédaction d‟ un document, le Manifeste Agile (Agile Manifesto), au début des années
2000. Il définit des valeurs et des principes partagés par tous les signataires et qui vont à l‟ encontre des méthodes
séquentielles, alors utilisées dans tous les secteurs et reconnues comme étant les plus performantes. Il s‟ agissait d‟ une
prise de position considérable !

b. Les valeurs
Les valeurs du manifeste sont les suivantes :
• Les individus et leurs interactions sont plus importants que les processus et les outils,

Support : Cours de gestion de projet informatique Professeur : M. Abou Jean-Baptiste : Ing Informaticien
2
0
 Année Académique : 2024- 2025 2 ème Année BTS IDA Ecole : IES LE CAMPUS COCODY

• Un logiciel qui fonctionne est mieux qu‟ une documentation exhaustive, Collaborer avec
les clients est préférable à la négociation contractuelle, S‟ adapter au changement est mieux
que de suivre un plan.
Puisque vous avez déjà un bon aperçu des méthodologies séquentielles, prenez une minute (ou plus…) pour relire les valeurs
unes à unes et mesurer les changements que cela suppose.
Ces valeurs sont relativement théoriques, mais elles découlent sur des principes très pratiques dans la gestion d‟ un projet
au quotidien.

c. Les principes
Le Manifeste comprend douze principes que je vous laisse lire tranquillement. Allez-y, ce n‟ est pas long !

d. Les pratiques
Les quatre valeurs et les douze principes sont partagés par toutes les pratiques Agiles. Pourquoi avoir plusieurs
méthodologies ? Tout simplement car les projets et les équipes sont différents, il faut donc avoir une palette de méthodes
qui puisse s‟ adapter à tous les cas.
Il existe une soixantaine de pratiques au total. Voici celles qui sont les plus utilisées :

• User stories
• Pair Programming
• Continuous integration (CI)
• Acceptance Testing
• Iteration Planning / Planning Game / Sprint Planning
• Daily Stand-Up Meeting / Daily Scrum Détaillons-les succinctement.

e. User stories
Une user story est une fonctionnalité écrite du point de vue de l’utilisateur et très succincte. Elle raconte ce que fera
l‟ utilisateur dans notre programme sous forme d‟ histoire.
Par exemple : “Linda cherche un aliment sur la page d‟ accueil.”.
Pair Programming (programmation en binôme)
Un écran, un code, deux programmeurs. Le binôme se met d‟ accord sur une fonctionnalité à développer et le fait
ensemble. Les avantages sont multiples : meilleur code, collaboration renforcée et communication facilitée.

Pur Beurre : deux développeurs (ses) pourraient ensemble coder la fonctionnalité d'authentification. Ils / elles
auraient probablement des stratégies différentes au début, puis échangeraient avant de se mettre d'accord puis de
la réaliser ensemble.

f. Continuous Integration (intégration continue)

Cette pratique naît du principe “Livrer fréquemment un logiciel opérationnel avec des cycles de quelques semaines à
quelques mois et une préférence pour les plus courts.”
Chaque fonctionnalité est intégrée à la précédente, ajoutée au programme en production, au lieu d‟ être développée dans
son coin comme c‟ est le cas en séquentiel. Cela permet de toujours avoir un logiciel qui marche et de le voir se développer,
ce qui motive l‟ équipe et les utilisateurs.

Support : Cours de gestion de projet informatique Professeur : M. Abou Jean-Baptiste : Ing Informaticien
2
1
 Année Académique : 2024- 2025 2 ème Année BTS IDA Ecole : IES LE CAMPUS COCODY

Pur Beurre : la première fonctionnalité pourrait être l'authentification. Elle serait certainement mise directement
sur un serveur de test. Quand la fonctionnalité suivante serait prête (la recherche par exemple), elle serait
"ajoutée" à l'authentification et nous re-testerions l'ensemble. Puis nous ajouterions la mise en favoris. Et ainsi de
suite !

g. Acceptance Testing (tests d’acceptation)

Avant de passer à la story suivante, quelqu‟ un doit valider que celle-ci est bien terminée. Mais comment faire ? En suivant
les tests d‟ acceptation. Ces derniers donnent les conditions à réunir pour déclarer une story terminée.
Pur Beurre : si notre story est “Linda cherche "Nutella" sur la page d‟ accueil”, le test d‟ acceptation pourrait être
“Linda trouve Nutella”.
Planning game
Chaque User Story correspond à une nouvelle étape de développement (nous reviendrons sur ce point plus tard). À la
différence des méthodologies séquentielles, le planning des méthodologies agiles est flexible et redéfini à chaque nouvelle
User Story. L‟ équipe se réunit et estime la durée de réalisation de chaque User Story. Évidemment, les premières
estimations sont assez éloignées de la réalité mais plus l‟ équipe travaille ensemble plus leurs estimations s‟ affinent. Elles
itèrent pour arriver, au bout de quelques mois, à des estimations très justes.

h. Daily stand-up meeting

L‟ équipe se réunit chaque jour et chaque membre présent, très rapidement, ce qu’il a fait la veille, ce qu‟ il
fera aujourd’hui et un point bloquant. C’est ‘occasion de partager son travail et de recevoir des retours de la part de ses
collaborateurs. Pour éviter que cela ne dure plus de 30 minutes, tout le monde reste debout !

Les méthodes

Les pratiques sont regroupées en méthodes. Il en existe environ 8 que je vous laisse découvrir dans cet excellent article, les
plus populaires étant :
• Dynamic systems development methods (DSDM) : une approche incrémentale et itérative qui comprend une
intégration constante des clients,
• Feature Driven Development (FDD) : une méthodologie légère dont l‟ objectif est de créer un logiciel qui
s‟ adapte efficacement aux changements de demandes,
• Extreme Programming (XP) : une méthode très pragmatique et centrée sur les pratiques,
• Scrum : la méthode agile la plus populaire et la plus largement utilisée. Il s’agit d’une stratégie de développement
très flexible quand une équipe travaille ensemble pour atteindre un but commun. Nous la verrons plus en détail dans
le prochain chapitre !

Support : Cours de gestion de projet informatique Professeur : M. Abou Jean-Baptiste : Ing Informaticien
2
2
 Année Académique : 2024- 2025 2 ème Année BTS IDA Ecole : IES LE CAMPUS COCODY

2. Appliquez Scrum, la méthodologie la plus populaire

a. Présentation
Les dieux du Scrum
Scrum veut dire “mêlée” en anglais. Hé oui, cette méthodologie de projet vient du Rugby ! La méthode utilise les valeurs et
l‟ esprit du Rugby pour les adapter au développement de logiciel. Le sens de l‟ équipe, du contact, du travail bien fait !
Comme le pack pendant un ballon porté, l‟ équipe est soudée pour atteindre l‟ objectif. Le Scrum Master est, quant à lui,
similaire au demi de mêlée qui répartit les membres de l‟ équipe et les réorganise pour assurer la réussite du projet.
Alors, comment ça fonctionne ? Voyons ça dans le détail !
Au début du projet, le projet est découpé en fonctionnalités qui sont listées dans un backlog, une sorte de grand tableau.
Puis nous allons nous intéresser à la première version qui sera mise en ligne. Elle sera volontairement minimale, se
concentrant sur les fonctionnalités essentielles qui ont été indiquées comme prioritaires dans le backlog. Chaque mise en
production est appelée release et est constituée de plusieurs sprints.

Un sprint dure entre une et deux semaines et sert à développer une ou plusieurs fonctionnalités. Elles sont décidées par
l‟ équipe et le Product Owner (dont nous parlerons plus tard). Chaque sprint est découpé en Stories mais nous verrons
tout cela en détails plus tard. Pour l‟ instant, gardons en tête que le(a) développeur(se) de chaque story produira les mêmes
livrables que ceux que nous avons vus dans les méthodologies séquentielles mais à l‟ échelle d‟ une story et non du projet
tout entier.
Il / Elle aura donc à :

créer des spécifications fonctionnelles,

concevoir l‟ architecture de la story,
coder et tester.

Pendant un sprint, des points sont effectués lors des mêlées quotidiennes. Cela permet au Scrum Master, l‟ animateur
chargé de faire appliquer Scrum, de déterminer l‟ avancement par rapport aux engagements de chacun et éventuellement
d‟ apporter des ajustements.
À la fin de chaque sprint, l‟ équipe ajoute une nouvelle brique au projet qui devient ainsi, de sprint en sprint, de plus en plus
complet. Son évaluation et le feedback récolté permettent d‟ ajuster le backlog pour le sprint suivant. Cela s‟ appelle
l‟ inspection.
Puis l’équipe passe à un nouveau sprint, constitué de stories, et ainsi de suite !

b. Rôles
Les responsabilités et les missions des intervenants d‟ un projet agile sont très différentes en comparaison avec un projet
séquentiel car l‟ accent est mis sur l‟ appropriation du projet par chaque membre de l‟ équipe et sur la collaboration.

Support : Cours de gestion de projet informatique Professeur : M. Abou Jean-Baptiste : Ing Informaticien
2
3
 Année Académique : 2024- 2025 2 ème Année BTS IDA Ecole : IES LE CAMPUS COCODY

c. Le Product Owner
Il représente les utilisateurs finaux (ou clients) du projet. Il est responsable de la définition du contenu du produit et de la
gestion des priorités. C‟ est pourquoi il alimente régulièrement le backlog en nouvelles fonctionnalités et trie les
anciennes par ordre de priorité. Le Product Owner définit l’objectif d’une release et prend les décisions sur son contenu.

Idéalement il est disponible à plein temps pour mettre à jour le backlog, répondre aux questions sur le produit, définir les
tests d‟ acceptation (dont nous parlerons plus tard) et passer les tests.

d. Le Scrum Master
Il n‟ y a pas de chef de projet dans Scrum ! Chaque membre s‟ approprie le projet et l‟ équipe s‟ auto-organise en
conséquence. Le Scrum Master aide l’équipe à appliquer les principes de Scrum, en la guidant sur la rédaction d’User
Stories par exemple. Il fait également en sorte d‟ éliminer tout obstacle qui pourrait entraver le projet. On dit souvent que
le Scrum Master “protège” l‟ équipe car toute demande provenant de l‟ extérieur doit auparavant passer par le processus
Scrum.

Support : Cours de gestion de projet informatique Professeur : M. Abou Jean-Baptiste : Ing Informaticien
2
4
 Année Académique : 2024- 2025 2 ème Année BTS IDA Ecole : IES LE CAMPUS COCODY

e. L’équipe
Il s‟ agit du rôle principal ! C‟ est elle qui réalise le produit. Elle doit, par conséquent, posséder toutes les compétences
nécessaires à son bon développement. Les membres sont choisis par le Scrum Master en fonction de leur motivation et de
leurs compétences. C’est l’équipe qui définit elle-même la façon dont elle organise ses travaux,

ce n’est pas le Scrum Master ni le Product Owner. Chaque membre de l’équipe apporte son expertise.
Les responsabilités de l’équipe sont donc essentielles !

f. Débuter un projet : sprint 0

On appelle “Sprint 0” la période précédant le premier sprint. Elle est dédiée à l’organisation du projet : prise de
connaissance avec le produit et avec les attentes des utilisateurs, recrutement de l’équipe et création du back log.
g. Vision
Nous avons vu que la responsabilité majeure du Product Owner est de faire en sorte que le produit développé réponde à un
besoin des utilisateurs. Il doit posséder une vision très forte du produit qu‟ il souhaite pour être capable de la transformer.
Cette vision répond à la question toute simple (et pourtant souvent complexe) du “pourquoi ?”. Pourquoi notre utilisateur va-
t-il se servir de l’application que nous développons ? La réponse doit être limpide.

h. Utilisateurs
Le Product Owner se doit de connaître parfaitement les utilisateurs qu’il représente. Garder en tête leurs besoins est une
première étape mais connaître leurs usages actuels est encore mieux.

Pour cela, le Product Owner crée une ou plusieurs personas et les partage au reste de l’équipe.

Support : Cours de gestion de projet informatique Professeur : M. Abou Jean-Baptiste : Ing Informaticien
2
5
 Année Académique : 2024- 2025 2 ème Année BTS IDA Ecole : IES LE CAMPUS COCODY

Qu‟ est-ce qu‟ une persona ?

Il s‟ agit du portrait-robot de l‟ utilisateur de notre produit. Nous lui donnons un prénom, un âge, nous lui construisons une
histoire et lui donnons des habitudes qui reflètent ce que nous savons déjà de notre utilisateur.
L‟ objectif est de rendre plus tangible le développement de chaque fonctionnalité. Il est plus facile de penser à Lisa que de
penser à l‟ utilisatrice Y !

i. Backlog
Puis le Product Owner remplit le backlog.

Le Backlog est un grand tableau listant les fonctionnalités prévues pour le produit et leur état d‟ avancement (en attente de
développement, prévu, en cours, fini, …). Chacune est placée par ordre de priorité de haut en bas, celle en haut étant la
prochaine fonctionnalité à développer.
En général un tableau de backlog contient les colonnes suivantes :

• Product backlog : les fonctionnalités qui ont été priorisées par le Product Owner
et qui sont en attente de développement.
• Development : User Stories en développement Done : User Stories qui ont
été mises en production.

À ce stade, il n‟ y a que la colonne Product Backlog qui est remplie. C‟ est normal car nous n‟ avons pas encore démarré le
premier sprint ! L‟ équipe va analyser la première fonctionnalité, la découper en user stories et déterminer le scope du
premier sprint. Nous voyons tout cela dans le prochain chapitre !

Support : Cours de gestion de projet informatique Professeur : M. Abou Jean-Baptiste : Ing Informaticien
2
6
 Année Académique : 2024- 2025 2 ème Année BTS IDA Ecole : IES LE CAMPUS COCODY

3. Sprintez !
a. De la fonctionnalité à la tâche
Avant de démarrer un sprint, l‟ équipe se réunit pour analyser les fonctionnalités en attente et déterminer le scope du
prochain sprint. Mais pourquoi ne pas se dire “un sprint = une fonctionnalité” ?
Tout simplement car une fonctionnalité peut être très large et longue à mettre en oeuvre. Cela peut être, par exemple,
“Compte utilisateur”. Or l‟ intérêt des méthodes agiles est justement de découper le projet en petites tâches plus faciles
à planifier et à tester. Ces tâches sont appelées des “Stories” car elles sont écrites de manière à raconter une histoire.
b. Les Stories
Rappelez-vous de la première valeur du Manifeste : “Les individus et leurs interactions sont plus importants que les
processus et les outils”. L‟ utilisateur est au cœur des méthodes agiles. Notre objectif, en tant qu‟ équipe de développement,
est donc de créer un programme qu’il utilise vraiment. Avoir en tête l‟ utilisation de l‟ outil, plus que le nom d‟ une
fonctionnalité, nous aide à garder en tête ce qui doit effectivement être produit.

Une Story est une action réalisée par l’utilisateur dans un certain but. Par exemple : “Linda veut cliquer sur “se
connecter” pour accéder à son compte”.
La première tâche est donc de découper une fonctionnalité en Stories. Dans notre cas, ça pourrait être :

• “Linda veut cliquer sur “se connecter” pour accéder à son compte.”
• “Linda veut cliquer sur “mon compte” pour voir ses informations personnelles.” “Linda veut cliquer
sur “modifier mes informations” pour changer son mot de passe.”
• etc.

Support : Cours de gestion de projet informatique Professeur : M. Abou Jean-Baptiste : Ing Informaticien
2
7
 Année Académique : 2024- 2025 2 ème Année BTS IDA Ecole : IES LE CAMPUS COCODY

c. Écrire une User Story

Vous avez peut-être remarqué que j‟ ai construit mes phrases selon le même modèle.
“<En tant que>, je veux <faire une action> pour <résultat de l‟ action>”.

En anglais, ce modèle s‟ appelle “As… I want… so that…”. La formulation vient de Mike Cohn, dans son ouvrage User
Stories Applied, et est très en vogue.
Écrire ses User Stories en suivant ce modèle vous permet d‟ être pragmatique et de visualiser très rapidement qui
effectue l‟ action, l‟ action en elle-même et le résultat attendu.

Une User Story raconte une histoire et peut être réalisée en un sprint. La notion nous vient de l‟ Extreme Programming.
Un des cofondateurs de la méthode, Ron Jeffries, propose d‟ ailleurs les trois caractéristiques suivantes :

• La carte : toute User Story est représentée par une carte.

• La conversation : le titre de la carte raconte une histoire.
• La confirmation : le contenu de la carte détaille le résultat attendu et donc le moment où nous pouvons indiquer
que la story est terminée.

Vous pouvez ajouter d‟ autres détails importants dans la carte, comme des sous-tâches techniques par exemple.
Il existe trois types de story :

 Les stories techniques (core)

 Les défauts (bug).

 Les user stories,

Il faut parfois réaliser des modifications dans un système dans le but de l‟ améliorer lui-même ou de réparer des bugs, pour
autant ce sera transparent pour l‟ utilisateur. Nous ne pouvons donc pas écrire de User Story et allons préférer une autre
typologie.

Support : Cours de gestion de projet informatique Professeur : M. Abou Jean-Baptiste : Ing Informaticien
2
8
 Année Académique : 2024- 2025 2 ème Année BTS IDA Ecole : IES LE CAMPUS COCODY

d. Définir un planning
Chaque Story inclut également une estimation de sa complexité en nombre de points. Elle est calculée en équipe pendant un
“planning poker”.

Concrètement, le Scrum Master distribue un paquet de cartes à chaque développeur. L‟ équipe pose des questions sur le
contenu de la story puis chaque membre montre, en même temps, son estimation. L‟ équipe en discute et mise sur un chiffre.
Puis elle propose un planning. Évidemment, plus une story est complexe et plus il sera compliqué de prévoir la date de
livraison. C‟ est pourquoi nous utilisons la suite de Fibonacci et non une suite linéaire.
Un membre se propose alors de réaliser la story et en devient responsable.

e. Découper en tâches
Le responsable de la story la découpe en tâches. Chaque tâche est un jour de travail. Si nous résumons, un sprint a une ou
plusieurs stories qui ont elles-mêmes plusieurs tâches.
Quand tout ceci est prêt, nous pouvons commencer le sprint !

f. Développer une story Les étapes

Chaque story suit les mêmes étapes qu‟ un projet séquentiel mais à son échelle ! C‟ est-à-dire :
écriture des spécifications fonctionnelles, écriture des spécifications techniques, tests et code
Les spécifications fonctionnelles forment le manuel utilisateur. Commencer par détailler comment l‟ utilisateur se servira
du programme aide le développeur à éclaircir toutes les étapes du développement. Ces spécifications sont souvent moins
détaillées que dans le cadre d‟ un projet séquentiel.
Les spécifications techniques forment la documentation technique et sera très utile à toute l‟ équipe.
Coder et tester. Une bonne pratique de développement dans un projet agile est de commencer par écrire les tests puis
d‟ écrire le code qui les valide. Il s‟ agit du Test Driven Development (TDD pour les intimes). C‟ est un mode de pensée
très différent mais extrêmement puissant.
Les tests en agile sont très similaires à ceux utilisés dans les méthodologies séquentielles (tests unitaires et d‟ intégration).
Laissez-moi vous présenter un petit nouveau : le test de confirmation.

g. Les tests de confirmation

Vous souvenez-vous des trois caractéristiques d‟ une story ? Carte, conversation et confirmation. Nous n‟ avons pas encore
parlé de la dernière composante : la confirmation. En effet, comment le développeur peut-il être sûr que la story est terminée
? C‟ est le rôle du Product Owner de donner les conditions qui font que le développeur pourra passer à la story suivante.

Souvent, la confirmation coule de source car elle correspond à l‟ User Story. Quand “Linda veut cliquer sur “se connecter”
pour accéder à son compte.”, nous savons que la story est terminée quand elle peut effectivement le faire !
Mais quand la story est technique ou correspond à un bug, il peut être intéressant d‟ indiquer les conditions requises. Par
exemple : “Recevoir les données de l‟ API Google Maps”.

Souvent, nous y faisons référence en les appelant “ Tests de confirmation” car les développeurs font rarement la vérification
à la main. Tout comme en séquentiel, ils vont configurer un robot qui va, comme un grand, tester que le programme remplit
bien les conditions demandées.
Support : Cours de gestion de projet informatique Professeur : M. Abou Jean-Baptiste : Ing Informaticien
2
9
 Année Académique : 2024- 2025 2 ème Année BTS IDA Ecole : IES LE CAMPUS COCODY

h. La story est morte, vive la story !

Quand la story passe les tests de confirmation, elle est déclarée finie et son responsable la déplace dans la colonne “ Done”.
Puis il passe à une nouvelle story qui fait partie du sprint en cours ! Quand les stories prévues pour la release sont finies, on
met toutes les stories en ligne et on passe à un nouveau sprint.
En résumé, une story passe par les phases suivantes :
• Proposition : un jour, une personne suggère une nouvelle fonctionnalité.
• Acceptée : le Product Owner accepte la proposition et l‟ ajoute dans le backlog.
• Estimée : l‟ équipe estime la taille de la story.
• Prête : la story est écrite et estimée. Elle est en attente de développement.
• En cours : l‟ équipe est en train de la développer.
• Fini : elle est en ligne !

Les étapes peuvent être différentes selon les pratiques de chaque équipe.
La revue de code (Code Review) est une bonne pratique en développement informatique. Une personne de l‟ équipe relit le
code d‟ un autre membre et suggère des modifications ou pose des questions. Cela améliore la communication et la qualité
du code.

Bravo, vous en savez maintenant plus sur la gestion de projet ! En vérité, il vous reste tout un monde à découvrir.

Support : Cours de gestion de projet informatique Professeur : M. Abou Jean-Baptiste : Ing Informaticien
3
0