Pour décrire le travail effectué, nous utiliserons une présentation un peu particulière. En effet, ce chapitre a été découpé en deux sous-chapitres, afin de le rendre plus clair. Les deux parties de ce stage ont été accomplies en même temps, mais la première était consacrée à la réalisation d'une maquette pour un site de paiement électronique. Elle sera intitulée 'Maquette de paiement électronique'. Parallèlement à celle-ci, l'objet de la seconde était de procéder à : Elle sera intitulée 'Amélioration de la recherche par activité'.

3.1 Maquette de paiement électronique

3.1.1 Le cahier des charges de la maquette de paiement électronique

Aujourd'hui, ORT s'oriente vers le commerce électronique sur Internet, après s'être imposé avec le Minitel. Ses services sur le renseignement d'entreprise (par exemple '36 17 Euridile') l'on fait croître. Mais pour beaucoup le commerce électronique est encore un mythe ; en effet, seulement quelques sites américains réalisent des profits (Amazon, Altavista...). Ainsi nous verrons au cours de ce projet les techniques qui sont utilisées puis, les normes et outils de paiement retenus. Lorsque M. Gaume m'a demandé de réaliser cette maquette de paiement, une première étude avait été effectuée par M. Collet. Celle-ci avait permis d'obtenir une vue générale du fonctionnement. M. Gaume s'est occupé de trouver les moyens et les acteurs pour la mise en place de cette évolution au sein du groupe ORT. Ce chapitre sera conclu par une présentation de la maquette réalisée.

3.1.1.1 But général

Le but est de fidéliser les clients. ORT tend à transposer toutes les offres Minitel vers Internet (suppression progressive des offres Minitel, ainsi que des liaisons spécialisées - LS). De plus, elle souhaite conquérir de nouveaux clients, ce qui lui permettrait de s'ouvrir à d'autres marchés. Le service doit donc offrir différentes solutions de paiement (abonnement, paiement à la consultation...) adaptables à chaque profil, avec une interface intuitive et qui plaise à un large public. Nous nous attacherons à présenter ce projet, en commençant par une étude du marché qui aboutira sur la solution retenue. Pour finir, nous étudierons le principe de fonctionnement de la maquette retenue.

3.1.1.2 Explication détaillée des résultats à obtenir

Pour comprendre ce qui était nécessaire de mettre en place, considérons un exemple type de navigation et de paiement. Dans notre étude, la personne qui cherche des informations et qui est connectée à l'Internet sera nommée 'internaute', il s'agit d'un client. Voici donc une procédure classique qui permet d'appréhender les besoins.

L'internaute est parvenu sur un des sites du Groupe ORT. Pour permettre un suivi des sessions utilisateurs, chaque connexion est identifiée par un numéro sur le serveur ORT. L'internaute a procédé à une recherche dans une base de données (article de La Tribune, annonce officielle...). Après avoir retrouvé l'information il devra choisir un mode de paiement l'autorisant à avoir accès au document sélectionné.

Pour ce projet, le principe de paiement a été copié sur le modèle du Minitel (qui est un réussite pour la société) auxquels ont été rajoutées des solutions propres au WEB. Voici donc les différentes solutions de paiement :

1. Accès sans abonnement :

2. Accès par abonnement : Mais pour toutes ces méthodes de paiement, il faut réaliser une interface qui soit le plus clair possible pour éviter toute confusion de la part de l'utilisateur.

3.1.2 Compte-rendu d'activité sur la maquette de paiement électronique

Pour ce projet, je n'ai pas suivi de plan de développement précis, car il s'agissait plutôt d'une activité annexe au déroulement de mon stage. Ainsi, M. Gaume venait me voir régulièrement pour modifier la maquette. N'ayant jamais été confronté au paiement électronique sur le WEB, j'ai donc visité plusieurs sites Internet et lu plusieurs documents traitants de ce sujet. Dans ce qui suit, vous trouverez une étude de ce qui est utilisé sur le Réseau des Réseaux ainsi qu'un résumé des techniques employées. Nous conclurons sur la dernière maquette qui a été réalisée. Les différentes versions de celle-ci ont permis la validation étape par étape de la mise en place du projet.

