Entreprise20.fr

Après avoir longtemps existé de façon officieuse en entreprise (sur imitative des collaborateurs), Netvibes vient d’annoncer un partenariat historique avec Sage pour rentrer par la grande porte dans le monde de l’entreprise : Partnership with Sage brings Netvibes to even more Enterprises. Pour être plus précis, Netvibes va devenir la solution officielle de portail pour la future version de ERP X3 (un produit à destination du mid-market). Cet accord va donc permettre aux clients de Sage de profiter des offres Premium Dashboards et Netvibes for Enterprise.

Netvibes en entreprise

Cette nouvelle monture devrait sortir au premier trimestre 2010 et être propulsée par Wasabi, la nouvelle version majeure de Netvibes : Le nouveau Netvibes, édition Wasabi. Un choix tout à fait intéressant car il répond à deux besoins : le tableau de bord personnalisable pour les employés et le lecteur de flux (qui a été grandement amélioré dans la nouvelle version : New Netvibes Will Be World’s Biggest Real-Time Feed Reader).

La nouvelle version de Netvibes

Le système de personnalisation de l’interface permettra donc aux collaborateurs de choisir les informations et applications qui leur conviennent le mieux (en s’appuyant pour cela sur le standard Universal Widget API), à défaut il sera possible de leur proposer différents choix par défaut.

Concernant la lecture de flux RSS, là encore il y a du nouveau puisque la nouvelle version propose différents modes d’affichage (liste, mosaïque…) mais également le support des protocoles d’échange de données en temps réel Pubsubhubbub et RSS Cloud.

Bref, ce ne sont que des bonnes nouvelles et le début d’une expérimentation à grande échelle du principe de personal dashboard qui va pouvoir être testé auprès de dizaines de milliers d’utilisateurs dans un contexte professionnel. Bien évidement il existe d’autres éditeurs de solutions de ce type mais peu ont le même parcours que Netvibes (cocorico !).

D’ailleurs à ce sujet je suis à la recherche de retours d’expérience sur l’implémentation à grande échelle de ce type de fonctionnalité…

(via Read/Write Web)

J’ai peu lire pas mal d’articles ces derniers temps qui exposent des points de vue très radicaux vis à vis du RSS (et des formats de syndication en général) :

• Ten Reasons Why “Enterprise RSS” Has Failed To Become Mainstream ;
• Rest in Peace, RSS ;
• Going with the flow: whither enterprise RSS?.

Les arguments avancés dans ces articles sont grosso-modo les mêmes : RSS est une technologie rigide qui n’induit pas frocément de la collaboration, de plus les utilisateurs ne savent pas et ne veulent pas savoir ce qu’est RSS. À contrario, le microblog est une pratique très souple, en temps réel, qui facilite les conversations et qui est très simple à prendre en main. Bref, le RSS est mort et les outils comme Twitter vont dominer le monde et même tuer les blogs. Pas si vite, car même si cet excès d’enthousiasme envers le microblogging est conjoncturel, le RSS est loin d’être enterré. En fait la vérité se situe entre les deux, comme toujours d’ailleurs quand il est question de choix technologique (comme quoi l’informatique n’est pas binaire).

Je vous propose donc une synthèse des avantages / inconvénients de ces deux solutions.

Concernant le RSS (et les formats de syndication en général) :

• C’est une technologie très puissante (car rigoureuse) mais largement sous-exploitée par les utilisateurs dont les usages se cantonnent à de la lecteur de flux via Netvibes ou Google Reader ;
• C’est aussi une technologie limitative car il n’est pas possible d’avoir accès aux archives des flux que vous avez lus ;
• Il faut coupler la consommation de flux avec du social bookmarking pour faire de la veille collaborative.

Concernant le microblog :

• C’est une pratique beaucoup moins sophistiquée mais plus souple ;
• La collaboration s’exprime au travers des retweets (RT) et des #tags ;
• Permet de faire de la veille proactive en “poussant” un lien vers un collègue avec une @.

Nous pourrions résumer en disant que le microblog est performant pour faire de la veille informelle et en tant qu’outil d’éveil, le RSS est lui plus adapté à de la veille industrialisée et de la syndication entre plateforme (d’intranet à intranet).

OK, mais nous pouvons pousser la réflexion un peu plus loin :

