El Gafif Essaadia

Rapport de stage de fin de formation
Présenté en vue de l'obtention du diplôme de :

INGENIEUR EN INFORMATIQUE
Sous le thème
La maintenance évolutive des applications

CCS
Réalisé par
Mlle. EL GAFIF Essadia
Organisme : CGI Technologies et solutions Logo :
Encadré par : Mme. Hajar Zouhair Encadrant professionnel

Encadré par : Mme. Fidae Harchli Encadrant pédagogique
Soutenu le 14-07-2021 devant le jury :
HALKHAMS Imane : Enseignant chercheur à l’UPF Président du jury
HAJJI Tarik : Enseignant chercheur à l’ENSAM Examinateur

Dédicaces
Louange à Allah ;
Paix et Salut sur le Prophète, Sa Famille et Ses Compagnons.
A nos parents ;
Aucune dédicace ne saurait exprimer l’amour, l’estime, le dévouement et le
respect qu’on a toujours eu pour vous. Rien au monde ne vaut les efforts fournis jour et nuit
pour notre éducation et notre bien-être. Ce travail est le fruit de vos sacrifices que vous
avez consentis pour notre éducation et notre formation.
A nos frères ;
On vous exprime à travers ce travail nos sentiments de fraternité, d’amour et
d’attachement. Avec tous nos vœux de bonheur, de santé et de réussite.
Membres de nos familles ;
Vous avez toujours été présents pour les bons conseils. Votre affection et votre
soutien nous ont été d’un grand secours tout au long de notre vie.
A tous nos amis ;
En témoignage de l’amitié qui nous uni et des souvenirs de tous les moments que
nous avons passés ensemble, on ne peut trouver les mots justes pour exprimer notre
affection.
A tous ceux qui nous aiment

Du fond du cœur MERCI
2
Université Privé de Fès CGI Technologies et Solutions
Remerciement
Au terme de ce travail, nous tenons à adresser nos sincères remerciements à tous ceux
qui ont contribué au bon déroulement de ce projet.
Nous remercions vivement M. BOUKAR Azzelarabe, mon responsable au sein de la

société pour son ultime confiance, sa disponibilité et surtout ses judicieux conseils, qui ont
contribué à alimenter ma réflexion.
Nous remercions également Mme. ZOUHAIR Hajar, notre encadrante au sein de la
société, et nous tenons à témoigner toute nos reconnaissances pour son aide durant toute la
période du stage, M. MEGZARI Chakir pour son partage d’expertise et son aide technique ainsi
que toute l’équipe TMA CCS pour leur disponibilité permanente, serviabilité ainsi que leur
précieux conseils.
Nous exprimons également nos profondes gratitudes à notre encadrante pédagogique à
l’UPF, Mme. HARCHLI Fidae, pour sa disponibilité et ses conseils et M. ITAHRIOUAN
Zakaria pour son soutien et encouragement.
Nos plus vifs remerciements vont aussi à l’ensemble du corps enseignant de l’UPF qui
nous a préparé théoriquement et pratiquement, et au corps administratif pour les conseils et les
encouragements reçus lors de cette année.
Nous tenons à remercier également tout le personnel de CGI de Fès, pour leur
serviabilité, leur accueil et leur soutien.
Nous formulons nos sincères remerciements à l’égard des membres du jury, d’avoir
accepté de juger notre travail. Finalement, nous remercions toute personne qui a contribué de
près ou de loin à l’élaboration de ce travail.
3
Table des matières
Liste des figures....................................................................................................................................... 7

Liste des acronymes ................................................................................................................................ 9
Introduction générale............................................................................................................................. 10
Chapitre I : Présentation du contexte du stage ...................................................................................... 12
I.1. Introduction............................................................................................................................... 12
I.2.Presentation de CGI Technologies et solutions ....................................................................... 12
I.2.1. Préface................................................................................................................................. 12
I.2.2. Histoire de CGI .................................................................................................................. 13
I.2.3. Constitution de CGI........................................................................................................... 14
I.2.4. Secteurs cibles de CGI ....................................................................................................... 16
I.2.5. Clients de CGI .................................................................................................................... 17
I.2.6. CGI Maroc.......................................................................................................................... 18
I.2.7. Activités de CGI Maroc ..................................................................................................... 19
I.3.Presentation de ma mission lors du stage ................................................................................ 19
I.4. Conclusion ................................................................................................................................. 20
Chapitre II : Le projet TMA CCS.......................................................................................................... 21
II.1. Introduction ............................................................................................................................. 21
II.2. TMA (Tierce Maintenance Applicative) ............................................................................... 21
II.2.1. Définition ........................................................................................................................... 21
II.2.2. Classification de la ML .................................................................................................... 22
II.2.3. Modèle de méta processus de la maintenance de logiciel .............................................. 23
II.2.4. Importances et objectifs finaux de la TMA .................................................................... 23
II.3. Définition CCS ......................................................................................................................... 24
II.4. Les différentes CCS ................................................................................................................. 24
II.4.1. Référentiel ITS (REFITS)................................................................................................ 25
II.4.2. Service Insight (SI) ........................................................................................................... 25
II.4.3. My Security Desk (MSD) ................................................................................................. 26
II.4.4. SMTP Messaging OMSM ................................................................................................ 26
II.5. Plan Assurance Qualité ........................................................................................................... 27
II.5.1. Définition ........................................................................................................................... 27
II.5.2. AMO (Assistance à la maitrise d’ouvrage) .................................................................... 27
II.5.3. Les gestions de qualité...................................................................................................... 29
II.5.4. La conception et les spécifications techniques ............................................................... 30
4
II.5.5. Les outils utilisés ............................................................................................................... 32
II.6. Conclusion ................................................................................................................................ 35
Chapitre III : Analyse fonctionnelle et technique du projet TMA-CCS ................................................ 36
III.1. Introduction............................................................................................................................ 36
III.2. La méthodologie de pilotage ................................................................................................. 36
III.3. My Security Desk (MSD) ...................................................................................................... 38
III.3.1. Description....................................................................................................................... 38
III.3.2. Architecture..................................................................................................................... 39
III.3.3. Fonctionnalité .................................................................................................................. 39
III.4. Diagramme de classe ............................................................................................................. 40
III.5. Technologies utilisées............................................................................................................. 41
III.5.1. Un Framework ................................................................................................................ 41
III.5.2. Langages .......................................................................................................................... 46
III.5.3. Serveurs ........................................................................................................................... 47
III.5.4. Logiciels ........................................................................................................................... 47
III.6. Conclusion .............................................................................................................................. 48
Chapitre IV : Les tâches réalisées ......................................................................................................... 49
IV.1. Introduction ............................................................................................................................ 49
IV.2. Recette MSD ........................................................................................................................... 49
IV.3. Mettre à niveau le Framework ZK ....................................................................................... 50
IV.3.1. La différence entre les deux versions ............................................................................ 50
IV.3.2. Réalisation ....................................................................................................................... 50
IV.4. Les tests d’intrusion avec ZAP ............................................................................................. 58
IV.5. Création des procédures stockées ......................................................................................... 61
IV.5.1. Définition ......................................................................................................................... 61
IV.5.2. Avantages ......................................................................................................................... 61
IV.5.3. Problématiques ................................................................................................................ 61
IV.5.4. Solutions ........................................................................................................................... 61
IV.6. RFC calcul des permissions................................................................................................... 63
IV.6.1. Request for Change (RFC) ? .......................................................................................... 63
IV.6.1. Problématique ................................................................................................................. 63
IV.6.2. Solution ............................................................................................................................ 64
IV.6.3. Résultat ............................................................................................................................ 66
IV.7. Batch synchronisation des changes ...................................................................................... 66
IV.7.1. C’est quoi un batch ? ...................................................................................................... 66
IV.7.2. Problématique ................................................................................................................. 67
5
IV.7.3. Solution ............................................................................................................................ 67
IV.8. Conclusion .............................................................................................................................. 68
Conclusion générale .............................................................................................................................. 69
Bibliographie ......................................................................................................................................... 70
6
Liste des figures
Figure 1 : CGI en chiffres ....................................................................................................................... 12
Figure 2 : Evolution de la marque CGI .................................................................................................. 13
Figure 3 : Les clients de CGI .................................................................................................................. 18
Figure 4 : Répartition des sites CGI Maroc ........................................................................................... 19
Figure 5 : Type maintenance ................................................................................................................ 22
Figure 6 : Modèle de méta processus de la maintenance logiciel ...................................................... 23
Figure 7 : Logo Mantis BT ..................................................................................................................... 32
Figure 8 : Flux de travail pour Mantis BT ............................................................................................. 33
Figure 9 : Logo GIT ................................................................................................................................ 33
Figure 10 : Interface JENKINS ............................................................................................................... 34
Figure 11 : Méthodologie cycle en V .................................................................................................... 36
Figure 12 : Méthodologie en cycle V en pratique ................................................................................ 38
Figure 13 : Diagramme de classe .......................................................................................................... 40
Figure 14 : Architecture N-tiers ............................................................................................................ 41
Figure 15 : Architecture Hibernate ....................................................................................................... 42
Figure 16 : Flux de communication des services web.......................................................................... 44
Figure 17 : Architecture modulaire de Spring ...................................................................................... 44
Figure 18 : Architecture server-centric de ZK ...................................................................................... 45
Figure 19 : Design pattern MVC ........................................................................................................... 45
Figure 20 : Exemple interface Mantis BT ............................................................................................. 49
Figure 21 : Pop-up d’erreur .................................................................................................................. 51
Figure 22 : Exemple hflex / vflex .......................................................................................................... 51
Figure 23 : Page Authentification avant la modification ..................................................................... 52
Figure 24 : Page Authentification après la modification ..................................................................... 52
Figure 25 : Gérer panorama avant la modification ............................................................................. 53
Figure 26 : Page gérer panorama après la modification ..................................................................... 53
Figure 27 : Fenêtre ajouter widget avant la modification ................................................................... 54
Figure 28 : Fenêtre ajouter widget après la modification ................................................................... 54
Figure 29 : Page gérer administrateurs après la modification ............................................................ 55
Figure 30 : Fenêtre ajouter administrateurs avant la modification .................................................... 56
Figure 31 : Fenêtre ajouter administrateur après la modification...................................................... 56
Figure 32 : Menu configurations et demandes avant la modification ................................................ 57
Figure 33 : Menu configurations et demandes après la modification ................................................ 57
Figure 34 : Menu suivi des changements avant la modification ......................................................... 58
Figure 35 : Menu suivi des changements après la modification ......................................................... 58
Figure 36 : Installation ZAP ................................................................................................................... 59
Figure 37 : Ajout de l’entrée ZAP ......................................................................................................... 59
Figure 38 : Activation de ZAP ............................................................................................................... 60
Figure 39 : Interface de l’outil ZAP ....................................................................................................... 60
Figure 40 : PS qui supprime data lier au client .................................................................................... 61
Figure 41 : PS qui supprime structure de data lier au client ............................................................... 62
Figure 42 : PS qui supprime Tree lié au client ...................................................................................... 62
Figure 43 : PS supprimer client ............................................................................................................. 63
Figure 44 : Modification de la structure d’un client ............................................................................ 63
Figure 45 : Requête d’Ajout de la colonne ........................................................................................... 64
7
Figure 46 : Méthode de récupération des droits ................................................................................. 64
Figure 47 : Méthode de modification de allowed ............................................................................... 64
Figure 48 : Appel de la méthode modification de allowed ................................................................. 65
Figure 49 : Modification de style .......................................................................................................... 65
Figure 50 : Rafraichissement du panneau ............................................................................................ 65
Figure 51 : Affichage du pop-up ........................................................................................................... 65
Figure 52 : Panneau clients lors de recalcule des permissions............................................................ 66
Figure 53 : Affichage du pop-up ........................................................................................................... 66
Figure 54 : Les différentes classes de Batch ......................................................................................... 67
8
Liste des acronymes
CCS : Customer Care Service
TI : Technologies de l'information
CRM : Customer Relationship Management
RH : Resource Humaine
ZAP : Zed Attack Proxy
ML : Maintenance Logicielle
OBS : Orange Business Service
TIC : Technologies de l'information et de la communication
SOAP : Simple Object Access Protocol
IHM : Interface Homme Machine.
Ajax (DWR) : Ajax (Direct Web Remoting)
AMO : Assistance à la maitrise d'ouvrage
SFG : spécifications fonctionnelles générales
STD : spécifications techniques Détaillées
FTU : Fiche des tests unitaires
XSLT : eXtensible Stylesheet Language Transformations.
API : Application Programming Interface
ORM : Object-Relationnel Mapping
SMTP : Simple Mail Transfer Protocol
HTTP : Hypertext Transfer Protocol
AXIS : Apache eXtensible Interaction System
WSDL : Web Services Description Language
COM : Component Object Model
CORBA : Common Object Request Broker Architecture
EJB : Entreprise Java Bean
XML : Extensible Markup Language
9
Introduction générale
Le savoir et la connaissance s’accroissent de plus en plus grâce à l’outil informatique, les

