Documentation on Zwindler's Reflection

101 façons de déployer Kubernetes : 125 solutions, des PRs communautaires et une UI qui s'améliore

Sun, 29 Mar 2026 18:00:00 +0200

Il bouge encore

Depuis la sortie de l’interface web du projet début février, le projet a continué à évoluer. Ajout de solutions manquantes, petites améliorations de l’UI, contributions externes, optimisations de performances… Bref, un bon petit mois bien rempli pour ce gros side project que j’aimerais faire grossir.

101-ways-to-deploy-kubernetes

Note : si vous n’avez pas suivi les épisodes précédents :

93 façons de déployer Kubernetes — le Google Sheet original
101 façons de déployer Kubernetes (v2) — passage sur GitHub
Une nouvelle UI pour explorer les 118+ solutions — l’appli Astro + Tailwind

7 nouvelles solutions

Le catalogue est passé de 118 à 125 solutions. Voici les ajouts depuis le dernier article :

Xen Orchestra - ajouté pendant un stream de Cuistops => Déploiement de clusters Kubernetes (MicroK8s) via les “recettes” de Xen Orchestra, la plateforme de management de Vates. Catégorie ManagementPlatform.
Charmed Kubernetes - suite à un commentaire sur LinkedIn, j’ai remplacé l’entrée “Juju” par Charmed Kubernetes, qui est le vrai nom du produit Canonical pour déployer Kubernetes via Juju.
kubeaver - découvert en scrollant bluesky sans but => un installateur Kubernetes offline/online avec une GUI, basé sur Kubespray et Ansible. Certifié CNCF conformance (pour ce que ça vaut…).
talos-bootstrap - script interactif de Cozystack pour bootstrapper des clusters Kubernetes sur Talos OS.
boot-to-talos - Outil de Cozystack (encore) qui convertit n’importe quel OS existant en Talos Linux, complètement depuis le userspace. Partiellement utilisé par Quentin dans un contexte que je ne peux révéler ;-)
TOPF - Talos Orchestrator by PostFinance, un CLI pour gérer des clusters Kubernetes basés sur Talos. Découvert sur le discord de Cuistops
Talhelper - Outil CLI pour créer des clusters Talos en mode GitOps, à partir d’un seul fichier YAML déclaratif. Je l’avais initialement mis de côté mais à y réfléchir, pourquoi pas le mettre.

On notera qu’au même titre que kubeadm et k3s, il y a beaucoup de solutions qui s’appuient sur Talos Linux. De mon point de vue, ça valide l’OS et ça confirme l’adoption croissante de cet OS immutable pour Kubernetes.

Refonte complète des tags

Un gros chantier a été la refonte de tous les tags du catalogue. Ils étaient incohérents : des noms d’outils utilisés comme tags (openshift, rancher…), des tags redondants (on-premise + self-hosted), des tags manquants ou parfois faux (par ex. “lightweight” sur des outils qui lancent des VMs).

J’ai nettoyé les tags de toutes les catégories :

Desktop : suppression des noms d’outils comme tags, ajout de gui pour Docker Desktop, Orbstack, Podman Desktop, Rancher Desktop
Selfhosted : suppression du tag redondant on-premise (29 solutions), ajout de tags pertinents (automation, edge, lightweight, bare-metal…)
ManagementPlatform : toutes les solutions ont maintenant 3 tags (multi-cloud, managed, gui, automation…)
KubernetesInKubernetes : correction de vcluster (virtualization → lightweight)

De nouveaux filtres dans l’UI

J’ai ajouté un filtre par nombre d’étoiles GitHub qui n’apparaît que quand le filtre “Open Source only” est activé. Plutôt pratique pour identifier rapidement les projets les plus populaires (> 100, > 1k, > 10k stars).

L’occasion aussi de réorganiser la barre de filtres : le sélecteur de statut (Active/Abandoned) est passé en dropdown compact, et le layout général a été retravaillé pour rester lisible même avec plus de filtres.

Dernier point, lorsque vous faites une recherche dans la barre principale, une variable vient d’ajouter à l’URL : pratique pour partager des solutions directement avec le lien.

