GNIE

LOGICIEL

82

SEPTEMBRE

2007

RETOUR DEXPRIENCE

tude de cas :
valuation de la Migration
dune Architecture Logicielle
dune Socit de Commerce
lectronique
YAQUELINE CORRALES

ET

C L A U D E Y. L A P O R T E

Rsum : Une migration logicielle est un processus consistant changer un logiciel dun environnement un autre
ou dune version de base vers une autre, en effectuant les adaptations ncessaires pour que le systme continue de
fonctionner correctement. Lquipe de dveloppement du site de commerce lectronique ECommerce BF a effectu une migration darchitecture logicielle afin de mieux rpondre aux besoins croissants de sa clientle. Ce site
compte plus de 3 600 clients dans plus de 60 pays.
Cette valuation a inclus les aspects concernant le volet technique de la migration darchitecture logicielle et
dautres aspects tels que le processus de gestion de la migration, limpact que ces migrations ont sur lquipe de
dveloppement, ainsi quune valuation du contexte organisationnel. Pour faciliter lvaluation de la migration,
on a effectu une analyse de larchitecture logicielle. Puis, on a ralis une analyse du contexte organisationnel
avec lquipe de dveloppement et la direction, pour ensuite valuer le processus de migration ainsi que la gestion du projet.
Mots cls : migration logicielle, architecture logicielle, systme dinformation.

1. INTRODUCTION

logie utilise : il peut rsulter dun changement

excut trop rapidement ou sans planification adquate, dune mauvaise analyse des besoins ou dune
mauvaise utilisation des ressources humaines et
matrielles.

Lvolution constante de la technologie informatique pousse les entreprises mettre en place des
changements technologiques qui peuvent avoir un
impact important sur la technologie utilise et sur
les personnes responsables de la mise en uvre.
Ces changements technologiques doivent rpondre
des besoins et doivent suivre les orientations technologiques de lentreprise afin de bien sintgrer
son plan daffaires. Malheureusement, beaucoup
dentreprises ralisent ces changements technologiques sans effectuer une analyse de risques et sans
considrer les impacts sur le fonctionnement de
lorganisation. Ceci peut souvent mener un chec.
Cet chec ne dpend pas seulement de la techno-

La socit Media B2B est spcialise dans lexploitation de sites daffaires lectroniques et fournisseur de solutions daffaires. En 1996, Media
B2B a lanc son premier site de commerce lectronique, ECommerce BF, et a mis en place la premire version de son architecture logicielle. Depuis,
Media B2B continue faire voluer son architecture logicielle pour mieux rpondre aux besoins de
performances, de fiabilit, de scurit, de stabilit

40

GNIE

LOGICIEL

82

SEPTEMBRE

2007

RETOUR DEXPRIENCE

Tableau I : Description des sites de Media B2B

de ses sites daffaires lectroniques et pour sadapter aux changements constants de la technologie
informatique. Media B2B exploite 13 sites daffaires lectroniques diffrents avec plus de 7 000
compagnies membres, dans plus de 60 pays. Le
tableau I prsente une brve description de chacun
de ces sites. Les noms de la socit et des sites ont
t modifis pour assurer la confidentialit.

quune brve analyse des principaux critres de

qualit de larchitecture.
Prsentation de lanalyse de la migration logicielle du site ECommerce BF, de la motivation,
des risques, des cots ainsi que de lanalyse de la
convergence de la migration avec le processus
daffaires de la compagnie.
Prsentation de lanalyse du processus de migration darchitecture logicielle et de la gestion du
processus ainsi que des objectifs technologiques
et stratgiques de la migration.
Prsentation des rsultats de lvaluation du processus de migration darchitecture logicielle, des
conclusions et des recommandations pour des
migrations logicielles futures.

Afin de rpondre aux besoins croissants de ses

clients, ECommerce BF effectue priodiquement
des migrations darchitecture logicielle, ce qui lui
permet damliorer les services et de poursuivre son
volution technologique. Pour le site ECommerce
BF, les migrations darchitecture logicielle nont
jamais t compltement estimes ou quantifies.
Ce projet a permis dvaluer limpact des migrations technologiques afin daider la direction
appuyer les dcisions futures quant la ncessit
deffectuer des migrations darchitecture logicielle.
En effectuant une valuation des migrations darchitecture logicielle et de limpact que ces changements ont sur lquipe de dveloppement, la direction
pourra mieux comprendre la pertinence du changement darchitecture logicielle et obtiendra un rapport
dtaill des bnfices de tels changements en termes
de productivit, damlioration du travail, de la facilit dutilisation des nouveaux outils, des gains en
performances et en qualit.

2. PRSENTATION

DU SITE

ECOMMERCE BF

Le site ECommerce BF a t dvelopp en suivant

une architecture 3-tiers J2EE (Java 2 Enterprise Edition) qui spare linterface de lutilisateur de lensemble des fonctionnalits offertes, du traitement des
applications et de la base de donnes. Le systme
dECommerce BF repose sur larchitecture logicielle
de Media B2B et utilise cette architecture pour le traitement de linformation ainsi que pour les aspects de
scurit, confidentialit et autres. Lutilisation de larchitecture de Media B2B avantage le site ECommerce
BF, car ce dernier peut profiter de lexpertise de larchitecture, de sa stabilit ainsi que de toutes les mises
jour et amliorations qui sont effectues. La figure
1 montre larchitecture du systme utilis par le site
ECommerce BF.
2.1 MODLISATION

DU SITE

La logique daffaires ncessaire au fonctionnement

dECommerce BF est supporte par larchitecture
logicielle de Media B2B, ce qui permet lquipe
de dveloppement dECommerce BF de concen-

41

Le plan de larticle est le suivant :

Prsentation du site ECommerce BF, de ses fonctionnalits, de son architecture et de son volution.
Prsentation des rsultats de lvaluation du
contexte organisationnel dECommerce BF.
Prsentation de larchitecture logicielle de Media
B2B et description des aspects techniques du systme, de sa modlisation, de son volution ainsi

GNIE

LOGICIEL

82

SEPTEMBRE

2007

RETOUR DEXPRIENCE
Figure 1 : Architecture du
systme dECommerce BF

Tableau II : Caractristiques du site ECommerce BF

42

GNIE

LOGICIEL

82

SEPTEMBRE

2007

RETOUR DEXPRIENCE

Figure 2 : Cycle de dveloppement dECommerce BF

trer ses efforts lvolution fonctionnelle du site

selon les besoins du march.
Pour lajout des nouvelles fonctions, ECommerce
BF utilise un cycle de dveloppement comprenant
quatre phases principales tel quillustr la figure 2.
Pour chaque version dECommerce BF, les
documents suivants sont produits : les spcifications des fonctionnalits, le plan dassurance-qualit, le plan de mise en production ainsi que le
calendrier davancement du projet.
2.2 VOLUTION

DU SITE

Depuis les dbuts, une vingtaine de versions

