diff --git a/ensiie-project/.gitignore b/ensiie-project/.gitignore
new file mode 100644
index 0000000000000000000000000000000000000000..ac03cf262b420409771a4f4010dfc0ef31f91398
--- /dev/null
+++ b/ensiie-project/.gitignore
@@ -0,0 +1,4 @@
+postgres-data
+.idea/
+vendor
+composer.lock
\ No newline at end of file
diff --git a/ensiie-project/document/Presentation.md b/ensiie-project/document/Presentation.md
deleted file mode 100644
index 3b431509a5ee7fa3ca07a4a00b595343431e840a..0000000000000000000000000000000000000000
--- a/ensiie-project/document/Presentation.md
+++ /dev/null
@@ -1,140 +0,0 @@
-
-
-Projet web ENSIIE 1A 2018
-======
-
-Objectif pédagogique
-----------
-
->Apprendre à concevoir et développer des applications web utilisant un serveur de bases de données.
->Prendre conscience des problématiques d’organisation d’équipes et de répartition des tâches.
-
-Les sujets
-------------
-
-Nous proposons trois sujets qui seront détaillés ultérieurement et présentés lors de la première séance :
-
-* [Agenda des associations](sujets/agenda-des-associations.md)
-* [Accueil des nouveaux arrivants](/sujets/accueil-des-nouveaux-arrivants.md)
-* [Le twitter de l’ENSIIE](sujets/twittiie-le-twitter-de-ensiie.md)
-
-PROJET LIBRE
------
-
->Vous pouvez également proposer votre propre sujet. Celui-ci devra être défini, au plus tard, à la fin de la première séance et devra être validé.
-
-Soyez imaginatifs ! Mais veillez, tout de même, à respecter les contraintes présentées ci-dessous. N’hésitez pas à imaginer des sujets qui pourraient vous servir (ou vos associations) au quotidien. Nous serons là pour vous accompagner au cours de la réalisation de ce projet, alors profitez-en !
-
-Must have
--------
-
-### Les sujets devront tous proposer **au minimum**
-
-> * Une authentification
-> * Un compte administrateur donnant les droits à certaines fonctionnalités (au choix)
-> * Un profil utilisateur éditable
-> * Une base de données relationnelle :
-> * au moins 3 tables
-> * au moins une table de jointure ( n…n)
-> * au moins une jointure dans une requête
-> * des INSERT, DELETE, UPDATE, SELECT
-> * Un CRUD (Create Read Update Delete)
-
-Du javascript (au minimum validation JS des formulaires).
-Nous attendons de la part des élèves une véritable appropriation du sujet. Il ne suffira pas de remplir des cases à cocher pour avoir la moyenne, nous voulons voir une démarche d’ingénieur, pas d’exécutant.
-
-### Les technologies
-
-#### On oblige
-
-> * PHP 7.0
-> * PostgreSQL
-> * JavaScript
-
-#### On aimera
-
-> * Toutes les bonnes pratiques citées sur http://www.phptherightway.com/
-> * PHP 7.1+
-> * Les tests automatisés (unitaires, fonctionnels, de sécurité, de performance, …)
-> * Une API REST bien faite
-> * Les animations CSS parcimonieuses qui profitent à l’UX
-
-#### On n’aimera pas
-
-* Les frameworks (Zend Framework, Symfony, Angular, etc)
-* Le XML
-* jQuery utilisé n’importe comment
-* HTML5 utilisé n’importe comment
-
-### Séances
-
-> * **3 avril 2018** : choix du sujet, début des projets, présentation de Docker (documentation)
-> * **24 avril 2018** : point d’avancement, échange sur les bonnes pratiques, analyse du code
-> * **22 mai 2018** : soutenance, livraison des sources
-
-### La notation
-
-Une partie de la note sera attribuée par groupe, une autre réservée à l’investissement personnel.
-
-> Les points auxquels nous ferons attention lors de la notation :
-> * La méthodologie, quels vont être vos choix d’organisation ?
-> * La participation au sein de l’équipe, on attend que vous soyez moteur et que vous soyez force de proposition.
-> * La qualité technique du projet, nous voulons pouvoir comprendre votre code sans nous arracher les cheveux. Préférez peu de code bien fait avec des fonctionnalités complètes à une grosse quantité de code illisible, avec beaucoup de fonctionnalités copiées collées et/ou à moitié terminées.
-> * La soutenance du projet, nous souhaitons voir une soutenance dynamique. Pas de présentation point par point afin de vérifier que oui il y a bien une inscription et ou un CRUD. On veut voir que ça marche, on veut être convaincu et on veut se l’arracher votre projet. Encore moins une lecture de votre rapport.
-> * Le rapport du projet a un but complètement différent de la soutenance. La soutenance nous permet de voir le produit tel que vous avez imaginé son utilisation, le rapport nous permet de comprendre la partie interne du fonctionnement de votre groupe. Il est très important pour nous de bien comprendre quels ont été les enjeux de chaque groupe, quelles ont été les difficultés rencontrées et surtout quelles ont été les solutions trouvées pour les contourner.
-
-### L’environnement de développement
-
-Afin de s’affranchir de problème d’infrastructure, nous vous mettons à disposition un environnement de développement pour ce projet.
->Lors du premier cours nous vous présenterons l'utilisation du git que nous avons mis à votre disposition ainsi que le fonctionnement d'un Docker entièrement configuré et prêt à être utilisé pour développer votre projet.
-
-### Le rendu des sources et du rapport
-
->Les projets devront être pushé sur ce [repository git](https://github.com/Un3x/ensiie-project) sur une branche ```<nom-de-votre-groupe>-group```.
-
-**ATTENTION**: ce repo git n'as pas pour but d'être utilisé pendant le développement. Il s'agit de notre outil pour récupérer vos projets et pouvoir les utiliser. L'utilisation d'un git au cours du développement n'est pas obligatoire, mais nous vous encourageons à en utiliser un (github, arise, ensiie, bitbucket, gitlab etc)/
-
-> Le rapport doit être inclus dans les sources du projet, à la racine: ```/rapport.pdf```
-
-Toutefois, il serait dommage de rester bloquer sur le rendu donc préparez-vous avant et contactez nous le plus tôt possible en cas de problème.
-
-#### Le rapport
-
-> * Faire 10 pages maximum pour refléter le monde de l’entreprise où la concision est une qualité
-> * Expliquer l’approche mise en place, les problématiques rencontrées (techniques comme méthodes) et les solutions apportées
-> * Expliquer la répartition des rôles au sein de l’équipe
-> * La problématique à laquelle il répond.
-
-#### La soutenance
-
-Nous souhaitons simuler une séance plénière devant des investisseurs. Nous voulons que vous vous mettiez dans la peau d’une jeune startup devant vendre sa toute nouvelle application à un public d’investisseurs intéressés.
-Ce format de soutenance sera aussi une bonne occasion de se faire une première expérience de communication autour d’un projet.
-
-> * Présentation plénière (tous les groupes devant tout le monde)
-> * 8 minutes par groupe, pas une minute de plus
-> * Pure démo de l’application, pas de questions
-
-L’objectif est de vendre l’application aux personnes dans la salle, mode start-up **ACTIVÉ**
-La note de soutenance ne sera pas donnée le jour même
-
-> **Tout le monde doit être présent lors des soutenances.**
-
-Aussi, n’oubliez pas qu’on est là pour passer un bon moment, pas de lynchage, uniquement des critiques constructives. Nous comprenons également que le facteur stress peut jouer en votre défaveur en fonction de votre personnalité, aussi ne vous inquiétez pas car nous sommes conscients de cela et nous sommes là pour noter l’adéquation de chacun avec les attentes d’un ingénieur:
-
-> * Méthode
-> * Apprentissage
-> * Qualité du travail rendu
-> * Expression
-> * Adaptabilité
-
-### Notre équipe
-
-* Thomas COMES : ENSIIE promo 2012, Project Lead chez Matters.
-* Nassim Kirouane : Tech Lead chez Matters.
-* Remi Parpaillon : Php Gourou chez Matters.
-
-### Comment nous contacter
-
-Nous mettons un slack à votre disposition pour échanger avec nous. L'url vous sera communiqué lors du premier cours.
-
-Vous êtes également les bienvenus tous les jeudis après-midi dans nos locaux au 10 rue du Faubourg Poissonnière 75010 PARIS. Ce sera l’occasion de faire un peu plus connaissance, et d’assister à nos SteamLearn, les formations hebdo !
diff --git a/ensiie-project/document/sujets/accueil-des-nouveaux-arrivants.md b/ensiie-project/document/sujets/accueil-des-nouveaux-arrivants.md
deleted file mode 100644
index 0c4886359e941c189def5b044656f2f56fde5e8b..0000000000000000000000000000000000000000
--- a/ensiie-project/document/sujets/accueil-des-nouveaux-arrivants.md
+++ /dev/null
@@ -1,67 +0,0 @@
-
-
-Accueil des petits nouveaux
-======
-
-Contexte du projet
------
-
-Les premiers jours à Evry, c’est pas toujours facile. On arrive dans une toute nouvelle ville, on ne connait personne, et la seule chose que l’on a à faire c’est d’aller à l’école.
-
-La vie serait tellement plus simple si les élèves s’entraidaient un peu plus pour échanger sur tout ce qu’il y a à savoir. Connaître les endroits importants dans la ville, connaître la répartition des salles de l’école, qui contacter lorsqu’on a tel ou tel problème, où retrouver le planning de l’école, comment fonctionne le bar, etc.
-
-### Pré-requis
-Comme pour tous les sujets, on devra au moins retrouver dans l’application finale les parties suivantes :
-
-> * Une authentification
-> * Un compte administrateur donnant les droits à certaines > * fonctionnalités (au choix)
-> * Un profil utilisateur éditable
-> * Une base de données relationnelle :
-> * au moins 3 tables
-> * au moins une table de jointure ( n…n)
-> * au moins une jointure dans une requête
-> * des INSERT, DELETE, UPDATE, SELECT
-> * Un CRUD (Create Read Update Delete)
-> * Du javascript (au minimum validation JS des formulaires)
-
-Nous attendons de la part des élèves une véritable appropriation du sujet. Il ne suffira pas de remplir des cases à cocher pour avoir la moyenne, nous voulons voir une démarche d’ingénieur, pas d’exécutant.
-
-### Objectifs
-
-Proposer une application qui va permettre d’assigner des élèves comme tuteurs d’autres nouveaux élèves et suivre leur découverte de la ville d’Evry et du fonctionnement de l’école.
-
-L’application devra donc gérer, un ensemble d’élèves, d’achievement, de types d’élèves, de types d’achievement.
-Les élèves pourront être des nouveaux arrivants, des administrateurs ou des tuteurs.
-Pour qu’un élève soit tuteur, il faut qu’il ait déjà été onboardé par d’autres tuteurs.
-
-Les administrateurs pourront désigner des élèves comme étant des tuteurs (pour l’initialisation principalement).
-Lorsqu’un nouvel arrivant s’inscrit, une liste d’achievement lui est automatiquement assignée ainsi que plusieurs tuteurs.
-
-Les nouveaux arrivants pourront attribuer un status à unachievement.
-Une fois que la liste d’achievement est complètement finie, le nouvel arrivant se voit promu au rang de tuteur et pourra être assigné à l’accueil d’un autre élève.
-Comme les nouveaux arrivants arrivent en masse, il faudra prévoir un système permettant d’importer une liste d’élèves (leur assigner un mot de passe, les achievement, les tuteurs).
-
-Certains achievement devront nécessiter des compétences spécifiques afin de pouvoir être faites (la présentation arise par exemple). Les tuteurs auront donc des compétences qui leur permettront de faire réaliser certains achievement avec les nouveaux arrivants. La validation d’un achievement nécessitant des compétences particulières n’est possible que si au moins 1 un des tuteurs possède cette compétence.
-
-### Les difficultés du projet
-
-Une gestion propre des status des élèves et des achievement nous permettra de voir clair dans les intentions que vous allez donner à ce projet. Faites bien attention à la syntaxe des status et soyez stratégique dans votre implémentation afin d’avoir un code propre. On se mêle rapidement les pinceaux.
-
-La gestion de déclenchement automatique peut s’avérer un problème. Il faudra bien vous mettre d’accord sur ce qui se passe et à quel moment.
-Si l’algorithme d’attribution automatique d’achievement n’est pas extrêmement complexe, l’attribution automatique des tuteurs tout en gérant les compétences requises pour la réalisation des achievement pourra s’avérer être un exercice plus difficile. Attention ici à bien faire les choses dans l’ordre (et proprement :)).
-
-### Propositions de features
-
-Comme pour tous les projets, vous pouvez choisir de l’adapter / de l’étoffer tant que tous les pré-requis sont remplis.
-
-Voici en exemple une petite liste de fonctionnalités qui pourraient être implémentées dans le cadre du projet :
-
-> * La gestion des compétences des étudiants par les administrateurs / autres tuteurs.
-> * La possibilité d’avoir différentes listes d’achievements initiaux en fonction de l’élève. Peut-être y aura-t-il différente chose à faire pour accueillir un élève en milieu d’année qu’en début d’année. Ou il y aura d’autres choses à montrer aux arrivants étrangers, aux FIPAS etc.
-> * La gestion des promotions. Les étudiants appartiennent à une promotion. Gérer les changements de promo.
-> * Le suivi de l’avancée de l’accueil d’une promo. Une page permettant de savoir quels élèves ont quels tuteurs et où ils en sont de l’avancée de leur onboarding.
-> * Ce sont ici bien évidemment des propositions de fonctionnalités supplémentaires, il y en a beaucoup d’autres qui pourraient être pertinentes dans le cadre du projet. Ces fonctionnalités dépendront des objectifs que vous souhaiterez donner à votre projet.
-
-Ce sont ici bien évidemment des propositions de fonctionnalités supplémentaires, il y en a beaucoup d’autres qui pourraient être pertinentes dans le cadre du projet. Ces fonctionnalités dépendront des objectifs que vous souhaiterez donner à votre projet.
-
-**Bon courage.**
\ No newline at end of file
diff --git a/ensiie-project/document/sujets/agenda-des-associations.md b/ensiie-project/document/sujets/agenda-des-associations.md
deleted file mode 100644
index 8cfd62a001cbc2511c4a56d810c50196c9142263..0000000000000000000000000000000000000000
--- a/ensiie-project/document/sujets/agenda-des-associations.md
+++ /dev/null
@@ -1,71 +0,0 @@
-
-
-Agenda des associations
-=====
-
-Contexte du projet
------
-
-Les associations à l’écoles, ça nous connait. Le BdE, le bar, LudIIe, l’AS, ForumIIe, GalaxIIe etc. Et forcément, quand on est dans une association, on a besoin d’échanger de s’organiser et de se réunir.
-
-Etant donné que beaucoup d’élèves sont de petits cumulars et il est parfois difficile d’organiser des réunions où tout le monde pourra être présent (et encore, sans compter la multitude de raisons personnelles qu’il peut y avoir).
-Heureusement, l’agenda des associations sera bientôt là pour vous faciliter la vie. Grâce à cet agenda dédié aux associations vous pourrez savoir et gérer qui sera présent lors des réunions.
-
-### Pré-requis
-Comme pour tous les sujets, on devra au moins retrouver dans l’application finale les parties suivantes :
-
-> * Une authentification
-> * Un compte administrateur donnant les droits à certaines fonctionnalités (au choix)
-> * Un profil utilisateur éditable
-> * Une base de données relationnelle :
-> * au moins 3 tables
-> * au moins une table de jointure ( n…n)
-> * au moins une jointure dans une requête
-> * des INSERT, DELETE, UPDATE, SELECT
-> * Un CRUD (Create Read Update Delete)
-> * Du javascript (au minimum validation JS des formulaires)
-
-Nous attendons de la part des élèves une véritable appropriation du sujet. Il ne suffira pas de remplir des cases à cocher pour avoir la moyenne, nous voulons voir une démarche d’ingénieur, pas d’exécutant.
-
-### Objectifs
-
-Proposer une application qui va permettre d’organiser les réunions / événements associatifs.
-
-Dans ce projet il va falloir gérer, les élèves, les associations, les réunions et la participation des élèves à ces réunions.
-Les associations auront des adhérents qui pourront être soit des membres soit des administrateurs. Nous vous laissons le soin de mettre en place le modèle relationnel de données.
-
-Chaque élève pourra appartenir à une ou plusieurs associations, avec des rôles différents.
-
-Chaque élève aura un agenda personnalisé de ses réunions / événements à venir.
-
-> * Seuls les administrateurs des associations pourront créer des réunions
-> * Les élèves pourront dire s’ils participent à une réunion.
-> * Les status possibles des réunions seront Oui, Non, En attente de réponse.
-> * Les élèves seront notifiés des nouvelles réunions auxquelles ils doivent répondre.
-
-Si un élève a déjà une réunion à ce moment là, il en sera notifié (et ne pourra pas répondre présent aux deux réunions).
-
-### Les difficultés du projet
-
-La gestion des dates pourra aussi s’avérer être un challenge technique. Faites bien attention aux formats de dates que vous allez utiliser. Nous vous renvoyons vers PhpTheRightWay pour un premier aperçu de la gestion des dates en PHP.
-
-Il faudra aussi penser un affichage propre de l’agenda.
-Enfin, la gestion des statuts pourra s’avérer être un problème. Cela implique une gestion de droit au niveau de la participation aux réunions (qui peut être invité ?), mais aussi au niveau des administrateurs des associations qui seront les seuls à pouvoir créer des réunions ou événements.
-
-### Propositions de features
-
-Comme pour tous les projets, vous pouvez choisir de l’adapter / de l’étoffer tant que tous les pré-requis sont remplis. Vous pouvez choisir de faire un agenda sportif pour l’AS, un agenda des soirées etc.
-
-Voici en exemple une petite liste de fonctionnalités qui pourraient être implémentées dans le cadre du projet :
-
-> * Les administrateurs pourront voir l’agenda des réunions de toutes les associations.
-> * Lorsqu’un administrateur crée une réunion, l’agenda lui propose les créneaux où > tous les membres de l’association sont disponibles.
-> * Un système de notifications pour que les administrateurs soient au courant des > réponses de participation.
-> * Un envoi de mail automatique avant une réunion pour un rappel.
-> * Un mode réunion privée / réunion publique. En réunion privée, seuls les membres > pourront voir la réunion dans l’agenda, tandis que lors d’une réunion publique, tous > les élèves seront invités à participer (mais seuls les membres pourront répondre > présent ou non).
-> * Un mode d’annulation automatique des réunions 24h avant si moins de X personnes > répondent présent.
-> * Une synchronisation avec d’autres calendrier en ligne.
-
-Ce sont ici bien évidemment des propositions de fonctionnalités supplémentaires, il y en a beaucoup d’autres qui pourraient être pertinentes dans le cadre du projet. Ces fonctionnalités dépendront des objectifs que vous souhaiterez donner à votre projet.
-
-**Bon courage.**
\ No newline at end of file
diff --git a/ensiie-project/document/sujets/twittiie-le-twitter-de-ensiie.md b/ensiie-project/document/sujets/twittiie-le-twitter-de-ensiie.md
deleted file mode 100644
index 80712bda39cd10195c81b0c06311b74508a6c198..0000000000000000000000000000000000000000
--- a/ensiie-project/document/sujets/twittiie-le-twitter-de-ensiie.md
+++ /dev/null
@@ -1,67 +0,0 @@
-
-
-Twitiie le twitter de l'ENSIIE
-=====
-
-Contexte du projet
--------
-
-Twitter ne pourra pas toujours conserver son statut de leader du marché en termes de communication sociale. Il est temps de mettre fin à ce monopole.
-Je vous présente TwittIIe, l’application qui copie tout de twitter et qui va leur voler tout le marché.
-
-### Pré-requis
-
-Comme pour tous les sujets, on devra au moins retrouver dans l’application finale les parties suivantes :
-
-> * Une authentification
-> * Un compte administrateur donnant les droits à certaines fonctionnalités (au choix)
-> * Un profil utilisateur éditable
-> * Une base de données relationnelle :
-> * au moins 3 tables
-> * au moins une table de jointure ( n…n)
-> * au moins une jointure dans une requête
-> * des INSERT, DELETE, UPDATE, SELECT
-> * Un CRUD (Create Read Update Delete)
-> * Du javascript (au minimum validation JS des formulaires)
-
-Nous attendons de la part des élèves une véritable appropriation du sujet. Il ne suffira pas de remplir des cases à cocher pour avoir la moyenne, nous voulons voir une démarche d’ingénieur, pas d’exécutant.
-
-### Objectifs
-
-Proposer une application qui va permettre aux utilisateurs de communiquer via des messages augmentés.
-
-Dans ce projet il va falloir gérer, les élèves, les publications, les hashtags etc
-Les utilisateurs auront un feed d’activité et un feed de leur propre activité (mur perso etc).
-
-> * Les utilisateurs inscrits ont le droit de diffuser du contenu (limité en caractères, et avec un langage augmenté, émoticon, @, # ou autre)
-> * Les utilisateurs inscrits peuvent s’abonner aux contenu d’autres utilisateurs. Ce contenu apparaîtra alors dans leur feed d’activité.
-> * Les hashtag et les noms d’utilisateurs devront être cliquables afin de voir leur flux d’activité respectifs.
-> * Les administrateurs peuvent supprimer les publications. Les utilisateurs doivent faire une demande de suppression qui s’affichera dans une notification pour les administrateurs (tant qu’elle n’a pas été supprimée).
-> * Les utilisateurs peuvent ‘liker’ un message. Un contenu automatique pourrait alors être diffusé (tel utilisateur a ‘liké’ ce message, à diffuser sur le mur perso par exemple, ou sur une page dédiée).
-> * Les utilisateurs peuvent répondre à un message (et répondre à la réponse etc).
-
-Ce sont ici les features minimales que nous avons sélectionnées pour que le projet soit fonctionnel. Il conviendra de les adapter en fonction de la direction que vous souhaitez donner à votre projet.
-
-### Les difficultés du projet
-
-La première difficulté relative à ce sujet concernera évidement le parsing des messages afin de pouvoir rajouter des liens rapides vers les utilisateurs ou hastag. Attention à l’architecture de vos outils pour que le code soit propre.
-Enfin, dans ce genre de projet à but social il y a beaucoup d’écrans qui présentent la même donnée mais agencée de différentes façons. Avoir un bon modèle relationnel vous aidera à manipuler la données facilement. Essayez de prévoir !
-
-### Propositions de features
-
-Comme pour tous les projets, vous pouvez choisir de l’adapter / de l’étoffer tant que tous les pré-requis sont remplis. Vous pouvez choisir de faire un agenda sportif pour l’AS, un agenda des soirées etc.
-
-Voici en exemple une petite liste de fonctionnalités qui pourraient être implémentées dans le cadre du projet :
-
-> * Du contenu automatique pourrait être proposé aux nouveaux utilisateurs en fonction de leur goût (ou n’importe quel autre critère).
-> * La possibilité de partager le message de quelqu’un d’autre
-> * La possibilité d’envoyer un message privée à quelqu’un. En réponse d’un autre message par exemple.
-> * La possibilité de poster un message dans le futur. Ceci implique donc une bonne gestion des dates ainsi qu’une automatisation de l’envoi d’un post et d’une gestion de statut des messages.
-> * La possibilité d’afficher du contenu d’un autre format, comme des gifs ou des vidéos.
-> * Des accès rapides aux trendings topics (les hashtags sur lesquels il y a le plus d’activités).
-> * Une suggestion automatique des utilisateurs lorsqu’on écrit un @ et/ou des hashtag lorsqu’on a un # qui s’adapte à ce que l’utilisateur écrit.
-> * Ce sont ici bien évidemment des propositions de fonctionnalités supplémentaires, il y en a beaucoup d’autres qui pourraient être pertinentes dans le cadre du projet. Ces fonctionnalités dépendront des objectifs que vous souhaiterez donner à votre projet.
-
-Ce sont ici bien évidemment des propositions de fonctionnalités supplémentaires, il y en a beaucoup d’autres qui pourraient être pertinentes dans le cadre du projet. Ces fonctionnalités dépendront des objectifs que vous souhaiterez donner à votre projet.
-
-**Bon courage.**
\ No newline at end of file
diff --git a/ensiie-project/public/index.php b/ensiie-project/src/Controller/index.php
similarity index 100%
rename from ensiie-project/public/index.php
rename to ensiie-project/src/Controller/index.php
diff --git a/ensiie-project/src/Model/arise_data.php b/ensiie-project/src/Model/arise_data.php
new file mode 100644
index 0000000000000000000000000000000000000000..ed941ad6f9123b9f6a34ccec883dbdc06654852c
--- /dev/null
+++ b/ensiie-project/src/Model/arise_data.php
@@ -0,0 +1,38 @@
+<?php
+/**
+ * Created by PhpStorm.
+ * User: JALIK
+ * Date: 09/04/2019
+ * Time: 08:37
+ */
+require_once('db_data.php');
+
+/**
+ * @brief A partir d'un utilisateur connecté sur à travers Arise, récupère les informations essentielles
+ * @param $ariseUser
+ * Un utilisateur connecté par Arise
+ * @return
+ * Une variable qui ne contient que les informations qui nous intéressent
+ */
+function getUser($ariseUser){
+ $user['prenom'] = $ariseUser['...'];
+ $user['nom'] = $ariseUser['...'];
+ $user['pseudo'] = $ariseUser['...'];
+ $user['id'] = $ariseUser['...'];
+ $user['commandes'] = getCurrentCommands($user['id']);
+ return $user;
+}
+
+/**
+ * @brief Récupère les informations essentielles pour les invités :
+ * ATTENTION Utiliser cette fonction uniquement pour les invités connectés (qui ont entré le bon mot de passe)
+ * @return
+ * Une variable contenant les informations nécessaires pour qu'un invité puisse se connecter
+ */
+function getInvite(){
+ //TODO : Mettres ces infos dans des variables de config
+ $user['pseudo'] = "Invité.e";
+ $user['id'] = "invite";
+ $user['commandes'] = getCurrentCommands($user['id']);
+ return $user;
+}
\ No newline at end of file
diff --git a/ensiie-project/src/Model/db_connect.php b/ensiie-project/src/Model/db_connect.php
new file mode 100644
index 0000000000000000000000000000000000000000..3cf3a1d1140f2990f9b7dcd963df0fc2dde53429
--- /dev/null
+++ b/ensiie-project/src/Model/db_connect.php
@@ -0,0 +1,9 @@
+<?php
+/**
+ * Created by PhpStorm.
+ * User: JALIK
+ * Date: 09/04/2019
+ * Time: 08:35
+ */
+
+?>
\ No newline at end of file
diff --git a/ensiie-project/src/Model/db_data.php b/ensiie-project/src/Model/db_data.php
new file mode 100644
index 0000000000000000000000000000000000000000..a276caac298017063136124f3fcefc38a353cf77
--- /dev/null
+++ b/ensiie-project/src/Model/db_data.php
@@ -0,0 +1,52 @@
+<?php
+/**
+ * Created by PhpStorm.
+ * User: JALIK
+ * Date: 09/04/2019
+ * Time: 08:37
+ */
+require_once('db_connect.php');
+
+/**@brief récupère le nom de l'event courant
+ *
+ * @return mixed
+ */
+function getCurrentEvent(){
+ //Appel SQL
+ $event['id_event'] = ...;
+ $event['nom_event'] = ...;
+ $event['date_premiere_fin'] = ...;
+ $event['date_deuxieme_fin'] = ...;
+ return $event;
+}
+
+function getDefaultFins{
+ //Appel SQL
+ $heures['first_end'] = ...;
+ $heures['second_end'] = ...;
+ return $heures;
+}
+
+function getCurrentCommands($id){
+ //Get numero de l'event courrant
+ //SI pas d'event courant : throw exception
+ //Sinon, appel SQL, get commande with USERID=$id AND EVENTID=$eventID
+}
+
+/**
+ * @brief Ajoute une commande à la BDD
+ * @param $user
+ * La variable utilisateur contenant toutes les informations importantes
+ * @param $event
+ * La variable contenant les informations de l'évennement pour lequel l'utilisateur commande
+ * @param $command
+ * La variable contenant les informations de la commande
+ * @param $name
+ */
+function addCommand($user, $event, $command, $name){
+ $current_event = getCurrentEvent();
+ assert($event['id_event'] == $current_event['id_event']);
+
+}
+
+?>
\ No newline at end of file
diff --git a/ensiie-project/src/View/commande.php b/ensiie-project/src/View/commande.php
new file mode 100644
index 0000000000000000000000000000000000000000..80fd13ce0101b4600addda1df7f0ac8c0f0b13c8
--- /dev/null
+++ b/ensiie-project/src/View/commande.php
@@ -0,0 +1,10 @@
+<?php
+
+foreach( $commande in $user['commandes']){
+?>
+ <div class="truc">
+ <p>Vous avez commandé : <?php $commande['titre']?></p>
+ </div>
+ <?php
+}
+?>