Rapport de stage - SponsorBoost

Transcription

1 2012 Rapport de stage - SponsorBoost Création d une interface d affiliation publicitaire respectant le patron d architecture MVC Sous la direction de : M. Louis HOUETTE tuteur entreprise M. Sergio SARMIENTO tuteur IUT Christian Pavinich SponsorBoost 12/05/2012

2 Remerciements Je tiens tout d abord à remercier tout le personnel de SponsorBoost de m avoir accueilli et de m avoir permis d acquérir ma première expérience enrichissante en entreprise, ainsi qu à mon partenaire de stage M. Kévin Couard, avec qui j ai beaucoup apprécié travailler. J adresse particulièrement ces remerciements à mon tuteur de stage dans la société M. Louis Houette pour m avoir formé et pour m avoir donné la possibilité de comprendre l activité de la société et du monde de la publicité en ligne. Je les adresse également à M. Philippe Vasseur tout d abord pour m avoir choisi pour être un des deux stagiaires à représenter l IUT dans sa société, et pour m avoir assisté pendant le développement au cours de mon stage, et surtout, pour m avoir offert cette opportunité. Je remercie également M. Sarmiento, enseignant tuteur de mon stage en entreprise, pour nos échanges constructifs et formateurs. Et enfin, je remercie tous les professeurs de l IUT Informatique pour m avoir enseigné une méthode rigoureuse, un package technique, et de manière plus générale, un enseignement de qualité qui se sont révélés d une grande aide dans cette première projection dans le monde du travail. 1 P a g e

3 Résumé Ce document fait le rapport de mon activité au sein de la société SponsorBoost pendant mon stage de S4T à l IUT Informatique de Nice. Il aura duré 9 semaines au sein de la société SponsorBoost dans le département technique avec un collègue de ma promotion. SponsorBoost est une régie publicitaire qui tire son profit de la mise en relation des annonceurs avec les affiliés, qui diffusent leurs publicités. SponsorBoost se commissionne sur la rémunération entre annonceurs et affiliés. En clair, SponsorBoost facture les annonceurs, et rétribue les affiliés. On peut considérer que le département technique se découpe en deux pôles ; le pôle de production et le pôle de suivi et de développement. Le pôle de production agit comme un soutien de la force commerciale dans la mesure où elle aide à la création des campagnes annonceurs, des kits , et même des comptes client en général. Mon collègue de stage a été le plus présent à ce niveau, tandis que moi, ma participation fut majoritaire dans le pôle de suivi et de développement. Ce pôle s occupe de maintenir le bon fonctionnement du site Internet de la société et des outils en place, il doit également pouvoir être à l écoute des utilisateurs et des commerciaux. C est-à-dire comprendre des besoins, et les modéliser afin de proposer des modifications et améliorations sur le site web. L objectif du stage est la spécification, le développement et la validation d une évolution significative du site Internet de la société après conception et rédaction du cahier des charges spécifiant les besoins, attentes, et la planification du projet. Il a été réalisé conjointement avec un autre étudiant de la promotion Les langages de programmation utilisés pour ce projet sont le PHP et le SQL pour le traitement de données, le JavaScript pour les effets dynamiques côté client, et enfin HTML, CSS et la bibliothèque JavaScript jquery pour la structure des pages et leur style. Nous avons rapidement constaté des difficultés par rapport à la complexité de la base de données et du fonctionnement du site Internet, il a été décidé pendant la conception que nous utiliserions une architecture MVC (model, view, controller) adaptée au fonctionnement du site. Nous présenterons donc le différentiel établi entre le cahier des charges et le résultat obtenu, car l évolution des attentes et des besoins a été importante tout au long du développement. 2 P a g e

4 Summary This document aims to present the project done during my forth semester internship at the computer science UIT of Nice. It lasted nine weeks in a company called SponsorBoost in the technical department with a colleague of my promotion. SponsorBoost is an advertising company that takes care of linking advertisers with affiliates responsible of their distribution, and it s from the remuneration of the advertisers to the affiliates that SponsorBoost draws its revenues by charging a commission. We can consider that the technical department is divided into two poles; the production pole and the monitoring and development pole. The production center acts as a support of the commercial force to the extent that it helps advertisers create campaigns, kits, and even customer accounts in general. My placement colleague was more prevalent at this level, whereas my involvement was predominant in the monitoring and development division. This pole is responsible for maintaining the proper functioning of the company s website and of all the tools in place, it also must be responsive to the users and the business. That is to say, understand the needs, and model them to suggest changes and improvements on the website. The aim of the course is the identification, development and validation of a significant change in the website of the company after conception and editorial of the specifications detailing the needs, expectations, and project planning. It was conducted jointly with another student of the promotion given the magnitude of the task. The programming languages used for this project are PHP and SQL for data processing, JavaScript for client-side dynamic effects, and finally HTML, CSS and the JavaScript library jquery for page structure and style. Quickly, considering the difficulties encountered over the complexity of the database of the company and the functioning of the website, it was decided during conception that we would use an MVC (model, view, and controller) architecture adapted to the project. We will therefore present the differential established between the specifications and the result since the changing expectations and needs has been important throughout the development. 3 P a g e

5 Sommaire Introduction...6 I. Présentation de la société II. Le projet III. Conception A. SponsorBoost...7 B. Campagnes publicitaires...8 C. Le système de tracking...9 D. Les services pour affiliés...10 E. Les services pour annonceurs...10 A. L existant...12 B. Les raisons du projet...12 C. Objectif du stage et du projet...12 D. Cahier des charges...13 E. Cycle de développement...14 A. Base de données...17 B. Conception initiale...17 IV. Architecture MVC A. Présentation...20 B. Notre évolution...21 C. Le core...22 D. Webroot...23 E. Controller...24 F. Model...25 G. View...26 H. Helpers...28 I. Config...29 J. i18n P a g e

6 V. Travaux de développement A. Règles de codage à suivre...32 B. Programmation sur le projet et résultats obtenus...32 B.I Contrôleur campagne...33 B.II Contrôleur description campagne...34 B.III Autres contrôleurs...35 C. Travail effectué sur le site existant...36 D. Difficultés rencontrées sur le site existant...39 E. Difficultés rencontrées sur le projet...39 F. Tests...39 VI. Finalité du stage A. Planning final et différentiel des objectifs...42 B. Quantification...43 Conclusion...44 Glossaire...45 Bibliographie...47 Table des annexes P a g e

7 Introduction Ce rapport fait l objet du projet fait dans la société SponsorBoost durant le stage effectué du 11 avril au 15 juin Il porte sur la refonte de l interface d affiliation du site Internet de la société pour respecter le paradigme objet. De plus, il sera développé en suivant une architecture MVC que nous avons développé. Les langages utilisés sont le PHP *, le HTML *, le CSS * et le duo JavaScript * /jquery *. Il faut aussi rajouter le SQL * pour le traitement de la base de données. L objectif du projet, et le but du stage est de concevoir et de développer une nouvelle version performante de l interface d affiliation du site Internet tout en préparant une base solide pour la poursuite du projet aux autres interfaces du site, à savoir les interfaces annonceur et administrateur. Il est donc important de prendre en compte l aspect à long terme du projet, ce qui a allongé de façon considérable la phase de conception. D autant plus que la structure MVC proposée est en soit une solution exportable à tout type de développement web utilisant le langage PHP, et tout cela grâce à la généricité *, le polymorphisme *, et l héritage * permis par la programmation orientée objet. Il est évident qu au vu du temps dont nous disposions et de la taille du projet, il ne pouvait être fini pour les trois interfaces du site Internet. D où la demande faite de ne développer que l interface d affiliation. De plus, il faut savoir que le temps accordé pour le développement du projet a été partagé avec le temps prit pour maintenir et créer de nouvelles fonctionnalités pour le site web existant. Donc, comme dit précédemment, le but et la majeure difficulté sera de mettre en place une base solide et performante qui ne nécessitera aucun retour en arrière. Pour faire cela, les étapes et planifications de cette œuvre devront être définies à l avance dans le cahier des charges, rédigé par les stagiaires sous la supervision de la MOE *, et de la MOA *. Ces étapes ont donc été l analyse et la conception du projet suite aux besoins et exigences de celui-ci spécifiées dans le susdit cahier des charges *. Ensuite a suivi la phase de développement, effectué en parallèle avec la phase de tests. Il faut savoir que les spécifications du cahier des charges ont été amenées à évoluer lors de chacune de ces phases, il faut noter l apparition de l architecture MVC, contrainte absente lors de la définition initiale des objectifs et attentes du projet par la MOA. Seront présentés dans un premier temps la société SponsorBoost ainsi que son activité et ses buts, et le site Internet existant. Ensuite, seront abordées les différentes phases de la création, notamment la partie conception où l on détaillera les raisons de la décision prise d adopter une architecture MVC, et ses conséquences sur le déroulement futur à court et long terme du projet. Et enfin, nous montrerons les résultats obtenus ainsi que le planning final, et le différentiel établi entre les objectifs et les résultats finaux. 6 P a g e

