Stack technologique de cutty.dev — des choix conscients
Qu'est-ce qu'il y a sous cutty.dev et pourquoi. Sans évangélisme — la philosophie : une stack ennuyeuse et stable, un hébergement dans l'UE et une confidentialité intégrée à l'architecture, qu'une seule personne est capable de maintenir.
La plupart des articles « mon tech stack » sont une liste fière de nouveautés. Regardez, j'ai ceci, j'ai cela, et voici une toute nouvelle bibliothèque de la semaine dernière. Celui-ci sera différent.
Car la vérité est que lorsque vous gérez un projet seul, vous ne cherchez pas ce qui est le plus à la mode. Vous cherchez quelque chose qui ne vous réveillera pas à trois heures du matin. Et c'est précisément l'objet de toute cette stack technologique cutty.dev : ennuyeuse plutôt que tendance, européenne plutôt qu'américaine, privée dès les fondations, et suffisamment simple pour être gérée par une seule paire de mains.
Je t'explique cela au fur et à mesure, comme si nous en discutions autour d'un café.
Astro rendu côté serveur (et pourquoi pas quelque chose de "plus cool")
cutty.dev est un site Astro avec rendu côté serveur. Chaque requête passe par le serveur, construit la page et renvoie le HTML prêt à l'emploi. Ennuyeux ? C'est justement tout l'intérêt.
Je voulais trois choses : le rendu côté serveur sans machinerie lourde, une prise en charge multilingue sérieuse et immédiate, et de la rapidité sans surcharge. Astro offre tout cela, tout en gardant un code lisible. Quand j'y reviens après deux mois de pause, je sais exactement ce qui s'y passe. Pour un projet solo, cela vaut bien plus que n'importe quelle extension à la mode que plus personne ne supporte après un an.
Un seul fichier au lieu d'une base avec des feux d'artifice
SQLite. Une seule base de données, un seul fichier sur le disque. En plus de cela, une couche de requêtes qui communique avec TypeScript, donc si je change la structure des données, l'erreur s'affiche dans mon éditeur et non en production à minuit.
Pourquoi précisément cela ? cutty est "read-heavy". Quelqu'un clique sur un lien raccourci, nous effectuons une lecture et nous incrémentons le compteur. C'est tout. SQLite gère ce trafic sans problème, jusqu'à des chiffres vraiment élevés par jour. Et la sauvegarde ? Vous copiez le fichier. C'est fini. Sans cérémonie de réplication, sans scripts dont personne ne se souvient comment ils fonctionnent.
Faites attention à un point, car c'est un piège fréquent : les gens entendent "SQLite" et pensent "un jouet pour un projet d'examen". C'est faux. Moins de pièces mobiles signifie moins de choses qui peuvent tomber en panne. Ce n'est pas faire des économies sur la qualité, c'est une décision consciente.
Le serveur est situé en Europe et ce n'est pas un hasard
Serveur dédié en UE. Propre TLS, reverse proxy avec HTTPS automatique, application en conteneurs.
C'est le fondement de la manière dont cutty gère les données. Je sais exactement où elles se trouvent physiquement (pour les clients de l'UE et le RGPD, ce n'est pas une simple curiosité, mais une condition), je ne suis pas lié à un seul fournisseur, rien ne fuit automatiquement vers l'océan, et la facture est prévisible au lieu de fluctuer avec le trafic.
Oui, les plateformes pratiques de l'Ouest permettraient un démarrage plus rapide. On clique, on déploie, ça fonctionne. Sauf que vous payez pour cela avec l'endroit où atterrissent les données de vos utilisateurs. Pour moi, c'était un mauvais deal.
Les traductions font leur propre modèle, chez soi
cutty parle 25 langues. Cela est traduit par un modèle IA local et ouvert, qui s'exécute sur mon infrastructure. Je n'envoie pas le texte de l'interface à un fournisseur externe.
Les avantages sont pratiques. Une traduction unique ne coûte rien. J'ai un contrôle total sur la qualité et je peux les actualiser quand je le souhaite. Et puis, la machine a toujours besoin d'un œil humain, donc chacun de ces 25 langues a été révisé. Mais le fait que je le fasse chez moi signifie que la confidentialité n'est pas une ligne dans un tarif. C'est une propriété de la manière dont l'ensemble est construit.
Tailwind, conteneurs et quelques petites décisions
Style ? Utility-first, c'est-à-dire Tailwind. Pas de CSS-in-JS, pas de fichiers de styles séparés, tout directement dans les templates. Je ne perds pas de temps à inventer des noms de classes, les styles inutilisés ne finissent de toute façon pas sur la page finale, et le design tient la route car le système lui-même l'impose. Pour une seule personne, chaque minute n'est pas gaspillée en futilités.
Le déploiement, c'est Docker. Le même environnement en local et en production, fini le "ça marchait sur ma machine". Et si jamais il fallait le faire, je déplace tout sur un autre serveur en une trentaine de minutes. La portabilité est une forme silencieuse d'indépendance.
Ce que j'en ai retiré
La stack ennuyeuse gagne. Astro, SQLite, Tailwind, conteneurs. Tout est mature, éprouvé, documenté. Rien ne casse au moment où vous en avez le moins besoin.
L'hébergement en UE est prêt pour la production, vraiment. L'idée que "vous devez passer par le grand cloud américain pour être pris au sérieux" est un mythe. L'IA locale est également une réalité, il n'est pas nécessaire de confier ses données à une API externe pour obtenir des traductions correctes. Et dernière chose : une seule personne peut sortir quelque chose qui ressemble au travail d'une équipe entière. Il faut juste se rappeler que le temps est plus précieux que l'argent, et choisir chaque pièce en tenant compte de cet aspect.
Lorsque vous construisez quelque chose qui vous appartient, posez-vous une seule question pour chaque technologie : serai-je capable de le maintenir moi-même dans un an ? Si la réponse est non, alors vous avez probablement votre réponse.
Tout cela fonctionne ici : cutty.dev. Et si vous voulez discuter de l'une de ces décisions, écrivez à [email protected], je réponds le jour même.