2026 — OpenClaw sur Mac distant : multi-endpoints compatibles OpenAI, routage et résumé CI

En 2026, la première cause d’écarts entre « ça marche en SSH » et « le service plante la nuit », c’est un Node.js qui n’est pas le même binaire selon le contexte. Fixez Node 24 comme version unique sur le Mac distant : même préfixe d’installation pour votre utilisateur de service et pour les sessions interactives, et vérifiez avec node -v dans les deux cas avant toute étape suivante.

Le rôle de la passerelle doit rester mince : terminaison TLS éventuelle, authentification en entrée, routage vers les fournisseurs, journalisation structurée. Les clés API des fournisseurs appartiennent aux variables d’environnement ou à un magasin de secrets ; elles ne doivent jamais se retrouver dans un dépôt Git ni dans un artefact CI public. Sur un Mac loué partagé entre plusieurs projets, isolez au minimum un utilisateur système ou un répertoire de configuration dédié par équipe.

Prévoyez une sortie réseau cohérente : proxy d’entreprise, liste NO_PROXY pour l’admin local, et si vous terminez TLS devant la passerelle, un certificat dont la chaîne est connue du binaire Node via NODE_EXTRA_CA_CERTS lorsque l’autorité interne n’est pas dans le magasin par défaut.

Suivez la procédure d’installation officielle OpenClaw pour votre chaîne (archive, script ou paquet npm global selon la branche documentée), puis exécutez openclaw doctor ou l’équivalent recommandé : l’objectif est d’avoir un rapport sans erreur bloquante avant d’ouvrir le port d’écoute. Sur macOS, si la passerelle doit survivre aux déconnexions SSH, encapsulez-la dans un LaunchAgent : le plist doit répéter exactement les variables sensibles que vous avez validées à la main.

Points d’attention récurrents sur Mac distant : chemins absolus dans le plist, pas de dépendance implicite à un profil shell ; umask et droits sur les fichiers de log ; répertoire de travail explicite. Après modification du service, launchctl unload puis load, et contrôlez les journaux système si le port reste fermé. Gardez une commande de secours pour arrêter proprement le processus (lsof sur le port, puis signal) afin d’éviter les doublons qui provoquent EADDRINUSE.

Chaque backend compatible OpenAI est défini par une URL de base, un schéma d’authentification (Authorization: Bearer, en-tête personnalisé ou clé query selon le fournisseur), et des timeouts par route si la configuration le permet. Le routage s’appuie en général sur le champ model de la requête : préfixes du type gpt-, claude- ou noms entièrement qualifiés selon votre convention interne.

L’intérêt du Mac distant stable ici est double : les développeurs tirent les mêmes modèles via la même passerelle que la CI, et les équipes voient les mêmes latences et mêmes politiques de repli que le runtime de production interne.

Exposez un point de contrôle HTTP qui agrège l’état de la passerelle et la disponibilité résumée de chaque backend (par exemple sous forme JSON avec des champs ok ou des codes par cible). Depuis le Mac distant, testez en boucle fermée :

Un code 200 seul ne suffit pas si le JSON annonce une cible critique en échec ; faites valider la sémantique par votre supervision (Prometheus, Nagios, ou simple script launchd qui redémarre le service après N échecs consécutifs). Cette approche réduit le temps pendant lequel la CI ou les IDE continuent à envoyer du trafic vers une passerelle partiellement cassée.

Après un build ou un déploiement de configuration, la CI peut POST un petit document JSON vers une URL interne (reverse proxy + auth mutuelle ou réseau privé) avec : identifiant de pipeline, statut, hash court du commit, liste des fichiers de config modifiés, et version OpenClaw déployée. Alternativement, écrivez un fichier gateway-summary.json dans un répertoire d’artefacts que la passerelle ou un plugin lit au démarrage.

Sur GitHub Actions, GITHUB_STEP_SUMMARY permet d’afficher en markdown les mêmes informations pour les humains ; l’important est de garder le même schéma entre le Webhook machine-machine et le résumé lisible par l’équipe. Ainsi, quand un développeur « tire » une nouvelle image modèle ou une policy de routage, le journal CI et la passerelle racontent la même histoire.

404 Not Found côté client alors que le fournisseur répond en direct. Comparez les chemins : une base URL qui se termine déjà par /v1 combinée à un proxy qui rajoute /v1 produit un doublon invisible dans les journaux applicatifs. Testez curl avec la même URL finale que celle construite par la passerelle.

401 ou invalid_api_key uniquement sous launchd. C’est presque toujours une variable d’environnement absente dans le plist. Vérifiez avec un script de debug lancé par le même domaine de service, pas avec votre shell interactif.

Tout part vers le backend par défaut. Réordonnez les règles : les motifs les plus spécifiques en tête, le joker en dernier. Vérifiez que le client envoie bien le nom de modèle attendu (casse, alias, suffixe fournisseur).