De préférence des images jpg ou png en 300dpi. Le critère de qualité est la très bonne lisibilité des textes. Si les textes sont lisibles, mais difficilement, c'est insuffisant pour que les logiciels d'OCR fonctionnent bien.

Le format png comme le gif a l'avantage d'être compressé sans perte. Et l'inconvénient de créer des gros fichiers.

Le png peut-être légèrement avantageux (pas trop gros fichier) par rapport au jpeg, lorsque le fond de l'image est très uniforme. Sinon, autant rester en jpg.

Cela n'a pas de sens d'enregistrer un jpeg en png. On apporte pas d'information et on obtient un plus gros fichier.

Le gif n'est pas recommandé (pas pour la qualité mais pour la pérennité)

Deux scripts python différents sont utilisés pour d'abord transformer les images en pdf.
Un qui est bien adapté aux coupures de presse scandirjpg2df, et un qui est bien adapté aux revues scandir2pdf.
Le but est de réduire les opérations manuelles de préparation des fichiers.

L'idéal est d'inclure 'EN HAUT' de l'image le nom du journal, la date formatée et le numéro de la page comme ci dessus ^

L'intérêt est que ce texte sera inclus dans l'OCR et pourra être recherché. Faites très attention que cela ne dégrade pas encore plus l'image (re compression)

Si plusieurs articles sont regroupés sur une seule page (non recommandé), bien placer “le nom du journal, la date formatée et le numéro de la page” au dessus de chaque article. Pas d'acrobaties avec des flèches vers la droite ou la gauche. Ne pas placer des articles à coté les uns des autres. Mais plutôt au dessus les uns des autres.

Si votre document est déjà sous forme de pdf, autant ne rien à faire pour ne pas dégrader plus l'image. Mais attention, cela ne veut pas dire que c'est le format préféré. S'assurer surtout de sa très bonne lisibilité.

Nommage : il y a un choix à faire.

• Si vous décidez de vouloir nommer les fichiers suivant les règles, alors cela signifie que tout le lot devra être nommé manuellement.
• Si vous décidez de ne rien nommer, cela sera fait automatiquement après le traitement par l'IA en utilisant les informations extraites.

Ce qui peut pousser à nommer manuellement : peu de fichiers, temps libre infini, ou bien scans de très mauvaise qualité au point qu'il y a de bonnes chances que l'ocr échoue.

Le script de conversion en pdf pour les coupures de presse (scandirjpg2pdf) fait l'hypothèse que par défaut (c'est à dire en général), à chaque coupure de presse correspond une seule image. Mais il peut aussi traiter les autres cas.

Il traite aussi le cas ou une coupure de presse s'étale sur plusieurs images, mais il faut lui préciser, il ne peut pas deviner. Cf ci dessous. Dans ce cas, le nom des images est peu important, si ce n'est pour aider à l'ordonnancement des pages. C'est le nom du répertoire qui sera important et va déterminer le nom du pdf généré.
Dernier cas : avoir une image qui contient plusieurs coupures de presse est aussi gérable automatiquement (traité à ce stade comme une seule coupure). C'est à l'étape d'IA, plus tard que la détection de la présence de plusieurs articles est faite par chatgpt, le json généré contiendra plusieurs entrées. Vous remarquerez que dans ce cas, le nom du fichier n'est plus bijectif avec le contenu. C'est ok, car c'est le json qui a ce role.

Si il y a plusieurs articles dans le même journal à la même date en plusieurs images, utiliser un nommage avec un index par exemple. En nommage automatique ce n'est pas problématique non plus.

Donc, de préférence, un fichier image par article/coupure de presse. Chaque fichier nommé optionnellement. Dans ce cas, il n'a pas besoin d'être dans un répertoire dédié. Tout peut-être à la racine.

Si un des articles s'étale sur plusieurs pages, plusieurs images, alors, ses images doivent être regroupées dans un sous répertoire à nommer optionnellement selon les règles de nommage. Dans ce cas, le nom des images est peu important, si ce n'est pour aider à l'ordonnancement des pages. C'est le nom du répertoire qui sera important et va déterminer le nom du pdf généré.