3.1.2.1 Axes d'étude et de recherche choisis

La plupart des choix que j'ai opéré ont été fondé sur : Nous montrerons ce que représente le commerce électronique, les modifications techniques à apporter pour le mettre en œuvre ainsi que les aspects juridiques.

Puis nous terminerons par une présentation de la maquette.

3.1.2.2 Présentation

3.1.2.2.1 Mise en œuvre d'un système de commerce électronique
Une solution de commerce électronique est un nouveau composant qui vient s'insérer dans les processus existants qui régulent le fonctionnement de l'entreprise. Il doit être conçu pour s'intégrer le mieux possible dans sa manière de travailler.

L'environnement de commerce électronique, pour être complet et opérationnel, doit impérativement comprendre les éléments suivants :

A - Un "catalogue" électronique
     Il permet de présenter aux clients internautes les produits que l'on propose à la vente. Ce catalogue doit permettre de mettre en valeur les produits et leurs caractéristiques. Il doit offrir des moyens conviviaux de recherche d'un produit particulier et de stockage d'articles dans un panier virtuel. Des versions évoluées permettent de gérer des promotions ponctuelles, des systèmes de remises, des profils et des données client, etc. D'autre part comme Internet une clientèle potentiellement internationale, il est souvent intéressant de proposer des versions du catalogue en plusieurs langues. Enfin ce catalogue doit évidemment être doté d'outils permettant de gérer son contenu : ajout d'un article, modification des informations (prix, etc.).
B - Un système de paiement sécurisé
     Lorsqu'un client a choisi tous les articles qu'il voudrait acquérir, on doit lui proposer un système fiable et sécurisé pour réaliser un paiement en ligne. De nombreuses technologies sont disponibles, et il est important de choisir celle qui conviendra le mieux. Nous verrons dans la suite ces différentes technologies.
C - Un outil d'administration et de gestion de la boutique
     Comme une boutique classique, un magasin virtuel demande un minimum de gestion. On a besoin d'un outil qui permettra :
  • de prendre connaissance des commandes passées au fur et à mesure qu'elles sont enregistrées au niveau du catalogue électronique ;
  • dans certains cas (par exemple commerce électronique interentreprises), d'éditer des factures, des bons de livraisons … ;
  • d'étudier la fréquentation de la boutique, et d'analyser le comportement des clients, les rotations des produits...
D - Une logistique adaptée
     Ce volet est souvent négligé, car on suppose que les produits sont des informations et donc qu'elles ne sont pas physiques, mais il ne faut pas oublier de gérer le renvoi d'information au client par courrier, par Fax ou par E-mail.
E - Une promotion efficace
     Une fois que la boutique est réalisée, en ligne et opérationnelle, on doit la faire vivre, et inciter les clients internautes à venir la visiter régulièrement. Pour cela une réflexion sur la promotion, l'animation et au positionnement de la boutique électronique s'impose.
3.1.2.2.2 Risques encourus en effectuant une transaction et solutions
     L'étude de la sécurité des transactions sur Internet revient à évoquer trois réalités distinctes à ne pas confondre:
  1. L'identification des acteurs de l'échange.
  2. L'authentification des actes commerciaux.
  3. La confidentialité de certaines données, telles que le numéro de carte bleue.
Les différentes technologies, les concepts de sécurité mis en œuvre pour se prémunir contre ces risques, les protocoles développés par certains groupements industriels ainsi que les services existant sur Internet sont présentés dans ce qui suit.
A - Authentification
     Ce service permet d'authentifier les entités qui communiquent entre elles, préalablement à tout échange de données. Il a pour but de garantir l'identité des correspondants. On peut distinguer deux types :
  • l'authentification de l'entité homologue qui assure que l'entité réceptrice qui est connectée est bien celle annoncée. Son principal objectif est la lutte contre le déguisement.
  • l'authentification de l'origine qui assure que l'entité émettrice est bien celle prétendue.
