Archives mensuelles : décembre 2002

Combien coûte l’opensource ?

OK, la licence des logiciels opensource est gratuite. Mais quid des coûts associés (support, services, formation, …) ? Les éditeurs de logiciels commerciaux offrent des coûts de support explicites. Il est plus difficile d’obtenir un service de support auprès des développeurs d’un logiciel opensource. Employer quelqu’un pour qu’il passe son temps à suivre des forums et listes de discussion n’est pas non plus une solution économique. Sur le long terme, les logiciels opensource seraient-ils plus coûteux que les logiciels commerciaux ? Une analyse au cas par cas s’impose. Cette analyse devrait prendre en compte les faits suivants.
Si l’on emploie un expert interne pour participer à la communauté des développeurs et utilisateurs du logiciel opensource choisi, on gagne bien plus qu’un simple niveau de support : un expert interne fournit également la possibilité d’enrichir les fonctionnalités du logiciel, à la demande, et agit en tant qu’évangéliste interne pour favoriser un meilleur usage et un plus grand succès du logiciel sélectionné.
Un bon moyen pour évaluer la pérennité d’un logiciel opensource consiste à s’appuyer sur le travail d’analyse et de sélection des éditeurs de livres informatiques : plus un logiciel opensource à fait l’objet d’ouvrages (chez O’Reilly par exemple), plus il peut être considéré comme pérenne car ayant atteint une masse critique d’utilisateurs tel que l’avenir de son code source est assuré pour de nombreuses années.
De plus, l’adoption d’un logiciel sous licence opensource garantit une indépendance vis-à-vis de ses développeurs et éditeurs de manière à ce que ceux-ci ne puissent imposer de licences limitée dans le temps ni d’obsolescence programmée (« Telle version de notre logiciel ne sera plus supportée à partir de telle date… » ou bien « Telle version de notre logiciel comporte des failles de sécurité trop importantes, vous devriez adopter notre toute dernière version. »).
Il assez probable qu’une société comme Microsoft survive encore de nombreuses années et puisse offrir, à ses conditions, la maintenance du logiciel. Et il n’est pourtant pas si improbable qu’une communauté de développeurs d’un logiciel opensource abandonne un jour ce développement pour une raison ou une autre. N’est-il pas alors préférable de se fier à un éditeur commercial ? Sans doute que non car, même en cas d’abandon du logiciel par ses développeurs initiaux, non seulement la poursuite du développement peut être assurée par des développeurs indépendants ou d’autres sociétés mais le caractère public du code source permet également de s’approprier le maintien et le développement interne du produit. Dans le cas où un éditeur de produit fermé fait faillite, les coûts de possession du logiciel grimpent en flèche car il devient presque impossible d’obtenir support et maintenance à conditions économiquement raisonnables.
Dans le cas d’un logiciel répondant à un besoin précisément et durablement défini (surtout si ce besoin est celui d’un informaticien), il est très probable qu’un produit opensource soit préférable à un produit commercial qui, de par le modèle économique de son éditeur, gagnera probablement en fonctionnalités superflues. On considère souvent qu’un produit opensource est plus stable et contient moins de bugs et de failles de sécurité sur le long terme. On peut également apprécier le caractère prévisible des coûts de maintenance d’un logiciel opensource à long terme. Nul ne sait combien l’éditeur d’un produit fermé facturera la maintenance dans 5 ans.
Pour conclure, on peut dire que la comparaison du coût total de possession d’un produit fermé (propriétaire) et d’un produit ouvert (opensource) doit faire l’objet d’une analyse approfondie, au cas par cas. Et l’un des critères déterminants du TCO d’un produit ouvert et le degré d’activité et de vitalité de sa communauté de développeurs.

Foules en réseau

