Vers une préservation pérenne du répertoire des œuvres musicales avec électronique : développement du système AntonyTowards the long-term preservation of the repertoire of musical works with electronics: development of the Antony system

Alain Bonardi, Laurent Pottier, Malena Fouillou, Serge Lemouton, Jacques Warnier, Xavier Garnier et Thomas Bottini

Résumé | Index | Plan | Texte | Bibliographie | Notes | Citation | Auteur | Version PDF | a | A

Résumés   

Index   

Index de mots-clés : Informatique musicale, Musique électroacoustique, Documentation des œuvres, Préservation numérique, Archivage collaboratif, Ontologies sémantiques.
Index by keyword : Computer music, Electroacoustic music, Work documentation, Digital preservation, Collaborative archiving, Semantic ontologies.

Plan   

1. Contexte

1.1. Pourquoi ?

1L’expérimentation et la création musicales se sont largement appuyées, depuis la seconde moitié du xx^e siècle, sur le développement des technologies électroniques et numériques. Un corpus de milliers d’œuvres de musique mixte, notamment, a déjà été constitué, utilisant des techniques et des technologies extrêmement diverses. Les acquis de cette révolution qui touche aux supports de la création musicale n’ont toutefois pas la garantie d’être pérennes.

2Intrinsèquement liée à la durée de vie de logiciels en perpétuelle évolution et de langages de programmation non-interopérables, la sauvegarde d’une œuvre mixte ne dépend souvent que de la capacité de rares personnes, réalisateurs et réalisatrices en informatique musicale ou compositeur et compositrices, à mettre à jour les programmes développés (« patchs », codes informatiques, fichiers de partitions, etc.) au gré de la reprise de l’œuvre, conditionnant ainsi sa pérennité à ses interprétations. À ces difficultés inhérentes aux formats des œuvres utilisant des technologies numériques s’ajoute une problématique de conservation et de diffusion : à l’exception de la base de données Sidney (Lemouton Serge et. al., 2019, p. 41-58), archive numérique des œuvres mixtes créées à l’Ircam, un nombre très réduit d’initiatives pérennes a permis d’organiser systématiquement la conservation de leurs patchs tant pour leur sauvegarde que pour leur mise à disposition des artistes et des chercheurs. Le groupe de travail Antony, financé de janvier 2018 à décembre 2019 par l’Association Francophone d’Informatique Musicale (AFIM), se consacre à l’« Archivage collaboratif et préservation créative des œuvres de musique informatique » (Bonardi Alain et. al., 2020). Il a fait le constat suivant : les technologies utilisées dans le cadre des créations musicales utilisant les technologies audionumériques (à l’instar de l’ensemble des technologies numériques qui constituent notre environnement contemporain) se transforment sur des temps de plus en plus courts, ce qui ne permet pas d’établir une traduction et une transmission des savoirs et des pratiques.

3Le projet Antony est né en réponse au risque important qui pèse sur un pan entier du patrimoine musical des dernières décennies. Il s’agit d’une application Web permettant à la fois la sauvegarde, la documentation, le versionnage et la mise à disposition des composantes électroniques d’œuvres musicales utilisant des technologies numériques. L’enjeu de ce projet est donc de lutter contre le caractère éphémère de ces musiques. La rejouabilité des œuvres est une condition nécessaire à la possibilité de leur diffusion, de leur mûrissement et à l’établissement d’un répertoire musical.

1.2. Quoi ?

4Le nom du groupe de travail (Lemouton Serge et. al., 2018, p. 11-12) et du projet de plateforme a été choisi en hommage à David Wessel (compositeur disparu en 2014) et dont l’œuvre Antony (MacCallum John et. al., 2015), réalisée en 1977 sur un ordinateur DEC PDP 11 dans un Ircam encore en préfiguration, a été créée à l’International Computer Music Conference (ICMC) 1977 à San Diego. C’est la plus ancienne œuvre documentée dans la base de données Sidney de l’Ircam. Les travaux du groupe de travail Antony ont donné lieu à la réalisation d’un prototype logiciel qui a été présenté à la Maison des Sciences de l’Homme Paris-Nord en 2021 lors d’un colloque international « Antony — Préservation collaborative pour la musique avec électronique1 » qui avait permis de réunir la communauté des acteurs s’intéressant à la sauvegarde de ces musiques. Ce colloque a également permis une prise de conscience des institutions culturelles de la nécessité d’agir pour préserver ce patrimoine en danger.

