Vous êtes sur la page 1sur 65

Chap1:Présentation de l’Entreprise et du Sujet

1.1 Présentation de la SONATEL


1.1.1 Historique
La Société Nationale des Télécommunications a été créée le 23 Juillet 1985 par la
fusion de l’Office des Postes et des Télécommunications et de Télésénégal. La
Société Nationale des Télécommunications (SONATEL) est le premier opérateur de
télécommunications au Sénégal. Devant la nécessité de s’adapter au nouvel
environnement du monde des télécommunications, la SONATEL modifie ses statuts
en procédant à une ouverture de son capital en 1995.
En septembre 1996, SONATEL innove en mettant à la disposition de ses clients un
système de téléphonie mobile. Il est devenu en 1997 une société privée en s’alliant à
France Télécom qui possède actuellement 42% de son capital.
En 1999, une filiale Sonatel Mobiles a été créée avec la marque Alizé. Cette filiale
gère toutes les offres mobiles du groupe.
En 2001, une autre filiale Sonatel Multimédia chargée du développement de l’activité
Internet sous la marque Sentoo est créée.
Sonatel commence à s’imposée comme un leader régional rayonnant sur le Mali en
2002, la Guinée Bissau et la Guinée Conakry en 2007.
En 2003, l’entreprise consolide sa croissance en mettant en place reporting et outils
d’analyse prédictive.
En 2004, la filiale Sonatel Business Entreprises spécialisée dans les réseaux privés
d’entreprise est créée.
En Novembre 2006, le groupe Sonatel adopte la marque commerciale Orange et
adopte un nouveau logo formé par la ligature de deux mots dit « et commercial »,
symbole de sa fidélité avec tous ses partenaires.
Actuellement Sonatel est l’opérateur dominant au Sénégal et au pays sous régionaux.
Figure 1.1:Évolution de la Sonatel
1.1.2 Les Différents activités de la Société
Le Groupe Sonatel offre des solutions globales de télécommunications dans les
domaines de la téléphonie fixe et mobile, de l’Internet, de la télévision et des données
au service des particuliers et des entreprises.
Avec les technologies 4G et 4G+, le Groupe offre à ses clients la connectivité au très
haut débit mobile surtout avec l’avènement de la fibre.
1.1.3 Organisation de l’entreprise
La direction de la Sonatel est composée d’une direction générale, d’une direction
générale adjointe, des directeurs des filiales (Orange Mali, Orange Guinée, Orange
Bissau) et de 15 directions opérationnelles composées chacune de plusieurs
départements, services et centres techniques.

Figure 1.2:Organigramme de la Sonatel

1.1.3.1 La Direction des Ressources et Plateformes de Service


(DRPS)
C’est la direction qui est en charge de la production et de l’exploitation de réseau.
Elle est scindée en cinq pôles de direction:
 Le pôle d’Intervention (DINT)
 Le pôle d’Exploitation (DEX)
 Le pôle d’Etude et Planification (DEP)
 Le pôle de Transformation et de Pilotage de la Performance (TPP)
 Le pôle DI (Direction Ingénierie)
1.1.3.2 Présentation de DINT
Le pôle Intervention (DINT) est composé de quatre (4) départements:
 Le Département Pilotage et Gestion des Ressources (PGR),
 Le Département Interventions Réseaux Dakar (IRD),
 Le Département Interventions Réseaux Régions (IRR)
 Le Département Interventions Clients Fibre (ICF).
1.1.3.3 Le Département Interventions Clients Fibre (ICF)
Le département Interventions Clients Fibre a été créé le 1er décembre 2017 suite au
lancement du projet FTTH. Il a pour devise : « Tout ce qui se fait, peut mieux se faire
». Sa zone d’impact étant exclusivement la région de Dakar, ICF a pour mission :
 D’activer/désactiver les services à l’aide du réseau de gestion, de la livraison
de
lignes FTTH des clients B2C (D’entreprise à Consommateur)
 D’assurer la recette et la maintenance de l’infrastructure Fibre.
Ce département est constitué de quatre (4) services qui sont :
 Maintenance et Recette Fibre (MRF)
 Pilotage Production Clients Fibre (PPCF)
 Centre d’Intervention Clients Fibre (CICF)
 Pilotage Dérangements Clients Fibre (PDCF)
1.1.3.4 Le Service de Pilotage Production Clients Fibre
Le Service de Pilotage Production Clients Fibre pilote l’installation du réseau d’accès
par fibre optique chez le client.Il assure aussi la configuration des services d’internet,
de la télévision et de la téléphonie .
1.2 Présentation du Sujet
1.2.1 Contexte
A mesure que les entreprises se développent et adoptent différents logiciels
d'application pour optimiser la gestion et l’efficacité des données, l’intégration
manuelle des informations devient plus difficile en raison d'une documentation
excessive. C'est pourquoi de nombreuses entreprises utilisent l’intégration
d'applications d'entreprise pour automatiser l’échange de données entre les différents
composants du système d’informations d’une entreprise.
L' intégration de données entre applications est une solution permettant l’échange de
données de sources hétérogènes en temps réel.
L'objectif est de faciliter l'exploitation des données pour les utilisateurs afin
d'augmenter l'efficacité et la productivité globale de l'entreprise.
1.2.2 Problématique
Dans le Département de Pilotage Production Clients FTTX(Fiber To The X) de
nombreuses applications sont mise en place pour effectuer la configuration des
services d’internet,de télévision et de téléphonie offerte par la technologie FTTX .Les
pilotes utilisent les mêmes données sur des applications différentes après s’être
authentifier sur chacune d’elles.
Une authentification unique et une intégration de ces applications permettrait aux
pilotes de gagner du temps et d’accroître la production.
1.2.3 Objectif
Pour palier les problèmes identifiés à la section précédente le département PPCF
souhaite mettre en place une solution d’intégration .Cette plateforme permettra aux
différents pilotes d’effectuer une authentification unique pour accéder aux
différentes applications.L’automatisation de certaines taches permet aux pilotes
d’optimiser le temps .Ainsi ils pourront prendre en charge plus de demande ce qui
permet d’augmenter la productivité.
Pour atteindre cet objectif, le travail sera divisé en quatre phases :
 La première phase consistera à effectuer une étude de l’infrastructure existante
 La deuxième phase consistera à une analyse des besoins pour spécifier les
services offerts par le systèmes
 La troisième phase consistera à effectuer une conception de la solution
proposée:technologies et solution proposée
 La dernière phase consistera à faire la réalisation du projet.
