Architecture des réseaux · Étape 23

Traduis un besoin métier en contraintes réseau

Transforme un brief de PME, ses phrases ambiguës et ses risques en exigences mesurables, matrice de flux, criticité et critères d’acceptation.

Durée indicative · ~1 h 45Niveau intermédiairePrérequis conseillé · Modules 1 à 4 — adressage, services, segmentation et sécuritéPratique · TP
L’idée reçue

« Concevoir un réseau commence par choisir un firewall et des switches. »

Le matériel vient après. Une architecture commence par les activités à maintenir, les flux nécessaires, les pannes acceptables et les preuves attendues.

Tu interviens pour SORIA Distribution, une PME de deux sites. La direction a fourni des besoins utiles, mais aussi des formulations vagues. Ta mission est de produire un registre exploitable avant toute sélection d’équipement.

BesoinCe que l’activité doit pouvoir faire

Exemple : le dépôt consulte l’ERP.

ContrainteCe qui limite les choix

Exemple : migration sans arrêt complet.

HypothèseCe qui reste à confirmer

Exemple : six points d’accès suffisent.

01Lire sans proposer de solution

Télécharge le brief dans les ressources. Pendant la première lecture, interdiction d’écrire un nom de marque ou un modèle d’équipement.

Crée quatre colonnes :

DéclarationTypeSourceQuestion restante
Les visiteurs ont seulement accès à Internet.Fonctionnelle + sécuritéDirectionPortail captif ou simple accès isolé ?
Le réseau ne doit jamais tomber.Non fonctionnelle, non mesurableDirectionQuel temps d’arrêt et quel périmètre ?
Six AP sont prévus au siège.HypothèseInventaire initialUne étude radio l’a-t-elle validé ?
La migration doit maintenir l’activité.Contrainte projetDirectionQuelles fenêtres de maintenance ?
Une même phrase peut produire plusieurs exigences. « Le dépôt continue à préparer les commandes » implique le réseau, mais aussi la disponibilité locale des données et de l’application.

02Remplacer les absolus par des objectifs

La phrase « le réseau ne doit jamais tomber » n’est ni testable ni finançable telle quelle. Décompose-la :

1PérimètreInternet, ERP, LAN ou téléphonie ?
2DuréeCombien de minutes ou d’heures ?
3PerteCombien de données peuvent disparaître ?
4PreuveQuel test démontrera le résultat ?

Exemple de reformulation :

Le service ERP doit être restauré en moins de 2 heures après une panne
simple d’infrastructure, avec une perte maximale de 30 minutes de données.
La validation consiste à chronométrer une restauration documentée sur un
jeu de sauvegarde vérifié.

Tu viens de relier :

  • le RTO : durée maximale avant rétablissement ;
  • le RPO : quantité maximale de données perdues ;
  • le test d’acceptation : preuve concrète du respect de l’objectif.

03Construire la matrice de flux

Une segmentation sans matrice de flux devient une collection de VLAN sans politique. Pars des rôles et des services.

Source
Destination
Décision
Utilisateurs
ERP · HTTPS
Autoriser
Dépôt
ERP · HTTPS
Autoriser
Caméras
NVR, DNS, NTP
Limiter
Invités
Réseaux internes
Bloquer
VPN admin
Management · SSH/HTTPS
Autoriser
Utilisateurs
Management
Bloquer

Pour chaque ligne, précise ensuite :

  • protocole et port quand ils sont connus ;
  • direction de l’initiation ;
  • identité ou groupe autorisé ;
  • besoin de journalisation ;
  • propriétaire métier du flux ;
  • méthode de test.

04Classer la criticité

ClasseImpactExempleRéponse attendue
C1Activité arrêtéeERP / stockRTO et RPO validés, reprise testée
C2Travail fortement dégradéInternet / téléphonieContournement ou rétablissement rapide
C3Fonction secondaire indisponibleImpressionIntervention planifiée
C4Confort uniquementWi-Fi invitéBest effort

La classe ne se déduit pas du prestige technique du service. Elle vient de l’impact métier.

05Écrire des critères d’acceptation

Une exigence bien écrite permet une réponse oui/non. Complète au minimum ces tests :

AC-01 — Un poste invité reçoit une adresse du VLAN invité, atteint Internet
et échoue à joindre les préfixes internes.

AC-02 — La suppression du lien intersite ne supprime pas les fonctions locales
du dépôt définies dans le plan de continuité.

AC-03 — Un compte administrateur connecté par VPN atteint les interfaces de
management ; un poste utilisateur standard échoue.

AC-04 — Une panne critique génère une alerte en moins de 5 minutes.

AC-05 — La restauration de la configuration d’un switch est exécutée depuis
une sauvegarde datée et documentée.

06Identifier les questions bloquantes

Avant l’architecture, adresse au commanditaire les questions qui changent réellement le coût ou le risque :

  1. quelles fonctions du dépôt doivent rester locales pendant une coupure intersite ?
  2. le RTO de 30 minutes pour Internet exige-t-il un second opérateur ou accepte-t-on un routeur 4G/5G de secours ?
  3. quelles applications utilisent des adresses IP codées en dur ?
  4. le câblage et les baies ont-ils été audités ?
  5. quelles personnes approuvent les flux caméra, invités et administration ?
  6. quelle fenêtre de migration est acceptable ?
Erreur volontaire

Confonds besoin et solution

Écris d’abord : « Il faut deux firewalls en haute disponibilité. » Puis corrige cette phrase en trois éléments distincts :

  1. le service métier à maintenir ;
  2. la durée d’interruption acceptable ;
  3. les solutions candidates, dont la paire de firewalls n’est qu’une option.

07Livrable autonome

À partir du brief, produis un dossier court contenant :

  • 10 exigences numérotées ;
  • 5 hypothèses à confirmer ;
  • 5 questions au commanditaire ;
  • une matrice d’au moins 12 flux ;
  • les classes de criticité des services ;
  • un test d’acceptation par exigence importante.

Ce que tu retiens

L’architecture n’est pas une liste d’équipements. Elle relie un besoin métier à une exigence mesurable, une hypothèse explicite, un risque et une preuve de validation.

Ta progression

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