Workflows IA auditables en programmation clinique : l’enregistrement d’audit reproductible de bout en bout

Assemblez le prompt, le brouillon IA, la barrière de QC et l’approbation humaine d’une dérivation assistée par IA en un unique enregistrement d’audit reproductible et à altération détectable — empreintes plus environnement plus un horodatage fixe — pour qu’un livrable rédigé par l’IA réponde aux mêmes attentes d’intégrité des données et de piste d’audit que le code rédigé par un humain

La leçon de synthèse de la série de programmation clinique agentique : le workflow auditable de bout en bout qui relie toute la série. Pour une dérivation de BMI assistée par IA, cette leçon capture la référence du prompt, le code rédigé par l’IA, le résultat de la barrière de QC indépendante, l’environnement et l’approbation humaine en un unique enregistrement de provenance reproductible — empreintes de contenu plus versions de packages plus un horodatage fixe — construit avec du base R exécutable (digest, diffdf). Elle montre les deux versants : un brouillon IA bogué que la barrière de QC recale journalise REJECTED, et un brouillon corrigé qui réussit journalise APPROVED ; changer une valeur d’entrée modifie l’empreinte de contenu, de sorte que toute altération est évidente. L’enregistrement est ensuite relié aux principes d’intégrité des données ALCOA+. La frontière honnête tout du long : la piste d’audit consigne ce qui s’est passé, le rend reproductible, et rend les changements détectables — elle ne rend pas la sortie de l’IA correcte. La revue humaine plus une barrière franchie, voilà ce qui la qualifie.

Date de publication

2 juillet 2026

Modifié

7 juillet 2026

AstucePoints clés
  • Une soumission exige que toute la boucle assistée par IA soit traçable. Au fil de cette série, un copilote IA a rédigé des dérivations, des tableaux et des métadonnées, et une barrière indépendante a attrapé ses erreurs. La leçon de synthèse assemble cette boucle — prompt → brouillon IA → valider → approuver — en une seule piste d’audit : un enregistrement durable et reproductible de qui a fait quoi, avec quel code, sur quelle version, et qui l’a approuvé.
  • L’enregistrement est un véritable calcul, pas de la paperasse. Les empreintes de contenu (empreintes SHA-256) des données d’entrée, du code rédigé par l’IA et du résultat de QC — plus les versions de packages et un horodatage fixe — s’assemblent en un unique enregistrement de provenance avec digest et diffdf. Exécutez-le deux fois et il se reproduit octet pour octet.
  • L’enregistrement dit la vérité, dans les deux sens. Un brouillon IA bogué échoue à la barrière de QC et est journalisé REJECTED ; le brouillon corrigé réussit et est journalisé APPROVED. La piste d’audit consigne ce qui s’est réellement passé — elle n’entérine pas l’IA sans examen.
  • À altération détectable, pas une signature. Changez une valeur d’entrée et l’empreinte de contenu change, si bien que toute altération ultérieure ne correspond plus au journal. L’empreinte est une somme de contrôle d’intégrité, pas une signature cryptographique — la documentation de digest indique qu’elle n’est pas destinée à un usage cryptographique.
  • Journalisé est nécessaire, pas suffisant. La piste d’audit consigne, reproduit et rend détectable toute altération du travail ; elle ne rend pas la sortie de l’IA correcte. La revue humaine plus une barrière franchie, voilà ce qui la qualifie — un livrable rédigé par l’IA n’est pas un livrable validé par l’IA.

Introduction

Au fil de cette série, un copilote IA a fait un vrai travail de rédaction : il a écrit une dérivation de délai jusqu’à l’événement admiral, un tableau d’événements indésirables tern, des métadonnées Define-XML, et une re-dérivation de QC indépendante. Chaque fois, la même discipline a tenu — la sortie de l’IA était un brouillon non qualifié jusqu’à ce qu’une barrière indépendante la contrôle, et un humain était maître de l’approbation. Cinq leçons, cinq brouillons, cinq barrières.

Une soumission réglementaire demande une chose de plus à ce travail : il doit être traçable. Pas seulement « le nombre est juste », mais qui l’a produit, à partir de quel prompt, avec quel code, sur quelle version logicielle, contrôlé comment, et approuvé par qui — et cela doit le rester, vérifiable des années plus tard par un inspecteur qui n’a jamais été dans la pièce. Cette traçabilité, c’est la piste d’audit : l’enregistrement durable et ordonné de ce qui est arrivé à une donnée. C’est une exigence GxP — les réglementations qualité de « bonnes pratiques » qui régissent les données cliniques — et elle s’applique au code assisté par IA exactement comme au code rédigé par un humain.

