Documenter une veille utile au projet

Une jointure s'exécute, mais elle multiplie les lignes que tu comptes. Ce risque apparaît aussi dans un notebook, un document qui alterne cellules de code, résultats et explications, pendant la préparation des données avant le graphique. Tu trouves une option censée le détecter : comment vérifier qu'elle convient au projet et laisser une preuve utilisable par quelqu'un d'autre ?

Cette fiche travaille la veille du bloc BC04 : partir d'une décision du projet, consulter une source primaire, c'est-à-dire la documentation de l'équipe qui produit l'outil, puis distinguer sa déclaration de ton propre essai.

Poser une question qui permet de décider

« Faire une veille Python » est trop large. Ici, la question est :

Dans notre préparation avec pandas, peut-on faire refuser une jointure si plusieurs lignes de la table des clients portent le même identifiant ?

Pandas est la bibliothèque Python de manipulation de tableaux utilisée dans les notebooks. La décision est d'ajouter ou non ce contrôle avant de produire le fichier destiné au graphique. Elle ne dépend pas du choix de l'outil de BI.

Retrouver une déclaration précise

Ouvre la documentation officielle de pandas.merge. Cherche le paramètre validate. La valeur many_to_one contrôle que la clé de jointure est unique dans le tableau de droite. Dans notre question, les commandes sont à gauche et les clients à droite.

Compare avec la même rubrique de la documentation pandas 2.2.3. Elle décrit déjà ce contrôle. La page courante consultée le 8 septembre 2026 porte la version 3.0.5 et conserve cette règle. Cette comparaison ne donne pas la date de création de l'option et ne justifie pas, à elle seule, une mise à jour.

Remplis ton entrée au moment où tu recherches :

Champ	Exemple documentaire
Question	Refuser une jointure si un identifiant client se répète à droite ?
Source	Équipe pandas, `pandas.merge`, liens directs ci-dessus, rubrique `validate`
Version et dates	Documentation 3.0.5 comparée à 2.2.3 ; consultation le 8 septembre 2026 ; date de mise à jour de chaque page non indiquée
Déclaration	`many_to_one` vérifie l'unicité des clés à droite ; même règle dans les deux pages
Contrôle local	À compléter après l'essai : version, données, commande et résultat observé

Une page peut changer. Conserve avec ton entrée un court extrait ou une capture de la rubrique et son URL. Le copyright en bas de page n'est pas une date de mise à jour. La version de la documentation n'est pas celle de ton notebook.

Faire un essai qui peut contredire la promesse

Le petit jeu ci-dessous est construit pour l'essai, sans données personnelles. Une ligne de commandes représente une commande. Dans clients, l'identifiant x apparaît avec deux villes différentes : le rattachement est ambigu.

Avant d'exécuter, prédis le nombre de lignes après la jointure. Écris aussi quelle commande risque d'apparaître plusieurs fois.

Copie ce bloc dans une nouvelle cellule de ton notebook pandas :

import pandas as pd

print("pandas", pd.__version__)
commandes = pd.DataFrame({
    "commande": ["A", "B", "C"],
    "client": ["x", "y", "y"],
})
clients = pd.DataFrame({
    "client": ["x", "x", "y"],
    "ville": ["Lyon", "Paris", "Lille"],
})
resultat = commandes.merge(clients, on="client", how="left")
print(resultat.to_string(index=False))
print("Lignes avant :", len(commandes), "; après :", len(resultat))

merge réalise la jointure ; on désigne la colonne de correspondance et how="left" conserve toutes les commandes du tableau de gauche. len compte les lignes. Essai exécuté avec pandas 3.0.5 :

commande client ville
       A      x  Lyon
       A      x Paris
       B      y Lille
       C      y Lille
Lignes avant : 3 ; après : 4

La commande A se rattache aux deux lignes x. Compter les lignes de ce résultat comme des commandes compterait A deux fois.

Dans la cellule suivante, ajoute le contrôle trouvé dans la source :

commandes.merge(clients, on="client", how="left", validate="many_to_one")

L'erreur est attendue. L'essai avec pandas 3.0.5 renvoie MergeError et signale que les clés ne sont pas uniques dans le tableau de droite. Conserve le message obtenu avec ta version ; son texte peut différer.

Si pandas n'est pas disponible dans ton environnement, compare les lignes ci-dessus et la déclaration officielle. Inscris « résultat fourni examiné, contrôle local non réalisé ». Cette lecture permet de préparer la décision, mais ne prouve pas que le contrôle fonctionne sur ton poste.

Passer de l'essai à une décision bornée

Complète l'entrée avec trois phrases :

Observation : sur le jeu d'essai, la jointure sans contrôle produit quatre lignes pour trois commandes ; avec many_to_one, pandas 3.0.5 la refuse.
Conséquence : pour une jointure du projet qui attend un seul client à droite par identifiant, retenir ce contrôle avant la production du graphique.
À vérifier : confirmer la clé et la règle métier du vrai jeu, puis rejouer sur l'environnement du projet. Cet essai n'établit pas la qualité des données réelles.

Le contrôle détecte l'ambiguïté ; il ne choisit pas la bonne ville. Ne supprime pas une ligne uniquement pour faire disparaître l'erreur. Et ce contrôle n'établit pas que chaque commande trouve un client : une absence de correspondance demande une vérification distincte.

Modifier l'essai et compléter la preuve

Pour ce jeu fictif seulement, suppose que le responsable de la source confirme une unique entrée x à Lyon et une unique entrée y à Lille. Remplace la création de clients par ces deux lignes, puis rejoue les deux jointures. Prédis le résultat avant l'exécution.

Aide : les listes de la nouvelle table deviennent ['x', 'y'] pour client et ['Lyon', 'Lille'] pour ville.

Vérification : les deux jointures produisent trois lignes, une pour chaque commande, et celle avec contrôle ne lève plus d'erreur. Explique pourquoi les deux commandes du client y restent autorisées : l'unicité demandée porte sur les clients à droite, pas sur les commandes à gauche.

Reprends ensuite les données ambiguës du premier bloc. Dans la documentation, cherche ce que contrôle many_to_many. Décide si cette valeur protégerait le même livrable, puis essaie-la à la place de many_to_one.

Retour : la documentation indique que many_to_many ne réalise pas de contrôle d'unicité. L'essai produit les quatre lignes du premier résultat. Un paramètre nommé validate ne garantit donc pas que la règle attendue est vérifiée : sa valeur compte.

Réutiliser la veille sur ton projet

Choisis une autre question liée à un livrable réel : format accepté par un outil utilisé, comportement d'une fonction ou compatibilité d'une version. Produis une entrée documentaire et un petit essai qui pourrait révéler un écart.

Aide : une documentation explique le comportement annoncé ; une note de version précise un changement et sa version. Compare deux versions si ta question porte sur une évolution. Si tu ne trouves aucune différence sur le point contrôlé, écris-le sans inventer une nouveauté.

Vérification : une autre personne doit pouvoir retrouver la déclaration sans moteur de recherche, identifier la version essayée, refaire le contrôle et expliquer ce que son résultat autorise à décider. Elle doit aussi pouvoir nommer ce qui reste inconnu. Conserve le code et sa sortie dans le dossier du projet, sans données personnelles.

Donne à l'entrée un statut : à vérifier, confirmé sur le cas testé, écart trouvé ou sans effet sur le projet. Nomme le livrable concerné et la personne qui reprend le contrôle. Reviens sur l'entrée avant ce livrable ou lors d'un changement de version ; ajoute une observation datée au lieu d'effacer l'ancienne.