Mini Projet 4 1

M
Département : GTIC
Référence :
Licence Appliquée en Gestion des technologies de l’Information et

de la Communication
Projet Tutoré
Titre : Analyse et conception d’une

application de Journalisme économique
Réalisé par : Ahmed Kamoun

Insaf Tabelsi
Classe : GTIC L3 A / B
Encadré par : Mme. Ines Mezghani

M. Yemen Saibi
Entreprise d’Accueil : Saibi Intermediation
Année Universitaire : 2021-2022

Résumé
Le présent rapport expose le travail que nous avons effectué dans le cadre de notre
projet-tutoré.
L’objectif de ce travail est l’analyse et la conception d’une application mobile digitale

sous forme de mini-journal économique.
Cette application mobile propose un brief, qui analyse ce qui est long et résume ce
qui est important, sous forme de texte ou un service de podcast.
Mots clés : Application mobile, analyse, conception, journal économique, brief, podcast.
Abstract
This report presents the work we have done as part of our tutored project.
The objective of this work is the analysis and design of a digital mobile application
in the form of an economic mini-newspaper.
This mobile application offers a brief, which analyzes what is long and summarizes
what is important, in the form of text or a podcast service.
Keywords: Mobile application, analysis, design, economic newspaper, brief, podcast.

Remerciements
Tout d’abord, nous remercions Allah le tout puissant de nous avoir donné le
courage et la patience nécessaires à mener ce travail à son terme.
Je tiens à remercier tout particulièrement mon encadrante Mme. MEZGHANI

Ines, pour l’aide compétente qu’elle nous a apportée, pour sa patience et son en-
couragement. Son œil critique nous a été très précieux pour structurer le travail et
pour améliorer la qualité des différentes sections.
Nous tenons à remercier également notre encadrant de l’entreprise M. SAIBI

Yamen pour son aide immense, la qualité de son suivie ainsi que pour tous les
conseils et les informations qu’il nous a prodigués avec un degré de patience et de
professionnalisme sans égal.
Que les membres de jury trouvent, ici, l’expression de nos sincères remerciements
pour l’honneur qu’ils me font en prenant le temps de lire et d’évaluer ce travail.
Nous souhaitons aussi remercier l’équipe pédagogique et administrative de l’ISET’COM

pour leurs efforts dans le but de nos offrir une excellente formation.
Nous tenons à remercier Mme. BEN SALEM Yosra pour sa disponibilité et

ses orientations.
Pour finir, nous souhaitons remercier toute personne ayant contribué de près ou
de loin à la réalisation de ce travail.
Table des matières
Liste des figures viii
Liste des tableaux x
Introduction générale 1
1 Contexte général du projet 3
1.1 Présentation de l’organisme d’accueil . . . . . . . . . . . . . . . . . . 3
1.2 Présentation de l’incubateur du projet . . . . . . . . . . . . . . . . . 4
1.3 Présentation du projet à réaliser . . . . . . . . . . . . . . . . . . . . . 4
1.3.1 Problématique du projet . . . . . . . . . . . . . . . . . . . . . 4
1.3.2 Etude de l’existant . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3.3 Critique de l’existant . . . . . . . . . . . . . . . . . . . . . . . 7
1.3.4 Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.3.5 Chronogramme du projet . . . . . . . . . . . . . . . . . . . . . 9
1.3.6 Objectifs du projet . . . . . . . . . . . . . . . . . . . . . . . . 10
1.4 Choix de la méthode de travail . . . . . . . . . . . . . . . . . . . . . 11
1.4.1 Méthodologie agile . . . . . . . . . . . . . . . . . . . . . . . . 12
iv
TABLE DES MATIÈRES
1.4.2 Étude comparative de méthodes SCRUM et de méthodologie

XP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.4.3 Méthode de travail adoptée : SCRUM . . . . . . . . . . . . . 14
1.4.4 Principe de Scrum . . . . . . . . . . . . . . . . . . . . . . . . 14
1.4.5 Rôles de la méthode Scrum . . . . . . . . . . . . . . . . . . . 15
2 Etude de marché 16
2.1 Analyse de l’environnement interne et externe . . . . . . . . . . . . . 16
2.1.1 Benchmark . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.1.2 Les environnements adjacents (PESTEL) . . . . . . . . . . . . 17
2.1.3 Analyse swot . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.2 Élaboration de la stratégie marketing . . . . . . . . . . . . . . . . . . 20
2.2.1 Choix des critères de segmentation . . . . . . . . . . . . . . . 20
2.2.2 Ciblage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.2.3 Positionnement . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.2.4 Business Model Canvas . . . . . . . . . . . . . . . . . . . . . . 23
3 Backlog du produit 26
3.1 Étude préliminaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.1.1 Identification des exigences fonctionnelles . . . . . . . . . . . . 26
3.1.2 Identification des exigences non fonctionnelles . . . . . . . . . 27
3.2 Spécifications techniques . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.2.1 L’architecture logicielle . . . . . . . . . . . . . . . . . . . . . . 28
3.2.2 Outils de design . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.2.3 Outil de maquettege . . . . . . . . . . . . . . . . . . . . . . . 29
3.2.4 Environnement de conception . . . . . . . . . . . . . . . . . . 29
v
TABLE DES MATIÈRES
3.2.5 Outil de plannification . . . . . . . . . . . . . . . . . . . . . . 29
3.3 Spécifications générales des exigences . . . . . . . . . . . . . . . . . . 30
3.3.1 Détermination du cas d’utilisation global . . . . . . . . . . . . 30
3.3.2 Détermination du diagramme de classes de conception global

du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.4 Backlog du produit . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.4.1 Définition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.4.2 Tableau de backlog du produit . . . . . . . . . . . . . . . . . . 32
3.4.3 Définition des rôles dans SCRUM . . . . . . . . . . . . . . . . 34
3.4.4 Planification des sprints . . . . . . . . . . . . . . . . . . . . . 35
4 Sprint (1) 37
4.1 S’inscrire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.1.1 Diagramme de cas d’utilisation "s’inscrire" . . . . . . . . . . . 38
4.1.2 Tableau descriptif des scénarios du cas d’utilisation "s’inscrire" 38
4.1.3 Diagramme de séquence de cas d’utilisation "s’inscrire" . . . . 40
4.2 S’authentifier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.2.1 Diagramme de cas d’utilisation "s’authentifier" . . . . . . . . 41
4.2.2 Tableau descriptif des scénarios du cas d’utilisation ”s’authen-

tifier” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.2.3 Diagramme de séquence "S’authentifier" . . . . . . . . . . . . 43
4.3 Gérer son profil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.3.1 Diagramme de cas d’utilisation "Gérer son profil" . . . . . . . 44
4.3.2 Tableau descriptif des scénarios du cas d’utilisation"Gérer son

profil" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.3.3 Diagramme de séquence de "Gérer son profil" . . . . . . . . . . 45
4.4 Réalisation du sprint (1) . . . . . . . . . . . . . . . . . . . . . . . . . 45
vi
TABLE DES MATIÈRES
5 Sprint (2) 48
5.1 Payer un abonnement . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
5.1.1 Diagramme de cas d’utilisation "Payer un abonnement" . . . . 49
5.1.2 Description textuelle des scénarios du cas d’utilisation "Payer

un abonnement" . . . . . . . . . . . . . . . . . . . . . . . . . . 49
5.1.3 Diagramme de séquence de cas d’utilisation "Payer un abon-

nement" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
5.2 Consulter les news : . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
5.2.1 Diagramme de cas d’utilisation "Consulter les news " . . . . . 51
5.2.2 Tableau descriptif des scénarios du cas d’utilisation "Consulter

les News" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
5.2.3 Diagramme de séquence de cas d’utilisation "Consulter les news" 52
5.3 Ecouter les podcasts : . . . . . . . . . . . . . . . . . . . . . . . . . . 53
5.3.1 Diagramme de cas d’utilisation "Ecouter les podcasts" . . . . . 53
5.3.2 Tableau descriptif des scénarios du cas d’utilisation "Mettre à

jour l’application" . . . . . . . . . . . . . . . . . . . . . . . . . 54
5.3.3 Diagramme de séquence de cas d’utilisation "Ecouter les pod-

casts" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
5.4 La réalisation du sprint (2) . . . . . . . . . . . . . . . . . . . . . . . . 55
6 Sprint (3) 59
6.1 Mettre à jour l’application . . . . . . . . . . . . . . . . . . . . . . . . 60
6.1.1 Diagramme de cas d’utilisation "Mettre à jour l’application" . 60
6.1.2 Tableau descriptif des scénarios du cas d’utilisation "Mettre à

jour l’application" . . . . . . . . . . . . . . . . . . . . . . . . . 61
6.1.3 Diagramme de séquence de cas d’utilisation "Mettre à jour

l’application" . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
vii
TABLE DES MATIÈRES
6.2 Gérer les comptes utilisateurs . . . . . . . . . . . . . . . . . . . . . . 62
6.2.1 Diagramme de cas d’utilisation "Gérer les comptes utilisateurs" 62
6.2.2 Tableau descriptif des scénarios de cas d’utilisation "Gérer les

comptes utilisateurs" . . . . . . . . . . . . . . . . . . . . . . . 63
6.2.3 Diagramme de séquence de cas d’utilisation "Gérer les comptes

utilisateurs" . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
6.3 Publier les news et les podcasts . . . . . . . . . . . . . . . . . . . . . 64
6.3.1 Diagramme de cas d’utilisation "Publier les News et les pod-

casts" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
6.3.2 Tableau descriptif des scénarios de cas d’utilisation "Publier

les News et les podcasts" . . . . . . . . . . . . . . . . . . . . . 65
6.3.3 Diagrmme de séquence de cas d’utilisation "Publier les News

