AHMED HAMMAMI 3LATI Gestion de La Gouvernance Du Tenant Office

Ministère de l’Enseignement Supérieur, de la Recherche
Scientifique et des Technologies de l’Information et de la Communication

Université de Carthage Institut des Hautes Études
Commerciales de Carthage
Rapport de Projet de Fin d’Etudes présenté en vue de l’obtention du Diplôme de

Licence en Technologies de L’Information
Intitulé du Projet :
Conception et réalisation d’une application
Gestion de la gouvernance du tenant office
« Taux d’adoption & Boîtes à Risque »
Réalisé Par : AHMED HAMMAMI
Organisme d’accueil :
PROGED INTERNATIONALE
Encadrant Académique : Encadrant Professionnel :

Mr. SLIM MESFAR (IHEC) Mr. AHMED MEHDI (PROGED)
Année Universitaire 2020-2021

Dédicaces
Je dédie ce travail :
À mes très chers parents, pour leur amour, leurs sacrifices leur soutien et leur dévouement. Il n’y a
pas de mots qui puissent exprimer toute ma joie, ma gratitude et ma reconnaissance pour tout ce qu’ils
ont fait pour moi. Que Dieu leur accorde santé, bonheur et longue vie.
À ma chère sœur Kmar, merci de votre tendresse et de votre affection. Je te souhaite tout le bonheur
et la réussite.
À tous les membres de ma famille, pour toute leur tendresse, leur considération et leur soutien
permanent et à qui je dois énormément des choses merveilleuses.
À mes chers amis pour l’amitié qui nous a unies et pour tous les merveilleux moments et les souvenirs
partagés.
À toute l’équipe PROGED, qui m’ont encouragé et soutenu durant la période de ce stage.
À tous ceux que j’aime et à tous ceux qui m’aiment.
Remerciements
En préambule à ce rapport, je souhaite adresser ici tous mes remerciements aux personnes qui m’ont
apporté leur aide et qui ont ainsi contribué à l'élaboration de ce travail.
Nous tenons à remercier, toute l'équipe pédagogique de l'IHEC et les intervenants professionnels
responsables de la formation sur les nouvelles technologies, pour avoir contribué à ma formation.
Je tiens à exprimer également ma profonde reconnaissance à Mr Slim MESFAR qui m’a encadré
durant ce projet. Son aide et ses conseils, qu’il m’a apporté lors des différents suivis, ont
continuellement amélioré mon travail.
Je tiens à remercier tout particulièrement et à témoigner toute ma reconnaissance à Mr Ahmed

MAHDI, mon encadreur à PROGED pour sa disponibilité, ses conseils et l’aide qu’il m’a accordé
dans l’élaboration de ce projet. Je suis très reconnaissant à monsieur Anis BEN MAKHLOUF et à
toute l’équipe de PROGED pour leur aide, leur encouragement et leur conseil qu'ils m’ont accordé
durant la période du stage.
J’exprime ma sincère gratitude aux membres du jury, qui ont accepté d'évaluer ce projet de fin
d'étude.
Table de Matières
Table des Figures ............................................................................................................................................... i

Liste des Tableaux ............................................................................................................................................ii
Introduction générale ....................................................................................................................................... 1
Chapitre 1 : Contexte général du projet......................................................................................................... 4

1. Introduction .......................................................................................................................................... 4
2. Organisme d’accueil ............................................................................................................................. 4
3. Définition de la mission ........................................................................................................................ 5
3.1.Présentation du projet ....................................................................................................................... 5
3.2.Objectifs à atteindre.......................................................................................................................... 5
4. Etude de l’existant ................................................................................................................................ 5
4.1.Analyse de l’existant ........................................................................................................................ 5
4.2.Critique de l’existant ........................................................................................................................ 8
4.3.Solution proposée ............................................................................................................................. 9
5. Conclusion ............................................................................................................................................. 9
Chapitre 2 : Analyse et spécifications des besoins ....................................................................................... 11

1. Introduction ........................................................................................................................................ 11
2. Cadre méthodologique de développement ....................................................................................... 11
3. Modélisation conceptuelle .................................................................................................................. 13
3.1. Choix de la méthode de conception............................................................................................... 13
3.2. Choix du langage de modélisation ................................................................................................ 13
4. Spécification des exigences ................................................................................................................ 14
4.1.Identification des acteurs ................................................................................................................ 14
4.2.Exigences fonctionnelles ................................................................................................................ 14
4.3.Exigences non fonctionnelles ......................................................................................................... 16
4.4.Vue architecturale des cas d’utilisations ........................................................................................ 18
4.5.Vue architecturale de diagramme de classes .................................................................................. 19
5. Le pilotage du projet par SCRUM.................................................................................................... 20
5.1.Découpage du projet ....................................................................................................................... 20
5.2.Backlog du produit ......................................................................................................................... 21
5.3.Planification des Sprints ................................................................................................................. 22
5.4.Planification du projet .................................................................................................................... 23
6. Conclusion ........................................................................................................................................... 23
Chapitre 3 : Étude technique de la solution ................................................................................................. 25
1. Introduction ........................................................................................................................................ 25
2. Spécification architecturale ............................................................................................................... 25
3. Spécification technologique ............................................................................................................... 27
3.1. Environnement matériel ................................................................................................................ 27
3.2. Environnement logiciel ................................................................................................................. 27
3.3. Technologies et langages de programmation utilisées .................................................................. 29
4. Conclusion ........................................................................................................................................... 31
Chapitre 4 : SPRINT 1 – Gestion de Taux d’adoption d’Outlook Online ................................................ 33

1. Introduction ........................................................................................................................................ 33
2. Objectif attendu et identification des tâches .................................................................................... 33
2.1. Objectif attendu ............................................................................................................................. 33
2.2. Sprint Backlog ............................................................................................................................... 33
3. Analyse détaillée des besoins ..................................................................................................................... 35
3.1. Diagramme de cas d’utilisation ..................................................................................................... 35
3.2. Description textuelle des cas d’utilisation ..................................................................................... 36
4. Wireframes des interfaces ......................................................................................................................... 37
5. Modélisation conceptuelle.......................................................................................................................... 38
5.1.Diagrammes de séquence du cas d’utilisation ................................................................................ 38
5.2.Diagramme de classes .................................................................................................................... 40
6. Réalisation ................................................................................................................................................... 42
6.1. Captures d’écran ............................................................................................................................ 42
6.2. Tests et validation.......................................................................................................................... 45
7. Conformité aux exigences non fonctionnelles .......................................................................................... 45
8. Conclusion ................................................................................................................................................... 46
Chapitre 5 : SPRINT 2 – Gestion de Taux d’adoption aux services (Teams & SharePoint) .................. 48
1. Introduction ........................................................................................................................................ 48
2.1. Objectif attendu ............................................................................................................................. 48
2.2. Sprint Backlog ............................................................................................................................... 48
3. Analyse détaillée des besoins ............................................................................................................. 50
4. Wireframes des interfaces ................................................................................................................. 52
5.1. Diagrammes de séquence .............................................................................................................. 53
5.2. Diagramme de classes ................................................................................................................... 55
6. Réalisation ........................................................................................................................................... 57
6.1. Captures d’écran ............................................................................................................................ 57
8. Conclusion ................................................................................................................................................... 58
Chapitre 6 : SPRINT 3 – Gestion des Boîtes à Risque (Messagerie Outlook) .......................................... 60

1. Introduction ........................................................................................................................................ 60
2.1.Objectif attendu .............................................................................................................................. 60
2.2.Sprint Backlog ................................................................................................................................ 60
3. Analyse détaillée des besoins ............................................................................................................. 61
4. Wireframes des interfaces ................................................................................................................. 62
5.1. Diagrammes de séquence .............................................................................................................. 63
5.2. Diagramme de classes ................................................................................................................... 64
6. Réalisation ........................................................................................................................................... 65
6.1. Captures d’écran ............................................................................................................................ 65
8. Conclusion ................................................................................................................................................... 67
Conclusion générale et perspectives ............................................................................................................. 68
Bibliographie et Webographie ...................................................................................................................... 69

Table des Figures
Figure 1: Logo de PROGED Business Solutions........................................................................................... 4
Figure 2: Logo du projet ............................................................................................................................. 5
Figure 3: Gouvernance de la Collaboration sous Microsoft 365 ................................................................ 6
Figure 4: Site Avepoint ............................................................................................................................... 7
Figure 5: Surveillez et créez des rapports sur les activités des utilisateurs ............................................... 7
Figure 6: Site Gover365 .............................................................................................................................. 8
Figure 7: Cycle de vie de la méthode SCRUM .......................................................................................... 12
Figure 8: Vue architecturale des cas d’utilisations................................................................................... 18
Figure 9: Diagramme de classe général ................................................................................................... 19
Figure 10: Découpage du projet............................................................................................................... 20
Figure 11: Microsoft Project - Planification du projet.............................................................................. 23
Figure 12: Architecture de la solution GMA365....................................................................................... 25
Figure 13: Office 365 Ecosystème ............................................................................................................ 26
Figure 14: Diagramme de cas d’utilisation sprint 1.................................................................................. 35
Figure 15: Wireframes des interfaces sprint 1 - Dashboard .................................................................... 37
Figure 16: Wireframes des interfaces sprint 1- Indicateurs Outlook ....................................................... 37
Figure 17: Diagramme de séquences journalisation Outlook Nombre email Envoyé/Reçu .................... 39
Figure 18: Diagramme de séquences Synchronisation des utilisateurs offices ....................................... 39
Figure 19: Diagramme de séquences affichage Nombre email Envoyé/Reçu ......................................... 40
Figure 20: Diagramme de classes du sprint 1 .......................................................................................... 41
Figure 21: Connexion Microsoft 365 ........................................................................................................ 42
Figure 222 : Création de l’application Azure AD GMA365 ....................................................................... 43
Figure 233 : Liste des applications Microsoft 365 .................................................................................... 43
Figure 244: Captures d’écran- Dashboard Front GMA365....................................................................... 44
Figure 255 : Captures d’écran-Front GMA365 « Nombre d’e-mail Envoyé/Reçu » ................................. 44
Figure 27: Wireframes des interfaces sprint 2- Indicateur Teams ........................................................... 52
Figure 28: Wireframes des interfaces sprint 2- Indicateur SharePoint.................................................... 52
Figure 29 : Diagramme de séquences journalisation Nombre de connexion au service SharePoint ...... 53
Figure 30: Diagramme de séquences journalisation - Nombre de connexion au service Teams ............ 54
Figure 31: Diagramme de séquences Affichage - Nombre de connexion au service SharePoint ............ 54
Figure 32: Diagramme de séquences Affichage - Nombre de connexion au service Teams ................... 55
Figure 34: Captures d’écran- Sprint 2 – Front Teams .............................................................................. 57
Figure 35: Captures d’écran- Sprint 2 – Front SharePoint ....................................................................... 57
Figure 37: Wireframes des interfaces sprint 3 – Botes à risques............................................................. 62
Figure 38: Diagramme de séquences journalisation et notification dépassements de quota ................ 63
Figure 39: Diagramme de séquences Affichage détail dépassement quota ............................................ 64
Figure 41: Captures d’écran- Sprint 3 – Boites à Risque .......................................................................... 65
Figure 42: Captures d’écran- Sprint 3 – Email envoyé ............................................................................. 66
I
Liste des Tableaux
Tableau 1: Tableau de Backlog initial...............................................................................................................22
Tableau 2: Planification prévisionnelle des Sprints .........................................................................................22
Tableau 3: Tableau de Backlog Sprint 1 ...........................................................................................................34
Tableau 4: Description textuelle du cas d’utilisation « Synchronisation des utilisateurs office »...................36
Tableau 5: Description textuelle du cas d’utilisation « MAJ de l’interface de journalisation des données » .36
Tableau 6: Description textuelle du cas d’utilisation - Affichage Nombre email Envoyés/Reçus ...................36
Tableau 7: Dictionnaire de données Sprint 1 ...................................................................................................41
Tableau 8: Tableau de Backlog Sprint 2 ...........................................................................................................49
Tableau 9: Description textuelle du cas d’utilisation – MAJ de la journalisation des données SharePoint ....50
Tableau 10: Description textuelle du cas d’utilisation – MAJ de la journalisation des données Teams .........51
Tableau 11: Description textuelle du cas d’utilisation - Affichage Nbre de connexion SharePoint ................51
Tableau 12: Description textuelle du cas d’utilisation - Affichage Nbre de connexion Teams .......................51
Tableau 13: Dictionnaire de données Sprint 2 .................................................................................................56
Tableau 14: Tableau de Backlog Sprint 3 .........................................................................................................60
Tableau 15: Description textuelle du cas d’utilisation Journalisation/Notification dépassement de quota...61
Tableau 16: Description textuelle du cas d’utilisation « Affichage détail dépassement de quota » ..............62
Tableau 17: Dictionnaire de données Sprint 3 .................................................................................................64
II
Introduction générale
Parce que l’Agilité est aujourd’hui essentielle dans un monde de forte transformation, les entreprises
doivent identifier très vite et en temps réel les points d’amélioration dans l’utilisation de leur système
d’information. Cela permettra de bien gouverner les solutions implémentées et de gérer efficacement
l’augmentation du volume et la complexité des données e-mails, documents, messages instantanés et
autres.
Cette évolution nous mène à étudier en particulier :

