Pourquoi Neos demande toujours avant d’écrire

Il existe deux façons de brancher un assistant sur un espace de travail. La première consiste à le laisser agir et à montrer ce qu’il a fait ; la seconde, à lui faire annoncer ce qu’il va faire et à attendre. Elles se ressemblent sur une démonstration. Elles n’ont rien à voir le jour où l’assistant se trompe.

Lire est libre, écrire ne l’est pas

Neos consulte sans rien demander : les tâches en retard, le document du devis, l’agenda de la semaine. La lecture n’abîme rien, et exiger une confirmation pour chaque question rendrait l’assistant plus lent que l’interface qu’il est censé raccourcir.

Toute création, modification ou suppression, en revanche, passe par une carte : ce qui va être fait, sur quoi, et deux boutons. Vous acceptez, vous corrigez la proposition, ou vous refusez — action par action, jamais en bloc.

Il n’a jamais plus de droits que vous

La confirmation ne suffirait pas seule : quelqu’un peut accepter par réflexe. Neos agit donc avec **vos** permissions, pas avec les siennes. Ce que votre rôle ne vous autorise pas à faire, il ne peut pas le faire non plus ; ce que vous n’avez pas le droit de voir, il ne le lit pas. Les droits sont appliqués côté serveur, au même endroit que pour l’interface et l’API — il n’y a pas de chemin de contournement, parce qu’il n’y a pas de second chemin.

Ce que ça coûte, et pourquoi ça les vaut

Ça coûte un clic. C’est réel, et c’est le prix à payer pour qu’un assistant soit utilisable sur des données qui comptent — celles d’une équipe, pas d’un bac à sable. Un assistant qu’on n’ose pas laisser écrire ne sert à rien ; un assistant qui écrit sans demander finit par ne plus être lancé du tout.

C’est la même logique que pour la reprise : Neos se souvient du fil en cours, donc « ouvre-la » suffit après avoir parlé d’une tâche. Le contexte raccourcit la demande ; la confirmation, elle, ne se raccourcit pas.