Ce que les éphémères ont à dire : extraction et structuration de données patrimoniales

Ce texte est une ébauche de réflexion sur le sujet.

Qu’est ce qu’un éphémère ?

Un éphémère (ephemera) est le terme archivistique pour “désigner des documents du quotidien créés pour un usage limité ou temporaire qui, en théorie, devaient être jetés après leur utilisation”¹. Ces documents sont pourtant aujourd’hui conservés pour leur valeur historique et culturelle. L’information y est mise en page, souvent au sein d’une composition illustrative originale. Ce sont des documents graphiques à part entière, où le sens circule autant par le texte que par l’image.

Les ephemera échappent souvent aux catégories classiques et comprennent une grande variété d’imprimés et d’objets papier ² :

• communication : dépliants, tracts, catalogues de vente et affiches.
• Événementiel : billets de spectacle, programmes de théâtre, cartons d’invitation et menus.
• Vie quotidienne : cartes de visite, timbres, calendriers de poche et étiquettes

Si dans mon travail je me concentrerai sur les éphémères des expositions, ce travail est voué à apporter un support à tout autre type de collection.

Pourquoi vouloir extraire les données des éphémères ?

Ces documents concentrent, sur quelques pages, l’essentiel des informations descriptives d’un événement : qui, quoi, quand, où, avec qui. C’est une donnée riche, mais brute et non structurée. De plus, les éphémères sont souvent la seule trace documentaire d’événements moins mainstream, plus marginalisés : soirées communautaires, expositions militantes, festivals associatifs, galeries.

En 2016, Séverine Montigny esquisse des pistes pour le traitement et la diffusion de ce type de collections. Elle conclut :

Masse documentaire, accroissement continu, variété typologique, fragilité rendent compliquée la gestion d’une collection d’éphémères. Mais il existe des modèles et des pratiques pour les classer et les signaler. À l’heure où la rétroconversion des imprimés et des manuscrits s’achève, en parallèle des fonds iconographiques auxquels ils sont parfois mêlés, il importe de révéler le potentiel de ces ensembles patrimoniaux originaux extrêmement riches pour l’histoire locale, et d’inventer des moyens de les valoriser.²

Ces documents restent difficiles à documenter : leur mise en page, très variable d’un objet à l’autre, rend la lecture en lot particulièrement ardue. Renaud Bardez a présenté le projet d’ART4LAB lors de la Journée d’étude “Faire et défaire les collections : politiques d’acquisition et d’aliénation dans les archives et les musées”³. Ayant récupéré, aux archives de l’Université libre de Bruxelles, une grande quantité d’éphémères provenant principalement de collections de musées et de galeries bruxelloises, il travaille avec Michèle Graye et des étudiant·es en histoire de l’art pour extraire manuellement les données de ces documents dans un fichier CSV. Devant la difficulté de numériser correctement ces documents, l’extraction manuelle est apparue comme la solution la plus rapide et la plus simple pour mener ce travail.

L’objectif de mon projet de recherche est double :

• Récupérer automatiquement l’information pour créer de la donnée structurée, exploitable et interrogeable.
• Rendre ces données liables à d’autres jeux de données du patrimoine (Linked Open Data).

Ce projet pourrait intéresser les partenaires suivants :

• Archives de la critique d’art, Rennes
• Artexte, Montréal
• Archives lesbiennes, Montréal
• Bibliothèque de l’Université libre de Bruxelles

Méthodo pragmatique

Le corpus de travail pour débuter le travail rassemble une cinquantaine d’éphémères récupérés sur le terrain, provenant de différents types d’institutions et couvrant différents types d’événements.

La contrainte technique posée dès le départ : une solution open-source et respectueuse de l’environnement, qui évite la duplication de traitements et de stockage.

Pipeline de départ

Le pipeline se déroule en cinq étapes :

• Capture (Numérisation)
• Extraction (Détection de mise en page & OCR)
• Validation (Correction humaine ou automatisée)
• Structuration (Mapping vers CIDOC-CRM humaine ou automatisée)
• Archivage et diffusion

Mapping hypothétique des données en CIDOC-CRM

Le mapping des données extraites suit les propositions déjà établies dans la littérature, notamment celles de SARI ou de Carboni, avec des classes centrales comme E7 Activity (l’événement), E53 Place (le lieu), E22 Human-Made Object (le document lui-même), E78 Curated Holding (le fonds d’archives) et E21 Person (les personnes impliquées). Cette partie sera le sujet d’un deuxième article.