• Ce qui permet aux traitements automatiques de savoir que les images d'un répertoire doivent être regroupées est la présence dans le répertoire d'un fichier multi.txt (de contenu sans importance, il peut être vide). le pdf généré sera créé dans le répertoire parent.
• L'ordre des fichiers images au final dans le pdf suit l'ordre alphabétique des nom des fichiers image

On peut très bien avoir un mix de répertoires avec et sans multi.txt. Les contenus des répertoires sans multi.txt seront traités localement, le pdf de chaque jpg restera dans le repertoire du jpg.

Si un sous répertoire avec multi.txt porte le même nom qu'un des fichiers image du répertoire au dessus, cela va créer un conflit puisqu'on va essayer de créer deux pdf avec le même nom. Donc, il faut veiller à repérer ce genre de problème. Ce problème est déjà arrivé plusieurs fois. (Actuellement le script ne fait pas cette vérif)

De préférence des images jpg en 300dpi avec un taux de compression faible. Le critère de qualité est la très bonne lisibilité des textes.

Les images sont à placer dans un répertoire par exemplaire de revue.

Les post traitements automatiques regrouperont les images en un seul pdf qui prendra le nom du répertoire et sera placé dans le répertoire au dessus. Les pdf sont constituées sans perte de qualité. Les images y sont stockées telles quelles. Pas de recompression effectuée.

En conservant les images, et en contrôlant la génération des pdf purs (sans ocr), on se prémunit des alterations par des outils tiers. Chaque fois que les outils d'OCR progresseront, on pourra en profiter.

Les fichiers image seront intégrés dans le pdf suivant l'ordre alphabétique du nom des fichiers images.

Il s'agit ici de répondre à la problématique de la conservation non pas du contenu des fichiers, mais des noms des fichiers et des répertoires qui les contiennent.

Ça évite des situations où par exemple un fichier devient : no_l___l_attaque.txt

alors que le fichier d'origine s'appelait : NOËL À L'ATTAQUE.TXT

si le fichier s'était nommé dès le départ : noel_a_l_attaque.txt, il n'aurait pas été altéré.

Le problème se situe à plusieurs niveaux :

• risque de perte d'informations lors de transferts ou recopies d'un système vers un autre. En raison d'incompatibilités du système de transfert ou bien du système cible.
• risque de perte d'informations en cas de certains types de crashs.

Avoir toute liberté dans le nommage signifie en gros :

• pouvoir choisir des noms de fichiers aussi long que voulus
• pouvoir mettre tous les caractères que le système actuel utilise : y compris ceux qui sont à problèmes : espace, accents, caractères spéciaux, points.

On aimerait bien avoir toute liberté sur les nommages, mais je recommande de volontairement restreindre les possibilités.

Il y a aussi une autre motivation envisageable : assurer l'uniformité de l'apparence des noms de fichiers. Par exemple, se limiter au lettres minuscules, ou bien toujours commencer un nom de fichier par une majuscule.

Voici la meilleure recommandation que je puisse faire, fruit d'années d'expérience en informatique :

