ip 189 déc 2000 - yves constantinidis consultant · n° 189 décembre 2000 3 fini, périmé,...

Dossier

DDéévveellooppppeemmeennttCChhrriissttoopphhee BBllaaeessss,, AAllaaiinn FFeerrnnaannddeezz,, JJeeaann--MMaarrcc BBeerrlliioouuxx,, GGiilllleess MMeerrggooiill,,JJeeaann--MMaarrcc LLeejjeeuunnee,, YYvveess CCoonnssttaannttiinniiddiiss

P R O F E S S I O N N E L L E

Internautes

SSoouurriieezz,,vvoouuss êêtteess ppiissttééssEErriicc LLaarrcchheerr

Achats informatiques

DDiimmiinnuueerr lleessrriissqquueess eett nnééggoocciieerrGGiilllleess BBllaanncchhaarrdd

Refacturation des réseaux

LLaa ddiipplloommaattiieess’’iimmppoosseeEEddwwaarrdd YYoouunnkkeerr,, DDaavviidd NNeeiill

Mensuel • Numéro 189 • décembre 2000

oonntt aauussssii ccoollllaabboorréé àà ccee nnuumméérroo ::

AAnnddrréé BBoorrssEErriicc BBoouullaannggeerr

SSoommmmaaiirree ccoommpplleett eenn ppaaggeess 44 eett 55Bouhot & Le GendreProduits et Services

n° 189 décembre 2000 3

Fini, périmé, dépassé, obsolète… Si l’on devait croire certains discours, c’en serait fini du développement et dela programmation.

Face à l’offre florissante en matière de progiciels, d’outils bureautiques et de services ASP, le programmeur seraitune race en voie de disparition. Il suffirait en effet d’installer un produit bien choisi et de définir rapidement unparamétrage adapté, ou de se connecter à un fournisseur de services, pour accéder au nirvana du système d’infor-mation. Qui plus est, le progiciel apporterait dans ses bagages un catalogue de “bonnes pratiques” permettant l’amé-lioration des processus. Et le management pourrait toujours faire porter au progiciel le chapeau des évolutions del’organisation, ce qui lui éviterait de se retrouver en première ligne pour conduire le changement. Enfin, les outilsbureautiques aux mains des utilisateurs suffiraient à combler les espaces laissés vides par les grands progiciels.

La réalité est toute autre. Les gros progiciels sont des outils précieux, mais ils réclament souvent un paramétrage trèslourd. Il s’agit alors de traduire des spécifications fonctionnelles sous une forme technique, qui ne ressemble certespas à Cobol, mais constitue tout de même une variété de code source. De plus, dès lors qu’une organisation veut dif-férencier quelque peu son service, il lui faut souvent aller au-delà des fonctions offertes : d’où le recours à desdéveloppements avec des langages “classiques” du style Java, C ou C++.

Par ailleurs, l’accélération du cycle des technologies conduit souvent les organisations à entamer des projets avantque les outils de base ne soient totalement mûrs ou intégrés. Il faut bien alors réaliser l’intégration et, là encore, ily a du pain sur la planche pour les programmeurs. Quant à réutiliser telles quelles, dans des systèmes décision-nels, les données issues des systèmes de gestion, cela s’avère bien difficile du fait de la faible qualité des donnéesexistantes. Il faut donc réaliser des logiciels ad hoc chargés de filtrer et de corriger les données avant injection dansles datawarehouses.

Enfin, les outils en principe destinés aux utilisateurs avertis sont peu utilisés et c’est encore aux développeurs de réa-liser les requêtes SQL ou Business Object ou les macros Excel un peu complexes.

Au total, les activités de développement ont encore de beaux jours devant elles. Elles ont seulement tendance à secomplexifier et à réclamer des outils et des compétences de plus en plus pointus. Les technologies et les méthodesau service du développement sont donc toujours d’actualité.

Dans ce numéro, L’Informatique Professionnelle vous en fournit les principales clés.

Jean-Marc Berlioux

Développeurs :la fin des temps !

Edito

Développer sous Linux

som

ma

ire Comment faire, comment choisir ?

Le choix de la plate-forme Linux pour effectuer un développement logicielest une décision importante. Mais, outre le système d’exploitation, il fau-dra aussi choisir le langage et les bibliothèques.

Christophe Blaess

p. 6

La collecte des données est essentielleLa collecte des données est une étape majeure d’un projet d’informatiquedécisionnelle. Pour réussir, les règles et les objectifs ne doivent pas êtreperdus de vue.

Alain Fernandez

p. 11Décisionnel

Orientations

La réduction fonctionnelle s’imposeLa suppression des fonctions non indispensables est un acte de saine ges-tion. En identifiant les fonctions dont le coût est supérieur à la valeur,l’analyse de la valeur permet de décider.

Jean-Marc Berlioux

p. 17

Architectures à composants

Savoir-faire et organisationLe développement et l’implémentation d’une architecture à composants impo-sent une réorganisation complète et une coordination des acteurs du projet.

Gilles Mergoil

p. 19

Un SOAP opéra !La mort de DCOM ne fait plus de doute. En 2003, plus de 70 % des e-ser-vices invoqués au travers de l’internet le seront en utilisant SOAP deMicrosoft.

Jean-Marc Lejeune

p. 23

Déve loppement

e -bus iness

Sommaire

L'Informatique Professionnelle4

La mort de DCOM

p. 25 Un acteur de qualitéLes exigences des consommateurs doivent être placées au cœur de la qua-lité des développements. Reste à qualifier leur vision et à endiguer leurimmaturité.

Yves Constantinidis

L’utilisateur

Internautes

p. 30 Souriez, vous êtes pistés !Attention, sur l’internet, la liberté est surveillée. Que ce soit à l’intérieur ouà l’extérieur des entreprises, des yeux et des oreilles observent en perma-nence le moindre de vos déplacements. Eric Larcher

p. 35 Diminuer les risques et négocierLes achats informatiques coûtent cher. Pour diminuer les risques etles coûts, acheteurs et informaticiens doivent travailler de pair.

Gilles Blanchard

p. 37 La double compétence est de rigueurPour gérer l’indispensable compromis entre les besoins, la techniqueet l’organisation, le concepteur doit disposer de la durée et se formeraux impératifs des métiers.

André Bors

L'Informatique Professionnelle - Mensuel publié par Gartner • Directeur des rédactions : Olivier Le Gendre • Directeur de la publication : Norbert MiconnetRédacteur en chef : Jean-Marc Berlioux • Rédacteur en chef délégué : Jean-Michel Atzel • Comité éditorial : Jean-Pierre Corniou, Serge Leclerc, Catherine Leloup, ChristianMorfouace, Jacques Pantin, Frédéric-Georges Roux, , Pierre Lora-Tonet, Serge Yablonsky • Secrétaire de rédaction/Maquette : Céline Holleville • Gestion des abonnements :Sylvie Garofalo • Siège social : Gartner, Immeuble Défense Bergères - TSA 40002 - 345 avenue Georges Clemenceau - 92882 Nanterre cedex 9 - Tél : 01 41 35 15 15 - Fax : 01 4135 15 10 • Abonnements : France 2 450 FF HT (tva 2,10 %) - Etranger 2 660 FF • Commission Paritaire 61050 • RC 350 624 102 - SARL au Capital de 1.012.500 F • ImprimerieModerne de Bayeux - Zone Industrielle - 7 rue de la Résistance - BP 133 - 14401 Bayeux cedex - Tél. 02 31 51 63 20.

Management

Sommaire


Ressources humainesConcepteurs

p. 41 La diplomatie s’impose !Plusieurs méthodologies de refacturation des télécommunicationsexistent. Une seule est vraiment efficace : la diplomatie. Etude de cas.

Edward Younker, David Neil

TélécommunicationsRefacturation des réseaux

p. 46 De la subjectivité à l’objectivitéDéclarations. Le régime fiscal des indemnités de licenciement achangé. Gare aux redressements !

Eric Boulanger

Arrêts et tendancesIndemnités de licenciement

p. 49 Les e-mails sont-ils des correspondances privées ? • Portage de .NETsur Linux • USA : doublement des visas high-tech • Oracle9i :Marketing et poudre aux yeux • Batteries Dell : au feu ! • Internet etgrandes oreilles : La Chine vous salue bien !

En brefA suivre...


Le choix d’effectuer le développe-ment d’un logiciel en langage Cou C++ sous Linux recouvre enréalité deux prises de décision. En

premier lieu, on fait le choix d’un sys-tème d’exploitation. L’utilisation de Linuxcomme environnement de développe-ment est une option nouvelle dans lemilieu industriel. La seconde décisionconcerne le langage et les bibliothèquesemployées. D’autres langages sont eneffet disponibles, et il faut être en adé-quation avec le but final de l’applicationet avec le public visé. Nous allons exa-miner ici les possibilités qu’offrent lesoutils disponibles sous Linux pour unebonne réalisation logicielle en langage Cou C++.

Développement sous LinuxNous avons indiqué que le choix de laplate-forme Linux pour effectuer undéveloppement logiciel est déjà unedécision importante. Plusieurs motiva-tions peuvent être à l’origine de cechoix. Tout d’abord, Linux constitueprobablement le meilleur systèmed’exploitation pour la diffusion de logi-ciels libres. L’esprit qui anime la com-munauté Linux est tel qu’un nouveauprojet est généralement bien accueilliet l’enthousiasme des participants per-met la progression rapide d’un logiciel,pour peu que l’équipe soit suffisam-ment motivée.Ce type de choix n’est plus seulementle fait d’amateurs ou d’étudiants : cer-

Développer sous Linux

Comment faire,commentchoisir ?

Développement


Le choix de la plate-formeLinux pour effectuer undéveloppement logiciel

est une décisionimportante

Pour assurer la réussite d’un développement applicatif sous Linux, il estimportant de bien cibler les objectifs. Ceux-ci conditionneront à la fois lesoutils et les langages de programmation à utiliser.

Ingénieur en informa-

tique, il intervient comme

conseil et développeur

auprès de compagnies

aériennes, d’aéroports ou

de centres d’études.

Christophe Blaess

taines entreprises ont déjà compris l’in-térêt immédiat que présente pour ellesl’adhésion à la logique des logicielslibres. C’est le cas, par exemple, pourcertains fabricants de périphériquespour ordinateurs : ils diffusent les spé-cifications techniques de leur matérielet fournissent une assistance pour ledéveloppement de drivers libres per-mettant le fonctionnement sous Linux.Le choix du système Linux commeenvironnement de développement peutaussi être motivé par la qualité desoutils présents “librement” et larichesse de la documentation dispo-nible sur Internet. Dès son installation,une distribution Gnu/Linux comprendtous les outils logiciels nécessaires auprogrammeur – éditeurs, compilateurs,débogueurs – et ce pour l’ensemble deslangages informatiques courammentemployés.De plus, le portage des applicationsvers d’autres environnements Unix estsouvent très rapide, puisqu’il ne néces-site qu’une simple recompilation desfichiers source. Il est alors possible dedisposer de stations de développementde type PC, puissantes et économiques.Notons également que Linux, loind’être limité aux PC, est disponible surun large éventail de machines. Lesapplications tournant sous ce systèmedisposent ainsi automatiquement d’uneportabilité “interne” sur une gammecomplète d’architectures et de proces-seurs différents.Cependant, la motivation la plus fré-quente pour le développement sousLinux, est tout simplement le choix dece système comme plate-forme appli-cative finale. Cette solution est depuisplusieurs années retenue dans de nom-breux laboratoires, centres d’études,etc. L’utilisation de Linux comme envi-ronnement principal dans le domainedes applications industrielles est plusrécente, mais une fois les réticences

initiales vaincues, on assiste générale-ment au sein d’une entreprise à uneprogression lente mais continue duparc de machines fonctionnant sousLinux.Pour assurer la réussite d’un dévelop-pement applicatif sous Linux, il estimportant de bien cibler dans quellecatégorie s’inscrit le produit : logiciellibre diffusé sur Internet ou réservé àun usage interne ; application destinéeà être largement portée sur d’autressystèmes d’exploitation ou au contrairelimitée à une utilisation uniquementsous Linux. Ceci influe à la fois sur lesoutils et langages de programmation àemployer, ainsi que sur les buts priori-taires que l’équipe de développeursdevra se fixer.

Choix du langageDans le monde industriel, l’un despoints forts les plus appréciés du sys-tème Linux est sa stabilité. Les stationsconfigurées correctement peuvent pré-senter des temps de fonctionnementinterrompu très longs. Les seuls arrêtsdu système sont alors dus aux compo-sants matériels, et non au logiciel.D’où des taux de disponibilité du sys-tème particulièrement élevés, ce qui esttrès précieux dans certains types d’ap-plication.L’exemple le plus fréquemment cité estcelui du serveur web. Le logiciel libreApache est très utilisé pour constituerdes serveurs performants et peu coû-teux sous Linux. Pour configurer etpersonnaliser un serveur réseau, onemploie souvent le langage Perl, quipermet d’écrire rapidement de petitsscripts puissants, pour dynamiser lecontenu des pages web, programmerdes robots logiciels gérant des listes dediffusion ou encore trier et répartir lecourrier ou les articles Usenet.Pour des applications nécessitant uneimplication technique plus importante,

Comment faire, comment choisir ?


On assiste à uneprogression lente maiscontinue du parc demachines fonctionnantsous Linux

L’un des points forts lesplus appréciés du systèmeLinux est sa stabilité

Christophe Blaess

les langages les plus utilisés sont le Cet le C++. La rapidité et la puissancedes applications produites constituentdes arguments de choix. En contrepar-tie, la portabilité est un peu plus res-treinte, essentiellement en ce quiconcerne l’interface utilisateur.En fait, le noyau Linux, ainsi que tousles utilitaires système, sont écrits en C.L’emploi de ce langage permet doncd’accéder facilement aux ressources debas niveau indispensables dans cer-taines applications (interfaçage, écri-ture de pilote de périphérique, etc.) Lelangage C offre des avantages tech-niques en termes de puissance et derapidité convenant tout particulière-ment aux applications scientifiques etindustrielles. De plus, en tant que lan-gage compilé, il fournit un fichier exé-cutable autonome, ce qui assure laconfidentialité des algorithmes utilisésdans les sources. Cet aspect constitue,dans certaines circonstances, un avan-tage réel sur les langages interprétés.L’environnement graphique utilisé sousLinux, comme pour les autres Unix, estle système X-Window. Ce système trèspuissant est particulièrement intéres-sant sur des machines en réseau, car ilpermet de déporter des affichages surdes stations distantes. X-Window n’im-pose que très peu d’obligations enterme d’aspect ou de comportementdes applications. C’est pourquoi denombreuses bibliothèques graphiquesdifférentes coexistent, compliquantparfois quelque peu le portage desapplications.Sous Linux, deux environnements gra-phiques principaux existent actuelle-ment : le système Gnome, issu du pro-jet Gnu, et le système KDE. L’uncomme l’autre sont installés automati-quement avec la plupart des distribu-tions actuelles, et c’est l’utilisateur quichoisit son environnement favori lorsde la connexion. Ces environnements

jouent sur l’aspect et le comportementdes fenêtres (menu système, bordures,réaction à la souris, etc.), mais ils ontaussi un rôle important dans la commu-nication entre les applications.Choisir d’utiliser l’environnementGnome ou KDE pour l’interface utili-sateur d’une application n’est donc pasune action innocente. D’autant qu’ilfaut alors être conscient que la portabi-lité de l’application hors de l’universLinux est largement diminuée. Uneautre possibilité est d’employer unebibliothèque portable sur l’ensembledes systèmes Unix. L’environnementMotif s’est imposé comme standard defait dans les systèmes informatiquesindustriels. Il en existe plusieurs implé-mentations commerciales sous Linux,ainsi qu’une implémentation librenommée Lesstif. L’utilisation de cesbibliothèques permet d’assurer une cer-taine portabilité des applications gra-phiques, tout en conservant l’efficacitéet les performances d’un langage com-pilé proche de la machine.

Outils de développementLes outils de développement dispo-nibles librement sous Linux sont éton-namment puissants. Au cœur de la pro-grammation en langage C ou C++ setrouve naturellement le compilateur.Celui que l’on emploie sous Linux senomme GCC. Il s’agit d’un compila-teur produit par le projet Gnu, dont lebut est de fournir librement des logi-ciels de remplacement pour tous lesutilitaires système et outils de dévelop-pement sous Unix. Le compilateurGCC n’a rien de spécifique à Linux, ilest disponible sur de nombreux autresUnix, et un portage a même été réalisésous Dos. La qualité de GCC est telleque certains le préfèrent aux compila-teurs natifs vendus sur les stationsUnix classiques. Il représente égale-ment une alternative intéressante aux

Développement


Le noyau Linux et tous lesutilitaires système sont

écrits en C

Choisir Gnome ou KDEn’est pas une action

innocente

compilateurs très coûteux, puisqu’ilpermet d’équiper facilement et àmoindre frais toutes les stations desdéveloppeurs d’une équipe. GCC sedécline en plusieurs versions installéesconjointement, selon que l’on préfèreutiliser le langage C, le C++, voire ledialecte Objective C. Les très nom-breuses options disponibles pour ajus-ter la configuration du compilateur per-mettent d’adapter son comportementaux désirs du programmeur, notam-ment en ce qui concerne les respectsdes normes les plus courantes (Posix,Iso C99, etc.)Le compilateur GCC est un outil fonc-tionnant en ligne de commande, qu’onpeut donc lancer directement “à lamain” en indiquant les options désiréeset les fichiers sources à compiler. Cetutilitaire n’effectue qu’une seule tâche,mais il la réalise au mieux, sans quedes considérations d’interface utilisa-teur ne viennent le distraire de son rôle.Pour améliorer l’ergonomie du postede travail programmeur, il existe toute-fois un certain nombre d’environne-ments de développement intégré, quiregroupent un éditeur de texte pour lasaisie des fichiers sources et des com-posants graphiques (boutons, menus…)pour invoquer directement le compila-teur en arrière-plan, en s’assurant del’emploi des options correctes. Cesenvironnements permettent aussi l’ap-pel du débogueur Gnu, nommé GDB.À l’instar du compilateur, cet outilfonctionne par une invocation depuisune ligne de commande puis il offreune interface utilisateur minimale. Lesenvironnements de développementintégré l’encadrent et présentent uneinterface graphique plus attrayante, enpermettant l’exécution d’un pro-gramme instruction par instruction,l’inspection des variables, etc.Le projet Gnu regroupe une panopliecomplète d’outils destinés à assister le