Batterie de tests

Test en ocr simple de conversion en texte

Première technique, la plus grand public : passage du PDF dans Google Docs. Sur l’exemple d’un éphémère du MUCEM, l’OCR fonctionne plutôt bien pour la reconnaissance pure du texte : les mots sont entiers, cohérents, et Google Docs parvient même à repérer les titres. Mais on perd complètement l’organisation visuelle et les images : le texte est aplati, la donnée déstructurée. Impossible, dans ce format, de savoir à quelle information un mot se rattache, ni à qui il est relié.

Exemple illustrant bien les problématiques visées (texte sur image, information dispersée) sans être trop complexe pour un premier test.

Test pipeline extraction de mise en page puis OCR (Alice Truc)

Deuxième piste, sur les conseils d’Alice Truc, une collègue de laboratoire dont le projet de thèse porte sur l’analyse et l’édition numérique de la revue Opus International (1967-1995). Elle a développé une méthodologie pour l’extraction de données, et je l’ai contactée car elle rencontrait le même type de difficulté d’OCR, en raison d’une mise en page différente selon les articles et de la présence d’images. Elle m’a partagé son notebook Google Colab pour faire des tests. La méthode consiste à identifier d’abord les zones de mise en page (layout detection) avec YOLOv10, avant de lancer un OCR Tesseract sur chacune d’elles. La sortie est une donnée structurée en JSON.

Concrètement, le notebook s’appuie sur YOLOv10b, pré-entraîné sur le jeu de données DocLayNet (poids du dépôt moured/YOLOv10-Document-Layout-Analysis, exécutés via THU-MIG/yolov10), pour détecter cinq types de zones : Caption, Picture, Section-header, Text et Title. Chaque zone est ensuite passée à Tesseract via pytesseract, avec le pack linguistique français (tesseract-ocr-fra). Le test a été mené sur Google Colab (Google Drive monté comme stockage), avec des seuils de détection conf=0.1 et iou=0.2. Pour chaque image, le notebook produit un JSON listant les zones détectées (label, coordonnées, texte extrait), une image annotée, et les crops (ROI) correspondant à chaque zone.

Exemple après annotation

Exemple après OCR en json - sur la page de couverture

{
    "image_name": "page_001.png",
    "detections": [
        {
            "index": 1,
            "label": "Text",
            "coordinates": [
                179,
                7776,
                1006,
                8050
            ],
            "extracted_text": "Mai/Septembre\n2026",
            "roi_filename": "page_001_roi_1.png"
        },
        {
            "index": 2,
            "label": "Page-footer",
            "coordinates": [
                2254,
                7747,
                3592,
                8027
            ],
            "extracted_text": "Rendez-vous réguliers 27\nEn famille 33",
            "roi_filename": "page_001_roi_2.png"
        },
        {
            "index": 3,
            "label": "Picture",
            "coordinates": [
                18,
                16,
                3764,
                7114
            ],
            "extracted_text": "",
            "roi_filename": "page_001_roi_3.png"
        },
        {
            "index": 4,
            "label": "Page-footer",
            "coordinates": [
                179,
                7776,
                1006,
                8050
            ],
            "extracted_text": "Mai/Septembre\n2026",
            "roi_filename": "page_001_roi_4.png"
        },
        {
            "index": 5,
            "label": "Text",
            "coordinates": [
                1174,
                7770,
                1836,
                8038
            ],
            "extracted_text": "Expositions\nÉvénements",
            "roi_filename": "page_001_roi_5.png"
        },
        {
            "index": 6,
            "label": "Text",
            "coordinates": [
                2254,
                7747,
                3592,
                8027
            ],
            "extracted_text": "Rendez-vous réguliers 27\nEn famille 33",
            "roi_filename": "page_001_roi_6.png"
        },
        {
            "index": 7,
            "label": "Section-header",
            "coordinates": [
                48,
                88,
                3719,
                1306
            ],
            "extracted_text": "",
            "roi_filename": "page_001_roi_7.png"
        },
        {
            "index": 8,
            "label": "Section-header",
            "coordinates": [
                44,
                80,
                3705,
                1315
            ],
            "extracted_text": "",
            "roi_filename": "page_001_roi_8.png"
        }
    ]
}

Résultat : Mitigé.

• Positif : La détection de layout découpe efficacement l’image en zones distinctes, préservant une partie de la structure.
• Négatif : L’OCR reste limité sur les textes intégrés aux images ou les typographies non standard. Surtout, chaque zone est traitée isolément : les relations spatiales (un titre au-dessus d’une date, un nom sous un logo) sont perdues. Or, c’est précisément cette hiérarchie visuelle qui donne son sens à l’information.

