Je suis donc intervenu au RIA 2008 d’Adobe en insistant sur trois points, que je crois essentiels, lorsqu’on parle des RIA.

La qualité des données.

Les « Rich Internet Applications » n’ont de sens que dans une architecture orientée ressources, puisque nous sommes dans la quatrième vague d’architecture des systèmes d’information, celle que je nomme DataWare (après les phases de Hardware, Software et Netware). Le découplage entre les données et les interfaces qui les utilisent, implique une attention particulière aux données, à leur qualité ainsi qu’à la manière dont on les expose (notamment avec les logiques d’API).
Ainsi, ce n’est pas tant une architecture de service (une SOA) dont nos systèmes d’information ont besoin, car même ceux qui prônent une architecture de service sont aujourd’hui les premiers à dire que cela n’est possible que s’il y a déjà une architecture des données, une architecture orientée ressource, sous-jacente.

Une qualité des données déplorable dans un système d’information et c’est tout l’édifice qui menace de s’écrouler. La mauvaise qualité des données est le cancer de nos systèmes d’information mais, bien que chacun a intimement conscience qu’il faut faire quelque chose, personne ne sait comment et par quel bout il faut commencer.

Or je suis intiment convaincu que la qualité des données métiers d’un système d’information est directement corrélée à la qualité des interfaces applicatives. Combien de fois avons nous vu des interfaces insipides et incompréhensibles où les utilisateurs, ne sachant quoi mettre, finissaient pas remplir les champs en mettant « titi », « tata », et « toto ». Seulement voilà, les « titi », « tata » et « toto », on va les retrouver dans les bases de données et dans le reporting. Aussi, le premier levier dans l’amélioration de la qualité des données passe par là où elles rentrent, dans la phase de saisie, c’est à dire via l’IHM. On notera à ce propos le partenariat entre SAP et Adobe qui vise à mettre une couche de RIA en Flex en remplacement des écrans SAP (que personne ne regrettera).

Un projet RIA amène donc nécessairement la question de la qualité des données au coeur des discussions, non seulement pour les données qui seront consultées mais également pour celles qui seront saisies via ces nouvelles interfaces.

L’alignement de l’IT sur le Business.

« Aligner l’IT sur le Business », vous entendez peut-être comme moi depuis maintenant de nombreuses années cette injonction. Or c’est faux. Il s’agit là d’une énormité, d’un leurre, il ne faut en aucune manière aligner l’IT sur le business.
D’abord parce que ce slogan induit une logique d’allégeance d’un département de l’entreprise vis à vis d’un autre, et cela ne mène qu’à des querelles de chapelles et, in fine, à un système féodal avec ces baronnies et ces mécanismes de servitude. En effet, véhiculer une telle approche c’est vouloir faire de la DSI les soutiers de l’organisation et ça, ce n’est pas possible.
Ensuite, parce que l’histoire ancienne et récente nous apprend que ce sont toujours les systèmes techniques qui provoquent des désajustements par rapport aux autres systèmes que sont les systèmes sociaux, juridiques, économiques, etc. Si quelqu’un devait s’aligner, ce serait donc bien plutôt au métier de s’aligner sur les opportunités technologiques offertes par le système technique du web.

Mais les innovations techniques et technologiques doivent être socialisées, tout comme il a fallu socialiser des inventions comme le dentifrice ou le vélo : personne en effet ne voulait se mettre de la pâte de fluor dans la bouche, tout comme personne ne pensait que l’on pouvait tenir en équilibre sur deux roues. C’est d’ailleurs pour cela que le tour de France à été créé : pour démontrer au grand public que l’on pouvait tenir en équilibre sur une bicyclette. Et ce n’est qu’à partir de ce moment que les ventes de vélos ont décollé. Pour filer la métaphore, le web est aujourd’hui un « tour de France pour des DSI » : il montre que oui, c’est possible, on peut faire plus simple, plus efficace et pour moins cher.

Toujours est-il que si les DSI persistent à ne pas voir les innovations du web d’aujourd’hui, les métiers, eux, les voient tous les jours ; et ils n’ont pas une patience infinie. A la DSI de prendre ses responsabilités et « d’innover le métier » en promouvant les opportunités du web.

L’IT ne doit pas s’aligner sur le business, pas plus que le métier ne doit s’aligner sur l’IT. Il ne faut pas opposer l’IT et le Business, les deux doivent composer. Ce n’est pas une question d’alignement mais de réajustement, précisément d’un réajustement suite au désajustement du web.

