Cybersécurité de l’IA : 18 pays posent les bases du développement sécurisé

L’intelligence artificielle n’est pas seulement un outil capable de produire du texte, des images ou des recommandations. Elle devient aussi une cible : un système mal protégé peut être manipulé, ses données peuvent être altérées et ses composants logiciels peuvent servir de point d’entrée à des acteurs malveillants. Face à ce risque, 18 pays, dont la France, les États-Unis et le Royaume-Uni, ont soutenu le 26 novembre 2023 des lignes directrices communes pour développer des systèmes d’IA plus résistants aux attaques.

L’initiative marque une étape importante parce qu’elle place la cybersécurité au début du projet, et non à sa toute fin. L’objectif n’est pas de ralentir toute innovation en IA, mais d’éviter que la rapidité de lancement, les fonctionnalités ou la baisse des coûts ne prennent systématiquement le pas sur la protection des utilisateurs, des entreprises et des infrastructures qui emploient ces systèmes.

Un référentiel commun, pas un traité international

Le texte, porté par l’Agence américaine de cybersécurité et de sécurité des infrastructures, la CISA, et le Centre national de cybersécurité britannique, le NCSC, s’intitule Guidelines for Secure AI System Development. Il réunit des agences de cybersécurité de 18 pays autour d’un même principe : la sécurité doit être intégrée à toutes les étapes du cycle de vie d’un système d’IA.

Jen Easterly, directrice de la CISA, y voit « une étape clé dans notre engagement collectif des gouvernements du monde entier pour assurer un développement et un déploiement sécurisés des capacités d’IA dès leur conception ». Pour elle, le consensus est notable : les signataires reconnaissent explicitement que la sécurité ne peut être sacrifiée au profit de la fonctionnalité, de la rapidité de mise sur le marché ou de la réduction des coûts.

Il faut toutefois préciser la portée de l’annonce. Il ne s’agit ni d’une loi internationale ni d’un accord imposant des sanctions aux entreprises qui ne suivraient pas les recommandations. Le document propose un cadre volontaire, destiné à guider les développeurs, les fournisseurs de logiciels, les opérateurs de services et les décideurs publics.

Pourquoi la sécurité dès la conception est-elle essentielle ?

L’expression « sécurisé dès la conception », souvent résumée par l’anglais secure by design, renvoie à une idée simple : prévoir les menaces avant que le produit ne soit mis entre les mains du public ou d’une entreprise. En pratique, cela signifie que les équipes doivent identifier les scénarios d’attaque, protéger les données et contrôler les accès avant même la mise en service.

Cette approche est particulièrement importante pour l’IA. Un système de ce type repose sur de nombreux éléments : jeux de données, modèles entraînés, interfaces de programmation, serveurs, bibliothèques logicielles, outils de déploiement et fournisseurs externes. Une faiblesse dans l’un de ces maillons peut avoir des conséquences sur l’ensemble du service.

Les risques ne se limitent pas au vol d’informations. Des données utilisées pour entraîner ou ajuster un modèle peuvent être falsifiées. Une chaîne de logiciels insuffisamment vérifiée peut introduire une vulnérabilité. Des personnes malveillantes peuvent tenter de contourner les garde-fous d’un assistant, de récupérer des informations auxquelles elles ne devraient pas avoir accès, ou encore d’utiliser un outil d’IA à des fins abusives.

La cybersécurité ne doit donc pas être confondue avec la seule question de la fiabilité des réponses d’un modèle. Une IA peut produire une réponse erronée sans avoir été attaquée. Inversement, une IA techniquement performante peut devenir dangereuse si son infrastructure, ses données ou ses accès sont mal protégés.

Quatre étapes pour mieux protéger les systèmes d’IA

Les directives communes organisent la sécurité autour de quatre moments du cycle de vie : la conception sécurisée, le développement sécurisé, le déploiement sécurisé, puis l’exploitation et la maintenance sécurisées. Cette logique vise à empêcher que la protection soit reportée à une phase tardive, lorsque corriger une faille devient plus difficile et plus coûteux.

Concevoir en partant des menaces

Au stade de la conception, les organisations sont invitées à évaluer les risques liés à leur système et aux usages qu’il permettra. Il s’agit notamment de déterminer quelles données sont sensibles, qui pourra accéder au modèle, quels abus sont envisageables et quelles conséquences aurait une compromission.

Cette étape pousse aussi les responsables à attribuer clairement les responsabilités. La sécurité ne relève pas uniquement d’une équipe informatique appelée en urgence après un incident. Elle concerne les dirigeants, les concepteurs, les développeurs, les équipes chargées des données et les prestataires.

Développer sans fragiliser la chaîne logicielle

Pendant le développement, les lignes directrices insistent sur la protection des données, des modèles et des composants logiciels. Les fournisseurs utilisés par une organisation ont ici une importance particulière : un produit peut être solide sur le papier tout en dépendant d’une bibliothèque, d’un service hébergé ou d’un logiciel tiers vulnérable.

Le texte recommande donc de mieux contrôler les fournisseurs de logiciels et de protéger les éléments critiques contre la falsification. Cette vigilance concerne autant le code que les données utilisées par l’IA. Si des informations sont modifiées de manière malveillante, les résultats du système peuvent être altérés sans que le problème soit immédiatement visible.

