Pour des raisons légales ou disciplinaires, les organismes étatiques au sein de l'union européenne veulent mettre à disposition leurs données environnementales. Des pratiques sont apparues qui répondent à des besoins à court terme mais moins sur le long terme. La réduction des budgets (que tous connaissent), les passes-droits accordés par la législation (mais différemment interprétés) ainsi que la complexité des outils informatiques (pour le plus grand bonheur des sociétés privées) contribuent à la formation d'un maelström administrativo-technique parfois assez complaisant.

Un métacatalogue sans serveur carto¹, c'est la métadonnée sans la donnée. C'est comme un restaurant sans la cuisine : on passe commande, on attend, mais rien ne vient. Sauf que le cœur d'un restaurant... c'est la cuisine ! Vous pouvez mettre le paquet sur la déco, le service ou faire valoir la situation du restau, ses partenaires... si la cuisine ne suit pas, les gens ne reviendront pas.

L'interfaçage des métacatalogues avec des serveurs cartographiques¹ est donc indispensable pour mettre en place des catalogues riches. Sans cela, et en se contentant d'afficher des méta-informations, les catalogues n'ont pas de stock et donc ne sont plus de vrais catalogues. Ils deviennent de simples répertoires, des annuaires, qui fourniraient le même service que Google mais en moins bien : savoir qui est qui et qui à quoi.

Entre bonnes et mauvaises pratiques : les pratiques courantes

« Oui, mais les producteurs de données n'ont pas fourni la donnée »

Mais alors, pourquoi les y faire figurer ?

« Ça peut servir... Et puis... il y a les évaluations annuelles... »

Effectivement cela peut parfois faire sens, à des fins de recensement par exemple. On peut même imaginer une utilisation pro-active de ces annuaires, par un responsable ou un chercheur qui voudrait avoir une vue d'ensemble, ne rien oublier avant de construire une problématique ou de mettre en place une collaboration (ou vérifier que telle fiche de métadonnée cite bien le financeur...). Quelqu'un de directement concerné y verra donc un intérêt et nombreux sont les catalogues qui ont déjà peu ou prou cette orientation.

Ce type d'usage (des métacatalogues en guise d'annuaires) est cependant démesuré. Si cela n'avait de conséquence on pourrait attendre que l'outil grandisse (soit connu), avant d'en récolter les fruits (saisie directement par les producteurs de données). Mais les projets de recherche en environnement, principaux moteurs de production de data, fonctionnent à de plus courts termes et avec des campagnes de récolte échelonnées, souvent objets de missions ponctuelles. Dans ce contexte la mise à jour des fiches sera succincte, et la mise à jour des données restera un rêve.

Si cet usage était l'objectif unique, un administrateur serait d'ailleurs plus efficace (et moins coûteux) en utilisant un site web classique (un CMS par exemple), ou une application institutionnelle bien connue et déjà existante (le métacatalogue national). Posséder son propre métacatalogue n'est pas indispensable pour référencer ses données de façon légale. Il y a donc une dérive.

Autre conséquence de cet usage en tant qu'annuaire : la multiplication des fiches pauvres dans les catalogues. Comme une promesse ou un verrou, la fiche pauvre est mieux que rien. Elle est malheureusement rarement enrichie, même quand la donnée pourrait déjà être partiellement accessible sans mettre en défaut le producteur, et souvent même après qu'elle soit visiblement délivrée de toute obligation.

Pourrissement des catalogues

Les outils sont plus complexes qu'ils n'y paraissent, à l'installation comme dans leur usage avancé. Si l'on compte le contexte actuel et des personnels techniques mouvants, ne pas surdimensionner les projets et prévoir la passation est important pour les unités, qui l'ont compris en mettant en œuvre des Geonetwork1, première brique parfaitement intégrable à des systèmes plus complexes2 . Mais leur maintenance et niveau d'utilisation semblent déjà sous-estimés (ou réduites aux briques logicielles les plus simples), sans doute parce que mal positionnés au sein des structures (les outils trop loin des chercheurs, les données trop loin des informaticiens).

En réponse, les structures se mettent parfois à cultiver un usage interne de leur catalogue (en saisissant des fiches de données acquises) ou à ne s'en servir que comme d'une vitrine promotionnelle (en saisissant des fiches de description). Soit l'acceptation in fine de leur usage en tant qu'annuaire. Mais cela ne suscite que peu d'émulation et même en tant que tel, les outils ne semblent pas réellement maintenus (non-utilisation de droits d'accès pour les fiches de données acquises, absence de mise-à-jour sur les fiches de description...).

