· Hernán Pérez Rodal · Engineering · 6 min read
Pourquoi nous avons mis la traçabilité on-chain : FSMA 204 compliance au niveau protocole
La plupart des plateformes de traçabilité utilisent la blockchain comme marketing. Nous racontons comment et pourquoi chez Darwin nous l'utilisons au niveau architectural — et quand ça n'a PAS de sens.
TL;DR — Chez Darwin nous avons construit 12 smart contracts sur Polygon PoS + OP Stack L2 pour identity, governance, DID registry et inventaire NFT-based. Ce n’est pas du blockchain-washing : c’est la couche d’intégrité pour la conformité réglementaire. Ce post raconte ce que nous avons mis on-chain, ce que nous avons laissé off-chain, et pourquoi.
Le problème que la base de données ne résout pas
FSMA 204 exige que chaque Critical Tracking Event (CTE) soit traçable, intègre et vérifiable pendant des années. Question évidente : pourquoi ne pas tout stocker dans une DB traditionnelle ?
Parce que lorsque la FDA, un détaillant ou un auditeur indépendant demande :
“Comment savons-nous que les CTEs que vous nous montrez aujourd’hui sont les mêmes que ceux enregistrés au moment où l’événement s’est produit ?”
Dans une DB centralisée, la réponse est : “faites confiance à notre système”. En production, ça ne suffit pas pour :
- Audits multi-tier — le détaillant ne fait pas confiance à la DB du producteur
- Recalls cross-organization — les acteurs ne partagent pas d’infrastructure
- Compliance avec rétention pluriannuelle — les données doivent rester vérifiables même si une entreprise fait faillite
La blockchain résout ça sans “trust me, bro”. Mais uniquement pour les bons champs.
Ce que nous avons mis on-chain (et ce que NON)
✅ On-chain : ce qui définit l’intégrité
| Composant | Pourquoi on-chain |
|---|---|
| Identity (DID registry) | Chaque acteur (producteur, usine, transporteur) a une identité vérifiable sans dépendre d’une autorité centrale |
| Governance | Règles de qui peut signer quel type de CTE, actualisables via multisig avec audit trail |
| NFT-based inventory | Chaque lot = un NFT unique avec historique immuable ; les transferts reflètent le mouvement physique |
| Attestations critiques | Hashes des CTEs clés, signatures numériques, timestamps — le minimum pour prouver l’intégrité sans exposer de data sensible |
| FSMA 204 compliance anchors | Checkpoints vérifiables qu’un auditeur peut reconstruire sans accès à notre infrastructure |
❌ Off-chain : ce que le on-chain casse
| Composant | Pourquoi off-chain |
|---|---|
| Data sensible | Noms, fournisseurs, prix, formulations — rien qui violerait la privacy si exposé |
| Bulk events | Des millions de CTEs/an on-chain seraient prohibitivement chers |
| Médias lourds | Photos, PDFs, preuves numériques — vivent dans Cloud Storage, on-chain uniquement le hash |
| Règles métier dynamiques | Risk scoring, ML anomaly detection — off-chain, actualisables |
| UI state / préférences | Firebase, cache, sessions — rien qui doive être immuable |
La règle que nous utilisons : on-chain uniquement ce qui doit être publiquement vérifiable + immuable + cross-organization. Tout le reste, c’est de la latence et du coût inutiles.
L’architecture : 12 smart contracts
Nous nous sommes posés sur Polygon PoS pour throughput + coût bas, et OP Stack L2 pour les opérations qui exigent un settlement vers Ethereum L1.
Les contrats principaux :
1. Identity layer
DIDRegistry.sol— Decentralized identifiers par acteur (spec W3C DID)RoleManager.sol— Rôles, permissions et délégations avec audit trailAttestationRegistry.sol— Signatures cryptographiques des CTEs clés
2. Governance
Governance.sol— Multisig pour les updates de règlesPolicyEngine.sol— Règles de signature par type d’événement (qui peut signer quoi)
3. Inventory + Traceability
InventoryNFT.sol— ERC-721 étendu : chaque lot est un NFT avec metadata de CTEsTransferLogger.sol— Mouvements physiques reflétés comme transfers on-chainBatchSplitting.sol— Split/merge de lots préservant le lineage
4. Compliance
ComplianceAnchor.sol— Ancre les checkpoints FSMA 204 + EUDR avec timestampRecallRegistry.sol— Recalls cross-organization, vérifiables par quiconqueDocumentRegistry.sol— Hashes de preuves numériques (PDFs, photos, Due Diligence Statements)
5. Integration
BridgeL1.sol— Finalisation sélective vers Ethereum L1 pour les événements critiques (réduit les coûts en maintenant l’intégrité maximale sur l’essentiel)
Ce qui n’a pas marché
Mettre tout on-chain en V0. Première tentative : tous les CTEs on-chain. Résultat : 0,10-0,30 $ par événement, et des milliers d’événements/jour → budget hors de contrôle. Corrigé en V1 avec le principe “seulement checkpoints + hashes”.
Contrats monolithiques. Nous avons commencé avec un seul contract “Traceability.sol” qui faisait tout. Impossible à upgrader sans casser les références. Refactorisé en 12 contrats avec upgradeable proxies (pattern UUPS).
On-chain identity sans fallback off-chain. Quand un producteur rural perdait son wallet, il perdait son identité. Nous avons ajouté un mécanisme de récupération via DID governance multisig — vous ne compromettez pas la décentralisation, mais vous assurez la continuité opérationnelle.
Ce qui a marché
Séparation claire on-chain/off-chain par principe de “nécessité de vérifiabilité”.
UUPS upgradeable proxies — nous pouvons faire évoluer les contrats en préservant historique et références.
NFT par lot, pas par événement — le lot comme entité atomique on-chain ; les événements liés off-chain mais avec hash vérifiable. Équilibre entre coût et intégrité.
Bridge sélectif L1 — seules les attestations critiques atteignent Ethereum L1. Le reste vit sur L2. Coût 100x moindre, intégrité équivalente à 95 %.
Intégration avec détaillants — quand Walmart demande un audit, ils peuvent vérifier nos checkpoints on-chain sans avoir besoin d’accéder à nos systèmes. Ça change le jeu pour le supply chain compliance.
Quand la blockchain n’a PAS de sens
Pour être honnête : la plupart des features de traçabilité n’ont PAS besoin de blockchain.
Si votre cas est :
- Traçabilité interne au sein d’une seule entreprise → une DB suffit
- Peu d’acteurs de confiance qui partagent déjà une infra → DB centralisée + signatures numériques suffit
- Données qui changent fréquemment → vous ne voulez pas d’immuabilité
- Exigences de faible criticité qui ne passent pas d’audit → overhead inutile
La blockchain a du sens quand vous avez besoin que des tiers puissent vérifier l’intégrité sans vous faire confiance. Pour tout le reste, simplifiez.
Lessons learned
- On-chain ≠ tout on-chain — utilisez-la uniquement pour ce qui nécessite une vérifiabilité cross-organization
- L’inventaire NFT-based scale mieux qu’event-based — lot comme atome, événements comme hashes liés
- Les L2s sont le sweet spot — coût bas, sécurité haute pour la plupart des cas ; bridge sélectif vers L1 pour le critique
- Upgradeable proxies dès le jour 0 — le coût initial paie largement quand il faut itérer
- Gardez aussi la governance off-chain — multisig on-chain + processus opérationnels clairs off-chain
Et maintenant ?
Nous explorons les zero-knowledge proofs pour des preuves de compliance sans exposer de données sensibles. Le cas : qu’un détaillant puisse vérifier qu’un lot respecte certains critères (origine, certification, non-déforestation) sans avoir besoin d’accéder à toutes les données du producteur.
Si vous construisez de la traçabilité pour supply chain régulée et hésitez entre DB pure ou blockchain, mon conseil est : commencez par identifier quelles données nécessitent une vérifiabilité cross-organization. Ce sous-ensemble va on-chain. Le reste, non.
Vous évaluez la blockchain pour la traçabilité ? Parlons-en — nous pouvons partager l’architecture et vous aider à décider si le cas le justifie (parfois la réponse est “non, et c’est bien”).
