Les nouvelles architectures agiles

Transcription

1 point de vue Les nouvelles architectures agiles Passer du Playmobil au Lego

2 Sommaire Le lego BPM 4 L'approche par les processus Le puzzle Urbanisation 7 Quand l information remplace l application Le scoubidou MDM 10 Les nouveaux jeux de données Le mécano SOA 13 Les applications composites La Wii SCRUM 17 Les démarches agiles Les Sims Ajax 21 De nouvelles interfaces personnalisables et ergonomiques L'auteur Rémi Moebs Senior Manager Responsable de la cellule «Architecture et Solutions Collaboratives» au sein de la Division Business Consulting de Sopra Group Atlantique Consultant et agitateur technologique depuis 12 ans sur les sujets Web, Web 2.0, KM et collaboratif, e-commerce, Architectures agiles et distribuées.

3 Avez-vous déjà essayé d assembler 2 Playmobils? C est la quadrature du cercle permanente pour les utilisateurs et les informaticiens à chaque nouveau projet informatique, et inévitablement on rachète une nouvelle boite, plus jolie, plus complète que la précédente mais avec les mêmes bonshommes de base. Pourquoi ne pas essayer de remplacer les trop nombreuses boites de Playmobil par une seule boite de Lego? Pour le moment il n y a pas encore la notice, mais on peut construire simplement beaucoup de modèles nouveaux avec la forme souhaitée sans jeter les briques à chaque fois. C est la promesse des nouvelles architectures agiles. Il s'agit d offrir un nouveau terrain de jeu avec toute une panoplie de nouveaux jouets qui seront abordés dans les épisodes qui composent ce point de vue, dans un esprit «SOA* pour les nuls». * Service Oriented Architecture 3

4 Le Lego BPM : l approche par les processus Le but du jeu : on joue à «Top-Down» Le BPM (Business Process Management) est un acronyme désignant l approche par les processus. L idée phare derrière ce nouveau trigramme anglo-saxon est de redonner le pouvoir aux utilisateurs par ce qu on appelle une approche «Top-Down», opposée à l approche bottom-up dans laquelle les informaticiens dictent les contraintes et les solutions. Figure 1 : Le BPM (Business Process Management) SI structurant Approche Bottom Up Urbanisation & SOA SI au service du métier Approche Top Down Au lieu de piloter les projets informatiques par le simple choix réducteur d une solution (une nouvelle boite Playmobil à chaque fois), l utilisateur se réapproprie l usage de son information manipulée dans ses processus, confisquée jusqu à présent par les applications et les progiciels. C est lui qui choisit la couleur et la forme des Legos qui sont assemblés. Même dans le cas d un choix progiciel, qui devient la norme avec la structuration et l enrichissement progressif de l offre des éditeurs, une modélisation amont des processus permet de piloter l intégration du produit et non de la subir. En gros, on dirige le paramétrage du produit au lieu d en subir le paramétrage standard. 4

5 La règle du jeu : modéliser et piloter par les processus On part donc des processus, qui décrivent les activités métier de l entité concernée. En principe, la modélisation de ces processus est simple et indépendante de l organisation, et doit donc survivre à une réorganisation géographique ou fonctionnelle. Les processus constituent un élément du patrimoine d une entreprise, et doivent faire l objet d un référentiel construit et maintenu en fonction du périmètre des métiers exercés. On s appuie sur une modélisation des processus, en utilisant un formalisme normalisé également : le BPMN (Business Process Modeling Notation) qui génère un langage d exécution des workflows, le BPEL (Business Process Execution Language, prononcer «Bipeul» pour les diners en société). Figure 2 : Le Business Process Modeling Notation Mauvais Bon Les processus sont constitués de différents états qui s enchaînent, entre lesquels on gère des transitions, manuelles ou automatisées par une application (c est seulement à ce moment qu on commence à parler d application informatique dans l approche top-down). Ces transitions sont gérées par un moteur d exécution des processus, qui se charge d exécuter les transitions et d appeler les applications correspondantes, on rajoute souvent la couche BAM (Business Activity Monitoring) qui permet de mesurer les indicateurs clés d exécution des processus (exemple : délai d instruction d un dossier). Ce qu on gagne : une informatique plus efficace et recentrée sur les métiers L approche BPM permet de ne commander que des applications en rapport direct avec le métier des utilisateurs, sans céder aux sirènes des éditeurs. On constate bien souvent que quand une suite progicielle est achetée, les utilisateurs restent cantonnés aux 10 % des fonctions les plus utiles (ou plus accessibles) au quotidien. 5

