4 jours pour défendre une entrevue full-stack R&D

Le strict minimum vital

Java est un langage à typage statique, orienté objet, qui tourne sur la JVM. Tout est classe (sauf primitives : int, long, double, boolean, etc.). Les classes compilent en bytecode (.class) exécuté par la JVM.

Concepts à maîtriser en 1 ligne chacun

• Classe vs interface : une interface décrit un contrat (méthodes abstraites + defaults depuis Java 8), une classe l'implémente.
• Abstract class : peut avoir état et méthodes concrètes, héritage simple uniquement.
• Final : sur variable = constante ; sur méthode = non redéfinissable ; sur classe = non héritable.
• Static : appartient à la classe, pas à l'instance.
• Equals vs == : == compare les références, .equals() compare les valeurs (si bien redéfini).
• hashCode + equals : contrat : si a.equals(b) alors a.hashCode() == b.hashCode(). Obligatoire pour HashMap/HashSet.
• Exceptions checked vs unchecked : checked (ex: IOException) → le compilateur force le try/catch ou throws. unchecked (RuntimeException) → non forcées.

Collections — tableau décisionnel

Streams (Java 8+) — exemple

List<String> names = people.stream()
    .filter(p -> p.age() > 18)
    .map(Person::name)
    .sorted()
    .collect(Collectors.toList());

Pièges que les interviewers adorent

• String immutable : s + "x" dans une boucle = O(n²). Utiliser StringBuilder.
• Autoboxing : Integer vs int, == sur Integer peut surprendre (cache [-128, 127]).
• ConcurrentModificationException : modifier une collection pendant un for-each.
• Null + Optional : Optional est là pour dire "peut être absent". Ne jamais retourner null quand Optional est approprié.

Le pitch en 3 phrases

Spring est un framework Java dont le cœur est l'IoC (Inversion of Control) : au lieu que ton code instancie ses dépendances, c'est le container Spring qui le fait pour toi (Dependency Injection).

Spring Boot ajoute une couche de convention over configuration : starters Maven/Gradle, auto-configuration, serveur Tomcat embarqué → un jar exécutable en 30 secondes.

Stéréotypes Spring