B - Confidentialité des données
     L'objectif de ce service est d'empêcher des données d'être compréhensibles par une entité tierce non autorisée, le plus souvent en état de fraude passive, c'est-à-dire en écoute de l'information sur le réseau.

On distingue :

  • la confidentialité intégrale où l'ensemble des données transmises doit être protégé;
  • la confidentialité d'un champ spécifique où la protection est assurée pour quelques données incluses dans une transmission.
C - Intégrité des données
     Contre les fraudes actives (brouillage, modification des données ou de l'identité, déguisement en émission ou en réception), ce service détecte les altérations partielles ou intégrales des données entre émetteur et récepteur.
D - Non-répudiation
     On distingue deux types de non-répudiations :
  • la non-répudiation à l'origine des données qui fournit au récepteur une preuve ou attestation empêchant l'émetteur de contester l'envoi ou le contenu d'un message effectivement reçu,
  • la non-répudiation de la remise qui fournit à l'émetteur une preuve empêchant le récepteur de contester la réception ou le contenu d'un message effectivement remis.
E - Conclusion
     En fonction des services de sécurité et des mécanismes de sécurité, nous pouvons en déduire les solutions suivantes pour résoudre les risques définis précédemment:
  • une des solutions pour résoudre le problème lié à l'identification des parties d'un échange est l'utilisation des algorithmes de chiffrement 'à clé publique' (de type RSA) qui permet de garantir l'identité des deux interlocuteurs d'un échange. Un message chiffré par la clé privée de l'émetteur ne peut être déchiffré qu'avec la clé publique de cet émetteur, dont le récepteur dispose ; un message chiffré avec la clé publique du destinataire ne peut être déchiffré que par celui-ci, à l'aide de sa clé privée.
  • une des solutions pour assurer l'authentification des actes commerciaux peut être les mêmes algorithmes à clé publique qui permettent, d'une part, de signer un acte de manière irréfutable, et d'autre part (grâce à un ' résumé' numérique du message, lui-même signé) de contrôler l'intégrité du fichier.
  • pour terminer une des solutions pour garantir la confidentialité est le chiffrement. La sécurisation des paiements électroniques pose deux questions, l'une relative à l'intégrité et la confidentialité des données, l'autre concernant les processus ou le protocole qui doit être utilisé.
3.1.2.2.3 Paiement électronique sur Internet
Nous constatons que les solutions technologiques se multiplient pour proposer des échanges sécurisés sur Internet. Il existe des groupements industriels qui travaillent pour concevoir un standard pour les paiements en ligne. Certaines sociétés offrent déjà des services proposant des transactions sécurisées.

Le but de ce chapitre est de présenter les différentes manières qu'offrent ces services pour payer un produit ou un service sur Internet ; ainsi que les acteurs participant au développement du paiement électronique.

A - Principaux systèmes de paiement de l'Internet
     Trois systèmes de paiement s'organisent et se rodent aujourd'hui sur Internet : le paiement par carte bancaire, l'argent liquide électronique ou la gestion de compte intermédiaires de paiement. Il existe aussi d'autres systèmes, mais qui présentent peu d'intérêt pour notre étude.
B - Carte de crédit
     On peut payer directement avec sa carte de crédit au fournisseur en transmettant le numéro, la date d'expiration et le nom du porteur de celle-ci. Le fournisseur transmet ces informations à l'organisme gestionnaire de la carte, les contrôle, débite le compte du client et crédite celui du fournisseur.

C'est une solution très utilisée actuellement mais qui n'est absolument pas sécurisée. Si le message ainsi constitué n'est pas chiffré, il y a un risque évident d'interception malveillante des informations ; la capture des données pouvant se produire n'importe où, sur les serveurs ou sur les équipements de communication.

Si le message est chiffré, le risque devient quasiment nul ; les systèmes de clés privées et publiques étant pratiquement inviolables.

Ce système présente quelques limites :

  • le système de paiement par carte bancaire n'est pas adapté aux petites transactions, le coût du traitement d'une opération pouvant être supérieur à la valeur de la transaction elle-même ;
  • un paiement ne peut être reçu que par un fournisseur agréé. Le système ne permet pas de transférer de l'argent à n'importe qui ; il ne permet pas à tout un chacun de vendre sur Internet, à moindres frais ;
  • le client n'est pas anonyme ;
  • le fournisseur, et plus encore l'organisme gestionnaire, sont en mesure d'exploiter des informations nombreuses et précises sur la consommation du client ;
C - Gestion des comptes intermédiaires de paiement
     Le principe : un organisme gère, pour le compte des débiteurs et des créanciers, les opérations de paiement.

Le client ouvre un compte auprès de l'organisme, soit en l'alimentant de manière préalable (pré-paiement), soit en autorisant celui-ci de débiter auprès de sa banque ou du gestionnaire de sa carte de crédit les sommes à payer aux créanciers.

Les créanciers signent un contrat avec l'organisme, qui précise la façon dont celui-ci doit leur reverser les sommes payées par les clients (ainsi, le cas échéant, les commissions prélevées par l'intermédiaire).

