Vue normale

Il y a de nouveaux articles disponibles, cliquez pour rafraîchir la page.
À partir d’avant-hierFlux principal

Petites brèves : les algorithmes publics, des données personnelles trop publiques et de la censure

26 novembre 2024 à 04:18

Trois liens vers des sites créés récemment à suivre :

    Commentaires : voir le flux Atom ouvrir dans le navigateur

    ConFoo Montreal 2025 : l’appel à conférences est ouvert

    La conférence ConFoo est de retour pour sa 23ᵉ édition, du 26 au 28 février 2025 à l’Hôtel Bonaventure de Montréal ! Venez découvrir pourquoi ConFoo est devenu l’un des événements phares pour les développeurs et développeuses en Amérique du Nord et de partout à travers le monde.

    Nous sommes présentement à la recherche de conférenciers et de conférencières avides de partager leur expertise et leur savoir dans une multitude de domaines des hautes technologies ; PHP, Ruby, Java, DotNet, JavaScript, Intelligence Artificielle, et plus encore !

    Offertes en français ou en anglais, nos présentations sont généralement d’un format de 45 minutes, incluant un 10 minutes de questions des participants. Nos conférenciers et conférencières invitées profitent d’un traitement privilégié ; avec notamment la couverture de leurs frais de déplacement et d’hébergement, en plus de l’accès à l’expérience complète de l’événement (présentations, repas, etc.).

    Vous avez jusqu’au 22 septembre prochain pour soumettre votre projet de présentations !

    Si vous souhaitez simplement vous inscrire en tant que participant, profitez dès maintenant d’un rabais de 300$ en réservant votre inscription d'ici au 18 octobre !

    Faites partie de l’aventure avec nous et découvrez comment l’intelligence humaine façonne le milieu des hautes technologies !

    Commentaires : voir le flux Atom ouvrir dans le navigateur

    Comment l’archéologie entre progressivement dans l’ère du logiciel libre

    L’archéologie est un domaine qui, depuis ses débuts, s’attache au catalogage, à la structuration et l’archivage de données issues de fouilles. Sur le terrain, elle a longtemps reposé sur la création de fiches, la collecte manuelle d’information sur papier, et le dessin à la main, retranscrit lors des phases d’étude sur support numérique. Ce n’est que récemment que certains archéologues ont lancé le mouvement de la fouille « tout numérique ». Je vous propose de raconter ici l’histoire de la numérisation de l’archéologie, qui, comme vous allez le voir, repose en partie sur le logiciel libre.

    Sommaire

    Qu’est-ce qu’un chantier de fouilles ?

    L’archéologie française se divise en deux branches principales : l’archéologie préventive, qui intervient lors de projets de construction, et l’archéologie programmée, menée sur des sites choisis pour répondre à des problématiques de recherche. Supervisées par les Services Régionaux de l’Archéologie du Ministère de la Culture, ces activités sont réalisées par différents organismes : opérateurs publics et privés pour l’archéologie préventive, et associations, CNRS ou universitaires pour l’archéologie programmée. Cette dernière mobilise souvent des bénévoles, notamment des étudiants, leur offrant une formation pratique complémentaire.

    Pour l’archéologue, la fouille est un outil, et non un but en soi. Ce que l’archéologue cherche, c’est de l’information. En substance, il s’agit de comprendre l’histoire d’un site, son évolution, ses habitants à travers les éléments qu’ils ont laissés derrière eux, que ce soit les ruines de leurs habitats, de leurs activités artisanales ou leurs sépultures. Ceci est d’autant plus important que la fouille est un acte destructeur, puisque l’archéologue démantèle son sujet d’étude au fur et à mesure de la fouille.

    Pour être exploitée, l’information archéologique doit être organisée selon des principes bien établis. Le premier concept clé est la couche sédimentaire (Unité Stratigraphique - US), qui témoigne d’une action humaine ou d’un phénomène naturel. L’étude de l’agencement de ces couches révèle la chronologie du site, la succession des évènements qui s’y sont déroulés. Ces couches peuvent être regroupées en faits archéologiques : fossés, caves, sépultures, sont en effet des regroupements de couches qui définissent un élément spécifique. Enfin, les objets trouvés dans ces couches, ou mobiliers, sont catalogués et identifiés par leur couche d’origine, fournissant des indications chronologiques et culturelles cruciales.

    chantier mastraits
    Le chantier de fouilles de la Nécropole des Mastraits, à Noisy-le-Grand (93).

    Les actions menées par l’archéologue tout au long du chantier sont également enregistrées. En effet, l’archéologue procède à des sondages, réalise des tranchées, mais fait aussi de nombreuses photos, ou des dessins de tout ce qu’il découvre au fur et à mesure de l’avancement du chantier. La documentation produite peut être pléthorique, et un catalogage indispensable.

    Cette information descriptive est complétée par une information spatiale, le plan des vestiges mis au jour étant essentiel pour l’analyse et la présentation des résultats. L’étude de ce plan, associée aux informations descriptives et chronologiques, met en évidence les grandes évolutions du site ou des détails spécifiques. Sa réalisation est généralement confiée à un topographe en collaboration avec les archéologues.

    À l’issue de la phase de terrain, une phase d’analyse des données collectées est réalisée. Cette phase dite de post-fouille permet de traiter l’ensemble des informations recueillies, d’en réaliser la description complète, d’effectuer les études nécessaires à la compréhension du site en faisant appel à de nombreux spécialistes : céramologues, anthropologues, archéozoologues, lithiciens, carpologues, anthracologues, spécialistes de la paléométallurgie, etc.

    Cette phase de post-fouille aboutit dans un premier temps à la réalisation d’un rapport d’opération, compte rendu le plus exhaustif possible du site et de son évolution. Ces rapports sont remis au ministère de la Culture qui en juge la qualité. Ils ne sont pas destinés à être largement diffusés, mais sont normalement accessibles à toute personne qui en fait la demande auprès de l’administration concernée. Ils sont une base de travail importante pour l’ensemble de la communauté scientifique.

    Sur la base de ce rapport, la publication d’articles dans des revues spécialisées permet de présenter les résultats de l’opération plus largement, parfois en fonction de certaines thématiques ou problématiques spécifiques.

    Pratique de l’archéologie : exemple dans le préventif

    L’utilisation de très nombreux listings papier est une constante. Ces listings permettent de tenir à jour l’enregistrement de la donnée sous forme de tableaux d’inventaire des couches, des faits, des sondages, des photos, etc. Des fiches d’enregistrement spécifiques sont également utilisées dans de nombreuses spécialités de l’archéologie, telle que l’anthropologie funéraire.

    Sur le terrain, les éléments mis au jour sont encore pour une très grande majorité dessinés à la main, sur papier calque ou millimétré, qu’il s’agisse d’un plan de vestiges ou des nombreux relevés de coupe stratigraphique. Ceci demande bien entendu un temps important, en particulier en cas de vestiges complexes.
    L’utilisation de tachéomètres électroniques, puis du GPS différentiel a permis de se passer des décamètres, ou des systèmes de carroyage, lors de la fouille des sites. Des topographes, spécifiquement formés, ont alors commencé à intervenir sur site pour la réalisation des plans généraux.

    La collection documentaire obtenue à l’issue d’un chantier de fouille est particulièrement précieuse. Il s’agit là des seuls éléments qui permettront de restituer l’histoire du site, en croisant ces données avec le résultat des études réalisées. La crainte de la disparition de ces données, ou de leur utilisation par autrui du fait d’une découverte remarquable, est un sentiment souvent partagé au sein de la communauté archéologique. L’archéologue peut se sentir dépositaire de cette information, voire exprimer un sentiment de possession qui va tout à fait à l’encontre de l’idée de science partagée et ouverte. L’idée que l’ouverture de la donnée est le meilleur moyen de la protéger est loin d’être une évidence.

    fiche de conservation, illustrant le coloriage manuel des parties de squelette retrouvées
    Fiche de conservation, illustrant le coloriage manuel des parties de squelette retrouvées

    Exemple de fiche descriptive d’une couche archéologique
    Exemple, parmi tant d’autres, de fiche descriptive vierge d’une couche archéologique

    Le début de la numérisation

    C’est essentiellement après la phase terrain que les outils numériques ont été apprivoisés par les archéologues.

    En post-fouille, la documentation papier est encore souvent une base documentaire fondamentale pour l’analyse du site. L’irruption de l’informatique au milieu des années 80 a conduit les archéologues à transcrire cette donnée sous forme numérique, afin de faciliter son analyse et sa présentation. Bien que les logiciels aient évolué, le processus est pratiquement le même aujourd’hui, avec une numérisation de la documentation sous de nombreux formats.

    Les listings peuvent être intégrés à des bases de données (le plus souvent propriétaires tel MS Access, FileMaker ou 4D) ou des tableurs. De nombreuses bases ont été développées en interne, localement, par les archéologues eux-mêmes. Uniquement attributaires, elles se sont progressivement mises en réseau et adaptées au support, permettant d’envisager un usage sur le terrain, sans que ceci ne soit largement déployé.

    Base de données
    Exemple d’une base de données au tournant des années 2000

    Toute la documentation dessinée sur le terrain est amenée à être redessinée au propre sur support numérique, dans des logiciels de dessin vectoriel, très souvent Adobe Illustrator, parfois Inkscape.
    Les données en plan, levées par le topographe, sont réalisées sous Autocad et étaient exportés en .dxf ou .dwg avant d’être remis au propre sous Adobe illustrator, ce qui est le cas également des dessins réalisés sur le terrain.
    Le mobilier est confié à des spécialistes qui le décrivent, le dessinent, en dressent l’inventaire, le plus souvent dans des tableurs. Leurs dessins sont là encore scannés et remis au propre numériquement.

    Avec le recul, nous constatons que les outils numériques sont majoritairement utilisés comme des outils de mise au propre de l’information collectée sur le terrain. Bien des tableurs ne sont ainsi que la stricte transcription des tableaux papier utilisés par les archéologues, auquel on ajoutera quelques totaux, moyennes ou médianes. Les dessins réalisés sur papier, sont décalqués dans des logiciels de vectorisation pour plus de lisibilité et les plus-values scientifique sont finalement assez limitées.

    Il en résulte une documentation numérique relativement disparate, avec l’usage de nombreux outils propriétaires, des formats fermés, et une séparation très forte entre l’information spatiale et l’information descriptive (ou attributaire).

    L’usage progressif des bases de données a cependant permis d’agglomérer certaines données et de rassembler et mettre en relation l’information. Des travaux universitaires ont également permis d’alimenter la réflexion sur la structuration des données archéologiques et de former de nombreux archéologues, permettant d’adopter des pratiques plus vertueuses.

    Le mouvement tout numérique

    Jusqu’à présent, passer au tout numérique dans le cadre archéologique semblait relativement utopique. Il a fallu que de nouvelles technologies apparaissent, que des supports portables et simples d’usage se mettent en place, que les réseaux se développent, et que les archéologues s’emparent de ces nouveaux outils.

    Le collectif Ramen (Recherches Archéologiques en Modélisation de l’Enregistrement Numérique) est né des échanges et des expériences de divers archéologues de l’Institut National De Recherches Archéologiques Préventives (Inrap) qui se sont regroupés autour de la réalisation de la fouille programmée de la nécropole médiévale de Noisy-Le-Grand, fouille gérée par l’association Archéologie des Nécropoles et confiée à la direction scientifique de Cyrille Le Forestier (Inrap). Cette fouille programmée a permis de lancer une expérimentation sur la complète dématérialisation de la donnée archéologique en se basant sur la photogrammétrie, le SIG, et une base de données spatiale.

    Principe général

    Si le topographe intervient bien toujours pour la prise de points de référence, le relevé détaillé des vestiges est assuré, pour cette expérimentation, par la mise en œuvre de la photogrammétrie de manière systématique. Cette méthode permet, par la réalisation de multiples photos d’un objet ou d’une scène, de réaliser un modèle 3D précis, et donc exploitable à postériori par l’archéologue en post fouille. La photogrammétrie constitue à Noisy l’unique outil de relevé, remplaçant purement et simplement le dessin sur papier. En effet, à partir de ce nuage de points 3D, il est possible d’extraire de multiples supports en 2D et d’ajouter la géométrie ou des informations supplémentaires dans la base de données: contours de la sépulture, représentation du squelette in situ, profils, mesures, altitudes, etc.

    Relevé photogrammétrique d’une sépulture
    Relevé photogrammétrique d’une sépulture

    L’enregistrement des données est assuré par l’utilisation d’une base de données relationnelles et spatiales dont l’interface est accessible dans QGIS, mais également via une interface web directement sur le terrain, sans passer par des inventaires ou listing papier. L’interface web a été réalisée grâce à SQLPage, serveur web qui utilise un langage à base de SQL pour la réalisation de l’interface graphique, sans avoir à passer par les langages de programmation plus complexes classiquement utilisés pour la création d’applications web, tel PHP.

    Bien entendu, cette démarche se poursuit également en laboratoire lors de l’étape d’analyse du site.

    Logiciels et formats libres

    Mais l’abandon du support papier nécessite de nous poser la question de la pérennité des fichiers et des données qu’ils contiennent.

    En effet, dans un processus de dématérialisation complet, la mémoire du site n’est plus contenue sur des centaines de fiches manuscrites, mais dans des fichiers numériques dont nous ignorons à priori si nous pourrons les conserver sur le long terme. L’impossibilité d’accéder à cette donnée avec d’autres logiciels que ceux originellement utilisés lors de leur création équivaut à leur destruction. Seuls les formats standards peuvent répondre à cette problématique, et ils sont particulièrement utilisés par les logiciels libres. Pour la photogrammétrie, les formats .ply et .obj, qui sont implémentés dans de nombreux logiciels, libres et propriétaires, ont été choisis. Pour la donnée attributaire et spatiale, elle est enregistrée dans des bases de données relationnelles libres (Spatialite et Postgis), et facilement exportable en .sql, qui est un format standardisé et reconnu par de très nombreuses bases de données.

    Malheureusement, le logiciel libre reste peu utilisé dans notre quotidien archéologique, et les logiciels propriétaires sont souvent très bien implantés. Le libre souffre encore aujourd’hui d’a priori et d’une mauvaise image au sein de la communauté archéologique, qui le trouve plus compliqué, moins joli, moins efficace, etc.

    Le libre a cependant fait une incursion majeure avec l’arrivée du Système d’Information Géographique (SIG) libre QGIS, qui a permis d’installer un SIG sur tous les postes des agents de l’institut et de l’envisager comme un outil d’analyse à l’échelle d’un site archéologique. Par un accompagnement et la mise en place d’un plan de formation adéquat, de nombreux archéologues ont été formés à l’usage du logiciel au sein de l’Institut.

    QGIS a véritablement révolutionné nos pratiques en permettant l’interrogation immédiate de la donnée attributaire par la donnée spatiale (quel est ce vestige que je vois sur le plan ?) ou, à l’inverse, de localiser un vestige par sa donnée attributaire (où se trouve la sépulture 525 ?). Il est cependant très fréquent d’avoir encore d’un côté la donnée attributaire dans des tableurs ou des bases de données propriétaires, et la donnée spatiale dans QGIS, l’interrogation des deux reposant sur des jointures.

    Bien entendu, QGIS permet aussi l’analyse des données, la création de plans thématiques ou chronologiques, indispensables supports à nos réflexions. Nous pouvons, à partir de ces éléments, réaliser les très nombreuses figures du rapport d’opération, sans passer par un logiciel de dessin vectoriel, en plan comme en coupe (représentation verticale de la stratigraphie). Il permet de normaliser les figures par l’emploi des styles, et, par l’usage de l’outil Atlas, de réaliser des catalogues complets, pour peu que la donnée soit rigoureusement structurée.

    analyse spatiale
    Exemple d’analyse dans Qgis de répartition des rejets de céramique sur un site gaulois

    Dans le cadre de l’expérimentation sur la nécropole des Mastraits, Si Qgis est bien un des piliers du système, quelques logiciels propriétaires sont encore employés.

    Le logiciel de traitement utilisé pour la photogrammétrie est propriétaire. L’objectif à terme est de pouvoir utiliser un logiciel libre, MicMac, développé par l’IGN, étant un possible candidat. Il manque cependant encore d’une interface pleinement intuitive pour que les archéologues puissent s’approprier l’outil de manière autonome.

    De même, les enthousiasmantes dernières évolutions du projet Inkscape devraient nous inciter à nous tourner davantage vers ce logiciel et à utiliser de manière systématique le .svg. L’usage de Scribus pour la PAO devrait également être sérieusement envisagée.

    Le logiciel libre et ses indéniables avantages prend ainsi doucement place, essentiellement via QGIS, dans la chaîne de production de nos données archéologiques. Nous ne pouvons qu’espérer que cette place grandira. Le chemin paraît encore long, mais la voie libre…

    Badass, spatial et attributaire réunis

    Le développement de la Base Archéologique de Données Attributaires et SpatialeS a eu comme objectif d’intégrer, au sein d’une seule et même base de données, les informations attributaires renseignées par les archéologues et les informations spatiales recueillies par le topographe. Il s’agit même de rassembler, au sein des tables dédiées, les informations attributaires et spatiales, garantissant ainsi l’intégrité de la donnée.
    Son principe s’appuie sur le fonctionnement de la chaine opératoire en archéologie, à savoir l’identification et l’enregistrement par l’archéologue des vestiges mis au jour, auquel succède le relevé tridimentionnel réalisé par le topographe. Ce dernier dispose, dans la base de données, de tables spécifiques dans laquelle il peut verser la géométrie et des données attributaires minimales (numéro, type). Des triggers vont ensuite alimenter les tables renseignées par les archéologues avec la géométrie, selon leur identifiant et leur type.

    La base est ainsi l’unique dépositaire de l’information attributaire et spatiale tout au long de l’opération, du terrain à la post fouille.

    Le format de la base de données est à l’origine SpatiaLite. Mais la masse documentaire produite par la nécropole des Mastraits nous a conduit à la porter sous PostGIS. Nombre d’opérations archéologiques ne nécessitent cependant qu’une petite base SpatiaLite, qui permet en outre à l’archéologue d’avoir la main sur son fichier de données. Seuls quelques gros chantiers peuvent avoir besoin d’une solution PostgreSQL, par ailleurs utilisée pour le CAtalogue de VIsualisation ARchéologique (Caviar) qui a vocation à accueillir les données spatiales et attributaires produites à l’institut.

    Naturellement, Badass a été couplée à un projet QGIS proposant déjà des styles par défaut, mais aussi quelques requêtes ou vues communément utilisées lors d’une étude archéologique. Une extension QGIS a été développée par plusieurs étudiants afin de permettre la génération automatique du projet et de la base de données.

    Pour entrer dans Badass : la Bad’Mobil

    Il restait la question de la portabilité de ce système. QGIS est un logiciel demandant beaucoup de ressource et dont l’interface est inadaptée aux petits écrans, appréciés pour leur portabilité sur le terrain (téléphones et tablettes).

    Choisir d’utiliser une base SpatiaLite ou PostGIS permettait d’envisager dès le départ une interface web, qui pourrait alors être utilisée sur n’importe quel terminal. Il avait d’abord été envisagé de lancer un développement en PHP/HTML/CSS avec un serveur web Apache. Mais ceci nécessitait de disposer d’un serveur web, et de programmer toute une interface. Il restait aussi à répondre à quelques questions d’infrastructure : où l’héberger, quels financements pour cela, et qui pour administrer l’ensemble ?

    C’est ici même, sur LinuxFR, que l’un des membres du collectif a découvert SQLPage. Ce logiciel libre, développée par lovasoa, permet de disposer d’un serveur web très simple, et la réalisation d’une application de type CRUD avec une interface dont le développement ne repose que sur du SQL.

    SQLPage repose sur un fichier exécutable, qui, lancé sur un poste informatique, transforme celui-ci en serveur web. Un fichier de configuration permet de définir notamment l’emplacement de la base de données qui sera interrogée. Pour chaque page web de l’interface, on écrit un fichier .sql pour définir les données à aller chercher ou modifier dans la base, et les composants d’interface qui permettront de l’afficher (tableaux, formulaires, graphiques…). L’accès à cette interface se fait dans un navigateur web. Si le poste est en réseau, l’adresse IP du poste permet d’y accéder à distance, avec une adresse comme http://192.168.1.5:8080 par exemple. L’utilisation d’un VPN nous permet d’utiliser le réseau de téléphonie mobile, ce qui nous dispense de toute mise en place d’un réseau local avec routeur, antennes, etc.

    principe
    Principe de fonctionnement général

    Ainsi, l’installation de l’ensemble est très simple et ne repose que sur une arborescence de fichiers à déployer sur le poste serveur : la base de donnée, et un répertoire contenant le binaire SQLPage et les fichiers constituant les pages web.

    En nous appuyant sur la documentation (et en posant parfois des questions à l’auteur du logiciel), nous avons pu développer seuls une interface très complète répondant bien à nos besoins sur le terrain. Nommée Bad’Mobil, l’interface web permet d’accéder à l’ensemble des données attributaires renseignées par les archéologues et permet désormais, grâce aux évolutions constantes de développement de SQLPage, de visualiser la donnée spatiale. La documentation produite au cours du chantier peut également être consultée si les fichiers (photos, dessins scannés, etc.) sont placés au bon endroit dans l’arborescence. Les pages se composent principalement de formulaires de création ou de modification, ainsi que de tableaux listant les éléments déjà enregistrés. La visualisation de la géométrie permet de se repérer spatialement sur le terrain, en particulier en cas de chantier complexe, et d’interagir avec la donnée attributaire.

    L’interface de BadMobil, avec SQLPage
    L’interface de BadMobil, avec SQLPage

    Cas d’utilisation et bénéfices concrets

    Première expérience aux Mastraits

    Le chantier de fouille de la Nécropole des Mastraits a été le chantier test de ces développements. L’importante quantité de données récoltées, mais également son statut de fouille programmée permet de mettre en place ce genre d’expérimentation avec un impact bien moindre que dans une fouille préventive où les délais sont particulièrement contraints.

    La mise en place de l’interface SQLPage a permis la dématérialisation complète de l’enregistrement attributaire, et se révèle très performante. Il s’agit d’un changement majeur de nos pratiques et va nous permettre gagner un temps extrêmement important lors du traitement des données.

    Ceci permet également de centraliser l’information, de travailler à plusieurs personnes en même temps sans attendre la disponibilité des classeurs d’enregistrement traditionnellement utilisés, et de guider les archéologues au cours du processus d’enregistrement, évitant les oublis et les erreurs. Grâce à une interface simplifiée, la saisie peut se faire de manière très intuitive sans réelle nécessité de formation approfondie.

    L’homogénéité de la donnée saisie est ainsi meilleure, et les possibilités d’interrogation bien plus importantes.

    Perspectives d’avenir

    À l’issue du développement de Badass et Bad’mobil sur la nécropole des Mastraits, il nous a paru possible d’envisager son déploiement dans le cadre de l’archéologie préventive. Si la question de l’infrastructure réseau nécessaire au fonctionnement de cette solution peut se poser (nécessité de disposer d’une alimentation électrique stable sur des chantiers perdus en pleine campagne, disponibilité des tablettes, couverture réseau…), les bénéfices en termes d’homogénéité des données et de facilité de saisie sont très importants. Quelques chantiers d’archéologie préventive ont ainsi pu tester le système, la plupart du temps sur des sites de petite ampleur, en bénéficiant de l’accompagnement des membres du collectif.

    Les développements futurs s’orienteront sans doute vers l’intégration de nouveaux formulaires, ou de nouveaux outils de suivi. Actuellement, Badass permet de recueillir les observations communes à tous les sites archéologiques, ainsi que les observations anthropologiques du fait de son utilisation au sein de la nécropole des Mastraits.
    Nous pourrions ainsi envisager d’intégrer les nombreuses spécialités de l’archéologie, mais il est probable que nous obtenions alors une énorme machine dont la maintenance pourrait s’avérer complexe. Nous restons donc prudents à ce sujet.

    Conclusion

    Petit à petit, l’emploi des outils numériques s’est généralisé dans les métiers de l’archéologie. Après les traitements de texte et tableurs des années 90 (souvent sous mac), les premiers dessins vectoriels numérisés sous Adobe Illustrator, et les bases de données sous Filemaker, Access ou 4D, les outils numériques sont aujourd’hui en mesure d’être utilisés au cours de toute la chaîne d’acquisition de la donnée.

    L’apport des logiciels et des formats libres est majeur pour cette nouvelle étape.

    QGIS a fondamentalement révolutionné la pratique archéologique en offrant au plus grand nombre l’accès au SIG, permettant de relier et de manipuler les données attributaires et spatiales. Il a ouvert la voie à de nouvelles évolutions, et à l’intégration de technologies jusque-là peu utilisées par l’archéologie (notamment l’utilisation de bases de données relationnelles et spatiales au format SQL).
    SQLpage nous a permis d’offrir à l’archéologue une interface complète et simple afin d’accéder à une base de données en réseau. Si son développement nécessite une connaissance certaine du SQL et du fonctionnement d’un site web, son déploiement et sa maintenance sont tout à fait abordables.
    SQLPage répond à un réel besoin sur le terrain. Pour les archéologues, il permet de simplifier leur pratique tout en répondant à la complexité grandissante face à la masse documentaire à traiter, et à l’accroissement de l’exigence qualitative des rendus.

    L’association de QGIS, des bases de données spatiales et relationnelles et d’une interface web parfaitement adaptée au terrain comblent désormais le manque constaté d’un outil efficace et fiable d’enregistrement archéologique à l’échelle de l’opération. À ce titre, Badass associée à Bad‘Mobil comblent totalement les attentes des archéologues qui les ont expérimentés.

    Si les logiciels libres ont, ces dernières années, entamé une timide percée chez de nombreux opérateurs d’archéologie (certains les ont pleinement adoptés), des réticences restent présentes, que ce soit des utilisateurs, mais aussi parfois des DSI des administrations publiques, qui peuvent préférer opter pour un service tout-en-un doté d’un support technique.

    Mais la persistance des usages des logiciels propriétaires n’est pas sans poser de réels problèmes quant à la pérennité des données archéologiques et les archéologues commencent juste à découvrir le problème. Leur attachement à leurs données — si elle va parfois à l’encontre du principe de la science ouverte — devrait cependant les inciter à opter pour des formats dont la pérennité apparaît certaine, garantissant par là même l’accès à ces données dans le futur, quel que soit le logiciel ou le système d’exploitation utilisé, s’ils ne veulent pas que leur travail tombe dans l’oubli…

    Commentaires : voir le flux Atom ouvrir dans le navigateur

    Règles de pérennité des comptes LinuxFr.org, données à caractère personnel et effet un an

    3 juin 2024 à 15:38

    En février 2023, nous annoncions la mise en place d’une durée de conservation des données à caractère personnel (DCP) sur LinuxFr.org, avec à partir du 28 juin 2023 :

    • fermeture des comptes inactifs pendant trois ans et suppression de leurs données conservées inutiles au service ;
    • suppression des données associées inutiles au service pour les comptes fermés depuis plus d’un an.

    L’aide du site explique :

    Depuis le 31 mai 2023, une information de date de dernière activité est associée à chaque compte. Ajoutons que depuis septembre 2023 l’accès à cette information est aussi réduite au besoin du service (on peut connaître l’info de son propre compte ; les admins ont seulement besoin de savoir si la dernière activité date de moins d’un mois, d’un an, trois ans ou plus, en raison des règles précitées).

    Nous voici donc un an après, et cette partie de la règle s’applique donc pour la première fois. Nous détaillerons les effets dans la seconde partie de la dépêche.

    Sommaire

    Script de minimisation des données et semaine normale

    La suppression des données inutiles au service repose actuellement sur un script de minimisation externe, lancé manuellement. Une des raisons de l’aspect manuel est notamment le fait que l’on n’avait pas encore passé la première année, qui marque un seuil comme nous le verrons plus tard.

    La précédente exécution du script ayant eu lieu le 19 mai 2024 à 11h (Paris), voyons ce que ça donne sur 12 jours et quelques heures :

    Started at vendredi 31 mai 2024, 22:19:15 (UTC+0200)
    Dry run mode
    13 inactive accounts never used to purge
    0 users to minimize
    0 accounts to minimize because inactive and not seen since 1 year
    0 active accounts not seen since 3 years to inactivate and minimize
    12 users without comments/contents to purge
    12 accounts to purge
    6 logs to purge
    12 friendly_id_slugs to purge
    0 taggings to purge
    0 oauth_access_grants for an oauth_application to purge
    0 oauth_access_tokens for an oauth_application to purge
    0 oauth_applications to purge
    0 oauth_access_grants to purge
    0 oauth_access_tokens to purge
    0 deleted comments to minimize
    0 comments from non-public contents to purge
    0 taggings from non-public contents to purge
    0 wiki_versions from non-public wiki_pages to purge
    0 slugs from non-public wiki_pages to purge
    0 non-public wiki_pages to purge
    0 slugs from non-public trackers to purge
    0 non-public trackers to purge
    0 slugs from non-public posts to purge
    0 non-public posts to purge
    0 poll_answers to from non-public polls to purge
    0 slugs from non-public polls to purge
    0 non-public polls to purge
    0 slugs from non-public bookmarks to purge
    0 non-public bookmarks to purge
    0 slugs from non-public diaries to purge
    0 diaries converted into non-public news to purge
    0 non-public diaries to purge
    1 news_versions from non-public news to purge
    10 paragraphs from non-public news to purge
    0 links from non-public news to purge
    1 slugs from non-public news to purge
    1 non-public news to purge
    1 non-public contents to purge
    

    En fonctionnement pré-« 1 an », on a seulement quelques comptes créés mais jamais utilisés à nettoyer (ainsi que tout ce qui y est associé, donc les comptes « accounts », les individus « users », les logs associés « logs » s’il y en a, les raccourcis pour les adresses du site « slugs ») et les contenus, commentaires et étiquetages associés non publics donc non visibles qui ne sont plus nécessaires. On parle donc d’une poignée de comptes et autres par semaine.

    Effet « 1 an »

    Quelques heures plus tard, le résultat n’est plus du tout le même :

    Started at Sat Jun 1 10:55:34 CEST 2024
    Dry run mode
    15 inactive accounts never used to purge
    250 users to minimize
    2616 accounts to minimize because inactive and not seen since 1 year
    0 active accounts not seen since 3 years to inactivate and minimize
    1412 users without comments/contents to purge
    1412 accounts to purge
    2285 logs to purge
    1412 friendly_id_slugs to purge
    6 taggings to purge
    0 oauth_access_grants for an oauth_application to purge
    0 oauth_access_tokens for an oauth_application to purge
    0 oauth_applications to purge
    15 oauth_access_grants to purge
    47 oauth_access_tokens to purge
    147 deleted comments to minimize
    98 comments from non-public contents to purge
    288 taggings from non-public contents to purge
    0 wiki_versions from non-public wiki_pages to purge
    0 slugs from non-public wiki_pages to purge
    0 non-public wiki_pages to purge
    0 slugs from non-public trackers to purge
    0 non-public trackers to purge
    166 slugs from non-public posts to purge
    165 non-public posts to purge
    10 poll_answers to from non-public polls to purge
    2 slugs from non-public polls to purge
    2 non-public polls to purge
    46 slugs from non-public bookmarks to purge
    46 non-public bookmarks to purge
    27 slugs from non-public diaries to purge
    0 diaries converted into non-public news to purge
    27 non-public diaries to purge
    139 news_versions from non-public news to purge
    1278 paragraphs from non-public news to purge
    33 links from non-public news to purge
    66 slugs from non-public news to purge
    61 non-public news to purge
    301 non-public contents to purge
    

    On a certes gagné 2 comptes jamais utilisés de plus à nettoyer, mais surtout on va minimiser plusieurs milliers de comptes et supprimer ou minimiser des centaines de contenus, commentaires et étiquetages. C’est le moment où la main ne doit pas trembler et où l’on doit avoir confiance dans le script de nettoyage et dans nos sauvegardes de la base de données, parce qu’il va falloir l’exécuter pour de vrai, et pas juste en mode « dry run » ou répétition, test à vide.

    En pratique, quelques soucis très mineurs rencontrés sur la grosse transaction faite en base de données : un problème d’ordre de suppression et l’impossibilité de mettre une chaîne vide pour l’adresse de courriel, car il y a un index dessus qui demande l’unicité (une adresse .invalid propre à chaque compte sera donc utilisée).

    Après l’exécution, si on relance le script, on se retrouve juste avec le nombre de comptes encore ouverts mais sans activité depuis un an :

    Started at Sat Jun 1 13:30:16 CEST 2024
    Dry run mode
    0    inactive accounts never used to purge
    0    users to minimize
    905  accounts to minimize because inactive and not seen since 1 year
    (…)
    

    Ça change quoi ?

    Regardons les statistiques des comptes avant et après le nettoyage « 1 an » (les évolutions ont été mises en visibilité avec un point rouge) :

    Avant/après sur les statistiques des comptes

    Interprétation : il s’agit des états des comptes par ordre d’identifiant en base de données (temporellement dans l’ordre de création), regroupés par paquets de 10 000 consécutifs. Quasiment pas de modification sur les comptes très anciens (il y en a beaucoup moins), et les changements se concentrent sur les comptes des dernières années. On a moins de comptes fermés après (on a pu en purger) et donc plus de comptes purgés (c’est-à-dire d’identifiants qui ne sont plus utilisés en base). Et le reste des changements correspond aux visites nominales du site.

    On peut comparer les statistiques juste avant :

    53667 utilisatrices et utilisateurs ayant ou ayant eu des comptes (et encore présents en base de données)
    33216 comptes
    2205 comptes utilisés sur le site au cours des trois derniers mois avec 20.2 jours de moyenne sans visite et 25.3 jours d’écart‑type
    10 comptes en attente
    2809 comptes fermés

    Et les actuelles (au moment de la rédaction de cet article) :

    51943 utilisatrices et utilisateurs ayant ou ayant eu des comptes (et encore présents en base de données)
    31492 comptes
    2208 comptes utilisés sur le site au cours des trois derniers mois avec 20.0 jours de moyenne sans visite et 25.3 jours d’écart‑type
    1 compte en attente
    1089 comptes fermés

    Nous avons aussi réoptimisé les tables de la base de données (enfin on a dit à la base d’optimiser ce qu’elle pouvait avec un OPTIMIZE TABLE quoi). Ça devrait avoir entre une absence d’effet et un effet imperceptible sur les performances, a priori.

    Et côté sauvegarde, on est passé d’un dump compressé gzip de 2 088 253 834 octets avant à 2 086 608 391 octets après, soit un gain faramineux de 0,08 %, bref rien.

    Et après ?

    Une fois « 1 an » passé, on aura chaque semaine les quelques comptes créés mais jamais utilisés à nettoyer, ainsi que les quelques contenus, commentaires et étiquetages associés non publics non nécessaires. Mais aussi les comptes qui auront atteint l’année d’inactivité dans la semaine courante (probablement une ou deux dizaines). Et ce jusqu’aux « 3 ans ».

    À partir des « 3 ans », on va commencer à fermer des comptes et il y aura encore plus de données concernées chaque semaine.

    Et ensuite on aura atteint le rythme nominal de fermeture de comptes et de minimisation de données associées.

    Rendez-vous pour les « 3 ans » en juin 2026 donc.

    Commentaires : voir le flux Atom ouvrir dans le navigateur

    RootDB - une application web de reporting, auto-hebergée

    Logo de RootDB
    Présentation rapide de RootDB, une application auto-hébergeable open-source (AGPLv3), permettant de générer des rapports à base de requêtes SQL.

    Dashboard

    Sommaire

    Genèse du projet

    Pour les besoins d'un client, il fallait que je génère rapidement des statistiques d'usage diverses et variées (à bases de tableaux et graphiques), à partir de plusieurs base de données relationnelles classiques et que j'intègre ces rapports dans un backoffice.

    Le premier réflexe fut de me tourner vers une solution que j'ai utilisée pendant une dizaine d'années auparavant et qui se nomme MyDBR. Cela répondait parfaitement à son besoin tout en étant abordable. MyDBR, bien maitrisé, permet de faire énormément de choses, mais l'interface est vraiment datée et l'accès aux fonctionnalités des bibliothèques graphiques se fait par l’intermédiaire de wrappers en SQL.

    J'ai cherché des alternatives, auto-hébergeables, simples à mettre en place, maintenues et avec la même logique pour la création de rapport mais je n'ai pas trouvé mon bonheur. Il y a, évidemment, pleins de solutions qui existent mais il y avait toujours quelque chose qui n'allait pas après essai, que ce soit dans la manière de générer des rapports ou bien les pré-requis, parfois compliqués, pour l'hébergement.

    D'ou l'idée de créer, avec un collègue, notre propre solution de reporting - parce que pourquoi pas, finalement.

    Open-source

    Ce projet n'était pas open-source à la base et nous pensions simplement vendre des licences d'utilisation.

    Sauf qu’aujourd’hui beaucoup de monde utilise le cloud, et ce dernier vient avec ses solutions intégrées de reporting, limitant de fait l'intérêt de ce genre de projet. Pour faire bref, je reste convaincu que tout le monde n'est pas sur le cloud et que ce genre de solution peut encore intéresser quelques personnes.
    À cause des doutes sur la pertinence même du projet, je n'ai jamais sérieusement cherché du financement, ce qui ne m'a jamais permis d'être à temps plein dessus. Nous avons donc mis du temps avant de produire quelque chose d'exploitable dans un environnement de production : un an et demi environ.
    À cela s'ajoute le fait que ce projet n'existerait pas sans toutes les briques open-source sur lesquelles il se base. Et comme c'est l'open-source qui me fait vivre depuis un certain nombre d'années, il me semblait finalement bien plus naturel de rendre ce projet open-source (licence AGPLv3) que d'essayer de le vendre en chiffrant le code source.

    RootDB ?

    Étant familier du SQL et du JavaScript, nous voulions avoir une solution qui ne mette pas de bâtons dans les roues du développeur, à savoir :

    • utiliser principalement le SQL pour la récupération et le traitement des données ;
    • avoir un accès intégral à la bibliothèque graphique choisie ;

    Ce choix de préférer un environnement de développement de rapport orienté développeur est assumé, d'où le nom du projet.

    Fonctionnalités

    Je ne vais pas vous présenter toutes les fonctionnalités car le site web principal et l'instance de démonstration les présentent déjà correctement. Je vais donc plutôt mettre en avant les spécificités du projet.

    Websocket

    Les requêtes SQL peuvent prendre du temps à tourner, surtout si les tables ne sont pas correctement optimisées. Par conséquent l'interface repose lourdement sur les websockets afin d'éviter les problèmes de timeout. Quand un rapport est exécuté, l'exécution des différentes requêtes est dispatchée de manière asynchrone et les vues affichent des résultats uniquement quand les données arrivent sur le websocket du rapport.
    D'une manière générale toute l'interface est rafraichie par websocket.

    Bibliothèques graphiques au choix

    Nous donnons accès à Chart.js ou D3.js, sans limitation, sans wrapper. Il est donc possible de se référer directement à la documentation officielle de ces deux bibliothèques.

    Onglets & Menu

    Nous aimons bien les menus. :)
    C'est simple, élégant et permet d'accéder à beaucoup d'options de manière claire.
    L'interface repose sur une barre de menu principale dynamique et une barre d'onglets dans lesquels s'affiche les différentes parties de l'application. Il est donc possible d'ouvrir plusieurs rapports (ou le même) dans le même onglet du navigateur web.

    Cache

    Il existe deux niveaux de cache :

    • un cache utilisateur, pratique pour cacher des résultats de manière temporaire afin de partager des résultats avec un autre utilisateur.
    • un cache système (jobs) ou il est possible de générer du cache de manière périodique. Nécessaire pour des rapports qui utilisent de très grosses tables qu'il n'est parfois pas possible d'optimiser.

    Paramètres en entrée

    Il est très facile de générer ses propres paramètres afin de filtrer les rapports, que ce soit sur une plage de date, une liste d'options sortie d'une base de données, des cases à cocher etc.

    Liens entre rapports

    Que ce soit avec Chart.js ou bien un tableau, vous pouvez créer des liens entre vos rapports ou bien sur le même rapport pour faire des rapports de type drill-down.

    Hébergement

    Côté API, RootDB est une application Laravel qui fonctionne sur du PHP en version 8.2.x (voir 8.3.x, mais pas encore bien testé) et utilise Memcached pour la gestion du cache.
    Le serveur de websocket est propulsé par Laravel Reverb.
    Côté Frontend, il s'agit d'une application React classique, en TypeScript, qui utilise PrimeReact pour la suite de composants prêt-à-l'emploi.

    Conclusion

    Concernant les fonctionnalités que nous aimerions mettre en place petit à petit :

    • une interface de configuration pour Chart.js - afin de, quand même, rendre plus simple la configuration des charts, tout en laissant la liberté au développeur de coder en javascript les fonctionnalités avancés ;
    • un nouveau type de connecteur pour supporter Microsoft SQL Server ;
    • une fonctionnalité d'auto-rafraichissement des rapports ;
    • l'import asynchrone de gros fichiers CSV ou Excel.

    Nous pouvons aider à l'utilisation, par l’intermédiaire :

    • d'un salon discord mais ce n'est pas forcément idéal pour ce genre de projet. Je suis donc entrain de regarder du côté de Matrix, éventuellement ;
    • un forum classique.

    Voilà, c'était une brève présentation de RootDB.
    C'est un projet qui n'a pas encore été testé par beaucoup de monde, d’où cette présentation pour le faire connaitre un peu plus.

    Commentaires : voir le flux Atom ouvrir dans le navigateur

    Ubix Linux, le datalab de poche

    Ubix Linux est une distribution Linux libre et open-source dérivée de Debian.

    Le nom « Ubix » est la forme contractée de « Ubics », acronyme issu de l'anglais Universal business intelligence computer system. De fait, le principal objectif d'Ubix Linux est d'offrir une plateforme universelle dédiée à l'informatique décisionnelle et à l'analyse des données.

    Il s'agit d'une solution verticale, prête à l'emploi, dédiée à la manipulation des données et à la prise de décision. Allégée par conception, elle n'embarque qu'un jeu limité d'outils spécialisés dans ce domaine. Ceux-ci permettent néanmoins de couvrir tous les besoins dont l'acquisition, la transformation, l'analyse et la présentation des données.

    Ubix Linux - Vue d'ensemble

    Origines de la distribution

    La volonté initiale du concepteur de la distribution était de pouvoir disposer, à tout moment et en toutes circonstances, des outils lui permettant de réaliser des analyses de données et d'en présenter le résultat ad hoc. Ce « couteau suisse » de manipulation des données, devait également lui permettre d'éviter de devoir justifier, rechercher, acquérir et installer l'écosystème logiciel nécessaire chaque fois que ce type de tâches se présentait à lui.

    Son cahier des charges stipulait donc une empreinte disque la plus faible possible sans pour autant faire de concessions au niveau des fonctionnalités. La distribution se devait d'être portable et exécutable immédiatement dans des contextes variés, sans nécessité d'investissement, d'installation ou de droits d'accès particulier.

    De ce fait, Ubix Linux ne se démarque pas par ses aspects « système », mais plutôt par sa destination et ses cas d'usage.

    Au-delà du besoin initial

    À l'heure où de nombreux concepts liés à la manipulation des données tels que le « Big Data », la « Data Science » ou le « Machine Learning » font la une de nombreux médias, ceux-ci restent encore des boîtes noires, affaire de spécialistes et d'organisation disposant des moyens de les mettre en application.

    Si le grand public en intègre de mieux en mieux les grandes lignes, il ne dispose encore que de peu de recul sur la manière dont ses données peuvent être utilisées, ainsi que la richesse des débouchés associés.

    D'un autre côté, de nombreux gisements de données à la portée du plus grand nombre demeurent inexploités, faute de compétences ou de moyens facilement accessibles.

    Il se trouve qu'Ubix Linux peut permettre de surmonter cette difficulté, en offrant à tous les moyens de s'approprier (ou se réapproprier) et tirer parti des données disponibles.

    Philosophie

    Par nécessité, Ubix Linux a été conçue en intégrant uniquement des produits libres et open-source. Bien que cette distribution puisse s'avérer utile à toute personne devant manipuler des données, elle se doit de préserver et défendre une approche pédagogique et universaliste.

    Elle a pour ambition de mettre les sciences de données à la portée de tous. La distribution en elle-même n'est qu'un support technique de base devant favoriser l'apprentissage par la pratique. Il est prévu de l'accompagner d'un tutoriels progressifs.

    Les outils low-code/no-code intégrés dans la distribution permettent de commencer à manipuler des données sans devoir maîtriser au préalable la programmation. Néanmoins, des outils plus avancés permettent ensuite de s'initier aux principes des algorithmes d'apprentissage automatique.

    Synthèse

    Ubix Linux s'inscrit dans la philosophie du logiciel libre et plus particulièrement dans celle des projets GNU et Debian.

    Elle se destine à :

    • demeurer accessible à tous ;
    • pouvoir s'exécuter sur des configurations matérielles relativement modestes, voire n'être installée que sur un périphérique portable USB ;
    • proposer un outil pédagogique pour appréhender de façon pratique la science des données et l'apprentissage machine ;
    • permettre la découverte, l'expérimentation et l'aguerrissement de tout un chacun aux principaux outils de manipulation des données ;
    • offrir une boîte à outils légère et agile, néanmoins complète et utile pour un public professionnel averti.

    Et après…

    Nous sommes à l'écoute de toute suggestion. Toutefois, les moyens étant ce qu'ils sont (au fond du garage), la réactivité à les prendre en compte pourra s'avérer inversement proportionnelle.

    Nous souhaiterions que cet outil pédagogique puisse bénéficier au plus grand nombre : si vous voulez contribuer à la traduction du contenu du site officiel en espagnol, en portugais ou en allemand, vous êtes les bienvenus.

    Commentaires : voir le flux Atom ouvrir dans le navigateur

    David Revoy, un artiste face aux IA génératives

    Par : Goofy
    2 juillet 2023 à 05:42

    Depuis plusieurs années, Framasoft est honoré et enchanté des illustrations que lui fournit David Revoy, comme sont ravi⋅es les lectrices et lecteurs qui apprécient les aventures de Pepper et Carrot et les graphistes qui bénéficient de ses tutoriels. Ses créations graphiques sont sous licence libre (CC-BY), ce qui est un choix courageux compte tenu des « éditeurs » dépourvus de scrupules comme on peut le lire dans cet article.

    Cet artiste talentueux autant que généreux explique aujourd’hui son embarras face aux IA génératives et pourquoi son éthique ainsi que son processus créatif personnel l’empêchent de les utiliser comme le font les « IArtistes »…

    Article original en anglais sur le blog de David Revoy

    Traduction : Goofy, révisée par l’auteur.

    Intelligence artificielle : voici pourquoi je n’utiliserai pas pour mes créations artistiques de hashtag #HumanArt, #HumanMade ou #NoAI

    par David REVOY

     

    Pepper sur une chaise entourée de flammes, reprise d'un célèbre mème "this is fine"

    Image d’illustration : « This is not fine », licence CC-BY 4.0, source en haute résolution disponible

    « C’est cool, vous avez utilisé quel IA pour faire ça ? »

    « Son travail est sans aucun doute de l’IA »

    « C’est de l’art fait avec de l’IA et je trouve ça déprimant… »

    … voilà un échantillon des commentaires que je reçois de plus en plus sur mon travail artistique.

    Et ce n’est pas agréable.

    Dans un monde où des légions d’IArtistes envahissent les plateformes comme celles des médias sociaux, de DeviantArt ou ArtStation, je remarque que dans l’esprit du plus grand nombre on commence à mettre l’Art-par-IA et l’art numérique dans le même panier. En tant qu’artiste numérique qui crée son œuvre comme une vraie peinture, je trouve cette situation très injuste. J’utilise une tablette graphique, des layers (couches d’images), des peintures numériques et des pinceaux numériques. J’y travaille dur des heures et des heures. Je ne me contente pas de saisir au clavier une invite et d’appuyer sur Entrée pour avoir mes images.
    C’est pourquoi j’ai commencé à ajouter les hashtags #HumanArt puis #HumanMade à mes œuvres sur les réseaux sociaux pour indiquer clairement que mon art est « fait à la main » et qu’il n’utilise pas Stable Diffusion, Dall-E, Midjourney ou n’importe quel outil de génération automatique d’images disponible aujourd’hui. Je voulais clarifier cela pour ne plus recevoir le genre de commentaires que j’ai cités au début de mon intro. Mais quel est le meilleur hashtag pour cela ?

    Je ne savais pas trop, alors j’ai lancé un sondage sur mon fil Mastodon

    sondage sur le fil mastodon de David : Quel hashtag recommanderiez-vous à un artiste qui veut montrer que son art n'est paz créé par IA ? réponses : 55% #HumanMade 30% #Human Art 15% Autre (commentez)

    Source : https://framapiaf.org/@davidrevoy/110618065523294522

    Résultats

    Sur 954 personnes qui ont voté (je les remercie), #HumanMade l’emporte par 55 % contre 30 % pour #HumanArt. Mais ce qui m’a fait changer d’idée c’est la diversité et la richesse des points de vue que j’ai reçus en commentaires. Bon nombre d’entre eux étaient privés et donc vous ne pouvez pas les parcourir. Mais ils m’ont vraiment fait changer d’avis sur la question. C’est pourquoi j’ai décidé de rédiger cet article pour en parler un peu.

    Critiques des hashtags #HumanMade et #HumanArt

    Tout d’abord, #HumanArt sonne comme une opposition au célèbre tag #FurryArt de la communauté Furry. Bien vu, ce n’est pas ce que je veux.

    Et puis #HumanMade est un choix qui a été critiqué parce que l’IA aussi était une création humaine, ce qui lui faisait perdre sa pertinence. Mais la plupart des personnes pouvaient facilement comprendre ce que #HumanMade signifierait sous une création artistique. Donc 55 % des votes était un score cohérent.

    J’ai aussi reçu pas mal de propositions d’alternatives comme #HandCrafted, #HandMade, #Art et autres suggestions.

    Le succès de #NoAI

    J’ai également reçu beaucoup de suggestions en faveur du hashtag #NoAI, ainsi que des variantes plus drôles et surtout plus crues. C’était tout à fait marrant, mais je n’ai pas l’intention de m’attaquer à toute l’intelligence artificielle. Certains de ses usages qui reposent sur des jeux de données éthiques pourraient à l’avenir s’avérer de bons outils. J’y reviendrai plus loin dans cet article.
    De toutes façons, j’ai toujours essayé d’avoir un état d’esprit « favorable à » plutôt que « opposé à » quelque chose.

    C’est aux artistes qui utilisent l’IA de taguer leur message

    Ceci est revenu aussi très fréquemment dans les commentaires. Malheureusement, les IArtistes taguent rarement leur travail, comme on peut le voir sur les réseaux sociaux, DeviantArt ou ArtStation. Et je les comprends, vu le nombre d’avantages qu’ils ont à ne pas le faire.

    Pour commencer, ils peuvent se faire passer pour des artistes sans grand effort. Ensuite, ils peuvent conférer à leur art davantage de légitimité à leurs yeux et aux yeux de leur public. Enfin, ils peuvent probablement éviter les commentaires hostiles et les signalements des artistes anti-IA des diverses plateformes.
    Je n’ai donc pas l’espoir qu’ils le feront un jour. Je déteste cette situation parce qu’elle est injuste.
    Mais récemment j’ai commencé à apprécier ce comportement sous un autre angle, dans la mesure où ces impostures pourraient ruiner tous les jeux de données et les modèles d’apprentissage : les IA se dévorent elles-mêmes.

    Quand David propose de saboter les jeux de données… :-P 

    Pas de hashtag du tout

    La dernière suggestion que j’ai fréquemment reçue était de ne pas utiliser de hashtag du tout.
    En effet, écrire #HumanArt, #HumanMade ou #NoAI signalerait immédiatement le message et l’œuvre comme une cible de qualité pour l’apprentissage sur les jeux de données à venir. Comme je l’ai écrit plus haut, obtenir des jeux de données réalisées par des humains est le futur défi des IA. Je ne veux surtout pas leur faciliter la tâche.
    Il m’est toujours possible d’indiquer mon éthique personnelle en écrivant « Œuvre réalisée sans utilisation de générateur d’image par IA qui repose sur des jeux de données non éthiques » dans la section d’informations de mon profil de média social, ou bien d’ajouter simplement un lien vers l’article que j’écris en ce moment même.

    Conclusion et considérations sur les IA

    J’ai donc pris ma décision : je n’utiliserai pour ma création artistique aucun hashtag, ni #HumanArt, ni #HumanMade, ni #NoAI.
    Je continuerai à publier en ligne mes œuvres numériques, comme je le fais depuis le début des années 2000.
    Je continuerai à tout publier sous une licence permissive Creative Commons et avec les fichiers sources, parce que c’est ainsi que j’aime qualifier mon art : libre et gratuit.

    Malheureusement, je ne serai jamais en mesure d’empêcher des entreprises dépourvues d’éthique de siphonner complètement mes collections d’œuvres. Le mal est en tout cas déjà fait : des centaines, voire des milliers de mes illustrations et cases de bandes dessinées ont été utilisées pour entraîner leurs IA. Il est facile d’en avoir la preuve (par exemple sur haveibeentrained.com  ou bien en parcourant le jeu de données d’apprentissage Laion5B).

    Je ne suis pas du tout d’accord avec ça.

    Quelles sont mes possibilités ? Pas grand-chose… Je ne peux pas supprimer mes créations une à une de leur jeu de données. Elles ont été copiées sur tellement de sites de fonds d’écran, de galeries, forums et autres projets. Je n’ai pas les ressources pour me lancer là-dedans. Je ne peux pas non plus exclure mes créations futures des prochaines moissons par scans. De plus, les méthodes de protection comme Glaze me paraissent une piètre solution au problème, je ne suis pas convaincu. Pas plus que par la perspective d’imposer des filigranes à mes images…

    Ne vous y trompez pas : je n’ai rien contre la technologie des IA en elle-même.On la trouve partout en ce moment. Dans le smartphones pour améliorer les photos, dans les logiciels de 3D pour éliminer le « bruit » des processeurs graphiques, dans les outils de traduction [N. de T. la présente traduction a en effet été réalisée avec l’aide DeepL pour le premier jet], derrière les moteurs de recherche etc. Les techniques de réseaux neuronaux et d’apprentissage machine sur les jeux de données s’avèrent très efficaces pour certaines tâches.
    Les projets FLOSS (Free Libre and Open Source Software) eux-mêmes comme GMIC développent leurs propres bibliothèques de réseaux neuronaux. Bien sûr elles reposeront sur des jeux de données éthiques. Comme d’habitude, mon problème n’est pas la technologie en elle-même. Mon problème, c’est le mode de gouvernance et l’éthique de ceux qui utilisent de telles technologies.

    Pour ma part, je continuerai à ne pas utiliser d’IA génératives dans mon travail (Stable Diffusion, Dall-E, Midjourney et Cie). Je les ai expérimentées sur les médias sociaux par le passé, parfois sérieusement, parfois en étant impressionné, mais le plus souvent de façon sarcastique .

    Je n’aime pas du tout le processus des IA…

    Quand je crée une nouvelle œuvre, je n’exprime pas mes idées avec des mots.
    Quand je crée une nouvelle œuvre, je n’envoie pas l’idée par texto à mon cerveau.

    C’est un mixage complexe d’émotions, de formes, de couleurs et de textures. C’est comme saisir au vol une scène éphémère venue d’un rêve passager rendant visite à mon cerveau. Elle n’a nul besoin d’être traduite en une formulation verbale. Quand je fais cela, je partage une part intime de mon rêve intérieur. Cela va au-delà des mots pour atteindre certaines émotions, souvenirs et sensations.
    Avec les IA, les IArtistes se contentent de saisir au clavier un certains nombre de mots-clés pour le thème. Ils l’agrémentent d’autres mots-clés, ciblent l’imitation d’un artiste ou d’un style. Puis ils laissent le hasard opérer pour avoir un résultat. Ensuite ils découvrent que ce résultat, bien sûr, inclut des émotions sous forme picturale, des formes, des couleurs et des textures. Mais ces émotions sont-elles les leurs ou bien un sous-produit de leur processus ? Quoi qu’il en soit, ils peuvent posséder ces émotions.

    Les IArtistes sont juste des mineurs qui forent dans les œuvres d’art générées artificiellement, c’est le nouveau Readymade numérique de notre temps. Cette technologie recherche la productivité au moindre coût et au moindre effort. Je pense que c’est très cohérent avec notre époque. Cela fournit à beaucoup d’écrivains des illustrations médiocres pour les couvertures de leurs livres, aux rédacteurs pour leurs articles, aux musiciens pour leurs albums et aux IArtistes pour leurs portfolios…

    Je comprends bien qu’on ne peut pas revenir en arrière, ce public se sent comme empuissanté par les IA. Il peut finalement avoir des illustrations vite et pas cher. Et il va traiter de luddites tous les artistes qui luttent contre ça…

    Mais je vais persister ici à déclarer que personnellement je n’aime pas cette forme d’art, parce qu’elle ne dit rien de ses créateurs. Ce qu’ils pensent, quel est leur goût esthétique, ce qu’ils ont en eux-mêmes pour tracer une ligne ou donner tel coup de pinceau, quelle lumière brille en eux, comment ils masquent leurs imperfections, leurs délicieuses inexactitudes en les maquillant… Je veux voir tout cela et suivre la vie des personnes, œuvre après œuvre.

    J’espère que vous continuerez à suivre et soutenir mon travail artistique, les épisodes de mes bandes dessinées, mes articles et tutoriels, pour les mêmes raisons.


    Vous pouvez soutenir la travail de David Revoy en devenant un mécène ou en parcourant sa boutique.

    Ouvrir le code des algorithmes ? — Oui, mais… (1/2)

    15 mai 2023 à 05:42

    Voici le premier des deux articles qu’Hubert Guillaud nous fait le plaisir de partager. Sans s’arrêter à la surface de l’actualité, il aborde la transparence du code des algorithmes, qui entraîne un grand nombre de questions épineuses sur lesquelles il s’est documenté pour nous faire part de ses réflexions.


    Dans le code source de l’amplification algorithmique : publier le code ne suffit pas !

    par Hubert GUILLAUD

    Le 31 mars, Twitter a publié une partie du code source qui alimente son fil d’actualité, comme l’a expliqué l’équipe elle-même dans un billet. Ces dizaines de milliers de lignes de code contiennent pourtant peu d’informations nouvelles. Depuis le rachat de l’oiseau bleu par Musk, Twitter a beaucoup changé et ne cesse de se modifier sous les yeux des utilisateurs. La publication du code source d’un système, même partiel, qui a longtemps été l’un des grands enjeux de la transparence, montre ses limites.

    un jeune homme montre une ligne d'une explication de l'encodage des algorithmes au rétroprojecteur

    « LZW encoding and decoding algorithms overlapped » par nayukim, licence CC BY 2.0.

    Publier le code ne suffit pas

    Dans un excellent billet de blog, le chercheur Arvind Narayan (sa newsletter mérite également de s’y abonner) explique ce qu’il faut en retenir. Comme ailleurs, les règles ne sont pas claires. Les algorithmes de recommandation utilisent l’apprentissage automatique ce qui fait que la manière de classer les tweets n’est pas directement spécifiée dans le code, mais apprise par des modèles à partir de données de Twitter sur la manière dont les utilisateurs ont réagi aux tweets dans le passé. Twitter ne divulgue ni ces modèles ni les données d’apprentissages, ce qui signifie qu’il n’est pas possible d’exécuter ces modèles. Le code ne permet pas de comprendre pourquoi un tweet est ou n’est pas recommandé à un utilisateur, ni pourquoi certains contenus sont amplifiés ou invisibilisés. C’est toute la limite de la transparence. Ce que résume très bien le journaliste Nicolas Kayser-Bril pour AlgorithmWatch (pertinemment traduit par le framablog) : « Vous ne pouvez pas auditer un code seulement en le lisant. Il faut l’exécuter sur un ordinateur. »

    « Ce que Twitter a publié, c’est le code utilisé pour entraîner les modèles, à partir de données appropriées », explique Narayan, ce qui ne permet pas de comprendre les propagations, notamment du fait de l’absence des données. De plus, les modèles pour détecter les tweets qui violent les politiques de Twitter et qui leur donnent des notes de confiance en fonction de ces politiques sont également absentes (afin que les usagers ne puissent pas déjouer le système, comme nous le répètent trop de systèmes rétifs à l’ouverture). Or, ces classements ont des effets de rétrogradation très importants sur la visibilité de ces tweets, sans qu’on puisse savoir quels tweets sont ainsi classés, selon quelles méthodes et surtout avec quelles limites.

    La chose la plus importante que Twitter a révélée en publiant son code, c’est la formule qui spécifie comment les différents types d’engagement (likes, retweets, réponses, etc.) sont pondérés les uns par rapport aux autres… Mais cette formule n’est pas vraiment dans le code. Elle est publiée séparément, notamment parce qu’elle n’est pas statique, mais qu’elle doit être modifiée fréquemment.

    Sans surprise, le code révèle ainsi que les abonnés à Twitter Blue, ceux qui payent leur abonnement, bénéficient d’une augmentation de leur portée (ce qui n’est pas sans poser un problème de fond, comme le remarque pertinemment sur Twitter, Guillaume Champeau, car cette préférence pourrait mettre ces utilisateurs dans la position d’être annonceurs, puisqu’ils payent pour être mis en avant, sans que l’interface ne le signale clairement, autrement que par la pastille bleue). Reste que le code n’est pas clair sur l’ampleur de cette accélération. Les notes attribuées aux tweets des abonnés Blue sont multipliées par 2 ou 4, mais cela ne signifie pas que leur portée est pareillement multipliée. « Une fois encore, le code ne nous dit pas le genre de choses que nous voudrions savoir », explique Narayan.

    Reste que la publication de la formule d’engagement est un événement majeur. Elle permet de saisir le poids des réactions sur un tweet. On constate que la réponse à tweet est bien plus forte que le like ou que le RT. Et la re-réponse de l’utilisateur originel est prédominante, puisque c’est le signe d’une conversation forte. À l’inverse, le fait qu’un lecteur bloque, mute ou se désabonne d’un utilisateur suite à un tweet est un facteur extrêmement pénalisant pour la propagation du tweet.

    Tableau du poids attribué en fonction des types d’engagement possibles sur Twitter.

    Ces quelques indications permettent néanmoins d’apprendre certaines choses. Par exemple que Twitter ne semble pas utiliser de prédictions d’actions implicites (comme lorsqu’on s’arrête de faire défiler son fil), ce qui permet d’éviter l’amplification du contenu trash que les gens ne peuvent s’empêcher de regarder, même s’ils ne s’y engagent pas. La formule nous apprend que les retours négatifs ont un poids très élevé, ce qui permet d’améliorer son flux en montrant à l’algorithme ce dont vous ne voulez pas – même si les plateformes devraient permettre des contrôles plus explicites pour les utilisateurs. Enfin, ces poids ont des valeurs souvent précises, ce qui signifie que ce tableau n’est valable qu’à l’instant de la publication et qu’il ne sera utile que si Twitter le met à jour.

    Les algorithmes de recommandation qui optimisent l’engagement suivent des modèles assez proches. La publication du code n’est donc pas très révélatrice. Trois éléments sont surtout importants, insiste le chercheur :

    « Le premier est la manière dont les algorithmes sont configurés : les signaux utilisés comme entrée, la manière dont l’engagement est défini, etc. Ces informations doivent être considérées comme un élément essentiel de la transparence et peuvent être publiées indépendamment du code. La seconde concerne les modèles d’apprentissage automatique qui, malheureusement, ne peuvent généralement pas être divulgués pour des raisons de protection de la vie privée. Le troisième est la boucle de rétroaction entre les utilisateurs et l’algorithme ».

    Autant d’éléments qui demandent des recherches, des expériences et du temps pour en comprendre les limites.

    Si la transparence n’est pas une fin en soi, elle reste un moyen de construire un meilleur internet en améliorant la responsabilité envers les utilisateurs, rappelle l’ingénieur Gabriel Nicholas pour le Center for Democracy & Technology. Il souligne néanmoins que la publication d’une partie du code source de Twitter ne contrebalance pas la fermeture du Consortium de recherche sur la modération, ni celle des rapports de transparence relatives aux demandes de retraits des autorités ni celle de l’accès à son API pour chercheurs, devenue extrêmement coûteuse.

    « Twitter n’a pas exactement ’ouvert son algorithme’ comme certains l’ont dit. Le code est lourdement expurgé et il manque plusieurs fichiers de configuration, ce qui signifie qu’il est pratiquement impossible pour un chercheur indépendant d’exécuter l’algorithme sur des échantillons ou de le tester d’une autre manière. Le code publié n’est en outre qu’un instantané du système de recommandation de Twitter et n’est pas réellement connecté au code en cours d’exécution sur ses serveurs. Cela signifie que Twitter peut apporter des modifications à son code de production et ne pas l’inclure dans son référentiel public, ou apporter des modifications au référentiel public qui ne sont pas reflétées dans son code de production. »

    L’algorithme publié par Twitter est principalement son système de recommandation. Il se décompose en 3 parties, explique encore Nicholas :

    • Un système de génération de contenus candidats. Ici, Twitter sélectionne 1500 tweets susceptibles d’intéresser un utilisateur en prédisant la probabilité que l’utilisateur s’engage dans certaines actions pour chaque tweet (c’est-à-dire qu’il RT ou like par exemple).
    • Un système de classement. Une fois que les 1 500 tweets susceptibles d’être servis sont sélectionnés, ils sont notés en fonction de la probabilité des actions d’engagement, certaines actions étant pondérées plus fortement que d’autres. Les tweets les mieux notés apparaîtront généralement plus haut dans le fil d’actualité de l’utilisateur.
    • Un système de filtrage. Les tweets ne sont pas classés strictement en fonction de leur score. Des heuristiques et des filtres sont appliqués pour, par exemple, éviter d’afficher plusieurs tweets du même auteur ou pour déclasser les tweets d’auteurs que l’utilisateur a déjà signalés pour violation de la politique du site.

    Le score final est calculé en additionnant la probabilité de chaque action multipliée par son poids (en prenant certainement en compte la rareté ou la fréquence d’action, le fait de répondre à un tweet étant moins fréquent que de lui attribuer un like). Mais Twitter n’a pas publié la probabilité de base de chacune de ces actions ce qui rend impossible de déterminer l’importance de chacune d’elles dans les recommandations qui lui sont servies.

    Twitter a également révélé quelques informations sur les autres facteurs qu’il prend en compte en plus du classement total d’un tweet. Par exemple, en équilibrant les recommandations des personnes que vous suivez avec celles que vous ne suivez pas, en évitant de recommander les tweets d’un même auteur ou en donnant une forte prime aux utilisateurs payants de Twitter Blue.

    Il y a aussi beaucoup de code que Twitter n’a pas partagé. Il n’a pas divulgué beaucoup d’informations sur l’algorithme de génération des tweets candidats au classement ni sur ses paramètres et ses données d’entraînement. Twitter n’a pas non plus explicitement partagé ses algorithmes de confiance et de sécurité pour détecter des éléments tels que les abus, la toxicité ou les contenus pour adultes, afin d’empêcher les gens de trouver des solutions de contournement, bien qu’il ait publié certaines des catégories de contenu qu’il signale.

     

    graphe des relations entre comptes twitter, tr-s nombreux traits bleus entre minuscules avatars de comptes, le tout donne une impression d'inextricable comlexité

    « 20120212-NodeXL-Twitter-socbiz network graph » par Marc_Smith ; licence CC BY 2.0.

     

    Pour Gabriel Nicholas, la transparence de Twitter serait plus utile si Twitter avait maintenu ouverts ses outils aux chercheurs. Ce n’est pas le cas.

    Il y a plein d’autres points que l’ouverture de l’algorithme de Twitter a documentés. Par exemple, l’existence d’un Tweepcred, un score qui classe les utilisateurs et qui permet de voir ses publications boostées si votre score est bon, comme l’expliquait Numerama. Ou encore le fait que chaque compte est clustérisé dans un groupe aux profils similaires dans lequel les tweets sont d’abord diffusés avant d’être envoyés plus largement s’ils rencontrent un premier succès… De même, il semblerait qu’il y ait certaines catégories d’utilisateurs spéciaux (dont une catégorie relative à Elon Musk) mais qui servent peut-être plus certaines statistiques qu’à doper la portée de certains comptes comme on l’a entendu (même s’il semble bien y avoir une catégorie VIP sur Twitter – comme il y a sur Facebook un statut d’exception à la modération)…

    Ouvrir, mais ouvrir quoi ?

    En conclusion de son article, Narayan pointe vers un très intéressant article qui dresse une liste d’options de transparence pour ceux qui produisent des systèmes de recommandation, publiée par les chercheurs Priyanjana Bengani, Jonathan Stray et Luke Thorburn. Ils rappellent que les plateformes ont mis en place des mesures de transparence, allant de publications statistiques à des interfaces de programmation, en passant par des outils et des ensembles de données protégés. Mais ces mesures, très techniques, restent insuffisantes pour comprendre les algorithmes de recommandation et leur influence sur la société. Une grande partie de cette résistance à la transparence ne tient pas tant aux risques commerciaux qui pourraient être révélés qu’à éviter l’embarras d’avoir à se justifier de choix qui ne le sont pas toujours. D’une manière très pragmatique, les trois chercheurs proposent un menu d’actions pour améliorer la transparence et l’explicabilité des systèmes.

    Documenter
    L’un des premiers outils, et le plus simple, reste la documentation qui consiste à expliquer en termes clairs – selon différentes échelles et niveaux, me semble-t-il – ce qui est activé par une fonction. Pour les utilisateurs, c’est le cas du bouton « Pourquoi je vois ce message » de Facebook ou du panneau « Fréquemment achetés ensemble » d’Amazon. L’idée ici est de fourbir un « compte rendu honnête ». Pour les plus évoluées de ces interfaces, elles devraient permettre non seulement d’informer et d’expliquer pourquoi on nous recommande ce contenu, mais également, permettre de rectifier et mieux contrôler son expérience en ligne, c’est-à-dire d’avoir des leviers d’actions sur la recommandation.

    Une autre forme de documentation est celle sur le fonctionnement général du système et ses décisions de classement, à l’image des rapports de transparence sur les questions de sécurité et d’intégrité que doivent produire la plupart des plateformes (voir celui de Google, par exemple). Cette documentation devrait intégrer des informations sur la conception des algorithmes, ce que les plateformes priorisent, minimisent et retirent, si elles donnent des priorités et à qui, tenir le journal des modifications, des nouvelles fonctionnalités, des changements de politiques. La documentation doit apporter une information solide et loyale, mais elle reste souvent insuffisante.

    Les données
    Pour comprendre ce qu’il se passe sur une plateforme, il est nécessaire d’obtenir des données. Twitter ou Facebook en ont publié (accessibles sous condition de recherche, ici pour Twitter,  pour Facebook). Une autre approche consiste à ouvrir des interfaces de programmation, à l’image de CrowdTangle de Facebook ou de l’API de Twitter. Depuis le scandale Cambridge Analytica, l’accès aux données est souvent devenu plus difficile, la protection de la vie privée servant parfois d’excuse aux plateformes pour éviter d’avoir à divulguer leurs pratiques. L’accès aux données, même pour la recherche, s’est beaucoup refermé ces dernières années. Les plateformes publient moins de données et CrowdTangle propose des accès toujours plus sélectifs. Chercheurs et journalistes ont été contraints de développer leurs propres outils, comme des extensions de navigateurs permettant aux utilisateurs de faire don de leurs données (à l’image du Citizen Browser de The Markup) ou des simulations automatisées (à l’image de l’analyse robotique de TikTok produite par le Wall Street Journal), que les plateformes ont plutôt eu tendance à bloquer en déniant les résultats obtenus sous prétexte d’incomplétude – ce qui est justement le problème que l’ouverture de données cherche à adresser.

    Le code
    L’ouverture du code des systèmes de recommandation pourrait être utile, mais elle ne suffit pas, d’abord parce que dans les systèmes de recommandation, il n’y a pas un algorithme unique. Nous sommes face à des ensembles complexes et enchevêtrés où « différents modèles d’apprentissage automatique formés sur différents ensembles de données remplissent diverses fonctions ». Même le classement ou le modèle de valeur pour déterminer le score n’explique pas tout. Ainsi, « le poids élevé sur un contenu d’un type particulier ne signifie pas nécessairement qu’un utilisateur le verra beaucoup, car l’exposition dépend de nombreux autres facteurs, notamment la quantité de ce type de contenu produite par d’autres utilisateurs. »

    Peu de plateformes offrent une grande transparence au niveau du code source. Reddit a publié en 2008 son code source, mais a cessé de le mettre à jour. En l’absence de mesures de transparence, comprendre les systèmes nécessite d’écluser le travail des journalistes, des militants et des chercheurs pour tenter d’en obtenir un aperçu toujours incomplet.

    La recherche
    Les plateformes mènent en permanence une multitude de projets de recherche internes voire externes et testent différentes approches pour leurs systèmes de recommandation. Certains des résultats finissent par être accessibles dans des revues ou des articles soumis à des conférences ou via des fuites d’informations. Quelques efforts de partenariats entre la recherche et les plateformes ont été faits, qui restent embryonnaires et ne visent pas la transparence, mais qui offrent la possibilité à des chercheurs de mener des expériences et donc permettent de répondre à des questions de nature causale, qui ne peuvent pas être résolues uniquement par l’accès aux données.

    Enfin, les audits peuvent être considérés comme un type particulier de recherche. À l’heure actuelle, il n’existe pas de bons exemples d’audits de systèmes de recommandation menés à bien. Reste que le Digital Service Act (DSA) européen autorise les audits externes, qu’ils soient lancés par l’entreprise ou dans le cadre d’une surveillance réglementaire, avec des accès élargis par rapport à ceux autorisés pour l’instant. Le DSA exige des évaluations sur le public mineur, sur la sécurité, la santé, les processus électoraux… mais ne précise ni comment ces audits doivent être réalisés ni selon quelles normes. Des méthodes spécifiques ont été avancées pour contrôler la discrimination, la polarisation et l’amplification dans les systèmes de recommandation.

    En principe, on pourrait évaluer n’importe quel préjudice par des audits. Ceux-ci visent à vérifier si « la conception et le fonctionnement d’un système de recommandation respectent les meilleures pratiques et si l’entreprise fait ce qu’elle dit qu’elle fait. S’ils sont bien réalisés, les audits pourraient offrir la plupart des avantages d’un code source ouvert et d’un accès aux données des utilisateurs, sans qu’il soit nécessaire de les rendre publics. » Reste qu’il est peu probable que les audits imposés par la surveillance réglementaire couvrent tous les domaines qui préoccupent ceux qui sont confrontés aux effets des outils de recommandations.

    Autres moteurs de transparence : la gouvernance et les calculs

    Les chercheurs concluent en soulignant qu’il existe donc une gamme d’outils à disposition, mais qu’elle manque de règles et de bonnes pratiques partagées. Face aux obligations de transparence et de contrôles qui arrivent (pour les plus gros acteurs d’abord, mais parions que demain, elles concerneront bien d’autres acteurs), les entreprises peinent à se mettre en ordre de marche pour proposer des outillages et des productions dans ces différents secteurs qui leur permettent à la fois de se mettre en conformité et de faire progresser leurs outils. Ainsi, par exemple, dans le domaine des données, documenter les jeux et les champs de données, à défaut de publier les jeux de données, pourrait déjà permettre un net progrès. Dans le domaine de la documentation, les cartes et les registres permettent également d’expliquer ce que les calculs opèrent (en documentant par exemple leurs marges d’erreurs).

    Reste que l’approche très technique que mobilisent les chercheurs oublie quelques leviers supplémentaires. Je pense notamment aux conseils de surveillance, aux conseils éthiques, aux conseils scientifiques, en passant par les organismes de contrôle indépendants, aux comités participatifs ou consultatifs d’utilisateurs… à tous les outils institutionnels, participatifs ou militants qui permettent de remettre les parties prenantes dans le contrôle des décisions que les systèmes prennent. Dans la lutte contre l’opacité des décisions, tous les leviers de gouvernance sont bons à prendre. Et ceux-ci sont de très bons moyens pour faire pression sur la transparence, comme l’expliquait très pertinemment David Robinson dans son livre Voices in the Code.

    Un autre levier me semble absent de nombre de propositions… Alors qu’on ne parle que de rendre les calculs transparents, ceux-ci sont toujours absents des discussions. Or, les règles de traitements sont souvent particulièrement efficaces pour améliorer les choses. Il me semble qu’on peut esquisser au moins deux moyens pour rendre les calculs plus transparents et responsables : la minimisation et les interdictions.

    La minimisation vise à rappeler qu’un bon calcul ne démultiplie pas nécessairement les critères pris en compte. Quand on regarde les calculs, bien souvent, on est stupéfait d’y trouver des critères qui ne devraient pas être pris en compte, qui n’ont pas de fondements autres que d’être rendus possibles par le calcul. Du risque de récidive au score de risque de fraude à la CAF, en passant par l’attribution de greffes ou aux systèmes de calculs des droits sociaux, on trouve toujours des éléments qui apprécient le calcul alors qu’ils n’ont aucune justification ou pertinence autres que d’être rendu possibles par le calcul ou les données. C’est le cas par exemple du questionnaire qui alimente le calcul de risque de récidive aux Etats-Unis, qui repose sur beaucoup de questions problématiques. Ou de celui du risque de fraude à la CAF, dont les anciennes versions au moins (on ne sait pas pour la plus récente) prenaient en compte par exemple le nombre de fois où les bénéficiaires se connectaient à leur espace en ligne (sur cette question, suivez les travaux de la Quadrature et de Changer de Cap). La minimisation, c’est aussi, comme l’explique l’ex-chercheur de chez Google, El Mahdi El Mhamdi, dans une excellente interview, limiter le nombre de paramètres pris en compte par les calculs et limiter l’hétérogénéité des données.

    L’interdiction, elle, vise à déterminer que certains croisements ne devraient pas être autorisés, par exemple, la prise en compte des primes dans les logiciels qui calculent les données d’agenda du personnel, comme semble le faire le logiciel Orion mis en place par la Sncf, ou Isabel, le logiciel RH que Bol.com utilise pour gérer la main-d’œuvre étrangère dans ses entrepôts de logistique néerlandais. Ou encore, comme le soulignait Narayan, le temps passé sur les contenus sur un réseau social par exemple, ou l’analyse de l’émotion dans les systèmes de recrutement (et ailleurs, tant cette technologie pose problème). A l’heure où tous les calculs sont possibles, il va être pertinent de rappeler que selon les secteurs, certains croisements doivent rester interdits parce qu’ils sont trop à risque pour être mobilisés dans le calcul ou que certains calculs ne peuvent être autorisés.

    Priyanjana Bengani, Jonathan Stray et Luke Thorburn, pour en revenir à eux, notent enfin que l’exigence de transparence reste formulée en termes très généraux par les autorités réglementaires. Dans des systèmes vastes et complexes, il est difficile de savoir ce que doit signifier réellement la transparence. Pour ma part, je milite pour une transparence “projective”, active, qui permette de se projeter dans les explications, c’est-à-dire de saisir ses effets et dépasser le simple caractère narratif d’une explication loyale, mais bien de pouvoir agir et reprendre la main sur les calculs.

    Coincés dans les boucles de l’amplification

    Plus récemment, les trois mêmes chercheurs, passé leur article séminal, ont continué à documenter leur réflexion. Ainsi, dans « Rendre l’amplification mesurable », ils expliquent que l’amplification est souvent bien mal définie (notamment juridiquement, ils ont consacré un article entier à la question)… mais proposent d’améliorer les propriétés permettant de la définir. Ils rappellent d’abord que l’amplification est relative, elle consiste à introduire un changement par rapport à un calcul alternatif ou précédent qui va avoir un effet sans que le comportement de l’utilisateur n’ait été, lui, modifié.

    L’amplification agit d’abord sur un contenu et nécessite de répondre à la question de savoir ce qui a été amplifié. Mais même dire que les fake news sont amplifiées n’est pas si simple, à défaut d’avoir une définition précise et commune des fake news qui nécessite de comprendre les classifications opérées. Ensuite, l’amplification se mesure par rapport à un point de référence précédent qui est rarement précisé. Enfin, quand l’amplification atteint son but, elle produit un résultat qui se voit dans les résultats liés à l’engagement (le nombre de fois où le contenu a été apprécié ou partagé) mais surtout ceux liés aux impressions (le nombre de fois où le contenu a été vu). Enfin, il faut saisir ce qui relève de l’algorithme et du comportement de l’utilisateur. Si les messages d’un parti politique reçoivent un nombre relativement important d’impressions, est-ce parce que l’algorithme est biaisé en faveur du parti politique en question ou parce que les gens ont tendance à s’engager davantage avec le contenu de ce parti ? Le problème, bien sûr, est de distinguer l’un de l’autre d’une manière claire, alors qu’une modification de l’algorithme entraîne également une modification du comportement de l’utilisateur. En fait, cela ne signifie pas que c’est impossible, mais que c’est difficile, expliquent les chercheurs. Cela nécessite un système d’évaluation de l’efficacité de l’algorithme et beaucoup de tests A/B pour comparer les effets des évolutions du calcul. Enfin, estiment-ils, il faut regarder les effets à long terme, car les changements dans le calcul prennent du temps à se diffuser et impliquent en retour des réactions des utilisateurs à ces changements, qui s’adaptent et réagissent aux transformations.

    Dans un autre article, ils reviennent sur la difficulté à caractériser l’effet bulle de filtre des médias sociaux, notamment du fait de conceptions élastiques du phénomène. S’il y a bien des boucles de rétroaction, leur ampleur est très discutée et dépend beaucoup du contexte. Ils en appellent là encore à des mesures plus précises des phénomènes. Certes, ce que l’on fait sur les réseaux sociaux influe sur ce qui est montré, mais il est plus difficile de démontrer que ce qui est montré affecte ce que l’on pense. Il est probable que les effets médiatiques des recommandations soient faibles pour la plupart des gens et la plupart du temps, mais beaucoup plus importants pour quelques individus ou sous-groupes relativement à certaines questions ou enjeux. De plus, il est probable que changer nos façons de penser ne résulte pas d’une exposition ponctuelle, mais d’une exposition à des récits et des thèmes récurrents, cumulatifs et à long terme. Enfin, si les gens ont tendance à s’intéresser davantage à l’information si elle est cohérente avec leur pensée existante, il reste à savoir si ce que l’on pense affecte ce à quoi l’on s’engage. Mais cela est plus difficile à mesurer car cela suppose de savoir ce que les gens pensent et pas seulement constater leurs comportements en ligne. En général, les études montrent plutôt que l’exposition sélective a peu d’effets. Il est probable cependant que là encore, l’exposition sélective soit faible en moyenne, mais plus forte pour certains sous-groupes de personnes en fonction des contextes, des types d’informations.

    Bref, là encore, les effets des réseaux sociaux sont difficiles à percer.

    Pour comprendre les effets de l’amplification algorithmique, peut-être faut-il aller plus avant dans la compréhension que nous avons des évolutions de celle-ci, afin de mieux saisir ce que nous voulons vraiment savoir. C’est ce que nous tenterons de faire dans la suite de cet article…

    ❌
    ❌