Intégration professionnelle BTS SIO SISR · Étape 01

Construis un dossier de preuves exploitable

Transforme commandes, tests, schémas, tickets et décisions en preuves traçables, vérifiables et limitées, sans exposer de données sensibles.

Durée indicative · ~1 h 30Niveau débutantPrérequis conseillé · Leçon 1 — comprendre le parcours, le laboratoire et la logique de preuvePratique · TP
L’idée reçue

« 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

Question
Preuve utile
Preuve insuffisante seule
Le client reçoit-il la bonne configuration réseau ?
adresse, passerelle, DNS + test de connectivité
capture de l’écran de configuration
Le service répond-il réellement ?
test depuis le client attendu + réponse observée
état local du processus
Le filtrage interdit-il un flux ?
test négatif depuis la zone concernée + règle correspondante
règle affichée sans test
La restauration fonctionne-t-elle ?
restauration testée + contrôle du service restauré
fichier de sauvegarde présent
Une décision était-elle justifiée ?
besoin, options, contrainte, choix, risque résiduel
nom du produit choisi

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.

Mission

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.

0
Ta progression

Chargement de l’état… Se connecter pour synchroniser.