5L’année 2025 a été consacrée au développement d’une version opérationnelle d’Antony, grâce à un financement du Fonds d’accompagnement à la transformation numérique et à la cybersécurité (FTNC) du ministère de la Culture. Ce développement a été confié à la société Logilab sous la responsabilité du CNSMDP.

2. Cahier des charges

6Les paragraphes suivants énumèrent et décrivent les onze points sur lesquels repose le cahier des charges du projet Antony. Ces points expriment les caractéristiques et les choix qui président au développement du projet.

2.1. Ouvert

7Le logiciel s’appuie exclusivement sur des technologies libres, standards et éprouvées, bénéficiant d’une communauté active et d’une documentation complète. Son code source est publié en Open Source sous licence AGPL. Son interopérabilité est assurée par une API documentée, permettant notamment l’échange avec d’autres bases de données telles que MusicaSearch du consortium Musica2/HumaNum ou la base de données Sidney de l’Ircam. Le système privilégie systématiquement les formats de données ouverts et documentés, en évitant toute dépendance à des services propriétaires.

2.2. Un système dynamique

8Antony doit permettre la mise à jour incrémentale des éléments déposés dans la base de données, qui évoluent continûment selon les différentes versions des œuvres. Il doit également permettre de suivre l’évolution des logiciels que ces œuvres utilisent, si l’on veut pouvoir continuer à les jouer.

2.3. Pérennité

9La pérennité du système repose sur une approche globale. Au niveau des données, le système doit permettre des sauvegardes périodiques à long terme sur les serveurs avec un dispositif de backup sur des data centers géographiquement distincts assurant la traçabilité et l’intégrité des données.

10L’architecture technique est conçue de manière modulaire pour faciliter la maintenance et l’évolution du système. Le code source est structuré selon les bonnes pratiques de développement et accompagné de tests automatisés couvrant les fonctionnalités principales. D’autre part, l’engagement institutionnel a permis de pérenniser un financement de fonctionnement de la plateforme Antony pour prendre en charge les coûts d’hébergement et de maintenance.

2.3.1. Pérennité des données

11La pérennité des données repose sur l’utilisation des standards du web sémantique pour représenter les données, notamment le format Resource Description Framework (RDF). Le RDF repose sur plusieurs principes. Tout d’abord, l’utilisation d’un identifiant unique et pérenne pour les entités informatives décrites : l’Uniform Resource Identifier (URI). Ensuite, la description des données avec des triplets composés d’une URI, d’un prédicat (verbe ou nom de propriété) et d’une valeur pouvant être une valeur constante ou l’URI d’une autre entité (lien entre entités). Puis, l’expression de ces descriptions de données dans des formats textuels bruts. Enfin, l’utilisation d’ontologies et de vocabulaires existants pour définir les prédicats ou certaines valeurs. L’ensemble de ces mécanismes permettent la construction d’un graphe de connaissances dont les éléments sont définis sémantiquement et documentés, qui repose au maximum sur des composants standards ou populaires, et qui peut être lu directement par des humains ou des machines. Cela facilite la réutilisation des données et assure leur pérennité sur le long terme.

2.3.2. Pérennité du code

12Le code logiciel de l’application est publié sous une licence libre GNU AGPL. Les licences libres permettent à chacun et chacune d’exécuter librement le programme, de consulter son code source, d’étudier son fonctionnement et de l’améliorer. Cela constitue donc un gros avantage pour la pérennité de l’application, car son code n’est pas dissimulé par une entité qui pourrait disparaître.

2.3.3. Pérennité de la plateforme

