Skip to content

Aaron Swartz, l’enfant improgrammable d’internet

14/09/2014

Ce billet revient sur deux documents :
le film-documentaire sur Aaron Swartz, The Internet’s Own Boy, que les francophones peuvent regarder grâce à une petite équipe de dévoués de sous-titreurs ;
et un livre d’A. Swartz, inachevé, diffusé à titre posthume par son éditeur :
A Programmable Web.
D’où le titre ci-dessus. Ces deux oeuvres sont sous licence Creative Commons.

The Internet’s Own Boy

The Internet’s Own Boy retrace la vie courte d’Aaron Swartz, qui s’est suicidé à 26 ans alors qu’il était poursuivi en justice pour avoir téléchargé des millions d’articles Jstor. Outre les explications sur les circonstances de la fin de sa vie, ce film permet surtout de découvrir une figure fondatrice d’Internet, moins médiatisée (du moins il me semble) que beaucoup d’autres dont les noms nous sont bien plus familiers.

La version sous-titrée est parue en juillet, peut-être étiez-vous déjà parti en vacances. Si c’est le cas, si vous ne l’avez pas encore vue, prenez le temps de le faire : il ne sera pas perdu.

Je suppose que « figure fondatrice » est inappropriée, vue que Swartz, né en 1986, n’a pu apporter sa contribution à l’internet qu’à partir de 12 ans, en 1998, en inventant une sorte d’ancêtre de Wikipedia : une encyclopédie collaborative en ligne, invitant chaque internaute à partager ses connaissances.

La lecture de A Programmable web permet de se rappeler que le premier navigateur inventé par Tim Berner-Lee était structurellement un outil de lecture/édition des pages web : le web était conçu à l’origine comme un mode de participation permanente, même si par la suite c’est le navigateur Netscape, parti sur une autre logique et une autre technologie qui s’est imposé (A Programmable Web, p. 22-23 de la version PDF). Il a fallu plusieurs années pour revenir à un web réinscriptible.

Où l’on voit qu’à 12 ans, Aaron Swartz était déjà complètement dans une compréhension de ce qu’était et pouvait être le web.

Plutôt que fondateur, disons qu’Aaron Swartz a un rôle fondamental dans plusieurs dimensions du développement d’Internet.

J’ai été particulièrement marqué par les minutes du documentaire consacré au rejet du projet de loi SOPA. Il partait manifestement perdant, tout en continuant à lutter contre ce projet, sous diverses formes. Et il me semble que si sur ce type d’engagement ses compétences techniques lui ont permis plus facilement d’en appréhender les enjeux, celles-ci n’étaient pas indispensables.

De mon point de vue, au-delà des informations biographiques, ce documentaire interpelle fortement sur la responsabilité de chacun face aux enjeux sociaux, notamment ceux liés à Internet — puisque Internet est amené à être au cours du quotidien de tous.

Et l’exemple de SOPA nous permet de nous rappeler que non, rien n’est jamais joué, même quand on pense que c’est trop tard, ou qu’on est dépassé par des forces plus grandes de toute façon.

Tiens, par exemple en ce moment, en France, il est beaucoup question — de nouveau, et ça reviendra régulièrement tant que cette neutralité ne sera pas mise à bas — de la neutralité du Net. En témoignent cet article (partagé sur Twitter par Laure de la Raudière), ou cette infographie (avec des chats, des voitures, des sangliers et des pigeons — ça devrait parler à tout le monde) que je vous invite à partager (même si je lui préfère cet article d’avril 2014 paru sur Rue89 qui expose de manière tout aussi claire pas mal d’enjeux).

Donc Internet est encore en train de se faire (et ce sera sans doute toujours le cas), il y aura encore besoin d’acteurs pour y jouer un rôle fondamental.

Précisons que lorsque Swartz s’est mobilié contre SOPA, il n’était pas seul à défiler. L’évolution d’internet ne dépend pas que de figures qui jouent un rôle fondamental : il dépend aussi de milliers ou millions de personnes qui acceptent, ou non, de jouer un rôle de simple contributeur.

A Programmable Web

Justement, dans A Programmable Web, Aaron Swartz aborde un de ces autres chantiers sur les lesquels il faut être vigilants : la concentration du web autour de quelques plates-formes (les GAFA), cette concentration qui empêche à la longue traîne d’être opérationnelle, cette concentration qui nous permet de lire plusieurs fois par semaine des billets d’Olivier Ertzscheid, futurologue angoissant.

Aaron Swart propose d’aller vers des logiciels peer-to-peer :

Un logiciel en peer-to-peer, si on arrive à faire en sorte que ça marche, semblerait rassembler le meilleur des deux univers : la liberté de modifier le mode de fonctionnement d’un programme sur nos ordinateurs locaux aussi bien que la possibilité de partager et de collaborer avec d’autres personnes sur Internet. Et pour ceux qui se préoccupent de liberté [il dit ailleurs : les êtres humains veulent généralement être libres. Si vous ne me croyez pas, demandez à un ami de vous enfermer dans le coffre de votre voiture, puis réévaluez votre position] (comme pour ceux qui aiment partager de la musique), ça paraît être le prochain grand projet de la recherche à venir.

Si je comprends bien, il dit : « Un logiciel peer-to-peer, ce serait cool. Vous ne comprenez pas trop comment c’est censé marcher ? Moi non plus, mais l’essentiel est que vous compreniez que c’est vraiment une solution« .

Ce que je retiens de la démarche de Swartz, c’est qu’il ne faut pas faire des questions techniques un pré-requis pour s’autoriser à s’intéresser à quelque chose, et estimer que c’est important. D’ailleurs, la technique, on la développe souvent après avoir identifié qu’il y avait là une compétence importante à acquérir, pas avant. Donc le point de départ, c’est bien de comprendre les enjeux, pas la machinerie.

Plus globalement, A Programmable Web est un ouvrage assez déconcertant. La commande de l’éditeur était : une petite synthèse sur la question du web sémantique.

