Rapport Final Ouedraogo David PP

UNIVERSITÉ JOSEPH KI-ZERBO
(UJKZ)
******
INSTITUT BURKINABÈ DES ARTS ET MÉTIERS
(IBAM)
RAPPORT DE STAGE POUR L’OBTENTION DE LA LICENCE

PROFESSIONNELLE
OPTION : Méthodes Informatiques Appliquées à la Gestion (MIAGE)
Période de stage : 01 juillet 2021 au 30 septembre 2021
THEME :
MISE EN PLACE D’UN SYSTÈME DE

COMMUNICATION BASE SUR LES SMS POUR
LES PROFESSIONNELS ET LES
PARTICULIERS.
Présenté par OUEDRAOGO David Pascal Pawindtaoré
Maitre de stage : Directeur de rapport :

M. DARGA Lael Dr TRAORE Yaya
Ingénieur de conception IoT Enseignant à l’IBAM
Année Académique 2020-2021

RAPPORT DE STAGE
SOMMAIRE
SOMMAIRE .............................................................................................................................. i
DÉDICACE............................................................................................................................... ii
REMERCIEMENTS ............................................................................................................... iii
LISTE DES SIGLES ET ABREVIATIONS ......................................................................... iv
LISTE DES FIGURES GRAPHIQUES ................................................................................ vi
LISTE DES TABLEAUX ...................................................................................................... vii
INTRODUCTION GÉNÉRALE ............................................................................................ 1
CHAPITRE I : PRÉSENTATION DES STRUCTURES DE FORMATION ET
D’ACCUEIL ............................................................................................................................. 2
I. PRÉSENTATION DE LA STRUCTURE DE FORMATION (IBAM) .......................... 2
II. PRÉSENTATION DE LA STRUCTURE D’ACCUEIL(OKABI) ............................. 5
CHAPITRE II : ANALYSE ET CONCEPTION .................................................................. 6
I. ÉTUDE PREALABLE .................................................................................................... 6
II. EXPRESSIONS DES BESOINS ............................................................................... 14
III. CONCEPTION GLOBALE ...................................................................................... 26
IV. RÉALISATION ......................................................................................................... 35
CHAPITRE III : BILAN DU STAGE .................................................................................. 46
I. DÉROULEMENT DU STAGE ET ACTIVITÉS MÉNÉES ......................................... 46
II. OBSERVATIONS ET SUGGESTIONS ................................................................... 47
CONCLUSION GÉNÉRALE ............................................................................................... 48
BIBLIOGRAPHIE ET WEBOGRAPHIE..............................................................................I
TABLE DE MATIERES ...................................................................................................... III
ANNEXES ................................................................................................................................ V
OUEDRAOGO DAVID PASCAL PAWINDTAORE i

RAPPORT DE STAGE
DÉDICACE
À
Toute ma famille
OUEDRAOGO DAVID PASCAL PAWINDTAORE ii

RAPPORT DE STAGE
REMERCIEMENTS
Nous ne saurons continuer notre travail sans d’abord présenter nos sincères
remerciements à tous ceux qui ont contribué de près ou de loin à l’obtention ainsi qu’au bon
déroulement de ce stage. Nos remerciements vont aussi à tous ceux qui ont contribué d’une
manière ou d’une autre à l’élaboration de ce document. Nous adressons nos remerciements
particulièrement à :
• M. Lael DARGA, notre maître de stage, qui n’a ménagé aucun effort, à nous soutenir
malgré ses multiples occupations, à nous écouter et à nous orienter vers la bonne
direction en apportant des réponses adéquates à toutes nos questions.
• Dr Yaya TRAORE, le coordonnateur de la filière MIAGE, notre professeur de suivi,
qui a joué un rôle primordial dans l’obtention de ce stage et qui nous a témoigné son
entière disponibilité à nous assister tout au long de la rédaction de ce document.
• M. Ilias OUEDRAOGO, Co-fondateur et Ingénieur de conception informatique à
OKABI, pour sa collaboration et son apport indispensable à la réussite de ce travail.
• M. Oumarou KABORE, Co-fondateur gérant de OKABI Technology Services, pour
son implication tout au long du travail malgré un calendrier très chargé.
• Dr Blaise KONE, Directeur de l’IBAM, et tout le corps professoral pour les conseils
et la formation de qualité que nous avons reçus au cours de ces trois (3) années.
• Tous nos proches et amis qui nous ont toujours soutenu et encouragé.
OUEDRAOGO DAVID PASCAL PAWINDTAORE iii

RAPPORT DE STAGE
LISTE DES SIGLES ET ABREVIATIONS
SIGLE/ABREVIATION SIGNIFICATION
Ingénierie Informatique et Organisation et Protection

2IOPSIE
des Systèmes d’Information dans l’Entreprise
Ingénierie Informatique et Technologies de

2ITIC
l’Information et de la Communication
2TUP 2 Tracks Unified Process
ABF Assurance Banque Finance
ADB Assistance de Direction Bilingue
AIB Antenne informatique de Bobo Dioulasso
API Application Programming Interface

Autorité de Régulation des Communications
ARCEP
Électroniques et des Postes
ATOS Administratifs, Techniques, Ouvriers, de Service
COCOMO Constructive Cost Model
Chef des Services Administratif, Financier et

CSAFC
Comptable
CSS Cascading Style Sheet
CU Cas d’utilisation
DA Directeur Adjoint
Diplôme d’Études de Comptabilité et Gestion
DESCOGEF
Financière
DESS Diplôme d’Études Supérieures Spécialisées
DG Directeur Général
HM Homme Mois
HTML HyperText Markup Language
HTTP HyperText Transfer Protocol
OUEDRAOGO DAVID PASCAL PAWINDTAORE iv

RAPPORT DE STAGE
IBAM Institut Burkinabè des Arts et Métiers
IUFIC Institut Universitaire de Formation Initiale et Continue
Java EE Java Entreprise Environnement
JPA Java Persistence API
JS JavaScript
JSON JavaScript Object Notation
JWT Json Web Token
LMD Licence Master Doctorat
LPSAA Licence Professionnelle en Assistance Administrative
MAGE Master en Administration de Gestion des Entreprises
MBF Master en Banque Finance
MCCA Master en Comptabilité-Contrôle-Audit
MIAGE Méthodes Informatiques Appliquées à la Gestion
SIM Subscriber Identity/Identification Module
SGBD Système de Gestion de Base de Données
SMS Short Message Service
SQL Structured Query Language

Technologies de l’Information et de la
TIC
Communication
Nouvelles Technologies de l’Information et de la
NTIC
Communication
UJKZ Université Joseph KI-ZERBO
UML Unified Modeling Language
WWW World Wide Web
OUEDRAOGO DAVID PASCAL PAWINDTAORE v

RAPPORT DE STAGE
LISTE DES FIGURES GRAPHIQUES
Figure 1: Schéma présentant le processus 2TUP ..................................................................... 11

Figure 2: Planning de réalisation du projet .............................................................................. 14
Figure 3: Diagramme de cas d’utilisation ................................................................................ 16
Figure 4 : Diagramme de séquence vue de l’extérieur pour le CU « Authentification » ......... 21
Figure 5: Diagramme de séquence vue de l’extérieur pour le CU « Ajouter un contact » ...... 22
Figure 6 : Diagramme de séquence vue de l’extérieur pour le CU « Envoyer un message » .. 23
Figure 7 : Schéma présentant l’architecture 2 tiers .................................................................. 24
Figure 8 : Schéma présentant l’architecture 3 tiers .................................................................. 25
Figure 9: Diagramme de classes............................................................................................... 31
Figure 10: Diagramme d’activité du CU « Envoyer un message » .......................................... 32
Figure 11 : Diagramme de déploiement ................................................................................... 34
Figure 12: Ecran d’inscription.................................................................................................. 44
Figure 13 : Ecran de connexion................................................................................................ 44
Figure 14 : Ecran Ajout d’un contact ....................................................................................... 45
Figure 15: Ecran d’envoi de message ...................................................................................... 45
Figure 16: Illustration du Token JWT ...................................................................................... VI
OUEDRAOGO DAVID PASCAL PAWINDTAORE vi

RAPPORT DE STAGE
LISTE DES TABLEAUX
Tableau 1 :Comparaison des méthodologies de développement ............................................... 9

Tableau 2: Liste des cas d’utilisation ....................................................................................... 16
Tableau 3: Description du CU « Authentification » ................................................................ 17
Tableau 4: Description du CU « Ajouter un Contact » ............................................................ 18
Tableau 5: : Description du CU « Envoyer un message non programmé » ............................. 19
Tableau 6: Description du CU « Envoyer message programmé » ........................................... 20
Tableau 7: Description de la classe « Entreprise »................................................................... 27
Tableau 8: Description de la classe « Utilisateur » .................................................................. 27
Tableau 9: Description de la classe « Destinataire » ................................................................ 28
Tableau 10: Description de la classe « ListeDiffusion » .......................................................... 28
Tableau 11: Description de la classe « ListeDiffusion_Destinataire» ..................................... 29
Tableau 12: Description de la classe « Message » ................................................................... 29
Tableau 13: Description de la classe « Forfait » ...................................................................... 30
Tableau 14: Description de la classe « Promotion » ................................................................ 30
Tableau 15: Description de la classe « Paiement » .................................................................. 30
Tableau 16: Description de la classe « SMS » ......................................................................... 33
Tableau 17: Comparatif des différents SGBD ......................................................................... 38
Tableau 18: Comparatif des différents serveurs d’applications ............................................... 39
Tableau 19: Coût total du projet ............................................................................................... 43
Tableau 20: Formule de calcul COCOMO ........................................................................... VIII
OUEDRAOGO DAVID PASCAL PAWINDTAORE vii

RAPPORT DE STAGE
INTRODUCTION GÉNÉRALE
U ne communication efficace doit être effectuée au bon moment et adressée au public cible
adéquat. Dans le contexte du Burkina Faso, on utilise différents canaux de
communication tel que : Facebook, WhatsApp à travers les statuts ou le bouche à oreille. Cette
situation, quoi qu’efficace pour les particuliers, se trouve très limitée pour les
entreprises. D’après le rapport du troisième trimestre de l’année 2020 sur les données du marché
national de la téléphonie mobile fourni par l’Autorité de Régulation des Communications
Électroniques et des Postes (ARCEP), le nombre de cartes SIM actives est estimé à 22 117 218
pour les trois réseaux de téléphonie mobile.
Alors que le SMS (acronyme anglais Short Message Service) demeure un canal très utilisé dans
les communications quotidiennes, son rôle dans l’expérience client est plus important que
jamais.
Fort de ce constat, la structure « OKABI Technology Services » s’est donné comme objectif de
se positionner dans ce domaine afin de proposer un système de communication basé sur les
SMS pour les professionnels et les particuliers. C’est dans ce contexte que nous avons été
accueillis au sein de ladite entreprise pour un stage de trois (3) mois afin de mettre en place une
plateforme répondant à ce besoin.
Cette plateforme web devra permettre aux professionnels et aux particuliers d’envoyer des
messages personnalisés à un ou plusieurs contacts.
Pour mener à bien cette étude, notre démarche s’articulera autour de trois axes principaux à
savoir :
v la recherche documentaire ;
v la rédaction du rapport ;
v la réalisation du système.
Le présent document détaille toutes les étapes liées au processus de réalisation de ce projet. Il
est reparti sur trois (03) grands chapitres notamment :
v La présentation des structures de formation et d’accueil ;
v La réalisation d’une plateforme web d’envoi de SMS ;
v Le bilan de notre stage à OKABI Technology Services.
OUEDRAOGO DAVID PASCAL PAWINDTAORE 1

