Valiz : Moteur de recherche open-source

Aller au contenu | Aller au menu | Aller à la recherche

Mot clé - sémantique

Fil des billets - Fil des commentaires

dimanche, octobre 19 2008

Compte-rendu de la discussion jabber du 18 octobre 2008

J'ai été invité par le salon exalead de JabberFR à venir discuter de Valiz et plus généralement du principe d'un moteur de recherche open-source. Cela s'est donc déroulé hier, samedi 18 octobre 2008 de 20h30 à 22h30. J'ai décidé d'en faire un compte-rendu ici ce qui permet de faire le point sur l'état du projet mais aussi d'informer les absents.

L'indexation et le contenu

Nous avons parlé de la cible de Valiz, le contenu accessible. Indexer uniquement des sites pleinement conformes aux recommandation sur l'accessibilité est illusoire, il y en a trop peu. Mieux vaut se concentrer sur des sites faisant des efforts d'accessibilité.

Un moteur modulaire

L'intérêt d'un moteur de recherche modulaire a été souligné. Ce lui assure son évolution, lui permet d'évoluer dynamiquement. Cela permet également d'interfacer beaucoup d'outils au travers d'API.

BOINC et le calcul distribué

Une des faiblesse de Valiz sera sa faible infrastructure hardware comme nos moyens seront forcément limités. Une idée avancée lors de cette discussion était de sous-traiter des calculs à une plate-forme de calcul distribué via BOINC par exemple. Une partie du travail pourrait ainsi être traité en-dehors des serveurs de Valiz. Il ne s'agirait évidemment pas de calcul en temps réel mais plutôt de traitements de l'index, d'analyse de contenu, etc...

Faire participer les universités

Une autre idée qui a été proposé est de soumettre Valiz, ou du moins certains modules aux universités qui ont les moyens de le faire avancer et de mettre des serveurs à disposition. C'est probablement le chemin le plus plausible pour que Valiz devienne réalité.

Le site de Valiz

Le blog

Plusieurs personnes ont critiqué le blog comme support de discussion pour les débats. Ce n'est pas un support adapté, il devrait plutôt être utilisé pour faire des annonces sur l'avancement du projet. Ce n'est pas faux.

La page d'accueil

Cette page n'est pas suffisamment compréhensible, elle prête à confusion. Surtout la partie en anglais qui est du pure massacre (issu de Google Translate), il faudrait au minimum que je la réécrive. Je pense plutôt la remplacer par une explication beaucoup plus concise et mettrait en avant le blog et le wiki.

Le wiki

Beaucoup étaient de l'avis que le wiki était la forme la plus adaptée au projet. Il y en avait déjà un en place, un Dokuwiki. Mais il semblerait qu'il y ait besoin de quelque chose de plus costaud pour notamment y intégrer les discussions. C'est pourquoi je vais remplacer le Dokuwiki par un Mediawiki très prochainement.

Structure et cadre du projet

J'ai profité de la discussion pour situer le cadre de Valiz. Il s'agit d'un projet bénévole entretenu par des passionnés. Valiz sera un des projets de l'association Texuma, une association à but non-lucratif dont l'objectif et de faciliter le développement de projets software ou touchant à internet.

Le budget et la publicité

Le thème de la publicité a été abordé également. Allons-nous intégrer de la publicité dans les résultats des recherches ? Non évidemment. Pourquoi ?
Proposer de la publicité sur une page souhaitant présenter du contenu accessible dans ses résultats implique que la publicité aboutisse également vers des sites accessibles. Et si le site visé par la publicité était accessible, il figurerait naturellement en bonne place dans les résultats et n'aurait donc pas à payer. Par ailleurs le but de Valiz n'est pas lucratif.
Évidemment ça ne rend pas les choses simples pour autant, un moteur de recherche a besoin d'importantes ressources hardware (serveurs, baies, bande passante, switchs, routeurs ,spares, etc...) ce qui est extrêmement onéreux. Évidemment une partie du budget pourrait être constituée de dons, mais il faudrait avoir une popularité similaire à Wikipedia pour que ce soit significatif.
Même si cela reste un point capital, je préfère ne pas trop m'y attarder tant que nous n'avons pas un cahier des charges concret et réaliste.

Et maintenant ?

