Spotify (paquet .deb officiel, spotify-client 1.2.95, Debian 13) ne s’ouvre plus. Aucune fenêtre, aucun message. Depuis le lanceur, rien ne se passe. Depuis un terminal :

$ spotify
$ echo $?
1

Avec --enable-logging=stderr, une seule ligne sort :

INFO:cef/libcef/common/crash_reporting.cc:209] Crash reporting enabled for process: browser

Puis le processus se termine avec le code 1.

Fausses pistes

• Le GPU : --disable-gpu, --in-process-gpu, --ozone-platform=x11|wayland, --use-gl=egl ne changent rien, le code de sortie reste 1.
• Le paquet : aucune mise à jour récente de Spotify, le binaire est intact.
• La config : ~/.config/spotify/prefs est lisible et cohérent.

Un test avec un profil vierge (XDG_CONFIG_HOME et XDG_CACHE_HOME pointés vers un dossier temporaire) démarrait, lui. Le problème venait donc du profil existant, pas de l’installation.

La cause

Spotify est une application CEF (Chromium Embedded Framework). Comme Chromium, elle n’autorise qu’une instance par profil, avec trois liens symboliques dans ~/.cache/spotify :

SingletonLock   -> huntervcx-imac151-10745
SingletonCookie -> 11476635766705238864
SingletonSocket -> /tmp/org.chromium.Chromium.sCe4Pv/SingletonSocket

Le contenu de SingletonLock est <hostname>-<pid>. Au démarrage, Chromium lit ce lien :

• si le hostname est celui de la machine, il vérifie si le PID tourne encore et récupère le verrou s’il est mort ;
• si le hostname est différent, il suppose que le profil est utilisé par une autre machine (profil sur un partage réseau) et ne touche à rien.

Ici, le verrou avait été laissé la veille par une session qui n’avait pas fermé proprement l’appli, avec l’ancien hostname huntervcx-imac151. Entre-temps, la machine était devenue iMac-Arthur. Spotify voyait donc un verrou « d’une autre machine » et quittait sans rien dire.

Le correctif

Vérifier qu’aucun Spotify ne tourne, puis supprimer les trois liens :

pgrep -af spotify
rm ~/.cache/spotify/SingletonLock \
   ~/.cache/spotify/SingletonCookie \
   ~/.cache/spotify/SingletonSocket

Ces fichiers ne contiennent que le verrou : ni compte, ni cache de morceaux, ni préférences. Spotify redémarre normalement.

À retenir

• Changer de hostname avec une appli Chromium/Electron/CEF qui a planté ou qui est restée ouverte laisse un verrou orphelin que l’appli ne sait plus reprendre.
• Même symptôme possible avec Chrome, Edge, VS Code, Discord, etc. : ls -la sur le dossier de profil et regarder les Singleton*.
• Un code de sortie 1 sans message est souvent un verrou ou un profil, pas un souci de GPU.
• Si tu changes de hostname, ferme tes applications avant, ou nettoie les Singleton* après.

Le symptôme

Instance : ~/.local/share/PrismLauncher/instances/26.3/minecraft. Écran 5120x2880 en plein écran, guiScale:3. Dans logs/latest.log, à l’ouverture de l’inventaire créatif :

Too many items (64) in UI, some will be skipped! (Reached maximum texture size 512x512)

Un petit dépannage en jeu existe : F3+T (recharger les packs) fait revenir les icônes, jusqu’à la prochaine fois.

Première piste : l’atlas d’icônes

Les icônes d’items de l’interface sont dessinées dans un atlas plafonné à 512x512 px. Si tout ne rentre pas, les items en trop sont ignorés : icône transparente. Ça ne dépend pas du resource pack, et avec un écran 5120x2880 en guiScale:3, les icônes sont grandes, donc l’atlas se remplit vite.

Mon hypothèse de calcul (non confirmée) : une icône fait 16 px x guiScale, donc un atlas de 512x512 contient 64 icônes à guiScale:4 (64 px), environ 100 à 3 et 256 à 2. Ça colle avec les logs : le message est apparu le 21 (14:07, 66 items) et le 22 (22:30:53, 64 items).

Test : guiScale:2 améliore les choses, mais l’interface devient trop petite. Un contournement, pas une solution.

Fausse piste : le driver et le noyau

• Noyau 7.2.11-imac5kstitch, amdgpu OK.
• OpenGL fonctionne sur le système : eglinfo en Wayland donne radeonsi pitcairn, GL 4.6, et glxinfo sous XWayland est accéléré.

Mais dans Minecraft, avant même la création de la fenêtre :

GlBackend.loadLibrary ... Could not retrieve OpenGL functions

Le jeu retombe alors sur Vulkan (RADV PITCAIRN, Mesa 25.0.7), et ça fonctionne. Les messages Requested swapchain extent ... not within allowed extent ne sont que le redimensionnement du plein écran sous XWayland, sans gravité.

Le vrai problème : SDL retombe sur XWayland

J’avais essayé de forcer OpenGL avec preferredGraphicsBackend:"default" dans options.txt (jeu fermé, sinon il réécrit le fichier). OpenGL échouait toujours avec la même erreur et le jeu repartait sur Vulkan : ce test n’avait donc jamais vraiment eu lieu.

La cause : SDL retombait sur XWayland, parce que mon compositeur n’a pas fifo-v1. La correction est une variable d’environnement dans l’instance Prism (Paramètres de l’instance, variables d’environnement, avec OverrideEnv=true) :

SDL_VIDEO_DRIVER=wayland

Résultat

Test du 23 octobre à 10h25 : OpenGL 4.6 radeonsi pitcairn, fenêtre SDL en wayland, guiScale:3, monde solo. Plus de souci d’icônes et plus de Too many items.

