L’annonce officielle indique que l’environnement auto-hébergé Claude Code est en bêta publique, réservé aux organisations Team et Enterprise, désactivé par défaut et indisponible aux organisations sous ZDR (conditions et périmètre annoncés). Ne commandez donc pas de Mac au seul motif que vous envisagez l’auto-hébergement.
Symptôme → le cloud ne répond pas à une exigence vérifiable de réseau, de gouvernance ou d’accès aux outils. Solution rapide → évaluez un Runner autogéré, mais ne prévoyez un Mac qu’après confirmation de la compatibilité de la plateforme et validation réelle des tâches Xcode.
Dernière mise à jour : 25 septembre 2026. Les conditions de bêta, d’éligibilité et de prise en charge doivent être vérifiées avant publication auprès de l’annonce et de la documentation officielles de Claude Code ainsi que de la documentation Apple sur les agents externes et Xcode.
Cet article s’adresse à vous si : Vous êtes responsable IT et devez arbitrer entre réseau, frontières de données et responsabilités d’exploitation. Vous dirigez une équipe plateforme ou Apple et devez valider des Runners, des tâches Xcode ou une chaîne Mac CI.
Distinguez les trois modes avant de choisir
Le cloud, l’environnement auto-hébergé et Remote Control ne décrivent pas trois niveaux d’une même machine. Ils déterminent où s’exécute le travail, qui administre l’environnement et si la session dépend d’une machine personnelle. Confondre ces modes conduit à acheter une capacité inadaptée ou à traiter une session de développeur comme un Runner partagé.
| Mode | Où s’exécute la session ou le Runner ? | Responsabilité opérationnelle | Adéquation indicative |
|---|---|---|---|
| Cloud géré | Dans l’environnement géré par le fournisseur | L’équipe vérifie les politiques et les accès, sans administrer le Runner sous-jacent | Forte si les exigences réseau et de gouvernance sont satisfaites |
| Environnement auto-hébergé | Sur l’infrastructure contrôlée par l’organisation, selon le mode déployé | L’équipe prend en charge le déploiement, la capacité, les mises à jour et la surveillance | Forte si une contrainte impose un environnement d’exécution sous contrôle interne |
| Remote Control | La session reste associée à l’environnement de l’utilisateur qui l’a démarrée | L’utilisateur conserve la responsabilité de sa machine et de la session | Faible comme substitut à un Runner d’équipe partagé |
Quand le cloud reste-t-il le meilleur choix ?
Si les équipes peuvent utiliser le cloud sans enfreindre leurs règles de réseau, de gouvernance ou de traitement des données, commencez par ce mode. Vous évitez alors d’ajouter à votre périmètre l’exploitation d’un Runner, la maintenance de son image, la gestion de sa capacité et le traitement de ses incidents. Cela ne signifie pas que le cloud convient à toutes les politiques internes : votre responsable sécurité doit vérifier les flux et les contrôles réels, pas seulement l’étiquette du produit.
Remote Control peut-il remplacer un Runner partagé ?
Non. Remote Control sert à continuer une session liée à l’environnement de son utilisateur ; il ne transforme pas, à lui seul, une machine personnelle en service d’exécution partagé, administré et disponible pour une chaîne CI. La distinction compte pour les droits d’accès, la continuité après le départ d’un collaborateur, la traçabilité des tâches et la gestion des secrets. Si votre objectif est de fournir un Runner durable à une équipe, évaluez le modèle auto-hébergé et ses prérequis de déploiement plutôt que de bâtir votre conception autour d’une session personnelle.
Vérifiez la prise en charge Runner avant de concevoir l’infrastructure
Une annonce d’auto-hébergement n’est pas une confirmation que chaque système d’exploitation, machine ou outil est pris en charge. Avant une demande d’achat, consignez le système visé, le mode Runner documenté, les dépendances et la personne qui assumera son cycle de vie. La documentation de déploiement en production doit guider la vérification des modes de déploiement et des opérations ; elle ne doit pas être interprétée comme une validation implicite de votre environnement Mac.
| Vérification | Ce que l’équipe doit établir | Décision si l’information manque |
|---|---|---|
| Système d’exploitation et exécution | Le système et le mode d’exécution visés sont-ils explicitement pris en charge dans la documentation actuelle ? | Ne pas acheter ni intégrer la plateforme sur la seule base de l’annonce générale |
| Images et mises à jour | Qui construit, corrige, publie et contrôle les images du Runner ? | Attribuer un propriétaire et une procédure avant le pilote |
| Capacité | Le mode choisi est-il fixe ou à la demande, et qui configure l’orchestration ? | Documenter l’allocation, la limite de capacité et le comportement en cas d’indisponibilité |
| Accès et identité | Comment les utilisateurs, sessions et droits sont-ils rattachés à l’organisation ? | Faire valider les rôles et la traçabilité par les responsables plateforme et sécurité |
Le Runner auto-hébergé prend-il en charge macOS ?
Ne le présumez pas. La prise en charge de l’auto-hébergement et la prise en charge explicite de macOS sont deux affirmations différentes : au moment de votre décision, recherchez une confirmation précise dans la documentation officielle et faites-la valider pour la version et le mode que vous voulez utiliser. Si la documentation ne confirme pas macOS, classez le point comme « non vérifié » ; une démonstration sur une autre plateforme ne lève pas ce doute.
Votre responsable plateforme doit consigner la version de la documentation consultée, le système d’exploitation, le mode Runner et toute restriction applicable. Si la réponse est absente ou ambiguë, demandez une clarification officielle avant d’engager l’achat d’un hôte Mac ou d’annoncer une capacité de production. Cette étape protège aussi les équipes d’exploitation : une infrastructure correctement provisionnée ne compense pas une plateforme qui n’est pas officiellement adaptée à l’usage prévu.
**Point de vigilance :** une connexion réussie prouve seulement qu’une session a démarré dans les conditions testées. Elle ne prouve ni la prise en charge formelle de votre système d’exploitation, ni la stabilité sous charge, ni la compatibilité avec les outils de compilation de votre organisation.
Séparez les exigences de sécurité des hypothèses sur la résidence des données
« Auto-hébergé » décrit l’emplacement d’exécution du Runner, pas nécessairement l’emplacement de chaque donnée échangée avec le modèle. Pour votre analyse, séparez au minimum le dépôt et ses copies de travail, les artefacts produits, les secrets accessibles au Runner, ainsi que les prompts, réponses et résultats d’outils transmis pour l’inférence. La documentation du modèle auto-hébergé est le point de départ pour cartographier les flux ; les contrôles de conservation doivent être examinés séparément.
| Élément à tracer | Question à poser | Responsable principal |
|---|---|---|
| Code et fichiers de travail | Quelles copies sont créées dans l’environnement d’exécution et qui peut les lire ? | Plateforme et sécurité |
| Prompts, réponses et résultats d’outils | Quelles données sont envoyées pour l’inférence et quelles règles de traitement s’appliquent ? | Sécurité et gouvernance de l’IA |
| Secrets de compilation | Le Runner peut-il lire des clés, certificats ou jetons, et comment l’accès est-il limité ? | Équipe Apple et sécurité |
| Historique et conservation | Quelles politiques organisationnelles, exceptions et durées s’appliquent au compte concerné ? | Administrateur de l’organisation |
Pour une revue exploitable, demandez à chaque équipe de répondre à une question distincte : la sécurité confirme-t-elle les flux et les secrets ; la gouvernance confirme-t-elle la conservation et les exceptions ; la plateforme confirme-t-elle l’identité et les journaux ; l’équipe Apple confirme-t-elle que les certificats et artefacts sont séparés des usages de développement ordinaires ? Si une réponse dépend d’une hypothèse non documentée, traitez-la comme un blocage, pas comme une décision déjà validée.
Délimitez Claude Code et les tâches Xcode
Claude Code peut intervenir dans des activités d’analyse ou de modification de code, mais cela ne prouve pas que son Runner puisse réaliser les tâches natives de votre chaîne Apple. Classez les opérations selon leurs dépendances : revue du code et travaux génériques d’un côté ; compilation macOS, utilisation de Xcode ou du simulateur, et signature de l’autre. La deuxième catégorie réclame un environnement Apple approprié et des accès aux certificats gérés avec soin.
L’environnement auto-hébergé peut-il exécuter une compilation Xcode ?
Seulement après vérification de la prise en charge de la plateforme Runner et validation de bout en bout de votre pipeline. Apple documente l’accès d’agents externes aux outils Xcode dans sa documentation consacrée à cette intégration. Cette documentation décrit une possibilité d’intégration avec Xcode ; elle ne confirme pas, à elle seule, que le Runner auto-hébergé de Claude Code prend en charge macOS, Xcode ou votre processus de signature.
L’équipe Apple doit donc valider séparément l’environnement d’exécution, les outils disponibles, le profil de signature, l’accès aux secrets, la production de l’artefact attendu et le transfert vers les étapes suivantes. Tant que ces vérifications ne sont pas faites, gardez la compilation Xcode hors du périmètre de production de l’Agent. Si un vrai Mac est nécessaire, comparez les options de nœud dédié et de Mac distant en tenant compte des exigences d’accès et d’isolement ; la page des solutions Mac proposées par MACGPU peut servir à examiner une piste de capacité, mais ne remplace pas la validation de compatibilité du Runner.
Comparez le coût complet et attribuez chaque charge
Un tarif d’utilisation cloud et le coût d’un Runner autogéré ne couvrent pas nécessairement les mêmes postes. Sans prix officiel vérifié pour votre plan et sans mesures internes de charge, annoncer un pourcentage d’économie serait trompeur. Construisez plutôt le calcul avec les données de votre contrat, de votre inventaire et du temps d’exploitation réellement mobilisé.
| Poste à renseigner | Cloud | Auto-hébergement |
|---|---|---|
| Usage du service | Tarif officiel applicable au plan et aux fonctions activées | Tarif officiel applicable au service, s’il s’applique au mode retenu |
| Hôte et capacité | Inclus, facturé séparément ou soumis aux conditions du service : à vérifier | Achat ou location des hôtes, capacité de réserve et remplacement |
| Images et mises à jour | Responsabilité décrite par le fournisseur : à confirmer | Temps de création, tests, mises à jour et retour arrière |
| Orchestration et surveillance | Paramètres et limites du service | Mise en place, alertes, journaux et astreinte |
| Capacité inutilisée | À mesurer selon la facturation réelle | Ressources provisionnées mais inutilisées, plus coûts d’alimentation et d’exploitation pertinents |
| Incidents et continuité | Processus et engagements contractuels à vérifier | Diagnostic, remise en service et responsabilité de l’équipe interne |
Coût total de la solution = facturation du service + capacité d’exécution + temps d’administration + maintenance des images + orchestration et surveillance + incidents et capacité inutilisée.
Pour comparer les options, fixez la même période et le même périmètre de tâches ; renseignez le prix issu de la page officielle applicable ou de votre contrat, puis mesurez les heures d’administration et les périodes d’inactivité. Pour le cloud, relevez les postes réellement facturés et les contrôles que vous devez tout de même gérer. Pour l’auto-hébergement, ajoutez le temps consacré aux correctifs, aux mises à niveau, aux tests et au dépannage, même si les hôtes sont déjà présents dans votre parc. Si vous ne pouvez pas chiffrer un poste, inscrivez « à mesurer » au lieu de le traiter comme gratuit.
**Pour FinOps :** ne comparez pas une facture cloud observée à un Runner autogéré théorique. Incluez une fenêtre de charge représentative, le coût du travail d’exploitation et le traitement des périodes où la capacité provisionnée ne sert pas.
Pilotez avec des critères de sortie et un responsable nommé
Le pilote doit lever les incertitudes qui changent la décision, pas seulement démontrer qu’un utilisateur peut ouvrir une session. Attribuez un responsable à chaque vérification et arrêtez l’essai si une exigence bloquante — plateforme, données ou signature — reste sans réponse vérifiable.
Voici les conditions de décision à inscrire dans votre dossier d’architecture :
- Si le cloud satisfait les exigences réseau, de gouvernance et de traitement des données, alors conservez le cloud et évitez d’ajouter l’exploitation d’un Runner.
- Si une exigence de réseau, d’outillage contrôlé ou de conformité ne peut pas être satisfaite dans le cloud, alors étudiez l’auto-hébergement, à condition que le Runner soit confirmé pour la plateforme et le mode visés.
- Si l’usage comprend Xcode, macOS ou la signature, alors exigez une confirmation de prise en charge et une validation de pipeline sur l’environnement cible avant de décider de la capacité Mac.
- Si le cas d’usage correspond à une session individuelle à distance, alors évaluez Remote Control comme tel ; ne le présentez pas comme une infrastructure d’équipe partagée.
- Si les politiques de conservation, l’éligibilité ZDR ou les règles sur les secrets ne sont pas validées, alors suspendez l’intégration des dépôts et des tâches sensibles.
- Écrivez les cas d’usage. Séparez l’assistance au développement, l’exécution de commandes, les tests génériques et les tâches Apple. Désignez les dépôts et les données autorisés pour chaque catégorie.
- Vérifiez les conditions officielles actuelles. Confirmez le statut de la bêta, l’éligibilité de votre organisation, les restrictions ZDR et le mode Runner dans la documentation publiée au moment du test.
- Validez la plateforme cible. Faites consigner par l’équipe plateforme le système d’exploitation, le mode d’exécution, les dépendances et la politique de mise à jour. Une compatibilité non documentée reste une question ouverte.
- Faites approuver la carte des flux. La sécurité doit tracer les copies locales, les secrets, les prompts, les réponses et les résultats d’outils ; la gouvernance doit vérifier les règles de conservation et les exceptions applicables.
- Exécutez les tâches représentatives. Testez séparément les activités non Apple et les tâches Xcode ; pour ces dernières, contrôlez l’accès aux outils, l’isolation des certificats, l’artefact produit et son transfert dans la chaîne.
- Renseignez le TCO observé. Collectez les coûts contractuels, la capacité consommée, les heures d’exploitation, les mises à jour et les incidents. Laissez les valeurs inconnues marquées « à mesurer ».
- Décidez avec des critères de sortie. Le responsable plateforme signe l’aptitude opérationnelle, la sécurité signe les données et les accès, l’équipe Apple valide le parcours de compilation, et FinOps valide le périmètre économique. Sans ces validations, le pilote ne vaut pas autorisation de production.
Choisissez la capacité Mac seulement après avoir confirmé le besoin
La réponse à la question « cloud ou auto-hébergé ? » ne suffit pas à déterminer s’il faut un Mac. Un cloud déjà conforme évite de financer une couche Runner interne ; un Runner contrôlé par votre organisation implique davantage d’administration, de maintenance et de traitement des incidents ; et un besoin Xcode exige une validation distincte de la plateforme Apple et de la signature. Acheter du matériel avant ces vérifications expose l’équipe à immobiliser une capacité inutilisable ou à devoir reconstruire le pipeline.
Si vos essais confirment qu’une tâche Xcode doit s’exécuter sur un Mac réel, choisissez ensuite entre achat et capacité distante selon la durée d’usage, le besoin de contrôle physique, l’exploitation attendue et les exigences d’accès. Pour un pilote ou un besoin temporaire de Mac CI, MACGPU peut offrir une expérience sur Mac distant sans que vous ayez à acquérir immédiatement une machine ; vérifiez toutefois les modalités, l’environnement disponible et l’adéquation à votre pipeline avant de confier une tâche de production. Pour l’achat, prévoyez au contraire le provisionnement, la maintenance et la responsabilité de disponibilité. Vous pouvez consulter les options Mac de MACGPU une fois la nécessité d’un environnement Mac établie, et non pour décider à la place de la vérification Runner.