Quelle revue humaine faut-il au code assisté par IA ?

L'IA peut réduire le temps nécessaire pour rédiger une modification, mais elle ne raccourcit pas la liste des problèmes possibles en production. La revue humaine doit augmenter avec l'étendue des dégâts possibles, la sensibilité du code et la solidité des preuves jointes à la demande de fusion. La quantité de texte rédigée par une IA n'a presque aucune importance.

J'utilise quatre niveaux de revue. Une petite modification réversible dans un composant isolé peut demander un seul relecteur compétent et des tests ciblés. Une modification qui touche à l'identité, à l'argent, aux données de santé, aux autorisations, au déploiement ou à une dépendance partagée exige des relecteurs indépendants qui connaissent le domaine, des tests plus larges, des preuves de sécurité et une décision explicite de mise en production. Il ne s'agit pas de se méfier de l'IA. C'est un contrôle d'ingénierie normal appliqué à une source capable de produire du code plausible plus vite qu'une équipe ne peut l'examiner.

Une politique utile tient dans un dépôt, s'exécute dans l'intégration continue et indique précisément aux auteurs quelles preuves ils doivent fournir. Une politique qui affirme que chaque modification issue de l'IA réclame une attention particulière finira en approbation automatique d'une case. Une politique qui associe des faits observables à des contrôles nommés résiste à une journée de mise en production chargée.

Examinez la conséquence, pas l'auteur

Le bon niveau de revue dépend de ce que la modification peut affecter, et non de la personne qui l'a saisie, copiée, générée ou révisée après sa génération. La provenance reste importante, car les relecteurs doivent savoir ce qui a été vérifié indépendamment. Elle ne remplace pas la classification du risque.

Commencez par deux axes : la taille de la modification et la sensibilité du code. La taille ne se limite pas au nombre de lignes. Comptez les composants traversés, les interfaces publiques modifiées, les migrations de données ajoutées, les fichiers générés remplacés, les périmètres de configuration changés et les chemins d'exécution affectés. Une modification de douze lignes dans l'autorisation peut présenter plus de risques que deux mille lignes de données de test. La taille du diff aide à orienter la revue, mais ne mesure pas la sécurité.

La sensibilité tient à l'autorité du code et aux dégâts qu'une erreur pourrait causer. Considérez comme sensibles l'authentification, l'autorisation, la cryptographie, les secrets, la facturation, les données personnelles, les parcours cliniques, les autorisations d'infrastructure, les pipelines de compilation, les manifestes de dépendances et les opérations destructrices sur les données. Ajoutez les domaines propres au produit, tels que les règles de droits ou les limites de sécurité. Conservez cette liste dans le contrôle de versions pour empêcher un auteur de la réinterpréter discrètement lorsqu'une échéance approche.

La réversibilité constitue le troisième fait qui change la réponse. Un libellé erroné sur une page derrière une option peut être désactivé en quelques minutes. Une migration qui supprime des colonnes, un événement publié auprès de consommateurs externes ou un identifiant exposé dans un journal ne peuvent pas être rappelés proprement. Relevez le niveau lorsque le retour en arrière dépend d'une restauration de données, de la coordination avec une autre équipe ou d'une action demandée aux clients.

Une classification pratique consigne ces faits dans la demande de fusion au lieu de demander une note de risque floue :

Quels services, magasins de données et interfaces publiques changent ?
Le code prend-il ou applique-t-il une décision de sécurité ou de métier ?
L'équipe peut-elle revenir en arrière sans perdre ni retraiter des données ?
La modification touche-t-elle aux dépendances, aux instructions de compilation ou aux autorisations de déploiement ?
Quelles preuves montrent que le nouveau comportement fonctionne et que l'ancien fonctionne toujours ?

