Depuis vingt ans, j'exerce trois métiers avec la même démarche : comprendre un système, le construire, et vérifier qu'il tient. J'ai été chercheur en simulation numérique, puis développeur, puis architecte cloud. Aujourd'hui, je suis les trois à la fois.
Dix ans chez Safran Aircraft Engines, dans le département Méthodes : simulation numérique de la combustion, calcul haute performance, coordination de deux programmes européens de 10 millions d'euros chacun avec plus de vingt partenaires industriels et académiques, cinq doctorants encadrés, des articles et trois brevets. En parallèle, l'enseignement : mécanique des fluides à l'ISAE-SUPAERO puis à l'ENSTA. Le métier, déjà : faire produire des résultats à des machines, et savoir lesquels croire.
Dans un département Méthodes de motoriste aéronautique, on ne fait pas confiance à une simulation parce qu'elle a tourné : on la qualifie. On écrit les critères avant, on vérifie après, et on refuse le résultat quand il ne tient pas. J'ai fait ça pendant dix ans sur des chambres de combustion, en calcul haute performance, pour des bureaux d'études qui engageaient des moteurs d'avions sur ces résultats.
J'y ai aussi appris à coordonner : j'ai piloté deux programmes européens de recherche de 10 millions d'euros chacun, avec plus de vingt partenaires industriels et académiques, et j'ai encadré cinq doctorants. J'ai appris à transmettre en enseignant la mécanique des fluides à SUPAERO puis à l'ENSTA.
Ce que j'en garde : quand je relis aujourd'hui ce qu'une IA produit, je refais exactement ce travail de qualification.
À trente-cinq ans passés, j'ai quitté la recherche pour un environnement où l'on peut changer les choses. J'ai commencé par le matériel : j'ai fait de l'électronique, de l'impression 3D et des microcontrôleurs, j'ai développé un prototype après un hackathon gagné, et j'ai conçu un MOOC pour apprendre aux autres à fabriquer un objet connecté. Je suis ensuite passé au logiciel : lead full stack chez Inwibe, j'ai reconstruit leur application web en jouant aussi le rôle de product owner.
J'ai enfin abordé le cloud par le grand bout : pour le ministère irlandais des Transports, j'ai conçu et développé de zéro, sur Azure, la plateforme de données et de supervision de l'autoroute M50 de Dublin, je l'ai sécurisée et je lui ai donné son intégration continue et son infrastructure en Terraform. J'ai aussi animé la communauté Azure des consultants de JEMS.
Ce que j'en garde : j'ai pris goût à livrer entier, de l'architecture au bouton, et j'ai gardé le réflexe de décrire l'infrastructure en code dès le premier jour.
Chez JEMS, j'ai réalisé la partie infrastructure pour Vinci. Chez SFEIR, j'ai accompagné la migration vers Azure de la holding et du groupe LVMH. Chez Ardian, pendant trois ans, j'ai audité la sécurité de la plateforme Azure existante, j'ai aidé à choisir le partenaire, puis j'ai conçu la nouvelle landing zone. Chez Log Consulting, j'interviens pour Saint-Gobain comme architecte et solution designer, et je dirige la practice IA de Log. J'ai aussi formé les équipes de Lacoste à Azure et à Git.
En parallèle, j'ai créé Dalaran Consulting pour faire ce que ces missions ne me laissaient pas faire : construire. J'ai livré l'extranet de France Hydrogène, le pointage puis l'ERP de Vissouarn, et j'ai conçu Medivh, la chaîne de développement assistée par l'IA avec laquelle je les livre.
Ce que j'en garde : j'applique à une PME de quarante personnes ce qu'un grand groupe exige en sécurité, en traçabilité et en réversibilité, parce qu'à cette échelle, ça ne coûte presque rien quand on le prévoit dès le départ.
J'ai enseigné la mécanique des fluides à SUPAERO et à l'ENSTA, j'ai corrigé les concours des grandes écoles et les oraux des concours polytechniques, j'ai conçu un MOOC sur les objets connectés pour l'IMT et récemment encore j'ai formé les équipes de Lacoste à Azure et à Git. Aujourd'hui, à la fin de chaque projet, je forme les équipes de mes clients pour qu'elles sachent utiliser et administrer leur outil sans moi.
C'est aussi pour ça que je documente mes projets avant de les coder : un outil qu'on peut expliquer est un outil qu'on peut reprendre.