Nous venions d’acheter notre Nissan Qashqai et je voulais conserver une copie de sa fiche de vente.

Pas seulement quelques captures d’écran ou les photos du véhicule : je voulais garder la page complète, son apparence et, autant que possible, ses interactions, même une fois l’annonce retirée du site.

L’objectif était donc assez simple :

• sauvegarder la page complète ;
• conserver les CSS et les images ;
• conserver le JavaScript utile ;
• pouvoir ouvrir la copie sans connexion Internet ;
• idéalement obtenir un seul fichier HTML facile à archiver.

C’est exactement le genre de problème que cherche à résoudre SingleFile.

SingleFile CLI

SingleFile est surtout connu comme extension de navigateur, mais il existe également en version ligne de commande :

github.com/gildas-lormeau/single-file-cli

Les exécutables précompilés sont disponibles directement dans les releases :

github.com/gildas-lormeau/single-file-cli/releases

Sous Windows, il suffit notamment de récupérer :

single-file.exe

L’exécutable peut être utilisé directement, sans installation particulière. Il pilote Chrome ou un autre navigateur basé sur Chromium, charge réellement la page, puis rassemble son contenu et ses différentes ressources dans un fichier HTML autonome.

La commande utilisée

Dans mon cas, j’ai utilisé PowerShell avec la commande suivante.

L’adresse du site d’origine est volontairement anonymisée ici :

.\single-file.exe "<URL_DE_L_ANNONCE>" "HOPAUTO_QASHQAI_82005_ISO_OFFLINE.html" --browser-headless=false --block-scripts=false --load-deferred-images=true --browser-wait-until=networkIdle --browser-wait-delay=8000 --remove-hidden-elements=false --remove-unused-styles=false --remove-unused-fonts=false --remove-alternative-images=false --browser-executable-path="C:\Program Files\Google\Chrome\Application\chrome.exe"

Le résultat est un gros fichier :

HOPAUTO_QASHQAI_82005_ISO_OFFLINE.html

Les images, feuilles de style et autres ressources peuvent notamment être intégrées directement dans ce HTML.

À quoi servent les paramètres ?

Ces options privilégient clairement la fidélité de la copie plutôt que la taille du fichier final.

Un piège avec les sites React

La première sauvegarde semblait parfaite.

J’ouvrais le HTML localement, la page apparaissait avec les bonnes photos puis, une fois son chargement terminé… les photos disparaissaient.

Le problème ne venait pas de SingleFile lui-même mais du fonctionnement du site.

La page utilisait React/Next.js. SingleFile avait correctement intégré les JPEG dans le HTML, mais les données utilisées ensuite par React contenaient toujours les URL originales des images.

Le scénario devenait donc :

Ouverture du HTML
        ↓
Affichage des images intégrées par SingleFile
        ↓
Hydratation de l'application React
        ↓
Réapplication des URL originales
        ↓
Tentative de chargement depuis Internet
        ↓
Images perdues hors ligne

La solution évidente aurait été de désactiver complètement JavaScript.

Elle aurait aussi supprimé une bonne partie de l’intérêt de la sauvegarde : galerie, boutons et autres interactions n’auraient plus fonctionné.

Dans mon cas, la meilleure solution a donc été plus ciblée : conserver React et le JavaScript de la page, mais empêcher uniquement la réhydratation de remplacer les images intégrées par leurs anciennes URL distantes.

C’est une limite importante à connaître : SingleFile peut parfaitement capturer les ressources d’une page, mais un site web moderne reste parfois une véritable application dont le JavaScript continue à vouloir communiquer avec son serveur d’origine.

Un outil à garder sous la main

Malgré cette petite difficulté, single-file.exe est exactement le genre d’utilitaire que j’aime garder dans un dossier d’outils.

Pas d’interface compliquée, pas besoin de créer un projet : une URL, un fichier de sortie et une commande.

Pour archiver une documentation, une fiche produit, une ancienne page personnelle ou, comme ici, la fiche du véhicule que l’on vient d’acheter, c’est particulièrement pratique.

Et surtout, quelques années plus tard, un gros fichier HTML autonome sera probablement beaucoup plus utile qu’un lien terminé depuis longtemps en erreur 404.

L’idée n’était surtout pas de coder sur un iPhone. Rien que d’y penser, ça ne donne pas particulièrement envie.

Mon objectif était différent : utiliser l’iPhone comme une télécommande pour Codex.

