OpenCode 2.0 vs Claude Code : faut-il migrer sur Mac ?

Le premier blocage : confondre choix du modèle et remplacement de l’agent

La décision dépend d’abord de l’objectif recherché. Trois situations sont souvent mélangées :

• Changer de modèle : conserver le même agent, mais sélectionner un autre modèle ou un autre point d’accès.
• Réduire la dépendance à un fournisseur : utiliser plusieurs fournisseurs, une clé API personnelle, une passerelle interne ou un modèle local.
• Remplacer toute la chaîne de travail : changer l’agent, les permissions, les commandes, les extensions, les habitudes de reprise et la procédure de validation.

OpenCode 2.0 répond surtout au deuxième objectif. Sa documentation bêta indique qu’il peut être connecté à différents fournisseurs avec une clé API, une authentification OAuth ou une variable d’environnement. Les identifiants saisis dans la commande de connexion sont stockés par le service OpenCode ; une clé présente dans un fichier de configuration doit donc être remplacée par une variable d’environnement et ne doit jamais être validée dans Git. (documentation des fournisseurs OpenCode)

Claude Code propose également plusieurs chemins d’authentification : la console Anthropic, les forfaits Claude Pro ou Max, ainsi que des environnements d’entreprise comme Amazon Bedrock ou Google Vertex AI. Le choix n’est donc pas simplement « outil ouvert contre outil fermé » ; il porte aussi sur le niveau de centralisation, la facturation et le support que l’équipe accepte. (guide officiel d’installation de Claude Code)

Pour un projet livré à des clients, la stabilité du parcours compte davantage que la possibilité de sélectionner un modèle supplémentaire. Si la migration impose de réécrire des règles, de vérifier des extensions ou de corriger des commandes d’automatisation, le coût de transition peut dépasser l’économie attendue sur les appels de modèle.

Le deuxième blocage : un coût affiché ne représente pas le coût d’une tâche

OpenCode 2.0 peut rendre la facturation plus modulable, mais cette souplesse déplace une partie du travail vers l’utilisateur. Il faut choisir le fournisseur, conserver les clés, surveiller les limites, contrôler les modèles réellement utilisés et expliquer les écarts de consommation.

Claude Code offre une trajectoire plus prévisible pour les usages individuels. La page tarifaire officielle indique un accès Pro à 20 $ par mois en facturation mensuelle, un accès Max à partir de 100 $ par personne et par mois, ainsi qu’une tarification séparée à l’usage pour certains comptes d’équipe et d’entreprise. Ces montants doivent être vérifiés avant publication ou achat, car les taxes, la région et les conditions d’abonnement peuvent modifier le montant affiché. (tarification officielle d’Anthropic)

Avec une API, le calcul devient différent : une tâche consomme des entrées, des sorties, des reprises, des résumés de contexte et parfois des appels supplémentaires provoqués par un échec. La grille officielle Anthropic publiée pour mai 2026 donne, à titre d’exemple, des tarifs par million de jetons qui varient selon le modèle, la région, la mise en cache et le mode de traitement. Comparer uniquement le prix d’un million de jetons ne permet donc pas de conclure sur la rentabilité d’un agent. (grille tarifaire API publiée par Anthropic)

La comparaison correcte doit utiliser un même dépôt et une même tâche :

1. relever le nombre de fichiers touchés ;
2. noter les appels ou crédits consommés ;
3. compter les tentatives supplémentaires ;
4. enregistrer le temps passé à examiner les changements ;
5. inclure le coût d’une correction manuelle après échec ;
6. vérifier si la construction et les tests finaux passent réellement.

Un outil moins cher par appel peut devenir plus coûteux si l’agent oublie le contexte, répète une modification ou exige plusieurs interventions humaines.

Le troisième blocage : la récupération après échec

