Rapport de stage de fin de tronc commun - Freemariosmilax.free.fr/other/rapport.pdf · Rapport de...

Rapport de stage de fin de tronc commun BOUKHOBZA Elior

RAPPORT DE STAGE

DE FIN DE TRONC COMMUNNOM: BOUKHOBZAPRENOM: EliorLOGIN: boukho_ePROMOTION: 2010

ENTREPRISE:

Nom: TANGANE Adresse: 132 Boulevard Camelinat

92240 MalakoffSite Web: http://www.tangane.com

Directeur Général: Mr BARRAUD FrançoisMr GAUTHIER Laurent

Maître de stage: Mr LIWERANT StephaneFonction: Chef de projet technique.Téléphone: Email: [email protected]

Durée du stage:

Date de début: 1er Septembre 2008Date de fin: 29 Janvier 2009

Durée effective en mois: 5 mois.

1

Sujet du stage:

Développeur Web/Bases de données en PHP/MySQL.

Le sujet de mon stage consiste à participer au développement d'une Application Internet Riche en Flex/PHP/MySQL.

http://www.tangane.com/

mailto:[email protected]


SommaireSommaire

Table des matières

Sommaire.......................................................................................................................2

Introduction...................................................................................................................5

Présentation de TANGANE...........................................................................................7Fiche de la société Tangane.............................................................................................................8Présentation de Tangane..................................................................................................................9Organisation de Tangane................................................................................................................11Secteur d'activité de Tangane.........................................................................................................13Position du stage dans les travaux de l'entreprise..........................................................................14

Travail effectué au sein de Tangane.............................................................................15 Présentation du projet:..................................................................................................................15 Objectifs du projet Lovelee...........................................................................................................17 Organisation du projet...................................................................................................................19 Compte-rendu d'activité:...............................................................................................................221)Développement de l'interface d'administration........................................................................22

A)Développement d'un site de gestion des données...............................................................22B)Développement d'une API pour les services de modération...............................................26C)Conclusion...........................................................................................................................29

2)Développement de l'application principale...............................................................................30A)Structure du projet...............................................................................................................30B)Utilisation du Framework TRIAD......................................................................................33C)Développement de modules PHP et de procédures MySQL...............................................36

Module de création et d'envoi de mails templates:..........................................................37Module d'importation d'utilisateurs du site Amoureux.com:...........................................38Module des signes astrologiques des utilisateurs............................................................39Module Utilisateur: gestion du ban par Login et par Email............................................40Module Blacklist: liste noire des utilisateurs...................................................................40Module Utilisateur: Mise en avant des utilisateurs..........................................................41Module d'Alertes: les alertes utilisateur...........................................................................41Module d'abonnement et de désabonnement...................................................................42

D)Conclusion..........................................................................................................................433)Intégration des pages Marie-Claire et Cosmopolitan...............................................................44

A)Description de la mission....................................................................................................44B)Conclusion...........................................................................................................................45

4)Mise en place d'une solution de paiement................................................................................46A)API Payment.......................................................................................................................47B)API Subscription.................................................................................................................52C)Conclusion...........................................................................................................................54

5)Autres tâches.............................................................................................................................55Filtrage par IP..................................................................................................................55

Sommaire 2


Ajout des régions et des villes de Suisse et de Belgique.................................................55Création de mails de confirmation d'abonnement et de désabonnement.........................55Stats hebdomadaires de Lovelee......................................................................................56

Conclusion...................................................................................................................58

Glossaire......................................................................................................................60

Annexes.......................................................................................................................67Documentation sur l'entreprise......................................................................................................681)Projets de Tangane....................................................................................................................68

Ubiplanet.................................................................................................................................68Ooshop....................................................................................................................................68

2)Chiffre d'affaires de l'entreprise................................................................................................68Documentation sur le matériel/logiciels........................................................................................70

A)Eclipse.................................................................................................................................70B)SVN.....................................................................................................................................72C)Firebug................................................................................................................................73D)Charles Web Proxy..............................................................................................................73E)EMS SQL Manager.............................................................................................................74

Résultats bruts................................................................................................................................761)Captures d'écran........................................................................................................................76

1 : Développement de l'interface d'administration de Lovelee...............................................762 : Développement de l'application principale de Lovelee.....................................................843 : Intégration des pages Marie-Claire et Cosmopolitan:........................................................934 : Mise en place d'une solution de paiement avec SOGENACTIF.......................................96

2)Documentations utilisateur.....................................................................................................100Documentation pour l'utilisation de l'API de modération.....................................................100Documentation pour l'utilisation de l'API Subscription........................................................106

Sommaire 3


REMERCIEMENTS

Je souhaiterais remercier Mr Barraud François, Mr Gauthier Laurent et Mr Chouteau Pierre de m'avoir accueilli au sein de Tangane et pour m'avoir permis d'enrichir mes connaissances sur le monde de l'entreprise. J'ai été particulièrement ravi d'avoir eu de très bon contacts avec eux afin que le déroulement de mon stage se fasse sans encombres et dans les meilleures conditions.

Je remercie aussi Mr Liwerant Stéphane pour m'avoir encadré tout au long de mon stage et pour avoir défini avec précision les tâches qui m'étaient confiées afin que mon travail se fasse dans les meilleures conditions. Je remercie également toute l'équipe Lovelee, Hadrien, Antoinette, Emmanuel, Marie-Joëlle et Caroline, ainsi que Mr Klein Pierre et Mr Oppici Raphaël, les clients, grâce à qui l'ambiance tout au long du projet a été très conviviale et agréable.

Et bien entendu tous les employés de Tangane en général avec qui j'ai eu de très bonnes relations qui ont favorisé mon insertion dans l'entreprise et qui m'ont permis d'effectuer mon stage « dans la joie et la bonne humeur ».

Je souhaite de garder de bons contacts avec eux en espérant travailler à nouveau avec eux un jour.

Sommaire 4


IntroductionIntroduction

Pour mon stage de mi-études, il me fallait trouver un stage dans l'informatique qui soit adapté à la fois au niveau de connaissances que j'ai pu acquérir jusque là, mais aussi qui soit adapté à mon projet professionnel afin de remplir les objectifs que j'avais posés à mon entrée à l'EPITA ou à la fin de la première année du cycle Ingénieur. Mes critères de recherche de stage étaient donc prédisposés à chercher dans le domaine du Multimédia, plus précisément dans le développement d'applications.

Au cours de cette année de ING1, j'ai pu apprendre beaucoup de choses qui ont quelque peu modifié mon projet professionnel développé à mon entrée à l'EPITA. Au départ, j'étais venu dans l'espoir de devenir développeur/programmeur de jeux vidéo, et au fil de la première année du cycle ingénieur, où j'ai pu effectuer beaucoup de projets touchant à différents domaines, j'ai pu me faire une idée et réviser mon projet professionnel afin qu'il convienne mieux à mon choix de carrière. Cependant, n'étant pas encore sûr de mes choix, étant donné que je ne suis encore qu'en fin de première année, et n'ayant encore aucune expérience dans le monde de l'entreprise, je n'étais pas encore tout à fait sûr de mon choix. Néanmoins, j'étais animé par l'idée de poursuivre dans la spécialisation « Multimédia et Technologies de l'Information », c'est pourquoi ma recherche de stage s'est tournée vers ce domaine-là.

Avant cette première année, je n'envisageais absolument pas de faire du Web un jour. J'étais absolument convaincu de vouloir faire dans le développement de logiciels ou de jeux vidéo. Ce choix de carrière est toujours présent, cependant n'ayant pas beaucoup d'expérience sur le sujet, il me fallait découvrir d'autres domaines afin d'obtenir un point de vue plus vaste sur la question.

D'autre part, le domaine du Web avait bien évolué au cours de ces dernières années. Les pages ne sont plus aussi statiques qu'auparavant, à présent de plus en plus de sites web interagissent avec l'utilisateur, que ce soit à travers des blogs, des forums, des wikis ou tout récemment par l'apparition d'applications Web, le Web est devenu plus que dynamique. Cette « révolution » du Web, que certains appellent « Web 2.0 », permet alors à de plus en plus de technologies d'apparaitre, se basant sur des technologies déjà existantes comme le Flash, faisant du Web un domaine à part entière.

C'est pourquoi, au vu des différents projets Web que l'on peut voir comme le panel d'applications Google ou encore les applications totalement dynamiques, mon point de vue sur le Web avait complètement changé et je voulais faire mon stage dans une entreprise qui travaille dans ce domaine afin d'acquérir plus de connaissances et de décider si c'était un bon choix de carrière.

J'ai été contacté par plusieurs entreprises travaillant dans le Web qui recherchaient quelqu'un pouvant les aider dans différents projets Web. Cependant, lorsque la société Tangane m'a contacté, elle m'avait parlé de quelque chose dont je n'avais pas du tout connaissance auparavant, c'est à dire le développement d'applications Internet, ou RIA pour « Rich Internet Applications ». Cette société étant spécialisée dans les RIA, et je me suis dit que cela pourrait être une grande valeur ajoutée à mes connaissances que de faire un stage dans ce domaine afin de

Introduction 5


comprendre comment se déroule le développement de ce genre d'applications. De plus, sachant que dans mon projet professionnel initial je voulais faire du développement d'applications, faire des applications Web rejoignait complètement mon projet initial, ce qui m'a poussé à répondre à leur offre.

Les technologies utilisées pour le développement de RIA concernent l'utilisation de Adobe Flex, une nouvelle technologie d'Adobe pour compléter le Flash qui n'était plus du tout adapté au développement d'applications Web; La plateforme de Microsoft .NET, notamment SilverLight qui est leur technologie pour rivaliser avec celle d'Adobe; mais aussi du Java, du PHP pour tout ce qui est coté serveur, ainsi que des bases de données MySQL, SQL Server...

Bien que j'aie déjà eu l'occasion de faire du Java, du PHP et du .NET, le Flex m'était totalement inconnu - bien que j'aie déjà vu des démos de ING3 sur certains projets faits en Flex -, c'est pourquoi la curiosité m'a amené à faire mon stage dans ce domaine afin d'en connaître un peu plus sur cette technologie. Mon expérience en Java, PHP et MySQL était un plus pour pouvoir de mon côté aider l'entreprise dans le développement de leurs projets.

Pour résumer, mes objectifs avant d'entrer à Tangane, étaient de pouvoir en apprendre un peu plus sur le développement de RIA, obtenir une expérience en tant que développeur Web dans une entreprise (et non dans des projets scolaires), mais aussi découvrir en général le monde de l'entreprise, la gestion de projets, les contraintes auxquelles les employés sont confrontés, etc... Tout ce genre de choses que l'on ne peut découvrir justement que sur le terrain, et aussi pour pouvoir appliquer concrètement tout ce que j'ai appris au cours de l'année. De plus, cette technologie m'étant totalement inconnue, cela me permettra d'apprendre quelque chose de nouveau afin d'élargir mon domaine de compétences en vue du prochain stage ou de l'emploi que j'obtiendrai en fin de scolarité.

Pour l'entreprise, mon objectif consistait à apporter un point de vue différent aux projets auxquels je serai confrontés obtenu au travers de mon expérience professionnelle et de mon expérience obtenue en école, et de proposer une solution correcte et satisfaisante afin d'aider l'équipe de développement à rendre le projet dans les temps et en bonne et due forme. Leur objectif était de me former le plus rapidement possible afin que je puisse apporter mon aide au développement des projets auxquels je serai affecté.

Ce rapport aura pour but donc de préciser ma fonction tout au long de mon stage sur les différents projets auxquels j'ai été assigné, puis d'apporter un point de vue détaillé sur mon apport par rapport à l'entreprise, et sur ce que l'entreprise m'a apporté. Je vais dans un premier temps détailler les taches qui m'ont été affectés, expliquer ce qui m'était demandé et ce que j'ai produit, puis faire une analyse des résultats afin de déterminer ce que l'entreprise a tiré de mes travaux et ce que j'ai moi-même tiré de ces travaux. Enfin je terminerai par une conclusion qui résumera tout ce que j'ai pu tirer de cette expérience et sur ce que je n'aurai pas pu obtenir au cours de mon stage.

Introduction 6


Présentation de TANGANEPrésentation de TANGANE

Présentation de TANGANE 7


Fiche de la société Tangane

Statut juridique: SASCapital social: 82 250,00 EurosNationalité: FrançaiseSIRET: 487 923 161 00011 Principaux dirigeants:– Mr BARRAUD François, PDG de Tangane et cofondateur.– Mr GAUTHIER Laurent, Directeur Général de Tangane et cofondateur.– Mr CHOUTEAU Pierre, Directeur Technique et cofondateur.

Date de création: 11 Janvier 2006

Adresses des sites: – Siège Social:

20 rue Louis Guérin 69100 Villeurbanne

– Tangane Paris:132 Boulevard Camelinat, 92240 Malakoff

– Tangane Lyon:22 Rue Seguin, 69002 Lyon

Taille de l'entreprise: 10 à 20 employés.Activité: Programmation Informatique

Téléphone: 0149859706Site Web: http://www.tangane.com

Fiche de la société Tangane 8

http://www.tangane.com/


Présentation de Tangane

Tangane a été formée en Janvier 2006 par M. François Barraud et M. Laurent Gauthier, animés par la conviction de faire des applications internet riches (RIA) les applications internet de demain au service du business. Étant à l'origine des premières applications de e-commerce en France, les fondateurs de Tangane ont développé depuis sa création une véritable expertise dans l'utilisation des RIA au service du business et proposent leurs services aux entreprises qui désirent booster leur compétitivité face à la concurrence.

M. Barraud a dirigé la division Services de Microsoft France durant 3 ans, et a dirigé pendant 4 ans le site Ooshop.com (cf Annexe Ooshop), le site Internet de vente alimentaire du groupe Carrefour. M. Gauthier était le directeur technique de Business Interactif, et le cofondateur de la SSII F.R.A, à l'origine de grands projets dont celui de Carrefour Ooshop, mais aussi de Sodexho, Société Générale...

M. Chouteau était quant à lui en charge du développement des projets e-commerce de Carrefour au sein de Business Interactif, dont Ooshop.

Ensemble, ils se rendirent compte que les RIA pouvaient être alignées sur le business, notamment grâce à la mise en œuvre d'architectures orientées services (SOA) à base de services web, qui permettent une grande simplicité d'intégration dans le SI existant sans réécriture des couches métiers, et de l'approche business qu'elles pouvaient apporter aux entreprises.

La société vit alors le jour en 2006, regroupant différents profils: experts .NET, développeurs d'applications RIA, développeurs Web et bases de données, conseillers technologiques, infographistes... tous animés par les mêmes convictions.

La société a d'abord démarré à Malakoff, en banlieue parisienne, en tant qu'éditeur en développant ses propres projets comme par exemple le site Ubiplanet, site communautaire tout en Flash. Cependant, le projet vit le jour au moment où Facebook commençait à prendre de l'ampleur et à s'imposer comme référence en la matière. Bien que très complet, il ne réussit cependant pas à s'imposer face à Facebook et Tangane dut arrêter ce projet afin de se concentrer sur un autre axe, les prestations de services. Elle décida alors de devenir une devenir une SSII orientée RIA

Elle bénéficia du soutien de plusieurs grands groupes, dont Adobe, fondateur de la technologie Flash/Flex, Microsoft ou encore AIR. Sa popularité grandissante, elle a participé à de nombreuses conférences RIA afin de prouver la valeur des RIA dans les technologies web de demain et réussit à se faire un nom dans le milieu.

Elle a en outre eu l'occasion de travailler pour plusieurs gros clients qui lui ont fait confiance, comme par exemple France Telecom, Mediatis, Exane, Gallimard...

La société est restée 1 an à Malakoff, avant de déménager vers Paris, agrandissant ainsi leurs locaux, avant de revenir à nouveau vers Malakoff en Avril 2008. La société a ouvert ensuite un site sur Lyon en Juin 2008, ce qui lui permit de couvrir plus de territoire et d'avoir de plus en plus de clients et d'employés. M. Gauthier est en charge du site lyonnais.

Présentation de Tangane 9


Aujourd'hui, la société continue dans son approche services, en agissant pour des grands groupes tels que France Telecom, Mediatis ou Cléopâtre Productions, qui ont fait appel à Tangane pour développer leur apport business. Elle comporte une vingtaine de salariés de différents profils, dispersés sur Paris et Lyon, ou travaillant dans les locaux des clients.

Vous pouvez apercevoir l'évolution du chiffres d'affaires de Tangane dans l'annexe I.2.1

Présentation de Tangane 10


Organisation de Tangane

Organisation de Tangane 11


Comme on peut le constater, l'organisation de Tangane est assez commune aux entreprises du type. L'entreprise est dirigée par deux cadres dirigeants qui sont le Président Directeur Général représenté par François Barraud et le Directeur Général représenté par Laurent Gauthier. Laurent Gauthier est aussi en charge des RH de l'entreprise.

Le directeur technique, Pierre Chouteau, est en charge de la relation entre l'équipe technique, représentée par les chefs de projets techniques et les consultants, et les cadres dirigeants. C'est lui qui s'occupe d'accepter ou non les appels d'offre et qui distribue les projets aux équipes techniques.

Parallèlement, il y'a aussi des directeurs de projets qui sont en charge de l'équipe technique du projet qu'ils dirigent, et qui communiquent avec les clients à la place de Pierre.

Ensuite, dans la couche inférieure de la hiérarchie, on a d'une part les chefs de projets techniques, qui dirigent une équipe composée de développeurs, d'intégrateurs, et un directeur artistique qui s'occupe du design du site. Ils qui sont en charge d'établir les relations avec les clients pour relater de l'avancement des projets et des tâches à distribuer aux équipes. Ils sont aussi en charge des relations avec les prestataires de services. D'autre part on a les consultants, en charge de fournir du conseil aux directeurs de projet pour assurer la rentabilité des fonctionnalités pour chacun des projets.

Enfin on a toute l'équipe technique, donc les développeurs, les designers et les intégrateurs qui s'occupent de respecter les étapes du cycle de vie du projet auxquels ils sont affectés et qui s'entretiennent avec leur chef de projet pour présenter leur avancement au client. Cette équipe est composée de profils différents (développeurs Web, développeurs base de donnée, testeurs, stagiaires...)

On distingue donc trois niveaux de hiérarchie: La direction, représentée par François Barraud, Laurent Gauthier et Pierre Chouteau ainsi que par les directeurs de projet; la coordination, représentée par les chefs de projet et les consultants; et le centre opérationnel, qui comporte les équipes techniques et les designers.

Organisation de Tangane 12


Secteur d'activité de Tangane

Comme indiqué en Introduction et dans la présentation de l'entreprise, Tangane est depuis plus d'un an une société de services (SSII) spécialisée dans le développement d'applications web, particulièrement dans la création d'applications riches (RIA) au service du business.

Les solutions proposées sont donc orientées business, les entreprises font appel à elle pour :

• Du conseil pour augmenter leur rentabilité et se démarquer de la concurrence à travers la mise en place d'applications riches (recommandations sur les meilleures pratiques, conseils de choix technologiques (Flex, SilverLight), conseils d'architecture technique par rapport à leur SI existant, etc...).

• Le développement d'applications riches pour le business, comme par exemple le développement d'applications e-commerce (MixCommerce, Store Factory, Lovelee...)

• La refonte de leur système d'information s'intégrant avec le SI existant (Mediatis, Gallimard...)

• La formation d'équipes de développement et d'infographistes sur les technologies RIA.

Secteur d'activité de Tangane 13


Position du stage dans les travaux de l'entreprise

L'entreprise, depuis sa création, a pour habitude d'embaucher des stagiaires pour aider les équipes de développement sur les différents projets affectés. En effet, le personnel étant assez réduit (10 à 20 personnes embauchées en CDI) et les projets étant nombreux, toute aide est bonne à prendre, et un stagiaire, même si il n'a pas toute l'expérience qu'aurait un employé, est généralement motivé pour apprendre vite et par conséquent apporter une aide supplémentaire aux équipes.