Ouvrir un terminal, donner un objectif à Codex, fermer le téléphone et le laisser travailler tranquillement pendant quelques heures. Puis revenir plus tard voir le résultat, apporter quelques précisions et éventuellement lui donner une nouvelle tâche.

C’est comme ça que je me suis retrouvé à lancer des /goal depuis la plage de Palma avant de remettre tranquillement mon téléphone dans le sac.

Pour arriver à ce résultat, je suis d’abord passé par GitHub Codespaces, puis ShellFish sur iOS, avant de finalement réaliser que j’avais déjà une solution encore mieux adaptée : ma seedbox, SSH et tmux.

Première expérimentation : GitHub Codespaces

Sur le papier, GitHub Codespaces répond parfaitement au besoin.

À partir d’un dépôt GitHub, on obtient en quelques instants une véritable machine de développement dans le cloud :

• le dépôt Git est disponible ;
• on dispose d’un terminal Linux ;
• Node.js et les différents outils du projet peuvent être installés ;
• Codex CLI peut fonctionner comme sur une machine classique ;
• l’environnement est accessible depuis Internet.

Pour travailler ponctuellement sans avoir son ordinateur avec soi, c’est assez bluffant.

Une fois connecté au Codespace, je pouvais simplement lancer :

codex

Puis confier une tâche relativement autonome à Codex avec un /goal.

Et c’est précisément là que le fonctionnement devient intéressant.

Codex n’a pas besoin que je reste devant le terminal pendant qu’il travaille. Il peut analyser le projet, parcourir les fichiers, écrire du code, lancer des commandes, exécuter des tests et corriger ses erreurs.

L’iPhone ne sert donc pas réellement à développer.

Il sert à dire à Codex quoi développer.

ShellFish : le terminal qu’il me fallait sur iPhone

Restait néanmoins un problème : comment accéder confortablement à cet environnement depuis un iPhone ?

Passer systématiquement par une interface web n’était pas particulièrement agréable. Je voulais quelque chose de beaucoup plus direct : ouvrir une application et me retrouver immédiatement dans mon terminal.

J’ai finalement retenu ShellFish, une application iOS permettant notamment d’utiliser SSH et SFTP.

Et pour mon besoin, c’était exactement ce qu’il fallait.

Le fonctionnement était alors très simple :

iPhone
   │
ShellFish
   │
   │ SSH
   ▼
GitHub Codespace
   │
   ├── Git
   ├── projet
   └── Codex CLI

J’ouvrais ShellFish, je me connectais à mon environnement distant et je retrouvais un véritable terminal.

Quelques commandes suffisaient alors pour me placer dans le projet et lancer Codex :

cd mon-projet
codex

Je pouvais ensuite écrire mon /goal, vérifier que Codex était correctement parti sur sa tâche et ranger le téléphone.

C’était beaucoup plus proche de l’expérience que je recherchais.

Le téléphone devient une télécommande

Ce changement de perspective est finalement assez important.

Essayer de reproduire un environnement VS Code complet sur un écran de téléphone n’a que peu d’intérêt pour moi. L’écran est trop petit, le clavier virtuel devient rapidement pénible et naviguer entre plusieurs fichiers n’est pas agréable.

Avec un agent comme Codex, ce n’est plus réellement nécessaire.

Mon workflow ressemblait plutôt à ça :

Ouvrir ShellFish
       ↓
Connexion SSH
       ↓
Reprendre Codex
       ↓
Donner un /goal
       ↓
Vérifier le démarrage
       ↓
Fermer ShellFish
       ↓
Profiter des vacances

Quelques heures plus tard, je pouvais revenir voir le résultat.

C’est une manière assez différente d’envisager le développement à distance.

Depuis la plage de Palma

Et c’est pendant nos vacances à Majorque que cette expérimentation a réellement pris son sens.

Pas besoin de sortir un ordinateur portable ni de chercher une table et une prise électrique.

Depuis la plage de Palma, je pouvais sortir l’iPhone, ouvrir ShellFish, me connecter à mon environnement et donner une nouvelle tâche à Codex.

Quelques minutes plus tard, le téléphone retournait dans le sac.

Codex, lui, pouvait continuer son travail.

C’est assez amusant la première fois que l’on réalise qu’une tâche de développement relativement conséquente est en train de s’exécuter quelque part pendant que l’on est tranquillement sur une plage à plusieurs milliers de kilomètres.

Mais cette utilisation m’a aussi permis de mettre en évidence les limites de mon architecture.

La limite de Codespaces

