Le bon outil au bon endroit : Qu'est ce que j'ai mis sur mes serveurs ?

C’est fou ce qu’on peut faire avec un simple VPS. Mais encore faut-il savoir quoi y installer, comment, et surtout où. Parce que quand on commence à auto-héberger ses services, une question revient vite : "Qu’est-ce que je garde ? Qu’est-ce que je jette ? Et dans quoi je m’investis vraiment ?"

Cet article fait partie de la Quête 2 : Construire son open stack personnel, dans mon arc d’automatisation. On ne va pas encore parler de l’infrastructure (ça arrive dans l’article suivant), mais plutôt des outils que j’ai choisis pour construire ma stack numérique personnelle.

Pourquoi j’ai voulu choisir moi-même mes outils

Avant d’avoir un VPS, j’utilisais Make, Supabase Cloud, Zapier, Notion… le genre d’outils super pratiques, mais qui finissent par te faire te sentir prisonnier.

• Le coût devient vite problématique dès que tu veux scaler un peu.
• Les limitations sont frustrantes (nombre de scénarios, d’actions, de lignes…).
• Et surtout, tu n’es jamais vraiment chez toi.

Comme le dit très bien le livre Read Write Own, le Web 2.0 nous a promis des merveilles gratuites, avant de refermer les portes une fois qu’il avait assez d’utilisateurs. C’est exactement ce que j’ai vécu avec Make : changement de politique, limitations, abonnement obligatoire.

Ça me l’a fait aussi avec Supabase Cloud. J'avais hébergé mon n8n dessus pour sécuriser mes accès si mon VPS crashait. Mais un jour, mon accès a été coupé : trop d'exécutions pour le plan gratuit, et je ne payais pas. Résultat : j’ai dû reconstruire mon n8n de zéro.

Même chose avec Notion. C’est une super promesse… mais il devient lent, complexe, et surtout il n’est pas auto-hébergeable. Et plus tu y investis de temps, plus tu deviens dépendant. Le piège parfait. Il fallait que je parte tant qu’il était encore temps.

C’est là que j’ai découvert l’auto-hébergement. Et là, tout a changé.

Je me suis cassé les dents sur l’installation de n8n en ligne de commande (Docker, base de données, accès sécurisé, tout ça en ligne de code Linux… un enfer quand on débute). Mais quand j’ai trouvé Coolify, ça a été le game changer.

Pourquoi Coolify ?

• Parce que je voulais une interface simple pour déployer mes services.
• Parce que Docker isole chaque outil dans un conteneur, et donc si quelque chose plante, ça n’impacte pas tout le reste.
• Parce que je pouvais tout centraliser depuis un seul endroit, sans taper 40 lignes de commandes à chaque fois.

Coolify m’a donné ce que je cherchais : du confort, de la clarté et une organisation pour mon infra.

Ma stratégie pour choisir les bons outils

Quand on commence à construire sa stack (la "stack", c’est l'organisation de son système : quels outils on utilise pour quoi), on a envie d’installer plein de choses. Mais avec le temps (et mes limites matérielles), j’ai appris à sélectionner intelligemment. Voici ma boussole de choix.

📊 La métaphore du corps humain

Pour bien visualiser, j’ai imaginé mon stack comme un corps humain. Voici comment chaque outil prend vie dans mon écosystème

🔍 Comparaison des outils testés (ou évités)

• WordPress vs Ghost : j’ai un blog principal sous WordPress (matthieucousin.com) pour mes portfolios photos, vidéos de voyage, etc. C’est lourd, mais hyper customisable. Mais pour mon blog d’exploration perso et de documentation technique (world.matthieucousin.com), je voulais un truc minimaliste et rapide. Ghost me permet d’écrire en Markdown, de publier vite, et de garder le flow. WordPress me ralentissait trop, brisait mon élan et ma créativité en "plomberie technique".
• Supabase vs NoCodeDB : NoCodeDB a un super éditeur visuel. Mais comme je ne fais pas encore de requêtes manuelles fréquentes ou de CRM complexe, je préfère pour l’instant rester avec Supabase comme seule base. Il est plus lourd, oui. Il prend des ressources. Mais il est aussi très complet, intuitif, et scalable.
• Coolify vs UnosHost/RunTP : les autres sont cools aussi, mais Coolify coche toutes les cases sans conflit de proxy (tant qu’on comprend ses besoins). Et surtout : la stabilité avec Docker, c’est inestimable. Attention cependant : certains services comme Discourse ne sont pas encore supportés nativement. Renseignez-vous bien sur la compatibilité.

🧠 Mon critère principal : auto-hébergeable

Je privilégie des outils que je peux garder dans le temps, sans abonnement caché, sans surprise. Parce qu’à force d’additionner les services cloud à 10€/mois, on se retrouve à payer plus cher qu’un serveur complet, et sans garantie de pérennité.

Mais avoir un serveur, ce n’est pas tout. Il faut penser sécurité (j’y consacre un article entier) et sauvegardes (article à venir).

Je veux pouvoir démarrer, sauvegarder, restaurer, et migrer. Être le maître de mes outils, pas un simple utilisateur dans un système qui change les règles en cours de route.

Oui, je perds un peu en mobilité. J’investis du temps dans la mise en place. Mais au final, je gagne en stabilité, en autonomie, et en sérénité.

• J’ai choisi Supabase parce qu’il repose sur PostgreSQL, une techno solide et prometteuse.
• J’ai choisi n8n parce que c’est le service le plus personnalisable, où l’on peut tout faire, même via requêtes HTTP brutes si besoin.
• J’ai choisi Ghost pour sa sobriété, sa légèreté et son alignement avec mes besoins : écrire, publier, basta.

Oui, il y aura toujours des outils plus récents, plus cools, plus trendy. Mais à un moment, il faut choisir ses armes et les maîtriser. Ne pas passer sa vie à tester, mais à construire.
NB: C’est un peu le problème de toutes les nouveautés IA du moment : on saute d’un outil à l’autre sans construire. On passe plus de temps à tester qu’à produire..

🧭 Dans le prochain article, on parlera de la répartition concrète des services entre mes VPS : comment j’ai choisi mes offres chez Contabo, et pourquoi j’ai décidé de séparer les rôles entre maître et agents.

On commence à monter un petit empire…