Ce procédé permet à l'entreprise de juger plus distinctement la qualité de travail des personnes qu'à travers un CV et un entretien. Ainsi, la plupart du temps les stagiaires sont embauchés à la fin de leur stage (dans le cas des stages de fin d'étude), ce qui est profitable pour l'entreprise tout comme pour le stagiaire.

Pour le projet Lovelee par exemple, il y'a eu en tout 4 stagiaires embauchés à des périodes différentes du projet, qui n'étaient pas des stages de fin d'étude, et ces stagiaires ont tous gardé un contact avec Tangane à l'issue de leur stage pour proposer leur aide à l'entreprise (télétravail, travail à temps partiel, etc...). Mon stage fait justement partie de ces stages, et j'espère qu'à terme je continuerai à garder contact avec Tangane pour proposer mon aide à leurs futurs projets.

Position du stage dans les travaux de l'entreprise 14


Travail effectué au sein de TanganeTravail effectué au sein de Tangane

Le projet Lovelee

Présentation du projet:

Le site Lovelee.com (www.lovelee.com) est un site de rencontres utilisant les interfaces riches pour concurrencer ses rivaux en matière d'ergonomie et de facilité d'utilisation afin de permettre aux utilisateurs de faire des rencontres dans un environnement agréable.

Présentation du projet: 15

Figure 1: Ancienne version de Lovelee

http://www.lovelee.com/


Le site, présent depuis 2005, a d'abord été développé en utilisant la technologie ColdFusion d'Adobe pour améliorer le confort des utilisateurs grâce aux animations et au dynamisme des pages. Cependant, le site n'a pas reçu le succès escompté et dut arrêter le développement pendant quelques temps, jusqu'au jour où le fondateur du site, Mr Klein Pierre, décida de développer une nouvelle version du site, utilisant les nouvelles technologies pour attirer plus de monde.

Il a donc cherché des fonds d'investissements auprès de différents actionnaires dont Marie-Claire pour vendre une amélioration de Lovelee qui incorpore de nouvelles fonctionnalités, pour le rendre plus pratique et plus attirant pour les utilisateurs. Il vendit le projet au groupe Marie-Claire et c'est Tangane qui s'est vu confier le développement de Lovelee en Juin 2008, pour en faire une application riche en Flex.

Le projet a été démarré en Mai 2008, et une équipe a été formée pour le développement et la mise en ligne de cette nouvelle version de Lovelee. J'ai moi-même participé activement au développement du site et à la mise en place de nombreuses fonctionnalités.

Présentation du projet: 16


Objectifs du projet Lovelee

Le site Lovelee.com est un site de rencontres nouvelle génération fait en Flex. Comme tout bon site de rencontres, il doit proposer aux utilisateurs un certain nombre de services pour leur permettre de faire des rencontres dans un environnement agréable tout en garantissant leur droit à leur vie privée. On compte parmi ces services:

– Des fonctions de recherche selon plusieurs critères (age, ville, goûts...)– Des diaporamas de profils d'utilisateurs correspondant à un profil recherché.– La possibilité de personnaliser son profil et de renseigner un certain nombre d'informations

aidant à la mise en relation des utilisateurs.– Un système de comparaison d'affinités pour découvrir les utilisateurs qui leur correspondent

le mieux.– L'envoi et l'archivage de messages privés.– Un système de « liste d'amis » pour faciliter la communication entre utilisateurs.– Un système de « blocage » des utilisateurs « nocifs ».– Des alertes en temps réel pour prévenir lorsque quelqu'un visite leur fiche ou leur envoie un

message privé.– La possibilité d'ajouter des photos qui seront validées par des modérateurs pour éviter les

abus.– Un système de Newsletter qui leur permet de rester au courant des nouveautés du site et des

nouveaux utilisateurs susceptibles de les intéresser.

À cela s'ajoute une panoplie de fonctionnalités uniques à Lovelee, comme par exemple:– Une recherche selon les résultats de sondages sur les habitudes de la vie courante, le

« philtre d'amour » afin de mettre en relation les utilisateurs partageant les mêmes hobbies.– La possibilité de sauvegarder des recherches pour que les utilisateurs n'aient pas à remplir

systématiquement tous les champs de recherche.– La possibilité de « flasher » quelqu'un, c'est à dire déclencher une alerte pour le prévenir en

temps réel qu'un utilisateur a apprécié son profil.– Une messagerie instantanée facilitant le dialogue en temps réel.– Des applications de mise en relation entre utilisateurs.– Une interface dynamique qui ne se charge qu'au démarrage, assurant aux utilisateurs un

confort d'utilisation.

L'objectif du projet est donc d'implémenter toutes ces fonctionnalités à travers une RIA tout en assurant un service rapide et complet, ceci afin d'attirer le plus d'utilisateurs et hisser le site au même rang que ses concurrents comme Meetic ou Parship.

Le site est un site payant pour les hommes mais gratuit pour les femmes, au même titre que Meetic, afin d'attirer le plus de femmes possible à s'inscrire et par la suite, de pousser des hommes qui recherchent des femmes à souscrire à un abonnement pour rencontrer des femmes à travers le site. C'est un argument de vente que la plupart des sites de rencontre payants utilisent pour attirer leur clientèle.

Objectifs du projet Lovelee 17


La première version du site était prévue pour Octobre 2008, et devait comporter la majeure partie des fonctionnalités attendues afin d'assurer la transition de l'ancien Lovelee vers le nouveau sans encombre pour les utilisateurs.

Pour la suite du projet, les nouvelles version de l'application étaient livrées à des intervalles plus courts, toutes les une ou deux semaines environ, qui apportait de nouvelles fonctionnalités, en supprimait d'autres jugées peu utiles, qui corrigeait certains bugs remarqués sur les précédentes versions, etc...

Dans les versions qui ont suivi, un service technique a aussi été mis en place pour répondre aux questions des utilisateurs et pour corriger certains bugs détectés par les utilisateurs.

Objectifs du projet Lovelee 18


Organisation du projet

L'équipe du projet Lovelee est composée de différents profils qui se complètent:

– Le chef de projet technique, Mr. Stéphane Liwerant, s'occupe des relations avec le client et les prestataires de service. C'est lui qui distribue les tâches à effectuer aux développeurs et aux designers. Il supervise chacune des différentes phases du projet jusqu'à la mise en production et la validation par le client.

– Deux développeurs RIA, en charge de la partie Flex du projet. – Deux développeurs Web/Base de données, qui sont en charge de la partie HTML/PHP du

projet, et des interactions avec la base de données. – Un designer, qui conçoit le design de chacune des parties du projet qui seront intégrées par

la suite par les développeurs.– Ainsi que les stagiaires, de développement Flex, PHP ou MySQL, qui aident l'équipe à

implémenter les différentes parties du projet.

Le projet suit un cycle de développement assez commun à ce genre de projets:

– Tout d'abord, une réunion réunit les différents acteurs du projet, dans laquelle le chef de projet fait un point sur tout ce qui a été produit, ce qu'il reste à faire et ce qui n'est pas réalisable, et avec le client ils décident de ce qui doit être mis en place pour la prochaine version. A l'issue de cette réunion, le chef de projet distribue le compte-rendu de la réunion à l'équipe du projet, en leur affectant à chacun un certain nombre de tâches qu'ils auront à effectuer pour la prochaine version.

– Débute alors la phase de développement, et chacun à un certain nombre de tâches bien précis à remplir pour la prochaine livraison du produit.

– Une fois leur travail terminé et testé, ils le donnent à valider au chef de projet qui s'assure qu'il valide bien les spécifications du client. Si il estime qu'il manque des éléments ou que certaines choses doivent être enlevées, il leur en fait part pour qu'ils puissent corriger leur version locale.

– Lorsque tous les membres ont effectué leurs tâches, une phase de test débute où tous les membres testent le produit pour éventuellement détecter et corriger les bugs avant la mise en production de la version.

– Enfin, la version est mise en production, suivie d'une nouvelle phase de test s'assurant que tout fonctionne bien sur la base de données en production et que la nouvelle version n'altère pas les fonctionnalités existant dans les versions précédentes. C'est généralement à ce moment que l'on peut détecter les problèmes de charge qu'on ne peut pas visualiser en développement.

– Enfin, le client teste à son tour la version produite et valide le travail de l'équipe en exprimant éventuellement les améliorations pouvant être apportées en vue de la prochaine version.

Organisation du projet 19


Le projet suit une méthode de développement Agile, c'est à dire privilégiant la communication et la collaboration plutôt qu'un travail individuel et borné par les demandes initiales du client.

– Le client travaille dans les locaux, ce qui lui permet de réagir en temps réel avec l'équipe. Il peut alors négocier directement avec l'équipe sur certains points qui n'ont pas été exprimés lors de la réunion, comme la mise en place de nouvelles fonctionnalités ou le retrait d'autres jugées peu utiles ou trop coûteuses... De même l'équipe peut discuter avec le client sur l'abandon de certains objectifs exprimés lors de la réunion qui se sont avérés trop coûteux ou difficiles à mettre en place de par la structure du projet.

– La structure du projet est flexible afin de permettre l'ajout et le retrait de certaines fonctionnalités avec facilité.

– La communication entre membres est privilégiée au travail seul. Pour cela plusieurs outils de communication sont mis en place: pour la communication, des clients de messagerie instantanée sont utilisés, comme Skype, pour permettre un dialogue rapide entre les membres de l'équipe; et pour le code, un outil de contrôle de version, SVN, permet aux membres de l'équipe de partager leur travail afin que les autres membres puissent comprendre ce qui a été fait, ce qu'il reste à faire, et éventuellement de notifier les améliorations de code qui peuvent être faites, de pointer des bugs ayant échappé au développeur, etc...

– La documentation du code est privilégiée à une documentation complète: Cela permet une compréhension du travail par chacun des membres et donc d'avoir une bonne communication au sein de l'équipe.

En ce qui concerne l'environnement de développement, l'équipe utilise celui créé pour le développement de RIA. Les employés travaillent sous Windows, sont équipés de plusieurs navigateurs Web pour tester le produit (Mozilla Firefox, Internet Explorer, Opera...), et utilisent plusieurs IDE comme Eclipse ou Notepad++ pour l'écriture du code.

Pour le développement PHP, les machines ont le serveur Apache d'installé, configuré avec la plupart des extensions PHP utiles pour le développement Web. Le développement base de données se fait à partir d'un logiciel très utile, EMS SQL Manager, qui permet la visualisation des tables, la coloration syntaxique du code SQL et autres fonctionnalités utiles au développement SQL.Pour le développement Flex, les machines possèdent l'outil Flex Builder, qui est un compilateur Flex pour la création d'applications, et bien entendu le Flash Player pour visualiser les fichiers SWF (binaires Flex compilés). D'autre part, elles possèdent aussi un outil très utile pour le debug, Charles Web Proxy, permettant d'identifier toutes les requêtes qui passent entre le Flex et le PHP, mais aussi le contenu des requêtes HTTP, etc... Des captures d'écran de chacun de ces outils sont disponibles en annexe II: Documentation sur le matériel/logiciels.

Enfin, l'entreprise utilise un framework conçu pour le développement de RIA, le framework Triad. C'est un framework développé par Tangane qui utilise l'architecture « 3 Tiers » pour le développement de RIA. Il fournit un panel de fonctions et de classes pour aider au développement des RIA pour plusieurs langages: Flex, PHP, Java, et .Net.



L'architecture Trois Tiers :Comme son nom l'indique, c'est une architecture basée sur trois niveaux:

– La couche présentation, qui correspond à la partie visuelle et interactive du projet. Elle présente les données qu'elle reçoit et envoie des requêtes à la couche métier. On parle aussi d'interface homme-machine (IHM). Sur ce projet, elle correspond à la partie Flex/HTML.

– La couche métier (ou business), qui s'occupe du traitement des données côté serveur. C'est la partie fonctionnelle du projet, elle reçoit les requêtes de la couche présentation et communique avec la base de données pour lui renvoyer les résultats. On dit qu'elle offre des services applicatifs et métiers à la couche présentation. Sur ce projet, elle correspond à la partie PHP, en utilisant la programmation orientée objet pour découper les services sous forme de modules en collaboration à la fois avec les modules Flex mais aussi avec les tables de la base de données.

– La couche données, qui gère l'ensemble des données du système. Elle fournit les données à la couche métier de manière uniforme (on parle de couplage faible). Elle peut être représentée par une base de données SQL, mais aussi par des fichiers XML, par un envoi de mails, etc... Sur ce projet, elle est représentée par une base de données MySQL.

Figure 2: Schéma d'une architecture 3 Tiers

Le framework Triad permet de guider le développement des RIA en suivant cette architecture et en utilisant le modèle MVC (Modèle Vue Contrôleur). Une description plus détaillée du framework se trouve plus loin, dans le chapitre « Utilisation du Framework TRIAD »



Compte-rendu d'activité:

1) Développement de l'interface d'administration

A) Développement d'un site de gestion des données.

Le développement de Lovelee se distingue en deux sous-parties indépendantes l'une de l'autre, qu'on appelle « back-office » et « front-office ».

Le front-office concerne tout ce qui fait partie de la partie principale de l'application, celle que les visiteurs et les membres verront et utiliseront. C'est ici que l'on retrouvera la partie Flex du site et les pages HTML/PHP. C'est la plus grosse partie du site.

Le back-office concerne la partie administration de l'application, ce dont les visiteurs n'auront donc pas accès, et qui permettra d'effectuer certains traitements en rapport avec le site, comme par exemple la modération des utilisateurs et des photos ou encore la création et la suppression d'éléments du site comme les sondages.

Ces deux parties sont indépendantes l'une de l'autre: le développement de la partie back-office ne doit pas dépendre de la partie front-office et vice-versa. Cela permet d'externaliser la partie d'administration du site afin de permettre à des utilisateurs externes au site principal d'administrer le site sans avoir besoin d'en faire partie.

Dans un premier temps donc, ma mission consistait à développer une interface d'administration en PHP/HTML afin que les modérateurs du site puissent facilement administrer les données du site principal sans toucher à la base de données et sans avoir besoin de connaître le fonctionnement du site principal.

L'interface se devait d'être simple d'utilisation, afin que quiconque puisse modérer le site sans aucune connaissance préalable; et sécurisé, afin que seules certaines personnes, dans le cas présent les modérateurs Lovelee, puissent accéder aux données du site principal et les modifier.

Voici une capture d'écran illustrant cette interface :

Développement de l'interface d'administration 22


Question sécurité d'abord, un triple système d'authentification est utilisé:

- Premièrement, l'administrateur doit entrer ses identifiants de connexion, en l'occurrence un nom d'utilisateur et un mot de passe. Il peut si son navigateur le permet enregistrer un Cookie gardant ses identifiants en mémoire afin qu'il n'aie pas à les renseigner lors de la prochaine session. Bien entendu le mot de passe n'est pas enregistré dans ce cookie, mais un identifiant de session unique généré par une fonction de hachage (MD5), qui est difficilement déchiffrable. Cet identifiant est aussi enregistré dans la base de données et permettra de vérifier si cet utilisateur s'est déjà authentifié dans une précédente session.

- Deuxièmement, une vérification par IP. Le service de modération nous a fourni une plage d'IP de leurs machines afin que l'on puisse restreindre l'accès à l'interface à seulement ces machines. Bien entendu cela implique que les modérateurs peuvent utiliser l'interface de modération uniquement à partir de leurs postes.

- Enfin, dernièrement, une authentification interne à chacun des services: pour chaque utilisation de service (validation des annonces, validation des médias...) de l'interface, une vérification est effectuée sur la validité de l'identifiant de session de l'administrateur. L'identifiant de session généré lors de l'authentification a une durée de vie limitée, qui est actuellement limitée à 5 minutes. Ce qui signifie que si l'utilisateur n'a effectué aucune action sur le site au bout de 5 minutes, l'identifiant de session devient invalide et l'utilisateur est automatiquement déconnecté. Il devra alors se réauthentifier pour utiliser à nouveau l'interface. Cela permet de gérer le cas où un modérateur oublie de se déconnecter, pour éviter que quelqu'un d'autre ayant accès à sa machine puisse utiliser l'interface.


Figure 3: Page d'authentification de l'interface de gestion


Bien entendu, d'autres systèmes plus sécurisés pouvaient être mis en place, comme l'utilisation de certificats avec des clés privées ou le cryptage SSL, mais l'interface devait être déployée rapidement pour pouvoir être utilisée par les modérateurs, c'est pourquoi ce système, à défaut d'être optimal, était suffisant pour garantir la sécurité des données.

Deuxièmement, la simplicité d'utilisation. L'interface se décline en plusieurs rubriques, chacune réservée à une catégorie de données à modérer:

- Les utilisateurs: Les modérateurs ont accès aux informations des inscrits sur Lovelee: pseudonyme, mot de passe, email, date de naissance, genre recherché, niveau d'utilisateur et les droits d'accès (cf Annexe III.1.1.1). Ils peuvent aussi voir leurs annonces et leurs photos à partir de leur fiche, et valider ou non ces données. Cela leur permet d'avoir accès à ces informations sans avoir besoin d'aller sur le site principal.

- Les annonces: Les modérateurs voient toutes les annonces publiées par les utilisateurs afin de les valider ou de les refuser si elles ne respectent pas les règles du site (cf Annexe III.1.1.2).

- Les médias: Même chose que pour les annonces, les modérateurs peuvent visualiser tous les médias envoyés sur le serveur par les utilisateurs pour décider de valider ou non ces médias (cf Annexe III.1.1.3). Par média, on entend principalement des photos. Dans une future version du site, d'autres types de média pourraient être ajoutés, comme par exemple des vidéos ou des musiques. Actuellement, ce n'est pas le cas, les utilisateurs ne peuvent envoyer que des photos.

- Les alertes: Les modérateurs ont accès aux nouvelles alertes émises par les utilisateurs pour signaler un mauvais comportement de certains utilisateurs. Un message est émis par le plaignant expliquant la raison de sa plainte, et le modérateur peut alors décider de punir ou non le coupable à partir de sa fiche. (cf Annexe III.1.1.5)

- Les sondages: Les modérateurs peuvent gérer les sondages qui apparaitront sur le site. Ils ont accès à la liste des sondages déjà créés et peuvent changer la date d'apparition d'un sondage. Ils peuvent aussi créer de nouveaux sondage et choisir leur date d'apparition sur le site. Bien entendu deux sondages ne peuvent pas se chevaucher et un sondage doit avoir un certain nombre de champs préremplis avant d'être créé. Tout ceci est géré par cette interface qui se veut simple d'utilisation (cf Annexe III.1.1.6)

- Les scammeuses: Les modérateurs peuvent visualiser la liste des personnes répertoriées comme « scammeuses » sur le site. Une « scammeuse » (nom spécialement féminin) est désignée comme une personne faisant du démarchage auprès des utilisateurs pour obtenir des informations personnelles, leur soutirer de l'argent ou tout autre manipulation frauduleuse. Pour contrer cela, des mesures ont été prises sur le site afin de détecter les personnes pouvant être des scammeuses potentielles. Par exemple, les personnes envoyant des messages privés contenant leur adresse mail peuvent être des scammeuses potentielles. A partir de là, les modérateurs peuvent via l'interface de modération accéder à la liste des dernières scammeuses potentielles répertoriées, et décider ou non de les laisser continuer à utiliser l'application. Les modérateurs ont aussi accès à un historique complet et disposent d'une fonction de recherche (cf Annexe III.1.1.7).



Pour chacune de ces catégories, une liste est affichée avec des boutons qui représentent chacune des actions possibles pour un élément (ex: Valider une annonce, Bannir un utilisateur, ...), ce qui fait que le modérateur a juste à cliquer sur un bouton pour modérer les données. La liste est bien entendu paginée, ce qui évite d'avoir à charger toutes les données sur la même page (surtout lorsqu'il y'a plus de 2000 résultats).

Voilà principalement les fonctions que propose cette interface pour simplifier la modération des données du site. D'autres fonctionnalités plus basiques sont aussi contenues dans l'interface pour simplifier encore plus la navigation, comme la recherche d'utilisateurs, la visualisation des annonces et média non validés directement dans la fiche des utilisateurs, un calendrier en Javascript pour le choix des dates, et d'autres sur lesquelles il n'est pas nécessaire de s'étendre davantage.



B) Développement d'une API pour les services de modération

L'interface de modération des données présentée précédemment est une interface de gestion manuelle, c'est à dire que les modérateurs doivent se connecter et modérer manuellement les données. Mais il fallait aussi automatiser tout cela et proposer la modération des données sous forme de services afin de permettre à des modérateurs externes ayant leur propre interface de modérer les données en faisant appel à des méthodes hébergées sur notre serveur.