dECommerce BF ont t mises la disposition
des clients un rythme dau moins trois nouvelles
versions par anne. Ces versions visent principalement ajouter de nouvelles fonctionnalits pour
rpondre aux exigences du march.
Afin de donner une ide de lampleur de lvolution dECommerce BF ainsi que des diffrentes
migrations logicielles ayant t effectues au cours
des dernires annes, le tableau III prsente
quelques exemples des diffrentes versions
dECommerce BF partir de la version 5.6 de larchitecture (Tableau III).

Nous avons fait les constats suivants :

Le projet est dfini selon les exigences du client,
il est document et suivi tout au long de son cycle
de vie. Par contre, il nexiste pas une politique
pour la gestion des exigences.
La planification du projet de lquipe dECommerce BF est satisfaisante. Cependant, le suivi
est presque inexistant dans lorganisation.
Pour lassurance-qualit, les objectifs sont tablis,
les personnes concernes sont identifies et les
problmes sont adresss correctement. Par contre,
il nexiste pas de procdures en ce qui a trait au
plan dassurance-qualit dans lorganisation.
Pour la gestion de la configuration, un plan est tabli et les lignes directrices sont utilises pour chaque
nouvelle version. Les ressources sont alloues et les
responsabilits sont assignes. Il ny a pas de mise
en uvre du processus pour le suivi ou le contrle.
La dfinition et la documentation des projets sont
labores correctement.

3. VALUATION

DU CONTEXTE
ORGANISATIONNEL

Ce chapitre prsente les rsultats de la mini valuation de la maturit du processus de dveloppement selon le modle du CMMI 2 (Capability
Maturity Model Integration) [1] et les rsultats des
valuations des facteurs humains.
3.1 VALUATION DU PROCESSUS

Nous avons effectu une mini valuation avec la

directrice du site. Cette valuation consistait en un
questionnaire sur les diffrentes pratiques logicielles

43

au sein de lquipe de dveloppement dECommerce

BF. Les domaines de processus valus sont :
Gestion des exigences : processus par lequel on
tablit comment lentreprise gre les exigences du
produit et de ses composants afin de dterminer
si le produit final rpond aux exigences initiales.
Planification des projets : processus qui sert tablir et grer des plans qui dterminent les activits
du projet.
Suivi et contrle de projets : processus dans
lequel le projet est suivi dans toutes ses tapes, de
sorte que des actions correctives soient prises
quand le projet scarte du plan initial.
Assurance qualit logicielle : processus qui fournir aux quipes et aux gestionnaires une vision
objective du processus utilis par le projet ainsi
que sur les produits en laboration.
Gestion de la configuration logicielle : processus
qui vise maintenir lintgrit des produits du
projet tout au long de son cycle de vie.

GNIE

LOGICIEL

82

SEPTEMBRE

2007

RETOUR DEXPRIENCE

Tableau III : Principales fonctionnalits de quelques versions dECommerce BF partir de la version 5.6 de larchitecture

Tableau IV : Outils dvaluation des changements de la socit IMA

Nous avons aussi constat quil serait judicieux,

pour ECommerce BF, damliorer sa gestion des
processus pour arriver un meilleur contrle de
limplantation et du suivi des projets. Il faut profiter
de lexprience du personnel pour transmettre leur
savoir dans les autres quipes.
3.2 LES

3.2.1 valuation des commanditaires (sponsors)

Lvaluation des commanditaires permet dvaluer le niveau et le type dengagement dont ils
doivent faire preuve afin dassurer le succs de la
mise en uvre dun projet de changement. Par
exemple, on demande aux personnes qui subiront
le changement propos dvaluer, sur une chelle
de 1 5, laffirmation suivante : le commanditaire fait preuve dune implication personnelle et
dun engagement important au sujet de ce changement. On calcule les scores de chaque personne
concerne et on calcule la moyenne pour chaque
question. Le score reprsente la probabilit de
succs de mise en uvre du projet de changement. Un score lev signifie que le succs de
mise en uvre de ce changement est tout fait
probable. Un score moins lev signifie que des
stratgies doivent tre dveloppes, car le niveau
et le type dengagement des commanditaires peuvent menacer le succs de la mise en uvre du
changement.

FACTEURS HUMAINS

Afin de mieux tablir le profil des personnes responsables de la mise en place de la migration logicielle, plusieurs valuations ont t ralises en
utilisant les outils dvelopps par la socit amricaine Implementation Management Associates
(IMA) [2]. Ces valuations visent mesurer la gestion des changements dune organisation et prdire les points amliorer pour des changements
futurs. Les valuations aident dterminer la synergie dune quipe de travail, sa capacit effectuer
un changement et la probabilit de succs pour ce
changement. Le tableau IV numre quelques outils
dvaluation.

44

GNIE

LOGICIEL

82

SEPTEMBRE

2007

RETOUR DEXPRIENCE

Daprs lvaluation, nous pouvons conclure que :

les commanditaires sont engags dans les changements au niveau de lorganisation,
les dveloppeurs ont de la difficult comprendre
les messages transmis par les commanditaires,
car ils ne comprennent pas limpact ou le bienfond des changements demands,
les commanditaires manquent de conviction en
ce qui a trait leurs attitudes envers les changements : les employs sentent quils sont en faveur
du changement, mais ils ne peroivent pas leurs
engagements face ce quils demandent,
le systme de renforcement sopre principalement au niveau de lquipe et non individuellement.

eu la plus grande influence sur le stress organisationnel sont limplication des employs, les nouvelles mises en uvre du contrle de qualit et les
nouvelles techniques introduites. Le stress de la
vie professionnelle est faible, ce qui contribue positivement ladaptation face aux changements.
Lutilisation des rsultats des valuations du
niveau de stress aidera lorganisation mieux quantifier les migrations et, par consquent, mieux estimer et dlguer les activits relies aux changements
technologiques. Lorganisation doit suivre de prs le
stress organisationnel pour que celui-ci ne vienne
pas dtriorer le climat de travail dans lentreprise.
3.2.4 valuation des agents de changement
Lvaluation des agents de changement permet de
dterminer le profil des personnes qui seront responsables de mettre en place un changement complexe. Les valuations indiquent que le niveau de
comptence de lquipe des agents de changement
est modr. Nous avons remarqu quen gnral,
lentreprise dispose dun climat qui favorise lintgration des changements grce au niveau dengagement des intervenants.

On a propos que la direction analyse en profondeur les rpercussions des changements proposs. Le tout pourrait se faire en produisant un plan
de projet plus dtaill et mieux adapt chaque
quipe de travail. Ce plan pourrait utiliser plus efficacement les canaux de communication avec les
quipes de travail. Il faudra sassurer que lquipe
de migration saisisse le bien-fond des changements en plus de faire connatre les critres de succs pour mener bien le projet.

Fait intressant : les employs peroivent les

