Rapport Final Ouedraogo David PP [PDF]

Zitiervorschau

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

2ITIC

Informatique

et

Technologies

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

ARCEP

Autorité de Régulation des Communications Électroniques et des Postes

ATOS

Administratifs, Techniques, Ouvriers, de Service

COCOMO

Constructive Cost Model Chef des Services Administratif,

CSAFC

Financier et

Comptable

CSS

Cascading Style Sheet

CU

Cas d’utilisation

DA

Directeur Adjoint

DESCOGEF

Diplôme d’Études de Comptabilité et Gestion 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

de

iv

RAPPORT DE STAGE IBAM IUFIC

Institut Burkinabè des Arts et Métiers 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

TIC NTIC

Technologies de l’Information et de la Communication Nouvelles Technologies de l’Information et de la 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 KIZERBO. 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é.

OUEDRAOGO DAVID PASCAL PAWINDTAORE

2

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 : OUEDRAOGO DAVID PASCAL PAWINDTAORE

3

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.

OUEDRAOGO DAVID PASCAL PAWINDTAORE

4

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 OUEDRAOGO DAVID PASCAL PAWINDTAORE

5

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

OUEDRAOGO DAVID PASCAL PAWINDTAORE

6

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.

OUEDRAOGO DAVID PASCAL PAWINDTAORE

7

RAPPORT DE STAGE Méthodologies Description Ø

Cascade

RUP (Rational Ø

Process)

Distingue clairement les Ø

déroulées d’une

phases du projet.

Ø

Non itératif. Pas de modèles

manière

pour

séquentielle.

documents.

Le RUP est à la Ø une Ø

Ø

Itératif. Spécifie

le

Assez flou dans sa mise en œuvre.

différents Ø

entre

un outil prêt à

intervenants du projet.

phases en amont

Propose des modèles de

et en aval au

documents

développement.

Ø

Cible

des

projets de plus de

les

dialogue

les

méthodologie et l’emploi. Ø

Points faibles

Les phases sont Ø

fois

Unified

Points forts

pour

des

Ne couvre pas les

projets types.

10

personnes. 2TUP

(Two Ø

Truck Unified

autour

Process) Ø

Ø

Ø

S’articule

de Ø

Ø

Itératif.

Plutôt superficiel

Laisse une large place à

sur

les

phases

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

Cible

des

prototypes.

documents

types.

projets de toutes tailles. XP (eXtreme

Ø

Ensemble

des Ø Ø

bonnes

Programming)

pratiques Ø

de

sa

aux aspects techniques.

œuvre.

Innovant

Cible : Moins

programmation en duo.

10

personnes.

Assez flou dans

Donne une importance

développement. Ø de

Ø

Itératif.

: Ø

mise

en

Ne couvre pas les

phases

en

amont et en aval au développement.

OUEDRAOGO DAVID PASCAL PAWINDTAORE

8

RAPPORT DE STAGE Scrum

Ø

Se base sur des Ø

Donne toute confiance Ø

La

itérations dites

aux développeurs et les

œuvre

sprints

laisser faire leur travail.

développement

Chaque itération a un

n’est

objectif bien précis et

précisée.

de

développement Ø

fournit

une Ø

fonctionnalité testée.

mise

en du pas

Développement 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 ;

OUEDRAOGO DAVID PASCAL PAWINDTAORE

9

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

OUEDRAOGO DAVID PASCAL PAWINDTAORE

10

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

OUEDRAOGO DAVID PASCAL PAWINDTAORE

11

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.

OUEDRAOGO DAVID PASCAL PAWINDTAORE

12

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 :

OUEDRAOGO DAVID PASCAL PAWINDTAORE

13

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

OUEDRAOGO DAVID PASCAL PAWINDTAORE

14

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 CU01

S’authentifier

CU02

Gérer forfaits

CU03

Gérer les promotions

CU04

Choisir un forfait

CU05

Gérer les contacts

CU06

Gérer liste de diffusion

CU07

Envoyer un message non programmé

Description Permet aux utilisateurs de se connecter à l’application Permet d’enregistrer, modifier et supprimer les forfaits Permet d’enregistrer, modifier et supprimer les promotions Permet de choisir un forfait afin de pouvoir envoyer des sms Permet d’enregistrer, modifier et supprimer les contacts Permet d’enregistrer, modifier et supprimer les listes de diffusions

