III. TRAVAIL EFFECTUE : MODULE D’APPELS D’OFFRES

1. LE CAHIER DES CHARGES

1.1. Contexte

Pour ses missions, SITS fait fréquemment appel à des prestataires de service. Ceux-ci sont recrutés dans des sociétés de service (SSII) par le biais d’appels d’offres. Le projet doit permettre de remplacer le processus manuel existant par un module intégré à l’intranet SITS.

1.2. Description du processus

1.2.1. Formalisation de l’appel d’offres

En amont de tout appel d’offres, le responsable dont émane le besoin en sous-traitance doit rédiger un document matérialisant l’appel d’offres. Ce document résume toutes les informations concernant l’appel d’offres : la description de la mission, le profil souhaité, etc.

Ce document a une double utilité : il permet d’une part de décrire les attentes de SITS en terme de mission, et d’autre part, il servira de support lors des différents entretiens pour sélectionner la société de prestation de service. Ce document est envoyé aux commerciaux d’une sélection de société de service. Le modus operandi de sélection des sociétés sera décrit ci-dessous.

Tous les appels d’offre ont généralement la même forme. Ils possèdent un squelette commun. Les paragraphes seront tous repris dans le contrat signé avec la société de services. Notons qu’un certain nombre d’informations sont redondantes dans l’appel d’offre. Elles permettent d’insister particulièrement sur certains aspects. Décrivons en détail chaque partie du document d’appel d’offre. Un exemple d’appel d’offres sera inclus en Annexe I : Le framework.

1.2.1.1. L’identifiant

Chaque appel d’offres doit être identifiable de manière unique. C’est pourquoi il est nécessaire de lui attribuer un identifiant. L’identifiant est laissé à l’instigation du rédacteur de l’appel d’offre. Il est cependant préférable qu’il ait la forme suivante : APPEL D’OFFRES – AO-[service/ss-service]-[année]-[thème]-[numéro] Avec :

• Service/ss-service : le nom du service (ou sous-service),
• année : l’année du début de la mission,
• thème : le type de mission (par exemple : web)
• numéro : numéro d’ordre de la mission pour le thème.

Cet identifiant doit figurer en haut de l’appel d’offre.

1.2.1.2.a. Descriptif rapide de la mission

Un rapide descriptif de la mission apparaît en caractère gras. Ce descriptif résume en une ou deux phrases le type de mission demandé par SITS ainsi que sa durée.

1.2.1.2.b. Descriptif rapide du profil

Ensuite, le profil du candidat souhaité par SITS est rapidement décrit. Plus le niveau de détail sera élevé dans cette partie, plus les compétences requises seront pointues.

Pour conclure le titre, la mention suivante pourra apparaître : Les candidats proposés devront impérativement faire partie du personnel de la société qui les présente.

1.2.1.3. Actions à mener

Ce paragraphe permet de décrire plus en détail le type de mission que le prestataire devra mener. Dans cette partie, les informations sont présentées de manière hiérarchisée. Les éléments les plus importants seront placés en premier, et les moins importants en dernier.

1.2.1.4. Profil souhaité

Il s’agit d’un complément d’informations par rapport au descriptif du profil réalisé en titre. Les éléments les plus importants sont repris dans cette partie.

1.2.1.5. Compétences requises

Les compétences sont là encore présentées dans un ordre décroissant d’importance. Les premières énoncées doivent impérativement être maîtrisées par le candidat, tandis que les dernières sont plus considérées comme des « bonus » pour le candidat. Les mots clés précédant les compétences sont dans l’ordre : « expertise … », « maîtrise de … », « bonne connaissance de… », « connaissance de … ».

Un certain nombre de connaissances de type « savoir-être » peuvent apparaître en dernière ligne de la liste. Il est possible de définir des « profils type » pour chaque mission, comme nous le montrons dans le Tableau 2 Profils type. D’autres profils seront à définir par la suite.

Tableau 2 Profils type

1.2.1.6. Environnement technique

Les différents environnements techniques devront être résumés dans cette partie. Une liste (non exhaustive) pourra être proposée à l’utilisateur.