et les podcasts" . . . . . . . . . . . . . . . . . . . . . . . . . . 66
6.4 Réalisation du Sprint(3) . . . . . . . . . . . . . . . . . . . . . . . . . 66
Bibliographie 70
A Annexe 71
viii
Liste des figures
1.1 Application mobile "LesEchos" . . . . . . . . . . . . . . . . . . . . . . 6
1.2 Application mobile "Brief.me" . . . . . . . . . . . . . . . . . . . . . . 6
1.3 site web "ilboursa.com" . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.4 Chronogramme du projet . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.5 Processus Agile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.6 processus scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.1 Analyse SWOT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.2 Utilisation des smatphones en Tunisie en 2020 . . . . . . . . . . . . . 22
2.3 Business Model Canvas de Econo.Brief . . . . . . . . . . . . . . . . . 24
3.1 Diagramme des cas d’utilisation global . . . . . . . . . . . . . . . . . 30
3.2 Diagramme de classe . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.3 Planing des sprints . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.1 Diagramme de cas d’utilisation "s’inscrire" . . . . . . . . . . . . . . . 38
4.2 Diagramme de séquence "s’inscrire" . . . . . . . . . . . . . . . . . . . 40
4.3 Diagramme de cas d’utilisation "s’authentifier" . . . . . . . . . . . . . 41
4.4 Diagramme de séquence de "s’authentifier" . . . . . . . . . . . . . . . 43
ix
LISTE DES FIGURES
4.5 Diagramme de cas d’utilisation de "Gérer son profil" . . . . . . . . . . 44
4.6 Diagramme de séquence de "gérer son profil" . . . . . . . . . . . . . . 45
4.7 Interface de "Acceuil" . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.8 Interface de "Connexion" . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.9 Interface "Inscription" . . . . . . . . . . . . . . . . . . . . . . . . . . 47
5.1 Diagramme de cas d’utilisation "Payer un abonnement" . . . . . . . . 49
5.2 Diagramme de séquence "Payer un abonnement" . . . . . . . . . . . . 51
5.3 Diagramme de cas d’utilisation "Consulter les news" . . . . . . . . . . 51
5.4 Diagramme de séquence "Consulter les news" . . . . . . . . . . . . . . 53
5.5 Diagramme de cas d’utilisation "Ecouter les podcasts" . . . . . . . . . 53
5.6 Diagramme de séquence "Ecouter les podcasts" . . . . . . . . . . . . . 55
5.7 Interface de "Payement" par "e-dinar" . . . . . . . . . . . . . . . . . . 56
5.8 Interface de "Payement" par carte bancaire . . . . . . . . . . . . . . . 56
5.9 Interface d’ "Affichage des articles" . . . . . . . . . . . . . . . . . . . 57
5.10 Interface de "l’affichage de l’article choisi" . . . . . . . . . . . . . . . . 57
5.11 Interface "Ecouter les podcasts" . . . . . . . . . . . . . . . . . . . . . 58
6.1 Diagramme de cas d’utilisation "Mettre à jour l’application " . . . . . 60
6.2 Diagramme de séquence "Mettre à jour l’application" . . . . . . . . . 62
6.3 Diagramme de cas d’utilisation "Gérer les comptes utilisateurs " . . . 63
6.4 Diagramme de séquence "Gérer les comptes utilisateurs" . . . . . . . . 64
6.5 Diagramme de cas d’utilisation "Publier les News et les podcasts " . . 65
6.6 Diagramme de séquence "Publier les News et podcasts" . . . . . . . . 66
6.7 Interface d’un exemple d’un article à publier . . . . . . . . . . . . . . 67
6.8 Interface de l’accès administrateur . . . . . . . . . . . . . . . . . . . . 67
x
Liste des tableaux
1.1 Tableau comparatif entre les solutions existantes sur le marché . . . . 8
1.2 Les objectifs du projet . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.3 Analyse de méthodes et de méthodologie de travail . . . . . . . . . . 13
2.1 Benchmark concurrentiel . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.2 Origine de l’information . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.3 Pourcentage des articles classés dans les 12 thèmes définis . . . . . . . 21
2.4 Utilisation d’Internet en Tunisie . . . . . . . . . . . . . . . . . . . . . 21
3.2 Rôles des membres du SCRUM . . . . . . . . . . . . . . . . . . . . . 35
4.1 Backlog du sprint (1) . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.2 Description des scénarios du cas d’utilisation " s’inscrire " . . . . . . . 39
4.3 Description des scénarios du cas d’utilisation " s’authentifier " . . . . 42
4.4 Description des scénarios du cas d’utilisation" Gérer son profil " . . . 44
5.2 Tableau descriptif du cas d’utilisation "Payer un abonnement " . . . . 50
5.3 Description textuelle du cas d’utilisation "Consulter les news" . . . . . 52
xi
LISTE DES TABLEAUX
5.4 Description textuelle du cas d’utilisation "Ecouter les podcasts" . . . 54
6.2 Description textuelle du cas d’utilisation "Mettre à jour l’application" 61
6.3 Description textuelle du cas d’utilisation "Gérer les comptes utilisateurs" 63
6.4 Description textuelle de cas d’utilisation "Publier les News et les pod-
casts" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
xii
Introduction Générale
a révolution numérique est aujourd’hui une réalité dans tous les secteurs de
L l’économie.
En effet, le numérique modifie en profondeur les manières de produire, d’échan-

ger et de consommer.
Pour la plupart des entreprises, Internet est devenu un canal de communication

et de vente incontournable, et l’ensemble de l’économie est désormais converti au
"numérique".
La question est de comprendre comment le numérique, va à court et moyen

terme, transformer les marchés et les organisations, mais aussi l’espace et la société.
Avec l’avènement du digital, les canaux d’information se transforment afin de

s’adapter aux nouveaux fonctionnements du public : la presse écrite en proposant une
version digitale, la télévision en proposant des replays sur leur site web et même la
radio en proposant des podcasts. Un des nombreux avantages du web et notamment
des réseaux sociaux pour les professionnels, c’est d’avoir à disposition divers formats,
permettant d’adapter les contenus selon la cible.
La diffusion de l’information, par internet, constitue un modèle économique in-

téressant : entre bannières publicitaires web et accès à une sélection d’articles par
l’abonnement, un média y gagne non seulement en visibilité, mais aussi financière-
ment. De même qu’il y a une certaine rentabilité grâce à la refonte des process de
production de l’information.
INTRODUCTION GENERALE
La circulation de l’information, sur le web attribue, une meilleure réactivité à

l’actualité et surtout par rapport aux attentes des lecteurs. Un format print demande
forcément plus de temps pour l’impression et la distribution. La notion d’instanta-
néité de l’information sur le net se répercute également sur les relations presse : les
attachés de presse ont à disposition toutes les retombées presse.
C’est dans ce même contexte de restructuration qu’apparaisse notre projet de

digitalisation de la presse économique. Nous avons conçu une application mobile
sous forme de mini journal digital qui publie les news économiques sous forme de
briefs et podcasts.
Par conséquent, ce présent rapport qui est le rendu du travail réalisé durant cinq
mois de pratique avec la société "Saibi Intermediation" dans un programme d’incu-
bation avec l’incubateur "MEDIA LOVES TECH", est subdivisé en six chapitres :
Dans le premier chapitre intitulé "Contexte général du projet", nous présenterons

le projet, l’étude de l’existant, la méthode de travail utilisée et le planning du projet.
Le deuxième chapitre intitulé "Etude de marché", nous présenterons l’analyse

de l’environnement interne et externe, l’élaboration de la stratégie marketing suivie
par le Business Model canvas.
Le troisième chapitre intitulé Backlog du produit, nous exposerons tous les outils
utilisés pour la conception et le maquettage de la solution ainsi que le backlog du
produit.
Le quatrième et le cinquième chapitres contiendront l’analyse, la conception et

la réalisation de ces deux sprints.
Le sixième chapitre intitulé "Sprint (3)", sera consacré à l’analyse et la concep-

tion du dernier sprint.
Nous finirons notre rapport par une conclusion générale dans laquelle nous ré-
sumerons les axes de notre projet tout en exposant quelques vues futures.
2
Chapitre 1
Contexte général du projet
e premier chapitre a pour objectif mettre notre projet dans son cadre général.
C Tout d’abord nous présentons l’entreprise d’accueil Saibi Intermmediation
Suarl et son domaine d’activité, ainsi que l’incubateur du projet.
Ensuite nous annonçons la problématique qui nous guidera à la solution.

Nous exposons le chronogramme du projet, nous décortiquons les différents besoins
et les objectifs pour arriver au choix méthodologique.
1.1 Présentation de l’organisme d’accueil
Saibi Intermédiation Suarl a ouvert ses portes le 20 février 2019, étant une
entreprise spécialisée dans la facilitation des opérations de commerce international.
Elle a réussi à établir des partenariats avec des sociétés exportatrices de plusieurs
types de produits. Saibi Intermédiation Suarl est un "Courtier" qui joue le rôle
d’intermédiaire entre les importateurs et les fournisseurs (de produits).
L’objectif principal est de proposer les meilleurs rapports Qualité/Prix aux

clients tout en jouant sur les quantités du côté des producteurs.
3
CHAPITRE 1. CONTEXTE GÉNÉRAL DU PROJET
1.2 Présentation de l’incubateur du projet
Ce projet répond à des besoins exprimés par le chef de projet de la société Saibi
Intermediation dans le cadre de participation dans un programme d’incubation, qui
est MEDIA LOVES TECH. Ce dernier cherche à identifier et permettre la mise en
œuvre de solutions efficaces pour les enjeux et les problématiques des médias et du
journalisme en Tunisie, au Maroc et en Algérie.
MEDIA LOVES TECH est une initiative de DW Akademie, le centre de la

Deutsche Welle pour le développement international des médias, la formation jour-
nalistique et la transmission de connaissances.
L’incubateur est en partenariat avec Al Khatt ONG tunisienne qui œuvre pour
la liberté de la presse et l’expression et se veut un laboratoire d’idées sur l’avenir du
journalisme à l’ère d’internet.
1.3 Présentation du projet à réaliser
Dans la présente partie, nous allons donner un aperçu du sujet sur lequel nous
avons travaillé tout au long de la période du stage.
1.3.1 Problématique du projet
De nos jours, les réseaux sociaux tiennent un rôle d’information important au-
près des internautes notamment des jeunes, les personnes de plus de 60 ans restent
globalement fidèles aux journaux papiers.
La croissance d’internet et des réseaux sociaux laisse à penser que le journa-

lisme tel que nous l’entendons en tant que profession soit menacé par ces nouvelles
technologies.
Grâce à internet, nous obtenons l’information rapidement et en grande quantité

mais ne dit-on pas qu’être plus informé ne signifie pas forcément être mieux informé.
Rechercher et trier les bonnes informations parmi toutes les données qui n’ont
de cesse de s’accroître continuellement se révèle être particulièrement chronophage.
4
La visualisation des informations est par ailleurs un facteur de grande impor-

tance, elle doit être facilement accessible au lecteur et rédiger de façon adaptée à
leurs besoins.
Tandis que ces informations ont causé un bombardement incessant de notifica-