Et Aaron Swartz commence par dégommer les efforts du W3C en matière de normalisation – à tel point qu’on pourrait croire qu’il trouve que le web de données, RDF, tout ça, c’est vraiment n’importe quoi (le dernier chapitre semble révéler qu’en fait non, c’est plutôt quelque chose de très intéressant et très puissant #spoiler) :

Au lieu de l’attitude « Allez, on va fabriquer quelque chose qui fonctionne » qui a permis au web (et à Internet) d’avoir un tel succès, ils ont importé l’état d’esprit normatif des mathématiciens, et les structures institutionnelles des personnels universitaires et militaires. Ils ont formé commissions (committees) pour former des groupes de travail écrire des ébauches (drafts) d’ontologies qui listaient soigneusement (dans des documents Word de 100 pages) toutes les choses de l’Univers et les diverses propriétés qu’elles pouvaient avoir, et ils ont passé des heures dans des débats talmudiques pour déterminer si une machine à laver était un robot de cuisine ou un appareil de ménage.

[...]

Et c’est comme ça que le « Semantic Web Activity » du Worldwide Web Consortium (W3C) a passé son temps à rédiger des standards sur des standards : l’Extensible Markup Language (XML), le Resource Description Framework (RDF), le Web Ontology Language (OWL), les outils de Gleaning Resource Descriptions from Dialects of Languages (GRDDL), le Simple Protocol And RDF Query Language (SPARQL) [...].
Peu ont été largement utilisés, et ceux pour lesquels ce fut le cas (XML) sont devenus des fléaux pour toute la planète, une offense contre les programmeurs acharnés qui avaient produit des formats sensés (comme JSON), pour favoriser plutôt des boules de poils [?] hyper-compliquées sans aucun rapport avec la réalité.

Un peu plus loin, Aaron Swart fait une longue diatribe sur XML, mais j’en ferai un billet à part entière car je comprends mieux à présent le problème natif avec l’EAD.

Pour en revenir au web sémantique et aux technologies du Lined Data, il est vrai que tant que les développements liés à cette technologie restaient au niveau du W3C et des normes, ça ne prenait pas. Et puis il y a eu DBPedia, donc une application concrète avec une masse d’informations produites — et ça a vraiment démarré (voir la toute récente mise à jour du schéma recensant les publications de jeux de données liées, le Linked Open Data Cloud Diagram)

Ce qui précède, c’était l’introduction. Je ne vais pas vous traduire tout l’ouvrage, je vous invite plutôt à le lire (d’autant que comme c’est un brouillon, Swartz s’autorise certaines libertés savoureuses), car il remet pas mal d’idées en place. Et, ce qui est excellent, il incite parfois à protester (je n’avais pas envie d’être d’accord avec tout).

En voici donc juste quelques extraits.

Le plan est le suivant :

[Pour comprendre le web sémantique] nous allons commencer par essayer de comprendre l’architecture du web — ce qui va bien, et à l’occasion ce qui ne va pas, mais surtout pourquoi elle est ainsi. Nous verrons comment elle permet aux utilisateurs et aux moteurs de recherche de co-exister paisiblement tout en supportant n’importe quoi, du partage de photos aux transactions financières.

Nous continuerons en analysant ce que signifie élaborer un programme par dessus le web — comment écrire un logiciel qui serve correctement à la fois ses utilisateurs immédiats aussi bien que les développeurs qui veulent construire quelque chose dessus. Trop souvent, une API est conçu à l’issue du développement d’une application existante, comme une arrière-pensée ou un élément complètement indépendant.

Aaron Swartz consacre plusieurs pages à la structures de bonnes URL. Ces pages sont essentielles car nous oublions trop souvent dans notre navigation, et plus encore en s’habituant aux applis mobiles, que l’URL est la clé de voûte du web, puisque c’est elle qui donne accès aux choses (je dis aux choses, parce que jusqu’à il y a quelques années les URL donnaient surtout accès aux documents seulement, mais c’est de moins en moins vrai). Le maintien et la lisibilité des URL préserve en grande partie des enclosures du web (outre les questions juridiques de réutilisation, évidemment).

Les URLS ne doivent pas être considérées comme un effet de bord ou un question secondaire, comme beaucoup semblent le souhaiter. Designer les URLs est la part la plus importante de l’élaboration d’une application web et il faut commencer par là. La manière dont elles sont construire permet de déduire toute une série d’informations implicites sur le contenu de votre site, comment il est structuré et comment il devrait être utilisé ; toutes ces questions sont importantes et ne doivent pas être évacuées.

Aaron Swartz consacre ensuite du temps à expliquer les méthodes GET et POST de l’architecture REST. En gros, c’est la manière dont notre navigateur est capable de dialoguer avec des bases de données accessibles sur le web via des pages web (généralement des formulaires de requêtes). On est au coeur de la question du web de données, puisque celui-ci cherche à résoudre la question du décloisonnement de ces bases (puisque la structure des données stockées se perd dès lors qu’on ne les récupère qu’en HTML, non sémantique — ou si peu).

En résumé, GET est une commande lancée par un navigateur pour obtenir une ressource ; POST sert à agir sur cette ressource (à modifier l’information, par exemple).

Le chapitre 4 explique pourquoi le concepteur d’un logiciel en ligne (de type Gmail, Google Calendar ou Trello) a tout intérêt à autoriser ses utilisateurs à exporter leurs données stockées : c’est seulement ainsi qu’il convaincra les internautes qu’ils ne risquent pas de les perdre en venant les déposer chez lui.

Le chapitre 5 s’occupe des API. Et comme c’est là qu’il parle de XML et de JSON, je me le garde pour un autre billet. Surtout, Aaron Swartz (à travers l’exemple d’un catalogue de livres mis en ligne) glisse progressivement de la nécessité de mettre en place des API, à l’utilité de publier les données en RDF.

L’argument principal donné au chapitre 6 est le suivant : votre API ne pourra jamais envisager tous les types de requêtes qu’un internaute voudrait faire — et c’est là que SPARQL, interrogeant des données RDFisées, permet une bien plus grande liberté (cf. de recents exemples de requêtes tordues complexes intellectuellement créatives de requêtes, donc, ici ou ), et donc ouvrent à un plus grand potentiel votre base de données aux développeurs.

Une remarque tout de même :

RDF peut avoir toutes ces nombreuses caractéristiques sympathiques, mais il y a un gros revers : il est incomparablement plus compliqué à utiliser que JSON. Comme XML, il a son propre modèle de données, ce qui signifie qu’il faut écrire un code spécial pour transposer sa manière de voir le monde et la vôtre. Il y a des outils et des techniques pour amoindrir cela (comme mon propre outil RDFTramp [Swartz fournit en note un lien vers http://www.aaronsw.com/2002/rdftramp/, qui ne fonctionne plus], qui essaie de faire ressembler RDF à des objets Python bien plus normaux), mais ça reste un sérieux problème.

Le chapitre 7 retrace rapidement l’histoire de l’open source et du GNU Project.

La conclusion au chapitre 8 décrit un logiciel qui semble très intéressant et dont j’ignorais l’existence : CWM.

Un des outils les plus excitants du Web Sémantique est un programme appelé CWM [...]. CWM (prononcez COOM) est un des programmes les plus formidables que j’aie vus ; c’est un véritable couteau suisse des données, intégralement consacré au RDF.
Evidemment, il assure les bases — lire et écrire des fichiers RDF de différents formats, combiner plusieurs fichiers, produire des résultats dans un format soigné.
Evidemment, il peut aussi faire une recherche dans un jeu de données pour répondre à votre requête de la même manière que le fait SPARQL.
Mais CWM va un peu plus loin. Il ne se contente pas de rechercher dans les données : il réfléchit sur elle. CWM peut appliquer des règles logiques ; voici un exemple :
{?x a :Man} => {?x :mortality :mortal}
(si quelque chose est un homme, alors cette chose est mortelle.) Donnez cela à CWM, avec ce qui suit :
:Socrate a :Man.
Et il va en déduire logiquement que Socrate est mortel. De tels ensembles de règles ont évidemment toutes sortes d’usages [...]
Mais CWM peut faire beaucoup plus que des simples inférences logiques de base. Il a aussi une large variété de fonctions implémentées, qui peuvent aller de processus mathématiques à de la cryptographie avancée. Grâce à elles et à quelques règles intelligentes, vous pouvez bâtir des programmes entiers avec CWM.
Au fait, rien de tout cela n’est nouveau — presque tout le logiciel a été conçu en 2001.

Et enfin, le Tabulator :

Vous devriez essayer le dernier projet de Tim [Berner-Lee] : le Tabulator. C’est une petite extension pour votre navigateur web qui vous permet de voir les documents RDF associés aux pages web standard.

En conclusion, je pensais lire le livre avec l’espoir de me dire à la fin : « Ca, c’est fait ». J’en ressors avec beaucoup d’autres choses à faire… Et vous aussi.

Programme de contrôle automatisé des accès aux ressources en ligne

01/09/2014

Traduction d’extraits d’un article paru le 25 juillet 2014 dans Code4Lib : Getting What We Paid for: a Script to Verify Full Access to E-Resources.
Récupérer le code du programme

Elsevier - accès refuséAvec le nombre croissant de ressources en ligne dans les bibliothèques universitaires, il devient impossible de contrôler manuellement que l’accès à chacune d’entre elles a été correctement ouvert par le fournisseur. L’article en question passe un certain temps à démontrer l’intérêt d’automatiser une telle fonction. Je vous fais grâce de la traduction de cette introduction, en postulant que vous êtes tous convaincus de la chose. Et voici la traduction de quelques passages.

J’ai développé un script d’Access Checker aux ressources électroniques, un script Ruby qui automatise la vérification de l’accès à ces ressources. [...]

En 2013, la revue Code4Lib a publié un article décrivant un outil baptisé Normac, qui comprenait un access checker fonctionnant sur les mêmes principes que celui décrit ici. [...]

Les utilisateurs de cet Access Checker qui veulent vérifier l’accès à des plates-formes non encore supportées par l’outil peuvent
a)  créer leur propre version du script ; b) contribuer à l’évolution du script via Github ; ou c) me demander d’ajouter
la plate-forme souhaitée (et attendre que je trouve le temps de le faire). [...]

