Ta thèse est parfaite ici : "Dans ma thèse, j'ai conçu un laryngophone connecté pour la rééducation vocale. Le pipeline complet : collecte de données audio (design électronique du device), preprocessing (filtrage, MFCC features), entraînement d'un modèle de classification sur des patterns vocaux (CNN/LSTM), puis intégration dans une application mobile. J'ai géré chaque étape de manière autonome."

"Overfitting : le modèle apprend les données d'entraînement par cœur mais ne généralise pas. Solutions : régularisation (L1/L2), dropout, early stopping, plus de données, data augmentation. Underfitting : le modèle est trop simple. Solutions : augmenter la complexité du modèle, réduire la régularisation, ajouter des features pertinentes. Je monitore via les courbes de train/validation loss."

"Pipeline standard : 1) Containerisation (Docker) du modèle et de ses dépendances. 2) API REST (FastAPI) pour exposer les prédictions. 3) CI/CD (GitHub Actions) pour tester automatiquement. 4) Monitoring : drift detection, métriques de perf en prod (via MLflow ou Azure ML). 5) Retraining pipeline planifié quand les métriques dégradent."

"RAG combine un LLM avec une base de connaissances externe (vector store). Le LLM ne répond pas de mémoire, mais récupère d'abord les documents pertinents (via embeddings + cosine similarity) puis génère une réponse contextualisée. On l'utilise quand : le LLM doit connaître des données privées/récentes que le fine-tuning serait trop coûteux à mettre à jour. Exemple : chatbot de support qui répond à partir de la documentation interne."

"Chez Dataroots, j'ai travaillé sur des pipelines complets avec dbt pour la transformation de données et Azure Databricks pour le traitement à grande échelle. Pour le ML spécifiquement, la qualité du pipeline de feature engineering est souvent plus importante que le choix du modèle. J'ai l'habitude de séparer feature store, training set et validation set de manière rigoureuse."

"Mon parcours me donne un avantage rare : je comprends les enjeux métier ET je sais coder. Ma thèse m'a montré que la partie IA dans un projet réel, c'est 20% du travail — le reste c'est ingénierie, collecte de données, integration. Je veux leverager mon background engineering (rigueur, systémique) pour livrer des systèmes ML robustes, pas juste des notebooks."

"J'utilise un framework RICE (Reach × Impact × Confidence / Effort) adapté à la data. Je commence par aligner les stakeholders sur des OKRs communs — si tout le monde veut du 'reporting', je remonte à la question business derrière. Ensuite je score les initiatives et je présente une roadmap trimestrielle avec quick wins clairement identifiés. Sur le projet canadien chez Dataroots, j'ai dû arbitrer entre 3 équipes différentes avec des urgences contradictoires — on a résolu ça avec un comité de gouvernance bi-mensuel."

"Un data product de qualité est : Fiable (SLA clair, tests de qualité automatisés), Découvrable (catalogué dans Collibra ou autre, documenté), Réutilisable (pas un one-shot pour un seul stakeholder), et Actif (des utilisateurs réels l'utilisent en production avec des métriques d'adoption). Le pire data product : le dashboard que personne n'ouvre après le go-live."

"Trois niveaux : 1) Adoption (views uniques/semaine, nb users actifs vs cibles) — Power BI a son usage analytics natif. 2) Impact métier : est-ce que des décisions ont été prises grâce au dashboard ? Je demande un 'decision log' au client. 3) Qualité : taux d'erreur signalées, nombre de tickets de support. Pour le projet football club chez Dataroots, on suivait l'utilisation hebdomadaire et on adaptait les visualisations selon les feedbacks."

"La data governance, c'est l'ensemble des règles, rôles et processus qui garantissent que les données sont fiables, sécurisées et utilisées de manière appropriée. Chez Dataroots, j'ai travaillé avec Collibra pour cataloguer les données, définir les data owners et implémenter des data quality rules. Sans gouvernance : les équipes travaillent sur des versions différentes des mêmes KPIs, la confiance dans la data s'effondre."

"Je parle leur langage : je lis du SQL, je comprends dbt models, je sais ce qu'est un DAG et la différence entre un fact table et une dim table. Ça change tout. Je m'assure que les user stories ont une acceptance criteria précise et testable. Je participe aux code reviews quand c'est pertinent. Mon background ingénieur me permet de ne pas être le 'PM qui ne comprend pas la complexité technique'."

"Je commence par comprendre avec quoi exactement on est comparé — souvent la comparaison n'est pas apples-to-apples. Ensuite je recentre sur la valeur : TCO sur 3 ans, coûts cachés de la migration, coût du non-scalable. Je propose si possible un PoC avec ROI mesurable. L'objectif n'est pas de gagner l'argument prix mais de faire valider la valeur — si on peut montrer un ROI de 3x en 18 mois, le prix n'est plus le sujet."

"Pour une PME : Ingestion → Azure Data Factory ou Fivetran pour synchroniser les sources (ERP, CRM, fichiers). Stockage → Azure Data Lake Gen2 (bronze/silver/gold layers). Transformation → dbt (que je connais bien) sur Azure Synapse ou Fabric. Visualisation → Power BI Service avec Row-Level Security. Gouvernance → Fabric Data Catalog ou Collibra selon la maturité. Timeline réaliste : MVP en 8 semaines."

"Je commence toujours par une slide 'Before/After' avec un vrai cas d'usage de leur industrie. Pendant la démo, je ne montre jamais le back-end — uniquement l'interface utilisateur finale. Je contextualise chaque feature : 'Aujourd'hui, pour obtenir ce chiffre vous avez besoin de 2h de travail Excel chaque lundi — là, c'est automatique et temps-réel.' Je pose des questions tout au long pour valider que je parle de ce qui les intéresse vraiment."

"Le cloud provider (Microsoft/AWS/GCP) prend en charge l'infrastructure physique, le réseau, l'hyperviseur. Le client prend en charge ses données, ses identités, ses applications et selon le modèle (IaaS/PaaS/SaaS) les OS et middlewares. En IaaS (VM) : le client gère l'OS. En PaaS (Azure SQL) : Microsoft gère l'OS et la DB engine, le client gère ses données. En SaaS (Office 365) : Microsoft gère tout, sauf les données et accès utilisateurs."