Howard Rheingold évoque la richesse sociale inexploitée des foules qui nous entourent tous
les jours (lorsque l’on va prendre le train, dans un aéroport, dans la rue, …) et
l’opportunité qu’il y aurait à exploiter ce capital par le biais de réseaux wireless
d’ordinateurs embarqués dans nos vêtements. Vous croisez tous les jours, sans le savoir,
quelqu’un qui pourrait vous raccompagner chez vous, qui pourrait acheter un objet que vous
cherchez à vendre, qui pourrait aimer sortir avec vous. La mise en réseau de ces ressources
permettrait de créer des « alliances provisoires au sein de groupes d’intérêt éphémères » et
permettrait de donner plus de sens à ces voisinages opportuns. Des agents logiciels
fonctionnant sur l’ordinateur porté par chaque individu dans ses vêtements pourraient former
des réseaux et tenter de mener des transactions pour le compte de chacun. Quelques
universités ont mené des projets de recherche dans cette direction. Des bibliothèques de
codes pour agents logiciels de ce type ont été écrites.
Le point critique à résoudre est la confiance : comment décider, pour un agent logiciel, si
il peut ou non faire confiance à un autre agent qu’il croise à portée de réseau ? Plusieurs
solutions ont été explorées. Ces agents pourraient s’appuyer sur des mécanismes de
réputation permettant d’évaluer de manière quantitative le degré de confiance à accorder à
un autre agent lors de l’établissement d’une transaction, en fonction notamment des
transactions réalisées dans le passé par cet autre agent.
Un frein important à la réalisation de ce type de système est le manque de performance et
d’autonomie des matériels informatiques actuellement portables par l’individu (PDA de type
Palm ou Pocket PC notamment).
J’espère que les problématiques logiques telles que l’établissement de relations de
confiance entre agents pourront être résolues par les avancées du Web Sémantique.

« tangle proxy » et les fourmis

Le système tanglesuit les navigations web de ses utilisateurs et propose aux utilisateurs qui consulteront des pages déjà parcourues des liens les menant directement aux pages ensuite consultées par les premiers visiteurs, comme autant de raccourcis. Ce principe rappelle les algorithmes inspirés du déplacement des fourmis qui laissent une trace derrière elles de manière à ce que cette trace se renforce et qu’ainsi des chemins balisés apparaissent vers les lieux de nourriture les plus abondants. Cependant, il me semble que, dans le cas de tangle, ce type d’algorithme ne pourrait être utile qu’à la condition qu’un même utilisateur ait une raison particulière de parcourir plusieurs fois le même chemin lorsqu’il trouve une page « intéressante ». Si ce n’est pas le cas, alors tangle ne doit pas permettre d’éviter le phénomène suivant : un utilisateur a été tenté par un lien hypertexte à l’intitulé intéressant, il a cliqué dessus et a trouvé une page décevante puis d’autres utilisateurs reproduisent la même situation donc tangle renforce le lien qui pointe vers cette page non intéressante et de plus en plus d’utilisateurs « tombent dans le piège ». Il faudrait ne renforcer que les liens parcourus plusieurs fois par le même utilisateur car, à défaut de proposer à l’utilisateur un moyen d’évaluer la qualité d’une page après l’avoir consultée (fonctionnalité aujourd’hui non présente dans tangle), seul le fait qu’un individu revienne plusieurs fois sur la même page paraît significatif quant à la qualité de cette page et donc à l’opportunité de renforcer le lien qui y pointe.

Folding@Home ne vous ralentit pas

Ces mesures montrent que Folding@Home a un impact négligeable (non perceptible par l’utilisateur) sur les performances d’un ordinateur. Les auteurs conseillent, au passage, de faire tourner F@H sous la forme d’un service Windows à partir de sa version « text-only » (sous ligne de commande) combinée à un outil de gestion de services tel que FireDaemon.
Les différents points à examiner pour promouvoir l’utilisation de F@H dans un contexte « corporate » sont : l’impact sur les performances des postes de travail, la compatibilité avec l’architecture du réseau (F@H fonctionne -presque- correctement avec un proxy HTTP classique), l’intégrabilité sur le poste de travail même si celui-ci est téléadministré (faisable a priori, à condition de créer, dans les scripts d’intégration, les usernames correspondant à chaque profil), la consommation en bande passante (je ne dispose d’aucune mesure pour le moment), la consommation électrique (non négligeable a priori) et, critère sans doute déterminant, la communication non seulement auprès des utilisateurs (communication interne) mais aussi, éventuellement, auprès du public.