Sur chaque plate-forme, la page d’accès à une ressource que le lecteur peut consulter contient une mention claire de son accessibilité : une icône verte, par exemple, ou un texte disant « l’accès à ce ebook est fourni par… » ou « Texte intégral ». Cette mention d’accès diffère d’une plate-forme à l’autre — et parfois même diffère d’un package à l’autre pour un même fournisseur. La présence de cette mntion (ou le code HTML qui lui correspond) est ce que l’Access Checker contrôle. [...]

L’Access Checker est un simple script JRuby qui automatise l’accès à chaque ressource. On l’exécute en ligne de commande en mettant comme paramètres les fichiers en entrée et en sortie :

>jruby access_checker.rb urls_to_check.csv access_results.csv

L’Access Checker prend en entrée un fichier .csv qui peut contenir un certain nombre de colonnes (généralement, notamment, titre et identifiant de la ressource), et dont la dernière colonne doit impérativement être l’URL associée à ce titre. Toutes les URLs du fichier doivent concerner le même fournisseur [donc on exécute le programme pour chaque plate-forme indépendamment] [...]

Quand on ouvre le script, celui-ci affiche la liste des plates-formes supportées par l’Access Checker. Il faut indiquer quelle plate-forme on veut contrôler. Le script vérifier le code HTML qui se trouve derrière chaque URL pour y trouver les chaînes de caractères attendues spécifique à la plate-forme spécifiée. Si la chaîne de caractère est trouvée, le résultat correspondant est indiqué.

L’Access Checker peut être amélioré en ajoutant la reconnaissance d’autres plates-formes, ce qui est assez simple à faire. Une fois que vous avez le code HTML d’exemples pour 1) une ressource avec accès au texte intégral ; 2) une ressource avec accès réservé ou aucun accès ; et 3) toute autre type d’erreur rencontrée sur la plate-forme en question que le rapport doit pouvoir identifier et signaler, vous inspectez le coude HTML pour reconnaître les mentions d’accès pour chacun de ces cas. La suite est triviale.

Liste des plates-formes actuellement reconnues :

Apabi
Alexander Street Press
Duke University Press (Highwire)
Ebrary
EBSCOhost
ScienceDirect
SAGE Knowledge
SAGE Research Methods
SpringerLink
SerialsSolutions
University Press Scholarship
Wiley Online Library

Récupérer le code du programme

Je vous laisse lire le reste de l’article si vous voulez plus de précisions sur la manière dont ça fonctionne (pour éviter les risques de rejet des connexions si trop de tentatives de clics successives, etc.) et des exemples d’utilisation.

Gephi : première utilisation – spatialisation

23/07/2014

Le fichier en entrée

Pour ma part, j’utilise un fichier listant les composants de notre système d’information documentaire. Vous devriez avoir un fichier à vous, à la structure comparable, suite aux consignes de ce billet.

Extrait : liste des applications du SCD, et à chaque application j’ai indiqué les applications associées et le service qui l’administre

source-exemple

Dans la fenêtre de chargement, j’ai choisi de dire que mon graphe était non dirigé. Dans le cas contraire, la spatialisation m’aurait affiché des flèches, dont je ne veux pas ici.

L’interface

Voilà à quoi ça ressemble quand on a simplement ouvert Gephi, et chargé un fichier de données.

interface-gephi

 

4 étapes simples

1. Répartition des noeuds dans l’espace en fonction d’un algorithme

Pour la plupart des cas qui nous occupent, c’est Force Atlas ou Force Atlas 2 qui sont recommandés. Force Atlas 2 n’est que la v2 de Force Atlas, une version améliorée dans la manière de traiter les calculs.

Le principe de base, très simple, est expliqué par exemple sur cette page.

Donc vous choisissez un algorithme dans la liste déroulante, et vous réglez les paramètres

algorithme

