Pourquoi Zerolith : mettre en ligne sans devenir sysadmin

Les autres articles de ce blog sont des tutoriels. Celui-ci est le premier qu'on écrit, et il sert à autre chose : dire pourquoi la plateforme existe, ce qu'on ne fera pas, et ce qu'on aimerait ajouter ensuite.

Le problème qu'on essaie de résoudre

Mettre une petite application en ligne demande aujourd'hui des compétences qui n'ont rien à voir avec celles qui ont servi à l'écrire.

En gros, il y a deux options, et aucune des deux ne convient vraiment à un petit projet.

La première, c'est la machine à soi, un VPS à quelques euros. Il faut l'installer, le mettre à jour, le surveiller, s'occuper du certificat, du pare-feu, des sauvegardes, et se rappeler six mois plus tard comment on avait bricolé tout ça. La facture est prévisible, d'accord. Mais le travail ne s'arrête jamais, et il retombe entièrement sur quelqu'un qui voulait juste que son code réponde à une URL.

La seconde, c'est le gros fournisseur cloud. Techniquement il n'y manque rien. Sauf que la console suppose un spécialiste, qu'il faut avaler trois douzaines de concepts avant de déployer quoi que ce soit, et surtout que la facture est ouverte : on donne une carte bancaire, et on découvre le montant du mois à la fin du mois. Une entreprise avec une équipe finops s'en accommode. Un particulier, une association ou une startup de trois personnes, beaucoup moins, et c'est souvent la vraie raison pour laquelle le projet ne sort jamais.

Il manque quelque chose entre les deux : un endroit où poser un bout de code qui répond à une URL, sans rien administrer, et dont le coût ne peut pas dépasser ce qu'on a mis dessus. C'est ce qu'on construit.

Pour qui c'est fait, et pour qui ça ne l'est pas

On vise les petits projets. Le script qu'on aimerait exposer en API, le webhook derrière un formulaire de contact, le prototype qu'on veut montrer à trois personnes avant de savoir s'il mérite mieux, le POC interne, la première version d'un produit.

Et on vise surtout des gens qui ne sont ni développeurs d'infrastructure ni administrateurs système. Quelqu'un qui sait écrire, ou faire écrire, une fonction Python de trente lignes, et qui n'a aucune envie d'apprendre Kubernetes pour la mettre en ligne. Il n'y a rien à provisionner ni à dimensionner : l'espace de travail est créé au premier déploiement, et il est cloisonné du reste de la plateforme.

En revanche, ce n'est pas fait pour tout. Une charge permanente à fort trafic reviendra moins cher sur une machine louée au mois ; c'est de l'arithmétique, et on l'écrit sur la page tarifs plutôt que d'attendre que vous le découvriez. Un binaire compilé, un service qui garde un état en mémoire entre deux requêtes, un processus qui doit tourner en continu : mauvais outil. Le bon cas, c'est du code qui s'exécute quand on l'appelle et qui n'existe pas le reste du temps.

Une facture qui ne peut pas déraper

C'est la partie qui compte le plus, et c'est un choix d'architecture avant d'être un argument commercial.

Le compte marche au crédit prépayé. Vous créditez, la consommation débite, et à zéro plus rien ne démarre. Ce n'est ni une alerte ni un quota vérifié après coup : la vérification se fait au bord du réseau, avant que la requête n'atteigne quoi que ce soit. Un appel non authentifié ne réveille aucun conteneur, un compte à sec non plus. Le solde ne peut pas passer sous zéro, donc il n'y a pas de mauvaise surprise en fin de mois. Il n'y a d'ailleurs pas de facture de fin de mois du tout.

Le reste suit de là. Une fonction au repos n'a aucun conteneur en vie, donc ne coûte rien. Le temps d'exécution est compté à la seconde. Les prix sont unitaires et publics : 0,000004 € par Gio-seconde de mémoire réservée, 0,0000125 € par vCPU-seconde, 0,0000004 € par appel.

Une précision qu'on préfère donner nous-mêmes, parce qu'elle ne se devine pas : vous ne payez pas la durée de vos appels, vous payez la durée de vie du conteneur. Après le dernier appel, il reste debout une minute et demie environ avant de disparaître. La forme du trafic compte donc autant que son volume. Cinq mille appels groupés en rafales coûtent quelques millièmes d'euro ; les mêmes cinq mille étalés un par un, chacun isolé, en coûtent moins d'un. Dans les deux cas on reste très loin d'un abonnement mensuel, et dans les deux cas le plafond est le crédit qui reste sur le compte.