• se limiter à des noms de 64 caractères ou moins
• interdiction absolue d'utiliser le caractère ' ' : espace
• n'utiliser aucun caractère autre que les caractères de base ASCII dans la liste suivante :
  • chiffres de '0' à '9'
  • lettres de 'a' à 'z'
  • lettres de 'A' à 'Z'
  • '_' tiret bas (fait office d'espaces)
  • '-' tiret

Oui en effet, il est interdit d'utiliser les caractères accentués.

Je pourrais être plus restrictif, pour donner un aspect plus léché au fond, mais ce n'est pas nécessaire. Au delà, trop de personnes ne font pas l'effort de respecter les règles, juste par flemme ou étourderie.

Pour commencer, il est possible de faire un renommage automatique de tout ce qui existe déjà pour respecter ces règles. (par un programme informatique, un script existant.)

Les noms de répertoire doivent-être aussi bref que possible. Les systèmes de fichiers Windows ont encore des limitations sur la longueur de chemin complet des fichiers à 255 caractères (nom du fichier inclus) Il est facile de dépasser le maximum autorisé. Au delà de 255 caractères, on peut avoir des pertes de fichiers (pas transférés, ignorés) ou des situations inextricables.

• S'ajoute à la liste précédente un seul caractère qui ne doit apparaître qu'une fois : le point '.'
  

Il ne sert que de séparateur avant les (en général 3) caractères de l'extension du fichier (.doc, .txt, .pdf, etc…)

Le nom d'un fichier n'est pas sensé décrire ce qu'il contient. C'est à la base de données du fond de la faire. Si bien que ces contraintes ne dégradent pas vraiment le contenu du fond.

Exemple de fonds respectant ces contraintes de nommage : https://sceau-archives-ovni.org/fonds/

Les noms de fichiers doivent-être aussi bref que possible. Ils ne doivent pas servir à donner d'autres indications qu'une identification sans ambiguïté du document. Les systèmes de fichiers Windows ont encore des limitations sur la longueur de chemin complet des fichiers. Il est facile de dépasser le maximum autorisé. Il faut aussi chercher à atteindre la plus grande uniformité dans les nommages.

Format pour la datation complete:

AAAA-MM-JJ

Si le jour du mois n'est pas connu :

AAAA-MM-xx

ou si seul le mois est pertinent

AAAA-MM

Si le mois n'est pas connu ou si seule l'année est pertinente :

AAAA

ou

AAAA-xx

ou

AAAA-xx-xx

C'est comme ci dessus, avec un _ ajouté à la fin.

Si vous avez déjà des dates au format :

JJ-MM-AAAA ou AAAA_MM_JJ ou JJ_MM_AAAA ou AAAA/MM/JJ et autres

ne passez pas votre temps à renommer en AAAA-MM-JJ. le renommage est fait de façon automatique.

Même si votre date n'est pas au début du fichier, pas la peine de la déplacer, cela est fait automatiquement (s'il n'y en a pas déjà une).

Par contre, si vous avez des dates avec des mois en texte, là ça mérite renommage manuel par vous.

De bloqué, en gros, nommage fichier : il y a le format et position de la date _ suivi du nom du journal _ potentiellement fini par un numéro de page px et c'est à peu près tout ce qui est assez stabilisé.

Cas avec deux articles dans le même journal sur deux pages différentes,

1976-10-11_l-est-republicain_nancy_p01.jpg

1976-10-11_l-est-republicain_nancy_p22.jpg

Cas avec deux articles dans le même journal, à la même page,

1976-10-11_l-est-republicain_nancy_1_p01.jpg

1976-10-11_l-est-republicain_nancy_2_p01.jpg

Cas avec deux articles dans le même journal et la page n'est pas connue

1976-10-11_l-est-republicain_nancy_1.jpg

1976-10-11_l-est-republicain_nancy_2.jpg

Proposé par Xavier : ajouter un fichier xyz_info.txt placé à coté du document(s) xyz contenant les informations destinées à la base. ça a le gros avantage de supprimer le risque d'incohérence entre la base et les documents puisque dans ce nouveau contexte, le fichier de “base” est généré automatiquement. Permet aussi une recherche sans avoir besoin de la base. Fichier texte de préférence au format texte UTF8 si vous savez faire.

Une autre approche plus automatisée, consiste à générer avec une IA (genre ChatGPT) des fichiers texte .json équivalents au xyz_info.txt. Ils sont générés automatiquement et validés par un humain manuellement. Xavier a développé une petite appli d'aide à la correction (si généré par IA) ou création manuelle de ces json. Nous avons maintenant une appli plus élaborée pour rendre les corrections plus ergonomiques.

• l'ordre des champs n'a pas d'importance
• on peut omettre des champs
• un champ vide peut être exprimé de trois façons
  • par omission
  • null
  • “”

champs :

Formatage : tableau d'objets json dans un fichier texte au format utf-8

Exemple dans le cas ou le document (pdf) inclus 2 articles :

[
  {
    "date_parution": "1976-08-07",
    "date": "1976-08-11",
    "pays": "FR",
    "ville": "Carnon-Plage",
    "journal": "Midi-Libre",
    "titre": "Conférence de Richard Bessière",
    "resume": "Conférence audio-visuelle",
    "page": "p2"
  },
  {
    "date_parution": "1976-08-08",
    "date": "XXXX-XX-XX",
    "pays": "FR",
    "ville": "Montpellier",
    "journal": "Midi-Libre",
    "titre": null,
    "resume": "Observation d'O.V.N.I.",
    "qualite": "passable"
  }
]

dans le cas d'un seul article, on peut encoder comme ça, c'est à dire, un objet json isolé (pas un tableau)

{
    "date_parution": "1976-08-08",
    "date": "XXXX-XX-XX",
    "pays": "FR",
    "ville": "Montpellier",
    "journal": "Midi-Libre",
    "titre": null,
    "resume": "Observation d'O.V.N.I.",
    "qualite": "passable"
}

Comprenez bien que nous sommes en mesure aujourd'hui de créer ces fichiers automatiquement, par scrutation du texte par une IA.

champs :

• journal:nom du journal
• date:format standard
• numéro: nombre entier ou toute représentation textuelle fidèle de la dénomination du numéro
• support:
  • original : en possession du journal
  • copie: en possession d'une photocopie physique de la revue
  • numerique: si on ne possède que le scan de la revue
• qualité:
  • insuffisant
  • passable
  • bonne (par défaut)

champs :

• date:
• titre:
• pays: au format ISO (fr par défaut)

A faire pour déterminer les champs selon le type de document

recette : prendre toutes les bases déjà existantes et prendre le meilleur de chacun et supprimer ce qui n'est pas vraiment necessaire

exemple 1: base-presse-cnegu(version_excel).xls

exemple 2 : sceau-recension_des_cdp_ovni_de_la_presse_francophone_1935-1969_v_56#2-02_2018

exemple 3 : ovni-dans-la-presse-fhs-dcy-actu_17_janvier_2018.xls

example 4 : sceau_base_presse_dcy_fhs_10_2017_extrait_1944-1969-2.xlsx (colonnes pas nommées)

example 5 : sceau_recension_des_revues_ufologiques_francophones-projet_numerisation-v15_11_2017_#1.xlsx

example 6 : jmi_revues_ufologiques.xlsx

exemple 7: revues_ufologiques_francophones_bmi.xlsx

exemple 8 : fonds_borie_cdp_presse_q-1965-1990.xls

Une fois terminée la préparation des fichiers pdf et de l'arborescence, …
puis la géné auto des json, …
la génération automatique d'un fichier .csv avec le chemin complet déjà intégré peut se faire en quelques clicks (avec un script en python) et manip rapides.
En tout cas extrêmement plus rapide et moins débilitant que d'avoir à faire un copier-coller acrobatique 1500 fois.

Aussi, si la date et le nom du périodique sont présents dans le nom du fichier (pdf, avec renommage déjà fait par un humain), on peut le prendre comme info plus fiable que ce qui est dans le json généré automatiquement.

Tout cela a déjà été codé en python.

exemple de génération auto

1947-05-05;aile 597 aile vo;fond_rre//1947-05-05_aile-597-aile-vo.pdf
1947-07-22;la presse n88 a;fond_rre//1947-07-22_la_presse_n88_a.pdf
1947-07-24;europameric couv;fond_rre//1947-07-24_europameric_couv.pdf
1947-07-24;europameric p1;fond_rre//1947-07-24_europameric_p1.pdf
1947-07-24;europameric p2;fond_rre//1947-07-24_europameric_p2.pdf
1947-07-24;europameric p3;fond_rre//1947-07-24_europameric_p3.pdf
1947-08-16;ailes encore les sv 1125;fond_rre//1947-08-16_ailes_encore_les_sv_1125.pdf
1947-08-16;ailes que penser de la bombe atomique;fond_rre//1947-08-16_ailes_que_penser_de_la_bombe_atomique.pdf
1947-08-16;les ailes iles maury;fond_rre//1947-08-16_les_ailes_iles_maury.pdf
1947-08-16;wing encore les sv 1125;fond_rre//1947-08-16_wing_encore_les_sv_1125.pdf
1947-08-16;wing que penser de la bombe atomique;fond_rre//1947-08-16_wing_que_penser_de_la_bombe_atomique.pdf
1947;action 8 aout;fond_rre//1947_action_8_aout.pdf
1947;conquerant  quart de tr;fond_rre//1947_conquerant--quart-de-tr.pdf
1947;illustration 22nov  ail;fond_rre//1947_illustration-22nov--ail.pdf
1947;les ailes ovni roswell;fond_rre//1947_les_ailes_ovni_roswell.pdf
1947;roswell daily record;fond_rre//1947_roswell_daily_record.pdf
1947;spotter p 175;fond_rre//1947_spotter-p-175.pdf
1950-01-14;parismatch kehyoe;fond_rre//1950-01-14_parismatch_kehyoe.pdf
1950-02;tintin journ;fond_rre//1950-02_tintin_journ.pdf
1950-03-24;l inter n233;fond_rre//1950-03-24_l_inter_n233.pdf
1950-03-24;l inter n233 couv;fond_rre//1950-03-24_l_inter_n233_couv.pdf
1950-03-24;l inter n233 humour;fond_rre//1950-03-24_l_inter_n233_humour.pdf
1950-03-31;cest la vie n21;fond_rre//1950-03-31_cest_la_vie_n21.pdf
1950-03-31;cest la vie n21couv;fond_rre//1950-03-31_cest_la_vie_n21couv.pdf
1950-03-31;l inter n234 p5 bas;fond_rre//1950-03-31_l_inter_n234_p5_bas.pdf
1950-03-31;l inter n234 p5 haut;fond_rre//1950-03-31_l_inter_n234_p5_haut.pdf
1950-04-02;la presse;fond_rre//1950-04-02_la_presse.pdf
1950-04-02;la presse couv;fond_rre//1950-04-02_la_presse_couv.pdf
1950-04-15;paris match n56;fond_rre//1950-04-15_paris-match-n56.pdf
1950-04-15;paris match n56 couv;fond_rre//1950-04-15_paris-match-n56_couv.pdf
1950-04-16;la vie catho couv;fond_rre//1950-04-16_la_vie_catho_couv.pdf
1950-04-16;la vie catho p01;fond_rre//1950-04-16_la_vie_catho_p01.pdf
1950-04-16;la vie catho p02;fond_rre//1950-04-16_la_vie_catho_p02.pdf
1950-05-06;images n1078 couv;fond_rre//1950-05-06_images_n1078_couv.pdf
1950-07-17;life couv foto trent;fond_rre//1950-07-17_life_couv_foto_trent.pdf
1950-07-17;life p20 foto trent;fond_rre//1950-07-17_life_p20_foto_trent.pdf
1950-11-30;point vue cather;fond_rre//1950-11-30_point-vue-cather.pdf
1950;avril imagemonde sv fr;fond_rre//1950_avril-imagemonde-sv-fr.pdf
1950;avril imagemonde;fond_rre//1950_avril-imagemonde.pdf
1950;images n1066;fond_rre//1950_images_n1066.pdf

si en plus, sont présents des fichiers xyz_info.txt, alors, il devient possible de générer un fichier de base complet,
si en plus, sont présents des fichiers .json, alors, il devient possible de générer un fichier de base complet, comme

https://sceau-archives-ovni.org/fonds/fond_rre/base_fond_rre_CdP1_2_3_4.html

Si on suit l'idée de Xavier avec le fichier xxx_info.txt, ou utilise une IA pour générer les .json, le fichier de base est généré automatiquement et tout ce qui suit peut être généré par script, automatiquement.

Par le chemin du fichier dans l'arborescence des fichiers, précédé d'un nom de fond.

nom_du_fond//rep1/rep2/.../AAAA-MM-JJ_...ext  

avec .ext == .txt ou .pdf (pas .jpg ou .png)

notez bien l'usage du / pour séparer les répertoires. A utiliser plutôt que '\' car / est plus standard dans les systèmes d'exploitation et pose moins de problèmes lors des traitements de chaines de caractères.

Cela suppose que les re-nommages “normatifs” repertoire/fichier ont déjà été effectuées sur la copie entre les mains de ceux qui font la saisie.

Une fois terminée la préparation des fichiers pdf et de l'arborescence, … puis la géné auto des json, … la génération automatique d'un fichier .csv avec le chemin complet déjà intégré peut se faire en quelques clicks (avec un script en python) et manip rapides. En tout cas extrêmement plus rapide et moins débilitant que d'avoir à faire un copier-coller acrobatique 1500 fois.

Aussi, si la date et le nom du périodique sont présents dans le nom du fichier (pdf, avec renommage déjà fait par un humain), on peut le prendre comme info plus fiable que ce qui est dans le json généré automatiquement.

Tout cela a déjà été codé en python.

Ce csv est ensuite ouvert dans open/libre office pour en faire un fichier .ods (ou excel si vraiment personne ne veut utiliser le format open document)

Exemples :

—– Pour une coupure de presse en une image seule 1954-06_coeurs_vaillants_helicop.jpg dans un répertoire …/CdP/1954_presse/1954-06_coeurs_vaillants/

Le chemin a mettre est :

fond_RRE//CdP/1954_presse/1954-06_coeurs_vaillants/1954-06_coeurs_vaillants_helicop.pdf

Pour une coupure de presse regroupant plusieurs images en un pdf (les images étant dans un répertoire …/CdP/1954_presse/1954-11-11_Jean-Pierre_n_06)

Le chemin a mettre est :

fond_RRE//CdP/1954_presse/1954-11-11_Jean-Pierre_n_06.pdf

Pour une revue x regroupant plusieurs images en un pdf (les images jpg étant dans un répertoire …/revues/rep1/rep2/AAAA-MM_x_n_06)

Le chemin a mettre est :

fond_RRE//revues/rep1/rep2/AAAA-MM_x_n_06.pdf

Le nom du fond qui doit être discriminant, permet de localiser sur quel serveur on doit aller le chercher.

ça signifie, que par ailleurs, il y a une information qui dit en pratique où est situé le fond. Une table de correspondance. A clarifier

Cela permet de gérer la possibilité que chaque fond soit hébergé sur un serveur spécifique avec une méthode d'accès spécifique.

Cela peut du coup aussi jouer sur la méthode à utiliser pour reconstruire le chemin d'accès complet. Au cas par cas.

Certains fonds peuvent être privés, et dans ce cas, il faut contacter une personne par exemple.

Si le fond est totalement public, les fichiers peuvent être en ligne, et la reconstruction du chemin complet consiste à juste remplacer (programmatiquement, dynamiquement)

nom_du_fond//

par quelque chose qui ressemble à

https://sceau-archives-ovni/fonds_publics/nom_du_fond/

Les syntaxes ci dessus sont théoriques et servent à définir un chemin absolu, indépendant de la méthode d'accès au ficher. Actuellement, en pratique les fichiers sont accédés sur le web et les chemins sont des url.

Toutes les étapes décrites ci dessous sont automatisées sauf indication contraire. Automatisées dans le sens où le nombre d'opération manuelles est fixe (O(1)) et indépendant du nombre de documents traités.

Les scripts (en langage python) sont déjà tous été développés. Et adaptés à chaque fois pour les spécificités de chaque fond.

Prenons l'exemple d'un fond provenant de RRE.

• étape de stabilisation des nommages et de l'arbo en général :
  • étape 0) préparation des fichiers et nommages de ces fichiers par RRE, en respectant autant que possible les règles
  • arborescence brute mise à disposition à LCN, de préférence en l'envoyant par sftp sur le NAS dans /fonds_1/Validation/Fond_RRE
  • check poussé auto de la corruption de tous les jpeg et check auto de la corruption de tous les pdf
    • rapport de corruption à RRE, si un pdf ou jpeg corrompu ou à problème, retour étape 0)
  • tentative de renommage auto des répertoires pour respecter les règles de nommage (caractères utilisés et formatage des dates)
  • tentative de renommage auto des fichiers pour respecter les règles de nommage (caractères utilisés et formatage des dates)
  • détection et suppression de fichiers dupliqués (outil dupeGuru)
  • encore beaucoup de cas pathologiques ?
    • oui : remontée de l'info à RRE, retour à l'étape 0)
    • non : correction de ces cas par LCN
      • super, succès.
      • suppression de l'OCR dans tous les pdf (gain de temps en le faisant ici)
      • placement de la totalité de l'arborescence sur le serveur, comme arborescence de “travail” et arborescence de référence. Avec par défaut, protection contre la suppression de fichiers.
      • elle doit devenir son arborescence de travail, à distinguer de l'arborescence mise en ligne (qui peut être avec des images moins résolues par exemple)