sociétés sont, désormais, contraintes à suivre le rythme accéléré avec lequel circule
l’information dans un vaste mouvement de changement.
De nos jours, certes, la technologie de l’information, développe un nouvel environnement
inventif au niveau des entreprises, cependant les systèmes informatiques sont ouverts, de plus
en plus interconnectés à travers diffèrent flux de données, et de moins en moins à l’abri en
termes de sécurité. Il est possible d’agir uniquement lorsqu’un problème survient en procédant
à un dépannage. Cette solution reste cependant très hasardeuse car elle ne garantit pas toujours
le bon rétablissement du système, d’une application ou d’un équipement stratégique, ni la
restauration dans un délai raisonnable.
La continuité du service dépend avant tout d’une maintenance régulière : révisions, mises à
jour, contrôles voire, en cas de dysfonctionnements, dépannages et réparations.
Ces opérations peuvent être effectuées par le client exprimant l’utilisateur final, mais bien
souvent ce travail dépasse ses compétences. La maintenance informatique est assurée soit par
une équipe d’informaticiens en interne soit externalisée auprès d’un prestataire spécialisé, on
parle alors d’infogérance ou de Tierce Maintenance Applicative (TMA).
Le but est de satisfaire les clients donneurs d’ordre et les utilisateurs finaux qui cherchent auprès
d’elle, des solutions simples, efficaces, performantes, et surtout faciles à maintenir et à faire
évoluer pour but de répondre à leurs éventuelles exigences.
Mon stage effectué au sein de CGI Technologies et Solutions, d’une période de six mois,
s'inscrit dans le cadre d'un stage technique de fin d'études qui, dans lequel, j’ai fait partie de
l’équipe TMA_CCS afin de pouvoir mener des tâches de développements évolutifs, en se
mobilisant à apporter des changements profonds pour moderniser les outils de travail, améliorer
son efficacité et optimiser les services fournis par le client.
Donc, ce rapport a pour but de donner un aperçu du stage que j'ai effectué au sein de CGI. La
migration de ZK et les évolutions que j’ai développé. Mon travail ne s’arrête pas seulement à
développer mais à en suivre tout le déroulement. Entre Lire le chiffrage, étape de test, suivi des
versions et développement, mon travail reste très varié au quotidien.
Ce rapport vous accompagnera à travers quatre chapitres pour mieux comprendre la
méthodologie suivie et l’analyse effectué pour aboutir à une solution pertinente.
Dans le premier chapitre, nous commençons par une description générale de l’établissement
d’accueil « CGI Technologies et Solutions » suivi d’une, description de projet TMA-CCS.
Dans le deuxième chapitre, on va déterminer la description de projet TMA-CCS.
Dans le troisième chapitre, nous allons voir l’analyse fonctionnelle et technique de notre
système d’information.
10
Dans le quatrième chapitre, nous présentons les tâches réalisées accompagnées d’une
description de chacune d’elles.
11
Chapitre I : Présentation du contexte du stage
I.1. Introduction
Nous introduisons le présent chapitre par une section qui donne un bref aperçu sur l’organisme
d’accueil, à savoir la société CGI, son organisation, ses domaines d’activité et ses clients. La
deuxième sera dédiée à une présentation de ma mission lors du stage.
I.2.Presentation de CGI Technologies et solutions

I.2.1. Préface
CGI Technologies et Solutions est une société de Services et d’Ingénierie Informatique. Elle se
positionne, d‘ores et déjà, en tant que vecteur de modernisation du secteur des Nouvelles
Technologies au Maroc. [1]
Groupe CGI « Conseillers en Gestion et Informatique » est un groupe canadien actif dans le
domaine des services en technologies de l'information et de la communication et en gestion des
processus d'affaires. Il a été fondé en 1976 par Serge Godin et André Imbeau.
Il se classe parmi les cinq plus grands groupes mondiaux dans son secteur. CGI et ses filiales
emploient plus de 73 000 professionnels. Le Groupe CGI fait partie de la liste Forbes Global
2000, un classement des 2000 plus grandes entreprises au monde publié par le magazine
économique américain Forbes.
L’illustration suivante présente quelques chiffres sur le Groupe CGI :
Figure 1 : CGI en chiffres
12
I.2.2. Histoire de CGI
CGI a été fondée en 1976 par deux entrepreneurs de 26 ans, Serge Godin et André Imbeau. CGI
signifiait « Conseillers en gestion et informatique ». Ils ont démarré l'entreprise dans le sous-sol
de la résidence de Serge dans la ville de Québec avec un seul client, un téléphone et beaucoup d'ambition.
Aujourd'hui, nous sommes 73 000 professionnels travaillant dans le monde entier. La société
s’étant mondialisée, nous sommes maintenant connus simplement sous le nom de CGI.
Ensemble, les professionnels de CGI ont bâti l'une de plus importantes entreprises qui offre une
gamme complète de services-conseils en technologie de l'information (TI) et en management
au monde. CGI est reconnue pour l'excellence de ses services et affiche une croissance rentable
durable.
Figure 2 : Evolution de la marque CGI
 1976-1986
Au cours de ses dix premières années d’existence, CGI a développé une stratégie, un modèle et
un ensemble de principes de gestion qui se sont traduits par une croissance considérable et qui
continuent de guider l’entreprise encore aujourd’hui – nous appelons ces éléments « la
Constitution de CGI ». Durant cette période, le marché des services en TI n’en était alors qu’à
ses balbutiements. Tout en continuant à fournir des services-conseils, CGI a élargi son offre
pour réaliser également des contrats d’intégration de systèmes.
Vers la fin de cette décennie, certains de nos clients ont envisagé la possibilité d’externaliser
leurs fonctions informatiques et plusieurs sont allés de l’avant. CGI s’est adapté en élaborant
une stratégie pour participer au marché émergent de l’impartition.
 1986-1996
En 1986, CGI a commencé à faire l’acquisition d’entreprises offrant des services d’impartition
et est devenue une société ouverte afin de les financer. Grâce à ces acquisitions, nous avons été
en mesure d’offrir des services informatiques complets, y compris des services-conseils en TI
et en gestion, des services d’intégration de systèmes ainsi que d’impartition des TI.
Au cours de cette même période, CGI s’est également établi au sein du marché des services en
gestion des processus d’affaires et s’est positionnée en vue de s’adapter à la tendance émergente
vers la mondialisation.
En 1992, la version initiale des Assises de gestion de CGI (PDF) a été créée afin de servir de
fondement pour l’ensemble des cadres de gestion, des politiques et des lignes directrices de
l’entreprise. Ces Assises de gestion ont permis à CGI de prendre des décisions d’affaires éclairées et
d’assurer une croissance saine.
13
 1996-2006
En 1996, la clientèle de CGI comprenait déjà des leaders mondiaux dans nos secteurs d’activité
cibles, et notre objectif était de disposer d’une masse critique dans les marchés géographiques
des clients clés, d’acquérir une connaissance approfondie de leurs secteurs d’activité ainsi que
de développer des pratiques spécialisées et des solutions novatrices.
Caractérisée par la mondialisation et les regroupements d’entreprises, cette période représente
aussi celle où le secteur informatique a atteint sa maturité. L’exécution de notre stratégie de
croissance axée sur les acquisitions et sur la croissance interne a occupé une place centrale
pendant cette phase d’expansion. Nous appliquons d’ailleurs cette stratégie encore aujourd’hui.
 De 2006 à aujourd'hui…
Cette période est marquée par un engagement continu envers les principes fondamentaux qui
contribuent au succès de tous les partenaires de CGI et à la réalisation de son objectif stratégique
qui est de doubler la taille de l’entreprise.
En 2010
CGI a fait l’acquisition de Stanley Inc., et de ses filiales Oberon et Techrizon. Cette acquisition
a presque fait doubler la taille des activités de CGI aux États-Unis. De plus, cette combinaison
de ressources et de compétences a créé davantage d’occasions de croissance au sein de
l’important marché du gouvernement fédéral des États-Unis.
Deux années plus tard, CGI a réalisé sa plus grande acquisition avec Logica, une entreprise
anglo-néerlandaise de services technologiques et d’entreprise. L’acquisition a fait passer la
taille de son équipe de 31 000 à 65 000 professionnels, et a accru sa présence, ses capacités et
son expertise pour servir ses clients dans les Amériques, en Europe et en Asie. Grâce à cette
acquisition, CGI se classe au cinquième rang parmi les plus importantes entreprises
indépendantes de services-conseils complets en TI et en management au monde.
Aujourd’hui, forte d’une présence dans de centaines d’emplacements partout dans le monde,
d’une solide expertise sectorielle et d’un éventail complet de services en technologie de
l’information (TI), CGI est en mesure de répondre aux besoins d’affaires de ses clients partout,
en tout temps. CGI est toujours déterminée à être reconnue comme un leader de classe mondiale
qui offre une gamme complète de services-conseils en TI et en management par ses clients, ses
membres et ses actionnaires. Tout en restant fidèle à sa Constitution, CGI continue à s’adapter
pour mieux tenir compte des changements du marché des TI, répondre aux exigences
commerciales de ses clients à l’échelle locale et mondiale, et satisfaire les attentes de ses
professionnels et de ses actionnaires.
I.2.3. Constitution de CGI
La vision de CGI :
Être un leader de classe mondiale qui offre une gamme complète de services conseils en
technologie de l’information (TI) et en management et qui contribue au succès de ses clients.
14
La mission de CGI :
Contribuer au succès de ses clients grâce à des services-conseils de la plus grande qualité,
compétence et objectivité ; exercer un leadership éclairé qui les aidera à atteindre pleinement
leurs objectifs en technologie de l’information, en processus d’affaires et en gestion.
Les valeurs de CGI :
Partenariat et qualité
Pour nous, le partenariat et la qualité constituent une philosophie et une façon d'être. Nous
approfondissons sans cesse notre compréhension des activités de nos clients. Nous développons
les meilleures pratiques de gestion, nous y adhérons et nous les intégrons à nos cadres de gestion
de la relation client et de prestation des services afin d'établir des partenariats solides et
durables. Nous sommes à l'écoute de nos clients et nous avons à cœur leur pleine satisfaction.
Objectivité et intégrité
Nous faisons preuve de la plus grande indépendance dans le choix des produits, services et
solutions que nous recommandons à nos clients. Nous adhérons aux meilleurs standards de
qualité, d’objectivité et d’intégrité. Nous n’acceptons aucune rémunération de la part de
fournisseurs. Nous agissons toujours de façon honnête et éthique. Nous ne cherchons jamais à
tirer d’avantages indus et évitons les conflits d’intérêts, qu’ils soient réels ou perçus.
Intrapreneurship et partage
Notre succès collectif repose sur notre compétence, notre engagement et notre enthousiasme.
Nous favorisons une culture d’innovation et d’autonomie de façon à rendre chacun d’entre nous
imputable de la satisfaction de nos clients, assurant ainsi notre croissance rentable. Par le travail
d’équipe et le partage de notre savoir-faire et de nos connaissances dans toutes nos activités à
l’échelle mondiale, nous offrons à nos clients ce que CGI a de meilleur. En tant que membres
de CGI, nous prenons part activement au succès de notre entreprise, et bénéficions de la valeur
ainsi créée en participant aux profits et en ayant accès à l’actionnariat.
15
Respect
Dans toutes nos actions, nous sommes respectueux envers nos membres, clients, partenaires
d’affaires et concurrents. En tant qu’entreprise mondiale, nous reconnaissons la grande richesse
que la diversité nous apporte. Nous célébrons cette diversité tout en adhérant à la culture
d’entreprise de CGI.
Solidité financière
Tous nos efforts visent une performance financière qui se distingue par sa constance et sa
solidité afin de soutenir notre croissance à long terme au bénéfice de nos membres et de nos
actionnaires. Notre solidité financière nous permet d’investir continuellement dans les capacités
de nos membres, dans nos services et dans nos solutions d’affaires au profit de nos clients. Dans
ce but, nous gérons nos affaires de manière à réaliser un rendement supérieur aux normes de
l’industrie.
Responsabilité sociale
Notre modèle d’affaires, qui en est un de proximité, a été conçu afin de développer des liens
étroits avec nos clients et avec nos collectivités. En tant que membres, nous prenons à cœur nos
responsabilités sociales et contribuons à l’évolution des collectivités où nous vivons et
travaillons.
I.2.4. Secteurs cibles de CGI
CGI met à profit ses connaissances sectorielles approfondies et son expertise technologique afin
de fournir à ses clients des repères dans le dédale que constitue la numérisation des ressources
humaines, des processus et des technologies.
Services bancaires – Nous travaillons avec 15 des 20 plus importantes banques au
monde et collaborons avec nos 10 principaux clients depuis en moyenne 26 ans.
Communications – Nous collaborons avec 6 des plus importants fournisseurs de
services de communication au monde pour répondre aux demandes des
consommateurs pour de nouveaux produits et services et offrir une prestation de
services omnicanale, personnalisée et en temps réel.
Gouvernements – CGI a collaboré avec plus de 2 000 clients dans 15 pays pour
améliorer les services offerts aux citoyens et l’efficacité opérationnelle.
16
Santé et sciences de la vie – Nous offrons du soutien à plus de 1 000 établissements
de santé, à 195 M de prestataires de régimes d’assurance maladie, à 3 millions de
fournisseurs, à 500 pharmacies et à 50 entreprises pharmaceutiques et de sciences de
la vie.
Assurance – Nous aidons des centaines d’assureurs, de courtiers et d’agents partout

