Stage Ingénieur

Développement d’un module de gestion des

échéanciers de crédit et mise en place de sa solution
de déploiement

Réalisé par

Fatma MASMOUDI

Encadré par : Mme Zouhour SELLAMI

Année Scolaire

2023 - 2024
 Remerciements
J’adresse mes remerciements les plus sincères a toute personne qui a contribué

de près ou de loin à la réalisation de ce projet.

Je suis très reconnaissante envers l’équipe de ATOM Engineering qui m’a

resérvé un accueil très chaleureux et qui m’a soutenu tout au long de mon stage.

En particulier, j’aimerais remercier mon encadrante Zouhour SELLAMI ainsi

que Mr Mohamed KHANFIR qui ont été d’une aide indispensable durant ce stage.

Leurs conseils, suggestions et corrections ont été très précieux pour faciliter et

mener à bien ce travail.

Finalement, j’exprime ma gratitude envers les cadres qui dirigent l’École Supérieure
des Communications de Tunis qui fournissent des efforts quotidiens afin d’améliorer
notre formation.

i
 TABLE DE MATIÈRES

Chapitre 1 :Contexte Général . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2 Organisme d’accueil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.2.1 Présentation de la société . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.2.2 Logo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.2.3 Domaines de spécialisation . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.3 Analyses et spécifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.3.1 Description de la mission principale de mon stage . . . . . . . . . . . . . . 3

1.3.2 Analyse des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

Chapitre 2 :Déroulement du stage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.1 Méthodologie Agile Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.1.1 Définition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.1.2 User Story . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.1.3 Les branches de développement . . . . . . . . . . . . . . . . . . . . . . . 7

2.1.4 Les environnements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.1.5 Concrétisation de la méthodologie Agile Scrum . . . . . . . . . . . . . . . 8

2.2 User Story 1 : Initiation du projet . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.2.1 La création des dépots de code . . . . . . . . . . . . . . . . . . . . . . . . 9

ii
 2.2.2 La création des pipelines CI/CD . . . . . . . . . . . . . . . . . . . . . . . 10

2.2.3 La création des environnements . . . . . . . . . . . . . . . . . . . . . . . 10

2.3 User Story 2 : Générer un échéancier de crédit . . . . . . . . . . . . . . . . . . . . 11

2.3.1 Première tache : Générer l’échéancier . . . . . . . . . . . . . . . . . . . . 12

2.3.2 Deuxième tache : Afficher la liste des échéanciers . . . . . . . . . . . . . . 13

Chapitre 3 :Conception et Développement . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3.1 Etude Conceptuelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3.1.1 Diagramme Cas d’Utilisation . . . . . . . . . . . . . . . . . . . . . . . . . 14

3.1.2 Diagramme de Classe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3.2 Développement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3.2.1 Phase de développement . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3.2.2 Tests Unitaires . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

Chapitre 4 :Mise en place de la solution de déploiement . . . . . . . . . . . . . . . . . . 20

4.1 Configuration des ressources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

4.2 Création de la pipeline CI/CD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

4.2.1 Création de la pipeline CI/CD du projet .Net . . . . . . . . . . . . . . . . . 21

4.2.2 Création de la pipeline CI/CD du projet Angular . . . . . . . . . . . . . . . 24

4.3 Résultats obtenus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

iii
 TABLE DES FIGURES

1.1 Logo de Atom Engineering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2.1 User Story 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.2 Création des depots de code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.3 Pull request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.4 Création des pipelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.5 Création des environnemets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.6 Environnement de déploiement . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.7 User Story 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.8 Générer l’échéancier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.9 Afficher la liste des échéanciers . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.1 Diagramme cas d’utilisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3.2 Diagramme de classe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.3 Les méthodes de la table tirage . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.4 Les méthodes de la table échéance . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.5 Exécution des tests unitaires . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

4.1 Ressources en VMs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

4.2 Création de pipeline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.3 Rapport de couverture de code . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.4 Fichiers d’éxécution du projet .Net . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.5 Fichiers d’éxécution du projet Angular . . . . . . . . . . . . . . . . . . . . . . . . 25