1.2.1.7. Autres informations

Les autres informations à faire apparaître sur le document d’appel d’offre sont les dates, lieux et contacts.

Deux dates doivent être précisées : la date de réponse à l’appel d’offre ainsi que la date de début de mission.

Les personnes à contacter seront le rédacteur de l’appel d’offre et son responsable hiérarchique. Leurs noms, postes et e-mails seront à renseigner sur le document.

1.2.2. Choix des destinataires

Une fois l’appel d’offre rédigé, il faut sélectionner un certain nombre d’entreprises de service auxquelles sera envoyé l’AO. Chaque responsable de SITS possède sa propre liste de contacts au sein des sociétés de service. Néanmoins depuis près d’un an un effort a été fait pour mutualiser les carnets d’adresse des responsables. Des rapprochements ont été faits et une liste commune des sociétés prestataires de service a été dressée à SITS.

Cette liste peut être découpée en plusieurs catégories.

1.2.2.1. Les catégories

Seule la première des catégories présentées ici est commune à tout SITS, les autres ne sont là qu’à titre d’exemple et laissées à la discrétion des responsables.

1.2.2.1.a. La catégorie 1 : les 10 premières

Les 10 premières sociétés correspondent aux partenaires les plus importants de SITS, c’est à dire ceux avec qui SITS a signé le plus de contrats. La consigne a été passée d’envoyer systématiquement les appels d’offre aux entreprises de la catégorie 1. Un contrat cadre a été signé avec ces sociétés dans lequel il est précisé qu’en échange de l’envoi systématique des AO aux sociétés, des remises sur le volume seront concédées à SITS.

1.2.2.1.b. La catégorie 2 : les en-cours

Cette liste comprend la liste de toutes les sociétés qui ont actuellement au moins un contrat en cours avec SITS.

1.2.2.1.c. La catégorie 3 : les anciens

Cette liste comprend toutes les entreprises qui ont un jour effectué une mission à SITS.

1.2.2.1.d. La catégorie 4 : les autres

Cette liste comprend toutes les entreprises qui ont eu un contact avec un responsable de SITS.

1.2.2.2. Les carnets d’adresse

Les contacts des responsables sont essentiellement les commerciaux des entreprises de service. Ces listes sont aujourd’hui hétérogènes : cartes de visite, agendas personnels, listes Excel, etc. Ces listes sont alimentées quotidiennement par les nouveaux contrats, par des appels prospectifs de sociétés, etc.

1.2.3. Traitement des retours

Lorsque les SSII reçoivent les appels d’offre, généralement elles s’efforcent d’y répondre. Il est par ailleurs demandé que tous les échanges relatifs aux appels d’offre soient réalisés par mail (et non par téléphone). Les réponses doivent comprendre :

• Un ou plusieurs CV,
• les disponibilités relatives,
• les conditions commerciales,
• un bref rappel des missions (en cours ou passées) effectuées à SITS.

Actuellement, les réponses sont à moitié traitées « à la main ». C’est à dire que le responsable trie les réponses, et les envoie à l’agent Lotus Notes correspondant, qui va les ranger dans un répertoire spécifique pour un traitement manuel ultérieur.

Ensuite, le responsable va imprimer toutes les réponses et les annoter à la main avant de confronter ses conclusions avec le second responsable qui aura effectué les mêmes opérations de son côté.

• Les informations tirées par le responsable sont :
• Le tarif de la prestation,
• un classement (via une notation),
• des remarques diverses.

1.2.4. Les rendez-vous

Les meilleures réponses seront ainsi sélectionnées. Un mail (générique) est envoyé à tous ceux dont la candidature n’a pas été retenue. Le responsable prend alors rendez-vous dans les trois jours ouvrés suivant la date limite d’envoi des réponses, avec le commercial et le candidat prestataire afin de vérifier l’adéquation entre le candidat et la mission proposée. A l’issue des rendez-vous un nouveau classement est effectué, et seul le meilleur est retenu.

Après chaque rendez-vous, un petit rapport est réalisé par les responsables. Ce rapport comprend essentiellement :

