Page de recherche dans les notes du jardin numérique de Stéphane Klein

Recherche effectué dans :

Tous type de notes (5)

journal_note (5)

Filtre actif, cliquez pour en enlever un tag :

retour-d-expérience

Cliquez sur un tag pour affiner votre recherche :

Résultat de la recherche (5 notes) :

Après 3 ans d’utilisation intensive de mon Thinkpad T14s AMD Gen 3, le roulement de son ventilateur a commencé à faire du bruit. C’est le genre de bruit qui me rend totalement fou.

Identification et analyse de ventilateur d'origine

Voici la pièce en question :

Sonnet 5 a réussi à lire l’étiquette et à me donner les détails :

Fabricant : Delta Electronics Inc. (Made in China)
Modèle : NS85C41
Type : DC Brushless
Alimentation : DC5V, 0.50A
Un code produit du type 21QG01 (ou proche) et un QR code de traçabilité
Marquages de certification UR us et EPA

Delta Electronics est l’un des plus gros fabricants mondiaux de ventilateurs pour PC portables — ils équipent notamment Lenovo, Dell, HP en OEM. C’est un type de fournisseur « premium » (avec Foxconn, AVC, Sunon).
Leurs roulements sont généralement de bonne qualité constante, avec un contrôle qualité industriel sérieux, ce qui explique que le vôtre a tenu 3 ans en usage intensif avant de commencer à faire du bruit — c’est une durée de vie tout à fait normale, voire bonne, pour ce type de composant.

Sonnet 5

J’ai découvert les types de roulements utilisés dans les ventilateurs de laptop :

Sleeve bearing (roulement à manchon/bague) Le plus basique et le moins cher : un axe qui tourne dans un manchon en bronze/laiton imprégné d’huile. Bon marché à produire, mais l’usure est progressive et le bruit apparaît vite dès que le film d’huile se dégrade (chaleur, gravité qui fait couler l’huile vers le bas sur un axe vertical/incliné). C’est typiquement ce qu’on trouve sur les clones bas de gamme.

Ball bearing (roulement à billes) Des billes métalliques dans une cage, avec beaucoup moins de friction et de dérive dans le temps. Plus cher à fabriquer (précision d’usinage des billes et des chemins de roulement), mais dure largement plus longtemps et résiste mieux à la chaleur soutenue (le CPU d’un T14s tourne facilement à 60-80°C sous charge, ce qui dégrade l’huile d’un sleeve bearing plus vite).

FDB (Fluid Dynamic Bearing) Un axe usiné en cuivre pur (tournage de précision, pas de fritté comme le sleeve bearing classique) avec des rainures hélicoïdales qui guident l’huile et créent une pression maximale au point critique de charge, ce qui soutient et centre l’axe en rotation. C’est une évolution nettement plus sophistiquée du sleeve bearing : présenté par les fabricants comme un compromis silence/durabilité supérieur au ball bearing classique. C’est ce type de roulement qu’utilise notamment Sunon dans sa gamme MagLev/Vapo.

Variantes hybrides (hydro-bearing, dual-ball, oil-impregnated + ball) Les fabricants premium (Delta, Foxconn, AVC, Sunon — ceux que Lenovo utilise en OEM) combinent souvent les deux approches ou utilisent des formulations d’huile plus stables thermiquement, avec des tolérances d’usinage bien plus serrées.

Sonnet 5

Je n’ai pas trouvé la datasheet du modèle NS85C41 ni sur https://www.delta-fan.com, ni sur https://www.alldatasheet.com. Sonnet 5 pense que ce modèle semble être une référence « custom » fabriquée spécifiquement pour Lenovo, non cataloguée publiquement chez Delta Electronics.