agents de changement comme des gens ayant de
bonnes attitudes pour diminuer le stress organisationnel. Il faudrait exploiter cette situation avantageuse.

3.2.2 valuation de la culture de lorganisation

Cet outil permet dvaluer si le changement mettre
en place est cohrent avec la culture de lorganisation. On peut aussi identifier des facteurs de rsistance aux changements proposs.

3.2.5 valuation des personnes vises par le changement

Cet outil vise valuer le degr dadaptation au
changement de chacune des personnes impliques
dans le projet afin dtablir le niveau de rsistance
au changement.

Selon les rsultats des valuations, ECommerce

BF jouit dune structure de travail flexible, ce qui
laidera lorsque viendra le temps de faire face
des problmes technologiques ou professionnels.
On y favorise beaucoup la collaboration entre les
gens, ce qui rend lorganisation plus rceptive aux
demandes de changements de ses clients.

Nous avons mesur un grand cart entre les

personnes values. Nous avons jug que le fait
davoir deux personnes plus craintives et deux plus
fonceuses face aux changements, pourrait aider
quilibrer la synergie de lquipe.

Par contre, les opinions des employs sur la

migration darchitecture logicielle sont mitiges :
ils ont des opinions trs divergentes sur le sujet et
il nexiste pas de vision long terme en ce qui a trait
lavancement professionnel des employs.
Puisque lquipe ECommerce BF a un bon
esprit dquipe, il faut profiter de cette force pour
favoriser lintgration des changements mettre
en uvre. Lopinion des employs en ce qui
concerne la position dECommerce BF face aux
changements, est mitige. Donc, lintgration de
nouvelles technologies devrait se faire en utilisant
les employs favorables aux changements pour que
ceux-ci convainquent les employs plus rticents.

Tenant compte du fait que les rpondants ont

une certaine habitude des volutions constantes au
sein des projets sur lesquels ils travaillent et quils
sont favorables ces changements, la compagnie
pourra profiter de cette ouverture pour mener avec
succs chaque changement quelle veut mettre en
place. Elle pourrait identifier la ou les personnes
cls pouvant favoriser la russite du nouveau projet et les motiver pour quelles agissent en tant que

3.2.3 valuation du niveau de stress

Lvaluation du niveau de stress permet de mieux
comprendre le stress o les changements futurs
auront lieu. Pour ECommerce BF, les facteurs ayant

45

Toutes les personnes values sont daccord

sur la ncessit des migrations logicielles et elles
estiment que ce changement sera implant avec
succs. De plus, elles ne sentent pas que ce changement est li leurs performances, mais plutt
un besoin spcifique de lorganisation.

GNIE

LOGICIEL

82

SEPTEMBRE

2007

RETOUR DEXPRIENCE

promoteurs du changement. Il faudrait galement

penser concevoir un plan permettant dencourager les employs rticents pour les motiver adopter le projet et faciliter ainsi lavancement des
changements.

software architecture of a program or computing

system is the structure or structures of a system,
which comprise software elements, the externally
visible properties of those elements, and the relationships among them [8] donne une bonne ide
de ce quune architecture doit comporter. Larchitecture logicielle est une cl essentielle de la russite dun projet logiciel. Il est important de bien
analyser les raisons menant sa conception, que
ce soit les influences techniques, sociales, daffaires ou les proprits auxquelles le systme doit
rpondre : performances, fiabilit, disponibilit,
scurit ou autres.

3.2.6 valuation du systme de renforcement

Cette valuation vise tablir si le systme actuel
de renforcement, par exemple les rcompenses et la
rmunration, de la compagnie saligne avec les
attentes et aspirations des membres de lquipe.
Nous avons remarqu que les employs, qui
ont rempli le questionnaire, avaient des prfrences
opposes au systme de renforcement propos par
lentreprise. Par exemple, les employs manifestent
une prfrence pour avoir des congs plus longs,
pratique quils ne peroivent pas comme rpandue
au sein de lentreprise.

4.1 DESCRIPTION

DU SYSTME

La version 5.9 de larchitecture est base sur une

stratgie de dveloppement favorisant la rutilisation des composants. Cette stratgie de dveloppement est connue dans le march du logiciel pour
la facilit faire voluer le systme par squence
ou version, ainsi que pour lamortissement du cot
de dveloppement grce un taux lev de rutilisation [8].

Par rapport aux tches alloues, la reconnaissance au travail et au renforcement intrinsque,

nous avons observ une certaine concordance entre
ce que la compagnie offre et ce que les employs
prfrent.

4.1.1 Modlisation de larchitecture logicielle

Afin de mieux prsenter la modlisation de larchitecture logicielle, cette section donne une description des diffrents lments qui la constituent
en essayant dutiliser la notion de Langage de description darchitecture ( Architecture Description
Language - ADL).

En gnral, nous avons observ que les rpondants souhaiteraient avoir plus de responsabilits,
dinfluence et de participer la rsolution de problmes importants. La compagnie devrait mieux
connatre et rcompenser les capacits professionnelles de ses employs.

Larchitecture version 5.9 est divise en composantes qui sont regroupes selon la fonctionnalit
laquelle elles doivent rpondre. Ainsi, on trouve un
rfrentiel ( framework 3), appel Media B2B Open
Server (MOS) qui contient les modules suivants :
Request Management (gestion de requtes), Media
B2B Presentation Layer (MPL couche de prsentation), Media B2B Business Layer (MBL couche du
service daffaires), Media B2B Communication Layer
(MCL couche de communication), Server Plug-ins
(serveur de plugiciels), le Inter-Server Communication
(communication entre serveurs), et le framework &
utilities (outils de gestion).

Nous jugeons que lutilisation des moyens

dencouragements montaires au lieu du systme de
cadeaux propos par lentreprise rglerait le problme des encouragements tangibles. Nous proposons que les tches offertes soient plus varies, car
cela est considr comme prioritaire par la plupart
des rpondants.

4. PRSENTATION ET ANALYSE
DE LARCHITECTURE LOGICIELLE
La tendance de linformatique des dernires annes
a amen larchitecture logicielle jouer un rle
central dans le gnie logiciel. La dfinition The

Le rfrentiel MOS intgre les composantes

suivantes afin doffrir une application serveur :
La composante Request Management est responsable de la rception des requtes externes,
de leur authentification, de leur acheminement
et de lautorisation de leur excution.
La composante Presentation Layer est la couche
qui contient toute la logique de prsentation.
Aucun processus daffaires ny est trait. Cette
couche fournit trois composants : lInput handler qui contient des objets reprsentant les paramtres dentre, le Presentation Controller qui
contrle le traitement du contenu dynamique et le
Presentation View, qui transforme les objets reprsents en contenu dynamique.

Figure 3 : Composantes de larchitecture logicielle

46

GNIE

LOGICIEL

82

SEPTEMBRE

2007

RETOUR DEXPRIENCE

Tableau V : Exemples de fonctionnalits de la version 5.9 de larchitecture

