Lettre ouverte et IA militaire & Sécuriser les agents IA par isolement - Actualités Hacker News (28 févr. 2026)

Commençons par le sujet le plus chargé politiquement: une lettre ouverte intitulée “We Will Not Be Divided”. Les auteurs—présentés comme des employés de Google et d’OpenAI—affirment que le Département de la Défense américain exercerait une pression sur Anthropic, notamment parce que l’entreprise refuserait deux usages: la surveillance de masse sur le territoire américain, et des systèmes capables de tuer de manière autonome sans supervision humaine. Le texte mentionne un levier très concret: la possibilité que le Pentagone invoque le Defense Production Act pour contraindre Anthropic à fournir, voire “adapter”, ses modèles. Pire: la menace de faire passer l’entreprise pour un “risque pour la chaîne d’approvisionnement”, une étiquette qui peut compliquer des contrats, des partenariats, et même l’accès à certains marchés. Et le point tactique de la lettre, c’est l’idée de division: si une boîte pense que ses concurrentes vont céder, elle peut être tentée de céder à son tour. D’où cet appel à une position commune—avec un objectif simple: maintenir un refus coordonné sur la surveillance domestique et sur l’autonomie létale sans humain dans la boucle. La page liste des centaines de signataires “vérifiés” —plus de 500 chez Google et près d’une centaine chez OpenAI dans le décompte affiché—avec la possibilité de signer anonymement tout en prouvant son emploi. Les organisateurs décrivent une infra minimaliste: hébergement Fly.io, base SQLite chiffrée, emails de vérification, appli Flask open source, pas de scripts d’analytics. Ils reconnaissent aussi des détails intéressants: un bug de vérification ayant permis un faux nom pendant un court moment, et des doublons que leur déduplication automatique n’avait pas attrapés. Bref, même le mécanisme de “preuve” devient lui-même un sujet de sécurité et de confiance. Ce qu’il faut retenir, au-delà du débat: on voit émerger une contestation interne, structurée, et techniquement outillée, autour des lignes rouges d’usage des modèles. Et ça, c’est nouveau à cette échelle.

Dans un registre plus “ingénierie”, mais lié au même fond de risque: comment sécuriser des agents IA qui exécutent des actions sur nos machines ? Gavriel Cohen défend une idée assez tranchée: il faut considérer les agents comme non fiables—potentiellement malveillants—et construire la sécurité dans l’architecture, pas dans des listes de permissions plus fines ou des pop-ups de confirmation. Son exemple, c’est NanoClaw, qui prend le contrepied d’approches où l’agent tourne sur la machine hôte par défaut. Ici, l’isolement est la règle: chaque invocation d’agent se fait dans un conteneur éphémère—Docker, ou Apple Container sur macOS—créé à la demande et détruit ensuite. Les agents tournent en utilisateur non privilégié, et n’accèdent qu’aux répertoires explicitement montés. Le système d’exploitation fait respecter la frontière. Le point subtil, et très important: NanoClaw évite aussi le “multi-agent dans le même bac à sable”. Cohen critique un modèle où plusieurs agents partagent le même environnement, car cela ouvre la porte à des fuites accidentelles—le scénario typique “agent perso” qui voit des traces de l’agent “boulot”. Dans NanoClaw, c’est séparation stricte: conteneur, système de fichiers, et même historique de session distinct. Il ajoute une défense en profondeur: un fichier d’allowlist de montages, hors du répertoire projet, que l’agent ne peut pas modifier, et qui bloque par défaut des chemins sensibles—.ssh, .gnupg, .aws, des .env, des motifs liés aux clés privées et identifiants. Le code hôte est monté en lecture seule, et comme le conteneur est détruit, les actions ne persistent pas. Même les discussions de groupe sont traitées comme surface d’attaque: des groupes non principaux sont “non fiables” par défaut, avec interdiction d’envoyer des messages à d’autres chats ou de planifier des tâches ailleurs—un garde-fou explicite contre l’injection de prompt via des contenus tiers. Enfin, Cohen tape aussi sur la complexité logicielle: il oppose un cœur de quelques milliers de lignes à des projets perçus comme des “monolithes” avec centaines de milliers de lignes et dizaines de dépendances, difficiles à auditer. Là encore, l’idée est simple: moins il y a de surface, plus on peut raisonner sur la sécurité.

