matinee hub retail

Matinée au Hub Retail à Lyon le 25/01

Le Hub Retail est une association professionnelle rhône-alpine qui fédère des commerçants et acteurs du secteur concernés par le cross canal et les questions connexes. De même qu’en septembre dernier Equip Mag (salon spécialisé pour le retail physique, point de vente) et eCommerce Paris étaient regroupés, pour hub retail, il n’y a plus de ecommerce, uniquement du commerce.

Notre client King Jouet en est membre fondateur d’Hub Retail et m’a proposé d’y assister.

Hub Retail organise tous les mois des matinées d’échange. Ce 25 janvier la rencontre a eu lieu à Lyon.

Le coeur de la matinée était un retour de visite au NRF à New-York d’Olivier Dauvers, journaliste spécialisé brillant qui n’a pas sa langue dans sa poche.

Il a parlé de 4 innovations qui l’ont marqué par leur intelligence, non pas technique mais « marketing » de solution à une problématique de la relation client.

– utilisation de capteurs (type accéléromètres / volume du pied) pour caractériser finement l’adéquation d’une chaussure de running avec la morphologie/foulée du client. Le commerçant en tire une information d’une grande valeur qui pousse le client à s’approprier le produit plus facilement.

– application de yield management à des denrées périssables. L’exemple montré était basé sur un rayon boulangerie équipé d’étiquettes pilotables à distance. L’historique de vente analysé permet de prévoir finement l’impact du prix sur les ventes, et donc de réduire la perte pour des produits à durée de vie courte.

– utilisation de reconnaissance d’image pour détecter les rayon vides à partir de caméras montées sur l’ensemble des caddies du magasin : ces caméras grand angle parcourent sans cesse les rayons, transmettent en temps réel les images captées et permettent de voir dans quel linéaire on a des manques. La détection se fait en quelques secondes, sans besoin de parcourir physiquement le magasin. Le réassort peut ainsi se faire très rapidement.

– Utilisation de reconnaissance d’image pour compter le contenu du caddie sans besoin de RFID sur chaque produit. Une caméra est placée sur la poignée du chariot. Elle filme en continu le caddie et détecte les produits qui y sont posés (ou enlevés) afin de permettre un paiement sans caisse et sans attente. L’intérêt de ce système réside dans l’absence de puce RFID sur chaque produit.

L’intervention se termine sur la présentation de la librairie physique Amazon ouverte à Seatlle. C’est un très bon exemple d’application du meilleur du online sur un produit off line. On trouve dans cette librairie :

– quelques milliers de titres mais uniquement les meilleures ventes (les autres sont dispos en ligne)

– tous les livres sont montrés de face vs sur la tranche dans une librairie traditionnelle (torticoli garanti)

– les livres sont classés par thématique et ont tous un extrait des avis clients et les étoiles des internautes. Chaque livre est ainsi bien mis en valeur.

– au delà des thématiques, de nombreuses « aspérités » dans la présentation de l’offre sont présentes : les 100 livres qu’il faut avoir lu dans sa vie, si vous avez aimé tel livre, vous aimerez  celui là ou celui là, parmi les policiers, une sélection d’histoires vraies, … 

– et bien sûr captation de toute information via un compte client unique partagé Amazon bookshop et Amazon online.

La matinée se poursuit par une table ronde retour d’expérience sur la politique omni canal basée sur l’expérience de King Jouet d’un côté, et de la Boite à Outil de l’autre. 

Cette table ronde est également animée par Olivier Dauvers qui n’hésite jamais à challenger les visions des différents intervenants, quitte à pointer des contradictions ou des situations difficiles. 

Dans les deux cas des histoires différentes, des contextes concurrentiels différents, et des approches disctinctes sur l’apport du cross canal.

La politique de prix et d’offre entre site internet et magasin physique par exemple est traitée différemment par les deux marchands.

Enfin, la matinée se termine par un cocktail networking qui est l’occasion de rencontrer les fondateurs d’Improveeze, l’inventeur français du concept de « phygital » dans le retail, alliance du monde physique et du monde digital en magasin.

Une excellente matinée donc, tous le remerciements à Olivier Bourgeois, fondateur et délégué général du Hub Retail

Architecture multi-tenant, une fausse bonne idée ?

