Découvrez Le Bibliothécaire Innovant, la newsletter thématique gratuite d'Archimag dédiée aux professionnels des bibliothèques et de la conservation !
Depuis quelques mois, il est possible de prendre un fichier Excel issu d’une base de données, de le copier sur son ordinateur, puis d’envoyer un e-mail au dit PC afin de lui demander de trouver un moyen de transformer ce fichier en base de donnée dynamique, de le rendre disponible sur internet et de créer une page web permettant d’interroger la base de données et d’y écrire.
Comptez une petite dizaine de minutes à compter de l’envoi de l’e-mail et quelques centimes de coût d’intelligence artificielle, votre agent s’occupera du reste : "Congratulations !", vous avez créé votre premier SIGB.
Quelques échanges de plus et vous pourrez ajouter des utilisateurs avec différents niveaux de privilèges, une plus jolie interface, le rapatriement des notices de la BnF (que l’on remercie pour son API gratuite) ou encore un petit bot chargé de créer des bibliographies.
J’ai réalisé cette expérience il y a quelques mois, à peu près au moment où les cotations boursières des principaux éditeurs de logiciels subissaient un mini-krach : la modique somme de deux-mille-milliards de dollars s’évaporant dans ce que l’on a ensuite appelé "SaaSpocalypse" (SaaS comme Software as a Service). Bref, des logiciels par abonnements. Gageons que les éditeurs de nos logiciels professionnels savent de quoi il est ici question.
Lire aussi : En 2025, le marché des logiciels pour bibliothèques en stagnation
Pourquoi on paye pour un logiciel
Ces sociétés existent pour une raison simple : personne (ou presque) ne sait se servir d’un ordinateur et n’a envie d’apprendre à coder pour savoir quelle requête envoyer à quel serveur afin de rapatrier tel paquet de données pour les faire ensuite traiter par tel autre service externe afin d’ajouter une information X à une notice Y.
On paye donc pour un logiciel qui fait cela avec des interfaces graphiques : une série de boutons, de champs, de sliders, de menus déroulants et autres cases à cocher qui, une fois validés, envoient une requête préformatée au serveur susmentionné. Et c’est très pratique : le logiciel permet également d’obliger à passer par des workflows précis, cadre les requêtes au sein des contraintes diverses (normes, interopérabilités, etc.) ou permet également de se reposer sur des équipes compétentes ayant pensé avant vous à ce dont vous auriez besoin ensuite.
La contrepartie de cette situation est que vous dépendez justement de ce à quoi on a pensé avant vous et que vous devez partager avec (parfois) des centaines d’autres établissements : telle fonctionnalité, dont vous avez cruellement besoin, n’intéresse peut-être en fait personne d’autre, et il y a fort peu de chances qu’une entreprise y consacre du temps de développement. Parallèlement, cette autre fonctionnalité vous empoisonne la vie en vous obligeant à des étapes inutiles.
Vous devez, de plus, vous former à chaque évolution du logiciel. Les mises à jour sont autant de possibilités de rater un sous-menu… Vous avez probablement un certain nombre de tickets ouverts chez votre support afin de vous aider à retrouver comment sortir les statistiques qui vous intéressent… Et je ne parle même pas du jour où, ayant changé de fournisseur, vous allez devoir tout réapprendre. Et sans doute rebâtir à la main tout ce qui n’aura pas pu être exporté de votre ancienne base vers la nouvelle, car le second (et vraisemblablement très bon) logiciel n’intègre pas tel champs, telle option, telle possibilité et que vous comprenez bien qu’il n’est pas possible de demander à un développeur de passer une semaine dessus.
Lire aussi : IA génératives en bibliothèque : 15 cas d’usage à tester pour gagner du temps
Peut-on coder son propre SIGB ?
Mais alors, serait-il raisonnable - comme décrit plus haut - de coder soi-même son SIGB ? Cette éventualité est-elle aujourd’hui viable ? D’aucuns appellent ce genre de développement du "vibe coding" : demandez à un bot de vous écrire du code, voyez ce qui sort et itérez jusqu’à arriver à un résultat satisfaisant. Jusqu’il y a environ six mois, le résultat était en général potable, mais clairement pas utilisable en milieu professionnel. Depuis, la question mérite qu’on se la pose.
Des opérateurs existent pour cela, leur principal argument étant le prix. Dans l’univers du SaaS, le "vrai" coût est humain : lorsque vous payez un logiciel, vous assurez à l’équipe qui est derrière un salaire (c’est environ 80 % de ce que vous versez) et un peu de calcul et de stockage (les 20 % qui restent). En arrivant à se passer des humains tout en proposant un environnement sécurisé et juridiquement aux normes, le service devient alors aussi compétitif que les IA qui y travaillent sont performantes. Et leurs compétences augmentent vite, très vite… D’où le SaaSpocalypse.
Alors, nos grands éditeurs vont-ils disparaître ? Clairement non : les institutions concernées ne sont pas exactement connues pour leur tendance à prendre des risques et on ne verra pas de sitôt une collectivité risquer de perdre une base de données ou de se retrouver exposée. En revanche, pour gérer un petit fonds aux particularismes mal adaptés aux grands logiciels ou pour le mettre juste en ligne sur un petit site à part, sans budget, cela se discute.
Lire aussi : Cloudification, IA, transition bibliographique... Où en est le SIGB de demain ?
Une autre voie existe déjà
Un autre chemin est possible : une voie où devenir acteur de son propre logiciel est conçu dès le développement. Autant dire qu’ici, tout est à inventer ou à tester : accès à un bac à sable, ajout de la création de clés API directement par les utilisateurs (et gestion des coûts serveurs potentiellement liés), possibilité de partager une fonctionnalité que l’on vient d’imaginer, voire intégration directe d’un bot au sein même du logiciel.
Allons plus loin : si ledit bot a accès au code du logiciel et peut le modifier (et prendre ainsi le statut d’agent), pourquoi ne pas lui donner aussi les clés de la base qui lui est liée ? Ainsi, plutôt que de créer le bouton manquant, on lui donnerait juste l’ordre d’aller réaliser la requête directement au serveur, ce qui permet aussi d’ailleurs de réduire drastiquement la nécessité de développer l’ensemble des fonctionnalités décrites plus haut et qui ne servent pas tous les jours.
Science-fiction, vous pensez ? Peut-être pas… Et vous seriez sûrement surpris d’apprendre qu’il existe déjà des moyens de le faire et à un coût très bas (comptez une quarantaine d’euros par mois, la moitié une fois que votre architecture est bien en place et bien documentée). Je le sais, car je l’ai fait. Et il y a quelque chose de magique (et d’un peu effrayant) à voir votre interface aller chercher une clé API à la BnF dans son environnement, interroger la base, vérifier qu’elle ne trouve pas ce qu’elle veut et aller fouiller Wikipédia et des sites d’éditeurs pour cataloguer quinze jeux sortis le mois dernier en se basant simplement sur une liste de code-barres. Le tout sans hallucinations.
Alors, bien sûr, pour tout ce qui est opérations routinières et répétées des centaines de fois par jour (interrogation d’un mot-clé, prêts, retours, etc.), les interfaces classiques restent parfaitement pertinentes. Et nettement plus économes en énergie aussi. Mais ne pourrait-on pas attendre de nos chers éditeurs un peu plus d’audace et d’imagination qu’une énième fonction de recherche en langage naturel comme étant la seule feuille de route IA à proposer ?
Cédric Limousin
[Formateur et consultant IA]