Réseaux humains

Valdis Krebs l’affirme, l’horizon de visibilité dans un réseau de personnes est de deux : il est difficile d’obtenir une information complète et fiable sur les événements relatifs aux amis des amis de vos amis. Si le savoir dont vous avez besoin ne se situe pas en deça de cet horizon, vous supposerez en général qu’il n’existe pas et vous réinventerez la roue ou paierez pour que l’on vous fournisse cette connaissance. Pour faire face à cette limite de la communication interpersonnelle, les organisations ont souvent la tentation de chercher une solution technologique.

Qu’est-ce qu’un weblog ?

Selon Meg Hourihan, le point commun essentiel entre tous les weblogs, c’est le format de présentation : anté-chronologique et daté, il laisse le lecteur apprécier la fraîcheur du contenu et la fréquence des mises à jour. De plus, le lecteur peut réagir par email (avec un lien vers la boîte aux lettres du carnetier) ou, souvent, par un lien « commentaire » par lequel chaque item s’accompagne un forum. Contrairement à un « site perso » classique, le weblog amalgame en une seule page de multiples éléments aux sujets variés. Chaque message publié sur un weblog s’accompagne d’une date de publication et d’un « permalink » c’est-à-dire d’une adresse URL qui ne variera jamais et permet de lier ce message depuis des sites extérieurs sans crainte que le lien ne casse. Le permalink permet à d’autres auteurs de weblogs de signaler le message que vous avez publié et de le commenter directement depuis leur site. Ainsi, d’un weblog à l’autre, les carnetiers font référence à leurs messages respectifs de manière précise et entretiennent une conversation en réseau, sans lieu unique de rencontre. Parfois, des communautés étroites de webloggers se forment et organisent des rencontres « in real life » sous la forme de dîners ou autre, pour pouvoir faire plus ample connaissance et échanger face à face.

Pourquoi passer de l’ASP à PHP ?

Pour une entreprise qui a adopté ASP, pourquoi faudrait-il passer à PHP ? Pour profiter de la grande quantité de code opensource disponible, parce que le modèle de développement PHP est proche du modèle ASP, parce que PHP est désormais disponible sur Windows, parce que PHP est suffisament performant pour l’entreprise comparativement à ASP. Le point de vue de l’auteur de cet article sur les autres langages opensources pour le Web : la laideur de perl ne convient pas pour les gros projets ; le modèle de développement de python et zope est bien mais trop éloigné de celui d’ASP ; JSP n’est pas un bon choix car les langages de scripting sont plus adaptés au Web que ne l’est Java.

Les réseaux d’entreprises