Déployer avec des contrôles et des tests adaptés

Une IA ne devrait pas être rendue disponible sans évaluations de sécurité appropriées. Les signataires recommandent notamment de tester les systèmes avant leur publication et de prévoir des mécanismes de contrôle adaptés à leur niveau de risque.

Pour une entreprise, cela peut impliquer de limiter certains accès, de vérifier l’identité des utilisateurs ou de surveiller les interactions inhabituelles. Le principe est de réduire les occasions de détournement, tout en conservant une capacité à comprendre ce qui s’est produit si un incident survient.

Surveiller et corriger après le lancement

La sécurité ne s’arrête pas le jour où un outil est mis en ligne. Les recommandations invitent les opérateurs à surveiller les abus, à corriger les vulnérabilités découvertes et à maintenir leurs systèmes dans le temps. Cette dimension est essentielle dans un secteur où les logiciels, les attaques et les capacités des modèles évoluent rapidement.

Les 18 pays veulent créer une méthode partagée

Parmi les pays associés à cette initiative figurent l’Australie, le Canada, la République tchèque, l’Estonie, la France, l’Allemagne, l’Italie, le Japon, le Kenya, la Corée du Sud, les Pays-Bas, la Nouvelle-Zélande, le Nigeria, la Norvège, la Pologne, Singapour, le Royaume-Uni et les États-Unis.

L’intérêt d’une telle coopération tient au caractère mondial des services numériques. Un modèle peut être conçu dans un pays, entraîné grâce à des infrastructures réparties dans plusieurs autres, puis proposé à des utilisateurs sur tous les continents. Des pratiques radicalement différentes d’un territoire à l’autre compliqueraient la sécurisation de cette chaîne.

Le NCSC britannique présente ces premières directives comme le socle possible de travaux futurs. Elles ont vocation à aider les développeurs à prendre des décisions éclairées à chaque phase du projet, sans prétendre fournir une liste définitive de règles techniques. Au lancement de l’initiative, une centaine de partenaires issus de l’industrie, des gouvernements et d’organisations internationales devaient se réunir, parmi lesquels Microsoft, l’Institut Alan Turing et les agences de cybersécurité britannique, américaine, canadienne et allemande.

Ce que ces directives changent, et ce qu’elles ne règlent pas

L’apport principal de ces lignes directrices est d’établir un vocabulaire et des priorités partagés. Elles rappellent aux éditeurs de systèmes d’IA qu’ils doivent penser à la résistance aux attaques aussi sérieusement qu’aux performances du modèle. Pour les petites structures comme pour les grands groupes, ce cadre peut aussi servir de checklist pour repérer les oublis les plus fréquents.

Mais le texte laisse une grande marge d’interprétation. Ses recommandations sont générales et non contraignantes. Elles n’imposent pas de calendrier, de mécanisme de contrôle indépendant ni de pénalité en cas de non-respect. Leur effet dépendra donc de l’adoption réelle par les entreprises, les administrations et les fournisseurs de technologies.

Elles ne répondent pas non plus à toutes les questions soulevées par l’IA. La protection des droits d’auteur, les biais, la transparence des modèles, la responsabilité en cas de dommage ou l’impact sur l’emploi relèvent d’autres débats, souvent réglementaires. Les traiter séparément ne signifie pas qu’ils sont secondaires : cela montre plutôt que la gouvernance de l’IA repose sur plusieurs couches complémentaires.

Quel lien avec la Déclaration de Bletchley ?

L’annonce intervient quelques semaines après le sommet britannique sur la sécurité de l’IA, organisé à Bletchley Park. Le 1er novembre 2023, 28 pays, parmi lesquels les États-Unis, le Royaume-Uni, la Chine et des États membres de l’Union européenne, ont signé la Déclaration de Bletchley avec l’Union européenne.

Cette déclaration se situe sur un terrain plus large. Elle reconnaît que les systèmes d’IA les plus avancés peuvent créer des risques graves, voire catastrophiques, et appelle à une coopération internationale pour mieux les comprendre et les prévenir. Elle aborde donc les risques liés aux capacités de l’IA, à ses usages et à ses effets potentiels sur la société.

Les lignes directrices du 26 novembre sont plus opérationnelles sur le plan de la cybersécurité. Elles s’intéressent à la façon de construire et d’exploiter des systèmes difficiles à compromettre. Les deux textes poursuivent un objectif commun de prévention, mais ils ne sont ni équivalents ni interchangeables.

Ce qu’il faut surveiller

La question décisive, après cette déclaration commune, est celle de la mise en pratique. Les entreprises qui développent ou déploient de l’IA devront montrer si elles transforment ces principes en procédures concrètes : tests de sécurité, contrôle des dépendances logicielles, suivi des abus, protection des données et capacité à corriger rapidement une vulnérabilité.

Il faudra également observer si cette coopération entre agences nationales débouche sur des outils plus précis, des standards techniques ou des exigences communes pour les fournisseurs. À ce stade, les 18 pays ont surtout posé un principe politique et opérationnel clair : l’intelligence artificielle ne doit pas être sécurisée après coup. Sa protection doit faire partie de sa conception même.