GitHub Codespaces est excellent pour créer rapidement un environnement de développement.

Mais un Codespace reste, par conception, une ressource temporaire.

Il peut notamment être arrêté après une période d’inactivité. Ce comportement est parfaitement logique pour éviter de laisser tourner inutilement des machines dans le cloud.

Pour mon utilisation de Codex, en revanche, je recherchais presque exactement l’inverse.

Je voulais quelque chose comme :

10h00  → lancement d'un /goal

10h05  → téléphone dans le sac
         Codex continue à travailler

12h00  → reconnexion
         vérification du résultat

12h10  → nouveau /goal

17h00  → reprise de la session

Je voulais donc un environnement permanent, mais également une session de terminal persistante.

Et c’est là que tmux devient particulièrement intéressant.

tmux : la pièce manquante

tmux est ce que l’on appelle un multiplexeur de terminal.

Son fonctionnement peut paraître un peu obscur au premier abord, mais pour mon utilisation une seule de ses fonctions est réellement importante :

une session tmux continue d’exister même lorsque je ferme ma connexion SSH.

Je peux créer une session :

tmux new -s codex

Puis lancer Codex à l’intérieur :

codex

Je donne ensuite un /goal à Codex.

Une fois la tâche lancée, je détache la session avec :

Ctrl+B puis D

Je peux maintenant fermer complètement ShellFish.

La connexion SSH est coupée.

Mais sur la machine distante :

tmux
  │
  └── Codex
        │
        └── /goal en cours

continue tranquillement à fonctionner.

Quelques heures plus tard, je me reconnecte en SSH et je tape :

tmux attach -t codex

Et je retrouve exactement le même terminal, avec la même session Codex.

C’est précisément ce qu’il me fallait.

Et si je remplaçais Codespaces ?

À ce stade, une question assez évidente s’est posée.

Pourquoi utiliser une machine Codespaces alors que je disposais déjà d’une machine Linux accessible en permanence ?

J’utilise une seedbox, allumée 24 heures sur 24 et accessible à distance en SSH.

Elle disposait déjà d’une bonne partie de ce dont j’avais besoin et pouvait devenir mon environnement Codex permanent.

Il suffisait finalement d’y disposer de :

• Git ;
• mes dépôts ;
• Codex CLI ;
• tmux ;
• SSH.

L’architecture devenait alors :

                    GitHub
                      ▲
                      │
                   git push
                      │
                      │
iPhone ── ShellFish ──SSH──► Seedbox
                              │
                              ├── projets Git
                              │
                              └── tmux
                                   │
                                   └── Codex CLI
                                         │
                                         └── /goal

Plus besoin de créer ou démarrer un Codespace.

Ma machine de développement distante était déjà allumée en permanence.

Une session par projet

Avec tmux, je peux également organiser les sessions en fonction des projets.

Par exemple :

tmux new -s zod

pour un projet, puis :

tmux new -s smb

pour un autre.

La commande suivante permet de voir les sessions disponibles :

tmux ls

Ce qui peut donner quelque chose comme :

zod: 1 windows
smb: 1 windows
blog: 1 windows

Depuis ShellFish, je peux alors choisir celle que je veux reprendre :

tmux attach -t zod

Je retrouve immédiatement Codex et son contexte de travail.

Puis je détache à nouveau :

Ctrl+B puis D

Et la session continue à vivre sans mon téléphone.

ShellFish + SSH + tmux + Codex

C’est finalement cette combinaison qui répond réellement à mon besoin :

        iPhone
           │
       ShellFish
           │
          SSH
           │
        Seedbox
           │
         tmux
           │
      Codex CLI
           │
         /goal

Chaque élément a un rôle très simple.

ShellFish me donne un terminal confortable sur l’iPhone.

SSH me permet d’accéder à la machine distante.

tmux rend mes sessions indépendantes de la connexion SSH.

Codex CLI effectue le travail.

GitHub reste le point central où je pousse ensuite les modifications.

L’ensemble est finalement beaucoup plus simple qu’un environnement de développement distant traditionnel.

Codespaces n’était pas une mauvaise piste

Pour autant, je ne considère pas mon expérimentation avec GitHub Codespaces comme inutile.

Au contraire.

Codespaces m’a permis de valider le concept sans avoir à préparer une infrastructure particulière.

J’ai pu vérifier qu’il était réellement possible de :