RAPPORT DE STAGE
CHAPITRE I : PRÉSENTATION DES STRUCTURES DE

FORMATION ET D’ACCUEIL
D ans ce chapitre, nous présenterons successivement notre structure de formation qu’est

l’Institut Burkinabè̀ des Arts et Métiers (IBAM) et OKABI Technology Services, notre
structure d’accueil, l’objectif étant de montrer le cadre dans lequel se déroule le projet.
I. PRÉSENTATION DE LA STRUCTURE DE FORMATION (IBAM)
L’Institut Burkinabè̀ des Arts et Métiers (IBAM) est un établissement d’enseignement

professionnel plein de ressources et de formations qualifiantes. Il a été́ créé en janvier 2000 à
la faveur de la refondation de l’Université́ de Ouagadougou rebaptisée Université́ Joseph KI-
ZERBO.
1. Historique
Sis à Somgandé, l’Institut Burkinabè des Arts et Métiers (IBAM) est un établissement
d’enseignement professionnel. Il a été créé en janvier 2000 à la faveur de la refondation de
l’Université de Ouagadougou rebaptisée l’Université Ouaga I Pr Joseph KI-ZERBO, le 26
décembre 2015, puis plus simplement « l’Université Joseph KI-ZERBO » depuis le 12 avril
2019. L’IBAM est la matérialisation, la concrétisation dans les faits de l’engagement de
l’Université Joseph KI-ZERBO (UJKZ) dans la professionnalisation des filières. Cette nouvelle
vision a pour but d’accroître son efficacité externe.
2. Objectif
L’objectif principal de l’IBAM est de répondre aux besoins du marché de l’emploi par la mise
à disposition d’un potentiel humain de cadres moyens et supérieurs dans les divers secteurs
d’activité. Cette nouvelle orientation se justifie par l’incapacité de l’État d’embaucher tous ceux
qui sortent de l’université.

RAPPORT DE STAGE
3. Organisation
L’IBAM est organisée en une structure hiérarchico-fonctionnelle.
Nous avons :
• Le conseil de gestion qui est l’organe suprême regroupant le directeur, le directeur

adjoint, les coordonnateurs, les enseignants permanents, le CSAFC, la secrétaire
principale et le représentant du personnel ATOS ;
• Le conseil scientifique qui concerne le directeur, le directeur adjoint, les
coordonnateurs et les enseignants de rang A de l’Institut ;
• Le cabinet du directeur auquel sont rattachés directement le CSAFC, le directeur
adjoint, et la secrétaire principale qui coiffe le personnel ATOS. Au directeur adjoint
sont rattachés les coordonnateurs de filières et aux coordonnateurs de filières est rattaché
le personnel enseignant de l’Institut.
4. Filières de formation
En vue d’atteindre les objectifs cités précédemment, l’IBAM offre des formations dans
plusieurs filières. Celles-ci sont réparties en trois (03) groupes selon le diplôme ou la période
de formation.
v Licences professionnelles (Formation initiale)
Les filières de formations initiales en licences professionnelles sont :
- Assistant de Direction/Bilingue (ADB) ;

- Assurance-Banque-Finance (ABF) ;
- Comptabilité-Contrôle-Audit (CCA) ;
- Marketing et Gestion (MG) ;
- Méthodes Informatiques Appliquées à la Gestion (MIAGE).
v Licences professionnelles (Formation continue ou en soir)
L’IBAM offre aussi des formations continues ou en soirs dans les filières suivantes :
- Licence Professionnelle en Assistance Administrative (LPAA) ;

v MASTERS
En master, l’IBAM offre cinq (05) filières de formation qui sont :

RAPPORT DE STAGE
- Master en Administration et Gestion des Entreprises (MAGE) ;

- Master en Banque-Finance (MBF) ;
- Master en Comptabilité-Contrôle-Audit (MCCA) ;
- Master en Informatique, option Ingénierie des Systèmes d’Informations en
Entreprise (ISIE) ;
- Master en Informatique, option Sécurité Informatique.
v DESCOGEF
L’IBAM étant toujours dans la recherche de l’innovation, la formation en Master ne sera pas
pour lui la fin du marathon. Il poursuit son devoir de citoyenneté en donnant un ouf de
soulagement à toute personne désirant désormais avoir une formation en Expertise Comptable
au Burkina Faso avec la formation en Diplôme d’Études de Comptabilité et Gestion Financière
(DESCOGEF).
Cette formation pour l’expertise comptable en partenariat avec d’autres universités comme le
CESAG et l’IUFIC a été ouverte à partir de l’année académique 2020-2021.
En termes de perspectives, l’IBAM envisage dans les années à venir l’ouverture en formation
continue des filières professionnelles en architecture, en publicité et en statistiques appliquées,
licence en Multimédia, en Réseaux et Télécoms ainsi que des Masters en Réseaux et Télécoms.
La filière MIAGE a été créée dans l’optique de répondre aux besoins croissants des entreprises
en cadres compétents dans le domaine des Technologies de l’Information et de la
Communication (TIC). Cette filière accueille en première année les bacheliers des séries C, D
et E ayant passé avec succès le test de sélection ou ayant été acceptés en tant qu’auditeurs libres.
Les étudiants en fin de cycle en MIAGE doivent mettre en pratique les connaissances acquises
en classe en effectuant un stage d’une durée d’au moins trois (03) mois suivi d’une soutenance
publique. Ce stage a pour objectif de leur permettre de se familiariser avec le monde
professionnel et d’appliquer leurs connaissances théoriques acquises au cours de leur formation.
Il constitue la partie pratique de la formation à l’issue de laquelle un rapport est rédigé et soutenu
par l’étudiant(e) devant un jury.
C’est pour répondre à cette exigence académique que nous avons effectué notre stage pratique
à OKABI Technology Services que nous présenterons dans les lignes qui suivent.

RAPPORT DE STAGE
II. PRÉSENTATION DE LA STRUCTURE D’ACCUEIL(OKABI)

1. Histoire
OKABI TECHNOLOGY SERVICES est une entreprise de prestation de services informatiques
fondée en 2019 par de jeunes ingénieurs audacieux et rêvant d’inventer l’avenir.
Son identité repose sur l’audace et l’esprit entrepreneurial et c’est pour cela qu’elle a choisi
comme slogan « oser inventer l’avenir avec vous » : en mobilisant ces valeurs essentielles,
elle explore sans cesse de nouveaux moyens de faire levier sur les dernières évolutions
technologiques pour préparer l’avenir.
Elle a eu l’occasion de travailler au sein de grands groupes européens qui lui ont permis de
développer des compétences pointues sur les processus de développement applicatifs ainsi que
les normes industrielles dans le monde. Ces compétences larges des métiers de l’informatique
lui ont permis d’être l’interlocuteur unique pour accompagner les entreprises dans leurs
transformations digitales dans tout le Burkina Faso et en Afrique. Elle dispose d’ingénieurs et
de techniciens certifiés qui, chaque jour, ne ménagent aucun effort pour apporter leur expertise
aux entreprises qui en ont besoin pour être flexibles et efficaces.
OKABI travaille avec des entreprises de toutes tailles (3 à 500 utilisateurs) et accorde beaucoup
d’importance aux contacts humains : ses clients le savent, elle est un partenaire à leur écoute
sur lequel ils peuvent toujours compter. Elle s’adapte aux contraintes budgétaires et stratégiques
de ses clients, ce qui lui permet de construire une entreprise de plus en plus performante avec
des bases fortes : l’audace, le respect des engagements et l’innovation continue sont les maîtres
mots.
2. Vision
OKABI a pour vision d’offrir un cadre idéal pour créer une dynamique collective avec ses
collaborateurs, afin qu’ensemble ils puissent innover et changer leur quotidien par la
technologie. Et pour cela, il faut que l’ensemble de ses collaborateurs partagent les mêmes
valeurs qu’elle.
3. Services
OKABI offre des services principalement dans les trois domaines ci-après :
v Ingénierie logiciel
v Digital & Data
v Hébergement cloud

RAPPORT DE STAGE
CHAPITRE II : ANALYSE ET CONCEPTION
A près avoir présenté les structures de formation et d’accueil, nous allons dans ce chapitre,
traiter le thème soumis à notre analyse qui est « Mise en place d’un système de
communication basé sur les SMS pour les professionnels et les particuliers ». Pour ce faire
nous allons d’abord présenter notre thème, la méthode d’analyse et de conception de notre
projet, les acteurs impliqués ainsi que le planning de notre étude. Ensuite, suivra l’expression
des besoins. Puis, une étude technique et une conception détaillée du futur système seront
présentées. Enfin, nous ferons cas des différents éléments entrant dans la réalisation du projet.
I. ÉTUDE PREALABLE
Dans cette première partie, nous présenterons différentes facettes du thème de notre travail ainsi
que les éléments d’analyse et de conception de notre système.
1. Présentation du Thème
La présentation du thème s’articulera autour de deux (02) axes principaux à savoir la

problématique et les attentes de la solution proposée.
a. Problématique
Le domaine du marketing a connu une importante évolution depuis le début des années 80.
C’est ainsi que le concept de « marketing relationnel » a progressivement pris de l’ampleur tant
dans les domaines industriels, que ceux des services. En effet, le marketing relationnel est cette
démarche de fidélisation clientèle qui permet d’assurer la croissance continue d’une entreprise
sur la durée tout en l’aidant à traverser sereinement les crises économiques et les problématiques
posées par la concurrence.
Conscientes de cette réalité, bon nombre d’entreprises se sont engagées à conserver de bonnes
relations avec leurs clients et ce, en ne restant pas en marge des nouvelles technologies de
l’information et de la communication (NTIC). Dans le contexte du Burkina Faso, on utilise
différents canaux de communication tel que : Facebook, WhatsApp à travers les statuts ou le
bouche à oreille. Cette situation, quoi qu’efficace pour les particuliers, se trouve très limitée
pour les entreprises. Selon l’article du 09 mars 2021 du TIC Magazine faisant état des

RAPPORT DE STAGE
statistiques sur de l’utilisation d’Internet et des médias sociaux au Burkina Faso en 2021, le
taux de pénétration d’Internet est de 25,7%. Au regard de cette situation, plusieurs
professionnels se posent cette question : Comment communiquer avec ses clients ne disposant
pas forcement d’un accès à internet et ce à coût réduit ?
Pour y parvenir, l’entreprise OKABI Technology Services a décidé de mettre en place un outil
de communication basé sur les SMS dénommé SMS4All, sigle dérivé de « SMS for all » c’est-
à-dire « SMS pour tous », qui va permettre aux entreprises de maintenir de bonnes relations
avec leurs clients et ce à un prix imbattable. C’est dans ce cadre que nous avons été accueillis
dans ladite entreprise pour mener une réflexion sur le thème « Mise en place d'un système de
communication basé sur les SMS pour les professionnels et les particuliers ».
b. Les attentes
Au regard des besoins exprimés, les résultats attendus à l’issue de ce projet consistent à créer
une plateforme web qui permet :
v La création et l’importation des contacts ;