Cette leçon de synthèse construit cet enregistrement. Pour une dérivation assistée par IA, elle capture la boucle — prompt → brouillon IA → valider → approuver — sous la forme d’un unique enregistrement de provenance : une description compacte et reproductible de l’origine d’un artefact et des étapes qui l’ont produit. Tout ici s’exécute en base R. Le prompt et le brouillon de l’IA sont montrés à titre d’illustration (rédigés dans votre propre outillage) ; le R qui calcule les empreintes des artefacts, exécute la barrière de QC et assemble l’enregistrement est réel et s’exécute.

Note

Cette leçon de synthèse est l’enregistrement ; la SOP est la politique. La procédure de gouvernance — les rôles, le workflow du prompt à l’approbation, et la correspondance avec les attentes de la FDA et de GAMP 5 — se trouve dans Valider le code généré par IA en programmation clinique : une SOP auditable. La SOP dit ce qu’est la politique ; cette leçon montre l’enregistrement à altération détectable que la politique produit. Lisez la SOP pour la procédure ; lisez ceci pour l’artefact concret et exécutable.

La boucle, transformée en enregistrement

Le workflow que chaque leçon de cette série a suivi comporte quatre étapes :

1 · Prompt Un humain écrit la spécification/le prompt · référence la SAP ou la spécification ADaM

2 · Brouillon IA Le copilote renvoie du code R · capturé verbatim sous forme de texte

3 · Valider Une barrière de QC indépendante s’exécute · diffdf PASS / FAIL

4 · Approuver Un humain qualifié relit · approuve · APPROVED / REJECTED

Une approbation (ou sign-off) est une personne nommée et qualifiée qui atteste que le contrôle a été effectué et réussi, et qui en répond lors d’un audit. Pour rendre la boucle auditable, nous capturons chaque étape sous forme d’une valeur que nous pouvons stocker et revérifier : la référence du prompt, le code rédigé par l’IA, le résultat de QC, l’environnement, les métadonnées fixes — et, surtout, les empreintes de contenu des artefacts pour que tout changement ultérieur soit détectable.

Nous utilisons un petit ADSL (Subject-Level Analysis Dataset — jeu de données d’analyse au niveau sujet, une ligne par sujet) avec la taille et le poids, et la dérivation sous audit est un BMI (indice de masse corporelle — le poids en kilogrammes divisé par la taille en mètres au carré) initial. La taille est en centimètres, elle doit donc être divisée par 100 avant d’être élevée au carré.

Assembler l’enregistrement de provenance

Le bloc ci-dessous est la capture entière, de haut en bas, et chaque valeur du tableau final est calculée, pas saisie. Il construit les données d’entrée, capture la dérivation rédigée par l’IA sous forme de texte, exécute une re-dérivation de QC indépendante à partir de la même spécification, soumet les deux à la barrière avec diffdf(), calcule l’empreinte de chaque artefact, lit l’environnement et assemble un enregistrement.

Quelques choix déterministes en font un journal durable plutôt qu’un instantané qui change à chaque exécution. Les valeurs d’entrée sont des littéraux fixes. L’environnement est capturé à partir des seules chaînes de version (R.version.string, packageVersion()) — jamais d’une horloge système. L’horodatage est une chaîne illustrative codée en dur, pas Sys.time(). Résultat : l’enregistrement — et ses empreintes — se reproduisent octet pour octet à chaque rendu, ce qui est exactement ce que doit faire une piste d’audit. Nous hachons avec SHA-256, une somme de contrôle de longueur fixe (une empreinte d’intégrité) des octets qu’on lui donne : une entrée identique produit toujours l’empreinte identique, et tout changement en produit une différente.

library(digest); library(diffdf)

# 1. Input data: a small ADSL, fixed in-block values => deterministic
adsl <- data.frame(
  USUBJID = sprintf("01-%03d", 1:6),
  HEIGHT  = c(170, 165, 180, 158, 175, 168),   # cm
  WEIGHT  = c( 72,  60,  85,  55,  90,  68),    # kg
  stringsAsFactors = FALSE)

