> 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/best-practices.md). # Bonnes pratiques Conseils pratiques pour créer des Playbooks fiables Utilisez ces bonnes pratiques pour rendre les Playbooks plus faciles à exécuter, à relire et à améliorer. ## Commencez par la couverture du Brand Kit et des prompts Un Brand Kit à jour et une couverture complète des prompts sont les deux principaux leviers de qualité. Vérifiez les deux avant d’optimiser la structure du Playbook. ## Commencez avec moins d’instructions Donnez à l’agent suffisamment de direction pour comprendre l’objectif, puis ajoutez des contraintes là où vous avez besoin d’un comportement prévisible. Des instructions trop prescriptives peuvent réduire la capacité de l’agent à raisonner face aux cas limites. ## Organisez les Sections par phase Utilisez des phases comme **Recherche**, **Brouillon**, et **Vérifier**. Évitez d’organiser les Sections autour des personnes, comme « Strategist Section » ou « Editor Section ». Une structure par phase est plus facile à réutiliser et à relire. ## Formatez chaque Section de manière cohérente Donnez à chaque Section une structure interne prévisible afin que l’agent comprenne l’objectif, que le relecteur puisse parcourir le travail rapidement et que les Sections en aval sachent quel Artifact utiliser. Une Section solide comprend généralement : * **Objectif :** Une ou deux phrases qui définissent ce que cette Section doit accomplir. * **Inputs et références :** Les champs Inputs, Artifacts, Brand Kit, les Tools ou les Knowledge Bases que la Section doit utiliser. Insérez-les via le menu oblique lorsque c’est possible. * **Instructions :** Des étapes numérotées pour le travail que l’agent doit effectuer. Concentrez-vous sur les décisions, les contraintes et les préférences de sources. * **Sortie :** L’Artifact que la Section doit rédiger, ainsi que le format requis, comme un rapport Markdown, une carte JSON ou un article final. Utilisez le même modèle dans toutes les Sections. Par exemple, une Section de recherche pourrait énoncer l’objectif, référencer le prompt cible et le Brand Kit, lister les étapes de recherche, puis écrire les conclusions dans **AI & Google Results.md**. Une Section de rédaction pourrait faire référence à **Content Outline.md** et **Topic Research.md**, lister les exigences de rédaction, puis écrire le brouillon dans **Article Draft.md**. ## Utilisez les Sections comme points de contrôle Ajoutez une Section lorsque vous avez besoin de : * D’un Artifact distinct. * D’une pause pour une relecture humaine. * D’un point de référence clair pour les Sections suivantes. ## N’écrivez des Artifacts que lorsque vous avez besoin de persistance Le contexte se transmet automatiquement entre les Sections. Utilisez des Artifacts lorsqu’un résultat doit être stocké, partagé ou référencé plus tard. ## Référencez les Knowledge Bases par leur nom Choisissez la Knowledge Base spécifique dans le sélecteur de Knowledge Base de l’étape. La sélection automatique ou une recherche dans toutes les Knowledge Bases peut récupérer depuis la mauvaise source. ## Référencez les Artifacts par leur nom Les noms des Artifacts sont stables. Les noms de fichiers peuvent changer. Utilisez le menu oblique pour insérer des références d’Artifact par nom dans les Sections suivantes. ## Séparez la publication de la création de contenu Utilisez les Playbooks pour créer, actualiser, relire et préparer le contenu. Publiez depuis une colonne Grid, un Playbook de publication séparé ou un CMS MCP après relecture. Cela permet de mieux contrôler la relecture éditoriale, le mapping des champs CMS et le suivi des publications. Lorsqu’un Playbook ou un CMS MCP publie ou actualise une page, utilisez l’AirOps MCP `track_aeo_page_content_update` avec l’URL de la page et le type de mise à jour afin qu’AirOps Insights puisse relier les futures évolutions de visibilité IA, de citations, de mentions et de trafic à cette mise à jour de contenu. ## Associez les Playbooks de détection d’opportunités et ceux de production de livrables Laissez un Playbook surveiller les données et repérer les opportunités, puis laissez un Playbook d’action distinct produire le résultat. Cela rend chaque Playbook plus facile à comprendre, à relire et à faire évoluer. ## Demandez à Quill de traduire les prompts de Workflow Lorsque vous migrez un Workflow, collez le prompt d’origine avec tout le contexte et demandez [Quill](/docs/fr/quill.md) de le traduire en une consigne concise pour l’agent. Raccourcissez ensuite le résultat. ## Faites relire les modifications proposées par un humain Des Playbooks bien conçus proposent des modifications pour validation humaine au lieu de les appliquer automatiquement lorsque le jugement est important. Ce modèle renforce la confiance, détecte les cas limites et tient les parties prenantes informées. --- # 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/best-practices.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.