Ce qui reste à vérifier : sur le serveur, avec plus d’items (créatif en multi), quand il sera de nouveau en ligne. Si l’avertissement revient, il faudra voir s’il vient du serveur ou du backend. En attendant, mon avis : le vrai coupable était le repli sur XWayland, pas la taille de l’atlas.

À retenir

• Si OpenGL échoue dans Minecraft alors que eglinfo et glxinfo fonctionnent, regarde quel backend SDL utilise vraiment.
• Sous un compositeur Wayland sans fifo-v1, SDL peut retomber sur XWayland. SDL_VIDEO_DRIVER=wayland dans l’environnement de l’instance Prism règle le problème.
• Un test n’a de valeur que si on a vérifié qu’il teste bien ce qu’on croit (ici, le « test OpenGL » tournait en fait sur Vulkan).

L’objectif est donc simple :

arthur-perrot.example.com
        ↓
Adresse IPv4 publique actuelle

Le PC vérifie régulièrement son IP publique et, lorsqu’elle change, met automatiquement à jour l’enregistrement DNS correspondant chez Cloudflare.

Dans ce guide, nous allons réaliser ce DDNS avec un simple script Bash, l’API Cloudflare et un timer systemd sous Debian.

Prérequis

Il faut :

• un domaine dont le DNS est géré par Cloudflare ;
• Debian ou une distribution utilisant systemd ;
• curl ;
• jq ;
• un token API Cloudflare.

Installation des dépendances :

sudo apt update
sudo apt install curl jq

Dans les exemples, nous utiliserons :

Zone DNS : example.com
Record   : arthur-perrot.example.com

1. Créer le token API Cloudflare

Depuis Cloudflare, créer un API Token ayant uniquement les permissions nécessaires sur la zone concernée.

Permissions recommandées :

Zone → DNS → Edit
Zone → Zone → Read

Il est préférable de limiter le token à une seule zone DNS plutôt que de lui donner accès à l’ensemble du compte.

On peut vérifier que le token fonctionne :

export CF_API_TOKEN='cfat_xxxxxxxxxxxxxxxxx'

curl -s \
  -H "Authorization: Bearer $CF_API_TOKEN" \
  "https://api.cloudflare.com/client/v4/zones?name=example.com" | jq

Cloudflare doit retourner notamment :

{
  "success": true
}

La réponse contient également l’identifiant de la zone :

"id": "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"

Conservez ce Zone ID, nous allons l’utiliser directement dans le script.

2. Créer l’enregistrement DNS

Créer dans Cloudflare un enregistrement A, par exemple :

Type : A
Name : arthur-perrot
IPv4 : 1.2.3.4
TTL  : Auto

L’adresse initiale importe peu : le script la remplacera lors de sa première exécution.

On pourra vérifier la résolution avec :

dig +short arthur-perrot.example.com @1.1.1.1

Par exemple :

1.2.3.4

3. Créer le script DDNS

Créons notre script :

sudo nano /usr/local/bin/cloudflare-ddns

Contenu :

#!/bin/bash

set -e

TOKEN="$CF_API_TOKEN"
ZONE_ID="xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
RECORD="arthur-perrot.example.com"

