1130 lines
70 KiB
HTML
1130 lines
70 KiB
HTML
<!DOCTYPE html>
|
||
<html lang="fr">
|
||
<head>
|
||
<meta charset="UTF-8"/>
|
||
<meta name="viewport" content="width=device-width, initial-scale=1.0"/>
|
||
<title>TIPE – Codes LDPC · Guide Oral</title>
|
||
<link href="https://fonts.googleapis.com/css2?family=Playfair+Display:wght@400;600;700&family=Nunito:wght@300;400;500;600;700&family=Fira+Code:wght@400;500&display=swap" rel="stylesheet"/>
|
||
<style>
|
||
:root{
|
||
--bg: #080d17;
|
||
--bg2: #0f1624;
|
||
--card: #111c2d;
|
||
--card2: #0d1520;
|
||
--border: #1d2e47;
|
||
--border2: #243548;
|
||
--amber: #f5a623;
|
||
--amber2: #fbbf24;
|
||
--sky: #38bdf8;
|
||
--green: #34d399;
|
||
--red: #f87171;
|
||
--purple: #a78bfa;
|
||
--text: #e2e8f0;
|
||
--text2: #94a3b8;
|
||
--text3: #64748b;
|
||
--mono: 'Fira Code', monospace;
|
||
--serif: 'Playfair Display', serif;
|
||
--sans: 'Nunito', sans-serif;
|
||
}
|
||
*{box-sizing:border-box;margin:0;padding:0;}
|
||
html{scroll-behavior:smooth;}
|
||
body{background:var(--bg);color:var(--text);font-family:var(--sans);font-size:15px;line-height:1.7;overflow-x:hidden;}
|
||
|
||
/* NAV */
|
||
nav{position:sticky;top:0;z-index:100;background:rgba(8,13,23,.92);backdrop-filter:blur(12px);border-bottom:1px solid var(--border);padding:0 2rem;display:flex;align-items:center;gap:0;height:54px;overflow-x:auto;}
|
||
nav a{color:var(--text2);text-decoration:none;font-size:13px;font-weight:600;letter-spacing:.04em;white-space:nowrap;padding:0 14px;height:54px;display:flex;align-items:center;border-bottom:2px solid transparent;transition:all .2s;}
|
||
nav a:hover,nav a.active{color:var(--amber);border-bottom-color:var(--amber);}
|
||
nav .logo{color:var(--amber);font-family:var(--serif);font-size:17px;margin-right:20px;white-space:nowrap;border-bottom:none !important;}
|
||
|
||
/* HERO */
|
||
.hero{padding:80px 2rem 60px;max-width:1100px;margin:0 auto;}
|
||
.hero h1{font-family:var(--serif);font-size:clamp(2.2rem,5vw,3.4rem);font-weight:700;line-height:1.15;color:#fff;}
|
||
.hero h1 em{color:var(--amber);font-style:normal;}
|
||
.hero p{color:var(--text2);max-width:640px;margin-top:16px;font-size:16px;}
|
||
.meta-row{display:flex;flex-wrap:wrap;gap:12px;margin-top:28px;}
|
||
.badge{display:inline-flex;align-items:center;gap:6px;background:var(--card);border:1px solid var(--border);border-radius:6px;padding:6px 14px;font-size:12px;font-family:var(--mono);color:var(--text2);}
|
||
.badge span{color:var(--amber);}
|
||
|
||
/* SECTIONS */
|
||
section{max-width:1100px;margin:0 auto;padding:60px 2rem;}
|
||
.sec-header{display:flex;align-items:baseline;gap:14px;margin-bottom:36px;}
|
||
.sec-header h2{font-family:var(--serif);font-size:clamp(1.5rem,3vw,2.1rem);color:#fff;}
|
||
.sec-num{font-family:var(--mono);color:var(--amber);font-size:13px;opacity:.7;}
|
||
.divider{border:none;border-top:1px solid var(--border);margin:0;}
|
||
|
||
/* TWO-COL */
|
||
.two-col{display:grid;grid-template-columns:1fr 1fr;gap:24px;}
|
||
@media(max-width:700px){.two-col{grid-template-columns:1fr;}}
|
||
|
||
/* CARDS */
|
||
.card{background:var(--card);border:1px solid var(--border);border-radius:12px;padding:22px 24px;}
|
||
.card h3{font-size:15px;font-weight:700;margin-bottom:14px;display:flex;align-items:center;gap:8px;}
|
||
.card h3 .icon{font-size:18px;}
|
||
.card ul{list-style:none;display:flex;flex-direction:column;gap:10px;}
|
||
.card ul li{display:flex;gap:10px;align-items:flex-start;color:var(--text2);font-size:14px;line-height:1.6;}
|
||
.card ul li::before{content:'';width:6px;height:6px;border-radius:50%;margin-top:8px;flex-shrink:0;}
|
||
.card.good ul li::before{background:var(--green);}
|
||
.card.bad ul li::before{background:var(--red);}
|
||
.card.warn ul li::before{background:var(--amber);}
|
||
.card ul li strong{color:var(--text);}
|
||
|
||
/* TIMING TIMELINE */
|
||
.timeline{display:flex;flex-direction:column;gap:4px;margin-top:8px;}
|
||
.tl-row{display:flex;align-items:center;gap:12px;}
|
||
.tl-label{font-family:var(--mono);font-size:11px;color:var(--text3);width:180px;flex-shrink:0;}
|
||
.tl-bar-wrap{flex:1;background:var(--bg2);border-radius:4px;height:22px;overflow:hidden;border:1px solid var(--border);}
|
||
.tl-bar{height:100%;border-radius:4px;display:flex;align-items:center;padding-left:8px;font-size:11px;font-family:var(--mono);color:#fff;font-weight:600;white-space:nowrap;}
|
||
.tl-time{font-family:var(--mono);font-size:11px;color:var(--text3);width:50px;text-align:right;flex-shrink:0;}
|
||
.col-intro{background:linear-gradient(90deg,#6366f1,#818cf8);}
|
||
.col-lineaire{background:linear-gradient(90deg,#0891b2,#38bdf8);}
|
||
.col-ldpc{background:linear-gradient(90deg,#059669,#34d399);}
|
||
.col-tanner{background:linear-gradient(90deg,#d97706,#f59e0b);}
|
||
.col-enc{background:linear-gradient(90deg,#dc2626,#f87171);}
|
||
.col-bf{background:linear-gradient(90deg,#7c3aed,#a78bfa);}
|
||
.col-soft{background:linear-gradient(90deg,#be185d,#f472b6);}
|
||
.col-analyse{background:linear-gradient(90deg,#065f46,#10b981);}
|
||
.col-ccl{background:linear-gradient(90deg,#92400e,#fbbf24);}
|
||
|
||
.timer-total{background:var(--card);border:1px solid var(--amber);border-radius:10px;padding:16px 24px;margin-top:24px;display:flex;align-items:center;gap:16px;}
|
||
.timer-total .big{font-family:var(--mono);font-size:2.4rem;color:var(--amber);font-weight:700;}
|
||
.timer-total .desc{color:var(--text2);font-size:14px;}
|
||
|
||
/* SLIDES */
|
||
.slides-grid{display:flex;flex-direction:column;gap:16px;}
|
||
.slide-card{background:var(--card);border:1px solid var(--border);border-radius:12px;overflow:hidden;transition:border-color .2s;}
|
||
.slide-card:hover{border-color:var(--border2);}
|
||
.slide-header{display:flex;align-items:center;gap:12px;padding:14px 20px;border-bottom:1px solid var(--border);cursor:pointer;user-select:none;}
|
||
.slide-num{font-family:var(--mono);font-size:11px;padding:3px 8px;border-radius:4px;color:#fff;font-weight:700;flex-shrink:0;}
|
||
.slide-title{font-weight:700;font-size:14px;flex:1;}
|
||
.slide-timing{font-family:var(--mono);font-size:12px;padding:3px 10px;border-radius:20px;background:rgba(56,189,248,.1);color:var(--sky);border:1px solid rgba(56,189,248,.2);flex-shrink:0;}
|
||
.slide-section-tag{font-size:11px;color:var(--text3);font-family:var(--mono);flex-shrink:0;}
|
||
.slide-body{padding:20px 24px;display:none;}
|
||
.slide-body.open{display:block;}
|
||
.slide-script{background:var(--bg2);border-left:3px solid var(--amber);border-radius:0 8px 8px 0;padding:16px 20px;font-size:14px;line-height:1.8;color:var(--text);margin-bottom:14px;font-family:var(--sans);}
|
||
.slide-script em{color:var(--amber);font-style:normal;font-weight:600;}
|
||
.slide-note{display:flex;gap:10px;align-items:flex-start;background:rgba(167,139,250,.08);border:1px solid rgba(167,139,250,.2);border-radius:8px;padding:12px 16px;font-size:13px;color:var(--text2);}
|
||
.slide-note .note-icon{font-size:16px;flex-shrink:0;margin-top:1px;}
|
||
.slide-note.green{background:rgba(52,211,153,.06);border-color:rgba(52,211,153,.2);color:#86efac;}
|
||
.slide-note.warn{background:rgba(245,166,35,.06);border-color:rgba(245,166,35,.2);color:#fcd34d;}
|
||
.slide-note.red{background:rgba(248,113,113,.06);border-color:rgba(248,113,113,.2);color:#fca5a5;}
|
||
.expand-icon{color:var(--text3);font-size:18px;transition:transform .2s;}
|
||
.slide-card.open .expand-icon{transform:rotate(180deg);}
|
||
|
||
/* SECTION COLORS FOR SLIDE NUMS */
|
||
.sn-intro{background:#6366f1;}
|
||
.sn-lin{background:#0891b2;}
|
||
.sn-shan{background:#059669;}
|
||
.sn-ldpc{background:#d97706;}
|
||
.sn-tanner{background:#f59e0b;}
|
||
.sn-enc{background:#dc2626;}
|
||
.sn-bf{background:#7c3aed;}
|
||
.sn-soft{background:#be185d;}
|
||
.sn-analyse{background:#065f46;}
|
||
.sn-ccl{background:#92400e;}
|
||
|
||
/* REVIEW SECTION */
|
||
.review-grid{display:grid;grid-template-columns:1fr 1fr;gap:20px;}
|
||
@media(max-width:700px){.review-grid{grid-template-columns:1fr;}}
|
||
.review-card{background:var(--card);border:1px solid var(--border);border-radius:12px;padding:22px 24px;}
|
||
.review-card h4{font-size:14px;font-weight:700;margin-bottom:14px;color:var(--sky);font-family:var(--mono);}
|
||
.review-card .formula{background:var(--bg2);border:1px solid var(--border);border-radius:6px;padding:10px 14px;font-family:var(--mono);font-size:13px;color:var(--amber);margin:8px 0;}
|
||
.review-card p{font-size:13px;color:var(--text2);line-height:1.7;}
|
||
.review-card ul{list-style:disc;padding-left:18px;font-size:13px;color:var(--text2);display:flex;flex-direction:column;gap:6px;}
|
||
|
||
/* TIPS */
|
||
.tips-grid{display:grid;grid-template-columns:1fr 1fr 1fr;gap:16px;}
|
||
@media(max-width:900px){.tips-grid{grid-template-columns:1fr 1fr;}}
|
||
@media(max-width:600px){.tips-grid{grid-template-columns:1fr;}}
|
||
.tip-card{background:var(--card);border:1px solid var(--border);border-radius:12px;padding:20px;}
|
||
.tip-card .tip-icon{font-size:24px;margin-bottom:10px;}
|
||
.tip-card h4{font-size:14px;font-weight:700;color:var(--text);margin-bottom:8px;}
|
||
.tip-card p{font-size:13px;color:var(--text2);line-height:1.7;}
|
||
|
||
/* FOOTER */
|
||
footer{text-align:center;padding:40px;color:var(--text3);font-size:12px;font-family:var(--mono);}
|
||
|
||
/* OPEN ALL BUTTON */
|
||
.btn{background:var(--amber);color:#000;font-weight:700;font-size:13px;padding:9px 18px;border-radius:7px;border:none;cursor:pointer;font-family:var(--sans);transition:opacity .2s;}
|
||
.btn:hover{opacity:.85;}
|
||
.btn.ghost{background:transparent;color:var(--amber);border:1px solid var(--amber);}
|
||
|
||
/* Scroll top */
|
||
#top-anchor{position:absolute;top:0;}
|
||
|
||
/* QUICK ISSUE BANNER */
|
||
.issue-banner{background:linear-gradient(135deg,rgba(248,113,113,.08),rgba(251,191,36,.08));border:1px solid rgba(248,113,113,.25);border-radius:12px;padding:20px 24px;margin-bottom:28px;}
|
||
.issue-banner h3{color:var(--red);font-size:14px;font-weight:700;margin-bottom:8px;}
|
||
.issue-banner p{font-size:13px;color:var(--text2);}
|
||
|
||
/* progress legend */
|
||
.legend{display:flex;flex-wrap:wrap;gap:10px;margin-top:20px;}
|
||
.leg-item{display:flex;align-items:center;gap:6px;font-size:12px;color:var(--text2);}
|
||
.leg-dot{width:12px;height:12px;border-radius:2px;flex-shrink:0;}
|
||
</style>
|
||
</head>
|
||
<body>
|
||
<div id="top-anchor"></div>
|
||
|
||
<nav>
|
||
<a class="logo" href="#top-anchor">⚡ LDPC · TIPE</a>
|
||
<a href="#analyse">Analyse</a>
|
||
<a href="#minutage">Minutage</a>
|
||
<a href="#script">Script</a>
|
||
<a href="#reviser">À réviser</a>
|
||
<a href="#jury">Jury & Conseils</a>
|
||
</nav>
|
||
|
||
<!-- HERO -->
|
||
<div class="hero">
|
||
<h1>Guide Oral TIPE<br/><em>Codes LDPC</em></h1>
|
||
<p>Analyse complète de ta présentation, script mot-à-mot pour chaque slide, minutage précis et points techniques à maîtriser pour les 15 minutes d'exposé.</p>
|
||
<div class="meta-row">
|
||
<div class="badge">Slides : <span>35</span></div>
|
||
<div class="badge">Durée cible : <span>15 min 00s</span></div>
|
||
<div class="badge">Format : <span>Anthony PERRONI · n°49871</span></div>
|
||
<div class="badge">Outil : <span>Typst — Annexes Rust</span></div>
|
||
</div>
|
||
</div>
|
||
<hr class="divider" style="max-width:1100px;margin:0 auto;"/>
|
||
|
||
<!-- ================================================ ANALYSE ================================================ -->
|
||
<section id="analyse">
|
||
<div class="sec-header">
|
||
<span class="sec-num">01</span>
|
||
<h2>Analyse globale</h2>
|
||
</div>
|
||
|
||
<div class="issue-banner">
|
||
<h3>⚠ Point critique de rythme</h3>
|
||
<p>35 slides en 15 minutes = <strong>~26 secondes par slide en moyenne</strong>. C'est tendu mais tenable à condition de traiter certaines slides en "animation rapide" (15s) et de garder les 50-60s pour les slides cruciales (Sum-Product, Shannon, LLR). Le minutage slide-à-slide ci-dessous a été calibré pour tomber pile à 15 min.</p>
|
||
</div>
|
||
|
||
<div class="two-col">
|
||
<div class="card good">
|
||
<h3><span class="icon">✅</span> Ce qui fonctionne très bien</h3>
|
||
<ul>
|
||
<li><strong>Ouverture par des applications concrètes</strong> (drone FPV, satellite Athena-Fidus) — accroche excellente, le jury est immédiatement dans le concret.</li>
|
||
<li><strong>Narration « Shannon → NP-hard → LDPC »</strong> — le fil conducteur est limpide : on pose le problème, on montre le mur théorique, on propose la solution. Très bien construit.</li>
|
||
<li><strong>Démonstration par image</strong> (slide 30/35) — extrêmement frappante visuellement, c'est le point fort mémorable de toute la présentation.</li>
|
||
<li><strong>Courbe waterfall comparative</strong> (slide 32/35) — climax parfait de la partie analyse : trois algorithmes sur le même graphe, un seul regard suffit.</li>
|
||
<li><strong>Progression hard → soft décoding</strong> — la transition Bit-Flipping → LLR → Sum-Product → Min-Sum est pédagogiquement très claire.</li>
|
||
<li><strong>Code source Rust en annexe</strong> — montre une implémentation sérieuse et complète ; atout fort si le jury pose des questions sur la mise en œuvre.</li>
|
||
<li><strong>Illustration du LLR</strong> (slide 27/35) — axe signé avec valeur et confiance, très bien visualisé.</li>
|
||
</ul>
|
||
</div>
|
||
|
||
<div class="card bad">
|
||
<h3><span class="icon">⚠️</span> Ce qu'il faut corriger ou renforcer</h3>
|
||
<ul>
|
||
<li><strong>Slide 35/35 (Conclusion) trop creuse</strong> — « QC-LDPC / FPGA / Test Réels » : trois mots sans bilan. Il faut absolument improviser un résumé fort oralement (voir script).</li>
|
||
<li><strong>Slide 34/35 (Méthode de génération)</strong> — trois noms listés sans comparaison ni résultat. La slide semble incomplète. Compenser dans le discours avec un mini-tableau comparatif oral.</li>
|
||
<li><strong>Slide 26/35 (Syndrome et Analyse)</strong> — courbe intéressante mais difficile à expliquer en 20s. Si tu manques de temps à l'oral, zapper après deux phrases.</li>
|
||
<li><strong>Encodage dense (slide 22)</strong> — tu soulèves le problème de la densification de G mais la solution (Richardson-Urbanke, QC-LDPC) n'est qu'en annexe. Mentionner explicitement oralement.</li>
|
||
<li><strong>Slide 1 (Utilisation) sans légendes</strong> — les URLs seules ne parlent pas au jury. Tout repose sur ton discours oral ; le script ci-dessous comble ce vide.</li>
|
||
<li><strong>Slides 8–9 (Exemple code (5,2))</strong> — deux slides pour un exemple basique, c'est serré en temps. Objectif : 15–20s par slide, aller vite, ne pas s'attarder.</li>
|
||
<li><strong>Lien explicite Shannon ↔ algorithmes manquant à l'oral</strong> — quand tu présentes la slide waterfall comparative (32/35), dis explicitement les distances à la limite : Sum-Product à 1–1.5 dB, Bit-Flipping à 5–6 dB.</li>
|
||
</ul>
|
||
</div>
|
||
</div>
|
||
</section>
|
||
<hr class="divider" style="max-width:1100px;margin:0 auto;"/>
|
||
|
||
<!-- ================================================ MINUTAGE ================================================ -->
|
||
<section id="minutage">
|
||
<div class="sec-header">
|
||
<span class="sec-num">02</span>
|
||
<h2>Guide de minutage</h2>
|
||
</div>
|
||
|
||
<p style="color:var(--text2);margin-bottom:28px;">Chaque section doit consommer exactement ce temps. Les barres sont proportionnelles. <strong style="color:var(--amber)">Garde un œil sur ta montre aux transitions de section.</strong></p>
|
||
|
||
<div class="timeline">
|
||
<div class="tl-row">
|
||
<div class="tl-label">Intro · slides 1→4</div>
|
||
<div class="tl-bar-wrap" style="max-width:600px;">
|
||
<div class="tl-bar col-intro" style="width:14.4%">1:30</div>
|
||
</div>
|
||
<div class="tl-time">1:30</div>
|
||
</div>
|
||
<div class="tl-row">
|
||
<div class="tl-label">Codes linéaires · 5→9</div>
|
||
<div class="tl-bar-wrap" style="max-width:600px;">
|
||
<div class="tl-bar col-lineaire" style="width:22.2%">2:10</div>
|
||
</div>
|
||
<div class="tl-time">2:10</div>
|
||
</div>
|
||
<div class="tl-row">
|
||
<div class="tl-label">Shannon + NP · 10→11</div>
|
||
<div class="tl-bar-wrap" style="max-width:600px;">
|
||
<div class="tl-bar col-ldpc" style="width:11.7%">1:05</div>
|
||
</div>
|
||
<div class="tl-time">1:05</div>
|
||
</div>
|
||
<div class="tl-row">
|
||
<div class="tl-label">Déf. LDPC · 12→15</div>
|
||
<div class="tl-bar-wrap" style="max-width:600px;">
|
||
<div class="tl-bar col-tanner" style="width:22.2%">2:10</div>
|
||
</div>
|
||
<div class="tl-time">2:10</div>
|
||
</div>
|
||
<div class="tl-row">
|
||
<div class="tl-label">Tanner · 16→21</div>
|
||
<div class="tl-bar-wrap" style="max-width:600px;">
|
||
<div class="tl-bar col-enc" style="width:13.3%">1:20</div>
|
||
</div>
|
||
<div class="tl-time">1:20</div>
|
||
</div>
|
||
<div class="tl-row">
|
||
<div class="tl-label">Encodage · 22</div>
|
||
<div class="tl-bar-wrap" style="max-width:600px;">
|
||
<div class="tl-bar col-bf" style="width:5%">30s</div>
|
||
</div>
|
||
<div class="tl-time">0:30</div>
|
||
</div>
|
||
<div class="tl-row">
|
||
<div class="tl-label">Bit-Flipping · 23→26</div>
|
||
<div class="tl-bar-wrap" style="max-width:600px;">
|
||
<div class="tl-bar col-soft" style="width:16.7%">1:40</div>
|
||
</div>
|
||
<div class="tl-time">1:40</div>
|
||
</div>
|
||
<div class="tl-row">
|
||
<div class="tl-label">Soft decoding · 27→32</div>
|
||
<div class="tl-bar-wrap" style="max-width:600px;">
|
||
<div class="tl-bar col-analyse" style="width:26.7%">2:40</div>
|
||
</div>
|
||
<div class="tl-time">2:40</div>
|
||
</div>
|
||
<div class="tl-row">
|
||
<div class="tl-label">Analyse · 33→34</div>
|
||
<div class="tl-bar-wrap" style="max-width:600px;">
|
||
<div class="tl-bar col-ccl" style="width:10%">1:00</div>
|
||
</div>
|
||
<div class="tl-time">1:00</div>
|
||
</div>
|
||
<div class="tl-row">
|
||
<div class="tl-label">Conclusion · 35</div>
|
||
<div class="tl-bar-wrap" style="max-width:600px;">
|
||
<div class="tl-bar col-intro" style="width:7.5%;background:linear-gradient(90deg,#f59e0b,#ef4444)">45s</div>
|
||
</div>
|
||
<div class="tl-time">0:45</div>
|
||
</div>
|
||
</div>
|
||
|
||
<div class="timer-total">
|
||
<div class="big">15:00</div>
|
||
<div class="desc">Durée totale cumulée.<br/><span style="color:var(--text3)">Marge de ± 30s acceptable. En cas de retard, compresser slides 8-9 (exemple) et 26 (syndrome chart).</span></div>
|
||
</div>
|
||
|
||
<div class="legend">
|
||
<div class="leg-item"><div class="leg-dot col-intro" style="background:#6366f1"></div>Intro / Plan</div>
|
||
<div class="leg-item"><div class="leg-dot" style="background:#0891b2"></div>Codes linéaires</div>
|
||
<div class="leg-item"><div class="leg-dot" style="background:#059669"></div>Shannon / Complexité</div>
|
||
<div class="leg-item"><div class="leg-dot" style="background:#d97706"></div>Déf. LDPC + Tanner</div>
|
||
<div class="leg-item"><div class="leg-dot" style="background:#7c3aed"></div>Décodage hard</div>
|
||
<div class="leg-item"><div class="leg-dot" style="background:#be185d"></div>Décodage soft</div>
|
||
<div class="leg-item"><div class="leg-dot" style="background:#065f46"></div>Analyse / Girth</div>
|
||
<div class="leg-item"><div class="leg-dot" style="background:#92400e"></div>Conclusion</div>
|
||
</div>
|
||
</section>
|
||
<hr class="divider" style="max-width:1100px;margin:0 auto;"/>
|
||
|
||
<!-- ================================================ SCRIPT ================================================ -->
|
||
<section id="script">
|
||
<div class="sec-header">
|
||
<span class="sec-num">03</span>
|
||
<h2>Script slide par slide</h2>
|
||
</div>
|
||
<p style="color:var(--text2);margin-bottom:20px;">Clique sur une slide pour ouvrir son script. Le texte en <strong style="color:var(--amber)">orange</strong> signale les mots à insister ou les formulations clés. Les encarts colorés donnent des notes de présentation.</p>
|
||
<div style="display:flex;gap:10px;margin-bottom:24px;">
|
||
<button class="btn" onclick="openAll()">Tout ouvrir</button>
|
||
<button class="btn ghost" onclick="closeAll()">Tout fermer</button>
|
||
</div>
|
||
|
||
<div class="slides-grid" id="slides-container">
|
||
|
||
<!-- ===== SLIDE 1/35 ===== -->
|
||
<div class="slide-card" id="sc0">
|
||
<div class="slide-header" onclick="toggle('sc0')">
|
||
<div class="slide-num sn-intro">1/35</div>
|
||
<div class="slide-title">Introduction : Utilisation</div>
|
||
<div class="slide-timing">~30s</div>
|
||
<div class="slide-section-tag">Introduction</div>
|
||
<div class="expand-icon">▼</div>
|
||
</div>
|
||
<div class="slide-body">
|
||
<div class="slide-script">
|
||
« Je vais vous présenter les <em>codes LDPC</em> — Low Density Parity Check. Avant d'entrer dans la théorie, voici trois contextes réels qui les utilisent quotidiennement : un <em>module caméra de drone FPV</em> avec OpenIPC, qui doit transmettre de la vidéo HD en temps réel malgré les interférences radio ; et le satellite <em>Athena-Fidus</em>, un satellite franco-italien de télécommunications haut débit. Ces systèmes partagent une contrainte commune : transmettre des données <em>fiables</em> à travers un canal qui introduit du bruit. C'est exactement ce problème que les codes LDPC résolvent. »
|
||
</div>
|
||
<div class="slide-note warn">
|
||
<span class="note-icon">💡</span>
|
||
<div>La slide n'a que des images et des URLs — <strong>tout le contexte vient de toi à l'oral</strong>. Si tu manques de temps plus tard, tu peux compresser cette intro à 20s en listant juste les applications sans détailler.</div>
|
||
</div>
|
||
</div>
|
||
</div>
|
||
|
||
<!-- ===== SLIDE 2/35 ===== -->
|
||
<div class="slide-card" id="sc1">
|
||
<div class="slide-header" onclick="toggle('sc1')">
|
||
<div class="slide-num sn-intro">2/35</div>
|
||
<div class="slide-title">Introduction : Communication Numérique</div>
|
||
<div class="slide-timing">~25s</div>
|
||
<div class="slide-section-tag">Introduction</div>
|
||
<div class="expand-icon">▼</div>
|
||
</div>
|
||
<div class="slide-body">
|
||
<div class="slide-script">
|
||
« Voici le modèle classique d'une chaîne de communication numérique. Une source génère un message, un émetteur l'encode en signal, ce signal traverse un <em>canal bruité</em> — typiquement un canal AWGN — et un récepteur doit décoder le signal reçu pour retrouver le message original. La question centrale de mon TIPE : comment garantir que le message reçu est <em>identique</em> au message envoyé, malgré le bruit du canal ? »
|
||
</div>
|
||
<div class="slide-note green">
|
||
<span class="note-icon">✅</span>
|
||
<div>Slide simple, aller vite. Pointer le schéma du doigt (ou d'un stylo) : source → canal → destination.</div>
|
||
</div>
|
||
</div>
|
||
</div>
|
||
|
||
<!-- ===== SLIDE 3/35 ===== -->
|
||
<div class="slide-card" id="sc2">
|
||
<div class="slide-header" onclick="toggle('sc2')">
|
||
<div class="slide-num sn-intro">3/35</div>
|
||
<div class="slide-title">Problématique</div>
|
||
<div class="slide-timing">~20s</div>
|
||
<div class="slide-section-tag">Introduction</div>
|
||
<div class="expand-icon">▼</div>
|
||
</div>
|
||
<div class="slide-body">
|
||
<div class="slide-script">
|
||
« Ce qui nous amène à notre problématique : <em>« Comment utiliser les codes LDPC pour garantir la fiabilité d'une transmission en présence de bruit ? »</em> Je vais montrer que la réponse repose sur une structure mathématique très particulière de la matrice de contrôle, et sur des algorithmes itératifs qui permettent d'approcher la limite théorique de Shannon. »
|
||
</div>
|
||
<div class="slide-note warn">
|
||
<span class="note-icon">💡</span>
|
||
<div>Lire la problématique à voix haute calmement, puis enchaîner immédiatement. Ne pas rester dessus trop longtemps.</div>
|
||
</div>
|
||
</div>
|
||
</div>
|
||
|
||
<!-- ===== SLIDE 4/35 ===== -->
|
||
<div class="slide-card" id="sc3">
|
||
<div class="slide-header" onclick="toggle('sc3')">
|
||
<div class="slide-num sn-intro">4/35</div>
|
||
<div class="slide-title">Plan</div>
|
||
<div class="slide-timing">~15s</div>
|
||
<div class="slide-section-tag">Introduction</div>
|
||
<div class="expand-icon">▼</div>
|
||
</div>
|
||
<div class="slide-body">
|
||
<div class="slide-script">
|
||
« Pour y répondre : j'établirai d'abord les fondements des <em>codes linéaires</em>, puis je définirai les <em>codes LDPC</em> et leur représentation graphique, j'aborderai l'encodage, les algorithmes de décodage, et je terminerai par une <em>analyse comparative des performances</em>. »
|
||
</div>
|
||
<div class="slide-note green">
|
||
<span class="note-icon">✅</span>
|
||
<div>Très court. Pointer chaque item en parlant. Enchaîner sans marque d'hésitation.</div>
|
||
</div>
|
||
</div>
|
||
</div>
|
||
|
||
<!-- ===== SLIDE 5/35 ===== -->
|
||
<div class="slide-card" id="sc4">
|
||
<div class="slide-header" onclick="toggle('sc4')">
|
||
<div class="slide-num sn-lin">5/35</div>
|
||
<div class="slide-title">Définition : Codes Linéaires en Bloc</div>
|
||
<div class="slide-timing">~35s</div>
|
||
<div class="slide-section-tag">Codes linéaires</div>
|
||
<div class="expand-icon">▼</div>
|
||
</div>
|
||
<div class="slide-body">
|
||
<div class="slide-script">
|
||
« Un code linéaire en bloc <em>(n, k)</em> est un sous-espace vectoriel de <em>F₂ⁿ</em> de dimension k. Concrètement : on encode k bits d'information en n bits, en ajoutant m = n−k <em>bits de redondance</em> — les bits de parité. L'encodage est une application linéaire, un plongement de l'espace des messages dans l'espace des mots de code. Cette structure vectorielle est fondamentale : elle nous permettra de détecter et corriger les erreurs introduites par le canal. »
|
||
</div>
|
||
<div class="slide-note">
|
||
<span class="note-icon">💬</span>
|
||
<div>Pointer le diagramme de plongement F₂² → F₂³ sur la slide. Insister sur : « sous-espace vectoriel » et « redondance contrôlée ».</div>
|
||
</div>
|
||
</div>
|
||
</div>
|
||
|
||
<!-- ===== SLIDE 6/35 ===== -->
|
||
<div class="slide-card" id="sc5">
|
||
<div class="slide-header" onclick="toggle('sc5')">
|
||
<div class="slide-num sn-lin">6/35</div>
|
||
<div class="slide-title">Définition : Matrice Génératrice</div>
|
||
<div class="slide-timing">~30s</div>
|
||
<div class="slide-section-tag">Codes linéaires</div>
|
||
<div class="expand-icon">▼</div>
|
||
</div>
|
||
<div class="slide-body">
|
||
<div class="slide-script">
|
||
« L'encodage se formalise via la <em>matrice génératrice G</em> de taille k×n, dont les lignes forment une base du code. Pour un message u, le mot de code est simplement c = uG. En forme systématique, G = [Iₖ | P] : les k premiers bits du mot de code sont <em>exactement</em> les bits du message original — c'est ce qui rend le décodage pratique. P est la matrice de parité qui génère la redondance. »
|
||
</div>
|
||
</div>
|
||
</div>
|
||
|
||
<!-- ===== SLIDE 7/35 ===== -->
|
||
<div class="slide-card" id="sc6">
|
||
<div class="slide-header" onclick="toggle('sc6')">
|
||
<div class="slide-num sn-lin">7/35</div>
|
||
<div class="slide-title">Définition : Matrice de Contrôle</div>
|
||
<div class="slide-timing">~35s</div>
|
||
<div class="slide-section-tag">Codes linéaires</div>
|
||
<div class="expand-icon">▼</div>
|
||
</div>
|
||
<div class="slide-body">
|
||
<div class="slide-script">
|
||
« La <em>matrice de contrôle H</em> = [Pᵀ | Iₙ₋ₖ] définit l'espace dual du code : tout mot de code c vérifie Hcᵀ = 0. C'est la propriété fondamentale. Quand on reçoit un vecteur r = c + e — le mot de code plus une erreur — le <em>syndrome</em> s = Hrᵀ = Heᵀ est directement la signature de l'erreur. Si s = 0 : aucune erreur détectée. Si s ≠ 0 : le syndrome nous informe sur la <em>position</em> des bits erronés. Tout le décodage repose sur cette relation. »
|
||
</div>
|
||
<div class="slide-note green">
|
||
<span class="note-icon">✅</span>
|
||
<div>Slide capitale. Bien insister sur Hcᵀ = 0 ↔ « appartient au code ». Et s = Heᵀ : « le syndrome ne dépend que de l'erreur, pas du message transmis ».</div>
|
||
</div>
|
||
</div>
|
||
</div>
|
||
|
||
<!-- ===== SLIDE 8/35 ===== -->
|
||
<div class="slide-card" id="sc7">
|
||
<div class="slide-header" onclick="toggle('sc7')">
|
||
<div class="slide-num sn-lin">8/35</div>
|
||
<div class="slide-title">Exemple — Code (5,2) · Partie 1</div>
|
||
<div class="slide-timing">~20s</div>
|
||
<div class="slide-section-tag">Codes linéaires</div>
|
||
<div class="expand-icon">▼</div>
|
||
</div>
|
||
<div class="slide-body">
|
||
<div class="slide-script">
|
||
« Un exemple rapide : code (5, 2). On choisit P, on en déduit G. Pour le message u = [1 1], le mot de code c = uG = <em>[1 1 1 0 1]</em>. Les 2 premiers bits sont le message, les 3 suivants sont les bits de parité générés automatiquement. »
|
||
</div>
|
||
<div class="slide-note warn">
|
||
<span class="note-icon">⚡</span>
|
||
<div>Aller <strong>très vite</strong> sur cette slide. L'exemple est illustratif, ne pas s'y attarder. Le jury connaît les codes linéaires.</div>
|
||
</div>
|
||
</div>
|
||
</div>
|
||
|
||
<!-- ===== SLIDE 9/35 ===== -->
|
||
<div class="slide-card" id="sc8">
|
||
<div class="slide-header" onclick="toggle('sc8')">
|
||
<div class="slide-num sn-lin">9/35</div>
|
||
<div class="slide-title">Exemple — Code (5,2) · Partie 2</div>
|
||
<div class="slide-timing">~20s</div>
|
||
<div class="slide-section-tag">Codes linéaires</div>
|
||
<div class="expand-icon">▼</div>
|
||
</div>
|
||
<div class="slide-body">
|
||
<div class="slide-script">
|
||
« On vérifie : Hcᵀ = 0 — c'est bien un mot de code valide. Si on reçoit r = [1 1 <em>0</em> 0 1] avec une erreur sur le 3ème bit, le syndrome est non nul — l'erreur est détectée. Sur un code aussi petit on pourrait même la corriger, mais c'est impraticable à grande échelle — ce qui nous amène au problème de complexité. »
|
||
</div>
|
||
<div class="slide-note warn">
|
||
<span class="note-icon">⚡</span>
|
||
<div>Même consigne : aller vite. Finir par « impraticable à grande échelle » pour préparer la slide suivante naturellement.</div>
|
||
</div>
|
||
</div>
|
||
</div>
|
||
|
||
<!-- ===== SLIDE 10/35 ===== -->
|
||
<div class="slide-card" id="sc9">
|
||
<div class="slide-header" onclick="toggle('sc9')">
|
||
<div class="slide-num sn-shan">10/35</div>
|
||
<div class="slide-title">Approcher la Limite de Shannon</div>
|
||
<div class="slide-timing">~35s</div>
|
||
<div class="slide-section-tag">Shannon</div>
|
||
<div class="expand-icon">▼</div>
|
||
</div>
|
||
<div class="slide-body">
|
||
<div class="slide-script">
|
||
« En 1948, Shannon démontre qu'il existe une limite fondamentale : pour un canal AWGN de rapport Eb/N₀, la <em>capacité C</em> est le taux maximal d'information transmissible sans erreur. Ce graphe montre que pour un code de longueur <em>n = 64 800</em> — c'est le standard DVB-S2 pour la télévision par satellite — on s'approche à <em>moins de 0,5 dB</em> de cette limite théorique. Pour n petit, on reste loin. La question est donc : comment construire des codes qui approchent la limite, avec un décodage efficace ? »
|
||
</div>
|
||
<div class="slide-note green">
|
||
<span class="note-icon">🎯</span>
|
||
<div>Slide très importante — c'est la motivation principale. Revenir dessus mentalement lors des slides 25 et 32 (waterfall) pour <strong>quantifier l'écart à Shannon</strong>.</div>
|
||
</div>
|
||
</div>
|
||
</div>
|
||
|
||
<!-- ===== SLIDE 11/35 ===== -->
|
||
<div class="slide-card" id="sc10">
|
||
<div class="slide-header" onclick="toggle('sc10')">
|
||
<div class="slide-num sn-shan">11/35</div>
|
||
<div class="slide-title">Le Mur de la Complexité</div>
|
||
<div class="slide-timing">~30s</div>
|
||
<div class="slide-section-tag">Shannon</div>
|
||
<div class="expand-icon">▼</div>
|
||
</div>
|
||
<div class="slide-body">
|
||
<div class="slide-script">
|
||
« Le décodage optimal — le <em>décodage par maximum de vraisemblance</em> — cherche le mot de code le plus proche au sens de la distance de Hamming. Le problème : c'est <em>NP-difficile</em> pour H quelconque, avec une complexité en O(2ᵏ). Pour k = 648, on parle de 2⁶⁴⁸ ≈ 10¹⁹⁵ opérations — totalement hors de portée. Il nous faut donc une structure spéciale sur H qui permette un décodage <em>polynomial</em>. Et c'est exactement ce que fournissent les codes LDPC. »
|
||
</div>
|
||
<div class="slide-note green">
|
||
<span class="note-icon">🎯</span>
|
||
<div>Slide pivot de la présentation. « NP-difficile → LDPC comme solution » est le cœur de la narration. Finir sur un ton légèrement dramatique pour marquer la transition.</div>
|
||
</div>
|
||
</div>
|
||
</div>
|
||
|
||
<!-- ===== SLIDE 12/35 ===== -->
|
||
<div class="slide-card" id="sc11">
|
||
<div class="slide-header" onclick="toggle('sc11')">
|
||
<div class="slide-num sn-ldpc">12/35</div>
|
||
<div class="slide-title">Définition des Codes LDPC</div>
|
||
<div class="slide-timing">~40s</div>
|
||
<div class="slide-section-tag">LDPC</div>
|
||
<div class="expand-icon">▼</div>
|
||
</div>
|
||
<div class="slide-body">
|
||
<div class="slide-script">
|
||
« Un code LDPC est un code linéaire en bloc dont la matrice de contrôle H est <em>clairsemée</em> — d'où « Low Density Parity Check ». Dans un code régulier (wc, wr), chaque colonne a exactement wc uns et chaque ligne exactement wr uns. Ici, H ∈ M₁₅,₃₀(F₂) avec wc = 3 et wr = 6 — à peine 3 uns par colonne sur 15 possibles. Cette faible densité, de l'ordre de <em>10%</em>, est la clé : elle permet des algorithmes de décodage itératifs efficaces. Le rendement est R = 1 − m/n = 1/2. »
|
||
</div>
|
||
<div class="slide-note green">
|
||
<span class="note-icon">🎯</span>
|
||
<div>Slide définitoire centrale. Insister sur : <strong>« la matrice est creuse — c'est tout, c'est tout ce qui change par rapport à un code linéaire classique — mais ça change tout »</strong>.</div>
|
||
</div>
|
||
</div>
|
||
</div>
|
||
|
||
<!-- ===== SLIDE 13/35 ===== -->
|
||
<div class="slide-card" id="sc12">
|
||
<div class="slide-header" onclick="toggle('sc12')">
|
||
<div class="slide-num sn-ldpc">13/35</div>
|
||
<div class="slide-title">De la Matrice aux Équations de Parité</div>
|
||
<div class="slide-timing">~30s</div>
|
||
<div class="slide-section-tag">LDPC</div>
|
||
<div class="expand-icon">▼</div>
|
||
</div>
|
||
<div class="slide-body">
|
||
<div class="slide-script">
|
||
« Chaque ligne Lⱼ de H définit une <em>équation de parité</em> fⱼ. Par exemple, f₀ : r₇ ⊕ r₁₀ ⊕ r₁₅ ⊕ r₂₂ ⊕ r₂₄ ⊕ r₂₉ = 0. On vérifie le syndrome Hr^T = 0 sur le vecteur reçu. Si fⱼ = 1, un nombre <em>impair</em> de bits parmi ceux impliqués a été inversé — il y a eu une erreur. La faible densité de H signifie que chaque équation ne met en jeu que <em>wᵣ = 6 bits</em> sur 30 possibles. »
|
||
</div>
|
||
</div>
|
||
</div>
|
||
|
||
<!-- ===== SLIDE 14/35 ===== -->
|
||
<div class="slide-card" id="sc13">
|
||
<div class="slide-header" onclick="toggle('sc13')">
|
||
<div class="slide-num sn-ldpc">14/35</div>
|
||
<div class="slide-title">L'Entrelacement des Contraintes</div>
|
||
<div class="slide-timing">~30s</div>
|
||
<div class="slide-section-tag">LDPC</div>
|
||
<div class="expand-icon">▼</div>
|
||
</div>
|
||
<div class="slide-body">
|
||
<div class="slide-script">
|
||
« L'aspect crucial : chaque bit rᵢ participe à <em>wc = 3 équations distinctes simultanément</em>. Par exemple, r₂₄ est surveillé par f₀, f₉ et f₁₄. Si plusieurs équations échouent et pointent toutes vers ce même bit, il est très probablement erroné. C'est un <em>mécanisme de vote croisé</em> : la redondance n'est pas simplement répétée, elle est répartie sur le mot de code de façon à maximiser l'information sur chaque bit. »
|
||
</div>
|
||
<div class="slide-note green">
|
||
<span class="note-icon">💡</span>
|
||
<div>Bonne phrase-clé : « les contraintes s'entrecroisent — chaque bit est surveillé par plusieurs équations, chaque équation surveille plusieurs bits ».</div>
|
||
</div>
|
||
</div>
|
||
</div>
|
||
|
||
<!-- ===== SLIDE 15/35 ===== -->
|
||
<div class="slide-card" id="sc14">
|
||
<div class="slide-header" onclick="toggle('sc14')">
|
||
<div class="slide-num sn-tanner">15/35</div>
|
||
<div class="slide-title">Graphe de Tanner : Définition</div>
|
||
<div class="slide-timing">~30s</div>
|
||
<div class="slide-section-tag">Tanner</div>
|
||
<div class="expand-icon">▼</div>
|
||
</div>
|
||
<div class="slide-body">
|
||
<div class="slide-script">
|
||
« Pour visualiser cette structure, on construit le <em>graphe de Tanner</em> G(H) : un graphe bipartite avec d'un côté les nœuds de variable V — un par bit — et de l'autre les nœuds de contrôle C — un par équation de parité. Il y a une arête entre vⱼ et cᵢ si et seulement si H_{i,j} = 1. Ce graphe est <em>équivalent à H</em> : mêmes degrés, même structure. Il va être le support géométrique de tous nos algorithmes de décodage. »
|
||
</div>
|
||
</div>
|
||
</div>
|
||
|
||
<!-- ===== SLIDES 16-19/35 (ANIMATIONS) ===== -->
|
||
<div class="slide-card" id="sc15">
|
||
<div class="slide-header" onclick="toggle('sc15')">
|
||
<div class="slide-num sn-tanner">16→19/35</div>
|
||
<div class="slide-title">Construction du Graphe de Tanner (animations)</div>
|
||
<div class="slide-timing">~50s total</div>
|
||
<div class="slide-section-tag">Tanner</div>
|
||
<div class="expand-icon">▼</div>
|
||
</div>
|
||
<div class="slide-body">
|
||
<div class="slide-script">
|
||
<strong>[Slide 16/35 — Les nœuds]</strong> « On commence par placer les 30 nœuds de variable en haut et les 15 nœuds de contrôle en bas. »<br/><br/>
|
||
<strong>[Slide 17/35 — Nœud de contrôle]</strong> « Le nœud c₀ est connecté aux bits qu'il surveille : v₇, v₁₀, v₁₅, v₂₂, v₂₄, v₂₉ — exactement les uns sur la première ligne de H. »<br/><br/>
|
||
<strong>[Slide 18/35 — Nœud de variable]</strong> « Réciproquement, v₁₀ est connecté aux trois nœuds de contrôle c₀, c₅, c₁₁ — les trois équations où la colonne 10 de H vaut 1. »<br/><br/>
|
||
<strong>[Slide 19/35 — Graphe final]</strong> « En répétant pour tous les bits, on obtient le graphe de Tanner complet. Sa structure bipartite reflète exactement la matrice H — c'est la représentation graphique des contraintes de parité. »
|
||
</div>
|
||
<div class="slide-note warn">
|
||
<span class="note-icon">⚡</span>
|
||
<div>Ces 4 slides sont des <strong>animations progressives</strong>. Les enchaîner fluidement et rapidement — environ 12s par slide. Ne pas attendre entre chaque transition.</div>
|
||
</div>
|
||
</div>
|
||
</div>
|
||
|
||
<!-- ===== SLIDE 20/35 ===== -->
|
||
<div class="slide-card" id="sc19">
|
||
<div class="slide-header" onclick="toggle('sc19')">
|
||
<div class="slide-num sn-tanner">20/35</div>
|
||
<div class="slide-title">La Contrainte de Somme Nulle — Sans erreur</div>
|
||
<div class="slide-timing">~20s</div>
|
||
<div class="slide-section-tag">Tanner</div>
|
||
<div class="expand-icon">▼</div>
|
||
</div>
|
||
<div class="slide-body">
|
||
<div class="slide-script">
|
||
« Dans le graphe, chaque nœud de contrôle cᵢ <em>calcule le XOR</em> de ses voisins. Si le mot de code est valide, tous les nœuds de contrôle obtiennent 0 : les équations sont toutes satisfaites. C'est la vision graphique de Hcᵀ = 0. »
|
||
</div>
|
||
</div>
|
||
</div>
|
||
|
||
<!-- ===== SLIDE 21/35 ===== -->
|
||
<div class="slide-card" id="sc20">
|
||
<div class="slide-header" onclick="toggle('sc20')">
|
||
<div class="slide-num sn-tanner">21/35</div>
|
||
<div class="slide-title">La Contrainte de Somme Nulle — Détection</div>
|
||
<div class="slide-timing">~20s</div>
|
||
<div class="slide-section-tag">Tanner</div>
|
||
<div class="expand-icon">▼</div>
|
||
</div>
|
||
<div class="slide-body">
|
||
<div class="slide-script">
|
||
« Si un bit est inversé, les nœuds de contrôle qui lui sont connectés calculent maintenant 1 au lieu de 0 — <em>l'erreur est détectée</em>. Ici, 0 ⊕ 1 ⊕ 0 = 1 : ce nœud de contrôle est insatisfait. C'est le signal qui va déclencher la correction dans les algorithmes itératifs. »
|
||
</div>
|
||
</div>
|
||
</div>
|
||
|
||
<!-- ===== SLIDE 22/35 ===== -->
|
||
<div class="slide-card" id="sc21">
|
||
<div class="slide-header" onclick="toggle('sc21')">
|
||
<div class="slide-num sn-enc">22/35</div>
|
||
<div class="slide-title">Encodage LDPC : Calcul de G</div>
|
||
<div class="slide-timing">~30s</div>
|
||
<div class="slide-section-tag">Encodage</div>
|
||
<div class="expand-icon">▼</div>
|
||
</div>
|
||
<div class="slide-body">
|
||
<div class="slide-script">
|
||
« Pour encoder, on calcule la forme systématique par <em>pivot de Gauss sur H</em>. Mais attention : H est creuse — 20% de densité — et l'opération de pivot la rend <strong>dense</strong> — 50% ou plus. La matrice G résultante est donc dense, ce qui implique un encodage en <em>O(n²)</em>. Pour les grands codes industriels comme DVB-S2 avec n = 64 800, c'est inaceptable. La solution : des structures <em>QC-LDPC quasi-cycliques</em> et l'algorithme de Richardson-Urbanke permettent un encodage en O(n), détaillés en annexe. »
|
||
</div>
|
||
<div class="slide-note warn">
|
||
<span class="note-icon">💡</span>
|
||
<div>Ne pas oublier de mentionner Richardson-Urbanke et QC-LDPC ici, même brièvement. La slide soulève un problème ; le jury peut interroger sur la solution.</div>
|
||
</div>
|
||
</div>
|
||
</div>
|
||
|
||
<!-- ===== SLIDE 23/35 ===== -->
|
||
<div class="slide-card" id="sc22">
|
||
<div class="slide-header" onclick="toggle('sc22')">
|
||
<div class="slide-num sn-bf">23/35</div>
|
||
<div class="slide-title">Décodage : Bit-Flipping</div>
|
||
<div class="slide-timing">~35s</div>
|
||
<div class="slide-section-tag">Décodage hard</div>
|
||
<div class="expand-icon">▼</div>
|
||
</div>
|
||
<div class="slide-body">
|
||
<div class="slide-script">
|
||
« Entrons dans le cœur du décodage. Le premier algorithme, le <em>Bit-Flipping</em>, opère sur des décisions strictes — des bits purs, pas des probabilités. Principe : à chaque itération, les nœuds de contrôle transmettent leur verdict de parité à leurs voisins. Chaque nœud de variable <em>compte ses équations insatisfaites</em>. Si la majorité de ses wc équations échouent, le bit se retourne — il change de valeur. On itère jusqu'à ce que le syndrome soit nul, ou jusqu'à atteindre le nombre maximum d'itérations. »
|
||
</div>
|
||
<div class="slide-note green">
|
||
<span class="note-icon">✅</span>
|
||
<div>Bien faire le lien avec la slide précédente : « les nœuds de contrôle insatisfaits qu'on vient de voir vont maintenant <em>voter</em> pour identifier quel bit est erroné ».</div>
|
||
</div>
|
||
<div class="slide-note warn">
|
||
<span class="note-icon">🎞️</span>
|
||
<div>Cette slide a <strong>deux états d'animation</strong>. Le premier montre la description textuelle du Message Passing. Le second révèle le graphe avec v₀–v₃ et les étapes VN→CN, CN→VN puis le FLIP. Pointer les nœuds en les nommant pendant l'animation — « v₁ a reçu un verdict défavorable de ses trois équations, il se retourne ».</div>
|
||
</div>
|
||
</div>
|
||
</div>
|
||
|
||
<!-- ===== SLIDE 24/35 ===== -->
|
||
<div class="slide-card" id="sc23">
|
||
<div class="slide-header" onclick="toggle('sc23')">
|
||
<div class="slide-num sn-bf">24/35</div>
|
||
<div class="slide-title">Bit-Flipping : Graphe de flot de contrôle</div>
|
||
<div class="slide-timing">~25s</div>
|
||
<div class="slide-section-tag">Décodage hard</div>
|
||
<div class="expand-icon">▼</div>
|
||
</div>
|
||
<div class="slide-body">
|
||
<div class="slide-script">
|
||
« Voici l'organigramme. Mot reçu r en entrée. Boucle : ① mise à jour des nœuds de contrôle — calcul du syndrome s = Hr^T — ② mise à jour des nœuds de variable — flip si majorité d'équations violées. À chaque itération, on teste si <em>s = 0</em> : si oui, succès immédiat. Si on dépasse le nombre maximum d'itérations, <em>échec</em> — la trame est perdue. En pratique, on fixe Imax entre 50 et 200 itérations. »
|
||
</div>
|
||
</div>
|
||
</div>
|
||
|
||
<!-- ===== SLIDE 25/35 ===== -->
|
||
<div class="slide-card" id="sc24">
|
||
<div class="slide-header" onclick="toggle('sc24')">
|
||
<div class="slide-num sn-bf">25/35</div>
|
||
<div class="slide-title">Waterfall — Bit-Flipping LDPC (3,6)</div>
|
||
<div class="slide-timing">~30s</div>
|
||
<div class="slide-section-tag">Décodage hard</div>
|
||
<div class="expand-icon">▼</div>
|
||
</div>
|
||
<div class="slide-body">
|
||
<div class="slide-script">
|
||
« Voici la <em>courbe waterfall</em> pour un code LDPC (3,6) de longueur n = 1296. L'axe horizontal est le rapport Eb/N₀ en dB, l'axe vertical le Bit Error Rate. On voit le comportement caractéristique : une chute très abrupte du BER — le « waterfall » — autour de <em>5 à 6 dB</em>. Comparé au signal non codé, le gain est substantiel. Mais on reste loin de la limite de Shannon. Pour aller plus loin, il faut du décodage <em>soft</em> — qui utilise non plus des bits, mais des valeurs continues. »
|
||
</div>
|
||
<div class="slide-note warn">
|
||
<span class="note-icon">💡</span>
|
||
<div>Mentionner la distance à Shannon : « ~5 à 6 dB de la limite ». Ce chiffre sera comparé lors de la slide 31.</div>
|
||
</div>
|
||
</div>
|
||
</div>
|
||
|
||
<!-- ===== SLIDE 26/35 ===== -->
|
||
<div class="slide-card" id="sc25">
|
||
<div class="slide-header" onclick="toggle('sc25')">
|
||
<div class="slide-num sn-bf">26/35</div>
|
||
<div class="slide-title">Bit-Flipping : Syndrome et Analyse</div>
|
||
<div class="slide-timing">~20s</div>
|
||
<div class="slide-section-tag">Décodage hard</div>
|
||
<div class="expand-icon">▼</div>
|
||
</div>
|
||
<div class="slide-body">
|
||
<div class="slide-script">
|
||
« Cette courbe montre l'évolution du nombre d'équations insatisfaites au fil des itérations du Bit-Flipping, pour différents niveaux de bruit. À fort SNR, le syndrome converge vers zéro en <em>une dizaine d'itérations</em>. À SNR plus faible, la convergence est plus lente ou échoue. — L'avantage de cet algorithme : sa <em>complexité minimale</em> — seulement des XOR et des compteurs — O(n) par itération. En revanche sa limite fondamentale : il ignore complètement la <em>confiance du récepteur physique</em>. Un bit reçu à 0,51 V est traité exactement comme un bit reçu à 4,5 V — c'est ce qui va nous pousser vers le décodage soft. »
|
||
</div>
|
||
<div class="slide-note warn">
|
||
<span class="note-icon">🎞️</span>
|
||
<div>Cette slide a <strong>deux états</strong>. Le premier montre uniquement la courbe de convergence du syndrome. Le second révèle les blocs Avantages / Limite présents sur la slide. <strong>Ne pas sauter la Limite</strong> (« ignore la confiance ») — elle sert de transition directe et explicite vers le décodage soft.</div>
|
||
</div>
|
||
</div>
|
||
</div>
|
||
|
||
<!-- ===== SLIDE 27/35 ===== -->
|
||
<div class="slide-card" id="sc26">
|
||
<div class="slide-header" onclick="toggle('sc26')">
|
||
<div class="slide-num sn-soft">27/35</div>
|
||
<div class="slide-title">Décodage Soft : Le LLR</div>
|
||
<div class="slide-timing">~35s</div>
|
||
<div class="slide-section-tag">Décodage soft</div>
|
||
<div class="expand-icon">▼</div>
|
||
</div>
|
||
<div class="slide-body">
|
||
<div class="slide-script">
|
||
« Pour aller plus loin, on passe au décodage <em>soft</em>. Au lieu de décisions binaires, on travaille avec des probabilités sous forme de <em>Log-Likelihood Ratios</em>. Le LLR d'un bit vᵢ est défini comme le logarithme du rapport P(vᵢ = 0 | yᵢ) / P(vᵢ = 1 | yᵢ). Le signe encode la <em>décision</em> sur le bit — positif vaut 0, négatif vaut 1 — et la valeur absolue encode la <em>confiance</em>. Un LLR de +10 : très sûr que c'est un 0. Un LLR de −0,3 : légèrement penché vers 1, mais très incertain. Cette information graduelle est précieuse pour le décodage. »
|
||
</div>
|
||
<div class="slide-note green">
|
||
<span class="note-icon">💡</span>
|
||
<div>Pointer l'axe gradué sur la slide : « −6 → forte confiance bit = 1 ; +10 → forte confiance bit = 0 ; +0.3 → très incertain ».</div>
|
||
</div>
|
||
</div>
|
||
</div>
|
||
|
||
<!-- ===== SLIDE 28/35 ===== -->
|
||
<div class="slide-card" id="sc27">
|
||
<div class="slide-header" onclick="toggle('sc27')">
|
||
<div class="slide-num sn-soft">28/35</div>
|
||
<div class="slide-title">Sum-Product : Belief Propagation</div>
|
||
<div class="slide-timing">~45s</div>
|
||
<div class="slide-section-tag">Décodage soft</div>
|
||
<div class="expand-icon">▼</div>
|
||
</div>
|
||
<div class="slide-body">
|
||
<div class="slide-script">
|
||
« L'algorithme <em>Sum-Product</em>, ou Belief Propagation, est le décodeur <em>optimal</em> pour les graphes sans cycles. Au lieu de bits, les nœuds échangent des LLR — des « croyances ». Deux règles fondamentales : d'abord, l'<em>information extrinsèque</em> — un nœud n'envoie jamais son propre avis à l'expéditeur de ce même avis, pour éviter l'auto-renforcement. Ensuite, la <em>mise à jour des nœuds de contrôle</em> : m_{c→v} = 2 tanh⁻¹(∏ tanh(m_{u→c}/2)), le produit portant sur tous les voisins u de c <em>sauf</em> v. Cette formule provient de la probabilité conditionnelle de parité — chaque nœud agrège l'information de ses voisins sans se biaiser lui-même. »
|
||
</div>
|
||
<div class="slide-note green">
|
||
<span class="note-icon">🎯</span>
|
||
<div>Slide la plus technique. Le jury <strong>va sûrement poser des questions dessus</strong>. Savoir dériver la formule tanh (voir la section "À réviser"). Insister sur « information extrinsèque » : c'est le concept clé.</div>
|
||
</div>
|
||
</div>
|
||
</div>
|
||
|
||
<!-- ===== SLIDE 29/35 ===== -->
|
||
<div class="slide-card" id="sc28">
|
||
<div class="slide-header" onclick="toggle('sc28')">
|
||
<div class="slide-num sn-soft">29/35</div>
|
||
<div class="slide-title">Sum-Product — Déroulement complet</div>
|
||
<div class="slide-timing">~25s</div>
|
||
<div class="slide-section-tag">Décodage soft</div>
|
||
<div class="expand-icon">▼</div>
|
||
</div>
|
||
<div class="slide-body">
|
||
<div class="slide-script">
|
||
« L'algorithme complet : <em>initialisation</em> des messages v→c avec les LLR de canal. Puis alternance de mises à jour : nœuds de contrôle, puis nœuds de variable — m_{v→c} = L_v^canal + ∑ m_{c'→v}. À chaque itération, on calcule le LLR apostériori Λⱼ = L_v^canal + ∑ m_{cᵢ→vⱼ} pour prendre la <em>décision finale</em> : v̂ⱼ = 0 si Λⱼ > 0, sinon 1. On itère jusqu'à satisfaction du syndrome ou Imax. »
|
||
</div>
|
||
</div>
|
||
</div>
|
||
|
||
<!-- ===== SLIDE 30/35 ===== -->
|
||
<div class="slide-card" id="sc29">
|
||
<div class="slide-header" onclick="toggle('sc29')">
|
||
<div class="slide-num sn-soft">30/35</div>
|
||
<div class="slide-title">Transmission d'image — Démonstration</div>
|
||
<div class="slide-timing">~35s</div>
|
||
<div class="slide-section-tag">Décodage soft</div>
|
||
<div class="expand-icon">▼</div>
|
||
</div>
|
||
<div class="slide-body">
|
||
<div class="slide-script">
|
||
« Voici une démonstration concrète que j'ai implémentée. J'ai simulé la transmission d'une image sur canal AWGN à <em>Eb/N₀ = 2,3 dB</em>. À gauche : l'image originale. Au centre : l'image reçue bruitée — pratiquement illisible, 30% des pixels sont corrompus. Et à droite : les résultats du décodage Sum-Product pour trois rendements différents — R = 1/2, 2/3 et 3/4. On voit clairement qu'un rendement plus faible, donc <em>plus de redondance</em>, donne une meilleure correction. C'est le compromis fondamental entre débit et fiabilité — et les codes LDPC permettent de le naviguer précisément. »
|
||
</div>
|
||
<div class="slide-note green">
|
||
<span class="note-icon">⭐</span>
|
||
<div>Point fort de la présentation. Prendre <strong>le temps de le présenter correctement</strong>. Le visuel est immédiatement compréhensible même sans explications techniques — c'est parfait pour le jury.</div>
|
||
</div>
|
||
</div>
|
||
</div>
|
||
|
||
<!-- ===== SLIDE 31/35 ===== -->
|
||
<div class="slide-card" id="sc30">
|
||
<div class="slide-header" onclick="toggle('sc30')">
|
||
<div class="slide-num sn-soft">31/35</div>
|
||
<div class="slide-title">Min-Sum — Approximation matérielle</div>
|
||
<div class="slide-timing">~30s</div>
|
||
<div class="slide-section-tag">Décodage soft</div>
|
||
<div class="expand-icon">▼</div>
|
||
</div>
|
||
<div class="slide-body">
|
||
<div class="slide-script">
|
||
« Le Sum-Product nécessite des opérations tanh, coûteuses en matériel. L'algorithme <em>Min-Sum</em> utilise une approximation : le produit des tanh est remplacé par un <em>minimum</em> — m_{c→v} ≈ (∏ sgn(m_{u→c})) × min|m_{u→c}|. La mise en œuvre devient triviale : seulement des <em>comparateurs</em> pour le minimum et des <em>XOR</em> pour les signes. En ajoutant un facteur d'échelle α ≈ 0,75 à 0,875 qui compense le biais, les performances restent très proches du Sum-Product, avec une fraction du coût matériel. »
|
||
</div>
|
||
<div class="slide-note green">
|
||
<span class="note-icon">💡</span>
|
||
<div>Relier au contexte DVB-S2 / 5G : « c'est Min-Sum qui est implémenté en FPGA dans les standards industriels, pas Sum-Product ».</div>
|
||
</div>
|
||
</div>
|
||
</div>
|
||
|
||
<!-- ===== SLIDE 32/35 ===== -->
|
||
<div class="slide-card" id="sc31">
|
||
<div class="slide-header" onclick="toggle('sc31')">
|
||
<div class="slide-num sn-soft">32/35</div>
|
||
<div class="slide-title">Waterfall — Comparaison des 3 algorithmes</div>
|
||
<div class="slide-timing">~35s</div>
|
||
<div class="slide-section-tag">Décodage soft</div>
|
||
<div class="expand-icon">▼</div>
|
||
</div>
|
||
<div class="slide-body">
|
||
<div class="slide-script">
|
||
« Ce graphique est le <em>bilan de performance</em>. Trois algorithmes sur le même code (3,9) — R = 2/3. Le <em>Sum-Product</em> est à environ <strong>1 à 1,5 dB de la limite de Shannon</strong> — remarquable. Le <em>Min-Sum</em> perd quelques dixièmes de dB mais reste excellent. Le <em>Bit-Flipping</em> est nettement moins performant — 5 à 6 dB — mais il est beaucoup plus rapide. Le choix dépend du compromis : décodage embarqué en temps réel → Min-Sum sur FPGA ; haute qualité de service → Sum-Product. Dans tous les cas, on bat largement le signal non codé. »
|
||
</div>
|
||
<div class="slide-note green">
|
||
<span class="note-icon">🎯</span>
|
||
<div><strong>Slide climax de l'analyse.</strong> Relier explicitement à la slide 10 (Shannon) en disant les distances en dB. C'est le point d'orgue de la démonstration.</div>
|
||
</div>
|
||
</div>
|
||
</div>
|
||
|
||
<!-- ===== SLIDE 33/35 ===== -->
|
||
<div class="slide-card" id="sc32">
|
||
<div class="slide-header" onclick="toggle('sc32')">
|
||
<div class="slide-num sn-analyse">33/35</div>
|
||
<div class="slide-title">La Topologie de H : Le Girth</div>
|
||
<div class="slide-timing">~35s</div>
|
||
<div class="slide-section-tag">Analyse</div>
|
||
<div class="expand-icon">▼</div>
|
||
</div>
|
||
<div class="slide-body">
|
||
<div class="slide-script">
|
||
« Un paramètre clé pour les performances est le <em>girth</em> — la maille — longueur du plus court cycle dans le graphe de Tanner. Sur un <em>arbre</em> sans cycles, le Belief Propagation est exact. Mais sur un graphe cyclique, les messages peuvent revenir à leur point de départ après l cycle itérations, créant des <em>corrélations</em> qui dégradent la convergence. Un 4-cycle — le pire cas — crée des corrélations immédiates qui peuvent bloquer le décodage. Un girth élevé <em>retarde</em> l'apparition de ces effets : idéalement, girth ≥ 2·Imax pour que les cycles n'influencent pas les premières itérations. »
|
||
</div>
|
||
<div class="slide-note green">
|
||
<span class="note-icon">🎯</span>
|
||
<div>Question classique du jury : « pourquoi le BP n'est-il pas exact ? ». La réponse est ici : les cycles. Bien maîtriser cette notion.</div>
|
||
</div>
|
||
</div>
|
||
</div>
|
||
|
||
<!-- ===== SLIDE 34/35 ===== -->
|
||
<div class="slide-card" id="sc33">
|
||
<div class="slide-header" onclick="toggle('sc33')">
|
||
<div class="slide-num sn-analyse">34/35</div>
|
||
<div class="slide-title">Méthodes de génération de H</div>
|
||
<div class="slide-timing">~25s</div>
|
||
<div class="slide-section-tag">Analyse</div>
|
||
<div class="expand-icon">▼</div>
|
||
</div>
|
||
<div class="slide-body">
|
||
<div class="slide-script">
|
||
« Pour construire H avec un bon girth, trois méthodes. <em>Gallager (1962)</em> : la méthode originale — simple, rapide, mais des cycles de longueur 4 sont fréquents. <em>MacKay-Neal (1996)</em> : construction aléatoire avec rejet actif de tout arc qui créerait un 4-cycle — girth garanti ≥ 6, performances nettement supérieures. <em>Progressive Edge-Growth (2005)</em> : on maximise le girth local à chaque ajout d'arête par un BFS — c'est aujourd'hui la <em>méthode de référence</em>, et celle que j'ai implémentée en annexe. Ces trois méthodes produisent des codes différents, mais c'est le girth qui fait toute la différence. »
|
||
</div>
|
||
<div class="slide-note red">
|
||
<span class="note-icon">⚠️</span>
|
||
<div>La slide ne montre que 3 noms. <strong>Tout vient de toi oralement.</strong> Préparer bien ce résumé comparatif — le jury va probablement demander : « laquelle avez-vous implémentée et pourquoi ? »</div>
|
||
</div>
|
||
</div>
|
||
</div>
|
||
|
||
<!-- ===== SLIDE 35/35 ===== -->
|
||
<div class="slide-card" id="sc34">
|
||
<div class="slide-header" onclick="toggle('sc34')">
|
||
<div class="slide-num sn-ccl">35/35</div>
|
||
<div class="slide-title">Conclusion</div>
|
||
<div class="slide-timing">~45s</div>
|
||
<div class="slide-section-tag">Conclusion</div>
|
||
<div class="expand-icon">▼</div>
|
||
</div>
|
||
<div class="slide-body">
|
||
<div class="slide-script">
|
||
« Pour conclure : les codes LDPC résolvent élégamment le problème de la transmission fiable. La matrice <em>clairsemée H</em> rend le décodage polynomial là où le décodage ML est NP-difficile. Le graphe de Tanner fournit un cadre géométrique naturel pour les <em>algorithmes itératifs</em> — du Bit-Flipping simple jusqu'au Sum-Product qui approche Shannon à 1 dB. Mon implémentation en Rust — disponible en annexe — couvre la génération de H par Gallager et MacKay-Neal, l'encodage systématique, et les trois décodeurs. Les perspectives naturelles sont : les <em>QC-LDPC</em> pour l'implémentation parallèle sur FPGA, qui sont le standard en DVB-S2 et 5G NR, et des tests sur canal réel. Je suis à votre disposition pour vos questions. »
|
||
</div>
|
||
<div class="slide-note red">
|
||
<span class="note-icon">⚠️</span>
|
||
<div>La slide elle-même est quasi-vide. <strong>Ce script est impératif</strong> — il faut tout dire à l'oral pour donner une vraie conclusion. Ne pas se contenter de lire les 3 mots affichés.</div>
|
||
</div>
|
||
</div>
|
||
</div>
|
||
|
||
</div><!-- /slides-grid -->
|
||
</section>
|
||
<hr class="divider" style="max-width:1100px;margin:0 auto;"/>
|
||
|
||
<!-- ================================================ RÉVISER ================================================ -->
|
||
<section id="reviser">
|
||
<div class="sec-header">
|
||
<span class="sec-num">04</span>
|
||
<h2>Points techniques à maîtriser</h2>
|
||
</div>
|
||
<p style="color:var(--text2);margin-bottom:28px;">Ces points <strong>reviendront en questions du jury</strong>. Savoir les expliquer rapidement à l'oral, sans notes.</p>
|
||
|
||
<div class="review-grid">
|
||
|
||
<div class="review-card">
|
||
<h4>// Mise à jour Sum-Product (CN)</h4>
|
||
<div class="formula">m_{c→v} = 2 tanh⁻¹( ∏_{u∈N(c)\{v}} tanh(m_{u→c}/2) )</div>
|
||
<p>Savoir d'où ça vient : probabilité conditionnelle de parité, lemme de Gallager, passage en LLR via tanh. La dérivation complète est en annexe dans ta présentation. L'intuition : c'est le produit des « croyances » des voisins, exprimées via tanh, puis repassé en LLR via tanh⁻¹.</p>
|
||
</div>
|
||
|
||
<div class="review-card">
|
||
<h4>// Min-Sum : pourquoi ça marche ?</h4>
|
||
<div class="formula">tanh(x/2) ≈ sgn(x) · e^{-|x|/2} pour |x| grand</div>
|
||
<p>L'approximation : le minimum de |m_{u→c}| domine le produit des tanh. On remplace le produit par un minimum. Le facteur α ∈ [0.75, 0.875] compense le biais introduit par l'approximation. Compromis : perte de 0.2–0.5 dB vs Sum-Product, mais implémentable avec des comparateurs et des XOR.</p>
|
||
</div>
|
||
|
||
<div class="review-card">
|
||
<h4>// Pourquoi le BP n'est-il pas exact ?</h4>
|
||
<p>Le BP est exact sur un arbre (graphe sans cycles) — il converge en diamètre(G) itérations. Sur un graphe avec des cycles, les messages se propagent et reviennent à leur point de départ après ℓ itérations (ℓ = girth/2), créant des corrélations artificielles. Ces corrélations violent l'hypothèse d'indépendance des messages entrants, ce qui rend le BP approximatif. Girth élevé → indépendance maintenue plus longtemps → meilleures performances.</p>
|
||
</div>
|
||
|
||
<div class="review-card">
|
||
<h4>// LLR sur canal AWGN</h4>
|
||
<div class="formula">L^canal(y_i) = 2y_i / σ²</div>
|
||
<p>Avec BPSK : bit 0 → +1, bit 1 → −1. Signal reçu y_i = x_i + n_i, n_i ~ N(0, σ²). Le LLR initial est proportionnel au signal reçu — c'est la décision soft optimale sur ce canal. σ² = N₀/2 = 1/(2Rσ_SNR).</p>
|
||
</div>
|
||
|
||
<div class="review-card">
|
||
<h4>// Pourquoi les LDPC approchent Shannon ?</h4>
|
||
<p>La « Density Evolution » (Richardson-Urbanke) permet de calculer analytiquement le seuil de convergence du BP en fonction de Eb/N₀ et des distributions de degrés (λ, ρ). Pour des codes irréguliers optimisés, ce seuil peut être à moins de 0.05 dB de la limite de Shannon. En pratique, DVB-S2 (n=64800, irrégulier) est à ~0.5 dB. La longueur n → ∞ permet d'approcher la limite par la loi des grands nombres.</p>
|
||
</div>
|
||
|
||
<div class="review-card">
|
||
<h4>// Girth minimum d'un code régulier</h4>
|
||
<div class="formula">girth ≥ 4 (toujours pair)</div>
|
||
<p>Girth = 4 : deux colonnes de H partagent au moins 2 positions de 1 → deux VN ont deux CN en commun → corrélation immédiate. MacKay-Neal garantit girth ≥ 6. PEG maximise le girth en construisant arête par arête via BFS. Girth = 4 est interdit : doit être évité à tout prix dans la construction.</p>
|
||
</div>
|
||
|
||
<div class="review-card">
|
||
<h4>// Encodage et complexité</h4>
|
||
<ul>
|
||
<li>Gauss-Jordan sur H → G dense → O(n²) : pas viable pour n=64800</li>
|
||
<li>Richardson-Urbanke (forme ALT) → O(n + g²) avec g le « gap » très petit</li>
|
||
<li>QC-LDPC (blocs circulants) → registres à décalage → O(n) trivial sur FPGA</li>
|
||
<li>DVB-S2 : Z=360, blocs 45×90 → n=64800 avec encodage parallèle</li>
|
||
</ul>
|
||
</div>
|
||
|
||
<div class="review-card">
|
||
<h4>// Questions classiques du jury</h4>
|
||
<ul>
|
||
<li>« Le BP converge-t-il toujours ? » → Non : trapping sets, pseudo-codewords. On fixe Imax.</li>
|
||
<li>« Quelle différence entre Gallager-A et Gallager-B ? » → Seuil de flip : wc vs ≥ b.</li>
|
||
<li>« Pourquoi irrégulier > régulier ? » → VN de degré 2 accélèrent la convergence initiale.</li>
|
||
<li>« Complexity du BP ? » → O(n·wc·Imax) par trame — linéaire en n.</li>
|
||
<li>« C'est quoi un trapping set ? » → Sous-ensemble de VN qui font osciller le décodeur.</li>
|
||
</ul>
|
||
</div>
|
||
|
||
</div>
|
||
</section>
|
||
<hr class="divider" style="max-width:1100px;margin:0 auto;"/>
|
||
|
||
<!-- ================================================ JURY ================================================ -->
|
||
<section id="jury">
|
||
<div class="sec-header">
|
||
<span class="sec-num">05</span>
|
||
<h2>Conseils pour l'oral et le jury</h2>
|
||
</div>
|
||
|
||
<div class="tips-grid">
|
||
<div class="tip-card">
|
||
<div class="tip-icon">🎯</div>
|
||
<h4>Pointer systématiquement</h4>
|
||
<p>Pour chaque matrice, graphe ou courbe, pointer avec un stylo ou le doigt. « Ici, cette colonne a wc = 3 uns » en montrant — ça ancre visuellement le discours et donne de l'assurance.</p>
|
||
</div>
|
||
<div class="tip-card">
|
||
<div class="tip-icon">⏱️</div>
|
||
<h4>Surveiller les transitions</h4>
|
||
<p>Les points de contrôle critiques : à la fin de la partie Codes Linéaires (≈ 3min40), à la fin de Tanner (≈ 7min), à la fin de Bit-Flipping (≈ 9min30). Si tu es en retard, compresser les slides 8-9 et 26.</p>
|
||
</div>
|
||
<div class="tip-card">
|
||
<div class="tip-icon">🔗</div>
|
||
<h4>Faire des liens narratifs</h4>
|
||
<p>Nommer explicitement les connexions : slide 25 → « on est à 5 dB de Shannon », slide 32 → « Sum-Product est à 1 dB », puis « voilà pourquoi DVB-S2 utilise les LDPC ». Le jury doit sentir une progression logique.</p>
|
||
</div>
|
||
<div class="tip-card">
|
||
<div class="tip-icon">📖</div>
|
||
<h4>Formuler en français courant</h4>
|
||
<p>Pour les formules, ne pas lire les symboles — expliquer en mots : « ce produit porte sur tous les voisins du nœud de contrôle sauf celui à qui on envoie le message ». Ça montre une vraie compréhension.</p>
|
||
</div>
|
||
<div class="tip-card">
|
||
<div class="tip-icon">💻</div>
|
||
<h4>Valoriser le code Rust</h4>
|
||
<p>Si le jury demande comment tu as implémenté, dire : « en Rust, avec une représentation CSR+CSC pour H — format creux qui respecte la faible densité —, et un graphe de Tanner précalculé pour le décodage ». Ne pas plonger dans le code en présentation.</p>
|
||
</div>
|
||
<div class="tip-card">
|
||
<div class="tip-icon">🖼️</div>
|
||
<h4>La slide image (30/35)</h4>
|
||
<p>C'est ton argument visuel le plus fort. Si tu sens le jury décrocher, cette slide les raccroche instantanément. Prends le temps de laisser le visuel parler 2 secondes avant d'expliquer.</p>
|
||
</div>
|
||
<div class="tip-card">
|
||
<div class="tip-icon">❓</div>
|
||
<h4>Répondre aux questions</h4>
|
||
<p>Si une question porte sur un concept en annexe (Richardson-Urbanke, codes irréguliers, QC-LDPC, canal AWGN, trapping sets), y répondre directement — tu as tout dans les annexes. Proposer d'y aller si besoin.</p>
|
||
</div>
|
||
<div class="tip-card">
|
||
<div class="tip-icon">🤝</div>
|
||
<h4>Incarner le chercheur</h4>
|
||
<p>Dire « j'ai implémenté », « j'ai simulé », « j'ai observé » — pas « on voit que ». Tu es l'auteur du travail. La courbe de l'image transie — c'est toi qui l'as produite. Le girth de ton code — tu l'as calculé.</p>
|
||
</div>
|
||
<div class="tip-card">
|
||
<div class="tip-icon">🏁</div>
|
||
<h4>Finir en force</h4>
|
||
<p>Les derniers mots de ta conclusion doivent être clairs, posés, avec un regard vers le jury : « Je suis à votre disposition pour vos questions. » Pas d'hésitation, pas de « voilà ». Une phrase ferme, un silence. Ça marque.</p>
|
||
</div>
|
||
</div>
|
||
</section>
|
||
|
||
<footer>Anthony PERRONI · TIPE 2025–2026 · Codes LDPC · Guide généré sur la base de main.pdf</footer>
|
||
|
||
<script>
|
||
function toggle(id){
|
||
const card=document.getElementById(id);
|
||
const body=card.querySelector('.slide-body');
|
||
const icon=card.querySelector('.expand-icon');
|
||
const isOpen=body.classList.contains('open');
|
||
body.classList.toggle('open',!isOpen);
|
||
card.classList.toggle('open',!isOpen);
|
||
}
|
||
function openAll(){
|
||
document.querySelectorAll('.slide-body').forEach(b=>b.classList.add('open'));
|
||
document.querySelectorAll('.slide-card').forEach(c=>c.classList.add('open'));
|
||
document.querySelectorAll('.expand-icon').forEach(e=>e.style.transform='rotate(180deg)');
|
||
}
|
||
function closeAll(){
|
||
document.querySelectorAll('.slide-body').forEach(b=>b.classList.remove('open'));
|
||
document.querySelectorAll('.slide-card').forEach(c=>c.classList.remove('open'));
|
||
document.querySelectorAll('.expand-icon').forEach(e=>e.style.transform='');
|
||
}
|
||
// Highlight active nav section on scroll
|
||
const sections=document.querySelectorAll('section[id]');
|
||
const navLinks=document.querySelectorAll('nav a[href^="#"]');
|
||
window.addEventListener('scroll',()=>{
|
||
let current='';
|
||
sections.forEach(s=>{
|
||
if(window.scrollY>=s.offsetTop-80) current=s.id;
|
||
});
|
||
navLinks.forEach(a=>{
|
||
a.classList.toggle('active',a.getAttribute('href')==='#'+current);
|
||
});
|
||
},{passive:true});
|
||
</script>
|
||
</body>
|
||
</html>
|