> 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/workflow-concepts/testing-and-iteration.md).

# Tests et itérations

Bonnes pratiques pour tester et itérer votre workflow

Les tests et les itérations sont des étapes fondamentales pour créer un workflow prêt pour la production. Dans cette section, nous présenterons les meilleures pratiques pour tester et itérer sur votre workflow.

## Mode de test gratuit

AirOps fournit **50 000 tâches de test gratuites par mois** pour les tests dans le Studio. Vous pouvez utiliser les tâches de test pour les tests de workflow et les exécutions lancées depuis l’éditeur de Playbook.

{% hint style="info" %}
Les tâches de test sont disponibles pour tous les espaces de travail et sont distinctes de votre allocation de tâches de production. Les tests de workflow et les exécutions de l’éditeur de Playbook utilisent d’abord les tâches de test, puis les tâches de production une fois le solde des tâches de test épuisé.
{% endhint %}

## Comment tester votre workflow

Il existe deux façons de tester votre workflow : étape par étape ou toutes les étapes en même temps.

Lorsque vous testez une étape à la fois, la valeur de chaque étape sera mise à jour. **Lorsque vous testez toutes les étapes en même temps, les valeurs de chaque étape ne seront mises à jour que si l’exécution réussit. En revanche, les valeurs ne seront pas mises à jour si vous rencontrez une erreur.** Par conséquent, la bonne pratique consiste à toujours tester une étape à la fois jusqu’à ce que votre workflow soit prêt pour la production

### Tester une étape

<figure><img src="https://344527547-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FX2n5yPRPynbnWuO4SH0M%2Fuploads%2Fgit-blob-621eef10ef494b864c2427aeafb1fee71630d8eb%2FCleanShot%202025-02-27%20at%2006.34.40%402x.png?alt=media" alt=""><figcaption></figcaption></figure>

* **Commencez à l’étape Start :** pour commencer à tester un workflow, vous devez ajouter des valeurs à l’étape de départ
* **Cliquez sur la flèche de la première étape :** cela n’exécutera que la première étape
* **Utilisez les journaux pour comprendre la sortie de l’étape afin de pouvoir la référencer dans les étapes futures :** les journaux sont essentiels pour comprendre la structure des données de la sortie de l’étape - utilisez cette sortie pour vous aider à faire référence à cette étape dans les étapes suivantes
* **Concevez l’étape ou les étapes suivantes :** continuez à concevoir votre workflow en faisant référence aux étapes précédentes à l’aide du bouton d’assistance des variables rose
* **Continuez à tester chaque étape suivante :** après avoir conçu une étape, cliquez sur le bouton de lecture pour tester l’étape. Continuez ce processus jusqu’à ce que vous disposiez d’un workflow prêt pour la production

### Tester les étapes dans les conditionnels

Vous pouvez déboguer des étapes individuelles à l’intérieur de branches conditionnelles (chemins vrai et faux). Cela facilite le test et l’itération sur des workflows complexes avec une logique de branchement :

1. Accédez à l’étape conditionnelle dans votre workflow
2. Développez la branche vraie ou fausse que vous souhaitez tester
3. Cliquez sur le bouton de lecture d’une étape individuelle dans la branche
4. L’étape s’exécutera en utilisant les valeurs de test actuelles, ce qui vous permettra de vérifier la logique de chaque chemin

### Testez l’ensemble de votre workflow

Il existe **deux options pour tester votre workflow de bout en bout :**