- Comment mettre en place une gouvernance au service de la productivité et de la collaboration
au sein de l'organisation ?
- Pourquoi avons-nous besoin de contrôler, automatiser et gouverner les espaces de
collaboration au sein de Microsoft 365 ?
Microsoft 365 [1] combine un ensemble de services puissants conçus pour la gestion et la maintenance
des entreprises à tous les niveaux. En fait, Microsoft 365 offre une nouvelle façon de communication
en équipe grâce à Outlook, SharePoint et Teams qui alimentent toutes les capacités de l’entreprise.
Mais, ces services peuvent être limités, et par conséquent, ont besoin des fonctionnalités et d’options
afin de mieux contrôler et mesurer l’état du business, ainsi augmenter la productivité de l’équipe.
L’objectif principal de notre projet est de concevoir puis développer une application « Gestion de la
gouvernance du tenant office 365 » qui permet :
- d’avoir des fonctionnalités d’analyse basées sur les indicateurs afin de faciliter l’adoption
des outils collaboratifs.
- de surveiller et alerter d’une manière intelligente en cas d’une pique et interpréter le temps
restant pour qu'une boite soit saturée.
Cette gouvernance s’occupe de l’utilisation efficace de l’informatique et ses ressources pour
améliorer l’efficacité et la productivité de l’organisation.
Dans ce contexte et dans le cadre de notre projet de fin d’études, nous visons la mise en place d’une
application qu’on dénotera " GMA365" (Governance Management Application) et qui permettra la
gouvernance du tenant office 365 pour gérer le Taux d’Adoption et les Boites à Risque.
Page 1
Le présent rapport permet de détailler les différentes étapes suivies lors du développement de notre
projet. Il se compose de six chapitres.
Dans le premier chapitre, nous commençons par présenter le cadre général du projet, la mission qui
nous a été confiée
Le deuxième chapitre est consacré pour préciser les besoins fonctionnels et non fonctionnels, ainsi
que le cycle de développement adopté pour la mise en œuvre de notre projet
Le troisième chapitre est consacré à la description de l’étude technique de la solution tout en
déterminant les technologies et outils utilisés.
Les chapitres quatre, cinq et six, présentent respectivement les Sprint développés selon la méthode
SCRUM. Dans chaque Sprint, nous décrivons les objectifs, l'analyse des exigences, les modèles
conceptuels ainsi que l'implémentation, les tests et la vérification de l’intégration.
Page 2
C HAPITRE 1 :
CONTEXTE GENERAL
DU PROJET
Page 3
Chapitre 1 : Contexte général du projet
1. Introduction
Dans le premier chapitre, nous nous intéresserons d'abord à l'introduction du cadre global du projet
et à la description des exigences. Il s'agit en fait d'une introduction à l'organisation d'accueil, suivie
de la définition de la tâche, de la présentation du projet et des objectifs à atteindre. Ensuite, nous
étudions et discutons quelques applications similaires existantes, puis nous présentons la solution
proposée.
2. Organisme d’accueil
PROGED International [4] (Figure 1), créée en 2010, est une société de services et d’ingénierie
informatique, qui offre une large gamme de solutions innovantes. Cette gamme a permis de répondre
aux besoins de tout type d’entreprise en matière de portails d’entreprise, de gestion électronique de
documents et d’outils d’aide à la décision d'entreprises sur la plateforme Microsoft SharePoint et
Office 365.
PROJED International comprend environ une dizaine d’ingénieurs et administratifs. Les marchés les
plus envisagés par PROGED International sont le marché national ainsi que le marché français.
Figure 1: Logo de PROGED Business Solutions
PROGED offre un éventail complet de services, de solution et d’expertise pour accélérer la

transformation des activités de ces clients. Les services de PROGED sont présentés comme suit :
- Transformation digitale,
- Mise en place d’intranet (extranet),
- Les réseaux sociaux d'entreprise,
- Les portails de GED et numérisation,
- L’automatisation des processus (Workflows),
- Support Office 365 et Formations.
Page 4
3. Définition de la mission
3.1. Présentation du projet
La mise en œuvre d’office 365 est un projet qui a des impacts non négligeables sur les modes de
fonctionnement de l’organisation et les comportements des utilisateurs. C’est pourquoi nous
allons examiner la problématique de la gouvernance à mettre en place pour le fonctionnement en
mode courant une fois qu’office 365 aura été déployé et adopté. La solution informatique intitulé
GMA365 comme il est indiqué dans la Figure 2, permet de gouverner les tenant office et de
mieux cibler et attirer les clients potentiels.
Figure 2: Logo du projet
3.2. Objectifs à atteindre
Comme le sujet l’indique, notre objectif est de concevoir et de mettre en place un système
« Gestion de la gouvernance du tenant office 365 » qui permet de contrôler l’autonomie à des
entités dans la gestion de la sécurité et d’avoir des fonctionnalités d’analyse basées sur les
indicateurs afin de faciliter l’adoption des outils collaboratifs.
L’application « GMA365 » vise à :
- Créer une interface Dashboard pour visualiser l’état du tenant Microsoft 365
- Visualiser les indicateurs du taux d’adoption :
o Nombre d’e-mail Envoyé/Reçu
o Nombre de connexion aux services (SharePoint & Teams)
- Notifier en cas de dépassement de quota
4. Etude de l’existant
4.1. Analyse de l’existant
Afin d'approfondir notre compréhension du sujet et avoir une idée plus claire sur notre projet et
ses fonctions attendues, nous avons mené une étude sur des solutions qui s'inscrivent dans le même
cadre que notre projet. Pour cela nous allons étudier, d’une part, la gouvernance des tenants office
Page 5
sous MS 365 et, d’autre part, les solutions de gouvernance sur le marché comme Avepoint et
Govern365.
4.1.1. Prérequis :
Toute solutions consacrées pour la gestion de gouvernance du tenant Microsoft 365 offrent
un ensemble de fonctions assurant la bonne gestion et le monitoring du tenant.
Nous commençons par présenter les définitions des concepts :
- Tenant Microsoft : un « Tenant » représente la bulle indépendante correspondant à une
société hébergée dans Office 365. Dans ce tenant, seuls les utilisateurs et les informations de
l’entreprise y sont stockés et ne sont visibles que de l’entreprise en question.
- La gouvernance informatique : consiste à définir des processus définis pour une utilisation
informatique efficace et protégée. C’est une tâche essentielle pour les entreprises.
4.1.2. Gouvernance sous Microsoft 365
Microsoft propose des solutions pour la gestion de la gouvernance, tels que : Gouvernance de
la collaboration, Gouvernance des informations de Microsoft (MIG) et Microsoft Information
Protection (MIP)
- Gouvernance de la collaboration [11] : La gouvernance de la collaboration consiste à gérer
l’accès des utilisateurs aux ressources, à respecter les normes de votre entreprise et à garantir
la sécurité de vos données.
Figure 3: Gouvernance de la Collaboration sous Microsoft 365
- Gouvernance des informations de Microsoft (MIG) [12] : il s’agit d’utiliser les fonctionnalités
de gouvernance des informations de Microsoft (parfois abrégé en MIG) pour gérer les données
en matière de conformité ou d’obligations réglementaires.
- Microsoft Information Protection (MIP) [13] : Les fonctionnalités MIP sont incluses dans la
Conformité Microsoft 365 et donnent les outils nécessaires pour permettre de connaître les
données, protéger ces données et éviter leur perte.
Page 6
4.1.3. Solutions sur le marché
Nous citons quelques exemples de plateformes proposées sur le marché :
a) Avepoint [14] :
AvePoint Cloud Governance met à la disposition des utilisateurs des ressources informatiques
en libre-service (SaaS) pour migrer, gérer et protéger les données dans Microsoft 365.
Figure 4: Site Avepoint
Figure 5: Surveillez et créez des rapports sur les activités des utilisateurs
Cette plateforme permet de Contrôler toutes les actions de gestion de DocAve pour surveiller
la conformité des administrateurs aux politiques.
Page 7
b) Govern365 [15] :
Govern 365 est une application qui permet aux utilisateurs finaux de provisionner
intuitivement toutes les charges de travail proposées par Office 365 tout en maintenant le
bon équilibre entre le contrôle administratif et l’autonomisation des utilisateurs dans
Office 365.
Figure 6: Site Gover365
4.2. Critique de l’existant

La critique des applications similaires à notre projet est une étape utile et importante. Elle vise à
porter des jugements objectifs afin de découvrir toute lacune ou limitation rencontrées lors de
l'étude des systèmes existants, et projeter de fournir ainsi un système plus fiable que les systèmes
existants sur le marché.
Après analyse des solutions cités, nous avons constaté quelques limites parmi lesquelles nous
citons :
• Complexité d’installation et de configuration de l’application (client lourd),

