En bref
OpenDuet est un modèle sous licence MIT de CopilotKit pour créer un agent proactif auto-hébergé. Le projet en est encore à ses débuts. La question n’est pas seulement de savoir si un bot peut fonctionner en arrière-plan, mais à quel moment il doit demander une autorisation avant d’agir sur un système externe.
Introduction
Un agent qui attend une instruction est facile à interrompre : il s’arrête généralement lorsque l’utilisateur cesse de le solliciter. Un assistant proactif doit décider quand vérifier s’il y a du travail, quoi préparer, quand interrompre son propriétaire et quelles actions nécessitent une autorisation. Chaque décision implique un compromis entre confort, interruptions et risque.
CopilotKit a annoncé OpenDuet le 27 octobre comme un modèle auto-hébergé pour ce type d’assistant. L’entreprise décrit un résumé matinal, des vérifications en arrière-plan, une conversation persistante et un ordinateur séparé doté d’un navigateur. Elle indique que l’assistant demande l’accord de l’utilisateur avant certaines actions sensibles, comme l’envoi de messages ou la suppression d’éléments. Ce sont des affirmations du projet, et non les résultats d’un test de déploiement indépendant. (Source : CopilotKit — Introducing OpenDuet)
La proactivité est un flux de travail, pas une permission
Une façon utile d’évaluer l’architecture consiste à découper une tâche en étapes. Premièrement, un agent observe des informations autorisées, comme un calendrier. Deuxièmement, il interprète et hiérarchise. Troisièmement, il prépare une action proposée. Enfin, il peut agir sur un système externe. Ces étapes présentent des modes de défaillance différents et nécessitent des contrôles différents.
Par exemple, un brief matinal peut être erroné sans pour autant envoyer immédiatement un message au mauvais destinataire. Un brouillon de réponse peut être modifié avant l’envoi. Le passage du brouillon à l’envoi constitue donc un point naturel pour une approbation humaine, à condition que cette approbation soit liée au destinataire et au contenu exacts qui seront réellement envoyés.
L’annonce d’OpenDuet décrit la possibilité d’autoriser une action une seule fois, de toujours l’autoriser ou de la refuser. Cette souplesse est utile, mais une permission persistante crée une nouvelle responsabilité : la portée, l’expiration, la révocation et l’auditabilité doivent être claires. Une approbation pour une facture ne devrait pas devenir silencieusement l’autorisation de payer n’importe quelle facture. (Source : CopilotKit — OpenDuet announcement)
Auto-hébergé ne signifie pas sans dépendances
Le projet fonctionne sur OpenBot, avec des bots, des compétences et des paramètres propres à OpenDuet. Son dépôt indique qu’il est encore en début de développement et qu’il évolue activement. Il précise également que CopilotKit Intelligence est requis pour les fils de conversation et la mémoire, et qu’une clé est nécessaire pour démarrer le serveur. L’annonce mentionne une clé Intelligence gratuite ; les coûts des modèles et des services tiers sont des questions distinctes. (Source : OpenDuet — Repository)
Cette distinction est importante pour la planification de la confidentialité. Héberger une application sur sa propre infrastructure donne le contrôle sur certains composants, mais ne prouve pas que toutes les données y restent. Les opérateurs doivent examiner ce que reçoit le service requis, où vont les appels aux modèles, quels connecteurs détiennent des identifiants et quels journaux ou télémétries sont activés. Un schéma de déploiement est plus informatif que la seule expression auto-hébergé.
Le dépôt est distribué sous licence MIT. Cette permission s’applique au dépôt, et non automatiquement à chaque modèle, service ou connecteur qui y est intégré. (Source : OpenDuet — MIT license)
Concevoir une approbation qui résiste à la réalité
Une approbation robuste doit identifier qui l’a demandée, l’outil et le compte concernés, l’opération exacte proposée et la portée de toute permission future. Pour un message, afficher les destinataires et le contenu ; pour une suppression, afficher la cible ; pour un paiement, afficher le montant et la destination. Si des détails importants changent après l’approbation, l’autorisation doit être réexaminée.
Il s’agit d’une recommandation de conception, et non de l’affirmation qu’OpenDuet met en œuvre tous ces contrôles. Le projet décrit une frontière d’approbation et une piste d’audit, mais la description publiée seule ne constitue pas un audit de sécurité. Les concepteurs devraient tester les appels directs aux outils, les chemins de connecteurs alternatifs, les nouvelles tentatives et les redémarrages de l’agent afin de vérifier si la même politique s’applique de manière cohérente. (Source : OpenDuet — Repository)
L’ordinateur propre à l’agent constitue une autre frontière. Un navigateur peut améliorer la résilience lorsqu’un ordinateur portable est fermé, mais il élargit aussi la surface d’attaque : un contenu web non fiable peut tenter d’influencer ce que fait l’agent. Restreindre les identifiants, isoler l’environnement d’exécution et utiliser des comptes à privilège minimal restent nécessaires même lorsqu’une boîte de dialogue de confirmation existe.
Comment mesurer l’utilité sans récompenser le bruit
Un assistant proactif doit être jugé sur les résultats plutôt que sur le nombre de notifications qu’il génère. Suivez les alertes exploitables, les interruptions erronées, le temps gagné après vérification et les erreurs détectées avant exécution. Pour les approbations, suivez à la fois les actions risquées manquées et les actions routinières qui nécessitent à plusieurs reprises une intervention humaine.
Commencez par un accès en lecture seule et des flux de travail limités aux brouillons. Comparez le brief à ce que l’utilisateur avait réellement besoin de voir, puis élargissez la portée uniquement là où le bénéfice est évident. Conservez un chemin de retour arrière et examinez les permissions devenues persistantes. Un système qui demande une approbation si souvent que les utilisateurs cessent de lire n’est pas plus sûr simplement parce qu’il affiche une boîte de dialogue.
OpenDuet est une implémentation de référence intéressante précisément parce qu’elle rend visibles ces arbitrages produit. Sa valeur à long terme dépendra moins de la revendication d’autonomie que de la capacité des utilisateurs à comprendre, encadrer et annuler l’autonomie qu’ils accordent.
FAQ
OpenDuet est-il entièrement local ?
Pas par défaut selon la documentation : le projet nécessite une clé CopilotKit Intelligence pour les fils de conversation et la mémoire. Vérifiez la documentation actuelle et les flux de données avant le déploiement.
L’auto-hébergement supprime-t-il les coûts de modèle ?
Non. Les fournisseurs de modèles et d’autres services peuvent facturer séparément.
Les approbations remplacent-elles les tests de sécurité ?
Non. La frontière et tous les chemins vers les outils sensibles doivent encore être testés, en parallèle de l’isolation des identifiants et de l’environnement d’exécution.
Le dépôt est-il open source ?
Oui. Son dépôt utilise la licence MIT, tandis que les dépendances peuvent avoir des conditions différentes.
Pour aller plus loin
— The Agent Report