8 A. SponsorBoost I. Présentation de la société SponsorBoost est avant tout une société qui propose un service de mise en relation entre annonceurs et affiliés. Située à Nice au 15 rue Alberti dans le bâtiment C de la résidence Nice-Europe, elle propose également de nombreux autres services spécifiques aux affiliés comme aux annonceurs. La première version du site Internet a été développée en 2008 par Philippe Vasseur, basé sur son propre système de «tracking *». L activité et l évolution des techniques utilisées n ont pas cessées de croître depuis, et le chiffre d affaires annuel avoisine maintenant le million d euros pour un total de 6 employés. La société est également distributeur d un service de routage * en marque blanche * pour diffuser les campagnes par des annonceurs en utilisant les bases de contacts des affiliés. Elle souhaite à terme posséder sa propre plateforme de routage qui est actuellement en développement. Les principaux partenaires de SponsorBoost sont cités ci-dessous : Figure 1 Vingt principaux partenaires de SponsorBoost 7 P a g e

9 Au final, on peut dire que SponsorBoost a pour mission d'aider chacun à booster la rentabilité de son business sur le web, en proposant les solutions les mieux adaptées à chaque besoin spécifique. On ne fera ici que présenter brièvement le fonctionnement de la société, afin de mieux visualiser le cadre de travail du projet et mieux comprendre la pertinence des objectifs ciblés. B. Campagnes publicitaires Elément central de l activité de SponsorBoost, les campagnes publicitaires sont initialement créées par les annonceurs qui viennent chercher un nombre plus important de cibles * (internautes) afin de promouvoir leur site Internet et booster leurs achats. Les campagnes se distinguent de plusieurs façons différentes, essentiellement par leur moyen de diffusion et par leur moyen de rémunération pour les affiliés. Il y a au total 4 types de rémunération : - Le coût par achat (CPA) : L affilié est rémunéré avec un montant fixe pour chaque acte ou vente effectué grâce à sa diffusion. Il y a aussi dans le même type le CPA%, ici l affilié est rémunéré avec montant variable calculé sur le montant total de l acte ou de la vente, avec un taux fixe. - Le coût par clic (CPC) : L affilié est rémunéré avec un montant fixe dès qu il y a clic sur la publicité. - Le coût par lead (CPL) : Un lead est un formulaire que la cible de la publicité remplit contenant ses informations personnelles et, il est constitué au minimum d une adresse . Ce sont les leads qui permettent de constituer les bases de contacts. Les leads peuvent avoir une grande valeur sur Internet, et peuvent monter jusqu à 30 euros l unité pour les plus complets. Une fiche d inscription peut aussi être considérée comme un lead. L affilié est donc rémunéré avec un montant fixe pour chaque lead rempli grâce à sa diffusion. - Le coût par mille (CPM) : Ici au bout de 1000 affichages, l affilié est rémunéré avec un montant fixe. Et il y a au total 7 types de diffusion : - Les campagnes qui autorisent «l incentive» ou l incitation : C est-à-dire que la publicité de par son message attractif déclenchera le clic de la cible. - Les campagnes de mailing : C est le type le plus important, il consiste en la diffusion d un publicitaire sur un grand nombre d adresses. Elles sont ciblées selon le public souhaité, d où l importance d avoir des leads les plus détaillés possible. - Les campagnes autorisant les mots-clefs : Il arrive qu un annonceur se réserve le droit d utiliser certains mots clefs relatifs à sa campagne, ou à son activité afin d être mieux référencé. Lorsque ce n est pas le cas, les affiliés ont le droit d investir sur ce genre de mots clefs pour leurs diffusions (par divers moyens que nous ne détaillerons pas). - Les campagnes avec clic de validation: Pour afficher la campagne, la cible doit cliquer sur un élément choisi par l affilié (bouton ou autre). - Les campagnes site-under : Un site-under est finalement un pop-up qui s affiche derrière la page de l utilisateur sans l interrompre dans son opération. - Liens textes autorisés : La campagne se résume à un lien, non caché. 8 P a g e

10 - Avec codes promotionnels : une campagne qui dispose de codes promotionnels permet justement une diffusion d offres promotionnelles (l affilié utilise ce code dans la publicité, qui sera transféré au site marchant lors du clic client). C. Le système de tracking Mis à part les campagnes et les membres du site, un autre élément tout aussi important de la société est le système de tracking des campagnes. On appelle tracking, le procédé essentiel qui permet de faire remonter à la base de données de SponsorBoost chaque action, vente, affichage ou clic que génère une campagne annonceur sur un site ou une base affilié. Ceci permet à la société de toucher la commission, principale source de son revenu et de rémunérer les efforts de l affilié responsable de cette conversion. Il consiste en la pose d un élément pouvant prendre plusieurs formes (selon le type de campagne) qui est en fait un petit code PHP de quelques lignes, que nous appellerons tag. Il doit se trouver à un endroit déterminé lors du passage forcément obligatoire d une cible. Lorsque cette cible exécute une action relative à la campagne publicitaire, ce bout de code va simplement appeler une fonction PHP situé sur le site Internet de SponsorBoost, qui va aller écrire toutes les informations relatives à cette campagne. Comme par exemple le numéro de la campagne, le numéro de l affilié ou encore le numéro de la candidature à cette campagne, etc Ce procédé peut se faire en plusieurs étapes. Depuis la création de la société, le fonctionnement du tag a évolué car présente des pertes. C est-à-dire que même avec la version actuelle, il y a une part non négligeable (30%) de non remontée des actions en rapport à une campagne. Cette perte est principalement due au fait que les navigateurs bloquent de plus en plus les trackings publicitaires. D autre part, des erreurs peuvent survenir pour de nombreuses raisons, comme une mauvaise installation du tag, ou un exemple connu est le non-retour de la cible sur le site marchand après avoir effectué le paiement sur une plateforme sécurisée tierce. Aucun tag n est installable sur ce dernier, et prouver la confirmation de l achat est délicat. Ce qui résulte en une perte sèche pour SponsorBoost. L annonceur n est pas facturé pour son gain, l affilié n est pas rémunéré pour sa diffusion, et il n y a donc aucune remontée de commission. Il y a au total 3 versions du tag : - V1 : Basée sur l utilisation de cookies *, technique facile à mettre en œuvre mais présente beaucoup de pertes. - V2 : Comme la V1, cette version utilise des cookies mais aussi sur un suivi de l adresse IP en base de données, et dans la Session * de l affilié. Demande plus de compétences techniques de la part de l annonceur. - V3 : Ce système encore en développement, donne des résultats très satisfaisants. Il est plus simple à installer, moins invasif, et repose sur une technologie développée par SponsorBoost de «Cookie Serveur». 9 P a g e

11 D. Les services pour affiliés Un affilié peut être considéré comme un particulier, ou une entité. Dans la société un affilié possède potentiellement un site Internet ou une base de contacts, et souhaite le rentabiliser. Pour cela, on dispose de plusieurs outils pour l assister dans cette tâche. Certains d entre eux sont directement utilisables depuis l interface d affiliation du site Internet de SponsorBoost. Les employés du département technique sont également là pour compléter ces outils. Un affilié peut donc : - Postuler aux campagnes référencées des annonceurs depuis l interface d affiliation, et les diffuser selon leur type. Soit sur leurs sites personnels, ou par sur leurs bases de contacts soumises à SponsorBoost. - Mettre à disposition sa ou ses bases de contacts, pour le routage ing des campagnes publicitaires des annonceurs. - Acheter des crédits de routage permettant l envoi d un nombre important d s. Ce système a pour avantage d utiliser une plateforme de routage en marque blanche performante pour l envoi de ses newsletters et publicités. - Encaisser ses paiements à partir de 30 euros HT. - Parrainer d autres affiliés pour augmenter ses revenus. - Mettre à disposition des tableaux statistiques détaillés en ligne. Ils permettent de contrôler l efficacité des campagnes diffusées, et de ses bases de contacts et ainsi surveiller les revenus qu il dégage. E. Les services pour annonceurs Un annonceur peut être une personne mais est plus généralement représentée par une entité qui n est autre que le site Internet en question, qui souhaite profiter des outils de SponsorBoost pour augmenter ses profits. Les employés du département technique sont également à disposition pour les assister, notamment dans le montage des campagnes et l installation du tag. Un annonceur peut donc : - Utiliser les services de co-registration : lors de la soumission d un lead, rajouter la présence d une case à cocher pour inscrire la cible aux newsletters de l annonceur. - Faire appel à SponsorBoost pour mettre au point un ensemble de mots clefs pertinents pour le site Internet. Ceci améliore son classement dans les moteurs de recherche. Ce procédé est appelé le «keywording». - Soumettre ses campagnes publicitaires. - Se positionner sur des carrefours et des comparateurs de prix pour booster son trafic. 10 P a g e

12 - Re-ciblage publicitaire ou retargeting: Procédé complexe qui est en fait un système de publicité ciblée. Une cible qui n achète pas son panier peut recevoir des offres similaires s il visite un autre site partenaire de l opération. 11 P a g e

