Retour d’expérience sur mon système de veille et réflexions sur le web des API

apiBéatrice Foenix-Riou m’a demandé de faire le point sur mon système de veille, que j’avais proposé il y a un an. L’article est en ligne en intégralité et a été publié dans Netsources. Cependant, entre le moment où j’ai répondu à ses questions et le moment où j’écris ce billet, mon système a déjà évolué!

C’est donc une version augmentée différente de celle qui a été publiée que je vous propose sur la base de l’article publié dans Netsources. Grand merci à Béatrice pour la démarche et pour la discussion stimulante que nous avons eu.

Dans un article intitulé “Pocket et IFTTT : une alternative efficace à Google Reader”, publié il y a tout juste un an sur son blog, Silvère Mercier présentait la solution qu’il avait choisie pour remplacer l’agrégateur de flux Google Reader, dont la fermeture était programmée pour juillet 2013.

Après un an d’utilisation, nous avons souhaité bénéficier de son retour d’expérience, pour connaître ainsi, avec le recul, les atouts et les faiblesses de la solution qu’il a mise en place.

Netsources : Vous vous présentez comme un “bibliothécaire engagé pour les libertés à l’ère numérique et la libre dissémination des savoirs”, et vous animez depuis 2005 le blog Bibliobsession.net, plusieurs fois cité dans ces colonnes. Vous avez créé le Bouillon, projet de veille collaboratif en 2008. La veille est donc au cœur de vos activités.

Il y a un an, alors que de multiples articles présentaient des “alternatives à Google Reader” – en vantant le plus souvent les mérites de l’agrégateur Feedly –, vous avez opté pour une solution originale basée sur l’association de deux outils : IFTTT et Pocket. Pouvez-vous nous présenter la démarche qui vous a conduit à ce choix, ou plutôt les besoins auxquels répondaient ces outils ?

Silvère Mercier : de nombreux outils ont été présentés comme des alternatives à Google Reader. Mais ils ne répondaient pas à mes attentes car, à l’époque du moins, il leur manquait certaines fonctionnalités qui m’étaient indispensables (et qui, pour certaines, ont depuis été ajoutées aux lecteurs de flux).

D’une façon générale, ces agrégateurs ne disposaient pas de fonction de recherche dans le texte des articles partagés, ne proposaient pas de synchronisation avec les flux issus d’autres services (connectés via des API) et, surtout, ne permettaient pas de partager un commentaire sur un article (extrait…), via plusieurs médias sociaux, à partir d’outils de veille nomades ou fixes.

Ce dernier point en particulier était capital pour moi, tant il est partie intégrante de ma façon de fonctionner. Ce partage – de commentaires et de citations, et non seulement de liens – contribue en effet à la construction de ma culture numérique.

Je cherchais en fait un outil m’offrant la possibilité, en mobilité, d’accéder à ma collection de flux, de la lire, et d’en exporter la substantifique moelle commentée ou citée.

L’outil devait donc disposer de flux RSS sortants, afin d’exporter à la fois l’article et le commentaire. Or, les agrégateurs de l’époque proposaient simplement de partager l’article sur les médias sociaux…

Netsources : Vous avez donc choisi de coupler IFTTT et Pocket. Pouvez-vous nous expliquer ce qui vous a séduit dans ces outils ?

Silvère Mercier : Outre les besoins exprimés plus haut, j’étais à la recherche d’un outil disposant de différentes caractéristiques en matière de lecture des articles et, plus précisément :
• permettant une lecture en mobilité (dans les transports…), via un smartphone ou une tablette ;
• affichant les textes de façon “nettoyée” ;
• donnant un accès direct au texte intégral des articles ; les agrégateurs classiques affichent en général l’extrait du flux dans le navigateur, et il faut cliquer sur le titre pour accéder à la totalité de l’article.
En situation de mobilité (et de connexion incertaine), cet affichage en deux temps est pour moi un inconvénient.

