Bon, alors là, Google a fait encore trèèèès fort.
Mercredi matin, la firme de Mountain View a carrément publié sur son propre bug tracker Chromium le code d'exploitation d'une faille... qui n'est toujours pas corrigée ! Et pas une petite vulnérabilité oubliée dans un coin, hein, mais une vraie faille de la mort qui tue que la chercheuse indépendante Lyra Rebane leur avait remontée gentiment et en privé . Ça fait 29 mois (2 ans et demi, les matheux ^^) et elle attend toujours un patch !
Le truc vise la Browser Fetch API, un mécanisme qui permet à un site de télécharger de gros fichiers en arrière-plan, genre une longue vidéo. Sauf qu'en la détournant, le code ouvre un service worker qui reste actif en permanence. Du coup, un site malveillant que vous visitez peut glisser un bout de JavaScript qui transforme votre navigateur en relais, tout cela à votre insu.
Parfait donc pour devenir un poxy anonyme pour des inconnus, un nœud de botnet pour des attaques DDoS, ou se faire surveiller quand on surfe sur le net... Et le plus vicelard, c'est que la connexion se rouvre ou reste ouverte même après avoir redémarré le navigateur, voire la machine entière.
Côté victimes, on parle de Chrome, de Microsoft Edge et de quasiment tous les navigateurs basés sur Chromium. Et que vous soyez sur Windows, macOS ou Linux, le bug s'en moque royalement. Rebane a confirmé que Brave, Opera, Vivaldi et Arc sont vulnérables eux aussi.
Bien sûr, Firefox et Safari, eux, passent clairement au travers, parce qu'ils ne supportent pas ce fameux téléchargement en arrière-plan. Bref, encore une fois, ne pas suivre le troupeau de mouton team-Chromium, ça paye !! Si vous cherchiez une raison de plus de larguer Google , la voilà servie sur un plateau.
Perso, ce qui me sidère, c'est que la faille a été classée S1, le deuxième niveau de gravité le plus élevé chez Google et il ne s'est toujours rien passé 29 mois après. C'est ouf quand même... Le post sur le tracker Chromium a bien été supprimé mais on le trouve toujours sur quelques archives / miroirs...
Après l'impact de cette faille, reste quand même limité car elle ne franchit aucune frontière... par exemple, elle ne donne pas accès à vos mails ni au reste de votre ordinateur, mais juste à ce qu'un navigateur sait déjà faire (ce qui est déjà énorme !!). Mais elle pourrait permettre à des cybercriminels de se constituer une flotte de milliers, voire de millions de navigateurs détournés, et le jour où une autre faille tombe, vous avez déjà l'armée prête à dégainer !! La bombe est là, il manque juste la mèche en fait !
Et pour se protéger ?
Bah franchement, pas grand-chose à faire côté utilisateur tant qu'il n'y a pas de patch. Si vous voulez mon avis bancal, le seul signal visible que vous pouvez guetter, c'est un menu de téléchargement qui s'ouvre tout seul sans raison, donc méfiez-vous donc si ça arrive. Maintenant si le sujet vous angoisse vraiment, basculer sur un navigateur pour les adultes ^^, genre Firefox ou Safari règlera la question d'un coup !
Faut pas oublier que Google passe son temps à pointer du doigt les éditeurs trop lents à patcher, alors j'comprends vraiment pas comment ils ont pu merder à ce point.
Votre vieux Galaxy S5 qui prend fort la poussière dans un tiroir, mérite mieux je crois !
Un dev, Capcom6 a mis en ligne SMS Gateway for Android , une app Kotlin sous licence Apache 2.0 qui transforme n'importe quel smartphone (Android 5.0+) en passerelle SMS programmable. Cela vous permet de récupérer une API REST pour ensuite envoyer et recevoir vos SMS avec votre propre téléphone et votre propre SIM et ainsi vous passer de services payants équivalents.
Il y a 3 modes au choix. Le mode local quand l'app lance un serveur HTTP sur le port 8080, accessible depuis votre réseau. Le mode cloud où l'app se connecte au service tiers api.sms-gate.app, ce qui est pratique pour ceux qui ont une IP dynamiques ou plusieurs appareils. Et le mode "private server" qui permet d'héberger le backend chez vous, en totale autonomie.
Mais dans tous les cas, les requêtes restent les mêmes à savoir du bon vieux POST JSON avec basic auth.
Et côté fonctionnalités, y'a tout ce qu'il faut. Multi-SIM si votre téléphone est compatible, messages multipart automatiquement découpés pour les SMS longs, suivi de statut en temps réel (sent, delivered, failed), webhooks pour 8 événements différents (sms:received, sms:sent, sms:delivered, sms:data-received, mms:downloaded, system:ping...). Et puis du chiffrement bout-en-bout activé sur le mode cloud, comme ça personne ne peut lire vos messages en clair.
Maintenant vous vous demandez peut etre à quoi ça peut servir ??
Bah je pense à de l'envoi SMS 2FA pour vos applications, tout ce qui est messages transactionnels (confirmations de commande, rappels de RDV), des notifications push via SMS, et même du data SMS binaire pour piloter des périphériques IoT à distance. Pourquoi pas ? Y'a plus de limites après... Ah et y'a aussi une intégration n8n officielle (ici sur le repo example-webhooks-n8n ) pour brancher l'API à vos workflows, plus une bibliothèque PHP sur Packagist. Bref, y'a un petit écosystème qui commence à se développer autour.
Pour l'installer, oubliez le Play Store. capcom6 distribue uniquement des APK sur les GitHub Releases. Faut donc activer les sources inconnues, télécharger le .apk, et installer manuellement.
Après quand on fait le calcul côté pognon c'est vite vu. Twilio par exemple facture $0.0083 par SMS aux US, plus 1,15 $ / mois par numéro, plus les frais. Donc pour 1000 SMS par mois c'est vite entre 50 à 80 $. Avec SMS Gateway for Android et votre forfait perso, vous ne payez rien d'autre que votre forfait...
Après y'a quelques limites à connaitre... Par exemple, si vous pensiez faire de l'envoi massif pour du marketing (comprenez du spam), votre opérateur va évidemment bloquer rapidement votre SIM. Et puis évidemment, faut que le téléphone soit allumé h24 avec sa connexion data activée. Donc pour du transactionnel léger c'est nickel mais pour du mass-mailing, oubliez ! De toute façon, n'oubliez pas, y'a une place pour vous en enfer, les spammeurs.
Voilà, donc si vous avez un vieux smartphone Android qui fait dodo dans un tiroir et que vous avez besoin d' une API SMS pour vos automations perso ou votre stack interne, c'est une alternative à Twilio très sympa !
Je suis tombé sur un accessoire à moins de 10 euros qui ne paie pas de mine, et que j'utilise pourtant tous les jours depuis que je l'ai reçu. C'est un simple autocollant. Un carré de vinyle transparent d'environ 8 cm de côté, qui liste les raccourcis clavier essentiels de macOS et se colle dans le coin de votre MacBook.
L'idée est bête comme chou. Au lieu d'aller chercher sur Google "comment faire une capture d'écran sur Mac" pour la centième fois, vous baissez les yeux vers le coin de votre clavier et c'est écrit. Cmd+Maj+4 pour capturer une zone de l'écran, Cmd+Espace pour ouvrir la recherche Spotlight, Cmd+Option+Échap pour forcer une application à quitter. Tout est regroupé sur un petit carré.
La pose se fait en deux minutes. Le vinyle est transparent, donc une fois collé sur la coque ou près du trackpad, ça reste discret et ça ne jure pas avec le design du Mac. Synerlogic conseille de dépoussiérer la surface et d'appliquer l'autocollant progressivement pour éviter les bulles d'air (évidemment moi je me suis précipité, donc ça a laissé quelques bulles, mais l'autocollant se repositionne sans mal pour les retirer). Bon point en plus : la colle n'est pas définitive. Vous pouvez retirer l'autocollant sans laisser la moindre trace, ce qui est cool si vous revendez la machine plus tard.
Le vrai intérêt, c'est pour les gens qui débutent sur Mac. Quand on arrive de Windows, les raccourcis changent tous, et c'est un des trucs les plus agaçants de la transition. Avec la liste sous les yeux, l'apprentissage se fait tout seul, sans effort. Au bout de quelques semaines, vous connaissez les raccourcis par cœur et l'autocollant devient un filet de sécurité pour les commandes que vous utilisez moins souvent.
Et si vous êtes sous Windows, Synerlogic décline exactement le même autocollant en version Windows, avec les raccourcis Windows qui vont bien pour gagner en productivité.
Alors oui, ça reste un autocollant. Il liste les raccourcis classiques, pas les combinaisons exotiques d'un développeur ou d'un monteur vidéo. Et si vous maîtrisez déjà votre Mac sur le bout des doigts, il ne vous apprendra rien. Mais à moins de 10 euros, franchement n'hésitez pas. Disponible ici sur Amazon pour macOS , et ici pour Windows !
Anthropic, la boîte derrière l'IA Claude, a racheté Stainless pour plus de 300 millions de dollars. Stainless, c'est un nom que le grand public ne connaît pas, mais l'outil est partout : il transforme automatiquement la spécification d'une API, l'interface par laquelle deux logiciels se parlent, en SDK.
Pour rappel, un SDK, c'est un ensemble de bibliothèques de code prêtes à l'emploi pour les développeurs, ici dans une dizaine de langages comme Python, TypeScript, Go ou Java.
En clair, quand un développeur veut brancher son application sur l'API de Claude, il utilise un SDK généré par Stainless. La boîte, fondée en 2022 par un ancien ingénieur de Stripe, a produit chaque SDK officiel d'Anthropic depuis les tout débuts de l'API Claude. Le rachat consolide donc une brique que l'entreprise utilisait déjà tous les jours.
Stainless ne s'arrête pas aux SDK. La société fournit aussi de l'outillage pour les serveurs MCP, le protocole poussé justement par Anthropic qui permet aux IA de se connecter à des outils et des données externes. Du coup le rachat fait sens à double titre : Anthropic met la main sur la génération de SDK et sur une partie de l'infrastructure MCP, deux briques où il veut clairement être central.
Sauf que voilà le détail un peu fou. Stainless ne servait pas qu'Anthropic, et sa liste de clients comprend OpenAI, Google DeepMind, Perplexity, Groq et Cloudflare, autrement dit la plupart des concurrents directs d'Anthropic sur le marché de l'IA.
La suite est sans pitié. Anthropic ferme tous les produits hébergés de Stainless, générateur de SDK compris. Les clients actuels gardent les SDK déjà générés et peuvent les modifier, mais le robinet, lui, est coupé. Tout le monde va devoir trouver une alternative ou rapatrier la génération de SDK en interne.
Pourquoi mettre 300 millions sur la table pour ça ? Parce que la vraie bataille n'est plus seulement sur les modèles d'IA, mais sur la couche d'outillage autour.
Celui qui contrôle la façon dont les développeurs branchent leurs applications et orchestrent leurs agents IA contrôle une partie de l'écosystème. OpenAI muscle son propre Agents SDK de son côté. Anthropic, lui, préfère racheter directement l'usine, et au passage priver ses concurrents d'un fournisseur bien pratique.
Source : TechCrunch
Le 23 juillet 2025, le Luxembourg entier s'est retrouvé sans réseau mobile, sans téléphone fixe et sans communications d'urgence pendant plus de trois heures.
Dix mois plus tard, on connaît enfin la cause grâce au média The Record : une faille jusque-là inconnue dans le logiciel d'un routeur Huawei.
Le mécanisme est presque bête. Du trafic réseau spécialement fabriqué a été envoyé vers des routeurs d'entreprise Huawei, et ce trafic les a fait redémarrer en boucle, sans jamais s'arrêter.
Pas besoin de pirater quoi que ce soit ni de voler un mot de passe, il suffisait d'envoyer les bons paquets au bon endroit. Ces routeurs équipaient l'infrastructure de POST Luxembourg, l'opérateur télécom historique du pays. Quand le cœur du réseau redémarre en continu, tout s'effondre derrière. Aucune charge criminelle n'a été retenue, faute de pouvoir désigner un responsable.
Le plus inquiétant, c'est ce qu'on ne sait toujours pas. La vulnérabilité n'a jamais été publiée. Aucun identifiant CVE, le numéro de référence standard qui permet de cataloguer une faille de sécurité, n'a été déposé dans les dix mois qui ont suivi.
On ignore si le trou a été bouché, combien d'autres opérateurs utilisent les mêmes routeurs, et si des équipements identiques sont encore vulnérables aujourd'hui quelque part. Les enquêteurs pensent même que POST n'était pas une cible : le trafic malveillant ne faisait peut-être que transiter par son réseau.
Et là, impossible de ne pas penser à FX Lindner. Ce chercheur en sécurité allemand avait alerté Huawei dès 2012 sur la fragilité de leurs équipements réseau, code bâclé et failles à la pelle.
Huawei avait minimisé. Treize ans plus tard, la même histoire se rejoue, sauf qu'elle ne touche plus un labo de test mais un pays entier, services d'urgence compris.
Ça repose la question de fond, celle de la souveraineté des infrastructures télécom européennes. L'Europe parle de souveraineté numérique depuis des années, surtout sur le cloud et l'IA. Mais les tuyaux eux-mêmes, les routeurs qui font transiter les appels et les données, restent souvent du matériel dont le code source échappe totalement aux opérateurs.
Faire tourner le réseau national d'un pays sur des routeurs dont on ne maîtrise ni le code ni le calendrier de correctifs, c'est un pari risqué. Et le Luxembourg vient de découvrir ce que ça coûte quand le pari échoue. Bref, treize ans d'avertissements ignorés, et il aura fallu un pays débranché trois heures pour que le sujet revienne sur la table.
Source : The Record
Hier soir, le compte Google Cloud de Railway est passé en statut restreint. Du jour au lendemain, sans préavis et sans la moindre explication.
Railway, pour ceux qui ne connaissent pas, c'est un service américain qui permet aux développeurs et aux startups de mettre un site ou une application en ligne en quelques clics, sans avoir à louer ni configurer eux-mêmes des serveurs.
Dans le jargon, on appelle ça un PaaS, une plateforme d'hébergement clé en main. Des milliers d'entreprises s'en servent pour faire tourner leurs services au quotidien. Sauf que Railway, lui, fait tourner son propre tableau de bord, son API et son control plane (la partie qui orchestre toute la plateforme) sur Google Cloud. Donc quand Google a coupé, tout est tombé.
Résultat : environ six heures de panne. Les utilisateurs se sont retrouvés avec des erreurs "no healthy upstream" en cascade, impossible de se connecter, impossible de déployer quoi que ce soit. Le pire dans l'histoire, c'est que Railway n'est pas un petit client de passage. La boîte dépense plus de 10 millions de dollars par an chez Google Cloud. Même ça n'a pas suffi à éviter le débranchement automatique.
Le ton des équipes Railway est agacé. Angelo Saraceno, ingénieur chez eux, a lâché que leurs contacts chez Google étaient eux-mêmes confus et que les clients étaient furieux. Et cette phrase, qui résume tout : "nos clients se fichent que ce soit Google, c'est à nous d'assumer notre disponibilité". Difficile de leur donner tort.
Ce n'est pas la première fois. Railway avait déjà déménagé une partie de son infrastructure en colocation (des serveurs loués dans un datacenter, qu'on gère soi-même) en 2024, justement parce que les problèmes avec Google Cloud posaient un risque existentiel à leur activité.
Sauf qu'ils avaient gardé le control plane chez Google. Mauvaise idée, visiblement. Et en 2024, Google avait déjà fait exactement le même coup au fonds de pension australien UniSuper, suspendu une semaine entière sans raison claire.
Là où ça pique, c'est l'angle métier. Railway est un PaaS. Google Cloud propose aussi un PaaS. Autrement dit, Railway hébergeait son business chez un concurrent direct, qui peut le débrancher quand il veut, par un automatisme mal réglé ou autre chose. Vous voyez le piège. Confier sa plateforme d'hébergement à quelqu'un qui vend exactement le même service, c'est lui donner les clés et la corde.
Source : The Register
Chaac Pizza Northeast, qui exploite plus de 100 restaurants Pizza Hut sur la côte est des États-Unis, attaque son propre franchiseur en justice. Le motif : un logiciel d'IA imposé par le siège pour gérer les livraisons, et qui aurait fait perdre près de 100 millions de dollars au franchisé.
Le logiciel s'appelle Dragontail. Il a été racheté en 2021 par Yum Brands, la maison mère de Pizza Hut, et il sert à orchestrer la production en cuisine et l'attribution des livraisons. Pizza Hut a fini par le rendre obligatoire pour ses franchisés.
Sur le papier, optimiser qui fait quoi et quand, c'est exactement le genre de tâche où une IA devrait briller. Sauf qu'en pratique, le résultat raconté dans la plainte est un désastre.
Le détail le plus parlant concerne les livreurs. Dragontail leur montrait si une autre commande allait bientôt être prête. Du coup, beaucoup de livreurs prenaient une commande, puis attendaient sur place quinze minutes pour en grouper une deuxième.
Résultat : la première pizza partait froide et en retard. Le genre de comportement algorithmique qui a du sens sur un tableur d'optimisation, et aucun sens dans la vraie vie d'un client qui attend son dîner. Et le client, lui, ne sait pas que c'est un algorithme qui a décidé de faire poireauter sa commande.
Les chiffres avancés par Chaac sont violents. Avant Dragontail, plus de 90 % de ses livraisons arrivaient en moins de 30 minutes, avec de bons scores de satisfaction. Après le déploiement, la croissance du chiffre d'affaires à New York est passée de plus de 10 % à environ moins 10 %. Le franchisé accuse donc Pizza Hut d'avoir violé le contrat de franchise en imposant un outil qui sabote la production, sans même fournir le support promis.
L'affaire est devant le tribunal des affaires du Texas, et elle dépasse largement le cas Pizza Hut. De plus en plus de franchisés se retrouvent à devoir installer des outils maison décidés par le siège, sans avoir leur mot à dire, et sans pouvoir revenir en arrière si ça plombe leur activité. Quand l'outil est une IA opaque qu'on ne peut ni ajuster ni désactiver, le franchisé paie les pots cassés tout seul.
Bref, une IA d'optimisation qui optimise si bien qu'elle livre les pizzas froides, c'est le genre de promesse 2026 qu'on n'avait pas vu venir.
Source : Gizmodo
Si comme moi, vous bloguez encore à l'ancienne, c'est à dire depuis l'interface web de WordPress.com, sachez qu'Automattic vient de balancer une app pour Mac qui s'est donné pour mission de vraiment bousculer votre façon d'écrire.
WordPress Workspace est donc un éditeur de site, un agent IA, un outil de prise de note... Bref, un outil fourre-tout qui est en réalité un agent IA branché sur votre contenu et capable aussi d'uploader des médias vers la médiathèque de votre site. Ça se présente donc comme un chat auquel on peut demander tout et n'importe quoi, du style "Voici mon article [TEXTE]. Publie le" ou encore "J'ai la flemme, écris moi un article sur ça : [SUJET]".
Vous pouvez aussi l'utiliser pour interroger votre site web, corriger des trucs, mettre à jour des articles...etc.
Le DMG se télécharge en direct depuis le GitHub d'Automattic , et c'est entièrement gratuit avec n'importe quel plan WordPress.com durant la bêta. Et ça fonctionne aussi avec les sites auto-hébergés comme le mien, pour peu que vous l'ayez lié avec Jetpack.
Ce qui est cool avec cet outil c'est surtout que c'est un agent qui connaît déjà votre site WordPress, son contenu, ses médias, ses guidelines et les permissions liées à votre compte. Donc ça va vite...
Au menu des fonctionnalités, vous aurez de la dictée vocale qui s'alignera sur le ton du site, l'envoi de captures d'écran que vous balancez directement dans l'outil, et un raccourci clavier global qui invoque l'agent depuis n'importe quelle app Mac où vous écrivez, même hors WordPress.
Côté multi-sites, vous pouvez aussi naviguer entre plusieurs sites, où chacun devient son propre workspace avec ses propres réglages et ses propres "guidelines" comme on dit, déjà mémorisées.
Sur la roadmap, Automattic prépare une fonctionnalité Guidelines dans le cœur de WordPress, plus des Memories (apprentissage continu de l'agent), des Skills (capacités partageables en équipe) et des Artifacts (stockage de contenu en cours). L'objectif est donc plutôt clair : Ils veulent transformer WordPress en couche de contexte permanente pour les outils IA, et plus simplement en CMS où on dépose des articles.
Donc à tester si vous publiez régulièrement sur WordPress.
HydroTracker, c'est une app Android open source pour suivre votre consommation d'eau au quotidien. C'est sans pub, ça fonctionne hors-ligne et ça a été mis au point par Ali Cem Çakmak, physicien et développeur passionné !
L'écran d'accueil d'HydroTracker, sobre et lisible
Côté fonctionnalités, vous avez donc le suivi quotidien classique avec objectif personnalisé, des graphiques hebdo, des cartes thermiques mensuelles, le suivi des séries de jours réussis et 3 widgets à mettre sur écran d'accueil.
Par contre, ça marche pas pour suivre votre conso de bière, désolé mes amis Chouffinistes ^^
Et puis surtout, y'a l'intégration Health Connect ce qui permet à HydroTracker de lire et écrire dans la base santé Android partagée par Samsung Health, Google Fit, Fitbit, Garmin ou Strava. Comme ça, toutes vos données sont centralisées !
Alors j'sais pas si vous avez déjà tracké votre consommation d'eau mais la plupart des apps d'hydratation se contentent de compter les verres d'eau. Cem, lui, s'appuie sur le Beverage Hydration Index (y'a une étude à ce sujet publiée dans l'American Journal of Clinical Nutrition ) et applique des coefficients différents selon les boissons, avec les seuils EFSA pour l'Europe et IOM pour les US. Un verre de lait équivaut par exemple à 1,5 fois sa quantité d'eau, et un soluté de réhydratation orale aussi. C'est logique vu la composition réelle, et pourtant aucune app grand public ne pousse le bouchon aussi loin niveau finesse !
Les analytics d'HydroTracker, façon dashboard scientifique
Et le gros morceau, vous l'aviez deviné, c'est surtout la confidentialité. Prenez par exemple Water Reminder, une app concurrente bien installée sur Android. Hé bien avec elle, vos heures de prise d'eau, votre régularité, votre comportement, tout part chez Google.
Alors que HydroTracker, lui, garde tout en local et la synchro Health Connect reste bien sûr à 100% optionnelle. Bref, si vous tenez à votre indépendance numérique vis-à-vis des géants américains , et que vous aimez rester hydraté, c'est l'app idéale !
L'app est sous licence GPL v3, dispo sur le Play Store (et bientôt sur F-Droid), ou en APK direct depuis les releases GitHub . Par contre, pas de version iOS pour l'instant. Ah et j'oubliais, les notifications de l'app s'adaptent à votre cycle de sommeil, donc elle ne vous harcelera pas la nuit. C'est con dit comme ça, mais peu d'apps le font.
Voilà, si vous voulez creuser le code, c'est sur GitHub et Cem a même sa page perso sur cmckmk.com .
Merci à Alex pour le tip !
gVim, la version avec interface graphique du légendaire éditeur de texte Vim, récupère le support de GTK4. Pour situer, GTK c'est la boîte à outils qui dessine les fenêtres, les boutons et les menus des applications sous Linux.
Vim tournait jusqu'ici sur GTK2 et GTK3, deux versions vieillissantes. GTK4 modernise tout ça. Et le détail qui fait causer : le commit indique noir sur blanc que le portage a été co-écrit par Claude, l'IA d'Anthropic.
Le boulot a pris plusieurs semaines. Le support GTK4 est maintenant intégré au code de Vim, activable avec une option de compilation, --enable-gui=gtk4. GTK4 apporte un rendu plus moderne et un meilleur support des écrans haute densité, là où GTK2 commençait sérieusement à dater.
GTK2 n'est d'ailleurs plus vraiment maintenu côté GNOME depuis un bon moment, donc rester dessus n'était pas tenable éternellement. Pour l'instant, le script de configuration garde quand même GTK3 par défaut si vous ne précisez rien, le temps que la nouvelle version soit éprouvée. Aucune installation existante n'est donc affectée, et ça débarquera en option dans la prochaine version de Vim.
Le plus intéressant, ce n'est pas le code mais le tag "Co-authored-by: Claude" dans l'historique Git. Vim, c'est un projet open source vénérable, démarré en 1991, l'éditeur des barbus et des serveurs Linux du monde entier. L'éditeur n'a pas bougé sur ses fondamentaux depuis des décennies, et ce genre de modernisation graphique traîne souvent faute de bras pour s'en occuper.
Voir une IA créditée comme co-autrice sur une toolkit graphique de trente ans, c'est quand même un signal fort. Et personne n'a planqué la contribution : elle est assumée et tracée.
C'est exactement le bon réflexe. Le débat sur les contributions d'IA dans l'open source n'est pas nouveau, Greg Kroah-Hartman, un des mainteneurs du noyau Linux, avait déjà posé le sujet sur la table. Le vrai problème n'a jamais été "l'IA a écrit du code", mais "est-ce que c'est transparent et est-ce qu'un humain a relu et validé".
Ici, les deux cases sont cochées. Le code est passé par la revue habituelle du projet, et le crédit est explicite. Un curieux peut remonter le commit et voir précisément ce qui a été fait.
Bref, une IA qui aide à dépoussiérer une toolkit de trente ans en le disant clairement, c'est plutôt la version saine du truc.
Source : Phoronix