🇬🇧 Looking for the English version? Click here

✍️ 100% humain, rédigé par moi-même, sans IA. Je pense ce que j'écris.

💻 Je suis actuellement ouverts aux propositions d'entreprise (cofondation, CDI, freelance...)

Je suis ingénieur/architecte logiciel/web, focalisé sur l'utilisation de la programmation fonctionnelle pure (FP), pour déjouer les contraintes du monde réel, exprimer un métier avec un haut degré de précision, et concevoir des systèmes qui structurent suffisamment l'espace de recherche pour que les humains comme les IA convergent naturellement vers les bonnes solutions. Dit comme cela, cela peut légitimement sonner comme de simples formules magiques ou générales, mais je souhaite par ce profil indiquer pourquoi, et comment.

J'ai d'abord accumulé de l'expérience via le prisme de la programmation orientée-objet (OOP), avec des langages courants comme C/C++, PHP, TypeScript (et leurs frameworks : Symfony, Next, Nest, etc.)... mais j'ai toujours gardé une main sur la FP en parallèle. Avec les années, j'ai fini par rencontrer un certain nombre de limites fondamentales en OOP, indépendantes de ma volonté. Elles m'ont poussé à tourner la page, et à sacrifier une partie de mes connaissances, afin de me projeter vers l'un des mouvements tectoniques les plus profonds de l'industrie actuelle (OOP → hybrid FP style → FP), toujours en cours (e.g. ici chez IBM, là grâce à Unspash, les fortes influences sur Rust à Mozilla avec les traits/impl/iterators/etc, ...).

Pour autant, je suis très conscient des technologies encore à l'œuvre aujourd'hui dans l'industrie. C'est d'ailleurs ce qui m'a rendu Language-Agnostic : ce qui compte n'est plus véritablement tel ou tel langage, en tant que tel, mais le runtime qu'il embarque avec lui, et que l'on peut mettre à profit. Dit autrement, je m'intéresse tout autant à Go, qu'à Rust, qu'à TypeScript/JavaScript, PHP, Roc, OCaml, Python... et c'est sans fin ! Chaque langage a des forces et des faiblesses : il s'agit d'activer les forces (e.g. résilience, vitesse, portabilité...) au bon moment, au bon endroit. En tant que langages couramment utilisés, ils ont été testés et éprouvés au contact du réel, et servent donc de plateforme parfaite pour l'exécution des programmes. Des centaines de milliers d'ingénieurs ont résolu des bugs à leur sujet. On peut donc opérer la chose suivante : écrire le code dans un autre langage, pourvu que ce dernier soit suffisamment abstrait, afin d'être complètement libres d'exprimer les idées les plus techniques et scientifiques qui soient, et ensuite, compiler (i.e. transformer le code) vers tous ces langages. On obtient ainsi le meilleur des deux mondes : un langage pensé pour son expressivité, donnant de profondes possibilités, couplé aux runtimes de langages de terrain, fiables et efficaces, qui exécutent les idées exprimées dans le premier.

Ma philosophie est donc mésomorphique, hybride, à l'image de nos écrans modernes (i.e. à cristaux liquides) : langage primaire et code solides, précis, structurés, concis et vérifiables (par la machine) ; mais runtime, code et langages secondaires liquides, flexibles et adaptables, prenant en compte les besoins, l'historique et le legs d'une entreprise.