v l’envoi de SMS programmés ou non à un ou plusieurs contacts ;
v à terme, l’envoi de questionnaires aux différents contacts (extension future);
v la génération de données statistiques issues des réponses aux questionnaires (extension
future).
2. Méthodologie
Une méthode d'analyse et de conception est un procédé dont l’objectif est de permettre une
formalisation des étapes préliminaires du développement d'un système afin de rendre ledit
développement plus fidèle aux besoins du client.
a. Cycle de développement
Le cycle de développement constitue la démarche fondamentale permettant d’obtenir un produit

logiciel dans un délai raisonnable tout en minimisant les ressources.
Le tableau suivant résume une étude comparative entre les principales méthodologies de
développement que nous avons choisi vu la diversité de ces méthodes.

RAPPORT DE STAGE
Méthodologies Description Points forts Points faibles
Cascade Ø Les phases sont Ø Distingue clairement les Ø Non itératif.

déroulées d’une phases du projet. Ø Pas de modèles
manière pour les
séquentielle. documents.
RUP (Rational Ø Le RUP est à la Ø Itératif. Ø Assez flou dans
fois une Ø Spécifie le dialogue sa mise en œuvre.
Unified
méthodologie et entre les différents Ø Ne couvre pas les
Process)
un outil prêt à intervenants du projet. phases en amont
l’emploi. Ø Propose des modèles de et en aval au
Ø Cible des documents pour des développement.
projets de plus projets types.
de 10
personnes.
2TUP (Two Ø S’articule Ø Itératif. Ø Plutôt superficiel
Truck Unified autour de Ø Laisse une large place à sur les phases
Process) l’architecture. la technologie et à la situées en amont
Ø Propose un gestion des risques. et en aval du
cycle de Ø Définit les profils des développement.
développement intervenants, les Ø Ne propose pas
en Y. plannings, les de documents
Ø Cible des prototypes. types.
projets de toutes
tailles.
XP (eXtreme Ø Ensemble des Ø Itératif. Ø Assez flou dans
bonnes Ø Donne une importance sa mise en
Programming)
pratiques de aux aspects techniques. œuvre.
développement. Ø Innovant : Ø Ne couvre pas
Ø Cible : Moins programmation en duo. les phases en
de 10 amont et en aval
personnes. au
développement.

RAPPORT DE STAGE
Scrum Ø Se base sur des Ø Donne toute confiance Ø La mise en

itérations dites aux développeurs et les œuvre du
sprints de laisser faire leur travail. développement
développement Ø Chaque itération a un n’est pas
objectif bien précis et précisée.
fournit une Ø Développement
fonctionnalité testée. rapide et répétitif
se traduit par une
forte pression sur
l’ensemble des
membres de
l’équipe de
développement.
Tableau 1 :Comparaison des méthodologies de développement

L’étude comparative réalisée sur les processus de développement RUP, XP, 2TUP, Cascade et
Scrum résumés dans le tableau 3 nous permet de tirer les conclusions suivantes :
- le processus RUP néglige les contraintes techniques qui sont indispensables dans notre
projet, nous avons par conséquent choisi de l’écarter,
- le processus XP néglige la phase de capture de besoins fonctionnels et techniques et la
phase de conception et donne une grande importance à la phase de développement, il
est par conséquent écarté,
- CASCADE est un processus séquentiel et non itératif,
- Scrum quant à lui subdivise les différentes phases du projet en sprint qui en théorie ne
dépasse pas 30 jours,
- le processus 2TUP permet en particulier de séparer les contraintes fonctionnelles des
contraintes techniques érigées sous forme de deux branches permettant de les exploiter
parallèlement.
Suite à l’étude et à la comparaison des processus de développement et aux fins de contrôler les
risques et de mener à bon terme notre projet, nous avons opté pour le processus 2TUP pour
plusieurs raisons :
- d’une part, 2TUP donne une grande importance à la technologie ce qui est important
pour notre projet ;

RAPPORT DE STAGE
- d’autre part, 2TUP est un processus en Y qui contient une branche technique, une
branche fonctionnelle et une branche réalisation. Les deux branches technique et
fonctionnelle peuvent être exploitées en parallèle. De ce fait, si la technologie évolue
ou, s’il arrive que lors du déroulement du projet, il y a modification d’un besoin
technique, la branche technique peut être traitée puis réintégrée dans le projet
facilement. De même si une nouvelle fonctionnalité se présente, seule la branche
fonctionnelle va être traitée sans toucher à l’autre branche.
Le processus utilisé pour réaliser ce projet est le 2TUP (2 Track Unified Process) qui est un
processus de développement logiciel implémentant le processus unifié.
Le 2TUP propose un cycle de développement en « Y » (Figure 1), qui dissocie les aspects
techniques des aspects fonctionnels. Il commence par une étude préliminaire qui consiste
essentiellement à identifier les acteurs qui vont interagir avec le système à construire, à
identifier les messages qu'échangent les acteurs et le système, à produire le cahier des charges
et à modéliser le contexte.
Le processus s'articule autour de trois (3) phases essentielles :
ü Une branche fonctionnelle qui comporte :

• La capture des besoins fonctionnels, qui produit un modèle des besoins focalisés
sur le métier des utilisateurs. Elle qualifie au plus tôt le risque de produire un
système inadapté aux utilisateurs. De son côté, la maîtrise d’œuvre consolide les
spécifications et en vérifie la cohérence et l’exhaustivité ;
• L’analyse qui consiste à étudier précisément la spécification fonctionnelle de
manière à obtenir une idée de ce que va réaliser le système en termes de métier.
Les résultats de l’analyse ne dépendent d’aucune technologie particulière.
ü Une branche technique qui comporte :

• La capture des besoins techniques, qui recense toutes les contraintes et les choix
dimensionnant la conception du système. Les outils et les matériels sélectionnés
ainsi que la prise en compte de contraintes d’intégration avec l’existant
conditionnent généralement des prérequis d’architecture technique ;
• La conception générique, qui définit ensuite les composants nécessaires à la
construction de l’architecture technique. Cette conception est complètement
indépendante des aspects fonctionnels. Elle a pour objectif d’uniformiser et de

RAPPORT DE STAGE
réutiliser les mêmes mécanismes pour tout un système. L’architecture technique

construit le squelette du système informatique et écarte la plupart des risques de
niveau technique. L’importance de sa réussite est telle qu’il est conseillé de
réaliser un prototype pour assurer sa validité.
ü Une phase de réalisation qui comporte :
• La conception préliminaire, qui représente une étape délicate, car elle intègre le
modèle d’analyse dans l’architecture technique de manière à tracer la cartographie
des composants du système à développer ;
• La conception détaillée, qui étudie ensuite comment réaliser chaque composant ;
• L’étape de codage, qui produit ces composants et teste au fur et à mesure les unités
de code réalisées ;
• L’étape de recette, qui consiste enfin à valider les fonctions du système développé.
Figure 1: Schéma présentant le processus 2TUP
Source : https://images.app.goo.gl/3RovscgRg37mduii9

RAPPORT DE STAGE
Le processus 2TUP s’appuie sur UML tout au long du cycle de développement, car les
différents diagrammes de ce dernier permettent en plus de leur facilité et de leur clarté, de bien
modéliser le système à chaque étape.
b. Langage de modélisation
Un langage de modélisation est un langage artificiel qui peut être utilisé pour exprimer
l’information ou la connaissance des systèmes dans une structure qui est définie par un
ensemble cohérent de règles.
Pour développer une application, il faut d’abord organiser les idées, les documenter avant
de commencer la réalisation tout en définissant les modules et les étapes. On appelle cette
démarche « modélisation ». Pour réaliser cette modélisation, nous allons utiliser le langage
UML (voir ANNEXE 2 : Le langage UML) pour plusieurs raisons.
Nous pouvons citer entre autres qu’il :
ü présente l'avantage d'être le standard en matière de modélisation objet

universellement reconnu ;
ü est un langage visuel, car sa notation graphique permet d’exprimer visuellement des
solutions objets facilitant ainsi la comparaison et l'évaluation de celles-ci ;
ü est un langage formel et normalisé doté d'un gain de précisions et d'un gage de stabilité
;
ü sert à formaliser tous les documents techniques d'un projet et permet d'affiner les
détails de l'analyse au fur et à mesure de l'avancée du projet ;
ü est capable d'utiliser le même atelier de génie logiciel, depuis l'expression des besoins
des utilisateurs jusqu'à la génération de tout ou partie du code ;
ü est un support de communication performant, car il cadre l'analyse tout en facilitant
la compréhension des représentations abstraites complexes.
3. Groupe de travail
Les acteurs constituent l’ensemble des personnes nécessaires pour la réalisation de ce projet.
On les classe en trois (03) groupes distincts travaillant en synergie. Il s’agit du groupe de
pilotage, du groupe de projet et du groupe des utilisateurs.

RAPPORT DE STAGE
a. Groupe de pilotage
C’est le groupe dirigeant chargé de veiller au bon déroulement du projet. Il planifie les dates
clés du projet, examine les propositions du groupe de projet, et décide des orientations
stratégiques. Ce groupe est constitué de :
❖ M. Lael DARGA, notre maitre de stage

❖ M. Oumarou KABORE
❖ M. Ilias OUEDRAOGO
b. Groupe de projet
Le groupe de projet est l’ensemble des personnes chargées de réaliser le projet. Il est
l’intermédiaire entre le groupe de pilotage et le groupe des utilisateurs. Ce groupe est composé
principalement de David Pascal Pawindtaoré OUEDRAOGO, étudiant en troisième (3ème)
année en Méthodes Informatiques Appliquées à la Gestion (MIAGE) à l’IBAM.
c. Groupe des utilisateurs

Ce groupe représente l’ensemble de tous ceux qui vont utiliser le futur système. Il participe à la
capture des besoins fonctionnels. Il s’agit de notre public cible, c’est-à-dire de l’ensemble des
personnes qui se rendront ou seront susceptibles de se rendre sur notre plateforme.
d. Planning de réalisation
Pour mener à bien notre étude et la réaliser dans les délais, nous avons subdivisé le projet en
tâches. Pour cela, nous avons utilisé le diagramme de Gantt qui est un outil utilisé en
ordonnancement et en gestion de projet ; il permet de visualiser (à l’aide d’un graphe) dans le
temps les différentes tâches liées à un projet. Le planning prévisionnel est résumé dans le
tableau ci-dessous :

RAPPORT DE STAGE
Figure 2: Planning de réalisation du projet
Après cette phase d’étude préalable du système, nous allons passer à la phase d’expressions des
besoins.
II. EXPRESSIONS DES BESOINS
Cette partie consiste à identifier les différents acteurs qui vont interagir avec le futur système
ainsi que les différents messages qu’ils échangeront entre eux.
1. Présentation du processus de fonctionnement de la plateforme web SMS4All.

