À propos (Ingénierie)

J’ai commencé à coder à 10 ans. Début des années 80. Mon premier ordinateur était un Tandy MC-10 : une claque. Je me souviens encore des premières lignes en BASIC et de ce moment où tu tapes Run… et il se passe quelque chose parce que tu l’as écrit.

Puis il y a eu l’adolescence et les machines qui ont formé mon goût : Atari ST, Amiga 500. L’Amiga, surtout, a été un tournant : un OS, un terminal, des outils, une manière de penser “système”. C’est là que le développement est devenu une discipline, pas un hobby.

Ce que je fais depuis #

J’ai passé plus de deux décennies à construire et faire tourner des logiciels dans des environnements exigeants : d’abord des systèmes C/Unix (facturation, maintenance, support de production — le réel, ce qui a formé mon exigience sur “le produit qui tourne”), puis des plateformes Java/JVM, l’architecture logicielle, et aujourd’hui du lead technique sur des sujets de sécurité/fiabilité.

Le fil conducteur, lui, n’a pas changé :

  • Les API comme des produits : design, gouvernance, outillage, et tout ce qui évite que ça parte en vrille.
  • Le Dev et le Run : ce qui compte, c’est ce qui se passe après “ça marche chez moi”.
  • Des stacks pragmatiques : C, Java, Kotlin, JavaScript… pas pour collectionner, mais parce que les contraintes bougent et qu’il faut livrer.
  • Du leadership technique : débloquer, rendre les décisions explicites, garder un système cohérent quand il grossit.

Ce que je refuse de faire #

Je ne vends pas de potion magique.

  • Pas de “adoptez X et tout ira mieux”.
  • Pas de cosplay d’architecture : des patterns sans pression, des abstractions sans preuves.
  • Pas de “vitesse” obtenue en refilant la dette à la prochaine équipe ou “au toi de dans 18 mois”.
  • Pas de “best practices” balancées comme des commandements.

Quand un choix a des trade-offs (c’est toujours le cas), je le dis clairement : ce que ça apporte, ce que ça coûte, et ce que ça rend plus dur ensuite.

Les problèmes qui m’intéressent vraiment #

Je suis à mon meilleur niveau sur les sujets où la réalité oblige à être clair :

  • Plateformes et outillage interne : DX, garde-fous, conventions qui réduisent le chaos sans tuer l’autonomie.
  • Design et intégration d’API : contrats, versioning, compatibilité, et les cas limites qui n’apparaissent qu’en production.
  • Architecture guidée par la prod : observabilité, modes de panne, sécurité, opérabilité, support à 2h du matin.
  • Refactoring de systèmes vivants : réduire le couplage, diminuer le blast radius, payer la dette volontairement — sans arrêter de livrer.
  • CI/CD et discipline de release : faire du déploiement un process fiable, pas un événement.

Ce que tu trouveras sur ce blog #

J’écris ici ce que j’utilise pour garder des projets lisibles et livrables :

  • architecture & modularité (quoi séparer, quoi garder ensemble)
  • refactoring guidé par des signaux (pas par des humeurs)
  • JVM (Kotlin/Java), CI/CD, et outillage qui change vraiment le quotidien
  • IA comme outil d’ingénierie — et quand ne pas l’utiliser
  • Hugo / pipeline éditorial (pour partager des connaissances simplement)

Transmission : partager, documenter #

J’ai aussi fait la part “moins visible” mais décisive : revue, doc, mentoring, ateliers internes, partage de pratiques — tout ce qui évite aux équipes de réapprendre les mêmes leçons dans la douleur.

En dehors du travail #

  • J’ai été entraineur de Cesta Punta, je te laisse chercher ce que c’est (timing et réactivité).
  • Je pratique le judo depuis quelques années (discipline et régularité).
  • Je maintiens des modules open-source autour d’outils pour le jeu de rôle sur table (Foundry VTT), parce que fabriquer des outils, c’est instructif (et ça remet vite les idées à leur place).

👉 Licence