Une idée qui traînait depuis longtemps

Ça faisait des années que je voulais un endroit à moi. Un site qui regroupe tout : les projets sur lesquels je bosse, les POCs que j'expérimente, les articles que j'écris, les choses que j'apprends. Un point central qui raconte ce que je fais, plutôt que des bouts éparpillés sur GitHub, itch.io, LinkedIn, et des disques durs qui prennent la poussière.

Mais comme toujours, il y avait trop de choses à faire à côté. Un jeu à développer, des clients, des projets pro, des enfants, des journées qui ne durent pas assez longtemps. À chaque fois que l'idée remontait, elle repartait dans la pile « un jour, peut-être ».

Et puis récemment, j'ai regardé en arrière. J'ai vu la quantité de projets, de prototypes, de petits outils que j'avais accumulés ces dernières années — beaucoup intéressants, presque tous oubliés dans un recoin. Je me suis dit que c'était dommage de laisser tout ça sans vie. Que ces travaux pouvaient valoir quelque chose, pas juste pour moi, mais pour les gens qui y trouveraient des idées, des réponses, ou simplement un regard différent sur un problème.

Alors j'ai décidé de dépoussiérer tout ça. De reprendre chaque projet, chaque POC, chaque expérimentation un peu abandonnée — et de les transformer en quelque chose d'utile. En source de savoir à partager. C'est ce que ce site est censé devenir : un endroit où je remets mes travaux en lumière, où je raconte ce que j'ai appris en les faisant, et où ça peut servir à d'autres.

Mais pour que ça marche, il me fallait d'abord le site lui-même. Et c'est là que ça devient intéressant.

Deux jours, zéro ligne de code

Ce site que vous êtes en train de lire n'existait pas il y a deux jours. Le domaine était acheté, l'idée était là, mais pas une seule ligne de code. Deux jours plus tard, ekioo.com est en production : 11 pages, 8 projets, un blog, un formulaire de contact, du contenu bilingue, des animations, un sitemap, des meta SEO, et du contenu exposé en markdown brut pour les agents IA.

J'ai tout construit en binôme avec Claude.

Voici comment ça s'est passé, d'un point de vue technique.

Le setup : Blazor Server, zéro template

Pas de template, pas de starter kit. J'ai démarré d'un dotnet new blazorserver vide et j'ai construit chaque brique à la main — ou plutôt, en décrivant ce que je voulais et en laissant Claude coder.

Le stack final :

  • .NET 10 avec Blazor Server
  • Markdig pour le rendu Markdown
  • YamlDotNet pour le parsing du frontmatter YAML
  • Brevo (ex-Sendinblue) pour les emails de contact
  • Vanilla JS pour l'animation de particules
  • CSS pur — pas de framework, pas de Tailwind

