[🛠] Transférer des sauvegardes PDF de Naver Blog vers GitHub Pages

✨ Résumé de GPT-5.5 　

Le récit de l’extraction de 173 articles et 1 521 images depuis 18 sauvegardes PDF de Naver Blog, puis de leur réintégration dans la structure existante du blog GitHub Pages.

J’ai eu envie de ramener sur ce blog GitHub Pages les articles que j’avais accumulés sur Naver Blog.

Plus précisément, il ne s’agissait pas seulement de conserver des fichiers de sauvegarde quelque part. Il y avait déjà des textes écrits. Ils avaient des dates, des images, des catégories, et aussi les pensées de cette période. Mais ces traces étaient rangées à part, dans une autre maison appelée Naver Blog.

Au final, je voulais remettre ce blog au centre de mes archives. Un blog GitHub Pages est simple, mais il me permet d’empiler mes traces dans la structure que je veux.

Sauf que cette fois, il ne s’agissait pas d’écrire un nouvel article.

Je devais prendre 18 sauvegardes PDF de Naver Blog et déplacer les articles et les images qu’elles contenaient dans la structure Jekyll existante du blog.

J’ai commencé par fixer les conditions

Dès le départ, l’objectif était simple.

Je voulais importer les sauvegardes de Naver Blog, mais faire en sorte qu’elles se lisent, dans ce blog, comme des articles qui auraient toujours été là.

J’ai donc fixé quelques conditions.

• Extraire tous les articles des 18 PDF, sans omission.
• Conserver la date de chaque article et le lien original.
• Placer les images sous assets/images/YYYY-MM/YYYY-MM-DD/, conformément à la convention du blog existant.
• Faire continuer la numérotation de la série Aujourd'hui, ma journée à partir des articles existants.
• Ne pas mélanger les articles de restaurants, de voyage, d’IA, de développement et autres dans la numérotation Aujourd'hui, ma journée.
• Ne pas forcer les articles dans les catégories existantes ; créer de nouvelles catégories si nécessaire.
• Ne pas importer telles quelles les phrases cassées par les PDF.
• Le résultat devait être constitué d’articles Jekyll capables de passer le build.

Écrit comme ça, cela paraît banal. Mais une fois lancé, ce n’était pas une simple copie de fichiers.

C’était le déménagement d’archives d’un système vers un autre.

Je ne pouvais pas faire confiance au texte des PDF seul

Au début, je pensais qu’il suffirait d’extraire le texte et les images des PDF.

Les articles ont bien été extraits. Les images aussi. Mais le problème venait du corps du texte. Les phrases récupérées depuis les PDF se coupaient parfois à des endroits étranges.

Par exemple, cela donnait ce genre de chose.

Vouloir contrôler seul cette immense tempête le plus vite possible, cet excès d'élan lui-même était la plus grande cause qui me rendait impuissant

à cause de cela.

Une seule phrase se retrouvait séparée comme deux paragraphes, des mots étaient coupés, et le rythme de lecture était détruit.

Si je les avais migrés dans cet état, il y aurait bien eu une sauvegarde, mais les articles auraient été abîmés. Ce n’aurait plus vraiment été un texte à lire par quelqu’un, plutôt une trace arrachée à un PDF.

J’ai donc changé de direction.

J’ai utilisé les PDF comme point de départ pour la liste des articles et l’extraction des images, puis j’ai relu le HTML original de Naver pour restaurer le corps du texte. En suivant le flux des paragraphes, des listes et des citations de l’éditeur Naver, j’ai reconstruit le contenu en Markdown.

C’est seulement là que les articles sont redevenus des articles.

J’ai aligné les images sur la méthode du blog existant

Les images étaient importantes, elles aussi.

Les articles Naver en contenaient beaucoup. Surtout dans les articles de voyage ou de restaurants, les images étaient presque le corps du texte lui-même. Déplacer uniquement le texte aurait donné des archives à moitié vides.

Au final, j’ai importé 1 521 images.

Les chemins d’images ont suivi la convention du blog existant.

assets/images/2025-09/2025-09-09/naver-004-001.jpg

J’ai organisé les noms de fichiers avec l’année-mois, la date, puis le numéro d’import Naver. Comme ça, même plus tard, il reste possible de retrouver de quelle date et de quel import vient chaque image.

Dans le corps des articles, j’ai gardé la syntaxe d’image Markdown ordinaire.

![naver-004-001](/assets/images/2025-09/2025-09-09/naver-004-001.jpg)