# 2. The AI-drafted derivation, captured VERBATIM as text (illustrative -- drafted in your tooling).
#    This text string is itself an artifact we hash, so the log records exactly what code the AI returned.
ai_draft_code <- "ai_out$BMI <- round(ai_out$WEIGHT / (ai_out$HEIGHT / 100)^2, 1)"
ai_out <- adsl; eval(parse(text = ai_draft_code))

# 3. Independent QC re-derivation from the SAME spec (BMI = kg / m^2, one decimal place)
qc_out <- adsl; qc_out$BMI <- round(adsl$WEIGHT / (adsl$HEIGHT / 100)^2, 1)

# 4. The QC gate: diffdf compares the AI draft against the independent re-derivation on the subject key
qc_report <- capture.output(diffdf(ai_out, qc_out, keys = "USUBJID"))
gate_pass <- any(grepl("No issues were found", qc_report))

# 5. Content hashes -- tamper-evident, reproducible fingerprints of each artifact
h_input  <- digest(adsl,          algo = "sha256")
h_draft  <- digest(ai_draft_code, algo = "sha256", serialize = FALSE)  # a string => serialize = FALSE
h_result <- digest(ai_out,        algo = "sha256")

# 6. Environment capture -- version strings only, NEVER a wall clock (keeps the record deterministic)
env_r <- R.version.string

# 7. Assemble ONE provenance record (the timestamp is a FIXED illustrative string, not Sys.time())
record <- data.frame(
  Field = c("Spec / prompt ref", "AI model", "Prompt ID", "Input data (sha256)", "AI-draft code (sha256)",
            "QC result (sha256)", "QC gate (diffdf)", "R version", "digest / diffdf",
            "Timestamp (UTC, illustrative)", "Human reviewer", "Approval status"),
  Value = c("ADaM-BMI-derivation v1.2 / SAP §9.3", "claude-opus-x (illustrative)", "PRM-2026-014",
            substr(h_input, 1, 16), substr(h_draft, 1, 16), substr(h_result, 1, 16),
            ifelse(gate_pass, "PASS - zero differences", "FAIL"),
            env_r, paste(packageVersion("digest"), packageVersion("diffdf")),
            "2026-07-02T09:00:00Z", "A. Programmer (QC lead)",
            ifelse(gate_pass, "APPROVED", "REJECTED")),
  stringsAsFactors = FALSE)

knitr::kable(record)
Field Value
Spec / prompt ref ADaM-BMI-derivation v1.2 / SAP §9.3
AI model claude-opus-x (illustrative)
Prompt ID PRM-2026-014
Input data (sha256) 8b7e4e496f9a608c
AI-draft code (sha256) ad432d6eaa47edca
QC result (sha256) 1561ec8b7c93e5c2
QC gate (diffdf) PASS - zero differences
R version R version 4.5.1 (2025-06-13)
digest / diffdf 0.6.39 1.1.2
Timestamp (UTC, illustrative) 2026-07-02T09:00:00Z
Human reviewer A. Programmer (QC lead)
Approval status APPROVED

Lisez l’enregistrement de haut en bas et c’est toute la boucle en un seul endroit. La référence du prompt pointe vers la section de la SAP qui a spécifié la dérivation. Le modèle d’IA et l’ID du prompt disent ce qui a produit le brouillon. Les trois empreintes identifient les données d’entrée, le code rédigé par l’IA et le résultat de QC — de sorte qu’un relecteur peut plus tard confirmer qu’il regarde exactement les mêmes artefacts. La ligne de la barrière de QC est le verdict du contrôle indépendant. Les champs d’environnement figent le logiciel. Et parce que la barrière a réussi, le statut d’approbation affiche APPROVED, attribué au relecteur nommé qui est maître du sign-off. Un objet unique, durable et reproductible porte la provenance d’une dérivation assistée par IA.

L’enregistrement dit la vérité : le versant REJECTED

La ligne d’approbation n’est pas décorative, et ce n’est pas à l’IA de l’accorder. Elle reflète la barrière. Alimentez la même machinerie avec un brouillon IA erroné — ici le copilote oublie la conversion centimètres-vers-mètres et élève au carré la variable HEIGHT brute — et la barrière de QC échoue, si bien que l’enregistrement journalise REJECTED :

library(digest); library(diffdf)