Le cadre de travail tend d'ailleurs à considérer ces catalogues comme une fin en soi, devant être mis en place au cours d'une mission, d'un CDD par exemple, à l'issu duquel tous espèrent l'auto-alimentation des outils. Mais quand la personne en charge du projet change de projet, ou si ce projet n'évolue pas, un statu quo s'installe autour de cet usage en tant qu'annuaire, et débouche au mieux sur une utilisation strictement interne de l'outil. Sa faible attractivité ne lui permettant pas de s'auto-alimenter, le catalogue commence alors à dépérir, à n'être consulter que subrepticement par des évaluateurs et des experts et à ne gagner qu'en austérité. L'évolution, la sécurité ou de simples migrations vers des versions plus récentes des outils, sont alors ralenties car personne ne se bouscule pour s'en occuper. C'est également un mauvais chemin, car si demain un producteur fournit la donnée, il faudra bien proposer quelque chose. Ne serait-ce que pour la stocker.

À cause du caractère unilatéral de ces annuaires (du bas vers le haut), il n'y aura pas non plus de hausse exponentionnelle des métadonnées saisies d'une année sur l'autre. Les chercheurs gravitant autour des structures étant souvent les principaux pourvoyeurs de données, mais ayant du mal à y voir leur intérêt post-financement. La logique voulant qu'à terme les évalués eux-mêmes n'y voient plus leur propre intérêt, leurs catalogues étant relativement figés.

Ces pratiques ont un temps répondu à certains besoins, par le jeu des annexes INSPIRE³. Elles permettent aussi de ne pas trop s'engager, en attendant l'outil miracle. Mais à terme elles polluent la visilité des structures et dévalorisent l'activité même de métacatalogage, souvent perçu comme rébarbatif au sein des unités.

L'outil miracle

Cette demande de référencement des données environnementales émanant des états³, avec parfois une obligation de moyens, des outils sont à notre disposition. Le BRGM français et la FAO des Nations Unies s'impliquent dans le développement de solutions gratuites et opensource¹. Dans le même temps, des plates-formes informatiques conséquentes proposent leurs services aux structures étatiques, cela dans des conditions privilégiées quand les besoins sont standards.

Pour certaines grandes entités administratives (IGN ou IFREMER par exemple), la nécessité du métacatalogage était identifiée avant les consignes étatiques, et elles ont su y répondre pour leur propre usage, par des moyens parfois devenus des normes⁶. Les consignes sont suffisamment souples pour s'adapter à l'existant et les formats peuvent cohabiter. Déjà cependant, la disponibilité de compétences informatiques proches des structures semble nécessaire pour adapter, migrer ou créer des passerelles entre les formats.

Pour d'autres entités plus petites mais avec beaucoup de données spatiales (EPCI notamment), le besoin est tellement massif que l'usage d'outils clé-en-main, doublé d'une pression hiérarchique effective, peut faire le travail. Ainsi les Infrastructures de Données Spatiales² semblent satisfaire les besoins des collectivités territoriales ou de certains services déconcentrés de l'état. En l'espace de quelques années un marché s'est ainsi créé, avec des solutions intégrées allant de 6 000 à 75 000 € selon le niveau d'intégration ou la taille du projet. Ajoutez à cela la maintenance annuelle ou d'éventuels développements additionnels pouvant coûter plus cher que l'outil d'origine.

La question de l'utilisateur

Mais pour les structures de recherche la question des IDS² reste en suspens. La précision des consignes étatiques s'est arrêtée net. Des expériences ont été tenté avec peu de succès⁵. Leur caractère automatisé déconcerte, elles semblent s'adresser à des utilisateurs déjà professionnels des outils SIG et sont parfois étonnament austères. Si leur installation et maintenance demandent des compétences en administration de serveurs, leur simple usage demande des compétences de géomaticien, et le développement en appelle à plusieurs technologies informatiques très différentes. Dans le cadre d'une structure de recherche, le risque est que le coût humain ou financier soit supérieur à l'utilité finale.