La première génération réussie est une mesure trompeuse pour un agent terminal. Dans un dépôt réel, une tâche traverse souvent plusieurs fichiers, des tests, des dépendances et des commandes Git. Le critère important est la capacité à reprendre sans perdre la logique déjà validée.

Claude Code documente des commandes de continuation et de reprise d’une session, notamment claude -c, claude --continue et claude --resume. Il propose aussi un mode de planification et des limites de tours dans les exécutions non interactives. Ces mécanismes ne garantissent pas qu’une tâche réussira, mais ils donnent une structure explicite pour reprendre une session interrompue. (utilisation de l’interface en ligne de commande Claude Code)

OpenCode 2.0 dispose également d’agents distincts, de permissions ordonnées et de connexions à plusieurs fournisseurs. Cependant, sa documentation précise que la bêta peut encore casser des fonctions, modifier les interfaces de programmation ou effacer des données. Pour cette raison, une équipe ne devrait pas considérer une démonstration réussie comme une preuve de stabilité opérationnelle.

La tâche de comparaison doit être volontairement peu spectaculaire : modifier une fonctionnalité répartie sur plusieurs fichiers, ajouter un test, exécuter la suite concernée, produire un diff et revenir à l’état précédent. Le journal doit distinguer :

• la planification correcte ;
• la modification réellement appliquée ;
• les commandes exécutées ;
• les erreurs de test ;
• le nombre de reprises humaines ;
• la méthode de retour arrière ;
• la capacité à continuer après une interruption réseau ou une limite de contexte.

Sans données issues d’une même tâche et d’un même dépôt, les jugements de communauté sur la vitesse ou la qualité restent des pistes de test, pas des conclusions.

Les permissions : le point où une migration peut créer un incident

OpenCode 2.0 remplace plusieurs éléments de configuration de la première génération. La documentation V2 utilise notamment permissions à la place de permission, shell à la place de bash, subagent à la place de task, et edit pour couvrir plusieurs opérations de modification. Une ancienne configuration peut donc sembler lisible tout en ne produisant plus le comportement attendu. (permissions dans OpenCode 2.0)

Le modèle de permission V2 repose sur une liste ordonnée de règles. Les ressources peuvent désigner un chemin, une commande, une URL, une requête ou un identifiant d’agent. Les répertoires externes demandent une décision distincte, tandis que le shell s’exécute avec les droits du compte macOS utilisé. Une règle trop large sur les commandes shell peut donc donner à l’agent une autorité bien plus étendue que prévu.

Claude Code propose de son côté des listes d’outils autorisés ou interdits, des répertoires supplémentaires et des modes de permission. La documentation signale explicitement que le contournement total des demandes de permission doit être utilisé avec prudence. (permissions et sécurité dans Claude Code)

Pour un projet personnel, la base minimale devrait être :

• dépôt placé dans un répertoire de travail isolé ;
• fichiers .env et certificats refusés par défaut ;
• écriture limitée au dépôt ;
• commandes de lecture Git autorisées ;
• git push, suppression de fichiers et publication interdits sans confirmation ;
• aucun accès automatique aux répertoires de documents personnels ;
• clés stockées dans le trousseau ou dans l’environnement, jamais dans le dépôt.

Pour un dépôt d’équipe, il faut ajouter une validation humaine avant toute migration de dépendance, tout accès à un répertoire externe, toute commande réseau et toute modification de configuration de signature. L’objectif n’est pas de supprimer toute automatisation, mais de rendre chaque élargissement de périmètre observable.

Les données : un client ouvert ne signifie pas un traitement local

OpenCode 2.0 permet de connecter plusieurs fournisseurs, mais le client ne détermine pas à lui seul le parcours des données. Dès qu’un modèle distant est sélectionné, les invites, les extraits de code nécessaires et les réponses transitent vers le fournisseur ou vers la passerelle configurée.

