Anthropic vient de mettre en avant une étude qui montre un résultat qui n'est pourtant pas très flatteur pour les outils assistés par IA. L'étude menée par Judy Hanwen Shen et Alex Tamkin cible un cas bien précis : l'apprentissage d'une nouvelle bibliothèque pour le développement (dans le cas présent, en Python). Les développeurs devaient produire du code avec ou sans IA, et ensuite répondre à des questions sur la compréhension du code en question.

Les résultats ne sont pas totalement surprenants, mais révélateurs sur le domaine de l'apprentissage. Les développeurs qui ont utilisé l'IA ont certes produit le code plus rapidement, mais la différence était marginale : environ deux minutes de moins. Mais sur la compréhension du code, le résultat est par contre significativement visible : environ 17 % moins bon.

L'étude se concentre sur 52 développeurs, essentiellement des profils « junior », c'est-à-dire globalement des débutants. Ils connaissaient le Python (le langage utilisé) mais pas la bibliothèque (Trio). La préparation (10 minutes) se faisait sans IA, le développement lui-même (environ 35 minutes) avec ou sans IA (selon le groupe), le quiz se faisait sans IA, tout comme le sondage en fin d'enquête.

Dans le questionnaire final, donc, les personnes ayant travaillé avec l'IA étaient donc moins bien notées que celles ayant travaillé sans IA. Sur le temps de développement, la différence moyenne est de deux minutes, sur des tâches qui prenaient un peu moins de 21 minutes à un peu plus de 25 minutes (avec l'aide de l'IA) ou un peu moins de 22 minutes à un peu plus de 27 minutes sans IA. L'étude complète est disponible sur Arxiv.

La compréhension dépend des choix par rapport à l'IA

Dans les utilisateurs de l'IA, les développeurs ont passé parfois un temps significatif (30 % de celui alloué) pour poser des questions à l'assistant. Certains ont utilisé l'IA pour rédiger totalement le code, d'autres ont posé des questions avant de le faire rédiger, et une partie a rédigé le code avant de le faire corriger par l'IA. Dans tous ces cas de figure, les résultats sur la compréhension du code sont logiquement mauvais (ils sont dans la moyenne basse des résultats au questionnaire). D'autres ont choisi de générer le code mais de demander des explications à l'assistant pour comprendre son fonctionnement. Enfin, certains ont posé des questions sur les tâches pour des explications, avant de concevoir le code. Il y avait plus d'erreurs, mais une meilleure compréhension du résultat (dans la moyenne haute des résultats, mais en dessous des développeurs qui n'ont pas employé l'IA).

Bien évidemment, il ne faut pas généraliser : travailler avec l'IA ne rend pas nécessairement les développeurs moins bons, et les gains en productivité peuvent être significatifs (Anthropic parle de 80 % de gains, probablement dans des cas très précis). Qui plus est, l'échantillon reste assez faible, sur un cas assez précis. Mais l'étude montre tout de même une chose, qui semble assez évidente : la pratique améliore la compréhension du code pour les débutants. Une des suggestions d'Anthropic serait donc de ne pas déployer les outils assistés par IA pour tous les développeurs, et de laisser les profils débutants développer par eux-mêmes, pour qu'ils puissent améliorer leurs compétences.

Si Apple tend à prendre en charge ses appareils de plus en plus longtemps, avec un suivi qui remonte parfois plus de dix ans en arrière, ça n'a pas toujours été le cas. Le premier iPad, par exemple, a été lancé sous iOS 3 et la dernière mise à jour officielle est iOS 5.1.1, après moins de deux ans et demi de suivi. Mais john (nyan_satan sur X) a décidé de passer outre les limites d'Apple : il a porté iOS 6 sur le premier iPad.

Il avait déjà fait la même chose avec l'iPod touch de troisième génération, un iPod touch qui était assez proche de l'iPhone 3GS mais était resté bloqué sous iOS 5, contrairement à l'iPhone. Le programme qui permet cet exploit est open source et nécessite une version précise d'iOS 6, la 6.1.3. Il a utilisé une version d'iOS pensée initialement pour l'iPad 2. Il n'indique pas si tous les composants fonctionnent, mais la version cellulaire voit visiblement son modem être désactivé.

Un hacker porte iOS 6 sur l'iPod touch 3G, qui n'avait jamais pu en profiter

Pour le reste, c'est certes un exploit, mais c'est surtout assez vain. Le premier iPad était limité techniquement avec sa puce A4 et ses 256 Mo de RAM, et passer à iOS 6 plutôt qu'iOS 5 ne change rien au problème : la tablette est globalement inutilisable avec les sites web actuels (bien trop lourds) et les certificats nécessaires pour des connexions sécurisées sont absents. Pour les applications, celles de l'époque peuvent encore fonctionner, mais ce n'est pas systématique : les apps qui reposent sur des serveurs sont souvent bloquées car la connexion est impossible ou parce que les technologies employées ont été modifiées depuis. Et rappelons que si l'iPhone 4 (équipé du même système sur puce, mais avec 512 Mo de RAM) a bien reçu iOS 7 à l'époque, ce n'était pas très utilisable.