dans le monde, y compris 7 des 10 principales compagnies d’assurance à l’échelle
mondiale.
Secteur manufacturier – Nous offrons des services à plus de 700 clients du secteur
manufacturier dans divers segments, dont les industries automobiles et aérospatiale,
la haute technologie, les industries minière et métallurgique, les pâtes et papiers, et
les produits chimiques.
Pétrole et gaz – CGI est le partenaire de toutes les principales sociétés pétrolières et
gazières dans le monde, offrant des services pour l’ensemble de la chaîne de valeur.
Commerce de détail et services aux consommateurs – CGI offre des services à
plus de 800 clients dans les domaines du commerce de détail, de la vente en gros,
des biens de consommation courante et des services aux consommateurs.
Transport et logistique − Nous collaborons avec des chefs de file des secteurs du
transport aérien, ferroviaire, maritime, routier et du transit régional, et de la logistique.
Services publics – CGI est partenaire de plus de 450 clients des secteurs de
l’électricité, de l’eau et du gaz, et de 8 des 10 plus grandes sociétés de services publics
en Europe et en Amérique du Nord.
I.2.5. Clients de CGI
CGI a une clientèle internationale, avec de grands clients institutionnels dans un large éventail
d'industries et de marchés. Les États-Unis représentaient 29% de leur clientèle en mars 2015,
tandis que le Canada était le deuxième pourcentage le plus élevé avec 15%. La majorité des
contrats restants de CGI sont en Europe, avec 15% dans le reste du monde.
Ci-dessous l’ensemble des clients clés de CGI :
17
Figure 3 : Les clients de CGI
I.2.6. CGI Maroc
CGI figure parmi les plus importants fournisseurs de services en technologies de l’information
(TI) au monde. Au Maroc, où travaillent 920 professionnels, il offre des services complets en
TI, dont des services-conseils en management ainsi que des services d’intégration de systèmes,
en gestion des processus d’affaires et d’impartition (externalisation).
CGI est le premier fournisseur francophone de services en TI offerts sur le continent « Near
shore » au Maroc. Cette position permet à CGI de collaborer étroitement avec ses clients
français et de leur offrir un savoir-faire sectoriel tant sur le plan des technologies que des
affaires, afin de contribuer à la croissance de leur organisation.
CGI offre actuellement des services à 45 clients actifs formés de grands noms français pour qui
ses professionnels réalisent une cinquantaine de projets.
CGI dispose de plusieurs centres techniques et fonctionnels au Maroc. Ces centres offrent
notamment des services liés aux technologies SAP, Java JEE, Mainframe, Oracle et Microsoft,
ainsi que des systèmes de gestion de la relation client (CRM) et des RH.
CGI au Maroc possède une double certification : ISO 9001 et ISO 27001.
CGI Maroc est un des premiers fournisseurs francophones de services en TI, avec 3 sites :
Casablanca, Rabat et Fès.
18
Figure 4 : Répartition des sites CGI Maroc
I.2.7. Activités de CGI Maroc
Actuellement, 45 clients dans 6 secteurs d’activité. CGI Maroc fournit à ses clients plusieurs
prestations dans des secteurs diversifiés :[3]
Intégration de systèmes : aider les clients à concevoir, élaborer et intégrer des systèmes et
applications pour optimiser leur fonctionnement.
Application Management : refondre efficacement les systèmes qui appuient un processus
d'affaires, pour atteindre les résultats visés.
Infrastructure Management : offrir aux clients une gamme complète de services
d'architecture d'entreprise allant des services conseils stratégiques à la mise en œuvre final.
Managed Testing : fournir à l'organisation, les processus et l'environnement de test qui
permettront d'obtenir des résultats optimaux.
Business Process Outsourcing : l'externalisation d'une partie de l'activité de l'entreprise vers
un prestataire extérieur, un sous-traitant.
Support : aider les clients à maximiser leurs investissements en leur offrant un soutien
personnalisé grâce à des services tels que du matériel de formation, des communications
continues et des conseils techniques d'experts.
I.3.Presentation de ma mission lors du stage
Suite à mon intégration au projet TMA CCS, j’étais mené à suivre un ensemble de formations,
qu’on peut les catégorisées en deux parties :
- Formations présentées par l’entreprises, pour but de faire découvrir au nouvel arrivant
son cadre de travail, ses différentes assises de gestion, ses pratiques et démarches à
19
suivre et à appliquer afin de préserver son processus de qualité et rester toujours sous le
cadre de norme 9001.
- Formations reliées au cadre du projet TMA CCS, ces derniers cernes en particulier
l’aspect de sécurité, applicatives et techniques. Ceci est fait afin de former les
collaborateurs, d’être alerter a toute éventuelle menace, distinguer entre information :
publique, confidentiel, privée...
Elle s’étend également avec la récupération de plusieurs document dédié à l’explication d’une
façon général, découvrir le plan de qualité du projet, les procédures pour la mise en place de
l’environnement, l’installation des différentes CCS, afin de garder la même structure
d’enivrement de développement local.
Après avoir terminé la totalité des formations obligatoires, une réunion a été organisée par mon
manager, qui a pris le soin dans un premier temps, de me donner une idée générale sur les
différentes visions est perceptives ciblés au cours des prochaines mois. Dans un second temps,
on a eu un petit discours de découverte pour cerner mes connaissances dans le domaine, à
travers lequel, il m’a confié des tâches particulières dans le projet.
Alors, nous avons décidé que je commence mon activité au sien de l’équipe de TMA afin de
collaborer les efforts pour la mise en place des évolutions au faveurs de l’application MSD.
Dans ce cadre, je me suis engagé à réaliser deux missions respectives et indispensables pour le
bon déroulement du projet TMA CCS, qui en effet, sont :
- Le développement des évolutions affectés tout en veillant sur la non régression sur
d’autres fonctionnalités des CCS.
- Mener le travail en respectant les démarches de qualité indiquée et respecter par tous les
membres du projet pour but de clarifier, documenter, testé tout bout de code ajouté.
Par la suite, et dès que les premières tâches seront effectuées, ma mission consisterait à :
- Faire des recettes complètes de toutes l’application.
- Mis à niveau de Framework ZK.
- Faire les tests d’intrusion avec ZAP.
- Création des procédures stockés.
- Développement des évolutions.
- Création des Batchs.
I.4. Conclusion
Ce chapitre a été conçu pour se familiariser avec l’environnement du travail, l’entreprise

d’accueil et savoir ma mission lors du stage. Dans le chapitre suivant, on étudiera l’ensemble
des définitions nécessaires pour mieux comprendre le projet TMA-CCS.
20
Chapitre II : Le projet TMA CCS
II.1. Introduction
Ce chapitre résume l’ensemble des définitions et des atouts nécessaires à comprendre afin de
mieux suivre et maitriser les parties suivantes, où les différentes taches réalisées sont décrites.
Il fait office d’un descriptif détaillants le jargon employé dans le cadre du projet, ainsi que les
démarches appliquées et les informations nécessaires et indispensables pour assurer la qualité
du travail à fournir.
II.2. TMA (Tierce Maintenance Applicative)

II.2.1. Définition
La TMA (Tierces Maintenances Applicative) fait référence à la délégation à un fournisseur
externe de services liés au cycle de vie d'une application (correction de bugs, maintenance des
offres existantes, ajout de fonctionnalités et mises à niveau, etc.).[13]
L'externalisation de la maintenance des applications offre de nombreux avantages à une
l'entreprise ou client particuliers :
Contrôle des coûts 
Qualité de service garantie 
Accès à des compétences spécialisées
Assurer la continuité des connaissances sur le projet
Pour chaque projet de maintenance, l’équipe TMA s’engage à définir les indicateurs de qualité
de service définis dans le contrat avec le client au début du projet. Ces engagements sont
régulièrement mesurés et présentés par le chef de projet et le directeur de projet dans les comités
de pilotage.
Afin de garantir la meilleure qualité de service et permettre aux différentes entreprises de se
concentrer leurs propres métiers, la TMA a mis en place une organisation rigoureuse et une
série de meilleures pratiques acquises au cours des années de son intégration dans le monde
Professional :
 Fiabilité des ressources existantes

 Traçabilité des actions sur l'application
 Documentation technique et fonctionnelle
 Test fonctionnel et fichier de validation
 Gestion des versions
 Maintien des compétences fonctionnelles et techniques
 Procédure de réintégration en fin de mission (réversibilité)
Le domaine de l’externalisation la maintenance des applications permet de répondre à deux

enjeux majeurs :
21
 Financier
- Réduire les coûts et bénéficier, avec le même budget, d’une augmentation de
périmètre.
 Business
- Optimiser la qualité de services et augmenter la réactivité de développement pour
les Offres Sur Mesure (ou OSM) pour les clients finaux, et de nouveaux comptes
prospectifs.
- Permettre une fluctuation de charges tout en maîtrisant les coûts.
Pour répondre à l’enjeu financier, l’objectif de la TMA est d’apporter :
 De la souplesse et de la fluidité pour dimensionner l’équipe de réalisation.
 Une mutualisation des ressources.
Pour répondre à l’enjeu Business, l’objectif de la TMA est d’apporter :
 Une forte réactivité pour la mise en place de nouvelles fonctionnalités aux
utilisateurs finaux
 Une modularité et une évolutivité de l’architecture pour optimiser la prise en
compte des évolutions
Activités de ML (Maintenance logicielle)

 Corriger des anomalies, optimiser et améliorer les performances, développer de
nouvelles fonctionnalités du produit ou évoluer des fonctionnalités,
 Assurer le bon fonctionnement du logiciel,
 Améliorer la qualité du produit, le processus de développement et la mise à jour
des outils de développement et de l’infrastructure …,
 Apporter un support fonctionnel et technique aux responsables d’applications
ainsi qu’aux équipes d’exploitation du client.
II.2.2. Classification de la ML
Les types de la ML varies à travers deux principales démentions :
*temps
*Objectif
Figure 5 : Type maintenance
22
L’aspect proactif :
Indique une maintenance qui anticipe les attentes, prend l'initiative de l'action :
Une évolution qui ne peut être réalisé qu'une fois parvenu à son terme (Perfectif), une
correction destinée à prévenir, à empêcher une régression de se produire par exemple
(Préventif).
L’aspect réactif :
Indique une maintenance Qui réagit, exerce une intervention vis-à-vis une demande, un besoin
du client :
Une évolution qui prend en charge des nouvelles spécifications (Adaptative), de corrections
des anomalies de fonctionnement remontées par le client (Corrective).
Quelques soit le types d’interventions de la TMA durant le cycle de vie d’un projet, chaque
modification ou améliorations acceptée et développer doit suivre un procès bien précis selon
son type, ceci permet ainsi, de bien cordier entre l’entreprise clients et l’équipe TMA.
Afin de mieux clarifier le besoin et respecter les dates de livraison. Un type de ses procès sera
décrit dans la séquence suivante.
II.2.3. Modèle de méta processus de la maintenance de logiciel
Figure 6 : Modèle de méta processus de la maintenance logiciel
Un procès de maintenance est composé de plusieurs aspects primordiales pour son

fonctionnement, son encadrement et sa mise en production. Généralement, le processus démarre
par une demande d’implémentation, qui déclenche une analyse de besoin, des revues et des
estimations par l’équipe TMA à travées lesquelles le client et l’équipe de maintenance peuvent
soit se mettre d’accords sur les migrations à adopter, et pour que l’implémentation des
modifications nécessaire peut commencer. Soit, estimer le non nécessité du besoin et mettre la
demande en retraite.
II.2.4. Importances et objectifs finaux de la TMA
L'important pour un client c’est qu'il considère la TMA comme une satisfaction de business.
L'objectif premier est de satisfaire les métiers à travers la maintenance. A partir de ce moment-
23
là, le client ne considéra plus la TMA comme une solution des corrections de bug mais un
moyen aussi qui agit sur l'aspect fonctionnel en plus que technique.
Souscrire un contrat de TMA auprès d'un prestataire permet à l'entreprise de :
- Maîtriser les coûts de maintenance.
- Gagner en agilité.
- Avoir à disposition les bonnes ressources et les bonnes compétences.
- Se concentrer sur son cœur de métier.
- Se libérer des contraintes de maintenance informatique.
II.3. Définition CCS