iv
4.6 Fournir les informations du tirage . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.7 Echéancier d’un tirage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.8 Liste des tirages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

v
 CHAPITRE 1
CONTEXTE GÉNÉRAL

1.1 Introduction

Du 3 Juillet 2023 jusqu’au 15 Aout 2023 j’ai eu la chance de rejoindre l’équipe de ATOM
Engineering dans le cadre de mon stage d’été.
Spécialisée dans les services numériques depuis sa création en 2013, ATOM s’est démarquée
grace au dynamisme et la créativité de son équipe.
Durant la période du stage j’ai eu l’opportunité de réaliser un module de géstion des échéanciers
d’un crédit ainsi que la mise en place de son processus Devops grace à l’outil Azure Devops.
Ce stage était également l’occasion pour moi de découvrir le monde proffessionnel, de travailler
harmonieusement au sein d’une équipe et de m’engager à atteindre mes objectifs pour le bon
déroulement du projet.
Afin de réfleter au mieux ces quelques semaines et le contexte de ce projet, je vais tout d’abord
me pencher sur l’organisme d’accueil, ses spécialités et ses méthodologies de travail. Par la suite, je
vais faire la description détaillée de mon projet, l’environnement de travail ainsi que l’implémentation
de la solution. Finalement, je vais présenter les résultats obtenus.

1
1.2 Organisme d’accueil

1.2.1 Présentation de la société

ATOM Engineering est une entreprise de services numériques offshore. Depuis sa création en
2013, elle connait une évolution progressive grâce à un environnement créatif et dynamique.

1.2.2 Logo

F IGURE 1.1 – Logo de Atom Engineering

1.2.3 Domaines de spécialisation

Atom se spécialise dans les technologies Microsoft et son expertise s’étend sur différentes
méthodologies et standards :
— Architectures : Orienté Objet, architecture multi-tiers, MVVM, IOT
— Technologie Web : Asp.Net Core, Angular, Bootstrap
— Cloud : Azure cloud services, Saas
— Mobiles : Native, Hybride, Cross plateforme, Xamarin, Android, IOS
— Méthodologies : Agilité, Scrum, Devops

1.3 Analyses et spécifications

Les phases d’analyses et de spécifications permettent de détailler ce qui a été ébauché lors de
l’étude préliminaires. Elles permettent aussi de dégager l’étude fonctionnelle afin obtenir une idée
sur les objectifs principaux de mon stage.

2
 Dans ce qui suit, je vais décrire la mission principale de mon stage, après, je vais détailler les
besoins fonctionnels et non fonctionnels de la solution que je vais proposer.

1.3.1 Description de la mission principale de mon stage

Mon projet consiste en première phase de concevoir, réaliser et tester un module de gestion des
échéanciers d’un crédit.
Ce module permet de générer un échéancier détaillé grace aux informations de crédit fournies
par l’utilisateur.
En deuxième phase, j’ai eu pour mission de mettre en place les processus intégration, distribu-
tion et déploiement continu de cette application.
Afin de réaliser ce projet j’ai utilisé les frameworks .Net7 et Angular 14. Ainsi que l’outil Azure
Devops.

1.3.2 Analyse des besoins

Cette partie servira à clarifier les besoins fonctionnels ainsi que les besoins non-fonctionnels
de l’application.

Besoins Fonctionnels

Les besoins fonctionnels représentent les fonctionnalités concrètes du projet. En d’autres termes
ils expriment ce que le système doit exécuter.
Dans ce cas, l’application a pour but de :
— Ajouter les informations relatifs à un tirage, à savoir, son montant, le montant principal, le
taux d’interet, la date de remboursement, ...
— Générer l’échéancier de ce tirage grace à une formule mathématique.
— Valider ou annuler un tirage en particuler.
— Modifier les échéances selon le besoin de l’utilisateur.
— Supprimer un tirage.

3
Besoins Non Fonctionnels

Les besoins non fonctionnelles concernent la performance, la disponibilité et l’évolutivité de

l’application.
Dans notre cas, l’application répond parfaitement au besoin de l’utilisateur en assurant un
temps de réponse minimum.