Un paiement peut être déclenché sur l'initiative du fournisseur (qui transmet à l'intermédiaire une facture approuvée par le client, soit en temps réel pour autorisation soit en temps différé), ou sur l'initiative du débiteur (qui prend contact avec l'intermédiaire pour lui indiquer ce qu'il faut payer. En aucun cas, les informations bancaires du client ne sont transmises au fournisseur ou au créancier.

De très nombreux systèmes correspondent aujourd'hui à ce schéma sur Internet : First Virtual, mais aussi Open Market et Globe ID de GCTech (France).

D - Numéro vert
     C'est un système rustique qui consiste à compléter une commande grâce à un numéro vert, ce qui laisse aussi la porte ouverte à toutes les malversations. Toutefois, c'est un principe souvent usité.
E - E-mail
     Un autre système, peu fiable, consiste après une commande, à donner des informations bancaires telles que son numéro de carte par le mail. Or celui n'est pas sécurisé. L'avantage de cette méthode est qu'elle distingue le circuit de commande du circuit de paiement.
F - Porte-monnaie électronique
     Il s'agit d'une carte en principe infalsifiable. Un banquier peut la remplir par le débit d'un compte. Grâce au lecteur d'un micro-ordinateur, elle délivre de la monnaie électronique sur le réseau que le prestataire peut récupérer. Le SEPT, Service d'Etude commun de la Poste et de France Telecom, à Caen, travaille sur le sujet depuis plusieurs années. Cette carte aurait aussi son intérêt pour le commerce traditionnel et plus particulièrement, celui où les transactions sont peu élevées.

Toutefois, le Groupement des cartes bancaires français semble peu enthousiaste pour le porte-monnaie électronique. Il considère que le chèque et la carte bancaire répondent largement aux besoins actuels.

3.1.2.2.4 Outil de commerce électronique
Le choix d'un outil de commerce électronique va devoir supporter diverses méthodes de paiement et tenir compte des logiciels actuellement en place. Suite à un tour d'horizon sur les solutions offertes, le plus apte à remplir le cahier des charges est le protocole SSL. Voici donc un résumé de ses caractéristiques.
Protocole SSL (Secure Sockets Layer)
     La technologie développée par Netscape Communications pour assurer la confidentialité et l'authenticité des communications sur Internet est appelée Secure Sockets Layer (SSL). C'est une plate-forme ouverte, mise dans le domaine public pour la communauté d'Internet. Nestcape Navigator et Netscape Commerce Server sont les premiers produits offrant cette technologie non-propriétaire.

Le but du protocole SSL est d'assurer la confidentialité et la fiabilité d'une communication entre deux applications de type client/serveur. L'avantage de SSL est qu'il soit un protocole de niveau applicatif indépendant des protocoles TCP/IP. En effet, le protocole SSL se situe en-dessous des protocoles tels qu'HTTP, Telnet, FTP, Gopher ; et au-dessus des protocoles TCP/IP.

