Un manager affirme que la revue de code est morte. Son équipe n’est pas d’accord. Quelqu’un répond par la question qui tranche vraiment : si vous êtes soumis à SOC 2, comment fusionnez-vous sans qu’un humain approuve la modification ? Un praticien de la conformité répond, à juste titre, que le cadre ne se soucie pas de la manière dont l’approbation est obtenue, mais seulement que le processus documenté soit suivi. Cette réponse est exacte, et c’est là que commence la partie intéressante, car le processus qu’une équipe devrait documenter est plus étroit et plus étrange que ce que les deux parties du débat supposent.
Les outils disponibles aujourd’hui pour cela sont réels et opérationnels : Greptile, GitHub Copilot code review, Claude Code, chacun lisant les pull requests en ce moment même. La question utile n’est donc pas de savoir si une IA est autorisée à approuver une modification. C’est de comprendre ce que SOC 2 exige réellement de cette approbation, et ce qu’un signal de revue de code est conçu pour indiquer, par opposition à ce qu’une approbation de conformité doit encore établir par elle-même.
Ce que CC8.1 exige réellement
La gestion des changements dans SOC 2 est couverte par un seul critère, CC8.1. En termes simples, il exige qu’une modification soit autorisée, développée, configurée, documentée, testée, approuvée et mise en œuvre via un processus défini, afin que les modifications atteignent la production de manière délibérée plutôt que par accident. Il énumère les étapes qu’une modification doit franchir et s’attend à ce que vos modifications les franchissent effectivement.
Le mot qui porte tout le débat est « approuvé ». Le critère nomme l’étape. Il ne précise pas qui, ou quoi, l’effectue. Les critères de SOC 2 sont rédigés pour être basés sur des principes et neutres sur le plan technologique : vous définissez le contrôle qui répond au critère, et l’auditeur teste le contrôle que vous avez défini, tel que rédigé, sur la période. Rien dans CC8.1 ne dit que l’approbateur doit être une personne. Une politique qui autorise l’approbation automatisée pour une catégorie définie de modifications peut y répondre, à condition que le contrôle soit délimité, documenté, fonctionne comme vous l’avez décrit, et que votre auditeur l’accepte comme tel.
Ceci n’est pas hypothétique. Des équipes réécrivent déjà leur politique de gestion des changements pour que les modifications à faible risque puissent être approuvées par des moyens automatisés, l’approbation humaine étant réservée aux modifications au-dessus d’un seuil de risque qu’elles définissent. C’est une posture CC8.1 défendable lorsque vous pouvez en apporter la preuve. C’est une politique, appliquée et testée, et non son absence.
Les trois points que « l’IA l’a approuvé » ignore
Premièrement, la séparation des tâches. Une approbation n’a de valeur que si l’approbateur est indépendant de l’auteur. C’est l’attente la plus ancienne en gestion des changements : la personne qui a écrit la modification n’est pas la seule à la valider, afin qu’aucun acteur unique ne puisse pousser ce qu’il veut en production. « L’IA l’a approuvé » se heurte directement à cela. Si le même agent rédige le diff et l’approuve, ou si deux automatisations le font sans vérification indépendante entre elles, vous avez confondu auteur et approbateur. C’est ce point que l’auditeur examinera, et non le mot « IA ».
Deuxièmement, la politique doit effectivement le stipuler. Un auditeur ne teste pas vos intentions, mais votre processus documenté par rapport à ce qui s’est passé. « Le bot de revue était satisfait » n’est pas un contrôle à moins que votre politique de gestion des changements définisse ce réviseur : ce qu’il est, quelles modifications il peut approuver, ce qu’il vérifie, et quand une intervention humaine est encore requise. Sans cela, une approbation automatisée n’est pas un contrôle fonctionnant comme prévu. C’est une fusion avec un commentaire de robot joint.
Troisièmement, la traçabilité des preuves est la même dans les deux cas. Ce qu’un auditeur échantillonne ne change pas parce qu’un bot a approuvé : il veut voir que la modification a été autorisée, qu’elle a été testée, qui ou quoi l’a approuvée, et que tout cela est lié à la modification et consigné. L’approbation automatisée respecte CC8.1 lorsqu’elle produit cette traçabilité pour chaque modification qu’elle traite. Si elle ne laisse pas de trace, elle n’a pas remplacé le contrôle, elle l’a ignoré.
Un détail technique que le fil de discussion omet : un commentaire n’est pas une approbation
Sous la philosophie, il y a un détail technique qui pèse plus que la philosophie elle-même. Dans le modèle de GitHub, un réviseur IA laissant un retour et un réviseur IA émettant une action d’approbation sont deux choses différentes, et les outils cités ne font pas tous la seconde.
GitHub Copilot code review, disponible depuis 2025, publie ses retours sous forme de Comment review par conception. Selon la description de GitHub lui-même, il ne compte pas pour les approbations requises et ne bloque ni ne débloque une fusion. Donc « laisser Copilot approuver » n’est pas, mécaniquement, quelque chose que Copilot fait : un humain requis, ou une règle d’auto-fusion que vous avez configurée, émet toujours l’action d’approbation. L’action de pull request de Claude Code lit les modifications et, selon la manière dont vous la configurez, publie ses retours sous forme de commentaires ou d’un événement de revue formel, donc ce qu’il soumet, et si cela peut satisfaire une règle de protection de branche, est quelque chose que vous configurez et vérifiez. Greptile lit chaque pull request pour détecter les bugs et les problèmes de qualité avec le contexte de l’ensemble de la base de code et signale les problèmes sur la modification.
Donc « l’IA peut approuver » est une décision de configuration autant qu’une décision de politique. Quel outil émet quel signal, ce que ce signal est autorisé à contrôler, et où la trace de ce signal est enregistrée sont des éléments que vous définissez intentionnellement, dans les règles du dépôt et la protection des branches, et non des choses qui découlent d’un tweet. Définissez-les délibérément, car cette configuration est le contrôle que votre auditeur testera réellement.
Une revue verte n’est pas une revue de conformité
Même une fois les aspects techniques réglés, le fil de discussion passe sous silence une question plus difficile. Chacun de ces outils est conçu pour répondre aux questions que la revue de code a toujours posées : est-ce correct, et est-ce sûr. Ce sont les bonnes questions à poser pour un diff, et de bonnes questions à automatiser. Mais savoir si la modification respecte toujours les cadres pour lesquels vous êtes audité est une question différente.
Cette deuxième question dépend des contrôles que vous avez documentés et de ce sur quoi votre dernier audit s’est appuyé, et ce n’est pas une propriété du code qu’un réviseur de bugs peut déduire du diff. Une modification peut être correcte, sûre, passer toutes les vérifications automatisées, et pourtant affecter un contrôle qui sera échantillonné. Voici un exemple concret.
export const auditLog = {- retentionDays: 365,+ retentionDays: 30, // trim storage cost}Propre, correct et moins coûteux : rien ici n’est un bug ou une vulnérabilité. SOC 2 ne fixe pas de durée de conservation, mais votre propre contrôle de journalisation et de surveillance, oui, et il dépend de l’existence de ces journaux pendant la durée à laquelle vous vous êtes engagé à les conserver. Si votre contrôle ou les preuves d’audit supposent une fenêtre plus longue, les événements plus anciens que la nouvelle durée ne pourront plus être consultés, et un audit qui échantillonne la période constatera que les journaux ne la couvrent plus. Définissez la durée de conservation en fonction des besoins de votre contrôle et de vos preuves, et non uniquement en fonction de la facture de stockage.
Où heygrc intervient
Cette modification de la durée de conservation est propre et correcte en soi, ce qui explique précisément pourquoi une question de conformité peut rester ouverte même après que tous les signaux de revue de code sur celle-ci sont verts. Donc, lorsqu’une politique indique qu’une modification a été « approuvée par des moyens automatisés », la question honnête à poser est : approuvée comme correcte, ou approuvée comme conforme ? Ce sont deux approbations différentes, et dans ce fil de discussion, une seule d’entre elles était sur la table.
heygrc est conçu pour la seconde. Il lit chaque pull request par rapport aux cadres que vous devez respecter et identifie le contrôle exact qu’une modification touche, au niveau du diff, qu’elle ait été écrite par une personne ou un agent. Il ne cherche pas à être un vérificateur de bugs : gardez Greptile, Copilot ou Claude Code pour la correction et la sécurité, les rôles pour lesquels ils sont conçus, et utilisez heygrc pour la lecture de conformité distincte, rapportée de la seule manière qui donne de la valeur à une constation de conformité, en citant la clause.
Si vous allez autoriser l’approbation automatisée à fusionner des modifications à faible risque sous CC8.1, c’est une direction raisonnable. Une lecture automatisée de la conformité est la vérification manquante qui vous aide à déterminer quelles modifications sont réellement à faible risque en premier lieu. Les exemples ici sont illustratifs, du type de modification qui soulève la question plutôt que des données de télémétrie que nous revendiquons. Mais le principe tient par lui-même : SOC 2 n’a jamais exigé qu’un humain approuve vos pull requests. Il a exigé que quelqu’un, ou quelque chose, les approuve de manière traçable, indépendamment, conformément à un processus que vous avez documenté. Qu’un réviseur de code soit satisfait ne signifie pas que ce processus a été suivi.