Les flux automatisés

Un flux applique la même séquence à chaque fois qu'une situation se présente : une opportunité est créée, une demande de matériel est enregistrée, une candidature arrive. L'IA rédige, compare, calcule — puis dépose le résultat dans la boîte de réception où une personne approuve ou rejette. Le motif récurrent est toujours le même : déclencheur → l'IA prépare → un humain valide → le document est écrit.

      
flowchart LR
    T[Déclencheur\névénement / planification / appel] --> P[Étapes\nrédaction, appels d'outils, conditions]
    P --> A{Approbation}
    A -->|approuvé| W[Écriture dans Dokos]
    A -->|rejeté| S[Rejet consigné]
    W --> L[Suivi des exécutions]
    S --> L

    

Quatre façons de déclencher un flux

Sur un événement de document — à la création, à la modification, à la validation ou à l'annulation d'un type de document donné. Une condition permet de restreindre le déclenchement aux cas qui vous intéressent, par exemple les seules opportunités au-delà d'un certain montant.

Sur une planification — toutes les heures, chaque jour, chaque semaine ou chaque mois, pour les traitements de fond : synthèse hebdomadaire, contrôle de cohérence, relances.

À la demande — vous lancez le flux vous-même, ce qui est aussi le mode dans lequel vous le mettez au point avant de l'automatiser.

Par appel externe — un système tiers déclenche le flux par un appel entrant, signé par un secret partagé et restreint aux adresses que vous autorisez.

Ce qu'un flux enchaîne

Les étapes se composent dans un éditeur visuel. Chacune fait une chose : demander à l'IA de rédiger ou d'analyser, appeler un outil Dokos, appeler un outil fourni par un serveur MCP externe, tester une condition pour bifurquer, exécuter un script, ou marquer un point d'approbation où l'exécution s'arrête jusqu'à décision humaine.

Garder la main

Trois réglages déterminent ce qu'un flux a le droit de faire, et ils se règlent flux par flux.

Au nom de qui il s'exécute. Un flux porte l'identité d'un utilisateur désigné : ce sont ses permissions qui s'appliquent. Un flux qui traite des candidatures ne doit pas être porté par un utilisateur qui voit la comptabilité.

S'il écrit sans surveillance. Par défaut, un flux prépare et attend. L'écriture non surveillée doit être explicitement autorisée, et n'a de sens que pour un traitement dont vous avez vérifié le comportement sur plusieurs exécutions réelles.

Combien il peut consommer. Un plafond de jetons par exécution empêche une boucle ou un document anormalement volumineux de faire dériver la facture du fournisseur de modèles.

Interprété ou compilé

Un flux s'exécute de deux manières. En mode interprété, le modèle décide à chaque exécution : c'est souple, adapté aux tâches qui demandent du jugement, et cela consomme des jetons à chaque passage.

En mode compilé, vous décrivez le traitement en français une fois ; Dokos en génère un script que vous relisez et validez, puis c'est ce script qui s'exécute. Le comportement devient identique d'une exécution à l'autre et ne coûte plus rien en jetons. Dokos garde trace de la version validée : si la description change après coup, le flux signale que le script relu n'est plus à jour.

Suivre les exécutions

Chaque exécution est conservée : son déclencheur, le document concerné, les étapes franchies, celle qui a échoué le cas échéant, et les jetons consommés. Vous ouvrez une exécution pour comprendre ce que l'IA a lu et produit à chaque étape — c'est là qu'on diagnostique un flux qui répond à côté, avant de reprendre ses consignes.

Voir aussi

• L'assistant — la boîte de réception où les approbations arrivent
• Activer et paramétrer l'IA — le journal d'audit