Orange Business Services (OBS) est un fournisseur de services de télécommunications et IT
qui propose à ses clients des solutions adaptées aux réseaux d’entreprises. Ces solutions
s’appuient sur des serveurs, des routeurs, des pares-feux et de nombreux autres équipements
dont l’administration n’est pas facile, généralement parce que l’on est obligé de passer par
l’intermédiaire d’un terminal UNIX et de nombreuses lignes de commandes.
De plus, l’accès à un terminal sur une machine est une solution très risquée en termes de sécurité
: rien n’empêche le client de faire une mauvaise manipulation et de désactiver ou corrompre les
données de son service ou celui d’un autre client. Il ne faut pas surtout oublier que cette petite
porte représentée par un terminal accessible à distance, peut être suffisante pour qu’un pirate
informatique s’introduise dans le système et cause de gros dégâts pour l’entreprise
(désactivation de services, récupération de données industrielles, etc.)
Dans ce cadre, OBS propose à ses clients d’administrer leurs services par l’intermédiaire
d’applications web, nommées Customer Care Service (CCS), qui permettent d’effectuer toutes
les opérations courantes en quelques manipulations. Les données saisies sont analysées avant
d’être traitées et, de cette manière, le risque d’erreur diminue considérablement. La TMA des
CCS dans le domaine TIC.
Ce système permet aussi d’introduire une certaine sécurité en attribuant des droits d’accès aux
administrateurs en fonction des équipements disponibles : un administrateur pourra donc avoir
accès aux ressources qu’il gère et ne connaîtra ni l’existence des ressources des autres clients
ni les ressources de son entreprise qui sont en dehors de son périmètre d’action.
En général, les applications CCS sont livrées aux clients pour leurs permettre la
personnalisation/configuration de leurs offres de service. En addition, ces applications aident
les clients à administrer leurs propres ressources (fournies par OBS) sans la nécessité de
contacter le fournisseur tout le temps pour une configuration ou un changement.
II.4. Les différentes CCS

Le projet TMA CCS comporte en totalité 12 applications, qui sont mis à la disposition des
différents clients d’OBS, ceci, d’après les services dans les quelles sont t’inscrit, 6 d’entre elle
fait partis du périmètre marocain, ces CCS varies en termes d’objectif de création, but
d’utilisation, fonctionnalités, technologies, services ou outils à configurés ….
24
Dans ce sujet, nous nous contentant de citer les CCS couvert par notre périmètre, aussi celles
où, il eut de l’activité durant ma période du stage en raison de manque d’information nécessaire
sur les autres soit ceux qui ne font pas partie du scope, soit ceux où j’pas eu encore l’occasion
pour intervenir.
II.4.1. Référentiel ITS (REFITS)

Description :
Cette application a pour objectif de permettre la gestion d’un ensemble d’objets communs aux
différents CCS. Elle couvre une Gand base de données derrière comportant les données
partagées et utiliser par les différent autres CCS. Cette gestion est effectuée par une Web
application appeler durant les différentes transactions avec le référentiel soit directement à
travers les Web Services (SOAP) et des requêtes IBATIS.
Technologies du projet :
 Java 1.6.1 
 MySQL 5.5 
 Open LDAP 2.4 
 AXIS 1.4
 Apache 2.4
 Tomcat 6
II.4.2. Service Insight (SI)

Description :
Service Insight est un portail de génération des rapports pour les clients d’OBS et pour les
responsables des services clients. Il rassemble les rapports de plusieurs sources de données
sous forme d’indicateurs.
Service Insight permet d’avoir des rapports cohérents, une vue globale du service avec
plusieurs indicateurs (graphiques, données) et des profils utilisateur différents pour un
affichage spécifique pour chaque utilisateur.
Le portail Service Insight est composé de trois parties :
- Une IHM pour les administrateurs OBS accessible en Intranet. Elle permet de gérer les
administrateurs OBS, les clients et les utilisateurs des différents clients.
L’administrateur OBS peut également construire une arborescence contenant les
indicateurs du client.
- Une IHM pour les utilisateurs (Administrateurs clients OBS). Elle permet à l’utilisateur
de visualiser les indicateurs du client auquel il est rattaché et pour lesquels il a les droits
de visualisation. Il peut également construire des panoramas permettant de visualiser
rapidement certains indicateurs.
- Un ensemble de batchs est utilisé pour gérer les tâches d’administrations non
disponibles dans l’IHM d’administration (exemple : définition des indicateurs et de
leurs modes d’affichage).
25
 Java 1.7
 Apache Maven 3
 Spring 3.0.7. RELEASE
 Hibernate 3.4.0.GA
 ZK 7.0.7
 Tomcat 8
 Apache
 API JFreeChart 1.0.13
II.4.3. My Security Desk (MSD)

Description :
Les clients d‘OBS peuvent souscrire à un service d’hébergement de matériel, et de paramétrage
de ce matériel ou de logiciel.
L’application MSD réalise l’interface entre les administrateurs OBS et les administrateurs
clients, ainsi que le suivi et l’historisation des demandes des administrateurs clients.
L’application MSD permet également à OBS d’envoyer des notifications à ses clients sur les
sujets sensibles (par exemple les alertes virales).
 Java 1.6
 Apache Maven 3
 Spring 3.1.2. RELEASE
 Hibernate 3.4.0.GA
 JBPM 3.3.1.GA
 ZK 6.5.5
 Tomcat 6
 Apache
 Perl 5.8
 MySQL 5.5
II.4.4. SMTP Messaging OMSM

Description :
Le rôle du CCS OMSM est de permettre au client de gérer son service de messagerie (Sun Java
System Messaging Server).
Il propose y a deux accès :
- Le premier pour les administrateurs qui permettent de gérer les utilisateurs, groupes,
agendas et visualiser des statistiques issues du serveur de messagerie,
- Le deuxième pour les utilisateurs permet de visualiser le carnet d’adresse de son client
et de gérer son compte.
26
Cette différentiation se fait à l’authentification. C’est le moyen qui permet aux différents clients
d’orange business services de personnaliser les accès aux services messagers pour ses
utilisateurs ceci se fais d’après leurs privilèges aux sains de leurs sociétés respectives.
 Java 1.5
 Perl 5.8.5
 Struts
 Ajax (DWR)
 Webserver sun
 Sun Java System Directory Server Enterprise Edition v6
 JAX-WS
II.5. Plan Assurance Qualité
II.5.1. Définition
Le Plan Assurance Qualité (PAQ) précise les dispositions communes mises en œuvre
conjointement par ORANGE et CGI pour assurer le TPAS TMA CCS sur un périmètre
prédéfini.
Le PAQ permet de :
 Définir des modalités conjointes d’échanges et de travail entre ORANGE et CGI,
 Donner à tous les participants les procédures et standards à appliquer,
 Définir les responsabilités d’ORANGE et de CGI en matière d’organisation,
 Servir de base aux activités des ingénieurs qualité d’ORANGE et de CGI.
ORANGE et CGI, pour les aspects qui ne relèvent pas des échanges respectifs entre eux,
appliquent chacun des dispositions internes qui concourent au respect de ces dispositions
communes.
Ce plan manifeste une organisation, tout un procès à suivre est à respecter durant les différents
échanges entre la parties cliente et la partie prestataire. Ces à travers cette direction est méthodes
que CGI assure la qualité de ses services, ceci se concrétise par un ensemble de démarche,
exigences, procédures et organisme à appliquer.
Dont on peut citez comme premier point majeur, l’activité AMO qui est un facteur essentiel,
une unité simplifiant les transactions entre client et TMA. Un ensemble de gestion.
Lors des différentes phases de la mise en production, que nous allons détaillés dans les parties
qui suivent.
II.5.2. AMO (Assistance à la maitrise d’ouvrage)
L’activité AMOA est une activité très rare au Maroc, ça nous donne la possibilité de gérer des
projets transverses à la place du client. Nous pouvons dire qu’avec cette activité, nous portons
une autre casquette fonctionnelle et nous participons -en plus de la maîtrise d’œuvre- à la
27
maîtrise d’ouvrage. L’objectif est d’assister le client à mieux exprimer et cadrer son besoin et
même proposer des nouveaux projets à sa place.
Voici une vue globale sur l’ensemble d’activités réalisées sous le lot d’AMOA :
 Définition du besoin.
 Rédaction de cahiers des charges.
 Conseil sur les plateformes.
 Support à l’installation, validation du bon fonctionnement.
 Support à la production.
 Formation des utilisateurs, des administrateurs.
 Hébergement.
Ceci était le travail général réalisé par l’équipe du projet. Le périmètre au niveau duquel nous
travaillons repose sur les trois activités mentionnées précédemment.
La liste suivante décrit brièvement les activités que nous assurons sur l’ensemble du périmètre
du projet :
 Montée en compétence fonctionnelle et technique sur l’ensemble des
applications du périmètre Maroc.
 Réalisation des tests et recettes en respectant les spécifications fournies.
 Correction et développement en respectant les délais et les différentes normes
qualité.
 Contribution à l’autonomie et la dynamique de l’équipe.
 Soutient technique de l’équipe.
 Enrichissement de la base de connaissance fonctionnelle et technique au profit
de l’équipe du projet.
Les objectifs du projet partagés avec ORANGE sont les suivants :
 Réduire les coûts ; 
 Maintenir la qualité de service ;
 Respecter les délais imposés ;
Mettre en place un cycle d’amélioration pour garantir un niveau de qualité et de performance

en continuelle progression.
Les facteurs de succès partagés avec ORANGE sont les suivants :
 Qualité de service, productivité, respect des délais favorisant une bonne
satisfaction du client.
 Souplesse, réactivité et efficacité dans le traitement des demandes urgentes ;
 Réduction des coûts.
28
II.5.3. Les gestions de qualité
II.5.3.1 La gestion des exigences
La gestion des exigences se résume en 3 points principaux qui sont :

 La gestion de la cohérence entre les exigences et les produits de sortie du projet.
 Le fait que les exigences soient bien comprises par les parties prenantes et que
celles-ci s’engagent à les satisfaire.
 La gestion des modifications apportées aux exigences en cours de projet.
Les exigences utilisateurs se traduisent en spécifications fonctionnelles générales (SFG). Ces

dernières permettent une vision générale des fonctionnalités à mettre en place. Une fois que les
exigences du client sont établies, celles-ci sont traduites en spécifications fonctionnelles
détaillées (SFD), qui ont pour rôle de détailler en profondeur l’ensemble des exigences.
Les exigences sont gérées par :
 Des discussions avec le client par téléphone ou Mail / réunion de lancement.

 Les critères d’acceptation.
 L’estimation, l’analyse d’impact (Chiffrage et Devis).
II.5.3.2 La gestion des incidents
 Définition :
Tout évènement n'appartenant pas aux opérations normales et pouvant engendrer une
interruption de service ou une diminution de sa qualité.
 Émission :
Reçu via un rapport d'anomalie indiquant qu’un composant ou une fonctionnalité ne répond pas
aux exigences définies.
Le rapport d‘incident doit contenir :
 Le nom et la version du composant (logiciel ou documentaire) concerné,
 Le scénario de reproduction,
 Le nom et les coordonnées de la personne signalant l’incident,
 Les détails concernant des corrections éventuellement souhaitées,
 Les autres composants potentiellement impactés par l’incident,
 Toutes autres informations utiles pour l’analyse de l’incident (Logs, jeux)
 Origines d’incidents :
CGI s’engage à proposer tout l’aide à disposition.
29
L’anomalie est gérée en conformité avec les niveaux de service validés lié au domaine de
responsabilité d’ORANGE.
La gestion des incidents cherche à rétablir au plus vite le service, donc il peut intervenir en deux
temps :
- Un premier permettant la mise en place d’un contournement acceptable.
- Le deuxième permettant la mise en place de la solution définitive.
Dans certains cas, la résolution d’un incident peut conduire à la gestion d’une évolution.
II.5.4. La conception et les spécifications techniques
Une fois les spécifications fonctionnelles validées, elles sont traduites en spécifications
techniques détaillées (STD). Les spécifications techniques décrivent de manière très détaillée
l’ensemble des traitements à effectuer.
Dans les spécifications techniques, on retrouve les détails des modifications à apporter à un
programme (la ligne à laquelle il faut modifier le code, les nouvelles structures appelées dans
le programme, les nouvelles variables, etc…).
Les spécifications techniques détaillées doivent être validées avant de passer à la modification
effective du programme ou à la création du nouveau programme.
II.5.4.1 Les tests unitaires

En se basant sur la STD, les tests unitaires sont élaborés avant le début du développement. Une
fois que les développements commencent, ils peuvent être mis à jour. Cela permet une maitrise
des phases du développement, ainsi qu’une facilité de déroulement des test-cases à la fin de
l’écriture du code.
Les développeurs utilisent les Test cases ou la fiche des tests unitaires (FTU), en général c’est
un fichier Excel, pour tracer et effectuer les tests unitaires, ainsi que le résultat des test-cases
réalisés.
II.5.4.2 Le développement
Les entrants et les moyens nécessaires pour la réussite de la phase développement sont :
 Le planning détaillé.
 Les spécifications techniques (STD).
 Les normes de codage.
 Vérification/ Validation : la version validée de la STD.
