Aller au contenu
Blaze

Agent IA · Monaco

Un agent d’entreprise, avec un mandat précis.

Un mandat, quatre contrôles

Schéma du parcours proposé, à construire et vérifier. Aucun dossier client ni service de production n’est représenté.

  1. Mandat

    Limiter les outils et les opérations

  2. Préparation

    Décrire l’action et son destinataire

  3. Confirmation

    Approuver une version précise

  4. Exécution contrôlée

    Vérifier les droits et constater le résultat

Un assistant qui répond à une question et un programme qui modifie un outil n’ont pas la même responsabilité. Pour un agent d’entreprise, la conception commence par le mandat : ce qu’il peut lire, préparer et exécuter. Blaze propose de définir cette frontière avec les équipes de Monaco avant de connecter un système réel. Les exemples de cette page sont des parcours à concevoir, pas des connecteurs déjà livrés.

Rendre l’action proposée concrète

Prenons une demande de document : l’agent pourrait chercher le dossier autorisé, identifier la pièce demandée et préparer une réponse. Il faudrait ensuite présenter au collaborateur le destinataire, la version exacte du document et le texte proposé. L’accord sur un brouillon ne doit pas donner implicitement le droit de lire d’autres dossiers ou d’ajouter des pièces à l’envoi.

Ce parcours oblige à distinguer consultation, préparation et exécution. Chacune doit disposer de permissions propres et produire un résultat compréhensible. Une phrase comme « occupe-toi du dossier » n’est pas un mandat exploitable : il faut préciser les opérations possibles, leurs limites et la personne qui peut les confirmer.

Appliquer les droits hors du modèle

Les permissions doivent être vérifiées par le système qui exécute l’action, même si l’interface ne montre que des choix autorisés. Un texte trouvé dans un document ou un message ne doit jamais devenir une instruction privilégiée. Les essais doivent donc inclure de fausses demandes de changement de destinataire, des pièces étrangères au dossier et une révocation des droits pendant la préparation.

Une action engageante doit être soumise avec ses conséquences concrètes. La validation porte sur cette version, puis l’exécution doit vérifier que les données et le mandat sont encore valables. Pour les décisions de vigilance, le professionnel décide toujours ; l’agent peut préparer une analyse, mais aucune configuration ne doit transformer sa suggestion en approbation juridique automatique.

Prévoir les résultats incomplets

Un connecteur dépend des interfaces officiellement disponibles, de leurs permissions et de leurs conditions d’usage. La première étude doit vérifier ces points pour chaque outil ; elle ne suppose pas que tout logiciel peut être connecté. Une exportation contrôlée ou un traitement manuel peuvent rester nécessaires lorsque l’interface est absente ou trop large.

Il faut aussi concevoir les interruptions : un délai dépassé ne signifie pas forcément que l’action a échoué. Avant de réessayer, le système doit pouvoir reconnaître une opération déjà exécutée pour éviter un double envoi. Le journal attendu relie demande, proposition, approbation et résultat, sans y recopier inutilement les données du dossier.

Évaluer une première tâche limitée

Un agent commence par un ensemble limité d’actions et des comptes clairement identifiés. Une première évaluation peut utiliser une messagerie ou des documents fictifs ; l’accès aux outils de travail s’introduit dans le périmètre convenu. L’équipe doit comprendre l’action proposée, les informations qui la motivent et le moment où une confirmation humaine est nécessaire. Cette visibilité concerne aussi les nouvelles tentatives et les services de secours, afin qu’une erreur n’élargisse pas discrètement les accès.

L’utilité doit être évaluée sur le temps de préparation et de contrôle, le nombre de propositions corrigées, les interruptions et les reprises. Le projet Vedetta prévoit des fonctions d’assistance pour toutes les professions concernées par la vigilance ; les intégrations restent à construire. Un démonstrateur d’agent ne doit pas être présenté comme une fonction de production disponible.

Examiner le périmètre

Proposition de service

Périmètre de service proposé

Découvrez comment nous cadrons une tâche d’IA, évaluons ses cas difficiles et concevons la revue avec les personnes qui utiliseront ses résultats.

Consulter la présentation

Texte revu le

Questions fréquentes

L'agent peut-il envoyer des e-mails à nos clients ?
Un parcours peut être conçu pour préparer un message et demander une confirmation sur son contenu, son destinataire et ses pièces. La capacité d’envoyer dépend ensuite d’un connecteur autorisé et testé. Cette page ne promet pas un accès existant à votre messagerie ni des envois autonomes.
Comment évitez-vous qu'un agent fasse n'importe quoi ?
Le contrôle repose sur des permissions appliquées côté système, une validation des actions engageantes et des essais qui provoquent des erreurs. Un journal aide à comprendre ce qui s’est passé, mais ne rend pas tout réversible : un message envoyé peut nécessiter une correction plutôt qu’une annulation.
Nos données servent-elles à entraîner un modèle ?
Aucune autorisation d’entraînement ne découle du projet. Avant l’usage d’un prestataire, il faut vérifier ses conditions de conservation et de réutilisation ainsi que les traitements permis. Les exemples actuels sont synthétiques ; les données réelles ne doivent pas être introduites pour simplement « voir si cela fonctionne ».

Poursuivre la lecture

Définir le bon périmètre

Un parcours, ses utilisateurs et les informations nécessaires : le point de départ d’un projet précis.

Contacter Blaze