• Le tarif négocié,
• la disponibilité du candidat,
• un commentaire sur l’entretien,
• une note.

Une fois le contrat signé, un mail est envoyé aux autres candidats.

1.3. Besoins fonctionnels

Les besoins fonctionnels de l’application seront :

• Gérer une liste de contacts (les commerciaux),
• permettre la création d’un appel d’offres formalisé,
• gérer l’envoi de l’appel d’offres aux contacts concernés,
• permettre le suivi de l’appel d’offres :
  • réception des offres,
  • tri et pose d’appréciations,
  • gestion des réponses après le choix.
• génération du contrat,
• archivage des processus.

1.4. Contraintes techniques

Le projet doit s’intégrer, sous forme d’un groupe de modules, à l’intranet SITS.

2. COMPTE-RENDU D’ACTIVITE

2.1. Axes d’étude et de recherche choisis

Les développements sont largement conditionnés par l’utilisation du « framework ». Cependant, la méthodologie de développement d’un projet reste très classique. L’intégralité du processus de développement met en vis à vis deux entités : la maîtrise d’œuvre d’un côté, et la maîtrise d’ouvrage de l’autre. Ces dernières doivent suivre le processus habituel de rédaction de documents que nous allons résumer dans le Tableau 3.

Tableau 3 - Étape du développement d'un site

Dans le cadre du stage, la MOE et la MOA étaient très proches, puisque la MOA, en la personne de Bruno Desplanques, était le chef de la section SIT/SI dont dépendait le développement. Néanmoins, c’est sur ce modèle que le développement du module s’est effectué.

3. SPECIFICATIONS FONCTIONNELLES

3.1. Fonctionnalités du système

3.1.1. Carnet d’adresses

Le système permettra de détenir et gérer un carnet d’adresse, doté de fonctionnalités de groupement des contacts.

3.1.2. Saisie d’un appel d’offres

Le système permettra de saisir un appel d’offres via un formulaire, puis d’y adjoindre différents groupes de contacts en provenance du carnet d’adresses de l’utilisateur.

3.1.3. Suivi des appels d’offres

Le système doit permettre d’ajouter, de façon automatique ou non, une réponse à un appel d’offres ; puis d’y attacher diverses informations, telles qu’une note, le prix proposé, divers commentaires … Ces réponses pourront ainsi être classer afin de sélectionner les meilleurs candidats et d’envoyer automatiquement un mail de refus aux contacts dont la proposition n’a pas été retenue. Les informations précédemment renseignées pourront être rappelées à cette étape pour faciliter le choix. Une fois le candidat définitif choisi, on pourra renseigner les conditions tarifaires et dates définitives pour générer le contrat.

3.1.4. Archivage

Les appels d’offres traités seront archivés afin de pouvoir êtres consultés à titre de comparaison ou de statistiques.

3.1.5. Préférences

Les utilisateurs pourront administrer les préférences de leur compte.

3.2. Contraintes de l’organisation sur le système et contraintes du système sur l’organisation

3.3. Solution technique choisie

Le système sera un module de l’intranet SITS, écrit en PHP il utilisera l’architecture du Framework SITS.

3.3.1. Le framework

La réalisation du site intranet de SITS a été faite, au même titre que tous les sites développés par l’équipe INET, à l’aide du framework SITS. En découlent des contraintes en terme d’architecture du site, de programmation des modules et de normalisation de la structure des programmes. Cependant, l’utilisation du framework comporte de nombreux avantages, comme l’homogénéisation de la conception des sites au sein de l’équipe, une base saine et optimisée pour la création de nouveaux sites, une architecture en perpétuelle évolution, et améliorée quotidiennement.

L'Annexe I détaille plus en avant les composantes et fonctionnalités du framework.

3.3.2. Le langage PHP

Le framework a été développé intégralement en PHP, et de plus, l’équipe effectue tous ses développements en PHP. L’intranet SITS ayant été, lui aussi, développé en PHP, le choix du langage de programmation s’oriente tout naturellement vers le PHP, qui de plus, est un langage souple et flexible, tout particulièrement adapté à ce type de développement.