Pour comprendre chacun des paramètres, voyez  ce diaporama p. 31 (tutoriel Gephi, en français – les diapos qui précèdent sont très intéressantes aussi).

Le paramètre le plus important est l’échelle (pour Force Atlas 2) et la force de répulsion (pour Force Atlas) : si après avoir cliqué sur bouton Exécutervous trouvez que votre nuage de noeuds est trop ramassé, il faut augmenter l’une de ces valeurs (sans avoir peur de rajouter 1, 2 ou 3 zéros à la valeur par défaut).

Pensez toujours à arrêter l’algorithme en cours : sinon, il continue de faire ses calculs pour affiner perpétuellement (même si vous ne voyez plus la différence) la spatialisation de vos données.

Désormais le nuage initial ressemble à :

après spatialisation

Etape 2. Calcul du poids de chacun des noeuds et des liens

Afin de déterminer des sacs groupes de noeuds et les dimensions de chaque noeud, on utilise la colonne de droite pour qu’à chaque noeud soit associée une valeur, calculée notamment en fonction du nombre de noeuds entrants.
Au fait, en vrai, il faudrait dire sommets, qui est la bonne traduction de node pour désigner les intersections des arêtes dans une forme géométrique. Mais je crois que je vais y renoncer et rester sur « noeuds ». Je sais, c’est mal)

Ainsi, la modularité va permettre de définir des groupes (donc sera utile lors de la partition) : la modularité calcule « le nombre de liens dans chaque groupe moins nombre de liens dans les mêmes groupes, dans un graphe où les liens auraient été redistribués de façon aléatoire. » (source)

Donc en face de « modularité » vous cliquez sur « Exécuter ». Vous validez les valeurs par défaut dans la fenêtre qui s’ouvre, ça ira très bien.

(dans certains cas, la Centralité Eigenvector – explications – peut être plus intéressante : elle ne valorise pas le nombre de liens, mais leur diversité, càd le nombre de destinataires distincts pour un noeud donné)

Etape 3. Constituer des groupes

La modularité permet de dégager des groupes (fonction Partition). Et à chaque groupe, on va attribuer une couleur spécifique.

Donc en haut à droite, onglet Partitions, cliquer sur actualiser pour actualiser la liste des critères qui permettent de partitionner les données.

Dans la liste déroulante, je choisis « Modularity Class ».

partition - liste

Et j’obtiens un certain nombre de groupes, chacun ayant une couleur spécifique.

En bas de la liste, je clique sur Appliquer

appliquer partition

Mes noeuds ont désormais des couleurs.

Mais comme ces noeuds sont tout petits, on ne les voit pas bien. Il faut donc maintenant agrandir la taille des noeuds, en tenant compte de leur importance dans le « réseau ».

Etape 4. Attribuer une taille proportionnelle à chaque noeud

C’est l’onglet Classement juste à côté.

Et dans cet onglet, il ne faut pas rater la petite icône Diamant sur la droite. Je le signale parce que j’ai mis du temps à la repérer.

classement-poids

Puis vous choisissez le paramètre de classement Degré, une taille min et une taille max : les différents noeuds vont prendre des dimensions qui iront de ce minimum à ce maximum.

Puis le bouton « Appliquer ».

classement-appliquer

Et voici le résultat :

classement-resultat

Dernière phase : afficher les noms des noeuds

Faut reconnaître que c’est quand même pratique de savoir qui est qui.

En dessous de l’image, il y a un certain nombre d’icônes permettant d’afficher ou de masquer certaines infos, et de jouer sur leur taille.

Ne pas rater la toute dernière icône complètement à droite, qui affiche plus d’options.

barre-outils

Tadaaaam !

SI documentaire

Bon, c’est pas le schéma le plus joli du monde, mais :

  • il m’a demandé peu d’efforts (quelques minutes)
  • il est quand même parlant et signifiant, et les sous-ensembles sont bien identifiés :
    • les outils de l’Abes
    • ceux de la DSI
    • ceux du Cléo
    • ceux du CCSD (même si la couleur serait à revoir)
    • et pour le Sidoc, distinction assez bonne des outils internes et des interfaces publiques

Calames IT ?

21/07/2014

« IT » pour « Instrument de travail », bien sûr.

logo CalamesPréambule

Ce billet vient à la suite d’une d’une discussion sur Twitter avec le responsable du réseau Calames alimentant le compte Calames de l’Abes.

Manifestement, des choses m’échappent (non, ce n’est pas ironique), et si je mets ici l’état de mes réflexions (qui en fait n’est qu’un avis personnel, mal informé de surcroît), ce n’est pas pour en faire une tribune, mais simplement pour prolonger l’échange : les 140 caractères de Twitter sont rapidement frustrants pour développer des argumentaires sur ce genre de dossier.

Donc j’expose ce que je comprends de la situation, à partir de quoi j’alimente ma réflexion sur ce dossier. L’objectif étant d’être contredit par des personnes mieux informées, venant apporter des infos complémentaires me permettant de comprendre pourquoi je n’avais rien compris.

Court rappel : l’EAD

eadL’EAD est un format XML inspiré de la TEI (autre format XML), développé pour permettre de structurer de l’information textuelle permettant de décrire toutes les informations nécessaires à un inventaire d’archives.

L’EAD est conforme à l’ISAD(G), norme de description des archives : cela signifie que l’ISAD(G) explique le type d’informations que doit contenir un inventaire d’archive. Et l’EAD fournit un ensemble de balises permettant de répondre à ces consignes.

L’EAD est apparu lorsque des services d’archives ont voulu mettre en ligne les inventaires d’archives jusque-là au format papier : cette transposition de la version papier vers une version en ligne ne se satisfaisait pas d’un PDF ou d’un fichier HTML : ces deux formats faisaient perdre toute la sémantisation des informations (si cette notion n’est pas claire, je peux préciser en commentaires).

Les archivistes ont donc récupéré la TEI, qui existait déjà pour baliser du texte en XML, pour l’adapter à leurs besoins spécifiques (concepts particuliers, qui devinrent des balises particulières).

Un éditeur EAD ?

Et donc, il y a ce projet, mentionné aux JABES 2014, évoqué dans l’édito d’Arabesques 73 : le projet de développer un outil national de saisie en EAD, en partenariat avec la BnF, qui est aussi intéressée pour ses propres projets d’archives et manuscrits.

Le constat est (je suppose) le suivant : pour l’instant, quand on veut faire un inventaire en EAD, on a le choix entre saisir du texte XML au kilomètre dans un éditeur XML, ou avoir un espace de masque de saisie très contraignant, où de toute façon les balises sont des balises et les attributs des attributs. Bref, il y a une petite aide sur le temps de saisie, mais ça reste assez pas top. Le projet consisterait donc (je suppose encore) à développer un masque de saisie pour l’EAD, comme peut le faire XMLMind XML Editor adapté à l’EAD (comme quoi Calames n’est pas le seul à écrire en EAD), avec la gestion de listes d’autorités — le tout en mode connecté à une base de données comme c’est le cas pour l’éditeur actuel.