travail du développeur. Citons, parexemple, les utilitaires d’archivage per-mettant de créer des bibliothèques defonctions personnalisées, les enjoli-veurs de code source pour uniformiserl’aspect des fichiers créés par les diffé-rents membres d’une équipe, les outilsRCS ou CVS qui assurent le contrôlede version et permettent ainsi le travailsimultané par plusieurs développeurssur le même projet en minimisant lesrisques de modifications concurren-tielles.

Documentation et exemplesLa richesse de la documentation dispo-nible concernant l’environnementLinux fait partie des caractéristiques dece système qui sont les plus attrayantespour les programmeurs. On peut trou-ver sur Internet des sites regroupantdes informations de grande qualitédans tous les domaines intéressant ledéveloppeur.En ce qui concerne l’environnementLinux en général, l’installation et laconfiguration des applications ou l’ad-ministration du système, on consulterales documents HOW-TO, traduits enfrançais, qui regroupent des informa-tions sur la plupart des sujets impor-tants pour l’utilisateur. Pour vérifier lasyntaxe d’appel d’une routine de labibliothèque C, pour connaître la signi-fication d’un appel système (c’est-à-dire un service offert par le noyauLinux lui-même) ou encore pour étu-dier le détail de toutes les options pro-posées par une application, il existeune commande MAN dont l’invocationest très commode. Elle donne accès àdes fichiers indépendants, que l’onnomme habituellement “pages demanuel” par analogie avec les classeursde documentation livrés avec les Unixtraditionnels. Chaque page (qui peutreprésenter parfois une dizaine depages imprimées) contient la documen-

Comment faire, comment choisir ?


Les très nombreusesoptions disponibles pourajuster la configuration ducompilateur permettentd’adapter soncomportement aux désirsdu programmeur

Le projet Gnu regroupeune panoplie complèted’outils destinés à assisterle travail du développeur

Christophe Blaess

tation pour une routine de la biblio-thèque C, un appel système ou un utili-taire. Il existe environ mille pages demanuel pour Linux actuellement tra-duites en français.Le programmeur pourra toujoursconsulter à son gré les sources dunoyau ou celles de la bibliothèque C,ce qui représente non seulement unesource d’information exacte en ce quiconcerne une fonctionnalité précise,mais également des exemples perfor-mants et souvent élégants, d’implé-mentation d’algorithmes(1).Les fonctionnalités offertes par lenoyau Linux et les routines de plushaut niveau proposées par la biblio-thèque C standard ne sont que rarementsuffisantes pour la réalisation d’uneapplication complète. Nous avons déjàabordé la question de l’interface gra-phique généralement indispensable.Mais il est souvent nécessaire de faireappel à d’autres bibliothèques réalisantdes tâches diverses. Citons, parexemple, l’existence de bibliothèquesintégrant des algorithmes de compres-sion, de cryptage, de lecture de fichiersgraphiques dans la plupart des formatsusuels. Citons aussi la possibilité d’ac-céder aux objets disponibles sur un busCorba ou encore d’utiliser des passe-relles vers d’autres langages de déve-loppement comme Python, Perl ouTcl/Tk. Toutes ces bibliothèques sontdisponibles sous forme de code sourcelibrement consultable et adaptable àdes besoins spécifiques.Pour conclure cette présentation rapide,j’aimerais insister sur l’aspect intellec-tuellement motivant que représente,pour un programmeur, la possibilité detravailler dans un environnement où ilest possible d’avoir accès au fonction-nement interne du système dans sesmoindres détails, où rien ne reste dissi-mulé à qui désire obtenir des informa-tions, et où la qualité des outils et l’as-

sistance disponible via Internet fontque l’on ne reste jamais bloqué face àun dysfonctionnement d’un utilitairesystème.

Christophe Blaess

[email protected]

Développement


Les fonctionnalitésoffertes par le noyau

Linux et les routines deplus haut niveauproposées par la

bibliothèque C standardne sont que rarement

suffisantes

J’aimerais insister surl’aspect intellectuellementmotivant d’avoir accès au

fonctionnement internedu système dans ses

moindres détails

1 - Ceci est d’ailleurs vrai pourl’ensemble des applications dispo-nibles sous Linux, la plupart desdistributions fournissant d’em-blée plusieurs centaines de méga-octets de fichiers sources immé-diatement consultables.

BIBLIOGRAPHIEProgrammation système en C sous Linux,Christophe Blaess, éditions Eyrolles.

http://perso.club-internet.fr/ccb

C’est le site de Christophe Blaess surlequel on peut retrouver notamment lespages de manuels Linux traduites en fran-çais. Autres adresses utiles :

www.linux-center.org/ fr : liens de docu-mentation française sur Linux

www.linux.org/ : ensemble de liens inter-nationaux sur Linux

www.gnu.org/home.fr.html : le projet Gnu

Sur le Net

Votre avisnous

intéresse,

écrivez-nous !

[email protected]

Votre avis...

Revue d’auteurs, l’Informatique Professionnelle accueilledes opinions qui n’engagent pas la rédaction.

Décisionnel

La collectedes donnéesest essentielle

Capitale, la collecte des données d’un système décisionnel est une opérationparticulièrement délicate. Accessibilité, nettoyage, consolidation, qualité,traçabilité et coûts ne doivent jamais être perdus de vue. Les freins et lesréticences des personnes non plus !

La collecte des données dans l’en-treprise est une étape majeure duprojet d’informatique décision-nelle. Lors des premières réalisa-

tions (projet EIS, Infocentre ou DataWarehouse), les concepteurs traitaient unpeu rapidement cette question. Ils par-taient du postulat qu’il “suffisait” de rapa-trier un maximum de données en un pointaccessible. Le décideur serait alors àmême de dénicher les informations per-tinentes et essentielles cachées au seindes bases de données. Le mythe du déci-deur-orpailleur des bases information-nelles a perduré. Ce mythe est à l’origine de nombreuxsystèmes décisionnels inutilisables.Pour éviter l’échec d’un tel projet, il ne

faut donc pas se limiter exclusivementaux aspects techniques. La question dela collecte des données doit être recon-sidérée pour prendre en compte lesbesoins fondamentaux en terme d’utili-sation des données.

Adopter une démarche projetPar définition, toutes les données del’entreprise n’ont pas la même valeurpour tout le monde. Cette notion devaleur est fortement dépendante del’usage et de l’utilisateur. Certainesdonnées seront importantes pour unutilisateur en fonction de ses préoccu-pations et insignifiantes pour d’autres. Avant de commencer les opérations decollecte, il est donc indispensable

Développement

n° 189 décembre 2000 11

Toutes les données del’entreprise n’ont pas lamême valeur pour tout lemonde

Consultant indépendant, il

intervient depuis plus de

15 ans auprès des grands

comptes et des PME sur la

conception des systèmes

d’information stratégiques

Alain Fernandez

d’identifier avec précision les besoinsdes utilisateurs et les limites du projet.Il ne sert à rien de mettre à la disposi-tion des utilisateurs potentiels desquantités faramineuses de données fortéloignées de leurs préoccupations. Une donnée devient une informationlorsqu’elle est porteuse de sens. La per-ception du sens dépend des utilisateurset des préoccupations du moment.Nous ne sommes pas égaux devantl’information et cette dernière n’est pasporteuse d’un sens universel. Seuls lesutilisateurs, en fonction de leurs préoc-cupations, sont à même de transformerles données en informations. La simpli-cité de l’accessibilité technique ne doitpas être l’unique critère de collecte. Ilfaut adopter une démarche projet afinde bien cerner les objectifs et les fron-tières des différents domaines d’inter-vention en fonction du besoin présent.La base décisionnelle pourra par lasuite être enrichie, au fur et à mesuredes nouveaux projets. Ne perdons pasde vue que le vieil adage “Qui peut leplus peut le moins” est souvent faux eninformatique.

Collecte, Consolidation etmaîtrise des coûtsUne fois la problématique bien définieet les domaines d’intervention circons-crits, la question purement techniquede la collecte peut alors être abordée.En règle générale, les concepteurs seheurtent à trois difficultés :

• l’accessibilité des données en raisonde l’hétérogénéité du système d’in-formation,

• le nettoyage des erreurs et aberrationscontenues dans les bases,

• la consolidation nécessaire pourrendre les données utilisables.

Les systèmes d’information de nosentreprises n’ont pas été conçus en sixjours. L’approche a toujours été parcel-laire et étalée dans le temps. Chaqueprojet était lancé pour répondre à unbesoin fonctionnel précis et ponctuel,limité le plus souvent à une unité, unedivision ou un service. Personne neconsidérait à leur juste mesure lesbesoins futurs en terme d’accès auxdonnées essentielles. Notons que lesdifférents rapprochements, rachats etfusions d’entreprises viennent com-plexifier encore la question de la cohé-rence du système d’information. Les opérations de nettoyage constituentla seconde difficulté rencontrée par lesconcepteurs. Les systèmes d’informa-tion contiennent de nombreuses don-nées erronées et inutilisables sur leplan décisionnel (par exemple, deserreurs, des valeurs aberrantes, desomissions, etc.). Les applications deproduction pleinement opérationnelleset recueillant la satisfaction des utilisa-teurs n’en sont pas exemptes. La présence d’erreurs au sein de sys-tèmes d’information parfaitement rodéss’explique simplement. Les donnéesqui n’influencent pas les résultats,

Développement


Le vieil adage " Qui peutle plus peut le moins " est

souvent faux eninformatique

Les systèmesd’information contiennent

de nombreuses donnéeserronées et inutilisables

sur le plan décisionnel

SUR LE TERRAIN

Il y a quelque temps, je suis intervenu comme " pompier " sur un projet de Data Warehouse en dérou-te, censé répondre à des besoins de pilotage et d’études clientèle dans le service marketing d’un équi-pementier. La base construite comportait d’énormes quantités de données techniques relatives à laconception et à la fabrication des produits. Ces données, sûrement riches d’enseignements pour leshommes du bureau d’études, de la production ou des méthodes, demeuraient purement absconses pourles gens du marketing. Pourquoi les avait-on placées dans la base décisionnelle ? Tout simplement parceque ces données étaient déjà structurées et aisées à collecter. Personne ne s’était préoccupé de l’en-seignement que pouvaient en tirer les utilisateurs, en l’occurrence les gens du marketing, par nature peuversés dans les questions de mécanique.

n’ont pas à être vérifiées trop soigneu-sement. Cependant, ces données peusignificatives pour les tâches de pro-duction sont peut-être porteuses d’unsens informationnel beaucoup plusriche pour les décideurs. Lors de la col-lecte, il faudra contrôler la validité detoutes les données devant jouer un rôledécisionnel dans le projet. On ne peutse permettre de laisser les utilisateursprendre des décisions à partir d’infor-mations erronées car dans ce cas le sys-tème serait très rapidement mis aurebut. Les travaux de consolidation consti-tuent la troisième difficulté à considé-rer. Du fait des anciennes habitudes decloisonnement et de découpage desentreprises en centres de profits auto-nomes, les règles de gestion élémen-taires sont rarement standardisées auniveau du groupe. Ceci est d’autantplus vrai lors de fusion et de rachat,avec le rapprochement d’entreprisesconservant leurs propres modes de cal-cul. Pensons simplement aux diffé-rentes façons de calculer un chiffred’affaires. Chaque entreprise utilise sapropre méthode (avec ou sans les ris-tournes, les escomptes, les commis-sions, etc.). Comment peut-on intégrer ou compa-rer les éléments d’activité lorsqueceux-ci sont calculés différemment ? Ilest du ressort de l’architecte du projetde mettre à la disposition des décideursdes données cohérentes. Ainsi, lors de la collecte, il faudrarésoudre chacun de ces points. La tâcheest conséquente et grèvera significati-vement les budgets “financier” et“temps” du projet. Pour éviter de selancer dans des opérations trop com-plexes, il faudra toujours garder enligne de mire le paramètre coût. Pourchaque point difficile de la collecte,nous nous poserons alors la question dela rentabilité en mettant en regard l’ap-

port sur le plan décisionnel des don-nées à collecter et le coût de l’opéra-tion. Bien que fortement subjectif (ilest difficile d’exprimer a priori l’ap-port décisionnel d’une information), cequestionnement permettra d’éviter lesdépassements de coûts et de délaisinconsidérés.

Une gestion centraliséeL’accroissement de la quantité des don-nées en circulation dans les entreprisessuit une loi exponentielle. Avec l’incer-titude ambiante et la rapidité du chan-gement, les hommes sont avides d’in-formations et chaque unité produit deplus en plus de données. Il est désor-mais temps de gérer les données nonseulement en termes d’accessibilitémais aussi en termes de qualité et detraçabilité. De plus en plus d’acteurs de l’entre-prise sont concernés par la prise dedécision. Le processus de banalisationde la fonction décisionnelle va rapide-ment s’accélérer avec l’essor attendudes portails informationnels d’entre-prise (EIP). Déjà, les projets décision-nels se multiplient. Que ce soit pourdes questions d’aide au pilotage, degestion de relation client ou d’analysequalité, de plus en plus d’applicationsvoient le jour. Il existe une forte ten-dance à la mise en œuvre de Datamartsspécifiques pour répondre localement àun problème posé. Paradoxalement,cette solution satisfaisante quant auxrésultats, contribue fortement à la dis-persion des données dans l’entreprise.Ainsi, on peut retrouver dans des basesdécisionnelles distinctes, des donnéesredondantes à différents stades detransformation et de fraîcheur. Pour limiter les erreurs et plus généra-lement pour mieux maîtriser les coûtsde nettoyage et de mise en forme desdonnées, il est temps de placer unobservatoire centralisant non pas les

La collecte des données est essentielle

n° 189 décembre 2000 13

Il est du ressort del’architecte du projet demettre à la disposition desdécideurs des donnéescohérentes

Il est temps de gérer lesdonnées en termes dequalité et de traçabilité

Alain Fernandez

données mais leur(s) définition(s),leur(s) parcours et leurs utilisations.Pour cela, Il faut au préalableconstruire un référentiel centralisé àmême de répondre à des questions dugenre : d’où provient cette donnée ?Quand est-elle mise à jour ? Commentest-elle calculée ? Quelles sont les pré-cautions d’usages ?On appelle “métadonnées” les donnéessur les données apportant des réponsesà ces questions. Pour une parfaite ges-tion, tous les modules fonctionnels dusystème d’information assurant le stoc-kage, l’extraction, le traitement et laprésentation, devraient util iser etmettre à jour le référentiel. Jusqu’à récemment encore, la défini-tion d’un format standard demeurait ledernier obstacle à la généralisation desmétadonnées. Deux formats étaient enlice : l’OIM (Open Information Model)proposé par le Meta Data Coalition etsoutenu par Microsoft, à l’origine de sadéfinition, et le CWM (CommonWarehouse MetaData) supportée parl’OMG (Object Management Group),Oracle et IBM, entre autres. Les deuxformats s’appuient sur UML (UnifiedModeling Language) pour la phase de

modélisation et XML (ExtensibleMarkup Language) pour les formats dedescription et d’échanges. Fin sep-tembre 2000, l’OIM a choisi de baisserles bras et d’abandonner sa norme pourcontribuer à la prochaine version del’OMG, le futur format unifié.

Décloisonnement et pouvoirs"parallèles"Les besoins en matière de collecte nese limitent pas aux données présentesdans la sphère de prérogatives des utili-sateurs du système décisionnel. Pourprendre les décisions, il faut pouvoiraccéder à des données situées à l’exté-rieur, au sein de bases dépendantesd’autres activités et d’autres services.Là encore, il ne faudra pas limiter notreétude à l’aspect exclusivement tech-nique mais bien s’informer auprès desproducteurs et utilisateurs habituels desdonnées concernées. A ce stade, on aborde la difficultémajeure du projet. Prenons unexemple : récupérer les chiffres censésdécrire l’activité d’une filiale peut pré-senter quelques difficultés techniquesqui demeureront rarement insurmon-tables. Ces données seront alors dispo-

Développement


Il faut créer unobservatoire centralisantnon pas les données mais

leur(s) définition(s),leur(s) parcours et leurs

utilisations

Pour prendre les décisions,il faut pouvoir accéder à

des données situées ausein de bases dépendantes

d’autres activités etd’autres services

LES OUTILS DE COLLECTE

Les outils comme Datastage d’Ardent ou Genio de Hummingbird automatisent la collecte et le net-toyage des données provenant des bases de données et des ERP les plus courants. Une fois le schémad’extraction modélisé pour les différentes sources, l’utilisateur définit les transformations nécessairespour rendre les données disponibles à des fins décisionnelles (calculs d’agrégat, contrôle des valeurs,élimination des aberrations...). Ces outils gèrent aussi le référentiel de méta-données centralisé. Lagrande majorité des bases sont accessibles en mode natif et il est possible de développer sa propre pas-serelle spécifique pour les sources de données non supportées par le produit.

GERER LA DONNEE A PRIORI

Dans tous les cas, il faudra envisager la potentialité informationnelle des données gérées par les appli-cations de production dès le lancement des projets système d’information. Nous perdons beaucoup tropde temps à récupérer des données peut-être secondaires pour une application de production maisimportantes pour les besoins décisionnels. Rappelons-nous qu’une des principales récriminations desutilisateurs d’ERP concernait l’absence d’éléments décisionnels. Avec l’essor de l’e-business et plusgénéralement de l’importance stratégique liée à l’éclatement de l’entreprise et au développement de lasupply-chain, l’information joue un rôle clé.

nibles. En revanche, nous ne dispose-rons d’aucune garantie sur leur validitéet surtout sur les précautions d’usage àrespecter avant d’en tirer un enseigne-ment. Chaque filiale, chaque service, chaqueactivité définit ses propres règles degestion. Avant d’utiliser une donnée etde chercher à en extraire une quel-conque information, il est préférable aupréalable d’en référer aux détenteurs decette connaissance, les seuls à même denous informer et de nous mettre engarde. Mais les détenteurs de cetteconnaissance seront-ils prêt à la com-muniquer à d’autres décideurs ? C’esttoute la question du décloisonnementet du partage de la connaissance qui sepose. Le culte de la compétition indivi-duelle, encore en vigueur dans de tropnombreuses entreprises, encourage leshommes à thésauriser leurs informa-tions pour asseoir plus confortablementleurs pouvoirs. Ils ont, le plus souvent,tout intérêt à ne pas communiquer lesrecommandations nécessaires à l’usagedes données... Surtout si personne ne leleur demande explicitement !Cette question cruciale est à traiteravec précaution. D’autant plus quel’information n’est pas répartie unifor-mément dans l’entreprise. Certaines