3.3.3. Le site d’administration

La gestion du contenu éditorial est réalisée pour tous les sites réalisés par l’équipe via le site d’administration. Nous suivrons donc encore une fois les us de l’équipe.

3.4. Processus de l’application et cas d’utilisation

Figure 7 - Le processus d'appel d'offres

Lorsqu’un Appel d’Offres doit être passé, l’utilisateur va tout d’abord générer son Appel d’Offres. Lorsque celui-ci sera prêt, il pourra ajouter des contacts à qui l’envoyer à partir de son carnet d’adresses. Le système se chargera alors d’envoyer l’Appel d’Offres par e-mail.

Lorsqu’une réponse arrivera pour cet Appel d’Offres, il sera ajouté à sa liste des réponses. L’utilisateur aura alors accès aux informations qu’elle contient et pourra y attacher diverses informations, telles que le prix proposé, le nom du prestataire, la date de disponibilité … Il pourra aussi lui attribuer une note pour le classement.

Une fois toutes les réponses arrivées, ou la date limite de réponse atteinte, l’utilisateur pourra sélectionner quelques candidats à recevoir, un mail sera alors envoyé aux autres afin de leur signifier le refus de leur candidature.

Lorsque le candidat définitif aura été choisi, l’utilisateur devra renseigner les informations définitives (en terme de dates, tarifs, etc.) afin de générer le contrat, qui n’aura plus qu’à être signé.

3.5. Ecrans et états d’utilisation

Plusieurs « écrans » seront proposés aux utilisateurs autorisés, ils seront accessibles à partir de la page d’accueil de l’intranet. Il faudra être authentifié et appartenir à un groupe spécifique pour y avoir accès.

3.5.1. Carnet d’adresses

Cette page permettra d’afficher le carnet d’adresses de l’utilisateur, ainsi que d’ajouter de nouveaux contacts à celui-ci.

3.5.2. Créer un Appel d’offres

Cet écran permettra de créer un nouvel Appel d’offres. Une première partie sera consacrée au renseignement de l’Appel d’offres en lui-même, tandis que la seconde permettra de choisir à quels contacts l’envoyer. Une sélection groupe par groupe ou contact par contact sera proposée.

3.5.3. Suivre mes Appels d’offres

Cet écran proposera une liste des Appels d’offres en cours, et pour chacun, permettra de gérer les réponses.

3.5.3.1. Suivi des réponses

Pour chaque réponse, un formulaire permettra de renseigner les différentes informations : note, prix, commentaires …

3.5.3.2. Actions

Divers écrans permettront aux utilisateurs d’affecter les réponses reçues, de façon fine ou groupée : Suppression, messages, sélection.

3.5.3.3. Rapport

Pour chaque appel d’offres des statistiques seront établies, et pourront être visualisées sous forme de tableau ou de graphique.

3.5.4. Appels d’offres archivés

Cet écran reprendra la même structure que le module de suivi des Appels d’offres en cours, à la différence que les informations présentées ne seront pas éditables.

3.5.5. Préférences

A l’aide de cet écran, l’utilisateur pourra personnaliser ses préférences, telles que l’affichage des contacts dans son carnet d’adresses, ainsi que ses groupes, listes de profils et de compétences …

3.6. Profils et droits utilisateurs

Le module se basera sur les profils utilisateurs de l’intranet SITS, à savoir :

• Super-administrateur,
• administrateur de groupe,
• membre d’un groupe,
• utilisateur authentifié,
• utilisateur non authentifié.

Seuls des utilisateurs au minimum identifiés pourront avoir accès au module, et ce à condition d’être référencés comme responsables de service dans l’annuaire LDAP.

3.7. Eléments permettant l’exploitation du site

L’exploitation du site nécessite un certain nombre d’éléments.

En premier lieu, un système d’interfaçage avec la messagerie doit être mis en place, par l’intermédiaire d’un agent Notes. Ce système doit être le plus transparent possible pour l’utilisateur.