Chez Antidot, nous avons une équipe R&D qui rassemble des développeurs de profils assez variés. Le terme de « développeur » ne doit pas être pris dans un sens réducteur, car ce sont des hommes et des femmes passionnés par leur métier, et qui non seulement codent bien des logiciels complexes mais qui, en plus, sont capables de prendre du recul sur leur métier et s’intéressent à l’évolution des technologies de l’informatique et de l’Internet, qu’elles impactent directement leur activité ou pas.

Aujourd’hui, nous avons choisi de partager sur le blog Antidot un billet écrit par Benoît Sautel, l’un de ces ingénieurs, qui partage depuis plus d’un an ses idées de « développeur passionné », comme il se définit lui-même, sur son blog « Fier de coder ».


 

Les concepts de Software as a Service ou de Cloud Computing sont de plus en plus répandus dans l’informatique d’aujourd’hui. Cela a pour conséquence que les éditeur de ogiciel ne vendent plus directement un logiciel mais le service que rend leur logiciel. Cette nouvelle façon de déployer du logiciel a changé la donne dans la façon dont sont conçus ces mêmes logiciels.

Vers un déploiement simplifié

Les architectures multi-tenant (multi-entités ou multi-locataires en français) ont vocation à faire en sorte qu’un logiciel soit capable de gérer un certain nombre de clients en une seule installation. Au lieu d’installer le logiciel une fois pour chaque client, ce dernier est capable de créer des environnement virtuels distincts pour chaque client de sorte à ce que de l’extérieur les autres environnements ne soient pas du tout visibles. En fin de compte, le logiciel répond lui-même aux problématiques de déploiement.

Dans le contexte d’un prestataire de service qui souhaite vendre son service à différents clients, l’architecture multi-tenant semble être la réponse évidente. Il suffit de déployer le logiciel une fois et de créer autant d’environnements que nécessaire, et le tour est joué. L’administration d’un tel système est, du coup, relativement simple.

Au prix d’une grande complexité dans le code

Je travaille en ce moment sur une application web basée sur une architecture multi-tenant. Et clairement ce type d’architecture a un coût dans le développement. Ce coût étant principalement dû à la complexité engendrée. C’est la raison pour laquelle je m’interroge à ce sujet.

Pour assurer l’isolation et l’indépendance des différentes instances, il me semble assez important de séparer les données de chaque instance dans une base de données dédiée. C’est une meilleure garantie de l’indépendance des données, mais c’est également pratique lorsqu’il s’agit de récupérer les données d’une instance pour transférer l’instance sur un autre serveur.

Tout cela implique qu’il n’est pas possible de considérer la base de données comme unique. On ne peut donc pas y accéder via un singleton dont on délègue d’ailleurs volontiers la gestion à notre outil de gestion de dépendances. Le connecteur à la base de données n’est plus un singleton, ce qui signifie que tous les composants qui s’en servent ne peuvent plus non plus être des singletons. D’ailleurs, la configuration du logiciel ne peut plus être non plus un singleton puisqu’il y en a une par instance. Bref, la perte de cette unicité limite très franchement le gain apporté par les outils et principalement ceux qui se chargent de l’injection de dépendance. Un peu comme si on retournait dans le passé.

Le code métier a bien souvent besoin de connaître sur quelle instance il travaille. Un objet représentant l’instance actuelle est ainsi passé en paramètre de la plupart des appels métier. La complexité de l’ensemble du code augmente ainsi fatalement et la testabilité prend du plomb dans l’aile. Difficile de faire du code simple dans une telle architecture.

De plus, une architecture multi-tenant ouvre une nouvelle gamme de risques de sécurité. Il n’est en effet pas envisageable qu’on puisse accéder à des données d’un autre environnement et encore moins de pouvoir les modifier. Pourtant, c’est le même code sur la même machine qui va gérer l’ensemble des environnements. Le risque est bien présent.

SaaS et architecture multi-tenant sont-ils vraiment compatibles ?

L’architecture multi-tenant a de nombreuses qualités quand il s’agit d’exploiter le logiciel en Software as a Service. Le logiciel sait nativement gérer lui-même l’ensemble des instances. Mais cela implique des contraintes auxquelles on ne pense pas forcément au départ.

