À l'automne 2025, la fin du support de Windows 10 m'a placé devant un choix assez concret.
Mon poste de travail principal, TALYN, n'était pas éligible à Windows 11. Pourtant, avec son Core i7, ses 32 Go de mémoire, ses SSD et sa GTX 1660 SUPER, il répondait toujours largement à mes besoins professionnels.
Changer de machine uniquement pour répondre aux prérequis du nouveau système d'exploitation me paraissait difficile à justifier.
J'ai donc choisi une autre voie : conserver le matériel et remplacer Windows.
En novembre 2025, j'ai donc basculé sur Linux Mint.
Ce qui avait commencé comme une réponse pragmatique à la fin de Windows 10 allait finalement modifier plus profondément ma manière d'utiliser et de dépanner mon poste de travail.
Une transition moins brutale qu'elle n'y paraît
Passer de Windows à Linux Mint pouvait sembler constituer une rupture importante. Dans mon cas, elle l'a été beaucoup moins que prévu.
Sous Windows, j'utilisais déjà régulièrement Cygwin pour retrouver un environnement et des outils Unix qui me manquaient nativement. La ligne de commande et une partie des habitudes propres à cet écosystème faisaient donc déjà partie de mon environnement de travail.
Linux Mint n'a pas introduit ces usages. Il les a plutôt rendus natifs.
Concernant mes usages de développement et de ligne de commande, je ne repartais donc pas de zéro.
Les différences les plus importantes sont apparues ailleurs : fonctionnement de l'environnement graphique, périphériques, pilotes et, plus généralement, diagnostic du système lorsque quelque chose ne se comportait pas comme prévu.
Quand le premier freeze change la manière de raisonner
L'une des premières difficultés sérieuses est arrivée quelques semaines après la migration.
L'interface graphique s'est figée. Dans un premier temps, le pointeur de la souris répondait encore, avant que la machine ne semble finalement complètement bloquée.
C'est à ce moment-là que j'ai commencé à découvrir une distinction devenue depuis importante dans ma manière de diagnostiquer mon poste : une interface graphique figée ne signifie pas nécessairement que tout le système l'est.
Accès à un TTY (une console texte accessible en dehors de l'interface graphique), inspection des processus, redémarrage de Cinnamon, récupération de la session graphique, Magic SysRq (une combinaison clavier bas niveau qui parle directement au noyau) : j'ai progressivement constitué une hiérarchie de solutions permettant d'essayer de récupérer la machine avant de recourir au redémarrage brutal.
Certaines fonctionnent selon la nature du blocage. D'autres non.
L'important était ailleurs : le redémarrage complet n'était plus nécessairement ma première réponse à un environnement graphique qui ne répondait plus.
Quand le problème venait finalement du stockage
Les ralentissements et blocages m'ont également amené à plusieurs reprises à suspecter la mémoire.
TALYN dispose pourtant de 32 Go de RAM. En mesurant mémoire utilisée, disponible et sollicitation du swap (la mémoire de secours sur disque), rien ne permettait de conclure à un épuisement de la RAM. Des processus relativement actifs étaient bien présents, notamment le navigateur et Cinnamon, mais ces mesures ne suffisaient pas à expliquer les symptômes.
Cela m'a rappelé une règle simple que l'on oublie facilement lorsqu'un incident bloque son outil de travail :
un symptôme n'est pas une cause.
La même logique — mesurer avant conclure — m'a fait élargir l'investigation au-delà de la RAM. C'est là que le problème réel est apparu : l'espace disque disponible. Docker, avec l'accumulation d'images et de données au fil des mois, y avait sa part.
Ces investigations m'ont surtout laissé quelque chose de plus durable qu'une réponse ponctuelle : des commandes et une méthode pour examiner mémoire, swap, espace disque, processus et journaux avant d'établir un diagnostic.
Un scanner USB reconnu… mais pas réellement utilisable
Le matériel périphérique m'a confronté à un autre type de difficulté.
Mon Fujitsu ScanSnap S1300i était bien visible sur le bus USB. Cela ne signifiait pourtant pas qu'il était immédiatement utilisable sous Linux Mint.
Il a fallu descendre progressivement dans la chaîne : USB, SANE (le système standard Linux de gestion des scanners), firmware, permissions, puis application de numérisation.
Le firmware nécessaire n'était pas immédiatement disponible dans mon installation. Une fois récupéré et correctement déclaré auprès de SANE, scanimage a finalement été capable de piloter le scanner.
Le scanner était désormais exploitable via SANE, en ligne de commande. Restait un écart net avec l'usage quotidien que j'en attendais.
Quand le contournement devient un petit projet Rust
Le support était là : SANE savait piloter le scanner, scanimage savait numériser.
Mais mon besoin était beaucoup plus banal : placer des documents dans le chargeur, choisir un profil, lancer un scan recto-verso et récupérer directement un PDF exploitable. Cet écart entre ce que le support rendait possible et ce que mon usage quotidien exigeait, je pouvais évidemment le combler à coups de commandes shell. J'ai préféré transformer le besoin en petit projet et développer scan_cli en Rust — la suite logique de cette appropriation, pas un produit à part.
L'outil ne remplace ni SANE ni le firmware du scanner. Il orchestre les briques existantes pour fournir la couche d'usage qui me manquait :
- détection automatique du scanner ;
- profils document, niveaux de gris et couleur ;
- numérisation recto-verso ;
- génération de PDF ;
- configuration persistante ;
- gestion des principales erreurs ;
- diagnostic de l'environnement.
Ce cas est assez représentatif de ce que j'ai progressivement apprécié sous Linux.
Le système ne m'empêchait pas de faire ce que je voulais. Les briques existaient et étaient accessibles. Ce qui manquait était la couche correspondant exactement à mon usage.
J'ai pu la construire.
La ligne de commande n'est plus un outil de secours
Cygwin m'avait déjà habitué à utiliser des outils Unix sous Windows. Il serait donc faux de présenter mon passage à Linux Mint comme une découverte soudaine du terminal.
Ce qui a changé est plutôt sa place.
Sous Linux, la ligne de commande n'est plus une couche que j'ajoute à mon environnement : elle fait naturellement partie du système que j'administre.
Une commande utilisée initialement pour diagnostiquer un incident peut devenir un réflexe. Une séquence qui fonctionne plusieurs fois devient une procédure. Une procédure suffisamment stable finit dans mes notes ou dans un playbook.
Au fil des mois, je me suis donc constitué une petite boîte à outils adaptée non pas à « Linux » en général, mais à mon poste et à mes usages.
Un apprentissage largement assisté par l'IA
Il manque cependant un élément important à ce retour d'expérience : je n'aurais probablement pas mené ces investigations aussi loin sans l'assistance d'un LLM (Large Language Model), le type de modèle d'intelligence artificielle qui alimente notamment les assistants comme ChatGPT ou Claude.
Face à un problème, cette assistance me permettait d'avancer par itérations : décrire un symptôme, formuler des hypothèses, effectuer des vérifications, analyser leurs résultats puis écarter certaines pistes jusqu'à parvenir à une solution.
Le LLM ne connaissait pas nécessairement la cause dès le départ. L'intérêt était justement dans cette progression. Chaque résultat obtenu sur la machine alimentait l'étape suivante du diagnostic.
Cette approche m'a accompagné aussi bien pour comprendre un blocage de Linux Mint que pour diagnostiquer une saturation du stockage ou rendre mon scanner réellement utilisable. Dans ce dernier cas, la démarche est même allée au-delà du dépannage puisqu'elle a abouti à la création de scan_cli.
L'association Linux, ligne de commande et assistance par IA s'est ainsi révélée particulièrement efficace : le système fournit beaucoup d'informations observables et d'outils permettant d'agir, tandis que le LLM aide à transformer progressivement ces informations en diagnostic puis en solution.
Avec le recul, c'est une dimension importante de cette migration : je n'ai pas seulement appris à mieux utiliser Linux Mint. J'ai aussi appris à m'appuyer sur l'IA pour aller plus loin dans la compréhension et la résolution de problèmes que je n'aurais probablement pas abordés seul de la même manière.
Ce que je retiens finalement de cette migration
Je n'ai pas quitté Windows 10 parce que TALYN était devenu inutilisable. Il fonctionnait encore suffisamment bien pour que son remplacement, uniquement parce qu'il n'entrait pas dans les critères de Windows 11, me paraisse difficile à justifier. Linux Mint a d'abord été une réponse pragmatique à cette situation — Cygwin avait déjà préparé une partie du terrain, les mois suivants ont fait le reste.
Les incidents, eux, n'ont pas disparu : freezes, saturation de l'espace disque, périphérique récalcitrant. Certaines solutions ont fonctionné immédiatement, d'autres ont constitué des fausses pistes. Mais ils ont progressivement produit quelque chose que je n'avais pas anticipé lors de la migration : une connaissance beaucoup plus précise du fonctionnement de mon propre poste, et une méthode plus solide pour le diagnostiquer avant de le redémarrer.
C'est cette réflexion qui me sert aujourd'hui de point d'entrée pour documenter ces expériences séparément — certains des incidents évoqués ici feront l'objet de contenus à part : retours d'expérience techniques, playbooks de diagnostic et de récupération, notes opérationnelles. Ils n'existent pas encore ; ce texte n'en est que le point de départ.
Après plusieurs mois sous Linux Mint, le changement le plus durable n'est peut-être finalement pas le système d'exploitation lui-même.
C'est la manière dont j'ai recommencé à regarder ce qui se passe en dessous.