L’IA générative n’est plus seulement utilisée pour développer des malwares : elle alimente aussi leur exécution.

En novembre 2025, Google avait proposé une analyse à ce sujet. Il avait donné plusieurs exemples. Dont celui d’un dropper VBScript faisant appel à l’API Gemini pour l’aider à obscurcir son code.

L’analyse est reprise en source dans l’International AI Safety Report 2026. Il s’agit du rapport « officiel » préfigurant le Sommet de l’IA qui se tiendra en Inde du 16 au 20 février. Comme celui de l’an dernier, il donne un instantané de la compréhension scientifique des IA généralistes, sous l’angle de la sûreté. Parmi les experts impliqués, il y a, côté français, Jonathan Collas  conseiller industrie et numérique au SGDSN. Et Gaël Varoquaux (Inria), chef de projet pour le consortium Scikit-learn.

Pour cette édition, la définition des « risques émergents » a été restreinte. Il s’agit désormais de ceux « qui naissent à la frontière des capacités de l’IA ». Une manière, nous explique-t-on, de mieux se poser en complément à des initiatives telles que le panel scientifique de l’ONU sur l’IA.

Des IA plus persuasives, mais une influence « non démontrée à l’échelle »

Depuis l’an dernier, les systèmes dit de raisonnement se sont répandus. Les performances en mathématiques, code et sciences en ont particulièrement bénéficié. Côté méthodes d’entraînement, le rapport met en avant la distillation, avec l’exemple de DeepSeek-R1, dont les chaînes de pensée ont nourri DeepSeek-V3.

Des avancées, il y en a aussi eu sur le contenu que génèrent les IA. Constat, dans les grandes lignes : il est devenu plus difficile à détecter. Pour l’illustrer, le rapport cite, entre autres, les observations de chercheurs de l’université de Californie à San Diego sur un test de Turing avec GPT-4o. Dans 77 % des cas, les participants ont considéré comme d’origine humaine un texte en fait créé par le LLM.
Une autre expérience citée émane d’UC Berkeley. Elle a porté sur le clonage de voix. Dans 80 % des cas, les participants ont pris l’IA pour le locuteur d’origine.

Autre étude d’UC Berkeley, autre aspect : les capacités de persuasion dont les IA font preuve. Elles se montrent parfois plus efficaces que l’humain. Les preuves en ce sens « se sont accumulées » ces derniers mois, précise le rapport, qui en dresse un tableau récapitulatif. Centré sur les effets négatifs (propagande politique, notamment), il témoigne cependant aussi d’effets potentiellement positifs, dont la réduction de l’adhésion aux théories du complot.

L’efficacité du contenu IA par rapport au contenu que crée l’humain n’est toutefois pas démontrée à l’échelle, nous explique-t-on. Cela peut s’expliquer par le coût de distribution et par l’effet de balance que suscite, en conditions réelles, l’exposition à des points de vue antagonistes.

Cybersécurité : pas encore d’IA à tout faire, même si la détection de vulnérabilités est acquise

Sur le volet cyber, la difficulté à établir des relations de cause à effet complique l’estimation du rôle de l’IA dans la sévérité et l’échelle des attaques.

Les LLM se révèlent en tout cas performants pour découvrir des vulnérabilités. À ce sujet, on nous mentionne le dernier DARPA AI Cyber Challenge. Lors de cette compétition, un système agentique s’est hissé dans les hauteurs du classement en découvrant 77 % des failles.

Malgré ces progrès, aucune attaque intégralement autonome n’a pour le moment été signalée. Au moins un incident s’en est néanmoins approché. Il a impliqué les services d’Anthropic. Celui-ci s’en est fait l’écho en novembre 2025, estimant que l’attaquant avait automatisé, par ce biais, 80 à 90 % du travail, l’humain n’intervenant que pour des décisions critiques.

De manière générale, le rapport invite à ne pas surestimer le potentiel actuel des IA. Ne serait-ce que parce que la plupart des évaluations n’englobent que des compétences isolées ; pas des attaques de bout en bout. Jusqu’ici, les outils à disposition ont surtout accéléré ou mise à l’échelle des méthodes existantes.

