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…

Découvrez les Monuments Historiques grâce à l’Open Data !

Pourquoi cette application ?

L’ouverture du site data.gouv.fr le 5 décembre 2011, aussitôt suivie d’autres initiatives, a marqué une accélération du mouvement Open Data en France.

Nous avons voulu apporter notre pierre à l’édifice, en réalisant une démonstration qui met en avant le grand intérêt qu’il y a à pouvoir mailler des données issues de différentes sources grâce aux standards du web sémantique, et la capacité de notre solution Antidot Information Factory à le faire rapidement et simplement, dans une approche industrielle.

Et parce que la France demeure année après année la première destination touristique mondiale, parce que nos territoires regorgent de trésors architecturaux et patrimoniaux, nous avons choisi de réaliser une application de recherche qui vous permet de partir à la découverte de près de 44.000 monuments historiques français !

Quelques explications (un peu) techniques :

Notre application « Monuments historiques » a été réalisée en exploitant 7 sources de données ouvertes :

  1. la liste des Immeubles protégés au titre des Monuments Historiques disponible sur data.gouv.fr. Cette source de données décrit 43.720 monuments dans un fichier CSV.
  2. la liste des gares de voyageurs du Réseau Ferré National avec leurs coordonnées  telle que fournie par data.gouv.fr. Cette source de données décrit 3.065 gares dans un fichier XLS. Elle est exploitée pour situer les monuments à proximité d’une gare.
  3. la liste des stations du métro parisien avec leurs coordonnées, fournie par OpenStreetMap. Cette source de données décrit 301 stations et elle est exploitée pour situer les monuments à proximité d’une station de métro.
  4. les données du code officiel géographique (COG) de l’INSEE. Cette source de données décrit 22 régions, 99 départements, plus de 4.000 cantons et chefs lieux dans un graphe RDF.
  5. Les photos des monuments historiques de Wikipedia proposée par Wikimedia Commons. Cette source de données, notamment alimentée par le concours Wiki loves monuments, apporte 122.828 photos pour 12.586 monuments historiques désignés par leur code PA : il s’agit d’un code délivré de façon unique pour chaque monument et présent dans la liste citée en 1.
  6. La description des monuments historiques de Wikipedia fournie par DBpedia. Cette source de données en RDF décrit 3,64 millions d’objets, dont 413.000 lieux. Cette source est accessible directement à partir des informations de Wikimedia Commons
  7. Les informations de géolocalisation de Yahoo! via Yahoo! PlaceFinder. Cette source permet de géolocaliser à partir de leur adresse les monuments non géolocalisés dans Wikimedia Commons ou DBpedia

La chaine de traitement mise en œuvre pour la réalisation de cette application avec Antidot Information Factory est la suivante :

  1. Une première étape de nettoyage, normalisation et transformation en RDF des fichiers CSV et XLS issus de data.gouv.fr au moyen de Google Refine.
  2. Récupération des données de Wikimedia Commons : un processus de traitement Antidot Information Factory collecte les informations via l’API de Wikimedia et les transforme en RDF : Antidot Information Factory a permis de construire ce processus industriel sans avoir à écrire une seule ligne de code, simplement en assemblant des modules de traitement pris dans une bibliothèque de 50 modules existants.
  3. Récupération des données d’OpenStreetMap pour les stations de métro via son API.
  4. Collecte de toutes les informations de géolocalisation par Antidot Information Factory via l’API de Yahoo! PlaceFinder, pour les lieux non déjà géolocalisés.
  5. Maillage de toutes les données issues des 7 sources par Antidot Information Factory : le résultat est un graphe RDF comprenant plus de 4,5 millions de triplets, dont près de 450.000 ont été inférés à partir des sources.
  6. Ce triple store est ensuite la source unique mise en entrée du module d’indexation du moteur de recherche Antidot Finder Suite.

Le résultat est une application web de recherche permettant  de trouver des monuments historiques

  • par une recherche en plein texte
  • dans une région, un département ou une ville donnés
  • par type de monument : église, château, statue, site industriel
  • par période historique : préhistoire, moyen-âge, renaissance etc
  • par type de propriétaire : personne ou société privée, commune, Etat…

avec combinaison possible de tous ces critères, sous forme de « facettes de recherche » très simples à manipuler.

Conclusion (provisoire)

Cette application a été réalisée en quelques jours, sans impliquer de développeurs et par simple paramétrage de notre solution Antidot Information Factory. Cela montre, s’il en est encore besoin, la puissance et la justesse de l’approche et des technologies du Web Sémantique promues par le W3C.

Cette application démontre que l’Open Data favorise l’émergence de nouveaux usages : par la mise à disposition de données qui sont facilement reliées à d’autres données, la seule limite devient notre imagination et notre capacité à proposer de nouveaux services innovants et utiles !

Merci à tous les fournisseurs de données qui ont rendu possible cette réalisation, notamment le Ministère de la Culture et de la Communication pour la liste des monuments historiques et la Société Nationale des Chemins de Fer pour la liste des gares, avec une mention toute particulière pour les contributeurs de Wikipedia, que vous pouvez soutenir par un don.

A vous maintenant de partir à la découverte de nos monuments historiques, au gré de vos envies !


Crédits : Etalab | Wikimedia Commons | DBpedia | Open Street Map | INSEE | Wikipedia francophone | Wikipedia anglophone

Application réalisée avec Antidot Information Factory – Nous contacter : [email protected]


Le contenu de ce billet est sous licence CC BY-SA. Traduction en anglais disponible ici.

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 » !