I. Remerciements *

II. Prise de contact *

III. Mise en place des objectifs *

IV. Réalisation *

V. Suivi *

VI. Bilan *

Table des illustrations

Table de la base FluxCentre *

Poly-zone de l'application *

Poly-zone de l'aide et de la messagerie *

Table des Interactions *

Nomination des fichiers pour chaques fonctionnalités *

Aide générique : didactique *

Messagerie d'assistance *

Architecture logicielle *

Intervention chronologique *

Organigramme synoptique *

Simulation et délais de connexion *

1. Remerciements

Dans le cadre de la fin de la deuxième année de l'ES2I un stage de deux mois au sein d'une entreprise nous est demandé. Il doit être une mise en application des méthodes et techniques acquises au cours de l'année.

Je vous remercie de m'avoir accueilli et aidé au mieux à tirer profit de mes enseignements. J'ai apprécié de travailler en équipe et utiliserai le retour d'expérience pour construire l'avenir.

 

 

2. Prise de contact

La prise de contact a eu lieu courant novembre, je me suis présenté dans cette entreprise à la recherche de mon stage de fin de deuxième année. Le responsable du secteur informatique après un entretien, m'a contacté en me soumettant les projets de développement qu'il souhaitait pour son entreprise.

 Le thème proposé après réajustement est  : la réalisation d'un serveur de données en utilisant les protocoles et l'interface d'un navigateur Internet afin de connecter les sites distants de l'entreprise.

La structure informatique est composée de réseau de PC, PMF et d'imprimantes sous Window for Workgroup ( réseau local de type 10 base T à la caisse primaire et dans les agences ), des serveurs NT4 et Unix, des routeurs, des passerelles fonctionnant en X25 et en TCP/IP servant à l'ensemble des activités de l'entreprise. Le nombre d'agent de la Caisse tourne aux environs des 2700 personnes pour le département, dont une cinquantaine pour le Secteur Informatique de Valmante ( le centre )

 

 

3. Mise en place des objectifs

Il m'a été demandé de réaliser une application pilote permettant d'accéder à une base de données en utilisant les protocoles et l'interface d'un navigateur Internet. Une application du type client serveur Minitel étant en place, il s'est agit de s'approprier les structures afin de comprendre le fonctionnement même de l'application demandée.

Objectifs : réalisation d'un outil de travail permettant de garder trace de l'activité tout en allégeant le travail administratif s'y affairant.

La structure existante comportait plusieurs formulaires réalisés sous différentes plates-formes logicielles, Excel, Minitel, Macro nécessitant des saisies multiples de l'information et parfois même des retranscriptions manuscrites. Un document contenant un certain nombre de champs de données faisait office de base de données ... Dans un souci d'unification et de portabilité la solution interface Internet + Base de données ODBC intranet a semblé la plus adaptée; non pas parce qu'elle est utilisée au quotidien par les futurs utilisateurs mais parce qu'un élargissement vers de nouveaux outils de ce type est relativement " fluide " pour les utilisateurs et les réseaux. Une courte étude préliminaire sur le nombre mensuel de transactions a été faite pour s'assurer de la viabilité d'un outil de cette ampleur. Une étude complémentaire est développée plus loin.

4. Réalisation

La réalisation d'un tel outil en un temps limité n'est pas sans poser quelques problèmes d'organisation. J'ai choisi quatre grandes lignes de priorité pour mener à bien cet outil :

Finir , Adapter, Former, Adopter.

En effet la Fin du développement d'un logiciel n'est pas un aboutissement en lui même puisqu'il faut une fois mis au point qu'il soit bien Adapté aux besoins initiaux et si tel est le cas une bonne Formation sur le produit est nécessaire avant de le faire Adopter.

Plusieurs solutions ont été envisagées pour la réalisation de ce projet, en particulier sur le choix du langage choisi pour structurer l'interface graphique. Une interface graphique uniquement en java me semblait un peu trop lourde à gérer en particulier pour les stations 486 sous 8 Mo. J'ai écrit plusieurs modules en java, dont le module de sécurité mais là encore le chargement de la machine virtuelle java s'est avéré trop lourd par rapport au gain du code java.

La répartition du travail a été inégale en effet la réalisation de la base de données de concert avec les agents du département a été réalisée rapidement. Cela m'a permis de créer une petite application pilote montrant les possibilités et la fluidité d'une interface Web et de sa base sql. Cette architecture adoptée, nous avons commencé à élaborer les différentes fonctionnalités que l'application devait avoir, mais nous n'avons pas réellement défini de cahier des charges. Le développement a été sans grande difficulté puisque nous avions pensé la conception avant. La conception se résume à l'accès d'une base de données au travers d'un navigateur Internet ( C.f Architecture logiciel )