tions sur les smartphones, des sollicitations croissantes via les réseaux sociaux et de
la multiplicité des articles sur les sites web de presse.
Ceci a débordé les gens de l’économie. Ces derniers sont les experts, les consul-
tants et chercheurs de l’économie, ainsi que les sociétés commerciales, les Startups
et les sociétés de technologie.
Via notre projet nous visons à solutionner la problématique suivante :

•Comment le lecteur va accéder facilement à une information économique
bien structuré et adapté à son besoin ?
1.3.2 Etude de l’existant
L’étude de l’existant est une phase importante pour bien comprendre le système
et définir ses objectifs.
Cette partie a pour objectif de faire le tour sur les solutions similaires et les plus
connues sur le marché en dégageant les points forts et les points faibles de chacune
de ces solutions.
En Europe, il existe plusieurs applications mobiles de journalisme économique,

mais qui nécessite un abonnement pour chaque mois parmi lesquelles nous citons
LesEchos et Brief.me. En Tunisie, il existe ilBourssa.com.
5
Figure 1.1 – Application mobile "LesEchos"
LesEchos est l’application la plus complète en analyses, conseils, places de

cotation et outils financiers, pour réussir en Bourse.
Figure 1.2 – Application mobile "Brief.me"
Brief.me est un média indépendant édité par la société Brief.me. Sa mission est
de proposer un service d’information synthétique,qui explique et met en perspective
l’actualité.
6
Figure 1.3 – site web "ilboursa.com"
ilboursa.com est le premier portail boursier de nouvelle génération en Tunisie.

L’objectif du site est de développer la culture boursière et économique en Tunisie et
de contribuer au renforcement de la visibilité de la Bourse de Tunis pour y attirer
de nouveaux investisseurs.
1.3.3 Critique de l’existant
Nous allons citer dans le tableau1.1 les points forts et les points faibles de chaque
solution trouvée dans le paragraphe précédent.
7
—
Avantages Inconvénients
LesEchos -Accéder à toute l’actualité économique ; -Absence de changement de
mode de lecture sombre et
mode paysage
-Accéder à une information riche, variée, ac- -Application payante
cessible facilement et rapidement ;
-Avoir Une expérience unique et totalement
personnalisée autour de vos intérêts person-
nels ;
-Approfondir l’actualité à travers différentes
rubriques telles que : Economie, Finance, In-
dustrie, Politique, Business, International.
Brief.me -Brief.me, du lundi au vendredi à 18h30, -Absence d’archives de news
votre journal en ligne qui explique et met en
perspective ce qui s’est passé dans le monde.
-Brief.me Week-end, chaque samedi à 9h, une -Application payante
édition qui revient à la source d’un sujet d’ac-
tualité pour mieux le comprendre en donnant
du contexte et de la perspective historique.
-Brief.me Panorama : des synthèses théma-
tiques qui expliquent les principaux sujets
présents dans l’actualité. Un à deux nou-
veaux panoramas chaque mois.
ilboursa.com -ilboursa.com s’appuie sur des outils in- -Absence d’application mo-
contournables : cotations, actualités écono- bile
miques et financières, graphiques.
-L’aspect communautaire est particulière- -Site non ergonomique
ment développé (échanges d’avis).
-Site bien référencié. -Site non responsif
-Version gratuite.
Table 1.1 – Tableau comparatif entre les solutions existantes sur le marché
8
Le tableau 1.1 indique que les applications de journalismes ont presque les même
fonctionnalités sur le marché et que chaque application nécessite des frais.
1.3.4 Solutions
Les entreprises de presse profitent des possibilités de création offertes par le

numérique en général, en transformant le contenu journalistique en contenu essen-
tiellement cross media.
Dans cette perspective, un renouvellement des modèles éditoriaux s’est imposé :

diversité des formats de production, contenus hypermédia, délinéairisation de la
diffusion, nouvelles narrations et bien d’autres pratiques éditoriales marquent l’offre
journalistique.
Afin d’améliorer l’expérience client en ligne, une nouvelle application mobile

"Econo.Brief" verra le jour en proposant :
•un mini-journal digital qui permet de retrouver le lien entre ses lecteurs et
la presse économique via un Brief qui analyse ce qui est important et résume
ce qui est long ;
•et un podcast qui offre l’opportunité d’écouter les news économiques faci-
lement.
1.3.5 Chronogramme du projet
La clé principale de la réussite d’un projet est un bon planning. Nous avons
subdivisé les étapes nécessaires pour la réalisation du projet sous forme d’un tableau.
La figure 1.3.5 illustre le chronogramme que nous avons suivi tout au long du
cycle de vie du projet :
9
Figure 1.4 – Chronogramme du projet
Comme le montre la figure 1.3.5, cinq étapes principales peuvent être dégagées :
•Compréhension de sujet : elle permet de décortiquer, fixer les objectifs
et choisir la méthode de pilotage du projet,
•L’étude théorique : durant cette étape nous allons déterminer les théo-
ries, les concepts clés et les idées préexistantes liés à notre sujet pouvant
nous servir comme support de réalisation des objectifs fixés,
•Audit et Benchmarking : à ce niveau nous allons faire l’audit de la
présence d’applications similaires et une analyse de la concurrence dans l’en-
vironnement digital,
•Conception et réalisation : il s’agit de spécifier les besoins, les modéliser
et concevoir la plateforme,
•Rédaction du rapport :une description détaillée de notre travail.
1.3.6 Objectifs du projet
Le but de ce projet est de développer une application de journalisme économique

sur Android.
En effet, elle nous permettra dans un premier temps de diffuser l’information

économique. Cette application mobile sera utilisée par les gens de l’économie : les
10
experts, les consultants et chercheurs de l’économie, ainsi que les sociétés commer-
ciales, les Startups et sociétés de technologie.
Nos objectifs doivent répondre aux caractéristiques de l’acronyme SMART (Spé-

cifique, Mesurable, Atteignable, Réaliste, Temporel).
—
Objectifs Gain et augmentation des Internationalisation et déve-
SMART abonnées lopement sur le marché afri-
cain
Spécifiques Gagner et augmenter le taux Avoir une couverture sur toute
d’abonnements l’Afrique
Mesurables Atteinte de 1000 abonnées en 12 Taux d’engagement selon le posi-
mois tionnement géographique
Atteignables Avoir des abonnements grâce à la Avoir des abonnements grâce à la
version Premium et la publicité version Premium et la publicité
Réalistes Payement des abonnements payement des abonnements
Temporels Après la concrétisation de l’objec- Après la concrétisation de l’ob-
tif, au terme de la période d’un an jectif, au terme de la période de
nous pouvons affirmer si l’objectif quatre ans nous pouvons affirmer
a été atteint si l’objectif a été atteint
Table 1.2 – Les objectifs du projet
1.4 Choix de la méthode de travail
Un projet informatique, quelle que soit sa taille et la portée de ses objectifs,

nécessite la mise en place d’un planning organisationnel tout au long de son cycle de
vie. C’est ainsi qu’est apparue la notion de méthode. Une méthode, dans le contexte
informatique, peut être définie comme une démarche fournissant une méthodologie
et des notations standards qui aident à concevoir des logiciels de qualité. Le but de
cette partie est de montrer la méthode de travail que nous avons suivi tout au long
du projet.
11
1.4.1 Méthodologie agile
La gestion de projet agile est une méthodologie de développement itérative qui

valorise la communication humaine et le retour d’informations, l’adaptation aux
changements et la production de résultats de travail.
Figure 1.5 – Processus Agile
La figure 1.5 montre que les méthodes agiles utilisent un principe de dévelop-
pement itératif qui consiste à découper le projet en plusieurs étapes qu’on appelle
itérations.
Ces itérations sont des mini-projets définis avec le client en détaillant les diffé-
rentes fonctionnalités qui seront développées en fonction de leur priorité.
Le chef de projet établit alors un planning correspondant aux tâches nécessaires

pour le développement de ces fonctionnalités. Chaque itération se déroule entre trois
à quatre semaines en effectuant chaque jour une réunion quotidienne pour obtenir
un produit livrable.[1]
Parmi les méthodes agiles nous citons la méthode SCRUM et la méthodologie

XP.
12
1.4.2 Étude comparative de méthodes SCRUM et de mé-

thodologie XP
Il est très important de bien choisir la méthode de travail qui répond parfaite-
ment aux besoins et qui s’adapte le mieux aux exigences du client.
Alors, il est nécessaire de faire une étude comparative entre les méthodes pour
pouvoir sélectionner la meilleure qui s’adapte au projet.
Le tableau ci-dessous, décrit la méthode Scrum et la méthodologie XP de travail

ainsi que les points forts et les points faibles de chacune.
Description Points forts Points faibles

- Travail - Augmentation de la pro- -"Sprints" exigent un ni-
Scrum contrôlé quoti- ductivité ; veau de productivité maxi-
diennement mal pour tous les acteurs du
projet ;
- Se base sur - Simplicité des processus. -Si l’un des membres quitte
des itérations l’équipe cela peut perturber
dites sprints de l’ensemble du projet.
développement.
-Ensemble de -Simple à mettre en oeuvre -XP ne peut s’adresser qu’à
Méthode
"Best Practices" des projets petit ou moyens
XP
de développe- en raison de ses caractéris-
ment (Idéal tiques.
pour le travail
en groupe)
-Cible des pro- -Applicable pour les projets
jets de moins de complexes.
dix personnes
Table 1.3 – Analyse de méthodes et de méthodologie de travail
D’après le tableau 1.3, nous constatons que la méthodologie XP et la méthode

Scrum proposent de travailler d’une façon itérative, que ce soit au niveau des plan-
nings, de spécifications ou de développement.
13
1.4.3 Méthode de travail adoptée : SCRUM
A travers l’étude comparative définie dans le paragraphe précédent, nous avons

remarqué que toutes les méthodes étudiées assurent le travail itératif et incrémental,
et chacune met l’accent sur une phase bien déterminée. Nous avons opté pour la
méthode SCRUM car elle satisfait les conditions suivantes :
•Exprimer clairement les fonctionnalités de produit.
•Hiérarchiser les fonctionnalités de produit pour mieux atteindre les objec-
tifs et les missions.
•S’assurer que l’équipe de développement comprend suffisamment les fonc-
tionnalités de produit.
1.4.4 Principe de Scrum
La figure 1.6 illustre le principe d’un projet mené suivant la méthodologie Scrum.
Figure 1.6 – processus scrum
Nous constatons dans la figure 1.6 que tout projet Scrum commence par la
définition de backlog du produit.
En effet ce dernier sert à développer des produits, généralement en quelques