Pour cela, une autre mission consistait à développer une API (Application Programming Interface, ou Interface de Programmation d'applications) proposant les services de modération de données. Le service de modération externe n'aura juste qu'à appeler les pages web en spécifiant via les paramètres HTTP le service qu'il désire appeler.

L'API est divisée en deux pages, communément aux besoins des équipes de modération. Une première page a pour fonction de récupérer un certain type de données, comme par exemple les utilisateurs, et une autre page permet de modifier les données. Tout ceci se fait à travers des requêtes HTTP par passage de paramètres GET ou POST indiquant les données à récupérer ou à modifier. Cela signifie qu'à partir de leur interface, simplement en remplissant des formulaires qui vont appeler les pages de l'API avec les paramètres nécessaires, ils pourront accéder et modifier les données du site principal sans se soucier des traitements réalisés par l'API.

La première partie concerne donc la récupération de données. Pour faciliter la lecture des données par tous les utilisateurs de l'API, les données sont fournies sous forme d'un flux XML. En effet, le XML est reconnu pour être facilement interprétable grâce à son principe de structuration des données en balises. La lecture de flux XML est donc énormément simplifiée à partir du moment où l'on connait le schéma du document, c'est à dire la structure du document. Ici, le schéma des flux XML était donné par le client, ce qui rendait le développement de cette fonction de l'API très simple.

Pour utiliser cette fonction, les modérateurs appellent la page web de l'API en lui passant en paramètres GET le type de données qu'ils souhaitent recevoir ainsi que l'intervalle de dates des données, le tout sous un format spécial indiqué dans le cahier de spécifications du client. Par exemple, les modérateurs peuvent demander la liste des utilisateurs créés entre le mois de Juin et Juillet 2008, de statut VIP et n'étant pas bannis. Vous pourrez trouver les explications sur le format utilisé en Annexe III.2.1: Documentation pour l'utilisation de l'API de modération

La page web leur renverra alors un flux XML conformément à la requête demandée, et l'équipe de modération pourra ensuite interpréter ce flux à partir de leur interface. Voici un exemple de requête et de flux XML renvoyé :

Exemple de requête de flux XML:


moder_xml.php?tbeg=1125525600&tend=1262127600&st=1&typemoder=1


Cette requête demande la liste d'utilisateurs créés entre Janvier 2007 et Janvier 2009. Cf Annexe III.2.1

La deuxième partie concerne la manipulation des données. Pour cela, ils font appel à une autre page de l'API en passant cette fois-ci un seul paramètre, une chaîne de caractères, ici en POST (donc à travers un formulaire).

Cette chaîne regroupe toutes les actions a effectuer sous un format bien spécial décrit dans le cahier de spécifications du client (cf annexe III.2.1). Les actions sont séparées entre elles par un pipe (« | »). Enfin chaque action est en réalité une suite de valeurs renseignant sur la nature de l'action (comme par exemple valider une annonce, bannir un utilisateur...). L'API a donc pour fonction de décrypter la chaîne et d'effectuer les actions requises.

Exemple de requête:

Cette requête comporte 5 actions:– Validation de l'annonce n°10 et mise en « Ugly » l'utilisateur concerné– Refus de l'annonce n°12 et mise en « VIP » l'utilisateur concerné– Validation de la photo n°15 et redimensionnement à (0, 0, 100, 100) (x, y, largeur, hauteur) avec mise en VIP.– Suppression de l'utilisateur n°14.– Ban de l'utilisateur n°15

Comme la requête se fait à travers une chaîne de caractères, elle doit obéir à un format précis pour pouvoir être décryptée par l'API. D'autre part, le traitement doit être asynchrone, ce qui


2,10,2,1|2,12,3,3|3,15,2,3,0,0,100,100|1,14,3,0|1,15,6,0

Figure 4: XML de réponse à la requête


signifie qu'une action dont le format est invalide ne doit pas bloquer les suivantes. Enfin, toutes les actions sont enregistrées afin que les modérateurs puissent déterminer quelles actions ont échoué et les renvoyer à l'API pour les traiter à nouveau.

Ce système est certes, assez complexe et des améliorations auraient pu être apportées pour mieux gérer les requêtes, comme par exemple l'envoi des requêtes par flux XML. Mais le client, c'est à dire l'équipe de modération, avait déjà leur interface qui génèrait ces chaînes de caractères, il fallait donc adapter l'API à leur modèle.

Cet API se veut précis et structuré, afin de permettre à toute équipe de modération ayant leur propre interface graphique de gestion de pouvoir modérer les données du site à partir de leur interface seulement en faisant appel aux services de l'API. Il leur suffit d'appeler les pages de l'API à travers leur interface en passant un certain nombre de paramètres sous le format décrit dans la documentation, paramètres généralement générés par des liens, des boutons ou des formulaires.

Actuellement, c'est la société Concileo qui s'occupe de la modération de Lovelee et qui utilise cet API pour modérer les données à partir de leur interface de gestion. Un système d'authentification par IP a été mis en place ici aussi afin d'empêcher toute personne extérieure d'utiliser les méthodes de l'API.



C) Conclusion

C'est à peu près tout concernant la partie Back-office de Lovelee. Le développement de cette partie a duré environ 2-3 semaines, ce qui m'a permis de déployer une première version de l'interface avant la première livraison du site principal pour que les équipes de modération puissent être à jour avec les utilisateurs du site et puissent agir sur les données relatives à ces utilisateurs (bannissement, validation de média, etc...).

Une seconde version a été livrée en Novembre prenant en compte toutes les modifications du modèle de données dues au développement des différentes versions de la partie front-office du projet. Parmi les modifications effectuées, il y'a notamment le rajout de la partie sur les scammeuses et la gestion des sondages.

Le développement de cette interface m'aura permis d'acquérir les notions:– Utilisation de la POO pour le développement web.– Respect du cahier de spécifications d'un client.– Développement d'un système d'authentification sécurisé par identifiants de session et par IP.– Développement d'une API Web pour un service externe.– Utilisation des flux XML pour communiquer des informations.– Compatibilité sur différents navigateurs web.– Configuration d'un serveur Web (Apache).

Concernant les notions techniques que j'ai acquises : – Développement en PHP en utilisant la programmation objet.– Sécurisation d'un site web en utilisant des identifiants de session.– Failles de sécurité qu'engendrent les cookies.– Correction des failles XSS (Cross site Scripting).– Développement de pages HTML et de feuilles de style CSS et soucis de compatibilité.



2) Développement de l'application principale

A) Structure du projet

Le développement du projet s'effectue selon l'architecture 3 Tiers pour le développement de RIA qui sépare le développement en trois couches distinctes qui communiquent entre elles:

– La couche présentation, c'est à dire la partie visuelle du produit. C'est ce que les utilisateurs verront sur leur navigateur lorsqu'ils utiliseront le produit. Cette partie communique avec le serveur pour récupérer et envoyer les données des utilisateurs. Elle est développée en Flex et correspond aux fichiers SWF qui sont des fichiers Flash compilés.

– La couche métier, qui va recevoir les données de la partie présentation et effectuer les traitements nécessaires pour leur renvoyer les résultats attendus. Elle communique avec la couche d'accès aux données pour envoyer et recevoir les données. Cette partie découpe le développement en « métiers », c'est à dire en modules effectuant chacun un traitement spécifique. Par exemple, un module Message s'occupant des relations d'envoi et de réception des messages privés. Cette couche est représentée par des classes dans des pages PHP, chaque classe correspondant à un module (ou métier).

– La couche données, qui s'occupe de stocker et de renvoyer les données à la couche métier. Cette couche correspond à la partie base de données, les données étant stockées dans des tables, et les traitements étant effectués par le biais de procédures stockées.

Pour mettre en place cette architecture, on utilise le modèle MVC (Modèle-Vue-Contrôleur) qui sépare là encore le développement selon trois couches:

– La vue: C'est la couche procédant à l'affichage des informations. C'est ici que seront définies les différents affichages du programme, indépendamment des données.Pour le développement Flex, on a d'un côté les fichiers procédant à la déclaration et l'agencement des éléments des pages, les fichiers MXML. Ces pages sont ensuite liées à une ou plusieurs classes ActionScript, ce qu'on appelle les classes « Behind », qui vont déclarer des évènements et des écouteurs afin de réagir avec le modèle pour récupérer les données à afficher dans les MXML. Tous ces éléments font partie de la vue.

– Le modèle. Il correspond à la partie traitement de données de l'application. Ces éléments sont séparés en modules pour se spécialiser dans un type de traitement spécifique.Ici, cela correspond à des classes ActionScript qui vont envoyer et recevoir des données du serveur, c'est à dire aux classes PHP, et les envoyer à la vue pour qu'elle puisse les afficher.Pour bien séparer la vue du modèle, les méthodes des classes ne sont pas appelées directement, mais par le biais d'un objet intermédiaire. D'autre part, les objets ne sont pas créés directement, mais par l'intermédiaire de « factories », garantissant la séparation entre les couches.

– Le contrôleur: C'est ce qui va permettre de relier le modèle à la vue, et vice-versa, par le biais d'évènements et d'écouteurs. Cela permet à la vue de solliciter le modèle lorsqu'un événement est déclenché, et d'avertir la vue des réponses du modèle.A chacun des éléments de la vue est associé un ou plusieurs évènements, chacun reliés à leur tour à un ou plusieurs éléments du modèle, et vice-versa.

Développement de l'application principale 30


Cette architecture permet donc de bien séparer le travail, afin que le développement d'une partie n'entrave pas le développement d'une autre. Voici un schéma explicitant ce concept pour le projet Lovelee (cf page suivante).


Figure 5: Architecture MVC de Lovelee


B) Utilisation du Framework TRIAD

Le Framework TRIAD permet de faciliter le développement de RIA suivant ce modèle, en fournissant bon nombre de classes et d'outils qui permettent de gérer les interactions entre les différentes couches. Pour mieux illustrer le fonctionnement du Framework, faisons une trace d'une action sur le site, par exemple la visualisation d'une fiche utilisateur.

1) L'utilisateur clique sur la fiche d'un autre utilisateur. L'application charge pour cela la vue « MemberForm.mxml » liée au behind « MemberFormBehind.as » via la méthode initBehind() appelée depuis la vue. Cette classe définit des méthodes pour obtenir les données à afficher et déclare des écouteurs qui vont réagir aux différents évènements qui surviendraient sur la fiche, dont celui de la visualisation de la fiche par un utilisateur.

2) Parmi ces évènements, celui qui nous intéresse est celui de l'obtention des données de l'utilisateur. L'écouteur qui réagit à cet événement est la fonction onScreenRequest, qui réagit lorsqu'un utilisateur demande à voir sa fiche. Cette fonction va ensuite faire appel au modèle pour obtenir les données requises.

3) C'est ici que le framework fait son apparition. L'appel au modèle ne se fait pas directement dans la classe behind, mais par l'intermédiaire d'une classe Command du framework qui va s'occuper d'exécuter les actions demandées. Cette classe implémente le design pattern Command, ce qui permet entre autres de séparer le traitement en tâches, de gérer les cas d'erreur, etc...

L'exécution de commandes se déroule en trois étapes: - Ouverture d'un nouvel ensemble de taches, ou « layer »- Exécution des taches, qui peuvent très bien comprendre l'ouverture d'un nouveau layer.- Fermeture du layer.Le framework est spécialement désigné pour permettre les tâches imbriquées, ce qui permet de simplifier énormément les opérations de debug si l'une des tâches échoue, car chacune des tâches est enregistrée dans un log via une commande du framework, traceDebug.

4) Le modèle est sollicité par le behind pour exécuter un certain nombre de méthodes en se servant de l'objet Command passé en argument pour séparer les étapes d'exécution. Pour l'acquisition des données de la base, chacun des modules du modèle doit implémenter la méthode loadData. Le Behind va donc chercher le ou les modules AS (ActionScript) intervenant dans la réquisition des données, et pour chacun d'eux appeler cette fonction loadData.

5) Le module AS communique avec le module PHP pour obtenir les données par l'intermédiaire de la fonction callService de la classe Command. Celle-ci prend en paramètres un nom de classe, un nom de méthode et une liste de paramètres et exécute la méthode de la classe PHP en question. Ce transfert se fait par envoi d'un message binaire qui contient les paramètres de l'exécution du service, ou AMF (Action Message Format).L'intérêt du framework ici est que cette méthode fonctionne quel que soit le langage de la couche métier, que ce soit PHP, Java ou C#.


http://www.amfphp.org/

http://en.wikipedia.org/wiki/Command_pattern

6) La méthode PHP communique à son tour avec la base de données en appelant une ou plusieurs procédures stockées MySQL. La communication avec la base de données est aussi facilitée par le framework qui définit des méthodes d'envoi de requêtes SQL quelle que soit la base de données, et qui procède à la connexion, l'envoi de la requête, l'obtention des résultats sous différents formats (entier, tableau à une dimension, tableaux à deux dimensions) et à la déconnexion, le tout en une seule opération.

7) Le module PHP retourne la réponse sous forme d'un tableau qui sera encodé dans un message AMF, message qui sera récupéré ensuite par le module AS pour mettre à jour ses champs. Le module AS va ensuite envoyer un événement via la méthode sendEvent qui va envoyer au contrôleur l'évènement, avec en paramètres la nature de l'évènement (fiche loadée, photo loadée, etc...), et la nature de la réponse (ok, failed). Cette méthode, tout comme loadData, doit être implémentée par chacun des modules du modèle.

8) Enfin le contrôleur, en charge d'écouter les évènements, va envoyer l'évènement reçu à toutes les vues, via la méthode dispatchEvent de l'objet Controller du framework. En l'occurence, la vue MemberFormBehind qui écoute l'évènement va exécuter la méthode onMemberLoaded, qui va mettre à jour la vue MXML associée avec les données récupérées, et affiche la fiche de l'utilisateur demandée.

9) L'utilisateur voit la fiche de la personne.

Ce cheminement est plus ou moins celui de toutes les actions du site, et le framework TRIAD permet de faciliter ce processus pour rendre le développement clair et structuré et pour réduire le temps de debug.

Une autre spécificité du framework est de séparer l'affichage des données statiques, les labels, de la vue. Ce qui signifie qu'il n'y aura pas de texte dans la vue, mais uniquement du code. Les labels sont définis dans des fichiers XML situés dans un répertoire « resources ».

Ces fichiers sont associés à une ou plusieurs vues. Ils définissent les liaisons entre les noms des labels et leur contenu. Cela permet par exemple d'obtenir les labels en plusieurs langues, en créant deux fichiers XML de structure identique, l'un contenant les labels en Français et l'autre en Anglais. Il suffit alors dans la vue d'appeler une méthode qui va aller chercher le fichier XML de la langue correspondant à celle de l'utilisateur, et de récupérer la valeur du label en question.

Pour cela, le framework TRIAD définit une fonction translate qui doit être implémentée dans chacun des behind, dont la fonction est d'aller chercher le fichier XML contenant les labels à afficher dans la vue associée, avec la langue spécifiée par l'utilisateur. Cette méthode fait ensuite appel à la méthode du framework getLabel pour obtenir la valeur du label passé en argument.

Exemple de fichier XML:

<?xml version="1.0" encoding="utf-8"?><labels>

<country_1><![CDATA[France]]></country_1><country_2><![CDATA[Espagne]]></country_2><country_3><![CDATA[Italie]]></country_3>

</labels>Figure 6: Fichier XML Français des Pays


Ainsi, dans la vue qui affiche la liste déroulante des choix de Pays, selon le choix de langue de l'utilisateur, la liste contiendra les noms des pays en anglais ou en français. On évite ainsi d'avoir à définir une vue pour chacune des langues,

Voilà donc en général les fonctionnalités les plus importantes du framework. Celui-ci comporte également d'autres fonctionnalités intéressantes comme la gestion de « niveaux », qui pour une méthode, permet d'avoir des résultats différents selon le niveau passé en argument; ou encore la conversion de fichiers XML en tableaux...


<?xml version="1.0" encoding="utf-8"?><labels>

<country_1><![CDATA[France]]></country_1><country_2><![CDATA[Spain]]></country_2><country_3><![CDATA[Italy]]></country_3>

</labels>Figure 7: Fichier XML Anglais des Pays


C) Développement de modules PHP et de procédures MySQL

Ma mission consistait au développement des modules PHP nécessaires à la communication des données de la base vers la couche Flex, c'est à dire, si on se réfère à la structure du projet, aux classes ActionScript du modèle.

Cela consistait en la définition et l'implémentation de classes PHP dont les méthodes servent de communication avec la base de données, afin de permettre à la couche Flex de dialoguer avec la base de données par un appel de services.

Le développement des classes s'accompagne intrinsèquement de la création de procédures stockées MySQL pour l'acquisition et l'enregistrement des données. Cette méthode permet de bien séparer la couche métier de la couche données, afin que le traitement des données se fasse uniquement côté SQL évitant ainsi la surcharge du serveur et les éventuels blocages. Le framework TRIAD facilite les communications entre le PHP et le MySQL, grâce à un panel de fonctions qui exécutent la plupart des actions nécessaires à l'envoi d'une requête SQL et renvoient la réponse sous différents formats, selon la fonction appelée.

Ce sont les fonctions « executeSQLFormat » où format est l'un des formats suivants:– Scalar: Si la réponse est un seul nombre.– SingleLine: Si la réponse ne consiste qu'en un seul enregistrement.– RecordSet: Si la réponse contient plusieurs enregistrements.– NoResult: Si la réponse ne renvoie rien.

Cette fonction prend en paramètres le nom de la base, la requête et un tableau d'arguments et envoie la requête à la couche SQL. Le résultat est alors retourné sous le format spécifié.

Exemple de requête: Liste des amis de l'utilisateur

$request correspond a l'appel de la procédure stockée sp_user_selectLoginFriend_onID (%d). $args est le tableau d'arguments qui va remplacer les % de la requête. $res est le retour de la méthode executeSQLRecordSet de TRIAD, qui prend en paramètres le nom de la base (ici « lovelee »), la requête et le tableau d'arguments. Ce résultat est donc un tableau d'enregistrements.Enfin on extrait chaque enregistrement dans un tableau avec la fonction fetch_assoc, qui est une méthode de la classe MySQLi de PHP.Il ne reste plus qu'à renvoyer $res à la couche Flex pour lui fournir la liste d'amis, avec en plus un élément $res['errorList'] qui sera non nul si la procédure stockée échoue et qui contiendra un message d'erreur à afficher côté Flex.


$request = "CALL sp_user_selectLoginFriend_onID(%d)";$args = array($usr_id);$res = executeSQLRecordSet('lovelee', $request, $args);

while ($row = $res->fetch_assoc()) {$ArrayOfDetail[] = $row;

}$res = $ArrayOfDetail;

Figure 8: Récupération de la liste des amis de l'utilisateur

http://fr2.php.net/manual/fr/book.mysqli.php


Pour respecter les standards du développement avec TRIAD, les procédures stockées doivent respecter un nom bien précis définissant le mieux possible leur fonction. Ceci permet aux développeurs PHP et MySQL de retrouver facilement la procédure qu'ils recherchent.

Le nom doit être au format : « <type_proc>_<nom_table>_<type_action><description> ».– type_proc: sp (pour stored procédure, qui ne renvoie rien mais affiche des données) ou udf

