--- title: "Créer et gérer des actions" description: "Créer une action, en conserver plusieurs versions, et synchroniser ces versions avec Git ne forment qu'un seul workflow plutôt que trois" url: https://docs.ovhcloud.com/fr/guides/public-cloud/data-platform/dpe-actions-manage lang: fr lastUpdated: 2026-09-14 --- > For AI agents: the complete documentation index is available at https://docs.ovhcloud.com/fr/llms.txt, the full documentation bundle is available at https://docs.ovhcloud.com/fr/llms-full.txt. # Créer et gérer des actions ## Objectif Créer une action, en conserver plusieurs versions, et synchroniser ces versions avec Git ne forment qu'un seul workflow plutôt que trois. Cette page couvre ce workflow, ainsi que ce qui déclenche une reconstruction et ce qui n'est pas possible aujourd'hui. Quel type d'action créer est une question distincte, à laquelle répond la page [Actions](https://docs.ovhcloud.com/fr/guides/public-cloud/data-platform/landing-page-dpe-actions.md). ## Créer une action Lorsqu'un repository est vide, la première chose que vous souhaitez faire est de **créer une action**. Depuis la page principale, cliquez sur le bouton _New action_ en haut à droite de l'écran. Vous serez alors invité à choisir le type d'action que vous souhaitez effectuer depuis le Platform Store. ![Créer une action — Typeofactions](/images/public-cloud/data-platform/product/dpe/actions/picts/typeofactions.png) :::info Notez que l'édition des actions est toujours en mode autosave. Utilisez les [versions](https://docs.ovhcloud.com/fr/guides/public-cloud/data-platform/dpe-actions-manage.md#gestion-des-versions-des-repositories-dactions) si vous ne souhaitez pas altérer vos actions déployées en production. ::: ### Mode avancé Les actions du Data Processing Engine sont toutes configurées à l'aide d'un ensemble d'entrées spécifiées via un fichier de configuration JSON. Il existe 2 façons pour les utilisateurs de mettre à jour les entrées d'une action : - soit en utilisant l'interface graphique - soit en utilisant un **mode avancé** qui vous permet de modifier directement le fichier de configuration JSON L'utilisation du « mode avancé » offre un peu plus de flexibilité et d'options qui peuvent être utiles pour les utilisateurs avancés. ![Mode avancé](/images/public-cloud/data-platform/product/dpe/actions/picts/advanced-mode.png) :::info Notez que le mode avancé est également très pratique pour les [actions Custom](https://docs.ovhcloud.com/fr/guides/public-cloud/data-platform/dpe-actions-custom.md), car il offre une expérience proche d'un IDE dans le navigateur. Cela vous permettra de coder des scripts Python personnalisés directement au sein de la platform sans avoir à gérer de fichiers localement sur votre ordinateur. ::: ## Gérer les actions À mesure que votre Projet mûrit, la structure et l'organisation deviennent de plus en plus importantes. Pour faciliter cela, la Platform propose plusieurs méthodes pour mieux organiser et gérer vos actions : - [Repositories](https://docs.ovhcloud.com/fr/guides/public-cloud/data-platform/dpe-actions-manage.md#gestion-des-versions-des-repositories-dactions) : permet de compartimenter vos actions en différentes sections pouvant être versionnées - [Versions](https://docs.ovhcloud.com/fr/guides/public-cloud/data-platform/dpe-actions-manage.md#gestion-des-versions-des-repositories-dactions) : la platform propose une expérience de gestion des versions en ligne pour chaque repository d'actions individuellement. La platform dispose de son propre système de contrôle de version, mais vous pouvez également synchroniser chaque repository avec Git - **Descriptions & Tags** : chaque action peut se voir attribuer une _description_ et/ou des _tags_. Cela vous permet de documenter votre Projet, particulièrement utile lors d'une collaboration au sein de grandes équipes. - **Lineage** : chaque action contient un sous-onglet lineage, accessible lors de l'édition d'une action. Il affiche chaque [workflow](https://docs.ovhcloud.com/fr/guides/public-cloud/data-platform/dpe-workflows.md) qui contient l'action. Les workflows vous permettent d'orchestrer l'exécution de plusieurs actions et de les lancer dans un ordre spécifique à l'aide de stages. ### Gestion des versions des repositories d'actions L'édition des actions est toujours en mode autosave. Lorsque vous essayez d'itérer sur des actions existantes, il est recommandé de créer plusieurs versions du code des actions. Cela vous permet d'introduire progressivement des variations pour expérimenter et tester votre travail, tout en gardant intacte la version en production. **Sur la platform, cette gestion des versions se fait au niveau des repositories**. Les repositories sont les onglets que vous voyez en haut de la vue arborescente des Actions. ![repos](/images/public-cloud/data-platform/product/dpe/actions/picts/repos.png) Vous ne pouvez pas versionner une action individuelle, mais tout un repository d'actions. Le panneau de gestion des versions est accessible en haut à droite de l'en-tête du repository : ![Gestion des versions des repositories d'actions — Versioning panel](/images/public-cloud/data-platform/product/dpe/actions/picts/versioning-panel.png) :::info Cette fonctionnalité est également disponible sur d'autres composants qui implémentent des repositories, tels que les [requêtes de l'Analytics Manager](https://docs.ovhcloud.com/fr/guides/public-cloud/data-platform/analytics-manager-queries.md#versionnage-des-requ%C3%AAtes). Elle fonctionne de la même manière, il vous suffit de rechercher les éléments d'interface équivalents dans l'écran Queries. ::: Il existe 2 systèmes de gestion des versions sur la Platform : - [Système de contrôle de version de la Data Platform](https://docs.ovhcloud.com/fr/guides/public-cloud/data-platform/dpe-actions-manage.md#utiliser-le-syst%C3%A8me-de-contr%C3%B4le-de-version-de-la-platform) : le système de gestion des versions par défaut sur tous les repositories - [Gestion des versions Git](https://docs.ovhcloud.com/fr/guides/public-cloud/data-platform/dpe-actions-manage.md#utiliser-un-repository-li%C3%A9-%C3%A0-git) : si vous décidez de synchroniser votre repository avec Git Voyons maintenant comment tout cela fonctionne en pratique ! ### Utiliser le système de contrôle de version de la Platform Par défaut, chaque repository d'actions sur la platform dispose d'un système de contrôle de version intégré, vous permettant de gérer manuellement différentes versions du code (c'est-à-dire, des actions) qu'il contient. Les repositories disposent désormais de : - une **version déployée**, qui est la version servie lors de l'[exécution du job](https://docs.ovhcloud.com/fr/guides/public-cloud/data-platform/landing-page-dpe-jobs.md). - une **dernière version**, qui est la version actuellement en cours d'édition via le panneau de l'éditeur. :::info Si votre repository ne possède _qu'une seule version_, cette version est à la fois la version déployée et la version modifiable, ce qui signifie que les changements affectent immédiatement la production. ::: Si votre repository possède _deux versions ou plus_, seule la dernière version peut être modifiée. Toutes les autres versions, y compris la version déployée, seront en mode lecture seule. Pour créer une nouvelle version pour le repository, ouvrez le panneau de gestion des versions en haut à droite et cliquez sur l'icône **+**. ![Utiliser le système de contrôle de version de la Platform — Versioning fp1](/images/public-cloud/data-platform/product/dpe/actions/picts/versioning-fp1.png) Choisissez quelle version dupliquer pour créer la nouvelle version. ![Utiliser le système de contrôle de version de la Platform — Versioning fp2](/images/public-cloud/data-platform/product/dpe/actions/picts/versioning-fp2.png) Après la création de la nouvelle version, la _version déployée_ ne changera pas. Vous pouvez modifier directement la nouvelle version. ![Utiliser le système de contrôle de version de la Platform — Versioning fp3](/images/public-cloud/data-platform/product/dpe/actions/picts/versioning-fp3.png) Cliquez sur le bouton **Play** pour définir une nouvelle version comme version déployée : la version du code utilisée lors de l'exécution des actions du repo. ![Utiliser le système de contrôle de version de la Platform — Versioning fp4](/images/public-cloud/data-platform/product/dpe/actions/picts/versioning-fp4.png) ### Utiliser un repository lié à Git Chaque repository peut être lié à un repository Git externe, auquel cas les versions sont synchronisées avec les commits Git. Cela vous permet de mettre à jour et de tester les actions en continu sans affecter la version déployée en production. #### Lier un repository à Git Pour lier votre repository sur la platform à Git, vous devez cliquer sur l'icône en forme d'engrenage pour modifier un repository existant ou en créer un nouveau. L'une ou l'autre de ces actions ouvrira la fenêtre de configuration du repository. ![img1](/images/public-cloud/data-platform/product/dpe/actions/picts/repository_configuration_window.png) Cliquez sur _Connect to Git_ pour développer la fenêtre. ![img1](/images/public-cloud/data-platform/product/dpe/actions/picts/repository_configuration_full.png) Ici, la première chose que vous devez saisir est l'URL SSH du repository. Elle se trouve généralement dans les options de clonage de repository des solutions Git courantes. Sur GitHUB, par exemple, elle se trouve dans Code > Clone > SSH. ![github](/images/public-cloud/data-platform/product/dpe/actions/picts/github.png) Cliquez ensuite sur _FETCH_ pour récupérer les branches distantes et sélectionner la branche que vous souhaitez utiliser. Enfin, copiez la clé SSH publique donnée en bas et collez-la dans la liste des clés SSH associées à votre compte sur votre solution Git. Pour GitHUB, vous pouvez suivre [ce tutoriel](https://docs.github.com/en/authentication/connecting-to-github-with-ssh/adding-a-new-ssh-key-to-your-github-account). #### Commit et push Après avoir modifié un objet dans un repo, votre repo affichera les changements non commités comme montré dans l'image ci-dessous. Vous pouvez les commit et push en cliquant sur la flèche pointant vers le haut indiquée dans l'image. ![commit](/images/public-cloud/data-platform/product/dpe/actions/picts/commit_push.png) :::info En cas de conflit lors d'un push, vos changements ne seront pas poussés vers la branche que vous avez configurée ; ils seront à la place poussés vers une nouvelle branche portant le même nom que la branche actuelle, avec un suffixe _\_conflictN_, où N est le numéro du conflit. Par exemple, si votre branche s'appelle _current-branch_ et que votre push provoque un conflit, la nouvelle branche s'appellera _current-branch\_conflict1_. En cas de nouveau conflit lors d'un push, la nouvelle branche s'appellera _current-branch\_conflict2_. ::: #### Pull et merge Récupérez les changements distants en cliquant sur la flèche pointant vers le bas indiquée dans l'image ; une fenêtre pop-up vous invitera à confirmer votre décision. Tous les changements non commités seront perdus et les deux branches seront fusionnées ensemble. ![pull](/images/public-cloud/data-platform/product/dpe/actions/picts/pull_merge.png) ## Organiser et partager du code entre les actions Une action est un unique fichier `.py` avec une fonction d'entrée (`customfunc(event)` par défaut), ajouté par glisser-déposer ou via l'IDE avancé. Il n'existe **aucune structure de package multi-fichiers au sein d'une seule action**. Pour réutiliser du code entre les actions, utilisez l'un des chemins documentés : - **Référencer un repository Git** dans le champ _Python Requirements_ : ``` git+https://github.com/OWNER/REPO.git@ git+https://github.com/OWNER/REPO.git@latest ``` - **Versionner tout votre repository d'actions via Git** : [liez-le en SSH](#lier-un-repository-à-git), récupérez une branche, et collez la clé SSH publique côté Git. C'est le mécanisme prévu pour partager du code entre les actions. :::info Il n'y a **aucune variable Python globale** partagée entre les actions : chaque job s'exécute dans un conteneur neuf qui s'arrête à la fin du job. Les valeurs réutilisables sont transmises via les **Environments** (variables d'environnement), qui peuvent être assignées à plusieurs actions et workflows à la fois. ::: ## Déclencher un Notebook depuis une action Déclencher un Notebook depuis une action Custom **n'est pas pris en charge**. Les Notebooks sont des instances Jupyter avec leur propre cycle de vie manuel Start/Stop, et le flux documenté est l'inverse : convertir un notebook en action. **Modèle recommandé :** convertissez le code du notebook en action Custom, qui peut ensuite être orchestrée dans un [workflow](https://docs.ovhcloud.com/fr/guides/public-cloud/data-platform/dpe-workflows.md) ou via un appel API. ## Gérer les actions de manière programmatique (CI/CD) Il n'existe **aucun endpoint REST dédié** pour créer, mettre à jour ou supprimer des actions. L'approche officielle est la [synchronisation Git](#utiliser-un-repository-lié-à-git) : liez le repository d'actions à un repository Git via SSH, puis commit et push depuis la platform, ou pull les changements effectués en dehors de celle-ci. Pour le CI/CD, cela signifie que modifier une action consiste en un **commit dans le repository Git lié**, suivi d'un pull depuis la platform. Les [workflows](https://docs.ovhcloud.com/fr/guides/public-cloud/data-platform/dpe-workflows.md) peuvent être exécutés manuellement ou via un appel API, le déclenchement reste donc disponible même si le CRUD des actions passe par Git. ## Comportement de build - **Ce qui déclenche un build.** Les builds des workers sont déclenchés par des **changements de dépendances** : la mise à jour des dépendances redéploie l'environnement. Pour les dépendances Git, cliquez sur **Force Build** pour réinstaller. - **Pas de cache d'image.** Les workers préconstruits et la mise en cache d'images pour les actions ne sont pas disponibles aujourd'hui (contrairement aux images Notebook préconfigurées : Base, Data Science, PySpark, TensorFlow). - **Autosave et versions.** L'édition d'une action est toujours en mode autosave. Pour éviter d'affecter la production, créez une nouvelle [version](#utiliser-le-système-de-contrôle-de-version-de-la-platform) : elle devient la _dernière version_ modifiable, tandis que la _version déployée_ reste figée. :::info Pour minimiser les reconstructions, regroupez les dépendances partagées dans un **Environment** réutilisable plutôt que de les redéclarer pour chaque action. ::: ## Aller plus loin Si vous avez besoin d'une formation ou d'une assistance technique pour la mise en oeuvre de nos solutions, contactez votre commercial ou cliquez sur [ce lien](https://www.ovhcloud.com/fr/professional-services/) pour obtenir un devis et demander une analyse personnalisée de votre projet à nos experts de l’équipe Professional Services. Posez vos questions, faites-nous part de vos commentaires et interagissez directement avec l’équipe qui développe la Data Platform sur le [canal Discord](https://discord.gg/ovhcloud) dédié. Si vous avez besoin d'une assistance concernant vos services OVHcloud, créez une demande depuis notre [centre d'aide](https://help.ovhcloud.com/csm?id=csm_get_help). Rejoignez notre [communauté d'utilisateurs](https://community.ovhcloud.com/).