DOSSIER DE VALIDATION

Directeur de Projet Informatique

Nom Prénom MELKI Achraf

Nom(s) Prénom(s) du ou des tuteurs VILLARDIER Lucas
Acronyme de la certification IPI visée DPI
Niveau visé 7
Date de la soutenance 28 Septembre 2023
Lieu de la soutenance 7 rue Jean Marie Leclair 69009 Lyon

1
 Remerciement

Dans le cadre de ma formation et du programme Digitalents de l'IPI, j'ai eu le privilège de

rejoindre l'entreprise Sopra Steria en tant qu'alternant à partir d'octobre 2020. Aujourd'hui,
je tiens à exprimer ma profonde gratitude envers toutes les personnes qui ont contribué à
faire de ces trois années une expérience enrichissante, même dans un contexte parfois
difficile :

Tout d'abord, je souhaite remercier chaleureusement l'équipe du SDMIS, avec qui je travaille
actuellement. Merci à VAN ZUIJLEN Nicolas, BEDOK Robin, PITTORE Axel, VILLARDIER Lucas
et TOUS Florent pour leur collaboration précieuse et leur soutien constant.

Je tiens également à exprimer ma reconnaissance envers l'équipe de la Ville de Lyon, avec

laquelle j'ai eu l'opportunité de collaborer par le passé. Mes remerciements vont à
VERSAVAUD COLLET Isabelle, WARTIN Maxence, LE MIGNANT Hugo, TERKI HASSAINE Elyes et
HGUIG Jihad pour leur accueil et leur engagement.

Enfin, un grand merci à l'ensemble des intervenants qui ont partagé leur expertise au cours
de ma formation, ainsi qu'à mes camarades de promotion pour leur camaraderie et leur
partage de connaissances.

Ces trois années ont été une étape cruciale de ma formation et de mon développement
professionnel, et cela n'aurait pas été possible sans le soutien et la collaboration de chacun
d'entre vous. Je suis reconnaissant d'avoir eu l'opportunité de travailler à vos côtés et
d'apprendre de vous.

2
3
 Sommaire