Identification des acteurs

Un acteur est une personne physique ou morale qui prend part ou bien qui est affecté par
l’action ou le projet en question. Notre application est destinée principalement à une banque qui
va pouvoir grace à notre application de gérer ses tirages envers le bailleur de fonds.

4
 CHAPITRE 2
DÉROULEMENT DU STAGE

2.1 Méthodologie Agile Scrum

2.1.1 Définition

La méthodologie agile scrum est la combinaison de la philosophie agile et du framework scrum.

Agile signifie ”incrémental”, ce qui permet aux équipes de développer des projets par petites
étapes. Scrum est l’un des nombreux types de méthodologie agile, connue pour décomposer les
projets en morceaux importants appelés ”sprints”. La méthode agile scrum convient aux entre-
prises qui ont besoin de terminer rapidement des projets spécifiques.
La méthode agile scrum est un système de gestion de projet qui repose sur un développement
progressif. Chaque itération se compose de sprints de deux à quatre semaines, dont l’objectif est
de développer d’abord les fonctionnalités les plus importantes et d’aboutir à un produit potentiel-
lement livrable. D’autres fonctionnalités sont intégrées au produit au cours des sprints suivants et
sont ajustées en fonction des commentaires des parties prenantes et des clients entre les sprints.
La méthode agile scrum présente plusieurs avantages. Tout d’abord, elle encourage la création
de produits plus rapidement, puisque chaque série d’objectifs doit être réalisée dans le délai im-
parti pour chaque sprint. Elle exige également une planification et une définition des objectifs
fréquentes, ce qui permet à l’équipe de se concentrer sur les objectifs du sprint en cours et d’ac-
croı̂tre sa productivité.

2.1.2 User Story

Un User Story est une explication informelle et générale d’une fonctionnalité logicielle rédigée
du point de vue de l’utilisateur final ou du client. L’objectif d’un User Story est d’articuler la
manière dont un travail fournira une valeur particulière au client.

5
Critères d’acceptation

Acceptance Criteria ou les critères d’acceptation sont les critères auxquels un objet de test doit
satisfaire pour être accepté par un utilisateur, un client ou une autre partie prenante. Les critères
d’acceptation aideront l’équipe à comprendre ce qui est inclus dans le champ d’application et ce
qui n’est pas inclus dans le champ d’application du User Story.

Story Points

Les story points est une unité de mesure qui permet d’estimer l’effort nécessaire afin d’implémenter
intégralement une tâche. Les équipes assignent des story points en fonction de la complexité ainsi
que du volume de travail.
Plusieurs équipes utilisent la séquence Fibonacci (1, 2, 3, 5, 8, 13, 21, 34, 55, 89, etc.) pour
les estimations, plutôt qu’une séquence linéaire ascendante (1, 2, 3, 4, 5, 6, 7, etc.) ou une suite de
nombres aléatoire.

Priorité

Dans Azure Devops il y a 4 niveaux de priorité :

— Priorité 1 : Fonctionnalités qui ont été examinées et approuvées par l’ensemble de l’équipe
en tant que priorités absolues pour le département et les équipes individuelles. Ces éléments
auront généralement la priorité sur les éléments moins prioritaires en raison de leur va-
leur pour l’organisation. Les propriétaires de produits et les spécialistes de la livraison
doivent accorder la plus grande importance à ces fonctionnalités lorsqu’ils s’assurent que
des progrès sont réalisés pour les achever dans les délais impartis. Ces fonctionnalités
doivent être en cours de réalisation jusqu’à ce qu’elles soient achevées, et peuvent être
clôturées une fois que les critères d’acceptance sont remplis.
— Priorité 2 : Fonctionnalités qui sont prioritaires au niveau de l’équipe mais qui ne sont pas
identifiées comme des priorités absolues dans l’ensemble du département. Les propriétaires
de produits et les spécialistes de la livraison doivent régulièrement examiner ces éléments

6
 pour s’assurer que des progrès sont accomplis en vue d’une réalisation dans les délais. Ces
