Quels contrôles de pull request d'agent doivent bloquer le merge ?

Un agent peut produire un diff propre, une description convaincante et du code qui passe une revue rapide, tout en laissant une application exposée ou impossible à restaurer. La décision de merge doit donc reposer sur des preuves mesurables par le dépôt, pas sur l'assurance de l'agent ni sur la petite taille apparente du patch.

J'utilise sept contrôles bloquants : tests, CodeQL, revue des dépendances, détection des secrets, contrôles d'autorisation, répétition de migration et vérification du rollback. Chacun répond à une catégorie d'échec différente. Une suite de tests verte ne prouve pas qu'un nouveau paquet est sûr. Une analyse statique sans résultat ne dit pas si une migration va verrouiller la table la plus sollicitée.

Ces contrôles valent pour les changements humains comme pour ceux des agents. L'agent modifie le volume, la vitesse et la forme des erreurs, mais ne justifie pas une voie séparée moins exigeante. Si une modification ne fournit pas les mêmes preuves que tout autre pull request, elle n'est pas prête pour le merge.

Un contrôle doit produire une preuve, pas un conseil

Un contrôle de merge doit rendre un résultat reproductible de réussite ou d'échec pour le commit exact qui entrera dans la branche protégée. Un commentaire demandant de vérifier une dépendance est un conseil. Un check obligatoire qui identifie le paquet, la version, l'avis et le seuil de gravité est une preuve.

La distinction compte, car beaucoup de fonctions de sécurité se contentent par défaut de signaler après le moment utile. Un scanner peut créer une alerte, envoyer un e-mail ou ouvrir une issue tandis que le bouton de merge reste disponible. L'équipe dit alors que le scan est actif, bien qu'il ne puisse rien arrêter. Vérifiez quatre propriétés pour chaque contrôle :

• Il s'exécute sur le commit de tête actuel du pull request.
• La protection de branche exige son résultat nommé.
• Un job ignoré, expiré ou en échec ne compte pas comme réussi.
• Le résultat contient assez de détails pour reproduire la décision.

Conservez la politique dans le dépôt. Un petit manifeste se révise mieux qu'une collection de réglages connus des seuls administrateurs :

merge_gates:
  tests: required
  codeql: required
  dependency_review: required
  secret_scan: required
  authorization: required
  migration_rehearsal: required_when_changed
  rollback_verification: required

required_when_changed n'est pas une échappatoire. Le contrôle détecte d'abord les fichiers concernés, puis lance la répétition ou enregistre clairement not applicable. Un filtre de chemins ne doit pas laisser un check requis en attente indéfiniment. L'agent ne doit pas décider que sa propre modification risquée est dispensée.

Limitez les permissions du workflow au strict nécessaire de chaque job. Le code d'un pull request est une entrée non fiable, même si la branche appartient à votre organisation. Un contrôle qui expose un jeton d'écriture ou un secret de production au code examiné peut créer un problème plus grave que celui qu'il devait détecter.

Protégez l'identité du check comme sa logique. Les règles de branche exigent souvent un nom de statut. Deux workflows capables de publier le même nom peuvent laisser le plus faible satisfaire la règle. Donnez un nom unique au job de politique, limitez les personnes qui modifient son fichier et exigez la revue de ses propriétaires. Si une file de merge crée un nouveau commit combiné, relancez les contrôles sur ce commit ou liez les résultats à la révision en file. La preuve de la tête d'hier n'est pas celle du merge d'aujourd'hui.

Traitez la configuration du contrôle comme du code sensible. Un pull request qui modifie un seuil, supprime un chemin, réduit un paquet de requêtes ou ajoute une exception change le sens de tous les résultats verts suivants. Rendez les diffs de politique très visibles et demandez un mainteneur qui comprend le contrôle touché. L'agent peut proposer ce changement, mais il ne doit pas passer plus facilement parce qu'il modifie son propre juge.

Les tests bloquent les régressions observables

Le contrôle de tests doit bloquer toute modification qui casse le comportement défini sur les versions prises en charge du runtime et de la base. Il doit employer les mêmes entrées de build que le commit de merge, notamment les dépendances verrouillées, fichiers générés, feature flags et état du schéma.

