IA capable de se propager : ce que l’expérience d’Anthropic démontre — et ses limites

La question n’est pas de savoir si un téléviseur va soudain développer une volonté propre. Elle est plus concrète : des capacités d’IA pourraient-elles aider un programme à s’installer sur différents appareils, puis à en rejoindre d’autres ? Le compte rendu de Mon Carnet sur les travaux attribués à des chercheurs d’Anthropic décrit plusieurs expériences qui éclairent cette question. Elles montrent des briques techniques préoccupantes, mais pas une IA malveillante déjà autonome et répandue dans la nature.

Une démonstration de calcul distribué, pas un virus autonome

Un premier problème est matériel : un modèle peut-il fonctionner sans un serveur puissant, en répartissant le calcul entre de petits appareils ? Dans l’expérience rapportée, quinze boîtiers Android TV ont fait tourner collectivement Gemma4-26B-A4B, un modèle de 26 milliards de paramètres, à environ 0,39 jeton par seconde. Chaque boîtier exécutait une partie du modèle. Le débit était faible, mais l’essai illustre qu’un groupe de machines modestes peut fournir ensemble des ressources de calcul qu’un appareil isolé ne possède pas.

Cette distinction compte pour interpréter le risque. Faire fonctionner un modèle sur plusieurs machines n’équivaut pas à lui faire trouver ces machines, obtenir un accès, s’installer et recommencer sans intervention humaine. Le premier essai portait sur la capacité de calcul collective ; il ne démontrait pas, à lui seul, une chaîne de compromission autonome. Une IA distribuée est une possibilité d’architecture, pas la preuve qu’un réseau d’objets connectés est déjà devenu son hôte.

Le scénario de propagation repose sur plusieurs étapes

Un ver informatique classique suit généralement des instructions prévues pour rechercher ou exploiter certaines failles. Le scénario décrit est plus adaptable : un agent pourrait examiner un environnement, reconnaître le matériel, choisir des logiciels compatibles, résoudre des erreurs d’installation et tenter de poursuivre son chemin. Les modèles ne remplaceraient pas les appareils vulnérables ni les accès nécessaires ; ils pourraient automatiser une partie du travail de préparation et d’adaptation.

Les expériences résumées séparent justement certaines de ces étapes. Un modèle de neuf milliards de paramètres aurait configuré un environnement d’exécution dans huit des neuf catégories de matériel testées. Dans un autre essai, GLM-5.2 a orchestré une réplication dans un réseau fermé de huit machines virtuelles Android et atteint les huit machines lors de quatre essais sur cinq. Mais le réseau simplifié avait des accès sans authentification, l’agent qui dirigeait les opérations tournait sur un serveur distinct et le modèle propagé était un autre modèle. Ce montage ne prouve donc pas qu’un modèle unique peut, de bout en bout, se copier et se répandre seul sur des appareils du monde réel.

Ce que signifie l’adaptation d’une génération à l’autre

Un autre résultat rapporté concerne la transmission de notes et de solutions pratiques entre des instances successives d’un agent. Le taux de réussite d’une tâche d’installation est passé de 45 % à des résultats compris entre 61 % et 84 % au fil des générations. Cette progression ne signifie pas que le modèle modifiait spontanément ses paramètres. Les copies pouvaient réutiliser les instructions et les connaissances accumulées par leurs prédécesseurs.

Pour un développeur, la nuance évite de confondre deux mécanismes. L’apprentissage du modèle, au sens d’une modification de ses paramètres, n’est pas la même chose que la conservation d’un état externe : notes, procédures ou solutions déjà trouvées. Un agent peut devenir plus efficace dans une tâche répétée parce qu’il reçoit de meilleures indications, sans que son modèle ait été réentraîné. Dans une analyse de sécurité, il faut donc examiner aussi ce qui est transmis entre exécutions, et pas seulement le modèle utilisé.

Une projection à distinguer d’un résultat observé

Le compte rendu rapporte que les chercheurs projettent que les capacités nécessaires pourraient être réunies dans un modèle suffisamment compact d’ici la fin de 2026. C’est une projection fondée sur des tendances, pas une échéance garantie ni la constatation qu’un tel système existe déjà. Il rapporte aussi que certaines opérations pourraient prendre un à plusieurs jours sur du matériel modeste. Une propagation lente ne serait pas forcément négligeable si elle touchait de nombreux appareils, mais l’ampleur réelle dépendrait des accès, des vulnérabilités et des protections présentes.

Le risque redouté tient notamment à la différence entre une architecture centralisée et une architecture répartie. Un service centralisé peut dépendre de serveurs identifiables ; un système réparti entre de nombreuses machines pourrait être plus complexe à isoler et à arrêter. Cela décrit une difficulté potentielle de réponse à incident, non une invulnérabilité. La taille des modèles et leurs communications peuvent aussi rendre certaines opérations plus visibles, selon le compte rendu.

Les mesures de sécurité déjà pertinentes

Les recommandations rapportées concernent des contrôles concrets : supprimer les mots de passe par défaut, protéger les interfaces d’administration et surveiller les échanges inhabituels entre appareils. Ce sont des mesures de sécurité des objets connectés, pas une garantie contre tout scénario impliquant une IA. Elles réduisent surtout des conditions qui pourraient faciliter l’accès ou rendre une activité anormale plus difficile à repérer.

• Pour les fabricants : éviter les identifiants par défaut et renforcer la protection des interfaces d’administration.
• Pour les opérateurs de réseau : repérer les communications inhabituelles entre appareils, sans assimiler toute anomalie à une attaque confirmée.
• Pour les développeurs : distinguer, dans une évaluation, le calcul distribué, la préparation d’un environnement et la propagation effective ; documenter les hypothèses de réseau et d’authentification.

Une équipe qui évalue des agents logiciels dans un environnement contrôlé peut aussi consulter notre méthode pour préparer un bac à sable pour agents IA. Ce cadre concerne les essais d’agents de développement ; il ne constitue pas une solution directe à la sécurité des appareils connectés.

Checklist pour lire les résultats sans les surinterpréter

• La démonstration porte-t-elle sur le calcul, l’installation, l’accès à des machines ou la chaîne complète ?
• Le réseau est-il réel ou simulé, et les accès sont-ils protégés par authentification ?
• L’agent qui décide et le logiciel qui se propage sont-ils le même modèle ?
• Le chiffre présenté est-il un résultat expérimental ou une projection attribuée aux chercheurs ?
• Les résultats décrivent-ils une attaque observée, ou une capacité testée dans un cadre limité ?

À ce stade, les éléments rapportés justifient de prendre au sérieux la sécurité des appareils connectés et l’automatisation de tâches offensives. Ils ne justifient pas d’affirmer qu’une IA se réplique déjà librement dans les foyers. Pour les équipes techniques, la conclusion utile est plus précise : évaluer séparément les capacités qui composent le scénario, vérifier les hypothèses de chaque démonstration et ne pas confondre une projection avec une attaque constatée.