Les fondamentaux qu’on vérifie avant tout le reste : familles d’apprentissage, jeux d’entraînement et de test, cycle de vie d’un modèle et mise en production.
Cliquez sur une question pour dérouler la réponse attendue.
Ajuster un modèle sur des exemples pour qu’il réponde correctement sur des cas jamais vus. La règle n’est pas écrite à la main : elle est extraite des données.
Lire la réponse détailléeTrois régimes, distingués par ce que vous donnez au modèle, pas par l’algorithme.
Supervisé. Vous donnez des paires (entrées, réponse attendue). Le modèle apprend à reproduire la réponse. C’est le cas de presque tous les projets d’entreprise : risque, fraude, conversion, délai.
Non supervisé. Vous donnez les entrées seules. Le modèle cherche une structure — des groupes, des axes, des écarts. Il n’y a pas de bonne réponse à comparer : la réussite se juge à l’usage.
Par renforcement. Vous ne donnez ni étiquette ni structure. L’agent agit, l’environnement répond par une récompense, et la politique s’ajuste. C’est le régime des décisions en séquence : enchères, recommandation interactive, pilotage.
La phrase qui montre que vous avez compris le découpage : la famille se choisit d’abord, l’algorithme ensuite. Si vous avez une cible mesurable et des exemples passés, vous êtes en supervisé. Si vous cherchez à comprendre un nuage sans vérité, en non supervisé. Si la bonne action dépend de ce qui se passe après, en renforcement.
Ce qu’il ne faut pas faire en une minute : dérouler les algorithmes de chaque famille. L’intervieweur vérifie que vous savez nommer le régime, pas que vous savez implémenter un estimateur. Les méthodes se traitent à part, famille par famille.
Deux précisions qui évitent la réponse de manuel :
Trois mots que tout le reste du sujet suppose. Si vous les mélangez, la conversation suivante part de travers.
L’exemple est une unité d’observation : une ligne, un client à une date, une transaction, une image. C’est un cas. On dit aussi instance, observation, enregistrement. La question de méthode cachée derrière ce mot : à quel grain prévoyez-vous ? Un modèle entraîné par commande ne sert pas une décision par foyer, et inversement.
La variable est une propriété de cet exemple : âge, montant, jour de la semaine, pixel, texte. On dit aussi caractéristique, feature, colonne. Elle est ce que le modèle voit. Elle n’est pas la réponse.
L’étiquette est la réponse connue pour cet exemple, quand elle existe : a résilié, montant réel, classe du dossier. On dit aussi cible, label, vérité de référence. Elle est ce que le modèle doit viser pendant l’apprentissage. En production, elle arrive souvent plus tard, ou jamais.
Un tableau à dire à voix haute :
| Mot | Rôle | Question qu’il pose |
|---|---|---|
| Exemple | une unité | à quel grain décide-t-on ? |
| Variable | une entrée | que sait-on au moment de prédire ? |
| Étiquette | la réponse | que voulait-on vraiment savoir ? |
La confusion junior à corriger tout de suite : l’étiquette n’est pas une variable de plus. Si vous la mettez parmi les entrées, vous ne prédisez plus : vous recopiez. Et la question qui suit naturellement — cette valeur sera-t-elle connue à l’instant de la décision ? — est déjà une question de cadrage, pas d’algorithme.
En entretien, terminer par le vocabulaire de la prédiction : une fois le modèle ajusté, il reçoit des variables et rend une prédiction. L’étiquette, si elle existe encore, sert à mesurer, pas à calculer.
Programmer une règle, c’est écrire le comportement. Apprendre une règle, c’est la faire émerger d’exemples. Les deux produisent un système qui décide. Ils ne se déboguent pas de la même façon, et ils n’ont pas le même contrat.
La règle écrite est explicite : si le montant dépasse 10 000 et que le pays est nouveau, bloquer. Vous la lisez, vous la testez unitairement, vous la changez en changeant le code. Quand elle se trompe, vous savez pourquoi au sens du texte. Quand le métier évolue, quelqu’un met à jour la condition.
La règle apprise est implicite : le modèle a ajusté des milliers de coefficients pour coller aux exemples. Vous ne la lisez pas. Vous la mesurez. Quand elle se trompe, vous inspectez des cas, des variables, des écarts — pas une ligne if. Quand le métier évolue, ce sont les données qu’il faut rafraîchir, pas seulement le code.
Ce que l’intervieweur veut vous entendre dire : ce n’est pas une question de modernité, c’est une question de connaissance. Si le métier sait déjà formuler la décision, l’écrire coûte moins cher que de la faire découvrir. Si la décision dépend d’un mélange que personne ne sait « si-alors », l’apprentissage a un objet.
Trois conséquences pratiques, plus utiles qu’une définition :
La formulation qui clôt : vous programmez ce que vous savez, vous apprenez ce que vous ne savez pas écrire.
On part de la décision métier et de ce qui change si la prédiction existe. Sans destinataire, sans action, il n’y a pas de problème de machine learning à cadrer.
Lire la réponse détailléeElle remplace la cible qu’on voulait vraiment. Le modèle l’atteint, et le métier découvre trop tard que ce n’était pas la question posée.
Lire la réponse détailléeParce qu’un modèle associe, il n’explique pas une intervention. Il répond : quand je vois ceci, cela arrive souvent ensuite. Il ne répond pas : si je change ceci, cela changera. En projet, cette confusion produit des actions qui n’ont aucun effet, ou l’effet inverse.
L’exemple à donner sans théorie : les ventes de glaces et les noyades montent ensemble. Un modèle qui « prédit » les noyades à partir des ventes de glaces aura un beau score en été. Ouvrir plus de glaciers n’évitera aucune noyade. La cause commune, c’est la chaleur.
En entreprise, le même schéma a l’air sérieux.
Ce que l’intervieweur veut : que vous sépariez prédire et agir.
Prédire se contente d’une association stable. Un score de risque pour prioriser une revue humaine peut s’appuyer sur des corrélations, si personne ne croit avoir trouvé le levier.
Agir pour changer la cible exige une hypothèse causale, ou à défaut un essai : on change une chose, on compare. Sans cela, optimiser le modèle revient à optimiser un symptôme.
La phrase utile en réunion : le modèle dit où regarder ; il ne dit pas quoi pousser. Si le commanditaire veut un levier — baisser le churn, augmenter la conversion — le livrable n’est pas seulement un score. C’est un protocole pour tester l’action, et l’honnêteté de dire qu’une variable importante n’est pas un bouton.
Deux précautions de langage qui font senior sans quitter le cadrage : vous évitez « ce facteur cause la résiliation » à partir d’une importance de variable ; vous proposez « si nous faisons X à la moitié des cas, Y bouge-t-il ? ».
En une phrase : chaque exemple est tiré indépendamment des autres, selon la même distribution.
C’est tout. Et c’est déjà beaucoup, parce que presque tout ce que vous mesurez hors production suppose que cette phrase reste vraie demain.
Identiquement distribués : les cas futurs ressemblent, en loi, aux cas sur lesquels vous avez appris et mesuré. Un score de 0,81 n’est une promesse que si le monde de la mesure est le monde du service.
Indépendants : connaître un exemple ne renseigne pas sur le suivant. Deux lignes du même foyer, du même patient, de la même journée de marché, violent souvent cette idée. Le modèle n’est pas « faux » ; c’est votre mesure qui est trop optimiste, parce que les cas ne sont pas de nouveaux tirages.
Ce qu’on attend de vous n’est pas une démonstration. C’est de savoir quand la phrase est invraisemblable, et de le dire avant qu’on célèbre un chiffre.
La conséquence de méthode, sans entrer dans les protocoles de découpage : si les exemples ne sont pas échangeables, le chiffre que vous montrez ne se transportera pas. Vous le signalez, vous adaptez le grain ou la période, et vous cessez de parler comme si l’échantillon était un sondage parfait.
La relance « est-ce toujours faux alors ? » se tranche ainsi : l’hypothèse est un idéal de travail, pas une description du monde. On s’en sert tant qu’elle est assez vraie pour que la mesure serve ; on la quitte dès qu’un groupe, une date ou une décision casse l’échangeabilité.
Généraliser, c’est bien répondre sur des cas que le modèle n’a pas utilisés pour s’ajuster. Ce n’est pas recopier la table d’apprentissage. C’est extraire une régularité assez stable pour servir ailleurs.
La distinction tient en une image : un étudiant qui retrace le corrigé des exercices vus n’a pas encore montré qu’il saura traiter le prochain devoir. Le modèle est dans la même situation. Les exemples d’entraînement sont les exercices vus. La seule preuve qui compte, c’est l’examen — des cas tenus à l’écart, ou mieux, des cas arrivés après.
Ce que l’intervieweur vérifie à ce niveau, c’est le vocabulaire de l’objectif, pas le catalogue des techniques. Vous dites :
Vous n’avez pas besoin, ici, de dérouler les familles de défauts ni les recettes pour les corriger. Ces discussions existent, et elles viennent après avoir nommé le but. Le but, c’est : servir un cas nouveau sans l’avoir appris par cœur.
La phrase qui suffit, et qui est déjà plus rare qu’on ne croit : un modèle n’a de valeur que sur ce qu’il n’a pas vu. Tout le reste du métier — réserve de données, suivi en production, honnêteté des chiffres — n’est que la police de cette phrase.
La métrique technique dit si le modèle prédit juste. La métrique métier dit si la décision vaut mieux. C’est la seconde qui justifie le projet.
Lire la réponse détailléeParce qu’un modèle n’a de sens que s’il bat quelque chose de plus simple, et que ce quelque chose doit exister avant que vous ouvriez une librairie. L’heuristique n’est pas un pis-aller de junior. C’est le premier livrable de méthode.
Vous écrivez d’abord la règle qu’un humain appliquerait lundi matin : toujours la moyenne, toujours le dernier mois, toujours la classe la plus fréquente, toujours « si le montant dépasse X ». Cette règle a trois vertus qu’aucun estimateur n’a encore.
Elle force le cadrage. Pour écrire l’heuristique, vous devez savoir l’unité, l’instant, la décision. Si vous n’y arrivez pas, le problème n’est pas mûr — et le dire maintenant coûte une heure, pas un trimestre.
Elle donne une barre. Tant que vous n’avez pas ce chiffre, « 0,74 » ne veut rien dire. L’heuristique transforme un score en gain. Parfois le gain est nul, et la bonne conclusion est de garder la règle.
Elle valide le tuyau. Brancher les données, produire une prédiction, la mesurer, l’écrire quelque part : si ça échoue sur une moyenne, ça échouera sur un modèle, avec plus de théâtre.
Ce n’est pas la question des catalogues de références par type de tâche. C’est le réflexe : avant d’apprendre, vous essayez de décider sans apprendre. Si la décision s’écrit déjà, vous avez peut-être fini. Si elle ne s’écrit pas, vous savez au moins ce que le modèle doit justifier.
La phrase attendue : le premier système en production d’un projet ML est souvent une règle, et c’est tant mieux. Elle sert les utilisateurs tout de suite, et elle sert de témoin le jour où le modèle arrivera.
Cadrage, données, modèle, déploiement, puis suivi. Sauter la première ou la dernière étape produit un modèle qui n’aide personne, même s’il a un beau score.
Lire la réponse détailléeParce qu’un modèle amplifie ce que vous lui donnez, y compris le bruit, les trous et les mensonges. Changer d’algorithme sur une table sale change le théâtre, pas l’issue. C’est pour ça que les projets bloquent ici, et rarement sur le choix de la librairie.
« Qualité » n’est pas un slogan. En entretien, vous le cassez en questions concrètes.
Est-ce la bonne unité ? Doublons, grains mélangés, un client éclaté en trois identifiants. Le modèle apprend alors des artefacts de système, pas un phénomène.
Est-ce vrai à l’instant de la décision ? Une colonne renseignée après coup, une table qui arrive avec un jour de retard, un champ corrigé à la main deux semaines plus tard. La qualité dans le fichier d’étude n’est pas la qualité au moment de prédire.
L’étiquette est-elle crédible ? Une cible saisie à la va-vite, un statut par défaut, un historique réécrit. Le plafond du modèle, c’est le plafond de cette colonne. Aucun estimateur ne le lève.
Le silence a-t-il un sens ? Une valeur manquante qui veut dire « n’a jamais ouvert le compte », et une autre qui veut dire « le connecteur a planté ». Les traiter pareil, c’est inventer une variable.
Ce que l’intervieweur veut entendre : vous inspectez avant d’apprendre. Volume, fraîcheur, modalités absurdes, ruptures de schéma, désaccord entre deux sources qui devraient dire la même chose. Une journée sur un histogramme et une jointure douteuse rapporte plus qu’une semaine d’essais.
La formulation qui montre le métier : le goulot n’est pas « il nous manque des données », c’est « nous ne savons pas encore ce que ces colonnes veulent dire, ni quand elles existent. » Tant que cette phrase n’est pas close, entraîner, c’est sceller l’ambiguïté dans un artefact.
La labellisation n’est pas une corvée avant le « vrai » travail. C’est le travail : vous fabriquez la vérité que le modèle visera. Son coût et ses désaccords décident souvent du sort du projet, bien avant le premier entraînement.
Le coût n’est pas seulement le tarif à l’exemple. C’est le temps d’experts rares, la rédaction d’un guide, la formation des annotateurs, le contrôle, les allers-retours quand la consigne était ambiguë, et le délai avant d’avoir assez de cas difficiles — ceux qui font la différence. Mille lignes évidentes coûtent peu et n’enseignent rien ; deux cents cas limites coûtent cher et portent le sujet.
D’où la question à poser tôt : avons-nous le droit de ne pas tout étiqueter ? Un échantillon stratifié, une file où l’humain décide déjà, un historique de décisions passées (avec leurs biais) : parfois la cible existe déjà, mal, et il faut décider si on la recycle ou si on recommence.
Le désaccord n’est pas un incident. Si deux annotateurs compétents divergent, la cible n’est pas encore une cible : c’est une notion floue. Le modèle n’arbitrera pas mieux que le guide. Trois réflexes, dans l’ordre :
Ce qu’il ne faut pas faire : moyenniser en silence et passer à l’entraînement. Vous auriez un modèle sûr d’une vérité que les humains ne partagent pas.
La phrase senior : un désaccord entre annotateurs est souvent le premier signal que la question métier n’est pas unique. Parfois il faut deux cibles, ou une règle pour les cas clairs et un humain pour les autres — pas un label unique inventé à la majorité.
Un paramètre est une valeur que le modèle calcule pendant l’entraînement à partir des données. Un hyperparamètre est une valeur que vous écrivez avant, pour dire comment il a le droit d’apprendre.
Le test qui tranche tous les cas : est-ce que cette valeur sort des données, ou est-ce que je l’ai choisie ? Sortie de l’ajustement : paramètre. Choisie par vous : hyperparamètre.
Dans une droite y = ax + b, a et b sont des paramètres. Le nombre de passages sur les données, le rythme d’ajustement, la taille d’un arbre, le nombre de groupes demandés : ce sont des hyperparamètres. Vous ne les « apprenez » pas au même titre ; vous les décidez, éventuellement en comparant quelques essais.
Pourquoi l’intervieweur pose la question : parce que les deux mots circulent comme des synonymes, et que la confusion produit des phrases vides — « on a optimisé les paramètres » sans qu’on sache si quelqu’un a touché la recette ou si le modèle a simplement été réajusté.
Deux conséquences de vocabulaire, sans entrer dans les méthodes de recherche :
Le détail et les exemples de code sont dans hyperparamètres : ce que vous réglez, ce qu’il apprend. En entretien, la phrase suffit : vous réglez les hyperparamètres ; le modèle trouve les paramètres.
En figeant ce qui a produit le chiffre, pas en promettant le bit près sur toutes les machines. Reproductible, ici, veut dire : dans six semaines, un collègue peut retrouver le même essai — mêmes données, même code, mêmes réglages — et comprendre d’où vient le score.
Quatre verrous, et c’est déjà un bon niveau junior.
Les graines. Tout ce qui tire au hasard — découpage, initialisation, échantillonnage — reçoit une graine écrite. Sans ça, deux lancements du même script ne racontent pas la même histoire, et vous comparez du bruit.
La version des données. Un chemin « data/latest » n’est pas une version. Vous pointez un instantané : date, identifiant de table, hash, tag de dépôt. Si quelqu’un a corrigé dix lignes hier, l’essai d’avant-hier n’existe plus.
La version du code. Le commit, pas « le carnet sur ma machine ». Le script d’entraînement, la préparation, les dépendances. Un environnement déclaré — fichier de verrouillage, image — évite le « ça marchait chez moi » de la librairie qui a bougé.
Les réglages et la mesure. Ce que vous avez choisi avant l’ajustement, et comment le score a été calculé. Un 0,91 sans définition n’est pas reproductible : on ne sait pas ce qu’on reproduirait.
Ce que vous n’avez pas à garantir en entretien, et le dire est mature : le déterminisme strict sur GPU, entre deux drivers, n’est pas toujours tenable. Vous visez la rejouabilité de l’expérience, pas la religion du flottant.
La phrase qui clôt : si je ne peux pas nommer le commit, le jeu et la graine, je n’ai pas un résultat, j’ai une anecdote.
Parce que trois jours plus tard, personne ne sait ce qui a produit le 0,93. Pas le modèle exact, pas le jeu, pas le découpage, pas la définition du score. Sans suivi, vous ne comparez plus : vous collectionnez des souvenirs.
Le suivi d’expériences est le carnet de laboratoire du métier. Chaque essai enregistre de quoi prouver que deux lignes sont comparables : données, code, réglages, métrique, durée, auteur. Le score seul ne suffit pas. Si l’essai B a tourné après une correction de préparation, le « progrès » est peut-être un changement de question.
C’est la raison d’être d’un outil comme MLflow. Il n’invente pas la science. Il empêche que le carnet reste un fichier resultats_v7_final_vrai.xlsx sur un poste. Vous lancez une exécution, vous consignez, vous rangez l’artefact, vous retrouvez.
Ce qu’on attend de vous n’est pas une visite guidée de l’interface. C’est de dire pourquoi vous en avez besoin :
Sans cet usage, installer l’outil ne sert à rien. Avec cet usage, même un tableau tenu proprement est déjà du suivi — l’outil devient rentable quand les essais se multiplient et que plusieurs personnes touchent au même problème.
Le fond est développé dans suivi des expériences ; le geste dans le script est dans instrumenter un entraînement avec MLflow.
En une phrase d’entretien : MLflow existe parce que la mémoire de l’équipe n’est pas un système de versions.
Une démarche pour faire vivre un modèle : versionner, déployer, surveiller, réentraîner. Un outil comme MLflow n’en couvre qu’une partie.
Lire la réponse détailléeVous choisissez selon quand la décision a besoin du score, pas selon ce qui paraît plus moderne.
Par lots : vous scorez une population d’un coup, souvent la nuit, vous écrivez le résultat quelque part, et le process le lit plus tard. Convient quand la décision est planifiée — une campagne du lundi, un calcul de risque hebdomadaire, une liste de relances. Le coût se lisse. La fraîcheur est celle du lot. Si rien n’a besoin du score à la seconde, le lot est le bon défaut.
En ligne : vous scorez un cas, maintenant, parce que la décision est dans la requête. Une autorisation, un prix affiché, un message dans un parcours. La latence devient un contrat. Les variables doivent être là à cet instant. Le coût suit le trafic.
La grille de choix, à dire simplement :
| Question | Plutôt lots | Plutôt en ligne |
|---|---|---|
| La décision attend-elle ce soir ? | oui | non |
| Faut-il le dernier clic, la dernière transaction ? | rarement | souvent |
| Tolérez-vous une seconde ? | largement | ça dépend du parcours |
| Combien de cas, quelle régularité ? | une vague | un flux |
Beaucoup de projets commencent en ligne par mimétisme et découvrent qu’un fichier du matin suffisait. L’inverse existe : un lot figé à J-1 pour une décision à la seconde produit des scores déjà morts.
Ce n’est pas encore la question de l’interface (API contre job) : c’est la question du temps de la prédiction. Une fois ce temps choisi, l’interface suit.
La phrase attendue : je score en ligne seulement si la décision est en ligne. Le reste est de l’élégance coûteuse.
Ce n’est pas la même question que « prédire par lots ou à la requête ». Ici, c’est quand les paramètres bougent.
Hors ligne. Vous ajustez le modèle sur un jeu figé, vous le figez à son tour, vous le déployez. Il ne change plus jusqu’au prochain entraînement décidé par quelqu’un — ou par un cycle. C’est le régime de presque toute la production : on sait ce qui est en service, on le teste, on le retire.
En ligne — au sens online learning. Le modèle met à jour ses paramètres au fil des exemples qui arrivent. Il n’attend pas un réentraînement. Il épouse le flux. Utile quand le phénomène tourne plus vite qu’un cycle de release : enchères, contenus, certains ajustements de recommandation.
L’idée à tenir en entretien, sans dérouler les algorithmes : l’apprentissage en ligne échange de la fraîcheur contre du contrôle. Vous gagnez la capacité à suivre le présent. Vous perdez la simplicité d’un artefact versionné que tout le monde a vu. Un mauvais exemple, une saison atypique, une attaque, et le modèle se déplace tout seul.
D’où le réflexe majoritaire : entraîner hors ligne, prédire en ligne si besoin. Les paramètres sont stables entre deux revues. Si le monde accélère, vous raccourcissez le cycle de réentraînement — ce qui n’est pas encore de l’apprentissage en ligne : c’est de l’hors ligne plus fréquent.
Quand l’apprentissage en ligne se justifie vraiment : une cible qui se constate tout de suite, un flux massif, et une équipe capable de borner la dérive des paramètres — seuils, oubli contrôlé, filet de sécurité. Sans cela, « on met à jour en continu » est une phrase, pas un système.
La distinction en une ligne : hors ligne, vous choisissez quand le modèle change ; en ligne, le flux le décide.
C’est l’idée simple, et souvent suffisante : le modèle ne reçoit pas en service les mêmes variables, calculées de la même façon, que pendant l’apprentissage. Il n’a pas « oublié ». On lui parle un autre langage.
Un carnet pandas d’un côté, une requête SQL de l’autre. Un fuseau, un arrondi, une valeur par défaut, un filtre « lignes complètes » qui n’existe plus à l’instant de la requête. Rien de spectaculaire. Assez pour que le score hors ligne reste beau et que la prédiction réelle soit une autre fonction.
On dit training-serving skew. En entretien, une phrase vaut mieux qu’une liste de pannes : deux implémentations de la même variable sont deux variables. Tant que la préparation n’est pas un artefact unique — un pipeline, un magasin, un contrat — l’écart est une question de temps, pas de talent.
Ce n’est pas encore le diagnostic complet d’un modèle qui « marchait au labo ». D’autres causes existent. Celle-ci est la plus banale, et elle se prévient en ne calculant la variable qu’une fois, au même endroit, pour l’apprentissage et pour le service.
La relance « comment vous vous en apercevez ? » : en comparant, sur les mêmes cas, ce que le carnet aurait envoyé et ce que l’endpoint envoie. Si les vecteurs diffèrent, vous n’avez pas un problème de modèle. Vous avez deux systèmes.
Pas la personne qui a entraîné le dernier carnet. Un modèle en service est un produit, et un produit a un propriétaire nommé, joignable, capable d’arrêter la bascule. Si vous ne savez pas qui c’est, personne ne le possède — et c’est déjà une réponse.
La propriété se découpe. L’erreur est de la laisser entière sur le data scientist, ou entière sur la plateforme.
Le métier possède la décision. C’est lui qui dit si l’on s’en sert, à quel seuil de courage, et si le projet continue. Un score orphelin dans une table n’a pas de propriétaire : il a un auteur oublié.
L’ingénierie possède le service. Disponibilité, latence, rollback, secrets, capacité. Le modèle est un artefact dans une chaîne, comme un binaire. Quand l’API tombe à 3 h, ce n’est pas un problème de score.
La science des données possède la recette. Données admissibles, hypothèses, rythme de réentraînement, lecture des écarts. Elle ne « livre pas et part ». Elle reste l’interprète de ce que le modèle fait encore.
En entretien, on veut les noms de rôles et le week-end. Qui valide une promotion ? Qui est réveillé ? Qui a le droit de couper ? Un modèle de risque dans un flux d’autorisation sans astreinte n’est pas en production : il est en probation permanente.
La phrase qui sépare un candidat qui a opéré : posséder, c’est pouvoir arrêter. Si personne n’a l’autorité de retirer le modèle sans réunion de crise, la propriété est une fiction, et le prochain incident l’écrira à votre place.
Quand une politique le dit, pas quand quelqu’un a une intuition le vendredi. Réentraîner est un déploiement. Chaque fois, vous prenez le risque de remplacer un champion par un candidat moins bon, ou par un candidat ajusté sur des étiquettes encore molles.
La politique tient en trois déclencheurs, et un interdit.
Le calendrier, comme plancher. Une cadence calée sur la vitesse du phénomène : la semaine pour des habitudes d’achat, le trimestre pour un risque lent. Prévisible, budgété, sans héroïsme. Réentraîner « plus souvent » n’est pas plus sûr : c’est plus de bascules.
La performance constatée, comme exception. Les vraies étiquettes, une fois mûres, passent sous un seuil convenu. C’est le déclencheur le plus juste, et le plus lent. Il suppose que quelqu’un rattache la vérité aux prédictions passées.
Une revue humaine, comme filet. Un comité court, ou un unique propriétaire, qui dit oui à la bascule. Un cycle entièrement automatique qui promeut parce que le job est vert n’est pas une politique : c’est une habitude.
L’interdit : promouvoir parce que c’est récent. Un modèle n’est pas meilleur à la date du jour. Le candidat et le champion se mesurent sur les mêmes données récentes ; on ne bascule que si l’écart dépasse le bruit. Sinon on garde le champion, et on a quand même appris quelque chose.
Vous ne déroulez pas ici les tests de distribution ni le vocabulaire des dérives : ce sont d’autres questions. Vous dites simplement que le monde bouge, que le calendrier existe pour ça, et qu’une alerte amont n’est pas, à elle seule, un ordre de remplacer.
Le détail — fenêtre de données, étiquettes immatures, critère de bascule — est dans réentraîner un modèle : quand, et sur quelles données.
En une phrase : je réentraîne selon une cadence et une règle de promotion, jamais selon l’humeur ni selon la fraîcheur du fichier.
Le modèle change le monde qu’il prédit. Les données de demain ne sont plus celles d’hier, et réentraîner sans précautions apprend sa propre politique.
Lire la réponse détailléeLe démarrage à froid (cold start), c’est devoir décider pour un cas dont vous n’avez pas encore l’historique que le modèle sait lire. Un nouvel utilisateur, un nouvel article, un nouveau marché, un nouveau produit : les variables qui font d’habitude le travail sont vides.
Ce n’est pas une panne. C’est un trou structurel du problème. Le modèle entraîné sur des clients de trois ans ne sait rien d’un compte ouvert ce matin. Lui envoyer des zéros, c’est lui faire croire qu’il reconnaît quelqu’un.
En entretien, on attend que vous nommiez le trou, puis que vous parliez d’une politique de repli — pas d’un algorithme miracle.
Une règle en attendant. Popularité, moyenne du segment, offre d’accueil, file humaine. Le premier système d’un nouveau catalogue est souvent une heuristique, et c’est honnête.
Demander un peu d’information. Trois préférences, un secteur, une photo. Vous créez l’exemple au lieu de faire semblant qu’il existe.
S’appuyer sur le semblable, sans mentir. Un contenu neuf hérite des traits de sa catégorie, pas d’un historique qu’il n’a pas. Vous le dites au métier : la qualité sera celle du voisinage, pas celle des vieux titres.
Décider quand le modèle a le droit de prendre la main. Un seuil de volume, une durée, un nombre d’événements. Avant ça, le score du modèle n’est pas un score : c’est une extrapolation déguisée.
La confusion à éviter : ce n’est pas « on manque de données en général ». C’est cette unité-là qui n’a pas de passé, alors que les autres oui. Un système mature a deux chemins : le modèle pour les cas riches, la politique de froid pour les autres.
La phrase utile : le démarrage à froid se conçoit, il ne se « laissera pas absorber » par plus d’entraînement.
La cible, les données, l’usage prévu, les limites et qui l’opère. Assez pour qu’un tiers décide de s’en servir — ou de s’en passer — sans rouvrir le carnet.
Lire la réponse détailléeOn nomme qui peut être lésé, comment on le verrait, et ce qu’on ferait d’un écart. L’honnêteté du raisonnement compte plus qu’une recette ou qu’un déni.
Lire la réponse détailléeÀ un seul, d’abord, et il suffit en entretien : calculer la même variable une fois, et la relire à l’apprentissage comme au service. Tant que chaque équipe réécrit « montant moyen 30 jours » dans son coin, vous avez autant de définitions que de carnets — donc un écart entraînement-service programmé.
Le magasin de variables (feature store) est ce contrat. Une définition, une table ou un service, un point dans le temps. L’entraînement demande : que savait-on de ce client mardi à 11 h ? Le service demande la même chose, maintenant. Si les deux lectures ne passent pas par la même recette, le magasin n’a pas servi.
Ce n’est pas « une base de plus pour ranger des colonnes ». Ranger sans contrat de temps, c’est un lac. Le mot qui justifie l’objet, c’est la cohérence temporelle et organisationnelle : plus personne n’invente la variable dans un notebook de vendredi soir.
Vous n’avez pas à dessiner une plateforme. Vous dites quand ça commence à valoir le coût : plusieurs modèles, plusieurs consommateurs, des variables coûteuses, une production qui ne pardonne pas deux SQL divergents. Un unique modèle lu par un unique job peut vivre avec un pipeline unique versionné. Le magasin devient intéressant quand la même définition doit survivre à plusieurs équipes.
La phrase à garder : le magasin ne rend pas les variables plus intelligentes ; il empêche qu’elles deviennent plusieurs variables.
Une fois décidé quand vous prédisez, il reste comment vous livrez le score. L’API et le job sont deux interfaces. On les choisit sur le contrat d’intégration, pas sur le prestige.
Le job par lots écrit une table, un fichier, une partition. Les consommateurs lisent quand ils veulent. Vous maîtrisez l’heure, le débit, le relancement. Les échecs se voient comme un job rouge, pas comme une file d’utilisateurs. C’est le bon défaut dès que personne n’attend une réponse HTTP pour avancer.
L’API de scoring répond à un appel : voici les variables, voici le score. Elle se justifie quand un système déjà synchrone — un site, un moteur d’autorisation, un outil interne — ne peut pas attendre le prochain fichier. Vous achetez alors la disponibilité, la latence, le dimensionnement, l’authentification, le versionnement d’endpoint.
La grille, volontairement terre à terre :
Les deux coexistent souvent : un job calcule le gros, une petite API sert les cas nouveaux. Ce n’est pas une trahison du choix, c’est une architecture.
Ne pas confondre avec « prédiction en ligne contre par lots » : on peut prédire en ligne via un job très fréquent, et on peut exposer une API qui ne fait que lire un score déjà écrit. L’interface n’est pas le régime temporel. En entretien, séparer les deux phrases montre que vous avez déjà branché un modèle à autre chose qu’un notebook.
La règle : j’offre une API seulement si quelqu’un doit m’appeler ; j’offre un job si quelqu’un doit lire.
Quand la décision s’écrit déjà, et que l’apprendre n’ajoute que de l’opacité. Ce n’est pas une question « ML ou pas ML » au sens large : c’est le face-à-face règle contre modèle sur un sujet que le métier sait formuler.
La règle gagne dans des cas très concrets, que vous nommez sans théâtraliser.
Le métier énonce la politique. « Au-delà de tel montant, revue obligatoire. » « Ce code produit n’a pas le droit à ce canal. » Ce n’est pas un motif caché dans une table : c’est une norme. Un modèle qui la redécouvre est un luxe. Un modèle qui la contourne est un incident.
Il faut pouvoir expliquer la décision en une phrase, à un client ou à un auditeur. La règle se lit. Le modèle se raconte, au mieux. Quand la lisibilité est le produit — tarif, éligibilité, conformité — la règle n’est pas un pis-aller. C’est le livrable.
On doit tester unitairement, aujourd’hui. Une condition se pince dans un test. Un artefact appris se mesure statistiquement. Si l’équipe n’a que la première discipline, forcer le second outil crée une dette que personne n’opère.
Le gain mesuré est trop mince pour payer le système vivant. Une heuristique déjà en place, comprise, branchée : si le modèle gagne un point illisible et coûte une astreinte, la règle a gagné économiquement. C’est une victoire, et il faut oser l’écrire.
Ce que vous n’enroulez pas ici : la liste des raisons d’abandonner tout un projet d’apprentissage. D’autres questions couvrent le volume, les étiquettes, le maintien. Ici, le modèle pourrait exister. Vous dites pourquoi la règle reste devant.
La combinaison, souvent la vraie réponse : la règle pour les interdits et les évidences, le modèle pour la zone grise. En entretien, ça sonne plus juste qu’un camp.
La phrase qui clôt : battre un modèle, pour une règle, ce n’est pas refuser le progrès ; c’est refuser d’apprendre ce qu’on sait déjà.