Acteurs Gestionnaire, Client Gestionnaire Gestionnaire Client Client Client

Permet d’envoyer un message instantané à une ou plusieurs

Client

listes de diffusions Permet de prévoir l’envoi d’un

CU08

Envoyer un message programmé

message à une ou plusieurs listes

Client

de diffusions CU09

Consulter historique

CU10

Réponse

OUEDRAOGO DAVID PASCAL PAWINDTAORE

Permet d’afficher la liste des messages envoyés Permet de répondre à un message reçu

Client Destinataire

15

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

OUEDRAOGO DAVID PASCAL PAWINDTAORE

16

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 »

OUEDRAOGO DAVID PASCAL PAWINDTAORE

17

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 »

OUEDRAOGO DAVID PASCAL PAWINDTAORE

18

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é »

OUEDRAOGO DAVID PASCAL PAWINDTAORE

19

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).

OUEDRAOGO DAVID PASCAL PAWINDTAORE

20

RAPPORT DE STAGE

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

OUEDRAOGO DAVID PASCAL PAWINDTAORE

21

RAPPORT DE STAGE

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

OUEDRAOGO DAVID PASCAL PAWINDTAORE

22

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.

OUEDRAOGO DAVID PASCAL PAWINDTAORE

23

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;

OUEDRAOGO DAVID PASCAL PAWINDTAORE

24

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

OUEDRAOGO DAVID PASCAL PAWINDTAORE

25

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.

OUEDRAOGO DAVID PASCAL PAWINDTAORE

26

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 Attribut

Description

Type de donnée

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

DateModif

Date de la dernière modification

Date

Tableau 8: Description de la classe « Utilisateur »

OUEDRAOGO DAVID PASCAL PAWINDTAORE

27

RAPPORT DE STAGE v Classe : Destinataire Attribut

Description

Type de donnée

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

DateModif

Date de la dernière modification

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 Attribut

Description

Type de donnée

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

DateModif

Date de la dernière modification

Date

DateSuppr

Date de suppression

Date

FlagSuppr

Champ qui vérifie si la liste est supprimé Booléen ou pas Tableau 10: Description de la classe « ListeDiffusion »

OUEDRAOGO DAVID PASCAL PAWINDTAORE

28

RAPPORT DE STAGE v Classe : ListeDiffusion_Destinataire Attribut

Description

Type de donnée

DateAffectation

Date d’affectation du destinataire à la Date liste de diffusion

Tableau 11: Description de la classe « ListeDiffusion_Destinataire» v Classe : Message Attribut

Description

Type de donnée

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

DateModif

Date de la dernière modification

Date

DateSuppr

Date de suppression

Date

FlagSuppr

Champ qui vérifie si le message est Booléen supprimé ou pas Tableau 12: Description de la classe « Message »

OUEDRAOGO DAVID PASCAL PAWINDTAORE

29

RAPPORT DE STAGE v Classe : Forfait Attribut

Description

Type de donnée

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

DateModif

Date de la dernière modification

Date

Statut

État du forfait (Actif ou Inactif)

Chaine de caractère

Tableau 13: Description de la classe « Forfait » v Classe : Promotion Attribut

Description

Type de donnée

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 Attribut

Description

Type de donnée

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. OUEDRAOGO DAVID PASCAL PAWINDTAORE

30

RAPPORT DE STAGE

Figure 9: Diagramme de classes

OUEDRAOGO DAVID PASCAL PAWINDTAORE

31

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 »

OUEDRAOGO DAVID PASCAL PAWINDTAORE

32

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 : Attribut

Description

Type de donnée

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

Content

de

chaines

téléphones des destinataires du message

caractères

Le contenu du message

Chaine de caractères

de

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. OUEDRAOGO DAVID PASCAL PAWINDTAORE

33

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.

OUEDRAOGO DAVID PASCAL PAWINDTAORE

34

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 :

OUEDRAOGO DAVID PASCAL PAWINDTAORE

35

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

Access

conversion de données ü Une

forte

intégration

convenable

aux

applications

distantes. de

Microsoft Office/VBA,

ü Mono-plateforme (MS Windows) ü Non implémentation complète de la norme SQL.

ü Une possibilité de développer 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 actifpassif, en se basant sur le cluster OS)

ü Langage T-SQL très convivial, intégration de CLR

