Construit sur Perl

Toute l'architecture de Chinaski (un CMS en Perl, un builder de site statique en Perl, et une base de données SQLite) repose sur un pari délibéré : les technologies ennuyeuses survivent aux technologies passionnantes en production. Cette page explique le raisonnement derrière ce choix, avec les mots du projet lui-même, et ce qu'il implique pour vous en tant qu'exploitant.

Un langage stable depuis des décennies

Perl 5 est ennuyeux de la bonne manière. L'interface binaire n'a pas rompu entre versions mineures depuis des décennies. Les dépendances ne se renomment pas toutes seules. Le langage est livré avec Debian par défaut, sans compilateur à ajouter par-dessus. Un programme Perl écrit en 2005 fonctionne encore aujourd'hui, du point de vue du projet, c'est le bon choix d'ingénierie pour un logiciel d'infrastructure qui doit pouvoir être débogué à 2 h du matin par quelqu'un qui ne l'a pas écrit.

L'argument de la surface d'attaque joue lui aussi en faveur de la stabilité : un langage figé avec des dépendances empaquetées par Debian est plus petit et plus auditable qu'une pile dont l'arborescence node_modules ou le requirements.txt se dérobent sous vos pieds entre deux versions.

Ce que le projet utilise lui-même

L'application d'administration (Mojolicious), le builder statique (Template Toolkit), la couche de base de données embarquée (DBI avec DBD::SQLite) et le traitement d'images (Imager ; aucun appel shell à ImageMagick) sont les choix pratiques. Les composants de sécurité sont également standards : hachage des mots de passe par bcrypt via Crypt::Passphrase, chiffrement AES-256-GCM pour les identifiants stockés et signature de sessions HMAC via CryptX, et DateTime avec DateTime::TimeZone s'appuyant sur la base des fuseaux horaires IANA pour une planification correcte.

Partout où un sous-système a besoin de fonctionnalités optionnelles (l'importeur Markdown, par exemple), ces modules se chargent paresseusement, et uniquement au moment où on en a besoin. Un site auquel il en manque un démarre et sert tout le reste ; seule cette route se dégrade, avec un message clair dans la zone d'administration.

Le pari des dépendances

La plupart des systèmes de gestion de contenu accumulent de la surface : plugins, intégrations, points de terminaison d'analytique, assets de CDN. Chaque ajout parie que la capacité ajoutée vaut la complexité et la surface d'attaque supplémentaires, et comme le README du projet le formule, la plupart de ces paris gagnent en démo et perdent en production. Chinaski fait le pari inverse.

Résultats concrets de ce pari, tels que le projet les documente :

• Une petite liste de dépendances entièrement contenue dans Debian stable: une installation fraîche se résout entièrement depuis les paquets système, sans aucune compilation.
• Zéro JavaScript à l'exécution sur la sortie publique: une garantie structurelle plutôt qu'une promesse de politique. Le serveur web Caddy sert des fichiers statiques depuis le disque ; l'application Perl n'est jamais dans le chemin des requêtes publiques, si bien qu'aucun mécanisme ne peut faire embarquer un traceur avec vos pages.
• Compatible air-gap par défaut: pas de télémétrie, pas de validation de licence auprès d'un serveur externe, pas de polices ni d'icônes depuis un CDN. Une fois installé, Chinaski n'a pas besoin d'internet. Toutes les intégrations capables de sorties réseau (vérifications de mises à jour, SMTP, webhooks, sauvegardes cloud) sont livrées désactivées tant que vous ne les activez pas délibérément.

Écrit avec l'IA, fonctionne sans IA

Chinaski a été écrit avec l'assistance de l'IA (Claude Code et Kimi) et devrait être maintenu de la même manière. La stabilité de Perl rend cela inhabituellement auditable : le langage n'a pas changé ses idiomes depuis trente ans, si bien que le code généré se lit proprement de haut en bas. La position du projet est que la maîtrise de l'IA est la compétence de contribution qui compte, la maîtrise de Perl n'est pas requise pour maintenir Chinaski.

Des compromis assumés

Le minimalisme a de vrais coûts, que le projet énonce sans détour :

• Il n'y a pas d'écosystème de plugins : pas d'architecture de hooks, pas de registre de plugins, pas de place de marché de thèmes.
• La base de données est SQLite, pas Postgres (Postgres est prévu pour un futur palier multi-tenant).
• Cela reste un travail opérationnellement impliquant : vous êtes propriétaire du serveur, de la base de données et des sauvegardes.

Si vous exploitez de nombreux sites clients et voulez des piles identiques que vous pouvez reconstruire en confiance, ce compromis est séduisant. Si vous avez besoin de l'écosystème qu'apporte une plateforme plus grande, c'est précisément ce que Chinaski refuse de fournir.

Ce que cela signifie pour vous

Le bénéfice pratique du choix du langage apparaît dans l'exploitation, pas dans le marketing :

• Installez une fois, redémarrez moins. La pile se présente sous forme de paquets de la distribution, pas de remous de framework entre les mises à jour système.
• Lisez le code. L'implémentation tient dans un petit nombre de fichiers, écrits avec les commentaires en tête et structurés pour qu'une correction n'exige pas d'archéologie : les trente années d'idiomes stables du langage gardent tout simple.
• Une sortie auditable. Les affirmations liées à la sécurité (gestion des sessions, chiffrement au repos, absence de télémétrie) sont toutes appliquées à des endroits uniques dans le code : rien à auditer à travers cinq répertoires.
• Le noyau est sous licence MIT ; les futurs modules Pro commerciaux devraient utiliser des fichiers de licence signés localement sans connexion sortante, conformément à la promesse air-gap.