personnes placées aux nœuds d’infor-mations disposent d’un pouvoir de faitsignificatif. L’architecte du systèmedécisionnel devra faire preuve de psy-chologie pour inciter les hommes àcommuniquer et éviter de heurter defront les sensibilités. Il prendra aussigarde à ne pas asseoir encore plusconfortablement le pouvoir deshommes clés en entérinant technique-ment les domaines informationnels. Sur ce type de projet, l’engagement dela direction est indispensable ! Sansson réel appui, le projet est irréalisable.Seuls les dirigeants pourront expliquerles avantages de la coopération dans unesprit gagnant-gagnant au niveau del’entreprise. Et pour les causes perdues,ils seront aussi les seuls en mesure de“faciliter” l’ouverture des portes desrebelles à l’entreprise communicante.

Sélectionner les données Prenons le cas de la construction detableaux de bord de pilotage. Pourchaque indicateur inclus(1), nous sélec-tionnerons les données nécessaires à saconstruction en valorisant chacun descritères essentiels (voir figure 1). Ils’agit d’un travail de groupe, et chacundonnera son avis pour chaque critère àl’aide d’une note comprise entre 1 et 4.

La collecte des données est essentielle

n° 189 décembre 2000 15

Le culte de la compétitionindividuelle encourage leshommes à thésauriserleurs informations

L’architecte du systèmedécisionnel devra fairepreuve de psychologiepour inciter les hommes àcommuniquer

1 - Pour la méthode de choix desindicateurs, se référer à l’articledu même auteur dans le numéro176 de l’InformatiqueProfessionnelle.

Alain Fernandez

FIGURE 1 - LES CRITERES DE SELECTION DES INFORMATIONS

(D’après Fernandez, les Nouveaux Tableaux de bord des décideurs)

Disp

onibi

lité p

olitiq

ue

Simplicité de la règle

Pérénnité de l’information

Fiabilité

Coût

Acce

ssibi

lité t

echn

ique

Utilisationdécisionnelle

En plus des critères de disponibilité“politique” (les hommes sont-ils prêtsà partager ?), d’accessibilité techniqueet de coût, nous tiendrons aussi comptede la simplicité de la règle d’agrégation(limiter les calculs trop complexes etdifficilement maintenables), de lapérennité des informations (seront-ellesencore valides demain ?) et de la fiabi-

lité (quel est le degré de confiancequ’on peut accorder aux données sélec-tionnées ?).(2)

Alain Fernandez

[email protected]

http://www.multimania.com/itm

Développement


Seuls les dirigeantspourront "faciliter"

l’ouverture des portes desrebelles à l’entreprise

communicante

2 - Dans le cas de constitution d’unDatamart à usage statistique laprocédure pourra être simplifiée.

POUR REUSSIR SA COLLECTE

1. Adopter un mode projet : l’information n’est pas universelle, on ne rend disponible que les donnéesnécessaires pour les besoins présents.

2. Considérer les quatre aspects de la collecte :

- Accessibilité physique : réalisation des interfaces d’accès, “décodage" des tables de production, repé-rage des données clés

- Préparation des données : nettoyage des données, élimination des valeurs aberrantes, gestion desmises à jour ...

- Cohérence logique : consolidation, règles d’agrégation, mise en cohérence de valeurs issues desources gérées différemment, gestion des données absentes...

- Disponibilité politique : les hommes détenteurs des données ou de la connaissance sur les donnéessont-ils prêts à partager ?

3. Garder en ligne de mire le facteur coût : quels sont les coûts de mise à disposition des données etquel est leur apport sur le plan décisionnel ?

BIBLIOGRAPHIELes Nouveaux Tableaux debord pour les décideurs, AlainFernandez, Éditions d’Organi-sation (nouvelle édition2000)

Revue d’auteurs, l’Informatique Professionnelle accueille des opinions qui n’engagent pas la rédaction.

Bulletin d'abonnementBulletin d'abonnement

Nom : Prénom :

Société : Fonction :

Adresse :

Code postal : Localité :

Tél.:

Fax : email :

OUI, je souscris un abonnement d'1AN à L'InformatiqueProfessionnelle au prix de :

2450 F HT (TVA 2,1 %) pour la France 2660 F pour l'étranger

Je joins mon réglement par chèque à l'ordre de GartnerGroup France et je recevrai une facture justificativeJe règlerai à réception de facture

Bulletin à retourner ou à faxer à : Sylvie Garofalo • Gartner FranceImmeuble Défense Bergères • 345 avenue Georges Clemenceau • TSA 40002 • 92882 Nanterre cedex 09 • Tél : 01 41 35 15 15 • Fax : 01 41 35 15 10Conformément à la législation en vigueur, vous disposez d'un droit d'accès et de rectification pour toute information vous concernant

Orientations

La réductionfonctionnelles’impose

Pour tenir les délais, les budgets et les coûts, alors que les développeursexpérimentés sont de plus en plus rares et chers, mieux vaut remettre à plustard la réalisation des fonctions non indispensables. L’analyse de la valeurest un outil qui permet de choisir en connaissance de cause.

Les responsables de développementsapplicatifs le savent bien : unebonne partie des fonctionnalitésréclamées par les maîtrises d’ou-

vrage ne servent finalement pas. Il s’agitd’un gaspillage manifeste. Du coup, lesfonctions utiles elles-mêmes sont péna-lisées : elles coûteront plus cher, arriverontplus tard, comporteront plus de bogues,etc. Or nous entrons dans une période oùla tenue de délais courts va devenir deplus en plus un critère majeur de succèsdes projets…

Pendant qu’on y est…Très souvent, la maîtrise d’ouvragecède à la tentation de “profiter de l’oc-casion”, “pendant qu’on y est”, pour

raccrocher au projet tout ce qui peutavoir un quelconque rapport, proche oulointain, avec lui. Certaines maîtrisesd’ouvrages ne sont pas sûres de pou-voir relancer un autre projet de sitôt.Elles préfèrent donc réclamer des fonc-tions sans être certaines de leur utilité,mais “au cas où” elles en auraientbesoin d’ici leur prochain projet.D’autres maîtrises d’ouvrages,confrontées à l’angoisse légitime durisque d’erreur dans la conception d’unnouveau système, essaient de se garan-tir en “taillant large”. D’autres encoreont une envie latente de perfection etrêvent d’un système d’informationidéal. D’autres demandent toutes lesfonctions qui leur paraissent utiles,

Développement

n° 189 décembre 2000 17

Certaines maîtrisesd’ouvrages préfèrentréclamer des fonctionssans être certaines de leurutilité

Directeur des programmes

de Bouhot & Le Gendre.

Rédacteur en Chef de

L’Informatique

Professionnelle.

Il intervient depuis plus de

vingt ans dans le domaine

des systèmes d’information.

Jean-Marc Berlioux

sans se rendre compte que la valeurproduite par certaines fonctions serainférieure à leur coût. D’autres, enfin,se trompent de bonne foi sur la valeurde certaines fonctions, dans le cas de lamise en place d’un nouveau processus,par exemple.Le phénomène ne date pas d’hier. Onaurait pu espérer que, à force d’expé-riences douloureuses, les utilisateursauraient su en tirer les leçons et s’im-poser à eux-mêmes une modérationpragmatique.Mais les maîtrises d’ouvrage sont sou-vent tentées de justifier a posteriori lesfonctions supplémentaires, soit parl’évolution du monde dans l’intervalleentre la conception et la livraison del’application, soit par une applicationavisée du principe de précaution. Enfait, il s’agit là, le plus souvent, demodes de défense. Le fait est que lesméthodes de conception “classiques”les ont autorisés à se laisser aller à cegenre de dérive.L’absence de refacturation du coût desprojets aux maîtrises d’ouvrage estd’ailleurs un facteur d’aggravation decette tendance. Quand on ne paye pas lesfonctions supplémentaires, on peut êtretenté de s’attribuer une part un peu plusgrande du gâteau informatique (au détri-ment des autres maîtrises d’ouvrage).Une part notable des demandes des uti-lisateurs est donc largement irration-nelle. Les concepteurs fonctionnelsdoivent être conscients de cette ten-dance et disposer d’un outil méthodo-logique pour lutter contre les dérivesqu’elle implique.

L’analyse de la valeurL’analyse de la valeur fournit une baseméthodique à la réduction fonction-nelle. Le principe de base est lesuivant : à chaque fonction est asso-ciée une “valeur” estimée.On évalue ensuite le coût de la fonc-

tion. Ce coût inclut les charges dedéveloppement, d’installation, de for-mation, etc. spécifiques à la fonction,mais aussi l’impact de cet ajout sur lesdélais de livraison de l’ensemble, lerisque de dégradation de la fiabilité etde la qualité de l’application, l’allonge-ment de l’apprentissage, etc.Toutes les fonctions dont le coût estsupérieur à la valeur sont éliminées oureportées. Au total, on essaie doncd’optimiser le rapport valeur/coût.

Des fonctions auxiliairesattrayantesIl arrive qu’une démarche de réductionfonctionnelle parvienne à réduire lescoûts et les délais à un niveau inférieurau budget. Deux options sont alorsenvisageables. Soit repêcher quelquesfonctions éliminées de justesse. Soitintroduire des fonctions destinées àrépondre à des besoins latents impor-tants.L’introduction de telles fonctions, pourautant qu’elles soient bien choisies,peut permettre de renforcer sensible-ment la satisfaction des utilisateurs. Iln’existe pas de baguette magiquegarantissant le choix pertinent de fonc-tions destinées à répondre à desbesoins latents. Cependant, on peutrappeler que les ressorts qui sous-ten-dent la satisfaction “supplémentaire”des utilisateurs tournent le plus souventautour de la communication, de l’accé-lération, de la liberté de créer des fonc-tions auxiliaires (par exemple d’extrac-tion ou de représentation), de l’aide àla compréhension des faits ou des don-nées, de la réduction des travaux fasti-dieux et du confort d’utilisation.A titre d’exemple, une interface per-mettant de récupérer des données dansdes outils bureautiques de type Excelest souvent un facteur de satisfaction.

Jean-Marc Berlioux

Développement


Quand on ne paye pasles fonctions

supplémentaires, on peutêtre tenté de s’attribuer

une part un peu plusgrande du gâteau

informatique

Toutes les fonctions dontle coût est supérieur à lavaleur sont éliminées ou

reportées

Architectures à composants

Savoir-faireet organisation

Développer et implémenter une architecture à composants obligent àrepenser les méthodes et les outils. Rien de plus simple ! Le vrai défi résidedans la nouvelle organisation des équipes de développement.

L’intérêt actuel que suscitent lesarchitectures distribuées aussiappelées “architectures à compo-sants” démontre que fournisseurs

et utilisateurs de technologies ont su capi-taliser sur les succès d’hier et tirer ensei-gnement des erreurs passées.En effet, nous disposons aujourd’huide solutions qui concilient la fiabilitédes systèmes centralisés avec la sou-plesse des systèmes client-serveur, etce sans hériter de la rigidité des pre-miers ou des coûts élevés de déploie-ment des seconds.Parmi ces nouvelles architectures, lesoffres J2EE(1) de Sun et DNA(2) deMicrosoft encouragent la centralisationdes objets métiers, la factorisation des

services techniques -sécurité, déploie-ment, ...- tout en permettant une forteréactivité aux nouveaux besoins desutilisateurs.L’objectif de ces nouvelles offres estsimple : permettre aux équipes informa-tiques de concentrer leur attention surles attentes des utilisateurs en s’abs-trayant de la complexité technique demise en œuvre des nouveaux services.Cette louable intention n’est certes pasnouvelle, elle est simplement aujour-d’hui devenu réalisable… en s’entou-rant d’un minimum de précautions !

Marier l’ancien et le moderneUn bref rappel de l’évolution des archi-tectures permet de se rendre compte

Développement

n° 189 décembre 2000 19

Nous disposonsaujourd’hui de solutionsqui concilient la fiabilitédes systèmes centralisésavec la souplesse dessystèmes client-serveur

1 - Java 2 Entreprise Edition.

2 - Distributed interNetArchitecture.

Président de Neoxia

(www.neoxia.com).

Cabinet de conseil

en architectures

informatiques

distribuées.

Gilles Mergoil

que ces fameuses “nouvelles technolo-gies” tirent une partie de leur légitimitéde techniques plus anciennes, large-ment éprouvées et extrêmement effi-caces lorsqu’elles sont utilisées à bonescient.Il n’est nul besoin de rappeler les quali-tés des systèmes centralisés en matièrede sécurité, de support transactionnelet, dans une certaine mesure, de “scala-bilité” (3). Longtemps critiqués, ils peu-vent tirer gloire aujourd’hui de l’inca-pacité des architectures client-serveur àles égaler sur ces points précis.Pour leur part, les architectures client-serveur ont contribué fortement à élar-gir la place qu’occupe l’informatiquedans nos entreprises. Elles ont accru lepouvoir des équipes métiers sur lessystèmes d’information … mais proba-blement un peu trop.En privilégiant l’utilisateur final, nousavons obtenu des progrès immenses enterme d’ergonomie et acquis uneliberté quasi totale pour accéder à l’in-formation et la traiter.Mais ce transfert du centre de décisiondu technique vers le fonctionnel estsouvent à l’origine de nombreux blo-cages. Il a eu les conséquences quenous connaissons : failles de sécurité,incohérence de l’information, manqued’interopérabilité, incapacité à monteren charge, coûts et délais de déploie-ment élevés.Les nouvelles architectures nous pro-posent de concilier le meilleur destechnologies précédentes et surtout demieux définir le partage des rôles entreéquipes techniques et équipes métiers.D’une architecture à base d’applica-tions, le système d’information doitpasser à une architecture en servicesmétiers.A chaque domaine métier significatifde l’entreprise correspond un servicemétier qui factorise un savoir-fairesous forme d’un ensemble d’objets

métiers. Les objets et services métiersviennent s’intégrer dans une architec-ture mettant à leur disposition des ser-vices techniques de haut niveau à tra-vers des interfaces normalisées et –plus ou moins – universelles.Les applications traditionnelles sontremplacées par des applicationslégères, qui intègrent différents ser-vices métiers pour proposer à l’utilisa-teur les fonctionnalités attendues.

Des ORB aux serveursd’applicationsLa mise en place de telles architecturespose des problèmes de conception clas-siques mais également de nombreuxproblèmes d’ordre technique. Parmi lesdéfis majeurs, on trouve la sécurité deniveau applicatif, la prise en compte dela montée en charge, l’intégration del’existant, mais également la garantiede l’intégrité des données et la localisa-tion des services et des objets métiers.Ces dernières années ont vu l’émer-gence des ORB (4) incarnés par la spé-cification CORBA(5) et ses implémen-tations d’une part et la technologieMicrosoft DCOM(6) d’autre part.Ces ORB ont commencé à offrir desmoyens techniques permettant la miseen place d’architectures en servicesmétiers. Pourtant, ces technologies sesont rapidement révélées technique-ment très complexes et difficiles àmettre en œuvre dans l’entreprise. Ceconstat a contribué à l’apparitionrécente des serveurs d’applications quiont pour objectif de faciliter le déve-loppement des objets métiers, en éloi-gnant le plus possible tous les pro-blèmes techniques de bas niveau.Les serveurs d’applications sont repré-sentés sur le marché par l’architectureMicrosoft DNA d’une part et la spécifi-cation Java 2 Entreprise et ses implé-mentations d’autre part.

Développement


Les architectures client-serveur ont accru lepouvoir des équipes

métiers

Des serveursd’applications ont pour

objectif de faciliter ledéveloppement des objets

métiers en éloignant leplus possible tous les

problèmes techniques debas niveau

3 - La "scalabilité" (scalability enanglais) est la capacité à sup-porter une montée en charge.

4 - Object Request Broker : midd-leware orienté objet permet-tant le dialogue inter-proces-sus entre objets.

5 - Common Object RequestBroker Architecture.

6 - Distributed Component ObjectModel.

Les serveurs d’applicationUn serveur d’applications intègre unensemble de services nécessaires au fonc-tionnement des applications distribuées.Le service d’annuaire rend possiblel’indépendance à la localisation. Il per-met de localiser un service ou un objetmétier à partir de son nom. Le servicede transaction permet de garantir l’inté-grité des données. Il rend possible lestransactions distribuées. Ce type deservice est déjà connu sous le nom demoniteur transactionnel. Le service desécurité de niveau applicatif permet dedéclarer de manière centralisée lesautorisations d’utilisation des objetsmétiers et ceci jusqu’au niveau desméthodes. Le service de message per-met la communication, sous forme demessage, entres composants du sys-tème d’information. Ce service est unreprésentant de la famille des MOM(7).Le service de déploiement permetl’installation des objets métiers etautres composants dans le serveurd’application. Le service web, qui n’estni plus ni moins qu’un serveur HTTP,permet l’accès au système d’informa-tion par une interface web.C’est l’intégration de tous ces services,plutôt que chaque service pris isolé-ment qui fait le véritable intérêt desserveurs d’application. Enfin, la capa-cité des serveurs d’application à semettre en grappe rend possible la mon-tée en charge et la tolérance à la panne,et ceci sans développement supplémen-taire. C’est également une de leursgrandes forces.

Le mythe de laprogrammation distribuéePour ceux qui ont fait ou feront le choixd’adopter les architectures à compo-sants, la difficulté provient moins dudéveloppement que de la capacité àcomprendre les concepts fondamentauxde l’informatique distribuée.

L’évolution des technologies, en infor-matique comme ailleurs, est ainsi faitequ’il ne s’agit pas toujours de “fairecomme avant, plus facilement” maisplutôt de penser différemment !Une croyance répandue est que l’on pro-gramme une application distribuée exac-tement comme on le fait en local, latechnologie se chargeant de tout. Il n’enest rien. Les appels aux méthodesmétiers se font via le réseau. Les tempsd’appel de bout en bout sont donc consi-dérablement plus longs qu’en program-mation locale. Ceci reste vrai même sil’appelé et l’appelant sont logés sur lamême machine, l’appel donnant lieu àune coûteuse communication inter-pro-cessus. Cet élément technique fonda-mental est à prendre en considérationdès la conception afin d’éviter deconstruire un système d’information auxperformances inacceptables.Ce simple exemple met en lumière lebesoin d’une nouvelle répartition desrôles au sein de l’organisation encharge du système d’information.Les équipes projet au service des utili-sateurs doivent bénéficier d’une archi-tecture technique fiable et de procé-dures de développement et d’intégra-tion. Elles doivent également disposerd’un support technique pointu pouréviter de mettre en péril la bonnemarche du système.