Les agents savent satisfaire l'assertion la plus proche. Ils peuvent ajouter un fallback qui met un test au vert tout en cassant la gestion d'erreurs, la pagination, la concurrence ou un contrat d'API voisin. Exigez des tests quand le comportement change, mais ne mesurez pas la qualité au nombre de lignes ajoutées. Vérifiez si le test échoue quand l'implémentation est retirée ou annulée.

Un contrôle de tests utile possède des couches nommées séparément :

• Tests unitaires pour la logique locale et les cas limites.
• Tests d'intégration pour la base, la file, le cache et les contrats de services externes.
• Tests de contrat pour les formes publiques des requêtes et réponses.
• Un petit smoke test du livrable construit.

Réparez les tests instables au lieu de les répéter jusqu'au succès. Une nouvelle tentative peut collecter des diagnostics, mais l'état final doit montrer le premier échec. Sinon, un agent peut merger du code dont la seule propriété prouvée est qu'il fonctionne parfois.

Le smoke test doit démarrer le livrable, appeler un endpoint de santé et un chemin d'écriture significatif, puis l'arrêter proprement. Tester le source sans démarrer l'application empaquetée manque des fichiers absents, de mauvais réglages d'environnement, des migrations cassées et des plantages au démarrage. Le résultat d'un service web peut rester compact :

{"commit":"abc123","build":"pass","startup_ms":842,"health":200,"write_read_cycle":"pass"}

Ne faites pas d'un pourcentage universel de couverture le contrôle principal. La couverture peut révéler un changement non testé, mais un dépôt atteint un score élevé avec de faibles assertions. Bloquez selon les suites obligatoires et le comportement modifié, puis utilisez l'évolution de couverture comme preuve de revue.

Protégez les tests de l'implémentation qu'ils jugent. Si un pull request change une règle et réécrit les assertions pour accepter le nouveau résultat, la suite peut passer tandis que le contrat se déplace en silence. Un reviewer doit comparer les tests à l'API publique, à l'issue ou au critère d'acceptation. Pour les parseurs, validateurs, calculs de facturation et accès, ajoutez du mutation testing ou des entrées volontairement fausses. Il faut savoir si la suite rejette une implémentation incorrecte plausible.

Conservez les artefacts quand le contrôle échoue : graine du test aléatoire, image exacte de la base, logs de services débarrassés des secrets et commande de reproduction. Un statut sans ces données renvoie l'agent ou l'ingénieur suivant aux suppositions. Limitez la rétention selon les règles de données et ne téléversez jamais un snapshot de production pour simplifier la reproduction.

CodeQL bloque les chemins connus vers des vulnérabilités

Le contrôle CodeQL doit bloquer les nouveaux résultats à forte confiance dans les langages et livrables générés que CodeQL analyse réellement. Un résultat propre ne doit pas laisser croire que toute l'application est sûre.

GitHub décrit CodeQL comme un système qui compile le code dans une base interrogeable et exécute des requêtes dessus. Ce modèle suit les données à travers le code plutôt que de rechercher seulement du texte suspect. Il reste limité par les langages pris en charge, le succès du build, les requêtes choisies et le code présent. Si la construction de la base exclut silencieusement un service, le résultat vert couvre moins que ne le pensent les reviewers.

Utilisez un workflow aux langages explicites et à la politique de requêtes fixe :

name: codeql
on: [pull_request]
permissions:
  contents: read
  security-events: write
jobs:
  analyze:
    strategy:
      matrix:
        language: [javascript-typescript, go]
    steps:
      - uses: actions/checkout@v4
      - uses: github/codeql-action/init@v3
        with:
          languages: ${{ matrix.language }}
          queries: security-extended
      - uses: github/codeql-action/autobuild@v3
      - uses: github/codeql-action/analyze@v3

Dans un vrai dépôt, épinglez les actions tierces à des digests de commits revus. Les tags rendent l'exemple lisible, mais un tag mutable agrandit la zone de confiance d'un job de sécurité obligatoire.

Décidez ce qui bloque avant la première alerte. Je bloque en général les nouveaux résultats au seuil de gravité et de précision convenu, tout en gardant la dette existante visible dans une base. Tout bloquer le premier jour encourage les rejets en masse. Tout ignorer durablement crée un angle mort. Attribuez des responsables et des échéances à la base.