Ne laissez pas les auteurs choisir un niveau faible sur leur seule intuition. Les règles du dépôt peuvent relever automatiquement une modification lorsqu'elles détectent des chemins protégés, des dossiers de migration, des manifestes de paquets, des fichiers d'infrastructure ou un diff volumineux. Un relecteur peut aussi relever le niveau après avoir examiné la conception. Une baisse de niveau doit exiger une justification enregistrée et le nom de la personne qui l'a acceptée.

Quatre niveaux rendent la politique utilisable

Quatre niveaux suffisent à la plupart des équipes. Davantage de catégories provoquent des discussions sur les étiquettes, tandis qu'un nombre inférieur force le travail courant et le travail dangereux à passer par le même contrôle. Le nom des niveaux compte moins que leurs conditions d'entrée et les preuves demandées.

Le niveau 1 couvre les modifications limitées et réversibles. Il comprend par exemple les textes, les styles isolés, les données de test, les commentaires et les petites refactorisations internes sans changement de comportement. Exigez la compilation normale, l'analyse de style, les tests unitaires concernés et un relecteur qui connaît ou possède la zone. La fusion automatique peut convenir après approbation si la protection de branche empêche l'auteur d'approuver sa propre modification et si tous les contrôles obligatoires réussissent.

Le niveau 2 couvre le comportement courant en production. Il comprend une logique fonctionnelle limitée, un comportement d'API qui préserve le contrat, des corrections dans du code établi et des modifications de configuration modestes. Exigez un relecteur indépendant, des tests ciblés sur le comportement modifié, toute la suite de tests affectée, une analyse statique, la recherche de secrets et une revue propre des dépendances. La demande de fusion doit expliquer ce que l'IA a produit, ce que l'auteur a ensuite modifié et quelles affirmations il a vérifiées sans se fier à l'explication générée.

Le niveau 3 couvre les modifications sensibles ou larges. Placez ici l'identité, le contrôle d'accès, le parcours de paiement, les données de santé, les migrations, les bibliothèques partagées, les règles de déploiement, les contrats publics et les modifications qui traversent plusieurs composants. Exigez deux relecteurs, dont un responsable du domaine ; ajoutez des tests d'intégration ou de bout en bout à la frontière qui porte le risque ; lancez l'analyse de sécurité adaptée au langage ; examinez les modifications de dépendances et de fichiers de verrouillage ; exigez un plan de déploiement et de retour en arrière. Le second relecteur ne doit pas répéter le premier. Confiez à l'un le comportement et la conception, à l'autre la sécurité, les données ou l'exploitation.

Le niveau 4 couvre les modifications aux conséquences graves ou difficiles à inverser. La conception cryptographique, les frontières de privilèges, la transformation massive de données, les règles d'identité en production, la confiance dans la compilation, l'aide à la décision clinique et un nouvel échange externe de données en sont des exemples. Exigez une revue de conception avant l'implémentation, des responsables nommés pour les domaines concernés, une modélisation des menaces, des tests d'abus et de panne, les preuves d'un déploiement progressif et une personne explicite qui accepte le risque résiduel. Certaines équipes imposent aussi un responsable de mise en production ou un comité de changement. Ne le faites que si cette personne possède le contexte et le pouvoir d'arrêter la mise en production ; une approbation cérémonielle ajoute du retard sans apporter de contrôle.

Une politique lisible par une machine permet de revoir l'association entre faits et niveaux. Cet exemple reste volontairement simple afin que chaque équipe l'adapte à son système de CI :

review_tiers:
  tier_1:
    approvals: 1
    checks: [build, lint, unit]
  tier_2:
    approvals: 1
    checks: [build, unit, affected_suite, static_analysis, secrets, dependencies]
  tier_3:
    approvals: 2
    required_roles: [code_owner, domain_owner]
    checks: [tier_2, integration, security_scan, rollback_test]
  tier_4:
    approvals: 3
    required_roles: [code_owner, security_owner, release_owner]
    checks: [tier_3, threat_model, misuse_tests, staged_release]
