Rapport de stage de fin d'études - Capgemini Toulouse - INSA Hauts-De-France Sujet : Développement d’une application de «pricing » d’un acteur de l’énergie (1 équipe agile de 13 personnes) Outils utilisés : Intellij IDEA, Visual Studio Code, Oracle SQL Developer , Jenkins, SonarQube , Gitlab, MobaXterm , Jira, Confluence, travail en mode agile (SAFE).

1. INSA Hauts-de-France, Campus Mont Houy, 59313 Cedex 9, Valenciennes - France
Tél : +33 (0) 3 27 51 12 02 - Site web : www.uphf.fr/ISTV
Année Universitaire : 2020- 2021
UNIVERSITÉ POLYTECHNIQUE HAUTS-DE-FRANCE
INSA HAUTS-DE-FRANCE
Valoriser
Facturation Offres
Offres sur table de coût de sourcing
Estimer
Structure de prix
Indexation
Optimiser
Tarif sur Palette
Analyse des contrats
Puissance
Consommation
Clients
Taxes
Mark-up
Estimation Offres services & Services
Services
Avenants
Indexation
Dépôtde garantie
Offres sur Courbe de Charge
Devis
Profil de consommation
Site
Marges nettes
Reconduction
OffresGaz Reporting
Taux d’ARENH
Tarif acheminement
TURP
Offressurgrille
Conseiller
Valoriser
Facturation
Offres
Offres sur table de coût de sourcing
Estimer
Structure de prix
Indexation
Optimiser
Tarif sur Palette
Analyse des contrats
Structure de prix
Puissance
Consommation
Clients
Taxes
Mark-up
Estimation
Offres services & Services
Services
Avenants
Indexation
Dépôtde garantie
Offres sur Courbe de Charge
Devis
Profil de consommation
Site
Marges nettes
Reconduction
OffresGaz Reporting
Taux d’ARENH
Tarif acheminement
TURP
Offressurgrille
Conseiller
Facturation
Devis
Profil de consommation
OffresGaz
Tarif acheminement
TURP Taxes
Site
TURP
TURP
Offres
Structure de prix
OffresGaz
Application Pricing OpérationneL des Offres
Maintenance de l’application APOLO (Application de Pricing
Opérationnel des Offres)
Diplôme de Master
Filière : Ingénierie des Systèmes Embarqués et
Communications Mobile (ISECOM)
Niveau : 2ème année Master
Rapport de stage de fin d’études
➢ Encadré par :
▪ M. TIXIER Florent
▪ Mme. ZWINGELSTEIN Marie
➢ Réalisé par :
▪ DOUIEB Otmane

2. 1
Résumé
Dans ce rapport, je vais faire une présentation générale de l’entreprise et de projet, après
une présentation de l’équipe APOLO ONE à laquelle je suis rattaché.
Ensuite je présenterai la méthodologie de travail notamment la méthode SAFe, ainsi le
cycle de développement DevOps avec toutes ces étapes, et finalement je parlerai de quelques
tâches que j’ai réalisées pendant mon stage tel que l’ajout de l’authentification sur une
plateforme, la gestion et la remontée des erreurs et l’ajout d’un pipeline sur Jenkins.
Mots clés
Pricing, Agile, SAFE, DevOps, Java EE, Springboot, microservices.

3. 2
Remerciements
Ce travail résulte de la contribution de nombreuses personnes, que ce soit d’un point de
vue professionnel en m’apportant des connaissances et savoir-faire, ou personnel en faisant de
moi ce que je suis aujourd’hui. C’est pourquoi je voudrais, dans ce remerciement, dire quelques
mots de ces personnes. Ces quelques lignes ont pour but de leur exprimer toute notre
reconnaissance.
Tout d’abord, je tiens à remercier mon tuteur de stage Mr. TIXIER Florent qui m’a aidé
à s’intégrer avec l’équipe et être à côté de moi pour me soutenir durant mon stage, ainsi toute
l’équipe APOLO ONE.
Je voudrais aussi remercier mon encadrante Mme. ZWINGELSTEIN Marie habileté
d’enseignement supérieur à l’Institut National des Sciences Appliquées Hauts-de-France, qui
nous a apporté une contribution incalculable, ajoutant à son talent d’Encadrant, son savoir, son
expérience et sa rigueur scientifique ainsi pour sa confiance, sa motivation et ses conseils.
J’exprime également ma gratitude à l’égard des membres du jury pour qu’ils aient
accordé pour l’évaluation de mon projet de fin d’études en citant :
▪ Mr. GHARBI Mohamed : Professeur d’enseignement supérieur à l’Institut National des
Sciences Appliquées Hauts-de-France.
▪ Mr. DIDOUX Ahmed : Professeur d’enseignement supérieur à l’Institut National des
Sciences Appliquées Hauts-de-France.
Mes remerciements vont aussi à l’encontre de l’ensemble du corps professoral de
l’Institut National des Sciences Appliquées Hauts-de-France et plus spécialement notre
Responsable Pédagogique du Master Mr. DAYOUB Iyad ainsi le corps enseignant de la filière
ISECOM pour la qualité de l’enseignement qu’ils nous ont assurée et pour leurs efforts
permanents d’amélioration de la formation.

4. 3
Table des matières
Résumé ....................................................................................................................... 1
Mots clés..................................................................................................................... 1
Remerciements ............................................................................................................ 2
Liste des figures........................................................................................................... 4
Liste des abréviations ................................................................................................... 5
Introduction................................................................................................................. 6
Chapitre 1 : Présentation de l’entreprise et du projet........................................................ 8
Introduction................................................................................................................. 8
1. Présentation de l’entreprise ..................................................................................... 8
2. Présentation de projet APOLO ................................................................................ 8
2.1. Le projet APOLO..........................................................................................................................8
2.2. L’équipe APOLO ONE.................................................................................................................9
Conclusion .................................................................................................................. 9
Chapitre 2 : Méthodologie et tâches abordées ............................................................... 11
Introduction............................................................................................................... 11
1. Méthodologie ...................................................................................................... 11
1.1. Méthodologie SAFe (Scaled Agile Framework).........................................................................11
1.2. Cycle de développement & DevOps...........................................................................................15
1.2.1. Continuous FeedBack : Analyse, recueils, et mise à jour des données (MCO)..................16
1.2.2. Plan : Conception fonctionnelle..........................................................................................18
1.2.3. Build : Cycle de développement .........................................................................................19
1.2.4. Continuous intégration : Test et validation.........................................................................21
1.2.5. Deploy : Processus de déploiement ....................................................................................24
2. Réalisations......................................................................................................... 25
2.1. Ajout d’authentification pour QuoteX Simulation......................................................................25
2.2. Gestion des erreurs......................................................................................................................28
2.3. Ajout d’un pipeline sur Jenkins « DevOps » ..............................................................................30
Conclusion ................................................................................................................ 35
Conclusion générale ................................................................................................... 36

