TP0 — Étude d'architecture : que faut-il monter ?

Conception d'architecture Ingénieurs · ESIROI étude · arbitrage · matrice de flux · rapport

---

1. Contexte — vous êtes le bureau d’études

Ordre de mission — Direction des systèmes d’information, TAAF

Objet : étude d’architecture préalable — refonte du SI de la base Martin-de-Viviès (île Amsterdam).

Votre bureau d’études est mandaté pour proposer l’architecture du futur système d’information de la base. Vous remettrez un dossier de conception — quatre artefacts, décrits au §7 — qui constitue le chapitre TP0 de votre rapport de réalisation. Les contraintes non négociables figurent au §2 ; tout le reste relève de vos arbitrages, et chacun devra être justifié : un choix non justifié est un choix qui n’existe pas.

Les TAAF (Terres australes et antarctiques françaises) refont le système d’information de leurs bases. La Réunion est le siège — mais à des jours de lien satellite. Les bases australes — Terre Adélie, Îles Éparses, Amsterdam, Crozet, Kerguelen — doivent donc vivre par elles-mêmes : leur annuaire, leurs applications, leurs données, sur place. Et de plus en plus, elles doivent parler entre elles : partager un document, se surveiller mutuellement, s’entraider quand le siège est injoignable.

Dans ce module, le siège reste hors champ. Ce que vous concevez, c’est une base autonome, et son lien avec l’archipel voisin — qui sera, dans la suite du module, un autre groupe de la promotion, avec sa propre base.

Votre groupe n’est pas encore l’équipe qui installe. Vous êtes le bureau d’études. On vous confie une base et une question :

Qu’est-ce qu’on monte, exactement — et pourquoi ça plutôt qu’autre chose ?

À l’issue de l’étude, vous remettez votre dossier au commanditaire (l’instructeur). Il le lira comme un client lit une proposition : en cherchant les choix non justifiés et les failles. Puis, en débrief collectif, il présentera l’architecture de référence et la confrontera à la vôtre. Rédigez donc en anticipant la contestation — c’est ce qu’on attendra de vous en clientèle.

L’étude est collective, la construction sera répartie

Vous menez l’étude et la rédaction en groupe — c’est le format d’un bureau d’études. Mais dans la suite du module, chaque membre héberge sa part de la base sur son propre poste. Concevez donc en sachant que chaque membre du groupe devra être capable de monter — et de défendre — ce que le groupe aura tranché.

---

2. Ce qu’on vous impose (et rien d’autre)

Ces éléments ne se discutent pas. Tout le reste est à vous.

Contrainte	Détail	Pourquoi elle existe
Technologies 100 % open source	Pas de licence propriétaire, y compris pour l’hyperviseur, l’annuaire, le pare-feu.	Souveraineté et coût : les TAAF ne paient pas de licence par site isolé.
Éloignement géographique	Aucune intervention physique rapide. Le Marion Dufresne fait 4 rotations par an vers les subantarctiques ; la Terre Adélie n’est desservie que de novembre à février (banquise le reste de l’année).	Une panne non réparable à distance immobilise le SI jusqu’à la rotation suivante — des semaines, voire plus de six mois en Terre Adélie.
Réseau restreint	Lien satellite : bande passante faible, latence élevée, quota mensuel.	Tout ce qui « stream » vers l’extérieur coûte cher ou sature.
Contrainte météo	Épisodes cycloniques : le lien peut être coupé plusieurs jours. Coupures électriques possibles.	Le site doit fonctionner sans ses voisins ni le siège, puis se resynchroniser.
Plateforme cible	4 postes étudiants (un par membre du groupe), VirtualBox, reliés par le switch managé de la salle (voir §3).	C’est là, en groupe, que votre architecture sera réellement montée.
Travail en groupe de 4	Chaque membre héberge une part de l’infra sur son poste ; les zones sont séparées par VLAN sur le switch.	Une base se conçoit et se tient à plusieurs — la répartition fait partie de la conception.

Et une contrainte de forme : votre architecture doit être répartissable sur les 4 postes du groupe — chaque membre porte une brique cohérente (une zone, le pare-feu…). Une proposition élégante qui demande quatorze serveurs, ou que le groupe ne peut pas se répartir proprement, n’est pas une bonne proposition.

