Collaborer avec des LLM : où automatiser et où instaurer des garde-fous

La sécurité des LLM est devenue une question opérationnelle. Les modèles de langage s’intègrent aux opérations de sécurité, à la surveillance des fraudes et à l’ingénierie logicielle plus rapidement que les cadres destinés à les encadrer. Cet article examine les nouvelles surfaces d’attaque — de l’injection de prompt au dépassement du périmètre d’action des agents (agentic overreach) — et analyse ce que l’IA confidentielle, l’IA souveraine et l’IA digne de confiance peuvent réellement apporter.

Un schéma récurrent dans les récents reportages : un collaborateur demande conseil à un copilote d’intelligence artificielle dans le cadre d’une réponse à incident, le modèle formule avec assurance une recommandation erronée, et l’utilisateur humain la suit. Une telle erreur n’entraîne probablement pas de conséquences graves à chaque fois, mais dès qu’elle produit des dommages significatifs, elle fait immédiatement la une des médias. Amazon a relancé le débat sur l’utilisation responsable des agents d’IA générative à la suite d’une panne d’Amazon Web Services [1] ayant entraîné la perte de millions de transactions [2]. Parmi les causes identifiées figurait le fait que des agents d’IA avaient été autorisés à effectuer des modifications sur des systèmes de production sans validation humaine préalable. La base de données de production de McKinsey ainsi que sa plateforme interne d’intelligence artificielle Lilli ont été compromises par une attaque par injection de Magentic SQ [3], menée par CodeWall dans le cadre du programme public de divulgation responsable de vulnérabilités HackerOne de McKinsey [4].

Du chatbot expérimental à l’infrastructure opérationnelle

Les LLM ne sont plus de simples chatbots expérimentaux. Ils sont de plus en plus intégrés dans les processus opérationnels des organisations. Souvent, avant même que les collaborateurs soient correctement informés et formés, ils sont contraints, par les politiques internes de leur entreprise, d’utiliser ces outils et de collaborer avec eux. L’engouement autour des LLM a également poussé de nombreuses organisations à entrer dans une véritable course à l’adoption face à leurs pairs. Les LLM sont désormais présents dans de nombreux domaines : copilotes pour les centres opérationnels de sécurité (Security Operations Centers, SOC), surveillance des fraudes, conformité, support client ou ingénierie logicielle, pour ne citer que quelques exemples [5], [6]. Les êtres humains restent capables d’évaluer le niveau de criticité d’une situation de sécurité en fonction de la priorité des tâches et des processus opérationnels concernés. C’est précisément dans ces environnements imprévisibles que les limites des LLM apparaissent : leurs décisions reposent sur des calculs probabilistes visant à déterminer la suite la plus probable, et non sur une compréhension réelle du contexte. Dans les environnements à forts enjeux, il est donc établi que ces modèles ne peuvent qu’assister la prise de décision humaine.

Nouvelles surfaces d’attaque : ce qui distingue les LLM

Les LLM ouvrent de nouveaux points d’entrée que les logiciels classiques ne présentent pas, notamment l’empoisonnement des modèles (model poisoning), l’empoisonnement des données (data poisoning) et l’empoisonnement des requêtes (prompt poisoning) [7], [8]. Les principaux schémas observés sont les suivants :

• Injection de prompt : un attaquant modifie les instructions système fondamentales transmises au modèle.
• Désalignement des objectifs (goal misalignment) : les objectifs émergents d’un agent divergent des objectifs humains initialement définis ; l’optimisation d’un objectif apparemment inoffensif peut ainsi conduire à des résultats nuisibles.
• Fuite de données : des informations confidentielles sont divulguées au cours de l’exécution d’une tâche visant à atteindre un objectif donné.
• Récupération empoisonnée (poisoned retrieval) : le modèle est manipulé afin de favoriser certains contenus, marques ou URL spécifiques.
• Dépassement du périmètre d’action d’un agent (agentic overreach) : un agent se voit accorder un niveau d’action ou d’autonomie supérieur à celui qui était prévu.

Dans les systèmes logiciels classiques, les décisions reposent en grande partie sur des règles explicites et des mécanismes déterministes. Les LLM sont au contraire conçus comme des systèmes probabilistes : ils présentent des comportements émergents et génèrent des résultats dont la vérification reste difficile.

Le déficit de gouvernance

Il existe clairement un déficit de gouvernance dans l’adoption des LLM et dans leur intégration aux processus décisionnels. Les organisations déploient les LLM plus rapidement qu’elles ne mettent en place des cadres de sécurité, des mécanismes de surveillance, des procédures d’audit et des standards d’évaluation adaptés. Parmi les mesures couramment utilisées pour lutter contre les attaques visant les LLM figurent l’intervention humaine (human-in-the-loop), l’isolation par génération augmentée de récupération (Retrieval-Augmented Generation, RAG), les traces d’audit, l’évaluation des modèles, les tests adversariaux, l’explicabilité ainsi que les approches de déploiement respectueuses de la vie privée [7].

Trois axes pour avancer au-delà de la peur