mois. Elle est focalisée sur un ensemble de fonctionnalités à faire, dans des itérations
appelées Sprints. Chaque Sprint vise un objectif défini par le directeur de produit
14
(Product owner), à partir duquel sont choisies les fonctionnalités à implémenter dans
ce backlog du sprint, en tenant compte des priorités et de la capacité de l’équipe.
Un sprint est un bloc de temps fixé aboutissant à créer un incrément du produit

potentiellement livrable qui dure entre 2 et 4 semaines.
La réunion quotidienne permet de faire un point avec toute l’équipe sur le travail
qu’il réalisera le jour même et liste les difficultés qu’il a rencontrées.
A la fin de chaque Sprint, l’équipe délivre un produit potentiellement livrable au
client.
1.4.5 Rôles de la méthode Scrum
La méthode Scrum définit trois rôles qui sont :

•Le Product Owner (le propriétaire du produit) :c’est une personne
qui porte la vision du produit à réaliser, généralement c’est un expert dans
le domaine.
•Le Scrum Master (le directeur du produit) : c’est la personne qui
doit assurer le bon déroulement des différents sprints du release et qui doit
impérativement maîtriser la méthode Scrum.
•Scrum Team (l’équipe de Scrum) : Il est constitué des personnes qui
seront chargées d’implémenter les différents besoins du client. Bien évidem-
ment, cette équipe sera constituée des développeurs, des infographistes et
des testeurs, etc.
Conclusion
Ce chapitre nous a présenté le cadre général du projet à savoir : l’organisme

d’accueil, la problématique et sa solution, les objectifs que nous sommes fixés ainsi
que la méthodologie à suivre pour le pilotage du projet.
Le chapitre qui suit portera sur une étude de marché ainsi que l’approche mar-
keting.
15
Chapitre 2
Etude de marché
ans le chapitre précédent, nous nous sommes intéressés à la présentation de

D l’organisme d’accueil, le cadre général du projet et le choix de la méthode de
travail en expliquant son principe.
Dans ce chapitre, nous présenterons l’analyse de l’environnement interne et ex-

terne, l’élaboration de la stratégie marketing suivie par l’utilisation de l’outil Lean
Canvas.
2.1 Analyse de l’environnement interne et externe
2.1.1 Benchmark
Le benchmark est une pratique de veille concurrentielle, qui sert à évaluer la

performance de notre projet pour satisfaire la clientèle et de le comparer avec les
concurrents. Ce benchmark est établi sur la base de nos concurrents.
Le tableau 2.1 illustre le benchmark concurrentiel, que nous avons réalisé afin
d’approfondir le diagnostic de l’environnement externe.
16
CHAPITRE 2. ETUDE DE MARCHÉ
Table 2.1 – Benchmark concurrentiel
Nous remarquons, à partir de cette étude, que les solutions existantes présentent
un manque de fonctionnalités par rapport à notre solution.
2.1.2 Les environnements adjacents (PESTEL)
L’analyse PESTEL est un outil d’analyse stratégique permettant à l’entreprise

d’identifier les facteurs externes qui ont un impact sur son activité.
Cet outil offre une vision synthétique et globale des éléments qui régissent le
marché dans le but d’élaborer une stratégie d’entreprise.
P- Politique :
Le secteur des Technologies de l’Information et de la Communication (TIC) est un
secteur prioritaire en Tunisie à la fois en tant que vecteur de développement des
autres secteurs économiques mais aussi en tant que secteur dynamique d’innovation
ouvert à l’international.
E – Économique :
Selon l’Institut National de la Statistique (INS), le secteur des technologies

de l’information et des télécommunications contribue à hauteur de 7.2 % du PIB et
emploie quelques 80 000 personnes (2016). Toujours selon la même source, le secteur
représente 1800 entreprises privées, 219 centres de services partagés, huit centres de
développement servant des multinationales, une densité téléphonique de 98,8 lignes
17
pour 100 habitants, plus de 3 millions d’internautes avec une évolution annuelle de
38% par an.
S – Social/ Socioculturel :
De nos jours, nos modes de vie changent grâce à la digitalisation car elle simplifie
notre quotidien. Il est donc important aux entreprises mais aussi aux médecins
de proposer à ces clients de nouveaux supports techniques. De plus, il y a une
amélioration concernant la compétitivité des start-up par l’investissement dans les
TIC et le positionnement dans l’économie numérique.
T–Technologique :
Le nouveau concept de la l’actualité économique commence à prendre de l’am-

pleur en Tunisie. En effet cette nouvelle technologie facilitera le travail des gens de
l’économie.
E– Écologique :
Le digital est devenu incontournable pour le développement durable et ainsi

limitant leur impact sur l’environnement. Mais selon le rapport Clicking Clean publié
le 10 janvier 2017 par Greenpeace, le secteur informatique représente aujourd’hui
environ 7 % de la consommation mondiale d’électricité. La pollution générée par
l’industrie du net et son impact sur le climat sont équivalents à ceux du secteur de
l’aviation.
L-légal/législative :
Le secteur des télécommunications a fait l’objet de réformes juridiques depuis

la fin des années 1990. Le Code des Télécommunications (CT) a été promulgué par
la loi n° 2001-1 (15 janvier 2001), la loi n° 2002-46 (7 mai 2002), la loi n° 2008-
1 (8 janvier 2008) ainsi que la loi n° 2013-10 (2 avril 2013). Loi N°2018-20 du 17
avril 2018 relative aux Startups La loi a pour objectif de mettre en place un cadre
incitatif pour la création et le développement de Startups basées, notamment, sur
la créativité, l’innovation et l’utilisation des nouvelles technologies et réalisant une
forte valeur ajoutée et une compétitivité aux niveaux national et international.[2]
18
2.1.3 Analyse swot
La figure 2.1 ci-dessous, dégage les menaces existantes à contrecarrer ainsi que
les opportunités offertes que nous allons en tirer profit par l’exploitation des forces
de Econo.Brief et la recherche des solutions adéquates pour les faiblesses détectées.
Figure 2.1 – Analyse SWOT
19
2.2 Élaboration de la stratégie marketing
L’attitude marketing consiste pour une entreprise à bien connaître son public
pour mieux s’y adapter et pour agir sur eux d’une manière plus efficace.
En effet, la mise en place de la stratégie marketing repose sur trois éléments

fondamentaux qui sont la segmentation, le ciblage et le positionnement .
2.2.1 Choix des critères de segmentation
La segmentation permet de clarifier la composition d’un marché. À terme, la

segmentation de la clientèle aide à diriger les efforts marketing vers la bonne au-
dience.
Pour segmenter le marché de la presse économique, nous avons besoin d’un

certain nombre de critères :
•Origine de l’information
Nationale 40.60 %
Internationale 24,74 %
— Grand Tunis 14,77 %
Provinces tunisiennes 13,19 %
Régional (Maghreb) 6,69 %
Table 2.2 – Origine de l’information
Le tableau 2.2 montre que plus de 40 % des articles traitent des questions nationales
(qui touchent l’ensemble des Tunisien(ne)s, par exemple les décisions du gouverne-
ment), suivi par ceux qui traitent des sujets internationaux (25 %). La plupart des
articles de cette dernière rubrique sont les dépêches des agences ou les brèves de jour-
naux internationaux. Si nous additionnons les trois rubriques « nationale», « grand
Tunis » et « provinces tunisiennes », nous obtenons 68,6 % du total des articles, ce
qui veut dire que la majorité de l’information provient de Tunisie.[3]
20
•Contenu des articles
Thèmes Distribution des articles ob-

servés par thème
Politique, conflits, gouvernement 19,61 %
Genre (en général) 17,87 %
Célébrités, arts et sport 12,80 %
Pratiques culturelles, reli- 10,75 %
gieuses,traditionnelles et genre
Violence liée au genre 10,50 %
Développement durable, ques- 9,83 %
—
tions sociales et juridiques, so-
ciété civile
Enfants et genre 6,14 %
Histoires centrées sur les femmes 4,30 %
Economie, affaires 3,02 %
Hommes et masculinité 2,36 %
Santé 1,79 %
Personnes âgées et genre 1,02 %
Total 100%
Table 2.3 – Pourcentage des articles classés dans les 12 thèmes définis
Le thème dominant était Politique, conflits, gouvernement (19,6 %), suivi par
Genre (en général) (17,8 %) et Célébrités, arts et sports (12,8 %). Avec presque
le même pourcentage de 10 % nous retrouvons les questions de Violence liée au
genre et Pratiques culturelles, religieuses, traditionnelles et genre, suivies de très
près par le groupe Développement durable, questions sociales et juridiques, société
civile (9,8%).[4]
•Utilisation d’Inernet en Tunisie
—
En 2006 En 2016
Utlisation d’Internet 13 % 46 %
Table 2.4 – Utilisation d’Internet en Tunisie
21
D’après le tableau 2.4, nous constatons une forte croissance d’utilisation d’In-
ternet durant la période 2006-2016.[5]
•Utilisation des Smartphones
Figure 2.2 – Utilisation des smatphones en Tunisie en 2020
A la fin de 2020, le nombre de smartphones atteint 7.63 millions (64 %).

Le nombre de tablettes (1 %) atteint 164 mille et le nombre de téléphones 4.1 millions
(35 %).[6]
2.2.2 Ciblage
Après avoir établi le profil des segments, l’entreprise doit choisir les segments
sur lesquels elle concentrera son effort. En effet, il existe trois principales stratégies
de ciblage :
• Marketing différencié : un seul segment avec un seul produit.
• Marketing de masse : un produit pour plusieurs segments.
• Marketing multi-segment : des produits différenciés pour chaque seg-
ment.
Nous avons choisi la stratégie de marketing de masse en proposant un service

qui correspond parfaitement aux attentes des utilisateurs.
22
2.2.3 Positionnement
Dans le but de distinguer notre positionnement dans le marché nous avons

recouru au benchmark concurrentiel réalisé, il fallait que nous ayons un avantage
concurrentiel par rapport à nos trois concurrents : Espace Manager, ilBoursa.com
et l’économiste.
•L’avantage compétitif de Espace Manager : Espace Manager se dis-
tingue par l’actualité vérifiée et une édition Bilingue(Francais et Anglais).
•L’avantage compétitif de ilBoursa.com : ilBoursa.com se distingue
par une actualité vérifiée et personnalisée).
•L’avantage compétitif de l’économiste : l’économiste se distingue par
une actualité vérifiée seulement).
•Positionnement de Econo.Brief : Econo.Brief englobe toutes les fonc-
tionnalités de ses concurrents et se différencie par une actualité simplifiée ,
abonnement pas cher et un service de podcast.
2.2.4 Business Model Canvas
Le business model canvas est un outil que nous l’utilisons pour retranscrire de
manière simple le modèle économique d’une entreprise.
Il est parfaitement adapté à la phase de création, et peut aussi être utilisé pour le
lancement d’un nouveau produit ou d’un nouveau service.
23
Figure 2.3 – Business Model Canvas de Econo.Brief
24
Conclusion
Ce chapitre a été consacré à l’étude de marché qui englobe le benchmarking,