Le protocole SSL fournit donc une connexion sécurisée possédant les six propriétés de base suivantes :

  • La connexion est privée ;
  • Les messages sont cryptés après la phase d'établissement où une clé secrète est choisie ;
  • La connexion est authentifiée ;
  • Le serveur est toujours identifié ;
  • La connexion est sûre ;
  • Le transport inclut la vérification de l'intégrité du message à l'aide de fonction de hashage (par exemple, SHA, MD5, etc).
Le seul rôle de SSL est de décrypter et d'encrypter le flux des données du protocole applicatif utilisé (par exemple, HTTP ou telnet). Cela signifie que toute l'information contenue dans une requête et une réponse HTTP est encryptée (incluant par exemple un numéro de carte de crédit).

SSL est inclus dans le logiciel Nestcape Commerce serveur et dans tous les logiciels Nestcape Navigator. Un logiciel client-serveur ne communique de façon sécurisée avec un fournisseur d'information que si ce dernier possède le serveur Netscape et un certificat numérique. Netscape Communications a engagé RSA Certificate Services, une division de la société RSA Data Security, Inc. pour fournir des certificats aux utilisateurs des serveurs Netscape. Elle pense engager aussi d'autres autorités de certification.

3.1.2.2.5 Aspects juridiques
Internet intervient dans un cadre juridique international dans lequel il n'existe pas ou peu de réglementations spécifiques. Dans ce qui suit nous mettons en évidence les problèmes juridiques posés par le paiement en ligne sur Internet. Ce qui terminera notre analyse technique.

L'existence même d'Internet, réseau mondial de transport de l'information dont les acteurs appartiennent à un nombre illimité de pays, pose le problème du droit applicable à ce nouveau média, à la fois dématérialisé et délocalisé. Le problème de l'identification des responsables, de l'attribution des responsabilités et de la qualification du délit se pose alors.

Le paiement en ligne sur Internet soulève d'autres problèmes qui concernent la protection des informations sur les réseaux, le régime et la validité des télé-transactions, la réglementation de l'argent électronique...

De plus, comme la transaction commerciale transite sur le réseau, les questions suivantes se posent : comment authentifier l'identité de l'émetteur et/ou celle du récepteur ? Comment garantir l'intégrité des données transmises ? Comment fournir la preuve qu'un message a bien été émis ou reçu ? Comment assurer la confidentialité et la sécurité des données ? Comment perquisitionner et intercepter les informations et données, sur un réseau mondial ? Le nombre considérable d'utilisateurs et la multiplicité des sites possibles d'infractions rendent très aléatoire non seulement l'identification des contrevenants mais également son appréhension.

Avec des contenus aussi divers que la communication et la messagerie, l'information et les transactions, les jeux et la vidéo, la grande question est quelle législation appliquer ? Les législations de la presse, celles de l'audiovisuel, celles des télécommunications, qui reposent sur la création des services, le statut des entreprises, la réglementation des contenus ; sur des principes radicalement différents selon le support utilisé, ces législations pourront-elles s'appliquer au réseau mondial Internet ?

Des problèmes de différence de taxation sur les produits engendrent également des problèmes (notamment aux Etats-Unis entre les différents états).

Voyons maintenant la réalisation de la maquette et les choix techniques retenus.

3.1.2.3 Déroulement concret des études

L'objet de mon stage ne portait pas sur la question des choix techniques car cette partie était déjà mise en place. Je me suis renseigné pour comprendre le choix de la solution retenue.
3.1.2.3.1 Choix techniques
Pour des raisons de simplicité, de coût et de fiabilité le Groupe ORT a fait appel à la société ATOS, pour la gestion des transactions financières (tout ce qui touche aux informations sur le paiement est traité par ATOS). Rappelons que la société ATOS est depuis longtemps impliquée dans la gestion des flux financiers (gestion des transactions entre distributeur de billet et établissement financier,...) et qu'elle est un organisme certifié pour les transactions électroniques. ORT sous-traite le paiement électronique de tous les services WEB.