protected_paths:
  tier_3: [auth/, billing/, migrations/, infra/, package-lock.json]
  tier_4: [crypto/, production/identity/, clinical/decision-support/]

Cette configuration évite un échec courant : un auteur classe une modification d'autorisations comme petite parce que son diff compte huit lignes, obtient une approbation rapide et publie une branche qui accorde l'accès lorsqu'une requête échoue. Un chemin protégé relève le niveau avant tout débat sur le nombre de lignes. Les tests doivent alors couvrir le refus, les données manquantes et la panne du service, pas seulement la requête réussie.

Les tests doivent prouver l'affirmation risquée

Le nombre de tests dit peu de choses sur l'état de préparation d'une revue. La question utile consiste à savoir si les tests échoueraient face aux défauts plausibles introduits par cette modification précise. Le code généré arrive souvent avec des tests générés qui confirment la même hypothèse erronée. Une suite verte peut montrer la cohérence interne de deux artefacts faux.

Demandez à l'auteur de formuler l'affirmation risquée en termes simples, puis de la relier aux preuves. Pour un contrôle d'accès, l'affirmation pourrait être que seuls les professionnels de santé affectés à un cas peuvent consulter le dossier. Les preuves doivent couvrir un professionnel affecté, un autre qui ne l'est pas, un utilisateur sans rôle clinique, une réponse absente du service d'affectation et une session obsolète. Un test qui prouve le succès du professionnel affecté ne couvre que le cas favorable.

Les relecteurs doivent effectuer une mutation dans leur tête ou dans le code : remplacer && par ||, retirer le filtre du locataire, renvoyer un succès en cas d'exception ou faire réussir une collection vide. Si les tests proposés restent verts, ils ne protègent pas la décision. Les outils de tests par mutation peuvent automatiser une partie du travail, mais une mutation manuelle de cinq minutes suffit souvent à révéler un test généré qui répète simplement l'implémentation.

Exécutez les tests au niveau le plus étroit capable de réfuter l'affirmation, puis ajoutez des tests de frontière là où des composants peuvent diverger. Les tests unitaires conviennent aux branches et aux invariants. Les tests de contrat détectent les hypothèses incompatibles sur les requêtes et les réponses. Les tests d'intégration révèlent les contraintes de base de données, les frontières de transaction, les files d'attente, les caches et le middleware d'identité. Réservez les tests de bout en bout à un petit ensemble de parcours dont l'échec bloquerait la mise en production. Faire exécuter tous les tests de bout en bout à tous les niveaux gaspille du temps et apprend aux équipes à ignorer les résultats lents et instables.

Examinez les tests aussi soigneusement que le code de production. Surveillez les simulations qui contournent la couche d'autorisation, les jeux de données sans valeurs nulles réalistes, les assertions qui ne contrôlent que les codes d'état, les instantanés qui acceptent de nombreuses modifications sans rapport et les nouvelles tentatives qui cachent des situations de concurrence. L'IA produit très bien un volume de tests impressionnant autour d'une interface qu'elle a mal comprise.

L'auteur doit joindre les commandes exactes utilisées lorsqu'un contrôle local n'est pas déjà imposé par la CI. Un relecteur peut reproduire une exécution ciblée et voir une sortie de cette forme :

$ npm test access-policy.test.ts
PASS access-policy.test.ts
  assigned clinician can read (18 ms)
  unassigned clinician is denied (7 ms)
  missing assignment response fails closed (9 ms)
Tests: 3 passed, 3 total

La sortie ne constitue une preuve que si le commit de la demande de fusion l'a produite. Préférez les artefacts de CI liés au commit aux captures d'écran collées. Pour les niveaux 3 et 4, conservez les rapports de tests, les résultats d'analyse et les traces d'approbation avec la version afin que l'équipe chargée d'un incident puisse reconstruire ce qu'elle savait.

Le code sensible exige un regard de sécurité indépendant