Dans ce chapitre, nous avons commencé par présenter le groupe Sonatel, la structure
d’accueil, où nous avons effectué notre stage de fin de formation portant sur
l’intégration des Outils de Pilotage Production Clients Fibre.Nous avons ensuite
procédé à la
présentation de notre sujet.
Chap 2:Les Réseaux d’accès par Fibre Optique:FTTX et technologie GPON
Introduction
Notre stage s’est déroulé au département de PPCF qui est le seul plateau de pilotage
des clients fibres.Le système informatique qui fait l’objet de notre étude permet aux
pilotes d’effectuer la configuration d’un réseau FTTX.Il serait alors judicieux
d’étudier les réseaux d’accès FTTX.
Dans ce chapitre nous allons présenter les différents réseaux FTTX ainsi que les
architectures sous lesquelles ils peuvent être déployés.
2.1 Les Réseaux FTTX
Le FTTX (fiber to the X) consiste à amener la fibre optique au plus près de
l'utilisateur, afin d'augmenter la qualité de service (en particulier le débit) dont celui-
ci pourra bénéficier.Le «x» représente le point de terminaison de la fibre, comme la
maison, l’antenne, le bâtiment, etc.
Avec différentes destinations réseaux, FTTX se catégorise en plusieurs topologies
parmi lesquels nous avons :
2.1.1 FTTH
Le FTTH (Fiber to the Home - Fibre jusqu'à l'abonné) correspond au déploiement de
la fibre optique depuis le nœud de raccordement optique (lieu d'implantation des
équipements de transmission de l'opérateur) jusque dans les logements ou locaux à
usage professionnel.
Figure 2.1
:
A
r
chitecture du réseau FTTH
2.1.2 FTTB(Fiber To The Building)
Le terme FTTB désigne l’ensemble des connexions fibre arrivant jusqu’à l’immeuble
de l’abonné.
Contrairement à une connexion FTTH , la FTTB comprend deux réseaux:
– Le premier, du réseau de l’opérateur jusqu’au boîtier avec la fibre optique.
– Le second, du boîtier jusqu’à l’habitant avec des câbles en cuivre.
Figure 2.2
:
S
t
r
ucture d’un réseau FTTB
2.1.3 FTTN(supérieur à 300m) ou FTTC(à moins de 300 mètres)
Un réseau FTTN(Fiber To The Node) est constitué de fibre optique jusqu’au sous-
répartiteur . Ce dernier est une armoire qui regroupe plusieurs paires de cuivre du
quartier. On appelle aussi ces opérations des Montées en Débit (MeD) ou FTTC
(Fiber to the Cabinet ).
La fibre optique est apportée entre le NRA d’origine (NRA-O) jusqu’à un local, le
NRA-MED créé à proximité ou à la place du sous-répartiteur.
Figure 2.3
:
A
r
c
hitecture d’un réseau FTTN/FTTC
2.2 Architecture
La fibre est principalement déployée dans une des topologies suivantes :
2.2.1 Point to Point
Elle est caractérisée par le déploiement d’une fibre optique dédiée par usager, entre le
NRO(OLT) et le foyer raccordé(ONT). Son avantage est de permettre une absolue
étanchéité entre les différents abonnés et garantir la disponibilité totale de la ligne. En
revanche elle nécessite de déployer un nombre important de fibre. De plus, si une
nouvelle maison doit être rajoutée, une nouvelle fibre doit être mise en place.
Figure 2.4
:
A r
c h
it e
c t
u r
e

P2P
2.2.2 Point to Multipoint
La technologie point-à-multipoint permet quant à elle la mutualisation des signaux
optiques de plusieurs abonnés(ONT) sur une même fibre au Noeud de raccordement
optique(OLT). Plusieurs niveaux de coupleurs sont généralement placés entre le
noeud de raccordement optique et les abonnés.
2.2.2.1 Architecture PON
L'architecture PON (Passive Optical Network) est une technologie de déploiement
d'un réseau en fibre optique selon laquelle une fibre unique partant du NRO permet
de desservir plusieurs logements (par exemple jusqu'à 64), par réplication du signal
au niveau de coupleurs.
Dans la pratique, les équipements actifs au niveau du NRO (OLT,équipement de
terminaison côté réseau) disposent de ports PON permettant d'émettre/recevoir des
flux à/de plusieurs équipements terminaux d'abonnés (ONT ou ONU) sur une unique
fibre optique.
Des coupleurs optiques (il s'agit d'équipements passifs de petites tailles hébergés dans
les boîtiers d'épissurage), déployés le long du parcours, permettent de séparer le
signal dans le sens descendant et de le combiner dans le sens montant.
Figure 2.5:Architecture PON
2.2.2.2 Les entités
L’architecture FTTH généralement retenue par les opérateurs est une architecture
PON (Passive Optical Network). Le PON est une architecture point à multipoints
basée sur les éléments suivants :
 OLT( Optical Line Termination)
L'OLT, appelé aussi Optical Line Terminal, est l'équipement de terminaison, côté
réseau, assurant l’interface avec les fibres dans les réseaux FTTH en fibres optiques;
il est connecté à un ou plusieurs réseaux de distribution optique passifs (ODN).
Dans un réseau FTTH, un OLT est relié à une ou à plusieurs terminaison d'abonnés,
appelées Optical Network Unit (ONU) ou ONT.
 ODN(Optical Distribution Network )
L’ODN fournit le support de transmission optique pour la connexion physique des
ONUs aux OLTs. Sa portée est de 20 km ou plus. Dans le réseau ODN, un câble à
fibre optique, des connecteurs de fibre optique, des splitter à optique passif et des
composants auxiliaires collaborent les uns avec les autres. L’ODN comprend
spécifiquement cinq segments : la fibre d’alimentation, le point de distribution
optique, la fibre de distribution, le point d’accès optique et la fibre optique. La fibre
d’alimentation commence à partir du cadre de distribution optique (ODF) dans la
salle de télécommunication du bureau central (CO) et se termine au point de
distribution optique pour une couverture à longue distance. La fibre de distribution du
point de distribution optique au point d’accès optique de distribution à fibres optiques
pour les zones adjacentes. La fibre optique connecte le point d’accès optique à des
terminaux (ONTs), permettant ainsi une transmission de la fibre optique dans les
maisons des utilisateurs. De plus, l’ODN est le chemin essentiel pour la transmission
de données PON et sa qualité affecte directement les performances, la fiabilité et
l’évolutivité du système PON.
 ONU( optical network unit)
L'ONU est l’équipement utilisateurs chargé de terminer la fibre optique dans un
réseau d’accès à Internet par Fibre optique. Il fait la conversion du signal optique en
signal électrique et est conçue pour une utilisation par plusieurs abonnés..
 ONT
L’ONT (Optical Network Termination) est un élément qui assure l’adaptation optique
/ électrique et le filtrage des flux entrants et sortants destinés au client.Dans ce cas Il
n’y a qu’une seule fibre par client(est conçu pour être utilisé par un seul
abonné ).L’ONT se trouve généralement chez le client.
2.2.2.3 Types de réseaux d’accès PON
 EPON : Ethernet PON, un protocole PON basé sur Ethernet défini dans la
recommandation IEEE 802.3ah. Il peut atteindre jusqu’à 1Gb/s symétriquement
 APON : ATM PON : Un protocole PON basé sur ATM, très peu utilisé
 BPON : Broadband PON : Une évolution du protocole APON précédent,
défini dans la recommandation ITU G.983, ayant un débit jusqu’à 1Gb/s dans
le sens descendant et
622Mb/s dans le montant.

 GPON
La technologie GPON offre des vitesses asynchrones hautes performances de jusqu'à
2,5 Gigabits par seconde en aval et 1,25 Gigabits par seconde pour en amont. La
vitesse réelle dépend du taux de division. Le mot passif dans GPON fait référence à
une technologie point à multipoint. Le système de couplage repose sur des
composants passifs du réseau de distribution.
Il permet d'atteindre plusieurs utilisateurs sans avoir besoin de déployer des
amplificateurs.GPON bénéficie des technologies optiques, ces avantages sont élevés
en bande passante, faibles pertes de transmission, immunité électromagnétique et la
fiabilité sur la transmission des données. Il prend en charge plusieurs
communications sur la même fibre utilisant la lumière. GPON n'est pas un élément
unique, mais un réseau. Il s'agit d'un réseau d'accès filaire avec une topologie en
étoile qui connecte les utilisateurs finaux au central.
 WDM-PON : Wavelength Division Multiplexing PON : une évolution des
protocoles
PON précédents basée sur la longueur d'onde de plusieurs abonnés sur une même
fibre.
Le multiplexage par répartition en longueur d'onde PON, ou WDM-PON, offre une
meilleure confidentialité et une meilleure évolutivité car chaque ONU/ONT reçoit
uniquement sa propre longueur d'onde. Il est optimisé pour les applications jusqu'à 20
km, 40 canaux et 1 Gigabit/s par client.
La SONATEL utilise comme technologie de support le GPON
2.2.3 AON
L'AON est une architecture point à multipoint utilisant un équipement actif (c'est-à-
dire alimenté en électricité) installé dans le réseau d'accès, par lequel jusqu'à 128
utilisateurs peuvent être regroupés sur une fibre arrivant au NRO(OLT).
Contrairement au un Pon les coupleurs actifs permetrront d’atteindre des débits
équivalents au P2P.
Figure 2.6
:
A r
c h
it e
c t
u r
e

Point à Multipoint Actif


Conclusion
Ce chapitre a permis de décrire le réseau d’accès FTTX .Ensuite nous avons étudier
les différentes architectures possibles en mettant l’accent sur la technologie GPON
qui utilisée à la SONATEL.
Le prochain nous permettra de faire une étude sur les bonnes pratiques de
l’intégration des applications.
Chap 3:Etude sur les bonnes pratiques
Introduction
L'intégration des applications devient de plus en plus cruciale car peu importe à quel
point vous souhaitez effectuer tout votre travail à l'aide d'une seule application, c'est
presque impossible.Il existe plusieurs applications, répondant à des besoins et à des
rôles spécifiques au sein des entreprises.
Ce chapitre va nous permettre d'aborder les différentes solutions d'intégration
d'applications,la fédération d'identité et l'authentification unique.
3.1 Technique d'intégration
3.1.1 Les Middlewares
Un middleware est une interface permettant la mise en relation de plusieurs
applications hétérogènes. Il agit comme une passerelle afin de faciliter l’échange de
données entre deux systèmes distincts.
Il existe trois principaux types de middleware :
3.1.1.1 MOM
Dans un MOM (Message Oriented Middleware), les applications informatiques
communiquent par échange de messages d'une manière similaire au courrier
électronique : une application informatique émet un message qui est alors transmis à
l'application destinataire par le middleware pendant que l'application émettrice
effectue d'autres traitements (asynchronisme).
Le contenu du message est formaté par l'émetteur selon une convention pré-établie
puis analysé automatiquement par l'application destinataire conformément à cette
convention. Le format de données XML est souvent utilisé pour les messages.
3.1.1.2 ORB
Le middleware ORB(Object Request Broker) le principe d’appel de fonctions
distantes pour acheminer le service sollicité par le client vers le serveur. La fonction
distante est alors exécutée, et le résultat du service livré au client. C'est un mode de
fonctionnement synchrone, serveur et client agissant dans la même unité de temps.
3.1.1.3 MOT
Un MOT(Transaction Oriented Middleware) est un environnement réparti qui prend
en charge l'execution d'une application et la verification de son bon fonctionnement
en intégrant des mécanismes transactionnels. En plus des aspects purement
transactionnels, ils offrent un outil de gestion optimisé et partagé des ressources, un
outil de communication et un outil d'administration et de supervision.
Les MOT permettent au programmeur de ne pas s'occuper des problèmes de
simultanéités d'accès, de défaillance du système, de ruptures de connexions. Ils
fournissent le moteur pour faire tourner les applications au dessus des OS et du
matériel. Ils assurent une cohérence transactionnelles et facilite le découpage des
applications en services.
MOMs et ORBs restent des solutions très techniques ; ils permettent certes à la fois la
propagation des données et l'intégration des traitements, mais la sémantique des
échanges y reste fondamentalement point-à-point : le client doit connaître le format
du message qu'il adresse aux systèmes tiers ; ce couplage fonctionnel des systèmes
devient rapidement un cauchemar pour la maintenance et l'exploitation, en particulier
s'il est étendu à l'ensemble du SI ; enfin, la question de l'interopérabilité n'est pas
définitivement résolue, en particulier lorsque le système cible est très fermé.
3.1.2 Enterprise application integration EAI
Pour contourner les limites des middlewares les entreprises se tournent vers
l’Enterprise Application Integration (EAI). Cette plate-forme permet de réunir les
applications existantes d’une entreprise au sein d'un même espace, afin de les faire
communiquer entre elles.Un EAI permet en effet de se connecter à tous les types de
sources de données, de les extraire facilement, mais aussi de les structurer et de les
transférer d'un espace de stockage à un autre.
Les solutions EAI propose deux architectuires :
3.1.2.1 Architecture Point-to-Point
Le modèle point à point implique que chaque application a été personnalisée pour
pouvoir communiquer avec les autres applications et éléments de votre
environnement informatique. Chaque ressource doit donc être personnalisée en
fonction de toutes les ressources auxquelles elle se connecte. Il s'agit d'une tâche
fastidieuse et le modèle est par conséquent fortement sujet aux erreurs. Pour ne rien
simplifier, la maintenance du modèle se complexifie à chaque mise à jour de
l'infrastructure et des applications.

Figure
3.1:Architectute Pont-To-Point
3.1.2.2 Architecture Hub-and-Spoke
Le modèle en étoile résout ce problème avec un point de connexion central (le cœur)
qui relie toutes les applications et les services. Les rayons qui relient le cœur aux
applications et aux services peuvent faire l'objet d'une maintenance individuelle.
Ainsi, vous pouvez concevoir des applications plus spécialisées et réserver les tâches
d'intégration au cœur et aux rayons. Le principal désavantage de cette approche réside
dans la centralisation du cœur, car il devient le point unique de défaillance du
système et des communications au sein de votre infrastructure. Dans un modèle en
étoile, toutes les intégrations dépendent, par définition, du bon fonctionnement du
cœur.

Figure 3.2:Architecture en étoile


3.1.3 Entreprise Service Bus ESB
3.1.3.1 Définition et Architecture
ESB signifie Entreprise Service Bus. C'est est une nouvelle génération d’intégration
d’application, considérée en quelques sortes comme l’héritière de l’EAI. Un ESB est
construit sur des standards ouverts tels que le protocole XML pour la description des
messages(requête et réponse) et les services web pour l’échange de données.
À la différence de l'EAI, l'ESB n’intervient pas directement dans les applications du
système mais via des modules de web services au sein de chacune d'entre elles.
L'ensemble de ces modules de service est ensuite dirigé et partagé vers un flux central
où l'échange est assuré : le Bus applicatif.
Les déploiements de nouveaux outils et composants dans le système d'information est
ainsi facilité grâce à cette méthode.
Il est couramment utilisé dans les principes d'intégration d'applications d'entreprise
(EAI) ou d'architecture orientée services (SOA).
Figure 3.3:Architecture ESB
3.1.3.2 Principe
L'ESB en tant que médiateur entre les clients et les fournisseurs de services s'appuie
sur les principes suivants :
1. Découplage
L'une des choses les plus importantes que vous puissiez faire via ESB est de
dissocier les clients des fournisseurs de services.
2. Conversion de protocole de transport
ESB vous donne la possibilité d'accepter un protocole d'entrée et de
communiquer avec un autre fournisseur de services sur un protocole différent.
3. Amélioration des messages
ESB vous permet d'isoler le client et d'apporter quelques modifications de base
au message.
Par exemple, modifier le format de date du message entrant ou ajouter des
données d'information aux messages.
4. Transformation des messages
ESB vous permet de transformer un message entrant en plusieurs formats et
structures sortants.
Par exemple, XML vers JSON, objets XML vers Java.
5. Routage
ESB a la capacité de rediriger une demande client vers un fournisseur de
services particulier en fonction de critères de routage déterministes ou
variables.
6. Sécurité
ESB protège les services contre les accès non autorisés.
7. Chorégraphie de processus et orchestration de services
ESB gère les flux de processus et les services commerciaux complexes pour
effectuer une opération commerciale.
La chorégraphie des processus concerne les services métier, tandis que
l'orchestration des services est la capacité de gérer la coordination de leurs
implémentations réelles. Il est également capable d'abstraire les services métier
des services réellement mis en œuvre.
8. Gestion des transactions
ESB offre la possibilité de fournir une seule unité de travail pour une demande
commerciale, fournissant un cadre pour la coordination de plusieurs systèmes
disparates.
3.1.4 SOA
3.1.4.1 Definition
Contrairement à l'EAI qui consiste à lier des applications d'entreprise pour qu'elles
puissent communiquer entre elles (au moyen d'un moteur de raisonnement intelligent)
et effectuer des transferts de données « par lots », l'architecture orientée services
(SOA) assure des transferts de données « transactionnels », avec aucun logiciel tiers
requis. La SOA est différente de l'approche EAI en ce sens qu'elle ne dépend pas
d'une solution tierce.
le SOA repose sur les web services qui utilisent des langages standardisés. XML
(Extensible Markup Language), langage incontournable et universel pour les
descriptions efficaces des données, SOAP Service Oriented Architecture Protocol
comme protocole d'échanges des messages au format XML dans une logique de RPC
(Remote Procedure Call) et WSDL (Web Services Description Language), pour ne
citer que les principaux.
Le fonctionnement est ici un peu différent : nous avons été habitués au « Request and
Reply » (envoi d'une requête et réception de la réponse) alors qu'ici le principe est
« Publish and Subscribe » (les informations sont publiées et si on veut les recevoir,
on s'y abonne).La publication est dynamique : si jamais il y a de l'information à
transmettre, elle est publiée et tout le monde peut souscrire à ce service à n'importe
quel moment.
3.1.4.2 Principe
SOA repose sur les principes suivants :
 Contrat de service standardisé
Les services adhèrent à un accord de communication standard, tel que défini
collectivement par un ou plusieurs documents de description de service au sein d'un
ensemble donné de services.
 Autonomie de référence de service (un aspect du couplage lâche)
La relation entre les services est minimisée au point qu'ils sont seulement conscients
de leur existence.
 Transparence de l'emplacement de service (un aspect du couplage
lâche)
Les services peuvent être appelés de n'importe où dans le réseau où ils se trouvent,
peu importe où ils sont présents.
 Longévité du service
Les services doivent être conçus pour durer longtemps. Dans la mesure du possible,
les services doivent éviter de forcer les consommateurs à changer s'ils n'ont pas
besoin de nouvelles fonctionnalités. Si vous appelez un service aujourd'hui, vous
devriez pouvoir appeler le même service demain.
 L'abstraction des services
Les services agissent comme des boîtes noires, c'est-à-dire que leur logique interne
est cachée aux consommateurs.
 Autonomie de service
Les services sont indépendants et contrôlent les fonctionnalités qu'ils encapsulent, du
point de vue de la conception et de l'exécution.
 Apatridie de service
Les services sont sans état, c'est-à-dire qu'ils renvoient la valeur demandée ou
donnent une exception, minimisant ainsi l'utilisation des ressources.
 Granularité du service
Un principe pour garantir que les services ont une taille et une portée adéquates. La
fonctionnalité fournie par le service à l'utilisateur doit être pertinente.
 Normalisation des services
Les services sont décomposés ou consolidés (normalisés) pour minimiser la
redondance. Dans certains, cela peut ne pas être fait. Ce sont les cas où l'optimisation
des performances, l'accès et l'agrégation sont requis.
 La composabilité du service
Les services peuvent être utilisés pour composer d'autres services.
 Découverte de services
Les services sont complétés par des métadonnées de communication grâce auxquelles
ils peuvent être efficacement découverts et interprétés.
 Réutilisabilité des services
Logic est divisé en différents services, pour favoriser la réutilisation du code.
 Encapsulation de services
De nombreux services qui n'étaient pas initialement prévus dans le cadre de la SOA,
peuvent être encapsulés ou devenir une partie de la SOA.

3.2 Niveau d'intégration


3.2.1 L'intégration par les données :
C’est l’ensemble des techniques utilisées pour transférer les données entre les data
stores (où on stocke les données). sans avoir besoin d’introduire des changements sur
la logique des applications de l’entreprise.Ce qui peut être explicité comme étant le
fait d’extraire les informations d’un emplacement pour le mettre à la disposition d’un
autre qui a besoin de ces informations, tout en actualisant la base de données.Ce type
d’intégration est utilisé dans le cas où les applications à intégrer n’ont pas une
interface des utilisateurs et des APIs
3.2.2 L'intégration par les interfaces :
Cette approche est aussi appelée screen-scrapping qui permet de relier la logique
d’intégration dans l’interface des utilisateurs . L’intégration à ce niveau se fait par le
développement d’une interface commune (partagée) pour exposer les différentes
applications isolées en intra et inter-entreprises.
Il peut aussi extraire et échanger des données avec des applications distantes.
3.2.3 L’intégration les traitements :
L’intégration à ce niveau permet à des applications de partager les fonctionnalités
offertes par d’autres applications hétérogènes et indépendantes et cela par
l’invocation des services qu’elles exposent . Le mécanisme le plus simple permettant
de réaliser ce type d’intégration est l’utilisation des APIs (Application Programming
Interface), ou encore plus récemment les web services .
3.2.4 Intégration par les processus :
C’est la forme la plus complexe de l’intégration. Elle sert à rendre valable une
application dans le contexte d’une autre sans la dupliquer. Elle permet aussi de
construire de nouveaux processus métier à base des applications et progiciels(logiciel
applicatif) existants. Ceci crée de nouvelles opportunités pour l’entreprise à moindre
coût. Les données circulant dans la nouvelle organisation sont accédées et maintenues
selon une logique de métier (business logic) qui a des règles et une sécurité de
données. Ces données ne sont plus simples mais des objets métier (BOD : Business
Object Document, ex bon de commande) qui portent déjà un sens . Grâce à cette
forme d’intégration, les nouveaux processus métier qui les manipulent sont crées.
3.3 Authentification unique et la Fédération d'identité
Pour protéger l’accès aux services digitaux, il est nécessaire d’utiliser des identifiants
propres à chacun.La multiplication des applications au quotidien dans le cadre privé
et professionnel nous oblige à mémoriser toujours plus d’identifiants et de mots de
passe. utilisent les mêmes mots de passe ou des mots simples à retenir. Ces pratiques
nous rendent pourtant extrêmement vulnérables aux attaques.
C’est pour résoudre ces problèmes, que sont arrivées les solutions de Single Sign
On et de fédération d’identités.
Le Single Sign On (SSO) propose une solution à ce problème de prolifération des
mots de passe, avec une authentification unique de l’utilisateur. Cette authentification
se propage aux applications auxquelles l’utilisateur souhaite accéder grâce à la
fédération d’identité.
3.3.1 La Centralisation
Dans le cadre de la mise en place d'une fédération d’identité, une grande quantité
d’informations relatives aux acteurs sont manipulées. Ces informations doivent être
stockées dans une base d'informations afin d'en assurer la cohérence, la sécurité,
l’accessibilité et la centralisation.
Ainsi la base d'information étant beaucoup plus sollicitée en lecture, nous avons porte
notre choix sur les annuaires LDAP qui sont réputés être performants pour les accès
en lecture.
3.3.1.1 Annaire
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. Un annuaire électronique va centraliser des
informations et les rendre disponibles, via le réseau, à des applications, des systèmes
d’exploitation ou des utilisateurs.
3.3.1.2 Différnce entre Annuaire et Base de Données
Bien qu’un annuaire soit comparable à une base de données pour un grand nombre de
fonctionnalités, il en diffère en de nombreux points.
 Un annuaire est très performant en consultation (c’est-à-dire en lecture ou en
recherche). Par contre, un annuaire n’est pas très adapté pour des mises à jour
fréquentes (écriture). Les données contenues dans un annuaire sont en effet beaucoup
plus pérennes, et il est donc totalement inutile d’optimiser les fonctions de mise à
jour.
 Une base de données doit, par contre, généralement supporter
des applications qui la remettent constamment à jour. Cela signifie que la
fonctionnalité écriture dans une base de données est importante et doit par conséquent
être optimisée.
 Un annuaire LDAP organise les données de manière arborescente,tandis que
les bases de données le font au sein de tableaux à deux dimensions.
3.3.1.3 LDAP
3.3.1.3.1 Présentation
LDAP (Lightweight Directory Access Protocol, ou Protocole d'accès aux annuaires
léger) est un protocole standard permettant de gérer des annuaires, c'est-à-dire
d'accéder à des bases d'informations sur les utilisateurs d’un réseau par
l’intermédiaire du protocole 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.
LDAP est un protocole client-serveur et offre quatre modèles prédéfinis. L’objectif
de cette modélisation est de favoriser le partage et de simplifier la gestion des
informations concernant des personnes, et plus généralement toutes les ressources de
l’entreprise, ainsi que des droits d’accès des utilisateurs sur ces ressources.
Les modèles LDAP représentent les services que propose le serveur au client.Ainsi
on distingue :
 Le modèle de nommage définit comment l'information est stockée et
organisée
 Le modèle fonctionnel définit les services fournis par l'annuaire (recherche,
ajout, ...)
 Le modèle d'information définit le type d'informations stockées

 Le modèle de sécurité définit les droits d'accès aux ressources

3.3.1.3.2 Structure
Les données LDAP sont structurées dans une arborescence hiérarchique. Chaque
nœud de l'arbre correspond à une entrée de l'annuaire ou Directory Service Entry
(DSE) et au sommet de cette arbre, appelé Directory Information Tree (DIT), se
trouve la racine ou suffixe.
Les entrées correspondent à des objets abstraits ou issus du monde réel, comme une
personne, une imprimante, ou des paramètres de configuration. Elles contiennent un
certain nombre de champs appelés attributs dans lesquelles sont stockées des valeurs.
Chaque serveur possède une entrée spéciale, appelée root Directory Specific Entry
(rootDSE) qui contient la description de l'arbre et de son contenu.
Un objet est constitué d'un ensemble de paires clés/valeurs appelées attributs
permettant de définir de façon unique les caractéristiques de l'objet à stocker. Par
analogie avec la terminologie objet on parle ainsi de classe d'objet pour désigner la
structure d'un objet, c'est-à-dire l'ensemble des attributs qu'il doit comporter. De cette
façon un objet est un ensemble d'attributs avec des valeurs particulières.
LDAP utilise le format LDAP Data Interchange Format (LDIF) qui permet de
représenter les données LDAP sous format texte standardisé, il est utilisé pour
afficher ou modifier les données de la base.
Dc : domain component
Ou : organizational units
Cn : common name
Uid : user identifier
Figure 3.4:Exemple de DIT
3.3.2 La Fédération d'identité
Dans les entreprises les employées utilisent de nombreuses applications pour
éffectuer les tâches et doivent s'authentifier à chaque fois.La fédération d'identité
permet alors aux utilisatueurs d'accéder à toutes les applications du Système
informatique après s'être authentifiés une seule fois.En effet elle permet de propager
les informations d'authentifications vers les autres applications pour éviter à
l'utilisateur de saisir à nouveau son login et son mot de passe.Elle repose sur une
relation de confiance entre le founisseur de service(SP) et fournisseur d'identité(IdP).
3.3.2.1 Principe
Dans la fédération d'identité, un IdP se porte garant de l'identité des utilisateurs et un
SP fournit des services aux utilisateurs. Lorsqu'un utilisateur souhaite accéder à un
service d'un SP, le SP délègue l'authentification à l'IdP. C'est ce qu'on appelle la
fédération.Pour que la fédération d'identité ait lieu, le SP doit faire confiance à la
capacité d'authentification de l'IdP.
Supposons qu'un utilisateur souhaite accéder à une application :
1.L'utilisateur accède à l'application du SP.
2.Le SP exige que l'utilisateur soit authentifié auprès de l'IdP (le SP peut avoir des
mécanismes pour vérifier si l'utilisateur est actuellement authentifié auprès de l'IdP à
l'aide des données de session). L'utilisateur non authentifié est redirigé vers la page de
connexion de l'IdP.
3.L'utilisateur s'authentifie auprès de l'IdP (en saisissant les identifiants de
connexion).L’IdP vérifie au niveau de l’annuaire si les informations sont correctes et
récupère les informations additionnelles associées à son identité.
4.Si les informations d'identification de l'utilisateur sont correctement validées,
l'utilisateur est authentifié et reçoit un jeton d'accès(la validité et l’identité)
5.le fournisseur de service évalue le jeton et autorise l’accès de l’utilisateur.
Le figure ci-dessous vous aidera à comprendre facilement le flux.

Figure 3.5:
Princ ipe
de

fonctionnement de la Fédération d'identité


3.3.2.2 Lien de confiance
Outre la gestion technique assurée par les logiciels de fédération, il faut que les
fournisseurs d'identité et les ressources se fassent mutuellement "confiance".
Pour se faire mutuellement confiance un fournisseur d'identité et une ressource
peuvent s'engager à chacun respecter des règles (par exemple le fournisseur d'identité
peut s'engager à maintenir des informations à jour sur ses utilisateurs). Mais si chaque
paire de fournisseur d'identité-ressource doit le faire, le nombre d'engagements à
maintenir ainsi entre les multiples acteurs d'une communauté sera énorme.
Une fédération d'identité évite ce problème en regroupant des fournisseurs d'identité
et des ressources qui s'engagent, au moment de leur inscription, à respecter un
ensemble minimal de règles qui permettent d'assurer la confiance. Ainsi un
fournisseur d'identité ou une ressource qui s'inscrit dans une fédération n'a pas à
formaliser avec chacun des autres participants des relations de confiance, car il sait
que ces autres participants se sont engager à respecter des qui permettent d'assurer la
confiance.
Au sein d’un cercle de confiance, des règles existent pour assurer la protection des
données personnelles des utilisateurs qui peuvent être communiquées entre
fournisseurs.
3.3.2.3 SAML
Le SAML(Security assertion markup language) est un protocole ouvert et standardisé
basé sur le langage XML pour échanger des informations d’authentification et
d’autorisation entre des entités ou domaines de sécurité.
Il sert principalement à établir une authentification unique (SSO) entre un fournisseur
d'identités (IdP) et un prestataire de services (SP). Lorsqu'un IdP (un employeur, par
exemple) et un fournisseur de services implémentent le protocole SAML, ils peuvent
facilement authentifier les utilisateurs accrédités chez l’IdP pour qu'ils puissent
utiliser les services.
3.3.2.4 OAUTH
OAuth est un protocole libre qui permet d'autoriser un site web, un logiciel ou une
application (dite « consommateur ») à utiliser l'API sécurisée d'un autre site web (dit
« fournisseur ») pour le compte d'un utilisateur. OAuth n'est pas un protocole
d'authentification, mais de « délégation d'autorisation ».
OAuth permet aux utilisateurs de donner, au site ou logiciel « consommateur »,
l'accès à ses informations personnelles qu'il a stocké sur le site fournisseur de service
ou de données, ceci tout en protégeant le pseudonyme et le mot de passe des
utilisateurs.
3.3.2.5 OPENID
OpenID est un système d’authentification décentralisé qui permet l’authentification
unique, ainsi que le partage d’attributs. Il permet à un utilisateur de s’authentifier
auprès de plusieurs sites (devant prendre en charge cette technologie) sans avoir à
retenir un identifiant pour chacun d’eux mais en utilisant à chaque fois un unique
identifiant OpenID. Il permet aussi d’éviter de remplir à chaque fois un nouveau
formulaire en réutilisant les informations déjà disponibles.Les opérations sont
réalisées via des web services REST et les données sont échangées au format JSON.
Le protocole définit notamment des mécanismes optionnels de signature et de
chiffrement des données, ce qui n’était jusqu’alors pas possile dans les autres
protocoles.De manière similaire aux assertions SAML, ces jetons peuvent être signés
et chiffrés
OpenID a été conçu pour répondre aux limites de OAuth2 dans le domaine de
l’authentification forte.
3.3.2.6 Shibboleth
Shibboleth est développé depuis 2001 par Internet2 et désigne à la fois une norme et
un produit, il repose sur un mécanisme de propagation d'identités. Son objectif est
double :
 d'une part il permet, lors de la connexion à un service enregistré dans la
fédération, de déléguer l'authentification à l'établissement d'origine de
l'utilisateur.
 d'autre part il contribue à obtenir certains attributs (données annuaire) de
l'utilisateur, afin de gérer le contrôle d'accès ou personnaliser les contenus.
Shibboleth s'appuie en général sur un système CAS et offre donc également les
fonctionnalités de SSO standards (fenêtre d'authentification unique, plus besoin de
retaper son mot de passe lorsque l'utilisateur passe d'un service à l'autre).
3.3.3 L'Authentification Unique
L'authentification unique, souvent désigné par le sigle anglais SSO (de single sign-
on) est une méthode permettant à un utilisateur d'accéder à de multiples services,
sites web et application ne procédant qu'à une seule authentification.Une solution
d'authentification unique peut simplifier la gestion des noms d'utilisateur et mots de
passe à la fois pour les utilisateurs et les administrateurs.
3.3.3.1 Principe
Les utilisateurs n'ont plus besoin d'archiver des différents jeux d'identifiants et
peuvent se contenter de mémoriser un seul mot de passe plus complexe.
La procédure de connexion se déroule généralement comme suit :
1. Un utilisateur navigue jusqu'à l'application ou le site Web auquel il veut
accéder, c'est-à-dire le fournisseur de services.
2. Le fournisseur de services envoie un jeton contenant certaines informations à
propos de l'utilisateur (son adresse e-mail, par exemple) au système SSO, c'est-
à-dire le fournisseur d'identités, dans le cadre d'une demande d'authentification
de l'utilisateur.
3. Le fournisseur d'identités contrôle d'abord si l'utilisateur s'est déjà authentifié,
auquel cas il lui octroie l'accès à l'application du fournisseur de services et
passe directement à l'étape 5.
4. Si l'utilisateur ne s'est pas connecté, il sera invité à le faire en renseignant les
identifiants requis par le fournisseur d'identités. Il peut s'agir simplement d'un
nom d'utilisateur et d'un mot de passe, mais peut inclure d'autres formes
d'authentification comme un mot de passe à usage unique (OTP).
5. Une fois que le fournisseur d'identités valide les identifiants renseignés, il
renverra un jeton au fournisseur de services pour confirmer la réussite de
l'authentification.
6. Ce jeton est transmis au fournisseur de services par le biais du navigateur de
l'utilisateur.
7. Ce jeton que reçoit le fournisseur de services est validé en vertu de la relation
de confiance qui a été établie entre le fournisseur de services et le fournisseur
d'identités au moment de la configuration initiale.
8. L'utilisateur se voit octroyer l'accès au fournisseur de services.

Figure
3.6:Pro cédure

d'authentification
Si l'utilisateur tente d'accéder à un autre site Web, il faudra alors qu'une même
relation de confiance soit configurée entre ce nouveau site Web et la solution SSO,
puis la procédure d'authentification se déroulera en suivant les mêmes étapes.
3.3.3.2 Les différents types d’authentification unique
3.3.3.2.1 Approche fédérative
Dans ce mécanisme, chaque service gère une partie des données d'un utilisateur
(l'utilisateur peut donc disposer de plusieurs comptes),
mais partage les informations dont il dispose sur l'utilisateur avec les services
partenaires. Ce mécanisme a été développé pour répondre à un besoin de gestion
décentralisée des utilisateurs, où chaque service partenaire désire conserver la
maîtrise de sa propre politique de sécurité.
3.3.3.2.2 Approche centralisé
Le principe de base est ici de disposer d'une base de données globale et centralisée de
tous les utilisateurs ou d'un annuaire. Cela permet également de centraliser la gestion
de la politique de sécurité
3.3.3.2.3 Approche coopérative
Le mécanisme coopératif, dont les systèmes Shibboleth et CAS sont les principaux
représentants, part du principe que chaque utilisateur dépend d'une des entités
partenaires. Ainsi,lorsqu'il cherche à accéder à un service du réseau, l'utilisateur est
authentifié par le partenaire dont il dépend. Comme dans l'approche fédérative,
cependant, chaque service du réseau gère indépendamment sa propre politique de
sécurité.
3.3.3.3 Les Méthode d'authentification SSO
3.3.3.3.1 RADIUS
RADIUS (Remote Authentication Dial-In User Service) est un protocole client-
serveur permettant de centraliser des données d’authentification.
Le protocole RADIUS repose principalement sur un serveur (le serveur RADIUS),
relié à une base d'identification (base de données, annuaire LDAP, etc.) et un client
RADIUS, appelé NAS (Network Access Server), faisant office d'intermédiaire entre
l'utilisateur final et le serveur. L'ensemble des transactions entre le client RADIUS et
le serveur RADIUS est chiffrée et authentifiée grâce à un secret partagé.
Il est à noter que le serveur RADIUS peut faire office de proxy, c'est-à-dire
transmettre les requêtes du client à d'autres serveurs RADIUS.
Une séquence d’identification pourra donc se dérouler de la façon suivante
1. Le NAS demande au client de s’identifier:le client fournit son identifiant au NAS.
2. Le NAS achemine la demande au serveur RADIUS afin d’identifier (ou autoriser,
ou comptabiliser) le client ;
3. Le serveur RADIUS consulte la base de données hébergeant ces informations, par
exemple au travers du protocole d’annuaire LDAP.
4.Le serveur RADIUS retourne ainsi une des quatre réponses suivantes :
ACCEPT : l'identification a réussi ;
REJECT : l'identification a échoué ;
CHALLENGE : le serveur RADIUS souhaite des informations
supplémentaires de la part de l'utilisateur et propose un " défi " (en
anglais " challenge ") ;
CHANGE PASSWORD : le serveur RADIUS demande à l'utilisateur
un nouveau mot de passe
5. Le NAS peut alors authentifier le client grâce à la réponse obtenue du serveur
RADIUS.La figure ci_dessous illustre la procédure d'authentification avec RADIUS :
Figure 3.7
:Mé cani
sme

d’authentification Radius
3.3.3.3.2 KERBEROS
Kerberos est un protocole d'authentification réseau qui repose sur un mécanisme de
clés secrètes (chiffrement symétrique) et l'utilisation de tickets. L’utilisateur
s’authentifie sur le KDC puis utilise un ticket pour s’authentifier sur chaque service
demandé.Un KDC se compose d’un AS qui authentifie un utilisateur, et d’un serveur
d’octroi de tickets (TGS).
Chaque entité du réseau (client ou serveur) possède une clé secrète qui n’est connue
que de elle-même et du KDC. La connaissance de cette clé implique l’authenticité de
l’entité. Pour la communication entre deux entités du réseau, le KDC génère une clé
de session, appelée ticket Kerberos ou ticket de service.
Les étapes suivantes décrit le processus’authentification :
1. Le client demande au AS des informations d’identification pour un serveur
spécifique.
2. Le KDC vérifie les données d’identification et renvoie un TGT chiffré et une clé
de session.
3.Le client communique ensuite avec le TGS, en utilisant le TGT qu’il a reçu de l’AS
pour prouver son identité, et demande un service.
4.Si le client est admissible au service, le TGS émet un ticket Kerberos au client.
5.Le client contacte ensuite le serveur hébergeant le service (appelé le serveur de
service), en utilisant le ticket Kerberos pour prouver qu’il est autorisé à recevoir le
service. Le ticket Kerberos a une durée de vie configurable.
6.Le client s’authentifie avec l’AS une seule fois. S’il contacte le serveur physique
plusieurs fois, il réutilise le ticket AS.
La figure ci_dessous illustre le mécanisme d’authentification avec kerberos:

Figure 3.8:
A
u
t
h
e
n
t
i
fication avec Kerberos
3.3.3.3.3 CAS
Le CAS(Central Authentication Service) est un système d'authentification unique
(SSO) pour le web développé par l'Université Yale . On s'authentifie sur un site Web,
et on est alors authentifié sur tous les sites Web qui utilisent le même serveur CAS. Il
évite de s'authentifier à chaque fois qu'on accède à une application en mettant en
place un système de ticket.
Le principe de fonctionnement du CAS est décrit comme suit :
1- Le client web tente une connexion vers une application web à partir d’une requête
initiale en
http. L’application web redirige la requête vers une page d’authentification du
serveur CAS. Le
client peut accéder directement en https au CAS (1’) .
2- Le serveur CAS réalise l’authentification grâce à LDAP (login + mot de passe)
3- Le CAS génère un ticket ST (Service Ticket) au client. Ce dernier envoie les
paramètres de
connexion à l’application web et passe en paramètre le ticket ST.
4- L’application web accède directement au CAS en http ou en https et passe en
paramètre l’ID de service (l’ID de service est l’URL du service).
5- Le CAS génère un ticket TGC (Ticket Granting Cookies). Le CAS envoie le TGC
à l’application
web. C'est un cookie de session qui est transmis par le serveur CAS au navigateur du
client lors de
la phase de login.
6- Le CAS valide le ticket ST et retourne l’UID de l’utilisateur. En ce moment
l’utilisateur est authentifié et peut maintenant accéder à la page
Figure 3.9:Authentificaion avec CAS
3.4 Exemple d’EAI:France Telecom
France Telecom choisit webMethods spécialiste des solutions logicielles
d’intégration, pour répondre à l’ensemble de ses attentes concernant ses projets EAI
de partage des informations via des applications informatiques différentes. "Le
groupe a souhaité se doter d’outils performants pour ouvrir son système
d’information à ses clients et partenaires", explique Lucien Ducorney, directeur du
SICoR (système d’information commercial et ressources) de France Télécom. Un
second objectif consistait à intégrer des outils progiciels pour développer l’efficacité
des processus internes et de la relation commerciale.
3.4.1 L’entreprise Webmethods
webMethods était une société de logiciels d'entreprise, acquise par Software AG ,
spécialisée dans l'intégration d'applications, l'intégration de processus métier et
l'intégration de partenaires B2B. Fondée en 1996, la société vendait aux organisations
des systèmes permettant d'utiliser des services Web pour connecter des applications
logicielles sur Internet.. En 2007, WebMethods a été rachetée par Software AG est
devenue une filiale de cette entreprise.Software AG a conservé le nom webMethods
et l'utilise comme marque pour identifier une suite logicielle englobant l'amélioration
des processus, l'activation SOA, la modernisation informatique et l'intégration des
entreprises et des partenaires.
3.4.2 Service Webmethods
WebMethods est avant tout une plateforme d’intégration d’application d’entreprise
(en anglais EAI pour enterprise application integration). Elle consiste à faire
communiquer entre elles plusieurs applications hétérogènes. C’est-à-dire écrites dans
des langages différents .
Elle assure notamment la médiation entre ces différentes applications. Les
applications et bases de données deviennent personnalisables, qu’elles soient
installées sur site ou dans le cloud, elles sont interopérables. Les informations se
partagent de manière simple et efficace. De plus, les processus automatisé
fluidifient les flux de données.
La plateforme WebMethods permet de transporter des données de la source vers
la cible, de transformer les données avant l’envoi, de gérer le flux de messages
entre la source et la cible et d’assurer la connexion entre les différentes
applications. Les données sont traitées de manière à être accessibles en temps
réel, et demeurent disponibles aux nouvelles applications.
L’un des grands avantages de WebMethods, c’est le gain de temps. En effet,
plus besoin d’effectuer des développements supplémentaires et une
maintenance compliquée en cas d’ajout d’une nouvelle application.
Conclusion
Dans ce chapitre nous avons eu à étudier les différentes techniques
d’intégration.En suite nous avons une étude sur la propagation d’identité avant
de spécifier les méthodes d’authentification unique.
L’objet du chapitre suivant est d’étudier les technologie Web Services

Chap 4:Analyse de l’existant

Introduction
Au service de PPCF les pilotes utilisent de nombreuses applications pour effectuer les
configurations pour les services de téléphonie,d’internet et de la télévision et de
s’assurer du bon fonctionnement de ces services.
Il est alors important de réaliser une analyse du système informatique afin de
spécifier les limites du système et d’en apporter des améliorations.
4.1 Etude des outils de pilotage
4.1.1 AMS
AMS permet de faire la configuration des services pour les équipements de type
NOKIA.
Figure 4.1 :Interface d’accueil
 Déclaration de l’ONT
Pour créer l’ONT le pilote saisi le numéro de l’ONT et le numéro du client.

1.
2.

Enfin il faut créer une carte « Ethernet » à « 8 » ports permettant de porter l’ensemble
des services Internet, IPTV et VOIP :
 Création des cartes
À ce stade il faut créer les cartes suivantes :
◦ VEIP
D’abord il faut créer une carte « VEIP » à un port permettant de supporter les
services Internet et
VOIP .Cette carte permet dissocier les flux.
1.

2.

◦ Ethernet
Il faut ensuite créer une carte « Ethernet» à quatre ports permettant de supporter les
services Internet :
1.

2.

◦ VOIP
Maintenant on crée une carte « Ethernet» à deux ports permettant de supporter les
services VOIP :
1.

2.

 Afin d’activer les services effectuer les configuration ci_dessous :


◦ Internet
◦ VOIP

◦ Télévison
La configuration des services de télévision suit les étapes suivantes :
1.

2.
3.

4.1.2 U2000
U2000 permet d’activer les services pour les équipements HUAWEI :
 Déclaration de l’ONT :
 L’internet :
 La VOIP :
 La télévision :
4.1.3 SMART CONFIG
Cette application permet aux employés d’enregister les modems,de récupérer les
accès et d’ajouter des clients :
 Ajouter des clients
Elle permet d’enregistrer les clients qui bénéficie d’une installation d’un réseau
d’accès FTTX qu’il soit configuré ou pas.L’ajout des clients s’effectue de la
manière ci_dessous
1.
2.

3.
4.
5.

 Récupérer les accès


SMART_CONFIG permet aussi aux pilotes de récupérér les accès :
◦ Admin:Permet au technicien de se connecter sur le modem afin d’effectuer
les configurations nécessaire
◦ Password :
4.1.4 GAIA
Les pilotes peuvent utiliser GAIA pour tracer une demande ou faire la provision de la
carte VIACC tandis que les commerciaux l’utilisent pour ajouter des demandes.
 Provision de la carte VIACC
Avant ou après la configuration pour les services de télévision il faut faire une
provision de la carte VIACC afin de permettre à l’utilisateur d’accéder à ces services.
1.

2.
3.

4.
5.

6.
 Tracer la demande :

4.1.5 SPG
SPG permet de créer un compte IMS pour les clients en utilisant son numéro et son
password.
Les opérations de créations s’effectuent sur les 3 nœuds suivants :
 HSS:Permet d’allumer la lampe témoin au niveau du modem

 ATS :assure la disponibilité de la ligne


 ENS

4.1.6 RIGHTV
RIGHTV permet de vérifier si la provision de la carte VIACC est faite et que les
configurations pour la télévision sont correctes.Il permet également d’augmenter le
nombre de flux pour les clients souhaitant utiliser deux télévisions.
 Augmenter le Flux :
1.
2.

 Vérification sur les services de télévision :


Le pilote peut renseigner le Numéro du client ou de la demande pour vérifier que le
client peut utiliser la télévision.
1.

2.Le pilote clique ensuite sur modifier pour obtenir les information sur le bouquet

4.2 Processus de pilotage d’un réseaux FTTX


Il est crucial de décrire le processus de pilotage d’un réseau FTTX afin de mettre en
exherbe les limites du système informatique dues à la multitude des applications que
les pilotes utilisent.La figure 4.1 nous permet ainsi de décrire les différentes phases
de configuration des services.

Figure 4.1:Processus de pilotage


4.3 Limites
Même si le système informatique dont il dispose les permet d’effectuer toutes leurs
tâches,la multitude des applications porte préjudices dans l’optimisation de la
production et de l’efficacité.Les pilotes sont contraint de saisir les mêmes
informations pour effectuer chaque configuration.L’automatisation de certaines tache
peut éviter aux utilisateurs de devoir saisir les mêmes information à chaque
configuration.Ce qui permet d’éviter les erreurs de saisie.Une unification des
interfaces pourrait permettre aux pilotes de ne s’authentifier qu’une seule fois pour
accéder aux différentes applications.
Ce qui permet aux pilotes d’optimiser le temps et de pouvoir prendre en charge plus
de demande,d’où une productivité accrue.
Conclusion
Ce chapitre nous a permis de faire une présentation des différents outils de PPCF
.Ensuite nous avons eu à décrire le processus de configuration des services afin de
spécifier les limites du système et de pouvoir y remédier.
Le prochain chapitre va nous permettre de faire une étude sur les Technologies et
outils de Web Services
Chap 5:Technologies et outils de Web Services
5.1 Web Service
Les Web Services sont des services offerts via le web.Ce sont des programmes
informatiques reposant sur une architecture réseau client serveur qui permettent la
communication et l’échange de données entre les API et ceci indépendamment des
technologies dans lesquelles les applications sont développées.
Il existe deux types de web services sur lesquelles reposent l’échange entre les API 
5.1.1 API(Application programming interface)
L'intégration d'application n'est pas possible sans l'utilisation d'une interface de
programmation d'application ou d'une API.
Une API est une solution informatique qui permet à des applications de communiquer
entre elles et de s'échanger mutuellement des données. Une API est une façade par
laquelle un logiciel offre des services à d’autres logiciels. Elle regroupe un ensemble
de fonctions qui facilitent l'accès aux services d'une application ou d’un logiciel pour
les développeurs.
Les API sont très généralement accompagnées d’une description qui spécifie
comment des programmes tiers peuvent solliciter des fonctionnalités de l’application
ou du logiciel en question. Les API permettent aux développeurs d'ouvrir l'accès aux
ressources sans sacrifier le contrôle de la sécurité.Les langages et la syntaxe requis
sont décrits dans cette documentation.Elles se base sur les web services pour
dialoguer.Il existe deux grandes familles de services web :
5.1.1.1 SOAP
SOAP(Simple Object Access Protocol) est un protocole de communication basé sur
XML pour permettre aux applications de s'échanger des informations via
HTTP(HyperText Transfer Protocol) ou SMTP. Il permet ainsi l'accès aux services
web et l'interopérabilité des applications à travers le web. SOAP est un protocole
simple et léger et qui repose entièrement sur des standards établis comme le HTTP et
XMl. Il est portable et donc indépendant de tous système d'exploitation et du type
d'ordinateur.
Il permet la transmission de messages entre objets distants, ce qui veut dire qu'il
autorise un objet à invoquer des méthodes d'objets physiquement situés sur un autre
serveur.
Le message SOAP est un document XML et Un message SOAP présente une
structure normalisée. Il est toujours constitué
d’une enveloppe (SOAP-ENV : Enveloppe) munie :
 D’un en-tête (SOAP-ENV : Header) optionnelle qui contient des informations
de contexte spécifiques à l'application (par exemple, informations de sécurité
ou de chiffrement) qui sont associées à la demande SOAP ou au message de
réponse.

 D’un élément (SOAP-ENV : Body) obligatoire contenant le corps du message,


suivis d’éventuels éléments applicatifs spécifiques.
Exemple de Message SOAP :

Figure 5.1:Principe de SOAP


5.1.1.1.1 WSDL
WSDL (Web Services Description Langage) est un langage basé sur XML. Il permet
de décrire les composants des Web services nécessaires au protocole SOAP et à
l’interaction avec un autre service. Un document WSDL décrit quelles sont les
fonctionnalités qu’offre un Web service,
communique-t-il et par où est-il accessible. WSDL pourvoi un mécanisme structuré
pour décrire les opérations qu’un Web service peut remplir, les formats des messages
qu’il peut traiter, les protocoles qu’il supporte et les points d’accès à une instance
d’un Web service.
Pour ce faire, le langage définit 4 éléments principaux qui sont:
 portType: cet élément décrit le WebService, les actions qu'il peut exécuter et
les messages qui lui sont associés. Il peut être comparé aux prototypes des
fonctions dans un langage de programmation traditionnel.
 message: cet élément définit les données d'une action et peut être constitué de
plusieurs parties. Il peut être comparé aux arguments d'une fonction dans un
langage de programmation traditionnel.
 types: cet élément décrit les types des données utilisées par le WebService en
utilisant des XML Schema. Il doit absolument se placer au début d'après le
profil basique.
 binding: cet élément définit le format des messages et le protocole de
communication utilisé pour chaque WebService.
5.1.1.1.2 UDDI
UDDI (Universal Description and Discovery Integration) constitue une norme pour
les annuaires de services web : les registres UDDI. Les fournisseurs disposent d’un
schéma de description permettant de publier des données concernant leurs activités,
la liste des services qu’ils offrent et les détails techniques sur chaque service. La
spécification UDDI offre aussi une API aux applications clientes, pour consulter et
extraire des données concernant un service et/ou son fournisseur.
La mise en place d’un registre UDDI suit un processus uniforme imposé par la
spécification W3C. Chaque organisation qui veut mettre en place un registre UDDI
doit suivre ce processus pour devenir un opérateur UDDI.Les registres UDDI créées
sont organisés en réseaux, ils partagent ainsi les différentes informations publiées. La
publication d’un service chez un opérateur donne automatiquement lieu à un
processus de propagation des informations aux différents registres UDDI. L’accès à
l’ensemble des informations des registres peut se faire de n’importe quel opérateur
UDDI.
Chaque registre UDDI stocke trois sortes de données :
 Des données concernant les fournisseurs de services appelées pages blanches,
 Des données concernant l’activité ou le service métier des fournisseurs
appelées pages jaunes,
 Les données techniques de chaque service publié, qui constituent les pages
vertes.
5.1.1.2 REST
Rest(Representational State Transfer) est un style d’architecture logicielle permettant
de construire une application devant fonctionner sur des systèmes distribués,
typiquement Internet.
Il repose sur l’architecture client-serveur centré sur le transfert de représentations de
ressources via des requêtes et des réponses.L'un des grands avantages de la
programmation avec des API REST, c’est qu’elle permet d’utiliser plusieurs formats
de données - pas seulement XML, mais aussi JSON(JavaScript Objet Notation) et
HTML(HyperText Markup Language).Les services web conformes au style
d'architecture REST, aussi appelés services web RESTful,établissent une
interopérabilité entre les ordinateurs sur Internet.
Dans l’architecture REST, les données et les fonctionnalités sont considérées comme
des ressources et sont accessibles via des identificateurs de ressources uniformes
(URI), généralement des liens sur le Web. Au niveau serveur comme client une API
RESTful manipule des ressources par une représentation de celles-ci.Une ressource
peut être vu comme un objet en Pragammation Orientée Objet.
Le principe de REST est d'utiliser HTTP pour l'implémentation d'un Web Service.Il
ne consiste pas seulement à utiliser HTTP comme simple protocole de transport, mais
aussi pour définir l'API de chaque service.

Figure 5.2
:
p
r
i
n
c
i
pe de REST
5.1.1.2.1 URI
REST se base sur les URI (Uniform Resource Identifier) afin d’identifier une
ressource. Ainsi une application se doit de construire ses URI (et donc ses
URL :Uniform Resource Locator ) de manière précise, en tenant compte des
contraintes REST. Il est nécessaire de prendre en compte la hiérarchie des ressources
et la sémantique des URL pour les éditer.
Les URI peuvent contenir jusqu’à cinq parties, parmi lesquelles seules deux sont
obligatoires :
 Scheme (le schéma) : indique le protocole utilisé.

 Authority (l’autorité) : identifie le domaine.

 Path (le chemin) : indique le chemin d’accès à la ressource.

 Query (la requête) : représente une action de requête.

 Fragment (le fragment) : désigne un aspect partiel d’une ressource.

Seuls le schéma et le chemin doivent nécessairement apparaître dans chaque


identifiant. Dans la syntaxe commune aux URI, toutes les parties apparaissent les
unes derrière les autres et sont séparées par des signes bien précis.

Prenons l’exemple d’une adresse Web classique : example.org/test/test1.

 Scheme : http
 Authority : example.org

 Path : test/test1

 Query : search=test-question

 Fragment : part2

5.1.1.2.2 Verbe
Le principe de REST consiste à ’utiliser les verbes HTTP existants plutôt que
d’inclure l’opération dans l’URI de la ressource. Ainsi, généralement pour une
ressource, il y a 4 opérations possibles (CRUD) :
 POST (Create) : rajouter une ressource à une liste de ressources existantes,
donc création de ressource.
 GET(Read): récupérer la représentation d’une ressource ou d’une liste de
ressources
 PUT (Update) : modifier une ressource existante ou créer une nouvelle
ressource.
 DELETE : destruction d’une ou plusieurs ressources.

5.1.1.2.3 Réponse
Il est important d’avoir à l’esprit que la réponse envoyée n’est pas une ressource,
c’est la représentation d’une ressource. Ainsi, une ressource peut avoir plusieurs
représentations dans des formats divers : HTML, XML, CSV, JSON, etc.
C’est au client de définir quel format de réponse il souhaite recevoir via
l’entête Accept. Il est possible de définir plusieurs formats.

Exemple de réponse (Faire une capture au niveau de l’API):

GET /books
Host: mywebsite.com
Accept: text/html

5.1.1.2.3.1 Les codes de Réponse http


Les codes de statut de réponse HTTP indiquent si une requête HTTP a été exécutée
avec succès ou non. Les réponses sont regroupées en cinq classes: 
1. Les réponses informatives (100 - 199),
2. Les réponses de succès (200 - 299),
3. Les redirections (300 - 399),
4. Les erreurs du client (400 - 499),
5.  Les erreurs du serveur (500 - 599).

Les codes les plus courants sont :


 200 : succès de la requête ;
 301 et 302 : redirection, respectivement permanente et temporaire ;
 401 : utilisateur non authentifié ;
 403 : accès refusé ;
 400 : page non trouvée ;
 500 et 503 : erreur serveur ;
 504 : le serveur n'a pas répondu.

5.1.1.2.4 Lien entre les ressources


Les liens d’une ressource vers une autre ont tous une chose en commun : ils indiquent
la présence d’une relation. Il est cependant possible de la décrire afin d’améliorer la
compréhension du système. Pour expliciter cette description et indiquer la nature de
la relation, l’attribut rel doit être spécifier sur tous les liens. Ainsi l’IANA (Internet
AssignedNumbersAuthority) donne une liste de relation (self, next,edit, last,
payment, content...)
Exemple :
1. <?xml>
<search>
<linkrel="self"title="self"href="http://mywebsite.com/ serviceEtud/etudiants?
q=formation&nm=STIC&nv=M1"/>
<linkrel="next"title="next"href="http://mywebsite.com/ serviceEtud/etudiants?
q=formation&nm=STIC&nv=M2"/>
<Etudiants>//…
</search>
5.1.1.2.5 un paramètre comme jeton d’authentification
5.1.1.3 Comparaison REST et SOAP
La différence majeure entre ces 2 éléments est le degré de liaison entre le client et
le serveur. Un client développé avec le protocole SOAP ressemble à un logiciel
d'ordinateur, car il est étroitement lié au serveur. Si une modification est effectuée
d'un côté ou de l'autre, l'ensemble peut ne plus fonctionner. Il faut effectuer des
mises à jour du client s'il y a des changements sur le serveur et vice-versa.
Un client de type REST sait utiliser un protocole et des méthodes standardisées.
Son application doit rentrer dans ce modèle. On ne crée pas de méthodes
supplémentaires, on utilise les méthodes standardisées que l'on développe pour le
type de media dont on a besoin. Il y a en conséquence beaucoup moins de
couplage entre le client et le serveur : un client peut utiliser un service de type
REST sans aucune connaissance de l'API. A l'inverse, un client SOAP doit tout
savoir des éléments qu'il va utiliser pendant son interaction avec le serveur, sinon
cela ne fonctionnera pas.
Tableau 4.1:Comparaison de REST et SOAP

SOAP est un protocole. REST est un style d’architecture

SOAP ne peut pas utiliser REST car REST peut utiliser les services Web
c’est un protocole. SOAP car il s’agit d’un concept et
peut utiliser n’importe quel protocole
comme HTTP, SOAP.
SOAP permet que le format XML REST propose différents formats
(WSDL) XML, JSON, CSV, etc

SOAP utilise des services en REST utilise des services en appelant


appelant des RPC methodes des URLs (PUT, GET, POST,
DELETE)

SOAP définit les normes à suivre REST ne définit pas trop de normes
strictement. comme SOAP.

SOAP requière plus de bande REST requière moins de bande


passante et de ressources que REST passante et moins de ressources que
SOAP

SOAP est plus lent que REST REST est plus leger que SOAP

5.2 Proxy
Un proxy est un composant logiciel informatique qui joue le rôle d'intermédiaire en
se plaçant entre deux hôtes pour faciliter ou surveiller leurs échanges.
Dans le cadre plus précis des réseaux informatiques, un proxy est alors un
programme servant d'intermédiaire pour accéder à un autre réseau,généralement
Internet.
5.2.1.Principe de Fonctionnement
Le principe de fonctionnement basique d'un serveur proxy est assez simple : il s'agit
d'un serveur "mandaté" par une application pour effectuer une requête sur Internet à
sa place. Ainsi, lorsqu'un utilisateur se connecte à internet à l'aide d'une application
cliente configurée pour utiliser un serveur proxy, celle-ci va se connecter en premier
lieu au serveur proxy et lui donner sa requête. Le serveur proxy va alors se connecter
au serveur que l'application cliente cherche à joindre et lui transmettre la requête. Le
serveur va ensuite donner sa réponse au proxy, qui va à son tour la transmettre à
l'application cliente.

Un serveur proxy canalise donc toutes les requêtes du réseau interne puis va les
transmettre à l’adresse de l’expéditeur sur le serveur cible sur Internet.

Figure 5.3
:
F o
n c
t i
o n
n e
m e
n t

d’un serveur Proxy


5.2.2.Fonctionalités
Le serveur proxy peut assurer plusieurs rôles parmi lesquels :
 Le fonction de cache : En jargon informatique, une mémoire cache sert à
conserver
localement des informations qui ont une certaine probabilité de servir à nouveau à
court terme. Un serveur proxy stocke provisoirement les pages web que les
utilisateurs vont chercher sur Internet. Si un internaute requiert une information qui se
trouve déjà dans le cache, il sera servi plus rapidement.
 Le rôle d’enregistrement : Comme tout serveur qui se respecte, un proxy
génère un
fichier journal (log file). On y trouve la trace de toutes les requêtes effectuées par
tous
les postes clients dépendant du serveur en question.
 Le filtrage : On peut configurer un serveur proxy de telle sorte qu'il examine le
contenu des paquets qu'il reçoit pour le compte des clients, et qu'il refuse de
transmettre ceux qui ne répondent pas à certains critères.
 L’authentification :Dans la mesure où le proxy est l'intermédiaire
indispensable des
utilisateurs du réseau interne pour accéder à des ressources externes,il est parfois
possible de l'utiliser pour authentifier les utilisateurs, c'est-à-dire de leur demander de
s'identifier à l'aide d'un nom d'utilisateur et d'un mot de passe par exemple. Il est ainsi
aisé de donner l'accès aux ressources externes aux seules personnes autorisées à le
faire et de pouvoir enregistrer dans les fichiers journaux des accès identifiés.
 Les reverse-proxy
On appelle reverse-proxy (en français le terme de relais inverse est parfois employé)
un serveur proxy-cache "monté à l'envers", c'est-à-dire un serveur proxy permettant
non pas aux utilisateurs d'accéder au réseau internet, mais aux utilisateurs d'internet
d'accéder indirectement à certains serveurs internes.
5.2.3.Reverse Proxy
5.2.3.1.Principe de fonctionnement
Contrairement au serveur proxy qui permet à un utilisateur d'accéder au réseau
Internet, le proxy inverse permet à un utilisateur d'Internet d'accéder à des serveurs
internes.Le proxy inverse est la seule connexion entre Internet et le réseau privé.
Toutes les requêtes du serveur d’arrière-plan au réseau local passent par la même
interface de communication avant d’être transférées aux systèmes ciblés. Cette mise
en commun permet ainsi de contrôler les données du trafic entrant et autorise.

Figure

5.4 : Principe de reverse proxy


5.2.3.2.Fonctionnalités
Le serveur proxy assure plusieurs fonctionnalités :
 L'équilibrage de charge :
L'équilibrage de charge permet à des millions d'utilisateurs d'avoir un accès
permanent à une ressource Web rapidement. Il consiste à répartir la charge des
requêtes web sur plusieurs serveurs et le rôle du proxy inverse est de garantir que
chacun d'eux traite le même nombre de requêtes pour éviter les débordements.
 L’Anonymisation :
Le reverse-proxy intercepte toutes les requêtes avant de les transmettre au système
ciblé.Ainsi l'adresse IP réelle du serveur Web n'est jamais révélée. 
 Le Cache :
Il permet d’accélérer la vitesse du service grâce à son système de mise en
cache. Nous avons mentionné précédemment que les proxys, côté client, peuvent agir
comme un serveur de cache pour les ressources Web fréquemment visitées, afin de
maximiser l'expérience utilisateur. Cependant, côté serveur, cela est également
applicable, d'autant plus si les serveurs Web d'origine sont situés dans des endroits
très éloignés de la plupart des utilisateurs d'un site Web.
 Cryptage SSL(Secure Socket Layer) :
C'est extrêmement pratique à appliquer. Étant donné que le serveur proxy inverse
sera en mesure de décrypter facilement toutes les demandes Web générées et lorsqu'il
aura la réponse pour le client du serveur Web d'origine, il les cryptera afin qu'il puisse
voyager et y accéder. Et c'est pratique car il économise beaucoup de ressources pour
le serveur Web et l'utilise donc d'autres façons pour améliorer les performances.
Ce chapitre nous a permis d’étudier les technologies web services à savoir REST et
SOAP.Nous avons aussi eu à définir le principe de fonctionnement des serveurs
proxy et leurs fonctionnalités avant de d’aborder les reverse proxy.

chap6:Proposition d’une solution


Introduction
6.1 Analyse des besoins
En vue de la réalisation de notre système, un ensemble de fonctionnalités doit être défini. La
spécification fonctionnelle correspond à la description de l’ensemble des fonctionnalités de
notre système. Cette description doit permettre aux différents acteurs de réaliser toutes les
opérations qui les concernent.
6.1.1 les besoins fonctionnels
6.1.1.1 Les acteurs du systèmes
Un acteur est une « entité » externe au système qui interagit avec le système.Une même entité peut
être plusieurs acteurs pour un système, c'est pourquoi les acteurs doivent surtout être décrits par leur
rôle, ce rôle décrit les besoins et les capacités de l'acteur. Un acteur agit sur le système. L'activité du
système a pour objectif de satisfaire les besoins de l'acteur.
Les acteurs de notre système sont :
 Pilote :qui assure l’activation des services d’internet, de téléphonie et de la télévision pour
les clients fibre.
 Commercial :responsable de la prise en charge et de l ‘enregistrement des demandes des
clients.
 Administrateur :chargés de gérer les différents profils des utilisateurs, ainsi que leurs droits
d’accès à certaines fonctionnalités de l’application.
 Agent SCU :Il est charger de réceptionner les modems et de les enregistrer dans
SMART_CONFIG.
6.1.1.2 Découpage en modules
Notre système doit permettre aux pilotes d’accéder aux différentes
applications du service PPCF après authentifiés une seule fois.Elle consiste
à mettre en place une interface permettant aux pilotes d’accéder aux
différentes applications du système informatique comme s’il s’agissait
d’une.Les fonctionnalités du système peuvent être regroupées en 5
modules :

Figure 6.1:Architecture fonctionnelle du système


6.1.1.1 AMS
Il permet aux pilotes d’activer les services d’internet,de VOIP et de la
télévision pour les équipements NOKIA.Il offre l’option d’augmenter ou
de diminuer le débit ou de casser la configuration pour un client qui
bénéficie des services.
6.1.1.2 U2000
U2000 permet aux pilotes d’effectuer les mêmes tâches qu’avec AMS pour
équipements HUAWEI.
6.1.1.3 GAIA
Ce module permet aux acteurs du système d’ajouter une
demande,d’enregistrer de faire la provision de la carte VIACC et
d’enregistrer l’état de la demande
6.1.1.4 SMART_CONFIG
Ce modules comportes différentes fonctionnalités permettant aux agents
SCQ d’enregistrer les modems.Grace à ces fonctionnalités les pilotes
peuvent récupérer les accès et ajouter un client.
6.1.1.5 Module SRU
Grâce à ce module les pilotes peuvent créer un compte UMS pour le clent,
vérifier si les configurations pour la télévision sont correctes et augmenter
le flux.
Mis à part toutes ces fonctionnalités,l’administrateur peut créer des
identifiants pour les employés.
6.1.2 Besoins non fonctionnels
Cette permette devra permettre à la au département PPCF :
 D’optimiser temps :
L’automatisation de certaines tâches permet aux pilotes de gagner du temps dans la
configuration des services
 De réduire les coûts de main-d’œuvre
L’optimisation du temps permet à chaque pilote de prendre en charge plus de
demande ce qui permet de limiter le nombre d’employés.
 Réduction des erreurs humaines :
Les pilotes n’ont plus à saisir les mêmes informations pour effectuer les
configurations pour chaque client ce qui réduit les erreurs
6.1.3 L’Analyse
Pour mieux faciliter l’analyse, les différentes fonctionnalités du système sont
regroupées en quatre (04) modules fonctionnels :
6.1.3.1 AMS
Le diagramme ci_dessous permet de spécifier les différentes fonctionnalités de ce sous_système :
Figure 6.2 :Fonctionnalités du module AMS
6.1.3.2 U2000
La figure 6.3 permet de décrire les fonctionnalités offertes par le système :

Figure 6.3:Fonctionnalités du sous_système U2000


6.1.3.3 GAIA
Ce module peut être représenté comme suit :

Figure 6.4:Description du module GAIA


6.1.3.4 SMART_CONFIG
6.1.3.5 SRA

Figure 6.6:Fonction du module SRA


6.2 Conception
6.2.1 Conception Générale
Suite aux études réalisées précédemment, nous déduisons que le système d’intégration des
applications de PPCF sera composé d’un ensemble de composants.La figure ci_dessous montre les
différents composants du système :
Figure

6.7 :Architecture générale
6.2.2 Conception détaillée
6.2.2.1 choix des Technologies
6.2.2.1.1 REST
6.2.2.1.2 Python
Python est un langage de programmation puissant et facile à apprendre. Il
dispose de structures de données de haut niveau et permet une approche simple
mais efficace de la programmation orientée objet.

Parce que sa syntaxe est claire, que son typage est dynamique et qu’il est
interprété, Python est un langage idéal pour l’écriture de scripts et le développement
rapide d’applications dans de nombreux domaines et sur la plupart des plateformes.
L’ensemble des outils, des librairies, la communauté ; en somme, tout ce qui gravite
autour du langage lui-même en fait outil de choix.
6.2.2.1.3 Flask
Flask est un framework open-source de développement web en Python. Son but
principal est d’être léger, afin de garder la souplesse de la programmation Python,
associé à un système de templates.
6.2.2.1.4 Sqlite
SQLite est une bibliothèque écrite en langage C qui propose un moteur de
base de données relationnelle accessible par le langage SQL. Contrairement aux
serveurs de bases de données traditionnels, sa particularité est de ne pas reproduire
le schéma habituel client-serveur mais d’être directement intégrée aux programmes.
L’intégralité de la base de données (déclarations, tables, index et données) est
stockée dans un fichier indépendant de la plateforme.

6.2.2.1.5 Php
PHP(Hypertext Preprocessor), est un langage de programmation libre19,
principalement utilisé pour produire des pages Web dynamiques via un serveur HTTP,
mais pouvant également fonctionner comme n'importe quel langage interprété de
façon locale. PHP est un langage impératif orienté objet.
PHP a permis de créer un grand nombre de sites web célèbres,
comme Facebook et Wikipédia. Il est considéré comme une des bases de la création
de sites web dits dynamiques mais également des applications web.

6.2.2.1.6 mysql
MySQL est le système de gestion de base de données SQL relationnel Open Source le plus
populaire. MySQL est l’un des meilleurs SGBDR utilisé pour le développement de diverses
applications logicielles Web. MySQL est développé, commercialisé et supporté par MySQL
AB, une société suédoise. Ce tutoriel vous permettra de démarrer rapidement avec MySQL et
de vous familiariser avec la programmation MySQL.

6.2.2.1.7 SQLAlchemy
SQLAlchemy est la boîte à outils Python SQL et Object Relational Mapper
(ORM) qui offre aux développeurs d’applications toute la puissance et la flexibilité
de SQL.
Il fournit une suite complète de modèles de persistance d’un niveau d’entreprise
conçus pour un accès efficace et performant aux bases de données, adaptés dans un
langage de domaine simple et pythonique.
6.2.2.1.8 Apache2
Apache est un logiciel de serveur web gratuit et open-source qui alimente environ 46%
des sites web à travers le monde. Le nom officiel est Serveur Apache HTTP et il est
maintenu et développé par Apache Software Foundation.
Il permet aux propriétaires de sites web de servir du contenu sur le web d’où le nom
« serveur web » . C’est l’un des serveurs web les plus anciens et les plus fiables avec une
première version sortie il y a plus de 20 ans, en 1995.

6.2.2.2 Architecture détaillée


6.2.3 Outils pour le Déploiement
6.2.3.1 Conteneur
Tout comme dans le domaine des transports, les conteneurs informatiques
stockent des objets pour les transporter. Ils permettent d’expédier des
applications et leurs dépendances sur de multiples systèmes d’exploitation,
quels qu’ils soient. Ils garantissent que leur contenu est identique au départ
et à l’arrivée, et qu’il est sécurisé, grâce à leur mise en isolation.
Ils servent à minimiser la complexité liée à la configuration et à
l’administration applicatives, à accélérer les cycles de développement et de
production applicatifs, et, grâce à leur flexibilité et à leur portabilité.
La conteneurisation est une méthode qui permet de virtualiser, dans un
conteneur, les ressources matérielles , systèmes de fichiers, réseau,
processeur, mémoire vive, etc. ‒ nécessaires à l’exécution d’une
application. Dans cet espace sont aussi stockées toutes les dépendances des
applications : fichiers, bibliothèques, etc. Pour déplacer les applications
virtuelles d’un système d’exploitation à un autre, le conteneur se connecte
à leur noyau , ce qui permet aux différents composants matériels et
logiciels de communiquer entre eux.
6.2.3.2 Docker
Docker est une plate-forme open source pour développer, gérer et déployer des
applications à l'aide de conteneurs.
Docker élimine les tâches de configuration répétitives et banales et est utilisé tout
au long du cycle de développement pour un développement d'applications rapide,
facile et portable - bureau et cloud. La plate-forme complète de bout en bout de
Docker comprend des interfaces utilisateur, des interfaces de ligne de commande,
des API et une sécurité conçues pour fonctionner ensemble tout au long du cycle
de vie de livraison des applications.
Il présente plusieurs avantages :
1. Flexible :Toute application peut être transformée en conteneur

2. Léger :Contrairement à la virtualisation classique, Docker exploite et partage


le kernel du système d’exploitation de l’hôte, ce qui le rend très efficace en terme
d’utilisation des ressources du système

3. Portable :Il est possible de créer, déployer et démarrer des conteneurs sur son


ordinateur, celui de ses clients ou un serveur distant

4. Auto-suffisant :L’installation et la désinstallation de conteneurs ne dépend pas


des autres conteneurs installés. Ce qui permet de mettre à jour ou remplacer
un conteneur sans modifier les autres

5. Scalable :Dupliquer un container est extrêmement simple, ce qui permet de


réaliser de la scalabilité horizontale(ajouter de nouveaux serveurs réalisant le même
type tâche) aisément

6. Sécurisé :Par défaut, Docker crée des conteneurs en appliquant des règles de


sécurité strictes et isole les processus.

6.2.4 Dimensionnement des Conteneurs


Conclusion