Dans le but de tenir à jour les informations sur les clients d'ORT, ATOS envoie régulièrement des comptes rendus. La dénomination choisie par ATOS est SIPS (Service Internet de Paiement Sécurisé).

Voici est résumé du service offert.

Le commerçant choisi son mode de règlement :

2. Le commerçant choisi aussi les conditions de la transaction financière (devise).

3. SIPS est compatible avec :

Toutes les transactions sont sécurisées en utilisant le protocole SSL.

3.1.2.3.2 Explications sur la maquette réalisée
Cette étude intègre toutes les fonctionnalités nécessaires aux services WEB. Dans un premier temps, je ferai une description de la succession des écrans que l'utilisateur pourra voir puis-je reviendrai sur des détails techniques. Je finirai par une critique des résultats et de ce qu'il est possible d'améliorer.
3.1.2.3.2.1 Description du scénario
Pour cette maquette, qui doit rester générale, car elle s'intègre dans au moins 3 services WEB différents, nous sommes parties du principe que l'internaute avait sélectionné les informations qu'il voulait consulter.

Voici donc un schéma résumant les actions possibles, suivi d'une explication plus détaillée.

Description de la maquette
                  Description de la maquette

Comme vous pouvez le constater sur le schéma de fonctionnement, le principe est simple et se base sur un choix volontairement limité du degré de liberté de l'utilisateur. Cette limitation d'action de l'internaute :

  1. minimise les risques d'erreur ;
  2. permet d'aérer la présentation ;
  3. découpe les différentes parties en entités logiques, offrant une vision plus claire de ses actions.
Voici l'exemple d'un scénario lorsque l'utilisateur n'a pas d'abonnement et souhaite établir une facture : La maquette fut acceptée et validée par l'équipe supervisant les projets. Le fonctionnement est explicite. Il ne reste plus qu'à la mettre en place sur les serveurs de l'ORT.

A présent, des développeurs s'occupent de réaliser la liaison avec la société ATOS, c'est donc le début de la mise en place du service pour une utilisation en ligne.

3.1.3 Conclusion

Cette étude m'a permis d'étudier un marché en plein essor (le paiement électronique), mais surtout d'utiliser le langage HTML et le Javascript.

Dans la seconde partie du travail effectué, nous étudierons :

3.2 Amélioration de la recherche des Entreprises par leur activité

3.2.1 Le cahier des charges de la recherche des Entreprises par leur activité

Depuis 1995, le Groupe ORT a largement amélioré ses outils permettant la recherche d'information sur ses immenses bases de données. Il a également transposé toutes ses offres vers Internet. Concrètement ce changement de cap, a apporté avec lui de nouveaux environnements de développement. Voici donc une description sommaire des outils dont nous parlerons par la suite : Le but de ce chapitre est de vous amener à comprendre le travail qui était à réaliser et les outils disponibles. Nous conclurons sur une interprétation et critique des résultats.

3.2.1.1 But général

Pour comprendre le but de ce projet, il faut se pencher sur l'organisation informatique du Groupe ORT. En effet, l'énorme quantité de données de l'ORT est reçue sous forme de fichiers plats (textes, documents word, ...). Ensuite, ces fichiers sont réorganisés dans des bases de données ORACLE (données sur les entreprises), FULCRUM (données juridiques et documentaires).

Lors de la recherche d'informations sur les Entreprises, un critère fréquemment utilisé est son activité. Mais, les activités sont stockées sous forme d'un code NAF (Nomenclature d'Activités Française) normalisé par l'INSEE. Ce code permet de classer les activités professionnelles et de leur attribuer un numéro (exemple : 27.2A = Fabrication de tubes en fonte).

Or la plupart des bases de données contiennent les codes NAF (27.2A) plutôt que leur libellé (Fabrication de tubes en fonte). Ceci explique, la complexité de recherche sur un secteur d'activité. En effet, il fallait extraire au préalable, tous les numéros appartenant à ce secteur, pour ensuite lancer la recherche. Une solution avait été trouvée mais ne convenait pas ; à cause de problèmes de cohérence qui survenaient lors de recherche par mot-clé (par exemple, lors d'une requête concernant l'automobile, on pouvait récupérer des activités concernant l'agriculture).