Une revue générale du code et une revue de sécurité répondent à des questions différentes. La première demande si l'implémentation est correcte et maintenable. La seconde demande comment un attaquant, une dépendance compromise, une entrée malveillante ou un acteur interne trop privilégié pourrait pousser le système à enfreindre ses exigences de sécurité. Les réunir dans une seule case masque cette distinction.

L'OWASP Application Security Verification Standard offre aux équipes un vocabulaire utile pour ce travail. L'ASVS définit des niveaux de vérification de rigueur croissante et regroupe les exigences autour de domaines comme l'authentification, le contrôle d'accès, la validation, la cryptographie, la journalisation, la protection des données, les API et la configuration. Je ne copierais pas la totalité de la norme dans chaque demande de fusion. Associez les chemins sensibles du produit aux exigences applicables, puis rendez ces exigences visibles lorsqu'une modification touche ces chemins.

Le NIST SP 800-218 formule une idée proche dans son Secure Software Development Framework. Sa pratique de revue de conception demande une personne qualifiée qui n'a pas participé à la conception, des processus automatisés dans la chaîne d'outils, ou les deux, et elle demande aux équipes d'enregistrer les conclusions comme artefacts. La qualification compte. Une deuxième approbation prise au hasard ne répond pas à l'intention quand aucun relecteur ne comprend la frontière de confiance modifiée.

L'analyse statique de sécurité des applications, la recherche de secrets et l'analyse des dépendances sont des contrôles utiles, mais elles ne peuvent pas décider si un infirmier doit voir le dossier d'un patient donné ni si une règle de remboursement permet un abus. Les outils trouvent des motifs. Les humains doivent examiner l'autorisation métier, l'isolation des locataires, le comportement en cas de panne, la portée de l'audit et le rapport entre les données collectées et les données réellement nécessaires.

Pour une modification de sécurité de niveau 3, demandez un court cas d'abus en plus du cas d'acceptation normal. Un bon cas d'abus nomme un acteur, la capacité qu'il ne devrait pas avoir, le chemin qu'il pourrait essayer et le contrôle qui l'arrête. Exemple : un utilisateur du support modifie l'identifiant de compte dans une requête ; l'autorisation côté serveur rejette la requête avant la recherche de l'enregistrement ; l'entrée d'audit consigne la tentative refusée sans stocker la charge sensible.

Le niveau 4 exige un modèle de menaces avant que l'implémentation devienne coûteuse à modifier. Restez concret : actifs, frontières de confiance, points d'entrée, capacités de l'attaquant, contrôles et décisions non résolues. Le responsable de la sécurité doit examiner le modèle et le code, tandis que le responsable du service vérifie les hypothèses opérationnelles telles que la disponibilité de l'identité, le comportement de l'horloge, la conservation des données et le retour en arrière.

N'approuvez pas du code sensible parce que l'IA l'explique de façon convaincante. Une explication générée peut justifier l'implémentation qu'elle reçoit, y compris si elle est défectueuse. Reliez chaque affirmation de sécurité à un test, une configuration, une décision de conception examinée ou un comportement observé de la plateforme.

Les dépendances apportent du code invisible dans le diff

Une modification d'une seule ligne dans un manifeste peut ajouter des milliers de lignes de code exécutable par les dépendances directes et indirectes. Une modification de dépendance constitue donc une dimension de revue distincte, pas une petite variante de la revue du code source. Classez toute nouvelle dépendance d'exécution et toute réécriture importante d'un fichier de verrouillage au niveau 2 au minimum. Relevez encore ce niveau si le paquet s'exécute pendant la compilation, traite des données non fiables, reçoit des secrets ou s'exécute dans un service sensible.

