B2-33 Concevoir, maquetter, tester et documenter

1. La démarche d'un projet technique

Installer un réseau ou un serveur, ce n'est pas seulement taper des commandes. Un projet technique suit une démarche : on comprend d'abord ce que veut le client, on choisit une solution et on la justifie, on l'essaie sur une maquette, on prouve qu'elle fonctionne, puis on la déploie et on la documente. Chaque étape produit un livrable qui sert à la suivante.

2. Analyser le besoin

Le client exprime rarement son besoin en termes techniques : « le réseau doit être fiable », « il faut que ce soit sécurisé ». Ton travail consiste à transformer ces phrases en exigences que l'on pourra vérifier, et à recenser les contraintes qui limitent les solutions possibles.

• ContexteL'organisation, l'existant (schéma, matériel, logiciels), les utilisateurs concernés, ce qui pose problème aujourd'hui.
• ObjectifCe que le projet doit apporter, en une ou deux phrases : « garantir le routage entre les services même si un routeur tombe en panne ».
• Exigences fonctionnellesCe que la solution doit faire : « les invités accèdent à Internet », « chaque service a son réseau ».
• Exigences non fonctionnellesComment elle doit le faire : disponibilité, performance, sécurité, facilité d'exploitation, évolutivité.
• ContraintesBudget, délai (fermeture estivale), matériel existant à réutiliser, compétences de l'équipe, obligations juridiques (RGPD, licences).
• Critères d'acceptationComment le client saura que c'est réussi : ce sont eux qui deviendront les tests de recette.

2.1 D'une phrase floue à une exigence mesurable

Une bonne exigence est précise, mesurable et vérifiable par un test. Si tu ne peux pas écrire le test qui la vérifie, elle est encore trop floue.

2.2 Étudier l'impact d'une évolution

Un projet modifie un système qui fonctionne déjà. Avant de choisir, demande-toi ce que le changement touche : les utilisateurs (coupure, nouvelles habitudes, formation), l'existant (adresses, VLAN, règles de filtrage à reprendre), la sécurité (nouvelle surface d'attaque, nouveaux comptes), les coûts (licences, maintenance, formation) et le juridique (données personnelles, durée de conservation des journaux, licences logicielles). Cette étude d'impact justifie souvent une partie du planning : prévoir l'intervention un soir ou pendant une fermeture, avertir les utilisateurs, garder un plan de retour arrière.

3. Le dossier de choix comparatif

Quand plusieurs solutions répondent au besoin, il faut en choisir une et pouvoir le justifier devant la direction, un collègue ou un jury. Le dossier de choix compare au moins trois solutions selon des critères pondérés, fixés avant de noter.

3.1 Les parties d'un dossier de choix