Le système SMS4All devra permettre aux professionnels et aux particuliers d’envoyer des SMS
à plusieurs contacts. L’utilisation de notre plateforme nécessite, tout d’abord, la création d’un
compte pour s’enregistrer. Ensuite, on procèdera à l’ajout de contacts soit un a un, soit de
manière groupée à partir d’un fichier. Des lors, l’utilisateur peut envoyer des messages tant
qu’il dispose d’un solde suffisant. Ledit solde sera fonction de l’état du forfait choisi parmi les
offres proposées par la plateforme.
En option, des listes de diffusion peuvent être créées afin de faciliter l’envoi groupé de
messages. L’utilisateur peut également programmer l’envoi automatique des messages suivant
un horodatage précis.
1. Spécification fonctionnelle
La spécification fonctionnelle est la description des fonctions d’un logiciel en vue de sa
réalisation. Dans cette partie, nous décrirons dans les détails les exigences du futur système à
travers l’identification des acteurs, des cas d’utilisation et les différents diagrammes.
a. Identification des acteurs

Un acteur définit un ensemble cohérent de rôles qu’un utilisateur ou une entité externe peut
jouer en interagissant avec le système. Dans notre cas il s’agit bien :
v du gestionnaire : c’est l’agent chargé de la gestion de la plateforme au niveau de OKABI
v du client : c’est toute personne physique ou morale ayant souscrit au service de
SMS4All
v des destinataires : ce sont les personnes à qui sont destinés les messages envoyés depuis
la plateforme SMS4All

RAPPORT DE STAGE
b. Identifications des cas d’utilisations

Les cas d’utilisations désignent l’ensemble des interactions qui vont permettre à l'acteur
d'atteindre son objectif en utilisant le système. Le tableau suivant liste les cas d’utilisation de
notre futur système.
Numéro Cas d’utilisation Description Acteurs

Permet aux utilisateurs de se
CU01 S’authentifier Gestionnaire, Client
connecter à l’application
Permet d’enregistrer, modifier et
CU02 Gérer forfaits Gestionnaire
supprimer les forfaits
CU03 Gérer les promotions Gestionnaire
supprimer les promotions
Permet de choisir un forfait afin
CU04 Choisir un forfait Client
de pouvoir envoyer des sms
CU05 Gérer les contacts Client
supprimer les contacts
CU06 Gérer liste de diffusion Client
supprimer les listes de diffusions
Permet d’envoyer un message
Envoyer un message non
CU07 instantané à une ou plusieurs Client
programmé
listes de diffusions
Permet de prévoir l’envoi d’un
CU08 Envoyer un message programmé message à une ou plusieurs listes Client
de diffusions
Permet d’afficher la liste des
CU09 Consulter historique Client
messages envoyés
Permet de répondre à un message
CU10 Réponse Destinataire
reçu

RAPPORT DE STAGE
Tableau 2: Liste des cas d’utilisation
c. Diagramme de cas d’utilisation
Le diagramme de cas d’utilisation est un diagramme UML utilisé pour donner une vision
globale du comportement fonctionnel d’un système logiciel. Il permet d’une part de modéliser
les besoins des utilisateurs en les clarifiant et en les organisant et d’autre part d’identifier les
acteurs et les fonctionnalités du système comme le montre la figure ci-dessous :
Figure 3: Diagramme de cas d’utilisation

RAPPORT DE STAGE
d. Description textuelle de certains cas d’utilisation
Contrairement au diagramme de cas d’utilisation qui décrit les grandes fonctions du système
du point de vue des acteurs, la description textuelle permet d’exposer de façon détaillée le
dialogue entre les acteurs et le système. Pour faciliter la lecture de notre rapport nous nous
limiterons à la description de trois (4) cas d'utilisation.
Les cas d’utilisation qui sont décrits dans cette partie sont essentiellement : authentification,
ajouter un contact, envoyer un message non programmé et envoyer un message programmé.
v CU01 : Authentification
Résumé Ce cas permet à l’utilisateur de de s’authentifier au système
Acteur(s) Gestionnaire, Client
Préconditions Disposer d’une connexion internet et de navigateur internet
Scénario Nominal 1. L’utilisateur demande à se connecter
2. Le système l’affiche un formulaire de connexion
3. L’utilisateur rempli le formulaire et soumet au
système
4. Le système vérifie les données saisies [A]
5. Le système affiche la page principale
Scénario Alternatif [A] : L’identifiant et/ou le mot de passe sont incorrects
a. Le système notifie l’utilisateur de l’échec de
la connexion
b. Le système renvoi le formulaire de
connexion et le scénario reprend à partir du
point 3 du scénario nominal.
Post conditions L’utilisateur accède à son tableau de bord
Tableau 3: Description du CU « Authentification »

RAPPORT DE STAGE
v CU05 : Ajouter un contact

Résumé Ce cas permet d’ajouter un contact
Acteur(s) Client
Préconditions L’utilisateur est authentifié
Scénario Nominal 1. L’utilisateur demande à ajouter un contact
2. Le système lui envoi le formulaire
3. Il remplit le formulaire d’ajout
4. Le système vérifie les données[A]
5. Le système notifie que le contact a été enregistré
Scénario Alternatif [A] : Le numéro de téléphone est invalide ou existe déjà
1. Le système notifie une erreur à l’utilisateur
2. Le système renvoi le formulaire de contact et le
scénario reprend à partir du point 3 du scénario nominal.
Post conditions Le nouveau contact est enregistré dans le système.
La page des contacts s’affiche
Tableau 4: Description du CU « Ajouter un Contact »

RAPPORT DE STAGE
v CU07 : Envoyer message non programmé

Résumé Ce cas permet d’envoyer un message à une liste de contacts
Acteur(s) Client
Préconditions L’utilisateur est authentifié ;
Les contacts et au moins une liste de diffusion sont
enregistrées
Scénario Nominal 1. Il choisit l’option « envoyer message » du menu
2. Le système affiche le formulaire de message
3. Il remplit le formulaire
4. Vérifier si le solde est suffisant pour envoyer le
message [A]
5. Le message est envoyé aux contacts
Scénario Alternatif [A] : Le solde est insuffisant
1. Le système envoi une notification lui informant de
renouveler son abonnement
2. Le message est mis en attente
Post conditions La page des messages envoyés s’affiche
Tableau 5: : Description du CU « Envoyer un message non programmé »

RAPPORT DE STAGE
v CU08 : Envoyer message programmé

Résumé Ce cas permet de prévoir l’envoi d’un message à une liste
de contacts à une date donnée
Acteur(s) Client
Préconditions L’utilisateur est authentifié ;
Les contacts et au moins une liste de diffusion sont
enregistrées
Scénario Nominal 1. Il choisit l’option « envoyer message » du menu
2. Le système affiche le formulaire de message
3. Il remplit le formulaire
4. Vérifier si le solde est suffisant pour envoyer le
message [A]
5. Le message est enregistré
Scénario Alternatif [A] : Le solde est insuffisant
1. Le système envoi une notification lui informant de
renouveler son abonnement avant la date d’envoi
Post conditions La page des messages programmés s’affiche
Tableau 6: Description du CU « Envoyer message programmé »
e. Diagramme de séquence
Les diagrammes de séquences représentent les interactions entre le système et les utilisateurs
en montrant sous forme de scénarios la chronologie des envois de messages issus d’un cas
d’utilisation donné. Les diagrammes de séquences qui sont décrits dans cette partie sont
essentiellement :
- Authentification (figure 4)
- Ajouter un contact (figure 5) et
- envoyer un message (figure 6).

RAPPORT DE STAGE
Figure 4 : Diagramme de séquence vue de l’extérieur pour le CU « Authentification »

RAPPORT DE STAGE
Figure 5: Diagramme de séquence vue de l’extérieur pour le CU « Ajouter un contact »

RAPPORT DE STAGE
Figure 6 : Diagramme de séquence vue de l’extérieur pour le CU « Envoyer un message »
3. Spécification technique
La spécification technique est la description des choix techniques pris pour satisfaire les
spécifications fonctionnelles et les besoins.
a. Mise à disposition des conditions de travail
OKABI Technology Services a mis à notre disposition un serveur et une connexion internet
haut débit pour nos recherches.

RAPPORT DE STAGE
b. Architecture de développement
Une architecture en informatique désigne un mode de communication à travers un réseau entre

plusieurs éléments physiques et/ou logiques. Il en existe plusieurs types. Mais nous en
présenterons ici les plus répandues que sont les architectures deux (2) tiers et trois (3) tiers.
v Architecture deux (2) tiers
Cette architecture, aussi appelée architecture client/serveur de première génération, est
constituée de deux niveaux :
ü un Client qui gère la présentation et la logique applicative ;
ü un Serveur qui stocke les données de façon cohérente et éventuellement une partie de
la logique applicative.
La communication entre ces deux parties se fait en utilisant le langage SQL. Dans ce type
d’architecture, on constate une certaine indépendance du client par rapport au serveur. Dans ce
contexte, l’application devra être installée sur tous les postes clients c’est-à-dire sur toutes les
machines des différents acteurs du système. Quant à la base de données, elle sera sur un serveur
de données centralisé.
La figure suivante représente cette architecture.
Figure 7 : Schéma présentant l’architecture 2 tiers

Source : https://www.geonov.fr/architecture-client-serveur
Ø Avantages
L’architecture deux (2) tiers présente les avantages suivants :
• elle permet une exploitation multi-utilisateur de l’application : plusieurs utilisateurs
peuvent avoir accès à la même base de données ;
• elle répartit les charges entre les machines : le client s’occupe de l’interface
graphique ainsi que des traitements sur les données tandis que le serveur s’occupe
de la recherche des données pour satisfaire aux requêtes des clients;

RAPPORT DE STAGE
• elle offre une bonne sécurité des données : la sécurité des données est assurée au
niveau du système de gestion de la base de données.
Ø Inconvénients
• le coût de déploiement est élevé : il faut installer l’application sur tous les postes
clients et les configurer ;
• l’évolution du système est difficile à réaliser: à chaque mise à jour de l’application
correspond un redéploiement sur tous les postes clients, ce qui entraîne de nouveaux
coûts.
v Architecture trois (3) tiers
L’architecture trois (3) tiers, aussi appelée client/serveur de seconde génération, comporte trois
(3) niveaux dans l’application qui sont :
ü le Client léger : encore appelé « niveau présentation » dont le rôle principal est
l’affichage des résultats et la transmission des informations saisies par l’utilisateur final
vers le tiers suivant. Dans la pratique, le client léger est tout simplement un navigateur
Web qu’on aura configuré à cet effet ;
ü le Serveur d’application ou serveur applicatif : c’est la pièce maîtresse de
l’architecture. En effet, les traitements et les contrôles d’intégrité des données sont
effectués à ce niveau ;
ü le Serveur de données ou la base de données : C’est la partie qui s’occupe du stockage
et de la recherche des données en réponse aux requêtes du serveur d’application.
La figure suivante représente cette architecture.
Figure 8 : Schéma présentant l’architecture 3 tiers

Source : https://www.geonov.fr/architecture-client-serveur