• Absence de la gestion globale des quotas,
• Identifier les utilisateurs inactifs, les licences ou les mots de passe arrivant à expiration avec
des rapports sur Azure Active Directory pour prendre des mesures préventives,
• Exigence de connaissance approfondi d’administration de MS 365.
Page 8
• Des coûts de licences des applications de gestion de tenant MS 365 très élevées comme suit :
➢ AvePoint: pay as you go,
➢ Govern365 : à partir de 1000$ / mois.
4.3. Solution proposée

En tenant compte des limites des systèmes existants et des objectifs fixés, nous proposons de
concevoir et de développer une solution facilement accessible et fiable tout en respectant les
bonnes pratiques du développement sécurisé sur Microsoft Azure [10] telles que la simplicité de
navigation entre les pages, la bonne ergonomie et la sécurité des données confidentielles de
l’organisation.
La solution proposée est une application qui a les objectifs suivants :
- Mettre à disposition des responsables métier des indicateurs de taux d’adoption d’utilisation
office par leurs collaborateurs,
- Alerter en cas de dépassement de quota des boites à risque tel que Outlook Online,
- Garantir une haute disponibilité et une bonne performance,
- Optimisation des coûts.
5. Conclusion
Dans ce premier chapitre, nous avons parlé de notre organisme d’accueil puis nous avons décrit une
brève présentation du projet à réaliser. Ainsi, après avoir déterminé la problématique, nous avons
proposé notre solution alternative pour faire face à l’existant.
Dans ce qui suit, nous allons entamer le deuxième chapitre qui fera l’objet de l’analyse et la
spécification des besoins du projet ainsi que la présentation du Backlog produit et la planification de
travail à réaliser.
Page 9
C HAPITRE 2 :
ANALYSE ET
SPECIFICATIONS DES
BESOINS
Page 10
Chapitre 2 : Analyse et spécifications des besoins
1. Introduction
Dans le deuxième chapitre, nous présentons la méthode de développement adoptée et le choix du

modèle conceptuel. Enfin, nous terminerons ce chapitre par la description de la spécification des
exigences et finaliserons le plan de version pour produire un backlog de produit initial et le premier
plan de sprint.
2. Cadre méthodologique de développement
Tout projet ayant un niveau de complexité considérable rend l’adoption d’une méthodologie de
développement une nécessité pour garantir une qualité acceptable et éviter tout retard au niveau des
délais.
La société PROGED suit dans sa gestion des projets la méthodologie Agile Scrum [5] pour diverses
raisons.
En effet ce modèle assure une meilleure collaboration et une meilleure communication avec les
différentes équipes travaillant sur les projets de la société. La méthodologie Agile Scrum se distingue
par le travail de groupe, ses réunions quotidiennes et le suivi continu des projets, ce qui revient par la
facilité de la gestion des changements fréquents. Ce modèle assure une livraison de produits de
qualité, et conformes aux besoins et aux attentes des clients.
Dans notre cas, le projet est réalisé en monôme. Donc, nous essayons d’adapter Scrum à nos besoins.
Ainsi, nous utiliserons l’ensemble des bonnes pratiques suivantes :
- l’extraction des fonctionnalités à développer après la réalisation du Backlog du produit,
- le découpage du projet en un ensemble de sprints,
- le découpage de chaque sprint en un ensemble de tâches,
- une réunion quotidienne avec l’encadrant pour le suivi de l’avancement,
- une réunion hebdomadaire chaque mercredi où nous essayons de répondre à ces trois
questions :
• Quelles sont les tâches effectuées ?
• Quelles sont les difficultés rencontrées ?
• Quelles sont les tâches futures à réaliser ?
Page 11
Lorsque nous disons Scrum, il faut comprendre les mots concepts suivants :
Un Scrum Master : Le responsable de la compréhension, de l'adhésion et de la mise en œuvre de la
méthode Scrum qu'il maîtrise parfaitement.
Product Owner : Il porte la vision du produit à réaliser. Il travaille en interaction avec l’équipe de
développement qui doit suivre ses instructions.
Une équipe De Développement : Elle est chargée de transformer les besoins définis par le Product
Owner en fonctionnalités utilisables.
Les artefacts du Scrum se résument ci-dessous :
Le product Backlog (ou carnet du produit) : Il s'agit d'une liste hiérarchisée des exigences initiales
du client concernant le produit à réaliser.
Le Sprint Backlog (ou carnet de Sprint) : C'est le plan détaillé de la réalisation de l'objectif du
Sprint, défini lors de la réunion de planification du Sprint.
L'incrément : Il s'agit de l'ensemble des éléments terminés du product backlog pour le Sprint en
cours, ainsi que ceux des Sprints précédents.
Le Burndown Chart (ou graphique d'avancement) : Ce graphique simple indique l'état
d'avancement dans la réalisation des tâches du Sprint backlog. Il s’agit du tracé de la charge de travail
restante (exprimée généralement en heures) en fonction du temps (en jours).
S’il parait un peu difficile de déterminer la méthodologie de Scrum, sa mise en œuvre est aussi
simple et efficace. Voici son illustration :
Figure 7: Cycle de vie de la méthode SCRUM
Page 12
3. Modélisation conceptuelle
Dans cette section, nous décrivons la méthode de conception et le langage de modélisation utilisés
dans le cadre de notre projet.
3.1. Choix de la méthode de conception

Dans notre projet, nous avons choisi la méthode de conception orientée objet. La modélisation
d'objets comprend la création de modèles informatiques qui représentent des éléments du monde réel
qui intéressent les gens sans se soucier de la mise en œuvre. Par conséquent, il est difficile de
déterminer l'existence d'objets et d'isoler leurs données et d'utiliser leurs fonctions.
3.2. Choix du langage de modélisation

Dans le but de modéliser la conception d’un système extensible, évolutif, modulaire et orienté
objet, le formalisme UML s’est imposé comme un outil performant de modélisation.
En effet, le langage de modélisation UML permet de mener la phase de conception tout en bénéficiant
de la puissance et de la simplicité de ses diagrammes.
L’UML (Unified Modelling Language) [6] est une notation qui permet de modéliser un problème de
façon standard. Ce langage est né de la fusion de plusieurs méthodes existantes auparavant, et il est
devenu une référence en termes de modélisation objet, à un tel point que sa connaissance devienne
indispensable pour un développeur.
UML définit neuf diagrammes pour donner à l’utilisateur les moyens de visualiser et de manipuler
des éléments de modélisation : diagrammes d’activités, diagrammes de cas d’utilisation, diagrammes
de classes, diagrammes de collaboration, diagrammes de composants, diagrammes de déploiement,
diagrammes d’états transitions, diagrammes d’objets et diagrammes de séquences. Le choix d’UML,
comme outil de modélisation des flux et des différentes actions de l’application, peut être justifié par
plusieurs raisons :
• UML facilite la compréhension et la communication d’une modélisation objet,

• La notation UML s'impose comme un standard de fait à l'heure actuelle sur le marché,
• Il est adopté par les grands constructeurs de logiciel du marché,
• L’utilisation d’UML offre l’avantage de disposer de vues de haut niveau d'abstraction,
• Pour favoriser la communication entre utilisateurs, spécialistes et informaticiens.
Page 13
4. Spécification des exigences

Dans cette partie, nous expliquons en détail ce que l'application est censée faire et ceci à travers la
spécification des besoins fonctionnels et non fonctionnels.
4.1. Identification des acteurs

Un acteur est la personne ou le matériel qui interagit avec notre système afin de réaliser une
valeur ajoutée. Notre solution fait intervenir 2 acteurs principaux :
Acteur Rôle
Cet acteur possède tous les droits d’accès qui lui permettent
Administrateur système d’administrer le système. Il est le responsable du bon fonctionnement
de Microsoft Office 365 et l’application GMA365, il gère les
utilisateurs, les services entités, les indicateurs et suivre toutes sorte
d’interactions comme la journalisation et la synchronisation des
données.
Responsable Entité Cet acteur dispose le droit d’accéder à l’application GMA365. Il
analyse et interprète les indicateurs du taux d’adoption et suit les
notifications par alerte.
4.2. Exigences fonctionnelles
La création d’une application passe par l'élaboration de deux parties, la première partie c'est la
configuration et la mise en place de l'espace d’administration (Back Office).
A traves l’espace d’administration, l’administrateur de la solution peut :
- Inscription des responsables entités
- Gestion des entités
- Gérer les journalisations des transactions.
- Gérer le paramétrage du quota.
La seconde partie concerne la création et la mise en place des pages accessibles par tous les
responsables entités (Front Office),
Les fonctionnalités accessibles par les responsables entités peuvent être :
- Créer un Dashboard qui décrit l’état du tenant
- Gérer les indicateurs du taux d’adoption :
o Nombre d’e-mail Envoyé/Reçu
o Nombre de connexion aux services (SharePoint & Teams)
- Notification par alerte en cas de dépassement de quota
Page 14
4.2.1. Gestion de taux d'adoption
Il s’agit de suivre le taux d’adoption des utilisateurs pour les services Microsoft 365. En standard,
l’accès à ces indicateurs nécessite le droit d'administration et un effort important pour collecter toutes
les informations nécessaires.
La solution consiste à permettre aux administrateurs métiers (Responsable de service par exemple)
de suivre les indicateurs de ses collaborateurs, agréger et simplifier la lecture de ces informations
avec des rapports et des graphiques.
Un « indicateur » est une information sélectionnée parmi les autres parce qu'elle parait
particulièrement significative ou représentative d'une situation donnée.
Les indicateurs sont des éléments d’information à construire à partir des données disponibles dans les
bases de données. L’essentiel est qu’il y ait possibilité de comparaison :
✓ avec la valeur du même indicateur ailleurs (si possible dans un site de caractéristiques
identiques)
✓ avec une valeur antérieure du même indicateur.
Dans notre projet nous allons gérer les Indicateurs de fonctionnement qui permettent de donner une
image de l’activité des utilisateurs sur les différents services d’Office 365 [2] .
Ce type d’indicateurs est lié à la disponibilité des données sous Office 365 qui nécessite la
journalisation des données pour pouvoir réaliser un comparatif entre les données historiques et J-1
par exemple.
Nous allons gérer les indicateurs de fonctionnement suivants :
• Contrôler le trafic des boîtes aux lettres et comprendre l’adoption d’Exchange Online
dans une organisation :
Résumé du trafic des boîtes aux lettres : Nombre d’e-mail Envoyés/Reçus
• Activité d’ouverture de session d’utilisateur
Nombre de connexions aux services (SharePoint & Teams) par période.
4.2.2. Gestion des Boîtes à risque
L’évolution des boîtes aux lettres en termes de stockage, pose un problème aux services
informatiques.
La solution consiste à surveiller et alerter d’une manière intelligente en cas d’un pique et interpréter
le temps restant pour qu'une boite soit saturée.
Page 15
Pour toutes les boîtes aux lettres de l’organisation, nous devons afficher instantanément des détails
sur la taille actuelle, les restrictions de taille et les statistiques de comparaison entre la taille et le quota
alloué.
Pour ce faire, nous allons contrôler le trafic des boîtes aux lettres et comprendre l’adoption
d’Exchange Online dans une organisation en suivant les trois étapes suivantes :
a) Identification de la Taille des boîtes aux lettres
Cette étape consiste à identifier la taille des boites aux lettres utilisateurs sur Microsoft 365 qui
indique le nombre d'éléments dans chaque boîte aux lettres, la taille de tous les éléments dans une
boîte aux lettres particulière, la taille totale de la table des messages et la taille disponible de cette
table.
b) Définition des restrictions de taille des boîtes aux lettres
Imposer des restrictions de taille aux boîtes aux lettres permet aux administrateurs de veiller plus
facilement à ce que les utilisateurs n'occupent pas trop d'espace de stockage sur le serveur.
Pour ce faire, nous allons définir pour tous les utilisateurs des quotas de boîte aux lettres pour
l'émission d'un avertissement sur les limites définies, l'interdiction d'envoi ou l'interdiction de
réception. Il affiche également des indicateurs comme la taille de l'archive, son quota affecté et
l'avertissement basé sur la consommation de quota.
c) Taille actuelle des boîtes aux lettres par rapport aux quotas
Cette étape permet de préparer toutes les boîtes aux lettres et indique leurs tailles actuelles par rapport
à leurs quotas alloués pour :
- En cas de dépassement, créer des alertes personnalisées pour une notification par e-mail en
temps réel.
- Génération d’un rapport global ou détaillé.
Les administrateurs peuvent ainsi garantir une gestion des boîtes aux lettres efficace et éviter que la
consommation ne dépasse le quota défini.
4.3. Exigences non fonctionnelles