Analyse des résultats : comparaison IA vs vérification humaine

Pour évaluer la pertinence du pipeline et tester le mapping avec Cidoc-CRM, les fichiers JSON extraits ont été soumis à une IA (Euria) avec un prompt spécialisé CIDOC-CRM, puis comparés à une vérification humaine approfondie.

Protocole de test

Prompt soumis à l’IA

Tâche : Analysez les fichiers JSON fournis ci-dessous contenant des données brutes sur des expositions. Extrayez les informations pertinentes et mappez-les strictement vers les classes et propriétés du modèle CIDOC-CRM.

Instructions de mappage spécifiques aux expositions :
1. Identifiez l'exposition elle-même comme une instance de E7_Activity (ou E5_Event selon le contexte temporel révolu).
2. Mappez le titre de l'exposition à P140i was subject of -> E35_Title.
3. Mappez les dates de début et de fin à P4_has_time-span -> E52_Time-Span (avec P82a_begin_of_the_begin et P82b_end_of_the_end).
4. Mappez le lieu de l'exposition (musée, galerie, adresse) à P7_took_place_at -> E53_Place. Si des détails sur le bâtiment existent, utilisez E41_Appellation pour le nom du lieu.
5. Mappez les organisateurs (institutions, commissaires) à P14_carried_out_by -> E74_Group (pour les institutions) ou E21_Person (pour les individus), avec leurs rôles précisés si possible via P14.1_in_the_role_of.
6. Mappez les œuvres présentées (si listées) comme E22_Man-Made_Object liées à l'exposition via P12i was present in.
7. Gérez les descriptions et résumés via P3_has_note.

Contraintes de sortie :
- Présentez le résultat sous forme de tableau clair avec les colonnes : "Donnée Source (JSON)", "Concept CIDOC-CRM (Classe/Propriété)", "Valeur Extrait", et "Commentaire/Uncertainty".
- Si une information requise par le modèle CIDOC-CRM est absente du JSON, indiquez "Non disponible" dans la colonne valeur.
- Ne faites aucune supposition sur les données manquantes.
- Utilisez la terminologie exacte du CIDOC-CRM (ex: E7_Activity, P7_took_place_at).

Résultats de la requête

Voici l'analyse et le mappage CIDOC-CRM des données extraites de vos fichiers JSON concernant les expositions du Mucem.

Les données ont été consolidées pour identifier trois expositions distinctes mentionnées dans les documents : **« Bonnes Mères »**, **« Ferdinandea, l'île éphémère »** (Clément Cogitore), et **« Mossi Traoré, la mode aussi »**. Une quatrième entité, le **CCR (Centre de Conservation et de Ressources)**, est traitée comme une exposition permanente ou un lieu d'exposition spécifique.

##### Tableau de Mappage CIDOC-CRM

