Comment nettoyer les exports CSV et SAP avant le reporting

On blâme souvent le tableau de bord quand un rapport est en retard, confus ou erroné.

Cependant, le tableau de bord n'est souvent pas le véritable goulot d'étranglement. Le problème vient généralement du fichier source qui arrive avant même que le tableau de bord n'existe : un export CSV, une extraction SAP, un fichier texte copié-collé ou un classeur qui n'a jamais été conçu pour l'analyse.

Un utilisateur de Reddit sur r/excel a parfaitement résumé le problème. Il reçoit des extractions SAP, des CSV avec des délimiteurs aléatoires et des fichiers texte où les colonnes se décalent ou les en-têtes se cassent. Excel ne détecte pas toujours correctement le délimiteur. Avant de pouvoir analyser quoi que ce soit, il passe des heures à rendre le fichier exploitable. Il a également soulevé une question pratique que beaucoup d'équipes évitent : si un site web peut corriger le fichier automatiquement, êtes-vous à l'aise avec l'idée d'y télécharger les données de vos clients ?

Cet exemple provient d'une discussion Reddit sur la correction des extractions SAP, des fichiers CSV et des exports texte désordonnés.

C'est un meilleur point de départ que n'importe quel article sur l'esthétique des tableaux de bord. La plupart des rapports d'activité échouent bien plus tôt : au moment où les données d'entrée ne sont pas fiables.

Le travail invisible avant l'analyse

Un export d'entreprise peut sembler simple car il s'ouvre dans Excel.

Cela ne signifie pas qu'il est prêt pour l'analyse.

Un CSV peut utiliser des points-virgules dans un export et des virgules dans un autre. Un fichier texte peut contenir plusieurs lignes descriptives avant le véritable en-tête. Une extraction SAP peut inclure des étiquettes fusionnées, des lignes de sous-totaux, des lignes vides de séparation ou des pieds de page qui ressemblent à des données. Les dates peuvent arriver dans des formats mixtes. Les montants peuvent utiliser différentes conventions de devise ou de débit-crédit. Une colonne peut se décaler parce qu'une ligne contient un délimiteur inattendu à l'intérieur d'un champ de commentaire.

Rien de tout cela ne semble stratégique. Cela ressemble à du simple nettoyage.

Pourtant, c'est lors du nettoyage que se décide la véracité du rapport. Si la mauvaise ligne devient l'en-tête, chaque nom de colonne suivant est suspect. Si une ligne de pied de page reste dans les données, un total peut être compté deux fois. Si une colonne de date contient à la fois du texte et des valeurs de date, le reporting mensuel peut ignorer certains enregistrements sans prévenir.

C'est pourquoi l'instruction "créez simplement un tableau de bord" est souvent erronée. Un tableau de bord construit sur un export mal interprété ne fait que faciliter le partage de données erronées.

Ne jamais modifier le fichier brut

Le flux de travail le plus sûr sur tableur commence par une règle simple : ne modifiez jamais l'export brut directement.

Conservez le fichier original comme preuve. Créez une couche de travail propre à côté. Rendez ensuite visibles toutes les décisions de nettoyage.

Pour les exports complexes de type CSV ou SAP, la première révision doit répondre à des questions simples :

• Quelle ligne est le véritable en-tête ?
• Quelles lignes doivent être ignorées (titres, notes, vides, sous-totaux ou pieds de page) ?
• Quel délimiteur a été détecté ?
• Quelles colonnes ont changé de type ?
• Quelles dates ou quels montants n'ont pas pu être analysés correctement ?
• Quels champs ont été renommés ou fusionnés ?

Ces questions sont cruciales car le lecteur du rapport ne verra pas l'étape de nettoyage. Il verra un graphique, un résumé ou une recommandation. Si le nettoyage est incorrect, la réponse finale peut sembler parfaite tout en étant fausse.

Un scénario concret d'export désordonné

Supposons qu'un analyste opérationnel reçoive un export texte SAP pour le chiffre d'affaires régional. Le fichier s'ouvre dans Excel, mais les premières lignes correspondent au titre du rapport et à l'heure de génération. Le délimiteur est un point-virgule. Une ligne de pied de page contient un sous-total. Les montants utilisent des virgules. Les dates apparaissent sous les formes 2026-05-01 et 05/01/26.

La méthode de traitement sécurisée est la suivante :

