[ST40] Développement WebGepor Nicolas ANTONE Automne Introduction :

Transcription

1 Introduction : Dans le cadre des études d'ingénieur à l'utbm, l'étudiant se doit de réaliser en quatrième année un stage de 6 mois. Ce semestre de stage a lieu à l'issue des deux premiers semestres d'études du second cycle de la formation et permet à l'étudiant d'appliquer ses connaissances en réalisant une tâche de niveau technicien supérieur. Du 30 août 2004 au 11 février 2005, j'ai donc effectué un stage en tant que développeur Web pour la société GEPOR, filiale du groupe ARCELOR, pour un projet suivi par TIXIS SYSTEMS, une SSII qui gère les ressources informatiques du groupe. Le projet de ce stage consiste à continuer le développement du système de gestion des activités de la société GEPOR, qui remplace leur précédent système devenu obsolète et fonctionnant sous AS/400. Cette nouvelle application utilise la technologie ASP couplée à une base de données SQL/Server. J'ai choisi le sujet que me proposait cette entreprise car je souhaitais avoir un aperçu à la fois de l'informatique de gestion en entreprise mais aussi de la programmation Web. Page 1 / 38

2 Remerciements : Je souhaite exprimer ma gratitude à M. Philippe ADNET pour avoir retenu ma demande de stage. Je souhaite témoigner ma reconnaissance à mon tuteur M. Patrick SARAZIN, pour le suivi tout au long de mon stage, pour son aide à la compréhension et à la mise en place du projet. Je le remercie aussi pour le temps passé avec moi sur la conception du système. Merci également à M. Philippe LALLEMENT, chef du projet chez TIXIS SYSTEMS, pour avoir suivi une partie de mon travail, notamment l'accompagnement lors de la phase de mise en production. Je suis également reconnaissant envers tous le personnel de TIXIS ainsi que le personnel de GEPOR pour l'accueil et l'aide qu'ils ont pu me fournir. Page 2 / 38

3 Table des matières 1 Présentation de l'entreprise d'accueil Le groupe ARCELOR Présentation de TIXIS SYSTEMS Présentation de GEPOR Historique de l'entreprise Les produits Les infrastructures Situation géographique Le fonctionnement et les activités de GEPOR Présentation et finalité du système informatique Fluvial Saisie Rapport Contrôle de l'activité Pointage Facturation Le stage Sujet du stage Définition Antécédents Poste occupé dans la société Encadrement et notions informatiques L'ancien système : AS/ Client / Serveur : Intranet Informations sur la plate-forme ASP/SQL Server Moyens techniques Développement des scripts Gestion de la base de données Objectifs Visés : Planning daté du Travail Prévisionnel Planification réel Travail réalisé Déroulement du Travail Les grandes étapes du développement Finalisation de la partie saisie de l'activité Mise en page CSS/HTML Mise en production du site intranet Gestion de la partie pointage et statistiques sur le personnel Mise en place de la partie Facturation Exportation de la comptabilité Réorganisation de la partie suivi des stocks Généralités Synthèse de mon travail Synthèse des problèmes rencontrés Synthèse des résultats Vision critique de l'application Conclusion Lexique Bibliographie Page 3 / 38

4 1 Présentation de l'entreprise d'accueil 1.1 Le groupe ARCELOR Le groupe ARCELOR est né officiellement en février 2002 de la fusion de trois groupes européens : ARBED Luxembourg, ACERALIA Espagne et le français USINOR. Depuis ce rapprochement, le groupe ARCELOR est le premier sidérurgiste mondial avec une production mondiale de 40 millions de tonnes d'acier et un chiffre d'affaire de 26 milliards d'euros. La société emploie près de personnes dans plus de 60 pays (88 % en Union Européenne). ARCELOR développe ses activités dans quatre principaux secteurs : Il est le premier producteur mondial pour les Aciers Plats Carbone et les Aciers Longs Carbone, l'un des leaders mondiaux pour la production d'aciers Inoxydables, et parmi les premiers en Europe pour le secteur Distribution-Transformating-Trading (un secteur d'arcelor regroupant 250 sociétés de transformation et de distribution en aval de la production d'acier) Les principaux produits du groupe ARCELOR : - L'automobile : ARCELOR est le premier fournisseur d'aciers plats pour l'automobile en Europe et dans le monde avec une part de marché de 13 %. Une voiture sur trois en Europe est carrossée avec des aciers ARCELOR. - L'électroménager : Partenaire des plus grandes marques, ARCELOR est le premier producteur européen d'aciers destinés à l'électroménager. Aciers laminés à froid pour les structures et les renforts, aciers galvanisés appréciés pour leurs caractéristiques mécaniques et leur résistance à la corrosion, aciers composites qui absorbent et amortissent les vibrations. - Emballage : Sur le marché des aciers plats pour l'emballage, Arcelor Packaging International joue également les premiers rôles : Numéro 1 en Europe (28% du marché européen) et numéro 2 mondial (avec 8 %), leader mondial des boîtes boisson deux pièces (fond + couvercle). 8 milliards de boîtes boisson sont fabriquées chaque année avec de l'acier ARCELOR. - Construction : L'acier s'affirme aujourd'hui comme un matériau de construction noble et moderne, les plus grands architectes privilégient son élégance, sa résistance et sa légèreté. - Tube : ARCELOR propose sur ce marché des solutions acier très diversifiées : aciers plats au carbone, aciers longs au carbone, aciers inoxydables, en croissance dans tous les secteurs qui exigent un matériau inaltérable pour répondre à des contraintes industrielles sévères : résistance aux conditions extrêmes dans l'industrie chimique, le nucléaire, le pétrole ; légèreté, sécurité et longévité dans le transport, hygiène dans l'industrie alimentaire Page 4 / 38