adsl <- data.frame(
  USUBJID = sprintf("01-%03d", 1:6),
  HEIGHT  = c(170, 165, 180, 158, 175, 168),   # cm
  WEIGHT  = c( 72,  60,  85,  55,  90,  68),    # kg
  stringsAsFactors = FALSE)

# A BUGGY AI draft: forgets the cm -> m conversion (no /100), so BMI is off by a factor of 10,000
ai_draft_bug <- "ai_out$BMI <- round(ai_out$WEIGHT / (ai_out$HEIGHT)^2, 1)"
ai_out <- adsl; eval(parse(text = ai_draft_bug))

# The independent QC re-derivation is still correct (converts cm -> m)
qc_out <- adsl; qc_out$BMI <- round(adsl$WEIGHT / (adsl$HEIGHT / 100)^2, 1)

# The gate now finds differences on every subject -> FAIL
qc_report <- capture.output(diffdf(ai_out, qc_out, keys = "USUBJID"))
gate_pass <- any(grepl("No issues were found", qc_report))

h_input  <- digest(adsl,         algo = "sha256")
h_draft  <- digest(ai_draft_bug, algo = "sha256", serialize = FALSE)
h_result <- digest(ai_out,       algo = "sha256")
env_r    <- R.version.string

record_rej <- data.frame(
  Field = c("Spec / prompt ref", "AI model", "Prompt ID", "Input data (sha256)", "AI-draft code (sha256)",
            "QC result (sha256)", "QC gate (diffdf)", "R version", "digest / diffdf",
            "Timestamp (UTC, illustrative)", "Human reviewer", "Approval status"),
  Value = c("ADaM-BMI-derivation v1.2 / SAP §9.3", "claude-opus-x (illustrative)", "PRM-2026-014",
            substr(h_input, 1, 16), substr(h_draft, 1, 16), substr(h_result, 1, 16),
            ifelse(gate_pass, "PASS - zero differences", "FAIL"),
            env_r, paste(packageVersion("digest"), packageVersion("diffdf")),
            "2026-07-02T09:00:00Z", "A. Programmer (QC lead)",
            ifelse(gate_pass, "APPROVED", "REJECTED")),
  stringsAsFactors = FALSE)

knitr::kable(record_rej)
Field Value
Spec / prompt ref ADaM-BMI-derivation v1.2 / SAP §9.3
AI model claude-opus-x (illustrative)
Prompt ID PRM-2026-014
Input data (sha256) 8b7e4e496f9a608c
AI-draft code (sha256) bc402c9428a591bc
QC result (sha256) 877b38aae368c871
QC gate (diffdf) FAIL
R version R version 4.5.1 (2025-06-13)
digest / diffdf 0.6.39 1.1.2
Timestamp (UTC, illustrative) 2026-07-02T09:00:00Z
Human reviewer A. Programmer (QC lead)
Approval status REJECTED

Même pipeline, résultat opposé. L’empreinte AI-draft code (sha256) diffère de l’enregistrement approuvé ci-dessus parce que le texte du code est différent, la QC gate affiche FAIL, et l’Approval status affiche REJECTED. Rien dans l’enregistrement n’a flatté l’IA. Corrigez le brouillon — rétablissez la conversion /100 — et la machinerie identique fait basculer la barrière sur PASS et le statut de nouveau sur APPROVED, reproduisant exactement le premier enregistrement. C’est là tout le propos : la piste d’audit consigne la vérité de ce que la barrière et le relecteur ont décidé. Un workflow journalisé est nécessaire ; il n’est pas suffisant. Ce qui qualifie la dérivation, c’est la revue humaine plus la barrière franchie — pas le fait qu’elle ait été journalisée.

Détectabilité des altérations : changez une valeur, cassez l’empreinte

Les empreintes de contenu confèrent à l’enregistrement une seconde propriété : toute altération ultérieure d’un artefact audité est détectable — parce que l’empreinte stockée ne correspond plus. Recalculez l’empreinte de l’entrée après avoir changé un seul poids de 72 à 73 :

library(digest)

adsl <- data.frame(
  USUBJID = sprintf("01-%03d", 1:6),
  HEIGHT  = c(170, 165, 180, 158, 175, 168),   # cm
  WEIGHT  = c( 72,  60,  85,  55,  90,  68),    # kg
  stringsAsFactors = FALSE)

# The logged input fingerprint
h_original <- digest(adsl, algo = "sha256")