L’évolution de la balance entre usages offensifs et défensifs dépendra des choix sur l’accès aux modèles, le financement de la recherche et les normes de déploiement. Le manque de méthodes standards d’assurance qualité pour les outils IA, par exemple, complique leur adoption dans des secteurs critiques. Alors que dans le même temps, les acteurs de la menace n’ont pas cette contrainte…

Conscience situationnelle ne rime pas avec perte de contrôle

Quant aux dysfonctionnements et aux risques que cela implique, il y a, dans le rapport, à boire et à manger.

Des références à plusieurs études rappellent que des modèles ont démontré des capacités de conscience situationnelle. Autrement dit, une aptitude à détecter l’environnement dans lequel ils évoluent. De là la possibilité de se comporter différemment dans un scénario d’évaluation que dans le monde réel. Ou à dégrader artificiellement ses performances pour éviter des restrictions de déploiement. Ou encore à contourner sciemment des garde-fous pour remplir à tout prix un objectif, tout en le niant par après.

Le risque d’une perte de contrôle sur le long terme demeure cependant faible, faute de capacités à maintenir un fonctionnement autonome sur la durée.
Certes, cette durée s’est allongée dans quelques disciplines, à commencer par le codage. Mais un seul grain de sable peut faire dérailler la machine, comme l’illustre une étude universitaire axée sur la perturbation des systèmes langage-vision à partir d’une pop-up.

Le biais d’automatisation s’amplifie

Concernant l’impact de l’IA sur le marché du travail, le rapport cite des études – au Danemark et aux États-Unis – qui n’ont pas démontré de corrélation forte. Mais il en mentionne aussi plusieurs ayant conclu à un déclin de la demande en profils juniors.

L’amplification du « biais d’automatisation » apparaît plus claire. Déjà prononcé avec les systèmes automatisés « non IA », le phénomène se perpétue au contact des LLM. Le rapport cite deux études qui en témoignent. L’une démontre la tendance des utilisateurs d’outils d’assistance à l’écriture à adopter le point de vue que suggère le modèle. L’autre met en lumière le processus des raccourcis mentaux : sur une tâche d’annotation assistée, les participants ont moins corrigé les suggestion erronées venant d’une IA lorsque cela exigeait un effort supplémentaire.

Illustration générée par IA

The post Sommet de l’IA 2026 : quelques points-clés du rapport scientifique « officiel » appeared first on Silicon.fr.

Si les assistants de codage ne font pas tant gagner en productivité, c’est parce qu’ils cannibalisent la phase pendant laquelle les écarts de spécifications sont le plus souvent détectés.

Certes, le constat émane d’une start-up américaine qui en a fait son fonds de commerce. Mais la réflexion qui y a abouti a son intérêt, notamment par les indicateurs dont elle s’est nourrie.

Trois stats pour poser le problème

La semaine dernière, cette start-up – Bicameral AI – avait publié un « manifeste », intitulé « Les assistants de codage résolvent le mauvais problème ». Elle avait ouvert son propos sur trois statistiques.

La première est sourcée d’Index.dev (plate-forme de recrutement tech). Bicameral AI la présente ainsi : les équipes ayant utilisé l’IA ont réalisé 21 % de tâches en plus, mais le delivery global – au niveau de leur organisation – ne s’est pas amélioré.

Index.dev a en fait lui-même tiré ce chiffre du rapport « The AI Productivity Paradox », que Faros AI (plate-forme de développement) avait publié à l’été 2025. Il apparaît que Bicameral AI en fait un résumé incomplet : le taux de 21 % vaut pour les équipes qui ont un usage important (« extensive ») de l’IA. Et le delivery est jugé spécifiquement sur les métriques DORA.

Deuxième statistique : les développeurs expérimentés ayant utilisé des assistants de codage ont été 19 % plus lents, alors qu’ils croyaient être plus rapides. Difficile de la vérifier : l’article qui en rend compte, publié en janvier 2025, n’est plus accessible. Son auteur : METR, organisation à but non lucratif qui étudie l’impact sociétal de l’IA. Sa fondatrice est une ancienne de DeepMind et d’OpenAI.

Troisième statistique : 48 % du code généré par IA contient des vulnérabilités. Elle est censée provenir d’Apiiro (un spécialiste de l’AppSec) et dater de 2024. Le lien que fournit Bicameral AI pointe toutefois vers un post de septembre 2025 qui ne donne pas directement ce chiffre. Apiiro a tout de même régulièrement donné des estimations proches (« plus de 40 % » en avril 2025, « jusqu’à 50 % » en août 2025…).

