GitHub comme espace d'exécution pour agents IA : runbook coordonné Copilot coding agent et runners macOS dédiés

Pendant dix ans, GitHub a tressé code, issues, pull requests, Actions et modèle de permissions en un graphe optimisé pour la collaboration humaine. Les personnes écrivaient du code, ouvraient des PR, revoyaient des PR, puis fusionnaient une fois la CI verte. La transformation 2025–2026 porte sur l'acteur qui écrit le code : le dépôt passe d'un magasin de code à un bac à sable d'exécution pour agents.

Trois couches produit poussent la bascule. Copilot coding agent (cloud agent) démarre depuis l'assignation d'un issue ou un prompt Chat, ouvre une VM dédiée dans GitHub Actions, récupère le code via RAG, planifie la tâche et pousse des commits dans une draft PR. .github/agents/ permet aux équipes de déclarer plusieurs rôles spécialisés (optimisation des performances, écriture de tests, gestion de la documentation). Agentic Workflows (gh-aw, en aperçu technique) compile en YAML Actions du Markdown en langage naturel rangé dans .github/workflows/, puis fait tourner Copilot, Claude ou Codex en bac à sable pour des automatisations événementielles continues.

Empilées, ces couches font basculer la sémantique produit GitHub de « un humain écrit du code → le dépôt le conserve » vers « un humain écrit l'objectif → l'agent exécute dans le dépôt → un humain revoit la draft PR → la CI/CD déploie ». Comprendre cette bascule importe plus que courir après le dernier outil. Le contrat compute qui l'accompagne (runners self-hosted, nœuds Apple Silicon dédiés) devient le nouveau socle.

Beaucoup d'équipes branchent Copilot coding agent ou Claude Code directement sur des runners hébergés par GitHub. À court terme, c'est confortable. À long terme, quatre coûts apparaissent :

• Pool à la minute × jobs agent longs : les tâches agent relancent compilation, tests et analyses de sécurité. Un job seul dépasse souvent 30 minutes. La facturation à la minute combinée au bruit des voisins fait grimper la facture mensuelle de manière non linéaire, plus violemment qu'à l'époque où seuls des humains alimentaient la CI.
• Exposition du matériel de signature : sur un runner mutualisé, les secrets sont injectés dans l'environnement de l'agent. Sous une attaque par prompt injection ou une dépendance malveillante, certificats de signature et profils de provisionnement gagnent un chemin de fuite bien réel. SafeOutputs MCP Gateway, Agent Workflow Firewall (AWF) et threat detection job existent précisément pour séparer physiquement la capacité d'écriture de l'agent de son environnement d'exécution.
• Pression de revue imprévisible : un agent ouvre des dizaines de draft PR en une nuit. Sans AGENTS.md et garde-fous d'agents personnalisés, les reviewers se noient. GitHub exige par défaut une approbation humaine sur les draft PR avant que la CI/CD ne démarre, comme un interrupteur « human in the loop » fourni nativement.
• Apple Silicon sous-évalué : les projets iOS et macOS confient à l'agent Xcode, simulateur et envoi TestFlight. DerivedData, trousseau de signature et Xcode épinglé restent indispensables. Sur runners macOS hébergés génériques, c'est lent et cher. Sur un nœud dédié, c'est moins cher et auditable.

Mises en revue, ces lignes posent la conclusion : un espace d'exécution agent demande du compute dédié et un contrat de sécurité explicite, pas un runner générique « qui fera l'affaire ».

Le tableau ci-dessous aligne, sous angle d'ingénierie, trois notions souvent confondues, afin de choisir le bon point d'entrée en revue d'équipe :

Les couches ne sont pas exclusives. Les équipes matures placent Copilot coding agent en porte d'entrée pour « écrire du code », utilisent .github/agents/ pour encadrer les rôles (agent de tests, agent perf, agent docs) et complètent par Agentic Workflows pour de l'automatisation événementielle continue (analyser une CI rouge, trier chaque nouveau issue). GitHub devient alors un plan d'exécution propre « événement → agent → écriture contrôlée ».

Pour tout dispositif qui laisse un agent agir sur un dépôt, le contrat de sécurité prime sur le choix du modèle. GitHub Agentic Workflows rend cette couche explicite, et le motif mérite d'être repris quand on auto-héberge :

• SafeOutputs MCP Gateway : l'agent n'appelle pas l'API GitHub directement. Il déclare au gateway les opérations d'écriture souhaitées, qui les met en buffer sous forme d'artefacts. Une fois l'agent sorti, un job séparé doté des droits en écriture valide, sanitise et limite chaque requête. Le processus agent reste toujours en lecture seule et sans secrets.
• Agent Workflow Firewall (AWF) : l'agent s'exécute dans un conteneur isolé ; le trafic est routé via iptables vers un proxy Squid, et une allowlist de domaines bloque l'exfiltration de données et le commandement externe.
• Job de détection de menace : avant l'application d'un patch, un agent spécialisé sécurité analyse le diff (prompt injection, identifiants fuités, motifs malveillants). Le moindre soupçon fait échouer le workflow.
• Branch protection et revue humaine : Copilot coding agent ne peut pousser que sur les branches qu'il a créées. Les draft PR exigent une approbation humaine avant que la CI/CD ne tourne. Le « humain » reste la vanne de sûreté avant tout déploiement.

La spécification AGENTS.md, co-conçue en 2025 par OpenAI, Cursor, Jules, Amp et Factory, est le pendant humain du contrat d'espace de travail agent. Un « README pour agents » à la racine du dépôt offre à tout agent codeur un emplacement prévisible pour la structure du projet, les commandes de build et de test, les règles de style et les notes de sécurité.