Lors d’une mise à jour, si une régression est introduite, elle affectera immédiatement l’ensemble des clients. C’est un risque qu’il faut accepter de prendre, mais il peut être largement réduit en travaillant sur la qualité du logiciel. De la même façon, il est préférable de mettre à jour un logiciel à un moment où il est peu utilisé. Un logiciel multi-tenant implique de mettre tout le système à jour en même temps. Si les clients sont localisés un peu partout dans le monde, il est difficile de trouver un moment où tout le monde dort.

En général, un logiciel en SaaS est régulièrement mis à jour et évolue au fur et à mesure. Dans certains cas c’est tout à fait acceptable, si on considère par exemple que le service fourni par le logiciel se présente sous la forme de web services dont la rétrocompatibilité est assurée, les clients n’ont pas de raison de ne pas accepter les mises à jour. C’est davantage problématique quand le produit se présente sous la forme d’une interface graphique qui évolue régulièrement. Certains clients refusent catégoriquement que leur instance évolue et donc soit mise à jour.

Une architecture multi-tenant ne permet pas de mettre à jour certaines instances et pas d’autres. Il faut alors créer différentes installations du logiciel, chacun sur une version donnée. Et si on n’a pas de chance et qu’on n’arrive pas à trouver un petit nombre de versions pour satisfaire tout le monde, on se retrouve vite à déployer chaque client dans une installation distincte. Et là on a tout perdu. On a payé le surcoût lié à la complexité d’une telle architecture et on ne peut pas en profiter. Pire encore, on se retrouve à devoir quand même gérer une multitude d’installations, précisément ce qu’on souhaitait éviter au début.

Dev ou Ops ?

Se demander si les architectures multi-tenant sont pertinentes revient finalement à se demander où nous devons placer le curseur entre les parties Dev et Ops.

Dans les débuts de l’informatique, la moindre machine coûtait tellement cher qu’il était important d’optimiser chaque ligne de code assembleur des programmes de façon à économiser la moindre instruction processeur. Un gros investissement dans le développement des logiciels était nécessaire pour qu’ils soient capables de tourner sur des machines coûtant un prix raisonnable.

Mais, depuis ce temps-là, le monde de l’informatique a beaucoup changé. Les machines coûtent de moins en moins cher alors que leur puissance augmente, les réseaux se sont énormément développés, si bien qu’on n’achète même plus nous-même les machines mais qu’on paie un service d’hébergement (Infrastructure as a Service).

La virtualisation est venue ajouter une nouvelle dimension dans l’hébergement. Aujourd’hui, Docker est en passe de révolutionner une nouvelle fois ce domaine. On parle de plus en plus de Platform as a Service.

Tout cela est possible parce que le prix du matériel baisse sans cesse alors que sa puissance augmente. L’outillage s’est également adapté à ces changements et il est maintenant possible de gérer un parc de machines de manière quasiment automatique.

En parallèle de cette évolution en terme de technique, l’informatique est également de plus en plus populaire et même omniprésente. Mais le nombre de développeurs n’augmente pas aussi vite. Et jusqu’à nouvel ordre, il n’existe pas vraiment d’outils permettant d’automatiser le travail du développeur. Et heureusement pour nous !

Le curseur entre Dev et Ops s’éloigne petit à petit du développement. Il n’a jamais été aussi facile de déployer et d’exploiter du logiciel en masse (et ça sera certainement encore plus simple dans le futur).

Quel est le bon choix ?

Si la tendance actuelle se poursuit dans la même direction (ce qui me semble tout à fait probable), le déploiement sera de plus en plus automatisé et coûtera de moins en moins cher. Il me semble donc que dans le futur les architectures multi-tenant seront de moins en moins intéressantes.

Mais dès aujourd’hui, il me semble que le choix de partir sur une architecture multi-tenant n’est plus une évidence. Le logiciel en lui-même doit-il porter toutes les contraintes liées à son déploiement et la complexité qui va avec ? Grâce aux évolution des outils de déploiement, il est maintenant tout à fait possible de mettre en place en parallèle du logiciel une infrastructure de déploiement automatisée associée qui se charge de gérer ses différentes instanciations avec à chaque fois une configuration et une version bien précise. Ne vaut-il pas mieux développer deux systèmes distincts pour ne pas accumuler toute la complexité au même endroit ? Cela permet d’avoir à la fois un logiciel simple et toute la souplesse nécessaire au niveau du déploiement et de la gestion des différentes versions. N’est-ce finalement pas le moyen d’avoir le beurre et l’argent du beurre ?