Maîtrise d’ouvrage :priorité au métierPenser différemment met en cause l’or-ganisation des équipes et redistribue lesrôles et les responsabilités parmi lesacteurs, tant techniques que fonctionnels.Les équipes fonctionnelles vont ainsidevoir penser et formaliser leur savoir-faire et leurs attentes en tenant comptedes aspects dynamiques de leur métier.Elles doivent définir les bases pérennesde leur métier (les objets métiers per-sistants, c’est-à-dire stockés et parta-

Savoir-faire et organisation

n° 189 décembre 2000 21

La difficulté provientmoins du développementque de la capacité àcomprendre les conceptsfondamentaux del’informatique distribuée

Les équipes fonctionnellesvont ainsi devoir définirles bases pérennes de leurmétier

7 - Message OrientedMiddleware.

Gilles Mergoil

gés), ainsi que les processus répétitifs(les services métiers fondamentaux uti-lisés par tous). Elles doivent égalementformaliser leurs besoins spécifiques etcourt terme (objets et services vola-tiles, à durée de vie limitée et peu réuti-lisables) qui donneront lieu simplementà de nouvelles interfaces vers d’autresservices plus stables.Pour cela, les acteurs fonctionnelsdevront apprendre à utiliser un forma-lisme universel comme UML et ses casd’utilisation, permettant ainsi un dia-logue efficace avec leurs homologuestechniques.

Maîtrise d’œuvre :une nouvelle organisationPour leur part, les équipes de maîtrised’œuvre doivent se structurer pourprendre en charge trois fonctions :répondre efficacement aux besoins uti-lisateurs, concevoir l’architectureapplicative partagée, assurer la maîtrisedes technologies utilisées.L’ingénierie de projet (c’est-à-dire laconception et le développement desapplications) est prise en charge par deséquipes disposant d’une compétencetechnique intermédiaire et, chacune,d’une bonne vision d’un métier particu-lier. Leur rôle est de comprendre et dedéfinir clairement les besoins immé-diats des utilisateurs et de développerles applications nécessaires à partir desobjets et services métiers existants. Unede leurs responsabilités est égalementde détecter et de formaliser les anoma-lies et les attentes tacites ou explicitesdes utilisateurs afin d’alimenter les pro-cessus d’évolution du système d’infor-mation. Leur objectif est l’efficience(qualité, coûts, délais) au service desutilisateurs dans le respect de l’archi-tecture du système d’information.L’architecture applicative (c’est-à-direla conception et le développement desobjets métiers) est conçue par une

équipe disposant de fortes compétencestechniques et d’une bonne vision glo-bale des métiers de l’entreprise. Sonrôle est de définir, avec la maîtrised’ouvrage, les objets, composants etservices structurants du système d’in-formation. Les membres de cetteéquipe auront la charge de transposersur le plan technique les spécificationsfonctionnelles retenues en veillant àmaintenir la qualité générale de l’archi-tecture applicative. En effet, ils conçoi-vent et développent les éléments fonda-teurs du système d’information et doi-vent donc en assurer la fiabilité, lacohérence, la sécurité ainsi que la capa-cité à monter en charge.Ils ont donc la charge de l’évolution dusystème d’information. En prise directeavec les métiers fondamentaux de l’en-treprise, ils bénéficient également duretour d’information en provenance deséquipes ingénierie. Leur objectif est lapérennité du système d’information etl’assurance de sa capacité à répondreefficacement à l’évolution des métiersde l’entreprise.Quant à l’équipe “architecture tech-nique”, véritable task force composéed’architectes et d’experts techniques,elle permet de garantir la maîtrise desrisques technologiques. Ses membresétudient, proposent et valident les fon-dements techniques de l’architecture dusystème d’information. Ils mettent à dis-position de l’ingénierie les outils tech-niques et les procédures nécessaires àl’intégration des futurs objets et servicesmétiers au sein des applications. Ilsconseillent techniquement les équipesd’ingénierie et d’architecture applica-tive, apportent leur expertise et les fontbénéficier d’un transfert de compé-tences, si cela se révèle nécessaire.

Gilles Mergoil

Développement


L’ingénierie de projet estprise en charge par des

équipes disposant d’unecompétence technique

intermédiaire

L’équipe "architecturetechnique" permet de

garantir la maîtrise desrisques technologiques


La mort de DCOM

Un SOAPopera !

En 2003, plus de 70 % des e-services qui seront invoqués au travers del’Internet, le seront en utilisant SOAP de Microsoft. SOAP permet à deuxapplications de communiquer au moyen de messages XML transportés parHTTP, et ce, quel que soit le système d’exploitation, le langage dedéveloppement et le modèle d’objet utilisé (COM, EJB, etc.).

Les Américains ont le secret dessoap operas, ces feuilletons à l’eaude rose dont ils inondent le mar-ché. L’informatique n’y échappe

pas ! Ainsi, il fut longtemps question de lamort de J.R., la Java Revolution.Aujourd’hui, la question qui se pose est desavoir si SOAP, qui signifie Simple ObjectAccess Protocol, annonce la fin deDCOM (Distributed Component ObjectModel), le modèle objet distribué deMicrosoft.

Un peu d’histoire Pour bien comprendre ce qu’apporteSOAP, il est utile de revenir un peu enarrière, au début des modèles objets deMicrosoft. En 1996, Microsoft intro-

duisit DCOM comme une extension àson modèle objet COM, lui permettantde fonctionner en mode distribué.DCOM présupposait qu’aux deuxbouts de la communication il y avaitdes objets de type COM. DCOM per-met donc de communiquer, mais si toutse passe dans le monde propriétaire deMicrosoft. Au contraire, le modèle CORBA(Common Object Request BrokerArchitecture) rendait les mêmes ser-vices, mais dans un monde plus ouvert. Cette communication COM – COMdevait être en mode synchrone. Lesdeux systèmes communiquant par cebiais devaient établir une session entreeux. Ils étaient alors qualifiés de forte-

Développement

n° 189 décembre 2000 23

DCOM permet decommuniquer dans lemonde propriétaire deMicrosoft

Directeur de programme

chez Gartner.

Il a occupé des fonctions

de direction informatique

dans les domaines de la

logistique et du transport

aérien.

Jean-Marc Lejeune

ment couplés (tightly coupled). Lemiddleware utilisé dans ce mode decommunication était MS-RPC, la ver-sion Microsoft du DCE de l’OpenSoftware Foundation.

Evolution des besoins Les besoins en matière d’intercon-nexion de systèmes évoluèrent depuis1996, principalement suite à la pres-sion qu’exerce l’Internet sur les archi-tectures techniques. C’est ainsi qu’au-jourd’hui on ne peut plus se contenterde systèmes fortement couplés et pro-priétaires quand il s’agit d’ouvrir sonarchitecture technique au monde exté-rieur pour, par exemple, s’interconnec-ter avec ses partenaires et qu’en sus,cette communication se fasse au traversdes firewalls. Microsoft franchit une première étapeavec COM+ qui nous est arrivé dansWindows 2000. COM+, à côté des RPCadmet d’autres middlewares et notam-ment MSMQ, le système de “messagequeuing” de Microsoft. Ceci permet debâtir des interconnexions qui soient fai-blement couplées (loosely coupled). De telles interconnexions s’affranchis-sent de l’établissement d’une sessionentre les deux systèmes communi-quant, et peuvent même se passer de laprésence permanente du réseau entreeux, grâce aux mécanismes sécurisésdes systèmes de “message queuing”.Cependant, il est toujours nécessaired’avoir du COM aux deux extrémités. Une étape suivante est franchie grâce àSOAP. SOAP est défini par Microsoft,mais Microsoft l’a proposé commestandard à l’IETF, l’organisme quiveille à la destinée de l’Internet. Le butde SOAP est de permettre à deux appli-cations de communiquer au moyen demessages XML transportés par HTTP,et ce, quel que soit le système d’exploi-tation, le langage de développement etle modèle d’objet utilisé (COM, EJB,

etc.). XML doit cependant être adaptépour pouvoir décrire les interfaces deservices. Une telle interface dans unearchitecture orientée services contientnon seulement la définition de larequête et de la réponse, partie pourlaquelle XML n’éprouvera aucune dif-ficulté, mais aussi la définition del’identité du service, de son comporte-ment et du traitement d’exceptions,c’est-à-dire tout ce qui est traditionnel-lement décrit au travers d’IDL(Interface Definition Language). SOAP propose de réaliser la conver-sion des IDL en XML. SOAP ne signi-fie donc pas la mort de DCOM, mais ilvient le compléter en l’ouvrant aumonde extérieur. Microsoft fait la course Internet en tête Certes, SOAP n’a pas encore étéadopté en tant que standard par l’IETF,il s’agit toujours d’une proposition.Cependant au Gartner nous pensonsque cette proposition a de forteschances de passer et que, en 2003, plusde 70 % des e-services qui seront invo-qués au travers d’Internet, le seront enutilisant SOAP comme mécanismesous-jacent. Microsoft, malgré des débuts très lents,fait maintenant la course Internet entête. De plus, il le fait de manièreouverte, en publiant et proposant satechnologie comme standard IETF, tan-dis que d’autres s’acharnent à breveterdes clics de souris. Serait-ce là uneconséquence bénéfique de l’action dujuge Jackson ?

Jean-Marc Lejeune

Développement


On ne peut plus secontenter de systèmes

fortement couplés etpropriétaires

Le but de SOAP est depermettre à deux

applications decommuniquer au moyen

de messages XMLtransportés par HTTP

Votre avisnous intéresse,

écrivez-nous [email protected]

Votre avis...

Qualité

Visionutilisateuret maturité

Face à l’immaturité générale des processus, l’imperfection des méthodes, leflou des concepts et les failles des produits, peut-on espérer développer unjour des logiciels de qualité ? Oui, mais à condition que les maîtres d’œuvrerespectent des contraintes indispensables et que les maîtrises d’ouvragetiennent mieux leur rôle propre dans le projet.

Imaginons qu’un commandant de bordannonce le message suivant aux pas-sagers d’un avion de ligne :“Mesdames et Messieurs, nous avons

maintenant atteint notre vitesse de croi-sière, que je n’ai pas le droit de vous com-muniquer. J’ai une vue superbe sur lemont Blanc, que vous auriez pu distin-guer à votre gauche si le concepteur del’appareil avait bien voulu prévoir deshublots. Je dois vous annoncer que desretards sont à prévoir, pour des raisonstechniques que vous ne pouvez pas com-prendre. L’appareil que je suis en trainde piloter est sûr et fiable. Je vais mêmevous le montrer tout de suite en exécu-tant un looping. J’espère que cela vousfera plaisir”.

Une telle annonce est impensable dansun avion de ligne. Mais c’est pourtantce genre de discours que tiennentnombre de projets informatiques à leursmaîtrises d’ouvrage et leurs utilisateurs.

ImmaturitéUn seul mot peut résumer la situation :immaturité. Celle des processus, desméthodes, des concepts, des produits,des moyens et de la vision utilisateur.Processus. On ne s’étendra pas ici surle modèle de maturité des processus dedéveloppement (modèle CMM).Rappelons simplement que la majoritédes entreprises en est encore auniveau 1 : le processus de développe-ment n’est pas contrôlé et sa qualité

Développement

n° 189 décembre 2000 25

Un seul mot peut résumerla situation : immaturité.

Consultant à BSGL Conseil,

membre actif d’ADELI, il

intervient auprès des

grandes entreprises, en

France et à l’étranger, sur

des missions de diagnostic

et de conseil.

Yves Constantinidis

repose entièrement sur la compétenceet la bonne volonté des hommes. Etcette situation perdurera, très probable-ment, pour de nombreuses années.L’évolution sera lente, car, pour que lesprocessus changent, il faut que lesmentalités changent. Le frein est cultu-rel et humain.Méthodes. On s’accorde tous à direque les méthodes ne sont pas parfaitesmais qu’elles ont “le mérite d’exister”.Cet argument est pervers. Dans l’in-dustrie, lorsqu’une méthode de fabrica-tion est inefficace, on la change ou onl’améliore. La méthodologie devraitêtre un processus continu et non unensemble figé de normes. Mais, aujour-d’hui, la méthodologie est élaboréesous stress. Les techniques évoluenttrès vite et nous voulons que lesméthodes évoluent au même rythme.Prenons un exemple : trois gourous sesont réunis pour mettre au point laméthode de “l’orienté objet”. Il en adécoulé non pas une méthode, maisune notation, un “langage unifié demodélisation” (UML, UnifiedModeling Language). C’est un progrès,mais moins ambitieux que l’objectif dedépart. De fait, la notation a été norma-lisée avant les concepts, ce qui ne vapas sans problèmes.Concepts. Pour reprendre l’exempled’UML, la notation laisse entrevoir uncertain nombre de concepts. Sont-ilsclairement définis ? Chaque nouveauterme est-il précisé ? Si les mots“béton” et “armature” était aussivaguement décrit que le mot “agréga-tion” et “association” dans UML, lestours de la Défense ne resteraient paslongtemps debout !Moyens. Dans un contexte hautementcompétitif, où techniques et méthodesévoluent à un rythme accéléré, lesoutils qui supportent la construction dulogiciel sont mis à très rude épreuve.Leurs éditeurs doivent nécessairement

faire des arbitrages douloureux. Lesoutils devraient être pensés de façoncohérente et globale, en tenant comptede l’ensemble des activités deconstruction du logiciel. C’est rarementle cas. La course-poursuite que mènentles éditeurs d’outils les empêche deprendre le recul indispensable à uneconception rationnelle.Produits. Les produits sont-ils adaptésaux besoins, sont-ils utiles, sont-ilseffectivement utilisés ? Ce n’est pastoujours le cas. Les défauts évoqués ci-dessus sont évidemment pour beau-coup dans l’inadéquation des produits.Mais ce ne sont pas les seules causes.La qualité des processus est une condi-tion nécessaire, mais non suffisante, àla qualité des produits qui en résultent.Un processus parfaitement au pointpeut donner lieu à des produits inutili-sables. En particulier, aucun processusne peut garantir que les besoins des uti-lisateurs ont été bien compris.Vision utilisateur. L’utilisateur estencore trop souvent considéré commele passager à qui l’on peut cacher lesparamètres de vol et qui ne pourraregarder le paysage qu’à l’arrivée. Et,même lorsqu’il le souhaite, l’utilisateurou le maître d’ouvrage n’a pas lesmoyens d’avoir un regard sur les para-mètres du projet et sur la qualité duproduit. Cependant, l’utilisateur auraitdès aujourd’hui la possibilité deconnaître, et même d’influencer, laqualité du produit livré.Lorsque nous parlons d’immaturité, nejetons la pierre à personne. L’infor-matique est une activité jeune. Il estnaturel qu’elle soit immature. Mais lajeunesse n’explique pas tout.

Une machine molleet invisibleLe mot software résume à lui seul à lafois l’essor considérable de cette indus-trie et la disproportion entre sa fulgu-

Développement


Le processus dedéveloppement n’est pas

contrôlé et sa qualitérepose entièrement sur la

compétence et la bonnevolonté des hommes

Dans un contextehautement compétitif les

outils qui supportent laconstruction du logiciel

sont mis à très rudeépreuve

rante progression et la faible maturitédes produits qui en résultent. Le logi-ciel est mou, impalpable, aucunecontrainte ne pèse sur lui. Le bétonobéit aux lois de la physique et de lachimie. On ne peut pas construire unpont de n’importe quelle forme, n’im-porte où, n’importe comment. La misesur le marché d’un produit industriel nepeut se faire qu’après des contrôles, deplus en plus stricts, et dans le respectde normes.Avec le logiciel, il en va autrement.Les seules contraintes sont imposéespar le marché : coûts, délais, prix,concurrence. L’absence de contraintesphysiques sur le logiciel a des consé-quences importantes sur la maturité desprocessus et des produits. Le logicielétant mou, il peut être facilement modi-fié. D’où la difficulté, à tous lesniveaux, de contrôler et de gérer lesversions successives.De plus, la structure interne d’uneapplication ne peut pas être vue nimême devinée de l’extérieur, commec’est le cas pour un ouvrage d’art oupour un bâtiment. Les modificationssont invisibles, faciles, rapides et necoûtent pas cher. Elles restent inaper-çues, mais peuvent être lourdes deconséquences.

Se fabriquer des contraintesSerait-il donc utopiste d’imaginer dévelop-per des logiciels de qualité ? Je ne le croispas. Pour y parvenir, la solution consiste àfabriquer de toutes pièces un ensemble decontraintes, et à s’y conformer.Enoncée de cette manière, la démarchepeut paraître artificielle, voire saugre-nue. Pour la comprendre, il suffit derenverser la question : quelles sontcontraintes qu’on devrait appliquer enamont pour que le logiciel soit satisfai-sant en aval ? La réponse est alors tri-viale : ce sont celles qui permettront auproduit final de satisfaire à tous les cri-

tères de qualité. Or, les critères de qua-lité d’un produit logiciel, nous lesconnaissons. Ils sont précisément défi-nis par la norme internationale ISO/IEC9126. Ils sont au nombre de six.La capacité fonctionnelle. Le logicieldoit apporter un ensemble de fonctions.C’est la capacité fonctionnelle. Lesrésultats doivent être exacts, c’est-à-dire conformes à ce qu’on attend. Lelogiciel doit respecter les lois et règle-ments en vigueur et les exigences desécurité.La fiabilité. C’est l’aptitude du logicielà maintenir son niveau de service. Unlogiciel fiable est un logiciel qui a peude défaillances. Il peut être rapidementremis en état. Il sait maintenir un cer-tain niveau de service en cas dedéfaillance et recouvrer un état accep-table après remise en état.L’utilisabilité. Elle concerne l’effortnécessaire à l’utilisation. Un logicielutil isable est un logiciel facile àapprendre et à utiliser. Il s’adapte auprofil de l’utilisateur et réduit lesrisques d’erreur. L’utilisabilité estétroitement liée à l’ergonomie.Le rendement. Il concerne l’utilisationdes ressources (processeur, mémoire,etc.). Il mesure les performances dulogiciel.La maintenabilité. Un logiciel mainte-nable est un logiciel facile à analyser, àmodifier et à tester et sur lequel lesmodifications n’ont pas d’effets inat-tendus.La portabilité. La portabilité corres-pond à la facilité d’installation, autransfert aisé d’un environnement à unautre. Le logiciel portable est apte àremplacer un autre logiciel et à êtreremplacé par un autre logiciel.Ces six caractéristiques sont utiliséespour vérifier la qualité d’un produitlivré (progiciel ou application). Ellespeuvent donc nous aider à identifier lescontraintes à appliquer en amont.

Vision utilisateur et maturité

n° 189 décembre 2000 27

Le logiciel est mou,impalpable, aucunecontrainte ne pèse sur lui.

La solution consiste àfabriquer de toutes piècesun ensemble decontraintes et à s’yconformer.

Yves Constantinidis