Rien à voir avec l’informatique : les entreprises sont parfois « en réseau » par leurs relations et non par l’Internet. Une revue de la littérature au sujet des réseaux d’entreprises m’apprend que les trois sujets à débats en la matière sont la définition des réseaux d’entreprises, le repérage des réseaux d’entreprises et les politiques de soutien au développement des réseaux d’entreprises. Pour certains auteurs, ce qui permet de caractériser un réseau d’entreprises, c’est l’interaction et les relations fonctionnelles établies entre des sociétés (sous-traitants ?) et des industries. Pour d’autres, c’est la proximité géographique qui définit le réseau d’entreprises. Pour d’autres enfin, c’est l’existence d’une « infrastructure sociale » qui facilite les échanges d’information qui définit le réseau d’entreprises. Un réseau d’entreprises ne serait efficace qu’à la condition qu’il soit le cadre d’interactions sociales, de relations de confiance et qu’il soit le vecteur d’une vision partagée (de …?). L’un des facteurs clefs pour le succès du développement d’un réseau d’entreprises semble être l’existence de relations interindividuelles en présence (de visu). Les politiques de soutien au développement des réseaux inter-entreprises sont l’objet de critiques notamment de crainte qu’ils n’accroissent une sur-spécialisation d’une économie locale (multipliant ainsi les facteurs de risques pour cette économie). On reproche également à ces politiques de ne pouvoir concerner que les PME. Enfin, les critiques évoquent l’idée que le développement des NTIC rendrait obsolète le besoin d’une proximité géographique. Personnellement il me semble qu’au contraire, le développement des NTIC devrait permettre le développement de relations « en réseau » plus efficaces entre entreprises géographiquement proches. La téléprésence ne remplace pas l’établissement de relations « in real life » pour apprendre à se faire confiance.

Ca émerge ou pas ?

De la présentation d’un symposium sur « le Web Sémantique qui émerge » (trouvez-moi une meilleure traduction SVP), je retiens les points suivants :

  • le WS permet aux machines d’automatiser, d’intégrer et de réutiliser des données entre applications
  • le WS requiert un langage de formalisation des connaissances
  • ces connaissances permettent, en s’appuyant sur des ontologies, de décrire le contenu de sources d’information et les conditions de fonctionnement de services Web
  • le modèle UML, les langages de description d’ontologies pour le web, le modèle et la syntaxe RDF, le dialecte XDD (tiens, je ne le connaissais pas, celui-là) sont des outils proposés pour le réalisateur d’applications web sémantiques
  • les services web trouvent dans le WS des dialectes XML de description, des solutions de découverte de nouveaux services appuyés sur des ontologies.
  • les ontologies permettent l’indexation sémantique de site web et peuvent s’appuyer sur des des framework d’annotation sémantique et des offres de solutions aux performances adéquates pour une utilisation à grande échelle
  • plusieurs ateliers logiciels sont proposés par les chercheurs pour l’intégration d’ontologies ; ces frameworks offrent une forte évolutivité (« scalabilité »), la résolution des contradictions entre ontologies et le support de formalisation hétérogènes d’ontologies

Autrement dit, la promesse du WS pour l’entreprise (notamment), selon ce symposium, c’est de permettre l’intégration des données de l’entreprise grâce à une formalisation des connaissances appuyée sur 1/ des spécifications techniques (langages, modèles) dédiée à l’expression de connaissances, 2/ des outils logiciels d’intégration de référentiels (ontologies).

Passé et avenir des services Web