RAPPORT DE STAGE
Ø Avantages
Cette architecture se développe très vite grâce à ses multiples avantages que sont :
• une bonne disponibilité et une évolution facile : les applications trois (3) tiers sont
caractérisées par une facilité d’exploitation et une grande flexibilité pour l’évolution ;
En effet, les mises à jour sont faites au niveau du serveur d’application, ce qui n’entraîne
pas le redéploiement sur les postes clients ;
• un déploiement aisé : l’application n’est déployée que sur le serveur d’application. Les
clients n’ont besoin que d’un navigateur web compatible avec l’application ;
• une sécurité accrue : ces types d’application possèdent une grande sécurité des données.
En effet, l’accès à la base de données est effectué uniquement par le serveur
d’application contrairement aux applications deux tiers où tous les utilisateurs sont
connectés à la base. Il suffit donc de gérer la sécurité au niveau du serveur d’application.
Ø Inconvénients
Cette technologie est nouvelle et nécessite un personnel informatique initié pour sa mise en
œuvre. De plus, il est recommandé d’exploiter ce type d’architecture dans un réseau haut débit.
Solution retenue : A la suite de l’étude comparative que nous avons menée sur les deux (2)
types d’architectures, notre choix se porte sur l’architecture trois (3) tiers. En effet, cette
dernière se conforme aux standards d’architectures d’applications suivis par OKABI
Technology Services.
III. CONCEPTION GLOBALE
Dans cette partie, nous mettrons en évidence le dictionnaire de données, le diagramme des
classes, le diagramme d’activité du CU « Envoyer Message » ainsi que celui du déploiement.
1. Diagramme des classes
Dans cette partie nous mettrons en évidence notre dictionnaire de données, puis notre
diagramme de classes.

RAPPORT DE STAGE
a. Dictionnaire de données
Le dictionnaire de données contient l’ensemble des descriptions des attributs de chaque classe
qui est utilisé dans le système. Pour faciliter la lecture, nous allons faire la description classe
par classe.
v Classe : Entreprise
Attribut Description Type de donnée
IdCompte Identifiant de l’entreprise Entier
NomEntreprise Nom de l’entreprise Chaine de caractère
Sigle Sigle de l’entreprise Chaine de caractère
Téléphone Numéro de téléphone de l’entreprise Chaine de caractère
Email Adresse mail de l’entreprise Chaine de caractère
Solde Solde de l’entreprise Entier
DateCreation Date de création de l’entreprise Date
DateModif Date de la dernière modification Date
Statut État de l’entreprise (Actif ou Inactif) Chaine de caractère
Tableau 7: Description de la classe « Entreprise »
v Classe : Utilisateur
IdUtilisateur Identifiant de l’utilisateur Entier
Pseudo Nom d’utilisateur Chaine de caractère
Password Mot de passe de l’utilisateur Chaine de caractère
Nom Nom de l’utilisateur Chaine de caractère
Prénom Prénom(s) de l’utilisateur Chaine de caractère
FlagSuppr Champ qui vérifie si le compte est Booléen
supprimé ou pas
Statut État de l’utilisateur (Actif ou Inactif) Chaine de caractère
DateCreation Date de création de l’utilisateur Date
Tableau 8: Description de la classe « Utilisateur »

RAPPORT DE STAGE
v Classe : Destinataire
IdDestinataire Identifiant du contact Entier
Nom Nom du contact Chaine de caractère
Prénom Prénom(s) du contact Chaine de caractère
Statut État du contact (Actif ou Inactif) Chaine de caractère
DateCreation Date de création du contact Date
DateSuppr Date de suppression Date
FlagSuppr Champ qui vérifie si le contact est Booléen
supprimé ou pas
Téléphone Numéro de téléphone du contact Chaine de caractère
Tableau 9: Description de la classe « Destinataire »
v Classe : ListeDiffusion
IdListe Identifiant de la liste de diffusion Entier
Nom Nom de la liste de diffusion Chaine de caractère
NbDestinataires Nombre de destinataires dans la liste Entier
Statut État de la liste (Actif ou Inactif) Chaine de caractère
DateCreation Date de création de la liste de diffusion Date
FlagSuppr Champ qui vérifie si la liste est supprimé Booléen
ou pas
Tableau 10: Description de la classe « ListeDiffusion »

RAPPORT DE STAGE
v Classe : ListeDiffusion_Destinataire
DateAffectation Date d’affectation du destinataire à la Date
liste de diffusion
Tableau 11: Description de la classe « ListeDiffusion_Destinataire»
v Classe : Message
IdMessage Identifiant du message Entier
Titre Titre du message Chaine de caractère
Contenu Contenu du message Chaine de caractère
FlagProg Champ qui vérifie si le message est Booléen
programmé ou pas
Statut État du message (Actif ou Inactif) Chaine de caractère
DateEnvoi Date d’envoi effective du message Date
Heure Heure d’envoi effective du message Heure
DateEnvoiPrevu Date d’envoi prévu du message Date
HeureEnvoiPrevu Heure d’envoi prévu du message Heure
DateCreation Date de création du message Date
FlagSuppr Champ qui vérifie si le message est Booléen
supprimé ou pas
Tableau 12: Description de la classe « Message »

RAPPORT DE STAGE
v Classe : Forfait
CodeForfait Code du forfait Chaine de caractère
Montant Montant ou cout du forfait Entier
NbSMS Quantité de sms pouvant être envoyé Entier
DateCreation Date de création du forfait Date
Statut État du forfait (Actif ou Inactif) Chaine de caractère
Tableau 13: Description de la classe « Forfait »
v Classe : Promotion
CodePromotion Code de la promotion Entier
Pourcentage Taux de réduction Entier
DateDebut Date de début de la promotion Date
HeureDebut Heure de début de la promotion Heure
DateFin Date de fin de la promotion Date
HeureFin Heure de fin de la promotion Heure
DateCreation Date de création de la promotion Date
Statut État de la promotion (Active ou Inactive) Chaine de caractère
Tableau 14: Description de la classe « Promotion »
v Classe : Paiement
DatePaiement Date de paiement du forfait Date
Type Mode de paiement choisi Chaine de caractère
Agent Utilisateur ayant effectué le paiement Entier
Tableau 15: Description de la classe « Paiement »
b. Diagramme de classes
Le diagramme de classe exprime la structure statique du système en ce qui concerne les classes
et la relation entre ces classes.

RAPPORT DE STAGE
Figure 9: Diagramme de classes

RAPPORT DE STAGE
2. Diagramme d’activité
Le diagramme d’activité permet de faire une représentation graphique du déroulement d’un cas d’utilisation.
Le cas d’utilisation mis en exergue ici est « Envoyer un message » avec une vue sur les flots de données.
Figure 10: Diagramme d’activité du CU « Envoyer un message »

RAPPORT DE STAGE
NB : L’objet SMS est une instance d’une classe SMS non persistée en base de données destinée à structurer les
informations à envoyer au « Microservice 1SMS » pour l’envoi des SMS. Ainsi le tableau ci-dessous décris son
contenu :

SenderName Le nom du client qui envoi le message Chaine de caractères
SenderAdress Le numéro de téléphone du client Chaine de caractères
Adress La liste contenant les numéros de Tableau de chaines de
téléphones des destinataires du message caractères
Content Le contenu du message Chaine de caractères
Tableau 16: Description de la classe « SMS »
3. Diagramme de déploiement
Le diagramme de déploiement est un diagramme UML qui montre la configuration physique des différents
éléments qui participent à l’exécution du système, ainsi que les instances de composants qu’ils supportent. Il
est constitué de « nœuds » connectés par des liens physiques.
1
En informatique, les microservices sont une technique de développement logiciel — une variante du style architectural de
l'architecture orientée services (SOA) — qui structure une application comme un ensemble de services faiblement couplés. Les
microservices indépendants communiquent les uns avec les autres en utilisant des API indépendantes du langage de programmation.

RAPPORT DE STAGE
Figure 11 : Diagramme de déploiement
Notre diagramme de déploiement comprend quatre (4) nœuds qui représentent le serveur de
données, le serveur d’application, le poste client et l’API Gateway ou passerelle API.
En effet l’API Gateway est tel un annuaire répertoriant tous les microservices disponibles et il est chargé de
retrouver le microservice désiré.
Ce diagramme de déploiement laisse entrevoir l’architecture logicielle trois (3) tiers qui est utilisée pour ce
système.
Après cette partie consacrée à la conception globale du système, nous passons maintenant à la réalisation du
système en question.

RAPPORT DE STAGE
IV. RÉALISATION
Dans le cadre de la réalisation de ce système informatisé, nous avons utilisé plusieurs outils et techniques. Ainsi,
nous présentons d’abord les outils de développement utilisés et les politiques de test et de sécurité du système.
Ensuite, nous évoquons l’estimation financière de la mise en place de la plateforme. Enfin, nous présentons
quelques écrans de celle-ci.
1. Présentation des outils de développement
Un outil de développement est un logiciel qui aide un développeur dans le déroulement d’une activité de
développement.
a. Choix du Système de Gestion de Base de Données
Nous distinguons plusieurs SGBD dont les plus connus sont :

ü Microsoft Office Access;
ü Microsoft SQL Server;
ü MySQL ;
ü Oracle Database ;
ü PostgreSQL.
La liste comparative de ces SGBD est dans le tableau suivant :

RAPPORT DE STAGE
SGBD Avantages Inconvénients

Microsoft ü Très puissant et très ludique ü Gourmand en ressources réseau
Office ü Une grande série d'outils de ü Non convenable aux applications
Access conversion de données distantes.
ü Une forte intégration de ü Mono-plateforme (MS Windows)
Microsoft Office/VBA, ü Non implémentation complète de la
ü Une possibilité de développer norme SQL.
des applications Runtime
Microsoft ü Administration aisée ü Une licence très couteuse du produit,

SQL Server ü Fonction d'audit évolué ü Mono-plateforme (MS Windows)
ü Optimiseur statistique enrichi à ü Pas de prise en charge du LDAP
flux tendu ü Toujours pas de cluster (hormis en actif-
ü Langage T-SQL très convivial, passif, en se basant sur le cluster OS)
intégration de CLR ü Pas certifié SQLJ, pas d'intégration
ü Services Web Java, orientation C#
ü Support XML ü Pas de contraintes d'unicité multi null
ü Ordonnanceur intégré
MYSQL ✓ Rapide ü Non convenable aux grosses bases de
✓ Plus simple à utiliser données
✓ Multiplateforme (Windows, ü Les fonctionnalités limitées

Unix, Linux, etc.) ü Présente une sécurité moyenne
✓ gratuit ü Ne permet pas la reprise à chaud
✓ Facile à installer
✓ S’intègre facilement dans
l’environnement Apache

RAPPORT DE STAGE
Oracle ü Fourniture de technologies de ü Prix élevé
haut niveau et des solutions ü Une administration complexe
d’affaires intégrées
✓ Porosité entre les schémas
ü Fiabilité
✓ Une gestion des verrous mortels mal
✓ Intègre la technologie flashback conçue
ü Récupération efficace des ✓ Nombreuses failles de sécurités liées à
données incorrectement l'architecture elle-même
supprimées ou perdues grâce à
flashback d’Oracle
ü Fournit des bases de données
fiables et compétentes grâce aux
quatre propriétés (Atomicité,
cohérence,
isolation et durabilité)
PostgreSQL ü OpenSource et gratuit ü Pas possible de requêter sur plusieurs
ü Fiable et relativement bases à la fois : chaque base nécessite sa
performant, connexion
ü Supporte la majorité du standard ü Sauvegardes peu évoluées
SQL-92 ü Supporte les bases de moyenne
ü Possède de nombreuses importance
extensions (Java, Ruby, PL- ü Pas de services Web
SQL) ü Pas d'ordonnanceur intégré
ü Très riche fonctionnellement, ü Pas de fonctions d'agrégat OLAP
ü Simple d'utilisation et ü Pas de requêtes récursives
d'administration