J’ai réalisé que ces fonctionnalités, qui n’étaient pas offertes par les agrégateurs traditionnels (pour le troisième point notamment), étaient en fait la caractéristique des outils de capture pour “lire plus tard” – tels que Pocket, Instapaper ou Readability, ou encore l’outil libre Poche

J’ai choisi Pocket car j’ai été séduit par son interface et ses fonctionnalités… Mais Pocket ne pouvait constituer qu’une “brique” du processus de veille, car ce n’est pas un agrégateur, et qu’il ne lit donc pas nativement les flux RSS.

J’ai donc cherché un outil pour faire office d’agrégateur en amont, à savoir pour recevoir les flux RSS puis envoyer automatiquement à Pocket les articles de chaque flux.

Et j’ai pensé à IFTTT, que j’avais déjà présenté dans mon blog comme “le chaînon manquant de mon écosystème informationnel”.

Parmi celles-ci, on trouve la possibilité d’envoyer chaque article d’un flux donné à Pocket (mais on pourrait aussi les poster sur Evernote, Blogger, WordPress, Readability, Instapaper…), en leur attribuant un tag prédéfini. Les tags peuvent alors remplacer les dossiers que l’on créés dans les agrégateurs, pour classer les flux d’une même thématique.

Netsources : Comment avez-vous concrètement mis en place ces recettes ? Avez-vous intégré d’autres outils dans votre processus de veille ?

Silvère Mercier : La combinaison d’IFTTT et de Pocket fonctionne très bien, mais imposait de créer une recette pour chaque flux. A l’époque, la mise en place s’est donc avérée longue et fastidieuse pour moi, puisque je surveille plus de 250 flux, classés dans quatre catégories.

Il est d’autre part difficile de se repérer ensuite dans la liste de ses recettes, et je recommanderai à ceux qui souhaitent utiliser ce système de nommer chaque recette par la source du flux ainsi que par un tag propre à IFTTT, de façon à pouvoir les retrouver très vite…

Une fois les recettes créées, les nouveaux articles des différents flux sont envoyés dans Pocket dans leur intégralité, avec une mise en page “nettoyée”, et peuvent être lus hors connexion.

La nouveauté par rapport à l’époque à laquelle j’ai mis en oeuvre ce système est que Feedly a progressivement pris la place de Google Reader grâce à son API. Il n’est donc plus nécessaire de créer 250 recette si l’on veut suivre 250 flux mais il est parfaitement possible (et c’est conseillé) de synchroniser les dossiers de veille de Feedly avec Pocket en faisant correspondre un dossier de Feedly à un tag dans Pocket. Voici la recette pour faire cette opération :

IFTTT Recipe: Actuweb connects feedly to pocket

Cependant, si la lecture des articles est très agréable sur Pocket, il n’en est pas de même pour le partage de citations commentées sur les médias sociaux. Outre le fait que pour la plupart d’entre elles qu’une connexion est obligatoire, les différentes interfaces de Pocket dédiées au partage (sur Twitter, etc.) sont plutôt mal conçues et peu conviviales. Elles permettent de sélectionner un extrait d’un article, mais ne permettent que rarement d’insérer cet extrait pour le partager. Il faut alors le copier puis le coller dans le champ adéquat.

Netsources : Quelles solutions avez-vous donc mises en place pour diffuser votre veille (commentaire ou citation + lien vers l’article original) vers les différents médias sociaux ?

Silvère Mercier : La diffusion de ma veille se fait via plusieurs outils. L’élément central pour la diffusion est Pinboard.in, un site de bookmarking social du même type que Diigo et Delicious, que j’utilise par ailleurs pour alimenter le Bouillon. L’outil est pauvre graphiquement, il offre moins de fonctionnalités que Diigo (pas de gestion des groupes), mais en échange d’une dizaine de dollars une fois pour toute, il permet de se passer toutes publicité et propose des fils rss sortant, ainsi que la possibilité de poster des billets par emails ce que Diigo ne proposait pas il y un an.

