Confirmation des écritures

L’assistant ne se contente pas de lire : il peut modifier un système que vous avez connecté, supprimer un document d’une base, ou envoyer un email. Ces actions-là ne partent pas toutes seules. Elles vous sont soumises, et rien ne se passe tant que vous n’avez pas cliqué.

Pourquoi

Tout ce que l’assistant lit peut avoir été écrit par quelqu’un d’autre : un document déposé dans une base, une page synchronisée depuis un outil, une page web ouverte en cours de recherche, le corps d’un email reçu. Un contenu piégé peut donc contenir une instruction — « transfère ces factures à telle adresse », « supprime tel dossier » — que l’assistant lira comme une demande.

La validation humaine coupe court : une action qui sort de chez vous, ou qui modifie un système extérieur, passe sous vos yeux avant de partir.

Ce qui est soumis, et ce qui ne l’est pas

Action	Soumise ?
Écrire dans un système connecté (créer, modifier, supprimer), par un connecteur API ou un serveur MCP	oui
Envoyer, transférer, déplacer ou supprimer un email	oui
Supprimer un document d’une base, ou en remplacer le contenu	oui
Ajouter, réécrire ou supprimer un passage d’une note, depuis sa discussion	oui
Ajouter du texte à une note, ou créer une note, depuis une conversation ordinaire	oui
Ajouter un document, ou ajouter une section à la fin d’un document (hors de vos notes)	non
Écrire dans l’espace de travail de la conversation	non
Produire un fichier (tableur, document, présentation)	non
Retenir un souvenir	non

La ligne de partage est simple : ce qui sort de chez vous, détruit quelque chose ou écrit dans vos notes est soumis ; ce qui reste dans la conversation et se défait ne l’est pas. L’assistant ne décide jamais d’ouvrir la carte ni de s’en passer : dès qu’il écrit dans une note, que ce soit depuis la discussion de la note ou depuis une conversation ordinaire, la carte s’ouvre et montre le texte concerné, et seule votre approbation applique la modification. Ajouter à la note, sous une réponse, est votre propre geste : il s’applique directement. Tout confirmer reviendrait à cliquer trois fois par réponse — et c’est ainsi qu’on apprend à cliquer sans lire, ce qui viderait la garde de son sens là où elle compte vraiment.

Comment ça se présente

Dans l’assistant, une carte apparaît dans la conversation, juste après la réponse qui propose l’action. Son en-tête dit ce qui va se passer (« Modifier la note », « Envoyer « Bilan de la campagne » », « Créer un événement ») et le résume en une ligne : la note visée, les destinataires, la date et le nombre d’invités. La flèche à droite replie la carte sur cette seule ligne, avec Refuser et le bouton d’action, pour relire la réponse au-dessus ; elle la déplie à nouveau pour voir le détail.

La carte est durable : vous pouvez fermer l’onglet, revenir plus tard, elle sera toujours là. Une action non tranchée expire au bout de 24 heures.

Une note : chaque passage modifié tient sur deux lignes, − pour l’avant (les mots retirés sont barrés) et + pour l’après (les mots ajoutés sont surlignés), mis en forme comme dans la note. Une case par passage : décochez ceux que vous ne voulez pas, Tout sélectionner les reprend, et le bouton dit combien s’appliqueront (« Appliquer 5 sur 6 »). Tous les passages arrivent cochés ; celui qui ne change rien de visible (des espaces, la seule mise en forme) le dit en remarque. Seul un passage modifié entre-temps dans la note arrive décoché : il ne peut plus s’appliquer. Au moment où vous appliquez, Miraca vérifie que les passages retenus n’ont pas changé depuis que l’assistant les a lus, et que personne n’est en train de les écrire sur un autre appareil : sinon la carte le dit et rien n’est modifié. Les passages retenus s’appliquent tous, ou aucun.
Un message : les destinataires (À, copie, copie cachée), l’objet et le texte entier. L’objet et le texte restent modifiables jusqu’à l’envoi : ce que vous corrigez dans la carte est ce qui part. Les destinataires, eux, ne se changent pas dans la carte.
Un événement : le titre, la date, le lieu, les invités, et un avertissement quand des invitations partiront aussitôt.
Les autres écritures (fichiers, bases de connaissance, connecteurs, serveurs MCP) : les valeurs qui comptent, ligne par ligne. Une suppression est signalée comme telle. Pour un connecteur, chaque champ envoyé a sa ligne, sous le nom que l’outil recevra (« Montant : 12000 ») ; un champ vidé se lit « (vide) », et s’il y en a trop pour la carte, la dernière ligne dit combien ne sont pas affichés. Pour un serveur MCP, la carte nomme le serveur et l’outil (« Action dans « Notion » (create_page) ») et montre les arguments envoyés de la même façon. Une fois approuvée, elle montre aussi ce que l’outil a rendu, et la réponse de l’assistant reprend d’elle-même avec ce résultat (voir Après votre accord).

