La stack technologique de cutty.dev : des choix conscients

La plupart des articles sur « mon tech stack » sont une liste fière de nouveautés. Celui-ci porte sur autre chose — sur la philosophie qui sous-tend les choix de cutty.dev : ennuyeux et stable plutôt qu’à la mode, européen plutôt qu’américain, privé par conception, et suffisamment simple pour qu’une seule personne puisse le maintenir.

Framework : Astro (rendu côté serveur)

cutty.dev est une application Astro rendue côté serveur. Chaque requête passe par le serveur, qui compose dynamiquement la page et répond avec du HTML prêt à l'emploi.

Pourquoi : je voulais un rendu côté serveur sans lourde infrastructure, un bon support de nombreux langages intégré au framework lui-même, et une rapidité sans surcharge. Astro offre tout cela, et le code reste lisible — ce qui, dans un projet mené en solo, vaut plus que n'importe quel gadget à la mode.

Base de données : SQLite

Une seule base de données, un seul fichier. Ajout d'une couche de requêtes compatible avec TypeScript, permettant de détecter immédiatement les erreurs dans le code plutôt qu'en production lors d'un changement de structure des données.

Pourquoi : cutty.dev est avant tout « read-heavy » — chaque clic sur un lien entraîne une lecture et incrémente le compteur. SQLite gère cela parfaitement, même avec un trafic quotidien très élevé. La sauvegarde se résume à copier un seul fichier — sans cérémonie de réplication, sans scripts complexes. La simplicité ici n'est pas une économie de qualité ; c'est une décision consciente : moins de composants mobiles signifient moins d'éléments susceptibles de tomber en panne.

Hébergement : serveur dans l'Union européenne

Serveur dédié en UE, certificat TLS personnalisé, proxy inverse avec HTTPS automatique, application conteneurisée.

Pourquoi : c’est le fondement de la manière dont cutty.dev traite les données. Contrôle total sur leur localisation (crucial pour les clients en UE et pour le RGPD), absence de dépendance à un seul fournisseur, pas de réplication automatique vers les États-Unis offerte par les grandes plateformes cloud, et des coûts prévisibles plutôt qu’une facturation basée sur le trafic. Des plateformes occidentales pratiques offriraient un démarrage plus rapide — mais au prix de l’endroit où atterrissent physiquement les données de vos utilisateurs.

Traductions : modèle d'IA local

cutty.dev parle 25 langues, et les traductions sont réalisées par un modèle d'IA local et open source exécuté sur notre propre infrastructure.

Pourquoi : aucun texte de l’interface ne sort vers l’extérieur — nous ne l’envoyons à aucun fournisseur d’IA externe. Cela entraîne un coût nul par traduction individuelle et un contrôle total sur la qualité : nous pouvons les actualiser quand nous le souhaitons. La traduction automatique nécessite toujours une vérification humaine — et chaque langue a passé ce type de revue — mais le faire en interne signifie que la confidentialité n’est pas une option dans la grille tarifaire, mais une propriété de l’architecture.

CSS : utility-first (Tailwind)

Un seul système de styles, pas de CSS-in-JS, pas de fichiers de styles séparés. Tout est directement dans les templates.

Pourquoi : la vitesse d’itération. Je ne perds pas de temps à inventer des noms de classes, et les styles inutilisés n’atteignent jamais la page finale. Un design cohérent imposé par le système lui-même. Pour une seule personne, chaque minute économisée sur des tâches annexes compte.

Déploiement : conteneurs

Application conteneurisée (Docker), déployée de manière reproductible et portable.

Pourquoi : le même environnement en local et en production, pas de « ça marche chez moi », et la possibilité de migrer l’ensemble vers un autre serveur en trente minutes si nécessaire. La portabilité est une forme d’indépendance.

Ce que cela m'a appris

• La stack ennuyeuse gagne. Astro, SQLite, Tailwind, conteneurs — tout est mature, bien documenté et stable. Rien ne casse au moment le moins attendu.
• L’hébergement en UE est prêt pour la production. Le mythe « il faut aller sur un grand cloud américain pour être pris au sérieux » n’est qu’un mythe.
• L’IA locale est réaliste. Pas besoin de confier ses données à une API externe pour obtenir de bonnes traductions.
• Une seule personne peut lancer un produit qui ressemble à celui d’une équipe. Le temps est une ressource plus précieuse que l’argent, donc chaque choix ici protégeait précisément le temps.

Voir en direct. Questions concernant l'approche technique — hello@cutty.dev, je réponds le jour même.