Inspectez l'ensemble des fichiers analysés quand les services, langages ou commandes de build changent. Un nouveau client mobile, resolver généré ou backend séparé peut nécessiter un analyseur ou une étape supplémentaire. « CodeQL a réussi » n'a de sens que si les reviewers savent dire ce qu'il a examiné.

Séparez les échecs d'analyse des analyses propres. Si autobuild ne compile pas un paquet, le job doit signaler une erreur d'infrastructure ou de configuration, pas zéro résultat. Conservez le log de création de la base et le nombre de sources analysées par langage. Comparez ces nombres avec la branche de base et signalez toute forte baisse inexpliquée. Vous détecterez ainsi un cas ordinaire : une modification du build exclut le module vulnérable et le check devient rapide et vert parce qu'il voit moins de code.

Révisez les rejets comme des changements de politique, pas comme du rangement. Un faux positif demande une explication concrète liée au chemin et à la requête. Les commentaires de suppression doivent être étroits, attribués et visibles dans le diff. Une exclusion globale des fichiers générés peut convenir, après vérification qu'aucun template ou input de générateur maintenu à la main ne se trouve là.

La revue des dépendances arrête le risque avant l'installation

La revue doit bloquer un pull request quand son diff ajoute un paquet ou une version qui enfreint une politique explicite. Celle-ci peut couvrir la gravité des avis connus, les licences refusées, les sources inattendues et les dépendances directes sans propriétaire.

Ce contrôle diffère d'une alerte de vulnérabilité du dépôt. L'alerte dit qu'une dépendance vulnérable existe dans la branche. La revue demande si ce pull request dégrade le graphe. Celle de GitHub compare les manifestes et lockfiles du pull request, ce qui rend la décision rapide et attribuable.

Exigez la cohérence des lockfiles. Si l'agent modifie package.json sans le lockfile, ou le lockfile sans manifeste correspondant, le job doit échouer. Les commandes qui résolvent de nouvelles versions dans CI donnent un résultat non déterministe et peuvent tester un autre graphe que celui vu en revue.

Une politique compacte peut être :

dependency_policy:
  fail_on_severity: high
  deny_licenses:
    - AGPL-3.0
  allow_sources:
    - registry.npmjs.org
    - proxy.golang.org
  require_owner_for_direct_additions: true

La liste précise de licences relève du droit et du produit, elle ne doit pas être copiée aveuglément. Le dépôt doit la déclarer et le check doit afficher le paquet qui l'a déclenchée.

N'approuvez pas automatiquement un paquet parce que son nom ressemble à une bibliothèque suggérée. Les agents peuvent inventer des noms, choisir des forks abandonnés ou ajouter un client énorme pour une petite fonction. La sortie doit montrer nouveaux paquets directs et transitifs, registre, version résolue, licence et avis. Le reviewer peut alors demander si le code existant ou une dépendance plus petite suffit.

Échouez en mode fermé si le service ne produit pas de diff. Un flux d'avis indisponible peut justifier de retenir le merge, pas de transformer l'incertitude en vert. Une procédure d'urgence peut permettre un override documenté par un mainteneur nommé, avec le motif attaché au commit.

Testez l'installation dans un job isolé dont le réseau se limite aux registres approuvés. Les lifecycle scripts et plugins de build exécutent du code pendant l'installation. Un paquet peut donc être dangereux même s'il n'est jamais importé. Enregistrez les nouveaux scripts, binaires natifs et registres inconnus. Ne donnez ni identifiants de publication, ni jetons cloud, ni cache inscriptible partagé avec des builds fiables.

Le code embarqué et les images de conteneur entrent dans la même décision, même si la revue de manifeste les manque. Comparez digests, noms d'images de base, sous-modules Git et archives ajoutées. Les inputs de release doivent utiliser des digests immuables. Un tag comme latest rend la reproduction ultérieure impossible, car les octets changent sans nouveau diff.

La détection des secrets doit inspecter le diff et son historique

La détection doit bloquer lorsqu'un pull request introduit un motif d'identifiant ou un secret actif vérifié, même dans un fixture, un fichier supprimé, un bundle généré ou un commit antérieur.

