TP – Mener ma réalisation 1 de bout en bout

BTS SIO SISR 2e année – Bloc 2 – S16 – travail individuel ; relecture croisée en fin de séance

Note

But. Tu construis ta réalisation 1 (celle cadrée en S15), du dossier de choix à la fiche descriptive, en fabriquant les preuves au fur et à mesure. Si tu n'as pas de projet, prends l'un des sujets de secours.

Durée : 3 h 40 de séance (parties A à E), plus le travail personnel nécessaire entre deux séances. Prérequis : cours S16 lu ; ta fiche de cadrage de S15.

Note

Comment ce TP fonctionne. C'est un chantier : les consignes donnent la méthode et les points de contrôle, pas les commandes. Tu t'appuies sur tes séances précédentes.

Nom : ____________ Réalisation 1 : ____________________________

Partie A – Le kit de démarrage (≈ 20 min)

Crée l'arborescence de ton dossier de réalisation et un dépôt Git :

mkdir -p ~/R1/{docs,configs,scripts,preuves,tests}
cd ~/R1 && git init
printf "# Réalisation 1 : INTITULÉ\n" > README.md
printf "| Date, heure | Action | Résultat | Preuve |\n|---|---|---|---|\n" > docs/journal-de-bord.md
git add . && git commit -m "Initialiser le dossier de la réalisation 1"

Dossier	Contenu
`docs/`	Cahier des charges, dossier de choix, documentation technique, utilisateur, journal
`configs/`	Configurations sans secret
`scripts/`	Scripts d'installation et d'exploitation
`preuves/`	Captures, sorties de commandes, journaux
`tests/`	Plan de recette, rapport de tests

Je comprends. Pourquoi interdire les secrets (mots de passe, clés privées) dans configs/ ? Comment les gérer ? ______________________

Éléments de réponse

Le dépôt peut être lu, copié, rendu accessible à un jury : les secrets sont une fuite en puissance, et Git conserve l'historique (S08). On les remplace par des gabarits (motdepasse = À-DÉFINIR) et on les garde dans un fichier à part, hors dépôt, ou chiffré (Ansible Vault). Les mots de passe de laboratoire peuvent être simples mais ne doivent pas être réutilisés ailleurs.

Partie B – Concevoir et préparer les tests (≈ 50 min)

1. Rédige dans docs/ :

le cahier des charges reformulé (besoin, contraintes, exigences mesurables) ;
un dossier de choix comparant deux options sur un choix structurant (tableau du cours) ;
le schéma et le plan d'adressage ;
l'analyse d'impact : quels éléments existants sont touchés par la solution ? quels risques en cas de mauvaise utilisation ou de panne ?

2. Prépare, avant d'installer, le plan de recette dans tests/plan-de-recette.md :

#	Exigence	Scénario	Attendu	Mesure / preuve
T1
T2
T3
T4

