Archives de catégorie : Fiche technique

Fiche technique : le Wifi 8

Alors que le Wi-Fi 7 commence à peine à se déployer dans les équipements haut de gamme, la prochaine génération de la technologie sans fil pointe déjà son nez.

Le Wi-Fi 8, officiellement désigné sous le nom de IEEE 802.11bn Ultra High Reliability (UHR), ne ressemble à aucune des générations précédentes. Là où le Wi-Fi 7 misait tout sur la course aux débits avec son concept d’Extremely High Throughput (EHT), le Wi-Fi 8 change fondamentalement de philosophie.

La caractéristique la plus marquante du Wi-Fi 8 est ce recentrage stratégique. Les générations successives, du Wi-Fi 4 au Wi-Fi 7, ont toutes poursuivi un même objectif, celui d’augmenter les débits théoriques maximaux.

Le Wi-Fi 8 rompt avec cette logique en ne cherchant plus à atteindre des vitesses de pointe toujours plus élevées, mais en garantissant des connexions stables, une latence prévisible et une fiabilité sans faille, même dans les environnements les plus denses et les plus saturés.

MediaTek, l’un des principaux concepteurs de puces, résume ainsi cette évolution en expliquant que le Wi-Fi 7 est une « machine à débit » tandis que le Wi-Fi 8 se conçoit comme un « tissu de fiabilité ». Cette distinction n’est pas un simple argument marketing, car elle cache un changement d’architecture radio profond.

Sur le plan des performances brutes, le Wi-Fi 8 ne devrait pas surpasser significativement son prédécesseur. Il conserve les mêmes blocs de 320 MHz maximum, les mêmes bandes de fréquences en 2,4 GHz, 5 GHz et 6 GHz, ainsi que la même modulation 4096-QAM, si bien que le débit théorique maximal reste aligné sur celui du Wi-Fi 7, soit environ 23 Gbit/s.

En revanche, le gain se situe ailleurs. Selon les premières estimations, le débit effectif en conditions réelles pourrait être amélioré d’environ 25 % par rapport au Wi-Fi 7, tandis que la latence serait réduite d’autant. Certains fabricants évoquent même des débits théoriques proches de 100 Gbit/s, mais ces chiffres restent à prendre avec précaution, car l’essentiel est ailleurs : ce qui importe pour l’utilisateur, c’est une connexion fiable de 500 Mbit/s à travers deux murs, et non une vitesse théorique de 5,8 Gbit/s mesurée en laboratoire.

Continuer la lecture

Linux : run0 ou la fin programmée de sudo ?

Pendant des décennies, la commande sudo a été la clé de voûte de l’administration des systèmes Unix et Linux, un passage obligé pour les administrateurs souhaitant effectuer des opérations privilégiées. Cependant, un vent de changement souffle sur l’écosystème Linux. Des annonces récentes et des décisions majeures de la part de distributions influentes comme Fedora et Ubuntu laissent entrevoir la disparition programmée de sudo au profit de nouvelles alternatives plus modernes et sécurisées. Le leader de cette révolution n’est autre que run0, un outil intégré à systemd qui promet de redéfinir notre rapport aux privilèges système.

Le talon d’Achille de sudo: une question de conception

Pour comprendre ce changement, il faut revenir sur la faille fondamentale de sudo. Depuis sa création dans les années 1980, cette commande repose sur un mécanisme ancien et risqué : le bit setuid.

Le problème est que sudo est un binaire appartenant à root avec le bit setuid activé (rws). Cela signifie qu’un utilisateur standard, en exécutant sudo, voit le processus s’exécuter avec les droits de root. Si le binaire présente des défauts, un attaquant peut injecter une exploitation qui sera alors exécutée avec les droits root.

La surface d’attaque de sudo est également pointée du doigt. Avec plus de 100 000 lignes de code (presque 150 000 lignes, ce qui peut étonner car basiquement sudo effectue un fork+exec, fonctionnalité qui peut s’écrire en moins de 100 lignes de code en langage C), la marge d’erreur est considérable. Cet héritage des débuts d’Unix est aujourd’hui perçu par de nombreux experts comme une anomalie : « SUID est un concept très étrange. Dans mon monde idéal, nous aurions un système d’exploitation qui n’utilise pas du tout SUID ».

run0: la réponse de systemd

Continuer la lecture

Claude Code vs Codex : Le duel des agents de codage

