Le code, le terminal, les fichiers : la trouille en 20 minutes

La fenêtre noire

La première fois que j'ai vu un développeur ouvrir son terminal, j'ai eu le même réflexe que tout le monde : ne touche à rien.

Fenêtre noire. Texte blanc. Curseur qui clignote. Aucun bouton, aucune icône, aucun indice visuel sur ce qu'on est censé faire. L'impression que si on appuie sur la mauvaise touche, quelque chose d'irréversible se produit. Un fichier système effacé. Un disque dur formaté. Une catastrophe silencieuse.

Cette peur, je l'ai gardée longtemps. Même en construisant des outils no-code depuis vingt ans, même en connectant des APIs, même en automatisant des process entiers avec Zapier, je contournais le terminal comme on contourne une flaque. Il était là, dans un coin de mon Mac, et je faisais semblant de ne pas le voir.

Ce qui m'a débloquée, ce n'est pas un cours. C'est une phrase entendue par hasard, dans une conversation entre deux devs : "attends, je vais juste aller dans le dossier". Et l'un d'eux a ouvert le terminal, tapé quatre lettres, et navigué dans ses fichiers exactement comme je le fais dans le Finder.

C'est tout. Il est allé dans un dossier.

La fenêtre noire ne fait pas autre chose que ça.

Un projet de code, c'est un dossier

Quand Lovable génère un projet pour moi, ou quand Claude Code crée des fichiers, voilà ce qui se passe concrètement : un dossier apparaît sur un ordinateur quelque part. Dans ce dossier, il y a d'autres dossiers. Et dans ces dossiers, des fichiers.

C'est ça, un projet de développement. Un dossier, avec des fichiers dedans. Rien d'autre.

J'ai mis du temps à le réaliser parce que personne ne le dit jamais explicitement. On parle de "codebase", de "repository", d'"architecture". Des mots qui sonnent comme des structures complexes, des édifices techniques inaccessibles. La réalité est beaucoup plus décevante.

Si tu ouvres le projet Pimpela sur mon ordinateur, tu trouves un dossier qui s'appelle pimpela. Dedans, un dossier src, un dossier public, quelques fichiers à la racine. C'est la même logique que le dossier Comptabilité 2024 sur ton bureau, avec ses sous-dossiers Factures, Relevés, Déclarations.

Les fichiers .txt, .py, .html : du texte, rien que du texte

Maintenant, les extensions. C'est souvent là que la peur s'installe.

Un fichier .py, un fichier .html, un fichier .js : ça ressemble à des formats exotiques, des formats qui nécessiteraient des logiciels spéciaux, une formation, un accès quelconque. La vérité : ce sont des fichiers texte. Exactement comme un .txt.

Si tu prends un fichier app.py et que tu l'ouvres avec le Bloc-notes ou TextEdit, tu vois du texte. Des phrases en anglais, quelques symboles, des indentations. Rien de binaire, rien de crypté, rien d'illisible. Du texte que quelqu'un a écrit, lettre par lettre.

J'ai testé ça il y a quelques mois, par curiosité, sur un des fichiers générés par Claude Code pour Ask Aurelia. J'ai fait "ouvrir avec TextEdit". Et là, j'ai lu. Pas tout compris, évidemment. Mais j'ai lu. C'était du texte.

Pourquoi des extensions différentes ?

L'extension ne change pas la nature du fichier. Elle indique juste quel programme est censé l'interpréter.

.docx dit à Word : c'est pour toi. .pdf dit à Acrobat : c'est pour toi. .py dit à Python : c'est pour toi. .html dit au navigateur : c'est pour toi.

Le fichier lui-même reste du texte. C'est le programme qui le lit qui lui donne un comportement. Un fichier .py contient des instructions écrites en langage Python. Quand Python le lit, il exécute ces instructions. Quand TextEdit le lit, il affiche juste le texte brut, sans rien exécuter.

C'est pour ça qu'on ne "double-clique" pas sur un fichier .py pour le lancer comme on double-clique sur un .docx. Il faut demander explicitement à Python de le lire. Et c'est là qu'intervient le terminal.

Le terminal : l'explorateur de fichiers en mode texte

Le Finder sur Mac, l'Explorateur sur Windows : ce sont des interfaces visuelles pour naviguer dans des dossiers et voir des fichiers. On clique sur un dossier, il s'ouvre. On clique sur un autre, on descend d'un niveau. On fait glisser un fichier, il se déplace.

Le terminal fait exactement la même chose. Sauf qu'au lieu de cliquer, on tape.

C'est vraiment tout. Il n'y a pas de couche supplémentaire de complexité. Il n'y a pas de dimension cachée. C'est une interface textuelle pour faire ce que le Finder fait en visuel. Les développeurs l'utilisent parce que c'est plus rapide pour certaines opérations, parce que certains outils ne fonctionnent qu'en ligne de commande, et parce que ça donne l'impression d'être dans Matrix. Surtout la troisième raison, je pense.

Ce que fait cd

cd veut dire "change directory". Changer de répertoire. Ouvrir un dossier.

Quand tu tapes cd Documents, tu fais exactement ce que tu fais quand tu double-cliques sur le dossier Documents dans le Finder. Tu te déplaces dedans. Le terminal te dit maintenant que tu es dans Documents, et toutes les commandes suivantes s'exécuteront depuis cet endroit.