13La plateforme est déployée sous forme de conteneur Docker. Cette forme permet d’encapsuler le code de l’application, ainsi que l’ensemble de ses dépendances, au sein d’un composant qui peut être exécuté sur n’importe quelle infrastructure d’accueil Docker. Docker est aujourd’hui un système très populaire et tous les fournisseurs de ressources informatiques proposent des infrastructures d’accueil Docker. Ainsi, l’application n’est pas dépendante d’un unique fournisseur et peut être très facilement redéployée. C’est un gage de pérennité à long terme. Par ailleurs, des sauvegardes périodiques seront effectuées automatiquement afin de permettre une remise en service de l’application et de ses données, en cas de problème ou de panne.

2.4. Innovant dans son développement

14Le développement du projet utilise des modèles et des méthodes de développement innovants, afin de fournir une API-Rest documentée et se conformer aux standards du web sémantique. La gestion des fichiers est prise en charge par du stockage object S3 (qui peut être fourni par le logiciel libre Minio, par exemple).

2.5. Standards, Ontologies/Thesaurus

15La refonte d’Antony s’appuie sur une réécriture du modèle conceptuel originel selon les propriétés et les relations de l’ontologie CIDOC CRM (COM CIDOC., 2025), étendue par les ontologies FRBRoo/LRMoo (ICOM CIDOC., 2025) et DOREMUS (Cecconi, Cécile et al., 2024). Le CIDOC CRM est une ontologie standard dans le champ du patrimoine, des musées, de l’archéologie, des sciences, et plus récemment de la recherche en lettres et sciences humaines et sociales. Sa présence toujours croissante dans les milieux culturels, scientifiques et artistiques est due d’une part à sa longévité (elle est un standard ISO depuis presque vingt ans), et d’autre part à son caractère générique et abstrait, qui la rend opérationnelle et conceptuellement féconde dans ces domaines d’activité. Sa promesse est ainsi de proposer une manière commune de représenter les objets physiques/sémiotiques/conceptuels, les phénomènes historiques et sociaux, et toute forme d’activité humaine avec leur contexte.

16Le consortium Musica2 d’Huma-Num a pour objectif de communiquer auprès de la communauté musicologique francophone sur les apports heuristiques du CRM et sur sa mise en œuvre pratique dans les projets de bases de données. L’enjeu pour le CNRS est de positionner le CRM comme langage conceptuel commun pour la modélisation et la documentation des objets étudiés et produits par les musicologues, afin de réaliser l’interopérabilité conceptuelle et technique de données sous-jacentes. En tant qu’ontologie abstraite et générique, le CIDOC CRM n’a pas vocation à inventorier et caractériser l’ensemble des objets propre à notre domaine métier (« compositeur », « RIM », « version d’une œuvre musicale », « patch Max », « fichier Faust », « concert », « Yamaha DX7 », etc.). Ces entités métier seront ainsi toutes modélisées avec des classes génériques du CRM (« Personne », », « Objet informationnel »), mais le CRM encourage leur typage avec des thésaurus qui fixent la sémantique des entités propre à chaque métier. Ainsi, Antony est en train de produire des thésaurus pour inventorier les concepts, les notions, les types et les mots spécifiques aux domaines qui le concernent, et les mettre à disposition de la communauté sur l’instance Opentheso2 publique d’Huma-Num.

17Ainsi la démarche de modélisation s’appuie-t-elle sur deux dimensions toujours en dialogue : la caractérisation et l’organisation des choses (avec une ontologie) et l’inventaire des mots qui désignent ces choses et leur affectent une sémantique partagée (avec des thésaurus). Sur le plan de la gestion de projet, cette distinction est vertueuse, car elle autonomise le travail sur les mots/types/concepts lié au développement logiciel réalisant la logique de l’application : les acteurs spécialistes du métier peuvent gérer leurs thésaurus dans un outil autonome et les valoriser dans leurs communautés indépendamment du processus de construction de l’application, que les développeurs iront consommer pour nourrir les écrans.

2.6. Collaboratif, démarche participative, publics visés

18Antony s’adresse à une grande diversité de compétences, à des contributeurs de différentes professions (RIMs, musicologues, interprètes, compositeurs et compositrices, étudiants et étudiantes, organisateurs et organisatrices, éditeur et éditrices, etc.…). L’interface de la plateforme est destinée à permettre à plusieurs acteurs et actrices de travailler simultanément sur la même version d’une œuvre.

