zcf : ce que le CLI installe réellement dans Claude Code et Codex

Le problème visé : trois installations avant la première ligne de code

Claude Code et Codex sont deux clients distincts. Chacun a ses fichiers de configuration, ses variables d'environnement et ses conventions de fournisseur. Brancher un relais API compatible, ajouter des workflows, déclarer des serveurs MCP : à la main, cela représente plusieurs fichiers à éditer avant d'écrire la moindre ligne de code. zcf cible précisément cette étape. Le README résume l'objectif par « Zero-config, one-click setup for Claude Code & Codex », avec prise en charge bilingue, système d'agents et assistant IA personnalisé. Le public visé est donc l'utilisateur individuel qui veut passer d'un abonnement ou d'un relais à un environnement fonctionnel sans lire la documentation des deux clients. Ce n'est pas un outil pour une équipe qui doit versionner ses configurations : le dépôt ne décrit aucun mode de ce type.

Ce que fait la commande i, d'après le README

La commande centrale est `npx zcf i`. Le README la décrit en commentaire comme « Full initialization: install + workflows + API/CCR + MCP ». Quatre opérations, donc : installation du client, mise en place de workflows, configuration d'API ou de CCR, et déclaration de serveurs MCP. Deux autres commandes sont documentées : `npx zcf u` pour « Update workflows only », et `npx zcf --lang zh-CN` pour changer la langue de l'interface. Un mode non interactif existe, illustré ainsi : `npx zcf i -s -p 302ai -k "sk-xxx"`. Les options `-s`, `-p` et `-k` correspondent visiblement à un mode silencieux, à un preset de fournisseur et à la clé d'API. Le README ne donne pas la signification développée de ces trois lettres. C'est une lacune réelle : un lecteur qui veut automatiser l'installation dans un script doit deviner, ou aller sur le site. La commande recommandée reste `npx zcf` sans argument, qui ouvre le menu interactif.

Le flux de données reste hors du dépôt

Le README ne décrit pas l'architecture interne. On sait que le projet est écrit en TypeScript, que le point d'entrée est un binaire npm lancé via `npx`, et que la commande d'initialisation touche à quatre domaines nommés séparément. On ne sait pas où les workflows sont écrits sur le disque, ni comment le preset de fournisseur est traduit en configuration client, ni si CCR est installé comme dépendance ou seulement configuré. Le dépôt renvoie explicitement vers https://zcf.ufomiao.com/ pour « More usage, options, and workflows ». Le badge JSDocs suggère une documentation d'API générée, mais son contenu n'est pas fourni ici. Toute description précise du flux interne serait donc une invention. Ce qui est observable, c'est le découpage : installer, mettre à jour les workflows, configurer le transport, déclarer les serveurs. Cette séparation en quatre étapes est cohérente avec un outil qui veut rester ré-exécutable, mais elle n'est pas prouvée par le matériel fourni.

Mises à jour et coût de maintenance

Les versions récentes s'enchaînent vite : zcf@3.7.1 le 20 juillet, zcf@3.7.2 le 4 août, zcf@3.7.3 le 31 août. Trois correctifs en six semaines sur la branche 3.7. Le dépôt n'est pas archivé et le dernier push correspond à la dernière release. La commande `npx zcf u` existe justement pour ne mettre à jour que les workflows, sans refaire l'initialisation complète. C'est le point important pour le coût de maintenance : si les workflows évoluent souvent, un utilisateur qui a personnalisé ses propres fichiers devra vérifier ce que `u` écrase. Le README ne documente pas ce comportement. Sur la licence, le projet est publié sous MIT, ce qui autorise la réutilisation et la modification avec conservation de l'avis de licence. Cela ne dit rien du statut des workflows, des prompts ou des assets distribués par l'outil, qui peuvent provenir d'ailleurs. Ce n'est pas un avis juridique : si vous redistribuez zcf ou son contenu, lisez le texte de licence dans le dépôt.

Le README comme page de sponsors

Une part importante du README est occupée par des blocs de sponsors : AICodeMirror, Z.ai et son GLM CODING PLAN, code0.ai, Claude API, PatewayAI, 302.AI, PackyCode, APIKEY.FUN. Chaque bloc contient un lien de parrainage, parfois un code promo, et des arguments commerciaux sur la fiabilité ou le prix des relais. Le README précise d'ailleurs que ZCF reçoit un parrainage via AICodeMirror et que le projet est sponsorisé par Z.ai. Ce n'est pas un défaut en soi. C'est un fait à intégrer dans la lecture : la commande non interactive documentée utilise `-p 302ai`, un fournisseur qui figure aussi parmi les sponsors. Le preset par défaut mis en avant n'est donc pas neutre. Si vous évaluez zcf pour un usage professionnel, prévoyez de vérifier séparément chaque fournisseur proposé, notamment ses conditions de facturation et de traitement des données.

Quand zcf n'est pas le bon outil

Trois cas se dessinent. Premier cas : vous travaillez derrière un proxy d'entreprise avec inspection TLS et voulez savoir exactement quels domaines sont contactés. Le README ne liste pas ces domaines, et l'outil écrit dans des fichiers de configuration d'agent. Vous devrez tracer vous-même. Deuxième cas : vous utilisez un client autre que Claude Code ou Codex. zcf ne cible que ces deux-là ; les sponsors mentionnent Cline, Roo Code ou Gemini, mais le README ne dit pas que zcf les configure. Troisième cas : vous voulez des configurations versionnées et relues en revue de code. Une commande interactive qui écrit dans votre répertoire personnel n'entre pas dans ce flux. Le mode non interactif avec `-s -p -k` s'en rapproche, mais la signification exacte des options n'est pas documentée dans le dépôt, ce qui rend l'automatisation fragile.

L'alternative : écrire la configuration soi-même

L'alternative directe n'est pas un autre outil, c'est l'absence d'outil. Claude Code et Codex se configurent par leurs propres fichiers et variables d'environnement, documentés par leurs éditeurs respectifs. La différence d'approche est nette : zcf regroupe quatre opérations dans une commande et fournit des presets de fournisseurs, tandis que la configuration manuelle vous laisse choisir chaque valeur et versionner le résultat. Le coût est le temps d'installation initiale et la lecture de deux documentations. Le bénéfice est que rien ne change dans votre dos lors d'une mise à jour. Un utilisateur qui change rarement de fournisseur et garde ses configurations dans un dépôt Git n'a probablement pas besoin de zcf. Un utilisateur qui teste plusieurs relais et réinstalle souvent y trouvera un gain concret, à condition d'accepter la dépendance au site de documentation.

Conclusion éditoriale

À adopter si vous voulez installer Claude Code ou Codex avec un preset de fournisseur en une commande non interactive, et si vous acceptez que les détails vivent sur zcf.ufomiao.com plutôt que dans le dépôt. À éviter si vous avez besoin d'une documentation hors ligne auditable, ou si vous ne voulez pas qu'un outil écrive dans vos fichiers de configuration d'agent sans les lire d'abord. Avant tout : lancez npx zcf sans argument pour voir le menu, puis npx zcf u seul, et vérifiez les fichiers modifiés dans votre HOME avant de lancer la commande d'initialisation complète.

Sources officielles

1. License: MIT
2. Project website
3. README
4. Releases
5. UfoMiao/zcf on GitHub