L'installation se fait en deux parties, dans cet ordre :

À la fin, tu seras prêt à lancer /initialisation dans la prochaine leçon.

Partie 1 : mettre en place ton coffre

Étape 1 : Télécharger le coffre de formation

On t'a préparé un coffre Obsidian prêt à l'emploi. Tout est déjà configuré :

• La structure IPCRA (Inbox, Projets, Casquettes, Ressources, Archives) : les dossiers où vont tes notes
• Les skills (/initialisation, /done, /weekly-review, /inbox-processor...) : des workflows IA prêts à lancer
• Les templates (daily note, weekly note, projet, casquette, phase de vie) : pour créer des notes structurées en un clic
• Le fichier AGENTS.md : les instructions qui disent à l'IA qui elle est, comment travailler avec ton coffre
• Le fichier opencode.json : la config qui indique à OpenCode où chercher tes skills

Tu n'as qu'à le télécharger, l'ouvrir dans Obsidian, et tu auras déjà 90 % du travail fait.

1. Télécharge le fichier ZIP ci-dessus
2. Décompresse-le
3. Le dossier obtenu s'appelle quelque chose comme templatesecondcerveau-main : renomme-le en Workspace (sans accent, sans espace, c'est plus propre pour le terminal et la sync)
4. Place-le où tu veux sur ton ordinateur. La recommandation : ~/Documents/Workspace/ (Mac/Linux) ou Documents\Workspace\ (Windows)

Important : ne renomme pas les dossiers à l'intérieur du Workspace. La structure est pensée pour fonctionner avec l'IA. Tu peux par contre librement renommer le dossier racine.

Étape 2 : Installer Obsidian

1. Va sur obsidian.md/download
2. Télécharge la version pour ton système (Mac, Windows ou Linux)
3. Installe et lance l'application

Obsidian, c'est quoi ? Un éditeur de notes en Markdown qui fonctionne 100 % en local sur ton ordinateur. Tes données restent chez toi. C'est ce qui permet à l'IA d'y accéder directement.

Tu ne connais pas Obsidian ? Va voir la leçon Naviguer dans Obsidian pour les bases (créer une note, naviguer, lier, organiser).

Étape 3 : Ouvrir ton coffre dans Obsidian

Une fois Obsidian lancé, ouvre ton coffre. Attention au choix du dossier : ce n'est pas le Workspace que tu ouvres, mais le sous-dossier Second Cerveau qui se trouve dedans.

1. Dans Obsidian, clique sur « Open folder as vault » (Ouvrir un dossier comme coffre)
2. Sélectionne le sous-dossier Second Cerveau à l'intérieur de ton Workspace
3. Clique sur Ouvrir

Pourquoi Second Cerveau et pas Workspace ?

