que peut-on offshorer dans une dsi ? page 6 · projet • suivre l’évolution de la...

LA RÉFÉRENCE TECHNIQUE DES PROFESSIONNELS DE L'INFORMATIQUE

n°69

Bim

estr

iel -

sep

tem

bre

/oct

ob

re20

07 -

16€

QUE PEUT-ON OFFSHORERDANS UNE DSI ? PAGE 6

La qualité intrinsèquedes applications dansles contrats de servicePAGE 22

Le « backsourcing » : lorsque l’externalisationn’est pas utilisée avec précaution…PAGE 35

Etat de l’art de la convergence : lien entreinformatique et téléphonie PAGE 47

Assurer le succès des projets avec la TierceRecette Applicative PAGE 41

EN SAVOIR PLUS

Demandez le Livre Blanc rédigé par leGartner Group et CAST sur ce thème :« Information Series on ApplicationManagement » :www.castsoftware.com/outsourcing

Découvrez l’expérience de plusieurssociétés utilisatrices de solutionsd’Application Intelligence :www.castsoftware.com/customers

ZOOM OUTSOURCING

L’AVIS DES DIRECTIONS INFORMATIQUES

Ministère des FinancesDirection Générale des ImpôtsNadine ChauvièreSous-Directrice des SI de la DGI

« Les solutions d’Application IntelligenceCAST nous aident à obtenir une meilleure visi-bilité de notre parc applicatif au travers detableaux de bord composés d’indicateurstechniques objectifs afin de faciliter le dialogueavec les équipes et avec nos maîtrises d’ou-vrage. »

Groupe SFR CegetelEric EteveDirecteur InformatiqueCentre Ingénierie Mobilité

« La solution CAST de gestion de la sous-traitance est un élément clé dans le systèmede pilotage mis en place par SFR-Cegetelsur ses TMA. Nous avons constaté uneattention plus particulière apportée par lesSSII à la qualité des livrables et à la fiabilitédes chiffrages depuis qu’ils savent que nouspouvons facilement les auditer »

Framatome - Groupe AREVAMichel FondevioleDSI de Framatome-ANP

« CAST fournit des critères objectifs d’appré-ciation dans le dialogue parfois difficile avecle sous-traitant ainsi que des indicateursnécessaires au suivi de l’évolution des appli-cations et constitue au sein de Framatomeun outil de progrès partagé. »

Les entreprises, devenues plus mûres

vis-à-vis de l’outsourcing, sont désor-

mais capables d’opérer des externali-

sations plus stratégiques. On l’a récemment

observé dans l’automobile avec Renault ou dans

la grande distribution avec Carrefour.

Dans l’externalisation des applications métier,

c’est surtout la volonté d’accroître l’efficacité

opérationnelle de l’informatique qui est motrice :

pouvoir fournir plus rapidement un service à

valeur ajoutée aux utilisateurs et aux clients dans

un contexte en perpétuelle évolution.

Comme dans n’importe quelle opération d’out-

sourcing, le contrat liant le fournisseur est capi-

tal, en particulier les SLAs. Néanmoins, les

applications métier étant par nature soumises à

de fréquents changements en cours de contrat,

les seuls SLAs se révèlent vite insuffisants pour

garantir la qualité de service et éviter les dérives

de coûts.

C’est là que le bât blesse : l’externalisation des

applications métier occasionne un risque de

perte rapide de savoir-faire technologique et

par conséquent critique. Vigilance et suivi sont

de mise pour garder le contrôle de la qualité

de service et éviter les dépendances par nature

dangereuses.

L’externalisation réussie d’applications métier

est donc le fruit d’une vision anticipatrice parta-

gée avec le prestataire. Sont ainsi apparues

des solutions dites d’Application Intelligence,

basées sur une technologie avancée d’analyse

de code source.

En fournissant des indicateurs techniques aux

donneurs d’ordre, ces solutions permettent de

piloter un parc applicatif sous-traité en temps

réel, tant en terme de qualité, que de maintena-

bilité et de coût. Résultat : le donneur d’ordre

conserve la maîtrise intellectuelle de ses appli-

cations métier et le contrôle de la relation avec

son sous-traitant.

La valeur ajoutée de ce type de solutions d’Ap-

plication Intelligence est visible à chaque étape

d’une opération d’outsourcing, comme décrit

ci-après.

Audit de l’existant et préparation des appels

d’offres

• Déterminer les caractéristiques techniques

du portefeuille applicatif existant avant de le

sous-traiter

• Disposer d’informations de référence pour

évaluer les propositions des sous-traitants

• Obtenir une image à l’instant t des applica-

tions pour permettre un suivi dans le temps

Transfert vers le prestataire

• Réduire la phase d’acquisition de la

connaissance pour entreprendre plus vite

des tâches productives

• Diminuer le coût lié à la production d’une

documentation exploitable et maintenable

par le prestataire

Contrôle de la qualité et des coûts en cours de

projet

• Suivre l’évolution de la maintenabilité et de

la qualité pour éviter toute dérive

• Etre capable de valider la quantité et la qualité

du travail facturé

• Etre en mesure de challenger le sous-trai-

tant lors des négociations d’avenants

• Industrialiser les recettes techniques

Renouvellement de contrat, transfert ou ré-inter-

nalisation

• Déterminer et qualifier les écarts entre la

prestation prévue et les livrables recettés

• Disposer des informations techniques

caractéristiques du portefeuille applicatif en

fin de prestation

Le leader mondial de ce type de solutions est

d’ailleurs un éditeur français, CAST. Reconnu

par les analystes informatiques comme pré-

curseur du marché, CAST compte plus 500

comptes utilisateurs de sa plate-forme d’Appli-

cation Intelligence dans le monde.

La maîtrise des applicationset des prestataires dansune opération d’outsourcing

Cycle de vied'une opération d'Outsourcing

Suivi de proje

t Contrôle des coûts

Transfert de connaissances

Fin de

contrat Appels d'offres

Rece

tte te

chni

que

www.castsoftware.com

Publi-Reportage

De la valeur ajoutée de l’ApplicationIntelligence pour piloter efficacementun parc applicatif sous-traité

Edito

4 IT-expert n°69 - septembre/octobre 2007

Nouvelle tête, mais Canal HistoriqueComme vous pouvez le constater, la photo ci-contre a changé. Et pour cause : un nouveaurédacteur en chef coordonne les articles d’IT-expert. Un changement dans la continuité. Eneffet, il ne s’agit nullement de marquer une forterupture, mais de choix personnels. C’est pour-quoi nous nous efforcerons de maintenir le très

bon niveau d’expertise qui fait la réputation d’IT-expert, auquel colla-borent volontiers les meilleurs spécialistes. Une posture indispensablepour répondre de façon pertinente aux attentes d’un lectorat légitime-ment exigeant. Bref : un œil nouveau et expérimenté, mais dans lalignée historique. Notre objectif : répondre aux questions des respon-sables informatiques, afin que nos lecteurs disposent d’un outil d’aideà la décision qui soulève les bonnes questions et propose des répon-ses d’experts de terrain.

L’offshore sans tabouDossier polémique s’il en est, l’offshore informatique soulève l’indigna-tion de nombre de partenaires sociaux et de certains de nos diri-geants. Pratique répandue depuis plus de trente ans, il se répand chezles éditeurs et profite aujourd’hui de processus perfectionnés. Depuisquelques années, les directions informatiques tentent elles aussi cetteaventure, via sociétés spécialisées ou des SSII françaises. Dans cedossier « Offshore », au-delà des polémiques sociales ou politiques(également abordées), nous souhaitions expliquer comment se passeconcrètement ce type de projet. En effet, il nous a semblé intéressantd’examiner l’opérationnel, les limites et les enjeux de cette tendancede plus en plus incontournable. Des éléments indispensables pouranalyser la pertinence d’une solution possible, ou pour l’écarter. Carl’auteur aborde ce sujet sans tabou, expliquant même dans quels casun projet peut se révéler éligible. Sujet voisin, la rubrique « Quoi deneuf docteur ? » se penche sur le backsourcing, épine douloureuse del’externalisation. Enfin, Jean Mounet, président du Syntec Informatiqueet vice-président de Sopra, explique pourquoi il considère l’offshorecomme une évolution majeure.

Un numéro très complet et utile, à lire, à relire et à conserver. Nousespérons qu’il vous aidera à mieux comprendre et décrypter les tech-nologies et les pratiques, et de vous ouvrir toujours plus d’horizons.Car la conduite informatique a cela de commun avec un voyage envoiture : on est bien plus serein quand on sait où l’on va, et que l’ondispose de plusieurs alternatives pour l’itinéraire.

José DizRédacteur en Chef

édito

EditeurPress & Communication FranceUne filiale du groupe CAST3, rue Marcel Allégot92190 Meudon - FRANCETél. : 01 46 90 21 21Fax. : 01 46 90 21 20http ://www.it-expertise.comEmail : [email protected]

Rédacteur en chefJosé DizEmail : [email protected]

Directeur de publicationAurélie MagniezEmail : [email protected]

Abonnements/PublicitéEmail : [email protected]

Conception GraphiqueC. GrandeEmail : [email protected]

ImprimeurMoutot Imprimeurs

ParutionIT-expert - (ISSN 1270-4881) est un jour-nal édité 6 fois par an, par P & C France,sarl de presse au capital de 60 976,61 €.

AvertissementTous droits réservés. Toute reproductionintégrale ou partielle des pages publiéesdans la présente publication sans l’auto-risation écrite de l’éditeur est interdite,sauf dans les cas prévus par les arti-cles 40 et 41 de la loi du 11 mars 1957.© 1996 P&C France. Toutes les marquescitées sont des marques déposées.Les vues et opinions présentées danscette publication sont exprimées par lesauteurs à titre personnel et sont sous leurentière et unique responsabilité. Touteopinion, conseil, autre renseignement oucontenu exprimés n’engagent pas la res-ponsabilité de Press & Communication.

Abonnements01 46 90 21 21Prix pour 6 numéros (1 an)France ; U.E. : 89 € TTCDom TOM, Autres Pays : 128 € TTC

Un bulletin d’abonnement se trouveen pages 29/30 de ce numéro.

Vous pouvez vous abonner surhttp://www.it-expertise.com/Abonnements/Default.aspxou nous écrire à[email protected]


IT-expert n°69 - septembre/octobre 2007

5IT-expert n°69 - septembre/octobre 2007

SommaireDossierQue peut-on offshorer dans une DSI ?Après un bref rappel des positions en France sur le sujet, le dossier aborde l’offshore à tra-

vers des cas concrets, afin de déterminer les étapes indispensables et de mesurer les gains

et les bénéfices. Si l’on débat souvent de l’offshore comme arme concurrentielle des SSII, le

tabou demeure concernant les DSI. C’est pourquoi, fort de son expérience de terrain, l’au-

teur démontre la pertinence stratégique de l’offshore dans une DSI et liste même des critè-

res d’éligibilité des projets.

TechniqueLa qualité intrinsèque des applications dans les contrats de serviceLes contrats de prestation de services informatiques de développement intègrent des clau-

ses concernant les délais et des niveaux de performance fonctionnelle. Mais le plus souvent,

rien sur la qualité intrinsèque du code source livré. Pourtant, une telle démarche bénéficie-

rait non seulement à la solution et au commanditaire, mais aussi au prestataire. Une belle

démonstration accompagnée de règles et de conseils incontournables.

Actualités InternationalesLes informations marquantes d’éditeurs, de marchés, d’organismede standardisation, de débats en cours et de tendances.

Quoi de Neuf Docteur ?Le « backsourcing » : lorsque l’externalisation n’est pas utilisée avecprécaution…Lors d’une externalisation qui ne tient pas ses promesses, l’entreprise est le plus souvent

amenée à ré-internaliser. Après un aperçu sans concession des risques de l’externalisation,

l’auteur apporte ses conseils pour une bonne gouvernance dans ce type de projet.

Comment ça Marche ?Assurer le succès des projets avec la Tierce Recette ApplicativeEn confiant à un prestataire spécialisé la recette d’applications existantes à traversun contrat forfaitaire, l’entreprise mutualise les outils de test et de pilotage, lesressources et les méthodologies quel que soit le projet.

Fenêtre sur courInterview de Jean MOUNET, Président du SYNTEC Informatiqueet Vice-Président de Sopra Group« Le projet « idéal » est une TMA stable sur de gros volumes et que l’on souhaite offsho-

rer pour une durée de 3 à 5 ans. » Pour le président du Syntec Informatique, le temps du

tabou de l’offshore dans les DSI est révolu. Il constate que la France, recherchant une

proximité linguistique, se tourne de plus en plus vers le Maghreb ou la Roumanie. Seu-

lement 3 % du volume global des services informatiques sur un potentiel que Jean Mou-

net estime de 12 % à 15 %.

LivresConduite de projets informatiques offshore par Éric O’Neill chez Eyrolles, et Manager un

projet informatique par Sophie Fernandes et Olivier Englender aux Éditions d’Organisation.

Rubrique à bracEtat de l’art de la convergence : lien entre informatique et téléphonieL’auteur montre comment les trajectoires des innovations informatiques et en télécommu-

nications ne pouvaient que se croiser pour fusionner. Puis, il expose les impacts des com-

munications unifiées sur les utilisateurs, mais aussi sur les équipes informatiques. Une

perspective intéressante qui donne du sens.

6

22

31

35

41

44

46

47

Dossier & Interviews


Que peut-onoffshorer dansune DSI ?

OFFSHORE IT : La France est-elle protégée ou en retard ?

En retenant la définition du Syntec, l’offshore correspond à des services consommés enFrance et réalisés à l’étranger.

La part de l’offshore est estimée à environ 2 à 3 % de l’activité IT en France. C’est de 3 à 5fois moins qu’en Allemagne, Belgique, Pays-Bas… et surtout qu’en Angleterre.Cette estimation traduit un retard d’environ 7 ans par rapport à la Grande Bretagne qui aintégré le modèle offshore depuis plus de 10 ans, notamment avec l’Inde, l’Afrique du sud,les pays de l’Est (Roumanie, Pologne…).

En échangeant avec les DSI, plusieurs éléments d’explication sont évoqués :• Le rapport entre les taux pratiqués en offshore et les taux « locaux » n’est pas représen-

tatif des économies potentielles, celles-ci étant difficiles à chiffrer et parfois (au mieux)inexistantes dans certains cas.En tout cas, elles sont suffisamment incertaines pour rester encore prudents.Cette analyse est d’ailleurs partagée hors de nos frontières : d’une enquête effectuéeauprès des 10 entreprises les plus importantes pratiquant l’offshore aux Pays-Bas, il res-sortait que « elles (ces entreprises) ont l’impression de gagner de l’argent, mais sont inca-pables de mesurer combien ».

L’Inde superpuissancede l’Offshore

Avec son milliard d’habitants, ses 18langues principales, 28 états ayantchacun leur propre administration,l’Inde est un pays de contraste danslequel il est difficile de s’y retrouversans y être préparé.

C’est d’abord un marché en pleinecroissance : 8 à 9 % par an, tirée engrande partie par les 30 % de crois-sance du secteur IT. La classemoyenne représente 160 millionsd’habitants.

A la traîne dans nos échanges bilaté-raux (2,1 Md € d’importations pour1,8 d’exportations, l’Inde n’est quenotre 40ème client), la France vise undoublement des échanges d’ici 2010.

Dans le domaine de l’IT, l’Inde reven-dique une position de « centre de res-sources mondial », au même titre quela Chine se positionne comme« l’usine du monde ».

L’Inde se caractérise par ses colossalessociétés IT (Infosys en croissance de45 % par an depuis 5 ans).Les 15 pre-mières représentent 70 % du marchéIndien. Les plans de recrutement deTata Consulting Services, Wipro,Satyam… se chiffrent par « paquet »de 10 000 informaticiens.Leur profita-bilité est forte et elles disposent d’ail-leurs d’une trésorerie telle qu’ellesapparaissent désormais comme desprédateurs potentiels.Elle dispose d’unsystème éducatif performant : tous lesans, l’Inde met sur le marché plus de400 000 ingénieurs,c’est plus que tou-tes les ressources des sociétés de ser-vices informatiques en France. Sonouverture sur le monde se lit dans leschiffres suivants :actuellement,80 000étudiants poursuivent un cursus supé-rieur aux US, 17 000 en Grande Breta-gne… et à peine 1 000 en France !

Même si elles ne sont encore que peunombreuses, des sociétés IT compo-sées d’Indiens francophones com-mencent à prendre position sur lemarché Français et atténuent l’unedes barrières majeures au dévelop-pement de l’offshore en France : lalangue.


• Les échecs récents et médiatisés de grands contrats d’externalisation : ils ont indirec-tement « ralenti » les DSI. Face aux difficultés d’un montage d’externalisation, ils ne sou-haitent pas ajouter celles qui consistent à travailler avec un partenaire dont les forcessont en dehors de France.

• Les difficultés concrètes (linguistiques et culturelles) à travailler avec des équipes distan-tes sont fortes, beaucoup plus que pour nos collègues anglo-saxons.

• Enfin, travailler actuellement avec des pays « low cost » véhicule aujourd’hui une imagenégative, tant sur les aspects qualité, sécurité des données et protection du savoir faire,et également une « culpabilité sociale ».

Ces impressions sont d’ailleurs reçues 5 sur 5 par les opérateurs eux-mêmes, notammentles grandes SSII indiennes (voir l’encart sur l’Inde). Comme l’indiquait Monsieur KapilSIBAL, Ministre Indien des sciences et technologies, lors de son récent passage à la mai-son de l’ESSEC : « Il est extrêmement difficile, pour une société étrangère, notamment horsde l’Europe, de faire du business en France ».

Dans le domaine IT, la faiblesse du marché français, et globalement la difficulté de péné-tration n’encourage pas les opérateurs offshores à être aussi agressifs qu’ils le sont ailleurs.

Dans ce paysage où la France fait figure d’exception, les DSI sont pris en tenaille entre deuxconduites à tenir vis-à-vis de l’offshore ; à la fois défensive parce qu’il s’agit de repousser le plustard possible l’expérience offshore, mais aussi audacieuse afin d’anticiper le modèle offshorepour être prêt « au bon moment ».