Point de contrôle (à faire valider par l'enseignant ou un camarade) : chaque exigence a au moins un test mesurable.

Éléments de réponse

Un plan de recette utile contient des tests de fonctionnement nominal, de panne (un composant arrêté), de sécurité (accès non autorisé refusé) et de restauration. Exemple pour un service web disponible : T1 page servie par la VIP ; T2 arrêt d'un serveur sans interruption visible ; T3 alerte reçue dans les 5 minutes ; T4 restauration depuis la sauvegarde en moins de 4 heures.

L'analyse d'impact est une compétence de la grille (« étudier l'impact d'une évolution ») : cite les services, les utilisateurs, les flux et les sauvegardes touchés.

Partie C – Mettre en œuvre par jalons (≈ 90 min)

Découpe ta mise en œuvre en jalons de 15 à 30 minutes. Pour chaque jalon, tu notes dans le journal avant de passer au suivant. Exemple de découpage :

Jalon	Contenu	Preuve attendue
J1	Maquette : machines et réseaux	`ip -br a` de chaque machine, schéma à jour
J2	Service principal installé et testé	Capture du service qui répond
J3	Éléments de sécurité (VPN, pare-feu, droits)	Configuration, `wg show`, règles
J4	Éléments de continuité ou de qualité (HA, QoS, sauvegarde)	Configuration, test
J5	Supervision et alerte	Capture de l'alerte reçue

À chaque jalon :

Installer / configurer (dans l'ordre prévu) ;
Tester (les tests de la partie B) ;
Versionner la configuration (git commit -m "…pourquoi…") ;
Noter le journal et ranger la preuve.

Warning

Quand un problème apparaît, ne passe pas au jalon suivant : applique la méthode de S13, rédige quelques lignes de rapport d'incident (symptôme, cause, correction) dans docs/incidents.md. Ces notes sont des preuves de la compétence « identifier, qualifier et réagir face à un incident ».

J'anticipe. Quels jalons risquent de dépasser le temps prévu ? Comment limiteras-tu l'impact (périmètre à réduire, plan B) ? ______________________

Éléments de réponse

Souvent : la bascule/haute disponibilité et la supervision (nombreux réglages). Une bonne réponse réduit le périmètre sans renoncer à l'exigence (deux serveurs plutôt que trois), prépare un plan B documenté, et garde du temps pour la recette et la fiche : mieux vaut une réalisation plus petite, prouvée, qu'une grande à moitié testée.

Partie D – Recette et rapport de tests (≈ 30 min)

Exécute le plan de recette et complète tests/rapport-de-tests.md :

#	Résultat obtenu (mesure, heure)	Preuve	Verdict
T1
T2
T3
T4

Écris ensuite, pour la documentation technique (docs/documentation-technique.md) :

l'architecture (schéma + adressage) ;
la procédure de reconstruction (ordre des étapes, fichiers à utiliser) ;
la procédure de restauration en cas de panne ;
la liste des alertes et la conduite à tenir.

Et une page de documentation utilisateur : comment accéder au service, qui contacter en cas de problème.

Je comprends. Quelle différence entre documentation technique et documentation utilisateur ? ______________________

Éléments de réponse

La technique s'adresse à l'administrateur : elle décrit comment c'est fait et comment le réparer. L'utilisateur décrit comment s'en servir, sans vocabulaire d'administrateur. Les deux sont attendues dans la grille (« documentation technique et utilisateur »).

Partie E – La fiche descriptive (≈ 30 min)

Rédige la fiche (modèle officiel remis par l'enseignant) : recto puis verso, avec les sections du cours. Prépare la liste des preuves à lier.

Test de lecture. Donne ta fiche à un camarade, qui la lit cinq minutes puis répond :

Question	Sa réponse
Quel est le besoin ?
Quelle est la solution ?
Qu'a fait l'auteur lui-même ?
Quelles compétences du bloc 2 sont mobilisées ?
Quelle preuve lui semble la plus convaincante ?
Que ne comprend-il pas ?

Reprends la fiche selon ses retours.

Éléments de réponse

Une fiche réussie permet à un lecteur extérieur de répondre aux cinq premières questions sans te parler. Les points qu'il ne comprend pas indiquent ce qu'il faut préciser (ou ce que tu ne sais pas expliquer).

Pour aller plus loin

Écris le script qui remonte ta maquette (scripts/demarrer.sh).
Prépare l'instantané « nominal » de chaque machine et un fichier docs/acces.md.
Chronomètre une reprise à froid : en combien de temps un camarade démarre-t-il ta maquette ?

Retour en entreprise (si ta situation le permet)

Observer : qu'est-ce qui, dans ton entreprise, ressemble à ta réalisation ? Qu'est-ce qui diffère ?
Documenter : fais relire ta documentation par ton tuteur ; note ses remarques.

Rendu

Dossier de réalisation (dépôt Git ou archive) contenant : docs/, configs/ (sans secret), scripts/, preuves/, tests/ ; et la fiche descriptive PDF nommée RENDU-B2A2-S16-NOM.pdf.

Bilan de la séance

Niveau : Non maîtrisé, Maîtrise partielle, Bonne maîtrise ou Excellente maîtrise, ou Non évalué.

Compétence du référentiel	Ce que j'ai fait dans cette séance	Niveau
B2.1 – Concevoir une solution d'infrastructure réseau
B2.2 – Installer, tester et déployer une solution d'infrastructure réseau
B2.3 – Exploiter, dépanner et superviser une solution d'infrastructure réseau

Note

Les codes sont ceux du référentiel.

Je sais faire, sans aide :

Concevoir et préparer les tests avant d'installer ;
Mettre en œuvre par jalons, avec preuves et journal ;
Versionner les configurations sans secret ;
Rédiger rapport de tests, documentation technique et utilisateur ;
Rédiger une fiche claire pour un lecteur extérieur.

Ce que je dois reprendre : ______________________

Ma question à poser à l'enseignant : ______________________