Comment exploiter plusieurs entreprises à 10 k$ de revenus mensuels avec une stack à 20 $ par mois

 (stevehanov.ca)
64 points par GN⁺ 2026-04-13 | 1 commentaires | Partager sur WhatsApp
  • Stratégie de bootstrapping permettant d’exploiter plusieurs entreprises SaaS générant plus de 10 k$ de MRR avec moins de 20 $ par mois de coûts d’infrastructure, en s’appuyant sur un VPS unique, le langage Go, SQLite et un GPU local
  • Au lieu d’AWS ou d’une orchestration cloud complexe, tous les services tournent sur un seul VPS à 5 à 10 $, afin de se concentrer sur le traitement des requêtes plutôt que sur la gestion de l’infrastructure
  • Choix de Go comme langage backend pour obtenir un processus de déploiement extrêmement simple, avec compilation en binaire unique sans gestion de dépendances, puis déploiement direct sur le serveur
  • Exécution de VLLM sur un GPU local (RTX 3090) pour ramener à zéro le coût du traitement batch IA, tout en réservant les modèles de pointe via OpenRouter aux seules fonctionnalités en contact direct avec l’utilisateur
  • Même sans capital-risque, maintenir les coûts presque à zéro permet d’obtenir une runway pratiquement infinie et de disposer d’assez de temps pour trouver l’adéquation produit-marché

Stratégie de serveurs lean

  • En 2026, la manière « standard » de lancer une web app consiste à provisionner sur AWS un cluster EKS, une instance RDS et une NAT Gateway, ce qui entraîne plus de 300 $ de dépenses mensuelles même sans le moindre utilisateur
  • L’alternative consiste à louer un VPS à 5 à 10 $ par mois chez Linode ou DigitalOcean et à tout faire tourner sur un serveur unique
  • 1 Go de RAM peut suffire si elle est bien utilisée, et en cas de marge insuffisante, un swapfile peut prendre le relais
  • Avec un seul serveur, il est possible de savoir exactement où se trouvent les logs, pourquoi un crash est survenu et comment redémarrer le service
  • La raison de préférer un VPS à AWS tient à des coûts prévisibles et à une architecture simple

Pourquoi choisir Go

  • Python ou Ruby consomment déjà la moitié de la RAM rien qu’avec le démarrage de l’interpréteur et la gestion des workers gunicorn
  • Go offre de bien meilleures performances pour les charges web, un système de types strict et, en 2026, c’est un langage que les LLM comprennent très facilement pour le raisonnement
  • L’avantage central de Go est la simplicité du déploiement : toute l’application est compilée en un unique binaire lié statiquement, construit sur un laptop puis envoyé sur le serveur avec scp pour être exécuté
  • Pas besoin de l’enfer des dépendances avec pip install ni d’environnements virtuels, et il est possible de construire un serveur web de niveau production sans framework obèse
  • Avec la seule bibliothèque standard de Go, on peut écrire un serveur capable de traiter des dizaines de milliers de requêtes par seconde

IA locale : ramener à zéro le coût des traitements batch

  • Si vous avez une carte graphique chez vous, vous disposez déjà de crédits IA illimités
  • Lors de la création de eh-trade.ca, il fallait mener une vaste recherche boursière qualitative en analysant les rapports trimestriels de milliers d’entreprises, ce qui aurait pu coûter plusieurs centaines de dollars via l’API OpenAI
  • À la place, VLLM a été exécuté sur une RTX 3090 (24 Go de VRAM) achetée 900 $ sur Facebook Marketplace, supprimant la nécessité de payer un fournisseur IA
  • Parcours de montée en puissance pour l’IA locale :
    • Commencer avec Ollama : configuration en une ligne de commande (ollama run qwen3:32b), test immédiat de différents modèles et excellent outil pour itérer sur les prompts
    • Passer en production avec VLLM : Ollama devient un goulot d’étranglement sous requêtes concurrentes, tandis que VLLM est radicalement plus rapide grâce à PagedAttention. En envoyant simultanément 8 à 16 requêtes asynchrones, le traitement batch s’effectue en mémoire GPU pour un temps proche de celui d’une seule requête
    • Transformer Lab : quand il faut faire du pré-entraînement ou du fine-tuning, cela peut être réalisé facilement sur du matériel local
  • Pour gérer cela, développement de laconic, un outil de recherche agentique optimisé pour une fenêtre de contexte de 8K, qui « page out » les parties inutiles d’une conversation comme le ferait le gestionnaire de mémoire virtuelle d’un OS, afin de ne garder dans le contexte actif du LLM que les faits essentiels
  • llmhub : outil qui abstrait tous les LLM sous la forme provider/endpoint/apikey, pour gérer sans friction les entrées/sorties texte et image, en local comme dans le cloud