• génération des pdf à partir des images, avec un script spécifique selon que c'est des CdP ou des revues. Les pdf sont constituées sans perte de qualité. Les images y sont stockées telles quelles. Pas de recompression effectuée.
  • encore des de conflits de noms identiques qui bloquent la génération ?
    • oui : remontée de l'info à RRE ; re nommages necessaires dans l'arborescence de travail.
• OCR global
  • par Nuance pour les scans be bonne qualité
  • ou google vision api, pour les scans de qualité insuffisante (payant)
    • si google vision api. il fournit un critère de confiance à chaque ocr. Parcours de tous les fichiers et Génération d'un fichier donnant la liste des scans de qualité insuffisante (confiance<0.7), trié par confiance croissante. Génération d'une arborescence peu dense ne contenant plus que les images à rescanner.
      • re-scan de ces images, écrasement dans l'arborescence avec les nouvelles images
        • copier coller de l'arbo peu dense sur l'arbo de travail
    • si google vision api. Permet d'extraire l'orientation des scans. → permet un redressement des images auto en post traitement.
• Conversion auto des .doc en pdf
  • ces pdf sont ocr par nature
  • placement de tous ces pdf issus de .doc dans une branche de répertoires dédiée, pour qu'ils ne soient jamais passés à l'OCR dans le futur.