Scalabilité, Fiabilité, Maintenabilité. C'est sur cet alliage que mon attention s'est polarisée depuis plusieurs années, en concevant des systèmes qui maximisent sans sacrifice ces trois propriétés. Que ce soit rendre des écosystèmes modernes véritablement sécurisés et scalables, cibler des serveurs "legacy" sans sacrifier la sûreté moderne, ou pousser des bases de données relationnelles dans leurs limites physiques : mon office est de répondre très rapidement à des millions de requêtes par jour (pour les clients dans leur ensemble), sans bug (pour un client isolé), avec aisance et vélocité (pour l'équipe technique).

J'ajoute à cela un sujet important : le pivot technologique (Transpilation & Strangler Fig Pattern). J'entends par là la capacité d'orchestrer la migration complète du code d'une entreprise (d'un écosystème/langage "legacy" vers un runtime natif ultra-performant comme Rust ou Go) sans aucun risque de réécriture Big Bang. À l'image du figuier étrangleur naturel, qui s'enroule progressivement autour d'un vieil arbre pour finir par le remplacer intégralement (sans jamais l'abattre brusquement), un langage FP bien conçu s'insère au sein de la base de code existante (via la FFI : Foreign Function Interface). Elle isole et sécurise ainsi mathématiquement la logique métier par îlots. Une fois le code métier assaini, le découplage est tel qu'il suffit de modifier la cible de transpilation pour basculer d'un environnement d'exécution à l'autre, en 10 secondes (ce moment est particulièrement gratifiant, en voici une preuve à cet endroit : ici, un projet bascule d'un runtime/langage (JS) vers un autre (PHP), sans modifier la moindre ligne de code). On transfert la complexité du projet vers l'architecture de compilation, ce qui permet à l'entreprise de changer radicalement de classe de performance tout en continuant de livrer des fonctionnalités au quotidien. Les mêmes que d'habitude, mais : plus vite, beaucoup plus fiable, et beaucoup, beaucoup plus loin. Et bien sûr, ce qui a été fait une fois, pourra être refait 10 ans plus tard, avec un autre langage cible, mais bien plus rapidement : l'étape de l'insertion étant déjà faite, il n'y aura qu'à réécrire quelques FFIs, puis basculer. Tout simplement. Cela assure à l'entreprise une mise à jour naturelle, alignée en permanence sur les nouvelles technologies et les nouveaux standards de performance, sans sacrifier ce qu'elle sait faire de mieux : son métier, son produit propre.

Je pense fondamentalement, comme Milewski, que l'avenir de la programmation réside dans la faculté d'expression d'idées mathématisées (invariants, effets, lois, etc.), avec des langages enracinés dans les théories modernes (e.g. Théorie des Catégories, HoTT, etc.). Comme j'ai pu l'écrire sur mon blog, le code est de plus en plus assumé par l'IA, mais la programmation change de définition, se mathématise, et reste humaine : il s'agit de moins en moins de dire à la machine comment faire, mais surtout quoi faire (e.g. sous forme d'arbre décisionnel), prisant ainsi tout paradigme de programmation allant en ce sens.

Voilà pour les grandes lignes, et la trajectoire d'ensemble !

Actuellement, je cherche un ambitieux projet à fonder ou à booster, dans lequel je crois à 100%.

Pourquoi PureScript est-il très présent dans mes projets ?

Car c'est un langage directement ancré dans les recherches les plus avancées (i.e. Haskell), à très haute densité conceptuelle, particulièrement puissant compte-tenu de la moderne préférence pour la type safety (i.e. ce qui protège le code d'une immense classe de bugs potentiels), et très pragmatique par ailleurs, car ouvert au legacy (FFI). C'est donc un langage capable de s'hybrider intelligemment à l'existant, capable de travailler de très près avec des langages complètement différents. Quand on code en PureScript, on code en fait aussi (si on le souhaite) en Go, en C++, en Scheme, en PHP, en Python, en Lua, en JavaScript/TypeScript, en Erlang, etc. Et on ne le fait pas de manière dispersée, on le fait dans la même base de code. PureScript est un hub central mettant à profit chacun de ces langages/écosystèmes/runtimes, avec leurs points forts. Ce n'est donc pas un langage ordinaire, au sens usuel du terme. C'est aussi un langage proxy, à très forte valeur ajoutée (abstractions, design, théorie sous-jacente, conventions...).

Sa courbe d'adoption ressemble à celle d'Haskell : organique (i.e. up-plateau-up-plateau...). C'est à mon sens le meilleur scénario possible, car son évolutivité est encore libre (non bloquée par le risque de casser un existant massif), mais suffisamment influencée par de réels besoins (adoption significative, en remplacement de TypeScript, par exemple).

Concernant l'IA, j'ai également eu l'occasion d'exprimer mes idées sur LinkedIn, en échangeant avec des pairs. Je crois que l'un des messages qui illustre le mieux ma conviction est celui-ci :

• 🧩 Agnosticisme d'exécution (Runtime agnosticism) : Comme expliqué plus haut, je conçois donc des logiques métier pures, découplée des environnements d'exécution spécifiques, traditionnellement associés aux langages mainstream de l'industrie. Mon travail actuel consiste à amener la programmation fonctionnelle stricte dans des endroits où on son apport est le plus spectaculaire (e.g. comme ici avec PHP, ici avec Go, etc.), en tirant parti d'écosystèmes massifs existants sans sacrifier la sûreté de typage avancée. J'ai la conviction profonde que l'ère des guerres de religion entre langages de programmation est révolue. Il est temps de profiter des forces de chaque langage (ex: Erlang pour la tolérance aux pannes, PHP pour le déploiement omniprésent, Node.js pour les I/O asynchrones, C/C++/Rust/Chez Scheme pour la vitesse d'exécution brute, etc.) en favorisant un dialogue intelligent entre eux. Cela peut notamment se faire via un langage suffisamment abstrait pour agir comme une couche universelle, sans souffrir du syndrome du "plus petit dénominateur commun" (ex: Haxe), et en offrant une FFI et une compilation optimisées/puissantes. Je parle plus longuement de ce sujet dans cet article, et j'en ai fait une preuve testable publiquement, partagée avec un petit nombre d'ingénieurs, avec qui je travaille, et initiés au sujet. Pour rendre cet agnosticisme réellement industriel, mon travail implique du Compiler Engineering : au-delà de l'architecture, je conçois des compilateurs pour retrouver des écosystèmes complets (avec performance native) comme Go ou PHP (via TCO, DCE, monomorphisation, portage intégral de Standard Libraries...), tout en préservant la possibilité d'utiliser des langages hautement expressifs et fidèles à la pensée pure (dénuée des contingences matérielles de la machine).
  
  
  
  

• ⚡ Architectures "Lock-free" : J'explore des patterns d'Event Sourcing intéressants (POC, que j'ai initialement discuté ici, également implémenté dans un projet réel). Je me concentre sur la capacité à pousser des bases de données monolithiques (comme PostgreSQL) à une échelle FAANG (60k+ TPS) en utilisant des paradigmes sur-mesure comme le DDD sans agrégat (Aggregateless DDD), les Context Collision Observers (CCO) et l'optimistic batching.
  
  
  
  

• 📐 FP pure et Théorie des Catégories : Je passe par la rigueur mathématique, non seulement pour la beauté de la théorie elle-même (merci Milewski ❤️), mais pour résoudre des problèmes d'ingénierie notoirement difficiles : la concurrence, l'état distribué, l'invalidation de cache, les "machines à remonter le temps" (Time Travel Debugging), la symétrie architecturale, etc.
  
  
  
  

Je tiens à rassurer sur un point : j'ai conscience de la complexité de mes descriptions. Tout cela ne vise pas à complexifier pour complexifier, mais au contraire à accueillir, au même niveau, la complexité accrue qui accompagne votre croissance. Il faut voir cela comme un transfert de complexité : la logique interne de l'entreprise se compliquant (e.g. trafic des clients, parc de serveurs, équipes internes...), il s'agit d'y répondre par des tampons conceptuels denses qui capturent cette complexité, évitant ainsi de dénaturer vos interfaces, celles des développeurs, votre organisation interne, etc. J'ai la conviction indurée, profonde, qu'une technique riche soulage l'ensemble d'un groupe. Cela vise donc moins à intimider qu'à vous proposer une vision crédible des choses, éléments tangibles à l'appui. À mon sens, la bonne complexité est la complexité intentionnelle, contrôlée, en opposition à une complexité contingente et accidentelle, fuitant jusqu'au produit lui-même, et ressentie par les clients et/ou les développeurs.

Un certain nombre de ces choix sont déterminants dans le cadre d'une politique d'entreprise orientée IA. D'un point de vue agentique, une IA se voit notamment offrir des rails et des garde-fous (e.g. Hindley-Milner, System F...) qui réduisent considérablement son espace de recherche stochastique.

Si ce petit manifeste vous intrigue, n'hésitez pas à me contacter pour des échanges plus approfondis ailleurs, entre humains !

Sur un plan technique, je serais ravi d'échanger autour de : runtime agnosticism, Event Sourcing, PLT & compilers, FP, Category Theory, les entrailles de Postgres...

Et/ou sur un plan plus général, parlons de vos projets concrets !

(Photo prise/stylisée avec un Kodak, en 2026, et en Écosse : je suis un coureur de longue date, et j'ai l'habitude de faire l'équivalent kilométrique d'entre 1 et 3 marathons par semaine, dans des cadres aussi naturels que possible)