• @Component — générique (bean détecté par classpath scanning).
• @Service — couche logique métier.
• @Repository — couche accès données (+ traduction d'exceptions DB).
• @Controller — MVC web (retourne une vue).
• @RestController — REST JSON (= @Controller + @ResponseBody).

Injection de dépendances — 3 styles

// ✓ Recommandé : par constructeur (immutable, testable)
@Service
public class DocumentService {
    private final OcrEngine engine;
    public DocumentService(OcrEngine engine) {
        this.engine = engine;
    }
}

// Moins recommandé : par field
@Service
public class DocumentService {
    @Autowired private OcrEngine engine;
}

Mini-REST Spring Boot (à pouvoir débiter)

@RestController
@RequestMapping("/api/documents")
public class DocumentController {

    private final DocumentService service;

    public DocumentController(DocumentService service) {
        this.service = service;
    }

    @GetMapping("/{id}")
    public ResponseEntity<Document> get(@PathVariable Long id) {
        return service.findById(id)
            .map(ResponseEntity::ok)
            .orElse(ResponseEntity.notFound().build());
    }

    @PostMapping
    public ResponseEntity<Document> create(@RequestBody @Valid DocumentDto dto) {
        Document saved = service.create(dto);
        return ResponseEntity.status(HttpStatus.CREATED).body(saved);
    }
}

Spring Data JPA — accès DB

@Entity
public class Document {
    @Id @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;
    private String title;
    // getters/setters
}

public interface DocumentRepository extends JpaRepository<Document, Long> {
    List<Document> findByTitleContainingIgnoreCase(String q);
}

Questions susceptibles en entrevue

• "Quelle est la différence entre Spring et Spring Boot ?" → Spring = framework IoC/DI, Spring Boot = Spring + convention + auto-config + serveur embarqué.
• "Pourquoi injection par constructeur ?" → immutabilité (final), testabilité (pas besoin de container pour les tests unitaires), détection précoce des dépendances circulaires.
• "Qu'est-ce que @Transactional ?" → ouvre/commit/rollback une transaction autour d'une méthode. Fonctionne par proxy AOP — attention aux appels internes (this.method() ne déclenche pas le proxy).

ACID en une phrase chacun

• Atomicité : une transaction est tout-ou-rien.
• Cohérence : une transaction passe d'un état valide à un autre (contraintes respectées).
• Isolation : les transactions concurrentes ne se voient pas (selon niveau).
• Durabilité : une fois commit, les données résistent au crash.

Niveaux d'isolation (du plus faible au plus strict)

Index — quand et pourquoi

• Accélère SELECT/JOIN/WHERE sur la colonne indexée.
• Ralentit INSERT/UPDATE/DELETE (index à maintenir).
• Clustered (MSSQL) : les données elles-mêmes sont triées selon la clé (1 seul par table).
• Non-clustered : index séparé pointant vers les lignes.
• Index couvrant : contient toutes les colonnes du SELECT → pas besoin d'aller chercher la ligne.

MSSQL vs Oracle — différences mémorables

Fonctions fenêtre (modernes, souvent demandées)

SELECT
    order_id,
    customer_id,
    total,
    ROW_NUMBER() OVER (PARTITION BY customer_id ORDER BY total DESC) AS rn
FROM orders;
-- rn = 1 pour l'ordre le plus gros de chaque client

Procédure stockée — concept IMDS-pertinent

Dans un produit OCR en prod, tu peux avoir besoin d'un batch : "traite tous les docs reçus aujourd'hui". Une procédure stockée encapsule cette logique côté DB → moins de round-trips réseau, logique réutilisable, granularité de droits.

-- MSSQL
CREATE PROCEDURE dbo.process_pending_docs
AS
BEGIN
    UPDATE documents SET status = 'processing'
    WHERE status = 'pending';
    -- ...
END;

Vocabulaire à maîtriser

• Race condition : deux threads accèdent à une ressource partagée, résultat dépend de l'ordre.
• Deadlock : A attend B, B attend A → plus rien ne bouge. Exemple classique : chacun locke une ressource différente dans l'ordre inverse.
• Livelock : les threads réagissent mais n'avancent pas (comme deux personnes dans un couloir qui se décalent au même moment).
• Starvation : un thread n'obtient jamais la ressource.
• CPU-bound : limité par le calcul. Parallélise sur N cœurs.
• I/O-bound : limité par les attentes (disque, réseau). Async/coroutines / thread pool.

Java — ExecutorService

ExecutorService pool = Executors.newFixedThreadPool(8);
List<Future<OcrResult>> futures = pages.stream()
    .map(p -> pool.submit(() -> ocrEngine.process(p)))
    .collect(Collectors.toList());

for (Future<OcrResult> f : futures) {
    results.add(f.get()); // bloque jusqu'à fin
}
pool.shutdown();

Java — synchronized / volatile / AtomicInteger

// synchronized : verrou sur un objet
public synchronized void increment() { counter++; }

// volatile : garantit visibilité entre threads (pas atomicité)
private volatile boolean running = true;

// Atomic : opérations atomiques sans lock explicite
AtomicInteger counter = new AtomicInteger(0);
counter.incrementAndGet();

Python — le GIL expliqué simplement

Le Global Interpreter Lock empêche 2 threads Python d'exécuter du bytecode en même temps dans le même process. Conséquence :

• CPU-bound + threading = pas d'accélération. Utiliser multiprocessing.
• I/O-bound + threading = ça accélère (GIL relâché pendant I/O).
• asyncio : mono-thread coopératif, idéal pour I/O-bound massif.

from concurrent.futures import ProcessPoolExecutor
with ProcessPoolExecutor(max_workers=8) as ex:
    results = list(ex.map(ocr_process, pages))

C++ — std::thread basique

#include <thread>
#include <mutex>

std::mutex m;
int counter = 0;

void worker() {
    std::lock_guard<std::mutex> lock(m);
    counter++;
}

int main() {
    std::thread t1(worker), t2(worker);
    t1.join(); t2.join();
}

Pattern OCR parallèle (pertinent pour IMDS)

Un document de 100 pages = 100 tâches indépendantes. Le bon pattern : une queue de pages, un pool de workers, collecte ordonnée des résultats. Embarrassingly parallel → speedup quasi-linéaire jusqu'à saturation I/O disque ou mémoire GPU.

Nuances des trois termes (tu vas être testé là-dessus)

• OCR (Optical Character Recognition) : texte imprimé, machine-lisible.
• ICR (Intelligent Character Recognition) : caractères manuscrits, lettre par lettre (formulaires à remplir case par case).
• IWR (Intelligent Word Recognition) : mots manuscrits entiers, cursif — niveau supérieur car il faut aussi segmenter.

Pipeline classique

1. Acquisition : scanner, photo, PDF. Résolution conseillée : 300 DPI pour texte imprimé.
2. Prétraitement :
   • Conversion niveaux de gris.
   • Binarisation (seuillage Otsu, adaptatif Sauvola).
   • Debruitage (médian, bilatéral).
   • Correction de perspective (Hough lines → homographie).
   • Deskew (rotation pour redresser).
3. Segmentation/layout analysis :
   • Détection de zones (texte vs image vs tableau).
   • Segmentation en lignes, mots, caractères (classique) ou bounding boxes (deep).
   • Méthodes : connected components, XY-cut, MSER, CTPN, EAST, DBNet.
4. Reconnaissance :
   • Classique : features + SVM / kNN (obsolète).
   • Moderne : CNN par caractère, CRNN (CNN + BiLSTM + CTC) par ligne.
   • Engine phare open source : Tesseract 4/5 (LSTM).
5. Post-traitement :
   • Correction via dictionnaire, n-grams de langue.
   • Extraction d'entités (dates, montants, numéros) : regex ou NER.
   • Validation métier (somme d'un total, checksum IBAN…).

CTC loss — le truc à savoir expliquer

Connectionist Temporal Classification permet d'entraîner un modèle séquence-à-séquence sans alignement manuel caractère-par-caractère. Le modèle peut prédire un "blank" token et des répétitions, la CTC marginalise sur tous les alignements possibles. Indispensable pour OCR texte manuscrit où on ne sait pas où chaque caractère commence.

Métriques OCR

• CER (Character Error Rate) = Levenshtein(pred, gt) / len(gt). Ex : 2 % signifie 2 erreurs par 100 caractères.
• WER (Word Error Rate) : idem au niveau mot.
• F1 sur entités extraites (dates, montants) — métrique métier.

Évolution rapide du domaine (2019-2025)

Depuis 2020, le paradigme bouge du pipeline modulaire (detect + recognize + layout) vers des modèles end-to-end multi-modaux qui traitent image + texte + layout simultanément.

Modèles à citer pour montrer ta veille

Tradeoffs OCR classique vs end-to-end

Ce que tu peux dire en entrevue (phrase modèle)

"Le domaine a basculé de pipelines modulaires Tesseract + post-traitement vers des approches end-to-end type LayoutLM ou Donut, où le modèle ingère image + tokens + positions. Mais en production bancaire/assurance, on reste souvent sur des architectures hybrides : OCR classique pour la robustesse et l'explicabilité, modèles Transformer pour l'extraction d'entités sur formulaires complexes. Le bon choix dépend du volume de données annotées et des contraintes de latence."

Ton terrain — à réutiliser dans le pitch

• Convolutions, pooling, architectures (ResNet, U-Net, EfficientNet).
• Data augmentation : rotation, flip, crop, color jitter, mixup, cutout.
• Transfer learning : fine-tune un backbone pré-entraîné sur ImageNet, coût réduit.
• Segmentation vs détection vs classification : bien distinguer les 3.
• Pour ton doc IMDS : segmentation de zones de document → U-Net ou Mask R-CNN pertinents.

Pont thèse médicale → OCR documentaire

Les deux sont des problèmes de compréhension spatiale d'images structurées. Un CT-scan 3D a un voxel comme un scan 2D a un pixel. Les CNN/U-Net que tu as utilisés pour segmenter des organes sont les mêmes familles que ceux utilisés pour segmenter des zones de document. Le vocabulaire change, pas la machinerie.

Reconnaissance faciale — survol

• MTCNN : Multi-Task CNN pour détecter visages + landmarks (yeux, nez, bouche).
• FaceNet : triplet loss, embeddings 128-d, similarité cosinus.
• ArcFace : additive angular margin loss → embeddings plus discriminants.
• Pipeline : détection → alignement (affine sur landmarks) → embedding → matching dans DB (FAISS pour 1:N rapide).
• Éthique à mentionner : biais démographiques documentés (NIST FRVT), consentement, RGPD.

À savoir en 10 points

1. Pointeurs vs références : un pointeur peut être nullptr et réaffecté, une référence jamais.
2. new / delete : allocation dynamique manuelle. À éviter en moderne, préférer RAII.
3. RAII (Resource Acquisition Is Initialization) : les ressources sont libérées dans le destructeur → pas de fuites.
4. Smart pointers : std::unique_ptr (propriété unique), std::shared_ptr (comptage de références), std::weak_ptr (casse les cycles).
5. Const correctness : const sur un paramètre, un return type, une méthode membre.
6. Rule of 3/5/0 : si tu définis un destructeur, tu dois probablement définir copy constructor et copy assignment. Règle de 5 ajoute move.
7. Move semantics (C++11) : std::move transfère la propriété sans copie. Grosse perf pour vecteurs, strings.
8. Templates : génériques compilés, équivalent de Java generics mais plus puissants.
9. STL : std::vector, std::map, std::unordered_map, std::string, algorithms std::sort, std::find.
10. Versions : C++11 (move, auto, lambda), C++14, C++17 (std::optional), C++20 (concepts, ranges).

Exemple propre C++ moderne

#include <memory>
#include <vector>
#include <string>

class OcrEngine {
public:
    OcrEngine(std::string model_path) : model_path_(std::move(model_path)) {}
    std::string recognize(const std::vector<uint8_t>& image_bytes) const;
private:
    std::string model_path_;
};

auto engine = std::make_unique<OcrEngine>("model.bin");
auto text = engine->recognize(bytes);

Position honnête en entrevue

"Je lis du C++ moderne sans souci, j'ai fait de la perf numérique pendant ma thèse. Je n'ai pas mis en prod de gros projet C++, donc sur les détails ABI/build systems type CMake, je serais en apprentissage. Mais la sémantique du langage (RAII, move, templates) m'est familière."

C# pour un dev Java

Si tu connais Java, C# est à 80 % familier. Différences notables :

• Propriétés : public string Name { get; set; } — plus de getters/setters manuels.
• LINQ : list.Where(x => x.Age > 18).Select(x => x.Name).ToList() — équivalent streams Java mais en méthodes extension.
• async/await : natif, Task<T> comme CompletableFuture<T>.
• var : inférence de type locale.
• Délégués & événements : pointeurs de fonction typés + pattern pub/sub intégré.
• record (C# 9+) : classes immuables en 1 ligne, comme Java 14+.
• using : équivalent try-with-resources Java.

Écosystème

• .NET (successeur de .NET Core) : cross-platform, open source. .NET Framework : legacy Windows-only.
• Visual Studio : IDE historique Microsoft, très utilisé en C#/C++.
• NuGet : équivalent Maven/npm.
• ASP.NET Core : équivalent Spring Boot pour web.
• Entity Framework Core : ORM équivalent JPA/Hibernate.

Si ils posent une question, voici les points à cocher

• JSX : sucre syntaxique pour React.createElement.
• Hooks : useState, useEffect, useMemo, useCallback, useContext, useRef.
• Règles des hooks : toujours au top niveau, jamais conditionnellement.
• Reconciliation et Virtual DOM : pourquoi React est rapide.
• Keys dans les listes : stabilité du rendu.
• State management : Context, Redux, Zustand, Jotai — savoir quand quoi.
• Server Components (Next.js 13+) : rendu côté serveur, pas d'hydratation.

Piège classique : useEffect et dépendances

// ✗ Bug : infinite loop
useEffect(() => {
    setUser({ ...user, name: 'New' });
}, [user]);

// ✓ Bon : pas de dépendance, effet monté une fois
useEffect(() => {
    fetchUser().then(setUser);
}, []);

JSF (mentionné dans le JD)

JavaServer Faces, framework web Java ancienne génération (composants côté serveur). Très différent de React. Si ils te demandent, dis honnêtement "je ne connais pas, mais j'ai compris que c'est un framework Java de composants UI côté serveur, avec un cycle de rendu similaire dans l'esprit à React/Angular mais exécuté sur JVM".

Ton levier

Tu as une formation QA publique sur ton site (/qa-formation). Cite-la. C'est un différenciateur.

Pyramide des tests

• Unitaires (beaucoup, rapides) : une fonction isolée. JUnit + Mockito (Java), pytest (Python), xUnit/NUnit (C#).
• Intégration (moyen) : plusieurs composants + DB réelle ou testcontainers.
• End-to-end (peu, lents) : Selenium, Playwright, Cypress.

Patterns à connaître

• AAA : Arrange / Act / Assert.
• Mocks vs stubs vs fakes : mock vérifie les interactions, stub retourne une valeur pré-programmée, fake est une vraie implémentation simplifiée.
• TDD : Red → Green → Refactor.
• BDD : Given/When/Then (Cucumber, Gherkin).
• Code coverage ≠ qualité. 80 % de couverture peut rater des bugs. Mutation testing (PIT) plus révélateur.

Exemple JUnit + Mockito

@ExtendWith(MockitoExtension.class)
class DocumentServiceTest {
    @Mock OcrEngine engine;
    @InjectMocks DocumentService service;

    @Test
    void shouldReturnRecognizedText() {
        when(engine.process(any())).thenReturn("hello");
        String result = service.ocr(new byte[]{1,2,3});
        assertEquals("hello", result);
        verify(engine, times(1)).process(any());
    }
}

Tests en contexte OCR

Défi spécifique : comment teste-t-on un modèle ML non-déterministe ? Réponses à avoir :

• Tests de régression sur un dataset de validation figé avec seuil de CER acceptable.
• Tests unitaires sur le pré/post-processing (déterministes).
• Tests de charge (perf, mémoire).
• Tests d'intégration sur docs "réels" du client.
• Monitoring en prod (distribution des scores de confiance, drift de données).

Concepts à citer si la conversation dérive

• SOLID : Single resp., Open/closed, Liskov, Interface segregation, Dependency inversion.
• Clean Architecture / Hexagonal : domaine au centre, adapters à l'extérieur.
• Monolithe vs microservices : IMDS est probablement sur un monolithe modulaire — ça reste légitime.
• REST vs GraphQL vs gRPC : trade-offs (simplicité, flexibilité, perf).
• Webservices SOAP (dans le JD !) : XML, WSDL, encore très présent dans bancaire/assurance. Survol suffit.
• Message queues : RabbitMQ, Kafka, ActiveMQ — utile pour batch OCR asynchrone.
• Patterns : Repository, Service Layer, Factory, Strategy, Observer, Circuit Breaker.

Architecture probable d'IMDS (spéculation raisonnée)

• Backend Java/Spring (+ legacy C++ pour le cœur OCR performant).
• Frontend React moderne + legacy JSF pour l'admin.
• DB MSSQL ou Oracle (clients bancaires = Oracle souvent).
• Intégration SOAP pour clients corporate.
• Batch + streaming pour gros volumes de docs.

Tu peux arriver en disant "je suppose que votre archi ressemble à X, dites-moi si je me trompe" — ça montre que tu as réfléchi.

IDE

• IntelliJ IDEA : référence Java/Kotlin. Raccourcis : Ctrl+N (classe), Ctrl+Shift+N (fichier), Shift+Shift (tout), Ctrl+Alt+L (format), F6 (move).
• Visual Studio : C#/C++. F5 (run debug), F10/F11 (step over/into).
• VS Code : léger, multi-langage.

Build tools

• Java : Maven (XML, déclaratif) et Gradle (Groovy/Kotlin DSL).
• C++ : CMake (quasi standard), Ninja, Make.
• .NET : MSBuild, dotnet build.
• Python : pip, poetry, uv, pyproject.toml.
• JS : npm/pnpm/yarn, bundlers Webpack/Vite/esbuild.

CI/CD

• Jenkins, GitLab CI, GitHub Actions, Azure DevOps, TeamCity.
• Étapes typiques : checkout → build → test unit → test integ → scan sécurité → package → deploy staging.

Git — les trucs à savoir

• Rebase vs merge (préférences d'équipe).
• Stash, cherry-pick, reflog (récupérer un commit perdu).
• Git flow vs GitHub flow vs trunk-based.
• Hooks pre-commit (format, lint) — lien avec ta formation QA.

Vocabulaire incontournable

• Train / val / test : ne jamais toucher le test avant la fin.
• Overfitting : modèle qui mémorise le train, échoue en val. Régularisation, dropout, early stopping, plus de data.
• Bias-variance tradeoff : underfit (haut biais) vs overfit (haute variance).
• Métriques classification : accuracy, precision, recall, F1, AUC-ROC. Matrice de confusion.
• Précision vs rappel : en OCR, si tu préfères rater un caractère que d'en inventer, tu optimises la précision.
• Loss functions : cross-entropy, MSE, L1, Dice (segmentation), triplet (embeddings), CTC (séquences).
• Optimizers : SGD, Adam, AdamW. Learning rate schedule (cosine, warmup).
• Batch norm / Layer norm / Dropout : régularisation.

Transformers en 2 minutes

• Attention = softmax(QK^T / √d) V.
• Self-attention : Q, K, V viennent de la même séquence.
• Multi-head : plusieurs attentions parallèles capturant différents aspects.
• Position encoding : ajoute l'info d'ordre (sinusoïdal ou appris).
• Encoder-only (BERT), decoder-only (GPT), encoder-decoder (T5, TrOCR).

LLMs en production (si ça dérive)

• RAG : retrieval-augmented generation, alternative au fine-tune.
• Vector DB : Pinecone, Weaviate, Qdrant, pgvector.
• Chunking, embeddings, re-ranking.
• Prompt engineering : few-shot, chain-of-thought, structured output (JSON mode).
• Limites : hallucinations, coût, latence, privacy.

Framework STAR pour les anecdotes

• Situation : contexte, en 2 phrases.
• Task : ce qu'il fallait faire.
• Action : ce que toi tu as fait (pas "l'équipe").
• Result : résultat chiffré si possible.

Gérer l'inconnu

• Ne pas bluffer. Dire "je ne connais pas X, mais voici comment je l'aborderais" vaut mieux qu'une réponse fausse.
• Pensée à voix haute : les interviewers aiment voir ton raisonnement.
• Poser des questions de clarification avant de répondre à un exercice technique.

Présentiel — signaux non-verbaux

• Contact visuel, sourire pas forcé, poignée de main ferme (sans écraser).
• Pas de téléphone sur la table.
• Prendre des notes sur le carnet = engagement perçu.
• "Je ne sais pas" dit calmement > 5 min d'invention.

Ton profil doctoral — à encadrer

Risque perçu : "doctorant = chercheur déconnecté du terrain". À contrer explicitement :

• Mentionner tes SaaS freelance (tu as livré des produits en prod).
• Parler deadlines, utilisateurs, contraintes.
• Si tu as un GitHub actif, le mentionner.
• Dire "j'aime autant la rigueur scientifique que l'itération rapide produit".

Ce qu'on te demandera de produire

• Spécifications fonctionnelles : ce que le logiciel doit faire, côté métier. Public : PO, clients, QA.
• Spécifications techniques : comment le faire — architecture, contrats d'API, schémas DB, algos. Public : devs.
• User stories : "En tant que [rôle], je veux [action] afin de [bénéfice]." + critères d'acceptation.
• Diagrammes UML : classe, séquence, cas d'usage, états. Ils ne demandent pas de les faire parfaits, mais de comprendre.

Structure type d'une spec technique

1. Contexte : problème, qui est impacté, lien avec les specs fonctionnelles.
2. Exigences : fonctionnelles (ce que ça fait) + non-fonctionnelles (perf, sécurité, scalabilité, accessibilité).
3. Architecture : diagramme composants, flux de données.
4. Contrats : APIs (REST endpoints, payloads), schémas DB, messages (queues).
5. Algorithmes : pseudocode ou diagramme si complexe.
6. Plan de test : cas nominaux, limites, erreurs.
7. Risques & trade-offs : ce qu'on choisit, ce qu'on abandonne, pourquoi.
8. Plan de livraison : étapes, dépendances, estimations.

Exigences non-fonctionnelles à ne pas oublier

• Performance : latence p50/p95/p99, throughput, consommation mémoire.
• Scalabilité : horizontale (+ machines) vs verticale (+ puissance).
• Disponibilité : SLA, tolérance aux pannes.
• Sécurité : authentification, autorisation, audit log, chiffrement au repos et en transit.
• Conformité : RGPD, Loi 25 (Québec), rétention de données.
• Accessibilité : WCAG pour le front.
• Observabilité : logs, métriques, traces.

Pièges à éviter dans une spec

• Décrire le "comment" avant d'avoir figé le "quoi".
• Oublier les cas d'erreur (40 % des bugs en prod viennent de là).
• Specs trop longues : personne ne les lit. 5-10 pages max pour une feature moyenne.
• Pas de critères d'acceptation mesurables ("rapide" ≠ "< 200 ms p95").
• Absence de section "ce qu'on ne fera pas" — évite le scope creep.

Ressources pour se former

• Livre : "Software Requirements" de Karl Wiegers — la référence.
• Livre : "Writing Effective Use Cases" d'Alistair Cockburn.
• Format design doc : chercher "Google Design Doc Template" ou "RFC Rust" — inspirants.
• UML : plantuml.com et mermaid.js pour diagrammes en texte versionnables.

Ce qu'un bon reviewer regarde, dans l'ordre

1. Correctness : est-ce que le code fait ce qu'il prétend faire ? Y a-t-il des cas limites non couverts ?
2. Tests : couverture suffisante ? tests déterministes ? noms explicites ?
3. Sécurité : injection SQL, XSS, auth, secrets hardcodés, input sanitization.
4. Performance : boucle O(n²) cachée, requêtes N+1, absence d'index, mémoire.
5. Lisibilité : naming, complexité cognitive, commentaires utiles (pas "augmente i de 1").
6. Architecture : respect des couches, couplage, cohésion, SOLID.
7. Convention : style, formatting, imports — idéalement automatique (linter).
8. Doc : Javadoc/docstrings sur API publique, README à jour ?

Ton au moment de commenter

• "nit:" pour un détail mineur (le reviewer OK si ignoré).
• "suggestion:" pour une amélioration non bloquante.
• "blocker:" ou sans préfixe pour un problème qui doit être réglé avant merge.
• Questions > ordres : "Pourquoi avoir choisi X plutôt que Y ici ?" > "Fais Y".
• Complimenter ce qui est bien fait (pas juste les critiques).

Côté auteur de PR

• PR petite : idéalement < 400 lignes modifiées. Au-delà, la qualité de review chute.
• Description claire : contexte, screenshots si UI, lien vers le ticket.
• Répondre à chaque commentaire : accepté + commit, ou argumenté en retour.
• Tests qui passent avant de demander la review.

Ressources

• Google Engineering Practices — Code Review (guide officiel gratuit).
• Livre : "The Art of Readable Code" de Boswell & Foucher — concis et efficace.

Pyramide et stratégie

Voir la fiche "Tests & QA" plus haut pour les bases. Ici, ce qu'on attend d'un analyste-programmeur : rédiger des plans de test et des cas de test, pas juste écrire des tests unitaires.

Plan de test (doc)

• Scope : ce qui est testé / ce qui ne l'est pas.
• Environnements : dev, staging, prod-like.
• Données de test : jeux de données, génération, anonymisation.
• Types de tests : unit, intégration, end-to-end, performance, sécurité, régression.
• Critères de sortie : % de couverture, zéro bug bloquant, perf p95 < X ms.

Cas de test unitaire (template)

1. Identifiant (ex: TC-001).
2. Prérequis / données en entrée.
3. Étapes.
4. Résultat attendu.
5. Priorité (P1/P2/P3).

Spécifique OCR

Tester un modèle non-déterministe : jeu de validation figé, seuil d'acceptation (ex: CER < 2% sur dataset X). Automatiser via un job CI qui relance à chaque changement de modèle.

Types de documentation

Framework Diátaxis (à citer, très pro)

4 quadrants selon que le lecteur cherche à apprendre ou à accomplir, et selon que le document est pratique ou théorique :

• Tutorials — apprendre par la pratique (lesson).
• How-to guides — résoudre une tâche précise.
• Reference — consulter un fait.
• Explanation — comprendre un concept.

Confondre ces modes = doc illisible (ex: un tutoriel qui bascule en explication théorique au milieu).

Javadoc / docstring — minimum viable

/**
 * Recognize text in an image using the configured OCR engine.
 *
 * @param image raw bytes of the document page (PNG or JPEG)
 * @param lang ISO 639-2 language code (e.g. "fra", "eng")
 * @return extracted text, never null, empty string if nothing recognized
 * @throws OcrException if the engine fails or the input is invalid
 */
public String recognize(byte[] image, String lang) throws OcrException { ... }

Formats de réunion probables chez IMDS

• Stand-up quotidien (10-15 min) : hier, aujourd'hui, blockers.
• Sprint planning : sélection des tickets pour le sprint.
• Sprint review / démo : montrer ce qui a été livré.
• Rétrospective : ce qui a marché, ce qui n'a pas, ce qu'on change.
• Design review : discussion technique d'une spec avant implémentation.
• Réunion R&D / chercheurs : discuter papiers, explorer pistes ML.

Posture recommandée

• Arriver avec les éléments demandés (démo prête, chiffres, liens).
• Prendre des notes — même symboliquement, ça montre l'engagement.
• Poser des questions intelligentes — éviter "je n'ai pas compris", préférer "peux-tu préciser X par rapport à Y ?".
• Ne pas monopoliser la parole, mais intervenir au moins une fois par réunion.
• Résumer les décisions par écrit à la fin (bénéfique pour tout le monde + te positionne comme rigoureux).

Réunion R&D : ton terrain

C'est là que ton profil doctoral peut briller. Être capable de :

• Lire un paper et le résumer en 5 minutes pour l'équipe.
• Évaluer si une approche est applicable au produit (faisabilité, coût, perf).
• Proposer des métriques d'évaluation.
• Identifier les limites méthodologiques d'un benchmark.

Tutos courts (1-2 h chacun)

• Spring official guides : "Building a RESTful Web Service" — le tuto canonique sur spring.io/guides. 30 min.
• Baeldung : référence en articles courts. Chercher "Spring Boot tutorial", "Spring annotations", "JPA tutorial".
• Fireship — Spring in 100 seconds (YouTube) : démarrage instantané.
• Amigoscode (YouTube) : série Spring Boot full-stack claire.

Lecture approfondie (si temps)

• "Effective Java" de Joshua Bloch — 3e édition. La bible. Item par item.
• "Spring in Action" de Craig Walls — 6e édition. Pragmatique.
• "Java Concurrency in Practice" de Brian Goetz — pour le multithreading.

Docs officielles (bookmark pour référence)

• docs.spring.io — doc officielle Spring.
• docs.oracle.com/javase — Javadoc standard.

Exercice pratique (obligatoire)

Crée un projet Spring Boot via start.spring.io avec dependencies : Web, JPA, H2. Écris en 2 h un CRUD d'entités. Tu auras touché contrôleurs, services, repositories, entités, config — l'essentiel.

Tutos

• SQLBolt (sqlbolt.com) : interactif, 20 leçons, fait en 2-3 h.
• Mode Analytics SQL Tutorial : progressif jusqu'aux window functions.
• Use The Index, Luke (use-the-index-luke.com) : le meilleur texte sur les index, gratuit.

Docs vendeurs

• docs.microsoft.com/sql — MSSQL / T-SQL.
• docs.oracle.com/database — Oracle / PL/SQL.

Livres

• "SQL Performance Explained" de Markus Winand — 180 pages, absolument essentiel sur la perf.
• "Designing Data-Intensive Applications" de Martin Kleppmann — au-delà de SQL, la référence des systèmes de données modernes.

Exercice

Sur un schéma avec 3 tables (users, orders, products), rédige sans regarder : (1) top 10 users par somme des commandes, (2) users sans commande, (3) produit le plus vendu par mois. Si tu bloques, tu sais où tu dois réviser.

C++ — survol rapide

• cppreference.com — référence canonique, précise (plus que cplusplus.com).
• "A Tour of C++" de Bjarne Stroustrup — 240 pages, écrit par le créateur du langage, survol moderne.
• "Effective Modern C++" de Scott Meyers — pour C++11/14, excellent si temps.
• Les Core Guidelines (isocpp.org/guidelines) — les bonnes pratiques officielles.

C# — survol

• Microsoft Learn — C# guided tour — officiel, gratuit, compact.
• "C# in Depth" de Jon Skeet — pour comprendre les subtilités, mais volumineux.

Objectif 4 jours

Ne cherche pas à maîtriser. Cherche à lire sans être perdu et à avoir 3-4 concepts à citer (RAII, smart pointers, move semantics en C++ ; LINQ, async/await, propriétés en C#).

Papers fondateurs à survoler (abstracts + figures)

• CRNN (Shi et al., 2015) — "An End-to-End Trainable Neural Network for Image-based Sequence Recognition".
• CTC loss (Graves et al., 2006) — le papier original, dense mais clé.
• EAST (Zhou et al., 2017) — détection de zones de texte rapide.
• LayoutLM / LayoutLMv3 (Microsoft, 2019/2022) — multimodal texte + layout + image.
• Donut (Kim et al., 2022) — OCR-free document understanding.
• TrOCR (Li et al., 2021) — Transformer-based OCR.

Outils open source

• Tesseract — OCR historique, LSTM depuis v4. github.com/tesseract-ocr/tesseract.
• PaddleOCR (Baidu) — alternative moderne et puissante, multi-langue.
• EasyOCR — simple à déployer, 80+ langues.
• docTR (Mindee) — open source end-to-end en PyTorch/TF.
• Hugging Face Transformers — pour LayoutLM, TrOCR, Donut, Nougat.

Blogs et tutos

• Towards Data Science — nombreux articles comparatifs OCR (qualité variable, mais bons starter).
• Papers with Code (paperswithcode.com) — filtre "Scene Text Recognition", "Document Understanding".

Rafraîchissement ciblé

• "Dive into Deep Learning" (d2l.ai) — livre interactif gratuit, avec PyTorch/MXNet/TF, théorie + code.
• "The Little Book of Deep Learning" de François Fleuret — concis (200 pages), téléchargeable.
• "Deep Learning" de Goodfellow, Bengio, Courville — la bible (mais long).

Cours

• CS231n (Stanford, Karpathy) — Convnets pour la vision, tous les cours en ligne.
• Fast.ai — "Practical Deep Learning for Coders", approche top-down.
• DeepLearning.AI (Andrew Ng, Coursera) — série historique mais toujours solide.

Chaînes YouTube

• 3Blue1Brown — "Neural networks" série. Intuition mathématique incomparable.
• Andrej Karpathy — "Neural Networks: Zero to Hero" — de backprop from scratch jusqu'à GPT.
• Yannic Kilcher — analyses de papers récents.

Papers à connaître

• AlexNet (2012), VGG (2014), ResNet (2015), Attention is All You Need (Transformer, 2017), BERT (2018), GPT series, CLIP (2021), ViT (2020).

Livres structurants

• "Clean Code" de Robert C. Martin — nommage, fonctions, objets. Classique.
• "The Pragmatic Programmer" de Hunt & Thomas — principes agnostiques.
• "Designing Data-Intensive Applications" de Kleppmann — pour la partie systèmes.
• "Refactoring" de Martin Fowler — catalogue de refactos.
• "Domain-Driven Design Distilled" de Vaughn Vernon — version courte (150 p) de DDD.

Articles

• Google Engineering Practices (google.github.io/eng-practices) — code review, change management.
• Martin Fowler blog (martinfowler.com) — microservices, architecture, refactoring.

Livres

• "Cracking the Coding Interview" de Gayle McDowell — algo/ds interview classiques.
• "System Design Interview" de Alex Xu (Vol 1 & 2) — questions de design.

Plateformes

• LeetCode — problèmes codés. Faire 2-3 easy sur arrays/hashmap pour l'aisance.
• HackerRank — similaire, interviews simulées.

Soft side

• "Staff Engineer" de Will Larson — si tu vises un rôle senior à terme.
• Recherche "STAR method interview" — framework universel pour répondre aux questions comportementales.

Algèbre linéaire (omniprésente)

• Vecteur : x ∈ ℝⁿ — liste de n nombres. Une image 224×224×3 aplatie est un vecteur de dimension 150528.
• Matrice : W ∈ ℝ^(m×n).
• Produit matriciel : y = W x, dimensions (m×n)·(n×1) = (m×1). C'est la brique d'une couche dense.
• Produit scalaire : a · b = Σ aᵢbᵢ. Mesure la similarité entre deux vecteurs (si normalisés = cosinus).
• Norme : L2 = racine de la somme des carrés. Utilisée pour régulariser, mesurer la taille d'un gradient.
• Transposition, inverse, déterminant : à connaître conceptuellement.

Calcul différentiel (cœur de l'apprentissage)

• Dérivée : f'(x) = lim_{h→0} (f(x+h) - f(x)) / h. Pente de la tangente.
• Gradient : généralisation multi-variée. ∇f(x) = (∂f/∂x₁, ..., ∂f/∂xₙ). Pointe dans la direction de plus forte montée.
• Règle de la chaîne (clé de la backpropagation) : si z = f(g(x)), alors dz/dx = dz/dg · dg/dx. C'est la mécanique qui propage les gradients à travers les couches.
• Jacobienne / Hessienne : matrices de dérivées. Rarement utilisées directement en DL (trop chères), mais fondement théorique des optimiseurs d'ordre 2.

Probabilités & statistiques

• Distribution : p(x) donne la probabilité (ou densité) de chaque valeur.
• Gaussienne : N(μ, σ²). Utilisée pour initialiser les poids, modéliser du bruit.
• Maximum de vraisemblance : choisir les paramètres qui maximisent P(données | paramètres). La cross-entropy sort de là.
• Bayes : P(A|B) = P(B|A)·P(A) / P(B). Base des méthodes bayésiennes, du naive Bayes.
• Espérance, variance, covariance : statistique descriptive de base.

Le minimum à pouvoir expliquer en entrevue

"Un réseau de neurones est une fonction paramétrée f(x; θ). On la rend différentiable, on définit une loss L, et on met à jour θ par descente de gradient : θ ← θ - η ∇L. Tout le reste est de l'ingénierie autour de ce principe."

Machine Learning — définition

Toute méthode où un modèle apprend des paramètres à partir de données, plutôt qu'être codé en règles manuelles. Le Deep Learning en est un sous-ensemble.

Taxonomie

• Supervisé : on a (x, y), on apprend f(x) ≈ y. Classification, régression.
• Non supervisé : on n'a que x, on cherche une structure. Clustering (k-means), réduction de dim (PCA, t-SNE, UMAP), génération (VAE, GAN).
• Auto-supervisé : on fabrique les labels depuis les données elles-mêmes. BERT masque des mots et prédit, CLIP aligne image/texte. Base des LLMs modernes.
• Renforcement : agent + environnement + récompense. AlphaGo, robotique, jeux. Moins courant en produit SaaS.

ML classique (avant 2012)

Deep Learning — ce qui change

• Feature learning : fin du feature engineering manuel. Le réseau apprend ses propres représentations.
• Scale : ça marche mieux avec beaucoup de données et de calcul — inverse du ML classique où le plafond arrive vite.
• Universalité : une seule famille d'outils (réseaux + SGD) pour image, texte, audio, tabulaire, séquences.
• Coût : besoin de GPU/TPU, datasets massifs, expertise pour que ça converge.

Quand choisir quoi — règle pragmatique

• Données tabulaires < 100 k lignes → XGBoost / LightGBM. Souvent bat DL et reste interprétable.
• Image, texte, audio, séquence, ou beaucoup de données → DL.
• Besoin fort d'interprétabilité (santé, finance régulée) → régression logistique + SHAP, ou modèles hybrides.
• Peu de labels → auto-supervisé / transfer learning à partir d'un modèle pré-entraîné.

Critique honnête

"Le DL n'est pas magique. Sur des données tabulaires en entreprise, XGBoost le bat régulièrement. Le DL gagne quand la structure des données est spatiale ou séquentielle et que le volume permet d'exploiter la capacité du modèle. Chez IMDS, sur de l'OCR, le DL est incontournable. Sur du scoring de risque sur les métadonnées de docs, XGBoost serait probablement suffisant et plus explicable."

Le neurone artificiel

Formule la plus simple :

z = w₁x₁ + w₂x₂ + ... + wₙxₙ + b   (combinaison linéaire)
a = σ(z)                            (non-linéarité)

• w : poids appris.
• b : biais.
• σ : fonction d'activation (non-linéaire).

Sans la non-linéarité σ, empiler des couches reste linéaire (inutile). C'est la non-linéarité qui donne au réseau sa capacité d'approximation universelle.

Couche dense (fully connected)

z = W x + b       # W: matrice (out, in), x: vecteur (in), b: (out)
a = σ(z)          # activation

Fonctions d'activation — tableau comparatif

Piège fondamental

Un réseau sans non-linéarité = régression linéaire (même si 100 couches). Le nombre de couches ne compense jamais l'absence de non-linéarité.

Définition

Calcul de la sortie du réseau à partir de l'entrée, couche par couche, de l'input vers le output.

Réseau à 2 couches (exemple minimal)

# Input: x ∈ ℝ^n
# Hidden: h = σ(W₁ x + b₁)
# Output: ŷ = W₂ h + b₂ (régression)
# Output: ŷ = softmax(W₂ h + b₂) (classification)

Côté PyTorch

import torch
import torch.nn as nn

class MLP(nn.Module):
    def __init__(self, in_dim, hidden_dim, out_dim):
        super().__init__()
        self.fc1 = nn.Linear(in_dim, hidden_dim)
        self.relu = nn.ReLU()
        self.fc2 = nn.Linear(hidden_dim, out_dim)

    def forward(self, x):
        h = self.relu(self.fc1(x))
        return self.fc2(h)

model = MLP(784, 256, 10)
x = torch.randn(32, 784)       # batch de 32 images flatten
logits = model(x)              # shape (32, 10)

Ce qui se passe en mémoire

• PyTorch construit un graphe de calcul dynamique à chaque forward.
• Chaque opération (linéaire, ReLU, etc.) enregistre ses inputs pour pouvoir calculer les gradients au backward.
• Ce graphe est stocké dans tensor.grad_fn.

Batch, vectorisation, performance

• On traite un batch de N échantillons à la fois, pas 1 par 1 (GPU en raffole).
• Typique : batch size 32, 64, 128, 256, 512 selon la mémoire GPU.
• Batch size élevé = gradient plus stable mais convergence parfois pire (moins de bruit stochastique).

Définition

Une loss est une fonction L(ŷ, y) qui quantifie l'erreur entre la prédiction et la vérité. C'est ce qu'on minimise. Le choix de la loss dépend totalement de la tâche.

Régression (sortie = nombre réel)

• MSE (Mean Squared Error) : 1/N Σ (ŷᵢ - yᵢ)². Sensible aux outliers.
• MAE (Mean Absolute Error) : 1/N Σ |ŷᵢ - yᵢ|. Plus robuste aux outliers.
• Huber loss : MSE si erreur petite, MAE si grande. Compromis.

Classification binaire

• BCE (Binary Cross-Entropy) : -[y log(p) + (1-y) log(1-p)]. Avec sigmoid en sortie.
• BCEWithLogitsLoss en PyTorch : combine sigmoid + BCE pour la stabilité numérique.

Classification multi-classe

• Cross-Entropy : -Σ yᵢ log(pᵢ). Combine softmax + log + négatif.
• Label smoothing : au lieu de 0 ou 1, utiliser 0.1 ou 0.9. Améliore la généralisation.
• Focal loss : pondère les exemples difficiles. Utilisée en détection d'objets (classes déséquilibrées).

Segmentation

• Dice loss : 1 - 2|A∩B| / (|A| + |B|). Bonne pour objets petits/déséquilibrés.
• IoU / Jaccard loss : similaire à Dice, autre formulation.
• Combo : CE + Dice. Pratique courante.

Embeddings / retrieval

• Triplet loss : ancre, positif, négatif. Pousse positif près, négatif loin.
• Contrastive loss : paires (similaire, dissimilaire).
• InfoNCE : contrastive moderne, utilisée par CLIP, SimCLR.
• ArcFace : marge angulaire pour reconnaissance faciale.

Séquences

• CTC loss : alignement-libre, pour OCR, reconnaissance vocale.
• Cross-Entropy par token : génération de texte, traduction.
• Seq2Seq attention : avec teacher forcing.

Détection d'objets

• Multi-tâche : classification + régression de bbox. Loss combinée.
• Smooth L1 / IoU / GIoU / DIoU pour la partie bbox.

Code PyTorch

import torch.nn.functional as F

# Régression
loss = F.mse_loss(pred, target)

# Classification multi-classe (avec logits en entrée)
loss = F.cross_entropy(logits, labels)

# Classification binaire
loss = F.binary_cross_entropy_with_logits(logits, targets)

# CTC
loss = F.ctc_loss(log_probs, targets, input_lengths, target_lengths)

L'idée en une phrase

La backpropagation n'est rien d'autre que la règle de la chaîne du calcul différentiel, appliquée systématiquement au graphe du réseau, pour calculer le gradient de la loss par rapport à chaque paramètre.

Pourquoi c'est nécessaire

Pour mettre à jour un poids w, on a besoin de ∂L/∂w. Mais L dépend de w indirectement, à travers plusieurs couches. La backprop décompose ce calcul.

Illustration à 2 couches

# Forward
z1 = W1 x + b1
a1 = σ(z1)
z2 = W2 a1 + b2
L  = loss(z2, y)

# Backward (règle de la chaîne)
dL/dz2 = dL/dz2                       # dépend de la loss
dL/dW2 = dL/dz2 · a1ᵀ                 # pour mettre à jour W2
dL/db2 = dL/dz2
dL/da1 = W2ᵀ · dL/dz2                 # propager vers la couche précédente
dL/dz1 = dL/da1 * σ'(z1)              # dérivée de l'activation
dL/dW1 = dL/dz1 · xᵀ
dL/db1 = dL/dz1

Chaque couche a deux responsabilités :

1. Calculer dL/d(paramètres) pour se mettre à jour.
2. Calculer dL/d(entrée) à transmettre à la couche précédente.

Autograd en PyTorch

x = torch.randn(10, requires_grad=True)
y = x.sum()
y.backward()          # calcule tous les gradients automatiquement
print(x.grad)         # gradient accumulé dans .grad

Pourquoi "accumulé" et pas "remplacé"

PyTorch accumule par défaut (utile pour gradient accumulation sur plusieurs petits batches). D'où l'appel à optimizer.zero_grad() avant chaque .backward().

Vanishing / exploding gradients

• Vanishing : avec sigmoid/tanh en couches profondes, les gradients deviennent ~0 → les premières couches n'apprennent pas. Fix : ReLU, batch norm, skip connections (ResNet).
• Exploding : gradients qui divergent. Fix : gradient clipping (torch.nn.utils.clip_grad_norm_).

Truc de pro : gradient checking

Pour vérifier une implémentation manuelle de backprop : comparer le gradient calculé à une dérivée numérique (f(x+ε) - f(x-ε)) / 2ε. Coûteux mais imparable.

SGD (Stochastic Gradient Descent)

θ ← θ - η · ∇L(θ)

# η : learning rate
# ∇L : gradient calculé sur un minibatch

Variantes majeures

Learning rate — LE hyperparamètre

• Trop grand → divergence, loss qui explose.
• Trop petit → convergence lente, possible local minimum.
• LR scheduling : diminuer progressivement. Cosine decay, step decay, reduce on plateau.
• Warmup : augmenter progressivement au début — critique pour les Transformers.
• LR finder (Fast.ai) : technique pour trouver un bon LR empiriquement.

Code PyTorch

optimizer = torch.optim.AdamW(model.parameters(), lr=1e-4, weight_decay=0.01)
scheduler = torch.optim.lr_scheduler.CosineAnnealingLR(optimizer, T_max=100)

# Boucle d'entraînement
for epoch in range(100):
    for x, y in dataloader:
        optimizer.zero_grad()
        loss = criterion(model(x), y)
        loss.backward()
        optimizer.step()
    scheduler.step()

Batch size, epoch, iteration — vocabulaire

• Iteration : 1 forward + 1 backward + 1 update sur 1 batch.
• Epoch : 1 passage complet sur le dataset.
• Dataset 10 000, batch 100 → 100 iterations par epoch.

Diagnostiquer l'overfitting

Train loss diminue, val loss stagne ou remonte. Courbes qui divergent = overfitting.

Techniques

• Plus de données (toujours la meilleure).
• Data augmentation : rotation, flip, crop, color jitter, mixup, cutout, cutmix, RandAugment.
• Dropout : désactive aléatoirement p% des neurones pendant le training. p=0.5 dans les papers originaux, 0.1-0.2 pour Transformers modernes.
• Weight decay (L2) : pénalise la somme des carrés des poids dans la loss. Pousse vers poids petits.
• L1 : somme des valeurs absolues, tend à rendre des poids exactement nuls (sparsité).
• Early stopping : arrêter dès que la val loss remonte.
• Label smoothing : évite que le modèle soit trop confiant.
• Model ensembling : moyenner plusieurs modèles.

Normalisation — stabilise l'entraînement

• Batch Normalization : normalise par batch. Populaire en CNN. Problèmes avec petits batches ou RNN.
• Layer Normalization : normalise par sample. Standard en Transformers.
• Group Norm, Instance Norm : variantes pour cas spécifiques (vision, style transfer).

Code PyTorch — dropout & L2

class Model(nn.Module):
    def __init__(self):
        super().__init__()
        self.fc1 = nn.Linear(784, 256)
        self.dropout = nn.Dropout(0.3)
        self.fc2 = nn.Linear(256, 10)

    def forward(self, x):
        x = F.relu(self.fc1(x))
        x = self.dropout(x)
        return self.fc2(x)

# L2 via weight_decay dans l'optimizer
optimizer = torch.optim.AdamW(model.parameters(), lr=1e-3, weight_decay=1e-4)

CNN — Convolutional Neural Networks (vision)

• Convolution : filtre (kernel) glissant sur l'image, produit scalaire local. Partage de poids → invariance par translation.
• Pooling : max ou average sur une région. Réduit la dimension spatiale.
• Receptive field : zone de l'image qui influence un neurone donné. Grandit avec la profondeur.
• Feature map : sortie d'une couche conv (C canaux × H × W).

Architectures historiques à citer

Architectures pour segmentation / détection

• U-Net : encoder + decoder + skip connections. Standard pour segmentation médicale, mais aussi doc.
• Mask R-CNN : détection + segmentation instance.
• YOLO (v1 à v12) : détection d'objets rapide, one-stage.
• DETR (2020) : détection via Transformer, end-to-end sans NMS.

RNN, LSTM, GRU (séquences)

Idée : état caché h_t qui intègre le passé. h_t = f(x_t, h_{t-1}).

• Vanilla RNN : théoriquement puissant, pratiquement instable (vanishing).
• LSTM (1997) : ajoute cell state + gates (forget, input, output). Gère mieux long terme.
• GRU (2014) : simplifié, 2 gates. Moins de paramètres.
• BiLSTM : deux LSTM, un dans chaque sens. Utilisé dans CRNN pour OCR.

Transformers (2017 — le tournant)

Remplace la récurrence par l'attention. Permet parallélisation massive et capture des dépendances à très long terme.

Self-attention en 3 lignes

Q = X W_Q   # queries
K = X W_K   # keys
V = X W_V   # values
Attention(Q,K,V) = softmax(QKᵀ / √d) V

• Multi-head attention : plusieurs attentions en parallèle, concaténées.
• Position encoding : ajoute l'info d'ordre (sinusoïdal ou appris).
• FFN : après attention, un MLP par position.
• LayerNorm + résiduelle : autour de chaque sous-couche.

Variantes

Pourquoi Transformers dominent depuis 2020

• Parallélisme total (contrairement aux RNN).
• Capacité à scaler (plus de data + plus de params = mieux).
• Même architecture, tous domaines (texte, image, audio, vidéo).
• Transfer learning massif via pré-entraînement auto-supervisé.

Les 5 briques

1. Dataset : accès aux données.
2. DataLoader : batch, shuffle, multi-worker.
3. Model (nn.Module).
4. Loss.
5. Optimizer.

Dataset + DataLoader

from torch.utils.data import Dataset, DataLoader
from torchvision import transforms
from PIL import Image

class DocumentDataset(Dataset):
    def __init__(self, paths, labels, transform=None):
        self.paths = paths
        self.labels = labels
        self.transform = transform

    def __len__(self):
        return len(self.paths)

    def __getitem__(self, idx):
        img = Image.open(self.paths[idx]).convert("L")  # grayscale
        if self.transform:
            img = self.transform(img)
        return img, self.labels[idx]

tf = transforms.Compose([
    transforms.Resize((128, 128)),
    transforms.RandomRotation(5),
    transforms.ToTensor(),
    transforms.Normalize([0.5], [0.5]),
])

train_ds = DocumentDataset(train_paths, train_labels, transform=tf)
train_dl = DataLoader(train_ds, batch_size=64, shuffle=True, num_workers=4)

Modèle CNN simple

class DocClassifier(nn.Module):
    def __init__(self, num_classes):
        super().__init__()
        self.features = nn.Sequential(
            nn.Conv2d(1, 32, 3, padding=1), nn.ReLU(), nn.MaxPool2d(2),
            nn.Conv2d(32, 64, 3, padding=1), nn.ReLU(), nn.MaxPool2d(2),
            nn.Conv2d(64, 128, 3, padding=1), nn.ReLU(), nn.AdaptiveAvgPool2d(1),
        )
        self.fc = nn.Linear(128, num_classes)

    def forward(self, x):
        x = self.features(x)
        x = x.flatten(1)
        return self.fc(x)

Training loop pro

device = torch.device("cuda" if torch.cuda.is_available() else "cpu")
model = DocClassifier(num_classes=10).to(device)
optimizer = torch.optim.AdamW(model.parameters(), lr=1e-3, weight_decay=1e-4)
scheduler = torch.optim.lr_scheduler.CosineAnnealingLR(optimizer, T_max=20)
criterion = nn.CrossEntropyLoss()

best_val = float('inf')
for epoch in range(20):
    model.train()
    for x, y in train_dl:
        x, y = x.to(device), y.to(device)
        optimizer.zero_grad()
        logits = model(x)
        loss = criterion(logits, y)
        loss.backward()
        torch.nn.utils.clip_grad_norm_(model.parameters(), 1.0)
        optimizer.step()

    model.eval()
    val_loss, correct, total = 0, 0, 0
    with torch.no_grad():
        for x, y in val_dl:
            x, y = x.to(device), y.to(device)
            logits = model(x)
            val_loss += criterion(logits, y).item() * x.size(0)
            correct += (logits.argmax(1) == y).sum().item()
            total += x.size(0)
    val_loss /= total
    acc = correct / total
    print(f"Epoch {epoch}: val_loss={val_loss:.4f} acc={acc:.4f}")

    if val_loss < best_val:
        best_val = val_loss
        torch.save(model.state_dict(), "best.pt")

    scheduler.step()

Pièges fréquents

• Oublier model.train() / model.eval() — dropout et batchnorm se comportent différemment.
• Oublier optimizer.zero_grad() — gradients accumulés à l'infini.
• Oublier with torch.no_grad(): en validation — RAM qui explose.
• Oublier .to(device) — batch sur CPU, modèle sur GPU → crash.
• Normaliser les données en train et pas en val/test.
• Utiliser le test set pour tuning — data leakage.

Outils modernes à connaître

• PyTorch Lightning : encapsule la training loop, gère GPU/multi-GPU/TPU.
• Hugging Face Transformers + Accelerate : standard pour NLP/multimodal.
• Weights & Biases, MLflow, TensorBoard : tracking des expériences.
• Hydra / OmegaConf : gestion de config.
• Optuna : recherche d'hyperparamètres.

Traitement d'image — prétraitement qu'on applique presque toujours

• Conversion niveaux de gris : 0.299 R + 0.587 G + 0.114 B (luminance ITU-R BT.601).
• Binarisation : seuillage global (Otsu maximise la variance inter-classe), ou adaptatif (Sauvola, Niblack) par fenêtre — indispensable sur scans inégalement éclairés.
• Filtrage : gaussien (flou doux), médian (sel et poivre), bilatéral (préserve les bords), morphologique (érosion/dilation/ouverture/fermeture).
• Détection de contours : Sobel (gradient horizontal/vertical), Canny (bords fins).
• Transformations géométriques : rotation, perspective (homographie via OpenCV cv2.warpPerspective).
• Hough transform : détecter lignes, cercles — utile pour deskew et détection de cadres de formulaires.
• Connected components : identifier des régions connectées — utile pour layout analysis.
• OpenCV est la Swiss army knife de tout ça. PIL/Pillow en alternatif pur Python.

OCR (Optical Character Recognition) — texte imprimé

Pipeline classique :

1. Prétraitement (binarisation, deskew, denoising).
2. Détection de zones de texte (MSER, CTPN, EAST, DBNet).
3. Segmentation en lignes (profils horizontaux de pixels).
4. Reconnaissance ligne par ligne : CRNN (CNN features + BiLSTM + CTC) ou Tesseract (LSTM depuis v4).
5. Post-traitement : dictionnaire, n-grams, correction orthographique.

Moderne : bout-en-bout via Transformers (TrOCR, Donut, Pix2Struct). Pour IMDS bancaire/assurance, hybride reste pertinent : déterminisme + explicabilité.

ICR (Intelligent Character Recognition) — manuscrit case par case

• Typiquement : formulaires où chaque lettre va dans sa propre case.
• Segmentation triviale (boîtes imprimées).
• Reconnaissance caractère par caractère par CNN.
• Datasets classiques : EMNIST, NIST SD19.
• Défi : variabilité des styles d'écriture.

IWR (Intelligent Word Recognition) — manuscrit cursif mot par mot

• Plus dur : pas de séparateurs explicites, lettres liées.
• Modèles : CRNN + CTC (apprend la segmentation implicitement), ou modèles sequence-to-sequence avec attention.
• Lexique contraint améliore beaucoup (nom propre, ville, libellé attendu).
• Datasets : IAM Handwriting Database, RIMES (français).

Reconnaissance de formes — "shape recognition"

• Classique : moments de Hu, descripteurs de forme (Fourier descriptors), contours.
• Moderne : CNN directement.
• Usage IMDS typique : détecter cases à cocher, signatures, logos sur documents.

Reconnaissance faciale

1. Détection : MTCNN, RetinaFace — bounding box + 5 landmarks.
2. Alignement : warp affine sur les landmarks — visage centré, orienté.
3. Embedding : réseau (FaceNet, ArcFace) produit un vecteur de 128 à 512 dim.
4. Matching :
   • 1:1 vérification → distance cosinus + seuil.
   • 1:N identification → recherche approximate nearest neighbor (FAISS, HNSW).

Losses caractéristiques :

• Triplet : pousser ancre-positif proche, ancre-négatif loin.
• ArcFace : marge angulaire dans l'espace des embeddings, SOTA en 2018-2020.

Biais éthiques documentés (NIST FRVT) : accuracy qui varie selon ethnie/genre. À mentionner pour montrer maturité.

Classification de documents

• Par image seule : CNN (ResNet, EfficientNet) sur la mise en page visuelle → marche bien quand les types ont des apparences distinctes (facture vs contrat).
• Par texte OCR : après OCR, classification texte via TF-IDF + SVM (baseline) ou BERT-like (moderne).
• Multimodal : LayoutLM, LayoutLMv3, Donut — image + texte + positions 2D. SOTA depuis 2020.
• Datasets : RVL-CDIP (400k docs, 16 classes), IIT-CDIP.

Extraction d'information sur documents (KIE — Key Information Extraction)

• Au-delà de classifier : extraire des champs structurés (date, montant, numéro).
• Approche texte : NER (Named Entity Recognition) sur le texte OCR. spaCy, BERT NER.
• Approche multimodale : LayoutLM fine-tuné pour token classification avec positions.
• OCR-free : Donut génère directement le JSON structuré.
• Datasets : FUNSD, SROIE (tickets de caisse), CORD, DocVQA.

Classification

OCR & reconnaissance de texte

• CER (Character Error Rate) = Levenshtein(pred, gt) / len(gt). 2% = 2 erreurs / 100 caractères.
• WER (Word Error Rate) : idem au niveau mot.
• BLEU : usuel en traduction, parfois en OCR.

Détection d'objets

• IoU (Intersection over Union) : |A∩B| / |A∪B|. Seuil typique 0.5.
• mAP (mean Average Precision) : moyenne AP sur les classes à divers seuils d'IoU.

Segmentation

• IoU par classe, mIoU.
• Dice : 2|A∩B| / (|A|+|B|).
• Pixel accuracy : trompeuse si classes déséquilibrées.

Régression

• MSE, MAE, RMSE, MAPE, R².

Embeddings / retrieval

• Recall@K, MRR (Mean Reciprocal Rank), NDCG.

Règle d'or : métrique ≠ objectif business

Une accuracy de 95% sur un classifieur médical qui rate les vrais positifs (cancer) est inacceptable. Toujours valider avec le stakeholder métier ce qui compte vraiment. En OCR pour IMDS, rater une date sur un formulaire peut être bien pire qu'une lettre dans le nom du client.

Pièges méthodologiques

• Data leakage : info du test fuit vers le train. Normalisation calculée sur tout le dataset, split par date mal fait, features dérivées du label…
• Split naïf : shuffle aléatoire alors que les données sont temporelles ou groupées (plusieurs échantillons d'un même patient). Toujours splitter au bon niveau.
• Overfit sur le val set : à force de tuner sur val, on finit par overfitter val. Garder un test set vraiment intouché.
• Metric hacking : choisir la métrique qui flatte le modèle plutôt que celle qui compte métier.
• Sélection de seed : tester plusieurs seeds et ne reporter que le meilleur — frauduleux.
• Survivorship bias dans les données : on n'entraîne que sur les cas qui ont été labellisés, qui sont souvent les cas "faciles".

Pièges ingénierie

• Drift de données en prod : la distribution d'entrée change, le modèle se dégrade silencieusement. Monitoring indispensable.
• Reproductibilité : seeds, versions de libs, déterminisme GPU (parfois impossible). Enregistrer tout (code, hash dataset, hyperparams).
• Compute gaspillé : 10 expériences à 100k$ l'une sans hypothèse claire. Définir avant ce qu'on cherche à prouver.
• Deployment drift : prétraitement différent entre training et inference. Tout écrire en pipeline réutilisable.

Biais dans les données

• Reconnaissance faciale : NIST FRVT a mesuré des accuracy très différentes selon ethnie, genre, âge. Conséquence : un système "performant" en moyenne peut échouer systématiquement sur un sous-groupe.
• OCR : datasets publics biaisés vers langues latines, police imprimée propre. Cursif arabe ou texte historique tamoul → performances catastrophiques si pas spécifiquement entraîné.
• Toujours auditer la performance par sous-groupe, pas juste en global.

Interprétabilité

• SHAP, LIME : expliquent des prédictions individuelles.
• Grad-CAM, attention maps : visualiser les zones d'une image qui ont compté.
• Contexte bancaire/assurance (clients IMDS) : le RGPD/Loi 25 Québec peut exiger une "logique du traitement" explicable.

Conformité & privacy

• Documents = données personnelles souvent sensibles. Minimisation, pseudonymisation, chiffrement.
• Droit à l'effacement : si un client demande, il faut pouvoir effacer ses données — y compris des embeddings en cache.
• Entraînement sur données clients : vérifier base légale. Consentement ? Intérêt légitime ? Anonymisation robuste ?

Attitude à tenir en entrevue

Montrer ces préoccupations te distingue d'un candidat "je fit un modèle, regardez l'accuracy". Les équipes R&D matures cherchent des gens qui anticipent les problèmes de prod et d'éthique, pas juste qui codent des notebooks.