6 On sert plusieurs objectifs majeurs, dont : n un alignement garanti de l informatique sur les besoins métier, puisqu ils sont à la source des applications ; n une utilisation plus pertinente des budgets informatiques; n une activité globalement recentrée sur le vrai besoin métier, éliminant ainsi les dérives «nouveaux jouets», la technologie passe au second plan ; n une bien meilleure maîtrise de l activité, qui est modélisée, partagée par tous au sein des processus, mesurable et adaptable en permanence, on est bien là sur le terrain de l agilité métier. Dans un monde idéal : «Processus-Land», le nouveau nirvana de la MOA Dans un monde idéal, toute entité, société, organisation possède un référentiel des processus complet et maintenu à jour en permanence par les Directions Métier. Seules les évolutions de processus nécessitent des adaptations des applications existantes. On distingue généralement des responsables (ou propriétaires) de processus, qui veillent à leur bonne application. Globalement, la culture processus est efficacement généralisée, et l informatique est vraiment au service des métiers. Le grand jeu de Lego est en place Dans la vraie vie : quel modèle de gouvernance? Dans la vraie vie des entreprises et des organisations, on constate qu il est difficile : n de constituer un référentiel des processus ; n de le maintenir et de le faire vivre ; n de basculer d une culture progiciels-solutions à une culture processus-informations, même dans le cas où les 2 points précédents sont correctement gérés ; n des problèmes résident souvent dans la difficulté de mettre en place une gouvernance efficace pour la modélisation initiale des processus et leur diffusion ensuite dans l organisation. L approche doit être crédible et légitime pour être appliquée efficacement ; n il faut distribuer les Legos de manière équitable et construire la notice avant distribution des boites. En synthèse, jouez avec vos Legos! Le BPM apporte une plus-value fondamentale sur la formalisation et la maîtrise de ses processus, on replace le métier au cœur de l action, la technologie informatique redevient l outil qu elle aurait dû rester. 6

7 Le puzzle Urbanisation : quand l information remplace l application Le but du jeu : assembler ses quartiers pour construire le puzzle L idée Phare à la base de l urbanisation est de construire et maintenir une vue cohérente des zones et des quartiers du SI, comme si on voyait les différents quartiers d une ville : quartier des échanges, quartier des référentiels, quartier pilotage Figure 3 : Exemple de vue urbanisée d'un SI E-Commerce A partir de la vue haute des processus et des référentiels, on descend ensuite dans les couches fonctionnelles, applicatives et techniques, avec toujours une vue urbanisée par quartiers. Le lien entre les fonctions du SI, vision maîtrisée par les utilisateurs, et les couches techniques, vision maîtrisée par les informaticiens, est effectuée via une vue services dans l approche SOA (Service Oriented Architecture). Les utilisateurs «piochent» dans les services (la boite Mecano) pour construire leurs applications. 7