5. 4
Liste des figures
Figure 1: PI Planning (SaFe)--------------------------------------------------------------------------------------------------- 12
Figure 2: PI (SaFe)--------------------------------------------------------------------------------------------------------------- 13
Figure 3: Cycle de développement DevOps ------------------------------------------------------------------------------ 16
Figure 4: Board des instances------------------------------------------------------------------------------------------------ 17
Figure 5: Supervision MCO --------------------------------------------------------------------------------------------------- 17
Figure 6: Relation d’exigence entre Spécification et code 1 --------------------------------------------------------- 18
Figure 7: Relation d’exigence entre Spécification et code 2 --------------------------------------------------------- 19
Figure 8: Exemple d’un fichier liquibase ---------------------------------------------------------------------------------- 21
Figure 9: Exemple d'un test en Groovy (Framwork Spock) ----------------------------------------------------------- 22
Figure 10: Test d’intégrations et de non régression-------------------------------------------------------------------- 23
Figure 11: Processus de développement git flow----------------------------------------------------------------------- 24
Figure 12: Interface QuoteX Simulation----------------------------------------------------------------------------------- 25
Figure 13: Interface de login ------------------------------------------------------------------------------------------------- 26
Figure 14: Interface de l'ADMIN--------------------------------------------------------------------------------------------- 26
Figure 15: Gestion des utilisateurs QuoteX------------------------------------------------------------------------------- 27
Figure 16: Interface du MCO------------------------------------------------------------------------------------------------- 27
Figure 17: Interface de l'expert pricing------------------------------------------------------------------------------------ 28
Figure 18: US dans Confluence : Résultat constaté--------------------------------------------------------------------- 28
Figure 19: US dans Confluence : Critères d'acceptation-------------------------------------------------------------- 28
Figure 21: Erreur remontée avant la gestion des erreurs------------------------------------------------------------- 29
Figure 22: Erreur remontée après la gestion des erreurs------------------------------------------------------------- 30
Figure 23: Interface de Jenkins ---------------------------------------------------------------------------------------------- 30
Figure 24: les pipelines -------------------------------------------------------------------------------------------------------- 31
Figure 25: Nouveau pipeline ajouté---------------------------------------------------------------------------------------- 31
Figure 26: Fichier groovy appelé -------------------------------------------------------------------------------------------- 32
Figure 27: Paramètres de script groovy ----------------------------------------------------------------------------------- 32
Figure 28: Le pipeline sur Jenkins avec les stages----------------------------------------------------------------------- 33
Figure 29: Stages du script groovy------------------------------------------------------------------------------------------ 33
Figure 30: Script yaml appelé depuis le fichier groovy ---------------------------------------------------------------- 34
Figure 31: les tâches du script yaml---------------------------------------------------------------------------------------- 34
Figure 32: Script shell ---------------------------------------------------------------------------------------------------------- 35

6. 5
Liste des abréviations
APOLO : Application de Pricing Opérationnel des Offres
DevOps : Development and Operations
SAFe : Scaled Agile Framework
AMS : Application Management Service
MCO : Maintien en Condition Opérationnelle
TMA : Tierce Maintenance Applicative
CRM : Customer Relationship Management
MEP : Mise en production
MAB : Mep à blanc
IC : Innovation Commerciale
RTE : Release Train Engineer
PI : Program Increment
BO : Business Owner
BM : Business Owner
US : User Story
PO : Product Owner
DSTUM : Daily Stand Up Meeting
DSIT : Direction des Services Informatiques & Télécoms
DoD : Definition of Done
DoD : Definition of Ready
TU : Test Unitaire
TI : Test d’intégration
TNR : Test de non régression
TDD : Test Driven Development
JDD : Jeux de données
VM : Machine virtuelle

7. 6
Introduction
Le choix de mon stage s’est orienté vers le développement logiciel car c’est un domaine
qui m’intéresse et j’aurai la possibilité de monter en compétences sur plusieurs technologies à la
mode. De plus, c'est un domaine proche de notre formation ISECOM et plus spécifiquement des
systèmes embarqués, car les deux sont liés par du développement. Grâce aux connaissances en
programmation et en système embarqué j’ai pu basculer vers le développement logiciel sans trop
de difficultés.
Dans mon stage de fin d’études en développement de logiciels, j’ai travaillé sur un projet
pour un fournisseur d’énergie en France. Ce projet a la volonté d’appliquer les paradigmes les
plus récents dans sa réalisation. La volonté est d’augmenter et de faciliter les itérations pour
fournir une plus-value client rapide. La méthodologie SAFe et un certain nombre d’outils
DevOps y sont alors appliqués. Il s’agit d’une application de pricing et de différents services
associés à la fourniture d’énergie dont la maintenance corrective et évolutive est effectuée par
Capgemini.
Dans le cadre de la maintenance de ce logiciel et la refonte du nouveau logiciel,
Capgemini est chargée d’analyser les nouveaux besoins, d’implémenter et de déployer de
nouvelles versions majeures et mineures de l’application, d’analyser les anomalies de production
et de déployer des patchs correctifs.
Concrètement, ce logiciel est un fournisseur de services qui recourt à la mise en place d’une
architecture microservice. J’ai alors pu contribuer à l’implémentation de ses différentes
évolutions, mais aussi ajouter des fonctionnalités diverses facilitant le processus de
développement.
Après une présentation globale du projet au sein de Capgemini, des principaux outils
utilisés et de l’agilité mis en place, ce rapport se découpera ensuite en différentes parties
représentant le projet à différentes périodes du stage. Chacune abordera une partie sur les
méthodes de travail mise en place et sur les différentes taches réalisées.

8. 7
CHAPITRE 1 :
Présentation de l’entreprise et du projet

9. 8
Chapitre 1 : Présentation de l’entreprise et du projet
Introduction
Dans ce chapitre j’ai fait une présentation de l’entreprise, de la practice AMS ainsi que du projet.
Après une présentation de l’équipe APOLO ONE.
1. Présentation de l’entreprise
Capgemini est divisé en plusieurs pôles. L’AMS (Application Management Service) est
une division de Capgemini chargée de réaliser le développement d'évolutions majeures, le
support fonctionnel et la maintenance corrective et préventive des projets. La maintenance
corrective est plus communément appelée Maintien en Condition Opérationnelle (MCO).
L'entité AMS est constituée de plusieurs contrats de Tierce Maintenance Applicative (TMA)
avec divers clients.
Les différentes équipes affectées aux applications d’un même client sont regroupées en
centres de services.
Mon stage est rattaché au projet APOLO qui se positionne sur le centre de services client.
Ce service regroupe un certain nombre de projets de maintenance applicative pour ce dernier.
2. Présentation de projet APOLO
2.1. Le projet APOLO
Apolo est un fournisseur de services, il sert principalement à établir des devis, mais aussi
à effectuer de l’indexation de prix pour suivre l’évolution de prix au cours du marché.
Il est appelé par deux CRM (Customer Relationship Management – Gestion de la Relation
Client) : Veg@ et Legacy, qui peuvent être considérés comme les points d’entrée de ce système.
Les téléconseillers utilisent l’une de ces deux applications pour établir des devis, et donc leur
retourner des prix.
Concrètement, le logiciel fournit un ensemble de prix pour les sites concernés par le
devis. Un site correspond à un bâtiment, ou une partie d’un bâtiment, dont la consommation est
relevée par un compteur. Le téléconseiller, qui est chargé de faire une proposition commerciale,
reçoit, pour chacun des sites à valoriser du client, un prix minimum en dessous duquel il ne peut
pas vendre, et un prix conseillé optimal.
L’objectif est de fournir au conseiller un outil permettant de générer des devis, tout en assurant
une maîtrise des risques inhérents à la fourniture d’énergie. Il pourra, en plus, avoir un ensemble
de données lui permettant d’ajuster au mieux les prix à proposer au client.