éléments doivent être en cours de réalisation jusqu’à ce qu’ils soient achevés et peuvent
être clôturés une fois que les critères d’acceptance sont remplis.
— Priorité 3 : Ces éléments sont destinés à contenir des User Stories opérationnels (par exemple,
des communications, des mises à jour standard, etc...).
— Priorité 4 : Les éléments en statut P4 ne doivent pas être travaillés. Une fois que ce travail
devient une priorité, il doit généralement être déplacé vers le statut P2.

Les taches

En règle générale, chaque User Story est associée à plusieurs tâches. Les tâches sont utilisées
pour décomposer encore plus les User Stories. Les tâches sont la plus petite unité utilisée pour
suivre le travail.

2.1.3 Les branches de développement

Les branches permettent aux équipes de développeurs de collaborer facilement au sein d’une
base de code centrale. Lorsqu’un développeur crée une branche, le système de contrôle de version
crée une copie de la base de code à ce moment précis. Les modifications apportées à la branche
n’affectent pas les autres développeurs de l’équipe. C’est évidemment une bonne chose, car les
fonctionnalités en cours de développement peuvent créer de l’instabilité, ce qui serait très pertur-
bant si tout le travail se déroulait sur la branche de code principale. De plus, les développeurs
peuvent facilement récupérer les modifications apportées par d’autres développeurs pour collabo-
rer sur des fonctionnalités et s’assurer que leur branche privée ne s’éloigne pas trop de la branche
principale.

2.1.4 Les environnements

Un environnement est un ensemble de ressources que vous pouvez cibler avec des déploiements
à partir d’un pipeline. Des exemples typiques de noms d’environnement sont Dev, Test, Staging

7
et Production. Un environnement Azure DevOps représente une cible logique où votre pipeline
déploie des logiciels. ...

2.1.5 Concrétisation de la méthodologie Agile Scrum

Avant de commencer la réalisation du projet, une réunion de planification s’impose afin que
chacun des membres de l’équipe connaisse les besoins du projet et les taches qui lui sont assignées.
Durant ce meeting Mr Mohamed Khanfir qui représente le Product Owner, Mme Zouhour Sel-
lami qui est le Scrum Master et nous meme les stagiaires qui représentons l’équipe de développeurs
avons amplement discuté les besoins du projet.
Au bout de cette réunion, un planning détaillé a été mis en place. Un planning dans lequel deux
User Stories m’ont été assignées.

2.2 User Story 1 : Initiation du projet

F IGURE 2.1 – User Story 1

Ce User Story a pour but de créer les éléments essenciels du projet, à savoir les dépots, les

8
braches de développement, les pipelines et les environnements de déploiement.
Trois taches ont été créées dans ce User Story, la première étant la création des dépots, la
deuxième est la création des pipelines et finalement la création des environnements.

2.2.1 La création des dépots de code

F IGURE 2.2 – Création des depots de code

Comme le montre la figure ci-dessus, au bout de cette taches je doit avoir deux dépots, un
pour la partie API et un pour la partie Frontend, je doit aussi créer une branche de développement
qui dans mon cas s’intitule ”Feature/FMD/US24”. Je doit aussi initialiser les projet backend et
frontend.
Lorsque je travaille sur des modifications concernant les fonctionnalités qui m’ont été attribué,
j’utilise la branche développeur afin de ne pas créer des conflits avec la version du code dans la
branche principale.

F IGURE 2.3 – Pull request

9
 Par la suite je crée un Pull Request, qui détécte d’éventuels conflits avec la branche principale.
Et finalement je vais migrer la branche développeur avec la branche principale et modifier ainsi la
version du code dans la branche principale.

2.2.2 La création des pipelines CI/CD

F IGURE 2.4 – Création des pipelines

A l’issue de cette tache je doit avoir deux pipeline CI/CD. Une pipeline qui concerne la partie
API et une autre pour le projet Frontend.-[1]

2.2.3 La création des environnements

La toute dernière tache de ce User Story concerne la création des environnement de déploiement.
La figure ci-dessous décrit en détails cette tache.

F IGURE 2.5 – Création des environnemets

10
 Au bout de cette tache, j’ai créé l’environnement logique ”Development” où je vais plustard
définir les ressources.-[2]