8 La règle du jeu : cartographier en couches, le puzzle en 3D Dans le cadre du livre blanc «Urbanisation & SOA» téléchargeable à l adresse : Sopra Group a formalisé une approche système urbanisé et SOA avec 5 niveaux de référence : n Processus n Fonctionnel n Services n Logique (ou applicative) n Physique (ou technique) L apport de cette approche est d offrir une nouvelle couche pivot d interaction et de dialogue entre les utilisateurs et les informaticiens : la vue centrale permettant de publier des services SOA et de constituer des référentiels MDM. Figure 4 : cartographier en couches VUE METIER - PROCESSUS Deux vues fonctionnelles pour décrire les processus métier et la vision urbanisée VUE URBANISEE - SYSTEME D'INFORMATION Une vue Pivot pour assurer la transition entre vues métier et vues informatiques VUE PIVOT SOA - ARCHITECTURE ORIENTEE SERVICES VUE INFORMATIQUE - ARCHITECTURE LOGIQUE Deux vues informatiques pour décrire l'architecture logique et l'architecture technique VUE INFORMATIQUE - ARCHITECTURE TECHNIQUE Ce qu on gagne : réfléchir avant d agir, le plus d une vision urbanisée Cette approche permet de rationaliser l évolution du Système d Information : n On mesure beaucoup mieux l impact d une évolution (où je rajoute des pièces) ; n On trie les projets vraiment utiles (impact trop lourd, pièces déjà existantes) ; n On mutualise et on réutilise beaucoup avec le réemploi systématique des services et des référentiels partagés (j assemble et je complète mon puzzle plutôt que de refaire). 8

9 Dans un monde idéal : tout est modélisé et modélisable, la machine à puzzles On dispose d un référentiel complet et maintenu des 5 couches qui permet : n d avoir en permanence une vision centralisée et consolidée des processus et du Système d Information ; n de distribuer efficacement les compétences en les spécialisant par couches ; n de mettre en place une gouvernance maîtrisée des processus, des données et des services. On peut envisager dans ce contexte un apport non négligeable de l approche MDA (Model Driven Architecture, se référer au livre blanc «Urbanisation & SOA» pour une description plus complète). Cette approche va autoriser une transition automatique entre les modèles : on peut ainsi imaginer de générer automatiquement une application composite SOA à partir de sa modélisation. Dans la vraie vie : l usine à gaz cartographique, un puzzle trop complexe? En réalité, l approche urbanisée amène bien souvent au constat d un référentiel complexe et trop difficile à maintenir efficacement sur l ensemble des couches. En pratique il vaut mieux privilégier la couche processus qui est la moins évolutive et porteuse de la plus grande valeur ajoutée. Il est intéressant également d adopter au minimum un référentiel de services. Le deuxième écueil principal concerne la gouvernance du Système d Information : l approche urbanisée se fonde sur l appartenance des quartiers à des Directions métiers, or il est souvent bien délicat de décider à qui appartient tel référentiel de données ou tel quartier fonctionnel. Le relatif échec de l approche CRM qui a buté bien souvent sur la gouvernance du Référentiel Client dans les organisations complexes en est un exemple vécu. En synthèse, pas de puzzle de 5000 pièces! L urbanisation est un outil puissant et complexe qui apporte une plus-value indéniable dans la maîtrise d un Système d Information et de son évolution. L approche SOA apporte en prime une nouvelle zone de dialogue entre MOA et MOE. En pratique, il faut savoir doser son effort et trouver le curseur d arrêt de la modélisation, on peut également urbaniser progressivement par quartiers et par couches. 9

10 Le scoubidou MDM : les nouveaux jeux de données Le but du jeu : maîtriser ses informations de référence, construire son scoubidou Le concept de base à l origine du MDM (Master Data Management) n est pas vraiment nouveau : il s agit d assurer la qualité et la fiabilité des données de référence (qu on appelle les Master Data), mais il a souvent été mis à mal par la vague des ERP ou la complexité croissante du SI et du nombre d applications. Des exemples de Master Data : Référentiel Client/Personne/Usager, Référentiel Produit. L idée Phare du MDM est d assembler de manière cohérente dans un référentiel maître (le Master) les mêmes informations présentes sous des formes différentes (les variantes) dans les applications, puis de fournir les outils pour modéliser et administrer ces référentiels. Pour continuer le parallèle avec le scoubidou, chaque source est un fil de couleur différente, toutes ces sources s assemblent via des opérations de transformation pour construire des référentiels cohérents. Figure 5 : Exemple d'approche MDM (source IBM) Master Data Applications existantes Applications existantes Master Data Référentiel Master Data Applications existantes Master Data Nouvelles applications Système historique/ analytique 10