Un contrôle des dépendances doit répondre aux questions suivantes : quels paquets ont été ajoutés, supprimés et mis à jour ; si des paquets indirects ont changé ; si des vulnérabilités connues s'appliquent ; quelles licences entrent dans le produit ; si le registre et l'identité du paquet attendus correspondent. La revue des dépendances de GitHub, par exemple, compare les modifications entre les commits de base et de tête et peut imposer un seuil d'échec dans une demande de fusion. D'autres systèmes d'hébergement proposent un équivalent. Le résultat de la politique compte davantage que le fournisseur.

N'acceptez pas un diff immense du fichier de verrouillage sous prétexte que le gestionnaire de paquets l'a produit. Régénérez le fichier depuis le manifeste déclaré avec le gestionnaire de paquets fixé dans le dépôt, puis comparez le résultat. Les URL de registre inattendues, les scripts de cycle de vie, les noms de paquets trompeusement proches, les modifications d'intégrité et les mises à jour sans rapport méritent une enquête.

Les nouvelles dépendances exigent aussi un contrôle humain de leur nécessité. Une équipe ajoute souvent un paquet parce que le code généré l'importe, puis vérifie seulement si ce paquet possède une vulnérabilité publiée. Demandez si la bibliothèque standard ou une dépendance existante accomplit déjà la tâche, si le paquet est activement maintenu, quel code s'exécute à l'installation et quelle difficulté présenterait sa suppression. Les bases de vulnérabilités signalent des défauts connus ; elles ne peuvent pas dire qu'un paquet élargit inutilement la confiance.

Pour les versions de niveaux 3 et 4, conservez une nomenclature logicielle lorsque le système de compilation peut la produire et gardez la provenance de l'artefact compilé. SLSA considère la provenance comme des informations vérifiables sur le lieu, la date et la manière dont un artefact a été produit. Cela ne prouve pas que le code est sûr, mais permet au relecteur de relier l'artefact déployé au code source et au processus de compilation examinés.

Des approbateurs explicites évitent les validations vides

Deux approbations ne servent à rien si chaque relecteur suppose que l'autre a vérifié la sécurité, le comportement des données et le déploiement. Chaque approbation obligatoire doit porter sur un sujet nommé. Les responsables du code peuvent orienter une modification vers des personnes, mais le modèle de demande de fusion doit dire à chacune quelle décision elle prend en charge.

Utilisez des rôles adaptés au risque : responsable de l'implémentation, du domaine, de la sécurité, des données et de la mise en production. Une modification de niveau 2 peut n'exiger qu'un responsable de l'implémentation. Une migration qui transforme des données de patients pourrait demander un responsable du domaine pour vérifier leur sens, un responsable des données pour vérifier la migration et la récupération, et un responsable de la sécurité ou de la confidentialité pour contrôler l'exposition. Une même personne qualifiée peut remplir deux rôles, mais la trace doit le préciser.

L'auteur ne peut pas fournir l'approbation indépendante. La personne qui a rédigé les instructions pour l'IA ne devient pas indépendante au motif que le modèle a produit le code. L'auteur assume la modification : il doit la comprendre, la modifier, la tester et expliquer ses limites. S'il ne peut pas expliquer une branche ou une dépendance, la revue doit s'arrêter jusqu'à ce qu'il y parvienne.

Les commentaires d'approbation doivent consigner une décision, pas une formule sociale rassurante. Une approbation utile de niveau 3 pourrait indiquer : isolation des locataires examinée dans les couches de requête et de service ; refus reproduit pour un utilisateur d'un autre locataire ; retour de migration vérifié avec une copie de données représentatives ; acceptation du risque restant d'une brève pause d'écriture pendant le retour. Cette note donne au responsable de mise en production et à la future équipe d'incident des informations concrètes.

Annulez les approbations lorsque l'auteur pousse une modification substantielle après la revue. Définissez autant que possible ce caractère de façon mécanique : changement d'un chemin protégé, d'un fichier de dépendances, d'une migration, d'une autorisation ou diff supérieur à une petite limite configurée. Une faute de frappe dans un commentaire ne doit pas relancer une revue à trois personnes, mais un nouveau traitement d'erreur dans un chemin d'autorisation doit le faire.