(pour user defined function, qui renvoie un résultat mais n'affiche rien)– nom_table: le nom de la table en rapport avec la procédure– type_action: action principale de la procédure: select, insert, delete, update– description: une courte description de la procédure.

L'exemple précédent, sp_user_selectLoginFriend_onID, signifie: « Procédure qui va agir sur la table user, qui va faire un select sur les logins des amis de l'utilisateur dont on a l'ID »

Les modules PHP devaient donc respecter ces méthodes de développement afin d'être comprises par toute l'équipe, à la fois par les développeurs PHP/MySQL, mais aussi par les développeurs Flex qui ont besoin d'un format de réponse précis pour récupérer les données. Une grande partie du travail consistait donc à comprendre ce dont à besoin l'autre partie et de créer en conséquence les méthodes et les procédures nécessaires à la satisfaction de ces besoins.

Voici les modules que j'ai eu à développer pour le front-office:

● Module de création et d'envoi de mails templates:

Ce module permet de créer et d'envoyer des mails prédéfinis aux utilisateurs en ne remplaçant qu'un certain nombre de champs spécifiques à l'utilisateur. Ce sont des « templates » qui sont définis sous la forme de fichiers XML qui contiennent seulement deux balises: une balise <subject> qui définit le sujet du mail et une balise <body> pour son contenu. Cette balise contient du code HTML dont les champs à remplacer sont entourés par des '%'.

Ces templates sont stockés dans un répertoire avec un nom de fichier bien précis permettant de renseigner le type de mail (mot de passe perdu, etc...), la langue de l'utilisateur et le sexe. (ex: « template_passwordLost_m_fr » est le template du mail envoyé en cas de mot de passe oublié pour un utilisateur masculin français).Il suffit alors d'appeler une méthode du module en lui passant en paramètres le type de mail, le genre, la langue, et un tableau associatif qui associe un nom de champ à sa valeur. Le module va alors automatiquement récupérer le bon template et remplacer les champs par ceux du tableau.

Exemple: Template du mail « passwordLost » (simplifié):

« template_passwordLost_m_fr.xml »



Ce template est récupéré en passant comme paramètres: « passwordLost » pour le type de mail, « m » pour le genre et « fr » pour la langue, ainsi que le tableau de remplacements qui est sous la forme: array("user" => $user, "password" => $password). Le module va alors automatiquement remplacer %user% par la valeur de $user, et de même pour les autres champs entourés de %.

● Module d'importation d'utilisateurs du site Amoureux.com:

Le site proposait aux utilisateurs du site Amoureux.com d'utiliser leur abonnement sur Lovelee et de profiter ainsi de toutes les fonctionnalités de Lovelee. Pour en profiter, il fallait que les inscrits d'Amoureux.com aient leur compte sur Lovelee en ayant les mêmes informations que sur leur compte Amoureux. Il fallait donc pouvoir exporter leurs données d'Amoureux pour ensuite les importer sur Lovelee.Ce module était destiné à cet usage. Tous les jours un fichier d'import était généré sur Amoureux contenant les données des membres à ajouter à la base Lovelee. Le module devait télécharger ce fichier et en extraire les données pour les ajouter ensuite sur Lovelee.

Le fichier en question était un fichier au format CSV, c'est à dire un fichier texte dont les données sont délimitées par un séparateur. Chaque ligne du fichier correspond à un utilisateur, et les champs sont séparés par un ','. Ce format est très maniable et sert souvent à l'importation et l'exportation de données. De ce fait, il est très facile d'analyser ce fichier et d'en extraire les données pour les ajouter en base.

Exemple :


<mail> <subject><![CDATA[Mot de passe oublié]]></subject> <body><![CDATA[ <html>

<body> <div class="mail"> <h1>Bonjour %user% !</h1><br/> <p>Suite à votre demande, un mot de passe a été généré pour vous

permettre de vous connecter sur Lovelee.</p> <table> <tr> <td>Mot de Passe:</td> <td>%password%</td> </tr> </table> </div></body>

</html>]]></body></mail>

Figure 9: Exemple de Template de mail


En première ligne on a le descriptif des champs de la table, et ensuite chaque ligne correspond à un utilisateur à ajouter, chaque champ étant séparé par une virgule. Il suffit de découper chaque ligne selon le séparateur et d'ajouter les données à la base.

L'importation nécessitait quand même quelques vérifications préalables avant l'ajout. Il fallait en outre vérifier que les comptes n'existaient pas déjà dans la base, vérifier que les villes existent, adapter le format des données pour qu'elles soient valides (comme par exemple enlever les accents et les espaces dans le pseudo), vérifier qu'il n'y a pas de champs vides, etc... Il fallait donc garder une trace des traitements n'ayant pas pu être effectués, de toutes les lignes qui n'ont pas pu être traitées afin qu'elles soient traitées ultérieurement au cas par cas. Ces lignes sont enregistrées dans plusieurs fichiers, chacun correspondant à une source d'erreur (login existant, ville inexistante, champs vides, etc...). Ainsi, l'administrateur peut voir quels traitements ont échoué afin de procéder manuellement à leur ajout.

Enfin, il fallait aussi que l'importation ne bloque pas la base de données pendant l'exécution, car il pouvait y avoir beaucoup de comptes à ajouter, et le temps de les ajouter un par un pouvait bloquer la base de données pendant quelques minutes. L'idée est d'utiliser un système de delaying entre chaque traitement, allongeant la durée de l'importation mais permettant d'empêcher la monopolisation du CPU et de la base.

● Module des signes astrologiques des utilisateurs

Ce module permet de gérer les signes astrologiques des utilisateurs.Le site propose d'afficher trois types de signes astrologiques: Signe du Zodiaque, Signe de Venus et Signe Chinois. Ce module permet d'obtenir à partir de la date de naissance d'un utilisateur ses signes astrologiques pour ensuite les afficher sur les différentes parties du site (fiche utilisateur, recherches, etc...) Ce module gère aussi les changements en temps réel, c'est à dire que lorsqu'un utilisateur modifie sa date de naissance, les signes astrologiques sont automatiquement modifiés. Une capture d'écran de la page de la fiche est disponible en annexe III.1.2.5.

Dans un premier temps, il fallait d'abord importer les données sur les signes astrologiques, c'est à dire les dates de naissance, la définition amoureuse, ainsi que la définition de la relation qu'ils entretiennent entre eux (par exemple, un Bélier avec un Gémeaux) dans la base de données. Il fallait donc concevoir le modèle de la base pour qu'à partir de la date de naissance de l'utilisateur, on ait accès aux signes astrologiques, à leur définition, etc...Un script a été développé pour insérer ces données à partir d'un fichier texte récupéré sur une base de données d'un site Internet spécialisé dans les signes astrologiques. Il a fallu aussi développer les procédures stockées nécessaires à l'acquisition des données relatives aux signes astrologiques à partir de la date de naissance.


"usr_login","usr_password","usr_email","sex_code","usr_birthday",..."jeanjean123","lalalila","[email protected]","M","12/01/1979",..."virgo12","AxM4FR7u","[email protected]","F","15/11/1981",...

Figure 10: Exemple de fichier CSV d'import d'utilisateurs


● Module Utilisateur: gestion du ban par Login et par Email

Nouvelle fonctionnalité pour le module Utilisateur: empêcher les utilisateurs dont le pseudo ou l'email sont bannis par l'administration de se réinscrire sur le site. Cette fonctionnalité intervient lors de l'inscription et lors du changement de mail d'un utilisateur. Une popup est alors affichée à l'utilisateur le prévenant que l'inscription ou le changement de mail ne peuvent pas s'effectuer.

Pour gérer cela, un statut a été ajouté à un utilisateur empêchant tout autre utilisateur d'utiliser son pseudo ou son email. Le test consistait uniquement à vérifier si, pour le login ou email passé en paramètre lors de l'inscription, il existait déjà dans la base et avait le statut de banni, auquel cas l'inscription renvoyait « false ». Ce statut correspond au champ "vld_code" mis à 4 (login banni), 5 (email banni) ou 6 (les deux) de la table user.

● Module Blacklist: liste noire des utilisateurs.

Ce module gère les listes noires d'utilisateurs, c'est à dire la liste des utilisateurs qu'un utilisateur n'a pas envie de voir dans les recherches et n'a pas envie de recevoir de mails ou d'invitations de leur part. Ce module concerne: l'ajout et le retrait de la liste, le filtrage des mails, des invitations et le filtrage des différentes listes d'utilisateurs retournées (recherches, diaporamas, newsletters, etc...)

Le module en lui-même était déjà développé, mais il possédait encore quelques bugs:– L'ajout et le retrait dans la même session était défectueux.– Le module filtrait les mails, mais ne filtrait pas les alertes, ce qui signifie que l'utilisateur

recevait les alertes de nouveau message et ne voyait aucun nouveau message dans sa boite.– De même, il recevait des demandes de chat et de jeu sans voir son correspondant.– L'ajout d'un ami en blacklist le supprimait de la liste d'amis du côté de l'utilisateur, mais pas

du côté de l'utilisateur filtré.– Le « blacklistage » pendant un chat ou un jeu ne bloquait pas l'envoi des messages tant que

la session n'était pas rechargée.

Il fallait donc corriger tous ces bugs, du côté PHP, MySQL, mais aussi du côté Flex, afin de fournir une fonctionnalité de filtrage efficace. Cette correction s'est bien entendu accompagnée de beaucoup de tests afin de vérifier que le module fonctionne dans toutes les situations.Vous trouverez une capture d'écran de la blacklist en Annexe III.1.2.3

D'autre part, la fonction de filtrage était très coûteuse en base, malgré toutes les optimisations qui pouvaient être faites. Il a donc été décidé de ne l'appeler que pour les fonctions les plus importantes du site, comme la recherche ou les messages privés, mais de la supprimer pour les fonctions les plus utilisées, comme par exemple la liste des utilisateurs en ligne.



● Module Utilisateur: Mise en avant des utilisateurs

Lors de l'affichage des listes d'utilisateurs, comme par exemple lors des recherches ou de l'affichage des diaporamas de la page d'accueil, une note, ou score, est calculée pour chacun des utilisateurs permettant de mettre en avant ceux qui ont les notes les plus élevées.

Ce score est calculé à partir des caractéristiques de l'utilisateur, notamment leur statut (VIP, Normal ou Ugly), leur statut de connexion (en ligne ou non), leurs photos et leur annonce. Une fonction de calcul attribue pour cela un « poids » à différents critères, par exemple, si le membre est connecté, elle lui attribue 30 points; si le membre est VIP, 40, etc... Elle additionne ensuite tous ces poids pour obtenir la note finale, le maximum étant 100.

Cette fonction était déjà développée mais ne prenait pas en compte beaucoup de critères (seulement le statut et le statut de connexion), mettant plus en avant les membres « Normaux » connectés que les VIP déconnectés. Il fallait donc améliorer cette fonction pour répondre aux spécifications du client, en attribuant des poids plus élevés à certains critères et en en créant d'autres. Un exemple de l'application de ce scoring est utilisé dans les fonctions de recherche. Une capture d'écran de la page des résultats de recherche se trouve en annexe III.1.2.6.

● Module d'Alertes: les alertes utilisateur

Ce module permet de gérer les alertes reçues par les utilisateurs. Ces alertes surviennent au cours d'évènements provoqués par les autres utilisateurs: Nouveau message privé, Nouveau Flash, Demande de chat... Une alerte est ensuite envoyée, selon la nature de l'évènement, pour prévenir l'utilisateur.

L'affichage de ces alertes est paramétré à travers les options du profil : L'utilisateur peut choisir les alertes dont il veut être averti. Il existe deux types d'alertes: les alertes mail et les alertes live. Les alertes mail sont les alertes qui seront envoyées par mail, elles correspondent aux évènements n'ayant pas besoin d'être notifiés en temps réel, par exemple les messages privés et les demandes d'amitié. Les alertes live, au contraire, sont les alertes qui seront envoyées en temps réel, qui émettront un message clignotant sur le côté gauche du site. Ce sont les alertes qui ne peuvent que surgir en temps réel, comme par exemple une demande de chat ou une visite de fiche. L'utilisateur peut donc choisir quelles alertes il veut


Par exemple, le maximum était:• Membre VIP• Qui a une annonce• Qui a des photos• Qui est de la même région que l'utilisateur• Qui est connecté actuellement

Le poids accordé à un membre VIP est plus important que tous les autres; Le poids accordé à un membre qui est de la même région est plus important que celui d'un membre connecté, mais moins important que celui d'un membre qui a des photos, etc...

Figure 11: Exemple de score


recevoir, et quelles alertes il veut filtrer. Notons que les alertes ne sont pas toutes configurables.Le menu des options d'alertes est disponible en annexe III.1.2.4.

Le module devait donc récupérer la liste des alertes cochées par l'utilisateur et filtrer avec celles qu'il a décochées, et de notifier l'utilisateur lorsqu'un événement survient dont l'alerte a été cochée.

Enfin, le module d'alerte gère aussi le contenu des newsletter: l'utilisateur peut spécifier dans les options les critères de recherches qui lui seront parvenues dans la newsletter. Le module récupère alors ses critères de recherches et les applique à la recherche qu'il recevra dans sa newsletter.Il peut choisir la région, l'age et la possession d'une photo. (cf Annexe III.1.2.4).

● Module d'abonnement et de désabonnement

Ce module permet de gérer les abonnements des utilisateurs. Un utilisateur peut s'abonner à une formule, changer d'abonnement, visualiser son abonnement, se désabonner et reprendre son abonnement. Sur Lovelee, l'abonnement donne le droit aux utilisateurs masculins de profiter de la plupart des fonctionnalités du site, à savoir l'envoi de messages privés, le chat, les jeux, les demandes d'amitié et les flashs. Cet abonnement est payant et a une durée limitée, allant de 1 à 6 mois. Durant cette période, un utilisateur a tout a fait le droit de se désabonner et de changer d'abonnement. Le module devait donc implémenter toutes ces fonctionnalités pour permettre aux utilisateurs de gérer leur abonnement.

Ce module est en relation avec « l'API Subscription », une interface mise en place pour effectuer les souscriptions aux offres proposées par Lovelee qui sera détaillée plus loin dans le rapport.Lorsqu'un utilisateur clique sur une offre la première fois, il est redirigé vers la page https qui lui demande d'entrer ses coordonnées bancaires. Après avoir souscrit a un abonnement, si il clique sur une formule, il ne sera pas redirigé vers cette page, mais effectuera directement un changement d'abonnement, sans aucun prélèvement. Le module devait donc être défini dans ce sens et devait permettre de renseigner si oui ou non un utilisateur avait déjà souscrit a un abonnement, de telle sorte qu'on n'ait pas besoin de lui redemander ses coordonnées bancaires.De plus, il devait aussi gérer le désabonnement mais aussi le réabonnement, c'est à dire qu'un utilisateur qui se désabonne doit pouvoir reprendre son ancienne offre sans avoir besoin de renseigner à nouveau ses coordonnées bancaires.



D) Conclusion

C'est à peu près tout concernant le développement de modules. La plupart des modules étaient déjà développés avant mon arrivée sur le projet, c'est pourquoi je n'ai pas eu à beaucoup développer sur cette partie là du projet.

Cette partie a été la partie qui m'a appris le plus de choses durant ce stage. Les notions que j'ai pu acquérir sont :

– L'utilisation et la compréhension du modèle MVC à partir d'un exemple concret qui est le front-office de Lovelee.

– Utilisation d'un framework d'entreprise pour le développement.– Structure et organisation du développement d'applications riches en Flex et PHP.– Séparation des couches de développement et travail modulaire.– Optimisation des requêtes MySQL pour supporter la charge.– Construction d'un modèle de base de données utilisant les formes normales à travers

l'exemple de Lovelee.– Utilisation d'outils externes pour simplifier le développement (EMS, Charles, Firebug...)– Aperçu du mode de développement de RIA selon l'architecture 3 Tiers.

Concernant les compétences techniques :– Utilisation de l'extension MySQLi de PHP pour simplifier les opérations de base de

données.– Utilisation d'un système de logging utilisant le module PEAR de PHP.– Utilisation des messages AMF pour permettre la communication entre le Flex et le PHP.– Développement de procédures stockées et de fonctions MySQL.– Autres connaissances relatives au développement PHP et MySQL acquises durant la période

de stage.

Le développement du front-office a donc été pour moi une bonne source d'apprentissage, et m'a permis ainsi d'aider au développement du projet afin qu'il puisse être livré dans les temps. Le nombre de développeurs PHP ayant baissé après les départ des stagiaires, il fallait donc que je prenne rapidement le relais pour développer les modules restants et permettre au Flex d'interagir avec la base de données pour ajouter les fonctionnalités attendues par le client.

Cette partie a duré environ 4 mois, période durant laquelle j'ai eu aussi d'autres missions comme l'intégration des pages d'accueil de Marie-Claire et de Cosmopolitan, mais aussi la mise en place du système de paiement des offres Lovelee. J'en parlerai plus en détail dans les chapitres suivants.



3) Intégration des pages Marie-Claire et Cosmopolitan

A) Description de la mission

Pour attirer plus d'utilisateurs, des pages d'inscription à Lovelee ont été développées pour être hébergées sur les sites web de Marie-Claire et de Cosmopolitan, afin de permettre aux visiteurs quotidiens de ces deux sites web de pouvoir s'inscrire sur Lovelee directement. Ces pages reprennent le même style de page que celui de la page d'inscription de Lovelee, mais en proposant un design différent qui colle à celui du site sur lequel elle est hébergée, à savoir Marie-Claire et Cosmopolitan.

Il fallait donc d'une part, designer les pages HTML et les feuilles de style CSS afin que ces pages reprennent le design global du site web, puis ensuite d'y intégrer les traitements PHP pour permettre l'inscription et la connexion à Lovelee directement à partir du site web.

Le design des pages HTML et des feuilles CSS était à la charge du développeur HTML/CSS. Le graphiste lui envoyait une maquette du résultat à obtenir, le développeur devait alors adapter la page pour correspondre avec la maquette, en faisant bien entendu attention à ce que les pages donnent le même résultat sur la plupart des navigateurs web.

Les pages étaient ensuite envoyées à l'intégrateur PHP, qui devait intégrer les traitements de données des formulaires aux pages, afin de permettre l'inscription et la connexion à partir de ces pages. Des captures d'écran des pages en question se trouvent en annexe III.1.3.1 et en annexe III.1.3.2.

D'autre part, ces pages devaient s'adapter au layout (disposition) du site dans lequel elles étaient hébergées, c'est à dire que les pages sont disposées dans un bloc, qui est entouré par d'autres blocs appartenant au site MC/Cosmo. Cependant, ces blocs ont leur propre feuille de style, et certaines propriétés écrasent les propriétés des feuilles de style du bloc Lovelee. Il fallait donc adapter ces feuilles de style de telle sorte qu'elles aient la main sur celles des blocs environnants sans pour autant les altérer (et par conséquent refaire le test sur tous les navigateurs).

C'est un travail assez fastidieux, mais qui a été facilité grâce à un plugin de Firefox, Firebug, qui retourne la liste des propriétés CSS appliquées à un élément, et qui retrace quelles propriétés sont écrasées par d'autres. Vous pouvez avoir un aperçu de ce plugin en annexe II.3.

Les tests d'intégration ont été effectués grâce à des appels de services de MC/Cosmo qui permettaient d'avoir le code HTML des blocs environnants, pour que l'on puisse procéder à la correction des feuilles de style avant la mise en disposition des pages.

Intégration des pages Marie-Claire et Cosmopolitan 44


B) Conclusion

En conclusion, cette partie m'aura surtout appris à déjouer les pièges du développement de pages HTML pour qu'elles soient compatibles sur tous les navigateurs. En effet, d'un navigateur à l'autre, la façon de parser le HTML change, certains réagissent différemment et il faut adapter le code pour qu'il soit compatible sur tous les navigateurs (ou du moins, les plus utilisés).

Il fallait aussi faire attention à la cohabitation de plusieurs feuilles de styles pour une même page, faire attention aux propriétés CSS qui sont écrasées par celles des autres feuilles CSS et qui donnent un résultat inattendu... Tous ces pièges ont été mis en évidence lors de cette partie, et il a fallu utiliser bon nombre de stratagèmes pour contrer tous ces pièges et donner le résultat attendu par le client.

En outre, cette partie m'a permis d'acquérir les notions:– Développement de feuilles CSS et compatibilité tous navigateurs– Connaissances sur les pièges CSS et sur la façon de les résoudre– Notions de « Hacks CSS », utilisation de propriétés « spéciales » pour résoudre certains

problèmes.– Respect du consortium W3C pour le développement des pages HTML– Intégration et adaptation de code PHP dans des pages HTML.

Au niveau technique : – Utilisation de SOAP pour obtenir le code HTML des blocs MC/Cosmo via des web services.– Mise en cache des pages pour accélérer leur affichage.– Développement avancé de feuilles de styles CSS.

Le développement de cette partie a duré environ 1 semaine, mais à chaque nouvelle version de la page d'accueil de Lovelee, il fallait aussi créer les pages d'accueil MC/Cosmo, ce qui fait qu'il y eut plusieurs versions des pages d'accueil développées durant ma période de stage.

Intégration des pages Marie-Claire et Cosmopolitan 45


4) Mise en place d'une solution de paiement

Le site Lovelee propose des services gratuits et des services payants aux utilisateurs. L'inscription est gratuite, et les utilisateurs peuvent gratuitement profiter des services de base, c'est à dire la visualisation des fiches, les recherches, l'utilisation du bloc note, le zapping, etc... Par contre, tous les services de mise en relation, c'est à dire l'envoi de messages, la messagerie instantanée, les jeux de mise en relation, et tout ce qui permet de mettre en relation les utilisateurs entre eux, sont payants (plus précisément, ils sont payants pour les hommes).

L'abonnement se fait par le choix d'une formule, qui autorise pendant une durée déterminée les utilisateurs à profiter des services payants. Plusieurs formules sont disponibles, qui vont de 1 à 6 mois, avec des offres promotionnelles bien entendu pour pousser les utilisateurs à s'abonner. Il fallait donc mettre en place une solution de paiement sécurisée et simple d'utilisation pour permettre aux utilisateurs de s'abonner comme ils le feraient sur les autres sites proposant des services payants.

Pour cela, Tangane a décidé d'utiliser les solutions de paiement e-commerce de Atos Origin et de la Société Générale, SOGENACTIF. SOGENACTIF propose plusieurs solutions de paiement pour les sites marchands, sous forme d'API pour être facilement utilisables par les sites de e-commerce. Dans un premier temps, c'était l'API Payment de SOGENACTIF qui a été utilisé. Cet API demandait un paiement de l'utilisateur une bonne fois pour toutes, et à chaque fois que l'utilisateur désirait reprendre une formule, il devait à nouveau payer. Ensuite il a été décidé de prendre l'API Subscription afin de permettre aux utilisateurs de reconduire leur abonnement automatiquement.

Le paiement devait s'effectuer en trois temps:

- L'utilisateur choisit une formule sur Lovelee, il est redirigé vers une page lui permettant de choisir le moyen de paiement (CB, Visa...)

- Il est ensuite redirigé sur le site de SOGENACTIF lui demandant de renseigner ses coordonnées bancaires. Ce site est la propriété de SOGENACTIF et est entièrement sécurisé.

- La banque vérifie si le paiement peut s'effectuer, si oui l'utilisateur est ensuite redirigé vers Lovelee qui lui signale que son abonnement a bien été pris en compte. Dans le cas contraire, l'utilisateur est renvoyé vers Lovelee qui lui signale que son abonnement n'a pas été pris en compte en lui fournissant la raison du refus. Bien entendu l'utilisateur peut aussi annuler la transaction.

Le passage d'une étape à l'autre se fait par l'appel des services de l'API. Il fallait donc implémenter les pages permettant de mettre en œuvre ce processus de paiement.

L'API proposait plusieurs exécutables, chacun en rapport avec une étape du processus de paiement, ainsi qu'un certificat de démonstration pour effectuer les tests. Elle comportait aussi une série de pages d'exemple pour utiliser l'API, ainsi que les documentations associées.

Mise en place d'une solution de paiement 46


A) API Payment

L'API Payment permet d'effectuer des paiements ponctuels. Il n'y a donc pas de reconduction d'abonnement ni de modification.

Le processus de paiement nécessite l'implémentation de trois pages PHP, chacune faisant appel à l'un des services de l'API. Pour permettre d'identifier à quel service chacune des pages fait appel, les pages ont comme nom « call_<service> », où service est le nom du service de l'API.

Les services de l'API sont disponibles sous forme de binaires (exécutables), et prennent un certain nombre d'arguments, dont certains sont facultatifs, qui permettent de passer d'une étape du processus à l'autre. Pour l'API Payment, ces services sont au nombre de deux : request et response.

• request est le service générant la requête envoyée à SOGENACTIF pour initier le paiement. • response est le service analysant la réponse reçue de SOGENACTIF pour en tirer les

informations nécessaires à la souscription.

Par conséquent, les pages à développer sont les pages call_request, dont le but est de générer la requête à envoyer à SOGENACTIF, et call_response, qui va analyser la réponse de SOGENACTIF pour confirmer à l'utilisateur de sa prise d'abonnement si le paiement s'est bien effectué. D'autre part, une autre page doit aussi être développée, qui est la page call_autoresponse. Cette page fait appel au binaire response et est systématiquement exécutée lorsque l'utilisateur valide ses coordonnées bancaires. Selon la réponse de la banque concernant la transaction, c'est sur cette page que se font les opérations en base comme l'affectation de l'abonnement à l'utilisateur, mais aussi et surtout pour garder une trace des transactions effectuées.

Voici un schéma illustrant le processus (cf page suivante):

D'autre part, pour utiliser l'API, le commerçant à besoin d'un certificat et d'un numéro d'identification qui sont fournis par Atos dans le pack de l'API. Le pack contient aussi un certificat de démonstration pour que le commerçant puisse faire les tests avant de mettre la solution en production.