# Someone edits ONE value after the fact: subject 01-001's weight 72 -> 73
adsl_tampered <- adsl
adsl_tampered$WEIGHT[1] <- 73
h_tampered <- digest(adsl_tampered, algo = "sha256")

data.frame(
  version = c("logged input", "one weight changed 72 -> 73"),
  sha256  = c(substr(h_original, 1, 16), substr(h_tampered, 1, 16)),
  matches_log = c(TRUE, h_tampered == h_original))
                      version           sha256 matches_log
1                logged input 8b7e4e496f9a608c        TRUE
2 one weight changed 72 -> 73 4c2a655f8baa417d       FALSE

L’empreinte change complètement à cause d’une modification d’un seul chiffre, si bien que les données altérées ne correspondent plus à la valeur stockée dans l’enregistrement d’audit — l’altération ne peut pas passer silencieusement. Voilà ce qu’apporte l’« adressage par contenu » : le journal pointe vers le contenu, pas vers un nom de fichier, de sorte que changer le contenu invalide le pointeur.

Une mise en garde honnête, dite clairement : il s’agit de détectabilité des altérations, pas de sécurité. Une somme de contrôle SHA-256 prouve que les octets sont inchangés ; ce n’est pas une signature cryptographique et cela ne prouve pas qui a fait un changement, ni n’empêche un acteur déterminé de recalculer l’empreinte après avoir édité à la fois les données et le journal. La documentation de digest indique sans détour qu’elle “is not meant to be used for cryptographic purposes.” Appelez cela une somme de contrôle d’intégrité, pas une signature — c’est le bon outil pour la reproductibilité et la détection de changement au sein d’un processus contrôlé et porté par un humain, et rien de plus.

Lire l’enregistrement comme un enregistrement d’audit ALCOA+

Les régulateurs évaluent l’intégrité des données au regard d’un petit ensemble de principes connu sous le nom d’ALCOA+. Le guide MHRA sur l’intégrité des données GxP définit ALCOA comme Attributable (attribuable), Legible (lisible), Contemporaneous (contemporain), Original (original) et Accurate (exact), le « + » ajoutant Complete (complet), Consistent (cohérent), Enduring (durable) et Available (disponible) — et note qu’il n’y a aucune différence d’attente quel que soit l’acronyme utilisé. L’intégrité des données est le degré auquel les données sont complètes, cohérentes et exactes tout au long de leur cycle de vie ; le même guide de la FDA sur l’intégrité des données qui régit les enregistrements rédigés par un humain régit ceux assistés par IA. L’enregistrement de provenance correspond à chaque principe ALCOA+ :

Principe ALCOA+ Comment l’enregistrement le soutient
Attributable Relecteur humain + modèle d’IA + Prompt ID disent qui et quoi a produit et approuvé chaque artefact
Legible Des champs simples et lisibles par un humain — pas un état interne opaque
Contemporaneous Le champ d’horodatage consigne quand l’étape a eu lieu (ici une chaîne fixe illustrative)
Original Les empreintes entrée/brouillon/résultat adressent par contenu les originaux ; une copie conforme est vérifiable face à elles
Accurate Le statut de la barrière de QC (diffdf) est la preuve que la dérivation a été contrôlée indépendamment
Complete Référence du prompt → brouillon → résultat de QC → approbation : toute la boucle est capturée, rien n’est omis
Consistent Les empreintes déterministes se reproduisent à l’identique, si bien que l’enregistrement est cohérent en interne d’une régénération à l’autre
Enduring Un artefact durable commité et figé avec l’analyse, pas un état de console transitoire
Available Il se trouve à côté du code et du commit, récupérable des années plus tard par un relecteur ou un inspecteur

ALCOA+ est appliqué ici comme un principe que l’enregistrement est bâti pour satisfaire — pas comme une certification que cette leçon confère. Le R Validation Hub formule la même idée pour les outils sous-jacents : l’assurance vient d’une validation documentée et portée par un humain, pas de la parole de l’outil lui-même.

La frontière honnête

Alignez ce que l’enregistrement fait et ne fait pas, car la distinction est tout le propos de la leçon de synthèse.

La piste d’audit consigne ce qui s’est passé, le reproduit octet pour octet, et rend détectable tout changement des artefacts audités. Ce sont des propriétés réelles et précieuses, et c’est exactement ce dont une soumission a besoin de la part d’un livrable assisté par IA.

