Workflows IA déterministes : un langage, pas un enregistrement

Le travail analytique a deux modes qui prétendent n'en faire qu'un. L'investigation est ouverte : on divague, on révise, on suit le chiffre surprenant. La répétition est l'inverse : le pack de fin de mois, la réponse au superviseur, le deck du comité du lundi - les mêmes étapes sur des données nouvelles, où une surprise n'est pas un constat mais un incident. Une plateforme qui traite les deux comme un seul mode sera médiocre dans les deux ; toute la question de conception est de savoir ce que mérite le second mode.

La réponse de DataQube : un workflow - un artefact distinct, de premier rang, avec une prétention forte. Pas « l'agent essaiera de refaire pareil ». Pas « nous avons sauvegardé votre session et nous la rejouerons ». Un workflow est un programme : étapes ordonnées, paramètres typés, accès déclaré - une chose qu'on peut lire, relire et raisonner avant qu'elle tourne, et qui se comporte ensuite de la même façon à chaque fois.

Le risque des automatisations enregistrées

La plupart des produits d'agents offrent la répétition comme un enregistrement : prendre la session qui a marché, la sauvegarder comme tâche, la lancer selon un calendrier. En démo, c'est superbe. Le risque arrive plus tard, et il s'accumule en silence. Un enregistrement transporte tout ce que la session contenait par hasard - les détours exploratoires, les hypothèses de ce jour-là, des valeurs enfouies dans la cellule dix-sept qui ne valaient que pour octobre. Personne ne peut dire précisément ce qu'il fera sur des données nouvelles, car personne n'a jamais écrit ce qu'il devrait faire ; et quand l'enregistrement est « rejoué » par un modèle qui improvise autour, chaque exécution mensuelle est une interprétation fraîche de l'histoire. La dérive n'a pas de journal des modifications. La première fois que le pack du lundi se contredira, il n'y aura rien à comparer - juste deux exécutions, deux humeurs, et une réunion.

Si vous évaluez les fonctions d'automatisation d'une plateforme d'agents, voici la question qui sépare l'enregistrement de l'ingénierie : montrez-moi l'artefact qui tourne lundi - puis-je le lire, et pouvez-vous prouver ce qu'il peut toucher ?

Un workflow est un programme qu'on peut lire

