SWARMRecherche en IA agentique et cybersécurité
Swarm

Agents IA et processus critiques : pourquoi un moteur déterministe

Fabrice Pizzi · Projet Swarm

Après une demande de paiement, une réponse perdue conduit à un risque de répétition ; le parcours contrôlé conserve l’état inconnu, bloque la relance aveugle et recherche l’effet observé.
Une réponse perdue ne prouve pas l’absence d’effet : conserver l’incertitude et réconcilier avant toute nouvelle tentative.
Image fixeOuvrir le GIF

Pour un agent de développement, corriger une erreur après coup est souvent possible. Pour une opération financière ou une modification irréversible, cette logique atteint vite sa limite : un second essai peut produire un second effet. Le traitement des reprises devient alors une question de sécurité métier.

Avec Swarm, j’explore cette séparation entre raisonnement agentique et contrôle explicite de l’exécution. Les travaux de Cursor sur les bases de code autonomes apportent un retour d’expérience sur la coordination. Leur domaine d’expérimentation ne qualifie pas un processus bancaire.

Le paiement dont la réponse n’arrive pas

Considérons une demande de règlement autorisée. Le connecteur reçoit l’instruction, mais la connexion se coupe avant que le demandeur obtienne une réponse exploitable. Deux situations sont possibles : l’effet n’a pas eu lieu, ou il a eu lieu sans que le demandeur puisse le confirmer. À cet instant, « erreur de transport » ne signifie pas « aucun paiement ».

Si l’agent recrée l’opération avec une nouvelle identité et la renvoie, il pourrait doubler le règlement. S’il annonce un échec certain à l’utilisateur, il pourrait provoquer une intervention manuelle qui le double également. L’incertitude doit donc traverser le rapport, l’interface et la décision de reprise.

Un accusé de réception, une décision d’autorisation et un effet observé sont trois faits différents.

Ce scénario expose le risque d’un traitement critique. Il ne décrit pas un paiement réel réalisé par Swarm : le connecteur du pilote concerné produit des effets simulés.

Conserver l’intention avant de décider la reprise

Une reprise maîtrisée conserve l’identité de l’intention et ses paramètres : bénéficiaire, montant, devise, ressource et mandat. La clé d’idempotence sert à reconnaître la même opération dans le contrat du connecteur. Changer les paramètres ou créer une nouvelle clé pour contourner un résultat incertain détruit ce lien.

La documentation Stripe sur l’idempotence illustre ce mécanisme pour son API, avec des règles précises de réutilisation et de conservation. Ces propriétés dépendent du service : elles ne constituent pas une garantie universelle de traitement exactement une fois.

Lorsque l’effet reste inconnu, il faut rechercher l’état faisant autorité et réconcilier le résultat avant d’autoriser une nouvelle émission. La réconciliation peut elle-même échouer ou rester ambiguë ; cette limite doit rester visible. Une compensation ultérieure est une autre opération, avec ses propres droits, et ne fait pas disparaître l’effet initial.

Ce qui est présent dans le pilote Swarm

Le moniteur Trust Rust contient des opérations d’engagement et de réconciliation sur un domaine simulé. Le contrat distingue notamment des états engagés, refusés, inconnus et réconciliés. Le traitement d’une action déjà engagée, réconciliée ou inconnue ne doit pas être confondu avec un nouvel effet par simple rejeu de l’engagement.

Le contrôle réexamine le mandat et les conditions applicables à l’opération. Une approbation de principe ne doit pas couvrir des paramètres modifiés. Ces contrats sont examinables dans le code ; ils ne démontrent ni connecteur financier de production, ni contrôle de tous les chemins externes, ni indépendance de toutes les autorités.

Le risque se joue aussi dans le compte rendu

Une architecture peut conserver l’état correct et néanmoins tromper l’opérateur si une couche transforme « résultat inconnu » en « échec sans effet ». La même rigueur doit donc être appliquée aux sorties, aux erreurs, aux journaux et aux reprises manuelles. Les traces ordinaires ne sont pas, à elles seules, un journal inviolable.

L’évaluation pertinente injecterait une perte de réponse à différentes étapes et vérifierait l’effet réellement observé, la conservation de l’intention et les décisions autorisées ensuite. La simulation fournit une preuve bornée sur ce contrat ; le passage à un système réel exigerait la qualification du connecteur et de ses garanties effectives.

Le dépôt Swarm rend cette recherche d’architecture examinable. Pour les processus critiques, la question décisive reste : que sait-on de l’effet, et sur quelle preuve accepte-t-on de recommencer ?