Les contributions d’Antoine Caron (Slashgear)

Un grand merci à Antoine Caron (@slashgear) qui, au-delà de m’avoir aidé sur les performances et la sécurité de ce blog, a aussi contribué directement au projet 101 ways avec plusieurs PRs !

Hiérarchie des headings - les cartes utilisaient des <h3> sans <h2> dans la page. Antoine a corrigé ça pour une hiérarchie correcte (h1 → h2), ce qui améliore la navigation pour les lecteurs d’écran.
Accessibilité du champ de recherche - ajout d’un vrai <label> (en sr-only) et passage du type="text" à type="search" pour une meilleure sémantique.
Skip links - ajout de liens “skip to content” pour la navigation au clavier (WCAG 2.1, critère 2.4.1). Trois liens : vers la recherche, les filtres, et le contenu principal.

Amélioration des performances

En parlant de performances, le site s’est aussi amélioré côté PageSpeed. Voici un avant/après sur Lighthouse mobile :

De 82 à 99 en performances mobiles, avec du 100/100 en bonnes pratiques et SEO.

Ces gains viennent d’un ensemble de corrections, notamment la résolution du clipping des cartes au hover, un bug CSS assez vicieux lié à content-visibility: auto qui impliquait contain: paint et coupait le haut des cartes quand elles se soulevaient au survol. Antoine avait identifié le problème avec l’overflow-hidden, et Copilot a trouvé la cause racine dans le CSS containment.

Merci !

Un grand merci à tous ceux qui contribuent, que ce soit en me mentionnant les outils manquants, en soumettant des PRs, ou simplement en partageant le projet.

Merci spécial à Antoine Caron pour ses PRs sur l’accessibilité et la CI - c’est vraiment chouette de voir quelqu’un prendre le temps d’améliorer un projet open source qui n’est pas le sien. Et c’est d’autant plus appréciable qu’Antoine m’avait déjà aidé sur ce blog avec l’optimisation des images en AVIF et les security headers HTTP. 🙏

Le projet compte maintenant 125 solutions. Si vous en connaissez d’autres, n’hésitez pas à ouvrir une issue ou une PR (ou juste à me ping, en cas de flemme) !

👉 zwindler.github.io/101-ways-to-deploy-kubernetes

101 façons de déployer Kubernetes : une nouvelle UI pour explorer les 118+ solutions

Mon, 09 Feb 2026 18:00:00 +0200

De Google Sheet à une vraie application web

Vous vous souvenez peut-être de mes précédents articles sur ce projet : d’abord un simple Google Sheet avec 93 méthodes, puis un dépôt GitHub avec plus de 100 entrées.

Aujourd’hui, je peux présenter la dernière itération de ce projet : une vraie interface web pour explorer toutes ces solutions !

👉 101-ways-to-deploy-kubernetes

Pourquoi une UI ?

Le tableau Markdown sur GitHub, c’était déjà mieux que le Google Sheet pour la collaboration, mais à peine. Difficile à parser, difficile de rajouter des colonnes sans que ça devienne trop le bazar (c’était déjà le cas, ahah), et surtout, ultra MOCHE.

J’ai donc décidé de transformer tout ça en une interface moderne et intuitive, avec l’aide d’un LLM.

Stack technique : Astro + Tailwind

Pour ce projet, j’ai choisi une stack simple mais efficace :

Astro : un framework moderne qui génère des sites statiques ultra-rapides
Tailwind CSS : pour un design responsive sans prise de tête

Le résultat ? Un site léger, plutôt rapide, et qui fonctionne aussi bien sur desktop que sur mobile (même si l’expérience desktop reste plus confortable vu la quantité de données).

Les fonctionnalités

Des cartes pour chaque solution

Fini le tableau digne d’un dev back (non, pire, un ingé kube…) ! Chaque outil dispose maintenant de sa propre “carte” animée avec :

Le logo du projet
Le type de licence (OSS ou propriétaire)
Le nombre d’étoiles GitHub
Des liens directs vers le projet et des ressources tierces (blogs indépendants, REX, tutos…)