Le tout fait ~2 800 lignes de code (C#, Razor, CSS, JS). C'est compact, lisible, et chaque fichier a une responsabilité claire.

Le workflow avec Claude

Le rythme de travail ressemblait à ça :

  1. Je décris ce que je veux — en français, en termes de produit, pas de code. "Je veux une page projets qui liste mes projets depuis des fichiers markdown avec du frontmatter YAML."
  2. Claude explore le code existant — il lit les fichiers, comprend les patterns déjà en place, et propose une implémentation cohérente avec le reste.
  3. Il code — le composant Razor, le service C#, le CSS, et le contenu markdown.
  4. Je review et j'ajuste — parfois c'est bon du premier coup, parfois je corrige une direction.

Ce qui change par rapport à coder seul : la vitesse d'itération. Quand je dis "ajoute un système de mentions dans les commentaires avec @agent:claude", je n'ai pas à écrire le parser, le modèle, l'endpoint ET le rendu UI. Claude fait tout d'un bloc, et je peux me concentrer sur la direction du produit.

L'architecture en bref

Contenu en Markdown

Tout le contenu (blog + projets) est stocké dans des fichiers .md avec un frontmatter YAML :

---
title: "Mon article"
description: "Description SEO"
date: 2026-04-06T14:00:00+02:00
tags: ["Tag1", "Tag2"]
---

Un MarkdownService parse le YAML, convertit le body en HTML via Markdig, et retourne des modèles typés. Le système est simple et il n'y a pas de base de données pour le contenu — juste des fichiers sur disque.

Bilingue dès le départ

Chaque contenu existe en deux versions : article.md (français) et article.en.md (anglais). Le middleware de détection de langue suit trois niveaux de fallback :

  1. Query string (?lang=en)
  2. Cookie (persiste 365 jours)
  3. Header Accept-Language du navigateur

Si le navigateur n'est pas français, le site bascule automatiquement en anglais. Les traductions UI (navigation, labels, boutons) sont dans un LocalizationService avec un dictionnaire de 50+ clés.

Design system custom

Le CSS fait 923 lignes — un design system dark theme complet avec variables CSS, composants réutilisables (cards, tags, timeline, pricing), et un responsive propre. Pas de framework, pas de classes utilitaires — juste du CSS lisible avec une palette cohérente.

L'accent doré (#d6b86a) sur fond navy (#0a0a1a), c'est le genre de choix qu'on fait en 5 secondes et qui donne le ton à tout le site.

Animation de particules

Un canvas JS de 134 lignes qui dessine des particules dorées connectées entre elles. C'est subtil, ça suit la souris, ça s'adapte au DPI et au mobile, et ça survit aux navigations Blazor (qui re-rendrent le DOM). Un petit détail visuel qui fait passer le site de "template" à "identité".

Anti-spam maison

Le formulaire de contact utilise un double mécanisme :

  • Honeypot — un champ invisible que les bots remplissent
  • Token cryptographique — un checksum XOR encodé en base64 avec un timestamp. Si le formulaire est soumis en moins de 3 secondes ou plus d'une heure après le chargement, c'est rejeté.

Pas de CAPTCHA, pas de dépendance externe.

Ce qui a été fait le deuxième jour

Le premier jour, c'était la structure : layout, pages, contenu, design system. Le deuxième jour, c'était la profondeur :

  • 3 articles de blog complets (Todo, Dispatcher, ce devlog) avec versions EN
  • 3 diagrammes SVG faits à la main pour illustrer l'architecture du dispatcher
  • Une page projet Todo avec vidéo intégrée
  • Un sitemap dynamique qui lit les dates du frontmatter
  • Des meta descriptions SEO localisées sur toutes les pages
  • Un endpoint markdown brut (/content/blog/{slug}.md) pour que les agents IA puissent lire le contenu directement
  • Un second sitemap (/sitemap-content.xml) qui indexe le contenu markdown
  • Umami analytics intégré en une ligne
  • Un CLAUDE.md pour documenter les conventions du projet

Tout ça, en une journée, à deux (moi + Claude).

Les diagrammes SVG

Un point qui mérite d'être mentionné : les diagrammes de l'article sur le dispatcher sont des SVG écrits à la main — pas générés par Mermaid ou Draw.io.

Claude a produit les SVG directement dans le code, avec le design system du site (mêmes couleurs, mêmes border-radius, même police). Ça a demandé quelques itérations — le premier jet avait des flèches mal centrées et des blocs qui se chevauchaient. Mais après 2-3 corrections, les diagrammes sont propres et parfaitement intégrés visuellement.

C'est le genre de tâche que je n'aurais jamais fait manuellement pour un blog post. Trop chronophage. Avec Claude, c'est devenu raisonnable.

Ce que j'ai appris

L'agent n'est pas un générateur de code

La tentation, c'est de traiter Claude comme un copier-coller intelligent. Ce qui marche mieux, c'est de lui donner le contexte du projet, le laisser explorer le code existant, et lui décrire l'intention plutôt que l'implémentation. Il s'adapte aux patterns en place — nommage, structure, style — et produit du code cohérent.

La review reste indispensable

Claude fait des erreurs. Des champs d'API mal nommés (j'ai découvert que assignedTo n'était pas assigneeHandle quand la moitié des tickets n'ont pas été créés). Des SVG avec des flèches qui passent au-dessus des blocs. Des positions mal calculées. La review humaine corrige ces erreurs en temps réel, et l'itération est rapide.

La vitesse change la nature du travail

Quand tu peux expédier un site complet en deux jours, tu ne réfléchis plus de la même manière. Tu ne te demandes plus "est-ce que ça vaut le coup de faire cette page ?" — tu la fais. Tu ne te demandes plus "est-ce que j'ai le temps pour un sitemap ?" — tu le fais. La friction disparaît, et tu te concentres sur ce que tu veux que le produit soit.

Le résultat

~2 800 lignes de code. 11 pages. 8 projets. Blog bilingue. SEO. Analytics. Contact. Animations. Contenu markdown exposé pour les agents IA.

Deux jours.

Je ne dis pas que c'est parfait. Il y a des coins à polir, du contenu à enrichir, des features à ajouter. Mais le site est en production, il fait ce qu'il doit faire, et il a été construit à une vitesse qui aurait été impensable il y a un an.

C'est ça, travailler avec un agent.

Suivez le développement

Le site va continuer à évoluer. Si vous voulez suivre les prochains articles — ou discuter de comment j'utilise l'IA dans mes projets — rejoignez-moi sur Discord.

→ Rejoindre le Discord