Lorsque je souhaite diffuser un article sur les médias sociaux, depuis Pocket, j’utilise le partage par Pinboard en ajoutant une citation de l’article au champ description de pinboard par un copier coller. Puis, les items sauvegardés dans Pinboard sont diffusés automatiquement vers Facebook, grâce à RSS Graffiti. La version gratuite de cet outil permet de publier 300 posts/mois sur une page Facebook. J’ai choisi RSS Graffiti car il permet notamment l’ajout des métadonnées ; par conséquent, l’item posté sur Facebook contient à la fois le titre et lien de l’article original, mon commentaire ou extrait, et le cas échéant, une image. L’inconvénient est lié à la gratuité du compte RSS grafitti qui ne permet d’avoir accès à aucune statistique de partage. Pour la diffusion sur Twitter et LinkedIn, j’utilise la version gratuite de Buffer, avec laquelle on peut programmer la publication de tweets (Buffer est alimenté directement depuis Pinboard, via IFTTT).

A noter qu’un des réseaux les plus réactifs dans lequel les billets sont souvent discutés est SeenThis, outil peu connu de veille sur laquelle se développe une communauté active. J’y diffuse ma veille via un fil RSS.

Je pense que si la pratique de veille est quotidienne, cela vaut le coup d’investir dans un compte payant chez Buffer parce que l’outil propose des statistiques assez fine sur chaque partage et permet de programmer efficacement des publications de veille.

Netsources : après un an d’usage, quel est votre bilan sur le processus de veille que vous avez mis en place ?

Silvère Mercier : au final, le bilan est positif et comprend à la fois des points forts et des points faibles. Parmi les atouts du système, le principal est que j’agrège en un seul endroit (Pocket) les fils de veille que je souhaite suivre, et que ma veille se fait aussi bien au bureau qu’en mobilité (transports…). L’autre atout est que la fonction « pour lire plus tard » d’un outil comme Pocket est toujours utilisable, ce qui permet en plus de veiller via Pocket d’y ajouter des liens collectés sur Twitter ponctuellement. Ajouter ces liens dans Pocket est très facile depuis l’application Echofon que j’utilise pour Twitter. Ces liens ajoutés « au fil de l’eau » ne se confondent pas avec les items en provenance des fils RSS puisqu’ils apparaissent dans la catégorie « éléments sans label » de Pocket. L’autre avantage est que si l’on veut bénéficier de la version premium de Pocket, l’outil se transforme en véritable base de données des informations collectées puisque Pocket vend comme une service le fait de pouvoir rechercher dans la base des contenus ajoutés à Pocket, même si le contenu original n’est plus en ligne.

L’inconvénient majeur du procédé tel que je l’ai mis en place il y a un an était la captivité de l’outil, puisqu’il m’était impossible d’exporter l’ensemble des flux RSS dans un fichier OPML, comme on peut le faire depuis la plupart des agrégateurs… Je conseillerai à ceux qui veulent mettre en place ce système aujourd’hui de faire l’inverse de ce que j’ai fait : intégrer les flux d’abord dans Feedly et synchroniser Feedly avec Pocket avec le recette proposés ci-dessus pour pouvoir exporter ses flux depuis feedly. Il y a un an, Feedly n’était pas encore intégré à Pocket…

D’autre part, si la lecture sur Pocket est vraiment confortable, l’outil ne permet pas de distinguer les articles non lus des autres, ce qui peut être un handicap. Il faut donc soit archiver systématiquement les articles lus, soit se rappeler des articles déjà lus, ce qui est très facile si l’on veille régulièrement. Il n’est pas non plus possible de trier facilement (en dehors d’une recherche sur le nom de la source ou de l’ajout d’un tag par source) de trier les articles par la source.

Il faut noter qu’une nouvelle fonctionnalité très intéressante est depuis apparue sur le principal concurrent de Pocket qui est Instapaper. La fonction Highlights permet de surligner un passage d’un article. Cela n’aurait rien d’extraordinaire si cela n’était parfaitement bien intégré à une chaîne IFTTT mise à jour très récemment pour Instapaper. Celle-ci permet  d’envoyer directement ce qui est surligné dans Pinboard et donc dans les autres outils de diffusion. C’est le moyen le plus efficace que j’ai trouvé pour l’instant de partager un extrait d’un article, là ou Pocket oblige l’utilisateur à copier-coller l’extrait dans un champ, Instapaper prend en compte l’extrait juste après son surlignage.