Des filtres puissants

Vous cherchez uniquement des solutions open source ? Des outils pour le développement local ? Des plateformes de management ?

Les filtres par catégories permettent de naviguer facilement :

Desktop (développement local)
Managed (offres cloud)
Self-hosted (automatisation on-premise)
Infra As Code
Kubernetes OS (systèmes spécialisés)
Management Platform
Kubernetes in Kubernetes

Et vous pouvez aussi filtrer par statut (actif, abandonné) ou afficher uniquement les solutions open source ou production ready.

Une barre de recherche

Vous savez ce que vous cherchez ? Tapez directement le nom dans la barre de recherche pour trouver la solution en un instant.

Des tags pour affiner

Au-delà des catégories, les tags permettent d’identifier rapidement les technologies sous-jacentes (kubeadm, k3s, k0s…).

Le saviez-vous ? Au moins 18 outils utilisent kubeadm !

En compilant toutes ces données, j’ai découvert quelque chose de fascinant : au moins 18 outils utilisent kubeadm comme backend pour déployer Kubernetes ! 🤯

Et ce n’est même pas en comptant les offres managées des cloud providers !

C’est typiquement le genre d’information qu’on peut maintenant visualiser instantanément grâce à cette nouvelle interface.

Un projet collaboratif

Le projet reste 100% open source et collaboratif. Les données sont toujours stockées dans le dépôt GitHub, et l’UI est générée automatiquement à partir de ces données (j’ai même rajouté des previews pour les PRs).

Il manque un outil ou un provider ? Vous avez repéré un bug ? N’hésitez pas à ouvrir une issue ou à soumettre une Pull Request !

Le projet compte maintenant 118 solutions (et je sais qu’il en manque certainement), avec pour chacune :

Des liens à jour
Le statut du projet
Des références externes (tutoriels, retours d’expérience…)

Essayez, commentez, partagez

Rendez-vous sur zwindler.github.io/101-ways-to-deploy-kubernetes pour explorer toutes ces solutions !

OK, c’est un infâme “call to action” comme on en voit sur tous les réseaux sociaux. Soit.

Cependant, je ne peux pas savoir si c’est utile (ou non) si vous ne le faites pas. Je peux le laisser en l’état (ça n’est pas génant en soit, j’ai plein d’autres side projects qui n’attendent que mon temps libre) ou le faire vivre, si ça vous plait / sert.

Et si vous trouvez ce projet utile, n’hésitez pas à :

Star le projet sur GitHub
Partager avec vos collègues de la communauté Cloud Native
Contribuer en ajoutant des outils manquants ou en corrigeant des erreurs

Merci d’avance ! 🙏

101 façons de déployer Kubernetes (v2) : maintenant sur Github avec plus de méthodes, plus de détails, plus de tout

Sun, 04 Jan 2026 10:00:00 +0200

Une nouvelle version, une nouvelle maison

Il y a quelques mois, je vous présentais mon tableau recensant 93 façons différentes de déployer Kubernetes, sur Google Sheets.

À la suite de la remarque de Ludovic Piot qui aurait aimé contribuer un ou deux outils manquants, j’ai pris un peu (beaucoup, en vrai) de temps pendant ces vacances pour déménager tout ça sur Github : 101-ways-to-deploy-kubernetes

Pourquoi sur un dépôt git plutôt que sur un Google Sheet comme au début ? Parce que ça me permet facilement de rendre ce projet vraiment collaboratif, notamment via des PRs (et surtout leur validation ou non).

Google Sheets, c’était bien pour commencer, quand c’était un outil perso pour m’aider à écrire mon livre, mais pour la collaboration, c’était pas viable.

Quoi de neuf dans cette v2 ?

Contributions facilitées

Le projet dispose maintenant d’un CONTRIBUTING.md qui explique comment participer.

Vous connaissez une solution qui n’est pas listée ? Vous avez repéré une erreur ? Un lien cassé ? Il vous suffit de faire une Pull Request !

De nombreuses nouvelles méthodes (j’ai pas compté mais probablement une douzaine)

