Phishing Apple et MFA bombing & Attaque supply-chain autour de LiteLLM - Actualités Hacker News (2 avr. 2026)

On commence par cette histoire de phishing particulièrement instructive racontée par Matt Mullenweg. Le scénario démarre par une pluie de demandes de réinitialisation de mot de passe Apple — le genre de “fatigue MFA” où l’attaquant vous pousse à cliquer “autoriser” juste pour retrouver la paix. Puis ça monte d’un cran : les escrocs ouvrent un vrai dossier auprès du support Apple en se faisant passer pour lui, ce qui déclenche de vrais emails Apple, parfaitement légitimes, avec un vrai identifiant de dossier. Et ensuite, un appel entrant “Apple Support” donne des conseils plausibles avant d’envoyer un lien vers un faux site très bien copié… qui affiche même le bon numéro de dossier. Le point clé : des attaques qui s’appuient sur des workflows réels et des emails authentiques deviennent beaucoup plus difficiles à repérer. La défense la plus fiable reste simple : ne jamais valider une action non sollicitée, et vérifier les liens en allant soi-même sur le domaine officiel, pas via un SMS ou un appel entrant.

Dans la même veine “sécurité, mais à l’échelle”, Mercor confirme un incident lié à une compromission de la chaîne d’approvisionnement autour de LiteLLM, un projet open source très utilisé dans des stacks AI. L’intérêt — et le côté inquiétant — c’est l’effet domino : un paquet compromis peut toucher des milliers d’organisations en aval, parfois sans qu’elles aient l’impression d’avoir un “point d’entrée” direct. Ici, des revendications d’un groupe d’extorsion circulent, avec des échantillons de données supposées, tandis que l’entreprise parle de confinement et d’enquête avec des experts externes. Ce qu’il faut retenir : dans l’AI, l’infrastructure logicielle se construit souvent sur des briques communes, et une seule dépendance peut devenir un multiplicateur de risque. Ça renforce l’idée qu’auditer ses dépendances et surveiller son supply-chain n’est plus optionnel, même pour des équipes petites.

Côté open source toujours, un contributeur de la liste sécurité du noyau Linux signale un changement de rythme assez brutal : on serait passé de quelques rapports de vulnérabilités par semaine, à plusieurs par jour. Et cette fois, beaucoup de rapports seraient réellement valides — pas juste du bruit généré automatiquement. Résultat : plus de triage, plus de doublons, et une pression constante sur les mainteneurs. La discussion intéressante derrière les chiffres, c’est l’évolution de la stratégie : si des failles “redécouvrables” apparaissent en continu, l’embargo perd de sa valeur pour tout ce qui n’est pas critique, et on s’oriente vers des corrections publiques plus rapides, et des cycles de mise à jour plus réguliers côté utilisateurs. En clair : moins de débats sur l’étiquette, plus d’énergie sur le correctif et sur l’hygiène de maintenance à long terme.

On quitte un instant le logiciel pur pour une affaire qui touche la confiance, les assurances, et un écosystème entier : au Népal, la police fédérale, via le Central Investigation Bureau, décrit un réseau de fraude qui exploitait le système d’évacuation héliportée en haute altitude. L’accusation : des urgences médicales mises en scène, des évacuations déclenchées sous pression, et des factures d’hôpital gonflées, parfois soutenues par des dossiers médicaux falsifiés. Le mécanisme global ressemble à un marché de commissions : une partie des remboursements d’assurance repartirait vers des opérateurs de trek, des hôpitaux et des compagnies d’hélicoptères. Des poursuites ont été engagées contre plusieurs dizaines de personnes, avec des éléments comme des vidéos de surveillance contredisant des récits de “maladie critique”. Pourquoi c’est important ? Parce que si les assureurs internationaux perdent confiance, ce sont les voyageurs honnêtes qui paient via des primes plus élevées, des exclusions, ou des refus de couverture — et c’est tout le secteur du trekking qui en subit les conséquences.

Passons à l’éducation et au débat écrans contre papier. La Suède fait marche arrière après des années de numérisation agressive à l’école : retour des manuels physiques, accent sur l’écriture manuscrite, et tendance vers des écoles primaires sans téléphone. Le gouvernement insiste : ce n’est pas un rejet de la technologie, plutôt une tentative de la remettre à sa place — plus tard, et quand elle aide réellement. Ce qui motive le pivot, ce sont des inquiétudes sur l’attention, la lecture “en profondeur”, et les compétences de base chez les plus jeunes. Les recherches citées vont dans le sens que, pour certains types de textes, le papier favorise une meilleure compréhension que l’écran, surtout chez les enfants. La portée dépasse la Suède : beaucoup de pays s’apprêtent à ajouter encore plus d’outils numériques et d’AI à l’école, et ce genre de recul oblige à reposer la question : qu’est-ce qui marche vraiment, et à quel âge ?

Dans le monde de l’entreprise, un retour d’expérience chez Michelin retient l’attention : un ingénieur raconte pourquoi l’équipe a choisi Clojure pour concevoir un système de “référentiel” de données de production. L’idée n’était pas de faire original, mais de répondre à un besoin : beaucoup de structures de données qui changent, et des règles métiers complexes qu’on veut exprimer autrement que par un empilement de classes et de conditions. Avec une approche “code comme données”, ils ont pu modéliser des règles sous forme de descriptions modifiables, plus faciles à faire évoluer et à discuter en atelier. Et comme Clojure tourne sur la JVM, l’intégration avec du Java existant reste praticable. L’intérêt pour d’autres équipes : ce n’est pas une pub pour un langage, c’est un rappel que la productivité dépend souvent de la manière dont on représente le métier — et que des outils moins mainstream peuvent être pertinents, à condition d’y aller progressivement et de tenir compte de la montée en compétence.

Côté infrastructure, IBM et Arm annoncent une collaboration autour d’approches “dual-architecture” pour les environnements enterprise. Dit simplement : l’objectif est de rendre plus facile la cohabitation entre des logiciels pensés pour Arm et des plateformes IBM orientées disponibilité, sécurité et continuité d’activité. Pourquoi maintenant ? Parce que les besoins AI et data bougent vite, et que les grandes entreprises cherchent à gagner en flexibilité sans migrer brutalement ni remettre en cause des exigences comme la souveraineté des données ou l’uptime. Même si l’annonce reste très stratégique, le signal est clair : l’enterprise veut pouvoir déplacer des workloads et des environnements plus librement, et les acteurs historiques essaient d’éviter que l’innovation ne se fasse uniquement “ailleurs”, hors de leurs systèmes critiques.

On termine avec une histoire plus “méta”, mais révélatrice de l’époque : une analyse du dataset complet de Hacker News, environ 10 Go, explorée en s’appuyant sur Codex pour générer des requêtes et des scripts. Le résultat, ce sont des courbes de popularité de sujets dans le temps — pas seulement pour suivre des rivalités classiques entre technos, mais aussi pour tenter de mesurer des évolutions de comportement, comme la longueur moyenne des commentaires, qui semblerait diminuer progressivement. L’intérêt n’est pas de prendre ces graphiques comme vérité absolue, mais de voir à quel point des outils AI rendent plus accessible l’analyse d’un gros corpus réel, sans être un spécialiste des données. Et au passage, ça pose une question : si nos discussions en ligne deviennent plus courtes, est-ce qu’on échange mieux… ou juste plus vite ?