Une façon de répondre, c’est de constater que les DSI se voient parfois imposer un modèleoffshore par leur DG ou leur DAF, parce que, sur d’autres secteurs d’activités, l’entreprisea réalisé des gains importants.

Plutôt que de traiter le sujet de façon théorique, nous avons fait le choix de l’illustrer concrè-tement au travers d’expériences vécues. L’ambition n’est pas de dégager Une vérité, maisde donner des points de repère, des pistes de recommandations pratiques pour les DSI etleurs équipes.


Les retours d’expérience cités concernent des entreprises des secteurs de la distribution,de la banque, et de l’industrie. L’effectif IT est de plusieurs centaines de personnes. Lesexpériences décrites ont été effectuées en relations directes avec des prestataires offsho-res, ce qui rend les témoignages cités particulièrement concrets.

Nous nous sommes toutefois engagés à garder confidentiels les cas cités pour des raisonsmultiples : bilan non encore établi, résultat non atteint, risque de perturbation sur le dialoguesocial en cours

Histoires vécues : deux cas concrets d’offshore

L’histoire d’un projet

Prenons l’exemple d’une DSI n’ayant jamais travaillé en mode offshore.

Pour mettre en œuvre un programme ambitieux, support à la mise en œuvre de sa straté-gie, la Direction Financière « propose » au DSI de réaliser un premier projet en offshore.Cette décision est guidée par la nécessité d’accroître le nombre de projets à engager alorsmême que l’enveloppe budgétaire est réduite : la solution offshore apparaît comme la pluscrédible pour atteindre l’objectif.

Ce premier projet constitue le socle du futur SI commercial et vise à intégrer et gérer le référen-tiel de données de gestion commerciale. Au niveau technologique, le projet s’appuie sur uneplateforme expérimentale de développement de services web.

N’ayant aucune expérience de ce type de projet, cette DSI s’appuie sur une société offshorequi propose une équipe répartie sur 2 sites : une direction de projet réduite en France (un Directeur de projet à temps plein), et une équipe de développement en Inde.

L’organisation est présentée sur le « schéma ci -dessous ».

Pilotage

Spécifications Recette

Pilotage

Adaptations/traduction

Pré-recette

Pôle fonctionnel

Pôle de test

Pôle de développement

Pôle technique

OffshoreKick off

Trav

aux

Off

sho

re"p

ivo

t"Tr

avau

x su

r si

te"o

n sh

ore

"

Un modèle d'organisation : client/"pivot"/offshore

« Les problèmes

rencontrés ne remontaient

pas lors des instances

de pilotage mises

en place :

il a été nécessaire

in fine de se rendre sur

place pour les découvrir. »


La coordination est assurée via des téléconférences quotidiennes, hebdomadaires (comitéprojet opérationnel), bi mensuelles (comité contractuel).

Les principales difficultés concrètes rencontrées ont été les suivantes :• Les équipes de développement se sont heurtées à des difficultés techniques, certaines

prévisibles (maîtrise de la plateforme de développement), et d’autres totalement inatten-dues, par exemple l’installation initiale des serveurs de développement.

• Maîtrise du fonctionnel : la complexité de certaines règles de gestion ainsi que lesbesoins de traduction ont alourdi les processus de gestion des questions, précisionsfonctionnelles…Finalement, la réactivité attendue de l’offshore du fait du décalage horaire (l’un desarguments des opérateurs : « les anomalies transmises le soir sont corrigées pendantla nuit ») n’a pas été au rendez-vous, bien au contraire.

• Méthodologie de test : après plusieurs livraisons de qualité insuffisante, l’équipe projets’est rendue compte que les développeurs ne procédaient pas aux tests unitaires. Ilsétaient à la charge d’une équipe de test dédiée, moins qualifiée. Pour respecter desdates de livraison, certains composants étaient livrés sans aucun test.

• De sérieux problèmes de reporting ont été rencontrés, dus à la fois à la distance maiségalement aux différences culturelles.

• Enfin, le turn-over des équipes a atteint 50 % 1 sur la durée du projet, y compris sur lespostes d’encadrement : mis devant le fait accompli, le client avait à ré expliquer le pro-jet aux nouveaux arrivants…

Au final, le projet a coûté plus cher que s’il avait été conduit avec un prestataire en France.Les délais estimés initialement (avec optimisme toutefois) à 3 mois ont été en réalité de plusde 18 mois, faisant prendre un retard au moins équivalent au programme associé.

A l’inverse, les sources de difficultés ayant été localisées, ce même client a poursuivi avecsuccès ce mode de travail par la suite. Il a toutefois travaillé en direct avec les équipes dedéveloppement, assurant lui-même les tâches et le rôle de « pivot ».

Il ne faut pas, au vu du tableau dépeint, considérer hâtivement le modèle comme inopéranten France, mais ne nous masquons pas des difficultés qui se retrouvent d’une expérienceà l’autre.

L’histoire d’une TMA

La TMA représente un réel enjeu pour les opérateurs offshore. C’est en effet l’activité quileur permet de décrocher des marchés importants, ces contrats faisant souvent boule-de-neige : les compétences acquises dans un contexte client étant réutilisées rapidementpour d’autres clients sur le même contexte.

Il ne faut pas s’étonner de trouver, chez les opérateurs offshore des compétences en grandnombre à la fois sur les ERP leaders (SAP…) mais également sur des « niches fonctionnel-les » telles que sur les progiciels de pilotage, de gestion de projet…

Offshorer sa TMA, c’est additionner les caractéristiques d’un projet d’externalisation et cel-les de collaborer avec un prestataire offshore.

Le cas décrit correspond à la mise en œuvre d’une opération pilote offshore. L’objectif ini-tial est de renforcer l’équipe support face à un accroissement important du champ fonction-nel supporté (gestion financière et technique des projets de recherche pour la DirectionR&D).

Le choix a donc été de confier à un grand opérateur indien les tâches courantes prises encharge par une équipe actuellement de 5 personnes. Dans un premier temps, les tâches degestion d’incident, de problèmes et de changement, l’exploitation « standard », les travaux

« L’installation initiale

du serveur de

développement, opération

qui prend normalement

2 jours, n’avait pas

été effectuée après

2 mois de travail,

alors que l’on pensait

les développements

très avancés ! »

1] Ce taux de turnover n’est pas hors norme. En moyenne de 30 % en Inde, il atteint 50 à 60 % à Bangalore, baptisée la« Silicon Valley Indienne ». Il est également très important dans les pays nearshore du fait de l’accroissement de la demande.


à la demande (production d’états spécifiques…), puis dans un second temps, la gestion deconfiguration, la gestion de version.

L’équipe offshore, de 7 personnes, a passé 4 mois sur le site client dans l’optique d’êtreopérationnelle à l’issue de cette période de transfert de connaissance.

Cette opération présente des complexités multiples, notamment de transférer environ 150compétences (business, techniques, processus de support…) à une équipe dont c’était -pour la plupart - le premier déplacement hors de leur pays.

La clé du succès a été de traiter cette première étape en mode projet, avec notamment unealternance de formations, d’exercices, de « training », et d’activités permettant en définitivede faire fonctionner les équipes ensemble, avec respect et reconnaissance mutuelle desqualités de chacun.

Votre projet est-il éligible ?

L’histoire du projet décrite précédemment a le mérite de mettre en évidence des difficultésdiverses. En ce sens, elle présente un caractère très pédagogique !

Une première règle (de bon sens) que nous évoquait un Directeur de projet Offshore dansle secteur pharmaceutique est : « don’t outsource your problems ! ».

Appliquée aux projets IT, il est plus facile de confier en offshore un projet que l’on sauraitparfaitement maîtriser en interne plutôt qu’un projet qui présente des innovations, l’expé-rimentation de nouveaux outils de développement par exemple.

Critères d'éligibilité : le projet…

Met en œuvre de nouveaux outils, une nouvelle architecture, des échanges avec de multiples applications…

Nécessite un travail étroit avec les utilisateurs

Couvre le « cœur de métier », ou l’intégration ERP avec remise à plat des processus

Ne présente pas un caractère répétitif

A des enjeux très forts, les conséquences d’un échec sont importantes pour le business de l’entreprise a un caractère confidentiel

Présente des interactions multiples, en continu

Les équipes sont peu mobiles, insuffisamment préparées,peu motivées par les caractéristiques du projet

Se situe en environnement connu, maîtrisé, il est faiblement intégré à d’autres projets / applications

Ne nécessite pas de fortes interactions avec les utilisateurs : réécriture des legacy, rewamping, migration…

Couvre un domaine « standard » ou des développements autour d’un ERP déjà intégré

Permet de procéder largement par mise au point puis itération

A des enjeux faibles, des solutions de contournement sont prévues et possibles

Nécessite des interactions concentrées à des points clés, relativement faibles

On peut constituer et rendre disponible une partie de l’équipe, elle est mobile, bilingue si besoin, intéressée par le contexte multiculturel

Caractéristiques de votre équipe

Complexité technique

Complexité fonctionnelle

Domaine concerné

Répétitivité – aptitude à être itéré

Enjeu business

Intéractions avec les utilisateurs

« Par ailleurs, la diffusion

de « bonnes pratiques »

(ITIL…) a pour avantage

de « normaliser »

les process. Il est plus

facile de trouver des

prestataires formés

et compétents,

rapidement

opérationnels. »


Dans l’industrie, ce principe est en application depuis longtemps. Les entreprises externa-lisent d’abord les « grandes séries » de produit standard, dont les gammes de fabricationsont connues, maîtrisées, documentées… Les « petites séries » de produits complexesnécessitant un travail important de conception, mettant en œuvre des innovations… sontconservées en interne.

Le degré de formalisation des tâches et d’innovation sont des critères d’éligibilité des pro-jets offshore. D’autres sont présentés dans le schéma 2. Ils ne sont pas nécessairementdéterminants sur la réussite ou l’échec, mais ils donnent un aperçu des risques qui devrontfaire l’objet d’un suivi spécifique.

Ils sont séparés en deux « familles » : les critères intrinsèques au projet et les critères liés à« l’environnement » au sens large.

Concernant l’éligibilité, certaines DSI « matures » ont intégré l’examen systématique de l’al-ternative offshore.

Les principes sont :• La mise en place des grilles de critères personnalisés,• Un premier inventaire de projets « éligibles » lors du processus de scoring annuel du por-

tefeuille de projets,• La création d’un pôle de compétence « offshore », l’un de ses membres participant sys-

tématiquement aux comités mensuels de revue des projets.

Y a t-il une taille « idéale » de projet offshore ?

Bien qu’il soit difficile de généraliser, la taille du projet entre en ligne de compte. Trop petit(moins de 15 m*h), le projet sera fortement dépendant des personnes mobilisées et ne per-mettra pas la mise en œuvre des process standards de management. Il ne couvrira pas toutce que l’on peut attendre d’une expérimentation et aura un « coût d’entrée » important rap-porté à la taille du projet.

A l’inverse, pour un projet de plus de 50 m*h, la prise de risque pourra apparaître trop impor-tante, les conséquences d’un échec trop lourdes à rattraper.

Quelques typologies de projet sont plus fréquemment rencontrées dans des contextesoffshore : revamping d’application, migration des legacy (quasi iso fonctionnel), réalisationde reportings…

Les activités éligibles…

En Grande-Bretagne, aux US, plus généralement dans une culture anglo-saxonne, le raison-nement offshore est intégré dans la gouvernance de l’informatique. Le choix de ce qui est ounon éligible obéit à des critères qui sont plus d’ordre stratégique (par exemple ne pas dévoilerd’avantages concurrentiels) que techniques.

En France, les opérateurs offshores doivent faire leurs preuves. Rien d’étonnant à ce que lesactivités retenues par les clients, et ciblées commercialement par les opérateurs, soientconcentrées sur des activités que l’on accepte plus facilement d’externaliser.Ce sera par exemple la TMA, « incident management », « problem management », « changemanagement », ou le testing : conception et exécution de jeux d’essai, la Tierce RecetteApplicative.

Elles sont en général décrites et appliquées en interne. Elles ne nécessitent pas de fortes com-pétences, voire elles soulagent les équipes internes de travaux perçus comme rébarbatifs.

Les domaines concernés seront plutôt « banalisés », tels la comptabilité, le reporting finan-cier, la « supply chain »…


A l’inverse, la GRH, domaine couramment externalisé, pour la gestion de la paie… est trèsrarement « offshorée » : encore une exception à la française ?

Les gains escomptés : miroir aux alouettes ?

Les travaux supplémentaires

Pourquoi, alors que le taux d’un développeur offshore peut atteindre le quart du TJM pra-tiqué pour le même profil en France, on ne concrétise pas de façon équivalente les écono-mies réalisées sur le budget externe du projet ?

Le premier phénomène qui explique l’écart est l’accroissement important de la charge demanagement de projet côté client (pilotage, contrôle qualité…). Le second est lié à lacourbe d’apprentissage. Comme pour l’introduction d’une nouvelle technologie, les pre-miers projets offshore ne permettent pas de concrétiser les bénéfices dès le premier pro-jet. Tirer le meilleur profit de ce modèle de développement nécessite du temps, enparticulier pour rendre optimum, « fluidifier » les relations entre le client et le prestataire.

Les principaux postes ou activités supplémentaires constatés sont principalement :

Le renforcement du pilotage de la sous-traitance (« controlling » et recettes intermé-diaires) afin d’éviter les effets « boîte noire » potentiellement très préjudiciables dans unprojet offshore :• mise en place des cycles et outillage de pilotage à distance s’ils ne sont pas encore dif-

fusés dans l’entreprise : video conférence ou conf call, gestion collaborative de projet etde livrables…

• audit des processus projet : développement, tests, correction d’anomalies, assurancequalité…

• revues de code (en prévision d’éventuelle reprise en main, de backsourcing)

La rédaction de spécifications adaptées• l’appropriation par un opérateur offshore requiert plus de précisions, une description

plus détaillée et exhaustive des règles de gestion.• la traduction interprétée des « livrables » clés et des supports d’échange : spécifications,

PAQ, fiche anomalie…

Le partage et le fonctionnement des processus transversesEn effet, de nombreux échecs sont dus à un mauvais fonctionnement des équipes dans uncontexte multiculturel : ce qui fonctionne en local ne marche pas nécessairement de lamême façon dans un projet offshore, notamment le mode de management, la mise souspression, l’engagement sur les délais…

Une partie des travaux supplémentaires peut être prise en charge par les prestataires : cer-tains offreurs prennent en charge le lien entre équipes client et leur centre de développe-ment offshore.

Leur prestation peut être plus ou moins complète, jusqu’à rendre quasiment transparent lefait que les développements sont effectués à distance. Encore faut-il vous assurer qu’au-delà du discours commercial les modes de fonctionnement sont réels et que la société peutafficher plusieurs réalisations réussies.

Le cycle du projet offshore

Sur le schéma « un modèle d’organisation », servant de base à l’histoire du projet, lestâches sont réparties selon 3 niveaux : le niveau client (sur site), le niveau offshore et unniveau intermédiaire regroupant les tâches supplémentaires.

« Plus les travaux

supplémentaires sont

intégrés dans l’offre du

prestataire, plus on perd

une partie du bénéfice

escompté. A l’inverse,

plus on travaille en direct

avec les équipes offshore,

plus on optimise le gain ! »

Le jargon de l’offshore

Dans les formes diverses d’externali-sation (« sourcing ») d’activité ou deproduit & service IT, on parle de near-shore et d’offshore pour traduire lerecours à un prestataire basé àl’étranger pour réaliser des travaux etservices qui seront « consommés » enFrance, ces travaux étant initialementà la charge d’équipes locales.

On parle d’offshore dès lors qu’onqualifie les pays éloignés en terme deculture, de décalage horaire, de dis-tance. Pour la France, les prestatairesoffshores se situent en grande majo-rité en Inde. Loin derrière, sans quel’on puisse parler de courant offshoreon va trouver des prestataires enChine, au VietNam, à Maurice, Mada-gascar, en Argentine…

Le nearshore qualifiera des pays« plus proches », ce qui se traduitconcrètement par la possibilité defaire des aller/retour fréquents (parexemple sur 1–2–3 jours). Bien sou-vent, l’existence d’un « tissu » franco-phone, par exemple lié à l’accueil denombreux étudiants étrangers dansnos cycles de formation supérieurs.Pour les entreprises Françaises, onretrouve les pays du Maghreb (Tuni-sie, Maroc) et les pays de l’est (Rou-manie, Pologne…).

Le BPO (Business Process Outsour-cing) couvre des actes métiers (toutou partie de processus) et embarquele système d’information associé. Ilpeut concerner des fonctions variéesde l’entreprise : centres d’appel, backoffice banque/assurance…

Pour être complet, quand la presta-tion dépasse l’exécution formelle d’unprocessus et fait appel à des actionsqui requièrent une forte initiative etdes connaissances, on parle de KPO(Knowledge Process Outsourcing).Quelques exemples : recherche d’an-tériorité dans le domaine des mar-ques & brevets, dataminingservices…


On peut noter que ces 3 niveaux existent dans tous les schémas de projet offshore. Leniveau intermédiaire peut être pris en charge par le client, l’opérateur lui-même, un tiers(société pivot).

Parmi les méthodes appliquées, l’offshore programming permet de limiter l’effet boîtenoire par une transparence sur les compétences mobilisées et la production du résultat paritération. Chaque itération est l’occasion d’un point de convergence entre équipes. Cemode spécifique ne s’applique pas à tous types de projets, mais il sera particulièrementadapté à des projets plus faciles à itérer : migration, revamping…

Evaluation des coûts supplémentaires

L’estimation du surcoût découle de paramètres à la fois techniques (on retrouve les facteursd’éligibilité des projets), mais également d’éléments externes, comme par exemple l’apti-tude des équipes projet, à appréhender, voire inventer des modes de fonctionnement, oul’acceptation par les équipes opérationnelles de ce qui est bien souvent perçu comme unecontrainte.

De ce fait, la variabilité du surcoût est forte. Donc, sans vouloir généraliser, il est intéressant dedonner les chiffrages constatés sur un projet par phase et en global sur les schémas suivants.