Enfin, l'API contient aussi un tutoriel de conception de templates personnalisés de la page de paiement qui se trouve sur le serveur SOGENACTIF. Les templates sont de simples pages HTML (sans code PHP) qui doivent obéir à des règles:

– Elles ne doivent pas contenir de balises fermantes </body> et </html>.– Elles doivent obligatoirement contenir un tag [SIPS] qui est la partie immuable des pages,

qui contient le formulaire de renseignement des coordonnées bancaires.– Elles ne doivent pas faire appel à des éléments externes, car cela compromettrait la sécurité

de la page.

Ce tutoriel est le Guide de Personnalisation des Pages, et définit quelles sections de la page peuvent être modifiées. En outre, un outil de test est aussi fourni pour tester les templates, test_template. C'est un exécutable qui prend en argument un template et un style de page (paiement normal, paiement avec CVV...) et qui génère la page HTML de paiement personnalisée. Avec cet outil, le programmeur peut développer et tester ses propres templates avant de les envoyer à SOGENACTIF pour qu'ils les mettent sur leur FTP.


Figure 12: Processus de paiement SOGENACTIF


Développons à présent le processus de paiement utilisé par l'API Payment.

– Lorsque l'utilisateur choisit sa formule de paiement, il est redirigé vers la page « call_request » avec des paramètres GET renseignant sur l'action, c'est à dire l'identifiant de l'offre et de l'utilisateur.

– Tout d'abord, les informations concernant le paiement sont récupérées à partir des valeurs passées en paramètres: le montant de l'offre, la durée de l'offre, etc...

– Ensuite, s'effectue un appel au binaire « request » Cet exécutable prend un certain nombre d'arguments et génère un formulaire HTML qui redirigera l'utilisateur vers la page de paiement SOGENACTIF avec les informations nécessaires au paiement.

– Parmi ces informations, certaines sont obligatoires, comme le numéro d'identification du commerçant, qui va permettre d'identifier le certificat du commerçant obligatoire à l'utilisation de l'API; la devise utilisée par le commerçant, le pays du commerçant; le numéro de transaction (qui peut être généré par l'exécutable) qui doit être unique; les moyens de paiement proposés; et les informations du paiement, c'est à dire le montant, la durée et l'identifiant de l'offre.

– D'autres données sont facultatives, et sont uniquement destinées à la personnalisation des pages de paiement SOGENACTIF, comme par exemple l'affichage ou non du logo de sécurisation de paiement; la couleur d'arrière-plan, le logo affiché, l'affichage du moyen de paiement, etc... C'est aussi ici que le commerçant spécifie le template de personnalisation des pages SOGENACTIF.Toutes ces données sont expliquées dans le Dictionnaire de données fourni dans la documentation de l'API.

– Enfin, un paramètre doit être renseigné, qui est le chemin du fichier « pathfile ». Ce fichier est un fichier texte spécifiant les chemins utilisés par l'API: le chemin des images, le chemin des exécutables, etc... C'est ici qu'est spécifié le chemin du certificat du commerçant.

– Une fois tous ces paramètres renseignés, l'exécutable request est appelé. Si il n'y a pas d'erreur, l'exécutable génère le formulaire HTML. Ce formulaire ne contient que les logos des moyens de paiements spécifiés, qui redirige vers la page de paiement SOGENACTIF lorsque l'utilisateur clique sur un des logos.Ce formulaire peut donc très bien être inséré dans une page HTML du site. Vous trouverez une capture d'écran de la page call_request en annexe III.1.4.1.

– L'utilisateur doit ici entrer ses coordonnées bancaires. Il peut aussi décider d'annuler si il le souhaite. La page est entièrement sécurisée et les données qui transitent sont cryptées. Une capture d'écran est disponible en Annexe III.4.2.

– Une fois qu'il a rempli le formulaire, une demande d'autorisation est effectuée auprès de sa banque. La banque lui renvoie un code réponse renseignant si oui ou non la transaction peut s'effectuer. SOGENACTIF analyse ce code et effectue le prélèvement si la réponse est positive.


– SOGENACTIF fait ensuite appel à la page « call_autoresponse ». Cette page est appelée quelle que soit la réponse de SOGENACTIF, et permet au commerçant par exemple de garder une trace des transactions effectuées. Cette page doit pouvoir être disponible à partir de la page SOGENACTIF et l'adresse doit être spécifiée dans le fichier « pathfile ». Cette page est systématiquement appelée quelle que soit la réponse de la transaction. C'est donc à ce moment que s'effectue les opérations en base concernant la souscription à l'abonnement.

– Enfin, selon la réponse de la banque, la page SOGENACTIF renvoie soit une confirmation du paiement avec un récapitulatif de la transaction, soit une page qui signale à l'utilisateur que sa transaction n'a pas pu être effectuée. L'utilisateur peut alors ici cliquer sur le bouton « Revenir à la boutique » qui le redirige vers la page « call_response » faisant appel au binaire response. Exemple en annexe III.4.3.

– L'exécutable response prend en paramètres le message crypté de SOGENACTIF et le décrypte pour en tirer les informations.Parmi les informations du message crypté, on retrouve tous les paramètres passés lors de l'appel à call_request, c'est à dire les informations du commerçant et du paiement; mais aussi les informations de la transaction effectuée, c'est à dire les codes réponse de la banque, de SOGENACTIF et de CVV (pour le code au dos de la carte bleue), le numéro de la transaction, les 4 premiers chiffres de la carte bleue, etc...

– Cette page ne doit pas en général effectuer de traitements, étant donné qu'elle n'est appelée que si l'utilisateur clique sur le bouton de retour. Dans le cas de Lovelee, lorsqu'il s'agit d'une transaction réussie, cette page confirme à l'utilisateur de sa souscription à l'abonnement qu'il a choisi; dans le cas contraire elle lui renvoie la nature du refus, selon le code réponse qu'elle a reçu de SOGENACTIF. La descriptions des codes de retour se trouve dans le Dictionnaire des Données.

– L'utilisateur peut alors profiter directement de son abonnement, si l'abonnement a réussi, ou revenir sur la page de paiement SOGENACTIF si il y a eu échec.

Pour tester, un certificat de démonstration est fourni avec l'API. Lors de la phase de tests, le paiement peut se faire avec un numéro de carte bleue quelconque sans qu'il n'y ait aucun prélèvement. Il suffit juste de spécifier comme numéro de commerçant le numéro de démonstration.

C'est durant cette phase que se fait le développement des pages call_request et call_response. Cependant, ni les templates, ni la page call_autoresponse ne peuvent être utilisés durant cette phase. Les opérations comme l'insertion en base des données de l'abonnement et des transactions doit donc se faire temporairement dans la page call_response pour pouvoir être testées et vérifiées durant cette phase.

Une fois la phase de tests conclue, le commerçant peut passer en phase de « préproduction ». Durant cette phase, le paiement se fait comme en phase de production, c'est à dire que l'utilisateur doit entrer un numéro de carte bleue valide, mais aucun montant ne sera prélevé. Le numéro de commerçant ainsi que son certificat doivent donc être renseignés. De plus, c'est durant cette phase que les tests sur le template et sur la page call_autoresponse doivent être effectués. Si il y'a des problème, ils doivent donc être résolus avant de passer en production.


Le commerçant doit effectuer au moins un test de paiement concluant avant de pouvoir passer en production. Un entretien avec Atos doit se faire pour valider le passage en production. Bien entendu, il faut s'assurer que tout fonctionne avant de valider cette phase, notamment les opérations en base.

Dans le cas où il y aurait des problèmes avec l'abonnement, un service de back-office est disponible sur le site d'Atos, pour procéder aux remboursements si il y'a besoin. C'est pourquoi il faut impérativement garder une trace de toutes les transactions.

Cette solution de paiement pouvait suffire pour les offres de Lovelee dans un premier temps. Les utilisateurs souscrivaient pour une offre pendant une durée limitée, et à l'issue de leur période, si ils le souhaitaient, ils pouvaient prendre une nouvelle formule pour reconduire leur abonnement.

Cependant, pour les utilisateurs ce système posait problème, puisque l'abonnement se coupait d'un seul coup et les utilisateurs ne pouvaient plus profiter de Lovelee jusqu'à ce qu'ils reprennent un abonnement. Il fallait alors trouver une solution pour qu'ils puissent reprendre le même abonnement au terme de l'ancien sans avoir à repasser par SOGENACTIF. Après quelques études, il s'est avéré que c'est l'API Subscription qui remplissait au mieux ces fonctions, en proposant une reconduction automatique de l'abonnement pour les utilisateurs, et un système de prélèvement simple à installer pour le commerçant.



B) API Subscription

Cette solution de paiement permet d'effectuer des prélèvements périodiques aux utilisateurs, assurant ainsi la reconduction de leur abonnement sans qu'ils n'aient besoin de devoir renseigner à nouveau leurs coordonnées bancaires. Cette solution était donc plus adaptée au client comme aux utilisateurs, qui n'avaient pas leur abonnement stoppé d'un coup, et qui pouvaient à tout moment suspendre ou changer d'abonnement sans qu'il n'y ait aucune répercussion sur leur compte bancaire.

Le processus est assez similaire à celui de l'API Payment, à quelques différences près.

Tout d'abord, il n'y a plus deux binaires mais trois à présent, qui utilisent le même fonctionnement que ceux de l'API Payment, mais qui peuvent prendre plus de paramètres :

– recordabo, qui correspond sensiblement au binaire request.– responseabo, qui correspond au binaire response.– manageabo, qui sert à la modification de l'abonnement et qui utilise le même procédé que

recordabo.Les pages appelant chacun des services sont donc les pages call_recordabo, call_responseabo et call_manageabo. De même, la page call_autoresponseabo sert pour la réponse automatique comme pour l'API Payment.

D'autre part, la création de la requête par l'exécutable recordabo nécessite la plupart des paramètres déjà nécessaires pour request, mais le montant de la transaction n'est ici pas obligatoire. Il dépend de la valeur d'un paramètre, « sub_type » : Si celui-ci vaut 0, la transaction est « gratuite », c'est à dire qu'aucun montant n'est prélevé à l'utilisateur lors de la souscription. Au contraire, si sub_type vaut 1, le commerçant doit spécifier un montant que l'utilisateur doit payer lors de l'inscription. Cela permet donc, dans le cas d'offres gratuites, de ne faire payer l'utilisateur qu'au bout de la fin de la période d'essai, chose qui n'était pas possible avec la solution précédente.

De plus, la requête pouvait contenir à présent des informations sur l'utilisateur, à savoir son nom, son adresse, etc... Ceci dans le but de pouvoir effectuer des livraisons. Dans le cas de Lovelee, ce n'était pas nécessaire car Lovelee proposait des services virtuels, ces paramètres n'avaient donc pas besoin d'être renseignés.

Enfin, la différence la plus importante est qu'au terme de la transaction un numéro d'identifiant unique est généré qui est le numéro d'abonné. Ce numéro est très important pour les prélèvements et les modifications d'abonnement, il doit donc être gardé avec soin côté commerçant et côté client.

La mise en place de cet API nécessitait une modification du modèle de la base de données pour prendre en compte le cas des abonnements récurrents et des opérations de suspension et de modification d'abonnement. La plus grosse partie du travail ne résidait donc pas dans la mise en place de l'API Subscription, mais plutôt dans le développement des procédures stockées nécessaires au bon fonctionnement de ce nouveau système.



L'autre intérêt de l'API Subscription réside dans le système de prélèvement automatique. Enfin, pour être précis, ce n'est pas réellement automatique puisqu'il nécessite quand même une action du commerçant pour effectuer les prélèvements.

Pour cela, le commerçant doit générer des fichiers de requête qui contiennent les informations des abonnés à prélever. Parmi ces informations, on compte bien entendu le numéro de l'abonné reçu lors de l'étape de souscription, mais aussi le numéro du commerçant, la devise utilisée, le montant à prélever et un numéro de transaction qui doit être unique. Les informations contenues dans ces fichiers ainsi que la syntaxe utilisée sont expliquées dans le Guide de Transfert de Fichiers.

Ces fichiers doivent ensuite être déposés sur le serveur FTP d'Atos. Toutes les heures, un robot va passer vérifier le contenu du FTP pour voir si il n'y a pas de nouveaux fichiers. Atos va ensuite analyser le contenu de ces fichiers, et si les fichiers sont bien construits, procéder aux demandes de prélèvement auprès des banques. Selon le résultat de la demande, Atos va à son tour générer des fichiers de réponse, que le commerçant doit alors récupérer et analyser à son tour pour effectuer les opérations en base comme l'affectation du nouvel abonnement.

Le format des fichiers de requête et de réponse est expliqué dans l'Annexe III.2.2 : Documentation pour l'utilisation de l'API Subscription, ainsi qu'un exemple d'utilisation.

Un robot est donc nécessaire, qui doit chaque jour vérifier quels abonnés doivent être prélevés, et générer les fichiers de requête nécessaires à Atos. Puis il doit bien entendu pouvoir récupérer les fichiers de réponse et analyser ces fichiers pour effectuer les opérations en base nécessaires.

Donc la mise en place de cette solution de paiement permettait d'ajouter des fonctionnalités importantes concernant l'abonnement, comme la suspension d'abonnement et la modification de la formule. A présent, lorsque les utilisateurs désiraient changer d'offre, ils n'avaient pas besoin de devoir à nouveau passer par la page de paiement SOGENACTIF. Leur numéro d'abonné étant déjà renseigné, le changement d'abonnement se faisait instantanément.

La modification d'abonnement entraînait la fin de l'abonnement en cours et la prise du nouvel abonnement tout en gardant le même numéro d'abonné. Il suffisait alors au robot de voir quels abonnements ont été souscrits après son dernier passage, et de générer les fichiers nécessaires pour procéder aux prélèvements des nouveaux abonnés.

Au contraire, la suspension d'abonnement arrêtait l'abonnement en cours, mais gardait toujours le numéro d'abonné. A partir de là, si l'utilisateur souhaitait reprendre son offre, il n'avait pas besoin de devoir renseigner à nouveau ses coordonnées bancaires grâce à son numéro d'abonné. Ce sera au robot de procéder au paiement, de la même manière que lors du changement d'abonnement. Tout est donc automatisé, et donc beaucoup plus agréable pour les utilisateurs comme pour les commerçants.



C) Conclusion

En conclusion, cette partie m'aura surtout appris à lire une documentation attentivement et à faire appel à mon esprit de synthèse pour résumer au chef de projet ce qui est implémentable et ce qui ne l'est pas. En outre, j'ai eu a faire quelques documentations sur l'installation et l'utilisation de chacune des API. Vous en trouverez une copie de l'API Subscription en annexe III.2.2.

Parmi les notions que j'ai acquises, se trouvent :– Lecture de documentations et résumés.– Implémentation de pages appelant des services d'une API.– Fonctionnement du système de paiement des sites e-commerce.– Adaptation du modèle de données pour répondre aux besoins du client.

Pour ce qui est des compétences techniques, cette partie là ne m'a pas apporté grand chose, mais l'apport le plus important selon moi est la compréhension du système de paiement des sites e-commerce, qui était complètement flou avant mon arrivée. Cela m'a permis de comprendre que l'implémentation est vraiment simple à réaliser et ne demande aucune qualification particulière.

Ceci m'a permis de mettre en place rapidement le système de paiement, mais le plus gros du travail a été d'adapter la base de données pour qu'elle puisse gérer les abonnements. L'implantation des APIs, quant à elle, est relativement aisée et peut se faire par n'importe qui tant la documentation qui l'accompagne est simple et précise.



5) Autres tâches

Pour finir, d'autres tâches m'ont été confiées qui n'entrent dans aucune des catégories de tâches citées précédemment. Ce sont de petites tâches qui ne font pas l'objet d'un chapitre mais dont il est nécessaire de parler.

● Filtrage par IP

Afin de compléter la gestion des scammeuses (cf gestion des scammeuses), un système de filtrage d'IP a été mis en place afin d'empêcher à ces personnes d'accéder au site et d'effectuer leur démarchage. Pour cela, une page a été développée contenant des plages d'IP de personnes potentiellement scammeuses. En général, ce sont des IP de pays d'Europe de l'Est et d'Afrique, car c'est en général de ces endroits là que viennent ce genre de personnes.

Si une adresse IP appartenant à ces plages d'IP tente d'accéder à une page du site, la page la redirige vers une page de « maintenance ». Ceci est implanté sur toutes les pages du site, sauf bien sur les pages d'aide, qui restent disponibles au cas où une personne est interdite d'accès alors qu'elle ne le mérite pas. Elle peut dans ce cas toujours contacter le service technique et exposer son problème.

● Ajout des régions et des villes de Suisse et de Belgique

Le site Lovelee recensait toutes les régions et les villes de France, mais l'ancien site gérait aussi les villes et régions de Suisse et de Belgique. Il fallait donc les rajouter dans la base de données pour que le site puisse accepter les utilisateurs de ces régions/villes.

Le plus gros du travail consistait à récupérer les noms des villes et leurs codes postaux à partir d'Internet. Il fallait trouver une base de données fiables et pouvoir les importer sur la base de données Lovelee. En effet, sur l'ancien site, il n'y avait que les régions de Suisse et de Belgique, mais pour correspondre avec la nouvelle base, les noms des villes et les codes postaux étaient nécessaires et ils étaient malheureusement absents de l'ancienne base. Il fallait donc les insérer et bien entendu insérer les relations entre les villes et les codes postaux.

Cependant, cette opération n'a jamais été mise en production. Une étude à démontré que sur l'ensemble des utilisateurs du site, la part des belges et des suisses était inférieure à 1%, et que l'implémentation de cette fonctionnalité ne générerait pas assez de revenus par rapport au coût de la mise en place. Elle a donc été abandonnée, mais prête à être mise en production si besoin est.

● Création de mails de confirmation d'abonnement et de désabonnement

Le développement des modules d'abonnement et de désabonnement était accompagné de la création des mails de confirmation associés, qui étaient envoyés lorsque l'utilisateur souscrivait à un

Autres tâches 55


abonnement ou se désabonnait. Ce sont des mails HTML qui utilisent le système de templates cité précédemment.

Il fallait donc créer ces pages HTML qui affichent toutes sortes d'informations concernant l'abonnement pris ou le désabonnement de l'utilisateur, et les insérer dans le template prêt à être envoyé aux utilisateurs. Exemple:

● Stats hebdomadaires de Lovelee

Enfin, la dernière tâche confiée consistait à relever les statistiques hebdomadaires de fréquentation du site. Ces statistiques sont composées du nombre de visiteurs journaliers, du nombre d'inscrits journaliers hommes et femmes, et du nombre d'abonnés ainsi que le chiffre d'affaire engendré.

Ces statistiques devaient être récupérées tous les jours depuis la mise en production de la première version de Lovelee, et envoyées au client. Cela lui permettait d'investir dans de nouvelles fonctionnalités si les revenus le permettaient.

Ces stats étaient récupérées à partir d'un script en base de données qui récupérait les données pour chacune des statistiques. Il fallait ensuite les insérer dans un fichier Excel avant de les envoyer au client. Exemple:

Autres tâches 56

Figure 13: Email d'abonnement


Autres tâches 57

Figure 14: Statistiques quotidiennes d'utilisation de Lovelee

Synthèse quotidienne des éléments clef du modèle de recrutement / transformation

Total du Jour Total depuis le début de la semaine Total depuis le début du mois Total depuis le 6 Octobre 08

Visiteurs

VU

Logs uniques

% Logs 38,63% 40,16% 38,63% 36,30%

Inscrits

Masculins 475 475

Féminins 370 370

Total 845 845

Abonnés

Nombre 25 81 25 104

% Inscrits 5,26% 2,02% 5,26% 1,27%

CA X € X € X € X €

CA/Abonné 0,00 € 0,00 € 0,00 € 0,00 €

6 726 36 324 6 726 114 210

2 598 14 586 2 598 41 454

4 013 8 165

2 658 9 944

6 671 18 109


ConclusionConclusion

Pour conclure, ce stage chez Tangane a été une mine de connaissances pour ce qui est du développement d'applications web, plus particulièrement pour le développement d'applications riches qui sont les applications de nouvelle génération.

En outre, ce stage m'a permis d'acquérir beaucoup de connaissances, que ce soit dans la gestion de projet, dans les méthodologies de développement, dans la communication entre les différents acteurs du projet, dans l'utilisation d'outils simplifiant le développement, etc... mais aussi au niveau technique, dans la découverte de technologies (Flash, Flex..), dans la maîtrise d'outils et de langages de programmation (PHP, MySQL...) et dans la découverte d'un environnement de développement différent de ce qu'on dispose en milieu scolaire.

Le projet Lovelee, qui est un projet de site de rencontres en Flex et PHP, a permis de mettre en pratique toutes les notions que j'ai apprises durant ma scolarité, mais aussi les notions que j'ai acquises au cours du stage; et ce malgré les contraintes qui pesaient sur nous (temps, qualité, coûts...).

Le projet était développé suivant un modèle conçu pour le développement d'applications riches qui est le modèle 3 Tiers, structurant le développement en trois axes:

– la partie présentation, qui est en Flex, qui représente toute la partie visuelle sans les données.

– la partie métier en PHP qui relie la partie visuelle aux données par l'intermédiaire de modules (ou métiers).

– la partie données en MySQL qui s'occupe de la récupération et du stockage des données.Ceci afin de pouvoir répartir les tâches selon les profils des développeurs.

