Exécution agentique des tests : quelles garanties de sécurité et de conformité exiger ?

Un agent de test lit un scénario, se connecte à une application, saisit des données, observe les écrans et produit des preuves. Ces capacités accélèrent l’exécution des tests manuels et en Gherkin. Elles conduisent aussi, légitimement, le service sécurité à examiner le traitement des données avant toute mise en service.

Dans un précédent article, nous avons présenté l’exécution agentique des tests manuels et Gherkin et les questions à se poser avant de se lancer. Nous nous concentrons ici sur la sécurité et la conformité.

Notre conviction est simple : un agent de test doit avoir un flux de données explicable. Les équipes QA doivent pouvoir dire précisément quelles données sont transmises à l’agent IA, comment elles sont sécurisées et pendant combien de temps elles sont conservées. Elles doivent aussi pouvoir poser les mêmes questions à tout fournisseur d’exécution agentique, quel qu’il soit.

Cet article propose la grille d’analyse à appliquer à une solution d’exécution agentique, puis les réponses apportées par notre solution Lynqa pour les distributions Cloud et Self-Managed. Les éléments qui relèvent du détail d’implémentation (architecture fine, matrice des flux, liste des sous-traitants) sont documentés dans le DPA et le Trust Center, et approfondis lors de la revue sécurité qui précède un projet pilote.

L’agent reçoit en entrée des tests manuels au format action/résultat attendu, ou des scénarios en Gherkin. Cela inclut les actions à réaliser, les résultats attendus, les données de test nécessaires au scénario, ainsi que des pièces jointes. Ces données proviennent du référentiel de tests (par exemple, les données des tickets « Test » et « Test Execution » de Xray).

Pendant l’exécution, l’agent observe l’interface. Il peut voir des références de contrat, des montants, des documents ou des informations relatifs à un compte de test. Les captures d’écran, les observations et les journaux produits à chaque étape deviennent, eux aussi, des données à protéger.

L’architecture de la solution détermine l’étendue de cet accès. Certains outils exploitent le DOM, le code, les appels réseau ou les logs du navigateur. Lynqa fonctionne par “computer-use” : il utilise une souris et un clavier virtuels et interprète uniquement les informations visibles à l’écran. Il n’accède ni au DOM, ni au HTML, ni au code source, ni aux API, ni à la base de données. Ce choix d’architecture réduit structurellement la surface d’accès : ce que l’agent ne peut pas atteindre n’a pas besoin d’être protégé de lui.

Figure – Le parcours des données pendant l’exécution agentique d’un test

Un agent utilise parfois un compte de test ou un secret technique. Ces informations ne doivent pas être écrites en clair dans le scénario. Dans Lynqa, elles sont renseignées séparément en tant que données sensibles non visibles. Elles ne sont pas intégrées au texte envoyé au modèle d’IA.

Les conditions d’utilisation de Lynqa Cloud interdisent l’utilisation de données personnelles dans les tests et les données de test. La bonne pratique reste la même quel que soit l’outil : des jeux de données synthétiques ou anonymisés, des comptes limités à l’environnement de test et des droits faciles à révoquer.

Figure – Les données sensibles sont fournies séparément du cas de test et masquées dans Lynqa

La revue de sécurité analyse le parcours réel des données. Huit questions permettent de cadrer rapidement le sujet. Vous pouvez les reprendre telles quelles dans votre dossier d’évaluation, pour Lynqa comme pour toute autre solution d’exécution agentique :

Les réponses doivent être documentées dans le DPA (Data Processing Agreement), qui facilite cette vérification en regroupant les contrôles et les documents applicables. Un fournisseur qui ne peut pas répondre simplement à ces huit questions vous demande, de fait, de lui faire confiance sur parole.

Le fournisseur exploite l’infrastructure, assure les mises à jour et supervise le service. Ce modèle facilite le démarrage, à condition de connaître la localisation de chaque traitement. L’hébergement de l’application et l’inférence du modèle d’IA peuvent se situer dans deux régions distinctes.

Le service sécurité vérifiera notamment le chiffrement, l’isolation logique des clients, la gestion des secrets, les durées de conservation, la liste des sous-traitants et les garanties du fournisseur d’IA. Une adresse IP fixe permet également d’autoriser précisément l’agent à accéder aux environnements de test.

Il s’agit d’une distribution « on-premise » utilisant un LLM validé et disposant d’accès encadrés par la DSI de l’entreprise utilisatrice. L’agent, ses exécuteurs et son stockage sont déployés dans l’environnement du client. Le BYO-AI peut prendre la forme d’une clé API appartenant au client ou d’une gateway IA interne déjà approuvée par l’entreprise.

Avec une gateway ou un modèle interne, les tests, captures, prompts, résultats et journaux restent dans le réseau du client. Cette configuration répond aux besoins des applications inaccessibles depuis Internet et des environnements réglementés. Le client conserve, en contrepartie, la responsabilité de l’installation, de la supervision, des sauvegardes et des mises à jour qu’il décide d’appliquer.

Figure – Lynqa Cloud et Lynqa Self-Managed répondent à deux niveaux de contrôle

Un rapport SOC 2 Type II évalue la conception des contrôles et leur efficacité opérationnelle sur une période donnée. Il couvre par exemple la gestion des accès, les changements, la surveillance, la réponse aux incidents et la protection des systèmes.