Modifier la vision utilisateurLorsque vous faites construire une mai-son, vous allez visiter le chantier.Même si vous n’êtes pas architecte,vous avez la possibilité de vérifier nonseulement la couleur des fenêtres, maisaussi les matériaux de construction etles techniques utilisées.En matière de construction de logiciel,les choses fonctionnent autrement.L’ utilisateur a un droit de regard et aussides possibilités de contrôle, mais ceux-cirestent superficiels. Il peut effectivementvérifier la couleur des fenêtres (affichéesà l’écran) mais les exigences de fiabilité,de portabilité et de rendement sont rare-ment décrites et quand, par hasard, ellesle sont, c’est le plus souvent de façonfloue ou incomplète.Un simple particulier qui fait construiresa maison de campagne peut avoir desexigences très précises quant à laforme ou à la manière dont la maisons’insère dans le paysage.En informatique, un maître d’ouvrageou un donneur d’ordres a rarement desexigences aussi précises. Et ceci pourdeux raisons : parce qu’il ne sait pascomment les exprimer et surtout parcequ’il ne sait pas quel type d’exigencesil est en droit d’exprimer, ni commentil les fera contrôler et respecter. Parexemple, peu de cahiers des chargesexpriment des exigences de maintena-bilité. Lorsqu’ils le font, ils exprimentplus souvent les moyens à utiliser(méthodes et outils) que les objectifs àatteindre (par exemple, un encadrementde l’effort moyen consacré à la correc-tion d’un bogue).

Un outil de dialogueIl est donc important que les caractéris-tiques de qualité, qui sont actuellementun outil de contrôle, deviennent égale-ment un outil de dialogue et le fonde-ment des spécifications des produits.Pour cela, il faut que l’utilisateur, le

maître d’ouvrage, le donneur d’ordres,modifient la perception qu’ils ont dulogiciel. Aujourd’hui, le logiciel estune boîte noire. A défaut de devenirune boîte transparente, il faut qu’elle setransforme au moins en une boîte “decouleurs”, où les différentes caractéris-tiques soient identifiables.La première étape consiste donc à don-ner un vocabulaire commun aux pro-ducteurs et aux consommateurs delogiciel. Avoir un vocabulaire com-mun, centré sur les objectifs plus quesur les moyens, permet de construireplus vite un cahier de charges plus clairet de se concentrer sur le contenu. Cecipermet également à chaque acteur dejouer pleinement son rôle : le produitfini au maître d’ouvrage, le travail poury parvenir au maître d’œuvre.

Vers une échelle de maturitéde la maîtrise d’ouvrageIl existe une échelle de la maturité pourles organisations de développement dulogiciel. De la même façon, on pourraitimaginer une échelle de maturité pourles organisations consommatrices, quipourraient ainsi s’autoévaluer. Cetteéchelle comporterait également cinqniveaux :Niveau 1 : le cahier des charges estabsent ou embryonnaire, les besoins nesont pas formalisés.Niveau 2 : l’organisation établit uncahier des charges minimum, purementfonctionnel, ou en délègue la rédactionà un consultant.Niveau 3 : l’organisation coopère avecle consultant pour établir un cahier descharges global, tenant compte des sixcaractéristiques citées plus haut, oul’établit elle-même selon des règlesprécises et un savoir-faire éprouvé.Niveau 4 : l’organisation mesure l’effi-cacité de la maîtrise d’œuvre, grâce àdes audits, des diagnostics, des évalua-tions, des techniques d’analyse de la

Développement


Les exigences de fiabilité,de portabilité et de

rendement sont rarementdécrites

La première étapeconsiste donc à donner unvocabulaire commun aux

producteurs et auxconsommateurs de

logiciel

valeur, et ce à tous les stades du déve-loppement ; le produit demeure uneboîte noire, mais sa valeur est connueen temps réel.Niveau 5 : l’organisation a les moyenset la volonté de maîtriser l’efficacité dela maîtrise d’œuvre, en faisant ou nonappel à des compétences externes.

Bénéfices communsUne plus grande maturité apporteraitaux organisations consommatrices unemaîtrise croissante du rapportqualité/prix.Au niveau 1 : la qualité est aléatoire ;les besoins sont satisfaits par hasard,donc rarement.Au niveau 2 : les besoins sont partielle-ment satisfaits et de façon peu prévisible.Au niveau 3 : les besoins sont large-ment satisfaits, avec néanmoins despoints aveugles.

Au niveau 4 : la satisfaction desbesoins est quasiment garantie dès lesphases amont, la non-satisfaction decertains besoins est formalisée.Au niveau 5 : l’organisation connaît apriori le rapport entre le coût et la qua-lité du produit qu’elle va faire dévelop-per et elle en a la maîtrise.Les bénéfices d’une telle autoévalua-tion seraient également partagés par lesorganisations de développement(maîtres d’œuvre, sous-traitants) :celles-ci disposeraient d’une visionréaliste des qualités et des limites deleurs maîtrises d’ouvrage, et elles pour-raient se prémunir en conséquence.En matière de logiciel comme ailleurs,les exigences des consommateursseront sans aucun doute les meilleursstimulants de la qualité.

Yves [email protected]

Vision utilisateur et maturité

n° 189 décembre 2000 29

Les exigences desconsommateurs serontsans aucun doute lesmeilleurs stimulants de laqualité

Yves Constantinidis

Ne manquez pas ce numéro

Pour tout renseignement ou pour recevoir

Architecture Informatique et Télécom,

contacter Sylvie Garofalo au

tél. : 01 41 35 15 18 - Fax : 01 41 35 15 10

Chaque mois, dans Architecture Informatique et Télécom, un dossier complet pour orienter vos choix techniques

Bouhot & Le GendreProduits et Services

Au sommaire vous trouverez :

Les factures du 21ème siècle

Les moyens de paiement sur internet

Les mécanismes du traitement des cartes de crédit sur internet

Mise en place des paiements sur internet

Critères d’évaluation des solutions de paiement sur internet

Les standards basés sur le langage XML : une saine concurrence

Espace de confiance

Les problèmes de sécurité des paiements

Les moyens de paiement futurs du commerce électronique

Paiements électroniques : les agents électroniquesauront les pleins pouvoirs

La facturation électronique : l’importance de la relation client

Les portefeuilles électroniques

Revue d’auteurs, l’Informatique Professionnelle accueille des opinions qui n’engagent pas la rédaction.

Internautes

Souriez, vousêtes pistés !

e-business


N’importe qui peutenvoyer un message avecn’importe quelle adresse

d’expéditeur

Les messageries et les sites web sont des portes ouvertes pour lesmalveillants en général et les pirates en particulier. Mais attention, desparades existent !

Pour tout un chacun, “sécuritéInternet” rime souvent avec fire-wall, VPN, passerelle antivirus,SSL, etc. Pourtant, en se focali-

sant uniquement sur la sécurité des flux,des infrastructures réseaux, des serveursinternes (messageries, applications, etc.)ou externes (sites web, DNS, etc.), onoublie que l’utilisation irraisonnée et/ouincontrôlée d’un simple logiciel de mes-sagerie ou navigateur web peut mettre enpéril les informations confidentielles del’entreprise, relatives à ses activités ou àses salariés.Nous allons nous intéresser ici auxdeux services les plus utilisés surInternet, à savoir la messagerie et leweb.

Lettres ouvertes aux piratesRappelons quelques réalités simples !Un jour, un utilisateur de ma sociétém’envoya un mail, contenant l’en-têteSMTP d’un courrier électronique qu’ilvenait de recevoir et qui le laissaitquelque peu perplexe : il s’agissaitd’un message “anonyme”, dont l’expé-diteur avait indiqué une adresse sourceinvalide.Mon utilisateur s’étonnait qu’il soitpossible de faire ce genre de choses. Jedus alors lui expliquer que la message-rie, telle que des centaines de millionsde personnes l’utilisent chaque jourdans le monde, n’assure en standardaucun service d’authenticité. Celasignifie que n’importe qui peut

Ingénieur ESME-Sudria,

titulaire du Mastère spé-

cialisé en sécurité des sys-

tèmes informatiques et

des réseaux de l’ENST,

il est actuellement en

charge de la sécurité des

systèmes d’information

au sein d’une grande

entreprise française.

Eric Larcher

Souriez, vous êtes pistés !

n° 189 décembre 2000 31

Un e-mail peut êtremodifié en cours de routesans que son destinataireait un quelconque moyende s’en rendre compte

Pour signer un e-mail, ilfaut disposer d’uncertificat personnel valide

1 - Voir RFC 2633 sur www.rfc-edi-tor.org.

Eric Larcher

envoyer un message avec n’importequelle adresse d’expéditeur.Et même si un individu envoie un e-mail sous sa propre identité, rien nel’empêche de nier cet envoi ultérieure-ment. On appelle ceci la répudiation.La messagerie Internet ne permet pasnon plus la non-répudiation d’un cour-rier électronique.Par ailleurs, il faut savoir qu’un e-mailpeut être modifié en cours de route(que ce soit intentionnellement ou paraccident), sans que son destinataire aitun quelconque moyen de s’en rendrecompte. On dit alors que son intégritén’est pas garantie.Enfin, tout message circule “en clair”sur les réseaux qu’il emprunte lors deson transport du serveur SMTP de l’ex-péditeur vers celui de son destinataire.Ainsi, n’importe qui peut prendreconnaissance de n’importe quel mes-sage, du moment qu’il est capable del’intercepter en cours de route. Il n’y adonc aucune confidentialité.Résumons-nous : confidentialité, inté-grité, authenticité et non-répudiation,autant de services qui paraissent indis-pensables mais qui ne sont malheureu-sement pas assurés sur les messageriesélectroniques. Avec la place que prend la messagerieaujourd’hui dans les échanges entresalariés, partenaires, clients et fournis-seurs, il paraît donc déraisonnable de secontenter d’un système aussi peu fiableet qui date … de vingt ou trente ans !

S/MIMEAlors, comment faire pour sécuriser unoutil dont plus personne ne peut se pas-ser. Il existe une solution qui s’appelleS/MIME (1) (Secure/MultipurposeInternet Mail Extensions). Il s’agit del’extension sécurisée de la normeMIME (permettant d’attacher à unmessage toutes sortes de fichier).S/MIME, reconnue en standard au sein

des principaux clients de messagerieInternet, comme Netscape Messengerou Microsoft Outlook (Express), arecours :- Au chiffrement pour assurer la confi-

dentialité du courrier électronique ; - de la signature numérique pour mettre

à disposition les services d’intégrité,authenticité et non-répudiation quenous évoquions plus haut.

Quand on parle de chiffrement et/ou designature numérique, on pense automa-tiquement à la cryptographie, a fortiorià clés publiques. Et qui dit cléspubliques dit généralement certificats.En effet, il faut bien s’assurer de l’au-thenticité d’une clé et de l’identité deson titulaire, sinon on ne pourrait pasparler réellement d’authenticité ou denon-répudiation d’un message électro-nique signé.Le standard S/MIME repose justementsur des certificats numériques à lanorme X.509 v3. En pratique, pouractiver les fonctionnalités de chiffre-ment et de signature numérique dansun logiciel compatible S/MIME, il suf-fit de récupérer un certificat pourchaque individu souhaitant pouvoirs’échanger des messages “sécurisés”.Ainsi, pour signer un e-mail, il fautdisposer d’un certificat personnelvalide. Cette opération nécessite l’em-ploi de la clé privée associée au certifi-cat individuel que l’on possède. Pourchiffrer un message à l’attention d’uneautre personne, il faut donc au préa-lable disposer de son certificat afin deconnaître sa clé publique, nécessaireaux opérations de chiffrement.A l’arrivée, le destinataire suit ladémarche opposée : il utilise sa clé pri-vée (liée à la clé publique de son certi-ficat) afin de déchiffrer le messagequ’il a reçu, et emploie la clé publiquede l’expéditeur (contenue dans son cer-tificat) afin de vérifier la signature dece message.

e-business


On peut alors créer uneautorité de certification

interne à l’entreprise,capable de délivrer ses

propres certificats

Même si vous êtes le seulutilisateur de votre

ordinateur, lesadministrateurs systèmesde votre société pourront,

le plus souvent à votreinsu, accéder aux mêmes

informations…

2 - On peut alors en vérifier l’au-thenticité et l’intégrité grâce à laclé publique de l’autorité.

Pour une utilisation ponctuelle ou dansune population limitée, on peut secontenter de se connecter au site webd’une autorité de certification et deman-der, en ligne, un certificat, dont le coûtannuel sera de l’ordre d’une centaine defrancs pour les certificats les plusbasiques. Ces derniers seront alorsgénérés et signés par cette autorité(2).En revanche, s’il faut permettre à l’en-semble des salariés d’une société depouvoir envoyer des messages sécuri-sés, i l devient nécessaire d’avoirrecourt à ce qu’on appelle une infra-structure à clés publiques ou PKI(Public Key Infrastructure). On peutalors créer une autorité de certificationinterne à l’entreprise, capable de déli-vrer ses propres certificats. Ceux-cipourront alors être vérifiés non seule-ment par les salariés mais égalementpar les partenaires, clients ou fournis-seurs de l’entreprise.Ainsi, grâce à S/MIME, aux certificatset éventuellement aux PKI, il est pos-sible d’échanger des correspondancesélectroniques en toute sécurité, sans ris-quer la divulgation ou l’altération d’in-formations confidentielles et sensibles.

Des traces sur le Web Lorsqu’on surfe sur le Web pour la pre-mière fois, on découvre un monde(voire un univers) d’une richesseinsoupçonnée, où des millions de ser-vices sont rendus accessibles par unsimple clic de souris.Mais on est, en général, loin de se dou-ter que chaque site accédé, chaquepage, fichier ou image récupérés,chaque musique ou vidéo que l’on jouesur son ordinateur s’accompagne detoute une série d’enregistrements aussiprécis que nombreux.En local tout d’abord, c’est-à-dire surle poste de l’utilisateur, les navigateursweb enregistrent de façon horodatée,les adresses de toute page accédée,

dans un fichier ou répertoire appeléhistorique. Ce dernier permettait histo-riquement (si l’on peut dire) à l’utilisa-teur de différencier à l’écran les liensqu’il avait déjà visités durant les joursprécédents. Depuis les versions 4.0 desnavigateurs de Netscape et Microsoft,le système de “complétion” ou rem-plissage automatique des adresses encours de saisie dans la barre d’adressesrepose également sur cet historique.Ces adresses, entrées à la main, fontd’ailleurs l’objet d’un enregistrementspécifique par le navigateur.Mais tout ceci n’est rien à coté ducache. Le cache a pour objet de mémo-riser presque tous les éléments (textes,images, animations, sons, etc.) consti-tuant chaque page visualisée via le navi-gateur. Il permet de garder en mémoire(vive et sur le disque dur) les fichiersrécemment récupérés, afin d’en accélé-rer l’affichage en cas d’accès ultérieursà condition que les sites dont elles sontissues n’aient pas été modifiés.Le cache, l’historique ainsi que la listedes adresses saisies permettent donc desavoir précisément, non seulement lesadresses des documents visualisés parune personne, mais également lecontenu de ceux-ci. Dans le cas d’unemachine utilisée par plusieurs per-sonnes (dans un cybercafé ou aubureau), il n’est donc pas très difficilede savoir précisément ce que faisaitmonsieur X à 14 h 32, deux jours plustôt. Et même si vous êtes le seul utili-sateur de votre ordinateur, les adminis-trateurs systèmes de votre société pour-ront, le plus souvent à votre insu, accé-der aux mêmes informations…

Traces distantesMais là ne s’arrête pas le pistage. Eneffet, chaque serveur web génèrenombre d’informations, dans des“fichiers logs” contenant les noms desressources utilisées par les clients dis-

tants, les versions des navigateurs etdes systèmes d’exploitation utilisés parceux-ci, l’adresse de la page où a ététrouvé chaque lien accédé, etc. Cesinformations sont autant de traces dis-tantes, sur lesquelles l’utilisateur n’aque peu ou pas du tout de contrôle. Voici une ligne d’un fichier log, extra-ite du site web internet-securise.com.proxy.superisp2000.fr - -[25/Jun/2000:08:45:06 +0100] “GET /HTTP/1.1” 200 3620 “http://www.lar-cher.com/eric/guides/” “Mozilla/4.51[fr] (Win98; I)”Examinons chaque champ. Le premiercorrespond à l’adresse (IP ou DNS sidisponible) de la machine ayant accédéau site considéré. Viennent ensuitedeux tirets indiquant qu’aucuneauthentification n’a été utilisée (“accèsanonyme”). Ces champs sont rensei-gnés lorsque vous saisissez un couplenom d’utilisateur - mot de passe dansune fenêtre d’authentification, permet-tant ainsi d’accéder à une partie privéed’un site web.On trouve ensuite la date et l’heureexactes auxquelles la requête a étéreçue par le serveur web. Juste après,on note la commande envoyée par lenavigateur : “GET/HTTP/1.1” quisignifie “Je comprends la version 1.1du protocole HTTP, envoyez-moi la

page d’accueil (/) du site”. Cetteséquence est suivie d’un code (200)indiquant que la requête précédentes’est déroulée correctement (on auraitpu trouver ici le fameux code 404 si lapage n’avait pas existé) ainsi que lataille en octets des données envoyées.Ce que nous venons de décrire jusqu’àprésent est le minimum d’informationsgénérées par tout site web lors de l’ac-cès à n’importe quel fichier qu’il met àdisposition. Cela signifie que si la paged’accueil du site comporte trois images,nous verrions apparaître trois lignes(donc requêtes) de ce type (en plus decelle correspondant à la page d’accueilen elle-même), seul l’argument de lacommande GET variant d’une requête àl’autre (ex. : GET/images/accueil.jpg).Cependant, nous pouvons constaterque d’autres informations apparaissentdans la ligne du fichier log reproduiteplus haut. C’est tout simplement parceque nous avons activé le niveau maxi-mal de logging. On distingue en effetdeux chaînes. La première contientl’URL de la page à partir de laquellel’utilisateur a cliqué sur un lien poin-tant vers la page d’accueil du site dontla ligne de log est issue. En clair, ilexiste un lien sur la page d’adressehttp://www.larcher.com/eric/guides/pointant vers le site http://www.inter-

Souriez, vous êtes pistés !

n° 189 décembre 2000 33

Ces informations sontautant de traces distantes,sur lesquelles l’utilisateurn’a que peu ou pas dutout de contrôle

Eric Larcher

CONSEILS

Une PKI peut être “insourcée” ou “outsourcée”. Dans le premier cas, elle repose entièrement sur desinfrastructures internes à l’entreprise. Dans le second, elle est partiellement ou totalement sous-traitéeà une société spécialisée. Le choix de l’une ou l’autre de ces solutions s’effectue en fonction des besoinsde l’entreprise, de son budget, son organisation et des compétences dont elle dispose en interne. Danstous les cas, il ne faut surtout pas se contenter d’une approche technique mais également s’intéresseraux questions organisationnelles liées à l’implantation, l’utilisation et l’exploitation de la PKI.