Or il me semble que c’est tout particulièrement dans un projet RIA que départements métiers et informatique doivent réinventer leur relation. Ce qui m’amène donc à présenter les nouveautés qu’apportent les RIA dans le design et la conception des solutions informatiques.

Un nouveau design

C’est donc dans le contexte que je viens d’évoquer rapidement que les RIA peuvent apporter de la valeur car :

• il y a un découplage entre les données et les services qui permet une évolution maîtrisée et non conflictuelle entre MOE et MOA, entre IT et Business. En effet, la répartition des responsabilités est beaucoup plus aisée dans les architectures orientées ressources car la granularité des données est beaucoup plus fine que ces lourds processus d’entreprises supportés par les progiciels.

• il y a une « expérience utilisateur » qui tend à se rapprocher d’une expérience cinématographique (et ce n’est pas pour rien que derrière, au niveau du code, on parle de programmation évènementielle). Faire d’une application un flux, plutôt qu’une succession d’écrans statiques, cela implique de nouvelles pratiques dans le design et la conception des applications, notamment grâce à un effort de scénarisation.

Cette logique d’application, qui devient un flux continu, se retrouve dans la possibilité de faire des « Undo » plutôt que d’avoir des « Pop-Up de confirmation ». Tout comme un film, on peut en permanence revenir en arrière : faire des avances et des retours rapides dans le traitement d’un processus. Ceux qui utilisent des logiciels comme Photoshop sont déjà habitués à telles pratiques.

On a longtemps comparé les projets informatiques au BTP (maîtrise d’oeuvre, maîtrise d’ouvrage, cahier des charges, etc.). Avec les RIA, il peut-être temps de comparer un projet informatique à un projet cinématographique (producteurs, scénariste, réalisateur, monteur, etc.)

Related posts:

1. Adobe RIA 2008 A l’invitation d’Adobe, Je ferai l’allocution d’ouverture de l’évènement annuel...
2. Vers les « Semantic RIA » La question d’une interface graphique (IHM) pour la navigation et...
3. Sens et enjeux des modèles de stockage et d’accès aux données C’est typiquement le genre d’article qui nécessite des corrections, des...

La question d’une interface graphique (IHM) pour la navigation et la consultation des données au format RDF est une question lancinante pour tout ceux qui veulent participer à la promotion et à la progression du nombre de triplets RDF au sein du Web.

D’un côté le web sémantique est un web of data dont on rappelle qu’il est un web essentiellement pour les machines et plus seulement un web de documents pour l’oeil humain, mais d’un autre côté on sait pertinemment que, pour un type d’application spécifique, il y a un fort intérêt à proposer des interfaces hommes-machines agréables et conviviales.

Rappelons brièvemet les outils qui constituent les pièces du puzzle web sémantique :

• des outils pour éditer les données en RDF, soit manuellement, soit automatiquement ;
• des systèmes de stockage des données en RDF, ainsi que des systèmes proposant des endpoint SPARQL pour lancer des requêtes du même nom ;
• des framework et des librairies pour que les développeurs puissent travailler avec les données en RDF et intégrer des requêtes SPARQL dans leurs applications ;
• des navigateurs RDF ;
• des moteurs de règles (ou raisonneurs) OWL ;

Il existe des solutions pour chacun de ces morceaux du puzzle, avec plus ou moins de maturité. Il faut toutefois souligner que le choix d’une des pièces du puzzle peut réduire la latitude sur le choix des autres composants. Face à ce dilemme, OpenLink tire son épingle du jeu en étant présent sur toutes les couches, qui plus est avec des solutions robustes et efficaces :

• OpenLink Data Spaces (ODS) comme système de gestion de contenu ;
• Virtuoso qui propose un stockage des données en RDF et un endpoint SPARQL
• OpenLink AJAX Toolkit (OAT) qui est un framework AJAX pour travailler avec des données en RDF (OpenLink embarque également l’API Jena ) ;
• OpenLink Virtuoso est également un moteur de règle OWL ;
• OpenLink Virtuoso, toujours lui, propose également des modules de génération de RDF à partir de bases relationnelles, mais aussi depuis GRDDL, DRFa, et microformats ;
• OpenLink Data Explorer, qui est une extension Firefox permet également de navigateur sémantique ;