GeOrchestra par exemple^{2 et 5} fusionne plusieurs applications et service web en un seul outil. Son intérêt semble surtout résider dans l'authentification commune entre le métacalogue, le serveur cartographique et un service de dépôt. Ceci, bien utilisé et dans un certain cadre de travail, peut effectivement être très performant, en permettant à un utilisateur distant d'être totalement indépendant dans le référencement et le stockage de sa donnée, et d'agir seul. Si cet utilisateur, producteur de données, est contraint de fournir alors il fournira. Moyennant finance (le marché surfant un peu sur la vague INSPIRE) et quelques coups de baguettes sur les doigts des producteurs, vous verrez alors votre IDS se peupler gentillement de fiches riches, et faire de votre structure une structure aux normes.

C'est malheureusement plus compliqué pour les unités de recherche. Une incompréhension réside dans la question de l'utilisateur fournisseur de donnée. Qui est-il ? Dans notre cas des chercheurs, mais pour les IDS communes ça reste un géomaticien. Une structure de recherche qui n'a pas de géomaticien à disposition n'aura donc toujours pas résolu le problème avec une IDS. Sauf à saisir des fiches pauvres, mais dans ce cas un Geonetwork¹ seul suffit...

Créer du lien

Car les structures de recherche ne sont pas des collectivités territoriales. Et les producteurs de données, les chercheurs, ne sont pas des employés municipaux. Ils ont des arguments justifiés, visant à conserver la primeur de leurs données avant publications ou autres types d'utilisations privilégiées, et ne veulent pas se retrouver seul face à la machine. Le devenir des données dans une IDS paraît également incertain. En effet si l'outil permet aux utilisateurs d'être indépendants, le risque est justement qu'ils agissent de façon indépendante ! Et par la voie la plus simple pour eux (dépôt de fichiers de données) mais pas forcément la plus intéressante pour la recherche (puisqu'engendrant une difficulté à synthétiser les données ainsi déposées).

Dans le même temps, les chercheurs sont plus que quicquonque sensibles à la nécessité d'archiver le passé. Le géomaticien ne se heurte donc pas à un mur de béton, mais la pression hiérarchique s'arrête sur lui. C'est à lui de proposer des outils qui donnent envie, et permettent le stockage et l'accès aux données sans perte de leur primeur ou de leur caractère confidentiel.

Il y a donc un effort à fournir de la part des informaticiens/géomaticien, qui doivent mettre en place les outils puis instaurer un lien fort entre eux et les chercheurs dès le début des projets de recherche, même s'il ne s'agit que de rationnaliser un bête fichier Excel de 20 lignes. Car ce fichier est parfois le fruit d'un long travail sur le terrain et a beaucoup de valeur pour le chercheur, mais aussi potentiellement pour d'autres. Charge alors au géomaticien de valoriser même très modestement ce butin, ce qui passera de près ou de loin par son intégration dans une base de données.

Ce fichier (qui sera devenu un objet de base de données) sera référencé par une fiche de métadonnée. Cette fiche de métadonnée diffusera un service web à partir des données qu'elle référence. Le contenu de ce service aura été décrété par le chercheur (en lien avec son informaticien). La fiche de métadonnée apportant maintenant une plus-value.

Un process permettant de travailler de façon partagée en conservant un haut niveau de confidentialité autour des données. Le chercheur peut ainsi, s'il le souhaite, communiquer dès le début de son projet de recherche (puisqu'il décide finement de qui a accès à quoi, en lien avec son informaticien). Il peut s'il le souhaite, s'en servir comme base de travail. Il peut s'il le souhaite, diffuser de la donnée occurrentielle (haut niveau de précision), synthétisée (faible niveau de précision, mais parfois plus parlant) ou même sans attribut (très faible niveau de précision, précision spatiale uniquement). Les accès distants (publics ou privés) pointant à chaque fois vers le même entrepôt et bénéficiant de la même actualité des données, cela qu'elles s'affichent de façon complète ou dégradée.

La possibilité de diffuser la donnée doit être pensée en amont de la mise en place d'un métacatalogue, même si inutilisée au départ. Le lien avec la donnée doit être pensé en amont de la saisie d'une fiche de métadonnée, même si la donnée est inexistante au départ. Ou l'informaticien n'est que demandeur. Sans cela difficile d'enclencher l'auto-promotion qualitative des outils, et de ne pas sans sombrer dans la politique du nombre ou dans une technocratie scientifique.

