Les livres de prog n'apprennent pas à programmer

date: Nov 17 2025 4 min de lecture

Lire des livres sur Kubernetes ne fait pas de toi un ingénieur Kubernetes. Arrête de lire, ouvre un terminal et casse tout jusqu'à apprendre.

.learning.devex.opinion

J’ai vu un thread Twitter hier. Quelqu’un postait sa pile de bouquins O’Reilly — ‘Learning Python’, ‘Kubernetes: Up and Running’, ‘Designing Data-Intensive Applications’. Des centaines de commentaires pour les féliciter.

Personne demande s’ils ont écrit du Python. Personne demande s’ils ont déployé un pod. Juste des applaudissements pour avoir acheté des livres.

Pile de livres de programmation applaudie sur Twitter

On apprend pas en lisant

Les livres restent sur l’étagère. Le code tourne en prod.

J’ai interviewé des dizaines d’ingénieurs qui ‘ont lu le livre sur Kubernetes’. Quand je leur demande d’écrire un deployment, ils bloquent. Ils connaissent la théorie. Ils ne savent pas écrire le YAML

On n’apprend pas à programmer en lisant. On apprend en cassant des trucs, en les réparant, et en comprenant pourquoi ça a cassé

Le spectacle que tout le monde joue

Poster sa collection de livres c’est la version tech de ‘je travaille sur moi’. Ça fait productif. Ça signale l’expertise. Mais le signal n’est pas la compétence

Le vrai apprentissage ressemble à ça:

  • Des projets à moitié finis sur ton GitHub
  • Des messages d’erreur que tu as mémorisés
  • Cet incident prod auquel tu penses encore
  • Des questions Stack Overflow auxquelles tu as vraiment répondu

Les livres ne te donnent pas ça. Casser et réparer des systèmes, oui

Les livres enseignent les mauvaises choses

La plupart des livres de prog couvrent des fondamentaux que ChatGPT explique mieux en 10 secondes. Le reste c’est de la théorie que tu n’utiliseras jamais

Ce dont tu as besoin:

  • Comment l’authentification marche vraiment dans ta stack
  • Pourquoi ton container est out of memory
  • Comment débugger ce problème réseau

Ce que les livres te donnent:

  • Des design patterns de 1995
  • Des exemples jouets qui compilent mais ne résolvent rien
  • Une couverture exhaustive de features que tu ne toucheras jamais

Les livres optimisent pour la complétude. Les vrais projets ont besoin de profondeur dans des domaines étroits

Pratiquer bat consommer passivement

Lire c’est passif. Tu penses comprendre jusqu’à ce que tu essaies de l’implémenter.

Je pensais connaître Docker après avoir lu les docs. Puis j’ai passé une semaine à débugger pourquoi mon image faisait 2GB. Le livre mentionnait les multi-stage builds. Il n’expliquait pas quand ton cache casse ou pourquoi l’ordre des layers compte

J’ai appris Docker en:

  • Construisant 50 images cassées
  • Lisant les messages d’erreur
  • Checkant ce que les autres projets faisaient vraiment
  • Fixant ce qui cassait en CI

Pas en lisant 400 pages de théorie sur les containers

Certains livres marchent

Les docs de référence marchent. ‘Voici l’API, voici des exemples’ marche. C’est un outil, pas un manuel scolaire

Les bouquins techniques profonds marchent quand tu connais déjà les bases. Tu ne peux pas apprécier ‘Designing Data-Intensive Applications’ avant d’avoir construit quelques applications data-intensive

Les livres d’architecture marchent si tu as ressenti la douleur qu’ils résolvent. Sinon c’est juste des patterns que tu cargo-cult dans ton code

Ce qui marche vraiment

Construis quelque chose. Choisis un projet. Fais-le marcher. Rends-le meilleur. Déploie-le. Casse-le. Répare-le.

Lis du code. Pas des livres sur le code. Du vrai code de prod. Regarde quels patterns les vrais ingénieurs utilisent. Regarde ce qu’ils évitent.

Regarde les gens travailler. YouTube a des milliers d’heures d’ingénieurs qui construisent des vrais systèmes. Regarde-les débugger. Regarde-les refactorer. Vois leur processus de pensée.

Fixe de vrais problèmes. Contribuer à l’open source enseigne plus que n’importe quel livre. Tu deals avec de vraies contraintes, de vraies reviews, de vrais users.

Le problème du collectionneur de livres

Je connais des ingénieurs avec des étagères pleines de livres de prog. Aucun d’eux n’est senior engineer

Les seniors que je connais:

  • Ont 3-4 livres de référence qu’ils ont vraiment utilisés
  • Suivent la documentation, pas des manuels
  • Apprennent en construisant et cassant
  • Lisent le code source quand ils sont perdus

Les livres c’est du comfort food. Ils te font sentir que tu apprends. Mais l’apprentissage se passe dans le terminal, pas sur l’étagère

Commence maintenant

Ferme cet article. Ouvre ton éditeur. Choisis un truc que tu ne connais pas. Code-le comme tu peux. Fais-le marcher. Casse-le exprès. Répare-le

C’est comme ça qu’on apprend

Les livres c’est pour avoir l’air smart sur Twitter. Le code c’est pour faire avancer les choses

Vous avez aimé cet article ? Partagez-le !

Sofiane Djerbi
Sofiane Djerbi

Architecte Cloud & Kubernetes, Expert FinOps.

Commentaires