Propositions et validation

Vue d’ensemble

Lorsqu’ElevenAgents Architect termine une modification, il vous la remet sous forme de proposition : une branche qui contient la modification, des tests démontrant son bon fonctionnement et une proposition de fusion demandant la fusion de cette branche dans main. Cette page explique le fonctionnement de chaque élément, où le trouver et comment une proposition passe d’une conversation au trafic réel.

Qu’est-ce qu’une proposition ?

Une proposition s’appuie sur le modèle existant de gestion des versions :

La proposition de fusion est une proposition de fusion ElevenAgents standard, du même type que celle qu’un collègue ouvre manuellement. Ce n’est pas un type d’objet distinct.

Une proposition de fusion couvre exactement une branche source et une branche cible ; une proposition contient donc une solution candidate. Pour comparer plusieurs options, demandez à Architect de placer chacune sur sa propre branche. Chaque branche dispose alors de sa propre proposition et vous pouvez répartir le trafic entre elles dans le cadre d’une expérience.

Création d’une proposition

Architect crée une proposition lorsque vous lui demandez de corriger ou d’améliorer un élément, ou lorsque vous lui transmettez un test en échec, une conclusion Spotlight ou un ticket de triage. La séquence complète, avec les outils appelés par Architect à chaque étape, est décrite dans l’exemple détaillé. En résumé :

1. Architect analyse la situation, crée une branche et prépare la modification dans votre brouillon sur cette branche.
2. Architect écrit des tests et des simulations pour la modification, puis les exécute dans la conversation avant de vous présenter le résultat.
3. Architect ouvre la boîte de dialogue de publication. Vous examinez le diff et sélectionnez Publier, ce qui valide la modification comme nouvelle version sur la branche.
4. Architect ouvre une proposition de fusion vers main et rédige sa description à partir des commits et exécutions de tests réels de la branche.
5. Architect vous propose d’envoyer une petite part du trafic réel vers la branche pendant l’examen de la proposition. Cette action nécessite votre approbation.

Vous pouvez vous arrêter à n’importe quelle étape. Une branche dotée d’une version publiée mais sans proposition de fusion reste utile : vous pouvez la tester vous-même ou ouvrir une proposition ultérieurement.

Validation dans la conversation

Architect écrit et exécute les tests pendant la création de la modification, et non dans une étape distincte que vous lancez ensuite. Pour une correction, un schéma utile consiste à montrer que les nouveaux tests échouent sans la modification et réussissent avec elle. Architect peut exécuter les mêmes tests sur la branche d’origine et sur le brouillon qui contient la modification.

Architect n’exécute pas automatiquement cette vérification avant-après pour chaque modification. Demandez-la lorsqu’elle est importante, par exemple : « Montrez-moi la nouvelle simulation qui échoue sur main et réussit sur la branche, puis ouvrez une proposition. »

Un test réussit lorsque toutes les conditions de réussite sont remplies. Pour un test LLM, la réponse de l’agent satisfait les critères de réussite. Pour un test d’appel d’outil, l’outil attendu est appelé avec les paramètres attendus. Pour une simulation, la conversation simulée remplit ses conditions de réussite. Pour vérifier la stabilité des résultats, demandez à Architect d’exécuter les tests plusieurs fois. Il peut répéter chaque test jusqu’à 50 fois et communiquer le taux de réussite.

Consultez Tests pour savoir comment chaque type de test est défini.

Où trouver les propositions

Ouvrez l’agent, puis accédez à Contrôle de version > Propositions. La liste peut être filtrée par statut, par auteur (Créé par) et par réviseur (En attente d’examen par, Examiné par). Une proposition ouverte par Architect dans votre conversation vous indique comme auteur.

Architect renvoie également un lien vers la proposition dans la conversation dès sa création.

Anatomie d’une proposition

La page d’une proposition affiche les branches source et cible, son statut, la possibilité de la fusionner et l’écart de retard ou d’avance de la branche source par rapport à la cible. Elle comporte les onglets suivants :

Examen et fusion

Statuts

Une proposition de fusion possède l’un des statuts suivants :

Lorsqu’une proposition est ouverte, le dernier examen de chaque réviseur est soit Approuvé, soit Modifications demandées. Il n’existe pas de statuts distincts « testé » ou « prêt pour examen ». Les résultats des tests sont affichés dans l’onglet Exécutions de tests.

Les examens et les commentaires apparaissent dans la chronologie d’activité de l’onglet Vue d’ensemble, à côté de chaque nouvelle version validée sur la branche source.

Qui peut approuver et fusionner

• Toute personne disposant d’un accès éditeur à l’agent peut examiner une proposition, à l’exception de son auteur. Comme Architect agit en votre nom, vous ne pouvez pas approuver une proposition qu’Architect a ouverte dans votre conversation. Un collègue doit le faire.
• Une proposition peut être fusionnée dès lors qu’elle reçoit au moins une approbation d’une personne autre que l’auteur et qu’aucun dernier examen de réviseur n’est Modifications demandées. Les administrateurs du Workspace peuvent fusionner sans approbation.
• La fusion dans une branche protégée nécessite des autorisations d’administrateur ou l’approbation d’un administrateur.

Architect ne peut pas approuver, commenter, fusionner ni fermer une proposition de fusion. Ces étapes sont toujours réalisées par des personnes. Consultez Propositions de fusion pour connaître l’ensemble des règles d’examen.

Ce qui se passe lors de la fusion

Il n’y a pas d’étape de publication distincte après une fusion. La fusion crée une nouvelle version sur la branche cible et cette version traite immédiatement le trafic réel correspondant à la part de trafic reçue par la cible. Lorsque la cible est main et qu’aucune répartition de trafic n’est configurée, cela concerne tous les appelants.

La fusion :

• Transfère à la cible toute part de trafic réel détenue par la branche source.
• Archive la branche source par défaut.
• Ferme toute autre proposition ouverte provenant de la même branche.
• Résout le ticket de triage associé, s’il existe.

Déploiement progressif

Avant qu’une proposition ne soit fusionnée, vous pouvez envoyer une part du trafic réel vers sa branche afin que de vrais appelants testent la modification.

Les parts de trafic doivent toujours totaliser 100 %, et le routage est déterministe pour chaque conversation. Modifier la part d’une branche protégée, y compris en retirant du trafic à un main protégé, nécessite un administrateur. Consultez Déploiement du trafic.

Propositions proactives

Aujourd’hui, le parcours proactif consiste à utiliser Spotlight, puis à transmettre le résultat. Spotlight observe en continu les conversations de votre agent. Il produit un résumé hebdomadaire avec des analyses suggérées, déclenche des alertes en temps réel et recommande des modifications de configuration. Pour transformer une conclusion Spotlight en proposition :

Les tickets de triage fonctionnent de la même manière. Votre agent en production peut signaler des problèmes à examiner pendant les conversations, et Discuter avec Architect sur un ticket lance son analyse.

Des automatisations planifiées, avec des rapports envoyés dans une boîte de réception Architect, sont en cours de développement. L’onglet Boîte de réception de la page Architect leur sert d’espace réservé.