• Les fichiers logs doivent êtres déclarés à la CNIL ainsi que les coordonnées de toutes les personnesayant accès à ces fichiers.

• Une charte d’utilisation encadrant l’utilisation des accès à Internet est indispensable.

• L’utilisation de serveurs proxy filtrants et/ou d’anonymat permet de réduire les risques de divulga-tion d’informations qui n’ont aucune raison de quitter l’entreprise. Notez cependant que certainssites ont besoin de ces informations ou utilisent des technologies à risques (scripts, applets, etc.) etpeuvent ne plus fonctionner correctement via ces proxies.

e-business


Lorsque vous surfeznombre de traces sont

générées par votrenavigateur en local et les

administrateurs desserveurs consultés saventexactement quelles pages

vous avez visualisées

Les logs générés par lesproxies internes peuvent

porter atteinte à la vieprivée des salariés

3 - Art. 5 de la loi du 6/1/78.

net-securise.com. On appelle ceci lechamp Referer.La seconde chaîne décrit précisémentle système ainsi que la version du navi-gateur utilisés. En l’occurrence, ils’agit ici de Netscape Communicator(nom de code “Mozilla”) en versionfrançaise 4.51 sous Windows 98.

Quels risques ?Ainsi, lorsque vous surfez sur n’im-porte quel site web, nombre de tracessont générées par votre navigateur enlocal et les administrateurs des serveursconsultés savent exactement quellespages vous avez visualisées, quel jouret à quelle heure, avec quel navigateuret système d’exploitation. Ils saventégalement d’où vous venez. Notez queces informations peuvent être égale-ment enregistrées au sein des serveursproxy dont votre entreprise dispose.Dans ce cas, le log du proxy va indi-quer en tête de chaque ligne : l’adressede la machine interne accédant au siteweb externe et le log du serveur ainsiconsulté comprenant celle du proxy(puisqu’il se situe entre le client et leserveur).Tout ceci n’est pas sans poser un cer-tain nombre de problèmes. Sur le planjuridique tout d’abord, les logs généréspar les proxies internes (ainsi que lesinformations stockées en local) peu-vent porter atteinte à la vie privée dessalariés puisqu’ils mémorisent exacte-ment les mêmes données que cellesque nous avons décrites plus haut. Deplus, il s’agit d’informations nomina-tives puisqu’elles permettent “l’identi-fication des personnes physiques aux-quelles elles s’appliquent(3)” (vial’adresse indiquée en tête de chaqueenregistrement).Ensuite, vis-à-vis des serveurs web dis-tants, il peut être dangereux de révélertant d’informations sur les systèmes etnavigateurs utilisés en internes et sur

les sites d’où est issu l’utilisateur. En effet, la connaissance des versionsexactes des logiciels et systèmesemployés permet de lancer des attaquescontre ceux-ci, autorisant parfois l’ac-cès à des fichiers disponibles en localsur la machine du surfeur. De plus, lechamp Referer peut révéler les adressesde serveurs intranet de l’entreprise siun lien vers un site web externe estproposé sur un tel serveur interne…

Des solutions antitracesHeureusement, il est possible d’effacervoire de désactiver les traces localesrien qu’en modifiant les paramètres deconfiguration des navigateurs.Concernant les traces distantes, lespossibilités sont plus complexes. Onpeut masquer l’adresse de la machineou du proxy accédant à un site web viaun proxy d’anonymat (commewww.anonymizer.com ou www.proxy-mate.com). Il est également possible deréduire le nombre et la précision desinformations générées via l’emploi deproxies fi ltrants locaux tels queAdSubstract, Webwasher ou encoreJunkbuster.Dans tous les cas, l’établissementd’une charte d’utilisation des accèsinternet, éventuellement secondée parun contrôle d’accès au niveau proxy etun anti-virus bloquant les scripts mal-veillants, permettent de limiter lesinformations sensibles pouvant insi-dieusement quitter l’entreprise.

Eric Larcher

([email protected])


BIBLIOGRAPHIEL’Internet sécurisé, Éric Larcher, mars 2000,Eyrolles.


Diminuerles risqueset négocier

En informatique, le management des achats relève d’appréciationsspécifiques et de pratiques communes. Outre la négociation tarifaire,l’acheteur professionnel peut aider l’informaticien à réduire le risquefournisseur et le risque contractuel.

On le sait, les achats informatiquescoûtent cher. Il n’est pas rare queleur montant atteigne le tiers desfrais généraux de nos entreprises.

Leur maîtrise est donc devenue un objec-tif prioritaire du management.Les achats informatiques conjuguentplusieurs particularités qui les différen-cient des achats traditionnels. Ces par-ticularités sont liées essentiellement àl’aspect stratégique de l’informatiquedans nos entreprises, à l’importancedes dépenses et à la rapidité de l’évolu-tion de la technologie.Remarquons aussi que l’informatiquese traite souvent en mode projet. Cesprojets comportent quasi systématique-ment un volet “achats”, pour des

licences, du matériel, des prestations deservice…

L’organisation des achatsPeu d’entreprises ont aujourd’hui réel-lement donné aux services achats lesmoyens d’intervenir sur les dépensesinformatiques. Les enjeux sont pour-tant importants et une bonne prise encompte des meilleures pratiques per-mettrait de réaliser des gains substan-tiels et d’éviter les erreurs liées à unemauvaise appréciation du risque. Mais, bien sûr, les freins sont nom-breux. De fait, l’introduction de la pro-blématique des achats dans nos projetsinformatiques relève d’une gestiondélicate du changement, car tradition-

Management

n° 189 décembre 2000 35

Peu d’entreprises ontréellement donné auxservices achats les moyensd’intervenir sur lesdépenses informatiques

Responsable des achats

informatiques dans une

grande banque privé.

Gilles Blanchard

nellement les chefs de projet sont seulsmaîtres à bord et s’occupent générale-ment aussi de la fonction achat.Pourtant les bonnes pratiques en matièred’achats informatiques exigent un fonc-tionnement en équipe entre les acheteurset la direction du projet. Que le projetinformatique soit complexe, ou qu’ilconcerne la simple homologation d’unmatériel qui sera approvisionné au fildes besoins, chacun a son rôle à jouer. Plus un achat est stratégique, plus ladirection du projet pilote et décide enconnaissance de cause. Le service achatsa, dans ce cas, la charge de proposer desstratégies d’acquisition et de négociationfournisseur. Plus l’achat est banal etconcerne des produits de commodité,plus le service achats sera autonome.Pourquoi une telle organisation ?Parce que l’aspect prix ne peut pas êtrele seul élément à prendre en comptepour les achats informatiques. Ainsi,lorsque l’on acquiert une solutioninfluant directement sur la compétiti-vité de l’entreprise sur ses marchés, leprix ne peut évidemment pas être lecritère principal.

Les risques “achat”En fait, si le principe générateur de lafonction achat se situe dans la maîtrisedes dépenses, le rôle de l’acheteur ne selimite pas à cela. Dans les achats structu-rants, comme c’est souvent le cas eninformatique, l’acheteur a une autre res-ponsabilité importante. Il doit absolumentlimiter un double risque lié à cet achat : lerisque fournisseur et le risque contractuel.

Le risque fournisseurDiminuer le risque fournisseur est clai-rement une tâche du service achats.Certes, il est vain de penser qu’un ser-vice achats peut suivre la santé finan-cière de tous les fournisseurs. Mais iln’est pas impossible de définir la listedes dix ou vingt fournisseurs princi-

paux et d’organiser son service achatsde façon à connaître en permanencel’évolution de ce “hit parade” d’entre-prises. Pour cela, il convient de :• mener des réunions périodiques entre

les acheteurs et les responsables com-merciaux et administratifs par exemple,

• assurer le suivi des affaires en coursavec l’avis des chefs de projet sur ledéroulement des prestations,

• attribuer une notation qualité à jour,• faire réaliser des audits fournisseurs

par des organismes spécialisés.Voici quelques idées pour diminuer lerisque fournisseur. Il n’en reste pasmoins que souvent la crise chez unfournisseur se déclenche de façon bru-tale parce que des éléments d’apprécia-tion ont été soigneusement dissimulés.

Le risque contractuelSi la responsabilité de la négociationdes contrats se retrouve habituellementau sein du service achats, en ce quiconcerne l’informatique la réductiondu risque contractuel ne pourra se fairequ’en connaissance de cause.Comment en effet négocier un risquecontractuel si on ne comprend pas lecahier des charges ?Face à ce problème, certains répondentqu’il s’agit là d’une préoccupation duchef de projet. Justement non ! Le chefde projet connaîtra dans sa vie peut-êtredeux ou trois projets majeurs, alors quel’acheteur en négociera des dizaines. Cedernier aura une expérience d’une autrenature que celle du chef de projet. Ilpourra alors négocier des engagementsfournisseurs à partir d’une expériencecertes moins en profondeur dans lesprojets, mais bien plus diversifiée.C’est, là encore, la collaboration entrel’acheteur et le chef de projet qu’il fautprivilégier.

Gilles Blanchard

Management


Les bonnes pratiques enmatière d’achats

informatiques exigent unfonctionnement en équipe

entre les acheteurs et ladirection du projet

Le chef de projetconnaîtra dans sa vie

peut-être deux ou troisprojets majeurs, alors que

l’acheteur en négocierades dizaines


Concepteurs

La doublecompétenceest de rigueur

Toute application nouvelle est le fruit d’un compromis entre les besoins, latechnique et l’organisation. A la croisée des chemins, le concepteur doitdisposer de la durée pour devenir aussi un bon connaisseur du métier del’utilisateur.

Tout le monde s’accorde sur lanécessité de coupler la concep-tion des applications informatiquesà un véritable reengineering de

l’organisation et des procédures exis-tantes. Car il va de soi que l’informatiquen’est qu’un moyen parmi d’autres pourl’exécution de processus de gestion oude production, dans lesquels toutes lestâches interagissent entre elles. C’est avecl’objectif d’améliorer le plus possiblel’efficacité d’ensemble d’une unité opé-rationnelle que doivent être menées lesétudes de conception. Là est la conditionpremière d’une bonne rentabilité desinvestissements informatiques, et celanécessite un travail d’étude en profon-deur de chaque domaine concerné par des

développements informatiques.C’est aussi une tâche quasi permanenteque de veiller à la meilleure synergieentre les fonctions du système d’infor-mation et le reste des processus opéra-tionnels. Car le système d’informationdoit régulièrement évoluer, tant pourtirer parti de l’évolution technique quepour prendre en compte l’évolution desmétiers des utilisateurs, lesquels doi-vent souvent répondre à des exigencesou à des opportunités nouvelles.Ces principes étant admis, il faut entirer toutes les conséquences quant àl’organisation des travaux d’étude etaux moyens humains mis en œuvre.Les concepteurs sont les premiersconcernés.

Ressources humaines

n° 189 décembre 2000 37

C’est avec l’objectifd’améliorer le pluspossible l’efficacitéd’ensemble d’une unitéopérationnelle quedoivent être menées lesétudes de conception

Diplômé d'une école

d'ingénieurs (Ponts 1973),

André BORS a été chef de

projet, puis responsable

d'un centre de développe-

ment et d'exploitation

informatiques.

Il est aujourd'hui conseiller

informatique au Ministère

des Affaires étrangères.

André Bors

La fonction organisationDe prime abord, la solution coule desource : elle consiste à doter l’entre-prise non d’un simple service informa-tique, mais d’un service informatiqueet organisation. Concrètement, ce ser-vice est alors doté d’une équipe dédiéeà la fonction organisation, avec pourmission de travailler le plus possible ensynergie avec les équipes de dévelop-pement.C’est là une solution qui a longtempseu la faveur de la profession. Son prin-cipal avantage est d’affirmer claire-ment une volonté politique d’efficacitéet de rationalisation. Ainsi le serviceinformatique et organisation se trouve-t-il dûment investi pour étudier etdévelopper des solutions susceptiblesde faire évoluer l’organisation exis-tante. Un autre avantage de la formuleest de disposer en interne de consul-tants qui, pour peu qu’ils disposent dela durée, acquièrent progressivementune très bonne connaissance dudomaine sur lequel ils interviennent.C’est, pour ces intervenants, un pré-cieux atout, dont ne disposent pas leplus souvent les consultants externes.Malgré cela, les résultats ont souventété décevants et la formule est large-ment tombée en désuétude.La première raison tient sans doute à ceque les moyens humains affectés à lafonction ont rarement été à la hauteurdes besoins. Faute d’une consciencesuffisante de l’enjeu, la tentation l’aparfois emporté de donner dans lademi-mesure. On a recruté en nombreinsuffisant des consultants du niveauadéquat, ou bien on s’est contenté defaire intervenir des consultants exté-rieurs ponctuellement sur les projets lesplus stratégiques.Quoi qu’il en soit, la formule présenteun inconvénient majeur, à savoirqu’elle fait peu de cas du rôle et de lacontribution des utilisateurs pour la

conception et la mise en œuvre dessolutions. Car même avec une solideéquipe de consultants, la contributiondes utilisateurs reste une condition sinequa non du succès des projets. Or, dansce schéma, la mobilisation des utilisa-teurs ne va pas de soi. Parce que ceux-ci se trouvent alors dans une positionun peu “inférieure”, ou ressentiecomme telle, et que cela ne favorisepas l’instauration d’un véritable parte-nariat. En fait, beaucoup d’utilisateurscomprennent mal qu’un service qu’ilsperçoivent d’abord comme un servicetechnique se trouve ainsi investi d’unpouvoir d’intervention dans leur tra-vail, un pouvoir qui sous-tend peu ouprou celui de l’évaluation. Le risque estgrand, dans ces conditions, que les uti-lisateurs ne s’investissent pas suffisam-ment dans des projets qu’ils ne ressen-tent pas comme étant les leurs.Le problème reste ainsi posé de bienrépartir les rôles entre utilisateurs etinformaticiens.

L’implication et le rôle desutilisateursSi l’on ne peut se permettre de canton-ner les utilisateurs aux seconds rôles, ilfaut éviter de trop “inverser la vapeur”au détriment du rôle et des prérogativesdu service informatique. Ainsi l’idée deconfier aux directions et services utili-sateurs les tâches de conception et lamaîtrise des choix de solutions pré-sente de sérieux inconvénients.De même que les informaticiens nepeuvent être au même niveau que lesutilisateurs dans la connaissance deleur métier, ces derniers n’ont pas lacapacité d’appréhender les aspectstechniques des choix de solutions.L’ expérience montre qu’il est très diffi-cile d’expliquer aux utilisateurs lestenants et aboutissants de la mise enœuvre d’un nouveau système d’exploi-tation ou d’une nouvelle filière de

Ressources humaines


Même avec une solideéquipe de consultants, la

contribution desutilisateurs reste une

condition sine qua non dusuccès des projets

L’idée de confier auxdirections et services

utilisateurs les tâches deconception et la maîtrise

des choix de solutionsprésente de sérieux

inconvénients

développement. Fort logiquement,l’utilisateur ne s’intéresse qu’à lacouche supérieure du système, cellequ’il voit. Il ne peut pas appréhenderdes questions comme celles de lapérennité du système d’exploitation oude la dépendance vis-à-vis d’un four-nisseur.C’est pour cela qu’il faut aussi exclurela possibilité, parfois évoquée, de fairerédiger les cahiers des charges par lesseuls utilisateurs. Il est indispensableque les concepteurs informaticiens yprennent une part prépondérante.Confier aux directions utilisatrices lestâches de conception et la maîtrise deschoix de solutions, c’est aussi s’orien-ter vers une segmentation du systèmed’information qui risque fort de mettreen péril sa cohérence d’ensemble.Souvent préoccupés d’aller vite, lesutilisateurs ont naturellement tendanceà “faire leur marché” et à pousser àl’acquisition d’équipements (matérielset/ou progiciels) sans se préoccuper del’existant en matière de filières dedéveloppement ou de réseaux, sansparler des contraintes de sécurité. Il estalors difficile au service informatiquede faire prendre en compte ses argu-ments techniques et de jouer son rôled’architecte du système d’information.

Des concepteurs compétentsdans leur domaineEn fait, il n’y a guère d’alternative ! Leservice informatique doit s’astreindre àappréhender le mieux possible le tra-vail des utilisateurs et à concevoir dessolutions qui allient la richesse fonc-tionnelle au réalisme technique. Il s’en-suit que les concepteurs doivent parve-nir à joindre les deux bouts que consti-tuent le métier des utilisateurs d’unepart, l’état de l’art informatique d’autrepart. Pour ce faire, il ne suffit pasqu’ils soient “à l’écoute” des utilisa-teurs.

En effet, la mission d’un concepteur neconsiste pas à enregistrer servilementles demandes “fonctionnelles” de ceuxqu’on leur a désignés comme interlocu-teurs. Il n’existe pas de besoin fonc-tionnel qui se concevrait et s’exprime-rait indépendamment des techniquesdisponibles. Une nouvelle applicationest de plus en plus souvent issue de larencontre entre une possibilité tech-nique nouvelle et un besoin, parfoislatent.Pour construire les solutions les mieuxadaptées aux besoins, la conceptiondoit aussi être un processus itératif.Elle nécessite que s’instaure entre lesconcepteurs et les utilisateurs de tousniveaux, des échanges continus et untravail en symbiose. Ainsi peuvent sefaire, au jour le jour, les arbitrages surles fonctionnalités des applications,mais aussi sur les calendriers de déve-loppement ou diverses modalités demise en œuvre.

La voie à suivreCette constatation induit deux consé-quences principales quant à l’organisa-tion des études :1. Concernant la formation desconcepteurs. Quand ils ne possèdentpas déjà une vraie compétence dans ledomaine sur lequel ils interviennent,les concepteurs d’origine informatiquedoivent l’acquérir. Il vaut mieux, pourcela, ne pas se satisfaire d’une forma-tion sur le tas, au travers d’échangesavec les utilisateurs ou d’une documen-tation parcellaire. On ne doit pas hési-ter à investir dans une formation adhoc. Le principe doit être de dévelop-per réellement une double compétenceciblée et que la fonction ne dérive pasvers un profil de généraliste. A l’in-verse, les personnes dont la formationinitiale est non technique, par exempledes diplômés d’écoles de gestion, doi-vent s’imposer de suivre un cycle de

La double compétence est de rigueur

n° 189 décembre 2000 39

Fort logiquement,l’utilisateur ne s’intéressequ’à la couche supérieuredu système, celle qu’il voit

Le service informatiquedoit s’astreindre àappréhender le mieuxpossible le travail desutilisateurs et à concevoirdes solutions qui allient larichesse fonctionnelle auréalisme technique

André Bors

