Deux fichiers comportent les colonnes date, produit et montant. Leur fusion semble évidente jusqu’au moment où un total devient incohérent. Les noms identiques ne garantissent ni la même unité, ni la même définition, ni la même période. Un tableau peut compter des articles quand l’autre compte des colis ; un prix peut être unitaire dans un fichier et représenter toute la ligne dans l’autre. Avant de réunir les données, il faut construire une correspondance de sens, puis conserver les informations qui permettront de vérifier le résultat.
Lire les colonnes avec leurs définitions
Pour chaque champ, demandez ce qu’une valeur représente exactement. Le montant inclut-il des taxes, une remise ou des frais ? La durée est-elle en minutes ou en heures ? La date correspond-elle à la saisie ou à l’événement ? Un dictionnaire de données peut rester très court : nom, définition, unité et exemple. Le rédiger avant la fusion révèle souvent les différences que l’aperçu du fichier ne montre pas. Faites valider les ambiguïtés par les personnes qui produisent les tableaux.
La documentation Microsoft sur l’ajout de requêtes Power Query décrit la création d’une table à partir de plusieurs tables en s’appuyant sur les en-têtes. Cela explique le fonctionnement d’une opération, pas la cohérence métier des nombres assemblés. Notre article sur un pourcentage d’utilisation du disque illustre autrement l’importance de savoir ce qu’un indicateur mesure avant de l’interpréter.
Décider d’une unité de travail commune
Choisissez l’unité finale en fonction de la question à traiter, puis écrivez la conversion prévue pour chaque source. Une unité commune ne suffit pas si les grandeurs diffèrent : on ne transforme pas automatiquement un nombre de colis en nombre d’articles sans connaître leur contenu. Dans ce cas, il faut obtenir une donnée complémentaire ou conserver des catégories distinctes. Une valeur inconnue mérite un signalement plutôt qu’un coefficient inventé pour que le total paraisse complet.
Gardez les champs d’origine avant conversion. Ajoutez un nom de source et, si possible, un identifiant permettant de retrouver la ligne initiale. Un fichier intermédiaire pourra contenir l’ancien montant, l’unité d’origine et la valeur normalisée. Cette traçabilité des transformations est utile lorsque quelqu’un conteste un résultat ou qu’une règle évolue. Écraser la donnée initiale fait gagner une colonne, mais complique la recherche d’une erreur. La lisibilité du tableau final ne doit pas effacer son histoire.
Tester les cas qui risquent de tromper
Choisissez quelques lignes simples, puis une valeur nulle, une valeur manquante et un cas atypique. Vérifiez les séparateurs décimaux, les dates ambiguës et les codes qui commencent par zéro. Une cellule vide peut signifier absence d’information, tandis qu’un zéro peut être une mesure réelle. Les traiter de manière identique modifie parfois le résultat. Le jeu de contrôle doit refléter les difficultés de vos fichiers, pas seulement les premières lignes propres affichées à l’écran.
Les opérations d’assemblage ont également plusieurs objectifs possibles. Ajouter des lignes de même nature n’est pas rapprocher deux tables grâce à une clé. Si vous reliez des sources, vérifiez que l’identifiant correspond au même objet et qu’une répétition n’augmente pas involontairement le nombre de lignes. Conservez quelques exemples attendus. Notre article sur les variations des réponses d’IA rappelle pourquoi une transformation proposée automatiquement mérite elle aussi une vérification reproductible.
Contrôler le résultat au niveau du détail et du total
Comparez le nombre de lignes attendu, les valeurs manquantes et les sous-totaux par source. Un total général plausible peut cacher deux erreurs qui se compensent. Examinez donc un échantillon de détails, puis quelques regroupements connus des équipes. La validation du résultat doit être faite par une personne qui comprend les données, et pas uniquement par celle qui sait utiliser l’outil. Signalez les exclusions et les hypothèses dans le livrable pour qu’un lecteur ne les interprète pas comme des faits.
Enfin, conservez la règle d’import avec la date, les fichiers utilisés et les limites connues. La prochaine fusion sera plus simple si le producteur sait quels changements de format doivent être annoncés. L’objectif n’est pas de rendre chaque tableau identique dans tous ses usages, mais de réunir des valeurs compatibles pour une question précise. Une fusion fiable commence par le sens des colonnes, poursuit avec des transformations explicites et se termine par des contrôles compréhensibles. Le bouton qui assemble les fichiers n’est que l’une de ces étapes.
