Mémoire de Master — Analyse et questions d'examinateur

A. Contradiction majeure sur la signature des transactions.
Le §3.3.2 (Sécurité) affirme : « les transactions blockchain sont signées cryptographiquement par le wallet Ethereum de l'acteur initiateur, garantissant la non-répudiation ». Le §5.2 (Implémentation) indique : « le backend charge l'ABI du contrat et son adresse […] et signe les transactions à l'aide d'une clé privée sécurisée côté serveur ». Les deux affirmations sont incompatibles. Si toutes les transactions sont signées par une clé serveur unique, alors : (i) il n'y a aucune non-répudiation — l'identité on-chain de tous les acteurs est identique ; (ii) le système est entièrement recentralisé sur le serveur Render ; (iii) quiconque compromet cette clé peut écrire ce qu'il veut sur la chaîne au nom de n'importe quel acteur. L'argument central du mémoire — décentralisation et confiance sans intermédiaire — s'effondre sur ce point.

B. La conformité EUDR est revendiquée mais non implémentée.
Le §3.4.2 affirme que l'EUDR « implique notamment la géolocalisation des parcelles de production et la traçabilité jusqu'au producteur individuel — deux fonctionnalités que le système AgriTrace adresse directement ». Or : le schéma de base de données (Fig. 4.2, table lots) ne contient aucun champ de coordonnées GPS, et la struct Lot du smart contract (Annexe A) non plus. Il n'existe ni parcelle, ni polygone, ni latitude/longitude nulle part dans le modèle. La revendication de conformité EUDR n'est donc soutenue par aucune donnée dans le système.

C. Le modèle de lot ne gère ni agrégation ni scission.
C'est le problème le plus fondamental. Le chapitre 1 explique très bien que les pisteurs agrègent du cacao provenant de multiples producteurs, que les coopératives regroupent, que les exportateurs conditionnent en conteneurs. Or le modèle de données traite le lot comme une entité atomique et immuable, de la récolte à l'export, avec un producteur unique. Le cas d'usage « Agréger les sacs en conteneurs » figure dans le diagramme de cas d'utilisation mais n'a aucune contrepartie ni dans la struct Lot, ni dans le schéma relationnel, ni dans les tests. Un système de traçabilité cacao qui ne modélise pas le mélange de lots ne trace pas la réalité de la filière.

D. Divergence du modèle de prix entre on-chain et off-chain.
La table prix_bord_champ possède les colonnes produit, campagne, date_effet — modèle multi-campagne correct. Le smart contract utilise un simple mapping prixOfficielParProduit[uint256] : un seul prix courant par produit, sans notion de campagne ni de date d'effet. Conséquence : un lot récolté en campagne N mais validé après changement de prix sera contrôlé contre le mauvais seuil, et il est impossible d'auditer a posteriori quel prix était en vigueur au moment d'une transaction donnée. C'est un défaut de conception réel, pas un détail.