En plus, concernant Calames en tout cas, le logiciel utilisé est propriétaire — et vu que les besoins sont nationaux, pourquoi ne pas envisager de développer une solution plus satisfaisante (et pourquoi pas open source ? j’ignore si c’est dans la feuille de route).

J’avoue que j’ai sursauté en apprenant l’apparition de ce projet. Mais c’est sans doute dû à mon propre parcours et la compréhension que j’ai développée de tout ça. Donc je vais prendre le temps d’expliquer le pourquoi de ma surprise.

Mon EAD à moi

Quand je me suis intéressé à l’EAD, c’était à l’Ecole des chartes. Pour ma thèse, j’avais des centaines de lignes Excel de description de monnaies médiévales dans un tableau interminable, et mon projet était le suivant : trouver la bonne manière de mettre en ligne ce qui était un tableur, mais qui pouvait devenir de la base de données.

Un inventaire de monnaies est toujours organisé en séries, avec une approche arborescente très comparable à ce qu’on trouve dans les fonds d’archives : en ce sens, l’EAD est bien plus adapté pour les décrire sous forme de « collections » que les notices Marc, qui par nature sont isolées les unes des autres.

Et vu ma situation de départ, je n’ai pas envisagé une seule seconde de saisir ces descriptions de monnaies en EAD :  le texte existait déjà, il ne s’agissait que de trouver la bonne manière de le convertir en EAD. Bref, de générer de l’EAD, pas de l’éditer.

D’où par exemple ce billet de 2007, sur la conversion d’Excel vers EAD (avec méthode pour regrouper les séries à partir de descriptions sous forme de notices).

L’EAD, c’est du XML

Mais au-delà de mon cas particulier, j’ai toujours entendu que XML n’était pas fait pour être saisi à la main : le XML est un format de manipulation de données. Il est très pratique, il est lisible en clair quand on l’ouvre dans un simple éditeur de texte, mais il est extrêmement verbeux.

En un sens, JSON serait plus adapté que XML si on a prévu de saisir les données au kilomètre.

Contrairement à ce qu’on pourrait être tenté de croire, l’EAD ne doit pas être mis en parallèle avec les formats MARC. MARC est un format beaucoup plus économe, conçu précisément comme étant un masque de saisie (200$a est plus simple à écrire que « Titre de forme », eh oui !). Ce n’est pas le cas de <unittitle></unittitle>.

Ensuite, je rappelle ce que j’ai écrit au début : l’EAD est venu comme outil à disposition des archivistes comme équivalent des inventaires d’archives publiés.

Dans une chaîne de publication, le XML est un outil extrêmement puissant : outre les capacités d’indexation sémantique grâce au choix de balises signifiantes (une balise de date, de lieu géographique, etc.), le XML permet de produire en sortie toutes sortes de formats : ainsi Revues.org stocke ses articles en TEI, pour les proposer des formats de lecture HTML, ePub et PDF. Et je ne parle pas des tables des matières et autres outils de navigation rendus possibles par le fait qu’un texte soit encodé en XML, et non en HTML par exemple.

Mais dans la chaîne de production de Revues.org, les auteurs de saisissent pas de la TEI. Celle-ci est produite grâce à un module de conversion (OpenText).

Bref, pour moi comme pour d’autres, le XML est un conçu comme un format intermédiaire qui vient s’insérer entre les formats de rédaction (Word, LateX, etc.) et les formats de diffusion (HTML, ePub, PDF, SMS).

D’où notamment mon billet L’EAD, c’est pour l’import-export.

L’EAD chez les archivistes

J’ai eu l’occasion d’utiliser deux outils du monde des archives utilisant l’EAD : Pleade et le portail européen des archives.

Dans ces deux cas, l’EAD est un format d’import. Ces 2 outils sont des plates-formes de diffusion d’inventaires en ligne, et non de saisie de ces inventaires.

Calames peut être mis en parallèle avec le portail européen : comme outil partagé pour le signalement. Mais le portail européen des archives s’adresse à des établissements ayant déjà des outils de production d’EAD (logiquement, même si pas toujours vrai), et n’envisage donc pas de proposer une interface de saisie.

Ils ne prennent pas en charge le mode de production du fichier EAD qui y est injecté. Et je ne connais (mais, je le répète, ma connaissance est très limitée) que Calames pour essayer d’assurer l’ensemble de la chaîne.

Je signale au passage que certains archivistes veulent que leur outil de gestion d’archives soit nativement en EAD (les expressions varient, mais c’est l’idée globale : que les infos sur leurs archives, stockées dans l’outil en question, soient en EAD). Ça n’a pas d’intérêt et ça ne veut rien dire.
L’EAD est un format de production d’inventaire. L’inventaire n’est qu’un objet de publication.  Ce qui est important, c’est que cet outil de gestion soit capable de produire de l’EAD (et éventuellement d’en ingurgiter : mais il faudrait voir d’abord s’il arrive souvent à un service d’archives de recevoir un fonds avec son fichier EAD attaché, en ayant comme mission de gérer ce fonds).

Court rappel : l’origine de Calames

J’ai pris le temps d’expliquer la genèse de mon propre positionnement.

L’honnêteté intellectuelle me contraint de dire que le besoin de manipuler (au sens : traiter à la main) les inventaires de Calames vient de son origine et n’a rien d’absurde : Calames naît de la conversion de Palme et du Catalogue général des manuscrits pour une mise en ligne via le format de  publication EAD. Ces origines sont rappelées dans la version finale du bilan de 6 années d’existence de Calames, mis en ligne le 17 juillet sur le site de l’Abes.

Évidemment, la conversion EAD de ces deux sources n’a pas produit un résultat parfait : il était donc nécessaire de reprendre ces données à la main, pour les corriger et les améliorer. Et pour que ça « prenne » auprès des établissements, il aurait été peu convaincant de leur dire : voici vos fichiers XML, maintenant corrigez-les.

Le besoin d’une interface facilitatrice (c’est la raison d’être d’une interface !), commune, est naturel. Et c’est vrai que les services d’archives qui produisent de l’EAD ne se sont jamais retrouvés dans une telle situation.

L’interface de catalogage : un problème à résoudre

Là où je ne peux qu’être d’accord avec l’Abes et la BnF, c’est que la situation actuelle est insatisfaisante. Les conditions dans lesquelles les collègues en bibliothèque décrivent leurs fonds d’archives sont contraignantes.