Ils donnent des ordres de grandeur et des points de repère sur les surcoûts par type de tra-vaux et sur le surcoût global, avec une séparation entre la part liée au premier projet offs-hore (le « droit d’entrée ») puis l’évolution de cette part « après apprentissage ».

0 20 40 60 80 100 120

coût cible théorique

Représentation des gains potentiels

coût 2ème projet Offshore

coût 1er projet Offshore

développement en local

coût projet (K€)

scén

ario

de

réal

isat

ion

coût équipe localecoût équipe offshoredéplacements

charge 1er projet offshore

Incidences de l'offshore par grande phase

charge 2ème projet offshore

développement en local

charge par phase(rapporté à une base "standard"

de 100 j*h par phase)

scén

ario

de

réal

isat

ion

pilotagerecettespécifications

0 50 100 150 200

« Il est recommandé

de ne pas s’engager

sur un gain immédiat :

le premier projet permet

‘d’essuyer les plâtres’.»

« L’offshore a été une

excellente occasion pour

nous de remettre en

place des rôles précis par

rapport à une culture

« plateau projet » où on

ne voit plus qui fait quoi.

Cela a permis de remettre

de l’ordre et de

réapprendre à écrire

à nos chefs de projet,

à mieux formaliser.

Finalement,

on réapprend à écrire…

en Français ! »


Ces estimations, assorties d’une marge de variation, donnent néanmoins un coup d’arrêtaux idées reçues :• le gain potentiel pouvant être raisonnablement espéré du premier projet offshore est de

l’ordre de 10 % ! soit une valeur inférieure à l’incertitude d’une estimation effectuée aumoment où se prend la décision.

• Après 1 ou 2 projets complets menés par les mêmes équipes, le gain potentiel est de 20à 25 %.

• En cible « théorique », c’est-à-dire en supposant que la performance des équipes est simi-laire à celle constatée pour un développement local, le gain potentiel est de 40 à 45 %.

Le gain potentiel est-il le seul enjeu du modèle offshore ?

Des bénéfices induits

Parmi les raisons qui poussent les DSI à examiner l’offshore, la motivation principale estéconomique. Ces économies prévues permettent soit de maintenir le volume d’activitédans un contexte de budget plus faible ou encore d’augmenter ce volume à iso budget.Parmi d’autres résultats constatés, on note la possibilité de redéployer les forces de déve-loppement internes sur des projets à fort enjeu, comme pour toute forme d’externalisationou de sous-traitance.

Dans certains cas, le choix de l’offshore peut être stratégique s’il correspond à une volontéde l’entreprise de développer son activité à l’international, et notamment dans les pays« low cost ».

De façon plus inattendue, les responsables de pôles de compétences offshores ont notéune montée en compétence significative des équipes sur différentes dimensions :• Amélioration de la qualité de la rédaction de spécifications, du pilotage de la sous-traitance,• Pratique de « l’anglais projet »,• Utilisation de moyens de pilotage à distance (chat, skype, audio et télé conf), plus glo-

balement la conduite de projet en environnement multiculturel…

A noter donc : confier un projet offshore (avec une préparation adaptée des équipes), c’estaussi un atout permettant aux DSI de fidéliser certains chefs de projet de talent…

Quels enseignements tirer ?

Quand on analyse les difficultés rencontrées dans les deux « histoires vécues », on réalisefinalement que ce sont en partie les mêmes que celles que l’on rencontre en sous-traitanceclassique : techniques et fonctionnelles, qualité des livraisons et des tests, conduite de pro-jet, reporting…

Concernant l’offshore, elles prennent des formes inattendues. L’éloignement (distance,horaire, culture) rend les difficultés plus fortes et plus longues à traiter, à la fois pour poserle diagnostic, ainsi que pour mettre en œuvre la résolution.

Quand finalement, un contrat « bien ficelé » et un processus de sélection permettent de(relativement bien) sécuriser une relation avec les fournisseurs habituels, ces dispositionssont insuffisantes pour travailler avec des opérateurs offshores.Les recommandations suivantes permettront de limiter les surprises.

Un terrain préparé

La première recommandation est de ne lancer un projet offshore que si le terrain est pré-paré. On peut parler de degré de « maturité » pour l’offshore. Dans une structure non pré-parée, avec des choix d’équipe interne, de partenaires, parfois effectués trop vite, laprobabilité d’atteindre les objectifs – voire de mener l’opération à bonne fin – est faible.

« Chaque membre

de l’équipe offshore a un

point de contact dans

l’équipe locale (qu’on peut

assimiler à un « coach »).

Ce lien informel permet

à la fois de faciliter

l’intégration dans le

contexte de l’entreprise,

de traiter, par une voie

non hiérarchique les

difficultés rencontrées

et de créer des liens dans

la durée, l’enjeu étant

asservi à l’efficacité de

l’opération et à la

performance

des équipes »

« On ne peut pas se satis-

faire d’un acquiescement

pour valider la bonne

compréhension. Il faudra

confirmer systématique-

ment par écrit dans la

foulée ce que vous

attendez de votre

interlocuteur suite à un

échange, en usant

et abusant du

‘ let me confirm…’ !»


C’est malheureusement un cas fréquent, ce qui contribue à véhiculer l’image plutôt réser-vée que l’on constate au sein des DSI actuellement.

C’est pourquoi, à la question « êtes-vous prêts pour un projet offshore ? », le DSI devra,pour répondre, s’interroger sur deux registres :1. Les processus sont-ils à un stade de maturité suffisant, c’est-à-dire :

• Sont-ils facilement « détachables » de la structure ? Ou bien y a-t-il de multiplesimbrications, une chaîne de responsabilité complexe qui rendent très difficile leurexternalisation ?

• Existe-t-il déjà une logique client/fournisseur dans leur exécution traduite par desengagements de service (SLA), un reporting périodique ?

2. Les esprits sont-ils préparés en ce qui concerne :• La conduite du changement vis-à-vis des équipes informatiques associées ou non

au projet : la résistance vis-à-vis du transfert de connaissance peut nécessitersimultanément, la mise en perspective de projets professionnels.

• Le volet social : les incidences sur les postes et emplois ont-elles été appréhen-dées, préparées ?

Une grille d’éligibilité doit être appliquée pour localiser et évaluer les risques AVANT ladécision. Elle doit, si possible, être discutée avec les donneurs d’ordre métier.

Une phase de lancement spécifique : L’offshore kick off

Une fois le choix offshore décidé, les équipes, locales et offshore, devront être préparéesensemble aux situations et modes de fonctionnement spécifiques qu’elles partageront ensuite.

L’enjeu est de rendre l’équipe offshore (les deux parties) opérationnelle. Dans ce contexte,le transfert de compétences porte sur des dimensions fonctionnelles et techniques dupérimètre applicatif concerné, mais il doit également couvrir d’autres dimensions indispen-sables : business, comportementales…

Ce transfert s’effectue via un plan de formation et d’évaluation spécifique gérée comme unprojet ou une première phase. En effet, les modules de formation « standard » qui existentdans l’entreprise, nécessitent d’être adaptés au contexte offshore.Dans l’exemple TMA cité, pas moins de 150 compétences (donc points d’acquisition) ontété recensées alors même que l’équipe offshore disposait déjà d’une très bonne connais-sance et de références sur le domaine fonctionnel.

Pour réussir la préparation des équipes, nous préconisons de mener une phase spécifique(l’offshore kick off), en général sur le site du client dont les objectifs sont :• D’organiser, dans un délai contraint, les transferts de compétences des 2 parties,• De dérouler la TOTALITE des processus qui seront ensuite exécutés à distance, et de les

décrire dans un plan d’assurance qualité adapté (le PAQ offshore),• De permettre de nouer des relations de personne à personne qui faciliteront ensuite les

communications à distance.

Cette étape mixant formation, training et activités communes peut représenter de 2 à 4mois, mais elle permet de gagner un temps précieux par la suite et d’accélérer la courbed’apprentissage.

Géré comme un projet, l’offshore kick off nécessitera un animateur dédié qui, à la fois, coor-donnera les différentes étapes de la progression pédagogique, animera certains modules,et mobilisera les acteurs clés de l’entreprise (côté IT et côté business) pour les aider à adap-ter le contenu des sessions.

L’identification de ce chef de projet dédié permet d’éviter le «cumul des mandats» que l’on ren-contre de façon fréquente, lorsque le transfert de connaissance est confié aux acteurs opéra-tionnels qui doivent simultanément gérer cette tâche de fond avec l’activité quotidienne !


Un résultat induit du transfert de compétences est de créer le kit de base permettant l’intégra-tion de nouveaux membres dans l’équipe offshore (notamment en regard du turn-over).

Par exemple, dans un contexte projet, l’offshore kick off portera sur un lot ou un périmètreréduit du projet. La finalité première sera de mettre en œuvre les processus de spécifica-tions, de pilotage, de recette, de revues…

Sur une prestation de testing, il s’agira de vérifier la capacité de l’opérateur à installer uneversion, exécuter une campagne de tests de non régression, adapter les scénarii de test àdes évolutions fonctionnelles, initialiser une fiche anomalie, mettre à jour l’outil de pilotageet de suivi partagé etc.

Les schémas suivants résument le déroulement de l’opération.

5. Project management - follow up

Trame de la phase "Offshore kick off"

1. Decision 2. eligibility + contract 3. KT plan Welcome

Training

Evaluation

"Real life" tasks with support

"Real life" tasks without support

Reach Finalorganization

M1 M2 M3Offshore team on site Offshore team off site

6. Administrative tasks - Logistics

7. HR management

8. Internal Communication

Recruitment Team building Ongoing commitmentstabilization

Go - NoGo Milestone KT : Knowledge Transfer

4. KT realization off site4. KT realization

Process de support

Avancement du transfert de compétences offshore

Règles métier

Application

Pourcentage d'avancement

Do

mai

nes

de

tran

sfer

t d

e co

mp

éten

ces

: ext

rait

s

% de modules dispensés% connaissances vérifiées

0 20% 40% 60% 80% 100%

Enjeux business

« Les status meeting,

c’est également

l’occasion de vérifier

le moral des troupes

et de s’assurer

que les différents

process établis

dans le kick off sont

bien appliqués. »


Une phase de simulation de l’organisation distante est effectuée. Elle permet de s’assurerde la mise en place des process internes au plus tôt, d’apporter des compléments le caséchéant. Elle permet également de « rassurer » les équipes sur la limitation de l’impact vis-à-vis des clients business.

Une conduite de projet renforcée

Suivre l’avancement des équipes est probablement l’un des enjeux majeurs dans la réus-site des projets offshore. Comment, à distance, faire remonter les difficultés, sécuriser lesdélais de livraison, manager la qualité, percevoir « l’ambiance »… ?

Localement, on sait diagnostiquer, mener un recadrage, remobiliser les équipes… A dis-tance, c’est impossible : ne pouvant pas réagir, il est nécessaire d’anticiper un mode depilotage qui prévoit des points projet réguliers (« status meetings »), de préférence sur siteoffshore ou en alternance (en local, sur site).Le status meeting offshore réunit les objectifs couverts, usuellement, par plusieurs instan-ces. Il couvre les points fonctionnels, techniques, contractuels…On peut prévoir ces points à un rythme mensuel ou bimestriel selon les phases du projet,et de les planifier à 6 mois, un an.

Comme évoqué précédemment, le contrôle du projet est une prestation offerte par les opé-rateurs offshore. A vous de vérifier que l’ensemble des sujets est couvert et que vousbénéficierez d’une certaine transparence. Si ce n’est pas possible, un compromis est deconfier une mission de contrôle à un prestataire d’assistance à maîtrise d’ouvrage présenten local et sur site offshore.

Un mode pérenne sécurisé

Confrontés à l’externalisation, les DSI constatent régulièrement un turn-over excessif deséquipes. Hélas, l’offshore obéit à la même règle ! Le client souhaite conserver les meilleurséléments qui ont une bonne connaissance de leur entreprise, alors même que, vu du pres-tataire, la fidélisation et la progression de ces mêmes ressources passe par une nécessairerotation… Quand on sait que le turn-over dans les sociétés IT en offshore peut atteindre50 %, le phénomène doit être pris en compte et traité spécifiquement.Il est toujours possible de mettre en place des instruments contractuels pour lutter contreun turn-over excessif (incitations financières…). Néanmoins, la demande dans les pays lowcost est telle qu’il vous faudra composer avec !

En fin de phase offshore kick off, il est nécessaire de s’assurer que les équipes ont unecharge de travail conséquente pour mettre en pratique. Cela paraît de bon sens, mais onconstate que la tendance naturelle est d’être trop « protecteur », de traiter en interne le pluspossible de travaux de façon à « laisser du temps » pour l’apprentissage. C’est un risque,car faute de charge suffisante, les équipes sont normalement réduites, des membres cléspouvant être réaffectés à des projets similaires pour d’autres clients ! Ensuite, assurez-vousque le prestataire offshore dispose des moyens et outils pour faire monter en compétenceune ressource nouvelle, sans que vous n’ayez à vous impliquer excessivement. Par exem-ple, incluez dans les livrables de la prise de connaissance le package de formation d’unnouvel arrivant.

Et vous : êtes-vous « OFFSHORE PROOF » ?

Avec des promesses alléchantes et, en même temps des risques, dont une partie est fina-lement autant liée à la maturité interne qu’à la qualité du prestataire, le modèle offshore estaujourd’hui l’un des thèmes de la réflexion stratégique des DSI.

Notre principale recommandation est donc d’anticiper.


Anticiper les domaines d’application au sein du périmètre IT : quels projets seraientéligibles, quelles activités ?

L’enjeu est d’avoir préalablement cartographié ces domaines d’application avant que lasolution offshore ne soit brutalement « imposée » par votre DG ou DAF.

Anticiper la recherche d’un opérateur apte à travailler, dans la durée, en partenariat.

Il devra bien entendu disposer de compétences fortes sur le périmètre d’expérimentationque vous retiendrez, donc apte à encourager la généralisation du modèle. Le choix du par-tenaire et du pays se fera en prenant en compte des critères de sélection supplémentaires :langue de travail, aptitude à constituer une équipe interne motivée… Il pourra égalementêtre guidé par la stratégie de développement internationale de l’entreprise.

Trouver un opérateur offshore ne présente pas de difficultés particulières dès lors quevous respectez les critères standards de consultation : références, compétences desmembres de l’équipe, vérification des certifications annoncées… Vous pouvez égalementfaire appel à des consultants locaux (privilégiez un consultant local connaissant le business

A retenir : Nos conseils pour réussir

Le respect de quelques règles permet d’éviter les erreurs les plus importantes.

1. Vous vous interrogez sur l’opportunité d’enclencher un projet offshore• Les activités « offshorées » sont formalisées, codifiées précisément• Elles requièrent un volant de « main-d’œuvre » important• Elles sont « acceptables » par le client final, soit parce qu’elles ne nécessitent

pas d’échanges fonctionnels multiples, soit parce qu’elles portent sur unpérimètre non critique,

• Une équipe interne mobilisable, de bon niveau, motivée, avec une grandecapacité d’adaptation et d’écoute

• Une réflexion sur les critères d’éligibilité a été menée (une grille de scoringexiste)

2. Vous avez décidé et retenu un projet• Un chef de projet est dédié, déchargé en grande partie de ses travaux opé-

rationnels• Le programme de kick off et la méthode de conduite de projet sont adaptés :

ils prévoient un volet multiculturel, et se traduisent a minima par une forma-lisation et une mise en pratique des processus transverses (sous forme d’un« PAQ offshore »).

• Une visite sur site offshore est planifiée• Un plan de communication / mobilisation est réalisé en interne

3. Les équipes offshores sont déployées, la configuration est opérationnelle• Les calendriers, ordres du jour, thèmes et lieux des status meeting sont établis• Le dispositif d’intégration de nouvelles ressources est démultiplié, testé et

opérationnel• Un retour d’expérience est fait sur le premier projet avant généralisation

4. …Faites la chasse aux idées reçues• La qualité des travaux offshore n’est pas forcément mauvaise• Les gains obtenus ne sont pas concrétisés immédiatement, ils ne sont pas

en rapport avec les taux pratiqués• Généraliser l’offshore n’est pas synonyme de réduction d’effectifs


IT en France). Au-delà de la recherche de partenaires, ils sauront également vous aiderdans les montages contractuels, les aspects RH… Vous pouvez également (ce qui est leplus répandu) vous appuyer sur des sociétés basées en France qui mobilisent leur proprecentre de ressources offshore : dans ce cas, le gain potentiel est plus faible puisqu’une par-tie du management est assurée par le sous-traitant.

Enfin, c’est anticiper la conduite du changement (au sens large).

L’offshore est une transformation dont les premières cibles impactées sont les équipes IT,mais dont la portée va au-delà. Vous aurez à expliquer aux métiers que certaines règles degestion « cœur de métier » sont codées et implémentées à 5 000 km.Compte tenu de la sensibilité du sujet, vous aurez également à traiter avec les instances dereprésentation du personnel.

Pour finir, on peut en effet, difficilement traiter du thème de l’offshore sans aborder lesconséquences en matière d’emploi. Actuellement, la part de l’offshore dans les budgetsinformatiques représente un pourcentage inférieur à la croissance du secteur. L’incidenceen matière d’emploi n’est donc pas visible : elle se traduit principalement par une part decroissance non génératrice d’emplois directs en France. Bien que les avis divergent, ilparait probable que la part d’activité offshore augmente de façon beaucoup plus forte etdouble entre 2007 et 2009.

Plusieurs indices : l’ampleur du phénomène chez nos voisins européens et aux US, lastratégie des grands cabinets, notamment la forte accélération de leurs implantationsdans les pays low cost ces dernières années, l’accélération de l’implantation en France deforces commerciales des SSII offshore, leur référencement par les grands comptes, et lespremières réussites qui feront tâche d’huile et enfin la « banalisation » de l’outsourcing offs-hore dans l’industrie et les services, encouragés par des mises en relation au travers devoyages d’étude organisés dans les pays low cost par les chambres de commerce ou lesfédérations professionnelles.