5 1.2 Présentation de TIXIS SYSTEMS TIXIS SYSTEMS est une SSII (Société de Services et d'ingénierie en Informatique) née en 2000 de la fédération des équipes Etudes Informatiques des sociétés du groupe USINOR. TIXIS SYSTEMS est le plus important fournisseur en systèmes d'information d'arcelor, dont elle est filiale à 100 %. Sa clientèle se compose d'environ 75 clients répartis dans plus de 10 pays différents et compte au minimum 900 collaborateurs. TIXIS SYSTEM assure au sein du groupe : La conception, la réalisation et le déploiement de solutions répondant à des besoins spécifiques. La conception, la réalisation de solutions réutilisables par le groupe. L'intégration de solutions du marché. Les clients sont suivis tout au long du cycle de vie de leur système d'information. 1.3 Présentation de GEPOR GEPOR SAS (Société par Actions Simplifiées) est une filiale de Sollac Lorraine depuis 1999 et depuis 2001, filiale à 100 % d'arcelor. Cette société occupe un rôle clef au sein du groupe ARCELOR car c'est elle qui est en charge du transit des charbons et des aciers entre les différents clients en début et en fin de production. Elle assure ainsi l'importation des matières premières (minerais, charbons), de demi-produits (brames, coils) et l'exportation de produits sidérurgiques (aciers plats carbone, rails, fils). La société s'occupe principalement de la gestion et du suivi de l'activité en amont et en aval des différents ports. L'activité amont est centrée sur le déchargement des bateaux de matières premières et l'activité aval sur l'expédition de produits finis par voie maritime Historique de l'entreprise 1976 : Création de GIE GEPOR Actionnaires : LORFONTE, SOLLAC et SOLOTRA 1993 : GEPOR devient une SNC (Société en Nom Collectif) Actionnaires : LORFONTE, SOLLAC et UNIMETAL Filiale à 100 % de USINOR SACILOR 1999 : Filiale à 100 % de SOLLAC Lorraine 2001 : GEPOR devient une SAS (Société par Actions Simplifiée) Page 5 / 38

6 1.3.2 Les produits Réceptions : Principalement différents types de charbons qui proviennent de pays miniers éparpillés tout autour du globe : Charbon (Amérique du Sud) Coke (Chine) Brames (Mexique, Brésil) Blooms (Angleterre) Coils (Slovénie, Russie) Expéditions : Après de multiples transformations, ces charbons deviendront des aciers qui seront alors transportés par péniche, wagon ou camion dans diverses villes européennes telles que Strasbourg, Ottmarschein (France), Anvers (Belgique), Duisbourg et Neuwied (Allemagne) : Bobines de tôle Bobines à axe vertical (sur palette) Paquets de fer blanc Rails de Chorus Divers aciers marchands et fils machine (en bobines) Ces expéditions se font pour la plupart par voie fluviale (environ 10 % de la production d'acier) pour des raisons géographiques, monétaires et pratiques. En effet, une péniche peut transporter jusqu'à 2500 tonnes d'aciers, l'équivalent de 100 camions ou de 4 trains. Page 6 / 38

7 1.3.3 Les infrastructures L'entreprise GEPOR s'étend sur deux sites : le port d'illange et le port de Richemont. L'expédition des aciers se fait uniquement à Illange, car proche de Sollac Lorraine pour le transfert des produits finis alors que la réception de minerais s'effectue sur les deux ports. Illange : 800 mètres de quai avec un pont portique de 15 tonnes sur 500x100 mètres d'emprise et une grue électrique sur rails de 9 tonnes sur 550 mètres d'emprise. Une halle pour les aciers de 200x30 mètres avec une darse de 100x12 mètres, équipée de deux ponts roulants de 30 tonnes. Un réseau ferré de 16 km et 3 km de routes et de pistes. Richemont : 1020 mètres de quai avec un pont portique de 20 tonnes sur 460x60 mètres d'emprise. Une halle pour les aciers de 100x30 mètres avec un pont roulant à deux chariots de 6 tonnes. Un réseau ferré de 10 km et 3 km de routes et de pistes Situation géographique Page 7 / 38

8 1.4 Le fonctionnement et les activités de GEPOR Pour analyser le système informatique de gestion des activités de GEPOR, il est nécessaire d'expliquer le fonctionnement des réceptions et des expéditions depuis le port. Comme expliqué dans la présentation de l'entreprise, l'activité de GEPOR est centrée sur le chargement et le déchargement de produits par voie maritime. On peut séparer son activité en deux catégories : Les réceptions : Pour la réception de charbon, des vapeurs de mer (les minéraliers) qui peuvent transporter jusqu'à tonnes, déchargent aux ports de mer (Anvers, Dunkerque,...) les matières premières sur des allèges qui feront la navette entre Anvers et le port d'illange. C'est le port d'anvers qui prévient GEPOR pour l'affrètement d'une allège. Une allège contient généralement une seule famille de produit (Coke, Combustibles,...). A partir de là, le bureau fluvial suit la position de l'allège jusqu'à sa destination à l'aide des passages écluses. Ce suivi permet de connaître les prochaines arrivées et donc de planifier les équipes pour effectuer le déchargement des allèges. Arrivées à GEPOR, elles sont ainsi déchargées à l'aide d'engins locaux appelés ponts portiques, grues, chargeurs ou pousses-wagons. Les matières premières sont soit envoyées à l'agglomération ou vers les Hauts Fourneaux par le réseau ferré interne à l'entreprise, soit stockées en attente sur des emplacements identifiés appelés tas. Les expéditions : Concernant l'aval, c'est à dire l'expédition des aciers, les produits finis arrivent de Sollac ou de clients extérieurs et sont ré-acheminés par voie fluviale vers les ports proches des clients. Le chargement des allèges s'effectue dans une halle équipée de deux ponts portiques permettant de placer les bobines ou les rails dans les cales du bateau. Page 8 / 38

9 Les agents sur le terrain travaillent sur deux postes (Matin et Après-Midi). Le poste de nuit est utilisé pour des impératifs de délais au même titre que les samedis, dimanches et jours fériés. Pour chaque poste, les agents conduisent les engins pour manipuler les produits, et les chefs d'équipes remplissent en fin de poste un rapport par engin utilisé. Ce rapport est lu (parfois corrigé) et validé par le contrôleur de gestion et servira à établir la facturation une fois tous les rapports d'un mois validés. Précédente gestion des activités : L'ensemble de l'activité du port était jusque là saisi sur un logiciel développé par une entreprise extérieure et exploité par l'intermédiaire d'une machine AS/400. Les agents remplissaient une grille pour valider leur travail et, dans le même temps, un support papier ; le contrôleur de gestion se devait de vérifier la cohérence entre les deux documents. Ainsi, avant le démarrage du projet ASP/SQL, les machines utilisées pour gérer l'activité du port étaient des AS/400 couplées au logiciel de comptabilité SAGE. L'application développée sur l'as/400 a plus de 15 ans et coûte en moyenne euros par an pour la maintenance et pour le serveur (qui est sous exploité). De plus, le programme commençait à devenir obsolète et les nouveaux modules rajoutés au fil du temps ne sont pas documentés, ce qui rend la maintenance très difficile. Ajouté à une convivialité qui est vraiment dépassée, la société GEPOR a alors décidé de mettre à jour son système informatique et de concevoir une version plus moderne de son application de gestion. Page 9 / 38

10 1.5 Présentation et finalité du système informatique On peut diviser le nouveau système informatique Web-Gepor en plusieurs soussystèmes : Fluvial C'est le premier maillon de la chaîne de gestion. Le suivi des allèges commence par leur affrètement / chargement par les vapeurs de mer. Cette facette a un rôle important dans le suivi de l'activité de GEPOR, car elle permet la saisie des activités amont et d'envoyer un certificat de déchargement à l'armateur (document spécifiant que l'allège a totalement été déchargée) Saisie Rapport C'est la partie accessible aux équipes présentes sur le terrain. Les chefs d'équipes saisissent les activités effectuées sur leur poste, en renseignant les personnes qui ont travaillées, le temps passé à manipuler le produit, sur quel engin, quelle allège Contrôle de l'activité Dans ce sous-système, une personne appelée contrôleur de gestion, suit la saisie des activités faites sur le terrain. Ce système donne donc la possibilité de consulter les rapports d'activité, de les corriger si nécessaire et de les valider, ce qui aura comme effet de les préparer pour la facturation. Pour cette tache, le système met à disposition un ensemble d'états statistiques ou récapitulatifs sur les rapports Pointage Il permet de gérer la présence des salariés de l'entreprise, personnel administratif et agents du terrain, afin de pouvoir contrôler par le biais d'états statistiques les heures du personnel Facturation Ce sous système doit permettre d'établir la facturation et la comptabilité complète de GEPOR : au niveau de la facturation, il permet de sortir automatiquement les factures d'après la saisie de rapports, de donner au comptable la possibilité de saisir ses propres factures ou avoirs en manuel, et d'envoyer les données vers le logiciel de comptabilité SAGE qui fera le lien avec la banque de l'entreprise. Page 10 / 38

11 Aperçu des interactions entre les différents systèmes Fluvial Saisie de l activité Gestion des Vapeurs de Mer + Création des Allèges qui vont être déchargées / chargées. Est nécessaire à Les agents sur le terrain saisissent les rapports pour valider leur travail. Permet d'élaborer Pointage du Personnel Rapports d'activité Permet de sortir des états statistiques sur le personnel et de suivre le pointage. Contrôleur de Gestion Comptabilité Contrôle et corrige les rapports d activité avant de les valider pour la facturation. Facturation Exportation vers Sage Génère automatiquement les factures à partir des données de la saisie de l activité + Saisie des factures manuelles. Page 11 / 38

12 2 Le stage 2.1 Sujet du stage Définition Le sujet défini avant mon arrivée portait sur la poursuite du développement d'une application intranet pour permettre la saisie de l'activité portuaire, son suivi, ainsi que la gestion de la logistique depuis le chargement des allèges jusqu'à la facturation du client. Je devais ainsi m'occuper dans un premier temps de toute la partie facturation du programme dont l'objectif est de sortir les factures destinées aux clients suivant l'activité saisie par les utilisateurs, puis dans un deuxième temps, de développer quelques états pour finaliser le système. Il était aussi question de mettre en place un site Internet pour la société si l'application intranet était terminée avant la fin de l'année Antécédents Avant mon arrivée, deux stagiaires sont passés par TIXIS SYSTEMS et ont contribué au développement de l'application : Le premier, un étudiant à l'iie (Institut d'informatique d'entreprise), qui était en projet de fin d étude (stage de 6 mois) en vue d'obtenir un diplôme d'ingénieur, s'est occupé de la faisabilité du nouveau système. Il a ainsi mis en place la structure générale de l'application, conçu le modèle de la base de données et codé une première partie. Il a développé la partie gestion fluviale et saisie des rapports d'activité. Mais son sujet de stage était centré essentiellement sur la conception de l'application à l'aide d'une méthode de gestion de projet (méthodologie P+). Le second stagiaire, qui a commencé son stage juste après le précédent et qui l'a terminé la semaine où je suis arrivé, était en D.U.T. Informatique à Metz (stage de 10 semaines). Son rôle était de continuer le développement de l'application et d'assurer la transition entre le premier stagiaire et mon stage. Il s'est occupé de la partie pointage et des états statistiques qui en découlent ainsi que la gestion des stocks et du suivi des produits. Page 12 / 38

13 2.1.3 Poste occupé dans la société Durant ce stage, j'occupais un poste de développeur pour aider la société GEPOR à la conception de leur nouveau programme de suivi d'activité (programme commandé à TIXIS SYSTEMS). Mon rôle était donc d'assurer le développement de l'application ainsi que la gestion de la base de données. J'étais en relation avec la personne s'occupant de l'informatique à GEPOR, M. SARAZIN, mon tuteur de stage, qui a grandement participé à l'étude de la conception des différents états. Je gardais également contact avec le personnel de TIXIS SYSTEMS, spécialisé dans les applications de gestion. L'application étant supervisée par TIXIS, je servais aussi d'intermédiaire pour les comptes rendus sur l'avancement du projet. 2.2 Encadrement et notions informatiques L'environnement privilégié du groupe ARCELOR est Microsoft Windows. Chaque poste est sécurisé et protégé par le triplet User, Password, Domain et donne accès à un certain nombre d'applications. De ce fait, le choix du langage et de la plate-forme du projet ont été décidés par TIXIS suite à une analyse des coûts et une analyse de la facilité de maintenance à long terme par la société. Le développement du site intranet est donc effectué en ASP, et le serveur de base de données est Microsoft SQL Server L'ancien système : AS/400 AS/400 est une gamme de mini-ordinateurs IBM apparue début février L'AS/400 est une architecture composée d'éléments matériels et logiciels, comportant notamment une base de données et des éléments de sécurité avancés. La force de l'as400 réside dans la modularité de ses éléments constitutifs lui conférant un haut degré d'adaptabilité et de sécurité. En effet l'architecture AS/400 est une structure en couche séparant les éléments matériels et logiciels. Le système d'exploitation de l'as/400 est appelé OS/400. Il repose sur une couche appelée MI (Machine Interface) chargé de fournir un ensemble de fonctions (API, application programming interface) que les applicatifs doivent utiliser afin de s'interfacer avec le matériel. Contrairement à la plupart des systèmes d'exploitation, la gestion de la plupart des composants matériels (mémoire, entrées-sorties, gestion des processus,...) est assurée par une couche indépendante, appelée SLIC (System Licensed Internal Code), située sous la couche MI. Ainsi l'architecture AS400 assure une réelle indépendance entre le matériel, le système d'exploitation et les applications. Page 13 / 38

14 2.2.2 Client / Serveur : Une notion importante dans un projet Internet/intranet est celle de client/serveur : Serveur : Le serveur est l'ordinateur où est stockée une base de données et/ou des pages de scripts, ou encore d'autres services. Le serveur va donc répondre à la requête de l'ordinateur client (ce qui correspond ici à interpréter les pages de scripts et éventuellement accéder à la base de données) pour lui renvoyer la ressource (ici une page HTML). Client : Le client est l'ordinateur qui va accéder aux ressources du serveur et sur lequel le résultat de la requête pourra être exploité Intranet Un intranet est un réseau local privé qui utilise les technologies de l'internet : Web, , etc., mais qui ne s'ouvre pas aux connexions publiques. Un site intranet est donc un site accessible uniquement depuis le réseau local de l'entreprise Informations sur la plate-forme ASP/SQL Server ASP (Active Server Pages) est un standard mis au point par Microsoft en 1996 permettant de développer des applications Web interactives, c'est-à-dire dont le contenu est dynamique. Les pages Web ASP (fichier repérable par l'extension.asp) contiennent du code HTML et des scripts écrits en langage VBScript (Similaire au langage Visual Basic de Microsoft). ASP est en réalité une technologie, ou plus exactement un environnement de programmation, permettant de représenter sous forme d'objets les interactions entre le navigateur du client, le serveur Web, ainsi que les connexions à des bases de données (grâce à ADO, ActiveX Data Objects) ou bien des composants COM (Component Object Model). Les ASP sont donc exécutés du côté du serveur (au même titre que les scripts CGI,PHP,...) et non du côté client (contrairement aux scripts écrits en JavaScript ou les applets Java qui s'exécutent dans le navigateur de l'utilisateur connecté à un site). Les ASP sont intégrables au sein d'une page Web en HTML à l'aide de balises spéciales permettant au serveur Web de savoir que le code compris à l'intérieur de ces balises doit être interprété afin de renvoyer des données (généralement du code HTML) au navigateur du client. Page 14 / 38

15 Ainsi, les Active Server Pages s'inscrivent dans une architecture 3-tier. C'est à dire qu'un serveur supportant les scripts ASP peut servir d'intermédiaire entre le navigateur du client et une base de données en permettant un accès transparent à celle-ci grâce à la technologie ADO (ActiveX Data Objects), qui fournit les éléments nécessaires à la connexion à un système de gestion de bases de données et à la manipulation des données grâce au langage SQL. Les ASP ont été conçus à la base pour fonctionner sur le serveur Web de Microsoft intitulé Microsoft IIS (Internet Information Server). Ce serveur web, mis au point par Microsoft en 1996, a l'avantage d'être gratuit, il fonctionne sous le système d'exploitation Microsoft Windows NT (IIS 4). Enfin, SQL Server est un SGBD (Système de Gestion de Base de Données) développé par Microsoft. Page 15 / 38

16 2.3 Moyens techniques Pour mener à bien ce projet, les connaissances requises se focalisent sur le langage SQL afin de manipuler la base de données et le langage de scripts ASP pour les pages intranet. Concernant le langage SQL, déjà étudié lors de la première année du second cycle, j'en maîtrisais correctement toutes les fonctions et les maniements, mais certaines requêtes plus complexes m'ont poussé à me documenter sur le sujet, notamment sur les clauses de regroupement de données et les jointures multiples. Les logiciels utilisés pour le développement, durant mon stage, sont : «Microsoft SQL Server Query Analyser» pour mettre au point les requêtes SQL avant de les intégrer aux pages web (visualisation des résultats) et pour gérer la base de données (insertion, modification ou suppression de données pendant la phase de développement). «Microsoft Visual InterDev», un environnement de développement complet pour programmation. Utilisé pour créer les pages ASP (avec frappe intuitive et mise en relief des mots clés du langage de script), il permet de gérer la mise à jour automatique de l'application entre ma version de travail sur disque local, et la version en ligne sur le serveur distant. «Silverrun» pour la création du modèle de base de données Développement des scripts Le langage utilisé pour la programmation des pages ASP est le VBScript. Bien que n'ayant pas étudié la programmation web à l'utbm, l'adaptation a été relativement facile pour moi, du fait de ma connaissance du langage de scripts serveur concurrent, le PHP, et pour avoir déjà conçu quelques programmes en Visual Basic. Le VBScript est finalement très semblable au Visual Basic ; les mots clés et les fonctions intégrées sont identiques, seul changent les objets que l'on manipule (principalement des résultats de requêtes). Finalement, les seules notions qui me faisaient défaut sont celles rattachées au langage javascript (qui permet d'exécuter des scripts côté client). Ce langage, très proche du langage C et du Java par sa syntaxe, permet d'accéder aux objets d'une page HTML et de contrôler les entrées de l'utilisateur par exemple. J'ai donc effectué quelques recherches pour connaître les objets que l'on pouvait manipuler, leurs propriétés et la syntaxe de leurs méthodes. Page 16 / 38

17 2.3.2Gestion de la base de données Concernant la gestion de la base de données de l'application, une personne spécialisée appartenant à un bureau d'étude, s'occupe de la normalisation, de la création, des ajouts et suppressions de tables, et de la maintenance de la base. Concrètement, pour ajouter une table dans l'application, il me faut remplir un formulaire en ligne avec une description des champs, ainsi que des informations sur leur taille et leur type ; le bureau d'étude a pour mission de normaliser les champs et d'exécuter les scripts d'ajouts sur le serveur SQL. Cette méthode, qui m'enlève un certain degré de liberté, leur permet de rester informé sur les modifications de la base de données du projet. Je ne peux donc pas créer ou supprimer les tables directement, ni choisir les noms des champs. Le principal inconvénient est le temps nécessaire à la validation de ma demande, qui peut aller de quelques heures à trois ou quatre jours, ce qui est relativement long quand on attend la mise en place d'une table pour tester un script. La base de données du projet est installée sur un serveur de développement présent uniquement pour réaliser des tests et mettre au point les scripts ASP, mais également sur un serveur de développement qui contient les données réelles de l'application (l'activité du port). Chaque demande de création de table est dans un premier temps effectué sur le serveur de développement, puis après avoir reçu ma validation, recopiée à l'identique sur le serveur de production. 2.4 Objectifs Visés : L'objectif de ces 6 mois de stage est d'arriver à terme à une application complète, fiabilisée et opérationnelle. Pour ce faire, l'application doit être capable de traiter toute la logistique de GEPOR depuis le chargement des produits à Anvers jusqu'à l'impression des factures. Il faudra donc dans un premier temps finaliser la saisie de rapport qui est le centre de l'application, mettre en place une gestion des tarifs, un module de création, d'automatisation et d'édition des factures, ainsi qu'un module d'export de données vers le logiciel de comptabilité SAGE. Par-dessus ce travail, viendra se greffer la réalisation d'états statistiques supplémentaires nécessaires au suivi de l'activité du port. Cette application a une importance hautement stratégique pour l'entreprise puisque toute son activité depuis l'amont jusqu'à la comptabilité, sera saisie et conservée sur celle-ci. Il est donc primordial que l'application fonctionne parfaitement puisqu'une coupure pour maintenance entraînerait une baisse de la productivité de la société. Page 17 / 38

18 2.5 Planning daté du Travail Prévisionnel 30/08/04 au 10/09/04 2 Semaines 13/09/04 au 24/09/04 2 Semaines 27/09/04 au 22/10/04 4 Semaines 25/10/04 au 29/10/04 1 Semaine 02/11/04 au 12/11/04 2 Semaines 15/11/04 au 10/12/04 5 Semaines 20/12/04 au 31/12/04 2 Semaines 03/01/05 au 07/01/05 1 Semaine 10/01/05 au 04/02/05 4 Semaines 07/02/05 au 11/02/05 1 Semaine Découverte du sujet et des activités de l'entreprise. Familiarisation avec le langage ASP Conception de la partie Facturation Automatique Développement de la partie Facturation ainsi que des états statistiques directement rattachés Préparation à la mise en production de l'application Transfert de la base de données de l'as/400 vers le nouveau système Formation des utilisateurs sur le nouveau système. Correction des bugs non mis à jour pendant la phase de test Développement de plusieurs états statistiques pour compléter les fonctionnalités de l'application Correction des dernières anomalies. Mise au point de la Facturation Manuelle Conception + Reverse Engineering sur l'exportation de données vers le logiciel de comptabilité Finalisation + Test de toute la partie Facturation Finalisation des derniers états de l'application Ajout de fonctionnalités et Correction des bugs Documentation + Rapport de Stage Page 18 / 38

19 2.5.2 Planification réel Je m'efforçais de planifier au mieux le travail à accomplir. Un problème récurrent rencontré lors de la planification de mon travail est une constante remise en question de la finalité d'un état. C'est à dire qu'il m'est arrivé à plusieurs reprises de reprendre un état terminé pour le modifier car ses objectifs, définis au départ, avaient évolué ou ne correspondaient plus aux attentes de l'utilisateur. De plus, au fil du stage, on s'est aperçu que les états programmés par le second stagiaire étaient pour la plupart erronés. Ils ont été développés pendant l'été et de ce fait, peu de contrôles et de tests ont été réalisés car le personnel était réduit. J'ai donc repris la majeure partie de ces états pour les retravailler. Les erreurs venaient principalement d'inattentions dans les algorithmes de parcours de résultats. D'autres problèmes venaient de la présentation des pages en général (placement et style des éléments de la page) car cet étudiant ne connaissait pas le langage HTML. C'est pourquoi, beaucoup de tâches ne respectaient pas le planning prévisionnel à cause de ces corrections qui, à partir de la mise en production, étaient bien souvent à réaliser dans l'urgence pour ne pas bloquer l'activité du port. Page 19 / 38

20 3 Travail réalisé 3.1 Déroulement du Travail A mon arrivée, l'application était encore en phase de développement. Sa mise en production était planifiée pour le 1er novembre. J'avais donc 2 mois pour développer et corriger les états indispensables à son fonctionnement. La facturation s'effectuant en fin de mois, j'avais ainsi un mois supplémentaire pour développer ce module (facturation automatique) sachant que la création de factures manuelles et l'exportation de données vers la comptabilité pouvait attendre la fin du mois de décembre 2004 (l'ancien système AS/400 était encore en fonctionnement uniquement pour gérer cette partie). A partir de ce planning prévisionnel, qui m'imposait de respecter les délais puisque la facturation ne pouvait pas prendre de retard, j'ai pu mettre en place mon propre planning pour développer les différents états et modules du système. Rapidement, j'ai compris que l'application qui était en phase de développement, et qui avait été développée par les deux précédents stagiaires, n'était pas exempt d'erreurs d'analyse et de bugs divers. Il était donc nécessaire, pour assurer le fonctionnement optimal de reprendre une bonne partie du travail effectué afin de corriger ces problèmes. Ceci devant être réalisé tout en ne prenant pas de retard sur le travail à effectuer. La majorité de ces modifications n'était pas planifiée car bien souvent, les erreurs du programme étaient découvertes au jour le jour par les agents sur le terrain qui entraient les rapports d'activités ou par le contrôleur de gestion. Les différents problèmes venaient surtout du fait que l'application déjà développée n'était pas encore entrée en phase de test. Les stagiaires étaient donc réduits à débuguer leur code avec leurs propres tests du système, ce qui ne correspondaient pas à une utilisation en conditions réelles. Ce n'est que plus tard que l'on s'est aperçu du côté figé de leur développement : trop de paramètres en dur dans le code limitaient l'évolution de l'application. Un exemple concerne les types de prestations qui sont modifiables dans la partie administrateur. Le problème est que la saisie de l'activité fait référence à ces prestations mais les conditions sur ces prestations sont codées en dur dans les sources. Si le besoin venait à modifier une prestation, celle-ci ne serait pas prise en compte dans tout le programme ce qui remet en cause l'utilité de la facette administration du site. Page 20 / 38

21 3.2 Les grandes étapes du développement Finalisation de la partie saisie de l'activité La partie saisie de l'activité, qui est le noyau de l'application, n'était pas exempte de bugs au moment où j'ai repris en main le système. Le principe de cette facette est de fournir à l'utilisateur des menus dynamiques où il peut choisir un élément pour remplir plus facilement le rapport. Par exemple, une fois que le bureau fluvial enregistre les allèges avec leur date d'arrivée prévisionnelle, une liste déroulante contenant ces allèges est disponible lors de la saisie du rapport, et une fois sélectionnée, elle permet de mettre à jour les champs allège, produit, code stock et date de chargement. La saisie de l'activité est un des plus gros fichiers en nombre de lignes du code source. Ceci est dû à la présence de nombreuses fonctions javascript pour contrôler les entrées de l'utilisateur et ainsi l'empêcher de saisir des aberrances. La taille de ces fichiers sources m'a posé problème pour la compréhension des scripts (qui n'était d'ailleurs pas facilité par l'indentation absente et des commentaires trop souvent inexistants). Mon travail sur cette partie consiste à fiabiliser au maximum la saisie et à mettre en place, en parallèle à la facturation, une gestion des tarifs. Cette tâche s'est rapidement étendue à la correction de bugs et à la réécriture de fonctions mal conçues. Pour exemple, la gestion des dates est assez complexe puisqu'il existe trois formats dans l'application : le format français pour l'affichage, le format anglais pour les fonctions intégrées, et le format SQL pour les sauvegarder dans la base de données. Page 21 / 38

22 3.2.2 Mise en page CSS/HTML La reprise du code source des précédents stagiaires n'était pas évidente pour des raisons de lisibilité : à mon arrivée, les sources de l'application n'étaient pas indentées, ce qui n'est pas particulièrement gênant sur des fichiers de quelques lignes mais elles devenaient complètement illisibles au-delà de 500 lignes (Certains fichiers dépassent les 3000 lignes de code). De plus, le code HTML était fortement redondant et ne respectait pas les standards du langage avec la présence de balises ouvrantes qui n'étaient jamais refermées (ce qui ne gène pas trop Internet Explorer, tant que le code javascript n'y fait pas référence). Malgré la simplicité du langage, j'ai dû m'employer pour corriger et remettre en forme les balises, simplement par souci de clarté et de comptabilité avec les futures évolutions du langage et/ou des navigateurs web. Un autre problème lié au souci de la lisibilité du code source concerne les informations de mise en page et de style, qui étant omniprésentes, participaient grandement à la surcharge du code. Il était donc nécessaire de mettre en place des feuilles de styles CSS (Cascade Style Sheet) pour regrouper toute la mise en page dans un fichier externe. L'avantage est que la modification de ce simple fichier permet de changer la mise en forme de toutes les pages de l'application en lieu et place de modifier une à une les balises de chaque page. Cette tâche était loin d'être inutile puisque l'interface de l'application était, à mon goût, fortement négligée. Une seule couleur pour le fond et le menu, des états qui étaient soit fait de tableaux blancs, soit de couleurs trop vives. Avant la mise en place de feuilles de styles : Page 22 / 38

23 Mise en page avec les feuilles de styles : La mise en place de feuilles de style a permis de changer la charte graphique de l'application, qui est passée d'une dominance de couleurs vives avec des polices standards, à des couleurs plus agréables à l'œil avec une police et des titres uniformisés. L'impression des états : L'ajout d'une feuille de style dédiée à l'impression était également nécessaire puisque jusque là, on imprimait exactement ce qui s'affichait à l'écran, ce qui, à cause des couleurs, allait vite faire augmenter le budget cartouche d'encre. Cette feuille de style permettait donc un formatage spécial impression sans couleur et en masquant certains éléments inutiles (comme les boutons des formulaires). Ceci se faisant en utilisant l'argument «media» de la balise «link» (print pour impression et screen pour écran) Code : <link rel="stylesheet" type="text/css" href="css/impression.css" media="print"> <link rel="stylesheet" type="text/css" href="css/style.css" media="screen"> Page 23 / 38

24 Exemple de la feuille de style de la balise TH correspondant à l'en-tête d'un tableau : (Syntaxe de la feuille de style : «nom de la propriété: valeur;») Navigateur TH { font-weight: bold; mise en gras font-size: 10pt; taille de police 10 border: 1px solid #9999DD; couleur de bordure background: #5E6BD7; couleur du fond color: #FFFFD0; couleur du texte padding-right: 0.5em; marges padding-left: 0.5em; } TH { } Impression border: 1px solid grey; Uniquement une mise en forme des bordures, les autres propriétés conservent leurs valeurs standards. Le principal avantage de cette modification, en plus de donner une identité graphique à l'application avec une interface plus agréable, est la compatibilité avec les autres navigateurs et certainement avec les futures évolutions de Internet Explorer et des standards du Web (W3C) Mise en production du site intranet Après avoir passé un mois et demi à me familiariser avec l'environnement de programmation, comprendre les sources des états développés auparavant et commencer la programmation de mes propres modules, je devais préparer l'application à passer sur serveur de production. Pour cela, il fallait dans un premier temps trier les tables de la base de données de l'as/400 pour savoir lesquelles seraient recopier dans le nouveau système. Ce sont surtout les tables du fluvial qui étaient concernées puisqu'elles contenaient la liste des prochaines arrivées d'allèges avec tous les détails. Le principal problème était la différence de syntaxe entre les données exportées de la base de l'as/400 et la syntaxe nécessaire à leur importation dans MS SQL Server. Il subsistait de petites différences entre les deux comme des champs de texte brut à l'export alors que l'importation exige qu'ils soient encadrés par des doubles quotes. Un programme spécialisé dans le traitement de fichier CSV (fichier contenant les données contiguës séparées par un point virgule) a permis de corriger assez facilement ces erreurs de syntaxe. Une fois cette étape effectuée, il fallait comparer la structure des anciennes tables avec celle utilisée dans le projet intranet. Quelques champs avaient des points de disparité entre les deux systèmes : la structure pouvait être différente avec des champs dont le format n'avait pas été conservé (exemple des champs date qui se présentaient sous la forme de 5 champs Jour, Année, Mois, Heures, Minutes dans l'as/400 alors que sous MS SQL Server on utilise un seul champ avec le format date/heure), d'autres ont été rajoutés ou supprimés. Page 24 / 38

25 3.2.4 Gestion de la partie pointage et statistiques sur le personnel Avant la mise en place de l'application, le pointage du personnel s'effectuait par le biais de carnet de pointage : le chef de poste inscrit ses agents sur ce carnet qui est envoyé à la personne s'occupant de gérer les ressources humaines. Cette dernière entre alors les données dans des feuilles Excel pour faire ressortir des statistiques. L'idée, pour le nouveau système de pointage des personnes, est de permettre aux agents d'entrer sur la saisie des rapports d'activités, leur matricule avec soit le nombre d'heures et les produits manipulés s'ils ont travaillé, soit un code d'attente spécifique avec le temps passé s'ils ne pouvaient pas travailler (panne d'engin, heure de pauses, délégation, ). A partir de la saisie rapport, le pointage est automatisé : si une personne n'est pas pointée, elle est considérée comme absente. De plus, le fait d'associer un code à chaque heure pointée permet de construire des états statistiques répondant à la demande de GEPOR concernant le suivi des heures travaillées. La partie pointage et statistiques sur le personnel a été développée par le précédent stagiaire. Son utilisation en pratique a montré que la majorité des états était erronée suite à des oublis lors de la conception. En effet, la difficulté de ces états était de faire ressortir les heures supplémentaires ce qui correspond aux postes de nuit ainsi qu'aux samedis, dimanches et jours fériés. La requête devait donc afficher le nombre d'heures travaillées les jours fériés mais SQL Server n'a pas de composant date qui renvoie les jours fériés et encore moins les jours fériés de France. De plus, si un agent est pointé sur deux postes consécutifs, les heures du second poste sont considérées comme supplémentaires. La limitation de cette partie est qu'elle ne peut pas afficher le nombre d'heures supplémentaires à un poste de nuit. Le poste de nuit commence à 22 h à la date D, le poste du matin se fait donc à la date D+1. Les dates étant différentes, on ne fait pas la distinction entre un agent qui fait des heures supplémentaires et un agent qui revient travailler le lendemain. Pour les jours fériés, l'astuce consiste à calculer en ASP la date de Pâques de l'année en cours, puis à partir de celle ci, calculer les dates des jours fériés variables, associer dans une liste ces dernières aux jours fériés fixes, et injecter cette liste dans la requête. Il ne reste plus qu'à tester en SQL l'appartenance ou non de la date en cours à cette liste pour savoir si le jour est férié ou non. Concernant les samedis et les dimanches, la fonction «datepart», propre au langage SQL, renvoie le numéro correspondant au jour d'une date donnée. Page 25 / 38

26 D'autres états ont été repris car ils mettaient un temps beaucoup trop important à s'afficher. Souvent à cause de requêtes mal optimisées ou trop d'aller retour entre le serveur web et le serveur SQL sur une même page (j'ai pu regrouper dans un certain cas, six requêtes en une). Ces modifications n'étaient pas prévues dans le planning prévisionnel du projet ce qui retardait bien souvent le développement des autres parties Mise en place de la partie Facturation L'objectif premier de mon stage est l'élaboration de la partie facturation de l'application Web-Gepor. La conception et le développement de cette facette ont occupé une bonne partie de mon temps : elle concerne la mise en place de tarifs à partir de la saisie des rapports d'activités, la création automatique de factures, la saisie de factures manuelles et l'exportation vers le logiciel de comptabilité SAGE. La principale difficulté de cette partie est l'élaboration d'un masque pour l'impression des factures. En effet, l'environnement Internet (avec le navigateur web Internet explorer) est très mal adapté à la mise en page et à l'impression. De plus, bien que depuis l'introduction des feuilles de style, on puisse effectuer des mises en formes plus évoluées, le contrôle de l'impression n'est toujours pas pris en charge par IE (un des grands reproches fait à IE est qu'il ne respecte pas les standards des feuilles de styles). Ainsi, il est impossible de définir les marges ou l'orientation de la page (bien que possible d'après les règles du W3C), c'est pourquoi, la seule solution est de laisser l'utilisateur paramétrer son navigateur pour l'impression. Par exemple, pour que les factures sortent correctement, il faut fixer les marges à des valeurs particulières et supprimer les informations d'en-tête et de pied de page. La première idée était de sortir les factures sous format PDF, mais cette solution a été abandonnée suite à la complexité du document à mettre au point. En effet, la structure du fichier PDF doit se programmer, ce qui est relativement facile pour mettre en page un texte mais devient très complexe dans le cas de ce document, du fait de la présence de nombreux tableaux et des contraintes d'affichage. De plus, la création d'un fichier par factures pose un second obstacle : avec plus d'une centaine de factures mensuelles, les imprimer une à une aurait été fastidieux. Je me suis donc tourné vers une solution purement HTML en essayant dans un premier temps de placer chaque élément précisément sur la page à l'aide des feuilles de style. Mais je me suis heurté au problème de l'impression simultanée de plusieurs factures. Le fait de placer chaque élément de la facture par rapport à sa position relative sur la page, affiche, quand l'utilisateur demande l'impression de la facturation d'un mois donné, toutes les factures superposées sur une seule feuille. La seule solution envisageable est alors de structurer la page avec des tableaux invisibles. Finalement, lorsque l'utilisateur demande la facturation, l'application ouvre une fenêtre contenant toutes les factures demandées à la suite avec un saut de page à l'impression entre chacune d'elles. Lors de la mise en page, il faut que chaque facture prenne la même place en hauteur. Il est par conséquent nécessaire de connaître le nombre de lignes nécessaires à son édition pour compléter le document avec des lignes blanches. De plus, pour afficher un libellé sur plusieurs lignes sans agrandir la case du tableau conteneur, le texte doit contenir des retours à la ligne mais sans couper les mots. Page 26 / 38

27 Cette fonction de mise en page disponible sur n'importe quel traitement de texte n'est pas implémentée dans le langage ASP. J'ai donc dû mettre au point une fonction permettant, à partir d'un texte quelconque, de renvoyer ce texte avec des retours à la ligne pour éviter d'agrandir le tableau, tout en interdisant la césure des mots (ce qui se produisait si on laissait Internet Explorer gérer le texte). Exemple de Facture : Structure dans la base de donnée : Format à l'impression : Page 27 / 38

28 La facturation du Web-Gepor se divise en deux parties : Facturation Automatique : Le principe de ce module est d'extraire depuis les rapports du mois les données (le tonnage facturé, le tarif, le client, les produits) pour établir les factures. Ces données sont formatées puis enregistrer dans la base de données. Pour établir une facture, on somme les tonnages de toutes les activités liées à un client, facturés à un tarif correspondant à la prestation (tarifs de nuit, taxe de voie ferrée,...) Facturation Manuelle : Ce module présente à l'utilisateur un masque de saisie pour lui permettre d'entrer des factures manuelles sous la même forme que celles générées automatiquement. Il choisit le client puis saisit chaque ligne en renseignant la quantité et le montant de la prestation ainsi que sa description. La facturation est une partie sensible de l'application étant donné que l'on touche à la comptabilité de l'entreprise, il est nécessaire de mettre en place des verrous pour limiter les droits de l'utilisateur. C'est ainsi qu'on ne peut pas supprimer de factures excepté la dernière saisie manuelle. On peut aussi recommencer à générer les factures automatiques si une erreur venait à être détectée. Ces limitations permettent d'assurer une certaine sécurité contre les fausses manipulations, et l'effacement accidentel de données. Chaque commande désirant être exécutée doit à chaque fois être confirmer ce qui permet d'avertir l'utilisateur et de lui éviter les fausses manipulations. Lors du développement, une bonne partie du temps a été consacrée à vérifier manuellement les résultats (tonnage et montant) avancés par les factures pour ne pas envoyer des documents non conforme aux clients. Concernant la facturation automatique, la saisie d'un rapport déclenche un tarif en fonction de la prestation. Avant mon stage, ce tarif était fixé par rapport à quelques règles basiques codées en dur (en javascript) dans les sources ASP. Le problème avec cette méthode, c'est que GEPOR est en expansion et son activité évolue. Par conséquent, les conditions amenant à un tarif peuvent changer. C'est pourquoi, j'ai mis en place un état servant d'intermédiaire entre la saisie des rapports et les tarifs. Le contrôleur de gestion peut entrer des règles mathématiques qui déclencheront un code tarif : par exemple, la prestation du déchargement (1), sur la famille des combustibles (600), sur un poste de nuit (N) correspond au code tarif A. Un second état avec la correspondance entre code tarif et montant du tarif est tenu à jour. Cet état possède une fonction historique qui permet au comptable de connaître quand a eu lieu la dernière modification de la valeur du tarif et quelle personne s'est occupée de cette mise à jour. Page 28 / 38

29 3.2.6 Exportation de la comptabilité Après avoir sorti avec succès les factures de l'application Web-Gepor, la dernière partie de la chaîne logistique consiste à envoyer les données de ces factures vers le logiciel de comptabilité utilisé par la société : SAGE. GEPOR n'avait pas de documentation sur le format du fichier d'importation de SAGE. Tout ce que l'on savait, c'est qu'une personne externe avait développé un petit programme qui convertissait les données de l'ancien système (AS/400) en fichier texte prêt à être importer dans SAGE. Seulement, aucune source ou explication n'était disponible. C'est pourquoi, la seule méthode pour en comprendre le fonctionnement est d'utiliser le reverse engineering : à partir de la comptabilité d'un précédent mois enregistré dans SAGE, on a exporté les données vers un fichier texte, puis analyser la structure de ce fichier. Ce dernier est en fait constitué de balises qui délimitent chaque facture. Les données de la facture sont aléatoirement entrecoupées de sauts de ligne et de valeurs nulles. Après quelques jours de tests, je connaissais les transformations à effectuer pour créer ce fichier servant d'intermédiaire entre les deux applications. Les seules contraintes qui m'ont obligé à recommencer un bon nombre de fois mes tests sont les limitations des champs : le nom du client, par exemple, ne pouvait pas dépasser 15 caractères sous peine de faire échouer l'importation. Une fois le fichier d'importation créé sur le serveur, il doit être envoyé au client par le biais du navigateur. Après avoir essayé de développer mon propre script de gestionnaire de téléchargement, j'ai découvert qu'asp intègre un composant COM gérant les transferts de fichier client/serveur. Je devais passer par un script de téléchargement de fichier car un lien HTML vers ce dernier provoquait l'ouverture dans le navigateur et non le rapatriement sur le disque dur. Avec ce script, le navigateur web ouvre une fenêtre de téléchargement et l'utilisateur n'a plus qu'à choisir la destination pour enregistrer son fichier et gérer son importation vers le logiciel de comptabilité. Un problème qui nous a échappé dans un premier temps est les disparités entre les montants des totaux apparaissant sur les factures et les montants dans SAGE (de quelques centimes d'euros). Celles-ci étaient dues à deux méthodes différentes pour calculer et arrondir les totaux. Ma première idée était d'effectuer tous les calculs de la facture (multiplication de la quantité par le montant, puis somme des montants) et d'arrondir le total à la fin pour qu'il soit le moins approximatif possible. Mais SAGE gère les factures un peu différemment : dans son journal des ventes, il calcule le montant de la facture à partir des totaux arrondis de chaque prestation puis somme ces montants arrondis. Avant la correction, la comptabilité se retrouvait avec une différence entre son logiciel et l'application intranet ce qui pose problème étant donné que le premier sert à prélever l'argent à la banque et le second à justifier, par le bais de la facture, le prélèvement effectué. Page 29 / 38

30 3.2.7 Réorganisation de la partie suivi des stocks Le suivi des stocks n'existait pas dans la version précédente de l'application (AS400). Cette facette a été commencée par le précédent stagiaire, mais, certainement à cause d'un manque d'informations, il a mal su gérer les conditions nécessaires à la mise à jour des stocks. Par conséquent, bien que cette facette ne fasse pas partie du planning prévisionnel, j'ai repris quasiment tous les états développés à zéro. Sur le terrain, les stocks sont identifiés par des numéros de tas. Au niveau de l'application, chaque tas est donc identifié par son numéro, le port auquel il appartient, le produit qu'il contient, et le code stock du vapeur de mer qui a amené le produit. Le souci avec la version précédente est l'obligation pour le contrôleur de gestion de valider tous ses rapports dans un ordre chronologique ce qui en pratique ne pouvait pas être réalisable. A bien des reprises, après la validation d'un rapport, des erreurs de saisie étaient découvertes et corrigées. Le fait de revenir sur un rapport validé ne mettait à jour ni le suivi des stocks, ni son historique ce qui faussait toutes les statistiques. La nouvelle version du suivi des stocks comprend un état où le contrôleur de gestion saisit à chaque début de mois, le tonnage des produits restants sur les tas, permettant de limiter les différences entre le tonnage restant physiquement et celui du système informatique. Ces stocks initiaux sont conservés dans la base de données pour l'élaboration d'un état récapitulatif sur les mouvements de produits. A partir de là, j'ai construis un état qui récupère pour le suivi du produit demandé le tonnage de son stock initial. Puis il parcourt les rapports d'activités pour afficher les entrées/sorties. Ainsi, on ne sauvegarde plus comme auparavant les entrées/sorties mais on les calcule en dynamique. Avec cette méthode, la modification d'un rapport est immédiatement prise en compte. L'avantage avec cette méthode est qu'elle donne suite à d'autres états statistiques comme le suivi d'un produit sur une plus grande période, depuis sa première introduction dans l'activité du port jusqu'à son épuisement. Page 30 / 38

31 3.2.8 Généralités Généralement, pour construire un nouvel état, la méthode consiste à se demander quels sont les paramètres que l'utilisateur va pouvoir choisir (un intervalle de dates, critères de tri), quelles sont les données à aller rechercher dans la base de données et comment traiter ces données. Le plus souvent, la requête est mise au point sous «MS Query Analyser» pour avoir un aperçu du résultat de sortie, puis injecter dans le code source sous forme d'objet. Après, il ne reste plus qu'à réfléchir sur l'algorithme de parcours des enregistrements de la requête pour envoyer au navigateur les données formatées. Tant qu'on n'a pas atteint la fin des enregistrements Traiter les données Afficher les données Passer à l'enregistrement suivant Fin Tant Que L'interaction entre ASP et le serveur SQL est très conviviale : les méthodes disponibles pour l'objet ADO conviennent à tous les usages : Avancer dans un enregistrement, reculer, aller au premier, aller au dernier, test sur la fin du fichier, afficher la source de la requête, mise à jour des champs de l'enregistrement, suppression Les composants ActiveX Data Objects (ADO) permettent d'établir une interaction entre une application Web et des sources de données. Code : Définition d'une variable de session dans un fichier global contenant le nom du serveur de base de données, le type et le nom de la base, ainsi que le nom d'utilisateur et le mot de passe pour y accéder. Session("ConnectionString") = "Provider = sqloledb; Data Source=FLO-APP-SQL01; Initial Catalog=GEPORT; User Id=******; Password=******* " Création d'un objet ADO qui représente la connexion à la base Set Cn = Server.CreateObject("ADODB.Connection") On établit la connexion avec les paramètres définis dans ConnectionString Cn.Open Session("ConnectionString") Création d'un objet Requête Set MaRequete = Server.CreateObject("ADODB.RecordSet") Définition de la requête MaRequete.Open SELECT * FROM TAP001 WHERE...,Cn,0,3 Un des principaux reproches que l'on peut faire au langage de scripts VBScript, c'est le manque de clarté dans la gestion des variables : d'un côté, il permet de programmer sans se soucier du type de la variable (entier, réel, chaîne de caractères, ), et de l'autre, si on compare deux variables non typées à la source, mais qui au test de comparaison ne sont pas du même type, cette dernière échouera. Page 31 / 38

32 C'est ainsi que, avant de connaître cette particularité du langage, plusieurs tests avec les opérateurs de comparaison ne renvoyaient jamais la valeur booléenne vrai bien que le contenu des variables testées soit identique. La technique consiste donc à utiliser les fonctions pour transtyper les variables (les convertir en un type défini). Sinon, le langage est finalement assez simple à prendre en main et après six mois, je le maîtrise correctement. 3.3 Synthèse de mon travail Synthèse des problèmes rencontrés La conception de ce projet ne s'est pas faite sans problème, bien que je peux dire qu'aucun ne m'a réellement bloqué dans mon avancement : Conception des états : La première difficulté de ce projet a été de se familiariser avec le langage de l'entreprise pour comprendre et analyser les demandes de l'utilisateur. Les premières semaines, les états développés étaient rarement corrects lors de leur première mise en application. La tâche consistait à bien comprendre les besoins de l'utilisateur pour essayer de prévoir ou d'anticiper sa demande. Si j'arrivais à envisager les fonctionnalités finales d'un état (ce qui n'était vraiment pas évident au début du stage), je pouvais alors gagner du temps sur sa conception puisque j'évitais de revenir à plusieurs reprises pour corriger les imperfections et les cas omis. Ainsi, avant de me lancer dans la programmation d'un état, je devais contacter les personnes intéressées pour essayer de leur faire ressortir les éléments qui seront utiles pour sa création. Etape pas toujours évidente du fait de la différence entre le langage employé par les utilisateurs pour décrire ce dont ils ont besoin et notre langage plus technique pour prévoir le fonctionnement de la demande dans son contexte informatique. La base de données : Le problème avec la base de données conçue par le 1er stagiaire est qu'elle ne contient aucun champs clé avec incrémentation automatique ce qui complique certaines requête avec des jointures complexes. Les clés primaires se situent sur des champs variables et servent donc à limiter les enregistrements à champs identiques. Le fait de ne pas recourir aux champs à incrémentation automatique implique de contrôler l'insertion de données dans les tables pour ne pas générer d'erreur suite à des doublons dans la clé primaire. Page 32 / 38

33 Scripts ASP : Malheureusement, l'état du projet lors de ma venue m'a imposé à consacrer une bonne partie de mon temps à corriger les erreurs des précédents stagiaires et surtout, refaire la mise en page des sources et d'ajouter des commentaires même sur des facettes que je n'avais pas développée. Ceci dans le but de laisser un projet plus compréhensible et lisible à la personne qui va reprendre l'application pour la maintenance, mais aussi pour me faciliter la reprise des scripts après plusieurs semaines sans travailler dessus. J'étais conscient que la correction des erreurs d'autrui n'était pas vraiment le travail le plus gratifiant de mon stage. De plus, pendant ce temps, l'évolution du projet se retrouvait ralentie. Mais je pense que ce travail n'a pas été réalisé en vain car l'application est aujourd'hui beaucoup plus accessible pour sa maintenance. La documentation : Les documentations sur le projet laissées par les précédents stagiaires sont loin d'être exhaustives (je n'ai moi-même pas eu le temps de rédiger beaucoup de documents pour expliquer le fonctionnement du projet, mais j'ai passé plusieurs journées à commenter mon code source dans les détails). Une documentation sur la base de donnée avait été initiée mais n'a pas été mise à jour à chaque modification effectuée par le premier stagiaire. De ce fait, on s'est retrouvé avec un document ne reflétant pas la structure exacte de la base. Aucun modèle de donnée tenu à jour n'était disponible, excepté celui de la partie fluviale, ce qui ne facilitait pas la compréhension du système de données et posait problème pour retrouver les jointures entres les différentes tables. Le manque de documentation en général a été un frein à la compréhension et à la maîtrise rapide de l'environnement de développement de l'application Synthèse des résultats En premier lieu, le but de ce stage était, pour moi, la découverte de l'informatique industrielle de gestion, afin de me faire une idée sur les différents secteurs de l'ingénierie informatique. Elle n'est pas la voie qui m'attire le plus parmi tous les métiers de l'informatique, mais c'est un bon débouché pour tous ce qui concerne la conception de logiciels. Durant mon stage, j'ai pu avoir un aperçu de l'introduction de nouvelles technologies dans une société où la moyenne d'âge dépasse la cinquantaine. Ainsi, je devais soigner l'interface et la maniabilité de l'outil pour ne pas poser de difficultés aux utilisateurs. Il faut pour cela proposer des applications simples à utiliser et sans erreurs pour ne pas les rebuter. Je considère aussi ce stage comme une réussite au niveau des contacts humains et sur la compréhension des demandes des utilisateurs, ce qui a été possible par ma présence sur le terrain et mes contacts directs avec les personnes intéressées. Être proche de l'utilisateur garantit que celui-ci peut directement me joindre pour signaler des problèmes, proposer des améliorations et valider mon travail. Page 33 / 38

34 Ce stage a été pour moi l'occasion d'enrichir mes connaissances personnelles en développement Web. Maîtrisant déjà le langage PHP/MySQL de la plate-forme Open Source, la connaissance de l'asp/sql Server permet de couvrir quasiment toutes les applications du Web puisque la majorité des sites sont développés soit en PHP, soit en ASP (avec la croissance depuis quelques temps de ASP.NET, un nouvel environnement permettant de créer des pages Web avec l'aide des nouveaux langages rattachés à la plate-forme.net comme le C#). La programmation d'applications Internet/intranet est un secteur de l'informatique que je trouve particulièrement intéressant car j'apprécie de développer avec des langages puissants et dont l'adaptation est relativement facile. Cependant, depuis que je connais l'asp, je préfère la programmation PHP pour plusieurs raisons : je trouve ce langage plus strict et mieux structuré de part ses ressemblances au langage C, mais surtout la présence d'une communauté plus importante, avec de la documentation de qualité, des sites Internet et des forums pour apprendre, recevoir de l'aide, ou récupérer des scripts existants. Ce stage était aussi l'occasion de renforcer mes acquis en SQL, puisque j'ai consacré une partie de l'étude à mettre au point des requêtes plutôt complexes. C'était l'occasion d'améliorer mes connaissances dans ce domaine, et par conséquent, d'être capable d'avoir un aperçu des possibilités les plus avancées de ce puissant langage de manipulation de donnée. Au niveau des compétences, la gestion d'un véritable projet sur une longueur de six mois m'a permis de me rendre compte de la difficulté d'une planification à long terme, et de la différence entre le planning prévisionnel et réel. Avant ce stage, le plus long projet réalisé ne s'étendait pas sur plus de 10 semaines. Ainsi, la gestion de projet n'est pas un travail à prendre à la légère puisqu'il permet, s'il est effectué correctement, de gérer au mieux les ressources disponibles. Le développement de Web-Gepor m'a fait découvrir un visage de l'informatique où la moindre erreur n'est pas tolérée. Ainsi, avec le développement de la facturation, j'ai appris à contrôler plusieurs fois mes algorithmes, à analyser à maintes reprises les sorties des états pour éviter au mieux les erreurs ou les anomalies dans ce module. Cette facette exigeait effectivement de la rigueur dans la conception car l'entreprise ne pouvait pas envoyer de factures avec des montants incorrects et de plus, elle ne pouvait rester dans l'attente d'une correction puisque les factures doivent sortir à la fin du mois. C'est ainsi que parfois, j'ai dû m'adapter à l'urgence avec l'ajout de contraintes de temps pour la réalisation de certaines parties de l'application. Page 34 / 38

35 3.3.3 Vision critique de l'application L'application développée n'est pas parfaite. Après mon départ, il est possible que TIXIS interviennent pour modifier ou corriger des problèmes éventuels venant de cas ou de conditions n'ayant pas été testés. Cependant, malgré la complète fonctionnalité de l'application, il faut bien avouer que quelques points ne sont pas exempts de critiques : Web-Gepor a été peut être mal conçu au départ : faire de la rétro-conception à partir d'une application existence pour l'adapter à une nouvelle technologie, puis greffer par-dessus de nouvelles fonctionnalités, n'était peut être pas le meilleur choix. En effet, la base de données issue de l'as/400 a été dans un premier temps recopiée quasiment à l'identique, sans trop réfléchir aux nouveautés à implémenter ou sur une nouvelle manière d'organiser ces données dans la base. Comme les fondements avaient été érigés avant mon arrivée, je ne pouvais pas remettre en cause le travail déjà effectué. J'ai donc continué le développement malgré les limitations du système en faisant tout mon possible pour rattraper les maladresses de conception. A plusieurs reprises, j'étais dans l'obligation de modifier complètement la structure de certaines tables de la base créées lors du démarrage du Web-Gepor pour les adapter au nouveau système. La complexité de l'application à mettre en place ne pardonnait pas les oublis ou les erreurs non corrigées sur les tables principales du Web-Gepor. Concernant les défauts de l'application, cette dernière laisse l'impression d'avoir été développé en négligeant certaines parties. Par exemple les droits d'accès des utilisateurs : bien que chaque utilisateur soit associé à une liste de facettes à laquelle il a accès (avec un contrôle au niveau des variables de session), cette même personne, si elle connaît le nom d'une page correspondant à un état qu'elle n'a pas le droit de voir en théorie, pourra l'afficher sans problème (on ne peut pas faire de contrôle d'accès sur la page, puisqu'une page peut appartenir à plusieurs facettes). On a donc essayé de mettre en place une sécurité mais qui n'est efficace qu'à moitié : elle permet de filtrer les gens qui pourront entrer dans l'application, mais pas de sécuriser correctement les différentes facettes une fois la personne identifiée (des utilisateurs extérieurs à l'entreprise mais faisant partie du réseau ARCELOR peuvent donc contourner les sécurités). Page 35 / 38

36 Conclusion : Le développement de l'application permettant un suivi complet de l'activité portuaire de la société GEPOR a renforcé mon expérience du travail en entreprise aussi bien en terme de relations humaines que de compétences techniques. La mise en place de ce site intranet a permis de réaliser un gain financier non négligeable puisque le nouveau système informatique reviendra à 4500 euros par an au lieu des euros nécessaires à la maintenance de la précédente application. En plus de ce gain financier, GEPOR a gagné en productivité en se séparant de la majorité des innombrables feuilles de calculs remplies chaque jour pour suivre l'activité. L'objectif fixé au départ est atteint : à la fin de mon stage, l'application est complètement opérationnel et permet de gérer toute la logistique de l'activité portuaire de la société GEPOR. Cependant, je suis conscient que ce projet n'est pas parfait puisque certaines évolutions de l'activité de l'entreprise obligeront à réouvrir le code de l'application pour rajouter de nouvelles fonctionnalités. Mais je pense que le temps passé à nettoyer le code, à respecter les standards du HTML et à commenter mes scripts permettra à TIXIS de gérer la maintenance du projet dans de bonnes conditions. Je retiendrais de ce stage l'engagement personnel que j'y ai mis pour montrer ma motivation et ma volonté de réussir, voir d'essayer de faire mieux que ce qu'on me demandait. Enfin, je pense avoir réellement acquis un savoir-faire dans le développement informatique après ce stage. Page 36 / 38

37 Lexique : Affrètement : L'affrètement est le contrat par lequel l'armateur s'oblige, en tant que fréteur, à mettre à la disposition de l'affréteur, comme rémunération, tout ou une partie de la contenance d'un navire désigné, soit pour une durée déterminée (charte-partie au temps), soit pour un ou plusieurs voyages déterminés (charte-partie au voyage). Amont : Tout ce qui arrive à GEPOR. Allège : Bateaux (ou péniches) faisant la navette entre Anvers et le Port d'illange. Elles transportent jusqu'à 3000 Tonnes de produit. Armateur ou Affréteur : Société qui fait naviguer les allèges. Aval : Tout ce qui part de GEPOR. Vapeur de Mer : Minéraliers pouvant transporter Tonnes de produit. Naviguent uniquement sur mer et déchargent aux ports de mer (Anvers, Dunkerque,...). Coils : Bobines de tôles brutes. Brame : Produit semi-fini obtenu en laminant des lingots ou coulé en continu à l'aciérie, et coupé en différentes longueurs. La brame a une section transversale rectangulaire et est utilisée comme matériau de départ dans le processus de production de produits plats, c'est-à-dire des bobines laminées à chaud ou des plaques. Agglomération : Installation dans laquelle du minerai de fer fin, homogénéisé, est mélangé à de la chaux et à du poussier de coke puis cuit par combustion de coke. L'aggloméré, sorte de mâchefer, constitue l'essentiel de la charge minérale du haut fourneau. Service Destinataire : Service particulier d'un client (cokerie, agglomération, hauts fourneaux,...). Indentation : Mise en page minimaliste réalisée essentiellement à l'aide de tabulations, afin de rendre un code source plus lisible, en faisant ressortir visuellement la structure du document, notamment les structures de contrôles d'un programme. W3C (World Wide Web Consortium) : Organisme s'occupant de la normalisation des standards du web. HTML : HyperText Markup Language : langage de balisage hypertexte qui permet de mettre en forme les données pour les afficher dans un navigateur web. SQL : Structured Query Language, ou Langage d'interrogation des Données. Permet par le biais de requête, d'accéder aux informations d'une base de données. Page 37 / 38

38 Bibliographie : Sites Internet (2004) : : Quick Reference of ASP : Cours sur l'asp : SQL de A à Z / particularités de SQLServer : Section Vbscript / JavaScript / ASP : Encyclopédie libre : Site du Groupe ARCELOR : Explications sur Javascript / VbScript Les différentes sites intranet du groupe Arcelor Livres : Javascript pour les nuls, de Emily A Vander Veer, aux éditions First Interactive. Paru le 18 avril 2001 (ISBN : ) Gestion du Port Fluvial d Illange par Yoann DIDRY, mémoire présenté en vue d obtenir le diplôme d ingénieur IIE. (Juin 2004) Page 38 / 38