10. 9
2.2. L’équipe APOLO ONE
L’équipe APOLO ONE est chargée du développement des microservices de pricing et la
maintenance de l’application Veg@.
La conception fonctionnelle et la validation interne sont effectuées par des personnes membres
de l’équipe que l’on nomme « fonctionnelles ». Elles sont au plus proches du client et possèdent
la connaissance des besoins métiers des différentes tâches à implémenter. Ils ont un droit de
décision sur la réalisation à effectuer.
L’équipe de développement réalise la conception technique, l’implémentation, les tests
unitaires et les tests d’intégration.
L’équipe comprend des responsables techniques sont chargés de réaliser les conceptions
évolutives de l’architecture et effectuent diverses études de performance pour respecter les
différentes contraintes extra-fonctionnelles imposées ainsi des conceptions techniques. Ils sont là
comme support à l’équipe de développement. Dans le cas d’évolutions majeures et critiques de
l’application, ils peuvent être amenés à en implémenter une partie pour soulager l’équipe de
développement. Les responsables techniques réalisent une dernière relecture des différents
développements réalisés avant de les ajouter à la branche de développement stable. En d’autres
termes ils valident le travail fourni par les membres développeurs.
Une équipe en parallèle de Maintien en Condition Opérationnelle (MCO) réalise le recueil et
l’analyse des anomalies de production, ainsi que le support utilisateur. Elle organise, de plus, les
différentes évolutions de paramétrage des données en base sur les différents environnements.
Souvent les prix changent au cours du temps. Il est alors demandé d’administrer les nouveaux
prix dans nos bases de données. C’est alors l’équipe MCO qui réalise ces changements.
Une équipe de conduite applicative gère les environnements projets, notamment les instances
de serveurs et de bases de données d’environnement du client. Ils sont les principaux acteurs
dans le cas d’une MEP (mise en production) ou d’une MAB (Mep à blanc).
Dans l’équipe Team APOLO ONE à laquelle je suis rattaché, nous comptons 13 membres.
➢ 1 PO
➢ 1 Scrum Master
➢ 2 Responsables techniques
➢ 4 Fonctionnels
➢ 1 Technico-fonctionnel
➢ 4 Développeurs
Conclusion
Après la présentation de l’entreprise, du projet et de l’équipe, on peut partir au deuxième
chapitre là où on va parler de la méthodologie de travail et les outils utilisés ainsi quelques
tâches abordées durant mon stage.

11. 10
CHAPITRE 2 :
Méthodologie et tâches abordées

12. 11
Chapitre 2 : Méthodologie et tâches abordées
Introduction
Dans ce chapitre, je vais parler de la méthodologie de travail, notamment la méthode SAFe, ainsi
le cycle de développement & DevOps et finalement quelques tâches abordées pendant mon
stage.
1. Méthodologie
1.1. Méthodologie SAFe (Scaled Agile Framework)
Le projet regroupe deux trains (train VEGA et d’Innovation Commerciale) qui se chargent du
développement du nouveau CRM Veg@. La Team APOLO ONE fait partie du train IC
(Innovation Commerciale). Ce train est constitué d’un ensemble de 9 équipes de développement,
une équipe de RTE (Release Train Engineer) et un système team. Chacune de ces équipes se
synchronise dans la stratégie Scrum à suivre. Nous réalisons des sprints d’une durée de 2
semaines. Il faut 5 sprints pour réaliser un PI (Program Increment).
➢ Préparation au PI Planning (Program Increment Planning)
La partie Portfolio décide des grands sujets (Epics) qui devront être traités dans les différents PI
à venir. Les Epics sont les artefacts de plus haut niveau dans la hiérarchie des artefacts SAFe.
Elles définissent des initiatives stratégiques, comme la nécessité d’ajouter une nouvelle
fonctionnalité, ou une demande d’évolution urgente de la part des utilisateurs du CRM. Cela
peut être également un réajustement métier, comme une restriction sur une offre ou un nouveau
calcul de prix, ou bien l’ajout de nouvelles fonctionnalités présentes sur l’application legacy,
mais pas encore implémentées par Vega. Tout cela est englobé par une restriction budgétaire.
Ainsi dans la partie Program, un découpage des différentes Epics sera réalisé par les BO
(Business Owner) et le BM (Business Owner). Cela permettra de préparer les sujets (Features) à
venir. La Feature ici est un service fourni par le système auquel est destiné le logiciel, elle est le
niveau situé au-dessus de l’User Story (US). Les Features seront par la suite priorisées en suivant
les mêmes contraintes que la partie Portfolio, mais en ajoutant des restrictions sur les capacités
des équipes et en prenant en compte les reliquats du PI précédent. Lorsque celles-ci auront été
préparées et priorisées, elles seront ajoutées au program Backlog du train.
Ainsi la partie Team doit, durant le PI en cours, allouer un temps pour préparer celui à venir. La
Team APOLO ONE et les différentes équipes du train enrichissent leurs TeamBackLog. Nous
réalisons une étude des features et nous concevons alors les premières conceptions fonctionnelles
pour être le plus près lors de la prochaine itération. Ces étapes sont réalisées via des réunions

13. 12
avec le métier, un découpage en US des PO des différentes équipes et 2 cérémonies SaFe. Une
ou plusieurs cérémonies de « macrochiffrage », permet d’estimer la capacité de travail nécessaire
sur une Feature. Ainsi que plusieurs cérémonies de « Grooming » qui permettent d’étudier les
Features, de les découper en plusieurs US et d’en réaliser les premières conceptions.
Ainsi le PI planning peut débuter.
➢ Déroulement du Program Increment Planning
Figure 1: PI Planning (SaFe)
Le PI Planning (exemple d’un PI planning : figure 1) se tient dans les locaux du client à
Paris, dans la mesure du possible. Sont réunis l’ensemble des équipes des deux trains ainsi que
les différents acteurs de la méthodologie SAFe pour une durée de deux jours.
Durant la matinée du premier jour, le client présente le contexte métier et sa vision de la
solution pour l’incrément à venir à l’ensemble des deux trains. Le Product Manager, référent
métier au niveau Programme, expose aux équipes le backlog de features priorisé ainsi qu’une
rétrospective du PI précédemment passé, tout en appuyant son discours sur les reliquats et
problèmes rencontrés. Le planning des deux jours est alors annoncé et le programme incrément
planning peut ainsi débuter.
Les équipes projets se réunissent alors. Elles déterminent leur vélocité globale en
fonction du nombre de développeurs, fonctionnels, responsable technique, disponibles sur
chacun des Sprints du PI en prenant en compte les différentes absences. Ainsi à partir de cette
vélocité et des features qui rentrent dans le périmètre de leur projet, les équipes réaliseront une
dernière étude de ces sujets sous la forme d’un Grooming.
Tous les fonctionnels, maitres de leurs sujets, présentent à leur tour les différentes
conceptions métier, c’est-à-dire leurs idées de réalisation et le découpage en US effectué pour les
features. Dans le cas où des US sont trop techniques et ne présentent aucune plus-value métier et
ne permettent donc pas une démonstration en fin de sprint, nous créons des Enablers. Les
Enablers, dans la méthode SAFe, sont des éléments du Backlog de produit. Ils sont liés à des
besoins en termes de construction de l'architecture, d'infrastructure, de recherche de solutions ou
de mise en conformité du système.

