Tiens un ledger de preuves et de remédiations

Dossier de preuves

« Une capture d’écran ou une commande réussie suffit comme preuve. »

Non. Une preuve n’a de valeur pédagogique que si elle est reliée à une exigence, un contexte, une action ou un raisonnement, un résultat observé, une vérification et une limite.

01Pourquoi utiliser un ledger

Pendant les évaluations BTS, tu produis plusieurs types d’éléments :

captures
commandes
journaux
configurations
calculs
schémas
matrices
résultats de tests
décisions argumentées

Le ledger évite de transformer ces éléments en collection de fichiers sans lien avec les compétences évaluées.

Le contrat commun est :

EXIGENCE
→ CONTEXTE
→ ARTEFACT
→ ACTION OU RAISONNEMENT
→ RESULTAT OBSERVE
→ VERIFICATION
→ LIMITE
→ DECISION

02Utilise le template de preuves

Template vierge :

Télécharger le ledger de preuves

Une ligne correspond à un critère ou une exigence démontrée, pas à une commande exécutée.

Champs principaux :

Champ	Question
`assessment_id`	de quelle évaluation vient la preuve ?
`criterion_id`	quel critère est concerné ?
`requirement`	qu’est-ce qui doit être démontré ?
`context`	dans quel scénario et quel périmètre ?
`artifact_ref`	où se trouve la pièce conservée ?
`student_action_or_reasoning`	qu’as-tu fait ou conclu ?
`observed_result`	qu’as-tu réellement observé ?
`verification`	comment le résultat a-t-il été contrôlé ?
`limit`	que ne peux-tu pas conclure ?
`assessor_decision`	décision de l’évaluateur

03Ne confonds pas résultat et vérification

Exemple générique :

RESULTAT OBSERVE
le service répond sur le port attendu

VERIFICATION
requête fonctionnelle depuis le client autorisé
+ contrôle que le flux interdit reste refusé

LIMITE
ce test ne démontre pas la haute disponibilité ni la capacité sous charge

La limite n’affaiblit pas la preuve. Elle montre que tu sais exactement ce que l’observation permet d’affirmer.

04Une preuve doit être reproductible

Un autre technicien doit pouvoir comprendre :

quoi était attendu
sur quel composant
avec quelle condition initiale
quelle action a été réalisée
quel résultat a été obtenu
comment il a été vérifié

Évite les noms comme :

capture1.png
preuve-final-v2-ok.png
log.txt

Préfère une convention explicite :

ASSESSMENT-CRITERION-DATE-TYPE

Exemple fictif :

BTS-SISR-Y2-INTEG-001-C07-20261021-negative-test.txt

05Quand un critère échoue

Un échec n’est pas effacé du ledger.

La boucle correcte est :

critère évalué
→ preuve initiale
→ décision non validée
→ lacune observable
→ remédiation ciblée
→ nouveau cas équivalent
→ réévaluation du critère affecté
→ décision finale

Tu ne recommences pas automatiquement toute l’évaluation si les autres critères restent valides.

06Utilise le journal de remédiation

Template vierge :

Télécharger le journal de remédiation

Statuts :

OPEN
REMEDIATION_ASSIGNED
READY_FOR_RETEST
CLOSED_VALIDATED
CLOSED_NOT_VALIDATED

Le journal conserve :

criterion_id
résultat initial
lacune observée
activité de remédiation
variante de réévaluation
date
résultat du re-test
preuve du re-test
limite restante

07La remédiation doit être ciblée

Si le problème concerne la distinction DNS / connectivité IP, la remédiation doit entraîner cette discrimination.

Elle ne doit pas devenir :

refaire tout le cours réseau
refaire toute l'évaluation
mémoriser la cause du sujet précédent
recevoir la suite exacte de commandes du corrigé

Le re-test doit changer les valeurs ou le contexte tout en évaluant la même compétence.

08Exemple sans corrigé d’évaluation

Critère fictif :

CRIT-07 — prouver qu'un flux autorisé fonctionne sans ouvrir un flux interdit

Premier passage :

preuve positive : présente
preuve négative : absente

Décision :

NON VALIDE sur ce critère

Remédiation :

revoir la construction d'une recette positive/négative

Re-test :

nouveau scénario avec autre source, destination et service

Le formateur ne te donne pas la règle exacte à créer. Il réévalue ta capacité à construire et prouver la recette.

09Frontière des preuves

N’ajoute jamais dans les livrables pédagogiques :

mot de passe
clé privée
token
secret d'API
donnée personnelle réelle
topologie de production sensible
identifiant réel non nécessaire

Utilise les identités, adresses et artefacts synthétiques du laboratoire.

Si une capture contient un secret, elle n’est pas une « bonne preuve » simplement parce qu’elle montre le résultat attendu.

10Checklist avant remise

Pour chaque critère :

[ ] l'exigence est nommée
[ ] le contexte est borné
[ ] l'artefact est référencé
[ ] le résultat est observé et non inventé
[ ] une vérification existe
[ ] la limite est explicite
[ ] aucun secret ou donnée personnelle réelle n'est présent
[ ] si échec : le journal de remédiation est ouvert
[ ] si re-test : l'historique initial est conservé

✓À retenir

Ton dossier de preuves doit raconter une chaîne vérifiable, pas montrer une collection de captures. Une remédiation réussie conserve l’échec initial, cible la compétence manquante et démontre la progression sur un cas équivalent.