30
 Analyse d’impact (Devis).
Les développements doivent être réalisés en prenant en considération :

 La réutilisation du code (cette décision doit être basée sur la phase analyse).
 Les standards et normes de codage.
Une fois les développements terminés, une revue du code est faire. Ce processus se base sur les
spécifications techniques et les normes de codage. Il a pour objectif de corriger le code.
II.5.4.3 Les anomalies en test

Lorsqu’une anomalie est détectée, le Project Manager assigne l’anomalie à un développeur. Ce
dernier vérifie la pertinence des cas de test et trace les anomalies détectées. Il analyse ensuite
l’anomalie et modifie par conséquent le développement.
La mise à jour du développement nécessite la revue des Test unitaires et implique des futurs
tests, afin de s’assurer que le code modifié n’a pas impacté une partie déjà existante, ou une
modification déjà fonctionnelle. Si le résultat des tests est OK on doit mettre à jour le statut en
« ok » dans le test-cases.
II.5.4.4 Les tests d’intégration
Les entrants des tests d’intégration sont :

 Les résultats des tests unitaires (Test cases).
 Les spécifications fonctionnelles (SFD).
 Les spécifications techniques (STD).
 Le plan du test détaillant la séquence d’intégration (Test Cases).
L’analyste utilise le Test-cases pour mettre en place les tests d’intégration. Ces tests sont
vérifiés en se référant aux SFD et STD.
II.5.4.5 La livraison
Après la phase des tests d’intégration, il faut livrer le projet réalisé. Mais les tests continuent
toujours au niveau du client : ce sont les tests client. Ainsi, le client peut détecter une anomalie
au niveau du programme, si celui-ci ne prend pas en compte un ou plusieurs points des
spécifications.
31
II.5.5. Les outils utilisés
II.5.5.1 Mantis Bug Tracker
Figure 7 : Logo Mantis BT
L’outil utiliser par l’équipe TMA afin de faire le suivie des différents demandes clients, à savoir
la correction des bugs, le suivies des évolutions, le traitement des taches ordonnées.
Mantis est un système de suivi d'anomalies logicielles basé sur une interface web. Il est écrit en
PHP et requiert une base de données (MySQL, SQL Server, PostgreSQL et DB2) supportée et
un serveur web. Mantis peut être utilisé sur Microsoft Windows, Mac OS, OS/2 et sur de
nombreux OS du type Unix.
Le principe de cet outil consiste à enregistrer la déclaration d'un bug informatique, puis pour
les techniciens de maintenance informatique concernés, à mettre à jour l'avancement de sa
résolution, jusqu'à sa clôture.
Le déclarant de l'anomalie peut s'informer à tout moment sur l'avancement du traitement de son
problème, ceci se fait via le serveur Web.
Ceci se fait à travers l’implémentation d’un workflow décrivant les différentes étapes par
lesquelles pas une demande peut passer en identifiant les différents états, pouvant être atténuer
puis l’état actuel.
Un Workflow et la progression des étapes (tâches, événements, interactions) qui constituent un
processus de travail, impliquent deux personnes ou plus, et créent ou ajoutent de la valeur aux
activités de l'organisation.
Dans un flux de travail séquentiel : chaque étape dépend de l'occurrence de l'étape précédente.
Dans un flux de travail parallèle : deux étapes ou plus peuvent être exécutées simultanément.
32
Figure 8 : Flux de travail pour Mantis BT
II.5.5.2 GIT
Figure 9 : Logo GIT
Le leader mondial des logiciels de gestion des versions (Versioning) distribués, ces logiciels
sont utilisés principalement par les développeurs. En effet, ils sont exclusivement utilisés pour
gérer des codes sources, car ils sont capables de suivre l’évolution d’un fichier texte ligne par
ligne en présentant un outil traquant tous les changements.
GIT est fortement conseillés pour gérer un projet informatique d’une grande envergure. Car il
permet de suivre l’évolution des fichiers source et gardent les anciennes versions de chacun
d’eux. Son opérabilité ne s’arrête pas qu’à cela, Sion il va s’agir que d’un simple outil de backup
(sauvegarde). Cependant, il propose de nombreuses fonctionnalités qui s'avèrent très utiles tout
au long de l’évolution d’un projet informatique :
- Il garde qui a effectué chaque modification de chaque fichier et pourquoi. Il est
par conséquent capables de dire qui a écrit chaque ligne de code de chaque
fichier et dans quel but.
- Il est capable d’assembler (de fusionner) leurs modifications et d’éviter que le
travail d’une de ces personnes ne soit écrasé.
GIT a donc et par conséquent deux utilités principales :

- Suivre l’évolution d’un code source, pour retenir les modifications effectuées sur
chaque fichier et être ainsi capable de revenir en arrière en cas de problème.
33
- Travailler à plusieurs, sans risquer de se marcher sur les pieds. Si deux personnes
modifient un même fichier en même temps, leurs modifications doivent pouvoir être
fusionnées sans perte d’information.
II.5.5.3 JENKINS
Jenkins est un serveur d'intégration continue open source, capable d'orchestrer une chaîne
d'actions permettant de mener à bien le processus d'intégration continue de manière
automatisée. Jenkins est entièrement écrit en Java, est une application largement utilisée dans
le monde. [10]
Il s’agit d’une application serveur qui nécessite un serveur Web tel qu’Apache Tomcat. La
raison pour laquelle Jenkins est devenue populaire est son suivi des tâches répétitives au cours
du développement d’un projet. Par exemple, au cours de développement ou de l’évolution d’une
application, Jenkins testera en permanence ses constructions de votre projet et vous montrera
les erreurs aux premières étapes de votre développement.
En utilisant Jenkins, les éditeurs de logiciels peuvent accélérer leur processus de
développement, car Jenkins peut automatiser la création et les tests à un rythme rapide. Jenkins
prend en charge le cycle de vie complet du développement d'un logiciel, qu'il s'agisse de la
construction, du test, de la documentation, du déploiement ou d'autres étapes du cycle de
développement d'un logiciel.
Dans l'intégration continue après la validation du code, le logiciel est construit et testé
immédiatement. Dans un grand projet avec de nombreux développeurs, les commits sont
effectués plusieurs fois par jour. Avec chaque code de validation est construit et testé. Si le test
est réussi, la construction est testée pour le déploiement. Si le déploiement aboutit, le code est
poussé en production. Cette validation, construction, test et déploiement est un processus
continu, d'où le nom d'intégration / déploiement continu.
Figure 10 : Interface JENKINS
34
II.6. Conclusion
Ce chapitre, a pu fournir les définitions des termes du jargon utilisés dans le cadre du projet
TMA CCS, dont la définition de la TMA, CCS. Initialisées les structures des CCS qu’on va
entamés dans le prochain chapitre, ainsi que décrire le procès de qualité sur lequel les différents
échanges entre le client et l’équipe s’effectueront.
35
Chapitre III : Analyse fonctionnelle et technique du projet
TMA-CCS
III.1. Introduction
Par le contrat TMA CCS, ORANGE confie à CGI les activités de service en matière
d’assistance technique, de suivi de production, de conception, de développement et de
maintenance des logiciels en maîtrise d'œuvre. Ce chapitre va mettre l’accent sur les aspects
fonctionnelles et techniques reliés aux projets, décrire plus en détails les architectures sur les
quelles sont basées les différentes applications ainsi que les technologies avec lesquelles sont
développées.
III.2. La méthodologie de pilotage
Le projet TMA CCS se déroule sous le cadre de la méthode d’organisation du cycle en V qui
est une méthode très connue dont l’origine remonte à l’industrie et qui a été adaptée à
l’informatique dans les années 80. C’est l’une des premières méthodes qu’on apprend à l’école
après le cycle en cascade, et elle reste toujours d’actualité. [4]
La grande force du cycle en V, c’est qu’il définit assez précisément la manière dont les choses
devraient se passer. Voici un schéma déceptif des déférentes étapes formant l’architecture de
cette dernière :
Figure 11 : Méthodologie cycle en V
On peut y distinguer 3 grandes parties :

La phase de conception, la phase de réalisation (codage) et la phase de validation.
 Les phases de conception

Les phases de conception et de validation se découpent en plusieurs parties. Chaque étape ne
36
peut être réalisée qu’une fois que l’étape précédente est terminée, ce qui diminue les prises de
risque sur le projet.
Ce qui est bien visible sur le diagramme, c’est que chaque étape de conception possède son
alter ego de validation. Il devient alors assez aisé de valider un projet, car le référentiel de test
est connu très précisément.
Les différentes étapes :
Le cycle en V est constitué de 8 étapes qui ont toutes leur importance.
- Expression de besoin : Le client exprime son besoin, en décrivant les usages
correspondant au produit fini tel qu’il peut l’imaginer. Cela doit répondre aux questions
« Que veut-on ? » et « À quel coût ? ».
- Spécifications fonctionnelles : C’est le cahier des charges exact du produit final, tel que
le désire le client. Il doit couvrir l’intégralité des cas d’utilisation du produit, en
expliquant ce qu’il doit faire et non pas comment il va le faire.
- Spécifications techniques : C’est une traduction des spécifications fonctionnelles en
termes techniques. C’est durant l’élaboration des spécifications techniques que sont
choisies les technologies à mettre en œuvre pour développer le produit, et qu’est conçue
l’architecture logicielle du produit.
 La phase de réalisation (codage)

Codage : C’est la phase de réalisation à proprement parler, pendant laquelle sont développées
des briques qui sont ensuite assemblées pour créer le produit fini.
 La phase de validation
Validation : Le produit est à ce moment testé en regard de la spécification fonctionnelle. Toutes
les utilisations qui y ont été définies doivent pouvoir se vérifier dans les faits.
- Tests unitaires : Ces tests interviennent à un niveau « atomique ». Chaque brique
logicielle a été modélisée puis codée durant les étapes précédentes. Les tests unitaires
assurent que ces briques respectent de manière individuelle leur cahier des charges.
- Tests d’intégration : Ce sont là les premiers tests grandeur nature du produit fini. On
s’assure qu’il suit les indications des spécifications techniques.
- Mise en production et recette : Le produit est vérifié une dernière fois en préproduction,
avant d’être mis en production. Le client procède à la recette, pour vérifier que son
expression de besoin est respectée.
La pratique
Malheureusement, si le cycle en V est limpide d’un point de vue théorique, son application
réelle est très difficile. Dans une grande majorité de cas, on voit des organisations qui
ressemblent plutôt à ce schéma :
37
Figure 12 : Méthodologie en cycle V en pratique
La phase de conception se réduit à 2 étapes.

- Les spécifications fonctionnelles, qui représentent l’ensemble des besoins du client
et/ou définissent ce que doit faire le produit fini.
- Les spécifications techniques, qui détaillent comment le produit va être réalisé
techniquement.
La phase de validation contient juste 3 étapes.
- Les tests d’intégration, pendant lesquels on vérifie que l’intégralité du produit est valide
techniquement.
- Les tests de validation, qui sont un mélange de tests techniques et fonctionnels, et sur
lesquels le client se base souvent pour décider du lancement du produit.
- La recette, qui est utilisée pour vérifier que le produit est valide par rapport aux
spécifications fonctionnelles, mais qui a tendance à n’intervenir qu’après la mise en
production (ou bien elle est tronquée en préproduction, ce qui aboutit à mettre des bugs
en production).
Une telle organisation possède encore des avantages structurels assez convaincants, car elle
définit toujours les différentes étapes de la réalisation d’un projet. Mais bien souvent, on se
retrouve en réalité avec une organisation qui ressemble plutôt à quelque chose comme ça.
III.3. My Security Desk (MSD)

III.3.1. Description
Les clients d‘OBS peuvent souscrire à un service d’hébergement de matériel, et de paramétrage
de ce matériel ou de logiciel.
L’application MSD réalise l’interface entre les administrateurs OBS et les administrateurs
clients, ainsi que le suivi et l’historisation des demandes des administrateurs clients.
L’application MSD permet également à OBS d’envoyer des notifications à ses clients sur les
sujets sensibles (par exemple les alertes virales).
38
III.3.2. Architecture
L’application est divisée en couches logicielles :
- La couche d’accès aux données.
- La couche de services métier.
- La couche présentation.
La couche d’accès aux données :

- Gère la persistance (en base de données, sous forme de fichiers xml, web services).
- Offre une couche d’abstraction indépendante de la technologie de la base de données ou
plus généralement de la forme du stockage.
La couche de services métier :