Enfin, le premier iPad est plutôt une exception dans la gamme : la prise en charge a été nettement plus longue sur la majorité des tablettes. L'iPad 2 (lancé sous iOS 4) a été mis à jour jusqu'à iOS 9 par exemple, et la majorité des modèles a reçu sept à huit ans de mise à jour.

Une bonne nouvelle pour les amateurs de vidéos récupérées sur Internet (et de la TNT française) vient de tomber : le dernier brevet sur le Dolby Digital Plus, connu aussi sous le nom eAC3¹, est expiré. Et pour le monde libre, c'est un pas important : il va enfin être possible de proposer un décodeur open source sans se poser la question de la légalité de ce dernier.

Le problème de l'eAC3 (et du Dolby Digital avant lui) est simple : il était protégé par des brevets, et Dolby vend des licences pour décoder les deux codecs. Il existe des décodeurs open source depuis très longtemps, mais la distribution a toujours été hasardeuse. Dans les pays où les brevets logiciels sont reconnus, comme aux États-Unis, distribuer un décodeur eAC3 sans licence pouvait amener de nombreux problèmes, et c'est la raison pour laquelle VLC iOS — par exemple — ne lisait pas le Dolby Digital au milieu des années 2010. Comme les apps iOS sont techniquement hébergées aux États-Unis, VLC iOS ne pouvait pas intégrer de décodeur open source pour le Dolby Digital (contrairement à la version Mac).

À l'époque, c'est Apple qui avait réglé le problème : iOS 9.3 avait intégré un décodeur Dolby Digital Plus, avec une licence payée à Dolby. Dans la pratique, en 2026, les distributions GNU/Linux n'intègrent pas toujours de décodeur Dolby Digital Plus en standard, et de nombreux appareils ne décodent pas le codec, sauf en payant une licence (comme chez Archos en son temps).

Un problème de TNT

En France, le problème est plus prégnant que dans d'autres pays, pour une raison simple : la diffusion hertzienne (TNT) utilise le codec sur la majorité des chaînes depuis le passage en HD². Si vous avez un téléviseur, un décodeur externe ou un tuner (USB, par exemple) dont la partie logicielle ne décode pas l'eAC3, vous vous retrouverez sans son sur la majorité des chaînes. Un problème assez courant dans les années 2010, mais qui peut encore arriver si vous vous basez sur des solutions libres.

Techniquement libre

Comme l'AC3 en son temps (le dernier brevet date de 2017), l'eAC3 est donc techniquement libre. Phoronix explique que le dernier brevet qui protégeait l'eAC3 a expiré fin janvier. Les distributions GNU/Linux et les logiciels libres devraient donc pouvoir (enfin) intégrer un décodeur open source sans subir les foudres de Dolby et sans passer par des solutions détournées, comme pour FFMPEG.

Attention tout de même à un point : si l'eAC3 n'est plus protégé par des brevets, l'AC-4, lui, l'est encore. Il est utilisé notamment pour la TNT Ultra HD en France. Mais contrairement au Dolby Digital qui était employé (presque) partout, l'AC-4 reste assez rare en 2026.

Passage à la TNT 4K : le choix du Dolby AC-4 pourrait poser des soucis

Avec les AirTags 2, lancés il y a quelques jours, Apple a ajouté une nouvelle fonction aux Apple Watch : la puce U2 (pardon, la puce Ultra Wideband de 2e génération) intégrée dans les montres dès l'Apple Watch Series 9 peut enfin interagir avec les AirTags. Nous l'avons vu dans le test, Apple a ajouté un widget dans ce centre de contrôle qui permet d'obtenir la localisation précise d'un AirTag 2, équipé lui aussi de la puce U2. Une fonction réservée à la nouvelle balise… et uniquement à la nouvelle balise.

Test de l’AirTag 2 : deux fois plus facile à retrouver ?

Pourquoi le préciser ? Parce qu'un autre produit Apple intègre une puce U2 : le boîtier des AirPods Pro 3. Mais que ce soit avec la version actuelle de watchOS (26.2) ou la prochaine version (26.3, disponible en RC), la fonction est réservée aux AirTags 2. Le widget ne propose que les AirTags 2 et les apps Localiser de la montre (il y en a une dédiée aux appareils, une seconde pour les objets) ne proposent pas de détecter le boîtier des AirPods Pro 3.

La précision améliorée de la puce U2 est pourtant bien utile avec le boîtier, et il est parfaitement compatible avec tous les iPhone équipés. Mais peut-être qu'Apple va proposer une version remaniée des apps dans une future version de watchOS pour ajouter cette fonction.