PaaS, Coolify, Terraform et IA : Comment gérer son infra en 2026 quand on lance une startup

J’ai créé une première boite qui a bien marché il y a maintenant 14 ans et j’ai pu faire monter cette boite de 0 a plus de 700 employés.

Vous imaginez bien que les contraintes quand on démarre, les méthodes de travail, les outils, sont très loin de ce qu’on peut rencontrer dans le cadre normal de la plupart des boites que vous connaissez. On ne travaille pas de la même façon à 0 et à 700.

Faut être rapide, faut construire une application que les gens aient envie d’utiliser sans cramer des montagnes de fric qu’on n’a pas encore gagné et c’est un peu pour toute ces raisons là que j’ai choisi de ne pas m’occuper de toute la partie infra logicielle au début. Ce que j’appelle l’infra, c’est les serveurs, les bases de données, les sauvegardes, tout ce qui est invisible pour la majorité du gens mais essentiel pour qu’une application puisse fonctionner.

C’est essentiel, mais globalement tout le monde s’en fout. C’est pas ça qui permet de vendre un produit. Une bonne infra mais avec une application nulle, ça ne fonctionne pas. Et si on passe trop de temps sur l’infra, on fait pas un bon produit. Evidemment faut quand même que ça marche mais on peut le déléguer, je dirais même qu’on doit le déléguer. L’infra doit être un non sujet pendant plusieurs années quand on démarre.

Donc à l’époque j’ai choisi d’utiliser un PAAS, une plateforme as a service, qui justement, permet de déléguer toute l’infra à des gens dont c’est le métier. Et dès que je voyais des gens qui démarrait des entreprises mais qui commençaient à me parler de Kubernetes ou de Docker, je leur disais systématiquement que c’était beaucoup trop tôt pour parler de ça. J’ai toujours vu ça comme un mauvais signal dès qu’une personne passait son temps à m’expliquer comment il faisait son produit, et pas ce qu’il faisait comme produit. La nuance est importante.

Maintenant, je suis en train de changer d’avis. Sauf pour Kube. Je viens de lancer un nouveau produit, Kula, le monde a changé, la création de boite à changé et il est peut-être temps de revoir certains choix.

On va donc parler de PAAS, de coolify, de dokploy, de easypanel, de terraform, d’IA et de comment on peut déployer des applications dans le monde d’aujourd’hui.

PAAS or not PAAS

En 2014 j’ai écrit un article sur exactement ce sujet. Parce qu’en 2014 on quittait Heroku, notre PAAS de l’époque pour aller sur un serveur OVH.

Un PAAS c’est, en très simplifié, un environnement d’execution qui permet de faire tourner vos applications. Un PAAS gère à votre place les serveurs web, les bases de données, les sauvegardes. Il doit permettre de collecter et d’analyser les erreurs qui arrivent, vous signaler si vous êtes à court de mémoire ou de CPU.

On quittait Heroku parce qu’en 2014 on commençait à taper dans les limites de ce que pouvait apporter les PAAS. Parmi les limitations importantes que je pourrais citer :

• Il n’y avait pas de notion de réseau privé.
  Un réseau privé c’est ce qui permet à votre application de communiquer avec une base de données sans repasser par internet. Donc la base de données n’est accessible qu’au sein de votre réseau. La plupart des PAAS ne proposaient pas ça.
• Il n’y avait pas de notion de frontal web.
  Un frontal web c’est un serveur qu’on va placer devant la ou les applications. Ca permet notamment d’avoir différentes applications qui sont utilisés pour différentes partie d’un site web.

En 2014 avec Malt on avait besoin justement de pouvoir router des requêtes Web vers plusieurs applications différentes. Par exemple la page /search était une application à part de celle qui servait la page /profil.

Malgré tout, avec le recul, c’était un choix dangereux. La boite n’avait que 2 ans et j’ai du faire beaucoup d’ops pour reproduire une expérience développeur satisfaisante sur OVH. C’est du temps que j’ai pas passé ailleurs. Heureusement j’avais déjà de l’expérience sur le sujet et une bonne maitrise de certains outils d’automatisation comme Ansible ce qui a limité la casse.
Mais c’était aussi un choix économique. Un PAAS ça pouvait vite couter cher. Chaque ressource (une base de données, un serveur, un processus) est facturé indépendamment. Et en 2014 sur Malt, je peux vous dire qu’on comptait très fort chaque euro dépensé.

Bon, mais je vous parle de Malt en 2014. Ensuite la boite a bien grandi, nous avons doublé de taille chaque année. En 2017 on a embauché notre premier ops. On a commencé à faire du OVH Cloud. En 2018 on est parti chez GCP et on était plus à 100 euros près. Mais c’est pas le sujet d’aujourd’hui. Moi ce qui m’intéresse, c’est le démarrage.

Les PAAS self hosted