Évitez l'approbation par épuisement. Les grandes demandes de fusion générées sont difficiles à examiner, car le modèle peut les produire rapidement alors que le relecteur lit toujours à vitesse humaine. Fixez une limite de taille raisonnablement vérifiable, puis demandez à l'auteur de séparer les modifications indépendantes ou de fournir une suite de commits qui isole les changements mécaniques des changements de comportement. Ne réduisez pas l'examen parce que le découpage semble pénible. Si le code ne peut pas être séparé, relevez le niveau et réservez du temps de revue sans interruption.

Une équipe distribuée a aussi besoin d'une transmission claire. Consignez les contrôles qui restent, les personnes capables de les approuver et le blocage éventuel du déploiement. SaaS Production confie à des ingénieurs expérimentés le contrôle de son processus de développement assisté par IA, ce qui répartit bien les tâches : l'IA accélère la production, tandis que les humains conservent les décisions qui exigent contexte et responsabilité.

Les résultats de l'IA exigent plus que le diff

Les relecteurs doivent examiner les hypothèses qui entourent le code généré, pas seulement sa syntaxe. Une IA peut appeler une API inexistante, utiliser une vraie API dans la mauvaise version, inventer un champ de configuration, copier un modèle de sécurité obsolète ou élargir discrètement le comportement demandé. Le code obtenu peut compiler si des simulations ou des types permissifs dissimulent l'erreur.

Demandez à l'auteur de déclarer l'usage de l'IA au niveau de la modification, sans détailler chaque suggestion acceptée. Une trace utile indique les fichiers ou fonctions largement générés, le modèle qui a fourni le brouillon si la politique le demande, le contenu externe entré dans l'instruction et les éléments vérifiés indépendamment par l'auteur. Ne collez pas d'instructions sensibles ni de données propriétaires dans la demande de fusion. Cette déclaration oriente l'effort de revue et soutient la provenance, elle ne sert pas à humilier l'auteur.

Vérifiez les affirmations voisines du code auprès de sources qui font autorité. Si le code généré utilise une option de sécurité d'un framework, lisez le manuel de la version installée et vérifiez la valeur par défaut. S'il appelle un service cloud, comparez la requête et la réponse au schéma officiel de l'API. S'il implémente un protocole, testez le comportement concerné dans le RFC. La mémoire du modèle ne constitue pas une preuve, et une référence plausible que personne n'a ouverte est pire qu'une absence de référence, car elle peut mettre fin trop tôt à la revue.

Les modifications générées exigent un contrôle de périmètre par rapport à la demande. Comparez la tâche acceptée au diff et listez les comportements que la modification ajoute au-delà de cette tâche. Recherchez les nouveaux journaux, la télémétrie, les comportements de repli, les dépendances, la configuration, les appels réseau et la récupération d'erreur. Ces ajouts semblent souvent utiles, mais peuvent créer des conséquences de confidentialité, de coût et de sécurité que personne n'a accepté d'assumer.

Contrôlez l'exposition des données dans les deux sens. Vérifiez ce que l'auteur a envoyé au système d'IA selon les règles de l'organisation, puis ce que le code généré envoie pendant son exécution. Une fonction d'aide apparemment anodine peut sérialiser un objet entier alors que l'API ne demande que deux champs. Les tests doivent vérifier la forme de la sortie et confirmer que les journaux, les exceptions et les analyses excluent les secrets et les données réglementées.

Enfin, exigez la responsabilité sans demander une réécriture manuelle de façade. Obliger une personne à retaper du code généré ne le rend pas plus sûr. Demandez-lui d'expliquer les invariants, de reproduire les tests, de vérifier les API, de supprimer le périmètre inutile et de répondre à la revue. Le critère est une compréhension étayée par des preuves.