• Résolution hiérarchique : les sous-répertoires peuvent porter leur propre AGENTS.md, et l'agent choisit le plus proche du fichier modifié. Le dépôt principal d'OpenAI en compte 88 aujourd'hui.
• Must-follow versus Should : règles dures (« pas de commit sur main », « épingler Xcode 16.2 ») et préférences souples (« privilégier Swift Testing ») cohabitent. Le comportement de l'agent converge.
• README et AGENTS.md sont complémentaires : README sert les humains et les contributeurs externes, AGENTS.md sert les agents et accueille étapes de build, règles de long contexte et pièges de sécurité qui surchargeraient sinon la documentation humaine.
• Compatible Copilot CLI : les agents Copilot CLI dans JetBrains et VS Code prennent déjà en charge ~/.copilot/agents/.agent.md global, permettant d'empiler des préférences personnelles sur les règles d'équipe.

Pour un projet iOS ou macOS, AGENTS.md fige la commande d'épinglage Xcode, liste le point d'entrée xcodebuild, documente les pré-étapes de signature, déclare des gates comme -strict-concurrency=complete, nomme les labels du runner dédié et indique les répertoires interdits. Plus les règles sont explicites, moins l'agent improvise. Cela rejoint la liste « geler la baseline, baseline SSH, partitionnement du cache, isolation de signature » du runbook NUKCLOUD pour les nœuds Apple Silicon dédiés ; AGENTS.md en est la version lisible par agent.

Les chiffres ci-dessous proviennent de déploiements typiques iOS/macOS CI plus agents. Traitez-les comme des repères et mesurez les vôtres :

• Walltime d'un job agent : Copilot coding agent traite « corriger un bug et ajouter des tests » en général en 8 à 25 minutes ; « refactor d'un module plus build complet » atteint 30 à 90 minutes. Les pools mutualisés à la minute affichent encore un P95 de file d'attente de 15 à 45 minutes en pic de release.
• Cadence de draft PR : une fois Copilot coding agent activé, les équipes de taille moyenne voient le volume quotidien de draft PR croître de 2 à 5 fois. Le goulet passe de « écrire du code » à « relire des PR ». AGENTS.md et .github/agents sont les leviers de retour.
• Bénéfice SafeOutputs : avec SafeOutputs et AWF activés, le processus agent ne détient ni GITHUB_TOKEN, ni secrets, ni clé d'API MCP. Le taux de rejet interne du job de détection de menace tourne, en aperçu, autour de 0,5 à 2 %, surtout des faux positifs sur du contenu de type prompt injection.
• Bénéfice Apple Silicon dédié : sur un nœud dédié NUKCLOUD avec --concurrent-jobs 2 à 4 réservés au travail d'agent, un job xcodebuild complet se termine généralement 25 à 40 % plus vite qu'un runner macOS générique. Avec les hits de cache DerivedData, on gagne encore 30 à 60 %.
• Charge de reviewer : l'agent fait une self Code Review avant d'ouvrir la draft PR, ce qui comprime le premier tour de revue humaine. En contrepartie, les reviewers se concentrent davantage sur l'intention de conception et les frontières système que sur la syntaxe.

Voici un runbook minimal et exécutable, à associer à un runner Apple Silicon dédié. Avancer pas à pas, sans chercher la perfection dès le premier jour.

1. 01
   Écrire un AGENTS.md : fichier racine avec Must-follow (version Xcode, commandes de build, répertoires interdits, branch protection) et Should (style, format de commit). Ajouter des AGENTS.md imbriqués au besoin. Codex, Cursor et Copilot CLI savent tous les lire.
2. 02
   Déclarer des agents personnalisés .github/agents/ : au minimum trois rôles — un agent de tests qui ne touche que *Tests* et lance la suite complète, un agent de documentation qui ne touche que .md et le changelog, un agent de performance qui benchmarke avant de modifier. Restreindre les appels d'outils et les étapes obligatoires dans le prompt.
3. 03
   Adopter Agentic Workflows (gh-aw) : écrire en Markdown le triage d'issues, la réparation automatique des échecs CI et le balayage de la documentation. Laisser SafeOutputs activé pour conserver un processus agent en lecture seule et tout passage d'écriture par un job contraint.
4. 04
   Inscrire un runner Apple Silicon dédié : commander un nœud dédié NUKCLOUD depuis la page de commande, l'enregistrer comme runner self-hosted, lui attribuer les labels agent-macos, xcode-16, signing-isolated. Monter le trousseau de signature uniquement sur les jobs en écriture.
5. 05
   Poser le contrat de sécurité : sur le nœud, reproduire AWF avec Squid plus iptables. Sortir les secrets du runner (OIDC plus KMS cloud) pour que le conteneur agent ne puisse pas les lire. Exiger la revue humaine sur les draft PR avant CI/CD.
6. 06
   Boucle de revue et KPI : chaque semaine, suivre « nombre de draft PR, latence de revue, taux de rejet manuel, taux de détection de menace ». Affiner AGENTS.md et les prompts d'agent personnalisé en fonction. Associer le déploiement au tempo « par étapes, réversible » du runbook de portes CI de concurrence stricte Swift 6.

Tableau d'alignement de revue. Les équipes finance et réseau y posent les chiffres maison.

L'enjeu n'est pas « lequel coûte moins cher », mais « peut-on défendre l'espace d'exécution agent par écrit ? ». Sur un nœud dédié, SafeOutputs, AWF et la discipline de revue humaine se posent sur des labels runner réels, pas sur des slogans.