KarState — Construire un carnet d'entretien automobile sur la blockchain

Contexte

Kars & Motorbikes (KNM) est une startup luxembourgeoise qui a voulu s’attaquer à un problème bien connu du marché automobile d’occasion : la fiabilité du carnet d’entretien. Quand vous achetez une voiture d’occasion, vous n’avez aucune garantie que le kilométrage, les révisions et les réparations déclarés correspondent à la réalité. Toute la chaîne repose sur la bonne foi, des carnets papier qu’on peut perdre, ou des systèmes centralisés qu’un garage peu scrupuleux peut modifier.

KNM a fait le pari qu’une blockchain pouvait résoudre ce problème : chaque intervention est enregistrée de manière infalsifiable, traçable, et reliée à un véhicule identifié par son VIN. Le projet s’appelait KarState™. J’y suis intervenu comme Blockchain Advisor et architecte technique pour construire l’ensemble de l’écosystème.

Le projet n’a finalement pas été lancé commercialement — je reviens dessus à la fin. Ce que je raconte ici, c’est ce qui a été conçu et construit pendant la mission.

Problématique

Le cahier des charges technique posait trois questions non triviales à traiter en parallèle :

Comment enregistrer de manière fiable les interventions sur un véhicule ? La blockchain est la bonne réponse conceptuelle, mais il y a plusieurs façons de l’utiliser — blockchain publique (immuable, coûteuse en gaz), blockchain privée (moins coûteuse, moins décentralisée), solution hybride. Chaque choix a des implications sur la sécurité, la scalabilité et le modèle économique.

Comment identifier de façon unique et fiable un véhicule ? Le VIN (numéro d’identification du véhicule) est la référence officielle, mais son décodage est un cauchemar : différents constructeurs, différentes périodes, différentes conventions, sources partielles et parfois contradictoires. Construire une identification fiable demande d’aller croiser plusieurs sources et de gérer proprement les conflits.

Comment rendre tout ça utilisable par des garages, des vendeurs et des acheteurs qui ne veulent rien savoir de la blockchain ? L’expérience utilisateur devait masquer entièrement la complexité technique.

Approche

J’étais en équipe de 2 à 3 personnes selon les phases, en tant qu’architecte technique responsable des choix structurants.

Sur la blockchain. Après évaluation, on a retenu une architecture hybride : blockchain Ethereum privée pour les écritures quotidiennes à faible coût, avec la possibilité d’ancrer des preuves sur Ethereum public pour les cas qui demandaient une immuabilité maximale. J’ai installé et configuré l’infrastructure Ethereum privée, écrit les smart contracts en Solidity pour gérer les transactions et les données de maintenance, et utilisé Infura pour les connexions aux réseaux publics quand nécessaire.

Sur l’identification VIN. J’ai développé une API de décodage VIN multi-sources en PHP/Symfony, avec un pattern adapter qui permettait d’ajouter ou de retirer des sources de données sans toucher au cœur du système. Redis en cache pour éviter de taper les sources externes sur chaque requête. La logique de résolution des conflits entre sources a été le morceau le plus intéressant à concevoir — quand deux bases disent des choses différentes sur le même VIN, il faut une règle claire.

Sur l’interface. Développement d’un site vitrine complet en Angular (responsive), pour présenter le projet et, à terme, servir de point d’entrée utilisateur. Le choix d’Angular à l’époque était cohérent avec les compétences disponibles dans l’équipe.

L’ensemble a été construit from scratch — pas de reprise de code existant, pas de framework métier déjà en place. C’était à la fois la difficulté et l’intérêt de la mission : tout poser soi-même, tout arbitrer.

Réalisation

Sur environ 15 mois de mission, les livrables ont été :

• Architecture technique complète d’un écosystème combinant blockchain privée, API métier et interface web
• Smart contracts en Solidity pour la gestion du cycle de vie des interventions sur un véhicule
• Blockchain Ethereum privée opérationnelle, configurée pour les besoins du projet
• API de décodage VIN multi-sources avec cache, pattern adapter et résolution de conflits
• Site vitrine Angular responsive pour présenter le projet

Tout ce qui a été livré fonctionnait techniquement. Les briques pouvaient communiquer entre elles, les smart contracts s’exécutaient, l’API VIN retournait des résultats cohérents.

Le projet n’est jamais sorti

Il faut le dire honnêtement : KarState n’a jamais été lancé commercialement. Les raisons tiennent au modèle économique, au timing marché et à des décisions stratégiques qui ne relevaient pas de la technique. Ce n’est pas un cas rare dans les startups, et encore moins rare dans le monde blockchain de cette époque (2020-2022), où beaucoup de projets conceptuellement solides n’ont pas trouvé leur marché.

Je mentionne ça parce que je pense que c’est plus honnête de le dire que de laisser entendre un succès qui n’a pas eu lieu. Et surtout, parce que ce que je retiens de cette mission n’est pas diminué par l’arrêt du projet.

Ce que j’en retiens

Trois choses.

Construire from scratch force à des décisions qu’on ne prend jamais dans un projet legacy. Quelle blockchain ? Quelle architecture ? Comment identifier un VIN ? Quel framework front ? Chaque choix se défend avec des arguments, chaque choix ferme des portes pour la suite. C’est un exercice de clarté stratégique rare, et incomparablement formateur.

La blockchain, en 2020-2022, exigeait de faire le tri entre le signal et le bruit. Beaucoup de projets s’empilaient des couches blockchain pour faire “tech innovante” sans que ça réponde à un vrai besoin. Sur KarState, le besoin était réel — l’immuabilité du carnet d’entretien est un vrai problème que la blockchain adresse bien. Ce qui a manqué, ce n’est pas la pertinence technique. C’est autre chose.

Un projet non lancé ne rend pas le travail nul. J’ai livré un système qui tenait debout, des choix architecturaux qui étaient justes, du code qui était propre et documenté. Ce travail a existé, il m’a appris, il m’a structuré. Je continue aujourd’hui à appliquer ce que KarState m’a appris sur la confrontation aux technologies émergentes — et sur le fait que, quel que soit le devenir d’un projet, la qualité du travail livré est la seule chose qu’on contrôle vraiment.