F IGURE 2.6 – Environnement de déploiement

2.3 User Story 2 : Générer un échéancier de crédit

F IGURE 2.7 – User Story 2

La figure ci-dessus représente le User Story de mon projet qui s’intitule ”generate payment
schedule”.
La description de ce User Story est ”en tant que utilisateur je doit pouvoir générer mon échéancier
afin d’avoir toutes les mensualités”

11
 Dans le cas de mon projet le critère d’acceptation est ”En tant que agent de la banque, je peux
insérer toutes les informations relatifs à un tirage à savoir son montant, le montant principal, la
base de calcul, les dates de rempboursement, ... et à partir de ces informations un échéancier doit
etre généré.”

Story Points

L’équipe de Atom utilise la suite Fibonacci pour l’attribution des Story Points et après une
discussion avec les membres de l’équipe nous avons décidé d’attribuer la compléxité 3 au User
Story qui m’a été assigné.

Priorité

La génération de l’échéancier représente un élément crucial pour la réalisation du projet, mais

pendant la période de mon stage d’autres fonctionnalités étaient plus en urgence. Ainsi, afin de
respecter les délais définis avec le client nous avons décidé de définir la priorité à 2, ce qui définit
parfaitement le niveau de priorité auquelle se classe mon projet.

2.3.1 Première tache : Générer l’échéancier

Cette tache représente la partie de génération de l’échéancier à partir des informations de tirage
que va fournir un agent de la banque. Elle inclut la partie développement en Backend et en Frontend
de cette fonctionnalité ainsi que la partie de tests unitaires. Et finalement le déploiement de cette
fonctionnalité.

12
 F IGURE 2.8 – Générer l’échéancier

2.3.2 Deuxième tache : Afficher la liste des échéanciers

Cette tache définit l’affichage de la listes des tirages effectués par une banque. Elle inclut la
partie développement en Backend et en Frontend de cette fonctionnalité ainsi que la partie de tests
unitaires. Et finalement le déploiement de cette fonctionnalité.

F IGURE 2.9 – Afficher la liste des échéanciers

13
 CHAPITRE 3
CONCEPTION ET DÉVELOPPEMENT

3.1 Etude Conceptuelle

L’étude conceptuelle permet d’établir un schéma conceptuel des données de traitement. Dans
la suite, je vais présenter les diagrammes UML relatifs à mon projet qui représentent une étape
primordiale dans la réalisation de cette application.

3.1.1 Diagramme Cas d’Utilisation

Le diagramme Cas d’utilisation représente le comportement fonctionnel de l’application. En

d’autres termes, il décrit ce que le système fait et comment les acteurs l’utilisent.

F IGURE 3.1 – Diagramme cas d’utilisation

14
3.1.2 Diagramme de Classe

Un diagramme de classe décrit explicitement la structure d’un système. Et ce en modélisant ses

classes, ses attributs, et les relations entre ses objets.

F IGURE 3.2 – Diagramme de classe

La figure ci-dessus représente le diagramme de classe du projet. En effet, il y a deux tables

dans la bases de données :
— La table Tirage : qui a les attributs convention, numéro de tirage, référence de tirage, le taux
d’interet, le montant du tirage, la commission risque de change, la date du tirage, le cours
historique, le montant principal qui représente la somme d’argent du tirage principal qu’il
faut payer par échéance, la date de début de remboursement qui représente la date à laquelle
la banque doit payer la première échéance, la date de début de remboursement en principale
qui représente la date à laquelle la banque doit payer le premier montant en principal, la
date de fin de remboursement, le rythme de remboursement qui représente le rythme auquel
la banque va payer le crédit (par mois, par trimestre, par semestre, ...), l’option de fin de
mois, la base de calcul et l’année commerciale.
— La table échéance : a les attributs date de l’échéance, en cours qui représente le montant

15
 qui reste à payer du crédit principal, principal qui représente le montant du crédit principal
que la banque doit payer en un échéance, interet qui represente le montant d’interet que la
banque doit payer en un échéance et le nombre de jours qui représente le nombre de jours
écoulés depuis la dernière échéance.