La composante Business Service Layer est la

couche dimplmentation englobant toute la
logique daffaires de larchitecture. Elle renferme
deux niveaux de conception : le Media B2B Busi-

ness Service (MBS), qui sert dfinir les fonctionnalits daffaires, les isoler de la logique
de prsentation, contrler le flux de donnes et
le Media B2B Business Entity (MBE), respon-

47

Tableau VI : Attributs de la qualit

GNIE

LOGICIEL

82

SEPTEMBRE

2007

RETOUR DEXPRIENCE

Tableau VII : Exemples dattributs de qualit de la version 5.9 de larchitecture

Tableau VIII : Identification des cots en heures de la migration de larchitecture logicielle

sable de la persistance des entits daffaires dans

la base de donnes. Pour accder aux entits, cette
couche contient galement les Business Functional Objects (BFO) quimplmentent les rgles
et les oprations daffaires et les Business Data
Access (BDA) qui permettent daccder directement aux donnes.
La composante Communication Layer est la
couche permettant la communication des composants avec les systmes externes, que ce soit en
entre ou en sortie. Cette couche isole les chemins de communications des clients davec le
systme de Media B2B.
Les Server Plug-ins sont des composants qui sont
automatiquement charges au dmarrage du serveur. Elles sont utilises par les couches daffaires et de communication pour effectuer leur
traitement et par la couche de prsentation pour
gnrer des rapports.
La composante Inter-Server Communication facilite la communication entre les serveurs. Elle
englobe deux services : lOpen Server Services
(OSS) qui simplifie le processus dtablissement
des connexions entre deux serveurs et le Media
B2B Distributed Services (MDS) rseau fdrateur4 permettant le partage de services, donnes et
vnements travers les serveurs dune manire
sre et efficace.
Les Frameworks & Utilities sont des outils faci-

litant la gestion des settings , de la mmoire

cache des donnes, du traitement des documents
et de la gestion des messages.
4.1.2 Fonctionnalits de larchitecture logicielle
Le tableau V prsente quelques exemples des principales caractristiques ou fonctionnalits de larchitecture selon chacune de ses composantes, ainsi
que les amliorations labores dans la version 5.9,
par rapport aux versions antrieures de larchitecture.
4.1.3 Larchitecture selon les critres de qualit
La conception de larchitecture logicielle dun systme doit rpondre aux besoins de qualit comme
les performances, la fiabilit, la scurit, lintgrit et lvolutivit. Plusieurs mthodes, comme
ATAM, Architecture Tradeoff Analysis Method
[12], ou ABAS, Attribute-Based Architecture
[13], permettent danalyser larchitecture selon ses
attributs de qualit et font ressortir les points critiques de la conception. Les principaux attributs
de la qualit sont numrs dans le tableau VI :
Nous donnons quelques exemples des attributs
de la qualit de la version 5.9 de larchitecture dans
le tableau VII. Le niveau de priorit de chaque attribut est labor en suivant la nomenclature (X,Y)
o la premire lettre indique limportance de lobjectif et la deuxime, le niveau du risque. Cette

48

GNIE

LOGICIEL

82

SEPTEMBRE

2007

RETOUR DEXPRIENCE

affectation de priorit utilise lchelle H (haut),

M (moyen) et B (bas).

Pour lidentification des cots, nous avons utilis les activits du processus de dveloppement
recommandes par la norme ISO/CEI 12207 [22].
Cette norme dfinit les activits du processus de
dveloppement, savoir analyse des spcifications,
conception, code, intgration, tests, installation et
acceptation. Mme si la norme identifie les tapes
du processus de dveloppement logiciel et pas celles
dune migration, il nous apparat que certaines de
ces tapes doivent tre prises en considration lors
des migrations. Car, avant tout, une migration est
un processus de modifications dun logiciel et il
est ncessaire de sassurer que ce dernier soit gr
comme un processus logiciel incluant les diffrentes phases danalyse, de dveloppement et de
tests. Le tableau VIII numre le cot, en heures,
des activits de migration. Le nombre dheures
danalyse et spcifications a t identifi la suite
de rencontres avec les dveloppeurs et la directrice
du site. Le nombre dheures de formation a t
identifi la suite de rencontres avec les dveloppeurs et la direction du site.

DE LA MIGRATION LOGICIELLE

La plupart des entreprises sefforcent de faire voluer leur systme informatique pour mieux rpondre
aux exigences du march, la fulgurante volution
de la technologie, et pour sadapter aux nouveaux
standards. Media B2B offre des services plusieurs
rseaux daffaires, ce qui loblige chercher se
doter dune infrastructure commune pour offrir les
mmes services dans les diffrentes plates-formes.
Un processus daffaires se dfinit comme une
Suite cohrente dactivits et doprations commerciales quentretient une entreprise ou une organisation avec des tiers, traduisant les besoins de
ses clients et les exigences de son environnement,
et tenant compte ou non de ses activits internes
de manire les agencer selon une logique de cration de valeur [10]. Un processus daffaires inclut
les diffrentes activits dune organisation pour
rpondre efficacement aux besoins de ses clients.
Une entreprise na pas quun seul processus daffaires mais plusieurs processus cls qui sharmonisent entre eux pour atteindre ses objectifs et pour
produire de la valeur pour ses clients.
5.1 BESOINS

5.3 ANALYSE

TECHNIQUES

Une architecture logicielle est conue pour rpondre

aux spcifications fonctionnelles et aux attributs
de qualit ncessaires au logiciel. Dans le cas tudi, il sagit de rpondre aux besoins du site ECommerce BF. Larchitecture logicielle de Media B2B
doit rpondre aux besoins fonctionnels de lensemble de ses diffrents rseaux daffaires et non
pas un seul. Chacun des rseaux a des raisons
diffrentes pour migrer dune version darchitecture
une autre. Dans le cas dECommerce BF, certains
besoins techniques ont motiv la migration :
ECommerce BF avait besoin de performances et
de fiabilit pour rpondre aux exigences du march quelle dessert. Ainsi, un des principaux
objectifs de la migration darchitecture logicielle
dECommerce BF tait lamlioration de la
charge, de la scurit et des performances ;
le nombre de lignes dinventaire avait atteint une
limite de 2 giga-octets, ce qui rendait impratif
une division de la base de donnes et cette fonctionnalit ntait offerte qu partir de la version
5.9 de larchitecture ;
il fallait continuer amliorer les services de
scurit du site savoir la gestion du contrle
daccs, la gestion des sessions, la gestion des
mots de passe et lamlioration du systme de
dtection des intrus.
5.2 COT

DU RETOUR SUR INVESTISSEMENT

Il est possible que linvestissement effectu puisse ne