Pestel et l’analyse swot. Par la suite, nous avons élaboré notre stratégie marketing
et nous avons défini le Business Model Canvas de Econo.Brief.
Dans le chapitre suivant, nous allons présenter le backlog du produit.
25
Chapitre 3
Backlog du produit
ans le chapitre précédent, nous nous sommes intéressés à l’étude de marché

D du lancement de Econo.Brief.
Dans ce chapitre, nous présenterons l’environnement de travail ainsi que le Ba-

cklog du produit.
3.1 Étude préliminaire
L’étude préliminaire est la première étape du processus de développement. Elle

consiste à déterminer les besoins fonctionnels et opérationnels de notre application
web. En plus, elle nous permet de spécifier en détail les fonctionnalités attendues
d’un service ou d’un produit. Ceci sera donc l’objectif de cette partie.
3.1.1 Identification des exigences fonctionnelles
Les besoins fonctionnels listent les fonctionnalités de base d’un système. Cette
application couvre les besoins suivants :
•Gestion de l’inscription : seul le système qui permet d’approuver ou
de refuser les utilisateurs inscrits après vérification de leurs identités et de
supprimer ceux qui s’avèrent frauduleux.
26
CHAPITRE 3. BACKLOG DU PRODUIT
•Gestion de l’authentification : Elle permet aux utilisateurs de s’ins-

crire,de s’identifier, de mettre à jour les informations professionnelles et de
réinitialiser le mot de passe.
•Publication des News : Elle permet de publier des actualités écono-
miques sélectionnées, simplifiées et vérifiées.
•Publication des services de podcasts : Elle permet de consulter les
news économique via version audio.
•Fonctionnalité payante (Version Premium) : Mettre des publicités
sous forme de bannières pour qu’elle soit visible au niveau de l’application.
•Consultation des news économiques : Elle permet de visualiser les
news économiques publiées au niveau de l’application
•Fonctionnalité payante (Version Premium ) : des rapports analy-
tiques incluant des indicateurs de performance.
3.1.2 Identification des exigences non fonctionnelles
Les exigences non fonctionnelles sont des besoins qui caractérisent le système
en matière de performance. Pour rendre le travail efficace aux utilisateurs, il est
important de répondre aux exigences de qualités suivants :
•Sécurité : L’application doit être sécurisée pour que les données des uti-
lisateurs de l’application ne sont pas divulguées.
•Maintenabilité et scalabilité : Le code de l’application doit être lisible
et compréhensible an d’assurer leur état évolutif et extensible par rapport
aux besoins du marché.
•Responsive Design : Le design de l’application mobile doit être adapté
à toutes les tailles et résolutions d’écran.
•Performance : Les traitements doivent être optimisés pour avoir un court
temps de réponse.
•L’ergonomie : L’application offre une interface conviviale et facile à uti-
liser.
27
3.2 Spécifications techniques
Les besoins techniques donnent une vision globale sur l’architecture générale
de notre projet qui aboutit à développer l’application web. La première question
qui se pose pour la réalisation de la partie technique du projet c’est quelles sont
les technologies à utiliser pour assurer le bon fonctionnement de l’application. La
présente partie se concentre sur le choix de certaines technologies.
3.2.1 L’architecture logicielle
L’architecture logicielle décrit d’une manière symbolique et schématique les dif-

férents éléments d’un ou de plusieurs systèmes informatiques, leurs interrelations et
leurs interactions.
Contrairement aux spécifications produites par l’analyse fonctionnelle, le modèle

d’architecture, produit lors de la phase de conception, ne décrit pas ce que doit
réaliser un système informatique mais plutôt comment il doit être conçu de manière à
répondre aux spécifications. L’analyse décrit le « quoi faire » alors que l’architecture
décrit le « comment faire ».
Dans notre projet nous avons choisi de développer l’application avec le modèle
MVC : Model, View, Controller, qui constituent les trois couches de cette
architecture.
En effet, ce modèle fonctionne comme suit :
•Le modèle stocke la structure et l’état de l’objett modélisé.
•Le contrôleur permet de faire le lien entre la vue et le modèle, il modifie
la vue, et gère les différents outils tels que l’outil de sélection ou le crayon.
•La vue affiche le modèle et de récupérer les interactions avec l’utilisateurr
Elle constitue l’interface entre l’utilisateurr et le contrôleur.
En effet, ce choix permet de faciliter la maintenance et les évolutions futures
de la plateforme grâce à la séparation entre les différentes couches. Ainsi,
elle rend le travail plus facile aux développeurs (front-end et back-end) sur
le même projet.
28
3.2.2 Outils de design
Adobe Photoshop est une application logicielle de retouche d’image et de re-

touche photo et offre aux utilisateurs la possibilité de créer, d’améliorer ou de mo-
difier des images, des photos ou des illustrations.
Adobe Illustrator est un logiciel de création graphique vectorielle et offre des ou-
tils de dessin vectoriel puissants. Les images vectorielles sont constituées de courbes
générées par des formules mathématiques.
3.2.3 Outil de maquettege
Adobe XD est une application de conception d’expérience utilisateur développée

et publiée par Adobe. Il prend en charge la conception de vecteurs, le wireframing,et
de créer des prototypes interactifs simples.
3.2.4 Environnement de conception
UML : C’est un langage de modélisation normalisé à base de diagrammes, déve-

loppé pour aider les développeurs à spécifier, visualiser et construire la conception
de systèmes logiciels.
3.2.5 Outil de plannification
Trello est une application de gestion de projet gratuite qui permet d’organiser
ses projets sous forme de tableaux, eux-mêmes composés de listes en colonnes, qui
répertorient des tâches sous formes de cartes.
29
3.3 Spécifications générales des exigences
Une fois que les besoins fonctionnels et non fonctionnels sont établis, nous allons
proposer la spécification des exigences à partir des besoins identifiés. Pour ce faire,
nous allons dégager en premier lieu le diagramme de cas d’utilisation général et
le diagramme de classes global du projet. Par la suite nous allons passer vers la
classification et la planification des cas d’utilisation en itérations.
3.3.1 Détermination du cas d’utilisation global
Le diagramme des cas d’utilisation décrit le comportement (actions et réactions)

du système vis-à-vis de ses utilisateurs. L’ensemble des cas d’utilisation doit décrire
les exigences fonctionnelles du système. Nous avons dégagé le cas d’utilisation sui-
vants
Figure 3.1 – Diagramme des cas d’utilisation global
30
3.3.2 Détermination du diagramme de classes de conception

global du projet
Le diagramme de classes de conception indique les classes du système, leurs re-

lations (y compris l’héritage, l’agrégation et l’association), ainsi que leurs opérations
et attributs. Tout au long de ce projet, nous essayerons de construire le diagramme
ci-dessous.
Figure 3.2 – Diagramme de classe
D’après la figure 3.2 nous constatons qu’il y a trois classes décrivant l’application
mobile courante :
•Classe "Utilisateur" : Cette classe représente toutes les informations
liées aux comptes des utilisateurs du système qui peuvent être un simple
utilisateur ou un administrateur.
•Classe "Article News" : : Cette classe contient toutes les informations
liées aux articles résumés.
31
•Classe "Avis" :Regroupe les commentaires publiés par les utilisateurs de

l’application sur un article.
3.4 Backlog du produit
Dans cette section, d’abord, nous allons présenter le tableau de backlog du

produit. Ensuite, nous présenterons les rôles de chaque membre de l’équipe dans la
méthodologie du Scrum.
3.4.1 Définition
Le backlog du produit est l’élément le plus important de Scrum puisqu’il repré-

sente l’ensemble des caractéristiques fonctionnelles ou techniques qui constituent le
produit souhaité.
Les caractéristiques fonctionnelles sont appelées des histoires utilisateur (user

story) qui décrivent les interactions de l’utilisateur avec l’application. Dans un ba-
cklog du produit, les stories sont rangées selon l’ordre envisagé pour leur réalisation.
3.4.2 Tableau de backlog du produit
Le backlog du produit dans le tableau 3.1 ci-dessous, montre la liste des fonc-
tionnalités qui devront être implémentées dans notre application web. Celui-ci est
présenté dans l’ordre de priorités.
Le choix des priorités dans cette section est basé sur la dépendance entre les
fonctionnalités de l’application.Par exemple, nous ne pouvons pas effectuer la gestion
de profil tant que nous n’avons pas encore terminé la gestion de l’authentification.
32
Histoires utili- Estimations Priorités Descriptions Sprint

sateurs (User
Story)
S’inscrire 14jours Haute En tant qu’utilisa- 1
teur, il peut créer un
compte.
S’authentifier 8jours Haute En tant qu’utilisateur, 1
il peut se connecter à
l’application mobile.
Gérer le profil 13jours Haute En tant qu’utilisateur, 1
il peut faire la mise
à jour de ses informa-
tions personnelles.
Payer un abon- 14jours Haute En tant qu’utilisateur, 2
nement il peut payer un abon-
nement pour se béné-
ficier des services pre-
mium.
Consulter les 18jours Moyenne En tant qu’utilisateur, 2
News il peut faire apparaître
sur l’écran la liste des
articles de News dis-
ponible.
Ecouter les pod- 15 jours Moyenne En tant qu’utilisateur, 2
casts il peut écouter les
podcasts.
Mettre à jour 4jours Moyenne En tant qu’adminis- 3
l’application trateur, il peut mettre
à jour les fonctionnali-
tés de l’application.
33
Gérer les 9 jours Haute En tant qu’adminis- 3

comptes uti- trateur, il peut véri-
lisateurs fier l’authenticité les
comptes utilisateurs.
Soit il autorise l’accès
ou il refuse, en suppri-
mant des comptes uti-
lisateurs frauduleux.
Publier les News 9 jours Moyenne En tant qu’adminis- 3
et les podcasts trateur, il publie les
actualités et les pod-
casts.
— Backlog du produit
Le tableau 3.4.2 résume le Backlog du produit de notre future application.