| Donnée Source (JSON) | Concept CIDOC-CRM (Classe/Propriété) | Valeur Extrait | Commentaire/Uncertainty |
| :--- | :--- | :--- | : |
| **Exposition : Bonnes Mères** | | | |
| `page_002`: "Bonnes Meres" (Section-header) | **E7_Activity** (Instance: Exposition_Bonnes_Meres) | Bonnes Mères | Identifiant de l'événement. |
| `page_002`: "Bonnes Meres" | **E35_Title** via P140i was subject of | Bonnes Mères | Titre officiel. |
| `page_002`: "Jusqu'au 31 août 2020" (OCR error likely 2026) | **E52_Time-Span** via P4_has_time-span | Fin : 2026-08-31 (Hypothèse) | Le JSON indique "2020", mais le contexte (mai/juillet 2026) suggère une erreur OCR. La date de début n'est pas explicite dans l'extrait, seulement "Jusqu'au". |
| `page_002`: "Mucem J4", "fort Saint-Jean" | **E53_Place** via P7_took_place_at | Mucem J4, Fort Saint-Jean | Lieux multiples identifiés. |
| `page_002`: "Mucem", "Maison Christofle" | **E74_Group** via P14_carried_out_by | Mucem, Maison Christofle | Mucem (organisateur), Christofle (partenaire exceptionnel). |
| `page_002`: "réplique monumentale de la Bonne Mère" | **E22_Man-Made_Object** via P12i was present in | Réplique de la Bonne Mère | Objet spécifique mentionné comme présent. |
| `page_002`: "exposition immersive et solaire consacrée aux images, récits et luttes associés à la maternité..." | **E33_Linguistic_Object** via P3_has_note | Description thématique sur la maternité en Méditerranée. | Résumé extrait du texte descriptif. |
| **Exposition : Ferdinandea, l'île éphémère** | | | |
| `page_003`: "rerdinandea, l'île éphémère" (OCR: Ferdinandea) | **E7_Activity** (Instance: Exposition_Ferdinandea) | Ferdinandea, l'île éphémère | Titre corrigé de l'erreur OCR "rerdinandea". |
| `page_003`: "Clément Cogitore" (Section-header) | **E21_Person** via P14_carried_out_by | Clément Cogitore | Artiste principal / Commissaire. |
| `page_003`: "Jusqu'au 16 novembre 2026" | **E52_Time-Span** via P4_has_time-span | Fin : 2026-11-16 | Date de fin claire. Date de début non disponible dans l'extrait. |
| `page_003`: "Mucem J4", "Mucem fort Saint-Jean" | **E53_Place** via P7_took_place_at | Mucem J4, Fort Saint-Jean | Lieux mentionnés pour les événements liés. |
| `page_003`: "films et photographies" | **E22_Man-Made_Object** via P12i was present in | Films, Photographies | Types d'œuvres mentionnés ("fiction expérimentale"). |
| `page_003`: "A enima à napnle of insomniacs, 2022" (OCR error) | **E22_Man-Made_Object** via P12i was present in | Œuvre spécifique (Titre illisible) | OCR dégradé. Probablement une œuvre de Clément Cogitore (2022). |
| `page_003`: "En Juin 1857, l'activité volcanique..." | **E33_Linguistic_Object** via P3_has_note | Contexte historique de l'île Julia/Ferdinandea. | Note descriptive sur le sujet de l'exposition. |
| **Exposition : Mossi Traoré, la mode aussi** | | | |
| `page_003`: "Mossi Traoré, la mode aussi" | **E7_Activity** (Instance: Exposition_Mossi_Traore) | Mossi Traoré, la mode aussi | Titre de l'exposition. |
| `page_003`: "Mossi Traoré" | **E21_Person** via P14_carried_out_by | Mossi Traoré | Artiste / Styliste. |
| `page_003`: "Jusqu'au 16 novembre 2026" (Contexte voisin) | **E52_Time-Span** via P4_has_time-span | Fin : 2026-11-16 (Probable) | La date est spatialement proche dans le JSON, probablement commune à l'exposition Cogitore ou spécifique. Incertitude forte. |
| `page_003`: "Chemise de femme. Croatie, avant 1966" | **E22_Man-Made_Object** via P12i was present in | Chemise de femme (Croatie, avant 1966) | Objet de collection dialoguant avec l'exposition. |
| `page_003`: "couture comme terrain d'expérimentation..." | **E33_Linguistic_Object** via P3_has_note | Description du dialogue entre mode populaire et collections. | Résumé thématique. |
| **Lieu / Exposition Permanente : CCR** | | | |
| `page_006`: "Champ de visions" | **E7_Activity** (Instance: Install_Champ_de_visions) | Champ de visions | Installation permanente. |
| `page_006`: "Mathilde Rosier" | **E21_Person** via P14_carried_out_by | Mathilde Rosier | Artiste de l'installation. |
| `page_006`: "installation permanente" | **E52_Time-Span** via P4_has_time-span | Permanente | Pas de dates spécifiques. |
| `page_006`: "Centre de Conservation et de Ressources (CCR)", "Belle de Mai" | **E53_Place** via P7_took_place_at | CCR, Quartier de la Belle de Mai | Lieu spécifique distinct du J4. |
| `page_006`: "cinquantaine d'yeux de verre" | **E22_Man-Made_Object** via P12i was present in | Yeux de verre (Installation) | Composants de l'œuvre. |
| `page_005`: "Lappartement témoin" | **E7_Activity** (Instance: Expo_Appart_Temoin) | L'appartement témoin | Exposition permanente au CCR. |
| `page_005`: "Jusqu'au 30 juin 2026" | **E52_Time-Span** via P4_has_time-span | Fin : 2026-06-30 | Date limite mentionnée pour l'accès ou une spécificité. |
| `page_005`: "plus de 1 200 objets et documents", "guillotine" | **E22_Man-Made_Object** via P12i was present in | 1200 objets, Guillotine | Objets notables mentionnés dans la description. |