• Si le RSS est si compliqué à comprendre pour les utilisateurs alors que le microblog est ultra-intuitif, comment se fait-il qu’il y ai bien plus d’utilisateurs de Netvibes que de Twitter ?
• Si le microblog est un outils très puissant pour “prendre la température” et “tâter l’humeur”, comment se fait-il que les outils d’analyse de tendances sur Twitter soient aussi pollués et imprécis ?

Bref, ce n’est pas si simple et le pire dans tout ça, c’est que ce débat ne devrait même pas avoir lieu. Je rejoins ainsi l’avis de Bertrand Duperrin : “Comparer RSS et microblogging revient à confondre la fin et les moyens“. Le RSS est une technologie alors que le microblog est un outils (et Twitter un service). Il serait ainsi beaucoup plus opportun d’opposer social bookmarking et microblogging. La comparaison est d’autant plus absurde que la plupart des plateformes sociales qui sont citées en exemples comme Facebook ou FriendFeed font un usage intensif des flux RSS.

Au final je pense qu’il serait juste de dire que RSS et microblog se complètent mais ne s’opposent pas. J’abonde ainsi dans le sens de Lee Bryant qui rappelle que l’ennemi à combattre est l’email (ou plutôt les usages détournés que l’on peut en faire). Idéalement c’est en couplant les deux (syndication RSS et microblog) que l’on peut obtenir des résultats probants sur la réduction d’emails échanger et sur de la capitalisation de connaissance.

Attendons-nous donc à voir fleurir des solutions de microblogging de classe “entreprise” à l’image de la Socialtext Microblogging Appliance ou de solutions couplées de microblog / social bookmarking comme le propose Knowledge Plaza pour faciliter un usage plus souple de la veille en entreprise (en libre service) avec surtout des services intégrés à un portail d’entreprise.

Il est maintenant temps de conclure cet article et de me livrer à un petit exercice prédictif : je pense que dans un avenir proche les flux RSS voit devenir moins visibles pour les collaborateurs (qui se contenteront de liens ou boutons “Inscrivez-vous”) mais rester indispensables à la dynamique sociale des intranets 2.0 (notamment dans leur fonction première de syndication). Le microblog sera lui un outil réservé à quelques happy few qui s’en serviront au quotidien mais qui sera aussi proposé sous d’autres formes pour les plus hermétiques aux nouveaux outils (sous la forme des “Activités récentes” ou des “Hot Trends“).

Et vous : Est-ce que vous cumulez RSS et microblog ou avez-vous opté pour un seul outil de veille ?

Scandale cette semaine avec la parution d’un article sur le blog Read/Write Web : R.I.P. Enterprise RSS. L’auteur y explique que les technologies RSS n’ont pas réussies leur passage d’entrée pour les usages d’entreprise (l’auteur a rectifié sa position depuis la publication de l’article). Plutôt que de commenter l’article je vous propose d’étudier les différents scénarios d’usage de RSS dans un contexte d’entreprise.

Précisons qu’il s’agit bien là du format RSS, au sens “flux de donnes”, plutôt que de la technologie RSS en elle-même qui se révèle plutôt limitée vis à vis de concurrents comme Atom.

Nous pouvons tout d’abord scinder en deux les usages en fonction de la cible : pour les collaborateurs et pour le système d’information (les applications). Ce sont deux contextes séparés où peuvent cohabiter deux technologies différentes puisque ces types de flux ne sont à priori pas amené à se croiser.

RSS pour les collaborateurs : une veille collaborative et cumulative

La veille est très certainement le contexte d’usage le plus approprié aux flux RSS. Simples et légers les flux de données sont très faciles à déployer au sein d’une entreprise. Mais là où un utilisateur se contente de “consommer” les flux (rien n’est stocké), dans un contexte d’entreprise il serait plus judicieux de conserver les flux pour exploitation ultérieure.

L’idée serait alors de capter tous les flux entrants (pour limiter la consommation de bande passante) et d’y injecter une touche collaborative pour pouvoir surveiller l’usage que les collaborateurs en font : plus il y a d’inscrits à un flux et plus celui-ci présente un intérêt. Nous pourrions ainsi imaginer un système d’analyse d’audience interne qui pourrait identifier les sujets critiques et les informations entrantes à valeur ajoutée.

