Ce que Dinoer ne fait pas dans votre dos

Vous envisagez de donner à une chaîne de traitement de données l’accès à vos identifiants et au trafic sortant de votre machine. C’est une décision importante. Voici ce sur quoi cela repose, avec le fichier qui l’applique à chaque fois — et non pas notre simple affirmation.

Dinoer ne stocke jamais vos identifiants dans un terminal

Ils ne passent jamais par votre shell, votre historique de commandes ou les journaux de Dinoer.

→ lib/repertoire_chiffre.py — comment une information d’identification atteint réellement un formulaire →

La même règle vaut à l’intérieur d’evaluer : une action de scénario portant une valeur en clair sur un champ qui ressemble à password/secret est rejetée — action_secret_en_clair, vérifié avant même que le scénario n’atteigne Playwright, pas audité après coup.

Par défaut, ce que Dinoer écrit est masqué. Les valeurs de retour, les URL et les messages d’erreur qui passent par la sortie standard ou le journal des opérations sont neutralisés, sauf si vous demandez explicitement le contraire (--no-filtre-evaluer), auquel cas la sortie JSON en fait état.

→ lib/sanitisation.py

Ce que cela ne couvre pas : l’agent qui exécute Dinoer a son propre accès à votre machine. Si vous lui donnez un terminal, il peut lire votre répertoire monté comme n’importe quel autre fichier. Dinoer protège le chemin qu’il contrôle, et non celui que vous ouvrez à côté.

Le corpus est ce que le modèle délégué est autorisé à modifier

opencode.jsonc nie websearch/webfetch au modèle qui rédige votre rapport — il existe parce qu’une exécution réelle du 14 août 2026 a révélé le contraire : douze recherches actives, invisibles dans le texte final, qui puisaient du contenu que le corpus collecté ne contenait pas. Vérifié en capturant tout le flux d’événements du modèle, et non en se fiant à ce qu’il renvoyait.

→ opencode.jsonc, lib/modeles.py::invoquer_opencode()

Ce qui n’est pas couvert : bash reste autorisé — les scénarios réels en ont besoin —, et un modèle rejeté websearch a, lors d’une exécution de vérification, atteint le site web réel via bash curl. C’est la seule garantie sur cette page qui n’est pas absolue, et elle est nommée ainsi plutôt que arrondie à une valeur.

Cela ne dépend pas du répertoire depuis lequel vous le lancez. OpenCode lit opencode.jsonc depuis le répertoire dans lequel il est lancé, et le paquet .deb n’installe pas ce fichier. Depuis la 1.0.1, invoquer_opencode() définit donc elle-même le même refus, dans OPENCODE_CONFIG_CONTENT, fusionné avec toute valeur que vous aviez déjà. Mesuré le 25 septembre 2026 avec opencode debug config (OpenCode 1.18.32), lancé depuis /tmp avec cette valeur : websearch et webfetch sont deny, bash reste allow. Sans elle, depuis le même répertoire, les deux premiers sont allow — c’est pourquoi la valeur est définie à chaque appel plutôt que laissée au répertoire.

Ce que Dinoer rapporte, il ne le décide pas

pret_a_agir: false signifie une friction a été perçue — une signature WAF, un décalage de session, un plafond de navigation. Cela ne signifie pas je refuse de fonctionner. Dinoer rapporte ce qu’il a remarqué et vous laisse la décision.

La détection WAF est basée sur des mots clés et peut être incorrecte. Elle est signalée sous forme de nombre, jamais présentée comme une exception qui interrompt l’exécution, et --ignorer-waf est là pour le cas où vous avez vérifié et que c’était faux.

La nuance est plus importante qu’il n’y paraît. Un outil qui prêche sur le respect des règles d’accès devient un outil que l’on contourne, et un outil que les gens contournent cesse de rapporter quoi que ce soit du tout.

L’agent ne décide pas de ce qu’il fait, sauf une exception nommée

Chaque clic, chaque frappe, chaque navigation que le cœur du navigateur conservé effectue est une ligne écrite dans un fichier de scénario. Cette partie de Dinoer exécute une liste ; elle n’en crée pas une.

→ scenarios/schema.json

Le processus de recherche n’est pas la même chose. campagne.py délègue un jugement interprétatif réel à un modèle, que ce soit pour déterminer si une page répond à une question ouverte ou si deux pages décrivent le même événement. Cette délégation est l’objectif du processus, et non un manque à combler — mais cela signifie que cette garantie, prise au pied de la lettre, couvre le cœur du navigateur et non l’étape de synthèse qui le suit. Exprimez-le clairement plutôt que de laisser la formulation de l’ère RPA impliquer plus qu’elle ne couvre actuellement.

Vous pouvez tout vérifier par la suite

Chaque exécution est enregistrée dans un journal des opérations daté et en append-only, qui indique ce qui a été tenté, où, avec quel résultat, et étiqueté avec l’intention derrière cette action. Vous pouvez consulter ce que le pipeline a fait, pas seulement le rapport qu’il vous fournit.

→ journal.py, /var/log/dinoer/operations.jsonl

Qu’est-ce qui sort de votre machine, et par quelle porte ?

Trois choses peuvent quitter votre machine, et chacune relève de votre choix : les requêtes envoyées à l’instance SearXNG que vous configurez, le texte collecté envoyé au modèle d’OpenCode, et une notification envoyée à un serveur ntfy (ntfy.sh sauf si vous en indiquez un autre). Vos identifiants, non. Le tableau complet, avec le fichier derrière chaque ligne, est sur la page Architecture ; le prix de la deuxième est dit dans les choix techniques.

Et ce que Dinoer ne prétend pas faire

Ce n’est pas plus précis que le scénario ou la description que vous lui fournissez. Un document mal rédigé peut causer de réels problèmes, à la vitesse d’une machine, et la garantie du corpus mentionnée ci-dessus couvre l’origine d’une réponse, et non si la question posée était une bonne question.