Plutôt que de craindre les progrès des LLM, nous devons apprendre à mettre en œuvre les mesures nécessaires pour préserver notre sécurité. Il devient de plus en plus irréaliste de considérer les LLM comme de simples assistants inoffensifs. À mesure qu’ils s’intègrent dans des processus critiques, nous devons commencer à les considérer comme des infrastructures pertinentes du point de vue de la sécurité. Mais comment procéder ? Faut-il accepter des coûts d’utilisation plus élevés et dépendre de modèles propriétaires fermés, actuellement souvent plus puissants et plus efficaces que les modèles ouverts, au prix d’une perte de contrôle sur la confidentialité des données et la logique métier des organisations ? Ce n’est pas une direction durable. Les évolutions futures semblent plutôt s’orienter vers trois domaines complémentaires : l’IA confidentielle (Confidential AI), l’IA souveraine (Sovereign AI) et l’IA digne de confiance (Trustworthy AI).

IA confidentielle : protéger les données pendant l’inférence

Nous recourons de plus en plus fréquemment à des LLM déployés dans des environnements d’inférence cloud pour traiter des documents propriétaires, des interactions avec les clients ainsi que des bases de connaissances internes. Toutefois, l’inférence traditionnelle dans le cloud soulève des préoccupations importantes en matière de confidentialité des données, car des informations sensibles peuvent transiter par des infrastructures tierces ou être exposées par le biais de journaux système, de processus d’entraînement des modèles ou d’accès non autorisés. L’IA confidentielle (Confidential AI) répond à ces défis en associant des systèmes d’intelligence artificielle modernes à des technologies de sécurité permettant de protéger les données tout au long du cycle de vie de l’inférence.

Des modèles à poids ouverts, une condition essentielle de la souveraineté numérique

Plutôt que de s’appuyer sur un mécanisme unique, elle repose sur plusieurs couches de protection complémentaires, parmi lesquelles le calcul confidentiel (confidential computing) fondé sur des environnements d’exécution de confiance (Trusted Execution Environments, TEE) tels qu’Intel SGX, AMD SEV ou Nvidia GPU-CC, le chiffrement matériel des données au repos et en transit, une gestion sécurisée des identités et des accès, des communications chiffrées de bout en bout ainsi que des techniques d’apprentissage automatique visant à renforcer la protection de la vie privée, telles que l’apprentissage fédéré, la confidentialité différentielle et le calcul multipartite sécurisé [9].

Des plateformes telles que PrivateMode.ai illustrent cette évolution en permettant aux organisations d’exploiter les capacités de l’IA générative tout en conservant la maîtrise de leurs données stratégiques. En Suisse, des institutions publiques telles que l’Office fédéral de la statistique relèvent un défi similaire : exploiter le potentiel des données administratives pour des usages secondaires tout en garantissant strictement la protection de la vie privée. L’équipe développe notamment Lomas, une plateforme permettant l’analyse confidentielle de jeux de données sensibles — allant des dossiers médicaux aux statistiques sociales — sans exposer les données brutes. Les techniques de calcul confidentiel font également partie des approches étudiées par cette équipe.

Les modèles ouverts rattrapent progressivement leur retard. Le développement rapide des LLM à poids ouverts (open-weight LLMs) a considérablement élargi les possibilités de déploiement d’une IA confidentielle. Contrairement aux modèles commerciaux fermés, généralement accessibles uniquement par l’intermédiaire d’API cloud propriétaires, les modèles à poids ouverts permettent aux organisations de déployer, d’inspecter, d’adapter et de gouverner l’ensemble de la chaîne d’intelligence artificielle dans des environnements informatiques de confiance. Cette capacité revêt une importance particulière dans les secteurs traitant des informations sensibles ou soumis à des exigences réglementaires strictes, où la souveraineté des données, la transparence et l’auditabilité constituent des conditions essentielles. Parmi les exemples récents figure OLMo [10], une initiative de science ouverte portée par l’Allen Institute for AI (Ai2), qui met à disposition les poids des modèles, le code d’entraînement et les jeux de données afin de favoriser une recherche en IA reproductible. En Europe, EuroLLM [11] vise à développer des modèles fondamentaux multilingues à poids ouverts afin de renforcer la souveraineté technologique européenne tout en préservant la diversité linguistique du continent. Complétant ces initiatives orientées vers la recherche, des modèles et plateformes tels qu’ Apertus [12] se concentrent sur le déploiement sécurisé et la gouvernance des LLM, permettant aux organisations d’intégrer des modèles ouverts tout en conservant la maîtrise de leurs données sensibles. Ensemble, ces initiatives montrent que l’ouverture, la transparence et la capacité à déployer les modèles dans des environnements sécurisés deviennent progressivement des piliers centraux d’une IA digne de confiance.

IA digne de confiance : encadrer les modèles par des règles métier spécifiques