• Si certains pdfs regroupent plein de coupures de presse sur plein de pages
  • découpe de ces pdfs en autant de pdfs que de pages.
• Optionnellement
  • conversion des .pdf en .txt (extraction du texte dans un fichier .txt)
  • analyse des .txt automatique avec GPT-3.5 (payant) ou mieux. Avec réponse bridée à 300 tokens pour réduire le coût. Création d'un fichier .json
  • détection des .json au format éroné ou tronqué. Relance de l'analyse des .txt automatique avec GPT-3.5 (payant) ou mieux. Avec réponse bridée à 900 tokens. Remplacement du fichier .json
    • Si les fichiers ont été nommés manuellement (AAAA-MM-JJ_journal_page) : correction/ajout auto des champs de date, journal, page dans les .json
    • si les fichiers n'ont pas été renommés manuellement (scans bruts) alors, renommage des fichiers (.pdf, .jpg ou .png ou .gif, .json, .txt) en utilisant les .json
• Conversion si nécessaire de tous les .json au format utf-8 (si certains auraient été créés pour une raison ou une autre au format ANSI)
• Génération automatique du fichier de base, à divers formats (en csv, ods, xls, html, avec url ou sans url par exemple)
  • avec les .json ou _info.txt si disponibles
    • si un json contient un tableau avec plusieurs entrées, il y aura autant de lignes dans le fichier de base, c'est à dire que le fichier de base peut référencer plusieurs fois le même .pdf
  • mise en ligne temporaire du fichier de base html et des fichiers json, pdf, txt pour relecture
