Quels livres pour apprendre à programmer ? 3 titres, dans l'ordre, pour un débutant complet

Quels livres pour apprendre à programmer ?

Ouvrez le rayon informatique d'une grande librairie et regardez les dates. Un tiers des ouvrages exposés parlent d'une version de logiciel qui n'existe plus. Un autre tiers explique un framework dont l'écosystème a changé deux fois depuis l'impression. C'est la particularité vicieuse de ce domaine : un livre technique daté ne vous laisse pas simplement dans l'ignorance, il vous enseigne activement des choses fausses, et vous perdez ensuite des heures à comprendre pourquoi le code du chapitre 4 ne compile pas.

D'où une règle simple, qui commande toute cette sélection. Achetez peu de livres, et achetez ceux qui parlent de raisonnement plutôt que de syntaxe. Trois suffisent pour un débutant complet, et je vais vous expliquer pourquoi il n'y en a pas un quatrième.

Le vrai problème n'est pas le langage, mais vous n'y croirez pas tout de suite

Tout débutant commence par la mauvaise question : quel langage apprendre. La réponse honnête, c'est que ça n'a pas beaucoup d'importance, et que la question sert surtout à repousser le moment où il faudra écrire une première ligne.

Prenez Python. La syntaxe se lit presque comme de l'anglais, l'installation ne demande pas de configurer un environnement de compilation, les messages d'erreur sont compréhensibles par un humain. Vous écrirez un programme qui fait quelque chose d'utile dans votre première semaine, et c'est le seul critère qui compte au départ. JavaScript est un choix défendable si le web vous attire, C est un excellent deuxième langage et un très mauvais premier, Java vous fera écrire vingt lignes pour afficher une phrase.

Ce que vous apprenez avec le premier langage se transfère à peu près intégralement au deuxième. Les boucles, les conditions, les fonctions, les tableaux, la décomposition d'un problème en sous-problèmes : c'est ça, programmer. La syntaxe est l'accent, pas la langue.

Premier livre : Gérard Swinnen, « Apprendre à programmer avec Python 3 »

Gérard Swinnen, « Apprendre à programmer avec Python 3 » (Eyrolles, 3e édition, 2012, avec soixante pages d'exercices corrigés) Voir à la FnacApprendre à programmer avec Python 3, de Gérard Swinnen (lien affilié, ouvre un nouvel onglet). Aucun prérequis, aucune connaissance en mathématiques au-delà du collège.

Swinnen était professeur de sciences dans l'enseignement secondaire belge, et il a écrit ce livre pour ses élèves avant de le publier. Cela se sent partout : il explique lentement, il anticipe les confusions, il ne suppose jamais que vous connaissez déjà le vocabulaire qu'il emploie. L'ouvrage a longtemps circulé librement en PDF avant d'être repris par Eyrolles, et il a servi de premier contact avec la programmation à plusieurs générations d'étudiants francophones.

Ce qu'il vous apprend précisément : les variables, les boucles, les conditions, les fonctions, les listes et les dictionnaires, puis les objets, avec un exercice à faire toutes les quelques pages. Le livre est construit pour que vous tapiez du code, pas pour que vous le lisiez au lit.

Ce qu'il ne vous apprend pas, et il faut le dire franchement : rien de ce qui touche à l'écosystème Python actuel. Les chapitres sur les interfaces graphiques avec tkinter, sur la programmation web et sur les bases de données ont vieilli, parfois durement. Les outils modernes qu'un développeur Python utilise tous les jours n'y sont pas, pour la bonne raison qu'ils n'existaient pas.

C'est un défaut assumé, et voici pourquoi je le maintiens en première position. Le socle du langage, celui qui occupe les deux tiers du livre, n'a pas bougé d'un pouce depuis 2012. Une boucle for s'écrit exactement pareil. Ce premier livre est le plus périssable des trois, et c'est normal : c'est aussi celui dont vous vous débarrasserez le plus vite. Vous le lirez en six semaines et vous ne le rouvrirez jamais. Si vous préférez malgré tout quelque chose de récent, prenez n'importe quel manuel Python d'un éditeur technique sérieux publié depuis moins de trois ans, l'important est ailleurs.

Deuxième livre : Aditya Bhargava, « Les algorithmes, c'est plus simple avec un dessin ! »

Aditya Bhargava, « Les algorithmes, c'est plus simple avec un dessin ! » (De Boeck Supérieur, 2023, traduit de l'anglais par Bernard Desgraupes) Voir à la FnacLes algorithmes, c'est plus simple avec un dessin !, de Aditya Bhargava (lien affilié, ouvre un nouvel onglet). Prérequis : deux ou trois mois de code derrière vous, et au moins un programme qui vous a paru anormalement lent.

