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

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

---

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 présenterez vos slides de restitution — quatre artefacts, décrits au §7. 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 la métropole : c’est là que vivent les services centraux — l’annuaire en tête — et c’est de là que part l’administration. Les bases australes — Terre Adélie, Îles Éparses, Amsterdam, Crozet, Kerguelen — sont des satellites qui doivent continuer à travailler quand le lien coupe.

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 présentez vos slides au commanditaire (l’instructeur). Il les regardera 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. Préparez donc vos slides en anticipant la contestation — c’est ce qu’on attendra de vous en clientèle.

L’étude est collective, la construction sera individuelle

Vous menez l’étude et la restitution en groupe — c’est le format d’un bureau d’études. Mais dans la suite du module, chacun construit sa base sur son propre poste, en autonomie. 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 la métropole 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 la métropole, 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é — la 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 DIST["🇷🇪 Site distant — PC de l'instructeur"]
    C1[La Réunion, métropole<br/>annuaire · Nextcloud · stockage S3]
  end
  POSTE <-->|raccordement conçu à l'étude<br/>tunnel chiffré · peut tomber| DIST
  classDef base fill:#dcfce7,stroke:#15803d
  classDef reu fill:#dbeafe,stroke:#1d4ed8
  class POSTE base
  class DIST reu

Machine	Rôle joué	Ce qui y tournera
Vos 4 postes (un par membre)	Votre base australe, répartie	Le SI local : le pare-feu chez l’un, chaque zone chez un membre — en VMs VirtualBox, reliées par le switch managé
Le site distant (un PC tenu par l’instructeur)	La Réunion, la métropole	Les services centraux : l’annuaire (IAM), un Nextcloud mutualisé, un stockage objet S3. Vous ne les montez pas : vous vous y raccorderez dans la suite du module

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 ↔ métropole se fera par tunnel chiffré — c’est l’objet de l’axe C : concevez-le sur le papier aujourd’hui, vous le monterez plus tard dans le module.

---

4. Le périmètre fonctionnel à couvrir

Le commanditaire attend que votre architecture rende ces services. À vous de dire avec quoi, où (base ou métropole) et pourquoi là.

Un point de départ est déjà fixé : la métropole héberge les services centraux — l’annuaire (IAM), un Nextcloud mutualisé, un stockage objet S3. La vraie question, pour chaque besoin ci-dessous, devient donc : que doit-il rester à la base pour qu’on continue à travailler quand le lien tombe ?

4.1 Services de la base

Besoin	Question que vous devez trancher
Identités / authentification	L’annuaire central est en métropole, derrière le lien. Que se passe-t-il pour l’authentification quand le lien tombe ? Comptes locaux, réplique, cache — quel arbitrage, et à quel prix ?
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 objet — qui y accède, depuis où ? Et que remonte-t-on vers le S3 de la métropole, sachant le lien qu’on a ?
Partage de fichiers	Le Nextcloud est mutualisé en métropole. Que se passe-t-il pour les agents pendant trois jours de coupure — cache local, réplique, ou rien ?
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 Le raccordement à la métropole (#INFRA)

La base ne vit pas seule : l’annuaire est central, l’administration part de La Réunion, et les données finissent par remonter. Tout cela passe par un seul lien satellite — lent, cher, et qui tombe. 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.
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), montés dans vos slides. C’est là que le groupe tranche pour de bon.
Restitution	Vous présentez vos slides au commanditaire — les 4 artefacts et vos arbitrages (§8).

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 (ou par binôme). Les questions directrices sont celles auxquelles vos slides doivent répondre — le commanditaire les posera en séance.

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é derrière un lien qui tombe

1. Pour chaque besoin du §4.1 : au moins deux candidats open source, leurs licences, leur poids en ressources.
2. Central ou local ? La métropole héberge déjà l’annuaire, le Nextcloud et le S3. Pour chaque service, arbitrez : consommé à distance, répliqué sur la base, ou purement local. 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. Si l’annuaire est central et le lien coupé, qui peut encore se connecter à quoi ? Quelles parades existent, et que coûtent-elles ? (Vous vivrez cette question pour de vrai quand la base sera raccordée — 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 ↔ métropole

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.
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 (annuaire, administration, remontée de données…) — et rien d’autre. Que devient votre segmentation si « tout passe » ?
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 vers la métropole si la CA est du mauvais 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 ? (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 : les autres archipels

Votre base n’est pas la seule : Crozet, Kerguelen, Amsterdam, les Éparses, la Terre Adélie existent aussi. Un jour, deux bases devront peut-être se parler sans transiter par la métropole. Ne le concevez pas aujourd’hui — mais ne l’interdisez pas par construction : un plan d’adressage qui se chevaucherait entre archipels, par exemple, fermerait 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 milliers de kilomètres derrière un lien lent ? (Le S3 de la métropole est un candidat évident — à quel prix, et pour quelles données ?)
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 métropole, 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 slides : 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 métropole. 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 du site distant — deux réseaux qui se chevauchent ne s’interconnectent pas ;
• 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. Livrable — vos slides de restitution

Votre rendu n’est pas un rapport : c’est un jeu de slides que vous me présentez (je suis le commanditaire). Il porte vos 4 artefacts (§7) et rien de superflu — je dois suivre votre raisonnement en séance, pas lire quarante pages.

Ce que vos slides doivent contenir :

1. Le problème tel que vous l’avez compris — les contraintes du §2, en une slide d’ouverture. Si vous ratez celles-ci, le reste ne tient pas.
2. Vos 4 artefacts — une slide (ou deux) chacun :
   • 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. Le mode dégradé — ce que fait votre base pendant les 3 jours de cyclone, authentification comprise.
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 présenter deux découpages différents et convaincre tous les deux.