Les besoins non fonctionnels sont importants car ils agissent de façon indirecte sur le résultat et sur
le rendement de l’utilisateur, ce qui fait qu’ils ne doivent pas être négligés, pour cela il faut répondre
aux exigences suivantes :
- Fiabilité :
L’application doit fonctionner de façon cohérente sans erreurs et doit être satisfaisante.
Page 16
- Les erreurs :
Les ambigüités doivent être signalées par des messages d’erreurs bien organisés pour bien
guider l’utilisateur et le familiariser avec notre solution.
- Ergonomie des interfaces :
L’application doit être adaptée à l’utilisateur sans qu’il ne fournisse aucun effort (utilisation
claire et facile) de point de vue navigation entre les différentes pages, couleurs et mise en
textes utilisés : standard Microsoft.
- Sécurité :
Notre solution doit respecter surtout la confidentialité des données personnelles.
- Aptitude à la maintenance et la réutilisation :
Le système doit être conforme à une architecture standard et claire permettant sa maintenance
et sa réutilisation.
- Compatibilité et portabilité :
Un site web quel que soit son domaine, son éditeur et son langage de programmation ne peut
être fiable qu’avec une compatibilité avec tous les navigateurs web et tous les moyens
matériels.
Page 17
4.4. Vue architecturale des cas d’utilisations
Figure 8: Vue architecturale des cas d’utilisations
Page 18
4.5. Vue architecturale de diagramme de classes
Figure 9: Diagramme de classe général
Page 19
5. Le pilotage du projet par SCRUM
5.1. Découpage du projet

La structuration d'un projet consiste à le diviser en différents lots d'activités afin d'avoir des sous-
parties dont la complexité est plus facilement maitrisable.
La Figure ci-dessous décrit la structuration de notre projet :
Projet de fin d'etudes
SPRINT 1
Taux d’adoption d’Outlook Online
SPRINT 2
Taux d’adoption aux services (Teams & SharePoint)
SPRINT 3
Boîtes à Risque (Messagerie Outlook)
Figure 10: Découpage du projet
Les 3 sprints décrivent l’interface d’intégration entre Microsoft 365 et la nouvelle application
PROGED-365 via des services Web pour interconnecter et Synchroniser ces deux
environnements afin de fournir une image précise et en temps réels des données utiles pour la
préparation des indicateurs et générer les alertes :
- SPRINT 1 / Taux d’adoption d’Outlook Online
Contrôler le trafic des boîtes aux lettres et comprendre l’adoption d'Outlook Online dans une
organisation → Indicateur : Nombre d’e-mail Envoyé/Reçu (trafic des boîtes aux lettres)
- SPRINT 2 / Gestion des Indicateurs Taux d’adoption :
Activité d’ouverture de session d’utilisateur → Indicateur : Nombre de connexion aux
services (Teams & SharePoint)
- SPRINT 3 / Gestion des Alertes Boîtes à Risque (Messagerie Outlook) :
Notification par alerte en cas de dépassement de quota
Page 20
5.2. Backlog du produit
Le Backlog du produit est un outil qui sert à collecter les fonctions essentielles et les raffine
progressivement. C’est l’ensemble des caractéristiques fonctionnelles « user story » ou techniques
« technical story » qui constituent le produit souhaité.
Une user story s’écrit comme suit :
En tant que <rôle>
Je veux < liste de tâches>
Afin de < valeur ajoutée ou résultat>
Pour chaque user story, nous identifions le rang, l’estimation, l'importance et la description. Le
Tableau suivant décrit le Backlog produit de notre application et évoque les User Stories :
Le Tableau ci-dessous résume le backlog produit de notre application web initiale :
ID Fonctionnalité ID User Stories Priorité

1.1 En tant qu’administrateur système, je veux m’authentifier Elevé
En tant qu’administrateur système, je veux gérer les Moyenne
1.2 administrateurs entités
1.3 En tant qu’administrateur système, je veux gérer les Elevé
services entités
1 1.4 En tant qu’administrateur système, je veux Synchroniser Elevé
Gestion De
Taux les utilisateurs office
d’Adoption 1.5 En tant qu’administrateur système, je veux suivre la Elevé
d’Outlook journalisation des données pour le calcul des des
Online indicateurs des taux d’adoption
1.6 En tant qu’administrateur système, je veux gérer les Moyenne
messages : erreur système, …
1.7 En tant que responsable entité, je veux m’authentifier
1.8 En tant que responsable entité, je veux analyser les Elevé
indicateurs du taux d’adoption « Nombre d’e-mail
Envoyé/Reçu »
2.1 En tant qu’administrateur système, je veux gérer les Elevé
services office
En tant qu’administrateur système, je veux suivre la Elevé
Gestion de Taux 2.2 journalisation des données pour le calcul des indicateurs
d’adoption aux des taux d’adoption « Nombre de connexion aux services
2 services (Teams « Teams & SharePoint »
& SharePoint)
2.3 En tant que responsable entité, je veux analyser les Elevé
indicateurs du taux d’adoption Nombre de connexion aux
services (SharePoint & Teams)
Page 21
ID Fonctionnalité ID User Stories Priorité

3.1 En tant qu’administrateur système, je veux gérer les
3 quotas des boites emails
Gestion des En tant qu’administrateur système, je veux suivre la Elevé
Boîtes à Risque 3.2 journalisation de dépassement de quota (Messagerie
(Messagerie Outlook)
Outlook) 3.3 En tant qu’administrateur système, je veux gérer les Moyenne
messages
3.4 En tant que responsable d’entité, je veux suivre les Elevé
notifications par alerte en cas de dépassement de quota
Tableau 1: Tableau de Backlog initial
5.3. Planification des Sprints
Une fois que le Backlog du produit est suffisamment complet, nous avons trié les « User Stories »
précédemment. Par la suite, nous avons établi, lors de la réunion de planification des sprints, les
durées prévisionnelles du travail à effectuer durant chaque sprint.
Alors pour se repérer, la planification de sprint dans le processus Scrum sert à planifier le travail à
réaliser au cours du sprint. Voilà l’objectif de cette réunion qui servira également à répondre à deux
questions importantes :
- Qu’est-ce qui peut être fait dans ce sprint ?
- Comment transformer les éléments du product Backlog que l’on a sélectionné en un incrément
terminé ?
Mois Février Mars Avril Mai Juin
Analyse de la situation & Auto formation
Etude préliminaire et familiarisation avec le projet
Conception et mise en place de l’environnement
Sprint 1 : Taux d’adoption d’Outlook Online
Sprint 2 : Taux d’adoption aux services
Sprint 3 : Boîtes à Risque (Messagerie Outlook)
Finition et enchaînement entre les sprints
Rédaction du rapport
Tableau 2: Planification prévisionnelle des Sprints
Page 22
5.4. Planification du projet
Nous avons utilisé Microsoft Project pour la planification de notre projet
Figure 11: Microsoft Project - Planification du projet
6. Conclusion
Tout au long de ce chapitre, nous avons préparé notre planification de travail pendant laquelle nous
avons construit notre Backlog de produit en se basant sur les besoins fonctionnels et non fonctionnels.
Finalement nous avons mentionné le découpage de notre solution en des sprints. Dans le chapitre
suivant, nous allons enchainer en présentant notre étude technique.
Page 23
C HAPITRE 3 :
ETUDE TECHNIQUE DE
LA SOLUTION
Page 24
Chapitre 3 : Étude technique de la solution
1. Introduction
Dans ce chapitre, nous abordons les spécifications architecturales de notre projet en présentant le style
architectural utilisé, l’architecture physique et l’architecture système optées.
Ensuite, nous décrivons les spécifications technologiques de notre projet. Nous présentons notre
choix de l’environnement de travail, où nous spécifions l’environnement matériel et logiciel qu’on a
utilisé pour réaliser notre application et enfin nous présentons les technologies et langages de
programmation utilisés.
2. Spécification architecturale
L’architecture est l’ensemble des aspects techniques et applicatifs qui sont importants pour un
logiciel. Les choix architecturaux influent sur la réussite ou l’échec d’un projet.
La Figure 12 montre l’architecture système de notre application. Dans la partie front, nous avons
travaillé avec React js alors que dans la partie back nous avons travaillé avec Microsoft Power
Automate. React communique avec les API avec des données de type JSON et enregistre les données
dans une base de données Microsoft SQL Server.
Figure 12: Architecture de la solution GMA365
GMA365 utilise l’outil de développement Power Automate et Graph API pour collecter des
informations à partir des tenants de Microsoft 365.
Page 25
Les informations collectées sont ensuite stockées dans la base de données configurée dans le
GMA365, pour traitement et analyse. Ces informations peuvent être récupérées sous forme de
rapports, à tout moment.
Web client : Application sous l’Url Office365
Server : Azure
Database : Azure SQL Server
Office 365 Ecosystème
Figure 13: Office 365 Ecosystème
• SharePoint : SharePoint est une série de logiciels pour application

Web et portails développée par Microsoft. Les fonctionnalités des produits SharePoint sont
la gestion de contenu, les moteurs de recherche, la gestion électronique de documents,
les forums, la possibilité de créer des formulaires et des statistiques décisionnelles.
• Teams : Microsoft Teams est une application de communication collaborative propriétaire
officiellement lancée par Microsoft en novembre 2016. Le service s'intègre à la suite
Microsoft Office 365 et Skype et propose des extensions pouvant être intégrées à des produits
autres que Microsoft.
• Outlook : Communiquez, organisez-vous et menez à bien vos tâches grâce à un service gratuit
de courrier et calendrier personnels.
Page 26
3. Spécification technologique
Dans cette partie, nous menons une étude technique où nous décrivons les ressources logicielles utilisées
dans le développement de notre projet. Nous présentons alors notre choix de l’environnement de travail,
dans lequel nous spécifions l’environnement matériel et logiciel et les Technologies et langages de
programmation que nous avons utilisés pour réaliser cette application.
3.1. Environnement matériel

