Sécurité de l’IA dès la conception : la méthode 2026

70 % des entreprises n’intègrent pas la sécurité dès la conception de leurs systèmes d’IA, selon un fait établi publié par Brief IA le 19 octobre 2026. Cette lacune expose les projets à l’empoisonnement des données, aux attaques adversariales, aux fuites d’informations et aux erreurs de décision.

La méthode 2023 reste utile pour structurer une démarche concrète : identifier les risques avant de choisir un modèle, contrôler les données, limiter les permissions, tester les attaques et surveiller le système après sa mise en production. Les évolutions réglementaires européennes rendent désormais cette approche directement opérationnelle pour de nombreux systèmes à haut risque.

Pourquoi la sécurité doit être décidée avant le premier modèle

La sécurité d’un système d’IA ne se résume pas à protéger son serveur ou son API. Elle concerne toute la chaîne, depuis la collecte des données jusqu’aux réponses générées, en passant par le fine-tuning, les composants externes, les outils appelés par le modèle et les utilisateurs autorisés.

Une correction tardive coûte généralement plus cher qu’un contrôle intégré au début du projet. Lorsque les données, les prompts, les journaux et les droits d’accès ont déjà été configurés sans exigences de sécurité, l’équipe doit souvent modifier l’architecture, reprendre les jeux de données et réévaluer le comportement du modèle.

Le risque est également métier. Une réponse erronée dans un assistant interne n’a pas le même impact qu’une décision automatisée dans le recrutement, le crédit, la santé ou la sécurité. La première étape consiste donc à définir précisément ce que le système peut faire, pour qui, avec quelles données et dans quelles limites.

À retenir : la sécurité commence par le cadrage du cas d’usage. Un modèle performant ne compense pas un périmètre mal défini, des données non vérifiées ou des permissions excessives.

La fiche de cadrage minimale

Avant tout entraînement ou déploiement, documentez au moins :

• La finalité exacte du système et les décisions qu’il peut influencer.
• Les catégories de données utilisées, leur origine et leur niveau de sensibilité.
• Les utilisateurs, services et fournisseurs pouvant accéder au système.
• Les actions que le modèle peut déclencher, directement ou via des outils.
• Les conséquences d’une réponse fausse, manipulée, indisponible ou divulguée.
• Les critères permettant de suspendre le système ou de revenir à une version précédente.

Cette fiche devient le point de départ du registre des risques. Elle permet aussi de distinguer un assistant de recherche documentaire d’un agent capable d’envoyer des courriels, de modifier une base de données ou d’exécuter une commande.

Les données constituent le premier périmètre de défense

Un modèle ne peut pas être sécurisé si les données qui l’alimentent ne sont ni traçables ni contrôlées. L’empoisonnement des données désigne l’introduction volontaire ou accidentelle de contenus destinés à modifier le comportement du modèle, à créer une porte dérobée ou à orienter les résultats.

Le risque concerne les données d’entraînement, les jeux de fine-tuning, les documents importés dans une base documentaire et les contenus récupérés par un système RAG, c’est-à-dire une architecture qui recherche des documents avant de produire une réponse.

OWASP classe l’empoisonnement des données et des modèles parmi les risques majeurs des applications utilisant des LLM. Une base documentaire interne peut ainsi devenir un vecteur d’attaque si un fichier falsifié est ajouté, si sa provenance n’est pas contrôlée ou si son contenu est récupéré sans filtrage.

Contrôles à intégrer dans le cycle des données

• Conserver la provenance de chaque fichier, enregistrement ou corpus.
• Versionner les jeux de données et enregistrer chaque modification.
• Séparer les environnements de collecte, de préparation et de production.
• Vérifier l’identité des contributeurs et limiter les droits d’écriture.
• Détecter les doublons, les contenus anormaux et les instructions dissimulées.
• Effectuer une validation humaine pour les données critiques.
• Conserver une copie saine permettant de restaurer rapidement une version antérieure.

La séparation des rôles est essentielle. La personne qui collecte les données ne devrait pas être la seule à pouvoir les valider et les publier dans l’environnement de production.

Le cas particulier du RAG

Dans un système RAG, la réponse dépend autant du moteur de recherche que du modèle génératif. Il faut donc tester les documents eux-mêmes, la segmentation, les métadonnées, les règles de filtrage et le classement des résultats.

Un document peut contenir une instruction destinée au modèle plutôt qu’une information utile à l’utilisateur. Le système doit traiter les documents récupérés comme des données non fiables, et non comme des ordres prioritaires.

Les contrôles recommandés comprennent la restriction des sources autorisées, la validation des droits d’accès document par document, la journalisation des passages récupérés et le filtrage des contenus susceptibles de contenir des instructions malveillantes.

Les attaques adversariales exigent des tests dédiés

Une attaque adversariale cherche à provoquer une erreur du modèle au moyen d’une entrée spécialement construite. Dans l’IA générative, les attaques peuvent prendre la forme d’une injection de prompt, d’une instruction cachée dans un document, d’une tentative d’extraction du prompt système ou d’une demande conçue pour contourner les règles de sécurité.

