Expert FPGA & électronique numérique

Le FPGA est le fil le plus ancien de mon parcours. Il commence en 2008 avec une IP FlexRay écrite en VHDL pendant mon stage de fin d'études, et il court jusqu'à aujourd'hui — avec, au milieu, sept années consacrées au logiciel et au produit qui n'ont rien effacé.

Quatre terrains, quatre exigences différentes : le prototypage et l'industrialisation en bureau d'études, l'affichage urbain à grande échelle, l'industrie lourde et le nucléaire, puis la défense. Des domaines sans grand rapport les uns avec les autres, mais qui posent au fond les mêmes questions.

Mon rôle a toujours consisté à concevoir et faire évoluer des architectures FPGA capables de tenir une contrainte physique : un timing, un débit, une enveloppe de ressources. Il ne s'agit pas seulement de faire fonctionner une fonction, mais de maîtriser l'ensemble de la chaîne numérique — génération et décodage des trames, synchronisation temporelle, gestion des horloges, pipelines de données, occupation logique.

Chaque projet apportait ses spécificités, mais reposait sur des principes architecturaux communs. Cette répétition dans la diversité m'a permis de consolider une expertise profonde, orientée robustesse et reproductibilité.

Les cinq ans passés chez JCDecaux sont la partie la plus dense de ce parcours FPGA, et la plus visible : des matrices LED déployées en milieu urbain, monochromes ou couleur, de tailles et de résolutions très variables, exposées en continu et dont la moindre défaillance se voit littéralement, de loin.

Le travail y couvre toute la chaîne numérique, de la trame vidéo entrante jusqu'au pilotage de la matrice : une succession d'étages où chacun impose ses contraintes de timing, de bande passante et de ressources, et où une approximation à un maillon se voit sur le produit fini.

D'un terrain à l'autre, presque tout change : le domaine, la famille de FPGA, les protocoles, le niveau de process imposé, la taille de l'équipe. Un banc de test avionique sous DO-254 et un écran LED urbain n'ont, en apparence, rien en commun.

Et pourtant les problématiques fondamentales restent identiques : garantir un fonctionnement stable, avec un timing précis, dans des contraintes strictes de ressources et de coût industriel. Cette constance des invariants m'a conduit à développer des architectures modulaires et réutilisables, quel que soit le domaine.

Le développement FPGA impose des contraintes sévères, qui ont guidé l'ensemble de mes choix techniques. Voici les cinq qui reviennent sur chaque projet, avec, en marge, l'arbitrage que j'ai fini par adopter par défaut.

Mes décisions portent principalement sur la structuration des pipelines, la gestion fine des horloges et de leurs domaines, l'optimisation des flux pour limiter la consommation de ressources, la capacité à faire évoluer un design existant sans régression, et la clarté du découpage fonctionnel pour faciliter la maintenance.

Ces choix sont rarement spectaculaires, mais toujours guidés par une logique de pérennité industrielle.

Entre 2019 et 2025, je n'ai pas touché un FPGA. Six ans de logiciel, d'architecture et de produit, chez Naept puis chez ID-1. Puis un an chez Thales LAS, sur le composant FPGA d'un simulateur d'environnement électromagnétique — détaillé dans la fiche projet.

La question qui se posait était simple : après sept ans d'écart, qu'est-ce qui revient ? Réponse : l'essentiel, et vite. Les réflexes de découpage, de timing, de frugalité étaient intacts. Ce qui a demandé du travail, c'est le neuf — des protocoles que je ne connaissais pas (JESD204B/C, AURORA), des outils qui avaient dix ans de plus, et une équipe de sept développeurs FPGA travaillant en méthode agile, là où mes expériences précédentes s'étaient faites seul ou à deux.

Le plus intéressant a été de me faire contredire sur un sujet que je croyais réglé. J'étais arrivé convaincu qu'un reset doit être activé de façon asynchrone et relâché de façon synchrone. Le design en place était entièrement en reset synchrone. En creusant : sur un FPGA moderne, toutes les bascules sont initialisées au chargement de la configuration ; l'activation asynchrone n'apporte rien à un processus qui n'échantillonne qu'au front d'horloge ; et un reset synchrone est un signal comme un autre, que les outils analysent et contraignent sans surprise.

Ce socle FPGA a profondément structuré mon approche de l'ingénierie. Il m'a appris trois choses qui orientent encore aujourd'hui mes décisions d'architecte.

Cette fiche ne détaille pas chaque projet individuellement, mais rend lisible une expertise construite sur la répétition de projets concrets, industriels et contraints, étalés sur près de vingt ans. Elle constitue un socle technique fort, sur lequel se sont appuyés mes rôles ultérieurs en architecture logicielle, systèmes embarqués et conception de produits complets — et vers lequel je suis revenu sans difficulté après plusieurs années d'interruption.