1. Enregistrer l'export brut sans modification.
2. Identifier la ligne d'en-tête réelle et le délimiteur avant toute analyse.
3. Isoler les titres, lignes vides, notes, sous-totaux et pieds de page dans une note "lignes exclues", de manière explicite.
4. Harmoniser les dates et les montants dans des formats cohérents.
5. Créer une table propre avec une ligne par transaction ou écriture.
6. Effectuer des vérifications (doublons d'ID, couverture des dates, réconciliation des totaux, champs non analysés).
7. Seulement après ces étapes, générer le tableau de bord, le résumé ou l'explication des écarts.

Ce flux de travail permet à l'analyste d'expliquer comment les données ont été nettoyées si quelqu'un remet en question le chiffre final plus tard.

Power Query aide lorsque la structure est stable

Power Query est souvent l'outil idéal lorsque le format d'export est prévisible.

Si le même système envoie la même mise en page de fichier chaque semaine, vous pouvez créer des étapes d'importation reproductibles : supprimer les premières lignes, promouvoir les en-têtes, modifier les types, fractionner les colonnes, filtrer les vides, ajouter des fichiers. Il suffit ensuite d'actualiser la requête le mois suivant.

Cela fonctionne bien tant que la source est constante.

Les problèmes commencent quand la source devient instable. Un client envoie un export légèrement différent. SAP ajoute une nouvelle ligne de note. Une banque modifie les colonnes de son CSV. Un fournisseur utilise un délimiteur différent. Quelqu'un copie le fichier dans un e-mail et l'encodage change.

À ce stade, le problème n'est plus seulement la transformation, c'est le diagnostic. L'utilisateur doit savoir ce qui a changé avant de faire confiance au résultat.

C'est là que les flux de travail assistés par l'IA peuvent aider, à condition qu'ils détaillent leur raisonnement.

Ce qu'un flux de nettoyage par IA devrait proposer

Un flux de travail IA efficace ne devrait pas passer directement du CSV brut à l'analyse finale.

Il doit d'abord inspecter le fichier, identifier les problèmes structurels, expliquer les hypothèses qu'il formule et demander une validation lorsqu'une décision peut affecter le résultat.

Un flux de travail pratique ressemble à ceci :

1. Télécharger l'export brut.
2. Demander au système d'inspecter la structure avant de l'analyser.
3. Réviser les en-têtes détectés, les lignes ignorées, les types de champs et les problèmes d'analyse.
4. Générer une table nettoyée.
5. Lancer des vérifications sur les doublons, les valeurs manquantes, les totaux et la période couverte.
6. Créer enfin le rapport, le résumé ou le tableau de bord.

Cet ordre est essentiel. La couche de nettoyage doit être traitée comme une partie intégrante de l'analyse, et non comme une étape préliminaire invisible.

Pour les fichiers clients, financiers ou opérationnels sensibles, évitez de télécharger des données personnelles ou confidentielles brutes sur un outil public, sauf approbation de votre organisation. Si votre équipe a besoin de limites de données plus strictes, évaluez une option de déploiement privé avant de standardiser le flux de travail.

De la table propre au rapport d'activité

Une fois que la table est fiable, la tâche de reporting devient beaucoup plus simple.

L'utilisateur peut poser des questions métier au lieu de lutter contre la structure du fichier.

Par exemple :

Inspecte cet export SAP. Identifie les lignes d'en-tête, les lignes de sous-totaux, 
les colonnes décalées et les champs avec des types mixtes. Crée une table propre 
pour l'analyse, puis résume le chiffre d'affaires par mois et signale toutes 
les lignes que tu as exclues.
Copy

Ou encore :

Normalise ces fichiers CSV bancaires en une seule table de transactions. 
Garde les fichiers bruts inchangés. Détaille les hypothèses débit-crédit, 
puis crée un résumé mensuel des flux de trésorerie en mettant en évidence 
les transactions inhabituelles.
Copy

Le résultat ne doit pas être seulement un graphique. Il doit inclure les hypothèses, les vérifications et les exceptions qui rendent le graphique vérifiable.

C'est aussi pourquoi un flux de travail "du tableur au rapport" est souvent plus utile qu'une approche "tableau de bord d'abord". Le rapport peut expliquer ce qui a changé, ce qui a été exclu, ce qui semble incertain et ce que le lecteur devrait examiner ensuite.

Pour les tâches récurrentes, cela s'inscrit naturellement dans un flux de reporting CSV mensuel, un flux Excel vers tableau de bord ou un processus plus large de reporting par IA. Si le travail se répète chaque mois, il peut devenir un flux de reporting récurrent sur tableur au lieu d'une opération de sauvetage ponctuelle.

La place de RowSpeak

RowSpeak est particulièrement utile dans cette phase pré-tableau de bord car le travail est interactif.

Vous pouvez télécharger un tableur, un CSV, un PDF ou un fichier d'entreprise exporté, puis poser des questions en langage naturel. Pour un export désordonné, la première question n'a pas besoin d'être "fais-moi un tableau de bord". Une meilleure question initiale est : "qu'est-ce qui ne va pas avec ce fichier ?"

À partir de là, RowSpeak aide à inspecter la structure, à nettoyer les données dans une table exploitable, à générer des résumés et à créer des rapports, tout en conservant une trace révisable de la conversation. Le but n'est pas de cacher le nettoyage, mais de le rendre assez rapide pour être effectué et assez visible pour être digne de confiance.

Cette distinction est capitale pour les équipes financières, opérationnelles et de reporting client. Elles n'ont pas seulement besoin de graphiques plus rapides ; elles ont besoin d'avoir la certitude que les données sous-jacentes ont été lues correctement.

La règle pratique

Ne commencez pas par le tableau de bord.

Commencez par l'export.

Si le fichier brut est mal structuré, votre premier livrable n'est pas un graphique. C'est une table propre et révisée avec des hypothèses documentées. Une fois cette base établie, le tableau de bord ou le rapport a une chance d'être crédible.

Essayez RowSpeak pour votre prochain export complexe : inspectez le fichier avant de faire votre rapport