Dans cette optique, l'usage d'une IDS devient un poids car les principaux modules la composant¹ sont largement plus accessibles et industrialisables pris séparément. Bien accompagné, un géomaticien pourra s'en sortir seul pour proposer le même service mais à visage humain. Il sera bien plus libre dans la maintenance des outils et permettra au web-SIG de se construire tout seul au fil de l'avancée du stockage structuré des données.

Ceci moyennant un travail de sélection des projets où c'est possible, de dialogue permanent avec les chercheurs se traduisant par des propositions fiables et déployables rapidement par le géomaticien/informaticien. Travail aussi humain que technique, où la toute-puissance des outils semble trouver ses limites au profit des ressources et des compétences humaines.

Sous les pavés, la donnée

Il ne s'agit pas dans le discours de cet article, de pénaliser les producteurs de données récalcitrants. Nous ne parlons pas de rétention d'infomations. Précisons d'ailleurs qu'aux yeux de la directive européenne³, la sécurité et la confidentialité sont des exceptions légitimes à la fourniture de données (merci INSPIRE !).

Non, il s'agit plutôt d'éviter de pénaliser l'utilisateur quel qu'il soit, et qui perdrait son temps face à des fiches vides. Car noyer des fiches riches au milieu d'un florilège de fiches pauvres dévalorise les catalogues. Chronophagie et vanité peuvent alors s'entremêler en un balet diabolique et dans une course à la méta. Le pourrissement progressif des catalogues nationaux et internationaux, par le jeu des moissonnages⁴, en est une autre conséquence.

D'autant que souvent les producteurs ne fournissent pas parce qu'ils ne le veulent pas, mais parce qu'ils ne le peuvent pas. Leurs données n'étant pas stockées de façon structurée. Si elles l'étaient, rien n'empêcherait l'émission de donnée synthétique, épurée de tous contenu confidentiel, sous forme cartographique par exemple (nous parlons ici de simples requêtes de regroupement). C'est le passage de l'état de métacatalogue à celui de géocatalogue.

Dans ce cas, l'objectif de l'administrateur du catalogue se complique (mais à des fins bien plus productives !). Il ne doit plus courir après la méta, mais courir après la donnée, et proposer au producteur des moyens de saisie, stockage et protection de ses données. Car si le besoin est exprimé alors il faut y répondre (avant de perdre la donnée) ; et s'il ne l'est pas, c'est parfois qu'il en est d'autant plus prégnant, il faut aller le vérifier. Le géomaticien doit donc valoriser rapidement la donnée qui lui parvient. Il devra sans doute la spatialiser lui-même ou rendre évident l'intérêt d'un workflow⁷ dans le stockage de cette donnée.

Constatons d'ailleurs que quand la donnée est fournie, puis structurée, la méta a tendance à tomber toute seule ! Allons plus loin : grâce aux outils modernes dont nous parlons ici¹, quand la donnée est fournie, certains des champs les plus pénibles des normes en vigueur³ se remplissent automatiquement (comme les informations relatives au référencement spatial). De même et uniquement quand la donnée est fournie, le lien entre la méta et la donnée fonctionne dans les deux sens. Un utilisateur consultant vos données à distance (SIG ou catalogue moissonneur⁴) aurait donc accès à la dernière version de la fiche de métadonnée liée, sur votre propre catalogue source.