• piloter Codex depuis un téléphone ;
• travailler correctement avec un simple terminal SSH ;
• lancer des tâches relativement longues ;
• quitter son téléphone pendant leur exécution ;
• revenir plus tard contrôler le résultat.

C’était finalement une preuve de concept.

Une fois celle-ci validée, la seedbox s’est simplement révélée plus adaptée à mon usage permanent.

Les commandes à retenir

Au final, le nombre de commandes nécessaires est assez réduit.

Lancer Codex

codex

Créer une session tmux

tmux new -s codex

Ou en utilisant le nom du projet :

tmux new -s zod

Détacher une session

Depuis une session tmux :

Ctrl+B puis D

Codex continue alors à fonctionner.

Afficher les sessions existantes

tmux ls

Reprendre une session

tmux attach -t codex

Ou :

tmux attach -t zod

Vérifier les modifications effectuées par Codex

git status

Ajouter toutes les modifications

git add .

Créer le commit

git commit -m "Description des modifications"

Envoyer les modifications sur GitHub

git push

Si la branche distante n’existe pas encore :

git push -u origin nom-de-la-branche

Le workflow Git complet après le travail de Codex tient donc finalement en quatre commandes :

git status
git add .
git commit -m "Description des modifications"
git push

Conclusion

Cette expérimentation est partie d’une contrainte toute simple : je ne voulais pas emmener mon PC portable partout pendant les vacances.

GitHub Codespaces m’a d’abord fourni une machine de développement disponible à la demande.

ShellFish m’a ensuite permis de transformer mon iPhone en terminal SSH réellement utilisable.

Puis tmux a résolu le problème essentiel de la persistance : une tâche Codex pouvait continuer à tourner même après avoir fermé ShellFish et perdu la connexion SSH.

À partir de là, Codespaces n’était finalement plus indispensable. Ma seedbox pouvait assurer exactement ce rôle, avec l’avantage d’être déjà disponible 24 heures sur 24.

Ce que je retiens surtout de cette expérience, c’est que l’arrivée d’agents comme Codex modifie assez profondément la notion de développement à distance.

Je n’ai plus forcément besoin d’avoir mon IDE devant moi.

Je n’ai même plus forcément besoin de rester connecté.

Je peux simplement ouvrir ShellFish, reprendre une session tmux, donner un /goal à Codex et revenir quelques heures plus tard.

Et lorsque l’on peut faire tout ça en quelques minutes depuis la plage de Palma avant de remettre son téléphone dans le sac, on commence vraiment à comprendre l’intérêt des agents de développement autonomes.

Light Static Blog est né d’un besoin très simple : avoir un blog personnel que je comprends, que je maîtrise, et que je peux déployer sans usine à gaz.

Je voulais quelque chose de léger, statique, lisible, personnalisable, et assez propre pour durer. Pas un CMS complet. Pas une application serveur à maintenir. Pas une base de données pour trois articles et quelques images.

Juste du Markdown, un build, puis des fichiers HTML à déposer quelque part.

Pourquoi une solution perso ?

Il existe déjà beaucoup de solutions pour publier un blog. Certaines sont très bonnes. Mais j’avais envie d’un socle à ma main, avec des choix simples :

• des articles en Markdown dans le repo ;
• un site généré statiquement ;
• un thème facilement remplaçable ;
• un flux RSS complet ;
• un sitemap et un robots.txt propres ;
• une base SEO correcte dès le départ ;
• un déploiement automatisé vers mon hébergement.

Le but n’était pas de réinventer le web. Le but était plutôt de construire un petit outil clair, adapté à mon usage, et suffisamment générique pour rester réutilisable.

Le choix du statique

Le statique a un charme très particulier : une fois généré, le site n’a presque plus besoin de rien.

Pas de serveur applicatif, pas de session, pas de base de données, pas de mise à jour de plugin qui casse tout un dimanche soir. Le résultat final, ce sont des fichiers HTML, CSS, JS et images que n’importe quel hébergement web classique peut servir.

Pour un blog personnel, c’est exactement ce que je voulais :

• rapide à charger ;
• simple à sauvegarder ;
• facile à versionner ;
• peu fragile ;
• déployable aussi bien sur GitHub Pages que sur un hébergement SFTP.

Il y a aussi une raison plus pragmatique : la sécurité. Un site statique expose beaucoup moins de surface d’attaque qu’une application dynamique. Pas d’administration en ligne, pas de base de données accessible, pas de code serveur à exécuter à chaque requête. Rien n’est magique, évidemment, mais moins il y a de pièces mobiles en production, moins il y a d’endroits où quelque chose peut mal tourner.