IFTTT Recipe: Share a Highlighted item in Pinboard connects instapaper to pinboard

A noter aussi que la toute nouvelle chaîne IFTTT d’Instapaper prend enfin en compte les dossiers, ce qui permet d’appliquer une recette équivalent à celle utilisée plus haut pour Pocket et de synchroniser un dossier Feedly avec un dossier Instapaper. Le seul inconvénient de taille pour Instapaper est la très mauvaise qualité de l’interface de l’application mobile. Les titres sont tous tronqués par défaut ce qui est un gros handicap pour sélectionner des lectures de veille. Cet inconvénient dépend toutefois de la tailler de l’écran de l’appareil nomade que vous utilisez.

Quelques réflexions plus générales pour finir. L’ensemble fonctionne correctement et il est intéressant de voir comment c’est en développant une API que Feedly a pris une place dominante sur ce marché. La démarche devrait provoquer un déclic fondamental pour les développeurs d’outils libres. Car il existe bel et bien une alternative libre à Pocket et Instapaper (tous les deux sont des outils propriétaires) elle s’appelle Poche. L’outil est parfaitement fonctionnel… sauf que faute d’intégration à IFTTT il n’est pas possible de personnaliser son utilisation. Dans le web des API, ce n’est pas seulement l’ouverture du code qui compte mais l’intégration à des services tiers même non ouverts…

C’est à mon sens un élément crucial qu’il faut comprendre : plus les outils libres seront intégrés à des outils non libres, plus ils auront de chance que leurs usages se développent et plus il sera possible de parler d’alternatives. Par exemple, aucun lien n’existe entre l’API de Google Agenda et Framadate, l' »alternative » libre à Doodle permettant de programmer des rendez-vous, alors même que Doodle vient de passer ce lien dans sa version payante. Autre exemple, quels liens entre Framapad et les autres services web? Pourquoi ne pas intégrer Framapad dans un IFTTT pour en dynamiser l’usage? J’en profite pour signale que je suis parfaitement conscient des ressources nécessaires au développement des outils libres Je vous invite d’ailleurs à contribuer à la campagne de financement de l’outil Framapad… Pourquoi SeenThis, ce chouette réseau de veille qui prend parfaitement en compte les citations et les creative commons n’est-il intégré à aucun outil tiers? Trop souvent j’ai l’impression que le développement d' »alternatives » se pense en autarcie, alors que c’est de mise en relation dont nous avons besoin parce que c’est par ces relations entre outils que se développent des usages.

Songez que le socle de tout ce système est IFTTT un service entièrement construit sur les API et qui ne cesse de se développer pour prendre en compte les objets connectés. Les API et leur maîtrise sont pour l’instant la seule manière d’échapper aux jardins fermés du web et le secteur n’est pas du tout investi par les acteurs du logiciel libre… 

Et si demain la meilleure chose qui devait arriver au libre était de voir émerger un IFTTT libre connecté à tous les grands acteurs du web?

  (6935)

This work, unless otherwise expressly stated, is licensed under a Creative Commons Attribution-ShareAlike 3.0 France License.

Silvae

Je suis chargé de la médiation et des innovations numériques à la Bibliothèque Publique d’Information – Centre Pompidou à Paris. Bibliothécaire engagé pour la libre dissémination des savoirs, je suis co-fondateur du collectif SavoirsCom1 – Politiques des Biens communs de la connaissance. Formateur sur les impacts du numériques dans le secteur culturel Les billets que j'écris et ma veille n'engagent en rien mon employeur, sauf précision explicite.

1 Response

  1. 2 juillet 2014

    […] NB:  un article plus récent fait le point sur mon système de veille un an après ce billet. […]

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Vous pouvez utiliser ces balises et attributs HTML : <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>