Comment utiliser OpenCode Desktop

Semaine 1 : Installer et maîtriser le socle › Semaine 1 : Partie 2 (Installer le socle) › Installation technique

Cette leçon explique comment utiliser OpenCode Desktop au quotidien dans ton workspace : choisir une route de modèle, travailler au bon niveau de dossier, lire le contexte, préparer un plan, exécuter une modification contrôlée et retrouver le résultat dans le Business Brain.

Pourquoi tu fais ça

OpenCode Desktop est le poste de travail où tu dialogues avec l’IA sur tes fichiers, tes règles et, seulement lorsque nécessaire, tes outils connectés. Il transforme une conversation isolée en travail traçable dans ton espace de contexte.

OpenCode est un harnais agentique open source : le modèle produit le raisonnement et le texte, tandis qu’OpenCode lui donne un cadre de travail. Selon les permissions accordées, l’IA peut lire et modifier des fichiers, utiliser des commandes, appeler des outils, déléguer une recherche ou préparer un plan. Elle ne remplace pas ta décision ni tes validations.

OpenCode Desktop est une interface, pas le modèle, pas la mémoire de ton entreprise et pas un fournisseur de données. Le Business Brain reste dans tes fichiers Markdown. Le provider et le modèle actifs déterminent où le contenu de ta conversation est traité.

Objectif

À la fin de cette leçon, tu sauras :

ouvrir le bon workspace et reconnaître les éléments de l’interface utiles ;
choisir le provider et le modèle adaptés à une tâche ;
garder une liste de modèles lisible et éviter un mauvais routage ;
utiliser le mode Plan avant une modification qui mérite une validation ;
utiliser le mode Build pour exécuter une action explicitement validée ;
ajouter un fichier précis au contexte avec @ ou le trombone ;
retrouver une note, une session ou une commande avec Cmd+K ;
utiliser les skills et les MCP avec le minimum d’accès nécessaire ;
vérifier le résultat écrit dans ton Business Brain avant de poursuivre.

Avant de commencer

Tu dois avoir validé Installation technique. Prépare :

le dossier Workspace déjà ouvert dans OpenCode Desktop ;
le dossier Second Cerveau ouvert dans Obsidian ;
une route LLM déjà vérifiée sur une demande fictive ;
une tâche d’entraînement sans donnée réelle, par exemple une note fictive sur une décision commerciale ;
ton gestionnaire de secrets si tu dois vérifier un accès.

Ne teste pas une nouvelle route, un MCP ou une permission avec une donnée client, RH, financière ou stratégique réelle.

Partie 1 : reconnaître ton environnement de travail

Le workspace est la frontière de travail

Ouvre OpenCode Desktop sur Workspace, le dossier parent. L’IA peut alors suivre les règles de AGENTS.md, accéder au Business Brain dans Second Cerveau/ et, selon le pack livré, voir les projets voisins du workspace.

N’ouvre pas OpenCode directement dans Second Cerveau pour ce parcours. Obsidian ouvre le coffre métier ; OpenCode ouvre le workspace complet. Cette séparation permet aux règles et aux skills d’être disponibles sans transformer le coffre métier en environnement technique.

Pour une mission isolée, tu peux ouvrir un dossier de projet dédié. Dans ce cas, l’IA ne connaît que les fichiers présents dans ce dossier et les instructions qu’il contient. C’est utile pour un livrable ponctuel, à condition de ne pas oublier les informations nécessaires au travail.

Les éléments utiles de l’interface

Les libellés peuvent légèrement changer selon la version d’OpenCode Desktop. Retrouve les fonctions suivantes :

Élément	Utilité	Ton réflexe
Sélecteur de modèle	Choisir la route LLM de la session	Vérifier la route avant d’envoyer une information
Zone de demande	Décrire l’objectif, les contraintes et la sortie attendue	Dire ce qui doit être lu, produit et ne doit pas être fait
Sélecteur de mode	Passer de la préparation à l’exécution	Commencer en Plan pour une action non triviale
Trombone	Ajouter un fichier local au contexte de la demande	Vérifier le fichier avant de l’attacher
`@`	Référencer rapidement un fichier du workspace	Pointer une note précise plutôt que la résumer de mémoire
Panneau latéral	Ouvrir les statistiques, la console ou les documents	Diagnostiquer une session, pas surveiller chaque réponse
`Cmd+K`	Rechercher un fichier, une session ou une commande	Revenir vite au bon contexte