On reste dans l’IA, mais côté performance: Unsloth annonce “Dynamic v2.0” pour la quantification de modèles au format GGUF. Si vous utilisez llama.cpp, LM Studio, ou des moteurs compatibles, c’est typiquement le genre d’amélioration qui se traduit par: modèles plus légers, plus rapides, sans saccager la qualité. Ce qui change avec Dynamic v2.0, d’après Unsloth, c’est la sélection de la quantification couche par couche—pas juste quelques couches “critiques”, mais un choix dynamique pour chaque couche possible, avec des combinaisons qui varient selon le modèle. Ils insistent aussi sur une calibration “faite à la main” pour le chat, annoncée à plus de 1,5 million de tokens, et sur la compatibilité MoE et non-MoE. Côté évaluation, ils mettent en avant plusieurs métriques: MMLU en 5-shot, Aider Polyglot pour du code, et surtout la KL Divergence comme indicateur d’erreur de quantification—en rappelant qu’une perplexité flatteuse peut masquer des pertes de qualité, et que des jeux de calibration trop proches des tests peuvent sur-optimiser. Ils racontent même avoir dû bâtir leur propre framework MMLU pour reproduire les scores officiels, à cause de détails d’implémentation—tokenisation, templates de prompts—qui font varier les résultats. Et dans leurs exemples, ils comparent des quantifs type QAT à leurs schémas “Dynamic”, en promettant des gains d’accuracy à taille équivalente, ou des tailles réduites à accuracy comparable. À garder en tête: ce sont leurs chiffres, mais la démarche—mesures, réplication, discussion des pièges—est intéressante.

Passons à un sujet plus “compte utilisateur”, mais important: le centre d’aide d’OpenAI détaille comment supprimer son compte OpenAI/ChatGPT. Deux chemins sont mis en avant: une demande via le Privacy Portal, ou un flux de suppression en self-service dans ChatGPT. Via le Privacy Portal, on va sur privacy.openai.com, on choisit “Make a Privacy Request”, on indique qu’on a un compte ChatGPT “consumer”, puis “Delete my ChatGPT account”, et on suit les étapes. Via le site ChatGPT, c’est plus opérationnel: il faut être connecté depuis moins de dix minutes, puis Settings → Account → Delete account. Ensuite, double confirmation: saisir son email de compte et taper “DELETE” pour déverrouiller le bouton de suppression définitive. Point pratique sur l’argent: si vous voulez seulement arrêter de payer Plus, il faut annuler l’abonnement séparément. En revanche, supprimer le compte annule automatiquement un Plus actif—et donc stoppe la facturation après suppression. Sur les données, OpenAI rappelle des règles de rétention: les chats supprimés sont “hard-deleted” sous 30 jours, avec des exceptions—données déjà désidentifiées, ou conservation pour sécurité / obligations légales. Les chats archivés, eux, ne disparaissent pas: ils quittent juste la barre latérale et restent gérables via les réglages. Ils précisent aussi la gestion des “memories”: on peut supprimer une mémoire individuelle ou tout effacer depuis les paramètres dédiés. Et il y a un lien vers l’option permettant de refuser l’utilisation de contenus “consumer” pour améliorer les modèles—avec, au passage, le rappel que les données entreprise ne sont pas utilisées pour l’entraînement. Derniers détails qui évitent des surprises: un compte supprimé ne peut pas être réactivé; on peut recréer un compte avec le même email après 30 jours si tout est bien supprimé et que le compte n’était pas désactivé pour violation de règles ou rattaché à une organisation Enterprise. Et pour les numéros de téléphone, la limite de vérification—jusqu’à trois comptes—ne se “libère” pas automatiquement au moment de la suppression, même si, dans certains cas, des numéros consumer seraient retirés du système après 30 jours. Enfin, supprimer son compte ne sert pas à changer de méthode d’authentification, et l’erreur “account has been deleted or deactivated” est exactement ce qu’on voit quand on tente de se reconnecter avec un email lié à une demande de suppression.

Toujours sur le thème identité / âge / conformité: la Californie a adopté une loi, l’Assembly Bill 1043, qui impose aux fournisseurs de systèmes d’exploitation d’ajouter une étape de vérification d’âge lors de la création d’un compte. Entrée en vigueur prévue: 1er janvier 2027. Le texte demande une interface “accessible” où le titulaire du compte indique une date de naissance, un âge, ou les deux. Objectif affiché: produire un “signal” d’âge, non pas forcément un âge exact, mais une tranche—moins de 13, 13–15, 16–17, 18+—qui pourra être transmis aux applications dans un “covered application store”. Et la loi exige aussi, sur demande des développeurs, une API “à peu près cohérente” en temps réel pour obtenir ce signal. Ce qui interpelle, c’est l’extension possible du champ: on parle d’OS providers “au sens large”, ce qui, dans certaines lectures, pourrait inclure des distributions Linux. Sur Windows, l’article note que Microsoft collecte déjà la date de naissance via le compte Microsoft, donc l’adaptation serait relativement simple. Côté Linux, on voit surtout des critiques: difficile à faire respecter, facile à contourner via des builds non conformes, et certains imaginent des avertissements du style “non destiné à une utilisation en Californie”. Et on sent une tendance mondiale: exigences de vérification d’âge, polémiques sur la confidentialité, et tension permanente entre protection des mineurs et collecte de données supplémentaires.