Dans ce contexte, on ne voit pas comment l’offshore pourrait être neutre sur l’emploi.Espérons simplement qu’en contrepartie des incidences prévisibles sur l’emploi, noussaurons accompagner la montée en compétences de nos informaticiens et gagner denouveaux marchés dans ces mêmes pays. Parions aujourd’hui sur une seule attitude vis-à-vis de l’offshore : soyons AUDACIEUX. �

Olivier Chaussard, Directeur Associé du Groupe ORESYS, aconduit plus de 150 missions en tant que Directeur de projetainsi qu’en accompagnement du changement dans les projetsde transformation des entreprises. Il intervient notamment surdes projets offshore depuis 10 ans.

Oresys

Société de conseil indépendante de 200 consultants, ORESYS aide ses clients à

• piloter leurs activités,

• améliorer leur performance,

• mettre en œuvre leurs projets de transformation.

Oresys intervient sur toutes les dimensions :métier,organisation,processus,système d’information,accompagnement

du changement.

Pour mieux accompagner nos clients DSI confrontés à la mise en œuvre volontaire ou imposée de l’offshore, ORESYS

a complété et adapté les méthodologies de conduite de projet. Nous avons élaboré un ensemble d’outils pratiques pour

accélérer et sécuriser le cadrage et la conduite des projets offshore.

Pour compléter votre bibliothèquede référence technique,commandez vite les anciens numéros*d’IT-expert à tarif préférentiel !

IT-expert n°57Septembre/octobre 2005

DOSSIER : Equiper les forces de terraind’une solution mobile• La gestion des utilisateurs centraliséeou le provisioning• Les alternatives à la suite bureautique Microsoft• Les Tags RFID : révolution technologiqueou cauchemar• Les solutions Linux

IT-expert n°61Mai/juin 2006

DOSSIER : Optimiser innovations ettransformations en gérant le portefeuillede projets et d’applications• Subversion : le grand départ ?• L’accessibilité numérique• Wi-Fi

IT-expert n°60Mars/avril 2006

DOSSIER : La qualité des applicationsdéveloppées en technologies objet• L’industrialisation des développements au secours

des échecs projets• Environnements de Développement Intégrés• Urbanisme des Systèmes d’Information versus

Architecture d’Entreprise• Interview de Monsieur SAINT-ALME,

Responsable NTIC chez AG2R• Contrôle d’accès au réseau

IT-expert n°59Janvier/février 2006

DOSSIER : Vers un standard pour lepilotage des coûts informatiques - Un levierde performance économique : AB C/ABM• Contrôle des développements externalisés

& solutions de gouvernance• K9a : une nouvelle grille de lecture pour la conduite

agile de projets de systèmes d’information• Interview de Jérôme Dupont, Directeur

Conventions & Projets du GIP-MDS• La guerre des processeurs aura-t-elle lieu ?

IT-expert n°62Juillet/août 2006

DOSSIER : Panorama sur les techniquesAgiles• PHP5, une alternative à .NET et J2EE ?• Eclipse : le Big Bang Callisto• Test Driven Development• Interview d’Elisabeth Le Boité, Responsable

Qualité et Système d’Information du SIBSyndicat Interhospitalier de Bretagne

• Qui arrêtera Google ?

IT-expert n°66Mars/Avril 2007

DOSSIER : Sécurité : Les applications,le talon d’Achille des entreprises• RIA (Rich Internet Application) : définitions et panorama

des solutions• Gestion des droits numériques en entreprise avec RMS• Un observatoire pour mesurer l’urba• Interview d’Hubert Tournier, Senior Manager

chez Deloitte Consulting & Risk Services• Les DRM : une introduction

IT-expert n°65Janvier/février 2007

DOSSIER : Web 2.0 entreprise, quelles réalités ?• ITIL et ISO20000• Logiciel libre :Qu’exiger de son prestataire informatique ?• Les wikis : définitions fonctionnelles et techniques• Interview de Monsieur Kabla, DSI de Dassault

Systèmes Ventes France• Une approche structurée de la certification du

réseau : l’audit automatique du réseau et la validationdes changements des configurations

IT-expert n°64Novembre/décembre 2006

DOSSIER : Capital Immateriel• Windows Vista : le nouveau système

d’exploitation de Microsoft• Les curseurs sous SQL Server• Interview de Mme Seigneur, Directeur

Informatique du Conseil Général de Vendée• Wimax

IT-expert n°67Mai/juin 2007

DOSSIER : SOA, l’état de l’art• SOA :Architectures & outils• Imprimez moins, maîtrisez vos coûts !• Qualité interne de ses logiciels : mythes et réalités• Interview de Philippe VIALLETELLE et Franck DUPONT

de la société STMicroelectronics, site de Crolle• L’univers étrange des unités d’œuvre

* D

ans

la li

mite

des

sto

cks

dis

pon

ible

s


www.it-expertise.com

Je souhaite acheter les numéros suivants

Adresse d’expédition & de facturationIT-expert n°63Septembre/octobre 2006

DOSSIER : La géolocalisation• Géolocalisation, les techniques alternatives

au GPS• Le positionnement par GPS• Géolocalisation, tout n’est pas permis…• Interview de Me Gérard HAAS, Docteur en droit• Recyclage des e-déchets

IT-expert n°58Novembre/décembre 2005

DOSSIER : L’intégration de contenu,un problème bien réel• Les JavaServer Faces face à Struts• Sybase Adaptive Server Enterprise 15• Interview de Nicolas Maquaire,• Informatique et téléphonie :

à quand la convergence ?

IT-expert n°68Juillet/août 2007

DOSSIER : Le décisionnel• Du décisionnel à la gestion de la performance• La visualisation de l’information à des fins d’aide

à la décision• Les grandes étapes d’une chaîne d’ETL• Interview de Didier Fleury DSI chez CEGEDIM• ITIL : entre meilleures pratiques et référentiel

holistique

Année 2005� N° 57� N° 58

Année 2006� N° 59� N° 60� N° 61� N° 62� N° 63� N° 64

Pour commander les anciens numéros d’IT-expert, il vous suffitde nous renvoyer ce document à l’adresse suivante :

IT-Expert3, rue Marcel Allégot - 92190 Meudon - France

Tel : +33 (0)1 46 90 21 21 - Fax : +33 (0)1 46 90 21 20

� Mme � Mlle � M.

Nom

Prénom

Société

Fonction

Adresse

CP

Ville

E-mail

Tél

Fax

� Chèque joint à l’ordre de Press & Communication France

� Règlement à réception de facture

Date :Signature obligatoire :

Offre Spéciale

Tarifs TTC (TVA : 5,5 %)� 1 exemplaire : 8€ � 10 exemplaires : 60€

� 5 exemplaires : 35€ � Autre quantité :

Année 2007� N°65� N°66� N°67� N°68

Technique


La qualité intrinsèquedes applications dans les

contrats de service

La sous-traitance du développement applicatif, tant pour la maintenance corrective qu’évolutive,

requiert un cadre contractuel pour éviter toute dérive. L’approche traditionnelle des contrats de ser-

vices prend en compte les aspects critiques aisément vérifiables tels que les fonctionnalités atten-

dues, les délais et certains niveaux de performance.Elle omet généralement d’inclure les aspects liés

à la qualité intrinsèque du code source livré. Cette omission s’explique soit par un manque d’intérêt,

à tort, dans cette discipline, soit par la difficulté, apparente, de réalisation. La mise en œuvre de tels

contrats de service,pour être efficace,devra effectivement être adaptée à cette « nouvelle » discipline :

par une approche progressive, sélective et spécifique.


� L’approche traditionnelle

Fondamentalement, les contrats de service liés à la sous-trai-tance de la maintenance applicative corrective ou évolutive sontdéfinis pour, d’une part, protéger le commanditaire contre unelivraison non-conforme aux attentes, et protéger d’autre part lefournisseur contre un commanditaire éternellement insatisfait.Le meilleur moyen pour créer un terrain d’entente est de définirprécisément ce qui est attendu.Dans le cas d’une maintenance évolutive, cette définition passetout d’abord par les fonctionnalités attendues – le « pourquoi » decette sous-traitance – et les délais de livraison. Ces premiers élé-ments sont aisément vérifiables : les fonctions attendues sont-elles disponibles et délivrent-elles les résultats attendus ? Lalivraison a-t-elle lieu dans les délais impartis ? Dans le cas d’unemaintenance corrective, cette définition se focalise sur les délaisde correction. L’aspect fonctionnel est en effet implicite : corrigerle bogue ou le problème.

Par analogie avec le monde industriel, il s’agit de s’assurer que leproduit effectue son office (par exemple, assurer une communi-cation claire et audible pour un téléphone portable) et qu’il estproduit dans les temps.

A ces préoccupations de fonctionnalités et de délais, viennentensuite s’ajouter des considérations de performance. Le sujetest plus délicat car il requiert de définir les conditions précisesdans lesquelles les mesures de performance doivent être effec-tuées pour vérifier leur conformité aux attentes. Malheureuse-ment, la conformité ne protège pas intégralement contre unproblème en production, lié au niveau de performance. Par unesélection intelligente des conditions de test et par la prise demarge de sécurité, ce type de validation peut suffire dans la majo-rité des cas.

Pour poursuivre l’analogie industrielle, il s’agirait ici de vérifier quela consommation énergétique du produit est conforme aux atten-tes dans des conditions définies (pour reprendre l’exemple dutéléphone portable, l’autonomie en veille dans des zones de cou-verture réseau différente : en agglomération, en bord de mer…).Bien évidemment, certaines circonstances, non testées, peuventconduire à des consommations exceptionnellement élevées.En général, les contrats de service s’arrêtent ici. Deux questionsse posent en effet. Pourquoi aller plus loin ? Comment aller plusloin ?

� Pourquoi aller plus loin ?

Tout simplement parce que l’expérience montre qu’il reste tou-jours un sentiment d’insatisfaction ou de frustration. Soit parceque les livrables rencontrent des problèmes majeurs en produc-tion – dysfonctionnement, temps de réponse… –, soit parce queles livrables semblent, à la longue, de moins bonne facture.

� Comment aller plus loin ?

La validation automatique de la qualité intrinsèque du codesource livré constitue une approche efficace et économique.

Cette approche ne remet évidemment pas en cause les principesévoqués ci-dessus. Elle vient au contraire les compléter, sansavoir la prétention d’éradiquer toutes les causes possibles d’in-satisfaction.

Les avantages de cette approche complémentaire sont recon-nus : réduire plus avant les causes de problèmes en productionet améliorer la productivité du développement (cf. « Qualitéinterne de ses logiciels : mythes et réalités », IT-expert N° 67).A noter que ce second point peut sembler déplacé dans uncontexte de sous-traitance. Il serait pourtant erroné de considé-rer que les gains de productivité ne concernent et ne regardentque le sous-traitant. Au-delà des gains que le sous-traitant peuten espérer pour accroître sa marge opérationnelle, le commandi-taire gagne, lui, à préserver une situation saine pour ses contratsfuturs. Il peut compter sur la diminution, par exemple, du nombrede demande de changements facturés en dehors de la mainte-nance standard. En effet, l’estimation de la charge requise pourune modification donnée dans un contexte dégradé au fil dutemps peut faire basculer celle-ci de « maintenance » en« demande d’évolution » parce qu’elle dépasse un seuil défini de« jour/hommes ».

Si la nécessité de valider la qualité intrinsèque du code source estindéniable, encore faut-il pouvoir mettre en œuvre cette valida-tion. Aujourd’hui, avec l’existence de solutions logicielles spé-cialisées dans ce domaine, le problème n’est plus une questionde « produit » : il s’agit surtout d’une question de « processus ».

Comment utiliser une solution devérification et de validationautomatique de la qualité intrinsèquedu code source ?

Pour répondre à cette question, il est bon de mettre en avanttrois caractéristiques de la vérification et de la validation automa-tique de la qualité intrinsèque du code source :1 c’est une pratique émergente ;2 c’est une pratique critique pour le bon fonctionnement en pro-

duction des applications ;3 c’est une pratique fortement contrainte par les priorités

« métier ».

Mais avant de définir les conséquences de ces caractéristiques,il convient de passer en revue les capacités de validation et devérification en question.

� Vérification et validation automatique

La vérification et la validation automatique de la qualité intrinsè-que du code source est une discipline qui permet d’analyser lecode source, de le « comprendre » et de le mesurer selon diffé-rentes règles. Ces règles traduisent des pratiques de codage,d’architecture… Elles définissent des pratiques attendues et despratiques exclues. La solution logicielle utilisée sert alors d’instru-ment de mesure, de test.


Sur la base du nombre de cas où la pratique attendue ou exclueest identifiée, il est aisé de calculer des niveaux de respect de cesrègles et de finalement définir des seuils de tolérances lesconcernant.La nature des règles dépend de la solution logicielle utilisée. Ellespeuvent concerner de nombreux aspects du code source. L’im-portant est alors de lier ces règles à des caractéristiques ayant unimpact significatif sur le fonctionnement de l’application. La rela-tion devra aussi définir l’importance relative de la contribution dechaque règle à la caractéristique applicative.

La manière d’organiser les liaisons entre les règles de program-mation et les caractéristiques de l’application pourra s’inspirer dela norme ISO 9126 (et plus spécifiquement de la section 3 relativeà la qualité interne d’une solution logicielle) ou du modèle GQM(Goal-Question-Metric). Ces organisations permettent de tisserdes liens structurés entre l’ensemble des règles vérifiées et descaractéristiques macroscopiques de l’application. Pour donnerun exemple de caractéristique macroscopique d’une applica-tion, on peut s’intéresser à sa capacité à être modifiée rapide-ment pour s’aligner sur le rythme d’évolution requis par lesprocessus « métier » de l’entreprise.Cette organisation se révélera particulièrement utile dans le pro-cessus de sélection des règles à vérifier.

En poursuivant l’analogie avec le monde industriel, il s’agirait icide s’assurer que le produit a une MTBF (Moyenne des Temps deBon Fonctionnement, ou, en anglais, Mean Time Between Failu-res) acceptable en se basant sur les propriétés de chacun de sescomposants et de la façon dont les composants sont assemblés.

� Une pratique émergente

La capacité logicielle d’effectuer une validation et vérification auto-matique de la qualité intrinsèque du code source est relativementrécente. Son utilisation dans le cadre d’initiatives internes restel’apanage de sociétés pionnières en la matière. Son utilisation dansle cadre de contrats de service est encore plus marginale.Dans ce cadre, une approche progressive est de rigueur. Tenterde définir des objectifs pour toutes les règles existantes estcontre-productif. Une définition d’objectifs trop nombreuxconduit inévitablement à un effet « sapin de noël » où tous lesindicateurs clignotent, masquant potentiellement les indicateursles plus importants.Une approche prudente peut s’inspirer des niveaux de maturitédu modèle CMMI : commencer par mesurer le niveau de respectdes règles, reproduire les mesures sur les différents projets et aucours du temps, mettre en place des objectifs relatifs aux niveauxde respect des règles, mettre en place des contrats de servicebasés sur ces objectifs…

� Une pratique critique

En revanche, le fait que la qualité intrinsèque du code sourceimpacte directement le bon fonctionnement des applications enproduction ne permet pas de suivre une approche trop timorée.Personne ne pourra se satisfaire, dans l’éventualité d’un incidenten production, d’une réponse telle que : « nous sommes en

phase de collecte d’information ; nous commencerons à fixerdes objectifs dans 18 mois ».Une approche mixte permet de définir une cadence d’implémen-tation réaliste mais effective à très court terme. Cette approchemixte consiste à définir :- un jeu de règles pour lesquelles le sous-traitant s’engage à

effectuer la mesure du niveau de respect et à en fournir lavaleur au commanditaire ;

- un jeu de règles très restreint pour lesquelles le sous-traitants’engage à respecter des objectifs relatifs au niveau de respect.

La taille du jeu de règle pourra – et devra même – varier avec letemps et la maturité des intervenants.Pour commencer, un jeu de règle d’environ 10 règles par techno-logie impliquée est un maximum. Le choix de ces règles dépen-dra des préoccupations principales du commanditaire et de lafaisabilité technique. L’organisation des règles évoquée précé-demment doit servir à guider cette sélection, que ce soit par lechoix des caractéristiques de l’application recherchées, ou parl’importance donnée à telle ou telle règle dans ce domaine.L’engagement de fourniture des informations par le sous-traitantne dispense pas le commanditaire de mettre en place le mêmedispositif de mesure à la réception.

� Une pratique fortement contrainte par lespriorités « métier »

En théorie, le non-respect des objectifs fixés devrait conduire aurefus par le commanditaire d’une livraison de son sous-traitant enl’état.En pratique, en dépit de la possibilité technique de valider et véri-fier l’atteinte des niveaux de qualité attendus, il n’est pas réa-liste, dans la majorité des cas, de pouvoir appliquer une politiqueaussi stricte.En effet, autant le propriétaire « métier » de l’application compren-dra que l’on rejette une livraison qui ne réponde pas correctementaux attentes fonctionnelles, aux niveaux de performancerequis… autant, il aura du mal à accepter que son application nesoit pas mise en production simplement à cause d’une qualitéintrinsèque du code source insuffisante. La pression « métier »sera telle que la livraison sera acceptée.

Si l’on prend en compte la maturité du marché, le non-respectdes objectifs relatifs à la qualité intrinsèque du code source seraessentiellement utilisé pour conforter – ou non – une décisionbasée sur les résultats des tests fonctionnels et/ou de perfor-mance.La possibilité de définir des pénalités est une solution égalementpeu satisfaisante : dans le monde du développement logiciel oùrien ne disparaît réellement, une livraison de mauvaise facturepénalisera l’application non seulement pour la livraison concer-née, mais aussi pour tous les développements futurs relatifs àcette application. Il s’agit d’une réelle hypothèque sur le futur.

La seconde loi du développement informatique, énoncée par leDr. Lehman de l’Imperial College de Londres*, statue qu’il n’y aaucune raison pour que les choses s’améliorent avec le temps siaucune action n’est engagée en ce sens. L’opportunité créée ici

* Laws of Software Evolution Revisited, M M Lehman, Department of Computing, Imperial College - 1997