La protection au push et le scan du pull request règlent des problèmes liés mais différents. La première arrête un secret reconnu avant le serveur distant. Le contrôle examine ce qui est déjà arrivé et couvre des contributeurs ou types de jetons manqués. Une alerte qui n'est pas requise par la protection de branche ne bloque pas le merge.

Scannez toute la plage de commits par rapport à la branche de base, pas seulement le système de fichiers final. Un agent peut ajouter un jeton dans un commit et le retirer au suivant. Il reste dans Git et a peut-être atteint logs ou caches. Considérez-le exposé. Révoquez ou faites tourner l'identifiant, nettoyez l'historique proposé et relancez le contrôle.

Utilisez des fixtures synthétiques incapables de s'authentifier. Ils doivent s'identifier clairement et correspondre à un motif local plutôt que copier une vraie clé cloud. Les allowlists larges sont dangereuses, car erreurs et attaquants finissent par trouver le répertoire ignoré. Gardez les exceptions exactes, revues et proches de la configuration.

Combinez détecteurs de motifs, contrôle d'entropie et, lorsque le fournisseur le permet sans risque, vérification d'identifiants. Le motif a moins de risques réseau et de divulgation, mais manque les jetons privés. La vérification réduit le doute, tout en envoyant une partie du secret candidat à un service tiers. Elle ne doit jamais contacter un endpoint non fiable fourni par le pull request. Documentez les vérifications, celles qui restent locales et les données qui quittent CI.

Scannez les encodages courants et sorties générées sans traiter toute chaîne aléatoire comme un identifiant. Base64, l'encodage URL et les bundles minifiés peuvent cacher un secret apparu en clair plus tôt. Réglez le seuil avec des fixtures testés et révisez les mises à jour du détecteur comme la politique. Un scanner bruyant entraîne les mainteneurs au rejet, un scanner silencieux donne une fausse confiance.

La sortie doit donner l'emplacement sans divulguer la valeur :

{"result":"fail","detector":"generic-api-token","commit":"abc123","path":"config/dev.env","line":7,"fingerprint":"sha256:8f2c..."}

N'imprimez jamais la correspondance complète dans les logs CI ou un commentaire. Le masquage peut intervenir trop tard, car systèmes de logs, notifications et artefacts ont déjà copié la sortie.

Le scan ne remplace pas la revue des permissions du dépôt. Un workflow peut lire un secret de production sans le placer dans le diff, et un agent peut modifier un job de déploiement pour l'exfiltrer. Éloignez les secrets des jobs de pull request, limitez les permissions et imposez une revue humaine aux définitions CI.

Les contrôles d'autorisation maintiennent les interdictions

Le contrôle d'autorisation doit prouver que chaque opération protégée rejette le mauvais acteur et accepte l'acteur prévu à la limite du service. Les tests de connexion ne testent pas l'autorisation.

Les équipes confondent authentification, autorisation et visibilité de l'interface. L'authentification établit qui envoie la requête. L'autorisation décide si cette identité peut effectuer cette action sur cet objet. Cacher un bouton admin dans React ne change aucune décision d'une API Go. Si le backend accepte la requête, l'application reste exposée.

Créez une matrice de permissions pour les endpoints et actions modifiés, avec propriété et limites entre tenants :

read_private_project:
  anonymous: deny
  member: deny
  other_tenant: deny
  owner: allow
  admin: allow
update_project:
  anonymous: deny
  other_tenant: deny
  owner: allow

Générez les tests depuis cette matrice ou codez des cas tabulaires dans le langage du service. Chaque refus doit appeler le vrai handler avec des identifiants réalistes. Un mock qui remplace le middleware peut prouver que la route fonctionne tout en sautant le contrôle examiné.

Testez l'accès à l'objet, pas seulement les rôles. Deux utilisateurs peuvent être member dans des organisations différentes. Modifiez séparément les identifiants de ressource et de tenant pour détecter les références directes non sûres. Testez aussi endpoints groupés, exports, jobs de fond et resolvers GraphQL, qui contournent souvent les contrôles des handlers REST.