Le travail en groupe a été difficile. Nous avons été jusqu'à quatre dans le groupe mais les congés, les projets en cours et l'assistance n'ont permis réellement qu'à un seul agent de suivre les étapes du projet. Ainsi un suivi ou une mise à jour du produit risque d'être problématique bien que la structure logicielle utilisée soit idéale pour ce type de transformation.

 

1. La base de données

Nous avons crée une vaste base de données " FluxCentre " de 3Go pilotée par un pentium pro 200 et 128Mo de ram sous window NT4 et sql serveur 6.5. Une étude succincte des relations entre les tables a été effectuée afin d'amorcer l'application. Cependant de nombreuses modifications ont du être apportées au cours du développement. Des contraintes d'intégrité ont du être supprimées suivant la rigidité de l'interface et les assujettissements de sql serveur 6.5 en particulier sur les mises en forme de date.

 

 

Table de la base FluxCentre



 

 

 

Au final on s'aperçoit d'une redondance d'information et de l 'absence de certaine contrainte de clef, cette omission pourrait faciliter l 'éventuelle refonte de la base sans pour autant refaire l'intégralité de l'interface.

Nous avons installé sql serveur et les services NT s'y affairant pour compléter cette installation et pour faire communiquer notre base de données de manière transparente nous sommes passés par un gestionnaire ODBC ( C.f. Architecture logicielle mise en place ) .

 

 

2. L'Interface

J'ai découpé cette vaste réalisation en 3 modules : une interface de saisie, l'aide et la messagerie d'assistance. L'activation de ses différents modules s'effectue par un simple clique sur les boutons génériques de contrôle tels que l'impression de la page courante, la fermeture de l'application, la messagerie ...

Une interface de saisie a été mise en place pour intervenir dans les informations de la base à différents moments de l'activité. Elle permet d'interagir à tout moment avec les documents finaux. Elle fait office de lien entre les agents délocalisés, les coordinateurs, et la base conservant trace de l'activité. L'interface est principalement écrite en Java Script

 

1. Interface de saisie

 

Nous avons choisi comme support de l'interface un navigateur Internet afin qu'il y ait une portabilité maximale deux questions sont apparues : Quel navigateur choisir entre Explorer et Netscape  et de quel niveau de sécurité l'application peut être accrédité ?

Une étude de Explorer et Netscape sur window 3.11 et 95 a été réalisée afin de déterminer lequel des deux navigateurs sollicitait le plus de ressource. Le développement final de l'application fonctionne sur les deux plates-formes. Pour des raisons de compatibilité c'est Netscape communicator qui a été choisi.

Une longue étude de la sécurité et de ses implications a été établie. Il y a deux niveaux d'implication l'un sur l'usage même de netscape et l'autre sur les transmissions entre le serveur et le client web. En ce qui concerne le navigateur j'ai réalisé un sous navigateur supprimant les fonctions permettant de s'échapper de l'application comme par exemple le changement d'url.

Par contre le problème de communication est plus complexe. Le serveur n'est pas configuré pour établir des liaisons SSL ( Secrue Socket Layer utilisé pour certains paiements sécurisés) et donc de ce fait une interception des trames est envisageable. De par la nature des données transmises un encryptage n'a pas été jugé nécessaire par contre contrôler l'accès de l'application était essentiel puisque le procédé s'établit en un serveur Web donc accessible à toutes les machines du réseau ( impossibilité de filtrer l'adresse ip ) Il s'agit d'interaction avec une base de données et donc pas d'une simple consultation. Un accès restreint initial permet de saisir le numéro d'agent et le mot de passe s'ils sont valides ; ils sont stockés et réutilisés à chaque transaction avec la base de données évitant ainsi toute malveillance. Le retour d'information est autogéré c'est à dire que l'on ne peut rien consulter si l'authentification n'est pas réalisée en effet le répertoire où sont contenus les scripts d'autogénération-fusion n'est pas accessible en lecture donc pas de faille de sécurité pour quelqu'un qui voudrait entrer par une porte latérale. Toute une architecture de sécurité est en train d'être mise en place au sein de la sécurité sociale par le biais de lecteur de carte à puce interrogeant une base de données centralisée pour tous les agents ainsi le lancement de telle ou telle application est assujetti à un contrôle d'accès.

