Faire travailler des agents IA sans leur confier seuls les règles du jeu.

Pourquoi ajouter un moteur autour des modèles ?

Les modèles de langage sont utiles pour analyser un document, proposer une solution ou écrire du code. Ils produisent leurs réponses à partir de régularités apprises et du contexte reçu. Une formulation assurée ne garantit donc ni l’exactitude d’une conclusion, ni sa pertinence pour la situation présente.

Avec un simple assistant, une erreur peut rester une proposition à relire. Un agent outillé peut aussi modifier un fichier, transmettre des informations ou déclencher une opération. Il faut alors décider précisément ce qu’il peut faire, sur quelle cible et sous quelles conditions. La qualité de son explication ne constitue pas ce droit.

Comment une erreur devient un dommage

Une correction qui masque la faille

Un agent retire un test de sécurité pour obtenir un tableau vert. La faille de l’application reste ouverte. Vérifier la réparation exige de rejouer l’accès interdit, pas seulement de lire le rapport.

Un document qui donne de faux ordres

Une page consultée demande à l’agent d’envoyer une archive interne à une adresse externe. Ce texte est une donnée à analyser ; il ne doit pas devenir une autorisation d’envoi.

Une action répétée après une réponse perdue

Un service ne répond pas après une demande. L’opération a peut-être eu lieu. La répéter sans examiner son état peut produire un doublon, même si le compte rendu précédent ne mentionne aucun succès.

Ces exemples décrivent des risques possibles, pas des incidents revendiqués comme observés dans Swarm. L’OWASP décrit le risque d’autonomie excessive lorsque des fonctions, permissions ou décisions trop larges permettent à une sortie erronée ou manipulée de produire des dommages.

Ce que Swarm cherche à apporter

Swarm conserve une structure de travail explicite : un objectif, des exigences, un plan, des tâches et des dépendances. Les agents produisent des analyses ou des candidats. Des superviseurs conduisent les travaux et les arbitrages dans leur périmètre. Le moteur vérifie les conditions des transitions qu’il contrôle et conserve les éléments nécessaires à leur examen.

Cette séparation vise à éviter qu’un agent puisse transformer son propre récit en autorisation ou en preuve de réussite. Une revue porte sur un candidat identifié ; une modification ultérieure impose de réexaminer les preuves concernées. Une anomalie doit permettre une reprise expliquée, avec l’historique conservé.

La mémoire aide à retrouver du contexte et des enseignements. Elle n’accorde pas de nouveaux droits. De même, multiplier les agents peut répartir le travail, mais ne suffit pas à rendre leur résultat correct ou leur contrôle indépendant.

Pour quels usages ?

Le projet vise les équipes qui souhaitent déléguer des travaux à des agents tout en gardant des responsabilités, des règles et des critères de vérification explicites. Le développement logiciel en est un terrain d’application : cadrer une modification, produire un candidat, exécuter des contrôles, organiser sa revue et examiner le résultat.

Les processus métier constituent un second usage visé. Ils exigent leurs propres habilitations, connecteurs et preuves de fonctionnement. Une démonstration sur un scénario simulé ne qualifie pas un paiement réel ou une exploitation critique.