Durabilité

Chinaski est conçu pour survivre aux modes, de la mode logicielle, du churn des plateformes, du verrouillage propriétaire, même d'internet lui-même. Cette page explique ce que cela signifie concrètement : des URL durables, du contenu durable, des formats de sortie durables, et ce qui les rend tels.

Des URL durables

Les liens sont des promesses. Chinaski les tient ainsi :

Les renommages ne cassent jamais les liens. Quand vous renommez une page ou un post publié, ou changez le préfixe d'URL du blog, les redirections pour chaque ancienne adresse sont générées au prochain rebuild, automatiquement. Les vieilles URL continuent de fonctionner tant que votre site existe.
Un seul domaine est imposé avec une redirection intégrée : quelle que soit l'orthographe de votre hôte que vous n'avez pas choisie (www ou apex), elle envoie les visiteurs vers celle que vous avez choisie, en préservant la page.
Les URL sont des fichiers. Chaque page existe statiquement comme un répertoire HTML sur disque. Les lecteurs y accèdent par n'importe quel serveur web capable de servir un fichier ; le système de contenu n'a pas besoin d'être vivant, ni même en cours d'exécution, pour que le site fonctionne. Il n'y a aucun schéma d'URL propre à un framework à pourrir.
Traductions et liens alternatifs restent cohérents. Chaque langue a son propre sitemap, ses règles de redirection, et des balises hreflang croisées : la découvrabilité survit aux refontes de la structure de menus au-dessus d'elle.

Un contenu durable

Un fichier, aucun serveur. Tout le contenu (pages, posts, métadonnées de médias, comptes, historique d'audit) vit dans un unique fichier de base de données SQLite. Le sauvegarder, c'est copier un fichier ; il n'y a rien à redécouvrir ou reconfigurer lors d'une restauration. Pas d'identifiants, pas de chemin réseau, pas de cérémonie de migration entre versions mineures.
L'historique est intégré, pas acheté. Chaque enregistrement prend un instantané de révision ; chaque mutation de contenu est consignée dans un journal d'audit ; les soumissions de formulaires et leurs métadonnées sont conservées selon vos règles de rétention. Restaurer hier est une opération prise en charge qui n'exige pas d'archéologie médico-légale.
Les sauvegardes sont vérifiées, pas supposées. Chaque archive est testée après création, et chaque exécution planifiée consigne son issue dans un journal : succès, échec, et résultat de vérification par sauvegarde.
Les brouillons survivent aux plantages. Les modifications non enregistrées vivent côté serveur pendant que vous travaillez, si bien que fermer un onglet de navigateur ou perdre une session après une longue période d'écriture ne dévore pas l'après-midi.
Internet jamais requis. L'installation peut se faire depuis un bundle hors ligne ; ensuite, pas de télémétrie, pas de licence qui appelle la maison, pas de dépendances CDN. Si le réseau disparaît, votre site existe sur disque et l'admin sur votre serveur ; une continuité planifiée, pas accidentelle. Il existe un mode de déploiement « fin du monde » : le serveur répond en HTTP simple pour toujours, rien à renouveler, rien à faire expirer.
Des dépendances ennuyeuses exprès. Tout ce dont le logiciel dépend se livre dans la version stable de l'OS, si bien que des réécritures majeures de bibliothèques tierces ne peuvent pas vaporiser un comportement. La liste de dépendances est courte par conception : neuf modules, délibérément réduits.
Même la doc se livre avec l'instance. Les articles d'aide visibles dans la zone d'administration sont stockés dans la même base de données, si bien qu'ils voyagent avec vos sauvegardes.

Des formats de sortie durables

La sortie publiée du site s'en tient aux formats que le web n'a jamais dépréciés :

HTML simple, stylé génériquement, sans runtime requis : le site public a zéro JavaScript à l'exécution, par construction plutôt que par politique. Rien à quoi un traceur pourrait s'accrocher ; rien à casser quand un vendeur tiers change ses conditions.
Flux et fichiers standard, régénérés à chaque build : sitemap.xml, flux RSS, robots.txt, un fichier de politique de sécurité (security.txt), et des fichiers de règles de redirection dans des formats portables que d'autres serveurs peuvent utiliser.
Des données structurées (JSON-LD) sont écrites directement dans les pages comme HTML simple, lisibles pendant des décennies, par des moteurs de recherche ou des scripts que vous n'avez pas encore écrits.
Extras optionnels hors ligne d'abord : un service worker et une page hors ligne font partie de la sortie générée quand les fonctionnalités PWA sont activées.
Le serveur d'admin lui-même peut survivre sans internet: HTTP simple, aucun certificat à renouveler, aucun service externe à faire défaillir.

Ce que nous ne faisons pas délibérément

L'honnêteté sur les compromis fait partie du même principe :

Il n'y a pas de page builder visuel drag-and-drop. Le contenu du corps utilise un éditeur enrichi ; tout le reste passe par des formulaires structurés. Un builder visuel est sur la feuille de route ; il n'existe pas aujourd'hui.
Il n'y a pas d'écosystème ni de place de marché de plugins : pas de hooks, pas de registres, pas de chaînes de code tiers qui changent silencieusement ce que fera votre site l'an prochain.
La base de données est SQLite, un fichier par instance. Un palier multi-tenant avec Postgres est sur la feuille de route, pas livré aujourd'hui ; le chemin de migration n'est pas encore défini.
Vous êtes propriétaire du serveur, de la base de données et des sauvegardes. La durabilité, ici, signifie votre responsabilité, pas notre garde.

Le pari silencieux en dessous

Sous tout cela se cache un seul pari : les outils stables survivent aux outils ingénieux. Le langage dans lequel le système est écrit (Perl) n'a rompu aucune compatibilité en des décennies de versions mineures ; le moteur SQL (SQLite) traite votre base comme un fichier ; la sortie, ce sont des fichiers HTML sur disque ; l'interface d'admin évite les frameworks qui réécrivent leurs idiomes tous les deux ans. C'est ennuyeux exprès : un site construit sur Chinaski devrait encore s'afficher correctement dans une décennie sans aucun entretien, et le contenu devrait être exactement là où vous l'avez laissé.