En quelques mots, je conçois les cahiers des charges techniques du logiciel embarqué pour l’ensemble des serveurs que la R&D d’Eviden développe.

Dans un chantier de construction, un architecte fait des plans qui correspondent aux attentes d’un client, et qui ont vocation à être réalisés par une équipe de terrain. Mon travail est similaire : je réponds aux besoins de différents clients (internes et externes) en proposant les plans du logiciel embarqué des produits. Dans un serveur haut de gamme, celui-ci est réparti sur plusieurs composants : le BIOS du processeur, un ou plusieurs FPGA (réseau de portes programmables in situ) en charge des opérations en temps réel, et une BMC (puce de gestion de matériel) qui permet l’orchestration du serveur à distance, sans interférer avec son opération. Dans le cadre de nos supercalculateurs, s’y rajoutent des déclinaisons de ces composants pour encadrer l’infrastructure du châssis : gestion de l’alimentation, des pompes…

Nous avons une gamme de produits assez vaste, qui va de serveurs individuels « Edge », pouvant être déployés n’importe où, aux supercalculateurs, notre fer de lance. Ces derniers sont utilisés dans de grands centres de calcul pour des opérations intensives : météo, simulations physiques, nucléaire…

Au quotidien, c’est beaucoup de communication, interne et externe à l’entreprise. D’abord avec les clients de la R&D : en premier lieu les équipes commerciales, mais aussi avec ceux qui interfaceront avec le logiciel embarqué des serveurs. Ensuite, bien sûr, en interne dans la R&D : je ne peux pas tout savoir, donc nos experts m’aident à construire une vision d’ensemble de ce qui est possible ou non. Et enfin avec le reste de l’industrie, pour être au fait des nouveautés : je dois être dans les premiers informés lorsqu’une nouvelle technologie voit le jour, puis l’analyser, comprendre si elle a sa place dans nos produits, évaluer la complexité de son implémentation.

Je lis beaucoup de spécifications techniques, sur les produits que nous intégrons (processeurs, GPU, cartes réseau…) ou sur des standards émergents que nous pourrions être amenés à supporter. Je vais assister à des conférences, pour de la veille technique ou pour contribuer à des projets collaboratifs. Et j’écris beaucoup : bien sûr les spécifications de nos produits, mais aussi des présentations et rapports, et quelques prototypes que je programme sur le temps qu’il me reste !

Je travaille principalement en amont de l’introduction commerciale des produits, donc je ne peux pas parler de mes projets actuels dans le détail, mais ils incluent bien sûr la prochaine génération de nos serveurs et lames de calcul.

Parmi les produits existants sur lesquels j’ai pu travailler, les lames XH3515 pour le châssis BullSequanaXH3000 sont notoires : elles composent la majeure partie du supercalculateur JUPITER récemment ouvert à Jülich. C’est le plus grand d’Europe et le quatrième plus puissant au monde ! Le châssis lui-même est une machine impressionnante : plus de deux tonnes, des alimentations redondantes en triphasé montant à 150 kW, et refroidissement à eau avec redondance des pompes et coldplates entièrement fait maison. Et ce pour chaque châssis - il y en a 125 à JUPITER... C’est passionnant de travailler sur ce genre de projet.

C’est un domaine dont la complexité a été sous-estimée par l’industrie dans son ensemble. Pour les BMC notamment, les spécifications de protocoles qu’elle doit supporter – en quelques sortes, les « langues » électroniques que la BMC doit savoir parler – ont et continuent d’évoluer très vite, et leur implémentation peine à suivre. L’implémentation en passe de devenir le standard industriel, la distribution Linux OpenBMC, a une architecture très complexe, en partie en réponse à ces spécifications vastes et fluctuantes. Dans ce contexte, estimer la faisabilité d’un développement n’est pas simple.

De façon plus générale, au-delà du firmware, les besoins auxquels l’équipe d’architecture s’efforce de répondre proviennent de multiples acteurs parfois indirects (équipes, clients, mais aussi régulations, normes de sécurité informatique…), et peuvent être conflictuels ; c’est concilier ces besoins dans un projet en temps restreint qui pose souvent le plus de problèmes.

