Les principes

Quand tu lis une solution, ton cerveau dit « oui, logique, je suis » — et il a raison, il comprend. Mais comprendre en lisant ne coûte aucun effort de rappel.

Devant l'éditeur vide, on ne te demande plus de reconnaître : on te demande d'aller chercher. Ce sont deux mémoires différentes, et seule la seconde a été sollicitée.

C'est pour ça qu'on peut suivre un cours entier, tout comprendre, et rester tétanisé devant un fichier vide. Ce n'est pas un manque de connaissances, c'est un entraînement qui n'a jamais eu lieu.

« J'ai fini la leçon » ne veut rien dire. « J'ai compris » non plus — c'est même le piège principal.

Le test est simple et sans appel : page blanche, sans copier-coller, sans regarder le cours, tu écris quelque chose qui marche.

Si tu bloques, tant mieux : tu viens d'apprendre exactement où est ton trou. Ce blocage est l'information que tu cherchais, pas un échec.

Ne commence jamais par du code. Commence par écrire les étapes en français, en commentaires, dans ton fichier :

# 1. ouvrir le fichier / # 2. pour chaque ligne… / # 3. garder ceux au-dessus de 10

Puis tu remplis, une étape à la fois, en exécutant après chacune.

Tu ne te demandes jamais « comment j'écris ce programme » — question impossible. Tu te demandes « comment j'ouvre un fichier » — question à laquelle tu sais répondre en trente secondes.

Et ces commentaires restent dans le code final : ils sont devenus sa structure.

« Comment je fais ce programme ? » n'a pas de réponse. « Comment je trouve le maximum d'une liste ? » en a une, immédiate.

Le blocage vient presque toujours d'une question posée trop haut. Descends d'un cran, puis encore d'un cran, jusqu'à obtenir une question que tu sais traiter.

C'est la compétence qu'on n'enseigne jamais explicitement : passer d'un problème à du code. La syntaxe s'apprend en une semaine, ça, non.

Copier-coller le code d'un cours ne laisse aucune trace. Le retaper caractère par caractère en laisse une.

Mais l'étape qui compte vraiment vient après : ferme le cours et réécris-le de mémoire. Tu vas échouer — c'est exactement le but. L'échec de rappel est ce qui grave, pas la lecture.

Puis modifie-le pour qu'il fasse autre chose. Trois passages, trois profondeurs différentes.

Chercher de l'aide est normal et professionnel. Mais l'ordre change tout.

Même trente secondes de blocage avant de consulter modifient ce qui reste : c'est l'effort de rappel qui ancre, pas la lecture de la réponse.

L'ordre : ton cours et tes notes, puis la documentation, puis l'indice, et la correction en dernier — seulement quand tu as déjà écrit quelque chose, même faux.

Le seul vrai piège serait d'ouvrir la correction avant d'avoir tapé une ligne.

« Comment on écrit ça ? » — la syntaxe de groupby, l'ordre des arguments, comment ouvrir un fichier. Cherche, toujours. C'est ce que font les développeurs professionnels toute la journée. Personne ne retient les signatures par cœur.

« Qu'est-ce que je dois faire ? » — quelle structure choisir, quelles étapes suivre. Là, non. C'est précisément ce que l'exercice entraîne, et le chercher revient à le supprimer.

La première recherche te fait gagner du temps. La seconde te fait perdre l'exercice.

Ne lis pas de haut en bas comme un texte. Cherche d'abord le point d'entrée, puis pour chaque fonction : qu'est-ce qui entre, qu'est-ce qui sort. Ignore l'intérieur au premier passage.

Ensuite exécute-le et mets des print() partout pour voir les valeurs réelles.

Et le meilleur outil de compréhension : casse-le exprès. Change une valeur, supprime une ligne, vois ce qui pète. Ce qui casse te dit à quoi ça servait.

Une fonction qui marche sur l'exemple du cours mais tombe sur une liste vide, une division par zéro ou une valeur manquante n'est pas terminée.

Prends l'habitude de te demander, avant de passer à la suite : « qu'est-ce qui casse ça ? »

C'est la question qui sépare un script d'exercice d'un code sur lequel quelqu'un peut compter.

Tu n'as pas besoin d'une règle sur le nombre de lignes. Le signal est plus simple : si tu peux nommer ce que fait un bloc en trois mots, il mérite d'être extrait.

mention(note), rapport_qualite(df), detecter_derive(ref, prod) — chacun raconte ce qu'il fait sans qu'on lise son contenu.

C'est ce qui rend un fichier lisible : on peut suivre la logique sans jamais descendre dans les détails.

Un KeyError: 'prix' ne dit pas « ton code est mauvais », il dit « Pandas ne trouve pas ce nom de colonne » — et dans l'immense majorité des cas c'est un espace parasite, une majuscule ou un accent.

Le réflexe n'est pas de deviner, c'est d'aller voir : df.columns.tolist().