##### Observations sur la qualité des données (OCR et Structure)

1.  **Erreurs OCR critiques** : Plusieurs dates et noms propres sont altérés (ex: "2020" au lieu de "2026", "rerdinandea" pour "Ferdinandea", "obiets" pour "objets"). Un post-traitement de validation humaine est requis avant l'injection dans un système de production.
2.  **Ambiguïté temporelle** : Les dates de début sont souvent absentes des extraits JSON, seules les dates de fin ("Jusqu'au...") sont présentes. Le modèle CIDOC-CRM nécessite un `E52_Time-Span` complet ; ici, seule la borne de fin (`P82b_end_of_the_end`) est souvent disponible.
3.  **Lieux multiples** : Les expositions se déroulent souvent sur deux sites distincts ("Mucem J4" et "Fort Saint-Jean"). Dans le modèle CIDOC-CRM, il est préférable de créer deux instances de `E53_Place` liées à la même `E7_Activity` via la propriété `P7_took_place_at`.
4.  **Distinction Exposition/Événement** : Le JSON mélange des descriptions d'expositions (durées longues) et des événements ponctuels ("Nuit européenne des musées", "Spectacle"). Le mappage ci-dessus s'est concentré sur les entités "Exposition" comme demandé, mais les événements ponctuels devraient idéalement être modélisés comme des `E5_Event` distincts liés aux expositions via `P9_consists_of` ou similaires.

Vérification visuelle humaine

Euria a corrigé les fautes d’OCR par déduction.

Programmation du MUCEM de Mai à Septembre 2026 Concernant les expositions il y a :

• Bonnes Mères
  • Pas de dates de début en effet. jusqu’au 31 aout 2026
  • Partenaires : Caisse d’Épargne CEPAC et d’ONET [info manquée]; Maison Christofle
  • La réplique monumental est une statue, qui fait partie de l’exposition
  • Lieu : au MUCEM J4 [pas au fort st jean]
  • • evenements liés
  • pas de nom de curator
• Clément Cogitore
  • sous titre Ferdinandea, l’île éphémère
  • Pas de dates de début en effet. jusqu’au 20 sept 2026
  • lieu : Mucem Fort Saint-Jean
  • nom associé : Clément Cogitore, artiste
  • • evenements liés
• Mossi Traoré, la mode aussi
  • nom associé : Mossi Traoré, couturier?
  • Lieu : au MUCEM J4
  • Pas de dates de début en effet. jusqu’au 16 nov 2026
  • • evenements liés
• Le musée mène l’enquête
  • sous-titre : Comment fait-on parler les objets ?
  • lieu : Mucem Centre de Conservation et de Ressources
  • date : pas de date de début. Jusqu’au 31 juillet 2026
• Champ de visions
  • lieu : Mucem Centre de Conservation et de Ressources
  • date : pas de dates, installation permanente
  • partenariat : CIRVA
• Populaire ?
  • sous-titre : Les trésors des collections du Mucem
  • date : pas de dates, indiquée comme Exposition permanente
  • 1200 expôts, dont une guillotine
  • Lieu : au MUCEM J4
  • mediation : parcours audio pour enfant
  • • evenements liés
  • type : exposition permanente, exposition de collection
  • considéré dans sommaire comme rendez-vous régulier
• Méditerranées
  • sous-titre : Inventions et représentations
  • Lieu : au MUCEM J4
  • date : pas de dates, indiquée comme Exposition permanent
  • • evenements liés
  • type : exposition permanente, exposition de collection
  • partenaire : Mutuelles du Soleil et Volotea
  • considéré dans sommaire comme rendez-vous régulier
• L’appartement témoin
  • lieu : Mucem Centre de Conservation et de Ressources
  • pas de date
  • considéré dans sommaire comme rendez-vous régulier

Comparaison

L’analyse met en évidence la force de l’IA sur la structuration sémantique immédiate, mais aussi ses limites face aux ambiguïtés spatiales et aux erreurs d’OCR que l’œil humain corrige par contexte global.

Conclusion de l’analyse : Le pipeline actuel (Layout Detection + OCR + IA) est prometteur pour une pré-structuration massive, mais il nécessite impérativement une étape de validation humaine ou un algorithme de réassemblage contextuel (cross-page analysis) pour corriger les erreurs d’attribution spatiale (lieux) et temporelle (dates de fin vs dates d’événements).

Prompt optimisé

