Cette page s'affiche en anglais pendant qu'une traduction révisée pour votre langue est préparée.

Pourquoi nous considérons l'intention de l'agent comme un contrat de gouvernance et non comme un état d'esprit.

Le point de vue de Perspectis AI en langage clAIr : quelle est la place de l’intention de l’agent dans l’IA d’entreprise (politique, identité, outils, observabilité) — et pas seulement dans les invites — et comment nous envisageons les niveaux de risque et l’injection d’invites.

7 min de lecture2026-04-15

Note en langage clAIr à l'attention des dirigeants, des responsables des risques et des équipes clients (avril 2026)

En bref

Les systèmes « agentiques » font la une : des assistants qui planifient, activent des outils et agissent avec moins d'assistance. Nous pensons que les idées sous-jacentes à cette évolution méritent d'être publiées en tant que perspective sectorielle, car la question cruciale n'est pas de savoir si les modèles peuvent paraître sûrs d'eux, mAIs plutôt si une organisation peut justifier qui a été autorisé à fAIre quoi et pourquoi, en cas de problème ou de contrôle réglementAIre.

Perspectis AI est conçue pour que l'intention (le travAIl demandé et sous l'autorité de qui) soit intégrée à des environnements favorables à la gouvernance — identité, politique, limites des outils et observabilité — et pas seulement dans les instructions d'un modèle. C'est AInsi que nous concilions l'énergie de « l'assistant utile » avec le devoir de diligence dans les environnements professionnels.

Ce que nous entendons par « intention » en langage clAIr

Dans le langage courant, l'intention est simplement le but d'une requête : « résumer ce point », « rédiger un courriel », « créer une facture », « effectuer un contrôle de conformité ».

Sur une plateforme professionnelle, l'intention est également structurelle :

Qui a initié la tâche (une personne, un rôle, un service).
Quelle capacité est autorisée à s'exécuter (par exemple, le parcours d'un agent personnel par rapport à une tâche en arrière-plan).
Quelle catégorie d'action est concernée (consultation, modification, transfert de fonds ou tâche administrative irréversible).

Ces éléments ne doivent pas être sous-entendus par une formulation habile dans une fenêtre de discussion. Nous les considérons comme des informations que la plateforme doit comprendre et appliquer ; le modèle n'est donc pas le seul endroit où l'« intention » se manifeste.

Pourquoi l'intention ne peut pas résider uniquement dans le modèle

Un modèle de langage complexe peut interpréter le langage ; il ne peut cependant pas, à lui seul, constituer le système de référence pour les autorisations, la confidentialité ou la politique de facturation.

Nous concevons nos systèmes selon un principe simple : la gouvernance relève de l'application et du plan de données, et non pas uniquement des instructions adressées au modèle.

Cela signifie que :

Les contrôles de politique (fonctionnalités, rôles, limites organisationnelles) déterminent si une action peut être effectuée, même si le modèle « approuve » une requête inappropriée ou ambiguë.
Les registres d'outils et d'actions définissent les capacités existantes et leur niveau de risque ; le modèle ne peut pas créer de nouveaux points d'accès privilégiés par le biAIs de textes persuasifs.
Les barrières à l'information et les contrôles similAIres restent applicables lorsqu'un assistant récupère ou résume des informations sensibles, car les règles d'accès ne sont pas négociables en langage naturel.

Cette approche nous permet de réduire toute une catégorie de défAIllances où une réponse fluide semble autorisée, mAIs ne l'est pas.

Comment nous appréhendons le risque sans noyer le lecteur sous un jargon technique

Différentes actions comportent différents risques concrets. Nous regroupons cette idée dans une échelle pratique que de nombreuses équipes reconnAIssent déjà :

| Concept simple | Ce que cela signifie généralement en pratique |

| --- | --- |

| Lire | Consulter des informations ; nécessite toujours des règles d'accès et de confidentialité appropriées, mAIs n'entraîne pas de changement durable en soi. |

| Agir (modifier les données) | Créer ou mettre à jour des enregistrements ; requiert une responsabilité clAIre et souvent une étape de confirmation dans les canaux à haut risque. |

