rapport de stage

P a g e | 2

Labiedh Kais Rapport du projet de Stage ouvrier ENIT 2014 - 2015

Il apparaît opportun de commencer ce rapport de

stage par des remerciements, à ceux qui m’ont

beaucoup appris et même à ceux qui ont eu la

gentillesse de faire de ce stage un moment très

profitable. En premier lieu, mes remerciements les plus

respectueux vont à Mr Taher HAOUET, le directeur

de l’entreprise, pour m’avoir accueillie.

J’exprime toute ma gratitude aux membres de ce jury

qui m’ont fait l’honneur d’accepter de juger mon

travail.

Je ne peux pas oublier de remercier tous mes

enseignants pour la qualité de l’enseignement qui

nous a été dispensé.

P a g e | 3


AJAX Asynchronous Javascript And XML

CSS Cascading Style Sheet

DAO Data Access Object

ENIT Ecole Nationale d’Ingénieurs de Tunis

FAQ Frequently Asked Questions

HTML Hypertext Markup Language

HTTP HyperText Transfer Protocol

MVC Model-View-Controler

ORM Object-Relational Mapping

PHP Php Hypertext Processor

SEA Search Engine Advertising

SEA Serach Engine Optimization

SQL Structured Query Language

UML Unified Modeling Langage

XML eXtensible Markup Language

YAML YAML Ain’t Markup Language

P a g e | 4


....................................................................................................................... 2

............................................................................................................................. 3

.................................................................................................................. 4

..................................................................................................................... 6

....................................................................................................................... 7

..................................................................................... 9

................................................................................................................................ 9

................................................................................................ 9

. ..................................................................................................................................... 9

............................................................................................................................................ 9

................................................................................................................... 9

........................................................................................................................................ 9

..................................................................................................................................... 10

................................................................................................................................ 10

.............................................................................. 11

.............................................................................................................................. 11

............................................................................................................ 11

................................................................................................................................ 11

....................................................................................................... 11

............................................................................................................ 12

...................................................................................... 12 ....................................................................................................... 12

.................................................................................................... 13

...................................................................................... 15

.............................................................................................................................. 15

................................................................................................................. 15

..................................................................................................................... 15

................................................................................................................. 16

.............................................................................................................................. 16

................................................................................................................................... 17

........................................................................................................................ 19 .............................................................................................................................. 20

................................................................................................................................... 21

................................................................................................................................ 23

....................................................................................................... 24

P a g e | 5


.............................................................................................................................. 24

.......................................................................................................... 24

.............................................................................................................................. 24

............................................................................................................................... 24

........................................................................................................................... 25

....................................................................................................................... 25

................................................................................................................................ 32

...................................................................................................................... 34

P a g e | 6


Figure 1:Diagramme de cas d'utilisation réduit .............................................................................. 12

Figure 2:Architecture MVC ................................................................................................................ 16

Figure 3:Diagramme de paquetages ............................................................................................... 17

Figure 4:Diagramme de classe de la couche modèle ................................................................... 18

Figure 5: Diagramme d'état de transition d'une publication dans le forum de discussion ...... 20

Figure 6:Diagramme de séquence relative à la consultation de contenu de cours.................. 21

Figure 7:Diagramme d'activité d'une authentification/inscription ................................................ 22

Figure 8:Diagramme d'activité relative au Forum de discussion ................................................. 23

Figure 9:Interface d'accueil ............................................................................................................... 26

Figure 10:Interface d'authentification............................................................................................... 27

Figure 11:Interface d'inscription ....................................................................................................... 27

Figure 12:Interface représentant le contenu d'un cours ...................................................................... 28

Figure 13:Interface représentant un exemple de document ................................................................ 29

Figure 14: Interface représentant la liste des sujets dans le Forum ..................................................... 30

Figure 15:Interface représentant une discussion .................................................................................. 30

Figure 16: Interface de la partie administration ................................................................................... 31

Figure 17:Interface représentant la partie gestion des abonnés .......................................................... 32

P a g e | 7


Tableau 1:Présentaion des acteurs de la méthode SCRUM .................................................................. 10

Tableau 2:Description textuel du cas d'utilisation <<s'authentifier>> .................................................. 13

Tableau 3:Description textuel du cas d'utilisation <<gestion des utilisateurs>> .................................. 14

Tableau 4:Modéle MVC ......................................................................................................................... 15

P a g e | 8


Ce stage présente un chemin très riche par des informations et des expériences