3.2 Développement

Durant la phase de développement, les besoins et objectifs définis dans les étapes préliminaires
du projet vont etre implémentés et testés.
Dans ce qui suit, je vais présenter une description détaillée du développement de l’application
Web, ainsi que la réalisation des tests unitaires.

3.2.1 Phase de développement

Backend

La partie Backend désigne la partie de l’application qui est inaccessible par l’utilisataur et qui
définie les méthodes et fonctions qui assure son bon fonctionnement.
Pour le développement de cette partie, j’ai utilisé la Framework .Net7 avec l’outil Visual Studio
2022.
Le framework .NET s’agit d’un framework de développement logiciel de Microsoft. Il fournit
un environnement de programmation où les logiciels peuvent être développés, installés et exécutés
sur des systèmes d’exploitation Windows.
Les trois langages de programmation principaux avec lesquels on peut programmer une appli-
cation .NET sont CSharp, FSharp et Visual Basic. Pour le développement de ce projet j’ai choisi
de travailler avec le language de programmation orienté objet CSharp.
J’ai choisi de travailler avec CSharp car il favorise la création d’applications robustes et sécurisées,
il est flexible et a une très bonne gestion des erreurs.
Dans la suite, je vais détailler les méthodes que j’ai développé lors de cette phase et leurs
objectifs.

16
 F IGURE 3.3 – Les méthodes de la table tirage

La figure ci-dessus présente les méthodes développées de la table Tirage.

En effet, la méthode ”GetAllTirages” retourne tous les tirages enregistrés, la méthode ”Get-
ById” retourne le tirage qui possède un identifiant en particulier, la méthode ”Create” permet de
créer un Tirage et finalement la méthode ”Update” permet de modifier le status d’un tirage ”validé”
ou ”pas validé”.

F IGURE 3.4 – Les méthodes de la table échéance

La figure ci-dessus présente les méthodes développées de la table Echéance.

La méthode ”GetAllEcheances” similaire à la méthode ”GetAllTirage” va retourner tous les
échéances. De meme pour les méthodes ”GetById” et ”Create”. La méthode ”GetEcheancier” re-
tourne l’échéancier d’un tirage en particulier, la méthode ”GenerateEcheancier” génère les échéances
d’un tirage et la méthode ”UpdateEcheance” permet de modifier les échéances.

FrontEnd

En développement web, la notion de ≪ front end ≫ représente l’ensemble des éléments visibles
et accessibles par l’utilisateur final sur un site web.
Pour le développement de cette partie j’ai choisi de travailler avec le framework Angular 14

17
avec l’outil Visual Studio Code.
Angular s’agit d’un framework Javascript qui permet de réaliser des applications WEB Cross
Plateform.
Il est possible de développer sur Angular en Javascript natif, en Dart, ou bien en TypeScript.
J’ai travaillé dans ce projet avec Typescript qui est une surcouche de Javascript apportant notament
un typage fort, en gardant la syntaxe du langage. Il permet de faciliter le développement ainsi que
le test des applications webs.

3.2.2 Tests Unitaires

Le test unitaire consiste à isoler une partie du code puis à vérifier qu’il fonctionne comme il
faut. Il s’agit de petits tests qui valident l’attitude d’un objet et la logique du code.
Ces tests sont généralement effectués pendant la phase de développement.
Pour la réalisation des tests unitaires j’ai opté pour xUnit.net qui est un outil de test gratuit
et open source destiné pour les projets développé avec la Framework .Net. Il représente la toute
dernière technologie pour les tests unitaires CSharp, FSharp, VB.NET et autres languages .Net.
-[3]
Après avoir créer un projet xUnit.net j’ai pu tester les differents méthodes implémentées dans
”TirageService” et ”EcheanceService”.
La figure ci-dessus montre les différents tests exécutés pendant la phase de développement.
J’ai pu grace à ces tests vérifier les méthodes fondamentales de l’application comme la méthode
”GenerateEcheancier”.

18
F IGURE 3.5 – Exécution des tests unitaires

19
 CHAPITRE 4
MISE EN PLACE DE LA SOLUTION DE DÉPLOIEMENT