<Hi>cd .</Hi>. remonte d'un niveau. Comme cliquer sur la flèche "retour" dans le Finder.

C'est tout. Deux lettres, un espace, un nom de dossier. C'est la commande que j'utilise le plus souvent quand je travaille avec Claude Code, et c'est probablement la commande que tu utiliseras le plus toi aussi.

Ce que fait ls (ou dir sur Windows)

ls veut dire "list". Lister le contenu du dossier où tu te trouves.

C'est l'équivalent de regarder ce qu'il y a dans un dossier ouvert dans le Finder. Sauf qu'au lieu d'icônes, tu vois une liste de noms. Les dossiers, les fichiers, leurs noms, parfois leurs tailles.

Sur Windows, la commande équivalente s'appelle dir. Même logique, syntaxe légèrement différente.

Ces deux commandes, cd et ls, couvrent 80% de ce dont tu as besoin pour ne plus être perdue quand un tutoriel dit "ouvre ton terminal". Le reste, tu l'apprendras si tu en as besoin, au moment où tu en as besoin.

Essaie maintenant, ça prend trois minutes

Pas besoin de comprendre plus avant de toucher. La meilleure façon de dédramatiser, c'est de faire.

Ce que tu vas faire : ouvrir le terminal, aller dans ton dossier Documents, voir la liste de tes fichiers. C'est tout. Rien ne peut mal tourner. cd et ls ne modifient rien, ne suppriment rien, ne déplacent rien. Ce sont des commandes de lecture pure.

Sur Mac

Ouvre le Finder. Va dans Applications, puis dans le dossier Utilitaires. Double-clique sur "Terminal".

Alternative plus rapide : appuie sur Cmd + Espace, tape "Terminal", appuie sur Entrée.

Une fenêtre noire (ou blanche selon tes réglages) s'ouvre. Tu vois un curseur qui clignote. Le terminal t'indique où tu te trouves, généralement ton dossier personnel.

Tape exactement ceci, puis appuie sur Entrée :

Puis tape :

Tu vois apparaître la liste de tes fichiers et dossiers dans Documents. Tes propres fichiers. Ceux que tu connais.

C'est ça, le terminal.

Sur Windows

Appuie sur la touche Windows, tape "PowerShell", appuie sur Entrée. (Tu peux aussi chercher "cmd" si PowerShell ne s'ouvre pas.)

Une fenêtre s'ouvre, fond bleu ou noir selon la version. Tape :

Puis :

Même résultat : la liste de ce qui est dans ton dossier Documents.

Si tu vois tes fichiers apparaître, tu viens de naviguer dans tes dossiers en ligne de commande. Tu as fait exactement ce qu'un développeur fait des dizaines de fois par jour. Sans formation, sans cours, sans rien d'autre que trois minutes et deux commandes.

GitHub : le dossier partagé avec mémoire

Quand on commence à s'intéresser au développement, GitHub revient tout le temps. Les tutoriels y renvoient, les développeurs en parlent, Claude Code propose de "pusher sur GitHub". Le mot fait partie du paysage, et si on ne sait pas ce que c'est, il contribue à l'impression d'être à l'extérieur d'un club.

GitHub, c'est un endroit sur internet où on stocke des dossiers de code.

Mais avec une particularité : il se souvient de chaque modification apportée à chaque fichier, depuis le début. Si tu modifies un fichier aujourd'hui, puis dans trois semaines, puis dans deux mois, GitHub garde les trois versions. Tu peux revenir en arrière à n'importe quel moment. Tu peux voir exactement ce qui a changé entre deux versions, ligne par ligne.

C'est comme un Google Drive qui aurait un historique complet et granulaire de toutes les modifications, sur tous les fichiers, pour toujours.

Pour Pimpela, j'utilise GitHub pour exactement cette raison : quand Claude Code modifie des fichiers et que quelque chose casse, je peux revenir à la version d'avant. C'est une assurance. Pas une complexité supplémentaire.

La mécanique derrière (les "commits", les "branches", les "pull requests") peut attendre. Pour l'instant, retenir une seule idée suffit : GitHub est un endroit sur internet où vivent des dossiers de code, avec l'historique de tout ce qui leur est arrivé.

Ce que ça change de savoir ça

Quand Claude Code me dit "j'ai créé le fichier config.py dans le dossier src", je sais ce que ça veut dire. Je peux aller vérifier. Je peux l'ouvrir avec TextEdit si je veux voir ce qu'il y a dedans. Je peux naviguer jusqu'à lui en terminal si j'en ai besoin.

Quand un tutoriel dit "ouvre ton terminal et tape cd suivi du chemin de ton projet", ce n'est plus du charabia. C'est une instruction que je sais suivre.

Ce n'est pas une compétence technique. C'est une carte du territoire. Avant, je travaillais dans un pays dont je ne connaissais pas la géographie : je savais qu'il existait des villes, des routes, des frontières, mais je ne savais pas où elles étaient ni comment circuler. Maintenant j'ai la carte.

Les outils comme Lovable ou Claude Code font le travail de génération à ta place. Mais ils génèrent des fichiers, dans des dossiers, sur un ordinateur. Savoir ça, c'est savoir où regarder quand quelque chose ne va pas. C'est savoir quoi demander quand tu poses une question. C'est la différence entre subir un outil et l'utiliser.

Le terminal ne mord pas. Il attend juste qu'on lui parle.