Pourquoi home-ai.fr ?

Je suis maker avant d'être ingénieur. Depuis longtemps j'ai une CNC, une imprimante 3D, une graveuse laser, et une passion qui les relie toutes : les robots. J'en avais déjà fait plusieurs sous ROS, le Robot Operating System. Mon projet du moment : leur ajouter de la vision par ordinateur et un assistant IA embarqué. C'est ce projet-là — mis en pause pour construire l'outil qui le rendrait possible — qui a tout déclenché.

Je n'avais pas prévu de faire un site. Encore moins une plateforme self-host de vingt-huit services. J'avais prévu d'apprendre la vision à un robot.

D'un robot à un écosystème

Quand les premiers LLM grand public sont sortis, je les ai essayés comme tout le monde l'a fait : sur du code. Ils étaient mauvais. Mais ils s'amélioraient vite, et j'ai eu envie de tester jusqu'où je pouvais aller en m'appuyant sur eux pour reconstruire — depuis zéro — la stack logicielle dont mon robot nouvelle génération aurait besoin. ROS, c'est des milliers de briques empilées les unes sur les autres, et c'est ce monstre-là que j'ai voulu refaire à ma sauce. Très vite, je me suis retrouvé enseveli : trop de services, trop de versions, trop de scripts.

Mais c'est en parallèle qu'est venue la décision. Je découvre les serveurs MCP — un protocole qui permet à un agent IA d'appeler du code, des API, des bases de données. J'en construis un pour comprendre, je creuse les bases vectorielles, je comprends que la recherche y est sémantique, et je monte mon propre MCP autour de ma propre base de connaissances. Une fois branché, j'écris un document de vision pour le gestionnaire de projet dont j'aurais besoin, je le donne à un LLM en lui ouvrant l'accès à cette knowledge — et il code tout seul pendant des heures. Le résultat partait en vrille au bout d'un moment et il a fallu l'arrêter (les garde-fous, l'œil à la loupe et la rigueur restent indispensables), mais quelque chose s'était passé : ce que je voulais construire était devenu possible, à condition de le construire avec ces nouveaux outils.

J'ai rangé le robot. J'ai construit hub-projects. Et autour de lui, brique par brique, s'est ajouté tout ce qu'il fallait pour qu'un humain seul puisse opérer son propre écosystème : une knowledge centrale pour mes décisions, un MCP unifié pour que mes agents IA y aient accès, un cluster Kubernetes pour faire tourner tout ça à la maison, un dashboard unifié pour le piloter, un registre Docker privé pour les images, un système d'identité unique pour ne pas multiplier les mots de passe. Le robot, lui, attend toujours son retour — il aura sa place dans l'écosystème quand celui-ci sera prêt à l'accueillir.

C'est cette plateforme — née d'un détour pour fabriquer autre chose — que ce site raconte.

Qui écrit

Mon parcours s'est fait à l'envers. J'ai quitté l'école très tôt, sans le baccalauréat, et j'ai appris en démontant, en cassant, en refaisant. J'ai été tour à tour technicien informatique, gérant d'une société d'audiovisuel professionnel avec deux succursales en Afrique de l'Ouest, consultant indépendant à l'international, puis directeur technique d'une PME d'objets connectés où j'ai conçu pendant six ans une gamme de produits pour personnes sourdes et malentendantes — brevet déposé, marquage Fabriqué en France. J'y ai appris la Langue des Signes Française au passage. En chemin, j'ai monté plusieurs sociétés et gagné quelques concours, dont le premier prix de l'innovation au Concours Lépine. À 42 ans, j'ai passé un Master 2 en architecture logicielle — toujours sans avoir le baccalauréat.

Aujourd'hui je travaille pour un industriel du bâtiment français : quarante ans d'existence, une hiérarchie directe au féminin que j'admire, et une équipe que j'aime. Industriel le jour, maker la nuit.

Le fil rouge de tout ça : autodidacte, open-source par conviction, et plus à l'aise à construire mes propres outils qu'à attendre qu'on me les fournisse. C'est cette même habitude qui produit l'écosystème dont parle ce site.