Faites échouer le contrôle lorsqu'une nouvelle route protégée n'a aucune règle. L'autorisation manquante devient alors un défaut mesurable. Le serveur doit refuser par défaut. Une règle d'acceptation explicite s'audite mieux qu'un code dispersé qui refuse quelques mauvais cas connus.

Les agents réutilisent souvent un handler voisin, gardent son chemin de réussite et perdent le contrôle de propriété. La matrice rend cette omission visible et donne un contrat stable lorsque rôles ou règles de tenant changent.

Testez l'autorisation après normalisation des entrées. Casse, formats d'identifiants alternatifs, paramètres dupliqués et références imbriquées peuvent envoyer des requêtes équivalentes sur des chemins différents. Testez l'endpoint direct et toute route batch ou import qui atteint l'action. Si un worker effectue l'écriture finale, transmettez le contexte de l'acteur et du tenant au job au lieu d'en faire un utilisateur tout-puissant.

Enregistrez la décision attendue et la règle qui la produit, sans exposer les données privées. Un échec utile nomme la classe d'acteur, l'action, la classe d'objet et le statut attendu. Il ne copie ni jeton d'accès ni dossier complet. Le reviewer distingue alors un fixture cassé d'un vrai changement de privilèges.

La répétition de migration mesure les verrous et la réversibilité

Le contrôle de migration doit appliquer chaque changement de schéma sur une copie à l'échelle de production, lancer des sondes de compatibilité et mesurer durée, verrous et rollback avant le merge. Une migration réussie sur une base vide prouve peu.

Utilisez un snapshot assaini ou des données générées avec des tailles de tables, index, contraintes et distributions similaires. Les données exactes de production n'ont rien à faire dans l'infrastructure de pull request. Il faut recréer la pression sans copier d'enregistrements personnels ou confidentiels.

Répétez la vraie séquence de déploiement. Si d'anciennes instances restent actives pendant la migration, testez l'ancien code sur le nouveau schéma et le nouveau code sur le schéma transitoire. Ajouter une colonne nullable est généralement compatible. La renommer en une fois peut casser toutes les anciennes instances encore en service.

Enregistrez une preuve lisible par machine :

{"migration":"20260727_add_project_state","apply_ms":18420,"max_lock_ms":310,"old_app_probe":"pass","new_app_probe":"pass","down":"pass"}

Fixez des seuils par base et classe de table. Un verrou de 300 millisecondes est anodin sur une table et perturbant sur une autre. Le reviewer doit voir le seuil choisi, la mesure et la version de base de l'essai.

Sur PostgreSQL, inspectez les opérations qui réécrivent une table, valident une contrainte ou construisent un index en bloquant les écritures. Préférez l'expansion puis la contraction : ajoutez la forme, déployez du code compatible avec les deux, remplissez par lots contrôlés, changez les lectures, puis supprimez l'ancienne forme plus tard. Un pull request de plus coûte moins qu'une improvisation pendant une panne.

Toutes les migrations n'ont pas de down sûr. Supprimer une colonne perd les données, inverser une transformation peut être ambigu. Exigez alors une récupération vers l'avant ou un point de restauration testé. Qualifier une migration irréversible de sûre parce qu'un fichier down existe est trompeur.

Testez les reprises et échecs partiels. Un déploiement peut s'arrêter après la création d'un index et avant l'enregistrement de la migration. La tentative suivante ne doit ni corrompre l'état ni échouer sans fin. Interrompez l'essai à une limite contrôlée, relancez et comparez schéma et registre. Un long backfill doit reprendre à un curseur enregistré, et un lot relancé ne doit ni dupliquer ni supprimer de données.

Mesurez aussi le disque et la réplication. Une réécriture de table peut consommer de l'espace temporaire, gonfler les journaux d'écriture et retarder les répliques. Une prédiction parfaite n'est pas nécessaire, mais enregistrez les valeurs sur les données d'essai et comparez-les aux limites du responsable de la base. Sinon, une migration locale rapide peut remplir un volume de production.

La vérification du rollback doit exécuter la récupération

Le contrôle doit déployer le candidat dans un environnement isolé, créer un état représentatif, déclencher la méthode de rollback prise en charge et prouver que la version précédente lit et écrit encore correctement. Un plan écrit ne constitue pas une vérification.