Accéder aux modèles de pointe via OpenRouter

  • Tout ne peut pas être traité en local, et les interactions de chat à faible latence face à l’utilisateur nécessitent des modèles de raisonnement de pointe comme Claude 3.5 Sonnet ou GPT-4o
  • Au lieu de gérer séparément les comptes de facturation, clés API et limites de débit d’Anthropic, Google et OpenAI, tout est unifié via OpenRouter
  • Il suffit d’écrire une seule intégration compatible OpenAI pour accéder immédiatement à tous les grands modèles de pointe
  • Prise en charge d’un routage de secours fluide : si l’API Anthropic tombe en panne, bascule automatique vers un modèle OpenAI équivalent, sans écran d’erreur pour l’utilisateur et sans logique complexe de retry

Un codage IA rentable avec GitHub Copilot

  • Alors que de nouveaux modèles coûteux sortent chaque semaine, de nombreux développeurs dépensent plusieurs centaines de dollars par mois en abonnement Cursor et en clés API Anthropic
  • À l’inverse, même avec Claude Opus 4.6 utilisé toute la journée, le coût mensuel dépasse rarement 60 $
  • Le secret est d’exploiter le modèle tarifaire de Microsoft : acheter un abonnement GitHub Copilot en 2023 et le connecter à VS Code standard
  • Astuce clé de Copilot : Microsoft facture à la requête et non au token, et une « requête » correspond à une saisie dans la boîte de chat. Même si l’agent analyse tout le codebase pendant 30 minutes et modifie des centaines de fichiers, cela ne coûte qu’environ 0,04 $
  • Stratégie optimale : rédiger un prompt détaillé avec des critères de réussite stricts, lui demander de « continuer jusqu’à ce que toutes les erreurs soient corrigées », puis le lancer

Utiliser SQLite comme base de données universelle

  • À chaque nouveau projet, sqlite3 est utilisé comme base de données principale
  • Du point de vue de l’entreprise, on considère souvent qu’un serveur de base de données dans un processus séparé est indispensable, mais en pratique, un fichier SQLite local accessible via une interface C ou la mémoire est plusieurs ordres de grandeur plus rapide qu’un serveur Postgres distant impliquant un saut réseau TCP
  • Malentendu fréquent sur la concurrence : l’idée selon laquelle SQLite verrouille toute la base à chaque écriture est fausse, et Write-Ahead Logging (WAL) permet de résoudre le problème
    • Avec PRAGMA journal_mode=WAL; et PRAGMA synchronous=NORMAL;, lectures et écritures ne se bloquent pas mutuellement
    • Un unique fichier .db sur un disque NVMe peut prendre en charge des milliers d’utilisateurs simultanés
  • Pour simplifier l’implémentation de l’authentification utilisateur, développement de la bibliothèque maison smhanov/auth, qui s’intègre directement à la base utilisée et prend en charge l’inscription, les sessions, la réinitialisation de mot de passe et la connexion via Google/Facebook/X/SAML

