Complexité est le mot qui m’a le plus marqué lors de la dernière conférence européenne INSPIRE (qui s’est tenue il y deux semaines à Strasbourg). Il a été prononcé de manière très fréquente que ce soit en séance plénière par des techniciens de la chose, par des responsables de grandes administrations publiques, par des élus ou que ce soit lors de présentations plus restreintes.

Je retiens 2 interventions totalement différentes et frappantes. La première par Bruce McCormack devant un relativement petit auditoire. Il présentait le résultat d’une petite enquête (à laquelle j’ai participé) lancée très peu de temps avant la conférence auprès d’un nombre très limité de personnes portant sur une analyse SWOT (forces, faiblesses, opportunités, menaces) de la directive européenne INSPIRE. Le terme qui ressort le plus de cette analyse est complexité (à ranger dans la catégorie faiblesses pour ceux d’entre vous qui auraient un doute). Une autre faiblesse récurrente accompagnait cette complexité : le manque de cas d’usage concrets. Situation classique d’un projet pour lequel des choix techniques ont été faits avant de connaître les besoins concrets (les besoins abstraits étaient plutôt clairs et sont toujours parfaitement d’actualité).

La seconde intervention a eu lieu en séance plénière au cours de présentations de retours d’expérience sur des projets réalisés en régions. La fin de séance a été l’occasion pour chaque intervenant de donner sa vision de l’évolution de la directive INSPIRE. Mário Caetano est revenu brièvement sur la complexité d’INSPIRE en saisissant une perche tendue par Fabrice Phung. Grosso modo, sa vision des choses était que le monde que nous décrivons, nous géomaticiens, et les problèmes que nous cherchons à résoudre sont complexes par nature et que les prendre en main nécessite de manipuler des données et des outils complexes. La complexité serait donc inéluctable. De quoi faire sérieusement réfléchir.

On trouve la complexité un peu partout. La vie, l’univers et langage par exemple sont complexes. Appréhender de manière frontale des problèmes complexes est une mauvaise idée. En général, pour résoudre des problèmes l’homme utilise des abstractions. Deux d’entre elles sont intéressantes : la simplification et la généralisation. La simplification consiste à ne retenir que certaines caractéristiques du phénomène observé en supposant que les perturbations non prises en compte dans ce modèle simple sont négligeables dans le cadre de l’étude. Exemple : tous les corps en chute libre tombent à la même vitesse… si l’on suppose que le champ gravitationnel est uniforme, si l’on fait abstraction de toutes les autres forces et si les corps en question sont lâchés en même temps et à la même vitesse… C’est simple et efficace : on gère la majorité des cas de la sorte tant que les besoins et les capacités de mesure ne deviennent pas incompatibles avec la précision du modèle.

Le problème en sciences c’est qu’il arrive toujours un moment où l’on constate que le modèle adopté jusqu’ici n’est plus adapté. Souvent, maintenir un modèle simple ne permet pas de prendre en compte tous les paramètres dont l’on a besoin. Lorsque l’on souhaite intégrer un plus grand nombre de phénomènes apparemment distincts dans un même modèle on procède à une généralisation. C’est le cas par exemple de la théorie de la gravitation universelle de Newton qui couvre à la fois les phénomènes de chute des corps décrits par Galilée et les déplacements des planètes. C’est aussi le cas de la théorie des cordes, chère à Sheldon Cooper, qui s’attache à prendre en compte dans un même modèle la mécanique quantique et la relativité générale. Ces généralisations ne procèdent pas du tout d’une simplification (sauf dans le cas de la généralisation cartographique mais c’est hors sujet ici). Elles visent à définir un modèle plus général capable de prendre en compte des phénomènes jusque là considérés comme étant à la marge par les outils préalablement disponibles. La généralisation apporte un niveau de complexité égal à tous les phénomènes qu’elle englobe avec cet effet de bord qui consiste à ajouter de la complexité là où il n’y en avait pas, peu ou moins. À force de généralisations on arrive donc à une complexité de plus en plus importante pour une plus-value qui ne s’exprimera, la plupart du temps, que dans des cas de plus en plus marginaux. Excellent article scientifique dénonçant la généralisation à outrance : la montre à moutarde (désolé si mon sarcasme a touché ceux parmi vous qui en ont acheté une).

La complexité n’est pas une mauvaise chose en soit. En particulier, elle permet de faire des avancées majeures en recherches théoriques qui pourront ensuite déboucher sur des applications plus courantes. Elle est simplement déplacée lorsqu’on nous l’impose, lorsqu’elle ne répond pas à l’un de nos besoins majeurs et lorsque nous ne sommes pas armés pour y faire face. Fixer quelque chose avec un clou est une opération relativement complexe en soi. Mais voilà, on peut acheter toute sorte de clous pour toute sorte de matériaux, choisir le marteau adapté et n’importe quel voisin digne de ce nom vous expliquera comment faire si vous avez des doutes. De surcroît, en général, vous ne devez pas fabriquer vos propres clous, ni votre marteau, vous ne devez pas lire 200 pages de spécifications avant de vous lancer, vous êtes la plupart du temps certains de l’utilité de planter un clou et dans le pire des cas, si vous avez affreusement mal aux doigts après le premier coup de marteau, vous savez pourquoi et êtes suffisamment malin pour comprendre d’où cela vient et comment ne pas le refaire au prochain coup.