ü Pas certifié SQLJ, pas d'intégration

ü Services Web ü Support XML

Java, orientation C# ü Pas de contraintes d'unicité multi null

ü Ordonnanceur intégré MYSQL

✓ Rapide

ü

données

✓ Plus simple à utiliser ✓ Multiplateforme (Windows,

Non convenable aux grosses bases de

ü

Les fonctionnalités limitées

Unix, Linux, etc.)

ü

Présente

✓ gratuit

ü

Ne permet pas la reprise à chaud

une

sécurité moyenne

✓ Facile à installer ✓ S’intègre facilement dans l’environnement Apache

OUEDRAOGO DAVID PASCAL PAWINDTAORE

36

RAPPORT DE STAGE Oracle

ü Fourniture de technologies de haut niveau et des solutions d’affaires intégrées

ü Prix élevé ü Une administration complexe ✓ Porosité entre les schémas

ü Fiabilité

✓ Une gestion des verrous mortels mal

✓ Intègre la technologie flashback

conçue

ü Récupération

✓ Nombreuses failles de sécurités liées à

efficace

données

des

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 ü Fiable

et

ü Pas possible de requêter sur plusieurs

relativement

performant,

connexion

ü Supporte la majorité du standard SQL-92 ü Possède

bases à la fois : chaque base nécessite sa ü Sauvegardes peu évoluées ü Supporte

de

nombreuses

les

bases

de

importance

extensions (Java, Ruby, PL-

ü Pas de services Web

SQL)

ü Pas d'ordonnanceur intégré

ü Très riche fonctionnellement, ü Simple

d'utilisation

moyenne

ü Pas de fonctions d'agrégat OLAP et

ü Pas de requêtes récursives

d'administration

OUEDRAOGO DAVID PASCAL PAWINDTAORE

37

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 :

OUEDRAOGO DAVID PASCAL PAWINDTAORE

38

RAPPORT DE STAGE

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

Serveur

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 WebLogic

Légère

Rapide

Très

Très

légère

rapide

Facile

Très forte

Payant

Server

Tomcat

Serveur complet avec tous les composants. Serveur léger. Tomcat est

Très facile

Forte

gratuit

un conteneur de servlet. Composants limités Serveur

Wildfly

Très

Très

légère

rapide

Très facile

Très forte

gratuit

complet,

implémente entièrement 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 OUEDRAOGO DAVID PASCAL PAWINDTAORE

39

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 OUEDRAOGO DAVID PASCAL PAWINDTAORE

40

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 OUEDRAOGO DAVID PASCAL PAWINDTAORE

41

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.

OUEDRAOGO DAVID PASCAL PAWINDTAORE

42

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

(en FCFA)

FCFA)

Désignation

Quantité

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

OUEDRAOGO DAVID PASCAL PAWINDTAORE

43

RAPPORT DE STAGE

4. Présentation de quelques écrans de l’application

Figure 12: Ecran d’inscription

Figure 13 : Ecran de connexion

OUEDRAOGO DAVID PASCAL PAWINDTAORE

44

RAPPORT DE STAGE

Figure 14 : Ecran Ajout d’un contact

Figure 15: Ecran d’envoi de message

OUEDRAOGO DAVID PASCAL PAWINDTAORE

45

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

OUEDRAOGO DAVID PASCAL PAWINDTAORE

46

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.

OUEDRAOGO DAVID PASCAL PAWINDTAORE

47

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

OUEDRAOGO DAVID PASCAL PAWINDTAORE

48

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. b.

Mise à disposition des conditions de travail .......................................................... 23 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 Activités menées ........................................................................................................ 46 Connaissances acquises ............................................................................................. 46 II. OBSERVATIONS ET SUGGESTIONS ................................................................... 47 1. 2.

CONCLUSION GÉNÉRALE ............................................................................................... 48 BIBLIOGRAPHIE ET WEBOGRAPHIE..............................................................................I 1. 2.

Bibliographie ................................................................................................................ I 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.

Complexité

S

P

E

Effort(en

Temps de développement(TDEV en

Homme mois)

mois)

Effort = 2,4 * KLS1,05 Effort = 3 * KLS1,12 Effort = 3,6 * KLS1,2

TDev = 2,5 * Effort0,38

TDev = 2,5 * Effort0,35

TDev = 2,5 * Effort0,32

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