Au 3 septembre 2026, TeamCity 2026.2 est officiellement publié et sa documentation confirme des outils MCP capables de lire, créer, mettre à jour et supprimer des Pipelines, avec une autorisation OAuth/PKCE et des limites entre mode sécurisé et Brave Mode (notes de version officielles ; documentation MCP de TeamCity). TeamCity 2026.2 MCP peut donc entrer en essai d’entreprise, mais pas en production ouverte par défaut. Cette semaine, activez uniquement le mode sécurisé, une identité limitée au projet et le diagnostic en lecture seule. Gardez les écritures sur un projet de test et les compilations Xcode sur un pool de Mac de confiance isolé.

Cette méthode s’adresse aux responsables de plateforme qui veulent connecter un agent externe à TeamCity sans lui donner un chemin implicite vers les livraisons. Elle concerne aussi les équipes sécurité qui doivent prouver les droits effectifs, ainsi que les équipes macOS responsables des agents Xcode, de la signature et de la capacité des Mac distants.

01

Matrice de décision pour l’acceptation MCP

La question utile n’est pas de savoir si l’agent « se connecte ». Il faut déterminer ce qu’il peut faire, avec quelle identité, sur quel projet et avec quel retour arrière. Les quatre niveaux suivants donnent une décision exploitable.

Capacité Décision initiale Périmètre autorisé Preuve attendue
Diagnostic en lecture seule Autoriser pour le pilote Projet de test puis projets non sensibles Lecture des journaux, des statuts et des configurations sans modification
Déclenchement contrôlé d’une compilation personnelle Autoriser sous conditions Branche et projet explicitement désignés Identité du demandeur, paramètres du lancement et annulation vérifiée
Écriture dans un Pipeline Limiter au projet de test Branche non productive, revue obligatoire Diff avant/après, approbation, historique de configuration et restauration
Suppression d’un Pipeline ou d’un projet Refuser au pilote Aucun accès direct de l’agent Test négatif, alerte et procédure d’intervention humaine

La capacité officielle d’un outil n’est pas une permission universelle. Les rôles et permissions TeamCity déterminent ce que l’identité peut réellement consulter ou modifier (documentation officielle des rôles et permissions). Un agent capable d’appeler un outil de suppression ne doit donc pas recevoir un rôle qui lui permettrait de l’exécuter sur l’arborescence entière.

Le bon seuil de production est progressif :

  • Pilote accepté : lecture des journaux et déclenchement contrôlé, sans accès aux secrets de signature.
  • Mise en production limitée : écriture possible uniquement dans des projets de test, avec validation humaine et historique exploitable.
  • Extension refusée : héritage non maîtrisé, absence de journal exploitable, impossibilité de révoquer l’identité ou accès indirect à un Mac de signature.

Cette matrice évite une erreur fréquente : confondre la réussite d’une requête MCP avec l’acceptation du risque opérationnel.

Attention. Un agent peut disposer d’une autorisation MCP valide tout en étant trop puissant dans TeamCity. Vous devez tester l’action autorisée et l’action interdite, avec la même identité et sur des projets voisins. La capture d’une page de connexion ne constitue pas une preuve de cloisonnement.

02

Responsabilité de la plateforme CI/CD

Le responsable TeamCity doit définir le périmètre fonctionnel avant de transmettre un point d’accès à un agent. La documentation d’intégration MCP de TeamCity 2026.2 doit être lue avec les notes de version, car la liste des outils et leur comportement peuvent évoluer avec une version corrective (intégration des agents IA et MCP).

Commencez par inventorier les actions nécessaires. Un agent qui résume un journal n’a pas besoin de créer une configuration. Un agent qui relance une compilation n’a pas besoin de modifier le Pipeline. Une séparation claire réduit la portée du jeton et simplifie l’audit.

Pour chaque action, le responsable de plateforme remet à l’équipe sécurité :

  • le nom de l’outil appelé ;
  • le projet cible ;
  • l’identité et le type de jeton ;
  • les paramètres acceptés ;
  • le résultat attendu ;
  • la procédure d’annulation ou de restauration.

L’agent ne doit pas être installé avec un compte administrateur « temporaire ». Le caractère temporaire d’un compte ne réduit ni sa visibilité ni son pouvoir pendant sa période d’utilisation. Les permissions doivent être attachées à une identité de service ou à un utilisateur explicitement désigné, puis révoquées par un responsable nommé.

