Débrancher GitHub Actions : Pourquoi nous fusionnons désormais nos PRs en local (Règle #65)

Pourquoi nous avons éteint l'usine à gaz de l'intégration continue dans le cloud pour adopter la fusion locale souveraine : sécurité absolue des secrets, cycles instantanés et zéro euro gaspillé en machines virtuelles distantes.

1. LA FACE CACHÉE DE L'INTÉGRATION CONTINUE DANS LE CLOUD

Pour n'importe quelle équipe de développement moderne, GitHub Actions est devenu un réflexe pavlovien. Vous ouvrez une Pull Request, un conteneur distant démarre chez Microsoft ou Google, installe des gigaoctets de dépendances, lance votre suite de tests, et allume un voyant vert avant de vous autoriser à cliquer sur le bouton de fusion (Merge).

Pendant longtemps, nous avons fait comme tout le monde. Puis nous avons regardé la réalité en face :

1. La surface d'attaque des secrets : Pour que vos tests d'intégration tournent sur un runner distant, vous devez y injecter vos clés d'API, vos tokens cloud et vos identifiants de bases de données. À chaque exécution, vous exposez vos accès les plus sensibles aux risques de fuites dans les logs ou de compromission de dépendances tierces (attaques de supply chain).
2. La facture à la minute : Même sur des projets modestes, l'accumulation de runners Ubuntu/macOS facturés à la seconde finit par grignoter vos crédits ou générer des surcoûts injustifiables.
3. L'inertie insupportable : Attendre 3 minutes de mise en file d'attente (queue) et de téléchargement de paquets pour une simple vérification de typographie ou un commit d'une ligne est une hérésie qui brise le flux de concentration.

2. LA GENÈSE DE LA RÈGLE #65 : ZÉRO MERGE DANS LE CLOUD

Le 24 septembre, face à la multiplication des contributions autonomes de nos agents IA (notamment Jules), nous avons pris une décision radicale de gouvernance : la Règle #65.

Règle #65 (Gouvernance Crilo Automation) : L'usine GitHub Actions distante est formellement éteinte. Toutes les fusions de Pull Requests s'effectuent exclusivement en local, après validation stricte des tests sur l'environnement de contrôle souverain. La branche main ne reçoit que des commits déjà certifiés.

ANCIEN FLUX vs NOUVEAU FLUX SOUVERAIN (RÈGLE #65)
────────────────────────────────────────────────
ANCIEN FLUX (Cloud / Fragile)        NOUVEAU FLUX (Local / Souverain)
┌──────────────────────────┐        ┌──────────────────────────┐
│ PR ouverte sur GitHub    │        │ PR créée par l'agent     │
│ Runner distant démarre   │        │ Outil `sans-actions`     │
│ Secrets exposés au cloud │        │ Tests exécutés en local  │
│ Attente 3 à 5 minutes    │        │ Secrets protégés au coffre│
│ Merge automatique distant│        │ Squash-merge + push direct│
└──────────────────────────┘        └──────────────────────────┘

En supprimant les déclencheurs automatiques (pull_request: et push:) de nos fichiers YAML de workflow dans GitHub, nous avons immédiatement neutralisé tout risque d'exécution de code arbitraire par des agents non audités.

3. L'OUTIL SOUVERAIN SANS-ACTIONS EN PRATIQUE

Remplacer une usine cloud ne signifie pas renoncer à la rigueur des contrôles. Pour automatiser ce processus sans friction, nous avons conçu un utilitaire en ligne de commande : sans-actions.

Lorsqu'un agent ou un collaborateur soumet une Pull Request, l'ingénieur humain n'a qu'une seule commande à taper :

sans-actions fusionner <numéro_pr>

En coulisses, le script exécute une séquence déterministe et chirurgicale :

1. Rapatriement de la branche distante : Téléchargement du diff sans jamais polluer l'espace de travail principal.
2. Exécution de la suite de tests locale : Lancement des linters, des tests de non-régression et des vérifications de syntaxe dans un environnement éphémère local.
3. Squash-Merge déterministe : Fusion propre des modifications avec conservation de la signature de l'auteur et de l'identifiant de mission.
4. Suppression de la branche distante : Nettoyage automatique du dépôt GitHub.
5. Push direct vers origin/main : La branche de production avance d'un bloc, sans aucun merge commit parasite.

4. L'ÉPURATION DES DÉPÔTS DE LA CONSTELLATION

Appliquer ce changement à un dépôt unique est trivial ; le généraliser à une flotte de 15 dépôts interconnectés (JARVIS-WorkFlow, Eywa, GrokBot, _registry, _mcp, _skills...) a constitué une véritable épreuve de force.

Dans chaque dépôt, nous avons neutralisé les déclencheurs automatiques, supprimé les caches fantômes et harmonisé les scripts de validation locale (pre_push_ci_check.sh).

Désormais, un agent comme Jules sait qu'il ne doit jamais attendre qu'un robot GitHub fusionne son travail : il prépare sa PR, soumet son rapport dans l'Issue, et attend que le guichet de contrôle local valide l'intégration.

5. MANIFESTE POUR UNE INTÉGRATION CONTINUE LOCALE ET FRUGALE

Cette transition nous a rappelé une vérité fondamentale trop souvent oubliée par l'industrie logicielle :

1. Votre machine de développement est plus puissante qu'un runner partagé : Avec un processeur moderne et un SSD, vos tests s'exécutent 10 fois plus vite sur votre terminal que dans un conteneur distant sous-dimensionné.
2. La simplicité bat la machinerie : Un script bash ou Python de 150 lignes bien écrit est infiniment plus compréhensible et maintenable qu'une chaîne de 12 actions GitHub communautaires dont personne ne lit le code source.
3. La souveraineté commence à la racine : Si vous ne pouvez plus déployer votre code lorsque GitHub subit une panne de son infrastructure Actions, vous n'êtes pas propriétaire de votre système : vous en êtes le locataire précaire.

Publié par CriloCom — Veille Technologique & Architecture Cloud.