DÉDICACE A MA FAMILLE i REMERCIEMENTS Ce rapport n’aurait jamais paru sans le concours sous diverses formes de plusieurs personnes. C’est donc avec le souci d’un tendre devoir que nous témoignons notre extrême gratitude à l’égard de ceux dont nous rappelons, particulièrement à : Pr. JAZET Pierre Michel, mon superviseur de mémoire, pour sa coordination ; M. TEKOUDJOU François Xavier, mon encadreur académique, pour le temps qu’il m’a consacré durant tout ce travail, pour ses conseils et surtout pour sa patience incomparable ; M. TEKEU Guimezap Hypolithe, mon encadreur professionnel, pour la confiance qu’il m’a accordée et pour ses nombreux conseils pendant la réalisation de ce travail ; M. NWOKAM Rostand Verlaine notre chef de département, pour ses conseils, ses encouragements dont il a su nous apporter ; Tout le corps enseignant pour leurs enseignements et leur dévouement ; Tout le personnel de IUC pour la sympathie et la passion partagée ; Toute ma famille pour leur soutien indescriptible ; Tous mes camarades de promotion SIGL 2020 – 2021 pour le climat de gaieté et de confiance qu’ils ont su créer durant notre formation ; Tous ceux qui ont participes de près de loin a l’élaboration de ce mémoire. A vous tous encore, je vous dis merci. ii SOMMAIRES DÉDICACE ............................................................................................................................................................ I REMERCIEMENTS ........................................................................................................................................... II SOMMAIRES...................................................................................................................................................... III LISTE DES ABRÉVIATIONS .......................................................................................................................... IV LISTE DES FIGURES .........................................................................................................................................V LISTE DES TABLEAUX ................................................................................................................................... VI RÉSUMÉS ......................................................................................................................................................... VII ABSTRACT ...................................................................................................................................................... VIII INTRODUCTION GÉNÉRALE ....................................................................................................................... IX CHAPITRE 1 : ÉTAT DE L’ART....................................................................................................................... 1 SECTION 1 : CONCEPTS THÉORIQUES................................................................................................................... 2 I. gÉNÉRALITÉ sur les annuaires .............................................................................................................. 2 II. Protocole LDAP .................................................................................................................................. 6 SECTION 2 : CONTEXTE ...................................................................................................................................... 18 I. Contexte ................................................................................................................................................ 18 II. problematique ................................................................................................................................... 18 III. consequence ...................................................................................................................................... 19 IV. objectifs vises .................................................................................................................................... 19 V. interet du projet ..................................................................................................................................... 20 CHAPITRE 2 : CADRAGE DU THÈME ......................................................................................................... 21 SECTION 1 : ÉTUDE CRITIQUE ET ORIENTATION ................................................................................................. 22 I. presentation de l’existant ...................................................................................................................... 22 II. critique de l’existant .......................................................................................................................... 22 III. Solutions existantes et nouvelle orientation ...................................................................................... 23 SECTION 2 : CAHIER DE CHARGES ..................................................................................................................... 24 I. Besoins .................................................................................................................................................. 24 II. objectifs ............................................................................................................................................. 24 III. criteres d’acceptation........................................................................................................................ 25 IV. planning et couts ............................................................................................................................... 26 CHAPITRE 3 : METHODOLOGIE ET OUTILS ........................................................................................... 32 SECTION 1 : MOTIVATION ET CHOIX METHODOLOGIQUE .................................................................................... 32 I. Motivation ............................................................................................................................................. 32 II. choix du modele de cycle de vie ........................................................................................................ 32 III. presentation de la methodologie ....................................................................................................... 34 BIBLIOGRAPHIE .............................................................................................................................................. 41 iii LISTE DES ABRÉVIATIONS SIGLES SIGNIFICATIONS SI Système informatique API Application Programming Interface AD Active Directory LDAP Lightweight Directory Access Protocol CN Common Name DIT Directory Information Tree DN Distinguished Name DSA Directory System Agent DSE Directory Service Entry O Organization OU Organizational Unit SGBD Système de Gestion de Base de Données SN Surname SQL Structured Query Language SSL Secure Socket Layer TLS Transport Layer Security UID Userid RDN Relative Distinguished Name PO Product Owner LDIF LDAP Data Interchange Format / Lightweight Data Interchange Format iv LISTE DES FIGURES Figure 1 Positionnement des deux notions d’infrastructure et de service d’annuaire [5]........................................ 4 Figure 2 Architecture de LDAP [9]......................................................................................................................... 8 Figure 3 Serveur LDAP [1] ..................................................................................................................................... 8 Figure 4 Protocole asynchrone [1] .......................................................................................................................... 9 Figure 5 Arborescence expliquée [1] ...................................................................................................................... 9 Figure 6 Exemple d'un DN et RDN sous une DIT de racine "dc=exemple,dc=com" ........................................... 12 Figure 7 Authentification LDAP [11] ................................................................................................................... 14 Figure 8 Gestion des habilitations [11] ................................................................................................................. 15 Figure 9 : Product Breakdown Structure ............................................................................................................... 29 Figure 10 Diagramme de GANTT ........................................................................................................................ 30 v LISTE DES TABLEAUX Tableau 1 Série de clés généralement utilisées [7] ................................................................................................ 10 Tableau 2 Solutions existantes [13] ...................................................................................................................... 23 Tableau 3 : Ressources humaines.......................................................................................................................... 26 Tableau 4 : Ressources matérielles ....................................................................................................................... 27 Tableau 5 : Ressources logicielles ........................................................................................................................ 27 Tableau 6 : Bilan ................................................................................................................................................... 28 Tableau 7 : Organigramme des taches .................................................................................................................. 29 Tableau 8 Quelques modèles de cycle de vie ........................................................................................................ 32 vi RÉSUMÉS vii ABSTRACT viii INTRODUCTION GÉNÉRALE Aujourd’hui, les technologies de l’information et de la communication sont d’un apport capital au développement des entreprises, et la gestion rationnelle des temps de travail des employés devient compliquée et chronophage. Généralement, cinq fonctions principales sont reconnues a l’entreprise. La fonction technique, la fonction humaine, la fonction commerciale, la fonction recherche et développement, et enfin la fonction financière. De toutes ces fonctions, celle humaine revêt une importance capitale dans le fonctionnement d’une entreprise ; car réalité humaine, l’entreprise est une unité sociale. L’informatique est devenue un outil permettant d’améliorer la rentabilité, la productivité et d’optimiser le temps de réalisation des activités d’une entreprise. Cependant, la création des comptes d’annuaire et l’envoi du manuel d’utilisation des services offerts par l’entreprise de façon manuelle nécessitent dès lors un effort considérable de l’administration. C’est dans cette optique de pallier à ces problèmes que l’idée de notre projet de mémoire est née, avec pour objet de structurer la démarche d’une solution « développement d’une passerelle interopérable de génération des comptes d’annuaire à partir d’une API » rapide visant à apporter satisfaction à l’administration des entreprises et des établissements scolaires. Afin de contribuer de manière efficace a la résolution de cette préoccupation, nous avons divise notre travail en cinq chapitres : Un premier chapitre intitulé Etat de l’art, qui présente les concepts théoriques sur l’annuaire, le protocole LDAP et le contexte de ce travail. Le second chapitre intitulé Cadrage du thème, qui présente dans un premier temps une étude critique et orientation et dans un deuxième temps le cahier de charges. Le troisième chapitre intitulé Méthodologie et outils, qui présentent la motivation et le choix méthodologique Le quatrième chapitre intitulé Analyse et conception de la solution, qui présente dans un premier temps une analyse approfondie, dans un deuxième temps une modélisation conceptuelles et en fin une architecture générale de l’application. Le cinquième chapitre intitulé Résultats obtenus et discussion, qui présente dans un premier temps les outils et méthodes d’implémentation, dans un deuxième temps la solution réalisé et en fin une évaluation des résultats obtenus et l’impact sur l’entreprise. ix CHAPITRE 1 : ÉTAT DE L’ART 1 SECTION 1 : CONCEPTS THÉORIQUES I. GÉNÉRALITÉ SUR LES ANNUAIRES Introduction Dans l’entreprise, les applications et les serveurs ont besoin des données pour l’authentification, les droits d’accès… autant d’informations difficiles à maitriser, car très volatiles et éparses. Ceci entraine une dépression rapide, voire une incohérence des données stockées. Les annuaires LDAP offrent une réponse à ce problème en proposant de centraliser les informations et par le biais d’un protocole standardisé, d’y connecter des applications clientes. [1] Le but de cette partie est de : Définir l’annuaire et citer les différences entre ce dernier et une base de données ; Montrer le positionnement des deux notions d’infrastructure et de service d’annuaire ; Présenter le serveur d’annuaires et citer les intérêts d’un annuaire. I.1. DÉFINITION D’UN ANNUAIRE Un annuaire d’entreprise, c’est comme l’annuaire téléphonique, à ceci près qu’il gère plus de choses. Regardons les caractéristiques de l’annuaire téléphonique pour mieux comprendre le concept : Il liste des données (nom, prénom, numéro de téléphone, adresse) Il organise ces données (département/villes/nom) Il offre un moyen de consultation (en ligne, appli Smartphone, format papier) Il peut protéger les données (liste rouge) Il est plus consulté que mis à jour Il est disponible de manière permanente On peut trouver d’autres annuaires dans un SI : DNS : Domain Name Services NIS : Network Information Services WHOIS : base d’information concernant les noms de domaines [1] 2 Un annuaire électronique peut être vu comme une base de données spécialisée, dont la fonction première est de retourner un ou plusieurs attributs d’un objet grâce à des fonctions de recherche multicritères. Les objets peuvent être de nature très diverse. Par exemple, un objet de l’annuaire peut représenter une personne et les attributs de cet objet seront alors son nom, son prénom, son numéro de téléphone, etc. par exemple, un objet représentera une imprimante et les attributs de l’objet seront alors les différents noms de cette imprimante, son adresse réseau, sa situation géographique, etc. Un annuaire électronique centralise des informations et les rend disponibles, via le réseau, à des applications, des systèmes d’exploitation ou des utilisateurs. [2] I.2. DIFFÉRENCES ENTRE UN ANNUAIRE ET UNE BASE DE DONNÉES Un annuaire n’est pas fait pour stocker des informations constamment en mouvement. Un annuaire fournit une méthode de consultation standardisée. Chaque SGBD, même s’il utilise SQL comme langage d’interrogation nécessite sa propre interface de connexion. Une base de données organise ses informations dans des tableaux (TABLES) à deux dimensions, un annuaire organise les siennes dans une arborescence. Un annuaire fournit des modelés de données standardisés (SCHÉMAS), alors que le modèle conceptuel (MCD) d’une base de données varie d’une application à une autre et même d’une entreprise à une autre. [3] De plus, dans un annuaire : Il n’y a pas de dépendances entre les objets stockés Les objets peuvent être distribués sur plusieurs annuaires pour assurer une meilleure disponibilité. Les applications de l’annuaire n’ont pas besoin de connaitre la structure interne des données stockées. [4] 3 I.3. POSITIONNEMENT DES DEUX NOTIONS D’INFRASTRUCTURE ET DE SERVICE D’ANNUAIRE Figure 1 Positionnement des deux notions d’infrastructure et de service d’annuaire [5] La figure 1 montre les alimentations et les fonctions d’infrastructure et de service d’annuaires : A – Alimentation amont Trois canaux d’alimentation amont sont possibles : A1 : Applications de ressources humaines pour les utilisateurs internes constituent les Sources de l’annuaire. Ces sources peuvent être, entre autres, les fichiers du personnel. A2 : autres applications : les applications des ressources humaines n’ont pas nécessairement toutes les informations nécessaires pour alimenter l’annuaire, par exemple, le numéro de téléphone d’une personne sera alimenté par le PABX. Ainsi, d’autres applications que celles des ressources humaines contribuent à l’alimentation amont. A3 : Saisie manuelle : pour certaines catégories d’utilisateurs, il est possible qu’aucune application ne puisse être la source créatrice dans l’annuaire. Dans ce cas, les 4 administrateurs doivent pouvoir saisir les informations nécessaires directement dans l’annuaire. B – Alimentation aval Pour certaines applications et services du système d’information, l’annuaire est le point central d’alimentation des comptes d’accès (identifiants, mots de passe et autres attributs). Cette alimentation concerne toutes les actions de gestion courante sur ces comptes. C – Fonctions à destination des utilisateurs Les utilisateurs accèdent à l’annuaire pour obtenir des informations de type « Pages blanches », « Pages jaunes » ou « Organigramme ». D – Fonctions à destination des administrateurs Les administrateurs disposent de vues spécifiques sur l’annuaire pour exécuter leurs tâches de gestion (création, modification, suppression, etc.) et lorsqu’ils sont en charge de la gestion des identités pour s’assurer que le bon droit d’accès sont attribuées à la bonne personne pendant le bon laps de temps. [5] I.4. INTÉRÊTS D’UN ANNUAIRE D’une façon générale, l’utilisation d’un annuaire présente plusieurs intérêts : Administration centralisée et simplifiée : la gestion des comptes utilisateurs est simplifiée. Tout est centralisé dans l’annuaire. Authentification unifiée : un utilisateur authentifie sur une machine, sous condition d’avoir les autorisations nécessaires, peut accéder aux ressources stockées sur d’autres serveurs ou ordinateurs enregistres dans l’annuaire. Un seul compte permet un accès à tout le système d’information de l’entreprise. Référencement de tous les utilisateurs : l’annuaire s’apparente à une énorme base de données qui référence les utilisateurs, les groupes et les ordinateurs d’une entreprise. Les applications et systèmes d’exploitation s’appuient sur cette base de données pour réaliser de nombreuses opérations : authentification, identification, stratégie de groupe, déploiement de logiciels… [6] Conclusion 5 Dans cette partie on a vu la définition d’un annuaire et les différences entre ce dernier et une base de données. Le positionnement des deux notions d’infrastructure et de service d’annuaire. La présentation du serveur d’annuaire et les intérêts d’un annuaire. II. PROTOCOLE LDAP Introduction Le but de cette partie est de présenter le protocole LDAP, et de définir ce protocole. Expliquer le fonctionnement du protocole LDAP. Monter son architecture, ces principes et ses concepts. Décris que fournit ce protocole d’annuaires. Citer ses caractéristiques. II.1. PRÉSENTATION LDAP (Lighweight Directory Access Protocol), Protocole d’accès aux annuaires léger est prononce "èl-dap" est un protocole standard permettant de gérer des annuaires, c’est-à-dire d’accéder a des bases d’informations sur les utilisateurs d’un réseau par l’intermédiaire des protocoles TCP/IP. Les bases d’informations sont généralement relatives à des utilisateurs, mais elles sont parfois utilisées à d’autres fins comme pour gérer du matériel dans une entreprise. Le protocole LDAP, développé en 1993 par l’université du Michigan, avait pour but de supplanter le protocole DAP (servant à accéder au service d’annuaire X.500 de l’OSI), en l’intégrant à la suite TCP/IP. À partir de 1995, LDAP est devenu un annuaire natif (standalone LDAP), afin de ne plus servir uniquement à accéder à des annuaires de type X.500. LDAP est ainsi une version allégée du protocole DAP, d’où son nom de Lighweight Directory Access Protocol. [7] Ce dernier est un protocole de la couche application. Il fonctionne sur le port TCP 389. [3] II.2. QUE DÉFINIT LE PROTOCOLE LDAP ? Le protocole LDAP définit : Comment s’établit la communication client-serveur : commandes pour se connecter ou se déconnecter, pour rechercher, comparer, créer, modifier ou effacer des entrées. Les opérations de base : - Interrogation : search, compare - Mise à jour : add, delete, modify, rename - Connexion au service : bind, unbind, abandon. 6 Comment s’établit la communication serveur serveur : échanger leur contenu et se synchroniser (réplication service). Créer des liens permettant de relier des annuaires les uns aux autres (referral service). Le format de transport des données : ce n’est pas l’ASCII (comme pour HTTP, SMTP …), mais le Basic Encoding Rules (BER), sous une forme allégée (appelée LBER Lightweight). Les mécanismes de sécurité : les méthodes de chiffrement, et les mécanismes des règles d’accès aux données. [8] II.3. FONCTIONNEMENT DU PROTOCOLE LDAP Le protocole LDAP fonctionne en mode client-serveur. C’est-à-dire, les échanges entre le client et le serveur sont les requêtes/réponses Un client est un agent de l’annuaire DUA (Directive User Agent) Un serveur est un agent du système de l’annuaire DSA (Directory System Agents) Les requêtes et les réponses sont transmises par LDAP Une session LDAP consiste en une connexion de transport, une sécurité a la couche Transport (Transport Layer Security), une authentification SASL (Simply Authentification and Security Layer) et des messages LDAP TLS chiffre des messages LDAP venus de la couche application SASL permet d’assurer l’authentification entre le client et le serveur TLS et SASL sont un couple pour beaucoup d’application d’internet telle que LDAP, SMTP, POP, et IMAP. [9] II.4. ARCHITECTURE DE LDAP L’architecture du protocole LDAP (RFC 4511) est illustrée par la figure 2 : 7 Figure 2 Architecture de LDAP [9] Les échanges sont codes en BER (Basic Encoding Rules) de l’ASN.1 TCP utilise le port n° 389 pour le protocole LDAP [9] II.5. PRINCIPES ET CONCEPTS Le protocole d’accès à l’annuaire léger fonctionne (par défaut) sur le port le port TCP 389 pour LDAP et 636 pour LDAPS (LDAP over TLS/SSL). Un serveur LDAP agit en tant qu’intermédiaire entre une source de données et un client. Le client ne verra ni ne connaitra l’existence du stockage des données. En effet elles peuvent être dans un fichier plat ou dans une base de données. De plus, découpler les messages du stockage permet d’avoir plusieurs serveurs et un même système de stockage. [1] Figure 3 Serveur LDAP [1] 8 LDAP est asynchrone, c’est-à-dire que si le client émet plusieurs requêtes successivement, elles peuvent arriver dans un ordre diffèrent. [1] Figure 4 Protocole asynchrone [1] II.6. L’ARBORESCENSCENCE D’INFORMATION (DIT) LDAP présente les informations sous forme d’une arborescence d’informations hiérarchiques appelées DIT (Directory Information Tree), dans laquelle les informations, appelées entrées (ou encore DES, Directory Service Entry), sont représentées sous forme de branches. Une branche située a la racine d’une ramification est appelée racine ou suffixe (en anglais root entry). Chaque entrée de l’annuaire LDAP correspond à un objet abstrait ou réel (par exemple une personne, un objet matériel, des paramètres …). Chaque entrée est constituée d’un ensemble de paires clés/valeurs appelées attributs. Figure 5 Arborescence expliquée [1] 9 Les attributs des entrées Chaque entrée est constituée d’un ensemble d’attributs (paires clé/valeur) permettant de caractériser l’objet que l’entrée définit. Il existe deux types d’attributs : Les attributs normaux : ceux-ci sont les attributs habituels (nom, prénom …) caractérisant l’objet Les attributs opérationnels : ceux-ci sont des attributs auxquels seul le serveur peut accéder afin de manipuler les données de l’annuaire (date de modification …) Une entrée est indexée par un nom distinct (DN, Distinguished Name) permettant d’identifier de manière unique un élément de l’arborescence. Un DN se construit en prenant le nom de l’élément, appelé Relative Distinguished Name (RDN, c’est-à-dire le chemin de l’entrée par rapport à un de ses parents), et en lui ajoutant l’ensemble des noms des entrées parentes. Il s’agit d’utiliser une série de paires clé/valeur permettant de repérer une entrée de manière unique. Voici un tableau qui liste une série de clés généralement utilisées : [7] Tableau 1 Série de clés généralement utilisées [7] Clés Explication uid (userid) Il s’agit d’un identifiant unique obligatoire cn (common name) Il s’agit du nom de la personne Givenname Il s’agit du prénom de la personne sn (surname) Il s’agit du surnom de la personne o (organization) Il s’agit de l’entreprise dans laquelle la personne travaille u (organizational unit) Il s’agit du service de l’entreprise dans laquelle la personne travaille Mail Il s’agit de l’adresse de courrier électronique de la personne (bien évidemment) 10 II.7. QUE FOURNIT LE PROTOCOLE LDAP LDAP est un protocole d’annuaire standard et extensible. Il fournit : Le protocole permet d’accéder à l’information contenue dans l’annuaire, Un modèle d’information définissant le type de données contenues dans l’annuaire, Un modèle de nommage définissant comment l’information est organisée et référencée, Un modèle fonctionnel définissant comment on accède à l’information, Un modèle de sécurité définissant comment les données et l’accès sont protégés, Un modèle de duplication définissant comment la base est repartie entre serveurs, Des APIs pour développer des applications clientes, LDIF, un format d’échange de données. [8] II.7.1 MODÈLE DE NOMMAGE Comment référencer de façon unique les entrées et les données du DIT. RDN : Relative Distinguished Name Attribut unique qui distingue une entre des autres issues d’un même parent. DN : Distinguished Name Identifie de façon unique les entrées de l’arbre. S’obtiennent par agrégation des RDN suivant le chemin de l’entrée voulue jusqu’à la racine [10] Il définit comment les entrées de l’annuaire sont organisées et comment elles sont référencées. Structure arborescente contenant deux catégories d’objets : Les conteneurs : départ d’une nouvelle branche (nœud intermédiaire de l’arbre) Peuvent contenir des conteneurs ou des feuilles Généralement, une sous-organisation de l’organisation (zone géographique …) Les feuilles : elles représentent les données (généralement des machines, les utilisateurs …) [4] Voici un exemple d’un DN et RDN sous une DIT de racine "dc=exemple,dc=com": 11 Figure 6 Exemple d'un DN et RDN sous une DIT de racine "dc=exemple,dc=com" II.7.2 MODÈLE FONCTIONNEL Il décrit le moyen d’accéder aux données (syntaxe des requêtes) et les requêtes que l’on peut leur appliquer. Rappel des opérations de consultation / mise à jour : Operations d’interrogation : recherche (search) et comparaison (compare) d’entrées Opérations de mise-ajour des entrées de l’annuaire : add, delete, modify, rename Il n’y a pas d’opération de lecture d’une entrée. Pour connaitre le contenu d’une entrée, il est nécessaire d’écrire une requête qui pointe sur cette entrée. [4] Les opérations peuvent utiliser 3 critères : La Base spécifique le DN à partir duquel l’opération est réalisée. Pour une recherche sur la totalité de l’arbre il s’agira de la racine. 12 La PORTÉE est le nombre de niveaux sur lesquels l’action va être effectuée. Il existe 3 niveaux. SUB : l’action est effectuée récursivement à partir de la BASE sur la totalité de l’arborescence. ONE : l’action est effectuée sur un seul niveau inférieur à la BASE. BASE : l’action est effectuée uniquement sur la base spécifiée. Les FILTRES permettent d’effectuer des tests de correspondance lors d’une recherche. Le RFC 4516 décrit une méthode d’interrogation de l’annuaire par l’utilisation d’une URL dont la syntaxe est la suivante : ldap:://serveur[:port][/[base[?attributs à afficher][?[portée][?[filtre][?extensions]]]]]] Exemple pour rechercher tous les CN des étudiants de notre arbre : ldap://localhost:389/ou=etudiants,dc=univ-reims,dc=fr?cn?sub [3] II.7.3 MODÈLE D’INFORMATION LDAP présente les informations sous forme d’une arborescence d’informations hiérarchiques appelées DIT (Directory Information Tree). L’entrée est l’unité de base d’un annuaire (DES, Directory Service Entry). Elle correspond à une branche de l’adolescence. Chaque entrée correspond a un objet appel objectClass, par exemple une personne, un objet matériel, les paramètres … Cet objectClass est constitué d'un ensemble de paires clés/valeurs appelées attributs obligatoires ou facultatifs. Les types d'attributs sont des règles de codage et de correspondance, qui détermine les types donnés et les comparaisons à appliquer lors d'une recherche. Le schéma c'est l'ensemble des définitions d'objets et d'attributs qu'un serveur LDAP peut gérer. Cela permet de définir si un attribut peut avoir une ou plusieurs valeurs et/ou de les regrouper par objet (objectclass) pour définir s'ils sont obligatoires ou pas. [1] II.7.4 MODÈLE DE SÉCURITÉ Le modèle de sécurité décrit le moyen de protéger les données de l’annuaire des accès non autorisés. La sécurité se fait à plusieurs niveaux : 13 II.7.1 par l’authentification pour se connecter au service par un modèle de contrôle d’accès aux données par le chiffrement des transactions entre les clients et les serveurs ou entre les serveurs. [8] SERVICES DE SÉCURITÉ PROPOSES PAR LDAP Dans le domaine de la sécurité, LDAP propose des mécanismes pour gérer l’authentification et les habilitations des utilisateurs ainsi que la confidentialité des échanges. II.7.2 SERVICE D’AUTHENTIFICATION Plusieurs méthodes d’authentification correspondante à différents niveaux de sécurité sont offertes par la norme LDAP : La connexion anonyme (anonymous) généralement limitée à la consultation de parties restreintes de l’annuaire. L’authentification par identifiant/ mot de passe L’authentification par identifiant/ mot de passe avec hachage de ce dernier. L’authentification par identifiant/ mot de passe sur SSL. L’authentification par certificat X509. L’existence d’un annuaire LDAP allège donc, les applications de l’étape d’authentification en utilisant l’une des méthodes précédentes. [11] Figure 7 Authentification LDAP [11] Pour une meilleure sécurité, il vaut mieux utiliser la méthode d’authentification par identifiant / mot de passe sur SSL. Cette dernière veille à ce que les échanges soient sécurisés, d’une part, entre l’utilisateur et l’application, d’autre part, entre l’application et l’annuaire 14 LDAP. Pour ce faire, deux tunnels SSL sont nécessaires. Il faudra ainsi déployer un certificat sur l’application et sur le serveur LDAP. II.7.3 SERVICE D’HABILITATION On distingue deux types d’habilitations, habilitations concernant l’annuaire LDAP luimême et habilitations concernant le système utilisant l’annuaire. Cependant LDAP propose deux mécanismes pour la gestion des deux types d’habilitations. Le premier mécanisme gérant les habilitations sur les objets contenus dans l’annuaire consiste à utiliser des ACL (Access Control Lists) positionnées sur les nœuds de l’arbre LDAP et permet de définir les droits d’interactions des utilisateurs avec les branches intérieures. Le deuxième mécanisme consiste à définir des groupes et des rôles vis-à-vis les applications du système d’information. Un groupe LDAP permet de constituer des listes d’utilisateurs habilités à effectuer une action précise sur une application donnée. Les rôles aussi permettent de définir des habilitations, mais elles sont positionnées comme attributs dans la description des utilisateurs Les deux mécanismes sont illustrés par la figure ci-dessous [11] : Figure 8 Gestion des habilitations [11] 15 II.7.4 SERVICE DE CONFIDENTIALITÉ LDAP prend également en charge la sécurisation des échanges entre lui et ces clients, en utilisant le protocole SSL. [11] II.7.5 LES APIS Ces Bibliothèques de programmation permettent de créer des applications annuairecompatibles. Les APIs disponibles actuellement : U-M LDAP SDK – C (UMICH, Open-LDAP) Innosoft LDAP Client SDK (ILC-SDK) – C (InnoSoft) Netscape Directory SDK – Java, C (Netscape) PerLDAP Modules – Perl (Netscape) Net- LDAPapi – PERL (GNU) Java Naming and Directory Interface (JUNI) – Java (SUN) Active Directory Service Interface (ADSI) – COM (Microsoft) [8] II.7.6 LDIF LDAP Data Interchange Format (LDIF) est le standard de représentation des entrées sous forme de texte. Il est utilisé pour afficher ou modifier les données de la base suivant deux modes : faire des importations/exportations de la base, faire des modifications sur des entrées. Le format utilisé est l’ASCII. Toute valeur d’attribut ou tout DN qui n’est pas ASCII est codé en base 64. [8] II.8. CARACTÉRISTIQUES Mise à jour dynamique Souplesse des opérations de changements Organisation « simple » des données Sécurité d’accès potentielle Personnalisés [12] 16 Conclusion On a vu dans ce chapitre la présentation du protocole LDAP et que définit ce protocole. L’explication du fonctionnement du protocole LDAP. Montrer son architecture, ses principes et ses concepts. Décris que fournit ce protocole d’annuaires. Citer ses caractéristiques. 17 SECTION 2 : CONTEXTE I. CONTEXTE L’informatique est devenue indispensable pour les grandes entreprises, mais également les petites entreprises comme les PME et PMI. Toute entreprise devrait disposer d’ordinateurs pour que les employés, les étudiants dans les établissements scolaires puissent travailler, mais également d’un service d’annuaire (Active Directory) dans le but de centraliser l’administration des différents services de l’entreprise. L’Active Directory permet de recenser toutes les informations concernant le réseau, que ce soit les utilisateurs, les machines ou les applications. L’Active Directory constitue ainsi le noyau de toute l’architecture réseau et permet ainsi de faciliter l’accès aux applications et aux périphériques disponibles sur le réseau d’une entreprise. L’informatique est devenue un outil permettant d’améliorer la rentabilité, la productivité et d’optimiser le temps de réalisation des activités d’une entreprise. Cependant, la création des comptes d’annuaire et l’envoi du manuel d’utilisation des services offerts par l’entreprise de façon manuelle nécessitent dès lors un effort considérable de l’administration. C’est dans cette optique de pallier à ces problèmes que l’idée de notre projet de mémoire est née, avec pour objet de structurer la démarche d’une solution rapide visant à apporter satisfaction à l’administration des entreprises et des établissements scolaires. II. PROBLEMATIQUE Le problème principal que nous évoquons ici est relative à la difficulté et le temps nécessaire assez long pour crée des comptes dans l’annuaire active directory. Lorsqu’on sait que dans la plupart des cas, l’organisation dispose des informations nécessaires à la création de ces comptes dans une application en amont, alors on peut penser à la possibilité de récupérer ces informations pour les générer. La question centralise est donc celle de savoir quel peut être le moyen le plus adéquat de générer des comptes de l’AD sur la base des informations récupérées dans une autre application quel que soit la plate-forme. 18 Au vu de tout ce qui a été évoqué précédemment, il nous a semblé opportun de se poser les questions suivantes : Comment permettre aux entreprises de faciliter la création des comptes d’annuaire à partir des informations existantes ? Comment réduire considérablement le temps passé pour la création des comptes d’annuaires ? Comment faciliter la communication des différents services offerts par l’entreprise aux nouveaux arrivants ? III. CONSEQUENCE Comme conséquences, les étudiants n’aurons par : Accès aux cours dispensée en ligne Accès aux différents services mise à leurs dispositions (Office 365, WIFI, …) Connaissances des informations mise à leurs dispositions par leur tutelle IV. OBJECTIFS VISES Dans l’optique d’une gestion de projet par objectif, nous envisageons d’employer des objectifs SMART afin d’être Simple, Mesurable, Ambitieux, Réaliste et Temporel dans notre projet. IV.1 OBJECTIF GENERAL Notre objectif générale durant ce projet sera de : proposer une solution pour améliorer la communication et la création des comptes d’annuaire sur la base des informations existante en amont. IV.2 OBJECTIF SPECIFIQUES Nos objectifs tout au long de ce travail seront donc : D’appréhender le concept et de comprendre le fonctionnement d’un annuaire de type AD (Active Directory) ; De concevoir et de modéliser la solution ; D’implémenter un système informatique, pour l’amélioration de création des comptes d’annuaire dans les entreprises ; 19 V. INTERET DU PROJET L’intérêt de notre projet est de permettre aux entreprises de : Faciliter la création automatique des comptes d’annuaire des employés et des étudiants pour les établissements scolaires ; Gain de temps ; Convivialité dans le travail ; Faciliter la communication par mail sur les différents services proposés par l’entreprise via l’envoi de mail à la création de comptes d’annuaire d’un employé ; 20 CHAPITRE 2 : CADRAGE DU THÈME 21 SECTION 1 : ÉTUDE CRITIQUE ET ORIENTATION I. PRESENTATION DE L’EXIST ANT Nous ne saurions débuter ce travail sans avoir une idée claire et précise sur l’existant. Nous avons une idée générale de l’existant au sein de IUC car nous y exerçons aux services du numérique éducatif ou nous avons observé comment le processus de création des comptes d’annuaires se faisait et a traves des échanges avec le responsable du service sur cette tâche. Il en ressort de nos observations et échange que : La création des comptes d’annuaires des étudiants et du personnel se fait de façon manuel Il y’a beaucoup de plainte sur les comptes créer car certains étudiants ne parviennent pas accéder aux services mise à leurs disposition du fait que : leurs informations sont erronés, leurs comptes n’existe pas dans l’annuaire Les étudiants n’ont pas connaissance des services mise à leurs dispositions par l’institut L’existant ne se limitant pas exclusivement a IUC, nous avons pensé à explorer les solutions informatiques existantes. II. CRITIQUE DE L’EXISTANT La solution manuelle en place à IUC consiste en une simple réorganisation du système en reconduisant les qualités tout en conservant le traitement manuel. Cette proposition qui ne garantit en rien la rapidité et la fiabilité dans l’exécution des taches (création des comptes d’annuaire, …), occasionnera des erreurs de manipulation et fatiguera le personnel dans le traitement des informations. Ce fonctionnement possède néanmoins des avantages et des inconvénients. Avantage : Dépenses réduites dans le matériel informatique ; Garantie de fonctionnement. Inconvénients : Les procédures de créations des comptes d’annuaires restent toujours manuelles et la fatigue humaine peut commettre les erreurs de temps à autre ; 22 III. La durée d’exécution très longue allant pratiquement a 3 mois SOLUTIONS EXISTANTES ET NOUVELLE ORIENTATION Tableau 2 Solutions existantes [13] Critères JXplore phpLDAPadmin LDAP Synchronization Connector LDAP User Manager LDAP Administrator Très coûteux non non non non oui Création de compte oui oui oui oui oui Mise à jour oui oui non non oui Déplacement automatique des comptes existant non non non non non Gestion de mot de passe oui oui oui oui oui Envoie de mail non non non oui non Synchronisation à partir d’une source existante non non oui non non Personnalisable non non non non non Multiplateforme oui oui non oui non Graphique oui oui non oui oui Niveau de compétence requis élevé non non oui non non Au vue du tableau précèdent, il apparait que les solutions déjà existantes ne sont pas assez adéquates ou bien incomplètes pour la plupart (JXplore, phpLDAPadmin, LDAP User Manager), couteux (LDAP Administrator) et difficile à appréhender pour celle digne d’intérêt (LDAP Synchronisation Connector). Etant donné que le système actuel est encore assez rudimentaire et ne répond pas aux attentes, les principaux acteurs rencontrent d’importantes difficultés dans l’exercice de leurs tâches quotidiennes, diminuant par conséquent leur productivité. Ainsi pour optimiser la productivité des acteurs de ce système, il est donc important de mettre sur pied un système entièrement personnalisable, facile d’utilisation et adaptée aux besoins requis. 23 SECTION 2 : CAHIER DE CHARGES Le cahier des charges est un document qui décrit avec précision les besoins des utilisateurs et les conditions nécessaires à la réussite d’un projet. Il est à la fois un outil de communication et de description du projet pour éviter la production des résultats inadéquats. I. BESOINS Le besoin exprime ici est celui de concevoir une passerelle interopérable de génération des comptes d’annuaire a partie d’une API pour permettre de : Créer automatiquement les comptes d’annuaire des étudiants a partie des informations existante en amont Organiser les comptes crée en a année académique et les grouper par classe Déplacer automatiquement lors de la création les comptes déjà existant dans l’annuaire vers le nouvel emplacement (nouvel année académique > nouvelle classe > nouveau groupe) Envoie automatique du manuel d’utilisation des différents services offert par l’institut aux étudiants a la création des comptes d’annuaire II. OBJECTIFS Afin de répondre au mieux aux besoins, nous avons pu résumer les attentes spécifiques selon trois axes d’organisation, à savoir : l’axe fonctionnel, l’axe structurel et l’axe ergonomique. II.1. AXE FONCTIONNEL L’axe fonctionnel montre des actions qui amènent des possibilités supplémentaires a notre système, nos fonctionnalités sont groupées en catégories comme suit : Gestion des années académiques Création et consultation Gestion automatique des classes Création et consultation Gestion automatique des comptes étudiants Création, modification et consultation Consulter les comptes par groupe Envoi automatique du manuel d’utilisation par mail aux différents comptes crée Rapports 24 II.2. AXE STRUCTUREL L’architecture doit être une architecture n-tiers base sur 4 niveaux à savoir : La couche cliente représentée par un navigateur La couche de présentation représentée par un serveur web La couche traitement représenté par un serveur de d’application La couche d’accès aux donnés représentée par un serveur de base de données II.3. AXE ERGONOMIQUE La disposition des éléments sur l’écran doit garantir à l’utilisateur une souplesse afin d’améliorer à coup sûr l’expérience utilisateur. Qu’importe la taille et la disposition de l’écran, l’application doit rester conforme. III. CRITERES D’ACCEPT ATION Les critères d’acceptation (ou acceptance criterias en anglais) sont rédiges par le Product Owner (parfois en collaboration avec l’équipe de développement) et accompagnent chaque user story : ils représentent un ensemble de conditions que la story doit satisfaire pour être considérée comme complète et terminée. Pour formaliser les critères d’acceptations, les PO utilisent souvent une structure inspirée du langage Gherkin dédie a la description de comportements logiciels. Cette structure s’appelle GIVEN-WHEN-THEN (Etant donne – Quand – Alors) : GIVEN : l’état du logiciel avant l’exécution de la user story WHEN : un évènement qui déclenche un processus THEN : l’état du logiciel après l’exécution. [14] Les critères d’acceptabilité de notre système sont les suivants : Utilisabilité Ou encore aptitude à l'utilisation est définie par la norme ISO 9241-11 comme « le degré selon lequel un produit peut être utilisé, par des utilisateurs identifiés, pour atteindre des buts définis avec efficacité, efficiences et satisfactions, dans un contexte d'utilisation spécifié ». [15] 25 COMPRÉHENSIBILITÉ Ce principe de compréhension touche particulièrement les personnes ayant des limitations cognitives, mais rendra aussi les contenus web plus accessibles aux autres personnes ayant des limitations fonctionnelles ainsi qu’à tous les utilisateurs sans limitations. ROBUSTESSE Le principe de robustesse vise à ce que les contenus soient compatibles avec une large variété de navigateurs ou d’argents utilisateurs et particulièrement avec les technologies d’assistance utilisées par les personnes ayant des limitations fonctionnelles. IV. PLANNING ET COUTS IV.1 EVALUATION DU COUT DE REALISATION DU PROJET IV.1.1 RESSOURCES HUMAINES On désigne ici les personnes intervenant directement pour la réalisation du projet du point de vue rédaction des documents liés au projet et à sa réalisation. Tableau 3 : Ressources humaines Noms et prénoms Rôles M. TEKOUGJOU François Xavier Encadreur académiques Pr. JAZET Pierre Michel Superviseur M. TEUKEU Hypolithe Encadreur professionnel GNINTEDEM Noutsa Jospin Etudiant MASTER II SIGL/IUC IV.1.2 RESSOURCES MATERIELLES On désigne par ressource matérielle l’ensemble des biens physiques qui sont utilisés par l’entreprise pour mener à terme ses activités 26 Tableau 4 : Ressources matérielles Désignation Caractéristique Quantité Prix unitaire (FCFA) Ordinateur (portable) SSD 1To, RAM 8Go, CORE 01 i7 350000 350 000 Serveur Windows local SSD 500Go, RAM 8Go, CORE i5 01 0 0 Serveur Linux local SSD 100Go, RAM 8Go, CORE i5 01 0 0 350 000 Montant Total IV.1.3 Prix total (FCFA) RESSOURCES LOGICIELLES Tableau 5 : Ressources logicielles Nom Editeur Version Licence Fonction Windows serveur Windows 2012 R2 Payant Système 100 000 d’exploitation Ubuntu Ubuntu Foundation 20.04 Gratuit Système 0 d’exploitation Apache Apache Software Foundation 2.0 Gratuit Serveur web 0 Intellij IDEA Jetbrains 2019.3 Payant IDE 250 000 Gliffy Rogue Wave Software Propriétaire Création graphique 0 Gantt Project GanttProject Team 2.8.11 Gratuit Gestion des taches 0 StarUML MKLab 3.2.1 Propriétaire Conception et 42 000 modélisation Montant Total Prix (FCFA) 392 000 Bilan La méthode utilisée pour l’estimation des couts du projet est la méthode comparative ou analogique. En effet cette méthode est la plus utilisée lorsqu’un projet similaire a déjà été réalisé. L’estimation prend en compte les différences majeures avec les projets de même type, 27 la base des couts de l’entreprise et la variation des couts en fonction de la devise (FCFA, EURO, DOLLAR, …). Cette méthode d’estimation a une marge d’erreur de plus ou moins 10%. Pour une estimation plus précise du projet, nous couplons cette méthode avec la méthode des trois (03) points qui consiste a : 1. Sélectionner les personnes ayant une bonne connaissance du sujet 2. Leur demander de fournir individuellement leurs estimations liées au projet 3. Déterminer l’estimation (E) en fonction de l’estimation la plus pessimiste (PP), l’estimation la plus optimiste (PO) et l’estimation la plus probable (PB) suivant la formule suivante : E = (PO + 4*PB + PP)/6. [16] NB : il est important de noter que l’utilisation de la méthode des trois points est inappropriée si l’estimation pessimiste est trop éloignée de l’estimation probable. Ainsi, on a le tableau d’estimation des couts suivant : Tableau 6 : Bilan Charges lies au projet Coût (FCFA) Ressources matérielles 350 000 Ressources logicielles 392 000 Autres charges 150 000 Total 892 000 Main d’œuvre (30% du cout du projet) 267 600 Total 1 159 600 Imprévus (10% du cout du projet) 115 960 Cout total du projet IV.2 PLANIFICATION DU PROJET IV.2.1 PRODUCT BREAKDOWN STRUCTURE (PBS) 1 275 560 Le Product Breakdown Structure est une décomposition organisée et cohérente du projet en produits ou module et sous-produits ou sous-modules. C’est l’expression exacte de tout (matériel, logiciel), ce qui doit être accompli pour arriver à la fin du projet. 28 Figure 9 : Product Breakdown Structure IV.2.2 ORGANIGRAMME DES TACHES (WORK BREAKDOWN STRUCTURE) L’organigramme des taches nous permettra de présenter la répartition des tâches sur des intervalles de temps bien délimité. Le tableau 7 pages 29 met en exergue l’organigramme des taches liées au projet. Tableau 7 : Organigramme des taches Date Tache Responsable Résultats attendus Moyens Du 10/03/2021 Attribution du thème GNINTEDEM, Thème du projet Humains Validation du thème GNINTEDEM, Thème définitif du projet Humains Au 12/03/2021 M. TEKEU (03 jours) Du 13/03/2021 Au 15/03/2021 Pr. JAZET (02 jours) Du 16/03/2021 Au 08/05/2021 (47 jours) Du 10/05/2021 Au 19/05/2021 (09 jours) M. TEKOUGJOU, Recherche et collection des informations GNINTEDEM, Existant Humains et matériels Rédaction du cahier des charges GNINTEDEM, Cahier des charges Humains M. TEKEU, M. TEKOUGJOU, Pr. JAZET 29 Du 20/05/2021 Au 03/06/2021 (13 jours) Du 04/06/2021 Au 22/06/2021 (16 jours) Du 23/06/2021 Au 24/06/2021 Réalisation et validation du Template web GNINTEDEM, Template web Humains et matériels Développement, GNINTEDEM, intégration des M. TEKEU services et test Application web Humains et matériels Déploiement de la solution GNINTEDEM, Utilisation de la plateforme en entreprise Humains et matériels Formation des utilisateurs GNINTEDEM, Formation du personnel Humains et matériels Rédaction du mémoire GNINTEDEM, Rapport de mémoire Humains et matériels Rédaction du PowerPoint GNINTEDEM, Powerpoint de présentation Humains et matériels M. TEKEU (02 jours) Du 25/06/2021 Au 26/06/2021 (02 jours) Du 10/05/2021 Au 03/07/2021 (48 jours) Du 05/07/2021 Au 08/07/2021 (04 jours) IV.2.3 DIAGRAMME DE GANTT Conçu à partir du Work Breakdown Structure (WBS), le diagramme de Gantt donne une vue globale du projet et permet de visualiser dans le temps les diverses taches. Figure 10 Diagramme de GANTT 30 IV.3 LIVRABLES Le livrable désigne tout composant matérialisant le résultat d’une prestation de réalisation a la direction des systèmes d’information, c’est-à-dire toute production émise par le titulaire au cours du projet : document, courrier, module de code logiciel, dossiers de tests, application intégrée. Le livrable peut faire l’objet d’un bordereau de livraison, qui liste le contenu, la date, le fournisseur, le client, l’approbation par le client, et autre métadonnée. Une fois les objectifs atteints, les livrables seront les suivants : Le cahier de charges, Le document d’analyse, Le document de conception, Le document de réalisation, La version beta de l’application, Le guide d’installation. 31 CHAPITRE 3 : METHODOLOGIE ET OUTILS SECTION 1 : MOTIVATION ET CHOIX METHODOLOGIQUE I. MOTIVATION Les nouvelles technologies de l’information et de la télécommunication permettent d’intégrer des processus et fonctionnalités dans les entreprises. Ces technologies qui étaient jadis une exclusivité des grandes entreprises, sont maintenant à la portée de petites et moyennes entreprises. Ce mouvement a un impact sur la gestion globale de l’entreprise, sur sa vision et également sa stratégie. De ce fait, pour solutionner notre problématique, il est judicieux pour nous de de bien faire le choix des outils et modèle adéquat, afin de rester productif. II. CHOIX DU MODELE DE CYCLE DE VIE Un modèle de cycle de vie est une représentation abstraite d’un ensemble structure d’activités nécessaires pour le développement d’un logiciel. Ils en existent une panoplie, différents par la taille de l’équipe engagée dans le projet, les besoins du client, le temps imparti et le budget alloue. Cependant, toutes sont structurées pour permettre la production d’un logiciel de qualité, fidèle aux spécifications de départ. Entre spécification et conception, implémentation, validation, amélioration ou maintenance, les modelés de processus visent à accroitre la productivité des équipes de développement. Le tableau ci-dessous essaie de présenter différents modèles de processus parmi les plus connus avec leurs avantages et inconvénients. [17] Tableau 8 Quelques modèles de cycle de vie Modeles Avantages Inconvenients Cascade Simple de compréhension et d’utilisation, facile à manager, les étapes s’exécutent une à la fois, bonne documentation des résultats Aucun produit logiciel avant la fin du cycle, risque et incertitude élevé, inadapté pour les projets complexes et orientes objets, difficulté de mesure de l’évolution V Très discipline, marche bien pour Risque et incertitude élevé, non les petits projets, simple et facile adéquat aux projets complexes et d’utilisation orientes objet, non adéquat pour les 32 projets comportant un haut risque de changement Spirale Possibilité d’adaptation en cas de changement des spécifications, le développement peut être divisé en petites parties, meilleurs gestion des risques Gestion plus complexe du projet, à la fin du projet n’est pas très vite perceptible, onéreux pour de petits projets, la spirale peut ne pas s’achever Itératif Résultat périodiques, possibilité de développement parallèle, faible cout de changement, test et debugage continu, meilleure analyse des risques Requiert d’importantes ressources, difficile de changer les spécifications initiales malgré la facile adaptation au changement, requiert beaucoup d’attention managériale, incompatible aux petits projets RAD (Rapid Application Development) Favorable au changement de spécifications, mesure de l’évolution, évolution rapide en cas d’utilisation de puissants outils, productifs avec faible effectif, temps de développement réduit, encourage la réalisation des composants Dépend de l’habilite technique de l’équipe à détecter des outils puissants, seul les systèmes modulables peuvent être développes avec ce modèle, requiert des développeurs et concepteurs hautement qualifiés, complexité de management, adéquat pour les systèmes orientes composant et scalables Scrum Approche très réaliste pour le développement logiciel, encourage le travail en équipe, possibilité de développement et de démonstration rapide des fonctionnalités, ressources requises minimales, favorable au changement de spécifications, facile à manager Pas favorable à la gestion de dépendances complexes, risques élevé de maintenance et d’extensibilité, dépend de l’interaction avec le client, manque de documentation donc difficulté de transfert technologique a une nouvelle équipe Au vue de ce tableau, on observe que, la composition de l’équipe engagée dans le développement, le temps imparti, le budget, les contraintes de livraison et les compétences techniques sont importantes pour fixer le choix du modèle de processus à adopter. En effet, pour la réussite de ce projet, le travail en équipe et les démonstrations ont été fortement sollicités pour fournir une solution de qualité. De plus le cadre de travail doit permettre de répondre à des problèmes complexes, tout en livrant de manière productive et créative des produits de la plus grande valeur possible. 33 Cycle de vie et assurance qualité étant fortement lies, nous pouvons donc pencher pour le modèle Agile et plus précisément la méthode SCRUM qui semble s’accommoder à ces contraintes mais requiert néanmoins énormément de temps dans la réalisation du projet. III. PRESENTATION DE LA METHODOLOGIE III.1 METHODOLOGIE ADAPTE SCRUM Suite à une étude comparative, nous avons remarqué que les approches agiles sont plus adaptées à notre projet que toutes les approches traditionnelles. Bien qu’agile soit l’approche choisi, il faut noter que cette approche contient plusieurs méthodes parmi lesquelles : Scrum/XP Hybrid Agile Unified Process (AgileUP) Custom Hybrid (multiple méthodologies) Scrumban Itérative Development Scrum … Cependant, la méthodologie Scrum de l’approche agile est celle qui a retenu notre attention en raison des points suivant : Scrum convient aux équipes ayant un nombre de développeurs réduits. Ceci est notre cas. Le client est impliqué dans le développement de l’application : la consultation du client est nécessaire dès l’achèvement d’une tache. La progression des taches s’effectue pendant une durée de développement courte. III.2 PRESENTATION DE SCRUM La méthodologie Scrum a été conçue pour améliorer grandement la productivité dans les équipes auparavant paralysées par les méthodologies plus lourdes. Le principe de base de Scrum est de focaliser l’équipe de façon itérative sur un ensemble de fonctionnalités à réaliser, dans des itérations de durée fixe allant d’une a quatre semaines appelées SPRINT. Chaque sprint possède un but à atteindre, défini par le directeur de produit, a partie duquel sont choisies les fonctionnalités à implémenter dans le sprint. Un sprint abouti toujours sur la livraison d’un produit partiel fonctionnel. Pendant ce temps, le Scrum Master a la charge de 34 réduire au maximum les perturbations extérieures et de résoudre les problèmes non techniques de l’équipe. Ce processus est illustré par la figure suivante : Figure 11 Processus Scrum Source : https://upload.wikimedia.org/wikipedia/commons/8/89/VueGlobaleScrum.png III.2.1 LES ACTEURS On distingue plusieurs acteur, dont : Le directeur de produit encore appelé Product Owner est le représentant des clients et des utilisateurs, et fait partie également de l’équipe. Le Scrum Master veille à l’application de la méthodologie Scrum au sein de l’équipe. L’équipe qui contribue à la réalisation des fonctionnalités du projet (planification, développement, test et documentation). A noter que les membres de l’équipe travaillent tous ensemble : chaque membre peut faire ainsi des propositions, exprimer des idées et écouter les autres. III.2.2 LE PROCESSUS Tous les critères ou exigences du produit sont regroupées dans des journaux ou backlogs dont on distingue 2 types : Le backlog de produit ou « Produit backlog » en français qui regroupe la liste des fonctionnalités du produit. Le backlog de sprint ou « sprint backlog » en fonction des fonctionnalités du produit, regroupe la liste des taches qui devra être réalisées à l’itération en cours. Chaque tache 35 aurait fait l’objet d’une estimation préalable de charge par l’ensemble des membres de l’équipe afin d’estimer au mieux les taches qui peuvent réaliser un sprint. III.2.3 PLANIFICATION Le sprint : dès le début d’un projet, la première planification permet de définir le périmètre de chaque itération appelé sprint. Chaque sprint dure quelques semaines et regroupe une liste de taches (défini dans le backlog). La mêlée quotidienne : de plus, elle est rythmée par ce qu’on appelle une mêlée quotidienne d’un quart d’heure qui consiste chaque jour avec les membres de l’équipes ainsi que le directeur de produit de se tenir au courant de l’avancement du projet, notamment en : Faisant le point sur le travail effectue la veille par chacun Définissant les taches qui sont réalisées durant la journée Résolvant les éventuels problèmes qui avaient ou qui pourraient être rencontre par chacun Le développement suit un processus un processus itératif et incrémental : de nouvelles fonctionnalités sont rajoutées au produits. III.2.4 LA REVUE DE SPRINT La fin d’un sprint aboutit à la réalisation d’un produit avec des fonctionnalités partielles, avec la documentation associée. Dans la plupart des cas, cela conduit à une revue de sprint consistant à faire une démonstration de la réalisation du sprint devant le client afin de valider le travail réalisé et d’avoir un retour pour éventuellement ajuster le backlog du produit. III.3 CHOIX DE LA METHODE D’ANALYSE Pour programmer une application, il ne convient pas de se lancer tète baissée dans l’écriture du code : il faut d’abord organiser ses idées, les documenter, puis organiser la réalisation en définissant les modules et étapes de la réalisation. Cette démarche antérieure à l’écriture que l’on appelle modélisation a pour produit un modèle. Le tableau 9 page 37 illustre les méthodes d’analyse les plus connues. 36 Tableau 9 Méthodes d’analyse [18] Concept Description Merise (Méthode d’Etude et de Repose sur 5principes fondamentaux qui ont Réalisation Informatique par les précède à son élaboration (l’approche systémique, Systèmes d’Entreprise) les cycles de construction des systèmes d’information, l’approche fonctionnelle, la vision duale des données-traitement et approche du général au particulier). UML (Unified Modeling Language) Langage graphique de modélisation de données et de traitements SADT (Structured Analysis and Démarche systémique de modélisation d’un Design Technique) système complexe ou d’un processus opératoire NIAM Méthode d’analyse et de conception pour les systèmes d’information OMT (Object Modeling Technique) Méthode qui permet de couvrir l’ensemble des processus d’analyse et de conception en utilisant le même formalisme. L’analyse repose sur les trois points de vue : statique, dynamique, fonctionnel. Donnant lieu à trois sous modèles. BOOCH Méthode qui permet de faciliter l’implémentation de programmes dans des langages de programmation orientée objet, ainsi que de représenter les différentes phases du développement d’un projet. OOSE Méthode de développement crée par Ivar Jacobson, caractérisée par la définition des « use cases » (cas d’utilisation). Elle a été intégrée dans UML à partir de 1995 2TUP Processus de développement logiciel qui bénéficie de la maturité de nombreuses méthodes telles q’OOSE, BOOSH, OMT. 37 Les méthodes de modélisation ou d’analyse ont l’objectif commun de permettre que le système soit compréhensible par toutes les parties prenantes actuelles et futures du projet. Ainsi nous avons donc choisi le langage UML pour la richesse des détails conceptuels qu’il offre et sa facilite d’interprétation. De plus, il garantit une bonne compréhension de vues du système à mettre sur pied. 38 39 CHAPITRE 4 : ANALYSE ET CONCEPTION DE LA SOLUTION INFORMATIQUE Section 1 : Analyse approfondie Section 2 : Modélisations Conceptuelles Section 3 : Architecture générale de l’application CHAPITRE 5 : RÉSULTATS OBTENUS ET DISCUSSION Section 1 : Outils et méthodes d’implémentation Section 2 : Présentation de la solution réalisée et test Section 3 : Évaluation des résultats obtenus et impact sur l’entreprise CONCLUSION GÉNÉRALE 40 BIBLIOGRAPHIE [1] Antoine Bouët, «OpenClassrooms»: https://openclassrooms.com/fr/courses/2257706presentation-du-concept-dannuaire-ldap. Consulté le 13/05/2021 à 20h50 [2] F.Latti ET N.Hammadi, «Configuration et administration d’un annuaire LDAP avec un serveur de messagerie électronique en utilisant l’outil phpLDAPadmin», PFC, université Abou Bakr Belkaid-Tlemcen. Consulté le 13/05/2021 à 21h32 [3] C.Forget, «OpenLDAP Implémentation d’un annuaire LDAP,»: https://docplayer.fr/45740556-Openldap-implementation-d-un-annuaire-ldap.html. Consulté le 14/05/2021 à 9h28 [4] A.Guermouche, «Administration réseau Annuaire LDAP,» : https://docplayer.fr/16357588Administration-reseau-annuaire-ldap.html. Consulté le 14/05/2021 à 10h17 [5] F.Lau et Ph.Dajean, «LE PROJET D'ANNUAIRE D'ENTREPRISE,» CIGREF, 2005. [6] N.HOUSSET, «IMPLEMENTATION D’UNE AUTHENTIFICATION LDAP DANS SAS» : https://www.sas.com/content/dam/SAS/fr_fr/doc/supportclients/articles/us2016_q3_implementation-d-une-authentification-ldap-dans-sas.pdf. Consulté le 15/05/2021 à 20h20 [7] «Le protocole LDAP» : https://www.commentcamarche.net/contents/525-le-protocole-ldap. Consulté le 19/05/2021 à 10h32 [8] C.Duvallet, «Introduction aux annuaires LDAP,» : http://litis.univlehavre.fr/~duvallet/enseignements/Cours/M2MATIS/M2SRO-LDAP.pdf. Consulté le 19/05/2021 à 18h14 [9] A.WEI, «LDAP (Lighweight Directory Access Protocol)» : https://docplayer.fr/19167656-Ldaplighweight-directory-access-protocol.html. Consulté le 19/05/2021 à 18h51 [10] B.Métrot, «Rappels LDAP,» : http://anf2012.mathrice.fr/lib/exe/fetch.php?media=rappelsldap.pdf. Consulté le 20/05/2021 à 16h32 [11] Y.ADJAOUD et T.KEHOUL, Authentification unique avec CAS et LDAP, Béjaïa, MPE Option : http://www.univbejaia.dz/xmlui/bitstream/handle/123456789/9289/Authentification%20unique%20av ec%20CAS%20et%20LDAP.pdf?sequence=1&isAllowed=y. Consulté le 24/05/2021 à 20h51 [12] N.Foukia et M.Hoerdt, «Lightweight Directory Access Protocol - LDAP,» 2017- 2018. [En ligne]. Available: https://hepia.infolibre.ch/reseauxII-2017-2018/cours/RA-LDAP-2017-2018.pdf.Consulté le 24/05/2021 à 21h28 41 [13] «List of LDAP software» : https://en.wikipedia.org/wiki/List_of_LDAP_software. Consulté le 27/05/2021 à 20h55 [14] HUGO GEISSMANN, «Criteres d’acceptation» : https://blog.thiga.co/glossaire/criteresdacceptation/#:~:text=Les%20crit%C3%A8res%20d'acc eptation%20(ou,consid%C3%A9r%C3%A9e%20comme%20compl%C3%A8te%20et%20ter min%C3%A9e. Consulté le 28/05/2021 à 19h48 [15]« Utilisabilite » :https://fr.wikipedia.org/wiki/Utilisabilit%C3%A9#:~:text=L'utilisabilit%C3%A9 %2C%20ou%20encore%20aptitude,contexte%20d'utilisation%20sp%C3%A9cifi%C3%A9%20%C2 %BB. Consulté le 29/05/2021 à 05h11 [16] « Three-point estimation » : https://en.wikipedia.org/wiki/Three-point_estimation. Consulté le 29/05/2021 à 12h11 [17] « Tutoriel point, SDLC Models » : https://www.tutorialspoint.com/sdlc/index.htm. Consulté le 04/06/2021 à 12h11 [18] Wikipedia, Methodes d’analyse et de conception, https://fr.wikipedia.org/wiki/M%C3%A9thodes_d%27analyse_et_de_conception. Consulté le 08/06/2021 à 08h49 Brian Desmond, Joe Richards, Robbie Allen, Alistair G. Lowe-Norris ; Active Directory: Designing, Deploying, and Running Active Directory ; 5e édition ; 710 pages. Balaji Varanasi ; Practical Spring LDAP: Enterprise Java LDAP Development Made ; 204 pages. 42