La piste d’audit ne rend pas la sortie de l’IA correcte. Ce n’est pas une signature cryptographique. Elle ne certifie pas le modèle, et elle ne valide pas la dérivation. L’exactitude est venue de la barrière de QC indépendante et de la revue humaine — le versant REJECTED en est la preuve : la même machinerie d’enregistrement a journalisé une mauvaise réponse comme fausse. Un workflow d’IA journalisé est nécessaire à une soumission défendable ; il n’est pas suffisant. Dit simplement : rédigé par l’IA n’est pas validé par l’IA, et un enregistrement de la boucle n’est digne de confiance que parce qu’un humain qualifié a été maître de l’approbation à son terme.

🟢 Avec un agent IA

Demandez à Prova « Comment transformer ma boucle prompt → brouillon IA → QC → approbation en un enregistrement d’audit reproductible et à altération détectable en R, et qu’est-ce que cet enregistrement prouve réellement, par opposition à ce qu’il ne prouve pas ? » — elle répond en s’appuyant sur les leçons de validation de cette série, avec la capture de provenance exécutable digest + diffdf que vous pouvez adapter à votre propre dérivation. The runtime is the judge. Demandez à Prova →

Problèmes fréquents

Un enregistrement qui change à chaque rendu — d’ordinaire Sys.time(). Si l’enregistrement d’audit ou ses empreintes diffèrent entre deux rendus, quelque chose de non déterministe s’est glissé : un appel d’horloge système (Sys.time()/Sys.Date()), un tirage aléatoire, ou une valeur d’environnement qui varie. Une piste d’audit commitée doit se reproduire octet pour octet, alors capturez le temps sous forme de chaîne de métadonnées fixe, capturez l’environnement à partir des seules chaînes de version, et fixez chaque entrée comme un littéral. C’est le déterminisme qui permet à un relecteur de régénérer et de confirmer le journal des années plus tard.

digest() sur une chaîne de code renvoie la « mauvaise » empreinte. Par défaut, digest() sérialise son entrée avant de la hacher, ce qui est correct pour un data frame mais pas pour une simple chaîne — deux chaînes identiques peuvent produire des empreintes différentes d’une session à l’autre. Quand vous empreintez du texte de code capturé, passez serialize = FALSE pour que digest() hache directement les caractères (comme le fait ici l’empreinte du code rédigé par l’IA).

Traiter l’empreinte comme une signature. Une somme de contrôle SHA-256 prouve que les octets sont inchangés ; elle ne prouve pas qui les a changés et n’est pas cryptographiquement sûre — la documentation de digest le dit explicitement. Utilisez-la pour la reproductibilité et la détectabilité des altérations au sein d’un processus contrôlé, et fiez-vous à votre historique de contrôle de version et à vos contrôles d’accès (pas à l’empreinte) pour l’attribution et l’authenticité.

Lire « c’est journalisé » comme « c’est validé ». La piste d’audit consigne et reproduit le workflow ; elle ne qualifie pas la sortie de l’IA. Ne laissez jamais un enregistrement complet et reproductible se substituer à la barrière de QC indépendante et au sign-off humain — l’enregistrement est la preuve que la validation a eu lieu, pas la validation elle-même.

Questions fréquentes

Non. Une piste d’audit consigne ce qui s’est passé — le prompt, le brouillon IA, le résultat de QC, l’approbation — et le rend reproductible et à altération détectable. Elle ne rend pas le code correct. La conformité vient des mêmes barrières que tout code doit franchir (QC indépendant, revue humaine) plus le sign-off d’un humain qualifié ; l’enregistrement d’audit est la preuve que ces étapes ont eu lieu, pas un substitut à celles-ci. Un workflow d’IA journalisé est nécessaire, pas suffisant.

Non. Une empreinte SHA-256 est une somme de contrôle d’intégrité : elle détecte si des octets ont changé, ce qui rend un enregistrement à altération détectable. Elle n’identifie pas qui a fait un changement et n’est pas cryptographiquement sûre — la documentation de digest indique qu’elle “is not meant to be used for cryptographic purposes.” Pour la paternité et l’authenticité, fiez-vous au contrôle de version et aux contrôles d’accès ; utilisez l’empreinte pour la reproductibilité et la détection de changement.