| Transaction (argent ou facturation) | Travaux financiers ou liés à la facturation ; requiert une confirmation explicite et une autorisation stricte, car les erreurs ont des conséquences commerciales et réputationnelles. |

| Irréversible ou destructrice | Opérations administratives ou difficiles à annuler ; Mérite les contrôles les plus stricts – et, conformément à notre orientation de conception, nous ne souhAItons pas que le type de travAIl soit effectué silencieusement via les canaux mAIns libres les plus risqués, comme la voix, sans mesures de sécurité supplémentAIres.

Outre le risque lié à chaque action, nous accordons également une grande importance à l'intervention humAIne au niveau du produit : lorsqu'une approbation humAIne est requise, lorsqu'une personne supervise et peut intervenir, et lorsque l'autonomie est intentionnellement limitée. Il ne s'agit pas de bureaucratie gratuite ; c'est AInsi que les organisations réglementées et soucieuses de leur réputation gèrent les preuves.

Injection de prompts et comportements « émergents » : que se passe-t-il réellement ?

L'injection de prompts (tentatives de détournement ou de confusion d'un assistant par du texte malveillant) est un problème connu du secteur. Nous le prenons au sérieux – et nous reconnAIssons honnêtement qu'aucun filtre de texte n'est une solution miracle.

Ce que nous mettons en avant auprès de nos clients, c'est l'importance d'une défense en profondeur :

L'atténuation des risques au niveau du modèle (détection, nettoyage, journalisation) réduit la quantité de texte malveillant qui y parvient sans être modifié.
Des contrôles stricts au niveau du logiciel déterminent toujours si les outils s'exécutent, si des fonds sont transférés ou si des données restreintes sont renvoyées. AInsi, un modèle manipulé ne peut pas contourner silencieusement la politique de l'entreprise.

C'est grâce à cette combinAIson que nous abordons la sécurité sans prétendre que le modèle est infAIllible.

ComparAIson en un coup d'œil (structurelle, et non un score hebdomadAIre de fonctionnalités)

Ce tableau est destiné aux discussions avec les parties prenantes ; il sert à positionner le produit, et non à dresser une liste de cases à cocher. Les produits évoluent rapidement ; l'architecture, elle, évolue plus lentement.

| --- | ---: | ---: | ---: |

| Où l'intention doit se manifester | Identité, politique, registres, requêtes structurées, observabilité | Principalement dans les échanges | Quelle que soit la mise en œuvre par chaque équipe |

| Qui est responsable de l'application des règles ? | La couche plateforme que nous déployons et fAIsons évoluer | Les choix du fournisseur en matière de produit et d'administration du locatAIre | Les équipes d'ingénierie et de sécurité de l'organisation adoptante |

| Travaux importants et irréversibles | Définition explicite des risques, confirmations, contrAIntes de canal dans notre sens | Souvent hors périmètre ou générique | Entièrement personnalisé — puissant et impliquant de lourdes responsabilités |

| Protocole et outils de contexte du modèle | Nous considérons les outils comme des capacités encadrées, et non comme des superpouvoirs silencieux | Varie selon le produit | Dépend entièrement de la qualité de l'implémentation |

Pourquoi publions-nous ce type de perspective

Nos clients n'achètent pas seulement une « fonctionnalité d'IA ». L'engagement réel réside dans un fonctionnement fiable : continuité, séparation des tâches et une explication qui tient la route même en cas de problème. Nous investissons dans une communication publique et accessible, AInsi que dans des ressources techniques plus approfondies pour les experts en sécurité et en architecture, car nos clients méritent de savoir clAIrement ce qui relève du marketing et ce qui relève de la structure.

L'environnement de démonstration d'IA de Perspectis a notamment pour but de rendre cette différence concrète : non pas une simple démonstration sophistiquée, mAIs un large catalogue de scénarios réalistes où l'intention, les politiques et les flux de travAIl sont des préoccupations majeures.

Sources (externes, pour un contexte général du secteur)

Ce document est destiné à un public externe non technique. Des analyses techniques plus approfondies des contrôles, de l’état de mise en œuvre et des preuves sont disponibles dans notre documentation sur la sécurité et l’architecture, à destination des clients et des auditeurs.