Décembre 2023. Un soir, je code un truc en quelques heures : un compte à rebours pour mon premier marathon. Rien de plus. Un post-it numérique, quoi.

Des amis voient ça, ils veulent l’utiliser aussi. Je leur ouvre l’accès. Pas de plan, pas d’étude de marché, juste “ouais pourquoi pas”.

Deux ans passent. countdowns.fr tourne, tant bien que mal. Je répare quand ça casse, je pousse des trucs à l’arrache. Pas de vrais tests fiables, des pipelines qui cassent une fois sur deux, zéro environnement de test. Chaque déploiement, les doigts croisés.

Avril 2026. J’en ai marre de croiser les doigts.

La vraie question n’était pas “comment améliorer countdowns.fr”. C’était : comment arrêter de passer mon temps à éteindre des feux sur un truc que je gère seul, le soir, sur mon temps libre ?

Alors j’ai décidé d’en faire mon terrain de jeu. Pas pour vendre countdowns.fr. Pour m’obliger, sur un projet réel avec de vrais utilisateurs, à construire les réflexes d’automatisation que j’avais toujours remis à plus tard.

Ce que j’ai construit

D’abord, j’ai arrêté de faire l’autruche. Un audit des dépendances : 5 vulnérabilités critiques, dont une faille SSRF planquée dans axios. Sympa. J’ai remis à plat la suite de tests au passage : 218 tests bancals sont devenus plus de 1000 tests qui testent, pour de vrai, à chaque fois. Le pipeline GitLab CI qui plantait un coup sur deux, je l’ai enfin stabilisé : vérification, build, publication, à chaque push, sans croiser les doigts. Fini le “ça devrait marcher”.

Ensuite, j’ai automatisé le truc qui me bouffait mes soirées. Chaque mois, je mettais à jour la liste des événements sportifs à la main. Plus de 20 heures par mois, perdues. Maintenant, un script va chercher les nouveaux événements tout seul (API et scraping), déduplique, couvre 85 zones en France, et prévient les utilisateurs par email avec une sélection d’événements. Mes soirées et mes week-ends, je les récupère.

Puis je me suis donné un filet. Un environnement de qualification sur un Raspberry Pi, chez moi, qui reproduit la prod avant chaque déploiement. Ça change tout : je casse des trucs chez moi, pas chez les utilisateurs.

Et là, un bug est venu me rappeler que j’avais encore du chemin. Début juillet, un endpoint de synchronisation s’est mis à planter en silence : quand il échouait, l’hébergeur renvoyait sa propre page de maintenance à la place, avec un code 200, “tout va bien”, au lieu d’une vraie erreur. Mes vérifications ne voyaient rien. La fonctionnalité était cassée depuis des jours, et c’est un utilisateur qui me l’a signalé. Pas moi. J’ai corrigé, viré ce cache trompeur. Mais la leçon reste : un “ça marche” silencieux, c’est parfois le pire des mensonges.

Ce que ça m’apprend

Techniquement, j’engrange des patterns réutilisables : pipeline CI/CD, synchronisation fiable de données externes, environnement de qualification qui tient sur un Raspberry Pi.

Mais le vrai truc, il n’est pas là. countdowns.fr, le produit, je m’en fiche un peu. Ce qui compte, c’est d’arriver à garder un système en bonne santé sans y penser H24. Passer du mode pompier au mode “le système gueule tout seul quand ça déconne”.

Rien n’est fini. La supervision reste basique, je n’ai toujours pas écrit la doc des patterns réutilisables, et je découvre encore des trous, comme ce 200 qui mentait. Normal : c’est un labo, pas une vitrine.

Et maintenant

countdowns.fr tourne toujours, en ligne, code public sur GitLab . Allez fouiller si ça vous amuse. Et si vous trouvez un autre angle mort, dites-le-moi avant qu’un utilisateur ne s’en charge.