---

3. Le terrain réel — ce que vous aurez sous la main

Votre architecture sera réellement construite dans la suite du module. Concevez donc pour cette cible, pas pour un datacenter.

flowchart LR
  subgraph POSTE["🖥️ Vos 4 postes ESIROI + switch managé — votre base australe"]
    A[Membre A · OPNsense<br/>pare-feu · trunk VLAN]
    B[Membre B · zone front]
    C[Membre C · zone services]
    D[Membre D · zone SOC]
    A --- B
    A --- C
    A --- D
  end
  subgraph VOISIN["🏝️ L'archipel voisin — un autre Groupe, sa base"]
    V[OPNsense voisin<br/>+ ses 3 zones]
  end
  POSTE <-->|interconnexion conçue à l'étude<br/>tunnel chiffré · peut tomber| VOISIN
  classDef base fill:#dcfce7,stroke:#15803d
  classDef voisin fill:#dbeafe,stroke:#1d4ed8
  class POSTE base
  class VOISIN voisin

Machine	Rôle joué	Ce qui y tournera
Vos 4 postes (un par membre)	Votre base australe, répartie	Le SI local complet : le pare-feu chez l’un, chaque zone chez un membre — en VMs VirtualBox, reliées par le switch managé. Annuaire, applications, données, journaux : tout vit sur la base
La base voisine (un autre groupe, ses 4 postes)	L’archipel voisin	Leur SI, conçu par eux. Vous ne le montez pas : vous vous y raccorderez dans la suite du module, à travers un tunnel négocié à deux

Contraintes techniques de la plateforme — à intégrer dans votre conception :

• Infra répartie sur 4 postes. Chaque membre n’héberge qu’une part (une zone, ou le pare-feu) : la RAM d’un poste ne porte plus tout le SI. Mais budgétez quand même — et votre architecture doit survivre à l’extinction d’un poste.
• Segmentation par VLAN sur le switch managé. Les zones deviennent des VLAN 802.1Q : chaque poste-membre est sur un port access (dans le VLAN de sa zone), et le pare-feu OPNsense (Membre A) est sur un port trunk qui porte tous les VLAN. Vous choisissez vos numéros de VLAN (un par zone) — c’est un livrable de conception (artefact 4).
• Le piège 802.1Q. VirtualBox retire les étiquettes VLAN sur ses cartes : d’où le choix access untagged côté membres (le switch fait la zone) et trunk uniquement vers OPNsense (router-on-a-stick). Garantir que le trafic inter-zone traverse le pare-feu reste une question de conception — axe A.
• Le raccordement base ↔ base voisine se fera par tunnel chiffré entre les deux pare-feu — c’est l’objet de l’axe C : concevez-le sur le papier aujourd’hui, vous le monterez plus tard dans le module, avec l’autre groupe.

---

4. Le périmètre fonctionnel à couvrir

Le commanditaire attend que votre architecture rende ces services. À vous de dire avec quoi, dans quelle zone et pourquoi là.

Un point de départ est déjà fixé : tout vit sur la base. Il n’y a pas de service central joignable — le siège est à des jours de lien satellite, et le module ne le simule pas. La vraie question, pour chaque besoin ci-dessous, devient donc double : qu’est-ce qui doit tenir seul quand tout lien tombe — et qu’est-ce qu’on accepte de partager avec la base voisine ?

4.1 Services de la base

Besoin	Question que vous devez trancher
Identités / authentification	L’annuaire vit sur la base. Qui en dépend, et sur quels ports ? Un agent de la base voisine doit-il pouvoir s’y authentifier à travers le tunnel — ou jamais ?
Applications web	Le frontal exposé, et sa base de données. Quelle séparation entre les deux ?
Données scientifiques	Où vivent-elles ? Base de données, stockage — qui y accède, depuis où ? Et la base voisine peut-elle en héberger une copie (sauvegarde croisée), sachant le lien qu’on a ?
Partage de fichiers	Un Nextcloud sur la base. Un agent de l’archipel voisin doit consulter un document partagé : par où passe-t-il, avec quelle identité ?
Certificats internes	Qui délivre les certificats des services de la base ? Une CA interne — et dans quelle zone la mettre, elle qui fait confiance à tout le monde ?
Administration	D’où administre-t-on tout ça ? Ce plan d’administration doit-il être joignable depuis le frontal web ?