14. 13
Ainsi l’ensemble de ces User Stories et Enablers sont estimés selon la même méthode utilisée
lors des Sprints Plannings, c’est-à-dire le planning poker.
L’objectif final de ce travail est d’identifier les dépendances, ou « adhérences » entre
équipes et de réaliser la planification des 5 sprints suivants en conséquence. Par exemple, pour
réaliser de nombreuses US, nous avons eu besoin d’accéder au Web-Service exposé par une
autre équipe. Cela implique de connaitre le contrat d’interface de cette Api utilisée, mais aussi de
leur fournir la nôtre en cas de besoin. Nous devons alors communiquer avec l’autre équipe pour
savoir à partir de quand le service sera développé. En fonction de la date de réalisation prévue,
l’équipe peut positionner la Story dépendante sur un Sprint en particulier.
La difficulté est d’arriver à une coordination entre équipes pour pouvoir développer au
plus vite les features prioritaires. Les Scrum Masters jouent ici un rôle de facilitateurs pour gérer
le dialogue entre équipes. Dans le cas où une dépendance ne peut être résolue, il est possible
d’anticiper les impacts et donc de bouchonner les différentes interactions. L’expression «
bouchonner » stipule de simuler le retour d’un appel de Web-Service de l’Api que l’on souhaite
utiliser. Ainsi nos tests de validation peuvent être menés à bien. Lorsque l’évolution qui nous
concerne sera mise en place par l’équipe dépendante, le bouchon peut être levé et ainsi des tests
interconnectés peuvent être réalisés pour valider pleinement l’US.
Pour réaliser ce travail, les équipes utilisent un tableau en faisant figurer sur des post-it les
User Stories, les Enablers, les risques et les dépendances répartis par Sprint.
➢ Déroulement du PI
Figure 2: PI (SaFe)
La figure 2 représente le déroulement du PI, dans notre cas nous sommes de nombreuses
équipes travaillant en parallèle sur des sujets en commun. Pour aider la synchronisation de
l’ensemble des équipes et des sujets, nous utilisons tous, tout au long du PI, la méthodologie
Scrum. En mixant les cérémonies SaFe et Scrum au sein des équipes nous arrivons à avancer en
même temps sur les sujets en cours de développement et sur les conceptions des futurs sujets
tout en gardant un contact permanent avec les équipes pour lesquelles une dépendance existe.
Les cérémonies que nous appliquons au sein de la Team APOLO ONE sont les suivantes :
➢ DSTUM (Daily Stand Up Meeting) : Chaque matin, durant le sprint, à 9h45, pendant 15
minutes, une réunion est tenue dans le bureau où chaque personne (fonctionnel,
développeur, responsable technique, PO, Scrum Master) rend compte de ce qu’elle a fait
durant la journée précédente et des problèmes rencontrés. Elle expose ce qu’elle compte
faire dans la journée.
Un écran nous permet d’afficher différentes pages essentielles au bon déroulement du
DSTUM. D’une part, des pages de « dashboard ». Elles décrivent un état sur le bon
fonctionnement de l’application exposant des données en temps réel de l’application.

15. 14
Nous regardons un « board d’instance » qui permet une vérification du bon
fonctionnement des différents environnements (test, interconnections, production). Nous
regardons aussi un « board de supervision » qui affiche des données relatives à la
production, comme le nombre d’appels de webservices réalisés dans la journée, mais
aussi, si les différents tests joués automatiquement sur la production sont sans erreurs.
Nous étudions ici si une anomalie est détectée et si nous devons allouer du temps dans
notre journée au correctif de celle-ci.
Nous étudions ensuite via les pages de suivi de Jira, chaque tâche du Sprint en cours, une
à une, pour connaitre le bon avancement du Sprint pour être en capacité de vite distinguer
une tâche en retard, au risque de ne pas être validée et démontrable à la fin du sprint.
Dans ce cas le Scrum master doit avertir de ce retard lors de la cérémonie « Scrum de
Scrum ».
D’autres pages comme le suivi des sujets en conception pour le sprint suivant nous
permettent de savoir si des Grooming doivent être envisagés pour faire avancer des
conceptions.
➢ Grooming : Durant les 4 premiers Sprint, les Grooming sont organisés avec l’ensemble
de l’équipe pour réfléchir, présenter et concevoir les US et Enabler du prochain Sprint.
Malgré le fait que ces artefacts ont été déjà estimés, nous réalisons à chaque Grooming, si
nécessaire, une ré estimation, car les conceptions ont pu s’affiner. Cette réunion a pour
but d’identifier au mieux les risques et de les écarter. Elle permet aussi de vérifier si la
vélocité est toujours respectée et par là même si notre organisation des différents sprints
doit être modifiée.
Les Grooming, lors du sprint 5, ont pour but d’aborder avec toute l’équipe les Features
qui vont être prises dans notre Backlog lors du prochain PI. Un premier découpage en US
et Enabler sera réalisé et présenté, avec une estimation de chacune d’elles. Néanmoins le
déroulement de cette cérémonie reste le même que celui des précédents Sprints.
Le nombre de Grooming dans un Sprint n’est pas fixe et peut varier d’un Sprint à un
autre. Cette cérémonie a pour but d’étudier les futures tâches et donc d’estimer si elles
sont prêtes à être implémentées. Si les tâches n’ont pas subi d’ajustement et que celles-ci
n’ont pas d’intérêt à être présentées à l’équipe alors il n’est pas nécessaire de réaliser des
Grooming.
➢ Planification de sprint : L’équipe se réunit. Le PO (Product Owner) et les fonctionnels
présentent les US que l’on souhaite réaliser. Si nécessaire, des User Story peuvent être ré
estimés. Ensuite nous étudions, si existants, les reliquats du sprint terminé. Nous
estimons ces reliquats. Pour finir, nous choisissons un nombre d’US selon la capacité de
l’équipe. Nous déduisons 15% à la vélocité de l’ensemble de l’équipe, pour gérer les
aléas, c’est-à-dire les retours de production, les anomalies, la maintenance mais aussi les
différents allers et retours entre les équipes dont nous avons des dépendances.
➢ Team démo : Cette démonstration permet de démontrer à l’ensemble des parties
prenantes que les critères d’acceptations des US développées sont bien respectés. Suite à
cela, une livraison est effectuée. La démonstration est réalisée sur les environnements de
test. Les parties en dépendance avec d’autres équipes sont alors bouchonnées. N’est
validée que la réalisation et non pas les interconnexions. Etant un projet sur la conception

