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 cette fenêtre comme on contourne une flaque.
Bonne nouvelle : pour construire avec Claude Code aujourd'hui, tu n'as pas à l'ouvrir. Claude Code vit dans une application, avec une vraie interface, des boutons, une vue de tes fichiers. La fenêtre noire reste dans son coin.
Mais la peur qu'elle représente ne vient pas vraiment d'elle. Elle vient de tout ce qu'il y a derrière : le code, les fichiers aux extensions bizarres, les dossiers de projet. C'est ça qu'on va dédramatiser. En vingt minutes, et sans rien taper d'ésotérique.
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.
Et quand tu travailles avec Claude Code, ce dossier, tu l'as sous les yeux. L'application affiche son contenu sur le côté, exactement comme le Finder ou l'Explorateur de fichiers. Tu vois les dossiers, tu vois les fichiers, tu vois ceux que Claude est en train de créer ou de modifier. Pas de fenêtre noire. Une liste de fichiers, comme partout ailleurs.
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.
Tu peux faire le test toi-même. Prends un fichier généré par Claude Code, fais "ouvrir avec TextEdit". Tu vois du texte. Tu ne comprends pas tout, évidemment. Mais tu lis. C'est 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 un programme pour l'exécuter. Et la bonne nouvelle, c'est que Claude Code s'occupe de ça pour toi : quand un projet doit être lancé, tu le lui demandes, et il s'en charge. Tu n'as pas à savoir quelle commande taper ni où.
Voir ses fichiers sans rien installer
Pas besoin du moindre outil technique pour te réconcilier avec un dossier de projet. Tu en as déjà un sous la main : le Finder sur Mac, l'Explorateur sur Windows.
Fais le test, ça prend deux minutes et rien ne peut mal tourner. Ouvre ton Finder (ou ton Explorateur). Va dans ton dossier Documents. Regarde la liste : des dossiers, des fichiers, leurs noms. C'est exactement ce que Claude Code affiche quand il travaille sur un projet, à un détail près : lui, il voit aussi ce qu'il y a dans les fichiers, et il sait les lire.
Si un jour tu tombes sur un fichier au format inconnu, fais un clic droit, "Ouvrir avec", et choisis TextEdit ou le Bloc-notes. Tu verras le texte brut. C'est le même geste que pour n'importe quel fichier, et c'est tout ce dont tu as besoin pour vérifier ce que Claude a écrit.
Voilà la carte. Un projet est un dossier. Un dossier contient des fichiers. Les fichiers sont du texte. Tu peux tous les ouvrir et les regarder, sans rien installer, sans rien taper.
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. Et là encore, l'application gère la connexion à GitHub pour toi : tu n'as pas à apprendre les commandes.
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 sais où il se trouve.
Quand un tutoriel mentionne un dossier de projet, des fichiers, des extensions, ce n'est plus du charabia. C'est une géographie que je connais.
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.
La fenêtre noire ne mord pas. Et le plus beau, c'est que tu n'as même pas besoin de t'en approcher.