> ## Documentation Index
> Fetch the complete documentation index at: https://docs.devin.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Prise en charge de Windows

> Exécutez Devin sous Windows avec des blueprints et des sessions.

Devin prend en charge Windows comme plateforme pour les builds et les sessions. Les environnements Windows utilisent le même shell bash (Git Bash) que Linux ; la plupart des commandes de blueprint fonctionnent donc sur les deux plateformes sans modification.

<Warning>
  La prise en charge de Windows est actuellement disponible de façon limitée. Si vous souhaitez essayer Windows avec Devin, veuillez [nous contacter](https://cognition.com/contact) pour en savoir plus et obtenir un accès.
</Warning>

<div id="how-it-works">
  ## Fonctionnement
</div>

La prise en charge de Windows repose sur le même système de [configuration déclarative](/fr/onboard-devin/environment/blueprints) que Linux. La principale différence réside dans le champ `runs-on` de votre blueprint, qui indique à Devin sur quelle plateforme effectuer le build et l'exécution.

Comme les deux plateformes utilisent bash, vous pouvez écrire les mêmes commandes shell sur Linux et sur Windows. Les principales différences concernent l'organisation du système de fichiers et les gestionnaires de paquets disponibles :

| Aspect                  | Linux (par défaut)    | Windows                                    |
| ----------------------- | --------------------- | ------------------------------------------ |
| Répertoire personnel    | `/home/ubuntu`        | `/c/Users/Administrator`                   |
| Répertoire du repo      | `~/repos/<repo-name>` | `/c/Users/Administrator/repos/<repo-name>` |
| Gestionnaire de paquets | `apt-get`             | `choco` ou des installateurs directs       |

<div id="writing-windows-blueprints">
  ## Créer des blueprints Windows
</div>

<div id="single-platform-blueprint">
  ### Blueprint pour une seule plateforme
</div>

Si votre dépôt cible uniquement Windows, utilisez `runs-on: windows` au niveau racine :

```yaml theme={null}
runs-on: windows

initialize:
  - name: "Install Node.js"
    uses: github.com/actions/setup-node@v4
    with:
      node-version: "20"

  - name: "Install build tools"
    run: |
      choco install visualstudio2022buildtools -y
      choco install python --version=3.12 -y

maintenance: |
  npm install

knowledge:
  - name: lint
    contents: npm run lint
  - name: test
    contents: npm test
  - name: build
    contents: npm run build
```

<div id="multi-platform-blueprint">
  ### Blueprint multiplateforme
</div>

Pour effectuer le build du même dépôt pour Linux et Windows, définissez chaque plateforme dans un document YAML distinct, séparé par `---`. Chaque document déclare son propre label `runs-on`. Consultez l’encadré [YAML multi-document](/fr/onboard-devin/environment/blueprints#blueprint-sections) dans le guide des blueprint pour en savoir plus sur ce format.

```yaml theme={null}
runs-on: default
initialize: |
  curl -LsSf https://astral.sh/uv/install.sh | sh
  apt-get update && apt-get install -y build-essential

maintenance: |
  uv sync

knowledge:
  - name: test
    contents: uv run pytest

---
runs-on: windows
initialize: |
  choco install python --version=3.12 -y

maintenance: |
  uv sync

knowledge:
  - name: test
    contents: uv run pytest
```

Chaque document génère un build du snapshot distinct pour sa plateforme. Les sessions démarrent à partir du snapshot propre à la plateforme.

<Warning>
  Le YAML racine doit être un mapping, pas une séquence. Si vous écrivez l’exemple ci-dessus comme une seule liste (`- runs-on: default` / `- runs-on: windows`), le backend le rejettera avec `Invalid YAML: each YAML document must be a mapping, not a sequence; use '---' to separate multiple blocks`. Utilisez le séparateur `---` indiqué ci-dessus.
</Warning>

<div id="the-runs-on-field">
  ## Le champ `runs-on`
</div>

Le champ `runs-on` correspond à une configuration de machine enregistrée sur votre compte :

| Valeur               | Plateforme                    |
| -------------------- | ----------------------------- |
| `default` ou `linux` | Linux (plateforme par défaut) |
| `windows`            | Windows                       |

Vous pouvez spécifier `runs-on` sous forme de chaîne ou de liste :

```yaml theme={null}
# Plateforme unique
runs-on: windows

# Plusieurs plateformes dans un même bloc (les mêmes commandes s'exécutent sur chacune)
runs-on: [default, windows]
```

Lorsqu’un bloc énumère plusieurs plateformes, le système de build crée un snapshot par plateforme en exécutant les mêmes commandes.

<Warning>
  Avec la syntaxe de liste, les mêmes commandes sont exécutées sur chaque plateforme de la liste. Utilisez-la uniquement lorsque les commandes sont réellement multiplateformes (p. ex., `npm install`, `uv sync`). Pour les commandes spécifiques à une plateforme (comme `apt-get` sur Linux ou `choco` sur Windows), utilisez plutôt le [format multi-document](#multi-platform-blueprint) — un document par plateforme, séparé par `---`.
</Warning>

<div id="usage-and-cost">
  ## Utilisation et coût
</div>

Les sessions Windows consomment environ **9 %** d’ACU (ou de quota) de plus que des sessions Linux équivalentes. Pour plus de détails sur la façon dont l’utilisation est mesurée, consultez [Utilisation](/fr/admin/billing/usage#windows-sessions).

<div id="windows-session-behavior">
  ## Comportement des sessions sous Windows
</div>

<div id="shell">
  ### Shell
</div>

Les sessions Windows utilisent **Git Bash** comme shell par défaut — le même shell Bash que sous Linux. La syntaxe Bash standard fonctionne sur les deux plateformes :

```yaml theme={null}
- run: |
    export MY_VAR="hello"
    echo $MY_VAR
```

<div id="paths">
  ### Chemins
</div>

Sous Windows, les chemins utilisent le format Git Bash (`/c/...` au lieu de `C:\...`) :

```yaml theme={null}
# Chemins Linux
- run: cp config.json ~/.config/myapp/config.json

# Chemins Windows (format Git Bash)
- run: cp config.json /c/Users/Administrator/.config/myapp/config.json
```

<div id="secrets">
  ### Secrets
</div>

Les secrets sont disponibles sous forme de variables d’environnement durant les sessions, via la syntaxe bash standard (`$SECRET_NAME`) :

```yaml theme={null}
maintenance:
  - name: "Configure registry"
    run: |
      npm config set //registry.npmjs.org/:_authToken $NPM_TOKEN
```

<div id="file-attachments">
  ### Fichiers joints
</div>

Sous Windows, les fichiers importés sont enregistrés dans `/c/Users/Administrator/.files/` au lieu de `/home/ubuntu/.files/`.

<div id="computer-use">
  ### Computer Use
</div>

[Computer Use](/fr/work-with-devin/computer-use) est entièrement pris en charge dans les sessions Windows. Devin dispose d’un environnement de bureau Windows avec accès à Chrome, à la souris et au clavier, ce qui lui permet de tester des applications web ainsi que des applications de bureau Windows natives (p. ex. des applications WPF et WinForms) et d’enregistrer ses sessions de test.

<div id="blueprint-tips-for-windows">
  ## Conseils pour Blueprint sous Windows
</div>

<div id="installing-tools">
  ### Installation des outils
</div>

Utilisez `choco` (Chocolatey) ou des scripts de téléchargement directs :

```yaml theme={null}
initialize:
  - name: "Install Chocolatey packages"
    run: |
      choco install git -y
      choco install nodejs-lts -y
      choco install python --version=3.12 -y
      choco install dotnet-sdk -y
```

<div id="common-patterns">
  ### Schémas courants
</div>

**Projet .NET :**

```yaml theme={null}
runs-on: windows

initialize:
  - name: "Install .NET SDK"
    run: |
      choco install dotnet-sdk -y

maintenance: |
  dotnet restore

knowledge:
  - name: build
    contents: dotnet build
  - name: test
    contents: dotnet test
  - name: lint
    contents: dotnet format --verify-no-changes
```

**Projet Visual Studio / C++ :**

```yaml theme={null}
runs-on: windows

initialize:
  - name: "Install Visual Studio Build Tools"
    run: |
      choco install visualstudio2022buildtools -y
      choco install visualstudio2022-workload-vctools -y

maintenance: |
  msbuild /t:Restore MySolution.sln

knowledge:
  - name: build
    contents: msbuild MySolution.sln /p:Configuration=Release
  - name: test
    contents: vstest.console.exe bin/Release/Tests.dll
```