Claude Code s’exécute localement, mais sa documentation indique que les invites et les sorties de modèle sont envoyées sur le réseau pour le traitement par le modèle. Anthropic précise aussi qu’une organisation peut utiliser une clé API avec conservation nulle des données afin que les transcriptions ne soient pas conservées sur ses serveurs, tandis que des sessions peuvent rester stockées localement pour permettre leur reprise. (utilisation des données dans Claude Code)

Pour OpenCode 2.0, la configuration d’un fournisseur peut utiliser une variable d’environnement, une clé stockée via la commande de connexion ou un point d’accès personnalisé. Le contrôle réel dépend alors de la chaîne complète : client, service de routage, fournisseur de modèle, journaux de requêtes et politique de conservation.

La grille de contrôle à appliquer avant une migration est la suivante :

• Si le code ne peut pas quitter le poste, il faut utiliser un modèle local réellement vérifié ou conserver un outil et un fournisseur autorisés par la politique de l’organisation.
• Si plusieurs modèles sont nécessaires, OpenCode 2.0 peut être essayé, mais chaque fournisseur doit avoir sa propre clé, sa propre limite et sa propre politique de conservation.
• Si le projet exige une traçabilité centralisée, une passerelle ou une plateforme d’entreprise peut être préférable à plusieurs clés personnelles.
• Si le fournisseur est changé pour réduire le coût, il faut vérifier que les prompts, les journaux et les sorties ne sont pas envoyés à un intermédiaire non approuvé.

macOS, terminal et Xcode : trois usages qui ne se confondent pas

Claude Code prend officiellement en charge macOS 10.15 ou une version ultérieure, demande au moins 4 Go de mémoire vive, Node.js 18 ou une version plus récente et une connexion Internet pour l’authentification et le traitement par l’IA. OpenCode 2.0 s’installe actuellement via un paquet bêta et utilise le binaire opencode2, sans remplacer le binaire opencode de la première génération. Les deux peuvent donc être conservés côte à côte pour une phase de comparaison. (conditions d’installation de Claude Code)

Une installation de test peut rester volontairement séparée :

mkdir -p ~/ai-agent-lab/projet-test
cd ~/ai-agent-lab/projet-test

npm install -g @opencode-ai/cli@next
opencode2

La commande d’installation et l’absence actuelle de méthode Homebrew pour la bêta sont documentées par OpenCode. L’installation ne doit toutefois pas être confondue avec une intégration Xcode finalisée.

Dans un projet iOS ou macOS, l’agent peut lire le code, modifier des fichiers Swift, préparer une commande Git ou proposer une correction de test. Il ne remplace pas automatiquement :

• la gestion des certificats et des profils ;
• la signature du projet ;
• la sélection de l’équipe Apple ;
• le lancement du simulateur ;
• l’archivage ;
• la vérification des capacités et des entitlements ;
• l’acceptation finale dans Xcode.

OpenCode 2.0 peut donc accompagner un projet Xcode depuis le terminal, mais la chaîne de livraison doit être validée dans l’environnement Apple complet. La même limite s’applique à un usage créatif : un agent peut préparer un script audio, une logique d’export vidéo ou une automatisation de fichiers, sans se substituer aux vérifications de Final Cut Pro, Logic Pro ou des outils de design utilisés pour la livraison.

Pour une équipe sans Mac disponible en permanence, un environnement distant peut servir à isoler l’essai, installer les deux agents et effectuer la construction finale. Une configuration Mac distante pour les tests de développement est pertinente lorsque le besoin porte sur une session temporaire, tandis qu’un poste local reste préférable pour les périphériques physiques, les essais caméra, les appareils iOS connectés et les tâches quotidiennes intensives.

La méthode de double usage sur une semaine

La migration doit être traitée comme une expérience contrôlée, non comme un changement de préférence. Le dépôt de test doit être une copie récente du projet, avec un état Git propre, des secrets retirés et une procédure de construction écrite avant le premier essai.

Le protocole peut suivre ces étapes :

