Quand l’IA agit, un interrupteur ne suffit pas

1. Le changement se produit au niveau de l’effet

Le débat habituel sur l’IA s’intéresse d’abord aux réponses. Sont-elles exactes ? Semblent-elles aimables ? Contiennent-elles des hallucinations ? Ces questions restent importantes, mais ne rendent compte que des systèmes dont l’effet s’achève essentiellement avec une sortie.

Dès qu’une IA déplace un rendez-vous, envoie un message, modifie un fichier, prépare un achat ou publie du code, la réponse n’est plus qu’une étape intermédiaire. Ce qui compte est l’effet produit dans un autre système.

Le terme « acteur » ne doit pas être mystifié. Un agent n’a ni conscience humaine ni responsabilité morale propre. Sur le plan organisationnel, il doit néanmoins être traité comme une instance agissante, faute de quoi ni ses pouvoirs ni son parcours d’action ne peuvent être décrits proprement.

2. Un interrupteur arrive trop tard

Un interrupteur est nécessaire. Mais il n’aide qu’une fois le problème détecté. Il ne permet pas de récupérer automatiquement un message envoyé par erreur, un fichier supprimé ou une information publiée.

La sécurité commence donc plus tôt. Quelles données le système peut-il voir ? Quels outils peut-il appeler ? Peut-il seulement lire ou également écrire ? Dans quel espace et pendant combien de temps une autorisation est-elle valable ? Quelle action exige une confirmation humaine ?

Pour les systèmes d’agents, le NIST distingue notamment les accès aux outils en lecture, en écriture limitée et en écriture, ainsi que les environnements fiables et non fiables. [4] Cette distinction montre pourquoi « L’agent peut utiliser le navigateur » ne constitue pas une description de sécurité suffisante.

3. La responsabilité ne doit pas être déléguée à l’agent

Lorsqu’un agent agit mal, « L’IA a décidé » n’est pas une attribution valable de la responsabilité. Celle-ci reste entre les mains des personnes et des organisations qui définissent l’objectif, l’accès aux données, les outils, les validations et le contexte d’utilisation.

Cela ne signifie pas que chaque action individuelle doive être confirmée manuellement. Une telle exigence pourrait pratiquement empêcher toute automatisation utile et épuiser l’attention humaine par des validations insignifiantes.

La position opposée est donc légitime : des limites trop étroites peuvent rendre les systèmes inutiles. La réponse réside dans un régime d’action gradué. Les actions à faible risque et réversibles peuvent être exécutées automatiquement dans un cadre clairement défini. Les actions irréversibles, externes ou particulièrement lourdes de conséquences exigent un contrôle renforcé.

4. Ce qu’en fait FlameP

Dans FlameP, un agent ne doit pas simplement « être dans l’espace ». Son rôle doit être aussi visible que ses limites.

Premièrement, chaque agent a besoin d’une identité univoque. Les personnes doivent pouvoir reconnaître si un contenu provient d’une personne, d’un modèle ou d’un système agissant.

Deuxièmement, les autorisations sont liées à un contexte concret. Un agent qui produit des résumés dans un espace n’obtient pas pour autant automatiquement le droit d’envoyer des messages dans un autre.

Troisièmement, lire, proposer, préparer et exécuter sont séparés. Une bonne recommandation ne doit pas devenir imperceptiblement une action.

Quatrièmement, les actions lourdes de conséquences nécessitent des points de confirmation. La confirmation doit indiquer ce qui doit se passer, jusqu’où s’étend l’effet et si celui-ci peut être annulé.

Cinquièmement, le parcours d’action reste traçable : mission, contexte utilisé, appel d’outil, résultat et validation responsable.

5. La limite n’est pas seulement technique

Même un contrôle d’accès parfait ne résout pas toutes les questions. Un système peut agir de manière inappropriée dans le cadre de son autorisation parce que l’objectif ou le contexte a été mal formulé. Un journal peut être complet tout en restant incompréhensible pour les personnes. Une validation peut être formellement présente alors que la personne qui l’a donnée n’a pas pu saisir les conséquences.

FlameP ne doit donc pas confondre la sécurité avec une liste de contrôles techniques. Il faut un langage compréhensible, des paramètres par défaut parcimonieux et une conception qui ne masque pas l’incertitude.

6. Conclusion : l’action a besoin d’une constitution à petite échelle

Les agents ne sont pas dangereux parce qu’ils ont de mauvaises manières. Ils deviennent risqués lorsque capacité, autorisation et responsabilité se confondent.

La règle pratique de FlameP est la suivante :

Idée directriceAucun agent n’agit sur la seule base de ce qu’il sait faire. Il agit uniquement dans le cadre d’un rôle visible, d’un contexte limité et d’une responsabilité traçable.

L’interrupteur demeure. Mais il constitue le dernier dispositif de sécurité, et non la première idée.