13 II. Le projet A. L existant SponsorBoost possède actuellement un site Internet, qui remplit toutes les fonctions nécessaires à son activité. Mais, depuis la création de la société il n a cessé d évoluer. Aujourd hui on peut estimer la taille du site web ; avec un total de plusieurs dizaines de milliers de lignes de code pour les 3 interfaces (affilié, annonceur et administrateur) et plus de 700 fichiers. Il est essentiel à ce point d avoir un suivi du code existant pour éviter la redondance et optimiser la performance. B. Les raisons du projet L évolution du site Internet à cette vitesse nécessitera forcément à un point donné une évolution significative de son fonctionnement, ainsi que de son architecture, pour mieux convenir à sa taille actuelle. Plus précisément, il faut noter qu un nombre relativement important de stagiaires développeurs sont régulièrement recrutés dans la société pour améliorer les fonctionnalités du site. Etant une petite structure, le «versioning *» n était pas pris en charge, mis à part des sauvegardes ponctuelles et un développement en deux étapes (tests sur le serveur de développement local puis mise en ligne sur le serveur de production). Le suivi des modifications était difficile. Cette méthode de développement reste viable pour un développeur seul sur un petit projet, mais devient vite ingérable lorsque le nombre de développeurs augmente de pair avec la taille du projet. D où l apparition du besoin d instaurer une architecture plus performante et adaptée à l utilisation actuelle du site web. Tout cela est permis par la programmation orientée objet en PHP. En effet, la taille du site Internet devenant très importante la portée de la programmation procédurale est vite dépassée, et nécessite une évolution pour une réutilisation plus aisée du code. Il est nécessaire pour justifier la viabilité d un tel projet, d avoir des règles de codage strictes et des étapes de développement bien définis. Ces besoins ont fait naître l installation d un service «Git» interne, et l adoption d une architecture MVC personnalisée pour le projet. Seront expliqués plus bas les raisons de l apparition de ces deux concepts et leur fonctionnement. C. Objectif du stage et du projet Le travail des stagiaires ne devra pas être uniquement consacré au développement du projet, mais aussi sur l ajout de fonctionnalités sur le site web actuel, ainsi que le montage des campagnes publicitaires et de toutes les tâches qui peuvent être demandées à un employé du département technique. Cette partie du travail forcera les stagiaires à comprendre l activité de SponsorBoost, ainsi que le fonctionnement du site et la structure de la base de données. Ce stage a donc une vocation pédagogique dans la mesure où le développement du projet ne nécessite pas forcément une compréhension approfondie de l existant et de la société en général. Les stagiaires ressortiront donc avec une 12 P a g e

14 expérience technique dans le développement web, mais également avec une compréhension du monde de la publicité sur Internet. Le projet en lui-même, plus encore que simplement poser les fondations d un système plus performant et abouti, devra présenter à la fin du stage un fonctionnement amélioré par rapport à l interface d affiliation. Tout ceci, en respectant le paradigme objet et l architecture MVC, contrainte rajoutée au cours de la conception. Le code devra être documenté, et explicitement commenté. Le projet doit également présenter une configuration complète et facile d accès, pour choisir par exemple la base de données utilisée. Ou encore, à terme, l affichage multilingue. Il doit être facilement modifiable, et s adapter à n importe quel environnement de développement. Enfin, de façon analogue au site existant, il devra gérer correctement les statuts des différents membres, ainsi que leurs droits d accès à certaines fonctionnalités du site. Par exemple, un affilié seul n aura pas les mêmes droits qu un membre affilié et annonceur. Ou, de même, un utilisateur non connecté aura également des droits, mais limités. D. Cahier des charges La rédaction du cahier des charges fonctionnel du projet a été à la charge des stagiaires. Il devait respecter les attentes de la MOA, et représenter les objectifs définis par la MOE pour le projet demandé. Il faut noter que les attentes et objectifs du projet ont évolués tout au long de son développement et du stage. Il sera présenté à la fin de ce document, un différentiel entre les objectifs attendus, et les objectifs atteints. Voici la liste des fonctionnalités de service principales prévues pour le développement de l interface d affiliation : - FS1 : Visualiser les campagnes disponibles. - FS2 : Accéder à son profil affilié. - FS3 : Visualiser les statistiques. - FS4 : Choisir son moyen de paiement. - FS5 : Voir ses gains. - FS6 : Accéder à ses factures. - FS7 : Rechercher dans la FAQ (Foire Aux Questions). - FS8 : Contacter la société. - FS9 : Postuler à une campagne. - FS10 : S inscrire comme affilié. - FS11 : Ajouter des sites personnels ou des bases de contacts - FS12 : Récupérer les informations nécessaires d une campagne tels que les visuels/bannières/scripts ing/description/etc - FS13 : Récupérer les codes promotion. - FS14 : Visualiser les catalogues produits relatives à une campagne Les fonctions de couleur orange ont été rajoutées lors de la conception ou du développement. 13 P a g e

15 Malgré une conception et une visualisation globale du projet difficile, les besoins énoncés par la MOA sont relativement succincts. Chose normale, quant à la nature du projet qui est une évolution purement technique de l existant. Ces besoins ne sont que la conservation des fonctionnalités déjà présentes. Aucune perte ne doit donc être relevée, et plus encore les bugs présents doivent être éliminés. Planning prévisionnel : Figure 2 Planning prévisionnel Le stage n ayant officiellement duré que neuf semaines, le planning a naturellement été tassé vers la fin. Les tests et la correction s effectuant au fur et à mesure, le temps de développement a été allongé. D autant plus que le temps de conception a effectivement pris 2 semaines, malgré une planification large pour cette partie. Ce retard dans la conception est notamment dû aux décisions et problèmes rencontrés, expliqués dans la partie qui suit. E. Cycle de développement Pour éviter de reproduire les problèmes et erreurs du passé, il a été décidé qu il fallait instaurer un cycle de développement propre et strict. Pour cela, une solution performante était l installation d un système Git. Malgré une mise en place et une configuration complexe, la présence de git facilite grandement le suivi d un projet et propose un large éventail d outils de récupération et de gestion de projet. 14 P a g e

16 Techniquement, git est un logiciel de gestion de versions décentralisé. C est un logiciel libre par le créateur du noyau Linux ; Linus Torvalds. En utilisant le réseau local de SponsorBoost, et avec Git, nous pouvons gérer plusieurs projets. Plus précisément, durant le stage, nous avons eu à gérer le site existant et le projet. Git fonctionne avec un système de branches, qui une fois modélisé, ressemble à ceci : Figure 3 : Diagramme de git, ou «network» Ceci est un extrait du diagramme de développement du site Internet de SponsorBoost, depuis la mise en place de git. Ce type de figure est généré par Gitlab, qui est le service Web de gestion de git. Développé en Ruby on Rails *, il permet d accéder à tous les services proposés par git, avec des comptes utilisateurs. Toute action a donc un auteur, permettant une identification aisée du travail de chacun. Ce diagramme est très utile pour suivre l avancement du développement dans le temps. Chaque point représente une action relative à une branche de développement. Idéalement, chaque développeur possède sa propre branche de développement, voire même plusieurs. Il n y a pas de contrainte relative au nombre de branches, ou à leur gestion, chaque entreprise gère son projet comme il le veut. Chaque branche de développement est hébergée sur le réseau local de SponsorBoost, et doit être importée sur le poste personnel du développeur s il souhaite le modifier. Donc, au final, le développeur travaille en local sur son ordinateur. Et, dans l ultime, ne nécessite même pas de connexion au réseau dans la mesure où le logiciel est installé sur son poste, et peut fonctionner en autonomie. Une fois la connexion rétablie, il pourra soumettre sa branche personnelle enrichie par son travail, à la branche correspondante stockée sur le serveur. Il arrive évidemment que plusieurs développeurs travaillent, ou veulent fusionner leurs branches sur une même branche du serveur. Cela peut créer des conflits, voire même des écrasements de fichiers plus récents, par des fichiers anciens ramenés par les développeurs. Pour cela, git propose un gestionnaire de conflits, et interdit la fusion d une branche locale avec celle correspondante sur le réseau si la dernière version n a pas été ramenée. Evidemment, les actions des utilisateurs ont des noms bien définis, et «fusion» est un mot peu approprié pour décrire l étendue des possibilités offertes par git. Ces actions peuvent être plus ou moins étendues selon les droits attribués à chaque type d utilisateur. On peut donc : - Commit : Opération de base permettant de rajouter les modifications faites sur son poste, dans la branche locale (à na pas confondre avec le Push). - Push : Permet d apporter les modifications faites sur la branche locale, dans celle sur le réseau. (Représente un point sur le diagramme). 15 P a g e

17 - Pull : Inversement au push, permet d amener sur sa branche locale, la dernière version de la branche correspondante sur le réseau. - Merge : Fusionne deux branches sur le réseau, au final les deux branches mergées sont identiques. Représente une flèche allant d une branche à une autre sur le diagramme. - Switch : Change la branche locale pour correspondre avec celle choisie, elle sera identique à la dernière version connue. Pour avoir la dernière il faut «Pull» la branche. 16 P a g e

