Mémoire de fin d'études par Thomas Thiebaudet Ecole IPSSI - Groupe IP-FORMATION Master 2 - Expert en Informatique et Systèmes d'Information / Gestion de projets en technologies de l'information 2017-2018

1. Comment mettre en place une gestion
de projet efficace dans une équipe
technique réduite ?
THOMAS THIEBAUDET
2017-2018

2. 2
SOMMAIRE
SOMMAIRE .............................................................................................................................. 2
AVANT-PROPOS ..................................................................................................................... 3
INTRODUCTION...................................................................................................................... 4
REMERCIEMENTS .................................................................................................................. 6
1. Gestion de projet et méthodologies................................................................................ 7
1.1. Une méthodologie adaptée....................................................................................... 7
1.1.1. Analyse des solutions existantes....................................................................... 7
1.1.2. Choix d’une solution ...................................................................................... 11
1.2. Un principe fondamental : la communication........................................................ 12
1.3. Pilotage du projet ................................................................................................... 15
1.3.1. Distribution des rôles...................................................................................... 15
1.3.2. Application des méthodes............................................................................... 17
2. Gestion de projet technique.......................................................................................... 20
2.1. Partage et portabilité .............................................................................................. 20
2.1.1. Analyse des solutions existantes..................................................................... 21
2.1.2. Choix de la solution........................................................................................ 22
2.2. Conduite des versions ............................................................................................ 24
2.2.1. Choix d’un logiciel de versions...................................................................... 24
2.2.2. Choix d’une interface graphique de gestion ................................................... 25
2.2.3. Etablissement des conventions ....................................................................... 27
2.3. Stratégie de développement ................................................................................... 29
2.4. Intégration continue et livraison continue.............................................................. 31
2.4.1. Intégration continue........................................................................................ 32
2.4.2. Livraison continue .......................................................................................... 34
CONCLUSION ........................................................................................................................ 36
ANNEXES ............................................................................................................................... 37

3. 3
AVANT-PROPOS
Développeur web passionné, je me suis formé dans un premier temps et depuis
mon plus jeune âge de manière autodidacte au développement. C’est en 2014 que j’ai décidé de
donner des ailes à cette première expérience amateur en intégrant tout d’abord une formation
de niveau Bac + 2 à l’AFPA de Chevigny St-Sauveur (Côte d’Or). J’ai également pu effectuer,
durant ce temps d’apprentissage, un stage de trois mois chez MB Salon, magasin de mobilier et
décoration, afin d’y développer un back-office dédié à l’administration de l’entreprise.
Fort de cette expérience professionnelle, j’ai par la suite intégré, en 2015, le Mastère-
Développement Web Et Mobile de l’école IPSSI de Paris XIIème.
Je travaille actuellement pour l’entreprise Aérocontact, premier réseau professionnel
aéronautique et spatial. Aérocontact, en pleine expansion, dispose d’un portail dédié, spécialisé
dans l’actualité mais également dans l’emploi de l’industrie aéronautique, spatiale et de la
défense.
Au sein de cette entreprise, certains constats structurels, qu’il convient maintenant de
présenter, ont largement participé de la genèse de ce mémoire. Le premier de ces constats est
celui de la trop grande part d’intervention humaine tous les processus de développement, qui
conduit par conséquent à une probabilité d’erreurs trop grande, qu’il convient donc de réduire.
De plus, j’ai pu constater que le code des applications internes à l’entreprise jusqu’alors
développé était illisible du fait de l’absence de toute convention. La mise en place de
conventions m’a alors paru plus que nécessaire afin de gagner en efficacité. Enfin, sur une
période de plus de 13 années, aucune documentation n’avait été rédigée concernant les
programmes et applications développés en interne, ce qui n’assure pas la pérennité du système.
Fort de ces constats, j’ai pu cerner l’urgente nécessité d’établir un axe de bonnes pratiques,
de manière à allier bon niveau de collaboration entre développeurs et accessibilité dans le long
terme du code ; et ce, dans le cadre d’un projet en effectif technique réduit.

4. 4
INTRODUCTION
A l’aube d’une nouvelle ère axée sur la gestion de projet et à la suite de différents
constats que nous avons pu faire lors de nos différentes expériences au sein de l’entreprise
Aérocontact, il nous a semblé évident voir nécessaire de traiter ce sujet ; de la gestion de projet
efficace
Il convient tout d’abord de définir les différents éléments de notre sujet. Le thème
central de ce dernier est celui de la « gestion de projet ». Mais, plus que cela, il s’agit pour nous
de traiter de l’efficacité de cette dernière en équipe réduite.
La question de l’efficacité recouvre deux réalités. D’une part, il nous faut entendre,
par « gestion de projet efficace », une gestion de projet organisée et structurée, c’est-à-dire une
gestion de projet qui permet à tout collaborateur et en toute circonstance d’avoir des repères en
son sein. D’autre part, l’efficacité de la gestion de projet doit également être perçue, dans la
finalité-même du projet, comme une efficacité en termes d’incrémentation de livrable.
Il est alors indéniable que la gestion de projet en cycle court fera partie d’un requis non
négligeable de notre part dans notre implication à piloter de manière efficace le projet.
« Efficace », également, grâce aux différents outils et moyens mis en œuvre pour assurer
une base solide de communication au sein-même du projet.
Après avoir défini ce que qualifiera notre projet, jetons un œil au périmètre de celui-ci.
Le projet se veut adaptable à une équipe technique réduite. Mais pourquoi à une équipe
technique réduite ?
Il se trouve que mon poste actuel constitue cinquante pour cent de l’équipe technique
dédiée à Aérocontact. Pour le dire plus simplement, nous ne sommes que deux collaborateurs.
Parallèlement à ça, moins de ressources humaines ne veut pas dire que cela devrait être à
négliger. Il est important de jouir pleinement d’une petite ou d’une grosse équipe, dans le but
d’en exploiter l’intégralité de son potentiel. Nous axerons donc ce mémoire dans une gestion
de projet en équipe technique réduite et pour plus de clarté, nous aimerions préciser que nous
aborderons cette notion d’équipe réduite comme étant constitué d’un ensemble de trois
collaborateurs environ.

5. 5
Pour répondre à notre questionnement, nous consacrerons une première partie de ce
travail à la gestion et à la tenue d’un projet, à son pilotage et sa manière de fonctionner dès lors
que nous aurons analyser un panel de solutions existantes.
Puis, nous nous intéresserons à la gestion d’un projet technique. Il est primordial dans
l’organisation d’un projet, d’en connaître les tenants et les aboutissants, mais également de ne
pas ignorer les phases techniques qui la composent. En effet, si la phase de développement est
bien élaborée alors la productivité de l’équipe technique sera à son climax et plus rien ne pourra
arrêter un tel projet.