Une exception exige une échéance et un plan de reprise

Un incident de production peut parfois justifier une fusion avec des preuves incomplètes, mais l'urgence ne fait pas disparaître le contrôle manquant. Une exception doit nommer le contrôle échoué ou omis, le dommage immédiat que la modification évite, la personne qui accepte le risque supplémentaire, la limite de l'exposition, le déclencheur du retour en arrière et le moment où la revue normale sera terminée.

Réduisez autant que possible la modification d'urgence. Évitez les nouvelles dépendances, les refactorisations opportunistes, les remises en forme générales et les corrections générées sans rapport. Utilisez une option fonctionnelle, une limite de trafic, une configuration ciblée ou un correctif réversible lorsque le système le permet. Associez l'auteur au responsable de l'incident ou du service, puis consignez les commandes et les observations dans le dossier d'incident.

Certains contrôles doivent rester obligatoires même pendant un incident. Le code doit venir d'un contributeur authentifié, la compilation doit identifier le commit, les tests de base doivent s'exécuter sauf si le système de test est lui-même en panne, la recherche de secrets ne doit signaler aucun nouvel identifiant et une personne nommée doit autoriser la production. Si un contrôle ne peut pas s'exécuter, consignez ce fait et utilisez la meilleure vérification indépendante disponible. Le silence ne remplace pas un contrôle.

Fixez une échéance mesurée en heures ou en jours selon le système, pas une exception sans fin. La revue de suivi doit décider de conserver, remplacer ou annuler la modification d'urgence. Elle doit aussi ajouter le test manquant et chercher pourquoi le parcours normal n'a pas pu réagir assez vite. Suivez ce travail dans le cadre de l'incident, avec un responsable et une échéance.

Ne créez jamais un niveau bas permanent pour les corrections étiquetées comme urgentes. Cette étiquette se répandra au travail normal. Conservez un seul parcours d'exception avec des traces plus strictes et une revue ultérieure, puis mesurez sa fréquence d'utilisation. Des exceptions fréquentes signalent généralement des tests lents, des responsables indisponibles, des politiques confuses ou des déploiements trop difficiles à inverser.

Ajustez les niveaux avec les preuves des versions

Une politique de revue doit évoluer lorsque les preuves de production montrent qu'elle oriente mal le travail. Consignez le niveau attribué, sa raison, le temps de revue, les contrôles qui ont trouvé un problème, les modifications demandées après l'approbation, les références au retour ou à l'incident, et l'utilisation éventuelle d'une exception. Ne transformez pas ces données en concours de vitesse entre relecteurs.

Recherchez les erreurs d'orientation. Si les modifications de niveau 1 entraînent souvent des corrections en production, les chemins protégés ou les conditions d'entrée sont trop faibles. Si celles de niveau 3 attendent plusieurs jours sans que les relecteurs trouvent quoi que ce soit en dehors de la suite de tests normale, le niveau demande peut-être le mauvais spécialiste ou répète un contrôle automatisé fiable. Si les analyses de sécurité signalent toujours le même motif sans suite, ajustez la règle et documentez la raison au lieu d'apprendre aux relecteurs à ignorer les compilations rouges.

Échantillonnez les modifications approuvées ainsi que celles qui ont échoué. Un ingénieur expérimenté peut comparer périodiquement le diff, les preuves, le niveau et le résultat en production. L'objectif consiste à trouver la fausse confiance : des approbations sans décision attribuée, des tests qui ne couvraient pas l'affirmation risquée, des revues de dépendances qui avaient manqué des changements indirects ou des plans de retour impossibles à exécuter.

Gardez la première implémentation simple. Placez le tableau des niveaux dans le dépôt, protégez les chemins sensibles, exigez les contrôles d'état, attribuez les responsables du code et ajoutez des champs pour l'affirmation risquée, les preuves, le retour en arrière et la vérification de l'IA. Après plusieurs cycles de publication, ajustez l'association à partir des pannes et des retards observés.