Conclusion : construire une startup sans infrastructure complexe

  • L’industrie tech affirme qu’il faut une orchestration complexe, des factures AWS mensuelles énormes et des millions de dollars de capital-risque pour bâtir une vraie entreprise, mais ce n’est pas le cas
  • En combinant un VPS unique, des binaires compilés statiquement, des traitements batch IA sur GPU local et la vitesse brute de SQLite, il devient possible de lancer une startup évolutive en bootstrapping pour le prix de quelques cafés par mois
  • Cela donne au projet une runway infinie, laissant le temps de se concentrer sur la résolution des problèmes utilisateurs plutôt que sur l’angoisse du burn rate

À lire aussi

1 commentaires

 
GN⁺ 2026-04-13
Avis Hacker News

  • Dans les environnements d’entreprise, on considère souvent qu’il faut utiliser un serveur de base de données externe, mais en pratique un fichier SQLite local est bien plus rapide qu’un Postgres distant lorsqu’il communique via l’interface C ou en mémoire
    Bien sûr, SQLite est excellent, mais se connecter à Postgres en Unix domain socket sur localhost élimine presque tout le surcoût réseau
    Ce n’est pas plus difficile à utiliser que SQLite, on profite de toutes les fonctionnalités de Postgres, et l’exécution de rapports, la mise en place de read replicas ou d’une architecture HA sont bien plus simples
    Faire tourner Postgres sur le même serveur que l’application n’a absolument rien à voir avec le fait de surdimensionner en montant un cluster Kubernetes

    • Même sur la même machine, SQLite reste bien plus rapide que Postgres via domain socket (exemple à 100,000 TPS)
      Quand on exécute une monolithic app sur une seule machine, Postgres apporte peu de choses de plus que SQLite
      SQLite peut être étendu directement dans le langage de l’application via les Application functions, et grâce à Litestream, les sauvegardes et la réplication sont bien meilleures
      En revanche, la configuration par défaut n’est pas bonne : il faut séparer les connexions de lecture et d’écriture, et laisser l’application gérer elle-même la write queue
    • En pratique, si l’on exécute 100,000 requêtes SELECT 1, Postgres met 2.77 secondes contre 0.07 seconde pour SQLite (en mémoire), soit un écart énorme (lien du benchmark)
    • J’ai utilisé SQLite avec des extensions dans des scénarios haute performance traitant plusieurs millions de documents par seconde
      Cela aurait été possible avec un serveur distant, mais bien plus complexe
      À la place, la base était placée sur S3 et chaque instance récupérait une copie pour traiter en parallèle. SQLite est une alternative éprouvée quand la performance prime sur les fonctionnalités
    • Dire « on peut utiliser toutes les fonctionnalités de Postgres », n’est-ce pas exactement l’approche YAGNI (You Ain’t Gonna Need It) que critique l’article ?
    • Plus il y a de fonctionnalités inutiles, plus c’est une perte nette. La base idéale ne fournit que ce dont on a besoin

  • Beaucoup pensent qu’il faut dès le départ une configuration complexe avec serverless, Kubernetes, multi-zone HA
    Quand on dit « on peut simplement faire tourner ça sur un VPS bon marché », on reçoit des réponses du type « et le scaling ? », « et les sauvegardes ? », « et la maintenance ? », qui ne font au fond que répéter les slogans marketing du cloud
    Cette attitude ressemble presque à de l’impuissance apprise

    • Quand je travaillais comme consultant, je concevais parfois 25 composants cloud pour des applications de moins de 200 utilisateurs. C’était entièrement le résultat de cette idée que « cloud = complexité »
    • Les acheteurs IT dépensent sans compter l’argent de leur entreprise pour ne pas avoir à comprendre
    • On observe aujourd’hui la même chose dans les workflows à base d’agents. Les données d’entraînement sont remplies de bases de code prévues pour de grandes équipes, ce qui pousse même les petits projets vers des structures énormes
      Par exemple, on finit par mettre Shadcn, Tailwind, React, Zod et Vite sur une SPA avec juste quelques formulaires simples. La charge de maintenance est énorme
      Ce genre de stack peut être la « bonne réponse », mais pas forcément la réponse adaptée au contexte
    • La « génération cloud native » n’a jamais eu l’occasion d’apprendre ce dont une application de base a réellement besoin, à cause des offres gratuites
    • Cela dit, je pense quand même que les sauvegardes sont importantes

  • J’utilise Linode ou DigitalOcean et je ne paie que 5 à 10 dollars par mois. 1 Go de RAM suffit
    On peut encore réduire les coûts en regroupant plusieurs projets sur un serveur dédié
    Par exemple, j’utilise un serveur à 40 euros par mois via les enchères de serveurs Hetzner, sur lequel j’installe Proxmox pour faire tourner plusieurs VM (lien Proxmox)
    Même avec 15 VM, on tombe à 2.66 euros par VM, donc le coût par rapport à l’échelle est très avantageux
    Avec du matériel reconditionné, les sauvegardes sont indispensables, mais de toute façon il les faut déjà
    Hetzner, Contabo ou Scaleway restent des options bon marché

    • Les prix de Hetzner ont augmenté, mais OVH propose un matériel plus récent pour un tarif similaire
    • Je me demande pourquoi utiliser des VM et pas des conteneurs
    • Je me demande aussi comment est géré l’IPv4. Et est-ce commercialement autorisé de louer une grosse VM en tant qu’hyperviseur ?
    • J’ai l’impression que faire tourner ça simplement dans des conteneurs Docker serait plus efficace

  • Je pense que le mode WAL de SQLite est le principal levier d’économie
    Python ou Node peuvent être utilisés aussi bien que Go. Le VPS Hetzner avec 4 Go de RAM et 10 To de réseau coûte autour de 5 dollars par mois
    En revanche, si l’on utilise un serveur dédié, il faut faire des sauvegardes de base de données fréquentes et assumer soi-même la sécurité
    Moi, je configure ça avec Terraform en limitant l’accès SSH à ma seule IP, puis j’installe Tailscale et je ferme le port SSH public

    • Pour les sauvegardes, il est plus sûr d’utiliser un stockage chez une autre entreprise que le fournisseur de VM. Il faut pouvoir restaurer même si le compte est suspendu
      J’utilise Backblaze B2, mais avec Restic il est facile de sauvegarder aussi vers d’autres services
    • Il n’est pas forcément nécessaire de mettre en place une configuration compliquée pour sécuriser SSH. Un mot de passe fort peut suffire
    • J’ai déjà laissé Postgres exposé avec le mot de passe par défaut, et il a été compromis en serveur de bots en une seule journée
      Même récemment, les logs de tentatives SSH se sont remplis en une heure. Désormais, je désactive la connexion par mot de passe et je n’autorise l’accès que via Tailscale
      Un serveur exposé à Internet est vraiment dangereux
    • J’ai du mal à croire qu’un serveur puisse être infecté via SSH en une heure. À moins d’avoir un mot de passe faible ou d’avoir laissé VNC ouvert, ça semble impossible
    • Moi aussi, en migrant un site Django vers Docker Compose, j’ai abandonné Postgres pour SQLite en mode WAL. C’est devenu bien plus simple à gérer et à sauvegarder

  • Je pense que la limite à 1 Go de RAM est inutile. Avec 20 dollars par mois, on peut avoir 8 Go de RAM, utilisables pour le cache ou la base
    Une différence de 15 dollars n’a pas d’impact majeur sur l’exploitation d’une entreprise. Chercher à tout faire entrer dans un VPS à 5 dollars n’aide pas à faire croître le business

    • Mais 15 dollars, ce n’est pas non plus négligeable. Si 1 Go suffit, il n’y a pas de raison de dépenser plus
      À l’époque, on faisait très bien tourner une stack LAMP avec 128 Mo, et les sites web ne sont toujours pas si complexes
    • Avec une latence de lecture NVMe autour de 100 µs, SQLite peut traiter plusieurs centaines de requêtes par seconde
      Même sans cache, on peut absorber 17 millions de requêtes par jour, donc quadrupler l’infrastructure avant ça relève du gaspillage
    • La vraie raison de la limite à 1 Go est de s’entraîner à éviter la suringénierie et à se concentrer sur la valeur client
    • Les systèmes modernes ont une bien meilleure efficacité mémoire grâce à la compression de pages et au swap sur NVMe
      Le Macbook Neo 8 Go en est un bon exemple
    • Je pense aussi que 15 dollars de différence ne sont pas énormes, mais l’essentiel est de minimiser les coûts d’hébergement

  • WebSequenceDiagram a l’air d’un super produit
    Mais plus difficile que l’implémentation technique, c’est de trouver un problème qui a de la valeur et d’atteindre les utilisateurs. C’est là que se trouve la vraie valeur

    • Je me pose la même question. Entre le travail et la famille, la journée est trop courte. Mais quand on comprend un problème métier spécifique, la solution semble parfois évidente
    • Il existe déjà beaucoup de concurrents. Par exemple Excalidraw

  • Je suis abonné à GitHub Copilot depuis 2023, connecté à VS Code, et je l’utilise toujours
    Le point clé, c’est que Microsoft facture à la requête. Même si une seule requête modifie tout le code pendant plusieurs dizaines de minutes, cela ne coûte qu’environ 0.04 dollar
    Du coup, j’écris des prompts très précis, je lui dis de « continuer jusqu’à ce que toutes les erreurs soient corrigées », puis je vais prendre un café. En quelque sorte, Satya Nadella subventionne mes coûts de calcul

    • Mais il existe des cas de suspension de compte pour ce type d’abus à la requête (cas sur Reddit)
    • L’auteur qualifie GPT‑4o et Sonnet 3.5 de SOTA, donc il vaut mieux lire ses conseils sur l’IA avec un peu de prudence
    • (commentaire supprimé) dit ne pas comprendre pourquoi il a été downvoté

  • Je n’ai rien appris de nouveau dans cet article. Cela ressemblait surtout à des conseils de base emballés par une IA
    En voyant seulement le titre, je pensais qu’il serait question de trouver des idées et de réussir un lancement

    • Avec un titre comme « pour moins de 5 dollars par mois », il est normal d’obtenir des conseils de base. Mais étonnamment, beaucoup de gens ne connaissent pas ces choses
    • Dans ce cas, je recommande de lancer un blog. Ce qui vous paraît élémentaire est nouveau pour quelqu’un d’autre
    • Moi aussi, si je pouvais dépenser 5,000 dollars par mois pour en gagner 10,000, je le ferais volontiers. Le vrai problème est de trouver comment générer le revenu
    • La phrase « il faut le raisonnement de pointe de Claude 3.5 Sonnet ou de GPT‑4o » est une trace typique d’un texte IA
    • Mais l’auteur a raison sur l’inflation des ressources : on voit souvent des problèmes solvables avec un simple script Python être résolus de façon excessive avec AWS et Spark

  • Pour ceux qui se posent la question comme moi, MRR signifie « Monthly Recurring Revenue » (revenu mensuel récurrent)

    • C’est surprenant d’être inscrit depuis 16 ans sans connaître MRR
    • Il y a aussi ARR (Annual Recurring Revenue), qui n’est souvent qu’un chiffre gonflé en multipliant simplement le MRR par 12
      J’ai même vu des gens annoncer leur ARR après seulement deux mois d’activité

  • Une approche trop centrée sur le cloud augmente souvent inutilement la complexité et les coûts
    Dans la plupart des cas, un VPS de taille moyenne suffit largement
    Notre entreprise pouvait faire tourner 600,000 pages utilisateur sur un VPS à 30 euros, puis nous avons migré vers AWS pour payer 800 euros par mois. Aucun bénéfice au final
    S’il n’y a pas de raison particulière, mieux vaut conserver l’approche simple des serveurs classiques qui fonctionne depuis des décennies
    Au passage, il me semble que StackOverflow tourne aussi sur quelques serveurs root puissants