Dans un blog statique, cette simplicité compte. Une fois le build terminé, ce ne sont que des fichiers. Il n’y a pas besoin de dépendre d’un serveur d’images séparé ou de liens externes.

J’ai redistribué les catégories

La partie la plus délicate était celle des catégories.

Au début, je me suis demandé si je pouvais simplement placer les articles Naver quelque part sous diary. Mais avec ça, les articles auraient été difficiles à retrouver plus tard, et la structure du blog serait devenue floue.

J’ai donc créé de nouvelles catégories.

diary life
diary thought
diary relationship
diary restaurant
diary travel

J’ai aussi utilisé les catégories déjà présentes, comme diary ai, diary dev et diary religion. Les articles de lecture et de mindset sont allés sous reading mindset, les présentations d’apps sous tip app, et les récits de construction du blog sous devlog github-pages-blog.

Créer des catégories ne s’arrête pas au déplacement d’un fichier.

Il faut des pages de catégorie. Il faut aussi la navigation de la barre latérale. Les libellés et les liens de catégories visibles dans les archives doivent correspondre. L’icône placée devant chaque titre doit également suivre la convention existante du blog.

J’ai rangé les articles de restaurants avec [🍽️], ceux sur l’IA avec [🤖], ceux de développement avec [🧑‍💻], ceux de voyage avec [🧳], et ainsi de suite.

Ces détails peuvent sembler mineurs, mais s’ils se dispersent, les articles importés continuent à donner l’impression d’être des corps étrangers venus de l’extérieur.

J’ai gardé la numérotation Aujourd'hui, ma journée à part

Le point le plus facile à embrouiller était la numérotation Aujourd'hui, ma journée.

Les articles Certification du jour qui se trouvaient sur Naver étaient, en pratique, des Daily Reviews. Ils devaient donc continuer la série Aujourd'hui, ma journée du blog existant.

À l’inverse, les articles de restaurants, de voyage, d’IA ou de lecture ne font pas partie de Aujourd'hui, ma journée, même si leurs dates sont proches. Si ces articles entraient eux aussi dans la numérotation, la série elle-même se casserait.

Le résultat final a été aligné comme ceci.

Aujourd'hui, ma journée #1 ~ #200

Les numéros se sont enchaînés de 1 à 200, sans omission ni doublon. J’ai aussi vérifié que les articles hors Daily Review ne contenaient pas de numéro Aujourd'hui, ma journée #.

Ce n’était pas un simple rangement de chiffres.

C’était un travail pour préserver l’identité de la série.

La vérification représentait la moitié du travail

Ce qui fait peur dans ce genre de migration, c’est qu’elle peut avoir l’air correcte de l’extérieur alors qu’un détail se dérègle quelque part.

Un fichier image peut manquer alors que la référence Markdown est toujours là. Le front matter de catégorie peut ne pas correspondre au dossier réel. L’icône du titre peut s’écarter de la convention existante. Une icône ? cassée par le PDF peut rester telle quelle dans le corps du texte.

J’ai donc lancé des vérifications séparées.

Voilà, en gros, ce que j’ai contrôlé.

Articles importés : 173
Références d'images : 1 521
Images manquantes : 0
Restes de ? isolés visibles : 0
Numérotation Aujourd'hui, ma journée : #1 ~ #200
Numérotation mêlée à des articles hors Daily Review : 0
Discordances de dossiers de catégories : 0

À la fin, j’ai aussi lancé un build Jekyll.

bundle exec jekyll build

Avec un blog statique, c’est seulement quand le build passe que l’on peut vraiment souffler. Une seule erreur de syntaxe Liquid dans un fichier Markdown peut arrêter tout le site.

Résultat

Au final, j’ai déplacé vers ce blog 173 articles et 1 521 images depuis 18 sauvegardes PDF de Naver Blog.

Mais le plus important n’est pas dans les chiffres.

Ce travail n’était pas une simple sauvegarde. C’était la restauration de traces dispersées dans un seul système.

PDF, HTML de Naver, front matter Jekyll, pages de catégorie, navigation latérale, chemins d’images et numérotation de série devaient tous s’aligner. Si un seul élément se trompait, le contexte des archives se cassait.

Vu de l’extérieur, cela peut ressembler à un simple déplacement d’articles. Mais pour moi, c’était un travail de remise en ordre du système d’archives.

Je n’ai pas seulement ramené beaucoup d’articles. J’ai redécidé comment structurer les traces que j’avais accumulées, comment restaurer des données abîmées, et comment les installer dans les conventions du système existant.

Écrire des traces compte, mais les retenir pour ne pas les perdre compte aussi.

Ce travail était plutôt de ce côté-là.