L’image d’en-tête provient de Flickr.


Retrouvez les autres billets de Benoît sur son blog.

Et si vous avez envie de travailler chez Antidot, regardez les postes à pourvoir et écrivez-nous !

Faire et Savoir-faire

En informatique, Faire n’est pas compliqué.

C’est le Savoir-faire qui est long et difficile à acquérir.

La preuve ? Demandez à un informaticien de développer quelque chose qui va lui prendre disons 10 jours. Une fois le travail terminé, effacez tous les fichiers (on va plutôt dire que le serveur les a perdus et que la sauvegarde ne marchait pas…). Demandez-lui de recommencer. Eh bien, il le fera en 5 ou 6 jours tout au plus et le résultat sera meilleur que la première fois. Faire n’est donc pas compliqué.

En revanche, le coût d’acquisition des Savoir-faire informatiques a explosé ces dernières années avec la multiplication et la complexification des technologies.

Le bon vieux programme Basic des années 80 pour afficher des caractères sur un écran 80×24 n’est plus. Les programmes d’aujourd’hui sont incroyablement complexes : ils doivent fonctionner sur le Web comme sur mobile, pour des centaines d’utilisateurs, avec des performances et des fonctionnalités toujours plus riches. La diversité des compétences mises en œuvre explose littéralement. Qui maitrise aujourd’hui toutes les technologies et les savoir-faire nécessaires ? Si bien qu’à l’instar du bâtiment, le secteur informatique possède aujourd’hui ses corps de métier : ergonomes, graphistes, architectes, développeurs système ou réseau, algorithmiciens, développeurs Java ou C++ ou .Net ou PHP ou…

Et tout cela ne va guère en s’améliorant. Les environnements de développement et les plate-formes logicielles peinent à suivre le rythme et à réduire cette complexité. Si bien que dès qu’un projet implique un peu d’informatique, il faut mobiliser et inclure dans l’équipe des compétences technologiques fortes et seules des personnes ayant des compétences en programmation peuvent participer.

Prenons le cas du tout récent Big Data : certains, comme Harper Reed qui fut directeur technologique de la campagne électorale de Barack Obama, n’hésitent pas à dire que le Big Data c’est de « la connerie ». Sans aller jusque là, reconnaissons que le buzzword est désormais partout, et qu’il sert souvent d’alibi à des fournisseurs de matériel et de logiciel qui veulent renouveler à bon compte le marketing parfois essoufflé leurs offres. Pour autant,  il y a de l’or à tirer des données des entreprises, pour peu qu’on sache les faire parler, les analyser, les valoriser et les consolider avec des données externes afin de les contextualiser. qui peut faire ça ? Les « Data Scientists » nous dit-on. Une race nouvelle, hybride, possédant des compétences en statistiques et en informatique, avec une sensibilité avancée pour les données et une compréhension des enjeux métier. Mais existent-t-ils vraiment ? Il semblerait que non à lire 01net Entreprises (« Il y a urgence à enseigner le Big Data !« ) ou ITPro (« Le Big Data freiné par une offre complexe et une pénurie de compétence« ).

Source : wikibook « Data Science: An introduction »
Le fond du problème, c’est que les plateformes logicielles proposées sont trop complexes et exigent encore trop de mobiliser des compétences informatiques et techniques. Tout ça dans un contexte où les profils informatiques se font de plus en plus rares. Il faut arriver au point où la complexité technologique disparaît et où les solutions sont exploitables par des gens ayant avant tout des compétences métier et non des compétences technologiques. Un peu comme avec un iPhone : simple à utiliser et pourtant bourré d’innovation et de technologie.

C’est en ayant en tête ce contexte, et ces enjeux critiques d’agilité et de productivité, que nous concevons nos solutions logicielles chez Antidot.

Prenez l’exemple de notre solution d’analyse et d’intégration des données AIF  – Information Factory  : nous l’avons pensée et conçue de telle façon que vous pouvez construire des chaînes de traitement de données particulièrement avancées qui vont capter, nettoyer, sémantiser, classer, géotagger, enrichir, lier… des données sans nécessiter aucune connaissance en programmation.

