Quelle preuve demander avant d’autoriser une action?
Accès libre · Séquence de travail: 35 à 45 minutes estimées, comprenant lecture, analyse, production et correction. Durée à confirmer par un pilote; adaptez le temps à votre rythme.
Objectif professionnel
Relier un contrôle à une preuve observée
Production attendue: Une matrice de contrôle comportant entrée, règle, résultat attendu, preuve et propriétaire; les calculs détaillés lorsqu’ils sont pertinents.
Parcours de travail
- Comprendre et reformuler le mécanisme: 8 minutes.
- Construire le dossier du cas et vérifier les hypothèses: 12 minutes.
- Traiter la variante de transfert et examiner une référence: 10 à 15 minutes.
- Comparer au corrigé et réviser la production: 5 à 10 minutes.
Ces temps organisent une activité complète. La seule lecture de la page est plus courte. Conservez votre première réponse avant de consulter la correction; une production de 400 à 600 mots, ou un tableau et son commentaire d’une précision équivalente, permet de rendre le raisonnement examinable.
Le mécanisme
Un contrôle devient examinable lorsqu'il possède une entrée, une règle et une sortie observable. Un tableau de bord vert ne suffit pas si personne ne peut retrouver l'action testée. Une preuve doit être datée, attribuée et liée à une version du système. Elle établit seulement le résultat du test effectué. La transférer à une nouvelle version ou à une autre population suppose de justifier la comparabilité.
Le fournisseur écrit que son assistant respecte les permissions. Cette affirmation décrit une intention ou une capacité annoncée. Le responsable du déploiement doit savoir comment elle s'applique au système installé dans son entreprise.
Une documentation peut expliquer le fonctionnement prévu. Une configuration peut montrer les droits attribués. Un test peut montrer ce qui s'est passé dans un scénario déterminé. Ces éléments ne répondent pas à la même question.
Le responsable commence par préciser le contrôle attendu. Il ne demande pas seulement si le dispositif est "sécurisé". Il demande si l'assistant peut lire un dossier situé hors de son périmètre et comment cette tentative est refusée.
Il faut ensuite conserver les conditions du test. Quel compte était utilisé? Quelle version du système? Quelle opération a été tentée? Quel résultat était attendu? Une capture d'écran de refus sans ce contexte est difficile à interpréter.
Un test réussi ne prouve pas que tous les cas possibles sont maîtrisés. Il apporte une preuve limitée à ce qui a été examiné. Cette limite doit être visible dans la décision de déploiement.
L'entreprise peut donc tenir un registre simple. Chaque ligne associe une exigence, le moyen de contrôle et une preuve datée. Les exigences importantes sans preuve deviennent des points à résoudre avant d'élargir le périmètre.
Concevoir une preuve qui résiste à une objection
Pour un plafond fictif de 500 EUR, un essai à 501 doit produire deux observations concordantes: refus du contrôle et absence d'écriture dans le système de paiement. Si le message de refus apparaît après le paiement, le test échoue. Un essai à 500 n'est concluant que si la règle précise si la borne est incluse. Avec une autre devise, il faut définir la source et le moment du taux de conversion, ou refuser la devise non couverte. La fiche de test relie règle, entrée, résultat et preuve de l'état final.
Démonstration pédagogique: les données ajoutées à titre d’exemple ne sont pas des résultats empiriques.
Repères méthodologiques communs
Un système agentique peut être décrit comme une machine à états. La demande reçue, le plan proposé, l’autorisation, l’exécution et la confirmation sont des états différents. Le passage d’un état à l’autre doit produire une preuve observable. Lorsque la réponse d’un service n’arrive pas, l’état devient indéterminé: l’absence de confirmation ne démontre pas l’absence d’exécution. Cette distinction explique pourquoi une simple nouvelle tentative peut provoquer un doublon.
La frontière de confiance indique à quel endroit une information change de statut. Un document externe peut servir de donnée, mais il ne reçoit pas pour autant le pouvoir d’accorder des permissions. Une validation humaine peut autoriser une action précise sans autoriser toutes les actions ultérieures. Pour rester contrôlable, l’autorisation doit être liée aux paramètres effectivement exécutés. Si le bénéficiaire, le montant ou la ressource changent, le système doit déterminer si l’autorisation reste valable.
La recette doit combiner essais positifs et négatifs. Un essai positif vérifie qu’une opération autorisée fonctionne. Un essai négatif vérifie qu’une opération interdite ne produit aucun effet, y compris lorsque l’interface affirme l’avoir refusée. Les observations doivent donc atteindre le système de référence. Vérifier seulement le texte de la réponse laisserait invisible une action déjà réalisée.
La responsabilité ne se résume pas au nom d’un superviseur. Elle suppose un accès aux informations nécessaires, une capacité de suspension et une procédure de reprise. Dans votre dossier, associez chaque transition à un propriétaire et à une preuve. Cette construction permet ensuite d’examiner le coût, la qualité et les besoins de formation sur un même périmètre opérationnel.
Un dossier de décision technique
Présentez les composants, les états et les frontières de responsabilité. Séparez la sortie proposée par un modèle de l’action effectivement exécutée. Pour chaque contrôle, indiquez son emplacement, sa condition de déclenchement et la preuve observable. Un prompt prudent ne remplace pas un refus appliqué par le service.
Travaillez d’abord avec les informations effectivement fournies. Énumérez séparément les hypothèses nécessaires, en précisant lesquelles changeraient la décision. Si une donnée manque, formulez une conclusion conditionnelle ou une demande de preuve. Une valeur inventée ne doit jamais devenir une observation.
Cas professionnel: consolidation guidée
Situation fictive conçue pour l’apprentissage; les chiffres ne décrivent ni une étude ni un client réel.
Un fournisseur fournit trois captures d'écran et annonce que son agent respecte tous les plafonds de paiement. Préparez une demande de preuves et un protocole de six essais: montant inférieur, égal, supérieur, devise différente, droit révoqué et approbation modifiée.
- Définissez la décision ou la proposition à examiner et son périmètre.
- Construisez la production attendue avec les données du cas. Montrez les calculs et les unités, ou reliez chaque affirmation à une observation.
- Présentez au moins une interprétation concurrente. Indiquez la donnée qui permettrait de la départager.
- Rédigez une recommandation de 120 à 180 mots avec ses conditions de validité. Précisez ce qui reste impossible à conclure.
Transfert à une situation nouvelle
Le fournisseur refuse de transmettre des journaux confidentiels: proposez une preuve minimisée ou une observation contrôlée équivalente.
Répondez avant d’ouvrir le corrigé. Modifiez explicitement votre dossier initial: quelle règle reste valable, quelle hypothèse tombe et quelle preuve supplémentaire devient nécessaire? Une réponse qui répète simplement la conclusion du premier cas ne démontre pas le transfert.
Travail sur les références
NISTGEN: utiliser la partie consacrée à l'évaluation et à sa documentation comme cadre; les six essais ne constituent pas une certification NIST.
L’objectif documentaire est de soutenir ou de limiter la conclusion suivante: Relier un contrôle à une preuve observée.
Choisissez ci-dessous la source dont le périmètre correspond directement au mécanisme étudié. Identifiez sa section, sa version et sa date; relevez une proposition précise et expliquez son lien avec une étape de votre production. Indiquez également une conclusion que cette source ne permet pas de soutenir. Les portails généraux et programmes de formation constituent des points d’entrée, non une preuve scientifique du cas.
Si le texte intégral est inaccessible ou sous licence, ne prétendez pas l’avoir vérifié. Consignez la limite, identifiez le document ou la section à obtenir et rédigez votre conclusion sous cette réserve. Les calculs et situations fictives restent des constructions pédagogiques VOCE.
Ouvrir le corrigé argumenté
Correction du cas
Il faut les paramètres, identifiants de version, sorties du contrôle et état réel de la transaction. Une capture peut documenter l'interface sans prouver le refus serveur. Le résultat attendu doit être défini avant l'essai. Un succès sur les trois montants ne couvre pas le changement de devise ou la révocation.
Correction du transfert
Demander une observation supervisée sur données synthétiques, ou un extrait de journal minimisé relié aux identifiants du test. Un rapport indépendant peut convenir si son périmètre, ses méthodes et ses réserves sont accessibles. Le refus de livrer des données confidentielles n'autorise pas à remplacer la preuve d'exécution par une capture commerciale.
Évaluer puis réviser
Critère propre à ce module: Au moins un test négatif vérifie l'absence d'effet dans le système cible, pas seulement le texte affiché.
- 4 points: analyse du mécanisme, calculs ou relations documentaires corrects.
- 3 points: justification de la décision par des données et des hypothèses explicites.
- 2 points: traitement réel de la variante, avec une conclusion adaptée.
- 1 point: référence précise et limite de portée correctement identifiées.
Repère interne proposé: 8/10 sans erreur critique. Une preuve inventée, une causalité non démontrée, une unité erronée décisive ou un droit supposé sans fondement imposent une reprise. Ce barème sert à l’autoévaluation; il n’atteste pas à lui seul une compétence acquise.
Après comparaison, corrigez votre dossier dans une seconde version et ajoutez un court journal: erreur repérée, effet sur la conclusion, correction et vérification restante. Conservez les deux versions seulement si vous avez réellement effectué l’activité.
Références et portée
COURS VOCE® Démonstrateur pédagogique
Nature: document VOCE. Version: 2026-10-13.
Portée du registre: cas professionnels, exercices et critères des 16 cours. Vérification documentaire enregistrée: 2026-10-17.
Lecture intégrale du PDF de 43 pages conservé, version 1; site détaillé non relu Nouvelle revue: accès direct incomplet ou en échec le 17 octobre 2026.
NIST AI Risk Management Framework
Nature: cadre volontaire. Version: 1.0, 2023.
Portée du registre: organisation du risque et dossier de décision. Vérification documentaire enregistrée: 2026-10-17.
Page officielle consultée; révision en cours signalée
NIST Generative AI Profile
Nature: cadre volontaire. Version: NIST AI 600-1, 2024.
Portée du registre: tests, traçabilité et limites des systèmes génératifs. Vérification documentaire enregistrée: 2026-10-17.
Notice officielle NIST consultée; sections détaillées à relire avant validation
OWASP LLM06 Excessive Agency
Nature: référentiel sécurité. Version: 2025.
Portée du registre: droits, portée des outils, autonomie excessive. Vérification documentaire enregistrée: 2026-10-17.
Page officielle consultée
Les compétences VCLF sont des repères internes. Aucun alignement supplémentaire avec ESCO, e-CF ou un niveau de qualification n’est déduit automatiquement de cette réécriture. Les statuts de vérification ci-dessus restent ceux du registre; ils ne constituent pas une nouvelle lecture intégrale de chaque source.
Version et provenance
Compétence: VCLF-GOV-AI003. Réécriture et cas complémentaires: VOCE Association avec assistance IA, 18 octobre 2026. Le socle documentaire antérieur et ses réserves sont conservés. Relecture indépendante et mesure des durées auprès d’apprenants: à réaliser.