formation informatique qui fasse d’euxdes professionnels. Dans tous les cas,une réelle capacité d’adaptation estnécessaire et un niveau élevé de forma-tion initiale est très souhaitable.2. Concernant la gestion des équipesd’étude. Dès lors que des concepteursont été affectés sur un domaine, il estsouhaitable de les y maintenir pendantune période suffisante pour justifierl’investissement consenti. D’ailleurs,même avec une formation ad hoc, cen’est que progressivement qu’ils pour-ront s’immerger dans le métier des uti-lisateurs.Cela ne signifie nullement qu’ils doi-vent se trouver en sous-charge entredeux phases de développement d’uneapplication. D’une part, le domaineconfié à un ou plusieurs concepteurscomportera généralement un ensembled’applications dont les développe-ments, les évolutions, les refontes doi-vent être planifiés de manière à lisserleur charge de travail. D’autre part, lesconcepteurs doivent, entre deux phasesde développement, rester très présentsauprès des utilisateurs. Pourquoi ?Pour, entre autres choses, prendre encompte la maintenance indispensable,négocier le calendrier des fonctions quipourront être reportées, faire le bilandes gains par rapport aux coûts, prépa-rer les futures versions, étudier les évo-lutions dans le travail des utilisateurs.Ainsi, même si les concepteurs affectésà un domaine peuvent être en nombretrès réduit, ils doivent constituer lenoyau stable qui assure un service per-manent d’étude, de suivi et de “gestionclient” des utilisateurs. Il faut donc enprendre son parti. Les concepteursconstituent une ressource peu mobile,surtout par rapport aux développeursqui doivent pouvoir passer rapidementd’une application à une autre.Une objection assez courante à cetteapproche est qu’elle mettrait les

concepteurs dans une situation de “pro-priétaire” de leurs applications. On yrépondra en précisant simplement quedisposer de la durée n’est pas syno-nyme d’inamovibilité. Même avec deschangements d’affectation très espacés,le principe de mobilité doit s’appliquer,tout comme celui de l’évaluation.Précisons enfin que la mission ainsidéfinie pour les concepteurs ne laisseguère de place à d’autres tâches, enparticulier à l’encadrement des déve-loppeurs. Celle-ci doit revenir auxchefs de projet ou aux chefs d’applica-tion, des fonctions à bien distinguer decelle de concepteur.Tout compte fait, la fonction deconcepteur tend à se confondre, surtoutpour les plus expérimentés, avec cellede consultant. Et compte tenu de cetteproximité avec la fonction de conseil,on doit pouvoir attendre d’eux qu’ilsassurent aussi un rôle pédagogiqueauprès des utilisateurs.

André Bors

Ressources humaines


Les concepteurs doiventconstituer le noyau stable

qui assure un servicepermanent d’étude, de

suivi et de “gestionclient” des utilisateurs

L’encadrement desdéveloppeurs doit reveniraux chefs de projet ou aux

chefs d’application


Dossier Governance

Governance et NTIFaire plus avec moinsBalance Score CardUn modèle fédéralSourcing

et aussi...

Pilotage des intranetsE-mail et vie privée

Au sommairedu prochain numéro

Refacturation des réseaux

La diplomaties’impose !

Avec la multiplication des réseaux, l’explosion des coûts n’a pas tardé.Quand on veut remettre de l’ordre et canaliser les ardeurs, la refacturationdes réseaux aux utilisateurs est souvent utilisée. Plusieurs méthodes existentmais une seule réussit vraiment : la diplomatie. Etude de cas.

Les DSI et autres responsables infor-matiques sont fortement impliquésdans les décisions concernant lesdépenses informatiques et la plu-

part cherchent également à mettre au pointdes stratégies efficaces de refacturation.Gartner présente ici une étude de casconcernant une entreprise américaine.Cette entreprise s’était aperçu que salogique de récupération des coûtsWAN (ou réseaux étendus) ne répon-dait pas à ses besoins et ne fonctionne-rait plus dans ses futures architecturesde réseau. Un projet destiné à choisirles meilleures politiques de refactura-tion fut donc lancé. Sa conclusion futqu’il faudrait engager de gros effortspour parvenir à mettre en place un sys-

tème de refacturation des WAN fondésur l’usage.

Les méthodologies derefacturationDurant les années 90, les réseaux, et enparticulier les réseaux étendus d’entre-prise, ont changé radicalement entermes de technologie et d’importancestratégique. Mais les mécanismes admi-nistratifs, comme par exemple la refac-turation, n’ont pas suivi. De plus, lesentreprises essayent de mettre en placede nouveaux systèmes de réseau IPcomplexes tout en conservant leursbudgets informatiques au même niveau.La refacturation est un des mécanismesqui permet de faire face à la croissance

Télécommunications

n° 189 décembre 2000 41

La refacturation est undes mécanismes quipermet de faire face à lacroissance rapide du coûtglobal des réseauxétendus

Edward Younkeret David Neil

Gartner

rapide du coût global des réseaux éten-dus. Mais comme la plupart des sys-tèmes de refacturation ont été conçuspour gérer des réseaux anciens, il estnécessaire de chercher une nouvelleapproche de la refacturation desréseaux étendus.Les divers types de refacturation envigueur aujourd’hui sont les suivants :- un coût fonction du nombre d’utilisa-

teurs ;- la mesure de l’utilisation effective ;- le coût direct ;- le forfait par niveau.

Un coût fonction du nombred’utilisateursCette logique de facturation est utiliséepar de nombreux services informa-tiques comme une méthode passe-par-tout dans des domaines où lesmétriques sont encore mal maîtriséesou trop coûteuses à mettre en œuvre.Cet “abonnement” couvre un ensemblede services de base et de moyens per-mettant aux utilisateurs de faire leurtravail. Cela comprend par exemple :l’usage du helpdesk, les opérations surles PC, les services liés aux réseauxlocaux ou étendus, les services d’im-pression, etc.

La mesure de l’utilisationeffectiveCette méthodologie de refacturation sefonde sur des mesures représentativesde l’utilisation effective, tels que lenombre de MIPS, les secondes de CPU,les volumes de stockage sur disque oubien sur les paquets échangés et lestransactions effectuées. Certains res-ponsables informatiques, maniaques dela mesure, vont “tout” mesurer pourpouvoir calculer plus précisément lescoûts imputables à chaque acteur etpour garantir une égalité de traitement.Dans le cadre du passage des réseauxprivés à des réseaux partagés, la

mesure de l’utilisation effective estdevenue la forme la plus courante defacturation des réseaux.

Le coût directCertains services informatiques adopte-ront ou conserveront des méthodolo-gies de coût direct car nombre d’entreeux hésitent à adopter des méthodolo-gies de refacturation plus novatrices.La plupart découperont arbitrairementles coûts relatifs à un serveur partagé àpartir d’un chiffrage fait une fois par an(par exemple, sur la base de lamémoire disque, des entrées/sorties, dunombre de connexions par mois ou dunombre de transactions). Ces méthodo-logies de coût direct peuvent alimenterune sous-capacité chronique etaccroître les coûts.

Les tarifs forfaitairesà plusieurs niveauxLa méthodologie de refacturation sur labase d’un tarif forfaitaire à plusieursniveaux est généralement liée à diffé-rents niveaux de service garantis pourle réseau. Par exemple, avec ce sys-tème, à chaque niveau de disponibilitécorrespondra un tarif particulier. Ladisponibilité sans backup pourraitreprésenter le premier niveau. La dis-ponibilité avec backup téléphoniquepourrait constituer un second niveau etdes réseaux totalement redondantsreprésenter le niveau le plus élevé.

Le cas d’une entrepriseUne grande entreprise, géographique-ment dispersée, cherche à savoir com-ment optimiser les performances deson réseau et améliorer ses niveaux deservice. Elle a regroupé ses réseauxanciens sous forme d’un réseau IP(1200 routeurs et 60 000 utilisateurs) eta réussi à réduire le coût global de sonréseau étendu en dépit des mises àniveau de l’infrastructure, des contrain-



Certains servicesinformatiques découperont

arbitrairement les coûtsrelatifs à un serveur partagé

à partir d’un chiffrage faitune fois par an

A chaque niveau dedisponibilité correspondra

un tarif particulier

tes budgétaires et du manque de per-sonnel technique.Le trafic sur le réseau devrait doublerdans les deux prochaines années en rai-son de l’utilisation accrue des outils deplanification, de l’amélioration de lasécurité et de l’introduction des nou-velles applications. L’entreprise doitdonc dès maintenant investir fortementdans un nouveau réseau. Mais sil’usage du réseau n’est pas soigneuse-ment suivi et contrôlé, les coûts ris-quent fort de s’envoler.Les politiques de refacturation et lespratiques administratives correspon-dantes sont un des moyens essentielspour parvenir à une maîtrise des coûts.Les méthodes actuelles de récupérationdes coûts consistent en une associationde différentes méthodes : des affecta-tions de coûts à un niveau très global ;un système de refacturation simple(avec des accords sur les niveaux deservice) ; une refacturation réelle descoûts, qui ne permet de récupérer glo-balement qu’environ 50 % du coûtannuel d’un réseau étendu, auprès desclients internes et externes.Au plan organisationnel, le service chargédes réseaux étendus est structuré etfinancé comme un centre de coût dépen-dant du budget informatique central.

Les résultatsA la mi-1999, l’entreprise a lancé unprojet destiné à réétudier l’ensemble deces méthodes de refacturation. Elle aexaminé les meilleures méthodes envigueur dans les autres entreprises etmis en place des recommandationsconcernant sa politique future de refac-turation.Les principaux résultats de l’étude ontété les suivants.Les systèmes de refacturation de l’utili-sation effective, sur la base du nombrede paquets transmis, ne sont pas encoremûrs. Moins de 1 % des grosses entre-

prises ont mis en place de tels systèmesde refacturation. L’entreprise conti-nuera à travailler avec des systèmes for-faitaires ou fondés sur la nature des ser-vices fournis, jusqu’à ce que les modesde mesure de l’utilisation effective aientmûri, vers les années 2002-2003.Les directions opérationnelles de l’en-treprise considèrent souvent lesdépenses de réseaux étendus comme del’argent perdu. Dans ce cas, elles pen-sent évidemment que tout le travail desuivi, de mesure et d’évaluation descoûts liés à leur utilisation est inutile.L’adoption de systèmes de refactura-tion des réseaux étendus IP n’est pasencore très répandue et l’on constateune ignorance assez générale des avan-tages de la refacturation, même chezceux qui la mettent en pratique.La refacturation des réseaux étendus peutconstituer une méthode efficace pourmaîtriser l’utilisation de la bande pas-sante. Elle permet de promouvoir la révi-sions de certaines méthodes de travail etelle facilite le dialogue entre les diverspartenaires pour la mise au point d’ac-cords sur les niveaux de service.Cependant, si elle est mal mise en œuvre,une telle refacturation sera inefficace.La logique et les pratiques de refactu-ration doivent être harmonisées avec lastructure de l’entreprise, les évolutionsprévues, la stratégie du départementinformatique et les principes modernesde gestion financière.Ainsi :- il faut définir clairement les objectifs

visés et les bénéfices attendus de lamise en place d’une refacturation ;

- la refacturation devra être utiliséedans le cadre d’une stratégie globaledestinée à s’assurer que les ressourcessont utilisées de la façon la plus effi-cace et ne deviennent pas une armecontre les utilisateurs ;

- le soutien de responsables de hautniveau est indispensable ;

La diplomatie s’impose

n° 189 décembre 2000 43

Les politiques derefacturation et lespratiques administrativescorrespondantes sont undes moyens essentielspour parvenir à unemaîtrise des coûts

L’entreprise continuera àtravailler avec dessystèmes forfaitairesjusqu’à ce que les modesde mesure de l’utilisationeffective aient mûri

Edward Younker et David Neil

- les utilisateurs doivent être tenus res-ponsables des niveaux de servicequ’ils exigent.

Les facteurs clés de succèsCette entreprise est dans une phase cru-ciale de transition vers la mise enœuvre d’une politique de refacturationde son réseau et la mise en place destructures organisationnelles permet-tant de gérer la prochaine génération deréseaux. L’étude a montré qu’il n’exis-tait qu’un tout petit nombre d’entre-prises qui mettaient en œuvre desméthodes de refacturation fondées surl’utilisation effective. Les autres entre-prises utilisaient des méthodes derefacturation mises au point pour desenvironnements plus anciens, qui sontbeaucoup moins complexes du point devue de la refacturation.Les premières tentatives de refactura-tion des réseaux étendus menées parcette entreprise n’ont pas été très réus-sies car elles n’avaient pas été “bienvendues” à l’intérieur de l’entreprise.On aurait pu mieux surmonter les résis-tances initiales. Pour cela, il est indispen-sable que le directeur informatique (ou ledirecteur technique de l’entreprise) sefasse l’avocat de la refacturation. Il fautarriver à un consensus chez les respon-sables hiérarchiques des utilisateurs ets’assurer que les utilisateurs et les infor-maticiens comprennent les objectifs àcourt terme de la refacturation du réseau.Cela nécessite une approche presque“commerciale” du problème afin decommuniquer et de former l’ensembledes équipes de l’entreprise.La première priorité devrait être defaire évoluer les règles de refactura-tion, leurs conséquences organisation-nelles et les pratiques administratives.Ensuite, il faudra donner la priorité auxoutils, à la structure du modèle de fac-turation ainsi qu’au calcul des taux etdes charges.

Il est important d’expliciter et de défi-nir la future structure organisationnelleainsi que les services qui seront four-nis. Dans la plupart des entreprises, lepassage à de nouvelles structures detravail (par exemple, à l’utilisationd’un prestataire de service indépen-dant) devra se faire progressivement.De fait, le passage d’un centre de coûtinterne à un prestataire de servicesexterne est une opération qui prend dutemps et qui coûte de l’argent.Les utilisateurs et les informaticiensdoivent être formés aux objectifs et auxavantages de la refacturation du réseauétendu. Chaque méthode de refactura-tion est spécifique. Toutes possèdentleurs avantages et leurs inconvénients.La structure d’un modèle de refactura-tion des réseaux en entreprise serahybride, et combinera des approchesfondées sur l’utilisation effective asso-ciées à des approches fondées sur desaffectations de coûts ou sur des tarifsforfaitaires.Il serait intéressant d’envisager unmodèle forfaitaire à plusieurs niveaux,fondé sur les besoins en bande passanteet sur les niveaux de service. Cecipourrait constituer un système transi-toire en attendant de passer à un sys-tème fondé sur les consommationsréelles. Cependant, les accords sur lesniveaux de service et les coûts doiventêtre précisés pour chaque groupe d’uti-lisateurs et pour chaque système. Ils’agit là de tâches qui ne sont pasfaciles à mener.

En conclusionCette entreprise a pris conscience dufait que, parallèlement aux mutationsdes techniques des réseaux étendus,l’utilisation efficace de ses infrastruc-tures exige de nouveaux mécanismesde contrôle, tels que la refacturation.L’entreprise a conclu que la mise enœuvre d’une refacturation constitue



Les premières tentativesde refacturation des

réseaux étendus menéespar cette entreprise n’ont

pas été très réussies

La première prioritédevrait être de faire

évoluer les règles derefacturation, leurs

conséquencesorganisationnelles et les

pratiques administratives

plus un problème de diplomatie interneet de gestion financière qu’un pro-blème technique concernant les outilsde comptabilisation des ressourcesréseau. L’entreprise a également prisconscience du fait qu’un soutien visiblede la part des dirigeants est déterminantpour maximiser l’efficacité de la refac-turation. L’entreprise en a conclu que lefait de passer à de nouvelles méthodo-logies va poser des problèmes culturelset va probablement être une opérationcomplexe et consommatrice de temps.L’entreprise n’a pas encore mis enplace ces recommandations : elle estconfrontée actuellement aux problèmesde base qu’a soulignés l’étude.Les autres sociétés devraient profiter

des expériences vécues par cette entre-prise et analyser l’état de leurs sys-tèmes de refacturation et la façon dontelles vont s’attaquer au suivi et à lamaîtrise de la prochaine génération deréseaux. Un échec en ce domaine risquerait setraduire par une perte de contrôle surles coûts, qui pourraient se mettre àcroître très vite, sans que l’on en retiredes bénéfices en proportion ; il seraitensuite très difficile de reprendre lecontrôle de la situation.On doit également se rappeler que lesévolutions technologiques finiront tou-jours par prendre le pas sur toutes lesméthodologies de refacturation.

Edward Younker, David Neil

La diplomatie s’impose

n° 189 décembre 2000 45

Un soutien visible de lapart des dirigeants estdéterminant pourmaximiser l’efficacité dela refacturation

Edward Younker et David Neil

B U L L E T I N D E C O M M A N D E

Un nouveau rapport

Le tableau de bordjuridique des DSI

Ce rapport est conçu comme un ensemble de fiches pratiques répondantaux différentes contraintes et situations rencontrées par une DSI.

� Un outil indispensable, compte tenu de l’importancecroissante du droit pour les DSI.

Merci de m'envoyer votre dernier rapport"Le tableau de bord juridique des DSI" au prix de 3500 F HT (tva 5,5 %) + 38 F de port(tva 19,6 %) étranger 3700 FF + 73 F de port

Date :

Signature :

Nom : Prénom :Société : Fonction :Adresse :

Code postal : Localité :Tél. : Fax :

Je joins mon règlement par chèque à l'ordre de GartnerGroup France et je recevrai une facture justificative.

Je règlerai à réception de facture.Conformément à la législation en vigueur, vous disposez d'un droit d'accès et de rectification pour toute information vous concernant.

Un outil exceptionnel

Bulletin à retourner ou à faxer à : Sylvie GarofaloImmeuble Défense Bergères - 345 avenue Georges Clemenceau - TSA 4000292882 NANTERRE cedex 09 - Tél. : 01 41 35 15 15 - Fax : 01 41 35 15 10

Le tableau

de bord juridique

des DSI

Bouhot & Le Gendre

Produits et Services

+ CDAVEC DES MODELESDE CLAUSESConçu et rédigé par ALAIN BENSOUSSAN-AVOCATS

L’article 3 de la loi de finances pour2000(1) a instauré un nouveaurégime fiscal des indemnités delicenciement, applicable pour les

revenus perçus en 1999. En effet, le pré-cédent régime laissait place à une grandeincertitude puisqu’il n’exonérait l’in-demnité de licenciement de l’impôt surle revenu que pour les sommes qui com-pensaient un préjudice autre que la pertede rémunération, c’est-à-dire les sommesversées correspondant à l’indemnisationd’un préjudice. Ainsi, les tribunaux avaient mis enplace un certain nombre de critères quipermettaient de déterminer la part del’indemnité correspondant à l’indemni-sation d’un préjudice. Ils prenaient en