Quand l’IA fait perdre le temps qu’elle a fait gagner

Le manifeste se poursuit sur une référence à un fil Reddit avec près d’un millier de commentaires. Un développeur senior y témoigne de l’expérience – positive – de son équipe avec l’IA.

Bicameral AI pointe un des commentaires : le plus difficile n’est pas d’écrire le code, mais de gérer les cas particuliers qui se présentent au cours de l’implémentation. La start-up rebondit sur cet aspect : les assistants de codage sont connus pour ne pas faire remonter les écarts de spécifications, mais au contraire les dissimuler, affirme-t-elle. Par conséquent, on passe davantage de temps sur la revue de code… alors qu’avec l’IA, les managers en attendent davantage.

Dans ce contexte, le taux de développeurs considérant que les managers ne saisissent pas leurs points de douleur progresse nettement : 63 % en 2025, contre 49 % en 2024.

Ces chiffres proviennent du dernier sondage State of DevEx d’Atlassian. Bicameral AI le reprend pour annoncer que les assistants de codage font gagner aux développeurs près de 10 heures par semaine. Mais que l’accroissement des inefficacités sur le reste du cycle de développement anéantit presque ce gain.

Là aussi, la start-up fait un raccourci. Atlassian dit en fait que les outils GenAI en général font gagner au moins 10 heures par semaine à 68 % des développeurs. Mais qu’en même temps, 50 % perdent plus de 10 heures sur des tâches autres que le code*.

Ce fil conducteur mène Bicameral AI à une observation : le décalage entre intention métier et implémentation se crée lors des réunions produit. La start-up en veut pour preuve un sondage qu’elle a mené auprès de développeurs. Dans ce cadre, la majorité (63 %) ont déclaré découvrir des contraintes inattendues après s’être engagés sur l’implémentation.

Les écarts de spécifications, repérés surtout lors de l’implémentation

Les commentaires sur le manifeste et la collecte de réponses supplémentaires au sondage ont entraîné la publication, cette semaine, d’un deuxième article. Bicameral AI y confirme que le taux de développeurs découvrant les contraintes techniques au stade de l’implémentation est resté élevé (50 %).

La start-up mentionne un autre chiffre : 70 % déclarent que ces contraintes doivent être connues au-delà de leur équipe, auprès de populations qui n’interagissent pas régulièrement avec la codebase. Seulement, assure-t-elle, cette communication est difficile. Les pratiques de documentation des décisions n’aident pas : 52 % des répondants à son sondage transmettent les contraintes techniques par copier-coller sur Slack et 25 % les évoquent oralement, sans trace écrite. Plus globalement, 35 % des communications ne produisent aucun artefact persistant.

Bilan : dans la pratique, le conflit entre les specs produit et la réalité de l’engineering ne devient apparent qu’à la phase d’implémentation. Or, dès lors que l’IA phagocyte cette phase, le travail de découverte doit remonter à la phase de planification, sous peine de glisser sinon vers la phase de revue de code… et d’en être d’autant plus compliquée.

Le salut dans les prompts ? Le paradoxe de l’œuf et de la poule

Bicameral part ici du principe que les assistants de codage sont « accommodants » : ils peuvent demander des clarifications, mais ne suggèrent généralement pas d’explorer d’autres options.
« Il suffit de demander à l’IA de te challenger », a-t-on rétorqué, en substance, à la start-up. Elle y répond sous l’angle de l’œuf et de la poule : pour prompter correctement, il faut connaître au préalable la manière dont les contraintes techniques et produit peuvent entrer en conflit. Une connaissance qui, en l’état, ne fait donc essentiellement surface qu’à la phase d’implémentation…

Le traitement du problème en amont pourrait, contre-intuitivement au premier abord, s’appuyer sur des LLM. Lesquels examineraient comment une spéfication donnée pourrait impacter des structures de code existantes. Sur cette base, on pourrait imaginer un affichage en tant réel du contexte d’ingénierie pendant une réunion. Option qu’ont d’ailleurs suggérée certains participants au sondage.

* En 2024, IDC expliquait que le codage ne représentait que 16 % de leur temps de travail des développeurs. Contre 14 % pour l’écriture de spécifications et de tests, 13 % pour la sécurité, 12 % pour la surveillance des applications, etc.