concerne la définition d’actions à mener pour améliorer la situa-tion. Cela souligne l’importance de fournir, en complément duniveau de respect des règles choisies, la liste des situations non-conformes.

Dans la pratique…

� Organisation des règles

La liste des caractéristiques qui impactent le bon fonctionne-ment d’une application en production et en maintenance n’estpas exhaustive ni exclusive. Elle pourra être adaptée à chaquecontexte particulier.

On peut néanmoins dresser une liste des caractéristiques les plusintéressantes, à la fois par leur généricité et par la nature desimpacts sur l’application. Quelle est la capacité d’une application à :• résister au changement, non pas pour empêcher toute évolu-

tion mais pour continuer à fonctionner malgré des change-ments fréquents et nombreux ; ou, robustesse del’application,

• résister à la charge, maintenir un niveau de performanceacceptable quel que soit le contexte d’utilisation,

• assurer la sécurité des données qu’elle manipule, que ce soitcontre des attaques mal intentionnées ou que ce soit contredes dysfonctionnements internes,

• évoluer rapidement ; ou, évolutivité de l’application,• être comprise par un nouvel intervenant ; ou, transférabilité

de l’application.

A noter que ces caractéristiques ne dépendent pas que de la qua-lité intrinsèque du code source, mais cette dernière y participe.Cette organisation s’inspire largement de la norme ISO 9126 sanspour autant y adhérer en totalité. L’important dans cette organi-sation est de classifier ce qui est important pour l’entreprise quidépend des applications en question.

Un niveau d’organisation intermédiaire, également d’inspirationISO 9126 et GQM, se révèle utile pour :• continuer à tisser le lien entre une caractéristique macrosco-

pique ayant normalement des connotations « métier » et desrègles de programmation très précises liées à telle ou telletechnologie,

• simplifier la gestion de cette organisation, quand on sait quel’on peut être amené à manipuler des centaines et des centai-nes de règles, que ces règles peuvent requérir des niveauxd’expertise dans diverses technologies, et que des règlespeuvent évidemment participer à plusieurs caractéristiquesmacroscopiques.

Dans la mesure où l’on souhaite collecter des informations surl’ensemble des projets, il sera intéressant de créer des groupe-ments intermédiaires suffisamment génériques pour être utiles etutilisés dans de nombreux contextes.L’encart propose une liste relativement exhaustive, qui pourraêtre utilisée en l’état ou enrichie au besoin.


Intitulé Description Impacts

Architecture multicouches et d’ac-cès aux données

Règles relatives aux accès aux données dansune architecture multicouches et orientée objet.

Robustesse / Sécurité / Evolutivité

Réutilisation Règles relatives à la réutilisation de composantéprouvés et déjà disponibles

Robustesse / Evolutivité

Dépendances inter-objets Règles relatives aux zones d’influence de chan-gement d’un objet sur l’ensemble des autresobjets

Robustesse / Transférabilité /Evolutivité

Indépendance à l’environnementd’exécution

Règles relatives aux utilisations des ressourcesdes plateformes d’exécution et des systèmesd’exploitation

Robustesse / Sécurité / Evolutivité

Code mort Règles relatives au bruit inutile causé par ducode non utilisé (attention : une analyse statiquedu code ne fournit pas d’information sur le codemort dynamique ou logique)


Complexité algorithmique et struc-ture de contrôle

Règles relatives au contrôle de la complexitétoujours croissante des objets


Instanciation dynamiques Règles relatives à l’utilisation abusive, coûteuseet risquée, des instanciations dynamiques

Robustesse / Transférabilité /Evolutivité / Performance

Code vide Règles relatives au bruit inutile causé par ducode fonctionnellement vide

Transférabilité / Evolutivité

Capacité d’évolution Règles relatives à la marge d’évolution disponi-ble avant de poser des problèmes de mainte-nance

Evolutivité

Complexité d’héritage et de poly-morphisme

Règles relatives à l’utilisation abusive d’héritageet de polymorphisme


Complexité des requêtes SQL Règles relatives au contrôle de la complexitédes requêtes SQL, tant du côté serveur qu’em-barqué dans du code client

Robustesse / Transférabilité /Evolutivité / Performance

Documentation automatique Règles relatives à l’utilisation des méthodes dedocumentation automatique du code (selon lestechnologies)

Transférabilité

Mauvais commentaires Règles relatives à la présence de mauvais com-mentaires qui n’aident en aucun cas à la bonnecompréhension du code

Transférabilité

Liste des regroupements des règles relatives à la qualité intrinsèque ducode source

Voici une liste de regroupements permettant d’organiser les règles à vérifier et de gérer leur impact sur les caractéristiquesmacroscopiques d’une application


Intitulé Description Impacts

Conventions de nommage Règles relatives au respect des conventions denommage (attention : la vérification critique dela pertinence des noms utilisés nécessitera uneintervention humaine)

Transférabilité / Evolutivité

Volume de commentaire Règles relatives à la présence d’un volume suf-fisant de commentaire dans l’ensemble du code

Transférabilité

Style Règles relatives aux pratiques de mise en formesimplifiant la lecture du code

Transférabilité

Appels coûteux dans des boucles Règles relatives à la présence d’instructionsconsommatrices en ressources au sein de bou-cles algorithmiques

Performance / Sécurité

Gestion de la mémoire, des res-sources réseau et de l’espace dis-que

Règles relatives aux bonnes pratiques d’utilisa-tion des ressources physiques et logiques dusystème

Performance / Sécurité

Performance SQL et de manipula-tion des données

Règles relatives aux pratiques SQL identifiéescomme dangereuses en regard des performan-ces, tant du côté serveur qu’embarqué dans ducode client

Performance

Gestion des erreurs et des excep-tions

Règles relatives aux pratiques identifiéescomme dangereuse en regard du traitement deserreurs et des exceptions

Robustesse / Sécurité

Organisation des fichiers Règles relatives aux bonnes pratiques d’organi-sation des fichiers contenant le code source

Transférabilité

Modularité et encapsulation Règles relatives aux bonnes pratiques relativesà la modularité des composants

Evolutivité

Héritage et de polymorphisme Règles relatives aux pratiques orientées objetidentifiées comme dangereuses en regard de laprédictibilité du comportement

Robustesse / Transférabilité

Fluidité du code Règles relatives à la bonne structuration ducode et des appels inter-composants


Sécurité d’encapsulation Règles relatives aux pratiques orientées objetidentifiées comme dangereuses pour la confi-dentialité des données

Sécurité

Validation des saisies Règles relatives à la bonne validation dessaisies par les utilisateurs finaux

Sécurité

Sécurité des appels aux primitives Règles relatives aux appels de primitiveidentifiés comme dangereux

Sécurité

Gestion des états Règles relatives aux pratiques identifiéescomme dangereuses pour la confidentialité desdonnées en environnement multi-thread

Sécurité

Volume des composants Règles relatives au volume abusif descomposants


Taille des composants Règles relatives à la taille abusive descomposants



Philippe-Emmanuel DOUZIECHChef de produitCAST

� Engagement de mesure et de livraisondes résultats

Pour l’ensemble des règles disponibles pour les technologiesconcernées, le sous-traitant s’engage à fournir en annexe ducode source livré les niveaux de respect associés.

Cet engagement apporte les bénéfices suivants :• le gain d’attention apporté aux bonnes pratiques de dévelop-

pement d’un intervenant se sachant suivi,• la première étape nécessaire à un pilotage rationnel de l’acti-

vité de sous-traitance, permettant de commencer à mesurerl’impact de la non-qualité et à exercer un suivi dans le temps.

� Engagement de respect de seuilsde tolérance

Pour l’ensemble restreint des règles sélectionnées, le sous-trai-tant s’engage à respecter les seuils établis à l’avance. Dans cer-tains cas, le seuil de tolérance peut être nul pour éviter tout risquepotentiel.

Dans le cas où le seuil de tolérance autorise la présence de situa-tions non-conformes à la règle, la liste de ces situations devraégalement accompagner le niveau de respect de la règle. Cetteinformation pourra servir à analyser plus avant le risque associéet décider d’une action particulière.

Conclusion

Une gestion saine de contrats de service dans le domaine dudéveloppement applicatif passe inévitablement par l’addition dela dimension « qualité intrinsèque du code source ».L’ajout de cette dimension bénéficiera tant au commanditairequ’au sous-traitant : au commanditaire, par une meilleure préser-vation de la pérennité de ses investissements applicatifs ; ausous-traitant, par une opportunité d’accroître sa marge opéra-

tionnelle ; aux deux parties, par une gestion de la relation client-fournisseur plus mature et plus transparente. In fine, ceci repré-sente l’opportunité d’augmenter le volume des transactions quilie les deux parties.

Attention néanmoins, Rome ne s’étant pas construite en un jour, laprise en compte de la qualité intrinsèque du code source devra êtredéterministe – la qualité n’arrivera par hasard – et progressive – laqualité totale passe par de continuelles « petites » victoires –. �

A propos de la société CAST

CAST, pionnier et leader mondial des logiciels de gestion de la performance des

développements applicatifs (Application Development Performance Management),

fournit les métriques et l’information dont les managers IT ont besoin pour mieux

mesurer, contrôler et améliorer la qualité des applications métiers et la performance

des équipes de développement de par le monde.

Fondée en 1990, CAST a aidé plus de 600 grands comptes internationaux à accélé-

rer le processus de delivery,à réduire les risques en production,ainsi que le coût total

d’acquisition des applications, enfin à améliorer la satisfaction clients. CAST est

cotée sur le compartiment C d’Eurolist Paris (Euronext :CAS) et a équipé de nombreu-

ses sociétés des Fortune 2000,au travers de 11 bureaux en Europe et aux USA. Pour

plus d’information : www.castsoftware.com.

IT-expert, la référence techniquedes professionnels de l’informatique

Bimestriel de conseil et d’expertise technique,

IT-expert vous offre l’information essentielle pour

vous former et décider.

IT-expert, soudain tout est clair…


Pour tous renseignements : IT-expert - 3, rue Marcel Allégot - 92190 MEUDON - FRANCE

Tél. : +33 (0)1 46 90 21 21 - e-mail : [email protected]


Bon d’abonnement à faxer au+33 (0)1 46 90 21 20

ou renvoyer au Service Abonnements3, rue Marcel Allégot

92190 MeudonFrance


� Mme � Mlle � M.

Nom

Prénom

Société

Fonction

Adresse

CP

Ville

E-mail

Tél

Fax

�Je m’abonne 1 an au bimestriel IT-expert. Je recevrai 6 numéros pour 89 € TTC

�Je m’abonne 1 an à IT-expert version papier + accès au pdf en ligne* pour 120 € TTC

� Chèque joint à l’ordre de Press & Communication France

� Règlement à réception de facture

Date :Signature obligatoire :

Abonnez-vous à IT-expert

* Vous recevez dès sa parution un exemplaire d’IT-expert par la poste à l’adresse de votre choix et vous aurez accès à l’ensemble des anciens numéros d’IT-expert en version PDF sur le site webd’IT-expert : http://www.it-expertise.com

Actualités internationales


Actualitésinternationales

Le standard Web Services Policy 1.5 du W3Cassouplit les services Web

Développer des services Web permet d’ouvrir des fonctions d’une application àune autre voire à des systèmes d’information externes. Et SOA apporte uneréponse en termes d’architecture, avec une organisation et une orchestration maî-trisées. Néanmoins, depuis plusieurs années les développeurs ont confirmé lanécessité de gagner en flexibilité, en assouplissant les contraintes de descriptiondes extensions obligatoires et facultatives utilisées par un service. Sinon, la réécri-ture d’un service s’impose trop souvent lors de la modification d’applications deplus en plus évolutives, limitant l’intérêt des services Web et augmentant d’autantles coûts. Reliant les principales normes de services Web (SOAP 1.2, WSDL 2.0 etXML Schema) à « un ensemble d’extensions qui reflètent les besoins et l’expé-rience du secteur industriel » (dixit W3C), le standard Web Services Policy 1.5 per-met de limiter ces frais. Ce standard permet donc aux développeurs SOA d’activerles extensions d’un service sans interrompre le fonctionnement ni modifier desdescriptions de service de niveau inférieur.

Des processus éprouvésTouchant à ce niveau de communication, on comprendra l’importance d’un stan-dard, garantissant la pérennité des développements et l’interconnexion avec lesdifférents logiciels et plates-formes.Bien entendu, le groupe de travail Web Services Policy a invité des responsablesd’implémentation à effectuer des tests d’interopérabilité en évaluant des logiciels.Dix implémentations de Web Services Policy 1.5 ont permis de vérifier la maturitéde la spécification. Le groupe a également organisé une revue par plusieurs comi-tés techniques de services Web OASIS (UDDI, WS-RX, WS-TX et WS-SX) afin degarantir que Web Services Policy 1.5 satisfasse leurs cas d’utilisation.Un standard non reconnu par les acteurs du marché serait stérile. Or, Web Servi-ces Policy sera certainement très répandu. En effet, ce groupe de travail du W3Ccompte parmi ses membres les leaders du secteur : Adobe Systems, Axway Soft-ware, BEA Systems, CA, Fujitsu, IBM, IONA Technologies, JBoss, Layer 7 Tech-nologies, Microsoft, Nokia, Nortel Networks, Oracle, SAP, Sonic Software, SunMicrosystems, webMethods et WSO2.

