> This is a page from the ElevenLabs documentation. For a complete page index, fetch https://elevenlabs.io/docs/llms.txt. For the full documentation in a single file, fetch https://elevenlabs.io/docs/llms-full.txt.
# Fonctionnement d’ElevenAgents Architect
## Vue d’ensemble
Une conversation avec ElevenAgents Architect se déroule comme une conversation ElevenAgents en temps réel, sur le même moteur que celui qui alimente les agents que vous créez. Les outils d’Architect s’exécutent dans votre navigateur, au sein de votre session connectée. Chaque outil appelle les mêmes API ElevenAgents que le Dashboard, afin que chaque lecture et écriture soit vérifiée selon vos propres autorisations. Consultez [Autorisations, approbations et brouillons](/docs/fr/eleven-agents/operate/architect/authentication).
## Ce qu’ElevenAgents Architect sait par défaut
Au début de chaque conversation, Architect reçoit :
* **Votre compte et votre Workspace** : votre forfait, votre Workspace et votre utilisation.
* **Votre emplacement** : la page ouverte et, lorsque vous êtes dans un agent, cet agent ainsi que la branche que vous consultez. Dans la barre latérale, Architect reçoit également un instantané de la page, puis une mise à jour avant chaque message si la page a changé.
* **Un résumé de l’agent** : créé par ElevenLabs lorsque vous êtes dans un agent. Il couvre le nom et le propriétaire de l’agent, ses branches et leur répartition du trafic, le volume d’appels des 7 derniers jours, l’état du brouillon, les agents connectés, les procédures, la présence ou non de tests configurés, et les branches que vous pouvez modifier.
* **Le contexte de l’agent** : le document `agents.md` de l’agent, partagé avec toutes les personnes qui le créent. Consultez [Personnaliser Architect](/docs/fr/eleven-agents/operate/architect/customization).
* **Vos préférences** : votre document personnel `user.md`, qui s’applique à tous les agents que vous créez.
* **Le contexte transmis par le point d’entrée** : par exemple, les tests en échec, le constat Spotlight ou le ticket de triage. Consultez [Démarrer une conversation](/docs/fr/eleven-agents/operate/architect/entry-points).
* **Les messages précédents de ce chat.**
Architect ne démarre **pas** avec la configuration complète de l’agent, ses transcriptions, ses résultats de test, ses données Spotlight ou vos autres chats Architect. Il les lit à l’aide d’outils lorsque la tâche le nécessite. Ainsi, chaque conversation reste ciblée et Architect travaille toujours à partir de données actuelles, et non d’une copie obsolète.
## Investigations et instructions directes
Architect traite différemment deux types de demandes.
Les **instructions directes** indiquent la modification à apporter, par exemple « Ajoute une règle de sécurité qui bloque les discussions sur les tarifs des concurrents » ou « Raccourcis le premier message ». Architect lit la configuration concernée, effectue la modification et indique ce qu’il a préparé. Dans le mode d’approbation par défaut, les modifications de la configuration de l’agent sont préparées dans un brouillon sans vous demander votre accord. Les actions qui affectent le trafic en direct ou les ressources partagées attendent votre approbation.
Les **investigations** posent une question sans indiquer de correctif, par exemple « Pourquoi les appels concernant les remboursements sont-ils transférés ? » ou « Comment améliorer le traitement des remboursements ? » Architect effectue des recherches avant toute modification :
* Il rédige une **liste de tâches** pour l’investigation, qui reste visible au-dessus du champ de saisie à mesure que les éléments sont terminés.
* Il commence par des indicateurs peu coûteux, tels que le nombre de conversations, les thèmes et les résultats d’évaluation, avant de lire les transcriptions individuelles.
* Il analyse les conversations en parallèle et regroupe ses constats par cause racine.
* Son raisonnement est visible. Chaque étape de raisonnement se réduit sous la forme **Réflexion pendant Ns** et peut être développée.
* Il présente ses conclusions, y compris le nombre de conversations qu’il a effectivement lues. Il ne présente pas un échantillon comme exhaustif.
### Mode Plan
Pour les modifications plus importantes, passez le champ de saisie en mode **Plan** (appuyez sur Shift+Tab pour parcourir les modes). En mode Plan, Architect effectue ses recherches avec des outils en lecture seule, rédige un plan que vous pouvez suivre en temps réel, puis vous demande d’**Approuver le plan** ou de le **Rejeter**. Il n’apporte aucune modification avant votre approbation. Si vous rejetez le plan en ajoutant une note, Architect le révise et vous le soumet de nouveau.
Dans l’onglet Architect en plein écran, le plan apparaît dans un panneau au-dessus du champ de saisie. Dans la barre latérale, il apparaît sous forme de carte dans le chat.
## Exemple détaillé : améliorer le traitement des remboursements
Cet exemple suit une conversation unique, d’une question générale jusqu’à une modification prête à être examinée. Les noms des outils sont affichés pour vous permettre d’associer chaque étape à ce qui apparaît dans la conversation. Architect choisit lui-même ses étapes, une conversation réelle peut donc différer par son ordre et son niveau de détail.
La demande, envoyée depuis l’onglet Architect de l’agent :
> Comment améliorer le traitement des remboursements ?
#### Planifier l’investigation
Architect rédige une liste de tâches (`write_todos`) : mesurer le problème, trouver les conversations
de remboursement en échec, identifier les causes racines, proposer et tester un correctif.
#### Mesurer le problème
Architect lit les thèmes de l’agent (`get_agent_topics`, `get_topics_summary`) pour trouver le thème des remboursements
et son taux de réussite, puis compte et liste les conversations récentes de remboursement ayant échoué à
l’évaluation (`count_conversations`, `list_conversations`).
#### Lire les conversations
Architect recherche les demandes de remboursement dans les transcriptions (`search_conversation_messages`,
`semantic_search_conversations`), puis analyse en parallèle un lot de conversations en échec
(`analyze_conversation_subagent`). Chaque analyse indique ce que l’utilisateur souhaitait, où l’agent
s’est trompé et à quel tour cela s’est produit.
#### Identifier la cause racine
Architect compare les échecs avec la configuration actuelle (`get_agent_config`,
`list_procedures`, `get_procedure`). Il présente un constat tel que : « Dans 31 des 40 appels de remboursement
en échec, l’agent a appelé `lookup_order` avant de demander le numéro de commande, a reçu une erreur, puis
a transféré l’appel. »
#### Apporter la modification sur une branche
Architect crée une branche (`create_branch`) afin d’isoler la modification de l’agent en production. Il
modifie ensuite la procédure de remboursement (`update_procedure`) pour demander le numéro de commande avant la
recherche. La modification est préparée dans votre brouillon sur cette branche. Rien n’a changé pour les appelants en direct.
#### Rédiger des tests pour la modification
Architect rédige des tests qui reproduisent l’échec : une simulation d’un appelant demandant un remboursement
sans fournir de numéro de commande (`create_simulation_test`), un test d’appel d’outil vérifiant que
`lookup_order` n’est pas appelé en premier (`create_tool_test`), et un test généré à partir de l’une des
véritables conversations en échec (`generate_test_from_conversation`). Architect simule les outils ayant des
effets secondaires dans les simulations, afin qu’aucun remboursement réel ne soit émis.
#### Exécuter les tests avant et après
Architect exécute les tests sur l’agent sans la modification (`run_tests` sur la branche d’origine,
ou `run_agent_tests` avec `include_draft: false`), puis sur le brouillon incluant la modification
(`run_agent_tests`), et lit les résultats (`get_test_suite_summary`,
`get_test_suite_failures`). Le résultat attendu est que les nouveaux tests échouent sans la modification
et réussissent avec elle. Si les tests échouent encore, Architect lit les échecs, ajuste la modification et
les exécute à nouveau.
#### Présenter la modification
Architect résume la cause racine, la modification et les résultats des tests, puis ouvre la boîte de dialogue de
publication (`request_draft_publish`). Vous examinez le diff et sélectionnez **Publier**, ce qui valide la
modification comme nouvelle version sur la branche. Architect ne peut pas publier à votre place.
#### Ouvrir une proposition
Architect lit l’historique de la branche et l’aperçu de fusion (`get_branch_history`,
`merge_branch_preview`) et ouvre une proposition de fusion vers `main` (`create_merge_proposal`). La
description comprend trois sections, **Résumé**, **Tests** et **Comment examiner**, rédigées à partir des
validations et exécutions de tests réelles. Architect peut suggérer des examinateurs
(`suggest_merge_proposal_reviewers`), mais vous les choisissez.
#### Proposer un déploiement progressif
Architect propose d’envoyer une faible part du trafic en direct, généralement 5 %, vers la branche pendant l’examen de la
proposition (`set_traffic_split`). Cette action modifie le trafic en direct, elle attend donc votre
approbation.
La validation s’effectue dans la conversation, avant qu’il vous soit demandé de publier ou d’examiner quoi que ce soit. Lorsque la proposition parvient à un examinateur, les tests ayant motivé la modification sont déjà associés à l’agent et ont été exécutés sur la branche. Consultez [Propositions et validation](/docs/fr/eleven-agents/operate/architect/proposals) pour savoir ce que voit l’examinateur.
> **Tip**
>
> L’exécution des tests avant et après est une bonne pratique, mais Architect ne l’effectue pas automatiquement pour
> chaque modification. Pour vous en assurer, demandez-le directement, par exemple « Montre-moi les nouveaux tests
> qui échouent sur main et réussissent sur la branche. »
## Commandes slash
Saisissez `/` dans le champ de saisie pour afficher les commandes disponibles sur la page actuelle.
| Commande | Description |
| ------------- | ------------------------------------------------------------------------------------------- |
| `/start` | Configure le contexte de cet agent (`agents.md`) afin qu’Architect connaisse vos objectifs. |
| `/generate` | Génère un nouvel agent à partir d’une description. |
| `/debug` | Débogue les conversations récentes en échec. |
| `/test` | Exécute les tests et résume les résultats. |
| `/explain` | Explique en langage clair le rôle de cet agent. |
| `/optimize` | Suggère des améliorations du prompt et de la configuration. |
| `/review` | Examine les performances de l’agent et identifie des améliorations. |
| `/branch` | Crée une nouvelle branche pour cet agent. |
| `/experiment` | Crée une branche et la déploie comme test A/B. |
| `/rollback` | Examine les récentes modifications de configuration et les annule si nécessaire. |
| `/remember` | Enregistre un fait pour l’agent sous forme de document de base de connaissances. |
| `/dashboard` | Crée un Dashboard d’analyses personnalisé dans le chat. |
| `/clear` | Efface cette conversation et recommence à zéro. |
| `/feedback` | Envoie à ElevenLabs des commentaires privés sur cette session. |
La plupart des commandes s’appliquent uniquement lorsque vous êtes dans un agent. `/clear` et `/feedback` ne sont pas disponibles sur la page d’accueil de l’onglet Architect.
## Dashboards dans le chat
Architect peut créer un Dashboard dans la conversation pour répondre à une question à l’aide de données, par exemple « Répartis les transferts de cette semaine par motif et montre-moi la tendance. » Utilisez `/dashboard` ou formulez directement votre demande.
Architect collecte les données avec ses outils, les structure avec du [code](#running-code), et affiche un Dashboard composé des mêmes tuiles de métriques, graphiques, listes et cartes de texte que Spotlight. Un Dashboard peut inclure :
* Des **tuiles de métriques** avec une valeur principale, une évolution et un mini-graphique.
* Des **graphiques** : aires, courbes, barres, aires empilées, anneaux et listes de barres classées pour les répartitions des N premiers éléments.
* Des **listes** avec des libellés d’état, des dates et des liens vers des pages d’ElevenAgents, telles que des conversations individuelles.
* Des **cartes de texte** pour les constats et recommandations.
Dans l’onglet Architect en plein écran, les Dashboards s’affichent directement dans la conversation. Dans la barre latérale, ils s’ouvrent dans un panneau à côté du chat.
Les données du Dashboard sont conservées uniquement en mémoire dans l’onglet du navigateur où il a été créé et ne sont jamais enregistrées avec le chat. Après le rechargement de la page, l’ouverture du chat dans un autre onglet ou la création de plusieurs Dashboards volumineux, un ancien Dashboard affiche un message à la place de ses données. Demandez à Architect de le reconstruire. Les Dashboards sont des instantanés en lecture seule. Ils ne comportent pas de filtres et ne sont pas mis à jour en direct.
## Exécuter du code
Architect peut exécuter de courts programmes Python pour compter, regrouper et comparer les données issues de ses outils, par exemple afin de calculer les taux de résolution par semaine sur quelques centaines de conversations. Le code s’exécute dans un environnement isolé de votre navigateur, uniquement avec la bibliothèque standard Python. Il n’a aucun accès au réseau ni à votre compte ElevenLabs, et sa durée d’exécution est limitée à 20 secondes. L’exécution de code est déployée progressivement et peut ne pas être disponible dans tous les Workspaces.
## Réponses volumineuses
Lorsqu’un outil renvoie davantage de données que la conversation ne peut en contenir, par exemple une longue liste de conversations, Architect conserve la réponse complète en mémoire dans l’onglet de votre navigateur et travaille avec un résumé. Il peut rechercher et lire le reste à la demande. Un avis sur l’appel d’outil indique lorsque cela se produit. Ces réponses ne sont jamais enregistrées ni téléversées.