RAPPORT DE STAGE
ü Héritage de tables
Tableau 17: Comparatif des différents SGBD
Solution retenue : À travers l’étude comparative que nous venons de mener au Tableau
16 et du contexte de notre système, nous portons notre choix sur le SGBD PostgreSQL
version 13. En effet, PostgreSQL est gratuit et open source ; il est facile à déployer et
peut également contenir de très grandes quantités de données. Aussi, il offre une
interface web, « pgAdmin » pour l’administration de ses bases de données.
b. Languages de programmation
Un algorithme est un ensemble d’opérations à mener afin d’atteindre un résultat donné.

Afin de formuler ces algorithmes, dans le domaine informatique, nous utilisons des
langages de programmation.
Nous avons utilisé plusieurs langages pour le développement de notre

application.
Ce sont :
ü Java : Java est un langage de programmation orientée objet. (Pour les classes
métiers et les entités) ;
ü TypeScript : c’est un langage de programmation libre et open source développé
par Microsoft qui a pour but d'améliorer et de sécuriser la production de code
JavaScript ;
ü HTML 5 (HyperText Markup Language) : est un langage de marquage et de
balisage servant à écrire des pages pour le World Wide Web. (Pour les pages
web);
ü CSS 3 (Cascading Style Sheet): le CSS permet de faire la mise en forme des pages web.
c. Serveur d’application
Un serveur d’application met à la disposition des utilisateurs les différents services qu’il
héberge. Ces applications peuvent être accédées via un navigateur web. Il existe
plusieurs serveurs d’application parmi lesquels nous pouvons citer :

RAPPORT DE STAGE
ü Glassfish ;
ü Oracle WebLogic Server ;
ü Tomcat ;
ü Wildfly.
La liste comparative de ces serveurs d’applications se trouve dans le tableau ci-dessous.
Serveur Critères de comparaison

d’application Mémoire Démarrage Configuration Communauté Prix Liste des composants
GlassFish est certifié Java
EE 5 (EJB3, JPA, JSF,
Glassfish Légère Rapide Facile Forte gratuit JAX-WS 2.x, ...) et Java
EE 6 (EJB, CDI, JSF,
JAX-RS , ...)
Oracle
Serveur complet avec tous
WebLogic Légère Rapide Facile Très forte Payant
les composants.
Server
Serveur léger. Tomcat est

Très Très
Tomcat Très facile Forte gratuit un conteneur de servlet.
légère rapide
Composants limités
Serveur complet,
Très Très implémente entièrement
Wildfly Très facile Très forte gratuit
légère rapide l'ensemble des services
Java EE
Tableau 18: Comparatif des différents serveurs d’applications
Solution retenue : Apache Tomcat. En tant qu'implémentation de référence de

plusieurs versions des spécifications servlets, facile à mettre en œuvre et riche en
fonctionnalités, Tomcat est quasi incontournable dans les environnements de
développement. Les qualités de ses dernières versions lui permettent d'être

RAPPORT DE STAGE
fréquemment utilisé dans des environnements de production.
d. Plateforme de développement (Frameworks)
Un framework appelé aussi infrastructure logicielle désigne un ensemble cohérent de

composants logiciels structurels, qui sert à créer les fondations ainsi que les grandes
lignes de tout ou d’une partie d'un logiciel. Il est conçu en vue d'aider les programmeurs
dans leur travail. Les frameworks que nous avons utilisés sont :
Ø Spring Boot 2.5.3 : Spring Boot est un framework qui facilite le développement
d'applications fondées sur Spring en offrant des outils permettant d'obtenir une
application packagée en jar, totalement autonome. Pour la création de nos API, nous
l’avons associé au gestionnaire de dépendances Maven et également à Hibernate, qui
gère la persistance des objets en base de données relationnelle.
Ø Angular 12 : Angular est un Framework open source écrit en JavaScript qui permet la
création d’applications Web et plus particulièrement de ce qu’on appelle des « Single
Page Applications » : des applications web accessibles via une page web unique qui
permet de fluidifier l’expérience utilisateur et d’éviter les chargements de pages à
chaque nouvelle action.
Ø Bootstrap 4.3.1 : Bootstrap est une boîte à outils open source pour le développement
avec HTML et CSS.
e. Outils de conception
Les outils de conception désignent l’ensemble des outils utilisés depuis la conception jusqu’à
la réalisation du projet. Ce sont :
ü Adobe XD version 44.1.12 : c’est un outil de prototypage de site web et d’application

; il nous a permis de concevoir les maquettes des différents écrans de notre application
ü Power AMC version 15.1 : c’est un outil de conception ; il nous a donc permis de
concevoir nos différents diagrammes UML.
ü GanttProject : Il a servi à mettre en place notre diagramme de GANTT.
ü pgAdmin version 4 : il nous a été utile pour administrer notre base de données.
ü Git version 2.22.0 : Git est un logiciel de gestion de versions décentralisé. Il nous a
permis de gérer et archiver le code source de la plateforme.
ü GitLab : c’est un logiciel web libre offrant un système de suivi des bugs et
permettant l’intégration continue et la livraison continue. Présenté comme la

RAPPORT DE STAGE
plateforme des développeurs modernes, il offre la possibilité de gérer ses

dépôts Git et ainsi de mieux appréhender la gestion des versions de vos codes
sources.
ü Jenkins : c’est un outil open source de serveur d’automatisation. Il aide à
automatiser les parties du développement logiciel liées au build, aux tests et
au déploiement, et facilite l’intégration continue et la livraison continue.
ü Visual Studio Code : c’est un éditeur de code extensible développé par

Microsoft pour Windows, Linux et MacOs. Les fonctionnalités incluent la prise en
charge du débogage, la mise en évidence de la syntaxe, la complétion intelligente du
code, les snippets, la réfactorisation du code et Git intégrer
ü Postman version 8.12.2 : c’est un logiciel devenu très populaire pour tester les micros
services. Il nous a permis de tester notre API.
2. Politique de sécurité
La politique de sécurité désigne l’ensemble des moyens à mettre en place pour protéger le
logiciel. La sécurité de notre plateforme représente un aspect essentiel à prendre en compte.
Cette politique s’articule autour de la sensibilisation des utilisateurs, des mesures de sécurité
mises en œuvre dans le processus de développement de la plateforme et des mesures à
implémenter lors de sa mise en production.
v Sensibilisation des utilisateurs

Le facteur humain étant un élément important dans la démarche sécuritaire, il est nécessaire de
fournir à nos clients des conseils pratiques pour un meilleur rendement du service fourni par la
plateforme. Ainsi, le client peut se prémunir de plusieurs tords en adoptant les démarches
suivantes :
ü éviter de communiquer ses données d’authentification à un tiers ;
ü ne pas céder son ordinateur sans aucune surveillance de l’usage que l’on en fait ;
ü se procurer d’un anti-virus régulièrement mis à jour,
v Mesures de sécurité pour la phase le développement

L’accès à l’application a été protégé par un nom d’utilisateur et un mot de passe. En outre,
un utilisateur qui se connecte ne peut exécuter que les fonctionnalités du système que lui

RAPPORT DE STAGE
confère son profil. Ainsi un système d’authentification basé sur un token JWT (ANNEXE
1 : Token JWT) a été mis en place afin de protéger l’accès aux différentes ressources de la
plateforme. Les mots de passes ont été chiffrés avec la fonction de hachage bcrypt pour les
rendre illisibles à toute personne ayant accès à la base de données.
Au regard des erreurs que peuvent commettre les utilisateurs lors des saisies des données,
nous avons alors mis en place un système permettant de filtrer ces données. A la soumission
de données au système, ce système de filtrage détecte automatiquement les données invalides
et les signale à l’utilisateur pour qu’il puisse les corriger avant une nouvelle soumission.
v Mesures de sécurité à prendre pour l’exploitation

Ø La sécurité SSL
Pour notre système, nous préconisons d’ajouter un module supportant les protocoles
sécurisés comme SSL (Secure Sockets Layer) afin d’assurer des fonctions de sécurité très
élevées. En effet, la technologie SSL est une norme dans le domaine de la sécurisation
des transactions Internet. Le certificat SSL est donc une sorte de signature numérique
du site Internet. Le certificat va être utilisé pour crypter l’ensemble des transactions entre
un ordinateur et le site Internet.
En résumé, le certificat SSL assure la confidentialité et empêche l’espionnage ou
l’interception de données. Il rend impossible le piratage des informations échangées entre
le serveur et le navigateur. Il permet d’authentifier un site et assure au visiteur qu’il s’agit
bien du site officiel recherché.
Ø Politique de sauvegarde
La politique de sauvegarde consiste à prendre des mesures nécessaires pour préserver
l’intégrité des données en cas de disfonctionnement du système.
Alors nous préconisons :
ü des sauvegardes journalières qui ont une durée d’une semaine ;
ü des sauvegardes hebdomadaires qui ont une durée d’un mois ;
ü des sauvegardes mensuelles qui ont une durée de six (06) mois ;
ü des sauvegardes semestrielles qui ont une durée d’un an ;
ü des sauvegardes annuelles qui seront conservées définitivement.

RAPPORT DE STAGE
3. Estimation du coût de développement

La conception d’un logiciel inclut le plus souvent une phase très importante qui est
l’estimation du coût de réalisation. En effet, cette opération permet de connaître les
ressources humaines, financières et matérielles nécessaires pour mener à bien le projet. Il
existe plusieurs méthodes pour faire cette estimation. Nous utiliserons la méthode COCOMO
SIMPLIFIEE (Constructive Cost Model) pour la fiabilité de ces estimations. Les
informations concernant cette méthode sont détaillées en Annexe (ANNEXE 3 : La méthode
COCOMO).
De plus, nous estimons le nombre de lignes de code de notre application à neuf mille (9 000).
En supposant que le salaire d’un Ingénieur-informaticien est égal à 200 000 F CFA, on peut
alors estimer le coût de développement comme suit :
• Effort = 2,4*(9000/1000) 1,05 = 24.10Homme/Mois
• TDEV = 2,5*Effort 0,38 = 2,5*24.10 0,38 = 8.37 mois

• CDEV = 24.10 * X FCFA = 24.10 * 200 000 FCFA = 4 820 000 FCFA
En prenant en considération le coût du développement ainsi que celui du besoin en matériel

informatique et logiciels, on obtient le coût total du projet tel que présenté comme suit :
Coût unitaire Disponibilité ou coût total (en

Désignation Quantité
(en FCFA) FCFA)
Ordinateur portable 1 300 000 300 000
Serveur de test 1 - Disponible
GanttProject 1 - Licence gratuite
Sybase Power AMC 1 4 647 850 / an Version d’évaluation
PostgreSQL 1 - Licence gratuite
Visual Studio Code 1 - Licence gratuite
Développement - - 4 820 000
Coût Total 5120000
Tableau 19: Coût total du projet