19Il s’agit d’un projet dont l’ambition est d’encourager la participation d’acteur·ice·s appartenant à des communautés variées afin d’ouvrir le plus largement le répertoire des œuvres et des pratiques utilisant des moyens électroacoustiques ou d’informatique musicale. Un objectif avoué du projet est de construire un modèle permettant de répondre aux besoins d’acteur·ice·s appartenant à des répertoires artistiques différents de celui des productions actuellement stockées sur Sidney.

2.7. Gestion des droits, enjeux légaux

20Étant donné qu’Antony est destiné à stocker, documenter et offrir la possibilité de diffuser des œuvres musicales reposant sur des droits d’auteurs, des droits voisins d’interprète et des responsabilités d’éditeurs de musique, cet outil permet une gestion des droits numériques (DRM). Son interface présente des Conditions générales d’utilisation en conformité avec la législation du droit d’auteur, pour savoir déjà si un déposant a les droits de le faire et permettre de gérer les droits voisins sur les enregistrements, les patches et logiciels, des interprètes et des RIM (réalisateurs et réalisatrices en informatique musicale), ainsi que les licences sur les logiciels et sur les documentations produites sur la plateforme.

21La gestion des droits d’accès est stricte et différenciée en fonction du statut des utilisateurs (administrateur, responsable d’institution déposante, musicologue, documentaliste, public en simple consultation). Les droits au téléchargement des éléments électroniques d’une pièce sont conditionnés aux droits des utilisateurs de la base de données.

2.8. Documentation

22La documentation permet d’accompagner le projet à plusieurs niveaux complémentaires. Pour les utilisateurs, le système présente un mode d’emploi en ligne détaillant les recommandations et bonnes pratiques pour documenter les œuvres. La page d’accueil propose un formulaire pour contacter les administrateurs ainsi que des ressources pédagogiques.

23La documentation technique couvre l’architecture du système, son API, les procédures de déploiement et d’exploitation. Elle intègre également l’historique et la justification des choix techniques, facilitant ainsi la compréhension et l’évolution future du projet. Un guide de contribution au code source complète l’ensemble, permettant l’implication d’autres développeurs dans le respect des standards établis. Cette documentation va évoluer tout au long du projet en collaboration avec le Conservatoire et ses partenaires, assurant ainsi sa pertinence et son utilité pour les différents publics concernés.

2.9. Accessible

24Les utilisateur·rice·s majoritaires n’étant pas technophiles, l’accent est mis sur l’ergonomie du système d’administration en proposant une interface séduisante et réactive ainsi qu’une version réactive et mobile du projet.

2.10. Sécurisé

25Les données de l’application sont sécurisées et l’accès est contrôlé par l’application avec la gestion des permissions avancées de CubicWeb. Les bibliothèques externes sont en nombre limité et sont mises à jour régulièrement afin d’appliquer les correctifs de sécurité. Pendant la phase de développement, le code est passé en revue et validé par des pairs. Des tests d’intégration continue sont effectués afin d’identifier de potentielles régressions et un scan de sécurité est effectué.

2.11. Frugal, au bilan carbone raisonné

26Des solutions doivent être proposées pour répondre aux exigences de sobriété demandée pour réduire les émissions de gaz à effet de serre. Il est prévu d’éviter le stockage des captations audio et vidéo haute-définition pour la partie documentaire d’Antony lorsque ces captations existent sur d’autres plateformes, de chasser les fichiers redondants en les partageant s’ils sont communs à plusieurs pièces ou plusieurs versions d’une pièce. Les fichiers déposés seront stockés en un seul exemplaire sur les serveurs. Si plusieurs versions ont des fichiers identiques, un lien sera fait sur chaque version. Un fichier ne sera pas supprimé tant qu’une version aura un lien vers ce fichier.

27La société Logilab3 a été choisie, car elle met en œuvre des bonnes pratiques de sobriété numérique telles que l’hébergement des données par des fournisseurs français, le partage et le recyclage des ressources informatiques ou encore la limitation des déplacements.