1. Préparer l’environnement : relever la version de macOS, de Node.js, de Git, de Xcode et des deux agents.
2. Créer deux branches : une branche de référence pour Claude Code et une branche d’essai pour OpenCode 2.0.
3. Définir cinq tâches représentatives : correction multi-fichier, ajout de test, changement d’API, refactorisation limitée et correction d’un problème de construction.
4. Rédiger les mêmes consignes : même contexte, mêmes fichiers de départ, même objectif et même critère d’acceptation.
5. Enregistrer chaque action : modèle, fournisseur, durée observée, erreurs, commandes, demandes de permission et interventions humaines.
6. Tester la reprise : interrompre une tâche après une modification partielle, puis mesurer la capacité à reprendre sans repartir de zéro.
7. Valider dans Xcode : compilation, tests ciblés, signature, simulateur et archivage lorsque le projet l’exige.
8. Comparer les retours arrière : identifier si le diff peut être annulé proprement et si les fichiers générés restent maîtrisables.
9. Calculer le coût complet : abonnement ou appels, temps de supervision, corrections manuelles et maintien de la configuration.
10. Décider par dépôt : ne pas migrer toute l’organisation si un seul type de projet satisfait les critères.

Le choix peut être formulé ainsi :

• Si OpenCode 2.0 réussit les tâches critiques, garde une facture explicable, respecte les permissions et passe la validation Xcode, il peut être introduit d’abord sur les dépôts secondaires.
• Si le coût baisse mais que les reprises humaines, les régressions ou les changements de configuration augmentent, il faut conserver le double usage.
• Si la priorité est une livraison stable avec support unifié, Claude Code reste le choix de référence.
• Si le besoin principal est de varier les modèles ou de connecter un fournisseur interne, OpenCode 2.0 mérite un essai isolé, mais pas une migration irréversible.

La grille de décision avant migration

Les trois tableaux ci-dessous séparent les faits documentés, les coûts à mesurer et la décision opérationnelle. Ils ne remplacent pas un test sur le dépôt réel.

Le verdict pour les développeurs Mac en 2026

OpenCode 2.0 ne peut pas encore être considéré comme un remplacement général de Claude Code. La documentation officielle le décrit comme une bêta susceptible de changer, tandis que son installation séparée rend justement possible une stratégie plus prudente : conserver l’outil actuel, installer la nouvelle version à côté et comparer les mêmes tâches sur le même code.

Pour une équipe qui privilégie l’ouverture, le BYOK, le routage entre modèles ou l’expérimentation avec un modèle local, OpenCode 2.0 est un candidat sérieux pour une phase de double usage. Pour un projet livré régulièrement, soumis à des règles de sécurité ou dépendant d’une reprise fiable après erreur, Claude Code doit rester la référence tant que les résultats propres au dépôt n’ont pas démontré le contraire.

Le remplacement d’un agent terminal par un autre ne résout pas automatiquement les limites de coût : il peut les déplacer vers la surveillance des API, les erreurs de configuration, les permissions trop larges et le temps de correction. De même, une installation sur macOS ne transforme pas OpenCode 2.0 ou Claude Code en solution complète pour signer, tester et publier une application Xcode.

Si le Mac principal ne doit pas être modifié, le meilleur compromis consiste à isoler l’essai sur une machine distante, à y conserver les branches de test et à vérifier la construction finale dans un environnement Mac complet. NodeMini peut servir de support pour cette phase temporaire grâce à une location de Mac distant pour un environnement de développement isolé. Pour les projets qui nécessitent une présence régionale spécifique, les options de Mac distant en Virginie peuvent également être examinées avant de choisir le lieu d’exécution.

La recommandation finale reste donc conditionnelle : conserver Claude Code pour les projets stables, tester OpenCode 2.0 en double pour réduire la dépendance aux modèles, puis migrer dépôt par dépôt uniquement après validation du coût, des permissions, de la reprise et de Xcode.