Pourquoi nous avons construit Servor autour du Plan‑Execute‑Verify

L'erreur originelle des copilotes d'infra

Les premiers agents IA qui touchaient à l'infrastructure suivaient un schéma simple : on leur posait une question, et ils répondaient avec une commande shell à exécuter. C'était séduisant — et catastrophique. Un seul prompt mal interprété, et hop, rm -rf / sur un serveur de production. Pas exactement le moment où on a envie de découvrir que son agent n'avait pas compris la nuance entre staging et prod.

Nous avons construit Servor en partant de cette frustration. La règle qui guide toute l'architecture tient en trois mots : Plan, Execute, Verify. Et jamais dans un autre ordre.

1. Plan — annoncer avant d'agir

Le copilote de Servor n'a qu'un seul outil : exécuter une commande. Pas de connecteur magique, pas d'API cachée. Quand vous lui demandez « mets à jour nginx sur les trois serveurs européens », il ne peut rien faire d'autre que proposer des lignes de commande, une par une, et attendre.

Avant chaque exécution, l'interface vous montre :

• la commande exacte, telle qu'elle partira — pas une paraphrase ;
• le serveur ciblé et l'utilisateur système sous lequel elle tournera ;
• la classe de risque attribuée à la commande : lecture, modification réversible, ou opération destructrice ;
• le mode d'approbation en vigueur, modifiable en cours de session.

Trois modes coexistent. Ask : le copilote répond, analyse, explique, mais n'exécute rien. Plan, le mode par défaut : chaque commande passe par votre validation. Auto : le copilote enchaîne, et ne vous interrompt que sur une commande classée destructrice.

Quand une séquence mérite d'être figée, elle ne l'est pas par l'IA mais par un runbook : une suite de commandes relue, versionnée, rejouable. Servor en livre 27 officiels — nginx, Caddy, PostgreSQL, Redis, Docker, durcissement SSH, fail2ban, UFW, WireGuard, et le reste. Un runbook, c'est de la documentation exécutable ; un échange avec le copilote, c'est une conversation. Les deux ont leur place, mais ce ne sont pas les mêmes objets.

2. Execute — signé côté navigateur, vérifié côté machine

Ici se joue la partie la plus contre‑intuitive de l'architecture : ce n'est pas le serveur de Servor qui exécute. L'outil run_command est remonté au navigateur, qui classe le risque, applique la politique du mode, obtient votre accord, puis signe la commande avec une clé Ed25519 dérivée de votre clé de coffre.

Ce que ça change concrètement :

1. l'API relaie la commande signée verbatim — elle ne peut pas la réécrire sans casser la signature ;
2. l'agent installé sur la machine cible vérifie la signature localement avant d'exécuter quoi que ce soit ;
3. la sortie standard, la sortie d'erreur, le code de retour et la durée sont capturés et rangés dans l'historique unifié, quelle que soit l'origine de la commande — manuelle, IA, runbook ou terminal.

Tout passe par l'agent, qui ouvre lui‑même une connexion sortante vers le plan de contrôle. Aucun port entrant à ouvrir, et rien qui ressemble à un SSH piloté depuis nos serveurs : le SSH ne sert qu'à l'amorçage, le temps d'installer l'agent.

La liste de commandes interdites : la défense en profondeur

Même en mode Auto, certaines commandes sont refusées quel que soit votre accord. Pas par politique, par code : une analyse syntaxique légère inspecte chaque commande avant relais et la rejette si elle correspond à un motif interdit. rm -rf /, écriture disque brute vers /dev/sd*, modification de /etc/passwd, /etc/shadow ou /etc/sudoers, fork bombs. Le contrôle est appliqué deux fois : côté plan de contrôle, et de nouveau côté agent.

Ce que Servor ne fait pas — et qu'il vaut mieux dire

Servor ne prend pas d'instantané et ne restaure rien. Il n'y a pas de rollback automatique caché derrière un bouton. Une opération destructrice reste destructrice : c'est à votre stratégie de sauvegarde de rattraper le coup, pas à nous. On préfère l'écrire noir sur blanc plutôt que de laisser croire à un filet qui n'existe pas.

3. Verify — la confiance, c'est ce qu'on prouve

L'étape la plus négligée, et celle qui change tout. Le verify, c'est ce qu'on aurait dû faire après chaque intervention manuelle mais qu'on a « oublié » parce qu'on était sûr de nous. Le copilote, lui, n'a pas d'ego : on lui demande de prouver, il exécute une commande de lecture, et vous lisez la sortie.

Concrètement, un verify ressemble à :

• une commande qui doit retourner un code 0 (ex. nginx -v suivi d'un grep sur la version attendue) ;
• un systemctl is-active sur l'unité qu'on vient de toucher ;
• un curl -sS -o /dev/null -w "%{http_code}" https://… sur l'endpoint public ;
• la vérification d'un fichier généré, de sa taille ou de son empreinte.

Et la vérification ne s'arrête pas à la fin de la session. Les monitors de Servor — HTTP, TCP, ping, SSH, DNS, certificat SSL, espace disque, présence de processus, script personnalisé — continuent de regarder, avec une hystérésis configurable pour ne pas déclencher sur un hoquet. C'est le verify qui survit à l'opérateur.

Le journal d'audit signe tout

Chaque commande est consignée dans le journal d'audit, chaîné par empreintes à l'entrée précédente. Une modification ou une suppression sur une entrée passée ? Le trigger PostgreSQL append‑only refuse. Six mois plus tard, un auditeur peut exporter la chaîne et vérifier qu'elle tient. Le ledger est plus dur à corrompre que vos opérateurs.

Et la latence dans tout ça ?

Question légitime : si on doit lire, valider, exécuter, vérifier, on ne tient plus la cadence d'un incident en cours. Réponse : le mode Auto sert précisément à ça, avec des garde‑fous pré‑négociés qui, eux, ne se désactivent pas. Et pour les opérations courantes — installer un service, redémarrer une unité, renouveler un certificat — les runbooks officiels font le travail sans qu'on ait à convaincre un modèle.

L'objectif n'est pas de ralentir vos opérations. C'est de rendre l'imprudence coûteuse en clics et visible dans le journal. Les garde‑fous réduisent le risque ; ils ne le suppriment pas, et l'opérateur reste responsable de ce qu'il approuve.

Pour aller plus loin

Si vous voulez voir comment cette discipline cohabite avec une architecture zero‑knowledge — où Servor opère sur vos serveurs sans jamais connaître vos identifiants en clair — lisez notre article sur l'implémentation zero‑knowledge. Si vous voulez essayer, créez un compte Free, ajoutez un serveur de test, et restez en mode Plan le temps de vous faire une opinion.