J’ai commencé par créer des applications. Pas concevoir des plateformes, ni architecturer des systèmes distribués — simplement écrire des fonctionnalités, corriger des bugs et livrer des choses réellement utilisées. C’était surtout du Java, et j’y ai passé assez d’années pour acquérir les réflexes qu’impose l’exploitation de services de longue durée : surveiller le comportement mémoire, raisonner sur la concurrence et lire des thread dumps à des heures peu commodes. C’est encore la partie que je préfère, et je crois qu’elle a discrètement façonné tout le reste. Quand votre premier réflexe est « qu’est-ce que ça apporte à la personne qui s’en sert ? », vous finissez par poser d’autres questions plus tard, lorsque les systèmes grandissent et que les réponses deviennent moins évidentes.
Mon parcours#
Le passage du développement d’applications au cloud et aux systèmes distribués n’était pas un plan de carrière. C’était la conséquence naturelle d’applications devenues plus difficiles à exploiter. Un service en est devenu plusieurs. Les déploiements ont cessé d’être quelque chose qu’on fait un vendredi après-midi pour devenir quelque chose qui devait être ennuyeux et reproductible. L’état est sorti du processus pour aller quelque part qu’il fallait désormais raisonner avec soin. Chacun de ces changements était un problème que je devais comprendre pour continuer à faire le métier que je faisais déjà — et, en chemin, les comprendre est devenu le métier.
Les données ont suivi le même chemin. Les applications produisent des données, et quelqu’un finit toujours par vouloir en faire quelque chose d’utile : reporting, analytique, et aujourd’hui des modèles. Je me suis retrouvé sur les plateformes de données parce que les systèmes que je construisais en fournissaient les entrées, et que c’est précisément à la jointure entre « l’application » et « le pipeline » que les choses cassaient. Travailler des deux côtés de cette jointure m’a appris une chose à laquelle je crois toujours : la plupart des incidents en production qui ressemblent à des problèmes applicatifs sont des problèmes de données déguisés. Un schéma a changé. Un champ qui n’aurait jamais dû être nul l’était. Un traitement par lots s’est exécuté deux fois.
Les logiciels assistés par IA sont la version actuelle de cette même histoire. Le problème d’ingénierie intéressant, ce n’est pas le modèle — c’est tout ce qui l’entoure. D’où vient le contexte, et est-il à jour ? Comment savez-vous que la qualité s’est dégradée ? Que se passe-t-il en cas d’échec qui ne lève aucune exception, mais produit simplement une réponse discrètement fausse ? Ce sont des questions de données et de fiabilité, ce qui explique sans doute pourquoi ce travail me semble familier plutôt qu’étranger.
Ce dont je me suis convaincu#
Quelques convictions acquises à la dure, et que je tiens assez souplement pour accepter d’en débattre :
Les systèmes simples gagnent sur la durée. Pas simples à construire — simples à comprendre six mois plus tard, à 3h du matin, par quelqu’un qui n’était pas là quand ils ont été écrits. Le code astucieux est un emprunt contracté sur la patience de votre futur vous-même.
Si c’est difficile à déboguer, c’est un défaut de conception. L’observabilité ne se greffe pas après un incident. Le fait qu’un système puisse être compris pendant son exécution est une propriété que l’on décide dès la conception, et il est bien moins coûteux de la décider tôt. Je préfère livrer quelque chose de modeste et observable que quelque chose d’ambitieux et opaque.
La maintenabilité est une fonctionnalité sans ticket. Personne ne demande jamais « du code agréable à modifier », ce qui est exactement pourquoi elle est sacrifiée en premier. C’est pourtant elle qui détermine si une équipe avance encore vite deux ans plus tard.
La productivité des développeurs n’est pas un sujet secondaire. Des boucles de retour lentes ne font pas que perdre du temps : elles changent les comportements. Quand une suite de tests est interminable, on cesse de la lancer. Quand les déploiements font peur, on les regroupe, ce qui les rend plus effrayants encore. Beaucoup de ce qui ressemble à un manque de rigueur est en réalité un problème d’outillage.
Ce sur quoi je réfléchis en ce moment#
Je consacre actuellement du temps à l’évaluation — plus précisément, comment savoir si une fonctionnalité assistée par IA fonctionne quand il n’existe aucune vérité terrain propre à laquelle se comparer. C’est un problème frustrant d’une manière que je trouve réellement intéressante : la réponse honnête passe généralement par des métriques indirectes et de la relecture humaine, et chaque option a un mode de défaillance qu’il faut assumer ouvertement.
Je réfléchis aussi beaucoup au coût de l’observabilité. Il est facile de tout instrumenter et de se retrouver avec une facture et un tableau de bord que personne ne consulte. Décider ce qu’il ne faut pas mesurer s’avère être la compétence la plus difficile.
Pour le reste, je lis beaucoup et j’expérimente. Apprendre de nouvelles technologies ne m’a jamais pesé — même si je suis devenu plus circonspect avec le temps quant à les adopter rapidement. Les bonnes idées sont généralement encore bonnes deux ans après.
Loin du clavier#
Je roule beaucoup. Le vélo est ce que j’ai de plus proche d’un bouton de remise à zéro : c’est l’une des rares activités où le problème devant moi est entièrement physique et parfaitement soluble en pédalant.
Le reste de mon temps libre finit au garage, ou quelque part dans la maison avec les moulures démontées. J’aime les voitures, et j’aime y travailler — deux passe-temps distincts qui se recoupent parfois. Idem pour le bricolage et la rénovation : des meubles, des réparations, et ce projet ambitieux d’un week-end qui en occupe finalement trois.
J’ai cessé de prétendre que tout cela est sans rapport avec mon métier. Démonter quelque chose pour comprendre pourquoi ça ne fonctionne plus relève du même réflexe dans les deux cas, et les projets manuels sont utilement humiliants. Un changement de plaquettes se moque de votre niveau de confiance. On ne revient pas en arrière sur une coupe déjà faite, ce qui pousse à mesurer correctement du premier coup — une habitude que j’aimerais voir se transposer plus fidèlement aux changements en production.
Me contacter#
Je suis toujours partant pour échanger sur des problèmes d’ingénierie intéressants, des interventions en conférence ou de l’open source. La page contact rassemble les coordonnées, ou retrouvez-moi sur GitHub et LinkedIn.