Sur cette page
Une conversation devient plus utile quand on peut revenir au travail qu’elle décrit. Elle devient aussi plus lourde de conséquences lorsqu’elle peut proposer de le modifier.
C’est là que je veux que l’interface ralentisse un peu. Répondre à une question et changer le projet sont deux opérations distinctes. Le modèle peut employer le même ton dans les deux cas ; le produit doit montrer la différence.
Agent entre en bêta dans le cadre de la préparation de Bisonflow 2.0. Il réunit les questions sur le projet, les instructions écrites et vocales, et les commandes sur les tâches soumises à validation. Le mot bêta est utile ici : je veux des essais réels, limités, et des retours sur le point où le résultat cesse d’être fiable.
Commencer par une question dont on connaît la réponse
Un bon premier essai porte sur un projet que vous connaissez. Demandez ce qui reste ouvert pour un jalon ou une explication de tâche à partir du contexte disponible.
Comparez la réponse au travail réel. A-t-elle trouvé le bon projet ? Distingue-t-elle les faits enregistrés des déductions ? Peut-on suivre les références ? Lorsqu’une information manque, le dit-elle ou contourne-t-elle le problème par du texte ?
Connaître la réponse n’est pas tricher. Cela permet d’évaluer l’assistant avant de lui poser une question qu’on ne peut pas facilement vérifier.
J’éviterais de commencer par « organise tout mon espace ». Cette demande cache trop de décisions sur les priorités, les responsables et les doublons. Une question précise donne un essai plus juste à la personne comme au produit.
Relire la commande exacte
Lorsqu’Agent propose une modification prise en charge, la revue doit montrer la cible et la mise à jour attendue. Relisez-la comme une petite revue de code : bonne tâche, bonnes valeurs, bonne instruction.
La commande approuvée passe par les contrôles serveur existants. L’approbation ne contourne ni l’appartenance à l’espace, ni les permissions du projet, ni les règles de facturation, ni la validation. Une relance de requête ne doit pas appliquer deux fois la même action approuvée.
Ces protections font partie de l’implémentation. Elles ne rendent pas toutes les suggestions correctes. On peut approuver une mauvaise modification et le modèle peut mal interpréter une demande ambiguë. D’où l’importance de la proposition visible.
Pour un premier essai de modification, choisissez une tâche sur laquelle une erreur serait facile à repérer et à corriger. Examinez-la ensuite. Un message de réussite dans le chat ne remplace pas la vérification de la tâche.
La voix doit laisser la même trace
Le micro est un moyen de donner une instruction, pas un autre niveau d’autorité. Le résultat doit rester dans la conversation pour permettre de lire l’action proposée.
La parole est parfois imprécise : deux tâches ont un nom semblable, ou une date est corrigée au milieu d’une phrase. Le système doit utiliser l’instruction finale et clarifier l’ambiguïté restante plutôt que choisir silencieusement une cible.
L’article sur la voix développe ce point. Le test central reste de savoir si parler a facilité un travail utile, y compris sa revue après la saisie.
Les retours utiles pendant la bêta
« La réponse était bizarre » est un début. Un retour exploitable précise la question, le projet actif, le résultat attendu et ce qu’Agent a réellement proposé ou répondu. Si une tâche est concernée, identifiez-la sans copier de contenu privé dans un signalement public.
Le contexte manquant compte aussi. Une clarification ciblée peut être préférable à une réponse immédiate. Reposer sans cesse une question sur une information déjà visible est un autre problème. Je veux trouver cette limite par l’usage plutôt que supposer qu’un ton assuré signifie que tout fonctionne.
L’accès et l’usage dépendent de l’offre et de la configuration actuelles de l’espace. La page des tarifs reste la référence pour ce qu’on peut acheter aujourd’hui. L’offre future envisagée ne change pas ces conditions.
Plus d’autonomie doit se démontrer
Le nombre de tâches qu’un modèle peut créer en une minute ne m’intéresse pas. Il est facile de fabriquer un backlog chargé.
Je veux savoir si vous avez accepté le bon changement, refusé le mauvais et compris le résultat. Si cette boucle fonctionne, Agent pourra prendre en charge du travail plus utile. Sinon, ajouter des outils agrandirait le problème.
Commencez petit, examinez le résultat et gardez les décisions importantes. C’est ainsi que je souhaite voir utilisée cette bêta.
