-
diff --git a/docs/i18n/fr/docusaurus-plugin-content-docs/current/usage/architecture/backend.mdx b/docs/i18n/fr/docusaurus-plugin-content-docs/current/usage/architecture/backend.mdx
deleted file mode 100644
index 704284ced1..0000000000
--- a/docs/i18n/fr/docusaurus-plugin-content-docs/current/usage/architecture/backend.mdx
+++ /dev/null
@@ -1,54 +0,0 @@
-# 🏛️ Architecture du Système
-
-Mise à jour de ce Schéma
-
- La génération du schéma d'architecture du backend est partiellement automatisée.
- Le schéma est généré à partir des annotations de type dans le code en utilisant l'outil py2puml.
- Le schéma est ensuite revu manuellement, ajusté et exporté en PNG et SVG.
-
- ## Prérequis
-
- - Un environnement Python dans lequel openhands est exécutable
- (selon les instructions du fichier README.md à la racine du dépôt)
- - [py2puml](https://github.com/lucsorel/py2puml) installé
-
-## Étapes
-
-1. Générez automatiquement le schéma en exécutant la commande suivante depuis la racine du dépôt :
- `py2puml openhands openhands > docs/architecture/backend_architecture.puml`
-
-2. Ouvrez le fichier généré dans un éditeur PlantUML, par exemple Visual Studio Code avec l'extension PlantUML ou [PlantText](https://www.planttext.com/)
-
-3. Révisez le PUML généré et apportez toutes les modifications nécessaires au schéma (ajoutez les parties manquantes, corrigez les erreurs, améliorez l'agencement).
- _py2puml crée le schéma à partir des annotations de type dans le code, donc les annotations de type manquantes ou incorrectes peuvent entraîner un schéma incomplet ou incorrect._
-
-4. Examinez la différence entre le nouveau schéma et le précédent et vérifiez manuellement si les modifications sont correctes.
- _Assurez-vous de ne pas supprimer les parties ajoutées manuellement au schéma par le passé et qui sont toujours pertinentes._
-
-5. Ajoutez le hash du commit qui a été utilisé pour générer le schéma dans le pied de page du schéma.
-
-6. Exporte le schéma sous forme de fichiers PNG et SVG et remplacez les schémas existants dans le répertoire `docs/architecture`. Cela peut être fait avec (par exemple [PlantText](https://www.planttext.com/))
-
-
-
- 
-
-
-Voici une vue d'ensemble de l'architecture du système. Le système est divisé en deux composants principaux : le frontend et le backend. Le frontend est responsable de la gestion des interactions utilisateur et de l'affichage des résultats. Le backend est responsable de la gestion de la logique métier et de l'exécution des agents.
-
-# Architecture Frontend {#frontend-architecture-en}
-
-
-
-Cette vue d'ensemble est simplifiée pour montrer les composants principaux et leurs interactions. Pour une vue plus détaillée de l'architecture backend, consultez la section Architecture Backend ci-dessous.
-
-# Architecture Backend {#backend-architecture-en}
-
-_**Avertissement** : L'architecture backend est en cours de développement et peut être modifiée. Le diagramme suivant montre l'architecture actuelle du backend basée sur le commit indiqué dans le pied de page du diagramme._
-
-
-
-Diagramme d'Architecture OpenHands (4 juillet 2024)
-
-
diff --git a/docs/i18n/fr/docusaurus-plugin-content-docs/current/usage/architecture/runtime.md b/docs/i18n/fr/docusaurus-plugin-content-docs/current/usage/architecture/runtime.md
deleted file mode 100644
index e92b98bacf..0000000000
--- a/docs/i18n/fr/docusaurus-plugin-content-docs/current/usage/architecture/runtime.md
+++ /dev/null
@@ -1,128 +0,0 @@
-# 📦 Docker Runtime
-
-Le Docker Runtime d'OpenHands est le composant central qui permet l'exécution sécurisée et flexible des actions d'un agent IA.
-Il crée un environnement isolé (sandbox) en utilisant Docker, où du code arbitraire peut être exécuté en toute sécurité sans risquer de compromettre le système hôte.
-
-## Pourquoi avons-nous besoin d'un environnement d'exécution isolé ?
-
-OpenHands doit exécuter du code arbitraire dans un environnement sécurisé et isolé pour plusieurs raisons :
-
-1. Sécurité : L'exécution de code non fiable peut présenter des risques importants pour le système hôte. Un environnement isolé empêche le code malveillant d'accéder ou de modifier les ressources du système hôte
-2. Cohérence : Un environnement isolé garantit que l'exécution du code est cohérente sur différentes machines et configurations, éliminant les problèmes du type "ça marche sur ma machine"
-3. Contrôle des ressources : L'isolation permet un meilleur contrôle de l'allocation et de l'utilisation des ressources, empêchant les processus incontrôlés d'affecter le système hôte
-4. Isolation : Différents projets ou utilisateurs peuvent travailler dans des environnements isolés sans interférer les uns avec les autres ou avec le système hôte
-5. Reproductibilité : Les environnements isolés facilitent la reproduction des bugs et des problèmes, car l'environnement d'exécution est cohérent et contrôlable
-
-## Comment fonctionne le Runtime ?
-
-Le système Runtime d'OpenHands utilise une architecture client-serveur implémentée avec des conteneurs Docker. Voici un aperçu de son fonctionnement :
-
-```mermaid
-graph TD
- A[Image Docker personnalisée fournie par l'utilisateur] --> B[Backend OpenHands]
- B -->|Construit| C[Image OH Runtime]
- C -->|Lance| D[Action Executor]
- D -->|Initialise| E[Navigateur]
- D -->|Initialise| F[Shell Bash]
- D -->|Initialise| G[Plugins]
- G -->|Initialise| L[Serveur Jupyter]
-
- B -->|Crée| H[Agent]
- B -->|Crée| I[EventStream]
- I <--->|Exécute l'action pour
- obtenir l'observation
- via API REST
- | D
-
- H -->|Génère l'action| I
- I -->|Obtient l'observation| H
-
- subgraph "Conteneur Docker"
- D
- E
- F
- G
- L
- end
-```
-
-1. Entrée utilisateur : L'utilisateur fournit une image Docker de base personnalisée
-2. Construction de l'image : OpenHands construit une nouvelle image Docker (l'"image OH runtime") basée sur l'image fournie par l'utilisateur. Cette nouvelle image inclut le code spécifique à OpenHands, principalement le "client runtime"
-3. Lancement du conteneur : Lorsqu'OpenHands démarre, il lance un conteneur Docker utilisant l'image OH runtime
-4. Initialisation du serveur d'exécution d'actions : Le serveur d'exécution d'actions initialise un `ActionExecutor` à l'intérieur du conteneur, configurant les composants nécessaires comme un shell bash et chargeant les plugins spécifiés
-5. Communication : Le backend OpenHands (`openhands/runtime/impl/eventstream/eventstream_runtime.py`) communique avec le serveur d'exécution d'actions via une API RESTful, envoyant des actions et recevant des observations
-6. Exécution d'actions : Le client runtime reçoit les actions du backend, les exécute dans l'environnement isolé, et renvoie des observations
-7. Retour d'observation : Le serveur d'exécution d'actions renvoie les résultats d'exécution au backend OpenHands sous forme d'observations
-
-Le rôle du client :
-
-- Il agit comme intermédiaire entre le backend OpenHands et l'environnement isolé
-- Il exécute divers types d'actions (commandes shell, opérations sur fichiers, code Python, etc.) en toute sécurité dans le conteneur
-- Il gère l'état de l'environnement isolé, y compris le répertoire de travail actuel et les plugins chargés
-- Il formate et renvoie les observations au backend, assurant une interface cohérente pour le traitement des résultats
-
-## Comment OpenHands construit et maintient les images OH Runtime
-
-L'approche d'OpenHands pour construire et gérer les images runtime assure efficacité, cohérence et flexibilité dans la création et la maintenance des images Docker pour les environnements de production et de développement.
-
-Consultez le [code pertinent](https://github.com/All-Hands-AI/OpenHands/blob/main/openhands/runtime/utils/runtime_build.py) si vous êtes intéressé par plus de détails.
-
-### Système de marquage d'images
-
-OpenHands utilise un système à trois tags pour ses images runtime afin d'équilibrer reproductibilité et flexibilité.
-Les tags peuvent être dans l'un des 2 formats suivants :
-
-- **Tag versionné** : `oh_v{openhands_version}_{base_image}` (ex. : `oh_v0.9.9_nikolaik_s_python-nodejs_t_python3.12-nodejs22`)
-- **Tag de verrouillage** : `oh_v{openhands_version}_{16_digit_lock_hash}` (ex. : `oh_v0.9.9_1234567890abcdef`)
-- **Tag source** : `oh_v{openhands_version}_{16_digit_lock_hash}_{16_digit_source_hash}`
- (ex. : `oh_v0.9.9_1234567890abcdef_1234567890abcdef`)
-
-#### Tag source - Le plus spécifique
-
-Il s'agit des 16 premiers chiffres du MD5 du hash du répertoire pour le répertoire source. Cela donne un hash
-uniquement pour la source openhands.
-
-#### Tag de verrouillage
-
-Ce hash est construit à partir des 16 premiers chiffres du MD5 de :
-
-- Le nom de l'image de base sur laquelle l'image a été construite (ex. : `nikolaik/python-nodejs:python3.12-nodejs22`)
-- Le contenu du `pyproject.toml` inclus dans l'image.
-- Le contenu du `poetry.lock` inclus dans l'image.
-
-Cela donne effectivement un hash pour les dépendances d'Openhands indépendamment du code source.
-
-#### Tag versionné - Le plus générique
-
-Ce tag est une concaténation de la version openhands et du nom de l'image de base (transformé pour s'adapter au standard des tags).
-
-#### Processus de construction
-
-Lors de la génération d'une image...
-
-- **Pas de reconstruction** : OpenHands vérifie d'abord si une image avec le même **tag source le plus spécifique** existe. S'il existe une telle image, aucune construction n'est effectuée - l'image existante est utilisée.
-- **Reconstruction la plus rapide** : OpenHands vérifie ensuite si une image avec le **tag de verrouillage générique** existe. S'il existe une telle image, OpenHands construit une nouvelle image basée sur celle-ci, contournant toutes les étapes d'installation (comme `poetry install` et `apt-get`) sauf une opération finale pour copier le code source actuel. La nouvelle image est marquée uniquement avec un tag **source**.
-- **Reconstruction acceptable** : Si ni un tag **source** ni un tag **verrouillage** n'existe, une image sera construite basée sur l'image avec le tag **versionné**. Dans l'image avec tag versionné, la plupart des dépendances devraient déjà être installées, ce qui permet de gagner du temps.
-- **Reconstruction la plus lente** : Si aucun des trois tags n'existe, une toute nouvelle image est construite basée sur l'image de base (ce qui est une opération plus lente). Cette nouvelle image est marquée avec tous les tags **source**, **verrouillage** et **versionné**.
-
-Cette approche de marquage permet à OpenHands de gérer efficacement les environnements de développement et de production.
-
-1. Un code source et un Dockerfile identiques produisent toujours la même image (via des tags basés sur des hashs)
-2. Le système peut rapidement reconstruire des images lorsque des changements mineurs se produisent (en exploitant des images compatibles récentes)
-3. Le tag **verrouillage** (ex., `runtime:oh_v0.9.3_1234567890abcdef`) pointe toujours vers la dernière construction pour une combinaison particulière d'image de base, de dépendances et de version OpenHands
-
-## Système de plugins Runtime
-
-Le Runtime OpenHands prend en charge un système de plugins qui permet d'étendre les fonctionnalités et de personnaliser l'environnement d'exécution. Les plugins sont initialisés au démarrage du client runtime.
-
-Consultez [un exemple de plugin Jupyter ici](https://github.com/All-Hands-AI/OpenHands/blob/ecf4aed28b0cf7c18d4d8ff554883ba182fc6bdd/openhands/runtime/plugins/jupyter/__init__.py#L21-L55) si vous souhaitez implémenter votre propre plugin.
-
-*Plus de détails sur le système de plugins sont encore en construction - les contributions sont les bienvenues !*
-
-Aspects clés du système de plugins :
-
-1. Définition du plugin : Les plugins sont définis comme des classes Python qui héritent d'une classe de base `Plugin`
-2. Enregistrement du plugin : Les plugins disponibles sont enregistrés dans un dictionnaire `ALL_PLUGINS`
-3. Spécification du plugin : Les plugins sont associés à `Agent.sandbox_plugins: list[PluginRequirement]`. Les utilisateurs peuvent spécifier quels plugins charger lors de l'initialisation du runtime
-4. Initialisation : Les plugins sont initialisés de manière asynchrone au démarrage du client runtime
-5. Utilisation : Le client runtime peut utiliser les plugins initialisés pour étendre ses capacités (par exemple, le JupyterPlugin pour exécuter des cellules IPython)
diff --git a/docs/i18n/fr/docusaurus-plugin-content-docs/current/usage/cloud/cloud-api.md b/docs/i18n/fr/docusaurus-plugin-content-docs/current/usage/cloud/cloud-api.md
deleted file mode 100644
index 7c5126eb3a..0000000000
--- a/docs/i18n/fr/docusaurus-plugin-content-docs/current/usage/cloud/cloud-api.md
+++ /dev/null
@@ -1,177 +0,0 @@
-# API Cloud OpenHands
-
-OpenHands Cloud fournit une API REST qui vous permet d'interagir programmatiquement avec le service. Cela est utile si vous souhaitez facilement lancer vos propres tâches depuis vos programmes de manière flexible.
-
-Ce guide explique comment obtenir une clé API et utiliser l'API pour démarrer des conversations.
-Pour des informations plus détaillées sur l'API, consultez la [Référence API OpenHands](https://docs.all-hands.dev/swagger-ui/).
-
-## Obtention d'une clé API
-
-Pour utiliser l'API OpenHands Cloud, vous devrez générer une clé API :
-
-1. Connectez-vous à votre compte [OpenHands Cloud](https://app.all-hands.dev)
-2. Accédez à la [page Paramètres](https://app.all-hands.dev/settings)
-3. Localisez la section "Clés API"
-4. Cliquez sur "Générer une nouvelle clé"
-5. Donnez à votre clé un nom descriptif (par exemple, "Développement", "Production")
-6. Copiez la clé API générée et conservez-la en lieu sûr - elle ne sera affichée qu'une seule fois
-
-
-
-## Utilisation de l'API
-
-### Démarrer une nouvelle conversation
-
-Pour démarrer une nouvelle conversation avec OpenHands effectuant une tâche, vous devrez faire une requête POST vers le point de terminaison de conversation.
-
-#### Paramètres de la requête
-
-| Paramètre | Type | Obligatoire | Description |
-|-----------|------|-------------|-------------|
-| `initial_user_msg` | chaîne | Oui | Le message initial pour démarrer la conversation |
-| `repository` | chaîne | Non | Nom du dépôt Git pour fournir du contexte au format `propriétaire/repo`. Vous devez avoir accès au dépôt. |
-
-#### Exemples
-
-Mise à jour de ce diagramme
-
- La génération du diagramme d'architecture backend est partiellement automatisée.
- Le diagramme est généré à partir des annotations de type dans le code en utilisant l'outil
- py2puml. Le diagramme est ensuite manuellement révisé, ajusté et exporté en PNG
- et SVG.
-
- ## Prérequis
-
- - Environnement Python opérationnel dans lequel openhands est exécutable
- (selon les instructions du fichier README.md à la racine du dépôt)
- - [py2puml](https://github.com/lucsorel/py2puml) installé
-
-## Étapes
-
-1. Générer automatiquement le diagramme en exécutant la commande suivante depuis la racine du dépôt :
- `py2puml openhands openhands > docs/architecture/backend_architecture.puml`
-
-2. Ouvrir le fichier généré dans un éditeur PlantUML, par exemple Visual Studio Code avec l'extension PlantUML ou [PlantText](https://www.planttext.com/)
-
-3. Examiner le PUML généré et faire tous les ajustements nécessaires au diagramme (ajouter les parties manquantes, corriger les erreurs, améliorer le positionnement).
- _py2puml crée le diagramme basé sur les annotations de type dans le code, donc des annotations manquantes ou incorrectes peuvent entraîner un diagramme incomplet ou incorrect._
-
-4. Examiner la différence entre le nouveau diagramme et le précédent et vérifier manuellement si les changements sont corrects.
- _Assurez-vous de ne pas supprimer des parties qui ont été ajoutées manuellement au diagramme dans le passé et qui sont toujours pertinentes._
-
-5. Ajouter le hash du commit qui a été utilisé pour générer le diagramme dans le pied de page du diagramme.
-
-6. Exporter le diagramme en fichiers PNG et SVG et remplacer les diagrammes existants dans le répertoire `docs/architecture`. Cela peut être fait avec (par exemple [PlantText](https://www.planttext.com/))
-
-
-
-
-
-cURL
- -```bash -curl -X POST "https://app.all-hands.dev/api/conversations" \ - -H "Authorization: Bearer YOUR_API_KEY" \ - -H "Content-Type: application/json" \ - -d '{ - "initial_user_msg": "Check whether there is any incorrect information in the README.md file and send a PR to fix it if so.", - "repository": "yourusername/your-repo" - }' -``` -
-
-
-Python (avec requests)
- -```python -import requests - -api_key = "YOUR_API_KEY" -url = "https://app.all-hands.dev/api/conversations" - -headers = { - "Authorization": f"Bearer {api_key}", - "Content-Type": "application/json" -} - -data = { - "initial_user_msg": "Check whether there is any incorrect information in the README.md file and send a PR to fix it if so.", - "repository": "yourusername/your-repo" -} - -response = requests.post(url, headers=headers, json=data) -conversation = response.json() - -print(f"Conversation Link: https://app.all-hands.dev/conversations/{conversation['conversation_id']}") -print(f"Status: {conversation['status']}") -``` -
-
-
-#### Réponse
-
-L'API renverra un objet JSON avec les détails de la conversation créée :
-
-```json
-{
- "status": "ok",
- "conversation_id": "abc1234",
-}
-```
-
-Vous pouvez également recevoir une `AuthenticationError` si :
-
-1. Vous avez fourni une clé API invalide
-2. Vous avez fourni un nom de dépôt incorrect
-3. Vous n'avez pas accès au dépôt
-
-
-### Récupération du statut d'une conversation
-
-Vous pouvez vérifier le statut d'une conversation en faisant une requête GET vers le point de terminaison de conversation.
-
-#### Point de terminaison
-
-```
-GET https://app.all-hands.dev/api/conversations/{conversation_id}
-```
-
-#### Exemple
-
-TypeScript/JavaScript (avec fetch)
- -```typescript -const apiKey = "YOUR_API_KEY"; -const url = "https://app.all-hands.dev/api/conversations"; - -const headers = { - "Authorization": `Bearer ${apiKey}`, - "Content-Type": "application/json" -}; - -const data = { - initial_user_msg: "Check whether there is any incorrect information in the README.md file and send a PR to fix it if so.", - repository: "yourusername/your-repo" -}; - -async function startConversation() { - try { - const response = await fetch(url, { - method: "POST", - headers: headers, - body: JSON.stringify(data) - }); - - const conversation = await response.json(); - - console.log(`Conversation Link: https://app.all-hands.dev/conversations/${conversation.id}`); - console.log(`Status: ${conversation.status}`); - - return conversation; - } catch (error) { - console.error("Error starting conversation:", error); - } -} - -startConversation(); -``` - -
-
-
-#### Réponse
-
-La réponse est formatée comme suit :
-
-```json
-{
- "conversation_id":"abc1234",
- "title":"Update README.md",
- "created_at":"2025-04-29T15:13:51.370706Z",
- "last_updated_at":"2025-04-29T15:13:57.199210Z",
- "status":"RUNNING",
- "selected_repository":"yourusername/your-repo",
- "trigger":"gui"
-}
-```
-
-## Limites de taux
-
-L'API a une limite de 10 conversations simultanées par compte. Si vous avez besoin d'une limite plus élevée pour votre cas d'utilisation, veuillez nous contacter à [contact@all-hands.dev](mailto:contact@all-hands.dev).
-
-Si vous dépassez cette limite, l'API renverra une réponse 429 Too Many Requests.
diff --git a/docs/i18n/fr/docusaurus-plugin-content-docs/current/usage/cloud/cloud-issue-resolver.md b/docs/i18n/fr/docusaurus-plugin-content-docs/current/usage/cloud/cloud-issue-resolver.md
deleted file mode 100644
index 9a10f097f3..0000000000
--- a/docs/i18n/fr/docusaurus-plugin-content-docs/current/usage/cloud/cloud-issue-resolver.md
+++ /dev/null
@@ -1,56 +0,0 @@
-# Résolveur de Problèmes Cloud
-
-Le Résolveur de Problèmes Cloud automatise les corrections de code et fournit une assistance intelligente pour vos dépôts sur GitHub et GitLab.
-
-## Configuration
-
-Le Résolveur de Problèmes Cloud est disponible automatiquement lorsque vous accordez l'accès au dépôt OpenHands Cloud :
-- [Accès au dépôt GitHub](./github-installation#adding-repository-access)
-- [Accès au dépôt GitLab](./gitlab-installation#adding-repository-access)
-
-
-
-## Utilisation
-
-Après avoir accordé l'accès au dépôt OpenHands Cloud, vous pouvez utiliser le Résolveur de Problèmes Cloud sur les problèmes et les pull/merge requests dans vos dépôts.
-
-### Travailler avec les Problèmes
-
-Sur votre dépôt, étiquetez un problème avec `openhands` ou ajoutez un message commençant par `@openhands`. OpenHands va :
-1. Commenter le problème pour vous faire savoir qu'il y travaille
- - Vous pouvez cliquer sur le lien pour suivre la progression sur OpenHands Cloud
-2. Ouvrir une pull request (GitHub) ou une merge request (GitLab) s'il détermine que le problème a été résolu avec succès
-3. Commenter le problème avec un résumé des tâches effectuées et un lien vers la PR/MR
-
-
-
-#### Exemples de Commandes pour les Problèmes
-
-Voici quelques exemples de commandes que vous pouvez utiliser avec le résolveur de problèmes :
-
-```
-@openhands lisez la description du problème et corrigez-le
-```
-
-### Travailler avec les Pull/Merge Requests
-
-Pour qu'OpenHands travaille sur les pull requests (GitHub) ou les merge requests (GitLab), mentionnez `@openhands` dans les commentaires pour :
-- Poser des questions
-- Demander des mises à jour
-- Obtenir des explications de code
-
-OpenHands va :
-1. Commenter pour vous faire savoir qu'il y travaille
-2. Effectuer la tâche demandée
-
-#### Exemples de Commandes pour les Pull/Merge Requests
-
-Voici quelques exemples de commandes que vous pouvez utiliser avec les pull/merge requests :
-
-```
-@openhands reflétez les commentaires de la revue
-```
-
-```
-@openhands corrigez les conflits de fusion et assurez-vous que le CI passe
-```
diff --git a/docs/i18n/fr/docusaurus-plugin-content-docs/current/usage/cloud/cloud-ui.md b/docs/i18n/fr/docusaurus-plugin-content-docs/current/usage/cloud/cloud-ui.md
deleted file mode 100644
index a54a9c1822..0000000000
--- a/docs/i18n/fr/docusaurus-plugin-content-docs/current/usage/cloud/cloud-ui.md
+++ /dev/null
@@ -1,29 +0,0 @@
-# Interface Cloud
-
-L'interface Cloud fournit une interface web pour interagir avec OpenHands AI. Cette page explique comment accéder et utiliser l'interface Cloud d'OpenHands.
-
-## Accès à l'Interface
-
-L'interface Cloud d'OpenHands est accessible à [app.all-hands.dev](https://app.all-hands.dev). Vous devrez vous connecter avec votre compte GitHub ou GitLab pour accéder à l'interface.
-
-
-
-
-## Fonctionnalités Clés
-
-Pour des informations détaillées sur les fonctionnalités disponibles dans l'interface Cloud d'OpenHands, veuillez consulter la section [Fonctionnalités Clés](../key-features.md) de la documentation.
-
-## Paramètres
-
-La page des paramètres vous permet de :
-
-1. Configurer les préférences de votre compte
-2. Gérer l'accès aux dépôts
-3. Générer des clés API pour un accès programmatique
-4. Personnaliser votre expérience OpenHands
-
-## Prochaines Étapes
-
-- [Utiliser le Résolveur de Problèmes Cloud](./cloud-issue-resolver.md) pour automatiser les corrections de code et obtenir de l'aide
-- [En savoir plus sur l'API Cloud](./cloud-api.md) pour un accès programmatique
-- [Retourner à la Mise en Route](./openhands-cloud.md)
diff --git a/docs/i18n/fr/docusaurus-plugin-content-docs/current/usage/cloud/github-installation.md b/docs/i18n/fr/docusaurus-plugin-content-docs/current/usage/cloud/github-installation.md
deleted file mode 100644
index 222102e992..0000000000
--- a/docs/i18n/fr/docusaurus-plugin-content-docs/current/usage/cloud/github-installation.md
+++ /dev/null
@@ -1,57 +0,0 @@
-# Installation GitHub
-
-Ce guide vous accompagne dans le processus d'installation et de configuration d'OpenHands Cloud pour vos dépôts GitHub.
-
-## Prérequis
-
-- Un compte GitHub
-- Accès à OpenHands Cloud
-
-## Étapes d'Installation
-
-1. Connectez-vous à [OpenHands Cloud](https://app.all-hands.dev)
-2. Si vous n'avez pas encore connecté votre compte GitHub :
- - Cliquez sur `Se connecter à GitHub`
- - Examinez et acceptez les conditions d'utilisation
- - Autorisez l'application OpenHands AI
-
-## Ajout d'Accès au Dépôt
-
-Vous pouvez accorder à OpenHands l'accès à des dépôts spécifiques :
-
-1. Cliquez sur le menu déroulant `Sélectionner un projet GitHub`, puis sélectionnez `Ajouter plus de dépôts...`
-2. Sélectionnez votre organisation et choisissez les dépôts spécifiques auxquels vous souhaitez accorder l'accès à OpenHands.
- - OpenHands demande des jetons à courte durée de vie (expiration de 8 heures) avec ces permissions :
- - Actions : Lecture et écriture
- - Administration : Lecture seule
- - Statuts de commit : Lecture et écriture
- - Contenus : Lecture et écriture
- - Problèmes : Lecture et écriture
- - Métadonnées : Lecture seule
- - Pull requests : Lecture et écriture
- - Webhooks : Lecture et écriture
- - Workflows : Lecture et écriture
- - L'accès au dépôt pour un utilisateur est accordé en fonction de :
- - Permission accordée pour le dépôt
- - Permissions GitHub de l'utilisateur (propriétaire/collaborateur)
-3. Cliquez sur `Installer & Autoriser`
-
-
-
-## Modification de l'Accès au Dépôt
-
-Vous pouvez modifier l'accès au dépôt à tout moment :
-* En utilisant le même workflow `Sélectionner un projet GitHub > Ajouter plus de dépôts`, ou
-* En visitant la page Paramètres et en sélectionnant `Configurer les Dépôts GitHub` dans la section `Paramètres GitHub`.
-
-## Utilisation d'OpenHands avec GitHub
-
-Une fois que vous avez accordé l'accès au dépôt, vous pouvez utiliser OpenHands avec vos dépôts GitHub.
-
-Pour plus de détails sur l'utilisation d'OpenHands avec les problèmes et les pull requests GitHub, consultez la documentation du [Résolveur de Problèmes Cloud](./cloud-issue-resolver.md).
-
-## Prochaines Étapes
-
-- [Accéder à l'Interface Cloud](./cloud-ui.md) pour interagir avec l'interface web
-- [Utiliser le Résolveur de Problèmes Cloud](./cloud-issue-resolver.md) pour automatiser les corrections de code et obtenir de l'aide
-- [Utiliser l'API Cloud](./cloud-api.md) pour interagir programmatiquement avec OpenHands
diff --git a/docs/i18n/fr/docusaurus-plugin-content-docs/current/usage/cloud/gitlab-installation.md b/docs/i18n/fr/docusaurus-plugin-content-docs/current/usage/cloud/gitlab-installation.md
deleted file mode 100644
index 06ce63aaa0..0000000000
--- a/docs/i18n/fr/docusaurus-plugin-content-docs/current/usage/cloud/gitlab-installation.md
+++ /dev/null
@@ -1,50 +0,0 @@
-# Installation GitLab
-
-Ce guide vous accompagne dans le processus d'installation et de configuration d'OpenHands Cloud pour vos dépôts GitLab.
-
-## Prérequis
-
-- Un compte GitLab
-- Accès à OpenHands Cloud
-
-## Étapes d'Installation
-
-1. Connectez-vous à [OpenHands Cloud](https://app.all-hands.dev)
-2. Si vous n'avez pas encore connecté votre compte GitLab :
- - Cliquez sur `Se connecter à GitLab`
- - Examinez et acceptez les conditions d'utilisation
- - Autorisez l'application OpenHands AI
-
-## Ajout d'Accès au Dépôt
-
-Vous pouvez accorder à OpenHands l'accès à des dépôts spécifiques :
-
-1. Cliquez sur le menu déroulant `Sélectionner un projet GitLab`, puis sélectionnez `Ajouter plus de dépôts...`
-2. Sélectionnez votre organisation et choisissez les dépôts spécifiques auxquels vous souhaitez accorder l'accès à OpenHands.
- - OpenHands demande des permissions avec ces portées :
- - api : Accès complet à l'API
- - read_user : Lecture des informations utilisateur
- - read_repository : Lecture des informations du dépôt
- - write_repository : Écriture dans le dépôt
- - L'accès au dépôt pour un utilisateur est accordé en fonction de :
- - Permission accordée pour le dépôt
- - Permissions GitLab de l'utilisateur (propriétaire/mainteneur/développeur)
-3. Cliquez sur `Installer & Autoriser`
-
-## Modification de l'Accès au Dépôt
-
-Vous pouvez modifier l'accès au dépôt à tout moment :
-* En utilisant le même workflow `Sélectionner un projet GitLab > Ajouter plus de dépôts`, ou
-* En visitant la page Paramètres et en sélectionnant `Configurer les Dépôts GitLab` dans la section `Paramètres GitLab`.
-
-## Utilisation d'OpenHands avec GitLab
-
-Une fois que vous avez accordé l'accès au dépôt, vous pouvez utiliser OpenHands avec vos dépôts GitLab.
-
-Pour plus de détails sur l'utilisation d'OpenHands avec les problèmes et les merge requests GitLab, consultez la documentation du [Résolveur de Problèmes Cloud](./cloud-issue-resolver.md).
-
-## Prochaines Étapes
-
-- [Accéder à l'Interface Cloud](./cloud-ui.md) pour interagir avec l'interface web
-- [Utiliser le Résolveur de Problèmes Cloud](./cloud-issue-resolver.md) pour automatiser les corrections de code et obtenir de l'aide
-- [Utiliser l'API Cloud](./cloud-api.md) pour interagir programmatiquement avec OpenHands
diff --git a/docs/i18n/fr/docusaurus-plugin-content-docs/current/usage/cloud/openhands-cloud.md b/docs/i18n/fr/docusaurus-plugin-content-docs/current/usage/cloud/openhands-cloud.md
deleted file mode 100644
index 0b3d736a8d..0000000000
--- a/docs/i18n/fr/docusaurus-plugin-content-docs/current/usage/cloud/openhands-cloud.md
+++ /dev/null
@@ -1,24 +0,0 @@
-# OpenHands Cloud
-
-OpenHands Cloud est la version hébergée dans le cloud d'OpenHands par All Hands AI.
-
-## Accès à OpenHands Cloud
-
-Pour commencer avec OpenHands Cloud, visitez [app.all-hands.dev](https://app.all-hands.dev).
-
-Vous serez invité à vous connecter avec votre compte GitHub ou GitLab :
-
-1. Après avoir lu et accepté les conditions d'utilisation, cliquez sur `Se connecter à GitHub` ou `Se connecter à GitLab`.
-2. Examinez les permissions demandées par OpenHands et autorisez l'application.
- - OpenHands nécessitera certaines permissions de votre compte. Pour en savoir plus sur ces permissions,
- vous pouvez cliquer sur le lien `En savoir plus` sur la page d'autorisation.
-
-## Prochaines Étapes
-
-Une fois que vous avez connecté votre compte, vous pouvez :
-
-- [Installer l'Intégration GitHub](./github-installation.md) pour utiliser OpenHands avec vos dépôts GitHub
-- [Installer l'Intégration GitLab](./gitlab-installation.md) pour utiliser OpenHands avec vos dépôts GitLab
-- [Accéder à l'Interface Cloud](./cloud-ui.md) pour interagir avec l'interface web
-- [Utiliser l'API Cloud](./cloud-api.md) pour interagir programmatiquement avec OpenHands
-- [Configurer le Résolveur de Problèmes Cloud](./cloud-issue-resolver.md) pour automatiser les corrections de code et fournir une assistance intelligente
diff --git a/docs/i18n/fr/docusaurus-plugin-content-docs/current/usage/configuration-options.md b/docs/i18n/fr/docusaurus-plugin-content-docs/current/usage/configuration-options.md
deleted file mode 100644
index ae6820bd33..0000000000
--- a/docs/i18n/fr/docusaurus-plugin-content-docs/current/usage/configuration-options.md
+++ /dev/null
@@ -1,395 +0,0 @@
-# Options de Configuration
-
-:::note
-Cette page présente toutes les options de configuration disponibles pour OpenHands, vous permettant de personnaliser son comportement et
-de l'intégrer avec d'autres services. En Mode GUI, tous les paramètres appliqués via l'interface Paramètres auront la priorité.
-:::
-
-## Configuration Principale
-
-Les options de configuration principales sont définies dans la section `[core]` du fichier `config.toml`.
-
-### Clés API
-- `e2b_api_key`
- - Type: `str`
- - Défaut: `""`
- - Description: Clé API pour E2B
-
-- `modal_api_token_id`
- - Type: `str`
- - Défaut: `""`
- - Description: ID de token API pour Modal
-
-- `modal_api_token_secret`
- - Type: `str`
- - Défaut: `""`
- - Description: Secret de token API pour Modal
-
-### Espace de travail
-- `workspace_base` **(Déprécié)**
- - Type: `str`
- - Défaut: `"./workspace"`
- - Description: Chemin de base pour l'espace de travail. **Déprécié: Utilisez `SANDBOX_VOLUMES` à la place.**
-
-- `cache_dir`
- - Type: `str`
- - Défaut: `"/tmp/cache"`
- - Description: Chemin du répertoire de cache
-
-### Débogage et Journalisation
-- `debug`
- - Type: `bool`
- - Défaut: `false`
- - Description: Activer le débogage
-
-- `disable_color`
- - Type: `bool`
- - Défaut: `false`
- - Description: Désactiver la couleur dans la sortie du terminal
-
-### Trajectoires
-- `save_trajectory_path`
- - Type: `str`
- - Défaut: `"./trajectories"`
- - Description: Chemin pour stocker les trajectoires (peut être un dossier ou un fichier). Si c'est un dossier, les trajectoires seront sauvegardées dans un fichier nommé avec l'ID de session et l'extension .json, dans ce dossier.
-
-- `replay_trajectory_path`
- - Type: `str`
- - Défaut: `""`
- - Description: Chemin pour charger une trajectoire et la rejouer. Si fourni, doit être un chemin vers le fichier de trajectoire au format JSON. Les actions dans le fichier de trajectoire seront rejouées d'abord avant que toute instruction utilisateur ne soit exécutée.
-
-### Stockage de Fichiers
-- `file_store_path`
- - Type: `str`
- - Défaut: `"/tmp/file_store"`
- - Description: Chemin du stockage de fichiers
-
-- `file_store`
- - Type: `str`
- - Défaut: `"memory"`
- - Description: Type de stockage de fichiers
-
-- `file_uploads_allowed_extensions`
- - Type: `liste de str`
- - Défaut: `[".*"]`
- - Description: Liste des extensions de fichiers autorisées pour les téléchargements
-
-- `file_uploads_max_file_size_mb`
- - Type: `int`
- - Défaut: `0`
- - Description: Taille maximale de fichier pour les téléchargements, en mégaoctets
-
-- `file_uploads_restrict_file_types`
- - Type: `bool`
- - Défaut: `false`
- - Description: Restreindre les types de fichiers pour les téléchargements
-
-- `file_uploads_allowed_extensions`
- - Type: `liste de str`
- - Défaut: `[".*"]`
- - Description: Liste des extensions de fichiers autorisées pour les téléchargements
-
-### Gestion des Tâches
-- `max_budget_per_task`
- - Type: `float`
- - Défaut: `0.0`
- - Description: Budget maximum par tâche (0.0 signifie pas de limite)
-
-- `max_iterations`
- - Type: `int`
- - Défaut: `100`
- - Description: Nombre maximum d'itérations
-
-### Configuration du Sandbox
-- `volumes`
- - Type: `str`
- - Défaut: `None`
- - Description: Montages de volumes au format 'chemin_hôte:chemin_conteneur[:mode]', par ex. '/my/host/dir:/workspace:rw'. Plusieurs montages peuvent être spécifiés en utilisant des virgules, par ex. '/path1:/workspace/path1,/path2:/workspace/path2:ro'
-
-- `workspace_mount_path_in_sandbox` **(Déprécié)**
- - Type: `str`
- - Défaut: `"/workspace"`
- - Description: Chemin pour monter l'espace de travail dans le sandbox. **Déprécié: Utilisez `SANDBOX_VOLUMES` à la place.**
-
-- `workspace_mount_path` **(Déprécié)**
- - Type: `str`
- - Défaut: `""`
- - Description: Chemin pour monter l'espace de travail. **Déprécié: Utilisez `SANDBOX_VOLUMES` à la place.**
-
-- `workspace_mount_rewrite` **(Déprécié)**
- - Type: `str`
- - Défaut: `""`
- - Description: Chemin pour réécrire le chemin de montage de l'espace de travail. Vous pouvez généralement ignorer cela, cela fait référence à des cas spéciaux d'exécution à l'intérieur d'un autre conteneur. **Déprécié: Utilisez `SANDBOX_VOLUMES` à la place.**
-
-### Divers
-- `run_as_openhands`
- - Type: `bool`
- - Défaut: `true`
- - Description: Exécuter en tant qu'OpenHands
-
-- `runtime`
- - Type: `str`
- - Défaut: `"docker"`
- - Description: Environnement d'exécution
-
-- `default_agent`
- - Type: `str`
- - Défaut: `"CodeActAgent"`
- - Description: Nom de l'agent par défaut
-
-- `jwt_secret`
- - Type: `str`
- - Défaut: `uuid.uuid4().hex`
- - Description: Secret JWT pour l'authentification. Veuillez le définir avec votre propre valeur.
-
-## Configuration LLM
-
-Les options de configuration LLM (Large Language Model) sont définies dans la section `[llm]` du fichier `config.toml`.
-
-Pour les utiliser avec la commande docker, passez `-e LLM_