6. 6
REMERCIEMENTS
Arrivé au terme de ces trois années de formation au sein de l’école IPSSI, c’est avec
une certaine émotion et une certaine nostalgie anticipée, que je profite de l’occasion qui m’est
donnée, à la rédaction de ce mémoire, pour remercier, non seulement celles et ceux qui ont
permis, par leur soutien inconditionnel ou leur contribution, l’élaboration de ce travail ; mais
également toutes celles et ceux qui m’ont accompagné et porté tout au long de mon parcours.
Je tiens tout d’abord à adresser mes plus sincères remerciements, pour leur
engagement et la confiance qu’ils ont su m’accorder, à toute l’équipe de l’entreprise
Aerocontact ; et en particulier à mon employeur, Frédéric Vergoz et à mon collègue, Renaud
Fayolle, pour leur indéfectible soutien et la mise en partage de leurs compétences respectives.
Je souhaite également remercier l’école IPSSI qui m’a permis d’entreprendre - à une étape
cruciale de ma vie - une formation de qualité, gage d’un avenir professionnel aussi stimulant
qu’enrichissant. Merci à l’ensemble des intervenants de l’école, pour leurs compétences, leur
notion du partage et la foi qu’ils ont su placer en nous. Mes remerciements les plus sincères à
toute l’équipe de l’école IPSSI, et tout particulièrement à Vincent, qui m’a mis en relation avec
l’entreprise Aerocontact et sans qui, rien de cette belle aventure n’aurait été possible ; à
Magalie, formatrice-coordinatrice, pour son implication à toute épreuve dans la formation et
enfin à Murielle et à Edwige, pour leur sourire et leur bienveillance de chaque jour.
Mes remerciements les plus affectueux à mes collègues de formation, pour tout ce qu’ils
ont pu m’apporter tant sur le plan professionnel que personnel. Je remercie tout particulièrement
Nicolas Grévin et Anthony Lemprière ainsi que Ruby, sa compagne, pour m’avoir ouvert leur
porte pendant plus de deux ans lorsque les chemins de la vie m’ont amené à quitter la région
parisienne.
A ma mère, qui m’a toujours soutenu dans mes choix professionnels comme personnels,
merci.

7. 7
1. Gestion de projet et méthodologies
Dans une approche en gestion de projet et en méthodologies, on trouve des
centaines de façons de faire et ce dans d’innombrables références. Il y en a pour tout type de
projet, avec des approches toutes différentes, même si certaines sont plus ou moins semblables
en certains points.
Quand on parle de gestion de projet on fait référence à plusieurs éléments. Tout d’abord
un cadre organisé dans lequel est défini des règles, des processus, des manières de travailler,
des outils mais aussi des ressources humaines qu’elles soient internes ou externes au projet en
lui-même.
Dans un premier temps nous allons porter notre attention sur les différentes
méthodologies de projet, de façon à en sélectionner une qui permet de travailler avec une équipe
technique réduite ; puis nous examinerons, dans un second temps, la manière de communiquer
efficacement tout au long d’un projet. Pour terminer, le troisième point sera consacré, lui, au
pilotage du projet, c’est-à-dire à son organisation, ses différents processus de fonctionnement,
ses parties prenantes, ses différents rôles, etc.
1.1. Une méthodologie adaptée
De manière à aborder la gestion de projet dans sa globalité, nous examinerons dans
le prochain chapitre un panel de solutions existantes afin d’acter l’état de l’art en méthodologies
de projet. Dans le chapitre suivant, nous choisirons un axe de gestion de projet à intégrer dans
cette dernière de façon efficace et dans une équipe technique réduite.
1.1.1. Analyse des solutions existantes
L’analyse qui suivra prendra en compte quatre méthodologies de projet, deux
d’entre elles sont basiques et existent depuis que la gestion de projet est née tandis que les deux
autres sont plus spécifiques et aussi plus récentes dans le temps.

8. 8
Les méthodes traditionnelles sont utilisées depuis que la
civilisation pilote des projets que ce soit pour édifier des
pyramides ou rédiger un bilan comptable. Les tâches sont
définies en amont puis réalisées les unes à la suite des autres. Le
projet est terminé lorsque l’ensemble des besoins énoncés a été
réalisé et strictement comme il avait été défini.
Si cette méthode d’approche traditionnelle a fait ses preuves en remplissant, le plus
souvent son cahier des charges, c’est qu’effectivement il s’agit d’une méthode de projet
efficace. Malheureusement, son mode de fonctionnement ne laisse pas la place à l’adaptabilité
et n’est surtout pas centré sur l’Humain mais sur la finalité du projet en lui-même.
LES POINTS FORTS LES POINTS FAIBLES
- Cahier des charges rempli
- Utilisé depuis toujours
- Pas d’adaptabilité
- Pas prédisposé à l’Humain
Les méthodes adaptives sont elles aussi utilisées depuis très
longtemps et laisse place à l’adaptabilité. On pilote des projets
grâce à son système de fonctionnement pour s’adapter au marché
et à la concurrence mais aussi pour laisser une grande place à de
nouveaux besoins naissants.
Bien que l’adaptabilité soit l’un des avantages de cette méthode, il en est aussi le
talon d’Achille. En effet, à trop s’adapter, on peut en oublier son objectif final et il est très
compliqué et cela prend énormément de temps de redéfinir en permanence le but même du
projet.
D’un autre côté, son caractère modulable, voire évolutif, lui permet, dans certains cas de
rester leader de son marché ou encore de faire face à de nouveaux besoins ou de nouvelles

9. 9
nécessitées, telles que celle d’assurer une transition dans la diffusion de flux vidéo via la T.N.T.1
en 2005.
Ce n’est pas non plus une méthodologie axée sur l’Humain à cause, encore cette fois-ci
de sa trop grosse adaptabilité aux changements.
LES POINTS FORTS LES POINTS FAIBLES
- Adaptable à une ou plusieurs
situation(s)
- Fait ses preuves depuis longtemps
- Trop d’adaptabilité ne permet pas
toujours de remplir le cahier des
charges initial
- Pas prédisposé à l’Humain
Les méthodes agiles se veulent, paradoxalement, plus efficaces
et moins rigides. Cette méthodologie est plus récente est et fait
partie d’une tendance du marché 2018. Elles offrent plus de
flexibilité et une meilleure visibilité dans la gestion du projet.
Les méthodes s’exécutent dans plusieurs cycles courts où le
projet principal est découpé en mini-projets. Le mise à
disposition des avancées est régulière et s’établit en fonction de
l’évolution du besoin-client.
A contrario des méthodes adaptives, ces méthodes sont flexibles et permettent de
s’adapter à un environnement bien précis, sans perdre l’objectif final. Etant découpé en mini-
projets, elles favorisent le travail collaboratif et permettent au développeur de travailler comme
il le souhaite dans les tâches qui lui sont assignées, sur une période courte d’environ deux
semaines à un mois.
1
Comprendre « télévision numérique terrestre ».

10. 10
Cette méthodologie de gestion de projet a fait naître plusieurs « frameworks2
» qui lui
sont propre, Scrum3
étant le plus connu et qui lui permettent d’ajuster aux besoins du projet la
façon de piloter ce dernier.
LES POINTS FORTS LES POINTS FAIBLES
- Flexible
- Plus de visibilité sur l’avancée du
projet
- Travail collaboratif mis en avant
- Différents frameworks disponibles
- Plus de pression sur les parties
prenantes durant des cycles courts
Les méthodes PRINCE2 (PRojects IN Controlled
Environments, version 2) sont associées à un projet structuré,
pragmatique et adaptable et peuvent être utilisées pour tous
types de projet.
Cette méthode amène à l’utilisation de beaucoup plus de
conventions et de processus comme planifier, déléguer, et
contrôler les 6 grands aspects d’une gestion de projet
PRINCE2 : le coût, le délai, les bénéfices, la qualité, le
périmètre, les risques.
PRINCE2 possède trois avantages majeurs concernant la gestion de projet efficace
en équipe technique réduite. Il s’adapte à chaque projet et à beaucoup de situations. Il est très
organisé (peut-être trop) et assure de l’utilisation d’un grand nombre de processus.
2
« En programmation informatique, un framework (appelé aussi infrastructure logicielle1, cadre applicatif, cadre
d'applications, cadriciel, socle d'applications2 ou encore infrastructure de développement3) désigne un
ensemble cohérent de composants logiciels structurels, qui sert à créer les fondations ainsi que les grandes lignes
de tout ou d’une partie d'un logiciel (architecture). » (Wikipedia)
3
« Scrum est un schéma d’organisation de développement de produits complexes. Il est défini par ses créateurs
comme un « cadre de travail holistique itératif qui se concentre sur les buts communs en livrant de manière
productive et créative des produits de la plus grande valeur possible ». » (Wikipedia)