Pause plus légère, mais très “hacker”: SplatHash. Un projet open source qui compresse n’importe quelle image en… 16 octets. Oui, 128 bits. Et à partir de ce mini-empreinte, il reconstruit un aperçu flou en 32×32, typiquement pour afficher un placeholder pendant le chargement. Le pitch: plus compact que BlurHash ou ThumbHash, avec une taille fixe — pratique pour stockage et cache, et même pour enregistrer ça comme un simple entier 128 bits. Le repo annonce un décodage autour de 0,067 milliseconde, ce qui est cohérent avec la réalité produit: le décodage arrive à chaque chargement de page, chez tous les utilisateurs, donc chaque microseconde compte. Techniquement, SplatHash encode une couleur de fond et six “blobs” gaussiens, positionnés via une stratégie de matching pursuit, puis optimisés en couleur par ridge regression, le tout empaqueté en 128 bits. Il gère l’alpha, travaille en espace colorimétrique perceptuel Oklab, et propose des implémentations Go (référence), TypeScript/JavaScript et Python avec parité bit-à-bit—c’est rare et précieux. Compromis assumé: pas de réglage “qualité vs taille”, puisque la taille est fixe. Et l’encodage est plus coûteux que ThumbHash—mais l’auteur privilégie le coût côté client. Il y a une démo en ligne et des scripts de bench, et une release v1.3.0 datée… d’aujourd’hui, le 28 février 2026.

Deux notes plus “industrie logicielle” pour finir. D’abord, un article d’Ivan Turkovic qui démonte un refrain qu’on entend encore avec l’IA: “bientôt, plus besoin de développeurs”. Il fait une chronologie utile: COBOL en 1959 qui devait rendre le code lisible par des gestionnaires; les ambitions d’“automatic programming” et l’optimisme IA des années 60, puis le Lighthill Report et le premier AI winter; les 4GL et outils de reporting; les CASE tools et la génération de code à partir de modèles; les expert systems et le projet japonais Fifth Generation; puis le web, le no-code/low-code, et aujourd’hui les assistants type Copilot, GPT-4, Claude, Gemini. Sa thèse: chaque vague simplifie des tâches simples, mais déplace la difficulté vers les spécifications, l’intégration, la sécurité, les compromis, la maintenance, et l’évolution. Résultat: on écrit peut-être moins de “code de plomberie” à la main, mais on construit plus de logiciel au total, et le métier se reconfigure au lieu de disparaître. Ensuite, un signal faible mais parlant: Simplenote annonce qu’il n’est plus en développement actif. L’app reste disponible, mais l’équipe se limite à la maintenance du fonctionnement de base, sans nouvelles fonctionnalités. C’est le genre de mise à jour qui rappelle une réalité: la plupart des produits finissent en mode “stabilité”, et ça influence nos choix d’outils—surtout quand on mise sur une app pour prendre des notes pendant des années.

Et un dernier détour, parce que Hacker News aime aussi les essais longs: un article de Works in Progress sur la diversité des systèmes matrimoniaux. L’angle est net: le mariage n’est pas une forme “naturelle” unique, c’est un ensemble de solutions sociales pour gérer ressources, alliances, héritage et reproduction. L’article commence par le “ghost marriage” chez les Nuer: un homme mort sans héritier peut se voir attribuer une épouse; la dot en bétail est payée, et les enfants appartiennent légalement au défunt, portant son nom et héritant de ses biens—une réponse à la guerre et aux maladies. On passe ensuite par les débats anthropologiques du XXe siècle: sociétés où les unions sont plus informelles, divorce plus facile, soutien assuré par la parenté élargie; puis l’arrivée de l’agriculture et de la richesse stockable, qui rend la polygynie plus faisable pour les hommes riches—et change la valeur économique des filles, le bridewealth, et les contrôles sociaux autour de la fertilité. Le texte compare aussi des logiques d’héritage patrilinéaire et matrilinéaire, évoque des systèmes où l’extra-conjugal est socialement toléré, et discute l’Europe et l’Asie où la monogamie légale coexiste souvent avec des arrangements de fait. Conclusion: avec l’urbanisation, l’éducation, le travail des femmes et la mobilité, les pressions familiales se relâchent, les unions deviennent plus faciles à former… et à rompre. C’est moins “romance” que “économie politique du couple”, mais c’est précisément ce qui le rend éclairant.