🤹 Bon, tu veux te faire ton site web ?

dimanche 15 décembre 2024

• Mis à jour le 17/01/2025. Afficher les zones modifiées.
• Mis à jour le 18/12/2024. Afficher les zones modifiées.

---

J’ai fait quelques petites dizaines de sites web au fil des années. J’en ai fait avec des Content Management Systems (CMS) comme Wordpress ou SPIP, j’en ai fait avec des frameworks comme Django ou Flask, j’ai codé des petits trucs en Eleventy (11ty) et des gros trucs avec Kirby. J’ai même testé Svelte ou subi React. Il y a plein d’options pour faire un site, et j’en connais quelques unes.

Toi, ça fait un bail que tu n’as pas fait de site, mais tu as déjà bidouillé du HTML et du CSS. Peut-être un peu de PHP ou de JavaScript. Tu as peut-être eu un blog il y a dix ou quinze ans, que tu mettais à jour en FTP.

Dans ce post, je vais te parler des principes et des concepts, en laissant le comment-faire de côté. Je ne te donnerai pas de recette parce que je sais que tu trouveras la doc.

Le plus important : le contenu

Le cœur d’un site web, et ne laisse personne te dire le contraire, c’est le contenu.

Qu’est-ce que tu veux mettre sur le site ? Comment est-ce que ça sera structuré ?

Tout est possible. Tu veux deux blogs dans deux dossiers différents ? Possible. Tu veux un wiki pour afficher des notes qui se répondent entre elles ? Faisable. Tu veux une page toute simple avec un poëme dédié à ta footballeuse préférée ? Facile.

Allez. Tu sais ce que tu veux ? Bah écris-le.

Non, non, je déconne pas. Sur ton bureau, fais un clic-droit et sélectionne…

“Nouveau dossier”

Crée un répertoire. Dedans tu fais un fichier index.txt dans lequel tu écris le contenu de la page d’accueil de ton site. Puis pour chaque page tu crées un répertoire dans lequel tu mets un fichier index.txt et son contenu. Pour le nom de chaque répertoire, le mieux est d’utiliser un identifiant sans espaces et sans majuscules, de préférence sans accents, ça facilitera la tâche pour plus tard. Il y a des images à afficher dans ta page ? Glisse-les dans le répertoire de ladite page. Tu veux ajouter de la sémantique à ton texte, en utilisant des titres et sous-titres ? Fais-le en HTML si tu es à l’aise, ou en Markdown pour être plus lisible.

Là tu auras une arborescence de contenus de ton site. 95 % du boulot est fait. Maintenant il s’agit de l’habiller un peu et de le mettre en ligne, mais c’est des vulgaires considérations techniques.

Ah, en fait tu me posais la question spécifiquement pour la technique ? Ah bah OK alors on y va !

La technique

Si tu veux faire une seule page, il y a de grandes chances que tu n’auras pas besoin d’un CMS. Dans ce cas, tu fais un joli fichier HTML et un fichier CSS, et roule ma poule. On a établi au début que tu savais faire ça. Zou. On se retrouve pour la mise en ligne.

En revanche, pour encemoment.site j’ai utilisé un CMS minimaliste, 11ty. En effet, le site ne comporte qu’une page mais il agrège un tas de données. J’avais donné plus de détails sur mon article dédié, que je t’invite à lire.

En fait, jusqu’à trois pages tu peux te passer d’un CMS. Au delà c’est plus dur mais tout à fait envisageable.

Comme au bon vieux temps, les Server-side Includes

Une solution transitoire entre tout faire à la main et utiliser un CMS, c’est les Inclusions Côté Serveur (SSI) d’Apache httpd.apache.org/docs/2.4/fr/howto/ssi.html, ou l’équivalent chez nginx : SSI ou chez Caddy : templates. Je ne vais pas aller trop dans le détail, mais ça permet d’avoir les bénéfices d’un moteur de gabarits très basique pour inclure des variables (date, etc) ou des fichiers (en-tête, pied de page…) dans du HTML basique. C’est de la très ancienne technologie qui peut aussi gérer les listes de sous-pages ou de fichiers dans un répertoire.