IPMI est un standard de gestion de matériel qui a fait ses preuves, mais qui est aujourd’hui en passe d’être remplacé par un ensemble de protocoles plus modernes. Un bon nombre de ces standards sont définis par la Distributed Management Task Force (DMTF), un consortium dont nous faisons partie sous l’égide d’Atos. Principalement, les enjeux sont de modéliser des datacenters et des produits beaucoup plus complexes qu’à l’époque où IPMI a été établi, de répondre aux exigences modernes de sécurité, et de standardiser une interface utilisateur haut-niveau.

Un des objectifs de la DMTF est aussi de fournir des standards ouverts : n’importe qui peut accéder aux dernières versions des spécifications, et un bon nombre d’outils d’aide à l’implémentation et à l’interaction sont disponibles sous licence libre. C’est un gain énorme pour nos serveurs : tous nos partenaires et clients ont un accès directs aux standards qu’ils utilisent, ce qui réduit nos efforts de documentation, et facilite l’interopérabilité.

C’est aussi permettre à un public très large de développer des outils libres se basant sur ces standards - comme l’excellent dmidecode pour les tables SMBIOS, par exemple. Et enfin, donner un accès libre aux standards, c’est avoir d’autant plus de personnes qui peuvent y trouver des erreurs, et les remonter à la DMTF pour correction. Ce que j’ai d’ailleurs eu l’occasion de faire personnellement !

L’EPI est un projet de développement de processeurs encadré par l’Europe, partagé entre des entreprises et des universités. En tant qu’intégrateur serveur, Eviden a été choisi pour coordonner ce consortium : nous travaillons avec de nombreux partenaires, non seulement pour développer ces processeurs, mais aussi tout l’outillage matériel et logiciel qui va avec.

J’ai pu y contribuer en faisant l’architecture firmware préliminaire de la lame de calcul que nous comptons construire pour héberger la puce Rhea1 de SiPearl, pièce maîtresse du projet. Celle-ci a d’ailleurs récemment fait son « tape-out » (envoi des plans au manufacturier) ; certes, avec du retard, mais c’est un jalon que nous avons célébré !

Le logiciel libre, ce n’est plus le futur de l’informatique, c’est son présent ! Personnellement, au quotidien, la majorité des logiciels que j’utilise sont libres. Et ce n’est pas une restriction que je m’impose : ce sont réellement les meilleurs du marché pour mon utilisation.

Professionnellement, une de nos plus grandes adhérences à l’open source est la distribution OpenBMC, que je mentionnais précédemment. C’est un projet qui a ses défauts, mais sa plus grande qualité est d’être ouvert, et c’est la raison de son succès. Une bonne partie des partenaires qui nous vendent les composants matériels utilisés dans nos cartes nous fournissent un OpenBMC modifié adapté pour leurs produits : ces différentes sources nous aident grandement à développer la distribution qui sera sur notre produit final. Un autre avantage est que si l’industrie partage une base commune, l’interopérabilité entre les systèmes s’en trouve notablement améliorée : le client peut raisonnablement s’attendre à s’interfacer similairement avec une BMC basée sur OpenBMC, qu’elle soit produite par Eviden, HP ou Dell.

Nous avons été un des premiers grands intégrateurs à adopter OpenBMC en production, et progressivement tout le monde s’y est mis… Nous ne faisons pas encore beaucoup de contributions actives en retour vers le projet, mais c’est un chantier en cours. Notre objectif de contribution n’est d’ailleurs pas que philanthropique : c’est aussi un très bon moyen d’orienter l’industrie vers notre façon de faire les choses. Laisser faire les autres, c’est économique, mais ça veut aussi dire avoir du retard et devoir s’adapter ensuite.

J’ai déjà beaucoup parlé des avantages ; en termes de limites, on ne peut bien sûr pas tout dire ou tout divulguer. Notamment du côté du BIOS, la protection de la propriété intellectuelle est une des priorités des fabricants de puces, et même nous n’avons pas toujours accès à l’ensemble du code source. Pour la BMC, c’est moins le cas, car la difficulté réside plus dans l’implémentation des standards sur du nouveau matériel que dans des fonctionnalités vraiment novatrices et brevetables.

Pour ce qui est du secteur, le stratégique ne rentre pas nécessairement en conflit avec l’open source ; c’est même plutôt un gage de sécurité, car auditable plus facilement.