Séquence d’essai technique

Voici une séquence que vous pouvez exécuter dans un projet sans impact sur la livraison :

  1. Créez une configuration de test dont les journaux ne contiennent aucun secret ni certificat.
  2. Connectez l’agent avec l’identité dédiée et consignez l’heure, le projet et l’action demandée.
  3. Demandez une lecture de statut et de journal, puis vérifiez que la réponse ne révèle pas un projet parent ou voisin.
  4. Déclenchez une compilation sans signature et confirmez que l’agent de compilation utilisé appartient au pool prévu.
  5. Tentez une modification contrôlée du Pipeline, avec une différence volontairement identifiable.
  6. Refusez l’approbation, puis confirmez qu’aucune écriture partielle n’est restée.
  7. Testez une action de suppression sur un objet sans valeur, si votre procédure de sécurité l’autorise ; sinon, réalisez un test négatif documenté.
  8. Révoquez le jeton et vérifiez qu’une nouvelle requête échoue.

Les étapes de lecture et de modification doivent être rapprochées des droits REST effectifs, et non d’une simple déclaration dans l’interface (référence officielle des permissions REST). Le résultat à conserver est un dossier d’acceptation : requête, réponse, identité, projet, horodatage, journal et décision.

03

Modèle d’identité et de permissions

L’équipe sécurité doit contrôler quatre couches séparément :

  • l’autorisation accordée au client MCP ;
  • les permissions du compte dans TeamCity ;
  • les droits de l’agent de compilation ;
  • les droits du compte local macOS.

Ces couches ne sont pas interchangeables. Une restriction dans MCP ne corrige pas un compte TeamCity administrateur. Un compte TeamCity limité ne protège pas un agent macOS qui peut lire un trousseau de clés. Un pool de compilation séparé ne suffit pas si les mêmes secrets sont montés partout.

OAuth PKCE et jetons

OAuth PKCE convient à une autorisation interactive lorsque l’utilisateur doit confirmer le client et la session. Le contrôle doit porter sur le client déclaré, la redirection, la session ouverte et la possibilité de terminer cette session.

Les jetons d’accès répondent à un autre besoin : une intégration automatisée qui doit fonctionner sans intervention interactive. Ils exigent une durée de vie maîtrisée, un propriétaire, un emplacement de stockage protégé et une procédure de révocation. La documentation officielle des jetons TeamCity décrit leur gestion et leur retrait (gestion des jetons d’accès).

Pour chaque identité, consignez :

  • le propriétaire métier et le responsable de révocation ;
  • le projet autorisé ;
  • le niveau lecture ou écriture ;
  • la date d’expiration prévue ;
  • le coffre où le secret est conservé ;
  • le signal qui déclenche sa révocation.

Ne placez jamais un jeton dans un fichier de configuration partagé avec les journaux de compilation. Ne transmettez pas non plus un jeton global à un agent chargé de traiter un seul projet.

Héritage des projets

L’héritage depuis un projet parent est un point de contrôle prioritaire. Une permission visible sur le projet enfant peut provenir d’un niveau supérieur. Votre test doit donc inclure un projet cible, un projet frère et un objet parent.

La preuve attendue est double :

  • un export des rôles et permissions, interprété par l’équipe sécurité ;
  • un test réel de visibilité avec l’identité MCP, incluant un résultat attendu négatif.

Si l’agent voit des configurations qu’il ne doit pas connaître, arrêtez le pilote. Réduire le nombre d’outils ne suffit pas si l’identité conserve une visibilité excessive.

Expérience de terrain. La restriction la plus lisible est celle que vous pouvez expliquer sans contexte : « cette identité lit ce projet et déclenche cette configuration ». Si la réponse nécessite de parcourir plusieurs niveaux d’héritage, ajoutez une revue avant toute écriture.

04

Responsabilité du propriétaire de projet

Le propriétaire de projet décide ce qui peut être lu, déclenché ou modifié. Il doit classer les Pipelines selon leur impact, sans laisser l’agent déduire cette classification à partir du nom de la configuration.

Un Pipeline de test peut accepter une écriture limitée si les changements sont visibles et réversibles. Une chaîne de livraison de production doit rester derrière le processus de changement existant. L’agent peut préparer une proposition, produire un diff ou ouvrir une demande de revue ; il ne doit pas contourner l’approbation.