3. Antony

3.1. Modèle de données

28La modélisation des données, représentée en Figure 1 est confiée au cadriciel CubicWeb, permettant d’exprimer un modèle de données respectant les standards du web sémantique, et permettant la gestion fine des permissions exigées par l’application. Ce modèle de données se calque sur les classes de l’ontologie Cidoc-CRM pour représenter les entités (œuvres, versions, performances, personnes…) et leurs relations. Le modèle de données reprend également l’ontologie DoReMus qui apporte les éléments qui décrivent les événements musicaux.

29Les vocabulaires exprimés en SKOS et édités dans Opentheso4 sont récupérés périodiquement et chargés dans l’application. CubicWeb permet d’exporter les données RDF depuis une interface utilisateur, ou bien via une API en exécutant périodiquement un script.

Figure 1 : Modèle de données d’Antony

3.2. Planning 2025

30La convention signée entre le ministère de la Culture et le CNSMDP fixe un planning (voir Figure 3) sur une année de janvier 2025 à janvier 2026. Une fois les rôles définis, la liste des tâches inventoriées, la procédure de marché public pour choisir un prestataire faite, voici schématisé ci-après le déroulement du projet. Une première moitié de l’année a été consacrée au développement d’une version beta d’Antony. C’est une version vouée aux tests à mener auprès de la communauté des musiques électroniques. Ces tests portent sur les procédures de créations de comptes et de statuts d’utilisateur. Ils portent également sur les dépôts et gestions de leur documentation en mode collaboratif, de la gestion des droits. Ils permettent de confronter le modèle de données à la description de la multitude des pratiques musicales et pourquoi pas à d’autres univers du monde du spectacle vivant utilisant des technologies numériques.

Figure 2 : Fenêtre d’accueil de la version beta en test d’Antony

31Une fois analysés, via les retours utilisateurs à l’automne 2025, il est prévu la finalisation de la version 1 pour un déploiement fin 2025, dont un premier visuel est à retrouver Figure 2. Deux rendez-vous avec le ministère sont prévus : un point d’étape sur le projet le 4 juillet et l’autre le 17 janvier 2026 pour rendre compte et pour clore l’année.

Figure 3 : Planning du projet Antony sur l’année 2025

3.3. Gouvernance — ou comment est organisé Antony

32L’enjeu patrimonial du projet a nécessité de mobiliser différentes institutions culturelles. Celles-ci ont répondu présentes et ont statué sur le constat de péril auquel est voué le répertoire utilisant des dispositifs technologiques et sur la nécessité de désigner parmi elles un porteur de projet pour héberger le projet, d’accepter la solution Antony et d’en financer le développement et le fonctionnement récurrent. D’autre part Antony est porté par le consortium Huma-Num Musica2 qui permet d’interroger une communauté élargie de chercheurs dans les domaines de toutes les musiques avec dispositif. C’est l’occasion d’ouvrir Antony à d’autres expressions musicales avec dispositifs électroniques que la musique mixte. C’est aussi un soutien conceptuel de nommage et de description des objets stockés dans le dispositif.

Figure 4 : organigramme d’Antony

33Le schéma relationnel représenté Figure 4 décrit l’organisation du projet. Le CNSMDP, représenté par sa directrice Emilie Delorme, est porteur et hébergeur du projet. Le lien avec le financeur, le service numérique du ministère de la Culture, est une convention FTNC (Fond d’accompagnement à la numérisation et à la cybersécurité) jusqu’en janvier 2026. Un comité de suivi réunissant les institutions culturelles partenaires, se compose de la Direction Générale de la Création Artistique DGCA, de la Maison de la Musique Contemporaine (MMC), de la Sacem, de la Bibliothèque Nationale de France (BNF), du CEMF, de l’Ircam et du CNSMDP. Le bureau coordonne le projet. Il émane du groupe de travail Antony créé en 2018. Le groupe éditorial est prévu pour administrer et gérer la modération de la plateforme. Des groupes de travail sont montés en fonction des thématiques telles que les droits d’auteurs, le développement des thésaurus ou encore le travail sur le modèle de données.

