Commentaires (13)

J'ai créé et dirige la société OpenDataSoft qui se positionne exactement comme une solution dédiée aux problématiques de l'open data (http://www.opendatasoft.com/?page_id=12), idéalement pour permettre la création de portails personnalisés (donc en marque blanche).

Il ne faut pas confondre "sur étagère" et "boîte noire" car l'objectif d'une telle solution est bien de donner la main aux opérateurs d'un portail de services open data sur l'orchestration de ces derniers:

• multiples modes d'acquisition des données (formulaires web d'upload de fichiers dans divers formats déplorables facilement, connexion sur des flux de données du SI, crowdsourcing)
• outils de conversion des jeux de données vers des formats intéropérables
• outils d'enrichissement des données (géocodage, liens vers des ressources externes notamment sur le web)
• module de navigation dans les données (moteur de recherche à facettes directement dans les données et widgets de visualisation tels que tableaux, cartes et graphiques)
• accès aux données soit en mode téléchargement ou via des APIs pour insertion directe dans le code de développeurs
• module de monitoring de l'utilisation des données (notamment en mode APIs).

Disposer de l'intégration de tous ces composants sur une même plate-forme maximise les chances de tenir la promesse de l'open data, envers les producteurs de données, envers les réutilisateurs de données et envers les utilisateurs finaux.

En outre, une telles solution se doit ouverte aux écosystèmes en place et permettre la meilleure intéropérabilité possible avec les plates-formes existantes sur le cloud, aussi bien pour se sourcer en données (google docs, wikipedia ...) que pour exposer les données dans des "applications" générées automatiquement (google charts, formulaire facebook, flux twitter ...).
C'est tout l'intérêt notamment de positionner une telle solution en mode SaaS afin de ne pas restreindre le potentiel d'un hub open data pas des questions de sécurité du SI.

Enfin, un hub open data se doit d'être "accueillant" avec tout l'écosystème de partenaires qui y abonderont en données Le positionner dans le cloud est donc également un atout.

