Choisir une pile technologique qu’on peut maintenir seul.

Dans Choose Boring Technology, Dan McKinley accorde à une entreprise « environ trois jetons d’innovation » à dépenser en nouvelles technologies, et soutient que le coût à long terme de garder un système en marche dépasse de loin l’inconfort de bâtir avec des outils connus. Ennuyant, pour lui, veut dire que les façons de tomber en panne sont connues. Postgres, Python et cron sont ennuyants. C’est justement l’idée.

Une entreprise d’une personne a moins de jetons que ça, sans doute un seul. Dépensez-le dans le produit. Si le produit est un outil de prise de rendez-vous pour cliniques dentaires, la nouveauté va dans la logique d’horaire; la base de données, le cadriciel web et le déploiement doivent être des choses que vous pourriez réparer à moitié endormi.

Le test pratique : quand cette pièce casse à 23 h, pouvez-vous trouver la cause dans ses journaux sans ouvrir la documentation? Sinon, elle n’est pas encore ennuyante pour vous, peu importe sa popularité.

Postgres couvre la plupart des besoins pour lesquels les petits SaaS ajoutent des services. Chacun de ces choix retire une chose à faire rouler :

• Tâches en arrière-plan : une file qui stocke ses tâches dans Postgres, comme GoodJob ou Solid Queue pour Rails, pg-boss pour Node ou Procrastinate pour Python. Les tâches sont des lignes, elles survivent aux redémarrages et s’inspectent en SQL.
• Travail planifié : un déclencheur de type cron qui appelle une route HTTP de l’appli vaut mieux qu’un processus planificateur à part.
• Sessions et limites de débit : des témoins signés, ou une petite table avec une colonne d’expiration. Un serveur de cache se justifie quand vous mesurez une requête trop lente, pas avant.
• Recherche : la recherche plein texte de Postgres (tsvector, to_tsquery) suffit pour un catalogue de dizaines de milliers de lignes, sans grappe de recherche.
• Fichiers : un compartiment de stockage objet, jamais le disque local de l’appli, qu’un redéploiement peut remplacer.
• Un seul code source : un monolithe bien rangé, pas des services qui se parlent par le réseau. Découper plus tard est une refactorisation; refusionner des services est une migration.

L’argent est le coût visible d’une composante. Pour un fondateur seul, le temps est le plus gros, et on l’écrit rarement. Les fourchettes ci-dessous sont nos estimations, pas des mesures : elles supposent une petite appli en production, quelques heures d’incidents réparties sur l’année, des mises à jour de dépendances mensuelles et les cycles de mise à niveau de la section suivante. Servez-vous-en pour comparer des options, pas pour budgéter.

Les environnements d’exécution et les bases de données cessent de recevoir des correctifs de sécurité à des dates connues. Inscrivez-les à l’agenda le jour où vous choisissez une version. Les trois que vous risquez le plus d’utiliser :

• Node.js a changé son calendrier : à partir de Node 27, chaque version devient LTS et est prise en charge 36 mois après sa première version Current. En production, n’utilisez que des versions LTS.
• Python donne à chaque version environ deux ans de corrections de bogues, puis des correctifs de sécurité jusqu’à cinq ans après sa sortie.
• PostgreSQL prend en charge chaque version majeure pendant cinq ans et publie des versions mineures au moins tous les trois mois. Une mise à niveau mineure exige seulement de nouveaux binaires et un redémarrage; une majeure exige pg_upgrade ou un export suivi d’une restauration.
• Un rythme tenable seul : appliquez les mises à jour mineures et correctives chaque mois, toujours le même jour. Faites une seule mise à niveau majeure par année par composante, et jamais deux la même semaine, pour qu’une régression n’ait qu’un suspect.

Un fondateur seul ne regarde pas de tableaux de bord. Ne mettez en place que des signaux qui arrivent tout seuls, assez rares pour que vous agissiez sur chacun.

• Les erreurs par courriel, regroupées. Un message par nouvelle sorte d’erreur, pas un par occurrence. Si vous en ignorez plus de quelques-unes par semaine, corrigez-les ou faites-les taire; une boîte qu’on survole ne sert à rien.
• Une vérification de disponibilité externe sur une route qui touche la base, aux quelques minutes. Elle attrape ce que le suivi d’erreurs dans l’appli ne voit pas : une appli qui ne roule plus du tout.
• Des alertes de sauvegarde. Une sauvegarde en échec doit vous avertir le jour même. Aucune sauvegarde réussie depuis deux intervalles aussi : c’est ainsi qu’on voit une tâche qui s’est arrêtée sans bruit.
• Un coup d’œil mensuel aux requêtes lentes. Avec l’extension pg_stat_statements, select query, mean_exec_time from pg_stat_statements order by mean_exec_time desc limit 10 est toute la revue. Vérifiez que votre hébergeur la permet; chez Canner, les extensions exigent l’instance Postgres dédiée.
• À laisser pour plus tard : le traçage distribué, les chaînes de métriques sur mesure, l’envoi des journaux à un deuxième fournisseur. Ça paie avec beaucoup de services et beaucoup de monde.

Si vous hésitez entre une plateforme et un serveur que vous gérez vous-même, PaaS, VPS ou Kubernetes compare les trois en détail.

• Deux langages en production. Chaque environnement d’exécution double le calendrier de mises à niveau ci-dessus.
• Une base que vous n’avez jamais restaurée. Choisissez un hébergeur où restaurer tient en un bouton ou une commande, et essayez-le avant d’en avoir besoin.
• Écrire votre propre authentification. Stockage des mots de passe, réinitialisation, fixation de session : ce sont des problèmes résolus; utilisez l’authentification de votre cadriciel ou un service hébergé.
• Gérer vous-même des services avec état pour économiser 10 $ par mois. À trois à six heures par mois pour un Postgres maison, la version gérée se paie dès que votre temps vaut plus que quelques dollars de l’heure.
• Des microservices pour une équipe future. Embauchez l’équipe d’abord. Un monolithe propre se découpe plus facilement qu’un système distribué se refusionne.
• La toute dernière version majeure dès sa sortie. Attendez quelques versions mineures; le projet Node lui-même ne recommande que les versions LTS en production.