Connecter un assistant IA
à vos données de sécurité.

Voir l’encadré au-dessus du sommaire. La suite de l’article présente les trois éléments de l’accès machine, la façon dont le connecteur autorise un assistant IA, ce qui reste verrouillé face à l’automatisation, et ce qu’une équipe d’intégration peut réellement construire.

La plupart des plateformes de sécurité gardent leurs données derrière l’écran. eAviora les expose délibérément, par trois éléments qui partagent un même chemin gouverné vers les mêmes enregistrements. Ce ne sont pas trois produits distincts assemblés après coup : ce sont trois portes vers une seule exploitation connectée.

Une API REST v1 publique. L’interface programmatique sur laquelle votre équipe d’intégration développe. Elle est documentée par un contrat OpenAPI 3.1 généré à partir du code : la spécification est produite à partir du service en fonctionnement, si bien que la documentation ne s’éloigne jamais du comportement réel. Vous pointez un générateur de code sur le contrat et obtenez un client typé dans le langage de votre choix. Authentification par clé de type Bearer, ressources prévisibles, le document OpenAPI comme source unique de vérité.

Un serveur MCP, qui connecte un assistant IA à vos enregistrements en direct. Au lieu d’écrire du code sur l’API REST, vous laissez un assistant IA interroger les mêmes enregistrements en langage courant. Demandez-lui quelles actions correctives ouvertes ont dépassé leur date de vérification, ou quels événements de ce mois ont touché un danger donné : il atteint les données en direct par le serveur MCP plutôt que par un export périmé. L’assistant voit les mêmes enregistrements qu’une personne, dans la limite de ce qu’il est autorisé à voir.

Un connecteur OAuth 2.1 pour assistants IA. La couche de consentement et d’identité. Il autorise un assistant IA à agir au nom d’un utilisateur précis qui a donné son consentement, avec une permission limitée exactement à ce que vous accordez. C’est ce qui transforme « la plateforme a une API » en « j’ai ajouté un connecteur, je me suis connecté et j’ai choisi ce qu’il peut faire », sans clé collée dans une fenêtre de discussion ni compte de service partagé.

Le connecteur suit OAuth 2.1, la norme d’autorisation actuelle de référence, avec les renforcements qui comptent pour un système qui détient des données de sécurité. Le flux est conçu pour qu’un identifiant ne se trouve jamais là où il pourrait être copié, rejoué ou étiré en un accès de longue durée.

Enregistrement dynamique des clients (RFC 7591). Quand vous ajoutez le connecteur eAviora dans votre assistant IA, l’assistant s’enregistre automatiquement auprès d’eAviora selon la norme RFC 7591. Vous ne créez pas d’enregistrement d’application à la main et n’échangez pas de secrets clients par courriel.

PKCE obligatoire. Le mécanisme PKCE (Proof Key for Code Exchange) est exigé à chaque autorisation, il n’est pas facultatif. Il lie la demande d’autorisation au client qui l’échange ensuite, si bien qu’un code intercepté est inutilisable par quiconque d’autre.

Codes d’autorisation à usage unique. Le code court remis après votre consentement ne peut être échangé qu’une seule fois. Une réutilisation du même code est refusée, ce qui ferme l’attaque par interception la plus courante sur ce type de flux.

Accès de courte durée, actualisation tournante. Un jeton d’accès dure environ une heure. Derrière lui se trouve un jeton d’actualisation qui change environ tous les trente jours. Ainsi, même dans le pire des cas, un jeton d’accès divulgué expire vite, et l’identifiant de plus longue durée continue de changer au lieu de rester figé. Vous pouvez révoquer l’autorisation à tout moment, et l’assistant perd alors l’accès.

Consentement par portée, accordé dans l’application. Quand vous donnez votre autorisation, vous le faites dans eAviora, connecté sous votre propre identité, et vous choisissez les portées que le connecteur détiendra. Le connecteur agit ensuite en votre nom, celui de l’utilisateur qui a consenti, pour chacun de ses appels. C’est la propriété essentielle : il n’y a pas d’identité de robot anonyme. La piste d’audit nomme une personne.

Ce qui compte le plus pour un directeur de la sécurité n’est pas ce que le connecteur peut faire, mais ce qu’il ne pourra jamais faire. Ouvrir des données à l’automatisation n’est sûr que si l’automatisation passe exactement par les mêmes contrôles qu’une personne. Dans eAviora, c’est le cas : il n’existe aucun chemin parallèle et plus faible pour les machines.