18 III. Conception A. Base de données L utilisation de la base de données existante était une des exigences de la MOA, il a fallu adapter la conception du projet en fonction de cette dernière. Elle est constituée de soixante-quinze tables, et contient un très grand nombre de données (plus de 15 Go). Du fait du caractère confidentiel de la base de données, il ne sera pas possible d en présenter la structure, ni des noms de tables. B. Conception initiale Au début du projet, les seules exigences étaient de proposer un système utilisant le paradigme objet. Voici les cas d utilisation qu il fallait modéliser. Ces digrammes ont été créés en UML * avec le logiciel de conception Visual Paradigm. Figure 4 Diagramme de cas d utilisation 17 P a g e

19 Après avoir précisément défini les fonctions qu il fallait implémenter, il a fallu créer un diagramme de classes modélisant au mieux nos besoins, il se trouve en annexe I. En parallèle de cela, nous avons aussi fait des ébauches de diagrammes de séquence. Après plusieurs tentatives et discussions sur l identification d un objet traitant les données, nous avons décidé d insérer un objet inconnu appelé «composant» dont la réelle utilité devait être définie. Figure 5 Diagramme de séquence : voir ses gains Figure 6 Diagramme de séquences : afficher FAQ 18 P a g e

20 Il ne nous a pas fallu terminer ces digrammes, pour nous rendre compte que le plan n était pas viable et mal approprié à ce qu il nous fallait. Notre façon de raisonner ne collait aucunement à la manière dont nous voulions concevoir le projet. Il était évident qu il fallait revoir notre conception, pour avoir un système moins confus et plus performant. La décision a alors été prise d utiliser un modèle MVC adapté à nos besoins. A partir de là, nous avons refait une conception plus en adéquation avec le système existant, qui nous permettra en plus d utiliser la base de données existante, et d avoir un système performant et sécurisé. Le diagramme de classes final se trouve en annexe II. 19 P a g e

21 IV. Architecture MVC A. Présentation Le MVC est une architecture répandue de nos jours, et fréquemment utilisée. D après la définition de Wikipedia; «Le MVC est un patron d'architecture et une méthode de conception qui organise l'interface homme-machine (IHM) d'une application logicielle. Ce paradigme divise l'ihm en un modèle (modèle de données), une vue (présentation, interface utilisateur) et un contrôleur (logique de contrôle, gestion des événements, synchronisation), chacun ayant un rôle précis dans l'interface. Cette méthode a été mise au point en 1979 par Trygve Reenskaug, qui travaillait alors sur Smalltalk dans les laboratoires de recherche Xerox PARC1.» Le MVC se construit de cette manière : Figure 7 Schéma architecture MVC Le contrôleur, comme son nom l indique, joue le rôle d intermédiaire entre la vue et le modèle. Il sert à récupérer les données depuis le modèle, pour les traiter, et ensuite rendre le contenu à la vue. Le tout est efficacement séparé, chaque élément a un rôle bien défini. Il est facile de suivre l évolution du code, et d éviter les redondances nuisibles à sa lisibilité. Grâce au MVC, on ne verra plus de SQL mélangé dans le PHP, idem pour le JavaScript, le CSS et l HTML. Cependant, l'architecture MVC ne résout pas tous les problèmes. Elle fournit souvent une première approche qui peut ensuite être adaptée. Dans notre cas, une architecture MVC de base ne suffit pas à remplir toutes les exigences de la MOA, il faut l enrichir. 20 P a g e

22 B. Notre évolution D après un système imaginé par le département technique avant le recrutement des stagiaires, notre architecture MVC incorpore des éléments adaptés à un site web en PHP. Voici comment il se structure : Figure 8 Schéma MVC personnalisé On voit donc ici l apparition de plusieurs éléments, le schéma de construction des données à rendre à la vue est différent. L utilisateur passe obligatoirement par un fichier qui se nomme index, et qui s occupe d initialiser l environnement. C est-à-dire qu il crée l objet dispatcher et définit un certain nombre de constantes qu il récupère dans les variables initialisées par PHP, car peuvent changer d un système à un autre. Figure 9 Index.php 21 P a g e

23 Entre l index et le Dispatcher se trouve l objet Request, à vrai dire, il est instancié dans le constructeur de l objet Dispatcher. L objet Request récupère le contenu de l url, ainsi que le contenu de la superglobale * post. C est-à-dire les données de formulaire. Cet objet sera ensuite passé dans l objet Router qui identifiera le contrôleur, l action demandée ainsi que les paramètres GET de l url. Enfin, si le contrôleur existe ainsi que l action demandée, ce contrôleur est initialisé. Et, si l action appelée le nécessite, initialise le modèle ou se sert de helpers et finit le traitement en appelant la vue correspondante qui peut également utiliser des helpers pour structurer les données. Avec cette nouvelle architecture, et comme on a pu le voir avec le diagramme de classes correspondant, le projet ne se découpera pas en 3 dossiers que sont le modèle la vue et le contrôleur. On a au final 8 dossiers, avec un total de plus de 80 fichiers prévus lors de la fin du développement de l interface. Parmi ces dossiers, il y a : - Core - Webroot - Controller - Model - View - Config - Helpers - i18n C. Le core Élément central du projet, le core est un ensemble de fichiers définissant le comportement de l architecture, toute l organisation des données et du traitement se passe dedans. Le reste du projet n est que le contenu du site, et le code permettant de traiter les données. Autrement dit, le core est très facilement exportable dans un autre projet car ne contient rien, ou très peu d éléments relatifs au projet en lui-même. C est au final le conteneur d un ensemble de métaclasses *, qui définit l architecture alors que le reste définit le contenu propre au projet lui-même. Le core contient un ensemble de 8 fichiers : - Controller : Le contrôleur mère du projet. - Dispatcher : Point d entrée du système après l index, trouve le contrôleur demandé ainsi que son action grâce à Request et Router. - Header : Contient un ensemble de méthodes utilisés par l objet Controller, afin d envoyer des paramètres http selon la situation (erreurs 404, ou encore 410 quand la ressource n existe plus). - Includes : Sert à inclure tous les fichiers nécessaires au fonctionnement du core, plus les helpers. - Model : Le modèle mère du projet. - Request : Objet servant à récupérer, et stocker les informations dans l URL. - Session : Objet qui s occupe de toutes les actions relatives à la Session, permet non seulement de gérer efficacement les variables de Session (si plusieurs Session sont amenés à être utilisées en même temps 22 P a g e

24 sur le même environnement, les conflits sont évités), mais également à identifier le type d utilisateur connecté, ou non, pour gérer les droits d accès. Figure 10 exemple d utilisation de la clef de Session - Router : Objet servant à vérifier le contenu de l URL, grâce à des expressions régulières définies dans la configuration, pour chaque action que l utilisateur peut appeler. Cela sert à sécuriser les paramètres récupérés dans l URL. Par exemple : Figure 11 extrait conf.php Ici, on voit que l on fait appel à une méthode statique de Router ; connect qui prend 2 paramètres. Le premier paramètre correspond à ce qui pourrait être rentré dans l URL, et le deuxième paramètre à la redirection effectuée, si le premier paramètre correspond à l URL rentrée. Par exemple, la ligne 63 signifie que si aucun chemin n est spécifié, l utilisateur doit être redirigé vers la page index (différent de l index expliqué plus haut, celui-ci est une vue qui affiche la page d accueil) du contrôleur accueil. Ou encore, la ligne 65, si le contrôleur inscription est appelé avec un paramètre quelconque, l utilisateur doit être redirigé vers la page inscription, du contrôleur inscription, seulement, si le paramètre est une suite de chiffres. Avec cela, on voit tout de suite que cet outil peut s avérer très utile pour assurer la sécurité en évitant les injections SQL*, ou encore, pour économiser des lignes de code de vérification de paramètres. Ce n est pas non plus une contrainte d utilisation, car on peut très bien se passer de règle de redirection pour une page donnée. D. Webroot Le dossier Webroot contient toutes les ressources du projet. C est-à-dire, les scripts JavaScript, les feuilles de style CSS et les images. Mais il contient surtout l index du projet, celui qui crée le Dispatcher et initialise les constantes d environnement. Mais il y a un problème par rapport à son emplacement, étant dans le dossier Webroot, et non à la racine du projet. Il n y a donc pas d index dans la racine. Il faut donc recourir à des fichiers htacces, les htaccess sont des fichiers de configuration des serveurs web Apache *. Ils servent à modifier les droits d'accès, ou encore, à créer des redirections. Ici, nous allons utiliser leur capacité à créer des redirections. En recourant à deux de ces fichiers, dont un dans la racine du projet, et l autre dans Webroot, nous allons manipuler l URL afin de rediriger l utilisateur à l endroit souhaité. 23 P a g e