Autant dire que tout projet mettant en oeuvre les normes du web sémantique doit impérativement se pencher sur les solutions d’OpenLink s’il s’agit de faire autre chose que du prototypage, et si l’enjeu est de mettre quelque chose en production qui tienne la charge.

Mais si OpenLink s’impose quand on part de la base, à savoir du stockage des données, avec OpenLink Virtuoso, il n’en va pas de même si l’on se place dans une logique applicative pour laquelle la question n’est plus de faire toutes les requêtes SPARQL que l’on veut à la main, mais plutôt de proposer des interfaces à des utilisateurs. Car après tout, il n’y a pas d’incompatibilité entre l’homme et les données au format du web sémantique. C’est donc là que la question de l’interface se pose avec plus d’acuité.

Si l’on part de la question de l’interface, difficile de ne pas tourner son regard vers Adobe et Flex/Air : les plus belles interfaces graphiques sont en Flex/Flash et ActionScript a été validé par les meilleurs experts venant du monde Java, même par Bruce Eckel, l’auteur de « Thinking in Java « , qui écrit :

« the power of the ActionScript language tools along with the hybrid type checking (mostly static for tool support in Flex Builder, but dynamic whenever it’s convenient) makes for a programming experience that I find much more straightforward and pleasing than Java. »

Les Interfaces Riches amènent de nouvelles valeurs pour les standards du web sémantique :

• une programmation événementielle qui à amène à repenser les logiques applicatives traditionnelles ;
• des composants graphiques élaborés et très faciles à manipuler ;
• une parfaite adéquation avec les architectures orientées ressources (dans la lignée du style REST) qui supposent un découplage entre les ressources et la manipulation des ressources ;

Tout est en place pour que le couple RIA + Web Sémantique entre en résonance avec les « Semantic RIA ». Et les premiers projets allant en ce sens là sont apparus cet été.

Tupelo est une API pour manipuler de manière générique des données en RDF (un peu comme JDBC pour les bases de données relationnelles) qui permet de s’abstraire des spécificités de certaines APIs qui implémentent le stockage RDF sur des bases de données (Jena ou Sesame).

En s’appuyant sur Tupelo, le projet Tupelo Air a implémenté des librairies Actionscript pour manipuler des données en RDF et les services de connexion de Tupelo :

Plutôt que de faire un long commentaire, jetez un oeil au screencast de ce client riche (attention, temps de chargement significatif).

Je crois donc qu’il faudra suivre de près, dans les prochains mois, les évolutions des librairies d’Actionscript et les projets de la communauté des développeurs Flex car c’est aujourd’hui autour de Flex que convergent les logiques d’architectures orientées ressources, les RIA et l’utilisation des standards du web sémantique.

2009 l’année des « Semantic RIA » ?

Related posts:

1. MeetUp Semantic Web Ce jeudi 16 décembre 2010, à 17h, rendez-vous au MeetUp...
2. Designez vos URIs en RDF Mon hypothèse : plutôt que d’encoder les données en RDF,...
3. Seamless Semantic Services Solution - C’est quoi le Seamless Semantic Services Solution ? -...

La nouvelle a vite fait le tour de la blogosphère : Adobe, Yahoo et Google ont signé un partenariat pour indexer les fichiers flash.
Les premières réactions que j’ai pu lire sont plutôt positives. Mais je reste dubitatif devant cette initiative, et ce pour certaines raisons :

• d’abord sur le contenu : j’imagine (à tort ?) que la plupart des contenus en flash ne sont pas les textes les plus passionnants du web ; beaucoup de communication marketing me semble-t-il, non ? Ou en tout cas des textes très fragmenté.

• ensuite, ce contenu, s’il s’avère être de piètre qualité, va énormément rajouter de bruit dans les réponses des moteurs de recherche : quel intérêt pour l’utilisateur de voir les messages publicitaires et marketing contenus dans les flashs se retrouver dans ses résultats de requête ?

• la logique d’un site en flash n’est pas la même que celle d’un site en HTML, dans le premier elle est événementielle et souvent scénarisée, alors qu’il n’y a pas cette logique d’enchaînement scénarisé dans le HTML. Qui plus est, un évenement sous Flash (car Flash c’est surtout une programmation évenementielle), n’est pas forcément un clic de souris alors que le clic reste le seul moteur hypermedia du web en HTML. Deux logiques d’architecture de l’information et de politique éditoriale différentes donc.