Dans ce tableau chaque histoire utilisateur (User Story) est caractérisée par un rang
déduit à partir de sa priorité expliqués dans le paragraphe précédent de cette même
section.
Pour commencer la réalisation de nos histoires utilisateur, nous avons choisi les
cas d’utilisation les plus prioritaires.
3.4.3 Définition des rôles dans SCRUM
La méthode Scrum est basée sur trois rôles initiaux qui vont être affectés au
membre de projet.
Le tableau 3.2 ci-dessous présente la répartition des rôles dans Scrum.
34
Rôles Noms des membres

Le propriétaire du produit (Product Owner) Ahmed kamoun Insaf Trabelsi
Le directeur du produit (SCRUM Master) Yemen Saibi
Le membre de l’équipe (SCRUM Team) Ahmed kamoun Insaf Trabelsi
Table 3.2 – Rôles des membres du SCRUM
3.4.4 Planification des sprints
La réunion de planification des sprints est l’événement le plus important dans

la méthode de travail Scrum.
Le but de cette réunion est de préparer le planning de travail,d’identifier le

backlog des sprints et de choisir la durée des sprints qui diffère selon la complexité
du projet et la taille de l’équipe.
Comme le montre la figure 3.3, notre projet se déroule en trois livrables (Sprints).
Figure 3.3 – Planing des sprints
35
Conclusion
Ce chapitre a été consacré à la présentation de l’environnement de travail et le

backlog de produit.
Dans le chapitre suivant, nous montrerons la conception et la réalisation du

premier sprint.
36
Chapitre 4
Sprint (1)
ans le chapitre précédent, nous nous sommes focalisés sur l’étude préliminaire
D du projet, son étude technique, et la planification des différentes tâches.
Dans ce chapitre, nous nous intéresserons au développement du premier sprint.

Ce dernier se décompose en trois user stories :
Histoires utilisa- Estimations Priorités Descriptions

teurs(UserStory)
S’inscrire 14jours Haute En tant qu’utilisateur, il peut
créer un compte.
S’authentifier 8jours Haute En tant qu’utilisateur, il peut
se connecter à l’application
mobile.
Gérer le profil 13jours Haute En qu’utilisateur, il peut faire
la mise à jour de ses informa-
tions personnelles.
Table 4.1 – Backlog du sprint (1)
Le tableau 4.1 résume les fonctionnalités à réaliser du premier sprint.

Dans ce sprint nous pouvons dégager trois activités principales qui sont la spécifi-
cation fonctionnelle, la conception et le maquettage.
37
CHAPITRE 4. SPRINT (1)
Tout au long de ce sprint, nous respectons ces activités pour construire le plan de
trois cas.
4.1 S’inscrire
La section qui suit présente l’analyse et la conception de cas d’utilisation s’ins-

crire.
4.1.1 Diagramme de cas d’utilisation "s’inscrire"
La figure suivante illustre le digramme de cas d’utilisation de "s’inscrire" pour

l’utilisateur.
Figure 4.1 – Diagramme de cas d’utilisation "s’inscrire"
4.1.2 Tableau descriptif des scénarios du cas d’utilisation

"s’inscrire"
Dans le but de rendre notre diagramme de cas d’utilisation plus lisible et afin de
décrire le comportement d’un système, nous avons décidé d’utiliser la technique de
la description textuelle des cas d’utilisation pour détailler l’enchaînement des tâches.
38
Cas d’utilisation S’inscrire

Acteurs Utilisateurs
Précondition Espace de stockage disponible Télécharger
l’application mobile
Postcondition Avoir un compte
Scénario nominal 1-Ouvrir l’application
2-Cliquer sur l’onglet pour accéder à l’inter-
face de l’inscription
3-Saisir les informations personnelles tels que
le nom, le prénom, l’adresse email, le mot de
passe, etc...
4- Inscription réussite
5- Retourner à la page d’accueil de l’applica-
tion
Scénario alternatif 1-a-1 Le système affiche un message de type
" l’adresse email existe déjà "
1-a-2 Reprise de l’étape 3 du scénario nomi-
nal
Table 4.2 – Description des scénarios du cas d’utilisation " s’inscrire "
Le tableau 4.3 présente l’enchaînement détaillé du cas d’utilisation s’inscrire :

Depuis le tableau 4.3 nous constatons que l’inscription d’un utilisateur nécessite la
disponibilité de l’espace de stockage du smartphone et le téléchargement de l’appli-
cation mobile. Après le mobinaute ouvre l’application, clique sur l’interface d’ins-
cription et saisit ses informations personnelles. Dans cette étape notre système vérifie
les données saisies.
Dans le cas où un compte est attribué déjà à cet utilisateur, le système affiche
un message d’erreur, en demandant de ressaisir une autre fois ses informations, sinon
il sera redirigé vers la page d’accueil.
39
4.1.3 Diagramme de séquence de cas d’utilisation "s’ins-

crire"
La figure suivante illustre le digramme de séquence de "s’inscrire" pour l’utilisa-

teur.
Figure 4.2 – Diagramme de séquence "s’inscrire"
Selon, le diagramme de séquence, après que l’utilisateur ait saisi ses informa-
tions, la vue « inscription » effectue la vérification des champs.
En cas d’erreur de saisie, un message d’erreur sera envoyé à l’utilisateur pour res-
saisir ses informations. Sinon les données seront envoyées au contrôleur « Gestion
inscription » qui les envois au système, où se fait la vérification des informations et
l’envoi du résultat.
Par la suite, c’est au contrôleur qui procède à la destruction de la vue "inscription" :
si le résultat indique une erreur et si l’inscription est réussie, l’utilisateur sera ren-
voyé directement à la vue " Compte utilisateur" pour terminer la création de son
compte.
40
4.2 S’authentifier
Cette section, présente l’analyse et la conception de cas d’utilisation "S’authen-

tifier".
4.2.1 Diagramme de cas d’utilisation "s’authentifier"
Figure 4.3 – Diagramme de cas d’utilisation "s’authentifier"

”s’authentifier”
41
Cas d’utilisation S’authentifier

Objectifs/Résumé Se connecter à l’application
Précondition - Connexion internet disponible (Wifi/3G/4G)
- L’utilisateur doit être inscrit sur la plateforme.
- L’utilisateur doit connaitre ses identifiants.
Scénario nominal 1- Accéder à la plateforme.
2- Cliquer sur le bouton "s’authentifier".
3- Accéder à la vue authentification.
4- L’internaute saisit ses identifiants.
5- L’internaute clique sur le bouton "se connecter" .
6- Le système vérifie les informations saisies par l’utili-
sateur.
7- Le système renvoi vers la page d’accueil.
Scénario alternatif - Le système affiche un message d’erreur de type "votre
mot de passe est incorrect" ou "votre identifiant est in-
correct".
- Reprise de l’étape 3 du scénario nominal
Exceptions - Connexion interrompue
- L’utilisateur n’est pas inscrit
Postcondition - Avoir un compte.
- Utilisateur inscrit et authentifié par une adresse élec-
tronique et un mot de passe.
Table 4.3 – Description des scénarios du cas d’utilisation " s’authentifier "
42
4.2.3 Diagramme de séquence "S’authentifier"
La figure suivante illustre le digramme de séquence de "s’authentifier" pour l’uti-

lisateur.
Figure 4.4 – Diagramme de séquence de "s’authentifier"
D’après le diagramme, après que l’utilisateur ait saisi son identifiant et mot de
passe, la vue "authentification" effectue la vérification des champs.
En cas d’erreur de saisie, un message d’erreur sera envoyé à l’utilisateur pour

ressaisir ses informations, sinon les données seront envoyées au contrôleur "Gestion
authentification" qui les lit et les envois à son tour au système.
Durant cette opération, une recherche de l’identifiant et du mot de passe saisis et

l’envoi de la réponse s’effectuent par la suite le contrôleur procède à la destruction de
la vue "authentification". Le système affiche un message d’erreur d’authentification
à l’utilisateur si la réponse indique une erreur.
43
4.3 Gérer son profil
Cette section, présente l’analyse et la conception de cas d’utilisation "Gérer son

profil".
4.3.1 Diagramme de cas d’utilisation "Gérer son profil"
Figure 4.5 – Diagramme de cas d’utilisation de "Gérer son profil"
4.3.2 Tableau descriptif des scénarios du cas d’utilisation"Gérer

son profil"
Cas d’utilisation Gérer son profil

Objectifs/Résumé Mettre à jour ses informations et ses publications.
Précondition Être authentifié.
Scénario nominal 1- Accéder à la plateforme

2- S’authentifier
3- Modifier/supprimer/ajouter
Scénario alternatif —
Exceptions Connexion interrompue
Postcondition Profil mis à jour
Table 4.4 – Description des scénarios du cas d’utilisation" Gérer son profil "
44
4.3.3 Diagramme de séquence de "Gérer son profil"
La figure suivante illustre le digramme de séquence de "gérer son profil" pour

l’utilisateur.
Figure 4.6 – Diagramme de séquence de "gérer son profil"
D’après la figure, après que l’utilisateur ait saisi son identifiant et mot de passe,
la vue "authentification" effectue la vérification des champs. Quand les champs saisis
sont vérifiés, les données seront envoyées au contrôleur "Gestion de profil" qui les lit
et les envoie à son tour au système. Après, ce dernier valide. Finalement le profil
sera mis à jour.
4.4 Réalisation du sprint (1)
Dans cette partie nous avons réalisé les interfaces principales du sprint (1).
Les figures ci-aprés les présentent :
45
•L’interface "Accueil" : Cette interface permet à accéder à notre application

Econo.Brief .
•L’interface "Inscription" : Cette interface permet aux utilisateurs de choisir
le type d’inscription.
•L’interface "Connexion" : Cette interface permet aux utilisateurs de se
connecter.
Figure 4.8 – Interface de

Figure 4.7 – Interface de "Acceuil" "Connexion"
46
Figure 4.9 – Interface "Inscription"
Conclusion
Au niveau de ce chapitre, nous avons travaillé sur le sprint (1).

Outre, après la conception du ce sprint, nous avons procédé au maquettage de
quelques interfaces avec Adobe XD.
47
Chapitre 5
Sprint (2)
ans ce chapitre, nous allons détailler les différents User Story du sprint (2).
D Ce dernier se décompose en trois user stories :
—
teurs(UserStory)
Payer un abonne- 14jours Haute En tant qu’utilisateur, il peut
ment payer un abonnement pour
se bénéficier des services pre-
mium.
Consulter les News 18jours Moyenne En tant qu’utilisateur, il peut
faire apparaître sur l’écran la
liste des articles de News dis-
ponible.
Ecouter les pod- 15 jours Moyenne En tant qu’utilisateur, il peut
casts écouter les podcasts.
Le tableau 5.1 résume les fonctionnalités à réaliser du deuxième sprint. Dans ce