- Expose les services de recherche, de modification des données.
- Gère le paramétrage.
- Gère la logique applicative.
La couche de présentation :
- Contient les composants évolués spécifiques à l’application (formulaires
paramétrables).
- Génère l’affichage.
- Gère les contrôles de surfaces.
III.3.3. Fonctionnalité
Le portail My Security Desk est composé de deux parties :
Batchs :
- Création des feuillets : les feuillets de configuration (.conf, .xml et .html) décrivent la
configuration de chaque équipement.
- Duplication de la base de données. Cette base est utilisée pour l’usurpation des
utilisateurs.
- Génération des grammaires xslt permettant de visualiser les configurations des
équipements dans MSD
- Gérer les différents fichiers mis à disposition des utilisateurs
- Synchroniser les équipements du référentiel avec MSD
- Purger différentes informations de la base de données : anciennes demandes de
changements terminées, anciennes configurations d’équipements, …
- Construire des données à destination de RSCWeb.
IHM :
- Gérer les administrateurs OBS et client et leurs groupes.
- Gérer les clients et leurs groupes.
- Créer et suivre les demandes de changements sur équipements ou services.
- Gérer des formulaires préconstruits sous la forme d’un catalogue.
- Mettre à disposition des fichiers pour les utilisateurs.
39
- Créer et consulter des notifications à destination des utilisateurs.
- Consulter rapidement via une page d’accueil (panorama) la listes des notifications,
clients, demandes de changement et de visualiser les équipements sur une map monde.
- Gérer des demandes d’archivage de configurations.
- Gérer une liste de bookmarks à destination des utilisateurs.
III.4. Diagramme de classe
Figure 13 : Diagramme de classe
40
III.5. Technologies utilisées
III.5.1. Un Framework
Un Framework est un ensemble d’APIs, de bibliothèques, d’outils et de règles à suivre (Design
Patterns), basé sur l’inversion du contrôle qui support le développement d’applications. Les
frameworks sont développés par des programmeurs système.
Un Framework est composé de plusieurs briques/composants qui sont en interaction les uns
avec les autres. Les applications peuvent être écrites de manière plus efficace si nous utilisons
un Framework adapté au projet au lieu d’être obligé de réinventer à chaque fois la roue. Un
Framework Java fournit un ensemble de fonctionnalités à partir d’une implémentation objet.
Lors de développement à grande échelle et au cours de la conception par équipe, les frameworks
sont alors très utiles, voire indispensables.
III.5.1.1 Framework ORM - Hibernate

 Définition ORM
Dans une architecture n-tiers, l’ORM (Object-Relationnel Mapping) intervient au niveau de la
couche d’accès aux données.
Figure 14 : Architecture N-tiers
Le cœur de fonctionnement d’un ORM vise à rendre abstraite la couche d’accès à la base de
données afin de ne manipuler que des objets Java (Beans ou POJO pour Plain Old Java Objects)
dans les couches de service de l’applicatif.
A minima, cette couche d’accès aux données ou DAL (Data Access Layer) doit permettre
d’effectuer les opérations « basiques » de type CRUD (Create Read Update Delete) Les
principes fondamentaux d’un ORM sont :
- De définir la relation entre un objet Java et son pendant en base de données.
(Généralement un bean par table en base de données)
- De fournir une classe d’abstraction gérant les accès à la base de données (Session
Hibernate, session ibatis, …)
41
Dans cette classe d’abstraction, fournir à minima les méthodes pour effectuer les opérations de
type CRUD ainsi qu’une méthode pour exécuter du SQL natif.
Les ORM permettent d’effectuer cette abstraction en stockant la relation entre un objet Java et
une table de la base de données.
Ce mapping entre les objets Java et les tables de la base de données sont gérables de deux
manières :
- Via un fichier de mapping (généralement un fichier XML).
- Via les annotations JPA de Java 5 (Java Persistence API).
 Hibernate
Hibernate est un Framework open source gérant la persistance des objets en base de données
relationnelle. L’objectif principal était d'offrir des meilleures capacités en persistance que celles
proposées par EJB 2.0 en simplifiant ses complexités et complétant les fonctionnalités
manquantes.
Hibernate apporte une solution aux problèmes d'adaptation entre le paradigme objet et les
SGBD en remplaçant les accès à la base de données par des appels à des méthodes objet de haut
niveau.
Le but d'Hibernate est de libérer le développeur de 95 % des tâches de programmation liées à
la persistance des données communes. Hibernate assure la portabilité de votre application si
vous changer de SGBD. Hibernate propose au développeur des méthodes d’accès aux bases de
données plus efficace ce qui devrait rassurer les développeurs. Hibernate permet d’assurer la
persistance des objets de l’application dans un entrepôt de données. Cet entrepôt de données est
dans la majorité des cas une base de données relationnelle, mais il peut être un fichier XML. Le
Mapping des objets est effectué par Hibernate en se basant sur des fichiers de configuration en
format texte ou souvent XML.
 Architecture de Hibernate
Figure 15 : Architecture Hibernate
L’architecture de Hibernate est découpée en couches afin d’isoler les utilisateurs des API qui
le constitue.
42
- Hibernate permet d’assurer la persistance des objets de l’application dans un entrepôt
de données.
- Cet entrepôt de données est dans la majorité des cas une base de données relationnelle,
mais il peut être un fichier XML (XML mapping).
- Le mapping des objets est effectué par Hibernate en se basant sur des fichiers de
configuration en format texte ou souvent XML.
III.5.1.2 Framework SOAP
SOAP (Simple Object Access Protocol) est un protocole de RPC (Remote Procedure Call)
orienté objet bâti sur XML. [6]
Il permet la transmission de messages entre objets distants, ce qui veut dire qu'il autorise un
objet à invoquer des méthodes d'objets physiquement situés sur un autre serveur. Le transfert
se fait le plus souvent à l'aide du protocole HTTP, mais peut également se faire par un autre
protocole, comme SMTP.
Le protocole SOAP est composé de deux parties :
- Une enveloppe, contenant des informations sur le message lui-même afin de permettre
son acheminement et son traitement,
- Un modèle de données, définissant le format du message, c'est-à-dire les informations
à transmettre.
 Service WEB
Un service web (Web Service) comprend les composants suivants :
- Une implémentation du service, contenu sur un serveur.
- Un protocole de communication pour faire transiter les données SOAP sur http(s).
- Une description du service web pour que le client puisse l’invoquer (WSDL).
- Une API pour invoquer le service WEB (AXIS).
WSDL : Il définit de manière abstraite et indépendante du langage, l’ensemble des opérations
et des messages qui peuvent être transmis vers et depuis un service web donné. En ce sens on
peut définir le WSDL comme une sorte de langage de définition d’interface d’objet, au même
titre que ceux utilisés pour d’autres architectures d’applications à composants, telles que
CORBA ou COM.
WSDL permet de définir le message, les réponses aux messages et les types utilisés.
43
Figure 16 : Flux de communication des services web
III.5.1.3 Framework Spring
Spring est un Framework open source qui offre une alternative viable aux EJB, plus simple à
utiliser dans le cadre du développement d’applications professionnelles.
Spring est bien distingué du reste des frameworks de la même technologie par le fait qu’il est
un conteneur d’objets Java ordinaires POJO (Plain Old Java Object). Par ailleurs, Spring fournit
une riche API qui simplifie la programmation de certaines tâches et l’utilisation d’outils open
source répandus.
L’architecture de Spring se base sur plusieurs modules pour chaque aspect technologique
comme suit.
Figure 17 : Architecture modulaire de Spring
Un des autres attraits du conteneur Spring se situe dans l’intégration d’autres frameworks (Axis,
Hibernate, JSF) ainsi que d’autres technologies (JMS, JMX, …).
44
III.5.1.4 Framework ZK
ZK est un Framework Ajax de type server-centric, contrairement à Google Web Toolit) c'est à-
dire que la logique métier est géré intégralement côté serveur.[2]
Là ou Google Web Toolkit va générer des fichiers JavaScripts qui seront exécutés côté client
(navigateur), ZK ne génère pas de fichiers JavaScripts et utilise Ajax pour gérer les appels entre
le client et le serveur.
Figure 18 : Architecture server-centric de ZK
Le Framework ZK possède son propre type de fichier avec l’extension .zul dérivé du xul (XML
User Interface Language).
Un fichier zul comprend un ensemble de balises permettant de définir des boutons, des listes,
des menus, ou encore des zones d’édition, bref tous les éléments d’une véritable interface
utilisateur regroupés sous forme arborescente.
Le développement d’une application ZUL se rapproche du développement d’une application
cliente ou client-serveur traditionnelle. A chaque objet graphique sont associés des événements
(clic de souris, double clic, etc.) pour lesquels le développeur doit écrire du code.
 ZK et le design pattern MVC

Afin de contrôler les composant de l'interface utilisateur. L’approche utilisée par ZK peut être
classée dans le modèle de conception Modèle-Vue-Contrôleur (MVC). Ce modèle divise une
application en trois parties.
Figure 19 : Design pattern MVC
45
- Le modèle comprend des données d'application et des règles métier.
- La vue signifie l'interface utilisateur. La page ZUL qui contient les composants ZK
représente cette partie. L'interaction d'un utilisateur avec des composants déclenche
l'envoi d'événements aux contrôleurs.
- Le contrôleur joue le rôle de coordinateur entre View et Model. Il reçoit des
événements de la vue pour mettre à jour le modèle
III.5.2. Langages
 HTML
L’Hypertext Markup Language, est le format de données conçu pour représenter les pages web.
C’est un langage de balisage qui permet d’écrire de l’hypertexte. Il permet de créer des
documents interopérables avec des équipements très variés de manière conforme aux exigences
de l’accessibilité du web.
Il est souvent utilisé conjointement avec le langage de programmation JavaScript et des feuilles
de style en cascade (CSS).
 CSS
CSS (Cascading Style Sheets), forment un langage informatique qui décrit la présentation des
documents HTML et XML. Les standards définissant CSS sont publiés par le World Wide Web
Consortium (W3C). CSS est utilisé depuis les débuts des applications CCS. La feuille CSS est
la transcription de la charte graphique d'Orange.
 LESS
LESS est un langage de feuille de style dynamique qui peut être compilé en feuilles de style en
cascade (CSS) et s'exécuter côté client ou côté serveur. LESS est open source. La syntaxe
indentée de LESS est un métalangage imbriqué. LESS fournit les mécanismes suivants :
variables, imbrication, mixins, opérateurs et fonctions. La principale différence entre les pré
compilateurs CSS LESS et d'autres étant que LESS permet une compilation en temps réel par
le navigateur via less.js.
 Javascript
JavaScript est un langage de programmation de scripts principalement utilisé dans les pages
web interactives mais aussi côté serveur.
C'est un langage orienté objet à prototype, c'est-à-dire que les bases du langage et ses principales
interfaces sont fournies par des objets qui ne sont pas des instances de classes, mais qui sont
chacun équipés de constructeurs permettant de créer leurs propriétés, et notamment une
propriété de prototypage qui permet d'en créer des objets héritiers personnalisés. En outre, les
fonctions sont des objets de première classe.
 SQL
SQL (Structured Query Language) est un langage informatique normalisé servant à exploiter
des bases de données relationnelles. La partie langage de manipulation des données de SQL
46
permet de rechercher, d'ajouter, de modifier ou de supprimer des données dans les bases de
données relationnelles.
Outre le langage de manipulation des données, la partie langage de définition des données
permet de créer et de modifier la structure des données dans la base de données, la partie langage
de contrôle de transaction permet de commencer et de terminer des transactions, et la partie
langage de contrôle des données permet d'autoriser ou d'interdire l'accès à certaines données à
certaines personnes.
 Workflow Engine – jBPM

jBPM (Java Business Process Model) est un moteur de workflow. Il permet la gestion de flux
d'informations ainsi que la coordination entre biens et personnes. jBPM est un logiciel libre
développé par JBoss. Il est écrit en Java.
En plus du moteur de workflow, jBPM fournit des applications de développement simple. Elles
permettent de poser graphiquement les différentes étapes qui composent le processus.
III.5.3. Serveurs
 Apache HTTP Server
Apache HTTP Server, souvent appelé Apache, est un logiciel de serveur http produit par
l'Apache Software Foundation. C'est le serveur http le plus populaire du Web. Apache est utilisé
par certains applications CCS pour transmettre à l'utilisateur le contenu statique (images, pages
HTML, feuille de style CSS).
 Apache Tomcat
Apache Tomcat est un conteneur libre de servlet JEE. Issu du projet Jakarta, Tomcat est
désormais un projet principal de la fondation Apache. Tomcat implémente les spécifications
des servlets et des JSP de Sun Microsystems. Il inclut des outils pour la configuration et la
gestion, mais peut également être configuré en éditant des fichiers de configuration XML.
Comme Tomcat inclut un serveur HTTP interne, il est aussi considéré comme un serveur HTTP.
III.5.4. Logiciels
 Eclipse
Eclipse est un projet de la Fondation Eclipse visant à développer tout un environnement de
développement libre, extensible, universel et polyvalent.
Son objectif est de produire et fournir divers outils gravitant autour de la réalisation de logiciel,
englobant les activités de codage logiciel proprement dites mais aussi de modélisation, de
conception, de test, de reporting, etc.
Son environnement de développement notamment vise à la généricité pour lui permettre de
supporter n'importe quel langage de programmation.
 MySQL Workbench