25 Figure 12 -.htaccess de la racine Comme on peut le voir, le code ne fait que 2 lignes. Ici, on demande une redirection vers le dossier webroot, peu importe le contenu de l URL en conservant évidemment les paramètres éventuels (d où le $1). Le drapeau [L] signifie que cette commande de redirection arrête toute autre règle de redirection s il y en a. Figure 13 -.htaccess de webroot Ici, on passe à 4 lignes, on ajoute des conditions. C est-à-dire que l on n exécute la redirection vers index.php, que si l URL rentré ne correspond ni à un fichier, ou à un répertoire existant (dans le cas où l on veut accéder à des ressources de Webroot). C est d ailleurs la raison de l existence de deux fichiers htaccess, car s il n y avait pas la problématique des ressources, on n aurait fait qu un seul de ces fichiers. E. Controller Le dossier Controller contient donc tous les contrôleurs au sens MVC du projet (mis à part le contrôleur mère dans le core). Ils concentrent à eux seuls à peu près 65% du code du projet, ce sont eux qui structurent les données récupérées dans les modèles. On avait énoncé plus haut que chaque page correspondait à une action d un contrôleur. En effet, selon le contenu de l URL, l objet Dispatcher va trouver le bon contrôleur ainsi que son action (qui n est finalement qu une méthode de celui-ci). Figure 14 Constructeur du dispatcher 24 P a g e

26 Le déroulement de cette opération est relativement simple, le dispatcher initialise l objet Request, qui sera passé dans l objet Router, pour ensuite charger le contrôleur correspondant. Et, ensuite, la méthode de ce dernier correspondant à l action. Si l un de ces deux n existe pas, un message d erreur de type 404 est affiché. Enfin, en fonction de l action appelée, le modèle correspondant peut être chargé ou non, ainsi que la vue adéquate (en général une action correspond à une vue) avec la méthode render. On peut finalement imaginer qu un contrôleur représente un «use case» du diagramme de cas d utilisation présenté dans la partie conception, et les actions, les différents outils disponibles pour cette fonction. Par exemple, dans le contrôleur Campagne, qui permet la visualisation des campagnes, l utilisateur a à sa disposition des filtres pour leur affichage (par type de diffusion, ou de rémunération, etc ), ou peut même faire une recherche détaillée d une ou plusieurs campagnes en particulier répondant à divers mots clefs ou numéros. Chacun de ces outils correspond donc à une action (méthode) du contrôleur. F. Model Le dossier model, comme le dossier Controller contient tous les modèles au sens MVC excepté le modèle mère situé dans le core. Techniquement, ils contiennent très peu de lignes de code, car l essentiel de l utilité de ceux-ci se situe dans le modèle mère. C est elle qui contient les méthodes d accès à la base de données. Toutes les requêtes SQL s effectuent dans cet objet grâce à la méthode find et à ses dérivés. Voir l annexe III pour le code source de la méthode find. Tous les accès à la base de données se font grâce à des arrays de ce type : On construit le tableau selon différents critères : Figure 15 Exemple d array pour la méthode find - Fields : Contient les champs à afficher. - Conditions : Les conditions de la requête. - Order : L ordre d affichage des données. - Join : Les éventuelles jointures avec d autres tables. - Limit : La limite de données à afficher. L objet Model possède également des méthodes similaires pour les requêtes de mise à jour, de suppression, d accès à seulement une ligne d une table, voire même à un seul champ d une table. 25 P a g e

27 On voit tout de suite l avantage que présente cette méthode. Même si le développeur est contraint à suivre la structure ci-dessus pour récupérer des données, ce qui peut parfois présenter des limites, on a une totale absence de requêtes SQL dans les contrôleurs, améliorant la séparation du code et sa lisibilité. G. View Dernier dossier contenant les objets MVC, View contient donc les vues, à la seule différence que ce dossier contient lui-même autant de dossiers qu il y a de contrôleurs (qui nécessitent des vues). Ces dossiers portent le même nom que le contrôleur correspondant, et contient autant de vues que ce dernier a d actions, sauf pour les rares exceptions d actions utilisant la même vue. Il y a par contre un dernier dossier dans View qui s appelle layout, il contient un ensemble de fichiers (pour notre projet ils seront 3). C est eux qui définissent à quoi ressemble la page, c est-à-dire la position des menus, leur nombre, ou encore les entêtes et les pieds de page. En fait, le rendement d une vue par un contrôleur n est pas la dernière étape de l affichage à l écran de la page. En effet, la vue n est que le contenu de la page, c est elle la partie variable. En passant d une page à une autre dans un Site Internet, il y a toujours une partie qui ne varie pas, ceci est le layout. Il est évident que ces 3 utilisateurs n auront pas la même interface et les mêmes menus, c est pour cela que nous possédons 3 layouts : - Le layout affilié - Le layout annonceur - Le layout administrateur Le layout utilisé est défini dans le contrôleur mère. à la fin de chaque action, la méthode render est appelée par le Dispatcher. Figure 16 Fonction render La fonction ici est aussi relativement simpliste, le dispatcher passe en paramètre le nom de la vue (qui est en fait le même que le nom de l action). Suite à cela, on extrait les variables définies dans le contrôleur pour les rendre 26 P a g e

28 disponibles à la vue, et on inclut la vue. Il faut cependant remarquer la présence des commandes ob_start et ob_get_clean autour du require. D un côté, ob_start permet de mettre en mémoire tampon tout ce qui va être affiché à l écran. De l autre côté, ob_get_clean récupère le contenu de la mémoire tampon, que nous stockons dans une variable appelée content_for_layout. Cette variable n est autre que le contenu à afficher pour le layout appelé à la ligne 66. Figure 17 Extrait layout affilié Remarquons plusieurs choses dans ce layout : - Les balises noscript : interdit l utilisation du site si JavaScript n est pas activé dans le navigateur. - L inclusion de deux menus : menuaffilietop et menuaffilieleft. Ce sont les deux menus caractéristiques de l interface d affiliation, et contenus dans le dossier layout. Tandis que le menu du haut (menuaffilietop) est le même pour toutes les pages, le menu de gauche (menuaffilieleft), change selon la page affichée. D où la présence d une méthode getmenu dans chaque contrôleur permettant de retourner le contenu de ce menu sous forme d un array, et reconstruit dans le layout. Figure 18 Aperçu d un des menus accordéons (généré avec menuaffiliéleft.php) 27 P a g e

29 Figure 19 Aperçu du menu affilié (menuaffiliétop.php) - L appel de la méthode statique «modal» de l helper Flash, cette méthode sert à disposer un pop-up modal avec un lien de retour. Ceci seulement si messageflash est initialisé. - Et enfin l affichage du contenu de content_for_layout. H. Helpers Les helpers sont des objets PHP utilisés idéalement par les vues pour effectuer des tâches répétitives, ou redondantes. Un helper peut être modélisé dès qu il peut ajouter un niveau d abstraction à une tâche, pour simplifier son exécution. On a, au final, étendu leur utilité jusque dans les contrôleurs, pour l instant le projet dispose de 4 helpers. Au fur et à mesure du développement leur nombre et leur taille augmente pour satisfaire toujours plus de besoins. - Debug : Cet objet sert aux développeurs pour manipuler plus efficacement les sorties d erreurs en fonction de l environnement et de l état du site. Si le site est en ligne, on ne veut pas que d éventuelles erreurs affichent des détails trop précis aux utilisateurs afin de ne pas dévoiler le fonctionnement interne du système. Ou encore, lors d un développement on veut que les messages soient les plus détaillés possibles, d où la présence de plusieurs niveaux de debug définis dans la configuration, et traités par cet objet. - Flash : Comme dit ci-dessus, cet objet sert à afficher les pop-ups modales en jquery, il dispose d une option intéressante, qui est la précision d un lien de redirection. Ce lien va quoi qu il arrive rediriger l utilisateur à l adresse stipulée. Figure 20 Exemple de pop-up modal - Form : Objet servant à la construction d input de formulaire, grâce à cet objet aucun type d input n est oublié, on peut très bien les construire un par un ou tous en une seule fois rien qu en appelant une fonction. Le code source de l helper Form est dans l annexe IV. - Table : Objet très utile qui sert à la construction de tableaux html en ne passant qu un array. Un array type se trouve en annexe V. 28 P a g e