Claude Code d’Anthropic et Codex dominent le marché des agents de codage autonomes, mais ils incarnent deux visions opposées du développement assisté par IA, chacune avec ses forces et ses faiblesses.

La différence fondamentale ne réside pas seulement dans le modèle d’IA, mais dans l’endroit où le travail est effectué.

Claude Code adopte une architecture « Terminal-First ». Bien que l’inférence du modèle (la réflexion de l’IA) se fasse dans le cloud d’Anthropic, l’exécution des commandes, la lecture des fichiers et la gestion du contexte sont 100% locales. L’agent agit comme un script avancé qui prend le contrôle de votre shell. Il n’y a pas de « sandbox » intermédiaire : si Claude Code lance un serveur de développement ou une suite de tests, c’est votre CPU et votre RAM qui travaillent. Cette approche offre une transparence totale mais expose directement votre système local à la charge de travail.

Continuer la lecture

Créer et gérer son miroir local des dépôts officiels Ubuntu

La mise en place d’un dépôt personnel, ou miroir local, des dépôts officiels Ubuntu est une pratique d’administration système qui consiste à cloner tout ou partie des dépôts de paquets sur un serveur situé sur le réseau local. L’objectif est de centraliser les sources de mise à jour et d’installation pour l’ensemble des machines d’un parc informatique.

L’un des intérêts majeurs d’un miroir local est l’optimisation de l’utilisation de la bande passante et le gain de temps. Dans un environnement où plusieurs machines doivent être mises à jour, chaque serveur ou poste de travail télécharge individuellement les mêmes paquets depuis les serveurs publics d’Ubuntu, ce qui entraîne une duplication massive des données .

En installant un miroir local, les téléchargements depuis l’extérieur ne sont effectués qu’une seule fois, lors de la synchronisation du miroir avec les dépôts officiels. Toutes les autres machines du réseau se servent ensuite de ce miroir, via le réseau local, pour obtenir leurs paquets . La vitesse de transfert sur un réseau local (par exemple, via Ethernet ou Wi-Fi) est en effet bien supérieure aux débits offerts par une connexion internet, ce qui rend les installations et les mises à jour quasi instantanées .

La mise en place d’un miroir local offre une indépendance vis-à-vis de la connexion internet. Dans des environnements où l’accès à internet est limité, instable ou inexistant, comme les laboratoires, les salles de classe ou les réseaux industriels, le miroir devient une ressource essentielle . Les machines peuvent continuer à s’installer, se mettre à jour et fonctionner normalement même en cas de panne de la connexion internet ou d’indisponibilité des serveurs officiels . Cette autonomie garantit la continuité des opérations dans des environnements critiques .

Pour les administrateurs système, un miroir local est un outil de contrôle puissant. En ne synchronisant que les dépôts et les composants sélectionnés, l’administrateur garde la main sur les versions des paquets disponibles pour ses utilisateurs . Il est ainsi possible de geler un environnement à un instant T, de tester les mises à jour de sécurité sur un petit nombre de machines avant un déploiement plus large, ou de garantir que toutes les machines d’un parc utilisent une version identique d’un paquet donné . En pratique, l’administrateur modifie le fichier /etc/apt/mirror.list pour ne retenir que les dépôts pertinents (par exemple, en ne conservant que la branche security pour les mises à jour de sécurité) .

Voici un tutoriel détaillé expliquant comment créer, utiliser et entretenir un miroir de dépôt Ubuntu.

Continuer la lecture

Le protocole IP pour les nuls

Tous les appareils présents sur Internet, que ce soient des PC, des serveurs, des smartphones, ou des objets connectés, doivent utiliser les protocoles universellement adoptés pour communiquer. Ils doivent être conforme au modèle OSI.

Le modèle OSI (Open Systems Interconnection), normalisé par l’ISO en 1984, décrit sept couches superposées. Chaque couche fournit un service à la couche supérieure et utilise les services de la couche inférieure. Ce découpage permet de faire évoluer une couche indépendamment des autres.

Couche 1, physique : Se charge de la transmission des bits sur un support (câble cuivre, fibre optique, ondes radio). Elle définit les tensions électriques, les débits, les modulations.

Couche 2, liaison : Se charge de l’organisation des bits en trames, de la détection d’erreur, de l’adressage sur le lien local (adresses MAC pour Ethernet). Protocoles de couche 2 : Ethernet, Wi-Fi, PPP.

Continuer la lecture