Pour chaque écriture, exigez :

  • une différence avant/après ;
  • l’auteur technique et l’identité MCP ;
  • le motif de la modification ;
  • l’approbateur ;
  • la version précédente ;
  • une action de retour arrière testée.

Pour une suppression, le seuil est plus élevé. Une confirmation textuelle envoyée à l’agent n’est pas une procédure de récupération. Conservez une configuration exportée ou versionnée, et vérifiez que la restauration ne dépend pas du même canal MCP qui vient d’échouer.

Les configurations et historiques TeamCity doivent être traités comme des preuves de changement, pas comme de simples détails administratifs. Le propriétaire de projet transmet ensuite au responsable de plateforme la liste des objets autorisés et à l’équipe sécurité la liste des actions refusées.

05

Protection du pool Xcode et du Mac de signature

Lorsqu’un agent déclenche une compilation iOS, TeamCity reste le plan de contrôle. Le Mac distant exécute une tâche définie par un agent de compilation. Cette distinction doit rester visible dans l’architecture et dans les journaux.

La documentation TeamCity décrit la communication et l’installation des agents ; elle doit servir à vérifier l’identité du nœud, son rattachement et son état, sans extrapoler une isolation de sécurité que vous n’avez pas testée (communication des agents TeamCity).

Séparez au minimum les usages suivants :

  • diagnostic ordinaire : agent sans certificat de signature, données de test uniquement ;
  • validation de code non fiable : pool isolé, compte macOS distinct, accès sortant contrôlé selon vos règles ;
  • compilation de livraison : pool approuvé, chaîne fixe, secrets injectés au dernier moment ;
  • signature et publication : nœud réservé, accès humain limité, pipeline révisé.

Les pools d’agents permettent de formaliser cette séparation dans TeamCity (configuration des Agent Pools). Le point important est la chaîne complète : projet, configuration, pool, compte local, certificat et destination de publication.

N’utilisez pas le MCP comme tunnel SSH ou comme console distante vers le Mac. Un accès direct permettrait à l’agent de contourner les contrôles du Pipeline et d’atteindre potentiellement le trousseau, les fichiers de travail ou les journaux contenant des données sensibles.

Cette approche est pertinente au-delà de l’iOS. Pour une équipe audio ou vidéo, un Mac isolé peut exécuter un rendu ou une exportation dans un environnement reproductible, tandis que les essais de plugins et de fichiers fournis par des tiers restent sur un autre pool. Pour une équipe design, les tâches d’export automatisé peuvent partager une machine dédiée sans exposer les certificats de publication.

Si vous devez tester cette chaîne avec un Mac distant dédié à la compilation, traitez-le comme un nœud d’essai indépendant. La page de service ne remplace pas votre validation des comptes, des secrets et du routage TeamCity. Après le test, vous pourrez comparer un nœud temporaire avec une capacité de compilation durable.

06

Contrôle des journaux et arrêt d’urgence

L’équipe d’exploitation doit prouver qu’elle peut arrêter l’agent, le compte et la tâche. Cette preuve ne doit pas reposer sur une seule commande.

La procédure de test comprend :

  1. désactivation du jeton ;
  2. fermeture de la session OAuth ;
  3. arrêt de Brave Mode ;
  4. annulation d’une compilation en cours ;
  5. blocage de la configuration concernée ;
  6. vérification de l’absence de nouvelles requêtes ;
  7. contrôle de la configuration après restauration.

Les actions des utilisateurs et des identités automatisées doivent être suivies dans les journaux TeamCity (suivi officiel des actions utilisateur). Vérifiez que l’enregistrement permet de relier l’action à l’identité, au projet et à l’objet modifié.

Surveillez particulièrement :

  • les appels REST répétés ;
  • les déclenchements rapprochés d’une même configuration ;
  • les modifications successives d’un Pipeline ;
  • les tentatives d’accès à un projet voisin ;
  • les suppressions refusées ;
  • les compilations envoyées vers un pool inattendu.

La disponibilité du contrôle doit aussi être testée. Si le serveur TeamCity devient indisponible, l’équipe doit savoir quelles tâches sont arrêtées, lesquelles restent en file et comment empêcher une reprise non contrôlée. Si un Mac distant redémarre, contrôlez la reconnexion de l’agent et l’absence de récupération automatique d’un secret persistant.