30 Figure 21 appel de la méthode construire de Table On voit bien qu avec un array de ce type, aucun aspect d un tableau n est oublié, que ce soit le style, ou le nombre de colonnes et de lignes. On ne perd aucune possibilité offerte par les tableaux html. Il faut juste retenir une capacité additionnelle grâce à ce helper qui est le stockage en Session du code du dernier tableau généré, grâce au nom donné en dernier paramètre. De cette façon, si la méthode construire est de nouveau appelée avec le même nom de table, elle ne sera pas régénérée mais juste rendue par la Session. Cette fonction est très utile car de nombreuses pages du projet font appel à des tableaux très volumineux, qui prennent parfois plusieurs secondes à s afficher, et il arrive qu un utilisateur souhaite revenir sur le dernier tableau généré ou qu il actualise la page. Il faut juste être méfiant sur quels tableau utiliser cette fonctionnalité, si le tableau est susceptible de changer en temps réel, l utilisateur verra toujours le même. Le code source de la méthode construire est dans l annexe VI. I. Config Ce dossier contient seulement 2 fichiers ; conf.php et hook.php. Comme son nom l indique, conf.php permet la configuration de tout le projet avec un ensemble de variables statiques, il permet dans notre cas de : - Définir le niveau de debug utilisé. - Définir la langue utilisée par défaut par le fichier de libellés et de messages. - Définir des tailles de bannières rotatives (utilisées ponctuellement en tant que filtre pour des listes). - Définir l état du site, techniquement, c est un entier pouvant prendre plusieurs valeurs indiquant l état du site (en fonction, maintenance, etc ). - Définir la clef de Session pour empêcher les conflits de Sessions. - Définir la base de données utilisée. Figure 22 déclaration de la base de données - Définir les règles de redirection avec l objet Router. - Définir les droits d accès des types d utilisateur pour chaque contrôleur voire pour chaque action. 29 P a g e

31 Figure 23 array de déclaration des droits. L array est donc divisé en entiers, chaque entier correspond à un type d utilisateur. 0 correspond à un utilisateur non connecté, 1 à un affilié, 2 à un annonceur, etc On peut encore définir dans le futur d autres types. Pour chaque utilisateur, on déclare soit un contrôleur ; cela veut dire que cet utilisateur a le droit d accès pour chaque action de ce contrôleur. Ou, on déclare un contrôleur et une action, tous deux séparés d un «/» comme s il s agissait d un chemin. Cela ne laisse le droit d accès qu à l action précisée. C est dans le hook que sert cet array de droits, en effet, le hook est inclus dans le constructeur du contrôleur et consiste en une simple boucle de vérification, si le contrôleur et l action sont absents dans le tableau des droits de ce type d utilisateur, l utilisateur est redirigé vers l accueil, avec un message l invitant à se connecter ou créer un compte adéquat. Le code de hook.php se trouve en annexe VII. J. i18n I18n est le nom donnée aux fichiers de libellés dans les systèmes Unix. Ce nom correspond en fait à internationalisation (il y a 18 lettres entre le «i» du début et le «n» de la fin). Ce dossier contient donc des fichiers de libellés. C est eux qui définissent tous les textes affichés. Il y a pour l instant 4 fichiers ; 3 pour chaque type d utilisateur (affilié, annonceur et administrateur) et un pour définir lequel doit être chargé. Contrairement au site existant, on ne charge pas systématiquement la totalité des libellés pour éviter de surcharger le système. Chaque type d utilisateur n a besoin que d un nombre limité des messages disponibles sur la totalité du projet. Cette vérification n est qu une simple condition sur le type d utilisateur défini en Session. Pour l instant, la totalité des libellés est stockée dans celui des affiliés. Ce fichier rassemble donc 3 arrays : - Le premier pour les messages d information et/ou de succès. - Le deuxième pour les messages d erreur. - Le troisième pour les libellés des liens et autres objets html. Ils sont évidemment de degré 2 car ils doivent supporter plusieurs langues, tout en gardant les mêmes numéros pour que le changement soit dynamique sur un simple clic de bouton par exemple. 30 P a g e

32 Figure 24 extrait des messages d erreur d affilielib.php 31 P a g e

33 V. Travaux de développement A. Règles de codage à suivre La nature de notre travail étant diverse, nous nous devions d imposer des règles de codage à suivre pour chaque développeur. D autant plus que de nombreux intervenants seront amenés à revenir sur le code produit pour le site existant. Le texte détaillant les règles de codage est dans l annexe VIII. Dans la suite de ce document je vais présenter le travail que j ai pu accomplir seul. Mes sujets de développement sur le site existant étant nombreux, la partie du document sur ce travail en reflète l essentiel. La suite traitera également des parties développées sur le projet, qui, je le rappelle, est censé s inspirer de l interface d affiliation en place. Pour ne pas alourdir considérablement la quantité d images dans ce document, les captures des fonctions présentées dans la suite ne seront que ceux du projet. La comparaison avec le site existant est néanmoins intéressante, donc les captures du rendu des fonctions qui ont inspiré ceux du projet sont en annexe IX. B. Programmation sur le projet et résultats obtenus Avec le temps qu il nous restait après la conception du projet, ainsi que la mise en place de l architecture MVC personnalisée présentée plus tôt, mon collègue de stage et moi avons développé l interface d affiliation inspirée de l existant. Avant cela, présentons le style utilisé pour notre projet, n étant pas dans les objectifs définis par le cahier des charges, le style à volontairement était délaissé, mais nous ne pouvions nous permettre de développer un site Internet totalement vide de style. Voilà pourquoi nous avons installé le Bootstrap de Twitter. Comme son nom l indique, le Bootstrap de Twitter est une base d amorçage de style. Relativement complète et moderne pour un site Internet, il est très facile d emploi, et rapidement utilisable. Il consiste en un ensemble de feuilles de styles, et propose même des plugins jquery pour un rendu dynamique. Il est aujourd hui très populaire dans la communauté web et est facilement modifiable. Voici quelques points forts de Bootstrap : - Responsive design : peu importe la taille de l'écran de l'internaute, la page est toujours adaptée pour offrir un rendu optimisé et agréable. - Compatibilité : le framework a été conçu pour pouvoir être compatible avec de nombreux navigateurs (même IE7) et supports. Depuis la seconde version, la compatibilité est même garantie pour les tablettes et smartphones. - Plugins jquery : des plugins jquery sont conçus pour le framework. Cela permet ainsi une propreté et une simplicité dans le code. 32 P a g e

34 - Conçu avec LESS : c'est un outil très pratique qui étend CSS en lui offrant plus de possibilités que l'on ne peut avoir avec lui seul, avec par exemple des variables, des fonctions etc. B.I Contrôleur Campagne Figure 25 Exemple d utilisation de LESS Le contrôleur qui m aura pris le plus de temps à développer, est celui de l affichage des Campagnes. Il remplit les fonctions FS1, FS9, et FS13 avec un total de douze actions. Le contrôler Campagne nous permet de : - Rechercher une ou plusieurs campagnes selon divers critères séparés par des espaces, qui peuvent aller du numéro de la campagne, son nom, son descriptif abrégé et son descriptif complet. - Afficher une liste de campagnes selon un type de diffusion (tous les types ont été définis dans la partie I.B) - Afficher une liste de campagnes selon une catégorie, les catégories sont stockées en base de données, donc le menu peut changer en temps réel d où l utilité de la fonction getmenu. - Afficher une liste de campagnes selon un type de rémunération (tous les types ont été définis dans la partie I.B). - Postuler à une ou plusieurs campagnes avec ses bases ou ses sites. Figure 26 Page de postulation - Accéder à une liste des catalogues produit. - Accéder à une liste des codes promotionnels. 33 P a g e

35 - Afficher la liste des campagnes exclusives. - Afficher la liste des nouvelles campagnes. - Afficher une liste de campagnes selon leurs pays d origine. La liste des campagnes est un tableau relativement complexe à construire dans la mesure où, le nombre d informations affichés pour chaque campagne est important. Il est analogue à celui qui existe sur le site actuel. Figure 27 Exemple de tableau de campagnes (projet) Comme on le voit par rapport au tableau original, l esprit général du rendu a été conservé, les tableaux présentent la même structure. Le tableau du projet a été construit grâce au helper Table. Une des contraintes du développement de ce contrôleur devait être l utilisation d extensions html pour chaque liste de campagnes générées (ce fut également le cas pour le contrôleur de description des campagnes). Pour cela, j ai dû recourir à l utilisation de fichiers htaccess pour rediriger les url avec l extension html au fichier PHP adéquat. Ceci à pour utilité d augmenter la visibilité de ces pages dans les moteurs de recherche. En effet, les fichiers html sont mieux indexés dans les moteurs de recherche. Donc, les liens des menus sont des fichiers html mais nous sommes évidemment redirigés sur une page PHP. B.II Contrôleur Description Campagne Le prochain contrôleur que j ai eu l occasion de développer est le contrôleur de la description des campagnes. Il remplit les fonctions FS12 et FS14 avec un total de 12 actions. La difficulté majeure fut de développer un menu adéquat à chaque type de campagne, celles qui ont un script mailing, ou encore celles présentant des bannières rotatives. La méthode getmenu de ce contrôleur est donc plutôt volumineuse, avec de nombreux accès à la base de données via le modèle. Ceci étant, car à partir de la description d une campagne il faut pouvoir accéder à toutes les possibilités offertes par cette-dernière. D autant plus si la candidature d un affilié a été acceptée pour la campagne. 34 P a g e

36 Il faut par exemple pouvoir (s ils existent) accéder aux codes promotionnels ou encore aux catalogues produits de cette campagne, voire les bannières rotatives, les visuels, etc B.III Autres contrôleurs Figure 28 Aperçu de la description d une campagne Lors du développement j ai aussi eu à créer des contrôleurs de taille plus réduites, tels que celui gérant la connexion et la déconnexion d un utilisateur, ainsi que la page d accueil reprenant les textes de l existant. Figure 29 Page de connexion 35 P a g e