Le but du projet était de repenser cette base de données, de lui apporter une interface graphique sous UNIX et finalement d'intégrer cette base dans les outils Internet du Groupe.

Pour comprendre voyons un exemple simple du fonctionnement attendu.

Exemple :

mot clé = 'voiture'

résultat :

Code NAF Libellé
502Z Entretien et réparation de véhicules automobiles
711Z Location de véhicules automobiles
342A Fabrication de carrosseries automobiles
743A Contrôle technique automobile
... ...

Il faut ensuite développer autour de cette base une interface graphique sous UNIX permettant grâce à la souris de parcourir l'arborescence que forment ces activités. Et pour finir, développer en collaboration avec M. Roulet une interface pour le WEB utilisable simplement, comme si l'on cherchait une URL grâce à ALTAVISTA.
Nous verrons donc dans les chapitres qui suivent le déroulement de ce stage (les grandes étapes, les faits significatifs, la démarche suivie). Mais voyons avant un schéma résumant les différentes étapes.
Plan de déroulement
Le détail de la réalisation n'est pas lisible en ligne, mais si vous désirez obtenir l'intégralité du rapport veuillez me contacter.

3.2.3 Interprétation et critique des résultats

Retraçons le travail qui a été effectué durant ces 3 mois de stage, vérifions que les réalisations remplissent le cahier des charges, et qu'il ne reste pas de solutions à apporter où de modifications à implémenter.

Malgré mes prévisions, la mise en place de la base de données a durée plus longtemps que prévu. En effet FULCRUM SearchServer est une véritable 'usine à gaz' et les documentations fournies avec le logiciel sont vraiment compliquées à comprendre. Il est rare de découvrir des exemples précis et simples permettant de saisir immédiatement l'opération à effectuer.

Après la phase d'apprentissage du fonctionnement global de l'application, il a fallu mettre en place les nouvelles fonctionnalités sur la recherche linguistique. On remarque alors que les documentations ne sont pas complètes ou que l'information importante n'est pas mise en valeur.

Suite à une étude approfondie des documentations, il a était fait appel à la société d'édition. Mais les réponses furent longues à nous parvenir, du fait de la restructuration de la société FULCRUM.

Finalement, il en résulte une recherche simple mais efficace qui permet de visualiser le résultat. L'affichage met en gras les mots qui ont permis de sélectionner l'activité. Donc pour cette partie le cahier des charges est rempli.

Voyons maintenant la partie sur l'interface graphique réalisée sous X-Windows.


L'interface graphique sous UNIX m'a familiarisé avec l'environnement de FULCRUM SearchServer. Sa réalisation m'a également permis de découvrir la librairie Xforms. Le but de cette interface était de naviguer dans la nomenclature des activités, mais j'ai également ajouté un module permettant de rechercher directement des mots, et même d'interroger d'autres bases de données FULCRUM. A l'aide de ce développement, nous sont apparues les possibilités qu'allait nous offrir Internet. Le cahier des charges est rempli, et des améliorations ont même été apportées.

Nous allons à présent conclure sur la réalisation du site WEB.


La maquette WEB est l'aboutissement de mon stage. En effet, elle répond aux exigences du cahier des charges. J'aimerai assister à sa mise en place sur les autres sites du Groupe ORT.

Aucune contrainte de temps de réponse concernant les requêtes n'a été imposée, mais il serait intéressant de le réduire. Ainsi, il serait judicieux de revoir la partie qui parse les données renvoyées par FULCRUM. Cette modification peut certainement être réalisée en intégrant du PERL.


Pour l'instant ces réalisations sont à l'état de recherche au sein du Groupe ORT, mais j'espère que mon travail pourra servir pour une mise en production et permettra un accès plus convivial à la recherche sur les données.