Vingt-sept point sept

[Note du 1er septembre 2011 : le script décrit dans ce billet a été légèrement modifié depuis. Je travaille à d'autres changements qui feront l'objet d'un prochain billet]

Cela ne saute sans doute pas aux yeux de nos lecteurs, mais l’un des manques du catalogue (HIP = Horizon information portal) de ma bibliothèque est l’absence d’import des autorités du Sudoc.

Pour parler français, lorsque dans le Sudoc il existe une fiche détaillant les différentes identités d’une personne (par exemple « Stendhal » = « Henri Beyle », etc.) ou les (quasi-)synonymies entre certains concepts (par exemple « philosophie des arts » = « esthétique »), nous ne récupérons toujours que la forme de référence (Stendhal, esthétique).

Du coup, une recherche sur Henri Beyle ou Georges Rémi ne donnera rien, ou si peu, dans notre catalogue.

La solution idéale serait de changer de catalogue, mais comme ce n’est pas le genre de chose qui se fait en claquant des doigts, cela nous laisse le temps d’essayer de bricoler un peu.

Quand l’ABES a annoncé le lancement d’IdRef, j’ai tout de suite pensé qu’on pourrait utiliser cette application pour enrichir notre catalogue avec les autorités du Sudoc. J’ai d’ailleurs trouvé la même idée dans ce billet de Bibliothèques [reloaded]:

Exemple : (hypothèse de départ) mon opac permet d’afficher un message spécifique si l’internaute trouve 0 résultat. S’il y a 0 résultat, l’opac va interroger les autorités Sudoc, et trouver que les mots recherchés correspondent à une forme rejetée d’une notice d’autorités (exemple typique lié à des questions de translittération). Il récupère alors la forme retenue (celle qui est effectivement présente dans mes notices bibliographiques) et le propose comme rebond de recherche à l’internaute (rebond de recherche sur ma base, toujours).

Mais comme cela impliquait d’explorer à fond la syntaxe d’IdRef, et de se plonger la tête la première dans le javascript et/ou le php, je ne me suis pas senti pressé, vu que je n’ai jamais écrit un script fonctionnel de plus de 20 lignes jusqu’à présent.

Je ne sais pas si je dois remercier la météo, mais j’ai fini par m’attaquer au morceau au début de mes vacances… Le résultat est ce fichier javascript (700 lignes, mais beaucoup de blabla…) qui pourra se charger (bouton vert Install) dans Google Chrome sans autre forme de procès, ou bien dans Firefox après avoir au préalable installé l’extension Greasemonkey.

Le fonctionnement de mon script ne correspond pas exactement à la suggestion de Lully : la recherche dans IdRef est faite systématiquement, et pas seulement lorsque notre catalogue ne ramène aucune réponse.

Tout cela est très expérimental, et ne saurait être présenté à des lecteurs en l’état actuel. Mon but était avant tout de voir si cette idée pouvait avoir un début d’application, et quelles en étaient les limites (et accessoirement d’apprendre à programmer en javascript! D’ailleurs, il serait judicieux de rédiger une partie du code en php, mais c’est une autre histoire…)

La recherche simple

Le script ajoute aux pages de recherche simple et avancée de notre catalogue un nouveau panneau intitulé « Essai d’ajout de fonctions avec Greasemonkey« , qui présente plusieurs options.

nouveau panneau dans l'opac

Lors d’une recherche simple sur « Beyle », en gardant les options par défaut, le nouveau panneau nous indique :

• l’URL utilisée pour faire la requête dans idref : http://www.idref.fr/Sru/Solr?q=all:%22beyle%22&start=&rows=15&wt=json&fl=affcourt_z
• l’index utilisé : « all » (on le retrouve dans l’URL)
• le nombre de réponses trouvées : 5
• le nombre de formes alternatives conservées : 1
• l’url permettant d’avoir le résultat final dans notre catalogue : http://scdweb.univ-reims.fr/ipac20/ipac.jsp?index=.GK&term=%28beyle%20or%20stendhal%29&session=131A7763384G4.791700&menu=search&aspect=basic_search&npp=15&ipp=20&spp=20&profile=scdldap&ri=&aspect=basic_search&source=~!scdreims

recherche de Beyle

Dans cet exemple précis, le script a trouvé 5 formes correspondant à Beyle dans IdRef (dont la dernière serait sans doute à corriger…) : « Beyle, Thad L. (1934-) », « Beyle, Paul », « Beyle, Pauline (1786-18..) », « Stendhal (1783-1842) », « Stendhal, Henri Beyle (1783-1842). Vie de Henry Brulard ».

Un peu de nettoyage

Mais toutes les formes commençant par « Beyle » ne nous sont pas très utiles, puisqu’elles ne font que reprendre notre terme de recherche. De plus, si l’on réinjecte ces expressions dans le catalogue, la présence des parenthèses va gravement perturber la recherche (c’est un défaut de HIP que j’ai découvert à cette occasion… ). Il est donc nécessaire de « nettoyer » les formes obtenues, avant de les comparer avec la forme saisie par l’usager.

Par défaut, le script supprime donc tout ce qu’il trouve après la virgule, ce qui nous donne  : « Beyle », « Beyle », « Beyle », « Stendhal, « Stendhal », et ne garde que les formes nouvelles. En l’occurrence, il n’y en a qu’une : « Stendhal ».

Il est possible de modifier ce fonctionnement en cochant le bouton «  »supprime les parenthèses uniquement ». Dans ce cas les prénoms sont conservés. Cela génère une équation de recherche plus fine, mais aussi plus lourde. On peut faire l’essai en cliquant à nouveau sur « Chercher ».

recherche de Beyle en changeant une option

L’URL de recherche dans IdRef est la même, mais l’URL pour HIP est beaucoup plus longue : http://scdweb.univ-reims.fr/ipac20/ipac.jsp?index=.GK&term=(beyle%20or%20%22beyle%2C%20thad%20l.%22%20or%20%22beyle%2C%20paul%22%20or%20%22beyle%2C%20pauline%22%20or%20stendhal%20or%20%22stendhal%2C%20henri%20beyle%20.%20vie%20de%20henry%20brulard%22)&session=131A7763384G4.791700&menu=search&aspect=basic_search&npp=15&ipp=20&spp=20&profile=scdldap&ri=&aspect=basic_search&source=~!scdreims

Cela fonctionne de la même manière avec les expressions entre guillemets, qu’il faudra saisir bien de manière conforme à la structure des vedettes (« Blair, Eric » par exemple (avec la virgule!), et non « Eric Blair » pour obtenir la forme d’autorité, à savoir « Orwell, Georges »).

La recherche avancée

De même, on peut utiliser la recherche avancée, dont les champs seront « interprétés » avant d’être croisés les uns avec les autres (cela m’a demandé plus de travail, car il faut gérer plusieurs index, les opérateurs booléens, etc.)

Voici par exemple ce que donne une recherche (Auteur = beyle ET Sujet = beyle) :

Recherche Auteur Beyle et Sujet Beyle

L’URL pour HIP renvoit 26 réponses : http://scdweb.univ-reims.fr/ipac20/ipac.jsp?index=.AW&term=(beyle%20or%20stendhal)%20and%20.SW%3D(beyle%20or%20stendhal)&session=131EG779H4849.791973&menu=search&aspect=advanced&npp=15&ipp=20&spp=20&profile=scdldap&ri=&aspect=advanced&limitbox_1=&limitbox_2=&ultype=&uloper=%3D&ullimit=&ultype=&uloper=%3D&ullimit=&sort=&source=~!scdreims

On y trouve notamment la correspondance de Stendhal, puisque ce type d’ouvrage est indexé avec une vedette sujet au nom de l’auteur.

correspondance de Stendhal

Quels index interroger dans IdRef  et avec quelle troncature?

Je n’ai pas évoqué l’option proposé concernant le « mode d’interrogation d’IdRef » : par défaut, on procède à une recherche « tous mots » dans IdRef, au moyen de l’index « all ». Mais cette recherche peut être parfois trop générale, et ramener trop de réponses. Par exemple, si vous cherchez « Michel » dans un catalogue, il y a des chances que ce soit le nom de famille de la personne (Louise Michel par ex.) qui vous intéresse, et pas son prénom! Mais vous pourrez injurier votre index tous mots tant que vous voudrez, jamais il ne vous fera le plaisir de distinguer les noms et les prénoms. Il renverra donc imperturbablement 17 607 réponses comportant le mot « Michel ». Difficilement exploitable…

Comme on ne peut malheureusement pas faire des recherches par noms de famille dans IdRef (comme je l’expliquais dans le billet précédent), j’ai eu recours à un expédient : utiliser les index de type « phrase », qui sont alimentés par le contenu entier et exact des zones indexées, et non par les mots qui les composent. Concrètement (j’espère que je ne dis pas de bêtises), en explorant les index de type mot d’IdRef, on peut accéder à l’autorité « Michel, Louise (1830-1905) » en cherchant « Michel », « Louise,  » (1830-1905) », « Michel, Louise », « Michel, Louise (1830-1905) » et même « Louise (1830-1905) »!

Par contre, en explorant les index de type phrase, il faut impérativement saisir la forme complète et exacte de son nom : « Michel, Louise (1830-1905) ». Si l’on omet le prénom, ou même les dates, la réponse sera vide. Donc, si on veut trouver toutes les personnes dont le nom de famille est Michel, ou toutes les Louise Michel (quelque soit leur date de naissance), il faut utiliser une troncature.

(Je suis en train de réaliser qu’une armée de juges a dû rêver de troncaturer Louise Michel. Louise, si tu me lis, promis, ma troncature est pacifique…)

Louise Michel en 1871

En cliquant sur « plusieurs index ‘phrase’ (avec les diacritiques ; troncature grossière) » on créera une équation de recherche assez longue, qui additionne tous les index de type « phrase » disponibles dans IdRef. J’étais curieux de voir si les résultats seraient différents, et effectivement, ils le sont parfois. Pour « Michel », cette option permet de ne récupérer « que » 1090 réponses.

Je vais illustrer cette option par la recherche (Auteur Beyle et Sujet Beyle) que j’avais déjà commenté plus haut.

recherche Auteur Beyle et Sujet Beyle en changeant le mode d'interrogation

Voici l’URL d’interrogation de IdRef générée pour compléter l’index Auteur de HIP : http://www.idref.fr/Sru/Solr?q=%28persname_s:beyle*%20or%20corpname_s:beyle*%20or%20geogname_s:beyle*%20or%20famname_s:beyle*%20or%20uniformtitle_s:beyle*%20or%20name_title_s:beyle*%20or%20trademark_s:beyle*%29&start=&rows=15&wt=json&fl=affcourt_z.

L’URL pour l’index Sujet de HIP est un peu plus longue, car j’ai ajouté une interrogation de l’index « nom commun » (autrement dit, Rameau et Fmesh) de IdRef (subjectheading_s), qui aurait été inutile pour enrichir l’index Auteur (puisqu’un nom commun ne peut pas être auteur d’un document, alors qu’un nom propre peut être à la fois auteur et sujet…)

La troncature est cependant grossière, ce qui peut engendrer du bruit : un joker ( * ) est tout simplement ajouté après l’expression saisie par l’usager.

Dans le cas d’une recherche sur « Beyle », on récupère non seulement 3 des formes que l’on avait trouvées en utilisant l’index « all » (« Beyle, Thad L. (1934-) », « Beyle, Pauline (1786-18..) », « Stendhal (1783-1842) ») mais également Van Beylen, Marcel Beyleveld, Deryck Beyler, Louis Beylerian, Onnig (1947-….) Beyler, Jean-Noël (19..-….) Beyleryan, Arthur A.

En cherchant « Beyle* » ou « Michel* », on a donc encore trop de bruit, car a priori ni Jean-Noël Beyler ni Jules Michelet ne nous intéressent.

J’ai donc essayé de faire une troncature plus fine construite ainsi : (mot OU mot+espace+* OU mot+point+* OU mot+virgule+*). Logiquement, cela devrait couvrir tous les types d’autorités.

Pour « Michel », cette option donne encore 708 réponses, ce qui fait encore beaucoup, mais ce n’est pas surprenant car Michel est un nom de famille courant.

Pour « Beyle », voici l’URL d’interrogation de IdRef générée avec cette option : http://www.idref.fr/Sru/Solr?q=%28persname_s:(beyle%20beyle%5C%20*%20beyle.*%20beyle%2C*)%20or%20corpname_s:(beyle%20beyle%5C%20*%20beyle.*%20beyle%2C*)%20or%20geogname_s:(beyle%20beyle%5C%20*%20beyle.*%20beyle%2C*)%20or%20famname_s:(beyle%20beyle%5C%20*%20beyle.*%20beyle%2C*)%20or%20uniformtitle_s:(beyle%20beyle%5C%20*%20beyle.*%20beyle%2C*)%20or%20name_title_s:(beyle%20beyle%5C%20*%20beyle.*%20beyle%2C*)%20or%20trademark_s:(beyle%20beyle%5C%20*%20beyle.*%20beyle%2C*)%29&start=&rows=15&wt=json&fl=affcourt_z

Cette fois, on ne trouve que 3 réponses : « Stendhal (1783-1842) », « Beyle, Pauline (1786-18..) » et « Beyle, Thad L. (1934-) ».

Wanted : Paul Beyle. Forte récompense.

Tout serait parfait si ce n’était la disparition mystérieuse de « Beyle, Paul » que nous avions trouvé avec la première options (la recherche avec l’index global ‘all’), mais qui n’apparait pas avec l’index persname_s, que ce soit avec la troncature grossière ou plus fine.

La preuve : http://www.idref.fr/Sru/Solr?q=all:%22beyle,%20paul%22 permet de retrouver sa fiche, alors que http://www.idref.fr/Sru/Solr?q=persname_s:beyle,\%20paul* ne donne aucune réponse…

Je pense avoir trouvé un début d’explication en examinant le détail de la réponse à la première de ces requêtes. Voici le code XML généré :

<?xml version="1.0" encoding="UTF-8"?>
<response>
   <lst name="responseHeader">
      <int name="status">0</int>
      <int name="QTime">1</int>
      <lst name="params">
         <str name="q">all:"beyle, paul"</str>
      </lst>
   </lst>
<result name="response" numFound="1" start="0">
   <doc>
      <arr name="affcourt_r">
         <str>Beyle, Paul</str>
      </arr>
      <str name="affcourt_z">Beyle, Paul</str>
      <arr name="all">
         <str>150868537</str>
         <str>a</str>
         <str>Beyle, Paul</str>
         <str>Beyle, Paul</str>
         <str>autre</str>
         <str>ko</str>
         <str>ok</str>
         <str>fre</str>
         <str>eng</str>
         <str>dut</str>
         <str>FR</str>
      </arr>
      <arr name="d101_s"><str>fre</str><str>eng</str><str>dut</str></arr>
      <arr name="d102_s"><str>FR</str></arr>
      <arr name="d103_s"><str>autre</str></arr>
      <date name="dateetat_dt">2011-03-22T07:11:16Z</date>
      <date name="dateindex_dt">2011-03-22T07:13:17Z</date>
      <str name="heading_z">ok</str>
      <str name="id">2297903</str>
      <arr name="persname_t"><str>Beyle, Paul</str></arr>
      <str name="ppn_z">150868537</str>
      <str name="recordtype_z">a</str>
      <str name="subdivision_z">ko</str>
   </doc>
</result>
</response>

Quelques remarques sur ce code :

• J’imagine que les balises « arr » désignent des tableaux (arrays), comprenant un ou plusieurs composants, et que les balises « str » contiennent des chaînes (string).
• Les attributs « name » désignent des noms d’index : « all » (l’index général), « persname_t », « ppn_z », et plein d’index permettant de faire des limitations (dates, langue, nationalité, type de notice, emploi, etc.)
• Le nom complet figure deux fois dans l’index « all ». J’ignore pourquoi.
• Tous les index spécifiques sont repris dans l’index « all »
• Il n’y a pas d’index « persname_s » (index de type ‘phrase’ pour les personnes physiques)

J’en conclus que l’absence d’index « persname_s » dans cette fiche est une anomalie qui empêche de retrouver « Beyle, Paul » dans cet index.

Par comparaison, voici la fiche de « Beyle, Pauline » en XML (uniquement la partie <doc>…</doc>) :

<doc>
   <arr name="affcourt_r">
      <str>Beyle, Pauline (1786-18..)</str>
      <str>Périer-Lagrange, Pauline (1786-18..)</str>
      <str>1786-18..</str>
   </arr>
   <str name="affcourt_z">Beyle, Pauline (1786-18..)</str>
   <arr name="all">
      <str>03367454X</str>
      <str>a</str>
      <str>Beyle, Pauline (1786-18..)</str>
      <str>Beyle, Pauline (1786-18..)</str>
      <str>Périer-Lagrange, Pauline (1786-18..)</str>
      <str>beyle, pauline (1786-18..)</str>
      <str>périer-lagrange, pauline (1786-18..)</str>
      <str>mort</str>
      <str>ko</str>
      <str>ok</str>
      <str>fre</str>
      <str>FR</str>
      <str>1786-18..</str>
   </arr>
   <arr name="d101_s"><str>fre</str></arr>
   <arr name="d102_s"><str>FR</str></arr>
   <arr name="d103_s"><str>mort</str></arr>
   <date name="dateetat_dt">2011-01-13T07:34:07Z</date>
   <date name="dateindex_dt">2011-05-25T21:05:47Z</date>
   <date name="datemort_dt">1800-01-01T01:01:00Z</date>
   <date name="datenaissance_dt">1786-01-01T01:01:00Z</date>
   <str name="heading_z">ok</str>
   <str name="id">413435</str>
   <arr name="persname_s">
      <str>beyle, pauline (1786-18..)</str>
      <str>périer-lagrange, pauline (1786-18..)</str>
   </arr>
   <arr name="persname_t">
      <str>Beyle, Pauline (1786-18..)</str>
      <str>Périer-Lagrange, Pauline (1786-18..)</str>
   </arr>
   <str name="ppn_z">03367454X</str>
   <arr name="rcr_t"><str>1786-18..</str></arr>
   <str name="recordtype_z">a</str>
   <str name="subdivision_z">ko</str>
</doc>

Dans les dernières lignes on trouve bien une double indexation persname_t (personne, index mot) et en persname_s (personne, index phrase).

Dieu et l’ABES seuls savent pourquoi Paul Beyle y a échappé (absence de dates entre parenthèses ? manque de bol ? mauvais karma ?)

Mais ce n’est pas tout : en dépouillant ces fichiers XML, j’ai eu surprise encore plus mauvaise : Trrremblez mortels, car la faucheuse rôde sur IdRef!

IdRef, mis KO par la mort…

Les morts dansant la gigue dans les serveurs d'IdRef (Holbein)

Dans l’index tous mots « all », on trouve non seulement les noms et dates des entités décrites, mais aussi le PPN ou des mots clés comme  « FR » ou « fre ». Jusque là, rien de gênant. Cela pourrait même être pratique.

Là où les choses se gâtent, c’est quand des informations concernant les règles d’usage de l’autorité ou le statut des personnes vis à vis de l’état civil sont codés au moyen de mots qui ont une signification en français : « mort », « autre », « ko », « ok », « a ».

Faites donc l’expérience de rechercher dans l’interface publique d’IdRef des mots comme « mort » ou « ko » en sélectionnant le dernier index (« Tout ») du menu déroulant, et vous aurez une mauvaise surprise :

La mort rôde dans IdRef

La recherche « ko » en tous mots donne 2212960 résultats. La recherche « mort », 309329 résultats, et la recherche « autre », 1957180 résultats !

Je pense qu’il serait bon que ces clés d’index soient renommées (ou ne soient plus interrogeables par « all », mais ce serait dommage).

Enfin, je finirai ce billet par quelques remarques sur la syntaxes d’IdRef, qui ne sont pas encore toutes documentées par l’ABES.

La syntaxe d’IdRef : échapper pour que rien ne s’échappe

Toutes mes requêtes commencent ainsi : « http://www.idref.fr/Sru/Solr?q= », puis j’ajoute les paramètres, et je les termine par « &start=&rows=15&wt=json&fl=affcourt_z »

• « fl=affcourt_z » signifie que je ne veux obtenir qu’un seul élément : la forme d’autorité. Pas besoin du PPN, des formes rejetées ou d’autres champs.
• « start=&rows=15″ signifie que ne je veux les 15 premières réponses. On pourrait très bien mettre 30, 300 ou 3000, mais le risque est de récupérer un flot de données trop importantes à exploiter… Cette option est modifiable au moyen d’une la liste déroulante dans le panneau de gauche.
• « wt=json » signifie que je souhaite obtenir les résultats au format JSON. On pourrait les récupérer en XML, mais bon, c’était l’occasion de découvrir JSON…

La construction des paramètres, voila le gros morceau! D’autant plus  que les règles sont différentes selon les types d’index…

Voici comment cela se présente pour la troisième option (la plus complexe, index phrase avec troncature « fine ») :

• ((INDEX1) or (INDEX2) or (INDEX3)…. )
• chaque expression (INDEXn) est en fait elle-même composite. Voici la première : (persname_s:(beyle beyle\ * beyle.* beyle,*)

Quelques remarques :

• entre chaque index, il faut utiliser le booléen « or », mais au sein d’un même index, pour avoir le même effet, il faut séparer les termes par un espace. Sinon, le mot « or » sera interprété comme la vedette décrivant le métal précieux…
• dans les index phrase, tout doit être mis en minuscules mais contrairement aux index mot, les diacritiques (accents, cédilles, etc.) doivent être conservés, y compris les majuscules accentuées
• Dans l’url, ces diacritiques doivent être codés en  ISO 8859 et non en UFT-8. Par exemple « é » doit être codé %E9 et non %C3%A9. Ce qui a pour conséquence la non indexation de mots comprenant des caractères non représentables en ISO 8859.
• il faut ajouter « \ » devant certains caractères pour empêcher que le script leur attribue une valeur spéciale. En informatique, c’est ce qu’on appelle un « échappement ». Cela s’applique :
  • aux parenthèses ouvrantes et fermantes
  • à l’espace

Ainsi, pour rechercher le géographe « Reclus, Élisée (1830-1905) » avec cet index, et sans troncature, il faut utiliser cette URL : http://www.idref.fr/Sru/Solr?q=persname_s:reclus,\%20%C9lis%E9e\%20\%281830-1905\%29

Par contre, pour les index mot, comme l’index « all » :

• il ne faut pas « échapper » les espaces et les parenthèses
• on peut utiliser les guillemets doubles  »  » pour encadrer les expressions composés de plusieurs mots séparés par un espace
• tout doit être mis en minuscule, mais il faut aussi supprimer les diacritiques

Pour rechercher la même personne avec l’index « all », toujours sans troncature, il faut utiliser cette URL : http://www.idref.fr/Sru/Solr?q=all:%22reclus%2C%20elisee%22

Je reviens sur cette histoire d’encodage des caractères qui n’est pas évidente. Prenons par exemple un nom polonais, comme « Kościuk, Jacek« . Une URL ne peut pas comprendre de caractères spéciaux, c’est à dire non inclus dans le code ASCII original (128 caractères), et ne doit d’ailleurs pas comprendre certains caractères comme l’espace, le point, etc…  Pour qu’un navigateur comprenne le « s accentué », il faut donc l’encoder selon le standard UTF-8. Le code hexadécimal correspondant est « %C5%9B ». Il est faut donc deux octets pour le représenter (C5 et 9B).

Par contre, coup de bol, la plupart des caractères propres au français (sauf Ÿ, Œ, œ) peuvent certes être représentés sur deux caractères en UTF-8, mais aussi en un seul caractère selon d’autres standards.

Le Sudoc, et la plupart des sites modernes sont capables de gérer une URL comprenant des caractères en UTF-8. Voici un lien dans le Sudoc vers le livre dont ce monsieur est l’auteur : http://www.sudoc.abes.fr/DB=2.1/CMD?ACT=SRCHA&IKT=1004&SRT=RLV&TRM=Ko%C5%9Bciuk%2C+Jacek

Or, dans IdRef, que ce soit l’interface publique (0 résultats pour le terme  » Tout=Kościuk, Jacek ») ou le webservice, impossible de retrouver notre ami polonais! Même en remplaçant le « s accentué » par un « s » normal ou par « ? », et en interrogeant l’index « all »…

Conclusion

J’ai monté une vraie usine à gaz, qui n’est pas très fonctionnelle. Je doute que l’idée de départ soit finalement applicable, car IdRef renvoie souvent trop de réponses pour construire une URL qui ne fasse pas des km dans HIP. En plus je me demande si interroger le serveur de notre catalogue avec des équations si longues ne risque pas de le faire « surcharger » d’une manière ou d’une autre. Mais il faudrait quelqu’un de plus compétent que moi en informatique pour le dire.

Par contre, cela m’a permis d’aiguiser mes compétences en javascript, et de mieux comprendre le fonctionnement d’IdRef, et de relever quelques points délicats (échappement dans les index phrase) ou gênants (non indexation de certaines notices, pollution de l’index all par des certains mots clés).

J’espère que cela pourra être utile à d’autres personnes. Si vous voulez copier des morceaux de mon code pour votre usage, n’hésitez pas.