37 Figure 30 Page d accueil C. Travail effectué sur le site existant La nature de mon travail sur le site existant est relativement variée, l essentiel était la maintenance et l amélioration de tableaux comptables, et de monétisation sur les trois interfaces. Leur nombre étant très important, je ne vais que présenter ceux qui m ont pris le plus de temps, et ceux représentant le mieux la totalité de mon travail. Le premier est le tableau de monétisation de l interface administrateur, il permet de voir les résultats des shoots internes et en marque blanche, en filtrant sur les campagnes ou leurs catégories ou encore l annonceur etc Figure 31 Filtres du tableau de monétisation 36 P a g e

38 On voit ci-dessus les différents filtres applicables, la possibilité d exporter le tableau sous format Excel est également possible. Le tableau généré contient un nombre conséquent d informations utiles aux employés du département de comptabilité. Figure 32 Résultats du tableau de monétisation Ce tableau présente un total de 19 colonnes avec des informations sur les différents coûts et gains d un shoot (série de mails) fait avec une campagne, et une base de contacts. Le système de ce même tableau a été repris et adapté pour une utilisation dans l interface affilié. Quelques exemples d autres travaux (captures en annexe X) : - Gestion des statistiques des annonceurs avec validation ou refus des résultats des affiliés diffusant la campagne sélectionnée, implémentation de fonctions JavaScript pour la mise à jour dynamique des tableaux lors d une modification (Captures A). - Création de factures affiliées au format PDF, et envoi par mail en pièce jointe (Captures B). - Création de tableaux statistiques, avec possibilité de créer des factures directement depuis le tableau (Captures C). - Amélioration de tableaux pour les annonceurs, détaillant les transactions relatives à une ou plusieurs de leurs campagnes. La procédure pour valider les transactions est simplifiée, car ne nécessite plus la validation systématique de chaque transaction. Il est désormais possible d en valider, ou d en refuser plusieurs en fournissant un motif (Captures D). - Fonction de génération de fichier Excel (Captures E). 37 P a g e

39 Ce qu il faut finalement retenir, c est que malgré le grand nombre de moyens techniques utilisés pour satisfaire les besoins des différents demandeurs, la problématique observée était souvent la même. Le travail demandé étant souvent un tableau statistique, il fallait absolument veiller à la performance et l optimisation du code. Les calculs effectués pour construire ces tableaux étaient souvent complexes, et difficiles à mettre en œuvre, et demandent beaucoup de ressources. Il était donc très facile de ne pas tenir compte de la performance en se concentrant uniquement sur les résultats. Mais, un code trop gourmand peut même rendre le serveur indisponible, ou le tableau inutilisable, le temps nécessaire à l affichage étant trop important. Il faut par exemple veiller à ne pas recueillir des informations inutiles depuis la base de données, choisir quels champs il est nécessaire de récupérer, et enfin veiller à l optimisation des boucles, et minimiser leur nombre. Un autre point sur lequel j ai pu participer, est le développement d un jeu concours pour un annonceur. Ma participation ne fut que mineure par rapport à mon collègue de stage qui l a quasiment entièrement développé. Il faut noter qu il a été conçu avec l architecture MVC personnalisé présenté plus tôt, il a par conséquent servi à tester ce système avant sa mise en application pour notre projet. Figure 33 Page d accueil du jeu concours 38 P a g e

40 D. Difficultés rencontrées sur le site existant Quand il était question de développer de nouvelles fonctionnalités pour le site web existant, les difficultés étaient souvent les mêmes, et, je n étais personnellement pas habitué à gérer ce genre de problématique. Il faut savoir que la plateforme de SponsorBoost se doit de fonctionner sur tous les navigateurs, en effet la seule vitrine dont dispose la société est leur site Internet. Il est donc indispensable de veiller au bon fonctionnement de chaque amélioration développée, ainsi que la conservation d une mise en page agréable. Une autre difficulté à laquelle je ne m attendais pas, est le besoin de résultats rapidement. Il est évident que si l on nous demande de créer une fonction ou de résoudre un problème, c est qu elle émane d un besoin qui ne peut généralement pas attendre indéfiniment. Il a donc fallu que je sache m approprier rapidement d un code faisant souvent plusieurs milliers de lignes, et de le comprendre, afin de trouver rapidement une solution au besoin exprimé, tout en veillant à la compatibilité des modifications sur tous les navigateurs. E. Difficultés rencontrées sur le projet Lors des développements sur le projet, la mise en page et le style étaient un aspect secondaire, d autant plus qu ils étaient largement simplifiés par le fonctionnement de Bootstrap présentant un rendu quasi parfait sur tous les navigateurs. La principale difficulté que l on a pu rencontrer, était l utilisation de notre système MVC. Ce système est certes très performant et sépare bien les ressources utilisées, mais nécessite néanmoins un certain temps d adaptation car n est pas naturel pour les développeurs débutants. La formation sur l architecture MVC que nous avions pu avoir dans plusieurs matières à l IUT nous a tout de même grandement simplifiée la transition. Il a également fallu faire preuve de vigilance par rapport aux besoins du projet. Chaque texte doit systématiquement être mis en libellés, les droits de chaque action doivent être connus, et on doit utiliser au maximum les helpers et aucun code ne doit être redondant. F. Tests Autant pour le développement sur le site existant, que pour le projet, les tests effectués se résumaient essentiellement à des tests fonctionnels. La raison est que pour le site existant, le besoin de résultats était pressant. Il est évident que nous ne disposions pas du temps nécessaire pour mettre en place une batterie de tests unitaires. D autant plus, que jusqu ici la société n en a pas eu recours, mais que le système est prévu dans le futur pour s intégrer dans git, et s exécuter automatiquement après configuration et qui se baserait sur le framework Atoum. Le fonctionnement de git facilite grandement le déroulement des tests car permet de changer d environnement aisément. Pour tester une fonctionnalité, il faut la plupart du temps des données cohérentes dans la base de 39 P a g e

41 données, ce qui est rarement le cas sur le serveur de développement. Au fur et à mesure des tests, la cohérence de la base de données que l on utilise pour nos travaux, ne reflète plus celle qui est utilisée par le site Internet. Nous nous contentions donc d utiliser une branche adaptée pour tester nos fonctionnalités, avec la personne dont la demande a émané. Ce qui consistait en la création de données de tests, et la vérification du bon fonctionnement dans tous les cas de figure. En ce qui concerne le projet, la majorité du développement étant consacré à la mise au point du système MVC. Pour tester le bon fonctionnement de notre architecture, ce qui ne pouvait être délaissé au vu de la complexité du système était effectué grâce à l helper debug. Cet helper nous permet de placer des points de repère à des endroits stratégiques du code, afin de vérifier l état de l environnement dans chacun de ceux-ci. C'était finalement un système de backtrace * personnalisé qui se présentait comme une liste de points de passages. Ce système était plus rapide et lisible que l arrêt planifié d un code à un point donné, car on pouvait personnaliser le contenu de ce backtrace : Figure 34 fonction debug Figure 35 Résultat debug 40 P a g e

42 On voit sur cette capture le déroulement de l affichage d une page que l on a pu expliquer plus tôt. Le dispatcher est appelé par l index, qui initialise le contrôleur, qui lui, initialise la vue (description). La fonction peut aussi afficher le contenu de variables, ici le contenu de la Session à ce moment-là. On voit d ailleurs rapidement le problème, la variable «user» est vide, ce qui empêche le fonctionnement de la description. 41 P a g e

43 VI. Finalité du stage A. Planning final et différentiel des objectifs Comme on a pu le voir tout au long de ce document, les besoin exprimés initialement par la MOA ont été amenés à changer. De ce fait, le planning initial prévu dans le cahier des charges a été modifié. Figure 36 Planning final Il n a donc effectivement duré que 9 semaines, la majeure différence mis à part cela, est la période qui a suivi la fin de la conception. En effet, après la mise en place de git, le développement se sera fait en parallèle avec la phase de tests pour les raisons expliquées plus haut. Initialement, le cahier des charges de notre projet ne stipulait pas la nécessité d instaurer une nouvelle architecture pour le site Internet. Il imposait seulement l utilisation de la programmation orientée objet. Mais, pour les raisons que nous avons explicitées, ce n était pas viable. Donc, l apparition de l architecture MVC a changé les objectifs de ce projet. Alors que l objectif était de proposer une nouvelle version de toute l interface d affiliation, ce n était plus le cas une fois cette contrainte ajoutée. L objectif final était alors devenu la conception et le développement de cette base, respectant toutes les contraintes relatives aux nouveaux besoins exprimés par la MOA et détaillés dans la présentation du projet. Une fois cet objectif accompli, il fallait avec le temps qu il nous restait, développer le maximum de fonctionnalités définies par la conception. Il n y avait donc aucune exigence par rapport à la finalité ou non de l interface d affiliation, car on ne pouvait prévoir exactement la durée que prendrait le développement de l architecture. 42 P a g e

