Portfolio de Jérémy Digard | Mathématiques appliquées : de la théorie à l'impact
Étudiant en mathématiques à l'EPFL, j'explore comment appliquer la théorie pour concevoir des systèmes robustes face à des problèmes concrets. Ce site documente mes études de cas techniques.
Assurance paramétrique décentralisée
Investigation
Pour comprendre les raisons de l'échec de l'assurance agricole traditionnelle, je me suis rendu sur le terrain, au sein de l'exploitation fruitière de 60 hectares de la SAS Le Rialet.
En analysant les contrats d'assurance "papiers" avec l'exploitant, le problème est devenu évident : ce n'était pas un manque de données, mais un manque de transparence. Le déclenchement du remboursement dépendait d'une expertise humaine subjective et souvent trop lente.
Le constat : L'agriculteur n'a pas besoin d'une promesse de remboursement, il a besoin d'une garantie mathématique.
Le Défi : Connecter le Réel à la Blockchain
Ici, le défi majeur est la véracité de la donnée. Comment faire entrer un événement physique, comme une sécheresse, dans un système numérique fermé ?
J'ai conçu une architecture d'Oracles hybride :
- Sécurité Matérielle (Hardware) : Utilisation d'enclaves AWS pour certifier que la donnée météo n'a pas été altérée
- Logique Formelle (Move) : Traduction des clauses du contrat papier (ex: "si pluie < 50mm") en un Smart Contract immuable.
Solution : Une Protection Instantanée
Avec Robin Sanders, nous avons collaboré pour rendre cette complexité invisible. Tandis que je sécurisais l'architecture backend (Sui Blockchain), il a conçu une interface fluide permettant une souscription en quelques secondes.
Le résultat est une Proof of Concept fonctionnelle où :
- L'utilisateur souscrit sans compte bancaire (via zkLogin).
- Il reçoit un NFT : sa police d'assurance traçable.
- En cas de sinistre validé par l'Oracle, la trésorerie (placée en DeFi pour générer des rendements) déclenche le virement instantanément.
Impact
La technologie blockchain peut servir une cause sociale concrète : l'inclusion financière des populations non-bancarisées (à l'image de Julius, un fermier du Malawi cité dans nos recherches : voir l'article du Guardian).
Toutefois, le véritable obstacle reste l'intégration légale et la nécessité d'une réassurance systémique face aux risques climatiques.
Equissima – Algorithmique d'optimisation de planning
Le Problème : Un Chaos Logistique
Le Concours Complet d'Équitation est un triathlon logistique où des cavaliers enchaînent trois épreuves avec des temps de repos stricts. Jusqu'ici, la planification était manuelle et statique. C'était un système fragile : à la moindre chute ou retard, le planning papier devenait obsolète et impossible à recalculer en direct.
L'enjeu : Comment garantir mathématiquement la fluidité de l'événement sans sacrifier le bien-être des chevaux ni la sérénité des bénévoles ?
1. Comprendre avant de Résoudre
Mon premier obstacle était contextuel. J'ai passé du temps avec les juges et les organisateurs pour comprendre les contraintes invisibles de l'événement.
Cette immersion m'a appris une leçon d'humilité : la rigueur mathématique est stérile si elle ne s'ancre pas dans l'empathie pour les utilisateurs finaux (le stress d'un cheval au paddock, le temps de "remise en état" d'une piste).
2. Le Défi de la Traduction : Identifier le Goulot d'Étranglement
Le second défi a été de traduire ces contraintes organiques (flux continu, aléas) en un langage formel. Les simulations classiques (O(N²)) étaient trop lentes pour le direct.
J'ai changé de paradigme en modélisant le concours comme un Système à Événements Discrets dans l'algèbre Max-Plus. (Voir la preuve mathématique)
Cette approche permet une résolution en temps constant (O(1)) et offre un avantage décisif : la détection automatique du goulot d'étranglement. En calculant la valeur propre du système, l'algorithme pointe immédiatement la ressource critique (ex: "c'est la transition Dressage/Saut qui bloque"), permettant une optimisation ciblée impossible à voir à l'œil nu. (Voir le code)
3. L'Impact : De la Gestion de Crise à la Sérénité
La finalité de ce projet est son utilité sociale. L'algorithme ne remplace pas l'humain ; il l'augmente en lui redonnant le contrôle.
En passant d'une gestion réactive à proactive, le logiciel garantit l'équité sportive et réduit la charge mentale des bénévoles.
C'est aujourd'hui le seul logiciel capable de gérer cette spécificité (le "No-Wait Flow Shop" avec ressources partagées).
La solution est officiellement recommandée par le créateur du concept dans le guide technique de référence.
Détection en Live de pommes mures
Le Problème : L'Inefficacité du « Chercher‑Cueillir »
La SAS Le Rialet gère 60 hectares de production fruitière. Lors de la récolte des pommes (lady), le goulot d'étranglement n'est pas la cueillette elle‑même, mais la décision : identifier instantanément les fruits mûrs au milieu du feuillage (ce qui nécessite une formation pour savoir quand une lady est mûre).
Les solutions autonomes de ramassage actuelles sont trop lentes et trop coûteuses.
L'enjeu : Comment augmenter la productivité et réduire la charge mentale des saisonniers ?
Un modèle de détection fonctionne à environ 15 FPS. Or, pour superposer des informations sur la réalité sans donner la nausée à l'utilisateur, l'affichage doit se rafraîchir à plus de 60 FPS.
J'ai élaboré une stratégie de découplage :
- La couche « Lente » (IA) : L'algorithme de vision (semblable à YOLO‑seg) analyse l'image périodiquement pour identifier les pommes mûres.
- La couche « Rapide » (Spatial Computing) : On utilise les capteurs inertiels (IMU) et le suivi 6DOF des lunettes pour « ancrer » virtuellement le résultat.
J'ai écarté les solutions VR (trop lourdes, pas de vision périphérique) pour me concentrer sur les lunettes XREAL (Optical See‑Through).
Poids inférieur à 90 g (pour des shifts de 8 heures), luminosité extérieure et SDK permettant l'ancrage spatial.
J'ai contacté le constructeur pour proposer un cas d'usage industriel inédit, afin de valider cette architecture en conditions réelles (soleil, poussière).
Il ne s'agit pas seulement d'entraîner un modèle IA, mais de comprendre comment l'intégrer dans un flux de données en temps réel pour qu'il soit ergonomiquement viable pour un humain.
Détection en temps réel de la structure cognitive interne
Lors de ma formation au Process Communication Model (PCM), il faut identifier la structure de personnalité de l'autre et adapter son langage pour bien communiquer.
En pratique, c'est cognitivement épuisant : tenter d'analyser la syntaxe de son interlocuteur tout en maintenant une conversation fluide mène à une saturation mentale. Même le formateur ne peut pas écouter, analyser et corriger dix élèves simultanément.
L'objectif était de réaliser une analyse psychologique sur un flux audio continu, multi‑locuteurs et en direct.
- Isoler la voix de l'utilisateur cible parmi les autres.
- Transcrire le flux en texte avec un buffer glissant.
- Effectuer l'analyse psychologique instantanée (Llama).
Rq : l'analyse de la prosodie a été écartée car le gain de performance est mineur et seul le modèle propriétaire de hume.ai le permet. Le réel gain réside dans la compréhension de la théorie PCM par le modèle d'IA (sur lequel je travaille pour créer un modèle fine‑tuned et non prompté).
Le principal problème rencontré est le Cocktail Party Problem : identifier la voix du locuteur parmi une discussion. Je l'ai résolu en utilisant un extrait de la voix du locuteur enregistré seul, placé au début du chunk inféré par MossFormer.
Analyser la psychologie d'une personne est intrusif. Tout fonctionne sur mes propres serveurs, sans API externe, afin de protéger l'utilisateur.
Le système fonctionne via WebSocket et fournit un feedback en temps réel (latence < 3 s) à tous les apprenants/formateurs de tiptopconseil.fr.
Ce projet démontre qu'il est possible de combiner des modèles d'IA pour créer un outil pédagogique qui ne remplace pas le formateur, mais accélère l'apprentissage.
Cette architecture permet d'accélérer l'apprentissage des étudiants en centre de formation PCM qui l'utilisent depuis février 2026.
graph TB
A[Audio 48 kHz] --> B(MossFormer - Séparation)
B --> C(WhisperX - Transcription)
C --> D(Llama - Analyse)
D --> E[Feedback Utilisateur]