Les cinq mêmes contrôles, à chaque appel. Qu’une requête arrive par l’API REST, le serveur MCP ou le connecteur, elle passe par la même chaîne qu’une personne qui clique dans le produit :

• Vérification de portée : cet identifiant détient-il la permission pour ce qu’il demande ?
• Limitation de débit : les appels automatisés sont cadencés, si bien qu’un script emballé ne peut pas submerger l’exploitation.
• Isolation entre clients appliquée par la base de données : un exploitant ne peut jamais atteindre les enregistrements d’un autre. La frontière est appliquée par la base de données elle-même, pas seulement par le code applicatif, si bien qu’une erreur dans une requête ne peut pas la franchir.
• Contrôle des permissions : les mêmes règles de rôle et d’accès qui encadrent l’utilisateur consentant dans l’interface encadrent l’appel machine.
• Journal d’audit : chaque lecture et chaque proposition sont consignées sous l’identité de l’utilisateur qui a consenti, si bien qu’un examen ultérieur peut reconstituer exactement ce qu’une automatisation a touché.

L’état de gouvernance est verrouillé face à l’automatisation. L’état du processus et l’état de gouvernance ne peuvent jamais être fixés par l’API ou par le connecteur. Faire avancer une étape, approuver une classification, clôturer une action corrective, valider un contrôle d’efficacité : rien de tout cela ne peut être écrit par une machine. Un assistant IA peut lire l’enregistrement et proposer l’étape suivante, mais c’est une personne nommée qui tranche dans le produit. Par conception, l’accès machine se limite à la lecture et à la proposition pour tout ce qui engage une responsabilité.

L’intégration sortante est elle aussi renforcée. Quand eAviora envoie des événements vers vos systèmes, ces webhooks sont signés par HMAC pour que le destinataire puisse vérifier que le message provient bien d’eAviora et n’a pas été altéré, et le chemin de livraison est protégé contre la falsification de requêtes côté serveur pour que le mécanisme de webhooks ne puisse pas servir à sonder des réseaux internes. Tout, en entrée comme en sortie, est isolé entre clients et consigné au journal d’audit.

Une fois l’accès en place, les gains concrets se rangent en deux groupes : ce qu’un assistant IA fait pour l’équipe sécurité en langage courant, et ce qu’une équipe d’intégration construit sur l’API REST.

Pour l’équipe sécurité, par le connecteur. Un gestionnaire de la sécurité qui a autorisé le connecteur peut poser des questions à un assistant IA sur les données en direct au lieu d’attendre un rapport :

• Quelles actions correctives ouvertes ont dépassé leur date de vérification, et qui en est responsable ?
• Montre-moi les événements de ce trimestre liés à un danger donné, et résume les facteurs communs.
• Rédige une première liste d’événements semblables à ce nouveau compte rendu, qu’une personne examinera et confirmera.

Dans tous les cas, l’assistant lit les enregistrements en direct et propose. Une personne examine la proposition et agit dans eAviora, là où se trouvent les verrous de gouvernance. L’assistant accélère la lecture et la rédaction; il ne boucle jamais la boucle de lui-même.

Pour l’équipe d’intégration, par l’API REST. Comme l’API REST fournit un contrat OpenAPI 3.1 généré à partir du code, développer dessus relève du travail d’ingénierie ordinaire, pas de la rétro-ingénierie :

• Générer un client typé directement à partir du document OpenAPI et charger les enregistrements dans un entrepôt de données ou un outil d’analyse.
• Recevoir des webhooks signés par HMAC quand des enregistrements changent, et piloter à partir d’eux vos propres notifications ou tableaux de bord en aval.
• Alimenter eAviora en propositions depuis vos propres systèmes, en gardant à l’esprit qu’un humain approuve toujours ce qui fait avancer un processus.

La même gouvernance s’applique aux deux groupes. Que l’appelant soit un assistant IA en langage courant ou un service écrit par votre équipe, il voit une partie de l’exploitation isolée entre clients, soumise au contrôle des permissions et consignée au journal d’audit, et il peut lire et proposer, mais pas décider.

Les pages utiles : Développeurs et API, Confiance et sécurité, Analytique de sécurité. Pour cadrer une connexion pour votre exploitation, écrivez-nous.