Ma configuration OpenClaw : une seule machine capable de créer des sites web

Le site que vous lisez actuellement est maintenu par des agents IA qui tournent sur une petite machine Linux chez moi — et tout le dispositif est conçu pour qu’ils puissent effectuer un vrai travail sans jamais pouvoir tout casser.

Avant toute chose, la partie qui témoigne d’elle-même : cet article est actualisé une fois par semaine par le dispositif même qu’il décrit. Une tâche planifiée réveille un agent OpenClaw ; il relit cette page, corrige ce qui a vieilli, exécute les contrôles de garde et tamponne le résultat. La date « Mise à jour » en haut de cette page est écrite par cette tâche hebdomadaire — personne ne la saisit à la main. Si cette date est récente, c’est que le pipeline illustré dans ces schémas a tourné de bout en bout au cours des sept derniers jours.

Toute la machine en un coup d’œil

Tout vit sur une seule machine. Les modèles fournissent des jetons — surtout l’API cloud bon marché de DeepSeek de nos jours, avec des modèles locaux en secours — la passerelle OpenClaw les transforme en agents dotés d’outils, les agents modifient du contenu en texte brut, un générateur déterministe construit le site, et un unique script verrouillé constitue la seule route vers le serveur.

Ce que vous obtenez au final

L’état final, avant de parler configuration :

• « Rédige-moi un article sur X » dans le chat → un agent écrit un article Markdown dans le dossier content/ du site, en respectant le schéma de frontmatter et le style maison, puis reconstruit l’aperçu local.
• « Déploie-le » → l’agent exécute le script de déploiement, qui par défaut effectue une simulation : il montre exactement quels fichiers changeraient sur le serveur sans rien toucher. Publier pour de vrai exige un --go explicite de ma part, et même alors, le script commence par une sauvegarde côté serveur et ne supprime jamais rien.
• Une fois par semaine, une tâche planifiée réveille un agent pour actualiser le site — corriger les dates obsolètes, améliorer les articles faibles, vérifier les liens — avec des contrôles de garde avant toute publication (l’étape 3 en détaille le fonctionnement).
• laserlloyd.com lui-même est géré ainsi.

Cette répartition des tâches est tout l’intérêt : les agents tapent, les scripts font respecter les règles, et je prends la seule décision qui compte — celle de mettre un changement en ligne ou non.

Le matériel et l’OS : n’importe quelle machine Linux convient

J’utilise un mini-PC doté de beaucoup de mémoire unifiée parce que j’aime faire tourner de gros modèles en local (la pile complète est décrite dans mon article compagnon, Huit agents IA, une machine AMD). Mais pour la gestion de site web spécifiquement, les exigences sont modestes :

• N’importe quelle machine Linux 64 bits — un mini-PC, un vieux poste de bureau, voire un ordinateur portable capable. 16 Go de RAM font tourner correctement de petits modèles locaux ; 32 Go et plus ouvrent la porte à des modèles de taille moyenne qui écrivent une prose nettement meilleure.
• Une distribution avec systemd (presque toutes le sont) — la planification et la supervision des services décrites plus bas en dépendent.
• Python 3 pour le générateur de site statique, rsync + SSH pour les déploiements.

Un GPU n’est même pas strictement nécessaire. De petits modèles instruction-tuned tournent de façon acceptable sur CPU pour rédiger et éditer du texte. Mais je vais être honnête sur où j’en suis arrivé après des mois à faire tourner les deux : l’API cloud de DeepSeek est aujourd’hui le moteur principal de toute ma configuration OpenClaw. Les modèles locaux ouverts étaient le plan de départ, et ils tournent toujours, mais les compromis s’accumulent — des minutes de temps de chargement du modèle, du VRAM à jongler entre services, et une intelligence nettement inférieure à celle d’un modèle cloud de pointe qui coûte des fractions de centime par message. Le local est mon repli et mon niveau de confidentialité, pas mon usage quotidien. (La facture mensuelle réelle : environ 24 $.)

Étape 1 : installer une passerelle d’agents et un modèle local

Deux éléments : quelque chose qui sert un modèle via une API compatible OpenAI, et quelque chose qui transforme ce modèle en agent — avec des outils, un accès aux fichiers et des tâches planifiées.

Serveur de modèle. LM Studio, Ollama, ou le serveur de llama.cpp fonctionnent tous. Quel que soit votre choix, faites-le tourner en tant que service utilisateur systemd pour qu’il survive aux redémarrages :

