ModuleNotFoundError ne prévient jamais avant d'apparaître. Cette ligne rouge coupe l'écran en plein milieu d'un script, et pour qui apprend Python en autodidacte, elle ressemble d'abord à une punition plutôt qu'à une information utile. Pip est censé régler ce genre de blocage : c'est l'outil qui va chercher, dans l'immense catalogue de PyPI, les bibliothèques que Python n'installe pas d'office. Pour une débutante qui n'a jamais ouvert de terminal avant de se mettre à Python, l'installer sans erreur n'a pourtant rien d'évident.
Petite précision avant d'entrer dans le détail : certains liens de cet article sont affiliés, et si vous cliquez puis achetez quelque chose, je touche une petite commission sans que le prix change pour vous. Je ne garde que les outils qui m'ont vraiment servi, comme la formation par laquelle j'ai commencé.
Pip, le livreur qui va chercher ce que Python n'a pas en stock
Installer Python donne l'impression, au début, de recevoir une cuisine déjà entièrement équipée. En réalité, c'est plutôt une cuisine vide avec juste le sel et le poivre sur l'étagère. Pour manipuler un fichier Excel, envoyer un mail automatique ou dessiner un graphique, il faut aller chercher l'outil ailleurs, sur le Python Package Index, le catalogue géant où dorment des centaines de milliers de projets. Pip joue le rôle du livreur : on lui donne un nom, il va chercher le paquet correspondant et l'installe sur la machine. Depuis la version 3.4 de Python, ce livreur est en principe déjà présent sur l'ordinateur, ce qui évite une étape. Le hic, c'est que pip se lance depuis le terminal de l'ordinateur, pas depuis Python lui-même — une nuance qui n'a rien d'intuitif quand on découvre tout ça en même temps.
Pourquoi la commande plante quand on la tape dans Python
Une erreur revient sans cesse chez qui débute : ouvrir Python, attendre les trois chevrons « >>> », puis taper « pip install pandas » droit dedans. Le résultat tombe tout de suite, un SyntaxError sec, sans autre explication. Rien à voir avec une histoire d'indentation qui casse un bloc de code plus loin dans un script — cette erreur-là vient d'ailleurs, du simple fait que pip n'est pas un mot-clé Python. C'est un programme séparé, qui travaille pour Python, mais depuis le terminal de l'ordinateur, pas dans l'interpréteur. La Formation au langage Python que j'ai suivie insiste là-dessus dès les premières leçons, et c'est précisément le genre de détail qui, une fois compris, évite une bonne partie des blocages. Un message d'erreur, aussi sec soit-il, indique presque toujours où chercher, même s'il faut parfois plusieurs lectures pour saisir quoi.
Faut-il installer directement, ou dans un espace séparé ?
La tentation, une fois la première commande réussie, c'est d'installer un peu n'importe quoi, n'importe où — c'est ce que j'ai fait, avant de m'attirer les remarques gentilles d'un ami plus calé que moi en informatique (et qui élève des abeilles sur son balcon à ses heures perdues). Il m'a expliqué que tout installer directement dans l'environnement système finit tôt ou tard par créer un vrai sac de nœuds, et que sur Linux ou macOS, ça peut même abîmer des dépendances dont l'ordinateur a besoin pour démarrer correctement. Avant d'entendre ce conseil, j'avais surtout commis une autre erreur : me lancer directement dans un projet bien trop ambitieux pour mon niveau, sans construire les bases avant. Le genre de soirée où le ventilateur de l'ordinateur se met à ronfler pour de bon dès la deuxième tisane, sans que ça calme grand-chose. Résultat, des bibliothèques installées un peu partout, sans logique, pour un projet que je n'ai jamais terminé. La bonne pratique, c'est de créer un compartiment étanche par projet — j'en parle plus en détail dans mon billet sur comment créer un environnement virtuel python pour mieux organiser ses codes. Installer Python lui-même ne pose pas ce genre de question, c'est une étape à part, réglée une bonne fois avant de commencer ; ce sont les bibliothèques ajoutées ensuite qui demandent cette prudence.
La commande la plus fiable pour ne pas se planter : python -m pip install
Concrètement, la routine qui fonctionne à chaque fois tient en trois gestes : ouvrir le terminal (pas Python), activer l'environnement virtuel du projet, puis taper python -m pip install suivi du nom du paquet. Ce petit -m devant pip force l'ordinateur à utiliser la version de pip liée à la version de Python en cours d'utilisation, ce qui évite pas mal de confusion dès qu'on a plusieurs versions installées. Pour fixer une version précise d'un paquet, il suffit d'ajouter le numéro juste après le nom — une syntaxe que les documents techniques appellent la PEP 508, sans qu'il soit nécessaire d'en retenir le nom pour s'en servir. Avec plus de 500 000 projets disponibles sur PyPI, mieux vaut être précise sur ce qu'on demande. Le nom du paquet correspond presque toujours à ce qu'indique la documentation, et une fois l'import fait, le module devient disponible partout dans le script : dans une boucle, une fonction, une condition, un dictionnaire de résultats ou une simple chaîne de caractères à nettoyer. On peut aussi s'en servir pour trier une liste, lire une réponse tapée au clavier avec input(), ou simplement assigner le résultat à une variable comme n'importe quelle autre valeur. Si les histoires de terminal et de commandes vous perdent complètement, c'est en partie pour cette raison que j'ai fini par choisir une formation python qui prend le temps d'expliquer ce genre de détail avec des mots simples plutôt qu'avec du jargon d'ingénieur.
Repérer une installation réussie
Le signal qui compte, c'est la ligne « Successfully installed » qui termine le petit défilé de texte dans le terminal. À partir de là, le paquet est disponible, l'import fonctionne, et le script peut enfin faire ce qu'on lui demande. Ça reste une sensation curieuse, ce petit sentiment de pouvoir, pour qui ne savait pas ce qu'était une ligne de commande il n'y a pas si longtemps. Ce message ne garantit pas que tout le reste du script va tourner sans accroc, seulement que la bibliothèque, elle, est bien en place.
Que faire si ça coince encore
Si le message d'erreur persiste après tout ça, la cause vient rarement de pip lui-même : mauvais environnement activé, faute de frappe dans le nom du paquet, ou version de Python différente de celle attendue par la bibliothèque. Mes astuces pour déboguer son code python sans perdre patience le soir creusent ce genre de cas plus en détail. Une fois le paquet installé, un bloc try/except autour de l'import évite au moins que tout le script s'arrête net si jamais quelque chose manque encore ailleurs. Pour qui commence tout juste et veut éviter ce genre de crise de nerfs devant un terminal vide, la Formation au langage Python reste le point de départ le plus simple à recommander. Et s'il m'arrive de saturer un peu de Python certains soirs, l'idée de tout recommencer avec JavaScript ne m'a jamais vraiment traversé l'esprit assez sérieusement pour que ça change quoi que ce soit. Je reste fidèle aux serpents. Reste une question que je n'ai toujours pas tranchée : à partir de combien de bibliothèques installées un projet mérite-t-il carrément son propre fichier de dépendances, plutôt qu'une liste de commandes tapées à la volée ?