J'espère avoir l'opportunité de répondre à des demandes de précisions sur ce qui précède. (j'écris aussi de temps en temps ici http://www.opendatasoft.com/?cat=6).
Jean-Marc Lazard (http://fr.linkedin.com/in/jmlazard)

Il me semble que c'est précisément le but de Windows Azure Marketplace: https://datamarket.azure.com/

En effet, OpenDataSoft et l'Azure Market Place partagent cette approche SaaS et se distingueront vraisemblablement l'une de l'autre en termes d'offre sur les points suivants:

• offre "double" avec au choix cloud générique et cloud privé (garantie de localisation des données et sécurisation des services) ou seulement cloud générique
• typologie de formats de fichiers et flux traités automatiquement en input de la plate-forme: fichiers spécifiques comme ceux issues de SIG (shapefiles zippés pris en charge automatiquement) ou bien seulement fichiers plats de type .csv uniquement
• toolkit de nettoyage et enrichissement des données intégré à la plate-forme et utilisable en back-office par les personnes qui mettant à disposition les jeux de données, ou pas
• accès dynamique aux données par les réutilisateurs uniquement à travers des end-points ou via des APIs "riches"
• diversité des modes d'acquisition de données disponibles par défaut sur la plate-forme (files upload, connecteurs SI, push de flux à partir d'un bus applicatif tiers, crowdsourcing)
• et globalement la richesse des APIs du cloud que pourra accueillir la plate-forme de façon automatique (google docs, google charts, yahoo pipes, amazon DB ...)

Personnellement, je suis plus dans une démarche de PAAS en marque blanche, l'approche est plus globale et en même temps plus personnalisable, à la demande et sur-mesure. N'est-ce pas trop restrictif de parler de portail opendata ? Je parle en terme de finalité pour l'utilisateur final.

Oui, tout à fait d'accord avec Vincent, la notion de portail open data est bien trop restrictive, nous devrions a minima parler de portail de services open data
Et oui l'enjeu est bien de l'ordre du PaaS sur lequel peuvent se décliner diverses offres SaaS. Je dois avouer que j'use aussi un peu trop du terme SaaS, mais ce dernier est souvent plus connu et mieux compris que PaaS.
La notion de portails de services avec une solution open data en marque blanche a effectivé ma faveur sur l'approche "place de marché de données" (déjà faudra-t'il démontrer qu'il y a un marché de la données avec un cours de l'offre et de la demande, à date il y a en fait un marché des services de traitement et d'analyse de la donnée).
L'approche "marque blanche" a en effet le mérite de concilier les 3 composants qui devront nécessairement être associés pour que l'open data accouchent de projets/réalisations à a hauteur des promesses qu'on lui associe en termes de développement économique:

• un orchestrateur qui va insuffler l'open data dans tous ses projets (une collectivité par exemple) mais qui n'a que peu de données à partager en réalité
• un (des) opérateur(s) qui délivre effectivement les services aux usagers/clients (transport, énergie, tourisme, ...) qui sont ceux qui ont les données intéressantes
• une plate-forme pour déployer des hubs open data / open services, et là l'idée d'une plate-forme prête à l'emploi fait sens selon moi

Je vous signale également la plate-forme opensource que nous avons développée :
http://opendata.in-cite.net/
Elle est actuellement utilisée par la ville de Rennes, Rennes Métropole, Keolis Rennes, la ville de Nantes et bientôt le Conseil général 44. Nous travaillons également actuellement avec le CG 49.

Je partage le fait que les solutions technologiques Cloud (PaaS ou SaaS) sont parfaitement adaptées aux besoins d'un portail open data : facturation à l'usage, difficulté de prédire la charge, isolation avec le SI de l'entreprise...

Concernant les plateformes disponibles sur le marché, quelles sont les différences majeures entre les solutions évoquées plus haut et le produit CKAN conçu par l'Open Knowledge Foundation ? Même question pour les solutions de publication d'API type Mashery ou 3Scale ?

Concernant la principale différence entre l'approche CKAN (similaire à In-Cite?) et l'approche OpenDataSoft, elle réside dans le type "d'objet" manipulé au coeur de la plate-forme.

• les outils comme CKAN sont avant tout construits autour de la notion de jeu de données au sens "fichier". De façon probablement réductrice on pourrait dire que ce sont des CMS auxquels ont été ajoutés des fonctionnalités de publication de données à travers des APIs. Cette dernière fonctionnalité étant le plus souvent un ajout au coeur de l'outil, les limites les + courantes sont donc: forte contrainte sur le format de fichier pour réexpédition directe des données à travers une API (csv le + souvent), pas de possibilité de gérer la redistribution des data provenant d'un flux "temps réel", pas de services de nettoyage et normalisation des données. Pour ces raisons, lorsque ces solutions sont utilisés pour la réalisation de portails open data, elles sont adjointes à d'autres (modulo intégration spécifique le + souvent) pour couvrir un champ d'usages plus large.
• l'approche "data centric" a pour objectif de lever ces contraintes avec la conception de plates-formes dédiées à l'orchestration des flux de données et le développement rapide d'applications. Ainsi, un effort particulier est fait sur tous les moyens d'acquérir simplement de la donnée (upload de fichiers aux formats divers, branchement sur les flux du SI, crowdsourcing en provenance d'individus ou d'objets connectés) et les possibilités de croisements de données à travers des APIs personnalisables. En outre, le fait de stocker aussi bien les jeux de données originaux, les jeux de données normalisés et les données elles-mêmes, permet immédiatement des possibilités de navigation interactive dans les données à travers des cartes, des graphiques ...
• cette dernière approche est donc très complémentaire d'un Mashery, plate-forme sur laquelle il serait tout à faite envisageable de déployer une API personnalisée produite via une plate-forme comme OpenDataSoft

Enfin, j'ai évoqué le développement rapide d'application sur le cloud, les possibilités d'une solution comme Heroku (heroku.com) me paraissent totalement en ligne avec l'idée de produire des APIs open data à partir d'une plate-forme d'orchestration des flux de données.

Passionnantes perspectives selon moi, un nouveau type de gouvernance des SI, et des organisations, se préfigure à travers toutes ces initiatives.

en effet, et cette plate-forme entre dans la catégorie CKAN (en moins abouti d'ailleurs), bâtie sur base du CMS Drupal (tout comme In-Cité sur base du CMS Typo3) pour gérer la mise en ligne des datasets et des métadonnées associées.

Voici par ex.le features présentées sur Github pour data.vo in-a-box (https://github.com/opengovplatform/opengovplatform)

• Application build on Drupal-6.22
• Create a metadata record for a data asset via a web form or a file upload
• Apply an approval workflow for metadata records
• Manage users and organizations
• Create metric reports
• Manage contents through Drupal's native functionalities

Et tous les accès aux data en mode APIs des divers sites data.gov (medicare.gov ...) est le fait d'autres solutions utilisées par les administrations américaines en mode SaaS.
On a donc d'un côté la solution de catalogage des jeux de données et de l'autre celle d'exploitation directe des données.
Les solutions les plus récentes en SaaS tente de proposer cela de façon intégrer afin de concilier publication de datasets et de données en mode flux.

Ce cas est en effet un très bon exemple pour répondre à la question de @VincentD

Au plaisir de poursuivre cet échange qui, à travers des considérations techniques, touche la question des enjeux que l'on veut couvrir avec une démarche open data.

Je me permets du coup de pointer vers cet article du CTO de CapGemini "Big data or Open Data & Clou data" qui rejoint me semble-t-il la discussion que nous avons en ce moment: http://www.capgemini.com/ctoblog/2011/10/big-data-open-da...

Jean-Marc : notons tout de même que CKAN est désormais data-centric lui aussi : http://ckan.org/features/
Étant un logiciel libre, gratuit, avec une vraie communauté d'utilisateurs et développeurs, y compris parmi les administrations puisque le gouvernement anglais et bientôt la commission européenne l'utilisent pour leur plateforme OpenData, CKAN semble rester encore aujourd'hui le choix le plus sage :)

@Roux: en effet, ayant pas mal d'échanges avec les équipes d'OKFN sur CKAN, je reconnais que la direction prise est bien "data centric" et je suis d'accord qu'en solution logicielle à installer et customiser "on premises", ce choix peut être tout à fait pertinent.
Au plaisir de poursuivre cet échange stimulant ;-)

Il y a également une initiative intéressante avec Drupal via les plateformes opendata aux USA.

• http://groups.drupal.org/opendata-working-group
• http://www.whitehouse.gov/blog/2011/12/05/datagov-goes-gl...
• http://www.data.gov/opengovplatform