Bhargava est développeur, et il a eu l'idée de raconter les algorithmes classiques avec des dessins faits à la main plutôt qu'avec des démonstrations. Le résultat évite les deux pièges habituels du genre : ce n'est ni un traité universitaire couvert de notations, ni un livre de recettes qui vous fait recopier du code sans comprendre.

Ce qu'il vous apprend précisément : la recherche dichotomique, les tris, les listes chaînées et les tableaux, les tables de hachage, les graphes et le parcours en largeur, la programmation dynamique. Surtout, il vous apprend à évaluer le coût d'une solution avant de l'écrire, ce qui est la vraie bascule entre quelqu'un qui bricole et quelqu'un qui programme.

Ce qu'il ne vous apprend pas : la rigueur mathématique. Les preuves sont esquissées ou absentes. Si vous préparez un concours ou une thèse, il vous faudra autre chose. Pour tous les autres, c'est exactement le bon niveau de détail.

Une remarque sur l'ordre, qui compte beaucoup ici. Ne lisez pas ce livre en premier. Un algorithme est une réponse, et une réponse ne veut rien dire tant qu'on n'a pas rencontré la question. Attendez d'avoir écrit un programme qui met dix secondes là où il devrait en mettre une, et le chapitre sur la complexité vous éclairera d'un coup.

Troisième livre : Andrew Hunt et David Thomas, « Le Programmeur pragmatique »

