Upload
lydat
View
218
Download
0
Embed Size (px)
Citation preview
Création d’une application web
Bohémond FLAMAND
Stage de 1ère année de cycle ingénieur
ESIEE Paris
Rapport de stage
Table des matières
Description de la société ......................................................................................... 3
Contexte et travail réalisé ...................................................................................... 4
Contexte .......................................................................................................................... 4
Cahier des charges ........................................................................................................... 6
Solution proposée (maquette du projet sous forme de story-board) : ............................. 7
Réalisation technique .................................................................................................... 18
Bilan d’expérience technique, organisationnel et humain .................... 31
Description de la société
Médias, régies, annonceurs, agences de publicité, l’univers de la communication regroupe un certain
nombre de sociétés qui nécessitent une organisation rigoureuse afin de suivre le rythme intense de la
communication dans le monde.
TBS Group est une société Française d’ingénierie spécialisée dans le développement en environnement web
de logiciels/applications destinés aux acteurs de la communication, afin de leur proposer un meilleur
système d’information et de gestion.
A ce jour l’entreprise dispose de 8 logiciels, qui peuvent servir par exemple pour une entreprise à gérer ses
devis, ses évènements, son emploi du temps, ses fiches de paie, à réserver des espaces publicitaires, ou
encore à rester le mieux informé possible grâce à des grandes bases de données.
Pour citer quelques exemples, Carrefour, Danone, Libération, ou encore Le Monde sont des clients de TBS
Group qui ont adopté ces logiciels.
Ces applications ont été conçues il y a plus de 20 ans, mais l’univers technologique et le marché de la
communication sont en perpétuelle évolution, ce qui implique la nécessité de mettre à jour les logiciels en
intégrant des solutions adaptées et innovantes. Afin de répondre aux défis imposés par cette évolution, une
équipe de 6 ingénieurs développent et ajoutent systématiquement de nouvelles fonctionnalités aux logiciels.
Ils se chargent également de la résolution des problèmes liés à ces améliorations, rencontrés par les clients
qui les utilisent.
Enfin, pour former les clients sur l’utilisation de leurs différentes applications, une équipe de consultants est
chargée d’apprendre aux nouveaux clients comment fonctionnent les logiciels et de répondre aux questions
si besoin.
Contexte et travail réalisé
Contexte
Les applications sont déployées par la société sur un ensemble de serveurs applicatifs, et les clients se
connectent sur ces serveurs pour les utiliser. En règle générale pour une application, il existe un serveur par
pays. En d’autres termes, pour utiliser une application, les clients français se connectent sur le serveur
Français, les clients espagnols sur le serveur Espagnol et ainsi de suite.
De plus, sur chaque serveur, il existe plusieurs « exemplaires » de l’application. Par exemple, il existe un
exemplaire appelé « pré production » qui permet de tester le bon fonctionnement du logiciel sur le serveur.
Ces exemplaires sont appelés des instances (ou environnements), et il en existe généralement 3 par serveur :
o Instance/environnement DEVELOPPEMENT
o Instance/environnement PREPRODUCTION
o Instance/environnement PRODUCTION
Seulement, comme je l’ai expliqué précédemment, les applications sont souvent modifiées au sein de
l’entreprise pour intégrer les correctifs ou les nouvelles fonctionnalités développées. Ces modifications
engendrent la création de nouvelles versions, qui dans un premier temps restent locales, c’est-à-dire
qu’aucun client ne peut en bénéficier. Avant que je commence mon stage, lorsque les développeurs
voulaient « déployer » ces versions sur les différents serveurs afin que les clients puissent y accéder, ils
devaient effectuer manuellement ces opérations de mise à jour. Une version d’application étant
concrètement une succession de fichiers dans un dossier, ils devaient alors copier ces fichiers puis les coller
dans les répertoires de chaque instance sur leur serveur respectif.
Pour résumer, si l’entreprise voulait mettre à jour une application de manière exhaustive, il fallait effectuer
la même manœuvre « n » fois, « n » étant la multiplication du nombre de serveurs par le nombre d’instances
respectives.
Afin de pallier cette contrainte, le directeur du service informatique m’a donné comme mission de rendre
possible la mise à jour automatique d’une application sur toutes les instances désirées en une seule
manœuvre grâce à la création d’une interface.
Plus précisément, l’objectif était de créer une plateforme grâce à laquelle l’utilisateur pouvait choisir une
version d’application à déployer, et effectuer ce déploiement sur toutes les instances non à jour en évitant
les opérations de copie-collage manuelles.
Pour avoir une vision plus claire de l’objectif, voici ci-dessous un exemple avec un des logiciels de l’entreprise
nommé « ALOHA » (application qui sert gérer un annuaire et suivre les activités commerciales d’une
entreprise).
Supposons que la dernière version développée du logiciel ALOHA soit la version 8.00 et qu’on veuille la
déployer pour en faire bénéficier tous les clients en mettant à jour les instances qui ne le sont pas.
Déploiement automatique vers toutes les instances non à jour en une
seule manœuvre :
Toutes les instances dont la version n’est pas la dernière développée sont mises à jour.
Pour accomplir cet objectif, le directeur du service informatique m’a demandé dans un premier temps la
réalisation d’un cahier des charges puis d’un story-board réunissant les différents écrans de l’interface ainsi
que le détail de son fonctionnement. La consigne que je devais respecter était de concevoir l’architecture de
l’interface, sa forme et sa logique, sans me préoccuper de l’aspect technique que je devais traiter en second
lieu.
Cahier des charges :
Se connecter au moyen d’une page d’identification
Etant donné que l’interface est à usage interne, il fallait que je pense à créer un système
d’authentification.
Savoir quel serveur et quel environnement du serveur n’est pas à jour par rapport à quelle
application
Sachant que l’objectif est de mettre à jour les instances qui ne le sont pas, j’ai pensé qu’il était
nécessaire de créer un « tableau de bord » qui permettrait d’avoir une vision globale de l’actualité
des instances.
Choisir une version
J’ai pensé qu’il était nécessaire de pouvoir choisir l’application et la version de cette dernière à
déployer en premier lieu.
Choisir les instances destinataires
En second lieu, j’ai supposé qu’il était intéressant pour l’utilisateur de pouvoir choisir toutes les
instances destinataires sur lesquels il voulait déployer la version sélectionnée auparavant.
Valider son choix et lancer la mise à jour
Pour finir, l’interface devait donner la possibilité à l’utilisateur de valider son choix et de lancer le
processus de mise à jour
Se déconnecter
L’utilisateur devait pouvoir se déconnecter
Solution proposée (maquette du projet sous forme de story-
board) :
Story-board réalisé sur PowerPoint.
Page de connexion
Objectif
• L’utilisateur peut accéder à l’interface à l’aide de son identifiant et de son mot de passe
Tableau de bord
Objectif
• L’utilisateur est renseigné sur les applications qui ne sont pas à jour
Fonctionnalités de la page
• Chaque application est représentée par un bouton portant son nom
• Une notification rouge apparaît au-dessus des applications qui ne sont pas à jour
• L’utilisateur peut ajouter une application (bouton « + » à côté des boutons des applications)
Tableau de bord
Supposons que L’utilisateur ait cliqué sur le bouton « AdResa »
Objectif
• L’utilisateur peut visualiser sur l’application sélectionnée quel instance n’est pas à jour et sur quel
serveur
Fonctionnalités de la page
• Ajouter une application
• Ajouter une version
• Ajouter un patch
• Ajouter un serveur
• Ajouter un environnement
• Cliquer sur le bouton « Mettre à jour cette application »
Tableau de bord
Supposons que l’utilisateur ait cliqué maintenant sur le bouton « Aloha » et qu’il veuille mettre à jour cette
application, il clique sur le bouton « mettre à jour cette application », et est dirigé vers la page suivante
Choix du dossier à déployer
L’utilisateur dispose de l’ensemble des versions de l’application (ici Aloha).
Objectif
L’utilisateur peut cocher la version qu’il souhaite déployer.
Fonctionnalités de la page
• L’utilisateur peut valider son choix
• L’utilisateur peut revenir au menu principal
L’utilisateur peut également parcourir une version pour choisir un patch (le patch est une transition entre
deux versions).
Si l’utilisateur appuie sur valider une fois qu’il a sélectionné une version (ou un patch d’une version), il est
mené vers la page suivante.
Choix du serveur
Objectif
• L’utilisateur peut choisir le serveur sur lequel il va déployer la version sélectionnée auparavant
(toujours avec l’exemple d’Aloha, ici sont représentés les serveurs correspondants à cette
application).
Fonctionnalités de la page
• Chaque serveur est un menu déroulant (voir page suivante)
Choix du serveur
Objectif
• L’utilisateur peut choisir l’environnement du serveur sur lequel il veut déployer la version
sélectionnée
Fonctionnalités de la page
• Une indication visuelle indique si l’environnement n’est pas à jour
• Chaque environnement peut être coché par le client
Si l’utilisateur appuie sur « finaliser l’opération », l’opération est terminée et les instances cochées sont
mises à jour par rapport à la version sélectionnée auparavant.
Une fois la maquette achevée, je l’ai présentée aux collaborateurs concernés par le projet et après
validation de leur part de cette esquisse, je suis passé à l’étape suivante : la réalisation concrète de la
maquette.
Réalisation technique
Mes collaborateurs ont jugé que le PHP était le langage le plus approprié pour créer ce type d’application.
Le PHP est un langage de programmation web qui permet de créer des sites internet dynamiques. (Facebook,
YouTube sont des exemples de sites programmés en PHP). Ce langage informatique rend possible
l’interaction entre le site et l’utilisateur et permet ainsi de le rendre « vivant », dans le sens où le site
s’actualise en fonction des informations provenant des utilisateurs et d’internet. Il peut être considéré
comme le complément du langage HTML/CSS qui lui permet simplement la création de sites statiques (pas
d’interaction possible avec internet une fois le site crée).
Pour comprendre la suite du rapport et la réalisation technique du story-board, il me faut avant tout
expliquer quelques notions structurelles du PHP que j’ai utilisé. Il existe deux versants de ce langage, celui
relatif à l’utilisateur et qu’on appelle « formulaire » et celui concernant la base de données. Il y a donc dans
un premier temps un formulaire sur le site internet qui fait interagir l’utilisateur qui saisit des informations,
et ensuite une interaction avec la base de données qui permet de stocker ces informations.
Par exemple, imaginons qu’un visiteur veuille se créer un compte sur un site quel qu’il soit, il doit rentrer des
informations comme par exemple son prénom, son adresse mail, son mot de passe etc… (Partie formulaire).
Lorsqu’il valide les données qu’il a saisies, le programme interagit avec la base de données pour stocker ces
informations (partie base de données).
Ainsi, s’il se reconnecte sur le site et qu’il veut accéder à son compte, le langage PHP permet d’aller vérifier
si dans la base de données les informations de ce visiteur existent déjà, auquel cas l’accès au compte est
autorisé.
L’objectif, je le rappelle, est de mettre sur pied une application/interface web avec pour modèle visuel et
fonctionnel le story-board. Avant de me lancer dans le développement technique, les développeurs de
l’entreprise m’ont conseillé de commencer par la conception de la base de données (une base de données
est un conteneur informatique permettant de stocker l'intégralité des informations en rapport avec une
activité). Celle-ci devait donc comprendre toutes les informations nécessaires à la réalisation de l’interface.
Par conséquent, j’ai créé une base de données dans laquelle était stockée tous les noms des logiciels de
l’entreprise, leurs différentes versions, les instances et les serveurs hébergeurs. J’ai également ajouté dans
la base de données les différents noms des futurs utilisateurs de l’application (mes collègues) ainsi que leur
mot de passe associé pour s’identifier.
J’ai pu alors commencer le développement en PHP de l’application. J’ai installé l’environnement « wamp »
qui permet de développer localement (autrement dit j’étais le seul internaute à avoir accès à l’application)
en PHP avec une base de données « mysql », et téléchargé le logiciel « sublime text », éditeur de texte qui
permet de faciliter l’écriture des lignes de code.
Première étape : la connexion vers l’interface (‘page de connexion’ dans le story-board)
Etant donné que l’application devait rester privée et uniquement destinée à l’entreprise, il fallait avant
tout sécuriser l’accès à l’interface, autrement dit demander la saisie d’un identifiant et d’un mot de passe
pour pouvoir se connecter, comme prévue dans le story-board. Ainsi, voici ce qui se passe lorsqu’un
utilisateur se connecte à l’adresse URL de l’application :
La page « motdepasse.php » est un formulaire dans lequel l’utilisateur entre son identifiant et son mot de
passe.
Lorsqu’il appuie sur valider, il est dirigé vers la page edep.php avec les informations qu’il a saisi dans le
formulaire. La page « edep.php », qui a reçu les informations, vérifie par rapport à la base de données que
le mot de passe corresponde bien à l’identifiant, auquel cas l’utilisateur est redirigé vers la page
« index.php ». Sinon, il est renvoyé vers la page du mot de passe.
Le langage PHP permet de gérer l’ouverture et la fermeture de session afin de mémoriser des informations
relatives à la personne qui utilise l’application. Lorsque la page « edep.php » valide l’identifiant et le mot de
passe et mène l’utilisateur vers « index.php », une session s’ouvre. Ainsi, comme indiqué sur
l’organigramme, lorsqu’une session est ouverte, la page « index.php » affiche le contenu de l’application,
sinon elle redirige l’utilisateur vers la page du mot de passe.
motdepasse.php
Deuxième étape : création du ‘tableau de bord’
Comme prévu dans le story-board, une fois que l’utilisateur a saisi le bon mot de passe et qu’il se trouve
donc sur la page index.php, j’ai configuré dans un premier temps l’affichage des applications. J’ai pour cela
cherché à récupérer les noms des applications stockées dans la base de données pour ensuite les afficher à
l’écran. Ensuite, le langage HTML permet de créer des boutons-lien portant un nom, et j’ai donc procédé
de telle manière à ce que chaque nom d’application soit un bouton dont l’action respective est décrite
quelques lignes plus loin.
Chacun des boutons mène vers la même page « index.php » mais avec une spécificité propre au nom du
bouton.
Dans l’exemple ci-dessus, l’utilisateur a appuyé sur « ALOHA » et ce logiciel dans la base de données est le
n°1. Ainsi, lorsque dans l’adresse URL la variable « app » est égale à 1, la page chargée affiche les
informations relatives à l’application n°1.
Mais quelles sont les informations relatives à une application ?
Pour rester fidèle au story-board, il s’agissait à ce stade de configurer l’affichage des serveurs et des instances
de l’application sélectionnée. Cependant, pour arriver jusque-là, j’ai acquis une vision plus globale des
possibilités qu’offre le PHP, et j’ai pensé qu’au lieu de respecter strictement le story-board, il était possible
de réaliser toute l’opération de mise à jour sur la même page. (alors que l’interface telle qu’elle était conçue
dans le story-board, nécessitait plusieurs pages pour effectuer l’opération). J’ai donc choisi de procéder de
la manière suivante : lorsque l’utilisateur sélectionne une application, alors les versions ainsi que les
‘index.php?app=1’
‘index.php’
instances de cette application s’affichent. L’utilisateur peut alors sélectionner la version qu’il veut déployer
et les instances destinataires, puis valider son choix, ce qui enclenche automatiquement la mise à jour.
Affichage des versions : Récupération des versions dans la base de données qui correspondent à l’application
sélectionnée.
Affichage des instances : Récupération des instances dans la base de données qui correspondent à
l’application sélectionnée.
Pour les instances et les versions, j’ai ajouté une case à cocher pour pouvoir les sélectionner.
Ce qui donne, toujours avec le même exemple (l’utilisateur a appuyé sur « ALOHA ») :
Versions d’Aloha
Instances d’Aloha sur les différents serveurs
Troisième étape : ajout, modification et suppression des éléments
Pour avoir une application la plus souple et la plus fluide possible, j’ai configuré pour chacune des
instances, des applications et des versions la possibilité de les supprimer, de les modifier ou d’en créer de
nouvelles.
Afin de rendre possible ces fonctionnalités, j’ai créé des boutons qui permettent soit de
modifier/supprimer les éléments déjà existants, soit d’en créer si besoin.
Et lorsque l’utilisateur appuie sur un bouton, par exemple sur l’icône à côté de l’environnement
« ALOHA_PREPROD_ESPAGNE », le programme est conçu de telle manière à ce que le formulaire
correspondant s’affiche.
Exemple de bouton « modifier »
Exemple de bouton « ajouter »
L’utilisateur peut à présent modifier les informations de l’instance dans le formulaire en bas à droite, ou la
supprimer.
L’utilisateur a appuyé sur ce bouton
S’il avait appuyé sur le bouton « ajout » un peu plus bas :
L’utilisateur peut à présent configurer une nouvelle instance.
Une fois que l’utilisateur a rentré les informations de l’élément qu’il veut modifier ou ajouter, ou qu’il a
appuyé sur le bouton supprimer, c’est là qu’intervient l’interaction avec la base de données. Il existe des
requêtes qui permettent en fonction du choix de l’utilisateur de modifier un élément dans la base, de le
supprimer ou d’en ajouter un.
Quatrième étape : Notifications et indications colorées
Toujours dans l’idée de rester fidèle au story-board, il s’agissait à ce stade de concevoir le système de
notifications qui permet de renseigner l’utilisateur sur les instances non à jour.
En premier lieu, je devais concevoir une indication visuelle qui permettait de savoir quelle instance n’était
pas à jour. Avec les recommandations d’un développeur et afin de conférer plus de dynamisme et de
commodité à l’application, j’ai configuré tout un système de notifications. Le code est conçu de cette
manière :
L’utilisateur a appuyé sur ce bouton
Pour chaque version :
S’il s’agit de la version de préproduction (c’est-à-dire la version la plus récente mais qui n’est pas
encore officielle car elle est encore en test), alors l’icône correspondante est de couleur orange.
S’il s’agit de la dernière version officielle, l’icône correspondante est de couleur verte..
Pour chaque instance :
Si sa version actuelle est la version de pré production (c’est-à-dire la version la plus récente mais qui
n’est pas encore officielle car elle est encore en test), alors l’icône correspondante est de couleur
orange.
Si sa version actuelle est différente de la dernière version développée ou de la version de pré
production, alors l’icône correspondante est un sablier.
Si sa version actuelle est la dernière version développée (officielle), alors l’icône correspondante est de
couleur verte.
Si sa version actuelle est trop ancienne, l’icône correspondante est une croix rouge.
Pour changer d’exemple, voici l’écran qui s’affiche lorsque l’utilisateur appuie sur ‘ABOWEB’ :
En termes de notifications, il ne reste plus qu’à configurer les icônes rouges sur les boutons des
applications :
Rappel du story-board
Pour ce faire, j’ai précisé dans le programme la chose suivante : si dans la page de l’application
sélectionnée, on dénote la présence d’une icône sablier ou d’une croix rouge, alors on affiche une petite
icone rouge sur le bouton application. Ainsi, lorsque l’utilisateur arrive sur l’application, il sait directement
quelle application n’est pas à jour. Ce qui donne concrètement :
Cinquième étape : validation
L’utilisateur pouvait à ce stade cocher les cases de son choix, mais aucun bouton n’était prévu pour traiter
les données sélectionnées. Imaginons que l’utilisateur veuille déployer la version « ABO3 » sur
l’environnement « ABOWEB_DEV_FRANCE » :
L’utilisateur nécessite à présent un bouton pour valider son choix et traiter sa demande.
Une fois que l’utilisateur a validé son choix, l’icône de l’environnement sélectionné va alors se transformer
en sablier.
Et que se passe-t-il lorsque l’application dénote la présence d’icône(s) sablier ? Un programme externe à
l’application, que j’explique dans le chapitre qui suit, finalise le cycle de la mise à jour de l’environnement.
Sixième étape : Finalisation de l’opération
Sur toutes les instances localisées sur leur serveur respectif, nous avons avec l’aide d’un autre développeur
créé un programme qui vérifie toutes les heures si une mise à jour est demandée par un utilisateur de
l’application (présence de l’icône sablier dont je parlais dans le paragraphe précédent). Dans le cas d’une
réponse positive, le système de mise à jour est lancé et l’opération du copie-collage s’effectue
automatiquement. Le programme va chercher le dossier de la version à déployer, copie les fichiers de ce
dossier et les colle dans le dossier de l’instance. Lorsque cette opération prend fin, si elle a été réalisée
avec succès, l’icône à côté de l’instance dans l’interface est remplacée et la mise à jour est finie. Dans
l’exemple précédent, l’icône devient un rond orange car la version que l’utilisateur a déployée était la
version ABO3, version de pré production.
Bilan d’expérience technique, organisationnel et
humain
Lorsque je suis arrivé dans l’entreprise, le responsable de mon stage a pris du temps pour me présenter le travail que
j’allais effectuer mais surtout pour m’avertir de l’attitude à adopter. Il voulait que je sois le plus autonome possible,
en programmant les réunions dont j’allais avoir besoin avec mes autres collègues, et en recherchant par moi-même
les informations nécessaires à l’accomplissement de l’objectif.
A mon sens, je crois que cette approche a été véritablement efficace. Etant donné que je ne connaissais ni le
fonctionnement de l’entreprise, ni la façon dont je devais m’y prendre pour créer l’interface, ni même le langage que
je devais utiliser, j’ai cherché les premiers jours à accumuler le plus d’informations possible susceptibles de m’aider.
J’ai interrogé pour cela mes différents collègues afin de tout noter sur un cahier qui m’a servi de support tout au long
du projet. Le fait de savoir que je travaillais en autonomie quasi-totale m’a incité à me mobiliser le plus rapidement et
le plus efficacement possible car je n’avais pas envie de déranger mes autres collègues trop fréquemment ni de
décevoir.
D’autre part, le responsable de mon stage m’a demandé de consacrer deux semaines à la réflexion de l’objectif de
l’interface, de sa logique et de son aspect (cahier des charges et story-board), et ensuite de me vouer à la réalisation
technique. J’ai été dérouté par cette approche car à mon sens il était plus judicieux de commencer par me former au
langage informatique que j’allais utiliser avant de me lancer dans le story-board afin de savoir ce qui était possible
d’appliquer techniquement parlant. J’ai réalisé au fur et à mesure que je me trompais quand je pensais que la
conception de la logique d’une application sans connaître les futurs outils techniques utilisés était problématique, car
pratiquement tout est concevable à partir d’un certain niveau de connaissances. De plus, bien que le résultat technique
soit légèrement différent du story-board, ce dernier m’a permis d’enchainer les étapes de la réalisation technique avec
une véritable fluidité car j’avais toujours ce support comme repère.
J’ai donc pu constater à quel point le temps pris pour la réflexion (cahier des charges, story-board) s’avère être
important et efficace pour la réalisation d’un projet, quelle que soit la connaissance des outils techniques.
Dans le domaine des outils techniques, je ne pensais pas apprendre autant de notions en 2 mois de stage. Dans un
premier temps, en réalisant un story-board sur PowerPoint, j’ai pu découvrir toutes les fonctionnalités dont ce logiciel
dispose, permettant de produire des schémas clairs et créatifs. Ensuite, toujours pour réaliser le story-board, j’ai
cherché à comprendre le fonctionnement des mises à jour et donc par cet intermédiaire j’ai cherché à comprendre le
mécanisme des serveurs, du web service, et de manière générale tout ce qui concerne le réseau.
Mais le domaine dans lequel j’ai le plus progressé et appris le plus de notions reste celui du langage informatique. A
mon arrivée, je ne connaissais pas le langage PHP, et je ne connaissais que vaguement le langage HTML/CSS. A force
de travailler sur la conception de la plateforme, de déboguer de manière autonome en recherchant les solutions sur
internet, en lisant les différents tutoriels, je pense aujourd’hui avoir atteint un niveau en PHP et en HTML/CSS qui me
permet d’accomplir des tâches complexes. En lien avec le PHP, j’ai également acquis un savoir-faire concernant la
gestion des bases de données.
En ce qui concerne la forme, je crois avoir véritablement progressé sur la manière dont je programme. Etant donné
que j’ai écrit environ trois mille lignes de code pour créer l’interface, l’indentation (manière spécifique d’écrire les
lignes de code qui permet de les rendre plus lisibles) et la rigueur d’écriture du code se sont avérées indispensables
pour ne pas me perdre. J’ai également appris, notamment grâce à un des développeurs de l’entreprise, à concevoir le
code en respectant une architecture précise qui m’a permis in fine d’optimiser le programme, en évitant la redondance
et les lignes superflues.
Il me faut préciser que je n’aurais jamais pu réaliser ce travail en 2 mois sans les deux années de préparation intégrée
en école d’ingénieur. Les cours d’informatiques que j’ai suivi et notamment les enseignements du langage JAVA
m’avaient permis avant de commencer le stage d’acquérir la logique algorithmique. Et étant donné que les langages
se ressemblent pour la majorité d’entre eux, j’ai rapidement progressé quant à l’apprentissage du langage PHP.
J’ai le sentiment de m’être véritablement enrichi tout au long de ce stage. J’ai pris beaucoup de plaisir à travailler au
sein de cette entreprise qui m’a permis d’accomplir un objectif ambitieux , avec une équipe compétente et pédagogue.
Je compte par la suite poursuivre mon apprentissage du langage PHP, avec potentiellement l’objectif de créer cette
année une application web dont je garde le concept secret pour le moment.