Le making-of d'un déploiement raté Comment publier un simple fichier HTML a pris huit allers-retours

La chronologie complète du premier 404 jusqu'au design correct, sans rien sauter

La tâche de départ était simple : prendre un fichier HTML que j'avais déjà sur mon Mac, et le mettre en ligne sur mon site via GitHub + Vercel. Voici, minute par minute, ce qui s'est réellement passé.

• Étape 1

  Demande de déploiement du guide dans un dossier /guides/

  Structure proposée et acceptée. Commandes mkdir, cp, git add/commit/push données pour exécution.

• Étape 2 : 🔴 erreur

  Premier 404 : « le guide n'est pas lisible »

  La commande cp pointait vers un chemin qui n'existe que sur le serveur de l'assistant, jamais sur le Mac. Le fichier n'a donc jamais été copié, et rien n'a été poussé sur GitHub.

• Étape 3 : 🔴 erreur

  Deuxième 404, malgré une nouvelle tentative

  Même cause répétée une seconde fois, avec un chemin légèrement différent, toujours côté serveur de l'assistant, toujours invisible depuis le Mac.

• Étape 4

  Diagnostic correct : git status demandé

  Premier vrai pas de débogage utile : vérifier ce que git voit réellement, plutôt que de redonner la même commande.

• Étape 5 : 🔴 erreur

  Chemin dupliqué : guides/guides/

  Le terminal était déjà positionné dans le dossier guides/. La commande suivante a réutilisé le même chemin relatif, créant un dossier fantôme guides/guides/ introuvable par git.

• Étape 6

  Contournement : coller le HTML directement dans le terminal

  Plutôt que de continuer à chercher pourquoi cp échouait, bascule sur un cat >> fichier << EOF : coller le contenu HTML complet directement dans la commande terminal.

• Étape 7 : 🔴 erreur

  Version simplifiée poussée par erreur

  En tapant le HTML « à la volée » dans la commande, une version résumée et non-stylée a été produite à la place du design original complet. Déployée et visible publiquement quelques minutes.

• Étape 8 : ✅ résolu

  Récupération du fichier exact via l'API GitHub

  Plutôt que de retaper le design à la main, récupération du HTML déjà déployé directement depuis raw.githubusercontent.com, la seule source garantie identique à l'original.

Erreur n°1 : deux environnements, un seul mot « ton fichier » ne veut pas dire la même chose des deux côtés

C'est l'erreur la plus coûteuse de toute la séquence, et la plus facile à reproduire sans s'en rendre compte. Quand un assistant IA crée un fichier pendant la conversation, il l'enregistre sur son espace de travail, un serveur temporaire, jamais connecté physiquement à l'ordinateur de la personne.

$ cp /mnt/user-data/outputs/ollama-cloud-guide-final.html guides/ollama-cloud.html
cp: /mnt/user-data/outputs/ollama-cloud-guide-final.html: No such file or directory

Le message d'erreur est techniquement parfait, le système dit exactement la vérité. Le problème n'est pas dans la commande, il est dans l'hypothèse implicite qu'il existe un seul disque dur partagé entre l'assistant et la personne. Ce n'est jamais le cas.

Erreur n°2 : le chemin qui se duplique quand personne ne demande « où es-tu, là, maintenant ? »

Deuxième piège classique du travail en terminal : la confusion entre chemin absolu et chemin relatif. Après être entré dans le dossier guides/ pour vérifier son contenu, la commande suivante a réutilisé guides/ollama-cloud.html comme si on était encore à la racine du projet.

~/Site-Bryanb/guides % git add guides/ollama-cloud.html
warning: could not open directory 'guides/guides/': No such file or directory
fatal: pathspec 'guides/ollama-cloud.html' did not match any files

Git n'invente rien : il a cherché exactement ce qu'on lui a demandé, guides/guides/ollama-cloud.html, et ce dossier n'a jamais existé. Le fichier, lui, était bien là, juste un niveau plus haut que ce que supposait la commande.

Erreur n°3 : la version dégradée à la volée retaper un design complexe de mémoire ne marche jamais bien

Après deux échecs de copie de fichier, la solution de repli a été de coller le code HTML directement dans une commande terminal (cat > fichier << EOF). Sur le principe, c'est une bonne idée, ça ne dépend d'aucun chemin de fichier. En pratique, le contenu retapé à la volée était une version résumée, sans la mise en page ni le style d'origine.

La bonne pratique ici n'est pas de retaper un design complexe de mémoire dans un terminal, mais de traiter le fichier déjà déployé comme la source de vérité unique. Une fois qu'un design correct existe quelque part en ligne, il n'y a plus besoin de le recréer, seulement de le récupérer tel quel.

Ce que je fais différemment maintenant

• ✅

  Je vérifie toujours « où » avant « quoi »

  Avant d'exécuter une commande avec un chemin de fichier, je vérifie d'un coup d'œil si ce chemin appartient à mon ordinateur ou à l'environnement de l'assistant.

• ✅

  Un pwd avant chaque git add sensible

  Ça coûte une ligne de terminal et ça élimine la quasi-totalité des erreurs de chemin relatif dupliqué.

• ✅

  Le déployé fait foi, jamais la mémoire

  Dès qu'un design correct existe en ligne, je le récupère tel quel pour toute itération future, je ne demande plus jamais de le retaper.

• ✅

  Un seul fichier de référence pour tout le site

  Ce guide partage exactement le même CSS que le premier, copié-collé depuis la source déployée, pas réécrit. C'est la garantie qu'il n'y a plus de divergence visuelle possible entre les guides du site.