Le projet est passé de 93 à plus de 100 méthodes ! J’ai continué mes explorations et ajouté une douzaine de nouvelles solutions, dont certaines que vous m’aviez suggérées.

Informations sur les licences

J’ai enrichi le tableau avec des détails sur les licences de chaque projet. C’est particulièrement important pour identifier d’un coup d’oeil si un produit est réellement open source ou si c’est une solution à licence propriétaire ou commerciale.

J’ai eu le débat avec Ludovic justement, qui voulait comprendre pourquoi je n’avais pas listé “MKE (Mirantis Kubernetes Engine)”. Je lui avais répondu à l’époque que c’était parce que je ne pouvais pas avoir accès à une version d’essai en tant que “random des Internets” sans passer par un commercial, mais l’argument n’était pas hyper solide.

Pour trouver une règle “unique” à indiquer dans le CONTRIBUTING.md, j’ai donc réintégré une partie des solutions que j’avais “censurées”.

While the heart of the cloud native ecosystem is open source, both open source and closed source (proprietary) tools are accepted in this list. What matters is whether the tool helps deploy Kubernetes clusters, not its licensing model.

Nombreuses références externes

J’ai fait un important travail sur la partie “références externes”. L’idée du répo, au delà de juste fournir une liste à la prévert, est de référencer des articles de tiers indiquant comment mettre en place ces solutions et bénéficier des retours d’expérience de la communauté.

Dans l’idée de rendre le projet plus international (ça sera tout aussi utile aux anglophones qu’aux petits frenchies de ma communauté), j’ai récupéré en priorité des liens en anglais, pour le plus de solutions possibles de cette liste. Il en reste encore qui n’en ont pas, mais ça progresse.

Note importante : au-delà de la documentation officielle (qui existe très souvent pour la grande majorité des projets), j’ai en priorité voulu recenser :

Des tutoriels de qualité de la communauté
Des articles de blog détaillés
Des retours d’expérience concrets

Un projet toujours sous CC BY-SA 4.0

Le contenu reste sous licence CC BY-SA 4.0 (Attribution - Share Alike).

Cela signifie que vous êtes libre de :

Partager : copier et redistribuer le contenu
Adapter : remixer, transformer et créer à partir de ce matériel

Sous les conditions suivantes :

Attribution : vous devez créditer le projet
Partage dans les mêmes conditions : si vous adaptez le contenu, vous devez le distribuer sous la même licence

Comment contribuer ?

C’est simple :

Forkez le dépôt 101-ways-to-deploy-kubernetes
Ajoutez ou modifiez le contenu (en suivant le format du tableau)
Soumettez une Pull Request

Lisez le CONTRIBUTING.md pour plus de détails sur le processus et les bonnes pratiques.

Toutes les contributions sont les bienvenues : nouvelles entrées, corrections, enrichissements, suggestions…

Et la suite ?

Le projet va continuer à évoluer au fil des découvertes et de vos contributions.

Je continue aussi à explorer de nouvelles solutions et à enrichir les informations existantes. Et qui sait, peut-être qu’on dépassera les 150 méthodes d’ici la fin de l’année ? 😄

C’est le moment où je fais mon influenceur et que je vous demande de ne pas hésiter à :

Star le projet sur Github si vous le trouvez utile ⭐⭐⭐
Contribuer en ajoutant vos découvertes
Partager autour de vous si vous le trouvez utile

Rendez-vous sur github.com/zwindler/101-ways-to-deploy-kubernetes !

93 façons de déployer Kubernetes : j'ai recensé (presque) toutes les méthodes existantes

Sun, 02 Nov 2025 18:00:00 +0200

Un projet documentaire un peu fou

Quand j’ai commencé à écrire mon livre “Kubernetes : 50 solutions pour les postes de développement et les clusters de production”, je me suis rapidement rendu compte d’un problème : il existe une infinité de façons de déployer Kubernetes.

Bon, pas littéralement une infinité, mais quand même… beaucoup. Trop ?

Pour structurer mon livre et choisir quelles solutions j’allais couvrir, j’ai fait ce que tout bon nerd ferait : j’ai créé un tableau.