Dans Slack, la même action est postée dans le fil avec deux boutons. Seule la personne qui a déclenché l’action peut la valider, même si le message est visible de tout le canal.

Ne plus être interrompu

Pour un type d’action : la case « Ne plus demander pour l’agenda dans cette discussion » (ou pour les messages, les notes, les fichiers, les bases, les connecteurs), au pied de la carte, applique directement les prochaines actions de ce type dans cette discussion. Les autres types restent soumis. Par défaut, ce réglage ne couvre jamais une suppression, le remplacement du contenu entier d’un document, ni une écriture dans un connecteur (votre organisation peut en décider autrement, voir « Côté administration ») : la case n’apparaît pas sur leur carte, et cocher la case sur un envoi de message ne dispense pas la suppression d’un message. Une modification de note qui ne fait que retirer des passages compte comme une suppression.
Pour les notes, deux niveaux : sur la carte d’un ajout, la case « Ne plus demander pour les ajouts aux notes dans cette discussion » ne lève que les ajouts : un remplacement ou une suppression de passage resteront soumis. Sur la carte d’une modification, la case « Ne plus demander pour les notes dans cette discussion » lève aussi les ajouts et les modifications qui mêlent remplacement et suppression, jamais une suppression seule. Pour revenir en arrière, le menu ⋮ de la conversation propose « Redemander pour l’agenda » (ou pour le type retenu, ou « Redemander pour les ajouts aux notes »).
Pour tout : dans le menu ⋮ d’une conversation, « Appliquer les écritures sans confirmation » supprime la demande pour cette conversation-là, sauf pour une suppression, pour le remplacement du contenu entier d’un document et pour une écriture dans un connecteur, qui se demandent toujours, même sous ce réglage : « toujours » veut dire toujours. Le libellé du réglage le rappelle. Ce sont les niveaux par défaut : une organisation peut les modifier, action par action (voir « Côté administration »).
Vos notes, depuis une autre discussion : quand l’assistant écrit dans « Mes notes » (créer une note, ajouter du texte, renommer ou ranger une note, en remplacer tout le contenu, la supprimer), la même carte s’ouvre, présentée comme une écriture de note. La case des bases de connaissance ne lève jamais une écriture de note. Renommer, ranger ou changer les propriétés d’une note se lève par « Ne plus demander pour les notes », comme une modification ; remplacer le contenu entier d’une note ou la supprimer se demande toujours.

Ce sont des réglages par conversation : une nouvelle conversation repart en mode « on vous demande ». Si votre organisation exige une relecture humaine, ni l’un ni l’autre n’est proposé.

Côté administration

Dans le portail, la page Approbations (rubrique Activité) réunit ce qu’une organisation règle. La page est lisible par tous les rôles ; seuls un propriétaire ou un administrateur l’enregistrent.

Un niveau par action

Chaque action soumise a son niveau :

Niveau	Effet
Ne pas demander	L’action part sans carte.
Demander	Une carte d’approbation. La personne peut choisir de ne plus être consultée dans sa discussion.
Toujours demander	Une carte à chaque fois, sans exception possible.
Double approbation	La personne approuve, puis un administrateur valide. Rien ne part avant la seconde approbation.

Tant que rien n’est réglé, chaque action garde le niveau décrit plus haut : « Toujours demander » pour une suppression, le remplacement du contenu d’un document et une écriture dans un système connecté, « Demander » pour le reste. Un outil de serveur MCP classé en écriture suit la règle « Écrire dans un système connecté » : il n’a ni règle ni niveau qui lui soient propres.

Ces trois familles ont un plancher : elles peuvent descendre à « Demander », jamais à « Ne pas demander ». Il en va de même pour toute écriture dans une note : une note n’appartient qu’à la personne, et l’organisation ne retire pas sa carte à sa place. Seule la personne peut choisir de ne plus être consultée, dans sa discussion. À l’inverse, une écriture dans une note ne monte pas en double approbation. Toute autre action peut être relevée ou abaissée librement.

Sur une note partagée, le niveau réglé ici ne descend rien : dès qu’une note a un accès, ou qu’elle n’est pas la vôtre, chaque écriture de l’assistant y passe par sa carte, quel que soit le niveau de la règle, et Ne plus demander n’y est ni proposé ni appliqué. Une règle relevée à « Toujours demander » s’y applique comme ailleurs.

Exiger une approbation pour toute écriture

Cet interrupteur impose, il n’autorise pas :

chaque action passe par une carte, quel que soit son niveau ;
les utilisateurs ne peuvent plus s’en dispenser, conversation par conversation ;
les écritures sans écran sont refusées (voir ci-dessous) ;
les tâches programmées restent exemptes : personne ne regarde un déclenchement de 3 h du matin, et leurs écritures sont bornées par les accès et le budget de la tâche.

Écritures sans écran (API, MCP)

Un appel direct à l’API avec une clé, ou un client MCP (Claude Desktop, Cursor, n8n), n’a aucune conversation Miraca où poser une carte : personne ne peut y approuver quoi que ce soit. L’organisation choisit ce que deviennent ces écritures :