Le crédit offert à l'inscription (1 €, sans carte bancaire) couvre un projet de cette taille pendant des années. C'est volontaire : on préfère qu'un prototype qui n'intéresse personne ne coûte rien à son auteur plutôt que de lui facturer un forfait mensuel pour du vide.

L'agent IA comme interface d'administration

Une plateforme sans administration, ça reste une plateforme avec une API. Quelqu'un doit toujours traduire « je veux que ce script réponde à une URL » en appels d'API, et c'est exactement le genre de travail qu'un agent fait bien.

Zerolith expose donc un serveur MCP distant (Model Context Protocol), managé, connecté à votre compte en OAuth 2.1 : pas de clé API à coller dans un fichier de configuration, pas de secret qui traîne sur le disque. N'importe quel client qui parle MCP peut s'y brancher, que ce soit Claude ou Claude Code, Codex, Cursor, VS Code, Zed, ou l'agent que vous avez écrit vous-même. L'agent voit alors les mêmes actions que vous : écrire la fonction, la déployer, l'appeler, lire ses journaux et ses métriques, créer une base, regarder ce que ça consomme.

Rien n'oblige à passer par là. Le tableau de bord et l'API font tout ce que fait l'agent, et les deux chemins mènent aux mêmes fonctions. Mais quand on n'est ni dev ni ops, l'écart entre lire une documentation d'API et décrire ce qu'on veut n'est pas mince.

Ce qu'on ajoute, et selon quel critère

Le critère tient dans une question : est-ce que l'absence de cette brique oblige l'utilisateur à retourner gérer un serveur ? Si oui, elle a sa place. Sinon, elle attend.

C'est ce raisonnement qui a donné la base de données privée. Une fonction est sans état, et sans état la moitié des projets s'arrêtent là ; il fallait donc un endroit où écrire. C'est une base compatible SQLite, privée, dans votre propre espace, réservée à vos fonctions, répliquée vers un stockage objet, qui dort quand personne ne l'interroge et dont vous pouvez sortir un dump complet quand vous voulez. Le même raisonnement a donné le déclenchement par cron, les secrets en écriture seule, et les noms de domaine personnalisés avec leur certificat TLS géré.

Ce qu'on espère ajouter ensuite

Ce qui suit est une intention, pas un calendrier. On le publie quand même, parce que quand on choisit une plateforme on a le droit de savoir dans quelle direction elle va.

• Un stockage de fichiers. Une fonction qui doit conserver un fichier, une image envoyée, un PDF généré, un cache, n'a que la base pour ça aujourd'hui, et la base n'est pas faite pour. Un espace de stockage simple, attaché au compte comme l'est déjà la base, c'est la brique qui nous est demandée le plus souvent.
• Le dépôt d'un bundle complet. On déploie aujourd'hui du code qui s'appuie sur les bibliothèques déjà présentes dans l'image du langage. C'est confortable, et ça bloque net dès qu'il faut une dépendance qui n'y est pas. Pouvoir envoyer une archive avec ses propres dépendances ouvrirait tout l'écosystème d'un langage, sans revenir pour autant à la construction d'images par utilisateur.
• D'autres langages. Python et Node.js aujourd'hui. Les runtimes sont construits sur un contrat unique et minimal, une requête entre et une réponse sort, ce qui rend l'ajout d'un langage assez mécanique.
• D'autres pays d'Europe. La plateforme est hébergée en France et on l'assume (voir la page sécurité). Pouvoir choisir la région de ses fonctions ailleurs en Europe est la suite logique, pour la latence comme pour les contraintes réglementaires de certains projets.

Aucun de ces quatre points n'a de date. Deux existent déjà en brouillon, deux sont encore des idées. L'ordre de sortie dépendra de ce qu'on nous demandera.

Dites-nous ce qui vous manque

C'est le point le plus utile de cet article. On est une toute petite équipe, et on construit pour des projets qui ne ressemblent pas forcément aux nôtres. La brique qui vous bloque aujourd'hui est probablement plus importante que celle qu'on avait prévu d'écrire la semaine prochaine, encore faut-il qu'on l'apprenne.

Une idée, un besoin, un cas d'usage qui ne rentre pas, un prix qui ne tient pas la route chez vous : écrivez à contact@zerolith.io. On lit tout, et on répond.

Et si vous préférez commencer par du concret plutôt que par une déclaration d'intention, la documentation déploie une première fonction en quelques minutes, avec assez de crédit sur le compte pour ne pas avoir à y penser.