Le Workspace est le dossier parent qui peut héberger plusieurs projets (ton coffre de notes, mais aussi plus tard d'autres repos, sites, apps). Le coffre Obsidian, lui, c'est uniquement le sous-dossier Second Cerveau. Tu veux que la sync ne porte que sur ce sous-dossier, pas sur tout le workspace.

Vérification rapide

Une fois ouvert, tu dois voir dans l'explorateur à gauche :

• 0 INBOX/
• 1 PROJETS/
• 2 CASQUETTES/
• 3 RESSOURCES/
• 4 TOOLS/
• 5 ARCHIVE/
• _Import/

Si tu vois tout ça, c'est bon. Ton coffre est ouvert.

Étape 4 : Synchroniser ton coffre

L'objectif : que tes notes soient accessibles partout (ordi, téléphone), sauvegardées dans le cloud (au cas où ton ordinateur plante), et chiffrées.

Notre recommandation : Obsidian Sync

C'est ce qu'on recommande officiellement pour le bootcamp. 4 € par mois, et tu obtiens :

• Chiffrement de bout en bout : seul toi peux lire tes notes, même Obsidian ne peut pas y accéder
• Application mobile : tes notes sont synchronisées sur Obsidian Mobile (iOS et Android)
• Historique des versions : tu peux remonter à n'importe quel état antérieur d'une note
• Synchronisation rapide et stable

Pour 4 € par mois, c'est imbattable.

Configurer Obsidian Sync

1. Dans Obsidian, ouvre les Réglages (icône engrenage en bas à gauche)
2. Va dans l'onglet « Compte » et crée un compte Obsidian (ou connecte-toi)
3. Souscris au plan Sync (4 €/mois) depuis ton compte
4. Reviens dans Obsidian, va dans Réglages → Sync et active le Core plugin Sync
5. Clique sur « Choisir un coffre distant » puis « Créer un nouveau coffre »
6. Donne-lui un nom (par exemple Second Cerveau)
7. Définis un mot de passe d'encryption : note-le précieusement dans un gestionnaire de mots de passe. Sans lui, il n'y a aucun moyen de déchiffrer tes notes. Personne ne peut le récupérer pour toi.
8. Lance la première synchronisation

Synchroniser sur ton téléphone

1. Télécharge Obsidian depuis l'App Store (iOS) ou le Play Store (Android)
2. Crée un nouveau coffre dans l'app mobile, sans contenu local
3. Active le plugin Sync, connecte-toi avec ton compte Obsidian, sélectionne le coffre distant que tu as créé
4. Entre ton mot de passe d'encryption
5. Lance la sync : toutes tes notes apparaissent sur ton téléphone

Tu as maintenant ton coffre sur ton ordi, sur ton téléphone, et sauvegardé dans le cloud.

Les alternatives à Obsidian Sync

Si tu ne veux pas payer ou si tu veux plus de flexibilité, deux options principales :

La recommandation officielle reste Obsidian Sync. C'est ce qui marche le mieux out of the box, surtout pour le mobile.

Partie 2 : installer ton IA

Maintenant que ton coffre vit dans Obsidian et qu'il est synchronisé, on passe à la couche IA.

Étape 5 : Installer OpenCode Desktop

OpenCode Desktop est l'application qui va te permettre de travailler avec l'IA dans ton coffre.

OpenCode Desktop : l'app native multi-modèle qu'on utilise dans le bootcamp.

1. Va sur opencode.ai/download
2. Télécharge la version pour ton système (macOS Apple Silicon, macOS Intel, ou Windows)
3. Installe et lance l'application

Pourquoi OpenCode Desktop ? C'est l'app native multi-modèle qu'on recommande dans ce bootcamp. Elle te permet de connecter plusieurs providers (ChatGPT, OpenRouter, etc.) et de choisir le bon modèle pour la bonne tâche. Tout le détail est dans Comprendre l'anatomie de ton système.

Tu veux utiliser Claude à la place ? Va voir le tutoriel Configurer Claude Code en complément.

Tu veux un workflow terminal ? Va voir Utiliser l'IA dans un terminal.

Étape 6 : Prendre un abonnement ChatGPT

Pour les tâches sans enjeu de privacy (présentations, sites web, brainstorming, contenu public), un abonnement ChatGPT est le plus rentable. Il s'intègre directement dans OpenCode Desktop, sans coût marginal à l'usage.

1. Va sur chatgpt.com et crée un compte (ou connecte-toi)
2. Souscris au plan ChatGPT Plus (20 €/mois)

Important : désactive l'entraînement sur tes données

Par défaut, OpenAI utilise tes conversations pour entraîner ses futurs modèles. Désactive-le.

1. Clique sur ta photo de profil en haut à droite, puis Settings
2. Va dans Data Controls
3. Désactive l'option « Improve the model for everyone » (ou « Améliorer le modèle pour tout le monde »)

Cela empêche OpenAI de stocker et réutiliser tes prompts pour l'entraînement.

Étape 7 : Configurer ton provider zéro rétention (ZDR)

Pour les tâches publiques (présentations, sites web, brainstorming, contenu destiné à sortir), un modèle puissant et peu cher comme ChatGPT (étape 6) suffit largement.

Mais dès que tu manipules des données qui te concernent personnellement ou des données clients, il te faut des modèles privés, qui ne stockent ni ne réutilisent tes requêtes (ZDR, pour Zero Data Retention). C'est un réflexe à mettre en place dès le début, avant que tes données sensibles ne soient déjà passées ailleurs.

Pour ça, on te recommande trois options. Tu peux en choisir une seule, ou les combiner selon ton usage :

Option 7A : OpenRouter (au token, pour DeepSeek et les tests)

OpenRouter, c'est le proxy qui te permet d'accéder à tous les modèles open source (DeepSeek, GLM, Qwen, Kimi, Mistral, etc.) avec une seule clé API et une seule facture. C'est ton défaut au token : parfait pour DeepSeek V4 Flash (ultra bon marché) et pour tester de nouveaux modèles à la demande. Bonus : tu peux y forcer le ZDR (Zero Data Retention) pour que tes requêtes ne soient ni stockées ni réutilisées.

Créer ton compte

1. Va sur openrouter.ai et crée un compte (ou connecte-toi avec Google/GitHub)

Activer le ZDR

C'est l'étape qui rend ton usage privé :

1. Dans OpenRouter, clique sur ta photo de profil en haut à droite puis Settings
2. Va dans Privacy (ou Data Controls)
3. Active l'option « Zero Data Retention » (ou équivalent)
4. OpenRouter ne routera désormais ta requête que vers des providers qui ont signé un engagement ZDR. Tes prompts ne sont ni stockés ni utilisés pour l'entraînement.

Mettre du crédit

1. Va dans Credits (ou Billing)
2. Ajoute 10 € de crédit pour commencer. Avec DeepSeek V4 Flash à environ 0,14 $/M tokens en input, ces 10 € tiennent des semaines.
3. Optionnel : active l'auto-top-up pour recharger automatiquement quand tu descends sous un seuil
4. Optionnel : configure des spending limits (limites de dépense par jour/mois) pour éviter les surprises

Générer ta clé API

1. Va dans Keys
2. Crée une nouvelle clé API, donne-lui un nom (par exemple OpenCode Desktop)
3. Copie la clé et garde-la précieusement dans ton gestionnaire de mots de passe : elle ne te sera plus jamais réaffichée

Option 7B : Synthetic AI (recommandé pour le privé)

Pour tout ce qui touche des données clients ou sensibles, on te recommande Synthetic AI : un abonnement privé qui te donne GLM 5.2 en ZDR (zéro rétention), à prix fixe, sans compter les tokens.

Créer ton compte et t'abonner

1. Va sur synthetic.new et crée un compte
2. Souscris à l'abonnement (30 $/mois) : tu obtiens des tokens ZDR sur GLM 5.2, servis rapidement, pour à peu près le prix d'un abonnement ChatGPT
3. Récupère ta clé API Synthetic dans les paramètres de ton compte et garde-la dans ton gestionnaire de mots de passe
4. Tu la connecteras dans OpenCode à l'étape 9, puis tu sélectionneras GLM 5.2 comme modèle privé

Option 7C : Aller plus loin sur les providers

OpenRouter et Synthetic couvrent déjà l'essentiel. Si tu veux comparer d'autres providers ou avoir un plan B (acteur européen, plan illimité pour usage agent intensif), va voir la leçon Choisir son modèle IA qui détaille les providers que je recommande.

Étape 8 : Ouvrir ton Workspace dans OpenCode Desktop

Maintenant on connecte tout dans OpenCode.

1. Lance OpenCode Desktop
2. Clique sur « Open workspace » (ou « Add workspace » selon ta version)
3. Sélectionne le dossier Workspace (le parent, pas Second Cerveau). C'est important : OpenCode doit voir tout le workspace pour pouvoir agir aussi sur les autres projets que tu y ajouteras plus tard.
4. OpenCode lit automatiquement le fichier AGENTS.md à la racine et charge le contexte

Étape 9 : Connecter tes providers

Dans OpenCode Desktop, tu vas maintenant connecter ChatGPT et OpenRouter.

1. Ouvre les Settings d'OpenCode (icône engrenage ou raccourci selon ta version)
2. Va dans la section Providers (ou Models)
3. Connecte ChatGPT :
   • Clique sur Add provider puis sélectionne OpenAI (ou ChatGPT)
   • Connecte-toi avec ton compte ChatGPT Plus. Tu n'as pas besoin de clé API si ton abonnement est lié.
4. Connecte OpenRouter :
   • Clique sur Add provider puis sélectionne OpenRouter
   • Colle la clé API que tu as générée à l'option 7A
5. Connecte Synthetic AI :
   • Clique sur Add provider puis sélectionne Synthetic (ou un provider custom OpenAI-compatible si Synthetic n'est pas listé)
   • Colle la clé API générée à l'option 7B, puis coche GLM 5.2 : c'est ton modèle privé
6. Vérifie que tu peux sélectionner des modèles dans le sélecteur (tu devrais voir DeepSeek V4 Flash, GLM 5.2, GPT 5.6, etc.)

Tu es prêt.

Si tu rencontres un problème

Obsidian ne voit pas mes dossiers IPCRA Tu as probablement ouvert le mauvais dossier. Tu dois ouvrir Second Cerveau (le sous-dossier), pas Workspace (le parent). Refais l'étape 3.

Obsidian Sync ne synchronise pas

• Vérifie que ton abonnement Sync est bien actif dans ton compte Obsidian
• Vérifie que le plugin Sync est activé (Réglages → Plugins core → Sync)
• Vérifie que tu utilises le bon coffre distant et le bon mot de passe d'encryption

J'ai perdu le mot de passe d'encryption Obsidian Sync Personne ne peut le récupérer pour toi. C'est le prix du chiffrement de bout en bout. Si tu l'as perdu, la seule solution est de supprimer le coffre distant et d'en créer un nouveau (tu réuploades alors ton coffre local).

OpenCode Desktop ne trouve pas les skills Vérifie que tu as bien ouvert Workspace (et pas Second Cerveau) dans OpenCode. Le fichier opencode.json à la racine indique où chercher les skills (./Second Cerveau/4 TOOLS/skills). Si tu ouvres directement Second Cerveau, OpenCode ne trouve pas le opencode.json.

Le compte ChatGPT ne se connecte pas dans OpenCode En dernier recours seulement, tu peux créer une clé API sur platform.openai.com/api-keys et la coller dans OpenCode. Attention : la clé API facture au token, ce qui chiffre vite. Privilégie toujours le login ChatGPT : ton abonnement est déjà payé, aucun coût marginal.

ZDR pas trouvable dans OpenRouter L'option peut être dans Settings → Privacy, Settings → Data Controls, ou Account → Preferences selon la version. Cherche « Zero Data Retention » dans les réglages.

Checklist

• Coffre de formation téléchargé et renommé en `Workspace`
• Obsidian installé
• Le sous-dossier `Second Cerveau` ouvert dans Obsidian (structure IPCRA visible)
• Obsidian Sync activé avec mot de passe d'encryption sauvegardé (ou alternative configurée)
• Obsidian Mobile installé et synchronisé sur le téléphone
• OpenCode Desktop installé
• Abonnement ChatGPT Plus actif, entraînement désactivé dans les paramètres
• Compte OpenRouter créé, ZDR activé, 10 € de crédit, clé API générée et sauvegardée
• Abonnement Synthetic AI pris (30 $/mois), clé API récupérée, GLM 5.2 prêt à connecter
• Workspace ouvert dans OpenCode Desktop
• Providers ChatGPT, OpenRouter et Synthetic AI connectés dans OpenCode

Output attendu : ton coffre vit dans Obsidian et est synchronisé. OpenCode Desktop est ouvert sur ton workspace avec ChatGPT, OpenRouter et Synthetic AI connectés. Tu es prêt à lancer /initialisation dans la prochaine leçon.

La suite

La prochaine étape : lancer /initialisation dans OpenCode Desktop. C'est une conversation guidée de 3 à 4 heures qui remplit ton contexte personnel (qui tu es, ta vision, tes casquettes, tes projets, ta phase de vie).

Va à la leçon suivante : Initialiser son vault avec /initialisation.

Comment utiliser OpenCode Desktop

Dans cette leçon, je t'explique comment configurer OpenCode Desktop pour qu'il soit parfaitement opérationnel, puis comment l'utiliser au quotidien.

OpenCode, c'est un harnais agentique open-source : tu y ouvres un LLM (un modèle qui prédit le token suivant) et le harnais ajoute autour tout ce qui transforme un simple chatbot en agent (coder, appeler des outils, déléguer à des sous-agents, se planifier, s'auto-évaluer, respecter des permissions). C'est pour ça qu'on l'utilise plutôt qu'un chatbot question-réponse : la boucle agentique fait le travail, pas juste la réponse. C'est aussi un outil ouvert : tu y branches n'importe quel modèle (ChatGPT, Claude, DeepSeek, GLM, Qwen...) sans dépendre d'un seul fournisseur, et l'interface desktop reste très simple à prendre en main.

Étape 1 : Configurer tes fournisseurs et tes modèles

C'est la première chose à faire en arrivant. Clique sur la roue crantée en bas à gauche, puis va dans la section Fournisseurs et Modèles.

Fournisseur vs modèle, c'est quoi la différence ?

Pour résumer : tu choisis ton fournisseur en fonction de ses propriétés (prix, confidentialité, vitesse), puis tu actives chez ce fournisseur les modèles que tu veux utiliser. Par exemple, Fireworks est un fournisseur qui propose uniquement des modèles open source très optimisés pour tourner vite.

Les deux modes de connexion

Tutoriel : connecter OpenAI via abonnement ChatGPT

Quand tu cliques pour ajouter OpenAI, OpenCode Desktop te demande :

1. Veux-tu mettre une clé API ? (paiement à la consommation, donc plus cher si tu utilises beaucoup) ou
2. Veux-tu te connecter avec un abonnement existant ? (recommandé si tu as déjà ChatGPT Plus ou Pro)

Choisis l'option 2. Une page s'ouvre dans ton navigateur, tu te connectes, tu cliques sur Continue, et c'est plié. OpenAI est connecté, et tu peux maintenant sélectionner les modèles que tu veux activer.

La barre du bas et le sélecteur de modèles

Une fois tes fournisseurs configurés, tu retrouves tout en bas de ton écran :

• Le sélecteur de modèles : tous les modèles activés sont listés là.
• Le bouton Plus : te redirige vers la fenêtre "Connecter un fournisseur".
• Le bouton Paramètres : ouvre l'écran de configuration par fournisseur, où tu coches/décoches quels modèles sont visibles dans le sélecteur.

Astuce : décoche les modèles que tu n'utilises jamais, sinon ta barre devient un fouillis. Par exemple, sur OpenRouter, il y a des centaines de modèles disponibles. Garde-en 5 à 10 pertinents et désactive le reste pour avoir une interface propre.

Étape 2 : Connecter tes outils (MCP)

Sous le capot, OpenCode Desktop fait tourner OpenCode. Donc connecter des outils à OpenCode Desktop, c'est en réalité connecter des outils à OpenCode. La bonne nouvelle : tu as déjà tout ce qu'il faut dans ton coffre du bootcamp.

La méthode recommandée : /connect-mcp

Dans OpenCode Desktop, tape simplement :

/connect-mcp

Puis le nom de l'outil que tu veux ajouter (par exemple notion, firecrawl, playwright, microsoft 365). L'IA te guide étape par étape : elle identifie le bon package, récupère les variables d'environnement nécessaires, patche ta configuration sans rien casser de ce qui existe déjà.

Par défaut, le MCP est ajouté à la configuration OpenCode globale de ton ordinateur. Cela veut dire que tous tes workspaces ont accès à l'outil. Si tu changes de workspace (par exemple, du workspace démo à ton workspace principal), tu retrouves les mêmes MCP disponibles.

Les trois sections de Paramètres

Étape 3 : Comprendre l'interface

La barre latérale (icône crayon)

Quand tu cliques sur le crayon en haut à droite, une barre latérale s'ouvre. Elle te donne plusieurs vues utiles :

L'éditeur de notes intégré

Toujours dans la barre latérale, tu peux ouvrir le panneau Documents et éditer une note directement. C'est un éditeur Markdown léger, parfait pour travailler sur le même fichier que l'IA dans la même interface.

• Tu peux ouvrir plusieurs notes en même temps et les empiler sur la droite de ton écran.
• Syntaxe Markdown : barre en haut pour les commandes courantes, ou directement avec les caractères (### pour un titre de niveau 3, **texte** pour gras, etc.).

Étape 4 : Ouvrir l'IA dans le bon dossier

C'est le principe le plus important. L'IA voit ce qui est dans le dossier où tu l'ouvres. Rien d'autre.

Attacher un fichier ou pointer avec @

Tu peux enrichir ton contexte de deux manières en plein milieu d'une conversation :

• Attacher un fichier : clique sur l'icône trombone, sélectionne un fichier sur ton ordinateur.
• Arobase (@) : tape @ puis le début du nom du fichier (par exemple @weekly ou @embracing), et tu obtiens une recherche rapide dans ton coffre. Tu sélectionnes la note et elle est référencée. Excellent réflexe pour pointer vers une note précise sans avoir à la copier-coller.

Étape 5 : Niveau d'effort et modes (build / plan)

Niveau d'effort

Selon le modèle, tu as parfois une option niveau d'effort (thinking on/off). Plus le niveau est élevé, plus le modèle va prendre le temps de réfléchir avant de répondre. Certains modèles te le proposent, d'autres sont en non-thinking par défaut (réponse directe, pas de phase de réflexion).

Build mode vs Plan mode

Tu as deux modes principaux dans le sélecteur en bas de la barre de prompt :

Tu peux aussi ajouter des modes custom selon tes usages. Tout cela est détaillé dans la prochaine leçon "Bien utiliser l'IA".

Étape 6 : Recherche rapide avec Cmd+K

Le raccourci magique : Cmd+K ouvre une barre de recherche universelle. Tu peux chercher :

• Des fichiers : par exemple meeting review skill pour ouvrir la note correspondante.
• Des sessions : revenir à une conversation précédente.
• Des commandes : lancer une commande (skill) sans avoir à la taper.

C'est l'équivalent du Spotlight du Mac, mais pour ton workspace. À utiliser tout le temps.

Si tu rencontres un problème

Si tu rencontres un bug ou un comportement étrange dans OpenCode Desktop :

1. Reporter sur GitHub : ouvre une issue sur le repo public d'OpenCode.
2. Nous écrire un email à contact@perspectives.ac avec une description et idéalement un screenshot.

On corrige vite, et chaque retour participant améliore l'app pour tout le monde.

• Au moins 1 fournisseur configuré (clé API ou OAuth)
• Modèles que j'utilise vraiment cochés dans le sélecteur (les autres décochés)
• Au moins 1 MCP connecté via /connect-mcp (Firecrawl ou autre)
• Je sais ouvrir la barre latérale (crayon) pour voir mes statistiques de contexte
• Je sais utiliser @ pour pointer un fichier de mon coffre dans le prompt
• Je connais Cmd+K pour la recherche rapide
• Je sais différencier Plan mode (réfléchir) et Build mode (exécuter)

Apprendre à naviguer dans Obsidian

Avant de configurer ton vault, prends 15 minutes pour te familiariser avec Obsidian. Cette vidéo te montre les bases : créer un fichier, naviguer entre les notes, organiser tes dossiers, et les raccourcis essentiels.

L'essentiel à retenir

• Créer une note : Ctrl/Cmd + N
• Chercher une note : Ctrl/Cmd + O
• Lien entre notes : tape [[ puis le nom de la note
• Déplacer un fichier : drag & drop dans l'explorateur de fichiers à gauche
• Vue graphe : Ctrl/Cmd + G pour voir les connexions entre tes notes

Tu n'as pas besoin de tout maîtriser maintenant. L'important c'est de savoir créer, chercher et lier des notes. Le reste viendra en pratiquant.

Pour aller plus loin : les bases d'Obsidian en profondeur

Ces vidéos viennent de mes formations Atomic Knowledge et Atomic Notes. Pas obligatoires, mais elles te font gagner du temps si tu veux maîtriser vraiment l'outil avant d'attaquer le reste de la semaine 1.

Checklist

• J'ai regardé la vidéo d'introduction à Obsidian
• Je sais créer une note (Ctrl/Cmd + N)
• Je sais chercher une note (Ctrl/Cmd + O)
• Je sais créer un lien entre notes avec [[ ]]

Choisir son modèle IA

La recommandation officielle du bootcamp (OpenCode Desktop + ChatGPT + Synthetic AI pour GLM 5.2 + DeepSeek V4 Flash sur OpenRouter) est détaillée dans Comprendre l'anatomie de ton système. Cette leçon va plus loin : comment comparer les modèles, lesquels tester, et comment trancher.

D'abord, regarder où on en est

Le paysage des modèles bouge tous les mois. Avant de te fixer sur un choix, va voir où on en est réellement sur Artificial Analysis. C'est le benchmark indépendant le plus utile : il compare intelligence, vitesse, prix sur tous les modèles principaux.

Source : artificialanalysis.ai. À consulter régulièrement.

Le constat que tu fais en regardant : les modèles dits « high-end » se valent à peu près sur les tâches du quotidien. À 10 points près sur l'index d'intelligence, ils font globalement le même travail. La vraie différence se joue ailleurs : prix, vitesse, confidentialité, accès via abonnement ou API.

La meilleure façon de choisir : tester

Aucun benchmark ne remplace l'expérience. Tu vas trouver ton modèle préféré en testant plusieurs sur tes propres tâches.

La méthode simple :

1. Crée un compte OpenRouter (déjà fait à l'étape précédente si tu as suivi l'installation)
2. Active le ZDR dans les paramètres : OpenRouter ne route alors que vers des providers qui ne stockent pas tes prompts
3. Mets quelques euros de crédit (10 € suffisent pour des semaines de test)
4. Dans OpenCode Desktop, sélectionne le modèle, lance des requêtes sur tes vraies tâches du quotidien
5. Compare : qualité de la réponse, vitesse, ressenti général

OpenRouter te donne accès à tous les modèles open source avec une seule clé API et une seule facture. Tu peux basculer de DeepSeek à GLM à Qwen en une seconde.

Les modèles à essayer (mi-2026)

Voici la liste courte des modèles qui valent le détour aujourd'hui. Le paysage évolue vite, mais c'est ce qui est solide à l'été 2026.

Mes tops, à mettre dans ta stack quotidienne :

Aussi solides, à essayer pour varier ou se faire un deuxième avis :

Un mot sur les providers

Un modèle est un cerveau. Mais ce cerveau tourne sur des serveurs, et c'est ce qu'on appelle un provider. Le même modèle (DeepSeek V4 Flash par exemple) peut être hébergé par plusieurs providers différents : Fireworks, DeepInfra, Parasail, Novita, Together AI, etc. Chacun a sa politique de prix, sa vitesse, sa politique de confidentialité.

Ça peut vite devenir complexe. La bonne nouvelle : tu n'as pas à choisir un provider à la main.

La solution : OpenRouter. OpenRouter est un proxy qui route automatiquement ta requête vers le bon provider en fonction de la disponibilité du moment. Tu paies OpenRouter, OpenRouter paie le provider. Une seule facture. Un seul ZDR à activer. Et si un provider est down, OpenRouter bascule vers un autre sans que tu t'en aperçoives.

Pour les modèles closed source (Claude, GPT), il n'y a pas de provider tiers : Anthropic et OpenAI hébergent eux-mêmes. Pour eux, tu prends l'abonnement direct (ChatGPT Plus 20 €/mois, ou Claude Pro/Max via Claude Code).

Si OpenRouter ne te suffit pas

OpenRouter couvre 95 % des cas. Mais parfois tu veux un setup plus pointu : aller chez le provider directement pour bénéficier d'un plan illimité, d'un ZDR contractuel renforcé, d'une infra européenne, ou de la vitesse maximale possible. Voici les providers que je recommande, par ordre de préférence.

Le moins cher + ZDR

DeepInfra

Le provider le moins cher du marché sur la plupart des modèles open source (à partir de 0,02 $/M tokens). ZDR de série, SOC 2 et ISO 27001. 190+ modèles open source. C'est aussi un des providers vers lesquels OpenRouter route par défaut en mode Privacy. Bonne option si tu veux passer en direct pour réduire la facture ou simplifier ton stack.

deepinfra.com

100 % européen

Infomaniak AI Tools

Provider suisse, datacenters en Suisse, alimentés en énergie renouvelable. GDPR + nLPD-natif, OpenAI-compatible, modèles open source disponibles (Llama 3, Mistral 3, Qwen 3, Gemma 3n, modèles de transcription et d'image). Facturation à l'usage, et 1 million de crédits offerts pour tester un mois sans engagement. Le meilleur choix si tu veux un acteur français/suisse de confiance pour des données vraiment sensibles (clients EU, santé, juridique).

Setup éclair dans OpenCode

1. Crée un compte sur infomaniak.com et active AI Tools (1 M de tokens offerts)
2. Dans ton manager Infomaniak, copie ton product ID et génère un API token
3. Dans opencode.json, ajoute un provider custom de type OpenAI compatible avec baseURL = https://api.infomaniak.com/2/ai/{product_id}/openai/v1 et ton token en header
4. Sélectionne le modèle Mistral 3 ou Qwen 3 dans le sélecteur d'OpenCode et tape ta première requête

infomaniak.com/hosting/ai-services

Alternative intéressante pour usage agent intensif

Fireworks AI (FirePass)

Fireworks est l'un des providers les plus rapides du marché. Leur botte secrète : FirePass, un abonnement à 49 $/mois qui donne accès à Kimi 2.6 Turbo en illimité, sans coût par token. Conçu pour les harnesses agentic (OpenCode, Claude Code, Cline). Si tu itères beaucoup avec une IA en mode agent, le ratio est imbattable.

fireworks.ai · docs.fireworks.ai/firepass

Tu n'as pas besoin de t'inscrire chez tous. Synthetic AI pour le meilleur rapport qualité/prix du moment et ton usage privé (abonnement ZDR sur GLM 5.2, 30 $/mois, autour du prix de ChatGPT). DeepInfra pour le tarif le plus bas à la consommation. Infomaniak si tu as une contrainte juridique européenne et que tu veux un acteur suisse de confiance. Fireworks FirePass en alternative si tu utilises l'IA tous les jours en mode agent (illimité à 49 $/mois).

La confidentialité en 3 dimensions

Si tu manipules des données sensibles (clients, projets perso, journaling), trois questions importent :

Le label ZDR (Zero Data Retention) répond non aux deux premières questions et limite la troisième. Le provider s'engage contractuellement à ne rien stocker, ne rien réutiliser pour l'entraînement, et à supprimer les logs immédiatement.

Le vrai ZDR passe par une offre API/dev, pas par un abonnement grand public

C'est le point que beaucoup ratent, et il faut bien distinguer deux types d'abonnements :

• Abonnement grand public (ChatGPT Plus, Claude Pro) : conçu pour le chat, pas de ZDR. Tes conversations sont retenues pour la modération.
• Offre API/dev avec ZDR contractuel : soit au token via une API ZDR-compliante (OpenRouter en mode Privacy), soit en abonnement dev comme Synthetic AI (30 $/mois, qui sert du GLM 5.2 en ZDR réel). Là, le ZDR est bien contractuel.

Autrement dit, ce n'est pas « abonnement = pas de ZDR ». C'est : abonnement grand public = pas de ZDR, mais offre dev ZDR (Synthetic AI, ou API au token) = ZDR réel.

Ce que ça veut dire concrètement :

• Synthetic AI (abonnement dev) : GLM 5.2 en ZDR contractuel réel pour 30 $/mois. Le moyen le plus simple d'avoir du ZDR sur ton usage privé, sans compter les tokens. C'est l'option qu'on met en avant.
• OpenRouter Privacy mode : Settings, Privacy, activer ZDR. Un ZDR réel au token, parfait pour DeepSeek et les tests.
• ChatGPT Plus / Claude Pro : tu peux désactiver l'entraînement (« Improve the model for everyone » côté OpenAI, « Help improve Claude » côté Anthropic), mais ça ne supprime pas la rétention 30 jours pour modération. Évite d'y mettre des données vraiment sensibles (RGPD client, médical, juridique).
• Claude via Claude Code : politique plus stricte que Claude.ai (rétention 30 jours côté API, pas d'entraînement par défaut), mais ce n'est toujours pas du ZDR formel.

Règle simple : si la donnée est sensible, route-la via Synthetic AI (GLM 5.2) ou OpenRouter ZDR (DeepSeek, GLM 5.2), pas via ChatGPT.com ou Claude.ai.

Pour une plongée approfondie, va voir Zoom sur la sécurité.

Recommandation pour démarrer

Si tu hésites encore, voici la stack que je te conseille pour les premières semaines :

1. ChatGPT Plus (GPT 5.6, abonnement 20 €/mois) : pour les tâches créatives ou non sensibles (présentations, sites web, brainstorming). Non privé.
2. Synthetic AI (GLM 5.2, abonnement 30 $/mois, ZDR) : ton modèle privé quand la tâche est complexe ou touche des données sensibles (clients, raisonnement long).
3. DeepSeek V4 Flash (OpenRouter au token, ZDR) : ton défaut ultra bon marché, pour 80 % de tes tâches courantes.
4. Fable / Claude Opus 4.8 (via Claude Code, en option) : si tu as un abonnement Claude Pro/Max et que tu veux le meilleur sur certaines tâches.

Bascule entre les 4 selon le contexte. C'est ce qui fait la puissance du multi-modèle.

Quand changer ?

Le paysage évolue tous les mois. Une règle simple : dès qu'une réponse te déçoit, essaye un autre modèle sur la même tâche. Ça te dit beaucoup sur les forces et faiblesses de chacun. Et ça te garde à jour.

Pour les détails de connexion (clé API OpenRouter, abonnement ChatGPT dans OpenCode), retourne à Installation technique.

• Je suis allé voir où on en est sur artificialanalysis.ai
• Je comprends que tester soi-même reste la meilleure méthode
• J'ai testé au moins 2 modèles sur mes vraies tâches via OpenRouter
• Je connais ma stack par défaut : ChatGPT (GPT 5.6) + Synthetic AI (GLM 5.2, privé) + DeepSeek V4 Flash (+ Fable / Claude Opus 4.8 en option)
• Je sais que ZDR est activé sur OpenRouter dans mes réglages

Se repérer dans le monde de l'IA

L'IA a son propre vocabulaire. Cette page est un glossaire de référence : reviens-y chaque fois que tu rencontres un terme que tu ne connais pas.

Les fondamentaux

Modèle (LLM)

Un Large Language Model est un programme entraîné sur des milliards de textes pour comprendre et générer du langage. C'est le "cerveau" : l'intelligence elle-même. Exemples dans la stack du bootcamp : DeepSeek V4 Flash (open source, modèle par défaut), GLM 5.2 (Zhipu AI, pour les tâches complexes), Kimi 2.6 (Moonshot AI), Qwen (Alibaba, multilingue), GPT 5.6 (OpenAI, via ChatGPT Plus).

Un modèle ne fait rien tout seul. Il a besoin d'une interface pour recevoir tes messages et d'un provider pour faire tourner le calcul.

Provider

Le provider est l'entreprise qui fait tourner le modèle sur ses serveurs. C'est l'intermédiaire entre toi et le modèle. Exemples : OpenRouter (agrégateur recommandé dans le bootcamp), Anthropic, OpenAI, Alibaba.

Un même modèle peut être accessible via plusieurs providers. Qwen peut tourner chez OpenRouter, chez Alibaba, ou sur ta propre machine. Le prix, la vitesse et la confidentialité changent selon le provider.

Interface

L'interface est ce que tu utilises pour parler au modèle. Exemples : OpenCode Desktop (l'interface principale du bootcamp), Claude.ai (web), ChatGPT (web/app).

Une interface peut se connecter à différents providers et modèles. OpenCode Desktop peut utiliser DeepSeek, GPT, Qwen — il suffit de connecter le bon provider.

Token

Un token est l'unité de mesure du texte pour un modèle IA. Un token représente environ 3/4 d'un mot en anglais, un peu moins en français.

Quand on parle de "200K tokens de contexte", ça veut dire que le modèle peut traiter environ 150 000 mots d'un coup : l'équivalent d'un livre de 500 pages.

Les tokens servent aussi à la facturation : les providers facturent au nombre de tokens traités (entrée + sortie).

Fenêtre de contexte (Context Window)

La fenêtre de contexte est la quantité maximale de texte que le modèle peut "voir" en même temps. C'est sa mémoire de travail.

• La plupart des modèles : 128K-200K tokens
• Gemini : jusqu'à 1M tokens

Si tu dépasses la fenêtre de contexte, le modèle "oublie" le début de la conversation. C'est pour ça que les agents comme OpenCode gèrent le contexte intelligemment : ils envoient uniquement ce qui est pertinent.

Prompt

Un prompt est simplement le texte que tu envoies au modèle. Ça peut être une question, une instruction, un document à analyser. Un bon prompt est précis, contextuel et structuré. La qualité de la réponse dépend directement de la qualité du prompt.

Terminal

Le terminal est l'application qui permet de taper des commandes texte pour contrôler ton ordinateur. C'est la fenêtre noire (ou colorée) où tu tapes des instructions au lieu de cliquer avec la souris.

Exemples de terminaux : Ghostty, iTerm2, ou le Terminal par défaut de ton Mac/PC. OpenCode Desktop a son propre terminal intégré, donc la plupart des participants n'ont pas besoin d'en installer un.

CLI (Command Line Interface)

Une CLI (interface en ligne de commande) est un programme qu'on utilise en tapant des commandes dans le terminal. OpenCode peut s'utiliser en mode CLI, en plus de l'interface Desktop. GOG (pour Google Workspace) est une CLI.

Les concepts agentiques

Agent

Un agent est un modèle IA qui peut exécuter des actions, pas seulement répondre à des questions. Il peut lire des fichiers, écrire du code, naviguer sur le web, appeler des APIs, et enchaîner ces actions en autonomie pour accomplir une tâche complexe.

OpenCode Desktop transforme un modèle en agent : il lui donne accès à ton système de fichiers, à tes outils, à tes commandes.

Tool Calling (appel d'outils)

Le tool calling est la capacité d'un modèle à utiliser des outils externes. Au lieu de juste générer du texte, le modèle peut décider d'appeler un outil (lire un fichier, faire une recherche web, interroger une base de données) et utiliser le résultat pour continuer son raisonnement.

C'est ce qui fait la différence entre un chatbot et un agent.

MCP (Model Context Protocol)

Le MCP est un standard ouvert créé par Anthropic pour connecter des outils à un modèle IA. C'est comme un port USB universel pour l'IA.

Un serveur MCP expose des capacités (lire une base de données, scraper une page web, générer une image) et n'importe quelle interface compatible (OpenCode Desktop, Claude Desktop) peut les utiliser.

Exemples de MCP qu'on utilise dans le bootcamp : Firecrawl (web), n8n (automatisations), NocoDB (bases de données), QMD (recherche dans le coffre).

Skill (commande slash)

Un skill (ou commande slash) est un fichier Markdown qui contient des instructions pour l'IA. Quand tu tapes /newsletter dans OpenCode, il lit le fichier Second Cerveau/4 TOOLS/skills/newsletter.md et exécute les instructions qu'il contient.

C'est le mécanisme qu'on utilise pour créer des agents personnalisés. Le fichier contient le contexte, la méthode, les étapes : tout ce que l'IA a besoin de savoir pour exécuter le process.

À ne pas confondre avec les commandes systèmes d'OpenCode (comme /model ou /sync) qui sont des fonctions intégrées à l'interface.

Fork

Un fork est une copie d'un projet open-source qu'on modifie pour ses propres besoins. OpenCode est un fork de Claude Code : il est parti du code de Claude Code et a évolué indépendamment.

Infrastructure et technique

API (Application Programming Interface)

Une API est une interface qui permet à des programmes de communiquer entre eux. Quand OpenCode envoie ta question à DeepSeek via OpenRouter, il utilise l'API d'OpenRouter.

L'API est l'alternative aux interfaces web (chatgpt.com, claude.ai). Elle est plus flexible, plus puissante, et permet l'automatisation — mais elle nécessite une clé API et se facture à l'usage.

Clé API (API Key)

Une clé API est un mot de passe unique qui t'identifie auprès d'un provider. Quand tu connectes OpenRouter dans OpenCode, tu fournis ta clé API OpenRouter.

Règle absolue : ne commite jamais une clé API dans un repo Git, et ne la partage jamais. Si quelqu'un l'obtient, il peut utiliser ton compte et tu seras facturé. Stocke tes clés dans Bitwarden.

ZDR (Zero Data Retention)

Le ZDR signifie que le provider ne conserve aucune donnée après traitement. Ta requête arrive, la réponse est générée, tout est supprimé immédiatement. Rien n'est stocké, rien n'est loggé.

OpenRouter propose le ZDR activable en quelques clics. C'est la configuration recommandée dans le bootcamp. Voir la leçon Zoom sur la sécurité pour le détail.

opencode.json

Le fichier opencode.json est le fichier de configuration d'OpenCode, placé à la racine de ton Workspace. Il définit les providers connectés, les MCPs actifs, les permissions (ce que l'IA peut ou ne peut pas faire), et les options d'affichage. C'est l'équivalent d'un fichier de configuration de projet.

AGENTS.md

Le fichier AGENTS.md (ou claude.md dans certains contextes) est un fichier d'instructions permanent que l'IA lit à chaque session. Il contient ton identité, tes préférences, le contexte de ton projet, et les règles que tu veux qu'elle respecte. C'est la mémoire de travail persistante entre les sessions.

Dans le bootcamp, ce rôle est rempli par ton fichier Moi.md et les contextes dans ton coffre.

GitHub / GitLab

GitHub et GitLab sont des plateformes de stockage et de versioning de fichiers. Elles gardent un historique complet de toutes les modifications : tu peux revenir en arrière à tout moment.

GitHub appartient à Microsoft (serveurs aux USA). GitLab peut être auto-hébergé en Europe.

Repository (Repo)

Un repository (ou "repo") est un projet sur GitHub/GitLab. C'est un dossier versionné : chaque modification est enregistrée avec un horodatage et un message.

Inférence

L'inférence est le moment où le modèle génère une réponse. "Faire de l'inférence" = faire tourner le modèle pour produire du texte. Les providers d'inférence (OpenRouter, DeepInfra) sont des entreprises qui font tourner des modèles sur leurs serveurs sans les entraîner.

n8n

n8n est un outil d'automatisation open-source (comme Zapier ou Make, mais auto-hébergé). Il permet de créer des workflows visuels qui connectent des services entre eux. On l'installe sur ton propre serveur en semaine 3 du bootcamp.

Ollama

Ollama est un outil pour faire tourner des modèles IA en local sur ta machine. Au lieu d'envoyer tes données à un serveur distant, le modèle tourne directement sur ton ordinateur. Avantage : confidentialité totale. Inconvénient : nécessite du matériel puissant pour des performances correctes.

SSH (Secure Shell)

SSH est un protocole sécurisé pour se connecter à un serveur distant depuis ton terminal. C'est comme une télécommande chiffrée pour ton serveur. On l'utilise en semaine 3 pour accéder au serveur IA.

Webhook

Un webhook est une URL qu'un service appelle automatiquement quand un événement se produit. Exemple : "Quand quelqu'un paie sur mon site, appeler cette URL, puis créer son compte". Les webhooks sont le mécanisme de base des automatisations n8n.

Open-source vs propriétaire

Un modèle open-source (Qwen, DeepSeek, Llama) a son code et ses poids publiés : n'importe qui peut le télécharger, le modifier, le faire tourner. Un modèle propriétaire (GPT 5.6, Claude) est accessible uniquement via l'API du créateur.

L'open-source permet le self-hosting et offre plus de contrôle sur la confidentialité. DeepSeek V4 Flash est open-source et constitue le modèle par défaut recommandé dans le bootcamp.

Le coffre et l'infrastructure

Workspace

Le Workspace est le dossier racine depuis lequel tu lances OpenCode. Dans le bootcamp, c'est le dossier que tu télécharges au départ : il contient un sous-dossier Second Cerveau/ (ton coffre Obsidian), un fichier opencode.json, et les fichiers de configuration de l'agent.

Vault (Coffre) / Second Cerveau

Un vault (ou "coffre") est le dossier principal d'Obsidian qui contient toutes tes notes. C'est ton second cerveau : un ensemble de fichiers Markdown liés entre eux par des wikilinks. Dans le bootcamp, il s'appelle Second Cerveau/ et vit à l'intérieur du Workspace.

Obsidian Sync

Obsidian Sync est le service de synchronisation payant d'Obsidian. Il chiffre tes notes de bout en bout et les synchronise entre tous tes appareils (Mac, iPhone, iPad). C'est la solution recommandée dans le bootcamp pour synchroniser ton coffre (8$/mois avec le plan annuel). Les données passent par les serveurs d'Obsidian mais restent chiffrées.

Markdown (.md)

Le Markdown est un format de fichier texte simple utilisé par Obsidian. Un fichier .md est du texte brut avec des conventions de formatage (# titre, **gras**, - liste). C'est le format natif d'Obsidian et le format que l'IA lit le mieux. Il est compatible partout et n'est pas propriétaire.

Wikilink

Un wikilink ([[Nom de la note]]) est un lien interne entre deux notes dans Obsidian. C'est ce qui crée le réseau de connexions de ton second cerveau.

IPCRA

IPCRA est le système d'organisation du coffre : Inbox, Projets, Casquettes, Ressources, Archives. Chaque note va dans une de ces catégories. C'est une adaptation du système PARA de Tiago Forte.

Phase de vie

Une phase de vie est une période définie avec une intention claire. Exemples : "Lancer mon business", "Apprendre le machine learning", "Déménagement à Hong Kong". Les phases de vie structurent ton journaling et ta planification dans le coffre.

• J'ai compris la différence entre modèle, provider et interface
• Je sais ce qu'est un token et une fenêtre de contexte
• Je comprends ce que fait un agent vs un chatbot
• Je sais ce que signifie MCP, API, CLI, ZDR, SSH, webhook
• Je sais ce que sont le Workspace, le coffre, et opencode.json

Zoom sur la sécurité et la privacy

Travailler avec l'IA dans tes fichiers locaux, ça soulève deux questions : qu'est-ce qu'elle peut faire sur ton ordinateur, et qu'est-ce qui sort vers le provider quand tu lui parles. Cette leçon répond aux deux, dans cet ordre.

1. L'IA n'a pas accès à tout par défaut

C'est le premier point à comprendre. Quand tu lances OpenCode Desktop, l'IA ne peut rien faire sans ta validation. Elle a la configuration de base d'OpenCode, qui te demande explicitement avant chaque action :

• Lire ce fichier : tu valides ?
• Modifier cette note : tu valides ?
• Exécuter cette commande bash : tu valides ?

C'est volontaire. Tu gardes le contrôle de tout, mais ça peut vite devenir lourd au quotidien.

Le bouton "accepter automatiquement"

Dans les réglages d'OpenCode Desktop, tu peux activer une option qui dit à l'IA : « tu peux faire ce que tu veux sans me demander, je te fais confiance ». Pratique quand tu travailles à fond. Tu peux la désactiver à tout moment.

Compromis classique : confiance maximale (fluide mais l'IA peut tout faire) vs validation au cas par cas (sécurisé mais lent). La plupart des participants finissent par activer l'auto-accept dans leur coffre, et désactivent quand ils travaillent sur des projets clients sensibles.

Restreindre finement les permissions

Si tu veux quelque chose entre les deux extrêmes (auto-accept ou validation totale), tu peux configurer précisément ce que l'IA peut faire dans le fichier opencode.json à la racine de ton workspace.

C'est du JSON. Tu peux l'écrire toi-même en lisant la documentation officielle d'OpenCode sur les permissions. Ou, mieux : tu demandes à l'IA de le faire pour toi.

Le mini-prompt pour configurer tes permissions sans toucher au JSON

Plutôt que d'apprendre la syntaxe opencode.json, copie-colle ce prompt à ton IA dans OpenCode :

Je veux configurer tes permissions dans opencode.json.

D'abord, lis la documentation officielle ici :
https://opencode.ai/docs/permissions

Ensuite, pose-moi ces questions une par une, attends ma réponse
(oui / non / précise) avant de passer à la suivante :

1. Tu peux lire les fichiers dans Second Cerveau/ sans me demander ?
2. Tu peux écrire dans Second Cerveau/ sans me demander ?
3. Tu peux accéder aux autres dossiers de mon Workspace ?
4. Tu peux exécuter des commandes shell (git, ls, cat) sans me demander ?
5. Tu peux exécuter des commandes réseau (curl, wget) sans me demander ?
6. Tu peux exécuter des commandes destructrices (rm, mv, rmdir) sans me demander ?

À la fin, mets à jour opencode.json avec mes choix, montre-moi le résultat,
et explique-moi en une phrase ce que ça change.

L'IA va lire la doc à jour, te poser les questions dans ton langage, et écrire le JSON pour toi. Tu valides à la fin. Tu n'as jamais à toucher au JSON manuellement.

2. Ce qui est envoyé au modèle (et ce qui ne l'est pas)

C'est le deuxième point essentiel : quand tu poses une question à ton IA, qu'est-ce qui sort de ton ordinateur exactement ?

La réponse va te rassurer.

Ton coffre n'est pas uploadé en bloc

À chaque requête, l'IA ne « charge » pas tout ton coffre en mémoire pour ensuite l'envoyer au provider. Voici ce qui se passe vraiment :

Conséquence pratique

Tu n'as pas besoin de deux coffres séparés (un « sécurisé » et un « pas sécurisé »). L'IA ne va lire que ce dont elle a besoin pour la requête en cours.

Et tu peux utiliser différents modèles selon la sensibilité de chaque tâche, dans le même coffre. Par exemple :

• Tâche perso, brainstorm : DeepSeek V4 Flash sur OpenRouter ZDR
• Tâche avec données clients : GLM 5.2 via Synthetic AI (abonnement ZDR)
• Tâche créative sans enjeu : ChatGPT (GPT 5.6)

Tu bascules dans OpenCode Desktop en une seconde. Le coffre reste le même.

3. Pourquoi la confidentialité, c'est important

Si tu te dis « j'ai rien à cacher, ça me préoccupe pas », regarde cette vidéo. Elle explique en détail ce qui se passe vraiment avec tes données quand tu parles à une IA, et pourquoi c'est bien plus large qu'un simple problème individuel.

Les points clés en 1 minute :

• Snowden, 2013 : les agences de renseignement américaines (NSA Prism, programme XKeyscore) ont un accès direct aux serveurs de Google, Facebook, Apple, Microsoft. La devise interne : « on enregistre tout, on filtrera plus tard si besoin ». Le programme existe toujours, en plus puissant.
• Cloud Act, 2018 : toute entreprise US (peu importe où sont les serveurs) doit livrer les données au gouvernement américain sur demande. Donc même un data center « européen » d'AWS ou Azure est concerné.
• Politiques de rétention en pratique : ChatGPT conserve par défaut tant que ton compte existe. Claude conserve 5 ans + 30 jours après suppression + jusqu'à 2 ans pour modération « trust & safety » humaine. La suppression vraiment effective est rarement immédiate.
• Le marché de la prédiction : ton profil comportemental vaut de l'argent. C'est ce que documente Shoshana Zuboff dans The Age of Surveillance Capitalism. Cambridge Analytica, Brexit, élection Trump sont les exemples emblématiques.

La posture saine : considérer que tout ce qui sort vers un provider US est potentiellement archivé pour toujours, peu importe ce que dit leur politique de confidentialité officielle.

4. La confidentialité au quotidien : deux options ZDR

C'est la recommandation par défaut pour 90 % des cas.

ZDR (Zero Data Retention) signifie que ta requête arrive au provider, le modèle génère une réponse, et tout est supprimé immédiatement. Rien stocké, rien loggué, rien réutilisé pour entraîner un modèle. Le provider s'engage contractuellement et c'est auditable.

Pour ton usage privé, tu as deux options ZDR complémentaires. On met en avant Synthetic AI (abonnement privé) pour tout ce qui touche des données clients ou sensibles, et on garde OpenRouter ZDR (au token) pour DeepSeek et les tests.

Option 1 (à privilégier pour le privé) : Synthetic AI

Option 2 : OpenRouter ZDR, au token (DeepSeek et tests)

OpenRouter reste parfait pour DeepSeek V4 Flash (ton défaut ultra bon marché) et pour tester de nouveaux modèles à la demande, sans abonnement. Tu paies au token, tu actives le ZDR une seule fois, et tu es tranquille.

openrouter.ai : 400+ modèles, 60+ providers, une seule API.

1. Connecte-toi sur openrouter.ai
2. Va dans Settings (en haut à droite)
3. Section Privacy : active Zero Data Retention
4. Save

OpenRouter ne route alors que vers des providers qui ont signé l'engagement ZDR (Fireworks, Parasail, certaines instances DeepInfra...). Tes requêtes ne sont plus stockées.

Sur ChatGPT, désactive l'entraînement

Si tu utilises ChatGPT Plus connecté à OpenCode Desktop, fais ce réglage manuellement :

1. Va sur chatgpt.com, clique sur ton avatar en haut à droite
2. Settings, puis Data Controls
3. Désactive « Improve the model for everyone »

OpenAI ne peut plus utiliser tes conversations pour entraîner ses modèles. Note : la rétention reste tant que ton compte existe, ce n'est pas du ZDR. Pour les tâches sensibles, préfère Synthetic AI (GLM 5.2) ou OpenRouter ZDR.

5. Si tu préfères héberger en Europe

Pour ceux qui veulent une infrastructure non-US par principe (souveraineté, RGPD strict, Cloud Act), voici les options réelles à l'été 2026.

Recommandation : Scaleway Generative APIs

Scaleway est la meilleure option européenne pure-play. Data centers en France, ZDR par défaut (pas besoin d'activer une option), pas d'entraînement sur tes données, RGPD natif. Ils proposent Llama 3, Mistral, Mixtral, DeepSeek R1. Pas dépendant d'AWS / Azure / GCP : infrastructure propre.

scaleway.com/en/generative-apis

Alternative équivalente : OVHcloud AI Endpoints

OVHcloud AI Endpoints, data centers à Gravelines, plus de 40 modèles open source, certifié ISO 27001/27017/27018/27701. Souveraineté française complète, infrastructure 100 % propre.

ovhcloud.com/en/public-cloud/ai-endpoints

Mistral AI : possible mais avec nuances

Mistral AI est français, leurs modèles (Mistral Large 3, Magistral, Mistral Small 4, Codestral) sont solides en 2026. Mais attention :

• Le Chat (gratuit ou payant) : entraînement sur tes données activé par défaut, opt-out manuel, pas de ZDR disponible. À éviter pour un usage privacy-first.
• API / La Plateforme : ZDR disponible sur demande au support avec justification. Pas activable d'un clic. Rétention par défaut 30 jours.
• Cloud Act : Mistral utilise Microsoft Azure et Google Cloud comme sous-traitants pour l'inférence. Donc le Cloud Act peut techniquement s'appliquer, même si les serveurs sont en UE. Mistral Compute (data center propre en France, 18 000 GPU) est annoncé mais pas pleinement opérationnel.

mistral.ai

Verdict : Mistral via API + DPA signé + ZDR activé est acceptable. Mistral Le Chat, non recommandé pour des données sensibles.

Autres alternatives à connaître

• LLMBase : trop petite et non vérifiable (entité légale opaque, revenus très modestes). Non recommandé pour un usage sérieux.
• Albert AI (DINUM) : réservé aux agents de l'État, pas accessible aux particuliers.
• Lucie (Linagora) : modèle français mais performances actuelles insuffisantes pour un usage knowledge worker.

6. Pour les données très sensibles : faire tourner le modèle en local

Si tu travailles avec des données de santé, juridiques, hautement confidentielles, ou si tu veux la souveraineté absolue, fais tourner le modèle sur ton propre matériel. Rien ne sort de ton réseau.

La règle de base : pour que ça soit utilisable, le modèle doit tenir entièrement dans ta RAM (sur Mac, c'est de la RAM unifiée partagée avec le GPU). S'il déborde sur le disque, la vitesse s'effondre. Ton plafond de RAM détermine donc directement les modèles auxquels tu as accès.

Le plus simple (CLI)

Ollama

Une commande pour tout installer (curl -fsSL ollama.com/install.sh | sh), puis ollama run qwen3:8b. Idéal pour OpenCode Desktop qui s'y connecte en un clic.

ollama.com

Interface graphique

LM Studio

Une app desktop avec catalogue de modèles, téléchargement en un clic, chat intégré, et un serveur local compatible OpenAI. Plus accessible si tu fuis le terminal.

lmstudio.ai

Tier 1 : 16 Go de RAM (MacBook Air M2, MacBook Pro M3 base)

Tu peux faire tourner des modèles de 3 à 8 milliards de paramètres en Q4 (quantisation 4 bits). C'est suffisant pour du chat, de l'aide à la rédaction, des recherches simples. Pas suffisant pour de l'agentique avancé (multi-step, tool calls complexes).

Modèles à essayer :

• Gemma 4 E2B (Google, ~3,5 Go en Q4). C'est le nouveau modèle Google sorti en avril 2026. Multimodal (texte + audio + image). DeepMind a annoncé en mai un projet « Accelerating Gemma 4 » qui ajoute du multi-token prediction (le modèle prédit plusieurs tokens à la fois, ce qui accélère l'inférence sans dégrader la qualité). À surveiller.
• Qwen 3 4B ou Qwen 3 8B : très bon rapport qualité/taille, contexte 256K.
• Llama 3.2 3B : rapide, qualité correcte pour du chat.

Vitesse attendue : 30 à 60 tokens/seconde sur Mac M3 16 Go. Confortable pour du chat, juste pour de l'agentique.

L'intérêt à ce tier, c'est surtout de comprendre comment le local fonctionne et de tester. Pour un usage knowledge worker complet, tu seras vite limité.

Tier 2 : 32 à 64 Go de RAM (MacBook Pro M3 Max, Mac mini M4 Pro)

C'est le tier où le local devient vraiment utilisable au quotidien. Les modèles 12 à 32 milliards de paramètres deviennent confortables.

• Gemma 4 26B-A4B (Google, MoE, ~18 Go en Q4) : 3,8B de paramètres actifs seulement à chaque token, donc rapide.
• Qwen 3 32B (Q4) : meilleur open weight 30B à l'été 2026.
• DeepSeek R1 32B (Q4) : fort en raisonnement.
• Mistral Small 24B (Q4) : inférence très rapide.

Sur 64 Go, les modèles 70B (~43 Go en Q4) deviennent accessibles : Llama 3.3 70B, DeepSeek R1 70B.

Tier 3 : 128 Go et plus (Mac Studio M3/M4 Ultra)

C'est ici que tu peux faire tourner les gros modèles open source frontières (GLM 5.2, DeepSeek V4 Flash, Qwen 3 235B). Ordre de prix :

• Mac Studio M3 Ultra 192 Go : 10 000 à 13 000 €
• Mac Studio M4 Ultra 512 Go : 25 000 à 30 000 € (haut de gamme grand public absolu)

À 192 Go, tu peux faire tourner :

• DeepSeek R1 70B en Q8 (~80 Go) : qualité quasi équivalente à la version full precision
• Qwen 3 235B MoE en Q2 (~90-100 Go) : 22B actifs à chaque token
• GLM 5.2 744B MoE en Q2 (~150 Go estimé) : 40B actifs
• Mistral Large 123B en Q4 (~75 Go)

À 512 Go, DeepSeek V4 Flash en Q4 ou même certains modèles 400B+ deviennent faisables.

Comprendre la quantisation (Q2, Q4, Q5...)

Un modèle « brut » stocke ses paramètres en 16 bits (FP16). Le quantiser, c'est compresser ces paramètres sur moins de bits, pour qu'il prenne moins de RAM.

Le suffixe K_M ou K_S (K-quant Medium / Small) indique une variante optimisée qui préserve mieux les couches importantes du modèle. Pour Ollama, le défaut est généralement Q4_K_M, c'est très bien.

Pour aller plus loin

Sur le hardware et l'optimisation du local, je te recommande la chaîne YouTube @xcreate qui couvre le sujet en profondeur : choix de hardware, quantisation, comparaisons de modèles, retours d'expérience sur les Mac Studio.

Cas pratique : une équipe qui mutualise

Pour une boîte de 5 à 50 personnes, un Mac Studio Full Spec partagé devient rapidement rentable comparé à 10 ou 50 abonnements API. Tu installes Ollama dessus, tu exposes l'API en réseau local, chacun connecte son OpenCode Desktop dessus. Rien ne sort de l'infra. ROI typique : moins d'un an de mutualisation par rapport aux abonnements individuels.

7. Gérer ses secrets : API keys et mots de passe

Commençons par dédramatiser. La dernière promo a passé un temps fou à installer et brancher Bitwarden. Dans la grande majorité des cas, tu n'en as pas besoin.

Si ton coffre est en Obsidian Sync, tes clés sont déjà chiffrées

Quand ton coffre est synchronisé avec Obsidian Sync, tout est chiffré de bout en bout (E2E) avec ton mot de passe d'encryption. Même Obsidian ne peut pas lire tes fichiers.

Conséquence directe : avoir tes clés API en clair dans tes fichiers de config (opencode.json, .env) ou dans une note, ce n'est pas un problème grave. C'est chiffré E2E, le risque réel est très faible.

Tu n'es pas le Pentagone. Tu es un knowledge worker qui veut avancer vite avec son IA. Privilégie la simplicité d'usage plutôt que la complexité d'un password manager que tu vas galérer à connecter. Des clés en clair dans un coffre chiffré E2E, c'est très bien pour démarrer, et très bien pour durer.

Le bon sens minimal : 2 règles suffisent

1. Ne colle jamais une clé dans un espace public : session ChatGPT partagée, Discord, forum, ticket support. Là, elle sort vraiment en clair chez un tiers.
2. Ne commite jamais une clé dans un repo Git public non chiffré. Un .env poussé sur un GitHub public, c'est la fuite classique. Ajoute .env à ton .gitignore (détaillé en semaine 3) et le sujet est réglé.

Le reste, c'est du confort.

Optionnel (avancé) : Bitwarden comme coffre central

Tu n'en as pas besoin pour le bootcamp. Mais si tu veux aller plus loin, ou si tu gères des données client très sensibles (santé, juridique, secrets d'une boîte tierce), un password manager centralise proprement tous tes secrets (API keys, mots de passe, tokens, clés SSH). Bitwarden est gratuit, open source, chiffré de bout en bout, avec app mobile et extension navigateur.

bitwarden.com

Connecter Bitwarden à ton IA via Bitwarden CLI

Bitwarden propose un CLI (documentation officielle) qui permet à ton IA de récupérer un secret à la volée dans tes scripts ou tes sessions, sans jamais que tu n'aies à le coller en clair quelque part.

Installer le CLI :

# Mac
brew install bitwarden-cli

# Windows (via Chocolatey ou exécutable natif)
choco install bitwarden-cli

# Cross-platform via npm
npm install -g @bitwarden/cli

Workflow concret :

1. Une fois par session, tu déverrouilles ton coffre manuellement dans ton terminal :

bw unlock

Bitwarden te demande ton mot de passe maître. Une fois validé, il te retourne une commande à copier-coller :

export BW_SESSION="eyJhbGciOi..."

1. Tu colles cette commande dans ton shell. Tant que cette variable d'env existe, toutes les commandes Bitwarden fonctionnent sans demander à nouveau ton mot de passe.

2. Maintenant, ton IA dans OpenCode peut récupérer n'importe quel secret à la volée :

# Lister tes secrets
bw list items --search "OpenAI"

# Récupérer juste le mot de passe d'un item
bw get password "OpenAI API"

# Récupérer l'item complet en JSON
bw get item "OpenAI API"

1. Quand tu as fini ta session, verrouille à nouveau :

bw lock

Le token expire automatiquement après inactivité, donc même si tu oublies, tu n'es pas exposé indéfiniment.

Avantage : ton IA peut accéder à tes secrets quand elle en a besoin (pour faire un appel API, configurer un MCP), mais elle ne voit jamais ton mot de passe maître. Seul le token de session temporaire transite. Et tu peux révoquer l'accès à tout moment avec bw lock.

Prompt à donner à ton IA

Quand tu veux qu'elle utilise un secret dans une tâche, dis-lui simplement :

J'ai déverrouillé mon coffre Bitwarden. Mon BW_SESSION est exporté.
Récupère ma clé API OpenAI avec `bw get password "OpenAI API"`
et utilise-la pour [tâche].

Elle exécute, fait son boulot, et ton secret n'est jamais écrit en clair quelque part de persistant.

Et les secrets dans Obsidian ?

C'est parfaitement OK, à condition que ton coffre soit synchronisé via Obsidian Sync (chiffrement de bout en bout avec ton mot de passe d'encryption). Dans ce cas, une clé API dans une note ou dans opencode.json est chiffrée dès qu'elle quitte ta machine. C'est le setup par défaut recommandé.

Deux réflexes de bon sens, quand même :

• Ton coffre est en clair sur ton disque local (seul le transfert vers le cloud est chiffré). Sur ta machine perso, ce n'est pas un souci. Sur une machine partagée, active le chiffrement disque (FileVault sur Mac, activé par défaut).
• Ne pousse pas ton vault sur un GitHub public. Si tu veux le versionner sur Git, garde le repo privé, ou mieux, auto-hébergé (Gitea, voir semaine 3).

Autrement dit : coffre en Obsidian Sync, tes clés y sont bien. Un password manager n'ajoute qu'un cran de sécurité optionnel, utile surtout pour des données client très sensibles.

Dans tes projets de développement

Pour les projets de code (sites web, apps), utilise un fichier .env à la racine et ajoute-le dans .gitignore :

# .gitignore
.env
.env.local
.env.*.local

Les valeurs peuvent rester en clair dans le .env (il est ignoré par git). Si tu utilises un password manager, tu peux aussi les injecter via son CLI au moment du déploiement (CI/CD ou script local), mais ce n'est pas obligatoire.

8. Synchronisation du coffre

Quand tu synchronises ton coffre avec Obsidian Sync, GitHub ou autre :

• Obsidian Sync (recommandé) : tes données passent par les serveurs d'Obsidian, mais sont chiffrées de bout en bout avec ton mot de passe d'encryption. Même Obsidian ne peut pas les lire.
• GitHub (repo privé) : stockage sur serveurs Microsoft (US, soumis au Cloud Act). GitHub ne lit pas le contenu pour entraîner Copilot tant que tu ne l'actives pas explicitement.
• GitLab self-hosted ou Gitea sur ton propre serveur : alternative souveraine, plus technique. On installe Gitea en semaine 3 si tu prends ce chemin.

9. Récapitulatif

• Je comprends que l'IA demande validation par défaut, et que je peux activer l'auto-accept
• J'ai utilisé le mini-prompt pour configurer mes permissions opencode.json
• J'ai compris que l'IA ne lit que les fichiers pertinents (pas tout le coffre)
• Je connais Synthetic AI comme option ZDR privée mise en avant (GLM 5.2, abonnement 30 $/mois)
• J'ai activé ZDR sur OpenRouter (Settings, Privacy) pour DeepSeek et les tests
• J'ai désactivé l'entraînement sur ChatGPT (Data Controls)
• Je sais que des alternatives européennes existent (Scaleway, OVHcloud) pour les cas où c'est nécessaire
• Mes clés API sont dans un coffre chiffré E2E (Obsidian Sync), jamais dans un repo public ni un chat public

Travailler sur plusieurs projets en parallèle

Ton second cerveau est parfait pour ton usage perso. Mais très vite, tu vas vouloir utiliser ton IA sur d'autres choses : un site web, une app, un projet client, des notes d'équipe. La question devient : comment ouvrir l'IA sur plusieurs projets sans tout mélanger ?

Il y a trois options. Tu choisis selon ton besoin.

Option A : un projet OpenCode par projet (cloisonnement)

Tu ouvres OpenCode Desktop directement sur le dossier d'un projet. C'est un projet OpenCode à part entière : l'IA ne voit que ce dossier, rien d'autre.

Pour qui : projets clients sensibles, contextes vraiment différents, ou notes d'équipe que tu ne veux pas mélanger à ton perso. Si tu utilises Obsidian, chaque dossier est un coffre Obsidian séparé. Tu bascules avec « Switch vault ».

La seule contrainte technique : le fichier opencode.json doit être à la racine de chaque projet, là où tu lances l'IA. C'est lui qui dit où trouver les skills, les MCP, la config du projet.

{
  "$schema": "https://opencode.ai/config.json",
  "skills": {
    "paths": ["./4 TOOLS/skills"]
  }
}

L'AGENTS.md à la racine décrit le contexte spécifique du projet. Comme ça l'IA a son cadre dès qu'elle démarre.

Option B : un Workspace racine, plusieurs dossiers dedans (recommandé par défaut)

Tu ouvres toujours OpenCode au même endroit : un dossier Workspace racine. C'est un seul projet OpenCode qui contient tous tes sous-dossiers (second cerveau + projets web + projets clients...).

Pour qui : la plupart des cas. Tu n'as jamais à te demander où ouvrir l'IA. C'est toujours Workspace.

Seule chose à faire : quand tu ajoutes un nouveau dossier, mets à jour le AGENTS.md à la racine pour expliquer ce qu'il contient. L'IA lit ce fichier au démarrage et sait quel dossier consulter selon ta question.

Exemple d'extrait à mettre dans Workspace/AGENTS.md :

## Arbre du Workspace

- `Second Cerveau/` : mon coffre Obsidian (notes perso, projets, casquettes)
- `mon-site-web/` : repo du site Astro déployé sur Cloudflare Pages
- `projet-client-A/` : notes et scripts pour le client A, sensible, ne pas pousser de secrets
- `projet-perso/` : side project libre, expérimentations

Le fichier opencode.json à la racine, lui, sert à exposer les skills et les MCP à toutes tes sessions :

{
  "$schema": "https://opencode.ai/config.json",
  "skills": {
    "paths": ["./Second Cerveau/4 TOOLS/skills"]
  }
}

Option C : pas migrer du tout, brancher l'IA sur Notion ou Outline (MCP)

Si ton équipe utilise déjà Notion, Outline, Confluence ou un autre outil de doc interne, ne migre pas tout dans Obsidian. Tu peux brancher l'IA directement sur la base existante via un MCP (Model Context Protocol).

Le scénario : tu installes le MCP Notion dans ton opencode.json. Tu donnes tes credentials. À partir de là, l'IA peut lire et écrire dans la base Notion de l'entreprise. Tes collègues continuent d'utiliser Notion comme avant, toi tu gardes ta vélocité IA sur ton coffre Obsidian local plus l'accès via MCP.

Pour qui : équipes non techniques ou organisations établies qui ont déjà des centaines de pages dans Notion/Outline. Migrer tout dans Obsidian serait un projet de plusieurs mois pour zéro gain. Le MCP te permet d'avoir le meilleur des deux mondes immédiatement.

Comment connecter un MCP : voir le skill /connect-mcp (semaine 3) ou la leçon Installer ses outils IA.

Récap : quelle option pour quel cas

Par défaut, démarre avec l'Option B. C'est la plus simple à vivre au quotidien. Tu passeras à A ou C uniquement si ton contexte l'exige.

Addon : tout voir dans un seul Obsidian (symlinks et junctions)

Cas spécifique : tu es sur l'Option A avec plusieurs coffres Obsidian séparés (par exemple, ton coffre perso + un coffre d'équipe synchronisé via Obsidian Sync). Tu trouves chiant de basculer en permanence entre les deux. Tu voudrais voir toutes tes notes dans un seul Obsidian, le perso, avec le coffre d'équipe qui apparaît comme une casquette dedans.

La solution : un raccourci système qui pointe d'un dossier à un autre, sans le dupliquer. Sur Mac/Linux on appelle ça un symlink. Sur Windows, on utilise une junction (mklink /J).

Sur Mac / Linux : symlink (ln -s)

# Tu as un dossier séparé qui vit ailleurs dans le Workspace
~/Workspace/notes-equipe/

# Tu crées un symlink dans ton Second Cerveau, dans 2 CASQUETTES
cd ~/Workspace/Second\ Cerveau/2\ CASQUETTES/
ln -s ../../notes-equipe Notes-Equipe

Sur Windows : junction (mklink /J)

Sur Windows, les vrais symlinks demandent le mode développeur ou des droits admin. Pas pratique. L'équivalent fiable et sans droits admin pour les dossiers locaux, c'est la junction. Obsidian Desktop, OpenCode et Git la traitent exactement comme un dossier normal.

Ouvre un terminal (cmd ou PowerShell), pas besoin de mode admin :

cd "C:\Users\Toi\Workspace\Second Cerveau\2 CASQUETTES"
mklink /J "Notes-Equipe" "..\..\notes-equipe"

Le /J crée une junction (lien de jonction). C'est ce qui se rapproche le plus d'un symlink Unix dans la pratique : Windows considère le dossier comme réel, Obsidian Desktop le suit comme n'importe quel dossier.

À noter : une junction ne marche que pour des dossiers locaux sur le même volume (même lettre de lecteur). Si tu pointes vers un dossier sur un autre disque ou sur un partage réseau, utilise plutôt mklink /D (symlink vrai) qui exige le mode développeur Windows activé.

Trois points importants

1. Exclus le dossier lié d'Obsidian Sync du Second Cerveau qui contient le lien. Sinon Obsidian Sync va synchroniser deux fois le même contenu (une fois dans le coffre d'équipe, une fois dans ton perso via le lien) et créer des conflits. Va dans Settings → Sync → Selected folders et désélectionne le dossier symlinké/junction.

2. Sur mobile (Obsidian iOS / Android), les symlinks et junctions ne sont pas suivis. Si tu travailles beaucoup sur mobile, oublie cet addon : reste sur l'Option A et bascule entre coffres avec « Switch vault », ou passe à l'Option B où tout est nativement dans un seul dossier.

3. Pour partager des skills entre coffres, le symlink/junction n'est pas la meilleure approche. Utilise plutôt skills.paths dans opencode.json (voir section dédiée plus bas).

Synchroniser un coffre avec ton équipe

Une fois la structure choisie, comment plusieurs personnes partagent un même coffre Obsidian ?

Deux solutions selon ton équipe (la troisième, c'était l'Option C ci-dessus : MCP vers Notion/Outline).

Solution recommandée : Obsidian Sync partagé

C'est la solution la plus simple si chaque membre de l'équipe peut avoir une licence Obsidian Sync (4 € par mois et par membre, payé par l'entreprise typiquement).

1. Un membre crée un coffre Obsidian dédié à l'équipe (séparé de son perso).
2. Il active Obsidian Sync dessus et invite les autres membres depuis l'interface.
3. Chacun installe Obsidian, se connecte à son compte, sélectionne le coffre partagé, entre le mot de passe d'encryption commun.
4. Tout est synchronisé en temps réel, chiffré de bout en bout (E2E).

Coût : 4 €/membre/mois. Pour une équipe de 5, c'est 20 €/mois. Largement rentable comparé à n'importe quelle autre solution une fois que tu as testé la stabilité.

Avantages :

• Marche aussi sur mobile sans config supplémentaire.
• Pas de Git, pas de clone, pas de Personal Access Token à gérer.
• Conflits gérés automatiquement.
• Historique des versions intégré (jusqu'à 1 an selon ton plan).

Côté IA : chaque membre lance OpenCode sur son Workspace racine (Option B) avec le coffre partagé dedans, ou directement sur le coffre d'équipe (Option A).

Alternative gratuite : Syncthing

Si tu ne veux pas payer Obsidian Sync, Syncthing fait de la synchronisation peer-to-peer entre les machines des membres. C'est open source, gratuit, plus technique à mettre en place. Pas d'app mobile aussi propre qu'Obsidian Sync (app Android officieuse correcte, rien d'officiel sur iOS).

Pour qui : équipes tech qui ont déjà un setup serveur, ou bricoleurs qui acceptent le coût d'entrée technique.

À tester en sandbox avant de t'engager : la résolution de conflits Syncthing est moins fluide qu'Obsidian Sync, et il faut que les machines soient allumées en même temps pour la sync (ou avoir un nœud serveur permanent).

Partager des skills en équipe

Tu as créé un skill custom utile (par exemple /sync-compta, /newsletter, /onboarding-client) et tu veux que toute l'équipe puisse l'utiliser ?

Approche simple : dans le coffre partagé

Si ton équipe partage déjà un coffre via Obsidian Sync, les skills vivent dans Second Cerveau d'équipe/4 TOOLS/skills/ et sont automatiquement synchronisés à tout le monde. C'est l'option la plus naturelle. Tu n'as rien d'autre à configurer côté équipe.

Chaque membre référence ce dossier dans son opencode.json racine (Option B) :

{
  "$schema": "https://opencode.ai/config.json",
  "skills": {
    "paths": [
      "./Second Cerveau/4 TOOLS/skills",
      "./Second Cerveau d'équipe/4 TOOLS/skills"
    ]
  }
}

Approche multi-coffres : skills.paths étendu

Si chaque membre a son propre coffre perso, et qu'il y a en plus un dossier de skills d'équipe partagé séparément (Obsidian Sync dédié, repo Git, Syncthing, peu importe), tu pointes vers ces deux dossiers dans skills.paths :

{
  "$schema": "https://opencode.ai/config.json",
  "skills": {
    "paths": [
      "./Second Cerveau/4 TOOLS/skills",
      "./skills-equipe"
    ]
  }
}

OpenCode charge les skills des deux dossiers, et tout fonctionne dans la même interface. Chacun garde ses skills perso (/done, /welcome, /weekly-review...), et tout le monde profite des skills d'équipe (/onboarding-client, /newsletter...).

Points importants

Toujours un opencode.json à la racine du dossier où tu lances l'IA. C'est lui qui dit à OpenCode où trouver les skills, les MCP, la config. Sans ça, les skills ne sont pas chargés et tu te demandes pourquoi /welcome ne fait rien.

AGENTS.md à la racine, c'est le contexte de base. L'IA le lit au démarrage. Si tu changes d'option (passer de A à B par exemple), pense à mettre à jour ce fichier pour qu'il décrive bien la nouvelle structure.

Sur desktop, Obsidian suit nativement les symlinks (Mac/Linux) et les junctions (Windows). Sur mobile, oublie : utilise plutôt l'Option B ou Obsidian Sync sur un coffre dédié.

Obsidian Sync ne synchronise pas les fichiers cachés (.opencode/, .claude/, .git/). C'est pour ça qu'on met les skills dans 4 TOOLS/skills/ (visible), pas dans .opencode/ (caché). Vrai aussi pour l'AGENTS.md du Workspace : il doit être à la racine, pas dans un dossier caché.

Checklist

• Je connais les 3 options : A (un projet OpenCode par dossier), B (un Workspace racine), C (MCP vers Notion/Outline)
• Je sais que par défaut, je pars sur l'Option B : un Workspace racine avec tous mes dossiers dedans
• Je sais que opencode.json doit être à la racine du dossier où je lance l'IA
• Je sais que AGENTS.md à la racine décrit chaque sous-dossier pour orienter l'IA
• Pour partager un coffre Obsidian en équipe, Obsidian Sync à 4 € par membre est la solution la plus simple
• Je connais Syncthing comme alternative gratuite, et le MCP Notion/Outline si l'équipe ne veut pas migrer
• Je sais que skills.paths dans opencode.json accepte plusieurs dossiers de skills
• Si je veux tout voir dans un seul Obsidian : symlink (Mac/Linux) ou junction mklink /J (Windows), et exclure le dossier d'Obsidian Sync

Utiliser l'IA dans un terminal

OpenCode Desktop suffit largement pour suivre ce bootcamp. Tu n'as pas besoin du terminal pour construire ton second cerveau, créer tes skills, ou faire tourner tes rituels.

Mais le terminal devient pertinent dans deux cas. Cette leçon est pour toi si tu te reconnais dans l'un des deux.

Pourquoi utiliser l'IA dans un terminal ?

Si tu ne te reconnais dans aucun des deux, reste sur OpenCode Desktop. Tu pourras toujours revenir à cette leçon plus tard.

Les commandes de base du terminal

Le terminal (aussi appelé « ligne de commande » ou « console ») est une interface texte pour communiquer avec ton ordinateur. Au lieu de cliquer, tu tapes.

Tu n'as besoin que de 4 commandes pour le bootcamp.

Mac / Linux :

# Voir où tu es (Print Working Directory)
pwd

# Lister les fichiers du dossier actuel
ls

# Changer de dossier
cd nom-du-dossier

# Revenir au dossier parent
cd ..

Windows (PowerShell) :

# Voir où tu es
pwd

# Lister les fichiers
dir
# (ls fonctionne aussi sur PowerShell moderne)

# Changer de dossier
cd nom-du-dossier

# Revenir au dossier parent
cd ..

Exercice pratique (3 minutes)

1. Ouvre ton terminal
2. Tape pwd puis Entrée : tu vois ton dossier actuel
3. Tape ls (ou dir sur Windows) : tu vois les fichiers
4. Tape cd Desktop puis ls : tu entres dans le Bureau et tu vois son contenu
5. Tape cd .. : tu reviens en arrière

Astuce Mac : Tu peux glisser-déposer un dossier dans le terminal après avoir tapé cd (avec un espace) pour naviguer directement dedans.

Astuce Windows : Tu peux faire Shift + Clic droit sur un dossier dans l'Explorateur et choisir « Ouvrir PowerShell ici ».

C'est tout. Tu n'auras pas besoin de plus pour ce bootcamp.

Quel terminal utiliser ?

Les terminaux par défaut (Terminal.app sur Mac, PowerShell sur Windows) fonctionnent. Mais un terminal moderne est plus rapide, plus lisible, et surtout te permet de gérer plusieurs sessions IA en parallèle, ce qui change vraiment le quotidien.

Notre recommandation principale

Choisis selon ton OS :

Les alternatives solides

Si tu veux explorer d'autres options :

Installer Claude Code ou OpenCode en CLI

Choisis ton interface. Les deux sont compatibles avec ton coffre, tu peux changer d'avis à tout moment sans rien perdre.

Claude Code (recommandé si tu as un abonnement Claude Pro/Max)

Suis le guide d'installation officiel : docs.anthropic.com/en/docs/claude-code.

Une fois installé, tape claude dans ton terminal, connecte-toi avec ton compte Anthropic (le navigateur s'ouvre), c'est fait.

OpenCode (multi-modèle)

Suis le guide d'installation officiel : opencode.ai/docs.

Une fois installé, tape opencode dans ton terminal, puis /model pour configurer ton provider (OpenRouter recommandé, cf. la leçon principale d'installation).

Toujours ouvrir l'IA depuis ton workspace

L'IA n'a accès qu'au dossier dans lequel tu la lances. Si tu lances claude ou opencode depuis ton Bureau, elle ne voit pas ton coffre.

Le geste à faire à chaque session :

cd ~/Documents/WORKSPACE   # adapte au chemin de ton workspace
claude                      # ou opencode

Tu te retrouves dans le bon dossier, avec l'IA chargée de tout le contexte (AGENTS.md, skills, etc.).

L'alias cc : démarrer en une frappe

Plutôt que de taper cd puis claude (ou opencode) à chaque session, crée un alias cc qui fait les deux d'un coup.

Le plus simple : demande à ton IA de le créer pour toi.

Demande à ton IA

Lance ton IA une première fois, puis donne-lui ce prompt :

J'aimerais que tu crées un alias "cc" dans mon terminal.

Quand je tape "cc", il devrait :
1. Aller dans le dossier de mon workspace (adapte le path)
2. Lancer claude (ou opencode, à toi de choisir)

Modifie le bon fichier de config (.zshrc, .bashrc ou équivalent
selon mon shell) pour que l'alias soit permanent.

L'IA va détecter ton shell, modifier le bon fichier de configuration, et créer l'alias.

Tester

Ferme et rouvre ton terminal, puis tape :

cc

Tu devrais te retrouver dans ton workspace avec ton IA lancée. Une seule frappe au lieu de deux commandes.

• Je sais quand le terminal devient pertinent (dev avancé ou workflow flexible)
• Je connais les 4 commandes de base (pwd, ls, cd, cd ..)
• J'ai choisi mon terminal (cmux sur macOS, WezTerm sur Windows, ou une alternative)
• J'ai installé Claude Code ou OpenCode en CLI
• Je sais toujours lancer l'IA depuis mon workspace
• J'ai créé l'alias `cc` qui fait cd + lancement de l'IA

Cette leçon s'adresse aux utilisateurs de Claude Code. OpenCode Desktop reste la stack recommandée par défaut dans ce bootcamp. Mais si tu as un abonnement Claude Max et que tu veux travailler dans Claude Code (CLI terminal ou Claude Desktop), cette leçon te montre comment l'intégrer proprement avec ton coffre.

Deux Claude Code, deux configurations

Anthropic propose deux façons d'utiliser Claude Code :

Tu peux utiliser les deux, mais elles ne partagent pas leur configuration : tu vas devoir installer tes MCP deux fois si tu veux les retrouver dans les deux interfaces.

Dans le contexte de ce bootcamp (travailler dans ton coffre avec un agent qui voit tes fichiers), c'est Claude Code (CLI terminal) qui est l'équivalent direct d'OpenCode Desktop.

Ouvrir Claude Code dans ton coffre

Si Claude Code n'est pas encore installé, suis la page d'installation officielle d'Anthropic (méthodes natives recommandées : Homebrew sur macOS, WinGet sur Windows, apt/dnf/apk sur Linux). Une fois installé, pour l'utiliser dans ton système :

# Va dans ton Workspace racine
cd ~/Documents/WORKSPACE

# Lance Claude Code
claude

Claude Code démarre, lit l'AGENTS.md ou CLAUDE.md à la racine, remonte les parents s'il y en a, et a accès à tous les fichiers du dossier (Second Cerveau + autres projets).

Astuce : crée un alias dans ton .zshrc ou .bashrc :

alias cco="cd ~/Documents/WORKSPACE && claude"

Tu tapes cco n'importe où, tu atterris dans ton coffre avec Claude Code lancé.

Où sont rangés les MCP au niveau user

Pour qu'un MCP soit dispo dans toutes tes sessions (peu importe le dossier où tu lances Claude Code), tu dois le configurer au scope user (ce que les anciennes versions appelaient « global »).

Pour Claude Code (CLI terminal)

Deux options :

Option 1 : la commande claude mcp add (la plus simple)

claude mcp add --scope user firecrawl npx -y firecrawl-mcp
claude mcp add --scope user playwright npx -y @playwright/mcp@latest

Ces MCP sont disponibles partout, dans n'importe quel dossier où tu lances claude.

Option 2 : éditer le fichier de config user

Le fichier de config global de Claude Code CLI est ~/.claude.json (dans ton home, le même pour toutes tes sessions). Il contient ton OAuth, tes MCP au scope user (dispos partout) et au scope local (privés à un projet précis, indexés par chemin), plus l'état de chaque projet. Tu peux y ajouter une section MCP à la main, mais la commande claude mcp add est plus propre : elle écrit au bon scope, fait des backups automatiques, et garde les 5 derniers backups.

Attention : ~/.claude.json ≠ ~/.claude/. Le fichier .json héberge la config MCP et l'état. Le dossier .claude/ (sans extension) héberge tes skills, agents et commandes user-level (cf. section suivante).

Pour Claude Desktop (app GUI)

Pas de commande dédiée. Tu édites directement le fichier JSON :

• macOS : ~/Library/Application Support/Claude/claude_desktop_config.json
• Windows : %APPDATA%\Claude\claude_desktop_config.json

Format :

{
  "mcpServers": {
    "firecrawl": {
      "command": "npx",
      "args": ["-y", "firecrawl-mcp"],
      "env": {
        "FIRECRAWL_API_KEY": "fc_xxxxx"
      }
    },
    "playwright": {
      "command": "npx",
      "args": ["-y", "@playwright/mcp@latest"]
    }
  }
}

Important : après avoir édité ce fichier, quitte complètement Claude Desktop (Cmd+Q sur macOS, pas juste fermer la fenêtre) et relance. L'app ne recharge pas la config à chaud.

Pour debug : les logs sont dans ~/Library/Logs/Claude/. Le fichier mcp.log donne les connexions, et mcp-server-<NOM>.log donne les erreurs spécifiques à chaque serveur.

Différence clé à retenir

Skills dans Claude Code : pas de skills.paths déclaratif

C'est la grosse différence avec OpenCode. Dans OpenCode, tu listes des dossiers de skills dans opencode.json :

{
  "skills": {
    "paths": [
      "./Second Cerveau/4 TOOLS/skills",
      "./skills-equipe"
    ]
  }
}

Et OpenCode charge tous les skills des chemins listés. Claude Code ne supporte pas ça. Il lit les skills uniquement dans deux endroits :

• ~/.claude/skills/ : skills user / globaux (perso, dispos dans toutes tes sessions, peu importe le dossier où tu lances claude)
• .claude/skills/ : skills projet (à la racine du dossier où tu lances claude, non visibles ailleurs)

Deux détails utiles :

• Hot reload : ajouter, éditer ou supprimer un skill prend effet dans la session courante, pas besoin de redémarrer Claude Code.
• Conflit de nom : si un skill du même nom existe à plusieurs niveaux, l'ordre de priorité est enterprise > user > project.

Si tes skills vivent dans Second Cerveau/4 TOOLS/skills/ (la convention de ce bootcamp), Claude Code ne les voit pas par défaut.

La solution : symlink

Tu crées un symlink (Mac/Linux) ou junction (Windows) entre .claude/skills et le dossier réel de tes skills dans le coffre.

Mac / Linux :

# À la racine de ton Workspace (là où tu lances claude)
cd ~/Documents/WORKSPACE

# Crée le dossier .claude s'il n'existe pas
mkdir -p .claude

# Symlink : .claude/skills pointe vers le vrai dossier
# Important : le path source doit être relatif depuis l'emplacement du symlink,
# donc on entre d'abord dans .claude puis on remonte d'un cran.
cd .claude && ln -s "../Second Cerveau/4 TOOLS/skills" skills && cd ..

Si ta structure de coffre est custom (par exemple tu as renommé "Second Cerveau" en "REFLECTIA" ou utilisé une arbo différente d'IPCRA) : plutôt que de te battre avec les symlinks, demande à Claude Code de faire une passe sur l'ensemble du dossier pour corriger tous les chemins, et stocke tes skills directement dans .claude/skills/. C'est plus simple, ça évite les couches indirectes, et tu économises les tokens consommés par grep + résolution de symlink à chaque session.

Windows (junction, sans droits admin) :

cd "C:\Users\Toi\Documents\WORKSPACE"
mkdir .claude
mklink /J ".claude\skills" "Second Cerveau\4 TOOLS\skills"

Vérifie :

ls -la .claude/skills/
# Doit afficher le contenu de Second Cerveau/4 TOOLS/skills/

À partir de là, Claude Code voit tous tes skills (/initialisation, /import, /weekly-review, /done...) comme s'ils étaient nativement dans .claude/skills/. Tu tapes / dans Claude Code, tu vois la liste complète.

Variante : skills dispos partout via ~/.claude/skills

Si tu veux que tes skills coffre soient dispos dans tous les projets (pas seulement dans le Workspace), fais le symlink depuis ~/.claude/skills à la place :

# Attention : si tu as déjà des skills perso dans ~/.claude/skills, sauvegarde-les avant
ln -s ~/Documents/WORKSPACE/Second\ Cerveau/4\ TOOLS/skills ~/.claude/skills

Trade-off : tu n'as plus de dossier user séparé pour des skills uniquement perso. Pour la plupart des cas, le symlink projet (.claude/skills dans le Workspace) suffit largement.

Récap : lancer Claude Code dans ton coffre proprement

• Je connais la différence entre Claude Desktop (app GUI) et Claude Code (CLI terminal)
• Claude Code installé via la page de doc officielle (https://docs.claude.com/en/docs/claude-code/setup)
• Symlink .claude/skills → Second Cerveau/4 TOOLS/skills créé à la racine du Workspace
• Je sais où sont configurés les MCP user-scope dans Claude Code (~/.claude.json ou claude mcp add --scope user)
• Je sais où sont configurés les MCP dans Claude Desktop (~/Library/Application Support/Claude/claude_desktop_config.json sur macOS)
• Si j'utilise Claude Desktop : je sais qu'il faut quitter complètement (Cmd+Q) et relancer après chaque modif du JSON
• Claude Code lancé depuis mon Workspace : je vois mes skills via /

Sources

• Set up Claude Code (page d'installation officielle)
• Connect Claude Code to tools via MCP
• Extend Claude with skills
• Claude Code settings
• Connect to local MCP servers (Claude Desktop)

Cette leçon s'adresse aux utilisateurs de Codex. OpenCode Desktop reste la stack recommandée par défaut dans ce bootcamp. Mais si tu as un abonnement ChatGPT Plus ou Pro et que tu veux la boucle agentique d'OpenAI dans ton terminal, Codex (l'agent CLI de ChatGPT) s'installe proprement à côté de ton coffre. Cette leçon te montre comment, en te reposant au maximum sur ton IA.

Utiliser Codex dans son coffre

L'idée en une phrase

Bonne nouvelle : presque rien ne change. Le jour où tu passes d'OpenCode à Codex (ou à Claude Code, ou à un autre agent), tu ouvres l'agent dans ton dossier et tout ton contexte est déjà là : ton AGENTS.md, tes notes, tes projets. Tu n'as pas à tout reconfigurer.

Les deux seules choses à rebrancher quand tu changes d'agent, ce sont tes MCP et tes skills. Pourquoi ? Parce que chaque outil a sa propre convention pour ranger ces deux-là. Tout le reste marche pareil dès que tu ouvres le bon dossier.

Le reste de cette leçon, c'est juste ça : te connecter avec ton abonnement, puis rebrancher ces deux choses en laissant l'IA faire le travail.

Étape 1 : Se connecter avec ton abonnement ChatGPT

C'est le gros intérêt de Codex : tu te connectes avec ton compte ChatGPT (login), pas avec une clé API facturée au token.

Au premier lancement, tape codex, puis choisis Sign in with ChatGPT. Ton navigateur s'ouvre, tu autorises, c'est réglé. Codex tourne alors dans le cadre de ton abonnement Plus / Pro / Business, sans surcoût au token.

Pourquoi ça compte : l'autre méthode, c'est une clé API OpenAI facturée à chaque token consommé, et ça chiffre vite. Avec le login ChatGPT, tu réutilises l'abonnement que tu paies déjà. Pour le détail abonnement vs API, voir Structure des coûts →.

Étape 2 : Installer et lancer Codex dans ton coffre

Codex CLI s'installe en une commande :

# macOS / Linux (installeur officiel)
curl -fsSL https://chatgpt.com/codex/install.sh | sh

# ou via npm (multi-plateforme)
npm install -g @openai/codex

# ou via Homebrew (macOS)
brew install --cask codex

Sur Windows :

powershell -ExecutionPolicy ByPass -c "irm https://chatgpt.com/codex/install.ps1 | iex"

Ensuite tu ouvres Codex dans le dossier où tu veux travailler (c'est le principe le plus important : l'IA voit ce qui est dans le dossier où tu la lances) :

# Va dans ton Workspace racine, puis lance Codex
cd ~/Documents/WORKSPACE && codex

Codex lit l'AGENTS.md à la racine (son fichier d'instructions natif) et a accès à tout ton coffre.

Astuce : crée un alias cox dans ton .zshrc : alias cox="cd ~/Documents/WORKSPACE && codex". Tu tapes cox de n'importe où, tu atterris dans ton coffre avec Codex lancé.

Étape 3 : Rebrancher tes MCP (laisse ton IA le faire)

Tu as déjà tes MCP configurés dans Claude Code ou OpenCode. Pas besoin de tout refaire à la main : demande à ton IA de les transvaser dans Codex. Colle-lui ce prompt :

J'utilise déjà des MCP dans Claude Code et/ou OpenCode. Reprends ma
configuration MCP existante et transvase-la dans Codex, dans mon fichier
~/.codex/config.toml au niveau user (global), pour que ces MCP soient
actifs dans tous mes projets. Vérifie ensuite avec "codex mcp list".

L'IA regarde ta config existante, la traduit au format de Codex, et c'est fonctionnel.

Où c'est rangé ? Codex stocke ses MCP dans un fichier config.toml, à deux niveaux possibles :

• ~/.codex/config.toml (niveau ordinateur, recommandé) : tes MCP sont dispos dans toutes tes sessions, quel que soit le dossier.
• .codex/config.toml dans un projet : des MCP actifs uniquement pour ce projet (pratique pour séparer un MCP pro d'un MCP perso).

L'app Codex a aussi un onglet Plug-ins où tu peux voir et ajouter des MCP à la main. Mais le plus rapide reste de laisser l'IA s'auto-configurer : elle sait le faire, autant ne pas perdre de temps avec ça.

Étape 4 : Rebrancher tes skills (un simple symlink)

Petit piège à comprendre. Dans OpenCode, tu peux ranger tes skills où tu veux : le fichier opencode.json déclare le chemin, et l'IA va les chercher là. C'est parfait, tu synchronises tes skills comme tu veux.

Codex, lui (comme Claude Code et ChatGPT), ne fonctionne pas comme ça : il ne regarde les skills qu'à un seul endroit imposé, .agents/skills. Si tes skills sont ailleurs (dans Second Cerveau/4 TOOLS/skills, la convention du bootcamp), Codex ne les voit pas.

La solution, c'est la même que pour Claude Code : un symlink (un lien miroir) entre .agents/skills et ton vrai dossier de skills. Fais-le faire par ton IA, colle-lui ce prompt :

Crée un symlink pour que Codex voie mes skills. Mes skills sont dans
"Second Cerveau/4 TOOLS/skills" à la racine de mon Workspace. Crée un lien
symbolique ".agents/skills" qui pointe vers ce dossier (au niveau du
Workspace, ou dans ~/.agents/skills si tu veux qu'ils soient dispos dans
TOUS mes projets). Vérifie ensuite que le lien pointe au bon endroit.

Une fois le symlink créé, Codex croit qu'il y a des skills rangés dans .agents/skills, alors qu'en réalité ils vivent dans ton coffre. Tu tapes /skills (ou $ pour mentionner un skill par son nom) dans Codex, tu vois ta liste.

La philosophie du bootcamp : évite de ranger tes skills directement dans .agents/skills. Sinon ils restent coincés dans Codex / ChatGPT. Mieux vaut qu'ils restent transverses, dans ton second cerveau, dispos pour n'importe quel agent via le symlink. Ton système reste souverain, pas prisonnier d'un outil.

Récap

Retiens le principe : quel que soit l'agent vers lequel tu vas (Claude Code, Codex, un autre), les deux seules choses à rebrancher sont les MCP et les skills. Chacun a ses conventions pour ces deux-là. Le reste, tu ouvres dans le bon dossier et ça fonctionne.

• Je sais quand utiliser Codex (abonnement ChatGPT + boucle agentique GPT dans mon terminal)
• Codex CLI installé (npm install -g @openai/codex, Homebrew, ou l'installeur officiel)
• Je me connecte avec Sign in with ChatGPT (mon abonnement, pas une clé API facturée au token)
• Mes MCP rebranchés : config transvasée par l'IA dans ~/.codex/config.toml
• Mes skills rebranchés : symlink .agents/skills → Second Cerveau/4 TOOLS/skills
• Codex lancé depuis mon Workspace : je vois mes skills via /skills ou $

Sources

• Codex CLI (installation + connexion ChatGPT)
• Connecter Codex à des outils via MCP
• Créer et connecter des skills à Codex
• Configuration de base (config.toml)
• Dépôt open source Codex (openai/codex)

Le problème des secrets (plus petit qu'on ne croit)

Tu accumules des API keys, des tokens, des mots de passe. Anthropic, OpenAI, Telegram, Cloudron, NocoDB, PocketBase... Au début tu les mets dans un .env, puis dans une note, puis dans un message Telegram "pour ne pas oublier".

Avant de sortir l'artillerie lourde, dédramatisons. La dernière promo a perdu un temps fou à installer et configurer Bitwarden. Dans la grande majorité des cas, tu n'en as pas besoin.

Le vrai risque, ce n'est pas d'avoir une clé en clair dans un fichier. C'est qu'elle fuite vers l'extérieur. Tant que tes secrets restent dans ton coffre chiffré de bout en bout (Obsidian Sync) et sur ton disque, tu es tranquille.

Les patterns de fuite qui comptent vraiment :

1. Un .env commité sur un repo git public
2. Une clé collée dans un chat public (session ChatGPT partagée, Discord, forum)
3. Un secret affiché par l'IA dans une réponse que tu partages ensuite publiquement
4. Un .env envoyé en copier-coller par email ou messagerie non chiffrée

Ce qui n'est PAS un drame : une clé en clair dans .env, opencode.json ou une note, tant que ton coffre est chiffré E2E via Obsidian Sync. C'est le cas par défaut si tu as suivi le bootcamp.

La hiérarchie recommandée

La règle fondamentale : séparer l'inventaire du coffre. L'inventaire dit ce qui existe. Le coffre contient les valeurs secrètes.

En résumé : Infrastructure.md dit "j'ai un compte Anthropic à tel email", sans jamais contenir la valeur. La clé API, elle, vit soit en clair dans ton coffre Obsidian chiffré E2E (le plus simple), soit dans un password manager si tu veux un cran de plus. L'important : elle n'est jamais exposée dans un espace public.

Les niveaux de setup

Choisis selon ta situation. Pour la majorité des participants, le niveau 0 suffit largement. Les niveaux suivants sont optionnels, pour ceux qui veulent un cran de plus ou qui gèrent des données client très sensibles.

Niveau 0 : Clés en clair dans ton coffre chiffré E2E (recommandé par défaut)

C'est le setup que j'utilise personnellement. Je n'utilise pas Bitwarden. Mon coffre est synchronisé avec Obsidian Sync, donc chiffré de bout en bout, et mes clés vivent en clair dedans. Rien ne fuite tant que je ne pousse pas ça sur un repo public ou dans un chat public.

Les 2 garde-fous : .env dans .gitignore, et jamais de clé dans un espace public. C'est tout.

Niveau 1 : Bitwarden (optionnel, pour centraliser)

Setup :

1. Crée un compte sur bitwarden.com (gratuit)
2. Installe l'extension navigateur
3. Pour chaque API key, crée une entrée dans Bitwarden avec le nom du service et la valeur

Pour les plus techniques — Bitwarden a un CLI (bw) et un MCP server officiel qui permet à ton IA de récupérer des secrets de manière sécurisée :

# Installer le CLI Bitwarden
npm install -g @bitwarden/cli

# Se connecter
bw login

# Récupérer un secret
bw get item "Anthropic API Key" | jq -r '.login.password'

Niveau 2 : macOS Keychain (Mac users)

Stocker un secret :

# Ajouter une API key au Keychain
security add-generic-password \
  -a "mon-compte" \
  -s "ANTHROPIC_API_KEY" \
  -w "sk-ant-api03-xxxxx" \
  -T ""

Récupérer un secret :

# Lire la valeur
security find-generic-password \
  -s "ANTHROPIC_API_KEY" \
  -w

Utiliser dans un .env :

# Script qui génère le .env à partir du Keychain
echo "ANTHROPIC_API_KEY=$(security find-generic-password -s ANTHROPIC_API_KEY -w)" > .env

L'avantage : rien ne quitte ta machine. L'inconvénient : c'est local — si tu as un serveur distant, les secrets ne sont pas synchronisés.

Niveau 3 : Vaultwarden (auto-hébergé)

Si tu as déjà un serveur Cloudron (semaine 3), Vaultwarden est disponible dans l'App Store Cloudron en un clic. Sinon, voici le docker-compose :

services:
  vaultwarden:
    image: vaultwarden/server:latest
    container_name: vaultwarden
    restart: unless-stopped
    ports:
      - "8080:80"
    volumes:
      - vaultwarden-data:/data
    environment:
      DOMAIN: "https://vault.ton-domaine.com"

volumes:
  vaultwarden-data:

Une fois lancé, tu accèdes à l'interface web sur https://vault.ton-domaine.com, tu crées ton compte, et tu utilises les mêmes clients Bitwarden (extension navigateur, app mobile, CLI) — ils sont compatibles.

Comparatif

Ma recommandation : reste au niveau 0. Des clés en clair dans un coffre chiffré E2E (Obsidian Sync) couvrent l'immense majorité des besoins, et c'est ce que j'utilise moi-même. Si un jour tu gères des données client très sensibles ou tu veux centraliser proprement, Bitwarden (niveau 1) est le meilleur point de départ, et la migration vers Vaultwarden reste transparente (mêmes clients, mêmes données).

Le fichier Infrastructure.md

C'est ton registre — l'inventaire de tout ce qui tourne, sans les valeurs secrètes. Il vit dans ton vault Obsidian (par exemple 4 TOOLS/Infrastructure.md ou 2 CASQUETTES/[ta casquette tech]/Infrastructure.md).

Structure recommandée

# Infrastructure

## Serveurs
| Service | URL | Usage |
|---------|-----|-------|
| Serveur principal | 65.xxx.xxx.xx | Cloudron, apps |
| Cloudron | https://my.domaine.com | Panel admin |

## APIs & Services
| Service | Email du compte | Usage | Secret dans |
|---------|----------------|-------|-------------|
| Anthropic | mon@email.com | Claude API | Coffre .env (E2E) |
| OpenAI | mon@email.com | Whisper, GPT | Coffre .env (E2E) |
| Telegram Bot | - | Bot IA perso | Bitwarden |

## Bases de données
| Service | URL | Usage |
|---------|-----|-------|
| NocoDB | https://nocodb.domaine.com | Données clients |
| PocketBase | https://backend.domaine.com | Auth plateforme |

## Domaines
| Domaine | Registrar | Usage |
|---------|-----------|-------|
| mon-domaine.com | OVH | Site principal |

Ce qui est dans ce fichier : les noms, les URLs, les emails de compte, les usages. L'IA peut lire ce fichier pour savoir quels services existent.

Ce qui n'est PAS dans ce fichier : les API keys, les tokens, les mots de passe. Jamais. La colonne "Secret dans" indique où trouver la valeur (ton coffre .env, Bitwarden, Keychain...), pas la valeur elle-même.

Bonnes pratiques .env

Règle 1 : .env dans .gitignore

Toujours. Sans exception. Vérifie maintenant :

# Vérifier que .env est ignoré
cat .gitignore | grep -i env

Si ce n'est pas le cas, ajoute :

# Secrets
.env
.env.local
.env.*.local

Règle 2 : Créer un .env.example

Le .env.example contient les noms des variables sans les valeurs. Il est commité sur git — c'est la documentation de quelles variables sont nécessaires :

# .env.example — les noms sans les valeurs
ANTHROPIC_API_KEY=
OPENAI_API_KEY=
TELEGRAM_BOT_TOKEN=
NOCODB_URL=
NOCODB_TOKEN=

Quand tu installes le projet sur une nouvelle machine, tu copies .env.example vers .env et tu remplis les valeurs.

Règle 3 : Ne jamais commiter un .env

Si tu as déjà commité un .env par erreur :

# Retirer le fichier du tracking git (sans le supprimer)
git rm --cached .env
git commit -m "remove .env from tracking"

Attention : si le .env a été poussé sur un remote public (GitHub, GitLab), les secrets sont compromis. Change toutes les clés API qui étaient dedans. Sur un remote privé ou chiffré le risque est bien plus faible, mais par précaution, change-les quand même.

Pattern avancé (optionnel) : références au password manager

Uniquement si tu utilises un password manager (niveau 1 ou 3). Au lieu de laisser les valeurs en clair dans .env, tu peux les injecter depuis le coffre au moment voulu :

# Script setup-env.sh — génère le .env depuis Bitwarden
#!/bin/bash
bw unlock --check || bw unlock

echo "ANTHROPIC_API_KEY=$(bw get password 'Anthropic API Key')" > .env
echo "TELEGRAM_BOT_TOKEN=$(bw get password 'Telegram Bot')" >> .env
echo "NOCODB_TOKEN=$(bw get password 'NocoDB Token')" >> .env

echo "✓ .env généré depuis Bitwarden"

Tu lances ./setup-env.sh une fois, et ton .env est rempli. Le script peut être commité (il ne contient aucun secret), le .env généré ne l'est jamais.

Checklist

• J'ai créé ou mis à jour mon fichier Infrastructure.md (sans valeurs secrètes)
• J'ai choisi mon niveau de setup (clés en clair dans coffre E2E par défaut, password manager si besoin)
• Mes clés API sont dans un coffre chiffré E2E (Obsidian Sync) ou un password manager, jamais dans un espace public
• Mes fichiers .env sont dans .gitignore
• J'ai un .env.example avec les noms des variables (sans valeurs)