# Récupération de l'IPv4 publique
IP=$(curl -fsS -4 https://api.ipify.org)

# Recherche de l'identifiant du record DNS
RECORD_ID=$(curl -fsS \
  -H "Authorization: Bearer $TOKEN" \
  "https://api.cloudflare.com/client/v4/zones/$ZONE_ID/dns_records?type=A&name=$RECORD" \
  | jq -r '.result[0].id')

if [ "$RECORD_ID" = "null" ] || [ -z "$RECORD_ID" ]; then
    echo "Record $RECORD introuvable"
    exit 1
fi

# Récupération de l'adresse actuellement publiée
CURRENT=$(curl -fsS \
  -H "Authorization: Bearer $TOKEN" \
  "https://api.cloudflare.com/client/v4/zones/$ZONE_ID/dns_records/$RECORD_ID" \
  | jq -r '.result.content')

# Rien à faire si l'adresse n'a pas changé
if [ "$CURRENT" = "$IP" ]; then
    echo "IP inchangée : $IP"
    exit 0
fi

# Mise à jour du record Cloudflare
curl -fsS -X PATCH \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  "https://api.cloudflare.com/client/v4/zones/$ZONE_ID/dns_records/$RECORD_ID" \
  --data "{\"content\":\"$IP\"}" \
  | jq -e '.success' >/dev/null

echo "$RECORD : $CURRENT -> $IP"

Rendre le script exécutable :

sudo chmod 700 /usr/local/bin/cloudflare-ddns

Le fonctionnement est volontairement simple :

Récupération de l'IP publique
              ↓
Lecture du record Cloudflare
              ↓
      IP identique ?
        ↙           ↘
      Oui           Non
       ↓             ↓
   Ne rien       Mise à jour
    faire        Cloudflare

4. Stocker le token séparément

Il est préférable de ne pas mettre le token Cloudflare directement dans le script.

Créer :

sudo nano /etc/cloudflare-ddns.env

Avec :

CF_API_TOKEN=cfat_xxxxxxxxxxxxxxxxx

Restreindre ensuite les permissions :

sudo chown root:root /etc/cloudflare-ddns.env
sudo chmod 600 /etc/cloudflare-ddns.env

Ainsi, seul root peut lire le token.

5. Créer le service systemd

Créer :

sudo nano /etc/systemd/system/cloudflare-ddns.service

Avec :

[Unit]
Description=Cloudflare DDNS updater
Wants=network-online.target
After=network-online.target

[Service]
Type=oneshot
EnvironmentFile=/etc/cloudflare-ddns.env
ExecStart=/usr/local/bin/cloudflare-ddns

Puis recharger systemd :

sudo systemctl daemon-reload

Testons le service manuellement :

sudo systemctl start cloudflare-ddns

Puis :

systemctl status cloudflare-ddns

Un résultat comme celui-ci indique que tout fonctionne :

Starting cloudflare-ddns.service - Cloudflare DDNS updater...
arthur-perrot.example.com : 1.2.3.4 -> 203.0.113.42
Deactivated successfully.
Finished cloudflare-ddns.service - Cloudflare DDNS updater.

Lors des exécutions suivantes, si l’IP n’a pas changé :

IP inchangée : 203.0.113.42

Il est normal que le service apparaisse ensuite comme :

inactive (dead)

Il s’agit d’un service oneshot : il effectue son travail puis se termine.

6. Exécuter automatiquement le DDNS toutes les 5 minutes

Nous pouvons maintenant utiliser un timer systemd.

Créer :

sudo nano /etc/systemd/system/cloudflare-ddns.timer

Avec :

[Unit]
Description=Update Cloudflare DDNS every 5 minutes

[Timer]
OnBootSec=30s
OnUnitActiveSec=5min
Persistent=true

[Install]
WantedBy=timers.target

Activer le timer :

sudo systemctl daemon-reload
sudo systemctl enable --now cloudflare-ddns.timer

Vérifier son état :

systemctl status cloudflare-ddns.timer

On doit obtenir :

Active: active (waiting)

Pour connaître la prochaine exécution :

systemctl list-timers cloudflare-ddns.timer

Par exemple :

NEXT                        LEFT     UNIT
Tue 17:43:20 EDT            4min     cloudflare-ddns.timer

7. Vérifier les logs

Les exécutions du script sont enregistrées dans le journal systemd.

Afficher les dernières exécutions :

journalctl -u cloudflare-ddns.service -n 20

Suivre les prochaines exécutions en direct :

journalctl -fu cloudflare-ddns.service

Pour afficher uniquement les événements depuis le dernier démarrage :

journalctl -b -u cloudflare-ddns.service

8. Vérifier après un reboot

Le timer étant activé avec :

sudo systemctl enable --now cloudflare-ddns.timer

il redémarrera automatiquement avec Debian.

On peut vérifier :

systemctl is-enabled cloudflare-ddns.timer
systemctl is-active cloudflare-ddns.timer

Résultat attendu :

enabled
active

Environ 30 secondes après le démarrage, une première vérification sera effectuée. Ensuite, le script sera exécuté toutes les cinq minutes.

9. Vérifier le résultat

Afficher l’IPv4 publique :

curl -4 -s https://api.ipify.org
echo

Puis vérifier le DNS :

dig +short arthur-perrot.example.com @1.1.1.1

Les deux valeurs doivent correspondre :

203.0.113.42
203.0.113.42

Le fonctionnement final est donc :

                    ┌─────────────────┐
                    │   PC Debian     │
                    └────────┬────────┘
                             │
                     toutes les 5 min
                             │
                             ▼
                    IP publique actuelle
                             │
                             ▼
                   Comparaison Cloudflare
                             │
                    ┌────────┴────────┐
                    │                 │
               identique          différente
                    │                 │
                    ▼                 ▼
                 rien          Cloudflare API
                                      │
                                      ▼
                         arthur-perrot.example.com
                                      │
                                      ▼
                            nouvelle IPv4 publique

Cette solution a l’avantage de n’utiliser aucun daemon DDNS supplémentaire : seulement curl, jq, quelques lignes de Bash et les mécanismes natifs de systemd.

Elle convient notamment à un laptop qui change régulièrement de réseau : domicile, partage de connexion, Wi-Fi extérieur, etc.

Il faut cependant garder à l’esprit que le DDNS ne contourne pas le NAT ou les restrictions du réseau. Le nom DNS pointera bien vers l’adresse IP publique utilisée par le laptop, mais cela ne garantit pas que les connexions entrantes vers celui-ci soient possibles, notamment derrière un CGNAT ou un réseau qui bloque les connexions entrantes.

Puis :

• vous fermez le capot,
• le terminal crash,
• votre SSH coupe,
• ou VSCode redémarre.

Et toute la session disparaît.

Contexte perdu. Historique perdu. Travail perdu.

Le problème ne vient pas de Claude Code.

Le problème, c’est que votre agent tourne directement dans le terminal actif.

Quand le terminal meurt, le processus aussi.

Pourquoi tmux change complètement l’expérience avec Claude Code

tmux permet de détacher une session terminal de votre fenêtre actuelle.

Résultat :

• votre session continue même si vous fermez votre terminal,
• vous pouvez reprendre plus tard exactement là où vous étiez,
• votre contexte Claude reste chargé,
• vos longues tâches continuent en arrière-plan.

C’est particulièrement utile :

• en SSH sur un VPS,
• sur des sessions longues,
• en multi-projets,
• avec plusieurs agents Claude simultanés,
• sur des serveurs distants,
• ou simplement pour éviter de garder un MacBook réveillé inutilement.

La méthode : un alias cc

L’objectif :

• créer automatiquement une session tmux,
• lancer claude remote-control,
• rattacher directement le terminal à la session,
• générer un nom unique par projet.

Installation rapide

Bash

echo "alias cc='SESSION=claude-\$(basename \"\$PWD\")-\$(date +%s); tmux new-session -d -s \$SESSION \"cd \\\"\$PWD\\\" && claude remote-control\" && tmux attach -t \$SESSION'" >> ~/.bashrc && source ~/.bashrc

Zsh

echo "alias cc='SESSION=claude-\$(basename \"\$PWD\")-\$(date +%s); tmux new-session -d -s \$SESSION \"cd \\\"\$PWD\\\" && claude remote-control\" && tmux attach -t \$SESSION'" >> ~/.zshrc && source ~/.zshrc

Utilisation

Depuis n’importe quel projet :

cc

Le script va :

1. créer une session tmux dédiée,
2. lancer Claude Code dans le dossier courant,
3. rattacher automatiquement votre terminal.

Reprendre une session Claude Code

Même après fermeture du terminal, la session reste active.

Pour voir les sessions :

tmux ls

Pour reprendre une session :

tmux attach -t nom-session

Pourquoi cette approche est intéressante en entreprise

Dans des environnements d’infrastructure ou de développement avancés, cette méthode permet :

• de garder des agents persistants,
• de limiter les pertes de contexte,
• de travailler proprement en SSH,
• d’améliorer les workflows DevOps,
• de lancer plusieurs environnements Claude en parallèle,
• et d’éviter les interruptions liées aux postes utilisateurs.

C’est aussi très pratique pour :

• Kubernetes,
• CI/CD,
• administration Linux,
• automatisation,
• développement backend,
• cybersécurité,
• ou support technique longue durée.

Bonus : multi-projets proprement isolés

Comme le nom de session inclut automatiquement le dossier courant, chaque projet possède sa propre session Claude indépendante.

Exemple :

claude-api-1748812941
claude-frontend-1748812958
claude-infra-prod-1748812972

Vous pouvez donc travailler sur plusieurs environnements simultanément sans collision.

Conclusion

Beaucoup de développeurs utilisent Claude Code comme un simple terminal amélioré.

Mais avec tmux, on commence réellement à traiter l’agent comme un processus persistant.

Le gain en confort est immédiat :

• moins de pertes,
• moins de redémarrages,
• moins de contexte à recharger,
• plus de stabilité.

Pour des workflows techniques avancés, c’est rapidement indispensable.

Ceux qui parlent d’architecture hexagonale, de clean code, de patterns élégants, de séparation stricte des responsabilités.
Et ceux qui livrent.

Je caricature volontairement. Mais le débat existe.

Et je le dis haut et fort : je suis un mauvais dev.
5 ans chez Epitech m’ont appris à coder, mais je n’aime pas. Donc je ne suis pas le meilleur.
Pourtant, je couche la plupart de vos devs car cette faiblesse est mon plus grand atout pour mes clients.

Le fantasme du code parfait

On a tous croisé ce profil :

• 14 couches d’abstraction,
• 12 interfaces pour une seule implémentation,
• une architecture “future proof”,
• zéro feature visible côté client.

Techniquement, c’est impressionnant.
Conceptuellement, c’est propre.

Mais pendant ce temps-là, le client attend toujours que le bouton fonctionne.

Le client ne voit pas :

• ton injection de dépendances raffinée,
• tes design patterns bien placés,
• tes noms de variables exemplaires.

Il voit :

“Est-ce que ça marche ?”

À l’inverse : le cow-boy du code

Et puis il y a l’autre profil.

Celui qui écrit vite.
Parfois sale.
Parfois redondant.
Mais fonctionnel.

Le produit sort.
Le client est content.
Le business avance.

Et souvent, c’est ce code-là qui fait rentrer l’argent.

La vérité est entre les deux

Dire que seul le résultat compte serait faux.
La dette technique existe. Elle est réelle. Elle coûte cher.

Mais se cacher derrière “l’architecture parfaite” pour retarder la livraison, c’est aussi une forme d’évitement.

La loi de Pareto (que j’affectionne depuis mon adolescence) est utile ici :

20 % d’effort bien placé produisent 80 % de la valeur.

Les 80 % d’effort supplémentaires pour rendre le code “académiquement pur” ne produisent pas toujours 80 % de valeur supplémentaire.

Parfois, ils produisent 5 % de confort intellectuel.

Ce que le client achète vraiment

Un client n’achète pas :

• un pattern,
• une structure élégante,
• un repository bien organisé.

Il achète :

• une solution à un problème,
• un gain de temps,
• une réduction de coût,
• un avantage concurrentiel.

L’architecture est un moyen.
Pas une finalité.

Mais attention : “fonctionnel” n’est pas une excuse

Le discours inverse est tout aussi dangereux.

“Ça marche” n’est pas un argument suffisant si :

• personne ne peut maintenir le code,
• chaque modification casse autre chose,
• la scalabilité est impossible,
• le refactoring devient hors de prix.

Le code jetable en production est une bombe à retardement.

La vraie maturité consiste à savoir où mettre l’effort.

Une règle simple

Avant d’ajouter une couche d’abstraction, pose-toi trois questions :

1. Est-ce que ce besoin existe vraiment aujourd’hui ?
2. Est-ce que ça simplifie la maintenance future ?
3. Est-ce que le client en tirera une valeur mesurable ?

Si la réponse est non aux trois…
Tu es peut-être en train de coder pour toi, pas pour le produit.

Ce que j’ai appris avec le temps

Un bon développeur n’est pas celui qui écrit le code le plus élégant.

C’est celui qui sait :

• livrer vite quand il faut,
• structurer quand c’est nécessaire,
• simplifier au lieu de complexifier,
• arbitrer entre vitesse et propreté,
• et surtout stopper son onanisme architectural.

Le code parfait n’existe pas.
Le code utile, oui.

Et dans un projet :

l’utilité doit toujours passer avant l’ego technique.

Arrêtez de réinventer la roue.

Et par pitié, arrêtez de réinventer la hache qui va couper du bois pour réinventer cette foutue roue.

Pissez du code qui tourne, pas du code qui brille

Lorsqu’on développe des outils de synchronisation, d’indexation ou de traitement de fichiers (sauvegarde, scan de répertoires, etc.), le parcours récursif du système de fichiers devient très vite un point critique de performance.

Dans nos tests, nous avons voulu comparer concrètement deux approches courantes en Python :

• os.walk() (méthode historique, très utilisée)
• os.scandir() (API plus récente et bas niveau)

L’objectif : un benchmark simple, sans optimisation artificielle, exécuté sur des dossiers réels, avec quelques centaines à plusieurs dizaines de milliers de fichiers.

Le benchmark

Le test consiste à :

• parcourir récursivement un dossier
• compter le nombre total de fichiers
• mesurer le temps d’exécution

Même logique, même machine, même code métier.
La seule différence : la méthode de parcours.

Résultats observés

Voici quelques extraits représentatifs des tests réalisés :

👉 Dans tous les cas, os.scandir() est environ 2× plus rapide.

Et plus l’arborescence est grande, plus l’écart devient significatif.

Pourquoi cette différence ?

1. Le coût caché des stat()

os.walk() repose sur une abstraction plus haut niveau.
Lorsqu’il parcourt les fichiers, Python effectue beaucoup d’appels système stat() pour déterminer si une entrée est un fichier ou un dossier.

Ces appels sont :

• coûteux sur disque
• encore plus lents sur des partages réseau (SMB, NFS, NAS)
• multipliés par le nombre total d’entrées

2. os.scandir() travaille plus bas niveau

os.scandir() utilise directement les informations retournées par le système de fichiers (via dirent sous Linux).

Résultat :

• le type (fichier/dossier) est souvent déjà connu
• pas besoin de stat() systématique
• beaucoup moins de passages kernel ↔ userland

C’est précisément ce qui explique le gain massif de performance.

“Mais os.walk() utilise déjà scandir, non ?”

Oui… en interne, depuis Python 3.5.

Mais :

• os.walk() reste une API généraliste
• elle génère des tuples complets (root, dirs, files)
• elle fait plus de travail que nécessaire dans des cas simples

👉 Quand on veut juste parcourir vite, os.scandir() utilisé directement reste imbattable.

Pourquoi choisir Python, malgré des performances inférieures à certains langages ?

Il est largement admis que Python est, sur le plan strictement technique, plus lent que des langages compilés comme C, C++ ou Rust. Cette réalité ne constitue cependant pas un défaut en soi, mais plutôt un compromis assumé. Le choix d’un langage ne se limite jamais à la seule performance brute : il implique des considérations de budget, de complexité, de maintenabilité et de dette technique sur le long terme.

Python se distingue avant tout par sa simplicité de conception et de lecture. Un code plus clair réduit le temps de développement, facilite les relectures, limite les erreurs et permet une montée en compétence plus rapide des équipes. À budget égal, cela se traduit par plus de fonctionnalités livrées, plus vite, et avec un risque projet nettement inférieur.

Par ailleurs, tous les projets ne nécessitent pas une optimisation maximale dès leur conception. Dans de nombreux cas, la performance n’est pas le facteur limitant principal, ou peut être améliorée ponctuellement, uniquement là où c’est nécessaire. Python permet précisément cette approche progressive : commencer simple, puis optimiser de manière ciblée, sans sur-ingénierie prématurée.

Enfin, la dette technique est souvent sous-estimée lorsqu’on privilégie des technologies plus complexes dès le départ. Des langages très performants mais plus exigeants en expertise peuvent générer des coûts élevés en maintenance, en recrutement et en évolution fonctionnelle. Python, en réduisant cette complexité initiale, offre un équilibre durable entre efficacité, évolutivité et maîtrise des coûts.

Bref, un peu d’amour pour Python 😉

Cas concrets où la différence est critique

Dans nos projets, ce genre de gain est loin d’être théorique. Il est déterminant pour :

• 🔄 outils de synchronisation
• 📂 scan de dossiers autonomes avec plusieurs dizaines de milliers de fichiers
• 🧾 pipelines de traitement data
• 🌐 serveurs de fichiers
• 🧠 moteurs d’indexation

Diviser par deux le temps de scan, c’est :

• moins de charge CPU
• moins d’I/O disque
• moins de latence perçue
• et une meilleure scalabilité globale

Recommandation

👉 Pour tout nouveau développement Python impliquant un parcours récursif de fichiers :

• privilégier os.scandir() avec une récursion explicite
• réserver os.walk() aux scripts simples ou non critiques

Ce choix seul peut transformer un script “acceptable” en un outil réellement industriel.

Si vous travaillez sur des problématiques de performance, stockage, automatisation ou traitement de fichiers à grande échelle, je peux vous accompagner de l’architecture jusqu’à l’optimisation bas niveau.

📩 Un projet ? Contactez-moi : Arthur Perrot, expert infrastructure & cybersécurité.

Quand j’installe dans notre infra un disque dur, qui refuse obstinément de tourner, je ne me contente pas d’un diagnostic rapide. Et dans bien des cas - surtout avec les Seagate Exos, HGST Ultrastar ou Toshiba Enterprise - la cause n’est pas le disque lui-même, mais… le connecteur d’alimentation SATA.

🔍 Le coupable : la norme SATA 3.3 et la fameuse broche 3.3 V

Depuis la norme SATA 3.3, trois petites broches à l’extrémité du connecteur d’alimentation ont vu leur rôle évoluer :

Les disques Enterprise, souvent conçus pour les serveurs Dell, HP ou Supermicro, interprètent la broche 3 comme une commande de désactivation.
👉 Résultat : si votre alimentation PC envoie du 3.3 V sur cette ligne, le disque croit qu’on lui ordonne de s’éteindre. Il ne tourne pas, ne chauffe pas, et reste invisible dans le BIOS.

⚡ Pourquoi certaines alimentations posent problème

Les alimentations modernes (comme les Corsair CV550, BeQuiet!, Cooler Master ou Seasonic grand public) respectent scrupuleusement la norme SATA 3.3.
Elles transmettent donc la tension 3.3 V (le fameux fil orange) jusqu’aux broches du connecteur SATA.
Sur un disque standard, aucun souci.
Mais sur un disque Enterprise, cette tension active le signal PWDIS, qui bloque tout démarrage.

Et même si vous retirez le câble orange, certains modèles continuent à poser problème :

• le connecteur SATA peut faire contact mécanique avec les broches 1–3,
• un rail interne de l’alimentation peut réinjecter une faible tension parasite,
• ou le câblage interne garde la broche active malgré l’absence de fil apparent.

👉 Le disque reste donc désactivé, même sans fil orange visible.

🧠 Les solutions connues (et testées)

Bon ok là c’est pas du kapton, mais c’était à titre de test !

🟡 Pourquoi le Kapton est la meilleure solution

Le Kapton (polyimide) est un ruban isolant conçu pour l’électronique :

• il résiste à la chaleur (jusqu’à +260 °C),
• il ne laisse aucun résidu en cas de retrait,
• il est ultra-fin, donc le connecteur SATA s’enfiche sans forcer.

Pour neutraliser la ligne 3.3 V, il suffit :

1. De couper un petit rectangle (~5 × 3 mm),
2. De le coller sur les 3 premières broches à gauche du connecteur SATA (côté contacts dorés),
3. De rebrancher le câble d’alimentation.

Votre disque redémarrera instantanément — et sans aucune modification définitive du câblage.

🧩 En résumé

🧰 Conclusion

Ce petit détail de conception, invisible à l’œil nu, explique des centaines de faux diagnostics “disque HS” chaque année.

Chez nous, on préfère comprendre plutôt que remplacer.
Alors avant de renvoyer un disque “mort”, vérifiez vos câbles, vos rails… et si besoin, sortez le ruban Kapton.

💡 Astuce : si vous travaillez souvent avec des disques Enterprise, gardez toujours quelques adaptateurs Molex → SATA et un rouleau de Kapton tape dans votre atelier.
Cela vous évitera bien des sueurs froides.

Une PME française cliente, spécialisée dans le conseil et employant une dizaine de collaborateurs en télétravail, nous a contactés : depuis environ deux semaines, plusieurs de ses utilisateurs connectés via des Bbox Wi-Fi 6 ou Wi-Fi 6E de Bouygues Telecom rencontraient une instabilité importante sur leurs connexions VPN de type WireGuard. Nous l’avons aidée à diagnostiquer le problème.
Le phénomène touche principalement les configurations suivantes :

• Tunnel entre un client en IPv6 publique (Bbox) et un serveur en IPv4 fixe
• Accès via pont WireGuard / réseau local routé
• Protocole UDP encapsulant du trafic TCP (SMB, SSH, RDP, HTTPS)

🚨 Symptômes observés

• Ping fonctionnel (ICMP non impacté)
• RDP, SSH, SMB ou interfaces web qui se connectent puis se figent ou se déconnectent
• Fortes pertes de paquets, latence anormale sur les flux TCP lourds
• Aucun blocage firewall apparent, ni reset TCP
• Problème limité aux clients derrière Bbox Bouygues, les autres connexions (Free, Orange, SFR, Bouygues 5G, etc.) restant stables

🔍 Cause probable

Les analyses réseau réalisées pendant le diagnostic indiquent une réduction effective de la MTU sur les interfaces WAN des Bbox Bouygues Wi-Fi 6 depuis la dernière mise à jour firmware.
Cette mise à jour semble également forcer l’activation d’IPv6 (SLAAC / DHCPv6-PD), créant un mélange IPv6/IPv4 non transparent pour les tunnels WireGuard.

Résultat :

• Les paquets UDP WireGuard dépassant ~1408 octets sont fragmentés ou perdus
• Le ping (petits paquets) continue de fonctionner
• Les flux TCP encapsulés deviennent instables, particulièrement sur les connexions vers des serveurs IPv4 fixes.

🧰 Solution temporaire

Aucune communication officielle n’a encore été publiée par Bouygues Telecom, mais la solution est simple et efficace :

✅ Sur le poste client WireGuard (derrière la Bbox)

Modifier le fichier de configuration :

[Interface]
MTU = 1380

Puis redémarrer le tunnel.

Cette seule ligne force la taille maximale des paquets WireGuard à un seuil compatible avec la nouvelle MTU Bouygues (~1408 octets effectifs), supprimant immédiatement les pertes et ralentissements.

💡 En complément

• Désactiver IPv6 sur la Bbox (ou côté client) si possible (non possible sur les bbox grand public, pas de retex coté pro)
• Vérifier que le DNS utilisé est bien en IPv4
• Ne pas modifier le MTU côté serveur (pfSense ou Proxmox) si les autres clients fonctionnent correctement

🧩 Exemple typique

Dans le cas de ce client, un poste avec l’adresse WireGuard 10.61.0.10 derrière une Bbox Bouygues tentant d’accéder à un serveur Proxmox 10.172.41.1 voyait :

• Ping stable
• mais interface web (:8006) et SMB gelées.

Après avoir ajouté MTU = 1380, le trafic est redevenu fluide immédiatement.

🧠 En résumé

🛡️ Notre recommandation

Je conseille à tous mes clients utilisant des tunnels WireGuard sur infrastructures Bouygues de :

1. vérifier la stabilité du tunnel via ping -f -l 1472 (Windows) ou ping -M do -s 1472 (Linux),
2. ajuster le MTU à 1380 si nécessaire,
3. désactiver temporairement IPv6 si des instabilités persistent.

Je suis ce comportement de près et mettrai à jour cette note dès qu’un correctif officiel Bouygues ou une évolution de firmware sera confirmée.

💬 Besoin d’assistance ?
Je peux auditer votre tunnel WireGuard ou votre interconnexion multi-site.
👉 Contactez-moi : Arthur Perrot, expert infrastructure & cybersécurité.

Bits, octets : la base

• 1 octet (B) = 8 bits (b).
• Les débits réseaux sont généralement exprimés en bits par seconde (ex. 1 Gb/s).
• Les vitesses de disques ou de transferts de fichiers sont exprimées en octets par seconde (ex. 150 MB/s).

👉 Résultat : 1 Gb/s ≈ 125 MB/s en pratique.

Tableau comparatif des débits

Voici un tableau simple pour mieux visualiser les vitesses typiques des disques et des réseaux, avec leurs équivalents en anglais et en français :

Exemple concret : une sauvegarde de 1 To

Imaginons une sauvegarde de 1 To (≈ 1000 Go) à transférer vers un serveur de backup. Voici le temps que cela prend selon le réseau :

• Réseau 1 GbE (125 MB/s max) :
  1000 Go ÷ 125 MB/s ≈ 2h15
• Réseau 10 GbE (1250 MB/s max) :
  1000 Go ÷ 1250 MB/s ≈ 13 minutes
• Réseau 40 GbE (5000 MB/s max) :
  1000 Go ÷ 5000 MB/s ≈ 3 minutes

👉 Vous voyez le problème : sur du 1 GbE, un simple backup peut durer des heures, et pendant ce temps votre réseau est saturé.

Le goulot d’étranglement

Un principe clé à retenir : la vitesse finale dépend toujours du maillon le plus lent.

Prenons un exemple : vous devez sauvegarder 4 To de données.

• Sur des SSD NVMe capables de 3500 MB/s, la copie pure disque → disque pourrait théoriquement se faire en moins de 20 minutes.
• Mais si votre réseau n’est qu’en 1 GbE (≈ 125 MB/s réels), le transfert tombe à :
  4000 Go ÷ 125 MB/s ≈ 9 heures.
• Avec un réseau 10 GbE (≈ 1250 MB/s), le même backup prendrait seulement :
  4000 Go ÷ 1250 MB/s ≈ 53 minutes.

👉 Moralité : vos disques peuvent être ultra rapides, mais si le réseau est trop lent, c’est lui qui bloquera la performance globale.

Comment dimensionner intelligemment ?

1. Évaluer vos flux de données : combien de To de backup chaque nuit, combien de VM répliquées, quels temps de transfert acceptables.
2. Comparer disque et réseau : s’assurer que le réseau ne bride pas les disques, et inversement.
3. Prévoir de la marge : avec la croissance des données, il vaut mieux surdimensionner légèrement.
4. Segmenter vos usages : séparer trafic de production, backups, et répliques pour éviter la saturation globale.

Conclusion

Bien dimensionner le débit réseau est aussi critique que de choisir les bons serveurs.
J’accompagne les entreprises à auditer, optimiser et moderniser leurs infrastructures réseau et stockage. L’objectif : garantir que vos sauvegardes passent en temps voulu, sans saturer vos flux critiques.

📩 Un doute sur le dimensionnement de votre réseau ?
👉 Contactez-moi : Arthur Perrot, expert infrastructure & cybersécurité.

1. useradd : la commande native

useradd fait partie des outils bas niveau de gestion des comptes utilisateurs fournis par le paquet passwd (souvent issu du projet shadow-utils dans les distributions modernes).

• Rôle : créer un compte utilisateur en manipulant directement les fichiers systèmes comme /etc/passwd, /etc/shadow, /etc/group et /etc/skel.
• Comportement : par défaut, useradd est assez strict et minimaliste. Si aucune option n’est passée, l’utilisateur peut être créé sans répertoire personnel ni shell défini.
• Syntaxe : useradd -m -s /bin/bash nouvelutilisateur Ici, -m force la création du home directory et -s définit le shell par défaut.

En résumé, useradd est un outil bas niveau, destiné à être utilisé dans des scripts ou par des administrateurs expérimentés qui savent exactement quels paramètres fournir.

2. adduser : le wrapper convivial

adduser n’est pas une commande native du noyau ou des utilitaires de base, mais un script Perl (dans Debian/Ubuntu et dérivées). Son but est de rendre l’expérience plus simple et plus interactive.

• Rôle : fournir une interface de haut niveau pour useradd.
• Fonctionnement : il agit comme un wrapper : il appelle useradd (et parfois usermod) en arrière-plan, mais ajoute une logique de vérification et une interaction avec l’administrateur.
• Interaction : lorsque vous tapez : adduser nouvelutilisateur le script va vous poser des questions : mot de passe, nom complet, informations supplémentaires… puis créer automatiquement le répertoire personnel, copier les fichiers de /etc/skel, configurer les droits, etc.

Pourquoi en Perl ?

Historiquement, dans Debian et ses dérivés, adduser a été écrit en Perl afin de bénéficier rapidement d’un langage de script puissant et portable pour ajouter cette couche d’ergonomie au-dessus des outils système existants.

• Cela permettait d’avoir une logique conditionnelle et interactive, plus difficile à maintenir en pur shell.
• Avec Perl, la gestion des chaînes, des formulaires interactifs et de la configuration est plus simple.

3. Différences pratiques entre useradd et adduser

4. Conclusion : lequel utiliser ?

• Sur Debian/Ubuntu et distributions dérivées, adduser est recommandé pour la plupart des cas, car il est plus sûr et évite les oublis (home directory, shell, etc.).
• Sur d’autres systèmes comme Red Hat, CentOS, Fedora, seule la commande useradd est disponible — ce qui reflète bien sa nature d’outil universel.

En pratique, adduser n’est qu’un wrapper en Perl autour de useradd, mais il illustre bien une philosophie Debian : rendre l’administration plus accessible tout en gardant la puissance des outils Unix en arrière-plan.

👉 Lorsqu’on automatise la gestion des comptes dans nos infrastructures clientes, on privilégie useradd dans les scripts (prévisible, universel), et adduser dans l’administration manuelle quotidienne (ergonomique, sécurisé).

Dans une équipe, respecter un style de code est essentiel.
Un des outils simples de VSCode est le ruler : une ligne verticale qui s’affiche dans l’éditeur à une colonne donnée (par ex. 80 caractères).

Cela permet de se rappeler jusqu’où on écrit par ligne : meilleure lisibilité, cohérence entre développeurs, respect des bonnes pratiques.

Exemple de configuration minimaliste

Voici une configuration settings.json pour VSCode, concentrée sur l’essentiel :

{
    "editor.rulers": [80],
    "workbench.startupEditor": "newUntitledFile",
    "git.autofetch": true,
    "editor.detectIndentation": false,
    "editor.renderWhitespace": "all",
    "workbench.panel.defaultLocation": "right",
    "terminal.integrated.cursorStyle": "line",
    "terminal.integrated.fontFamily": "monospace",
    "window.menuBarVisibility": "toggle",
    "diffEditor.ignoreTrimWhitespace": false
}

Explications rapides

1. "editor.rulers": [80]
   Affiche un guide vertical à 80 colonnes → idéal pour garder un code lisible et homogène.
2. "workbench.startupEditor": "newUntitledFile"
   VSCode ouvre directement un fichier vide au démarrage → gain de temps, on code tout de suite.
3. "git.autofetch": true
   Met automatiquement à jour les infos Git distantes → on voit toujours l’état réel du projet sans fetch manuel.
4. "editor.detectIndentation": false
   Empêche VSCode d’essayer de “deviner” les indentations → l’éditeur suit vos règles, pas celles détectées dans le fichier.
5. "editor.renderWhitespace": "all"
   Affiche visuellement espaces et tabulations → évite les erreurs de style invisibles.
6. "workbench.panel.defaultLocation": "right"
   Place la console à droite plutôt qu’en bas.
   👉 Si on se limite volontairement à des lignes de 80 colonnes, mieux vaut garder plus d’espace vertical que horizontal.
   Cela reste toutefois un choix personnel, chacun adapte à son confort.

Un style clair, pour toute l’équipe

Mettre en place ces règles simples dans VSCode permet :

• d’avoir un code plus lisible,
• de garantir une cohérence entre développeurs,
• et d’éviter les erreurs invisibles (espaces, indentations incohérentes).

Un petit ajustement dans votre settings.json, et vous posez les bases d’un coding style partagé dans vos projets.

Quand on code en C ou C++, chaque fichier .h doit être protégé avec un header guard (#ifndef, #define, #endif) pour éviter les inclusions multiples.
On a tous déjà fait du copier-coller un peu mécanique… mais VSCode permet d’automatiser ça en un snippet ultra simple.

Le snippet magique

Voici un exemple de snippet à ajouter dans vos User Snippets VSCode (menu Preferences > User Snippets → choisir cpp.json):

"C C++ Header": {
    "scope": "c, cpp",
    "prefix": "header",
    "description": "Add #ifndef, #define and #endif",

    "body": [
        "#ifndef ${TM_FILENAME_BASE/(.*)/${1:/upcase}/}_H",
        "#define ${TM_FILENAME_BASE/(.*)/${1:/upcase}/}_H",
        "",
        "$0",
        "",
        "#endif"
    ]
}

Comment ça marche ?

• Tapez simplement header dans un fichier .h
• Appuyez sur Tab → VSCode génère automatiquement :

#ifndef MONFICHIER_H
#define MONFICHIER_H

// Votre code ici

#endif

Le nom du fichier est repris automatiquement et converti en majuscules. 🚀

Gain de temps & de rigueur

• Plus besoin d’écrire les guards à la main
• Uniformité garantie sur tous vos headers
• Moins d’erreurs d’inclusion multiple

Un petit snippet, un gros confort au quotidien.

Il suffit d’éditer le fichier /etc/inputrc et d’ajouter (ou décommenter) la ligne suivante :

set bell-style none

Enregistrez, rechargez votre session, et terminé : plus de beep intempestif ! 🎉

👉 Astuce bonus : vous pouvez aussi remplacer le beep par un signal visuel en utilisant :

set bell-style visible

python3 -m http.server 8000

Par défaut, cette commande lance un serveur HTTP qui rend accessible le dossier courant sur le port 8000.
Il suffit alors de se connecter à http://votre_ip:8000 depuis un navigateur pour télécharger vos fichiers.

✅ Idéal pour :

• partager des fichiers sur un réseau local,
• dépanner un collègue,
• accéder à vos données depuis un autre appareil.

⚠️ Attention : ce serveur est basique et ne gère pas la sécurité. À utiliser plutôt dans un cadre privé ou ponctuel.

Voici la commande magique :

xclip -selection clipboard -out | tr \n \r | xdotool selectwindow windowfocus type --clearmodifiers --delay 25 --window %@ --file -

👉 Explications rapides :

• xclip : récupère le contenu du presse-papier.
• tr \n \r : transforme les retours à la ligne pour éviter les bugs.
• xdotool type : simule la frappe caractère par caractère, comme un clavier humain.

Pratique, simple et 100% efficace pour gagner du temps !