> 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/agent-realmjoin/realmjoin-client/native-choco-runtime.md).

# Exécution Native Choco

Le Native Choco Runtime est le moteur d’installation de packages en processus de RealmJoin, qui remplace l’ancien binaire Chocolatey 0.10.3 tout en restant entièrement compatible avec les packages existants.

{% hint style="info" %}
Le runtime Choco natif a été introduit avec **RealmJoin Agent 4.21.6 (Bêta)**. La fonctionnalité est **facultative**: les clients existants continuent d’utiliser le moteur Chocolatey classique jusqu’à ce que vous activiez explicitement le runtime natif.
{% endhint %}

## Ce que c’est

Lorsque l’agent RealmJoin installe des packages logiciels en dehors d’Intune (voir [installation des packages](/fr/agent-realmjoin/realmjoin-client/deploy-apps.md#package-installation)), il s’est traditionnellement appuyé sur [Chocolatey](https://chocolatey.org/) comme moteur de packages sous-jacent. RealmJoin fournissait une version verrouillée et fortement patchée du CLI Chocolatey open source — version **0.10.3** — fournie sous la forme de `choco.exe` sous `C:\ProgramData\chocolatey\`.

Le **Native Choco Runtime** remplace cet exécutable Chocolatey fourni avec celui de RealmJoin, **sa propre implémentation conçue à cet effet** qui s’exécute **dans le processus** à l’intérieur du service RealmJoin. Il *émule* Chocolatey : il comprend le même format de package (`.nupkg`) et se comporte de la même manière du point de vue de l’auteur du package et de l’administrateur, mais il ne dépend plus de l’ancienne base de code Chocolatey 0.10.3.

Autrement dit, les packages que vous utilisez déjà continuent de fonctionner inchangés — seul le moteur sous-jacent change.

## Fonctionnement

* **Moteur en processus.** Les installations de packages s’exécutent dans le service RealmJoin au lieu d’appeler un binaire externe `choco.exe`. Le `chocolateyInstall.ps1` de chaque package est exécuté dans un espace d’exécution PowerShell en processus.
* **Stockage isolé.** Le runtime natif s’installe dans son **propre** racine, `C:\ProgramData\RealmJoin\choco\` (avec `lib\`, `extensions\`, et `logs\` sous-dossiers). Il n’écrit jamais dans l’état de Chocolatey classique sous `C:\ProgramData\chocolatey\` et ne modifie jamais, à l’échelle de la machine, `ChocolateyInstall` variable d’environnement. Cela signifie que le runtime natif et un Chocolatey classique préexistant peuvent **coexister** sur le même appareil.
* **Résolution automatique des dépendances.** Les dépendances de package déclarées dans le `.nuspec` (comme le [RealmJoin Core Choco Extension](/fr/agent-realmjoin/recommended-packages.md#realmjoin-core-choco-extension)) sont résolues et installées automatiquement à partir des sources que vous avez configurées.
* **`choco.exe` shim.** Certains scripts de package appellent `choco.exe` directement. Pour que ceux-ci continuent de fonctionner, le runtime déploie un petit shim vers `%ProgramFiles%\RealmJoin\choco-shim\choco.exe` qui redirige de tels appels vers le moteur en processus au lieu de les envoyer à Chocolatey classique. Le shim n’est pas ajouté au `PATH`; il n’est mis à disposition des scripts de package que pendant leur exécution.

## Compatibilité

Le Native Choco Runtime est conçu comme un **remplacement prêt à l’emploi**:

* Les packages RealmJoin existants (y compris tout ce qui provient du [Package Store](/fr/gestion-des-applications/packages/package-store.md)) s’installent et se désinstallent de la même manière.
* Les arguments / paramètres de package configurés dans le portail RealmJoin continuent de fonctionner.
* Le [RealmJoin Core Choco Extension](/fr/agent-realmjoin/recommended-packages.md#realmjoin-core-choco-extension) les cmdlets d’assistance utilisées dans les scripts de package restent disponibles.
* [RealmJoin ESP](/fr/agent-realmjoin/realmjoin-client/realmjoin-esp.md) / Autopilot sont pris en charge: sur un appareil vierge avec le runtime natif activé, `winchoco` les packages sont installés nativement pendant l’inscription, avec leurs dépendances résolues automatiquement.

{% hint style="warning" %}
Comme ce runtime est en bêta, nous vous recommandons de valider vos packages les plus importants sur un anneau pilote avant de le déployer à l’échelle du tenant. Veuillez signaler toute différence de comportement au support RealmJoin afin que nous puissions y remédier avant la disponibilité générale.
{% endhint %}

## Comment l’utiliser

Le runtime est sélectionné via un RealmJoin **paramètre**, vous pouvez donc le contrôler de manière centralisée au lieu de modifier des clients individuellement. Les paramètres RealmJoin se propagent, ce qui signifie que vous pouvez définir une **valeur par défaut à l’échelle du tenant** et, si nécessaire, **la surcharger pour des groupes spécifiques** (et les objets qu’ils contiennent).

{% hint style="info" %}
Clé du paramètre : `Chocolatey.UseNativeRuntime`

Valeur du paramètre : `vrai` / `faux`
{% endhint %}

Les paramètres suivants contrôlent le comportement :

<table><thead><tr><th>Paramètre</th><th width="120">Défaut</th><th>Signification</th></tr></thead><tbody><tr><td><code>Chocolatey.Enabled</code></td><td><code>faux</code></td><td>RealmJoin gère les packages de type Chocolatey sur l’appareil.</td></tr><tr><td><code>Chocolatey.UseNativeRuntime</code></td><td><code>faux</code></td><td>Commutateur principal. Lorsque <code>faux</code>, les installations passent toujours par le moteur classique <code>choco.exe</code>. Quand <code>vrai</code>, toutes les <code>winchoco</code> installations passent par le runtime natif en processus.</td></tr><tr><td><code>Chocolatey.DisableShim</code></td><td><code>faux</code></td><td>Uniquement pertinent lorsque <code>UseNativeRuntime = true</code>. Quand <code>vrai</code>, tout script de package qui appelle un <code>choco.exe</code> échoue de manière explicite au lieu d’être redirigé via le shim — utile pour mettre en évidence les scripts qui font encore appel à un binaire externe.</td></tr></tbody></table>

{% stepper %}
{% step %}

### Activez-le d’abord pour un groupe pilote

Ouvrez les paramètres d’un RealmJoin **groupe** qui contient un petit ensemble d’appareils pilotes et définissez `Chocolatey.UseNativeRuntime` à `vrai` ici. Comme les paramètres de groupe priment sur la valeur par défaut à l’échelle du tenant, seuls ces appareils passent au nouveau moteur.
{% endstep %}

{% step %}

### Validez vos packages

Laissez les appareils pilotes exécuter leurs affectations et mises à niveau de packages habituelles. Vérifiez que les installations réussissent et consultez les journaux si quelque chose semble anormal (voir [Problèmes d’installation des packages](/fr/depannage-et-faq/troubleshooting/package-installation-issues.md)).
{% endstep %}

{% step %}

### Déployez-le à l’échelle du tenant

Une fois que vous êtes sûr, définissez `Chocolatey.UseNativeRuntime` à `vrai` car le **valeur par défaut à l’échelle du tenant** afin que tous les clients l’utilisent. Les groupes individuels peuvent toujours se désinscrire si vous devez les maintenir temporairement sur le moteur classique.
{% endstep %}
{% endstepper %}

{% hint style="info" %}
La configuration suit le même modèle de paramètre tenant / surcharge de groupe que les autres paramètres de l’agent décrits dans [Paramètres généraux](/fr/administration-et-parametres/general.md) (par exemple **Configuration du client** et **Configuration LAPS** ).
{% endhint %}

## Quelle est la valeur par défaut

Le Native Choco Runtime est **désactivé par défaut** (`Chocolatey.UseNativeRuntime = false`). Les clients continuent d’utiliser le moteur Chocolatey 0.10.3 classique fourni jusqu’à ce qu’un administrateur active le runtime natif — à l’échelle du tenant ou pour un groupe spécifique. Cela vous permet d’adopter le nouveau runtime à votre propre rythme et de le revenir en arrière tout aussi facilement tant que la fonctionnalité est en bêta.

## Migration des appareils existants

Le runtime natif et Chocolatey classique **coexister** sur un appareil aussi longtemps que nécessaire. Lorsque vous activez le runtime natif sur un appareil qui possède déjà des packages installés avec Chocolatey classique :

* Les packages existants gérés par RealmJoin continuent de fonctionner et ne sont pas **renverrait** réinstallés simplement parce que le runtime a changé — leur état d’installation est conservé lors du basculement, il n’y a donc pas de vague de réinstallations.
* Les nouvelles installations et mises à niveau passent par le runtime natif ; l’installation classique reste sur le disque, intacte, jusqu’à ce qu’elle soit explicitement supprimée.

{% hint style="info" %}
La suppression à l’échelle du parc de Chocolatey classique est prévue comme une étape distincte et coordonnée. D’ici là, le runtime natif peut coexister sans problème avec une installation classique résiduelle, il n’y a donc pas d’échéance stricte pour la nettoyer.
{% endhint %}

Pour un appareil individuel (par exemple lors du support ou du contrôle qualité), un administrateur peut faire quitter Chocolatey classique à une machine avec le verbe du shim depuis un `migrer` verbe depuis un **élevé** terminal :

{% code overflow="wrap" %}

```powershell
# Prévisualiser ce qui se passerait, sans effectuer de modifications
& "C:\Program Files\RealmJoin\choco-shim\choco.exe" migrate --dry-run

# Réinstaller les packages avec état via le runtime natif, puis supprimer le classique
& "C:\Program Files\RealmJoin\choco-shim\choco.exe" migrate --yes
```

{% endcode %}

{% hint style="warning" %}
`choco migrate` est un **outil d’administration pour un seul appareil** (support, dev/QA, nettoyage ponctuel). Ce n’est **renverrait** pas le mécanisme permettant de déployer le changement sur tout un parc — utilisez pour cela les paramètres tenant/groupe.
{% endhint %}

## Journaux et dépannage

Les installations du runtime natif écrivent un journal par package dans :

```
C:\ProgramData\RealmJoin\choco\logs\<package-id>\<timestamp>_<version>_<operation>.log
```

(conservé avec les 10 entrées les plus récentes par package). Cela est distinct des `C:\ProgramData\chocolatey\logs\`. Lorsque vous collectez des journaux pour une demande de support, incluez le `C:\ProgramData\RealmJoin\` dossier comme décrit dans [Problèmes d’installation des packages](/fr/depannage-et-faq/troubleshooting/package-installation-issues.md).

### Référence des fichiers et des chemins

| Chemin                                            | Objectif                                                  |
| ------------------------------------------------- | --------------------------------------------------------- |
| `C:\ProgramData\RealmJoin\choco\lib\<id>`         | Racine d’installation des packages du runtime natif.      |
| `C:\ProgramData\RealmJoin\choco\extensions\<id>`  | Modules d’assistance PowerShell importés automatiquement. |
| `C:\ProgramData\RealmJoin\choco\logs\<id>`        | Journaux par installation (10 derniers par package).      |
| `C:\Program Files\RealmJoin\choco-shim\choco.exe` | Le `choco.exe` shim.                                      |


---

# 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 by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.realmjoin.com/fr/agent-realmjoin/realmjoin-client/native-choco-runtime.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

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.
