> For the complete documentation index, see [llms.txt](https://docs.realmjoin.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.realmjoin.com/fr/deploiement/infrastructure.md).

# Considérations relatives à l'infrastructure

## Réseau

RealmJoin est un service cloud-native et est conçu pour **un accès Internet sortant direct et sans restriction**. Il s’agit de la configuration prise en charge. Si votre politique de sécurité exige un filtrage sortant, suivez les règles ci-dessous — elles contiennent tout ce qu’il faut pour configurer un pare-feu pour RealmJoin :

* **Direction**: Sortant uniquement. Toutes les connexions sont initiées par le client ; aucune règle entrante n’est requise.
* **Protocole**: HTTPS (TCP 443) exclusivement.
* **Filtrage**: Par **nom d’hôte (FQDN)** uniquement — consultez la liste des points de terminaison ci-dessous. **Le filtrage basé sur les adresses IP n’est pas pris en charge.**

### Points de terminaison de connexion RealmJoin

Le client RealmJoin nécessite HTTPS sortant (TCP 443) et doit pouvoir atteindre tous les points de terminaison suivants :

<table data-search="false"><thead><tr><th>Hôte</th><th>Objet</th></tr></thead><tbody><tr><td><code>client-api.realmjoin.com</code></td><td>API backend du client RealmJoin</td></tr><tr><td><code>client-api-staging.realmjoin.com</code></td><td>API backend du client RealmJoin (staging)</td></tr><tr><td><code>cdn.realmjoin.com</code></td><td>Diffusion du contenu des packages logiciels</td></tr><tr><td><code>nuget.realmjoin.com</code></td><td>Flux de packages RealmJoin (NuGet)</td></tr><tr><td><code>gkrealmjoin.s3.amazonaws.com</code></td><td>Téléchargement du client RealmJoin</td></tr><tr><td><code>realmjoinstaticcdn.azureedge.net</code></td><td>Notifier RealmJoin</td></tr><tr><td><code>login.microsoftonline.com</code></td><td>Authentification Microsoft Entra ID</td></tr><tr><td><code>graph.microsoft.com</code></td><td>API Microsoft Graph</td></tr><tr><td><code>enterpriseregistration.windows.net</code></td><td>inscription d’appareil Microsoft Entra</td></tr><tr><td><code>x1.c.lencr.org</code></td><td>Validation du certificat (Let's Encrypt)</td></tr></tbody></table>

{% hint style="warning" %}
Référez-vous à ces points de terminaison **par nom d’hôte (FQDN), jamais par adresse IP**. **Nous ne pouvons pas fournir d’adresses IP ni de plages d’adresses IP pour RealmJoin, et le filtrage basé sur les adresses IP n’est pas pris en charge.** Le CDN des packages (`cdn.realmjoin.com`) est distribué via Azure Front Door, qui n’a pas de plages d’adresses IP fixes — voir [Azure Front Door](#azure-front-door) ci-dessous.
{% endhint %}

### Azure Front Door

`cdn.realmjoin.com` — le point de terminaison qui diffuse tout le contenu des packages logiciels — est fourni via [Azure Front Door](https://learn.microsoft.com/en-us/azure/frontdoor/front-door-overview), la plateforme mondiale de périphérie et de CDN de Microsoft. Cela a des conséquences directes sur le filtrage réseau :

* **Il n’existe pas de plages d’adresses IP fixes.** Azure Front Door utilise un pool d’adresses IP anycast global géré par Microsoft. Microsoft peut ajouter, supprimer ou réattribuer ces adresses IP à tout moment, sans préavis. Pour cette raison, aucune liste d’adresses IP n’existe ni ne peut être fournie — une telle liste serait immédiatement obsolète.
* **Le filtrage d’autorisation basé sur les IP cessera de fonctionner sans avertissement** et n’est pas pris en charge. Il en va de même pour l’interception ou la réécriture de ces noms d’hôte au niveau DNS.
* Si votre politique exige malgré tout de restreindre le trafic sortant, **les règles basées sur le nom d’hôte (FQDN)** sont la seule approche qui fonctionne avec RealmJoin.

### Éviter les proxys

* Le déploiement initial nécessite **un accès Internet direct**.
* **Aucun proxy** est idéal ; un **proxy transparent** fonctionne bien (s’il est vraiment transparent).
* Si un proxy est inévitable, les [points de terminaison de connexion RealmJoin](#realmjoin-connection-endpoints) doivent au minimum être accessibles directement.

En outre, les services Microsoft dont dépend RealmJoin doivent être accessibles. Microsoft publie les plages d’adresses correspondantes :

* [Plages d’adresses IP Azure et étiquettes de service – Cloud public](https://www.microsoft.com/en-us/download/details.aspx?id=56519) — plages d’adresses IP de calcul (y compris les plages SQL) utilisées par les datacenters Microsoft Azure. Un nouveau fichier est publié chaque mercredi (heure du Pacifique) avec les plages d’adresses IP prévues, prenant effet le lundi suivant (heure du Pacifique). Téléchargez le nouveau fichier et appliquez les modifications nécessaires sur votre site avant lundi.
* [URL et plages d’adresses IP Office 365](https://support.office.com/en-us/article/Office-365-URLs-and-IP-address-ranges-8548a211-3fe7-47cb-abb1-355ea5aa88a2) — plages d’adresses à inclure dans vos listes d’autorisation sortantes afin que les clients puissent utiliser Office 365 avec succès.

{% hint style="info" %}
Le filtrage des adresses IP seul n’est pas une solution complète en raison des dépendances vis-à-vis de services basés sur Internet tels que les services de noms de domaine (DNS), les réseaux de diffusion de contenu (CDN), les listes de révocation de certificats et d’autres services tiers ou dynamiques. Ces dépendances incluent des dépendances envers d’autres services Microsoft tels que le réseau de diffusion de contenu Azure et se traduiront par des traces réseau ou des journaux de pare-feu indiquant des connexions vers des adresses IP appartenant à des tiers ou à Microsoft mais non répertoriées sur cette page. Ces adresses IP non répertoriées, qu’elles proviennent de services CDN et DNS détenus par des tiers ou par Microsoft, sont attribuées dynamiquement et peuvent changer à tout moment.
{% endhint %}

### BranchCache et isolation des appareils

BranchCache est une technologie de pair-à-pair intégrée à Windows qui **réduit le trafic WAN** et **accélère la diffusion du contenu** en permettant aux clients de partager entre eux le contenu téléchargé au lieu que chaque appareil récupère le même contenu depuis le cloud.

{% hint style="info" %}
Pour RealmJoin, BranchCache est **activé par défaut** côté CDN et côté client.
{% endhint %}

**Pourquoi BranchCache plutôt que Delivery Optimization ?** Delivery Optimization ne prend pas en charge les sources de packages tierces — il fonctionne uniquement avec des points de terminaison contrôlés par Microsoft (Windows Update, Store, M365 Apps, Intune). BranchCache fonctionne pour le contenu tiers tel que les packages RealmJoin.

**Configuration :**

* **Côté CDN**: Activé par défaut. Sur demande, nous pouvons désactiver complètement BranchCache côté CDN (par tenant), ce qui rend la configuration côté client sans objet.
* **Côté client**: Activé par défaut. Définissez `BranchCache.Mode = "Undefined"` (voir [Paramètres utilisateur et groupe](/fr/ugd-management/user-and-group-settings.md)) pour modifier ce paramètre par défaut. Remarque : sur les clients existants, la fonctionnalité n’est pas désactivée activement une fois qu’elle a déjà été activée — exécutez `Disable-BC` sur les appareils souhaités pour la désactiver.

**Exigences réseau :**

* Les clients doivent pouvoir **communiquer directement entre eux** — ne les séparez pas dans des VLAN ou sous-réseaux différents, et ne bloquez pas le trafic pair à pair via l’isolation des appareils.
* RealmJoin utilise **le mode cache distribué** uniquement : chaque client conserve un cache local et récupère les données mises en cache auprès de ses pairs.
* **le mode cache hébergé** (serveur Windows dédié, configuré via la stratégie « Configure Hosted Cache Servers ») n’est **pas pris en charge** par RealmJoin.

**Fonctionnement :**

1. Lorsqu’un client télécharge un package logiciel pour la première fois, les fichiers sont divisés en fragments nettement plus petits que le contenu d’origine et mis en cache sur l’appareil.
2. Lorsqu’un autre client du même réseau demande le même package, il télécharge uniquement **les informations de contenu** au lieu du contenu complet depuis le serveur.
3. Le client utilise les informations de contenu pour **la découverte des pairs**: il envoie une requête multicast (« Quelqu’un possède-t-il l’ID de contenu XYZ ? »), et tout pair détenant le segment demandé répond directement via unicast.
4. Le contenu est transféré depuis les pairs sous forme de fragments. Si le logiciel demandé est disponible sur plusieurs appareils, la charge est répartie entre eux.

Pour plus de détails, voir Microsoft Learn : [BranchCache](https://learn.microsoft.com/en-us/windows-server/networking/branchcache/branchcache)


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.realmjoin.com/fr/deploiement/infrastructure.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