11 La règle du jeu : assembler des référentiels cohérents, trouver les bons fils Dans une approche toujours Urbanisation & SOA, le MDM permet de construire une zone référentiels : n dont l utilisateur est propriétaire (du modèle et du contenu des données) : le QUOI ; n dont l informatique assure l alimentation et la synchronisation : le COMMENT. En cohérence avec une approche services urbanisée, on crée une zone de dialogue MOA/MOE, la zone des référentiels (Master Data). D un point de vue SOA, le MDM peut être vu comme un Bus Applicatif des Données, tout comme l ESB (Enterprise Service Bus) est le Bus Applicatif des Services. Mauvais Bon En pratique, un référentiel Master Data devient la source unique des applications pour lire ou écrire les données de référence. Toute application souhaitant accéder à une donnée de référence doit passer par le «bus» MDM. Le processus MDM est focalisé uniquement sur les données partagées entre les applications, qui correspondant en général aux entités de référence de l organisation qui les manipule (Client, Dossier, Contrat, Produit, Compte ). Dans sa mise en œuvre, le MDM met en jeu un panel de technologies assez complexe, pour consolider, synchroniser et unifier les données partagées dans les différentes applications : n EAI pour les échanges inter-applicatifs ; n SOA pour les échanges découplés ; n ETL pour la gestion des flux batchs ; n Outils de gestion de la qualité des données (exemple : dédoublonnage) ; n Outils de modélisation des données ; n Outils d administration des données. Qu est-ce qu on gagne : des données de référence centralisées et fiabilisées La plupart des situations existantes proposent aujourd hui des données désynchronisées, incomplètes, inexactes et distribuées dans différents silos applicatifs. La présence de plusieurs progiciels pour gérer différents pans de l activité aggrave généralement le phénomène. 11

12 Le MDM entend répondre à ce problème de gestion des données de référence en offrant : n des espaces pour les données de référence, les Master Data, toujours fiables et à jour ; n un nouveau mode de gouvernance des données, dans un usage centralisé et unifié. Les gains espérés : n Qualité et fiabilité des données de référence ; n Évolutivité et maintenabilité des applications, qui deviennent indépendantes du modèle physique des données ; n Organisation plus efficace, des responsabilités mieux partagées sur les données métier de référence. Dans un monde idéal : coexistence pacifique des référentiels, chacun ses fils La vision idéale du MDM serait une suite de référentiels (quartier des référentiels dans une vue urbanisée) contenant les données de référence de l organisation, permettant à la MOA la réappropriation et le contrôle de données, indépendamment de leur représentation physique. L approche MDM consacre également un nouveau rôle, celui de Steward (ou Business Steward) : responsable des données d un domaine fonctionnel, il gère la cohérence et la qualité des données via les interfaces d administration du MDM. Il est informé des actions sur le référentiel (création, anomalie, événement déclenché sur règle métier paramétrable). Dans la vraie vie : qui tire les fils? On peut considérer aujourd hui que les outils techniques arrivent à maturité pour gérer des référentiels MDM. Par contre, le MDM pose le problème difficile à résoudre de gouvernance des données, lié à l organisation et à la légitimité réciproque de chacune des MOAs sur les différentes données de référence. Par exemple : n quelle Direction est responsable des contrats? n quelle Direction gère et contrôle les données produits? Le CRM avait déjà mis en évidence ce problème : à qui appartient le référentiel Client? Et dans la pratique bien des projets CRM s appuient sur des référentiels partiels ou insuffisamment consolidés, limités au périmètre de la solution retenue et non transverses au Système d Information. En synthèse, c est l heure de faire ses premiers scoubidous Le MDM reste un concept assez récent qu on peut encore qualifier d émergent. La grande force qui devrait faciliter son adoption est sa totale compatibilité avec une approche Top-Down et SOA. On se rend compte actuellement que le fameux middleware orienté services du SOA expose essentiellement des interfaces d accès aux objets métier, contenus dans les référentiels MDM. En effet, comme dans l approche SOA, le MDM propose une approche par l intégration et un découplage entre les vues métier et les vues techniques, permettant de garder l agilité sur chacune des couches. Et sa mise en œuvre peut tout à fait être progressive : on construit un référentiel et on «branche» progressivement les applications alimentant et consommant ce référentiel. 12