Uche Ogbuji retrace l’historique des services web. En voici un résumé très schématique. IBM MQSeries était l’un des précurseurs de la tendance. En leur temps, vinrent CORBA et leurs pendants Microsoftesques COM et DCOM. Le protocole RMI pour Java naquit et les succès de niche de MQSeries donnèrent le jour à des technologies équivalentes chez Sun et Microsoft. Les services distribués prirent ensuite la forme de services Web (HTTP + XML) tout d’abord avec l’offre visionnaire e-Speak de HP (un peu trop en avance sur son temps ?) puis avec l’émergence du rustique mais simple et robuste XML-RPC au sein de la communauté opensource. Du côté des grosses entreprises, leurs besoins de transactions inter-organisations les menèrent de l’EDI façon Internet à l’ebXML (sponsorisé par Sun). C’est fin 1999 que SOAP (sponsorisé par Microsoft) fit son apparition. Une partie de la communauté opensource constituée autour de XML-RPC adopta peu à peu SOAP car cette spécification technique, pour une fois, semblait très ouverte. Plusieurs standards furent proposer pour décrire les services Web et c’est WSDL qui, sous le sponsorship d’IBM et de Microsoft s’affirma comme candidat le plus sérieux puis UDDI fut proposé en complément, pour constituer des annuaires de services Web. Aujourd’hui, c’est le trio SOAP + WSDL + UDDI qui est présenté comme la spécification moderne des services Web. SOAP connaît un certain succès « de terrain » auprès des développeurs notamment, malgré les problèmes d’interopérabilité qui subsistent lors des implémentations, tandis qu’à l’autre extrémité, UDDI, qui est sensé être un support pour des politiques « corporate » de gestion des services Web, à encore plus de mal à trouver ses marques.
D’après Uche Ogbuji, deux visions s’affrontent aujourd’hui parmi les promoteurs des technologies pour services Web : les uns pensent que les équipes amenées à implémenter des services Web devraient se composer d’experts en technologies XML (approche adéquate pour traiter des problématiques de communication inter-entreprises) ou de développeurs s’appuyant uniquements sur des boîtes à outils hermétiques (approche fréquente pour des périmètres spécifiquement internes aux entreprises). Microsoft (avec .Net) et IBM offrent de telles boîtes à outils. BEA, Iona et Apache offrent des fonctionnalités similaires. Etant donné le manque de maturité des technologies des services Web, les éditeurs de boîtes à outils risquent d’être l’objet d’importantes contraintes d’évolution lorsque des normes consensuelles émergeront et que leurs boîtes à outil devront tenter de s’y conformer. OASIS souhaite définir un modèle universel de composants pour services Web (WSCM) qui couvriraient des besoins tels que ceux aussi bien ciblés par CORBA ou COM que ceux ciblés par les composants visuels à la JavaBeans ou à la Delphi. De plus, l’avenir des services web pourrait être fortement influencé par l’évolution des bases d’objets et des technologies telles que le Web Sémantique. Pour l’instant, seul SOAP a fait l’objet d’implémentations fréquentes. Des spécifications technologiques complémentaires telles que UDDI, bien qu’émises depuis longtemps, n’ont toujours par pris forme en pratique et on peut s’interroger sur leur avenir.
Personnellement, je doute même de la pérennité, et surtout du bien-fondé, de SOAP qui, malgré sa séduisante et trompeuse simplicité d’implémentation auprès des développeurs, repose sur des principes architecturaux très éloignés du principe de « couplage faible » (loose coupling) qui a fait le succès des technologies Web. Le modèle REST semble bien plus satisfaisant à cet égard (chercher « REST » dans ce blog pour plus d’infos à ce sujet) bien que nécessitant un mode de conception d’applications + services Web inhabituel pour les développeurs, plus familiers du « j’ai une fonction/méthode, je lui passe des paramètres et j’obtiens un résultat en sortie » à la RPC.

Progiciel et EHS

