À propos · Servor
Servor est né d’une frustration partagée par toute personne qui a déjà passé une nuit blanche sur une opération qui aurait dû prendre cinq minutes — aggravée par une génération d’agents IA qui balancent rm -rf sans tousser. On voulait un agent qui réfléchit avant d’agir, et qui prouve ce qu’il a fait après. On a construit Servor.
Périmètre
Servor exploite le serveur lui-même : y accéder, y mener l’opération, surveiller la machine, dire ce qui se passe, garder la trace de qui a fait quoi. Tout ce qui est de l’autre côté de cette ligne y reste, volontairement.
Dans le périmètre
Hors périmètre
Exploiter, pas déployer. Les deux catégories sont voisines — on peut livrer son application avec un outil et exploiter la machine en dessous avec Servor.
Principes
Ce sont des contraintes avant d’être des valeurs : chacune existe dans le code comme quelque chose que nous ne pouvons pas faire, pas comme quelque chose que nous promettons.
Le zero-knowledge est l’architecture de base, pas une ligne sur un slide. La phrase secrète, la clé dérivée et la clé privée ne quittent jamais le navigateur, et chaque commande y est signée avant d’être relayée. Vous ne nous faites pas confiance pour garder vos identifiants : un plan de contrôle entièrement compromis ne peut ni les lire, ni forger une exécution.
Chaque commande est classée par risque, validée selon le mode choisi, puis consignée avec sa sortie et son code de retour. Les garde-fous réduisent le risque d’une opération automatisée ; ils ne l’éliminent pas, et l’opérateur reste responsable. Ce que nous pouvons garantir, c’est qu’il ne se passe rien que vous ne puissiez relire après coup.
Nous écrivons le code que nous voulons encore maintenir dans dix ans : une stack stable, pas de framework de l’année, pas de dépendance abandonnée deux versions plus tard. L’exploitation de serveurs n’est pas un terrain de jeu pour la nouveauté gratuite.
Notre conviction
L’agent IA n’est pas là pour remplacer l’ingénieur d’infrastructure. Il est là pour lui rendre son temps — automatiser ce qui se répète, structurer ce qui est complexe, rendre la main là où c’est critique.
Ce qui implique de dire aussi la partie ingrate : le copilote propose, vous validez, et vous restez responsable de ce qui tourne sur vos machines. Les garde-fous rendent la mauvaise commande beaucoup moins probable. Ils ne la rendent pas impossible.
Roadmap
C’est un état du code, pas un calendrier de lancement. Rien n’est daté ci-dessous, et rien n’y figure avant de fonctionner.
Livré
V1
Ensuite
Sans date
Nous n’annonçons pas de date — ce qui est écrit ici est ce qui tourne.
Une question, une suggestion, une critique ?
Une seule adresse, lue par les personnes qui écrivent le code.