Et notre plus grande fierté c’est de voir des projets incroyables réalisés par des gens du métier, sans compétence en développement.

Car finalement les meilleures technologies sont celles qui savent se faire oublier.

 

Documation 2012 : AFS@Enterprise et Linked Enterprise Data

Linked Enterprise Data

Retrouvez-nous mercredi 21 et jeudi 22 mars sur le salon Documation 2012, stand E16 : vous y découvrirez AFS@Enterprise et le Linked Enterprise Data.

Et si vous ne pouvez pas venir à Documation mais souhaitez en savoir plus sur le Linked Enterprise Data, dites-le nous ici :

[contact-form subject= »Demande depuis le blog Antidot » to= »[email protected] »] [contact-field label= »Nom » type= »name » required= »true » /] [contact-field label= »Société ou Organisation » type= »text » required= »true » /] [contact-field label= »E-mail » type= »email » required= »true » /] [contact-field label= »Site web » type= »url » /] [contact-field label= »Précisez votre demande » type= »textarea » required= »true » /] [/contact-form]

La semaine prochaine sur Documation

Antidot présente la nouvelle version de sa solution AFS@Enterprise.

Votre SI est une mine d’informations inexploitées. AFS@Enterprise en extrait toute la valeur !

Pour améliorer la performance de votre entreprise, les métiers demandent une information toujours plus riche, plus pertinente et plus opérationnelle.

Répondez à cette attente en apportant les nouveaux objets métiers contextuels à leurs besoins :

  • pour le marketing et les ventes, agréger les données des réseaux sociaux avec celles de la CRM
  • pour les RH, cartographier le réseau des compétences et des collaborateurs
  • pour le support client, consolider les bases de connaissances sur les produits
  • et pour vous ? Quelles seraient les informations utiles à votre équipe ?

 

AFS@Enterprise est la première solution industrielle qui vous apporte la révolution du Linked Enterprise Data.

Le Linked Enterprise Data (LED) est une approche innovante qui facilite la réutilisation des données et documents dispersés dans les différents silos de l’entreprise. Le LED met en cohérence et lie ces données éparses, quels que soient leur format et leur structure, dans un entrepôt unifié, agile et évolutif. Il fait émerger l’information enfouie dans les fichiers et les bases de données : l’utilisateur accède directement à une information métier pertinente et utile !

 

Venez découvrir la puissance du Linked Enterprise Data et les fonctionnalités d’AFS@Enterprise sur notre stand E16.

Vous pouvez également assister à la table ronde à laquelle participe Fabrice Lacroix mercredi 21 mars 2012 de 14:30 à 17:00 sur le thème « Agrégation et réconciliation des données » ainsi qu’à notre présentation jeudi 22 Mars 2012 de 11:30 à 12:15 sur « Le Linked Enterprise Data, une révolution annoncée dans les Systèmes d’information des entreprises. Exemples notamment chez un grand industriel« 

Mais à quoi bon le big data ?

Un des mots à la mode dans notre domaine du traitement des données est big data. Il s’agit de la capacité à traiter des quantités massives de données structurées ou non structurées. Mais massives comment ? A partir de combien est-ce du big data ? Qui en a besoin ? Quelle est la réalité opérationnelle derrière ces mots ?

Rappelons d’abord que l’origine du big data est liée à une logique de programmation distribuée dite map-reduce qui a été développée par des sociétés du Web comme Google, Yahoo!, Facebook etc : ces grands sites mondiaux ont des tonnes de données à analyser et ne pouvaient pas se contenter des approches « bases de données centric » habituelles. Dropbox gère 100 millions de sauvegardes de fichiers par jour, Twitter annonce 200 millions de tweets quotidiens, Facebook supporte 250 millions d’uploads de photos par jour et en stocke plus de 40 milliards… Le big data est donc d’abord une approche informatique qui prend le relais quand une implémentation classique basée sur l’utilisation de quelques serveurs, même très costauds, ne suffit plus pour assurer les temps de traitement attendus. Ainsi, ces acteurs exploitent des clusters regroupant chacun plusieurs milliers de serveurs et manipulant des péta-octets [1] de données.