4.2 L’interconnexion avec la base voisine (#INFRA)

La base ne vit pas seule : l’archipel voisin a sa propre base, et les deux ont des choses à s’offrir — un document partagé, une surveillance croisée, une copie de sauvegarde. Tout cela passe par un seul lien — lent, cher, et qui tombe — entre deux organisations qui ne se font pas confiance par défaut. Votre architecture doit dire :

1. Par où le lien entre dans le SI de la base — dans quelle zone il se termine, et sur quel équipement.
2. Ce qui a le droit de le traverser — le tunnel n’est pas un câble magique : les flux qui le traversent se listent et se justifient, comme les autres. Et ce que le voisin ne verra jamais — votre annuaire, votre plan d’administration.
3. Comment les deux extrémités se reconnaissent — et ce qui se passe quand le lien revient après trois jours de coupure.

4.3 La place de la sécurité (#SECU)

Vous ne construisez pas la détection dans ce module — mais une architecture qui n’a pas prévu sa place ne pourra pas l’accueillir. Répondez donc simplement à :

• Où sont produits les journaux, et où sont-ils centralisés ? Qui pousse, qui tire — et qu’est-ce que ce choix implique pour vos règles de filtrage ?
• L’endroit qui reçoit les journaux : que doit-il pouvoir atteindre dans le SI ? Et si la réponse est « rien », comment votre architecture le garantit-elle ?
• Qui a le droit d’aller lire ces journaux — et depuis où ?

La question qu’on vous posera

« Votre serveur est compromis. Vos journaux, ils sont où — et la machine qui les détient, jusqu’où peut-elle aller ? » Réfléchissez-y maintenant — pas au montage, quand tout sera déjà câblé.

---

5. La méthode — quatre temps

Ce TP se conduit à votre rythme, mais pas sans discipline : un bureau d’études qui ne borne pas sa recherche rend une page blanche. Au cadrage, décidez en groupe du temps que vous accordez à la recherche — et tenez-le.

Temps	Ce que vous faites
Cadrage	Lecture de ce sujet en groupe. Répartition des 4 axes de recherche (§6). Un rapporteur est désigné : c’est lui qui déclare la recherche close et fait basculer le groupe en synthèse, même si un axe est incomplet.
Recherche	Chacun creuse son axe et répond à ses questions directrices. Notes écrites obligatoires — vous allez devoir les fusionner.
Synthèse	Mise en commun. Arbitrages. Production des 4 artefacts (§7). C’est là que le groupe tranche pour de bon.
Rédaction	Vous rédigez le chapitre TP0 du rapport — les 4 artefacts, vos arbitrages, les réponses aux dix questions (§8 et §9).

Le vrai risque : chercher au lieu de décider

Le mode d’échec habituel d’un bureau d’études : on cherche indéfiniment et on rend une page blanche. D’où la limite que vous vous fixez au cadrage : quand elle est atteinte, vous passez à la synthèse, même si un axe est incomplet. Une décision assumée avec un « nous n’avons pas eu le temps de vérifier ce point » vaut mieux qu’un artefact manquant.

---

6. Les 4 axes de recherche

Un axe par personne. Les questions directrices sont celles auxquelles votre dossier doit répondre — le commanditaire les posera au débrief.

Axe A — Découpage et cloisonnement

1. Qu’est-ce qu’une zone de sécurité ? Sur quel critère regroupe-t-on des machines dans une même zone — même service, même niveau de sensibilité, même exposition ?
2. Dans le périmètre du §4, combien de zones proposez-vous, et quel est le critère de chacune ?
3. Le frontal web est le plus exposé. Sa base de données est la plus précieuse. Peuvent-ils vivre dans la même zone ? Justifiez.
4. Comment obtient-on une séparation réelle entre des zones réparties sur plusieurs postes, à travers le switch managé, sachant que VirtualBox strippe les tags 802.1Q (§3) ? Où placez-vous les ports access (côté membres) et le port trunk (vers le pare-feu), et pourquoi cette répartition garantit-elle que le trafic inter-zone traverse le pare-feu ? Attention aux câblages « à plat » où toutes les machines se voient sur un même VLAN : une segmentation que le pare-feu ne voit pas passer n’en est pas une.
5. Quelle politique par défaut entre zones — tout autorisé sauf ou tout interdit sauf ? Que coûte chacune à l’exploitation ?
6. Où placez-vous le plan d’administration ? Doit-il être joignable depuis le frontal web ? Et vous, depuis votre poste, par où entrez-vous ?

Sources utiles : ANSSI — Recommandations relatives à l’interconnexion d’un SI à Internet et Recommandations pour la mise en place de cloisonnement système ; ANSSI — Guide d’hygiène informatique ; NIST SP 800-207 (Zero Trust, pour le vocabulaire) ; IEC 62443 pour les zones et conduits en environnement industriel/OT.

Axe B — Services et identité sur une base qui vit seule

1. Pour chaque besoin du §4.1 : au moins deux candidats open source, leurs licences, leur poids en ressources.
2. Local ou partagé ? Tout vit sur la base — mais pour chaque service, arbitrez ce que la base voisine a le droit d’en consommer : rien, un accès nominatif à travers le tunnel, une copie. Quel est votre critère ?
3. Que devient chaque service quand le lien tombe 3 jours ? Répondez service par service — c’est la question qui départage les architectures.
4. Le cas le plus dur : l’authentification à travers le tunnel. Un agent de la base voisine consulte votre Nextcloud : avec quel compte — un compte de votre annuaire, un compte du sien, un compte invité ? Que coûte chaque option en sécurité et en exploitation ? (Vous vivrez cette question pour de vrai quand les deux bases seront raccordées — autant l’avoir déjà pensée.)
5. Une CA interne délivre les certificats des services de la base. Dans quelle zone la placer, elle qui fait confiance à tout le monde — et qui a le droit de lui parler ?

Axe C — Interconnexion base ↔ base voisine

1. Quelles technologies de tunnel open source existent — au moins deux candidats (IPsec, WireGuard, OpenVPN…) ? Comparez-les sur ce qui compte ici : reprise automatique après coupure, empreinte en ressources, simplicité de configuration à distance, et facilité à négocier à deux (deux équipes, deux pare-feu, une configuration en miroir).
2. Où le tunnel se termine-t-il côté base — sur le pare-feu, ou sur une machine dédiée dans une zone ? Qu’est-ce que chaque choix implique pour votre matrice de flux ?
3. Qu’est-ce qui a le droit de traverser le tunnel ? Un tunnel n’est pas un câble magique : listez les flux nominatifs (un document partagé, une remontée de journaux croisée…) — et rien d’autre. Que devient votre segmentation si « tout passe » ? Et que devient-elle si le voisin est compromis ?
4. Comment les deux extrémités s’authentifient-elles — clé partagée ou certificats ? Et la question d’amorçage : comment authentifie-t-on le lien si chaque CA est de son côté du lien ? Que se passe-t-il si un certificat expire pendant l’hiver austral ?
5. Que fait le tunnel pendant et après la coupure ? Remonte-t-il tout seul ? Qu’est-ce qui se resynchronise à la reconnexion, et dans quel ordre ?
6. L’adressage des deux sites : quelle condition pour que l’interconnexion soit seulement possible — sachant que vous ne connaissez pas encore le plan du voisin ? (C’est une exigence directe pour votre artefact 4.)

Sources utiles : ANSSI — Recommandations relatives à l’interconnexion d’un SI à Internet et Recommandations de sécurité relatives à IPsec ; le whitepaper WireGuard ; la documentation OpenVPN sur les modes d’authentification.

Et demain : le siège, et les autres archipels

Votre base et sa voisine ne sont pas seules : Crozet, Kerguelen, la Terre Adélie, et un jour le siège à La Réunion avec un annuaire central. Ne le concevez pas aujourd’hui — mais ne l’interdisez pas par construction : un plan d’adressage qui se chevaucherait entre archipels, ou un tunnel « tout passe », fermeraient cette porte.

Axe D — Résilience, sauvegardes et mode dégradé

1. Énoncez la règle 3-2-1 de sauvegarde. Comment l’appliquer quand le second site est à des centaines de kilomètres derrière un lien lent ? (La base voisine est un candidat évident pour la copie hors site — à quel prix, pour quelles données, et avec quelle confiance ?)
2. Quelles données sont irremplaçables (mesures scientifiques non reproductibles) et lesquelles sont reconstructibles ? Traite-t-on les deux pareil ?
3. Une sauvegarde non testée n’existe pas : comment la vérifiez-vous depuis une base isolée ?
4. Mode dégradé : listez ce qui doit continuer à fonctionner sans le voisin ni le siège, et ce qu’on accepte de perdre. C’est un arbitrage, écrivez-le.
5. Quelles pannes pouvez-vous encaisser sans intervention physique ? Que faites-vous des autres — et qu’est-ce que ça implique pour la façon dont la configuration est conservée ?

---

7. Les 4 artefacts à produire

Ce sont vos livrables. Ils seront repris dans la suite du module : votre matrice de flux d’étude, en particulier, deviendra le brouillon de la matrice d’ACLs que vous implémenterez sur le pare-feu.

Une esquisse défendable, pas un livrable fini

Un bureau d’études sous contrainte ne produit pas un document d’architecture d’entreprise — et ce n’est pas demandé. Ce qu’on attend, c’est une esquisse que vous pouvez défendre en quelques pages : incomplète est acceptable, injustifiée ne l’est pas. Les artefacts seront confrontés à l’architecture de référence au débrief, puis affinés au fil de la construction. Ne polissez pas — tranchez.

Artefact 1 — Découpage en zones (schéma + justification)

Un schéma de votre architecture : les zones, ce qu’il y a dedans, ce qui les sépare, et la place réservée au raccordement vers la base voisine. Chaque zone est accompagnée d’une phrase de justification — pourquoi elle existe séparément. Et nommez proprement : une zone est un réseau, un hôte est une machine — les deux ne portent pas le même nom.

Fait à la main, sous draw.io ou en Mermaid, peu importe. Il doit être lisible en 30 secondes.

Artefact 2 — Matrice de flux

Le cœur de votre étude. Tout flux non listé est interdit.

#	Source	Destination	Protocole / Port	Sens	Justification métier
1	ex. : zone frontale	zone données	TCP/5432 (PostgreSQL)	→	L’application lit son contenu en base ; aucun autre port n’est nécessaire.
2
3

Le test de la ligne

Si vous ne savez pas écrire la justification métier d’une ligne, c’est que ce flux n’a probablement pas lieu d’être. Supprimez-la. Et méfiez-vous des ports : deux services différents peuvent écouter sur le même numéro dans deux zones différentes — un flux se définit par source, destination et port, jamais par le port seul.

Artefact 3 — Tableau d’arbitrage technologique

Besoin	Candidats étudiés	Retenu	Licence	Pourquoi celui-ci, ici
ex. : reverse-proxy	A / B / C	B	libre	Configuration minimale, TLS automatique via la CA interne ; ressources compatibles avec le poste.

Une ligne par besoin du §4. La colonne « pourquoi » doit citer au moins une contrainte du §2 — c’est elle qui est notée, pas le nom du produit.

Artefact 4 — Plan d’adressage, de VLAN et de répartition

Proposez un plan qui :

• attribue un sous-réseau propre à chaque zone de votre architecture ;
• attribue un numéro de VLAN à chaque zone (votre choix : distincts, dans 2–4094, en évitant le VLAN 1) — ce numéro devra être identique côté switch (port access) et côté OPNsense (sous-interface du trunk) ;
• reste lisible : en regardant une adresse, on doit pouvoir dire de quelle zone elle vient, et où est la passerelle ;
• distingue le plan d’administration du SI segmenté ;
• reste disjoint de l’adressage de la base voisine — deux réseaux qui se chevauchent ne s’interconnectent pas, et vous ne connaissez pas encore son plan : trouvez la convention qui rend la collision impossible ;
• répartit les briques sur les 4 membres : qui tient le pare-feu (le poste au trunk), quelle zone est hébergée par qui (les postes en access) — chaque membre porte une part cohérente.

Expliquez la logique de votre plan en deux phrases. C’est elle qui compte. Et gardez un soupçon : l’hyperviseur vous imposera peut-être des contraintes d’adressage que vous n’avez pas choisies (le plan d’administration en host-only, par exemple) — vous le découvrirez au montage, et c’est une leçon en soi.

---

8. Le rapport : chapitre TP0

Votre rendu est le chapitre TP0 de votre rapport de réalisation, pas un exposé oral, pas un document d’architecture de quarante pages. Il suit le plan commun à tous les chapitres ; pour le TP0, la partie « preuves » est constituée de vos 4 artefacts.

Ce que le chapitre doit contenir :

1. Le problème tel que vous l’avez compris : les contraintes du §2, en une demi-page d’ouverture. Si vous ratez celles-ci, le reste ne tient pas.
2. Vos 4 artefacts : chacun sur sa page :
   • Artefact 1, le schéma des zones ;
   • Artefact 2, la matrice de flux ;
   • Artefact 3, le tableau d’arbitrage technologique ;
   • Artefact 4, le plan d’adressage, de VLAN et de répartition sur les 4 membres.
3. Vos arbitrages : les 2-3 choix dont vous êtes le plus sûrs, et le choix dont vous êtes le moins sûr : annoncez-le vous-même.
4. Les dix questions (§9), numérotées Q1 à Q10.
5. Ce que vous n’avez pas eu le temps de traiter : assumé, listé.

Ce qui compte n’est pas d’avoir raison, ni de coller à une architecture de référence : c’est que chaque choix montre sur quoi il repose, et que vous reconnaissiez la limite quand elle est réelle. Deux groupes peuvent rendre deux découpages différents et convaincre tous les deux.

---

9. Les dix questions

De la plus facile à la plus difficile. Chaque réponse s’appuie sur vos artefacts, une réponse qui pourrait être celle de n’importe quel groupe n’est pas une réponse. Barème et niveaux : voir le rapport.

● Facile : relever, nommer, constater

1. Q1 : Combien de zones compte votre artefact 1 ? Pour chacune, donnez en une ligne le critère qui justifie qu’elle existe séparément.
2. Q2 : Relevez dans votre artefact 4 le sous-réseau, le numéro de VLAN et le membre du groupe qui héberge votre zone la plus exposée.
3. Q3 : Citez la ligne de votre matrice de flux qui relie le frontal web à sa base de données (source, destination, port) et nommez la contrainte du §2 que sa justification respecte.

●● Moyen : expliquer, justifier, relier

4. Q4 : Pourquoi le frontal web et sa base de données ne vivent-ils pas dans la même zone ? Répondez avec le scénario d’attaque précis que cette séparation bloque.
5. Q5 : À partir de votre répartition access/trunk (artefact 4), expliquez pourquoi un paquet parti de votre zone front vers votre zone services traverse obligatoirement OPNsense, et ce qui se passerait si deux membres étaient sur le même VLAN.
6. Q6 : Votre annuaire vit sur la base. Listez les ports qu’il exigera dans votre matrice, dites lesquels vous refusez au frontal web, et pourquoi.
7. Q7 : Prenez une ligne de votre tableau d’arbitrage : expliquez le choix retenu avec au moins une contrainte du §2 et un budget de ressources chiffré (RAM, disque) sur le poste qui l’héberge.

●●● Difficile : arbitrer, prouver, généraliser

8. Q8 : Le lien vers la base voisine tombe trois jours. Service par service (identité, fichiers, données, journaux) : qu’est-ce qui continue, qu’est-ce qui s’arrête, qu’est-ce qui se resynchronise au retour, et dans quel ordre ? Répondez avec vos choix de l’artefact 3.
9. Q9 : Vous ne connaissez pas le plan d’adressage du groupe voisin. Montrez, avec vos préfixes, quelle convention rend une collision impossible, puis décrivez ce qui se passerait concrètement pour un paquet si les deux plans se chevauchaient.
10. Q10 : La machine qui reçoit vos journaux est compromise. En vous appuyant ligne par ligne sur votre matrice de flux, dites jusqu’où l’attaquant peut aller dans votre architecture. Si la réponse n’est pas « nulle part », dites ce que vous changez, et ce que ce changement coûte.