4.1 Configuration des ressources

Avec Azure Devops, on a la possibilités d’ajouter des ressources à un environnement en Kuber-

netes ou en Machines virtuelles. Pour ma part, j’ai opté pour les ressources en machines virtuelles
car Kubernetes peut être complexe à mettre en place et à gérer, en particulier pour les applications à
petite échelle. Cependant, il excelle dans la gestion d’architectures de microservices dynamiques et
de grande envergure. Par contre, les machines virtuelles sont généralement plus faciles à gérer car
elles imitent l’infrastructure serveur traditionnelle. Des outils tels que les plateformes de gestion
de la virtualisation (par exemple, VMware) simplifient la gestion des machines virtuelles.
Malheureusement, pendant la période de mon stage je n’ai pas eu accès aux ressources de
l’entreprise. Pour cette raison, j’ai configuré ma propre machine en tant que machine virtuelle qui
hébérgera mon projet.-[4]

F IGURE 4.1 – Ressources en VMs

20
4.2 Création de la pipeline CI/CD

Un pipeline d’intégration et de déploiement continus (CI/CD) est une série d’étapes à réaliser
pour livrer une nouvelle version d’un logiciel. Les pipelines CI/CD sont une pratique axée sur
l’amélioration de la livraison de logiciels tout au long du cycle de vie du développement logiciel
grâce à l’automatisation. -[5]
En automatisant les phases de développement, de test, de production et de surveillance du
cycle de vie du développement logiciel, les organisations sont en mesure de développer un code de
meilleure qualité, plus rapidement. Bien qu’il soit possible d’exécuter manuellement chacune des
étapes d’un pipeline CI/CD, la véritable valeur des pipelines CI/CD est obtenue grâce à l’automa-
tisation.

4.2.1 Création de la pipeline CI/CD du projet .Net

J’ai tout d’abord commencé par la création d’une pipeline. En effet, j’ai créé un fichier de type
Yaml dans lequel je vais définir les étapes d’integration et de déploiement de mon projet.-[6]

F IGURE 4.2 – Création de pipeline

La pipeline est configuré de sorte qu’elle s’éxécute à chaque fois qu’il y a une modification
dans la branche principale.

21
L’étape de Build

L’étape de Build est la première étape d’un pipeline CI/CD, et elle automatise des étapes telles
que le téléchargement des dépendances, l’installation des outils et la compilation.
L’étape de Build se termine généralement par l’étape de génération d’Artifacts, au cours de
laquelle nous créons un paquetage prêt pour la production. Une fois cette étape terminée, la phase
de test peut commencer.
Afin de réaliser cette étape, j’ai créé un fichier de type ”Yaml” dans lequel j’ai configuré les
étapes de Build à savoir les phases de restauration des dépendances du projet qui servira à installer
toutes les dépendances du projet, ainsi que la phase ”Build” qui va compiler le projet.

L’étape de test

Après la phase de Build il faut lancer l’étape de test, qui va éxécuter les tests unitaires définis
précédemment.
Au bout de cette étape, j’ai créé un rapport de couverture de code qui aide à déterminer la
proportion du code du projet qui est réellement testée. Pour accroı̂tre votre confiance dans les
modifications du code et vous prémunir efficacement contre les erreurs. -[7]
L’examen des résultats de la couverture du code permet d’identifier les chemins de code qui ne
sont pas couverts par les tests. Cette information est importante pour améliorer la garantie des tests
au fil du temps.

22
 F IGURE 4.3 – Rapport de couverture de code

La figure ci-dessus affiche les résultats de couverture de code du projet .Net. ”Line Coverage”
représente le nombre total de lignes exécutées divisé par le nombre de lignes dans la base de code.
Cependant, ”Branch coverage” est une mesure qui indique si toutes les branches d’une base de
code sont exercées par des tests. Une ”branche” est l’un des chemins d’exécution possibles que le
code peut emprunter après l’évaluation d’un énoncé de décision (par exemple, un énoncé ”if”).

Récupération des fichiers d’éxécution :

Après les phases de Build et Test, un artifact a été généré, cet Arifact représente un paquetage
de fichiers pret pour l’éxécution.