• donc, comment ces deux logiques de contenu éditorial et d’architecture de l’information vont elles cohabiter dans l’index des moteurs de recherche et les pages de résultats ?

Au dela des contraintes techniques, il y a donc eu un partenariat. Mais pourquoi ce partenariat et pourquoi maintenant ?
L’intérêt d’Adobe semble de prime abord évident : c’est une reconnaissance pour leur format de fichier que de passer à la moulinette de l’indexation des moteurs de recherche. Les documents des interfaces riches vont rejoindre la masse des autres documents qui sont rentrés dans l’économie des moteurs de recherche.

Mais pour Google : pourquoi choisir d’indexer les fichiers Flash et de prendre ainsi le risque de perturber le modèle même de son fonctionnement ?

Google trouve-t-il son intérêt directement dans l’indexation, ou indirectement ? Dit autrement : font-il çà pour quelque chose ou contre quelque chose (ou quelqu’un) ? Vu sous cet angle c’est encore Microsoft le premier visé (décidément). Un Microsoft qui risque de se retrouver à être le seul moteur qui indexe ses interfaces riches en Silverlight.

Mais ce qui m’embête le plus dans cette annnonce, c’est que les architectures orientés ressources, qui sont les architectures de prédilection des trois interfaces riches (GWT, Flex et Silverligth), vont devenir moins incontournables : en effet, pourquoi faire les choses proprement avec une architecture orientée ressource si je peux avoir mon site indexé directement en Flash ? Cette annonce lève à mes yeux une contrainte qui avait du bon et qui avait le mérite de rendre cohérente, et vertueuse, une démarche d’architecture de l’information (et applicative) couplée avec des interfaces riches.

Certes, il est toujours possible – et souhaitable – de faire des architectures orientées ressrources, mais la contrainte de l’indexation étant maintenant partiellement levée, tout cela risque de ralentir la progression de certaines bonnes pratiques.
Autre hyppothèse pour expliquer ce partenariat : Google préfèrerait-il garder le web dans un certain « bordel ambiant » pour rester celui qui l’organise et le monétise pour nous ?
Et je termine avec cette dernière hypothèse : Google souhaite-til indexer les fichiers Flash non pas comme des documents, mais bien comme des applications, c’est à dire avec une logique d’indexation et de restitution bien spécifique (et donc monétisable de manière plus fine et mieux adaptée).

Sur ce sujet, je vous invite à lire deux billets intéressants sur le blog de François Le Droff, puis de consulter une très bonne synthèse d’Aurélien Pelletier sur les technologies RIA.

Vos avis sont les bienvenus pour confronter mes tergiversations à votre vision de la compréhension et des conséquences de cet accord Google / Yahoo! / Adobe sur l’indexation du Flash

Related posts:

1. Google Video for Business Google vient de rajouter la video dans son Offre Google...
2. Jouir de l’avenir Dans sa Vie du lettré aux éditions de minuit, William...
3. Plus loin avec Google Apps Saviez-vous qu’avec Google Spreadsheet vous disposez de quelques fonctionnalités bien...

Les jeux video se sont souvent parés des apparats des logiciels de gestion (jeux de simulation, de stratégie, de gestion) mais les logiciels de gestion eux-mêmes ont été plus timorés à chercher leur inspiration dans les jeux video.

La tendance va peut-être s’inverser. Les interfaces des applications web vont-elles entamer leur migration vers des interfaces induisant une utilisation similaire ou proche des usages numériques ludiques ?

Par exemple avec Google Web Toolkit, dont Didier Girard nous propose un fils de news précieux, on voit que cet environnement de développement d’interface web riches démontre son intérêt, et sa simplicité, notamment en proposant de petits jeux. Qui aurait pensé il y a à peine quelques années qu’un environnement pour interface d’application web serait utilisable pour faire des jeux video ?

L’idée est en tout cas séduisante pour un développeur : faire une application qui soit un jeu, tout en ayant les finalités d’un logiciel de gestion : gérer des stocks et des flux en bâtant son high score, faire un reporting financier comme on ferait une petite partie en ligne, gérer le staffing comme on joue à Tétris, etc.

C’est également ce qu’a souligné Joi Ito lors de son allocution à Paris le 11 Décembre (LeWeb3) en sous-entendant que nos interfaces de logiciels professionnels ressembleraient de plus en plus à ce que l’on voit dans World of Warcraft :