E. Valeurs d'initialisation dangereuses dans le constructeur.
Le contrat déployé s'initialise à 900 / 1500 / 300 FCFA/kg (café / cacao / anacarde), alors que les prix 2025-2026 sont 1700 et 2800. Entre le déploiement et l'appel à setPrixOfficiel(), le contrat accepte activement des transactions à 1500 FCFA/kg pour le cacao — soit exactement la fraude que le système prétend empêcher. Le candidat le signale honnêtement en annexe, mais initialiser à zéro (ou bloquer toute validation tant que le prix n'est pas défini) était la conception sûre.

F. Le « triple verrou » est un simple verrou avec deux confirmations d'ergonomie.
Les niveaux 1 (Flutter) et 2 (API) sont contournables par construction — le mémoire l'admet pour le niveau 1. Seul le niveau 3 (smart contract) offre une garantie. Présenter cela comme une « défense en profondeur » et comme « contribution originale majeure » est une surévaluation rhétorique. Par ailleurs, le contournement décisif n'est pas d'attaquer les trois niveaux : c'est de déclarer 2800 dans le système et d'en payer 2000 en espèces. Le mémoire le reconnaît, mais après avoir construit tout son argumentaire de validation dessus.

G. Aucune mesure quantitative.
Le §6.4 « Analyse des performances » ne contient aucun chiffre mesuré : « quelques centaines de millisecondes », « quelques secondes à quelques dizaines de secondes ». Aucun coût en gas mesuré, aucun débit, aucune latence instrumentée, aucun test de charge. Le titre de la section n'est pas honoré.

H. « Taux de transactions non conformes : nul par construction ».
Le §6.4 présente comme indicateur de performance un résultat qui est une tautologie : le contrat rejette les transactions non conformes, donc il n'en enregistre aucune. Ce n'est pas un résultat expérimental, c'est la reformulation d'une spécification.

I. Onze tests manuels, zéro test automatisé.
Hardhat fournit un environnement de test unitaire complet (Mocha/Chai, couverture, fuzzing). Aucun test unitaire Solidity n'est mentionné, ni couverture de code, ni test de régression. Pour un contrat immuable une fois déployé, c'est un manquement sérieux.

J. Aucune analyse de sécurité du smart contract.
Pas un mot sur : contrôle d'accès (onlyOwner, rôles — qui peut appeler creerLot() ? setPrixOfficiel() ?), réentrance, dépassement de gas sur les tableaux d'historique croissants, DoS par saturation, absence de mécanisme de pause d'urgence, absence de proxy d'upgrade. Or le mémoire souligne lui-même l'immutabilité : un bug déployé est définitif.

K. RGPD et données personnelles sur blockchain publique.
Le système enregistre des identités de producteurs sur un registre public, immuable et mondialement consultable, dans un dispositif dont la finalité affichée est la conformité à une réglementation… de l'Union européenne. Le RGPD impose un droit à l'effacement techniquement incompatible avec l'immutabilité d'une blockchain publique. Aucune mention dans le mémoire.

L. Confidentialité commerciale ignorée.
Le Tableau 2.1 note lui-même que la confidentialité d'une blockchain publique est « nulle ». Le système y publie prix, volumes, identités d'acheteurs et d'exportateurs — des données commercialement sensibles. Aucun exportateur n'acceptera de rendre publics ses volumes et ses fournisseurs. Cet obstacle à l'adoption, pourtant rédhibitoire, n'est jamais discuté.

M. « Décentralisé » avec quatre dépendances centralisées.
Render (backend), Neon (base), Pinata (pinning IPFS), Alchemy (accès RPC), plus Firebase et Resend. Le §3.3.2 affirme que « le système ne présente pas de point de défaillance unique ». C'est inexact : si Render tombe, l'application mobile ne fonctionne plus ; si Pinata cesse le pinning, les certificats deviennent irrécupérables (seul le hash subsiste).

N. Gouvernance des prix mal attribuée.
Dans le système, c'est l'Administrateur (acteur technique) qui « définit les prix bord champ ». Dans la réalité institutionnelle décrite au chapitre 1, ce sont le CCC et le CCA qui les fixent. Le système confie donc le paramètre le plus sensible à un rôle technique sans légitimité réglementaire. De plus, le CCA fixe légalement un prix à au moins 60 % du cours international (§1.2.3) — donc variable — ce que le modèle à valeur fixe ne capte pas.

O. Aucune validation utilisateur de l'« interface inclusive ».
L'inclusivité est annoncée comme l'une des quatre contributions principales. Elle repose sur des principes de conception raisonnables (pictogrammes, OTP, réduction du texte), mais aucun producteur n'a testé l'application. Aucun test utilisateur, aucun questionnaire SUS, aucun taux de réussite de tâche. Une contribution en accessibilité non évaluée auprès du public cible n'est pas démontrée.

P. Persistance de Sepolia.
Le mémoire fonde son argument d'immutabilité sur un déploiement testnet. Or les testnets Ethereum sont dépréciés régulièrement (Ropsten, Rinkeby, Kovan, Goerli l'ont tous été). L'historique « immuable » d'AgriTrace peut disparaître avec le réseau qui l'héberge.