Révisé le
Tester un assistant d’IA avant de s’y fier au travail
Une réponse convaincante en démonstration ne prouve pas qu’un assistant respectera les autorisations, ignorera des instructions cachées dans un document ou s’arrêtera avant une action non approuvée. Un exercice de préparation utile porte sur un processus clairement délimité et consigne les résultats, y compris les échecs et les éléments qui n’ont pas été vérifiés.
Décrivez d’abord le périmètre : la fonction de l’assistant, ses utilisateurs, ses sources de données, ses connecteurs, ses outils et les actions permises. Testez uniquement les systèmes qui vous appartiennent ou pour lesquels vous avez une autorisation explicite. Utilisez un environnement hors production et des données fictives. Un essai de sécurité ne doit pas exposer de véritables secrets ou dossiers clients.
S’appuyer sur un référentiel actuel, sans en faire un label de conformité
Le Top 10 des risques GenAI LLM de l’OWASP, édition 2026 et sa liste publiée pour 2026 fournissent un vocabulaire commun pour les risques d’injection d’instructions, de divulgation de renseignements sensibles, d’autonomie excessive et de traitement inadéquat des sorties. Servez-vous de ces catégories pour mieux cibler les essais, et non pour affirmer que tous les risques ont été couverts.
Pour un système qui planifie des étapes, appelle des outils ou délègue des tâches, ajoutez le référentiel distinct OWASP Top 10 for Agentic Applications, édition 2026. Il permet d’élargir l’examen au-delà du texte produit, notamment aux objectifs, aux identités, aux outils et aux échanges entre agents. Ces documents orientent l’analyse des risques. Ce ne sont ni des lois ni des certifications, et leur utilisation ne prouve pas qu’un système est sûr.
Définir le résultat attendu avant l’essai
Précisez le résultat attendu pour chaque cas avant de l’exécuter. Pour un assistant de soutien, les cas courants pourraient consister à répondre à partir d’un article d’aide approuvé, à citer la bonne version et à reconnaître que la source ne contient pas la réponse. Ajoutez des demandes ambiguës ainsi que des sources contradictoires ou périmées.
Désignez la personne qui décidera si la réponse est utilisable. Un paragraphe bien rédigé peut tout de même inventer une règle de remboursement ou omettre une exception importante. Évaluez les preuves et les conséquences pour l’organisation, pas seulement le ton ou la présence d’une citation.
Vérifier les limites d’accès et les instructions non fiables
Créez deux utilisateurs fictifs ayant des droits d’accès différents et des documents d’essai faciles à distinguer. Vérifiez que chacun peut obtenir les renseignements autorisés, sans accéder au contenu protégé de l’autre. Couvrez la recherche, les résumés, les questions de suivi et les contrôles d’accès de l’application. Un refus formulé par le modèle ne remplace pas un contrôle d’autorisation imposé par le système.
Dans un document d’essai autorisé, insérez une instruction contradictoire sans danger, par exemple une demande d’abandonner la tâche de l’utilisateur ou de reproduire un marqueur fictif réservé à un autre rôle. Le document doit rester une source de données, et non devenir une autorité capable de modifier les règles de l’assistant. Vérifiez aussi le traitement des liens et du balisage générés avant leur affichage ou leur transmission. N’utilisez jamais un vrai destinataire externe ou un véritable secret comme cible d’un essai d’exfiltration.
Vérifier les actions de l’agent, pas seulement ses réponses
Si l’assistant peut envoyer des messages, modifier des dossiers ou utiliser des outils, exercez ces fonctions avec des comptes d’essai et des destinations dans un environnement isolé. Confirmez que chaque outil dispose seulement des accès nécessaires à sa tâche. Tentez une action hors du périmètre convenu et vérifiez que le système la bloque réellement. Une réponse disant « je ne le ferai pas » ne suffit pas.
Lorsqu’une approbation humaine est requise, elle doit préciser la cible, la portée et les valeurs de l’action. Dans un essai contrôlé, modifiez ces détails après l’approbation et vérifiez que l’autorisation initiale ne permet pas l’action modifiée. Testez aussi l’annulation, les défaillances d’outils et les tentatives répétées. Définissez des limites de durée, de coût et de nombre d’appels d’outils pour éviter qu’une erreur entraîne une boucle sans fin. Prévoyez un moyen concret de désactiver l’intégration.
Conserver les preuves nécessaires à la décision
Pour chaque cas, notez le résultat attendu, la réponse ou l’action observée, le rôle du compte, la configuration pertinente et le verdict : réussite, échec ou résultat non concluant. Consignez la version du modèle ou du service si elle est accessible, ainsi que la date, les sources et les outils connectés. Répétez les cas importants : le comportement d’un modèle peut varier d’une exécution à l’autre.
Un compte rendu utile distingue les problèmes qui empêchent le lancement du pilote des correctifs moins urgents. Il nomme un responsable et précise comment chaque correction sera vérifiée. Reprenez les cas en échec après une modification et répétez les essais pertinents lorsque le modèle, les instructions, les autorisations, les documents ou les outils changent.
Un exercice limité éclaire une décision sur un pilote défini; il ne démontre pas l’absence de vulnérabilités. Faites ressortir les zones non testées et les risques qui restent à traiter. Il s’agit de conseils généraux de préparation, et non de conseils juridiques ou d’une opinion d’audit. Confirmez les exigences d’assurance propres à votre secteur auprès d’une personne qualifiée.
Source: https://genai.owasp.org/resource/owasp-genai-llm-top-10-2026/. Conseils généraux de préparation; il ne s’agit pas de conseils juridiques.