Pour le développement de notre projet, nous avons utilisé un Ordinateur portable HP qui dispose
de la configuration suivante : Processeur Intel Core™ i5, RAM 8Go, Type de système x64
3.2. Environnement logiciel

Le choix de l'environnement logiciel constitue un grand défi pour le développement car il
influence directement les facteurs temps et coût. Pour cela, il représente une étape critique et
importante.
a) Système d’exploitation :
Microsoft Windows 10 : Le choix de la plateforme de développement
est important pour la réalisation d’un projet. Nous avons choisi Windows
10 Professionnel comme un système d’exploitation pour notre projet
b) Outils de conception :
Visual Paradigm : Le choix de la plateforme de développement est
important pour la réalisation d’un projet. Nous avons choisi Windows 10
Professionnel comme un système d’exploitation pour notre projet
c) Environnement de développement :
Lors de l’implémentation de notre application, nous avons recouru aux différents logiciels.
Dans la suite, nous allons détailler cet environnement.
Visual Studio Code [9] : est un éditeur de code source léger mais
puissant qui s’exécute sur le bureau de l’utilisateur et est disponible
pour Windows, macOS et Linux. Il est livré avec un support intégré
pour JavaScript, TypeScript et Node.js et dispose d’un écosystème
riche d’extensions pour d’autres langages (tels que C++, C#, Java,
Pyton, PHP, Go) et d’exécution (tels que .NET et Unity)
Page 27
Microsoft Azure [10] : est la plate-forme applicative en nuage de

Microsoft. Son nom évoque le « Cloud computing », ou informatique
en nuage (l’externalisation des ressources informatiques d’une
entreprise vers les datacenters distants)
Azure Active Directory (Azure AD) [16] : est le service de gestion de

l’accès et des identités basé sur le cloud de Microsoft. Il permet aux
employés de se connecter de d’accéder aux ressources externes telles
que Microsoft Office 365. Le portail Azure et des milliers d’autres
applications SaaS et aux ressources internes telles que les applications
situées sur votre réseau d’entreprise et intranet que les applications
cloud développées par votre propre organisation.
Azure App Service : est un service http pour l’hébergement

d’applications web, d’API REST et de backends mobiles. Ses
utilisateurs peuvent développer dans votre langage préféré, par
exemple .NET, .NET Core, Java, Ruby, Node.js, PHP ou Paython. Les
applications s’exécutent et sont mises à l’échelle facilement dans les
environnements Windows et Linux.
Microsoft 365 : est constitué de la suite office (Word, Excel,

PowerPoint, Outlook, OneNote, Publisher et Access), ainsi que d’un
ensemble de services en ligne tels que OneDrive, Exchange Online,
SharePoint, Teams. La suite office permet le travail en mode
déconnecté à l’instar d’une suite perpétuelle, ce qui la distingue
d’office Online, qui s’utilise depuis un navigateur web. Le principe de
Microsoft 365 est d’être mis à jour au fur et à mesure des nouvelles
versions d’office.
Postman : est un environnement de développement d’API qui aide les

utilisateurs à créer, tester documenter, surveiller et publier la
Documentation de leurs API
Page 28
Node.js : est une plateforme logicielle libre en JavaScript orientée vers

les applications réseau événementielles hautement concurrentes qui
doivent pouvoir monter en charge. Parmi les modules natifs de Node.js,
on retrouve http qui permet le développement de serveur http.
Azure DevOps : est une forge logicielle éditée par Microsoft

permettant la gestion des ressources, la gestion des builds, le suivi des
éléments de travail, la planification de projet et l’analyse des
performances. Il a pour but d’augmenter la productivité des
développeurs, lesquels doivent utiliser la suite Visual Studio Team
System
Azure SQL Database [18] : Partie intégrante de la famille SQL Azure,

Azure SQL Database est le service de base de données relationnelle
intelligent et évolutif conçu pour le cloud. En permanence à jour, il
propose des fonctionnalités automatisées d'intelligence artificielle qui
vous suggéreront des optimisations de performances.
Microsoft Project Professional : est un logiciel de gestion de projet

édité par Microsoft. Il permet aux chefs de projet et aux planificateurs
de planifier et piloter les projets, de gérer les ressources et le budget,
ainsi que d’analyser et communiquer les données des projets
3.3. Technologies et langages de programmation utilisées

a) Bibliothèques utilisées
React js [3] : est une bibliothèque JavaScript utilisée pour créer des
composants d'interface utilisateur réutilisables et de faciliter la création
d'application web monopage, via la création de composants dépendant
d'un état et générant une page HTML à chaque changement d'état.
Bootstrap [7] : Bootstrap est une collection d'outils utiles à la création

du design de sites et d'applications web. C'est un ensemble qui contient
des codes HTML et CSS, des formulaires, boutons, outils de navigation
et autres éléments interactifs, ainsi que des extensions JavaScript en
option.
Page 29
b) Langage de programmation
Power Automate [17] : Power Automate est un service qui vous aide à
créer des workflows automatisés entre vos applications et services
favoris pour synchroniser des fichiers, obtenir des notifications,
collecter des données, etc.
Voici quelques exemples de ce que vous pouvez faire avec Power
Automate.
• Automatiser les processus d’entreprise
• envoyer des rappels automatiques sur les tâches en retard ;
• déplacer des données métier entre des systèmes selon un
calendrier ;
• connecter à près de 300 sources de données ou à toute API
accessible au public ;
.Net Core 5.0 : est un Framework open source multiplateforme, hautes

performances pour la création d’applications modernes, compatibles
avec le cloud et connectées à Internet. ASP.NET Core permet de créer
des applications et des services Web, des applications Internet des
objets (IoT) et des backends mobiles.
JavaScript [8] : JavaScript est un langage de programmation de scripts

principalement employé dans les pages web interactives et à ce titre est
une partie essentielle des applications web.
HTML : L'HyperText Markup Language, HTML, désigne un type de

langage informatique descriptif. Il s'agit plus précisément d'un format
de données utilisé dans l'univers d'Internet pour la mise en forme des
pages Web. Il permet, entre autres, d'écrire de l'hypertexte, mais aussi
d'introduire des ressources multimédias dans un contenu.
JSON : JavaScript Object Notation (JSON) est un format de données

textuelles dérivé de la notation des objets du langage JavaScript. Il
permet de représenter de l’information structurée comme le permet
XML par exemple.
Page 30
c) Les APIs REST utilisées :
Microsoft Graph API : Microsoft Graph permet de se connecter à de

nombreuses ressources liées à Office 365 (utilisateurs, discussions,
calendriers, groupes, …). La dénomination « Graph » vient du fait que
toutes ces ressources sont interconnectées, formant un réseau d’objets.
Par exemple, pour un utilisateur donné, Graph permet d’accéder à ses
messages, son calendrier, ses fichiers, mais également aux groupes
auxquels il appartient. Cet utilisateur est également associé à un
manager, à un ou plusieurs appareils (PC, téléphone, etc..), et d’autres
choses encore… Ces interconnexions permettent d’imaginer beaucoup
de scénarii d’utilisation.
4. Conclusion
Tout au long de ce chapitre nous avons présenté l’environnement de développement matériel et
logiciel ainsi que l’architecture que nous avons utilisé tout au long de notre projet. Dans le chapitre
suivant, nous détaillerons le SPRINT 1.
Page 31
C HAPITRE 4 :
SPRINT 1 :
GESTION DE TAUX
D’ADOPTION
D’OUTLOOK ONLINE
Page 32
Chapitre 4 : SPRINT 1 – Gestion de Taux d’adoption
d’Outlook Online
1. Introduction
Puisque Scrum est choisi comme méthode de gestion de projets, ce chapitre qui fait l’objet d’une
présentation du premier sprint, va être réparti selon les exigences de Scrum. En effet pour chaque Sprint,
il s’agit, dans un premier temps, de définir l’objectif attendu et élaborer le Sprint Backlog, ensuite il va
falloir présenter la conception et la réalisation.
2. Objectif attendu et identification des tâches

Un sprint est une itération de développement de la méthode Scrum. Il dure généralement entre
deux et quatre semaines. Tous les Sprints ont une durée constante et ne se chevauchent jamais, c’est-
à-dire qu’un Sprint ne peut pas démarrer tant que le précédent n’est pas encore terminé.
Les fonctionnalités réalisées durant le sprint sont sélectionnées dans le « product backlog » renseigné
par le « product owner ». L’équipe de développement se base sur leur estimation de la difficulté de
réalisation des fonctionnalités pour définir des priorités.
2.1. Objectif attendu

L’objectif de ce premier sprint étant de développer les modules relatifs à la journalisation des
données pour le calcul et la consultation du taux d’adoption outlook Online.
2.2. Sprint Backlog

Le Sprint Backlog est l'ensemble des éléments du Backlog du produit sélectionné pour le
Sprint. Le Sprint Backlog est une prévision sur les fonctionnalités qui seront dans le prochain
incrément et les tâches nécessaires pour fournir cette fonctionnalité dans un incrément terminé.
Le Tableau ci-dessous présente le Backlog du premier sprint et regroupe les fonctionnalités qui seront
développées au sein de ce sprint.
Page 33
Chapitre 4 : SPRINT 1 – Gestion de Taux d’adoption d’Outlook Online
ID User story ID Tâche Priorité

1 En tant qu’administrateur système, je 1.1 L’authentification d’un administrateur +++
veux m’authentifier
2 En tant qu’administrateur système, je 2.1 Gérer un administrateur Entité +++++
veux gérer les administrateurs entités 2.2 Modifier l’utilisateur office pour avoir le
rôle d’un administrateur Entité, dans le
contrôleur d’administrateur.
2.3 Tester le droit d’accès utilisateur
3 En tant qu’administrateur système, je 3.1 Gérer un service Entité. +++++
veux gérer les services entités 3.2 Ajouter la méthode nécessaire pour
l’ajout d’un service Entité
3.3 Modifier l’information service Entité des
utilisateurs office
4 En tant qu’administrateur système, je 4.1 Ajouter un utilisateur office dans Azure ++++
veux Synchroniser les utilisateurs Active directory
office
5 En tant qu’administrateur système, je 5.1 Ajouter la méthode d’ajout d’une +++++
veux suivre la journalisation des transaction office dans le journal
données d’adoption Outlook Online d’adoption Outlook Online.
6 En tant qu’administrateur système, je 6.1 Gérer les messages Erreur système +++++
veux gérer les messages 6.2 Afficher le Problème de synchronisation
6.3 Afficher le Problème de journalisation
7 En tant que responsable entité, je veux 7.1 L’authentification d’un responsable entité +++
m’authentifier
8 En tant que responsable entité, je veux 8.1 Analyser l’indicateur du taux d’adoption +++++
consulter le Nombre d’e-mail Nombre d’e-mail Envoyé/Reçu
Envoyé/Reçu » 8.2 Editer le rapport
9 En tant que responsable entité, je veux 9.1 Ajouter la méthode d’ajout d’un ++++
déposer un commentaire commentaire
Tableau 3: Tableau de Backlog Sprint 1
Page 34
3. Analyse détaillée des besoins