RAPPORT DE STAGE
4. Présentation de quelques écrans de l’application
Figure 12: Ecran d’inscription
Figure 13 : Ecran de connexion

RAPPORT DE STAGE
Figure 14 : Ecran Ajout d’un contact
Figure 15: Ecran d’envoi de message

RAPPORT DE STAGE
CHAPITRE III : BILAN DU STAGE
A près avoir présenté les activités à mener dans le cadre de la mise en place d’un système
de communication basé sur des SMS, nous faisons dans ce dernier chapitre le bilan de
notre stage. Pour ce faire, nous allons d’abord, présenter le déroulement du stage ainsi que
les activités menées au cours de son déroulement. Ensuite, nous apporterons nos critiques et
nos suggestions.
I. DÉROULEMENT DU STAGE ET ACTIVITÉS MÉNÉES
1. Activités menées
Notre stage s’est déroulé sur la période allant du premier (1) juillet 2021 au trente (30)
Septembre 2021 au sein de l’entreprise OKABI Technology Services. Durant ces trois (3)
mois, notre activité était essentiellement basée sur l’étude du thème « Mise en place d’un
système de communication basé sur les SMS pour les professionnels et les particuliers
» suivant le planning de réalisation du projet présenté plus haut.
Nous avons effectué entre autres les activités suivantes :
v L’initiation aux outils de télétravail tels que Microsoft Teams

v L’initiation au design avec Adobe XD
v La sécurisation des données avec un token
v L’initiation à l’intégration continue avec l’outil Jenkins
2. Connaissances acquises
Ce stage effectué au sein de l’entreprise OKABI Technology Services nous a été bénéfique à
plusieurs niveaux. Il nous a permis de :
v Mettre en pratique les connaissances académiques engrangées durant les trois (03) ans
de formation à l’IBAM ;
v Renforcer nos compétences en développement d’application web ;
v Renforcer nos compétences en sécurisation de données des API
v Renforcer nos compétences en prototypage d’applications
v S’imprégner des réalités de la vie professionnelle

RAPPORT DE STAGE
II. OBSERVATIONS ET SUGGESTIONS
Nous adressons nos remerciements à OKABI Technology Services pour le stage qu’il nous a
accordé et qui a été vraiment bénéfique pour nous. Nous apprécions à sa juste valeur l’accueil
chaleureux dont nous avons bénéficié de la part du personnel qui par ailleurs, a mis à notre
disposition des locaux agréables et conviviaux pour le travail. De plus, avec OKABI
Technology Services, l’effort est toujours récompensé. Ainsi, nous avions bénéficié d’une
rémunération mensuelle.
Au regard des résultats palpables auxquels nous sommes parvenus, nous suggérons à OKABI
Technology Services l’organisation de sessions de formations ouvertes et de hackathons afin
de détecter des talents qu’elle pourra récupérer pour booster son équipe de développement.
Nous encourageons OKABI Technology Services à continuer dans son élan et à être encore
plus porteur de valeurs et de bienfaits.

RAPPORT DE STAGE
CONCLUSION GÉNÉRALE
D ans le cadre de ce projet de fin d’études, nous avons conçu et développé un système de
communication basé sur des SMS pour les professionnels et les particuliers.
Afin de traduire les attentes des différents acteurs du projet, nous avons opté pour la méthode
2TUP et le langage de modélisation UML à travers notamment les diagrammes de cas
d’utilisation, de séquence, d’activité, de déploiement et de classes avant d’implémenter les
différentes fonctionnalités identifiées.
Ce travail fut l’occasion pour nous d’approfondir nos connaissances en matière de

développement d’applications avec des technologies telles que Angular, Spring Boot et de
mettre en pratique nos connaissances théoriques et méthodologiques acquises au cours de notre
formation à l’IBAM.
Ce stage nous a permis non seulement de nous familiariser avec le monde professionnel,
mais aussi de renforcer notre capacité à travailler en équipe grâce au télétravail

RAPPORT DE STAGE
BIBLIOGRAPHIE ET WEBOGRAPHIE
1. Bibliographie
ü OUEDRAOGO Inoussa, 2018, « Réalisation d’un système informatisé de suivi des
investissements publics au Burkina Faso », Rapport de fin de cycle de Licence, option
MIAGE, Ouagadougou, Institut Burkinabè des Arts et Métiers (IBAM), 68 p.
ü ZORE Madi, 2018, « Mise en place d’un système informatique de gestion des
immobilisations du Trésor public », Rapport de fin de cycle de Licence, option MIAGE,
Ouagadougou, Institut Burkinabè des Arts et Métiers (IBAM), 71 p.
ü SOURGOU Franck, 2019, « Mise en place d’une plateforme web de gestion financière et
comptable pour les petites et moyennes entreprises au Burkina Faso », Rapport de fin de
cycle de Licence, option MIAGE, Ouagadougou, Institut Burkinabè des Arts et Métiers
(IBAM), 60 p.
ü SAWADOGO Raogo Romaric Sylvain, 2020, « Réalisation d’un système informatisé
d’aide à l’établissement du cadre des dépenses à moyen terme », Rapport de fin de cycle
de Licence, option MIAGE, Ouagadougou, Institut Burkinabè des Arts et Métiers (IBAM),
67 p.
2. Webographie
ü Angular. One framework Mobile & desktop [en ligne] (page consultée plusieurs fois
pendant le développement de la plateforme).
https://angular.io/
ü Spring. Spring makes Java simple, modern, productive, reactive, cloud-ready [en ligne]
(page consultée plusieurs fois pendant le développement de la plateforme).
https://spring.io/
ü Developpez. Le club des développeurs informatique [en ligne] (page consultée plusieurs
fois pendant le développement de la plateforme).
https://developpez.com/
ü Primeng. The Most Powerful Angular UI Component Library [en ligne] (page consultée
plusieurs fois pendant le développement de la plateforme).
https://primefaces.org/primeng/
OUEDRAOGO DAVID PASCAL PAWINDTAORE I

RAPPORT DE STAGE
ü Stackoverflow. Stack Overflow - Where Developers Learn, Share, and Build Careers [en
ligne] (page consultée plusieurs fois pendant le développement de la plateforme).
https://stackoverflow.com/
ü Wikipédia. L'encyclopédie libre [en ligne] (page consultée plusieurs fois pendant le
développement de la plateforme).
https://fr.wikipedia.org/
ü Google. Mémoire Online [en ligne] (page consultée plusieurs fois au besoin).
https://memoireonline.com/
ü Google. TicMagazine.bf [en ligne] : rapport sur l’utilisation d’Internet et des

médias sociaux au Burkina Faso en 2021
https://ticmagazine.bf/
ü Google. arcep.bf [en ligne] ; rapport du troisième trimestre de l’année 2020 sur
les données du marché national de la téléphonie mobile
https://arcep.bf/
OUEDRAOGO DAVID PASCAL PAWINDTAORE II

RAPPORT DE STAGE
TABLE DE MATIERES
SOMMAIRE .............................................................................................................................. i
DÉDICACE............................................................................................................................... ii
REMERCIEMENTS ............................................................................................................... iii
LISTE DES SIGLES ET ABREVIATIONS ......................................................................... iv
LISTE DES FIGURES GRAPHIQUES ................................................................................ vi
LISTE DES TABLEAUX ...................................................................................................... vii
INTRODUCTION GÉNÉRALE ............................................................................................ 1
CHAPITRE I : PRÉSENTATION DES STRUCTURES DE FORMATION ET
D’ACCUEIL ............................................................................................................................. 2
I. PRÉSENTATION DE LA STRUCTURE DE FORMATION (IBAM) .......................... 2
1. Historique .................................................................................................................... 2
2. Objectif ........................................................................................................................ 2
3. Organisation................................................................................................................. 3
4. Filières de formation .................................................................................................... 3
II. PRÉSENTATION DE LA STRUCTURE D’ACCUEIL(OKABI) ............................. 5
1. Histoire ........................................................................................................................ 5
2. Vision........................................................................................................................... 5
3. Services ........................................................................................................................ 5
CHAPITRE II : ANALYSE ET CONCEPTION .................................................................. 6
I. ÉTUDE PREALABLE .................................................................................................... 6
1. Présentation du Thème ................................................................................................ 6
a. Problématique .......................................................................................................... 6
b. Les attentes............................................................................................................... 7
2. Méthodologie ............................................................................................................... 7
a. Cycle de développement ........................................................................................... 7
b. Langage de modélisation ....................................................................................... 12
3. Groupe de travail ....................................................................................................... 12
a. Groupe de pilotage ................................................................................................ 13
b. Groupe de projet .................................................................................................... 13
c. Groupe des utilisateurs .......................................................................................... 13
d. Planning de réalisation............................................................................................... 13
II. EXPRESSIONS DES BESOINS ............................................................................... 14
1. Présentation du processus de fonctionnement de la plateforme web SMS4All. ....... 14
1. Spécification fonctionnelle ........................................................................................ 14
a. Identification des acteurs ....................................................................................... 14
b. Identifications des cas d’utilisations ...................................................................... 15
c. Diagramme de cas d’utilisation ............................................................................. 16
d. Description textuelle de certains cas d’utilisation................................................. 17
e. Diagramme de séquence ........................................................................................ 20
3. Spécification technique.............................................................................................. 23
OUEDRAOGO DAVID PASCAL PAWINDTAORE III

RAPPORT DE STAGE
a.
Mise à disposition des conditions de travail .......................................................... 23
b.
Architecture de développement .............................................................................. 24
III. CONCEPTION GLOBALE ...................................................................................... 26
1. Diagramme des classes .............................................................................................. 26
a. Dictionnaire de données ........................................................................................ 27
b. Diagramme de classes ........................................................................................... 30
2. Diagramme d’activité ................................................................................................ 32
3. Diagramme de déploiement ....................................................................................... 33
IV. RÉALISATION ......................................................................................................... 35
1. Présentation des outils de développement ................................................................. 35
a. Choix du Système de Gestion de Base de Données................................................ 35
b. Languages de programmation ............................................................................... 38
c. Serveur d’application ............................................................................................. 38
d. Plateforme de développement (Frameworks) ........................................................ 40
e. Outils de conception............................................................................................... 40
2. Politique de sécurité ................................................................................................... 41
3. Estimation du coût de développement ....................................................................... 43
4. Présentation de quelques écrans de l’application ...................................................... 44
CHAPITRE III : BILAN DU STAGE .................................................................................. 46
I. DÉROULEMENT DU STAGE ET ACTIVITÉS MÉNÉES ......................................... 46
1.
Activités menées ........................................................................................................ 46
2.
Connaissances acquises ............................................................................................. 46
II. OBSERVATIONS ET SUGGESTIONS ................................................................... 47
CONCLUSION GÉNÉRALE ............................................................................................... 48
BIBLIOGRAPHIE ET WEBOGRAPHIE..............................................................................I
1. Bibliographie ................................................................................................................ I
2. Webographie ................................................................................................................. I
TABLE DE MATIERES ...................................................................................................... III
ANNEXES ................................................................................................................................ V
ANNEXE 1 : TOKEN JWT ............................................................................................... V
ANNEXE 2 : Le langage UML......................................................................................... VI
ANNEXE 3 : La méthode COCOMO..............................................................................VII
OUEDRAOGO DAVID PASCAL PAWINDTAORE IV