4. Conclusion et perspectives

34Au cours de l’année 2025, le développement et le beta testing du site Antony a été l’occasion de rassembler et de fédérer une communauté internationale d’utilisateurs concernés par la préservation, la diffusion et la mise à jour des dispositifs logiciels et matériels nécessaires à la performance des musiques faisant appel à des moyens informatiques et électroacoustiques. La liste de diffusion publique « antony-news5 » permet de suivre l’avancement du projet et de participer aux tests du prototype en ligne, en mettant à disposition des instructions à suivre : création d’un compte, CGU et rappel juridique, attente de l’équipe de développement. Un mode d’emploi de la plateforme est intégré à la page d’accueil. Les retours des utilisateurs/testeurs concernant la facilité de connexion pour la création de comptes de login, les bugs rencontrés, l’ergonomie de la plateforme, la simplicité et la compréhension de son fonctionnement sont attendus par l’équipe de développement. Nous souhaitons également recueillir l’avis des utilisateurs extérieurs concernant la capacité du modèle Antony à décrire d’autres champs musicaux ou d’autres pratiques artistiques utilisant des technologies. À noter que des financements provenant du consortium Musica2 vont permettre l’intégration de la source de données Antony dans le moteur de recherche MusicaSearch et la traduction de la plate-forme en anglais.

35En résumé, Antony propose donc une solution d’archivage de l’ensemble des fichiers nécessaires pour jouer l’électronique d’une œuvre musicale utilisant des technologies audionumériques. Antony permet d’inventorier en détail l’ensemble des fichiers versés pour une archive et d’y associer un identifiant, un droit, et une documentation. Antony propose de documenter la mise en œuvre du dispositif électroacoustique fonctionnant avec cette archive. Antony décrit les contextes, les pratiques techniques, les rôles, les instruments, les logiciels, les fonctions au plus juste, nécessaires pour jouer les œuvres. Antony, outil collaboratif, permet à plusieurs acteurs experts d’abonder la documentation pour qu’elle soit le plus explicite possible. Antony permet donc la sauvegarde et la diffusion des œuvres sur le court terme. Les solutions telles que Sidney ou Antony sont incomplètes bien sûr d’un point de vue archivistique. Mais nous avons affaire à un objet si particulier qu’il a nécessité de faire un pas de côté. Notre objet d’étude est un ensemble de fichiers numériques multiple et disparate, unique, dont le sens dépend d’un environnement technologique et de pratiques métiers capables de les mettre en œuvre. Quelques années d’évolution de ces technologies et l’oubli des pratiques de mise en œuvre pourraient rendre notre archive numérique inutilisable. Cette archive étant la partie électronique d’œuvres musicales, si elle n’est plus fonctionnelle, l’œuvre qu’elle accompagne ne peut plus être jouée.

36Si l’on veut assurer la rejouabilité et l’exploitation des archives stockées sur le moyen terme, il faut donc que d’une part la communauté des utilisateurs participe à la mise à jour des patches et des codes informatiques en créant de nouvelles versions à l’occasion de reprises de l’œuvre (dans une démarche de préservation créative) ou lors de changements technologiques majeurs, et que d’autre part le système propose des fonctionnalités d’aide à ces mises à jour grâce à des procédures de validation par éditorialisation, des outils d’aide au portage et des systèmes de tests automatisés.

37Enfin, nous devrons aborder la question de la préservation sur le long terme du répertoire constitué en s’appuyant sur des systèmes d’archivage numérique pérenne et des systèmes de stockage fiables et contrôlés. Mais ce serait le sujet d’un autre article.

Bibliographie   

Notes   

Citation   

Auteur   

Quelques mots à propos de :  Alain Bonardi

Quelques mots à propos de :  Laurent Pottier

Quelques mots à propos de :  Malena Fouillou

Quelques mots à propos de :  Serge Lemouton

Quelques mots à propos de :  Jacques Warnier

Quelques mots à propos de :  Xavier Garnier

Quelques mots à propos de :  Thomas Bottini