D'autre part, le développement est facilité par l'utilisation d'un framework spécialement conçu pour le développement d'applications riches, qui est le framework Triad, entièrement conçu par Tangane; mais aussi par l'utilisation d'outils extrêmement utiles pour le développement (Firefox, Eclipse, SVN...) améliorant ainsi la qualité de travail des développeurs.

Ma mission au sein de ce projet a été, d'une part, de fournir mon aide au développement du Front-Office de l'application, c'est à dire au développement de modules PHP de l'application. Il s'agissait d'implémenter des classes PHP qui seraient en liaison avec les modules Flex pour fournir les données de la base à la couche Flex. Ces classes sont donc en liaison avec le Flex, d'une part, mais aussi avec la base de données d'autre part. C'est pourquoi ma mission a aussi été de définir les procédures stockées MySQL qui seront appelées par les modules PHP afin de fournir les données attendues à la couche Flex. C'est pourquoi la communication entre les membres de l'équipe est primordiale, pour que chacun puisse aligner son travail avec celui des autres.

Parmi les modules que j'ai eu a développer, les plus importants ont été:

– Gestion des listes noires des utilisateurs– Envoi de mails « templates »– Gestion des alertes.– Abonnement et désabonnement des utilisateurs.

Conclusion 58


D'autre part, ma mission a aussi été de développer du début à la fin une interface d'administration extérieure à la partie principale du site. Cette interface, le « back-office », devait permettre aux modérateurs, extérieurs au site, de gérer les données du site de façon simple et sécurisée.

En outre, ils devaient pouvoir :– Valider ou refuser les annonces et les photos des utilisateurs– Bannir ou supprimer les utilisateurs.– Visualiser les fiches des utilisateurs directement.– Créer et modifier des sondages– Accéder à la liste des dernières annonces, photos et rapports des utilisateurs– etc...

Le tout à partir d'une interface simple et agréable. D'autre part, il fallait aussi pouvoir envoyer ces informations aux modérateurs sans qu'ils passent

par l'interface, par le biais d'une API qui fournit ces fonctions que les modérateurs peuvent appeler à partir de leur propre interface. Cela s'est fait simplement par la transmission de flux XML et de chaînes de caractères par le biais de requêtes HTTP GET ou POST.

La troisième partie de ma mission a été l'étude et l'implémentation de systèmes de paiement par le biais d'appel de services d'API. Les API, fournies par ATOS, comportent plusieurs binaires, ou services, qui permettent de passer d'une étape du processus de paiement à une autre, de manière entièrement sécurisée. Il suffisait de développer les scripts et les procédures stockées qui devaient faire appel aux services de l'API et de s'assurer de bien respecter les conditions d'utilisation pour installer le système. Cela m'a permis en outre de comprendre le fonctionnement des systèmes de paiement, qui sera vraiment profitable si je décide de poursuivre ma carrière dans le e-commerce.

Enfin, la dernière partie de ma mission m'a placé en tant qu'intégrateur Web, ce qui m'a permis d'en apprendre un peu plus sur ce rôle et de me mettre à leur place en intégrant les pages d'accueil pour les sites de Marie-Claire et Cosmopolitan.

En conclusion, ce projet m'a permis de mieux comprendre comment se déroule le développement d'applications web, tout en me permettant d'apporter mon aide au développement afin d'aider l'équipe à rendre un produit satisfaisant le client dans les temps et délais. J'ai acquis énormément de connaissances au cours de ce stage, et cela me sera d'une grande aide si je décide d'en faire ma carrière à la fin de mes études.

Conclusion 59


BibliographieBibliographie

– Téléchargement du framework Adobe Flex : http://www.adobe.com/fr/products/flex

– Manuel de référence et snippets de Flex: http://examples.adobe.com/flex2/inproduct/sdk/explorer/explorer.html

– Manuel de référence PHP :http://fr.php.net/manual/fr/

– Manuel de référence MySQL :http://dev.mysql.com/doc/refman/5.0/fr/index.html

– Encyclopédie libre Wikipedia: http://www.wikipedia.org

– Tutoriels de développement Web pour débutants et initiés : http://www.siteduzero.com

Bibliographie 60

http://www.siteduzero.com/

http://www.wikipedia.org/

http://dev.mysql.com/doc/refman/5.0/fr/index.html

http://fr.php.net/manual/fr/

http://examples.adobe.com/flex2/inproduct/sdk/explorer/explorer.html

http://www.adobe.com/fr/products/flex


GlossaireGlossaire— Application Internet Riche / RIA

Une application internet riche, ou RIA pour Rich Internet Application, est un type d'application de nouvelle génération qui possède plusieurs propriétés:

– Elle privilégie le confort utilisateur en offrant une interface plus ergonomique par le biais d'animations et de transitions.

– Elle ne requiert aucune installation de l'utilisateur, ce qui lui permet d'être utilisée sur n'importe quelle machine (à condition cependant, d'avoir le matériel nécessaire).

– Et enfin, propriété la plus importante, le traitement se fait entièrement côté client, en temps réel, en réagissant à des évènements (clics, glisser-déposer...).

Ce qui lui vaut son appellation d'application « riche ».Le terme « Internet » désigne le fait que cette application s'utilise à partir d'un navigateur web, sans aucun besoin de s'installer sur les machines du client.

Ce terme a été introduit par Macromedia en 2002, et fait souvent référence aux applications utilisant les technologies de Macromedia/Adobe (Flash, Flex). Cependant, ce type d'applications est de plus en plus courant, et d'autres technologies viennent rivaliser avec celles d'Adobe. Les exemples les plus courants sont les applications développées avec JavaFX ou Microsoft Silverlight.

— ActionScript

ActionScript (AS) est un langage de programmation destiné à produire des applications Flash. C'est un langage de script qui s'inspire de l'ECMAScript, qui est la standardisation du JavaScript. Au départ, ce langage était destiné à ajouter de l'intéractivité aux animations Flash, en réagissant à des évènements produits par les utilisateurs (clics de boutons, entrée de texte) pour afficher des images ou renvoyer des données.

Cependant, au fil du temps, grâce à l'évolution du web, son utilisation s'est dirigée vers le développement d'applications web en Flash (et plus récemment en Flex), notamment grâce à l'évolution du langage (ActionScript est actuellement à la version 3) qui se tourne vers de la programmation orientée objet (POO) et donc facilitant le développement d'applications. De plus, les technologies actuelles permet à l'ActionScript de communiquer avec les langages côté serveur, comme Java ou PHP, offrant alors une totale synchronisation entre le client et le serveur.

— API

Une API, ou Application Programming Interface, est un ensemble de fonctions ou de classes proposant des services destinés aux développeurs pour simplifier le développement. Ces services

Glossaire 61


peuvent être disponibles sous forme de bibliothèques, exécutables ou plus récemment de services Web, accessibles à partir de pages Web distantes.

— Certificat

Un certificat est une sorte d'identité électronique permettant de vérifier l'authenticité d'une personne utilisant un service grâce à un système de clés publiques et privées.

Le principe: Un utilisateur X propose un service à un groupe bien précis d'utilisateurs. Chaque utilisateur possède sa propre clé publique et sa clé privée pour déchiffrer les messages qui transitent entre eux et X. Cependant, pour s'assurer l'authenticité de ses clients, X fournit alors à chacun un certificat. Les utilisateurs doivent installer ensuite le certificat en s'assurant bien qu'il est validé par « l'autorité de certification » pour l'utilisation du service. Si c'est le cas, ils envoient leur clé publique à X, qui vérifie alors que leur clé est cohérente avec le certificat (généralement par le biais d'un identifiant crypté) par l'autorité de certification. Si c'est le cas, X leur fournit sa clé publique. La transmission entre X et les utilisateurs est alors effectuée. (cf Wikipedia:Certificat).

— Cookie

Un cookie est un fichier texte s'installant sur la machine cliente qui permet de garder en mémoire certaines informations. Généralement, ce sont des informations revenant souvent dans les pages, comme le nom d'utilisateur, l'identifiant de session ou encore le contenu d'un formulaire (pour faciliter la saisie ultérieure par exemple).

Les cookies ont généralement une durée de vie limitée dans le temps, certains expirant à la fermeture de la page (comme les identifiants de session), d'autres au bout d'une certaine période (lors des votes par exemple, pour éviter les doubles votes), d'autres illimités. L'enregistrement des cookies peut être néanmoins désactivé, car ce système de stockage peut être dangereux car il s'installe directement sur les machines du client.

— CSS / Feuilles de style

CSS (Cascading Style Sheet) ou Feuilles de style, sont des fichiers décrivant l'apparence des différents éléments d'une page HTML/XML, séparant le développement des pages HTML/XML du développement du style de la page. De plus, les CSS permettent de décliner l'apparence selon le récepteur: écran d'ordinateur, écran de téléphone portable, synthèse vocale... Selon le type de récepteur, l'apparence de la page sera différent, chose qui n'était pas possible en HTML strict.

Le terme « Cascading » permet en outre d'appliquer les styles en cascade, c'est à dire qu'on peut appliquer un style à un élément strict, tout comme on peut appliquer le style à toute une série d'éléments (d'où le terme de cascade). Par exemple, supposons que l'on veuille colorier tous les liens en rouge. En utilisant de l'HTML strict, on devrait mettre comme propriété de couleur rouge à

Glossaire 62

http://fr.wikipedia.org/wiki/Certificat_%C3%A9lectronique


TOUS les liens de la page. En utilisant le style en cascade, on ne le définit qu'une seule fois, le changement de style s'effectuant en cascade.

La technologie CSS est actuellement à sa troisième version, mais n'est pas encore gérée par tous les navigateurs Web.

— Design Pattern

Un design pattern (ou patron de conception) est un ensemble de pratiques communes pour répondre à un besoin précis dans le développement d'un logiciel. Il définit une manière de développer de façon à répondre à un besoin par la mise en pratique d'une architecture spécialement conçue pour répondre à ce type de besoin, quel que soit le langage utilisé (on reste cependant dans du langage orienté objet). Exemple de design patterns couramment utilisés: Singleton, Adapter, Factory, Command. (cf Wikipedia:Design Patterns).

— E-Commerce

Le e-commerce, ou commerce électronique, désigne l'échange de biens et de services par un réseau électronique comme l'Internet. Le marché du e-commerce est de plus en plus important grâce aux technologies croissantes de l'internet et à la sécurisation des transactions. Il est bien entendu régi par des lois et soumis à des restrictions.

On désigne plusieurs types de commerce, souvent représentés par des acronymes: B2B (Business 2 Business, ou commerçant à commerçant), B2C (commerçant à particulier), C2C (particulier à particulier)...

— Flex

Le Flex est une technologie lancée par Macromedia en 2004, qui a été reprise par Adobe en 2006 lors du rachat de Macromedia. C'est un ensemble d'outils formant un framework de développement d'applications riches en Flash.

Le Flex est basé sur un langage XML de description : le MXML (pour Macromedia XML), qui définit l'affichage et l'agencement des éléments des parties de l'application. D'autre part, l'interactivité avec les utilisateurs s'effectue par le biais d'un langage de script, qui est l'ActionScript, basé sur le standard ECMAScript.

Le kit de développement (SDK) Flex fournit tout un panel de fonctionnalités pour le développement d'applications riches, comme des boutons, des transitions, etc... Le résultat est un fichier SWF qui est un fichier Flash compilé, qui sera intégré dans une page HTML et dont l'affichage est défini par les feuilles de styles CSS. La compilation, elle, s'effectue à partir du Flex Builder, qui est un plugin de développement de l'IDE Eclipse. Cf Wikipedia:Adobe Flex

Glossaire 63

http://fr.wikipedia.org/wiki/Adobe_Flex

http://fr.wikipedia.org/wiki/Design_pattern


— Framework

Un framework est un ensemble d'outils et de fonctions qui favorisent le développement d'applications. Il est généralement accompagné d'un guide d'utilisation ou d'une documentation développeur qui en explicite les principes et qui oriente le développement vers une architecture modulaire.

Un framework est surtout utilisé en programmation objet, mais peut aussi servir pour d'autres types d'applications. Il suffit qu'il fournisse l'architecture à adopter et qu'il découpe le développement en modules, qui peuvent être des classes comme des fichiers.

D'autre part, un framework peut aussi servir d'extension à une architecture logicielle. On distingue en réalité plusieurs types de frameworks:

– Les framework d'infrastructure logicielle, pour développer des systèmes d'exploitation, des interfaces graphiques et des applications logicielles. Par exemple, .NET, Eclipse, J2EE...

– Les framework d'applications, qui fournissent des outils pour orienter le développement d'applications. Par exemple, Ruby On Rails, Flex, Zend Framework, Struts...

– Les framework de communication entre les applications. Exemple: AMF, SOAP, XML-RPC...

– Les framework d'entreprise, qui sont des framework désignés par les entreprises pour le développement de programmes au sein de l'entreprise.

– Et encore bien d'autres, la liste évoluant sans cesse au cours du temps.

— HTML/xHTML/XML

HTML (Hyper Text Markup Language) est un langage de programmation qui définit la structure d'une page web. Il utilise un système de balises pour agencer les éléments sur la page, et qui permet surtout d'insérer plusieurs types de contenus: du texte, des images, mais aussi et surtout des hyperliens, appelés plus communément liens, qui permettent de naviguer entre les pages.

HTML permet aussi de mettre en forme les éléments d'une page, en définissant des propriétés aux éléments, comme la couleur de fond, la taille de la police, etc... ; et peut contenir des références vers des éléments externes agissant sur la page, comme des feuilles de style ou des scripts.

La dernière version de l'HTML est appelée xHTML (pour EXtensible HTML) et s'inspire sur le format XML (Extensible Markup Language). Actuellement, le xHTML est à la version 1.0, mais une version 2 est en cours pour répondre plus précisément aux attentes du « Web 2.0 ».

Le XML est aussi un langage balisé, mais qui a la particularité d'être facilement extensible du fait qu'on peut définir ses propres balises, à moins de respecter un schéma précis.

— HTTP/GET/POST

HTTP, pour Hyper Text Transfer Protocol, est un protocole de communication client-serveur développé pour la transmission des pages Web. Ce protocole est utilisé pour la communication entre les clients HTTP, comme les navigateurs web, et les serveurs HTTP, comme par exemple Apache, pour envoyer et recevoir les pages web.

Glossaire 64


La communication se fait en deux phases:

1) L'envoi d'une requête, c'est à dire que le client HTTP envoie une requête HTTP au serveur spécifiant l'action à effectuer. Parmi ces actions, on reconnaît les requêtes :

– GET: C'est l'action utilisée pour demander une ressource au serveur. Elle ne modifie pas la ressource et peut être répétée sans effet. Par exemple, l'entrée d'une URL dans la barre d'adresse envoie une requête GET au serveur avec comme paramètre l'URL entrée.

– POST: C'est l'action utilisée pour envoyer des données sur le serveur. Cette action est susceptible de modifier la page, puisque les données sont ajoutées sur le serveur. Cette requête est par exemple envoyée lors de la soumission d'un formulaire, avec en paramètres les données contenues dans les champs du formulaire.

2) La réception de la réponse du serveur, c'est à dire que le serveur envoie une réponse HTTP au client (par exemple, pour une requête GET, le code HTML de la page avec les méta données). Le client n'a plus qu'a traiter la réponse, par exemple, en affichant la page Web dans le navigateur.

Le protocole HTTP est actuellement à la version 1.1, et des langages serveur comme PHP ou Java exploitent ce protocole pour la communication avec les pages web. Par exemple PHP peut accéder au contenu des requêtes HTTP GET et POST grâce aux variables superglobales $_GET et $_POST.

Par exemple, supposons que l'on veuille sauvegarder les données d'un formulaire dans une base de données. On peut ainsi accéder au contenu du formulaire grâce à la variable $_POST, qui contient les valeurs des champs par $_POST['nom_champ'].

— IDE

IDE, pour Integrated Development Environment, est un environnement créé pour le développement de logiciels en fournissant un ensemble d'outils utiles pour le développement. Un IDE regroupe généralement un éditeur de texte, un compilateur, un interpréteur (dans le cas de langages interprétés comme le Javascript) et quelquefois un debugger. De plus, la majorité des IDE proposent aujourd'hui une coloration syntaxique du langage utilisé, une indentation automatique, la complétion de termes fréquemment utilisés comme les mots clés du langage, ou encore la visualisation des erreurs de compilation.

Parmi les IDE les plus connus, on peut citer : GNU Emacs, Visual Studio, Eclipse, NetBeans...

— Javascript

Le Javascript est un langage de script côté client qui permet d'ajouter de l'interactivité aux pages web. C'est un langage orienté objet qui est une implémentation du standard ECMAScript et qui s'inspire du Java. Généralement, le Javascript sert a ajouter des fonctionnalités dynamiques au HTML, comme la vérification temps réel des données d'un formulaire, l'affichage et le masquage de certains éléments de la page dynamiquement, etc...

Glossaire 65


— Newsletter

Une newsletter est un bulletin d'information envoyé périodiquement à des utilisateurs d'un service envoyé de manière périodique à une liste de diffusion. Ce bulletin comporte différents types d'informations relatifs au service, comme par exemple les mises à jour du service, ou encore les nouveaux produits disponibles dans un site de vente...

— PHP

PHP (acronyme récursif pour Hypertext Preprocessor), est un langage de scripts libre principalement utilisé pour le développement de pages Web dynamiques côté serveur (HTTP), mais pouvant également fonctionner comme n'importe langage interprété, en exécutant les programmes en ligne de commande. C'est un langage impératif mais qui possède depuis la version 5 les fonctionnalités de la programmation orientée objet.

Le traitement des pages PHP est le suivant: Lorsqu'un client (navigateur) demande une page PHP, le code PHP contenu dans cette page est d'abord interprété (donc sans compilation) par le serveur (car c'est un langage côté serveur) avant toute réponse du serveur. Pour cela, la page doit obligatoirement avoir une extension php, le serveur saura alors automatiquement que cette page aura besoin d'être interprétée par l'exécutable PHP avant d'être renvoyée au client.

Ce mode de traitement fait du PHP un langage énormément utilisé dans l'écriture d'applications web, du fait de sa souplesse et de sa facilité d'utilisation, notamment parce qu'il s'interface avec différents langages de présentation, comme le HTML et les bases de données, notamment MySQL. De plus, le langage étant libre, de nombreuses extensions existent pour proposer des modules, comme le parsing XML ou la manipulation d'images, ou encore la cryptographie.

— SSII

Une SSII (Société de Services et d'Ingénierie Informatique) est une société proposant des services qui vont de la conception d'un cahier des charges à la mise en place de solutions combinant applications, matériel et suivi clientèle. Les différents métiers d'une SSII peuvent être: conseiller, concevoir, déployer, réaliser, maintenir, ou former.

— SOA

Une architecture orientée services, ou SOA pour Service Oriented Architecture, est une architecture qui organise le système d'information en services, ou métiers, dans le respect du « couplage faible », c'est à dire que les services ont une faible dépendance entre eux et peuvent être facilement ajoutés ou supprimés.

Glossaire 66


Le service est une action exécutée par un « fournisseur » (ou « producteur ») pour un « client » (ou « consommateur »). Cependant l'interaction entre consommateur et producteur est faite par le biais d'un médiateur responsable de la mise en relation des composants. Le service peut s'exécuter sur n'importe quelle plateforme quel que soit le langage utilisé, et doit être autonome et respecter un certain nombre de « contrats » définis par des interfaces.

Les architectures SOA ont été popularisées par l'apparition des services Web pour le ecommerce, facilitées par des frameworks de conception de services comme la plateforme .NET ou J2EE. Cf Wikipedia:Service Oriented Architecture.

— SQL/MySQL

SQL, pour Structured Query Language, est un pseudo-langage de requêtes destiné à la manipulation des données d'une base de données relationnelle. Les données sont organisées dans des Tables, qui possèdent des champs ou attributs, ce qui lui vaut son nom de langage « structuré ».

Le langage est composé de plusieurs couches, à savoir

– la définition des données, qui s'occupe de l'ajout, la mise à jour et la suppression des données;

– la manipulation de données, qui s'occupe de la récupération des données;– un contrôle de transactions, pour regrouper les requêtes en transactions;– une gestion des droits d'administration des données.

Sans entrer dans les détails, ces couches sont les couches obligatoires pour la gestion de bases de données. Cependant, au fil du temps, le langage se développe en proposant bon nombre de modules comme la gestion de procédures, la persistance des données, etc... Il faut savoir que SQL n'est pas le seul langage de requêtes, il en existe d'autres, comme Hibernate, LinQ, XQuery...

MySQL est un système de gestion de base de données (SGBD) utilisé généralement pour le développement d'applications web utilisant les bases de données. Il est développé par Sun Microsystems et fait partie des SGBD les plus utilisés au monde. Il est fourni comme SGBD dans des packages de développement Web comme WAMP ou LAMP.

Glossaire 67

http://en.wikipedia.org/wiki/Service-oriented_architecture


AnnexesAnnexes

Annexes 68


Documentation sur l'entreprise1) Projets relatifs à Tangane

1: Ubiplanet

Ubiplanet est le tout premier projet de Tangane, qui est un réseau social fait entièrement en Flash. Il propose aux utilisateurs d'afficher leurs centres d'intérêts, de mettre en ligne leur photos, etc... en leur fournissant une interface dynamique. En outre, elle propose un certain nombre de services comme une messagerie instantanée, un album de photos, etc... le tout en Flash faisant d'elle une application confortable pour les utilisateurs et qui ne nécessite aucune installation.

Site web : http://www.ubiplanet.com/

2: Ooshop

Ooshop est un site de vente virtuel (e-commerce) spécialisé dans la vente de produits alimentaires à domicile, une sorte de supermarché virtuel. Ce site appartient au groupe Carrefour et a été dirigé par Mr Barraud François pendant 4 ans. Le site propose aux consommateurs d'acheter leurs produits alimentaires directement sur le site de manière relativement aisée, grâce aux pages entièrement dynamiques, et la livraison se fait le lendemain à la première heure. Fin 2007, Ooshop devient le premier supermarché en ligne en termes de fréquentation.

2) Chiffre d'affaires de l'entreprise

La société Tangane est une entreprise de type SAS (Société par Actions Simplifiées) dont le siège social se situe à Villeurbanne (et plus particulièrement au 20, rue Louis Guérin).

Son capital s’élève à 82 250 euros et son chiffre d’affaire est en évolution ce que l’on voit par le graphique ci-dessous :

Chiffre d'affaires de l'entreprise 69

http://www.ubiplanet.com/


Annexe I.2.1: Évolution du chiffre d'affaires de Tangane

On peut voir de par ce schéma de l’évolution de cette société. En effet, nous voyons qu’en 2007, pour son envol, elle débute avec un chiffre d’affaire de 400 000 euros. Elle poursuit l’année suivante avec une augmentation de près de 1 500 000 euros ce qui marque une nette progression (augmentation de près de 4%). La société commence donc à se faire une place et à se faire connaître. Elle prévoit pour l’année 2009, un chiffre d’affaire de 5 000 000 d’euros, ce qui montre bien son engouement à vouloir développer ses actions.

Chiffre d'affaires de l'entreprise 70

Chiffres d'Affaires de TANGANE

0

1 000 000

2 000 000

3 000 000

4 000 000

5 000 000

6 000 000

2007 2008 2009

Années

Chiff

res

d'Af

fair

es (e

n eu

ros)


Documentation sur le matériel/logiciels

A) Eclipse