Mais pour moi, la solution que le projet prétend apporter (améliorer l’interface de saisie) est pourrie, car elle ne répond pas à un problème plus large.

Le problème plus large, c’est que dans ces établissements qui interviennent dans Calames, il n’y a pas d’outil de gestion des fonds d’archives et de manuscrits.

En disant cela, je fais peut-être une énorme erreur en croyant que ce qui existe dans mon SCD est vrai pour tout le monde. S’il vous plaît, rectifiez-moi et fournissez-moi des données chiffrées sur le nombre de BU qui ont mis en place un outil de gestion de leurs fonds d’archives.

Quoi qu’il en soit, ce que je constate dans mon SCD, c’est que si on veut avoir un outil de suivi des fonds à restaurer, ou des statistiques sur la consultation de ces fonds, ou la date du dernier inventaire (au sens de « récolement ») — 3 exemples de ce que permet généralement un « outil de gestion » — je n’ai rien. Eventuellement, je pourrai grapiller dans quelques tableaux Excel des informations éparses. Ce n’est pas là un « outil de gestion ».

Bref, on ne retrouve pas avec Calames l’articulation qu’on peut avoir pour le Sudoc entre un outil de signalement national, et des outils de gestion locaux.

Calames-et-rien

Prenons le problème par un autre bout : il est essentiel que les SCD se dotent de progiciels pour gérer leurs fonds d’archives et de manuscrits (et j’espère que le réseau Aurore ne me contredira pas !).

Car évidemment, ce n’est pas à l’Abes de fournir aux établissements ces outils de gestions de fonds d’archives et de manuscrits : ce sont des besoins locaux qui doivent relever des objectifs de chaque établissement.

Dans cette perspective, le projet d’améliorer l’interface de saisie en EAD de Calames est contreproductif) :

  1. côté établissements, ça permet aux responsables du signalement de ces fonds de moins souffrir, donc ça donne l’apparence qu’avoir un outil de gestion n’est peut-être pas si nécessaire que ça
  2. côté Abes (et BnF), ça oriente la charge de travail de l’équipe Calames vers l’interface de saisie, au lieu de travailler sur les modalités d’import (automatisés !) de données qui seraient exportées des systèmes locaux.

Ce même bilan de 6 ans de Calames contient son propre schéma, très intéressant, p. 13 (mais c’est moi qui ai entouré en rouge) :

import EAD dans Calames

Ce mode de fonctionnement existe déjà. Mineur, vraisemblablement.

Mais je regrette que les efforts se focalisent sur le catalogage natif, et que rien à ma connaissance (?) ne soit envisagé pour développer, favoriser, encourager les établissements à adopter des outils de gestion d’archives, en leur fournissant par exemple des éléments de cahier des charges concernant l’articulation à prévoir avec Calames.

La piste est évoquée (ce n’est pas rien, ce n’est pas beaucoup), p. 12-13 — et notamment la question du rôle du SGBM dans tout ça :

extrait Calames

Mais si Calames évoque le SGBM, je ne me souviens pas avoir vu le projet SGBM évoqué Calames. Est-ce le cas ?

Autres perspectives

Un risque serait de considérer le fichier EAD comme source d’information de référence, sur laquelle les responsables des fonds viendraient greffer des informations de gestion.

Je ne sais pas trop à quoi ça pourrait ressembler, du reste.

Ce que je veux dire, c’est que si on voulait aller vers une situation où la double saisie serait évitée, il me semblerait risqué de vouloir choisir l’information stockée dans Calames comme l’info de base, avec d’autres infos complémentaires (non redondantes) qui viendraient l’exploiter.

En effet, encore une fois, l’EAD est conçu comme un format visant à la mise en ligne d’inventaires d’archives. Les inventaires d’archives ne sont que des produits du travail courant des archivistes. Ils ne rendent pas compte de ce qu’est une archive.

Il me semble que le point de départ, là où l’information sera vraiment créée, devra s’appuyer (à terme…) sur le modèle conceptuel de description archivistique en cours d’élaboration. Ce modèle permettra de créer des environnements de saisie et de gestion. Et les outils qui mettront à disposition ces environnement seront en mesure d’exporter en EAD les données décrites.

Vous noterez que le sens serait inverse de celui du Sudoc : c’est logique ici puisque le partage des notices bibliographiques n’a pas d’intérêt. En revanche les environnement de saisie (outils de gestion) doivent impérativement être capables de se se connecter aux référentiels comme IdRef pour alimenter les descriptions des fonds.

Si on pousse la logique un peu plus loin, il me semble que Calames n’est pas un outil de mise en ligne d’inventaire (tel que l’EAD était envisagé). On peut certes y naviguer dans les fonds (et c’est important, car la présence d’un document au sein d’un fonds est porteur de sens) — mais à l’usage Calames est avant tout un outil de recherche mutualisé, plus qu’un outil de publication électronique d’un certain type de documents, des inventaires d’archives.

Ce n’est donc pas vraiment parce que l’EAD est parfaitement structuré pour satisfaire aux besoins de navigation et de recherche que ce format a été adopté : l’EAD s’est imposé parce que c’est un format bien répandu, comme un standard.

Et plus exactement, en l’occurence, comme un standard d’échange, en fait.

D’où mon billet sur l’import-export : l’EAD est pertinent pour Calames (comme format en entrée) parce qu’il existe par ailleurs des outils pour produire cet EAD.
Ici, l’EAD est donc un format intermédiaire entre deux applications.

En ce sens, plutôt que de le comparer à MARC, on pourrait le comparer à de l’iso2709.

Conclusion

En prenant le temps d’y réfléchir, je trouve dommage que le SGBm, puisqu’il est censé prendre en considération tous types de ressources que les bibliothèques doivent gérer, n’ait pas — à ma connaissance — été saisi comme une opportunité pour mettre à disposition des établissements un outil de gestion de leurs fonds d’archives et de manuscrits.

Sur Twitter, certains tweets de J.-M. Feurtet m’ont permis de réaliser que certains aspects du problème m’étaient inconnus.

Par exemple, un tel circuit, fonctionnant sur des exports (modèle du portail européen des archives, même si dans ce cas-là il n’y a pas d’automatisation avec logiciels des services qui l’alimentent), ne permettrait plus de continuer à suivre les bonnes pratiques de l’EAD en bibliothèque. Je reconnais ne pas connaître ces bonnes pratiques. Mais je ne vois pas en quoi des spécifications à l’export ne pourraient les mettre en application. D’autant que les archives aussi ont des « bonnes pratiques ».

Bref, j’invite chaleureusement aux explications pédagogiques :-)

Quant à moi, je vais aller lire cette étude sur Calames, qui vient d’être mise en ligne.