La fonction Environnement, Hygiène et Sécurité (EHS, EH&S, HS&E, appelez-là comme vous voudrez) n’est pas parfaitement couverte par les progiciels de gestion intégrée (ERP) tels que SAP. Cet article fait le point sur la question et donne quelques conseils à ceux qui sont amenés à lancer des projets d’acquisition de progiciels environnementaux également appelés EMIS (Environmental Management Information Systems).
Ce sont les investisseurs et non les managers (et encore moins les managers EHS) qui ont fait évoluer les systèmes comptables depuis les années 30. Ce n’est qu’avec l’Activity-Based Costing et l’Activity-Based Management que les managers EHS ont eu une opportunité de communiquer sur les technologies et actions de prévention de la pollution. Dans l’offre progicielle actuelle de SAP, le système comptable peut être interfacé avec un module EHS essentiellement tourné vers la gestion des substances dangereuses (à travers les fiches MSDS) mais fournissant également des fonctionnalités orientées santé, hygiène industrielle et sécurité. Les sociétés TechniDATA en Allemagne et Enterprism Solutions aux USA étendent ces fonctionnalités notamment en s’orientant vers la gestion des déchets. De grands pans de l’EHS ne sont donc pas encore couverts. Le reporting actuel « manque de robustesse » et les fonctionnalités EHS sont d’une grande pauvreté comparativement aux systèmes dédiés EHS ou aux logiciels EHS développés sur mesure.
Il ne faut pas se leurrer, nous rappelle l’article : ce sont les points de vue financiers et comptables qui influencent le plus les services informatiques. Et la sélection d’un progiciel EHS peut prendre des mois et impliquer un grand nombre de consultants et de prestataires. Ces projets sont donc complexes et requièrent une très forte clarification des rôles de chacun de ses acteurs, faute de quoi le projet peut tourner au renvoi réciproque des fautes et responsabilités, comme l’a montré l’exemple de Hershey Foods.
L’option du développement spécifique n’est pas à éliminer d’emblée : bien que risquée et coûteuse, elle permet d’obtenir des fonctionnalités très adéquates au besoin et offre une solution évolutive car implémentée de manière incrémentale. L’approche la plus couramment retenue dans les entreprises dotées d’un ERP consiste à se doter d’un progiciel EHS particulier, qui sera ensuite interfacé avec l’ERP comptable et financier. Des éditeurs EHS tels que Essential Technologies et Quantum Compliance Systems sont ainsi certifiés compatibles pour et par SAP.
Des organismes tels que l’EHS Software Development Group (EH&SSDG) peuvent être d’utiles conseillers dans de tels projets. Donley Technologies connaît également bien le marché des progiciels EHS et on trouvera quelques informations intéressantes sur http://www.ehsfreeware.com.

Un PDA, ça sert à quoi ?

Ils ont utilisé des PDA (Palm, Pocket PC, …) pendant longtemps. Finalement, à quoi ces curieuses petites choses leur ont-elles servi ? Un extrait des réponses :

  • lire des livres numérisés
  • jouer à des jeux électroniques
  • jouer aux échecs dans les toilettes
  • pointer son temps sur des projets et des clients pour pouvoir le refacturer
  • gérer RDV et contacts pour les nomades

On reproche aux PDAs :

  • la difficulté pour saisir des données de manière fluide et conviviale
  • la pauvreté de l’offre logicielle (surtout pour les Palm)
  • la lourdeur des synchronisations avec le poste de travail (attendre 10 à 30 minutes en fin de journée alors que c’est le moment de rentrer à la maison…)

Nombreux semblent être ceux pour qui les propriétaires de PDA essaient davantage de justifier l’utilité d’un symbole statutaire plutôt que de profiter d’usages réellement profitables de cet objet. Nombreux sont ceux, aussi, qui ont finalement abandonné leur PDA sur un coin de leur bureau après s’être amusés avec pendant quelques semaines. Pourtant, nombreux sont également ceux qui disent être devenus dépendants (notamment parmi les « nomades » ayant le plus de rendez-vous et de contacts à gérer au quotidien) ! Enfin, certains ont préféré le « Blackberry » de chez RIM, essentiellement pour son petit clavier ainsi que pour sa robustesse.

L’amateurisation de la publication