Couplé à un outils de bookmark collaboratif et à un système de recommandation, cette veille mutualisée présenterait d’autant plus de valeur : la fonction de veille n’est plus isolée au niveau des individus mais partagée entre les collaborateurs. Stocker les billets pourrait également présenter un intérêt, d’une part pour s’assurer de la disponibilité des informations (si jamais l’auteur de billet le met hors ligne) et d’autre part pour plus de discrétion (un concurrent pourrait devenir méfiant à l’idée que X personnes d’une même société s’intéresse de près à ce qu’il rédige).

Bien évidemment tout ceci nécessite le recours à des outils adaptés : soit une fonction intégrée au portail d’entreprise ou à l’intranet, soit un lecteur de flux d’entreprise comme Newsgator (dont le patron a réigé un billet en réponse à celui précédement cité : Enterprise RSS at NewsGator is Alive and Well).

RSS pour les applications : Flexibilité et modularité

Concernant les flux de données entre applications, là encore c’est la praticité de ce format qui en fait la valeur : idéal pour récupérer de l’info publié sur un intranet et le re-publier sur le portail d’entreprise. L’avantage est de pouvoir faire abstraction des outils de gestion de contenu utilisés et de pouvoir mettre en place ce système de re-publication sans trop de complications.

Dans un environnement plus critique (applications métier), les flux de données se révèlent également particulièrement performant. Ceci est d’autant plus vrai avec les flux reposant sur un format spécifiquement adapté aux contraintes des données (par extension des balises descriptives). Car n’oublions pas que RSS et des langages structurés comme BPML partagent une racine commune : le XML.

Bref, les possibilités d’usage du RSS en entreprise sont nombreuses et nous ne sommes qu’au début. De part leur nature très flexible et extensible les flux de données vont pouvoir évoluer en même temps que les besoins / habitudes des collaborateurs. Et n’oublions pas que les flux RSS sont des candidats idéals pour initier les collaborateurs à une approche plus “agile” de la gestion de l’information en entreprise.

La veille a toujours été le nerf de la compétition économique à laquelle se livrent les entreprises : veille stratégique, veille technologique, veille concurrentielle, veille produit, veille commerciale, veille sociétale…

Aujourd’hui le développement économique est tellement important et rapide que la veille est devenue un véritable sport de haut vol, un exercice d’endurance… une performance.

Heureusement, de nombreux outils permettent de nous faciliter notre travail de veille. Parmi ceux-ci vous connaissez bien-sûr les flux RSS et les agrégateurs de flux.

(Petit rappel pour ceux qui ne sont pas convaincus de l’utilité des flux RSS dans la veille :
Les fils RSS et la veille, RSS et veille)

———————–

Ainsi donc, tous vos collaborateurs qui sont amenés à faire de la veille utilisent déjà les flux RSS et un agrégateur. C’est bien mais les veilleurs partagent-ils leurs “trouvailles” avec leurs collaborateurs ? Et comment les veilleurs partagent leurs “trouvailles” avec leurs collaborateurs ?

Font-ils des rapports réguliers dans lesquels ils consignent chaque info qu’ils jugent pertinente ? Envoient-ils par e-mail les infos aux personnes susceptibles d’être intéressées ? Mais alors d’une veille synchrone, le partage devient asynchrone ! D’une veille centralisée, le partage devient dispersé !

———————–

Pour répondre à cette question et améliorer ainsi notre veille, nous avons mis en place dans mon agence une solution que je vous propose de découvrir. Voici d’abord un schéma illustrant la solution, suivi de quelques explications et enfin d’un tutorial.

(1) Les veilleurs veillent. Ils consultent dans leurs agrégateurs des centaines de flux RSS
(2) Les veilleurs filtrent l’information. Dans la multitude d’infos, ils sélectionnent celles qui peuvent être intéressantes. Ces sélections d’articles forment elles-mêmes des flux RSS.
(3) Les différents flux RSS qui concernent un même sujet sont fusionnés en un seul flux.
(4) Tous les collaborateurs susceptibles d’être intéressés par un sujet “veillé” ont à leur disposition un flux RSS qui regroupe au même endroit la sélection faite par les veilleurs à ce sujet, la crème de la crème !

Bien sûr les veilleurs eux-mêmes consultent aussi le flux remixé afin de profiter de la sélection de leurs confrères. Idéalement d’ailleurs, chaque collaborateur devrait participer à la veille : chacun participe d’une part à la création de ces flux de sélection et profite d’autre part de la sélection des autres.

Note : le schéma représente le partage d’un seul sujet.

Lire le reste de cet article »