Enfin, il faut que les futurs utilisateurs aient été informés de la création du module, et que ses fonctionnalités leurs aient été expliquées. Cette communication peut se faire par un envoi de mail sur les listes de diffusion, par l’organisation de réunions ou encore par l’envoi d’un prospectus décrivant les nouvelles fonctionnalités apportées par le module.

3.8. Eléments permettant l’administration du site

Le super-administrateur de l’intranet SITS s’occupera de l’administration du module.

3.9. Eléments de sécurisation du site

Les aspects concernant la sécurité du site sont principalement gérés par le framework. Un aspect supplémentaire doit être géré par le site : la détermination du statut de « responsable » permettant l’accès ou non au module d’Appels d’Offres.

4. DEROULEMENT CONCRET DES ETUDES

4.1. Étude détaillée

4.1.1. Architecture du site

Le site web suit l’architecture standard du framework, sans additions telles que des « templates ». Chaque fonctionnalité du système (points 3.1.1 à 3.1.5 du dossier de Spécifications fonctionnelles) étant affectée à un « module 1 », le tout regroupé dans le « groupe de modules 2 » appelé « Appels d’offres ».

4.1.2. Interfaçage avec la messagerie

Plusieurs solutions ont été envisagées pour l’interfaçage de l ‘application avec la messagerie :

• La solution « Tout Notes ® »,
• la solution « forward »,
• la solution « Queue sur le disque ».

4.1.2.1. Tout Notes ®

Un agent Notes ® effectue tout le traitement :

• Reconnaissance du message entrant,
• découpage du message,
• stockage des pièces jointes sur le serveur,
• enregistrement de la réponse dans la base de données.

Cette solution à l’avantage, mais aussi l’inconvénient, d’être monolithique et contraint à utiliser une autre technologie que celle utilisée pour le reste du projet.

C’est néanmoins cette solution qui a été choisie.

4.1.2.2. Forward

Un agent Notes ® reconnaît les messages et les transmet directement à un serveur de mail différent qui s’occupera d’effectuer tous les traitements ultérieurs. Cette solution aurait eu l’avantage de ne déléguer à Notes ® que la partie reconnaissance du message, tous les autres traitements en auraient été indépendants. Elle aurait par contre mobilisé un serveur mail supplémentaire à maintenir, la cohésion des technologies n’étant pas plus forte qu’avec la solution précédente.

4.1.2.3. Queue sur le disque

Un agent Notes ® s’occupe de la première partie du traitement :

• Reconnaissance du message entrant.
• Découpage du message.

L’agent le stocke alors dans une « Queue » sur un disque. À intervalles réguliers, un programme passe en revue les fichiers déposés dans la queue et finalise le traitement :

• Stockage des pièces jointes sur le serveur.
• Enregistrement de la réponse dans la base de données.

Cette solution intermédiaire aurait permit d’utiliser un agent Notes ® simple associé à un programme utilisant les technologies habituelles (PHP et classes d’abstraction du framework) pour le traitement. Mais deux problèmes ont été révélés : la gestion d’une queue aurait posé des problèmes de noms, et la présence d’un batch aurait nécessité une maintenance particulière.

4.1.3. Modèle conceptuel de données

La Figure 8 présente le Modèle conceptuel de données de la base de donnée utilisée par le module.

Figure 8 - Modèle conceptuel de données

4.2. Réalisation

La réalisation proprement dite s’est effectuée en deux lots :

• Contacts et création d’appels d’offres,
• Gestion des réponses.

Le premier était constitué de l’outil de création d’un appel d’offres, ainsi que de la gestion des contacts (nécessaire au processus de création), ainsi que de la partie des préférences en relation avec ces modules. Ce sont les écrans 3.5.1, 3.5.2 et 3.5.5 des Spécifications fonctionnelles.

Le second était constitué de la partie gestion des réponses, c’est à dire la partie suivi des appels d’offres (écrans 3.5.3 et suivants) ainsi que des archives (écran 3.5.4), mais aussi de l’agent Notes ®.

Pour avoir une description détaillée des modules, voir l'Annexe V : Documentation utilisateur sur le module Appels d’offres.

4.2.1. Architecture du site

