Emmanuel roch





télécharger 0.94 Mb.
titreEmmanuel roch
page7/12
date de publication23.10.2017
taille0.94 Mb.
typeManuel
e.20-bal.com > documents > Manuel
1   2   3   4   5   6   7   8   9   ...   12
PARTIE IV : LE PROJET « INTERFACES WEB TÉLÉMATIQUES »

1. Etude préalable

1.1 Note d’orientation
Contexte et objectifs
Cette étude préalable a pour objet de définir les orientations futures de l’environnement STEPE. Il s’agit alors de proposer des solutions d’évolutions technologiques afin de répondre au mieux aux attentes des clients tout en respectant les spécifications du groupe. STEPE est un environnement de développement et de démonstration utilisé par le groupe, pour le déploiement de services télématiques. Il est composé d’un serveur Sunone, d’une base de données Oracle et d’un EAI (Entreprise Application Intégration).
Les objectifs et les enjeux :


  • Faire évoluer les interfaces STEPE vers un environnement répondant aux normes de développement fixées par le groupe.

  • Réaliser et organiser les interfaces de la plateforme STEPE.


Périmètre de l’étude
L’étude préalable traitera des évolutions futures de l’environnement STEPE dans les domaines suivants :


  • Architecture applicative :




    • Étudier les choix technologiques de la DSIN en matière de développement web.

    • Proposer des perspectives d’évolution de l’architecture STEPE afin qu’elles puissent répondre aux normes préconisées par le groupe.

    • Déterminer et évaluer la charge de la mise à niveau de l’application.




  • Architecture physique :




    • Étudier l’organisation générale de la plateforme télématique STEPE. L’objectif vise à optimiser l’organisation de l’information au sein même de l’application STEPE (services télématiques, outils de gestion, outils d’administration).

    • Étudier et déterminer l’organisation et l’intégration des interfaces clientes dans l’environnement STEPE, en tenant compte de la diversité des utilisateurs.

    • Établir des normes graphiques propres à chaque interface cliente (PSA, Peugeot, Citroën., SUAL, RG etc.).




      • Les services télématiques :




    • Analyser les services existants, étudier la possibilité d’en améliorer l’ergonomie et la convivialité par l’intermédiaire de nouvelles interfaces.

    • Étudier la mise en place d’un service et d’une interface pour le projet X6/SUAL (définition des besoins et réalisation).




  • Gestion des utilisateurs :




    • Définir l’ensemble des profils utilisateurs en fonction des différents services télématiques et interfaces.

    • Améliorer la sécurité et la confidentialité de la plateforme STEPE par la mise en place d’une meilleure gestion des profils utilisateurs.

    • Étudier les choix technologiques proposés par la DSIN en matière de gestion des profils utilisateurs et de connexion à la plateforme (LDAP).


Note d’engagement et planning
La note d’engagement est l’un des derniers documents qui précède la phase de développement d’un projet informatique. Elle doit répondre à toutes ces questions :


  • Quels sont les engagements réciproques (en terme de coûts, de délais, de spécifications, de services, de retour sur investissement, de disponibilité des ressources) de la MOA et de la MOE ?

  • Comment est découpé le projet de réalisation ?

  • Quels sont les flux d’informations entre les phases du projet ?

  • Quelle est la composition de l’équipe projet ?

  • Quels sont les contraintes et les risques (fonctionnels et techniques) pesant sur le projet ?

Enfin, ce document doit présenter les caractéristiques du projet, c'est-à-dire le plan de développement et de mise en œuvre (en précisant les livrables), dates clés, ainsi que criticité et le degré d’urgence.

Pour la réalisation de ce projet, nous nous étions engagé à livrer les interfaces dans fin septembre (2 mois après le début des développements). La tableau ci-dessous décrit les différentes phase du projet et la charge de travail en terme de jour / homme.


3 jours




2 jours

3 jours

2 jours

13 jours





1 jour

5 jours

5 jours

7 jours

2 jours

