> For the complete documentation index, see [llms.txt](https://docs.airops.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.airops.com/docs/fr/actions/playbooks/run-a-playbook.md). # Exécuter un Playbook Exécutez les Playbooks manuellement, depuis les Grids ou avec des déclencheurs Vous pouvez exécuter un Playbook manuellement depuis l’éditeur, depuis une grille, ou automatiquement avec un déclencheur. Chaque exécution crée une session avec les détails d’exécution et des artefacts. ## Exécuter manuellement Utilisez une exécution manuelle lorsque vous testez un Playbook ou lorsque vous l’exécutez pour un seul cas d’usage. 1. Ouvrez l’éditeur de Playbook. 2. Cliquez sur **Exécuter le Playbook**. 3. Fournissez les entrées requises. 4. Consultez la sortie de la session et les artefacts. {% hint style="info" %} Les exécutions lancées depuis l’éditeur de Playbook utilisent des tâches de test avant les tâches de production. Chaque espace de travail dispose de 50 000 tâches de test gratuites par mois, qui peuvent être utilisées pour les tests de Workflow et de Playbook. Si votre espace de travail utilise toutes les tâches de test, AirOps utilise des tâches de production pour les exécutions supplémentaires depuis l’éditeur. Vous pouvez consulter l’utilisation des tâches de test dans le **Utilisation** onglet. {% endhint %} ## Exécuter depuis une grille Utilisez une grille lorsque vous souhaitez exécuter un Playbook publié sur des lignes de données structurées. 1. Ouvrez la grille. 2. Cliquez sur **+ Ajouter une colonne**. 3. Sélectionnez le **Playbooks** onglet. 4. Recherchez le Playbook. 5. Associez les colonnes de la grille, des valeurs statiques ou des Brand Kits aux entrées du Playbook. 6. Exécutez le Playbook pour une ligne ou en masse. {% hint style="info" %} Lorsqu’un Playbook s’exécute depuis une grille, il utilise la version et les associations d’entrées configurées sur cette colonne de grille. Les modifications que vous apportez dans le chat de la session s’appliquent aux artefacts, pas au Playbook. Pour modifier le Playbook lui-même, ouvrez-le dans l’éditeur. {% endhint %} Voir [Exécuter des Playbooks dans la grille](/docs/fr/actions/grids/run-playbooks-in-grid.md) pour la sélection de version, les exécutions en masse, l’état de la session et la révision des artefacts. ### Revenir à la grille source Après avoir ouvert un Playbook depuis une grille, sélectionnez **Revenir à la grille** dans les actions rapides de l’éditeur pour revenir à la feuille d’origine. Si vous avez ouvert le Playbook directement, AirOps revient à sa grille liée ou propose un sélecteur lorsque plusieurs grilles sont liées. L’option est masquée lorsqu’il n’y a aucune grille liée active. ## Exécuter automatiquement Utilisez un déclencheur lorsque le Playbook doit démarrer selon un planning, à partir d’un événement externe ou d’un signal AirOps. Les types de déclencheurs incluent : * **Planification :** Exécutez selon une cadence récurrente. * **Webhook :** Exécuter à partir d’une requête HTTP. * **Surveillance :** Exécuter lorsque Parallel Web Systems détecte une condition à partir de votre requête de surveillance. * **AEO Insight :** Exécuter lorsqu’un seuil Insights activé est atteint. Les exécutions déclenchées apparaissent dans l’historique des exécutions. Les exécutions nécessitant une révision humaine apparaissent aussi dans la boîte de réception. {% hint style="info" %} Pour la configuration des déclencheurs, les paramètres de version et des exemples de charges utiles webhook, consultez [Déclencheurs de Playbook](/docs/fr/actions/playbooks/triggers.md). {% endhint %} ## Versions et modifications des entrées Les colonnes de la grille et les déclencheurs peuvent utiliser **par défaut** ou une version épinglée du Playbook. * **par défaut** suit la version publiée actuelle. * **Épinglé** continue d’utiliser la version sélectionnée jusqu’à ce que vous la modifiiez. {% hint style="warning" %} Si une nouvelle version du Playbook modifie les entrées, mettez à jour les associations de colonnes de grille et la configuration des entrées du déclencheur avant un passage à grande échelle. De nouvelles entrées requises sans valeurs mappées ou configurées peuvent faire échouer la validation des exécutions ou les faire ignorer. {% endhint %} ## Réviser les sessions Chaque exécution produit une session. Une session contient : * Le journal d’exécution complet. * Les entrées utilisées pour l’exécution. * Le modèle utilisé et ses détails de raisonnement, lorsqu’ils sont disponibles. * Chaque artefact produit par le Playbook. * L’état de révision humaine, lorsque le Playbook inclut des blocs de révision. Les sessions sont visibles dans **Historique des exécutions** depuis le coin supérieur droit de l’éditeur de Playbook et dans la boîte de réception lorsque la révision est requise. L’activité de la session montre également la progression de la révision. L’activité des réviseurs est regroupée sous la tentative de vérification qui l’a produite, tandis que les réparations effectuées par l’agent principal restent dans la chronologie principale. Vous pouvez consulter cette activité pendant une exécution ou après avoir actualisé la session. ## Collaborer sur les artefacts Les artefacts prennent en charge les commentaires, les suggestions, les mentions, l’historique des versions et les modifications assistées par l’IA. Utilisez ces contrôles lorsqu’une sortie de session doit être révisée avant la publication ou une utilisation en aval. Les modifications affectent l’artefact de cette session, pas les instructions du Playbook. Voir [Artefacts](/docs/fr/actions/playbooks/artifacts.md) pour la collaboration complète, la récupération, le lien stable et le workflow de grille. ## Interrompre ou relancer une session de grille Si une session est marquée **Archivée**, vous pouvez consulter son historique et ses artefacts, mais vous ne pouvez pas lui envoyer de nouveaux messages. Démarrez une nouvelle session pour continuer le travail. Dans une grille, les cellules du Playbook affichent l’état actuel de la session. Vous pouvez ouvrir la session depuis la cellule, interrompre une session en file d’attente ou en cours d’exécution, et relancer les sessions terminales. Si une session a été exécutée sur une version antérieure du Playbook, la cellule affiche un avertissement afin que vous puissiez la relancer sur la version actuelle. ## Utiliser deux Playbooks pour la surveillance et l’action De nombreuses configurations de Playbook utilisent un modèle à deux Playbooks. Le premier Playbook surveille les données et trouve du travail pour vous. Il peut s’exécuter sur un déclencheur, analyser les insights AirOps, identifier des opportunités et les envoyer vers une grille avec AirOps MCP, par exemple des URL à actualiser ou des prompts à cibler. Le second Playbook agit sur ces lignes et produit le résultat. Vous pouvez l’exécuter manuellement ou comme action de grille sur la ligne produite par le premier Playbook, par exemple pour rédiger un article de blog à partir d’un prompt cible ou actualiser une page existante. Un Playbook trouve le travail. L’autre Playbook fait le travail et vous mène à un résultat. Vous pouvez utiliser l’un ou l’autre modèle seul, mais ils sont souvent combinés. {% hint style="info" %} Un Playbook qui surveille des données utilise généralement la mémoire pour éviter de recommander à nouveau le même élément dans une fenêtre configurée, par exemple 60 jours. {% endhint %} --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.airops.com/docs/fr/actions/playbooks/run-a-playbook.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.