Transformation directe : Eleventy (11ty)

Tu as ton répertoire de contenus au format Markdown ou HTML ? Si je te disais qu’il y a un moyen de tout transformer en HTML, ça te plairait ?

Le moyen le plus direct à mon avis, c’est Eleventy. Eleventy est en JavaScript et fonctionne avec un environnement NodeJS.

Si tu copies ton répertoire de contenu dans le projet Eleventy et que tu lances la commande, il va te générer un site web. Ça sera basique, pas d’en-tête, de menu, de pied de page, mais tu as pu découvrir la logique.

Il est possible de trouver des thèmes pour t’épargner le travail de concevoir et intégrer le design, par exemple sur 11tythemes.com. Comme beaucoup de ses équivalents, 11ty permet de stocker des données dans le frontmatter de chaque fichier texte : le titre de la page, la date, des étiquettes ou des catégories, mais aussi des données personnalisées à utiliser dans la page ou le gabarit (doc d’Eleventy). Si tu as le courage tu peux même utiliser du code JavaScript dans le frontmatter, qui sera exécuté lors de la compilation.

Un gros point noir qui s’est révélé à moi après la rédaction de cet article : Eleventy ne gère pas (bien) la hiérarchie des dossiers et fichiers. Il faut coder plein d’utilitaires si on veut faire un site qui se base uniquement sur la structure du système de fichiers, et pas sur les informations transmises via les métadonnées. Si le contenu de ton site provient surtout de données externes et que la hiérarchie des dossiers n’est pas déterminante, choisis 11ty. Sinon, choisis Hugo (section suivante).

Une fois le site compilé, tu as un répertoire qui s’appelle _site qui contient tout ton HTML prêt à être mis en ligne. Génial !

Le bon

• Tu pars de rien (donc tu as une très grande liberté de design et d’organisation, et même de source de tes données) ;
• c’est gratuit et open source ;
• 11ty est très rapide et n’inclut que le strict nécessaire ;
• le format de stockage des fichiers (Markdown + frontmatter) est extrêmement répandu ;
• la sortie en fichiers HTML statiques, la solution la plus universelle pour l’hébergement.

Le moins bon

• Tu pars de rien (donc tu dois tout faire) ;
• le site nécessite une étape de compilation avant d’être mis en ligne ;
• le contenu ne peut pas être édité en ligne (sauf en cas de dépot de code) ;
• l’environnement NodeJS peut être traitre pour la maintenance et l’entretien. Heureusement, 11ty n’a pas trop de dépendances ;
• la création de gabarits nécessite l’apprentissage d’un langage comme Nunjucks ou Liquid ;
• je trouve la doc un peu fouillis, c’est le revers de la médaille de tout ce qui est possible avec 11ty.

Jardin web : Quartz

Mettons que tu as beaucoup de contenu, tu as tout un énorme répertoire plein de fichiers Markdown qui se lient entre eux. De la doc, des notes, des références, etc. Et tu veux mettre tout ça sur le net.

À ce moment-là, Eleventy n’est pas forcément adapté. Je te propose Quartz. C’est là aussi dans un environnement NodeJS.

Quartz offre beaucoup moins de possibilités de personnalisation que 11ty ou Hugo, mais sa force n’est pas là.
Ce qui est proposé par Quartz, c’est une solution rapide pour publier du contenu à la manière d’un wiki, d’une documentation, d’un carnet de notes bien ordonné ou d’un jardin web plus entropique.

Les principales interventions de code dont il y a besoin pour mettre en place un site sous Quartz sont de l’ordre de la configuration et du style. Les gabarits marchent sans intervention mais surtout sans autant de possibilités qu’11ty ou Hugo. Quartz prend beaucoup de décisions pour toi, te laissant te concentrer sur ce qui est important : le contenu.

