Vous savez déjà écrire une procédure et la confier à un modèle. Ce qui change ici, c'est que l'exécution ne se fait plus sur votre ordinateur : elle a lieu dans le cloud, sur les vrais comptes de votre équipe, sur déclencheur, devant vos collègues.
Alors passez la visite guidée. Presque tout ce que vous avez déjà construit trouve sa place ici — cela porte simplement un autre nom.
| Ce que vous avez maintenant | Ce que cela devient dans Okou |
|---|---|
CLAUDE.md / AGENTS.md | Les Instructions d’un agent — ses consignes permanentes |
Une compétence / SKILL.md | Un workflow détenu par cet agent |
| Un serveur MCP que vous exécutez | Un connecteur personnalisé, où votre espace de travail a MCP activé |
| Clés API et variables d’environnement dans votre shell | Connecteurs — le secret reste hors du modèle |
cron plus un script sur votre ordinateur | Une automatisation sur le workflow |
| Plus d’onglets de terminal | Plus d’exécutions simultanées, achetées par espace de travail |
| Votre abonnement Claude ou Codex | Toujours le vôtre — connectez-le dans Paramètres → Modèles |
Commencez par retirer les deux éléments qui vous feraient sinon payer deux fois l’inférence et réécrivez ce que vous avez déjà.
1. Exécutez sur l’abonnement que vous payez déjà
Okou peut faire transiter les appels modèles via votre propre compte Claude ou Codex sur les offres Free et payantes, si votre compte fournisseur le permet.
Il y a deux volets à cela, réalisés par des personnes différentes.
Un administrateur choisit la route
Dans Paramètres → Modèles, un administrateur d’espace de travail décide comment chaque modèle est servi. Deux des options sont :
- Abonnement Claude — chaque membre connecte son propre plan Pro, Max ou Team.
- Abonnement Codex — chaque membre connecte son propre plan Pro ou Team.
La politique détermine la route, pas le sélecteur de modèle — donc si un modèle n’est pas configuré ainsi, votre connexion personnelle ne le servira pas.
Vous connectez votre propre compte
Dans Paramètres → Modèles, section Personnel — utilisé uniquement dans vos exécutions, avec vos propres identifiants :
- Claude Code OAuth — connectez-vous avec l’identifiant Claude Code pour les routes modèles Claude. Okou ouvre une page d’approbation Claude ; approuvez Okou, copiez le code d’autorisation affiché et collez-le dans la boîte de dialogue.
- ChatGPT (Codex) — connectez-vous avec la connexion appareil Codex. Okou copie un code appareil et ouvre la page d’approbation ; collez le code dans OpenAI, approuvez l’accès et laissez la boîte de dialogue ouverte pendant la connexion.
Vous pouvez connecter plusieurs comptes par fournisseur et en définir un comme actif. Une fois connecté, votre menu de compte affiche ce qu’il reste de chaque fenêtre d’utilisation de l’abonnement — la fenêtre de 5 heures et celle hebdomadaire — pour anticiper une limite avant qu’une longue exécution ne la rencontre.
Trois points à connaître avant de commencer :
- Vous pouvez utiliser votre propre fournisseur sur les offres Free et payantes ; votre compte fournisseur doit prendre en charge la route choisie.
- Un plan ChatGPT gratuit ne peut pas utiliser Codex via Okou. Plus ou Pro est requis.
- Quelle que soit la route du modèle, les appels d’outils, la génération et le stockage sont toujours facturés en crédits Okou. L’abonnement couvre la réflexion, pas l’action.
Le sélecteur de modèle à côté du compositeur de chat choisit un modèle ; il ne remplace pas la route attribuée par la politique à ce modèle. Le modèle vit aussi sur le fil de discussion, pas sur l’agent ni sur le workflow — voir Modèles.
2. Portez vos compétences sous forme de workflows
Ce que vous appelez une compétence, Okou l’appelle un workflow : une procédure nommée avec une description qui précise quand elle s’applique, une instruction qui explique comment faire le travail, et des fichiers optionnels associés. Un SKILL.md que vous avez déjà écrit est, presque ligne à ligne, une instruction de workflow.
Le moyen le plus rapide de transférer une compétence est de la remettre dans le chat. Vous n’avez pas à la réécrire, ni à exécuter quoi que ce soit :
- Déposez le fichier. Glissez votre
SKILL.mddirectement dans le chat — ainsi que toute checklist, modèle ou fichier de référence associé. - Ou donnez le lien à Okou. Collez l’URL GitHub du dossier de la compétence et laissez Okou tout lire.
Puis indiquez ce que vous souhaitez en faire :
« Voici la compétence que j’utilise dans Claude Code. Créez-en un workflow sur cet agent. Gardez la procédure, mais remplacez les chemins de fichiers locaux et les étapes shell par des connecteurs, et dites-moi ce qui n’est pas encore accessible. »