Depuis 2024 je suis parti de Malt et j’ai recommencé à créer des produits. J’adore faire ça. Je trouve que les premières étapes sont excitantes. Il faut savoir composer avec les contraintes, faire preuve de créativité.

J’ai lancé d’abord Broadcast en 2024, un service d’envoi de newsletter pour blog statique. Puis Pulse en 2025 pendant que je vivais au Japon, un service d’analytics pour les blogs. Connect en 2026, un service de commentaire as a service (comme Disqus). Writizzy en 2026 également, une plateforme de blog et newsletter, concurrente de Substack ou Beehiiv. C’était, jusqu’à présent, le projet le plus ambitieux et le plus gros.

Et pour tout ces projets j’ai utilisé une nouvelle gamme d’outil que j’ai découvert en 2024, les PAAS self hosted. Ce sont des PAAS, mais ce sont des PAAS qu’on peut héberger soi-même.

J’ai choisi Coolify, dont j’ai déjà parlé dans un ancien article.

Déjà évidemment, ça change le prix. Aujourd’hui je fais tourner Coolify sur deux machines, avec toutes mes applications, toute mes bases de données. Ca représente plus d’une trentaine de ressources et ça me coute 45 euros par mois. Rappelez-vous, je suis revenu dans un mode startup, donc avec très peu d’argent et c’est donc un argument de poids. Aucun PAAS commercial ne peut me permettre de faire tourner toute ces ressources pour ce montant. Ce serait à minima entre 300 et 1000 euros par mois.

J’y perds du temps, ça m’est quand même arrivé d’avoir quelques sueurs froides avec des updates systèmes, des pertes de connexion, des machines qui se mettent en carafes. Mais le fait d’utiliser un PAAS, donc un logiciel qui prend en charge tout le déploiement, le monitoring, les logs est un gain non négligeable. Même si je dois comprendre comment ça marche, j’ai pas l’obligation d’y passer autant de temps que si je devais tout gérer à la main et descendre dans les arcanes du fonctionnement d’un Kubernetes par exemple.

Mais, avec plus de 30 ressources managées, j’ai commencé à ressentir quelques limites et surtout, je me suis rendu compte que peut-être, je faisais peut-être fausse route. Et si l’IA pouvait devenir un excellent ops à ma place ?

Les limites de mon PAAS self hosted

J’adore Coolify, mais il y a quand même des limitations qui sont importantes :

• Coolify ne permet pas d’avoir plusieurs noeuds d’une même application
• Il n’y a pas de gestion des secrets. Toute les variables d’environnements sont en clair. Il faut utiliser un service comme infisical.
• Le monitoring existe mais il reste assez léger.
• Les backups sont uniquement en mode snapshot. C’est à dire que vous faites des photos de la base à intervalle régulière mais en cas de crash, vous perdez toutes les infos depuis le dernier backup.
• c’est du clickodrome. On peut difficilement automatiser le fait de reconstruire des ressources d’autant que l’api est limité.

Ce dernier point, si vous avez une seule application, c’est pas très grave. Mais j’ai déjà beaucoup trop d’applications. Si je dois remonter un serveur entier, il va falloir que je reconfigure tout et j’ai franchement pas envie. J’exagère, la base de données de Coolify est elle même sauvegardé en mode snapshot mais c’est un peu plus pénible et ça ne me permet pas de migrer facilement vers un autre service, comme Dokploy ou EasyPanel.

Alors j’ai testé autre chose. J’ai demandé à l’IA…

l’IAOps

Oui, l’ops ça prend du temps, ça peut être complexe et faut pas se planter. Mais faire du code qui permet d’automatiser son infrastructure, sa topologie réseau, ses sauvegardes, son observabilité, ça reste une excellente idée, bien plus que de faire des dizaines centaines de clicks sur une interface.

Parce que du code ça se versionne. Et je vous dis ça, j’ai déjà fait du Ansible, du Capistrano et des batch shells, donc je découvre pas ça en 2026.
Mais je sais aussi que le code c’est long à produire et encore une fois, c’est du temps qu’on ne passe pas sur le produit. Sauf… si c’est l’IA qui l’écrit.

En Octobre 2026 j’ai décidé de profiter de l’expérience que j’ai acquis sur Writizzy et Broadcast autour de l’envoi d’email pour lancer un autre produit : Kula. Kula c’est un outil d’envoi d’email marketing et transactionnel. Je gère des séquences, de la segmentation, du suivi analytics, de la gestion de la délivrabilité et c’est désormais le backend d’envoi d’email pour Writizzy et Broadcast. Si vous êtes déjà client de sendgrid, mailjet, brevo, ou resend, n’hésitez pas à tester. En plus je suis globalement moins cher.