Outre le gain de temps de cette approche (qui pourrait être discutée, car courir après la donnée est plus complexe que courir après la méta, et pose d'autres questions), un autre intérêt existe : conférer à son catalogue un caractère vendeur. Ce qui n'est pas anodin pour l'administrateur qui rencontre justement des problèmes à récupérer la donnée.

[Moissonnage et protection des données]

Sans rentrer dans les méandres juridiques du droit d'auteur, complexifié par le(s) cadre(s) légal(aux) inhérent(s) aux structures de recherche et aux données géo-scientifiques environnementales³, quelle protection offre concrêtement un métacatalogue ? Métacatalogue qui plus est moissonné par un ou plusieurs catalogues distants, ayant parfois une très grande visibilité, comme les catalogues nationaux et internationaux³ ! N'y a-t-il pas un paradoxe à parler de sécurité et de protection quand l'intérêt des métacatalogues, qui référencent des données parfois confidentielles, est ensuite de se moissonner entre eux ? Est-ce angoissant ou rassurant ?

Et bien la technologie du moissonnage⁴ fait l'objet de grandes discussions au sein de groupes de travail rassemblant des gens très compétents et issus d'horizons très divers (gestionnaires et développeurs). Il s'agit d'une techno qui va aspirer les informations qu'on lui soumet, et donc en créer une copie. Ce n'est pas du simple affichage et même si ça peut être utilisé en tant que tel, c'est différent des flux RSS ou d'autres types de web-services⁴.

Ainsi quand une fiche de métadonnée est moissonnée par un catalogue officiel, avec les nom, prénoms, email de l'auteur, ainsi que la date de création et/ou de mise à jour des données, alors le catalogue en question a enregistré ces informations lui-même, dans sa propre base de données. Un auteur ou producteur de données qui rencontrerait un problème d'usage illégal de ces données, bénéficierait donc d'un moyen simple de prouver l'ancienneté de ces données⁸. La condition sinequanone étant encore l'existence d'un lien de confiance entre le chercheur et l'administrateur du catalogue source, puisque la fiche moissonnée ne peut être modifiée qu'à partir du catalogue source (en l'absence de droits d'accès particuliers).

Précisons enfin que le moissonnage entre catalogues ne concerne que les méta-données. Les données elles-mêmes, éventuellement fournies (complètes ou partielles) sous forme de web-services, sont liées à leurs fiches de méta sous forme de liens. Ce sont ces liens qui seront moissonnés (autorisant un catalogue moissonneur à pointer sur la donnée originale) mais pas les données elles-mêmes.

Culture de la donnée

Savoir vendre les catalogues, faire aimer le métacatalogage, avec la diffusion de web-services⁴, en avançant la perspective d'être moissonné par les géocatalogues nationaux et internationaux³, offrir aux chercheurs des fenêtres publiques sur leurs travaux, leurs structures d'appartenance, les financeurs, l'assurance d'être considéré sur des sites officiels comme l'auteur unique de leurs données... Tout cela semble crucial pour démarrer un projet de géocatalogue puis pour le faire vivre. Un effet boule-de-neige par une plus grande visibilité des travaux de recherche, attirant d'autres chercheurs, d'autres jeux de données et parfois même d'autres publics.

Cet objectif semble conditionné à la mise en place de liens forts entre les informaticiens et les chercheurs et à l'impulsion d'une culture de la donnée. Il y a cette idée paradoxale à faire passer, que des données sont à la fois mieux protégées et plus accessibles sur un serveur distant. Il y a le stockage structuré des données de la recherche en environnement à organiser, à mutualiser et à valoriser, afin de voir un jour les catalogues s'auto-alimenter. Il y a un cercle vertueux à enclencher, des discussions à entamer et des données à faire parler.

Un mouvement qui viendra des informaticiens et des géomaticiens, en se rapprochant des producteurs et du terrain, mais surtout en pensant les métacatalogues comme la 1^ère brique d'une infrastructure et l'usage des serveurs cartographiques, la 1^ère pierre d'une culture.

1. Métacatalogue et serveur cartographique : Geonetwork et Geoserver par exemple, sont des outils Java, gratuits et opensource, permettant de mettre respectivement en place un catalogue de métadonnées et un serveur cartographique. Un métacatalogue est un portail de recensement des informations produites par un organisme (souvent spatiales, mais pas seulement). Un serveur cartographique est un système informatique permettant la diffusion de données spatiales. Un serveur cartographique travaille dans l'ombre d'un métacatalogue, l'utilisateur lambda ne s'y rend jamais, mais en profite à chaque fois qu'il consulte de la donnée spatiale. Les deux outils peuvent être utilisés conjointement ou de façon indépendante. Le système de base de données spatiales Postgres est également à l'œuvre dans ce type d'infrastructures, mais c'est un autre chapitre...
2. IDS : ou IDG, Infrastructure de Données Spatiales/Géographiques, SDI en anglais. Le terme apparaît depuis quelques années pour désigner des systèmes de web-SIG très complets et très orientés métier (pour des collectivités territoriales ou des établissement producteurs de données publiques par exemple). La région Bretagne a fortement contribué à populariser les IDS en France. Les outils GeOrchestra et EasySDI sont souvent cités en Europe, mais comme le terme l'indique, il s'agit bien d'infrastructures, difficilement réductibles à un seul outil mais plutôt constituées de systèmes de communication, du plus simple au plus complexe selon les besoins métiers. Les IDS les plus connues sont d'ailleurs elles-mêmes constituées de différentes briques logicielles¹, selon les standards imposés ou choisis.
3. INSPIRE : directive européenne en vigueur depuis 2007 et articulée autour de l'accès aux données. INSPIRE tente de standardiser l'accès aux données et concerne particulièrement les producteurs de « données publiques environnementales ». L'application de la directive semble fonctionner par étapes (annexes) en fonction de plusieurs obligations pour les états membres, de la fourniture des métadonnées à l'inter-opérabilité des données elles-mêmes. En France la directive INSPIRE a été transposé en ordonnance en 2010, son application est en charge du ministère de l'écologie et pilotée par le CNIG (Conseil National de l'Information Géographique). D'autres structures sont impliquées et parfois mandatées pour intervenir sur certains points, comme le BRGM (Bureau des Ressources Géologiques et Minières) pour mettre en place le portail national de métadonnées (Géo-catalogue, considéré comme « l'object focal de référence pour l'application de la directive en France ») ou contribuer au développement opensource des outils informatiques nécessaires (Geonetwork et Geoserver notamment). Un portail européen INSPIRE moissonne ensuite les portails nationaux. La bonne application de la directive semble surveillée par l'Union Européenne, avec parfois de grosses amendes dit-on. La France produit d'ailleurs un rapport annuel gouvernemental, avec des « indicateurs INSPIRE » et la mention je crois, des structures fournissant des flux de données conséquents.
4. Web-service : se dit de fonctionnalités d'applications capables d'échanger avec des applications distantes et éventuellement différentes de conception. Cela en utilisant des protocoles de communication standardisés entre les différents systèmes et qui ne regardent pas les mécaniques des systèmes impliqués. Le terme est souvent mieux définit par un ensemble d'usages plutôt que par un protocole précis. Des flux WMS ou WFS par exemple, sont des web-services traitant des données cartographiques, mais le protocole WMS est réputé ne faire que de l'affichage, le WMS du téléchargement. Des liens de téléchargements dynamiques ne sont peut-être pas des web-services en soi, mais pourraient être utilisés en tant que tel. Des flux RSS ou la technologie dite du moissonnage (harvest en anglais, le flux CSW) ne sont pas toujours considérés comme des web-services, mais fournissent des prestations très similaires.
5. La mise à disposition d'un GeOrchestra bac-à-sable à des structures de recherche a montré que si la méthode de mise en ligne de métadonnées reste relativement aisée, ce n'était pas le cas de la mise en ligne de données spatiales. Au final les structures se sont détournées de cet outil, qui les laissait face au même problème : comment rendre accessible des données spatiales sans être expert en géomatique ? De façon générale les catalogues des structures de recherche en environnement diffusent peu de données spatiales (mais en répertorient beaucoup !).

