Le « lac de données », une infrastructure technique pour déployer la gouvernance des données à l’Ina
Remerciements
Nous remercions Éléonore Alquier, responsable du département Data de l’Ina pour sa collaboration à l’élaboration de ce texte.
Texte intégral
1Depuis huit ans, l’Institut national de l’audiovisuel [Ina] travaille à mettre en place une nouvelle architecture pour son système d’information, autour d’une infrastructure, le « lac de données », qui organise l’ensemble des processus autour de la donnée : traitement, stockage, exploitation et valorisation. En permettant l’émergence d’une véritable gouvernance de données, cette évolution conduit à une nouvelle répartition des rôles et fait émerger de nouveaux profils professionnels.
2Cet article revient sur les différentes étapes qui ont conduit à définir cette architecture : les problèmes que nous avions à résoudre, les options envisagées et les raisons de nos choix. Il aborde dans un second temps les impacts de cette évolution sur l’organisation.
La donnée : nouvelles perspectives pour le système d’information
3L’idée du lac de données à l’Ina est née de deux convictions. D’une part, sur le plan de la modélisation des données, il est nécessaire de s’affranchir des « carcans de la pensée documentaire » touchant à la description de la collection1, de quitter le paradigme de la notice de catalogue pour aller vers celui de la donnée. Cette première exigence implique de dépasser les principes traditionnels des systèmes d’information documentaires, fondés sur l’association d’un document à une notice, pour appréhender de manière cohérente les différents niveaux de granularité qui vont de la collection au contenu du document (les données) en passant par le document et sa description (les métadonnées). D’autre part, sur le plan technique, il n’existe actuellement aucun système de gestion de données qui réponde de manière parfaite à tous les besoins. L’enjeu principal réside dans le fait de séparer les données des usages, c’est-à-dire penser les données indépendamment de l’utilisation qu’on en fait, en les plaçant au cœur du système.
4Cette double posture conceptuelle a guidé la réflexion des équipes de l’Ina dans les objectifs de la refonte de son système d’information : pour répondre aux enjeux actuels et futurs des systèmes d’information [SI] documentaires2, il faut adopter une approche qui implique de déconstruire la notice et de s’appuyer sur la diversité des technologies aujourd’hui à notre disposition.
La donnée au cœur de la nécessaire déconstruction de la notice
5La notice, au sens qu’on lui donne traditionnellement dans les métiers de l’information, est un document qui regroupe un certain nombre d’informations descriptives, ou métadonnées, concernant un objet d’une collection3. Si l’on examine l’évolution de la description documentaire, on constate que la notion de notice a préexisté à la notion de métadonnées. Cette dernière a émergé principalement en raison de l’augmentation du nombre d’informations nécessaires pour décrire un document, d’abord avec la numérisation et l’ajout des métadonnées techniques, administratives, juridiques et de structure, puis avec le besoin croissant de collecter, gérer et exploiter d’autres types de données périphériques : traces d’usage, données produites par les usagers dans le cadre du collaboratif (User Generated Content), données extraites du document ou générées automatiquement à partir de son analyse.
6L’apparition des métadonnées présentait un autre avantage : on pourrait parler de dimension « marketing » de la notion de métadonnées, le choix d’un nouveau terme venant redonner de l’intérêt à un sujet considéré comme dépassé. Pourtant, les premiers formats et modèles qui ont émergé pour encoder les métadonnées, qu’il s’agisse du XML, avec sa structure hiérarchique encadrée par des balises, du Dublin Core4 simple, avec ses quinze éléments facultatifs et répétables, ou encore de METS, un format container qui regroupe toutes les métadonnées et cartographie la structure du document, présentaient un point commun : comme la notice de catalogue avant eux, ils enfermaient la description documentaire à l’intérieur de frontières artificielles, créant de fait un nouveau document, un méta-document dont la fonction était de décrire le document-objet se trouvant à l’intérieur des collections.
7Ces quinze dernières années, la réflexion autour du modèle de graphe, survenue notamment à travers le concept de web sémantique, a fait émerger un nouveau modèle5. L’idée est de structurer l’information autour de la description d’entités du monde réel (objets, personnes, concepts, lieux, événements), de formuler des assertions concernant ces entités au moyen de triplets, puis de relier ces entités entre elles sous la forme d’un graphe. La notion de graphe a conduit à l’idée de « détruire » le méta-document que constituait la notice ou encore de faire « éclater » la notice6. Les données ne sont plus enfermées à l’intérieur d’une notice, mais liées les unes aux autres dans un espace global d’information. Dès lors, il devient possible de dépasser la vision documentaire des informations de signalement qui avait émergé avec l’idée de notice, qui limitait notre réflexion et maintenait artificiellement des frontières, en particulier entre le document et sa description, lorsqu’il s’agissait de lier les informations entre elles.
La donnée pour assurer le lien entre le document, sa description et son contenu
8La réflexion autour du web sémantique et du modèle du graphe nous a rappelé que la métadonnée est une donnée comme une autre et qu’il n’existe pas, pour le document numérique, de frontière imperméable entre le document dans sa globalité, sa description et son contenu. L’OCR7 ou la transcription, puis la fouille de texte et de données rendent possible l’analyse, non plus du document, mais du contenu lui-même : on peut désormais repérer une chanson diffusée à l’intérieur d’une émission télévisée, cartographier les lieux cités dans un documentaire, identifier le visage d’une personnalité ou l’apparition d’une marque à l’écran. Le contenu du document se retrouve à son tour partie prenante du signalement : la granularité de la description devient encore plus fine. Les métadonnées s’éloignent du rôle de métatexte8, qui pouvait être joué par la notice, pour être plus intrinsèquement liées aux entités repérables à l’intérieur du document lui-même. À partir de ce moment, la place de la donnée de signalement traditionnelle est inévitablement remise en question.
9Dans cette vision des choses, la donnée de signalement fait partie du contenu numérique de l’objet et est gérée conjointement avec lui, devenant ainsi en tant que telle un objet d’études potentiel. Par exemple, depuis 2005, l’Ina publie le baromètre Ina’STAT9, qui fournit une vision de l’actualité établie à travers la documentation des sujets des journaux télévisés [JT]. Cette documentation des JT est devenue une source, de la même manière que le catalogue de la BnF est devenu une source d’analyses massives sur les fonds. Ces exemples marquent la fin de la dichotomie entre notice et document : les données, qu’elles soient issues du catalogage ou extraites du document lui-même, constituent une représentation du contenu et permettent de l’appréhender, de l’exploiter, d’y accéder et de le valoriser.
La donnée au cœur du système d’information
10Ce nouveau paradigme du signalement, qui implique de traiter de façon cohérente toutes les informations dont on dispose au sujet de la collection et des objets qui la composent, nécessite de placer la donnée au centre du système d’information. Nous souhaitions donc centraliser toutes les données, quels que soient leur origine et leur usage (documentaire, commercial, juridique) concernant les documents qui forment les collections de l’Ina, quel que soit leur type (sons, images télévisées, archives écrites, livres et revues, photographies et même archives web), quelles que soient la nature et la structure des données qu’elles contenaient.
11Cette approche représentait pour l’Ina un véritable renversement du système d’information traditionnel. Auparavant, comme dans la plupart des organisations, le SI de l’Ina était organisé de manière verticale : à chaque besoin métier correspondait une application qui gérait ses propres données, ce qui avait pour conséquence la création de silos de données sans lien entre elles. Depuis une vingtaine d’années, l’architecture orientée service a permis l’émergence de solutions qui ajoutent une couche pour faire le lien entre les services applicatifs de différents silos, mais l’équivalent n’existe pas pour faire des liens au niveau de la couche de données. Notre idée était donc de briser ces silos pour permettre d’accéder de manière homogène à toutes les données disponibles. Il nous fallait gérer les données dans une infrastructure technologique unique, chargée de centraliser le traitement des données : c’est le rôle du lac de données.
12Le lac de données de l’Ina se définit donc comme une infrastructure unique de traitement et de stockage de la donnée structurée ou semi-structurée. Le terme de « lac » s’est imposé progressivement : au début du projet, on privilégiait les appellations de Business Intelligence10, « puits de données » ou « datawarehouse » (entrepôt de données). Cependant, l’image du puits présentait des connotations négatives (un puits sans fond d’où l’information ne remonte jamais), aussi lui a-t-on ensuite préféré celle, plus fédératrice, du lac. Nous imaginions un endroit où des bateaux pourraient naviguer et dont on maîtriserait le périmètre, au contraire de petits étangs isolés les uns à côté des autres.
13Pour autant, ce terme de « lac » peut s’avérer trompeur : en effet, les « Data Lake » tels qu’identifiés par le marché ne correspondent pas techniquement au modèle adopté par l’Ina11. Ces outils gèrent des fichiers à plat, avec une perte relative de la structure de données ; au contraire, le lac de données de l’Ina préserve cette structure, notamment à travers un modèle conceptuel commun auquel vont se relier toutes les données concernant la collection et son contenu.
Mise en œuvre du lac de données
14L’histoire de l’informatique n’est qu’une suite de centralisations et de décentralisations ; actuellement, nous sommes dans une phase de recentralisation des systèmes d’information constitués en silos. Au-delà de la centralisation des données, nous étions également convaincus, à l’heure de mettre en place le lac de données, qu’il fallait centraliser techniquement les processus de traitement et de stockage des données. La centralisation est aussi une réponse à un problème de moyens : maintenir un système et maîtriser les données est plus difficile et plus coûteux lorsque les silos se multiplient les uns à côté des autres, car une telle architecture dilue les moyens. L’enjeu était donc de définir une architecture adaptée pour centraliser les données tout en s’affranchissant du paradigme de la notice.
La solution universelle pour stocker et exploiter les données n’existe pas
15Historiquement, la base de données relationnelle constitue le cœur des systèmes d’information, dès lors organisés autour du modèle relationnel et de la notion de table. Pratiqués depuis quarante ans, ces logiciels robustes gèrent de façon optimale les contraintes d’intégrité des données. Cependant, les limites de ce modèle sont apparues au moment où les moteurs de recherche sont montés en puissance, faisant émerger des applications logicielles dans lesquelles le moteur de recherche est au cœur de l’infrastructure (search based applications12) et dont le principe consiste à interroger en langage naturel des données structurées ou semi-structurées stockées sous la forme de documents. On peut alors parler de « base de données document13 ». Ces nouveaux outils rendaient possible la scalabilité horizontale14, qui n’était pas supportée par les bases relationnelles, et présentaient donc des avantages en termes de coûts, de performance et de rapidité. Ils permettaient en outre de rechercher en plein texte à l’intérieur de l’ensemble des informations disponibles, métadonnées et contenu, limitant le besoin de connaître finement leur structuration pour formuler des requêtes. En revanche, les moteurs de recherche posent un problème en termes de gestion de données : pour rendre ce service, les mêmes informations doivent être répétées dans chaque document, ce qui oblige à des opérations complexes de réplication des données et peut conduire à les désynchroniser. Le modèle de table de la base de données relationnelle et le modèle orienté document du moteur de recherche présentent donc chacun des avantages et des inconvénients, sans qu’aucun des deux ne puisse résoudre tous les problèmes.
16Le modèle de graphe survenu par la suite propose une modélisation qui offre une grande souplesse dans la manipulation des données, grâce à une granularité très fine, mais peut aussi rendre très complexe la représentation de certains liens à l’intérieur des documents. En outre, cette notion de graphe s’est avérée difficile à appréhender pour les développeurs, ce qui peut expliquer une adoption relativement limitée dans l’industrie de ces technologies. Les triplestores, bases de données de graphes conformes aux technologies du web sémantique, présentent, en outre, de sérieux problèmes de performance et de modélisation. Même si d’autres modèles de graphes, indépendants du web sémantique, ont émergé par la suite avec des produits comme Neo4J, les problématiques de maintenabilité de ce type de technologie ne sont toujours pas pleinement résolues aujourd’hui et nous interdisent de nous reposer entièrement sur elles.
17Cette rapide comparaison des trois modèles actuels de stockage et d’interrogation des données montre qu’aucun ne présente toutes les caractéristiques qui lui permettraient de supplanter les autres. Différentes contraintes, en fonction du cycle de vie de la donnée et des besoins rencontrés pour son usage, impliquent de faire appel à la base de données relationnelle, à la base de données document, au moteur de recherche ou à la base de données graphe suivant les cas. Ce constat a conduit à la nécessité, pour le lac de données de l’Ina, de disposer de ces différents types d’applications pour gérer des données organisées en tables, en graphes ou en documents et de faire passer les informations de l’une à l’autre en fonction des besoins et des cas d’usage.
Un modèle conceptuel de données au cœur du système d’information
18Si le web sémantique ne nous fournissait pas les technologies capables d’atteindre notre objectif, son apport conceptuel nous montrait la voie pour réaliser des liens entre les données isolées dans différents silos, construire un graphe de l’ensemble des données et parvenir à les maîtriser15. Suivant ce principe, l’interopérabilité des données est assurée au travers des identifiants communs qui se trouvent dans les différents types de bases de données et via l’adoption d’un modèle conceptuel16 commun, suffisamment souple pour couvrir tous les cas de figure.
19Le modèle conceptuel mis en place pour le lac de données est organisé autour de trois entités principales17 : le contenu (l’essence de l’objet décrit), le support physique ou numérique, et l’événement (qui décrit l’histoire de l’objet depuis sa création en passant par son utilisation et sa conservation). Les éléments textuels (les attributs tels que les noms et les titres, ou les textes qui composent le contenu lui-même) sont eux-mêmes traités comme des entités, ce qui donne au modèle une souplesse et une extensibilité optimales. Enfin, chaque donnée est caractérisée par des informations de provenance. Très générique, ce modèle permet de décrire n’importe quel type d’objet et de lui associer toute sorte d’information. Les données représentées suivant ce modèle fondé sur leur logique intrinsèque, indépendamment de leur usage, constituent le cœur du système d’information : on peut dès lors parler de données primaires. Ces données primaires pourront ensuite être dérivées en données secondaires au sein du lac pour fournir des vues spécifiques sur les données, adaptées à tel ou tel type de besoin.
20Grâce à ce modèle, nous voulions centraliser la couche « data », c’est-à-dire toutes les bases de données de notre système, quel que soit leur type et quelles que soient la nature et la structure des données qu’elles contenaient. Pour cela, une infrastructure de stockage contenant à la fois une base de données relationnelle, une base de données graphe, une base de données document et un moteur de recherche a été mise en place. Au sein de cette couche de données, chaque type de base de données remplit sa fonction propre. La base de données relationnelle gère la donnée primaire s’agissant des données structurées (typiquement, les métadonnées) : le modèle de table est aujourd’hui celui qui assure le mieux les contraintes d’intégrité et la gestion des transactions. Par ailleurs, il s’agit d’une technologie bien connue et qui a fait ses preuves. Les données semi-structurées générées automatiquement (par exemple le résultat d’une transcription, d’une OCR ou d’un processus d’analyse automatique des visages) sont, elles, stockées dans une base de données document, plus adaptée à leur formalisme. Ce sont également des données primaires. Enfin, le graphe de connaissance et le moteur de recherche sont quant à eux alimentés par des données secondaires calculées à partir de ces données primaires.
21La mise en place du nouveau modèle de données a nécessité une reprise totale des données, transférées depuis toutes les bases existantes au sein de l’Ina vers le modèle unique du lac. L’enjeu de cette opération de longue haleine, conduite en parallèle au déploiement de l’infrastructure technique, était de mettre fin au silotage des données, d’éviter les redondances d’informations et de remettre les données en cohérence.
Une architecture en couches
22Les avantages de cette organisation des données, qui fait cohabiter plusieurs types de bases, sont clairs : il devient possible de manipuler la donnée de différentes manières suivant les besoins, en combinant les avantages respectifs de chaque type de produit. Les données primaires sont stockées suivant un modèle conceptuel commun qui respecte leur logique intrinsèque, tandis que des données secondaires sont produites pour répondre aux différents cas d’usage qui peuvent se présenter. Cependant, ce stockage multiple implique des risques. Comment contrôler la cohérence des données lors des réplications entre bases, puisque c’est le principe de ce système ? Comment s’assurer que cette cohérence n’est pas remise en cause en cas de panne ou d’interruption de la transaction ?
23Afin de répondre à cette problématique, nous avons donc ajouté, entre les bases de données et l’interface d’accès aux données, une couche de traitement dont la fonction est de transformer la structure physique des données, telle qu’elle se présente dans les bases, en une structure logique : le modèle de données qu’on expose via des web services. La donnée se trouve ainsi séparée des usages. En architecture de systèmes d’information, le modèle appelé MVC [Modèle Vue Contrôleur] distingue les données (le modèle), les services (le contrôleur) et l’interface (la vue). Le lac de données est organisé suivant ce principe, cette couche intermédiaire de services assurant le lien entre le stockage des données et les interfaces d’accès, et opère les traitements nécessaires. Dans cette couche intermédiaire, nous n’avons pas fait de choix dans les logiques de traitements : ils s’exécutent de façon synchrone (sous forme de web service), asynchrone (en batch18) ou encore en flux. Le choix s’effectue en fonction des besoins. Ensuite, les applications du système d’information de l’Ina qui ont besoin d’interagir avec des données s’appuient sur le lac de données à travers les web services offerts par la couche d’interface.
24Le principal apprentissage que nous avons retiré de notre démarche est que la couche intermédiaire, le module de traitement, est le cœur de notre système : c’est lui qui garantit l’interopérabilité du système en faisant en sorte que le modèle de données utilisé par les applications (notre modèle conceptuel) reste indépendant du stockage physique des données. De ce fait, les maîtrises d’œuvre des applications métiers du SI ne voient jamais la structure physique des données, leur structure réelle, mais accèdent à une structure normalisée produite par cette couche intermédiaire, dont nous sommes en mesure de garantir la permanence : si nous devons modifier la structure des bases, nous faisons évoluer les traitements intermédiaires, pour continuer à fournir aux usagers la même structure logique. De même, il est possible d’introduire un nouveau type de stockage de données sans perturber les services fournis par le lac de données ni sa logique d’ensemble.
L’articulation avec les applicatifs métiers
25Une fois le framework disponible, c’est-à-dire l’infrastructure déployée et le nouveau modèle de données disponible sous forme de web services, une diversité d’usages devient possible. Ceux-ci peuvent porter sur la consommation des données via des interfaces de consultation, sur l’exploitation des données disponibles pour construire de nouvelles visualisations, ou encore sur la production (manuelle ou automatique) de nouvelles données qui vont venir rejoindre le lac. Ces fonctions sont assurées par des applications métiers qui vont se brancher sur le lac de données en s’appuyant sur l’implémentation de nos flux et de nos web services. Les maîtrises d’œuvre de ces applications métiers n’ont pas la main sur le format des données : elles doivent décrire les données dont elles ont besoin, les interactions qu’elles souhaitent mettre en œuvre et les performances attendues. Côté lac de données, la base de données qui va répondre à la requête sera déterminée en fonction de ces besoins. Par exemple, la décision de stocker les données dans une base relationnelle puis de les répliquer dans un moteur de recherche est un traitement envisagé de façon générique, donc rapide à mettre en place. Le modèle de données le plus pertinent est ensuite exposé au demandeur, qui sera libre de modifier à la volée les données fournies et d’établir les profils d’accès des usagers, mais sans stocker les données modifiées dans une autre base : les données doivent rester en interaction avec le système du lac, sinon on retombe dans l’inconvénient de la multitude des « petits étangs ».
26Cette contrainte crée une dépendance de ces applications métiers à l’égard du lac, puisque c’est lui qui reçoit et stocke les enrichissements produits de leur côté pour conserver la cohérence de l’ensemble des données. Il est donc important de pouvoir compter sur la souplesse du modèle conceptuel du lac et la maniabilité offerte par l’infrastructure, avec ses différents types de bases et sa couche de traitement intermédiaire, pour limiter cette contrainte. Ainsi à l’heure actuelle, une nouvelle source de données peut être ajoutée en vingt-quatre heures et grâce à l’abstraction et aux possibilités de configuration offertes par le système, la plupart du temps sans recourir à du développement spécifique. De plus, tous les systèmes du lac sont automatisés avec une intégration continue. À partir de l’étape du codage, le déploiement s’effectue sur quatre environnements : développement, intégration, préproduction, production. Tout a été réfléchi pour que le déploiement soit automatisé et le plus simple possible, afin d’assurer la haute disponibilité et la scalabilité de ces quatre environnements.
27Cette souplesse et cette évolutivité constituent le point fort du système : c’est grâce à elles qu’il a été possible de concevoir cette approche par la structuration et la modélisation de la donnée avant même d’attaquer la question des processus ou de commencer à travailler sur les logiciels métier. Même si le chantier est déjà bien engagé, ce dernier chemin reste encore largement à parcourir : traduire ces cas d’usage en outils utilisables par les utilisateurs finaux, s’appuyant sur une nouvelle organisation adaptée.
Les implications organisationnelles
28Nous l’avons vu, la mise en place du lac de données constitue un bouleversement pour le système d’information de l’Ina. Au-delà de la mise en place d’un modèle conceptuel nouveau et de la centralisation de toutes les données dans une infrastructure technique commune, l’architecture mise en place impose à toutes les applications métiers de l’Ina d’articuler leur fonctionnement avec le lac de données. La mise en place d’une gouvernance et d’une organisation adéquates était donc nécessaire pour garantir le bon fonctionnement du SI.
Un département Data
29La réorganisation de l’Ina, effective au 1er septembre 2021, est venue confirmer cette trajectoire en modifiant l’organisation du travail à deux niveaux.
30Tout d’abord, au sein de l’ancienne direction des systèmes d’information [DSI], la mise en place d’une architecture centrée sur les données a eu pour conséquence de rendre obsolète la division classique de l’activité entre développement (build) et production (run). Il faut acter que les applications du SI ne sont pas des projets qui, une fois achevés, basculent dans un mode de maintenance minimal, mais des produits en constante évolution. Il devient donc nécessaire, outre l’intégration continue déjà évoquée, de s’organiser en lignes de produits pour gérer l’ensemble du cycle de vie des applications du SI. L’infrastructure du lac de données est elle-même un produit : une équipe pluridisciplinaire a été mise en place pour le gérer, réunissant des compétences allant de l’intégrateur technique, les devOps et les dataOps, à l’expert métier de la donnée, les analystes de la donnée.
31De même, au niveau de l’entreprise dans son ensemble, maîtriser la gouvernance des données de manière globale implique de regrouper tous les spécialistes de la donnée, qu’ils soient techniques ou métier, dans une même unité organisationnelle. Le nouveau département Data rassemble l’ingénierie de la donnée, c’est-à-dire des compétences en informatique ciblées sur la gestion de la donnée, et l’ingénierie documentaire, à savoir les compétences nécessaires pour modéliser, produire, gérer et interpréter les données dans un domaine spécifique, à l’Ina, l’audiovisuel.
32Cette nouvelle organisation, qui a fait fusionner la DSI avec une partie de l’ancienne direction des Collections au sein d’une nouvelle direction dite « Data et technologie », est aujourd’hui en mesure de rendre un meilleur service à l’ensemble de l’organisation. Les besoins métiers de l’entreprise sont dès lors pris en main par d’autres directions, par exemple la direction des Patrimoines, qui regroupe les documentalistes chargés de traiter et valoriser les collections. Au sein de ces directions, les pratiques doivent évoluer pour prendre en compte l’articulation avec le lac de données.
L’introduction de l’intelligence artificielle
33Disposer d’une infrastructure centralisée pour toutes les données de l’Ina nous ouvre également une nouvelle perspective : celle de pouvoir automatiser, en s’appuyant sur des technologies d’intelligence artificielle, la production d’un certain nombre de données. Certains systèmes sont déjà en production : transcription de la parole en texte [Speech to text] des émissions liées à l’actualité comme les JT, extraction d’entités nommées dans les transcriptions, analyse de la parole pour distinguer les voix d’homme et de femme, océrisation des bandeaux sur les chaînes d’information en continu ou analyse des visages sur les mêmes chaînes, segmentation automatique de programmes ou de sujets, etc. D’autres sont encore à l’étude, comme l’indexation automatique par sujet avec la classification automatique opérée à partir du texte transcrit, pour la rapprocher des 900 principaux descripteurs de notre thésaurus de noms communs.
34L’automatisation progressive d’un certain nombre de traitements répond principalement à deux cas d’usages : assister le travail des documentalistes pour augmenter la couverture des collections que l’on est capable de traiter et la granularité de certaines descriptions ; faire émerger de nouvelles connaissances par l’analyse d’informations extraites massivement de ces collections. Ainsi, les données générées au sujet des JT alimenteront un site qui donnera une vision de l’activité médiatique des différentes chaînes de télévision, y compris des chaînes d’information continue19. Ce changement technique est donc aussi un changement culturel, qui suscitera de nouveaux enjeux. Le premier concerne la validation humaine des données issues de l’IA : quelles données souhaitera-t-on valider, suivant quel processus et à quelles fins ? Le second est apparu alors que nous construisions petit à petit l’équipe chargée de piloter ce nouveau système d’information. Les professionnels capables de manipuler autant de types de modèles physiques, logiques, conceptuels, intellectuels, que ce soit au niveau logique ou au niveau des bases physiques, sont encore peu nombreux. Nous sommes donc confrontés à une lacune dans la formation des professionnels des données.
Du professionnel de l’information au professionnel de la donnée
35Peu à peu, la démarche consistant à penser les organisations par la donnée, non plus à travers la dimension technique, mais à travers la modélisation et le traitement de la donnée, arrive au cœur de la réflexion sur l’architecture des systèmes d’information : il ne s’agit pas seulement d’une spécificité du secteur culturel et patrimonial. On a ainsi vu émerger le profil de data analyst : alors que le data scientist fait des algorithmes et le data ingénieur des infrastructures techniques, le data analyst fait le lien entre cette vision technique et la vision métier des données.
36Cette évolution n’est pas terminée, mais pose la question de l’identification des bons profils. Le data analyst est plus difficile à former que les data scientists, qui sont des mathématiciens, ou les data ingénieurs, qui sont des informaticiens. Il s’agit d’un profil hybride, puisque son rôle consiste à appliquer les technologies numériques dans un domaine métier particulier. Il doit donc à la fois être formé dans ce domaine, s’approprier les technologies numériques alors même que celles-ci deviennent de plus en plus diverses et complexes, et apprendre à modéliser : une compétence spécifique qui n’est pas maîtrisée par les ingénieurs informaticiens, qui ne sont pas formés à cela.
37Il faut donc réaffirmer l’importance des professionnels de l’information dans cette transformation. Tandis que les entreprises supprimaient les centres de documentation, les documentalistes n’ont pas toujours compris l’importance de s’affranchir du document au sens strict du terme et de creuser la question de la donnée, certes technique, mais face à laquelle ils ont des compétences spécifiques à apporter. Cette double tendance a été à l’origine d’une perte de compétence, que l’on pourrait aujourd’hui compenser en formant de nouveaux professionnels de la donnée, héritiers directs des professionnels de l’information ou de la documentation. À l’heure de former des jeunes professionnels à ces métiers, l’appellation « data analyst » permet d’ouvrir un dialogue avec les directions informatiques des entreprises et les SSII20. L’enjeu est de leur expliquer nos méthodes et nos convictions et, en échange, de leur demander quelles technologies enseigner à nos étudiants pour qu’ils trouvent leur place parmi les professionnels du système d’information, pas seulement en tant qu’assistants à la maîtrise d’ouvrage [AMOA], mais aussi en tant que véritables spécialistes de la donnée. C’est un travail de lobbying de longue haleine, d’autant que le marché n’a pas fini d’évoluer et qu’il sera nécessaire de s’adapter au fur et à mesure de la demande.
Notes de bas de page
1 Gautier Poupeau, « Les carcans de la pensée hiérarchique et documentaire » sur le blog Les petites cases, 2009, http://www.lespetitescases.net/carcans-de-la-pensee-hierarchique-et-documentaire-1 et http://www.lespetitescases.net/carcans-de-la-pensee-hierarchique-et-documentaire-2, consulté le 1er novembre 2022.
2 Pour une idée des enjeux des SI documentaires, cf. Gautier Poupeau, « La donnée : nouvelle perspective pour les bibliothèques », dans Emmanuelle Bermès (dir.), Vers de nouveaux catalogues, Paris, éd. du Cercle de la librairie, 2016, p. 159-171, https://www.cairn.info/vers-de-nouveaux-catalogues--9782765415138-page-159.htm, consulté le 1er novembre 2022.
3 Cette partie reprend en grande partie les éléments de l’article suivant : Gautier Poupeau, « Histoire(s) de notices », dans Lisette Calderan, Pascale Laurent, Hélène Lowinger et Jacques Millet, Le document numérique à l’heure du web, ADBS, p. 25-40, 2012, Sciences et techniques de l’information, https://hal.inria.fr/hal-00740295/, consulté en ligne le 1er novembre 2022.
4 Le Dublin Core est un format descriptif simple et générique créé en 1995 à Dublin (Ohio) par OCLC [Online Computer Library Center] et le NCSA [National Center for Supercomputing Applications], définition issue du site de BNF https://www.bnf.fr/fr/dublin-core.
5 Pour plus d’informations sur l’intérêt du web sémantique pour les professionnels de l’information, cf. Emmanuelle Bermès avec la collaboration d’Antoine Isaac et de Gautier Poupeau, Le Web sémantique en bibliothèque, Paris, éd. du Cercle de la librairie, 2013 ; ou Emmanuelle Bermès, « Web de données et bibliothèques : l’évolution du modèle d’agrégation des données », dans I2D – Information, données & documents, 2016/2, vol. 53, p. 37, https://www.cairn.info/revue-i2d-information-donnees-et-documents-2016-2-page-37.htm, consulté le 1er novembre 2022.
6 C’est l’approche que le modèle FRBR [Functional Requirements for Bibliographic Records/Fonctionnalités requises des notices bibliographiques], par exemple, s’est efforcé d’adopter pour s’affranchir d’une vision documentaire attachée à la description d’objets matériels et aller vers une représentation logique des contenus. FRBR est un modèle conceptuel prenant en compte quatre niveaux d’analyse d’un document : l’objet physique (item), les caractéristiques de sa publication (manifestation), les caractéristiques de son contenu intellectuel (expression), les caractéristiques de la création abstraite à laquelle il se rattache (œuvre). Définition inspirée de celle de la BnF (https://www.bnf.fr/fr/modeles-frbr-frad-et-frsad).
7 Optical Character Recognition [Reconnaissance optique de caractères].
8 La notion d’intertextualité, développée par Gérard Genette en 1982, désigne les modes de relations existant entre plusieurs textes. La métatextualité est la relation d’un texte qui commente un autre texte. Gérard Genette, Palimpsestes. La Littérature au second degré, Paris, Seuil, 1982.
9 Ina’STAT classifie en rubrique les sujets des JT et propose un suivi de l’évolution des thématiques abordées. La méthode utilisée s’appuie sur un thésaurus, les termes du sujet de JT sont automatiquement rattachés à la branche du thésaurus correspondant. Voir l’exposé de la méthode, sur le site de l’INAthèque : http://www.inatheque.fr/publications-evenements/ina-stat/ina-stat-methodologie.html.
10 L’informatique décisionnelle, ou Business Intelligence, centralise et consolide aussi les données d’entreprise pour créer des aides à la décision pour les dirigeants.
11 Sur les lacs de données stricto sensu, se reporter à la captation de la présentation d’Anne Laurent à la séance du séminaire Les nouveaux paradigmes de l’archive le 15 décembre 2020, sur le thème « Des lacs de données pour quelles archives ? ». https://nparchive.hypotheses.org/738.
12 Terme utilisé par Exalead, une société française créée en 2000 par François Bourdoncle et Patrice Bertin. Elle proposait une solution logicielle documentaire reposant sur la technologie des moteurs de recherche.
13 En réalité, le moteur de recherche est une base de données document d’un type particulier, optimisée pour la recherche plein texte. Il existe d’autres bases de données document, comme les bases de données XML ou Json par exemple.
14 Possibilité de faire face à une augmentation d’activité en ajoutant un serveur pour répartir la charge sur plusieurs machines, elle s’oppose à la scalabilité verticale qui impose de faire fonctionner l’application sur une seule machine.
15 Gautier Poupeau, « Au-delà des limites, que reste-t-il concrètement du Web sémantique ? », sur le blog Les Petites cases, http://www.lespetitescases.net/au-dela-des-limites-que-reste-t-il-concretement-du-web-semantique, consulté le 1er novembre 2022.
16 Description de la structure des données d’un système d’information et des relations existant entre elles.
17 Il s’agit d’un modèle entité-relation inspiré de Bibframe et du Cidoc-CRM.
18Traitement informatique dont on programme à l’avance l’exécution, souvent pour l’exécuter la nuit.
19 Gautier Poupeau, « En quoi l’intelligence artificielle constitue pour l’Ina une opportunité pour renforcer ses missions de valorisation et de conservation du patrimoine audiovisuel », Les Futurs fantastiques, Bibliothèque nationale de France, 10 décembre 2021, https://www.bnf.fr/fr/mediatheque/en-quoi-lintelligence-artificielle-constitue-pour-lina-une-opportunite-pour-renforcer, consulté le 1er novembre 2022.
20 Sociétés de service en ingénierie informatique.
Auteur
-
Gautier Poupeau
Directeur de l’infrastructure des données, service du numérique du ministère de la Culture.
De 2014 à 2022, Gautier Poupeau a assuré les fonctions de Data Architect puis de responsable adjoint du département Data de l’Institut national de l’audiovisuel.
Le texte seul est utilisable sous licence Licence OpenEdition Books. Les autres éléments (illustrations, fichiers annexes importés) sont « Tous droits réservés », sauf mention contraire.
Le consulat de France à Cadix
Institution, intérêts et enjeux (1666-1740)
Anne Mézin et Anne Pérotin-Dumon (dir.)
2016
Archives et communisme(s) : l’avant-guerre (1919-1943)
Nouveaux outils, nouvelles archives
Sylvie Le Clec’h, Christian Oppetit et Serge Wolikow (dir.)
2016
Connaître les dénaturalisés de Vichy
La base Dénat, un nouvel outil et ses exploitations
Thomas Lebée et Annie Poinsot (dir.)
2019
Les archives iconographiques et audiovisuelles de la Reconstruction en France, de 1940 aux années 1960
Boris Labidurie et Christel Palant (dir.)
2023
Éducation populaire : engagement, médiation, transmission (XIXe-XXIe siècles)
Jean-Charles Buttier, Clothilde Roullier et Agnès Sandras (dir.)
2022
Les nouveaux paradigmes de l'archive
Claire Scopsi, Clothilde Roullier, Martine Sin Blima-Barru et al. (dir.)
2024