44 B. Quantification Malgré la liberté donnée par rapport à l avancement de l interface d affiliation, nous avons tout de même produit un certain nombre de fonctionnalités. Nous avons rempli au total 9 fonctions sur les 14 demandées, dont 2 sont encore en développement. Voici les fonctions que remplissent les contrôleurs existants, ainsi que le nombre de lignes (les contrôleurs ne sont que du PHP): Contrôleur Fonctions remplis Nombre de lignes Auteur Campagne 1, 9, 13, DescriptionCampagne (en développement) Stats (en développement) Profil 2, Inscription Accueil - 50 Connexion Christian Pavinich Christian Pavinich Kévin Couard Kévin Couard Kévin Couard Christian Pavinich Christian Pavinich Total 9 fonctions Figure 37 Tableau des contrôleurs La totalité du projet fait 2910 lignes (code PHP et JavaScript compris), sans compter les 4770 lignes des contrôleurs. S ayant efficacement réparti les tâches, le nombre de lignes que j ai pu développer est de 1455, plus les 2613 lignes de contrôleur. J ai donc produit un total de 4068 lignes seulement pour le projet. En ce qui concerne mon travail sur le site de SponsorBoost, le rapport de git fait part de 4486 lignes développées. 43 P a g e

45 Conclusion Au cours de mon stage à SponsorBoost, mes sujets de travail ont été multiples. J ai pu apprendre de nombreuses choses à propos de la publicité sur Internet, et plus généralement, de la vie en entreprise. Non seulement, nous avons eu à développer avec mon collègue un projet Informatique de grande ampleur, mais nous avons aussi participé à la vie de la société. Et, plus encore, avons pu réellement assister l activité dans le département technique. Initialement, ma crainte était d être livré à moi-même avec un projet volumineux à produire. Ça n a pas été le cas, j ai eu l agréable surprise de pouvoir participer à l effort de production de la société. Mon travail était suivi, et j étais conseillé au début sur la marche à suivre, pour acquérir au final une autonomie complète. J ai pu également donner mon avis pour le projet que nous devions effectuer, nous avons tous partagé nos points de vue, pour finalement aboutir sur les changements d objectifs expliqués dans ce rapport. Il a été intéressant de construire les bases d un projet à long terme, savoir que ce que l on a pu créer servira à d autres développeurs dans un travail futur, à une échelle complétement différente. Que ce soit pour les outils utilisés ou notre manière de travailler, la MOA et la MOE nous a laissées totalement libre de choisir les méthodes de travail les plus adaptées à ce que l on voulait. Bien sûr, à condition qu elles soient justifiées. Au final, ce stage m a permis d apprendre et de découvrir de nouvelles dimensions. J ai pu mettre en application les connaissances acquises tout au long de mes deux années de DUT, et me rendre réellement compte de l utilité de certaines notions, dont je pouvais parfois douter de l utilité. Je remercie encore M. Louis Houette et M. Philippe Vasseur de m avoir donné la possibilité de faire ce stage, et même de le poursuivre jusqu au 5 juillet. L expérience retenue me servira jusqu à la fin de mes études, et de ma vie professionnelle future. 44 P a g e

46 Glossaire JavaScript : JavaScript est un langage de programmation de scripts principalement utilisé dans les pages web interactives mais aussi côté serveur. jquery : jquery est une bibliothèque JavaScript libre qui porte sur l'interaction entre JavaScript (comprenant Ajax) et HTML, et a pour but de simplifier des commandes communes de JavaScript. La première version date de janvier PDF : Le Portable Document Format, communément abrégé en PDF, est un langage de description de pages créé par la société Adobe Systems et dont la spécificité est de préserver la mise en forme d un fichier. Pop-up : Un pop-up (de l'anglais pop-up window ou pop-up tout court), parfois appelée fenêtre surgissante ou fenêtre intruse est une fenêtre secondaire qui s'affiche, parfois sans avoir été sollicitée par l'utilisateur (fenêtre intruse), devant la fenêtre de navigation principale lorsqu'on navigue sur Internet. Html : L Hypertext Markup Language, généralement abrégé HTML, est le format de données conçu pour représenter les pages web. C est un langage de balisage qui permet d écrire de l hypertexte, d où son nom. PHP : Le PHP: Hypertext Preprocessor3, plus connu sous son sigle PHP, est un langage de scripts libre principalement utilisé pour produire des pages Web dynamiques via un serveur http. SQL : SQL (sigle de Structured Query Language) est un langage informatique normalisé servant à effectuer des opérations sur des bases de données. Ruby on rails : Ruby on Rails, également appelé RoR ou Rails est un framework web libre écrit en Ruby. Il suit le motif de conception Modèle-Vue-Contrôleur aussi nommé MVC. Généricité : En programmation, la généricité d'une fonction repose sur son indépendance vis-à-vis du type, et éventuellement du nombre de ses arguments. Polymorphisme : En informatique, le polymorphisme est l'idée d'autoriser le même code à être utilisé avec différents types, ce qui permet des implémentations plus abstraites et générales. MOE : Le terme maîtrise d'œuvre (souvent abrégé MOE ou MŒ) désigne une personne ou entité chargée de la conduite opérationnelle de travaux. MOA : Le maître d'ouvrage (abrégé en MO ou MOA) ou la maîtrise d'ouvrage est le donneur d ordre au profit duquel l ouvrage est réalisé. Cahier des charges : Un «cahier des charges» est un document contractuel décrivant ce qui est attendu du maître d'œuvre par le maître d'ouvrage. 45 P a g e

47 Tracking : Le tracking publicitaire est un dispositif permanent de mesure d efficacité publicitaire consacré à une marque ou un secteur d activité. Routage : Le routage est le mécanisme par lequel des chemins sont sélectionnés dans un réseau pour acheminer les données d'un expéditeur jusqu'à un ou plusieurs destinataires. Marque blanche : Une marque blanche repose sur le principe commercial de mise à disposition d'outils sans citer la marque ni l'origine de l'information transmise. Cible : Individu qui peut potentiellement interagir avec une campagne publicitaire diffusée par un annonceur Cookie : En informatique, un cookie (aussi appelé témoin) est défini par le protocole de communication HTTP comme étant une suite d'informations envoyée par un serveur à un client, que ce dernier retourne lors de chaque interrogation du même serveur. Session : En informatique et en télécommunication, une session est une période délimitée pendant laquelle un appareil informatique est en communication et réalise des opérations au service d'un client - un usager, un logiciel ou un autre appareil. Versioning : Processus permettant de conserver une trace des modifications successives apportées à un fichier numérique. Backtrace : Trace des fonctions appelées par un programme, affichées pour le débugger. Apache : Apache HTTP Server, souvent appelé Apache, est un logiciel de serveur HTTP produit par l'apache Software Foundation. C'est le serveur HTTP le plus populaire du Web. C'est un logiciel libre avec un type spécifique de licence, nommée licence Apache. Métaclasse : En programmation, une métaclasse est une classe dont les instances sont des classes. Autrement dit, une métaclasse est la classe d'une classe. Superglobale : Les Superglobales sont des variables internes qui sont toujours disponibles, quel que soit le contexte UML : UML (en anglais Unified Modeling Language ou «langage de modélisation unifié») est un langage de modélisation graphique à base de pictogrammes. Il est apparu dans le monde du génie logiciel, dans le cadre de la «conception orientée objet». 46 P a g e

48 Bibliographie Wikipedia ( a été utilisé pour les définitions suivantes du glossaire : - UML - Métaclasse - Apache HTTP Server - Session - Marque blanche - Routage - MOE - MOA - Polymorphisme - Généricité - Ruby on Rails - SQL - PHP - HTML - Pop-up - PDF - jquery - JavaScript Comment ça marche Cahier des charges : Définitions-marketing Tracking : Techno-science Cookie : Journaldunet Versioning : Wiktionary Backtrace : PHP Les superglobales : 47 P a g e

49 PHP Les superglobales : Journaldunet Qu'est-ce que le reciblage publicitaire? : Visual Paradigm : Wikipedia MVC : Twitter Bootstrap, from Twitter : siteduzero La seconde version de bootstrap : slideshare Atoum le framework de tests unitaires pour php 5.3 : git-scm : Jean Engels PHP5 cours et exercices : 48 P a g e

50 Table des annexes Annexe I : Diagramme de classes initial. Annexe II : Diagramme de classe final. Annexe III : Code source de la méthode find de Model.php. Annexe IV : Code source de l helper form.php. Annexe V : Array type à passer à la méthode construire de l helper Table.php. Annexe VI : Code source de la méthode construire de Table.php. Annexe VII : Code source de hook.php. Annexe VIII : Règles de codage. Annexe IX : Captures des fonctions existantes sur le site Internet (pour la comparaison avec le projet). Annexe X : Différentes captures de fonctions développées sur le site Internet 49 P a g e

51 Annexe I. Diagramme de classes initial 50 P a g e

52 Annexe II. Diagramme de classes final 51 P a g e