ALCOA+ est l’ensemble des principes d’intégrité des données que les régulateurs attendent des enregistrements : Attributable, Legible, Contemporaneous, Original, Accurate, plus Complete, Consistent, Enduring et Available (définis dans le guide MHRA sur l’intégrité des données GxP). Ils s’appliquent au code assisté par IA exactement comme au code rédigé par un humain : l’enregistrement de provenance rend une dérivation rédigée par l’IA attribuable (qui/quoi l’a produite et approuvée), originale et cohérente (empreintes de contenu), exacte (une barrière de QC indépendante) et complète/durable/disponible (toute la boucle, commitée avec l’analyse).

Supprimez toute source de non-déterminisme de l’enregistrement : fixez les entrées comme des littéraux, capturez l’environnement à partir des chaînes de version (R.version.string, packageVersion()) plutôt que d’une horloge système, et stockez l’horodatage comme métadonnée fixe au lieu de Sys.time(). Empreintez les artefacts avec digest() (utilisez serialize = FALSE pour les chaînes de code) et soumettez la dérivation à la barrière avec diffdf(). Commité et figé avec l’analyse, l’enregistrement se régénère alors octet pour octet sur n’importe quelle machine — c’est ce que « reproductible » signifie pour une piste d’audit.

La SOP d’IA auditable est la politique : les rôles, la procédure du prompt à l’approbation, et la correspondance avec les attentes de la FDA et de GAMP 5. Cette leçon de synthèse est l’artefact que la politique produit : un enregistrement de provenance concret, exécutable et empreint par contenu pour une dérivation, montré à travers ses versants REJECTED et APPROVED et relié à ALCOA+. La SOP vous dit ce que le workflow doit être ; ceci vous montre l’enregistrement à altération détectable qu’il génère.

Testez vos connaissances

Vous disposez d’un ADSL à deux sujets et d’une dérivation rédigée par l’IA capturée sous forme de chaîne. Construisez un petit enregistrement de provenance et démontrez ses propriétés d’intégrité.

  1. En prose : expliquez pourquoi l’enregistrement doit utiliser une chaîne d’horodatage fixe et une capture d’environnement par chaînes de version plutôt que Sys.time() et une horloge système — et quelle propriété casserait s’il ne le faisait pas.
  2. En R : calculez l’empreinte d’un petit data frame d’entrée et d’une chaîne de code rédigé par l’IA avec digest() (n’oubliez pas serialize = FALSE pour la chaîne). Puis changez une valeur d’entrée, recalculez l’empreinte de l’entrée, et montrez qu’elle ne correspond plus à l’originale — la propriété de détectabilité des altérations.

Une piste d’audit commitée doit se reproduire octet pour octet pour qu’un relecteur puisse la régénérer et la confirmer plus tard ; toute valeur d’horloge ou aléatoire la ferait changer à chaque rendu et casserait la reproductibilité (les propriétés ALCOA+ « Consistent »/« Enduring »). Pour l’empreinte, digest(df, algo = "sha256") empreinte un data frame ; digest(code_string, algo = "sha256", serialize = FALSE) empreinte du texte. Changer un seul octet d’entrée produit une empreinte différente.

Étape 1. L’enregistrement doit se régénérer à l’identique sur n’importe quelle machine, n’importe quel jour, pour qu’un inspecteur puisse le reproduire et confirmer que rien n’a changé. Sys.time() et d’autres valeurs d’horloge ou aléatoires feraient différer l’enregistrement — et ses empreintes — à chaque rendu, si bien que le journal ne pourrait jamais être reproduit ni vérifié. Capturer le temps sous forme de chaîne de métadonnées fixe et l’environnement à partir des chaînes de version garde l’enregistrement déterministe (les propriétés ALCOA+ Consistent et Enduring) ; l’horodatage illustre quand l’étape a eu lieu, consigné comme donnée, pas lu en direct.

library(digest)

adsl <- data.frame(
  USUBJID = c("01-001", "01-002"),
  HEIGHT  = c(170, 165),   # cm
  WEIGHT  = c(72, 60),     # kg
  stringsAsFactors = FALSE)

ai_draft_code <- "ai_out$BMI <- round(ai_out$WEIGHT / (ai_out$HEIGHT / 100)^2, 1)"

# Fingerprints: default serialisation for the data frame, serialize = FALSE for the code string
h_input <- digest(adsl,          algo = "sha256")
h_draft <- digest(ai_draft_code, algo = "sha256", serialize = FALSE)