http://bibliotheques.wordpress.com/2013/10/07/lead-cest-pour-limport-export/

http://bibliotheques.wordpress.com/2013/10/07/lead-cest-pour-limport-export/

Gephi : première utilisation – données (simples) en entrée

18/07/2014

Première chose à faire : munissez-vous d’un fichier CSV à 2 colonnes.

Pour la première fois (et les quelques suivantes), on ne va pas s’embarrasser de questions complexes sur le format des données en entrée.

Donc le plus simple, c’est d’avoir un fichier CSV à 2 colonnes. Pour les valeurs qui contiennent un espace, il faut mettre l’ensemble entre guillemets.

J’ai déjà donné quelques exemples de telles données dans le cadre d’une bibliothèque :

  • description du système d’information
    Le fichier contient alors l’ensemble des applications, et les liens entre elles.
    Si le SIGB est lié à l’annuaire LDAP de l’université (pour le chargement des lecteurs), au CAS (pour l’authentification), à un opac (logiciel spécifique), le fichier contiendra :

    SIGB;"annuaire LDAP"
    SIGB;CAS
    SIGB;opac
  • Liste des prêts pour chaque bibliothèque
    La spatialisation des prêts peut se faire avec plusieurs types de données en entrée.
    Il faut éviter les données trop diverses, trop éparses : donc éviter les identifiants (CB exemplaires, CB lecteurs), et plutôt constituer des populations si c’est possible.
    Exemple : pour chaque prêt enregistré par un chercheur, mettre côte à côte :

    Bibliothèque;"Laboratoire du chercheur"

    Ça permettra ensuite de visualiser la proximité entre tel labo et les collections d’une BU
    Autre possibilité : si vous faites du prêt multisites, mettre côte à côte

    "Bibliothèque de l'exemplaire";"Bibliothèque qui enregistre le retour du prêt"
  • Visualisation les collections
    Par exemple pour visualiser les tranches de cotes communes à plusieurs sites :

    "Bibliothèque";"Tranche de cote"

    Ca permet de voir les recoupements entre les différents sites, par tranche de cote.
    Il faut bien mettre une ligne par exemplaire (et non par tranche de cote différente) : le nombre de lignes identiques vient renforcer le lien entre les 2 entités mises en relation.

On pourrait penser à toutes sortes d’autres données

Ainsi, j’ai récupéré il y a quelques jours une liste de questions arrivées dans notre service de questions-réponses. Pour chaque question, je n’ai gardé que :

  • le niveau de l’internaute (Licence/Master/etc.)
  • le type de question (recherche bib/infos pratiques/etc.)
    Ca permettait de voir que (je simplifie) les L posent surtout des questions sur les infos pratiques ; que les M nous interpellent sur les problèmes de compte lecteur (ou autres services du même genre) et pour des recherches bibliographiques ; et les D et enseignants-chercheurs utilisent ce service quand ils ont des problèmes d’accès aux ressources en ligne.

On pourrait penser à toutes sortes de données relatives aux collections, aux lecteurs, aux services. Je suis sûr que des logs de connexion au reverse-proxy (si bien renseignées) nous en apprendraient beaucoup.

Bon, je vous laisse trouver un fichier de ce genre, et je vais préparer le billet suivant, qui va consister à charger le fichier dans Gephi.

4 manipulations prévues :

  1. obtenir une spatialisation « parlante » des données en entrée (organisation des objets ans l’espace), avec des écarts pertinents entre les différentes entités décrites
  2. calculer le poids (l’importance) des différents noeuds et liens
  3. générer un regroupement de certaines entités qui se verront ainsi attribuer une couleur commune
  4. obtenir que les entités apparaissent plus ou moins grosses, en fonction de leur importance dans les données en entrée (donc en fonction de l’étape 2)

Bref, un truc qui ressemble à ça :

sidoc

Et c’est promis, par la suite on verra d’autres fichiers plus complexes que les CSV. Mais ça permet de faire déjà pas mal de choses. Et comme pour ma part je vois passer chaque jour des fichiers contenant des colonnes, tels qu’il serait intéressant de les spatialiser, je me dis que c’est de la matière brute que vous avec forcément sous la main vous aussi. Alors que des fichiers GEXF, il faut un petit peu les chercher !

Mais que fait Gephi ?

03/07/2014

Suite au précédent billet, je comptais vraiment commencer à faire de petits exercices pratiques sur Gephi.

Mais au vu des premières utilisations, je me dis qu’il peut être utile d’expliquer le principe sous-jacent de l’outil.

La spatialisation des données, vous vous en doutez, n’est pas un truc un peu magique dans lequel on balance un ensemble d’information, et il en ressort un beau graphique bien parlant.

J’utilise le terme de « spatialisation » des données, sans doute impropre (en tout cas le sens dans lequel je l’emploie n’est pas – encore – référencé par Wikipedia). « Visualisation des données » est trop large (il y a plein de manières de faire de la visualisation des données, que Gephi ne prend pas en charge).

Dans Gephi, les données en entrée doivent être des concepts liés entre eux par paires. Ces concepts peuvent avoir un certain nombre d’attributs, et les liens peuvent également être qualifiés.

Sur la base de ces données, Gephi calcule la distance entre chaque paire de points.

Un lien vaut 1 ?

Mon premier cas d’exercice sur Gephi était la cartographie de notre système d’information documentaire : un ensemble de logiciels liés entre eux, et liés aux services qui les administrent.

En entrée, j’avais des données comme celles-ci, non qualifiées :

  • Aleph – Sidoc (pour moi, ça veut dire : Aleph administré par le Sidoc)
  • Aleph – Primo (ce qui signifie : Aleph alimente Primo)
  • Primo – Sidoc (Primo administré par le Sidoc)
  • Annuaire – Aleph (l’annuaire alimente Aleph)
  • Annuaire – DSI (annuaire administré par la DSI)
  • Harpège – Annuaire (Harpège alimente l’annuaire)
  • HAL-Unice – Primo
  • HAL – HAL-Unice
  • HAL – CCSD
  • etc.

On peut estimer qu’il y a une distance de 1 entre Aleph et le Sidoc. Il y a une distance 1 entre Primo et Aleph, et entre Primo et le Sidoc.

Mais quelle est la distance entre Aleph et HAL-Unice (2 sources alimentant Primo, administrées par 2 services distincts) ? Aucune n’est explicitée dans les données sources. Pourtant la spatialisation des données va donner à voir une distance entre ces deux outils.

Du point de vue mathématique, l’ensemble des données construit un univers à n dimensions, ou n correspond au nombre de liens (ou au nombre de concepts, ou au nombre de liens-1, enfin bref, n est bien supérieur à 2 ou 3).