MySQL Workbench est un outil visuel unifié pour architectes, développeurs et administrateurs
de base de données. MySQL Workbench fournit la modélisation des données, le développement
47
SQL et des outils d'administration complets pour la configuration des serveurs, l'administration
des utilisateurs et davantage.
 WinSCP
Puisque nous déployons nos applications sur des serveurs distants, nous avions besoin d’utiliser
un outil d’accès à distance.
WinSCP est un client SFTP graphique pour Windows. Il utilise SSH et est open source. Le
protocole SCP est également supporté. Le but de ce programme est de permettre la copie
sécurisée de fichiers entre nos ordinateurs locaux et les serveurs distants.
III.6. Conclusion
Cette partie nous a permis d’apprendre encore plus des différents aspects fonctionnels est
techniques, notamment les parties et les techniques qui vont être les acteurs principaux durant
le chapitre de la réalisation. Ceci nous a préparés d’une certaine manière à savoir et comprendre
comment la partie de développement va être entamée et surtout sur quel niveau va-t-elle agir.
48
Chapitre IV : Les tâches réalisées
IV.1. Introduction
Après avoir terminé avec l’étude fonctionnelle et techniques du projet TMA CCS, plus
précisément les CCS sur lesquelles j’ai eu l’occasion d’intervenir, ce chapitre va mettre
l’emphase sur la partie de réalisation, souligner les différentes interventions que j’ai dû effectuer
durant toute ma période de stage d’un côté purement technique.
IV.2. Recette MSD

Avant chaque livraison il faut faire une recette complète de l’application et pour savoir les
différentes fonctionnalités de MSD ils ont me donnée comme première tâche de faire une recette
complète.
C’est le fait de vérifier ou de contrôler le respect de spécifications technique et fonctionnelle.
Et s’il y a des anomalies on va les affectés à l’équipe pour les corrigés.
Et pour bien gérer notre travail on a utilisé l’outil Mantis sur le lequel on a déjà parlé dans la
deuxième partie.
Figure 20 : Exemple interface Mantis BT
Le principe de cet outil consiste à enregistrer la déclaration d'un bug informatique, puis, pour
les développeurs concernés, à mettre à jour l'avancement de sa résolution, jusqu'à sa clôture. Le
déclarant de l'anomalie peut s'informer à tout moment via le serveur Web de l'avancement du
traitement de son problème.
49
IV.3. Mettre à niveau le Framework ZK
ZK est un Framework d'interface utilisateur qui vous permet de créer des applications Web et
mobiles étonnantes sans avoir à apprendre JavaScript ou AJAX.
Cette tâche consiste à mettre à niveau le Framework ZK en passant de la version 6.5.5 [7] a une
version plus récente 9.5.0. [8]
IV.3.1. La différence entre les deux versions

ZK 9.5 est une mise à jour majeure axée sur l'amélioration des expériences des développeurs.
Des fonctionnalités offrant une mise à niveau plus fluide, une utilisation MVVM simplifiée,
une personnalisation plus facile du thème et des composants sont ajoutées à cette version.
Parmi les nouvelles fonctionnalités de cette nouvelle version :
- Prendre en charge un moyen de créer un thème personnalisé basé sur des thèmes
intégrés.
- Permet de faire glisser le bouton lorsque MouseDown sur n'importe quelle position dans
Rangeslider / Multislider.
- Soutenir une création de Bean à partir de @BindingParams.
- Radio / Checkbox fournit un nom de classe d'état pour une personnalisation plus facile
du thème.
- Supports audios pour ajouter des pistes.
- Prise en charge vidéo pour ajouter des pistes.
- Supprimer la bordure de l'en-tête div dans List / Tree box / grid.
- L'API des clients prend en charge scrollIntoView et focus à l'aide de la chaîne de
sélection.
- Remplacer les fonctions jQuery obsolètes (bind / unbind -> on / off).
- Implémenter un utilitaire d'interruption de clavier pour les composants en modal.
Parmi les bugs fixés :
- Impossible d'utiliser un tableau de classe comme liste ou modèle de grille.
- Erreur de calcul de la hauteur lors de l'utilisation de vFlex = "min" dans hlayout et
borderlayout.
- L'état sale de ListProxy n'a pas été nettoyé après l'enregistrement.
- Analyse des pourcentages négatifs dans decimalbox.
- jQuery surchargé provoque un mauvais fonctionnement des composants des faces
principales.
- Chosenbox efface et ajoute les éléments sélectionnés provoque une erreur js.
- Masquer redimensionner afficher l'en-tête de la liste reste invisible.
- La zone de recherche initialement désactivée a un style incorrect.
IV.3.2. Réalisation
Avant de commencer la correction des dysfonctionnements on a fait un tour sur les différentes
interfaces de l’application et on a lister tous les dysfonctionnements dans un fichier Excel.
50
 Le problème hflex / vflex
Hflex contrôle la flexibilité dans la direction horizontale, tandis que vflex dans la direction
verticale.
Les composants flexibles grandissent et rétrécissent pour s'adapter à leur espace donné. Les
composants avec des valeurs de flex plus élevées seront rendus plus grands que les composants
avec des valeurs de flex plus faibles, au rapport déterminé par les deux composants.
Figure 21 : Pop-up d’erreur
Pour corriger ce genre d’erreur on a fait un tour sur l’ensemble des fichiers .zul de l’application
et on modifie leurs attributs :
- Si on a hflex et width il faut garder un soi hflex soi width.

- Si on a vflex et height il faut garder un soi vflex soi height.
Figure 22 : Exemple hflex / vflex
Comme vous voyez dans cette capture au niveau de la balise window on a gardé le width et
height et au niveau de la balise hbox on a gardé vflex.
51
 Quelques interfaces avant et après la modification
 Page Login
L'écran de connexion permet à l'utilisateur de remplir son identifiant et son mot de passe pour
se connecter à MSD.
La capture ci-dessous nous montre la page authentification avant la correction de
dysfonctionnement.
Figure 23 : Page Authentification avant la modification
Après la redéfinition de style dans le fichier. less le dysfonctionnement est fixé.
Figure 24 : Page Authentification après la modification
52
 Page Gérer Panorama
Le menu Panorama représente la page d’accueil. Il permet de visualiser certains widgets comme
la carte des sites, la liste des changements et aussi la liste des notifications. Les widgets sont
paramétrables (statut, type de notification …).
Figure 25 : Gérer panorama avant la modification
Apres la correction de l’ensemble de dysfonctionnement la page panorama devient :
Figure 26 : Page gérer panorama après la modification
Pour ajouter widget, vous cliquez sur le bouton « Ajouter » en haut à droite dans l'onglet «
Panorama »
53
Figure 27 : Fenêtre ajouter widget avant la modification
Après avoir appliqué les modifications nécessaires tous les dysfonctionnements sont corrigé.
Figure 28 : Fenêtre ajouter widget après la modification
 Page gérer Administrateurs

Le menu Administrateur permet aux clients de gérer leurs propres équipes (création de compte
pour le portail MSD, suppression, réactivation de compte, suivi des compteurs). Les comptes
administrateurs créés peuvent être de 3 types :
- Advanced = gestion des administrateurs clients (c’est-à-dire vous pouvez créer modifier
et supprimer un administrateur si vous êtes un administrateur avancé) + demande de
changement,
- Standard = demande de changement
- Read Only = lecture seule
54
Après la correction des dysfonctionnement la page devient :
Figure 29 : Page gérer administrateurs après la modification
Pour accéder à la fenêtre de création d'un nouvel administrateur, cliquez sur le bouton Créer un
administrateur.
Cet écran permet de créer un nouvel administrateur.
Il est composé de quatre onglets :
- Le premier onglet « principal » permet de créer un nouvel administrateur.

- Le deuxième onglet « client » permet de lier cet administrateur à un client.
- Le troisième onglet "administrateur de groupe" est utilisé pour lier l'administrateur aux
groupes de l'administrateur.
- Le quatrième onglet « Droits d'accès » permet de définir les droits d'accès.
- Et le cinquième onglet « Permissions » permet de définir les permissions sur la structure
client.
55
Figure 30 : Fenêtre ajouter administrateurs avant la modification
L'utilisateur connecté peut accéder à ce pop-up en cliquant sur le bouton « créer un

administrateur » présent en haut à droite de la liste des administrateurs.
Après la correction des dysfonctionnement l’affichage devient :
Figure 31 : Fenêtre ajouter administrateur après la modification
 Page configurations et demandes

Le menu Configurations et demandes permet de visualiser les configurations associées à vos
boitiers (paramètres, versions ...) et de demander des changements sur ceux-ci via des
formulaires prédéfinis à différents niveaux de la structure du client.
56
Figure 32 : Menu configurations et demandes avant la modification
Après la modification de style la fenêtre devient :
Figure 33 : Menu configurations et demandes après la modification
 Page suivi des changements

Le menu Suivi des changements permet de voir et suivre le statut des changements.
57
Figure 34 : Menu suivi des changements avant la modification
Après la correction des hflex / vflex et l’application de style nécessaire on a obtenu le résultat
suivant.
Figure 35 : Menu suivi des changements après la modification
Notez bien que je me suis contenté de présenter quelques captures d'écrans puisque la correction
mise en place couvre la totalité de l’application.
Après la finalisation des dysfonctionnements on a passé à faire les tests d’intrusion.
IV.4. Les tests d’intrusion avec ZAP

Pour les tests du chantier ZK, sont fait en utilisant l’outil ZAP proxy.
Un test d’intrusion, également connu sous le nom test de pénétration, est une cyber-attaque
simulée contre votre système informatique pour rechercher des vulnérabilités exploitables.[9]
58
Dans le contexte de la sécurité des applications Web, les tests de pénétration sont couramment
utilisés pour augmenter un pare-feu d'application Web.
ZAP (Zed Attack Proxy) c'est un outil qui détecte les tests d’intrusion.[11]
 Installation de ZAP
1. Téléchargement de ZAP via google.
2. Lancement de l’installation.
3. Démarrer ZAP Aller dans Outils > Options Sélectionner « Local Proxies » et configurer
l’adresse (localhost) et choisir un port (bien le noter).
Figure 36 : Installation ZAP
4. Dans le navigateur de votre choix (Firefox ou Chromium) récupérer une extension qui
permet de configurer plusieurs proxy (par exemple switchyOmega sur Chromium ou
FoxyProxy Standard).
Plusieurs façons de le configurer :
Ajouter nécessairement une entrée « ZAP » pour passer par le proxy ZAP :
Figure 37 : Ajout de l’entrée ZAP
59
5. Activer manuellement le proxy ZAP quand nécessaire
Figure 38 : Activation de ZAP
Durant toute la période de test :
- On démarre ZAP le matin.

- On ouvre la dernière session enregistrée.
- On active le proxy ZAP dans le navigateur.
- En fin d’après-midi et avant de fermer ZAP on fait un instantané de session.
Figure 39 : Interface de l’outil ZAP
Vers la fin des tests du chantier ZK, chacun va générer un rapport ZAP sous forme d’HTML,
qui sera communiqué au client via la livraison.
60
IV.5. Création des procédures stockées
IV.5.1. Définition
- La procédure stockée est un groupe logique d'instructions SQL et PL / SQL qui
exécutent une action spécifique.[12]
- Stocké dans la base de données en tant qu'objets de base de données.
- Sont compilés uniquement au moment de leur création ou modification.
- Accepter les paramètres d'entrée et les valeurs de retour.
- Retourne la valeur de statut pour indiquer la réussite ou l'échec.
IV.5.2. Avantages
- Améliorez les performances de la base de données : Réduire les informations envoyées
sur le réseau.[15]
- Allocation de mémoire : Une seule copie de la procédure stockée est chargée en
mémoire pour être exécutée par plusieurs utilisateurs.
- Productivité : Le code redondant peut être évité.
- Intégrité : Un ensemble commun de procédures réduit les erreurs de codage commises.
IV.5.3. Problématiques
La suppression des données au niveau de l’IHM se fait physiquement par contre les données
reste dans la base donnée c’est pour ça on a créé des procédures stockées pour supprimer les
données logiquement.
IV.5.4. Solutions
Pour nettoyer les données on a pensé à créer des procédures stockées pour supprimer les
données logiquement on prend l’exemple des clients.
Pour qu’on puisse supprimer un client il faut supprimer ses données.
Figure 40 : PS qui supprime data lier au client
61
Cette procédure fait la suppression des données lié au client après on va supprimer la structure
liée à ses données.
Figure 41 : PS qui supprime structure de data lier au client
Après la suppression des données et la structure on passe à la suppression de leur tree.
Figure 42 : PS qui supprime Tree lié au client
Cette procédure prend en paramètre id de client comme entré et on a fait appel aux deux
procédures précédentes pour que la suppression fait sans problème on a utilisé cette technique
car dans la base donnée il y a l’option de référence No action.
62
Figure 43 : PS supprimer client
IV.6. RFC calcul des permissions