pas avoir de retombes tangibles. De plus, elles sont
difficilement mesurables. Mais ces changements peuvent gnrer des bnfices en termes de diminution
des cots de maintenance ou de fonctionnement, en
plus des amliorations dans les attributs de qualit du
site. Mme si ces changements ne se traduisent pas
en argent, ils ajoutent une valeur au processus daffaires
de la compagnie. Les paragraphes suivants dcrivent
les avantages de cette migration.
5.4. UTILISATION

DE TECHNOLOGIES CONCURRENTIELLES.

Une des principales raisons pour lesquelles larchitecture logicielle a volu continuellement rside
dans limplmentation de nouvelles technologies
ncessaires au fonctionnement des diffrentes
plates-formes pouvant amliorer la qualit de larchitecture et faciliter le dveloppement des sites.
Pour ECommerce BF, migrer vers une nouvelle
version de larchitecture permet de profiter de ces
technologies - surtout pour les nouvelles fonctionnalits - sans avoir modifier tout le code en place.
5.5 DIMINUTION

DE LEFFORT POUR SUPPORTER

LES ANCIENNES TECHNOLOGIES UTILISES.

Considrant que lors de la migration la version 5.9

de larchitecture, ECommerce BF na eu raliser
que des adaptations mineures la configuration et
quelques modifications au code, cet avantage perd de
la valeur. Il faut noter que la nouvelle version de larchitecture doit continuer de supporter des technologies
ayant t implmentes dans plusieurs versions antrieures et qui peuvent ne plus savrer comptitives
dans le march informatique. Toutefois, si ECom-

DU PROJET DE MIGRATION

Afin dtablir une rfrence pour des migrations

futures, nous avons estim les cots de la migration

49

5. ANALYSE

logicielle en termes dheures utilises pour chacune des tapes identifies.

GNIE

LOGICIEL

82

SEPTEMBRE

2007

RETOUR DEXPRIENCE

estims, etc.) ou les rsultats (c.--d. le logiciel ne

rpond pas aux spcifications initiales). Ces risques
ont une incidence sur le droulement du projet et,
sils sont mal grs, ils peuvent mener lchec
du projet.
Le tableau IX nonce, titre dexemples,
quelques risques identifis, leur impact dans le processus de migration ainsi quun rsum de lapproche ou de la solution qui a t prise lors de la
migration.

Figure 4 : volution mensuelle de temps de rponse

(le mois 0 reprsente le mois de la migration)

6. ANALYSE

merce BF utilise les outils de la nouvelle architecture

pour dvelopper ses nouvelles fonctionnalits, cet
avantage peut augmenter avec le temps.

DU PROCESSUS DE MIGRATION
DU SITE VERS LA NOUVELLE

Une migration logicielle doit assurer quune fois

le processus termin, lapplication continuera
fonctionner comme avant la migration. Il est
donc trs important de dcrire les comportements de lapplication et ses caractristiques
avant la migration, pour possder des mesures
qui permettront dtablir le succs ou lchec
de la migration. Mais ces aspects ne sont pas les
seuls indicateurs de succs du projet. Il est galement important dvaluer dautres facteurs cls
du projet et didentifier les objectifs avant le
dbut du processus, pour bien cibler les problmes rsoudre et valuer si ces objectifs ont
t atteints la fin du projet.

Daprs la lecture du code Java des diffrentes

versions dECommerce BF, nous avons observ une
croissance lente dans lutilisation des nouvelles technologies. En gnral, le codage des fonctionnalits
utilisant la nouvelle technologie est excut dans la
premire version migre, pour ensuite sarrter ou
voluer trs lentement. Ce constat permet de penser
que la diminution des cots de maintenance des
anciennes technologies peut stendre sur plusieurs
versions, sauf si on prend des mesures pour convertir lancien code.
5.6 AMLIORATION DES ATTRIBUTS DE QUALIT.

6.1 LE SUCCS OU LCHEC DU

DE LARCHITECTURE LOGICIELLE

En migrant vers cette version de larchitecture logicielle, ECommerce BF profite des amliorations des
attributs de qualit, ce qui peut se traduire par une
amlioration des services que le site offre ses clients.

Au Canada, selon une tude mene par KPMG

Canada [24] auprs de 1 450 organisations, 87%
des projets ont dpass leur chancier de plus de
30%, plus de 56% des projets ont dpass leur budget et 45% nont pas atteint leurs objectifs.

Avec plus de 190 000 recherches par jour, la

recherche constitue une des fonctionnalits critiques
dECommerce BF. Nous avons analys la variabilit
du temps de rponse des recherches effectues
lintrieur dune priode dun mois. Comme le
montre la figure 4, aprs la migration (mois 0), le
temps de rponse une recherche a lgrement augment pour ensuite rester plus ou moins stable.
5.7 RISQUES

PROJET DE MIGRATION

Pour dterminer le succs de la migration logicielle, il ne faut pas seulement valuer le respect des
chanciers et du budget. Il faut galement valuer la gestion du processus dans lensemble, la
gestion du personnel et son implication dans le projet, car ces aspects sont critiques au niveau du projet et ils peuvent assurer sa russite. Afin de mieux
rpondre aux besoins de cette valuation, nous
avons valu les critres de succs ou dchec, suivants : la dfinition des objectifs et des besoins,

DE LA MIGRATIONDARCHITECTURE

LOGICIELLE