sprint nous pouvons dégager trois activités principales qui sont la spécification fonc-
tionnelle,la conception et le maquettage. Tout au long de ce sprint, nous respectons
ces activités pour construire le plan de trois cas.
48
5.1 Payer un abonnement
La section qui suit présente l’analyse et la conception de cas d’utilisation "payer

un abonnement".
5.1.1 Diagramme de cas d’utilisation "Payer un abonne-

ment"
Figure 5.1 – Diagramme de cas d’utilisation "Payer un abonnement"
5.1.2 Description textuelle des scénarios du cas d’utilisation

"Payer un abonnement"
Le tableau 5.2 présente les scénarios du cas d’utilisation « payer un abonne-

ment» :
49
Cas d’utilisation Payer un abonnement

Acteurs Utilisateur
Objectifs / résumé L’utilisateur paye un abonnement parmi les
différents abonnements.
Préconditions Abonnement présélectionné
Scénario nominal 1-Accéder à la plateforme
2-S’authentifier
3-Ouvrir l’onglet paramètres
4- Choisir le type d’abonnement
5- Choisir le moyen de payement
6-Entrer les informations nécessaires de paye-
ment
7- Payer
Enchainements alternatifs Le système affiche un message d’erreur de
type « carte invalide » ou « échec de paye-
ment ».
Exception 1- connexion interrompue
2-Exécution erronée
Post conditions Abonnement payé
Table 5.2 – Tableau descriptif du cas d’utilisation "Payer un abonnement "
5.1.3 Diagramme de séquence de cas d’utilisation "Payer un

abonnement"
La figure suivante illustre le digramme de séquence de "Payer un abonnement"

pour l’utilisateur.
50
Figure 5.2 – Diagramme de séquence "Payer un abonnement"
5.2 Consulter les news :
La section qui suit présente l’analyse et la conception de cas d’utilisation «

Consulter les news ».
5.2.1 Diagramme de cas d’utilisation "Consulter les news "
Figure 5.3 – Diagramme de cas d’utilisation "Consulter les news"
51

"Consulter les News"
Cas d’utilisation Consulter les news

Acteurs Utilisateur
Objectifs / résumé L’utilisateur consulte les articles de news pu-
bliés.
Préconditions Inscription et/ou Abonnement payé
2-S’authentifier
3-Choisir un article à lire
Enchainements alternatifs Possibilité d’enregistrer l’article.
3-Article supprimé
Post conditions Article consulté
Table 5.3 – Description textuelle du cas d’utilisation "Consulter les news"
5.2.3 Diagramme de séquence de cas d’utilisation "Consul-

ter les news"
La figure suivante illustre le digramme de séquence de "Consulter les news"pour

l’utilisateur :
52
Figure 5.4 – Diagramme de séquence "Consulter les news"
5.3 Ecouter les podcasts :
5.3.1 Diagramme de cas d’utilisation "Ecouter les podcasts"
Figure 5.5 – Diagramme de cas d’utilisation "Ecouter les podcasts"
53

"Mettre à jour l’application"
Cas d’utilisation Ecouter les podcasts

Acteurs Utilisateur
Objectifs / résumé L’L’utilisateur les podcasts des news publiés.
Préconditions Inscription et/ou Abonnement payé
2-S’authentifier
3-Choisir un article à écouter
Enchainements alternatifs Possibilité d’enregistrer le podcast de l’ar-
ticle .
3-Article supprimé
Post conditions Podcast écouté
Table 5.4 – Description textuelle du cas d’utilisation "Ecouter les podcasts"
5.3.3 Diagramme de séquence de cas d’utilisation "Ecouter

les podcasts"
La figure suivante illustre le digramme de séquence de "Ecouter les podcasts"pour

l’utilisateur :
54
Figure 5.6 – Diagramme de séquence "Ecouter les podcasts"
5.4 La réalisation du sprint (2)
Dans cette partie nous avons réalisé les interfaces principales du sprint 2. Les
figures ci-dessous les présentent :
55
•L’interface de "Payement" : Cette interface permet aux utilisateurs de

payer un abonnement à travers le compte "e-dinar" ou à partir d’une carte
bancaire.
Figure 5.7 – Interface de "Payement" Figure 5.8 – Interface de "Payement"

par "e-dinar" par carte bancaire
56
•L’interface "Affichage des articles" : Cette interface permet aux utilisa-

teurs de consulter les articles publiés et de choisir l’article souhaité.
Figure 5.9 – Interface d’ "Affichage Figure 5.10 – Interface de "l’affichage

des articles" de l’article choisi"
57
•L’interface "Ecouter les podcasts" : Cette interface permet aux utilisa-

teurs d’écouter le podcast de l’article choisit.
Figure 5.11 – Interface "Ecouter les podcasts"
Conclusion
Au niveau de ce chapitre, nous avons travaillé sur le sprint N°2.
Outre, après la conception du ce sprint, nous avons procédé au maquettage de

quelques interfaces avec adobe xd.
58
Chapitre 6
Sprint (3)
ans ce chapitre, nous allons détailler les différents User Story du sprint 3.
D En se basant sur le même principe des deux sprints, nous allons suivre les trois
activités principales qui sont la spécification fonctionnelle, la conception et le ma-
quettage. Tout au long de ce sprint, nous respectons ces activités pour construire ce
produit. Ce dernier se décompose en trois user stories :
—
teurs(UserStory)
Mettre à jour l’ap- 4jours Moyenne En tant qu’administrateur, il
plication peut mettre à jour les fonction-
nalités de l’application.
Gérer les comptes 9 jours Haute En tant qu’administrateur, il
utilisateurs peut vérifier l’authenticité les
comptes utilisateurs. Soit il auto-
rise l’accès ou il refuse, en sup-
primant des comptes utilisateurs
frauduleux.
Publier les News et 9 jours Moyenne En tant qu’administrateur, il pu-
les podcasts blie les actualités et les podcasts.
59
6.1 Mettre à jour l’application
La section qui suit présente l’analyse et la conception de cas d’utilisation «

Mettre à jour l’application ».
6.1.1 Diagramme de cas d’utilisation "Mettre à jour l’appli-

cation"
La figure suivante illustre le digramme de cas d’utilisation de "Mettre à jour

l’application" pour l’administrateur.
Figure 6.1 – Diagramme de cas d’utilisation "Mettre à jour l’application "
60

"Mettre à jour l’application"
Cas d’utilisation Mettre à jour l’application

Acteurs Administrateur
Objectifs / résumé Apporter des modifications sur l’application.
Préconditions 1-Connection internet disponible
(Wifi/3G/4G)
2-L’administrateur doit connaitre ses identi-
fiants.
2-S’authentifier
3-Modifier le code de l’application et fixer les
bugs
4-Faire des tests
Enchainements alternatifs —
Exception -Problème de serveur
Post conditions Application mise à jour
Table 6.2 – Description textuelle du cas d’utilisation "Mettre à jour l’application"
6.1.3 Diagramme de séquence de cas d’utilisation "Mettre

à jour l’application"
La figure suivante illustre le digramme de séquence de "Mettre à jour l’applica-

tion" pour l’administrateur.
61
Figure 6.2 – Diagramme de séquence "Mettre à jour l’application"
6.2 Gérer les comptes utilisateurs
La section qui suit présente l’analyse et la conception de cas d’utilisation « Gérer

les comptes utilisateurs ».
6.2.1 Diagramme de cas d’utilisation "Gérer les comptes

utilisateurs"
La figure suivante illustre le digramme de cas d’utilisation de "Gérer les comptes

utilisateurs" pour l’administrateur.
62
Figure 6.3 – Diagramme de cas d’utilisation "Gérer les comptes utilisateurs "
6.2.2 Tableau descriptif des scénarios de cas d’utilisation

"Gérer les comptes utilisateurs"
Le tableau présente les scénarios du cas d’utilisation " Gérer les comptes utili-
sateurs" :
Cas d’utilisation Gérer les comptes utilisateurs

Objectifs / résumé Vérifier l’authenticité de l’utilisateur inscrits
Préconditions 1-Connection internet disponible (Wifi/3G/4G)
2-L’administrateur doit connaitre ses identifiants.
2-S’authentifier
3-Vérifier les informations de l’utilisateur
4-Autoriser l’accès
Enchainements alternatifs Si les informations de l’utilisateur sont invalides, l’admi-
nistrateur refuse l’accès ou supprime le compte.
Exception —
Post conditions -Compte utilisateur géré
Table 6.3 – Description textuelle du cas d’utilisation "Gérer les comptes utilisa-
teurs"
63
6.2.3 Diagramme de séquence de cas d’utilisation "Gérer les

comptes utilisateurs"
La figure suivante illustre le diagramme de séquence de "Gérer les comptes uti-

lisateurs" pour l’administrateur.
Figure 6.4 – Diagramme de séquence "Gérer les comptes utilisateurs"
6.3 Publier les news et les podcasts
La section qui suit présente l’analyse et la conception de cas d’utilisation "Pu-

blier les News et les podcasts".
6.3.1 Diagramme de cas d’utilisation "Publier les News et

les podcasts"
La figure suivante illustre le digramme de cas d’utilisation de "Publier les News

et les podcasts" pour l’administrateur.
64
Figure 6.5 – Diagramme de cas d’utilisation "Publier les News et les podcasts "
6.3.2 Tableau descriptif des scénarios de cas d’utilisation

"Publier les News et les podcasts"
Cas d’utilisation Publier les News et les podcasts

Objectifs / résumé Les News et les podcasts ser
Préconditions 1-Connection internet disponible (Wifi/3G/4G)
2-L’administrateur doit connaitre ses identifiants.
2-S’authentifier
3-Choisir les articles et/ou podcasts à publier
4-Publier les articles et/ou podcasts
Enchainements alternatifs —
Exception - Connexion interrompue
Post conditions - News et podcasts publiés
Table 6.4 – Description textuelle de cas d’utilisation "Publier les News et les pod-
casts"
65
6.3.3 Diagrmme de séquence de cas d’utilisation "Publier

les News et les podcasts"
Figure 6.6 – Diagramme de séquence "Publier les News et podcasts"
6.4 Réalisation du Sprint(3)
Dans cette partie nous avons réalisé les interfaces principales du sprint 3. Les
figures ci-aprés les présentent :
66
Figure 6.7 – Interface d’un exemple