Dans DataQube, cet artefact répond aux deux moitiés. Les workflows s'écrivent dans un petit langage dédié - .wf -, et voici le workflow d'exposition standard de nos scénarios de démonstration, légèrement abrégé (les méthodes d'outils viennent de votre propre catalogue) :

1import std @ 12 3## Rebuilds the monthly CRE exposure pack and stages it for review.4## @param sql the SQL capability the queries run under5## @param docs the document-store capability for policy citations6## @param conn the registered risk-warehouse connection7## @param as_of the reporting month-end, e.g. "2026-09-30"8## @param dest the file store that receives the pack9def cre_monthly_exposure(sql: Cap<dq.sql>, docs: Cap<dq.files>,10                       conn: Connection, as_of: String, dest: Store) -> Step<ArtifactRef> = {11let exposures: Table<{ segment: String, drawn: Decimal }> <- sql.execute_sql(12  connection_id: conn,13  sql: "select segment, sum(drawn_amount) as drawn14        from loan_book where cre_flag and as_of = '{as_of}' group by segment",15)16let policy: Markdown <- docs.cite(file: "policies/CRE-limits-2026.pdf", section: "3.2")17let pack: Markdown <- std.llm(prompt: "Build the CRE exposure pack for {as_of}.18  Exposures: {exposures.rows}. Limits, cited: {policy}")19let pdf: Pdf <- std.render_pdf(pack)20std.upload(pdf, name: "cre-exposure-{as_of}.pdf", store: dest)21}

Tout ce qu'un enregistrement laisse implicite est ici explicite. Les paramètres sont typés, déclarés dans la signature et documentés par des étiquettes que le vérificateur impose - la date d'arrêté est une entrée, pas de l'archéologie. Chaque effet est une étape liée et ordonnée. Et le langage lui-même est construit pour que l'artefact ne puisse pas dériver : total et déterministe par construction - pas de récursion, pas de boucles non bornées, pas de virgule flottante (décimales exactes uniquement), pas de nulls. Quand l'analyse doit changer, le changement est une nouvelle version de ce texte, revue comme tout changement d'un processus gouverné. Le déterminisme n'est pas une promesse sur l'humeur du modèle. C'est une propriété de l'artefact.

Il ne peut pas mentir sur ce qu'il touche

Regardez à nouveau la signature, car c'est elle qui fait le travail de sécurité. Chaque famille d'outils qu'un workflow peut utiliser doit arriver comme paramètre de capacité typé - sql: Cap<dq.sql> -, et les capacités ne peuvent pas être créées dans le corps. La signature est la surface d'accès : ce workflow peut interroger une connexion d'entrepôt, citer des documents et téléverser un artefact, parce que c'est tout ce qu'on lui a remis. De là, l'analyse calcule le manifeste de droits du workflow avant que rien ne tourne - ce qu'il lit, ce qu'il écrit, ce qu'il peut demander - comme fait vérifié, pas comme intention déclarée.

La discipline ne s'arrête pas aux outils natifs. Connectez un serveur MCP tiers - Jira, ServiceNow, un service interne - et ses outils sont dérivés automatiquement dans le même monde typé : la capacité apparaît comme jira: Cap<mcp.`jira-cloud`.*>, ses méthodes typées depuis le catalogue vivant, sans wrappers écrits à la main. Les outils externes obéissent aux mêmes règles que les natifs - déclarés dans la signature, comptés dans le manifeste, incapables d'apparaître dans une exécution qui ne les a pas déclarés.

Cette seule propriété change qui peut faire confiance à quoi. La personne qui approuve un workflow voit sa surface exacte au moment de l'approbation. Le système de permissions impose le même plafond que partout ailleurs : un workflow ne dépasse jamais les droits de son propriétaire, et la planification n'accorde rien. Et un auditeur qui demande « à quoi cette tâche a-t-elle pu accéder en mars » obtient la réponse de l'artefact lui-même, pas d'une reconstruction.

L'extraire est le travail de l'agent, pas le vôtre

Rien de tout cela n'exige que quelqu'un écrive du code de workflow. Le fil est l'endroit où le travail se comprend - et quand il doit tourner à nouveau, vous le demandez, et l'agent dérive le workflow du registre : les étapes qui ont réellement tourné, les paramètres qui ont réellement varié, les sources réellement touchées. Le registre append-only de l'investigation est assez précis pour compiler à partir de lui ; l'extraction est une projection de ce qui s'est passé vers un programme qui peut se reproduire. Vous relisez le résultat - lisible, typé, manifeste joint - au lieu de l'assembler.

Trois façons de l'exécuter

Le même artefact tourne de trois façons, et chacune répond à un besoin différent :

• À la demande - une personne le déclenche avec les paramètres du jour ; le pack de clôture, lancé plus tôt parce que le comité a avancé.
• Selon un calendrier - c'est un agent planifié : le pack du comité du lundi à 06:00 qui se reconstruit seul, compare avec la semaine précédente et prépare un brouillon pendant que la version distribuée reste intacte.
• Par appel d'outil - un agent en pleine conversation invoque le workflow standard au lieu de redériver les chiffres ; c'est ainsi qu'un nombre cité dans un fil ponctuel sort identique, exécution après exécution, au nombre du pack distribué.

Voici une exécution planifiée en cours - lundi, 06:00, personne au clavier :

D'après de réelles conversations clients — toutes les données sont fictives.

Chaque exécution atterrit au registre

Une exécution de workflow n'est pas du lancer-oublier. Chacune s'ajoute à l'historique : quelle version a tourné, avec quels paramètres, produisant quelles sorties, avec la chaîne de preuve complète - et ses résultats atterrissent dans un fil comme brouillon préparé qu'une personne publie. Les échecs apparaissent dans le même historique avec leur provenance, pas dans un journal que personne ne lit. Les garanties du registre ne faiblissent pas parce que personne ne regardait ; six mois d'exécutions du lundi, ce sont six mois de preuves, pas six mois d'espoir.

C'est tout le design : le fil est l'endroit où vous avez le droit d'être surpris, et le workflow est l'endroit où vous ne l'êtes jamais - parce que c'est un programme avec un manifeste, pas le souvenir d'un bon jour. Le module des agents planifiés de la page produit montre où cela vit dans la plateforme, et une démo extraira volontiers un workflow d'une conversation en direct devant vous.