6. Notamment sur la question des identificateurs de ressources (DOI, UUID...), des web-services (WMS, WFS...) ou des protocoles de communication (CSW, OAI...). L'IFREMER par exemple a popularisé les DOI jusque dans l'identification de données spatiales (alors qu'originellement dédiés aux ressources bibliographiques). Des outils comme Geoserver ou Mapserver semblent s'imposer à toute la zone européenne, sous l'impulsion de consortium comme l'OGC, d'ONG comme l'OSGeo, ou de pays comme la France et l'Italie. Le secteur privé est également impliqué dans le développement des outils (comme la société Camptocamp ou Titellus).

7. Un workflow est un protocole de traitement, une succession d'étapes permettant de valoriser un produit (dans notre cas : une donnée). Typiquement cela commence par la saisie, la vérification, la validation puis la diffusion, chacune de ces étapes étant l'objet de droits. Un workflow est souvent matérialisé dans les systèmes par la présence d'un champ Statut ou Accès (validé, privé, public, groupe...) et fait aussi l'objet de règles de validation et d'harmonisation.

8. Il ne s'agit pas forcément d'une méthode juridique empirique, mais au moins d'une forme d'officialisation. Les moissonnages du géo-catalogue français par exemple, supposent une validation humaine. Les moissonnages du géo-catalogue européen semblent aussi l'objet de filtres.