Un autre pilier essentiel de la sécurité des LLM consiste à concevoir des cadres d’IA digne de confiance (Trustworthy AI) capables d’encadrer les solutions d’intelligence artificielle au moyen de réglementations spécifiques au domaine, de connaissances métier et de garde-fous adaptés. À ce jour, il n’existe pas encore de solution systématique permettant de garantir une IA pleinement digne de confiance. Certaines approches reposent toutefois sur des ontologies spécifiques à certains secteurs, comme celle présentée dans [13], qui ne sont pas intrinsèquement interprétables par les machines. Notre équipe collabore avec Cuomo IT Consulting, qui dispose d’une solide base de clients dans les secteurs financier et médical et qui exprime un besoin important pour un cadre d’IA digne de confiance, intégré de manière automatisée, permettant de vérifier et de valider les réponses générées par les LLM.

Perspectives : des correctifs en continu

Nous sommes aujourd’hui à un tournant dans l’évolution des applications fondées sur les LLM. Comme lors des précédentes révolutions de l’ingénierie logicielle et des systèmes d’exploitation, cette transformation nécessite l’application constante de correctifs de sécurité. La situation est toutefois différente cette fois-ci : en raison de la nature générative et agentique des LLM, il peut être difficile de savoir précisément où, comment et à quel moment des informations confidentielles ont été exposées. Les mesures de protection les plus sûres semblent donc reposer sur une culture d’apprentissage et de formation continues, sur l’adoption de LLM véritablement ouverts — comprenant les données, les poids des modèles et les modèles eux-mêmes — ainsi que sur l’utilisation d’infrastructures informatiques conçues pour préserver la confidentialité des données.

Références

[1] B. Nolan, “An AI agent destroyed this coder’s entire database. He’s not the only one with a horror story,” Fortune. Accessed: Aug. 04, 2026. [Online]. Available: https://fortune.com/2026/03/18/ai-coding-risks-amazon-agents-enterprise/

[2] E. Kim, “Amazon orders 90-day reset after code mishaps cause millions of lost orders,” Business Insider. Accessed: Jul. 16, 2026. [Online]. Available: https://www.businessinsider.com/amazon-tightens-code-controls-after-outages-including-one-ai-2026-3

[3] “How We Hacked McKinsey’s AI Platform.” Accessed: Jul. 16, 2026. [Online]. Available: https://codewall.ai/blog/how-we-hacked-mckinseys-ai-platform

[4] “McKinsey & Company | Response Policy,” HackerOne. Accessed: Jul. 16, 2026. [Online]. Available: https://hackerone.com/mckinsey-company?type=team

[5] H. Xu et al., “Large Language Models for Cyber Security: A Systematic Literature Review,” ACM Trans. Softw. Eng. Methodol., Sep. 2025, doi: 10.1145/3769676.

[6] I. Hasanov, S. Virtanen, A. Hakkala, and J. Isoaho, “Application of Large Language Models in Cybersecurity: A Systematic Literature Review,” IEEE Access, vol. 12, pp. 176751–176778, 2024, doi: 10.1109/ACCESS.2024.3505983.

[7] M. Q. Li and B. C. M. Fung, “Security concerns for Large Language Models: A survey,” J. Inf. Secur. Appl., vol. 95, p. 104284, Dec. 2025, doi: 10.1016/j.jisa.2025.104284.

[8] J. Yan et al., “Backdooring Instruction-Tuned Large Language Models with Virtual Prompt Injection,” in Proceedings of the 2024 Conference of the North American Chapter of the Association for Computational Linguistics: Human Language Technologies (Volume 1: Long Papers), K. Duh, H. Gomez, and S. Bethard, Eds., Mexico City, Mexico: Association for Computational Linguistics, Jun. 2024, pp. 6065–6086. doi: 10.18653/v1/2024.naacl-long.337.

[9] F. Mo, Z. Tarkhani, and H. Haddadi, “Machine Learning with Confidential Computing: A Systematization of Knowledge,” ACM Comput. Surv., vol. 56, no. 11, p. 281:1-281:40, Jun. 2024, doi: 10.1145/3670007.

[10] D. Groeneveld et al., “OLMo: Accelerating the Science of Language Models,” in Proceedings of the 62nd Annual Meeting of the Association for Computational Linguistics (Volume 1: Long Papers), L.-W. Ku, A. Martins, and V. Srikumar, Eds., Bangkok, Thailand: Association for Computational Linguistics, Aug. 2024, pp. 15789–15809. doi: 10.18653/v1/2024.acl-long.841.

[11] P. H. Martins et al., “EuroLLM: Multilingual Language Models for Europe,” Procedia Comput. Sci., vol. 255, pp. 53–62, Jan. 2025, doi: 10.1016/j.procs.2025.02.260.

[12] P. Apertus et al., “Apertus: Democratizing Open and Compliant LLMs for Global Language Environments,” Dec. 01, 2025, arXiv: arXiv:2509.14233. doi: 10.48550/arXiv.2509.14233.

[13] C. B. Griesinger, V. Reina, D. Panidis, and H. Chassaigne, “AI evidence pathway for operationalising trustworthy AI in health: An ontology unfolding ethical principles into translational and fundamental concepts,” JRC Publications Repository. Accessed: Jul. 16, 2026. [Online]. Available: https://publications.jrc.ec.europa.eu/repository/handle/JRC140726