Outiller plutôt que répéter

Aucun de mes postes ne s'intitulait « développeur d'outils ». Pourtant, à chacun d'eux, j'ai fini par en construire — parce qu'une tâche revenait trop souvent, parce qu'un système ne se laissait pas observer, ou parce que la même information était recopiée à trois endroits différents.

Cette fiche rassemble ce fil, présent de mon stage de fin d'études jusqu'à aujourd'hui. Il ne s'agit pas d'outillage pour l'outillage : à chaque fois, le déclencheur a été un problème concret qui coûtait du temps, ou un risque d'erreur qu'on ne pouvait pas se permettre.

La première famille d'outils sert à observer. Un bus série, un lien haute vitesse, un système embarqué en fonctionnement ne se laissent pas inspecter à l'œil nu : il faut construire l'instrument qui rend leur comportement lisible.

C'était l'objet de mon stage de fin d'études — un outil d'espionnage et d'injection FlexRay sur FPGA, à une époque où les équipements du commerce étaient rares et coûteux. On retrouve la même logique dans le banc de test « Iron Bird » conçu pour un train chez Bombardier Transport, dans la messagerie de banc de test développée pour Thales, dans les outils PC de mise au point en C++/Qt chez JCDecaux, et, quinze ans après le FlexRay, dans les instruments de mesure que j'ai embarqués à l'intérieur du FPGA chez Thales LAS pour objectiver les performances des liaisons série rapides.

La deuxième famille attaque un autre problème : la recopie. Dès qu'une même information vit à plusieurs endroits — dans le code matériel, dans le code logiciel, dans la documentation — elle finit par diverger. Ce n'est pas une hypothèse, c'est une certitude à l'échelle d'un projet qui dure.

Chez Thales LAS, ce problème se posait sur des milliers de registres répartis sur une dizaine de FPGA. En binôme avec un développeur logiciel, j'ai mis en place un atelier où tout part d'une description unique : le code matériel, son pendant logiciel, la documentation, les interconnexions et les bancs de test en sont dérivés automatiquement, en quelques secondes. J'y ai ajouté le versionnement et l'identification automatiques, pour qu'on sache toujours quelle version d'un composant on a en face de soi. Le détail est dans la fiche projet.

La troisième famille concerne le trajet du code jusqu'à son usage réel. Chez Naept, j'ai conteneurisé l'ensemble du produit et mis en place un déploiement continu via GitLab CI, derrière un reverse-proxy Traefik.

Chez ID-1, j'ai installé l'intégration continue sur un environnement qui n'en avait pas — via Bitbucket, pour les applications web comme pour le firmware des boîtiers ESP32. Côté embarqué, la chaîne fait plus que compiler : elle exécute les tests, produit les binaires, vérifie que la reprogrammation à distance fonctionne sur la nouvelle version, et fabrique l'utilitaire de flashage des boîtiers neufs.

Ce dernier point est celui dont je suis le plus content. L'utilitaire est conçu pour être lancé par mon responsable, qui n'est pas du métier : mettre un boîtier sortant de production dans son état de livraison ne demande plus de développeur. Une chaîne d'outillage qui s'arrête à la porte de l'équipe technique n'est qu'à moitié terminée.

Ce travail n'est jamais visible dans le produit fini. Il se mesure autrement : au nombre de fois où l'on peut livrer sans crainte, et au temps qu'on ne passe plus à refaire à la main une manipulation qu'on a déjà réussie.

Quand l'outil dépasse mon besoin propre, il a vocation à sortir. Chez Naept, plusieurs briques développées pour le produit ont été publiées en open source — conversion ProseMirror ↔ HTML, contributions à PHPWord, Eloquent Sequence — parce qu'il n'y avait aucune raison que le problème soit résolu deux fois.

Je supporte mal de refaire à la main quelque chose que j'ai déjà fait une fois, et encore moins de reposer sur une vérification humaine là où une machine serait plus fiable.

Ce réflexe a une conséquence directe sur ma façon de concevoir : je cherche tôt la représentation qui permettra de tout dériver ensuite, et je préfère investir quelques jours dans un outil plutôt que de payer indéfiniment le prix d'une tâche répétitive. C'est aussi, très concrètement, ce qui rend un projet supportable dans la durée pour ceux qui le reprendront.