# Tamper-evidence: change one value, recompute, and show it no longer matches
adsl2 <- adsl; adsl2$WEIGHT[1] <- 73
h_input2 <- digest(adsl2, algo = "sha256")

identical(h_input, h_input2)   # FALSE -> the edit is detectable; the log no longer matches

identical() renvoie FALSE : une seule valeur changée produit une empreinte différente, si bien que l’altération ne peut pas passer inaperçue. L’empreinte rend l’enregistrement à altération détectable — tout en restant une somme de contrôle, pas une signature.

A. Oui — un enregistrement d’audit complet, reproductible et à altération détectable, voilà ce que signifie la validation. B. Pas par le seul enregistrement — la piste d’audit consigne et reproduit le workflow et le rend à altération détectable, mais l’exactitude vient de la barrière de QC indépendante qui réussit et d’un humain qualifié maître de l’approbation ; un workflow journalisé est nécessaire, pas suffisant. C. Oui, du moment que les empreintes se reproduisent octet pour octet d’une exécution à l’autre.

B. L’enregistrement est la preuve que la boucle a eu lieu et permet à quiconque de la reproduire et de la vérifier, mais il ne rend pas la sortie de l’IA correcte — c’est pourquoi le versant REJECTED existe (la même machinerie journalise une mauvaise réponse comme fausse). La validation, c’est la barrière indépendante franchie plus le sign-off humain ; l’enregistrement les documente. Les empreintes reproductibles (C) apportent la détectabilité des altérations et la cohérence, pas l’exactitude, et un enregistrement complet (A) est nécessaire mais pas suffisant.

Conclusion

Cette leçon de synthèse clôt la série en assemblant son travail en un seul objet auditable. Chaque leçon précédente a produit un brouillon IA et l’a fait passer par une barrière indépendante — une dérivation ADTTE admiral, un tableau tern, des métadonnées Define-XML, un contrôle de QC par double programmation. Ici, cette boucle devient un unique enregistrement de provenance reproductible : les empreintes de contenu de l’entrée, du code rédigé par l’IA et du résultat de QC, plus l’environnement, un horodatage fixe, le verdict de la barrière et l’approbation humaine. Il se reproduit octet pour octet, il est à altération détectable, et il correspond proprement à ALCOA+. Et il dit la vérité dans les deux sens — un brouillon en échec est journalisé REJECTED, un brouillon réussi APPROVED. Ce que l’enregistrement ne fait jamais, c’est rendre la sortie de l’IA correcte ; la revue humaine et la barrière franchie s’en chargent. L’IA change la vitesse du premier brouillon. Elle ne change rien à la responsabilité du chiffre, ni à la discipline qui rend une soumission assistée par IA défendable. The runtime is the judge.

Note

Cette leçon est reproductible : l’enregistrement de provenance, les versants REJECTED et APPROVED, le changement d’empreinte qui révèle l’altération, et la correspondance avec ALCOA+ se reproduisent tous ici avec des entrées fixes, de sorte que les empreintes sont identiques à chaque rendu. Copiez n’importe quel bloc et exécutez-le pour les reproduire. L’étape de rédaction par l’IA se fait dans votre propre outillage ; le R qui calcule les empreintes des artefacts, exécute la barrière de QC et assemble l’enregistrement est réel et s’exécute. The runtime is the judge.

Leçons connexes

Cette page vous a-t-elle été utile ?

Recevez les nouvelles leçons R & Python par e-mail

Pratique, reproductible, sans spam. Désinscription à tout moment.

Double opt-in. Nous ne partageons jamais votre e-mail.

Partager cette pageXLinkedInRedditHN

Réutilisation

Citation

BibTeX
@online{2026,
  author = {},
  title = {Workflows IA auditables en programmation clinique :
    l’enregistrement d’audit reproductible de bout en bout},
  date = {2026-07-02},
  url = {https://www.datanovia.com/learn/pharma-clinical/08-agentic-clinical-programming/auditable-ai-workflow-end-to-end},
  langid = {fr}
}
Veuillez citer ce travail comme suit :
“Workflows IA auditables en programmation clinique : l’enregistrement d’audit reproductible de bout en bout.” 2026. July 2. https://www.datanovia.com/learn/pharma-clinical/08-agentic-clinical-programming/auditable-ai-workflow-end-to-end.