• Revue et correction manuelle de tous les json, retour à l'étape précédente.
• Publication…

• upload sur le serveur NAS Synology (https://files.sceau-archives-ovni.org:6006/)
• indexation avec “universal search” de Synology.
• recherche full text possible pour les membres SCEAU
• téléchargement aussi accessible par sftp (perf)
• mise en ligne publique du xls sur google drive, faisant office de BDD. Avec accès en écriture limité aux proprios.

• potentiellement, copie de l'arborescence telle quelle sur https://sceau-archives-ovni.org/fonds/…
  • dans ce cas, les fichiers seront visibles comme cela : https://sceau-archives-ovni.org/fonds/fond_rre/base_fond_rre_CdP1_2_3_4.html
• mise en ligne publique du xls sur google drive, faisant office de BDD. Avec accès en écriture limité aux proprios.
  • le xls pointe directement sur les url publiques
  • on pourrait peut-être utiliser datastudio de google comme le COBEPS, pour mieux présenter la BDD. https://datastudio.google.com/u/0/reporting/7e5a715a-212b-473d-8491-992f94b87605/page/6kSMC?s=l6cZ8UAgv8U
• pas encore de recherche full text possible pour le public

Trois technologies complémentaires à considérer et qui peuvent se brancher au dessus de notre arborescence :

• Des browsers d'images/documents capables d'exploiter le format IIIF
  • https://iiif.io/get-started/iiif-viewers/
  • exemple : https://universalviewer.io/
• le format IIIF est juste un fichier texte qui contient des infos sur le document et son url. Il “suffirait” de créer des IIIF à partir de nos informations.
  • https://doc.biblissima.fr/iiif/introduction-iiif/
  • https://iiif.io/
• le concept et les logiciels associés au “Controlled digital lending” (CDL), qui permet de partager des documents numérisés comme le fait une bibliothèque. Utile pour les livres physiques dont on possède une copie numérique. Il devient alors possible de les partager de façon “raisonnable” comme une bibliothèque physique.
  • https://github.com/caltechlibrary/dibs pour une implémentation open source (logiciel à faire tourner sur notre serveur à priori)

Un principe clé du CDL est le ratio « possédé/emprunté », ce qui signifie qu'une bibliothèque ne peut pas diffuser plus que le nombre d'exemplaires qu'elle possède. Afin de s'assurer qu'elle respecte cette obligation, la bibliothèque prêteuse contrôle une œuvre numérisée au moyen d'un logiciel de gestion des droits numériques (DRM).

A key principle of CDL is the “owned to loaned” ratio, which means that a library cannot circulate more than the number of copies it owns. In order to ensure that it meets this obligation, the lending library controls a digitized work through digital rights management (DRM) software.

• en plus de l'indexation sur le NAS privé, qui permet des requêtes de recherche plus complexes
  • recherches full text possibles sur https://sceau-archives-ovni.org/mags/fts/fts.html (recherche qui devient plus lente à chaque ajout de documents)
• recherche sémantique comme sur https://sceau-archives-ovni.org/mags/fts/semantic_ldln.html

• Apache-Solar / Docker / NAS Synology DS920+ – https://solr.apache.org/ https://www.ldlc.com/fiche/PB00351846.html
• indexation de la totalité des documents par solar par une sorte de crawler
• site web su sceau offrant une interface proxi de recherche sollicitant solar sur le NAS
  • le résultat de la recherche est
    • un texte décrivant la méthode pratique d'accès au fond
    • le chemin d'accès au document, tel que décrit plus haut. Une url directe si possible.
    • si possible un extrait autour du match
• cf https://sceau-archives-ovni.org/mags/fts/spec/full_text_search_v2.01.pdf

Sécurisé en RAID sur NAS Synology avec miroir sur site distant (actuellement, 1x / semaine)

Sur le site sceau-archives-ovni, arborescence accessible directement.

+

Sécurisé en RAID sur NAS Synology Avec Miroir sur un autre NAS sur un autre site.

En 2023-24, nous utilisons le modèle gpt-3.5-turbo-1106 pour son faible coût. Il donne un bon rapport coût/intelligence pour notre application.
En 2025, nous utilisons gpt-4o-mini-2024-07-18 tout aussi performant semble-t-il et moins cher.