Les besoins à réaliser dans le premier sprint, ont été spécifiés et pour mieux expliquer, nous allons
présenter le diagramme des cas d’utilisation de ce sprint ainsi que les descriptions textuelles associées.
3.1. Diagramme de cas d’utilisation

La Figure ci-dessous nous illustre le diagramme des cas d'utilisation pour ce premier sprint :
Figure 14: Diagramme de cas d’utilisation sprint 1
Page 35
3.2. Description textuelle des cas d’utilisation

Dans le but de mieux comprendre les fonctionnalités de notre plateforme et les interactions avec
les différents acteurs, nous détaillons dans cette partie les principaux cas d’utilisations précédemment
identifiés.
3.2.1. Synchronisation des utilisateurs office
Cas d’utilisation
Acteurs Administrateur système
Précondition L’administrateur doit être authentifié.
Post-condition Les informations utilisateurs vont être mises à jour.
Scénario nominal 1. L’administrateur active le service de la synchronisation des données utilisateurs
office.
2. Le système affiche l’état activé.
3. Le système cherche les utilisateurs office
4. Le système enregistre la mise à jour vers les utilisateurs
Scénario alternatif 1a. Problème technique d’activation du service
1a.3. Reprise de l’étape 1
Tableau 4: Description textuelle du cas d’utilisation « Synchronisation des utilisateurs office »
3.2.2. Journalisation des données d’adoption « Nombre d’e-mail Envoyés/Reçus »
Cas d’utilisation
Post-condition Les informations des données d’adoption vont être mises à jour.
Scénario nominal 1.L’administrateur active le service de la journalisation des données des
indicateurs.
3. Le système cherche les données office : trafic des boîtes aux lettres « Nombre
d’e-mail Envoyés/Reçus »
4. Le système enregistre les données des indicateurs vers le journal
Tableau 5: Description textuelle du cas d’utilisation « MAJ de l’interface de journalisation des données »
3.2.3. Affichage de l’indicateur « Nombre d’e-mail Envoyés/Reçus »
Cas d’utilisation
Acteurs Responsable Entité
Précondition Le responsable Entité doit être authentifié.
Post-condition Affichage de l’indicateur Nombre d’e-mail Envoyés/Reçus
Scénario nominal 1. Le Responsable Entité demande l’interface d’affichage des indicateurs
2. Le système affiche le formulaire d’affichage passer des indicateurs
3. Le Responsable Entité saisit la période
4. Le système vérifie les données saisies.
Scénario alternatif 3a. Le commerçant saisit des données manquantes/invalides.
4a.1. Le système affiche un message d’erreur.
Tableau 6: Description textuelle du cas d’utilisation - Affichage Nombre email Envoyés/Reçus
Page 36
4. Wireframes des interfaces

Avant de nous emparer de la partie analytique, nous allons exposer quelques wireframes des
interfaces de ce Sprint pour y mettre en évidence les fonctionnalités et pour bien les assimiler.
- Dashboard
Figure 15: Wireframes des interfaces sprint 1 - Dashboard
- Gestion de Taux d’adoption : Nombre d’e-mail Envoyé/Reçu
Figure 16: Wireframes des interfaces sprint 1- Indicateurs Outlook
Page 37
- Synchronisation des utilisateurs office
Synchroniser Utilisateur office

Activer Désactiver
- Gérer les journalisations des transactions

Journalisation des indicateurs - Nombre d’e-mail Envoyés/Reçus
Activer Désactiver
Nous passons à présent, à la présentation de la conception de ce premier sprint. Pour cela,
nous allons documenter quelques cas d’utilisation à travers la construction des diagrammes de
séquence nécessaires. Nous proposons ensuite le diagramme de classes.
5.1. Diagrammes de séquence du cas d’utilisation

Les diagrammes de séquences représentent les interactions entre les objets.
Avant d’atteindre l’affichage de l’indicateur, le responsable entité doit s’authentifier avec son
login et son mot de passe sous office 365. Puis, n’a la possibilité d'accéder qu'aux services dont il est
autorisé.
5.1.1. Journalisation des données d’adoption « Nombre d’email »
Le schéma suivant montre les séquences à effectuer pour entamer la journalisation de l’indicateur
nombre d’email envoyé et reçu.
Page 38
Figure 17: Diagramme de séquences journalisation Outlook Nombre email Envoyé/Reçu
5.1.2. Synchronisation des utilisateurs office
Figure 18: Diagramme de séquences Synchronisation des utilisateurs offices
Page 39
5.1.3. Affichage de l’indicateur « Nombre d’e-mail Envoyés/Reçus »
Figure 19: Diagramme de séquences affichage Nombre email Envoyé/Reçu
5.2. Diagramme de classes

Les diagrammes de classes sont l'un des types de diagrammes UML les plus utiles, car ils
décrivent clairement la structure d’un système particulier en modélisant ses classes, ses attributs, ses
opérations et les relations entre ses objets.
Dans ce qui suit, nous présentons le diagramme de classes relatif à ce sprint.
a) Dictionnaire de données
Pour mieux comprendre l'aspect d'intégration du module, nous allons va aussi expliquer les
classes existantes :
Numéro Attribut Libellé Type

1 ID_Utilisateur_Office Identifiant d’un utilisateur Office Entier
2 Nom_utilisateur Nom d’un Utilisateur String
3 Prenom_Utilisateur Prénom d’un Utilisateur
4 ID_Service_Entité Service Entité String
5 Description_Entité Description service entité String
Page 40

6 ID_Rôle Identifiant du rôle d’un utilisateur Entier
7 Description_Rôle Description du rôle String
8 Email_Utilisateur_Office L’Email de l’utilisateur Office String
9 ID_IndicateurOutlook Identifiant de l’indicateur outlook Entier
10 Date_Traitement Date de traitement des données Date
11 Email_Envoyé Email Envoyé Entier
12 Email_Reçu Email Reçu Entier
13 Type_email Type Email (Envoyé/Reçu) String
14 Date_Création Date de création Date
Tableau 7: Dictionnaire de données Sprint 1
b) Diagramme
Figure 20: Diagramme de classes du sprint 1
Page 41
6. Réalisation
Dans cette partie, nous présentons quelques captures d’écran de notre application afin de
mieux comprendre la réalisation des différentes tâches de ce Sprint.
6.1. Captures d’écran
6.1.1. Authentification et création d’application Azure AD

• Authentification
Pour assurer que notre application soit sécurisée, nous avons choisi l’authentification
via Microsoft cela veut dire que le client qui veut utiliser notre application doit avoir
une licence Microsoft 365.
Figure 21: Connexion Microsoft 365
• Création d’application Azure AD
Afin de communiquer avec un tenant Microsoft 365, nous avons besoins de créer une
application AD avec des permissions Graph API pour consommer le tenant. La Figure 22
montre notre application crée sur azure AD :
Page 42
Figure 222 : Création de l’application Azure AD GMA365
Dans la Figure 23 L’application est installée dans le tenant du destinataire, nous pouvons accéder à
cette application à travers la liste des applications Microsoft 365 :
Figure 233 : Liste des applications Microsoft 365
Page 43
6.1.2. Dashboard (Front GMA365)

Cette interface [Figure 24] présente la page d’accueil, pour les responsables entités, qui
contient les différents choix des services misent en place.
Figure 244: Captures d’écran- Dashboard Front GMA365
6.1.3. Interface indicateur Outlook « Nombre d’e-mail Envoyé/Reçu »
Cette interface [Figure 25] présente la page indicateur Outlook, pour les responsables entités,
qui contient : le totale des emails envoyés et reçus avec le nombre de la journée données des
emails envoyés et reçus.
Figure 255 : Captures d’écran-Front GMA365 « Nombre d’e-mail Envoyé/Reçu »
Page 44
6.2. Tests et validation

Les tests, dans la méthode agile, sont essentiels au bon déroulement des développements. Afin
d'assurer la fiabilité des fonctionnalités développées, il est impensable de passer d’un sprint à un autre
sans pour autant l’avoir testé : les tests ont donc un rôle essentiel.
6.2.1. Test
Dans cette partie, nous avons choisi de tester :

- Connexion et Dashbord
o Connexion et authentification office 365
o Dashboard GMA365
- Traitement de l’indicateur Taux d’adoption outlook
▪ La journalisation de l’indicateur 1 « Nombre d’e-mail Envoyé/Reçu »
▪ La synchronisation des utilisateurs
▪ L’affichage de l’indicateur Nombre d’e-mail Envoyé/Reçu
Durant cette partie, nous avons eu quelques problèmes d’adaptations d’une part, sur le nouvel
environnement cloud Azure et la manière communication avec les services office 365 et d’autre
part, sur les nouvelles technologies.
6.2.2. Validation
A la fin du sprint nous avons effectué une réunion avec notre encadreur Mr AHMED MEHDI,
après le test de l’application, il nous a confirmé que le travail est effectué avec quelques
corrections.
7. Conformité aux exigences non fonctionnelles

Dans ce sprint, nous avons respecté les exigences non fonctionnelles suivantes :
Simplicité ; les espaces de gestion sont simples à utiliser
Temps de réponse : en utilisant Micosoft Graph API, l’application collecte les données
rapidement (Temps de réponse entre 1 et 5ms).
Ergonomie : nous avons travaillé avec le package « React-responsive », ce package nous permet
de créer des interfaces vraiment réactives et responsive dans notre projet.
La sécurité : Chaque acteur doit s’authentifier à travers Microsoft 365 pour accéder à
l’application.
Page 45
8. Conclusion
Dans cette étape de notre projet, nous avons conçu et réalisé notre premier sprint « Taux d’adoption
d'Outlook Online - Indicateur : Nombre d’e-mail Envoyé/Reçu (trafic des boîtes aux lettres » qui
décrit les tâches traitées. Puis nous avons illustré les différents diagrammes UML pour modéliser
notre module. Ainsi, nous avons décrit les interfaces et le fonctionnement des différentes tâches
traitées. Il constitue un premier incrément de notre application. Dans le chapitre suivant, nous
développons notre deuxième sprint.
Page 46
C HAPITRE 5 :
SPRINT 2 :
GESTION DE TAUX
D’ADOPTION AUX
SERVICES (TEAMS &
SHAREPOINT)
Page 47
Chapitre 5 : SPRINT 2 – Gestion de Taux d’adoption aux services
(Teams & SharePoint)
1. Introduction


L’objectif de ce premier sprint étant de développer les modules relatifs à la journalisation des
données d’adoption SharePoint et Teams puis le calcul et la consultation des indicateurs.
2.2. Sprint Backlog

Le Tableau ci-dessous présente le Backlog du deuxième sprint et regroupe les fonctionnalités qui
seront développées au sein de ce sprint.
Page 48
Chapitre 5 : SPRINT 2 – Gestion de Taux d’adoption aux services (Teams & SharePoint)