Eclipse est un IDE (Integrated Development Environment) proposant un panel de fonctionnalités pour aider au développement d'applications comme une coloration syntaxique, un correcteur syntaxique, l'accès direct à la documentation des fonctions, la visualisation de l'arborescence des fichiers des projets, l'autocomplétion, et bien plus encore.

Cet environnement était à la base conçu pour le développement de code source en Java, mais grand nombre de développeurs ont créé des « plugins » pour bénéficier des fonctionnalités d'Eclipse pour le développement sous d'autres langages, notamment le Flex et le PHP. Il tourne aussi bien sous Windows que sous Linux, et est actuellement à la version 3.4 de son développement.

Page web: http:// www.eclipse.org

Liste des projets de plugins eclipse : http://www.eclipse.org/projects/listofprojects.php

Une capture d'écran de l'IDE est disponible page suivante :

Documentation sur le matériel/logiciels 71

http://www.eclipse.org/projects/listofprojects.php

http://www.eclipse.org/

http://www.eclipse.org/

Annexe II.1: Fenêtre de l'éditeur d'Eclipse


B) SVN

SVN, ou Subversion, est un système de contrôle de versions d'un projet. Cet outil permet de découper les phases de développement d'un projet en versions, en gardant en mémoire toutes les versions du projet afin de déterminer exactement ce qui a été fait à une période donnée du projet, et de récupérer les données sauvegardées à un instant précis du développement.

Cet outil fournit aussi de nombreuses fonctionnalités pour le travail en équipe, comme la visualisation du travail effectué par un membre à une version donnée du projet, la mise à jour automatique de toutes les sources du projet lors d'une nouvelle version, la possibilité de gérer les conflits (partie de code d'un même fichier différente entre deux membres de l'équipe), etc... permettant ainsi à l'équipe d'être synchrone sur le développement.

Il existe plusieurs clients SVN disponibles sur plusieurs systèmes d'exploitation. Sous Windows, on peut trouver TortoiseSVN, qui est l'outil utilisé par Tangane pour le développement des projets. Ce client SVN est très complet et implémente une interface graphique pour chacune des fonctionnalités de SVN pour un usage simple et rapide. En outre, il permet de repérer automatiquement les fichiers à « commit », fournit des outils graphiques de résolution de conflits, et bien d'autres fonctionnalités graphiques.


Annexe II.2: TortoiseSVN: Outil de visualisation des logs

Page web: http://subversion.tigris.org

Page web de TortoiseSVN : http://tortoisesvn.net/

C) Firebug

Firebug est une extension de Firefox qui permet de simplifier énormément le développement de pages HTML et de feuilles de style CSS. Il permet, entre autres, de voir pour un élément donné d'une page, les propriétés de style qui lui sont affectées, de modifier la valeur de ces propriétés afin d'avoir un aperçu en temps réel, de voir le DOM de la page (c'est à dire la disposition des éléments sous forme d'arborescence), etc...

Cet extension permet surtout de modifier les feuilles de style appliquées à une page, sans pour autant devoir recharger la page grâce à l'aperçu temps réel, aidant considérablement dans le développement des feuilles de style. Il possède en plus un debugger Javascript.

Page web : http://getfirebug.com/

D) Charles Web Proxy

L'outil Charles Web Proxy est un outil qui trace les requêtes HTTP envoyées au navigateur et qui affiche leur contenu. Il permet en outre de visualiser le contenu des requêtes GET ou POST envoyées au serveur, la valeur des cookies, les liens externes d'une page, la valeur de la réponse renvoyée par le serveur, etc..

De plus, cet outil permet surtout de tracer les messages AMF (messages qui transitent entre la partie Flex et la partie serveur) de requête et de réponse, facilitant ainsi le déboguage d'applications Flex concernant la communication client-serveur.

Annexe II.3: Fenêtre de Firebug

http://getfirebug.com/

http://tortoisesvn.net/

http://subversion.tigris.org/


Page web : http:// www.charlesproxy.com/

E) EMS SQL Manager

EMS SQL Manager est un IDE de gestion de bases de données SQL. C'est une interface graphique offrant plusieurs fonctionnalités facilitant la gestion de bases de données, comme la coloration syntaxique du code SQL, la création de tables avec des formulaires, la gestion d'erreurs, des outils d'importation et d'exportation des bases, etc...

Cet outil est très utile pour le développement d'applications utilisant les bases de données. Les opérations communes comme la création de tables, de procédures, etc... sont facilitées par des formulaires, l'écriture du code SQL bénéficie de la coloration syntaxique et de l'autocomplétion, etc...

Cet outil est payant et est actuellement à la version 2007, proposé pour plusieurs systèmes de gestion de base de données, comme MySQL et PostGreSQL.


Annexe II.4: Charles Web Proxy: Visualisation du contenu d'un AMF

http://www.charlesproxy.com/

http://www.charlesproxy.com/


Page web : http://sqlmanager.net/fr/products/mysql/manager

Aperçu de la fenêtre de l'éditeur :


Annexe II.5: EMS SQL Manager: Editeur SQL

http://sqlmanager.net/fr/products/mysql/manager

Résultats bruts1) Captures d'écran

1: Développement de l'interface d'administration de Lovelee

Annexe III.1.1.1: Module de visualisation des utilisateurs

Annexe III.1.1.2: Module de visualisation des annonces non validées

Annexe III.1.1.3: Module de gestion des photos

Annexe III.1.1.4: Module de visualisation du profil

Annexe III.1.1.5: Module de visualisation des abus

Annexe III.1.1.6: Module de gestion des sondages

Annexe III.1.1.7: Module de visualisation des "scammeuses"

2: Développement de l'application principale de Lovelee

Annexe III.1.2.1: Page d'accueil de Lovelee

Annexe III.1.2.2: Page d'accueil de Lovelee

Annexe III.1.2.3: Blacklist de Lovelee

Annexe III.1.2.4: Options de choix d'alertes

Annexe III.1.2.5: Fiche astrologique d'un utilisateur

Annexe III.1.2.6: Recherche de profils

Annexe III.1.2.7: Choix des formules d'abonnement

3: Intégration des pages Marie-Claire et Cosmopolitan:


Captures d'écran 94

Annexe III.1.3.1: Lovelee sur Marie-Claire


Captures d'écran 95

Annexe III.1.3.2: Lovelee sur Cosmopolitan

4: Mise en place d'une solution de paiement avec SOGENACTIF

Annexe III.1.4.1: Page call_request affichant les moyens de paiement générés par le binaire request

Annexe III.1.4.2: Page d'entrée des coordonnées bancaires avec template personnalisé

Annexe III.1.4.3: Page call_response affichant les données de la réponse de SOGENACTIF


2) Documentations utilisateur

1: Documentation pour l'utilisation de l'API de modération

Documentations utilisateur 100

1) Récupération de flux XML

Afin de faciliter la modération et éviter tout problème d'accès distant à une base de données cliente, les services de modération proposent de réaliser la modération de l'application par la réception de flux XML.

a) Type de flux XML

Trois types de flux XML sont souhaités: – Données en attente: Données postées sur l'application qui n'ont pas encore été modérées– Données validées: Données validées par la modération.– Données rejetées: Données rejetées par la modération.

Le type de flux XML demandé est spécifié par un paramètre « st » envoyé en paramètre GET dans l'URL de la page de l'API.

Ce paramètre « st » peut prendre les valeurs 1, 2 ou 3 pour « en attente, validées, rejetées ». Pour les données concernant les utilisateurs, les valeurs spéciales 4, 5 et 6 renvoient le flux XML des utilisateurs ayant leur pseudo banni, leur email banni, ou les deux. Si ces valeurs spéciales sont passées pour la modération des données autres que les utilisateurs, une erreur est renvoyée.

Les données récupérées sont à fournir triées par date de modification :– décroissante (le plus récent en premier) pour les données validées ou refusées– croissante pour les données en attente.

b) Type de données

L'API doit pouvoir modérer au minimum trois types de données de l'application Lovelee, qui sont :– Les utilisateurs de l'application, ou les membres– Les annonces postées par les utilisateurs– Les photos envoyées par les utilisateurs

Aussi, pour faciliter la modération des utilisateurs, un type de données supplémentaire peut être demandé, qui sont les alertes envoyées par les utilisateurs.

Le type de données est spécifié par un paramètre « typemoder » envoyé dans l'URL de la page en paramètre GET. Il peut prendre les valeurs 1, 2 ou 3 pour les utilisateurs, les annonces et les photos (4 pour les alertes).

c) Date de modification

Pour limiter le nombre d'items dans le flux XML retourné, le service de modération peut spécifier

Processus d'utilisation de l'API pour les services de modération de Lovelee


un intervalle de temps, qui ne retournera que les données dont la date de dernière modification est contenue dans cet intervalle.

Ces intervalles sont spécifiées par les paramètres « tbeg » et « tend » passées en paramètres à l'URL. Les valeurs de ces paramètres sont des timestamps, et la valeur de tbeg doit être inférieure à celle de tend.

Exemple de réquisition des annonces non validées en 24 heures à une date donnée :http://api.lovelee.com/moder_xml.php?st=1&typemoder=2&tbeg=1160949600&tend=1161096836

d) XML retourné

Le XML retourné permettra d'afficher les éléments à modérer dans l'application externe des services de modération. La structure des items est extensible et on doit pouvoir ajouter ou retirer des champs facilement.

– Pour les utilisateurs:

<itemModer><Id>Identifiant utilisateur</Id><PseudoPoster>Pseudonyme de l'utilisateur</PseudoPoster><EmailPoster>Email de l'utilisateur</EmailPoster><AgePoster>Age de l'utilisateur</AgePoster><SexPoster>Sexe de l'utilisateur</SexPoster><SexOtherPoster>Sexe recherché par l'utilisateur</SexOtherPoster><DateCreate>Date de création/dernière modification</DateCreate>

</itemModer>

– Pour les annonces :

<itemModer><Id>Identifiant annonce</Id><IdPoster>Identifiant de l'utilisateur postant l'annonce</IdPoster><PseudoPoster>Pseudonyme de l'utilisateur postant l'annonce</PseudoPoster><EmailPoster>Email de l'utilisateur postant l'annonce</EmailPoster><AgePoster>Age de l'utilisateur postant l'annonce</AgePoster><SexPoster>Sexe de l'utilisateur postant l'annonce</SexPoster><SexOtherPoster>Sexe recherché par l'utilisateur postant l'annonce</SexOtherPoster><BodyText>Texte de l'annonce</BodyText><DateCreate>Date de création/dernière modification</DateCreate>

</itemModer>

– Pour les photos :

<itemModer><Id>Identifiant media</Id><IdPoster>Identifiant de l'utilisateur postant le media</IdPoster>


http://api.lovelee.com/moder_xml.php?st=1&typemoder=2&tbeg=1160949600&tend=1161096836


<PseudoPoster>Pseudonyme de l'utilisateur postant le media</PseudoPoster><EmailPoster>Email de l'utilisateur postant le media</EmailPoster><AgePoster>Age de l'utilisateur postant le media</AgePoster><SexPoster>Sexe de l'utilisateur postant le media</SexPoster><SexOtherPoster>Sexe recherché par l'utilisateur postant le media</SexOtherPoster><UrlThumb>URL de la miniature du media</UrlThumb><UrlImg>URL du media</UrlImg><WidthImg>Largeur de l'image</WidthImg><HeightImg>Hauteur de l'image</HeightImg><DateCreate>Date de création/dernière modification</DateCreate>

</itemModer>

– Pour les alertes :

<itemModer><Id>Identifiant de l'alerte</Id><IdPoster>Identifiant de l'alerteur</IdPoster><PseudoPoster>Pseudonyme de l'alerteur</PseudoPoster><EmailPoster>Email de l'alerteur</EmailPoster><AgePoster>Age de l'alerteur</AgePoster><SexPoster>Sexe de l'alerteur</SexPoster><SexOtherPoster>Sexe recherché par l'alerteur</SexOtherPoster><IdTarget>Identifiant de la cible de l'alerte</IdTarget><PseudoTarget>Pseudonyme de la cible de l'alerte</PseudoTarget><EmailTarget>Email de la cible de l'alerte</EmailTarget><AgeTarget>Age de la cible de l'alerte</AgeTarge><SexTarget>Sexe de la cible de l'alerte</SexTarget><SexOtherTarget>Sexe recherché par la cible de l'alerte</SexOtherTarget><BodyText>Contenu de l'alerte</BodyText><DateCreate>Date de création/dernière modification</DateCreate>

</itemModer>



2) Actions de modération

Afin de ne pas utiliser de chaîne de connexion à la base de données distantes pour mettre à jour les codes de validation, les services de modération procèdent par l'envoi d'une chaîne de caractère spécifiant toutes les actions à effectuer, qui sera passée par paramètre POST à la page de l'API.

Cette page doit découper la chaîne de caractère et effectuer les actions demandées comme la validation ou le rejet. La chaîne de caractère est passée en POST à la page, car elle est générée par le remplissage d'un formulaire de l'interface externe de modération. Le nom du champ du formulaire contenant la chaîne est « tabPost ».

Dans cette chaîne: – Le séparateur entre les actions à effectuer est le pipe, ou « | » .– Le séparateur des paramètres est la virgule « , »

a) Format des actions

Une action à effectuer est une suite de paramètres séparés par une virgule et exprimés dans un ordre précis. Si un des paramètres est omis ou a une valeur invalide, un code d'erreur doit être renvoyé.

Ex: « 1,1234,3,0 » est une action. Pour la définition de cette action, voir la suite du document.

b) Paramètres obligatoires et semi-obligatoires.

Certains paramètres sont obligatoires quelle que soit la nature de l'action demandée. D'autres ne doivent être renseignés que selon la valeur de certains autres. Par exemple, les paramètres spécifiant la largeur et la hauteur d'une image ne doivent être renseignés que si l'action concerne la modération d'images.

Les paramètres obligatoires sont, dans l'ordre :– « typemoder », ou le type de données à modérer. Il peut prendre trois valeurs: 1, 2 ou 3

pour les utilisateurs, les annonces et les photos. Les alertes ne sont pas traitées ici.– « idItem », l'identifiant de la donnée. Ca peut être l'id de l'utilisateur, de la photo ou de

l'annonce.– « st », ou le statut à affecter. Il peut prendre soit les trois valeurs : 1, 2 ou 3 représentant

respectivement les statuts « en attente », « validation » ou « rejet »; soit, si typemoder vaut 1 (utilisateurs), les valeurs 4, 5 et 6 pour « ban pseudo », « ban email », « ban pseudo email ».

– « level » : le niveau affecté à l'utilisateur. Ce paramètre est un peu spécial, c'est lui qui permet à la modération d'affecter le statut de « VIP » ou de « Non recommandable » (cf doc de Lovelee). Cependant, ce statut ne doit prendre de valeur que si le type de données concerne les annonces ou les photos, car en général ce sont elles qui permettent d'affecter un tel statut à un utilisateur. Ce paramètre doit donc valoir 0 dans le cas de modération des utilisateurs, et une valeur de 1 à 4 pour la modération des annonces et photos, représentant respectivement les statuts « Non recommandable », « Normal », « VIP » et « Super VIP ».



Les paramètres semi-obligatoires sont les paramètres ne devant être renseignés que si un des paramètres obligatoires à une valeur précise. Dans le cas actuel, ils ne doivent être renseignés que si le type de données à modérer concerne les photos, c'est à dire typemoder à 3 :Dans le cas des photos, la modération peut procéder à un recadrage des photos. Leur interface peut donc leur fournir quatre paramètres qui sont:

– les coordonnées (x,y) du point supérieur gauche du cadre de recadrage.– La largeur et la hauteur du cadre de recadrage.–

Ces paramètres doivent donc être passés dans l'ordre :– « x », l'abscisse du point supérieur gauche– « y », l'ordonnée du point supérieur gauche– « width », la largeur de la photo recadrée– « height », la hauteur de la photo recadrée.

Ces paramètres sont cependant obligatoires pour la modération des photos. Si un des paramètres n'est pas renseigné ou invalide, l'action ne se réalisera pas.

Exemples :

« 2,10,2,1|2,12,3,3|3,15,2,3,0,0,100,100|1,14,3,0|1,15,6,0 »

Cette chaîne comporte 5 actions : – « 2, 10, 2, 1 » = Validation de l'annonce n°10 et mise en statut « Non recommandable » de

l'utilisateur concerné.– « 2, 12, 3, 0 » = Refus de l'annonce n°12 et mise en VIP de l'utilisateur concerné.– « 3, 15, 2, 3 » = Validation de la photo n°15 et mise en VIP de l'utilisateur concerné.

« 0, 0, 100, 100 » = redimensionnement à (0, 0, 100, 100) (x, y, largeur, hauteur). – « 1,14,3,0 » = Suppression de l'utilisateur n°14.– « 1,15,6,0 » = Ban de l'utilisateur n°15



2: Documentation pour l'utilisation de l'API Subscription



Étude de l'API Subscription

1) Étude globale du système

Dans ce nouveau système, on n'est plus dans la phase de paiement strict tel qu'on l'avait avec l'ancien API. Là on passe à un système d'abonnements. Ce qui veut dire que ce n'est plus le consommateur qui va débiter son compte mais le commerçant qui va le lui débiter à des intervalles qu'il aura définis (et dont le consommateur aura connaissance).Pour cela, tout ce que le consommateur a à faire, c'est d'entrer son numéro de carte bleue afin que SOGENACTIF identifie si le compte existe, et renvoie alors tout un tas d'informations au commerçant pour que celui-ci procède au prélèvement.

Ce qui est fait:− L'utilisateur clique sur un abonnement. Il est redirigé sur une page appelée « call_recordabo »

(on peut changer les noms). Sur cette page, là où avant il y avait les types de carte, ici il n'y a qu'un seul bouton qui est « S'abonner » (bouton qu'on peut créer soi même).

− L'utilisateur clique sur ce bouton. Il est alors redirigé vers la page de SIPS d'abonnement. Celle ci est un peu différente de celle qui était proposée dans l'API Sale: Tout d'abord, les choix de moyens de paiement sont proposés sur cette page et dépendent de la valeur qu'on a mise dans call_recordabo sur les moyens de paiement (l'ordre, les cartes autorisées, etc).Ensuite, il est demandé a l'utilisateur de fournir ses coordonnées: Nom, Prénom, Adresse, Téléphone et Email. Ces champs peuvent ne pas être remplis, tout dépend de l'utilisation qu'on en fait, pour Lovelee par exemple on ne les stocke pas car ils sont déjà stockés dans la table User, mais on pourrait le faire pour garder des traces de la transaction, etc...Et enfin bien sur les informations de carte: numéro, expiration, CVV...

− Une fois qu'il a remplis ces informations, SOGENACTIF vérifie l'existence du compte, et redirige alors l'utilisateur vers la page « call_responseabo », qui va enregistrer sa transaction en base et ajoute dans la table usr_ofr la souscription du membre.

C'est donc assez similaire a l'ancien API, sauf que là où ça diffère vraiment, c'est la suite:

En effet à l'issue de la transaction un numéro d'abonné est fourni par SOGENACTIF. Ce numéro est très important c'est lui qui va identifier l'utilisateur auprès de la base d'abonnés de SOGENACTIF, c'est donc grâce à lui qu'on va pouvoir (enfin le commerçant va pouvoir) débiter le membre chaque mois de la somme due.