Lire la session sans se perdre dans la technique

Le panneau latéral, accessible depuis l’icône correspondante, propose habituellement deux vues utiles :

Statistiques : modèle utilisé, tokens d’entrée et de sortie, détail des messages et, selon la version, JSON envoyé au modèle. Utilise-la pour confirmer la route ou diagnostiquer un comportement inattendu.
Console : progression des appels d’outils et consommation du contexte. Utilise-la lorsqu’une session devient longue ou qu’un outil semble ne pas répondre.

Ces vues servent à comprendre un problème. Elles ne sont pas ton tableau de bord de performance. Si la conversation devient confuse ou approche la limite de contexte, résume le travail, termine proprement avec /done, puis commence une nouvelle session ciblée.

Partie 2 : choisir ton provider et ton modèle

Provider et modèle : deux décisions distinctes

Le provider est l’infrastructure qui reçoit la demande et exécute le modèle. Le modèle est le système qui génère la réponse. OpenCode Desktop relie les deux à ton workspace.

Question	Décision
Où la donnée est-elle traitée, avec quelles conditions de confidentialité, de coût et de vitesse ?	Provider
Quelle qualité de raisonnement, vitesse et spécialisation sont nécessaires à cette tâche ?	Modèle
Comment le modèle reçoit-il le contexte, les fichiers et les permissions ?	OpenCode Desktop

La route retenue dans Installation technique reste la référence. Vérifie les conditions réelles du produit et du compte avant de changer de provider, surtout pour une information classée orange ou rouge.

Connexions disponibles

OpenCode Desktop peut proposer deux formes de connexion selon le provider :

Clé API : elle est créée dans l’espace du provider, puis saisie uniquement dans le champ de credential prévu par OpenCode. La consommation est généralement facturée à l’usage.
Connexion par compte (OAuth) : une fenêtre de navigateur permet de lier un compte existant lorsque le provider et OpenCode proposent ce flux. Les modèles, limites et droits réellement disponibles dépendent de l’offre liée.

Si tu as un abonnement ChatGPT, choisis la connexion par compte lorsqu’elle est proposée et compatible avec ton offre. N’ajoute pas une clé API par défaut : une clé API est une facturation distincte de l’abonnement et peut engendrer une consommation au token.

Ne suppose jamais qu’un abonnement donne accès à tous les modèles ou à tous les modes dans OpenCode. Vérifie les modèles visibles après connexion, les limites applicables et le coût avant un usage intensif.

Garder le sélecteur de modèles propre

Dans les réglages, ouvre la section Providers, Models ou son équivalent. Garde uniquement les modèles réellement utiles à ton travail initial, par exemple :

une route courante pour les tâches vertes ;
une route validée pour les tâches sensibles, si ton besoin le justifie ;
éventuellement un modèle plus exigeant pour une tâche exceptionnelle.

Désactive les modèles inutilisés. Un catalogue trop large augmente le risque de choisir une mauvaise route, rend la vérification plus difficile et ralentit la décision.

Ne sélectionne pas le même modèle chez plusieurs providers sans comprendre la différence de facturation, de rétention et de confidentialité. Par exemple, une route proposée via un agrégateur peut être facturée à l’usage même si tu disposes d’un abonnement direct chez l’éditeur du modèle.

Niveau d’effort

Certains modèles exposent une option de réflexion ou de niveau d’effort. Un niveau plus élevé peut améliorer une tâche complexe, mais prend généralement plus de temps et peut coûter davantage. Utilise-le pour une analyse structurée, une décision difficile ou une modification technique complexe, pas pour une demande simple.

Si cette option n’apparaît pas, le modèle gère sa réflexion selon sa propre configuration. Ne cherche pas à la forcer par défaut.

Partie 3 : travailler avec le contexte

Demander une chose vérifiable

Une demande efficace précise :

l’objectif métier ;
les fichiers ou sources à utiliser ;
les contraintes, dont la confidentialité et les actions interdites ;
la sortie attendue ;
le niveau de validation requis avant une modification ou un envoi.

Exemple pour une première demande réelle après l’initialisation :

Lis [[Vision]] et le cycle stratégique actif.