Étant donné le positionnement haut de gamme du segment [Thinkpad T14s AMD Gen 3] (garantie 3 ans, usage en flotte d'entreprise) — plutôt qu'en raison du fabricant, [Delta Electronics] produisant aussi bien du bas de gamme que du premium selon la commande du client — [Claude Sonnet|Sonnet 5] pense qu'il est probable que ce ventilateur utilise un roulement de type [Ball bearing], possiblement dual-ball.

Il s’agit d’une inférence basée sur des indices indirects (durée de vie observée de 3 ans, positionnement produit, marketing général du fabricant), sans confirmation documentaire directe.

Remplacement par un ventilateur Aliexpress bas de gamme

Le 11 avril 2026, j’ai commandé ce ventilateur de remplacement chez Aliexpress à 35,99 €.

Je l’ai reçu le 26 avril et j’ai consulté cette vidéo pour l’installer. L’opération a été très simple.

Malheureusement, fin juillet 2026, le ventilateur fait à nouveau du bruit ! Après seulement 90 jours d’utilisation !

J’ai contacté le vendeur sur Aliexpress mais il ne semble pas très motivé à m’envoyer un nouveau modèle de remplacement :

Hello, the loud noise from the fan may be caused by hair or foreign objects being sucked in by the fan as it rotates. Therefore, this situation is more of a probabilistic issue.

Aliexpress

Étant donné son prix modeste et la panne survenue après seulement 90 jours — cohérent avec la faible résistance à la chaleur d’un roulement bas de gamme — Sonnet 5 suppose que ce ventilateur utilise un roulement de type Sleeve bearing.

Remplacement par un ventilateur acheté directement chez Lenovo

Ce bruit étant insupportable, j’ai cherché une solution pérenne. J’ai trouvé la section « pièces détachées » sur le site de support de Lenovo :

J’ai saisi le numéro de référence exact de mon modèle de laptop 21CQCTO1WW et j’ai trouvé les ventilateurs suivants : 5H41B77292 ou 5H41B77293.

J’ai demandé à Sonnet 5 la différence entre ces deux modèles de ventilateurs et j’ai eu la réponse suivante :

Bonne nouvelle : dans le cas présent, ce ne sont pas deux fans différents au sens fonctionnel, mais deux références FRU (Field Replaceable Unit) pour le même composant, provenant de fournisseurs différents.

Ce que disent les sources

Le module thermique 5H41B77292 est identifié comme AT2DU001VV0, JT4C5_UMA, explicitement compatible avec votre machine : T14s Gen 3 (Type 21CQ 21CR).

Les références 5H41B77292 / 5H41B77293 / 5H41B77294 sont systématiquement groupées ensemble par les revendeurs (Amazon, eBay, myfixguide, oemcomputerpart…) comme interchangeables pour les versions AMD du T14s Gen 3.

Les références 5H41B77305 / 06 / 07 correspondent, elles, aux versions Intel — donc pas pertinentes pour vous si votre machine est AMD (le suffixe « UMA » dans « JT4C5_UMA » suggère un chipset graphique intégré, cohérent avec les config AMD Ryzen sans GPU dédié).

Pourquoi Lenovo a plusieurs FRU pour la même pièce

C’est une pratique standard chez Lenovo : ils multi-sourcent certains composants (ici probablement le ventilateur/dissipateur) auprès de plusieurs fabricants (Delta, Foxconn, AVC, Sunon, etc. selon les périodes de production). Le boîtier, les caractéristiques électriques (5V, 0.5A, connecteur 6 fils) et la compatibilité mécanique sont identiques — seule l’origine/le lot de fabrication change. Ce n’est pas une histoire de config UMA vs dGPU ici (le T14s Gen 3 AMD n’a pas de dGPU dédiée), donc 77292 et 77293 sont fonctionnellement équivalentes.

Sonnet 5

Étant donné que les références 5H41B77292, 5H41B77293 sont internes à Lenovo, cette fois encore, je n’ai pas accès aux datasheets 😔.

Au hasard, je vais commander le modèle 5H41B77292 et je vais bien voir si ce modèle à 52 € au lieu de 35 € est de meilleure qualité et arrivera à nouveau à durer 3 ans !

Introduction

Après trois ans à repousser ce projet, je me suis enfin lancé en janvier 2026 dans la création de paquets RPM pour Fedora COPR.

J'ai créé et publié les packages aichat-git (repository) et text-to-audio (repository). L'expérience a été beaucoup plus simple et rapide que je le pensais. Les agents IA simplifient certes ce genre de tâche, mais même sans eux, le code reste plutôt minimaliste.

Pourquoi est-ce que je me suis intéressé à ce sujet ? Au départ, c'était pour distribuer qemu-compose sous forme de package RPM (voir issue).

Pour bien maîtriser ces opérations, la semaine dernière, je suis reparti de zéro et j'ai implémenté et publié le playground : fedora-rpm-copr-playground. Voici les objectifs de ce playground :

Générer un package pour distribuer un simple script Bash qui affiche un "Hello world" (dans la branche bash).
Générer un package pour distribuer une application Golang qui affiche un "Hello world" (dans la branche golang)

Pour chacun de ces packages, j'ai testé trois méthodes de build :

build du package RPM 100% local
build du package SRPM en local, puis upload sur Fedora COPR qui génère les RPM pour plusieurs plateformes et architectures (x86_64, aarch64, etc.)
une méthode basée à 100% sur Fedora COPR à partir des sources d'un dépôt GitHub, déclenchée automatiquement par un script GitHub Actions

Cette note documente ce playground et rassemble les difficultés que j'ai rencontrées. Le README.md reste consultable si vous préférez suivre un exemple pas à pas.

Le fichier .spec

Le point central pour créer un package RPM est le fichier .spec /rpm/hello-bash.spec :

# 
Name:           hello-bash
Version:        1.0.7
Release:        1%{?dist}
Summary:        A simple Hello World bash script

License:        MIT
URL:            https://github.com/stephane-klein/fedora-rpm-copr-playground
Source0:        hello-bash

BuildArch:      noarch

%description
A simple "Hello World" Bash script packaged as an RPM for Fedora COPR.

%prep
# Nothing to prepare, source is ready

%build
# Nothing to build, it's a bash script

%install
mkdir -p %{buildroot}/%{_bindir}
cp %{SOURCE0} %{buildroot}/%{_bindir}/hello-bash
chmod 755 %{buildroot}/%{_bindir}/hello-bash

%files
%{_bindir}/hello-bash

%changelog
* Thu Mar 19 2026 Stéphane Klein <contact@stephane-klein.info> - 1.0.0-1
- Initial release

Les lignes importantes dans ce fichier :

BuildArch: noarch, étant donnée que c'est un simple script, ce package n'est pas dépendant de l'architecture (processeur).
La section %install
La section %files

La syntaxe du format .spec peut sembler étrange en 2026. Elle date de 1995 — avant même l'existence de YAML (2001) et JSON (1999). Cette ancienneté explique les %... et %{...} qui peuvent paraitre cryptiques aujourd'hui.

Historiquement, le champ Source0 pointe vers une archive (généralement un tar.gz), contenant les sources du projet. Pour des cas simples, comme ici avec le script Bash, Source0 peut directement référencer le fichier source.

J'ai aussi implémenté une variante bash-multifiles dans le playground, pour tester le packaging de plusieurs scripts accompagnés d'un fichier de documentation. J'y indique les fichiers via Source0:, Source1:, Source2:, puis je les copie dans %install avec %{SOURCE0}, %{SOURCE1}, %{SOURCE2}. Cela fonctionne correctement, bien qu'au-delà de trois ou quatre fichiers, je pense qu'il soit probablement plus pratique d'utiliser une archive.

Build local du package RPM

Le script /build.sh suivant permet de générer un package RPM :

#!/bin/bash
set -e

TOPDIR="$(pwd)/rpmbuild"

mkdir -p "$TOPDIR"/{BUILD,RPMS,SRPMS,SOURCES,SPECS}

echo "Copying source to SOURCES..."
cp hello-bash "$TOPDIR/SOURCES/"

echo "Building RPM..."
rpmbuild --define "_topdir $TOPDIR" -ba rpm/hello-bash.spec

echo ""
echo "Build complete!"
echo "RPM: $TOPDIR/RPMS/noarch/"

Il commence par préparer la structure de dossier suivante :

/rpmbuild/
├── BUILD
├── RPMS
├── SOURCES
├── SPECS
└── SRPMS

Ensuite les fichiers à packager sont copiés dans rpmbuild/SOURCES

/rpmbuild/
├── BUILD
├── RPMS
├── SOURCES
│   ├── hello-bash
├── SPECS
└── SRPMS

Pour finir, la commande rpmbuild --define "_topdir $TOPDIR" -ba rpm/hello-bash.spec génère à la fois le package SRPM (source RPM) et le RPM binaire. L'option -ba signifie "build all". Pour générer uniquement le SRPM, il faudrait utiliser -bs (build source). Ici, comme le package contient un script Bash, il est de type noarch :

/rpmbuild/
├── BUILD
├── RPMS
│   └── noarch
│       └── hello-bash-1.0.7-1.fc42.noarch.rpm
├── SOURCES
│   ├── hello-bash
├── SPECS
└── SRPMS
    └── hello-bash-1.0.7-1.fc42.src.rpm

Publication sur Fedora COPR

Le playground contient un second script qui permet de publier le package sur Fedora COPR, ce qui permet de rendre accessible publiquement son package.

Voici comment cette méthode fonctionne. Tout d'abord, il faut créer un compte et un projet sur Fedora COPR. Dans le playground, j'ai implémenté le script init-copr-project.sh basé sur copr-cli, qui me permet d'automatiser la création du projet (paradigme GitOps).

$ copr-cli create "hello-bash" \
    --description "A simple Hello World Bash script packaged as an RPM (auto-build on tags)" \
    --chroot fedora-42-x86_64 \
    --chroot fedora-43-x86_64 \
    --chroot fedora-44-x86_64

Dans cet exemple, je demande à COPR de builder les packages du projet pour les distributions fedora-42-x86_64, fedora-43-x86_64, fedora-44-x86_64.

Après avoir configuré le projet COPR, je lance le script /build-copr.sh qui exécute :

copr-cli build "hello-bash" /rpmbuild/SRPMS/hello-bash-1.0.6-1.fc42.src.rpm

Le premier paramètre "hello-bash" est le nom du projet et le second est le package source SRPM préalablement construit localement par le script /build.sh.

Voici ce que donne l'exécution de ./build-copr.sh côté cli :

$ ./build-copr.sh

...

Build complete!
RPM: /home/stephane/git/github.com/stephane-klein/fedora-rpm-copr-playground/.worktree/bash/rpmbuild/RPMS/noarch/
Uploading package ./rpmbuild/SRPMS/hello-bash-1.0.6-1.fc42.src.rpm
 |################################| 8.5 kB 47.1 kB/s eta 0:00:00
Build was added to hello-bash:
  https://copr.fedorainfracloud.org/coprs/build/10252699
Created builds: 10252699
Watching build(s): (this may be safely interrupted)
  08:59:15 Build 10252699: pending
  08:59:45 Build 10252699: running
  09:00:15 Build 10252699: starting
  09:00:46 Build 10252699: running

Voici ce qui est visible sur l'interface web de COPR, https://copr.fedorainfracloud.org/coprs/stephaneklein/hello-bash/builds/ :

Une fois le build des packages terminé, il est facile d'installer le package avec les commandes suivantes :

$ sudo dnf copr enable -y stephaneklein/hello-bash
$ sudo dnf install -y hello-bash
$ hello-bash
Hello World

Automatisation GitOps avec COPR

Et pour finir, j'ai implémenté dans le playground l'automatisation complète de la compilation et publication des packages sur l'infrastructure COPR.

Pour cela, dans le script init-copr-project.sh j'ai déclaré l'URL du repository qui contient le code source :


...

copr-cli add-package-scm "$COPR_PROJECT" \
    --name hello-bash \
    --clone-url https://github.com/stephane-klein/fedora-rpm-copr-playground.git \
    --commit bash \
    --subdir . \
    --spec rpm/hello-bash.spec \
    --type git \
    --method make_srpm \
    --webhook-rebuild on

Le paramètre --commit bash permet de définir la branche Git à utiliser comme source.

Le paramètre --method make_srpm, qui permet à l'utilisateur d'utiliser un script personnalisé de génération du SRPM, à placer dans /.copr/Makefile à la racine du dépôt avec une cible srpm, exemple :

specfile = rpm/hello-bash.spec

.PHONY: srpm
srpm: $(specfile)
	mkdir -p /tmp/copr-srpm-build
	cp rpm/hello-bash.spec /tmp/copr-srpm-build/hello-bash.spec
	cp -r . /tmp/copr-srpm-build/source/
	cd /tmp/copr-srpm-build && \
		rpmbuild -bs hello-bash.spec \
			--define "_topdir /tmp/copr-srpm-build/rpmbuild" \
			--define "dist .fc42" \
			--define "_sourcedir /tmp/copr-srpm-build/source"
	cp /tmp/copr-srpm-build/rpmbuild/SRPMS/*.src.rpm $(outdir)

Je ne souhaite pas détailler ici d'autres méthodes comme tito ou Packit, mais la méthode make_srpm est la plus flexible, elle permet de contrôler entièrement comment le SRPM est construit.

Une fois tout ceci configuré, il est possible de rebuild le package directement en cliquant sur le bouton "Rebuild" sur l'interface web de COPR :

Dernière étape : j'ai implémenté un build automatique qui est déclenchée par un appel curl dans le job GitHub Actions /.github/workflows/trigger-copr-build.yml, dont voici le contenu :

name: Trigger Copr Build

on:
  push:
    tags:
      - '*'

jobs:
  trigger-copr-build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0

      - name: Verify tag is on bash branch
        run: |
          if ! git branch -r --contains ${{ github.ref_name }} | grep -q "origin/bash"; then
            echo "Tag ${{ github.ref_name }} is not on branch bash"
            exit 1
          fi

      - name: Trigger Copr webhook
        run: |
          curl -X POST https://copr.fedorainfracloud.org/webhooks/custom/226325/3cf20247-820b-4050-bfb1-593b01a6996f/hello-bash/

Ce job est exécuté à chaque publication d'un nouveau Git tag, suivi d'une vérification que le tag provient bien de la branche bash.

Claude Sonnet 4.6 m'a suggéré l'existence d'une méthode de polling de dépôt Git intégrée à COPR, mais je n'ai trouvé aucune trace de celle-ci dans la documentation.

J'ai aussi essayé d'utiliser la méthode basée sur les webhooks GitHub de COPR, mais je n'ai pas réussi à la faire fonctionner. L'interface de GitHub m'indiquait à chaque fois une erreur dans la réponse des calls HTTP. C'est pour cela que j'ai fini par déclencher le webhook custom via un job GitHub Actions.

Package d'un projet en Golang

Le playground contient aussi le packaging d'une application en Golang, consultable dans la branche golang.

Voici le contenu du fichier /golang/rpm/hello-golang.spec :

Name:           hello-golang
Version:        1.0.10
Release:        1%{?dist}
Summary:        A simple Hello World Go application

License:        MIT
URL:            https://github.com/stephane-klein/fedora-rpm-copr-playground
Source0:        %{name}-%{version}.tar.gz

BuildRequires:  golang >= 1.21

%description
A simple "Hello World" Go application packaged as an RPM for Fedora COPR.

%prep
%autosetup

%build
go build -ldflags "-X main.version=%{version}" -o %{name}

%install
mkdir -p %{buildroot}%{_bindir}
cp %{name} %{buildroot}%{_bindir}/

%files
%{_bindir}/%{name}

%changelog
* Fri Mar 20 2026 Stéphane Klein <contact@stephane-klein.info> - 1.0.0-1
- Initial release

Les principales différences avec la version pour Bash :

Absence de BuildArch: noarch
Présence de BuildRequires: golang >= 1.21
Et l'ajout des instructions suivantes :

%prep
%autosetup

%build
go build -ldflags "-X main.version=%{version}" -o %{name}

Peu de changement au niveau du script /build-rpm-locally.sh, qui génère ces fichiers :

rpmbuild
├── BUILD
├── RPMS
│   └── x86_64
│       ├── hello-golang-1.0.10-1.fc42.x86_64.rpm
│       ├── hello-golang-debuginfo-1.0.10-1.fc42.x86_64.rpm
│       └── hello-golang-debugsource-1.0.10-1.fc42.x86_64.rpm
├── SOURCES
│   ├── hello-golang-1.0.10
│   │   ├── go.mod
│   │   └── main.go
│   └── hello-golang-1.0.10.tar.gz
├── SPECS
└── SRPMS
    └── hello-golang-1.0.10-1.fc42.src.rpm

Cette fois, plus rien dans le dossier RPMS/noarch/, la commande rpmbuild --define "_topdir $TOPDIR" -ba rpm/hello-golang.spec build le package pour la distribution de la workstation du développeur.

Pour le reste, je n'ai pas identifié de différence majeure entre la version Bash et la version Golang

La suite… méthode Tito et Packit

Pour être tout à fait transparent, en rédigeant cette note, j'ai découvert les méthodes tito et Packit.

Je compte mettre à jour stephane-klein/fedora-rpm-copr-playground pour les tester et ensuite publier une nouvelle note de compte rendu.

Jusqu'à mi-décembre 2025, cela faisait environ 2 ans que j'arrivais à rester concentré sur un sujet à la fois. J'avais réussi à éviter de papillonner d'un sujet à l'autre. Pour moi, un sujet n'est vraiment terminé que lorsque j'ai publié la note correspondante.

Le dernier sujet que j'avais exploré avec succès était mon étude de Fedora CoreOS.

Je me suis ensuite lancé dans l'étude pratique approfondie de Podman Quadlets. J'ai réussi à publier coreos-quadlet-playground, mais avant même d'avoir commencé à rédiger ma note de synthèse, j'ai perdu ma discipline.

Dans cette note, je vais tenter d'expliquer comment et pourquoi j'ai "dérapé" et faire un bilan des side-projects sur lesquels j'ai papillonné pendant ces deux derniers mois (depuis mi-décembre).

Lors de mon travail sur Podman Quadlets, j'ai découvert comment ce projet utilise avec élégance systemd-run et le mécanisme des generators (systemd-run-generator) de systemd pour incarner la philosophie Unix.

Suite à cette découverte, j'ai repensé aux scripts manuels que j'utilisais ces derniers mois pour lancer mes VM QEMU. Exemple : up-qemu-vm.sh. Je me suis dit qu'il serait élégant de lancer des VM QEMU de la même manière que Podman Quadlets.

Je n'ai pas réussi à résister à cette idée. Le 10 décembre au soir, je me suis dit que j'allais consacrer une petite heure à tester cette idée via du vibe coding avec Aider et Claude Sonnet 4.5.
Cette heure s'est transformée en 12h de session non-stop. J'ai réussi à publier une première version de qemu-compose, mais je venais de rompre ma discipline : je n'avais toujours pas écrit ma note sur Podman Quadlets.

Depuis, je n'ai pas réussi à retrouver ma discipline. Je suis tombé dans une spirale de papillonnage qui a duré deux mois 🙈.

En rédigeant cette note, j'ai essayé de comprendre pourquoi j'avais dérapé.

Je pense que c'était la combinaison de plusieurs facteurs :

Le déclencheur : Ma première expérience réelle de vibe coding sur un projet complet. Cette expérience m'a tellement excité et en même temps tellement perturbé que j'ai perdu la motivation de rédiger ma note sur Podman Quadlets.
La cascade : Une fois le premier écart fait, l'effet "What the hell" s'est enclenché : mon cerveau a rationalisé la continuation du comportement déviant par un "de toute façon, c'est déjà foutu, autant continuer".
Le contexte : J'étais dans une période de stress et de frustration. L'illusion de toute-puissance qu'offrent les derniers modèles 4.5 d'Anthropic — obtenir des résultats rapides — m'a poussé dans une fuite en avant, un échappatoire pour combler mes frustrations du moment.

Depuis 2 ans, j'utilise trois garde-fous (circuit breakers) pour m'empêcher de démarrer un nouveau projet sans avoir terminé le précédent — autrement dit, pour éviter de papillonner et de survoler les sujets :

Je tracke toutes mes activités via Toggl. Quand je démarre une activité, je lance consciemment le chronomètre. Cette friction me force à nommer ce que je fais et à rester conscient du temps que j'y consacre. C'est un premier filtre contre les distractions impulsives.
Tous les matins, je rédige mes todo lists pro et perso dans Obsidian. L'élément clé est une section "Je ne veux pas faire" où je liste explicitement les tâches tentantes mais hors priorité. C'est mon exutoire pour les idées qui me donnent envie sans pour autant y céder.
La publication de notes sur notes.sklein.xyz me force à définir ma "Definition of Done". Une itération (un sujet) n'est terminée que quand la note est publiée.

En analysant mes notes, je constate que j'ai progressivement abandonné la rédaction de mes todo lists quotidiennes à partir du 5 décembre — soit 5 jours avant mon dérapage sur qemu-compose.
Je pense que ce n'est pas un hasard.

#JaiDécidé de reprendre cette routine dès demain. C'est mon garde-fou le plus important.

Voici les sujets en vrac que j'ai survolés pendant ces 2 derniers mois — tous sans note de synthèse publiée :

Réimplémentation complète de ma configuration chezmoi (inachevée)
- Développement de gnome-settings-import-export
Étude de timeshift et snapper
Installation et configuration de netbird sur mes NUC
Tentative d'installation de Kodi sur un de mes NUC (inachevée)
Nouvelle configuration Neovim from scratch basée sur LazyVim (inachevée) : lazyvim-playground
Migration de Fugitive vers Neogit
Développement et publication du plugin neo-tree-session.nvim
Étude puis abandon d'une migration Alacritty + tmux → wezterm (branche WIP)
Étude puis abandon d'une migration Alacritty + tmux → kitty
Étude d'une migration Alacritty → foot + tmux (en cours)
- Contribution au projet foot avec 2 Merge Requests :
  - Spawning new terminal with foot_exe from parent instance
  - Spawning new terminal with --config from parent instance
Test d'avante.nvim, notamment Avante Zen Mode — piste abandonnée
Migration de Aider vers OpenCode
Adoption de Jujutsu à la place de Git — utilisation quotidienne depuis plus d'un mois, progression continue mais pas encore fluide

Bilan : 13 explorations, 2 contributions open source, 1 plugin publié, 0 note de synthèse 😔.

En publiant cette note, je souhaite casser cet effet "What the hell".

Je vais sans doute accepter de ne pas publier de notes sur les sujets que j'ai abandonnés. Par contre, je souhaite à l'avenir publier des notes au sujet de :

[ ] ma migration vers OpenCode
[ ] ma migration vers Jujutsu
[ ] Netbird
[ ] Kodi
[ ] Lazyvim
[ ] Mes contributions à foot
[ ] Des notes au sujet de qemu-compose

Après ma note "Retour XP posts LinkedIn et mes canaux d'acquisition de mission Freelance", voici ma seconde note bilan de ma première année d'activité Freelance.

En 2022, ma dernière année complète en CDI qui me sert de référence, j'ai travaillé 219 jours. Cette année-là, 6 jours fériés sur 10 sont tombés en semaine et j'ai pris en tout 35 jours de congé.

Pour ma première année de Freelance, du 1er juillet 2024 au 30 juin 2025 :

J'ai travaillé l'équivalent de 206 journées complètes :
- J'ai facturé 168 jours de prestation
- À cela s'ajoute 39 journées complètes non facturées. Il s'agit soit de prestations supplémentaires que je n'ai pas facturées, soit du temps consacré à la prospection et aux échanges avec des prospects.
266 jours où j'ai travaillé plus de 30min
288 jours où j'ai travaillé au moins 1min
59 jours de vacances officielles, dont 18 qui sont tombés en weekend, donc j'ai posé l'équivalent de 41 jours de congés. Pendant ces 59 jours, j'ai au moins travaillé 18 jours durant plus de 30 minutes.

Si je fais le bilan, pour ma première année, j'ai travaillé 13 jours de moins que ma dernière année en CDI, pour un chiffre d'affaires qui correspond approximativement à un CDI à 75 K€ brut par an.

Répartition des jours que j'ai facturée de juillet 2024 à fin mai 2025 :

J'ai prévu de publier quelques notes de bilan de ma première année d'activité Freelance. Voici la première, une note d'analyse de mes canaux d'acquisition de missions.

Il y a environ un an, fin septembre 2024, j'ai publié 3 posts sur LinkedIn dans le but de faire connaître ma nouvelle activité Freelance :

Premier message :

Second message :

Troisième message :

Bien que ces messages aient généré 78 réactions, 23 reposts et 7163 impressions cumulées, ils ne m'ont apporté aucune mission directe.

Cependant, j'ai observé qu'ils ont efficacement informé l'ensemble de mon réseau professionnel de ma nouvelle activité.

Malgré cet échec sur ce canal d'acquisition, j'ai tout de même facturé 168 jours de prestation sur une période de 12 mois, du 1er juillet 2024 (jour du dépôt légal de ma micro-entreprise) au 30 juin 2025, en utilisant d'autres approches d'acquisition client.

Voici la répartition de ces 168 jours selon le canal d'acquisition :

Mon réseau direct, des anciens collègues très proches : 3 clients pour un total de 98 jours
Des candidatures spontanées : 2 clients pour un total de 50 jours
Recommandation indirecte d'un client qui n'était pas dans mon cercle de connaissance avant d'avoir travaillé avec lui : 1 client pour un total de 20 jours

Je n'ai reçu aucune proposition de mission sur Malt, pas même un message. Mon taux journalier de 700 € est peut-être trop élevé, ou alors c'est un problème de positionnement de profil. Je dois reconnaitre que je n'ai fait aucun effort à améliorer mon profil Malt depuis ma dernière phase d'optimisation présentée dans cette note du 25 septembre 2024.

Je n'ai répondu à aucune annonce de mission.

J'ai fait seulement deux candidatures spontanées et toutes les deux ont abouti.

Pour la première, j'ai ciblé un service que j'apprécie beaucoup et dont je suis client depuis presque 10 ans. J'avais repéré par leurs posts qu'ils avaient peut-être un budget pour des missions de développement.

Pour la seconde, j'ai visé un collectif que j'avais identifié il y a plus de 10 ans et pour lequel j'avais toujours eu envie de travailler.

Dans les deux cas, mes messages étaient parfaitement sincères, très éloignés des modèles de lettres de motivation qu'on trouve en ligne. J'avais fait mes recherches sur ces organisations et j'ai soigneusement détaillé mes motivations ainsi que les compétences que je pouvais leur apporter.

En repensant à ma stratégie d'acquisition de missions Freelance, je constate qu'elle ressemble étonnamment à ma façon d'obtenir mes CDI durant ma carrière :

J'ai répondu à une annonce d'emploi
J'ai répondu à une annonce d'emploi (Jobboard : Lolix)
Une amie proche m'a contacté pour une mission
Un ami proche m'a contacté pour un emploi
Une amie proche m'a contactée pour un emploi
J'ai ciblé une organisation en contactant une connaissance d'une communauté
J'ai lancé une bouteille à la mer à une connaissance d'une communauté
J'ai eu une proposition autour d'une bière alors que je n'avais rien prévu
J'ai lancé une bouteille à la mer à une connaissance d'une communauté

Voir aussi : Bilan de mon temps de travail de ma première année de Freelance

Dernière page.