Sauf que cette fois j’ai pas voulu refaire encore du Coolify pour Kula. J’ai donc utilisé l’IA pour créer des scripts Terraform afin de piloter mon infra (chez Hetzner, Bunny.net et AWS). J’ai ajouté du déploiement continu, du rolling upgrade avec Caddy, des sauvegardes incrémentales avec du WAL, des logs collectés dans dozzle. Et tout ça m’a pris moins d’1h de mise en place.

Je peux remonter mon infra complète plus simplement, je gère et versionne mes secrets avec Sops, j’ai baissé mon RPO de plusieurs heures à 1minute (le RPO c’est la perte de données maximale possible) et je peux tout piloter depuis mon code, en lançant des scripts. Enfin, mon LLM peut tout piloter.

Maintenant, si jamais vous n’avez pas compris RPO, Sops, WAL, rolling upgrade et que globalement ce que je viens de dire vous semble aussi clair que du Chinois, c’est parce que je vous ai peut-être induit en erreur…

L’IA ne fait qu’accélérer ce que vous savez faire

En réalité j’ai pas totalement changé d’avis. Je considère toujours que vous devriez repousser l’ops le plus tard possible mais avec beaucoup plus de nuances qu’avant.

Vous faites de l’ops quoi qu’il arrive, même avec un PAAS, mais une grande partie vous est simplifié, prémaché. Sauf que justement, vous déléguez des choix à des gens qui savent faire sans toujours comprendre les compromis qu’ils ont fait à votre place. Vous n’aviez pas forcément saisi avant aujourd’hui que vos sauvegardes étaient imparfaites. Vous n’aviez pas saisi peut-être que la gestion de vos secrets étaient aux fraises avant que je vous le mentionne.

Créer des projets informatiques c’est faire constamment des compromis entre couts, risques et gains. Et vous pouvez pas maximiser les trois. Peu de risques et beaucoup de gains ca demande beaucoup de budget. Peu de budget pour obtenir beaucoup de gains, c’est forcément parce que vous prenez des risques. Etc… C’est pas un problème à résoudre, ce sont des choix à faire.

Donc s’il vous manque des connaissance générales, si vous décidez de tout faire avec l’IA directement, ça risque de vous envoyer dans le mur parce que vous n’allez pas comprendre les compromis qui ont été faits.
C’est vrai, il n’y a plus autant qu’avant l’argument de la perte de temps. Vous pouvez aller très vite. Mais aller très vite dans le mur c’est pas forcément un avantage.

Dans mon cas, je partais pas de zéro, loin de là. Donc je savais où aller. Je faisais déjà de l’ops en ayant fait le choix d’utiliser Coolify en mode auto hébergé et puis j’avais une certaine expérience, y compris dans des boites bien plus grosses. Je comprends les compromis que je fais.

Quand je dis que je lance un nouvelle boite en utilisant terraform, je fais un raccourci. Je lance des produits depuis 2011. Et depuis mon départ de Malt, j’ai 2 ans dans les pattes avec Hakanai, Writizzy et Kula.
Quand je dis que j’ai mis 1h pour tout mettre en place. C’est vrai, mais j’ai mis 25 ans à apprendre à mettre ça en place en 1h.

Donc laissez moi reformuler.

Si vous n’avez aucune connaissance et expérience de l’ops, de l’infra, prenez un PAAS. Un PAAS très simple que vous n’hébergez pas (Clever Cloud, Scalingo, Sevalla par exemple et je fais exprès de ne pas citer d’alternatives US… mais j’avoue que certaines sont bien meilleures). Le cout restera acceptable et vous aurez l’occasion d’apprendre sur une stack qui est géré pour vous.
(je suis tombé sur koyeb aussi en écrivant l’article mais j’ai du mal à le positionner entre PAAS et IAAS, n’hésitez pas à me donner des infos si vous connaissez)

Si vous avez des connaissances mais que vous restez en phase de prototypage avec encore peu d’applications à gérer, choisissez un PAAS du marché ou un PAAS en self hosted, Coolify, Dokploy ou EasyPanel. Ici vous allez privilégier le cout et la flexibilité.

Si vraiment vous êtes connaisseurs, vous pouvez aller sur du serveur dédié piloté avec du terraform. C’est la version avancé de l’option précédente, orienté sur le cout et la flexibilité.

Dès que vous avez du volume, et plusieurs applications, un peu de complexité architecturale et du budget pour la financer, là vous pouvez commencer à regarder du côté des IAAS (de l’infrastructure as a service), DBAAS etc… Je conseille Scaleway ou Hetzner.

Bref, c’est dur de lancer une boite. C’est encore plus dur d’apprendre tous les métiers nécessaires d’un coup. Même avec l’IA. Ne perdez pas de temps sur ce que vous ne savez pas encore faire. Par contre, dès que vous avez acquis l’expérience, dites-vous que beaucoup de choses qui étaient très consommateurs en temps avant est désormais largement plus accessible. Revoyez vos idées préconçues sur le sujet et testez. Vous serez peut-être surpris.