Okou lit le fichier, propose le nom, la description et l’instruction, et vous montre le résultat avant de l’enregistrer.
Quatre différences à corriger lors du portage
- Un workflow appartient à un seul agent, et il ne peut accéder qu’aux connecteurs autorisés pour cet agent. Une compétence locale hérite de ce que votre shell peut atteindre ; celle-ci non. Si un workflow porté ne voit pas Gmail, vérifiez l’autorisation de l’agent, pas l’instruction.
- Le nom est un slug en minuscules —
triage-bug-report, 2 à 64 caractères. Invoquez-le explicitement avec/triage-bug-reportdans le chat de l’agent propriétaire, ou décrivez simplement le travail et laissez Okou faire correspondre la description. Une description précise permet au workflow de se déclencher automatiquement. - Les nouveaux workflows sont privés par défaut. Rendre un workflow public à l’espace de travail est une action volontaire, pas un effet secondaire de l’enregistrement. Deux agents peuvent détenir la même procédure et produire des résultats différents, car chacun a sa propre voix et ses propres autorisations.
- Les identifiants ne voyagent pas. Toute variable d’environnement ou clé dans une compétence locale devient un connecteur, pour que le secret reste sur la plateforme et hors de portée du modèle. Si aucun connecteur natif ne convient, créez un connecteur personnalisé plutôt que de coller une clé dans une instruction.
Ce qui reste inchangé : les fichiers complémentaires. Modèles, checklists, chartes graphiques et données de référence s’attachent au workflow comme ils étaient à côté de votre SKILL.md.
Votre CLAUDE.md est l’agent, pas un workflow
Les compétences deviennent des workflows. Les règles permanentes que vous gardez dans CLAUDE.md ou AGENTS.md — ton, style maison, interdits, quand s’arrêter et demander — vont sur l’agent, sous Instructions. C’est ce que chaque workflow de cet agent hérite.

Collez le fichier et demandez à Okou de l’intégrer dans les instructions de l’agent. Séparez selon la logique du produit : tout ce qui concerne notre façon de travailler va sur l’agent ; tout ce qui concerne une tâche précise devient un workflow.
3. Utilisez ensuite ce qu’un CLI local n’offre pas
Avec votre route modèle et vos procédures en place, le reste d’Okou est ce que votre ordinateur ne peut pas faire :
- Connecteurs — services autorisés que votre agent peut lire et écrire, avec l’identifiant conservé à la frontière réseau et chaque appel visible dans le journal d’exécution. Cela remplace la pile de tokens personnels dans votre profil shell.
- Connecteurs personnalisés — pour l’API interne sans connecteur natif. Un administrateur enregistre les préfixes HTTPS et l’authentification une fois. Si votre espace de travail l’active, un point de terminaison HTTP MCP Streamable peut être enregistré de la même façon, pour qu’un serveur déjà exposé à Claude Code soit accessible ici aussi.
- Exécutions simultanées — une dimension de l’espace de travail que vous pouvez augmenter, plutôt qu’un nouvel onglet terminal à ne pas oublier. Un long travail n’en bloque plus un court.
- Automatisations — un déclencheur attaché à un workflow : planification, nouvel e-mail, pull request fusionnée, événement calendrier, webhook. C’est ce qui transforme une procédure en coéquipier plutôt qu’en commande à retenir.
- Agents — une identité persistante avec ses propres instructions, ton et autorisations de connecteur, pour un comportement prévisible entre exécutions et utilisateurs.
- Intégrations — le même agent accessible depuis Slack, Telegram ou le web, au lieu d’un terminal sur une seule machine.

4. Partagez-le, au lieu de le garder dans un dotfile
La vraie différence avec une configuration locale, c’est que d’autres peuvent utiliser ce que vous avez construit — y compris ceux qui n’ouvriront jamais un terminal.
- Rendez l’agent Public et publiez le workflow que vous souhaitez voir exécuter en premier par l’équipe.
- Retirez identifiants et données ponctuelles de l’instruction et des fichiers avant publication.
- Invitez des collègues via Paramètres → Personnes → Ajouter un membre, avec Member comme rôle par défaut. Voir Inviter des collègues.
- Chaque membre connecte ses propres comptes et son propre abonnement Claude ou Codex. Aucun identifiant n’est partagé.
Les étapes 3 à 6 de Pour les nouveaux utilisateurs détaillent la création d’un agent, la publication d’un workflow et sa planification. La mécanique est la même ; seul le point de départ diffère.
Où aller ensuite
- Modèles — routage, votre propre abonnement et le coût de chaque modèle.
- Workflows — anatomie, propriété, visibilité et sélection par Okou.
- Automatisations — planifications, e-mails, GitHub, calendrier et webhooks.
- Autorisations — ce qu’un agent peut toucher et comment restreindre.
- Connecteurs personnalisés — pour l’API interne sans connecteur natif.

