Il s'agit d'un projet backend/smart contracts — une architecture et des constats d'audit, pas une interface à capturer. Tout ce qui suit est tiré directement du rapport d'audit et de la configuration CI du dépôt.
Pourquoi deux chaînes
Les données de remboursement médical ne peuvent pas résider sur une chaîne publique — identifiants des patients, codes de diagnostic et montants des demandes sont des données réglementées. Les assureurs et les auditeurs ont pourtant besoin d'une preuve infalsifiable qu'une demande a bien été traitée telle qu'enregistrée. Medichain+ scinde le problème : Hyperledger Fabric porte le cycle de vie à accès restreint des demandes (soumission, instruction, paiement) derrière un contrôle d'accès au niveau des canaux, tandis que Polygon reçoit périodiquement des ancrages cryptographiques (des empreintes, pas les données brutes), afin que toute partie puisse vérifier que le registre Fabric n'a pas été réécrit à son insu.
Parcours d'une demande
N'importe qui peut ensuite vérifier un enregistrement Fabric au regard de son ancrage on-chain sans jamais avoir besoin d'accéder lui-même au réseau Fabric — la chaîne publique prouve l'intégrité, pas le contenu.
Audit de sécurité interne — 19 constats
Avant de considérer ce projet digne de figurer dans mon portfolio, j'ai mené de ma propre initiative un audit de sécurité de la couche smart contracts et chaincode, calqué sur le périmètre d'une véritable revue avant déploiement. Les constats ont été classés par sévérité :
| Sévérité | Nombre | Catégorie de problème représentative |
|---|---|---|
| Critique | 2 | Absence de contrôle d'accès sur une fonction déclenchant un règlement |
| Élevée | 4 | Risque de réentrance dans le circuit de paiement ; valeur de retour d'un appel externe non vérifiée |
| Moyenne | 6 | Cas limites sur les entiers dans le calcul des montants ; absence d'émission d'événement lors d'un changement d'état |
| Faible | 4 | Schémas de stockage peu économes en gas ; messages d'erreur incohérents |
| Informatif | 3 | Documentation NatSpec manquante ; écarts par rapport au guide de style |
Tous les constats de sévérité critique et élevée ont été corrigés avant que le code ne soit jugé stable — le contrôle d'accès a été renforcé au moyen de modificateurs conditionnés par les rôles, et la fonction de paiement a été réécrite selon le schéma checks-effects-interactions afin de fermer la voie de réentrance.
Pipeline CI — 8 jobs
Chaque push déclenche un pipeline GitHub Actions dans lequel l'outillage de sécurité constitue un point de contrôle bloquant, et non une réflexion après coup :
| # | Job | Objectif |
|---|---|---|
| 1 | Lint (Solhint) | Vérification du style et des mauvaises pratiques connues dans les contrats |
| 2 | Compilation | Build Hardhat/Truffle de l'ensemble des contrats |
| 3 | Tests unitaires | Suite de tests de la logique du chaincode et des contrats |
| 4 | Analyse statique (Slither) | Recherche automatisée de schémas de vulnérabilité à chaque PR |
| 5 | Rapport de couverture | Échec en deçà d'un seuil minimal de couverture |
| 6 | Test d'intégration du réseau Fabric | Déploie un réseau Fabric de test et éprouve le chaincode de bout en bout |
| 7 | Déploiement sur testnet (Polygon Mumbai) | Déploie le contrat d'ancrage sur un testnet public |
| 8 | Publication des artefacts et rapports | Publie les artefacts d'audit et de couverture pour revue |
Ce que ce projet démontre
- La modélisation des menaces d'un système où la confidentialité (Fabric) et la preuve d'intégrité (Polygon) répondent à des exigences réellement distinctes, plutôt que de contraindre une seule chaîne à remplir les deux rôles.
- La conduite d'un audit structuré et hiérarchisé par sévérité sur mon propre code, plutôt que de le présumer sûr parce qu'il compile et passe les tests unitaires.
- L'intégration de l'audit et de l'analyse statique à la CI, afin que les régressions soient détectées avant la fusion, et non après.