Un standard, pas une normeLe World Wide Web Consortium ou W3C, est un consortium fondé en octo-bre 1994 pour promouvoir la compatibilité des technologies du World Wide Webtelles que HTML, XHTML, XML, RDF, CSS, PNG, SVG et SOAP. Le W3C n’émetpas des normes au sens européen, mais des recommandations à valeur de stan-dards industriels. Sa gestion est assurée conjointement par le Massachusetts Ins-titute of Technology (MIT) aux États-Unis, le European Research Consortium forInformatics and Mathematics (ERCIM) en Europe (auparavant l’Institut national derecherche en informatique et en automatique français (INRIA)) et l’Université Keioau Japon (définition de http://fr.wikipedia.org). •

Cognos rachète Applixpour 339 millionsde dollars

Après le rachat d’Hyperion parOracle, de Cartesis par BusinessObjects et d’Outlooksoft par SAP,Cognos s’empare d’Applix, éditeurde solutions d’analyse financièrepour 339 millions de dollars.

La société américaine propose dif-férents outils de CPM (CorporatePerformance Management) pouraméliorer le secteur financier. Onretrouve des outils d’analyse, dereporting et de prévision, couplés àdes applications d’élaboration bud-gétaire, de planification, et deconsolidation.

Le numéro deux mondial du sec-teur des logiciels décisionnels (der-rière Business Objects) espère bienconsolider son offre d’analysefinancière en enrichissant son offrede TM1, moteur d’analyse multi-mensionnelle OLAP d’Applix.Applix a enregistré un chiffre d’af-faires annuel de 61,2 millions dedollars sur son dernier exercice,avec une croissance annuelle de45 %. •



Le trésor de l’ex-pirate Napstercoûte cher à Bertelsmann

L’éditeur allemand Bertelsmann, propriétaire de laplate-forme de téléchargement Napster, vient depayer la somme de 130 millions de dollars aux édi-teurs de musique américains.

Après avoir ravi les internautes avec le télécharge-ment P2P gratuit (et illégal), la plate-forme Napsterdevient hors-la-loi et doit fermer en 2001, suite auxdémarches judiciaires menées par les majors del’industrie du disque depuis 1999. Le 17 mai 2002,le groupe de média allemand Bertelsmann (RTLGroup, éditions Random House, éditeur de maga-zines Gruner + Jahr - Prisma Presse en France -,éditeur de musique BMG, les services de com-munication Arvato, et la distribution média avecDirect Group) rachète Napster pour 8 millions dedollars, après y avoir investi 85 millions de dollarsen 2000. La plate-forme est alors relancée sousune forme payante. Après paiement d’une sommede 0,99 dollar, un titre musical peut être écouté 5fois. Des formules d’abonnement sont égalementpossibles.

Un succès plombé par les dédommagementsEn 2006, Napster compte plus de 600 000 abon-nés, mais doit rivaliser avec un concurrent detaille : le service iTunes d’Apple. Début 2007,Napster remplace le site MusicNow d’AOL etporte son nombre d’abonnés à plus de 860 000.Toutefois, dès 2003, EMI et Universal Musicavaient porté plainte aux États-Unis contre legroupe allemand pour son soutien au site de musi-que en ligne.

Les 130 millions de dollars versés en septem-bre 2007, s’ajoutent aux 60 et 110 millions de dol-lars déjà versés respectivement à Universal Musicet Warner Music. Soit un total de 300 millions dedollars payés par Bertelsmann pour effacer l’ar-doise. Mais pas tout à fait, car l’éditeur de musiqueEMI attend lui quelques dizaines millions d’eurosde dédommagement.Et si le trésor du pirate enrichissait surtout lesconcurrents du groupe de média allemand. •

Microsoft confirme son intérêt surla virtualisation

Malgré les technologies au point et performantes, la virtualisation deserveurs x86 reste très faible. Pourtant, ces technologies seraientune aubaine pour les éditeurs d’OS, car chaque instance nécessitemalgré tout une licence logicielle ou le paiement de support annuelpour RedHat et autres éditeurs « Open Source » (rares sont les entre-prises qui s’en affranchissent).D’ailleurs, ce marché est très animé. Après l’entrée en bourse réus-sie de VMWare par EMC, et le rachat par Citrix de la solution de vir-tualisation Xen, Microsoft affiche ses ambitions avec SystemsCenter Virtual Machine Manager 2007 (VMM), sa nouvelle suite desupervision sur console unique. Une arme concurrentielle permet-tant de convertir des images virtuelles VMware au format VHD deMicrosoft. De plus, VMM administre les serveurs virtuels en un pointunique, et peut convertir les serveurs physiques en machines virtuel-les et réciproquement, avec des fonctions de répartition de chargesur les serveurs physiques.

Une bataille très concrète avec VMWareLa grande évolution des serveurs virtuels repose sur la présenced’un hyperviseur agissant au niveau le plus bas du système (ou horssystème), et virtualisant les pilotes accédant aux ressources physi-ques de la machine. Ce qui rend la machine virtuelle indépendantedu matériel. Microsoft intégrera ce mécanisme dans son prochainWindows Server 2008 (nom de code Longhorn).En proposant une conversion des serveurs VMWare vers son environ-nement, Microsoft rétorque à son concurrent qui amène son logiciel auplus près du matériel avec sa solution ESX, qui s’affranchit pour lecoup de l’obligation d’utiliser un système d’exploitation spécifique. •

Bientôt l’e-book sur Amazon ou Google ?

Le leader mondial des produits de loisirs sur internet Amazon et leleader des moteurs de recherche Google lanceraient bientôt desoffres de livres électroniques, mais avec des stratégies différentes.Le libraire en ligne propose son lecteur portable Kindle connectableà Internet sans fil (« écran plat au format d’un livre, pour 400 à500 dollars », selon le New York Times). Sony a déjà lancé un tel lec-teur en 2004 qui se connecte à un ordinateur pour télécharger deslivres sur un site de ses sites Web. Kindle pourra télécharger certainsquotidiens en ligne, comme le Monde, le New York Times ou le WallStreet Journal, et intégrera un clavier pour prendre des notes ou desurfer sur le Web. Cependant, Amazon a opté pour son propre for-mat de livre électronique (celui de sa filiale Mobipocket, la sociétéfrançaise rachetée en 2005) plutôt que pour le format ouvert prônépar les éditeurs.De son côté, Google ouvre un service payant de téléchargement delivres. Depuis plusieurs mois, des centaines de milliers delivres sont numérisés par les équipes de Google pourbâtir une bibliothèque électronique mondiale. Lesrevenus des téléchargements payants seront par-tagés avec les éditeurs.Les diverses initiatives e-book (Sony ou Bar-nes & Noble) se sont jusqu’à présent sol-dées par des échecs. •



L’Iso rejette la demandede normalisation du formatOOXML de Microsoft

Le format bureautique Office Open XML(OOXML) créé par Microsoft est utilisé dans sasuite Office 2007. L’éditeur cherche à fairereconnaître OOXML comme une norme parl’ISO. Déjà reconnu comme standard parl’ECMA, OOXML suit actuellement le processusde normalisation ISO.

Dans sa décision publiée le 2 septembre 2007,l’Organisation internationale de normalisation(ISO) a rejeté la proposition de norme soumisepar l’Ecma 376, dite « OOXML ». De nombreuxpays votants ont néanmoins voté « Non mais… »(comme la France) ou « Oui mais… » (commeles États-Unis), ne fermant pas définitivement laporte. Bien entendu, les concurrents de Micro-soft comme IBM, Sun ou Google (entre autres)ont redoublé d’efforts pour défendre le non, etMicrosoft a fait du lobbying pour appuyer le oui.

Se fermer ou non le marché du secteur publicEn effet, pour rester fournisseur des gouverne-ments et administrations, les logiciels doiventde plus en plus respecter les standards, afind’assurer une interopérabilité maximale avec lessolutions tierces, voire des développementsinternes. Ainsi, en France, nous connaîtronsdans quelques mois les conclusions et déci-sions du projet RGI (référentiel général d’inter-opérabilité) lancé par Direction générale de lamodernisation de l’État (DGME).

Or, la norme actuelle ISO-ODF (Open Documentformat) existe déjà et est utilisée aussi bien parles logiciels open source comme Open Office,ou commerciaux comme IBM Lotus, Star Officede Sun ou Google Documents et Tableurs (ouGoogle Docs). Ce qui fait dire à certains qu’uneseule norme suffit. Toutefois, il est clair que le« .doc » de Microsoft reste le format de fait leplus utilisé.

Les discussions et adaptationsse poursuivent ?C’est pourquoi, il serait souhaitable qu’unaccord aboutisse entre Microsoft et les instan-ces de normalisation. L’éditeur acceptera-t-il derevoir sa technologie OOXML à partir les com-mentaires publiés par les organismes nationauxde normalisation (AFNOR et autres) afin de l’ali-gner à la norme ? Jusqu’où l’Iso acceptera-t-elle un écart entre les deux, ou des spécificités ?À suivre… Les décisions définitives n’intervien-dront qu’en mars prochain. •

e-commerce français : 7,8 milliards d’euros

La fièvre acheteuse se confirme sur le Web français. Forte de 14millionsd’abonnés en Internet haut débit, la France assoit sa position de nationnumérique avec les usages associés. Ainsi, au premier semestre 2007,les ventes en ligne ont enregistré une hausse de 38 %, pour un résul-tat de 7,8 milliards d’euros, contre 5,6 milliards un an auparavant. Selonla Fevad (Fédération du e-commerce et de la vente à distance), le paniermoyen de transactions a augmenté, à 91 euros contre 88 euros aupremier semestre 2006. À près de 19millions, le nombre de cyberache-teurs plus que doublé en trois ans !Si, les années précédentes, le phénomène touchait essentiellementles moins de 30 ans, les plus de 35 ans représentent aujourd’hui50 % de part de marché et les « 50 ans et plus » participent à hauteurde 23,4 %. La croissance du secteur de l’habillement profite forte-ment de cet engouement avec +59 % en un an, pour environ900 millions d’euros, soit 3,7 % du marché total de l’habillement,contre 2,3 % en 2006, et une estimation à 4 % pour 2007. Attentiontoutefois : l’eldorado n’est pas promis à tous, et 15 sites majeursassurent 80 % de l’activité, et des résultats. Le tiercé gagnant natio-nal ? Le site d’enchères eBay, le guichet virtuel de la SNCF et laRedoute. Bref, des plates-formes robustes et des investissementsconséquents. En attendant, le pli semble pris. •

Internet à haut-débit dans le TGVdès cet automne

Thalys, société euro-péenne d’exploitation detrains à grande vitesse,fournira un accès Inter-net Wi-Fi à large bande àtous les passagers enComfort 1 et Comfort 2voyageant entre Paris,Bruxelles, Amsterdam etCologne d’ici la mi-2008.

Pour proposer cette connexion transfrontière, Thalys a choisi unconsortium réunissant le fournisseur international de services decommunications Nokia Siemens Networks, le fournisseur européende solutions satellitaires à large bande à bord des trains à grandevitesse 21Net, et le fournisseur belge de services à large bande sur lecâble Telenet. Le consortium a réussi à combiner les technologiessatellitaires, GPRS et UMTS à un réseau sans fil de type « hotspot »pour fournir une connexion Internet transfrontalière permanente àbord de trains circulant à une vitesse de 300 km/h. C’est une pre-mière parmi les sociétés internationales d’exploitation de trains.Cette technologie associe un accès Internet satellitaire bidirectionnelà un réseau de points d’accès sans fil disposés dans chaque voitureComfort 1 et Comfort 2. Un passage continu de la technologieGPRS/UMTS à la connexion satellitaire sera également prévu, afin degarantir l’accès Internet à bord des trains lors de leur passage enzone couverte telle que les gares ou les tunnels.Les premiers trains Thalys équipés du Wi-Fi circuleront en servicecommercial à partir de l’automne 2007. •


Quoi de neuf Docteur ?

Backsourcing :Lorsquel’externalisationn’est pas utiliséeavec précaution

Le recours à l’externalisation est aujourd’hui une ques-

tion incontournable pour l’ensemble des organisations

et leur DSI. Au-delà de l’impérieuse nécessité de

réduire les coûts, les promesses sont nombreuses :

flexibilité, mise à disposition d’experts, transfert des

risques…

Deloitte Consulting a réalisé une étude visant à faire la

part des choses dans le domaine de l’externalisation.

Elle a porté sur 25 organisations de dimension interna-

tionale, dans tous les secteurs d’activité, aussi bien de

la sphère privée que publique. Cette étude a permis

de déterminer le niveau de satisfaction réel retiré de

l’opération. Elle met en valeur le fait que l’externalisa-

tion, bien qu’étant une tendance de fond, n’est pas tou-

jours en mesure de répondre aux objectifs pour

lesquels elle a été mise en place initialement.

Ainsi, avant de céder trop vite à l’appel des sirènes, il

convient de prendre un certain nombre de précautions

sous peine de ne pas retirer les bénéfices escomptés

de l’externalisation. En effet cette opération nécessite

une analyse préalable, la mise en place d’une structure

de gouvernance adaptée et un suivi minutieux afin de

garantir sa bonne réalisation.

Toutefois l’externalisation n’est pas une fatalité et de

nombreux exemples actuels démontrent qu’il est par-

fois préférable de ré-internaliser certaines fonctions.


Différentes variantes de l’externalisation

D’après Wikipédia, « l’externalisation, aussi appelée outsourcing,désigne le transfert de tout ou partie d’une fonction d’une entre-prise vers un partenaire externe. Elle consiste très souvent en lasous-traitance des activités non essentielles et non stratégiques(celles qui ne sont pas productrices de revenus) d’une entre-prise. »

Dans le domaine informatique, les prestations d’externalisationse déclinent de la conception à la réalisation de solutions infor-matiques, en passant par l’exploitation, l’hébergement ou lamaintenance. Cette liste n’est bien évidemment pas exhaustive,elle vise à illustrer la multiplicité des opportunités de recours àl’externalisation pour un DSI. Par ailleurs, le périmètre pris encharge par un contrat d’externalisation est très variable. Il peutcouvrir une activité réduite, voire la quasi-totalité de la fonctioninformatique pour de grands groupes internationaux. On parlealors de méga-contrats d’externalisation.

La délocalisation, ou offshoring, consiste à externaliser vers despays permettant de bénéficier d’un faible coût de main-d’œuvre.Dans le domaine IT, l’exemple le plus courant concerne le déve-loppement logiciel. Si l’Inde domine encore largement ce marché,elle est maintenant concurrencée par d’autres pays qui bénéfi-cient d’une bonne maîtrise de l’anglais et dont les coûts seraientencore plus faibles :• en Asie : Thaïlande, Malaisie, Philippines…• en Europe de l’Est : République tchèque, Pologne…• en zone Pacifique : Philippines, Iles Fidji…

Depuis peu se développe le concept du nearshoring. Dans cecas, le pays vers lequel est réalisée la délocalisation est prochegéographiquement et bénéficie de liens culturels et/ou histori-ques forts. Le Maroc est la parfaite illustration de ce conceptavec le développement rapide à Casablanca d’une activité offs-hore visant principalement les entreprises francophones. La Tuni-sie elle aussi se positionne sur ce marché.

Les bénéfices attendus del’externalisation ne sont pas toujoursau rendez-vous…

Le tableau suivant, issu de l’étude réalisée par Deloitte Consul-ting, permet d’avoir une vision des taux de succès et d’échec desopérations d’externalisation. Il indique :• les objectifs qui ont conduit les organisations interrogées à

externaliser,• le taux de participants ayant externalisé pour répondre à cha-

cun des objectifs, sachant qu’il était possible d’en sélection-ner plusieurs simultanément,

• le taux de participants pour lesquels la prestation n’a pas per-mis de satisfaire à l’objectif.

Force est de constater que les attentes sont variées mais tropsouvent déçues. La réduction des coûts, plébiscitée par 70 %des participants, apparaît comme l’objectif le plus fréquent. C’est

aussi celui qui a le plus de difficultés à être atteint avec 38 %d’insatisfaction. Le mécontentement quant à l’amélioration de laqualité de service est lui aussi notable avec 31 % des partici-pants. Le recentrage sur le cœur de métier et l’accès à desexperts de haut niveau déçoivent, dans une moindre mesure,respectivement à hauteur de 25 % et 20 %. (Cf tableau)

… et il peut parfois s’avérer préférablede ré-internaliser !

Toujours selon l’étude Deloitte Consulting, 25 % des participantsont ré-internalisé des fonctions après avoir réalisé qu’ils lesaccomplissaient mieux et/ou moins cher en interne.

La ré-internalisation, ou backsourcing, consiste à réintégrer, entotalité ou en partie, les fonctions et processus précédemmentexternalisés. L’exemple le plus emblématique, qui a marqué ledébut de la vague de ré-internalisations dans les pays anglo-saxons, a eu lieu en 2004. Il s’agissait de la rupture, par la célèbrebanque d’investissement « JP Morgan Chase », du méga-contratd’externalisation globale qui la liait avec IBM et de la ré-interna-lisation de 4 000 informaticiens. Des opérations de ce type ontlieu régulièrement, cependant elles sont rarement ébruitées carelles sonnent comme un constat d’échec autant pour le clientque pour son prestataire.

De plus la ré-internalisation peut ne concerner qu’un sous-ensemble du périmètre externalisé initialement. Nous n’assis-tons donc pas à une remise en question de l’externalisation maisplutôt à un rééquilibrage, quelquefois à marche forcée, vers unétat traduisant une élévation du niveau de maturité.

Une décision qui doit être préparéeavec soin

L’externalisation n’est pas une fatalité et doit reposer sur deschoix mûrement définis. A travers les interventions que nous réa-lisons à tous les niveaux du cycle de vie de la problématiqued’externalisation (définition des objectifs, analyse des processusinternes, définition du périmètre candidat à l’externalisation,accompagnement du changement…) nous relevons souvent lesdysfonctionnements suivants :

1. Des attentes excessives conjuguées avec une définition insuf-fisante des objectifs de l’opération d’externalisation ;

2. Une analyse insuffisante du périmètre à externaliser et de l’im-pact sur les processus métier de l’organisation ;

3. L’absence de structure de gouvernance permettant la défini-tion des processus de décision et le suivi de la prestation ;

4. Une capacité d’influence déraisonnable du prestataire surl’entreprise découlant de la mise en place de verrous fonction-nels et/ou technologiques.

La décision d’externaliser est stratégique. Bien préparée, ellepermettra de répondre de manière efficace à des objectifs qu’ilaurait a priori été impossible d’atteindre sans y recourir. En


contrepartie, elle implique des risques potentiels sur l’organisa-tion et ses opérations. Elle peut notamment entraîner une recon-figuration préjudiciable de la chaîne de valeur de l’entreprise.

Afin de limiter les risques, seules les activités non essentielles à lacapacité de création de valeur de l’organisation devraient êtrecandidates à l’externalisation. Ceci est d’autant plus importantlorsque l’entreprise dispose d’un avantage concurrentiel sur sesmarchés. Dans ce cas, il est impératif d’en identifier les fonde-ments afin d’être en mesure de le maintenir.

Par ailleurs, l’externalisation conduit à la mise en place d’un éco-système complexe entre la DSI et son prestataire. Afin de garan-tir la pérennité de cette relation, il sera nécessaire de mettre enplace une relation gagnant/gagnant. La négociation contractuelledevra prendre cet aspect en compte afin de ne pas menacer cetéquilibre qui doit s’établir sur le long terme et au bénéfice de cha-que partie. Dans cette perspective, le choix d’un prestataire estune étape critique au cours de laquelle il est impératif de vérifierles références clients présentées.

L’externalisation n’est pas une opérationdénuée de risques

Avant de procéder à une opération d’externalisation, il faut êtrevigilant quant aux risques auxquels la DSI et l’organisation elle-même s’exposent :

• Dérapage des coûts : Seuls les processus maîtrisés par uneorganisation devraient être candidats à l’externalisation. Dansle cas contraire, il est impossible de déterminer précisément lecoût du service rendu par le prestataire. A titre d’exemple,l’estimation financière ne doit pas se limiter aux coûts récur-rents et prendre en compte ceux liés à la mise en place desévolutions.

• Performances insuffisantes du prestataire : Si le niveau deservice rendu par le prestataire n’est pas conforme aux atten-tes, les répercussions peuvent toucher aux performancesmême de l’organisation. C’est le cas lorsque la fonction exter-nalisée participe d’un avantage concurrentiel, la capacité del’organisation à générer de la valeur risque alors d’être impac-tée.

• Gestion insuffisante des risques : Le transfert des risquesvers un prestataire sera toujours partiel car il est illusoire d’es-pérer couvrir la totalité des risques sur la base d’un contratd’externalisation. A titre d’exemple, en cas d’incident les com-pensations financières peuvent ne pas être équivalentes auxpertes. En effet, celles-ci sont par nature difficiles à évaluerdans leur globalité si l’image de l’organisation auprès de sesclients est impactée.

• Perte de compétences en interne : L’externalisationentraîne une érosion des compétences internes dommagea-ble pour l’organisation si elle impacte une fonction clé de lachaîne de valeur. Par ailleurs, il est nécessaire de disposer eninterne des compétences nécessaires au pilotage efficace duprestataire.

• Perte de confidentialité : Les prestataires peuvent avoiraccès à des informations confidentielles qui sont la propriétéde l’organisation. Cela entraîne une dégradation du niveauglobal de sécurité et un risque d’atteinte à la propriété intellec-tuelle, accru par le turnover du personnel du prestataire.

• Prise de contrôle par le prestataire : Un prestataire peutmettre en place des verrous (utilisation d’outils/formats pro-priétaires, large périmètre d’intervention…) lui permettantd’avoir un ascendant suffisant pour orienter les choix de l’or-ganisation ou de la DSI. Il peut s’ensuivre une perte de pouvoirde négociation qui se répercute directement au niveau descoûts ou de la qualité de service.

• Perte de confiance des collaborateurs internes : Pris entreplusieurs opérations combinant externalisation, délocalisa-tion et ré-internalisation, les collaborateurs risquent de perdreleurs repères. Les conséquences qui peuvent s’ensuivre vontde la démotivation des personnels à la perte de crédibilité dumanagement.

La gouvernance de la prestationd’externalisation

L’externalisation d’une fonction n’est pas une opération anodinepour une organisation, d’autant qu’elle ne se traduit pas pourautant par un transfert des responsabilités du point de vue duclient final. C’est à l’organisation qu’il revient de s’assurer, encontinu, que les risques sont gérés et que le prestataire fournit leniveau de service attendu.

Bénéfices attendus de l’externalisation Taux d’organisations ayant externalisépour cette raison (entre autres)

Tauxd’insatisfaction

Réduction des coûts 70 % 38 %

Amélioration de la qualité de service 57 % 31 %

Flexibilité, capacité à monter en charge 35 % Non disponible

Recentrage sur le cœur de métier de l’organisation 35 % 25 %

Accès à des experts de haut niveau 22 % 20 %

Transfert des risques au prestataire 22 % Non disponible


Il est donc essentiel pour l’organisation de conserver la maîtrisede la prestation à travers une entité de gouvernance de l’externa-lisation. C’est un processus actif que le client et le fournisseurdoivent adopter en commun et dont les actions consistent, demanière continue, à :• définir et mettre à jour les rôles et responsabilités des parties

prenantes au sein des processus de prise de décision,• gérer les escalades en cas de problèmes,• suivre le respect du niveau de service défini (disponibilité,

temps de réponse, capacité de traitement…),• superviser les coûts,• anticiper les changements et préparer les modifications

apportées au service,• etc…

La figure suivante illustre, à travers une adaptation de la roue deDeming, la place centrale de la gouvernance de l’externalisationtout au long du cycle de vie de la prestation.Le processus de gouvernance fournit les mécanismes permet-tant de suivre de manière continue les risques, les coûts, lademande et la fourniture de service. Il s’appuie sur des outils, desmétriques et des bonnes pratiques.

Parmi ces outils, le contrat de service, ou SLA (Service Level Agree-ment), occupe une place capitale. Il permet de décrire le service quele prestataire s’est engagé à fournir au client à travers :• les éléments quantitatifs caractérisant le service,• les responsabilités de chaque partie,• les engagements financiers en cas de respect ou non du

niveau de service,• les moyens de mesure et les modes de reporting,• etc…

L’incertitude quant à la capacité du fournisseur à disposer des res-sources nécessaires à la fourniture du service est un facteur de ris-que pour l’organisation. Pour éviter cet effet « boîte noire », leconcept de contrat de moyens opérationnels, ou OLA (OperatingLevel Agreement), a été développé. Il permet de s’assurer que l’en-semble des éléments et engagements du fournisseur de servicesont en place afin de pouvoir satisfaire au contrat de service.

Les bonnes pratiques pour la gouvernance de l’externalisationsont rassemblées au sein de différents référentiels, en particulier :• ITIL,• COBIT et les publications de l’IT Governance Institute,• le référentiel d’infogérance de l’AFNOR (XP Z67-801),

A propos de Deloitte

Avec 135 000 collaborateurs et associés, Deloitte est un cabinet d’envergure mon-

diale,présent dans près de 150 pays,sur les métiers de l’audit,du conseil, de l’exper-

tise comptable et de la finance.

En France, Deloitte Conseil et Risk Services regroupe 350 collaborateurs au sein

d’un réseau mondial constitué de 25 000 consultants. Ils interviennent dans des

domaines recouvrant les Systèmes d’Information, l’Externalisation, l’Efficacité Com-

merciale, la Fonction Finance, le Management des Risques, les Ressources Humai-

nes, la Stratégie et les Opérations.

Deloitte accompagne les organisations publiques et privées dans leurs projets de

transformation et leur recherche de la performance.

A partir de la compréhension des enjeux stratégiques et des métiers de ses clients,

Deloitte les aide à concevoir et à mettre en œuvre les organisations, les processus et

les systèmes d’information au service de leur stratégie.


• les travaux de l’OMPI relatifs à la gestion de la propriété intel-lectuelle lors des opérations d’externalisation.

Pour conclure

Depuis le début des années 2000, en pleine période de récessionéconomique, l’externalisation a été présentée comme une solutionpropre à réduire les coûts tout en permettant aux entreprises de sefocaliser sur leur cœur de métier. Cette vision trop souvent dogma-tique a pu, dans certains cas, réduire la fonction informatique aurang des « facilities » avec l’eau, l’énergie et les espaces verts !

De nombreuses déconvenues ont résulté du choix par défaut del’externalisation, sans prendre la peine d’analyser son coût réel etson impact sur la chaîne de valeur. Cela s’est traduit, principale-ment dans les pays anglo-saxons, par la renégociation decontrats avec les prestataires, voire par une ré-internalisationpartielle ou totale désignée par le terme de backsourcing.

Après une période d’espoirs déraisonnables, par ailleurs déçus, letemps de la maturité semble donc venu. L’intérêt de l’externalisa-tion, qui reste un outil précieux, n’est pas pour autant remis encause. Cependant, avant de prendre la décision d’externaliser, ilconvient de définir avec soin les enjeux de cette opération straté-gique. Chaque organisation doit se donner le temps et les moyensde déterminer, à partir de ses caractéristiques intrinsèques (métier,structure, historique, gestion des personnels…), la solution la plusefficiente entre l’outsourcing et la prise en charge interne. �

Références

• Deloitte Consulting : « Calling a change in the outsourcing market »

• http://www.interef.com/ateliers/grh_demain/fiches/externalisation.htm

• http://www.deseretnews.com/dn/view2/1,4382,600137853,00.html

• http://www.isaca.org/Template.cfm?Section=Home&CONTEN-

TID=21396&TEMPLATE=/ContentManagement/ContentDisplay.cfm.html

Vincent CHANALGouvernance et Stratégiedes Systèmes d’Information

Et toujours des informations sur nos partenaires,sur les sommaires des numéros d’IT-expert

http://www.it-expertise.com :un complément d’informationsà la version papier que vous recevez tousles 2 mois !



Et retrouvez de nouveaux services :• un moteur de recherche pour trouver les informations techniques qui vous intéressent• une nouvelle offre d’abonnement qui vous permet d’accéder aux anciens numéros d’IT-

expert en format pdf• les livres blancs techniques d’éditeurs de logiciels, de SSII, de nos partenaires…

dans une rubrique « téléchargements » ouverte à tous !

Comment ça marche ?


Assurerle succèsdes projetsavecla TierceRecetteApplicative

La TRA permet de garantir la qualité d’un

système d’information elle offre un retour sur

investissement (ROI) mesurable. Gérée sous le

prisme des risques métier,elle permet de garan-

tir un passage en production optimisé sur des

projets jugés sensibles voire critiques par la DSI.

La recette représente la phase primordiale de

tout projet informatique, malheureusement, elle

est trop souvent réduite, voire oubliée, faute de

temps ou de moyens (humains ou matériels). Il

en résulte des erreurs, parfois bloquantes pour

l’utilisateur, après le passage en production. Or,

la qualité des applications s’avère primordiale

pour garantir un service adapté aux demandes

et aux besoins des utilisateurs.


Déléguer l’organisation et l’efficacitéde la recette

La Tierce Recette Applicative permet à l’entreprise de s’abstrairedes contraintes organisationnelles et humaines liées à la gestiond’une cellule de recette. En recourant aux services d’un presta-taire, elle bénéficie également du savoir-faire et des processusrôdés sur le terrain de ses équipes.

Pour la Direction des Systèmes d’Information, la TRA permetde :

• Maîtriser ses coûts réels• Garantir un niveau de service et de qualité constant

auprès des utilisateurs tout en libérant des ressourcesqui vont être affectées à d’autres tâches

• Mieux gérer le personnel (évolutions de carrière, montéeet baisse de charge…) et gagner en flexibilité

• Accéder à des compétences pointues• Disposer de ces compétences uniquement selon ses

besoins• S’assurer de la qualité de service grâce à des engage-

ments de résultats

Pour l’utilisateur, la TRA permet :• D’avoir accès à des applications plus fiables (technique-

ment et fonctionnellement)• De s’assurer d’une meilleure prise en compte de ses

demandes par des informaticiens internes plus disponi-bles

• De gagner en qualité de service et en qualité des logi-ciels mis à disposition des utilisateurs

Les engagements sont la clé de voûte de l’édifice. Grâce à cesengagements contractuels pris par le prestataire sur des servicesmesurables, il devient possible d’obtenir la qualité de serviceattendue. Ces engagements portent sur :

• La qualité des livrables garantissant « zéro anomalie criti-que » en production, le respect des dates de livraison et latraçabilité des travaux,

• L’industrialisation permettant des gains de productivitédès la première année,

• La réactivité à travers la continuité de service et le traite-ment des demandes en un jour,

• La transparence et la réversibilité grâce à des reportings

Un facilitateur externe au carrefour de troismétiers

La Tierce Recette Applicative (TRA) incarne une démarcheconsistant à confier à un prestataire extérieur la recette d’applica-tions existantes, dans le cadre d’un contrat de prestation forfai-taire, comprenant des engagements de résultats en termes dequalité, de prix et de délais.

Il s’agit donc de créer un centre de services réalisant la recette ausein de l’entreprise cliente. Ce centre repose sur :

• La maîtrise de trois métiers : le métier du client, lesmétiers de la qualification et de la recette, et celui de lagestion de projet

• Un contrat forfaitaire,• Des engagements clairs et mesurables élaborés et vali-

dés par les deux parties,• Une démarche qualité via des processus et des indica-

teurs précis prédéterminés en commun,• Une industrialisation des processus de recette et de quali-

fication.

L’objectif de la TRA consiste à mutualiser et à capitaliser les outils(de test et de pilotage), les ressources et les méthodologies quel quesoit le projet, permettant ainsi de maîtriser les dépenses globales.

Tests et recette

Tests et recette

Tests et recette

Projet

Projet

Projet

Mise en production

Mise en production

Mise en production

Date de mise en production

3Phase

opérationnelle

1Phase

préliminaire

2Phase

probatoire

• Validation périmètre TRA • Etalonnage TRA • mise en oeuvre TRA opérationnelle

TempsT1 T2 T3

• Prise de connaissance• Analyse docs existants• Formations

• Finalisation convention de service

• Expertise TRA est acquise• Traçabilité TRA est étalonnée

T44

Réversibilité

• Transfert de compétence


La société MAP

10 années d’expérience dans le domaine de la recette et

du test, la volonté de l’excellence qualité et une parfaite

connaissance des métiers de nos clients, permettent à

MAP d’accompagner et de conseiller ses clients en vérita-

ble expert de la Qualité de leur SI. Aujourd’hui MAP est

reconnu comme le leader français de la qualité des Systè-

mes d’Information et intervient sur l’ensemble des sec-

teurs de l’économie nationale.

Philippe KRAMERDirecteur Général de MAP

Leader françaisde la qualité des S.I.

hebdomadaires, la capitalisation des connaissances etl’engagement de réversibilité (auditable à tout moment).

6 points clés pour une TRA réussie

Quelques conseils pour aider à la mise en œuvre d’une TRA :• Planifier une phase préliminaire afin de définir le périmètre et

les points d’amélioration que peut proposer le prestataire,• Définir contractuellement les engagements pris par le

prestataire et le client en chiffrant et en datant autant quepossible,

• Préciser l’ensemble des services compris dans la TRA,ainsi que les moyens et les délais mis en œuvre pour lesréaliser,

• Mettre en place des indicateurs précis permettant le suiviopérationnel de la TRA et le calcul du ROI,

• Communiquer en interne sur la mise en place de cettecellule et les modes d’interaction avec les différents ser-vices de l’entreprise,

• Valider chaque engagement et surtout les mesures et lesdélais en plein accord entre les deux parties. �

Voici des exemples de bénéfices obtenus sur desprojets incluant une TRA (ces gains sont dépendantsdu contexte client) :

• 95 % des anomalies détectées pendant laphase de qualification,

• aucune anomalie critique en production,• 20 % de gain de productivité pour l’activité de

recette dès la première année

Tout contrat de TRA doit absolument contenir uneclause de réversibilité. La réversibilité engage leprestataire à tout mettre en œuvre afin de permettreà son client de reprendre l’ensemble des activités derecette avec ses propres ressources. Ceci peut avoirlieu à tout moment, sur simple demande. Le délaientre la demande et l’application de la réversibilitéest défini contractuellement. Attention à bien définirles modalités et les moyens de cette réversibilité.

Pour la société MAP,TRA rime avec retoursur investissement

Fenêtre sur cour


Interview de Jean MOUNET,Président du SYNTEC Informatiqueet Vice-Président de Sopra Group

Le SYNTEC Informatique est la chambre professionnelle des SSIIet des éditeurs de logiciels.Nous avons interviewé son président Jean MOUNET, égalementvice-président de Sopra Group, au sujet de l’offshore.

� De plus en plus de projets sont offshorés mais peu de DSIsouhaitent communiquer à ce sujet, pourquoi une tellecrainte ?

Jean MOUNET : Je pense que la période de l’offshore non poli-tiquement correct est révolue, aujourd’hui l’offshore fait partie dupaysage. Cependant, il est encore un peu difficile d’avoir desretours d’expérience pour deux raisons principales : les projetssont encore faibles en nombre et les DSI n’ont pas encore assezde recul pour en parler. Je pense que dans quelque temps lestémoignages seront plus nombreux.

� Quels sont les pays de commande et les pays de destination ?

Jean MOUNET : Les Etats-Unis et la Grande-Bretagne sont lesdeux principaux pays de commande (85 à 90 %).

Les pays de destination sont plus nombreux : l’Inde (80 %), l’Europe de l’Est, le Maghreb et - depuis peu - l’Amérique du Sud.La France, comme tous les pays non anglophones, recherchedes sites offshore beaucoup plus variés pour essayer de tenircompte de l’aspect linguistique. Les Français regardent naturelle-ment vers le Maghreb dont les ingénieurs sont souvent formésdans les écoles françaises, où il existe une proximité linguistiqueet culturelle évidente, et où le décalage horaire est faible. Les Fran-çais travaillent aussi avec la Roumanie pour des raisons similaires.La répartition de l’offshore français se fait pour moitié en Inde etmoitié dans les autres pays. Les Allemands, quant à eux, travail-lent beaucoup avec les pays de l’Est : Pologne, Tchéquie, Slova-quie. Les Espagnols se lancent depuis peu dans de l’offshore enAmérique du Sud ou Centrale pour les mêmes motifs culturels etlinguistiques.

Certains spécialistes estiment que le coût de main-d’œuvre enInde commence à augmenter et réfléchissent à d’autres pays dedestination comme les Philippines, le Vietnam…La question des pays de destination n’aura jamais de réponsedéfinitive. Les pays de destination évolueront en fonction descaractéristiques de salaire et de qualité des ingénieurs qui serontformés.


La finalité est plutôt positive parce que cela permet à des payspauvres de se développer chacun leur tour.

� Quels sont les projets les plus difficiles à offshorer ?

Jean MOUNET : Les projets les plus difficiles à offshorer sontceux de petite taille, de courte durée, ainsi que les projets quinécessitent beaucoup d’évolutivité ou qui manquent de stabilité.D’autres ne peuvent être offshorés pour des raisons de confi-dentialité, lorsque le projet est, par exemple, lié au cœur de métierle plus intime de la société. Le dernier facteur qui empêche d’offs-horer est une mauvaise maîtrise de la langue du pays partenaire ;ce qui nécessiterait un investissement trop lourd. Quand, parexemple, toute la documentation est en français, les coûts de tra-duction peuvent s’avérer importants.Le projet « idéal » est une TMA stable sur de gros volumes et quel’on souhaite offshorer pour une durée de 3 à 5 ans.

� Pensez-vous que la mise en place de processus soit néces-saire ?

Jean MOUNET : Il est nécessaire de mettre en place des proces-sus qui permettent d’offshorer facilement des projets informati-ques. Cette mise en place de processus ne peut se faire que parle couple client/prestataire, la décision doit être commune. Il fautdévelopper la rigueur et le professionnalisme entre les SSII et lesclients pour que l’offshore soit efficace.

� Quelles en sont les conséquences humaines mais aussi enterme de qualité de développement ?

Jean MOUNET : L’offshorisation permet aux pays pauvres dese développer et d’augmenter le niveau d’instruction de leurpopulation en lançant de grand projet de formation des ingé-nieurs. Ce développement est positif pour l’économie mondiale.Pour les pays de « commande », l’impact a lieu sur le type de pro-fils recherché. Nous avons besoin de plus d’experts métiers,consultants, chefs de projets et moins de développeurs. Pourl’instant l’impact est assez faible en nombre.

Pour ce qui est de la qualité, les ingénieurs dans les pays tels quel’Inde, le Maroc, la Roumanie… sont de très bon niveau. Il fautjuste respecter les critères d’éligibilité et les processus d’indus-trialisation. Il ne faut jamais sous-estimer l’importance de la cul-ture et de la langue.

� Il est souvent reproché au SYNTEC de minorer l’impact durecours à l’offshore, quelle est la part des projets offshore enFrance aujourd’hui ?

Jean MOUNET : Non seulement nous ne minorons pas l’offs-hore mais je pense au contraire que c’est une évolution majeurede notre monde et de notre profession.Il faut distinguer deux « commanditaires » : les grands comptes,éventuellement via une SSII et les éditeurs de logiciels pour leursbesoins propres.Culturellement les éditeurs de logiciels ont toujours implanté descentres de R&D dans plusieurs pays, notamment aux Etats-Unis

pour une main-d’œuvre plus qualifiée et dans des pays à faiblecoût de main-d’œuvre. Le business model des éditeurs de logi-ciels est différent de celui des services informatiques.

Pour le marché des services informatiques de manière globale,ce qui est réellement offshorable ne représente plus que 30 à33 % du CA, part dans laquelle on trouve principalement l’inté-gration de systèmes, c’est-à-dire les projets au forfait et l’infogé-rance applicative (ou TMA). Je ne parle pas du BPO (BusinessProcess Outsourcing), quasi-inexistant en France à l’heureactuelle. Sur ces projets théoriquement offshorables, environ lamoitié n’est pas « éligible » parce qu’ils sont trop petits ou tropcourts (en effet près de 50 % du CA des SSII est fait sur desPME). Il faut atteindre une certaine taille de projet pour que l’offs-hore soit intéressant, une référence couramment utilisée serait de1 000 jours minimum. Il faut aussi prendre en considération queles projets offshorés sont quand même réalisés pour un tiers enlocal (pour le front office).

Aujourd’hui en France, la part de l’offshore sur le volume globaldes Services Informatiques est d’environ 3 %, mais 3 % de 12 %à 15 % (potentiel théorique). A titre de comparaison, les paysplus avancés sur ce sujet comme l’Angleterre et surtout les Etats-Unis consacrés 10 % de leur CA global à l’offshore.

� Pourquoi les pays anglo-saxons offshorent-ils plus que nous ?

Jean MOUNET : Les pays anglo-saxons sont culturellement plusouverts à ce sujet. Ils estiment que c’est un moteur de crois-sance et non une régression sociale. D’autre part, l’incitationfinancière est plus forte pour eux que pour nous. Le prix d’uneprestation en France pour un ingénieur donné est de 100, de 180en Grande-Bretagne et de 140 en Allemagne ou en Scandinavie.Les Anglais sont donc plus incités à offshorer pour réduire leurscoûts. Enfin les Anglo-Saxons n’ont pas le frein linguistiquenotamment avec l’Inde qui est le premier pays destinataire desprojets offshore.

� Pour conclure, comment voyez-vous l’avenir de l’informati-que en France sur ce thème ?

Jean MOUNET : C’est une évolution majeure dans la profession.L’offshore va continuer à se développer, surtout dans les grandscomptes. D’ailleurs, la croissance des projets offshore est supé-rieure à la croissance actuelle du marché.En 2008 ou 2009, je pense que l’on atteindra le chiffre de 5 % duCA des services informatiques qui sera offshoré. �


Livres

Conduite de projets informatiques offshorePar Eric O’NEILLPrix public : 45 euros - 336 pages - ISBN : 2-212-11560-1Editions Eyrolles

Manager un projet informatiquePar Olivier Englender et Sophie FernandesPrix public : 32 euros - 270 pages - ISBN10 : 2-212-53913-4Editions d’Organisation

Conduite de projets informatiques offshore

Éric O’Neill se spécialise dans l’offshore dès la fin des années 1980, alors qu’ildébute sa carrière à New York. De retour en France en 1994, il mène de grandsprojets d’offshore informatique, puis y crée son entreprise Outsourcing Advan-tage. Ce guide pratique s’appuie donc sur près de 30 années d’expérience deterrain sur ce type de chantier. Véritable outil professionnel, il multiplie lesconseils opérationnels et les check-lists, et propose une multitude de schémaset tableaux chiffrés. Par ailleurs, le livre ne se contente pas d’aborder la gestiondes phases de projets, mais apporte aussi une vision mondiale de l’offshore, demultiples éléments humains comme la motivation des hommes ou les décala-ges de salaires… Bref, une référence incontournable !

Manager un projet informatique

Les méthodes, les normes et les modèles défilent dans cet ouvrage très com-plet. Les auteurs ont choisi un découpage judicieux en trois parties : gérer unprojet de A à Z, les clés du chef de projet, les ressources. Cycles de vie, estima-tion de la charge, évaluation des risques, droits d’auteurs et propriété intellec-tuelle, cadre légal et contrat… tous les aspects de la direction de projets sontbien présents. LE lecteur appréciera les multiples encadrés « Conseils », et« Bon à savoir » qui émaillent l’ouvrage. On regrettera cependant le ton très(trop ?) sérieux du livre, et le peu de place réservé aux aspects humains (moti-vation des équipes, modes relationnels avec les utilisateurs, etc.). Ainsi, lesauteurs ne consacrent que deux pages à la conduite du changement dont ilsaffirment pourtant qu’il « constitue l’une des principales causes d’échec desprojets informatiques. »

Rubrique à brac


Les évolutions des débits réseau, les déréglementations des télécoms, les changements tech-

nologiques au niveau de l’informatique et de la téléphonie, ainsi que les nouveaux usages

demandés par les utilisateurs sont autant de facteurs qui non seulement sont à l’origine mais

encore poussent la convergence informatique et téléphonie que l’on observe depuis quelques

années.

Mais quelles sont les évolutions technologiques qui ont conduit à cette convergence ? Quels

sont les besoins des utilisateurs ? A quoi les équipes IT et téléphonie doivent s’attendre ? Quel-

les sont les grandes orientations dans les prochaines années ?

Etat de l’art de la convergence :lien entre informatiqueet téléphonie


Des évolutions technologiques séparéesmais similaires

Sans les évolutions des débits réseaux dans les cinq dernièresannées, la convergence que l’on observe en ce moment n’auraitpas été possible. Cependant seule l’augmentation des débitsréseaux et la réduction de leur coût n’auraient pas suffit ; lesdiverses mutations qui ont touché préalablement les domainesde l’informatique et de la téléphonie étaient indispensables.

Du mainframe à la flexibilité

Revenons à l’époque des premiers systèmes informatiques.Ceux-ci se composaient d’un mainframe avec des terminauxpassifs. Le constructeur du mainframe contrôlait alors à la fois lematériel, le système d’exploitation et les applications.Les différentes évolutions qui ont touché les réseaux ces derniè-res années ont abouti à une augmentation des débits tout enréduisant les coûts associés. L’accès à Internet a ensuite profon-dément changé la donne en imposant entre autre des protocolesde communications standardisés de façon globale. Le premierpas vers la convergence venait d’être réalisé.

Nous observons actuellement dans le secteur des télécoms lamême transformation que celle qui a été vécu dans l’informatique ily a une trentaine d’années. La comparaison avec la téléphonie tra-ditionnelle est assez simple à faire. Les PBX traditionnels sont com-parables aux mainframes dans le fonctionnement, à savoir un nœudcentral sur lequel se connectent les terminaux que sont les télé-phones, les systèmes d’exploitations associés à ce matériel et lesapplications sont édités par le constructeur du PBX. Cette compa-raison peut se poursuivre en ce qui concerne la maintenance dumatériel, la mise à jour du système et des applications.

Il n’y a pas encore très longtemps, les terminaux étaient connec-tés en direct sur les PBX. Les entreprises devaient alors gérer plu-sieurs réseaux étanches les uns par rapport aux autres : voix,donnée et éventuellement réseau sans fils. Chaque réseau ayantses propres terminaux, protocoles et outils de supervision. Cesinfrastructures en silos étanches ne sont plus adaptées auxbesoins des entreprises d’aujourd’hui.

Afin de répondre à une forte demande de leurs clients et pourpermettre une réduction des coûts liés à l’infrastructure réseau,les acteurs de la téléphonie d’entreprise ont créé la TOIP (Tele-phony Over IP). L’utilisateur utilise son téléphone de la mêmefaçon qu’habituellement alors que la voix est transportée sur leréseau de données. Dans ce cas la technologie utilisée implé-mente une numérisation de la voix très rigide et impose descontraintes de temps de réponse, débit du réseau.Malgré ces contraintes, en réduisant voire supprimant le réseaude téléphonie traditionnelle, les entreprises ont gagné en flexibi-lité tout en réduisant les coûts d’administration des réseaux.

La convergence sur le poste de travail

De leur côté, les accès au réseau Internet se sont multipliés, il estdésormais possible de se connecter sans fil depuis sa maison, un

hall d’aéroport, une chambre d’hôtel… Les débits et la qualité sesont améliorés et vont continuer à évoluer. Autant de raisonspour lesquelles les utilisateurs sont de plus en plus nomades.

Sur le poste de travail, c’est la gestion des données qui subit unetransformation. Les cycles de décision des entreprises se sontaccélérés, les collaborateurs ont besoins d’avoir accès aux don-nées les plus à jour en tout lieu et à tout moment. Inversement, ildevient indispensable de pouvoir partager et publier l’informationen temps réel.

Cette modification profonde des méthodes de travail fait apparaî-tre certains besoins comme :• Quand et comment joindre le bon interlocuteur ?• Comment partager un message vocal ou simplement l’archi-

ver comme élément d’un dossier ?• Comment intégrer ma disponibilité dans les processus métier

de l’entreprise ?• Comment partager un même document avec des collabora-

teurs distants ?• Comment créer une conférence audio/vidéo avec des parte-

naires extérieurs ?• Comment gérer ses communications vocales entrantes ?

C’est l’ensemble de ces points qui sont adressés par l’unificationdes communications.

Les communications unifiées

Les communications unifiées sont une approche qui consiste àrendre à l’individu le contrôle de ses communications.Il est évident que cette approche se concrétise entre autre eneffaçant les barrières qui ont existé pendant plusieurs annéesentre les réseaux voix, données et vidéo. L’hétérogénéité desoutils de communications disparaît alors au profit de l’individu.Pour être complète, l’approche des communications unifiée doitaussi prendre en considération l’état de l’utilisateur : capacité àcommuniquer, disponibilité…

Sur ce marché en pleine expansion (+21% en 2006 selon Infone-tics Research), on retrouve les grands acteurs du marché infor-matique, des réseaux et des télécoms. Chacun ayant développéson approche des communications unifiées cohérente avec soncœur de métier.

C’est ainsi que l’on retrouve sur ce sujet des Microsoft, IBM,Cisco, Nortel ou encore Oracle s’étant engagé sur ce sujetrécemment. Vu l’historique existant dans le monde des télécoms,l’hétérogénéité des interfaces existantes, les partenariats sontnécessaires.

Microsoft a ainsi passé des accords avec des constructeurs depasserelles de communications et des constructeurs de PBXcomme Nortel à travers l’ICA (Innovative CommunicationAlliance) pour délivrer une solution logicielle intégrée et certifiéeprenant en compte l’existant.


De nouveaux besoins, des changementsdans les équipes IT

De par le positionnement central sur l’individu des communica-tions unifiées, tout projet d’implémentation de communicationunifiée aura un impact autant sur les utilisateurs que sur les équi-pes d’infrastructure.

La vision de l’utilisateur

Nous l’avons compris, l’utilisateur est positionné au centre dusujet des communications unifiées en le rendant plus productif etplus efficace.

L’ergonomie des outils de communications unifiées a une placede choix dans son acceptation par les utilisateurs. Il ne fautcependant pas négliger l’importance de l’intégration de ces outilsdans l’environnement de travail de l’utilisateur, dans les proces-sus de l’entreprise ou encore sa capacité à collecter des donnéesprovenant de sources d’informations différentes.Par exemple, le client Communicator de Microsoft Office Com-munications Server 2007 agrège les informations du calendrierde l’utilisateur ainsi que l’état du poste de travail pour définir laprésence de l’utilisateur. Si ce dernier est en réunion, son état deprésence passera automatiquement en "en réunion". Communi-cator va aussi intégrer l’état du poste à savoir est-ce que l’utilisa-teur a verrouillé sa session de travail, auquel cas, il apparaîtra"absent".

Il n’est pas rare d’avoir des équipes qui collaborent à travers dif-férents fuseaux horaires, différentes cultures voire continents. Enintégrant la notion de présence dans ces outils, les équipes éloi-gnées peuvent trouver plus efficacement l’expert à même de

répondre à une demande ponctuelle. L’agrégation de sourcesde donnée peut aussi, par exemple, récupérer des informationsd’heures de travail ou d’absence du bureau et donc gagner dutemps à identifier le bon interlocuteur.Les communications unifiées se concrétisent souvent dans unpremier temps pour l’utilisateur dans l’apparition de la message-rie instantanée d’entreprise. A l’opposé d’un outil de chat surInternet, la messagerie instantanée d’entreprise est administra-ble, des mots clefs peuvent être bloqués et les conversationsarchivées.

La convergence téléphonie / informatique se destine actuelle-ment à des populations très nomades ou utilisant fortement letéléphone. A terme on peut imaginer que le téléphone disparaîtraau profit d’une interface de communication purement logiciellequi sera accessible et configurable de n’importe où (pour peuque l’administrateur l’ait autorisé).

C’est au niveau des équipes de travail que l’apport des commu-nications unifiées se fait ressentir le plus vite lors de la miseen œuvre. C’est un point à prendre en considération lors d’undéploiement. Le retour sur investissement sera plus rapide etplus visible si les collaborateurs bénéficient ensemble des fonc-tionnalités des communications unifiées. Dans le cas contraire, ily a fort à parier que l’utilisateur continuera à utiliser son télé-phone comme avant, enfin son téléphone portable…Avant d’arriver à une convergence informatique et téléphonieréussie, un projet complet doit être mené par les équipes IT.

La convergence vue par les équipes IT

Une des difficultés de la mise en œuvre des communicationsunifiées pour les équipes IT trouve sa source dans les natures

Communications unifiées

Des réseaux propriétaires et des expériences utilisateurs cloisonnées…

…vers des moyens de communications logiciels centrés sur l’individu.


même des environnements qui convergent. D’un côté, le réseaude données prévu pour véhiculer un contenu l’ordre et le délailivraison n’est pas impératif ; de l’autre, un réseau de circuitsprévu pour transmettre du contenu dans un laps de temps déter-miné.

Il s’agit donc de réussir soit à piloter le réseau de données pourdélivrer la voix en temps réel soit à s’adapter aux conditions duréseau existant. Ce sont assez schématiquement les visionsqu’ont respectivement Cisco et Microsoft.Pour Cisco le réseau est au cœur de la démarche et à travers desinitiatives comme SONA (Services Oriented Architecture) leréseau est piloté de bout en bout afin de permettre l’établisse-ment des communications. Le réseau IP permet littéralementl’établissement de circuits de communications.

L’approche prise par Microsoft a été d’exploiter le codec RTAudio. Ce codec large bande s’adapte aux conditions du réseauà la fois en terme de débit mais aussi en terme de latence. Cetteapproche permet aussi d’exploiter les communications unifiéesen dehors du réseau géré de l’entreprise, par exemple en dépla-cement depuis sa chambre d’hôtel.Dans tous les cas, il est évident que la qualité du transport sera unfacteur déterminant dans la réussite de l’implémentation d’unesolution de communications unifiées.

Comme on touche un sujet proche de la vie privée, la confiden-tialité des conversations téléphoniques est toujours un sujet sen-sible. Autant avec une connexion filaire directe entre le téléphoneet le PBX, il était assez difficile d’écouter plusieurs conversationssimultanément, autant avec la transmission de ces échanges surun réseau IP il est indispensable de considérer ce sujet dès ledébut.

Au-delà des considérations réseau, un projet autour de la conver-gence va réunir autour d’un même thème des équipes peu habi-tuées à communiquer entre elles : les équipes en charge duréseau de téléphonie et les équipes en charge des systèmesinformatiques. Le vocabulaire utilisé par les deux équipes seradifférent, il est alors important de donner le vernis nécessaire àchacune des équipes pour comprendre les attentes de l’autre.A terme, la convergence des deux infrastructures permettra uneoptimisation des dépenses en ayant une infrastructure com-mune, une supervision unique et des coûts de maintenance sim-plifiés.

Vocabulaire, sécurité, approche, autant de sujets structurant pourune équipe IT qui va concrétiser les communications unifiées.C’est probablement le plus grand défi à relever dans les prochai-nes années par les directions informatiques.

Une vision à moyen terme

L’expérience montre qu’il est impossible de prédire l’avenir dansles nouvelles technologies. Cependant on peut déjà voir quel-ques grandes directions dans lesquelles seront faits les investis-sements dans les prochaines années.

Intégration de la voix aux processus de l’entreprise : actuel-lement, la voix reste un moyen de communications principale-ment entre individus. Une fois que la convergence se sera établiedans les entreprises, naturellement on verra les communicationsvocales intégrées dans les processus comme le mail l’a été. Parexemple, pourquoi ne pas notifier automatiquement par télé-phone le responsable de production quand survient un incidentmajeur sur une application critique, les incidents mineurs étantnotifiés par mail.

Sécurité : Nous avons vu que la sécurité est un enjeu majeurdans cette convergence. La confidentialité est un point à prendreen considération dès à présent. Avec la réduction des prix descommunications téléphoniques, l’arrivée d’opérateurs de télé-phonie sur IP uniquement en remplacement des opérateurs tra-ditionnels, nous allons voir apparaître les mêmes risques etmenaces que ceux que l’on connaît sur la messagerie. On parleraalors de SPIT : "SPAM over IP Telephony", la capacité d’analyserle contenu des communications sera donc cruciale.

Mobilité : La même convergence sera attendue au niveau desmobiles, les interfaces voix et donnée convergeront. La notion deplusieurs numéros de téléphone tendra alors à disparaître au pro-fit d’une seule adresse de contact. Certes les premières initiativesmenées par Skype de transporter la voix sur les canaux de don-nées ont généré des freins de la part des opérateurs mais lademande et la technologie sont là.

Conclusion

La convergence informatique et téléphonie est actuellement uneréalité qui se concrétise par les communications unifiées. Lebénéfice portera autant pour les utilisateurs dans leur productivitépersonnelle ou à travers les groupes de travail que pour les équi-pes IT qui, en unifiant les réseaux optimiseront leurs dépenses entout en offrant de nouveaux services.La route n’est pas finie, les opportunités qui s’ouvrent dans cedomaine pour les entreprises, leurs partenaires ou clients sontinfinies. �

Damien CAROArchitecte InfrastructureMicrosoft

- Intrusion

- Phishing

- Chevaux de Troie

- Sécurité de la VoIP

- Mobilité

- Continuité d’activité...

www.infosecurity.com.fr

- Archivage et conservation

de l’information

- Virtualisation du stockage

- Gestion de cycle de vie

des données (ILM)

- Protection des données...

www.storage-expo.fr

EXPOSITIONS & CONFÉRENCES

21-22 novembre 2007CNIT-Paris La Défense

ET VOUS ?Avez-vous reçu votre badge d’accès ?

Réservé aux Professionnels

DEMANDEZ VOTRE BADGE GRATUIT !www.infosecurity.com.fr ou www.storage-expo.fr

Code invitation : ITE

Ne changez rien à votre infrastructure ! Avec la solution logicielle Voix sur IP (VoIP) de Microsoft, changez

d’avis sur la téléphonie. Bénéficier des avantages de la VoIP n’est

plus désormais synonyme de gros investissements et de déploiement

complexe. Pourquoi ?

Parce qu’il ne s’agit plus de matériels mais de logiciels. Vous pouvez

maintenant conserver votre infrastructure en l’état (votre PABX,

vos passerelles téléphoniques, et même vos téléphones).

Vous n’avez qu’à ajouter le bon logiciel. Un logiciel intégré à Active

Directory, Microsoft Office, Microsoft Exchange Server, et à votre

PABX. Ainsi, vous optimisez l’investissement réalisé dans votre PABX

en l’intégrant à votre nouvelle solution logicielle VoIP. Ce qui est

en place aujourd’hui fonctionne bien ; cela fonctionnera encore

mieux avec le bon logiciel. Pour en savoir plus, rendez-vous sur

www.microsoft.com/france/voip