Il a réécrit son serveur web, et le langage qui va avec

Descendez tout en bas de kmx.io. Sous le copyright, il y a une ligne que presque aucun site ne montre : le nom du logiciel qui vous a servi la page.

Ce n’est ni Apache, ni nginx, ni un runtime PaaS. C’est le serveur HTTP de Thomas de Grivel, écrit par lui, dans un langage de programmation qu’il a écrit aussi.

En 2026, c’est soit de la folie, soit la seule position cohérente. Je penche pour la deuxième, et je vais expliquer pourquoi.

Thomas de Grivel dirige kmx.io, société française de software hosting and development, active depuis 2020. Le résumé du site tient en une ligne : « boundary checks and perfectly sized allocations ». Traduction pour les gens normaux : il passe ses journées dans les endroits où les programmes se trompent de taille et de frontière, c’est à dire là où naissent les failles.

Concrètement, deux activités :

• Hébergement sur serveurs dédiés, OpenBSD, nginx, colocation. À partir de 200 € par mois, chiffré au projet.
• Développement commercial et open source, pour BSD, Linux, Windows, macOS et Android. Sites en KC3 ou Ruby on Rails, applications à plus gros volume en Elixir et Phoenix.

Sa pile personnelle : C, Common Lisp, Ruby, Elixir, Erlang, et OpenBSD partout.

Le site ressemble à ça. Vert sur noir, monospace, un compteur de vues affiché sans complexe. Rien sur cette page qui ne serve à quelque chose.

Sur sa page hébergement, l’argument est posé sans détour : du matériel dédié plutôt que des machines virtuelles, parce que moins de complexité veut dire moins de bugs et moins d’exploits.

Ça a l’air d’une évidence. En pratique, presque personne ne le fait, parce que la complexité, on ne la voit pas : elle est répartie sur des factures, des tableaux de bord et des couches qui appartiennent à quelqu’un d’autre.

Posez la question autrement. Entre le code que vous écrivez et le métal qui l’exécute, combien de couches ?

Sept d’un côté, deux de l’autre. Cet écart est une facture. Vous la payez en latence, en abonnements, en temps d’infogérance, et surtout en pannes que vous ne savez pas diagnostiquer parce que la couche fautive n’est pas chez vous.

Je vois passer les dégâts toute l’année, côté sinistres. Une part des interventions ne portent pas sur un site mal codé, mais sur un empilement que plus personne dans l’équipe ne comprend en entier.

J’en ai raconté un cas en détail il y a trois jours, et il n’a rien à voir avec l’hébergement : six étages d’empaquetage Windows où chaque étage ment à celui du dessus, au point que le message d’erreur affiché désigne un coupable qui n’existe pas. Le mécanisme est le même partout. Plus il y a de couches, plus la panne est loin de l’endroit où elle se voit.

Il reste des raisons parfaitement valables de prendre du cloud managé, et je continue d’en installer. Mais le choix par défaut mérite d’être discuté, et il ne l’est plus.

C’est ma première question, et je m’attendais à un argument de sécurité. Il y en a un, mais ce n’est pas celui qui pèse le plus.

Leur page sur la sécurité est effectivement éclairante, et elle n’est pas traduite en français. L’idée tient en deux gestes : auditer le code avant qu’un bug ne devienne une faille, et rendre les catégories entières d’attaques impossibles plutôt que de corriger les cas un par un.

Il en donne une deuxième.

Il cite OpenNTPd, OpenSSH, httpd, unwind, et LibreSSL, le fork d’OpenSSL né après Heartbleed. La page innovations en aligne beaucoup d’autres.

Regardez la liste une seconde fois. Si vous administrez un serveur Linux, vous vous connectez dessus avec un logiciel écrit par ces gens là. Choisir OpenBSD, dans cette logique, c’est se placer là où les briques que tout le monde utilisera dans cinq ans sont en train de s’écrire.

Il ajoute un projet en cours :

Là où ça devient rare, c’est l’étendue. La plupart des gens qui tiennent ce discours l’appliquent à une couche ou deux. Lui remonte la pile presque en entier.

Quatre briques sur sept sortent de chez lui :