Andrew Hunt et David Thomas, « Le Programmeur pragmatique : comment devenir pro » (Pearson France, 2024, 448 pages, traduit de l'anglais par Fiona Sourisseau) Voir à la FnacLe Programmeur pragmatique : comment devenir pro, de Andrew Hunt et David Thomas (lien affilié, ouvre un nouvel onglet). Prérequis : six mois à un an de pratique, et de préférence un projet personnel qui commence à devenir difficile à modifier.

La première édition américaine date de 1999. Le livre a été entièrement revu pour son vingtième anniversaire, et l'édition française de 2024 correspond à cette version remaniée. Un ouvrage technique qui reste pertinent vingt-cinq ans après sa sortie, dans un domaine où trois ans suffisent à périmer un manuel, mérite qu'on s'arrête sur la raison de cette longévité : il ne parle d'aucun langage en particulier.

Ce qu'il vous apprend précisément : à ne pas dupliquer une information dans deux endroits du code, à découpler ce qui n'a pas de raison d'être lié, à automatiser ce que vous refaites à la main, à écrire des programmes que vous serez encore capable de comprendre dans six mois. Le tout par petits chapitres autonomes, avec des anecdotes et des analogies, ce qui rend la lecture nettement plus agréable que la moyenne du rayon.

Ce qu'il ne vous apprend pas : à écrire votre premier programme. Le livre suppose que vous avez déjà souffert. Lu trop tôt, il paraît sentencieux. Lu au bon moment, c'est-à-dire quand vous venez de casser votre propre code en voulant l'améliorer, il donne l'impression que quelqu'un met enfin des mots sur ce que vous vivez.

Par où ne pas commencer

Voici la partie qui vous fera gagner le plus de temps et le plus d'argent.

Tout titre contenant un numéro de version ou un nom de framework. React, Django, Angular, Symfony, Node : ces livres sont écrits par des gens compétents et ils sont morts en dix-huit mois. La documentation officielle est plus à jour, gratuite, et meilleure. Achetez un livre sur un framework uniquement si vous travaillez dessus tous les jours et que vous voulez une vision d'ensemble, jamais pour apprendre à programmer.

« The Art of Computer Programming » de Donald Knuth. Ce sont des volumes magnifiques, l'un des monuments de la discipline, et à peu près personne ne les lit d'un bout à l'autre, y compris parmi les professionnels. Le code y est écrit en assembleur pour une machine fictive. Ce n'est pas un livre d'apprentissage, c'est une référence pour chercheurs.

Toute la famille des « Apprenez X en 24 heures » ou « en 21 jours ». Le format même contient le mensonge. Ces livres vous font recopier du code sans jamais vous laisser vous tromper, ce qui supprime précisément l'opération par laquelle on apprend.

« Coder proprement » de Robert C. Martin, et je sais que ce conseil va faire grincer. Le livre est très recommandé, il contient de bonnes choses, mais plusieurs de ses principes font aujourd'hui l'objet d'un débat sérieux dans la profession, notamment sa manière de découper les fonctions en très petits morceaux. Un débutant n'a pas les moyens de trier. Lisez-le dans deux ans, quand vous pourrez être en désaccord avec lui.

Enfin, un piège de format plutôt qu'un titre : les gros manuels de mille pages qui couvrent un langage exhaustivement. Ils ne se lisent pas, ils se consultent. Acheter une encyclopédie pour apprendre donne la sensation rassurante d'avoir investi, et cette sensation remplace souvent la pratique.

Ce qu'aucun livre ne fera à votre place

Il faut le dire sans détour : on n'apprend pas à programmer en lisant. On apprend à programmer en programmant, et la lecture sert uniquement à rendre cette pratique moins aveugle.

Un livre ne verra jamais votre erreur. Il ne saura pas que vous avez confondu l'affectation et la comparaison à la ligne 12, et que c'est pour ça que votre boucle tourne indéfiniment. Cette compétence-là, débusquer un bug dans son propre code, ne s'acquiert que par la répétition de l'agacement. Les gens qui savent programmer sont surtout des gens qui ont passé énormément de temps à réparer ce qu'ils venaient de casser.

Un livre ne vous donnera pas non plus de projet. C'est le manque le plus grave, parce que c'est le projet qui fournit la motivation quand le chapitre 9 devient aride. Prenez quelque chose de minuscule et d'égoïste : un script qui renomme vos photos, un programme qui suit vos dépenses, un petit jeu en texte. La règle est que ça vous serve à vous, personnellement, sinon vous abandonnerez au premier obstacle.

Un livre ne remplacera pas non plus le fait de lire du code écrit par d'autres. C'est l'exercice le plus négligé et l'un des plus rentables. Ouvrez un petit projet libre sur une plateforme de dépôts, choisissez un fichier, essayez de comprendre ce qu'il fait. Vous apprendrez en une soirée des tournures que personne n'enseigne.

Enfin, personne ne vous dira quand vous êtes prêt à passer au livre suivant. Le signe est toujours le même : vous rencontrez un problème que votre livre actuel ne traite pas. C'est le moment, pas avant.

Après ces trois livres

Vous aurez alors les bases d'un langage, une intuition du coût des solutions et une méthode de travail. C'est une fondation qui ne périme pas, et c'est précisément pour ça qu'elle tient en trois titres.

La suite dépend de la direction que vous prenez, et elle passera beaucoup moins par des livres que par de la documentation, des projets et des gens. Si vous voulez comprendre ce qui se passe sous votre code, la mémoire, le processeur, le réseau, la culture générale technique se construit avec d'autres ouvrages : voyez quels livres pour apprendre l'informatique, qui traite précisément de cette couche et ne reprend aucun des titres ci-dessus.

Et si vous prenez goût à cette manière d'apprendre par un parcours court plutôt que par une pile de livres, le reste de la collection quels livres acheter pour apprendre à applique la même méthode à d'autres domaines. Vous pouvez aussi parcourir le catalogue par genre pour repérer ce qui se publie autour de la technique et des sciences.

Les liens « Voir à la Fnac » sont affiliés : un achat nous verse une petite commission, sans changement de prix pour vous. Les livres sont choisis indépendamment.