Chaque module, au niveau du framework, dispose de son fichier d’entrée : engine/modules/intranet-sits/AppelOffres/{nom_module}.php.

Tous sont constitués de la même façon :

• Inclusion du fichier de déclaration de la classe du module,
• Instanciation d’un objet de ce type,
• Vérification de l’autorisation par l’appel à la méthode get_responsable(),
• Si l’accès est autorisé, appel de la méthode main() pour traiter la requête,
• Récupération du texte et du titre via les méthodes get_text() et get_boxTitle().

Les classes de module sont toutes basées, à des niveaux variables, sur la classe AppelOffres, elle-même basée sur la classe d’abstraction du framework WebSite. Divers objets additionnels sont utilisés par les méthodes de ces objets. Pour plus d’informations voir l'Annexe VI : Diagramme des classes.

4.2.2. Architecture de l’agent Notes

L’agent Notes contient deux classes :

• RecordMail, qui gère la prise en compte des réponses,
• MsgBox, qui s’occupe de la communication avec l’utilisateur.

Il utilise aussi divers packages personnalisés :

• Gnu-regexp-1.1.4, qui contient les classes de gestion des expressions régulières,
• FTP, qui contient les classes de transfert FTP,
• Myjdk, qui contient une version mise à jour de certaines classes standard.

L’agent utilise le protocole FTP pour transmettre les pièces jointes des mails au serveur web. Il utilise l’utilisateur web pour se connecter au serveur linux002.

À partir du répertoire $HOME de l’utilisateur ciblé (web), le chemin vers le répertoire documents du site est un lien symbolique, appelé web. Celui-ci, situé dans le répertoire ~/travail de l’utilisateur pointe vers le répertoire /opt/appli/web/ du serveur. Le client FTP dépose alors ses fichiers dans le répertoire ~/travail/web/htdocs/documents/intranetsits/pj/.

4.3. Recette et homologation

La phase de recette a été assez longue, malgré le faible nombre de bugs rapportés dans le Mantis (voir 3. Le suivi de la relation MOE/MOA : Mantis dans l'Annexe II). En effet la proximité de la MOA a fait que la majorité des demandes d’évolution et des corrections de bugs ont été orales, d’ou une faible tracabilité des problèmes.

4.4. Chronogramme

La Figure 9 présente le planning qui a été suivi lors du stage. Comme on peut le voir, le développement en tant que tel n’a pris qu’un tiers du temps total, bien qu’il se soit poursuivi, ponctuellement et à un rythme plus faible, lors de la phase de recette. La phase de recette elle-même, qui s’est conclue par le passage et le traitement d’un appel d’offres réel, a été menée conjointement à la rédaction de la documentation et au projet d’amélioration de l’Le travail effectué : Environnement de développement. Elle a aussi permis la correction de quelque bugs de l’intranet lui-même.

5. Interprétation et critique des résultats

5.1. Module d’appels d’offres

Le module a été développé suivant le cahier des charges, et tous les points présents dans le dossier des Spécifications fonctionnelles ont été traités.

5.2. Intranet SITS

Le module s’intégrant à l’intranet SITS, celui-ci a été suivi et diverses évolutions ont été effectuées – quelques bugs ont aussi été résolus. Citons par exemple :

• une fonctionnalité de rappel des congés en attente a été ajoutée,
• la gestion des congés sur plusieurs années est dorénavant possible,
• l’envoi d’un mail de notification à l’ajout d’un article, d’une news ou d’un lien …

Pour information, une description des fonctionnalités de l’intranet est insérée en Annexe VII.

5.3. Conclusion

Le cahier des charges a été respecté, et projet a été passé en production avec succès. Bien sûr des améliorations auraient encore pu être apportées, mais il a fallu choisir d’arrêter les développements à un point donné.

La mise en production s’étant conclue par le traitement complet, et avec succès, d’un appel d’offre réel, l’application peut être considérée comme terminée. L’utilisation de l’intranet étant encore réservée au service SIT/SI ainsi qu’au groupe de recette, les autres utilisateurs finaux n’ont pas pu l’utiliser.