# ~/.config/systemd/user/model-server.service
[Unit]
Description=Local LLM server
[Service]
ExecStart=/path/to/your/model-server --port 1234
Restart=on-failure
[Install]
WantedBy=default.target

systemctl --user enable --now model-server
curl -s http://localhost:1234/v1/models   # sanity check

Passerelle d’agents. J’utilise OpenClaw, une passerelle ouverte et auto-hébergée qui héberge des agents nommés, leur donne des outils (shell, lecture/écriture de fichiers, recherche web), route chaque agent vers un modèle (local ou cloud, avec des solutions de repli), et expose une interface de chat. Installez-la, pointez un agent « webmestre » vers votre modèle local, et accordez-lui un accès aux outils limité au répertoire du site web. Deux règles de configuration importantes quelle que soit la passerelle choisie :

• Liez la passerelle à l’interface loopback et placez toute interface de chat derrière une authentification. Un agent ayant accès au shell n’est pas quelque chose à laisser ouvert sur votre réseau.
• Limitez le répertoire de travail de l’agent au dépôt du site. Il doit modifier content/, pas votre répertoire personnel.

Deux niveaux : des agents locaux pour la routine, un modèle cloud puissant pour les réparations

Une seule machine, deux niveaux de puissance cérébrale. Les agents OpenClaw — s’appuyant sur l’API bon marché de DeepSeek, avec des modèles locaux en renfort — gèrent le travail quotidien à fort volume : rédaction, édition, vérification des liens, actualisation hebdomadaire. Mais quand le système lui-même casse (une régression de configuration, une passerelle plantée, une construction qui ne tourne plus), j’escalade vers un modèle de codage cloud puissant qui traite toute la machine comme son patient. J’ai raconté cette histoire séparément dans Quand OpenClaw casse, je répare avec Claude Code : les agents OpenClaw sont la main-d’œuvre, le modèle de codage puissant est le mécanicien.

L’équipe : tous les bots de la machine

La passerelle héberge un effectif d’agents nommés, chacun routé vers le modèle qui correspond à son travail. Ils apparaissent tous dans DisPatch, l’application de chat qu’utilise la famille — mais pas tous dans les deux modes : le verrouillage par code PIN de DisPatch divise l’effectif entre un ensemble sûr et toujours disponible, et un ensemble à pleine puissance qui n’apparaît qu’après déverrouillage.

Bot	Rôle	Tourne sur	DisPatch (verrouillé)	DisPatch (déverrouillé)
Bits	Accueil — l'agent à qui vous parlez ; comprend la demande, l'envoie au bon spécialiste	DeepSeek flash (cloud)	—	✔
Brains	Le penseur — spécifications, audits, tout ce qui mérite d'attendre	DeepSeek reasoner (cloud)	—	✔
Flash	Tâches rapides et suivis planifiés — le chien de garde qui traque le travail en retard	DeepSeek flash (cloud)	—	✔
Hermes	Le pont vers l'agent de codage — travail de programmation délégué	DeepSeek (cloud)	—	✔
Doxy	Cheval de trait local — travaux en masse et confidentiels qui ne doivent pas sortir de la maison	Modèle local 122B (vLLM)	—	✔
Charley	Vision — « qu'y a-t-il sur cette photo ? », tâches liées aux images	Gemma 31B (local, LM Studio)	✔	✔
Alpha & Beta	Assistants généraux adaptés à la famille — questions de devoirs, discussion quotidienne	DeepSeek flash (cloud)	✔	✔
Terminex	Pas un agent — le terminal de codage Reasonix de DisPatch, un vrai PTY dans le navigateur	DeepSeek (cloud)	—	✔

Leurs performances, honnêtement :

• Les bots adossés à DeepSeek sont les chevaux de bataille quotidiens. Les agents de niveau flash (Bits, Flash, Alpha, Beta) répondent en quelques secondes, coûtent des fractions de centime par message, et n’ont jamais besoin de chauffe. Brains, au niveau reasoner, prend nettement plus de temps par réponse — c’est le but, c’est à lui qu’on confie les problèmes qui méritent réflexion — et coûte quand même des centimes par session. La facture mesurée de toute la pile figure dans l’article sur les coûts.
• Les bots locaux sont plus lents et moins intelligents, mais privés et gratuits. Le modèle 122B de Doxy met plusieurs minutes à se charger en mémoire, et ses longs tours de parole peuvent en prendre plusieurs de plus ; les délais d’expiration de la passerelle ont dû être augmentés spécifiquement pour lui. Le modèle de vision de Charley est l’exception qui reste occupée — la description d’image est un service qu’aucun niveau cloud bon marché ne propose ici, donc un modèle local justifie son VRAM.
• L’ensemble sûr est délibérément ennuyeux. Alpha, Beta et Charley composent l’effectif du mode verrouillé : information générale et vision, aucun outil qui touche aux fichiers ou aux systèmes. C’est ce qui rend le fait de tendre un téléphone à un enfant totalement anodin.

