diff --git a/docs/i18n/fr/docusaurus-plugin-content-docs/current/usage/about.md b/docs/i18n/fr/docusaurus-plugin-content-docs/current/usage/about.md index a38679543382..b6dc0a9c7bbf 100644 --- a/docs/i18n/fr/docusaurus-plugin-content-docs/current/usage/about.md +++ b/docs/i18n/fr/docusaurus-plugin-content-docs/current/usage/about.md @@ -1,15 +1,12 @@ - - # À propos d'OpenHands ## Stratégie de recherche -La réplication complète d'applications de niveau production avec des LLM est une entreprise complexe. Notre stratégie implique : +Réaliser une réplication complète d'applications de qualité production avec des LLM est une entreprise complexe. Notre stratégie comprend : -1. **Recherche technique fondamentale :** Se concentrer sur la recherche fondamentale pour comprendre et améliorer les aspects techniques de la génération et de la gestion du code -2. **Capacités spécialisées :** Améliorer l'efficacité des composants de base grâce à la curation des données, aux méthodes d'entraînement, et plus encore -3. **Planification des tâches :** Développer des capacités pour la détection des bugs, la gestion des bases de code et l'optimisation -4. **Évaluation :** Établir des métriques d'évaluation complètes pour mieux comprendre et améliorer nos modèles +- **Recherche technique fondamentale :** Concentration sur la recherche fondamentale pour comprendre et améliorer les aspects techniques de la génération et de la gestion du code. +- **Planification des tâches :** Développement de capacités pour la détection de bugs, la gestion de base de code et l'optimisation. +- **Évaluation :** Établissement de métriques d'évaluation complètes pour mieux comprendre et améliorer nos agents. ## Agent par défaut @@ -17,12 +14,12 @@ Notre Agent par défaut est actuellement le [CodeActAgent](agents), qui est capa ## Construit avec -OpenHands est construit en utilisant une combinaison de frameworks et de bibliothèques puissants, fournissant une base solide pour son développement. Voici les principales technologies utilisées dans le projet : +OpenHands est construit en utilisant une combinaison de frameworks et bibliothèques puissants, fournissant une base solide pour son développement. Voici les technologies clés utilisées dans le projet : ![FastAPI](https://img.shields.io/badge/FastAPI-black?style=for-the-badge) ![uvicorn](https://img.shields.io/badge/uvicorn-black?style=for-the-badge) ![LiteLLM](https://img.shields.io/badge/LiteLLM-black?style=for-the-badge) ![Docker](https://img.shields.io/badge/Docker-black?style=for-the-badge) ![Ruff](https://img.shields.io/badge/Ruff-black?style=for-the-badge) ![MyPy](https://img.shields.io/badge/MyPy-black?style=for-the-badge) ![LlamaIndex](https://img.shields.io/badge/LlamaIndex-black?style=for-the-badge) ![React](https://img.shields.io/badge/React-black?style=for-the-badge) -Veuillez noter que la sélection de ces technologies est en cours et que des technologies supplémentaires peuvent être ajoutées ou des technologies existantes peuvent être supprimées à mesure que le projet évolue. Nous nous efforçons d'adopter les outils les plus appropriés et les plus efficaces pour améliorer les capacités d'OpenHands. +Veuillez noter que la sélection de ces technologies est en cours, et des technologies supplémentaires peuvent être ajoutées ou des existantes peuvent être supprimées à mesure que le projet évolue. Nous nous efforçons d'adopter les outils les plus appropriés et efficaces pour améliorer les capacités d'OpenHands. ## Licence -Distribué sous la [Licence](https://github.com/All-Hands-AI/OpenHands/blob/main/LICENSE) MIT. +Distribué sous la [Licence](https://github.com/All-Hands-AI/OpenHands/blob/main/LICENSE) MIT. \ No newline at end of file diff --git a/docs/i18n/fr/docusaurus-plugin-content-docs/current/usage/agents.md b/docs/i18n/fr/docusaurus-plugin-content-docs/current/usage/agents.md index d283f428418b..7b9cce4943a2 100644 --- a/docs/i18n/fr/docusaurus-plugin-content-docs/current/usage/agents.md +++ b/docs/i18n/fr/docusaurus-plugin-content-docs/current/usage/agents.md @@ -1,12 +1,10 @@ - - # 🧠 Agent Principal et Capacités ## CodeActAgent ### Description -Cet agent implémente l'idée de CodeAct ([article](https://arxiv.org/abs/2402.01030), [tweet](https://twitter.com/xingyaow_/status/1754556835703751087)) qui consolide les **act**ions des agents LLM dans un espace d'action de **code** unifié à la fois pour la _simplicité_ et la _performance_. +Cet agent implémente l'idée CodeAct ([article](https://arxiv.org/abs/2402.01030), [tweet](https://twitter.com/xingyaow_/status/1754556835703751087)) qui consolide les **act**ions des agents LLM dans un espace d'action **code** unifié pour la _simplicité_ et la _performance_. L'idée conceptuelle est illustrée ci-dessous. À chaque tour, l'agent peut : @@ -14,7 +12,7 @@ L'idée conceptuelle est illustrée ci-dessous. À chaque tour, l'agent peut : 2. **CodeAct** : Choisir d'effectuer la tâche en exécutant du code - Exécuter n'importe quelle commande Linux `bash` valide -- Exécuter n'importe quel code `Python` valide avec [un interpréteur Python interactif](https://ipython.org/). Ceci est simulé via une commande `bash`, voir le système de plugin ci-dessous pour plus de détails. +- Exécuter n'importe quel code `Python` valide avec [un interpréteur Python interactif](https://ipython.org/). Ceci est simulé via la commande `bash`, voir le système de plugins ci-dessous pour plus de détails. ![image](https://github.com/All-Hands-AI/OpenHands/assets/38853559/92b622e3-72ad-4a61-8f41-8c040b6d5fb3) @@ -22,4 +20,4 @@ L'idée conceptuelle est illustrée ci-dessous. À chaque tour, l'agent peut : https://github.com/All-Hands-AI/OpenHands/assets/38853559/f592a192-e86c-4f48-ad31-d69282d5f6ac -_Exemple de CodeActAgent avec `gpt-4-turbo-2024-04-09` effectuant une tâche de science des données (régression linéaire)_. +_Exemple de CodeActAgent avec `gpt-4-turbo-2024-04-09` réalisant une tâche de science des données (régression linéaire)_. \ No newline at end of file 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 index d422c59abca5..9a793fe9aec4 100644 --- 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 @@ -1,35 +1,35 @@ - - # 🏛️ Architecture du Système
- OpenHands System Architecture Diagram Jul 4 2024 -