13 Le mécano SOA : les applications composites Le but du jeu : découplage et assemblage Le principe simplifié d une architecture orientée services est de proposer un découpage du Système d Information en «tranches» horizontales : n Une tranche applications de surface ; n Une tranche middleware communiquant ou ESB (Enterprise Service Bus) ; n Une tranche back-office, contenant les briques métier structurantes du Système d Information. L objectif est de «décapsuler» les silos étanches et verticaux du SI (progiciels ou applications spécifiques) pour qu ils offrent désormais des «prises» sous forme de services pour pouvoir recomposer de nouvelles applications de surface plus rapides et plus simples à réaliser en assemblant les services disponibles. Figure 6 : Le SOA (Service Oriented Architecture) Applications verticales en Silos Vision SOA - Middleware Services et applications composites 13

14 Notion importante : l approche SOA autorise la rupture de technologie (en clair on peut coder son frontal en PHP et appeler un back-office en Java ou en Cobol via des Web Services par exemple). Chaque couche peut être développée dans une technologie différente (on va arrêter les débats stériles pour comparer les filières Java, PHP et Microsoft) puisque maintenant elles peuvent allègrement cohabiter. La règle du jeu : composer et recomposer autour d un ESB Comme le Web 2.0, l architecture logicielle suit la tendance sociologique : le recomposé est à la mode. L idée phare de l approche SOA est d assembler des services dédiés, des services partagés et des services techniques pour composer rapidement une application sur mesure. Figure 7 : Rôle central de l'esb Intranet Extranet Internet Applications composites Services composites Bus de Communication/Orchestration Services métier Métier 1 Métier 2 Métier 3 Un point à noter est le nouveau rôle central de l ESB (Enterprise Service Bus): comme le serveur d application a remplacé l OS, l ESB va remplacer (ou enrichir) progressivement le serveur d application pour le doter d un moteur de gestion des échanges, et le plus souvent d un moteur d exécution des processus. C est déjà la nouvelle brique infrastructure de base des architectures logicielles et le futur «centre nerveux» du Système d Information. 14

