La base de données est une source comme les autres, clin d’œil à Molière et à son Bourgeois Gentilhomme

<w

On a beaucoup parlé de la convergence entre business intelligence et moteurs de recherche d'entreprise. J'en ai discuté avec de nombreux clients et partenaires me demandant si oui ou non, à l'instar de Monsieur Jourdain faisant de la prose sans le savoir, Sinequa faisait de la Business Intelligence sans s'en douter. Je pense avec d'autres que Business Intelligence et DataBase Offloading sont parfois confondus.

Le « Database offloading » revient à utiliser un moteur de recherche pour requêter le contenu d'une base de données. La base de données étant d'abord conçue pour gérer des transactions, elle n'est pas optimisée pour donner accès à son contenu en vue de renseigner des applications de requêtage. Par exemple, une base de données qui gère l'intégralité des transactions d'une banque contient des informations permettant par exemple de disposer de façon agrégée de l'historique client.

• La solution Informatique 1.0 pour cela consiste à recopier le contenu de la base de données dans un entrepôt de données ou datawarehouse, puis à permettre le requêtage de cette datawarehouse. Cette solution que les contraintes technique d'hier rendaient obligatoire (cout du hardware, performances des bases de données,…) est aujourd'hui une enclume pour écraser une mouche.
  
• La solution Informatique 2.0 consiste à utiliser un moteur de recherche performant pour indexer la base de données et faciliter ainsi l'accès aux contenus utiles. Il faut un peu de paramétrage pour mettre cela en place. Le moteur de recherche doit être précis et fiable, robuste et scalable, totalement web en terme d'architecture et de technologie. Un moteur nouvelle génération pourra en outre générer des distributions sur des critères quantitatifs liés à telle ou telle colonne. Sinequa comme d'autres permet cette approche. Un des pionniers de cette solution astucieuse est l'excellent Jean-Paul Figer, ex CTO de Cap Gemini et aujourd'hui patron de son propre cabinet d'architecte informatique ; dans un style REST J (cf. REST, un style plus qu'un standard). Jean-Paul Figer a su tirer le meilleur parti de cette approche et il est capable de diviser le cout d'un projet par 10 ou plus ; et surtout de réduire le temps d'implémentation. Un bon moteur de recherche, Sinequa ou un autre, contribue dans ces cas de figure à des gisements de productivité impressionnants. Pour autant, et si brillante soit-elle, cette démarche n'est pas à proprement parler de la Business Intelligence mais plus du « Database Offloading » et de la réécriture d'applications en mode REST justement.
  

Je termine ce billet en soulignant une deuxième étape possible si on dispose d'un Bus de moteur de recherche gérant correctement la sécurité: étendre les possibilités applicatives au-delà des contenus de bases de données, indexer d'autres informations moins structurées, et proposer ainsi la vision 360° d'un client ou de tout autre sujet pertinent. Ici encore, scalabilité, gestion de la sécurité, connectivité, rendent tout cela possible.

Par honnêteté intellectuelle, je précise que l'idée de ce billet m'a été donnée par l'article d'Adriaan Bloem, Analyste chez CMS, qui rappelle qu'utiliser une technologie de moteur de recherche pour permettre d'accéder à moindre cout aux données contenues dans la base de données est astucieux, certes, mais correspond plus à du « Database offloading » qu'à de la Business Intelligence.

Google Docs, Sécurité et respect des droits : la possibilité d’une faille est-elle acceptable ?

Comme cela est relaté par exemple dans 01Net, Google Docs partage un peu trop les documents ou dans TechCrunch (en anglais), Google Documents a eu une faille de sécurité. Certains utilisateurs ont pu voir ce que d'autres avaient produit, en dépit des règles de partage et d'accès. Les bugs c'est monnaie courante en informatique c'est vrai, mais ce genre de problème est il grave ou pas ?

Je pense qu'il y a deux enjeux : un est factuel et lié à ce qui a été indument partagé, aux préjudices objectifs. L'autre est plus immatériel, il s'agit du manque de confiance généré par la possibilité d'une faille. Comment en effet au niveau individuel travailler sereinement si le fruit de notre travail risque d'être violé ? Comment accepter du point de vue de l'entreprise que certaines données confidentielles fassent l'objet de fuites ?

Le principe même de l'Entreprise 2.0 est le partage et l'échange de l'information, mais il vaut parce qu'il y a confiance dans les outils et an particulier à une condition expresse : le respect de l'intégrité des données de chacun. Plusieurs DSI de clients de Sinequa, en particulier dans la banque, le conseil et l'administration, ont justement choisi notre solution du fait des garanties qu'elle offre en matière de respect de la sécurité. Inversement, je connais une banque qui avait installé une solution de recherche (je ne dis pas laquelle) pour les répertoires partagés : le premier jour de la mise en ligne, un collaborateur a posé la question « bonus CODIR » obtenant ainsi la liste des bonus des dirigeants…

En matière de sécurité, il faut exiger le risque zéro. Si par exemple la solution de recherche n'est pas conçue pour gérer la sécurité au niveau applicatif et document, si les droits ne sont pas pris en compte au cœur de l'index et mais a posteriori, on est en danger. C'est une des raisons qui a amené Sinequa a développer ses propres connecteurs applicatifs. Si la solution de recherche ne permet pas de rafraichir les droits en permanence en fonction des nouvelles règles (tel qui avait droit n'a plus droit, tel document qui était partagé ne l'est plus…), il y aura toujours un risque de mauvais cas de figure, des périodes pendant lesquelles un utilisateur pourra poser une question et récupérer une information qui ne devait pas lui parvenir…

Personnellement, je pense qu'en matière de risque de non respect des droits d'accès, la possibilité d'une faille n'est pas acceptable. Et vous, quel est votre avis ?