La méthode 2023 doit donc prévoir des tests négatifs avant la mise en production. Il ne suffit pas de vérifier que le système répond correctement aux demandes normales : il faut aussi mesurer sa résistance aux demandes ambiguës, contradictoires, malveillantes ou excessivement longues.

Une campagne de tests utile

Construisez un corpus de tests couvrant plusieurs familles :

• Injection directe : l’utilisateur tente de remplacer les instructions du système.
• Injection indirecte : une instruction malveillante est placée dans un document ou une page récupérée.
• Extraction d’informations : le modèle est incité à révéler des données sensibles ou des instructions internes.
• Contournement : l’utilisateur reformule une demande interdite pour éviter les filtres.
• Manipulation du contexte : plusieurs documents contradictoires sont fournis au système.
• Abus des outils : le modèle tente d’appeler une fonction avec des paramètres dangereux.
• Déni de service : des entrées très longues ou répétitives provoquent une consommation excessive.

Chaque test doit posséder un résultat attendu, un niveau de gravité et un responsable. Les échecs doivent être reproduits après chaque changement de modèle, de prompt, de connecteur ou de base documentaire.

Du test manuel au red teaming

Les vérifications manuelles sont utiles pour commencer, mais elles ne suffisent pas pour un système exposé à de nombreux utilisateurs. Le red teaming consiste à rechercher activement des comportements dangereux avec des scénarios conçus pour contourner les protections.

Les tests doivent associer les équipes de sécurité, les développeurs, les responsables métier et, lorsque le risque le justifie, des évaluateurs indépendants. La qualité ne se mesure pas uniquement au nombre de refus : un système peut refuser trop peu, mais aussi refuser des demandes légitimes ou produire des réponses trompeuses malgré un refus apparent.

L’architecture doit limiter ce que le modèle peut réellement faire

Un modèle de langage ne doit pas disposer de droits supérieurs à ceux nécessaires à sa fonction. Cette règle devient critique lorsqu’il peut appeler des outils, consulter des bases ou déclencher des actions externes.

OWASP identifie notamment les risques liés à l’excès d’autonomie, à la divulgation d’informations sensibles, à la chaîne logicielle et au traitement dangereux des sorties. Une réponse générée ne doit jamais être considérée comme une commande sûre par défaut.

Les protections techniques prioritaires

• Accorder à chaque outil des permissions minimales et séparées.
• Exiger une validation humaine avant toute action irréversible.
• Utiliser des listes d’actions autorisées plutôt qu’un accès général.
• Vérifier les paramètres produits par le modèle avant exécution.
• Isoler les secrets, les clés d’API et les informations d’authentification.
• Limiter le nombre d’appels, le volume de données et le budget de calcul.
• Séparer les environnements de test et de production.
• Prévoir un mécanisme d’arrêt immédiat et un retour à une version sûre.

Un agent peut proposer une commande, mais un composant déterministe doit vérifier cette commande avant de l’exécuter. Pour une opération sensible, la validation humaine doit porter sur l’action exacte, ses paramètres et ses conséquences, pas seulement sur le texte produit par le modèle.

Le traitement des sorties

Les sorties doivent être échappées, validées et filtrées avant d’être transmises à une base de données, à un navigateur, à un système de paiement ou à une autre API. Une réponse apparemment textuelle peut contenir une charge exploitable si elle est insérée directement dans une requête ou une page web.

Le système doit aussi distinguer les faits vérifiés, les hypothèses et les réponses générées sans preuve. Pour les usages sensibles, imposez des citations internes, des contrôles de cohérence ou un transfert vers un opérateur lorsque le niveau de confiance est insuffisant.

La gouvernance transforme les contrôles en processus durable

La sécurité dès la conception échoue lorsque les exigences restent dans un document que personne ne consulte après le lancement. Il faut attribuer des responsabilités, définir des seuils d’acceptation et intégrer les contrôles aux outils de développement.

Le règlement européen sur l’IA impose aux systèmes à haut risque des exigences de gestion des risques, de gouvernance des données, de documentation technique, de journalisation, de supervision humaine, de précision, de robustesse et de cybersécurité. L’article 15 vise notamment la résistance à l’empoisonnement des données, aux modèles compromis, aux exemples adversariaux et aux attaques de confidentialité.

Répartition des responsabilités

Cette organisation évite de concentrer la responsabilité sur le seul fournisseur du modèle. L’entreprise qui intègre un modèle dans un processus conserve la maîtrise de son cas d’usage, de ses données, de ses accès et de ses décisions opérationnelles.

Les documents à maintenir

Conservez une fiche système, une description des données, les versions du modèle et des prompts, les résultats d’évaluation, les changements de configuration, les incidents et les décisions d’acceptation du risque.