Séparez rollback applicatif et rollback des données. Rebasculer le trafic vers l'ancien binaire peut prendre quelques secondes, tandis qu'un schéma destructif ou une transformation peut être irréversible. Le contrôle doit rendre les deux résultats. Si l'ancienne application ne fonctionne pas avec le nouveau schéma, marquez le candidat comme non réversible et exigez un déploiement progressif.

Une séquence pratique :

1. Déployer le commit main actuel et créer des enregistrements représentatifs.
2. Passer au livrable du pull request et exercer les chemins modifiés.
3. Créer de nouveaux enregistrements dans l'état mis à jour.
4. Restaurer le livrable précédent ou le snapshot avec le contrôle documenté.
5. Lancer les sondes de lecture, écriture, file et jobs de fond.

Le check conserve identifiants de livrables et snapshots, horodatages et résultats, sans identifiants secrets ni données client copiées. Mesurez le temps de récupération comme preuve de votre objectif opérationnel, pas comme promesse universelle.

Les snapshots ne servent que si quelqu'un prouve qu'ils contiennent tout le nécessaire. Fichiers, object storage, état des files, changements de schéma et effets externes peuvent se trouver hors du snapshot serveur. Listez ces limites. Un paiement, e-mail ou webhook déjà envoyé ne revient pas avec la base.

Rendez la sonde plus forte qu'un health check. Lisez un enregistrement créé avant la mise à jour et un après, modifiez les deux si la compatibilité le permet, et traitez un job de chaque version. Comparez la sortie visible, pas seulement les codes. Un serveur qui répond 200 tout en perdant un champ ou en lisant mal un enum n'est pas restauré.

Testez le contrôle qu'utilisera l'astreinte. Si le rollback de production exige de choisir un livrable, restaurer un snapshot ou changer le trafic, l'essai doit employer la même interface et les mêmes permissions. Un script privé sur l'ordinateur d'un ingénieur n'est pas un contrôle d'exploitation. La preuve doit montrer que le rôle opérateur restaure sans droits administrateur permanents.

Koder.ai prend en charge l'export du source, le déploiement et l'hébergement, les snapshots et le rollback. Les applications créées sur la plateforme peuvent utiliser ces livrables concrets dans le contrôle au lieu de décrire la récupération dans un paragraphe. La règle reste identique ailleurs : exécuter le contrôle et sonder l'application restaurée.

Un check obligatoire doit résumer les sept contrôles

La décision finale doit exiger un check de politique stable qui vérifie les sept résultats pour le commit de tête exact. Les noms de jobs changent, les matrices se multiplient et les chemins optionnels sautent du travail. Un petit agrégateur empêche la protection de branche de dériver.

Chaque contrôle doit émettre un résultat signé ou attesté par la plateforme contenant commit, version de politique, résultat et emplacement de la preuve. L'agrégateur refuse les résultats absents, anciens, neutres ou annulés. Il ne déduit jamais un succès d'un job qui n'a rien publié.

{
  "commit": "abc123",
  "policy": "merge-gates-v3",
  "results": {
    "tests": "pass",
    "codeql": "pass",
    "dependency_review": "pass",
    "secret_scan": "pass",
    "authorization": "pass",
    "migration_rehearsal": "not_applicable",
    "rollback_verification": "pass"
  },
  "decision": "allow"
}

Définissez un chemin d'override étroit pour les urgences. Exigez un mainteneur nommé, une seconde approbation, une raison écrite, une expiration et une issue de suivi. L'agent ne demande ni n'approuve sa propre exception. Publiez les overrides avec les résultats ordinaires afin qu'ils restent visibles après l'incident.

Ces contrôles ajoutent des minutes à certains pull requests et beaucoup plus aux migrations. C'est acceptable si ce temps achète des preuves précises. Lancez les contrôles bon marché d'abord, annulez les commits dépassés, mettez en cache les entrées fiables et réservez l'essai complet aux chemins concernés. N'affaiblissez pas un contrôle pour rendre le tableau vert plus vite.

Commencez par rendre le comportement actuel observable. Placez les sept noms dans un fichier de politique, reliez chacun à un résultat obligatoire et forcez le travail ignoré à s'expliquer. Le premier pull request d'agent incapable de produire ce dossier aura trouvé un trou dans la livraison avant la production.