• kc3_httpd, son serveur HTTP applicatif. Il tourne derrière nginx, qui garde le rôle de frontal HTTPS. Le nom et la version sont affichés en pied de page, ce que presque aucun hébergeur ne fait : vous savez ce qui vous répond.
• libkc3, le cœur du langage KC3, écrit en C11 pur.
• kmxgit, sa forge git auto hébergée, sur OpenBSD, disques NVMe en RAID1, certificats renouvelés tout seuls.
• Ses serveurs DNS, migrés vers nsd(8) et unwind(8) en août 2026. Il l’a raconté sur son blog les 19 et 20 août. Plus de résolveur tiers dans la chaîne.

Ce qu’il n’a pas écrit, il le finance : kmx.io verse un don mensuel au projet OpenBSD. C’est cohérent avec le reste. Quand on construit sur une brique amont, on la paie.

Petite vérification faite en écrivant cet article, parce que je n’aime pas répéter ce qu’on me dit :

nginx répond bien en frontal sur kmx.io, git.kmx.io et kc3-lang.org. kc3_httpd est derrière. Il n’a donc pas remplacé nginx, il a écrit ce qui vient après, ce qui est à la fois moins spectaculaire et beaucoup plus utile.

Je lui ai posé la question directement, parce qu’une vérification depuis l’extérieur ne dit jamais l’intention. Sa réponse ferme le sujet :

Personne ici ne prétend remplacer nginx sur le port 443. Il a écrit la couche qui exécute l’application, et il laisse à nginx ce que nginx fait bien.

Deuxième question. J’attendais le récit d’un chantier héroïque. La réponse est presque décevante :

Le coût est ailleurs. Le serveur HTTP est la partie facile, la dépense c’était le langage, et elle était déjà payée. C’est la logique des gens qui construisent des outils plutôt que des produits : le premier chantier est énorme, tous les suivants deviennent bon marché.

Reste le pourquoi. Sa réponse tient en une phrase :

Deux mots à retenir. Instrumenter, c’est à dire savoir ce qui se passe à l’intérieur, mesurer, tracer, intervenir. Linker, c’est à dire faire entrer son propre code dans le serveur lui même, sans passer par une interface qui recopie des requêtes d’un processus à l’autre. Quiconque a déjà essayé de comprendre pourquoi une page est lente à travers un frontal, un gestionnaire de processus PHP et un cache d’objets sait exactement ce qu’il achète là.

Troisième question, la plus bête et celle à laquelle je tenais le plus : la première fois qu’une page est sortie de son propre serveur, ça faisait quoi ?

Le type qui sert aujourd’hui son site, sa forge git et ceux de ses clients avec son propre logiciel vous dit que rien ne marchait bien au début. Gardez le en tête la prochaine fois qu’un projet vous paraît hors de portée.

Et une ligne plus loin :

Des années de développement et pas de grande réécriture. C’est rare au point d’être suspect. Quand la couche du dessous est à vous, personne d’autre ne peut vous obliger à tout jeter parce qu’il a changé d’avis.

Le moment de bascule arrive plus tard :

La première page servie prouve que le serveur répond. Les pages applicatives prouvent que la pile entière tient debout : le langage, le serveur, le C en dessous, et les trois qui se parlent sans colle.

Il ne s’est pas arrêté aux trois questions. Il a donné ses mesures, sa projection, et le mur sur lequel il bute. Je les sépare, parce que ces trois là n’ont pas la même valeur de preuve.

Dix millisecondes pour une page générée par un interpréteur, c’est bon. Pour donner une échelle, l’audit technique que j’ai fait de son site la semaine dernière mesurait, depuis l’extérieur, une médiane de 82 ms de temps de réponse serveur. Ces 82 ms contiennent le réseau, la poignée de main TLS et nginx. Les 10 ms sont ce que coûte l’application à l’intérieur. Le reste du budget part ailleurs, et son vrai problème de vitesse n’est d’ailleurs pas là : ce sont ses 3,3 Mo par page servis sans compression, un réglage de serveur, pas un défaut de conception.

Là on quitte la mesure pour l’arithmétique, et il le sait. Un facteur dix par la réécriture en C, multiplié par les cœurs d’une machine sérieuse. Je le cite parce que c’est son horizon, pas parce que c’est un chiffre à opposer à un concurrent. Aucune de ces deux multiplications n’est acquise.

Traduction pour ceux que le vocabulaire arrête. Sa base de données est protégée par un verrou unique : pendant qu’un fil d’exécution écrit, tous les autres patientent. Tant que ce verrou reste global, ajouter des cœurs ne sert plus à grand chose au delà d’un certain point, puisque tout le monde finit par attendre au même endroit. C’est exactement ce qui empêche la multiplication par 32 d’être une multiplication par 32.