Étape 2 : un site statique plus un script de déploiement verrouillé

Les agents et WordPress font mauvais ménage — une base de données, une connexion, des extensions et PHP sont autant de surfaces d’attaque et de modes de défaillance. Un générateur de site statique est le partenaire naturel d’un agent : tout le site n’est que des fichiers texte brut dans un dossier, la construction tient en une commande, et « publier » revient à copier des fichiers. Mon générateur est quelques centaines de lignes de Python (Jinja2 + Markdown + YAML) ; Hugo, Eleventy ou Zola fonctionnent de la même façon. Ce qui compte, c’est le contrat :

• Le contenu est constitué de fichiers Markdown avec frontmatter. Un LLM les modifie nativement et un git diff montre exactement ce qu’il a fait.
• La construction est déterministe. Même contenu en entrée, site identique au bit près en sortie — donc tout changement de sortie est traçable jusqu’à un changement de contenu.
• Il n’existe qu’un seul chemin de déploiement, et c’est un script avec la sécurité intégrée, pas un ensemble d’instructions que l’on fait confiance à l’agent de suivre.

Ce dernier point est le cœur de tout ce dispositif. Voici la forme du mien :

./deploy.sh preflight   # checks SSH, target webroot, size budget
./deploy.sh             # build + DRY-RUN rsync — prints what would change
./deploy.sh --go        # build + server-side backup + publish + verify

Et ce que le script garantit, par ordre d’importance :

1. Simulation par défaut. L’exécuter sans arguments ne peut jamais modifier le serveur. Un agent peut le lancer librement pour me montrer un déploiement en attente.
2. Ne supprime jamais. rsync tourne sans --delete. Un agent perdu peut écraser une page avec une version plus récente ; il ne peut pas effacer le site.
3. Sauvegarde en premier. Avec --go, le script prend une archive tar côté serveur du webroot avant qu’aucun fichier ne soit écrasé (en conservant les dernières). Si la sauvegarde échoue, le déploiement s’interrompt.
4. Échec fermé (fail-closed). Un manifeste manquant, un hôte injoignable, ou une valeur de configuration laissée en placeholder interrompt le processus avant que rsync ne tourne. Les fichiers source (templates, scripts, configurations) sont exclus en dur pour ne jamais pouvoir se retrouver dans le webroot public.
5. Vérifie après coup. Il récupère la page d’accueil en ligne et cherche un marqueur du générateur intégré à la construction — un simple HTTP 200 peut être un faux positif si un ancien hébergement répond toujours pour le domaine.

L’agent est autorisé à lancer la simulation et le preflight quand il le souhaite. Le drapeau --go m’est réservé. Cette seule asymétrie transforme « une IA a un accès quasi-SSH à mon site de production » d’un scénario terrifiant en un non-événement.

Étape 3 : mises à jour hebdomadaires planifiées, avec garde-fous

Le dernier élément rend le tout autonome. Un minuteur systemd se déclenche une fois par semaine et confie à l’agent une mission permanente : passer le site en revue, actualiser ce qui a vieilli, resserrer les articles faibles, vérifier les liens internes, et mettre en attente — pas publier — le résultat. C’est aussi cette tâche qui maintient cet article : sa mission inclut « relire l’article sur la configuration OpenClaw, corriger tout ce qui s’est éloigné de la réalité, et tamponner la date updated: ». La date en haut de cette page est ce tampon.

# ~/.config/systemd/user/site-refresh.timer
[Unit]
Description=Weekly website content refresh
[Timer]
OnCalendar=Sun 06:00
Persistent=true
[Install]
WantedBy=timers.target

Le service qu’il déclenche appelle l’API (ou la CLI) de la passerelle avec la mission, puis exécute les contrôles de garde sur ce que l’agent a mis en attente :