1 En tant qu’administrateur système, je 1.1 Gérer les services office : Teams, +++
veux gérer les services office SharePoint
2 En tant qu’administrateur système, je 2.1 Consulter le Dashboard Principale : +++
veux consulter le nombre des Nombre de Connexion à Office
utilisateurs connectés sur les différents 365, Nombre de connexion à
services Microsoft 365. OneDrive, Nombre de Connexion à
SharePoint
3 En tant qu’administrateur système, je 3.1 Ajouter la méthode d’ajout d’une +++
veux suivre la journalisation des transaction office dans le journal
données d’adoption Teams des données d’adoption : Nombre
de connexion au service Teams
4 4.1 Ajouter la méthode d’ajout d’une +++++
En tant qu’administrateur système, je transaction office dans le journal
veux suivre la journalisation des des données d’adoption : Nombre
données d’adoption SharePoint de connexion au service SharePoint
5 5.1 Analyser l’indicateur du taux +++++

d’adoption en consultant le
Dashboard Teams : (Nombre de
En tant que responsable entité, je veux communication, Nombre de
analyser l’indicateur Teams Réunion, Nombre de Message
Privé, Nombre de Message en
Equipe)
5.2 Editer le Rapport
6 6.1 Analyser l’indicateur du taux +++++
d’adoption en consultant le
Dashboard SharePoint : (Nombre
En tant que responsable entité, je veux de Page Visité, Nombre de Page
analyser l’indicateur SharePoint Vue/modifier, Nombre de fichier
Synchroniser, Nombre de Fichier
Partagé à l’intérieur d’une entité et
Nombre de Fichier Partagé à
L’extérieur d’une entité)
6.2 Editer le Rapport
Page 49



identifiés.
3.2.1. Journalisation des données d’adoption « Nombre de connexion aux services SharePoint »
Cas d’utilisation
indicateurs.
3. Le système cherche les données office : « Nombre de connexion au
service SharePoint »
4. Le système enregistre les données d’adoption vers le journal
Tableau 9: Description textuelle du cas d’utilisation – MAJ de la journalisation des données SharePoint
Page 50
3.2.2. Journalisation des données d’adoption « Nombre de connexion aux services Teams »
Cas d’utilisation
indicateurs.
3. Le système cherche les données office : « Nombre de connexion au
service Teams)»
4. Le système enregistre les données d’adoption vers le journal
Tableau 10: Description textuelle du cas d’utilisation – MAJ de la journalisation des données Teams
3.2.3. Affichage de l’indicateur « Nombre de connexion au service SharePoint »
Cas d’utilisation
Post-condition Affichage de l’indicateur Nombre de connexion au service SharePoint
Tableau 11: Description textuelle du cas d’utilisation - Affichage Nbre de connexion SharePoint
3.2.4. Affichage de l’indicateur « Nombre de connexion au service Teams
Cas d’utilisation
Post-condition Affichage de l’indicateur Nombre de connexion au service Teams
Tableau 12: Description textuelle du cas d’utilisation - Affichage Nbre de connexion Teams
Page 51

- Gestion de Taux d’adoption : Indicateur Teams
Figure 27: Wireframes des interfaces sprint 2- Indicateur Teams
- Gestion de Taux d’adoption : Indicateur SharePoint
Figure 28: Wireframes des interfaces sprint 2- Indicateur SharePoint
Page 52
5.1. Diagrammes de séquence

Les diagrammes de séquences représentent les interactions entre les objets en indiquant
La chronologie des séquences. Les diagrammes de séquences ajoutent une dimension temporelle
aux diagrammes de collaborations.
5.1.1. Diagramme de séquences du cas d’utilisation « Journalisation des données
d’adoption Sharepoint »
Le schéma suivant montre les séquences à effectuer pour entamer la phase de journalisation.
Figure 29 : Diagramme de séquences journalisation Nombre de connexion au service SharePoint
Page 53
5.1.2. Diagramme de séquences du cas d’utilisation « Journalisation des données

d’adoption Teams »
Figure 30: Diagramme de séquences journalisation - Nombre de connexion au service Teams
5.1.3. Diagramme de séquences du cas d’utilisation « Affichage des Indicateurs

Sharepoint
Le schéma suivant montre les séquences à effectuer pour entamer la phase d’affichage de l’indicateur.
Figure 31: Diagramme de séquences Affichage - Nombre de connexion au service SharePoint
Page 54
5.1.4. Diagramme de séquences du cas d’utilisation « Affichage des Indicateurs Teams

Le schéma suivant montre les séquences à effectuer pour entamer la phase d’affichage de l’indicateur.
Figure 32: Diagramme de séquences Affichage - Nombre de connexion au service Teams

5.2.1. Dictionnaire de données
Pour mieux comprendre l'aspect d'intégration du module, nous allons aussi expliquer les

1 ID_Utilisateur Identifiant d’un utilisateur Office String
2 Nom Nom d’un utilisateur String
3 Prénom Prénom d’un utilisateur String
4 ID_Role Identifiant du rôle d’un utilisateur String
5 Email_Utilisateur L’Email d’un utilisateur Office String
6 ID_ServiceEntité Identifiant d’une entité String
7 Description_Entité Description du poste String
8 Description_Role Description du rôle String
9 ID_IndicateurTeams Identifiant de l’indicateurOutlook String
10 DateCreation La date de création DateTime
11 NbrCall Le nombre d’appel effectuer par Entier
l’utilisateur
Page 55

12 NbrRéunion Le nombre de réunion qu’un Entier
utilisateur à effectuer
13 NbrMsgPrivé Le nombre de message privé qu’un Entier
utilisateur à envoyer
14 NbrMsgEquipe Le nombre de message envoyer en Entier
équipe par un utilisateur
15 NbrPageVisite Le nombre de page Sharepoint Entier
qu’un utilisateur à visiter
16 NbrPageVue_Modifier Le nombre de page Sharepoint Entier
qu’un utilisateur à vue ou modifier
17 NbrFishierSyncro Le nombre de fichiers qu’un Entier
utilisateur à synchroniser
18 NbrFishierPartagé_Int Le nombre de fichiers qu’un Entier
utilisateur à partager en interne
19 NbrFishierPartagé_Ext Le nombre de fichiers qu’un Entier
utilisateur à partager en externe
5.2.2. Diagramme
Page 56
6. Réalisation

o Front Teams
Figure 34: Captures d’écran- Sprint 2 – Front Teams
o Front SharePoint
Figure 35: Captures d’écran- Sprint 2 – Front SharePoint
Page 57

6.2.3. Test

- La journalisation de l’indicateur 2 « Nombre de connexion aux services (Teams &
SharePoint)»
- La synchronisation des utilisateurs
- L’affichage de l’indicateur Nombre de connexion au service SharePoint
- L’affichage de l’indicateur Nombre de connexion au services Teams
6.2.4. Validation
après le test de l’application, il nous a confirmé que le travail est effectué.

Temps de réponse : en utilisant Micosoft Graph API, l’application collecte les données
l’application.
8. Conclusion
Dans cette étape de notre projet, nous avons conçu et réalisé notre deuxième sprint « Nombre de
connexion aux services (Teams & SharePoint) » qui décrit les tâches traitées. Puis nous avons illustré
les différents diagrammes UML pour modéliser notre module. Ainsi, nous avons décrit les interfaces
et le fonctionnement des différentes tâches traitées.
Dans le chapitre suivant, nous développons notre troisième sprint.
Page 58
C HAPITRE 6 :
SPRINT 3 :
GESTION DES BOITES A
RISQUE (MESSAGERIE
OUTLOOK)
Page 59
Chapitre 6 : SPRINT 3 – Gestion des Boîtes à Risque (Messagerie
Outlook)
1. Introduction

L’objectif de ce premier sprint étant de développer les modules relatifs à la gestion des
utilisateurs, des groupes ainsi que des services.
2.2. Sprint Backlog

Le Tableau ci-dessous présente le Backlog du troisième sprint et regroupe les fonctionnalités qui
seront développées au sein de ce sprint.

1 En tant qu’administrateur système, je 1.1 Gérer les quotas boites emails +++
veux gérer les quotas des boites emails
2 En tant qu’administrateur système, je 2.1 Ajouter la méthode d’ajout d’une +++++
veux suivre la journalisation de transaction office dans le journal de
dépassement de quota (Messagerie journalisation de dépassement de
Outlook) quota (Messagerie Outlook)
3 En tant qu’administrateur système, je 3.1 Gérer les messages
veux gérer les messages
4 En tant que responsable d’entité, je 4.1 Gérer les messages par notification +++++
veux suivre les notifications par alerte 4.2 Editer le rapport
en cas de dépassement de quota
Page 60
Chapitre 6 : SPRINT 3 – Gestion des Boîtes à Risque (Messagerie Outlook)



identifiés.
3.2.1. Journalisation de dépassement de quota
Cas d’utilisation
Post-condition Les informations des données indicatrices vont être mises à jour.
Scénario nominal 1.L’administrateur active le service de la journalisation de dépassement de
quota.
3. Le système cherche les données office : volume des boîtes aux lettres > au
quota
4. Le système enregistre les données des indicateurs vers le journal
Tableau 15: Description textuelle du cas d’utilisation Journalisation/Notification dépassement de quota
Page 61
3.2.2. Affichage détail dépassement de quota

Cas d’utilisation
Post-condition Les informations des données stockées et à jour.
Scénario nominal 1.L’administrateur demande le détail des Notifications cas de dépassement de
quota.
2. Le système cherche le détail
3. Le système affiche le détail

Tableau 16: Description textuelle du cas d’utilisation « Affichage détail dépassement de quota »

- Boites à Risque
Figure 37: Wireframes des interfaces sprint 3 – Botes à risques
- Modèle Email à envoyer en cas de dépassement :

Chère/Cher « User », Votre espace de stockage (Outlook/SharePoint) est saturé. Vous avez
dépassé votre forfait de stockage : (vos documents SharePoint et les données de votre boîte
mail ne sont plus sauvegardés) sur X. (Vos mails/Vos Fichiers) ne sont plus transférées dans
vers X. La mise à jour de OneDrive et des apps compatibles avec le Cloud n’est plus effectuée
Page 62
sur vos appareils. Pour continuer à utiliser ces services, veuillez mettre à niveau votre espace
de stockage Cloud (Archive des emails/fichiers SharePoint) ou réduire l’espace de stockage
que vous utilisez.
Cordialement,
GMA 365
5.1. Diagrammes de séquence

Les diagrammes de séquences représentent les interactions entre les objets en indiquant
La chronologie des séquences. Les diagrammes de séquences ajoutent une dimension temporelle
aux diagrammes de collaborations.
5.1.1. Diagramme de séquences du cas d’utilisation « Journalisation et notification des
dépassements de quota Outlook Online
Le schéma suivant montre les séquences à effectuer pour entamer la phase de la journalisation et la
notification cas dépassement de quota.
Figure 38: Diagramme de séquences journalisation et notification dépassements de quota
Page 63
5.1.2. Diagramme de séquences du cas d’utilisation « Affichage détail »

Figure 39: Diagramme de séquences Affichage détail dépassement quota

5.2.1. Dictionnaire de données
Pour mieux comprendre l'aspect d'intégration du module, nous allons aussi expliquer les