Du point de vue de la programmation et du développement, ces interfaces placent selon moi la programmation événementielle sur le devant de la scène (Data FLow). Et l’Action Script d’Adobe a certainement de beaux jours devant lui.
L’utilisateur devra traiter des signaux informationnels qui arrivent de manière distribuée, par plusieurs canaux, puis réagir à ces événements.
Mais on ne vire dans la dimension ludique que si l’attention de l’utilisateur est en permanence stimulée par des événements vis à vis desquels on doit réagir et prendre des décisions. Pour cela il faut que l’information arrive sous forme d’un flux qui accapare notre attention. Mais que l’information devienne un flux, çà, on commence à s’y habituer avec les flux RSS.
Il y aura bien sûr différents niveaux de complexité. C’est ici comme dans un jeu d’échec : plus une information va modifier le contexte de la « partie », plus la réaction de l’utilisateur nécessitera de la réflexion.

Travailler en jouant, donc.

Cela semble d’autant plus plausible que les nouvelles générations n’ont pas les mêmes connexions neuronales que nous. Ils ont une forme d’attention que Katherine Hayles nomme « Hyper Attention », qui devient de l’attention distribuée selon Bernard Stiegler (à voir dans l’entretien qu’il m’a accordé). Cette Hyper Attention, à l’inverse de la Deep Attention, c’est celle qui fait que je suis capable de jouer à Tétris mais pas ma mère. C’est aussi celle qui fait que certains peuvent lire ou travailler tout en écoutant de la musique (çà, moi, j’en suis incapable).

Quand des consciences « cablées » différemment rencontrent des opportunités technologiques comme la programmation événementielle et les interfaces web riches ainsi que des pratiques numériques ludiques, on obtient un milieu dans lequel des transformations sont possibles.

Related posts:

1. Facebook pour l’entreprise Worklight propose des interfaces d’accès aux informations de l’entreprise en...
2. Le web sémantique pour les petits Le web sémantique est ludique et favorise l’éveil de vos...
3. Sens et enjeux des RIA Je suis donc intervenu au RIA 2008 d’Adobe en insistant...

Autour de ce que l’on pourrait nommer de manière générique les interfaces riches il y a profusion d’acronymes : Silverlight, Apollo, WPF, WPF/e, FLEX, AIR, JavaFX, GWT, SWING, etc.

Le but de toutes ces démarches : contrôler l’accès aux ressources web.
Le levier qu’elles utilisent toutes, ou l’argument qu’elles mettent en avant : une meilleure interface utilisateur et une meilleure ergonomie (user experience).

Une bonne manière d’éclairer les enjeux autour des interfaces riches – pour lesquelles j’utiliserai l’acronyme RIA – est de les présenter en parallèle des enjeux autour du SaaS (software as a service).

Les offres RIA sont clairement une menace pour les pure-players du SaaS. En effet, ceux-ci offrent leurs services via le navigateur : enlevez le navigateur à Google et il s’effondre immédiatement. C’est ce qui explique le soutien financier qu’apporte Google à Firefox. En effet, le partenariat de la barre de recherche Google dans Firefox permet d’alimenter financièrement la fondation Mozilla. Il n’est pas là pour inciter à utiliser Google – il n’en a pas besoin – mais pour s’assurer de la disponibilité d’un navigateur standard et indépendant, permettant d’accéder aux services de Google.

Ainsi, pour les acteurs traditionnels de l’industrie du logiciel, et on pense bien évidemment à Microsoft, le navigateur est le talon d’Achille des pure-players du SaaS. Ils s’y attaquent donc, mais comment ?
Cela se fait sous, au moins, trois angles d’attaque :

1. Montrer de belles interfaces : donner envie.
2. Démontrer la nécessité de continuer à utiliser les applications en mode déconnecté.
3. Insister sur l’avantage de capitaliser sur des applications de bureau qui ont accès aux fonctionnalités du système d’exploitation et aux tierces applications.

Forcément, comme l’assaut sur navigateurs traditionnels se déroule selon plusieurs axes, cela apporte une certaine confusion (sans compter avec la multiplication d’acronymes et de noms de code qui disparaissent au gré de la maturité des équipes marketing des uns et des autres.).

Pour débroussailler le terrain, il faut faire une première distinction entre les RIA : les RWA (Rich Web Application) et les RDA (Rich Desktop Application ) :