Tout projet logiciel comporte plusieurs risques pouvant affecter le processus (dlai du projet, cots

Tableau IX : Exemples de risques identifis pour la migration de larchitecture logicielle

50

GNIE

LOGICIEL

82

SEPTEMBRE

2007

RETOUR DEXPRIENCE

lanalyse de la gestion du projet de migration

incluant limplication des dveloppeurs, le respect
des chanciers et du budget et le soutien de la
direction. Nous estimons que lors dun processus de
migration logicielle, il faut considrer laspect
humain, de faon ce que les personnes responsables de la migration puissent mettre la disposition du projet toutes leurs comptences et que
ces dernires voluent en parallle avec la migration. Pour valuer cet aspect, nous examinerons
les activits de formation, daccompagnement et
de support qui ont t offertes aux membres de
lquipe de dveloppement.

le contrle, qui permet de mesurer et valuer laccomplissement de chacune des tapes du projet.
Un projet de migration darchitecture logicielle
doit tre gr comme les autres projets informatiques, en tenant compte des contraintes qui peuvent
survenir au cours du projet, tout en considrant les
risques lis au changement. Une migration logicielle doit tre vue comme un projet de changement o il faut spcifier les besoins, communiquer,
former, documenter et dmontrer limportance du
changement pour le motiver et le justifier comme
un avantage pour le processus daffaires de lentreprise.

6.1.1 Identification des objectifs de la migration

de larchitecture logicielle
Dans un projet de migration darchitecture logicielle, un des principaux avantages est dutiliser
les attributs de qualit quoffre une infrastructure
logicielle et de profiter de lvolution technologique de cette dernire. Comme lexpliquent plusieurs auteurs, une architecture logicielle peut
rpondre aux besoins dun ou plusieurs logiciels
qui gagnent lexprience et la solidit de larchitecture logicielle, ainsi qu la rduction des
cots de dveloppement et de maintenance
[8][20][21].

6.1.3 Planification de la migration darchitecture

logicielle
Lors de la planification dun projet, il faut dfinir
les objectifs, les activits raliser, la gestion des
risques, la prparation du budget et le plan de dveloppement [26]. Comme nous lavons mentionn,
la planification de la migration darchitecture logicielle a t incluse lintrieur des documents de
gestion de projets dECommerce BF. Les lignes
directrices de ce qui devait tre inclus lors de la
migration ainsi que les objectifs se retrouvaient
galement dans ces documents. La planification
initiale prvoyait un effort de dix jours de dveloppement pour assurer la migration.

Selon lanalyse des diffrents documents, nous

avons pu tablir que les principaux objectifs technologiques de la migration darchitecture logicielle
dECommerce BF taient :
amlioration des performances ;
amlioration de la distribution des charges.
amlioration des oprations :
- gestion des erreurs ;
- contrle de traces et des temps morts, distinction entre les erreurs du serveur et des erreurs
des usagers ;
- systme de dtection des intrus ;
- gestion des erreurs de synchronisation.
amlioration du systme de facturation.
6.1.2 Gestion du projet de migration
La gestion dun projet a pour objectif de conduire
le projet terme, en satisfaisant ou dpassant les
exigences initiales et en utilisant son savoir-faire et
ses habilets de gestion. La gestion dun projet a diffrentes fonctions [26] :
La planification, incluant les activits et les processus devant tre accomplis ; lorganisation,
qui dtermine quel travail doit tre accompli, la
rpartition des tches et lassignation des responsabilits ;

6.1.5 Consultation et acceptation du projet par

le client
Le processus dune migration darchitecture logicielle doit tre ralis de manire ce que les clients
ne voient aucun changement dans le comportement
de leur application. La norme ISO/CEI 12207 [27]
prcise que lors du processus didentification et de
rsolution des problmes, le client ne doit pas
connatre ou dterminer la nature du problme de
fonctionnement du nouveau systme, ni demander

la slection de lquipe, avec un leader qui puisse

entraner et guider les membres de son quipe
bien raliser le projet ;
la gestion, qui doit permettre de mener le projet
terme dans une atmosphre positive et motive ;

51

6.1.4 Gestion de facteurs tactiques

Les dcisions tactiques consistent jouer sur les
moyens, modifier les actions spcifiques pour
sadapter aux incidents de parcours et continuer
obtenir les avantages prvus sur le terrain. Lensemble des tactiques sinscrit dans la stratgie ;
celle-ci assigne chacune son rle, sa place dans le
dispositif, son type de dveloppement et ses limites.
La stratgie prvoit aussi ncessairement la coordination, lventuel degr de subordination et de
convergence des tactiques entre elles. [10]. Pour
bien grer les facteurs tactiques dune migration
logicielle, nous devons prendre en considration
les activits de consultation et lacceptation du projet par le client, la gestion des employs incluant les
stratgies de gestion du changement, de formation
et de soutien ; le contrle et la rtroaction du projet ; le plan de communication ; la gestion des
risques et la correction de problmes. Nous dcrivons ci-dessous quelques activits :

GNIE

LOGICIEL

82

SEPTEMBRE

2007

RETOUR DEXPRIENCE

sa correction. Le projet doit donc fournir les outils

et les processus pour trouver, attribuer, corriger et
fermer les dossiers derreurs. Une migration darchitecture logicielle doit tre teste et valide pour
sassurer que les fonctionnalits continuent fonctionner correctement.

Ainsi, elle sest assure que le processus saccomplirait plus facilement. La migration darchitecture
logicielle a t perue par les membres de lquipe
comme un processus ncessaire qui avait peu dimpacts sur le fonctionnement dECommerce BF.
6.1.8 La formation
Lobjectif de la formation est de faciliter la prise en
charge du nouveau produit par les utilisateurs et
leur appropriation des nouvelles rgles et procdures [28]. Dans le cas de la formation donne lors
de la migration de larchitecture logicielle, lobjectif tait de faciliter lassimilation des nouvelles
technologies mises en place par la version 5.9 de
larchitecture et dinciter lutilisation des nouvelles
pratiques, afin de motiver la continuit de la
mthode utilise lintrieur de lentreprise. En
plus de la formation, les dveloppeurs ont eu accs
un systme de rfrence interne, accessible via
lIntranet de lentreprise, ainsi qu un support de
lquipe dinfrastructure.

6.1.6 Gestion des employs

La culture organisationnelle peut avoir un impact
sur la gestion des employs qui doivent mettre en
uvre le changement. Comme nous lavons vu la
section 1.4.1.1, ECommerce BF jouit dune structure de travail flexible, favorisant la gestion des
problmes dordre technologique ou professionnel, ainsi que la gestion des employs. Lquipe
dECommerce BF possde un bon esprit dquipe
et cette force aide la mise en place des changements.
Pour la migration darchitecture logicielle, les
membres de lquipe dECommerce BF - six au total
- ont t impliqus, ce qui a permis une meilleure distribution des rles et lexploitation des forces de
chacun des membres, tout en effectuant un suivi
constant sur lavancement du projet.

6.1.9 Soutien de la direction

On peut observer deux attitudes selon le degr
de soutien de la direction pour un projet : le soutien et limplication. Le soutien consiste encourager ladoption du nouveau systme ou de la
nouvelle technologie par une attitude positive et
bienveillante. Limplication consiste prendre des
mesures pour assurer lassimilation du nouveau
systme et un fonctionnement efficace et efficient
[28]. Quand la direction se limite un soutien,
aucune planification nest faite lavance, les changements soprent en accord avec les initiatives
individuelles avec peu de contrle. Quand on parle
dimplication, on fait rfrence la planification du
projet et la gestion du changement.

6.1.7 Gestion du changement

Lobjectif de la gestion du changement est de
faciliter le passage dun systme sociotechnique
existant un systme vis [28]. Pour faciliter le
changement, il faut le faire comprendre travers
toute lorganisation et surtout lquipe qui doit le
mettre en place. Ceci permettra daugmenter le
degr dadaptation au changement des employs
et de diminuer la rsistance au changement. Comme
nous lavons vu la section 1.4.1.5, lvaluation de
ladaptation personnelle au changement effectu
auprs de lquipe dECommerce BF, nous a montr une diversit dans la faon de percevoir le changement et ce, mme si toutes les personnes taient
daccord sur la ncessit deffectuer des migrations logicielles. Pour faciliter le changement, la
direction dECommerce BF a assign les rles en
tenant compte des forces des membres de lquipe.

Pour ce qui est de la migration darchitecture

logicielle sur laquelle porte ce document, on peut
dire quil y a eu un peu dimplication de la part de
la direction, ce qui aurait pu rendre plus difficile la
russite du projet. Le projet tait prvu dans la planification des projets pour les annes 2004-2005

Tableau X : lments dun guide de migration

52

GNIE

LOGICIEL

82

SEPTEMBRE

2007

RETOUR DEXPRIENCE

et on avait estim leffort et les ressources ncessaires pour le mettre en place. Par contre, aucun
document ne faisait rfrence la gestion du changement.

tion du code, de la configuration et de la conversion des donnes si ncessaire ;

validation et vrification de la migration, incluant
les tests dintgration qui assurent que le systme
continue fonctionner comme avant la migration ;
rtrospective et valuation de la migration.

7. RECOMMANDATIONS
POUR LES MIGRATIONS FUTURES
Afin de maximiser les chances de succs lors dune
migration future, nous proposons les principales
recommandations suivantes.
LES MIGRATIONS DARCHITECTURE

Promouvoir la migration darchitecture des sites

et de linscrire dans sa stratgie datteinte des objectifs daffaires, car une architecture logicielle commune permet aux sites de la compagnie de profiter
de lexpertise acquise par linfrastructure, de sa
stabilit et de toutes les amliorations et correctifs
effectus lors de son volution.
7.2 AMLIORER LACCS

LA DOCUMENTATION

Indexer la documentation disponible pour rendre sa

consultation plus accessible. De plus, lquipe darchitecture logicielle devrait crer un outil de
dploiement pouvant indiquer facilement les tapes
qui doivent tre suivies pour mener bien la migration et ce, en utilisant lexprience de chacun des
sites qui ont effectu la migration.
7.3 DVELOPPER

9. RFRENCES
[1]

The CMMI Web Site. Carnegie Mellon. Software Engineering Institute. http://www.sei.
cmu.edu/cmm. (Consult le 30 octobre 2006)
[2] Implementation Management Associates
(IMA). http://www.imaworldwide.com/home.
asp. (Consult le 25 octobre 2006)
[3] Capability Maturity Model Integration
(CMMI), Version 1.1, (2002), CMU/SEI2002-TR-029, ESC-TR-2002-029
[4] valuation de la culture de lorganisation.
IMA Implementation Management Associates, Inc. Lakewood, Etats-Unis, 1998
[5] valuation des sponsors. IMA Implementation Management Associates, Inc. Lakewood,
tats-Unis, 1998.
[6] Test de stress organisationnel. IMA Implementation Management Associates, Inc. Lakewood, tats-Unis, 2000.
[7] valuation des agents de changement. (1998).
IMA Implementation Management Associates, Inc. Lakewood, tats-Unis, 1998
[8] L. Bass, P. Clements & R. Kazman : Software architecture in practice (2 nd ed.) ;
Boston, Pearson Education Inc., 2003
[9] D. Garlan, R. Monroe & D. Wile : Acme: An
architecture description language ; Computer Science Department, Carnegie Mellon
University, 1997
[10] Office qubcois de la langue franaise.
Le grand dictionnaire terminologique.
http://www.grandictionnaire.com. (Consult
le 13 septembre 2006)
[11] Wikipedia. http://fr.wikipedia.org. (Consult
le 10 aot 2006)
[12] R. Kazman, M. Klein & P. Clements : ATAM:
Method for architecture evaluation. ; Techni-