1 ID_Utilisateur Identifiant d’un utilisateur Office String
2 Nom Nom d’un utilisateur String
3 Prénom Prénom d’un utilisateur String
4 ID_Role Identifiant du rôle d’un utilisateur String
5 Email_Utilisateur L’Email d’un utilisateur Office String
6 ID_ServiceEntité Identifiant d’une entité String
7 Description_Entité Description du poste String
8 Description_Role Description du rôle String
9 QuotaAvertissement Quota d’avertissement Entier
10 ID Journalisation Identifiant Journalisation String
dépassement quota dépassement quota
11 DateCreation La date de création DateTime
12 Valeur Dépassement Valeur Dépassement Quota Entier
Quota
13 Notification Notification Entier
Page 64
5.2.3. Diagramme
6. Réalisation
Figure 41: Captures d’écran- Sprint 3 – Boites à Risque
- Modèle Email à envoyer en cas de dépassement :

Modèle Email envoyé systématiquement cas dépassement de quota
Page 65
Figure 42: Captures d’écran- Sprint 3 – Email envoyé

6.2.5. Test

- La journalisation du dépassement du quota « Gestion des Alertes Boîtes à Risque (Messagerie
Outlook) »
- La synchronisation des utilisateurs
- Notification par mail en cas de dépassement de quota
Par contre, faute de temps, nous n’avons pas compléter le développement de l’affichage du
détail des dépassements de quota des utilisateurs.
6.2.6. Validation
après le test de l’application, il nous a confirmé que le travail est effectué.
Page 66

Temps de réponse : en utilisant Microsoft Graph API, l’application collecte les données
l’application.
8. Conclusion
Dans cette étape de notre projet, nous avons conçu et réalisé notre troisième sprint « Notification par
alerte en cas de dépassement de quota Outlook online » qui décrit les tâches traitées. Puis nous avons
illustré les différents diagrammes UML pour modéliser notre module. Ainsi, nous avons décrit les
interfaces et le fonctionnement des différentes tâches traitées.
Page 67
Conclusion générale et perspectives
Ce travail s’inscrit dans le cadre du stage de fin d’études effectué au sein de la société PROGED
Internationale. L’objectif principal de notre projet est de contribuer à l’amélioration de la gestion du
tenant Microsoft 365.
Dans ce sens, nous avons commencé par une étude théorique sur les spécifications du projet GMA
365, le déroulement de ces différents modules, les solutions existantes et les besoins qui ont amené à
la réalisation de notre projet. Dès que les priorités des exigences de notre projet ont été fixées, nous
avons commencé le processus du travail.
Notre projet a été réalisé en quatre mois pendant lesquels nous sommes arrivés à développer les
différentes fonctionnalités de l’application qui permettant de consulter l’état de notre tenant avec une
manière visuellement attirante et simple.
De plus, GMA365 nous permet d’une part de mettre à la disposition des responsables entités les
indicateurs d’analyse du taux d’adoption relatif à Outlook Online, Teams et SharePoint et d’autre part
bien gérer les boîtes à risque de la messagerie Outlook en appliquant la règle de dépassement de
quota.
Durant notre stage de fin d’étude, nous avons eu l’opportunité de découvrir le monde professionnel
et de maitriser les nouvelles technologies. Un autre point assez pertinent de notre expérience était
l’occasion de travailler avec la méthode Scrum tout au long de la période de développement avec tout
ce qu’elle implique de responsabilité, d’organisation, d’estimation convenable de durée des tâches et
de travail d’équipe. Que ce soit technique ou social, cela nous permet d’améliorer nos compétences.
Notre processus n’est pas simple, nous devons faire face à certaines difficultés, telles que la
compréhension du sujet et l’étude des technologies. Malgré toutes les difficultés rencontrées, nous
avons réussi à mettre en œuvre l’application. Finalement, notre travail ne s’arrête pas à ce niveau.
Plusieurs perspectives peuvent être envisagés. En fait nous ne sommes pas arrivés à la phase de
gestion des entités. Comme perspective, nous souhaitons ajouter des filtres par service pour améliorer
la gestion des administrateurs entités qui est responsable de la consultation de l’utilisation des
différents services par les utilisateurs et ce par l’intégration de l’informatique décisionnelle
(Business Intelligence) pour une analyse plus approfondie des indicateurs.
Indépendamment des contraintes techniques et des défis confrontés, nous avons atteint les objectifs
et nous avons répondu aux exigences du projet.
Page 68
Bibliographie et Webographie
[1]. Microsoft 365 : travaillez en ligne avec OneDrive, SharePoint, Teams, Planner et Outlook
Editions ENI - Myriam GRIS.
[2]. Mise en œuvre d’office 365 : Gestion de projet et conduite du changement

Préface de Alain CROZIER, Président de Microsoft France
Editions ENI – Collection DataPro
Denis MEINGAN & Gilles BALMISSE
[3]. React : Développez le Front End de vos applications web et mobiles avec JavaScript Editions ENI -
Sébastien CASTIEL
[4]. https://www.progedsolutions.com/
[5]. «SCRUM,» [En ligne]. Available: https://www.thierry-pigot.fr/scrum-en-moins-de-10-minutes/
[6]. «UML,» [En ligne]. Available: https://web.maths.unsw.edu.au/~lafaye/CCM/uml/umlintro.htm
[7]. «Bootstrap,» [En ligne]. Available: https://getbootstrap.com/
[8]. «JavaScript,» [En ligne]. Available : https://www.javascript.com/
[9]. https://fr.wikipedia.org/wiki/Visual_Studio_Code
[10]. https://fr.wikipedia.org/wiki/Microsoft_Azure
[11]. https://docs.microsoft.com/fr-fr/microsoft-365/solutions/collaboration-governance-
overview?view=o365-worldwide
[12]. https://docs.microsoft.com/fr-fr/microsoft-365/compliance/manage-information-
governance?view=o365-worldwide
[13]. https://docs.microsoft.com/en-us/microsoft-365/compliance/information-protection?view=o365-
worldwide
[14]. https://www.avepoint.com/fr
[15]. https://www.govern365.com
[16]. https://azure.microsoft.com/fr-fr/services/active-directory/
[17]. https://docs.microsoft.com/fr-fr/power-automate/
[18]. https://azure.microsoft.com/fr-fr/products/azure-sql/database/
Page 69
Résumé
La gouvernance et d'administration de l'environnement Office 365 est un ensemble de principes,

règles, rôles et responsabilités qui guident et supervisent la coopération de tous les membres à réaliser
leurs tâches avec l’appui des services offerts.
L’objectif principal de notre projet est de concevoir puis développer une application « Gestion de la
gouvernance du tenant office ».
Cette application permet aux responsables entités et administrateurs de gouverner la Gestion de taux
d'adoption et la Gestion des Boîtes à risque.
Les Technologies utilisées en front « ReactJS, Bootstrap, JavaScript, HTML », en Back « Power
Automate, Graph API », le Déploiement « App service » et la Base de Données « Azure SQL
Database » avec Microsoft 365 « SharePoint, Teams, Outlook »
A travers ce document, nous allons décrire en détails les différentes étapes de réalisation du projet.
Abstract
The governance and administration of the Office 365 environment is a set of principles, rules, roles
and responsibilities that guide and oversee the cooperation of all members in carrying out their tasks
with the support of the services offered.
The main objective of our project is to design and then develop a "Holding office governance
management" application.
This application allows entity managers and administrators to govern the management of adoption
rates and the management of risk boxes.
The Technologies used in front "ReactJS, Bootstrap, JavaScript, HTML", in Back "Power Automate,
Graph API", the Deployment "App service" and the Database "Azure SQL Database" with Microsoft
365 "SharePoint, Teams, Outlook ".
Through this document, we will describe in detail the different stages of the project.

Langue

AHMED HAMMAMI 3LATI Gestion de La Gouvernance Du Tenant Office

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

AHMED HAMMAMI 3LATI Gestion de La Gouvernance Du Tenant Office

Transféré par

Droits d'auteur :

Formats disponibles

Ministère de l’Enseignement Supérieur, de la Recherche

Scientifique et des Technologies de l’Information et de la Communication

Rapport de Projet de Fin d’Etudes présenté en vue de l’obtention du Diplôme de

Réalisé Par : AHMED HAMMAMI

Encadrant Académique : Encadrant Professionnel :

Année Universitaire 2020-2021

Je tiens à remercier tout particulièrement et à témoigner toute ma reconnaissance à Mr Ahmed

Table des Figures ............................................................................................................................................... i

Introduction générale ....................................................................................................................................... 1

Chapitre 1 : Contexte général du projet......................................................................................................... 4

Chapitre 2 : Analyse et spécifications des besoins ....................................................................................... 11

Chapitre 4 : SPRINT 1 – Gestion de Taux d’adoption d’Outlook Online ................................................ 33

Chapitre 6 : SPRINT 3 – Gestion des Boîtes à Risque (Messagerie Outlook) .......................................... 60

Conclusion générale et perspectives ............................................................................................................. 68

Bibliographie et Webographie ...................................................................................................................... 69

Cette évolution nous mène à étudier en particulier :

Figure 1: Logo de PROGED Business Solutions

PROGED offre un éventail complet de services, de solution et d’expertise pour accélérer la

Figure 2: Logo du projet

3.2. Objectifs à atteindre

L’application « GMA365 » vise à :

4.1. Analyse de l’existant

Figure 3: Gouvernance de la Collaboration sous Microsoft 365

4.1.3. Solutions sur le marché

Nous citons quelques exemples de plateformes proposées sur le marché :

Figure 4: Site Avepoint

Figure 6: Site Gover365

4.2. Critique de l’existant

• Complexité d’installation et de configuration de l’application (client lourd),

4.3. Solution proposée

Dans le deuxième chapitre, nous présentons la méthode de développement adoptée et le choix du

2. Cadre méthodologique de développement

Figure 7: Cycle de vie de la méthode SCRUM

3.1. Choix de la méthode de conception

3.2. Choix du langage de modélisation

• UML facilite la compréhension et la communication d’une modélisation objet,

4. Spécification des exigences

4.1. Identification des acteurs

4.2. Exigences fonctionnelles

4.2.1. Gestion de taux d'adoption

4.2.2. Gestion des Boîtes à risque

4.3. Exigences non fonctionnelles

4.4. Vue architecturale des cas d’utilisations

Figure 8: Vue architecturale des cas d’utilisations

4.5. Vue architecturale de diagramme de classes

Figure 9: Diagramme de classe général

5. Le pilotage du projet par SCRUM

5.1. Découpage du projet

La Figure ci-dessous décrit la structuration de notre projet :

Projet de fin d'etudes

Figure 10: Découpage du projet

5.2. Backlog du produit

ID Fonctionnalité ID User Stories Priorité

ID Fonctionnalité ID User Stories Priorité

5.3. Planification des Sprints

5.4. Planification du projet

Nous avons utilisé Microsoft Project pour la planification de notre projet

Figure 11: Microsoft Project - Planification du projet

Figure 12: Architecture de la solution GMA365

Web client : Application sous l’Url Office365

Database : Azure SQL Server

Office 365 Ecosystème