La solution qu’il voit, et la phrase que j’ai failli couper :

Un développeur ordinaire aurait annoncé la fonctionnalité pour la prochaine version. Lui donne le nom du problème, la piste de solution, admet qu’il a atteint sa limite dessus, et constate que ça marche quand même en l’état. Je ne connais pas beaucoup d’éditeurs capables d’écrire ça sur leur propre produit.

Un verrouillage par sous-ensemble de la base est effectivement un problème de recherche, pas un ticket de sprint. Si vous êtes en thèse et que vous cherchez un sujet appliqué avec un banc d’essai réel, la place est libre, et le code est ouvert.

KC3 est un langage de programmation avec une base de données graphe intégrée dans le langage. Pas une bibliothèque à côté : le graphe contient les définitions elles mêmes.

Les traits qui le caractérisent :

• Syntaxe inspirée d’Elixir, avec filtrage par motifs et dispatch multiple.
• Macros et eval inspirés de Common Lisp.
• Interopérabilité C assumée, en style C11 via libffi.
• Le tout dans libkc3, une bibliothèque C11 pure qui contient parseur et interpréteur.
• Et ikc3, l’interface interactive, qu’il tient à ce qu’on mentionne.

Il avait raison, j’étais passé à côté. Voilà à quoi ça ressemble, dans ses propres lignes :

On tape une expression, on obtient sa valeur, on demande son type et le langage répond U8 : un entier non signé sur huit bits. Un langage de haut niveau qui vous rend une réponse de langage système, dans une boucle interactive. On voit ce qui se passe tout de suite, sans compiler un programme entier pour poser une question.

Version au moment où j’écris : 0.1.17, et le site dit lui même « a working prototype ». Pas de promesse de production, pas de levée de fonds, pas de conférence marketing. Le dépôt vit sur git.kmx.io, avec des miroirs sur GitHub et Codeberg.

Pour le reste, je ne vais pas vous paraphraser la syntaxe d’un langage que je n’ai pas écrit et que je n’utilise pas en production. Allez lire le dépôt : vous irez plus vite, et vous aurez la source.

Ce qui m’intéresse ici, c’est ce que ça dit du bonhomme. Écrire un langage, c’est un projet de dix ans. Écrire un serveur HTTP dedans, puis servir son propre site avec, puis sa forge git, c’est refuser une par une les briques que tout le monde accepte sans regarder.

Cinq billets en août 2026, dont deux sur la migration DNS et deux sur KC3. Ce n’est pas un blog d’entreprise avec un article par trimestre écrit par une agence : ce sont des notes de travail, datées, sur ce qui a été changé la veille.

C’est le meilleur test que je connaisse pour un hébergeur. Regardez ce qu’il écrit quand personne ne lui demande rien.

Autant le dire tout de suite, parce que je préfère perdre un lecteur que faire perdre 200 € par mois à quelqu’un.

Ça n’est pas pour vous si vous voulez un panneau cPanel, un installateur WordPress en un clic, un support de niveau 1 joignable le dimanche, ou un hébergement à 5 € par mois. Ce n’est pas le métier, et il ne prétend pas le contraire.

Ça peut être pour vous si vous portez une application Elixir, Ruby, Common Lisp ou C, si vous avez besoin de performances stables plutôt que de pics facturés, si votre projet a des contraintes de souveraineté ou de confidentialité, ou si vous en avez assez d’ouvrir des tickets à un fournisseur qui vous répond par un lien vers sa documentation.

Le fonctionnement est simple : vous décrivez le projet, il évalue, et après discussion vous recevez un accès SSH privé pour déployer depuis votre dépôt git. Pas de tarif au clic, pas de calculateur en ligne.

Transparence complète : Thomas est un ami, je ne touche rien sur cet article, et il n’y a aucune affiliation entre nous.

Si je le recommande, c’est pour une raison bête. Quand un client arrive avec un projet qui n’a rien à faire dans le cloud, je ne connais personne d’autre à qui l’envoyer. Et quand kmx.io a besoin d’un site plutôt que d’un serveur, c’est mon métier qui commence.

Lui le fer, moi la façade. C’est même une bonne façon de monter un projet : l’infrastructure chez quelqu’un qui l’opère vraiment, le site, le SEO et le suivi chez moi, et deux interlocuteurs qui se parlent au lieu d’un formulaire de support. Si votre projet ressemble à ça, écrivez moi, on regarde ensemble lequel de nous deux doit commencer.