UN GUIDE DE MIGRATION DARCHITEC-

TURE LOGICIELLE

Dvelopper un guide de migration qui tienne

compte des leons apprises lors des migrations prcdentes et qui contiendrait les indications prcises
sur la procdure de migration. Ce guide pourrait
contenir de linformation numre au tableau X.
7.4 DFINIR

UN PLAN DE MIGRATION

Dfinir un plan de migration qui favorise lutilisation des apprentissages et de lexprience acquise
lors des migrations prcdentes. Afin de faciliter la
migration, on pourrait tablir un plan de migration
qui inclurait les lments suivants :
Analyse et spcification de la migration :
- Identification des principaux changements
effectuer ;
dveloppement de la dmarche de migration :
- pour chaque module, identification des changements, dtermination des processus, de procdures et des tapes suivre pour la
migration ;
- dfinition de la documentation de migration
o il sera indiqu la dmarche qui doit tre suivie lors de la mise en uvre de la migration ;
- dveloppement des outils ncessaires la migration ;
formation technique, en indiquant les modifications aux composants logiciels, les changements
qui doivent tre faits au niveau du code, de la
configuration ou du systme en gnral ;
excution de la migration, incluant la modifica-

53

7.1 PROMOUVOIR

8. CONCLUSION
La russite dune migration logicielle ne dpend
pas que de la technologie, mais aussi des processus
de gestion et de gestion du changement ainsi que
dune bonne utilisation des ressources humaines
et matrielles. Malgr lexposition aux risques, une
migration darchitecture logicielle peut tre matrise grce aux habilets des gestionnaires et
leur expertise dans la gestion de projet. De plus,
lintgration active et la distribution des responsabilits dans lquipe de dveloppement permettent cette dernire de simpliquer davantage dans
le changement mettre en place et dassurer sa
russite.

GNIE

LOGICIEL

82

SEPTEMBRE

2007

RETOUR DEXPRIENCE

[13]

[14]

[15]

[16]
[17]

[18]

[19]

[20]

[21]

[22]

[23]

[24]

[25]

[26]

cal Report. CMU/SEI-2000-TR-004. Carnegie

Mellon. Software Engineering Institute, 2000.
M. Klein, R. Kazman, L. Bass, J. Carrire,
M. Barbacci et H. Lipson : Attribute-based
architecture styles ; Software Architecture,
Proceedings of the First Working IFIP Conference on Software Architecture, 1999.
M. A. Ct, W. Suryn, R. Martin et C. Y.
Laporte : Evolving a corporate software
quality assessment exercise: A migration path
to ISO/IEC 9126 ; Software Quality Professional, vol. 6, n 3, ASQ, 2004.
ISO/CEI 9126 -1, Software Engineering
Product Quality - Part 1: Quality Model,
2001, Organisation internationale de normalisation/Commission lectrotechnique
internationale, Genve,Suisse.
Unified Modeling Language. http://www.uml.
org. (Consult le 20 novembre 2006)
IBM Rational Software. http://www306.ibm.com/software/rational. (Consult le
20 novembre 2006)
Borland Together. http://www.borland.com/
us/products/together/index.html. (Consult
le 20 novembre 2006)
L. Kontogiannis, J. Martin, K. Wong, R. Gregory, H. Mller & J. Mylopoulos : Code
migration through transformations: An experience report ; Universit de Victoria, Universit de Toronto.
D. Dikel, D. Kane et J. R. Wilson : Software
architecture, organizational principles and
patterns (1st Ed.) ; N.J., Prentice-Hall Inc.,
2001
I. Jacobson, M. Griss et P. Jonson : Software
reuse: Architecture, process, and organization for business success ; New York, ACM
Press, 1997
ISO/IEC 12207: 1995. Standard for Information Technologie - Software life cycle processes - Implementation considerations, avril
1998.
The Standish Group. The CHAOS Report
(1994) . http://www.standishgroup.com/
sample_research/chaos_1994_1.php. (Consult le 12 novembre 2006)
KMPG. Que sest-il pass ? Lchec des
projets de technologie de linformation ,
1997. http://www.kpmg.ca. (Consult le 12
novembre 2006)
Organisation de coopration et de dveloppement conomiques (OCDE) : Gestion
des grands projets dinformatisation dans le
secteur publi : dfinitions et concepts .
http://www.oecd.org/document/41/0,2340,fr_2
649_37441_1916393_1_1_1_37441,00.html.
(Consult le 12 novembre 2006)
M. J. Christensen et R. H. Thayer : The project managers guide to software engineerings best practices (1st Ed.) ; IEEE Computer
Society, 2001