Le déploiement automatique

Une grosse partie du confort vient du déploiement.

L’idée est de pouvoir lancer une commande, générer le site, vérifier les sorties importantes, puis envoyer uniquement ce qui doit l’être sur le serveur. Le script SFTP gère donc le build, quelques contrôles, le transfert et une vérification des fichiers publiés.

Ce n’est pas spectaculaire, mais c’est exactement le genre de détail qui change l’usage au quotidien. Quand publier devient simple, on publie plus facilement.

Vibecodé avec Codex

Ce projet a aussi été une expérience de vibecoding.

Pendant quelques jours, j’ai construit le blog avec Codex comme compagnon de route : une idée, une itération, un test, une correction, puis une autre idée. Le système de thèmes, le RSS, le sitemap, les métadonnées SEO, le rendu Markdown, les améliorations mobiles, l’accessibilité, le script de déploiement… tout a été fait par petites passes successives.

Ce qui m’a plu dans cette manière de travailler, c’est le rythme. On peut avancer vite sans forcément bâcler, à condition de vérifier souvent :

npm run validate

À chaque étape, le projet devait continuer à construire proprement. C’est devenu une sorte de règle du jeu : expérimenter, oui, mais garder une base saine.

Un moteur et un carnet

Aujourd’hui, Light Static Blog est le moteur public générique. Et ce site, Carnet de dev, en est une déclinaison personnelle avec mon thème, mes contenus et mon déploiement.

Cette séparation me plaît bien :

Le moteur peut continuer à évoluer proprement, tandis que le carnet reste mon terrain d’expression.

Ce que je retiens

Ce projet est modeste, mais il coche beaucoup de cases importantes pour moi :

1. il est simple à comprendre ;
2. il produit un site statique rapide ;
3. il respecte les bases SEO et RSS ;
4. il laisse la main au thème ;
5. il se déploie sans friction ;
6. il garde le contenu dans Git.

Et surtout, il donne envie d’écrire la suite.

Il fallait bien un premier billet.

Ce blog naît d’une envie assez simple : garder une trace de ce que je fabrique, de ce que je teste, de ce que je casse parfois, et de ce que j’apprends en chemin.

Un carnet plutôt qu’une vitrine

Je ne veux pas en faire une grande scène officielle, avec projecteurs et phrases trop propres. L’idée est plutôt d’avoir un carnet vivant, où je peux poser des notes, documenter des choix, raconter un bricolage technique ou revenir sur une expérimentation.

Il y aura probablement des articles très courts, d’autres plus détaillés, et quelques détours. Ça me va bien : les projets numériques avancent rarement en ligne droite.

Des expérimentations geekesques

Une bonne partie du contenu tournera autour du développement et des bidouilles geekesques :

• essais d’outils ;
• petits scripts utiles ;
• interfaces bricolées ;
• automatisations ;
• tests autour du web, de l’hébergement ou de la génération statique ;
• idées qui commencent par “tiens, et si…”.

Le but n’est pas de prétendre avoir la réponse parfaite. Le but est de partager le chemin, les essais, les limites et les petites trouvailles.

Des projets vibecodés

J’ai aussi envie de documenter des projets vibecodés : ces moments où l’on part d’une idée, d’une intuition, d’une ambiance, puis où l’on construit en dialoguant avec les outils, le code et les contraintes.

Ce blog lui-même en fait partie. Il est à la fois le support et le premier terrain de jeu : thème terminal, déploiement, RSS, SEO, accessibilité, personnalisation… un petit laboratoire qui prend forme en avançant.

Photo, numérique et autres bifurcations

Il pourra aussi être question de photo, d’images, d’objets numériques ou de projets plus personnels. Pas forcément sous forme de grands tutoriels : parfois une image, une idée, un retour d’expérience ou une note de méthode suffisent.

Si un sujet touche à la création numérique, au plaisir de comprendre ou à la joie de bricoler quelque chose qui fonctionne, il a probablement sa place ici.

Pourquoi publier ?

Publier oblige à clarifier. Même quand personne ne lit tout de suite, écrire force à ranger un peu ses idées, à nommer ce qui était flou, à garder une trace consultable plus tard.

Et puis il y a une autre raison, plus simple : partager une expérimentation peut donner envie à quelqu’un d’essayer à son tour. Rien que pour ça, le carnet vaut le coup d’exister.

Bienvenue donc dans ce petit coin de web.