D’un point de vue logiciel, le big data est souvent associé à la pile technologique Hadoop mise en open source par Yahoo! et reprise par nombre d’entreprises à vocation commerciale (EMC, Cloudera, Hortonworks…). Hadoop et ses dérivés apportent un système de stockage distribué, une base de données répartie, ainsi qu’un cadre de programmation et d’exécution de tâches de calcul réparties.

 

Mais à quoi cela sert-il et quel sens cela a-t-il pour la plupart des entreprises qui ont quelques téra-octets de données à analyser ?

Quelques éléments de réponse :

  • Le big data est une technologie et non une solution. C’est un moyen et pas une fin. Donc dire « je vais faire du big data » n’a pas de sens car celui-ci ne répond à aucun besoin fonctionnel en particulier. C’est comme dire « je vais faire de la base de données » ou « je vais faire du Web ». Pour quoi faire ? La démarche doit rester pragmatique : partez de votre besoin, voyez s’il est satisfait de façon acceptable par des solutions existantes. Et si rien de ce qui existe ne convient (trop cher, trop lent) alors demandez-vous si une approche alternative exploitant les technologies du big data peut être envisagée.
  • Le big data nécessite de très fortes compétences. Tout d’abord, le niveau de maturité des technologies proposées nécessite des ingénieurs qualifiés pour installer, paramétrer, optimiser et faire tourner ces couches logicielles. A fortiori si vous comptez bâtir des solutions opérationnelles critiques. Il en va de même pour le développement des applications car celles qui veulent tirer partie de l’approche doivent être ré-écrites selon les principes du map-reduce. Souvenons-nous que chez Google ou Facebook, ce sont leurs meilleurs ingénieurs logiciels et  mathématiciens qui développent les applications big data.
  • Pour faire du big data, il faut beaucoup de données. Des téra-octets, voire plutôt des dizaines de téra-octets. À moins de 10 ou 15 serveurs, le passage au big data n’a pas de sens.
    Un exemple : Oracle vient de sortir une appliance big data petit format : 18 serveurs, 864 Go de mémoire, 648 To de stockage pour la modique somme de 455 000 $. Et encore… il reste à intégrer et à développer les applications qui reposeront sur cette architecture.


    Avec l’arrivée des processeurs massivement multi-cœurs, du in-memory computing ou des SSD, la frontière se déplace et pour la majorité des cas, un seul serveur moderne suffit encore. Alors que dans le cas d’un cluster, il faut prendre en compte le coût élevé de possession (TCO) : achat des machines, installation et administration, électricité, froid, maintenance… A fortiori s’il s’agit de n’effectuer que quelques heures ou jours de calcul par mois, la rentabilité d’une telle approche est difficile à atteindre. Big data et cloud computing pourraient alors avoir un avenir commun, mais a condition que les entreprises veuillent bien envoyer dans le cloud leurs téra-octets de données à analyser.

En définitive, il ne s’agit pas de savoir sur combien de serveurs les calculs sont faits, mais de savoir lesquels. Pour quel usage ? Quelle valeur créée ?
C’est pourquoi ce sont plutôt les éditeurs de logiciels qui vont s’emparer du big data, afin d’offrir des solutions opérationnelles répondant aux besoins des entreprises et passant à l’échelle du péta-octets. Les éditeurs de logiciels déjà actifs dans la BI, le data mining ou les moteurs de recherche intégreront ces techniques pour fournir des version « big » de leurs solutions.

Et d’ailleurs qu’en est-il côté Antidot ? Nos solutions sont conçues dès l’origine pour fonctionner aussi bien sur un seul serveur que sur des clusters de machines pour traiter des millions de données et répondre à des centaines de requêtes par seconde. Et nous travaillons déjà à intégrer à nos solutions les apports de l’approche big data.

Mais au delà de la surenchère marketing, nous nous attachons surtout à fournir des solutions qui créent de la valeur pour nos clients. Ainsi, notre framework d’analyse de documents offre des modules prêts à l’emploi couvrant des besoins aussi variés que la classification, la normalisation, l’annotation, l’enrichissement sémantique ou la géolocalisation des données… Agilité et vitesse d’exécution sont des enjeux qui nous semblent plus importants que force et volume.

Conclusion : ce n’est pas la peine de complexer si vous n’avez pas plusieurs centaines de téra-octets de données à analyser et si vous vous sentez exclu du big data. Car en définitive, seule la valeur que vous saurez tirer de vos données a vraiment de l’importance !