11. 11
En contrepartie PRINCE2 engendre de nombreux problèmes en gestion de projet :
en suivant les normes et conventions, trop de contrôles sont à effectuer dans de trop nombreux
processus. Les rôles et assignements sont beaucoup trop abondants pour être adoptés dans une
équipe technique réduite et le déploiement des mises à jour du projet ne se font pas en cycle
court, mais lors de phases propres à cette méthodologie, souvent très longues.
LES POINTS FORTS LES POINTS FAIBLES
- Multi-projet
- Projet structuré et organisé
- Adaptable
- De nombreux contrôles à effectuer
- Beaucoup de processus à gérer
- Trop de rôles à distribuer en équipe
technique réduite
- Pas de de gestion en cycle court
1.1.2. Choix d’une solution
Fort de ces quatre analyses, nous distinguons une méthodologie qui nous aiderait
dans la gestion de notre projet.
Les méthodes agiles nous assurent une livraison continue ; ce chapitre sera abordé, plus
tard, dans la partie 2. « Gestion d’un projet technique ».
Il est plus que clair, maintenant, que nous utiliserons la flexibilité d’agile, sa
visibilité sur l’avancée d’un projet, son travail centré collaboratif et l’ensemble de ses
frameworks disponibles et que nous travaillerons sur la pression éventuelle dont pourraient
souffrir certains acteurs de la réalisation technique.
Nous retiendrons que l’utilisation d’un cycle court de développement permet la diffusion
de modifications concernant l’utilisateur. Également, la visibilité du projet dans sa globalité
nous promet une lecture concrète de l’état du projet ; et ce, pour l’ensemble des collaborateurs.
Nous verrons plus en détail, lors du pilotage, du projet, les différentes manières d’allier
Agile à un projet et d’en implémenter le framework Scrum.

12. 12
1.2. Un principe fondamental : la communication
L’un des principes fondamentaux d’Agile, c’est bien de communiquer. On
communique sur ses avancées, on communique pour débattre, on communique par oral ou par
écrit ; mais surtout on communique !
Mais communiquer n’est pas suffisant, il faut aussi savoir le faire avec efficacité. Plus
que communiquer il faut savoir se faire comprendre et donc, bien sûr, être impliqué dans ce que
nous nous apprêtons à partager. On notera qu’un projet bien mené et efficace fera de la
communication un de ces piliers stratégiques dans une approche méthodologique en gestion de
projet.
Nous examinerons rapidement deux outils permettant de donner à un projet plus
d’efficacité, et ce par la manière dont les collaborateurs interagissent entres eux : Slack et
Trello, chacun assurant un aspect spécifique de cette gestion de projet.
Slack est une plateforme de communication propriétaire. Ce qui
est entendu par propriétaire c’est que Slack fournit une solution
entièrement et pleinement configurable autant par
l’administrateur que par l’utilisateur de l’application, pour le
compte d’une entreprise, d’une association, d’une cause, etc.
Slack permet la création de différents channels consacrés à des thèmes bien
spécifiques, l’utilisation de PM4
entre les collaborateurs et un système de notifications
paramétrable, Mais ce qui fait de Slack un des leaders du marché c’est le fait qu’il puisse se
connecter à d’autres logiciels de gestion de projet de manière à assurer une diffusion plus ample
d’informations que celles fournies par les différents utilisateurs.
On notera malheureusement que Slack est considéré comme très lourd pour n’importe
quel système d’exploitation. Par « lourd » nous entendons très nécessiteux en ressources, plus
précisément en ressources de mémoire vive. Bien évidement avec la configuration requise au
bon fonctionnement de l’application, un nouvel univers de communication s’ouvre à nous.
4
« PM » comprendre « Personal Message ».

13. 13
Cette plateforme est utilisée afin de partager une quelconque information avec
chaque collaborateur mais aussi de débattre sur différents points du projet, de brainstormer
quant à l’utilisation d’une nouvelle technologie, d’inviter ses collègues à boire un verre en fin
de journée, etc. C’est la solution en vogue et élue en 2017 comme tendance à suivre en tant
qu’outil adapté à la gestion de projet.
Trello est également un outil de gestion de projet disponible en
ligne. En l’utilisant comme accompagnement des méthodologies
Agiles il constitue la base centrale du travail à réaliser dans un
sprint5
pleinement distribué à travers l’ensemble des
collaborateurs.
Comme Slack, Trello est disponible en version gratuite comme
en version payante et intègre, elle, l’ensemble des
fonctionnalités disponibles sur toute l’application.
Cet outil est également connectable à d’autres solutions externes comme des mini-
plugins Scrum tels que le Planning Poker6
, de petits plugins, Jira7
et d’autres très grosses
solutions en gestion de projet.
On utilisera cette solution comme si nous utilisions des post-it, afin de garantir un
effet visuel compréhensible sur l’état d’avancée du projet. Sur chaque post-it, ou note, on
documentera un mini-projet, une fonctionnalité - par exemple - puis on détiller l’ensemble des
éléments constituant la réalisation de ce ticket. Chaque note est attribuée à un ou plusieurs
collaborateur(s) et nous définissons, lors de participations communes, le niveau de complexité
spécifique de la tâche à réaliser, dans le but d’en prévoir son temps de réalisation.
Trello est pleinement implémentable dans l’application Slack. Réservé à un chanel
bien précis, il permet efficacement de diffuser efficacement les différentes avancées de
l’ensemble ou d’un groupe de collaborateurs ; et ce, sans effort de leur part. En effet ils n’auront
5
« En développement logiciel, un sprint est un rassemblement de personnes impliquées dans un projet afin de
se concentrer sur le développement de ce projet. » (Wikipedia)
6
« Le planning poker est une façon ludique de produire des estimations sur la complexité de fonctionnalités à
développer. » (Wikipedia)
7
« Jira est un système de suivi de bugs, un système de gestion des incidents, et un système de gestion de projets
développé par Atlassian. » (Wikipedia)

14. 14
qu’à modifier leurs propres notes, déplacer d’état en état leurs avancées sur Trello pour que
l’intégralité de leur historique soit systématiquement reportée sur Slack.
D’autres applications sont intégrables à Slack et permettent le partage de fichiers
avec des services externes comme GitHub, Dropbox, Google Drive, Heroku et beaucoup
d’autres encore. Slack offre également une A.P.I.8
dédiée aux utilisateurs techniques. Celle-ci
donne un avantage non négligeable dans l’administration et la diffusion sur sa plateforme, de
messages personnalisés via l’intégration de simples scripts consumant cette dernière via leurs
serveurs de productions, de préproductions ou de tests.
Ce qu’il faut retenir de la communication en gestion de projet c’est que le plus
important n’est pas de définir des outils de communication mais de, premièrement,
communiquer et deuxièmement, le faire de façon compréhensive. Il revient à chaque partie
prenante d’établir dans son organisation, une part importante dans l’échange avec son ou ses
collaborateurs.
8
« En informatique, une interface de programmation applicative (souvent désignée par le terme API pour
application programming interface) est un ensemble normalisé de classes, de méthodes ou de fonctions qui sert
de façade par laquelle un logiciel offre des services à d'autres logiciels. » (Wikipedia)