Le périmètre mérite une lecture attentive, et c’est vrai pour tout éditeur. Le rapport peut couvrir le service principal sans inclure une application Marketplace, certaines intégrations ou tous les sous-traitants. Le critère audité et la période d’observation doivent également être précisés. SOC 2 est un rapport d’attestation, pas une certification générale de toute l’offre.

SOC 2 ne garantit pas automatiquement l’absence d’entraînement sur les données clients, la région d’inférence, la rétention des prompts ou la conformité de chaque configuration au RGPD. Ces points nécessitent des engagements contractuels et une description claire des flux.

Les scans DAST réguliers, le bug bounty, la gestion des vulnérabilités, le DPA, les clauses de transfert, les politiques d’usage des modèles et les journaux d’audit complètent le dispositif. La conformité devient utile lorsqu’elle permet au client de vérifier un contrôle précis.

La supervision humaine est également centrale. L’exécution doit être identifiée comme réalisée par un agent. Le QA examine les preuves, décide du verdict et conserve seul la décision de mise en production.

Lynqa exécute les tests manuels et Gherkin déjà validés dans le référentiel QA, par exemple Xray dans Jira. L’agent observe l’écran, agit sur l’interface et produit, pour chaque étape, l’action réalisée, l’observation, le verdict, l’explication et la capture associée. Des contrôles appliqués aux instructions reçues bloquent les contenus malveillants avant l’exécution.

L’accès est limité aux URL autorisées par le client et à l’environnement de test. Pour Lynqa Cloud, Smartesting fournit une adresse IP fixe qui peut être ajoutée à la whitelist. Le QA peut confirmer ou modifier le verdict ; sa décision est tracée dans Lynqa et, selon l’intégration, dans Xray. Lynqa ne décide jamais d’une mise en production.

Le SaaS Lynqa est hébergé chez Scaleway en France. L’inférence du modèle d’IA est actuellement réalisée aux États-Unis par l’API d’un fournisseur tiers. Ce transfert est encadré contractuellement et les données ne sont pas utilisées pour entraîner le modèle. L’identité du fournisseur d’inférence et la liste complète des sous-traitants sont documentées dans le DPA et tenues à jour dans le Trust Center Lynqa.

Les données Lynqa sont conservées 30 jours. Une demande de suppression peut être effectuée à tout moment et la suppression définitive intervient dans un délai maximal de 60 jours. Les données sont chiffrées, les clients sont isolés logiquement, les accès internes sont limités et les exécutions sont journalisées. Les incidents de sécurité affectant les données font l’objet d’une notification sous 24 heures.

Lynqa Self-Managed est disponible pour les organisations qui souhaitent héberger l’agent dans leur propre infrastructure. Les composants d’exécution, le stockage, les résultats et les journaux sont installés dans le réseau du client. Aucune télémétrie d’exécution n’est envoyée à Smartesting.

Le client utilise sa propre clé vers un fournisseur d’IA ou sa gateway interne. Dans cette seconde configuration, aucune donnée ne sort du réseau. Smartesting fournit les packages et les mises à jour ; le client les vérifie puis décide de leur installation.

Smartesting a obtenu un rapport SOC 2 Type II portant sur le critère de sécurité. Il couvre Lynqa Service API et Lynqa Dashboard sur la période du 1er mars au 31 mai 2026. L’audit a été réalisé par A-LIGN et les tests des contrôles n’ont relevé aucune exception. Lynqa for Xray et les intégrations tierces ne font pas partie de ce périmètre. Le rapport est accessible sur demande, dans le cadre d’un accord de confidentialité.

Le dispositif comprend également des scans DAST réguliers et un programme public de bug bounty en cours pour Lynqa for Xray. Le Trust Center Lynqa présente les contrôles relatifs à l’infrastructure, au produit, à l’organisation, aux procédures internes et à la protection des données ; c’est la source de référence, tenue à jour au fil des évolutions du dispositif.

Figure – Le Trust Center Lynqa regroupe les contrôles et documents de sécurité

Les informations actualisées sont disponibles dans le Trust Center Lynqa. Le DPA, les conditions d’utilisation et les autres documents contractuels sont accessibles depuis les documents légaux Lynqa.

Enfin, lors du cadrage d’un proof of concept, Smartesting remet un dossier sécurité destiné à votre RSSI : description détaillée des flux, architecture de la distribution retenue, sous-traitants et modalités de connexion à votre référentiel de tests. C’est ce dossier, et non un article de blog, qui sert de support à votre revue sécurité.

Avant de confier un test à un agent, l’équipe doit pouvoir expliquer quelles données il reçoit, ce qu’il observe, quel modèle les traite, où les preuves sont conservées et comment elles sont supprimées.

La sécurité repose sur une architecture adaptée aux données, des contrôles techniques et contractuels vérifiables, et une conformité indépendante dont le périmètre est clairement annoncé. Le choix entre Cloud et Self-Managed permet ensuite d’ajuster le niveau de contrôle au contexte de l’organisation.

Les huit questions de cet article sont le point de départ. Les réponses détaillées (architecture, flux, sous-traitants) se construisent avec vos équipes sécurité, lors du cadrage d’un projet pilote.