Prépare un plan pour une note de décision sur l'ouverture d'un nouveau canal commercial.
Indique les informations manquantes, les hypothèses, les risques et les options.
Ne crée ni ne modifie aucun fichier, n'appelle aucun outil externe et n'envoie rien.
Attends ma validation avant toute exécution.

La qualité de la demande vient surtout du contexte donné et de la précision sur la décision attendue. Il est inutile de rédiger un long prompt générique si les notes de référence sont déjà présentes et bien pointées.

Pointer un fichier avec `@`

Dans la zone de demande, tape @, puis quelques lettres du nom du fichier. Sélectionne la note trouvée pour la référencer dans la conversation.

Utilise @ pour :

une note de projet concernée par la demande ;
une décision ou un compte rendu précis ;
une source à synthétiser ;
un fichier de configuration que l’IA doit seulement inspecter.

Avant de référencer une note, vérifie qu’elle ne contient pas un secret ou une donnée qui ne doit pas sortir par la route LLM active. Un fichier attaché ou référencé devient du contexte transmis au modèle selon la configuration de la session.

Attacher un fichier avec le trombone

Le trombone permet d’ajouter un fichier situé hors du workspace ou un document que tu veux examiner ponctuellement. Utilise-le lorsque le document ne doit pas encore être importé dans le Business Brain.

Après l’analyse, décide explicitement de son devenir : le classer via l’Inbox, l’importer avec le skill adapté, le conserver hors du vault ou le supprimer selon la politique de l’entreprise. Ne transforme pas chaque pièce jointe en contexte permanent.

Éditer une note depuis OpenCode

Le panneau Documents peut ouvrir des notes Markdown dans la même interface. Il est utile pour relire le résultat de l’IA et corriger une formulation simple. Obsidian reste l’outil de référence pour parcourir et maintenir le Business Brain.

Quand l’IA modifie une note, relis :

le chemin du fichier ;
le titre et les propriétés de la note ;
les liens vers les projets ou domaines ;
les décisions, chiffres et noms propres ;
l’absence de contenu ou de secret non souhaité.

Partie 4 : choisir le bon mode de travail

Plan mode : comprendre avant d’agir

Utilise le mode Plan pour une tâche qui modifie des fichiers, implique une décision, touche un outil connecté ou comporte un risque de périmètre. L’IA lit le contexte, formule les étapes, signale les hypothèses et attend ton feu vert avant l’exécution.

Le Plan mode est recommandé pour :

créer ou restructurer une note importante ;
importer un document dans le Business Brain ;
connecter un outil ou modifier une configuration ;
préparer une analyse qui influence une décision ;
faire intervenir des données sensibles ;
demander une action externe, même réversible.

Relis le plan et valide explicitement ce qui doit être fait. Si une étape est floue, demande une correction avant de passer au mode Build.

Build mode : exécuter ce qui a été validé

Utilise le mode Build après validation. L’IA peut alors créer, modifier ou organiser les fichiers dans les limites de ses permissions et de ta demande.

Build mode ne donne pas un blanc-seing. Conserve les validations pour les actions à impact externe : publication, envoi d’un email ou d’un message, modification en masse, suppression, dépense, connexion d’un outil ou transmission de données sensibles.

Après l’exécution, demande un bilan bref : fichiers créés ou modifiés, sources utilisées, actions non réalisées et points à vérifier. Ouvre ensuite le résultat dans Obsidian pour valider le contenu et son emplacement.

Séquence recommandée

Ouvre le workspace et vérifie le modèle actif.
Pointe avec @ les notes qui portent le contexte nécessaire.
Choisis le mode Plan.
Demande le plan, les hypothèses et les risques.
Valide ou corrige le plan.
Passe en mode Build pour l’exécution limitée au plan validé.
Vérifie le fichier produit dans OpenCode, puis dans Obsidian.
Termine avec /done pour conserver une trace de la session selon les règles du workspace.

Partie 5 : skills, MCP et recherches

Les skills structurent les tâches récurrentes

Un skill est une méthode de travail stockée dans le workspace. Il indique à l’IA comment exécuter une tâche récurrente, avec ses entrées, ses étapes, ses règles de sécurité et sa sortie attendue.

Utilise un skill existant plutôt que de réinventer une procédure, par exemple :

/inbox-processor pour trier une information entrante ;
/meeting-review pour traiter une réunion ;
/thinking-partner pour challenger une décision ;
/research-assistant pour une recherche sourcée ;
/done pour clôturer une session.