Ne déclarez pas un délai de reprise ou une performance de nœud sans mesure dans votre environnement. Les résultats dépendent du réseau, du projet Xcode, de la file TeamCity et du pool sélectionné. Documentez ces résultats comme des tests internes, pas comme une conséquence automatique de la documentation du produit.

07

Décision de la direction technique

La direction technique peut utiliser trois décisions simples :

  • Autoriser le pilote si la lecture, le déclenchement contrôlé, la restriction de projet et la révocation sont démontrés.
  • Autoriser sous périmètre limité si les écritures restent cantonnées à un projet de test et si chaque changement possède un diff, une approbation et une restauration.
  • Suspendre si l’agent voit des projets non prévus, si Brave Mode reste actif sans fenêtre ni isolement, si la révocation n’interrompt pas les actions ou si le Mac de signature est atteignable hors du Pipeline approuvé.

Le passage à l’échelle doit suivre la charge réelle : volume de compilations, durée des files, nombre de projets, fréquence des essais et besoin de nœuds séparés. Pour un pilote, un Mac distant loué à la demande peut servir à établir la chaîne TeamCity–Agent Pool–Xcode sans immobiliser immédiatement un parc matériel. La décision d’un pool permanent ou d’un nœud réservé doit venir après les tests de routage, de redémarrage et de signature.

Cette distinction est essentielle pour l’achat. Un Mac local acheté offre un contrôle physique et convient à une charge stable avec besoin d’interface matérielle. Un Mac distant loué convient mieux à un pilote, à une équipe distribuée ou à une capacité variable, à condition d’accepter la dépendance réseau et de vérifier les exigences contractuelles de sécurité. Dans les deux cas, l’isolation des identités reste votre responsabilité d’architecture.

08

Questions fréquentes

Droits de modification et de suppression

TeamCity 2026.2 MCP expose des fonctions plus sensibles que la simple lecture. Une autorisation de connexion ne donne pas automatiquement le droit de modifier ou de supprimer, mais une identité trop large peut rendre ces outils dangereux. Traitez chaque capacité séparément et refusez la suppression pendant le pilote, sauf test contrôlé, documenté et réversible.

Limitation à un projet

Pour limiter un agent à un projet, combinez identité dédiée, jeton restreint, rôle minimal et test négatif sur les projets voisins. Examinez aussi les permissions héritées du projet parent. Si l’export des droits et le comportement observé ne concordent pas, suspendez l’intégration jusqu’à clarification.

Usage de Brave Mode

Brave Mode ne doit pas être considéré comme un réglage permanent pour une production partagée. Utilisez-le seulement dans un projet isolé, pendant une période définie, avec des données non sensibles et une surveillance active. L’équipe d’exploitation doit pouvoir le désactiver et annuler les compilations associées sans dépendre de l’agent.

Isolement du Mac de signature

Pour protéger le Mac de signature, séparez les Agent Pools, les comptes macOS et les secrets. Les agents utilisés pour du code non fiable ne doivent pas recevoir de certificat. Le nœud de publication doit accepter une chaîne fixe et approuvée ; l’accès MCP doit rester au niveau du contrôle TeamCity, jamais au niveau d’une session locale.

09

Recommandation finale

Votre solution actuelle peut être un parc de Mac achetés, des machines partagées ou une instance distante généraliste. Elle présente alors des limites concrètes : immobilisation du matériel pour un pilote, maintenance et remplacement à votre charge, capacité difficile à ajuster lorsque les files de compilation augmentent, et risque de mélanger diagnostic, code non fiable et signature sur le même nœud. Ce n’est pas une base idéale pour valider rapidement une gouvernance MCP.

Pour cette phase, louez plutôt un Mac distant isolé avec VpsMesh afin de créer un Agent Pool de test, d’exécuter un véritable projet Xcode et de vérifier le redémarrage, le routage et la séparation des secrets. Une fois les preuves réunies, vous pourrez décider rationnellement entre une capacité temporaire, un pool de compilation durable ou un nœud dédié à la signature. VpsMesh intervient ainsi comme environnement de validation contrôlé, pas comme substitut à votre modèle de permissions.