15. 15
1.3. Pilotage du projet
Comme défini dans le chapitre 1.1, nous travaillerons avec une méthodologie Agile
mais qui s’adaptera à une gestion de projet en équipe technique réduite. Nous verrons alors de
quelle manière distribuer les rôles au sein de l’équipe et comment seront appliquer les méthodes
Scrum tout au long de notre projet.
Une dernière partie sera consacrée aux feedbacks9
et à leur importance dans un cycle
court de projet.
1.3.1. Distribution des rôles
Le framework Scrum ne définit que trois rôles et c’est ce qui va nous arranger dans
leur distribution :
- Le Product Owner10
porte la vision du produit à réaliser et se doit de travailler de pair
avec l’équipe de développement. Dans le cas d’une équipe réduite, et si son rôle ne peut
être affecté à une personne précise il est important de comprendre que ses missions ne
peuvent pas, elles, être oubliées. Son rôle principal étant de définir l’ensemble des
besoins sous forme de « User Story11
» ; et ce, afin de les mettre à disposition de l’équipe
de développement.
- L’équipe de développement est le deuxième rôle disponible avec Scrum. On notera
qu’elle est chargée de transformer les besoins exprimés par le Product Owner en
fonctionnalités. Les administrateurs réseaux, les développeurs, les graphistes et bien
d’autres encore font partie de l’équipe de développement.
9
« Rétroaction de l'information, dans un système cybernétique. » (Wikipedia)
10
« Le product owner – ou PO - est responsable de la définition et de la conception d'un produit. Il est chargé de
mener à terme un projet en utilisant la méthode scrum. Aussi appelé chef de projet digital, il est organisé et très
rigoureux. » (Wikipedia)
11
« Dans les méthodes agiles, un récit utilisateur ou user story est une phrase simple dans le langage de tous les
jours permettant de décrire avec suffisamment de précision le contenu d'une fonctionnalité à développer. »
(Wikipedia)