[27] ISO/IEC 12207.0: 1996. Standard for Information Technologie - Software life cycle processes. 1996.
[28] C. Morley : Management dun projet systme dinformation (4e d) ; Paris : ditions
Dunod, 2004
[29] R. Agarwal, M. Tanniru et D. Wilemon : Assimilating information technology innovations:
Strategies and moderating influences ; IEEE
Transactions on Engineering Management,
vol. 44, n 4, novembre 1997.
[30] M. R. Barbacci et R. Kazman : Software
Architecture Evaluation Panel ; Software
Engineering Institute, Carnegie Mellon Univerity.
[31] M. Corrales, Y. Corrales, M. Foisy et H.
Zaky : valuation du niveau de maturit de
lorganisation. valuation du processus de
migrations technologiques et son impact dans
lquipe de dveloppement ; cole de technologie suprieure, 2004
[32] The Standish Group ; http://www.standishgroup.com. (Consult le 12 novembre 2006)
[33] L. Zhu L., M. Ali Babar et R. Jeffery : Mining patterns to support software architecture
evaluation ; National ICT Australia Ltd. et
University of New South Wales, Australie.
[34] L. Zhu, M. Ali Babar et R. Jeffery : A framework for classifying software architecture evaluation methods ; National ICT Australia Ltd.
et Universit de New South Wales, Australie.
NOTES

1 Entirement en franais
2 Marque enregistre ou inscrite sur le Registre
des marques de commerce par lUniversit Carnegie Mellon de Pittsburgh.
3 Framework est traduit en franais par logiciel intgr : logiciel dapplication qui combine sur un mme support les logiciels courants
dun bureau [10]. Ce terme est utilis dans le
prsent article pour en faciliter la comprhension.
4 Rseau fdrateur, traduction de langlais backbone dfini comme la partie centrale sur
laquelle repose un rseau de tlcommunication
caractris par son haut dbit, qui permet dinterconnecter des rseaux plus petits, lintrieur
dune entreprise, dune rgion ou de vastes territoires [10].
5 Une cl trangre est un champ de base de donnes de type cl primaire inscrit dans une table
secondaire ou table fille permettant la jointure
la table primaire ou table parent [11].
6 Le modle de communication est le moyen utilis
pour classifier et identifier comment linformation est gre dans la communication.
7 Proxy traduit en franais par serveur mandataire : lment de coupe-feu servant dintermdiaire entre le navigateur dun internaute
utilisant un rseau local et le serveur Web quil

54

GNIE

LOGICIEL

82

SEPTEMBRE

2007

RETOUR DEXPRIENCE

veut consulter, permettant ainsi de sortir du rseau

local et dy entrer, sans mettre en danger la scurit de ce dernier [10].

8 Load balancing est traduit en franais par

quilibrage de charge : distribution de tches
ou de communications au sein dun rseau pour
en amliorer les performances.

L'AFTI - Depuis sa cration en 1991, l'AFTI a pour vocation d'accompagner les jeunes diplms vers un premier emploi dans une entreprise de
haute technologie.
Implant Orsay en rgion parisienne, le Centre de Formation d'Apprentis AFTI propose aux
jeunes une solution qui concilie une monte en comptence dans des domaines particulirement pointus avec une relle exprience professionnelle.
De plus en plus d'entreprises leaders sont partie prenante de cette nouvelle dynamique :
Thales, Renault, Alcatel-Lucent, France Telecom, MBDA, Osiatis, SFR, ATOS Origin sont
membres de l'AFTI. Plus largement, une centaine de socits, dans des domaines les plus
divers, sont au cur du projet ducatif. Toutes partagent le mme niveau d'exigence professionnelle et l'ambition de participer activement la monte en puissance des jeunes
embauchs.
L'Ingnierie logicielle et l'alternance - L'ETGL est la formation d'ingnieur logiciel de l'AFTI.
Elle propose l'apprentissage par alternance sur deux ans. Le rythme, 5 mois en centre de formation puis 7 mois en entreprise sur les deux annes, est ajust au cycle de vie de production
logiciel et choisi pour son efficacit. Il permet aux entreprises de se doter d'ingnieurs logiciel
adapts leurs exigences oprationnelles.
La Formation - Les formations sont de type professionnelles, par modules de 2 7 jours.
ct des techniques et langages de base (de l'assembleur, C#/.Net en passant par la conception objet et J2E), l'apprenti dcouvre et applique les mthodologies (gestion de projet, de
configuration sous ClearCase, des exigences sous DOORS, CMMI, revues de pairs). Les formateurs sont issus des entreprises, et chaque formation est ainsi l'occasion de lier un contenu
une exprience vcue. Au del des travaux pratiques, ce sont les projets, rpartis sur la priode, qui permettent aux apprentis de mettre en application leurs connaissances pour en faire
de vraies comptences. Ils apprhendent ainsi l'ensemble du cycle de dveloppement, mais
aussi, lors de jeux de rle, les diffrentes responsabilits (interfaces, planification, qualit,
configuration, recette client).
Les missions confies - Les missions confies par les entreprises sont varies. Si la premire
priode dbute souvent par de la maintenance logicielle (corrective ou volutive) et de l'IHM,
les entreprises n'hsitent plus confier les spcifications et la conception un apprenti ETGL,
ou un dveloppement logiciel complet, une recette client
L'Ingnierie Systme - L'ETGL prend galement en compte l'volution vers l'ingnierie systme, au travers d'une option, propose sous forme de projet. En partenariat avec le
CNES/PlanteSciences, l'AMSAT et l'IUT de Ville d'Avray, les apprentis doivent lancer un ballon
atmosphrique. Ils disposent ainsi d'un vrai client, vrai co-traitant et vrai sous-traitant, pour un
projet o le matre mot est la multidisciplinarit (environnement, mcanique, lectronique,
logiciel).
Contact - www.cfa-afti.com
frederic.van-lauwe@thalesgroup.com (responsable pdagogique)
murielle.trindade@thalesgroup.com (relations entreprises)

55