IV.6.1. Request for Change (RFC) ?
La demande de changement (RFC) est une demande formelle pour la mise en œuvre d'un
changement.[16]
La RFC contient toutes les informations nécessaires pour approuver un changement. Des
informations supplémentaires sont ajoutées au fur et à mesure que le changement progresse
dans son cycle de vie.
Apres la réception d’une RFC on fait l’impact et chiffrage et il va être validé de leurs parts
avant de commencer le développement.
IV.6.1. Problématique
Actuellement, après la modification de la structure d’un client, le recalcule des permissions de
tous les administrateurs liés à ce dernier se lance en arrière-plan. En revanche, si le calcul des
permissions de l’administrateur avec lequel on est connecté n’a pas terminé, l’administrateur
n’a plus les droits sur le client modifié. Il ne s’affiche plus dans les panels clients existant dans
l’application.
Figure 44 : Modification de la structure d’un client
63
IV.6.2. Solution
Autorisé l’affichage des clients sur le panneau clients lors du calcul des permissions avec :
 Un arrière-plan grisé non sélectionnable.
 Un icône « help » à droite. Au survol de ce dernier on affiche le message suivant :
Vos permissions sur ce client sont en cours de calcul. Vous ne pouvez pas travailler
dessus pour l'instant. Merci de patienter avant de pouvoir y avoir de nouveau accès".
 Un rafraichissement du panneau lors du clique sur l’onglet qui contient ce dernier.

 Afficher un pop-up d'erreur lors de la modification des informations, ou la
modification de l’arborescence pour le client en cours de calcul des permissions,
avec le message d’erreur suivant : Vos permissions sur ce client sont en cours de
calcul. Vous ne pouvez pas travailler dessus pour l'instant. Merci de patienter avant
de pouvoir y avoir de nouveau accès.
Pour cela on va ajouter une colonne dans la base de données pour qu’on puisse faire le test avec.
Figure 45 : Requête d’Ajout de la colonne
Apres on va Ajouter une méthode qui permet de récupérer les droits liés à un user donner en
paramètre.
Figure 46 : Méthode de récupération des droits
Ajout d’une méthode qui permet de faire la modification coté BD de la colonne allowed à
« false ».
Figure 47 : Méthode de modification de allowed
64
Modifier l’implémentation de la méthode dessous afin de modifier la valeur du nouvel attribut
allowed à « false » pour les clients qui ont le calcul des permissions en cours.
Figure 48 : Appel de la méthode modification de allowed
Changement de style (arrière-plan grisé non sélectionnable...) de l’affichage des clients dont les
permissions sont en cours de calcul sur le panneau clients.
Figure 49 : Modification de style
Rafraichissement du panneau clients sur les deux onglets contenant ce dernier.
Figure 50 : Rafraichissement du panneau
Affichage du pop-up d'erreur après la recherche et la sélection d’un client pour lequel les
permissions sont en cours de recalcule.
Figure 51 : Affichage du pop-up
65
IV.6.3. Résultat
L’affichage des clients lors de recalcule des permissions sera :
Figure 52 : Panneau clients lors de recalcule des permissions
Le pop-up d'erreur affiché lors de la modification des informations, ou la modification de

l’arborescence pour le client en cours de calcul des permissions.
Figure 53 : Affichage du pop-up
IV.7. Batch synchronisation des changes

IV.7.1. C’est quoi un batch ?
Batch désigne en informatique l'automatisation d'une suite de commandes exécutées en série
sur un ordinateur sans qu'il soit nécessaire qu'un opérateur intervienne pour réaliser cette
66
opération. On le traduit la plupart du temps par le terme "lot" en français et par l'expression
"traitement par lots".[14]
On utilise le batch pour automatiser certaines tâches comme la gestion des comptes, ou l'arrêt
planifié des ordinateurs, en particulier dans le monde des entreprises qui possèdent un parc
informatique important. La technique du traitement par lots s'oppose alors aux programmes
interactifs ou transactionnels. On peut employer le terme pour le différencier d'un traitement en
temps réel.
IV.7.2. Problématique
Un grand nombre de vieux changes restent dans des états non-clos. Ça pollue l'affichage et ça
peut générer des problèmes de charges. Il faudrait donc pouvoir clôturer des vieux changes.
IV.7.3. Solution
Actuellement la suppression des changes se fait à l’aide d’un script de purge de data, les critères
valables pour lancer un purge est le délai (Nombre de jours avant la suppression physique des
données).
La nouvelle demande vise à améliorer les critères de sélection des changes à supprimer, en
ajoutant les deux critères délai et état. Pour cela on créer les classes suivantes :
SynchroChangeLauncher, SynchroChangeContext, SynchroChangeTask,
SynchroChangeProcess et CloseOlderChangesTask pour :
- Gérer les nouveaux critères (Date de dernière modification et état).

- Mise à jour de last_actor pour rendre sa valeur a system.
- Ajout d’un nouveau paramètre qui contiendra un message customisé ce message sera la
nouvelle valeur du champ commentaire interne.
Figure 54 : Les différentes classes de Batch
Après on fait la Configuration de l’envoie de mail automatique en commençant par l’ajout d’un
nouveau paramètre qui contiendra la liste des personnes qui recevront le mail accompagné des
informations :
- Nombre total de changes clôturés.
- Liste des références des changes clôturés.
- Statut final du traitement (OK, KO).
67
IV.8. Conclusion
Dans ce chapitre nous avons pu voir les différentes taches réalisées aux profils des applications
CCS de notre client, les problématiques affrontés ainsi que les solutions adoptées afin de donner
un travail de qualité qui répond aux exigences d’OBS.
68
Conclusion générale
La Tierce maintenance Applicative aide à externaliser la maintenance de tout ou partie des
applications d'une entreprise auprès d'un prestataire. Dans le cadre de notre stage, celui-ci se
voit transférer la responsabilité applicative des portails CCS (Customer Care Services) du client
OBS (Orange Business Services). Dans ce cadre de cette prestation, l’entreprise d’accueil CGI
a la charge également d'ajuster les applications aux besoins de l'OBS avec qui il est sous contrat.
Le projet TMA CCS consiste à réaliser, évoluer et maintenir plusieurs applications d’OBS en
suivant plusieurs démarches et méthodologies de travail telle que Cycle en V. Le respect de ces
démarches aide l’équipe à améliorer sa productivité vis-à-vis du travail demandé.
Le résultat de ce stage est donc des applications maintenues et évoluées dans le respect de
plusieurs règles de bonnes pratiques de programmation, qui permettent de les optimiser Surtout
en ce qui touche le volet de la sécurité. Pour compléter ces bonnes pratiques et autres démarches
adoptées, l’accent a été mis sur le choix de plusieurs outils connus et faciles d’apprentissage
pour permettre une maintenance plus efficace. En effet la maintenance d’une application
représentant la plus grande partie de son temps de vie, et les gains pour une application de cette
taille n’étant visibles que sur le long terme. Il est important de permettre à l’application d’être
maintenue facilement et rapidement.
Les évolutions développées sont ajoutées dans le code source de l’application MSD, elles sont
actuellement fonctionnelles et prêtes à être déployées, mais n’ont pas encore été validées par le
client car il doit passer par sa phase de test avant de confirmer le déploiement sur ses serveurs
de production.
De plus, il est nécessaire de rappeler qu’à la date de rendu de ce rapport, le stage n’est pas
encore terminé, puisqu’il se termine le 31 Juillet 2021. Ainsi donc, pendant la période qui reste,
je vais basculer vers un autre projet sur lequel je suivrai une formation obligatoire de 8 jours.
Cette expérience m'a permis d’apprendre profondément des nouvelles techniques avec des
nouveaux outils. De plus, c’était une opportunité pour améliorer mes compétences et mes
connaissances sur des langages de programmation.
En outre, ce stage était une occasion de mettre en pratique mes connaissances acquises et mon
savoir-faire, de se rapprocher des difficultés du marché de travail, et vivre une expérience
professionnelle valorisante et encourageante pour moi dans l’avenir
69
Bibliographie
[1] https://www.cgi.com/fr/profil-entreprise/cgi-histoire
[2] https://www.zkoss.org/documentation
[3] https://www.cgi.com/france/fr-fr/secteur-public
[4] https://www.geek-directeur-technique.com/2009/02/04/le-cycle-en-v
[5] https://www.journaldunet.fr/web-tech/dictionnaire-du-webmastering/1445246-spring-
en-informatique-definition-concrete-et-caracteristiques/
[6] https://whatis.techtarget.com/fr/definition/SOAP-Simple-Object-Access-Protocol
[7] https://www.zkoss.org/product/zk/releasenote/6.5.5
[8] https://www.zkoss.org/product/zk/releasenote/9.5.0
[9] https://www.vaadata.com/blog/fr/test-dintrusion-approche-methodologie-types-de-
tests-et-prix/
[10] https://www.journaldunet.fr/web-tech/guide-de-l-entreprise-digitale/1443820-
jenkins-logiciel-star-de-l-integration-continue-open-source-gratuit/
[11] https://www.zaproxy.org/getting-started/
[12] https://sql.sh/cours/procedure-stockee
[13] https://fr.wikipedia.org/wiki/Tierce_maintenance_applicative
[14] https://www.journaldunet.fr/web-tech/dictionnaire-du-webmastering/1203563-
batch-definition-
traduction/#:~:text=Le%20terme%20batch%20d%C3%A9signe%20en,expression%20
%22traitement%20par%20lots%22
[15] https://fr.slideshare.net/amritkaur1023611/5-stored-procedure-and-functions
[16] https://wiki.en.itprocessmaps.com/index.php/Checklist_Request_for_Change_
RFC
70

El Gafif Essaadia

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

El Gafif Essaadia

Transféré par

Droits d'auteur :

Formats disponibles

Rapport de stage de fin de formation

Présenté en vue de l'obtention du diplôme de :

La maintenance évolutive des applications

Mlle. EL GAFIF Essadia

Organisme : CGI Technologies et solutions Logo :

Encadré par : Mme. Hajar Zouhair Encadrant professionnel

Soutenu le 14-07-2021 devant le jury :

HALKHAMS Imane : Enseignant chercheur à l’UPF Président du jury

HAJJI Tarik : Enseignant chercheur à l’ENSAM Examinateur

A tous ceux qui nous aiment

Nous remercions vivement M. BOUKAR Azzelarabe, mon responsable au sein de la

Liste des figures....................................................................................................................................... 7

Le savoir et la connaissance s’accroissent de plus en plus grâce à l’outil informatique, les

I.2.Presentation de CGI Technologies et solutions

Figure 1 : CGI en chiffres

Figure 2 : Evolution de la marque CGI

I.2.3. Constitution de CGI

Les valeurs de CGI :

Assurance – Nous aidons des centaines d’assureurs, de courtiers et d’agents partout

I.2.5. Clients de CGI

I.2.6. CGI Maroc

I.2.7. Activités de CGI Maroc

I.3.Presentation de ma mission lors du stage

Ce chapitre a été conçu pour se familiariser avec l’environnement du travail, l’entreprise

II.2. TMA (Tierce Maintenance Applicative)

 Fiabilité des ressources existantes

Le domaine de l’externalisation la maintenance des applications permet de répondre à deux

Activités de ML (Maintenance logicielle)

Figure 5 : Type maintenance

II.2.3. Modèle de méta processus de la maintenance de logiciel

Figure 6 : Modèle de méta processus de la maintenance logiciel

Un procès de maintenance est composé de plusieurs aspects primordiales pour son

II.3. Définition CCS

II.4. Les différentes CCS

II.4.1. Référentiel ITS (REFITS)

II.4.2. Service Insight (SI)

II.4.3. My Security Desk (MSD)

II.4.4. SMTP Messaging OMSM

Mettre en place un cycle d’amélioration pour garantir un niveau de qualité et de performance

La gestion des exigences se résume en 3 points principaux qui sont :

Les exigences utilisateurs se traduisent en spécifications fonctionnelles générales (SFG). Ces

Les exigences sont gérées par :

 Des discussions avec le client par téléphone ou Mail / réunion de lancement.

II.5.3.2 La gestion des incidents

II.5.4. La conception et les spécifications techniques

II.5.4.1 Les tests unitaires

Les développements doivent être réalisés en prenant en considération :

II.5.4.3 Les anomalies en test

II.5.4.4 Les tests d’intégration

Les entrants des tests d’intégration sont :

Figure 7 : Logo Mantis BT

Figure 9 : Logo GIT

GIT a donc et par conséquent deux utilités principales :

Figure 10 : Interface JENKINS

III.2. La méthodologie de pilotage

Figure 11 : Méthodologie cycle en V

On peut y distinguer 3 grandes parties :

 Les phases de conception

 La phase de réalisation (codage)

La phase de conception se réduit à 2 étapes.

III.3. My Security Desk (MSD)

La couche d’accès aux données :

La couche de services métier :