Étant donné que Quartz contraint un peu ton usage, les données stockées dans le frontmatter des pages sont limitées. Il y a une petite dizaine de propriétés qui seront prises en compte (doc d’Obsidian, doc de Quartz), le reste sera ignoré.

Pour ton site ? Tu renommes tous les fichiers texte de ton répertoire de contenus pour leur donner l’extension .md, puis tu suis le procédé d’installation de la doc de Quartz, et tu peux utiliser ton répertoire tel quel sans même avoir à le recopier. La compilation de Quartz a tendance à être plus lente que celle de 11ty, mais c’est négligeable, à part sur un ordinateur très peu puissant.

Le bon

• Si ton but est juste d’afficher ton répertoire de notes d’Obsidian, c’est parfait (c’est même fait pour) ;
• c’est gratuit et open source ;
• le départ est facile, et le site généré contient tout un tas de trucs utiles (même une recherche) ;
• le format de stockage des fichiers est extrêmement répandu ;
• la sortie en fichiers HTML statiques, la solution la plus universelle pour l’hébergement.

Le moins bon

• L’environnement NodeJS peut être traitre pour la maintenance et l’entretien. Quartz a beaucoup de dépendances et une familiarité avec le JavaScript est nécessaire ;
• le site nécessite une étape de compilation avant d’être mis en ligne ;
• le contenu ne peut pas être édité en ligne (sauf en cas de dépot de code) ;
• côté performance du site généré, c’est pas brillant (700 Ko de JavaScript en premier chargement de ton site).

Le CMS par excellence : Kirby

Bon alors j’en parle ici depuis longtemps, je l’utilise depuis encore plus longtemps. J’ai testé ses concurrents et je suis revenu à Kirby. Je pilote deux gros sites (en quantité de contenus et en exigence de fonctionnalités) pour Paris Web. Si on a parlé de web ensemble, je l’ai mentionné, et je t’ai parlé du plaisir que j’ai à utiliser cet outil.

Kirby est un véritable CMS : à la différence de 11ty, Hugo et Quartz qui sont des générateurs de sites statiques, c’est une solution qui, une fois sur le serveur, te donne une interface de gestion du contenu. Outre le fait que ça te permet de modifier les contenus de ton site sans outillage exterieur, ça libère beaucoup de possibilités : recherche dans le site, traitement de contenus externes sans compilation…

Contrairement à 11ty, Hugo ou Quartz, il n’y a pas de frontmatter pour stocker les différentes données de ta page. Il n’y a pas de limites aux types de données : ça peut être une liste de pages du site, des dates, des liens, des fichiers liés, et même pourquoi pas du code CSS à insérer dans cette page particulière. Ça te permet aussi d’avoir plusieurs contenus textuels au lieu d’un seul (par exemple dans une page où tu veux stocker la présentation d’une conférence, et la transcription de celle-ci, à afficher à des endroits différents de ton gabarit). Cette profusion de possibilités te permet une grande flexibilité dans l’affichage de ton site.

Il va falloir adapter un petit peu les fichiers texte de ton site. Pour chacun il faudra formater le titre et le corps en respectant la syntaxe. De manière basique, c’est juste qu’il faut rajouter Title: avant le titre, et Content: avant le corps de ta page, et séparer les deux par des tirets ------. Une fois ce changement fait, le site peut être servi. Pour voir le site avant de le mettre en ligne, il faut un environnement PHP sur ton ordinateur, c’est un désavantage que les générateurs de sites statiques n’ont pas.

Le bon

