Illustration apprentissage 2025

This Year I Learned : ce que j’ai appris en 2025

Par le passé, j’ai déjà voulu tenir des séries de TIL (Today I Learned), sans jamais réussir à m’imposer une vraie constance.

Sans doute parce que certains jours, je n’avais rien appris qui méritait d’être publié. Ou plus honnêtement : quand on travaille pour des clients, une partie de ce qu’on découvre, corrige ou construit reste tout simplement sous NDA.

Puis en lisant des newsletters en retard, je suis tombé sur le concept de This Year I Learned.

Et je me suis dit : je fais déjà un bilan financier chaque année, cela semble intéresser du monde… alors pourquoi ne pas faire la même chose sur le volet apprentissage ?

Parce qu’au fond, une année de travail ne se résume pas à du chiffre d’affaires. Elle se résume aussi à ce qu’on devient.

Prendre du temps pour autre chose

C’est probablement l’apprentissage le plus important de l’année.

Depuis deux ans, je bossais presque tous les soirs. En journée, travail classique. En soirée, projets. Souvent le week-end aussi.

Même en prenant deux mois de congé, cela restait un rythme où je travaillais quasiment en continu.

Petit à petit, certaines choses ont commencé à passer après le reste :

moments en couple
moments avec les amis
temps avec les enfants
sport
repos mental

Fin d’année, après un bootcamp avec d’autres développeurs et freelances, j’ai changé d’approche.

Je me suis accordé du temps pour moi.

Et paradoxalement, cela m’a rendu plus efficace, plus lucide et plus productif.

Quand on est artisan, on entretient ses outils.

En freelance, je suis mon propre outil.

Comprendre la valeur de la data avec PostHog

Je n’ai jamais été très orienté analytics.

Pendant longtemps, je regardais parfois le trafic serveur par hasard, plus que par intérêt réel.

Puis en reprenant un projet, j’ai découvert PostHog.

Et je me suis dit que j’étais peut-être passé à côté de quelque chose.

Les données d’usage ne servent pas seulement à flatter l’ego ou compter les clics.

Elles servent à comprendre :

où les utilisateurs bloquent
ce qu’ils utilisent vraiment
ce qu’ils ignorent
ce qui mérite d’être amélioré

Cela reste secondaire dans mon approche, mais j’ai compris l’intérêt.

VPS : monter en autonomie

J’avais envie de lancer des pages statiques ou de petites apps sans devoir dépendre systématiquement d’un écosystème front / back séparé avec mille réglages.

Du coup, j’ai décidé d’apprendre à utiliser un VPS.

Au début :

un seul projet
configuration manuelle
beaucoup de tests
quelques erreurs

Puis progressivement :

plusieurs projets sur la même machine
reverse proxy
meilleures habitudes
compréhension plus large de l’infra

Je suis loin d’être expert, mais mon scope s’est élargi.

Docker : arrêter le “ça marche chez moi”

J’avais déjà essayé Docker auparavant, sans aller très loin.

En 2025, j’ai changé d’approche : j’ai décidé de containeriser mes projets, même les plus simples.

Pourquoi ?

Parce que les bugs impossibles à reproduire en production coûtent du temps, de l’énergie et parfois de la crédibilité.

Docker m’a apporté :

un environnement stable
un setup réplicable
des collaborations plus simples
moins de surprises entre local et prod

Le fameux works on my machine mérite de disparaître.

Coolify : gagner du temps au déploiement

En cherchant une solution plus simple pour déployer mes apps, je suis tombé sur Coolify.

Et honnêtement : excellent move.

Aujourd’hui, entre Docker + Coolify :

je configure une fois
je déploie vite
je centralise plusieurs projets
je perds moins de temps sur l’opérationnel

Cela m’a permis de rester concentré sur ce qui crée réellement de la valeur.

Electron : sortir du web

J’ai eu une idée d’application macOS pour me simplifier la vie.