[1] un péta-octet, en abrégé Po, représente 1015 octets, soit mille téra-octets ou un million de giga-octets…

Grande semaine pour l’Open Data français !

Cette première semaine de décembre 2011 aura marqué le vrai démarrage du mouvement Open Data en France, avec en l’espace de 3 jours une succession dense d’événements importants : lundi a eu lieu  le lancement par la mission Etalab, dirigée par Séverin Naudet,  de la plateforme officielle data.gouv.fr. Mardi soir se tenait la seconde édition des Data Tuesdays, qui montent en puissance et où Antidot était présente. Enfin mercredi a été ouverte la plateforme de réflexion collaborative de la SNCF data.sncf.com.

Chez Antidot, l’approche Open Data nous enthousiasme vraiment, car nous sommes convaincus que c’est le début d’un mouvement qui, en ouvrant les données publiques, va permettre à l’intelligence individuelle et collective des citoyens d’exprimer sa créativité.

Désormais, les données commencent à être publiées, et les standards, technologies et outils sont disponibles : et du coup, tout le monde va comprendre que l’Open Data n’est plus un problème de « comment faire« , mais bien de « que faire » et surtout « pourquoi le faire« .

Or le « que faire » et le « pourquoi le faire » peuvent justifier d’interconnecter des jeux de données issus de producteurs très différents, et de mailler des informations de nature très diverses pour les réutiliser d’une façon qui n’avait pas encore été imaginée. Et du coup, on en vient à considérer qu’il faut partager des données les plus brutes possibles, sans le filtre d’APIs qui présupposent des usages et en limitent d’autres. Espérer que des APIs propriétaires associées à chaque jeu de données vont être vraiment utiles est illusoire, pour une raison très simple : si, pour bâtir une application exploitant 13 jeux de données différents, il faut intégrer 13 APIs de fournisseurs différents, alors le résultat du développement sera un monstre totalement impossible à maintenir et à faire évoluer dans le temps, et donc au final inutile.

Il faut donc que les organisations qui se lancent dans l’Open Data publient des données non seulement ouvertes mais pleinement réutilisables : à cet égard, on ne saurait se contenter de proposer de sous forme d’une collection, aussi riche soit-elle, de fichiers XLS, PDF ou même CSV qui vont nécessiter beaucoup de travail pour que les données qu’ils renferment soient vraiment exploitées. Comme l’a dit fort justement Tim Berners-Lee à TED 2009 : « Raw data now! »

Le W3C a défini des standards pour l’accès aux données brutes, via l’approche du « web sémantique » ou « web des données » qui seul permet une réutilisation généralisée des données, par la mise en réseau massive des silos de données ouvertes où qu’ils se trouvent sur le web. 
Ces standards publiés par le W3C s’appellent RDF, OWL et  SPARQL. ils sont désormais matures et de nombreux outils existent pour les mettre en œuvre.

Nous considérons que la donnée brute en RDF, publiée dans le « nuage du Linked Open Data » ou « LOD cloud » est la seule vraie façon pérenne de permettre une réexploitation massive des données. Et nous ne sommes pas les seuls à le penser, si l’on en juge par la croissance formidable du LOD en l’espace de 4 ans : cliquez sur ces images de 2007, 2009 et 2011  pour les agrandir et mesurer la puissance de ce phénomène.



Pour découvrir l’approche ouverte du « web des données », nous vous conseillons le lire 3 billets de blog très pédagogiques écrits par notre collaborateur Gautier Poupeau, grand spécialiste du web des données et de l’Open Data. Vous pouvez aussi consulter les différentes présentations d’Antidot sur Slideshare.

Enfin, nous vous rappelons que  notre solution Antidot Information Factory (PDF – 4 pages) permet, de manière industrielle, de mailler très largement des données de provenance et de nature très diverses, de les exploiter et de les valoriser, notamment dans le cadre de projets Open Data ou Linked Data. Par ailleurs, nous avons publié en Open Source une bibliothèque en Java appelée db2triples qui simplifie la transformation en graphe RDF de données issues de bases de données relationnelles classiques. Nos solutions et notre expertise sont à votre disposition, n’hésitez pas à faire appel à nous dans le cadre d’un projet pilote ou d’un « proof of concept » !