Un très grand tableau.

Un Google Sheet qui recense actuellement 93 méthodes différentes pour déployer Kubernetes. Comme je n’aime pas “gâcher”, je le partage avec vous aujourd’hui en CC BY-SA 4.0 (Attribution - Share Alike) :

93 façons de déployer Kubernetes

Que contient ce tableau ?

Le tableau est structuré avec plusieurs colonnes pour vous aider à naviguer dans cette jungle :

Nom du produit (et éditeur quand c’est intéressant)
URL du produit : j’ai essayé de restreindre aux produits open source (ou aux services managés publics) même s’il y a quelques exceptions
Type de solution (j’y reviendrai)
“Basé sur” : là, c’est un truc assez rigolo… beaucoup de projets sont des surcouches de kubeadm, k3s ou k0s. Tous ne le disent pas ouvertement, et je m’en suis rendu compte en les essayant

Et peut-être un peu moins intéressant (peut-être que ça disparaîtra)

Est-ce que j’en parle dans mon livre ?
Est-ce que j’en parle sur mon blog ?

Les différentes catégories d’outils

Pour structurer d’abord ma pensée, et ensuite mon livre, j’ai essayé de classer ces méthodes en catégories.

Certaines sont assez évidentes (une offre managée, on voit tout de suite de quoi il s’agit), d’autres, un peu plus personnelles (et donc discutables).

Kubernetes sur desktop (Local Development)

Les outils pour développer en local sur votre machine. On parle ici des Minikube, kind et autres Docker Desktop

Infrastructure as Code (IaC)

Les outils qui vous permettent de décrire le déploiement de Kubernetes via du code (opentofu, crossplane, pulumi…)

Kubernetes in Kubernetes

Parce que pourquoi faire simple quand on peut faire… recursif ? 🤯. Ca se limite pour l’instant à vCluster et k3k.

OS spécialisés

Des systèmes d’exploitation conçus spécifiquement pour faire tourner Kubernetes. Je pense bien sûr à Talos Linux, mais pas que ;-P.

Kubernetes managés (les offres cloud clés en main)

Pas besoin de faire un dessin, on pense direct à la triplette EKS / AKS / GKE, mais aussi aux solutions françaises (OVHcloud Managed Kubernetes, bientôt Clever Cloud :smirk:)

Plateformes de management de clusters

Là, c’est une catégorie un peu à part, qui vont nous permettre de gérer plein de clusters Kubernetes et même de générer de nouveaux clusters gérés par des clusters… Souvent des bonnes usines à gaz comme Gardener ou pire Kubermatic Kubernetes Platform. On a quand même des trucs un peu plus funs comme Kamaji.

Outils d’automatisation pour self-hosted

Les solutions qui automatisent le déploiement sur vos propres machines, comme kubeadm, k3s et k0s (la triplette, base d’à peu près 50% des autres solutions du marché).

La révélation : tout le monde copie sur son voisin

En remplissant ce tableau, j’ai découvert quelque chose de marrant : une grande majorité des outils ne réinventent pas la roue.

Beaucoup de projets sont en fait des surcouches ou des wrappers autour de trois solutions de base que je cite juste avant (kubeadm, k3s et k0s). Et parfois, on a aussi des surcouches de solutions un peu plus confidentielles.

L’info n’est pas toujours disponible, j’ai parfois découvert ça au détour d’un blogpost, ou même en allant fouiller les entrailles de la solution.

C’est typiquement le genre de colonne intéressante pour bien se rendre compte qu’au delà de l’apparente diversité de ces solutions de déploiement, il y a en fait un gros standard et quelques variations.

J’espère réussir à dénicher plus d’indices similaires pour remplir encore un peu plus cette colonne :).

Un document vivant

Ce tableau n’est pas figé. Le nombre d’outils évolue régulièrement (j’en découvre de nouveaux presque chaque semaine).

Si vous connaissez une méthode qui n’est pas listée, n’hésitez pas à commenter sur les réseaux.

Note : je rappelle que je vise en priorité les solutions open source ou services managés publics (je viens de virer Mirantis Kubernetes Engine pour cette raison).

Et sinon, il me reste quoi à tester ?

J’ai déjà teasé sur les réseaux sociaux fréquentables, dans la liste des trucs que je n’ai pas encore testé mais qui pourraient me motiver, il y a :

Marp : présentations rapides et jolies avec Markdown

Mon, 13 Sep 2021 06:05:00 +0000

J’ai remplacé Powerpoint par Marp en 2019

Pendant des années, j’ai rédigé mes présentations professionnelles avec Powerpoint. J’étais un utilisateur correct de la suite Office en général (pas un roxxor, mais à l’aise).

Et là, c’est le drame, j’ai (enfin !) pu passer sous Linux sur ma machine pro. Ma vie est devenue tellement plus simple pour toutes mes tâches quotidiennes… SAUF… la rédaction de présentations.

J’ai vraiment pesté en passant à Libre Office. Je ne vais pas tacler ce dernier, beaucoup de la difficulté réside dans les formats ultras verrouillés de MS et le reverse engineering doit être horriblement complexe. J’ai donc commencé à chercher des alternatives.

It’s time to Duel…

J’ai donc demandé à mes petits collègues et copains speakers autour de moi ce qu’ils utilisaient comme moteur pour leurs présentations.

Grosso modo, les nerds m’ont répondu qu’ils n’avaient jamais quitté LaTeX et que pour les présentations ils utilisaient simplement Beamer, et les autres m’ont répondu Ascii doctor.

Pour la première, c’est une bonne alternative si vous n’êtes pas allergiques à la syntaxe de LaTeX (c’est mon cas). D’autant plus qu’on avait pas à l’époque d’aperçu en temps réel du code LaTeX (je ne sais pas si c’est toujours le cas) et qu’un néophyte passe beaucoup de temps à juste corriger les erreurs de syntaxe et de mise en page…

La seconde alternative est intéressante aussi. La syntaxe est plus digeste (je trouve) que LaTeX, il existe des éditeurs de texte capable de montrer un aperçu en temps réel du rendu final, et les formats d’export natifs incluent HTML 5, les manpages, les PDFs et ebooks,… bref, à peu près tout type de format récent qui peuvent intéresser un ingénieur en informatique qui partage quotidiennement sa connaissance. Sauf que la syntaxe d’AsciiDoctor est proche de celle de Markdown (au moins dans la philosophie) et pour avoir jonglé quelque temps entre les deux, il est facile de se prendre les pieds dans le tapis.

Or, j’utilisais déjà Markdown pour la rédaction de documentations de projets hébergés sur gitlab et accessoirement, pour rédiger une partie des articles de ce blog. Pour éviter mon auto-confusion et capitaliser sur mon habitude de Markdown, j’ai donc cherché une alternative à AsciiDoctor pour les présentations, mais en Markdown !

Entre alors Marp

Heureusement pour moi, j’ai trouvé très rapidement l’outil que je cherchais, et il s’appelle Marp. Pour être parfaitement précis, Marp est une collection d’outils open source (Marpit, Marp Core, Marp CLI, Marp for VSCode).

Ce que vous avez besoin de retenir c’est qu’en tant qu’utilisateur, vous n’aurez besoin que de Marp CLI si vous voulez générer vos decks de slides en ligne de commande. Un des gros intérêts de la CLI par rapport à une interface graphique est qu’elle va vous permettre d’automatiser la génération de vos decks de slide très facilement.

D’ailleurs, si ça vous intéresse, il se retrouve que Rémi Verchère a fait un article là-dessus il y a très peu de temps sur le compte Medium de LinkByNet : Making slides from anywhere for anyone using Marp, GitLab Pages and Gitpod.

Si en revanche vous préférez rédiger comme moi dans votre éditeur de texte et voir en live le support prendre forme, il existe donc aussi une extension VSCode pour Marp.

Comment ça marche ?

Grosso modo, Marp vient étendre le Markdown classique pour y ajouter :

La commande marp: true pour indiquer qu’il s’agit d’un document Marp et pas Markdown et une balise --- pour indiquer les nouvelles slides
des styles de slides et des thèmes customizables en CSS
un logiciel pour transformer le code Markdown en PDF ou HTML

Si vous êtes déjà à l’aise avec Markdown, vous remarquez donc que la prise en main est extrêmement simple. Finalement, si vous avez déjà un document Markdown, vous pouvez juste le transformer en présentation en ajoutant régulièrement des --- entre les paragraphes (j’exagère, mais vous voyez l’idée).

Et ce que j’apprécie particulièrement avec la preview Markdown, c’est qu’on a un visuel en temps réel de notre future documentation/présentation à partir de notre code.

Les styles

Out of the box, Marp propose 3 thèmes, qu’il est possible d’inverser (clair/sombre). La documentation sur ces thèmes est disponible ici.

En début de document, on indique qu’il ne s’agit pas d’un simple fichier Markdown, mais d’une présentation Marp de la façon suivante :

---
marp: true
theme: gaia
markdown.marp.enableHtml: true
paginate: true

Dans cet exemple, j’ai donc utilisé le thème Gaia, autorisé l’injection de HTML « perso » au milieu du code Markdown (on en reparlera) et ajouté le petit chiffre en fin de chaque slide avec « paginate: true ».

Bon… par défaut, c’est assez vite limité et pas super joli…

J’ai tout de suite voulu trouver d’autres thèmes (je n’en ai pas trouvé) et la documentation pour créer son propre thème est assez obscure.

Donc j’ai voulu customiser le mien, mais là aussi, la partie documentation sur la customisation/modification de thèmes existants est un peu légère, surtout si vous avez tout oublié en CSS comme moi.

Note: La documentation peu claire, c’est quasiment le seul reproche que je fais au projet Marp, tant j’en suis content. D’ailleurs, les développeurs de Marp travaillent à refaire la doc.

Grosso modo, la partie thème est gérée dans la partie « framework Marpit » (donc la partie la plus bas niveau du projet Marp). Vous trouverez ici la partie « customisation » via CSS Theme CSS (marp.app).

Ma personnalisation à moi

Je ne vais donc pas vous cacher mes petits secrets de speaker, je me suis donc fait un thème « par défaut » que j’utilise pour toutes mes conférences en tant que speaker et mes présentations internes (quand elles n’ont pas « besoin » du thème corporate).

En tout début de chaque deck, avant la première slide et après la partie Marp pure, j’ajoute ceci :

<style>
section {
background-color: #fefefe;
color: #333;
}
img[alt~="center"] {
display: block;
margin: 0 auto;
}
blockquote {
background: #ffedcc;
border-left: 10px solid #d1bf9d;
margin: 1.5em 10px;
padding: 0.5em 10px;
}
blockquote:before{
content: unset;
}
blockquote:after{
content: unset;
}
</style>

Le premier bloc change la couleur du fond des slides.
Le second me permet d’ajouter un paramètre « center » dans les images en Markdown pour la centrer (souvent très pratique quand on fait un peu de mise en page pour faire joli).
Les derniers me permettent de customiser l’apparence des blocs de « quotes ».

Ajouter des vidéos, du JS, etc

Si vous avez tout bien lu, vous vous souvenez peut-être que j’ai dit qu’on allait ajouter une option markdown.marp.enableHtml: true dans en début de fichier.

Ça va nous permettre de rajouter des bidouilles en HTML pour étendre un peu le Markdown et réaliser les 2-3% qui ne sont pas couverts par le langage.

Je l’utilise notamment de temps en temps pour rajouter un sauf de ligne pour faciliter la lecture, mais aussi lorsque j’ai besoin d’intégrer une vidéo dans un support.

Dans ce cas-là, j’ajoute la balise HTML suivante :

<div id=video><video controls="controls" width="800" src="binaries/microsoft_dance.mp4"></video></div>

Un exemple

Je ne vais pas continuer plus longtemps la liste des features de Marp, mais si vous voulez un exemple, j’ai mis à disposition le code Markdown ma conférence « Ciel ! Mon Kubernetes mine des Bitcoins ! »

Have fun !