En conférence, ou même sur internet en général, on a toujours tendance à parler de sujets techniques sous un prisme positif: la nouvelle technologie (ou pratique) qu’on a introduite avec succès, le service qu’on a réussi à "scale", la tranformation d’entreprise qu’on a réussi (microservice, DevOps…​)

En 2025, je vais utiliser au quotidien un assistant IA pour mes tâches.

Ou comment gagner en efficacité en standardisant au maximum les choix techniques dans les équipes de développement.

J’ai récemment open source tout l’écosystème Appclacks. Je résume dans cet article pourquoi la partie health check du projet est la meilleure du marché.

Lorsqu’on conçoit une API HTTP, on se retrouve vite confronté à un problème: certaines actions peuvent être longues et rentrent difficilement dans un modèle d’API synchrone. Comment résoudre cela ?

Les SLO, c’est mon sujet du moment. En plus, je suis dans le train pendant 3 heures, une durée parfaite pour écrire un article de blog avec une contrainte de temps qui me forcera à le sortir rapidement (sans ça les articles stagnent en brouillon).
J’expliquerai donc dans cet article pourquoi je pense que les SLO sont un excellent outil pour faire du suivi de qualité, aider à la priorisation, et détecter rapidement les problèmes en production, et pourquoi toutes les équipes (tech, produit, management…​) peuvent en bénéficier.

On entend maintenant depuis quelques années de plus en plus parler d’entreprises Françaises mettant en place des career track expertes (ou IC pour individual contributor). On parle souvent d’impact transverse dans ces rôles, mais n’y a t-il pas un risque de se disperser en faisant cela ?

DevOps, casser les silos dans les entreprises, faire collaborer équipes pour que tout le monde travaille dans la joie et la bonne humeur…​ On vise tous ça non ? Mais est-ce que parfois recréer les silos ne serait pas la solution pour une meilleure efficacité ?