Mais alors, qu’est-ce qui nous a pris avec GML, ISO19115/19139 et d’autres trucs dans le genre ? Pourquoi nous imposons-nous autant de souffrance ? Nous n’avons pas les outils pour écrire de tels fichiers ni, parfois, pour les lire ; nous avons toujours des doutes sur les informations censées être obligatoires à mettre dedans ; notre gentil voisin (celui avec les lunettes, qui est toujours plongé dans des livres bizarres et que l’on n’invite pas à nos fêtes) en a de plus en plus ras le bol de venir nous dépanner pour finir nos fiches de métadonnées (il faut dire qu’au bout de 10 ans nous n’avons toujours pas compris qu’il ne faut pas mettre à la fois une résolution et une échelle dans vos fiches) ; nous ne sommes même pas convaincus de la plus-value de ces formats par rapport à ce que nous utilisions avant. Je suis amer et sévère ? Parlons un peu des outils, tiens : un logiciel qui nécessite d’avoir le même niveau de compétence pour l’utiliser (pas pour le réparer, hein) que celui qui l’a conçu n’est pas vraiment un outil de mon point de vue.

Cela me fait penser au petit voisin qui a bravement surmonté l’épreuve des additions, puis celle des multiplications, et à qui il faut expliquer comment faire manuellement une division. Cela peut être un vrai calvaire pour certains, surtout quand il a conscience que n’importe quelle calculette fait le travail sans râler. C’est plus facile pour ceux qui ont le cerveau adapté aux maths, ceux qui ont des lunettes et qui voient l’intérêt de la chose (pas évident à cet âge). Voilà, la complexité est un facteur d’échec, voire d’abandon. Par voie de conséquence, c’est aussi une cause de sélection, volontaire ou non. Alors, dans la cadre d’un texte réglementaire qui doit être mis en œuvre de manière généralisée la complexité me semble être un excellent moyen de ne pas atteindre des objectifs et donc un bon moyen de programmer son propre échec (avec une admirable dose d’enthousiasme au départ ceci dit).

GML et ISO 19115 sont pour moi des exercices de style de généralisation des données et métadonnées pour prendre en compte n’importe quel besoin. Quelle est la plus-value d’utiliser un format qui permet de décrire un simple carré de plus d’une vingtaine de manières différentes (cf. GML Madness) ? Pourquoi codifier les informations de qualité et de généalogie dans des métadonnées en XML alors que ces informations ne sont pas exploitées de manière automatique par les moteurs de recherche, que ces informations sont difficilement exploitables par un humain normalement constitué ? La plus-value est-elle à la hauteur des efforts sans cesse renouvelés de développement, sensibilisation, formation, support technique sur ces formats, outils de saisie et de contrôle ? L’investissement réalisé par tous (les animateurs des démarches d’INSPIRE, les développeurs, les administrateurs, les producteurs et les utilisateurs) sur ces sujets techniques me paraît démesuré au regard de pratiques pragmatiques alternatives plus efficaces et appréciées : pour les métadonnées par exemple, un bon vieux Dublin Core avec quelques références à des documents lisibles par des humains pour les informations les plus complexes.

Oui, la complexité est partout dans notre monde. Elle est présente aussi en géomatique. Mais on n’est pas obligé de la subir et le meilleur moyen de la traiter est de la reporter soit dans des outils éprouvés qui savent la gérer (ce qui n’est pas franchement le cas dans la panoplie d’outils que nous utilisons) soit en la reportant dans des documents annexes en langage naturel que la plupart des géomaticiens savent lire et interpréter.

La complexité fait partie des mots que l’on utilise facilement sans trop savoir comment le définir. D’ailleurs, je ne m’y suis pas risqué. Je préfère rester dans le domaine de la perception. Personnellement, je situe la complexité dans le giron de la douleur. En général, la complexité est subie. Certains pervers la font subir aux autres ; ça arrive. Mais arrêtons de nous l’infliger nous-mêmes à grande échelle et par voie réglementaire qui plus est !

De la complexité
Étiqueté avec :