16. 15
de microservice nous réalisons alors des démonstrations sur des interfaces de bouchons
que nous avons développées. Ces interfaces simulent le CRM et nous permettent de tester
avec plus de facilité. Mais elles nous demandent du temps à allouer pour sa
maintenabilité lors d’évolutions. Cependant, il est possible que cette réunion n’ait pas
lieu. Notamment, par exemple, si les fonctionnalités ne sont pas à démontrer (Enablers)
ou si nous n’avons pas fini les US prévues dans le sprint.
➢ Système démo : Ainsi, en fin de PI une « Système démo » est réalisée. Elle réunit
l’ensemble des équipes (une centaine de personnes) et permet de démontrer le bon
fonctionnement des tâches réalisées en interconnexion avec les autres équipes. Lors du
déroulement de la démo, chaque équipe prend la main quand sa partie de l’application est
utilisée par la démo. Cela passe alors de l’IHM du CRM, du remplissage des données du
client (site, contrat, offre, etc ...), jusqu’à l’appel de pricing réalisé par mon équipe.
➢ Rétrospective : Chaque fin de Sprint, l’équipe de développement se réunit. Cette réunion
est animée par le Scrum master. La cérémonie ne suit pas un patern exact. Dans la plupart
des cas, il est demandé à chaque personne membre de l’équipe de s’associer à un état
émotionnel pour décrire comment il s’est senti sur le sprint. Ensuite chaque personne
décrit au minimum un point positif ainsi qu’un point qui nous a ralenti. Après la prise de
parole de tous, nous votons sur les points négatifs qui nous paraissent les plus importants.
Les 3 premiers points négatifs ayant le plus de votes seront discutés à la suite de la
réunion pour déterminer des axes d’amélioration. Chaque amélioration trouvée est
définie comme une action à réaliser et est assignée à une personne qui sera chargée de
son application.
Le plus souvent lors du dernier sprint du PI nous réalisons une rétrospective globale du
PI. Elle peut nous amener à parler de nous, de notre ressenti global, à exprimer nos
difficultés et nos axes d’amélioration. Chacun prend la parole tour à tour pour décrire un
point positif et un point d’amélioration à chaque membre de l’équipe.
1.2. Cycle de développement & DevOps
Dans la continuité de l’utilisation de SaFe, afin de permettre une implémentation rapide du
nouveau CRM, le client souhaite dé-commissionner l’ancien CRM le plus rapidement possible.
Il a donc dans sa stratégie de migrer les clients d’un CRM à l’autre, au fur et à mesure de
l’implémentation de Veg@. Le choix de développer par itération permet au client de garantir une
sécurité qui vise à décharger l’application legacy à chaque mise à jour de Veg@, en ayant le
temps de réaliser toutes les vérifications nécessaires au bon déroulement de cette migration.
Dans une volonté de faciliter et d’accélérer le processus d’itération, et d’avoir toujours une plus-
value, le client a décidé d’appliquer dans la réalisation de Veg@, le paradigme DevOps. Pour
cela, il paye une « Souscription DevOps » qui lui permet d’avoir un ensemble d’outils, lui
garantissant cette production rapide et continue en lui permettant des livraisons chaque fin de PI.
C’est l’équipe DSIT (Direction des Services Informatiques & Télécoms) du client qui se charge
de maintenir et de fournir les outils d’intégration continue.
Le DevOps se caractérise principalement par la promotion de l'automatisation et du suivi
(monitoring) de toutes les étapes de la création d'un logiciel, depuis le développement,

17. 16
l'intégration, les tests, la livraison, ainsi, jusqu'au déploiement ; mais aussi, l’exploitation et la
maintenance des logiciels. Les principes DevOps soutiennent des cycles de développement plus
courts, une augmentation de la fréquence des déploiements et des livraisons continues, pour une
meilleure atteinte des objectifs économiques de l'entreprise.
L’utilisation de DevOps se justifie dans sa volonté de faciliter les moyens de communication
entre les nombreuses équipes qui englobent le projet Veg@. Chaque équipe a accès aux mêmes
outils sur des plateformes partagées.
Tout cet environnement de travail nous permet au sein de l’équipe Team APOLO ONE de
suivre le cycle de développement DevOps comme illustré dans la figure 3.
Figure 3: Cycle de développement DevOps
La routine de développement des différentes tâches que j’ai pu implémenter suit pas à pas ce
processus. Pour une meilleure compréhension de mon travail et des nombreux outils utilisés au
quotidien, je vais expliquer avec détail chaque étape du processus Devops ci-dessus.
1.2.1. Continuous FeedBack : Analyse, recueils, et mise à jour des données (MCO)
L’équipe MCO se charge d’analyser la production et les anomalies. Elles utilisent ici différents «
dashboard », notamment le « board de supervision » qui lui donne différentes informations
nécessaires.
Les boards sont réalisés via l’outil Grafana qui permet la gestion et la visualisation de données
via des widgets. Cet outil permet d’interroger directement l’outil de visualisation Kibana. Ce
dernier permet de visualiser les données dans notre entrepôt de donnés Elasticsearch. Ce dernier
est utilisé pour le recueil de nos logs lors des appels sur nos différents microservices. On
enregistre les données d’entrée, de sortie, mais aussi d’autres informations durant le traitement
des appels comme les logs d’erreurs.
Ainsi nous arrivons à afficher un résultat qui facilite grandement l’analyse de la production et
des erreurs au cours du temps.

18. 17
Figure 4: Board des instances
Figure 5: Supervision MCO
Nous vérifions le nombre d’appels par jour des différents microservices de la production
avec le nombre d’erreurs, le récapitulatif des erreurs les plus courantes avec leurs détails et le
bon fonctionnement des microservices et des tests de non-régression lancés sur l’environnement
de production comme montré dans la figure 4 et 5. L’ensemble de l’équipe MCO se veut aussi la
plus proche des clients pour faciliter les échanges sur les différentes anomalies rencontrées et
ainsi lever un bug et initier un correctif le plus rapidement possible.

19. 18
Suite à la détection d’une anomalie et à son étude, un fonctionnel prend la main sur la
conception du correctif.
En plus de l’analyse, l’équipe MCO s’occupe de la maintenance des données de
production. Cela consiste, lors d’un réajustement des prix, avant une indexation ou bien lors de
l’ajout de nouvelles offres suite à un développement, à paramétrer les nouvelles données avec les
nouvelles grilles fournies par le client. L’administration est d’abord réalisée sur une base de
données de « référentiel », représentant une copie conforme de la production. Cette étape permet
de vérifier et de tester manuellement les nouvelles données. Dans le cas où tout est validé, un «
dump » est réalisé, c’est-à-dire qu’une copie de la base référentielle est appliquée à la base de
production.
La volonté nouvelle du client est de supprimer cet écart entre le recueil, l’analyse et la
mise à jour des données ainsi que le développement. L’ensemble des fonctionnels, mais aussi
des développeurs, sont alors amenés à être contactés par les différentes équipes lors de leurs
développements pour analyser les problèmes d’interconnexion. On nous demande aussi
dorénavant d’analyser les anomalies de production. C’est pour cela que le board de Supervision
est étudié soigneusement durant la cérémonie de DSTUM. Les fonctionnels aujourd’hui ont pour
rôle d’analyser les erreurs métier et d’administrer la base de données lors d’une évolution ou
l’ajout de nouvelles fonctionnalités. Le reste, comme la mise à jour des prix, est toujours réalisé
par la MCO, mais dans un futur proche se sera à l’équipe de développement de le réaliser.
1.2.2. Plan : Conception fonctionnelle
➢ Description du besoin
Les US et Enabler sont découpés en exigence. Lorsqu’un nouveau besoin apparaît, les
fonctionnels et PO vont, ; réaliser et écrire les spécifications fonctionnelles de la nouvelle tâche à
développer. Après avoir étudié les nouvelles tâches en spécifiant les DoD (Definition of Done) et
les DoR (Definition of Ready) pour chacune, ils rédigent une explication des différents besoins,
ainsi que les manières de les réaliser.
Pour cela, pour chacune des spécifications rédigées, un découpage en exigences métier est
effectué, selon le paterne bien précis suivant : NOM-EXG-NUM (ex : RCH-EXG-01, recherche
en grille exigence 01). Ils écrivent en suivant les erreurs métiers qu’il va falloir gérer dans le
développement avec le paterne similaire suivant : NOM-ERR-NUM (ex : RCH-ERR-01,
recherche en grille erreur 01).
Figure 6: Relation d’exigence entre Spécification et code 1

20. 19
Figure 7: Relation d’exigence entre Spécification et code 2
Comme veut le montrer la figure 6 et 7, ce découpage en exigence permet d’une part de
hiérarchiser les exigences en service métier. Mais, permet aussi lors du développement des
différentes tâches, d’annoter les méthodes implémentant l’exigence métier avec le même numéro
d’exigence, tout en renseignant les numéros d’erreurs associées. Ainsi, quand une erreur est
levée par notre application lors d’un pricing en échec, notre gestionnaire d’erreurs remonte le
code d’erreur concerné par l’échec. On peut donc facilement remonter directement à la source du
problème, voir le code en erreur et en récupérer l’exigence pour ainsi retrouver dans les
spécifications fonctionnelles son explication. Cela permet de réaliser une étude simple et rapide
de l’erreur, en comparant le code et les détails de l’exigence. En tant que développeur, cette
méthode nous permet de garantir une certaine dépendance dans la gestion des erreurs. Ainsi,
nous sollicitons moins les fonctionnels.
➢ Historisation et documentation
Toutes les descriptions des besoins des différentes tâches sont renseignées par les
fonctionnels, dans un premier temps sur l’outil JIRA sous la forme de ticket. Ces tickets sont
composés d’une simple description de la tâche à réaliser, ainsi que des liens vers la spécification
détaillée concernée. Les spécifications sont écrites dans l’outil Confluence qui, ici, est utilisé
comme un wiki. L’ensemble des équipes qui compose les deux trains peuvent accéder à la même
documentation. Cela permet, à partir d’une US, de remonter facilement à la feature à laquelle
elle hérite et ainsi voir les différentes US des autres équipes liées à cette même feature.
« Confluence » répertorie les différentes documentations réalisées par l’équipe de
développement. Cela peut comporter des explications concernant l’installation de son poste de
travail, des indications sur les processus de développement, ainsi que les descriptions des outils
d’intégration continues développées par les membres de l’équipe, comme l’utilisation des
pipelines d’intégration continues propre au projet et au déploiement de celui-ci.
1.2.3. Build : Cycle de développement
➢ Conception technique
Après avoir compris le besoin à implémenter et avant même de le développer, il est nécessaire de
concevoir la solution par le biais d’une conception technique. Cette conception est réalisée tout

21. 20
d’abord en se réunissant par groupe de 2 ou 3 développeurs. Nous parcourons ensemble le code,
pour étudier les possibles impacts, noter les classes/méthodes qui vont devoir être modifiées.
Plusieurs conceptions peuvent avoir lieu pour arriver à un détail suffisant et ainsi permettre à un
développeur qui n’a pas participé à la conception de réaliser le développement en suivant
simplement la conception technique. Ces conceptions sont réalisées avant le sprint qui portera
cette tâche à développer. Elle est présentée lors des Grooming en plus de la présentation métier
des fonctionnels.
Le développement peut alors débuter. La tâche dont la conception technique a été finalisée est
ajoutée au Backlog du sprint. Alors, lorsqu’un développeur souhaite réaliser la tâche, il
recherche le ticket associé et s’y assigne.
➢ Méthode de développement (Sonarqube)
Avant tout, lors du développement d’une tâche, il faut connaitre quels vont être les dépôts qui
seront impactés et ainsi créer une branche Feature associée pour chacun d’eux. Pour créer une
branche il existe un pipeline exposé par Jenkins permettant, en renseignant la branche source et
le nom de la nouvelle branche, de la créer en modifiant automatiquement les identifiants de
versions nécessaires dans le fichier de configuration du projet.
Le développement se fait en Java EE s’il s’agit d’une tâche réalisée sur l’application même. Si la
tâche réalisée a pour un but l’amélioration de l’intégration, cela peut être des technologies et
langages bien différents les uns des autres. J’ai déjà pu utiliser le langage Groovy pour la
conception des pipelines permettant le déploiement et la création de nouvelles branches ; ainsi
que le langage Kuery pour le développement des Dashboard. C’est un langage permettant de
réaliser des requêtes via Kibana pour traiter les logs de nos microservices. Mais la plupart du
temps se sont des développements de nouvelles exigences métier.
Dans l’application lors du développement de nouvelles méthodes implémentant des nouvelles
exigences il est nécessaire de les annoter avec le numéro d’exigence en question. Nous devons
aussi éviter la génération de codes smell, ou de vulnérabilités. Pour cela à chaque push d’une
branche un pipeline Jenkins va la scanner automatiquement à l’aide de Sonarqube et affichera les
diverses informations nécessaires au bon développement de la tâche.
➢ Paramétrage de données
Lors de l’implémentation d’une tâche, il est possible de devoir administrer certaines données en
base. Nous enregistrons en plus des grilles de prix, des données relatives à l’application, comme,
les messages d’erreurs métier associés aux exigences. Nous sommes amenés à modifier ou créer
des tables, mais aussi à ajouter des données. Pour cela nous utilisons la bibliothèque Liquibase,
qui permet à l’aide de fichier yml de réaliser des modifications de la base de données.