Tape / dans la zone de demande ou utilise Cmd+K pour retrouver une commande disponible. Si une tâche ne correspond à aucun skill, formule une demande normale et décide ensuite si la méthode mérite d’être formalisée.

Les MCP connectent des outils externes

Un MCP donne à l’IA un accès à un outil externe, par exemple un espace Notion, une base de données, une messagerie ou un moteur de recherche. C’est une permission supplémentaire et un nouveau flux de données.

Les intégrations sont désactivées par défaut. Connecte un outil seulement lorsqu’un besoin métier est identifié et validé. Utilise /connect-tool pour une connexion guidée, puis teste-la sur une donnée fictive ou non sensible.

/connect-tool

Indique ensuite l’outil que tu veux ajouter. L’IA doit t’expliquer le compte utilisé, les permissions demandées, les credentials nécessaires, les fichiers de configuration modifiés et la manière de retirer l’accès.

Ne pas charger des outils sans besoin

Chaque MCP actif peut alourdir le contexte et étendre les actions possibles de l’agent. Active le minimum nécessaire à la tâche, puis retire ou désactive l’accès quand il n’est plus utile.

Privilégie une CLI locale lorsqu’elle existe, que le cas d’usage est clair et que son installation a été validée. Une CLI est souvent plus déterministe et consomme moins de contexte qu’un MCP. Cette préférence ne remplace pas l’analyse des permissions et du flux de données.

Partie 6 : retrouver ce dont tu as besoin

`Cmd+K`, la recherche universelle

Utilise Cmd+K pour accéder rapidement à :

un fichier du workspace ;
une session précédente ;
une commande ou un skill ;
selon la version, une action de l’interface.

Cherche avec des mots précis. Par exemple, revue hebdo, cycle stratégique ou meeting review. Cette recherche ne remplace pas la structure PDRA : elle permet d’y revenir rapidement.

Reprendre une session ou en démarrer une autre

Reprends une session lorsque le même objectif, les mêmes sources et le même niveau de confidentialité restent valables. Démarre une nouvelle session lorsqu’un nouveau sujet exige un autre contexte, un autre modèle ou une nouvelle décision.

Une session courte et ciblée est plus facile à auditer. Avant de la quitter, vérifie les fichiers modifiés, prends la décision suivante et utilise /done lorsque le workspace le prévoit.

Démonstration

Le formateur part d’une demande fictive de direction :

« Prépare une note de décision sur un nouveau canal commercial. Utilise uniquement la note de test, indique les hypothèses et n’envoie rien à l’extérieur. »

La démonstration montre :

l’ouverture de Workspace et la vérification du modèle actif ;
l’ajout de la note de test avec @ ;
le passage en mode Plan ;
la lecture et la correction du plan ;
le passage en mode Build après validation explicite ;
la création de la note dans 0 Inbox/ ;
la vérification de la note dans OpenCode et dans Obsidian ;
la clôture avec /done.

Le résultat attendu est une session lisible : on sait quelle route a été utilisée, quels fichiers ont été lus, ce qui a été créé et ce qui reste à valider.

Exercice guidé

Ouvre Workspace dans OpenCode Desktop.
Vérifie le provider et le modèle actifs, sans afficher de credential.
Ouvre Cmd+K et retrouve une note fictive ou crée une note de test dans 0 Inbox/ si elle n’existe pas encore.
Référence cette note avec @.
Passe en mode Plan.
Utilise la demande ci-dessous.
Relis le plan et demande une correction s’il prévoit une action externe ou l’utilisation de fichiers non indiqués.
Valide le plan, passe en mode Build et laisse l’IA créer la note.
Vérifie le chemin et le contenu de la note dans OpenCode puis dans Obsidian.
Termine avec /done.

Nous travaillons uniquement avec des données fictives.

Utilise seulement la note que je viens de référencer. Propose d'abord un plan pour créer
dans 0 Inbox/ une note Markdown intitulée "Décision test - canal commercial".
La note doit contenir : le contexte, trois options, les hypothèses, les risques et la prochaine étape.

N'appelle aucun outil externe, ne lis aucun autre fichier et ne publie rien.
Attends ma validation explicite avant de créer ou modifier un fichier.

Output attendu

Tu disposes de :