23
 F IGURE 4.4 – Fichiers d’éxécution du projet .Net

Phase de déploiement

La phase ultime dans la CI/CD pipeline est le déploiement du projet en effet j’ai téléchargé
l’Arifact produit dans la phase de Build et j’ai associé l’environnement que j’ai précédemment
configuré pour déployer l’application. -[8]

4.2.2 Création de la pipeline CI/CD du projet Angular

La phase de build

Les fichiers d’éxécution dans un projet Angular peuvent etre créés grace à la commande build
dans l’éditeur de code ce qui va générer ces fichiers dans un dossier s’intitulant ”dist”.

24
 F IGURE 4.5 – Fichiers d’éxécution du projet Angular

Phase de déploiement

Finalement j’ai récupéré ces fichiers d’éxécution et j’ai déployé le projet dans l’environnement
configuré. -[9]

4.3 Résultats obtenus

Dans cette partie, je vais étaler les résultats finals de mon application.
Les figures ci-dessous représentent le formulaire qu’un agent de la banque doit fournir pour
générer l’échéancier.

25
 (a) Formulaire du tirage

(b) Générer l’échéancier

F IGURE 4.6 – Fournir les informations du tirage

Après avoir cliqué sur le bouton générer, un échéancier s’affiche comme le montre la figure
ci-dessous.

26
 (a) Consultation de l’échéancier

(b) Valider l’échéancier

F IGURE 4.7 – Echéancier d’un tirage

Finalement, en cliquant sur valider, l’échéancier sera confirmé. Et un tableau avec tous les
tirages s’affiche.

27
 (a) Consulter l’état du tirage

(b) Valider ou annuler le tirage

F IGURE 4.8 – Liste des tirages

Le tableau affiche tous les tirages de la banque. Avec la possibilité de valider ou bien d’annuler
un tirage et aussi la possibilité de consulter son échéancier.

28
 Conclusion
Ce projet était l’opportunité pour moi de découvrir à quoi ressemble véritablement un envi-
ronnement de travail. En travaillant au sein d’une équipe, en m’inspirant de mes collaborateurs et
de mes encadrants et en échangeant nos propositions et suggestions j’ai pu acquérir tellement de
connaissances qui me seraient utiles tout au long de mon parcours et pour celà je suis infiniment
reconnaissante à toute l’équipe de Atom.
Néanmoins, il est essentiel de mentionner les limites du travail que j’ai réalisé. J’aurais aimé
durant mon stage configurer des ressources de déploiement. Or, faute de temps et de quelques
inconveniences cette étape n’a pas été accompli. J’ai aussi voulu me pencher un peu plus sur la
partie de tests unitaires afin de les effectuer dans les règles de l’art.
Mis à part ces quelques limites, cette période de stage a enrichi énormément mon expérience.
En effet, j’ai appris la gestion d’un projet de bout en bout, les concepts d’integration et de déploiement
continu. J’ai aussi appri tellement sur le domaine de la Fintech et les crédits bancaires et bien
d’autres connaissances.
Finalement, ce stage est plein de points positifs qui resteront à jamais gravés dans ma mémoire.
Et c’est avec satisfaction que je conclus cette étape de mon parcours professionnel.

29
 REFERENCES

[1] “Un pipeline CI/CD, qu’est-ce que c’est ?”, Red Hat, 2022.

[2] “Create and target an environment”, Microsoft, 2023.

[3] R. M IRANDA, “How to Test a REST API with .NET and xUnit”, CodeMaze, 2022.

[4] “Azure DevOps release pipeline for .NET Web API using IIS”, Round the code, 2022.

[5] “Customize your pipeline”, Microsoft, 2023.

[6] “Build, test, and deploy .NET Core apps”, Microsoft, 2023.

[7] C. S. V ISWANADHA, “Publish Code Coverage Report in Azure DevOps Services pipeline
execution summary”, Microsoft, 2023.

[8] “Deploy to a Linux Virtual Machine”, Microsoft, 2023.

[9] Y. M ULONDA, “How to deploy an Angular App”, Medium, 2018.

30