La revue humaine suffit lorsqu'une personne indépendante qui possède les connaissances adaptées au domaine peut relier chaque affirmation importante à une preuve et arrêter la mise en production. Pour un travail aux conséquences faibles, cela peut prendre quelques minutes. Pour du code capable d'exposer des dossiers, de déplacer de l'argent, d'accorder des droits ou de corrompre des données, l'équipe doit à la production une décision plus lente et explicite, quelle que soit la vitesse d'apparition du premier brouillon.

Questions Fréquentes

Tout le code généré par IA exige-t-il une revue humaine ?

Oui, le code de production exige une revue humaine responsable, mais pas toujours avec la même profondeur. Une modification limitée et réversible ne suit pas le même parcours qu'un changement d'autorisations, de paiement, de données de santé, de déploiement ou de confiance dans la compilation.

Les tests automatisés peuvent-ils remplacer un relecteur humain ?

Non. Les tests peuvent prouver un comportement choisi, tandis qu'un relecteur vérifie si ce comportement, le périmètre, les hypothèses et le risque sont justes. Une bonne automatisation réduit l'inspection courante, mais une personne doit assumer la décision de production.

Comment classer une modification petite mais sensible ?

La sensibilité doit l'emporter sur le nombre de lignes. Une modification minuscule dans l'autorisation, la cryptographie, les secrets, les migrations ou l'identité de production appartient à un niveau supérieur, car ses conséquences peuvent être fortes et difficiles à inverser.

Les relecteurs doivent-ils savoir quel code vient de l'IA ?

Ils doivent savoir quelles parties ont été largement générées pour examiner les hypothèses et les preuves de vérification. La déclaration doit orienter l'attention, sans dispenser l'auteur de comprendre chaque ligne.

Combien d'approbateurs faut-il pour une modification IA risquée ?

Utilisez au moins deux relecteurs indépendants pour les modifications sensibles ou larges, avec une responsabilité nommée sur les domaines concernés. Les changements graves peuvent exiger des responsables de la sécurité, des données et de la publication, mais des signatures sans expertise adaptée apportent peu.

Quelles analyses de sécurité faut-il lancer sur du code assisté par IA ?

Lancez une analyse statique adaptée au langage, la recherche de secrets et le contrôle des dépendances comme base pour les modifications ordinaires de production. Ajoutez la modélisation des menaces, des tests d'abus et une revue manuelle de l'autorisation et des flux de données quand le code touche une frontière sensible.

Comment examiner les mises à jour de dépendances générées par IA ?

Examinez les modifications directes et indirectes, les vulnérabilités connues, les licences, l'identité du registre, les données d'intégrité et les scripts d'installation. Une personne doit aussi juger si la nouvelle dépendance est nécessaire, car les analyseurs ne détectent pas un élargissement évitable de la confiance.

Une correction de production urgente peut-elle contourner les niveaux ?

Elle peut suivre un parcours d'exception documenté, mais elle exige toujours un auteur authentifié, un commit identifié, des preuves de base, un approbateur de production nommé et un déclencheur de retour. Donnez une échéance à l'exception et terminez la revue manquante après l'incident.

Quelles preuves joindre à une demande de fusion avec du code IA ?

Joignez l'affirmation de comportement risquée, les résultats de tests ciblés liés au commit, les résultats d'analyse obligatoires, les changements de dépendances et un plan de retour si l'inversion n'est pas simple. Pour le code généré, ajoutez les API et les hypothèses que l'auteur a vérifiées indépendamment.

À quelle fréquence faut-il actualiser les niveaux de revue ?

Réexaminez-les après assez de versions pour voir les erreurs d'orientation répétées, et immédiatement après qu'un échec grave révèle une mauvaise règle. Utilisez les constats des tests, incidents, exceptions et échantillons d'approbations plutôt que de changer la politique sur une simple opinion.