Du coup, j’ai mis les mains dans Electron.

Je suis loin d’une maîtrise parfaite, mais j’ai découvert :

packaging d’applications
signature logicielle
compilation multi-OS
distribution desktop

Cela m’a rappelé une chose importante :

Je ne suis pas limité aux web apps.

Avec du temps, on peut rapidement apprendre de nouveaux terrains de jeu.

Travailler en binôme

Jusqu’ici, j’étais surtout solo sur mes projets.

Cette année, j’ai collaboré avec d’autres développeurs.

J’ai pu :

faire des PR sur leurs projets
co-construire des micro-SaaS
reprendre des produits existants
échanger sur les pratiques

Cela fait progresser vite.

Coder seul développe l’autonomie.

Coder à plusieurs développe la maturité.

Racheter un SaaS existant

Cet été, avec deux potes dev, j’ai participé au rachat d’un SaaS.

J’y ai appris :

comment se passent les discussions
quels points vérifier
comment valoriser un produit
comment structurer un deal

Mais surtout :

Reprendre un SaaS existant, ce n’est pas juste acheter des revenus.

C’est aussi reprendre :

une codebase
des choix passés
des habitudes techniques
des utilisateurs existants
des responsabilités réelles

Approche très différente d’un projet perso lancé dans son coin.

Créer son propre SaaS

J’ai aussi eu la chance de développer mon propre SaaS.

J’y ai découvert :

les petits bugs invisibles en local
les mises en production stressantes
les arbitrages produit
les attentes utilisateurs
la réalité business derrière la technique

On parle souvent du SaaS comme d’un revenu passif.

Soyons honnêtes :

Il n’y a que les notifications Stripe qui sont passives.

Casser ma production

Probablement une quinzaine de fois sur l’année.

Pour des raisons variées.

Le mieux serait évidemment :

staging propre
pipeline solide
zéro incident

Mais dans la vraie vie :

J’ai push en prod.
J’ai cassé la prod.
J’ai réparé la prod.

Et à chaque fois, j’ai essayé d’en tirer quelque chose :

pourquoi c’est arrivé ?
comment l’éviter ?
quel process manque ?
quelle sécurité ajouter ?

L’échec n’enseigne rien si on ne l’analyse pas.

IA : mieux l’intégrer

Je n’ai pas découvert l’IA en 2025.

Par contre, j’ai découvert de nouvelles manières de l’utiliser.

J’ai testé :

méthodes de prompting
workflows hybrides
assistance au debug
idéation produit
rédaction
refactoring

Avec des succès… et des échecs.

Je vois cela comme un outil, au même titre qu’un IDE.

À chacun ensuite d’en faire l’usage qu’il veut.

Ne plus dépendre d’un seul outil

Cette année, j’ai aussi voulu me détacher d’un IDE unique ou d’une seule manière de travailler.

J’avais envie de pouvoir changer d’éditeur rapidement, tester de nouveaux outils, rester léger.

J’ai donc cherché à simplifier mes méthodes :

configs plus sobres
environnement plus portable
moins de dépendances
plus de flexibilité

Quand l’écosystème bouge vite, rester figé coûte cher.

Et le reste

J’ai aussi appris, en vrac :

review de projets
analyses techniques
donner des conseils
contribuer à des communautés
rencontrer d’autres développeurs
créer de vraies amitiés
découvrir d’autres cultures tech

Tout cela compte autant que les lignes de code.

Bilan

Je n’ai pas pris la peine de noter chaque jour ce que j’apprenais.

Mais je sais une chose :

En 2026, j’aborde le développement d’une manière plus mature qu’en entrant en 2025.

Et pour l’année en cours ?

Je pense faire cet exercice mensuellement ou tous les deux mois.

Cela me semble beaucoup plus réaliste que du quotidien.

Parfois, progresser ce n’est pas en faire plus.

C’est trouver un rythme qu’on peut réellement tenir.

dkp