Sur son weblog, Clay Shirky discourt au sujet… des weblogs et
de l’amateurisation de masse de la publication. Naguère, au temps jadis d’avant, le processus de publication créait une
valeur non seulement parce que ce processus était coûteux (d’où une barrière à l’entrée et des opportunités d’échelle sur un
marché sans cesse plus concentré) mais aussi, du même coup, parce que l’éditeur devait sélectionner le contenu pour ne
publier que celui qui représenterait le plus de valeur sur le marché. Le développement de l’Internet et, aujourd’hui, des
weblogs, change la donne : le coût de publication est considérablement amoindri, les barrières à l’entrée se sont effacées,
et les auteurs n’ont plus à passer au travers du scepticisme professionnel de l’éditeur pour atteindre son public. Quels
modèles économiques peuvent se révéler intéressants dans ce contexte ? Créer une pénurie artificielle, en ne donnant accès au
contenu qu’aux seuls abonnés ayant payé est une solution envisageable. Mais l’abaissement des barrières à l’entrée rend très
probable l’apparition de « nouveaux entrants » sur le marché susceptibles de publier à coût plus bas voire nul. Restent les
revenus indirects : publicité, sponsorship et marketing direct. Le webloggeur (ou carnetier) peut également envisager de
demander des donations à ses lecteurs, éventuellement via une coopérative de webloggeurs. Enfin, il reste… la publication
sur papier. En effet, les rares personnes à gagner aujourd’hui de l’argent dans le monde des weblogs sont ceux qui ont publié
des livres décrivant le phénomène ! Mais la plus grande récompense pour le weblogueur n’est-elle pas simplement de participer
à la conversation ?

Agrégateurs de news RSS

L’OpenDirectory signale notamment les logiciels opensource suivants, parmi les nombreux agrégateurs de News RSS aujourd’hui disponibles : Aggie (.Net), AmphetaDesk (perl), MyHeadlines (PHP+MySQL), Peerkat (Python) et Reptile (en architecture peer-to-peer) . Parmi les logiciels signalés par l’OpenDirectory, j’ai notamment repéré fyuze, NewsApp de server.com,
NewzCrawler. Il faut également signaler les nombreux produits de syndication « in-bound » (=aggrégation) pour Zope, même si aucun n’offre de fonctionnalités « off-the-shelves », comme on dit (il faut coder un peu pour intégrer ces produits dans un site fait avec Zope).
Jon Udell citait (dans un article sur byte.com auquel, visiblement, on n’a plus accès à moinds de s’enregistrer auprès de byte.com ; le titre « personal RSS aggregators… ») les principaux aggrégateurs RSS. Amphetadesk et Peerkat m’ont paru les plus intéressants d’entre eux. J’ai installé Amphetadesk : ça marche bien malgré le
fait qu’Amphetadesk a repéré des centaines de canaux RSS lorsque je naviguais sur des sites de syndication tels que moreover,
newsisfree et syndic8. Du coup, ma liste de canaux disponibles est immense et bien peu utilisable ! Il manque encore des
fonctionnalités mais c’est un très bon début pour imaginer ce que seront les aggrégateurs personnels de demain. Reste à
tester Peerkat. Jon Udell, dans son article, cite de manière désordonnée les principales fonctionnalités attendues pour ce
genre d’agrégateurs (ou syndicateurs ?). Essayons d’y mettre un peu d’ordre :

  • présenter le contenu sur trois panneaux, à la façon des lecteurs de newsgroups (Usenet)
  • proposer des listes de canaux pré-enregistrés
  • lire les formats RSS 0.92, 1.0,
  • organiser les canaux par catégories
  • ouvrir une fenêtre d’alerte lorsqu’une actualité apparaît
  • organiser les actualités et canaux sous la forme d’un arbre « à l’Explorer »
  • lire les groupes de news NNTP (Usenet)
  • lire des sites web d’actualités (screen craping, web clipping)
  • ajouter de nouvelles sources facilement
  • faire lire les actualités par un synthétiseur vocal
  • faire défiler les actualités à l’écran sous la forme d’un prompteur
  • importer/exporter la liste de canaux
  • écrire des actualités
  • publier un canal
  • offrir une API (en XML/RPC par exemple)
  • supporter l’API de Blogger
  • sélectionner des actualités une à une, les filtrer, les annoter et afficher voire publier le résultat
  • avoir une interface claire, intuitive et conviviale
  • je vous laisse imaginer le reste

On ne tardera pas à voir apparaître des offres logicielles « corporate » pour la syndication de contenus. Sinon, il me reste encore à installer et tester peerkat.
Tiens, il y a aussi quelqu’un qui tente de définir Le Parfait Agrégateur RSS.