15 Ce qu on gagne : le Graal de la réutilisation L approche SOA répond enfin à la quête du Graal de l approche objet, initiée dans les années 90 : on va pouvoir vraiment mutualiser et réutiliser des composants logiciels. On distingue 3 types de services réutilisables : n des services partagés, qui sont exposés par un quartier fonctionnel du Système d Information (exemple : Facturation) et qui centralisent et mutualisent une fonction métier ; n des services techniques, qui permettent de mutualiser une fonction technique transverse (exemples : impression, stockage, GED, sécurité, ) ; n des services dédiés, qui sont des services composites créés pour servir un canal ou une application particulière (exemple : l ensemble des services dédiés de mon extranet client). Le SOA suit le principe de la spécialisation ascendante : les services des couches basses sont communs à l ensemble du SI, et plus on monte vers les couches hautes, plus les services se spécialisent, jusqu à la présentation qui est propre à chaque application composite. Le gain principal en développement et en maintenance est de s appuyer sur des couches communes validées et de ne réaliser que les nouveaux composants vraiment nécessaires au besoin. Dans un monde idéal : tout est service, l élément de base du mécano On associe trop souvent la SOA au seul Web Service, en fait c est bien le service qui est le boulon du mécano, c est lui qui autorise l assemblage entre deux pièces hétérogènes. Et le service n est pas forcément Web Service, c est toute interface permettant de faire communiquer deux applications informatiques via un contrat de service. Le critère de choix d une solution informatique n est plus seulement sa couverture fonctionnelle (le fameux silo vertical) mais son ouverture et son interopérabilité. Une bonne solution doit exposer les services des fonctions qu elle rend. La difficulté reste de définir le bon niveau de granularité fonctionnelle ou technique de l interface exposée par un service, rôle transverse des urbanistes et architectes, dont la SOA annonce le retour en force. Dans la vraie vie : SOA is dead? Un article désormais fameux a annoncé la mort de l approche SOA ( C est assez vrai pour la SOA de refonte. La probabilité de voir de grands projets de transformation pour migrer un Système d Information dans son ensemble vers une cible full SOA est en effet assez faible. L approche SOA répond par contre parfaitement à des besoins tactiques ou agiles : on peut «rhabiller» les anciennes applications en exposant sous forme de services leurs fonctions et donc adopter une trajectoire de convergence progressive. 15

16 Attention dans ce cas à la pertinence et l utilisabilité réelle des services exposés. Beaucoup d applications back-office ainsi «rhabillées» offrent une couche service inexploitable, car pas à la bonne granularité et exigeant une connaissance trop fine des fonctions exposées. A la décharge également de la SOA, un de ses points faibles est sa gestion des transactions. On ne peut pas enchaîner l appel de deux services en garantissant l exécution globale (exemple : création de compte puis transaction). Il faut prévoir des services de compensation manuels ou automatisés pour gérer les erreurs. En synthèse, il faut apprendre les règles du jeu, on va tous faire du mécano Ma conviction est qu on va tous faire du mécano à plus ou moins brève échéance, c est une lame de fond portée par un nouveau modèle. L approche SOA est la 4ème génération du modèle informatique après Mainframes, Client/Serveur et Client Web. L application composite va s imposer, Apple est en train de le démontrer avec l iphone. La SOA tactique, agile, progressive et intelligente va régner en maître, pour la plus grande joie des architectes et urbanistes. 16

17 La Wii Scrum : les démarches agiles Le but du jeu : aller vite à l essentiel L idée phare de l approche agile est de réaliser des projets rapides à forte valeur ajoutée, d une manière très interactive, en se concentrant sur les besoins essentiels. Comme la Wii a révolutionné le monde du jeu Vidéo en passant de l approche statique «canapé» à l approche agile «Wiimote», la méthode agile bouleverse le traditionnel cycle en V pour une approche des projets moins formelle et plus réactive. Figure 8 : Scrum, notion de mêlée Extrait Product Backlog Sprint Backlog Réalisation Incrément produit Sprint Sprint planning Daily Scrum Sprint review Sprint Retrospective On ne peut pas parler de l agilité sans évoquer Scrum, méthode agile basée sur la notion de mêlée (scrum donc), largement en vogue, qui propose un jeu de rôles pré-défini (Scrum Master, Product Owner) et des outils pour conduire les sprints (Product backlog : liste des besoins, Sprint Backlog : tableau de suivi de l exécution). On peut citer d autres méthodes itératives comme UP (Unified Process), XP (extreme Programming) ou la vieillissante RAD (Rapid Application Developement). 17

18 La règle du jeu : une méthode agile pour combiner agilité métier et agilité SI Aujourd hui, les métiers ont besoin d être agiles pour pouvoir s adapter en permanence à des demandes nouvelles (nouveau produit, nouvelle stratégie, fusion-acquisition, nouvelle réglementation ) avec souvent un enjeu fort sur le délai de mise en œuvre. L approche BPM sert en partie ce besoin en permettant aux utilisateurs de bien maîtriser leur processus, et donc leur évolution. Pour servir ce besoin d agilité métier, l entreprise a donc besoin d un Système d Information structurellement agile. C est ce qu apporte une architecture SOA. La méthode agile permet ensuite de combiner agilité métier et agilité technique en proposant une méthodologie de projet adaptée : n cycles de réalisation raccourcis (sprints de quelques semaines) ; n travail MOA/MOE commun en mode plateau ; n Définition progressive de la solution. La méthode agile peut servir deux types de problématiques : n un 1 er niveau «quick and dirty», pour faire du jetable tactique ; n un 2 nd niveau «développement rapide» pour produire rapidement des applications composites. Ce qu on gagne : ciblage, vitesse, dialogue, tout est mieux Un des objectifs majeurs de la méthode agile est de réduire les incompréhensions entre utilisateurs et informaticiens. Adieu les cahiers des charges formels de 100 pages décrivant une montagne de fonctions à réaliser, la méthode agile permet une construction progressive du besoin en traitant les fonctions demandées dans l ordre décroissant des priorités. Il simplifie notamment le travail de la MOA à qui on ne demande plus une description formelle et exhaustive de son besoin, mais à qui on propose une méthode interactive pour le définir. Un gain majeur est donc de favoriser les relations entre MOA et MOE. Le besoin originel est mieux compris, mieux cerné et servi plus rapidement. On réalise au final des applications moins chères, car concentrées sur le périmètre utile, et facilement adoptées par les utilisateurs. On combat efficacement la résistance au changement sur un nouvel outil trop complexe. Le mode «plateau» (tout le monde regroupé physiquement au même endroit) permet une proximité et une facilité d échange, qui facilitent l atteinte des objectifs et qui sont autant d atouts pour la suite du projet : le dialogue est déjà présent, les utilisateurs clés ont participé activement à la construction de l application et vont logiquement la promouvoir. 18

19 Dans un monde idéal : le «droit de retouche» permis aux utilisateurs par l agilité Des cycles projets raccourcis, un besoin réduit à son périmètre essentiel, des utilisateurs satisfaits : une approche agile bien menée semble plébisciter l usage de la Wii et renvoie au placard la bonne vieille méthode en V. Finalement, est-ce vraiment une bonne idée de demander à des utilisateurs de donner une vision exhaustive d une nouvelle application sous forme d un Cahier des Charges pesant et formel? Est-ce que finalement le vrai besoin et les vraies priorités ne sont pas noyés dans la masse d informations? Le concept d application informatique reste très théorique : il s agit d aider l utilisateur à mieux manipuler son information au quotidien, vaste programme! Ne devrait-t-on pas accorder forcément «un droit de retouche» à l utilisateur? La méthode agile répond parfaitement à cette carence de la méthode en V, en permettant aux utilisateurs et aux informaticiens d élaborer ensemble et progressivement la meilleure solution. A chaque étape, on montre, on échange, on ajuste, en re-priorisant intelligemment à chaque fois. Spécification Validation Conception préliminaire Intégration Conception détaillée Tests unitaires Codage Vieux modèle Mode agile 19

20 Dans la vraie vie : tout peut-il être agile? Puisque la méthode est si efficace, on se dit finalement pourquoi ne pas généraliser cette approche à l ensemble des applications du Système d Information? Et on touche là les limites de l agilité : n les problématiques d industrialisation et d exploitabilité sont peu ou pas traitées du tout, l agilité suppose un socle technique préexistant qui a déjà résolu tous ces problèmes ; n l agilité n est qu un «pattern organisationnel», comme pouvait l être par exemple la norme ISO Elle n impose pas de règles sur la qualité de la production. Il peut être utile alors de la coupler avec un outillage de type intégration continue, et d adopter une approche TDD (Test Driven Development) pour la réalisation de l application ; n L agilité ne laisse pas le temps de raisonner générique ou de construire des modèles structurants, elle produit très peu de composants réutilisables. Il parait donc difficile de traiter en mode agile la mise au point de briques structurantes, comme par exemple un référentiel de services, un référentiel MDM, ou un Infocentre. Ces composants nécessitent en effet une approche et une réflexion transverses, qui impactent l ensemble des objets métier du Système d Information. Difficile dans ces conditions de converger en quelques semaines seulement. En synthèse, nager agile en surface, garder quand même les bouteilles pour le fond En synthèse, l emploi d une méthode agile offre réellement de belles perspectives pour améliorer la réactivité du Système d Information aux demandes métier et apporter une vraie efficacité pour réconcilier informaticiens et utilisateurs dans la durée. Il est préférable de limiter la méthode agile à son périmètre d excellence : les applications composites «de surface» (ou IHMs) orientées usage, et garder en parallèle une approche traditionnelle conception-réalisation pour les couches basses du Système d Information. 20