22. 21
Figure 8: Exemple d’un fichier liquibase
Dans un fichier Liquibase, comme le montre l’exemple ci-dessus (figure 8), nous pouvons
appliquer à la requête certaines informations comme la version de l’application, la date d’ajout et
le nom du développeur. Nous pouvons rajouter aussi une précondition et un message d’erreur qui
vérifie s’il est nécessaire de lancer la modification, et donc si cela ne court aucun risque. La
requête, elle, peut être directement écrite en SQL, mais la syntaxe proposée par Liquibase peut
aussi être utilisée. Cette syntaxe permet une meilleure lisibilité et une compréhension des
personnes n’ayant aucune connaissance en SQL.
Cela nous permet d’avoir une historisation de données par version. Lorsque l’on souhaite
déployer notre application sur un nouvel environnement, il suffit de lancer le Liquibase pour que
la base de données de l’environnement ciblé soit à jour.
Nous utilisons également, de plus en plus, comme centre de données des dépôts git via des
fichiers json que l’on parse pour en récupérer le contenu. Ainsi, il est facilement possible d’en
modifier le contenu et d’historiser les modifications via des branches. Nous utilisons cette
technique aujourd’hui pour enregistrer des données de transcodage. Lorsqu’on nous envoie des
données suite à un appel REST au service de pricing, certaines d’entre elles doivent changer de
forme pour être utilisables par notre application. Par exemple si on reçoit la donnée « heure
pleine », nous devons la transformer en « hp ».
1.2.4. Continuous intégration : Test et validation
Lorsque le développement d’une tâche semble terminé, il est nécessaire de réaliser des tests
élaborés. Nous utilisons 4 différents tests, les TU (Test Unitaire), les TI (Test d’intégration), les
TNR (Test de non régression) et pour finir les tests fonctionnels. Cela s’explique par le fait que
nous jouons avec des données liées aux prix. Chaque prix doit être exact et minutieusement
contrôlé.
➢ Test unitaire

23. 22
À la fin du développement, ou durant le développement via le TDD (Test Driven Development),
il est nécessaire de réaliser des tests unitaires. La volonté de l’application est de maintenir un
pourcentage de coverage à hauteur de 80%. C’est pour cela qu’il est obligatoire d’avoir au
maximum une couverture de 80% sur le nouveau code fourni lors du développement d’une tâche
sous peine que son code ne soit pas validé.
Pour réaliser les TU, nous utilisons le langage Groovy, plus précisément le framework Spock. Ce
dernier permet de réaliser des tests unitaires plus expressifs et plus compréhensibles comme
montré dans la figure 9.
Figure 9: Exemple d'un test en Groovy (Framwork Spock)
Ainsi il est possible de voir facilement la construction du test. Le projet Apolo reposant sur des
domaines de l’énergie complexe, il est important de permettre une lisibilité et une
compréhension du test pour faciliter la relecture par d’autres développeurs. De ce fait, cette
façon d’écrire un test peut être compris par un fonctionnel ou le Product Owner. Ils peuvent être
amenés à nous aider lors de la création d’un test utilisant des jeux de données bien spécifiques.
➢ Test d’intégrations et de non régression
Pour tester l’entièreté de notre API et pour simuler un appel de pricing nous réalisons des TI. À
chaque nouvelle implémentation métier, soit nous ajoutons un TI qui teste l’intégration de cette
nouvelle fonctionnalité, soit nous ajoutons des vérifications supplémentaires à un test existant.
Nous les réalisons en utilisant l’outil Cucumber. Cet outil permet d’automatiser des tests écrits
via le langage Gherkin. Ce langage se veut le plus expressif possible. Son utilisation permet de
rendre compréhensibles les tests par le client. Ainsi, ce sont les fonctionnels qui écrivent les
scénarios de test, car ils possèdent la connaissance métier nécessaire. En tant que développeur
nous écrivons la traduction des tests sous la forme de code Java.

24. 23
Figure 10: Test d’intégrations et de non régression
On peut y voir dans la figure 10 un exemple de TNR, chaque phrase est traduite par des
méthodes Java écrites par un développeur. Nous avons différents types de phrases comme
l’indique l’image ci-dessus.
➢ Given, qui permet de mettre en place l’environnement en base de données pour la bonne
exécution du test.
➢ When, qui crée le jeu de données sous forme Json. Le test est lancé et nos services
l’exécutent.
➢ Then, récupère le jeu de données en sortie et réalise des tests selon les données attendues
décrites dans le test.
Les tests sont écrits sur la plateforme web Jira. Nous utilisons Xray for Jira, qui est une
application permettant d’organiser des tests dans Jira. Ainsi lors de l’exécution d’un groupe de
tests, nous les récupérons via une url qui les regroupe tous. Puis nous vérifions que nos nouvelles
fonctionnalités n’apportent aucune régression et qu’elles sont valides au DoD et DoR.
• Validation fonctionnelle
Pour valider fonctionnellement et pour permettre au fonctionnel de tester plus profondément les
tâches réalisées, il est nécessaire de lancer une installation de la branche courante sur un
environnement de recette. Ce déploiement est réalisé via un pipeline Jenkins. Il permet
d’automatiser des vérifications sur la branche en plus du déploiement. Ainsi il est possible de
voir, si les différents Tests d’Intégrations sont passants, si aucun Test Unitaire est en erreur, mais
aussi de visualiser le coverage du code via Sonarqube.
Le déploiement permet dans un premier temps, au fonctionnel, de réaliser des tests plus
approfondis via l’outil Postman en créant des jeux de données précis. Il permet aussi de réaliser
une présentation de la tâche au PO, qui la validera par la suite. Pour finir c’est sur ce même
environnement que la cérémonie de Team démo est réalisée.

25. 24
1.2.5. Deploy : Processus de déploiement
Le déploiement est réalisé par l’équipe de développement sous la tutelle de l’équipe de conduite
applicative qui pour rappel se charge de la maintenance des différents environnements et
serveurs.
Le projet suit le processus de développement git flow comme montré dans la figure 11:
Figure 11: Processus de développement git flow
Comme l’indique le schéma de notre organisation de git, lorsque nous réalisons des US ou
Enabler du sprint courant, nous créons pour chacune, des branches « Feature ». Nous réalisons
aussi des branches « Bugfix » pour le correctif de bug. Lors de la demande d’une mise en
production en fin de sprint ou de PI, nous créons une branche de « Release » qui représentera la
branche fixe de la version que l’on souhaite déployer. Le numéro de tag de la branche
représentera la montée de version de notre application. Nous réalisons alors sur cette branche les
dernières vérifications avant le déploiement. Si nous rencontrons des problèmes, nous réalisons
les correctifs directement sur cette branche de release. Les correctifs sont alors merge sur notre
branche develop qui représente notre branche maitresse du projet.
Ainsi le cycle de développement est terminé. L’itération peut redémarrer avec de nouvelles
tâches à réaliser.

26. 25
2. Réalisations
2.1. Ajout d’authentification pour QuoteX Simulation
La figure 12 illustre l’interface QuoteX Simulation où on fait les simulations de pricing avec des
jeux de données (JDD) en entrée et fait le calcul par les microservices de l’application APOLO.
Figure 12: Interface QuoteX Simulation
Moi j’étais chargé d’ajouter une authentification à cette interface pour ne pas donner accès à tous
les membres des équipes, ainsi ajouté des rôles pour les utilisateurs.
J’ai utilisé le framework Spring security pour faire l’authentification. Le stockage des utilisateurs
et leurs rôles se font dans la base de données PostgreSQL dans la table.
Il y a 3 rôles pour accéder à l'interface QuoteX Simulation : ADMIN / MCO / Expert pricing
Les comptes des utilisateurs sont stockés dans une base de données postgreSQL, et chaque
utilisateur a un rôle qui lui permet de visualiser l'interface QuoteX Simulation selon ses autorités.