Chaque message d'erreur contient l'endroit exact où regarder. Apprendre à les lire fait gagner plus de temps que n'importe quelle bibliothèque.

Devant une panne, la tentation est d'essayer des choses. C'est ce qui fait perdre le plus de temps.

La méthode : lister les causes de la plus fréquente à la plus rare, et les éliminer une par une avec un test à chaque fois.

ModuleNotFoundError ? D'abord which python — le venv est-il activé ? C'est le cas dans huit fois sur dix. Faire pip install directement « marche » parfois, en installant au mauvais endroit, et crée un problème plus difficile la semaine suivante.

Avant de toucher à quoi que ce soit, mesure. EXPLAIN ANALYZE pour une requête, %timeit pour du Python, les percentiles pour une latence.

Ajouter un index « au cas où » est un anti-patron : chaque index ralentit les écritures. On optimise ce qu'on a mesuré comme lent, jamais ce qu'on imagine lent.

Et note les deux chiffres. « C'est plus rapide » n'est pas un résultat ; « on est passé de 8 s à 40 ms » en est un.

Cinq commandes au terminal — taille, en-tête, nombre de lignes, recherche, extrait — prennent deux secondes sur un fichier que Pandas mettrait plusieurs minutes à lire.

Elles t'évitent de découvrir au bout de dix minutes que le séparateur est exotique, que l'en-tête tient sur trois lignes, ou que la colonne attendue n'existe pas.

Regarder avant de charger est le réflexe le plus rentable du métier.

Un AUC de 0,99 en détection de fraude ne devrait jamais déclencher une célébration, mais une enquête.

Quand un score s'améliore d'un coup après un changement de préparation des données, la première hypothèse à tester n'est pas « j'ai bien travaillé » mais « ai-je introduit une fuite ? ».

Le doute face à une bonne nouvelle est un réflexe professionnel. Il coûte dix minutes et évite des mois d'illusion.

Pour chaque variable, une seule question : au moment où je dois décider, est-ce que je connais déjà cette valeur ?

montant_rembourse n'existe qu'après qu'une fraude a été constatée. score_risque_final est produit en fin de traitement. Les deux corrèlent magnifiquement avec la cible, et les deux seront vides en production.

C'est une question chronologique, pas statistique — et c'est pour ça qu'aucune bibliothèque ne la posera à ta place.

fit apprend quelque chose des données : une moyenne d'imputation, un écart-type de scaling, un vocabulaire d'encodage.

Si ces paramètres sont calculés en incluant le jeu de test, chaque ligne de test a contribué à sa propre normalisation. Le score devient optimiste et ne se reproduit pas.

La règle vaut pour tout ce qui apprend : imputation, scaling, encodage, sélection de variables, PCA. Et le Pipeline de scikit-learn rend l'erreur structurellement impossible — c'est la vraie raison de l'utiliser.

Produire un tableau croisé n'est que la moitié du travail. La phrase qui l'accompagne est l'autre moitié.

« Une femme de première classe avait 97 % de chances de survivre, un homme de troisième classe 13 % — le sexe pesait plus que la classe, mais les deux se cumulaient. »

Si tu ne peux pas écrire cette phrase, tu as calculé sans comprendre. Et c'est cette phrase, pas le tableau, qui permettra à quelqu'un de décider.

Vingt graphiques produits par réflexe valent moins que six graphiques répondant chacun à une question écrite au-dessus.

Et le type de graphique découle du type des variables, pas du goût : catégorielle × numérique appelle un boxplot, numérique × numérique un nuage de points, beaucoup de paires une heatmap.

L'œil compare très bien les positions et les longueurs, mal les angles et les surfaces. C'est toute la condamnation du camembert.

Un arbre sans contrainte atteint toujours 100 % sur le train : il lui suffit de créer une feuille par exemple. Ce n'est pas de l'apprentissage, c'est une table de correspondance.

Le diagnostic se lit en trois cas : deux courbes basses et proches → sous-apprentissage ; deux hautes et proches → régime sain ; train haute et test basse → mémorisation.

Contraindre un modèle le rend moins bon sur le train et meilleur sur le test. C'est contre-intuitif, et c'est tout le métier.

Chaque fois que tu ajustes un hyperparamètre en regardant le score de test, tu transformes ce test en jeu de validation.

Au bout de quelques allers-retours, il ne mesure plus rien : il te dit ce que tu as optimisé, pas ce que ton modèle vaudra en production.

Les hyperparamètres se choisissent sur un jeu de validation ou par validation croisée. Le test sert une fois, à la fin, pour rapporter un chiffre.

Si tu lances cinquante pièces et gardes la meilleure, elle aura l'air biaisée. C'est exactement ce qui se passe avec cinquante essais d'Optuna sur un même jeu de validation.

La meilleure valeur observée combine la vraie qualité du modèle et la chance d'être tombée sur un découpage favorable. Le gain réel est typiquement la moitié du gain annoncé.

