- non seulement j’ai mis en place une équipe d’ingénieurs IA pour réaliser des tâches complexes
- mais je les ai intégrés dans Open Code, le meilleur agent de codage qui existe
Open Code a grandi
Open Code a considérablement mûri.
- Vous pouvez désormais contrôler des sous-agents,
- suivre leur travail,
- installer des compétences,
- piloter chaque élément du système,
- l’intégrer à GitHub,
- utiliser des images,
- et même utiliser votre iPad pour coder.
Et si cela ne suffit pas, jetez un œil à ces blogueurs qui utilisent Open Code en toute décontraction sur leur site.
Un leader incontesté
Avec plus de 100 000 étoiles, Open Code est le leader incontesté des agents de codage. Ce n’est plus seulement une option en terminal, mais un système capable de fonctionner avec une interface graphique complète, sur le Web, dans votre IDE et, bien sûr, en ligne de commande. Mais comme pour tout grand projet, tout a commencé par un petit drame.
Open Code a démarré comme un agent IA en terminal, créé par un développeur sur son temps libre. Dax et Adam, deux développeurs populaires, l’ont rejoint, contribuant à faire avancer le projet et obtenant même le domaine opencode.ai. Charm, la société connue pour ses projets open source en terminal, a manifesté son intérêt et a proposé des postes aux trois développeurs, leur demandant en fait de rejoindre l’entreprise.
Alors que le premier développeur a accepté, Dax et Adam ont refusé, affirmant vouloir conserver Open Code tel qu’il est : ouvert et sans financement par capital-risque, ce qui conduit généralement à une forme de monétisation et ne tient pas nécessairement compte des intérêts des utilisateurs. Pour résumer, le désaccord portait principalement sur le nom.
Dax a publié un tweet pour expliquer son point de vue, précisant que lui et Adam ne se souciaient pas du code et avaient en fait réécrit open code à partir de zéro. Quoi qu’il en soit, le PDG de Charm a répondu en exposant leur version. Et si vous voulez connaître l’avis de la communauté, il suffit de lire les commentaires.
L’agent de Charm devient Crush
Pour faire court, l’agent de Charm, un très beau projet si je dois être honnête, est aujourd’hui connu sous le nom de Crush et conserve toujours les commits de Dax et Adam dans son historique si on creuse suffisamment.
L’histoire continue
Bon, mis à part le drame, Open Code était autrefois un projet parallèle sous SSD et fait désormais partie d’une structure plus large appelée Anomaly, qui regroupe SSD, Open Code, Openoth et d’autres projets soutenus par Y Combinator, Max Levchin (l’un des fondateurs de PayPal) et d’autres.
Cela apporte des fonds de capital-risque, peut-être avec plus de contrôle pour les développeurs plutôt que de faire partie de quelque chose dont ils ne sont pas responsables. Et c’est quelque chose que j’apprécie.
L’agent open source s’intègre à n’importe quel modèle et peut être installé comme vous le souhaitez. Grâce à ses nouvelles fonctionnalités, il recommande désormais l’un de ces deux terminaux: Wezterm ou Gostty.
Ce que vous apprécierez en téléchargeant ces terminaux :
- Ultra-rapide et réactif – L’accélération GPU élimine tout décalage lors des sorties OpenCode volumineuses ou des requêtes Claude.
- Défilement fluide – Aucun à-coup ni retard lors de la navigation rapide dans de longs journaux, des blocs de code ou des erreurs.
- Propre et agréable à l’œil – Polices nettes, rendu parfait, moins de fatigue oculaire lors de longues sessions.
- Fonctionnalités et sensation natives – Les divisions/onglets intégrés fonctionnent très bien pour le multitâche sans les tracas de tmux.
Configuration et premiers pas
Nous aborderons la configuration en détail, mais comme on peut s’y attendre de la part de l’équipe qui l’a développé, elle est entièrement personnalisable via le JSON d’Open Code, qui peut être spécifique à un projet, global, et même remplacé par des variables d’environnement.
Je passerai sur la partie installation. Une fois Open Code prêt, vous verrez toute une série d’options intéressantes, de l’ACP au MCP en passant par « create », un petit assistant très pratique qui vous aide à créer un agent étape par étape.
Il existe également une option pour servir un serveur Open Code sans interface, d’exécuter une instance web, d’afficher les statistiques de tous les utilisateurs précédents, ainsi que de nombreuses autres fonctionnalités.
C’est parti
Open Code lance l’interface TUI avec le contexte du chemin actuel pour l’intégrer visuellement dans votre terminal. Il suffit d’installer le thème de votre choix (/themes) et le tour est joué.
La prochaine étape consiste probablement à choisir un modèle. Il y a Claude, disponible via Zen et Anthropic, ainsi que d’autres, mais surtout un modèle intéressant appelé Big Pickle, qui est un modèle d’Open Code libre d’utilisation pour le moment. Si ça ne vous dérange pas qu’il s’entraîne sur vos données, utilisez-le comme bot open source ; c’est très pratique et efficace.
Parmi les autres options gratuites notables, on trouve Miniax qui, selon Anthropic, est un LLM chinois qui « boit » littéralement vos données, alors à vous de juger.
Un petit mot sur Zen pour ceux qui ne connaissent pas : Zen est un routeur Open Code qui vous permet, selon les termes de l’équipe, d’entrer vos informations de carte bancaire une seule fois pour accéder à une liste de modèles testés et vérifiés.
Vous n’êtes pas satisfait que Claude « boive » vos tokens ? Passez à Codeex, Gemini ou à l’une des dizaines d’autres options. Et si vous êtes assez audacieux, vous pourriez même essayer Kimmy. Certains affirment qu’Opus est plus lent que Kimmy pour la plupart des développements. Bref, nous nous éloignons du sujet. Choisissez votre modèle ou Zen et passez à autre chose. Perso, en ce moment je termine mes api key Grok et Deepseek…
Important : Open Code ne cherche pas à tirer profit de Zen. Ils vous facturent les frais de carte de crédit au prix coûtant et rien de plus. Dès que votre solde est inférieur à 5 $, ils rechargent automatiquement 20 $ supplémentaires, ce qui, avec Claude, peut arriver toutes les heures. Mon Dieu, j’aimerais bien que ce soit une blague… (tous l’intérêt de la clé api Grok qui a l’air gratuite en comparaison, même si elle n’est pas parfaite).
Sessions et base de données
Une fois sélectionné, vous pouvez commencer à interagir avec votre agent.
Chaque session est enregistrée, et vous pouvez utiliser la commande « slash sessions » pour les retrouver dans l’historique. Un changement notable apporté récemment : le passage de JSON, qui stockait les sessions, à une base de données complète fonctionnant sous SQLite, rend l’expérience bien plus fluide lors de la recherche, du filtrage et du retour aux sessions.
Cette base de données, soit dit en passant, est accessible en exécutant open code DB. Je ne vois pas trop pourquoi vous en auriez besoin si vous ne développez pas sur Open Code. Sauf indication contraire, elle est stockée dans le répertoire partagé local d’Open Code.
- Une session contient l’historique complet,
- la fenêtre de contexte,
- le modèle actif et tout le reste, comme si vous ne l’aviez jamais quittée.
Je l’utilise constamment pour démarrer de nouvelles sessions uniquement lorsque je travaille sur une fonctionnalité entièrement nouvelle sans rapport avec le travail précédent.
Les agents : le premier élément constitutif majeur
Le premier élément constitutif majeur d’Open Code concerne les agents
Open Code en compte deux types :
les agents principaux et les sous-agents. Les deux agents principaux que vous avez sûrement déjà remarqués sont « plan » et « build », qui diffèrent essentiellement par leurs autorisations : « plan » peut uniquement lire et planifier, mais ne peut pas exécuter, même si on le lui demande.
Vous avez sûrement vu des gens devenir fous avec les agents.
- Ils ont un développeur
- un développeur senior
- un responsable marketing
- un commercial
Et si vous pensez que je plaisante, sachez que des gens essaient réellement de construire des choses aussi farfelues. Pour moi, cela n’a absolument aucun sens. Non seulement ce ne sont que des fichiers vides, mais même si j’ai moi-même construit quelque chose de modeste, je pense que la séparation a ici tout son mérite.
J’ai un plan, une structure et un agent supplémentaire qui résout mes tâches complexes, les fonctionnalités importantes et tout ce qui nécessite un système plus robuste.
Les sous-agents sont des agents spécialisés que vous pouvez appeler pour des tâches spécifiques et qui s’exécutent en arrière-plan. Open Code en possède deux. Le sous-agent général peut exécuter et explorer, mais sert principalement à la lecture. Taper « at » vous permettra d’invoquer le sous-agent dont vous avez besoin, soit depuis l’invite de commande, soit depuis les instructions de l’agent principal.
L’exemple tiré de la documentation montre le sous-agent de révision de code qui ne peut pas écrire mais dispose d’instructions pour effectuer une révision axée sur la sécurité et les performances.
Configuration de vos agents
Votre configuration pour les définir se trouve dans config/open code. Vous y trouverez plusieurs répertoires, tels que agent, command et skills. Mais le plus simple est d’ouvrir le fichier JSON d’Open Code et de les définir là-bas.
Lorsque vous redémarrerez, vous verrez un nouveau réviseur de code que vous pourrez appeler à votre guise.
Pour rendre ce sous-agent de révision de code encore plus intéressant, j’utilise un outil appelé GH dash pour prévisualiser les PR. J’ai un raccourci clavier qui ouvre une nouvelle fenêtre T-Max, crée un worktree avec work trunk, et ouvre open code avec une invite.
Ou bien nous pouvons simplement l’exécuter et demander à notre réviseur de code de faire son travail.
C’est l’une de ces automatisations qui vous donnent l’impression de vous rendre obsolète. À l’instar de ce réviseur de code, vous pouvez en ajouter d’autres, comme un ingénieur en sécurité, avec lequel vous pouvez commencer à communiquer en demandant à votre réviseur de code de déléguer les tâches de sécurité à cet autre agent.
Sécurité : ce qui m’empêche de dormir
C’est là que ça devient vraiment intéressant. Et honnêtement, je pense qu’ajouter un ingénieur en sécurité prend encore plus de sens quand on l’associe à ce que je vais vous montrer.
Chacun de ces agents que nous développons aura, à un moment ou à un autre, besoin d’identifiants, de clés API, de jetons, de mots de passe de base de données. Vous voyez l’idée. Et voici ce qui m’empêche de dormir la nuit. La plupart d’entre nous se contentent de stocker ces clés dans des variables d’environnement ou des fichiers de configuration, et on en reste là.
Mais c’est une faille de sécurité énorme qui ne demande qu’à éclater. Si votre machine est volée, si quelqu’un trouve cette clé dans un dépôt public, si quelqu’un parvient à s’introduire dans votre pipeline CI par ingénierie sociale, c’est fini. Cette clé statique existe pour toujours, tout comme l’accès qu’elle accorde.
Descope et les jetons JIT
C’est là que Descope entre en jeu et c’est pourquoi je l’intègre dans Open Code.
L'IA s'invite partout dans notre quotidien, mais les gros fournisseurs (Claude, Gemini, etc.) imposent de plus en plus de filtres et de censures qui biaisent les réponses. Pour poser des questions vraiment libres sans garde-fous...
J'utilise une plateforme qui rend ces modèles (Claude Opus 4.6, Gemini 3.1 Uncensored, etc.) totalement sans restriction. Ça change la vie pour les recherches approfondies ou créatives.
→ Tester l'IA sans filtre (30% off + 7 jours gratuits)Au lieu de clés statiques, vous obtenez ce qu’on appelle des jetons JIT (just-in-time). Votre agent demande l’accès. Descope vérifie votre identité, émet un jeton à durée de vie limitée, et ce jeton expire après quelques minutes. Cela change complètement la donne en matière de sécurité autour des agents. Mais s’ils se promènent avec des clés permanentes, nous ne faisons que créer davantage de cibles.
=> Lorsque vous ajoutez ce sous-agent ingénieur en sécurité, confiez-le à Descope. Votre futur vous en remerciera.
Les outils/projets de sécurité alternatifs
- Pipelock (open-source, single binary) : un proxy qui surveille les requests sortants de l’agent, scanne pour des leaks DLP (data loss prevention), bloque les exfiltrations potentielles d’API keys.
- llm-secrets ou outils similaires client-side : chargent les secrets de manière masquée (l’agent voit seulement $env[PRIVATE_KEY] sans la valeur réelle), décryptent localement en subprocess isolé, jamais dans le contexte LLM. Ça évite que la clé arrive chez Anthropic/OpenAI/Gemini.
- Utiliser un vault externe avec short-lived tokens (la vraie solution JIT) : HashiCorp Vault (open-source) ou AWS Secrets Manager / GCP Secret Manager avec just-in-time access via leur API (Vault a des engines comme « database » ou « transit » qui génèrent des creds temporaires).
- Dans ton skill/agent Open Code : créer un custom tool qui appelle l’API Vault pour « lease » un token (ex: 5-10 min TTL).
Exemple de flow :Agent a besoin d’une clé AWS → tool appelle Vault → Vault vérifie identité (via cert, token statique sécurisé, ou même OIDC si tu pushes) → retourne token temporaire. Le token meurt auto après usage/timeout. - Intégration simple dans Open Code : Crée un custom tool (voir docs Open Code : https://opencode.ai/docs/custom-tools) ou un MCP server qui wrappe l’appel au vault.
- Dans le prompt du « security engineer » sub-agent : « Avant toute utilisation de credentials, appelle le tool ‘get-jit-credential’ avec le service requis. N’utilise jamais de clé hardcodée ou d’env var directe. » Pour l’auth initiale vers Vault : utilise un seul token statique bien protégé (ex: dans un keyring OS ou 1Password CLI), ou mieux : auth par certificat machine.
- Alternatives plus légères / open-source immédiates : 1Password CLI ou Bitwarden CLI + script wrapper : l’agent appelle un tool qui fetch la secret via CLI et l’injecte temporairement (pas du vrai JIT, mais mieux que .env).
Créer votre propre agent
Si vous décidez de créer votre propre agent, exécutez la commande open code agent create. Un assistant s’affichera pour vous demander de décrire la fonction de l’agent. Vous pourrez définir les autorisations de manière interactive, puis le configurer :
- un agent principal,
- des sous-agents,
- ou les deux, pouvant servir d’agent principal et d’agent auquel vous pourrez attribuer des tâches plus tard.
La beauté du résultat généré réside dans le fait qu’il se trouve dans un fichier autonome, un plan d’instructions complet avec des exemples, le contexte des principes de base, des lignes directrices, des cas limites et la manière dont vous souhaitez voir le résultat.
Bon, ne nous emballons pas trop. Ce n’est pas vraiment un modèle complet entraîné sur mesure. Il s’agit simplement d’une injection de prompt, et sa qualité dépend entièrement de vous. Même si elle est de haute qualité avec des directives et tout le reste, rien d’autre qu’un ensemble d’autorisations n’empêche réellement l’agent de déroger au script et de les contourner. Ça m’est arrivé plus d’une fois. À utiliser avec prudence.
Pourquoi s’embêter avec des sous-agents plutôt qu’un simple fil de discussion ?
Cette séparation aide à deux égards. Premièrement, elle réduit les hallucinations : plus la tâche est spécifique, moins le modèle fait d’erreurs et meilleures sont ses performances. Les sous-agents sont donc un excellent moyen de décomposer les tâches et les instructions. Deuxièmement, cela facilite le suivi : vous verrez bientôt comment le fil principal que nous voyons en tant qu’utilisateurs est l’agent parent. Au-delà des prompts et du contexte de chaque agent, le simple fait qu’ils soient séparés représente beaucoup de travail.
Les compétences : le nouveau concept
Ce qui m’amène à mon dernier concept important. Un élément relativement nouveau dans le domaine des agents de codage, et plus particulièrement dans Open Code : les compétences (skills).
Au départ, les compétences seront vides. J’en ai ajouté quelques-unes. La première est la plus cruciale : elle donne à votre agent la capacité de localiser et d’installer des compétences de manière autonome.
Votre autre option consiste à trouver une liste telle que skills.sh et à parcourir des dizaines de milliers d’options open source conçues pour différentes tâches. Mais attention, il y a beaucoup de déchets. Il y a aussi SkillsMP, développé par Manus, qui semble être une méta-entreprise. Elle prétend disposer de près d’un demi-million de compétences disponibles.
Ce niveau de croissance exponentielle des compétences en IA donne vraiment l’impression qu’il s’agit de compétences générées par l’IA. Si vous choisissez quelque chose, une bonne idée est de suivre une plateforme fiable comme Vercel. Utilisez la commande npx et suivez l’assistant qui vous demandera si la compétence est pertinente pour un modèle ou un fournisseur spécifique, si elle est globale ou propre au projet, etc.
Une fois installée, vous pouvez appeler votre nouvelle compétence. Au cas où cela ne serait pas clair, les compétences, au-delà de toutes les explications compliquées, ne sont qu’une autre forme d’injection de prompt. L’idée est qu’elles ne sont pas chargées dans chaque fenêtre de contexte comme un prompt ou le fichier MD d’un agent. Elles sont là pour être utilisées à la demande.
Elles aident à guider, connecter et utiliser de nombreux autres outils et peuvent s’accompagner de scripts et d’exemples de code. Voici une compétence d’ingénieur DevOps qui dispose d’un fichier MD lui donnant un nom et des instructions textuelles claires. Tout cela n’est que des références de code et des éléments que l’agent aurait probablement pu trouver en cherchant en ligne.
Les raccourcis clavier
En attendant, parlons d’un de mes sujets préférés en tant que fier utilisateur de Neovim : les raccourcis clavier.
On ne voit pas grand-chose d’autre que dans Vim et Tmux : une touche leader qui change le mode de raccourcis pour qu’il n’interfère pas avec vos autres configurations. Je l’ai changée pour Ctrl+O pour l’instant. Ce n’est pas parfait, mais ça me convient.
L’une de mes choses préférées à faire avec mes raccourcis clavier est d’ouvrir un éditeur via open code. La boîte de prompt est sympa, mais y faire des sauts de ligne ou ajouter des listes n’est pas très pratique. Hop, mon prompt est dans Neovim. Enfin, je peux éditer mon texte comme un être humain avec un peu de dignité avant que l’IA ne me prive de ça aussi.
Constituer une équipe d’agents
Il est temps de constituer une équipe
Mais avant de m’y mettre, laissez-moi dire ceci. Tout cela est en mode test. C’est ainsi que je travaille en local, mais je l’améliore constamment. En fait, je pense que c’est la seule vraie façon de travailler correctement avec des agents : les corriger et faire en sorte qu’ils se souviennent de ce que vous venez de modifier en ajustant les prompts, les compétences et les paramètres.
La configuration d’une équipe autonome
J’ai décidé de tester une équipe autonome d’ingénieurs.
J’ai créé un chef d’équipe qui orchestre et délègue les tâches. Veuillez ne pas vous contenter de les ajouter au long fichier JSON comme je l’ai fait ; utilisez le générateur d’agents Open Code.
| Rôle | Responsabilités | Autorisations |
|---|---|---|
| Chef d’équipe | Orchestre et délègue les tâches, recueille les exigences | Lecture et délégation |
| Chef de produit | Lit, explore et comprend l’histoire utilisateur | Lecture seule |
| Développeur backend | Implémente les fonctionnalités | Lecture et écriture |
| Testeur / QA | Teste les fonctionnalités en parallèle du développement | Lecture et exécution de tests |
| Réviseur de code | Révision axée sur la sécurité et les performances | Lecture seule |
La prochaine fois que je lancerai Open Code, le chef d’équipe sera là pour servir. Vous remarquerez immédiatement une approche plus structurée des demandes.
Ca fonctionne, mais si vous voulez du tout-fait, il existe une équipe d’agents open source : Open Agents Control. Elle adopte une approche sérieuse avec un pipeline « plan first »… à tester.
Les agents de OpenAgentsControl (OAC)
| Nom de l’agent | Type | Rôle principal / Description |
|---|---|---|
| OpenAgent | Agent principal | Agent généraliste : tâches simples, questions, apprentissage du système, coordination initiale. Point d’entrée recommandé pour les nouveaux utilisateurs. |
| OpenCoder | Agent principal | Agent de développement production : fonctionnalités complexes, architecture, refactoring multi-fichiers, code de qualité expédiable. |
| SystemBuilder | Agent principal | Crée des systèmes IA personnalisés sur mesure (orchestrateurs, sous-agents, contextes, workflows) via un wizard interactif. |
| OpenFrontendSpecialist | Spécialiste catégorie (frontend) | Spécialiste frontend avec workflow structuré en 4 étapes : Layout (wireframe ASCII), Theme (design system, OKLCH), Animation (micro-interactions), Implementation (HTML sémantique). |
| ContextScout | Subagent auto-délégué | Découvre et priorise intelligemment les patterns pertinents dans les fichiers de contexte avant génération de code (arme secrète pour la cohérence). |
| TaskManager | Subagent auto-délégué | Décompose les fonctionnalités complexes en sous-tâches atomiques, vérifiables, avec suggestions d’agents et support d’exécution parallèle. |
| CoderAgent | Subagent auto-délégué | Génération focalisée et précise de code en respectant strictement les patterns du projet. |
| TestEngineer | Subagent auto-délégué | Rédaction de tests unitaires / intégration, approche TDD, validation des fonctionnalités. |
| CodeReviewer | Subagent auto-délégué | Revue de code automatisée + analyse de sécurité et de conformité aux standards. |
| BuildAgent | Subagent auto-délégué | Vérification de compilation, type checking, validation du build global. |
| DocWriter | Subagent auto-délégué / Spécialiste technical-writer | Génération automatique de documentation technique, README, guides, commentaires. |
| ExternalScout | Subagent auto-délégué (nouveau !) | Récupère la documentation live et à jour des bibliothèques externes (npm, GitHub, sites officiels) → évite les connaissances obsolètes. |
Plonger dans les sous-agents
Vous pouvez explorer en profondeur les sous-agents grâce aux flèches qui montrent des éléments que je n’avais vraiment jamais vus auparavant, comme un flux utilisateur dessiné par mon chef de produit et les modifications de code apportées par le développeur backend.
C’est agréable de voir l’interaction où le chef d’équipe demande au chef de produit de clarifier les exigences et de voir en temps réel comment le réviseur de code travaille et comment le testeur effectue ses tests à ses côtés.
Souvent, on voit une question posée par l’un des agents. Ou un autre agent chargé de développer une fonctionnalité qui revient me demander ce que je veux ou s’assurer que cela correspond à mes préférences avant de passer à la mise en œuvre.
Les limites du système
Certes nous avons une équipe. Mais cela vaut-il la peine ?
Eh bien, honnêtement, la structure est très pertinente lorsque je construis quelque chose d’important. Je l’utilise depuis quelques semaines et cela fonctionne à 95 %. Ce n’est en aucun cas parfait. Il y a des erreurs, mais je vais devoir aller plus loin pour dire si c’est révolutionnaire ou non.
Pour moi, le secret réside dans l’ajustement constant de ces sous-agents, chacun dans son propre fichier Markdown, et dans le fait de m’assurer qu’ils sont tous alignés sur ma façon de faire.
Au-delà des prompts et du contexte de chaque agent, le simple fait qu’ils soient séparés représente beaucoup de travail.
Les inconvénients
Gardez à l’esprit que ce n’est pas toujours idéal
Premièrement, cela implique beaucoup de tokens et les instructions sont beaucoup plus volumineuses. En fait, je laisse l’agent constructeur principal faire la majeure partie du travail qui ne constitue pas une nouvelle partie importante de mon application.
Deuxièmement, parcourir les sous-agents pour comprendre ce qui se passe et où placer leurs résultats n’est pas un plaisir. C’est sympa, mais vous préférereriez peut-être rester simple la plupart du temps.
Utiliser Open Code à votre façon
Utilisez Open Code là où cela vous convient
Open Code nvim est un plugin populaire qui vous permet d’invoquer open code depuis une session nvim en cours d’exécution.
C’est un plugin Neovim qui fait office d’interface graphique pour opencode. En gros : ça transforme ton Neovim en un environnement super productif avec IA contextuelle, un peu comme Cursor ou GitHub Copilot Chat, mais en version open-source + terminal-first et très personnalisable.
| Point fort | Description |
|---|---|
| Panneau de chat persistant | Un panneau de discussion dédié reste ouvert en permanence dans Neovim. Vous pouvez y converser naturellement avec l’IA sans perdre le contexte ni changer de fenêtre. |
| Contexte automatique ultra riche | Le plugin collecte de manière autonome et intelligente toutes les informations pertinentes de votre environnement actuel : • le fichier sur lequel vous travaillez, • la sélection ou le fragment de code que vous avez surligné, • les diagnostics LSP (erreurs, avertissements, suggestions), • la position exacte de votre curseur. Grâce à cela, vos prompts deviennent beaucoup plus précis : l’IA « voit » sur quoi vous êtes en train de travailler. |
| Chat rapide | Interaction ultra-rapide : vous sélectionnez un bout de code, vous tapez <leader>o/ (ou la touche que vous avez configurée), vous formulez votre demande de modification, l’IA propose une solution directement dans le chat. |
Interface web et iPad
Une autre façon d’utiliser Open Code consiste à passer par une interface web, ce qui ouvre tout un monde de nouvelles possibilités. Elle s’exécute sur un port local que vous pouvez ensuite exposer à l’extérieur avec un outil comme ngrok et consulter à distance depuis un iPad.
Vous y trouverez les sessions récentes avec les modifications de code et tout ce à quoi vous pouvez penser.
L’application GUI
Avant de conclure, je ne peux pas passer sous silence l’application GUI, une application entièrement native dont je ne suis pas sûr de l’avoir vue dans la liste des options disponibles dans la documentation. Elle est encore en version bêta, mais fonctionne parfaitement.
Ouvrez une session et continuez comme sur l’interface web, avec quelques ajouts sympas qui vous indiquent qu’un agent est en attente grâce à des notifications sonores et visuelles du système d’exploitation.
Prise en charge des images : la fonctionnalité phare
Une autre fonctionnalité assez géniale, et la raison pour laquelle je vous ai initialement dit d’attendre pour voir pourquoi Westerm ou Ghosty sont indispensables ici : la possibilité de partager des images. Eh oui, vous pouvez faire glisser une image vers Open Code dans le terminal et lui faire traiter une liste d’exigences, un thème, un style que vous souhaitez voir implémenté ou n’importe quel élément visuel.
Cela fait d’Open Code un outil fantastique capable de résoudre littéralement n’importe quoi, n’importe où. La question n’est donc pas de savoir si Open Code va rester ou non. Il est profondément intégré à tout ce que je fais. Je trouve qu’il est meilleur, plus facile, plus flexible pour configurer la disponibilité, ou n’importe quoi d’autre, vraiment.
Je n’ai même pas abordé l’écosystème, les projets qui l’entourent et tant d’autres fonctionnalités géniales, par souci de concision. Mais comme vous pouvez le constater, il est partout et fait un travail fantastique.
Gardez juste à l’esprit que la qualité varie considérablement. L’essentiel est de construire progressivement votre propre système, en ajustant les agents et les compétences à mesure que vous découvrez ce qui fonctionne pour votre workflow spécifique. C’est ainsi qu’on tire vraiment parti de ces outils :
- l’expérimentation
- et l’itération constante
Et si vous hésitez encore à franchir le pas, rappelez-vous qu’il y a 11 mois, l’idée même que l’IA puisse écrire 90% du code semblait folle. La vraie question n’est plus de savoir si cela va arriver, mais comment vous allez vous adapter à cette nouvelle réalité.