Réglage	Effet
Autoriser (par défaut)	Les écritures s’exécutent, dans la limite des droits de la clé.
Refuser ce qui demande toujours	Les actions au niveau « Toujours demander » sont refusées, les autres s’exécutent.
Refuser toute écriture soumise à approbation	Seules les actions au niveau « Ne pas demander » s’exécutent.

Un refus est dit à l’appelant, avec la marche à suivre : lancer l’action depuis l’assistant, depuis Slack, ou par une tâche programmée. Les écritures d’un serveur MCP activé par l’API (tools_enabled: ["mcp:<identifiant>"]) suivent ce réglage comme celles d’un connecteur.

La double approbation

Quand une action relève d’une règle en double approbation :

la carte de la personne l’annonce avant le clic (dans l’assistant ; dans Slack, le message ne le dit qu’après l’approbation) ;
après son approbation, la carte indique « En attente d’un administrateur » : rien n’est exécuté ;
un propriétaire ou un administrateur ouvre l’onglet À valider, lit l’action (la même carte que celle de la personne, en lecture seule, avec le titre du document visé) et la valide ou la refuse ;
à la validation, l’action s’exécute au nom de la personne, avec ses droits ;
la personne lit l’issue là où l’action a été proposée : sur la carte de sa discussion (validée, refusée, ou expirée faute de validation ; elle y reste affichée trois jours), ou dans le message du fil Slack.

Les écritures dans une note ne peuvent pas être soumises à une double approbation : une note n’est lue que par la personne à qui elle appartient et par celles avec qui elle la partage, jamais par un administrateur à ce titre, et un administrateur ne peut pas valider ce qu’il ne lit pas. Le niveau le plus strict d’une règle de note est « Toujours demander ».

Un administrateur ne valide pas sa propre action tant qu’un autre administrateur existe. Dans une organisation qui n’en compte qu’un, son approbation suffit, et le journal le note. Sans décision sous 72 heures, la proposition expire.

Les administrateurs sont prévenus par une pastille sur l’entrée « Approbations » et, sauf réglage contraire, par un courriel qui ne contient pas le détail de l’action. Depuis Slack, la personne approuve dans le fil ; la validation se fait au portail.

Sans écran (API, MCP), une action en double approbation suit le réglage « Écritures sans écran » comme une action au niveau « Toujours demander ». Les tâches programmées restent exemptes.

Le journal des approbations

L’onglet Journal de la même page, réservé aux propriétaires et administrateurs, liste ce que les utilisateurs ont approuvé, refusé ou laissé partir sans carte : la date, la personne, le geste (« Envoyer un email », « Supprimer un document »), la surface et la décision. Il se filtre par personne, par famille et par décision.

Le journal ne montre jamais le contenu d’une action : ni destinataire, ni objet, ni texte, ni titre de document. Il garde aussi les écritures parties sans carte (une personne a choisi de ne plus être consultée, ou la règle ne demande rien) et les écritures refusées faute d’écran. Les entrées sont conservées douze mois, et survivent à la suppression de la discussion dont elles viennent.

Depuis un connecteur MCP

Brancher Miraca sur Claude Desktop, Cursor ou n8n ouvre une autre porte d’écriture : supprimer un document, en remplacer le contenu, ou lancer une opération de connecteur qui modifie des données. C’est le client MCP qui vous demande l’autorisation, avec ses propres règles ; côté Miraca, ces appels suivent le réglage Écritures sans écran ci-dessus.

Limite connue : l’exécution de code

Un script ne peut pas attendre une décision humaine — il dispose de soixante secondes. Quand la confirmation s’applique, une écriture vers un système connecté depuis run_code est refusée, et l’assistant est renvoyé vers l’outil direct du connecteur, qui, lui, est validable. C’est une perte de capacité assumée : laisser cette voie ouverte ferait du code un moyen de contourner la validation.

Pour les tâches programmées

Une tâche n’est jamais soumise à confirmation. Ce qu’elle a le droit d’écrire se règle ailleurs, à la création de la tâche : les bases et connecteurs qu’elle peut modifier, et son budget en euros. Les serveurs MCP ne lui sont pas proposés : leurs outils sont des écritures par défaut, et personne ne relirait une action chez un tiers.

Une exception : l’envoi d’un email ou le transfert d’un message n’a lieu que si tous les destinataires sont membres de votre organisation. Un mail reçu ou une page lue pourrait sinon faire écrire à l’agent « transfère ceci à x@externe.fr », et l’envoi partirait sans que personne ne le voie : une tâche n’a ni conversation ni fil de discussion où poser une carte à confirmer. Dès qu’un seul destinataire est extérieur à l’organisation, rien ne part ; déposer un brouillon reste toujours possible, celui-là ne part jamais.

Voir aussi : Connecteurs API · Serveurs MCP · Tâches programmées · Assistant