16. 16
- Le Scrum Master12
est la personne qui devra s’assurer que la méthodologie scrum est
correctement appliquée et s’apparente à un rôle de coach, à la fois auprès de l’équipe de
développement mais aussi auprès du Product Owner. Précisons également que la
distribution de son rôle en équipe technique réduite peut être problématique et, comme
pour le Product Owner, il convient de ne pas en oublier les missions au sein du projet si
son rôle est laissé vacant.
Il est effectivement compliqué de distribuer les rôles de Product Owner et de Scrum
Master si l’effectif de l’équipe ne le permet pas. Mais comme nous l’avons noté précédemment,
ses missions sont trop importantes pour être mises de côté alors. Il conviendra alors de s’adapter
à notre problématique et de redéfinir, au besoin, la mise en place des rôles.
Si aucun collaborateur du projet ne peut adopter le rôle de Product Owner, il conviendra
alors de définir les besoins « client » avec l’ensemble de l’équipe ; et ce, afin de créer un
Product Backlog13
. Il permettra ainsi à l’équipe de développement de commencer à établir
différents sprints pour amorcer leur travail.
Dans la même mesure, le rôle du Scrum Master sera distribué à travers toute l’équipe pour
ne pas perdre de vue l’application des méthodes à déployer, c’est-à-dire que chacun devra
participer collectivement et activement au rôle de ce dernier.
Même si cette méthode de distribution des rôles peut en gêner plus d’un, il est important
de rappeler que nous faisons face à une problématique technique en équipe réduite et que, dans
un esprit de communication et d’organisation, nous avons sélectionné les méthodes Agiles et,
plus précisément, le framework scrum comme base structurante de notre projet.
12
« Le maître de mêlée (scrum master) est responsable de la compréhension, de l'adhésion et de la mise en
œuvre du framework. » (Wikipedia)
13
« Pour résumer, le backlog scrum est destiné à recueillir tous les besoins du client que l'équipe projet doit
réaliser. Il contient donc la liste des fonctionnalités intervenant dans la constitution d'un produit, ainsi que tous
les éléments nécessitant l'intervention de l'équipe projet. » (https://www.nutcache.com/fr/archives/44421/)

17. 17
1.3.2. Application des méthodes
Dans cette partie, nous allons voir les différentes méthodes applicables grâce au
framework scrum et son principe de fonctionnement itératif au sein d’un projet.
Commençons par une représentation graphique de son organisation grâce à ce schéma.
Présentation de Scrum. Source : https://medium.com/arpinum/scrum-nest-pas-une-m%C3%A9thode-agile-4c077a71401
Le Product Backlog, vu précédemment, est la liste des exigences du produit. Le
Sprint Backlog est lui aussi une sélection de « User Story » mais à destination du prochain
sprint ou sprint en cours. Le sprint est le moment où l’équipe de développement travaille à la
réalisation des tâches réparties sur l’ensemble des collaborateurs sur une période de deux à
quatre semaines. Un Daily Stand-up14
, Stand-up meeting ou encore Daily Scrum est organisé
chaque jour dans l’objectif de mettre en commun les apports de chacun au produit. La fin d’un
sprint est potentiellement synonyme de création d’un livrable, constituant tout ou une partie du
produit final. C’est bien entendu le côté itératif des sprints et des Daily Stand-up qui nous
intéresse tout spécialement. En effet la gestion de projet I.T. en cycle court nous assure le
contrôle sur le livrable attendu et permet donc, au fur et à mesure des sprints, de s’adapter au
marché ou à de nouvelles exigences.
14
« Une réunion debout est une réunion à laquelle les participants participent généralement en position debout.
L'inconfort de rester debout pendant de longues périodes a pour but de garder les réunions courtes. »
(Wikipedia)

18. 18
Nous allons maintenant passer en revue deux points pour lesquels nous avons
sélectionner la solution Agile propulsé par Scrum : les méthodes de fonctionnement dans un
sprint et les Feedbacks durant le cycle du projet.
Voici un schéma détaillant la phase de sprint : une
première étape est dédiée à la planification, une autre
au développement et un ensemble de phases (Test,
Accept, Review) constitue l’intégration et la
livraison continue, abordées dans le chapitre 2.
« Gestion de projet technique ». On retrouve en
source le Backlog et en phase final un livrable
incrémental par chaque sprint.
Lors de la phase de planification on utilisera Slack et Trello afin de mettre nos
informations en commun et d’intégrer, aux différentes solutions, les différents tickets estimés
et associés à un collaborateur. Ces tickets permettent à l’équipe technique d’organiser le travail
entre collaborateurs durant la phase suivante, celle du développement. Grâce aux outils de
partage déployés, l’avancée des travaux et des missions sera mise à jour et diffuser à l’ensemble
des utilisateurs de ces deux plateformes. Nous remplissons donc notre approche efficace dans
une gestion de projet collaborative.
Les retours sur expérience dans Scrum. Source :
https://guntherverheyen.com/2017/10/20/closed-
loop-feedback-control-with-scrum/
Nous terminerons cette dernière partie par le retour
sur expérience et/ou information durant le cycle de
gestion de projet. Un Feedback constitue un
renseignement d’une extrême importance, il faut lui
donner de l’importance et la traiter en conséquence.
On prendra donc note que le retour d’un ou plusieurs collaborateurs en fin de sprint
est un élément qui pourra potentiellement influencer, voire modifier, le prochain sprint en
réactualisant par exemple le Backlog.

19. 19
Après avoir analysé la façon de choisir une méthodologie adaptée à notre
problématique et examiné les principes de fonctionnement de cette dernière nous analyserons
la partie technique de notre projet afin d’y apporter une base structurée et organisée.

20. 20
2. Gestion de projet technique
Maintenant que nous avons abordé la partie méthodologique d’une gestion de projet
efficace et adaptée à une équipe réduite voyons, étape par étape, quels sont les différents points
techniques à mettre en œuvre.
Dans une première partie, nous expliciterons l’importance du partage et de la
portabilité d’un projet I.T. dans une première partie Puis, nous examinerons les conduites à
adopter dans la gestion des versions d’une application. Dans un troisième temps, nous
consacrerons notre analyse à la spécificité de l’utilisation d’une même stratégie de
développement entre collaborateurs. Pour finir, nous passerons en revue les différentes
manières d’intégrer et de livrer, de façon continue, des portions du projet.
2.1. Partage et portabilité
L’un des points essentiels, dans un projet, est de pouvoir travailler sur une même
base solide et cela dans un environnement de développement identique. Chaque collaborateur
doit avoir accès à une même documentation sur une même stack15
à utiliser dans le
développement des différentes phases d’un projet technique. On notera que l’uniformité d’une
base de développement est plus qu’essentiel : les mêmes versions des logiciels, applications,
serveurs, langages de programmation seront utilisées de façon unilatérale par toute l’équipe de
développement.
Pourquoi aborder la question du partage et de la portabilité d’un projet technique ? Avançons
que cela réduit d’éventuelles erreurs liées à des configurations exotiques, et que cela augmente
la productivité du développeur. Cela permet également de réduire les délais lors de
l’initialisation du projet pour chaque collaborateur et cela nous assure un support identique pour
chaque poste de travail.
Plusieurs solutions existent pour assurer le partage et la portabilité d’un projet informatique.
Nous analyserons trois de ces solutions dans la première partie « Analyse des solutions
15
« stack » (Anglicisme informatique) Ensemble de composants logiciels nécessaire à une application web
(Wiktionary)

21. 21
existantes » puis nous déterminerons dans le deuxième point « Choix de la solution » la solution
la plus adaptée dans le cadre d’une équipe technique réduite.
2.1.1. Analyse des solutions existantes
L’utilisation d’une machine virtuelle permettrait d’apporter une base
commune de développement. Malheureusement, il s’agirait là d’un
instantané d’un environnement et, en cas d’erreur, il serait plus
compliqué de revenir à une version fonctionnelle. De plus, e poids d’un
projet dans une machine virtuelle est conséquent et peut dépasser le
gigaoctet de données.
LES POINTS FORTS LES POINTS FAIBLES
- Multiplateforme - Instantané d’un environnement
- Lourd à partager
- Rollback compliqué en cas de
problème
- Configuration manuelle
Vagrant est un logiciel axé sur la création et la configuration
d’environnements de développement virtuels. Il est considéré comme
étant un « wrapper », ou « adapteur », des logiciels de virtualisation.
Le poids d’un projet est relativement correct avec quelques centaines
de mégaoctets de données. Cependant, le temps de lancement d’un
projet peut être problématique puisqu’il peut dépasser plusieurs
minutes.
LES POINTS FORTS LES POINTS FAIBLES
- Multiplateforme - Lancement du projet relativement
long

22. 22
- Configuration automatique via des
fichiers
- Rollback possible
- Des milliers d’images disponibles
- Construction du projet très long
- Syntaxe de construction des fichiers
de configuration spécifique à Vagrant
- Dépendant d’une machine virtuelle
Docker est un logiciel complet permettant la création de conteneurs
logiciels afin d’y héberger des applications. Son système est plutôt
simple à prendre en main et nous assure une construction et un
lancement du projet très rapides grâce à ses quelques mégaoctets de
données.
LES POINTS FORTS LES POINTS FAIBLES
- Multiplateforme
- Très léger
- Non dépendant d’une machine
virtuelle
- Syntaxe de construction des fichiers
de configuration native d’un système
UNIX
- Des milliers d’images disponibles
- Quelques éléments non compatible
Windows.
2.1.2. Choix de la solution
Après avoir analysé les bénéfices et les limites de ces trois solutions il est important
de rappeler les besoins et les objectifs de notre gestion de projet. Nous souhaitons une gestion
de projet « efficace » mais aussi dans un périmètre bien précis, celui d’une équipe technique
réduite. Ce que nous entendons par efficace dans le choix d’une base de développement va se
traduire par la rapidité, le support en cas de problème, la facilité de partage du projet et la
dimension multiplateforme de la solution.

23. 23
A première vue, il semblerait que l’utilisation d’une machine virtuelle a plus de points
négatifs que positifs :
- La rapidité de la solution ne convient pas à ce que nous avons défini.
- La facilité du partage est rendue difficile à cause du poids de la machine virtuelle en
elle-même.
Concernant Vagrant by HashiCorp, il semble s’agir d’une solution qui nous
permettrai une bonne portabilité du projet via les fichiers de configuration spécifiques à la
création d’une machine virtuelle accueillant un environnement de développement optimal au
partage. Malheureusement, sa dépendance aux logiciels de virtualisation le rend très lent tant
au lancement d’un projet que dans son utilisation de tous les jours. En effet chaque modification
de configuration implique de recréer un environnement entier. Cette solution est bien portable
mais perd de son efficacité avec le temps mis en œuvre pour son instanciation.
Docker est une des solutions les plus populaires pour la création d’environnement de
travail et fait ses preuves depuis 2013. Ce gestionnaire de conteneurs est facile à manipuler,
rapide d’utilisation et très simple à partager. En effet des milliers d’images existent déjà sur
DockerHub16
et concernent de nombreux environnements de développement différents et
spécifiques.
Vagrant et Docker étant des solutions plus ou moins similaires, un tableau comparatif
entre ces deux solutions est placé en annexe (Annexe n°1).
Pour conclure, il semble que, dans le but d’assurer une gestion de projet technique
portable et efficace, le choix de Docker soit, du fait de ses nombreux atouts, le plus évident.
16
« DockerHub » est la plus grande librairie de conteneurs au monde.
(https://www.docker.com/products/docker-hub)

24. 24
2.2. Conduite des versions
Il est essentiel, pour gérer un projet technique, de gérer les différentes versions
d’une application ou plus généralement d’un système informatique. Il appartient aux différents
collaborateurs de versionner eux-mêmes leurs avancées et de s’assurer de la bonne
collaborativité de leur travail. Avant d’aborder les conventions à mettre en place pour travailler
main dans la main avec son ou ses collaborateurs dans le chapitre 2.2.3. « Etablissement des
conventions », nous étudierons un premier choix possible, celui d’un logiciel capable de gérer
les versions d’un programme. Notre deuxième partie sera consacrée au choix d’une interface
graphique nous permettant d’avoir un rendu visuel, et qui peut nous assister de manière efficace
dans certains cas de figure et à certaines étapes de versionnement.
2.2.1. Choix d’un logiciel de versions
Plusieurs dizaines de logiciel de versions existent et certains ont leur « spécificité ».
Par spécificité nous entendons le type principal du système de versionnement, à savoir s’il est
ou non décentralisé. S’il est « décentralisé » l’outil permet un travail désynchronisé et offre le
moyen aux développeurs d’échanger leurs travaux entre eux.
Un des leaders de logiciel de versions centralisé est SVN17
disponible en licence
APACHE18
. A l’inverse le plus populaire et utilisé par plus de douze millions de personnes est
GIT. Contrairement à SVN, GIT est décentralisé, et requiert donc notre intérêt. D’une part, lors
d’un projet, les différents collaborateurs, qu’ils soient peu ou nombreux, ont besoin de travailler
à leur rythme. D’autre part, ils ont également besoin de pouvoir diffuser simplement leurs
dernières mises à jour sur le projet en question.
En 2014, le nombre de personnes utilisant GIT a dépassé le nombre de personnes utilisant
SVN. Donc que :
- Le côté décentralisé des logiciels de versions devient leader.
17
« « SVN » Subversion (en abrégé svn) est un logiciel de gestion de versions. » (Wikipedia)
18
« « APACHE » La licence Apache est une licence de logiciel libre et open source. » (Wikipedia)

25. 25
- GIT est le logiciel de versionnement le plus utilisé dans des projets open-source19
depuis.
Pourcentage d'utilisation de GIT et SVN de 2009 à 2014. Source : Eclipse Community Survey de 2014
Fort de ces constatations, il devient évident d’inclure GIT comme gestionnaire de
versions dans notre gestion de projet. Adapté à une équipe réduite grâce à sa décentralisation,
il est aussi efficace par sa stabilité et est utilisé par tous et partout dans le monde.
2.2.2. Choix d’une interface graphique de gestion
Versionner ses programmes pour mieux gérer une phase du projet semble suffisant.
Toutefois l’implémentation d’une interface graphique permet de gagner en efficacité dans la
gestion de ses versions.
Ce type d’interface s’accommode d’un rendu visuel prenant en compte l’ensemble des
éléments de versions et permettant de gagner du temps lors des contrôles que les développeurs
auraient sur leur historique de versionnement. On y retrouve les différents schémas de versions
19
« « open-source » est un programme informatique dont le code source est distribué sous une licence
permettant à quiconque de lire, modifier ou redistribuer ce logiciel. » (https://www.1min30.com/dictionnaire-
du-web/open-source-logiciel)

26. 26
par projet : les branches distinguant les environnements et le détail de l’ensemble des
modifications leur étant apporté.
Trois types d’interface sont disponibles : les interfaces de bureau, les interfaces en
auto hébergement et les interfaces hébergées sur site web. Passons en revue ces différentes
interfaces graphiques de gestion de versions.
- Les interfaces de bureau permettent, grâce à l’installation d’un exécutable sur un poste
de travail, de profiter visuellement d’indicateurs visuels sur l’état des fichiers. Il permet
aussi, grâce à ses raccourcis intégrés au menu (accessible avec le clic-droit), de changer
de branche ou de partager son travail sur le dépôt20
associé au projet. Malheureusement,
les interfaces de bureau ne sont pas multiplateformes et sont non-collaboratives mais
peuvent être utilisées en plus d’une interface graphique disponible, via un site internet,
afin de modifier l’apparence de l’explorateur de fichiers.
- Les interfaces en auto hébergement sont des solutions à déployer soi-même sur des
serveurs dont nous sommes propriétaires et assurons personnellement la maintenance.
Elles nous permettent de naviguer sur différents projets, d’accéder de façon intuitive
aux différentes versions d’un programme, de confirmer des fusions d’une branche à une
autre ou même d’en créer soi-même à partir d’une branche existante. Les interfaces en
auto hébergement sont livrées avec de nombreuses fonctionnalités : plugin de
documentation, suivi des bugs, CI/CD21
, etc. La partie intégration continue et livraison
sera détaillée dans le chapitre 2.4 « Intégration continue et livraison continue » afin
d’optimiser et d’automatiser certains processus afin de gagner en temps de contrôle et
de déploiement en limitant les erreurs humaines.
- Les interfaces hébergées sur site web sont sensiblement, voire totalement, aux solutions
en auto hébergement. Il s’agit principalement de ces mêmes solutions hébergées sur le
20
« « dépôt » En informatique, un dépôt ou référentiel, est un stockage centralisé et organisé de données. »
(Wikipedia)
21
« CI/CD » en référence à « continuous integration » et « continuous delivery » à savoir « intégration continue »
et « livraison continue ». (Wikipedia)
« L’ « intégration continue » est un ensemble de pratiques utilisées en génie logiciel consistant à vérifier à chaque
modification de code source que le résultat des modifications ne produit pas de régression dans l'application
développée. » (Wikipedia)
« La « livraison continue » est une approche d'ingénierie logicielle dans laquelle les équipes produisent des
logiciels dans des cycles courts, ce qui permet de le mettre à disposition à n'importe quel moment. Le but est de
construire, tester et diffuser un logiciel plus rapidement. » (Wikipedia)

27. 27
site web de l’entreprise les développant (N.B. : GitHub, GitLab, etc.) En général ces
interfaces sont gratuites pour les projets open-source et payantes pour les dépôts privés.
Le véritable choix d’une interface graphique se fera véritablement en fonction des
préférences personnelles et des ressources dont on dispose. Plus personnellement nous avons
opté pour la solution GitLab CE22
en auto hébergement sur un VPS dont nous disposions. Les
configurations requises pour héberger le Server GitLab sont intégrées en annexes (Annexe n°2).
2.2.3. Etablissement des conventions
Concernant la manière de procéder lorsque qu’il s’agit de versionnement il est
préférable de partir sur une base commune pour chaque collaborateur. On distinguera deux
grandes catégories de conventions, permettant ainsi un travail soigné et compréhensible pour
d’autres développeurs : les conventions de nommage et les conventions de fonctionnement.
- Les conventions de fonctionnement vont guider les collaborateurs dans leur façon de
versionner. Il y a des dizaines de façon de procéder, d’agir sur les versions, le plus
important étant d’adopter, chacun, le même mode de fonctionnement. Pour notre part,
nous utilisons la branche Master comme tronc commun et la branche Develop comme
base intermédiaire ; viennent ensuite s’ajouter les différentes Features de notre projet.
Nous reverrons en détail cette façon de fonctionner dans le chapitre 2. 4. « Intégration
continue et livraison continue ».
22
« « GitLab CE » GitLab est un gestionnaire Web de référentiels Git fournissant des fonctionnalités de wiki, de
suivi des problèmes et de pipeline CI / CD, utilisant une licence open source, développée par GitLab Inc. »
(Wikipedia)

28. 28
Elaboration d’une stratégie de versionnement. Source : Grafikart (https://www.grafikart.fr/tutoriels/divers/git-workflow-478)
- Les conventions de nommage permettront eux d’organiser les différentes versions du
programme et ce de façon lisible et compréhensible pour tous. Comme pour les
conventions de fonctionnement il existe aussi autant de convention de nommage et
comme pour ces derniers le plus important étant que les collaborateurs s’appuient tous
sur les mêmes conventions. Pour ma part je m’appuie sur des conventions de nommage
instaurées par une communauté de développeurs Android. Ainsi le nom de mes branches
est typé en fonctionnement de son état : un correctif (fix), une nouvelle fonctionnalité
(feat), un test (test), etc. La syntaxe du nom de ma branche est définie comme
type/branch-name et le nom du commit comme type(branch-name) action on this
branch. En soit, c’est une façon simple de procéder et garantissant une bonne lisibilité
pour toutes les personnes qui pourront consulter les différentes versions d’un
programme sur une plateforme comme GitLab.

29. 29
2.3. Stratégie de développement
Après avoir analyser le choix de l’environnement de développement et celui des
versions intéressons-nous à ce qui pourrait constituer une stratégie de développement qui se
veut efficace, collaborative et adaptée à équipe technique réduite.
Analysons les cinq points fondamentaux dans l’élaboration de cette stratégie.
Le premier pilier d’une stratégie de développement efficace est de définir des règles
et des façons de procéder dans la conception de programmes informatiques. Plusieurs
conventions existent déjà et ont été créées par des communautés I.T. à travers différents
langages de programmations. On y trouve par exemple les PSR23
de PHP publiées par le PHO
Interop Group, assurant des standards aux concepts de développement en PHP. Vous pourrez
retrouver en annexe n° la liste des PSR disponibles.
Le but de la démarche consistant à standardiser la façon dont est écrit une application
permet une uniformité dans un projet composé de plusieurs développeurs. Leurs différents
apports possèdent une même structure et de ce fait rend les travaux de son collaborateur plus
accessible à la compréhension.
Le deuxième pilier, qui est le pendant du premier, est axé sur les commentaires à
apporter au code. Commenter son code ne sert pas seulement à la rendre lisible pour soi ou pour
les autres mais permet aussi au développeur, en amont, de comprendre et optimiser ce qu’il
s’apprête à développer. Il est très important de ne pas reporter cette étape à plus tard et de
commenter son code au fur et à mesure de l’écriture d’un programme.
Le fait de documenter ses développements constitue le troisième pilier d’une
stratégie efficace. Cette phase s’effectue à la fin du développement d’un programme précis et
référence de manière détaillée les tenants et les aboutissants de l’application. Si on choisit
comme solution d’interface graphique à ses versions un système auto hébergé ou hébergé sur
un site comme GitLab ou GitHub, il nous faut savoir que l’on dispose d’un Wiki24
pouvant être
intégré à chacun de ses projets. L’idée de cette documentation prend toute son importance
lorsqu’un développeur devra maintenir et/ou optimiser une application qu’il n’a pas conçu et
23
« PSR » PHP Standard Recommendation pour « Recommandation des standards de PHP ».
24
« Un wiki est une application web qui permet la création, la modification et l'illustration collaboratives de pages
à l'intérieur d'un site web. » (Wikipedia)

30. 30
qu’il ne connaît peut-être pas ou peu. Il pourra alors aller se documenter sur l’application en
elle-même dès qu’il en ressentira le besoin.
Le quatrième pilier, quant à lui, est centré sur le partage entre collaborateurs des
différentes avancées sur l’écriture ou la conception d’un ou de plusieurs programme(s). C’est
l’étape la plus simple à mettre en place. Il suffit de tenir à jour les tâches qui nous auraient été
attribuées. Dans l’idée où l’ensemble des missions est disponible à travers le « cloud
computing »25
chaque collaborateur pourra autant s’informer sur les avancées de ses collègues
que s’organiser dans son propre travail.
Pour finir, le cinquième et dernier pilier est consacré à la revue de code26
. Cette
technique de relecture doit être effectuée par un collaborateur différent et à un rythme régulier.
Cette approche permet d’assurer une meilleure robustesse à l’application en général mais aussi
de partager et enrichir ses compétences par l’annotation de certaines remarques sur des parties
du script. GitHub et GitLab permettent nativement d’ajouter à une Pull Request27
un reviewer.
Ce dernier peut ou non posséder des droits sur la relecture assignée. Il faut par ailleurs
préciser qu’il peut suspendre la Pull Request ou demander des correctifs sur une ou plusieurs
parties du script. Ce genre de fonctionnalité nous assure un contrôle efficace sur le code ; et ce,
tout au long de son cycle de vie.
25
« Le cloud computing, en français l'informatique en nuage consiste à exploiter la puissance de calcul ou de
stockage de serveurs informatiques distants par l'intermédiaire d'un réseau. » (Wikipedia)
26
« La revue de code (de l'anglais « code review ») est un examen systématique du code source d'un logiciel. »
(Wikipedia)
27
« (Programmation informatique) Demande de fusion de branches. » (Wikipedia)

31. 31
2.4. Intégration continue et livraison continue
Schéma d’une approche DevOps. Source :
https://www.pingflow.com/ 1
Lorsque nous parlons d’intégration et de
livraison continue, nous le faisons dans une
approche DevOps28
; son principe étant d’allier
le développement logiciel à l’administration
réseau. Ce mouvement vise à instituer une
automatisation des tâches dans le but de gagner
en efficacité en produisant de nouvelles
fonctionnalités, dans des cycles courts,
simplement et rapidement diffusables en ligne.
L’intégration continue29
, « Continuous Integration » abrégé CI, nous permet d’assurer
une non régression du système applicatif à chaque modification apportée par n’importe quel
développeur et fait donc partie d’une phase indispensable dans une gestion de projet efficace et
collaborative. Nous examinerons ce point dans le chapitre 2.4.1. « Intégration continue ».
Concernant la livraison continue30
, « Continuous Delivery » abrégé CD, elle rassemble
en grande partie les éléments d’intégration continue dans le but de les diffuser ; et ce pour mettre
en production l’ensemble des modifications apportées au code source d’une application. On
notera quelques ajouts notables de fonctionnalités à la livraison continue dans le chapitre 2.4.2
« Livraison continue ».
On note que ces deux types d’intégration, appelées couramment CI/CD,
fonctionnent de pair et ne sont pleinement utiles et exploitables que lorsqu’elles sont combinées.
Voici un schéma, dont la facilité de compréhension fait le mérite, qui permet
d’appréhender leur fonctionnement tout au long du cycle de vie de d’une application.
28
« Le « devops » est un mouvement en ingénierie informatique et une pratique technique visant à l'unification
du développement logiciel (dev) et de l'administration des infrastructures informatiques (ops), notamment
l'administration système. » (Wikipedia)
29
« L'intégration continue est un ensemble de pratiques utilisées en génie logiciel consistant à vérifier à chaque
modification de code source que le résultat des modifications ne produit pas de régression dans l'application
développée. » (Wikipedia)
30
« La livraison continue est une approche d'ingénierie logicielle dans laquelle les équipes produisent des logiciels
dans des cycles courts, ce qui permet de le mettre à disposition à n'importe quel moment. Le but est de
construire, tester et diffuser un logiciel plus rapidement. » (Wikipedia)

32. 32
Le label « Pull Request » fait référence à une demande d’un collaborateur de fusionner ces
modifications à une branche spécifique du projet tandis que le label « Déploiement » acte de la
diffusion de l’ensemble des nouvelles modifications vers des versions accessibles par
l’utilisateur.
Schématisation du cycle d’intégration via l’intégration continue puis la livraison continue du code source.
Examinons ensemble la façon d’établir une CI/CD performante de manière à
ajouter à notre projet une couche d’automatisation pour gagner en efficacité dans la gestion de
notre projet technique.
2.4.1. Intégration continue
Commençons par voir en détail le principe de fonctionnement d’une CI.
Schématisation d’une intégration continue. Source : http://igm.univ-mlv.fr/~dr/XPOSE2012/Int 1

33. 33
L’étape qui nous intéresse le plus sur ce schéma est la partie « Compilation +
Exécution des Tests ». Pour nous situer, nous nous trouvons entre l’envoi des modifications du
développeur sur le dépôt et la création d’éléments appelés « artéfacts31
». Ces éléments,
« artéfacts », sont le résultat d’une phase de compilation et d’une phase de tests. L’ensemble
des processus cités ci-dessus s’exécutent à l’intérieur d’un même élément appelé « pipeline32
».
Les phases automatisées d’un pipeline sont appelées « jobs », ils s’exécutent les uns après les
autres et mettent le pipeline en échec si un des jobs est en erreur. Un exemple de pipeline
d’intégration continue est placée en annexe n°3. Pour comprendre plus facilement comment
l’intégration continue se déroule, voyons en détail les différentes parties que compose le
pipeline d’intégration continue.
- Une phase de compilation appelée couramment « build » va effectuer afin de s’assurer
de la non régression du code par ces changements. A ce stade, nous attacherons une
attention particulière à la compilation du programme en tentant d’émuler33
l’application
entièrement.
Imaginons que le projet sur lequel nous travaillons est orienté développement web. Il
est alors fort probable que nous disposons d’un gestionnaire de dépendance et/ou d’un
gestionnaire de paquet. Dans ce cas précis, et durant cette phase de build, nous nous
assurons que l’ensemble des dépendances et paquets ne créé pas de conflit entre eux et
que, de ce fait, l’application a pu correctement être compilée.
- Une phase de tests ciblant le code source applicatif. Après avoir compilé notre
programme dans la première étape, il devient alors nécessaire de s’assurer que
l’ensemble du code source ne comporte pas de bugs. C’est au développeur de concevoir
ces tests tout au long de son travail de développement afin que ces derniers soient
automatisés durant cette phase précise. Chaque test vérifiera le bon fonctionnement
d’une partie précise d’un programme ou d’une portion de code. On trouve trois grandes
catégories de tests qui sont les tests unitaires, les tests fonctionnels et les tests
31
« En informatique, un artéfact computationnel est le résultat obtenu par l'homme par l'usage d'outils ou de
principes reliés aux domaines de l'informatique, du multimédia ou de la pensée computationnelle. Un artéfact
computationnel peut être un programme, un script, un microprocesseur, une image, un jeu, une vidéo, une page
Web, etc. » (Wikipedia)
32
« Un pipeline (ou chaîne de traitement1), est l'élément d'un processeur dans lequel l'exécution des instructions
est découpée en plusieurs étapes. » (Wikipedia)
33
« Émulation. ... En informatique, l'émulation consiste à substituer à un élément de matériel informatique – tel
un terminal informatique, un ordinateur ou une console de jeux – un logiciel. La définition du terme émuler est
« partir du principe que de pratiquer le même comportement ». » (Wikipedia)

34. 34
d’acceptance. Il est nécessaire de réaliser le plus de tests possibles sur l’ensemble afin
d’éviter d’éventuelles erreurs humaines ainsi que pour vérifier au mieux que
l’application ou le programme informatique est pleinement fonctionnel.
2.4.2. Livraison continue
L’étape de livraison continue est une extension de l’intégration continue qui permet
de diffuser l’ensemble des mises à jour d’un programme. Voici une un schéma représentant la
livraison continue.
Schématisation d’une livraison continue. Source : https://bigdatanerd.wordpress.com/2016/07/04/continuous-data-pipeline-
continuous-delivery-and-data-engineering/
Rappelons-nous que nous utilisons la CI/CD dans l’objectif principal de produire
des nouvelles versions dans des cycles courts. Il est alors important d’automatiser le
déploiement application dans l’intention de ne pas réitérer manuellement chaque processus que
constitue cette mise en production.
Cette étape reprend les phases de build et de tests de l’intégration continue et implémente
une nouvelle phase, celle du déploiement. On peut également y retrouver des jobs consacrés à
l’analyse systématique du code comme des « linters34
». Ils nous seront utiles pour détecter des
erreurs de codes, des problèmes de syntaxe et le non-respect du style défini (cf. 2.3. Stratégie
de développement). Un exemple de pipeline de livraison continue est placée en annexe n°4.
Examinons ensemble cette phase d’analyse statique du code et celle du déploiement d’une
application à jour.
34
« Un linter est un outil d'analyse statique de code source. » (Developpez.com)

35. 35
- La phase d’analyse du code via des linters n’est pas obligatoire mais son utilisation est
vivement conseillée dans la gestion de notre CI/CD. En effet, elle reprend des principes
vus précédemment dans la stratégie de développement par les conventions et
l’utilisation de normes, comme les PSR de PHP, afin de récupérer ces règles et de statuer
sur la bonne conformité du code.
- La phase de déploiement rassemble les artéfacts créés par les jobs de build et
l’instantanée de l’application afin de les diffuser sur un serveur de production pour être
accessible à l’utilisateur final. Dans le cas où on utiliserait aussi GitLab ou GitHub, il
faut savoir que de nombreux plugins sont disponibles afin de connecter son application
à des services de type « cloud computing », comme AWS de Amazon ou AppEngine de
Google, qui fournissent des solutions excellentes dans l’hébergement de son
programme, application, site internet, etc.
La confusion entre déploiement continu et livraison continue est courante et il
convient d’en expliciter la distinction. La seule différence c’est la manière de finaliser cette
mise en production : si la diffusion de l’application est automatique, alors on parle de
déploiement continu ; à l’inverse, si la diffusion nécessite une action manuelle et humaine, alors
on parle dans ce cas de livraison continue.

36. 36
CONCLUSION
Afin de conclure ce mémoire, qui prend pour origine mes trois années d’expérience
au sein d’une équipe technique réduite, j’aimerais revenir sur deux points, plus précisément sur
le choix d’une méthodologie en gestion de projet et sur les processus qui la composent.
La gestion de projet nécessite, certes, une structuration, une manière de fonctionner, une
certaine façon d’attribuer les rôles, mais le plus important à retenir c’est qu’il suffit d’adopter
dans son projet une certaine rigueur, de manière à piloter l’ensemble efficacement. On y
ajoutera des règles de fonctionnements, des conventions dans le travail collaboratif, des façons
d’agir et de partager, mais cela ne rend pas le projet entièrement dépendant d’une et une seule
même méthodologie.
De plus, les processus qui composent une gestion de projet doivent être réfléchis. Il est
inutile de les calquer à une quelconque méthode de travail déjà existante si elle n’assure pas
une cohérence dans l’objectif global de la livraison d’une valeur incrémentale.
Dans une approche de gestion de projet efficace en équipe réduite, il convient donc
d’établir une manière de fonctionner qui soit cohérente avec le projet en lui-même, sans en
oublier la communication, le fondement même d’un bon pilotage de projet.

37. 37
ANNEXES
Nom Comparaison des fonctionnalités de Docker et Vagrant
N° Annexe n°1
Référence En référence au chapitre 2.1 Partage et portabilité d’un projet
technique
Source https://objectcomputing.com/resources/publications/sett/march-
2015-docker-vs-vagrant

38. 38
Nom Configuration requise pour l’installation d’un serveur GitLab
N° Annexe n°2
Référence En référence au chapitre 2.2.2. Choix d’une interface
graphique de gestion
Source https://docs.gitlab.com/ee/install/requirements.html

39. 39
Nom Liste des PSR (PHP) disponibles
N° Annexe n°3
Référence En référence au chapitre 2.3 Stratégie de développement
Source https://www.php-fig.org/

40. 40
Nom Exemple de pipeline GitLab d’intégration continue
N° Annexe n°4
Référence En référence au chapitre 2.4.1. Intégration continue
Source Nicolas Grévin : https://blog.eleven-labs.com/fr/introduction-
gitlab-ci/

41. 41
Nom Exemple de pipeline GitLab de livraison continue
N° Annexe n°5
Référence En référence au chapitre 2.4.2. Livraison continue
Source Nicolas Grévin : https://blog.eleven-labs.com/fr/introduction-
gitlab-ci/