un OpenCode Desktop ouvert au niveau de Workspace ;
une route de modèle identifiable avant chaque session ;
un sélecteur de modèles limité aux routes utiles ;
une méthode claire pour ajouter un fichier précis au contexte ;
une pratique Plan puis Build pour les modifications significatives ;
une note fictive créée au bon endroit et vérifiée dans Obsidian ;
une compréhension des différences entre un skill, un MCP et une demande normale ;
une session clôturée proprement.

Validation

Le cours est validé si tu peux, sans assistance :

expliquer la différence entre OpenCode Desktop, un provider et un modèle ;
identifier la route active avant une demande ;
ouvrir Workspace plutôt que le seul coffre Second Cerveau ;
référencer une note précise avec @ ;
demander et corriger un plan avant une modification ;
exécuter une action limitée en mode Build ;
retrouver le fichier créé dans Obsidian ;
expliquer pourquoi un MCP est une permission et un flux de données supplémentaires ;
retrouver un fichier, une session et une commande avec Cmd+K ;
clôturer une session avec /done.

La preuve à transmettre ou à montrer pendant le point de validation est une capture de la note fictive dans Obsidian, accompagnée du chemin du fichier, du modèle utilisé et du plan validé. Aucun secret, credential ou contenu réel de l’entreprise ne doit apparaître dans cette preuve.

Si ça bloque

Arrête toute transmission de donnée réelle et utilise cette demande de diagnostic :

Diagnostique uniquement mon utilisation d'OpenCode Desktop.
Ne modifie aucun fichier, ne connecte aucun outil, ne révèle aucun secret et n'envoie rien.

Vérifie séparément :
1. le dossier ouvert ;
2. les règles de workspace disponibles ;
3. le provider et le modèle actifs, sans credential ;
4. le mode de travail sélectionné ;
5. la disponibilité de la recherche Cmd+K et du référencement par @ ;
6. les MCP et permissions actifs ;
7. le chemin du fichier que je cherche.

Explique le diagnostic en français simple. Propose une seule correction à la fois et attends ma validation.

Symptômes fréquents

Je ne trouve pas un fichier avec @

Vérifie que le fichier est bien dans le workspace ouvert, que son nom est enregistré et que tu cherches quelques mots distinctifs. Si le fichier est hors workspace, attache-le ponctuellement avec le trombone ou ouvre le bon dossier de projet.

L’IA ne suit pas les règles du Business Brain

Vérifie que tu as ouvert Workspace, que AGENTS.md est présent à sa racine et que l’IA a lu les règles sans les modifier. Recommence dans une nouvelle session ciblée si le contexte précédent est devenu confus.

Je ne sais pas quel modèle est utilisé

Vérifie le sélecteur de modèles avant d’envoyer la demande. Utilise ensuite les statistiques de session si nécessaire. Ne continue pas avec une donnée sensible tant que la route n’est pas identifiée.

Un outil externe apparaît ou demande une autorisation

Lis la permission demandée et le compte concerné. Refuse ou annule si le besoin n’a pas été identifié. Un outil peut lire, modifier ou transmettre des données : demande un plan et teste-le avec une donnée non sensible avant tout usage réel.

La session devient lente ou incohérente

Vérifie la console et le niveau de contexte. Termine le travail en cours, utilise /done, puis ouvre une nouvelle session avec les seules notes nécessaires. Ne poursuis pas une longue conversation en ajoutant toujours plus de fichiers.

Ressources

Ce qu’il faut retenir

OpenCode Desktop est une interface et un harnais, pas le modèle et pas le Business Brain.
Le provider (où et sous quelles conditions) et le modèle (quelle capacité) sont deux décisions distinctes.
Plan avant Build : pour toute modification non triviale, demande d’abord le plan, valide-le, puis exécute.
@ référence un fichier précis, le trombone attache un document ponctuel ; les deux entrent dans le contexte transmis au modèle.
Un skill documente une méthode réutilisable, un MCP ajoute une permission et un flux de données vers un service externe.

À faire

Ouvre Workspace dans OpenCode Desktop et vérifie le provider et le modèle actifs.
Crée ou retrouve une note de test dans 0 Inbox/ et référence-la avec @.
Passe en mode Plan, demande le plan de l’exercice guidé et corrige-le si nécessaire.
Valide le plan, passe en mode Build et laisse l’IA créer la note.
Vérifie le fichier créé dans OpenCode puis dans Obsidian.
Clôture la session avec /done.