TOTAL : 41 Jours




1.2 Définition des besoins
Interfaces web télématiques
Les interfaces web télématiques mettent à la disposition des utilisateurs de nombreux services télématiques. L’objectif est de proposer de nouvelles spécifications fonctionnelles facilitant leurs utilisations. Ce travail sera fait dans le but d’améliorer l’ergonomie, la convivialité de ces interfaces. Un second point essentiel est d’optimiser le comportement des interfaces, notamment en matière de communication avec Webmethods. Enfin, tous ces développements devront être réalisés dans le but de faire évoluer les interfaces web télématique vers un environnement répondant aux normes de développement fixées par le groupe.
Interfaces Crashs Test
Le contexte :
À la demande de DRIA, DSIN étudie la mise en œuvre d’un service télématique dédié au CRASH Test. Une réunion a été organisée afin de prendre connaissance des attentes et des besoins des futurs utilisateurs (service DPTA/DMFV/SSV/SPB/ESS site de Belchamp). Les interfaces seront développées dans le souci d’offrir un environnement convivial, simple d’utilisation et respectant les normes du groupe (aussi bien d'un point de vue fonctionnel que technique).
À l’heure actuelle, les équipes réalisant les crashs fonctionnent de la manière suivante :


  • Configuration du RT3 via les interfaces PESTE. L'accès à ces interfaces étant limité, le véhicule ne peut pas être créé par les équipes de Belchamp et une demande doit être adressée à l'équipe PESTE.

  • Avant le crash : vérification du paramétrage en faisant un appel manuel depuis le véhicule. Seul l’appel voix est vérifié ;

  • Après le crash : le décodage de la trame SMS est réalisé sur demande de ESS par CVCO, le résultat est ensuite envoyé par mail.


L’objectif premier de l’application est de configurer le véhicule et d'activer les services télématiques. Ces deux étapes sont nécessaires à la vérification du déclenchement de l’appel d’urgence émis lors du crash d’un véhicule équipé d’un matériel RT3. Plus précisément, l’appel d’urgence est constitué d’un SMS et d’un appel voix, il s’agit alors de vérifier que l’envoi de ces deux types de messages a bien eu lieu. Ce document à pour objectif de présenter les besoins fonctionnels des interfaces définis lors de la réunion du 29 juin.
Identification des besoins :
Les interfaces nécessaires à la vérification du bon fonctionnement de l’appel d’urgence sont divisées en deux parties distinctes. Une première partie correspond à la configuration du matériel embarqué (RT3), une autre a pour vocation de présenter les résultats.


  • Une interface de paramétrage (configuration matérielle)


Cette interface a pour objectif de configurer le matériel embarqué (RT3) du véhicule. Elle se compose des éléments suivants :


  • Un formulaire permettant à l’utilisateur de renseigner trois informations nécessaires à la configuration du matérielle RT3 :




    • Le numéro de VIS doit être saisi par l’utilisateur dans un champ spécifique ;

    • Le numéro vocal est le numéro vers lequel sera redirigé l’appel téléphonique émis lors du crash ;

    • La version du RT3 doit être sélectionnée dans un menu déroulant, celui-ci contient toutes les versions logicielles du RT3 prisent en charge par l’application (5.4, 5.6 etc.).




Exemple de VIN : VF7 LC 9HYB 74233278


1

2



1- Marque du véhicule

2- VIS numérique

Le numéro utilisé par le RT3 est la partie 1 suivi de la partie 2 (Type de véhicule + VIS).




  • Une zone est réservée à l’affichage des données de configuration et à l’exécution du paramétrage. Cette zone non modifiable par l’utilisateur (réservé à l’administrateur) comprend les éléments suivants :




    • Le numéro de GSM ;

    • Le numéro court ;

    • L’opérateur téléphonique avec son numéro de sms-center;

    • Une action au niveau des interfaces permet l’activation des services nécessaires au bon déroulement de la configuration du RT3 (E-call, B-call et le provisionning) ;

    • Une seconde action, indépendante ou lié à la première, met à jour les services préalablement activés ;


Après la configuration du véhicule, les interfaces indiquent si le véhicule a été correctement paramétré en affichant à l’écran un message convivial. Néanmoins, il est essentiel de vérifier le bon fonctionnement du RT3 après sa configuration ; il faut pour cela déclencher un appel manuel depuis le véhicule et vérifier que l’appel voix a bien eu lieu et que le SMS a bien été reçu par les interfaces.


  • Une interface de visualisation du résultat


Cette interface a pour objectif de visualiser à travers un historique l’ensemble des trames SMS envoyé lors des crashs. Les éléments qui composent cette interface sont les suivants :


    • Une zone d’affichage répertorie les trames SMS des ‘X’derniers crashs dans un tableau, le nombre de crash présentés dans le tableau sera déterminé en fonction de l’espace disponible au niveau des interfaces ;

    • Une fonctionnalité manuelle et/ou automatique (à définir dans l'étude) permet la mise à jour des dernières données du tableau.

    • Par défaut, les crashs sont triés par date ; une action au niveau des interfaces permet de trier les crashs par type de véhicule.

    • Possibilité d’imprimer une campagne de crash par type de véhicule et par intervalle de date.



Contenu de la trame SMS décodée :
Le SMS envoyé par le véhicule, lorsque celui-ci subit un choc (ou lorsqu’il déclenché manuellement au niveau du RT 3), est visible immédiatement au niveau des interfaces. Le SMS est décodé et fournit les informations suivantes :


    • Type d’appel – E-call, B-call

    • Heure réelle – heure du crash et non celle du RT3

    • Version du RT3

    • VIS

    • Numéro de téléphone du centre d’appel

    • Airbag véhicule déclenché

    • Activation manuelle

    • Chocs détectés

    • Retournement véhicule

    • Moteur tournant

    • Absence + APC - Indique la position de la clé





Liste des utilisateurs et de leurs profils :


UTILISATEURS

PROFILS

Bachir BOUDJAHLAT

Utilisateur avec pouvoir

Sébastien ADOLPHE

utilisateur

Jonathan WILL

utilisateur

Gabriel ROY

utilisateur

Jean Vincent MAUVAIS

utilisateur

Christophe DELAMESURE

utilisateur


Informations complémentaires :


    • La fréquence des crashs est estimée à 5/6 chocs par semaine, mais cette fréquence peut varier selon les campagnes de crash ;

    • Les tests sont limités aux cartes SIM des opérateurs français, puisqu’une seule carte est fournie par DRIA ;

    • L‘application est disponible seulement via le réseau intranet du groupe ;

    • L’application n’est pas destinée à être Multi-Utilisateur ;

    • Conserver un historique de 12 mois pour les trames SMS ;

    • Réalisation d’un manuel utilisateur et administrateur.


1.3 Recherches des solutions techniques et fonctionnelles

Environnement de développement
IRWD (IBM Rationnal Web Developper) est l’environnement de développement qui est utilisé dans la réalisation des interfaces web. L’application web est hébergée sur un serveur Sunone web server 6.12 (serveur PYASQ2), les bases de données étant gérées par Oracle (version 9i).
Architecture applicative :
Dans le cadre de la mise aux normes des interfaces télématiques, le groupe recommande l’utilisation du framework LEGO pour le développement d’applications web. LEGO est un framework technique de composants J2EE basé sur Struts, il est utilisé pour le développement d'applications PSA. Le framework couvre les fonctionnalités suivantes :

  • Persistance (OJB, framework SQL) : Le framework propose une alternative entre deux solutions de persistance : une 1ère solution basée sur l'outil de mapping objet relationnel OJB et une 2ème solution basée sur un framework JDBC classique.

  • Services métiers : Un service métier correspond à l'implémentation d'une fonctionnalité métier avec les règles de gestion associées. Les services métier répondent ainsi à l'ensemble des cas d'utilisations de l'application.

  • Struts : Le framework Struts implémente le modèle d'architecture MVC2 (Model-View-Controller). Cette fonctionnalité sera décrite plus précisément par la suite.

  • Traces : Elles jouent un rôle très important en phase de débogage ainsi qu'en phase d'exploitation. Il faut donc s'astreindre, lors de la phase de développement à placer des traces dans le code aux endroits clés.

  • Multilinguisme : La solution de multilinguisme du framework est basée sur l'interface. Elle offre les services suivants : Lecture/MAJ d'un message internationalisé, Import/Export des données, Gestion des locales. Nous n’utiliserons pas l’outil d’internationalisation proposé par le framework, puisque notre application n’a pas vocation à être utilisé par des utilisateurs non francophones.

  • Sécurité applicative : La solution de sécurité applicative proposée par le framework s'articule autour des trois concepts suivants : l'utilisateur, le profil et le rôle.

Struts est un environnement de développement Java open source. Cet environnement permet d'assurer l'évolution des applications Web, de diminuer les coûts et les délais de développement, et d'accroître la fiabilité des applications. Les framework se sont imposés comme une alternative très avantageuse aux servlets et aux JSP en matière de développement d'applications Web en Java.
Les normes de développement PSA préconisent l’utilisation du modèle MVC dans le cadre de déploiement d’applications web. MVC est un modèle de conception qui impose la séparation entre les données, les traitements et la présentation. C'est pour cette raison que l'application est divisée en trois composants fondamentaux : le modèle, la vue et le contrôleur.
Le modèle, représente les données et les règles métier. C'est là que s'effectuent les traitements. Les bases de données en font partie, de même que des objets tels que les EJB et composants Cold Fusion. Les données renvoyées par le modèle sont indépendantes de la présentation, c'est-à-dire que le modèle ne réalise aucune mise en forme. Les données d'un seul modèle peuvent ainsi être affichées dans plusieurs vues. Cette capacité permet de factoriser le code, car le code du modèle n'est écrit qu'une seule fois puis réutilisé par toutes les vues.
La vue correspond à l'interface avec laquelle l'utilisateur interagit. Dans le cas des applications web, il s'agit dans la plus part du temps d'une interface HTML. Si le HTML reste l'interface dominante pour les applications web, de nouveaux formats sont rapidement apparus. L'un des grands avantages du MVC tient au fait qu'il gère l'utilisation de différentes vues pour votre application. Aucun traitement n'est effectué dans la vue; elle sert uniquement à afficher les données et permettre à l'utilisateur d'agir sur ces données.
Le contrôleur interprète les requêtes de l'utilisateur et appelle du modèle et de la vue nécessaires pour répondre à la requête. Ainsi, lorsque l'utilisateur clique sur un lien où soumet un formulaire HTML, le contrôleur ne produit rien et n'effectue aucun traitement. Il intercepte la requête et détermine quels modèles et quelles vues doivent êtres associés.
Pour résumer, une requête utilisateur est interprétée par le contrôleur, qui détermine quelles portions du modèle et de la vue doivent être appelées. Le modèle gère les interactions avec les données et applique les règles métier, puis renvoie les données. Enfin, le contrôleur sélectionne une vue et lui passe les données en paramètre.

Schéma du modèle MVC

Les tiles :
L’organisation générale des pages ne se fera plus par l’intermédiaire de frame mais par la mise en place des Tiles. En effet, cette technologie préconisée par le groupe est plus simple à mettre en œuvre et plus facile à maintenir.


Le framework SQL/OJB :
Le framework OJB (ObjectRelationalBridge) d’Apache est un framework de mapping Objet/Relationel. Il assure la gestion de la persistance d’objets Java dans une base de donnée relationnelle (SGBDR). Toutes les requêtes SQL sont générées automatiquement par OJB. Le développeur ne manipule plus que des objets Java au travers d’une API de persistance : la PersistenceBroker API.
Le framework SQL n’a pas vocation à remplacer OJB. Il offre une alternative à OJB dans la réalisation de requêtes complexes et difficiles à appréhender avec OJB en proposant une meilleure visibilité de la requête soumise à la base de données. Chaque requête à la base sera représentée par un objet facilitant l’édition de ses propriétés (la requête sera directement éditable sous forme de chaîne de caractère). Le framework SQL s’appuie sur les services OJB et obéit aux mécanismes transactionnels fournis par OJB (commit/rollback). Il facilite la génération de jointures et réalise les requêtes à la base de données sous forme de Prepared Statement. Toutes ces spécificités permettent d’utiliser conjointement ces deux framework SQL ce qui permet d’assurer une plus grande marge de manoeuvre sur les techniques d’accès aux données.
Normes de développement pour les applications web
Voici la liste des règles à respecter lors du développement d’une application web, en cas de non respect, la DSIN se réserve le droit de refuser l’industrialisation de l’application concernée.


Règles

Libellé

1

Les sites Web doivent rester compatibles avec les deux navigateurs Internet Explorer 5.5 et Netscape 7.0./Mozilla 1.0 et les versions supérieures de ces navigateurs.

2

La version du langage HTML utilisée doit être la version 4.0.

3

La version du langage JavaScript utilisée doit être au maximum la 1.4.

4

Les liens hypertextes internes à un site Web ne doivent pas être absolus et ne doivent jamais spécifier le protocole, le nom ou l'adresse IP du serveur.

5

Le poids total d'une page Web ne doit jamais excéder 50 Koctets (hors téléchargement de documents).

6

Les sites web ne doivent pas nécessiter de plugins autres que ceux fournis en standard avec les navigateurs indiqués ci-dessus.

7

L’utilisation de contrôles Active X ou d’applets Java sur la partie cliente d’un site Web doit être un cas particulier et est tolérée uniquement s’il n’est pas possible de faire autrement.

8

L'utilisation de Flash ne doit pas être retenue pour réaliser la navigation dans un site web.


Dans le cadre des futurs développements des interfaces web, l’un des objectifs est de mettre en place une solution de sécurité des interfaces tant au niveau de l’accès au contenu qu’a celui de la navigation. Le groupe PSA impose des normes de développement pour la mise en place d’une solution de sécurité applicative. Ces normes de sécurité sont à la charge du service REUNIS (REférentiel UNIque Sécurité). Il met à disposition des équipes projets des outils dédiés à la sécurité. Ces outils permettent de répondre à trois questions fondamentales :



    • Qui ? : Cette application permet de consulter l’ensemble des identifiants utilisés dans le groupe (personnel interne PSA, les externes/prestataires, Agape, GEFCO etc.).

    • Quoi ? : Le Catalogue des Services référence toutes les applications sécurisées. Pour chaque application, sont définis, fonctionnellement, les différents profils d'accès possibles (les services), chacun d'eux donnant un certain nombre de droits à une application ou un système d'information. Les services sont définis par les équipes projets et mis à disposition des utilisateurs. Selon la confidentialité de chaque service, il pourra être attribué par un ASL7, ou par le propriétaire du service.

    • Qui peut quoi ? : ADMReunis répond à cette question en faisant un lien entre le contenu du Référentiel des Identifiants et le Catalogue des Services. ADMReunis est l'outil de travail des ASL, il permet aux ASL d'attribuer aux utilisateurs de leur périmètre des moyens d'authentification (mot de passe, carte securID, certificat électronique) et des services (attribution / retrait de services définis dans le catalogue).


Concernant le service de contrôle d'accès au système d’information, Reunis propose une infrastructure LDAP. Cette infrastructure se compose de plusieurs serveurs redondants, placés derrière un répartiteur de charges. Cet ensemble permet de bénéficier d'un service d'interrogation, de consultation LDAP, donc de contrôle d'accès répondant à un DIC (Disponibilité Intégrité Confidentialité) de D=3.
L’annuaire LDAP PSA est le référentiel de sécurité du groupe PSA. Il contient toutes les informations liées à la sécurité logique ou physique : déclaration d’utilisateurs et affectation de tous les droits auxquels ils peuvent prétendre.
Dans les applications, l’annuaire PSA est principalement utilisé pour l’authentification d’utilisateurs et la gestion des accès aux données. L’annuaire LDAP permet de :


  • Sécuriser des applications dans le sens où chaque utilisateur doit s’identifier par la saisie d’un identifiant et d’un mot de passe RPI.

  • Affecter un profil aux utilisateurs. L’accès aux données est déterminé suivant les groupes LDAP auxquels l’utilisateur appartient.


Il existe deux modes d'attribution des services :


  1. ASL : Un utilisateur fait une demande d’accès à une application, l’ASL traduit ce besoin en service. Les RSLD8 sont chargés de valider chaque demande de copie du service de référence émanant de leurs ASL. Une fois la copie de service obtenue, l’ASL peut l’attribuer aux utilisateurs du département REUNIS dans lequel la copie a été demandée. Cette attribution est automatique, le propriétaire n’a pas besoin d’intervenir pour la valider.

  2. ASL + propriétaire : Le circuit des demandes de copies de services est identique à l’option précédente. Mais une validation de chaque attribution est systématiquement demandée au propriétaire du Service de référence.


Quelque soit le mode d’attribution, le propriétaire conserve une vue de l’ensemble des copies existantes de ses services. Il peut également à tout instant retirer un utilisateur de la liste des ayants droits ou même supprimer une copie de l’un de ses services.
Le schéma ci-dessous résume les différentes étapes à suivre par un ASL lorsqu’il doit attribuer pour la première fois un service à un utilisateur :



Recherche des solutions de sécurité
En ce qui concerne les interfaces STEPE, les droits utilisateurs peuvent être attribué à chaque service et outils de gestion. Le tableau ci-dessous présente un exemple des différents profils utilisateurs.





INTERFACES STEPE

SERVICES TELEMATIQUES

OUTILS DE GESTION

POI

TDG

TRK

TEX

PRO

DEV

INT

SDS

TKT

GDC

GAF

Administrateur

X

X

X

X

X

X

X

X

X

X

X

Utilisateur std 1

X







X




X




X

X







Utilisateur std 2




X

X

X

X










X




X

Utilisateur std 3

X




X










X

X

X








Le nombre total de profils possible avec une tel configuration est de 211 soit 2 048 combinaisons de profils différents.
Les profils d’accès à la plateforme sont déterminés par le propriétaire, REUNIS se charge ensuite de traduire se besoin fonctionnel en service. Pour les interfaces STEPE, le nombre de profil différent est élevé pour un nombre d’utilisateurs réduit (moins de 50). La traduction de tous ces profils en service est difficilement réalisable, cependant différentes solutions permettrait de répondre aux besoins de sécurité de la plateforme :


  1. Définir des profils utilisateurs type afin de réduire leur nombre. Il est important de bien définir les profils utilisateurs types car il seront amenés à être réutilisés :







INTERFACES STEPE

SERVICES TELEMATIQUES

OUTILS DE GESTION

POI

TDG

TRK

TEX

PRO

DEV

INT

SDS

TKT

GDC

GAF

Administrateur

X

X

X

X

X

X

X

X

X

X

X

Utilisateur avec pouvoir

X

X

X

X

X

X




X

X




X

Utilisateur télématique 1


































Utilisateur télématique 2



































Avantages : Cette solution est peu coûteuse en service, donc plus facile à gérer par le propriétaire et l’ASL.

Inconvénients : Cette solution n’offre pas la possibilité d’avoir une sécurité d’accès à chaque service télématique et chaque outil de gestion.


  1. Mise en place des services applicatifs $domain$


Il existe des services applicatifs ayant des attributs complémentaires variables appelés « $domain$ ». Ces attributs complémentaires doivent être valorisés par le propriétaire dès lors qu’il reçoit la copie de service émise par l’ASL et validé par le RLSD. Ces attributs servent à définir le périmètre des données qui seront accessibles par la copie du service accordé.
Avantages : - Toute la sécurité est administrée en externe.

- Possibilité de prendre en compte toutes les déclinaisons de profils possible.
Inconvénients : - Création de nombreux services applicatifs, cela peut poser problème lors de l’ajout d’un nouveau service télématique.

- L’activation des droits pour un utilisateur est coûteuse (temps, délais).

- La multiplication des services entraîne une difficulté d’administration aussi bien pour le propriétaire que pour l’ASL.

- Difficile à mettre en œuvre pour une population importante d’utilisateur web.


  1. Gérer en interne la sécurité au niveau des services et outils de gestion


Cette alternative utilise la sécurité de l’authentification via l’annuaire LDAP couplé à une logique interne de restriction de droits sur les services télématiques et les différents outils de gestion. Il suffit alors de mettre en place deux profils différents (deux services), un administrateur et un utilisateur standard. Grâce à une logique interne et par l’intermédiaire d’une interface, on accorde des droits d’accès aux utilisateurs standard préalablement autorisé à se connecter à la plateforme.
Avantages : Seulement deux services applicatifs sont nécessaires pour la mise en place de cette solution.

Inconvénients : - La sécurité de la plateforme n’est pas entièrement internalisée.

    • Charge supplémentaire pour le développement de la partie internalisée.




  1. Création de onze services applicatifs


Cette solution consiste à créer onze services applicatifs du coté de ADMReunis. On pourra alors attribuer plusieurs services applicatifs à un même utilisateur. Voici la liste des services applicatifs à créer :


Services applicatifs

Description

Légende :

TEL : Interfaces web télématique

SE2 : PRI du projet STEPE

USR : Utilisateur

ADM : Administrateur

PS : Pour les interfaces Crash Test on utilisera CRH à la place de TEL (RGS pour Roland Garros)

ADM_SE2_TEL 

USR_SE2_TEL _POI

USR_SE2_TEL _TDG

USR_SE2_TEL _TRK

USR_SE2_TEL _TEX

USR_SE2_ PRO

USR_SE2_TEL _ DEV

USR_SE2_TEL _ SDS 

USR_SE2_TEL _ TKT 

USR_SE2_TEL _ GDC

USR_SE2_TEL _ GAF

administrateur dispose de tous les droits

utilisateur ayant des droits sur POI (Envoi d’adresse)

utilisateur ayant des droits sur TDG (Télédiagnostic)

utilisateur ayant des droits sur TRK (Localisation)

utilisateur ayant des droits sur TEX (Texto)

utilisateur ayant des droits sur PRO (Configuration matérielle)

utilisateur ayant des droits sur DEV (Déviation Point)

utilisateur ayant des droits sur SDS (Suivi de service)

utilisateur ayant des droits sur TKT (Ticketing)

utilisateur ayant des droits sur GDC (Gestion des clients)

utilisateur ayant des droits sur TEX (Gestion des adresses favorites)
1   2   3   4   5   6   7   8   9   ...   12

similaire:

Emmanuel roch iconCours de Monsieur Mouline par Michaël Roch cm de Stratégie et Qualité
«l’art de positionner ses troupes avant la bataille, d’établir des positions défendables et durables, donc choisir le terrain, le...

Emmanuel roch iconEmmanuel Kemel

Emmanuel roch iconEmmanuel spitz

Emmanuel roch iconEmmanuel constans

Emmanuel roch iconEmmanuel dockes

Emmanuel roch iconEmmanuel chene

Emmanuel roch iconEmmanuel Arnaud

Emmanuel roch iconEmmanuel Gaudez

Emmanuel roch iconEmmanuel champs

Emmanuel roch iconEmmanuel César & Bruno Richard






Tous droits réservés. Copyright © 2016
contacts
e.20-bal.com