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 invitations — 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 : des assistants qui planifient, activent des outils et ré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 justifiant qui a été autorisée à fAIre quoi et pourquoi, en cas de problème ou de contrôle réglementAIre.

Perspectis AI est conçu 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 réagirons par « intention » en langage clAIr

Dans le langage courant, l'intention est simplement le but d'une requête : « resumer 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 transmises au modèle.

Cela signifie que :

Les contrôles de politique (fonctionnalités, rôles, limites organisationnelles) déterminant si une action peut être effectuée, même si le modèle « approuve » une requête incorrecte ou ambiguë.
Les registres d'outils et d'actions prenant en compte 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 les biAIs de textes persuasifs.
Les barrières à l'information et les contrôles similAIres restent applicables lorsqu'un assistant récupère ou résumé des informations sensibles, car les règles d'accès ne sont pas négociables en langue naturelle.

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 ; nécessite 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éterminant 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 évolutives | 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, contraAntes de canal dans notre sens | Souvent hors limite 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 imprimées, et non comme des superpouvoirs silencieux | Varie selon le produit | Dépend entièrement de la qualité de l'implémentation |

Pourquoi publications-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 mAIs 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.