L'évolution du programme pourrait être la récupération des informations de la carte agent puis de les transmettre directement au navigateur il ne me semble par ailleurs pas possible de supprimer la base de données des utilisateurs de cette application spécifique, un accès à la base centralisée est envisageable mais hypothétique dans la réalisation. Bien entendu la mise en place des liaisons SSL est souhaitable.

 

1. Fenêtrage : Distribution poly-zone

La distribution poly-zone n'est autre que l'organisation de l'écran en différentes zones actives ( frame ), l'avantage de cette organisation est la persistance d'une ou plusieurs zones alors que d'autres sont activées ou rafraîchies.

Poly-zone de l'application

Winlogo	Haut
	Bas
Winmenu
	Winsubmenu

En particulier la zone winlogo contient les champs d'identification. A la connexion l'utilisateur saisit son numéro d'agent et son mot de passe. S'il y a authentification, alors des informations sur l'utilisateur sont renvoyées au navigateur, comme par exemple le niveau de priorité, la date du serveur l'UGE d'appartenance ...

Poly-zone de l'aide et de la messagerie

Winaide

winaidemenu

2. Sub-Navigateur .

 

3. Interaction et fenêtrage

Table des Interactions

Pages	winlogo	winmenu	haut	bas	Winsubmenu		Verification	Liaison	Contreliaison
Default.htm	clef.htm	rien.htm	rien.htm	saisiepwd.htm	rien.htm
Saisiepwd.htm				ctrlpwd.htx			taille + int	ctrlpwd.idc	ctrlpwd.htx
ctrlpwd.htx	img + pwd	menuadmin.htm?0		rien.htm
		menuuge.htm?0
Menuadmin.htm?0		menuadmin.htm?X			Menuadminsub.htm?X0
Menuadminsub.htm?X0				opera0XY.htm	Menuadminsub.htm?XY

4. Codage des extensions

La multiplication des fonctionnalités a provoqué une surmultiplication des fichiers de requête et de fusion c'est pourquoi nous avons adopté un système de codage nous permettant de retrouver rapidement le fichier ou de déterminer sa nature de par son extension. Ainsi le fichier " Opera563.htm " est un fichier d'interface ( extension *.html ) pour l'administrateur ( série 5xx ) permettant l'enclenchement d'une requête d'insertion ( xx3 ) dans la table des types de transmission ( x6x ) .

Nomination des fichiers pour chaques fonctionnalités

1	Flux_Laser
2	Flux_Xmodem
3
4	Agent	Opera041.htm
5	Uge
6	Type trans			Opera063.htm
7	Identifiant
		Consultation	Modification	Ajout	Suppression
		1	2	3	4

2. L'aide

La mise en place d'une aide en ligne nous a semblé impérative pour éviter que les utilisateurs soient bloqués dans leur travail ou qu'ils fassent appel à une assistance extérieure. Nous avons réalisé un sous navigateur permettant de manière dynamique d'aller consulter la rubrique qui les concerne. La plus grande partie de l 'aide a pour but d'expliquer le fonctionnement des boutons et la saisie de l'information.

J'ai tenu a ce qu'une partie de cette aide soit réservée au mécanisme mis en œuvre pour la réalisation de cet outil d'une génération d'avant-garde. En effet cette partie peut faire office de manuel du programmeur; elle reste accessible à tous et démystifie le coté programmation en vue d'un enrichissement personnel.

L'exécution de l'aide est très difficile c'est pourquoi la réalisation de concert avec un agent du département m'a été d'une aide précieuse.

 

3. La messagerie d'assistance

Bien qu'elle ne fut pas demandée il m'a semble intéressant de mettre en place une messagerie d'assistance au produit. En effet l'absence de messagerie traditionnelle accessible à tous les utilisateurs toute l'assistance aurait du s'effectuer au téléphone de plus la conception de la messagerie utilise les mêmes concepts de programmation et d'interface que le reste de l'application.

Les utilisateurs ont ainsi la possibilité de contacter le superviseur ou le concepteur en vue d'un éclaircissement. Il peuvent également contacter un autre agent pour l'informer que la transaction a été effectuée. D'un autre coté un message à un centre ou à tous les utilisateurs peut être envoyé à des fins administratives ou logistiques.

Un archivage des remarques et des interventions peut alors être établi pour réaliser un forum interactif de discussion et de maintenance que tous peuvent consulter pour améliorer sans cesse leur outil de travail.