• Les RWA se servent du navigateur comme conteneur : c’est par exemple un plugin/module qui va enrichir les capacités natives de l’interface graphique du navigateur. Dans cette catégorie des RWA On retrouve Silverlight de Microsoft (ex WPF-e) et Flex de Adobe. Mais aussi Google, avec son GWT (Google Web Toolkit), qui est partie prenante dans l’évolution du navigateur. Une des particularités des RWA est qu’elles n’accèdent pas aux ressources du Desktop ou de l’OS sur lesquelles elles tournent.

• Autre version des RIA, les RDA. Contrairement au RWA elles sont totalement indépendantes du navigateur Web et ont la capacité d’accéder aux ressources du Desktop /OS. AIR est la déclinaison d’Adobe (en gros c’est du Flash dans une application de bureau) et WPF (Windows Presentation Foundation) celle de Microsoft. [Petite remarque en passant, seul WPF propose de faire du 3D en natif, mais c'est un détail pour ce qui nous occupe à présent].

Le salut des offres SaaS natives passe donc par des RIA en mode RWA (Rich Web Application). Et c’est tout logiquement que Google va mettre le paquet sur GWT. En passant, si vous développez avec GWT essayez GWT Designer, c’est ce que conseille Didier Girard (et il faut toujours écouter ce que dit Didier Girard). Salesforces, autre pure player historique du SaaS, a déjà annoncé via son offre VisualForce, qu’il permettait à ses clients de basculer les interfaces web traditionnelles en RWA (en l’occurrence on peut utiliser Flex). Sur ce dernier point, on peut trouver ici une galerie photo expliquant VisualForce en image.

Enfin, pour éviter l’hémorragie vers les RDA, les pure players du SaaS doivent répondre à la question du mode déconnecté : c’est la vocation de Google Gears (déjà utilisé par Zoho, un concurrent de Google Apps). Mais Google Gears n’est pas parfait car il laisse en suspend une question plus qu’épineuse qu’est la synchronisation des données lorsqu’on se re-connecte. Travailler en mode déconnecté est une chose : synchroniser les données lors de la re-connexion en est une autre.

Voilà donc le tableau de la situation des forces en présence en ne mettant en avant que les initiatives de Adobe (Flex en RWA et AIR en RDA), de Microsoft (Silvelight en RWA et WPF en RDA), et Google (GWT en RWA et Google Gears en palliatif aux RDA). A ces initiatives, on pourrait en rajouter d’autres comme celle de Sun avec JavaFX, mais cela reste secondaire dans le cadre de cette note.

Ce tableau rapidement dressé, esquissons quelques hypothèses sur les tendances à venir :

• tout d’abord le navigateur web classique ne va pas disparaître, les pages en html sont là pour durer ne serait-ce que pour la consultation (et pour ne pas décevoir ceux qui qui veulent continuer à surfer).
• les RWA sont la clef de voûte des acteurs pure player du SaaS, elles vont connaître une forte croissance dans les mois à venir. D’autant plus que c’est le champ de bataille actuel sur lesquel les acteurs offrant par ailleurs des RDA ont une déclinaison.
• côté RDA, il y aura peu d’élus. Car autant on peut accepter d’avoir plusieurs pages web ouvertes sur son bureau (ou dans des onglets), autant il devient lourd d’avoir plusieurs RDA en même temps. Les premiers à s’engouffrer sur les RDA sont ceux qui proposent des actes d’achat en ligne (l’expérience utilisateur favorisant l’acte d’achat), et l’on retrouve tout naturellement des vendeurs disposant d’un catalogue : FNAC et eBay dès à présent, et certainement les grands acteurs du retail (mais aussi, par analogie avec la notion de catalogue, peut être des institutions comme les bibliothèques tiens, en passant). Toujours côté RDA, vont émerger les applications en entreprise à la mode « software + service » (dénomination qui va certainement changer) pour les entreprises qui voudront construire sur, et autour, de leur patrimoine applicatif.

Une remarque pour finir, les RDA ne sont pas des pures fictions qui n’arriveront que dans plusieurs mois, certains en ont déjà fait leur fer de lance : vous connaissez iTunes ?

Related posts:

1. Pas de processus sur le Web Le principe de statelessness du web veut que chaque requête...
2. Mise en cache dans les navigateurs Internet Explorer et Opera (pas Firefox et Safari) mettent en...
3. Li-bé-rez nos camarades ! Imaginez que vous êtes prestataire ou consultant chez un client....