Je cherche des solutions pour rendre la requête moins energivore. Une première solution serait d’ajouter au prompt : “Réponds UNIQUEMENT par un objet JSON valide suivant ce schéma : {expositions: [{titre, lieu, date_fin, personnes}]}. Aucun texte explicatif.”

Au lieu de demander l’extraction ET le mappage en une seule requête massive (qui risque d’être imprécise et longue), découpez le processus :

• Requête 1 (Extraction structurée) : “Extrais uniquement les entités nommées (Titres, Dates, Lieux, Personnes) de ce JSON et présente-les sous forme de liste nettoyée.” (Tâche simple, faible énergie).
• Requête 2 (Mappage CIDOC) : “Voici la liste nettoyée [Coller le résultat 1]. Mappe-la vers CIDOC-CRM selon ce modèle JSON.” (Tâche mécanique, très faible énergie).

Prompt :

Rôle : Moteur de transformation de données vers CIDOC-CRM.
Tâche : Convertir la liste d'entités extraites ci-dessous en un objet JSON strict.

Règles strictes :
1. Aucune explication textuelle, aucun commentaire, uniquement le JSON.
2. Si une donnée est ambiguë, utilise la valeur "INCONNU". Ne devine pas.
3. Utilise ce schéma de sortie exact :
{
  "expositions": [
    {
      "titre": "String",
      "classe_activite": "E7_Activity",
      "date_fin": "YYYY-MM-DD",
      "lieux": ["String"],
      "acteurs": [{"nom": "String", "role": "E21_Person ou E74_Group"}]
    }
  ]
}

Exemple de comportement attendu :
Entrée : "Titre: Bonnes Mères, Lieu: Mucem J4, Fin: 31 août 2026"
Sortie : {"expositions": [{"titre": "Bonnes Mères", "classe_activite": "E7_Activity", "date_fin": "2026-08-31", "lieux": ["Mucem J4"], "acteurs": []}]}

Vision-language model (VLM)

Cette section relève de la prospective, et non du test. Contrairement aux tests 1 et 2, aucun VLM n’a encore été exécuté sur mon corpus d’éphémères : ce qui suit est une hypothèse de travail, construite à partir de la littérature et des caractéristiques annoncées des modèles, à confronter à un test réel avant toute adoption.

Le pivot envisagé consisterait à remplacer un pipeline OCR + LLM (deux étapes, avec perte d’information spatiale, comme observé dans le Test 2) par un VLM (vision-language model) unique, qui traiterait l’éphémère comme un tout cohérent, à la manière dont le ferait un archiviste humain.

Cette piste s’appuie sur une tendance observable dans les chatbots grand public : les modèles semblent pouvoir lire directement les documents qui leur sont fournis. Contrairement à l’approche testée précédemment (YOLO pour la zone, Tesseract pour le texte, LLM pour le sens), le VLM effectuerait une compréhension multimodale native (du moins en théorie, à ce stade de ma réflexion).

Le vision-language model (VLM) est un modèle d’IA qui traite conjointement des données visuelles et textuelles pour comprendre, relier ou générer du contenu multimodal (Kotsiantis et al., 2026 ⁵).

Ces gains restent, à ce stade, des hypothèses à vérifier plutôt que des résultats observés. :es VLM, bien que plus performants, sont certainement plus lourds en calcul qu’un OCR simple. Le compromis performance/énergie sera un enjeu majeur de mon prochain test.

Le VLM est un terme générique recouvrant plusieurs technologies distinctes :

“(i) classical VLMs (perception/retrieval/grounding), (ii) MLLMs that connect a vision encoder to an LLM-style generator for open-ended instruction following and (iii) agentic multimodal systems that integrate external tools (retrievers, knowledge graphs, planners, OCR and memory).”⁵

Pour ce projet, le type (i) des VLM classiques orientés perception, recherche et grounding, qui repère un objet ou une couleur dans une image présenterait moins d’intérêt que les types (ii) et (iii) : les MLLM à forte capacité d’OCR et de compréhension documentaire, et les systèmes agentiques multimodaux intégrant des outils externes (récupération d’information, graphes de connaissances, planification, OCR, mémoire), potentiellement pertinents pour construire le graphe CIDOC-CRM.

Comment les VLM fonctionnent : Indicative architecture of a Visual Language Model (VLM), showing the flow from multimodal inputs through the core fusion layers to diverse outputs. (Kotsiantis et al., 2026 ⁵, p. 32433).

Cette approche VLM apparaît non seulement plus robuste techniquement pour ces documents visuels, je vais donc me renseigner.