Ce site est strictement personnel. Je ne vends rien ici, je ne consulte pour personne, je n'ai pas de cours à proposer. Si ça change un jour, ce sera explicite. En attendant, le contrat est simple : je raconte ce que je construis, casse ou refactore, et tu en tires ce qui te parle.

Le constat qui rend ce site nécessaire

L'écart entre ce qui est publié sur l'IA et ce qui est construit avec elle s'élargit. Les premiers font du contenu ; les seconds font de l'infra. Les premiers savent narrer ; les seconds savent débugger un PVC pinné sur le mauvais node.

J'appartiens au second groupe, et la voix manque en français. Les sujets qui m'occupent réellement — quels modèles je fais tourner en local et lesquels je délègue, pourquoi mon agent n'invente plus de fonctions qui n'existent pas, comment je passe d'un docker-compose sur ma machine à un cluster qui se redéploie tout seul, ce que ça coûte vraiment en temps et en argent — n'ont presque pas d'écho dans notre langue. C'est cet angle mort que j'écris.

Ce qui distingue ici

Un écosystème self-host, opéré comme une PME, par une personne.

Aujourd'hui, vingt-six services tournent sur un cluster k3s à la maison ; d'autres sont en chantier. hub-tree cartographie l'architecture. knowledge-api stocke les règles et les décisions. mcp-unified les expose à mes agents IA. harbor stocke les images. sonarqube vérifie la qualité. hub-n8n orchestre les workflows. ledger suit mes frais. memories enregistre mes journaux audio. Chacun des autres a sa raison d'être.

Chaque service a son repo, son chart Helm, son cycle CI/CD. Tous parlent à tous via une couche commune. Et le tout, ce site compris, est administré depuis un dashboard unifié qui tourne lui-même dans le cluster.

Ce n'est pas une démo ; c'est ce que j'utilise au quotidien. La distinction n'est pas anodine. Une démo dort dans un dépôt et bit-rotte. Une infra qu'on opère se réveille tous les matins, casse parfois, et oblige à apprendre les détails qu'aucun tutoriel ne mentionne.

La promesse

Chaque article publié ici démontrera quelque chose qui tourne. Pas un Hello World. Pas une preuve de concept jetable. Un morceau de l'écosystème, expliqué dans son état réel, avec ses contraintes, ses dépendances et ses chiffres.

Le site lui-même est la première de ces démonstrations. Il s'appelle hub-www, il vit dans le même cluster que les autres services, il a son chart Helm OCI dans harbor, il est exposé via le même reverse proxy que tout le reste. Quand quelque chose ne tourne pas rond ailleurs dans l'écosystème, ce site le sait — plus tard, tu pourras voir l'état de chaque service en temps réel sur la page Stack.

Considère donc chaque article comme un audit ouvert. La couture est apparente. Si je dis qu'une migration prend deux jours, c'est qu'elle a pris deux jours dans Git ; tu peux vérifier. Si je décris un pattern, c'est un pattern qui produit du code en ce moment même.

Quatre piliers

Le contenu se range en quatre catégories.

Méthode — comment je travaille avec l'IA en 2026. Quels agents, quels prompts, quelles règles, quelles architectures de connaissance. Pourquoi mon assistant a accès à un MCP avant d'avoir accès à mon clavier.

Architecture — choix techniques expliqués et chiffrés. Pourquoi un seul cluster Kubernetes. Pourquoi pas de Cloudflare. Pourquoi un chart Helm OCI plutôt qu'un manifeste central. À chaque fois, les arbitrages.

Produits — les services qui sont aussi des produits réels. memories qui m'écoute parler. ledger qui suit mes frais. Ce que j'ai compris en les concevant pour moi avant de les concevoir pour d'autres.

Coulisses — ce qui coûte vraiment. Les pannes, les pertes, les renoncements. Les factures. Le temps que j'ai cru gagner et que j'ai en fait perdu. Les décisions que je regrette.

Ce sont des piliers, pas des cases hermétiques ; certains articles tomberont entre deux.

Le rythme

Un article par semaine, le lundi matin. Pas de notification, pas de pop-up. Tu peux t'abonner à la newsletter ou au flux RSS si tu veux le recevoir ; sinon le site reste consultable comme une archive ouverte.

À très vite.

— Damien