La documentation doit être produite pendant le développement, et non reconstituée après un incident. Les journaux doivent permettre de comprendre quelle version du modèle, quelles données, quels outils et quelles règles ont participé à une réponse donnée.

Les audits et la formation réduisent le risque humain

Les audits permettent de vérifier que les contrôles prévus fonctionnent effectivement. Ils doivent couvrir la conception, le développement, le déploiement et l’exploitation, avec une attention particulière aux modifications qui changent le comportement du système.

Un audit utile ne se limite pas à la présence d’une politique. Il vérifie les permissions réelles, les traces disponibles, les jeux de tests, les procédures d’incident, la qualité des données et la capacité à suspendre le service.

Un calendrier d’audit adapté au risque

• Avant le lancement : revue de l’architecture, des données, des permissions et des scénarios d’attaque.
• À chaque changement majeur : nouvelle évaluation du modèle, du prompt, des outils ou du périmètre documentaire.
• Après un incident : analyse de la cause, correction, test de non-régression et décision de remise en service.
• Régulièrement en production : contrôle des dérives, des accès, des coûts et des comportements anormaux.

La formation complète ces contrôles. Les développeurs doivent connaître les injections de prompt, la gestion des secrets et la validation des sorties. Les utilisateurs doivent savoir quelles données ne pas transmettre, comment signaler une réponse dangereuse et quand demander une vérification humaine.

L’obligation de culture de l’IA prévue par le règlement européen est applicable depuis février 2025. Elle renforce l’intérêt d’une formation proportionnée aux fonctions exercées, plutôt qu’une sensibilisation générale sans mise en pratique.

Ce que le règlement européen change pour les projets d’IA

Le règlement européen sur l’IA est entré en vigueur le 1er août 2024 et s’applique progressivement. Les interdictions et les obligations de culture de l’IA s’appliquent depuis février 2025, tandis que les obligations concernant les modèles d’IA à usage général s’appliquent depuis août 2025.

Pour les systèmes à haut risque, l’approche de sécurité dès la conception devient particulièrement importante. Les exigences portent notamment sur la gestion des risques, la qualité des données, la documentation, la conservation des journaux, la supervision humaine, la robustesse, la précision et la cybersécurité.

Les sanctions prévues par le règlement peuvent atteindre 35 millions d’euros ou 7 % du chiffre d’affaires annuel mondial pour certaines pratiques interdites. Les autres manquements peuvent entraîner une amende allant jusqu’à 15 millions d’euros ou 3 % du chiffre d’affaires annuel mondial, tandis que la transmission d’informations incorrectes aux autorités peut atteindre 7,5 millions d’euros ou 1 %.

À retenir : la conformité ne remplace pas la sécurité technique, mais elle impose de démontrer que les risques ont été identifiés, traités, documentés et surveillés.

La feuille de route en 30 jours

Jours 1 à 5 : cadrer le système

Définissez la finalité, les utilisateurs, les données, les outils appelés et les conséquences d’une erreur. Classez les actifs sensibles et désignez les responsables.

Jours 6 à 10 : cartographier les menaces

Documentez les scénarios d’empoisonnement, d’injection, de fuite, d’abus des outils, de compromission de la chaîne logicielle et de déni de service. Attribuez un niveau de gravité et un propriétaire à chaque risque.

Jours 11 à 18 : réduire les permissions

Supprimez les accès inutiles, isolez les secrets, ajoutez des validations humaines et placez un contrôle déterministe entre le modèle et chaque action externe.

Jours 19 à 24 : tester les comportements dangereux

Créez un jeu d’évaluation reproductible, exécutez des scénarios adversariaux et vérifiez les sorties avant leur utilisation dans d’autres systèmes.

Jours 25 à 30 : documenter et surveiller

Finalisez les fiches système, activez les journaux, définissez les alertes et testez la procédure d’arrêt. Le lancement ne doit intervenir qu’après la validation des critères d’acceptation.

Notre avis : la méthode 2023 reste efficace si elle devient un réflexe produit

La faiblesse principale n’est pas l’absence de normes ou de techniques : c’est le décalage entre les principes affichés et les contrôles réellement exécutés. Une équipe qui vérifie les données, limite les permissions, teste les attaques et surveille les changements dispose déjà d’une base solide pour réduire les incidents les plus prévisibles.

Le seuil de 70 % d’entreprises qui négligent encore la sécurité à la conception montre surtout que le sujet doit quitter la seule équipe cybersécurité. Les responsables produit, les développeurs, les équipes data, les juristes et les métiers doivent partager les mêmes critères de lancement.

Dans les six prochains mois, les projets les mieux préparés seront ceux qui pourront démontrer leur chaîne de décision : quelles données ont été utilisées, quels tests ont été passés, quels accès ont été accordés, quelles alertes existent et qui peut arrêter le système. La question ne sera plus seulement de savoir si un modèle répond bien, mais si l’organisation peut prouver qu’il reste maîtrisable lorsqu’un utilisateur, une donnée ou un composant tente de le détourner.