pour que l'étudiant puisse employer ses compétences dans une ambiance

professionnelle et bien encadrée.

Pendant quatre semaines, j'ai réussi à atteindre mes objectifs de rassembler le

plus grand nombre possible d'informations et de les employer convenablement dans

la création de mon application web.

Le but de ce rapport n'est pas de faire uniquement une présentation exhaustive

de tous les aspects techniques que j'ai pu apprendre ou approfondir mais aussi, de

manière synthétique et claire, de faire un tour d'horizon des aspects techniques et

humains auxquels j'ai été confronté.

J'ai exposé dans ce rapport en premier lieu une présentation de cadre de projet,

ensuite, j'ai présenté la partie d’analyse et spécification des besoins et par suite la

partie conception et enfin, la partie réalisation.

P a g e | 9


Ce chapitre a pour objectif de situer le projet dans son contexte général à savoir

l’organisme d’accueil et le sujet à traiter. Dans la première section, nous donnons

une brève présentation de l’organisme d’accueil Sedra Info Solution. Dans la

deuxième section, nous décrivons le sujet à traiter et les objectifs à atteindre.

Créé en 2012, Sedra info solution sa tendance principale c’est le webmarketing, elle

offre à ces clients des solutions du marketing digital basées sur les derniers

innovations technologiques afin d’arriver à améliorer leur stratégie marketing fasse

au concurrents sur le web.

Notre vision au niveau des services que nous offrons commence par les idées pour

arriver enfin à offrir un produit fini, on passant par différent states de création

commencent par le développement du site web jusqu’à la commercialisation de

l’image des entreprises de nos clients.

L’activité de Sedra Info Solution couvre les prestations suivantes :

Identité visuelle, Architecture commerciale, Design Global, Design Produits et

d’environnement, PLV/Merchandising, Marketing Opérationnel.

Nous allons présenter dans cette partie le sujet du stage pour bien le comprendre et

délimiter ce qui est demandé pour répondre aux spécifications d’une façon concise et

efficace

Le projet est intitulé « Développement d'une plateforme e-learning», il rentre dans le

cadre de mon stage d’ouvrier de la 1ere année du cycle d’étude ingénieur en

informatique à l’Ecole National d’Ingénieur de Tunis (ENIT) .Il s'agit de développer

une application Web destinée à la formation et apprentissage en ligne à travers les

cours publiés sous différents types, par différents experts et enseignants.

P a g e | 10


Pour assurer la bonne gestion du travail et afin d’améliorer la productivité de

l’équipe on a choisi la méthodologie SCRUM .

*Scrum : une méthode agile dédiée à la gestion de projets.

*Sprint : une méthode d'analyse de risque.

*product owner : Ce dernier est en charge de communiquer la vision globale

du produit à l’équipe. Il se doit de représenter le client final, se mettre à sa place et

donc de prioriser ses besoins.

*Scrum Master : Ce dernier agit en tant que facilitateur entre le responsable

produit et l’équipe (Product owner).

*Equipe projet : Dans la méthode Scrum, l’équipe est responsable de la

réalisation opérationnelle des travaux.

Role Acteur Mission L’équipe Labiedh kais

Maalej Ahmed Conception et développement de l’application

Product owner

Taher haouet Réunion avec le client pour dégager les besoins et présenter le travail final

Scrum Master

Taher haouet Suivi de l’avancement du projet, validation et planification des taches

Tableau 1:Présentaion des acteurs de la méthode SCRUM

Tout au long de ce chapitre, nous avons pu situer notre projet dans son cadre

général à savoir l’organisme d’accueil, la présentation du projet et ses objectifs et la

méthodologie adoptée pour parvenir à ces objectifs.

Dans le chapitre suivant, nous allons présenter l’analyse et spécification des besoins

de notre projet.

P a g e | 11


La réussite de tout projet dépend de la qualité de son départ. De ce fait, l’étape de

spécification des besoins constitue la base de départ de notre travail, elle doit décrire

sans ambiguïté le logiciel à développer.

Pour assurer les objectifs attendus, il est essentiel que nous parvenions à une vue

claire des différents besoins escomptés de notre projet. Au cours de ce chapitre,

nous allons dégager les fonctionnalités attendues du module en définissant les

différents cas d’utilisation.

*Administrateur :

Notre application web doit permettre aux administrateurs dans un premier lieu de

consulter les tableaux de bords des cours, des évènements, des discussions et des

utilisateurs.

*Acteurs :