• Du bon vieux PHP qui peut tourner sur un bon vieux serveur web ;
• conçu par un designer avec une réelle vision du produit et de son utilisation par des personnes pour qui le développement n’est pas l’activité principale ;
• tu peux stocker n’importe quel type de donnée pour chaque type de page ;
• énormément d’affordances pour le développement de tous les aspects du site ;
• tu pars de rien (donc tu as toutes les libertés) mais il y a plein de squelettes de sites disponibles (gabarits, styles, organisation, etc.) ;
• édition en ligne, avec un backend très flexible, facile à modifier depuis ton téléphone ;
• les gabarits sont en PHP basique et n’ont pas besoin de familiarité avec un autre langage spécial gabarits.

Le moins bon

• C’est payant, ça veut dire qu’à chaque fois que tu vas le mentionner un libriste bien intentionné va apparaître pour te donner son avis ;
• tu pars de rien (donc tu dois tout faire) ;
• le PHP a besoin d’un (tout petit) peu plus de puissance que le HTML statique, mais la possibilité d’utiliser du cache statique permet de limiter ce souci ;
• selon l’ordinateur de travail, la gestion de l’environnement PHP peut être difficile à mettre en place.
• Kirby gère (pour l’instant) très mal le versionnement des changements opérés sur les articles. C’est pas forcément gênant selon le type de contenus, mais c’est une différence marquante avec WordPress, à l’usage.

Ok, ok, Grav

Bon, tu n’est pas convaincu par le coût de Kirby ? Compréhensible. C’est adapté pour un site perso, mais c’est pas forcément la solution la plus pertinente.

Si tu souhaites cumuler l’utile (l’interface publication en ligne, comme Kirby) et l’agréable (gratuit et open source), il y a Grav. Je l’ai utilisé quelques années pour ce blog, c’est plutôt pratique à utiliser, mais j’ai préféré Kirby pour la flexibilité de sa structure de données.

Grav utilise des fichiers Markdown avec le même frontmatter qu’11ty, Hugo ou Quartz, ce qui limite le type de données qu’on peut y stocker (pas de longs contenus de markdown, par exemple). En revanche tu peux prendre ta hiérarchie de la première étape, ça devrait fonctionner sans modification.

Le bon

• Plein de thèmes et de plugins (mais certains sont playants) ;
• c’est gratuit et open source ;
• le format de stockage des fichiers est extrêmement répandu ;
• du bon vieux PHP qui peut tourner sur un bon vieux serveur web ;
• édition en ligne, avec un backend très flexible, facile à modifier depuis ton téléphone.

Le moins bon

• Le format avec frontmatter peut être limité selon les usages ;
• le PHP a besoin d’un (tout petit) peu plus de puissance que le HTML statique, mais la possibilité d’utiliser du cache permet de limiter ce souci ;
• selon l’ordinateur de travail, la gestion de l’environnement PHP peut être difficile à mettre en place ;
• les gabarits sont en Twig, un langage de templating à apprendre si tu n’en as jamais fait.

Attends, tu parles pas de Wordpress ?

Alors c’est vrai, l’autre fois j’ai juste dit que je l’aimais pas.

En gros :

• Il y a besoin d’une base de données (donc pas idéal pour l’énergie du serveur) ;
• le modèle de donnée est peu flexible : tu ne peux pas adapter chaque type de page à son contenu ;
• oui il y a énormément de choix de thèmes et de plugins—mais est-ce que tu as envie d’avoir à éviter ceux qui injectent des payloads JavaScript de 1 Mo, ceux qui sont incompatibles entre eux, ceux qui vont installer une backdoor ou ceux qui ont été conçus il y a dix ans et jamais mis à jour depuis ?
• t’as lu les bails sur Matt ?

En revanche, ok, c’est vrai, si tu veux un site en 5 minutes il y a un très grand nombre d’hébergeurs qui te proposent un bouton pour t’installer Wordpress et tu n’auras plus qu’à choisir un thème. Mais il faudra recopier l’arborescence de fichiers texte dans ton interface de Wordpress, un fichier par un. Mis à part ça, tu auras ton site rapidement sans avoir à te poser de question.