Figure 6.8 – Interface de l’accès ad-
d’un article à publier
ministrateur
Conclusion
À ce stade, nous avons réussi donc à développer les différents sprints de l’appli-
cation pour arriver à un produit complet.
Cette solution demeure à présent efficace, mais la science de l’information ne

cesse d’évoluer et par conséquent de nouveaux horizons peuvent être créés pour cette
solution.
67
Conclusion Générale
es lecteurs de la presse économique de nos jours sont constamment à la re-

L cherche des solutions pour accéder à l’information via internet. Cependant,
la visualisation des informations est par ailleurs un facteur de grande importance,
elle doit être facilement accessible aux lecteurs et rédiger de façon adaptée à leurs
besoins.
La solution la plus efficace consiste à développer une application, que nous avons
essayé tout au long du notre travail, de la construire, incrément par incrément en
utilisant la méthode Scrum.
Lors de la réalisation du projet nous avons étudié, conçu et faire le maquettage

de cette application Econo.Brief, qui permet de retrouver un lien entre les lecteurs
et la presse économique, en proposant un brief qui résume ce qui est long, sous forme
de texte ou un service de podcast.
Le point de départ de la réalisation de ce projet était de présenter l’organisme

d’acceuil, l’étude de l’existant, le choix de la méthode de travail, et la présentation
d’un aperçu global sur la problématique. Par la suite, nous avons réalisé un étude
de marché ainsi que notre stratégie marketing.
Nous nous sommes intéressés dans la partie suivante à spécifier les fonctionna-
lités de base de système ainsi que leur analyse et la justification des choix d’outils
de travail. Le dernier volet de notre projet était la mise en oeuvre de l’organisation
des environnements du travail ainsi que la conception des besoins et le maquettage
de ses différentes fonctionnalités.
CONCLUSION GENERALE
Ce travail était très intéressant, puisqu’il nous a permis de découvrir le monde de

l’Entrepreneuriat et les Start-Up, en travaillant avec l’incubateur MEDIA LOVES
TECH, qui nous a suivi par un programme d’accompagnement, et nous étions parmi
les finalistes et une prix spécial a récompensé notre travail avec une valeur de 3 000€.
Finalement, notre travail ne s’arrête pas à ce niveau, il est prêt pour toute
amélioration envisageable. En effet, plusieurs fonctionnalités peuvent être ajoutées
à l’application notamment l’intégration d’un espace de commentaires pour donner
l’accès aux utilisateurs de mettre leurs points de vue.
69
Bibliographie
[1] B.E. Haddad and J. Oger. Scrum, de la théorie à la pratique : initiation, perfec-
tionnement, agilité. Génie logiciel. Eyrolles, 2017. Dernière date de consultation
le : 18/12/2021, P 9-14 / P 55-62 / P 111-120.
[2] site http ://www.ordi3-0.fr/impact-environnemental-numerique.html.
[3] site https ://mdc.tn/wp-content/uploads/2019/05/OBSERVATION-DE-LA-

PRESSE-ECRITE-TUNISIENNE.pdf, consulté le 18/12/2021.
[4] site https ://mdc.tn/wp-content/uploads/2019/05/OBSERVATION-DE-LA-

PRESSE-ECRITE-TUNISIENNE.pdf, consulté le 18/12/2021.
[5] site https ://tunisia.mom-rsf.org/fr/medias/presseenligne/.
[6] site https ://www.leconomistemaghrebin.com/2021/02/24/usages-terminaux-

60-tunisiens-possedent-smartphone/.
70
Annexe A
Annexe
Enquête sur la presse économique - Econo.Brief
71
13/11/2021 20:09 Enquête sur la presse économique
Enquête sur la presse économique

Mesdames, Messieurs,
Parce que les "Gens de l’économie" sont débordés par l’information et n’ont pas le temps,
au cours de la journée, pour scruter les sites d’infos et les réseaux sociaux, nous avons
pensé à créer un mini-journal économique afin de retrouver le lien entre les lecteurs et la
presse économique.
Econo.Brief propose un Brief de l'actualité économique en analysant ce qui est important

et en résumant ce qui est long.
Dans cette optique, nous aimerions avoir votre avis sur notre service en remplissant le
questionnaire. Vos réponses nous aideront à optimiser en profondeur et en continu notre
projet.
Bien entendu, nous traiterons vos réponses avec la plus grande confidentialité.
Merci beaucoup de votre soutien.
*Obligatoire
1. Êtes-vous lecteur de la presse économique ? *
Une seule réponse possible.
Régulièrement
Occasionnellement
Jamais
2. À quelle période de la journée lisez-vous la presse? *
Plusieurs réponses possibles.
Le matin
Pendant la journée
Le soir après le travail
https://docs.google.com/forms/d/1kT7uI8GlLGG38YF6svprInbWbmpIWJcxQoRIkA4HAQk/edit?edit_requested=true 1/3
3. Un bref résumé quotidien de l’information économique via un outil digital est-il

intéressant pour vous ? *
Oui
Non
4. Préfériez-vous une édition : *
Ecrite
Podcast
5. Quel thème de la presse économique vous intéresse le plus ? *
Bourse
Finance
Finance publique
Pas de préférence
Autre :
6. Quelle est votre tranche d’âge ? *
Moins de 30 ans
Moins de 50 ans
Moins de 60 ans
7. Quelle est votre activité professionnelle ?
Nous vous remercions du temps que vous avez dédié à la réponse à ce

questionnaire.
Ce contenu n'est ni rédigé, ni cautionné par Google.
Forms

Mini Projet 4 1

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Mini Projet 4 1

Transféré par

Droits d'auteur :

Formats disponibles

M

Licence Appliquée en Gestion des technologies de l’Information et

Titre : Analyse et conception d’une

Réalisé par : Ahmed Kamoun

Encadré par : Mme. Ines Mezghani

Entreprise d’Accueil : Saibi Intermediation

Année Universitaire : 2021-2022

L’objectif de ce travail est l’analyse et la conception d’une application mobile digitale

Keywords: Mobile application, analysis, design, economic newspaper, brief, podcast.

Je tiens à remercier tout particulièrement mon encadrante Mme. MEZGHANI

Nous tenons à remercier également notre encadrant de l’entreprise M. SAIBI

Nous souhaitons aussi remercier l’équipe pédagogique et administrative de l’ISET’COM

Nous tenons à remercier Mme. BEN SALEM Yosra pour sa disponibilité et

Liste des figures viii

Liste des tableaux x

1 Contexte général du projet 3

1.1 Présentation de l’organisme d’accueil . . . . . . . . . . . . . . . . . . 3

1.2 Présentation de l’incubateur du projet . . . . . . . . . . . . . . . . . 4

1.3 Présentation du projet à réaliser . . . . . . . . . . . . . . . . . . . . . 4

1.3.1 Problématique du projet . . . . . . . . . . . . . . . . . . . . . 4

1.3.2 Etude de l’existant . . . . . . . . . . . . . . . . . . . . . . . . 5

1.3.3 Critique de l’existant . . . . . . . . . . . . . . . . . . . . . . . 7

1.3.5 Chronogramme du projet . . . . . . . . . . . . . . . . . . . . . 9

1.3.6 Objectifs du projet . . . . . . . . . . . . . . . . . . . . . . . . 10

1.4 Choix de la méthode de travail . . . . . . . . . . . . . . . . . . . . . 11

1.4.1 Méthodologie agile . . . . . . . . . . . . . . . . . . . . . . . . 12

1.4.2 Étude comparative de méthodes SCRUM et de méthodologie

1.4.3 Méthode de travail adoptée : SCRUM . . . . . . . . . . . . . 14

1.4.4 Principe de Scrum . . . . . . . . . . . . . . . . . . . . . . . . 14

1.4.5 Rôles de la méthode Scrum . . . . . . . . . . . . . . . . . . . 15

2.1 Analyse de l’environnement interne et externe . . . . . . . . . . . . . 16

2.1.2 Les environnements adjacents (PESTEL) . . . . . . . . . . . . 17

2.1.3 Analyse swot . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2.2 Élaboration de la stratégie marketing . . . . . . . . . . . . . . . . . . 20

2.2.1 Choix des critères de segmentation . . . . . . . . . . . . . . . 20

2.2.4 Business Model Canvas . . . . . . . . . . . . . . . . . . . . . . 23

3.1 Étude préliminaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3.1.1 Identification des exigences fonctionnelles . . . . . . . . . . . . 26

3.1.2 Identification des exigences non fonctionnelles . . . . . . . . . 27

3.2 Spécifications techniques . . . . . . . . . . . . . . . . . . . . . . . . . 28

3.2.1 L’architecture logicielle . . . . . . . . . . . . . . . . . . . . . . 28

3.2.2 Outils de design . . . . . . . . . . . . . . . . . . . . . . . . . . 29

3.2.3 Outil de maquettege . . . . . . . . . . . . . . . . . . . . . . . 29

3.2.4 Environnement de conception . . . . . . . . . . . . . . . . . . 29

3.2.5 Outil de plannification . . . . . . . . . . . . . . . . . . . . . . 29

3.3 Spécifications générales des exigences . . . . . . . . . . . . . . . . . . 30

3.3.1 Détermination du cas d’utilisation global . . . . . . . . . . . . 30

3.3.2 Détermination du diagramme de classes de conception global

3.4 Backlog du produit . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

3.4.2 Tableau de backlog du produit . . . . . . . . . . . . . . . . . . 32

3.4.3 Définition des rôles dans SCRUM . . . . . . . . . . . . . . . . 34

3.4.4 Planification des sprints . . . . . . . . . . . . . . . . . . . . . 35

4.1.1 Diagramme de cas d’utilisation "s’inscrire" . . . . . . . . . . . 38

4.1.2 Tableau descriptif des scénarios du cas d’utilisation "s’inscrire" 38

4.1.3 Diagramme de séquence de cas d’utilisation "s’inscrire" . . . . 40

4.2.1 Diagramme de cas d’utilisation "s’authentifier" . . . . . . . . 41

4.2.2 Tableau descriptif des scénarios du cas d’utilisation ”s’authen-

4.2.3 Diagramme de séquence "S’authentifier" . . . . . . . . . . . . 43

4.3 Gérer son profil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

4.3.1 Diagramme de cas d’utilisation "Gérer son profil" . . . . . . . 44

4.3.2 Tableau descriptif des scénarios du cas d’utilisation"Gérer son

4.3.3 Diagramme de séquence de "Gérer son profil" . . . . . . . . . . 45

4.4 Réalisation du sprint (1) . . . . . . . . . . . . . . . . . . . . . . . . . 45