La parade est la validation croisée imbriquée : une boucle interne qui optimise, une boucle externe qui évalue et n'a jamais participé au choix.

Le 0,5 utilisé par défaut n'est optimal que si les classes sont équilibrées et si les deux types d'erreur coûtent la même chose. C'est-à-dire presque jamais.

Si rater une fraude coûte 420 € et bloquer une transaction légitime 20 €, il devient rationnel de bloquer largement : chaque fraude évitée paie vingt et une fausses alertes. Le seuil optimal descend vers 0,08.

La question à poser au métier dès le début d'un projet : que coûte une fausse alerte, et que coûte un cas manqué ? Souvent personne n'a le chiffre, et la poser fait plus avancer le projet que trois points d'AUC.

Une régression logistique prend trente secondes, s'explique à un non-technicien, et donne le plancher de référence.

Si ton XGBoost optimisé ne la bat pas nettement, la complexité supplémentaire n'est pas justifiée — et tu viens de t'épargner un modèle difficile à maintenir et impossible à expliquer.

Le corollaire : sur données déséquilibrées, chiffre aussi le score d'un modèle trivial qui prédit toujours la classe majoritaire. C'est le vrai plancher, et il est souvent gênant.

En production, le score n'est qu'un critère parmi cinq : précision, interprétabilité, temps d'entraînement, capacité à intégrer des variables externes, et coût de maintenance.

Un gain de 2 % de précision ne compense jamais un modèle que l'équipe ne saura pas déboguer un dimanche soir.

Si l'écart entre le meilleur et le plus simple est inférieur à l'incertitude de mesure, prends le plus simple. Toujours.

Le code ne pourrit pas tout seul. Un modèle, si — parce que le monde qu'il décrit change.

Et cette dégradation est silencieuse : une API qui répond en 30 ms avec des prédictions fausses affiche exactement les mêmes métriques d'infrastructure qu'une API qui répond juste.

C'est la différence fondamentale entre déployer un logiciel et déployer un modèle. C'est ce qui justifie l'existence du MLOps.

git rm --cached .env retire le fichier des prochains commits. Il ne l'efface pas de l'historique, ni des serveurs, ni des caches, ni des forks. Des robots scannent les dépôts publics en continu, souvent en moins d'une minute.

Réécrire l'historique est possible et ne change rien au fond : la seule réponse correcte à un secret exposé est de le remplacer.

Le .gitignore se crée au premier commit du projet, avant qu'il y ait quoi que ce soit à protéger.

AmazonS3FullAccess « pour aller plus vite » donne un accès en lecture, écriture et suppression sur tous les buckets du compte — sauvegardes comprises.

N'accorde que ce qui est nécessaire, sur les ressources exactement concernées. Et sépare les droits : une API qui écrit des logs ne doit jamais pouvoir les effacer, ni remplacer le modèle qu'elle lit.

La même logique vaut pour une image Docker : chaque outil superflu qu'elle contient est une surface d'attaque de plus.

Chercher un responsable pousse chacun à minimiser son rôle, ce qui appauvrit l'analyse et fait disparaître l'information utile.

Chercher la faille systémique produit des correctifs qui tiennent — et personne n'a « oublié » un contrôle qui n'existait pas.

Un bon post-mortem dit ce qui s'est passé, pourquoi ça n'a pas été détecté, ce qu'on change, et ce qu'on ne change pas.

Retirer la variable sensible ne fait presque jamais disparaître les écarts entre groupes. Le code postal encode partiellement l'origine géographique et sociale, le type de contrat encode partiellement l'âge.

Le modèle reconstitue l'information à partir de variables corrélées, sans jamais l'avoir vue.

C'est pourtant la réponse la plus fréquente en entreprise. La seule façon de savoir est de mesurer les écarts sur les résultats : taux d'acceptation, faux positifs et faux négatifs, groupe par groupe.

On ne peut pas satisfaire simultanément parité démographique, égalité des chances et calibration : c'est un résultat d'impossibilité démontré, pas une limite technique.

Il n'existe donc pas de modèle « équitable » dans l'absolu. Il faut choisir quel critère privilégier — et ce choix est un arbitrage de valeurs, pas un problème d'optimisation.

Le rôle de l'ingénieur est d'apporter les chiffres du compromis, pas de le trancher seul dans le code. Un choix implicite reste un choix ; simplement, personne ne l'a assumé.

Sans graine fixée, ton collègue relance ton script et obtient 0,84 au lieu de 0,89 — et personne ne sait si c'est le hasard du découpage ou une vraie différence.

La reproductibilité tient à quatre choses : le code, les données (versionnées), l'environnement (versions figées) et l'aléatoire (graines fixées). La cause n°1 des écarts est la deuxième.

Et comme le déterminisme strict est impossible sur GPU, on rapporte une moyenne et un écart-type sur plusieurs graines. « F1 = 0,864 ± 0,011 » est honnête ; « F1 = 0,89 » ne l'est pas.