Comment faire cela sans rompre un contrôle ?

Journalisez les événements liés à la sécurité (qui a fait quoi et quand), incluez toujours l'acteur, écrivez-les dans un stockage durable et empêchez une suppression ultérieure de les effacer. SOC 2 (CC7.2) et ISO 27001 (A.8.15) exigent tous deux cela et vérifient par échantillonnage des événements effectivement enregistrés.

Ne placez jamais la clé dans le code source. Lisez-la depuis les variables d'environnement ou un magasin de secrets géré à l'exécution, gardez-la hors du dépôt et des journaux, et faites tourner tout secret ayant été validé. L'ISO 27001 A.8.24 (et la simple prudence) exige que les clés soient gérées, pas codées en dur.

Assurez-vous que la suppression atteint tous les endroits où les données de la personne sont stockées : la base de données principale, les caches, les index de recherche, les outils d'analytics, les sauvegardes (avec leur propre cycle de vie documenté) et tout processeur tiers auquel vous avez transmis les données. Lorsque le droit à l'effacement (RGPD Art. 17) s'applique, une copie oubliée est ce qui le contredit, donc la suppression doit les atteindre toutes.

Fixer la version, vérifier ce que vous téléchargez (via un fichier de verrouillage et des vérifications d'intégrité), éviter d'exécuter des scripts d'installation distants, et privilégier votre registre ou miroir validé. La NIS 2 (Art. 21(2)(d)) considère vos dépendances comme faisant partie de la sécurité de la chaîne d'approvisionnement, et les contrôles qui leur sont appliqués se trouvent dans votre manifeste et votre processus de build.

Activez le chiffrement au repos pour chaque stockage contenant des informations de santé protégées électroniques (la base de données, les buckets, les volumes, les sauvegardes), ou documentez pourquoi une mesure de protection équivalente est en place. La spécification de chiffrement de HIPAA (164.312(a)(2)(iv)) est adressable : appliquez-la lorsque c'est raisonnable, ou enregistrez une alternative équivalente, plutôt que de l'ignorer.

Accordez uniquement les accès nécessaires à chaque rôle ou service, refusez par défaut et évitez les autorisations génériques. SOC 2 (CC6.1) vérifie l'accès logique, et le principe du moindre privilège est ce qu'un auditeur échantillonne : chaque identité peut-elle faire uniquement ce que son rôle exige, et rien de plus ?

Journalisez des références et des codes minimaux, pas le contenu complet. Enregistrez un identifiant de requête ou de commande, masquez les champs personnels avant toute écriture, et ne journalisez jamais l'intégralité de la requête ou de l'objet utilisateur. Journaliser moins de données, et moins de données identifiantes, est au cœur de la minimisation des données du RGPD (Art. 5(1)(c)). Traitez un identifiant pointant vers une personne comme une donnée personnelle également, et limitez-vous à ce dont vous avez réellement besoin pour l'enquête.

Validez la cible avant de la récupérer : exigez https, résolvez l'hôte et rejetez les adresses privées, internes et locales (y compris les points de terminaison des métadonnées cloud). Privilégiez une liste autorisée lorsque les destinations sont connues, et ne suivez pas les redirections aveuglément. La falsification de requête côté serveur est un problème de validation des entrées (NIST 800-53 SI-10), et la vérification doit être effectuée dans le code qui émet la requête.

Une exportation est une nouvelle copie de données personnelles, traitez-la donc comme telle : attribuez-lui une date d'expiration pour qu'elle ne dépasse pas sa finalité, exportez uniquement les champs et les lignes nécessaires à cette finalité, et ne laissez pas une exportation récurrente devenir un second stockage permanent et non maîtrisé. C'est ce que prévoit la limitation de la conservation des données du RGPD (Art. 5(1)(e)).

Utilisez la tokenisation de votre processeur de paiement pour que les détails bruts de la carte soient envoyés directement à celui-ci, sans passer par vos serveurs. Stockez le jeton retourné et les quatre derniers chiffres pour l'affichage, et ne conservez jamais le numéro de carte complet ni le code de vérification. Cela vous permet de respecter l'exigence 3 de PCI DSS et réduit la portée de la conformité PCI qui s'applique à vous.

Si une décision concernant une personne est prise uniquement par un algorithme et a un effet juridique ou tout aussi significatif sur elle (refus de remboursement, de prêt, de compte), l'Art. 22 du RGPD l'encadre : en règle générale, la personne a le droit de ne pas être soumise à une décision entièrement automatisée de ce type. Lorsque cette décision est néanmoins autorisée (par exemple parce qu'elle est nécessaire à l'exécution d'un contrat ou basée sur le consentement explicite de la personne), l'Art. 22(3) exige des garanties, notamment la possibilité d'obtenir une intervention humaine, d'exprimer un avis et de contester le résultat. Dans tous les cas, ne laissez pas la branche automatisée avoir le dernier mot : orientez ces décisions vers un parcours où une personne peut les réviser.

Limiter l'accès aux fonctions sensibles est l'objectif de SOC 2 CC6.1 (contrôles d'accès logiques), et pour les actions privilégiées, une session valide n'est généralement pas suffisante à elle seule. Exigez un second facteur au moment de l'action privilégiée, refusez par défaut en son absence, et enregistrez la vérification, afin qu'atteindre un chemin d'administration nécessite plus qu'une session volée ou persistante.

Trois types de réviseurs automatisés analysent aujourd'hui une pull request : les réviseurs de code qui recherchent les défauts, les réviseurs de sécurité qui recherchent les vulnérabilités, et les réviseurs de conformité qui évaluent les modifications par rapport aux cadres que votre entreprise doit respecter. heygrc est un réviseur de conformité pour les pull requests : il examine chaque PR par rapport aux cadres que vous sélectionnez et cite le contrôle spécifique qu'une modification affecte, par exemple ISO 27001 A.8.15 ou SOC 2 CC6.1. À notre connaissance, c'est le premier réviseur de conformité pour les pull requests (juillet 2026).

La plupart des plateformes GRC et d'automatisation de la conformité s'intègrent à GitHub au niveau du compte et du dépôt : elles lisent les paramètres tels que la protection des branches et les revues obligatoires comme preuves que votre contrôle de gestion des modifications fonctionne. Cette intégration lit la configuration, pas le code. Examiner la pull request elle-même, lire les lignes modifiées et identifier le contrôle qu'elles mettent en risque, est une tâche différente. heygrc fait ce travail : une application GitHub qui examine chaque pull request par rapport aux frameworks sélectionnés et publie les résultats sous forme de vérification sur la PR.

Un audit est un indicateur retard : il échantillonne ce qui a été déployé il y a des mois, lorsque la violation est déjà en production et coûteuse. La revue de code est l'indicateur avancé, le dernier moment où une violation peut être évitée d'un clic. Pour la détecter à ce stade : identifiez quels contrôles résident effectivement dans le code, intégrez la question de conformité à la lecture de chaque diff, ancrez chaque signalement dans la clause spécifique et conservez la trace pour que la revue elle-même devienne une preuve d'audit.

Examinez le code généré par l'IA selon les mêmes critères que le code humain : l'auditeur ne demandera pas qui a écrit une modification, mais seulement si le contrôle a fonctionné. Ce qui change avec les agents, c'est le volume et les schémas d'échec. Un agent optimise pour la tâche visible, donc le code de contrôle perçu comme une friction (une ligne de journalisation, une vérification de permission, une limite de conservation) est en danger dans ses diffs. De plus, les agents ouvrent plus de pull requests qu'une lecture humaine de conformité ne peut suivre. Automatisez la première passe ; réservez l'intervention humaine aux décisions critiques.

Oui. heygrc est une application GitHub qui examine chaque pull request par rapport à ISO 27001:2022 et cite le contrôle spécifique de l'Annexe A concerné par une modification, par exemple A.8.15 pour un journal d'audit désactivé ou A.8.24 pour une cryptographie affaiblie. Vous l'installez sur vos dépôts, sélectionnez ISO 27001 et tout autre cadre applicable, et elle publie les résultats sous forme de commentaires de révision ainsi qu'un statut de vérification qui ne bloque pas la fusion sauf si vous l'exigez. À notre connaissance, il s'agit du premier outil de conformité pour les pull requests (juillet 2026).

Seulement si vous le souhaitez. Un contrôle de conformité sur une pull request doit par défaut avoir un statut neutre : il publie les résultats et un état de vérification, et la décision de fusion reste entre les mains de l'ingénieur. Les équipes qui veulent un blocage strict peuvent exiger le contrôle dans la protection de branche, ce qui transforme le même signal en bloqueur sur les branches qu'elles choisissent. heygrc fournit le statut neutre par défaut et prend en charge la configuration de contrôle requis.