Comment les projets IA changent les règles de sécurité
Sommaire
Qu’elle soit prédictive, générative, agentique ou encore embarquée, l’Intelligence Artificielle (IA) force les équipes projet à maîtriser un nouvel ensemble de compétences et à s’adapter à de nouvelles méthodes de travail, à une nouvelle vision du projet et surtout à de nouveaux risques inhérents à ce type de système.
ISP : les impacts de l’IA
Un projet IA ne suit pas la même structure qu’un projet « classique » et, bien qu’il n’existe pas encore de consensus sur un modèle particulier, il est difficile de superposer le cycle de vie d’un projet IA à celui d’un projet sans IA, principalement à cause de leur nature itérative induite par la phase centrale qu’est l’entraînement du modèle.
Cette phase itérative d’entraînement représente un processus à part entière comprenant :
- La collecte des données d’entraînement
- Leur préparation/qualification
- La validation du modèle en fonction des objectifs définis dans la phase d’initialisation.
Toutes ces étapes apportent de nouveaux risques et nécessitent des précautions supplémentaires par rapport à un projet sans IA.
Autre grand changement : la phase de clôture laisse place à une phase dite de « retrait ». En effet, la nature des systèmes IA empêche leur mise à disposition aux utilisateurs si une supervision du système ne peut être assurée, ce qui empêche de clôturer le projet et de le laisser évoluer seul. La fin du projet ne peut donc se solder que par le retrait du système et, avec cette nouvelle approche, de nouvelles méthodes s’imposent.
Le dynamisme d’un projet IA bouscule complètement les processus de gestion de projet et vient briser la frontière entre le BUILD et le RUN. Par conséquent, l’ISP ne se limite plus aux bonnes pratiques de développement, à la définition d’objectifs et à la recette : l’IA impose également la gestion des risques intrinsèques à la chaîne d’approvisionnement et au RUN.
Ce risque « dynamique » induit que la surface d’attaque s’élargit désormais à l’ensemble du processus et donc que chaque phase du projet contient ses propres risques et, avec eux, ses bonnes pratiques.
Quelle menace pour quelle phase et quelle réponse ?
Des risques dès l’initialisation
La définition du besoin et du cas d’usage IA est déjà une étape importante : grâce à une analyse d’impact et à la rédaction en amont d’une politique d’usage de l’IA au sein de l’entité porteuse du projet, il est possible de se prémunir contre de multiples risques opérationnels et cyber, notamment l’autonomie excessive qui peut survenir si les fonctionnalités strictement nécessaires et les limites du système imaginé n’ont pas été correctement définies.
L’analyse d’impact est un nouveau livrable décrit dans l’ISO 42001 (Intelligence artificielle – Système de management) qui permet de définir, entre autres :
- Les impacts positifs et négatifs que le système est supposé avoir dans son fonctionnement nominal;
- Les erreurs / échecs prévisibles du système, leurs impacts potentiels et leur acceptabilité ainsi que les mesures prévues ou mises en place pour les réduire;
- La complexité du système, ses fonctionnalités et ses limites;
- Les moyens prévus pour la supervision humaine tout au long du cycle de vie du système;
- Les compétences du personnel assigné au projet.
Cette analyse doit être réalisée avant même le début de la conception afin de prévenir au maximum les risques inhérents à l’IA. De plus, elle permet de valider la pertinence de l’utilisation de l’IA au regard des risques qu’elle implique. Elle peut également être répétée lors du retrait du projet afin de faciliter la transition vers de nouvelles ou anciennes méthodes.
Cet élément permet également de prévenir toute manipulation conceptuelle qui pourrait intervenir dès le début du projet et causer des dégâts irréversibles en modifiant insidieusement le système.
La planification et la collecte de ressources
Une fois les objectifs définis et la pertinence de l’utilisation de l’IA confirmée, la collecte des nombreuses ressources nécessaires à l’IA peut commencer : hardware, modèles et données d’entraînement vont représenter l’essentiel des éléments à réunir pour le bon déroulement du projet et, dans un projet IA, la gestion des tiers gagne fortement en criticité.
En effet, le projet sera dépendant des fournisseurs de données et du modèle tout au long de son cycle de vie : de nouvelles données d’entraînement peuvent s’avérer nécessaires pour l’évolution ou le maintien du système et les modèles évoluent au fil du temps, provoquant régulièrement de nouveaux échanges avec les fournisseurs.
Les risques apportés par l’intégration d’entités externes peuvent être maîtrisés en choisissant des partenaires reconnus et, grâce à une bonne définition des rôles et responsabilités, les impacts en cas de problème peuvent être limités.
Cette étape de cadrage sera également utile pour définir les rôles internes spécifiques aux projets IA, notamment afin d’orchestrer la supervision du système en période de RUN.
Une analyse de risque pourra également être réalisée une fois les responsabilités définies. Elle pourra porter sur les fournisseurs mais aussi sur les utilisateurs finaux, dont les droits devront également être définis afin d’identifier les risques qui pèsent sur le système en cas d’usage malveillant.
En complément, le modèle et ses performances peuvent être testés avec des outils tels que « Decoding Trust » et des exercices de red teaming, qui peuvent être réalisés en fonction du cas d’usage prévu pour le modèle acquis.
L’entraînement et le réentraînement
L’entraînement représente un nouveau processus à part entière pour les projets IA et constitue même une phase critique : il est exposé à de nombreux risques capables d’affecter le projet entier et de provoquer des coûts très importants si un retour en arrière devient nécessaire.
De plus, si votre système est réentraîné sur les entrées des utilisateurs, le projet devient fortement exposé à l’empoisonnement ainsi qu’au vol de données ou du modèle.
Réduire ce risque peut se faire grâce à plusieurs mesures complémentaires. On peut par exemple :
- Tracer l’origine des données et vérifier leur légitimité à chaque étape de la conception du système;
- Appliquer des règles de sandboxing afin de prévenir l’accès au modèle par des données qui n’auraient pas encore été vérifiées et qualifiées;
- Tester la robustesse (capacité d’un système d’IA à maintenir son niveau de performance dans différentes circonstances d’utilisation) lors d’exercices de red teaming;
- Mettre en place des mécanismes de réduction des hallucinations et superviser le comportement du modèle durant le RUN.
Une bonne pratique qui permet non pas de réduire la vraisemblance de ce risque mais son impact consiste à conserver une version initiale du modèle entraîné. Ainsi, si une version ultérieure est sujette à un empoisonnement, il suffira de repartir de cette version fonctionnelle et ainsi d’éviter des coûts importants.
Sans cela, en cas d’empoisonnement du modèle, le système devra être retiré et le projet devra reprendre depuis la phase d’acquisition des ressources.
Le réentraînement, en plus d’être une phase du projet, représente également une mesure de protection contre un risque prégnant au machine learning : la dérive.
Il n’est en effet pas rare qu’un modèle d’IA se mette à produire des résultats indésirables après son déploiement. Le réentraînement permet alors non seulement d’améliorer le modèle mais également de corriger ses comportements indésirables.
Le run
Le RUN devient donc une partie intégrante du cycle projet pour plusieurs raisons déjà mentionnées :
- Le système se base sur des éléments dynamiques et évolutifs;
- Le réentraînement, nécessaire à l’évolution et au maintien du système, représente plus qu’une simple mise à jour;
- Après le déploiement, le système est exposé à des risques ayant la capacité de mettre en péril l’ensemble du projet.
La mise à niveau du modèle et des données en période de RUN va donc devenir prioritaire car le système sera exposé à un nombre élevé de risques (7 des 10 risques du TOP 10 OWASP LLM peuvent survenir pendant le RUN) tels que : l’injection de prompt, la fuite d’information, la désinformation, la consommation illimitée, le déni de service ou encore l’empoisonnement et le vol de données ou du modèle.
Se protéger contre ces risques ne passe pas uniquement par la mise en place de solutions techniques ou d’un processus de patch management : l’ensemble des précautions prises en amont du déploiement permet également de réduire la plupart des risques auxquels le système et le projet s’exposent durant le RUN.
Afin de détecter toute dégradation ou comportement indésirable, une supervision humaine doit être mise en place et les ressources nécessaires à cette activité devront être allouées conformément à l’étude d’impact réalisée en amont du projet. Cette surveillance sera d’autant plus importante si des impacts sur la sûreté des individus ont été identifiés.
Le retrait
Du fait des capacités et de la puissance d’un système IA ainsi que de l’importante quantité de ressources nécessaires à son développement, si le projet s’arrête, le système ne peut pas être laissé en production ou à disposition des utilisateurs.
S’amorce alors un processus de retrait plus complexe qu’un simple décommissionnement applicatif : il faudra, en plus de couper l’accès au système, s’assurer que le modèle, ses données et tous les artefacts liés au projet ont été supprimés ou rendus inexploitables.
En effet, chaque composante du système peut contenir des informations sensibles pouvant porter préjudice à l’entité porteuse du projet : propriété intellectuelle, données personnelles, moyens de reconstruction du modèle, pour n’en citer qu’une partie.
Il faudra donc mettre en place un processus de retrait sécurisé et complet permettant de s’assurer que chaque composant du système a bien été pris en compte.
Ce processus peut être complété par une nouvelle analyse d’impact qui se base non plus sur un concept ou un projet, mais sur une situation bien réelle avec un système ayant potentiellement évolué depuis sa conception.
Ces précautions ne seront suffisantes que dans le cadre d’un retrait anticipé. Si le système doit être retiré à cause d’une dérive ou d’une compromission, votre organisation devra s’adapter rapidement et, pour limiter l’impact d’un tel scénario, il sera pertinent de maintenir des solutions de travail sans IA afin d’assurer un mode dégradé.
Contributions normatives et communautaires
La communauté n’a pas tardé à produire des ressources permettant de guider la conception, la mise en place et l’exploitation de systèmes d’IA de manière sécurisée, qu’il s’agisse d’entreprises, d’institutions ou d’organisations publiques.
L’ensemble de ces contributions permet déjà de mettre en place des solutions et bonnes pratiques couvrant l’ensemble du cycle de vie d’un projet IA.
Notre méthode
Chez Néosoft, nous avons pris le temps d’analyser et de comprendre les particularités d’un projet IA afin de construire une méthode d’ISP adaptée à ces projets.
Cette méthode est alimentée par une base de connaissances construite à partir des différentes ressources et publications à notre disposition puis consolidée en fonction des cas d’usage de l’IA.
Elle est composée :
- d’une base de menaces;
- d’une base de risques;
- d’une base de bonnes pratiques à mettre en place tout au long du projet afin d’assurer un cycle de vie sécurisé.
Bibliographie
- Secure Software Development Practices for Generative AI and Dual-Use Foundation Models: An SSDF Community Profile. NIST SP 800-218A, NIST, juillet 2024
- OWASP Top 10 for LLM Applications 2025 OWASP, 18 Novembre 2024
- Technologies de l’information — Intelligence artificielle — Système de management ISO/IEC 42001 :2023, ISO/IEC, 18 décembre 2023
- Technologies de l’information — Intelligence artificielle — Recommandations relatives au management du risque ISO/IEC 23894 :2023, ISO/IEC, 06 février 2023