« Le projet est terminé quand la topologie fonctionne dans le simulateur. »
Une solution professionnelle doit aussi expliquer les exigences, prouver les flux, décrire les limites, préparer l’exploitation et permettre à un tiers de reproduire les tests.
01Lire l’appel d’offre sans choisir trop tôt
Télécharge le brief final. Commence par produire quatre listes séparées :
- besoins métier ;
- contraintes techniques et administratives ;
- hypothèses à confirmer ;
- solutions candidates.
Ne transforme pas immédiatement chaque besoin en modèle d’équipement. Une exigence comme « accès logistique disponible » doit d’abord devenir un flux, une criticité, un objectif de reprise et un test d’acceptation.
02Construire le dossier
Crée l’arborescence indiquée dans le modèle :
mkdir -p projet-reseau-soria/{03-architecture,04-adressage,05-flux,06-dimensionnement,07-configurations/sanitized,08-simulation,09-recette/preuves,10-exploitation/runbooks,13-soutenance}Ajoute d’abord les fichiers de décision et de recette. La simulation doit servir le dossier, pas devenir l’unique source de vérité.
03Choisir le niveau de simulation
Le projet peut utiliser Packet Tracer, GNS3, EVE-NG, des VMs Linux ou plusieurs outils. Documente précisément ce que chaque outil prouve.
Au minimum, la démonstration doit présenter :
- VLAN et routage ;
- DHCP et DNS ;
- un flux autorisé et un flux refusé ;
- liaison intersite ou son équivalent documenté ;
- panne de route ou de gateway ;
- test applicatif de bout en bout.
04Compléter la recette
Copie le plan de recette dans le dossier puis complète chaque ligne :
cp module5d-plan-recette.csv projet-reseau-soria/09-recette/plan-recette.csvPour chaque test, indique :
- précondition réelle ;
- action exacte ;
- résultat attendu ;
- résultat observé ;
- statut ;
- preuve ;
- interprétation en cas d’échec.
Un test échoué et correctement expliqué vaut mieux qu’un statut « OK » sans preuve.
05Tester les scénarios critiques
Démontre la continuité et le moindre privilège
- valide un flux métier autorisé ;
- valide un flux interdit vers le management ;
- provoque la perte d’un lien ou du gateway principal ;
- mesure la durée de convergence ou de failover ;
- arrête un service HTTP et observe l’alerte associée ;
- vérifie un snapshot puis restaure une règle dans un environnement isolé.
06Contrôler la livraison
Copie la grille à la racine du projet, puis exécute le validator :
cp module5d-grille-evaluation.csv projet-reseau-soria/grille-evaluation.csv
chmod +x module5d-validate-delivery.sh
./module5d-validate-delivery.sh projet-reseau-soriaLe validator contrôle la présence de fichiers obligatoires, le poids de la grille, le dossier de preuves et plusieurs motifs sensibles. Il ne peut pas garantir l’absence de secret ni la qualité technique du contenu.
07Préparer la soutenance
Structure recommandée pour 20 minutes :
Prépare des réponses factuelles aux questions suivantes :
- quel est le principal point unique de panne restant ?
- pourquoi ce plan d’adressage ?
- quel flux serait bloqué en premier lors d’un incident ?
- comment révoquer un accès distant ?
- comment prouver qu’un backup est restaurable ?
- quelle décision changerait avec un budget plus faible ?
08S’autoévaluer
La grille totalise 100 points. Elle évalue autant la cohérence et les preuves que le fonctionnement de la maquette. Ne donne pas le score maximal à un élément non testé : indique plutôt la preuve manquante et le plan de validation.
✓Ce que tu livres
Un dossier final reproductible, une architecture justifiée, une simulation dont les limites sont déclarées, une recette avec preuves, une stratégie d’exploitation et une soutenance capable de défendre les arbitrages.