1. Rappel du besoin : objectif, exigences, contraintes (reprises de l'étape 1).
2. Solutions étudiées : au moins trois, décrites en quelques lignes chacune (principe, licence, éditeur).
3. Critères et poids : choisis avec le client, justifiés par le contexte.
4. Grille de notation : une note par critère et par solution, avec la source de l'information (documentation, essai sur maquette, devis).
5. Décision argumentée : la solution retenue, pourquoi, et ses risques ou points faibles, avec la parade prévue.

3.2 Exemple : choisir l'hyperviseur de Brocéliande Logistique

Les trois serveurs physiques du siège arrivent en fin de garantie : le responsable veut les remplacer par deux hôtes de virtualisation. Trois solutions sont étudiées : Proxmox VE (libre, support payant facultatif), Hyper-V (inclus dans Windows Server 2025) et VMware vSphere (abonnement). Les notes ci-dessous sont celles de l'équipe de Brocéliande, pour son contexte.

3.3 Des choix aux spécifications

Une fois la solution choisie, on rédige les spécifications techniques : ce qui sera installé et comment (matériel, versions, plan d'adressage, VLAN, noms, comptes de service, règles de filtrage). Pour la partie réseau de Brocéliande, ce sont les tableaux d'adressage et de VLAN du fil rouge. Les spécifications servent à construire la maquette, puis à écrire les tests : « SRV-LOG doit répondre en 172.16.50.30 » est à la fois une spécification et un résultat attendu.

4. Maquetter et prototyper

On n'installe pas directement en production une solution que l'on n'a jamais essayée. On la reproduit d'abord dans un environnement où une erreur ne coûte rien, puis on se rapproche progressivement du réel.

5. Tester : quels tests, à quel moment ?

Tester, c'est comparer un résultat obtenu à un résultat attendu écrit à l'avance. On ne teste pas tout d'un coup à la fin : chaque niveau de conception a son niveau de test. Le cycle en V représente ce lien : ce que l'on décide en descendant, on le vérifie en remontant.

6. Le cahier de recette

Le cahier de recette regroupe tous les tests d'acceptation. Il est écrit avant les tests, à partir des exigences, puis rempli pendant la campagne de tests. Il sert de preuve : pour le client, pour l'équipe qui reprendra l'installation, et pour ton jury.

• N° et exigenceUn numéro unique et l'exigence couverte (« E4 : les invités n'accèdent qu'à Internet ») : chaque exigence doit avoir au moins un test.
• PrérequisL'état de départ : quel poste, connecté où, avec quel compte, quels services démarrés.
• ProcédureLes actions et commandes, assez précises pour qu'un collègue rejoue le test sans toi.
• Résultat attenduCe qui doit se produire, écrit avant le test : « réponse de 172.16.50.30 », « Request timed out ».
• Résultat obtenu et statutCe qui s'est réellement produit, et le statut : OK, KO ou OK avec réserve.
• Preuve, date, testeurCapture d'écran ou sortie de commande, date du test et nom de la personne : c'est ce qui rend la recette opposable.

6.1 Quand un test échoue : le traitement d'une anomalie

À la fin de la campagne, on rédige le procès-verbal de recette : le client prononce la recette sans réserve, avec réserves (les anomalies mineures à corriger sous un délai convenu) ou la refuse.

7. Documenter

Une infrastructure non documentée dépend de la mémoire d'une seule personne. La documentation permet de maintenir, de dépanner vite, de faire évoluer et de transmettre. On distingue deux publics, qui n'ont pas besoin des mêmes documents.

7.1 Deux schémas complémentaires

Un seul schéma ne suffit pas. Le schéma physique montre les équipements et les câbles (quel port relié à quel port) ; le schéma logique montre les réseaux, les VLAN, les adresses et le chemin des flux. Le premier sert à câbler et à dépanner une liaison, le second à comprendre et à dépanner le routage.

7.2 Le contenu d'une documentation technique

1. Présentation : contexte, objectif, périmètre, version et historique des modifications.
2. Architecture : schémas physique et logique, plan d'adressage, tableau des VLAN, liste des équipements (modèle, rôle, adresse de gestion, emplacement).
3. Configurations : extraits commentés, et les fichiers complets en annexe (show running-config exporté).
4. Procédures d'exploitation : sauvegarder une configuration, ajouter un poste dans un VLAN, remplacer un commutateur, redémarrer proprement.
5. Recette : le cahier de recette rempli, les anomalies et leur traitement, le procès-verbal.

8. Situations de projet : à toi de décider

Voici des situations réelles de fin de projet chez Brocéliande Logistique. Pour chacune, choisis la réaction la plus professionnelle : l'explication s'affiche après ta réponse.

T9 | Tester OSPF | Résultat : ça marche | OK

R1# show ip interface g0/0.20 | include access list
  Inbound  access list is INVITES-IN

8.1 Ta réalisation est-elle prête ?

9. À l'examen et en entreprise

Tout ce que tu as appris dans cette fiche se retrouve dans les épreuves professionnelles. Les épreuves E5 et E6 s'appuient sur tes réalisations professionnelles : ce que tu as conçu, testé et documenté en stage, en atelier ou dans le fil rouge. Tous les détails sont dans le guide des épreuves.

10. L'essentiel

1. Un projet technique suit six étapes : analyser, choisir, maquetter, tester, déployer, exploiter ; chacune produit un livrable, et on documente tout au long.
2. Une exigence est précise, mesurable et vérifiable par un test ; « fiable » ou « sécurisé » sont des souhaits à traduire.
3. On recense aussi les contraintes (budget, délai, existant, compétences, juridique) et l'impact du changement.
4. Le dossier de choix compare au moins trois solutions avec des critères pondérés fixés avant de noter ; total = somme des notes × poids.
5. La décision est argumentée : solution retenue, raisons, risques et parades ; on raisonne en coût total (TCO).
6. Maquette (Packet Tracer) → prototype (VM, labo) → pilote → production : on monte quand la marche précédente est validée.
7. Tests unitaires, d'intégration, de recette et de non-régression ; sans oublier les tests négatifs et de résilience.
8. Une ligne de recette : exigence, procédure, attendu, obtenu, statut, preuve ; le résultat attendu est écrit avant le test.
9. Une anomalie est tracée (gravité bloquante, majeure, mineure), corrigée, retestée ; le PV prononce la recette avec ou sans réserves.
10. Documentation technique (schémas physique et logique, adressage, configurations, procédures) et utilisateur ; aucun mot de passe dedans.

Les repères clés

Tout cela tient sur une page : utilise le bouton Mémo à imprimer en haut de la fiche.

11. Quiz noté

12. Exercices : à toi de répondre

Écris ta réponse sous chaque énoncé et envoie-la à ton professeur. Quand il l'a validée, le corrigé s'affiche à la place du cadenas ; s'il te la renvoie « à revoir », lis son commentaire et corrige.

13. Fil rouge : la recette finale et le dossier de réalisation