RAPPORT DE STAGE
ANNEXES
ANNEXE 1 : TOKEN JWT

Les JSON Web Token sont particulièrement appréciés pour les opérations d’identification. Les
messages courts peuvent être chiffrés et fournissent alors des informations sûres sur l’identité
de l’expéditeur et si celui-ci dispose des droits d’accès requis. Les utilisateurs eux-mêmes ne
sont qu’indirectement en contact avec les token, par exemple lorsqu’ils entrent un nom
d’utilisateur et un mot de passe dans un masque. La véritable communication se fait entre les
différentes applications du côté serveur et client.
Structure d’un token JWT
Un JWT signé se compose de trois parties codées en base64 et séparées par un point:
HEADER.PAYLOAD.SIGNATURE
1) En-tête (header)
L’en-tête, ou header, est en général composé de deux parties et fournit des informations
essentielles sur le token. Il contient le type de token et l’algorithme de signature et/ou de
chiffrement utilisé. Un exemple de header de JWT :
{ "alg": "HS256", "typ": "JWT" }
2) Charge utile (Payload)
La charge utile du JSON Web Token est la partie qui contient les informations qui doivent
être transmises à l’application. C’est là que sont définis certains standards qui déterminent
quelles données doivent être transmises. Les informations sont fournies en paire clé/valeur,
les clés sont appelées « claims » dans les JWT.
3) Signature
La signature d’un JSON Web Token est créée grâce au codage base64 de l’en-tête et de la
charge utile et la méthode de signature/cryptage spécifiée.
Pour que la signature fonctionne, il est nécessaire d’utiliser une clé secrète connue
uniquement de l’application source. Cette signature vérifie d’une part que le message ne sera
pas modifié pendant le transfert. D’autre part, dans le cas d’un jeton signé avec une clé privée,
il authentifie également l’expéditeur du JWT.
Le cryptage crée une séquence de caractères apparemment aléatoire :

{ 7WK5T79u5mIzjIXXi2oI9Fglmgivv7RAJ7izyj9tUyQ }
OUEDRAOGO DAVID PASCAL PAWINDTAORE V

RAPPORT DE STAGE
Il est très aisé de comprendre le fonctionnement d’un JSON Web Token en utilisant
l’exemple d’une connexion utilisateur. Une clé secrète est déterminée avant l’utilisation
du JWT. Dès qu’un utilisateur a entré avec succès ses données de connexion, le JWT est
renvoyé avec la clé et stocké localement. Le transfert se fait par HTTPS afin de mieux
protéger les données.
Lorsque l’utilisateur veut accéder à des ressources protégées comme une API ou un chemin
d’accès protégé, le JWT sera envoyé par l’agent utilisateur comme paramètre (par exemple
« jwt » pour les GET-Requests) ou comme en-tête d’autorisation (pour POST, PUT,
OPTIONS, DELETE). L’interlocuteur peut déchiffrer le JSON Web Token et si le contrôle
est réussi, exécuter la demande.
Figure 16: Illustration du Token JWT
ANNEXE 2 : Le langage UML

UML est l’acronyme anglais pour « Unified Modeling Langage ». Il se traduit par « Langage
de modélisation unifié ». C’est un langage de modélisation graphique à base de pictogrammes
conçu pour fournir une méthode normalisée permettant de visualiser la conception d’un
système. Ce langage est utilisé pour la spécification, la visualisation, la modification et la
construction des documents nécessaires au bon développement d’un logiciel orienté objet. Il
offre un standard de modélisation, pour représenter l’architecture logiciel. Grâce à UML, il
est possible de générer tout ou une partie du code d’un logiciel à partir des divers documents
OUEDRAOGO DAVID PASCAL PAWINDTAORE VI

RAPPORT DE STAGE
réalisés.
Ce langage de modélisation nous offre principalement 13 diagrammes (depuis sa deuxième

version) pour modéliser un système. Ces diagrammes peuvent être utilisés selon la phase du
développement d’un logiciel.
En analyse, nous pouvons utiliser des :

ü Diagrammes de cas d’utilisation : modélisent les besoins des utilisateurs ;
ü Diagrammes de séquences vues de l’extérieur : présentent les scénarios entre les

utilisateurs ;
ü Diagrammes d’activités : c’est un enchaînement d’actions représentant
un comportement du logiciel.
ü En phase de conception, le développeur peut utiliser des :
ü Diagrammes de classes : pour représenter la structure interne du logiciel ;
ü Diagrammes d’objets : pour présenter l’état interne du logiciel à un instant donné ;
ü Diagrammes d’états-transitions : pour présenter l’évolution de l’état d’un objet ;
ü Diagrammes de séquence vue de l’intérieur : pour montrer les scénarios d’interactions

avec les utilisateurs au sein du logiciel ;
ü Diagrammes de composants : pour présenter les composants physiques du logiciel ;
ü Diagrammes de déploiement : pour l’organisation matérielle du logiciel.
Ces diagrammes sont rarement tous implémentés dans le cadre du même projet. Le choix des
diagrammes à mettre en œuvre dans la modélisation est généralement fonction de la nature
du projet et de sa taille.
ANNEXE 3 : La méthode COCOMO

Un grand nombre de méthodes est mis à la disposition des développeurs pour estimer le coût
de leurs plateformes. Notre choix se porte sur la méthode Constructive Cost Model
(COCOMO) pour l’estimation du coût total du développement (CTDEV) de notre
application, du fait de sa fiabilité. De plus, cette méthode permet également d’estimer le
temps de développement (TDEV) du système correspondant au temps requis pour terminer
le projet avec toutes les ressources disponibles. La méthode COCOMO se base
principalement sur la complexité de l’application à développer qui correspond à l’un des trois
OUEDRAOGO DAVID PASCAL PAWINDTAORE VII

RAPPORT DE STAGE
(03) types suivants :
Ø S : Ce sont des applications simples, n’ayant que peu de cas particuliers et de

contraintes. Elles sont parfaitement déterministes.
Ø P : Ce sont des applications intermédiaires, plus complexes que les applications de

type S. Elles restent tout de même déterministes bien que le nombre de leurs cas
particuliers et de tests soit plus important que pour les applications de type S.
Ø E : Ce sont des applications très complexes, que ce soit au niveau de leurs contraintes,
comme un système temps réel, où au niveau des données saisies, comme certaines
interfaces graphiques ou l’on ne peut envisager toutes les possibilités utilisateur
pourrait effectuer. Elles ne sont pas déterministes.
Effort(en Temps de développement(TDEV en

Complexité
Homme mois) mois)
Effort = 2,4 *
S TDev = 2,5 * Effort0,38
KLS1,05
Effort = 3 *
P TDev = 2,5 * Effort0,35
KLS1,12
Effort = 3,6 *
E TDev = 2,5 * Effort0,32
KLS1,2
Tableau 20: Formule de calcul COCOMO
NB : HM est le nombre d’« homme mois » nécessaire à la réalisation du projet, et KLS est le
nombre de Kilo Lignes Sources. Un homme mois correspond à 152 heures de travail effectif.
Le nombre de personnes requis pour réaliser le projet dans cet intervalle de temps est donc :
N = HM/TDEV. Étant donné que le salaire moyen d’un informaticien est de X FCFA, le
coût total de développement pour ce projet est : CTDEV = HM*X.
OUEDRAOGO DAVID PASCAL PAWINDTAORE VIII

Langue

Rapport Final Ouedraogo David PP

Transféré par

Informations du document

Titre original

Copyright

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Rapport Final Ouedraogo David PP

Transféré par

Droits d'auteur :

UNIVERSITÉ JOSEPH KI-ZERBO

RAPPORT DE STAGE POUR L’OBTENTION DE LA LICENCE

MISE EN PLACE D’UN SYSTÈME DE

Présenté par OUEDRAOGO David Pascal Pawindtaoré

Maitre de stage : Directeur de rapport :

Année Académique 2020-2021

OUEDRAOGO DAVID PASCAL PAWINDTAORE i

OUEDRAOGO DAVID PASCAL PAWINDTAORE ii

OUEDRAOGO DAVID PASCAL PAWINDTAORE iii

LISTE DES SIGLES ET ABREVIATIONS

Ingénierie Informatique et Organisation et Protection

Ingénierie Informatique et Technologies de

2TUP 2 Tracks Unified Process

ABF Assurance Banque Finance

ADB Assistance de Direction Bilingue

AIB Antenne informatique de Bobo Dioulasso

API Application Programming Interface

COCOMO Constructive Cost Model

Chef des Services Administratif, Financier et

CSS Cascading Style Sheet

HTML HyperText Markup Language

HTTP HyperText Transfer Protocol

OUEDRAOGO DAVID PASCAL PAWINDTAORE iv

IBAM Institut Burkinabè des Arts et Métiers

IUFIC Institut Universitaire de Formation Initiale et Continue

Java EE Java Entreprise Environnement

JPA Java Persistence API

JSON JavaScript Object Notation

JWT Json Web Token

LMD Licence Master Doctorat

LPSAA Licence Professionnelle en Assistance Administrative

MAGE Master en Administration de Gestion des Entreprises

MBF Master en Banque Finance

MCCA Master en Comptabilité-Contrôle-Audit

MIAGE Méthodes Informatiques Appliquées à la Gestion

SIM Subscriber Identity/Identification Module

SGBD Système de Gestion de Base de Données

SMS Short Message Service

SQL Structured Query Language

UML Unified Modeling Language

WWW World Wide Web

OUEDRAOGO DAVID PASCAL PAWINDTAORE v

LISTE DES FIGURES GRAPHIQUES

Figure 1: Schéma présentant le processus 2TUP ..................................................................... 11

OUEDRAOGO DAVID PASCAL PAWINDTAORE vi

LISTE DES TABLEAUX

Tableau 1 :Comparaison des méthodologies de développement ............................................... 9

OUEDRAOGO DAVID PASCAL PAWINDTAORE vii

OUEDRAOGO DAVID PASCAL PAWINDTAORE 1

CHAPITRE I : PRÉSENTATION DES STRUCTURES DE

D ans ce chapitre, nous présenterons successivement notre structure de formation qu’est

I. PRÉSENTATION DE LA STRUCTURE DE FORMATION (IBAM)

L’Institut Burkinabè̀ des Arts et Métiers (IBAM) est un établissement d’enseignement

OUEDRAOGO DAVID PASCAL PAWINDTAORE 2

• Le conseil de gestion qui est l’organe suprême regroupant le directeur, le directeur

v Licences professionnelles (Formation initiale)

Les filières de formations initiales en licences professionnelles sont :

- Assistant de Direction/Bilingue (ADB) ;

v Licences professionnelles (Formation continue ou en soir)

- Licence Professionnelle en Assistance Administrative (LPAA) ;

En master, l’IBAM offre cinq (05) filières de formation qui sont :

OUEDRAOGO DAVID PASCAL PAWINDTAORE 3

- Master en Administration et Gestion des Entreprises (MAGE) ;

OUEDRAOGO DAVID PASCAL PAWINDTAORE 4

II. PRÉSENTATION DE LA STRUCTURE D’ACCUEIL(OKABI)