Cela se fait grâce a un système de transfert de fichier FTP: Un fichier « requête » créé par le commerçant contient tous les numéros d'abonnés a prélever, ainsi que la somme due. Ce fichier doit obéir à un format spécifique dont je parlerai plus en détail plus loin. Le (ou les car on peut en envoyer plusieurs, en respectant la aussi une règle dont je parlerai plus loin) fichier est alors envoyé sur le serveur FTP de SOGENACTIF, et chaque jour à une heure fixe ces fichiers sont traités et un (ou plusieurs) fichier « réponse » est alors déposé par SOGENACTIF sur le FTP du commerçant qui contient des codes réponse sur chacun des abonnés entrés pour le prélèvement. Ceux dont le code réponse est valide seront prélevés et crédités sur le compte du commerçant.


Enfin il faut savoir qu'il existe aussi une procédure de modification d'abonnement pour les utilisateurs, qui peuvent changer leur abonnement (si le commerçant le permet) ou tout simplement changer leur coordonnées pour l'abonnement en cours.

2) Intégration de l'API

L'API SUBSCRIPTION est similaire à l'ancien API déjà présent. L'API comporte plusieurs fichiers nécessaires à son fonctionnement:− Binaire recordabo: C'est le binaire qui va s'occuper de créer le formulaire de création d'un

abonnement de la même manière que le binaire request.− Binaire responseabo: Binaire qui va s'occuper de générer la réponse à la requête à partir des

données cryptées fournies par SIPS. Même fonctionnement que response.− Binaire autoresponseabo: C'est le binaire qui va s'occuper de générer la réponse automatique

comme le fait autoresponse.− Certif.fr.<numero_certificat>: C'est le certificat nécessaire à l'identification du commerçant dont

le numéro est fourni.− Parmcom.<numero_certificat>: Ce sont les paramètres obligatoires des binaires de requête dans

le cas où ceux ci n'étaient pas fournis dans les pages PHP.− Parmcom.sogenactif: Fichier contenant les paramètres d'affichage personnalisé des pages de

paiement SOGENACTIF dans le cas où ceux ci n'étaient pas fournis dans les pages PHP.− Pathfile: Fichier contenant les chemins des différents fichiers nécessaires au fonctionnement de

l'API: certificat, parmcom, logos...− Les logos: bouton de création d'abonnement et de modification d'abonnement.

Le certificat, parmcom et pathfile sont déjà sur le serveur pour l'API Sale, par contre je ne sais pas si il faut un nouveau certificat ou non. Par contre il faudra les modifier pour les adapter à l'API subscription (pour le return_url, etc...)

Pour utiliser l'API, on doit donc faire appel à chacun des binaires en leur passant un certain nombre de paramètres. Cela se fait de la même manière qu'avec call_request, donc se référer à cette page pour plus de détails.Le binaire va alors générer un formulaire redirigeant vers la page SIPS dans le cas de recordabo ou manageabo, ou un tableau de données dans le cas de responseabo ou autoresponseabo. A nous alors de savoir transmettre et recueillir les données.

− L'abonnement: recordabo

L'appel au binaire se fera dans la page call_recordabo. Dans cette page, on spécifie quels paramètres on va envoyer au binaire pour que celui ci génère le formulaire redirigeant vers SIPS avec les paramètres nécessaires à la transaction.

Voici un listing des paramètres pouvant être renseignés:− merchant_id : Obligatoire: code du commerçant− merchant_country: Obligatoire: Pays du commerçant (fr)− currency_code: Obligatoire: Code de devise (978 pour l'euro)− pathfile: Obligatoire: Chemin du pathfile− card_list: Obligatoire: Liste des moyens de paiement a afficher sur la page SIPS (l'ordre et la

disposition peuvent être changés)− sub_normal_return_url: Obligatoire: L'url de retour en cas de transaction réussie.− sub_cancel_return_url: Obligatoire: l'url de retour en cas d'annulation ou d'échec− sub_automatic_response_url: Facultatif: l'URL appelant call_autoresponseabo.


− sub_type: Obligatoire: 0: L'utilisateur n'est pas débité à la souscription; 1: L'utilisateur est débité d'un montant spécifié par sub_amount qui devient alors obligatoire.

− sub_amount: Montant devant être débité à la souscription. Si sub_type vaut 0 ce champ est ignoré, si il vaut 1 il est obligatoire.

Facultatifs:− language: Langue affichée par SIPS (défaut: FR)− transaction_id: le numero de transaction. Ce numéro doit être unique, si il n'est pas renseigné,

SOGENACTIF en génèrera un avec l'heure de souscription.− order_id: Numéro de commande.− Caddie: contient une chaine de 4096 caractères max qui sera passée sans modification de la

requête a la réponse. On pourrait stocker l'user_id ici.− Paramètres d'affichage personnalisé de la page SIPS: on peut changer le background, le logo

commerçant, la couleur du texte, etc... on peut aussi renseigner le champ templatefile pour prendre en compte toutes les modifications directement dans un fichier template.

− Informations sur les coordonnées de l'utilisateur: Statut Civil, Nom, Prénom, Adresse, Email, Téléphone, Descriptions de l'abonnement, etc... se référer au dictionnaire de données. Si ces informations sont renseignés les champs seront préremplis sur la page de SIPS.

Ces informations seront alors cryptées par le binaire et transmis a SOGENACTIF pour l'affichage de la page et le traitement. Ensuite SOGENACTIF générera une réponse au format crypté, qu'on devra décrypter avec responseabo.

− La réponse: responseabo et autoresponseabo

La réponse générée par le binaire est sous forme d'un tableau dont on peut extraire facilement les données. Les informations fournies sont: − merchant_id: Identifiant commerçant− transaction_id: Le numéro de transaction− sub_subscriber_id: Le numéro d'abonné généré par SOGENACTIF. Ce numéro est très

important pour la suite.− transmission_date: Date de transmission de la souscription− response_code: code de réponse de SIPS− bank_response_code: code de réponse de la banque− CVV_response_code: code de réponse du CVV.− card_number, card_validity: contient les 4 premiers chiffres du numero de CB et la date

d'expiration de la carte− sub_payment_mean: moyen de paiement de l'utilisateur− sub_date, sub_time: Heure et Date de la souscription− caddie: Contient le contenu de la chaine telle que renseignée dans la requête− Informations sur l'utilisateur: Nom, Prénom, etc...

Avec ces informations, on peut ainsi stocker en base toutes les informations sur la transaction, la date, le type d'abonnement, l'utilisateur etc... On aurait alors deux tables différentes: une table « Souscription » qui contiendraient les infos sur la souscription, et la table « Transaction » qui contient les infos sur les transactions, c'est a dire les prélèvements.

Dans la table souscription on enregistrerait donc: la date d'abonnement, le numero d'abonné, le numero d'user, la réponse de SIPS ou de la banque, la durée de l'abonnement, le montant de l'abonnement (périodique)...



Dans la table de transaction on enregistrerait par contre: la date de la transaction (du prélèvement), le numero de l'abonné prélevé, le montant prélevé, le numero de la souscription...

− Gestion de l'abonnement: manageabo

Cette étape peut être autorisée pour les clients pour la modification de leur abonnement, ça peut être pour visualiser leur abonnement, modifier leurs coordonnées, ou annuler leur abonnement; on peut leur demander un mot de passe pour le faire, pour renforcer la sécurité.Le fonctionnement se fait de la même manière que pour l'inscription, à l'exception de quelques paramètres :− sub_subscription_id: le numéro de l'abonné. Il est forcément nécessaire à la modification

d'abonnements.− sub_operation_code: un numéro qui désigne l'action que SOGENACTIF doit faire:

2 : visualisation des informations de l’abonné3 : mise à jour des informations de l’abonné4 : suppression d’un abonnement5 : recherche du mot de passe6 : mise à jour des informations carte7 : modification du mot de passe

Ce choix peut être fait a partir d'une liste déroulante dans le call_manageabo, et à l'issue de ce choix, redirige vers la page de SIPS correspondante. Dans ce cas le champ data doit être mis à « NO_LOGIN_PAGE » pour éviter d'afficher la liste déroulante sur SIPS.

Remarque: Cette page n'est pas faite pour que le commerçant gère les abonnements de ses utilisateurs. Ceci se fait à partir de la méthode de transfert FTP. manageabo est là uniquement pour que les utilisateurs modifient eux mêmes leurs abonnements.

− Notes concernant la modification des pages:

SOGENACTIF donne le droit au commerçant de personnaliser le formulaire généré par recordabo, manageabo ou les pages SIPS. Pour cela il suffit de remplir certains des champs et de les passer en paramètres aux binaires:− merchant_language: la langue d'affichage des informations− bgcolor: couleur d'arrière plan de la page SIPS− textcolor: couleur de police de la page SIPS− receipt_complement: Texte en plus affiché lors du récapitulatif de la transaction sur SIPS− advert: image de la bannière− logo_id: logo affiché en haut à gauche− logo_id2: logo affiché en haut à droite− background_id: image d'arrière plan− submit_logo, cancel_logo et return_logo: images des boutons de soumission, annulation et de

retour sur les pages SIPS.− Templatefile: utilisation d'un template pour les pages SIPS. Si on utilise un template les

précédents champs seront ignorés.− Data: data est un masque de bits qui permettra de choisir certaines informations de SIPS a être

affichées ou non:



− NO_DISPLAY_CARD: désactive l'affichage du numero de carte bancaire lors de la modif d'abonnements.

− NO_LOGIN_PAGE: N'affiche pas la page de gestion des actions de modification− NO_RESPONSE_PAGE: N'affiche pas la page des récapitulations d'abonnement.− NO_SUB_DATA: Désactive l'affichage du formulaire d'entrée des coordonnées de

l'utilisateur.− NO_PAY_MSG : Désactive le message « Paiement par carte »− NO_SEC_MSG: Désactive le message de sécurité de transaction.− NO_SSL_SYMBOLS: Désactive les symboles de SSL− NO_VALID_MSG: Enlève le message incitant a cliquer sur Valider− NO_ACCEPT_MSG: Enlève le message « Votre abonnement a bien été enregistré » sur la

page de récapitulations d'abonnement.

Une fois le template créé, il faut l'envoyer sur le serveur SOGENACTIF ainsi que les images qui sont utilisées dans ce template.

3) Informations sur le transfert de fichiers

Une fois les numéros d'abonnés enregistrés dans la base, pour procéder au prélèvement sur les comptes bancaires des abonnés, le commerçant doit procéder par échange de fichiers par FTP sur le serveur SOGENACTIF. Pour cela il envoie des fichiers texte contenant les numéros d'abonnés et l'action à effectuer sur le serveur FTP sous forme de requêtes, et à des horaires fixes le serveur SOGENACTIF lui renverra des fichiers réponses contenant les codes de retour des requêtes.

Indications sur le fonctionnement du FTP:

Pour se connecter sur le serveur FTP:Adresse: ftp.elisa-services.comProtocole: FTP TLS/SSL implicitePorts: 990 (contrôle) et 31050 à 31090 pour les données.Mode: Passif (PASV)Login et Mot de passe: Fournis par ATOS

Le client FTP, l'adresse IP et l'outil de décompression des fichiers PKZIP doivent être transmis à ATOS pour vérifier la compatibilité.ATOS enverra alors les identifiants de connexion dans un fichier crypté nécessitant une clé qui sera fournie par téléphone. Un certificat de connexion sera aussi délivré pour l'authentification.

Un serveur de test est aussi fourni par ATOS: ftp2.elisa-services.com

Pour envoyer des fichiers, utiliser la commande put. Celle ci ajoutera automatiquement un préfixe du type sXXX.nom_fichier, où XXX est le numéro du fichier dans l'ordre de transfert.Pour recevoir, utiliser la commande get.Il est impossible de créer ou de supprimer des répertoires.Les fichiers doivent être compressés avant d'être envoyés (sauf indication). Il faut spécifier à ATOS le client de compression/décompression pour vérifier les compatibilités.


ftp://ftp.elisa-services.com/


D'autre part, les fichiers ne restent pas indéfiniment sur le FTP, il faut donc faire attention de les prendre aux fréquences décrites dans les docs.

Étapes de la mise en place du système de transfert:

1) Formulaire d'inscription auprès d'ATOS pour l'utilisation du FTP2) ATOS fournit des identifiants et effectue avec le client un test de connexion3) ATOS contacte le client pour lui envoyer la recette du traitement des fichiers4) Le client effectue un test d'upload de fichier requête sur leur serveur, et un test de download

du fichier réponse. Il envoie un PV de validation à ATOS.5) ATOS définit avec le client l'heure de traitement des fichiers et met en prod le système de

paiement par FTP

Les fichiers à envoyer doivent être envoyés dans un ordre précis exprimé dans l'entête du fichier. Le premier fichier devra commencer à 000001.A chaque fichier traité le serveur génèrera un fichier réponse dont le numéro est équivalent à celui rencontré dans la requête.

Pour cela, ATOS effectue d'abord un système de validation des fichiers:− nombre de colonnes des enregistrements− numéro du fichier− cohérence entre les colonnes des enregistrements− unicité des transaction_id− numéro de séquence des enregistrementsSi l'un des contrôles échoue ATOS retournera un fichier réponse contenant deux enregistrements: un dans l'entête et un dans le corps qui contiennent tous les deux un code d'erreur et la raison.Ensuite ATOS effectue une demande d'autorisation auprès de chacune des banques des abonnés du fichier, qui seront dans le rapport de réponse.Enfin il génère le fichier de réponse qui contient les codes de retour et d'autres informations sur le montant des transactions effectuées.

− Format des fichiers de requête:

Chaque fichier comporte un enregistrement d'entête, plusieurs enregistrements dans le corps et un enregistrement de fin.Les champs numériques doivent être rajoutés par des 0 avant. Les champs alphanumériques doivent être rajoutés avec des espaces après. Les enregistrements doivent avoir 200 caractères et sur une même ligne sans retour chariot.

− Enregistrement entête :

Champ Position Longueur Type F/O Commentairecode 1 2 N O valeur « 00 » (enreg. entête)pays du commerçant 3 2 AN O pays du commerçant tel que transmis

dans l’API (cf. merchant_country)



Champ Position Longueur Type F/O Commentaireid commerçant 5 15 N O SIRET commerçant tel que transmis dans

l’API (cf. merchant_id)date fichier 20 8 N O format JJMMAAAA : date génération du

fichierheure fichier 28 6 N O format hhmmss : heure génération du

fichiernuméro fichier 34 6 N O incrémenté de 1 à chaque fichierversion fichier 40 2 AN O valeur « 03 »bourrage 42 159 AN O rempli à blanc

Ex: Si mon merchant_id est 011223344551111, je mets dans mon entête fichier:

« 00FR0112233445511111612200818453300000103(bourrage) »

La date et heure peuvent donc être générée avec la création du fichier, et le numéro peut être stocké pour être incrémenté a chaque fichier.

− Enregistrements corps:

Champ Position Longueur Type F/O Commentairecode . 1 2 N O valeur « 03 » (enreg corps)pays du commerçant 3 2 AN O pays du commerçant tel que transmis

dans l’API (cf. merchant_country)id commerçant 5 15 N O SIRET commerçant tel que transmis dans

l’API (cf. merchant_id)numéro de séquence 20 6 N O +1 à chaque enregistrement. Le premier

enregistrement doit être le 000001.identifiant abonné 26 8 AN O identifiant de l’abonné à débiternuméro transaction 34 6 N O identifiant de la transaction de paiementmontant 40 12 N O montant du paiement exprimé dans la

plus petite unité de la devisecode devise 52 3 N O d’après ISO 4217 (ex. Euro : 978) email abonné 55 50 AN F non utilisénuméro référence 105 32 AN F numéro de commande, numéro de facture

ou numéro de dossier ou ... (numéro interne à l’application du client)

bourrage 137 64 AN O rempli à blanc Ex: « 03FR 011223344551111 000001 87AQbx91 458778 00005900 978 [email protected] (+bourrage jusqu'à 50)112AE97F12000(+bourrage jusqu'à 32)(bourrage) »

Le numéro de séquence peut être incrémenté a chaque ligne, l'identifiant abonné est tel celui stocké en base, et le numéro de transaction peut être généré pour être unique. Il faut bien faire attention aux différents bourrages à rajouter sinon le serveur ne pourra pas autoriser la requête

− Enregistrement fin


mailto:00FR01122334455111100000187AQbx9145877800005900978heliosaian@gmail.com









Champ Position Longueur Type F/O Commentairecode enreg 1 2 N O valeur « 09 » (enreg fin)pays du commerçant 3 2 AN O idem enregistrement 00id commerçant 5 15 N O idem enregistrement 00date fichier 20 8 N O idem enregistrement 00heure fichier 28 6 N O idem enregistrement 00numéro fichier 34 6 N O idem enregistrement 00version fichier 40 2 AN O idem enregistrement 00nombre abonnés 42 6 N O nombre enregistrements de type 03bourrage 48 153 AN O rempli à blanc

« 00FR0112233445511111612200818453300000103000892(bourrage) »

Le fichier réponse contient aussi un enregistrement entête, des enregistrements corps (autant que dans la requête) et un enregistrement fin.:

− Entête :

Champ Position Longueur Type F/O Commentairecode enreg 1 2 N O valeur « 00 » (enreg entête)pays du commerçant 3 2 AN O pays du commerçantid commerçant 5 15 N O SIRET commerçantdate fichier 20 8 N O format JJMMAAAA : date génération du

fichierheure fichier 28 6 N O format hhmmss : heure génération du

fichiernuméro fichier 34 6 N O incrémenté de 1 à chaque fichierversion fichier 40 2 AN O valeur « 03»réponse globale 42 2 AN O voir paragraphe Erreur : source de la

référence non trouvée pour signification du code

filler 44 157 AN O rempli à blanc

Réponse globale:

Code Signification00 fichier traité correctement (voir code par abonné pour détail)01 format incorrect02 fichier déjà traité03 rupture de séquence dans le numéro de fichier04 fichier non cohérent (compteur faux, entête ou fin invalide ou manquant, ...)99 Problème technique sur le serveur d’abonnement



− Corps:

Champ Position Longueur Type F/O Commentairecode enreg. 1 2 N O valeur « 03 » (enreg détail)pays du commerçant 3 2 AN O pays du commerçantid commerçant 5 15 N O SIRET commerçant tel que transmis dans

l’APInuméro de séquence 20 6 N O +1 à chaque enregistrement. Le premier

enregistrement commence à 000001.identifiant abonné 26 8 AN O identifiant de l’abonné à débiternuméro transaction 34 6 N O identifiant de la transaction de paiementmontant 40 12 N O montant du paiement exprimé dans la

plus petite unité de la devisecode devise 52 3 N O d’après ISO 4217 (ex. Euro : 978) email abonné 55 50 AN F renseigné si fourni à l’appelnuméro référence 105 32 AN F renseigné si fourni à l’appelcode réponse 137 2 N O code réponse de la demande

d’autorisation (cf. paragraphe Erreur :source de la référence non trouvée)

num. d’autorisation 139 6 AN F numéro d’autorisationcertificat 145 12 AN F certificat de paiementdate paiement 157 8 N F format JJMMAAAAheure paiement 165 6 N F format hhmmsstype de carte 171 12 AN F type de carte utilisée pour le paiementnuméro de carte 183 7 AN F extrait du numéro de carte utilisée

(format : ####.##)date expiration carte 190 6 N F date limite de validité de la carte utilisée

(format MMAAAA)Code réponse acquéreur

196 2 N F code réponse de l’acquéreur à la demande d’autorisation

filler 198 3 AN O rempli à blanc

Code réponse:

Code Signification00 paiement approuvé05 paiement refusé (cause non fournie)12 transaction invalide (format correct, contenu incorrect) 13 montant invalide14 abonné inconnu30 erreur de format 90 service temporairement indisponible

Numéro d'autorisation: identifiant d'autorisation généré.Certificat de paiement généré par la banque.



Date et heure de paiement, type de carte (VISA, MASTERCARD, CB...), Numéro de carte (6 premiers chiffres), date d'expiration -> No comment.

Code réponse acquéreur:

Code Signification

00 Transaction approuvée ou traitée avec succès02 Contacter l'émetteur de carte03 Accepteur invalide04 Conserver la carte05 Ne pas honorer07 Conserver la carte, conditions spéciales08 Approuver après identification12 Transaction invalide13 Montant invalide14 Numéro de porteur invalide30 Erreur de format31 Identifiant de l'organisme acquéreur inconnu33 Date de validité de la carte dépassée34 Suspicion de fraude41 Carte perdue43 Carte volée51 Provision insuffisante ou crédit dépassé54 Date de validité de la carte dépassée56 Carte absente du fichier57 Transaction non permise à ce porteur58 Transaction interdite au terminal59 Suspicion de fraude60 L'accepteur de carte doit contacter l'acquéreur61 Dépasse la limite du montant de retrait63 Règles de sécurité non respectées68 Réponse non parvenue ou reçue trop tard90 Arrêt momentané du système91 Émetteur de cartes inaccessible96 Mauvais fonctionnement du système97 Échéance de la temporisation de surveillance globale98 Serveur indisponible routage réseau demandé à nouveau99 Incident domaine initiateur

Une fois générés, ces fichiers sont disponibles sur le FTP jusqu'au lendemain horaire de génération. Si ils n'ont pas pu être pris par le serveur du commerçant, il faut demander à ATOS si il y'a moyen de les avoir à nouveau, mais ce n'est pas sûr...


Rapport de stage de fin de tronc commun - Freemariosmilax.free.fr/other/rapport.pdf · Rapport de...

Documents

Transcript of Rapport de stage de fin de tronc commun - Freemariosmilax.free.fr/other/rapport.pdf · Rapport de...