Une procédure automatique active dès leur connexion à la base de données leur boite aux lettres indiquant par là, la présence d'un courrier fraîchement posté. Une telle structure de messagerie pourrait tout à fait être étendue à l'ensemble des utilisateurs pour de l'information générique ou confidentielle.

Aide générique : didactique



 

Messagerie d'assistance



3. Connexion
1. Architecture logicielle

L'architecture logicielle a été influencée par l'architecture réseau, en effet tout les utilisateurs du produit sont sur un vaste réseau départemental. Nous avons installé Internet Information Serveur dont en particulier le service Web. Puis nous avons mis en place SQL Serveur et les services NT puis généré les pilotes ODBC pour faire communiquer le service IIS et le service " executive SQL "

Architecture logicielle



2. Intervention chronologique de l'activité

Il y a plusieurs acteurs dans la circulation des flux laser : les utilisateurs des différents centres, un superviseur, et un contrôle au niveau d'un organisme le CTI chaque acteur intervient à son tour comme le présente le schéma si dessous.

Intervention chronologique

 

 

3. Récapitulatif synoptique de l'activité

Organigramme synoptique



5. Suivi
1. Formation

J'ai présenté l'outil de l'activité des flux une fois fini ainsi que ses fonctionnements dans les grandes lignes. Il m'a semblé plus facile de réaliser le produit que d'en réaliser son didacticiel. J'ai donc décidé d'effectuer une formation plus poussée en définissant les mécanismes. Cela s'est dans l'ensemble bien passé. Il y a eu bien entendu quelques " bugs " qui ont été vite corrigés. Remarque après coup, une succincte documentation manuscrite semble nécessaire pour les utilisateurs encore peu familiarisés avec les didacticiels en ligne. Outre la formation de base aux utilisateurs et au superviseur la messagerie permet de communiquer avec les utilisateurs afin de mieux répondre à leur demande. Le produit doit toucher une quarantaine de centres et quelques personnes par centre. Afin de finaliser le produit une période d'essai sur sept centres est en cours.

2. Adaptation

Outre les " bugs " de programmation un certain nombre de petits problèmes sont survenus. Il a fallu repenser la logique de saisie lorsque les utilisateurs la percevaient difficilement. Lors des tests un problème inattendu de résolution graphique est apparu. En effet la gestion des couleurs étant automatique et le fenêtrage étant réalisé dynamiquement cela ne devait pas poser de problème pourtant il a fallu définir une taille dynamique des polices de caractères suivant la résolution de la carte vidéo sans quoi les barres de défilement s'activaient après une trentaine de caractères.

 

 

3. Adoption

J'espère que l'outil sur lequel j'ai travaillé sera définitivement adopté. Il est certain que des améliorations de convivialité, des élargissements de l'outil peuvent être apportés. Il m'a semblé que cet outil ne pouvait être adopté que si une période de " rodage "  et de mise au point était faite c'est une des raisons pour laquelle l'outil reste brut dans sa conception mais peaufiné dans son utilisation enfin je le souhaite ...

4. Analyse des taux de transfert

6 int 4 24

3 date 8 24

1 info 255 255

1 type 20 20

data flux char 323

mise en forme 100

plus/jour/flux 423

Transfert Nb flux Temps Ko/s

nb UGE 36 Jour 15ko 36 1 15,23

j/Semaine 5 Semaine 76ko 180 5 15,23

2 Semaine 152ko 360 12 12,67

semaine/mois 4 Mois 305ko 720 40 7,61

2 Mois 610ko 1440 240 2,54

mois/an 12 Année 3655ko 8640

Simulation et délais de connexion



6. Bilan
1. Acquisition des compétences

Les compétences acquises durant ce stage sont multiples. Sur le plan logiciel j'ai approfondi la maîtrise du javascript , l'automatisation de procédures en HTML et l'adaptation à des systèmes différents. Mais c'est sans aucun doute sur le plan relationnel que ce stage a été le plus enrichissant; avec un projet ayant une fin utile.

2. Réflexion sur l'entreprise

Cette société est dynamique grâce aux qualités et compétences de son personnel : sa disponibilité, son temps de réaction et sans oublier sa convivialité. Le service informatique est vaste, chacun y trouve sa place et la réflexion d'équipe y est enrichissante bien que le décisionnel soit parfois long à se mettre en place.

Marseille Le 16/09/98

Philippe ELDIN