Gephi calcule les distances entre chacun des concepts (qu’il appelle des noeuds) en fonction des relations exprimées (qu’il appelle des liens). Dans un monde normal, certaines de ces distances sont incompatibles entre elles.

Ensuite, Gephi essaie d’en rendre compte dans un espace en 2 dimensions, de la manière la plus satisfaisante possible. C’est-à-dire qu’il n’y a pas de manière neutre de le faire.

Normal : ce sont des algorithmes qui s’en chargent, et les algorithmes ne sont jamais neutres.

Pondérations et regroupements

Une des grandes forces de Gephi, c’est de ne pas juste spatialiser les données. « Juste spatialiser les données », çavoudrait dire donner à voir qu’il y a des noeuds et des liens.

C’est ce qui se passe quand on charge initialement un fichier : Gephi sort un machin tout moche.

gephi - graphe brut

Ensuite, Gephi est capable de faire 2 choses essentielles :

  • il identifie des groupes, sur la base des proximités déduites du fichier en entrée
  • il détermine quels noeuds sont plus importants que d’autres

Ces 2 opérations sont avant tout mathématiques. Leur rendu visuel n’arrive que dans un second temps. Ça signifie qu’avant de choisir des codes couleurs, il faut demander à Gephi d’opérer les calculs nécessaires pour les regroupements, et pour les pondérations. Gephi va donc enrichir les données de données nouvelles, calculées par lui sur la base de modèles mathématiques.

Là encore, rien n’est neutre et c’est de la responsabilité de l’utilisateur de savoir quel est le sens des algorithmes complexes qui tournent derrière.

Un exemple pour la pondération : imaginons une population de 100 individus reliés entre eux (mettons qu’on a recensé leurs échanges de mail : 1 mail = 1 lien).
Dans ces 100 individus, l’un a 60 liens avec 30 individus (il a échangé en moyenne 2 mails par personne destinatrice) ;un autre a 50 liens avec 40 individus.
Si on cherche à identifier les individus les plus actifs ou les plus influents, on valorisera tantôt le nombre de liens concernant un individu, tantôt la diversité de ses contacts, qui rend d’une certaine manière compte de l’étendue de son influence au sein du réseau.

Rapide exemple d’application en bibliothèque

Gephi est « vendu » pour être particulièrement adapté à l’étude des réseaux (un compte Twitter, un compte Facebook, un site web, etc.).

Mais en réalité de très nombreuses choses peuvent se concevoir comme des réseaux.

Je donnais ci-dessus l’exemple du système d’information documentaire.

Mais voici autre chose :

GraphePrêtsLes données analysées sont les suivantes : pour chaque prêt de janvier à avril, j’ai récupéré le nom de la BU et le nom du diplôme de l’étudiant (donc une ligne par prêt — 55.000 au total).

J’obtiens ainsi un positionnement des BU les unes par rapport aux autres, avec affichage de leur proximité ou éloignement en fonction des prêts : chaque fois qu’un lecteur emprunte dans 2 BU sur la période étudiée, ça les rapproche.

Je peux ainsi identifier des cursus qui sont à la frontière de telle ou telle bibliothèque, ou qui utilisent une particulièrement grande diversité de lieux. Je peux aussi lutter contre l’isolement de l’une des bibliothèques, ou au contraire en prendre acte.

Je reconnais que c’est encore très rudimentaire, mais ça donne des idées sur ce que peut être un « réseau » : une population (de tout et n’importe quoi) dont les membres ont des liens entre eux.

Un corpus d’œuvres d’art pourrait être étudié de la même manière. Les liens entre elles ne seraient pas seulement l’auteur, la période chronologique ou la région d’origine, mais aussi, par exemple, les caractéristiques iconographiques : bref, tout ce qu’elles peuvent avoir en commun les lie entre elles.

Bon, je pense que pour la prochaine fois, c’est promis, je vous en dirai un peu plus sur le mode d’emploi.

Méthodologie de projet : inscrire l’évolution des pratiques et procédures dans la feuille de route

24/06/2014
Merci à @marinik de m'avoir fait découvrir cette magnifique affiche

Merci à @marinik de m’avoir fait découvrir cette magnifique affiche

 

J’avais lu cet article en mars dernier, et je l’avais trouvé intéressant.

Et plus le temps passe, plus je suis confronté à des situations où j’aimerais tellement que toutes les personnes présentes l’aient lu aussi.

Donc je le mets sur ce blog pour le re-diffuser, et pour l’archiver (être sûr de le retrouver sans problème désormais, au lieu d’avoir à me demander avec quel tag j’ai bien pu l’indexer dans Diigo).

L’article initie sa réflexion à partir du renoncement par le gouvernement, du projet d’une solution de logiciel unique pour les paies des fonctionnaires (l’Opérateur national de paie, ou ONP).

L’auteur fait la démonstration suivante : quand on change d’outil, on attend de celui-ci qu’il vienne épouser les pratiques actuelles, en améliorant les processus (petites économies à chaque étape). Alors que l’administration qui le met en place devrait réfléchir à l’évolution de ses circuits pour optimiser au mieux l’outil adopté.

Extrait :

S’il ne s’agit que d’optimiser une organisation existante sans la transformer, alors le système d’information va devoir intégrer toutes les spécificités de l’organisation qu’il irrigue. Cette personnalisation des développements coûte très cher : dans cette configuration, le client n’achète pas une solution logicielle, il achète essentiellement l’assistance à maîtrise d’ouvrage pour rédiger les spécifications puis de coûteuses prestations de maîtrise d’œuvre pour pratiquer tous les développements spécifiques.

 

Il insiste sur l’importance du rôle de la gouvernance pour imposer une transformation de l’organisation interne, au lieu d’une adaptation la moins « douloureuse » possible.

Ces réflexions me font penser à un certain nombre de projets passés, ainsi qu’à ceux qui m’attendent dans les mois et les années à venir.

De manière générale, cette remise en perspective devrait nous poser question pour tout projet logiciel porté (ou subi, éventuellement) par l’établissement, et envisager d’annoncer d’entrée de jeu que parmi les objectifs de la mise en place d’un nouvel outil, il y aura le questionnement de l’organisation actuelle, pour la faire évoluer de manière à optimiser l’outil lui-même.
Non pas parce que l’outil est en soi contraignant ou méchant, mais parce que c’est sain dans le principe même de la conduite de projet.

Le présenter comme un principe méthodologique de base est peut-être une manière de faire passer les changements plus facilement (ils sont plus « légitimes » puisqu’ils ne sont pas « choisis » par le porteur du projet mais sont inhérents au principe du changement d’outil).

Numérique et administration : l’effondrement des cathédrales, par Nicolas Colin

Suivre

Recevez les nouvelles publications par mail.

Rejoignez 114 autres abonnés