<table data-card-size="large" data-view="cards"><thead><tr><th></th><th data-hidden data-card-cover data-type="files"></th></tr></thead><tbody><tr><td><strong>Option 1 :</strong> Cliquez sur « Test Worfklow » depuis l’étape Inputs</td><td><a href="https://344527547-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FX2n5yPRPynbnWuO4SH0M%2Fuploads%2Fgit-blob-2e117b7990834bcd5e38ebceeed80967eaf0b0a8%2FCleanShot%202025-02-27%20at%2006.35.09%402x.png?alt=media">CleanShot 2025-02-27 at 06.35.09@2x.png</a></td></tr><tr><td><strong>Option 2 :</strong> Cliquez sur « Tester le workflow » en haut à droite du Studio</td><td><a href="https://344527547-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FX2n5yPRPynbnWuO4SH0M%2Fuploads%2Fgit-blob-d6d0fd12845d8c7e36765281369257aa8bc851ec%2FCleanShot%202025-02-28%20at%2005.56.46%402x.png?alt=media">CleanShot 2025-02-28 at 05.56.46@2x.png</a></td></tr></tbody></table>

{% hint style="info" %}
Utilisez la **fonction « Test Workflow »** lorsque votre workflow est prêt
{% endhint %}

* **Cliquez sur Test Workflow :** cliquez **fonction « Test Workflow »** dans le coin supérieur droit
* **Saisissez vos valeurs de test :** ajoutez les valeurs de test que vous souhaitez exécuter
* **Exécuter :** cliquez **Exécuter** pour tester l’ensemble du workflow

## Meilleures pratiques de gestion des erreurs

Lors de la création d’un workflow pour la production, il existe des cas limites que vous devriez tester et prendre en charge dans votre workflow avant de le déployer à grande échelle. N’oubliez pas non plus que vous pouvez toujours demander [l’aide de Copilot pour corriger les erreurs](/docs/fr/actions/workflow-concepts/chat-with-copilot/fix-errors-with-copilot.md) que vous rencontrez pendant les tests.

### 1. Limite de la fenêtre de contexte

Chaque modèle de langage de grande taille (LLM) dispose d’une fenêtre de contexte maximale, ce qui signifie qu’il existe un nombre maximal de jetons (ou de caractères) que votre prompt peut contenir avant de provoquer une erreur.

{% hint style="info" %}
1 jeton correspond généralement à environ 4 caractères et à environ 3/4 d’un mot.
{% endhint %}

1. Pour vous assurer que votre prompt reste dans les limites de la fenêtre de contexte, vous pouvez estimer le nombre de jetons que vous utiliserez en copiant-collant votre prompt dans le compteur de jetons OpenAI suivant : <https://platform.openai.com/tokenizer>
2. Pour gérer les cas limites où votre prompt dépasse la limite de jetons, vous pouvez utiliser la syntaxe Liquid suivante pour découper vos entrées ou les sorties d’étape en un fragment plus court : `{{step_1.output | slice: 0, 10000}}`où 10000 est remplacé par le nombre de caractères que vous souhaitez regrouper en segments.

### 2. Erreurs de formatage du prompt

De nombreux workflows de production basés sur des modèles de langage de grande taille dépendent d’un format de sortie cohérent du modèle. Pour garantir la cohérence dans votre workflow, envisagez les méthodes suivantes pour gérer les sorties inattendues du prompt :

1. **Techniques de prompt :**
   * Pour empêcher le modèle d’introduire sa réponse par une phrase telle que « *Bien sûr, voici un...* », vous pouvez ajouter une commande à la fois dans le **Système** et **Utilisateur** comme « *Fournissez votre réponse dans le format suivant et n’ajoutez aucun commentaire supplémentaire :*"
   * Si votre sortie est au format HTML ou JSON, pour empêcher le modèle de commencer par ` ```html ` ou ` ```json `, vous pouvez demander au modèle *« Commencez par #... »* ou *« Commencez par {, terminez par } et n’incluez pas ` ```json ` dans votre réponse »*
2. **Analyse de code :**
   * Si vous avez encore du mal à obtenir une sortie cohérente, ou si vous souhaitez gérer des cas extrêmes où elle peut s’écarter de la sortie attendue, vous pouvez utiliser du code pour extraire tout texte qui précède votre premier caractère.


---

# 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/workflow-concepts/testing-and-iteration.md?ask=<question>&goal=<user_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.