Vous êtes plus que jamais invité à continuer de débattre. Valiz n'est pas mort et cherche à avoir un maximum de contributeurs pour discuter du cahier des charges. Il n'y a pas besoin de compétences particulières, être un utilisateur d'un moteur de recherche suffit amplement pour dire ce qui nous manque, comment on veut obtenir l'information, ce qui ne va pas avec les résultats, etc... Pour cela je vais mettre en place le wiki sous quelques jours.
Comme l'expérience était concluante, il n'est pas impossible que de nouvelles discussions de ce type aient lieu, que ce soit sur le salon d'exalead ou ailleurs. L'idéal à moyen terme serait de réunir les personnes intéressées sur un salon dédié permanent. Le log complet de la discussion

dimanche, février 4 2007

Critères d'accessibilité

Le rôle de Valiz

Valiz, en plus d'être un moteur open-source, a un objectif : devenir une référence dans la recherche accessible (où son utilisation et les résultats obtenus sont accessibles par le maximum de personnes possibles).

Les critères d'accessibilités

De l'utilisateur

J'aimerais fournir les résultats en fonction du profil de l'utilisateur. En fonction du navigateur utilisé (texte, oral, braille, normal,...) on peut facilement déduire les handicaps principaux de l'internaute (cela sera évidemment personnalisable) et en fonction de cela, des résultats adaptés pourront être fournis.
Même si l'internaute ne souffre d'aucun handicap, valiz n'indexera pas et ne fournira pas de sites non structurés (pour rester un minimum spécialisé et aussi pour économiser de précieuses ressources).

Des sites

Dans mes premiers billets, je signalais que pour les débuts, je pensais me baser sur une validation via l'API SOAP du W3C puis par la suite faire une analyse complète de l'accessibilité des sites car certains sites valides ne sont pas accessibles et vis-versa.
Je ne sais pas encore si je maintiendrai ce critère, mais dans tous les cas, réfléchissons aux critères d'accessibilité d'un site web :

  • Le contraste (via une analyse des attributs style et des feuilles de styles css)
  • La structure du site (sémantique, navigation par clavier simple (accesskey, tab,...)
  • Attributs alt renseignés (pas seulement alt="")
  • Présence de java-script, de java ou de flash
  • Et encore ... ?

L'accessibilité porte sur énormément de critères, néanmoins il n'est pas envisageable de faire une analyse automatique pour chaque site (même si on ne contrôlait que les bonnes pratiques d'opquast par exemple). Donc quels sont les critères facilement contrôlables et pertinents pour chaque profil d'utilisateur ?

mercredi, janvier 24 2007

La mise en forme du texte : à ignorer ?

Idéalement, la mise en forme est séparée du contenu avec l'aide des feuilles de styles (css). Cependant avant le xHTML, il était coutume de mettre en page le texte avec du HTML (<b>, <i>, <u>, ...) et certains on gardés (à tort) cette habitude pour générer leur contenu en xHTML.
À mon avis les seuls basiques qui pourraient jouer un rôle dans les résultats seraient <strong> et éventuellement <b>. Cependant je suis d'avis qu'il faut ignorer toutes les balises de formatage en dehors des <h1>, <hx...> car elles sont trop souvent utilisés à tord ou de manière abusive.
Qu'en pensez-vous ?

samedi, janvier 6 2007

Critères d'accessibilité et conformité W3C

Lors des réactions que j'ai récoltées suite au billet publié sur mon blog et visible sur valiz.org, plusieurs personnes ont relevé, et je suis d'accord avec elles, qu'il était dommage de se restreindre aux sites valides W3C (comprenez : qui ne retournent en passant par le validateur W3C) car :

  • Un site accessible n'est pas forcément conforme W3C
  • Il y a des sites valides qui sont totalement inaccessible ou qui mélangent contenu et mise en forme
  • Avec de tels critères, la quasi totalité des sites professionnels (dont les sites réalisés par les agences web) ne remplissent pas ces critères

Le but de Valiz est de fournir des résultats accessibles (comprenez : qui ne présente pas d'obstacle à la navigation), je pense dans un premier temps faire une simple validation au validateur (via l'api soap du w3c) pour déterminer simplement la conformité d'une page.
Puis, cette procédure sera remplacée par une fonction allant plus loin : analyse intelligente de la page et des erreurs retournées par le validateur et en fonction de cela si le site est jugé ok pour une navigation accessible, il sera admis dans l'index.

Je suis à l'écoute de tout commentaire/critique...