Maîtriser OpenCode et Oh My OpenAgent : un guide pratique pour techniciens et développeurs
Note sur les modèles : cet article utilise exclusivement les modèles GPT d’OpenAI disponibles dans un abonnement Copilot (GPT-5-mini, GPT-5.4-mini, GPT-5.3-Codex, GPT-5.4). C’est le choix par défaut de nombreuses entreprises qui limitent leurs équipes à ces fournisseurs. Pour une approche multi-modèles optimisant le rapport qualité/coût avec un budget d’environ 30€/mois, consultez l’article complémentaire : OpenCode + Oh My OpenAgent : building a multi-model AI coding stack for €30/month.
Vous utilisez déjà Copilot dans votre navigateur, GitHub Copilot CLI ou Claude CLI. Ces outils restent des assistants à la volée : une suggestion par-ci, une commande par-là. OpenCode change le paradigme. C’est un agent de développement complet qui vit dans votre terminal : il lit, modifie, exécute, débogue et déploie du code. Il a accès à votre système de fichiers, à vos outils internes et à vos clusters Kubernetes.
Oh My OpenAgent (OMO) est un plugin d’orchestration multi-agents qui s’installe par-dessus OpenCode. Le package npm s’appelle encore oh-my-opencode pour des raisons de rétrocompatibilité, mais le produit est désormais Oh My OpenAgent. L’abréviation courante est OMO — c’est celle que nous utiliserons dans ce cours.
Ensemble, OpenCode et OMO planifient un projet, explorent une codebase inconnue, corrigent un bug, rédigent un rapport, manipulent git en profondeur et poussent le tout sur Kubernetes.
Ce cours vous donne des bases solides en moins de deux heures. Vous apprendrez à lancer des tâches simples, à orchestrer des agents spécialisés, à maîtriser les coûts d’inférence, et à appliquer OMO à vos cas réels : investigation de pod Kubernetes, debug SQL PostgreSQL/MSSQL, rapports de bugs, automatisation Python/SQL, git avancé et intégration de logiciels. Aucun prérequis en intelligence artificielle n’est nécessaire. Vous devez juste savoir utiliser un terminal, lire du code et avoir accès à une installation OMO. La documentation officielle est disponible sur ohmyopenagent.com/docs.
Durée totale estimée : 1h50.
Public visé : techniciens, développeurs, exploitants, supports de niveau 2 et 3, et toute personne qui passe son temps à déboguer, investiguer, automatiser et documenter.
Table des matières
- Introduction & Installation (10 min)
- OpenCode : les fondamentaux (20 min) + Mini-lab 1
- Oh My OpenAgent : l’orchestration multi-agents (25 min) + Mini-lab 2
- Fonctionnalités avancées d’OMO (20 min) + Mini-lab 3
- Workflows concrets du quotidien (25 min) + Mini-lab 4
- Lab final : projet complet (20 min)
- FAQ rapide et bonnes pratiques
- Conclusion
1. Introduction & Installation (10 min)
1.1 Qu’est-ce qu’OpenCode
OpenCode est un agent de développement qui vit dans votre terminal. Contrairement à un assistant chat en ligne, il a accès à votre environnement local : il peut lire des fichiers, exécuter des commandes shell, interroger des bases de données, appeler des APIs, interagir avec Kubernetes, et modifier votre code en direct. Il ne se contente pas de répondre : il agit.
Imaginez un collègue senior capable de :
- Lire tout un projet en quelques secondes.
- Exécuter
kubectlpour inspecter un pod. - Corriger un script SQL bogué.
- Écrire un rapport de bug structuré.
- Rebaser une branche git et résoudre les conflits.
- Créer une application web, la dockeriser et la déployer.
C’est ce que fait OpenCode. Son interface principale est un prompt texte dans le terminal. Vous tapez ce que vous voulez faire, et l’agent exécute. Vous gardez toujours le contrôle : chaque action sensible peut être confirmée avant exécution, selon la configuration choisie.
La documentation officielle d’OpenCode est disponible sur GitHub.
1.2 Qu’est-ce qu’Oh My OpenAgent (OMO)
Oh My OpenAgent (OMO) est une surcouche multi-agents au-dessus d’OpenCode. Plutôt que d’envoyer toutes les tâches à un seul agent généraliste, OMO route chaque tâche vers un agent spécialisé. C’est comme passer d’un artisan seul à une petite équipe de spécialistes. Le dépôt officiel est sur GitHub et la documentation sur ohmyopenagent.com/docs.
Les principaux agents sont :
- Sisyphus : l’exécuteur généraliste. C’est le “faiseur” par défaut.
- Prometheus : le planificateur. Il découpe un projet en tâches concrètes avant l’exécution. Il est read-only : il ne peut pas exécuter de code.
- Hephaestus : l’architecte et codeur. Il conçoit et implémente des solutions techniques.
- Atlas : l’agent d’exploration et de cartographie de code. C’est lui qui exécute les plans de Prometheus via
/start-work. - Oracle : l’architecte et reviewer. Il fait de la revue, de la sécurité et de la qualité.
- Metis : le consultant pré-planification. Avant que Prometheus n’écrive un plan, Metis analyse la conversation pour détecter les angles morts : questions oubliées, ambiguïtés, risques de sur-ingénierie. C’est le garde-fou du planificateur. Invoqué automatiquement par Prometheus avant chaque génération de plan.
- Momus : agent critique et sécurité, pour remettre en question les plans.
- Explore : agent de recherche locale. Il explore le code avec les outils du shell (grep, glob, ast-grep) pour cartographier la codebase, trouver des patterns et localiser des fichiers.
- Librarian : agent de recherche externe. Il cherche en ligne : documentation officielle, dépôts GitHub, Context7, web search. Il apporte des connaissances fraîches que le projet local ne contient pas.
Ces agents peuvent travailler en parallèle, se déléguer des sous-tâches, et revenir avec un résultat structuré. Le coût total est souvent inférieur à celui d’un seul agent très gros, parce que chaque agent utilise le modèle adapté à sa mission.
1.3 Comparaison avec les outils que vous connaissez déjà
| Outil | Paradigme | Accès au système | Exécution de commandes | Multi-agents | Coût maîtrisable |
|---|---|---|---|---|---|
| Copilot Web | Chat, suggestions | Non | Non | Non | Limité |
| GitHub Copilot CLI | Suggestions de commandes | Local, limité | Oui, via suggestions | Non | Oui, mais simple |
| Claude CLI | Agent conversationnel | Oui | Oui, limité | Non | Moyennement |
| OpenCode natif | Agent terminal avec outils | Oui | Oui, intégré | Non (agent unique) | Oui, selon le modèle choisi |
| OpenCode + OMO | Agent terminal avec orchestration multi-agents | Oui | Oui, intégré | Oui, via OMO | Oui, avec routing par catégorie |
Copilot Web est excellent pour poser une question ou générer un snippet. GitHub Copilot CLI aide à compléter des commandes. Claude CLI est plus proche d’un agent, mais reste principalement conversationnel. OMO vont plus loin : ils modifient vos fichiers, exécutent vos outils métier, et peuvent enchaîner des dizaines d’étapes sans intervention.
Pour un technicien ou un développeur, la différence se ressent surtout dans les tâches longues et répétitives. Ouvrir un pod, lire ses logs, comparer avec un autre pod, vérifier une configmap, relancer un job, écrire le rapport : tout cela peut tenir dans un seul prompt.
Pour les utilisateurs de Claude Code
Si vous utilisez déjà Claude Code, cette sous-section est pour vous. Sinon, vous pouvez la sauter.
Claude Code et Oh My OpenAgent partagent le même ADN : ce sont des agents qui vivent dans le terminal, accèdent à votre système de fichiers, exécutent des commandes shell et modifient du code à votre place. Claude Code est aujourd’hui une référence chez les développeurs, et à juste titre : le modèle Claude offre un raisonnement long particulièrement solide, l’interface est immédiate, et l’intégration avec l’écosystème Anthropic (y compris l’extension VS Code) est très soignée.
Claude Code dispose d’un système de skills natif basé sur des fichiers SKILL.md, d’une capacité de sous-agents, et d’un support des MCP servers. L’écosystème tiers est également très actif : Superpowers et GStack proposent des skill packs qui étendent Claude Code vers une approche multi-agents.
Le tableau ci-dessous ne cherche pas à dire « l’un est meilleur que l’autre », mais à identifier les différences de conception qui comptent quand on hésite entre les deux.
| Critère | Claude Code | OMO |
|---|---|---|
| Philosophie | Agent central puissant, avec sous-agents et MCP en option | Orchestration multi-agents explicite par défaut (Sisyphus, Prometheus, Oracle, Atlas…) |
| Routing | Modèle principal + sous-agents et commandes (/plan, /review, /agents) | Catégories de tâches prédéfinies (Quick, Plan, Code, Review, Explore, Critical) avec routing automatique |
| Modèles | Modèles Anthropic (Sonnet, Opus, Fable…), choix possible via /model ou –model | Multi-fournisseurs : modèles OpenAI, Anthropic, Google, open source, etc. Sélection par catégorie pour optimiser le coût |
| Extensibilité | MCP servers, slash commands / skills (~/.claude/skills/), hooks, plugins, CLAUDE.md projet | Skills, plugins, MCP servers, slash commands (/start-work, /init-deep), AGENTS.md projet |
| Coût | Lié au modèle Anthropic choisi ; optimisable via modèle plus léger, /compact, et externalisation MCP | Maîtrisable par routing vers des modèles petits pour les tâches simples et modèles grands seulement là où c’est nécessaire |
| Courbe d’apprentissage | Faible : on lance claude et on commence | Un peu plus longue : il faut comprendre les agents, les catégories et la config, mais cela paie sur les workflows complexes |
Claude Code brille quand :
- Vous voulez un outil simple, immédiatement opérationnel, avec un raisonnement long natif excellent.
- Vous êtes déjà dans l’écosystème Anthropic ou vous utilisez l’extension VS Code.
- Votre besoin est conversationnel ou centré sur un seul agent de confiance.
OMO brille quand :
- Vous voulez une équipe d’agents spécialisés qui se passent le relais automatiquement (planification → exécution → revue).
- Vous souhaitez choisir le modèle le plus économique pour chaque sous-tâche, y compris des modèles open source ou spécialisés.
- Vous avez des workflows répétitifs et structurés (investigation Kubernetes, rapports de bugs, manipulation git complexe, etc.).
Ce qui change concrètement au quotidien :
Dans Claude Code, vous demandez à Claude de faire le travail ; si besoin, vous activez des MCP servers ou vous invoquez des commandes comme /plan ou /review. Dans OMO, le système décide souvent lui-même quel agent est le plus adapté, et il peut enchaîner plusieurs agents sans que vous ayez à les appeler un par un. Ce n’est pas magique : c’est une convention de routing qui devient utile dès que les tâches dépassent une simple question-réponse.
Verdict pratique : gardez Claude Code si vous cherchez un agent unique, puissant et bien intégré. Testez OMO si vous voulez composer avec plusieurs agents et maîtriser finement le rapport qualité/coût sur des tâches longues. Les deux outils sont légitimes ; le meilleur est celui qui correspond à votre façon de travailler.
1.4 Installation générique
L’installation officielle d’OpenCode se fait en deux commandes :
curl -fsSL https://opencode.ai/install | bash opencode auth login
Une fois OpenCode installé, activez le plugin Oh My OpenAgent dans votre fichier de configuration :
{
"plugins": [
"oh-my-openagent"
],
"defaultModel": "gpt-5-mini",
"agentRouting": true
}
Vérifiez l’installation :
opencode --version opencode agent list
1.5 Sécurité : bonnes pratiques
OMO exécute des commandes réelles sur votre système et peut modifier vos fichiers. Avant de lancer un agent dans un projet sensible, configurez les permissions dans ~/.config/opencode/opencode.json. La clé officielle est permission. Chaque outil peut être réglé sur ask (demander confirmation), allow (autoriser) ou deny (interdire).
{
"$schema": "https://opencode.ai/config.json",
"permission": {
"*": "ask", // comportement par défaut
"bash": "ask", // chaque commande shell doit être validée
"edit": "ask", // toute modification de fichier
"write": "ask", // création ou écrasement de fichier
"lsp": "ask" // requêtes LSP, y compris le renommage de symboles
}
}
Pourquoi lsp en ask ? Le renommage de symbole via LSP (lsp_rename) est une opération globale : il modifie toutes les occurrences d’une variable, fonction ou classe dans tout le projet. Une mauvaise interprétation du langage server peut entraîner des centaines de modifications involontaires. Il est prudent de demander confirmation.
Un préprompt global se configure avec la clé instructions. C’est un tableau de chemins vers des fichiers Markdown qui sont injectés dans le system prompt de chaque session. Vous pouvez y mettre un fichier de sécurité (security.md), mais aussi un fichier de conventions générales (global.md) commun à tous vos projets — sans avoir besoin d’un AGENTS.md par projet. C’est l’équivalent d’un CLAUDE.md pour Claude Code.
{
"instructions": [
"~/.config/opencode/instructions/security.md",
"./AGENTS.md"
]
}
Exemple de contenu pour ~/.config/opencode/instructions/security.md :
Règles de sécurité : - Ne jamais exécuter de commande de destruction sans confirmation explicite. - Ne jamais afficher de secret, mot de passe ou token dans la sortie. - Ne jamais pousser de code sur production sans revue par Oracle. - Toujours vérifier git status avant et après une modification.
Pour les environnements sensibles, exécutez OMO dans un conteneur isolé. Seashell (gitlab.com/pivert/seashell) est un environnement de développement DevOps portable et jetable, livré sous forme d’image Docker (~800 Mo). Il préconfigure des centaines d’outils (Python, Kubernetes, Ansible, Neovim…) dans un terminal unifié au thème Solarized Dark. Son intérêt sécuritaire : isolation Docker, sessions éphémères, aucune trace sur l’hôte. Images : docker.io/pivert/seashell, sources : gitlab.com/pivert/seashell.
1.6 Premier lancement
Lancez OMO dans un dossier de test :
mkdir ~/omo-test && cd ~/omo-test opencode
Vous arrivez sur un prompt interactif. Essayez une commande simple :
Crée un fichier README.md avec un titre "Projet test OMO" et une liste de trois fonctionnalités.
L’agent va créer le fichier, et vous pourrez le lire avec read README.md.
Astuce : Gardez vos premiers prompts courts et mesurables. Cela vous aide à comprendre ce que l’agent fait vraiment avant de lui confier des tâches plus larges.
Attention : Ne lancez jamais OMO dans un dossier contenant des secrets en clair (fichiers
.envnon versionnés, clés API, mots de passe). L’agent peut les lire et potentiellement les inclure dans des logs ou des réponses.
1.7 Ce que vous devez retenir avant de passer à la suite
OpenCode est un agent terminal. Oh My OpenAgent est un orchestrateur multi-agents. L’installation se fait via le script officiel et le plugin OMO. Le premier réflexe à acquérir est celui du coût : commencez toujours par le modèle le plus petit qui peut faire le job. Dans la grande majorité des cas, c’est la catégorie quick.
2. OpenCode : les fondamentaux (20 min) + Mini-lab 1
2.1 Outils de base
OpenCode dispose d’une boîte à outils riche. Voici les outils que vous utiliserez le plus souvent.
Lecture et édition de fichiers
read <fichier>: affiche le contenu d’un fichier.write <fichier> <contenu>: crée ou écrase un fichier.edit <fichier> <ancien> <nouveau>: remplace une portion de texte.glob <pattern>: trouve des fichiers par pattern (**/*.py,src/**/*.ts).grep <pattern>: cherche du texte dans les fichiers.
Exécution et diagnostic
bash <commande>: exécute une commande shell.lsp_diagnostics <chemin>: vérifie les erreurs de langage dans un fichier ou dossier.lsp_goto_definition,lsp_find_references: navigation dans le code.
Ces outils sont souvent appelés automatiquement par l’agent quand il en a besoin. Vous pouvez aussi les invoquer explicitement dans vos prompts pour gagner du temps ou forcer une action précise.
2.2 Raccourcis clavier essentiels
OpenCode propose plusieurs raccourcis via la séquence Ctrl+X :
Ctrl+XpuisM: changer de modèle.Ctrl+XpuisE: passer en éditeur Vim.Ctrl+XpuisB: afficher ou masquer le bandeau latéral.Ctrl+XpuisQ: quitter.Ctrl+Xpuis?: afficher la liste de tous les raccourcis.
Ces raccourcis accélèrent le travail sans quitter le prompt.
2.3 Choisir son modèle : la catégorie quick suffit souvent
Le choix du modèle est le premier levier de maîtrise des coûts. Les modèles les plus récents sont plus intelligents, mais aussi beaucoup plus chers. Pour la plupart des tâches de lecture, de grep, de refactor simple ou de debug, un modèle petit et rapide fait parfaitement l’affaire.
| Modèle | Usage recommandé | Prix relatif | Rapide ? | Précis sur du code ? |
|---|---|---|---|---|
| GPT-5-mini | Tâches simples, refactor, grep, explications, scripts courts | Bas | Oui | Suffisant |
| GPT-5.4-mini | Tâches un peu plus complexes, debug ciblé, explications structurées | Modéré | Oui | Bon |
| GPT-5.3-Codex | Génération de code, architecture moyenne, tâches techniques variées | Élevé | Moyen | Très bon |
| GPT-5.4 | Complexité élevée, raisonnement long, gros projets, revue de sécurité | Très élevé | Moyen | Excellent |
| GPT-5.5 | À éviter sauf cas très spécifiques et justifiés | Excessif | Variable | Excellent mais prohibitif |
Coût : Pour 80 % des tâches quotidiennes, la catégorie quick est le bon choix. Réservez GPT-5.4 aux revues de sécurité, aux architectures complexes, ou aux labos finaux. GPT-5.5 est presque toujours une erreur économique dans un contexte professionnel.
Comment changer de modèle dans un prompt :
/model gpt-5-mini Analyse ce script Python et dis-moi pourquoi il plante.
Ou directement :
@model:gpt-5-mini corrige ce fichier main.py
2.4 Exemple concret : débugguer un script SQL dans PostgreSQL ou MSSQL
Prenons un cas fréquent : un script SQL censé lister les commandes en retard, mais qui renvoie 0 résultat.
SELECT c.id, c.date_commande, c.statut FROM commandes c JOIN clients cl ON c.client_id = cl.id WHERE c.statut = 'EN_ATTENTE' AND c.date_commande < NOW() - INTERVAL '7 days' AND cl.region = 'NORD';
Vous suspectez un problème de fuseau horaire, de type de donnée, ou de jointure. Vous pouvez demander à OMO :
Le script commandes_retard.sql renvoie 0 résultat alors qu'on sait qu'il y a des commandes en retard. Analyse le fichier, vérifie le schéma des tables commandes et clients dans la base PostgreSQL de recette, et propose une correction.
L’agent va :
- Lire le fichier SQL.
- Inspecter le schéma (
\d commandes,\d clientsouINFORMATION_SCHEMA). - Identifier une incohérence (par exemple
cl.regionest en majuscules dans la table, oudate_commandeest untimestamp without time zone). - Proposer une version corrigée.
- Éventuellement exécuter la requête corrigée si vous lui donnez l’autorisation.
Pour MSSQL, les commandes équivalentes utilisent sqlcmd ou SELECT * FROM INFORMATION_SCHEMA.COLUMNS. La logique reste la même : lire, comparer le schéma, corriger, tester.
Astuce : Quand vous demandez une analyse SQL, précisez toujours le SGBD (PostgreSQL, MSSQL, Oracle, MySQL). Cela évite au modèle de proposer une syntaxe incompatible et fait gagner du temps.
2.5 Anti-patterns à éviter avec les modèles
- Toujours utiliser le plus gros modèle “au cas où” : c’est le meilleur moyen de multiplier par dix votre facture sans améliorer le résultat.
- Ne pas préciser la stack technique : un modèle petit se débrouille très bien si vous précisez PostgreSQL, MSSQL, Flask, Spring Boot, etc.
- Demander du code sans demander de tests : OMO peut générer des tests, mais il faut le lui demander explicitement.
- Oublier le contexte : un modèle n’a pas la mémoire de votre entreprise. Utilisez
@librarianou/init-deeppour l’enrichir.
2.6 Récapitulatif des bons réflexes fondamentaux
| Situation | Modèle | Agent | Raison |
|---|---|---|---|
| Lire un fichier et expliquer | Catégorie quick | Sisyphus | Pas besoin de plus |
| Corriger un script simple | Catégorie quick | Sisyphus | Rapide et économique |
| Optimiser une requête SQL | Catégorie quick | Sisyphus | Suffisant avec le schéma |
| Planifier une feature | GPT-5.4-mini | Prometheus | Besoin de structuration |
| Revue de sécurité | GPT-5.4-mini | Oracle | Précision nécessaire |
| Architecture complexe | GPT-5.4 | Hephaestus | Raisonnement long |
2.7 Mini-lab 1 : Analyser et corriger un petit script Python buggy
Objectif : Utiliser OMO pour diagnostiquer et corriger un script Python simple.
Durée : 10 minutes.
Prérequis : OpenCode installé, Python 3.10+ disponible.
Étapes :
- Créez un dossier
lab1-python-debug. - Créez un fichier
process_orders.py:
import csv
def load_orders(path):
with open(path, 'r') as f:
reader = csv.DictReader(f)
return [row for row in reader]
def total_by_status(orders):
totals = {}
for order in orders:
status = order['status']
amount = order['amount']
totals[status] = totals.get(status, 0) + amount
return totals
if __name__ == '__main__':
orders = load_orders('orders.csv')
print(total_by_status(orders))
- Créez un fichier
orders.csv:
id,status,amount 1,PENDING,120.50 2,PAID,85.00 3,PENDING,45.00
- Lancez OMO et demandez :
Le script process_orders.py plante avec une TypeError. Analyse-le, explique l'erreur, corrige-le, puis exécute-le pour vérifier.
Sortie attendue : Le script corrigé doit additionner les montants comme des flottants et afficher {'PENDING': 165.5, 'PAID': 85.0}.
Variante avancée : Demandez ensuite à l’agent d’ajouter des tests unitaires avec pytest.
Ajoute des tests unitaires pour process_orders.py avec pytest. Les tests doivent couvrir le cas nominal et le cas où le fichier CSV est vide.
Critères de réussite :
- L’agent identifie que
order['amount']est une chaîne de caractères. - Il applique
float()avant l’addition. - Le script s’exécute sans erreur et affiche les totaux corrects.
- Le modèle utilisé reste dans la catégorie quick.
- (Optionnel) Des tests pytest sont ajoutés et passent.
3. Oh My OpenAgent : l’orchestration multi-agents (25 min) + Mini-lab 2
3.1 Présentation de l’équipe d’agents
OMO ne fait pas tout avec un seul cerveau. Il délègue. C’est un peu comme une équipe de consultants : chacun a une spécialité, et le routing automatique choisit le bon profil pour la bonne tâche.
Sisyphus
C’est l’agent par défaut, celui qui exécute. Son nom vient du mythe : il pousse le rocher, avance pas à pas, ne se plaint pas. Sisyphus est parfait pour les tâches concrètes : “corrige ce bug”, “ajoute une fonction”, “exécute ce script”, “fais ce rebase”.
Sisyphus utilise souvent des modèles à petit contexte mais de haut niveau comme GPT-5.4, Kimi K2.7-Code ou GLM-5.2 quand on force un modèle au lieu de laisser les catégories. Le routing par catégorie choisit automatiquement le meilleur rapport qualité/coût.
Quand vous ne savez pas quel agent choisir, commencez par Sisyphus. Il est polyvalent, efficace et économique.
Prometheus
Prometheus planifie. Quand vous avez un projet un peu gros, il le découpe en tâches ordonnées. C’est l’agent à invoquer avec @plan ou quand vous voulez une roadmap avant de coder. Prometheus est read-only : il ne peut pas exécuter de code.
Prometheus est particulièrement utile quand plusieurs fichiers, plusieurs technologies ou plusieurs étapes sont en jeu. Il évite de partir tête baissée et de se perdre en cours de route.
Hephaestus
L’architecte. Il conçoit des solutions techniques, choisit les patterns, structure le code. Appelez-le pour des décisions d’architecture ou des implémentations complexes qui demandent un raisonnement structuré.
Atlas
Atlas explore et cartographie. Il est utile pour comprendre une codebase inconnue : “quels sont les modules principaux ?”, “où est défini tel service ?”, “quelle est la dépendance entre ces deux packages ?”. Atlas est un excellent compagnon de premier jour sur un projet.
Oracle
Oracle est l’architecte et reviewer. Il fait de la revue, de la sécurité et de la qualité. Il dit ce qui est bien, ce qui est mal, ce qui est risqué. Utilisez-le systématiquement avant de livrer du code critique. C’est l’agent qui vous évite de pousser un secret en production.
Metis
Metis est le consultant pré-planification. Avant que Prometheus n’écrive un plan, Metis analyse la conversation pour détecter les angles morts : questions oubliées, ambiguïtés, risques de sur-ingénierie. C’est le garde-fou du planificateur. Invoqué automatiquement par Prometheus avant chaque génération de plan.
Exemple concret : vous demandez “ajoute un système d’authentification”. Sans Metis, Prometheus pourrait sur-ingénierie dès le premier plan : trois providers OAuth, gestion des rôles, permissions fines, audit logs. Avec Metis, il pose d’abord les bonnes questions : “quel provider ?”, “besoin de MFA ?”, “rôles simples ou complexes ?”, “exposition publique ou interne ?”. Le plan final est plus juste, plus rapide à exécuter, et moins cher.
Momus
Momus est le critique. Il remet en question les plans, détecte les biais, souligne les risques. C’est un excellent garde-fou avant un déploiement ou une décision d’architecture. Si tout le monde dit oui, Momus dit “attendez, et si…”.
Explore et Librarian
Ce sont des agents de recherche. Explore part à la découverte de code avec les outils du shell (grep, glob, ast-grep). Librarian recherche en ligne (documentation officielle, GitHub, Context7, web search). Ils peuvent tourner en arrière-plan pendant que vous faites autre chose.
3.2 Comment invoquer un agent
La syntaxe la plus simple est la mention @agent au début ou dans le prompt :
@prometheus planifie la création d'un endpoint REST pour lister les pods Kubernetes
@oracle relis ce Dockerfile et dis-moi si tu vois des failles de sécurité
Vous pouvez aussi utiliser des slash commands :
@plan "ajouter une authentification par token à l'API Flask"
3.3 Pourquoi appeler d’autres agents alors que Sisyphus pourrait le faire
La tentation est forte de tout donner à Sisyphus. Il est généraliste, rapide, efficace. Mais deux problèmes apparaissent rapidement.
Premier problème : le coût. Sisyphus avec un gros modèle sur une grosse tâche coûte cher. En décomposant la tâche, on peut utiliser des modèles petits pour les sous-tâches simples et des modèles grands seulement là où c’est nécessaire.
Deuxième problème : la qualité. Un seul agent généraliste peut oublier des étapes, faire des raccourcis, ou ne pas voir un risque de sécurité. Un agent planificateur, un architecte et un reviewer travaillant en chaîne donnent un résultat plus fiable.
Exemple de décomposition :
@plan "Créer un endpoint REST qui expose les statuts des pods Kubernetes d'un namespace donné"
Prometheus va créer un plan : choisir le framework, structurer les routes, appeler l’API Kubernetes, gérer les erreurs. Puis Atlas ou Sisyphus exécute chaque étape. Enfin Oracle relit.
Le coût total est souvent inférieur à celui d’un seul agent GPT-5.4 qui ferait tout en une fois, parce que chaque sous-tâche peut être traitée avec le modèle minimum nécessaire.
3.4 Exemple de décomposition complète
Prenons un cas réel : “corriger une erreur 500 sur l’endpoint /api/orders”. Voici comment OMO peut décomposer la tâche :
- Explore : trouve les fichiers liés à
/api/orders. - Atlas : cartographie les dépendances entre le contrôleur, le service et la base.
- Sisyphus (catégorie quick) : lit les fichiers et les logs récents.
- Hephaestus (GPT-5.4-mini) : propose une correction architecturale si le bug est structurel.
- Sisyphus (catégorie quick) : applique la correction.
- Oracle (GPT-5.4-mini) : relit le patch.
- Sisyphus : exécute les tests.
Chaque agent utilise le modèle adapté. Le coût global reste maîtrisé parce que seules les étapes critiques utilisent un modèle moyen.
3.5 Les catégories de tâches et le routing automatique
OMO classe les tâches en catégories. Voici les principales :
| Catégorie | Agent typique | Exemple |
|---|---|---|
| Quick | Sisyphus | Question rapide, commande shell, mini-correction |
| Plan | Prometheus + Metis | Découper un projet ou une feature |
| Code | Hephaestus / Sisyphus | Implémenter, refactorer |
| Review | Oracle | Sécurité, qualité, bug hunt |
| Explore | Explore / Atlas | Cartographier, chercher |
| Memory | Librarian | Documentation, conventions |
| Critical | Momus + Oracle | Décision à haut risque |
Le routing automatique examine votre prompt et choisit la catégorie. Vous pouvez aussi forcer un agent avec @agent.
3.6 Le mode ulw (ultrawork)
ulw est un mode d’auto-motivation. Quand une tâche est longue ou répétitive, l’agent peut entrer dans une boucle de travail concentré, où il continue d’avancer sans relâche jusqu’à atteindre l’objectif ou jusqu’à épuisement d’une limite de sécurité.
Utilisez ulw quand :
- Vous avez une tâche répétitive sur beaucoup de fichiers.
- Vous voulez qu’un agent continue de travailler en arrière-plan.
- Vous êtes prêt à laisser l’agent itérer plusieurs minutes.
/ulw refactore tous les scripts Python de ce dossier pour remplacer os.path par pathlib
Attention :
ulwpeut consommer beaucoup de tokens si la tâche est mal cadrée. Précisez toujours un critère d’arrêt clair et un plafond de modèle.
3.7 Quand utiliser chaque agent : un guide rapide
| Votre besoin | Agent à privilégier | Pourquoi |
|---|---|---|
| “Corrige ce bug” | Sisyphus | Direct, exécuteur |
| “Comment structurer ce projet ?” | Prometheus | Planification |
| “Est-ce que ce code est sûr ?” | Oracle | Revue de sécurité |
| “Je ne comprends pas cette codebase” | Atlas / Explore | Exploration |
| “Ce plan est-il complet ?” | Metis | Détection d’angles morts avant planification |
| “Déploie ça sans risque” | Momus + Oracle | Garde-fous |
| “Code-moi cette architecture” | Hephaestus | Conception technique |
3.8 /start-work corrigé : Prometheus planifie, Atlas exécute
Le flux correct est le suivant :
- Vous écrivez
@plan "tâche"ou un prompt complexe. - Prometheus interviewe, clarifie, et crée un plan structuré.
- Vous exécutez
/start-work. - Atlas lit le plan et exécute les étapes.
Prometheus est read-only : il ne peut pas exécuter de code. Atlas est l’exécuteur. Confondre les deux rôles mène à des plans qui ne sont jamais appliqués.
@plan "Créer un endpoint REST qui expose les statuts des pods Kubernetes d'un namespace donné" /start-work
3.9 Pourquoi /init-deep est un investissement, pas une perte de temps
/init-deep scanne le projet en profondeur. Il lit les fichiers clés (package.json, pyproject.toml, Dockerfile…), identifie la stack technique, les conventions de nommage, les règles de linting, les dépendances, mais aussi les skills et MCP pertinents. Il génère un fichier AGENTS.md qui sert de briefing commun à tous les agents : Sisyphus sait dans quel langage coder, Prometheus connaît l’architecture avant de planifier, Oracle applique les règles de sécurité du projet, Explore ne part pas chercher dans les mauvais dossiers. Sans ce contexte partagé, chaque agent repart de zéro à chaque prompt.
Concrètement, /init-deep va lire :
- Les fichiers de configuration (
package.json,pyproject.toml,requirements.txt,Dockerfile). - Les règles de style et de linting.
- La structure des dossiers.
- Les tests existants.
- Les conventions de nommage.
Le fichier AGENTS.md produit sert de mémoire partagée. Quand Sisyphus, Hephaestus ou Oracle reprennent le travail, ils n’ont pas besoin de redécouvrir le projet.
Certains utilisateurs trouvent que /init-deep prend du temps au début. C’est vrai. Mais ce temps est rentabilisé dès la deuxième ou troisième question, parce que l’agent connaît déjà la structure du projet, les outils utilisés, les conventions de nommage et les dépendances.
Sans /init-deep, vous risquez de devoir répéter à chaque prompt : “c’est du Python”, “on utilise Flask”, “la base c’est PostgreSQL”, “les tests sont avec pytest”. Avec /init-deep, tout cela devient implicite.
/init-deep
Astuce : Lancez
/init-deepdès que vous arrivez sur un projet que vous ne connaissez pas. C’est le meilleur moyen de ne pas perdre du temps en spécifications et d’éviter les mauvaises suppositions.
3.10 Mini-lab 2 : Lancer /init-deep puis utiliser ulw pour automatiser une tâche simple
Objectif : Initialiser un projet et automatiser une tâche répétitive avec ulw.
Durée : 15 minutes.
Prérequis : Un projet existant avec au moins 5 fichiers Python, ou le lab 1 qui peut être réutilisé.
Étapes :
- Allez dans le dossier du projet.
- Lancez
/init-deepet attendez le résumé. - Demandez :
/ulw ajoute une docstring à chaque fonction de chaque fichier Python de ce dossier. Utilise la catégorie quick. Arrête-toi quand toutes les fonctions ont une docstring.
- Vérifiez le résultat avec :
opencode lsp_diagnostics .
Sortie attendue : Toutes les fonctions Python ont une docstring concise. Aucune erreur de syntaxe n’est introduite.
Critères de réussite :
/init-deepproduit un résumé correct de la stack.ulwtermine sans intervention manuelle.- Les docstrings sont présentes et pertinentes.
- Le coût reste faible grâce à la catégorie quick.
4. Fonctionnalités avancées d’OMO (20 min) + Mini-lab 3
4.1 Sous-agents et agents background en parallèle
OMO peut lancer des agents en arrière-plan. Cela permet de faire plusieurs choses en même temps : par exemple, demander à Explore de cartographier un projet pendant que Sisyphus corrige un fichier.
Pour lancer un agent en arrière-plan, utilisez run_in_background=true ou la syntaxe @explore background .... Vous pourrez récupérer le résultat plus tard avec un identifiant de tâche.
C’est particulièrement puissant pour les investigations longues. Vous pouvez lancer une recherche, continuer à travailler sur autre chose, et revenir consulter le résultat quand il est prêt.
4.2 Différences entre sous-agents, agents et skills
| Élément | Description | Exemple |
|---|---|---|
| Agent | Entité autonome avec un rôle | Sisyphus, Prometheus, Oracle |
| Sous-agent | Agent appelé par un autre agent pour une sous-tâche | Sisyphus appelle Explore pour chercher un fichier |
| Skill | Module de connaissances ou de capacités | skill git-master |
Les skills sont des extensions qui donnent des super-pouvoirs à un agent. Ils peuvent être globaux (disponibles partout) ou liés au répertoire courant.
4.3 Les skills : créer/utiliser un skill, exemple de skill proxy
Un skill est un fichier de configuration et éventuellement du code qui encapsule une capacité. Par exemple, le skill git-master fournit des commandes avancées de git.
Pour utiliser un skill existant :
/load git-master Rebase ma branche feature/login sur main et résous les conflits.
Pour créer un skill, vous écrivez un fichier dans .opencode/skills/ ou ~/.config/opencode/skills/. Voici un exemple minimal : un skill “proxy” qui permet de se connecter à des ressources internes sans exposer les mots de passe dans le prompt.
name: proxy
version: 1.0.0
description: Proxy sécurisé pour IBM MQ, Vault, Kafka, psql, sqlcmd
commands:
connect_mq:
description: Ouvre une connexion MQ en masquant le mot de passe
exec: python3 /opt/tools/mq_proxy.py --env {env}
connect_vault:
description: Lit un secret Vault via un wrapper
exec: vault read -field=value {path}
L’idée est simple : le mot de passe n’est jamais dans le prompt ou dans l’historique de chat. Il est lu depuis un gestionnaire de secrets ou une variable d’environnement côté outil.
Astuce : Tous les skills contenant des credentials doivent utiliser des variables d’environnement ou un vault. Ne jamais écrire de secret dans un fichier de skill versionné.
4.4 Les scopes
Les skills et les configurations peuvent être :
- Globaux : dans
~/.config/opencode/. Ils s’appliquent à tous vos projets. - Liés au répertoire courant : dans
.opencode/à la racine du projet. Ils s’appliquent uniquement à ce projet.
L’ordre de priorité est : configuration locale > configuration globale.
Cela permet de partager des conventions d’équipe via le dépôt git du projet, tout en gardant vos préférences personnelles dans votre home.
4.5 Les plugins
Les plugins sont des extensions qui ajoutent des outils à OMO. Ils peuvent intégrer des services externes, des bases de données, ou des systèmes internes.
Exemples de plugins utiles :
- Plugin Kubernetes pour
kubectl. - Plugin SQL pour exécuter des requêtes.
- Plugin git pour des opérations avancées.
- Plugin LDAP ou Active Directory pour des recherches d’utilisateurs.
- Plugin JIRA pour créer des tickets automatiquement depuis un bug report.
Un plugin se charge généralement automatiquement quand OMO détecte la configuration correspondante dans votre projet. Vous pouvez aussi le charger explicitement avec /load plugin:<nom>.
4.6 Les MCP
Les MCP (Model Context Protocol) sont des connecteurs normalisés pour enrichir le contexte de l’agent. Ils permettent à OMO d’accéder à des données ou des outils externes sans code spécifique. La liste officielle est sur opencode.ai/docs/mcp-servers/ et github.com/modelcontextprotocol/servers.
Exemples concrets de MCP :
- MCPs inclus dans OpenCode : Context7 (documentation officielle de librairies), Grep.app (recherche de code dans des dépôts GitHub publics).
- MCPs de recherche : SearXNG (web search privé).
- MCPs avancés : Android Emulator (émulation mobile), WordPress (gestion de contenu), Jira/Confluence (Atlassian).
Exemple d’utilisation de SearXNG :
@searxng recherche la dernière version stable de FastAPI et les changements majeurs depuis la 0.100
Exemple d’utilisation de Context7 :
@context7 /django/docs comment configurer un middleware personnalisé
Playwright n’est pas un skill : c’est un MCP. Dans OMO, il est accessible via la slash command /playwright ou comme MCP server. Le serveur s’exécute dans un conteneur Docker qui pilote un navigateur.
Ces outils donnent à l’agent des informations fraîches sans que vous ayez à les copier-coller. Ils sont particulièrement utiles pour des technologies qui évoluent vite.
4.7 Exemple complet : investigation d’une dépendance avec Context7 + SearXNG
Imaginez que vous devez intégrer une librairie Python que vous ne connaissez pas, par exemple httpx pour remplacer requests. Vous pouvez combiner plusieurs sources :
@context7 /encode/httpx montre-moi comment faire une requête GET avec timeout et gestion d'erreur
Puis, pour vérifier les bonnes pratiques actuelles :
@searxng httpx vs requests python best practices 2026
Enfin, demandez à Sisyphus d’appliquer :
@sisyphus remplace requests par httpx dans api_client.py. Gère le timeout et les exceptions.
Ce workflow montre comment OMO combine connaissance statique (Context7), connaissance fraîche (SearXNG) et exécution (Sisyphus).
4.8 Heads-up/tips : @librarian, @explore, @oracle, @plan
Voici quelques mentions rapides très utiles :
@librarian: retrouve de la documentation, des conventions, ou des exemples de code dans votre base de connaissances.@explore: explore un projet ou une codebase pour vous.@oracle: demande un avis critique sur une solution.@plan: demande un plan structuré avant toute exécution.
Ces mentions peuvent être combinées :
@plan @explore comment intégrer ce nouveau microservice avec l'API existante
4.9 Mini-lab 3 : Utiliser @librarian + @explore pour une investigation, puis déléguer
Objectif : Combiner la recherche documentaire et l’exploration de code pour résoudre un problème sans intervention manuelle.
Durée : 15 minutes.
Prérequis : Un projet avec une structure un minimum réaliste, ou le lab 2 réutilisé.
Étapes :
- Dans le dossier projet, demandez :
@explore liste-moi tous les fichiers Python qui interagissent avec une base de données ou une API externe
- Pendant qu’Explore travaille, demandez en parallèle :
@librarian quelles sont les conventions de l'équipe pour nommer les variables de connexion à la base de données
- Quand les deux résultats sont revenus, demandez à Sisyphus :
@sisyphus d'après les résultats de @explore et @librarian, refactorise le fichier data_access.py pour utiliser les conventions de nommage de l'équipe. Utilise la catégorie quick.
Sortie attendue : Le fichier est refactorisé avec les bonnes conventions. Les autres fichiers ne sont pas touchés.
Critères de réussite :
- Explore identifie correctement les fichiers concernés.
- Librarian retrouve les conventions applicables.
- Sisyphus applique les changements sans casser le code.
- Le refactoring est minimal et ciblé.
5. Workflows concrets du quotidien (25 min) + Mini-lab 4
Cette section est la plus proche de votre métier. Nous allons passer en revue cinq workflows très concrets, avec pour chacun un exemple de prompt et les commandes attendues.
5.1 Investigation d’un pod Kubernetes en erreur
Scénario : un pod redémarre en boucle dans le namespace production. Vous voulez comprendre pourquoi sans passer une heure à copier-coller des commandes.
Prompt OMO :
Investigue le pod qui redémarre en boucle dans le namespace production sur Kubernetes. Donne-moi : nom du pod, dernier événement, derniers logs, image utilisée, et une hypothèse de cause. Utilise la catégorie quick.
Commandes que l’agent va probablement exécuter :
kubectl get pods -n production kubectl describe pod <pod-name> -n production kubectl logs <pod-name> -n production --previous kubectl get events -n production --sort-by='.lastTimestamp'
L’agent va synthétiser les résultats en un résumé lisible. Vous n’avez plus qu’à prendre une décision.
Astuce : Quand vous investiguez un pod, demandez toujours
--previouspour voir les logs du conteneur avant le redémarrage. Les logs actuels d’un pod qui redémarre en boucle sont souvent vides.
5.2 Debug SQL avancé et rédaction d’un bug report
Vous avez une requête complexe qui est lente ou incorrecte. Vous voulez la corriger ET rédiger un rapport de bug clair pour votre équipe. C’est un workflow quotidien pour les supports de niveau 2 et 3.
Cas PostgreSQL : requête lente
Prompt OMO :
La requête reporting_mensuel.sql sur PostgreSQL met 45 secondes à s'exécuter. Optimise-la sans changer le résultat. Puis rédige un bug report au format Markdown avec : titre, description, requête originale, requête corrigée, explication, et tests suggérés. Utilise la catégorie quick.
Cas MSSQL : résultat incorrect
Prompt OMO :
La procédure stockée sp_GetMonthlySales sur MSSQL retourne des montants doublés à partir du 15 du mois. Analyse la procédure, le schéma des tables impliquées, et propose une correction. Utilise la catégorie quick.
L’agent va, dans les deux cas :
- Lire la requête ou la procédure stockée.
- Inspecter le schéma des tables concernées.
- Expliquer le plan d’exécution (
EXPLAIN ANALYZEpour PostgreSQL, plan de requête pour MSSQL). - Proposer une correction.
- Rédiger le bug report si demandé.
Exemple de sortie attendue pour le bug report :
## Bug report : lenteur du reporting mensuel
### Description
La requête `reporting_mensuel.sql` met 45 secondes à s'exécuter sur PostgreSQL de recette.
### Requête originale
```sql
SELECT * FROM commandes c
JOIN lignes l ON l.commande_id = c.id
WHERE c.date_commande >= DATE_TRUNC('month', NOW());
```
### Requête corrigée
```sql
CREATE INDEX idx_commandes_date_trunc ON commandes (DATE_TRUNC('month', date_commande));
SELECT c.id, c.date_commande, SUM(l.montant)
FROM commandes c
JOIN lignes l ON l.commande_id = c.id
WHERE c.date_commande >= DATE_TRUNC('month', NOW())
GROUP BY c.id, c.date_commande;
```
### Explication
La requête originale utilisait `SELECT *`, provoquait un seq scan et chargeait trop de colonnes inutiles. La version corrigée limite les colonnes et ajoute un index fonctionnel.
### Tests suggérés
1. Vérifier le temps d'exécution sur un mois complet.
2. Vérifier que le total reste identique avec la requête originale.
5.3 Manipulation git complexe avec le skill git-master
Le skill git-master est obligatoire pour tout ce qui touche à git au-delà d’un simple commit. Il gère le rebase interactif, le bisect, la recherche d’historique (git log -S), et les merges conflictuels.
Exemple de rebase conflictuel :
/load git-master Rebase ma branche feature/api-v2 sur main. Résous les conflits en gardant les changements de feature/api-v2 pour les routes et ceux de main pour les tests. Utilise la catégorie quick.
Exemple de git log -S :
/load git-master Trouve dans quel commit la fonction calculateTotal a été supprimée du fichier billing.js
Exemple de bisect :
/load git-master Git bisect pour trouver le commit qui a introduit l'erreur "connection timeout" dans les tests d'intégration.
Exemple de merge conflictuel :
/load git-master Merge la branche release/2026-06 dans main. Il y a des conflits sur les fichiers de configuration. Résous-les en conservant les valeurs de production de main et les nouvelles clés de release/2026-06.
Attention : Quand vous demandez une manipulation git, sauvegardez votre travail et vérifiez le résultat avec
git statusetgit log --onelineavant de pousser. Un agent peut faire une erreur, surtout sur des conflits complexes.
5.4 Automatisation Python/SQL pour dépanner une intégration logicielle
Vous devez comparer les données entre deux systèmes, par exemple un CRM et un ERP. OMO peut écrire un script Python qui lit les deux sources, compare les IDs, et produit un rapport d’écart.
Cas 1 : comparaison de clients entre CRM et ERP
Prompt :
Écris un script Python compare_clients.py qui : se connecte à PostgreSQL (table crm.clients) et à MSSQL (table erp.t_customers), compare les clients par email, et génère un CSV avec les écarts. Utilise des variables d'environnement pour les credentials. Utilise la catégorie quick.
Le script attendu ressemblera à ceci :
import os
import csv
import psycopg2
import pyodbc
POSTGRES_DSN = os.environ['POSTGRES_DSN']
MSSQL_DSN = os.environ['MSSQL_DSN']
def load_postgres_emails():
conn = psycopg2.connect(POSTGRES_DSN)
cur = conn.cursor()
cur.execute("SELECT email FROM crm.clients WHERE actif = true")
return {row[0].lower() for row in cur.fetchall()}
def load_mssql_emails():
conn = pyodbc.connect(MSSQL_DSN)
cur = conn.cursor()
cur.execute("SELECT email FROM erp.t_customers WHERE status = 'A'")
return {row[0].lower() for row in cur.fetchall()}
def main():
pg_emails = load_postgres_emails()
ms_emails = load_mssql_emails()
only_in_pg = sorted(pg_emails - ms_emails)
only_in_ms = sorted(ms_emails - pg_emails)
with open('ecarts_clients.csv', 'w', newline='') as f:
writer = csv.writer(f)
writer.writerow(['source', 'email'])
for email in only_in_pg:
writer.writerow(['postgres', email])
for email in only_in_ms:
writer.writerow(['mssql', email])
print(f"Écarts trouvés : {len(only_in_pg)} dans PostgreSQL, {len(only_in_ms)} dans MSSQL.")
if __name__ == '__main__':
main()
Cas 2 : génération d’un script SQL de réconciliation
Vous pouvez aussi demander à OMO de générer directement une requête SQL de réconciliation, par exemple pour trouver les commandes présentes dans l’ERP mais absentes du CRM.
Écris une requête SQL qui compare les commandes de l'ERP (MSSQL, table erp.t_orders) avec celles du CRM (PostgreSQL, externe via postgres_fdw, table crm.orders). Liste les commandes présentes dans erp.t_orders mais absentes de crm.orders. Utilise la catégorie quick.
Cela permet de déléguer la synthèse de deux sources à une requête exécutable par votre DBA ou votre outil de supervision.
Coût : Ce genre de script ou de requête est un cas d’école pour la catégorie quick. N’utilisez pas un modèle plus gros.
5.5 Mode “proxy” : se connecter à IBM MQ, Vault, Kafka, psql, sqlcmd
Le mode proxy est une pratique de sécurité. Au lieu d’écrire un mot de passe dans le prompt, vous demandez à OMO d’utiliser un outil intermédiaire qui lit le secret depuis un endroit sûr.
Exemple avec psql :
Connecte-toi à la base PostgreSQL de recette via le script /opt/scripts/psql_proxy.sh et exécute la requête dans check_users.sql. N'affiche jamais le mot de passe.
Exemple avec Vault :
Utilise le skill proxy pour lire le secret secret/data/api-keys et injecter la clé dans config.json sans l'afficher.
Exemple avec Kafka :
Publie le message contenu dans message.json sur le topic orders via le wrapper /opt/tools/kafka_proxy.py. Ne me montre pas les credentials.
Le principe est toujours le même : l’agent n’a jamais le secret en clair. Le secret est géré par un outil externe de confiance.
5.6 Anti-patterns dans les workflows OMO
- Donner les droits root à l’agent “juste pour aller plus vite” : c’est une erreur de sécurité. L’agent doit avoir les droits minimums.
- Exécuter des commandes de production sans confirmation : configurez OMO pour demander une validation avant toute action critique.
- Oublier de vérifier les logs de l’agent : l’agent peut mal interpréter une sortie de commande. Relisez toujours les commandes exécutées.
- Utiliser un modèle trop gros pour une tâche simple : une investigation de pod ou un grep ne mérite pas GPT-5.4.
- Pousser du code sans revue : même généré par OMO, le code doit être relu, idéalement par Oracle puis par un humain.
5.7 Mini-lab 4 : Scénario d’investigation pod Kubernetes
Objectif : Utiliser OMO pour investiguer un pod en erreur et produire un résumé actionnable.
Durée : 15 minutes.
Prérequis : Accès à un cluster Kubernetes (même de recette) avec au moins un pod en état CrashLoopBackOff ou Error.
Étapes :
- Connectez-vous au cluster :
kubectl config use-context <context>
- Demandez à OMO :
Dans le namespace recette, trouve le pod qui n'est pas Running, investigue sa cause, et propose une action corrective. Affiche les commandes exécutées et leurs sorties.
- L’agent va exécuter des commandes du type :
kubectl get pods -n recette kubectl describe pod <pod> -n recette kubectl logs <pod> -n recette --previous
Sortie attendue : Un rapport structuré avec le nom du pod, son statut, l’événement clé, l’erreur dans les logs, et une action corrective (par exemple “augmenter la limite mémoire” ou “corriger la variable d’environnement DATABASE_URL”).
Critères de réussite :
- Le pod en erreur est identifié.
- Les logs et événements sont collectés.
- L’hypothèse de cause est cohérente.
- L’action proposée est réalisable.
6. Lab final : Projet complet (20 min)
6.1 Objectif
Développer une mini application web de monitoring de pods Kubernetes, la containeriser, et la déployer sur Kubernetes. Vous utiliserez /start-work, Prometheus pour planifier, Atlas pour exécuter, et Oracle pour la revue.
6.2 Durée et prérequis
Durée : 20 minutes.
Prérequis :
- Accès à un namespace Kubernetes.
- Python 3.10+ et Flask installés localement.
kubectlCLI configuré.- Un compte pour pousser des images (registry interne ou Docker Hub).
6.3 Étapes
Étape 1 : Lancer le plan avec @plan
@plan "Créer une application Flask qui affiche la liste des pods d'un namespace Kubernetes avec leur statut. L'application doit être containerisée avec Docker et déployable sur Kubernetes via kubectl apply et un Service/Ingress."
Prometheus va produire un plan structuré, par exemple :
- Créer
app.pyavec Flask et kubernetes-client. - Créer
requirements.txt. - Créer
Dockerfile. - Builder l’image et la pousser.
- Déployer sur Kubernetes.
- Exposer le service.
- Vérifier le déploiement.
Étape 2 : Exécuter avec /start-work
/start-work @sisyphus exécute le plan de Prometheus. Utilise la catégorie quick pour les étapes simples et un modèle plus fort uniquement pour la configuration sécurisée de kubernetes-client.
L’agent va créer les fichiers, builder l’image, et déployer.
Exemple de contenu attendu pour app.py :
from flask import Flask, jsonify
from kubernetes import client, config
import os
app = Flask(__name__)
@app.route('/pods')
def pods():
namespace = os.environ.get('NAMESPACE', 'default')
config.load_incluster_config()
v1 = client.CoreV1Api()
pod_list = v1.list_namespaced_pod(namespace)
result = []
for pod in pod_list.items:
result.append({
'name': pod.metadata.name,
'status': pod.status.phase,
'restarts': pod.status.container_statuses[0].restart_count if pod.status.container_statuses else 0
})
return jsonify(result)
@app.route('/health')
def health():
return jsonify({'status': 'ok'})
if __name__ == '__main__':
app.run(host='0.0.0.0', port=8080)
Étape 3 : Revue avec Oracle
@oracle relis app.py, Dockerfile et le déploiement Kubernetes. Cherche les problèmes de sécurité, les erreurs évidentes et les améliorations possibles.
Étape 4 : Déploiement sur Kubernetes
Les commandes attendues :
kubectl apply -f deployment.yaml kubectl expose deployment pod-dashboard --type=LoadBalancer --port=8080 kubectl get svc pod-dashboard
Étape 5 : Vérification
kubectl get pods -n <votre-namespace> curl http://<service>/pods
6.4 Critères de réussite
- L’application Flask démarre localement ou dans un contètreur.
- L’image est buildée et poussée.
- Le pod tourne sur Kubernetes sans erreur.
- La route expose bien
/podset/health. - Oracle n’a pas identifié de faille critique non corrigée.
6.5 Déroulement type du lab final
Voici comment se déroule concrètement ce lab en 20 minutes :
- Minute 0-2 : Lancement de
@planet récupération du plan de Prometheus. - Minute 2-10 : Atlas/Sisyphus crée les fichiers et teste localement.
- Minute 10-14 : Revue par Oracle, corrections mineures si nécessaire.
- Minute 14-18 : Build, push et déploiement sur Kubernetes.
- Minute 18-20 : Vérification finale avec
kubectl get podsetcurl.
Si le temps est court, vous pouvez remplacer le déploiement réel par une simulation avec kubectl apply -f deployment.yaml sur un fichier généré par l’agent.
7. FAQ rapide et bonnes pratiques
Puis-je laisser OMO tourner sans surveillance ?
Non, sauf en mode ulw sur une tâche très bien cadrée et dans un environnement isolé. L’agent exécute des commandes réelles sur votre système. Surveillez les actions sensibles.
Que faire si l’agent fait une erreur ?
Revenez en arrière avec git, relisez les commandes exécutées, et affinez votre prompt. Les erreurs viennent souvent d’un manque de contexte ou d’une consigne floue.
Comment réduire la facture ?
- Utilisez la catégorie quick par défaut.
- Limitez la longueur des prompts.
- Évitez les modèles gros pour les tâches simples.
- Utilisez
/init-deepune seule fois par session de travail. - Faites relire par Oracle seulement sur le code critique.
Est-ce que le code généré est de qualité professionnelle ?
Il est souvent correct, mais il faut le relire. Oracle aide, mais un humain doit valider avant une mise en production. OMO est un accélérateur, pas un remplaçant.
Quelles sont les limites d’OMO ?
- L’agent ne sait pas ce qu’il ne sait pas. Il peut inventer des APIs ou des chemins.
- Il peut mal interpréter des logs complexes.
- Il n’a pas de mémoire permanente sauf si vous utilisez Librarian ou
/init-deep. - Il ne remplace pas une revue de pair humaine.
Conclusion
Oh My OpenAgent et Oh My OpenAgent ne remplacent pas votre expertise. Ils l’amplifient. En moins de deux heures, vous avez vu comment :
- Installer et lancer OMO.
- Utiliser les bons modèles pour maîtriser les coûts.
- Orchestrer des agents spécialisés selon la nature de la tâche.
- Exploiter les skills, les plugins et les MCP.
- Appliquer OMO à vos cas métier : pods Kubernetes, SQL, git, automatisation, rapports.
- Construire et déployer une petite application avec un workflow multi-agents.
La clé est de choisir le bon agent et le bon modèle pour la bonne tâche. Commencez par la catégorie quick et Sisyphus. Quand le sujet est complexe, faites appel à Prometheus, Hephaestus et Oracle. Quand vous ne connaissez pas le terrain, lancez /init-deep, @explore ou @librarian.
Prochaine étape : choisissez un bug ou une tâche répétitive de votre backlog, et essayez de la résoudre avec OMO en respectant les règles de coût et de sécurité vues dans ce cours. Commencez petit, mesurez le gain, et itérez.