Pourquoi et comment déployer une Gouvernance des contenus

Transcription

IT
LA RÉFÉRENCE TECHNIQUE ON-LINE DES PROFESSIONNELS DE L'INFORMATIQUE
Pourquoi et comment déployer
une Gouvernance des contenus ?
Gouvernance des Architectures SOA :
entre contrôle et flexibilité
La conduite du changement
au cœur de la réussite des projets
Mesurer et gérer la dette technique
des portefeuilles applicatifs
Bimestriel - mars/avril 2011
Les enjeux juridiques
du cloud computing
n°90
édito
Les réseaux sociaux au secours des entreprises ?
Les entreprises peineraient à attirer les talents de la
« génération Y », qui auraient besoin de leurs réseaux
sociaux… Affirmations généralement formulées
par des papy-boomers ! L’informatique n‘a pas
attendu les années 90 ou 2000 pour être la réalité
quotidienne de nombreux adolescents.
Cette dénommée « génération Y » est déjà au travail,
et justement dans ces entreprises. De plus, ces « jeunes » cherchent surtout
un job intéressant et rémunérateur (ou l’inverse). Enfin, ils se plaignent
plus du manque d’encadrement que de l’absence de gadgets ou de
technologies… ou de voitures de fonction ! Une organisation se doit de
proposer un cadre dans lequel s’expriment talent et créativité, et non pas
un terrain arboré ou chacun peut jouer avec ses règles à son jeu favori.
Réseaux sociaux ? Cette notion fourre-tout, très discutée par les papyboomers enthousiastes du marketing, se contentait de facebook et autres
linkedIn. On y a ajouté les blogs, un peu trop délaissés. À présent, ils
incarneraient la solution collaborative « indispensable »…
Qualifié ce type d’outil (peut-on parler de technique ou technologie ?...)
de « B2B » permet de « faire payer l’entreprise » et de dépasser le modèle
gratuit/publicité. Ainsi, nos évangélistes 2.0 deviennent consultants,
vantant les mérites de ces solutions.
Peut-être serait-il temps de ne pas confondre popularité grand public et
nécessité de l’entreprise. Il ne suffit pas d’ouvrir une crèche pour recruter
les meilleurs jeunes talents féminins… Ce qui, au passage, ne remet
nullement en cause la nécessité des crèches.
José Diz
Rédacteur en Chef
IT
LA RÉFÉRENCE TECHNIQUE ON-LINE DES PROFESSIONNELS DE L'INFORMATIQUE
Editeur
Press & Communication France
Une filiale du groupe CAST
3, rue Marcel Allégot
92190 Meudon - FRANCE
Tél. : 01 46 90 21 21
Fax. : 01 46 90 21 20
http://www.it-expertise.com
Email : [email protected]
Rédacteur en chef
José Diz
Directeur de publication
Aurélie Magniez
Abonnements/Publicité
Conception Graphique
Nicolas Herlem
[email protected]/
Parution
IT-expert - (ISSN 1961-9855) est un journal
édité 6 fois par an, par P&C France, sarl
de presse au capital de 60 976,61 €.
Avertissement
Tous droits réservés. Toute reproduction
intégrale ou partielle des pages publiées
dans la présente publication sans l’autorisation écrite de l’éditeur est interdite, sauf
dans les cas prévus par les articles 40 et
41 de la loi du 11 mars 1957. © 1996 P&C
France. Toutes les marques citées sont des
marques déposées.
Les vues et opinions présentées dans cette
publication sont exprimées par les auteurs
à titre personnel et sont sous leur entière
et unique responsabilité. Toute opinion,
conseil, autre renseignement ou contenu
exprimés n’engagent pas la responsabilité
de Press & Communication.
Abonnements
01 46 90 21 21
Vous pouvez vous abonner gratuitement
sur http://www.it-expertise.com/
4
IT-expert n°90 - mars/avril 2011
Sommaire
6
Dossier
Pourquoi et comment déployer une Gouvernance des contenus ?
GED, ECM, collaboration… Au-delà des technologies cohabitant dans ses silos, une
gouvernance des contenus s’impose, avec des rôles et des processus pour gérer les
cycles de vie de l’information, leurs modes de diffusion, etc. Ce dossier propose une
démarche claire pour valoriser au mieux ce capital.
12
Technique
Gouvernance des Architectures SOA : entre contrôle et flexibilité
Incontournable pour déployer cette architecture, la gouvernance SOA est spécifique à
chaque organisation. Néanmoins, des aspects communs doivent être pris en compte.
L’auteur analyse les axes stratégiques et opérationnels, détaille approches et outils et
explique en quoi ce projet concerne le pilotage de l’entreprise.
20
Actualités Internationales
26
Comment ça marche ?
Les informations marquantes d’éditeurs, de marchés, d’organisme
de standardisation, de débats en cours et de tendances
La conduite du changement au cœur de la réussite des projets
Malgré une prise de conscience par tous de la nécessité d’accompagner le changement,
peu de personnes se portent volontaires, y compris la DSI. Ce dossier montre pourquoi
et comment elle doit s’impliquer tout au long du projet pour lui éviter de rejoindre les
projets avortés faute d’accompagnement…
32
Quoi de neuf docteur ?
Mesurer et gérer la dette technique des portefeuilles applicatifs
Pendant trois ans, l’éditeur CAST a étudié 288 applications (108 millions de lignes de
code, 3,4 millions de points de fonction) soumises par 75 organisations pour analyser
leur qualité structurelle. En se basant sur ces travaux, l’auteur en dégage les principaux
enseignements. Très instructif !
42
Livres
Sharepoint Workspace 2010 de Fabrice Barbin et Les réseaux sociaux expliqués
à mon boss du collectif dirigé par Yann Gourvennec et Hervé Kabla.
44
Rubrique à brac
Les enjeux juridiques du cloud computing
Après une définition des concepts du cloud, l’auteure montre les avantages, bénéfices
et risques de ces offres. Comparant cloud et externalisation, elle relève les faiblesses
des contrats proposés par les fournisseurs de services cloud. Une dimension sensible
où les conseils sont les bienvenus !
5
Pourquoi & Comment
déployer une Gouvernance
des contenus ?
A
u cours de ces dernières années, les organisations ont fait des efforts conséquents pour gérer au mieux les différents
contenus qu’elles produisent, achètent ou utilisent quotidiennement. Des efforts généralement concrétisés par la mise en
œuvre et l’utilisation de solutions toujours plus performantes de gestion des contenus faisant émerger une nouvelle discipline :
l’Enterprise Content Management ou ECM (Document imaging + Document management ou DM + Web content management
ou WCM + Digital asset management ou DAM + Records management ou RM + Content integration ou ECI).
Et ces nouvelles solutions d’ECM sont venues s’ajouter à la liste déjà longue des systèmes existants dans les organisations
qui gèrent, plus ou moins bien, des contenus : serveurs de messagerie électronique, disques partagés, systèmes de GED,
plateformes de travail collaboratif…
6
Dossier
Aujourd’hui, la nécessité de fournir des contenus de qualité aux collaborateurs malgré la multitude des
systèmes, oblige les organisations à s’orienter de plus en plus vers une réelle gouvernance des contenus.
De la gestion à la gouvernance des contenus
Généralement le terme de gestion des contenus fait référence aux processus et aux technologies
supportant la création, la validation, la publication et l’archivage des contenus de l’entreprise en
s’inscrivant dans une démarche collaborative.
Mais cette gestion des contenus, intimement liée aux solutions d’ECM, reste bien souvent « localisée ».
Dans la plupart des cas, les organisations ont mis en place ces solutions pour répondre à des besoins
spécifiques issus de directions ou de départements particuliers : mise à disposition auprès des
collaborateurs du service comptable des images de factures, gestion de contrats pour le département
juridique, système de publication web pour la direction de la communication, espaces de travail
collaboratif pour la gestion de projet, messagerie électronique pour l’ensemble des collaborateurs, etc.
Malheureusement, l’approche transversale par processus métiers, entamée par de très nombreuses
organisations pour s’adapter à leur marché, demande de plus en plus aux collaborateurs d’obtenir,
d’agréger et d’utiliser des contenus provenant de différentes sources ou systèmes d’information connexes.
Trop peu d’organisations donnent à leur gestion des contenus une dimension globale et transversale à
laquelle sont associées des notions d’organisation, de standards et de stratégie d’entreprise ; notions
au cœur de la gouvernance des contenus.
Ainsi, la gestion des contenus ne traite que très rarement des questions relatives au cycle de vie des
contenus pouvant « transiter » par différents systèmes aux logiques différentes et spécifiques : que faire
des documents de travail présents sur une plateforme de travail collaboratif une fois ceux-ci validés ?
Faut-il les capitaliser et les intégrer aux référentiels de l'entreprise supportés par une autre plate-forme ?
Si oui, comment le faire et qui en est responsable ? Qui est responsable des règles de publication ?
Faut-il archiver ces documents ? Si oui, qui en est responsable et qui définit les règles de rétention ?...
Autant de questions à forts enjeux pour les organisations auxquelles la gouvernance doit apporter des
réponses claires et précises.
Un dispositif organisationnel indispensable
La gouvernance des contenus a pour objectif d’assurer une qualité optimale de l’ensemble des
contenus de l’entreprise, quelle que soit la plate-forme (portail, intranet, GED, WCMS…), en rationalisant
et rendant efficiente la gestion du cycle de vie complet des contenus.
Par contenu de qualité, il faut comprendre contenu valide, parfaitement et systématiquement défini à
l'aide de métadonnées (générales, métiers et éventuellement contextuelles) et possédant des droits
d'accès clairement définis et surtout effectifs.
Pour y parvenir, il est nécessaire de mettre en place un dispositif organisationnel facilitant l’établissement
des règles et des standards pour l’ensemble des contenus de l’entreprise en plaçant l’individu au cœur
des processus de gestion des contenus.
Ce dispositif organisationnel, composé de différentes « instances », doit répondre à un certain nombre
d’exigences pour être réellement opérationnel et porteur de valeur ajoutée dont voici les principales :
• les différentes parties prenantes (utilisateurs, producteurs de contenus, responsables métiers,
professionnels de l’information, informaticiens, etc.) doivent être représentées dans toutes les
« instances » du dispositif ;
• chaque « instance » correspond à un périmètre d’action bien délimité. On pourra par exemple
séparer l’instance chargée de définir les grands principes fonctionnels de gestion des contenus
de celle chargée de définir les éléments techniques (métadonnées, règles de nommages, plans de
classement, etc.) à mettre en œuvre pour les supporter ;
• le nombre limité d’instances doit être représentatif de l’ampleur de la gestion des contenus au sein
de l’entreprise ;
7
Exemple de dispositif organisationnel
Voici un exemple de dispositif organisationnel mis en place dans le cadre d’une gouvernance des contenus dans une collectivité
territoriale.
Le Comité de Gestion des Contenus a pour mission de piloter
la gestion des contenus et a pour principales activités :
• la définition des grands principes de gestion des contenus ;
• le suivi et l’amélioration de l’efficacité de la gestion des
contenus ;
• la validation des éléments techniques définis pour les nouveaux
systèmes de gestion des contenus ;
• l’arbitrage à la demande du Groupe Technique.
Le Comité de Gestion des Contenus est composé du Directeur
Général des Services, des principaux responsables des services
utilisateurs des systèmes de gestion des contenus ainsi que du
service informatique et du représentant du Groupe Technique.
Le Comité se réunit à une fréquence prédéfinie.
Le Groupe Technique a pour mission de définir et gérer la
mise en œuvre technique de la gestion des contenus et pour
principales activités :
• la définition et la gestion des différents éléments techniques
(métadonnées, architecture de l’information, workflows…)
permettant la mise en œuvre opérationnelle de la gestion
des contenus ;
• le suivi de la bonne réalisation du tableau de bord de la gestion
des contenus ;
• la prise en compte des demandes d’évolutions remontant
des relais.
Le Groupe Technique est composé d’un informaticien, d’un professionnel de l’information et des relais. Il peut faire intervenir
d’autres parties prenantes de la gestion des contenus en fonction des problématiques traitées. Il se réunit sur une base régulière.
Les relais ont pour mission de faciliter la mise en application et la bonne utilisation des règles de gestion des contenus par les
utilisateurs et ont pour principales activités :
• le suivi de la cohérence des différents systèmes de gestion de contenus vis-à-vis des principes et des règles définis par le
Comité de Gestion des Contenus ;
• la centralisation des retours utilisateurs sur la gestion des contenus et la transmission au Groupe Technique et/ou au Comité
de Gestion des Contenus
5 étapes vers la gouvernance
Une fois mis en place, le dispositif organisationnel devra s’attacher à faciliter la mise en œuvre de la
gouvernance des contenus qui se déroule en 5 étapes.
1. Définir des objectifs
Il s’agit de définir les objectifs à atteindre en terme de gestion des contenus, notamment en ce qui
concerne la qualité et la réutilisation des contenus.
2. Établir des règles et des standards
Il s’agit de traduire les objectifs préalablement définis en principes, règles et standards qui seront
utilisés quotidiennement par les différents acteurs impliqués et impactés par la gestion des contenus.
On peut par exemple citer :
8
Dossier
•
•
•
•
•
•
•
•
les métadonnées générales partagées par tous les systèmes de gestion des contenus ;
les métadonnées spécifiques à un système, une thématique ou un métier ;
les règles de nommages des contenus ;
le cycle de vie standard des contenus en fonction de leur nature ;
le cycle de vie des espaces collaboratifs ayant une durée de vie limitée ;
les consignes pour l’affectation de mots clés en vue de qualifier un contenu ;
les éléments à définir systématiquement lors de la création d’un nouvel espace collaboratif ;
…
Cycle de vie standard des documents
Exemple de cycle de vie d’un espace collaboratif
Il s’agit également d’identifier les collaborateurs responsables de ces règles et standards, de leurs
élaboration, utilisation et maintien.
Exemple d’éléments à définir systématiquement à la création d’un nouvel espace collaboratif
Objectifs
Vocation et buts à atteindre par la mise en œuvre et l’utilisation de l’espace collaboratif.
Audiences
Les audiences sont les différents groupes d’utilisateurs de l’espace collaboratif qui « consomment »
des contenus.
Contenus
Les différents types de contenus qu’il est nécessaire d’identifier et de définir précisément de manière
à en faciliter la gestion.
Contributeurs
Les personnes susceptibles de créer, valider ou enrichir des contenus.
Sources externes
Autres espaces collaboratifs ou autres applications du système d’information, susceptibles de fournir
des contenus à l’espace collaboratif.
Structures d’accès
Types d’organisation et/ou de structuration des contenus : plan de classement, mots clés (folksonomies),
références croisées…
Cycles de vie
Cycles de vie des contenus de l’espace collaboratif et de l’espace collaboratif lui-même.
9
3. Mettre en place les outils permettant de supporter ces règles et standards
Pour mettre en œuvre et supporter opérationnellement ces règles et standards, il est nécessaire de
fournir aux collaborateurs concernés les outils indispensables :
• référentiel commun de métadonnées ;
• système(s) de classement et d’organisation des contenus : taxonomie et/ou éventuellement thésaurus
ou ontologies ;
• une ou plusieurs plateformes d’ECM.
Si dans l’idéal une seule plateforme d’ECM est souhaitable, sur le terrain 2 ou 3 plateformes peuvent
coexister… dans le meilleur des cas !
4. Impliquer et responsabiliser les parties prenantes
Il s’avère impossible d’obtenir des contenus de qualité sans assigner des responsabilités et de rôles
vis-à-vis des contenus à des collaborateurs clairement identifiés, et sans élaborer, diffuser et appliquer
les règles précises associées à ces rôles.
Il s’agit notamment d’identifier qui est responsable d’un contenu et qui en est l’auteur. Bien entendu,
il convient de mettre en œuvre les mécanismes permettant de s’assurer de l’implication effective
des acteurs par exemple en mettant en place des relais chargés de faire le lien entre les instances du
dispositif organisationnel de la gouvernance des contenus et le terrain.
Définition et modification des indicateurs du tableau de bord
Comité de Gestion des Contenus
Responsables des espaces collaboratifs /
Gestionnaires documentaires
Réalisation mensuelle du tableau de bord
Groupe Technique
Exploitation et diffusion du tableau de bord
Comité de Gestion des Contenus
5. Maintenir le cadre
Les contenus, les besoins ainsi que les objectifs qui leur sont
associés évoluent au cours du temps. Il est donc nécessaire de
s’assurer que les règles et les standards existants correspondent
toujours à ces besoins et objectifs.
Pour ce faire, il est indispensable de mettre en place un tableau de
bord, de manière à avoir une vision claire et partagée de l’activité
de gestion des contenus et disposer d’éléments objectifs pour
s’assurer du bon fonctionnement de la gestion des contenus et
prendre les décisions qui s’imposent en connaissance de cause.
Exemple de réalisation d’un tableau de bord
Valoriser le capital de l’information
Une fois mise en place, la gouvernance des contenus permet à l’entreprise d’améliorer sa productivité et
de valoriser ses contenus, notamment au travers d’un accès à l’information beaucoup plus performant.
Une information réutilisée est une information qui gagne de la valeur. Valeur d’autant plus importante
que la qualité de l’information est grande et garantie ! n
Gilles Balmisse,
Directeur Associé
KnowledgeConsult, cabinet de conseil spécialisé dans la mise en oeuvre de dispositifs de gestion des connaissances, travail
collaboratif et veille.
Site web : www.knowledgeconsult.com/fr/
10
IDC, filiale du leader mondial du conseil, et des études dans les technologies de l’information.
Comment gagner en agilité face aux nouveaux impératifs métiers ?
IDC France
vous donne rendez-vous
jeudi 9 juin 2011 (9h – 15h30) à Paris
à la conférence IDC
« Décisionnel et Data
Management »
Au programme :
• Vision et analyse IDC : le marché du décisionnel, évolution des besoins
et des usages en France et en Europe (2011 – 2014)
• Ledécisionneldenouvellegénération : gagner en intelligence grâce à
une meilleure prise en compte du contexte des informations
• Des chantiers de plus en plus critiquesautourdesdonnées
• Projets décisionnels * : spécificités et facteurs de succès
*avec le retour d’expérience de Marie-Claude Poelman,
DSI de Nature & Découvertes
Pour participer à la conférence IDC Décisionnel le 9 juin 2011,
consultez le programme détaillé et inscrivez-vous gratuitement sur :
http://www.idc.com/france/BI2011
Code invitation : ITX
Contact : Valérie Rolland
[email protected]
tel : 01.56.26.26.85
Cette conférence gratuite est uniquement réservée aux entreprises utilisatrices.
Conférence organisée par
Gouvernance des Architectures
SOA : entre contrôle et flexibilité
L
es Architectures Orientées Services (SOA) répondent à un modèle d'interaction applicative particulier, mettant en œuvre
des composants logiciels simples et autonomes appelés « services ». Cette approche permet de décomposer l’expression
d’un besoin métier en un ensemble de fonctions basiques au niveau du système d’information. Elle invite également à
cesser de construire la vie de l'entreprise autour d'applications rigides et monolithiques, traditionnellement réparties en silos
fonctionnels. À contrario, elle favorise une architecture logicielle souple et modulaire, organisée en « services ». Ces derniers
sont partageables entre les différents domaines de l’entreprise, et donc réutilisables dans le cadre de l'implémentation de
processus métiers transverses.
12
Technique
Adopter une démarche SOA n’est pas trivial. Afin d'adresser les
nombreuses problématiques inhérentes à ce type d’architecture,
il est nécessaire de spécifier et de mettre en application un
dispositif de contrôle et de surveillance adapté, à même
d’encadrer et de limiter les nombreux impacts induits par
l’approche SOA.
Toutefois, encore faut-il veiller à garantir les bénéfices liés à
la SOA comme le premier d’entre eux : l’amélioration de la
compétitivité de l’entreprise en favorisant l'alignement entre
le métier et l'IT, et en accélérant le « Time to Market ». Et cela
nécessite plus que jamais une vigilance accrue, car il s’agit
de ne pas rigidifier le système plus que de raison. Un résultat
totalement contraire à la philosophie même de SOA, sensé
procurer souplesse et flexibilité au SI.
Alors, faut-il contrôler malgré tout ? Assurément ! Mais en veillant
à ne pas entraver l'agilité de l'architecture du SI, ni celle de son
organisation. Entre contrôle et flexibilité, l’entreprise doit trouver
son point d’équilibre.
Gouvernance SOA : « Buzz-Word », ou nécessité ?
Aujourd'hui, beaucoup d'entreprises adoptent (ou ont adopté)
une démarche SOA avec pour objectif premier de gagner en
agilité. Objectif : supporter au mieux et au plus vite l’expression
de nouveaux besoins métiers. En effet, la mise à disposition
rapide sur le marché et à destination des clients de nouveaux
produits et de services à forte valeur ajoutée est devenue le
nerf de la guerre.
Avec un peu de recul, on constate toutefois que les nombreuses
initiatives engagées n'ont pas toutes été couronnées du même
succès. Ainsi, s'il est en général assez aisé de « toucher du
doigt » les bénéfices tant attendus de la SOA lors de l'élaboration
d'un projet pilote (modularité de l’architecture, réutilisation de
composants, rationalisation du SI...), l'exercice s'avère bien plus
complexe et périlleux lorsqu'il s'agit de déployer et mettre en
œuvre des projets typés « SOA » à grande échelle, traversant les
différents silos fonctionnels et organisationnels de l'entreprise.
Dès lors, les nouveaux défis introduits par les architectures
SOA sont bien plus nombreux, et particulièrement difficiles à
appréhender : quelle stratégie de financement mettre en place
pour des services transverses et partagés, destinés à être utilisés
par différentes entités de l’entreprise ? Qui doit en assumer
la propriété et, par conséquent, la responsabilité ? Comment
prioriser le développement des services au regard du portefeuille
de projets et de leurs roadmaps ? Comment garantir la qualité
de leur développement, ainsi que leur performance et leur bon
fonctionnement à l’exécution ?
Il ne s’agit là que de quelques exemples, la liste exhaustive des
problématiques s’avérant fort longue.
Le flex-contrôle : enjeu fort de la Gouvernance SOA
Pour apporter une réponse à ces problématiques spécifiques
aux architectures de services, il est primordial de se doter
d'un dispositif permettant de cadrer la démarche globale. La
Gouvernance SOA est une discipline incontournable visant à
accompagner et à sécuriser le déploiement d'une SOA de bout
en bout, via l’identification, la spécification et la mise en œuvre
de processus, de bonnes pratiques et de principes directeurs
spécifiques aux architectures de services.
La Gouvernance SOA constitue un levier majeur de la rationalisation du SI :
• Optimisation du nombre de technologies employées,
• Réduction des redondances (au niveau des données, des
fonctions, des échanges),
• Convergence des SI de différentes entités, branches ou filiales,
standardisation (Objets Pivots, patterns d’intégration)…
Elle favorise également la réduction des coûts du département
informatique :
• Industrialisation des projets,
• Promotion de principes de réutilisation,
• Limitation des impacts d'une modification…
En outre, elle contribue à l’amélioration de la disponibilité et de la
fiabilité des applications, et offre une nouvelle agilité à l'entreprise
en permettant de réduire les délais nécessaires entre l'expression
des besoins par les métiers, et leur mise en œuvre au sein du SI.
Une mise en œuvre concrète et toujours spécifique
La Gouvernance SOA, concept sibyllin s’il en est, prend corps
et s’applique concrètement via l’identification, la formalisation,
la mise en œuvre et la supervision d’un régime (ou programme)
de Gouvernance. Pour être réellement efficace, ce dispositif
se doit d’être contextuel et adapté à l’entreprise qui initie la
démarche SOA, en tenant compte de ses processus existants
et de son organisation interne.
Dans la majorité des cas, ce nouveau régime de gouvernance
ne se construit pas à partir de la page blanche.
En effet, afin d’éviter certaines zones de recouvrements avec
des dispositifs existants et déjà en place, la gouvernance SOA
doit être appréhendée non pas comme une nouvelle discipline,
mais comme une extension et une particularisation de celles
déjà bien connues que sont la Gouvernance Informatique (aussi
appelée Gouvernance IT – avec certains frameworks connus
tels que Cobit), et l’Architecture d’Entreprise (EA – avec certains
frameworks connus tels que TOGAF). La gouvernance SOA
permet alors d’apporter un cadre pour les nouvelles activités
spécifiques à la mise en œuvre des Architectures de Services, et
non couvertes par les disciplines déjà en place dans l’entreprise.
13
Les dimensions multiples à considérer
La gouvernance SOA recouvre un périmètre d’application très
large, qui présente deux dimensions majeures : la stratégie et
l’opérationnel.
Sur l’axe stratégique, le programme de gouvernance SOA doit
proposer un cadre pour la gestion de portefeuilles de solutions
SOA (aussi connues sous le nom d’applications composites)
et la gestion de portefeuilles de services. Pour cela, il apporte
des éléments de réponses sur les différentes problématiques
stratégiques : l’identification (des solutions éligibles au paradigme
SOA, et des services candidats à la réutilisation), le financement
(qui paye pour la réalisation de fonctionnalités transverses et
partagées ?), la planification, la priorisation, la propriété et la
responsabilité, etc.
Sur l’axe opérationnel, il est nécessaire de contrôler et de sécuriser
les trois temps forts de l’existence des solutions SOA et des
services. A savoir : la phase de fabrication (« Design-Time »), la
phase de déploiement (« Deploy-Time ») et la phase d’exécution
(« Run-Time »). Cela nécessite la mise en place de processus
spécifiques de gestion des cycles de vie pour les solutions SOA
et pour les services, à même d’adresser les problématiques
relatives à chacune des trois grandes étapes précitées.
Sur chacun des deux axes, qu’il s’agisse des services ou
des solutions SOA, le programme de Gouvernance SOA doit
considérer les trois piliers fondamentaux d’un dispositif classique
de gouvernance que sont :
1. L'organisation (acteurs de la gouvernance, acteurs des activités
SOA et des tâches à réaliser, rôles et responsabilités…),
2. Les processus (les processus de la gouvernance SOA, et les
processus SOA à placer sous contrôle),
3. La technologie (standards, outils, architecture, infrastructure...).
Un programme de gouvernance SOA doit donc préconiser la
mise en place de processus adaptés aux particularités d’une
démarche SOA, d’un ensemble de directives de contrôle (aussi
appelées « principes directeurs », ou « politiques »), permettant
d’encadrer et de sécuriser à la fois la fabrication et l’exécution
des services (on parle alors de « Design-Time Policies » et de
« Run-Time Policies »), ainsi qu’une organisation cible qui soit
à même de supporter l’ensemble du dispositif méthodologique
et technologique proposé.
Prendre appui sur une méthode éprouvée
Construire un dispositif de gouvernance ne s’improvise
pas. Cela requiert une démarche méthodologique claire et
structurée, associée à une approche itérative et incrémentale.
Un nouveau dispositif de gouvernance peut effectivement
entraîner de nombreux impacts sur les axes méthodologiques
et organisationnels de la branche informatique, en introduisant
par exemple de nouveaux processus de gestion, ou en donnant
naissance à de nouvelles cellules organisationnelles transverses
(centres de compétences, cellule de gouvernance…).
La gouvernance SOA ne doit en aucun cas être déployée via une
approche de type « big-bang ». On veillera plutôt à procéder par
vagues de déploiement successives, avec pour chaque itération :
une phase d'identification, une phase d'implémentation, une
phase de mise en œuvre, puis une phase de supervision du
dispositif cible.
Ainsi il est de coutume d’identifier les objectifs que l’on se
fixe en termes de gouvernance, d’analyser les écarts avec le
dispositif existant, de planifier un plan de transformation et de
transition adapté, d’implémenter le dispositif cible sur le plan
technologique, méthodologique et organisationnel. Enfin, il s’agit
de mettre en place des métriques et des indicateurs de suivi
permettant d’évaluer l’atteinte des objectifs initialement fixés.
GOUVERNANCE SOA
Solutions SOA
(Applications
composites)
YES!
• Processus
• Organisation
• Outillage
YES!
Services
réutilisables
NO?
YES!
NO?
• Processus
• Organisation
• Outillage
NO?
• Processus
• Organisation
• Outillage
Portfolio Management
Gestion de Portefeuille
Dimension
stratégique
YES!
YES!
• Processus
• Organisation
• Outillage
NO?
• Processus
• Organisation
• Outillage
Build-Time
Phase de Fabrication
YES!
YES!
NO?
• Processus
• Organisation
• Outillage
YES!
NO?
• Processus
• Organisation
• Outillage
NO?
• Processus
• Organisation
• Outillage
Deploy-Time
Phase de Déploiement
Dimension
opérationnelle
Matrice de synthèse des différents sujets à prendre en compte au niveau du programme de Gouvernance SOA
14
NO?
Run-Time
Phase d’Exécution
Technique
La boîte à outils intelligente
Si la gouvernance SOA est bel et bien une affaire de méthode
avant d’être une affaire de technologie et d’outils, il n’en demeure
pas moins qu’il existe aujourd’hui sur le marché de nombreux
composants permettant d’outiller et de faciliter la démarche de
gouvernance, aussi bien sur les problématiques de fabrication
des services (et autres actifs SOA), que sur les problématiques
d’exécution en production.
Le Référentiel SOA favorise ainsi la communication et la
collaboration entre les différents acteurs qui contribuent au
cycle de développement des services.
Contrôler et fluidifier la fabrication
(axe « Design Time »)
La chaîne de fabrication amont des actifs SOA, qui donne
naissance aux différents composants réutilisables de
l’architecture de services, repose généralement sur une usine
logicielle complexe adaptée à l’univers SOA, ainsi que sur une
organisation réunissant des profils d’intervenants divers et
variés : urbanistes, architectes, développeurs, responsables
qualité, exploitants…
Indéniablement, la Gouvernance SOA s’avère être un atout
essentiel pour fluidifier et contrôler cet « atelier de fabrication
logiciel ». Le référentiel SOA (parfois injustement nommé
« annuaire de services »), de par les fonctionnalités qu’il offre
aux équipes projets, constitue le véritable « atout maître » de
cette gouvernance « Design-Time ».
En positionnant un référentiel SOA au centre de la plate-forme
de fabrication, il devient possible de stocker, référencer, indexer
et gérer de manière simple et compréhensible les composants
réutilisables de l’architecture de services, le tout en un endroit
unique, centralisé et facilement accessible. Véritable base de
connaissances du SI existant, le référentiel SOA se veut le
gardien du patrimoine SOA, et la mémoire de son évolution.
Suivre les différents composants partagés et réutilisables de
l’architecture au cours de leur existence devient possible : depuis
leur identification, jusqu’à leur déploiement sur les plateformes
d’exécution, en passant par les traditionnelles phases de
conception et de développement.
Pour ce faire, il propose de modéliser et de suivre le cycle de vie
des différents composants SOA. Ces cycles de vies décrivent
les différentes étapes de la méthodologie de projet suivie, et
mobilisent les intervenants adéquats sur chaque activité en
distribuant les tâches, en déclenchant des workflows et en
gérant les rôles, les responsabilités et les permissions (droits
d’accès et de visibilité sur les données au cours de chaque
étape et pour chaque intervenant).
Exemple de Cycle de Vie des Services géré dans le Référentiel SOA
S’il apporte souplesse et flexibilité aux processus de fabrication
et de gestion des actifs SOA, il propose également de paramétrer
et de faire appliquer de nombreux contrôles lors des transitions
entre les différentes étapes du cycle de vie. Ces contrôles
s'effectuent au travers des politiques de conception (« DesignTime Policies »), qui sont la concrétisation informatique des
principes directeurs identifiés lors de l’élaboration du régime de
gouvernance. L’application de ces contrôles permet de garantir
la qualité des livrables et des services développés, assure leur
conformité aux directives internes de gouvernance, et suscite
ainsi la confiance des consommateurs potentiels des services.
Il s’agit là d’un enjeu majeur de la gouvernance, permettant
de promouvoir la réutilisation de composants partagés dans
l’entreprise de façon transverse.
Flexibiliser et superviser l’exécution
(axe « Run-Time »)
L’outillage de la gouvernance ne se limite pas à la phase de
fabrication des services. Du côté des plateformes d’exécution, et
plus spécialement au niveau des environnements de production,
le contrôle et la surveillance des services déployés est également
pratiqué. Ils s'effectuent à deux niveaux distincts, et sont pris
en charge par deux briques d'architecture complémentaires.
Afin de contrôler les « services », un composant appelé
« Médiateur » se positionne au centre de l’architecture SOA
de référence (dans la zone des fonctions transverses). Il joue
le rôle de « proxy » incontournable pour toutes les invocations
des services back-ends situés dans les domaines fonctionnels
ou métiers du SI.
15
Au niveau des « transactions », le composant de type « SOA
Management » autorise quant à lui une supervision de bout en
bout des appels de services, analysant le parcours transactionnel
des échanges entre les différentes briques de l'architecture. Il
permet ainsi la surveillance et la mesure de métriques au niveau
des transactions (TLA), la détection des problèmes et l'analyse
des causes probables, ou encore la capture du contenu des
transactions et du contexte qui a provoqué l’erreur… Le tout,
bien entendu, en corrélant automatiquement les transactions,
éliminant ainsi la charge de recherche manuelle sur de multiples
composants et serveurs de l'architecture en cas de défaillance
du système. Ce type de composant offre la garantie d’une
architecture maîtrisée et placée sous contrôle.
Ainsi, il assure un découplage propre entre les consommateurs
et les fournisseurs de services, qui cessent alors de s’appeler
entre eux dans une approche de type sOA, pour « spaghetti
Oriented Architecture ».
Mais ce n’est pas là son seul atout. En tant que pivot central
de l’architecture, il met également en application et veille au
respect des « Run-Time Policies ». Ces politiques de gouvernance
sont édictées en amont lors de la spécification du dispositif de
gouvernance à mettre en œuvre, et portant sur les principes
d’exécution des services.
Ainsi, le Médiateur veille au respect des engagements
contractuels qui lient les consommateurs et les fournisseurs de
services, en contrôlant la qualité de service rendue (« QoS ») au
travers de politiques de type « SLA » (« Service Level Agreement »),
mais également la sécurisation des accès via l'application
de politiques de sécurité, ou encore le routage (technique ou
fonctionnel) des invocations vers la bonne version du service (si
plusieurs instances sont déployées sur la plateforme d'exécution)
en fonction de l’identité de l’application appelante.
En raison du positionnement central et hautement stratégique
de ce composant dans l’architecture, qui contrôle tous les flux
d’échanges entre consommateurs et fournisseurs de services, la
charge infligée et les volumétries constatées sont parfois telles
que le déploiement d’une simple brique logicielle n’est plus
satisfaisant. La fonction peut alors être confiée à un accélérateur
XML matériel de type « Appliance ».
Moteur
Dialogue Utilisateur
Passerelle B2B
Fonctions transverses
Annuaire de Services
MÉDIATEUR
Gestion des Identités
SOA
Management
Gestion des Permissions
Domaine fonctionnel/métier
Moteur
Exécution de Services
Moteur
Exposition de Services
Moteur
Système Légataire
Moteur
Système Légataire
Les composants de la Gouvernance Run-Time dans l'Architecture SOA de référence
16
Si les phases de fabrication et d’exécution des services sont
toutes deux adressées par le dispositif de gouvernance SOA,
lui-même soutenu par un outillage adapté, il est plus que jamais
recommandé de s’appuyer sur les nombreuses possibilités
d’intégration et de synchronisation offertes par les produits du
marché, afin de pousser plus loin le pilotage de l’architecture
de services et de gagner encore en simplicité, en fluidité, en
fiabilité et en contrôle.
Stratégiquement, il devient très vite naturel de chercher à
coupler et à faire communiquer ensemble le Référentiel SOA
et le Médiateur. Les avantages d’un tel rapprochement sont en
effet multiples :
• Pour le déploiement et le provisionnement des services sur
les plateformes d’exécution. Le référentiel SOA est garant
de l’état de progression des services dans leur cycle de vie.
Qui d’autre que lui serait mieux placé pour savoir où et à
quel moment déployer ces derniers sur les environnements
cibles (les moteurs d’exécution) ? Ou pour provisionner le
Médiateur, qui se doit d’exposer aux consommateurs les
services de façade appropriés ?
• L’intérêt est tout aussi flagrant pour les règles d’exécution
des services. Qu’il s’agisse de politiques « Run-Time » de type
« sécurité », de type « routage » ou encore de type « SLA »,
celles-ci doivent faire l’objet d’un accord préalable en phase
de fabrication, passé entre le propriétaire qui fournit le service
exposé, et le propriétaire de l’application qui va utiliser (ou
consommer) ce même service.
© Logica Business Consulting
Zone d’interaction Partenaires
Zone d’interaction Utilisateurs
Un pas de plus vers le pilotage stratégique
Cet accord doit être formalisé au travers d’un contrat d’utilisation.
Les différentes règles à appliquer au service (sécurité, SLA,
routage…) constituent les modalités de ce contrat. Si le référentiel
SOA est de toute évidence le lieu de prédilection pour déclencher
un workflow permettant d’établir ce type de contrat, le médiateur
demeure, pour sa part, le composant privilégié pour appliquer et
faire respecter les contrats lors de la réception des invocations
de services.
Dès lors, le besoin d’alimenter le Médiateur avec les contrats
établis en phase de fabrication depuis le référentiel SOA semble
évident.
Technique
(Zone de Fabrication)
(Zone d’Exécution)
fabriquent
Profil.XXX
Développeur
Appli.1
Architecte
Appli.2
Appli.3
Appli.n
Consommateurs
de Services
ENVIRONNEMENT TECHNIQUE (DEV, RECETTE MOE, VALIDATION MOA, PRODUCTION…)
RÉFÉRENTIEL
GOUVERNANCE
MÉDIATEUR
WSDL
Services
Contrats
provisionne
Services
Services
fabriquent
Profil.XXX
Développeur
Architecte
Système
« BackEnd » 1
Système
« BackEnd » 2
Fournisseurs
de Services
SOA
Le référentiel SOA communique avec le médiateur pour provisionner services et contrats sur la plateforme d'exécution
Qu'il s'agisse du provisionnement des services ou des contrats,
on constate que le référentiel SOA prend la dimension d’un
véritable « poste de contrôle et de pilotage » de l’architecture de
services. Il devient le pupitre de commande privilégié de ce qui
se passe sur les plateformes d’exécution : ce qui est initialement
défini en phase de fabrication fait foi sur ce qui s’exécute in fine
sur les environnements de production.
Applications pragmatiques et perspectives
A présent, quelques exemples de déclinaisons concrètes d’un
tel dispositif.
Financement et de refacturation des services
Les problématiques de financement et de (re)facturation des
services SOA peuvent être adressées aussi bien dans un
contexte purement interne (les différents domaines fonctionnels
et métiers de l'entreprise monnayant l'utilisation des services
qu'ils mettent à disposition des autres domaines) que dans un
contexte externe, qui consiste à facturer aux partenaires B2B
l'utilisation des services exposés à l’extérieur de l’entreprise.
Un constat s’impose : ces problématiques s'inscrivent dans la
lignée du déploiement d'un régime de gouvernance SOA. En
effet, elles nécessitent d’engager une réflexion de fond tant
sur le plan de la stratégie amont qu’au niveau de la mise en
œuvre opérationnelle du dispositif (outillage et paramétrage
spécifiques à déployer sur les environnements de fabrication
et d'exécution des services).
L’établissement d’une stratégie de gouvernance financière,
au sens large, permet notamment de définir les règles de
financement des moyens transverses :
• Elle formalise les différents postes de coûts (identification
des ratios entre matériels, logiciels, intervenants; évaluation
du coût des ressources non utilisées...), les services rendus
et l’engagement de QoS au regard des coûts ;
• Elle offre la possibilité d’identifier et de facturer des niveaux
de qualité de service différents (par exemple 5j/7 ou 7j/7) ;
• Elle valorise l’impact des demandes clients (nombre de
déploiements, d’incidents applicatifs, d’interventions en
astreinte) et autorise une forme de transparence sur les coûts.
On part du coût de revient (prix du matériel, des licences, des
intervenants, etc.) pour calculer le prix de vente du service.
Une telle démarche stratégique favorise le recouvrement de
l’investissement, et la constitution d’un budget prévisionnel
pour les investissements futurs grâce à un calcul de marge sur
le prix des services mis à disposition en interne, et/ou auprès
des partenaires B2B.
Sur le plan du respect des bonnes pratiques SOA, une politique
de refacturation interne peut, à elle seule, jouer un rôle essentiel
dans la promotion de la réutilisabilité des services au sein de
l’entreprise, dans l’incitation au respect des règles de conception
idoines, ainsi que dans l’identification et le suivi de métriques
dédiées à la réutilisation.
Au cours de la phase de fabrication des services, la méthodologie
de conception employée pour un service (re)facturable doit
également préciser certains aspects non fonctionnels importants,
relatifs aux aspects comptables : un modèle de mesure de
17
l'utilisation du service (qui doit être mesurée si le fournisseur
requiert une tarification à l’usage de type « pay per use »),
ainsi qu'un modèle de tarification (tarification à l’utilisation
de type « pay per use », tarification à l’abonnement de type
abonnement (subscription), tarification à la location de type
« leasing » etc.) permettant de déterminer le montant à facturer
au consommateur.
Ces aspects spécifiques doivent être pris en compte et
modélisés au niveau du contrat d'utilisation du service, qui fixe
les différentes modalités autour desquelles consommateurs et
fournisseurs de services s'accordent. Ainsi, des modalités de
nature financières viennent s'ajouter aux notions déjà connues
de SLA, de disponibilité, ou encore de sécurité...
Zone d’interaction Utilisateurs
La mise en place d'un dispositif de (re)facturation des services
exige donc une maturité certaine de l'organisation tant sur la
dimension stratégique de la gouvernance des services que
sur la dimension opérationnelle. Sur l'axe stratégique, on
retiendra la nécessité d'identifier et de spécifier un dispositif de
financement qui soit adapté au contexte, aux besoins et aux
objectifs spécifiques de l'entreprise qui s'engage dans cette
voie (dimensions « méthodologique » et « organisationnelle »,
accompagnées d’un ensemble de règles et de bonnes
pratiques...). Sur le plan opérationnel, il s'agira d'instrumenter
au mieux ce dispositif en adaptant l’architecture du SI et en
s’appuyant sur un ensemble d’outils, au cours des phases de
fabrication (« Design-Time ») et d'exécution (« Run-Time ») des
services (dimension « technologique »).
Zone d’interaction Partenaires
Moteur
Dialogue Utilisateur
Passerelle B2B
Exécution des
politiques liées à
la facturation
Fonctions transverses
SOA
Management
RÉFÉRENTIEL SOA
Gestion des Identités
Publication
des contrats
et politiques
de facturation
Gestion des Permissions
Authentification
Exécution des
politiques
Autorisation
Supervision SLA
Calcul des métriques, traces, logs
Supervision du respect
des SLA définis dans le
contrat
Moteur
Moteur de
Facturation
Moteur
Emission de la facture à
partir des mesures
d’usage et de la matrice
de tarification liée au
contrat
Remontée des métriques (mesures d’usage)
Système Légataire
© Logica Business Consulting
Dispositif type de refacturation des services
18
Technique
Stratégies Cloud et Green IT
Si les problématiques de financement et de (re)facturation des
services constituent une déclinaison concrète de la gouvernance
SOA, elles ne sont pas les seules. Bien d’autres initiatives
stratégiques, présentes ou à venir, risquent d’exiger l’existence
préalable d’un tel dispositif dans votre département informatique.
Ainsi, le succès d’une approche « Cloud Computing » repose en
grande partie sur l’existence d’un dispositif de gouvernance du
Cloud permettant d’encadrer la démarche. Digne héritière de la
gouvernance SOA, la gouvernance du Cloud est régie par les
mêmes principes fondamentaux. Seules les priorités changent.
Alors que la gouvernance SOA a naturellement tendance à favoriser
et à prioriser la gouvernance de la phase de fabrication des services
au détriment de la phase d’exécution, jugée moins prioritaire,
la gouvernance des architectures Cloud met plus fortement
l'accent sur la gestion des contrats qui lient les consommateurs
et les fournisseurs, en raison de l’importance fondamentale des
engagements en termes de SLA, qui doivent être soigneusement
appliqués, contrôlés et supervisés en conséquence.
Dans la lignée des problématiques Cloud, les stratégies dites de
« Green IT » (ou informatique verte) sont également gouvernées
par des principes directeurs que l’on rencontre dans le cadre de
la gouvernance SOA : celle-ci propose en effet d’ores et déjà
une méthode et des outils permettant d’optimiser le partage des
ressources utilisées par les différents services informatiques,
réduisant par là même la consommation d'énergie du système
d’information, et diminuant les coûts liés à l'acquisition de matériel.
Ainsi, il est tout à fait envisageable de spécifier et de mettre en
place certaines politiques et certaines métriques d’exécution
des services, permettant aux administrateurs d'infrastructures
IT complexes de déterminer avec exactitude la puissance
nécessaire au bon fonctionnement du système, et de mesurer
avec précision l'énergie « consommée » par chacun des services
de l’architecture , permettant in fine de mettre en place des
mécanismes de contrôle et de régulation des coûts énergétiques.
Un dispositif de gouvernance SOA à la fois rationnel, efficace
et adapté au contexte de l’entreprise est un atout stratégique
majeur qui ne s’achète malheureusement pas « clés en main ».
Même si certains intégrateurs peu scrupuleux prétendent détenir
la recette miracle et universelle s’appliquant uniformément dans
tous les contextes possibles… Ou si certains éditeurs affirment
pouvoir résoudre toutes les problématiques par le simple et
unique fait de déployer leur vaste (et coûteuse) suite d’outils
dans tout environnement.
La gouvernance n’est pas qu’une question d’outils. C’est avant
tout une démarche méthodologique structurée permettant
d’identifier, de spécifier, de mettre en œuvre, puis de superviser
un ensemble de processus et de principes directeurs qui vous
permettront de cadrer et de sécuriser votre initiative SOA. Elle
doit prendre en compte l’organisation, le contexte, la culture,
l’historique et toutes les particularités de l’entreprise afin de
répondre au mieux aux impératifs de contrôle et de flexibilité
qui lui sont propres, tant sur les dimensions technologiques,
méthodologiques qu’organisationnelles.
Elle peut également s’appuyer sur un outillage dédié, permettant
de faciliter et d’accélérer certaines tâches candidates à
l’automatisation, tant pour la fabrication que pour l’exécution
des services : à ce titre, le « Référentiel SOA » et le « Médiateur »
constituent les deux bras armés de la gouvernance SOA, et
deviendront rapidement vos meilleurs alliés pour contrôler et
piloter, aujourd’hui comme demain, la stratégie de votre système
d’information. n
Eric Vendeville,
Consultant Senior, en charge de
l’offre Stratégie de Gouvernance SOA
Eric Vendeville accompagne de grands comptes dans leur stratégie de déploiement
de la Gouvernance SOA. Il maîtrise la méthode et les outils relatifs au sujet de la
Gouvernance SOA. Il intervient le plus souvent sur des cadrages méthodologiques
et des cadrages d'architecture. Il traite des architectures orientées services (SOA)
dans leur ensemble depuis plus de six ans à présent.
Logica Business Consulting est l’entité Conseil du groupe Logica, entreprise du
service en business et technologie qui réunit 39 000 collaborateurs. Elle propose
conseil en management, intégration de technologies et externalisation à ses clients
du monde entier, dont les plus grandes entreprises en Europe.
Site web : www.logica.fr/conseil
19
Actualités
internationales
Encore du travail pour généraliser le télétravail
Une étude commandée à IDC par Bouygues Telecom montre que les entreprises françaises rechignent
à étendre le télétravail. Fin 2010, le cabinet d’études IDC a interrogé les responsables (DSI, RH…) de
240 entreprises françaises de plus de 50 salariés.
Premier résultat : 84 % des entreprises affirment disposer d’un extranet
et d’un réseau social interne (chiffre tout de même étonnant, où se
cachent-elles ?), 76 % proposent le Webmail et 81 % ont déployé (ou
vont déployer) un VPN pour l’accès distant au SI. L’audioconférence
(56 %) et le partage de documents (57 %) gagnent plus de terrain que
la visioconférence (50 %), la messagerie instantanée (49 %), la webconférence (48 %) et la messagerie unifiée fixe-mobile-PC (41 %).
Malgré tous ces équipements, seuls 24 % des entreprises interrogées
affirment permettre à leurs salariés de travailler depuis leur domicile,
et pour 81 % d’entre elles cela concerne moins de 10 % des salariés.
Des bénéfices clairement perçus…
Les entreprises reconnaissent pourtant les bénéfices apportés par
le télétravail comme les gains en productivité (88 %), une meilleure
satisfaction des clients (81 %), la motivation des salariés (76 %)… Quant
aux salariés, ils avancent comme arguments : une solution aux temps
de transports (61 %), une amélioration des conditions
de travail (29 %), une vie privée plus équilibrée (21 %),
le besoin de travailler au calme (27 %), etc.
Certes, 96 % des entreprises emploient des salariés
nomades (au moins à 20 % de leur temps de travail,
soit 21 % de la masse salariale) et 33 % organisent des
équipes virtuelles entre salariés géographiquement
éloignés. Néanmoins, 77 % des directions générales
se déclarent plutôt opposées au télétravail, contre
seulement 7 % favorables.
Certes, le télétravail devrait apporter de la souplesse
et de la flexibilité, même s’il faut pour cela revoir les
contrats d’assurance de l’entreprise et de travail
de chacun. Et évitons de suivre les commentaires
autour du recrutement difficile de la « génération Y »
(voir édito), de plus en plus indécente en période de
chômage, où les jeunes cherchent surtout un emploi
stable. n
20
Actualités internationales
SFR détenue à 100 % par Vivendi ?
Fin janvier, le groupe Vivendi devait encaisser 3,8 milliards de dollars versés par General Electric
suite à son désengagement dans NBC/Universal. Le groupe de communication français met
ainsi fin aux accords noués avec l’américain, lors de la présidence de Jean-Marie Messier.
Une somme qui s’ajoute au 1,25 milliard d’euros de dédommagement suite au conflit qui
opposait (depuis onze ans) le français à Deutsche Telekom sur la possession de l'opérateur
mobile polonais PTC.
Le Financial Times affirmait ainsi mi-mars que Vivendi était décidée à investir ce pécule pour
racheter la part de 44 % que détient l’opérateur britannique Vodafone dans SFR. Vivendi a
donc offert 6,9 milliards d'euros pour prendre le contrôle intégral de l'opérateur mobile français.
Ce qui porterait la valorisation de SFR à presque 21 milliards d’euros !
Toutefois (selon le Financial Times), une partie des actionnaires de Vodafone ne l’entend pas cette oreille, et estimerait le prix
d’achat aux alentours de 8 milliards d’euros, assortis d’un accord d’itinérance permettant aux abonnés Vodafone d’accéder au
réseau SFR en France.
Vivendi peut certainement attendre encore un peu, et miser sur l’impatience des actionnaires. Quant aux actionnaires de Vodafone,
ils peuvent espérer qu’un autre géant se porte candidat, mais cela est bien peu probable. n
Amazon Web Services joue le modèle gratuit
Proposer des services d’infrastructure (IaaS) avec
son offre EC2 (Elastic Compute Cloud) ne suffit plus
à Amazon Web Services. Pour commencer, AWS a
lancé son offre Elastic Beanstalk, permettant aux
développeurs de déployer et de gérer des applications
plus facilement à travers son service Cloud.
Et dernièrement, le fournisseur de services en ligne
a annoncé CloudFormation, facilitant l’utilisation
de ses ressources. Disponible sans surcoût, AWS
CloudFormation permet de décrire les ressources
nécessaires et la manière dont elles seront attribuées
selon les applications. Les techniciens peuvent utiliser
les gabarits CloudFormation pour définir les ressources
AWS utilisées pour exécuter une application. Autre
possibilité, créer ses propres templates à l’aide des
échantillons des gabarits CloudFormation.
Objectif : simplifier le provisionnement automatisé de ressources afin que les développeurs n’aient
pas à se préoccuper du séquençage ou des interdépendances.
Les gabarits assurent une meilleure productivité grâce aux fortes possibilités de réutilisation. En effet,
grâce aux gabarits AWS CloudFormation, les informaticiens peuvent copier des couches d’infrastructures
déjà exploitées, sans avoir à créer sans cesse les couches indispensables pour chaque nouveau
déploiement.
AWS a tout intérêt à proposer ce type de solutions gratuitement, puisqu’elle favorise le déploiement
de plus de ressources, payantes ! n
21
IBM : cent ans d’innovations
Le 16 juin 1911 naissait la Computing Tabulating Recording Company. À l’époque, l’entreprise combine
de multiples technologies dont les noms laissent rêveurs : la calculatrice de mesures de Julius Pitrap,
l’enregistreur de temps d’Alexander Dey, la pointeuse de William Bundy ou encore l’Electric Tabulating
Machine d’Herman Hollerith. Tous ces systèmes de traitement automatique donneront logiquement
naissance à l’informatique, sensés automatiser le traitement de l’information.
Le 14 février 1924, l’entreprise est rebaptisée International Business Machines Corporation, plus connue
jusqu’à aujourd’hui sous le nom d’IBM.
IBM a déjà mis en ligne de nombreuses ressources photo et vidéo, dont un excellent documentaire
retraçant l’histoire d’IBM, et même disponible en français !
Le dirigeant d’IBM, Sam Palmisano a inauguré le centenaire par un discours prononcé à HEC Paris le 2
mars 2010, et intitulé « A business and its ideas : Shaping a company and a century. » De nombreuses
ressources sont disponibles à cette adresse : http://www.ibm.com/ibm100. n
Microsoft apporte un milliard de dollars à Nokia, pour commencer
L’arrivée de Stephen Elop comme patron de Nokia n’est pas
passée inaperçue ! L’ex-dirigeant de la division Entreprise
de Microsoft a brutalement modifié le cap stratégique de
l’entreprise de téléphonie en s’engageant à adopter le système
d’exploitation mobile de Microsoft aux dépens de Symbian,
le 12 février dernier. Un système longtemps soutenu par le
constructeur finlandais, mais qui s’essouffle face à iOS d’Apple,
à Google Android et à Rim (BlackBerry).
À défaut de plusieurs, Microsoft annonce s’apprêter à verser
un milliard de dollars pour aider Nokia à intégrer et faire la
promotion de Windows Phone sur ses terminaux mobiles.
En outre, Nokia économise les frais de développement de
système d’exploitation mobile. Une aubaine en période de
réduction des coûts.
Stephen Elop et Steve Ballmer, les deux CEO tout sourire
De son côté, Microsoft touchera une licence pour le système d'exploitation mobile installé sur chacun des
téléphones Nokia, vendus par dizaines de millions. n
22
Actualités internationales
Une tablette sous Windows ? Pas avant dix-huit mois !
Le système Android de Google semble emporter tous les suffrages de
constructeurs de tablettes face à iOS de l’iPad Apple. Une ruée qui ne semble
pas bousculer Microsoft. En effet, le géant de Redmond annonce la sortie de
son OS pour tablette pour septembre… 2012 !
Prudence, méfiance ou technologies non encore abouties ? Plutôt la concordance
avec la sortie de Windows 8, dont une version est prévue pour l’architecture ARM,
adoptée par la quasi-totalité les fabricants de tablettes.
Et si Apple et Google devenaient incontournables sur ce marché avant cette date ? Et
si le nombre d’applications disponibles sous ces plateformes jouait en leur faveur ? Il
semblerait que Microsoft travaille à adapter Windows 7 aux écrans tactiles et à la durée de
vie de la batterie de tablettes… En attendant la bêta de Windows 8 pour tablettes dans quelques mois ! n
Adieu Internet Explorer 6 !
Après 10 ans de bons et loyaux services, Internet Explorer va tirer sa
révérence, même s’il reste utilisé par 11,3 % des internautes (contre
8 % pour IE7). Microsoft en assure même la promotion avec l’ouverture
du site « The Internet Explorer 6 Countown » (http://ie6countdown.com)
invitant les utilisateurs d’IE6 à adopter IE9.
Le site souligne que « plus de sites web pourront arrêter de supporter
IE6, épargnant des heures de travail aux développeurs. » C’est oublier
un peu vite certaines entreprises qui ont développé des applications
et intranets fonctionnant sous IE6... Bien que l’éditeur est prévu pour
elles des services d’aide à la migration.
Microsoft espère atteindre rapidement les 1 % d’internautes IE6 (sans
préciser de date), et invite les internautes à relayer son message en
installant des bannières spécifiques sur leurs pages Web ou les réseaux
sociaux.
Au passage, Microsoft s’offre aussi une campagne en faveur du téléchargement d’IE9. À moins que Google Chrome ou Firefox
sachent en tirer parti… n
es !
u
boutiq
e
r
v
u
Free o
« Nous allons ouvrir des boutiques Free […] dans les prochaines semaines, dans des villes moyennes situées entre
50 et 200 km de Paris » a déclaré début mars Xavier Niel, cofondateur du groupe Iliad et vice-président du conseil d’administration.
La politique 100 % Internet montre vite ses limites, même secondée par un support téléphonique. Pour devenir un acteur crédible
de téléphonie mobile à part entière, Free a compris que des boutiques physiques s’imposent. Quelques boutiques de 50 à 300
mètres carrés seront ouvertes pour commencer.
On trouvera donc des échoppes Free aux côtés de celles gérées par Orange, SFR, Bouygues Telecom ou Numéricable, avec des
emplois à la clé (et certainement des emplois durables…). Free avait déjà fait évoluer son modèle en proposant l’intervention de
spécialistes de proximité chez ses abonnés Internet et téléphonie.
Néanmoins, on peut légitimement se poser la question des tarifs et forfaits proposés. En effet, avec tous ces frais de structures
(indispensables), le trublion des opérateurs Internet pourra-t-il encore conserver des marges assez intéressantes avec des prix
agressifs ? À suivre… n
23
iPad 2 : Pas de quoi pavoiser
Début mars, Steve Jobs a tenu à présenter lui-même le nouveau-né tant attendu de la marque à la
pomme : l’iPad 2. Pour contrecarrer les rumeurs sur son état de santé alarmant, le patron d’Apple a
encore fait son show : « Nous travaillons sur ce produit depuis longtemps, et je ne voulais pas manquer
cela ! », a-t-il lancé sur scène.
En vendant plus de 15 millions d'exemplaires entre avril et décembre 2010, Apple annonce avoir
empoché 9,5 milliards de dollars, et avoir recensé 65 000 applications iPad pour 200 millions d’abonnés
à iTunes, à l'App Store et à iBooks.
Plus fin, plus léger et plus rapide, il est architecturé autour d’un processeur double cœur A5 cadencé à
1 GHz et dispose d’une caméra arrière HD avec zoom numérique 5X, d’une caméra frontale VGA et d’un
gyroscope à 3 axes. Ayant maigri d’un tiers, son épaisseur atteint tout juste 8,8 mm (contre 13,4 mm), et
son poids 601 grammes en version WiFi (contre 680 g). En revanche, les tarifs restent similaires (entre
499 dollars pour le modèle 16 Go et 829 dollars le 64 Go) et l’iPad2 -blanc ou noir- tourne sous iOS
4.3. En revanche l’iPad 1 est proposé pour 100 euros de moins. Il faut bien aider à vider les stocks…
Mais toujours pas de connecteurs USB ou autres, si ce n’est un adaptateur HDMI optionnel à environ
39 dollars. Bref, pas de quoi pavoiser, en attendant peut-être des ports USB et plus d’ouverture sur
l’iPad 3. Sait-on jamais ! n
Le cloud clés en main Open Source
Si les acteurs traditionnels de l’informatique (les géants
comme les plus modestes) lancent de grandes initiatives
autour de cloud, on n’entend beaucoup moins parler
des projets open source. Pourtant, certains méritent
clairement d’être mis en lumière.
XCP ou Xen Cloud Platform, tel est le nom du projet
Xen.org visant à fournir une infrastructure de cloud
privé prête à l’emploi. Enfin en version 1.0, XCP est
plutôt destinée « aux petites organisations souhaitant
se lancer dans le cloud privé » assurent les promoteurs
de la solution.
Reposant sur l’hyperviseur Xen, cette plate-forme supporte Windows et Linux comme systèmes
d’exploitation invités. Elle gère le réseau et le stockage, et apporte des outils d’administration pour
gérer la sécurité, les applications, le contrôle des performances, les correctifs, la reprise d’activité
après sinistre…
Sa compatibilité avec le projet de cloud computing ouvert OpenStack favorise l’interopérabilité et
l’ouverture, synonyme de pérennité. n
24
Interface pivot entre l’utilisateur et le SI, le poste de travail est un élément clé du système d’information.
Il est au cœur des processus d’échanges et de travail.
Si la multiplicité des terminaux modifient la forme du poste de travail, les attentes de l’utilisateur deviennent de plus
en plus nombreuses.
IDC, filiale du leader mondial du conseil,
et des études dans les technologies de l’information.
IDC France
vous donne rendez-vous
le mercredi 11 mai 2011 (9h – 15h30) à Paris 9ème
à la conférence IDC POSTE DE TRAVAIL 2011
Les nouveaux usages et enjeux du poste de travail
Au programme :
•
•
•
•
VISION ET ANALYSE IDC : ETAT DES LIEUX ET TENDANCES 20112015
LA MULTIPLICITE DES TERMINAUX AU SEIN DE L’ENVIRONNEMENT
DE TRAVAIL
CLOUD (SAAS, IAAS), VIRTUALISATION, CONVERGENCE FIXE
MOBILE REVOLUTIONNENT L’INFRASTRUCTURE DE POSTE DE
TRAVAIL ET SON ADMINISTRATION
TRANSFORMATION DE L’ENVIRONNEMENT ET DES METHODES DE
TRAVAIL : QUEL IMPACT SUR LES APPLICATIONS ?
Chaque thème sera agrémenté d’un retour d’expérience :
•
•
•
Fabrice de BIASIO, DSI, Europe Airpost
Antonio da SILVA, information manager, Roche SAS
Thierry MENARD, knowledge management manager, Bureau
Veritas
Le poste de travail prend une nouvelle dimension.
Au cœur des processus de travail, d’échanges,
de communication et de collaboration,
il devient un réel outil stratégique.
Pour participer à la conférence IDC Poste de travail
le 9 mars 2011,
consultez le programme détaillé et inscrivez-vous sur :
•
http://www.idc.com/france/postetravail2011
Code invitation : ITX
•
Contact : Valérie Rolland
[email protected] – tel : 01.56.26.26.85
Cette conférence gratuite est uniquement réservée aux entreprises utilisatrices.
Conférence organisée par
Avec le soutien de
Enterprise
La conduite du changement
au cœur de la réussite des projets
« Ce n’est pas notre périmètre ! », « C’est au métier de communiquer sur les changements », « On a assez de travail pour délivrer
des solutions fiables, ce n’est pas pour aller en chercher ailleurs »… Voilà, dans les grandes lignes, ce que répondent les DSI
interrogés sur leur positionnement vis à vis de la conduite du changement.
26
Comment ça marche ?
Pourtant, la Direction Informatique est bien impliquée (et souvent
incontournable) dans tout chantier de conduite du changement :
organiser un pilote, présenter un prototype, construire un
environnement de formation accessible en multisites, pour
plusieurs profils utilisateurs… autant de tâches à anticiper qui
mobilisent les ressources humaines et techniques. Une DSI
souvent en première ligne quand l’accompagnement se révèle
insuffisant ou inefficace.
nous n’aurions pas eu sinon », déclarait récemment le DSI d’un
des grands acteurs de la pharmacie.
On entend rarement : « Nous n’avons pas assez communiqué sur
les changements de rôle, les nouvelles procédures, la nouvelle
façon d’utiliser l’outil », mais plutôt : « L’application est trop
complexe, peu ergonomique, la navigation pas intuitive… ».
Conduire le changement pour réussir son projet
Des conséquences coûteuses
Un manque d’accompagnement du changement ternit immanquablement l’image de la DSI et ses conséquences sont
coûteuses :
• Du fait de la sur-complexité engendrée par les demandes
d’évolutions qui en résultent : au lieu de respecter la mise
en place d’une base fournisseurs unifiée et d’une procédure
centralisée d’administration, les acheteurs et approvisionneurs
de ce groupe de distribution avaient contourné cette règle
en utilisant le code fournisseur divers et en demandant des
extractions/rapatriement à partir d’Excel.
• Pour le projet, puisque le retour sur investissement (ROI)
est souvent calculé sur la base d’une utilisation nominale
des applications lors du déploiement. Ainsi, une entreprise
du secteur de la santé, ayant mis en œuvre une gestion
électronique de documents a constaté que chaque acteur
du processus avait continué, comme avant, à imprimer et
stocker les éditions papier intermédiaires. Les informations
n’étant pas cohérentes, c’était évidemment perçu comme
un problème lié au système d’information.
Des jalons et des outils
Au départ, la maîtrise du mode projet permet d’intégrer et
de synchroniser le cycle du projet informatique et d’y intégrer
les actions de conduite du changement aux moments le plus
propices. Parfois, certains déploiements sont abandonnés alors
que la majorité des utilisateurs avait été formée.
En outre, le dispositif profite pleinement de la mise à disposition
d’outils utiles à la conduite du changement. Au-delà des
environnements « bac à sable », base école… des outils de
mesure d’appropriation, d’ampleur du changement, ou tout
simplement des intranets intègrent la documentation, des
modules e-learning, des animations pédagogiques, des FAQ...
« Donner à nos chefs de projet un rôle de business partner favorise
le partage d’égal à égal des enjeux des projets. En outre, cela
permet de développer de nouvelles compétences au sein de
la DSI, et d’attirer des profils ayant une sensibilité métier que
A l’heure où les DSI définissent leur offre de service, contractualisent avec leurs clients, pourquoi ne pas offrir une variété de services autour de la conduite du changement ? À quel moment dans
le projet ? Pour quelle valeur ajoutée ? Avec quelles technicités ?
La DSI portant l’engagement de la réussite du projet se doit
d’assumer la conduite du changement. En collaboration
avec d’autres directions de l’entreprise pour accompagner
la dimension humaine du projet, elle apporte son expertise
reconnue en gestion de projet.
Le chef de projet complet aura donc à cœur de maitriser et de
sécuriser l’appropriation de l’outil qu’il réalise, au même titre
qu’il se préoccupe de la qualité de celui-ci ou de la maitrise de
ses coûts et délais… À travers les grandes étapes d’un projet
informatique, il convient d’identifier les points clés du chantier
conduite du Changement
L’étude d’opportunité porte aussi
sur la conduite du changement
C'est le moment décisif pour se poser quelques questions
comme : « Est-ce le bon projet ? », « Peut-on réellement lui
donner des garanties de réussite ? ». On délaisse trop souvent
la conduite du changement à ce stade, car le projet n’en est
encore qu’au stade de l’idée. Discuté presque uniquement en
haut lieu, il souffre de l’absence d’information des partenaires
sociaux, qui empêche toute communication.
Pourtant, il s’agit d’un moment-clé pour valider les conditions
réelles et concrètes qui garantissent la réussite :
• Le projet est-il soutenu par de vrais sponsors ? Le vrai
sponsor est celui qui acceptera de le défendre dans les
moments difficiles, de soutenir la direction de projet, et de
donner l’impulsion pour faire bouger l’organisation par la
voie managériale quand il le faudra.
• Le chantier conduite du changement est-il bien dimensionné ?
C’est le moment de mesurer l’énergie nécessaire à rendre
effectif le changement : acteurs dédiés au sein du projet,
budgets de formation, etc. Mieux vaut ne pas attendre le
déploiement pour annoncer les coûts induits par les choix
de déploiement décidés au moment du cadrage.
Des décisions claires devront être prises en cas de réponse
négative à ces deux questions : « Je n’ai pas de sponsor ! », « Je
ne dispose pas de ressources suffisantes », voire « L’ambition
du projet est démesurée et les moyens à affecter sont
disproportionnés ». La DSI jouera alors son rôle en alertant les
commanditaires, s’épargnant au passage bien des déconvenues
pour la suite du projet.
27
Conception générale : approche des utilisateurs
Déploiement : vigilance et ajustements
Le projet est lancé. Des représentants des futurs utilisateurs sont
associés à la définition de la solution cible dont les contours se
dessinent. Moment propice pour se préoccuper des utilisateurs.
Qui sont-ils ? Quelles sont leurs caractéristiques au regard du
changement à venir ? Quelles sont leurs aptitudes à vivre positivement ce changement ? Quelles sont leurs attitudes pressenties ?
Le chef de projet est payé de ses efforts d’anticipation en
matière de conduite du changement : son plan de déploiement
lui permet de synchroniser l’ensemble des actions techniques
et d’accompagnement afin de minimiser les perturbations
opérationnelles.
Le chef de projet est particulièrement bien placé pour réaliser
(ou tout du moins superviser) cette étude, qui demande une
bonne connaissance de la solution cible. Au vu de cette étude,
il veillera à réaliser les bonnes actions de communication pour
amener le futur utilisateur d’une attitude d’indifférence à l’égard
du projet à une attitude contributive au moment du déploiement
(voir le schéma ci-dessous).
Tout n’est pas gagné pour autant : il reste attentif aux signaux du
terrain et est en mesure d’adapter son dispositif pour répondre
aux aléas. Il est particulièrement visible à ce stade que la conduite
du changement est partie intégrante de la gestion de projet.
Stabilisation, atteinte de la performance
et fin de projet : passer le relai
Durant cette phase, le chef de projet constitue le réseau d’alliés
qui prendront le relais pour assurer la promotion du projet dans
les moments-clés.
Le projet n’est pas fini le jour du déploiement. La fin de
l’accompagnement resserré peut coïncider avec la phase de
vérification de service régulier avant le passage en maintenance.
Conception détaillée/recette :
mise en place des formations
Lorsque l’utilisation du SI devient nominale, le chef de projet
veille à transmettre le sujet aux équipes pérennes : passage du
support au helpdesk, des formations des nouveaux arrivants
à la DRH, etc.
Dès que le projet devient concret (fonctionnalités, ergonomie,
etc.) il est temps de se préoccuper de la préparation du
déploiement : Qui faudra-t-il former et comment ? (e-learning ?
présentiel ? mix ?). Qui faudra-t-il accompagner et comment ?
(utilisateurs clés, support déploiement). La valeur ajoutée de la
DSI à ce stade est en particulier la maitrise des outils à mettre
à disposition du projet : réalisation de modules e-learning, mise
à disposition d’outils collaboratifs pour renforcer les liens entre
le projet central et les relais locaux…
Et tout au long du projet
Garder une bonne connaissance du terrain, mesurer l’efficacité
des actions menées, proposer des évolutions des plans d’action
initiaux, donner au sponsor de la visibilité sur ces sujets et
l’alerter si besoin. En un mot : piloter la dimension conduite du
changement au même titre que les autres dimensions du projet !
LES GRANDES PHASES DU PROJET SI
Etude d’opportunité
Conception Générale
Conception Détaillée/Recette
Déploiement
Stabilisation
LES GRANDES ACTIONS CHANGE & LEURS OBJECTIFS
Formalisation
des enjeux
Réalisation
de l’étude d’impacts
Cadrage de la formation
et de l’accompagnement
Réalisation des modules
de formation/Kits support/
site intranet
Mobilisation managériale
Accompagnement
Pilotage du chantier Conduite du Changement (dont baromètre projet pour mesurer l’évolution de la perception du projet par les cibles)
Ébranler en communiquant
sur le périmètre du projet
Rassurer en communiquant
sur les moyens du projet
Informer en communiquant
sur les gains
Rassurer en communiquant
sur les modalités concrètes
La curiosité
La crainte
Accompagner et sécuriser
la réussite du déploiement
LA PERCEPTION DU PROJET PAR LES CIBLES
Le déni
« Ce projet
ne passera pas
par moi ! »
Le pessimisme
« Ils n’y arriveront
jamais ? »
« On ne peut
plus reculer »
La résignation
28
« Et ça fera quoi
exactement ? »
« Le sujet
est traité
sérieusement »
Le réalisme
« C’est peut être bien
pour la boite, mais moi
dans tout ça ? »
« Ce projet doit
permettre de … »
La compréhension
« On ne me laissera
pas seul »
La confiance
« J’y vais »
L’utilisation
Zoom sur deux outils de conduite du changement
Baromètre Projet : mesurer pour ajuster
Tout au long du projet, le baromètre projet fournit une mesure de
l’efficacité des actions de conduite du changement, et permet
selon les résultats de valider les orientations prises ou de les
recadrer si nécessaire. Il est aussi un moyen de garder contact
avec le terrain.
Le principe consiste à interroger un panel représentatif de cibles
impactées directement ou indirectement par le changement
(utilisateurs, acteurs clés…), sur la base d’un questionnaire
offrant des réponses de type QCM et des questions ouvertes.
La synthèse des réponses met en évidence :
• La mesure de l’efficacité des actions de communication
• Le « ressenti » utilisateurs (verbatims)
Le chef de projet dispose de retours concrets (verbatims, informations terrain…) qui renforcent la légitimité de son diagnostic
terrain et d’éventuelles actions complémentaires à son plan de
conduite du changement initial.
RightChange : faciliter les échanges DSI/métiers
La démarche RightChange est élaborée à partir du retour
d’expérience de plus de 300 opérations de conduite du
changement. Elle se base notamment sur la mesure du niveau
de résistance de la population concernée et de l’ampleur et de
la nature du changement à opérer, et permet de pouvoir agir
avec le maximum d’efficacité pour mettre en œuvre les bonnes
actions au bon moment.
Un projet qui suppose un changement de site géographique et
un changement de fonction ou de rôle ne se traite évidemment
pas de la même manière.
Pour identifier les leviers appropriés à chaque changement,
RightChange propose une méthode d’analyse se déroulant
en trois temps :
• mesure de « l’énergie » à fournir pour réussir les actions de
conduite du changement du projet,
• identification des axes d’optimisation de cette énergie, en
mettant en évidence où se situent les nœuds de complexité
par population,
• préconisations.
Formaliser
les enjeux
Élaborer
et mettre en œuvre
une stratégie
sur mesure
La restitution graphique de cette étude constitue un support
clair et objectif, apprécié des DSI comme base d’une discussion
avec la maitrise d’ouvrage stratégique.
Comme le confiait récemment un DSI au sein de l’administration
(par ailleurs particulièrement impactée par les réformes actuelles
– RGPP2 Révision Générale des Politiques Publiques) : « Le
dialogue autour des restitutions de RightChange permet un
échange très interactif avec les Directions utilisatrices, et
positionne le service informatique dans un rôle de conseil.
L’intérêt d’une conduite du changement objectivée, bien ciblée
et efficace rejaillit à court terme sur la qualité de la solution et à
moyen terme sur le niveau de confiance réciproque »
Mobiliser et animer
un réseau d'alliés
Positionner la Conduite
du Changement au cœur
du projet
Piloter les actions
et l'atteinte
de la performance
Derrière chaque réflexe, un(des) outil(s)
5 réflexes pour réussir la conduite du changement de votre projet
29
Quel rôle pour les DSI ?
Les DSI se trouvent face à une décision stratégique : étendre
leur champ d’intervention à la conduite des changements
induits par leurs projets SI, ou rester rivés sur leur métier de
fournisseurs de solutions informatiques fiables et performantes
à leurs clients internes.
L’investissement du terrain de la conduite du changement par
la DSI représente à la fois une opportunité et une difficulté.
Côté opportunité, il s’agit d’abord pour la DSI de jouer un rôle
plus stratégique au côté des métiers. Elle passe ainsi d’un rôle
de fournisseur interne à celui de « business partner ». Par ailleurs,
une meilleure maîtrise de la conduite du changement sur les
projets SI, ce sont des ressources métier plus faciles à mobiliser
en phase de conception, une solution mieux acceptée lors de
la recette utilisateurs puis du déploiement, des premiers mois
d’utilisation moins ardus. Autant de soucis et de coûts épargnés !
Toutefois, les DSI évoquent deux difficultés majeures. D’une
part, ils sont prudents face à une prise de responsabilité
supplémentaire et aux problèmes ou risques qui en découlent.
D’autre part, un tel repositionnement de la DSI nécessite des
compétences « Change » qui existent rarement dans les DSI,
et donc des opérations non négligeables de formations ou de
recrutement de nouvelles ressources.
Une voie à étudier pour les DSI est peut-être de s’allier aux
DRH ? La DSI apporterait du contenu (grâce à ses connaissances
fonctionnelles et techniques) et ses compétences projet, la
DRH portant les dimensions humaines et organisationnelles. n
Luc Molinier,
Directeur Associé
Olivier Chaussard,
Directeur Associé
Pierre de Saint Victor,
Directeur d’études
ORESYS, société de conseil indépendante de 250 consultants, aide ses clients
à piloter leurs activités, améliorer leur performance et mettre en œuvre leurs
projets de transformation. Dans le domaine de la conduite du changement, Oresys
accompagne ses clients, Direction informatique ou Directions métier à :
• Diagnostiquer les zones de risques (à fort impact)
• Choisir et mettre en œuvre les bons leviers (managériaux, communication, RH,
training…)
• Intégrer dans des organisations optimisées la conduite des changements et le
pilotage des déploiements au sein de grands programmes de transformation
(multi projets, multi sites…)
Oresys organise de nombreux évènements, conférences, échanges sur le sujet.
Site web : www.oresys.eu
30
Toutes les solutions et nouveautés en Open Source…
Pour encore plus de libre au service de l’entreprise !
Le salon européen dédié à Linux
et aux logiciels libres
NOUVEAU
LIEU
NOUVELLES
DATES
10-11-12
Bu
sin
es
sI
MAI
nt
2011
el
lig
en
ce
-C
lo
ud
Co
Inté
rop
éra
bilit
éMob
ilit
m
pu
tin
g
é-N
et
-C
wor
lus
ter
in
g
CNIT - Paris La Défense
&
kM
ana
g
G
rid
eme
-C
M
S
-C
ol
nt - P
oste
la
bo
ra
tif
-C
RM
de Tr
avail
-D
ata
Ce
nte
r-D
évelo
om
- E-C
ce
mer
P
- ER
fr
- In
uc
astr
utr
es
-
o
Inn
va
tio
n
ppement -
- Sécu
rité - S
OA & W
eb Ser vices -
- SGDB -
ualis
qué - Vir t
- Temps Réel & Embar
ation
P
- VoI
EXTRAIT DU PROGRAMME DES CONFÉRENCES :
- Dans les nuages et au-delà : un ciel dégagé pour les logiciels libres ?
- Du poste lourd aux terminaux légers en passant par le mobile : 2011 sera-t-elle enfin l’année du poste de travail Linux ?
- Quelle place pour l’Open Source dans l’e-Commerce de demain ?
- L’innovation dans le Web, de la plateforme au client
- Le futur des bases de données
- ERP, CRM, BI : les solutions open source à déployer en entreprise
- Mobilité, Linux, Libre : une conjugaison d’avenir ?
- Gestion de contenu, collaboration, réseaux sociaux : vers l’émergence d’une offre «Entreprise 2.0» en open source
Pour toute demande d’information : [email protected]
Demandez votre badge d’accès gratuit sur www.solutionslinux.fr
Un événement
Partenaire officiel
Mesurer & gérer la dette technique
des portefeuilles applicatifs
L
a société CAST a conçu une série de rapports visant à dégager les tendances actuelles relatives à la qualité structurelle
des applications de gestion (robustesse, performances, sécurité, facilité de modification...). En se basant sur ces travaux,
l'auteur expose les principaux enseignements qu'il en a tiré.
32
Quoi de neuf Docteur ?
La qualité structurelle à travers le globe
La qualité structurelle se réfère aux caractéristiques intrinsèques et non fonctionnelles d’une application,
c’est-à-dire à l’aplomb de son architecture et à la tenue de son code source plutôt que son alignement
à ses exigences fonctionnelles.
Les caractéristiques de qualité structurelle sont cruciales, car elles sont à la fois difficiles à mettre en
évidence au moyen des techniques classiques du test et en même temps la cause la plus fréquente des
problèmes de fonctionnement des applications telles des pannes, des dégradations de performance,
des intrusions par des utilisateurs non autorisés ou des altérations de données.
Les données de l’étude ont été recueillies sur une période de trois ans, proviennent de 288 applications,
totalisant 108 millions de lignes de code (équivalant à 3,4 millions de points de fonction), soumises par
75 entreprises ou organismes publics. Les résultats de ces analyses sont consignés dans Appmarq,
un référentiel de données sur la qualité structurelle maintenu par CAST. Ces 75 organisations relèvent
de huit secteurs d’activité, à savoir l’énergie, la finance, l’assurance, les services informatiques, les
technologies, les télécommunications, l’industrie et l’administration publique. Ces organisations sont
basées principalement en Amérique du Nord, en Europe et en Inde. La taille des applications analysées
s’étale de 10 000 à 5 millions de lignes de code, 26 % des applications contenant moins de 50 000
lignes de code et 32 % comportant entre 50 000 et 150 000 lignes de code. Ces données sont le fruit
d’un travail d’analyse et de mesure de la qualité structurelle sur l’éventail d’applications de différentes
technologies le plus large jusqu’à présent jamais étudié.
L’article se concentre sur quatre caractéristiques de la qualité structurelle : robustesse, performance,
sécurité et évolutivité. L’évaluation de chaque caractéristique provient d’une analyse du code source
visant à détecter des violations de bonnes pratiques en matière d’architecture et de codage. Les notes
de chaque caractéristique de qualité structurelle sont agrégées sur plusieurs niveaux (du module à
l’application) et sont calculées, sur une échelle allant de 1 (risque le plus élevé) à 4 (risque le plus faible),
en utilisant un algorithme qui apprécie la sévérité de chaque violation et sa pertinence quant à chacune
de ces caractéristiques.
Six enseignements majeurs pour les applications
La dette technique s’élève à plus d’un million de dollars par application moyenne
La dette technique étant un concept relativement nouveau, ne sont disponibles que peu de données
quantitatives sur ce sujet. La base de données Appmarq de CAST constitue un matériau de premier
choix pour produire une estimation de la dette technique basée sur le nombre de malfaçons de qualité
structurelle dans le code source.
Ces données offrent un cadre objectif et empirique de référence pour la communauté du développement.
Elles fournissent également une base de référence pour apprécier les compromis possibles entre coût
de correction des malfaçons du code source et risque que ces défauts peuvent entraîner en termes
de pannes ou de failles de sécurité.
Dette technique : Coût de l’effort requis pour corriger les malfaçons dans le code source au moment de la mise en production
d’une application. À l’instar d’une dette financière, la dette technique induit des coûts croissants dans le temps – des intérêts –
par le biais de la charge de maintenance et d’évolution elle aussi croissante à cause des malfaçons de qualité structurelle du code .
En utilisant un modèle d’estimation conservateur, nous estimons que la dette technique de notre
échantillon d’applications s’élève à 2,82 dollars par ligne de code. Pour une application de taille moyenne
de 374 000 lignes de code, cela correspond approximativement à une dette technique de 1,055 million
de dollars. Le coût d’apurement de cette dette technique représente donc le poste principal de coût
total de possession d’une application (TCO) et est donc à ce titre l’un des principaux facteurs du coût
de l’informatique.
33
Les analyses préliminaires résumées dans la figure 1 montrent que les applications C/C++ présentent
une dispersion dans la dette technique beaucoup plus importante que celle des applications élaborées
avec d’autres technologies, bien qu’un échantillon d’applications C/C++ plus grand eût été nécessaire
pour caractériser de façon fiable cette répartition.
En examinant la dette technique selon les différentes technologies, il apparait que plus le niveau
d’abstraction d’une technologie est élevé, plus la dette technique est faible.
Ainsi, plus le niveau d’abstraction est élevé, moins le développeur risque de commettre des erreurs, car
la plate-forme ou les frameworks de base prennent à leur charge davantage de tâches de bas niveau.
Figure 1 : La dette technique par technologie ��
Calcul de la dette technique
1. Le taux de violations des règles de codage par millier de lignes de code est fourni par une analyse effectuée au moyen de la solution « CAST Application Intelligence Platform ». Ces violations
des règles de codage permettent de mettre en évidence des problèmes relatifs à la sécurité, à la
performance, à la robustesse et à l’évolutivité du code.
2. Les violations des règles de codage sont classées en trois niveaux de sévérité (haut, moyen, faible).
Dans l’élaboration de l’estimation de la dette technique, il est fait l’hypothèse que seulement 50 %
des problèmes de sévérité haute, 25 % de sévérité moyenne et 10 % de sévérité faible seront
corrigés au cours de la vie opérationnelle d’une application.
3. Il est également fait l’hypothèse conservatrice que la correction de chaque malfaçon prendra
seulement une heure pour un coût horaire chargé de 75 dollars. D’autres études indiquent que ces
chiffres peuvent être plus élevés, notamment quand la correction intervient lorsque l’application
est entrée en phase d’exploitation.
4. Dette technique = (10 % des violations de faible sévérité + 25 % des violations de sévérité moyenne
+ 50 % des violations de sévérité élevée) x (Nombre d’heures de correction) x Coût horaire.
COBOL présente le meilleur niveau de sécurité
La figure 2 montre la répartition des scores de sécurité dans l’échantillon. Cette répartition bimodale
traduit le fait que les applications se rangent en deux types distincts : le groupe des applications
présentant un très haut niveau de sécurité et le groupe des applications présentant un niveau de sécurité
médiocre et un long étalement vers les scores de sécurité très faibles.
La répartition des scores de sécurité est la plus dispersée de toutes les répartitions relatives aux
caractéristiques de la qualité. Cela traduit des disparités significatives dans la prise en compte des
exigences de sécurité selon les types d’applications ou les secteurs d’activité considérés.
34
Sécurité : ensemble des attributs qui limitent le risque d’intrusions non autorisées dans les données gérées par une application.
Des analyses supplémentaires résumées dans la figure 3 montrent que les applications présentant
le niveau de sécurité le plus élevé ont été développées en COBOL et en environnement mainframe
dans le domaine des services financiers, où les exigences en matière de sécurité et de respect de la
confidentialité des informations sont élevées.
Les applications mainframe sont par ailleurs moins exposées aux problèmes de sécurité auxquels ont
à faire face les applications web. Néanmoins, les scores de sécurité moindres affichés par les autres
types d’applications sont surprenants. En particulier, les applications en .NET affichent les scores de
sécurité les plus bas. Ces données suggèrent que la prise en compte des considérations de sécurité
par la communauté du développement serait principalement liée aux contraintes réglementaires
imposées à certaines industries.
Figure 2 : Répartition des scores de sécurité ��
Figure 3 : Scores de sécurité par technologie ��
Les systèmes de l’administration publique sont les moins maintenables
Les scores d’évolutivité montrés en figure 4 répondent à une répartition bimodale, traduisant des
variations importantes dans la maintenabilité des applications de l’échantillon. Comme l’évolutivité
d’une application est une composante majeure de son coût total de possession (TCO), cette répartition
suggère des différences importantes de coût total de possession (TCO) entre les applications dont le
score d’évolutivité est élevé et celles dont le score est faible.
35
Évolutivité : ensemble des attributs qui rendent la modification d’une application plus facile et plus rapide.
Figure 4 : Score d'évolutivité ��
En comparant les scores d’évolutivité par secteur d’activité (figure 5), on constate que les scores
sont significativement plus bas dans le secteur public. Notre échantillon comprenait des applications
d’organismes publics situés à la fois aux États-Unis et dans l’Union européenne. Bien que nous ne
disposions pas de données de coût, ces résultats suggèrent que les organismes publics consacrent
une part significativement plus élevée de leur budget informatique à la maintenance des applications
qu’à la création de nouvelles fonctionnalités. Dès lors, il n’est pas surprenant que, dans son rapport
« IT Staffing & Spending Report » de 2010, le cabinet Gartner rapporte que le secteur public dépense
environ 75 % de son budget pour la maintenance, ratio le plus élevé de tous les secteurs d’activités.
Figure 5 : Niveau d’évolutivité par secteur d’activité ��
Les scores médiocres d’évolutivité dans le secteur public peuvent s’expliquer en partie par la forte
proportion d’applications externalisées dans ce secteur en comparaison du secteur privé. La figure
6 montre que 75 % des applications du secteur public figurant dans l’échantillon étaient externalisés
comparés à 51 % pour le secteur privé.
Lorsqu’on retire les applications du secteur public de l’échantillon, on constate peu de différence
entre les scores d’évolutivité entre applications externalisées et non externalisées. Le faible niveau
d’évolutivité des applications du secteur public peut résulter également de leurs conditions d’acquisition.
De multiples prestataires travaillant sur une application au cours du temps, l’absence dans les contrats
de mesures incitatives à l’élaboration de code facilement maintenable et des pratiques d’acquisition
plus délicates peuvent expliquer ces résultats. À l’opposé, le secteur des services informatiques
présente une médiane plus élevée et une variation plus étroite pour les applications qu’il élabore pour
son propre usage interne.
36
Figure 6 : Proportions d’applications externalisées pour les secteurs public et privé ��
Les langages récents sont moins bien notés en performance et robustesse
Performance : ensemble des attributs qui influent sur les temps de réponses et l’efficacité des applications.
Robustesse : ensemble des attributs qui influent sur la stabilité d’une application et la probabilité d’introduire de nouveaux défauts
lors de modifications.
Comme le montre la figure 7a les scores de performance sont fortement dispersés et plutôt denses
vers les niveaux élevés. À l’opposé, la répartition des scores de robustesse est la plus resserrée de
toutes les répartitions relatives aux caractéristiques de la qualité, avec une légère dissymétrie négative.
La tendance observée dans les scores de performance relève d’hypothèses impliquant à la fois des
facteurs technologiques et des facteurs humains. Primo, la disponibilité et l’utilisation d’outils automatisés
de test de performance ont facilité la détection des problèmes de performance et leur traitement au
cours du développement. La plupart des plates-formes modernes de test intègrent des modules de
test de performance. Bien que ces modules n’opèrent pas au niveau du code source, ils mettent en
évidence les engorgements et sensibilisent les développeurs aux problèmes qui pourraient ralentir
une application ou causer son arrêt intempestif. On s’attend à ce que les entreprises utilisant ces outils
affichent des scores de performance élevés. Deuxio, la performance est l’une des caractéristiques de
la qualité les plus saillantes, en particulier chez les utilisateurs dont elle impacte la productivité. Il n’est
pas rare que les utilisateurs finaux se plaignent à grands cris auprès des équipes de développement
à propos de mauvaises performances, donnant une priorité haute à la résolution de ces problèmes au
détriment d’autres tels qu‘une mauvaise maintenabilité.
Une analyse plus approfondie de ces données, résumée par la figure 8a, montre que les applications
Java EE affichent des scores de performance nettement plus bas que celles développées dans d’autres
langages. Les applications .NET montrent la même tendance, mais pas aussi forte que pour Java
EE. Toutefois, la modularité pourrait expliquer en partie les scores de performance pour .NET et Java
EE, comme évoqué à propos de l’enseignement 4, car une conception médiocre ou une modularité
excessive peuvent avoir un impact négatif sur les performances d’une application.
Figure 7a : Répartition des scores de performance ��
37
Figure 7b : Répartition des scores de robustesse ��
Figure 8a : Scores de performance par technologie ��
Figure 8b : Scores de robustesse par technologie ��
La modularité réduit l’impact de la taille sur la qualité
Les données d’Appmarq contredisent l’opinion classique selon laquelle la qualité d’une application
décroît lorsque sa taille augmente ; avec une exception, l’indice de qualité totale (une combinaison
de quatre mesures de la qualité) n’a pas une corrélation significative avec la taille des applications
dans l’échantillon. Toutefois, l’indice de qualité totale est corrélé négativement avec la taille des
applications COBOL, comme le montre la figure 9 dans laquelle les données sont reportées sur une
échelle logarithmique pour mieux faire apparaître la corrélation.
38
Une explication de cette corrélation négative repose sur le fait que le langage COBOL ne favorise pas la
modularité. En conséquence, les applications sont constituées de composants volumineux et complexes.
Les langages plus récents encouragent la modularité et d’autres techniques qui atténuent l’effet de la
complexité lorsque la taille des applications augmente. Par exemple, la figure 10 montre que la proportion
des composants très complexes (ceux dont la complexité cyclomatique est supérieure à 30) dans les
applications COBOL est bien plus élevée que dans les autres langages, alors que pour les nouvelles
technologies orientées objet, comme Java EE et .NET, cette proportion est plus faible, ce qui est totalement
cohérent avec les objectifs de la conception orientée objet. La modularité peut aussi expliquer les faibles
scores de performance dans .NET et Java EE, comme déjà indiqué dans le quatrième enseignement, car
des niveaux élevés de modularité peuvent impacter négativement les performances d’une application.
Figure 9 : Corrélation entre l’indice de qualité totale et la taille des applications COBOL ��
Figure 10 : Proportion de composants fortement complexes dans les applications ��
L’indéboulonnable GoTo (et autres violations)
Les deux enseignements suivants soulignent deux erreurs communément commises par les développeurs.
Le GoTo considéré comme éternel : Cela fait plus de 40 ans que l’éminent informaticien Edsger
Dijkstra s’est insurgé contre l’instruction GoTo en déclarant que cette dernière rend les programmes
inutilement complexes et sujets à bugs. La lettre de Dijkstra adressée en 1968 au rédacteur de la revue
Communications of the ACM et intitulée « GoTo considered harmful » est souvent considérée comme le
point de départ du mouvement de la programmation structurée, un ensemble de pratiques désormais
systématiquement enseignées dans tout cours de programmation.
Bien que la plupart des langages de programmation modernes aient éliminé l’instruction GoTo, des
langages plus anciens comme COBOL l’autorisent toujours. Il est alors choquant de constater qu’il
y avait 334 249 instructions GoTo dans les 33,4 millions de lignes de code contenues dans les 30
applications COBOL analysées dans le cadre de l’étude – soit grosso modo une instruction GoTo pour
cent lignes de code ! Même après des années de maintenance et de remaniements, ces instructions
néfastes infestent toujours les applications COBOL, ce qui laisse penser que les GoTo sont éternels.
39
Complexité cachée : Une violation courante dans la plupart des technologies est le nombre élevé d’appels
sortants vers d’autres composants d’une même application. Cette violation figure fréquemment en Java
EE, .NET, COBOL, ABAP et C/C++. La complexité de l’application associée à un grand nombre d’appels
sortants augmente alors de façon spectaculaire le temps requis pour faire évoluer une application.
Plus les interconnexions entre composants sont complexes, plus longue est la conception, la mise en
œuvre et le test d’une évolution, ceci se traduisant alors par une inflation du coût de possession et des
délais plus longs pour mettre à disposition des métiers de nouvelles fonctionnalités.
De telles observations indiquent que l’adoption des meilleures pratiques de conception et de codage
est lente. Des réticences à réduire la complexité d’un code qui semble fonctionner correctement
perdurent, même si le coût total de possession (TCO) et le temps pour livrer des améliorations pourraient
être substantiellement réduits en remaniant le code. Ces observations peuvent traduire un besoin de
formation continue des développeurs en matière de pratiques de codage et de conception.
Ces mêmes observations suggèrent également que les équipes de développement persistent à se
focaliser sur les performances et la sécurité de certaines applications critiques, ce au détriment de
l’élimination des problèmes de maintenabilité qui augmentent pourtant le coût total de possession
et pénalisent lourdement la réactivité aux besoins des métiers. Enfin, ces résultats suggèrent que les
responsables informatiques sont toujours enfermés dans un mode réactif privilégiant la satisfaction des
exigences court terme des métiers au détriment d’un mode plus proactif qui s’attaquerait aux causes
à long terme des coûts de l’informatique. n
Bill Curtis,
Directeur Scientifique et Directeur du CAST Research Labs
Bill Curtis a rejoint CAST en 2007 en tant que Directeur Scientifique, et dirige maintenant le CAST Research Labs. Il est un des experts
mondiaux les plus réputés dans le domaine de l’ingénierie et de la qualité logicielle. Il est reconnu pour avoir développé le CMM
(Capability Maturity Model) lorsqu’il était Directeur du Software Process Program au SEI dans les années 90, le standard mondial
d’évaluation de la maturité des processus et de l’organisation des entités de développement logiciel. Il a été nommé Directeur du
Consortium pour la Qualité Logicielle des Systèmes d’Information (CISQ) par le SEI (Software Engineering Institute, université de
Carnegie Mellon) et l’OMG, l’organisme mondial de définition de standards logiciels. Le CISQ a pour objectif de définir un standard de
mesure de la qualité logicielle des systèmes d’information et de la performance des équipes informatiques pour en permettre une
évaluation précise et objective.
Avant de rejoindre CAST, Bill Curtis avait co-fondé TeraQuest, leader mondial des services autour du CMM, racheté par Borland.
Avant TeraQuest, il a dirigé le Software Process Program au SEI, après avoir conduit les recherches sur les technologies intelligentes
d’interface utilisateur et le processus de conception d'un logiciel au MCC, la cinquième génération du consortium de recherche en
informatique à Austin, Texas. Avant le MCC, il a développé un système de mesure de la qualité et de la productivité d’un logiciel pour
la TIT, a mené des recherches sur les métriques et les pratiques logicielles chez GE Space Division, et a enseigné les statistiques à
l’Université de Washington.
CAST, leader mondial du marché de l’analyse et de la mesure des logiciels, permet d’automatiquement mesurer la qualité
structurelle des applications et la productivité des équipes de développement. Fondée en 1990, CAST a aidé plus de 250 grandes
entreprises à améliorer la satisfaction des utilisateurs de leurs systèmes d’informations et à réduire les risques informatique,
tout en en diminuant les coûts de développement et de maintenance. La plupart des grandes SSII ont également adopté CAST
dans le cadre de leur industrialisation et d’offres de services innovantes. CAST est cotée sur le compartiment C d’Eurolist Paris
(Euronext : CAS) et commercialise ses produits au travers d’une force de vente directe solidement implantée aux Etats-Unis, dans
les principaux pays Européen et en Inde, ainsi qu’au travers d’un réseau de partenaires intégrateurs.
Site web : www.castsoftware.com
40
Livres
SharePoint Workspace 2010
Collaborateur régulier d’IT-expert, Fabrice Barbin est un spécialiste des
technologies Microsoft Groove et SharePoint Workspace –entre autres. Doté du
sésame peu répandu de Microsoft MVP (Most Valuable Professional) sur SharePoint
Workspace, il a créé la Communauté SharePoint Workspace francophone et
intervient régulièrement lors de conférences nationales et internationales sur le
sujet. Homme de terrain, il réalise des missions de conseil, formation, avant-vente
et R&D auprès de PME et grandes entreprises.
Dans cet ouvrage très pédagogique, il permet au lecteur de découvrir à son rythme
la richesse fonctionnelle de SharePoint Workspace 2010. Utilisé avec SharePoint
2010 (en mode connecté ou déconnecté), il est aussi l’outil idéal de collaboration
agile du travailleur mobile ou nomade. Mais le livre aborde aussi les aspects liés
au déploiement, et aux divers scénarios d’utilisation. Les initiés apprécieront
les méthodes de personnalisation pour adapter SharePoint Workspace à leurs
besoins métiers. Sans oublier les explications et schémas sur l'architecture, la
sécurité ou l’intégration.
SharePoint Workspace 2010
Fabrice Barbin
Éditeur : ENI
585 Pages - environ 36 € (format numérique 30 € env.)
Les réseaux sociaux expliqués à mon boss
L’objectif du livre est clairement énoncé : expliquer les réseaux sociaux aux
décideurs des entreprises, à travers les témoignages d’acteurs qui les pratiquent. La
rédaction de cet ouvrage collectif a été dirigée par Hervé Kabla et Yann Gourvennec,
fondateurs de l’association Media Aces, « regroupant les entreprises petites ou
grandes, qui promeuvent les usages des médias sociaux ». À la lecture, on ne
peut que sentir le ton très militant des rédacteurs, ce qui n’est pas forcément un
défaut, mais qu’il est bon de souligner.
Le lecteur appréciera les très nombreuses explications pédagogiques, les schémas
et les nombreux exemples décryptés. Quant aux illustrations signées Fix, elles
apportent un rythme et une touche d’humour agréable. En revanche le jargon trop
appuyé (voire suralimenté) renferme le discours dans une dimension ésotérique
aux accents de marketing un peu trop « branchouille ».
À grand renfort de décideurs de grandes et prestigieuses entreprises, le livre joue
un peu trop sur la corde « vous allez manquer le train des gens qui comptent ».
Certes, il n’est pas de bon ton de critiquer les réseaux sociaux. Toutefois, à force
de trop en faire, certains pourraient être tentés de jeter le bébé avec l’eau du bain.
Et ce serait dommage. Qui trop embrasse…
Les réseaux sociaux expliqués à mon boss
Collectif dirigé par Yann Gourvennec et Hervé Kabla
Éditeur : Kawa Éditions
418 pages - environ 36 €
42
COMMENT AMELIORER MES LOGICIELS ?
RENTABILISER LES TESTS, EST-CE POSSIBLE ?
PUIS-JE TENIR MES CHARGES ET MES DELAIS ?
Le Comité Français des Tests Logiciels organise la
troisième Journée Française des Tests Logiciels (JFTL) le
5 avril 2011 aux Espaces CAP15, Quai de Grenelle à
Paris XV.
Evénement unique et indépendant dédié aux tests
logiciels et systèmes en France, la JFTL est l’occasion
d’échanger sur les grandes problématiques actuelles,
de découvrir de nouvelles techniques et de confronter
ses expériences.
Une réelle opportunité d’apprendre comment
améliorer l’efficacité et le rendement des activités de
recette, comment réduire les risques de défaillances
opérationnelles
des
systèmes
d’informations,
comment optimiser la gouvernance des tests…
Un programme axé sur les problématiques
essentielles
 Génération des tests de bout en bout
 Automatisation multiplateformes
 Tierce Recettes Applicatives multitechnologies
 Mise en œuvre concrète des
enseignements du CFTL
 Coûts cachés de la qualité
 Amélioration de la rentabilité des tests
 Critères d’entrée à l’externalisation des
tests
 Optimiser la gouvernance des tests
 Bénéfices du test statique.
Inscription préalable obligatoire: http://www.jftl.org/
120€ l’entrée sur saisie du code de réduction ITEXPEJFTL11
Plus de 150 sociétés en 2010
Avec le support de
Et de :
Acial, Altran CIS, Atos Origin, CAST, Cognizant, Dalisys, EGL,
Hardis conseil, Infotel, Kalistick, Kereval, Neotys,
ps_testware, Scopteam, Smartesting, Sopra, Steria, Wipro.
Et le soutien de nos sponsors média :
01 Informatique, BestPractices, Cloud Magazine,
DSIsionnel, IT-Expert, Programmez, Qualité références et
Solutions & Logiciels
Les enjeux juridiques
du cloud computing
Le cloud computing n’est pas un nouveau phénomène, contrairement à ce que le récent battage médiatique
entourant le concept pourrait nous faire croire.
44
Rubrique à brac
Économies d’échelle au-delà de l’ASP
À la base, le cloud computing correspond à une prestation de services de technologies de l’information
via Internet. Les utilisateurs de cloud computing n'ont pas besoin d'acheter ou d'installer des logiciels.
Les entreprises n'ont pas à exécuter leurs propres applications ou à faire tourner des serveurs de
données. Les prestataires de service de cloud computing hébergent des applications et fournissent
la puissance de calcul nécessaire en puisant dans leurs centres de données. Grâce à une bonne
mutualisation des moyens, ils bénéficient d'économies d'échelle considérables et réduisant de façon
spectaculaire les coûts de mise à disposition de ces services.
La raison de la récente hystérie des médias est en grande partie due au fait qu'il s'agit d'une tendance
croissante dans le sourçage des technologies de l’information qui, combiné avec les opérateurs du
Web 2.0, les sites de réseaux sociaux, les outils de collaboration et les technologies de virtualisation
de logiciels assurent la poursuite du développement du Web comme plate-forme clé du traitement
de l’information.
Le cloud computing est essentiellement un développement, une étape au-delà du modèle de fournisseur
d’applications hébergées (Application Service Provider - ASP) qui a été largement médiatisé vers
la fin du dernier millénaire. Une fiabilité accrue d'Internet et le développement de technologies de
chiffrement plus sophistiquées font en sorte que les sociétés sont davantage disposées et aptes à
s'intéresser plus sérieusement à l'offre de cloud computing, avec l'attrait particulier des réductions
de coûts qu'elle propose.
La nature du cloud computing signifie qu’un certain nombre de principes contractuels bien établis
en informatique, communs à de nombreuses juridictions, doit être réexaminé et exigera une analyse
constante et une remise en cause au fur et à mesure du développement et du raffinement de la technologie.
En outre, l'accroissement de la réglementation des affaires par l'intermédiaire de la protection des
données, de la loi Sarbanes-Oxley et de la directive relative aux marchés d’instruments financiers
constitue un défi pour les organisations qui cherchent à utiliser les services. Nous considérerons ici les
spécificités des dispositifs de l’informatique en nuage et nous examinerons les principales questions,
contractuelles et commerciales, auxquelles l'industrie est confrontée alors qu'elle tente d'intégrer le
cloud computing dans son utilisation quotidienne.
De quoi s’agit-il ?
Les définitions du cloud computing et du cloud lui-même varient en fonction de la personne que vous
interrogez. Toutefois, il est généralement admis que le cloud computing est constitué du logiciel en
tant que service (Software as a Service - SaaS), de la plate-forme en tant que service (Platform as a
Service - PaaS) et de l’infrastructure en tant que service (Infrastructure as a Service - IaaS). Et tous
impliquent la livraison de composants informatiques qui avaient été auparavant considérés comme
des produits ou des biens corporels (transactions) et d'une manière différente (relations). Le tableau
ci-après illustre les différents types de nuages qui sont disponibles.
Quel que soit le type de nuage utilisé, un certain nombre de caractéristiques communes aux services
s’en dégage :
• Libre-service à la demande : le client peut disposer automatiquement de capacités informatiques,
selon ses besoins, sans l’intervention du vendeur ;
• Ample accès au réseau : les capacités informatiques sont disponibles sur le réseau et accessibles
grâce à des mécanismes standard, à n'importe quel moment, n'importe où ;
• Mise en commun des ressources : les ressources informatiques du fournisseur sont mises en
commun pour desservir plusieurs clients en utilisant une configuration multitenant qui se traduit
par la réduction des coûts grâce à des économies d'échelle à effet de levier ;
• Modularité aisée : les capacités informatiques peuvent rapidement subir une extension (ou une
réduction) interne ou externe en fonction des besoins du client. Cela permet au client de réagir au
besoin en ressources sans prendre le risque qu’elles soient sur ou sous-dimensionnées ;
• Service mesuré (ou paiement selon l’utilisation) : l’utilisation des ressources du client peut être
suivie et contrôlée. En d’autres termes, le client paye pour ce qu’il utilise.
45
Nuage privé : l'infrastructure cloud n’est accessible
que par une seule organisation. Si les centres de
données sont partagés, les ressources matérielles
sont physiquement séparées entre les clients.
La communication peut se faire par l'Internet,
réseau dédié ou par réseau privé virtuel (VPN).
Infrastructure cloud
Nuage communautaire : l'infrastructure cloud
est partagée par diverses organisations ayant
des préoccupations communes, organismes publics,
banques, compagnies aériennes. Les clients consolident
leur pouvoir d'achat pour persuader les fournisseurs
de créer des services qui répondent à leurs besoins
commerciaux.
Client unique
Client 1
Client 2
Client 3
Nuage public : l'infrastructure cloud est partagée
par tous les membres abonnés. Les clients consolident
leur pouvoir d'achat pour persuader les fournisseurs
de créer des services qui répondent à leurs besoins
commerciaux. La communication se fait par l’Internet
public.
Client 1
Client 2
Client 3
Nuage hybride : l'infrastructure cloud est constituée
de deux ou plusieurs modèles de déploiement
qui restent distincts, mais qui sont reliés pour permettre
l'interopérabilité des applications. Ce rôle d'intégration
est essentiel et peut être effectué en interne ou
en externe. Ce modèle peut être utilisé par une société
qui considère que certaines applications sont plus
critiques ou sensibles que d'autres.
Services clouds publics
Clients
Services clouds
communautaires
Services clouds privés
Infrastructure interne
Les attitudes changent
Le cloud computing n'est pas une nouvelle notion : les marchés de consommation font usage du
cloud computing depuis un certain temps déjà, mais les grandes entreprises et organismes du
secteur public se sont montrés réticents à adopter le modèle. Cependant, les mentalités changent et
les grandes sociétés et les organismes du secteur public autrefois réticents envisagent maintenant le
cloud computing comme une option.
Le tableau ci-après tente d’illustrer ce changement d'attitude parmi les groupes du marché (du rouge
au gris) et met en évidence les caractéristiques du cloud computing qui sont les plus attrayantes pour
les différents groupes et organisations.
Consommateurs
Marché à maturité – coût faible ou aucun coût (financé par la publicité)
Flexibilité d’accès à la maison, au travail et en déplacement
Jeunes pousses
Élimine les barrières au démarrage (coût) et à la croissance (difficulté de mise
à l'échelle) qui auraient été rencontrées si une infrastructure IT sophistiquée
avait été nécessaire
PME
Permet aux employés de s’assumer : flexibilité et innovation
Coûts prévisibles : dépenses d’exploitation et non de capital
Grandes entreprises Rééquilibrage des profils de risque : réévaluation de ce qui doit être contrôlé
Utilisent des clouds privés ou à usage restreint pour en obtenir certains des
avantages
46
Multinationales
Flexibilité au déploiement mondial : augmentation de la réactivité du marché
Secteur public
N’est plus rouge suite à l’impératif de réduction des coûts
Clouds du service public et programmes de services partagés
Rubrique à brac
Les premières réticences étaient liées aux risques inhérents aux dispositifs du cloud computing.
Alors que les médias ont récemment souligné les avantages du cloud computing, des risques sont
inévitablement impliqués, comme pour tout régime d’externalisation ou d’informatisation. De même
qu’avec tout régime d’externalisation et/ou d’informatisation, c’est à l’acheteur de juger et de mettre en
balance ces avantages et ces risques dans le cadre de ses besoins particuliers et de l’accord particulier
en question. Le tableau ci-dessous indique les avantages et les risques les plus communément reconnus
et liés aux dispositifs du cloud computing.
Avantages
Risques
Faibles frais de service périodiques fixes
Les solutions non conçues spécialement
peuvent ne pas correspondre avec
précision aux besoins des entreprises et la
normalisation perd l'avantage concurrentiel
de l’excellence informatique
Assistance et maintenance améliorées :
le « Beta permanent »
Engagement contractuel à des conditions
standard fixes avec garanties, indemnités
limitées, etc.
Accès à n'importe quel moment, n'importe où
Manque d’intégration et de gestion
des anciens systèmes
Minimise les coûts d’investissement en matériel
Manque de contrôle des données et
du contenu
Faibles barrières à l’adoption : l’informatique
en nuage est conçue pour être conviviale et
minimiser les besoins spécifiques de formation
Risque d’être un client captif : une possibilité
de sortie doit exister (Entièrement du code
source et du code objet plus données ?
Comprendre les processus de transition)
Le soutien par la publicité peut réduire les coûts
d’autant
Risque élevé d'échec du prestataire de
services pour de nouveaux services en raison
de hauts coûts de démarrage et de faible
rendement initial
Les coûts de l’informatique en nuage devraient
diminuer au fil du temps avec l’accroissement
du nombre d’utilisateurs
Risque de suppléments cachés pour les
utilisateurs complémentaires, le stockage,
etc.
La normalisation forcée signifie que
l’organisation du l’informatique peut se
concentrer sur de véritables différenciateurs
pour son activité
Risque que le client ne parvienne pas
à contrôler l'utilisation ou l’accroissement
de stockage (aspect négatif du paiement
à l’utilisation)
Réduit les frais de gestion internes
Problèmes de conformité : protection des
données, chiffrement, loi Sarbanes-Oxley,
directive relative aux marchés d’instruments
financiers
IT « élastique » : peut s’étendre ou se réduire en
fonction des besoins
Complexité de souscription et de gestion
des accords de multi-sourçage
Fait partie du programme environnemental vert
des DSI et des directions de la communication :
les organisations peuvent externaliser leur
consommation carbone à des organismes en
mesure de gérer et de minimiser cet impact
Asservissement à la connectivité en ligne :
l'Internet est en passe de devenir un point
de défaillance unique pour de nombreuses
organisations : combien de temps une
entreprise pourrait-elle fonctionner en son
absence ?
47
Cloud computing versus externalisation
Le cloud computing et l’externalisation sont intrinsèquement différents (en termes de type de service
offert et de propriété des actifs utilisés pour fournir les services dans chaque cas) : c’est particulièrement
vrai lorsque vous considérez que les contrats de cloud computing sont essentiellement des contrats
de service plutôt que des licences de logiciels. Ce qui peut être considéré comme étrange, étant donné
les importants droits d'accès à un logiciel accordés dans le cadre d'un tel arrangement. Néanmoins,
le cloud computing est de plus en plus utilisé comme un ensemble d'outils pour l'externalisation des
services IT. Une utilisation courante se fait dans le cadre d'un accord multi-sourçage, où les organisations
utilisent le cloud computing comme un moyen d'y introduire de la flexibilité de telle sorte qu'ils peuvent
choisir les combinaisons, choisir les services qui répondent le mieux à leurs besoins globaux plutôt
que de se retrouver bloquées dans un accord multi-sourçage monolithique.
L'utilisation la plus courante du « cloud » sera hybride : lorsque les entreprises choisissent la solution
la plus appropriée selon différents scénarii du cloud public, elles construisent des clouds privés et
partagent également des services. D'autres organisations préfèrent toujours n’avoir qu’un seul prestataire
d'externalisation qui agit comme un « intégrateur de services » rassemblant un certain nombre de
services clouds différents (dans différents types d'environnement) et veille à leur intégration avec les
composants informatiques « non-cloud » et les systèmes anciens ou sur mesure appartenant au client.
Des caractéristiques distinctes d'un dispositif pour le cloud computing existent dans le contexte
d'externalisation. Par exemple, les prestataires de services de cloud computing sont en mesure de fournir
un niveau et une qualité d’assistance plus élevés par rapport à des applications logicielles particulières.
En général, ils ont le contrôle sur tout l'environnement d'exploitation. En tant qu'acheteur de ces
services, il faut cependant comprendre que, contrairement à un contrat d’assistance et de maintenance
typique, il est peu probable qu’un mécanisme de niveau de service et/ou de crédit de service existe.
Un autre aspect souvent négligé des dispositifs de cloud computing réside dans le risque de devenir un
client captif. Bien que la nécessité de dispositions de sortie ou de transition d’accords de sourçage IT
soit bien reconnue, il y a beaucoup moins de clarté dans le contexte des dispositifs de cloud computing.
De toute évidence, si une organisation doit malgré tout sauvegarder l’ensemble de ses données sur
ses propres serveurs pour s'assurer qu'elle y aura accès à la sortie de l'accord de cloud computing,
l’utilisation du cloud ne présente plus d’avantages, notamment en termes de réduction des coûts.
Principaux problèmes commerciaux et contractuels
Souscrire au cloud computing pose un certain nombre de questions juridiques qui lui sont propres et
sont donc différentes de la souscription à des produits et services informatiques traditionnels.
Bien que la question de la répartition des risques soit commune à tout contrat d’informatique traditionnelle,
le risque lié aux dispositifs de cloud computing est réparti différemment. En effet, les clients transfèrent
certains risques aux prestataires de services et en assument d'autres en interne. Il est donc essentiel
que tout contrat de cloud computing prenne en charge et intègre une répartition claire des risques
entre les parties.
48
Rubrique à brac
En fait, dans un dispositif de cloud computing certains estiment que le point de départ des deux parties
ne devrait pas être un contrat, mais plutôt un accord sur l’éventail des risques ou de l'équilibre recherché
des risques entre les parties dans le cadre de l'accord. Les fournisseurs seront désireux d’établir des
contrats types pour réduire les coûts, et de maintenir tous les clients « cloud » aux mêmes conditions.
Néanmoins, cela ne sera évidemment pas bien accueilli par les clients concernés, chacun cherchant
à transférer le risque différemment. Toutefois, dans la réalité, la négociation reste possible sur des
affaires de grande envergure. Et les fournisseurs doivent accepter que les clients aient des questions
légitimes quant à certaines des conditions tendancieuses disponibles sur le marché.
Idéalement, les conditions générales des fournisseurs devraient être suffisamment souples pour
permettre aux clients de sortir à relativement court terme d’un dispositif « cloud » et passer d’un
fournisseur de services à un autre.
Il a été soutenu que le comportement des clients sera influencé par la qualité du service, motivant les
fournisseurs à fournir un niveau de service aussi élevé que possible plutôt que de travailler selon des
niveaux de service définis dans un ensemble de conditions générales, dès lors et une fois de plus,
soutenant l'idée selon laquelle les contrats entre fournisseurs et clients ne sont pas nécessaires dans le
cadre du cloud. Selon notre analyse cependant, un certain nombre de questions juridiques continueront
à exiger une relation contractuelle entre client et fournisseur, indépendamment de la valeur ou de la durée
de la relation. Par exemple, les lois de protection des données en Europe exigent certaines garanties
à mettre en place lorsqu'il s'agit de données à caractère personnel. Dans un environnement où le
lieu de conservation ou de transfert des données n’est pas toujours clair, il est essentiel que le client
dispose d'une protection contractuelle. En France, par exemple, la réglementation sur la protection
des données exige qu'une copie du contrat en cause (envisageant le transfert de données à caractère
personnel) soit soumise au régulateur pour en autoriser le transfert.
Conclusion
Comme mentionné précédemment, la réalité est qu'un accord de services Cloud est peu susceptible de
fournir autant au niveau de la protection contractuelle qu’un accord de sous-traitance traditionnel. Les
clients doivent donc se fier davantage à la diligence raisonnable précontractuelle et à la gouvernance
postcontractuelle plutôt qu’au contrat lui-même.
Alors que, contractuellement, le cloud computing ne cadre pas forcément avec notre façon traditionnelle
et conditionnée de penser à de tels accords IT (sourçage ou autres), y compris la protection des données,
le cloud computing est là pour durer et continue de croître. C’est pourquoi nous devons, tout comme
les régulateurs, nous adapter. Et ce, rapidement. n
Sarah Pearce,
avocate, collaboratrice senior, Paris
Bird & Bird est un cabinet d’avocats international ayant pour particularité d’allier une solide expertise dans la plupart des domaines
du droit des affaires à une connaissance opérationnelle de nombreux secteurs économiques. Avec plus de 800 avocats et 21 bureaux
en Europe et en Asie (Bruxelles, Budapest, Bratislava, Düsseldorf, Francfort, La Haye, Helsinki, Hong-Kong, Londres, Madrid, Milan,
Munich, Paris, Prague, Lyon, Pékin, Rome Shanghai, Singapour, Stockholm et Varsovie), il dispose d’une capacité d’intervention étendue.
Les bureaux français (Paris et Lyon) rassemblent aujourd’hui près de 90 avocats dont 21 associés.
Site web : www.twobirds.com
49

Pourquoi et comment déployer une Gouvernance des contenus

Transcription

Documents pareils

Consultants EAI/SOA/Urbanisation (H/F)

SERVICE ORIENTED ARCHITECTURE SERVICE ORIENTED

Système d`Information

Simplivity-HISI Case Study

Travail sur un ancien et nouveau site Web

Activités de test externalisées : 5 conseils pour - IT

SAP Confidential Page 1 of 1 SAP Time and Attendance

Cloud computing ou l`informatique dans les nuages Les points de

Architecte de solutions

IBM SOA Infrastructure Consulting Services – stratégie et

PRODUCT NAME HEAD

ana rewakowicz

Table des matières

Les DSI et la téléphonie dans le Cloud

Corporate Performance Management solutions for Mid

La communication migre dans le Cloud