27. 26
Figure 13: Interface de login
• Utilisateurs QuoteX Simulation et leurs interfaces
On peut voir d’après la figure 14 que le compte ayant le rôle ADMIN a accès à toutes les
fonctionnalités de QuoteX Simulation :
Figure 14: Interface de l'ADMIN
Les ADMINs peuvent aussi gérer les comptes des utilisateurs (Ajout / Modification /
suppression / Export / Import). Le rôle ADMIN a aussi la possibilité d'exporter les utilisateurs en
format JSON, les mots de passe ne seront pas exportés en clair (tout est chiffré), et de même
pour l’import des utilisateurs (figure 15).

28. 27
Figure 15: Gestion des utilisateurs QuoteX
Le compte ayant le rôle MCO peut lancer les JDD ainsi les TNR (figure 16) :
Figure 16: Interface du MCO
Le compte ayant le rôle Expert pricing peut lancer seulement les JDD, c'est pour ça il ne peut pas
voir les deux colonnes "Définir référence" et "Comparaison" du tableau (figure 17).

29. 28
Figure 17: Interface de l'expert pricing
2.2. Gestion des erreurs
Dans cette partie, j’étais censé faire la remontée des erreurs. On utilise Confluence pour écrire la
description des features avec des analyses fonctionnelles et techniques (figure 18 et 19).
Exemple :
Figure 18: US dans Confluence : Résultat constaté
Figure 19: US dans Confluence : Critères d'acceptation

30. 29
Au début, quand on a une erreur à ce niveau, on remonte une erreur incompréhensible, donc il
fallait ajouter une gestion pour ces erreurs-là afin d’avoir une erreur compréhensible et avec plus
de détails que l’agent peut comprendre.
Au niveau code j’ai ajouté une exception pour des erreurs précises que je peux remonter par la
suite avec un code erreur.
Ensuite je lève une exception à l’endroit où il faut avec les informations nécessaires genre le
code d’erreur et d’autres informations compréhensibles pour les fonctionnels ou les agents afin
qu’ils corrigent leur jeu de données.
Et comme résultat au final, au lieu d’avoir une erreur incompréhensible comme dans la figure
21 :
Figure 20: Erreur remontée avant la gestion des erreurs

31. 30
On aura cette erreur avec tous les détails nécessaires (figure 22) :
Figure 21: Erreur remontée après la gestion des erreurs
2.3. Ajout d’un pipeline sur Jenkins « DevOps »
Dans cette tâche, j’ai fait la migration d’un pipeline depuis jenkins Capgemini vers le nouveau
jenkins de client pour raison de laisser tous nos jobs jenkins dans le réseau du client.
Voici l’interface de jenkins (figure 23) :
Figure 22: Interface de Jenkins

32. 31
Le pipeline que j’ai créé c’est « Refresh des scripts DevOps sur outils TCO » qui sert à faire un
git pull du git/nodejs sur une machine virtuelle (VM) outilsTCO qui est dans le réseau de
Capgemini. Et pour faire ça on passe par une machine intermédiaire qui s’appelle PLOA4 car
c’est elle qui a accès à outilsTCO, et ensuite on fait une connexion ssh entre PLOA4 et
outilsTCO pour exécuter notre script shell qui se trouve dans outilsTCO et qui fait le git pull.
Figure 23: les pipelines
Les paramètres de build de ce pipeline de la figure 24 sont les suivants (figure 25) :
Figure 24: Nouveau pipeline ajouté
Après au niveau du pipeline on exécute un fichier groovy par la suite qui va faire le traitement
derrière comme fait dans la figure 26.

33. 32
Figure 25: Fichier groovy appelé
Tout en bas, c’est le fichier groovy appelé depuis gitlab et qui est le suivant :
Figure 26: Paramètres de script groovy
La figure 27 montre le script groovy, dans ce fichier on ajoute tous les paramètres qu’on a
configurés au niveau de jenkins.

34. 33
Après on ajoute les stages, ces derniers sont affichés au niveau des étapes du pipeline comme
montré dans la figure 28 et 29 :
Figure 27: Le pipeline sur Jenkins avec les stages
Figure 28: Stages du script groovy

35. 34
Dans cette partie du code de la figure 30, on fait le checkout de la bonne branche, installation des
rôles ansible, git pull sur la VM outilsTCO et le rafraîchissement de tous les boards qui ont
relation avec cette action.
Le détail de ces étapes se fait dans un autre fichier yaml qu’on appelle par la suite.
Dans ce fichier yaml, on donne le rôle à l’utilisateur ansible pour accéder à la machine distante.
Figure 29: Script yaml appelé depuis le fichier groovy
Dans la figure 31, c’est montré comment on ajoute des tâches pour exécuter le fichier shell qui
est dans la machine outilsTCO, et par la suite faire le rafraichissement de tous les boards.
Figure 30: les tâches du script yaml

36. 35
La figure 32 montre le script qui fait le git pull :
Figure 31: Script shell
Conclusion
Dans ce chapitre, j’ai présenté notre méthode de travail, la méthode SAFe, comment on fait pour
les DSTUMs, le PI Planning, le team démo, la rétrospective, ...
Ainsi le cycle de développement DevOps et tous ce qui a relation avec les outils utilisés tels que
Jira, Confluence, Jenkins, Sonarqube.
Après une présentation de quelques tâches que j’ai fait durant mon stage notamment l’ajout
d’authentification sur QuoteX Simulation, la gestion des erreurs et l’ajout des pipelines sur
Jenkins.

37. 36
Conclusion générale
Durant mon stage chez Capgemini, j’ai appris pas mal de choses côté organisation,
méthode de travail, esprit d’équipe, développement logiciel ainsi du DevOps. Cela a été très
enrichissant.
J’ai eu l’opportunité de travailler en agilité (SAFe) et d’utiliser des outils intéressants
genre Jira, Confluence, Git/Gitlab, Jenkins et SonarQube, ainsi de monter en compétences sur
pas mal des technologies comme Java, Java EE, Springboot et NodeJS. J’ai travaillé dans une
partie de mon stage sur les boards d’instances en utilisant du NodeJS, après ça été
principalement du développement en Java et Springboot sur des multiples tâches différentes
telles que l’ajout d’authentification et gestion de la remontée des erreurs. Par la suite j’ai travaillé
côté DevOps sur les pipelines, notamment la création du pipeline sur Jenkins, le traitement
derrière avec du groovy/yaml/ansible/ssh.
Finalement je peux dire que c’était une belle expérience chez Capgemini. J’étais parmi
une excellente et ambitieuse équipe, et j'ai rencontré des gens incroyables.
Je suis par ailleurs convaincu que le travail élaboré pendant le stage n'est qu'une étape
primaire aussi bien pour une carrière professionnelle dans le développement logiciel avec
l’entreprise Capgemini qui m’ont donné l’opportunité de continuer d’exercer le rôle d’ingénieur
logiciel dans l’équipe après la fin de mon stage.