Etudiant : Ce sont les utilisateurs qui interviendront souvent dans notre application

vu que l’application leur est destinée en premier lieu. Ils peuvent notamment

consulter les cours, voir les chapitres d’un cours, poser une question dans le forum,

gérer leur abonnements, etc.

Enseignant : il a le privilège d’ajouter un cours, un chapitre, répondre aux questions

des élèves dans le forum.

Gestionnaire : son rôle est de gérer cette plateforme. Il s’occupe de la supervision

du forum, la gestion des évènements, la gestion de cours,

Les besoins non fonctionnels représentent les exigences implicites auxquelles le

système doit répondre. Pour le bon fonctionnement de notre projet, nous avons

dégagé les besoins non fonctionnels suivants :

- L’interface doit être ergonomique, conviviale et facile à utiliser.

– Le système doit être sécurisé.

– Le temps de traitement doit être acceptable.

P a g e | 12


Nous avons opté la méthode orientée objet pour spécifier les besoins de notre client.

Nous exposons dans cette partie, les diagrammes de cas d’utilisation que nous

détaillerons à travers une description textuelle.

Figure 1:Diagramme de cas d'utilisation réduit

P a g e | 13


Pour bien décrire les cas d’utilisation de la section précédente, nous allons présenter

dans cette partie une description textuelle de principales utilisations sous forme d’une

fiche descriptive.

Titre S’authentifier

Résumé Permettre aux utilisateurs de la plateforme de s’authentifier pour y accéder.

Acteurs Etudiant, enseignant, gestionnaire et administrateur

Pré-condition L’utilisateur possède déjà un compte.

Scénario nominal 1. L’utilisateur saisit son identifiant et son mot de passe. 2. Le système vérifie la correspondance de l’identifiant avec le mot de passe. 3. Si la correspondance est trouvée, le système vérifie l’état du compte (actif/bloqué) 4. En cas de succès, le système explore les fonctionnalités accessibles par cet utilisateur en fonction des rôles qui lui sont affectés.

Scénario alternatifs E1 : Correspondance non trouvée 1. Le système affiche le message « correspondance non trouvée » et le scénario reprend de 1. E2 : Compte bloqué 1. Le système affiche le message « Compte bloqué » et le scénario reprend de 1.

Tableau 2:Description textuel du cas d'utilisation <<s'authentifier>>

P a g e | 14


Titre Gérer les utilisateurs

Résumé Permettre à l’administrateur de l’application de gérer les utilisateurs de la plateforme (ajout, suppression, modification).

Acteurs Administrateur

Pré-condition L’utilisateur est authentifié en tant que administrateur

Scénario nominal 1. Consulter la liste des utilisateurs L’administrateur demande la liste des utilisateurs. Le système retourne la liste de tous les utilisateurs ainsi que les informations relatives. 2. Ajouter un utilisateur L’administrateur demande d’ajouter un nouvel utilisateur, il choisit le type d’utilisateur à ajouter et remplit le formulaire d’ajout retourné par le système. Le système valide les informations saisies et confirme l’ajout de l’utilisateur en cas de réussite. 3. Modifier un utilisateur L’administrateur choisit un compte à éditer, modifie les informations désirées et demande la modification. Le système valide les informations modifiées et confirme la modification en cas de réussite. 4. Supprimer un utilisateur L’administrateur choisit un compte à effacer. Le système confirme la suppression en cas de réussite.

Tableau 3:Description textuel du cas d'utilisation <<gestion des utilisateurs>>

Ce chapitre nous a permis de couvrir les différents besoins fonctionnels et non

fonctionnels auxquels doit satisfaire notre module. Nous avons aussi détaillé ces

besoins à travers des diagrammes de cas d’utilisation pour passer par la suite à la

conception de notre application qui sera présentée dans le chapitre suivant.

P a g e | 15


Dans le présent chapitre, nous allons entamer une partie cruciale du développement

logiciel et qui constitue un pont entre la spécification et la réalisation. Elle comporte la

conception de l’application, nous allons présenter dans un premier temps la

conception générale de notre application, puis la conception détaillée comprenant les

vues statiques via les diagrammes de classes et les vues dynamiques via les

diagrammes de séquences.

Un patron de conception ou un design pattern est un concept destiné à résoudre les

problèmes récurrents du génie logiciel suivant le paradigme objet. Les patrons de

conception décrivent des solutions standards pour répondre à des problèmes

d’architecture et de conception des logiciels par une formalisation de bonnes

