# Appel d’offre pédagogique — Réseau de SORIA Distribution

## 1. Contexte

SORIA Distribution exploite deux sites :

- un siège administratif et commercial ;
- un dépôt logistique distant.

L’entreprise veut remplacer une architecture devenue difficile à exploiter. La nouvelle solution doit rester compréhensible par une petite équipe informatique, limiter les interruptions et fournir des preuves de fonctionnement.

Ce projet est un exercice pédagogique. Il ne constitue pas un marché réel et n’attribue aucun diplôme, titre ou certification.

## 2. Périmètre

La proposition doit couvrir :

- architecture logique et physique des deux sites ;
- plan d’adressage IPv4 et VLAN ;
- services DHCP et DNS ;
- routage inter-VLAN ;
- filtrage stateful et publication contrôlée de services ;
- liaison intersite et accès distant sécurisé ;
- continuité de la passerelle au siège ;
- supervision, alertes, sauvegarde des configurations et runbooks ;
- dossier de recette et procédure de retour arrière.

Le candidat peut simuler la solution avec Packet Tracer, GNS3, EVE-NG, des VMs Linux ou une combinaison documentée. Les limitations de l’outil choisi doivent être explicites.

## 3. Données de dimensionnement

### Siège

- 50 utilisateurs à terme ;
- 60 postes filaires ou docks ;
- 10 téléphones IP ;
- 8 points d’accès ;
- 12 caméras ;
- 6 serveurs ou appliances ;
- 20 % de réserve minimale ;
- environ 430 W de budget PoE utile ;
- deux accès WAN disponibles ;
- deux équipements de passerelle prévus.

### Dépôt

- 20 utilisateurs à terme ;
- 18 postes ou terminaux logistiques ;
- 4 téléphones IP ;
- 4 points d’accès ;
- 5 caméras ;
- 25 % de réserve minimale ;
- environ 213 W de budget PoE utile ;
- un accès WAN principal ;
- possibilité d’un lien de secours à justifier.

## 4. Segmentation minimale attendue

Le candidat doit justifier les VLAN et préfixes. Le minimum fonctionnel est :

- management ;
- utilisateurs ;
- serveurs ;
- téléphonie ;
- Wi-Fi collaborateurs ;
- Wi-Fi invités ;
- caméras et objets connectés ;
- transit inter-équipements ;
- accès distant VPN.

Les réseaux invités et objets connectés ne doivent pas accéder directement au management.

## 5. Flux métier prioritaires

- utilisateurs vers DNS, DHCP et intranet ;
- dépôt vers application logistique du siège ;
- administrateurs vers équipements uniquement depuis le VPN ou le VLAN management ;
- caméras vers leur service d’enregistrement ;
- invités vers Internet uniquement ;
- supervision vers les équipements et services ;
- sauvegarde des configurations vers un dépôt protégé.

Chaque flux doit indiquer source, destination, protocole, port, justification et décision allow/deny.

## 6. Disponibilité et reprise

La proposition doit traiter :

- perte d’un lien inter-routeurs ;
- perte du gateway principal du siège ;
- indisponibilité du tunnel intersite ;
- perte d’un service HTTP interne ;
- disparition d’une route ou d’un voisin OSPF ;
- restauration d’une configuration après erreur opérateur.

Les objectifs doivent être formulés avec des critères mesurables : délai de détection, durée de basculement, pertes acceptables, RTO, RPO et preuve attendue.

## 7. Sécurité minimale

- administration hors des réseaux utilisateurs ;
- SSH par clés et comptes nominatifs ;
- mots de passe et clés privées absents du dossier livré ;
- filtrage inter-VLAN selon le moindre privilège ;
- accès distant par VPN ;
- WPS désactivé ;
- WPA2/WPA3-Enterprise lorsque le matériel le permet ;
- logs et alertes exploitables ;
- secrets gérés séparément des configurations sanitizées.

## 8. Livrables obligatoires

1. synthèse exécutive ;
2. registre des exigences et hypothèses ;
3. architecture logique et physique ;
4. plan d’adressage et tableau VLAN ;
5. matrice de flux ;
6. note de dimensionnement ports, PoE, uplinks et WAN ;
7. configurations ou extraits sanitizés ;
8. simulation ou laboratoire reproductible ;
9. plan de recette complété avec preuves ;
10. stratégie de supervision et d’alerting ;
11. stratégie de sauvegarde et restore drill ;
12. risques, limites, coûts relatifs et décisions différées ;
13. runbooks d’incident et rollback ;
14. support de soutenance.

## 9. Contraintes de réponse

- aucune marque n’est imposée ;
- tout modèle cité doit être relié à une fonction et une capacité ;
- les prix non vérifiés doivent être indiqués comme estimations ;
- les fonctions non simulables doivent être décrites et validées autrement ;
- une capture d’écran seule n’est pas une preuve suffisante sans commande, résultat attendu et interprétation ;
- les secrets réels ne doivent jamais être inclus.

## 10. Soutenance

Durée recommandée : 20 minutes de présentation et 15 minutes de questions.

La démonstration doit inclure au moins :

- un flux autorisé ;
- un flux interdit ;
- une panne et un basculement ;
- une alerte ;
- une vérification de snapshot ;
- un choix d’architecture contestable défendu avec preuves.