4 pesnées sur “De la complexité

  • 21 septembre 2017 à 9:52
    Permalien

    D’accord sur beaucoup de choses, sauf sur l’ostracisation des personnes à vision de portée variable (avec des lunettes).

    ISO 19115 est une aberration extraordinairement complexe, à la fois trop riche et pas assez complète. Et en réalité INSPIRE et ISO 19115 sont sensiblement différents. Exemple simple pour la date de la métadonnée : date de création pour ISO, date de mise à jour pour INSPIRE (ou de création c’est comme on veut, cf http://inspire.ec.europa.eu/documents/Metadata/MD_IR_and_ISO_20131029.pdf §1.1.1 et §2.11.2). Donc en ISO elle ne sert pas à l’usage principal de la découverte (trouver les dernières fiches modifiées), et en INSPIRE elle est complètement inutilisable. Dublin Core n’aurait pas résolu ce genre de problème (mais il aurait été beaucoup plus simple d’itérer, c’est évident).

    En ce qui concerne les alternatives, Dublin Core me paraît trop simple (et demande quand même un certain nombre de guides de mise en œuvre). Et je note qu’INSPIRE a 10 ans, DCAT a été normalisé en 2014 et geojson date de 2008 (normalisé en 2016).

    AMHA une alternative peut venir d’une standardisation de fait. Mais je ne vois personne aujourd’hui en mesure de la proposer, ni les projets open source ni les éditeurs. Il faudrait qu’une plateforme influente, motivée et qui en a les moyens la fasse développer à côté d’INSPIRE et ouvre la route du succès. Pas évident…

    Répondre
    • 21 septembre 2017 à 10:38
      Permalien

      Merci Mathieu pour ton commentaire. Tu as parfaitement raison.

      AMHA une alternative peut venir d’une standardisation de fait. Mais je ne vois personne aujourd’hui en mesure de la proposer, ni les projets open source ni les éditeurs. Il faudrait qu’une plateforme influente, motivée et qui en a les moyens la fasse développer à côté d’INSPIRE et ouvre la route du succès. Pas évident…

      Je suis d’accord sur le fait qu’une standardisation de fait émergera difficilement. En effet, on a connu au début des années 2000 un fort élan vers l’emploi des standards de l’ISO et de l’OGC. Aujourd’hui j’ai l’impression que nombre de plateformes influentes se désengage complètement de ces standards et préfèrent mettre en place des solutions alternatives (surtout pour leurs API). Certaines initiatives de ces plateformes se transforment en standards de fait (tuiles vecteur de MapBox par exemple ou GeoJSON par exemple) mais elles ont du mal à atteindre la sphère publique pour de multiples raisons : besoins différents et penchant à se méfier d’initiatives industrielles qui peuvent paraître comme éphémères notamment. Le fait que l’OGC, actuellement, ne n’apparaisse pas comme proactif ni même actif vu de l’extérieur n’aide pas à être rassuré. Sur le sujet précis des métadonnées, je ne pense qu’on doive attendre qu’une plateforme influente propose quelque chose car la majorité des besoins concerne l’échange de données entre autorités publiques. Si quelque chose de nouveau doit émerger, cela devrait venir soit d’INSPIRE elle-même soit de démarches similaires. Dans le domaine Open data avec la mise en œuvre de la directive européenne PSI dont une partie de la loi pour une République numérique est une conséquence par exemple. Ou le monde des bibliothèques et de la recherche qui passent leur temps à échanger des métadonnées depuis belle lurette.

      Répondre
  • 22 septembre 2017 à 9:49
    Permalien

    « le monde des bibliothèques et de la recherche » a ses équivalents directs aux points soulevés par ce billet, échapper au GML pour se confronter à du RDF/XML et des ontologies OWL tout en essayant d’obtenir des consensus entre chercheurs pour les thésauri SKOS […] n’est pas plus simple.

    Répondre
    • 22 septembre 2017 à 11:16
      Permalien

      Je ne connais pas l’état de l’art ni l’historique de ce qui peut être fait dans le domaine de la recherche et de bibliothèques (même si vu de l’extérieur AOI-PMH et Dublin Core ont l’air de fonctionner). C’était juste des pistes pour s’intéresser à ce que font les autres.

      C’est vrai qu’en soit RDF, XML, SKOS, OWL ne sont pas forcément des technologies simples. Mais mon propos n’est pas de dire que nous devrions n’utiliser que des technologies simples mais de dire que de choisir des formats et protocoles complexes n’a de sens que si le besoin le justifie et que si nous avons les bons outils pour ne pas avoir à subir cette complexité au quotidien.

      Opter pour la complexité en utilisant des formats/standards trop spécifiques à l’information géographique n’aide pas à mettre en place des outils simples et éprouvés. Les spécificités de l’information géographique ne sont pas à mes yeux une bonne raison pour ne pas se rapprocher de choses qui fonctionnent dans un autre domaine. Je me trompe peut-être en pansant que la recherche et les bibliothèques se débrouillent mieux que nous et en pensant que leur approche pourrait nous être bénéfique.

      Pour ce qui est des thesaurus, je ne pense pas que ce soit un enjeu majeur actuel. Nous en avons quelqu’uns d’opérationnels et disponibles en SKOS pour leur exploitation dans nos catalogues. Je ne pense pas que ce soit un souci au niveau des du catalogage actuel.

      Répondre

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *