Comment j'ai créé un README de profil GitHub qui ne devrait pas exister (mais qui le fait)
Cette traduction a été générée par une IA générative à l'aide de la traduction continue Action. →
Chaque grande histoire commence par un problème, et le mien était simple : le README de mon 
profil GitHub était un vrai bazar. Il était long. Il y avait trop de texte. Il débordait de badges — tellement que ça ressemblait à une collection de trophées internet. Hackathons, contributions GitHub, Astro, roadmap.sh — s’il existait un badge, je l’avais.
Au début, je pensais que c’était bien. Ça montrait tout sur moi, non ? Mais un jour, je l’ai regardé et j’ai réalisé :
Ce n’est pas stylé. C’est un désastre encombré.
J’avais besoin de quelque chose de nouveau. De quelque chose de propre. De quelque chose de visuellement frappant. Je voulais une grille Bento qui inciterait les gens à s’arrêter et à l’admirer, plutôt que de défiler dans la confusion. Un design si bien exécuté que toute personne qui le verrait voudrait instantanément le sien.
C’était le rêve. Maintenant, je devais juste le réaliser.
La première étape était simple : modéliser mon profil parfait en HTML et CSS. Et laissez-moi vous dire, c’était incroyable. Il avait une mise en page parfaite, des animations fluides et juste le bon équilibre entre contenu et espace. Puis la réalité m’a rattrapé. Il fallait que cela fonctionne dans le Markdown au format GitHub. Pas de problème, non ? Markdown prend en charge le HTML ! Alors j’ai copié mon magnifique HTML dans mon README et j’ai enregistré.
GitHub : Absolument pas.
Le Markdown de GitHub supprime un certain nombre d’étiquettes HTML, mais des étiquettes importantes. Des raisons de sécurité, bien sûr (et je respecte totalement cela, GitHub, vraiment ❤️), mais cela signifiait que mon design parfait était complètement inutilisable.
J’ai essayé de l’ajuster. De remplacer les étiquettes non prises en charge par celles qui fonctionnaient. Peut-être que je pouvais en sauver une partie ? Non. Les limitations du Markdown signifiaient que ma mise en page idéale était impossible.
En cas de doute, automatisez. Si je ne pouvais pas insérer directement mon HTML, peut-être que je pouvais générer quelque chose de dynamique avec un script ? Alors j’ai bricolé un script Python pour récupérer mon dernier dépôt GitHub et l’insérer dans mon README. Je laisse juste ces octets aléatoires que certains appelleraient du code Python ici :
22 collapsed lines
import requests
github_username = "yourusername"repos_url = f"https://api.github.com/users/{github_username}/repos?sort=pushed"
response = requests.get(repos_url)repos = response.json()
latest_repo = repos[0]["name"] if repos else "No repositories found."
with open("README.md", "r") as file: readme_content = file.readlines()
new_content = []for line in readme_content: if "<!--LATEST_REPO-->" in line: new_content.append(f"- Latest Repo: [{latest_repo}](https://github.com/{github_username}/{latest_repo})\n") else: new_content.append(line)
with open("README.md", "w") as file: file.writelines(new_content)Cela semblait être un pas dans la bonne direction. C’était automatisé. C’était fonctionnel. Mais cela ne résolvait pas mon problème principal. 😢
Il ne s’agissait pas de contenu dynamique — il s’agissait de design. Et aucun script Python ne rendrait le Markdown beau.
À ce stade, j’étais désespéré. J’ai envisagé l’impensable : il suffit de prendre une capture d’écran du HTML et de la mettre dans mon README en tant qu’image. C’était une approche brutale. C’était paresseux. C’était… efficace ?
Pendant un instant, j’ai vraiment pensé à le faire. Mais je savais au fond de moi que je ne me pardonnerais jamais si je laissais cela être ma solution finale.
À titre de référence, j’aurais utilisé Puppeteer et FFmpeg — je n’ai aucune idée de ce que sont ces outils.
J’ai abandonné le plan maudit de la capture d’écran et cherché quelque chose de plus flexible.
Les SVG.
Les SVG sont évolutifs, prennent en charge à la fois le texte et les images, et — plus important encore — ils peuvent intégrer du HTML à l’intérieur.
Alors j’ai essayé quelque chose comme ceci :
<svg width="800" height="400" xmlns="http://www.w3.org/2000/svg"> <foreignObject width="100%" height="100%"> <body xmlns="http://www.w3.org/1999/xhtml"> <h1>Hello from HTML inside SVG!</h1> </body> </foreignObject></svg>Prometteur ! Cela pourrait vraiment fonctionner !
Puis j’ai été occupé par d’autres choses, j’ai oublié de le déboguer, et je n’y suis jamais retourné.
Quand je suis revenu sur le projet, j’étais déterminé à le faire fonctionner.
Je me suis rendu compte que si je ne pouvais pas intégrer directement du HTML dans le Markdown, je pouvais feindre en utilisant des SVG imbriqués. (au fait, ceci est massivement simplifié ; le processus réel a pris des jours qui semblaient être des semaines, voire des mois, mais je sais que vous ne liriez tout de même rien de tout cela alors peu importe.)
Et puis, après des heures de recherche, je suis tombé sur une réponse révolutionnaire sur Stack Overflow :
https://stackoverflow.com/a/65049620/22573601
Cela m’a conduit à la solution actuelle :
- Convertir ma mise en page HTML en SVG.
- Encoder toutes les images en Base64 (parce que le Markdown de GitHub ne chargera pas les images externes à l’intérieur d’un SVG contenant du HTML).
- Inclure des SVG dynamiques (comme mes statistiques GitHub, mon statut Spotify, etc.).
- Tout automatiser avec GitHub Actions.
- Une mise en page en grille Bento élégante, parfaitement structurée en SVG.
- Un statut Spotify mis à jour en temps réel, inclus en SVG.
- Des statistiques GitHub, insérées dynamiquement via l’automatisation.
- Entièrement responsive, entièrement évolutif et absolument fou à construire.
Il se met à jour toutes les 5 minutes, fonctionne entièrement avec GitHub Actions, et ne dépend d’aucun service externe. C’est magnifique. C’est efficace. Et surtout, c’est techniquement absurde dans le meilleur des cas.
Jetez un œil à un exemple concret du résultat final à un certain point dans le temps.
Ce n’est pas si mal comparé à l’ancien README.md. Et ne commentez pas pourquoi j’écoute de la K-pop ! C’est mieux que vous ne le pensez, faites-moi confiance.
Consultez la version en direct sur mon GitHub trueberryless — si j’ai décidé de la garder… — et laissez un follow si vous y êtes déjà et avez apprécié cette lecture ! ❤️
Absolument.
Ce parcours fut frustrant, chronophage, et rempli de plus d’obstacles que je ne l’aurais jamais imaginé. Mais j’ai appris tellement de choses sur les SVG, les limitations du Markdown, GitHub Actions et l’automatisation en cours de route.
Est-ce que je le referais ? Définitivement.
Est-ce que je le recommanderais ? Seulement si vous avez une patience infinie. 😅
Mais au final, j’ai créé un README de profil GitHub qui ne devrait pas exister — mais il existe. Et je l’adore.