Dans une équipe qui s'appuie sur des agents de codage, ces agents ouvrent une grande partie des pull requests qui sont déployées, et ils sont souvent performants pour la tâche visible : la fonctionnalité fonctionne, les tests passent, les dépendances sont à jour. Ce qu'un agent n'a aucune raison d'évaluer, c'est si une modification a affecté un contrôle sur lequel votre entreprise est auditée, car cette obligation relève de vos cadres de référence et de votre contexte, et non du diff qu'il a été chargé de produire. C'est ce vide qu'une vérification de conformité pour le code généré par IA comble.
Les recapitulatifs existants des outils de conformité pour le code IA désignent généralement l'une de ces trois choses : l'analyse statique des bugs, le scan des dépendances et des licences, ou la détection des secrets. Ces outils sont utiles et valent la peine d'être utilisés. Aucun d'entre eux n'est conçu pour analyser une modification par rapport à SOC 2, ISO 27001 ou le RGPD au niveau d'un contrôle spécifique, ce qui est une question différente posée à la même pull request.
Ce que signifie la conformité ici, au niveau des contrôles
La conformité pour le code généré par IA ne consiste pas à vérifier les en-têtes de licence ou les scores de vulnérabilité. Il s'agit de déterminer si une modification a touché un contrôle que vous êtes tenu de maintenir : une frontière d'accès logique, un enregistrement de journal d'audit, un niveau minimal de chiffrement, une limite de conservation. Ces obligations sont définies dans les cadres de référence sélectionnés par votre entreprise, à un niveau de granularité vérifiable, par exemple ISO 27001:2022 A.8.15 pour la journalisation ou RGPD Art. 5(1)(c) pour la minimisation des données.
La raison pour laquelle il s'agit d'une lecture distincte est qu'une modification pertinente pour un contrôle est généralement du code correct. Il compile généralement, il est sûr, il est correctement licencié et il fait ce que l'agent lui a demandé de faire. Le problème n'est pas un défaut dans la modification ; c'est que la modification a discrètement modifié quelque chose qu'un auditeur pourrait examiner plus tard. Une vérification qui ne recherche que des défauts n'est pas conçue pour signaler cela.
Un exemple concret : un agent enrichit un profil avec plus de données que nécessaire
Supposons qu'un agent soit chargé d'ajouter un badge de niveau de fidélité à la page de compte. Pour calculer le niveau, il ajoute un cache user_profile et le remplit à partir du service d'identité. La manière la plus simple de procéder, et celle qu'un agent optimisant pour la tâche pourrait choisir, consiste à copier l'intégralité de l'enregistrement d'identité dans le nouveau stockage : date de naissance, numéro d'identification nationale, adresse, numéro de téléphone, ainsi que le niveau et le nom d'affichage que le badge utilise réellement.
La migration est propre et la fonctionnalité fonctionne du premier coup. Mais le nouveau stockage contient désormais quatre catégories de données personnelles dont le badge de fidélité n'a pas besoin. Cela relève de la minimisation des données, RGPD Art. 5(1)(c) : les données personnelles doivent être adéquates, pertinentes et limitées à ce qui est nécessaire pour la finalité. La correction consiste en une ligne d'intention : remplir le cache uniquement avec le niveau et le nom d'affichage. Il est moins coûteux de la faire dans la pull request qui a introduit le stockage, tant que l'auteur a encore le contexte. Si elle est laissée telle quelle, cela devient un nouveau stockage contenant des données personnelles inutiles pour sa finalité déclarée, découvert des mois plus tard.
Pourquoi les scanners de bugs, de vulnérabilités et de licences ne sont pas conçus pour détecter cela
La modification ci-dessus n'est pas du type que ces scanners sont conçus pour détecter : le code est correct, donc un scanner de bugs le valide ; aucune nouvelle dépendance n'a été ajoutée, donc un scanner de licences le valide ; et un scanner de vulnérabilités n'est pas conçu pour interpréter une augmentation de l'empreinte des données personnelles comme un résultat. Ainsi, les scanners conçus pour détecter ces éléments fonctionnent comme prévu lorsqu'ils les valident, car une modification pertinente pour un contrôle qui est par ailleurs propre n'est pas ce qu'ils sont conçus pour analyser. Ce n'est pas une critique à leur égard ; détecter les bugs, les vulnérabilités et les dérives de licences est réellement précieux, et la sortie d'un agent a besoin de tout cela.
Cela signifie qu'une lecture de conformité est une couche distincte, et non une version plus puissante du même scan. Elle analyse le diff par rapport aux cadres de référence auxquels vous êtes lié et identifie le contrôle que la modification a touché, ce qui est une information que les autres outils ne sont pas conçus pour produire. La posture raisonnable consiste à exécuter les deux : les scanners de qualité de code et de sécurité pour les défauts, et une vérification de conformité pour la dérive des contrôles, sur la même pull request.
Le changement qui rend cela urgent
Deux éléments changent lorsque les agents écrivent une grande partie du code. Volume : un agent ouvre plus de pull requests qu'une lecture de conformité humaine minutieuse ne peut suivre, donc la lecture devient soit un goulot d'étranglement, soit elle est ignorée. Forme des échecs : un agent optimise pour la tâche visible, donc le code de contrôle qui semble être une friction, une ligne de journalisation, une vérification de permission, une limite de conservation, est exactement le type de chose qu'un diff peut supprimer ou élargir sans s'en apercevoir.
Quelle que soit la personne qui a écrit une modification, l'auditeur évalue toujours si le contrôle a fonctionné, donc le code écrit par IA est soumis aux mêmes exigences que le code humain. Ce qui doit changer, c'est que la lecture de conformité doit désormais s'exécuter à la vitesse de la machine pour suivre le rythme, ce qui signifie automatiser la première passe et réserver le jugement humain pour les cas signalés.
Comment ajouter la vérification
Une vérification de conformité pour le code généré par IA s'exécute sur la pull request de la même manière que vos autres vérifications : elle se déclenche lorsqu'une PR est ouverte ou mise à jour, analyse le diff par rapport aux cadres de référence que vous avez sélectionnés et au contexte de votre entreprise, puis publie les contrôles qu'une modification touche avec la clause associée, sous forme de commentaire plus un statut neutre. Lorsqu'un agent ouvre la PR, la vérification rencontre le code là où l'agent l'a déjà placé, sans étape supplémentaire pour l'humain qui doit valider.
heygrc est conçu pour être cette vérification sous forme d'application GitHub : installez-le, configurez vos cadres de référence et votre contexte une fois (un seul appel REST que votre agent de codage peut effectuer pour vous), et il examine chaque pull request pour l'impact sur la conformité et cite le contrôle au niveau du diff. Il publie un statut de vérification neutre ainsi que des commentaires en ligne, afin d'informer plutôt que de bloquer, sauf si vous choisissez de l'exiger. Utilisez-le en complément de vos scanners de bugs et de sécurité, et non à leur place.