PAGE 6
SharePoint Workspace 2010 :
au cœur de la collaboration Microsoft
PAGE 26
L’automatisation dynamisera
Mission Critical Messaging
PAGE 32
L’expérience utilisateur enrichie
PAGE 16
ZOOM OUTSOURCING
L’avis des directions informatiques
Ministère des Finances Direction Générale des Impôts Nadine Chauvière
Sous-Directrice des SI de la DGI
« Les solutions d’Application Intelligence CAST nous aident à obtenir une meilleure visibilité de notre parc applicatif au travers de tableaux de bord composés d’indicateurs techniques objectifs afin de faciliter le dialogue avec les équipes et avec nos maîtrises d’ouvrage. »
Groupe SFR Cegetel Eric Eteve
Directeur Informatique Centre Ingénierie Mobilité
« La solution CAST de gestion de la sous- traitance est un élément clé dans le système de pilotage mis en place par SFR-Cegetel sur ses TMA. Nous avons constaté une attention plus particulière apportée par les SSII à la qualité des livrables et à la fiabilité des chiffrages depuis qu’ils savent que nous pouvons facilement les auditer. »
Framatome - Groupe AREVA Michel Fondeviole
DSI de Framatome-ANP
« CAST fournit des critères objectifs d’appréciation dans le dialogue parfois difficile avec le sous-traitant ainsi que des indicateurs nécessaires au suivi de l’évolution des applications et constitue au sein de Framatome un outil de progrès partagé. »
en savoir pLus
demandez le Livre Blanc rédigé par le Gartner Group et cast sur ce thème :
« information series on application management » :
www.castsoftware.com/outsourcing découvrez l’expérience de plusieurs sociétés utilisatrices de solutions d’application intelligence :
www.castsoftware.com/customers
de la valeur ajoutée de l’application intelligence pour piloter efficacement un parc applicatif sous-traité
La maîtrise des applications et des prestataires dans
une opération d’outsourcing
L
es entreprises, devenues plus mûres vis-à-vis de l’outsourcing, sont désormais capables d’opérer des externalisations plus stratégiques. on l’a récemment observé dans l’automobile avec renault ou dans la grande distribution avec carrefour.dans l’externalisation des applications métier, c’est surtout la volonté d’accroître l’efficacité opérationnelle de l’informatique qui est motrice : pouvoir fournir plus rapidement un service à valeur ajoutée aux utilisateurs et aux clients dans un contexte en perpétuelle évolution.
comme dans n’importe quelle opération d’outsourcing, le contrat liant le fournisseur est capital, en particulier les sLas. néanmoins, les applications métier étant par nature soumises à de fréquents changements en cours de contrat, les seuls sLas se révèlent vite insuffisants pour garantir la qualité de service et éviter les dérives de coûts.
c’est là que le bât blesse : l’externalisation des applications métier occasionne un risque de perte rapide de savoir-faire technologique et par conséquent critique.
vigilance et suivi sont de mise pour garder le contrôle de la qualité de service et éviter les dépendances par nature dangereuses.
L’externalisation réussie d’applications métier est donc le fruit d’une vision anticipatrice partagée avec le prestataire.
sont ainsi apparues des solutions dites d’application intelligence, basées sur
une technologie avancée d’analyse de code source.
en fournissant des indicateurs techniques aux donneurs d’ordre, ces solutions permettent de piloter un parc applicatif sous-traité en temps réel, tant en terme de qualité, que de maintenabilité et de coût.
résultat : le donneur d’ordre conserve la maîtrise intellectuelle de ses applications métier et le contrôle de la relation avec son sous-traitant.
La valeur ajoutée de ce type de solutions d’application intelligence est visible à chaque étape d’une opération d’outsourcing, comme décrit ci-après.
audit de l’existant et préparation des appels d’offres
• Déterminer les caractéristiques techniques du portefeuille applicatif existant avant de le sous-traiter
• Disposer d’informations de référence pour évaluer les propositions des sous- traitants
• Obtenir une image à l’instant t des applications pour permettre un suivi dans le temps
transfert vers le prestataire
• Réduire la phase d’acquisition de la connaissance pour entreprendre plus vite des tâches productives
• Diminuer le coût lié à la production d’une documentation exploitable et maintenable par le prestataire contrôle de la qualité et des coûts en cours de projet
• Suivre l’évolution de la maintenabilité et de la qualité pour éviter toute dérive
• Etre capable de valider la quantité et la qualité du travail facturé
• Etre en mesure de challenger le sous-traitant lors des négociations d’avenants
• Industrialiser les recettes techniques renouvellement de contrat, transfert ou ré-internalisation
• Déterminer et qualifier les écarts entre la prestation prévue et les livrables recettés
• Disposer des informations techniques caractéristiques du portefeuille applicatif en fin de prestation
Le leader mondial de ce type de solutions est d’ailleurs un éditeur français, cast.
reconnu par les analystes informatiques comme précurseur du marché, cast compte plus 500 comptes utilisateurs de sa plate-forme d’application intelligence dans le monde.
Cycle de vie d'une opération
d'Outsourcing
Suivi de projet Contrôle des coûts
Transfert cesdesan connais
Fin de contrat Appels d'offres
Recette techni
que
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 : redaction@it-expertise.com Rédacteur en chef
José diz
email : j.diz@it-expertise.com Directeur de publication aurélie magniez
email : a.magniez@it-expertise.com Abonnements/Publicité
email : abonnement@it-expertise.com Conception Graphique
nicolas Herlem
email : nico_freelance@yahoo.fr 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 e. Avertissement
tous droits réservés. toute reproduction intégrale ou partielle des pages publiées dans la présente publication sans l’autori- sation é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/
abonnements/default.aspx ou nous écrire à :
abonnement@it-expertise.com
Des nuages plus épais qu’il n’y parait…
Le cloud computing bouleverse la donne sur le marché logiciel, et cela ne fait que commencer ! après les succès de salesforce.com, amazon et Google, microsoft et iBm – entre autres – ont rapidement pris le train en marche. néanmoins, les abonnements à un service en ligne viennent bousculer le modèle bien établi de ventes de licences annuelles, plus la maintenance, plus, plus plus… forcément moins chers, ces abonnements procurent toutefois des revenus récurrents qui se révèleront finalement très payants. question de temps…
Le plus grand bouleversement pourrait pourtant toucher d’autres acteurs : les prestataires de toute sorte. en effet, le cloud sonne la fin – ou presque – des prestations d’installation, de déploiement, et de maintenance logicielle, etc. de même, les partenaires des éditeurs devront proposer des prestations à réelle valeur ajoutée pour subsister. en la matière, un peu de ménage sera certainement salutaire. et ne parlons pas de nombre de prestations en régie, de complaisance ou d’aveuglement…
en revanche, quelle chance pour des prestataires à valeur ajoutée ! un marché plus vaste sans effort, finis les maintenances matérielles ou liées au middleware, la gestion de versions… et mieux encore : moins de risque à assumer avec des applications hébergés sur les plates-formes de grands éditeurs. si certains modèles économiques demandent à être affinés, il semble bien qu’une nouvelle ère s’annonce. alors, autant s’y préparer plutôt que de commencer à gémir ou à nier l‘évidence !
José Diz rédacteur en chef
édito
6 Dossier
Le maintien en condition opérationnelle : un enjeu majeur sous-évalué
après mise en production d’une application, l’entreprise doit en assurer la pérennité.
et les impacts de cette maintenance (mco) touchent le système d‘information et les utilisateurs, mais aussi les équipes de maintenance et de projet. d’où la nécessité de l’organiser en amont pour piloter au mieux le cycle de vie de l’application.
16 Technique
L’expérience utilisateur enrichie
L’explosion des technologies dites Web 2.0 ou ria explosent et engendre parfois une dispersion préjudiciable. sites internet institutionnels ou avec accès aux données, portail Web, client lourd… mathieu Lombard, spécialiste de ces questions chez sopra Group, explique quels choix se prêtent le mieux pour répondre à chaque besoin.
22 Actualités Internationales
Les informations marquantes d’éditeurs, de marchés, d’organisme de standardisation, de débats en cours et de tendances.
26 Quoi de neuf docteur ?
SharePoint Workspace 2010 : au cœur de la collaboration Microsoft
client riche – éventuellement déconnecté – et personnel pour sharepoint 2010, le successeur de Groove arrive enrichi dans la future version de la suite office. mécanismes de synchronisation, collaboration multiple et multimodes… plongez au cœur de ce nouvel outil aux multiples facettes.
32 Comment ça marche ?
Mission Critical Messaging
dans la famille middleware, le mcm vise à assurer une connectivité ouverte entre les plateformes et les systèmes. découvrez comment diverses technologies se combinent pour favoriser l’interopérabilité : « Store and forward », « Request / Reply »,
« Publish / Subscribe », « Broadcast », « Multicast » et le pGm « Pragmatic General Multicast ».
37 Livres
Concevoir et déployer ses sites web avec Drupal, par Yoran Brault et Scrum : Le guide pratique de la méthode agile la plus populaire par claude aubry.
38 Fenêtre sur cour
L’automatisation dynamisera probablement l’adoption des points de fonctions
mike Harris, pdG du Groupe david consulting, explique comment l’analyse des points de fonctions permet de mesurer l’envergure, la taille et les délais des projets. autant de défis stratégiques et complexes pour les dsi cherchant à optimiser la gestion de leurs applications.
Sommaire
Dans la gestion des systèmes d’informations, les projets bénéficient bien souvent d’une meilleure visibilité que les applications, du fait des nouveautés apportées, des impacts qu’ils auront sur les utilisateurs au moment du déploiement… Du cadrage projet à la mise en production, les méthodes de gestion de projet sont aujourd’hui bien ancrées dans l’organisation des DSI avec toute la panoplie d’outils et d’indicateurs associés. Le passage en maintenance de l’application mérite souvent, lui, d’être plus préparé.
Le maintien
en condition opérationnelle :
un enjeu majeur
sous-évalué
Une préoccupation encore trop sous-estimée
Les deux constats suivants permettent d’illustrer la sous-estimation de l’importance du mco (maintien en condition opérationnelle) des applications :
• Une gestion de portefeuille des projets SI (ou PPM pour Projet Portfolio Management), souvent outillée, s’est par exemple fortement développée dans la plupart des entreprises ces dernières années. en revanche, on rencontre rarement des dsi ayant mis en œuvre une démarche de gestion du portefeuille d’application partagée (ou apm pour application portfolio management).
• Les référentiels de gouvernance et de bonnes pratiques pour les processus de la DSI se sont fortement développés au cours de la dernière décennie, mais ils ne couvrent pas de façon claire et homogène l’ensemble des activités que devra gérer un responsable de la maintenance d’une application. L’approche cmmi couvre bien les processus de développement, mais plutôt pour de gros projets. et si itil couvre effectivement la mise à disposition d’applications existantes, il concerne plutôt la partie production et non la maintenance évolutive. enfin, cobit propose une vision « macro de la dsi », avec une implication du responsable de la maintenance éclatée sur plusieurs des 34 processus au sein les domaines « planifier et organiser », « acquérir et implémenter », « délivrer et supporter », « surveiller et évaluer ».
La complexité et les enjeux du mco d’une application sont ainsi souvent sous-estimés : une fois le projet terminé et le système mis en production, le gros du travail est terminé !… pourtant, une fois l’application ouverte aux utilisateurs, reste à en assurer la stabilité et la pérennité. cette sortie parfois brutale du « mode projet » implique de nouveaux engagements, de nouveaux acteurs, de nouvelles contraintes… et tout l’enjeu devient alors de mettre en place l’organisation et les outils qui permettront de sécuriser la production tout en prenant en compte les besoins des nouveaux utilisateurs.
Les problématiques du maintien en condition opérationnelle d’une application, et a fortiori d’une grosse application, sont à prendre en compte à la fois par le responsable de la maintenance, mais aussi par le chef de projet, qui doit anticiper de nombreux points pour assurer la délivrance d’une application qui soit gérable par la suite.
Du projet à MCO : de forts déséquilibres à anticiper
après mise en production de l’application, les changements apportés feront l’objet de versions (lots d’évolutions ou de corrections). chacune de ces versions peut être vue comme un projet. et plusieurs d’entre eux sont menés en parallèle par les mêmes ressources. une situation qui engendre une organisation matricielle, avec des contentions sur les ressources et les environnements, mais aussi des problématiques supplémentaires à celle d’un projet unique.
en mode maintenance, les relations entre les différents acteurs évoluent, avec un rééquilibrage de l’implication des différents acteurs, et un niveau de complexité supplémentaire :
• En mode projet, les principaux échanges ont lieu entre MOA, AMO et MOE (équipes de développement/
intégration) avec des pics de relation avec les utilisateurs sur la conduite du changement, mais aussi des sollicitations ponctuelles du futur exploitant-hébergeur.
• En mode maintenance, les relations sont plus équilibrées entre l’ensemble des acteurs : MOA, AMO, moe (équipes de maintenance), exploitant-hébergeur et avec les utilisateurs.
chaque acteur de cet ensemble a souvent une représentation déformée de l’importance de l’application.
ainsi, un bon exercice pour le chef de projet puis le responsable de la maintenance consiste à s’imaginer régulièrement « à la place de chacun des autres acteurs », d’appréhender ses enjeux et de visualiser le projet ou l’application sous cet angle. L’exploitant est-il informé de l’arrivée prévisionnelle de 100 nouveaux utilisateurs qui auront certainement un impact sur les performances ? Le métier est-il sensibilisé aux impacts du futur renouvellement de tma et notamment de la période de ralentissement de la maintenance évolutive ? L’utilisateur est-il informé de l’impact des prochaines livraisons sur son travail le jour de la livraison et par la suite ?…
Nouveau contexte, nouvelles activités, nouveaux acteurs, nouveaux enjeux
autre problématique, le turn-over des équipes. en fin de long (trop long ?) projet, de nombreux participants ont changé de poste, les équipes des prestataires ont été renouvelées et les effectifs sont souvent réduits après la mise en production. si le responsable projet et le responsable mco sont différents, une phase de transfert de plusieurs mois est à privilégier avant le démarrage du mco. il est aussi indispensable que le responsable projet et responsable maintenance identifient en amont les ressources clefs et s’assurent du maintien d’un minimum de ces dernières par rapport à toutes les problématiques à traiter sur les premiers trimestres suivant la mise en production. enfin, il est souhaitable d’anticiper l’impact d’un éventuel changement de sponsor ou d’un transfert de responsabilité du donneur d’ordre. Les difficultés générées par le turn-over des équipes sont importantes au démarrage, mais perdureront toute la vie de l’application si elles ne sont pas correctement prises en compte.
une différence notable porte également sur l’équilibre entre « applicatif » et « donnée ». en mode projet, dans la majorité des cas, « l’énergie » est surtout consacrée à l’applicatif (interface utilisateur et traitements), même s’il existe des problématiques d’initialisation et de reprise de données. en configuration mco, un équilibre nouveau est à trouver entre les activités consacrées à la gestion de l’applicatif et celles consacrées à la gestion des données (analyses, mises en qualité, traitement de rejets…). il peut en résulter la prise en compte dans l’activité de maintenance d’un nombre important de « chantiers », avec un planning spécifique et indépendant des versions.
enfin, dans ce nouveau contexte, le nombre de processus récurrents nécessitant une gestion « au fil de l’eau » s’avère plus important qu’en mode projet. La collection des outils de pilotage du chef de projet (planning, plan de charge, gestion des risques…) reste pertinente, mais sera à compléter par des outils d’un responsable d’« activité » : indicateurs de pilotage par les processus, tableau de bord…
Identifier les activités-clés de la maintenance
sur de petites applications, le pilotage de la maintenance peut en général être réalisé par une équipe de quelques personnes. certaines activités, certains flux de communications, se font de façon informelle sans parfois même avoir été identifiés. sur des applications plus conséquentes, la gestion des différentes activités nécessite la mise en place d’équipe(s) dédiée(s) couvrant l’ensemble des fonctions, comme l’illustre le schéma suivant. La vision des activités n’est pas la même pour l’ensemble des acteurs, et le schéma est orienté « responsable de la maintenance », coordinateur entre les utilisateurs, la moa, la moe en charge des développements, l’exploitant. ainsi, les fonctions associées au développement, à l’exploitation… ne sont pas développées.
Projet Versions
Réalisation Tests et corrections Conduite du changement Spécifications
Recette
Projet Equipe(s) MOA-MOE
MOA MÉTIER
Exploitant
Intégrateur
Utilisateurs
Mise en œuvre Installation et gestion des environnements
soit interne
soit externe
Corrections des anomalies Traitements des demandes d’évolutions Gestion des versions
Suivi alertes Traitement rejets Gestion référentiels Cohérence fonctionnelle Gestion utilisateurs Gestion
des demandes Assistance
Maintenance Equipe(s) MOA-MOE
MOA Experts
Cellule de support et soutien
Exploitant hébergeur
Cellule d’administration
Mainteneur
Utilisateurs
Supervision & gestion des environnements Sauvegarde et PRA
Arbitrage fonctionnel
soit interne
soit externe
D’une organisation très linéaire Métiers – Maitrise d’ouvrage – Maitrise d’œuvre, on passe à des flux d’informations croisés entre des équipes remaniées dont les objectifs divergent.
Plan d’Occupation des Sols en mode maintenance
après le démarrage, il ne faut pas négliger la charge correspondant aux « nouvelles fonctions » à couvrir en mco, en particulier pour la « conduite applicative » sur une application qui n’est pas encore mature : assurer le bon fonctionnement au quotidien de l’application, en particulier des traitements par lot (batchs) avec une collaboration de tous les acteurs (y compris métier). on constate parfois des contextes où le fonctionnement en 2x8 avec astreintes du métier en soirée et week-end, prévues pour 2 ou 3 semaines après le démarrage d’une application est prolongé de nombreux mois…
Exemple de répartition type de l’activité en mode maintenance d’une grosse application (plusieurs dizaines de personnes en MOA)
Il est possible de s’appuyer sur le plan d’occupation des sols en mode maintenance pour s’assurer de la complétude de la couverture fonctionnelle en définissant son organisation.
Activités 39%
Chantiers :
instructions de dossiers fonctionnels transverses Versions :
préparations, instruction, tests des trains de maintenance
Activités :
travaux spécifiques liés au mode de maintenance (support utilisateurs, administration fonctionnelle…), pilotage, suivi de production
Versions 38%
Chantiers 23%
RÈfÈrentiel
des donnÈes Pilotage du MCO díune application Gestion
transverse Pilotage
Fonctions support au pilotage
MCO
´ Fournisseurs ª Maintenance du code
et des données Exploitation technique et supervision des traitements et infrastructures Stratégie
Pilotage des demandes d’évolutions et périmètres
Pilotage des versions
évolutives et correctives Pilotage de la qualité des données Pilotage de chantiers
hors versions Gestion des changements en production (ITIL)
Gestion des mises en production (ITIL) Gestion des niveaux
de service (ITIL)
Gestion financière (budgets et coûts) Achats Gestion contractuelle
Gestion RH
Processus internes, méthodologie
et qualité
Sécurité
Gestion des risques,
Audits et contrôles plannings et plans
de charge
Gestion des
environnements Gestion de la disponibilité et capacité (ITIL)
Gestion de la continuité de service (ITIL) Cohérence fonctionnelle
Organisation, gouvernance, instances
Communication
Veille règlementaire Chantiers d’amélioration
du fonctionnement (outillages,...)
Modifications des applications et donnÈes
Maintien du systËme en production Expressions des
besoins Conception
générale Recette Conduite
du changement Gestion documentaire
Tableaux de bord et reporting
Gestion de configuration
Conception détaillée
Veille techno
… Administration fonctionnelle des traitements/
Conduite applicative Service center / support utilisateurs
(niveaux 1 à n) (ITIL) Gestion des incidents
(ITIL)
Administration fonctionnelle des données et référentiels Gestion des habilitations
Gestion des
problèmes (ITIL) Formation continue
Appui à l’activité métier liée au système
Mise en œuvre plan de reprise/continuité d’activité Base
de données de configuration
(CMDB) Documentation
Utilisateurs Budget Ressources
humaines Demandes d’évolutions Anomalies
La majorité des fonctions représentées n’existeraient pas ou seraient moins développées dans un POS représentant les fonctions à couvrir en mode projet.
Repenser ou compléter l’organisation
La diversité des activités de mco pose des questions d’organisation. Les principes itil apportent ici un éclairage intéressant : distinguer les responsabilités sur la gestion des incidents et sur la gestion des problèmes et mettre en place des niveaux d’assistance en réponse aux sollicitations extérieures, en faisant en sorte que la grande majorité des sollicitations puisse être traitée par le niveau 1 (à l’aide d’une base de connaissance…). ainsi les experts fonctionnels ou techniques ne seront sollicités qu’à bon escient.
en fonction du contexte et de la taille de l’application, l’entreprise pourra mettre en place des cellules dédiées à certaines fonctions :
• Une cellule d’assistance utilisateur (ou à la relation avec l’assistance utilisateur de niveau 1 s’il existe un premier niveau d’assistance transverse aux différentes applications)
• Une cellule de cohérence fonctionnelle en charge de la préinstruction des demandes du métier, d’une veille règlementaire…
• Une cellule de type PMO (« Project Management Office » ou « Bureau programme »), en charge de la gestion des plannings, plans de charge, mais potentiellement également de la gestion documentaire globale, de la qualité, du contrôle interne, de la communication, de la gestion budgétaire…
• Une cellule d’experts techniques, en capacité d’instruire des dossiers en relation avec la maîtrise d’œuvre, de challenger des chiffrages…
• Une cellule d’« administration fonctionnelle » (ou d’« administration des données ») : gestion des référentiels, analyses, pilotage de plan d’action de mise en qualité des données…
• Une cellule dédiée à l’administration des utilisateurs (y compris des actions de revues de comptes permettant de répondre aux audits).
• Une cellule dédiée à la gestion transverse des environnements (recette, production, préproduction…), assurant l’interface et la coordination entre les équipes d’assistance à la moa et l’exploitant,
• …
La mise en place de telles entités en complément de celles en charge des processus principaux (spécifications, réalisation, recette…) permet de désigner clairement des responsables sur des processus
« au jour le jour » et d’assurer le bon fonctionnement global.
Exemple d’organisation d’un point de vue utilisateurs (avec les niveaux de la chaine de soutien)
Bonnes pratiques ITIL et bon sens
Afin de pouvoir sortir du « mode pompier permanent », il est impératif de distinguer la fonction de « gestion des incidents » (rétablir le service au plus vite) de celle de
« gestion des problèmes » (résoudre à plus long terme la cause des incidents).
Il est également envisageable, voire souhaitable (en fonction de la volumétrie), de prévoir dès le démarrage un dispositif dédié à la résolution des anomalies résiduelles qui n’étaient bloquantes pour le démarrage, mais qui, par nature, n’entrent pas non plus dans le processus de maintenance corrective non dimensionné à cet effet.
Pour cette double problématique, dédier des ressources à chaque fonction ou problématique n’est pas l’unique solution, l’essentiel est de bien identifier les sujets et les responsabilités puis d’estimer au mieux les charges correspondantes.
UTILISATEURS
Helpline
Maintenance à chaud (corrections urgentes) Maintenance à froid
Correction / Evolution / Recette Exploitation / Supervision Gestion des environnements
Expertise par domaine Recette
à chaud Cellule d’administration
fonctionnelle et technique
Conseillers utilisateurs spécifiques
Pilotage
NIVEAU 1NIVEAU 2NIVEAU 3Socle TechniqueCohér ence fonctionnelle
enfin, il convient de se pencher sur l’évolution des « cellules existantes ». en effet, l’entreprise devra faire évoluer les dispositifs de conduite du changement en capitalisant sur les acquis :
• La chaine de soutien utilisateur prévue pour le démarrage disparaîtra progressivement avec la stabilisation de l’application, la montée en compétence des utilisateurs, mais aussi de la cellule d’assistance téléphonique. La durée de maintien des dispositifs projet étant souvent figée, les transferts de connaissances doivent être optimisés.
• Les relais métiers identifiés au sein de l’organisation pour toute la phase projet tant au niveau des spécifications, de la recette utilisateurs que de l’accompagnement local doivent être mis en valeur et fidélisés au sein d’un réseau d’utilisateurs aux missions potentiellement multiples : relayer les besoins métier auprès des équipes de maintenance, expliquer aux utilisateurs les évolutions de l’organisation et les contraintes associées, être un des vecteurs de communication et de conduite du changement pour la mise en place des futures évolutions du système…
Identifier en amont et maintenir des ressources clefs du projet, et mettre en place un réseau ou club utilisateurs après démarrage doivent constituer deux réflexes importants pour le maintien des compétences sur les premiers mois de vie de l’application.
Identifier toutes les activités à assurer permettra de définir une organisation appropriée, couvrant l’ensemble de ces sujets, nouveaux ou non, l’expérience montrant qu’il n’y a pas forcément de sujets moins importants que d’autres.
Organiser l’activité, planifier les livraisons
fondées sur le souci de s’adapter rapidement à la stratégie mouvante de l’entreprise, les exigences actuelles d’agilité engendrent une évolution permanente des systèmes d’information et pas seulement d’un point de vue « réglementaire ». La maturité de l’application mise en production se mesure aussi selon sa capacité à s’intégrer dans le si de l’entreprise et à répondre aux exigences des autres applications internes ou externes.
TypoLogie DeS aCTiviTéS De mainTenanCe en fonCTion De Leur origine
maintenance corrective elle consiste à corriger les dysfonctionnements, bogues ou erreurs. une erreur s’analyse comme une différence entre les spécifications fonctionnelles et les résultats effectivement obtenus à l’usage.
par extension, on pourra y inclure la maintenance préventive qui a pour principal objectif d’anticiper la correction d’anomalie et donc de diminuer la charge de la maintenance corrective. La maintenance préventive consiste principalement à enrichir le code avec des mécanismes de traitement d’exception corrective (création d’applications de détection et de remise à niveau des incohérences, entretien de la documentation, entretien des jeux d’essais…). elle est destinée à permettre une utilisation optimale de l’application.
maintenance évolutive elle a pour objet la modification des missions spécifiées de l’application afin d’être en concordance avec les évolutions fonctionnelles et réglementaires (fiscalité, législation…). en fonctionnement normal, elle répond aux souhaits des utilisateurs ou des concepteurs en termes d’étendue fonctionnelle.
par extension, on pourra y inclure :
• La maintenance adaptative, qui consiste à modifier une application afin de l’adapter aux changements du système d’information et d’environnement technique (modification des interfaces de l’application, changement du système d’exploitation…). elle survient en réponse à des exigences externes.
• La maintenance perfective, qui consiste à optimiser le fonctionnement de l’application sans en changer les missions spécifiées. son objectif est l’amélioration de la qualité et des performances de l’application ou la facilitation de la maintenance. elle survient en réponse aux souhaits des utilisateurs ou des concepteurs en termes de qualité de service.
Le maintien en conditions opérationnelles (MCO) couvre usuellement les différentes activités de maintenance ainsi que toutes les problématiques de support utilisateurs, d’administration de données et référentiels, de gestion des habilitations, de conduite applicative et de continuité d’activité voire de formation continue (cf. POS)
Les différentes sources d’activités de maintenance applicative dont découle la typologie traditionnellement retenue des activités de maintenance (cf. tableau) montrent la nécessité d’être attentif aux besoins des différents acteurs (utilisateur comme exploitant), de les anticiper et de les planifier.
comme en mode projet, la prise en compte tardive d’un besoin implique une consommation de ressources et de temps supérieure. c’est pourquoi la planification des premiers mois doit permettre de trouver le bon équilibre entre :
• la résolution des anomalies liées à la production remontées par les utilisateurs et le traitement des incidents de production identifiés par l’exploitant,
• la résolution des anomalies résiduelles liées aux contraintes projet avant mise en production considérées comme non bloquantes pour la mise en production et les évolutions réglementaires gelées les derniers mois avant mise en production,
• liés à la vie de l’application proprement dite, les évolutions fonctionnelles (réglementaire ou non), préventives, adaptatives, perfectives…
pour cette planification, la construction des « trains de maintenance » embarquant ces différents sujets (cf. encart) devra intégrer l’effet de « sédimentation » des versions : une première version suite à la mise en production en phase de recette, une seconde en phase de conception détaillée, une troisième mineure lotie tout en travaillant à une future version majeure à longue échéance… Le rythme de croisière avec une implication équilibrée sur les différentes versions est complexe à trouver tant que le « versionning » est alourdi par la diversité des types de livraisons. ainsi, sur un projet pour traiter les différentes problématiques en fonction de l’urgence (besoin exprimé par le client) et la complexité de mise en œuvre (contrainte exprimée par le mainteneur), nos équipes avaient défini trois types de livraisons. Les principales livraisons planifiées trimestriellement (« trains de maintenance » ou livraisons
« à froid ») devaient intégrer les reports des livraisons mensuelles (« à tiède ») qui, elles-mêmes, intégraient les reports d’éventuelles livraisons « à chaud » intermédiaires.
dans la période suivant la mise en production de l’application, la tentation est grande de se laisser embarquer dans un flot de versions successives (pression métier forte) et de s’éloigner des objectifs de versionning fixés initialement pour la phase de maintenance. plus cet écart est important, plus il sera difficile ensuite de faire accepter au métier un retour au rythme initialement planifié.
Les premiers mois de production peuvent être synonymes de nombreux besoins de « trains de maintenance » (corrections et évolutions toujours urgentes !). Pourtant, la diversité et la multiplicité des livraisons complexifient de fait la gestion des environnements, les tests (en particulier ceux de non-régression) et, de fait, la maîtrise globale de l’application.
Mettre en place des trains de maintenance
Bien définir ses priorités est un prérequis à la construction efficace des différentes versions et de leur livraison sous forme de trains de maintenance. a ce sujet, les pratiques sont aussi nombreuses qu’il y a de projets. Les deux principaux entrants permettant de typer les versions sont :
• la charge et de la complexité de réalisation ;
• l’urgence (au sens métier) des corrections ou évolutions.
sur cette base, avec éventuellement d’autres entrants moins structurants (capacité à recetter, saisonnalité du besoin…), on définira ainsi classiquement des versions « mineures » (cycles courts de quelques mois contenant du petit évolutif) et des versions « majeures » (cycles plus longs, supérieurs à 6 mois et contenant des évolutions plus « lourdes »). Les corrections d’anomalies sont traitées le plus souvent avec le même phasage en « trains de maintenance », mais il est souvent nécessaire d’ajouter des véhicules intermédiaires permettant de traiter les cas « urgents » (anomalies de production non détectées en recette).
il est nécessaire de partager très en amont les priorités, délais et autres contraintes de chaque développement embarqué de sorte à gérer au mieux le moment venu les éventuels débords soit par report de la livraison, soit par restriction du périmètre. sur ce sujet comme sur tout projet, le mieux est de prévoir pour chaque livraison une marge de manœuvre pour traiter les imprévus et, si ceux-ci s’accumulent, il faudra, a minima, capitaliser pour mieux « dimensionner » les trains suivants.
pour définir au mieux les plannings de livraisons, voici quelques exemples de contraintes à prendre en compte :
côté métiers
et/ou maîtrise d’ouvrage :
• Respect des engagements conjointement définis lors du lotisse- ment du train de maintenance
• Respect des contraintes légales ou « entreprise » (pressions métier pour intégration d’évolutions urgentes dans une version souvent non adaptée)
• Chevauchements restreints sur les phases amont (études, spécifications) entre les versions (risques de confusions, problèmes de priorisation, difficultés de prises en compte du changement de besoin durant la version « n » dans la version « n+1 »…)
• Chevauchements restreints sur les phases de recette – préparation en particulier – (risques accrus de retard, problèmes de priorisation entre les validations : effet « domino » en cas de décalage de la mise en production, problèmes de mise à jour des versions sur les environnements…)
• Chevauchement restreint entre les phases amont et les phases de recette précédemment citées : ce sont souvent les mêmes acteurs ou les mêmes experts qui sont sollicités !
• Calage des phases critiques (validation spécifications, installations…) hors période critique de production (clôture mensuelle, paie, inventaire annuel,…) mais aussi hors congés et ponts !
côté technique et/ou maîtrise d’œuvre
• Aucun chevauchement entre phases de développement/
d’intégration entre les versions ou gestion contrainte et limitée de report entre versions,
• Tuilage restreint entre la rédaction des Spécifications détaillées et leur validation (remontées d’impacts d’une sfd en cours de finalisation sur une sfd déjà validée…)
• Respect des ratios phases de réalisation/intégration…
• Prise en compte des contraintes techniques (plateformes partiellement mutualisées ?) et humaines (ressources mutualisées ?) d’exploitation de l’application et de l’ensemble du système d’information
Un tableau de bord pour piloter le MCO
Étant donné la multiplicité des activités de mco, il est nécessaire pour le responsable de la maintenance de mettre en place très rapidement de bons indicateurs avec des objectifs aussi « smart » (spécifique- mesurable-atteignable-réaliste-temporellement défini) que motivants pour les équipes en charge de la maintenance.
Évidemment, pour suivre les opérations de mco, il faut mettre en place des indicateurs pertinents pour chaque processus :
processus exemples d’indicateur
Gestion des incidents • Délai de diagnostic du problème et/ou d’identification d’une première solution
• Nombre annuel d’anomalies bloquantes en production sans solution dans les délais définis
Gestion des problèmes • Délai de correction des anomalies (en fonction de la criticité de cette dernière)
• Nombre de livraison unitaire pour une anomalie instruction des demandes d’évolutions
réalisation des évolutions
• Délai d’instruction (en fonction de l’urgence)
• Respect des délais définis lors de l’instruction
• Nombre de livraison unitaire pour une évolution
Livraison • Complétude des livraisons
• Acceptabilité des livraisons (si tests d’acceptabilité fournis en amont) support utilisateur • Délai de réponse aux demandes de l’assistance utilisateur
• Délai de communication sur les incidents de production suivi global de la maintenance • Respect des délais de livraison des livrables de pilotage
• Adéquation des profils proposés pour les activités en régie (en se basant par exemple sur la nomenclature ciGref des emplois-métiers du si)
exploitation • Délai de remontée d’information d’incident en production détectée par la supervision
• Taux d’indisponibilité annuel
• Dépassement du délai de reprise d’activité (en période normale ou en période critique/rouge/…)
au-delà, d’autres indicateurs permettent aussi de communiquer sur la stabilisation et la maturation de l’application :
• le nombre d’appels utilisateurs enregistré par la cellule d’assistance
• le nombre et le délai d’instruction des demandes d’évolutions
• l’amélioration de la qualité globale de l’application : mesure mensuelle du rapport entre le nombre d’anomalies détectées en production sur le mois et le nombre moyen mensuel d’anomalies détectées en production sur les 12 derniers mois
• …
en mode projet, l’objectif temporel est évident et les autres objectifs sont facilement partagés par tous. a contrario, en mode maintenance, les échéances successives tendent à installer une routine malheureuse, voire préjudiciable à terme.
La motivation des équipes passe, entre autres, par la mise en valeur de la satisfaction client qui est meilleure lorsqu’il bénéficie d’une application stable et évolutive plutôt qu’avec l’imposition d’un nouvel outil.
Donner de la visibilité aux utilisateurs sur le traitement de leur problème améliore leur satisfaction.
Donner de la visibilité sur l’amélioration continue des travaux de maintenance et sur la satisfaction des utilisateurs améliore la motivation des équipes.
en cas de maintenance sous-traitée, l’entreprise utilisera ces indicateurs de pilotage pour définir des pénalités qui assureront la base d’une bonne relation contractuelle :
• Des pénalités financières pour stimuler le dispositif intégrateur, mais de manière équilibrée pour éviter les détournements de processus (penser à définir des malus mais aussi des bonus).
• Une mesure des indicateurs directement par l’intégrateur (vérification du respect de ses engagements).
• Mais aussi un principe de seuil de tolérance de non-conformités avant application des pénalités financières.
Une préoccupation croissante
Le maintien en condition opérationnelle des applications est rendu complexe par la diversité des objectifs à réaliser. La description des « tendances et facteurs d’évolutions » du métier « gestionnaire d’applications » de la nomenclature emploi-métier du ciGref illustre cette importance d’un mco bien géré :
« Dans un nombre croissant de projets, la qualité de la mise en service, qui marque la fin du projet et le début de l’exploitation de l’ouvrage, ainsi que l’utilisation intelligente et optimale des systèmes en place par les individus et surtout par les groupes, conditionnent la réussite globale du projet. C’était beaucoup moins vrai avec les technologies antérieures, lorsque l’essentiel des efforts de l’entreprise portait sur la conception et le développement des systèmes, et que l’autonomie des utilisateurs était relativement faible (contexte de travail fortement prescrit).
À l’image de ce que l’on constate dans d’autres secteurs d’activité, la valeur ajoutée se déplace de plus en plus de l’amont vers l’aval, à savoir le service client et l’usage. » n
Jérôme Bernard, directeur de projet
Jérôme Bernard et Guillaume De Bats accompagnement les chefs de projet dans la phase opérationnelle des projets (de la conception à la stabilisation après mise en production) et les responsables d’applications dans la définition du MCO et l’amélioration de sa performance, en apportant leur expérience et pragmatisme en termes de méthodologie et outil pour la définition et la mise en place de l’organisation, des instances, des processus et de l’outillage du pilotage.
Oresys
Acteur majeur du conseil en management et organisation, Oresys est une société indépendante de 230 consultants basée à Paris, Lyon, Bruxelles qui aide ses clients à piloter leurs activités, améliorer la performance et mettre en œuvre leurs projets de transformation.
ORESYS intervient sur toutes les dimensions : métiers, organisation, processus, système d’information, accompagnement du changement.
http://www.oresys.eu/
guillaume De Bats, responsable de l’activité Gouvernance et management des si
Le Web 2.0 et le RIA (Rich Internet Application), tout le monde en parle : je veux mon blog, mon wiki, des médias riches, du vectoriel… ! On en voit, donc on en veut !
Mais au-delà de l’euphorie et de l’aspect séduisant de ces technologies, il convient de se concentrer sur l’essentiel : offrir aux utilisateurs un design
agréable et une ergonomie facilitant l’accès et le traitement de l’information. Et dans l’univers Internet, ces caractéristiques peuvent donner envie de revenir aux visiteurs. Il ne s’agit donc pas d’une fin en soi, mais uniquement d’un moyen d’améliorer l’expérience utilisateur, c’est-à-dire, comme l’indique Wikipedia, « donner goût à l’utilisateur de revenir sur une interface numérique ».
L’ expérience utilisateur enrichie
En informatique, il ne faut pas négliger l’impact du visuel sur l’humain.
Le ressenti d’un premier contact avec une application s’appuie largement sur
sa « qualité perçue », subtile mélange
de rationnel et de subjectif.
Dans quels domaines introduire les RIA ?
dès qu’il s’agit de créer (ou d’améliorer) une interface applicative, le design et l’ergonomie sont aujourd’hui des préoccupations légitimes. L’avènement des applications en mode Web a largement contribué à cette prise de conscience et la plus- value est devenue évidente.
ainsi, dans leurs sphères privées et professionnelles, les
« Xnautes » sont demandeurs d’interfaces élégantes, riches dans leurs fonctionnalités, compréhensibles dans leurs modes d’interaction et réactives dans le traitement de leurs demandes.
poussées par la « modernisation » des interfaces B2B sur internet, les entreprises doivent prendre en compte la pression de leurs utilisateurs et faire évoluer leurs applications Xnet.
introduire les technologies ria dans les applications incarne l’un des moyens efficaces pour répondre à ces attentes. toutefois, l’enjeu sous-jacent pour les entreprises consiste à transformer ces apports technologiques en réelle plus-value business :
Cas d’utilisation plus-value business
site internet institutionnel améliorer l’image de marque :
• Modernité
• Dynamisme
• … site ecommerce /
eBusiness
développer le ca :
• Faciliter l’acte d’achat
• Différenciation commerciale
• …
application intranet améliorer la productivité :
• Favoriser l’adoption des applications par les utilisateurs
• Accélérer l’accès et le traitement d’informations
• Utiliser des médias
« dynamiques »
• …
portail d’entreprise apporter plus de confort :
• Cohérence des interfaces applicatives
• Signature (login) unique
• …
Bureau virtuel faciliter l’accès aux solutions/informations :
• Mobilité & usages nomades
• Portabilité des interfaces
• …
Quelles technologies RIA utiliser ?
aucune réponse toute faite ne s’impose ! d’une part, l’éventail du choix technologique s’élargit tous les ans ; d’autre part, le contexte de l’entreprise et le type de besoin/service attendu influencent largement le choix d’une (ou plusieurs) technologie(s).
ainsi, dans le cadre d’un si reposant sur des technologies microsoft, silverlight pourra être privilégié pour des questions de cohérence.
après de multiples retours d’expérience sur les technologies open source, certaines orientations technologiques peuvent être établies (et servir d’étalon pour comparer les solutions possibles).
Bien entendu, l’entreprise doit vérifier la faisabilité du besoin vis- à-vis des limitations techniques liées à chaque technologie ou au contexte cible (la figure 1 de la page suivante dresse le panorama technologique actuel en fonction des besoins adressés).
Le bon choix pour un site internet institutionnel HTmL / framework JavaScript / Wicket (Java) : ce triplet est particulièrement adapté, puisqu’il met l’accent sur le design en autorisant quelques comportements ergonomiques.
avantages : le HtmL est un langage bien connu avec de nombreux outils pour concevoir et intégrer des pages Web. ainsi, la réalisation d’un site se répartit entre la réalisation graphique (couche présentation) et l’intégration par Wicket avec le métier (couche logique) par simple paramétrage (et non reprise) du HtmL graphique. Wicket est très facile à utiliser et permet de ne pas développer de code Javascript pour les interactions entre le client et le serveur. L’utilisation de Javascript (via le framework) se limite ainsi aux interactions visuelles avec l’utilisateur et aucun traitement métier n’est (censé être) géré. un argument de poids, suffisamment rare pour être mentionné, tient dans la gestion du « Back / retour » du navigateur, assurée par Wicket via la sérialisation des données de pages.
points d’attention : Le spectre des possibilités reste limité en HtmL, et le paramétrage css ne peut pas révolutionner l’apparence et l’ergonomie. par ailleurs, l’ajout de Javascript peut devenir rapidement coûteux en termes d’efforts pour son développement et sa maintenance.
L’obésité du client : entre clients légers (accessibles depuis un navigateur) et clients lourds (déployés sur l’ordinateur
de l’utilisateur), l’évolution tend vers le client riche, aux fonctionnalités accessibles aux travers d’interfaces
stylisées et dynamiques.
Le bon choix pour un site (application) novateur avec accès à des données
flex : Les possibilités graphiques d’Abobe Flex sont révolution- naires et sa technologie permet de se dédouaner du caractère
« page à page » des applications Web traditionnelles (basées sur HTML) par l’intégration d’un mode « événementiel » sur une même page.
avantages : flex apporte une réelle rupture avec les sites et applications Web « traditionnelles ». en effet, la technologie vectorielle change radicalement l’apparence et flex peut être perçu comme un dérivé de la technologie flash permettant de réaliser de véritables applications métier. il offre ainsi une expérience utilisateur novatrice avec des interfaces très graphiques et dynamiques, enrichies de données multimédia.
pour ne rien gâcher, sa mise en œuvre est relativement facile en comparaison aux développements Javascript. flex ayant rapidement « fait le buzz », de nombreuses communautés technologiques se sont constituées et sont aujourd’hui très actives, avec notamment l’apparition de nombreux frameworks tels que puremvc et cairngorn ou encore Graniteds et Blazeds.
enfin, il ne faut pas considérer la nécessité d’utiliser le plug-in flash comme un inconvénient, car 98 % des navigateurs en sont équipés, selon adobe.
points d’attention : proposer de larges possibilités graphiques nécessite de les maîtriser sans en abuser. en effet, la forme doit toujours servir la fonction, et l’abus d’effets peut engendrer une lassitude des utilisateurs. dans l’univers des applications métier
d’entreprise il est dès lors important de ne pas succomber au
« trip technologique » et de (re)centrer les avantages de flex sur leurs plus-values d’usage (mode événementiel, chargement partiel des pages, utilisation des raccourcis clavier…). À noter également qu’il est difficile de séparer les équipes de design et d’intégration comme cela est souvent le cas avec d’autres technologies. il convient dès lors de bien gérer ces « disciplines » en délimitant notamment les compétences des uns et des autres ainsi que leurs contraintes respectives.
Note : dans le monde microsoft, silverlight est le concurrent direct de flex.
Le bon choix pour un site (application) efficace d’accès aux données
gWT : Google Web Toolkit est un ensemble d’outils développés par Google permettant de créer très facilement des écrans aux comportements riches et d’aboutir à une application en architecture n-tiers sans souffrir des contraintes techniques inhérentes à la communication client/serveur.
avantages : Les objectifs de Google sont, d’une part, de se dédouaner d’écrire du code Javascript et d’autre part de faciliter la communication. pour cela, les applications sont développées en Java puis « compilées » par GWt en HtmL et Javascript, afin de transposer côté client (navigateur) les fonctions visuelles et comportementales de l’application. pour une équipe disposant d’une expérience en langage Java, le temps de montée en compétence est très court. en outre, de
Client riche
(RIA) Client lourd
(résident)
Bureau virtuel
Portail
Application
Client léger (interface simple)
RAP
RAP
RCP
RCP Jsf
Swing
figure 1 : panorama des solutions selon les besoins adressés
nombreux exemples et tutoriaux sont mis à la disposition par les communautés technologiques ; en particulier, ceux fournis par Google permettent souvent de trouver rapidement une réponse en cas de blocage. un atout important de GWt par rapport au développement « à la main » en Javascript, est de disposer d’un vrai débuggeur offrant aux développeurs la possibilité de placer des points d’arrêts dans leur code Java et de pouvoir ainsi interrompre l’exécution du code Javascript côté client.
points d’attention : Les fonctions graphiques étant basées sur le couple HtmL/Javascript, elles sont moins élaborées qu’avec une technologie vectorielle (comme flex ou silverlight). par ailleurs, pour disposer d’un panel important de composants graphiques permettant de couvrir les aspects ergonomiques du modèle Web 2.0, il faut compléter la (pauvre) librairie de base de GWt avec des librairies tierces payantes ou gratuites (open source) comme myGWt ou smartGWt.
Note : GWt s’appuie sur des concepts très proches de ceux de rap (rich ajax platform) de la fondation eclipse, qui est le pendant « client léger » d’eclipse rcp (rich client platform).
Le bon choix pour un portail web ou d’entreprise
Liferay : L’orientation 100 % standard de ce portail open source lui permet d’être facilement extensible via les portlets respectant la norme JSR-168 et plus récemment JSR-286.
Ces portlets permettent aux utilisateurs de « composer » leurs propres interfaces et ont des comportements « autonomes » évitant ainsi le rechargement complet d’une page lors d’une interaction client/serveur.
avantages : du point de vue de l’administration du portail, Liferay offre la meilleure offre du marché open source. cette qualité est le point différenciant majeur de l’éditeur par rapport à ses concurrents. du point de vue technique, les différentes couches (interface graphique, accès aux services, accès aux données) sont bien séparées et assurent un développement maintenable.
Le framework, basé sur struts / spring / Hibernate / Lucene, est riche et stable, et permet de créer rapidement des prototypes. par ailleurs, le portail propose une gestion de contenu satisfaisante (génération de formulaires « à la volée », rubricage/sous- rubricage…) simple à mettre en œuvre et pouvant être étendue si nécessaire avec des fonctions tiers (comme alfresco). enfin, l’éditeur est actif en proposant de nombreuses versions dont les contenus sont souvent riches.
points d’attention : autant Liferay est très efficace quand les besoins à couvrir restent dans ses « traces », autant l’ajout ou l’extension de fonctionnalités peuvent nécessiter des développements longs et coûteux affectant fortement la maintenabilité et l’évolutivité du produit. par ailleurs, la richesse du framework induit une longue montée en compétence et il faut veiller à certaines compatibilités ascendantes entre les différentes versions.
Le cas des clients lourds
pour des cas particuliers, nécessitant par exemple des validations
« à la volée » trop lourdes ou des échanges d’information trop fréquentes pour être utilisables en mode client/serveur ou plus simplement pour l’accès au système de fichiers, il peut être nécessaire de se détourner du « client léger » mais sans forcément se détourner du « client riche » ! des technologies comme air (« le flex lourd ») ou rcp (« le rap lourd ») permettent de créer des applications riches répondant aux attentes des utilisateurs en termes de design et d’ergonomie tout en offrant de plus grandes possibilités techniques. il faut cependant garder à l’esprit que ces solutions amènent leurs lots de contraintes supplémentaires, comme la nécessité de déployer les applications sur chaque poste, même si air et rcp offrent des possibilités pour faciliter le déploiement et la mise à jour automatique.
Pour créer du visuel, interagissons visuellement !
pour créer une application riche, avec une ergonomique avancée, il est intéressant de procéder par ateliers itératifs avec les futurs utilisateurs. Les ateliers sont conduits successivement en mode
« paperboard » en représentant « à la main et au crayon » les différentes interfaces avec leurs objets de navigation (menus, chemins de fer…), leurs zones d’information (tableaux de données, zones de texte, images…) et leurs éléments d’interaction (formulaires de saisie, boutons…). La construction d’une interface suit une logique de production itérative et incrémentale, chaque atelier permettant de visualiser les interfaces réalisées et de définir (ou d’affiner) les interfaces à venir. deux expertises particulières sont dès lors nécessaires au cours de ces ateliers :
• Une connaissance de la faisabilité technique, liée à un « sens » de l’ergonomie, afin de ne pas « dessiner » des interfaces non (ou difficilement) réalisables.
• Une connaissance des besoins métier pour développer au plus tôt les bonnes interfaces et éviter les « va-et-vient » couteux en temps et en argent.
L’atout majeur de ce modèle d’atelier est de concrétiser ra- pidement et successivement les différentes interfaces et de les mettre en visibilité des futurs utilisateurs, évitant ainsi les effets de surprise voire de rejet : les méthodes agiles sont ainsi parfaitement adaptées à la création de ria.
Une opportunité pour définir les bons services techniques
outre les traitements automatisés de type batchs, les services que doit rendre une application sont tous accessibles à travers des interfaces qui la composent. dans le cadre des ria, les interfaces étant « le maillon fort » des applications, il est judicieux de profiter des ateliers nécessaires à leurs représentations pour définir les services techniques sous-jacents à leur exécution.
il est ainsi plus facile pour un utilisateur de décrire « ce qu’il veut qu’un composant fasse » en le voyant concrètement sur une interface, plutôt que d’établir une liste de fonctionnalités hors contexte. un interlocuteur it/dsi est alors nécessaire au cours des ateliers pour faire le lien entre un « objet utilisateur » et un service technique. ainsi, un service technique peut être
« attaché » à un bouton (son action), à une la liste déroulante (ses valeurs) ou encore un tableau (ses données), etc.
Note : cette approche permet de réaliser les premières étapes de la mise en œuvre d’une architecture de type soa en corrélant les services techniques à leurs usages métier. cela permet également d’entretenir la représentation urbanisée du si en définissant les référentiels de services et de données des applications.
L’interface visuelle, nouvelle clé de voute des applications
La qualité des interfaces a une place déterminante dans la production des applications informatiques actuelles : les utilisateurs ne demandent plus seulement que les fonctionnalités soient au rendez-vous, mais également que leur accès soit intuitif et leur utilisation efficace. sans tomber dans les extrêmes où les effets graphiques masqueraient la pauvreté fonctionnelle ou à l’inverse encombreraient l’usage d’une application, améliorer le design et l’ergonomie des interfaces représente une réelle plus-value pour les utilisateurs et les entreprises.
utiliser les dernières technologies paraît naturel. néanmoins, on ne s’improvise pas ergonome ou designer. La création et l’intégration d’interfaces riches nécessitent des compétences particulières que seule l’expérience permet d’enrichir. n
mathieu Lombard, consultant sopra Group
Acteur majeur du conseil et des services informatiques en Europe, Sopra Group a réalisé en 2008 un chiffre d’affaires de 1 129 millions d’euros et dispose d’un potentiel humain et intellectuel de plus de 12 000 personnes. Grâce à une culture historique de l’excellence et à une forte expertise sectorielle, fonctionnelle et technologique, le Groupe offre à ses clients une démarche globale adossée à un dispositif industriel éprouvé. Son périmètre de compétences s’étend depuis la réflexion stratégique en amont, jusqu’à la conduite de grands projets d’intégration de systèmes et à l’outsourcing applicatif. Pour plus d’informations, retrouvez-nous sur www.sopragroup.com.
ServicesEcrans
Spécifier les services en se basant sur les écrans
socle technique ateliers IHM
architecte spécifieurs designer / ergonome
Espace Conseils
AIDE GRA TUITE à la réalisation
de votre
cahier des char ges NOUVEAU !
Microsoft lance Sharepoint 2010
et Project 2010
sur Documation
économique > Intranet > Knowledge Management > Lecture automatique de documents (LAD) > Management de projet > Moteur de recherche > Open Source > Portail d’informations
> Publications multicanaux > SAAS > Sécurité, certifi cation > Sûreté de l’information > Travail Collaboratif > Veille > Web 2.0
Commandez v otre badge gr atuit
www.documation.fr Code : VSPIX
17 & 18 MARS 2010 - CNIT PARIS LA DÉFENSE
Actualités
internationales
VMware se paie les solutions de messagerie et de collaboration Zimbra
en rachetant à Yahoo! le logiciel serveur de messagerie le plus réputé dans sa version open source, vmware confirme sa volonté de bâtir des appliances virtuelles [des applications prêtes à l’emploi dans une machine virtuelle prête à être déployée]. L’éditeur annonce que Zimbra a réalisé en 2009 « un taux de croissance global de 86 % du nombre de ses boîtes – et de 165 % sur le segment des pme/pmi », et compte déjà plus de 55 millions de boîtes aux lettres !
simple à installer, très flexible Zimbra propose une solution complète de messagerie électronique incluant la collaboration. déployée au cœur de Yahoo!, mais aussi chez de très nombreux hébergeurs et fournisseurs d’accès de toutes tailles dans le monde entier, Zimbra é été spécifiquement conçu pour la virtualisation et le cloud computing. vmware assure qu’elle continuera
le support des solutions Zimbra, et poursuivra les initiatives open source. Bien entendu, l’éditeur les optimisera pour les inclure au mieux dans son infrastructure de cloud computing vsphere, au même titre que les logiciels de messagerie et de collaboration de microsoft, d’iBm entre autres.
selon les termes du contrat, Yahoo! conserve le droit d’utiliser la technologie Zimbra dans ses services de communication et notamment dans Yahoo! mail et Yahoo! calendar. n
IBM rachète Lombardi et s’impose dans le BPM
mi-décembre, iBm annonçait le rachat de l’éditeur américain Lombardi, spécialiste du Bpm (Business process management).
une acquisition majeure à l’heure de l’automatisation des tâches, puisque les processus métier sont justement au cœur de ces problématiques et de plus en plus couplés aux infrastructures de type soa par exemple. or, Lombrardi est réputée pour simplifier la modélisation des processus.
idc prévoit d’ailleurs une croissance moyenne annuelle de 15 % pour les quatre ans à venir pour un marché qui passerait de 1,7 milliard de dollars de chiffre d’affaires en 2009 à 3 milliards en 2013.
cette acquisition vient compléter le rachat du français ilog, désormais au portefeuille de Big Blue.
iBm dispose déjà de solution iBm au cœur de Websphere, qui devient l’infrastructure maîtresse commune, ou bientôt commune à toute son offre et au sein de filenet pour son offre ecm (enterprise content management ou gestion de contenu d’entreprise). Gageons que l’éditeur ayant réussi à faire communiquer ces deux briques saura tirer avantage de l’avance des solutions Lombardi pour se doter d’un socle Bpm global avec un ou plusieurs moteurs Bpm spécialisés.
iBm se renforce sur un marché face à d’autres mastodontes comme oracle, microsoft, tibco, progress software ou software aG. n
