« Une capture d’écran qui montre que ça marche est une preuve suffisante. »
Une capture peut être une trace utile, mais elle ne dit pas toujours ce qui était exigé, dans quel contexte le test a été réalisé, ce qui a réellement été vérifié ni ce que le résultat ne démontre pas.
01Distingue trace, preuve et conclusion
Une trace est un élément observé : sortie de commande, capture, extrait de configuration, ticket, journal, schéma ou résultat de test.
Une preuve relie cette trace à une exigence précise et à un contexte connu.
Une conclusion dit ce que tu peux raisonnablement affirmer à partir de la preuve.
Trace
systemctl affiche "active (running)"
Preuve possible
Le service nginx est actif sur la machine web01 au moment du test.
Conclusion acceptable
nginx est démarré localement sur web01.
Conclusion excessive
Le site est disponible pour tous les utilisateurs et résiste à une panne serveur.
La dernière phrase dépasse largement ce que la trace démontre.
02Utilise toujours les cinq champs
Chaque fiche de preuve du parcours doit contenir au minimum :
EXIGENCE
Ce qui devait être démontré.
CONTEXTE
Machine, réseau, rôle, scénario et conditions utiles.
ACTION
Ce que tu as fait ou observé.
RÉSULTAT + VÉRIFICATION
Le résultat obtenu et le test qui permet de le vérifier.
LIMITE
Ce que la preuve ne permet pas d'affirmer.
Tu peux ajouter :
Date
Auteur
Compétence travaillée
Référence du ticket ou du changement
Fichiers associés
Hash des fichiers importants
Décision ou suite à donner
03Choisis la preuve selon la question
Une bonne preuve répond à la question posée, pas à une question voisine plus facile.
04Ajoute un test positif et un test négatif quand c’est pertinent
Le test positif vérifie que ce qui doit fonctionner fonctionne.
Le test négatif vérifie qu’un comportement interdit ou inattendu reste bloqué.
Exemple de segmentation :
Exigence
Le poste d'administration doit joindre le serveur en SSH.
Le poste invité ne doit pas pouvoir le joindre.
Test positif
poste-admin → serveur:22 = autorisé
Test négatif
poste-invite → serveur:22 = bloqué
Si tu ne réalises que le test positif, tu ne démontres pas l’isolation attendue.
05Utilise une convention de nommage stable
Un dossier de deux ans devient inutilisable si les fichiers s’appellent capture1.png, test-final-v2-bis.txt et nouveau-document.md.
Une convention simple :
AAAA-MM-JJ_domaine_objet_type.ext
Exemples :
2026-11-04_reseau_plan-adressage_v1.md
2026-11-04_reseau_dns-test-client.txt
2027-01-12_windows_gpo-habilitations_validation.md
2027-04-08_support_ticket-inc0021_compte-rendu.md
Le nom doit aider à retrouver le contexte avant même d’ouvrir le fichier.
06Construis une fiche modèle
Crée preuves/MODELE-PREUVE.md :
# Preuve — titre court
## Exigence
## Contexte
## Action
## Résultat et vérification
## Limite
## Fichiers associés
## Conclusion
Puis duplique ce modèle au lieu de repartir d’une page vide à chaque activité.
07Préserve l’intégrité sans surpromettre
Pour un fichier important, tu peux conserver une empreinte :
sha256sum 2026-11-04_reseau_dns-test-client.txt \
> 2026-11-04_reseau_dns-test-client.sha256
sha256sum -c 2026-11-04_reseau_dns-test-client.sha256
Cela permet de détecter une modification du fichier après calcul de l’empreinte.
Cela ne prouve pas automatiquement :
- qui a créé le fichier ;
- que son contenu est vrai ;
- que l’horloge de la machine était correcte ;
- que la collecte respecte une chaîne de conservation juridique.
L’empreinte est donc un contrôle d’intégrité, pas une preuve magique d’authenticité.
08Nettoie avant d’archiver
Une preuve pédagogique ne doit pas contenir :
mot de passe réel
clé privée
jeton d'API
cookie de session
adresse personnelle
nom réel inutile
capture d'un compte personnel
secret de production
topologie sensible sans nécessité pédagogique
Si une valeur sensible est nécessaire pour comprendre le format, remplace-la par une valeur fictive clairement marquée :
TOKEN_DE_LAB_EXEMPLE
192.0.2.10
utilisateur-demo
soria.lab
Ne masque pas une donnée après l’avoir déjà publiée dans un dépôt : la suppression visuelle n’annule pas l’exposition historique.
09Évalue la qualité avant de conserver
Pose-toi cinq questions :
1. Est-ce que l'exigence est explicite ?
2. Est-ce que le contexte permet de comprendre le test ?
3. Est-ce que la vérification répond réellement à l'exigence ?
4. Est-ce que la conclusion reste dans la portée de la preuve ?
5. Est-ce que le fichier peut être partagé sans exposer de secret ou de donnée réelle ?
Si une réponse est non, la preuve doit être corrigée avant d’entrer dans le dossier.
10Relie les preuves entre elles
Un dossier professionnel n’est pas une galerie d’images. Les éléments racontent une chaîne :
besoin
→ décision
→ changement
→ test
→ résultat
→ incident éventuel
→ correction
→ nouvelle vérification
Par exemple, un plan d’adressage peut être relié à une configuration DHCP, puis à un ticket de panne, puis à un diagnostic et enfin à une recette après correction.
Cette continuité montre davantage de compétence que dix captures indépendantes.
Transforme trois traces en preuves
Choisis trois traces de laboratoire différentes : une sortie de commande, un schéma ou fichier de configuration, et un résultat de test. Pour chacune, produis une fiche avec les cinq champs obligatoires. Ajoute au moins une limite explicite et vérifie qu’aucune donnée sensible n’est présente. Calcule ensuite une empreinte SHA-256 d’un des fichiers et explique précisément ce que cette empreinte démontre et ce qu’elle ne démontre pas.
✓À retenir
Une preuve n’est pas un décor ajouté après le travail. Elle fait partie du travail : elle relie une exigence à une action, à une vérification et à une conclusion dont la portée reste maîtrisée.