32
Création d’une application web Bohémond FLAMAND Stage de 1 ère année de cycle ingénieur ESIEE Paris Rapport de stage

Rapport de stage - bohemond-flamand.combohemond-flamand.com/documents utiles/rapport tbs.pdf · ... son emploi du temps, ... le directeur du service informatique m’a demandé dans

  • 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.

Annexes :

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.