Je construis des référentiels qui ne se contredisent pas,
et des pipelines de déploiement qui ne dépendent plus de personne.
Développeur TIBCO EBX, architecte .NET et microservices, DevOps. Seize ans sur des systèmes qui n'ont pas le droit de se tromper.
Un chemin pour écrire.
Un autre pour lire.
Sur le référentiel tiers d'un grand assureur, les deux besoins s'opposaient : garantir la cohérence à l'écriture, sans faire attendre les systèmes qui lisent. Deux exigences contradictoires sur le même socle. La réponse a été de séparer les deux chemins.
Deux lignes. Une seule entreprise. Vraiment ?
La résolution d'identité, c'est décider si deux enregistrements désignent la même entité. Le problème n'est jamais l'outil, c'est la règle.
J'ai conçu et réalisé l'intégralité de la brique Dun & Bradstreet d'un référentiel tiers : appels aux API, consolidation des données, logique de matching sur DUNS et Name-Address. Le vrai travail n'est pas d'appeler l'API — c'est d'arbitrer les cas ambigus, et de rendre chaque décision traçable et reproductible.
Plus d'une dizaine de systèmes, producteurs et consommateurs, s'appuient sur ce référentiel. Chacun a besoin que la réponse soit la même.
Ce que je fais.
Ce que je refuse.
Engagements
- Rendre l'environnement reproductible avant d'optimiser quoi que ce soit
- Vérifier que ce qui marchait avant marche encore
- Quand une erreur revient, corriger ce qui l'a laissée passer
- Écrire les décisions, pas seulement le code
- Signaler un blocage le jour où il apparaît, pas au point d'étape
- Livrer une chaîne que l'équipe pourra reprendre sans moi
Refus
- Du code généré que personne n'a relu
- Empiler une couche de plus sur un socle qu'on n'a pas compris
- Appliquer une solution parce qu'elle a marché ailleurs ou parce qu'elle fait référence, sans vérifier qu'elle vaut ici
- Annoncer des gains chiffrés que personne n'a mesurés
- Un référentiel dont les règles vivent dans la tête d'une seule personne
Développeur d'abord.
Architecte ensuite.
Le signal, c'était les projets que je laissais passer.
Quatorze ans à la Matmut. Je m'y plaisais vraiment : une équipe solide, des sujets intéressants. Le signal n'était pas là — il était dans les sujets techniques que je laissais filer, ceux qui m'auraient emballé quelques années plus tôt. Sans m'en rendre compte. C'est con comme indicateur, mais c'est efficace.
Ce n'était pas une fuite. J'avais besoin d'un nouveau challenge, et j'ai préféré l'assumer plutôt que de laisser la motivation s'éroder.
Le premier contrat est tombé : full remote, en anglais, dans une équipe internationale. La techno, la langue, la culture de travail : tout était nouveau en même temps. Je m'y étais préparé — je m'étais formé sur EBX et en anglais avant de commencer. Avec le recul, c'est exactement ce dont j'avais besoin.
Hexarace
Un écosystème de plugins pour SimHub, que je conçois, développe et distribue seul. C'est mon terrain d'essai : j'y valide sur un produit qui m'appartient ce qui n'a pas sa place sur un projet client.
HexaDash
Tableaux de bord haute densité, du DDU 4 pouces à l'overlay plein écran. Plus de 80 simulations prises en charge via SimHub.
HexaShift
Pilotage des LED de volant : régimes moteur, drapeaux, alertes. Dix thèmes.
HexaLight
Éclairage ambiant synchronisé sur la course — Philips Hue, Govee, bandeaux LED.
Ce que j'y valide
- Temps réel
- Traiter un flux de télémétrie continu et garder l'affichage fluide.
- Lecture en course
- Une information qui demande à être cherchée est une information perdue — et du temps au tour en moins.
- Distribution
- Versionner, publier et faire installer un binaire par des gens que je ne connais pas — puis livrer les mises à jour suivantes en un clic, depuis le module lui-même.
- Développement assisté par IA
- C'est ici que j'industrialise le développement assisté par IA. Une architecture multi-agents où chaque agent a un rôle défini — spécification, architecture, développement, tests, revue, documentation — avec ce qui la rend réellement utilisable : revue systématique, tests automatisés, décisions tracées. Ce que je valide ici sur mon propre produit, je sais l'appliquer là où l'erreur coûte cher.
Un référentiel à construire,
ou à remettre d'aplomb ?
contact@hexainnovate.com
À distance ou sur site. Installé en Normandie, missions en français comme en anglais.
Un référentiel de données
À construire, à reprendre après un départ, ou à faire monter de version sans casser les systèmes qui en dépendent.
Une chaîne de livraison
À industrialiser quand elle dépend encore de gestes manuels, ou à reprendre quand personne ne sait plus ce qui tourne en production.