Une nouvelle fuite de données importante affecte entre 11 et 15 millions de Français, suite à une intrusion sur la solution MonLogicielMedical.com de Cegedim.
Un simple nom de processeur affiché dans l’UEFI, et la toile s’emballe. Le Core 9 273PQE, rattaché à la génération Bartlett Lake-S, aurait été repéré sur une ROG Maximus Z790 Apex.
Si l’information se confirme, cela signifierait qu’un nouveau CPU P-cores only pourrait fonctionner sur la plateforme LGA-1700.
Un CPU “P-cores only” à 5,9 GHz
Les éléments techniques évoquent une configuration jusqu’à 12 cœurs Performance sans E-cores, soit une rupture avec Alder Lake et Raptor Lake limités à 8 P-cores accompagnés de cœurs Efficient. La fiche associée au 273PQE parle de 12 cœurs / 24 threads, 36 Mo de cache L3 et une fréquence turbo pouvant atteindre 5,9 GHz, pour une base power annoncée à 125 W.
Ce modèle serait toutefois destiné au segment embedded/edge, et non au marché grand public. Cela change totalement la lecture : présence dans un BIOS ne signifie pas lancement retail.
Z790 Apex : validation interne ou vrai support ?
La Z790 Apex est une carte mère taillée pour l’overclocking extrême. Voir apparaître ce CPU sur ce modèle peut s’expliquer par un BIOS interne dédié aux partenaires ou aux tests. Un simple intitulé dans un screenshot ne garantit ni démarrage complet, ni stabilité, ni compatibilité officielle.
Le vrai sujet reste ailleurs : microcode public, BIOS diffusé aux utilisateurs et validation constructeur. Sans ces trois briques, le support restera purement théorique.
LGA-1700 prolongé ?
Si Bartlett Lake-S fonctionne réellement sur LGA-1700, Intel pourrait offrir un sursis inattendu à la plateforme. Un 12 P-cores haute fréquence sans E-cores séduirait mécaniquement la scène overclocking, surtout sur une carte comme la Z790 Apex.
Mais pour l’instant, rien n’indique une commercialisation grand public. Sans annonce officielle ni BIOS public, le 273PQE reste un aperçu intrigant, plus proche du laboratoire que du panier d’achat.
Tim Cook parle d’une « big week » qui démarre lundi matin. Apple planifierait des annonces étalées jusqu’à mercredi, avec une montée en puissance progressive.
Apple big week : cadence d’annonces et premiers indices
Le teaser posté sur X par le CEO affiche un logo Apple sur fond argent et le hashtag #AppleLaunch. Plusieurs rapports évoquent un rythme en trois temps, du lundi matin (US) au mercredi, avec un « Special Apple Experience » au milieu de semaine.
Des sessions prises en main seraient prévues à New York, Londres et Shanghai. Aucune fiche technique officielle n’accompagne ce teasing pour l’instant.
Produits pressentis et fenêtres de lancement
Un MacBook d’entrée de gamme revient avec insistance dans les rumeurs : puce A18 Pro, 8 Go de mémoire, 256 Go de stockage et écran 12,9 pouces. Le ticket d’entrée serait inférieur à 800 € et pourrait atteindre 599 $ (~555 €) selon certaines sources.
Des mises à jour de MacBook Pro en M5 Pro et M5 Max, un MacBook Air plus fin et de nouveaux iPad sont également cités. Les informations les plus récentes situent toutefois ces machines plutôt plus tard cette année, pas le mois prochain.
iPhone et périphériques affichage-accessoires
Sur le segment mobile, l’iPhone 17e est évoqué comme modèle plus abordable, avec écran OLED 6,1 pouces à 60 Hz. Côté desktop, un Studio Display 90 Hz est cité ainsi que de nouveaux bracelets Apple Watch. Les appareils pliables et lunettes connectées restent décrits comme plus lointains.
Si Apple confirme un MacBook à A18 Pro sous la barre symbolique des 800 €, la pression tarifaire serait immédiate sur le segment ultramobile, y compris face aux Chromebook premium et aux ultraportables Windows d’entrée de gamme. La bascule éventuelle vers M5 pour les MacBook Pro fixerait aussi le tempo de la fin d’année côté stations mobiles pro.
Dans un communiqué de presse du 25 février 2026, Panasonic a annoncé son nouveau micro LUMIX DMW-DMS1 destiné aux derniers appareils hybrides plein format de la marque. Ce micro est en fait équipé de plusieurs micros de 10 mm de diamètre permettant une capture directionnelle réglable et visant à off...
Utilitaire léger, gratuit, en français et portable permettant de masquer automatiquement les icônes de votre Bureau pour les afficher uniquement lorsque vous en avez besoin, via un simple clic...
Utilitaire léger, gratuit, en français et portable permettant de masquer automatiquement le curseur de votre souris au bout de quelques secondes lorsque vous n'utilisez pas celle-ci...
2>&1, >, >>, 2>/dev/null... Si ces symboles dans votre terminal Linux ou macOS vous font autant flipper qu'un regex, respirez un grand coup ! Quand vous aurez lu cet article, vous verrez qu'en fait c'est super simple à comprendre, et en 5 minutes vous saurez enfin ce que vous copiez-collez depuis des années depuis StackOverflow.
En fait, dans les shells Unix (bash, zsh, etc.), y'a 3 canaux de base : stdin (entrée, numéro 0), stdout (sortie normale, numéro 1) et stderr (les erreurs, numéro 2). Tout le reste, de > à 2>/dev/null, découle de ces 3 numéros.
> - Écrire dans un fichier (et tout écraser)
echo "Salut" > fichier.txt
Ça redirige stdout vers fichier.txt. Si le fichier existe déjà... c'est mort, il est écrasé sans sommation. Du coup, faites gaffe avec vos logs, une commande mal placée et ce sont des heures de données qui disparaissent.
D'ailleurs, si vous êtes du genre parano (et oui, vous avez raison !), set -o noclobber dans votre .bashrc empêchera > d'écraser un fichier existant lors d'une commande tapée à la main. Pour y arriver, il faudra utiliser >| pour forcer.
>> - Ajouter à la suite
echo "Ligne 2" >> fichier.txt
Même principe que >, sauf que ça ajoute à la fin au lieu d'écraser. C'est ce que vous voulez 99% du temps pour des logs (sauf si vous voulez repartir de zéro, là > fait le job). Une lettre de différence entre "tout va bien" et "où sont passés mes logs, boudiouuu ???".
2> - Rediriger les erreurs
commande_foireuse 2> erreurs.log
Le 2 c'est stderr, en gros (y'a pas d'espace entre le 2 et le >, sinon bash croit que 2 est un argument). Tout ce qui sort en erreur finit dans erreurs.log au lieu de polluer votre terminal. Perso, je trouve ça super pratique pour garder une trace propre quand vous lancez des scripts via crontab -e.
Et 2>> existe aussi, pour cumuler les erreurs au fil du temps au lieu d'écraser le fichier à chaque exécution.
2>&1 - Fusionner erreurs et sortie normale
commande > output.log 2>&1
Le fameux ! Le &1 dit à bash "le 1 c'est un file descriptor, pas un fichier qui s'appelle littéralement 1". Du coup stderr (2) est redirigé vers le même endroit que stdout (1), ou plutôt vers là où stdout pointe au moment où bash évalue la ligne. Ça va, vous suivez toujours ? ^^
Attention, l'ordre compte ! Bash lit les redirections de gauche à droite. > output.log 2>&1, stdout pointe vers le fichier, puis stderr suit... tout va dans le fichier. 2>&1 > output.log, stderr copie stdout qui pointe ENCORE vers le terminal, puis stdout est redirigé vers le fichier. Résultat, les erreurs restent dans votre terminal. Le piège classique.
Et &> fait la même chose en plus court :
commande &> output.log
&> est super pratique, mais spécifique à bash / zsh donc pour la portabilité, préférez quand même > fichier 2>&1.
2>/dev/null - Le trou noir
find / -name "*.conf" 2>/dev/null
/dev/null, c'est le trou noir d'Unix. Tout ce que vous envoyez là-dedans disparaît. Super pratique avec find qui vous crache 200 "Permission denied" pour un seul résultat utile.
Et si vous voulez TOUT faire disparaître (stdout + stderr) ? Un petit &>/dev/null et c'est réglé. Pratique dans vos scripts /etc/cron.d/ quand vous voulez zéro bruit (bon, j'exagère un chouïa, je sais...).
Si vous aimez les
raccourcis bash
, j'ai aussi ce qu'il faut.
Bref, voilà ce sont juste 5 opérateurs à retenir, et avec ça vous couvrez à peu près tout. Donc la prochaine fois que vous copierez un 2>&1, au moins vous saurez pourquoi.
Si vous utilisez Ubuntu 26.04, vous avez peut-être remarqué un truc bizarre dernièrement en tapant votre mot de passe sudo... Ouiiiiii, y'a des petites étoiles qui apparaissent !! Pas de panique, c'est "normal". Enfin, c'est nouveau...
En effet, sudo-rs, la réécriture en Rust de la bonne vieille commande sudo, a décidé d'activer pwfeedback par défaut. En gros, quand vous faites un sudo apt install bidule, au lieu du trou noir habituel, vous voyez maintenant des ***** défiler pendant la saisie du mot de passe. C'est un changement qui casse une convention vieille de 40 ans... et ça, forcément, ça fait du bruit !
Pour rappel, Ubuntu a basculé sur sudo-rs (le remplaçant en Rust du bon vieux sudo en C) depuis la version 25.10. Ça fait partie du même mouvement de réécriture des outils système en Rust,
comme les coreutils
dont je vous avais parlé. Et la 26.04 vient de "cherry-picker" comme on dit, un patch upstream qui active le feedback visuel par défaut.
Un bug report sur Launchpad (
#2142721
) est bien sûr arrivé direct, en mode vénère genre "*ÇA FAIT DES DÉCENNIES qu'on n'affiche pas la longueur du mot de passe pour empêcher le shoulder surfing ! C'est quoi ce bordel !!?? *"
Et la réponse des devs : Won't Fix. Circulez les relous !
En fait, leur argument c'est que le bénéfice sécurité est "infinitésimal". Parce que bon, votre mot de passe sudo c'est le même que celui de votre session (celui que vous tapez à l'écran de login, devant tout le monde). Et le bruit des touches trahit déjà la longueur de toute façon. Du coup, ils ont préféré régler le problème UX qui paume les débutants depuis le début des années 80.
Perso, le truc qui me gonfle c'est pour les tutos vidéo. Quand vous faites un screencast, les astérisques révèlent la longueur de votre mot de passe à tous vos spectateurs. Du coup faut aller reparamétrer chaque machine avant de filmer ou faire du masquage en post prod. C'est pas la fin du monde, mais bon, la flemme...
Alors pour désactiver ces jolies zétoiles :
sudo visudo
Et ajoutez cette ligne à la fin de /etc/sudoers :
Defaults !pwfeedback
Sauvegardez (Ctrl+X sous nano), et c'est réglé. Attention, ne touchez à rien d'autre dans ce fichier, une erreur de typo et sudo ne marchera plus. Grâce à cette manip, ce sera retour au trou noir ! Youpi !
Bon, vous connaissez la théorie du travailleur nomade... vous vous posez dans un café avec votre laptop, vous chopez du WiFi gratuit, et vous vous dites que l'isolation client du routeur vous protègera des autres branquignols connectés au même réseau.
Hé ben non ! Car des chercheurs viennent de démontrer que cette protection, c'était du vent... Oui oui, tous les routeurs qu'ils ont testés se sont fait contourner en 2 secondes.
Mais avant, pour ceux qui se demandent ce que c'est, l'isolation client c'est une option que les admins réseau activent sur les bornes WiFi pour empêcher les appareils connectés de communiquer entre eux. En gros, votre laptop ne peut pas voir celui du voisin. Enfin... ça c'est en théorie.
Parce qu'en fait, le truc c'est que cette fonctionnalité n'est même pas définie dans le standard WiFi (IEEE 802.11) ce qui oblige chaque fabricant à faire sa propre tambouille dans son coin, et du coup ça fuit de partout.
L'équipe derrière cette trouvaille, c'est des chercheurs de l'UC Riverside et de KU Leuven, dont Mathy Vanhoef, le même gars qui avait déjà mis le WPA2 à genoux avec
KRACK
en 2017. Pas un amateur, quoi et leur outil, baptisé AirSnitch, vient d'être présenté à la conférence
NDSS 2026
.
Ils ont ainsi trouvé 3 méthodes différentes pour contourner la protection d'isolation. La première abuse de la clé de groupe (GTK), normalement réservée au broadcast, pour envoyer du trafic directement à un appareil ciblé. Le pire, c'est que macOS, iOS et Android acceptent ce trafic sans broncher (merci les gars !).
La seconde fait rebondir les paquets via la passerelle, et la troisième vole carrément l'adresse MAC de la victime sur un autre point d'accès pour intercepter son trafic.
Brrrrrr.... 11 routeurs testés, du Netgear R8000 au Cisco Catalyst 9130 en passant par TP-Link, ASUS, Ubiquiti et même OpenWrt 24.10. Et ils sont TOUS vulnérables, sans exception ! Et que vous soyez en
WPA2
ou en WPA3, réseau perso ou entreprise, c'est pareil. Donc autant vous dire que ça pue !
Ils ont même réussi à effectuer un Man-in-the-Middle complet (interception de tout le trafic entre vous et Internet) en 2 secondes chrono. La "victime" qui regardait YouTube n'a même pas remarqué de lag et c'est comme ça qu'ils on pu intercepter tout son trafic, ni vu ni connu.
Alors du coup, on fait quoi ? Hé bien si vous gérez un réseau, oubliez l'isolation client toute seule et passez aux VLANs avec un VLAN par client. Oui c'est lourdingue à mettre en place, mais c'est le prix à payer pour avoir une sécurité solide. Certains constructeurs bossent aussi sur des clés de groupe individuelles par client, ce qui règlerait le problème à la source.
Côté utilisateur, la solution est plus simple...
VPN !!
Attention, ça ne marche que si le VPN est activé AVANT de vous connecter au réseau, pas après. HTTPS vous protège déjà pour le contenu des sites, mais selon Google, 6 à 20% des pages ne sont toujours pas en HTTPS... et même quand elles le sont, l'attaquant voit quand même où vous surfez et peut tenter du DNS spoofing. Donc sur n'importe quel
réseau WiFi public
, partez du principe que quelqu'un peut voir votre trafic, parce que visiblement c'est le cas.
Les 404, c'est la plaie du web... J'en sais quelque chose, je fais la chasse à ça en permanence sur mon propre site. C'est vrai que c'est relou parce que vous bookmarkez un projet cool, vous y retournez trois mois après... et pouf, ça a disparu. Le dev n'a pas renouvelé son nom de domaine, l'hébergeur a fermé boutique, le contenu s'est évaporé ou que sais-je encore... En fait, sur le web, RIEN n'est permanent.
PinMe
prend le problème à l'envers en collant vos fichiers directement sur
IPFS
. En gros, au lieu de dépendre d'un serveur unique qui peut tomber n'importe quand, vos pages sont distribuées sur un réseau décentralisé et identifiées par un hash CID unique. Du coup, tant que le réseau tourne, votre contenu existe. Pas besoin de renouveler quoi que ce soit, pas besoin de payer un hébergeur... ça fonctionne tout seul.
L'installation se fait en une ligne :
npm install -g pinme
Pour déployer votre site statique, c'est hyper simple :
pinmeuploaddist/
L'outil détecte le dossier de build, ou plutôt il le devine tout seul selon votre framework : dist/ pour Vite et Vue, build/ pour Create React App, out/ pour Next.js en export statique. Ça évite d'avoir à se palucher de la config.
Côté limites, on est sur 200 Mo par fichier et 1 Go au total ce qui est largement suffisant pour une landing page ou une démo ! Et c'est GRATUIT. Pour ceux qui veulent un domaine lisible plutôt qu'un hash cryptique, y'a aussi des domaines ENS (les .eth sur Ethereum) ou des sous-domaines en .pinit.eth.limo. Après pour les domaines custom faudra un compte VIP par contre.
Le truc sympa c'est que vos fichiers restent accessibles via n'importe quelle passerelle IPFS, genre dweb.link ou w3s.link. Ainsi, si votre hébergeur ferme ou que votre domaine expire comme je le disais en intro, on s'en fiche ! Le contenu est toujours là, épinglé quelque part sur le réseau. C'est du stockage immuable, basé sur le contenu lui-même... du coup personne ne peut modifier ou supprimer ce que vous avez publié. (Et en fait vous non plus, faut le savoir.)
Et y'a aussi des commandes pour exporter en fichiers CAR et réimporter ailleurs, ce qui est pratique pour archiver ou migrer entre passerelles.
Voilà c'est gratuit pour 1 Go de stockage, c'est open source (licence MIT) et
c'est par là
. Merci à Lorenper pour la découverte !
Si vous avez déjà tapé [ss -tulnp](https://www.it-connect.fr/lister-les-ports-en-ecoute-sous-linux-avec-lsof-netstat-et-ss/) dans un terminal, vous savez que c'est moche. Genre, VRAIMENT moche. Les colonnes qui se chevauchent, les adresses tronquées, bref c'est un festival du bordel. Mais c'était sans compter sur ce dev qui a pondu
Snitch
, un outil en Go sous licence MIT qui vient concurrencer ss et netstat... sauf que pour une fois, c'est lisible, regardez :
L'interface de Snitch en action, sobre et lisible
En gros, c'est un ss moderne avec une interface TUI interactive. Vous lancez la commande dans votre terminal et tadaaa, vous avez un tableau propre avec toutes vos connexions réseau, les processus associés, les ports, les protocoles... le tout avec des couleurs et une navigation au clavier. Rien à voir donc avec le pavé monochrome habituel !
Le truc cool aussi ce sont les filtres. Vous pouvez taper snitch ls proto=tcp state=listen pour ne voir que les sockets TCP en écoute, ou snitch ls proc=nginx pour traquer votre serveur web. Y'a même un filtre contains= pour chercher dans les adresses... genre contains=google pour voir tout ce qui cause avec Mountain View.
D'ailleurs, côté commandes c'est en fait bien fichu. snitch ls pour un tableau statique, snitch json pour du JSON brut si vous voulez scripter, et snitch watch -i 1s pour streamer les connexions en temps réel. Du coup ça s'intègre nickel dans vos pipelines.
La TUI elle-même vaut le détour. Vous naviguez avec j/k (comme dans Vim, forcément), vous basculez TCP/UDP avec t/u, et le plus jouissif... vous pouvez killer un processus directement avec la touche K. Plus besoin de noter le PID et d'ouvrir un autre terminal ! Sauf que attention, sur Linux faut quand même lancer en root pour avoir les infos complètes sur les processus, parce que l'outil va lire dans /proc/net/*. Ça ne marche pas non plus sur Windows, c'est Linux et macOS uniquement.
Pour ceux qui aiment personnaliser leur terminal (oui, je vous connaîs...), y'a une quinzaine de thèmes, Catppuccin, Dracula, Nord, Tokyo Night, Gruvbox... la config se fait dans ~/.config/snitch/snitch.toml et l'outil peut aussi conserver vos préférences de filtres entre les sessions (faut activer remember_state dans la config).
Côté installation, c'est pas la mer à boire. brew install snitch sur macOS, go install github.com/karol-broda/snitch@latest si vous avez Go, yay -S snitch-bin sur Arch, et y'a même des images Docker pour les plus prudents !
MinIO, tout le monde ou presque connaît car c'est LE truc quand on veut du stockage objet S3-compatible auto-hébergé sous Linux. Sauf que voilà... la licence AGPL, ça pique pour pas mal de boîtes qui ne veulent pas se retrouver à devoir ouvrir leur code.
Du coup, y'a un nouveau projet qui débarque dans le tiek et qui devrait en intéresser plus d'un. C'est
RustFS
, codé en Rust (comme le nom le laisse deviner mes petits Sherlock) et 100% compatible S3. En gros, vous prenez votre stack MinIO existante, vous remplacez par ce truc, et en fait tout continue de fonctionner pareil... Vos buckets, vos applis, vos scripts Python, boto3... tout pareil !
La licence c'est de l'Apache 2.0 comme ça y'a pas de contrainte virale, vous faites ce que vous voulez avec. Et c'est d'ailleurs sûrement la raison numéro un pour laquelle le projet cartonne.
Côté perfs, les devs annoncent 2,3x plus rapide que MinIO sur des petits objets de 4 Ko (testé sur un modeste 2 coeurs Xeon avec 4 Go de RAM). Bon, c'est un benchmark maison, à prendre avec des pincettes hein... mais finalement Rust pour du I/O intensif, ça se tient comme argument, car y'a pas de garbage collector qui vient foutre le bazar.
Et voilà, l'API tourne sur le port 9000 et la console web sur le 9001 (identifiants par défaut : rustfsadmin/rustfsadmin, changez-les vite fait hein). Y'a aussi du Kubernetes via Helm, un script d'install one-click, du Nix, ou un bon vieux git clone pour compiler vous-même (attention, sur macOS faut un ulimit à 4096 sinon ça ne marche pas).
Le conteneur Docker tourne en non-root (UID 10001), donc c'est plutôt propre niveau sécu. Pensez juste à faire un petit chown -R 10001:10001 data logs sur vos répertoires avant de lancer, sinon ça casse au démarrage.
Petit bonus appréciable, y'a aussi de la détection de corruption intégrée, et même du versioning de buckets pour les plus méfiants côté intégrité des données. D'ailleurs, côté monitoring, c'est déjà câblé pour envoyer vos métriques dans Grafana, vos traces dans Jaeger et le reste dans Prometheus. Un petit docker compose --profile observability up -d et c'est plié.
Par contre, on est encore en alpha et le mode distribué et le KMS sont en phase de test. Donc c'est PAS le genre de truc que vous mettrez en prod demain matin pour vos données critiques... mais pour du dev, du lab, ou des tâches pas trop sensibles... ça tourne impecc !
Bref, si l'AGPL de MinIO vous gave et que vous cherchez une alternative S3-compatible, en Rust, sous licence + permissive, allez jeter un œil à RustFS.
GDC ne sera pas le tremplin attendu pour les portables Windows sur Arm. L’absence de Qualcomm rebat le calendrier du segment, à un mois de l’échéance.
Qualcomm Windows gaming évite la GDC 2026
Qualcomm a confirmé à The Verge qu’aucune annonce liée à des machines Windows gaming ne sera faite à la GDC 2026, prévue du 9 au 13 mars à San Francisco. Le fournisseur ne proposera pas non plus de mises à jour Snapdragon X Series pour essais ou benchmarks sur place.
Ce retrait réduit fortement la probabilité de voir apparaître dès mars de nouveaux handhelds Windows sur Arm équipés de Snapdragon. La société n’a pas donné de raison officielle. Le rapport évoque toutefois la pénurie de mémoire, rappelant des propos tenus lors de l’appel aux résultats de février sur la disponibilité limitée des modules affectant les cadences d’assemblage.
Intel temporise aussi côté handheld
Deuxième frein conjoncturel, la fenêtre Intel se décale également. Des informations récentes situent les plans Panther Lake orientés handheld avec GPU Arc « G3 » en glissement vers le T2 2026, hors du créneau de mars.
Avec Qualcomm hors GDC et un timing Intel repoussé, la prochaine fenêtre industrielle crédible se rapproche de Computex 2026, début juin. C’est le moment où les OEM réajustent classiquement les feuilles de route laptop et handheld après les glissements de fin de T1 et début de T2.
Calendrier produit et réalignement OEM
Pour les constructeurs, l’absence de démonstrations Snapdragon X Series et de samples benchmarkables à la GDC retarde la validation des designs Windows on Arm. Couplé à la tension mémoire, cela limite les lancements en short-cycle et pousse les annonces coordonnables vers un cadre salon, plus propice aux mises à jour de gammes.
Ce décalage aligne paradoxalement les planètes pour des présentations plus mûres à Computex : maturité firmware, disponibilité DRAM/LPDDR, et positionnement face aux options x86 avec Arc G3 à l’horizon du T2 2026. Pour les joueurs, l’effet le plus tangible sera un premier semestre calme côté handhelds Windows, avant une reprise potentielle en juin si l’offre mémoire se normalise et si les plateformes Snapdragon et Intel arrivent à l’heure.
Deux chiffres résument l’annonce : 10,8 Go/s et HS-G6. Conséquence immédiate, le stockage embarqué grimpe d’un cran sans casser la compatibilité UFS 4.x.
UFS 5.0 et UFSHCI 5.0 : bande passante et efficacité au service des charges IA
JEDEC publie JESD220H (UFS 5.0) et JESD223G (UFSHCI 5.0) pour smartphones, automobile et systèmes informatiques basse consommation. Le standard vise un accès plus rapide aux données tout en restant compatible avec le matériel UFS 4.x.
UFS 5.0 pousse les lectures/écritures séquentielles jusqu’à 10,8 Go/s et intègre une égalisation de liaison pour fiabiliser les débits élevés. Un rail d’alimentation distinct isole bruit PHY et sous-système mémoire, ce qui simplifie l’intégration et améliore l’intégrité de puissance.
L’inline hashing ajoute des contrôles d’intégrité directement dans le chemin de données, accélérant la détection de corruption ou de manipulation. L’ensemble cible les usages IA embarqués, l’automobile, l’edge et les consoles.
MIPI M-PHY 6.0, UniPro 3.0 et HS-G6 à la manœuvre
Le lien d’interconnexion UFS 5.0 s’appuie sur MIPI M-PHY 6.0 et UniPro 3.0. Le nouveau mode HS-G6 double le plafond d’HS-G5 et fournit 46,6 Gb/s par voie et par direction. Sur 2 voies M-PHY, UFS 5.0 atteint ~10,8 Go/s effectifs en lecture/écriture.
Les industriels s’alignent : KIOXIA met en avant l’interface à 10,8 Go/s pour accélérer l’adoption mobile axée IA. MediaTek prévoit un support rapide sur ses plateformes hautes performances et sobres. Samsung annonce jusqu’à deux fois les performances d’UFS 4.1, des boîtiers plus compacts, une meilleure intégrité signal/puissance, un boot plus rapide et une gestion SLC buffer optimisée.
Sandisk parle d’un saut de performance pour l’edge intelligent, avec des solutions plus rapides, fiables et efficientes. SK hynix met en avant 10,8 Go/s en lecture pour réduire les temps de chargement LLM, l’intégration officielle Zoned LU pour des performances soutenues sur charges IA lourdes, et le Pre-Erase pour optimiser la vitesse d’écriture côté smartphone.
Implications techniques immédiates
Le couple UFS 5.0/UFSHCI 5.0 consolide le pipeline de données des SoC mobile/auto en multipliant la bande passante, tout en renforçant la fiabilité via l’égalisation et l’isolation d’alimentation. En pratique, le chargement de modèles IA et les traitements soutenus devraient gagner en latence et en régularité, sans pénaliser l’enveloppe énergétique.
Connexion