pratiques, ce qui signifie que l’on privilégie les solutions éprouvées (un patron de

conception n’est considéré comme « prouvé » qu’une fois qu’il a été utilisé avec

succès au moins dans trois cas).

-MVC Modèle View Contrôle :

Une architecture MVC impose une séparation en 3 couches : le Modèle, les Vues et

les Contrôleurs.

Vue Couche PRÉSENTATION. C’est la présentation graphique de l’application (l’interface utilisateur).

Contrôleur Il gère les différents types d’événements

Modèle Couche MÉTIER. Le modèle est représenté par la couche métier dans laquelle les informations relatives aux différentes entités de l’application seront encapsulées.

Tableau 4:Modéle MVC

-Doctrine :

Est un ORM (couche d'abstraction à la base de données) pour PHP. Il s'agit d'un logiciel

libre sous licence GNU LGPL.

P a g e | 16


Figure 2:Architecture MVC

Dans cette section, nous allons décrire d’une manière générale les différents

éléments constituant notre application à l’aide des paquetages.

P a g e | 17


Figure 3:Diagramme de paquetages

Paquetage Description

Entity Entités ou classes appartenant à la couche modèle. Ces entités sont mappées et persistées à travers l’ORM.

Vue Interfaces utilisateur et présentation.

Contrôleur Contrôle, synchronisation et gestion des évènements

EntityRepository Ce paquetage met en œuvre le patron de conception "Repository".Le repository fait abstraction à la manière dont les données sont connectés aux objets. Indépendamment de la source de données, la couche métier repose sur la repository afin de retrouver, ajouter, mettre à jour ou supprimer un objet du domaine

FormType Génération dynamique des formaulaires associés à leurs entités.

A ce niveau, il est demandé de spécifier chaque paquet de ceux illustrés dans la

partie précédente, et ceci à travers un diagramme de classes illustrant les classes,

leurs attributs et leurs méthodes ainsi que les associations entre eux. Mais, la partie

P a g e | 18


la plus importante est celle qui est relative à la couche modèle de données vue

qu’elle est constituée par les classes persistantes en base de données. Donc, dans

cette partie, nous allons présenter le diagramme de classes de la couche modèle,

puis, nous allons traduire ces diagrammes en schémas relationnels.

Figure 4:Diagramme de classe de la couche modèle

Ainsi, nous obtenons les schémas relationnels suivants :

— Utilisateur (id, identifiant, nom, prenom, email, passe, date_inscription, telephone,

sexe, chemin_image, attentes, derniere_connexion, actif, jeton_confirmation, roles,

domaine_enseignant, grade_enseignant, institut, filiale_etudiant, niveau_etudiant,

P a g e | 19


#parrain_id)

— Contact (id, nom, prenom, objet, message, date_envoi)

— Evenement (id, titre, description, date_debut, date_fin, lieu, chemin_image)

— Discussion (id, titre, message, date_creation, type, actif, #utilisateur_id)

— Commentaire (id, message, date_creation, #utilisateur_id, #discussion_id)

— Chat (id, message, date_creation, #utilisateur_id, #streaming_id)

— Cours (id, titre, description, date_creation)

— Chapitre (id, titre, description, date_creation, auteur, public, difficulte, #cours_id,

#support_cours_id, #exercices_id)

— Video (id, titre, description, date_creation, auteur, public, difficulte, #fichier_id,

#cours_id)

— Streaming (id, titre, description, date_debut, date_fin, integration, auteur, public,

difficulte, #cours_id)

— Attachement (id, nom_original, type_mime, taille, chemin_image)

— Abonnement (id, type, duree, prix)

— Abonnement_Utilisateur (id, #abonnement_id, #utilisateur_id, methode_paiement,

date_creation)

Les diagrammes d’états-transitions permettent de décrire les changements d’états

d’un objet ou d’un composant, en réponse aux interactions avec d’autres

objets/composants ou avec des acteurs.

Le diagramme de la figure 5, montre les différents états par lesquels passe une

publication de type question/réponse au forum de discussion.

P a g e | 20


Figure 5: Diagramme d'état de transition d'une publication dans le forum de discussion

Les diagrammes de séquence permettent de donner une vue dynamique sur

l’interaction entre l’acteur et le système. Nous représentons dans cette section, les

diagrammes de séquences relatives à quelques scénarios d’utilisation de notre

système.

La figure 6 décrit les étapes détaillées à accomplir pour voir le contenu d’un cours.

P a g e | 21


Figure 6:Diagramme de séquence relative à la consultation de contenu de cours

Dans cette partie, nous nous intéressons aux diagrammes comportementaux d’UML. Ces

Diagrammes permettent de modéliser des processus interactifs ou partiels pour des

systèmes donnés. Ils permettent notamment de modéliser les processus métiers (le fameux

Workflow).Nous commençons par montrer le diagramme d’activités relatives aux processus

d’authentification et d’inscription puis celles qui sont relatives aux Forums de discussions.

Une connexion est requise pour pouvoir accéder à quelques parties de la plateforme.

Pour ce faire, l’utilisateur inscrit saisit son identifiant (ou son E-mail) et son mot de

passe qui doivent être vérifiés par le système. S’il s’agit d’un utilisateur non inscrit,

l’utilisateur doit alors s’enregistrer en remplissant le formulaire d’inscription. (Voir

figure 7)

P a g e | 22


Figure 7:Diagramme d'activité d'une authentification/inscription

La figure 8 modélise de diagramme d’activités relatives aux Forums de discussions.

P a g e | 23


Figure 8:Diagramme d'activité relative au Forum de discussion

A travers ce chapitre, nous avons mis en place la conception de notre application. En

premier lieu, nous avons commencé par les patrons de conception utilisés, puis

donner l’architecture de notre travail, enfin, nous avons présenté quelques

diagrammes de classes que nous avons jugés nécessaires pour comprendre le

fonctionnement de notre application.

La conception de notre module étant établie, nous passons maintenant à la phase de

réalisation.

P a g e | 24


Après avoir achevé l’étape de conception de l’application, nous entamons dans ce

chapitre la phase de réalisation. Nous allons présenter, en premier lieu,

l’environnement du travail utilisé pour le développement de l’application, ensuite,

nous allons donner un aperçu sur le travail accompli à travers des captures d’écran.

Afin de réaliser notre module dans les conditions les plus favorables, nous avons mis

à notre disposition un ordinateur ayant la configuration suivante :

- PC ASUS, processeur Intel(R) Core (TM) i5-4210U CPU, 2.4 GHz avec 8Go de

RAM.

Système d’exploitation : windows 7

Espace disque dur : 1 TB

Pour les besoins de notre projet, nous avons utilisé l’outil de modélisation "Enterprise

Architect" qui nous a permis de concevoir l’architecture de notre plateforme ainsi que

les différents diagrammes contenus dans ce rapport.

Développé par Jetbrains cet éditeur, spécialisé dans PHP, offre tout un tas d'outils

pour développer de manière plus efficace et plus propre. Comme tous les IDE sa

configuration peut s'avérer un petit peu complexe, et c'est pourquoi je vous propose

de découvrir ensemble les différents outils qui le composent.

Git est un logiciel de gestion de versions décentralisé. C'est un logiciel libre créé

par Linus Torvalds, auteur du noyau Linux, et distribué selon les termes de la licence

publique générale GNU version 2.

P a g e | 25


Une plateforme de développement Web de type WAMP, permettant de faire

fonctionner localement (sans se connecter à un serveur externe) des scripts PHP.

WampServer n'est pas en soi un logiciel, mais un environnement comprenant deux

serveurs (Apache et MySQL), un interpréteur de script (PHP), ainsi

que phpMyAdmin pour l'administration Web des bases MySQL.

Symfony est un framework MVC libre écrit en PHP 5 destiné majoritairement aux

professionnels du développement. Il fournit des fonctionnalités modulables et

adaptables qui permettent de faciliter et d’accélérer le développement d'un site web.

MySQL est un système de gestion de bases de données relationnelles (SGBDR). Il

fait partie des logiciels de gestion de base de données les plus utilisés au monde,

autant par le grand public (applications web principalement) que par des

professionnels, en concurrence avec Oracle, Informix et Microsoft SQL Server.

-HTML5/CSS3 :

Langages permettant la création et la mise en forme des pages web.

— Materialize UI :

Framework UI basé sur la philosophie de Material design

— AJAX :

Architecture informatique permettant de construire des sites web dynamiques

et interactifs sur le poste client, en se basant sur des appels asynchrones JavaScript

et en se servant de différentes technologies Web (XML, JSON).

— XML, YAML, JSON :

Format de représentation de données.

Cette partie est consacrée à présenter quelques interfaces de l’application réalisée

lors de ce projet.

P a g e | 26


Figure 9:Interface d'accueil

La visibilité ou l'accessibilité dépend d'un cours à un autre. Il existe des cours qui

sont accessibles en mode public et d'autres qui sont privés (accessibles uniquement

par des utilisateurs authentifiés possédant un abonnement valable).

Donc, pour bénéficier de ce contenu privilégié, l'utilisateur doit s'authentifier, saisir

son identifiant et son mot de passe afin de pouvoir être redirigé vers la page d'accueil

et accéder aux différentes fonctionnalités de l'application, selon ses privilèges. La

figure suivante représente l'interface d'authentification d'un utilisateur.

P a g e | 27


Figure 10:Interface d'authentification

Figure 11:Interface d'inscription

P a g e | 28


La figure ci-dessous représente l'interface du contenu d'un cours. Nous rappelons

qu'cours peut contenir de chapitres (cours + exercices), de vidéos et/ou de

streaming.

Figure 12:Interface représentant le contenu d'un cours

P a g e | 29


Voici l'interface représentant le support de cours du premier chapitre du présent cours :

Figure 13:Interface représentant un exemple de document

Une des fonctionalités assurées par notre plateforme est la gestion du forum de

discussions. L'étudiant ou l'enseignant peut consulter la liste des sujets de

discussions (chose qui est iluustrée dans le figure14)

P a g e | 30


Figure 14: Interface représentant la liste des sujets dans le Forum

La figure 15 représente l'interface d'une discussion.

Figure 15:Interface représentant une discussion

P a g e | 31


L'administrateur à son tour, peut administrer cette plateforme à travers un tableau de

bords groupé par module ou par fonctionnalité

(ce qui est représenté dans la figure16)

Figure 16: Interface de la partie administration

P a g e | 32


A travers l'interface de gestion des utilisateurs (figure 17), l'administrateur peut gérer

ses derniers (ajout, suppression, voir profil).

L'utilisateur peut aussi ajouter un nouvel utilisateur à la plateforme.

Figure 17:Interface représentant la partie gestion des abonnés

Ce chapitre présente la dernière phase d’élaboration du projet qui est la phase de

réalisation, nous avons défini dans un premier lieu, l’environnement de travail et les

technologies utilisées, ensuite nous avons présenté quelques captures d’écran et

enfin nous avons vérifié le bon fonctionnement de notre application à travers des

tests et nous avons validé sa conformité aux besoins attendus.

Pour finir, nous allons clôturer notre rapport par une conclusion générale et des

perspectives.

P a g e | 33


Ce stage, au sein de la société SedraInfo, m'a permis de mettre en pratique les

compétences acquises au cours de ma formation à l’ENIT. J'ai pu approfondir ces

compétences et en acquérir de nouvelles.

Le stage m’a offert la possibilité d’intégrer une équipe dynamique de

professionnels qui m'ont guidés tout au long de la réalisation de cette application.

Durant ce stage, nous avons travaillé sur la conception et la réalisation d’une

plateforme E-learning. Ce projet a exigé un effort aussi bien au niveau de la conception

qu’au niveau de la réalisation pour aboutir finalement à une solution ergonomique,

flexible et répondant à notre besoin.

Dans ce stade, nous avons achevé notre projet, mais ça n’implique pas

évidemment que le travail fait soit parfait ou inchangeable, au contraire, il restera

ouvert à toute proposition d’amélioration. D’ailleurs son caractère générique et

évolutif nous offrira une infinité de possibilités d’extension. Comme première

extension, nous imaginons l’intégration d’un module permettant l’authentification

depuis un compte d’un réseau social comme Facebook, Twitter ou Linkedin. Une

éventuelle intégration d’un module de paiement (e-dinar, Paypal) paraît importante et

même primordiale.

P a g e | 34


http://www.dynamique-mag.com/article/methode-scrum-definition.4749

https://msdn.microsoft.com/en-us/library/ff649690.aspx

https://github.com/FriendsOfSymfony/FOSUserBundle

http://symfony.com/fr/doc/current/quick_tour/the_architecture.html

http://symfony.com/fr/doc/current/book/doctrine.html

http://wikipedia.com

http://openclassroom.fr

.

http://www.dynamique-mag.com/article/methode-scrum-definition.4749

https://msdn.microsoft.com/en-us/library/ff649690.aspx

https://github.com/FriendsOfSymfony/FOSUserBundle

http://symfony.com/fr/doc/current/quick_tour/the_architecture.html

http://symfony.com/fr/doc/current/book/doctrine.html

http://wikipedia.com/

http://openclassroom.fr/

rapport de stage

Software