Illustration générée par IA

The post Pourquoi les assistants de codage n’échappent pas au paradoxe de la productivité appeared first on Silicon.fr.

Les chercheurs en sécurité vont commencer à scanner les appliances connectées à Internet. Cela compliquera la détection des « vraies » tentatives d’exploitation.

L’avertissement est signé Ivanti. Il s’adresse aux utilisateurs de la solution EPMM (Endpoint Manager Mobile ; ex-MobileIron Core). En toile de fond, la découverte de deux vulnérabilités critiques. L’une (CVE-2026-1281) affecte la fonctionnalité de distribution interne d’applications. L’autre (CVE-2026-1340), la configuration du transfert de fichiers Android. Elles ont le même score de criticité (9,8)… et la même conséquence potentielle : l’exécution de code à distance sans authentification.

Ivanti en a révélé l’existence le 29 janvier, accompagnant son bulletin d’un correctif. L’éditeur déclarait alors qu’un « nombre très limité de clients » avaient été touchés. Peu après, un PoC était apparu.

« Considérer tout système comme compromis »

L’ANSSI néerlandaise (NCSC-NL) suit le dossier de près. Au fil des jours, elle est devenue plus alarmiste.

Le 2 février, l’agence avait noté que la vulnérabilité CVE-2026-1281 était activement exploitée. Elle recommandait aux utilisateurs d’EPMM de la joindre, le correctif n’étant pas suffisant en cas de compromission.

Le surlendemain, le NCSC-NL admettait que l’exploitation était « bien plus répandue qu’on ne le pensait ». Elle appelait tout simplement à considérer tout système comme étant compromis. Et ainsi à modifier les mots de passe de tous les comptes, à renouveler les clés privées et à surveiller le trafic interne.

Dans son dernier update, du 9 février, elle explique avoir identifié plusieurs organisations exploitant la vulnérabilité en question. Elle permet d’exfiltrer la base de données MIFS (MobileIron File Service). Et de récupérer ainsi des informations sur les appareils enregistrés. Notamment IMEI, numéros de téléphone et détails sur la SIM. Mais aussi utilisateurs LDAP et jetons d’accès et authentifiants Office 365.

Restaurer les sauvegardes… ou pas

Entre-temps, le NCSC-NL a contribué au développement d’un script de détection des intrusions. Ivanti l’a publié le 6 février, en parallèle d’IoC et de mesures de défense.

Sur les instances touchées avant la divulgation des vulnérabilités, on a découvert des fichiers malveillants dans le dossier racine, ainsi que dans /tmp et /var/tmp. Souvent d’un ou deux caractères, sans extension, parfois compressés avec 7z/LMZA2. Le favicon a par ailleurs été ciblé pour injecter un webshell.

Après la divulgation, les techniques se sont diversifiées, à tel point qu’il est difficile de les catégoriser en une liste d’IoC. Ivanti a toutefois observé un pattern consistant à créer des fichiers semblant être des pages d’erreur HTTP – par exemple, 401.jsp – pour héberger des webshells.

En date du 6 février, l’éditeur recommandait deux options en cas de compromission. Soit restaurer depuis des backups ou des instantanés de VM, soit construire un nouvel environnement et y migrer les données. Il conseillait aussi de changement le mot de passe de tout compte local et de remplacer le certificat public utilisé pour l’EPMM.

Du côté du NCSC-NL, on déconseille l’option restauration, au motif que les sauvegardes peuvent être compromises. Surtout si le script de détection produit des résultats…

La Commission européenne, victime probable

Le correctif n’entraîne pas d’indisponibilité, mais il ne survit pas à un saut de version. Ivanti promet de l’intégrer dans la prochaine release d’EPMM, prévue « au cours du premier trimestre 2026 ».

La Commission européenne n’a pas affirmé faire partie des victimes. Mais le 6 février, elle a déploré la compromission de « l’infrastructure centrale » utilisée pour gérer ses terminaux mobiles. Une attaque serait survenue le 30 janvier. Circonscrite « en 9 heures », elle pourrait avoir donné accès à des noms et à des numéros de téléphone.

Illustration générée par IA

The post La dernière faille Ivanti devient un poil à gratter appeared first on Silicon.fr.