considération, par exemple, des élé-ments comme l’âge du salarié, la pertede statut social, d’éventuelles difficul-tés de réinsertion pour évaluer la partexonérée de l’indemnité. Le montant de l’exonération dépendaitdonc de l’appréciation souveraine dujuge. Celle-ci étant particulièrementsubjective, il pouvait en résulter, pourle contribuable, de “désagréables sur-prises” et des redressements fiscauximportants. En effet, il était particuliè-rement difficile d’évaluer financière-ment la part de l’indemnité qui corres-pondait à l’indemnisation d’un préju-dice. Le contribuable se retrouvaitdonc dans une situation délicate lors del’établissement de sa déclaration de

Indemnités de licenciement

De la subjectivitéà l’objectivité

Arrêts et tendances


Il était particulièrementdifficile d’évaluer

financièrement la part del’indemnité quicorrespondait à

l’indemnisation d’unpréjudice

1 - Loi n° 99-1172 du 30 décembre1999, JO du 31 décembre 1999

Le régime fiscal des indemnités de licenciement a changé. Ce qui relevait del’appréciation du contribuable, des services fiscaux ou du juge estdorénavant fixé dans la loi. Plus objectif, le nouveau régime est toutefoismoins malléable.

Avocat à la Cour,

Alain Bensoussan-Avocats,

Directeur du département

Fiscalité et Droit des sociétés

Eric Boulanger

revenus puisqu’il devait seul effectuercette évaluation. Des contribuables debonne foi pouvaient dès lors mal éva-luer la part de leur indemnisation exo-nérée. Aux “tracas” du licenciementpouvaient alors s’ajouter ceux d’uneprocédure de redressement fiscal. Plusgrave, cette évaluation pouvait être trèsdifférente entre les juridictions etengendrer ainsi des “inégalités fis-cales” importantes.La loi nouvelle a le mérite de présenterclairement le régime fiscal des indem-nités de licenciement et de distinguercelles qui sont imposables et celles quisont exonérées d’impôt sur le revenu.Elle rappelle tout d’abord le principede l’imposition des indemnités delicenciement. Sont ainsi imposablestous les types d’indemnités : l’indem-nité compensatrice de préavis, l’indem-nité compensatrice de congés payés,l’indemnité de non-concurrence. Elleprévoit ensuite un certain nombred’exonérations. Celles-ci ne concernenttoutefois que les salariés qui ont aumoins deux ans d’ancienneté dans l’en-treprise et ceux dont les employeursoccupent habituellement au moins onzesalariés. Ainsi sont intégralement exo-nérées, les indemnités versées en casde licenciement abusif ou irrégulier,celles versées en cas de violation de laprocédure de licenciement et cellesversées dans le cadre d’un plan social. La loi précise, le cas échéant, un modede calcul objectif de la part exonéréede l’indemnité de licenciement, ne lais-sant plus de doute quant à une éven-tuelle qualification ou une appréciationsubjective du préjudice subi par le sala-rié licencié. Elle fixe enfin un montantmaximal pour la part exonérée : la moi-tié de la première tranche d’impositionde l’ISF, soit 2,35 millions de francs.S’agissant des indemnités exonérées,celles-ci ne le sont que dans la limite duplus élevé des trois montants suivants :

- le montant prévu par la convention collec-tive de branche, l’accord professionnel ouinterprofessionnel ou, à défaut, par la loi ;

- le double de la rémunération annuellebrute perçue par le salarié au cours del’année civile précédant celle de larupture de son contrat de travail ;

- la moitié du montant total des indem-nités perçues.

Toutefois, la part exonérée ne peutexcéder la moitié du seuil d’impositionde l’ISF, soit 2,35 millions de francs(2).Prenons l’exemple d’un salarié dont larémunération annuelle brute de l’annéecivile précédente s’établit à 600 000francs, et qui a perçu une indemnité égaleà 1 600 000 francs, dont 400 000 francscorrespondant à l’indemnité convention-nelle. En application des dispositionsnouvelles, l’indemnité sera exonérée àhauteur de 1 200 000 francs et imposablepour le surplus, soit 400 000 francs.En définitive, le nouveau régime instaureune plus grande égalité entre les contri-buables en édictant des règles précises,qui ne sont susceptibles d’aucune inter-prétation. Ces règles éviteront, à n’en pasdouter, de nombreux contentieux.Ces nouvelles dispositions enlèventtoutefois au juge tout pouvoir modéra-teur ou correcteur quant à l’impositiondes indemnités de licenciement. Cepouvoir souverain du juge permettait,en effet, d’exonérer de l’impôt sur lerevenu une part importante ou même latotalité de l’indemnité dans tous les casoù le licenciement entraînait des consé-quences particulièrement graves,notamment pour les salariés dont lespossibilités de reclassement étaientfaibles. Il n’en demeure pas moins queles tribunaux préciseront leur positiondans le futur, notamment au regard dutraitement des indemnités à caractèrede dommages et intérêts.

Eric Boulanger

De la subjectivité à l’objectivité

n° 189 décembre 2000 47

Des contribuables debonne foi pouvaient dèslors mal évaluer la part deleur indemnisationexonérée

La loi fixe un montantmaximal pour la partexonérée

2 - Le seuil d’imposition de l’ISFest actuellement fixé à 4,7 mil-lions de francs


Eric Boulanger

BIBLIOGRAPHIELa Gestion fiscale de l’entreprise1999, Éditions Tissot 1999.

Référencement

Les bonscomptes...

Humeur


Comment perdre de l’argent en voulant en gagner ? Facile, voici une petitehistoire édifiante ! Toute similitude avec une situation existante ou ayantexisté serait purement fortuite…

Directeur des programmes

de Bouhot & Le Gendre.

Rédacteur en Chef de

L’Informatique

Professionnelle.

Il intervient depuis plus de

vingt ans dans le domaine

des systèmes d’information.

Jean-Marc Berlioux

Réduisons nos coûts, çaaméliorera nos marges. Leraisonnement est impa-rable. A moins que…

Une grande société met en place unréférencement de ses fournisseurs.Objectif : réduire le nombre de ceux-ci. En effet, avec le stockage desinformations, la tenue à jour du fichieret le traitement des factures, la gestiond’un fournisseur coûte de l’argent.D’où l’idée lumineuse : moins defournisseurs égale moins de frais degestion, donc plus de marges.

Voyons cela d’un peu plus près ! Leclient a besoin d’une prestation.

Supposons qu’il ait deux offres,l’une d’une SSII référencée etl’autre d’une non-référencée.Comme il est pressé et qu’il veutappliquer la politique “corporate”,il va choisir le référencé, même sicelui-ci est plus cher. Et comme leréférencé le sait, il sera évidemmenten situation de force pour négocier.

Autre situation, le client ne trouvede solution acceptable que chez unnon-référencé. La technique estalors toute simple (elle est parfoissuggérée par les acheteurs eux-mêmes). Il suffit pour l’entreprisenon référencée d’aller voir unesociété référencée qui servira d’in-

termédiaire. Le mark-up, c’est-à-dire la dîme prélevée au passage,varie (entre une dizaine de pourcent et cent pour cent du prix initial,paraît-il). Et elle se répercute, c’estbien normal, sur le prix de vente auclient.

Essayez de faire une simulation surla prestation de quelques mois-homme d’un consultant de bonniveau. Juste pour voir si, parhasard, le surcoût ne dépasseraitpas largement l’économie !

Jean-Marc Berlioux

En bref...

A suivre...

n°189 décembre 2000 49

Les e-mails sont-ils descorrespondances privées ?Un e-mail émis depuis un posteprofessionnel constitue-t-il unecorrespondance privée ? Le débatfait rage depuis un moment. Or unjugement important est intervenu le2 novembre 2000. Le tribunal cor-rectionnel de Paris a condamnétrois cadres de l’Ecole Supérieurede Physique Chimie Industrielle deParis. Ils avaient pris connaissancedes e-mails d’un étudiant à soninsu. Un commentaire de ce juge-ment paraîtra dans notre prochainnuméro.

Portage de .NET sur LinuxCorel a déposé auprès de la SEC(U.S. Securities and ExchangeCommission) des documents pré-voyant la possibilité pourMicrosoft de lui confier le portagepartiel ou total de la plate-forme.NET de Microsoft sur Linux.L’ intention apparente de Microsoftde porter sa future plate-forme.NET sur Linux n’est pas surpre-nante, compte tenu des efforts faitpour positionner .NET comme unesolution équivalente à Java. Leportage de .NET sur Linux renfor-cera également les efforts deMicrosoft visant à soumettre deséléments de .NET (à savoir, laCommon Language Infrastructureet le langage de programmation

C#) à l’organisme de normalisationEuropean Computer ManufacturersAssociation (ECMA).Les méthodes traditionnelles envigueur au sein de l’ECMA exigentgénéralement au moins deux misesen œuvre indépendantes pour quel’adoption d’une technologie soitenvisagée. Lors des réunions desgroupes de travail de l’ECMA, lesreprésentants de Microsoft ont déjàindiqué que la société travaille surdeux mises en œuvre, dont l’uneest basée sur les plates-formes non-Wintel.

En fait, l’accord donne à Microsoftle droit de faire payer une rede-vance (ou tout autre mode derémunération) aux personnes quisouhaitent distribuer des copies de.NET pour Linux. Les entreprisesqui prévoient de tirer parti de laplate-forme .NET doivent voir cetaccord comme une étape positive,mais seulement comme une pre-mière étape, dans la longue marchevisant à positionner .NET commeun concurrent sérieux de Java.

USA : doublementdes visas high-techLe Sénat américain a décidé dedoubler quasiment le nombre devisas H1-B temporaires réservésaux travailleurs étrangers haute-ment qualifiés, en le faisant passerde 115 000 en 2000 à 195 000 pourchacune des trois années qui sui-vront. Les visas H1-B, qui sontdemandés par les employeurs, sontvalables trois ans et peuvent êtrerenouvelés pour trois ans. Cettemesure a été votée à la quasi-una-nimité au Sénat par quatre-vingt-seize voix contre une. Elle aensuite été examinée par laChambre des représentants, qui l’aadoptée. En principe, le présidentBill Clinton devrait approuver leprojet de loi, dernier passageobligé avant que cette mesuredevienne une loi.Même si l’octroi de visas H1-Bsupplémentaires est indubitable-ment une grande victoire pour leslobbyistes de la Silicon Valley quiont fait de fortes pressions pourfaire passer cette mesure, il nerésout pas la grave pénurie de com-pétences informatiques. La pénuriede compétences ne se réduit pas àune pénurie de personnes et cetteaugmentation du nombre de tra-vailleurs étrangers disponibles,quoique non négligeable, n’est pasune réponse au problème.

La pénurie decompétences ne se

réduit pas à unepénurie de personnes

En Bref...


Aux Etats-Unis, le nombre de per-sonnes employées dans l’informa-tique excède 1,5 million. Etantdonné l’importance de cette maind’œuvre, la plupart des entreprisesne sentira pas l’ impact de ces80 000 travailleurs supplémen-taires. Les plus touchées serontcelles qu’on appelle les bodyshops, c’est-à-dire les sociétés spé-cialisées dans la fourniture de per-sonnel informatique pour les pro-jets, et les sociétés high-tech, quisont les plus gros utilisateurs devisas H1-B. Même avec l’accrois-sement du nombre de visas, lademande en matière de personnelinformatique restera supérieure de20 % à l’offre jusqu’en 2003.

Oracle9i : Marketinget poudre aux yeuxÀ grand renfort de trompettes,Oracle a lancé Oracle9i, dernièreversion de son système de gestionde base de données (SGBD) –Oracle9i Database – et son serveurd’applications – Oracle9i Appli-cation Server. Oracle9i ApplicationServer est disponible immédiate-ment ; Oracle9i Database sera missur le marché à la fin du premiersemestre 2001.La vision exprimée par Oracleconcernant Oracle9i consiste à pro-poser un ensemble intégré de tech-nologies (Oracle9i Database etOracle9i Application Server)comme étant “les deux seulespièces” nécessaires pour une plate-forme informatique internet offrantun haut niveau d’évolutivité, dedisponibilité et de capacité à êtrepilotée. Cependant, Oracle9i n’estpas “magique”, comme l’a pro-clamé le directeur générald’Oracle. C’est une amélioration

logique du SGBD de la société etun solide lien marketing avec sonserveur d’applications remanié.Les solutions d’Oracle concernantles fonctionnalités d’autoparamé-trage, les améliorations destinéesaux OEM et la technologie d’envoide fichiers journaux et de mise enveille (Data Guard) peuvent traitercertains des problèmes concernantla capacité à être piloté et la dispo-nibilité qui ont longtemps gêné lesadministrateurs de bases de don-nées Oracle, ce qui a poussénombre d’entreprises vers les solu-tions de fournisseurs de logiciels

indépendants. Les entreprises quimettent en œuvre des infrastruc-tures de datawarehouse obtiendrontenfin en partie l’intégration pro-mise depuis si longtemps des cubesmultidimensionnels (basés surOracle Express), de la transforma-tion des extractions, du chargement(partiel) et du datamining.Les améliorations de la fonctioncluster d’Oracle (Real ApplicationClusters) visent également à offrirune plus grande capacité à monteren charge “scalabilité” pour faireface à un nombre important detransactions, ce qui renforce l’inté-rêt des clusters pour des systèmestransactionnels. En fait, les ana-lystes Gartner estiment qu’à courtterme, la plupart des entreprisescontinueront de faire évoluer leurssystèmes vers des serveurs multi-traitement symétriques mono-

image (single-image symmetricmultiprocessing) plus importants.Les analystes Gartner recomman-dent la prudence en ce quiconcerne Oracle9i. Sur le papier, labase de données Oracle9i sembleêtre une amélioration solide duSGBD Oracle8i, susceptible derégler un grand nombre des pro-blèmes pour lesquels les clientsOracle réclament des solutionsdepuis longtemps. Cependant, lesentreprises doivent traiter lesannonces d’Oracle concernant lesperformances de la base de don-nées Oracle9i comme n’importequelle annonce concernant un pro-duit non encore diffusé. Les entre-prises doivent prendre des déci-sions d’achat basées sur les pro-duits mis sur le marché et sur lesréférences de production en envi-ronnement réel. Les analystesGartner pensent que la plupart desclients Oracle envisageront d’utili-ser Oracle9i Application Serverpour renforcer les applicationsinternet et intranet multi-niveaux.

Batteries Dell : au feu !Dell Computer a annoncé le rappelvolontaire d’environ 27 000 batteriesutilisées dans les portables DellLatitude. Lorsque certaines condi-tions sont réunies, ces batteries peu-vent créer un court-circuit et s’en-flammer. Les clients Dell qui ontacheté les portables incriminés doiventcontacter leur gestionnaire de compteDell, télécharger un utilitaire de dia-gnostic de batteries (http://www.sup-port.dell.com) ou prendre les mesuressuggérées dans le bulletin d’informa-tions de Dell relatif au rappel(http://support.dell.com/battery/press.asp) pour déterminer si leurs batteriesont besoin d’être remplacées.

Les analystes Gartnerrecommandent la

prudence en ce quiconcerne Oracle9i

En bref...

n°189 décembre 2000 51

Internet et grandesoreilles : La Chine voussalue bien !Le ministre de l’Information chi-nois a publié un certain nombre denouvelles réglementations concer-nant les fournisseurs de contenuinternet. Ces nouvelles réglementa-tions obligent les prestataires deservices internet et de contenu àgarder une trace de tous les conte-nus publiés sur leurs sites et de tousles utilisateurs qui se connectent àleurs serveurs pendant soixantejours, et à fournir ces informationsà la police sur demande.Même si ces nouvelles réglementa-tions ne sont pas très différentes decelles qui avaient déjà été publiées,elles soulignent la détermination dugouvernement chinois à contrôler ou,pour le moins, à surveiller le contenu

de l’internet. En dehors de toutesconsidérations politiques, de l’inter-net en Chine n’attirera pas d’inves-tissements internationaux importants

avec la législation en vigueur. L’effetdissuasif que la réglementation dugouvernement chinois a eu sur ledéveloppement des activités interneta été particulièrement visible lorsqueles enchères lancées par le gouverne-ment pour la vente des sociétés inter-net, des noms de domaines et dessites web ont échoué lamentable-ment le 29 septembre 2000.

En 1999, la Chine a sorti ou ren-forcé des dizaines de décrets rela-tifs au contrôle du contenu dessites internet, même si ces décretsconcernaient essentiellement lessociétés dot-com nationales ou lesnouvelles sociétés. Puis, le 27 jan-vier 2000, le gouvernement chinoisa annoncé que toutes les sociétés,étrangères ou nationales, devaientenregistrer auprès des pouvoirspublics tous les logiciels qui utili-sent le chiffrement, ainsi que lesinformations relatives à chaque uti-lisateur de ces logiciels. La législa-tion sur le chiffrement a imposédes charges d’exploitation exorbi-tantes, voire impossibles à suppor-ter, aux entreprises souhaitant fairedes affaires en Chine.

Internet en Chinen’attirera pas

d’investissementsinternationaux

importants


B U L L E T I N D E C O M M A N D E

Un nouveau rapportRé-ingénierie du Développement d’Applications(RAD, CMM, UML)Conçu et rédigé par Jean-Pierre Vickoff.Un rapport de plus de 200 pages, intégrant des check-lists et denombreuses informations pratiques.

Au sommaire de ce nouveau rapport :• Méthode de conduite de projet RAD et phasage,• Profil et constitution de l’équipe projet, • Principes de modélisation (y compris UML),• Intérêt et logique d’un positionnement dans l’échelle CMM.

Merci de m’envoyer votre dernier rapport

“Ré-ingénierie du Développementd’Applications” au prix exceptionnel de

lancement : 3190 FHT (au lieu de 3690 FHT)

(TVA 5,5%) + 38 F de port (TVA 19,6%) ;

hors France, 3390 FHT+73 F de port.

Nom : Prénom :Société : Fonction :Adresse :

Code postal : Localité :Tél. : Fax :

Je joins mon règlement par chèque à l'ordre de GartnerGroup France et je recevrai une facture justificative.

Je règlerai à réception de facture.Conformément à la législation en vigueur, vous disposez d'un droit d'accès et de rectification pour toute information vous concernant.

Un rapport

Bulletin à retourner ou à faxer à : Sylvie GarofaloImmeuble Défense Bergères - 345 avenue Georges Clemenceau - TSA 4000292882 NANTERRE cedex 09 - Tél. : 01 41 35 15 15 - Fax : 01 41 35 15 10

Ré-ingénierie

du Développement

d’Applications

(RAD, CMM, UML)

U n e d i v i s i o n d e G a r t n e r G r o u p

Bouhot & Le Gendre

Produits et Services

ip 189 déc 2000 - yves constantinidis consultant · n° 189 décembre 2000 3 fini, périmé,...

Documents