Mais franchement, est-ce que se poser des questions n’est pas un des intérêts de se faire un site web ? (ok ok, pas toujours)

La mise en ligne

Quel hébergement ? Prends un mutualisé chez Infomaniak, Ouvaton ou Alwaysdata, ça sera le plus simple. Tu peux aussi regarder s’il y a pas un Chaton dans ton coin. Autrement tu peux prendre un Raspberry Pi, installer Debian, nginx (et PHP si besoin), et le brancher à ta box internet. Pas certain que ça soit plus écolo qu’un mutu, mais pourquoi pas. Ce qui est garanti c’est que ça sera plus complexe, et qu’il faudra que tu apprennes la maintenance de serveur, la sécurité, etc.

Le truc d’anciens, le (secure) File Transfer Protocol ((s)FTP)

En utilisant les identifiants SSH de ton hébergeur ou de ton serveur, tu peux te connecter en FTP, comme dans les temps ancestraux. D’autres systèmes ont pris la place de ce mode de déploiement, mais c’est quand même sans pareil quand on veut avoir une interface graphique.

Si tu utilises cette solution avec 11ty, Hugo ou Quartz, il faudra déployer manuellement ton site à chaque changement du contenu, des gabarits ou du style, bref après chaque compilation du site. Avec Kirby, étant donné que tu vas gérer ton contenu en ligne via l’interface du CMS, tu n’auras à déployer manuellement que les changements de gabarits ou de style, ce qui arrive bien moins souvent que les changements de contenu (à part si tu es comme moi et que tu modifies l’interface plus souvent que tu ne postes sur ton blog).

L’automatisation de l’Intégration Continue/Déploiement Continu (CI/CD)

Un truc qui est arrivé par l’industrie et qui s’est répandu par les forges logicielles grand public (Github, GitLab…), c’est la CI. En gros, quand du code est contribué dans la branche principale du dépot de code, le système va déployer automatiquement ce code sur un serveur. En pratique, pour ton site ça peut être très pratique si tu choisis un système qui a besoin d’une compilation (11ty, Hugo ou Quartz).

Ça marche en ajoutant un fichier de config spécifique pour le système d’intégration continue. Ce fichier va déterminer les actions à suivre pour différents types d’événements (par exemple du code inséré dans la branche principale). GitLab et Github proposent des pages perso, ce qui permet d’avoir une action qui prend le code du dépôt, déclenche la compilation du site, et la dépose sur ta page perso GitLab ou Github.

GitLab comme Github ne proposant pas d’environnement PHP, le système n’est pas envisageable avec Kirby ou Grav.

Les deux ?

Bien entendu, il est possible que l’action du CI soit une synchronisation du site via sFTP (ou Rsync). À ce moment-là on a un système automatisé de compilation du site et déploiement sur son propre hébergement web. Parfait pour 11ty, Hugo ou Quartz. Action Github FTP Deploy, code pour GitLab.

Entre tradition et modernité, les interfaces de publication

Kirby et Grav ont des interfaces d’édition de contenu (comme WordPress), que tu peux accéder depuis n’importe quel ordinateur ou téléphone.

À partir du moment où le système est déployé sur ton hébergement (via sFTP par exemple), tu peux faire tout plein d’opérations sur le contenu : créer, supprimer, déplacer, publier, dépublier… Bref, c’est super pratique si tu veux pousser la complexité de la génération du HTML depuis ton ordi (comme avec 11ty ou Hugo qui compilent le HTML) vers le serveur (où c’est le PHP qui fait ton HTML à la demande).

…je n’ai fait que gratter la surface

Cet article n’est pas exhaustif, mais il indique des pistes que j’estime pertinentes pour que tu puisses décider par toi-même la solution la plus adaptée.

Je n’aborde pas la partie graphique, mis à part la disponibilité des thèmes. On verra ça dans un prochain article, il faut que je trouve comment l’articuler 🙂