Mon expérience de prestataire en informatique embarquée chez Kickmaker a été immédiatement applicable chez Eviden… Car c’est le seul client pour lequel j’ai travaillé, en tant que développeur firmware sur les BMCs des supercalculateurs ! C’est à la suite de cette première collaboration qu'Eviden m’a recontacté, un an et demi après mon départ - cette fois pour un poste en interne, et comme architecte. 

J’étais entre temps parti chez EDF pour être product owner et architecte d’un ensemble d’applications de contrôle commande des centrales nucléaires. J’ai voulu m’essayer à un travail moins technique, plus proche des parcours standards en sortie de Centrale Lyon : la programmation et l’informatique de bas niveau ont toujours été avant tout des hobbies pour moi, j’avais des doutes sur le fait d’en faire ma carrière. Mais ça m’a manqué très vite !

J’ai tout de même beaucoup appris chez EDF, et si c’était à refaire, je le referais. N’ayant eu qu’une expérience de développeur auparavant, j’avais de bonnes idées, mais je voulais tout mettre en place tout de suite et tout seul ! Dans un groupe de 160 000 personnes, on apprend vite à choisir ses combats : moderniser tous les processus en quelques mois, ça marche sur un projet de deux personnes dans une startup, pas dans un complexe industriel. J’ai appris à communiquer, à écouter, à prioriser… J’ai beaucoup gagné en patience, ce qui m’a rendu plus crédible aujourd’hui lorsque je propose des changements d’architecture importants, mais réfléchis, et avec le soutien des équipes.

Passer mon double diplôme à Tokyo a été un privilège, et j’en suis extrêmement reconnaissant aux deux Écoles. J’ai eu la chance d’étudier dans le laboratoire du Dr. Ishigami, qui s’est toujours montré moderne et bienveillant, et j’y ai énormément appris. Je me souviens notamment d’un cours sur l’optimisation de compilateurs, qui m’a ouvert les yeux sur l’informatique de bas niveau…

Ça a aussi été l’occasion de rencontrer des étudiants brillants venus du monde entier. Je me suis rendu compte qu’avec de la motivation, rentrer dans les cercles de ce que je voyais comme une élite technique très lointaine était accessible : un de mes camarades de résidence étudiante faisait régulièrement de la contribution à gcc, le compilateur C/C++ du projet GNU !

La culture du travail japonaise m’a enfin beaucoup marqué, même si pas nécessairement positivement. J’ai vu des collègues dormir dans les labos, ou regarder fixement leur écran, exténués, pour ne pas partir trop tôt et risquer de faire mauvaise impression… Il ne faut bien sûr pas généraliser, mais j’en apprécie d’autant plus la culture de productivité et de respect du temps privé dont nous bénéficions en France. J’apprends tellement de choses grâce à des projets personnels sur mon temps libre, que je suis bien content d’en avoir.

3 adjectifs pour qualifier l’élève que vous étiez à Centrale Lyon ?

Insolent, curieux, et un peu perdu.

- Un.e camarade de promo avec qui vous traîniez tout le temps ?

Pas nécessairement celui avec qui je traînais le plus, mais je salue Alexandre Marsone, mon mentor à ECLAIR et sans qui je n’aurais probablement pas suivi la même voie professionnelle…

- Votre matière préférée à Centrale Lyon ?

Je citerai Catherine Musy-Bassot et Eric Blanco : l’automatique, c’est fantastique.

- Celle que vous appréciez le moins ?

La mécanique des systèmes solides.

- Ce que vous vouliez faire comme « métier » pendant votre formation à l’ECL ?

À peu près exactement celui que je fais aujourd’hui, peut-être plutôt orienté dans la robotique ou plus bas-niveau dans l’architecture processeur, mais je m’estime très bien loti.

- Que penserait l’élève que vous étiez s’il découvrait votre parcours pro jusqu’à aujourd’hui ?

Il aurait des étoiles dans les yeux !

- Un conseil que vous donneriez aux élèves actuellement à Centrale Lyon ?

S’investir à fond dans l’associatif. C’est pour moi la plus grande force de notre École ; on y apprend énormément, autant techniquement que socialement.