Remerciement................................................................................................................................. 2
Sommaire........................................................................................................................................ 4
I. Glossaire....................................................................................................................................... 6
II. Sopra Steria Group....................................................................................................................... 9
1. Histoire de l’entreprise.................................................................................................................. 9
2. Secteur d’activité, services et clientèles...................................................................................... 11
a. Sopra Steria : une entreprise présente au niveau national et international......................... 11
b. LIMONEST : L’un des 4 sites régionaux................................................................................. 13
III. Ville de Lyon..............................................................................................................................15
1. Le client....................................................................................................................................... 15
2. Le projet Manif............................................................................................................................ 16
a. Besoin fonctionnel................................................................................................................ 17
b. Cahier des charges................................................................................................................ 19
c. Besoin technique...................................................................................................................24
d. Cycle de vie du projet........................................................................................................... 25
3. Actions sur le projet.................................................................................................................... 25
IV. SDMIS....................................................................................................................................... 27
1. Présentation du Contexte............................................................................................................27
2. Tâches Récurrentes au Sein de la TMA........................................................................................28
a. MCO - Gestion des Tickets Incidents/Demandes d'Évolution............................................... 28
b. Réunions COAPP (Comité Opérationnel d'Application)........................................................ 28
c. Réunions de Livraison............................................................................................................31
3. Évolution du Webservice SMS..................................................................................................... 33
a. Contexte................................................................................................................................33
b. Analyse et Chiffrage.............................................................................................................. 33
c. Gestion de Projet et Documentation.................................................................................... 34
4. Migration des Interfaces Talend.................................................................................................. 35
a. Contexte et Introduction à Talend........................................................................................ 35
b. Planification et Préparation.................................................................................................. 36
c. Gestion de Projet et Suivi...................................................................................................... 36
d. Migrations par Lots............................................................................................................... 37
e. Déroulement de la Migration................................................................................................37
f. Livraison des Interfaces Migrées............................................................................................38
g. Conclusion.............................................................................................................................38
5. Sentinelle de la documentation.................................................................................................. 39
V. Projet Personnel.........................................................................................................................40
1. Quizz Football..............................................................................................................................40
a. Idée de départ.......................................................................................................................40

4
 b. Equipe Projet........................................................................................................................ 40
c. Présentation technique......................................................................................................... 41
d. Initialisation du projet...........................................................................................................42
e. Mise en place du backlog......................................................................................................42
f. Planning previsionnel.............................................................................................................44
g. Imprévues et contretemps....................................................................................................45
h. Retour d'expériences............................................................................................................ 46
2. Boutique en ligne........................................................................................................................ 47
a. Contexte................................................................................................................................47
b. Définition des User Stories................................................................................................... 47
c. Estimation des Story Points et Planification Poker................................................................48
d. Estimation en Heures et Répartition des Tâches.................................................................. 49
e. Écriture des Tests Unitaires (TU)........................................................................................... 50
f. Développement en Mode TDD.............................................................................................. 51
g. Retour d’expériences............................................................................................................ 52
VI. Conclusion et Bilan....................................................................................................................53
VII. Annexes................................................................................................................................... 54
VDL :................................................................................................................................................ 54
Manifestation (étape de création d’une manifestation) :......................................................... 54
SDMIS :............................................................................................................................................ 60
Répartition des applications :................................................................................................... 60
Sentinelle de la Documentation processus macroscopique :................................................... 60
Quizz Football :................................................................................................................................61
FindEleven (choix du mode de jeu) :.........................................................................................61
Règle du Jeu :............................................................................................................................ 61
FindEleven (jeu) :...................................................................................................................... 62
Geoplayer (carte) :.................................................................................................................... 62
GeoPlayer (règles du jeu) :........................................................................................................63
GeoPlayer (réponse) :............................................................................................................... 63

5
 I. Glossaire

Acronyme Signification

SDMIS Service Départemental-Métropolitain d'Incendie et de Secours

BA Business Analyst (Analyste Métier)

CP Chef de Projet

COAPP Comité Opérationnel d'Application

SFD Spécification Fonctionnelle Détaillée

STD Spécification Technique Détaillée

INT Environnement de qualification (Intégration)

PROD Environnement de production

ETL Extract, Transform, Load (intégration de données)

TU Tests Unitaires

6
 Application Programming Interface (interface de programmation
API
d'application)

CSS Cascading Style Sheets (feuilles de style en cascade)

Node.js Plateforme de développement JavaScript côté serveur

TDD Test-Driven Development (développement piloté par les tests)

US User Stories (Histoires d'Utilisateur)

SN Entreprise de Services du Numérique

SSII Société de Services en Ingénierie Informatique

CA Chiffre d'Affaires

CNAM Caisse Nationale d'Assurance Maladie

CMS Système de Gestion de Contenu

RGPD Règlement Général sur la Protection des Données

Une plateforme logicielle qui permet d'automatiser le déploiement, la

Docker
gestion et la mise à l'échelle d'applications dans des conteneurs.

7
OTEP Organisation temporaire de l’espace publique

Poker Technique de planification agile qui permet à une équipe de déterminer

Planning l'estimation de la complexité d'une tâche en utilisant des cartes

8
II. Sopra Steria Group

1. Histoire de l’entreprise

L’ESN Sopra Steria Group est née en 2014 de la fusion entre deux SSII, Sopra
et Steria, deux entreprises fondées à la fin des années 60 spécialisées dans le
conseil et la réalisation de projets numériques pour les grandes entreprises
et organisations. Fortes d’une clientèle variée, les deux entreprises ont su se
spécialiser, l’une dans le conseil pour les banques principalement, et l’autre
travaillant de façon récurrente avec l’Etat (armée-ministère etc…). Les
compétences de ces deux SSII, une fois fusionnées, ont permis à Sopra Steria
d’être une entreprise complète dans ses services et ses compétences.

Figure 1 : Histoire de l’entreprise (source : Document-d-enregistrement-universel)

L’ESN Sopra Steria compte à l’heure actuelle pas moins de 45000

collaborateurs dans 25 pays, majoritairement européens. L’entreprise

9
s’impose comme leader de la transformation numérique européenne, et
travaille en collaboration avec ses filiales pour fournir aux grandes
entreprises une solution de mise à niveau du numérique dans leurs
institutions, ainsi qu’une veille technologique de qualité.

Malgré l’année 2020 sur fond de covid ainsi qu’une crise majeure en octobre
2020 liée à une cyberattaque, le bilan 2020 de l’entreprise reste qualitatif et
les espoirs de reprise en 2021 sont nombreux :

Figure 2 : Résultat net et dividende actionnaire.

Figure 3 : CA 2022 et 2021

10
2. Secteur d’activité, services et clientèles

a. Sopra Steria : une entreprise présente au niveau national et international

Ayant fait le choix de ne proposer ses services qu’aux entreprises dites «

Grands comptes », Sopra Steria travaille avec des entités de divers secteurs. Il
est tout de même intéressant de voir dans quelles activités ces entreprises
sont implantées grâce à ce graphique représentant le chiffre d’affaires par
vertical :

Figure 4 : Chiffres d’affaires par typologie de client en 2020.

L’entreprise met en place pour ses clients une approche par verticaux : les
services sont regroupés par secteur d’activité des clients comme le montre le
graphique figure 1. Un point d’honneur est également mis sur la proximité
entre les équipes Sopra Steria et celles du client. Ainsi, les agences Sopra

11
Steria de chaque région entretiennent des relations étroites avec les équipes
de leurs clients. L’entreprise cherche également à devenir l’acteur principal
des projets numériques, en proposant une approche « End to end », et en
visant à offrir des services les plus complets possibles, de l’ébauche d’un
projet à sa mise en production puis à la veille technologique effectuée en
amont.

On constate que les verticaux « banque » et « secteur public » représentent à

eux seuls 45% du CA de l’entreprise. Depuis leur création, Sopra et Steria
étaient spécialisées dans le secteur de la banque, la fusion n’a pas changé les
objectifs de clientèle de l’entreprise.

Historiquement, l’entreprise dispose de connaissances sur le territoire

national dans les technologies bancaires mainframe et le langage cobol. Le
domaine bancaire tourne uniquement grâce au mainframe. En apportant ses
connaissances sur de nouvelles technologies comme java et l’environnement
Oracle, Sopra Steria joue le rôle de conseiller avisé sur les anciennes
technologies, et d’entrepreneur de changement en embarquant de plus en
plus de projets java.

Le groupe travaille avec des clients ayant choisi Sopra Steria depuis plusieurs
années. On retrouvera des entreprises très connues au niveau européen et
parfois même au niveau mondial. Parmi les entreprises et institutions ayant
choisi Sopra Steria, nous retrouverons celles-ci :

Figure 5 : Exemple des clients de SSG

12
b. LIMONEST : L’un des 4 sites régionaux

Le site de Limonest compte 1200 collaborateurs en 2021 travaillant dans

plusieurs agences regroupant les principaux verticaux. Limonest n’est pas le
seul site SSG présent dans la région, puisque la ville d’Annecy compte
également une implantation SSG, ainsi que Grenoble et Clermont.
Dans chacune des agences composant les sites tels que Limonest, l’approche
« end-to-end » est présente. Cette approche décrite plus haut, en plus de
proposer un accompagnement géographique des agences clientes, propose
un panel complet de services comme décrit ci- dessous :

Figure 6 : Approche « end-to-end », les services proposes.

À mon arrivée chez Sopra Steria en octobre 2020, j'ai entamé un parcours
professionnel marqué par une série d'affectations au sein de diverses
agences et missions. Mon expérience au sein de l'entreprise a été jalonnée
de changements et d'adaptations qui m'ont permis de découvrir les
différentes facettes du secteur de l'informatique et de la gestion de projets.

13
J'ai commencé mon parcours au sein de l'agence Industrie, où j'ai été
impliqué dans un projet de Maintien en Conditions Opérationnelles (MCO)
pour le Service Départemental-Métropolitain d'Incendie et de Secours
(SDMIS). Au cours des six premiers mois, j'ai acquis une certaine
compréhension des enjeux liés à la gestion des systèmes informatiques
critiques et j'ai contribué à maintenir leur fiabilité.

Par la suite, j'ai été transféré à la Ville de Lyon (VDL), toujours au sein de
l'agence Industrie, où j'ai travaillé pendant presque un an sur des projets liés
à la ville. Cette expérience m'a offert l'opportunité de participer à des projets
impactants pour la communauté, bien que le rythme soutenu et les
exigences aient également apporté leur lot de défis.

Après cette période, j'ai été détaché à l'agence SSE (Services, Santé, et
Énergie) pour une mission de Tierce Maintenance Applicative (TMA) au profit
de la Caisse Nationale d'Assurance Maladie (CNAM). Au cours des trois
trimestres suivants, j'ai travaillé sur le soutien et l'amélioration des systèmes
informatiques de la CNAM, acquérant ainsi une perspective plus approfondie
des enjeux dans le domaine de la santé et des services publics.

Enfin, j'ai fait un retour au SDMIS, où j'ai poursuivi la maintenance des

systèmes informatiques critiques, assurant leur disponibilité pour les
opérations de sécurité publique.

Ce parcours m'a apporté une expérience variée et m'a permis de mieux

comprendre les réalités et les contraintes de l'informatique au sein
d'organisations publiques et privées. Dans le cadre de ce mémoire, je vais
examiner plus en détail certaines de ces expériences, en tirant des
enseignements essentiels qui peuvent contribuer à ma croissance
professionnelle et à l'évolution des pratiques au sein de Sopra Steria.

14
III. Ville de Lyon
Un des premier projet sur lequel j’ai été amené à travailler est produit pour la
ville de Lyon. Il s’agit d’un projet de build1 initié par SSG en fin d’année 2020.

1. Le client

Ville centre de plus de 500.000 habitants, Lyon est au cœur d’une métropole
regroupant 1,5 million d’habitants et 59 communes. Elle gère un budget de près de
800 millions d’euros. Selon la loi P.M.L2, elle s’organise en 9 arrondissements. Elle
compte 221 conseillers municipaux et près de 8.000 agents.

Elle est organisée en :

· Une Direction Générale à laquelle sont rattachées la Direction des Finances

et le

Contrôle de Gestion ;

· Un Secrétariat Général comprenant 5 directions (dont la DSITN) et 4 missions

transverses (dont la Relation à l’Usager et le Délégué à la Protection des
données) ;

· Une Délégation Générale aux Affaires Sociales, aux Sports, à

l’Education et à l’Enfance ;

· Une Délégation Générale à la Culture ;

· Une Délégation Générale au Service au Public et à la Sécurité ;

· Une Délégation Générale aux Ressources Humaines ;

15
 · Une Délégation Générale à l’Urbanisme, à l’Immobilier et aux Travaux.

1
Un projet de build signifie la réalisation d’une toute nouvelle application.

2
La loi nᵒ 82-1170 du 31 décembre 1982 portant modification de certaines dispositions

du code électoral relatives à l'élection des membres du conseil de Paris et des conseils
municipaux de Lyon

Figure 8 : Macro Organigramme Ville de Lyon

2. Le projet Manif

Le projet de build mené par Sopra Steria depuis le mois de Juillet 2020
sur lequel j’ai été affecté s’appelle « Manif ». Ce dernier a pour but de

16
faciliter la demande de manifestations publiques pour les demandeurs. Par
manifestations, il faut entendre les évènements publics tels que les marchés
par exemple. Cette procédure n’est pas encore informatisée dans son
intégralité, le projet a donc vu le jour dans le but d’y remédier.

a. Besoin fonctionnel

La ville de Lyon, 3ème ville française selon sa démographie, est l’une

des villes les plus attractives en France depuis les 30 dernières années.
Considérée autrefois comme un bassin industriel, on retrouve aujourd’hui de
plus en plus d’entreprises du secteur tertiaire. Le changement de population
a aussi fait grandir les évènements culturels de la ville, dont le plus important
reste la fête des lumières, fête mondialement connue et que la ville de Lyon
accueille tous les ans.

Ainsi, le nombre de manifestations publiques dans la ville ne cesse de croître, mais le

système

d’enregistrement de celles-ci auprès de la ville reste archaïque.

« Plus de 1 300 manifestations sont organisées chaque année sur l’espace

public à Lyon. Ce chiffre est en constante augmentation et ce dans un
contexte de sécurité renforcée et de risque attentat. Ainsi, qu’elles soient
culturelles, sportives, humanitaires ou promotionnelles, un certain nombre
de règles liées à la sécurité sont à respecter pour que les festivités sur
l’espace public soient menées à bien et dans de bonnes conditions. L’objectif
étant d’obtenir toutes les autorisations nécessaires et de mettre en place
tous les éléments concourant à la sécurité des participants et des biens ainsi
qu’à la salubrité et à la tranquillité publique. »

Actuellement à l’adresse :

https://www.lyon.fr/demarche/securite/organiser-un-evenement-sur-lespace-public

17
L’on retrouve une procédure demandant de remplir un formulaire au format
word, pour enregistrer sa manifestation :

Figure 9 : word d’enregistrement d’une manifestation

18
 Pas besoin d’analyser bien loin la situation pour comprendre la lourdeur de cette
procédure :

Problèmes

Vérification des données saisies à la main

Problème de compatibilité des versions

UX/UI inexistante pour l’utilisateur

Impossibilité d’extraire correctement les données historiques

Gestion des dossiers à la main

Aucune mise à disposition de l’état de traitement du dossier sans

intervention humaine

La ville avait donc besoin d’informatiser ce processus pour améliorer la vitesse de

traitement

ainsi que la facilité d’inscription aux créateurs de manifestations.

b. Cahier des charges

Les enjeux pour la ville de Lyon sont les suivants :

- Augmenter la satisfaction des usagers en proposant un nouveau

e-service dématérialisé disponible 24/7 pour les usagers,
- Réduire les temps de traitement des demandes, la préparation et
l’organisation des commissions en optimisant la collaboration entre
toutes les parties prenantes et les services de la Ville,
- Optimiser la gestion des demandes grâce à la mise à disposition d'analyses
statistiques,
- Bénéficier d’un financement européen dès lors que le projet est en production
avant fin 2020.

19
 Dans le cadre du projet Secur’Cities, il est ainsi prévu :

- D’une part, de dématérialiser le formulaire papier de demande de

manifestation (dit formulaire « OTEP3 ») et d’offrir la possibilité de
facilement décrire le périmètre de la manifestation à l’aide d’un outil
de cartographie simplifié pour faciliter le dépôt de demande de
manifestation pour les organisateurs.
- D’autre part, de permettre l’instruction dématérialisée des différentes
demandes, d’assurer le suivi des différentes manifestations et
l’organisation des réunions de la Commission Consultative
Communale de Sécurité Publique (3CSP). Cette solution intégrera
également des outils permettant une analyse statistique et des outils
d’aide à l’instruction. L’ensemble de ces outils compose le logiciel de
gestion partagée des demandes de manifestation sur l’espace public
(ou « logiciel workflow »).

Afin de bénéficier du financement européen pour la réalisation du projet, la

Direction Sécurité et Prévention doit émettre un rapport de mise en œuvre de la
solution résultant du projet, qui intégrera une période d’utilisation de 3 mois
minimum. Ce rapport rédigé par la DSP est attendu pour juin 2021 au plus tard.

3
Organisation temporaire de l’espace publique

20
Qu’est-ce que le projet « Secur’Cities » ?

Ce projet prend forme autour de deux villes rayonnantes tant culturellement que
financièrement depuis de nombreuses années : Lyon, capitale des Gaules et 3ème ville
française, et Barcelone capitale de la Catalogne en Espagne, véritable ville culturelle.
Le projet a pour objectif de proposer toujours plus de sécurité aux habitants ainsi
qu’une meilleure organisation pour les créateurs des manifestations. Le projet séduit
l’Union Européenne et les deux villes tests se sont vu attribuer des subventions.
Maintenant que cet aparté est clos, voici la suite du cahier des charges.

Le cahier des charges du projet introduit dans un premier temps le besoin du

marché, à savoir le site « manifestation ». Ce projet implique :

- La mise en œuvre sous Lutèce d’un nouvel e-service dématérialisé de gestion

des demandes de manifestations sur l’espace public.
- La dématérialisation du formulaire de demande de manifestations sur l’espace public
existant.
- La création d’un éditeur de plans de sites de manifestations s’appuyant sur des fonds
de plans existants.

Néanmoins, le marché gagné par Sopra Steria Group n’inclut pas les éléments suivants, qui
viendraient encadrer le projet de build en lui-même :

- L’installation de l’architecture Java/Lutèce,

- La mise en place des environnements (recette, pré-production, production),
- La TMA, la TME,
- La reprise des données des demandes antérieures,
- La création des fonds de plans et pictogrammes de l’éditeur.

21
La première pierre technique du projet est fournie ici, il devra être réalisé en Java
8/Lutèce.

Java 8, pas trop de problème pour en comprendre l’environnement, cependant Lutèce

est un Framework peu connu, il sera détaillé plus loin.
Comme évoqué plus haut, la ville de Lyon a reçu pour la création de ce service une
aide européenne, la prise en charge par l’Europe d’une partie du coût du projet
impose une date butoir de livraison, interdisant au projet un retard quel qu’il soit.

Les exigences du client étaient finalement les suivantes, c’est sur celles-ci que la
préparation des travaux techniques s’est faite :

N° Exigences
F01 Le titulaire doit procéder à la dématérialisation du formulaire de demande
existant. Une adaptation des champs doit permettre une administration
en ligne du formulaire sur le modèle des e-services existants accessibles
depuis le portail Lyon.fr.
F02 Le titulaire doit proposer un e-service accessible 24/7 aux usagers de la
Ville de Lyon et à l’ensemble des utilisateurs des services membres de la
3CSP et des partenaires identifiés.
F03 L’application doit permettre la gestion du cycle de vie d’une demande de
manifestation dans le respect des workflows du métier.
F04 Le titulaire doit intégrer un éditeur de plan d’aménagement permettant de

positionner des pictogrammes prédéfinis sur un fond de plan référencé par

l’application. Un enregistrement au format image est demandé.

F05 L’application doit permettre la gestion et l’exploitation des données saisies

par l’usager via le formulaire et son espace organisateur.

22
F06 L’application doit permettre l’administration des référentiels métiers
permettant la réalisation d’actes de gestion et la qualification des dossiers
par les utilisateurs.
F07 L’application doit permettre le téléversement, l’enregistrement, la
consultation et l’édition de fichiers.
F08 L’application doit permettre l’échange de commentaires entre usagers et
utilisateurs des services membres de la 3CSP (à préciser en conception) et
interservices de la 3CSP
F09 L’application doit permettre l’envoi de notifications aux usagers et aux
utilisateurs. Si des notifications mails sont générées, celles-ci doivent
pouvoir être historisées et accessibles à l’utilisateur en consultation.
F10 L’application doit permettre la génération des courriers types et des
documents spécifiques comme l’ordre du jour et le procès- verbal de la
Commission depuis un dictionnaire de données.
F11 Des extractions de données multi critères doivent pouvoir être réalisées
depuis l’application afin de répondre au besoin de suivi et de reporting
des services membres de la 3CSP.
F12 La gestion des identités et des profils d’utilisateurs doit pouvoir être
réalisée depuis l’application.
F13 La création de statuts, d’indicateurs de suivi et d’alertes à associer à un
dossier doit être prévue.

23
 c. Besoin technique

Comme présenté en amont, le cahier des charges mentionne l’utilisation d’une

technologie nommée « Lutece ». Je vais maintenant apporter les précisions
concernant celle-ci, car elle est la base du besoin technique du client.

Lutece, comme son nom nous laisse penser, a vu le jour à Paris, et plus précisément
au sein du SI de la ville parisienne. Le besoin était simple : proposer pour les sites de
la ville un FrameWork java proposant une surcouche pour initialiser un projet de
type CMS (système de gestion de contenu). Ainsi, le lutece core, sous forme d’un jar,
fournit la possibilité de créer une application web en Java qui fonctionne via une
interface back et front, le back administrant les données et pages proposées sur le
front.

Un CMS a pour objectif de proposer une interface d’administration qui permet aux
utilisateurs agréés de modifier le Front-Office, c’était l’ambition du projet Lutece.
Dans sa version 7.2, Lutece propose de nombreux plugins qui améliorent la création
d'applications. Ces modules, également sous forme de jar, permettent de venir
ajouter de nouvelles fonctions au site.

Schéma technique de lutece :

Figure 10 : Schéma technique du core lutec

24
 d. Cycle de vie du projet

Le projet a été monté afin d’être conçu par itération, ainsi, 18 itérations de
deux semaines ont été prévues pour mener celui-ci à bien. La première
itération a démarré en septembre 2020 comme le montrera ce schéma
récapitulant le planning général de l’équipe :

Figure 11 : RoadMap du projet manifestation

Chaque itération comporte autant de tickets évalués en nombre d’heure que

d’heure/homme disponible pour les deux semaines. Ainsi, à l’aide de l’outil
de backlog JIRA, les sprints sont présentés deux lundis par mois afin de revoir
les priorités. Durant cette réunion, nous faisons un point sur le sprint
précédent afin d’intégrer les modifications nécessaires pour l’itération à
venir.

3. Actions sur le projet

J’ai intégré le projet manifestation en qualité de développeur fullstack java.

Durant toute la durée du projet j’ai donc développé des user stories en java,
ainsi que rédiger les tests unitaires. J’ai notamment évalué quelques-unes de

25
mes US (sur certaines, j’ai effectué un réagencement du temps de traitement
en fonction de mon expérience). Ainsi, j’ai mené à bien une quinzaine d’user
stories, sur différents secteurs fonctionnels du projet.

J’ai été chargé dans un premier temps de travailler sur le back office
administrateur du CMS Lutece. J’y ai développé 5 lots fonctionnels,
permettant d’administrer les données du front- office. Par la suite, une fois le
back-office terminé, j’ai récupéré les user story du front office où j’ai
principalement travaillé sur la gestion des purges (RGPD4), la gestion des
comptes utilisateur etc.

Alternant entre stabilisation de l’application et livraisons de corrections de

bugs, la fin du projet m’a permis de voir pour la première fois la procédure
complète de remise d’une application à un client, sachant que celui-ci a
choisi l’approche « end to end » de Sopra Steria, en demandant une
intégration cloud de celle-ci. Ainsi, j’ai pu expérimenter les livraisons
traditionnelles par pipeline GitLab ainsi que les livraisons sur le cloud OVH.

Durant les dernières semaines au sein de l’entreprise, j’ai travaillé avec mes
collègues sur les corrections par suite de la phase de recette. Chaque
semaine, une roadmap de correction était mise en place. Une fois les
corrections effectuées, j’étais chargé de préparer une version stable et de la
déployer via docker sur les 3 environnements à disposition : recette, pré prod
et prod.

4
Le règlement UE 2016/679 du Parlement européen et du Conseil du 27 avril 2016
relatif à la protection des personnes physiques à l'égard du traitement des données à
caractère personnel

26
IV. SDMIS

1. Présentation du Contexte

Au sein du Service Départemental-Métropolitain d'Incendie et de Secours (SDMIS), mon rôle

s'inscrivait au sein d'une équipe divisée en deux domaines distincts. Le premier domaine,
appelé "domaine spécifique," était dédié aux applications développées en interne par Sopra
Steria, où l'effectif était principalement composé de développeurs. Le second domaine,
qualifié de "domaine éditeur," englobait des applications externes, pour lesquelles l'équipe
était principalement constituée de spécialistes en Business Intelligence (BI), Talend, et autres
compétences similaires. Je faisais partie du domaine spécifique.

L'équipe était relativement restreinte, comprenant trois développeurs travaillant sur le

domaine spécifique, ainsi qu'un Business Analyst (BA) qui jouait un rôle crucial dans la
compréhension des besoins métier.

Dans mon rôle, j'étais responsable de la gestion de cinq applications appartenant au

domaine spécifique du SDMIS :

27
 - Mon Portail : application utilisée par les pompiers qui contient leurs informations
personnelles : contacts d’urgence, situation familiale, caserne d’affectation, adresse
personnelle …
- Webservice SMS : Webservice utilisé par différente application du SDMIS pour l’envoi
de SMS
- Point Métier : application rassemblant divers outils touchant à divers corps de métier
au sein du SDMIS. On y retrouve : La gestion de l'annuaire du SDMIS, une partie
destinée au SSSM, une application d'envoi de SMS.
- 3333TEL : application servant à la prise de rendez-vous médicaux au près du
personnel SSSM

2. Tâches Récurrentes au Sein de la TMA

a. MCO - Gestion des Tickets Incidents/Demandes d'Évolution

Une partie significative de mon travail consistait à gérer le Maintien en Conditions

Opérationnelles (MCO) des applications. Cela inclut la gestion des tickets incidents et des
demandes d'évolution soumises par les utilisateurs. La première étape de ce processus était
de chiffrer les tâches à effectuer et de fournir des estimations au Chef de Projet (CP) du côté
métier. Ces estimations étaient exprimées sous la forme de tailles de t-shirt, avec une échelle
allant de "S" (pour moins d'une journée) à "M" (pour entre une et deux journées) et "L"
(pour moins de trois journées). Si une tâche nécessitait plus de trois jours de travail, elle était
alors soumise sous forme de devis.

b. Réunions COAPP (Comité Opérationnel d'Application)

28
Chaque semaine, tous les Chefs de Projet du côté métier organisaient une réunion appelée
COAPP. Ces réunions étaient animées par le Responsable d'Application du côté Sopra Steria.
Elles constituaient un forum essentiel pour discuter des priorités, des avancements, et pour
s'assurer que les demandes métier étaient correctement prises en compte dans la
planification.

Le support du COAPP est un Excel avec différents onglets qui est utilisé à la manière d’un
powerpoint. Pour des raisons de confidentialité je ne peux pas montrer tous les onglets.

Voilà une description de chacun d’entre eux :

- La partie News sert à aborder l’avancement sur le gros chantier mais aussi mettre en
visibilité de tous les futures absences.
- La partie RIDA sert à définir les actions à mettre en place afin de traiter au mieux les
différents sujets

29
- La partie Devis contient la liste des devis en cours sur le périmètre ainsi que leur
statut d'avancement
- La partie Volumétrie contient une capture d’écran de nos résultat sur les SLA du mois
en cours

- La partie Tickets contient la liste de tous les tickets ouvert sur le périmètre, on
abordera ensuite ses tickets dans les parties Incidents ou Services
- La partie Incident contient la liste de tous les incident avec, lorsque c’est possible, une
date de livraison prévisionnelle du correctif
- La partie Services contient toutes les demandes de services avec, lorsque c’est
possible, une date de livraison prévisionnelle de l’évolution

30
 c. Réunions de Livraison

En outre, j'ai eu l'opportunité d'animer certaines réunions de livraison, qui avaient lieu
chaque jeudi. Lors de ces réunions, nous planifions les livraisons prévues pour la semaine
suivante, à la fois en environnement de test (INT) et en production (PROD). Les livraisons en
INT se déroulaient les jeudis, tandis que celles en PROD étaient programmées pour le mardi.

Ces réunions étaient cruciales pour assurer une transition fluide des nouvelles
fonctionnalités et correctifs vers les environnements de production, tout en minimisant les
interruptions potentielles pour les utilisateurs finaux. Pour rendre ce processus aussi
transparent que possible, nous partagions le tableau de suivi des livraisons avec tous les
Chefs de Projet (CP) clients. Au cours de la réunion, nous passions en revue les livraisons qui
avaient eu lieu au cours de la semaine en cours, puis nous examinions celles qui étaient
planifiées pour la semaine suivante.

31
L'objectif était multiple : tout d'abord, nous nous assurons que les membres de l’équipe
“Unité système” (US) à livrer ne seraient pas surchargés la semaine suivante, ce qui aurait pu
compromettre la qualité et la stabilité des livraisons. De plus, nous profitions de ces réunions
pour anticiper d'éventuelles indisponibilités de chacun des CP, ce qui aurait pu avoir un
impact sur la mise en place en INT ou en PROD de certaines applications. Cette approche
proactive a permis de minimiser les risques et de garantir une livraison réussie.

Tableau des livraisons d’une semaine effectué

Tableau des livraison d’une semaine à venir

Une fois la réunion effectué il est important de refaire une passe sur le tableau a différent
moment :

32
 - Les vendredi : Tous les vendredi soir, un mail récapitulatif des livraisons de la semaine
à venir est envoyé à l’intégralité du SI du SDMIS. Il est donc important de s’assurer
que tout le monde a bien rempli sa ligne correctement.
- Les veilles de livraison : Il faut s’assurer à la veille de chaque livraison que tout le
monde a bien rempli la ligne “sources” que le répertoire renseigné contient bien les
sources qui doivent être livré

3. Évolution du Webservice SMS

L'une des missions marquantes au sein de mon rôle au SDMIS a été l'évolution du
Webservice SMS, un projet qui a mis en lumière plusieurs facettes de la gestion de projet,
tout en relevant des défis techniques significatifs.

a. Contexte

Le Webservice SMS était initialement conçu pour interagir avec une API SOAP. Cependant,
l'évolution technologique a poussé vers l'adoption d'une API REST, plus moderne et flexible.
Mon rôle était de mener cette transition en gérant tous les aspects de ce projet, de l'analyse
initiale à la livraison finale.

b. Analyse et Chiffrage

La première étape de ce projet consistait à réaliser une analyse détaillée des besoins, en
collaboration avec le client. Cette étape a été cruciale pour comprendre pleinement les
objectifs de l'évolution, ainsi que les contraintes et les besoins spécifiques.

33
En tant que chef de projet, j'ai travaillé en étroite collaboration avec l'équipe technique pour
déterminer la portée de l'évolution. Cette phase de chiffrage a permis de fournir au client
une estimation précise de la taille du projet, classée comme "M" pour une durée estimée
entre une et deux journées.

c. Gestion de Projet et Documentation

L'aspect gestion de projet a pris une place centrale tout au long de cette mission. J'ai joué un
rôle essentiel dans la coordination des activités, en veillant à ce que chaque étape soit
correctement planifiée et exécutée.

Une part importante de ce projet a été la mise à jour de la documentation des applications
qui utilisaient le Webservice SMS. Cela inclut la création de guides de migration détaillés,
permettant aux équipes de développement et aux utilisateurs finaux de comprendre les
changements et de s'y adapter en conséquence.

La phase de développement a nécessité une coordination minutieuse pour garantir une

transition en douceur. Après la réalisation des développements, des tests rigoureux ont été
effectués en environnement de qualification (INT) en collaboration avec le client pour
s'assurer que les nouvelles fonctionnalités répondaient aux besoins et étaient exemptes de
bugs.

L'évolution du Webservice SMS a été une expérience riche en enseignements. Elle m'a
permis de développer mes compétences en gestion de projet, en communication avec les
clients, en coordination d'équipe et en documentation. De plus, cette mission a mis en
évidence l'importance de s'adapter aux évolutions technologiques, tout en maintenant la
stabilité des systèmes existants.

34
Ce projet m'a offert une perspective approfondie sur la gestion de projets informatiques au
sein d'une équipe restreinte, soulignant l'importance de l'équilibrage entre les
responsabilités de gestion de projet et les aspects techniques du développement. Il a
renforcé ma conviction que la gestion de projet efficace est la clé du succès de tout projet
informatique.

4. Migration des Interfaces Talend

a. Contexte et Introduction à Talend

Talend est une suite intégrée d'intégration de données et d'ETL (Extract, Transform, Load) qui
permet aux entreprises de gérer, transformer et synchroniser de grandes quantités de
données de manière efficace. Elle offre une plateforme puissante pour l'intégration de
données, la gestion de l'ETL, et l'automatisation des processus.

Exemple d’interface Talend

35
Le projet de migration des interfaces Talend était une initiative stratégique visant à mettre à
jour l'ensemble des interfaces Talend utilisées au sein de l'entreprise. Avant cette migration,
ces interfaces étaient développées en utilisant des versions de Talend allant de 4.7 à 8. La
mise à niveau vers Talend 8 était essentielle pour bénéficier des dernières fonctionnalités et
garantir une gestion efficace des flux de données.

b. Planification et Préparation

La première étape de ce projet a été la planification minutieuse. Il était crucial de déterminer

quelles interfaces devaient être migrées en priorité. Cela a nécessité une réunion de
consultation avec le client pour identifier les besoins critiques et les priorités
opérationnelles. Une fois ces informations en main, nous avons élaboré un document de
procédure de migration détaillé. Ce document servait de guide pour les différentes étapes de
la migration, du début à la fin.

c. Gestion de Projet et Suivi

La gestion de projet a joué un rôle central dans ce processus de migration. Pour garantir un
déroulement fluide du projet, nous avons créé un tableau de suivi détaillé qui permettait de
suivre l'avancement de chaque étape de la migration. Cela comprenait la répartition du
travail entre les membres de l'équipe, la validation des étapes achevées, et la résolution des
problèmes qui pouvaient survenir en cours de route.

36
 d. Migrations par Lots

Pour organiser efficacement le travail, nous avons découpé le projet en quatre lots distincts,
chacun représentant une application spécifique. Chaque lot a été livré indépendamment, en
commençant par les interfaces les plus critiques et en terminant par celles de moindre
importance.

e. Déroulement de la Migration

La migration proprement dite a été un processus complexe. Nous avons dû adapter les
composants des interfaces existantes pour les rendre compatibles avec Talend 8. Cela inclut
la mise à jour des transformations, des connexions aux sources de données, et des scripts
personnalisés. Une fois les migrations terminées, des Tests Unitaires (TU) ont été lancés pour
vérifier que les interfaces fonctionnaient correctement dans l'environnement Talend 8.

37
 f. Livraison des Interfaces Migrées

La livraison des interfaces migrées a été la dernière étape du projet. Chaque lot a été livré
séparément, avec une documentation détaillée pour faciliter l'intégration et l'utilisation par
les équipes opérationnelles.
J’ai également dû reprendre l’ensemble des documents existant pour chaque interface livré
afin de m’assurer que nous n'ayons pas de documents obsolètes (que ce soit les SFD ou les
STD)

Dans ce cas, la STD pour l’interface HRA_VERS_OPG n’existait pas donc j’ai du la créer et
mettre à jour les autres documents

g. Conclusion

Ce projet de migration des interfaces Talend a été une expérience enrichissante à bien des
égards. Il a mis en lumière l'importance d'une planification minutieuse, d'une gestion de
projet efficace, et de la collaboration étroite avec le client pour garantir la réussite d'une
mise à jour technologique majeure. Il a également souligné les compétences essentielles en
matière de gestion de données et d'ETL nécessaires pour mener à bien des projets de cette
envergure. En fin de compte, cette migration a permis à l'entreprise de tirer parti des
fonctionnalités avancées de Talend 8, renforçant ainsi sa capacité à gérer et à intégrer
efficacement les données dans un environnement en constante évolution.

38
 5. Sentinelle de la documentation

J’ai également travaillé à la rédaction de SFD et à la réalisation de maquettes concernant un

projet interne qui visait à inciter les collaborateurs à mettre à jour les différentes
documentations à chaque développement et de bien suivre le processus de livraison. Ce
projet (qui s’intitulait Sentinelle de la Documentation ) n’a pas pu voir le jour pour différentes
raisons.

Sur cette interface, le collaborateur doit spécifier le ticket, la date de livraison en production,
l'application concerné ainsi que le type de développement. En fonction de l’application
choisie le collaborateur doit ensuite renseigner les documents mis à jour ainsi que l’état
EasyVista du ticket (pour s’assurer qu’il soit bien mis à jour) et le ticket de livraison. Une fois
que toutes ces informations sont saisies, le collaborateur peut valider sa ligne et la demande
de livraison sera validée. Une vue d’ensemble serait ensuite disponible pour avoir un suivi de
la documentation des applications ainsi que des commentaires.

39
V. Projet Personnel

Face aux exigences du diplôme et aux responsabilités qui m'ont été confiées au sein de Sopra
Steria, il m'était clair que les projets que j'avais menés tout au long de mon alternance ne
seraient probablement pas suffisants pour valider mon diplôme. C'est ainsi que j'ai pris la
décision de consacrer une partie de mon temps libre à l'élaboration de nouveaux projets.
Mon objectif était double : d'une part, acquérir une expérience plus tangible dans la gestion
de projets informatiques, et d'autre part, explorer les technologies émergentes prisées sur le
marché de l'emploi.

1. Quizz Football

a. Idée de départ

L'idée sous-jacente à ce projet consistait à concevoir une plateforme permettant aux

utilisateurs de mettre à l'épreuve leur connaissance du football de manière divertissante.

b. Equipe Projet

Pour ce projet, notre équipe était constituée de deux membres :

- Mon camarade de classe et collègue, Mohamed BOUDISSA.

- Ma propre personne, Achraf MELKI.

Nous partagions tous les deux une passion de longue date pour le football. À noter que
l'inspiration pour ce projet nous a été transmise par deux autres camarades, Maxence

40
GIRAULT et Ruben VOLOSO-PAULOS, qui avaient déjà créé la plateforme QuizzLoL avec un
objectif similaire, mais axée sur le jeu "League Of Legends".

c. Présentation technique

Pour ce site, nous avons choisi la technologie Node.js. Ce choix s'est justifié par le fait
qu'aucun membre de notre équipe n'avait d'expérience préalable avec ce langage, et l'une
de nos motivations principales était d'explorer de nouvelles stacks technologiques. Notre
décision a également été influencée par la popularité actuelle de Node.js en tant que
framework JavaScript très en vogue et très demandé.

41
 d. Initialisation du projet

Après avoir esquissé les contours généraux du projet et fait le choix technologique approprié,
nous avons organisé une séance de brainstorming. L'objectif était de définir les types de
mini-jeux qui seraient disponibles sur la plateforme. En préparation à cette réunion, nous
avons créé un espace Notion regroupant toutes les décisions prises, le planning
organisationnel, la répartition des tâches, et plus encore. Un lien vers cette page Notion est
fourni en annexe.

Lors de la réunion de brainstorming, nous avons partagé nos idées en nous donnant une
limite d'une heure pour présenter le plus grand nombre d'idées possibles. Ensuite, au cours
de l'heure suivante, nous avons procédé à l'élimination des fonctionnalités jugées moins
intéressantes ou trop complexes.

Cela nous a laissé avec 5 idées sur lesquelles nous avons continué à travailler pour affiner
notre sélection.

Voici les idées qui ont été retenues :

e. Mise en place du backlog

Après avoir défini les fonctionnalités à intégrer, j'ai mis en place un backlog pour attribuer et
surveiller l'avancement de chaque tâche.

42
43
 f. Planning previsionnel

Avec les tâches désormais clairement définies et assignées, la prochaine étape consistait à
élaborer un planning permettant de prioriser les tâches et de fixer des échéances.

Nous avons donc organisé une séance de "poker planning" afin d'évaluer chaque tâche et de
les répartir de manière efficiente. À la suite de cette séance, nous avons conclu que les
parties qui demanderaient le plus de temps seraient les modes de jeu en eux-mêmes
(FindEleven, GeoPlayer et le Quizz), tandis que la partie "Responsive" serait développée de
manière continue tout au long du projet.

Suite à ces conclusions, voici le planning que nous avons établi :

La fin du projet des développements était prévu pour le 8 Septembre.

44
 g. Imprévues et contretemps

Le projet a été initié le 13 février 2023. Tout semblait bien se dérouler au départ, mais nous
avons rapidement été confrontés à un "problème" majeur : plusieurs départs ont été
enregistrés au sein de l'équipe de Sopra Steria, dont Mohamed BOUDISSA (projet VOLVO),
qui faisait partie de notre équipe. Ces départs ont entraîné une augmentation significative
des responsabilités de Mohamed au sein de son équipe de projet, l'amenant à quitter notre
projet "Quizz Football" afin de se concentrer davantage sur ses nouvelles missions au sein de
l'entreprise.

J'ai donc pris en charge la poursuite du développement de ce projet en solitaire.

Malheureusement, malgré la réalisation de deux des trois modes de jeu prévus, le projet n'a
pas pu être achevé dans les délais impartis. Le développement du dernier mode de jeu
(Quizz) n'a pas pu être entamé, et une refonte complète du CSS s'impose.

45
 h. Retour d'expériences

Ce projet a été une expérience inestimable qui m'a permis d'acquérir une multitude de
compétences et de connaissances précieuses. Tout d'abord, il m'a appris à faire face aux
imprévus de manière proactive, en particulier en ce qui concerne la gestion des ressources
humaines. Les départs inattendus au sein de l'équipe ont été une leçon sur la flexibilité et
l'adaptation nécessaires pour maintenir un projet sur la bonne voie malgré les changements.

En tant que chef de projet, j'ai eu l'occasion de découvrir les tenants et aboutissants de la
gestion d'un projet informatique. Cela impliquait non seulement de superviser le
développement technique, mais aussi de coordonner les ressources, d'établir des priorités et
de garantir que toutes les parties prenantes étaient informées et satisfaites. Cette expérience
m'a donné un aperçu profond du rôle essentiel d'un chef de projet dans la réussite d'un
projet.

Sur le plan technique, j'ai pu explorer une nouvelle technologie passionnante en choisissant
Node.js comme plateforme pour notre site. Cette décision a élargi mes compétences et m'a
ouvert les portes vers un nouvel univers de développement logiciel. J'ai également appris à

46
évaluer les avantages et les inconvénients des différentes technologies, en tenant compte de
l'expérience de l'équipe et de la demande du marché.

En résumé, ce projet a été une opportunité enrichissante qui m'a permis de développer ma
gestion des imprévus, d'acquérir une perspective approfondie du rôle de chef de projet dans
un contexte informatique, et de m'initier à une nouvelle technologie, renforçant ainsi mon
bagage professionnel de manière significative.

2. Boutique en ligne

a. Contexte

Dans le cadre d'un module consacré aux pratiques agiles au sein de ma formation, j'ai eu
l'opportunité de participer à un projet de création d'une boutique en ligne en collaboration
avec deux de mes camarades. Cette expérience s'est avérée particulièrement enrichissante,
mettant en pratique les principes agiles de gestion de projet et de développement logiciel.

b. Définition des User Stories

L'une des premières étapes cruciales du projet consistait à définir en détail les User Stories
(US) qui représentaient les fonctionnalités et les besoins attendus par le client. Nous avons
pris le temps de recueillir toutes les spécifications, les souhaits et les exigences, puis nous les
avons soigneusement formulés en US claires et concises. Pour garantir la pertinence de ces
US, nous avons eu la chance de bénéficier de la validation du client, incarné par notre
professeur jouant ce rôle.

47
 c. Estimation des Story Points et Planification Poker

Une fois les US clairement définies, nous avons entamé le processus d'estimation en utilisant
la méthode du poker planning. Chaque US a été attribuée un certain nombre de Story Points,
reflétant sa complexité et son envergure. Cette phase de l'estimation collective nous a
permis d'obtenir une vision plus précise des efforts nécessaires pour chaque US et de
prioriser le développement en conséquence.

48
 d. Estimation en Heures et Répartition des Tâches

Après avoir attribué les Story Points, nous avons poursuivi en estimant la durée en heures
pour chaque tâche associée à chaque US. Cette étape de l'estimation nous a permis de
quantifier plus précisément le travail à effectuer. Une fois cette étape terminée, nous avons
procédé à la répartition des tâches au sein de l'équipe, en veillant à ce que chaque membre
soit affecté aux domaines où il excelle.

49
 e. Écriture des Tests Unitaires (TU)

Dans le cadre des pratiques de développement piloté par les tests (TDD), nous avons rédigé
des Tests Unitaires (TU) pour chaque fonctionnalité que nous allions implémenter. Les TU ont
joué un rôle essentiel en assurant la qualité et la fiabilité du code, tout en garantissant que
chaque US était correctement validée.

50
 f. Développement en Mode TDD

Enfin, nous avons procédé au développement proprement dit, en suivant la méthodologie du

Test-Driven Development (TDD). Cela signifie que nous écrivons d'abord les TU pour une
fonctionnalité, puis nous développons le code nécessaire pour que ces TU réussissent. Ce
processus itératif nous a permis de détecter rapidement les erreurs et de les corriger avant
qu'elles ne deviennent des problèmes majeurs.

51
 g. Retour d’expériences

En conclusion, ce projet de boutique en ligne a été une véritable mise en pratique des
pratiques agiles. Il nous a permis de développer non seulement des compétences
techniques, mais aussi une compréhension approfondie de la gestion de projet agile, de la
collaboration en équipe et de la création d'un produit logiciel de qualité. Cette expérience
restera un jalon majeur dans mon parcours de formation et de développement
professionnel.

52
VI. Conclusion et Bilan

Mon expérience en entreprise en tant qu'alternant pendant trois ans a été enrichissante,
bien que ponctuée de quelques défis. Le changement fréquent de projets et de clients en
tant qu'alternant a été un aspect que j'aurais préféré moins prononcé. J'ai également
ressenti une certaine déception quant au fait de ne pas avoir eu l'occasion de travailler sur
un projet suffisamment conséquent pour constituer la base de mon mémoire. En
conséquence, j'ai dû consacrer beaucoup de mon temps libre à un projet personnel.

Cependant, j'ai grandement apprécié le niveau d'accompagnement dont j'ai bénéficié dès
mon arrivée. J'ai toujours été bien encadré et entouré de collègues sympathiques, ce qui a
contribué à rendre l'expérience agréable malgré les défis.

En ce qui concerne mon bilan de ma formation, je dois souligner que le rythme de

l'alternance (une semaine de cours pour trois semaines en entreprise) a été très bénéfique. Il
m'a permis de travailler sur des sujets concrets en entreprise tout en continuant d'apprendre
des concepts pertinents en formation. De plus, les intervenants maîtrisent parfaitement leurs
domaines de compétence et ont privilégié les travaux pratiques plutôt que les évaluations
classiques, ce qui a favorisé mon apprentissage.

En résumé, malgré quelques défis liés au changement fréquent de projets et à la charge de

travail personnelle nécessaire pour un projet personnel, mon expérience en entreprise a été
globalement positive grâce à l'encadrement solide et à l'ambiance conviviale de l'équipe. En
ce qui concerne ma formation, le rythme d'alternance et la qualité des intervenants ont été
des atouts majeurs pour mon développement professionnel. Je me vois plus en tant que lead
tech que comme chef de projet, car j'ai une réelle passion pour la technique.

53
VII. Annexes

VDL :

Manifestation (étape de création d’une manifestation) :

54
55
56
57
58
59
 SDMIS :

Répartition des applications :

Sentinelle de la Documentation processus macroscopique :

60
 Quizz Football :

FindEleven (choix du mode de jeu) :

Règle du Jeu :

61
FindEleven (jeu) :

Geoplayer (carte) :

62
GeoPlayer (règles du jeu) :

GeoPlayer (réponse) :

63