• Analyse de secrets. Une recherche de motifs dans le diff pour repérer tout ce qui ressemble à une clé API, un jeton, un mot de passe ou un nom d’hôte privé. Des outils comme gitleaks font cela directement. Toute détection interrompt l’exécution — échec fermé, sans exception.
• Vérification du contenu professionnel. Une seconde passe par un LLM, avec un prompt différent de celui du rédacteur, examine les changements en attente à la lumière d’une seule question : « une entreprise serait-elle à l’aise de publier ça ? » Le ton, les affirmations, les TODO non terminés, le texte de remplissage. Un échec laisse les changements en attente pour une revue humaine, au lieu de les déployer.
• La construction doit réussir, y compris le vérificateur de liens et de ressources — une image cassée ou un lien interne mort fait échouer l’exécution avant même qu’elle n’atteigne le script de déploiement.

Ce n’est que lorsque les trois passent que la tâche va jusqu’à simuler un déploiement — et sur ce site, la publication réelle attend toujours mon --go. Si un jour je fais assez confiance au pipeline pour laisser la tâche hebdomadaire publier de façon autonome, les garde-fous combinés au script de déploiement « ne supprime jamais, sauvegarde d’abord » limitent les dégâts possibles à « un mauvais article est passé en ligne et je l’ai restauré depuis la sauvegarde ».

Reproduire tout ça

Tout ce qui précède peut être construit à partir de cette description — rien n’y est propriétaire. La recette, condensée :

1. Choisissez une machine Linux et installez un serveur de modèle local (LM Studio, Ollama, llama.cpp) en tant que service systemd.
2. Installez une passerelle d’agents (OpenClaw ou équivalent) liée à l’interface loopback ; créez un agent webmestre avec des outils fichiers/shell limités au répertoire du site.
3. Migrez le site vers un générateur statique si ce n’est pas déjà fait — du contenu Markdown en entrée, une commande de construction en sortie.
4. Écrivez le script de déploiement verrouillé avec les cinq garanties ci-dessus : simulation par défaut, aucune suppression, sauvegarde en premier, échec fermé, vérification après déploiement. C’est la pièce qui mérite le plus de soin ; elle représente peut-être 150 lignes de bash.
5. Ajoutez le minuteur hebdomadaire et les deux contrôles de garde (analyse de secrets + revue de contenu par LLM), en échec fermé.
6. Gardez --go entre des mains humaines jusqu’à ce que le pipeline ait prouvé le contraire.

Conformément à la convention de ce site, l’encadré « à implémenter vous-même » en haut de l’article veut dire exactement ce qu’il dit : ce texte est délibérément assez détaillé pour que vous puissiez remettre l’article entier à votre propre LLM et lui demander de construire chaque pièce pour votre site. La liste des garanties du script de déploiement en constitue, de fait, le cahier des charges.

Pièges

• Le script de déploiement doit être l’unique chemin. La première fois que vous (ou un agent) bricolez un rsync à la main « juste cette fois », vous créez l’incident que le script existait pour éviter. Le mien exclut en dur les fichiers source et refuse les configurations en placeholder précisément parce qu’une commande ponctuelle ne le ferait pas.
• Un simple HTTP 200 n’est pas un déploiement réussi. Pendant ma migration WordPress, l’ancien hébergement continuait de répondre pour le domaine — chaque « vérification » passait pendant que les nouveaux fichiers restaient inutilisés. Intégrez un marqueur de générateur dans votre construction et cherchez-le sur la page en ligne.
• Les agents suivent le schéma que vous leur montrez, TODO compris. Si le squelette de votre article contient du texte de remplissage, un modèle paresseux publiera TODO: excerpt here tel quel. C’est la moitié de la raison d’être de la vérification du contenu professionnel.
• Ne laissez pas le rédacteur se relire lui-même. Même modèle, même prompt, mêmes angles morts. Le relecteur a besoin au minimum d’un prompt différent, idéalement d’un modèle différent.
• Les tâches LLM planifiées ont besoin de délais d’expiration et d’un réglage par défaut « en attente, pas publié ». Une tâche hebdomadaire capable de publier sans supervision finira par publier quelque chose de bizarre un dimanche à 6h du matin. La mise en attente ne coûte qu’une relecture.
• Les analyses de secrets ont leur place dans le pipeline, pas dans les instructions de l’agent. « Ne jamais inclure de secrets » dans un prompt est un vœu pieux ; une analyse en échec fermé sur le diff est un contrôle réel.