Diagramme de l'Architecture du Système OpenHands (4 juillet 2024)

+ Diagramme d'Architecture OpenHands 4 juillet 2024 +

Diagramme d'Architecture OpenHands (4 juillet 2024)

-Ceci est une vue d'ensemble de haut niveau 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. +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 du Frontend {#frontend-architecture-fr} +# Architecture Frontend {#frontend-architecture-en} ![system_architecture.svg](/img/system_architecture.svg) -Cette vue d'ensemble est simplifiée pour montrer les principaux composants et leurs interactions. Pour une vue plus détaillée de l'architecture du backend, voir la section Architecture du Backend ci-dessous. +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 du Backend {#backend-architecture-fr} +# Architecture Backend {#backend-architecture-en} -_**Avertissement** : L'architecture du backend est en cours de développement et est sujette à changement. Le diagramme suivant montre l'architecture actuelle du backend basée sur le commit indiqué dans le pied de page du diagramme._ +_**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._ ![backend_architecture.svg](/img/backend_architecture.svg)
- Mise à jour de ce Diagramme + Mise à jour de ce diagramme
- La génération du diagramme d'architecture du backend est partiellement automatisée. - Le diagramme est généré à partir des indications de type dans le code en utilisant l'outil py2puml. Le diagramme est ensuite manuellement revu, ajusté et exporté en PNG et SVG. + 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 fonctionnel dans lequel openhands est exécutable + - 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é @@ -38,17 +38,17 @@ _**Avertissement** : L'architecture du backend est en cours de développement et 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 ex. Visual Studio Code avec l'extension PlantUML ou [PlantText](https://www.planttext.com/) +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. Revoir le PUML généré et effectuer tous les ajustements nécessaires au diagramme (ajouter les parties manquantes, corriger les erreurs, améliorer le positionnement). - _py2puml crée le diagramme en se basant sur les indications de type dans le code, donc des indications manquantes ou incorrectes peuvent entraîner un diagramme incomplet ou incorrect._ +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. Revoir la différence entre le nouveau diagramme et le précédent et vérifier manuellement si les changements sont corrects. - _S'assurer de ne pas supprimer des parties qui ont été ajoutées manuellement au diagramme par le passé et qui sont toujours pertinentes._ +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 sous forme de fichiers PNG et SVG et remplacer les diagrammes existants dans le répertoire `docs/architecture`. Cela peut être fait avec (par ex. [PlantText](https://www.planttext.com/)) +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/))
-
+ \ No newline at end of file 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 index 71e121d45d62..d951347a2645 100644 --- 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 @@ -1,19 +1,17 @@ +# 📦 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. -# 📦 Runtime Docker - -Le Runtime Docker d'OpenHands est le composant principal qui permet l'exécution sécurisée et flexible des actions des agents d'IA. -Il crée un environnement en bac à sable (sandbox) en utilisant Docker, où du code arbitraire peut être exécuté en toute sécurité sans risquer le système hôte. - -## Pourquoi avons-nous besoin d'un runtime en bac à sable ? +## 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 poser des risques importants pour le système hôte. Un environnement en bac à sable empêche le code malveillant d'accéder ou de modifier les ressources du système hôte -2. Cohérence : Un environnement en bac à sable garantit que l'exécution du code est cohérente sur différentes machines et configurations, éliminant les problèmes du type "ça fonctionne sur ma machine" -3. Contrôle des ressources : Le bac à sable 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 +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 en bac à sable facilitent la reproduction des bugs et des problèmes, car l'environnement d'exécution est cohérent et contrôlable +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 ? @@ -23,17 +21,17 @@ Le système Runtime d'OpenHands utilise une architecture client-serveur impléme graph TD A[Image Docker personnalisée fournie par l'utilisateur] --> B[Backend OpenHands] B -->|Construit| C[Image OH Runtime] - C -->|Lance| D[Exécuteur d'actions] + C -->|Lance| D[Action Executor] D -->|Initialise| E[Navigateur] D -->|Initialise| F[Shell Bash] D -->|Initialise| G[Plugins] G -->|Initialise| L[Serveur Jupyter] - B -->|Génère| H[Agent] - B -->|Génère| I[EventStream] + B -->|Crée| H[Agent] + B -->|Crée| I[EventStream] I <--->|Exécute l'action pour obtenir l'observation - via l'API REST + via API REST | D H -->|Génère l'action| I @@ -50,80 +48,72 @@ graph TD 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 en utilisant l'image OH runtime -4. Initialisation du serveur d'exécution des actions : Le serveur d'exécution des actions initialise un `ActionExecutor` à l'intérieur du conteneur, mettant en place 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 des actions via une API RESTful, envoyant des actions et recevant des observations -6. Exécution des actions : Le client runtime reçoit les actions du backend, les exécute dans l'environnement en bac à sable et renvoie les observations -7. Retour des observations : Le serveur d'exécution des actions renvoie les résultats d'exécution au backend OpenHands sous forme d'observations - +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 un intermédiaire entre le backend OpenHands et l'environnement en bac à sable -- Il exécute différents types d'actions (commandes shell, opérations sur les fichiers, code Python, etc.) en toute sécurité dans le conteneur -- Il gère l'état de l'environnement en bac à sable, y compris le répertoire de travail courant et les plugins chargés -- Il formate et renvoie les observations au backend, assurant une interface cohérente pour le traitement des résultats +- 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 la construction et la gestion des images runtime assure l'efficacité, la cohérence et la 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 souhaitez plus de détails. +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. -### Système de balises d'images +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. -OpenHands utilise un système à trois balises pour ses images runtime afin d'équilibrer la reproductibilité et la flexibilité. -Les balises peuvent être dans l'un des 2 formats suivants : +### Système de marquage d'images -- **Balise versionnée** : `oh_v{openhands_version}_{base_image}` (ex : `oh_v0.9.9_nikolaik_s_python-nodejs_t_python3.12-nodejs22`) -- **Balise de verrouillage** : `oh_v{openhands_version}_{16_digit_lock_hash}` (ex : `oh_v0.9.9_1234567890abcdef`) -- **Balise source** : `oh_v{openhands_version}_{16_digit_lock_hash}_{16_digit_source_hash}` - (ex : `oh_v0.9.9_1234567890abcdef_1234567890abcdef`) +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`) -#### Balise source - La plus spécifique +#### 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 d'openhands +uniquement pour la source openhands. - -#### Balise de verrouillage +#### 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 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. -#### Balise versionnée - La plus générique +#### Tag versionné - Le plus générique -Cette balise est une concaténation de la version d'openhands et du nom de l'image de base (transformé pour s'adapter au standard des balises). +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 la même **balise source la 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 la **balise de verrouillage générique** existe. S'il existe une telle image, - OpenHands construit une nouvelle image basée sur celle-ci, en 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 balisée avec une - balise **source** uniquement. -- **Reconstruction correcte** : Si ni une balise **source** ni une balise **de verrouillage** n'existe, une image sera construite sur la base de l'image avec la balise **versionnée**. - Dans l'image avec la balise versionnée, la plupart des dépendances devraient déjà être installées, ce qui permet de gagner du temps. -- **Reconstruction la plus lente** : Si les trois balises n'existent pas, une toute nouvelle image est construite à partir de - l'image de base (ce qui est une opération plus lente). Cette nouvelle image est balisée avec toutes les balises **source**, **de verrouillage** et **versionnée**. +- **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 balisage permet à OpenHands de gérer efficacement les environnements de développement et de production. +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 balises basées sur des hashs) -2. Le système peut reconstruire rapidement les images lorsque des changements mineurs se produisent (en s'appuyant sur des images compatibles récentes) -3. La balise **de verrouillage** (ex : `runtime:oh_v0.9.3_1234567890abcdef`) pointe toujours vers la dernière version pour une combinaison particulière d'image de base, de dépendances et de version d'OpenHands +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 du Runtime +## Système de plugins Runtime -Le Runtime d'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 lorsque le client runtime démarre. +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. @@ -131,8 +121,8 @@ Consultez [un exemple de plugin Jupyter ici](https://github.com/All-Hands-AI/Ope Aspects clés du système de plugins : -1. Définition des plugins : Les plugins sont définis comme des classes Python qui héritent d'une classe de base `Plugin` -2. Enregistrement des plugins : Les plugins disponibles sont enregistrés dans un dictionnaire `ALL_PLUGINS` -3. Spécification des plugins : 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 lorsque le client runtime démarre -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) +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) \ No newline at end of file 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 new file mode 100644 index 000000000000..9f95c97fa475 --- /dev/null +++ b/docs/i18n/fr/docusaurus-plugin-content-docs/current/usage/cloud/cloud-api.md @@ -0,0 +1,177 @@ +# 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 + +![Génération de clé API](/img/docs/api-key-generation.png) + +## 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 + +
+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['id']}") +print(f"Status: {conversation['status']}") +``` +
+ +
+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 + +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 + +
+cURL + +```bash +curl -X GET "https://app.all-hands.dev/api/conversations/{conversation_id}" \ + -H "Authorization: Bearer YOUR_API_KEY" +``` +
+ +#### 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. \ No newline at end of file diff --git a/docs/i18n/fr/docusaurus-plugin-content-docs/current/usage/cloud/cloud-github-resolver.md b/docs/i18n/fr/docusaurus-plugin-content-docs/current/usage/cloud/cloud-github-resolver.md new file mode 100644 index 000000000000..fc3ef90413a0 --- /dev/null +++ b/docs/i18n/fr/docusaurus-plugin-content-docs/current/usage/cloud/cloud-github-resolver.md @@ -0,0 +1,33 @@ +# Résolveur GitHub Cloud + +Le Résolveur GitHub automatise les corrections de code et fournit une assistance intelligente pour vos dépôts. + +## Configuration + +Le Résolveur GitHub Cloud est disponible automatiquement lorsque vous +[accordez l'accès au dépôt OpenHands Cloud](./openhands-cloud#adding-repository-access). + +## Utilisation + +Après avoir accordé l'accès au dépôt OpenHands Cloud, vous pouvez utiliser le Résolveur GitHub Cloud sur les problèmes et les pull requests +du dépôt. + +### Problèmes (Issues) + +Sur votre dépôt, étiquetez un problème avec `openhands`. OpenHands va : +1. Commenter le problème pour vous informer qu'il y travaille. + - Vous pouvez cliquer sur le lien pour suivre la progression sur OpenHands Cloud. +2. Ouvrir une pull request 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 pull request. + + +### Pull Requests + +Pour qu'OpenHands travaille sur des pull requests, utilisez `@openhands` dans les commentaires de premier niveau ou en ligne pour : + - Poser des questions + - Demander des mises à jour + - Obtenir des explications de code + +OpenHands va : +1. Commenter la PR pour vous informer qu'il y travaille. +2. Effectuer la tâche. \ No newline at end of file diff --git a/docs/i18n/fr/docusaurus-plugin-content-docs/current/usage/cloud/openhands-cloud.mdx b/docs/i18n/fr/docusaurus-plugin-content-docs/current/usage/cloud/openhands-cloud.mdx new file mode 100644 index 000000000000..d1191c2c5ea5 --- /dev/null +++ b/docs/i18n/fr/docusaurus-plugin-content-docs/current/usage/cloud/openhands-cloud.mdx @@ -0,0 +1,65 @@ +# OpenHands Cloud + +OpenHands Cloud est la version hébergée dans le cloud d'OpenHands par All Hands AI. + +## Accéder à OpenHands Cloud + +OpenHands Cloud est accessible à l'adresse https://app.all-hands.dev/. + +Vous pouvez également interagir avec OpenHands Cloud par programmation en utilisant l'[API](./cloud-api). + +## Premiers pas + +Après avoir visité OpenHands Cloud, il vous sera demandé de vous connecter avec votre compte GitHub ou GitLab : + +1. Après avoir lu et accepté les conditions d'utilisation, cliquez sur `Log in with GitHub` ou `Log in with GitLab`. +2. Examinez les autorisations demandées par OpenHands, puis cliquez sur `Authorize OpenHands AI`. + - OpenHands nécessitera certaines autorisations de votre compte GitHub ou GitLab. Pour en savoir plus sur ces autorisations : + - GitHub : Vous pouvez cliquer sur le lien `Learn more` sur la page d'autorisation GitHub. + - GitLab : Vous pouvez développer chaque demande d'autorisation sur la page d'autorisation GitLab. + +## Accès aux dépôts + +### GitHub + +#### Ajouter l'accès aux dépôts + +Vous pouvez accorder à OpenHands un accès à des dépôts spécifiques : +1. Cliquez sur `Add GitHub repos` sur la page d'accueil. +2. Sélectionnez l'organisation, puis choisissez les dépôts spécifiques auxquels vous souhaitez donner accès à OpenHands. +
+ Détails des autorisations pour l'accès aux dépôts + + Openhands demande des jetons à courte durée de vie (expiration de 8 heures) avec ces autorisations : + - Actions : Lecture et écriture + - Administration : Lecture seule + - Statuts de commit : Lecture et écriture + - Contenus : Lecture et écriture + - Issues : 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 : + - L'autorisation accordée pour le dépôt. + - Les autorisations GitHub de l'utilisateur (propriétaire/collaborateur). +
+ +3. Cliquez sur `Install & Authorize`. + +#### Modifier l'accès aux dépôts + +Vous pouvez modifier l'accès aux dépôts GitHub à tout moment en : +* Utilisant le même processus `Add GitHub repos`, ou +* Visitant la page Paramètres et en sélectionnant `Configure GitHub Repositories` dans la section `Git Settings`. + +### GitLab + +Lorsque vous utilisez votre compte GitLab, OpenHands aura automatiquement accès à vos dépôts. + +## Persistance des conversations + +- Liste des conversations – Affiche uniquement les 10 conversations les plus récentes initiées au cours des 10 derniers jours. +- Espaces de travail – Les espaces de travail de conversation sont conservés pendant 14 jours. +- Environnements d'exécution – Les environnements d'exécution restent actifs ("chauds") pendant 30 minutes. Après cette période, la reprise d'une conversation peut prendre 1 à 2 minutes. \ No newline at end of file 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 index 41bfd143d2ae..e15d2bd94216 100644 --- 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 @@ -1,387 +1,395 @@ -# Options de configuration - -Ce guide détaille toutes les options de configuration disponibles pour OpenHands, vous aidant à personnaliser son comportement et à l'intégrer avec d'autres services. +# Options de Configuration :::note -Si vous exécutez en [Mode GUI](https://docs.all-hands.dev/modules/usage/how-to/gui-mode), les paramètres disponibles dans l'interface utilisateur des paramètres auront toujours -la priorité. +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é. ::: ---- - -# Table des matières - -1. [Configuration de base](#core-configuration) - - [Clés API](#api-keys) - - [Espace de travail](#workspace) - - [Débogage et journalisation](#debugging-and-logging) - - [Trajectoires](#trajectories) - - [Stockage de fichiers](#file-store) - - [Gestion des tâches](#task-management) - - [Configuration du bac à sable](#sandbox-configuration) - - [Divers](#miscellaneous) -2. [Configuration LLM](#llm-configuration) - - [Informations d'identification AWS](#aws-credentials) - - [Configuration de l'API](#api-configuration) - - [Fournisseur LLM personnalisé](#custom-llm-provider) - - [Embeddings](#embeddings) - - [Gestion des messages](#message-handling) - - [Sélection du modèle](#model-selection) - - [Nouvelles tentatives](#retrying) - - [Options avancées](#advanced-options) -3. [Configuration de l'agent](#agent-configuration) - - [Configuration de la mémoire](#memory-configuration) - - [Configuration LLM](#llm-configuration-1) - - [Configuration de l'espace d'action](#actionspace-configuration) - - [Utilisation du micro-agent](#microagent-usage) -4. [Configuration du bac à sable](#sandbox-configuration-1) - - [Exécution](#execution) - - [Image de conteneur](#container-image) - - [Mise en réseau](#networking) - - [Linting et plugins](#linting-and-plugins) - - [Dépendances et environnement](#dependencies-and-environment) - - [Évaluation](#evaluation) -5. [Configuration de sécurité](#security-configuration) - - [Mode de confirmation](#confirmation-mode) - - [Analyseur de sécurité](#security-analyzer) - ---- - -## Configuration de base - -Les options de configuration de base sont définies dans la section `[core]` du fichier `config.toml`. - -**Clés API** +## 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` - - Valeur par défaut : `""` - - Description : Clé API pour E2B + - Type: `str` + - Défaut: `""` + - Description: Clé API pour E2B - `modal_api_token_id` - - Type : `str` - - Valeur par défaut : `""` - - Description : ID du jeton API pour Modal + - Type: `str` + - Défaut: `""` + - Description: ID de token API pour Modal - `modal_api_token_secret` - - Type : `str` - - Valeur par défaut : `""` - - Description : Secret du jeton API pour Modal + - Type: `str` + - Défaut: `""` + - Description: Secret de token API pour Modal -**Espace de travail** -- `workspace_base` - - Type : `str` - - Valeur par défaut : `"./workspace"` - - Description : Chemin de base pour l'espace de travail +### 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` - - Valeur par défaut : `"/tmp/cache"` - - Description : Chemin du répertoire de cache + - Type: `str` + - Défaut: `"/tmp/cache"` + - Description: Chemin du répertoire de cache -**Débogage et journalisation** +### Débogage et Journalisation - `debug` - - Type : `bool` - - Valeur par défaut : `false` - - Description : Activer le débogage + - Type: `bool` + - Défaut: `false` + - Description: Activer le débogage - `disable_color` - - Type : `bool` - - Valeur par défaut : `false` - - Description : Désactiver la couleur dans la sortie du terminal + - Type: `bool` + - Défaut: `false` + - Description: Désactiver la couleur dans la sortie du terminal -**Trajectoires** +### Trajectoires - `save_trajectory_path` - - Type : `str` - - Valeur par défaut : `"./trajectories"` - - Description : Chemin pour stocker les trajectoires (peut être un dossier ou un fichier). Si c'est un dossier, les trajectoires seront enregistrées dans un fichier nommé avec l'ID de session et l'extension .json, dans ce dossier. + - 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. -**Stockage de fichiers** +- `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` - - Valeur par défaut : `"/tmp/file_store"` - - Description : Chemin de stockage des fichiers + - Type: `str` + - Défaut: `"/tmp/file_store"` + - Description: Chemin du stockage de fichiers - `file_store` - - Type : `str` - - Valeur par défaut : `"memory"` - - Description : Type de stockage de fichiers + - Type: `str` + - Défaut: `"memory"` + - Description: Type de stockage de fichiers - `file_uploads_allowed_extensions` - - Type : `list of str` - - Valeur par défaut : `[".*"]` - - Description : Liste des extensions de fichiers autorisées pour les téléchargements + - 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` - - Valeur par défaut : `0` - - Description : Taille maximale des fichiers pour les téléchargements, en mégaoctets + - 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` - - Valeur par défaut : `false` - - Description : Restreindre les types de fichiers pour les téléchargements de fichiers + - Type: `bool` + - Défaut: `false` + - Description: Restreindre les types de fichiers pour les téléchargements - `file_uploads_allowed_extensions` - - Type : `list of str` - - Valeur par défaut : `[".*"]` - - Description : Liste des extensions de fichiers autorisées pour les téléchargements + - Type: `liste de str` + - Défaut: `[".*"]` + - Description: Liste des extensions de fichiers autorisées pour les téléchargements -**Gestion des tâches** +### Gestion des Tâches - `max_budget_per_task` - - Type : `float` - - Valeur par défaut : `0.0` - - Description : Budget maximal par tâche (0.0 signifie aucune limite) + - Type: `float` + - Défaut: `0.0` + - Description: Budget maximum par tâche (0.0 signifie pas de limite) - `max_iterations` - - Type : `int` - - Valeur par défaut : `100` - - Description : Nombre maximal d'itérations - -**Configuration du bac à sable** -- `workspace_mount_path_in_sandbox` - - Type : `str` - - Valeur par défaut : `"/workspace"` - - Description : Chemin de montage de l'espace de travail dans le bac à sable - -- `workspace_mount_path` - - Type : `str` - - Valeur par défaut : `""` - - Description : Chemin de montage de l'espace de travail - -- `workspace_mount_rewrite` - - Type : `str` - - Valeur par 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. - -**Divers** + - 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` - - Valeur par défaut : `true` - - Description : Exécuter en tant qu'OpenHands + - Type: `bool` + - Défaut: `true` + - Description: Exécuter en tant qu'OpenHands - `runtime` - - Type : `str` - - Valeur par défaut : `"docker"` - - Description : Environnement d'exécution + - Type: `str` + - Défaut: `"docker"` + - Description: Environnement d'exécution - `default_agent` - - Type : `str` - - Valeur par défaut : `"CodeActAgent"` - - Description : Nom de l'agent par défaut + - Type: `str` + - Défaut: `"CodeActAgent"` + - Description: Nom de l'agent par défaut - `jwt_secret` - - Type : `str` - - Valeur par défaut : `uuid.uuid4().hex` - - Description : Secret JWT pour l'authentification. Veuillez le définir sur votre propre valeur. + - 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_