Les fichiers CSV sont censés être simples. C'est l'un des moyens les plus courants d'intégrer des données dans un logiciel, ils existent depuis des décennies, et la plupart des développeurs ont appris à les parser dès leur première année. Et pourtant, les imports CSV échouent constamment. La raison n'est pas celle que la plupart des équipes imaginent.
L'hypothèse de départ : « c'est juste un CSV »
Quand une équipe produit décide de supporter les imports CSV, le périmètre semble modeste. C'est un format standard. Il est largement utilisé. Ce ne sont que des lignes et des colonnes. Qu'est-ce qui peut être si compliqué ?
Cette hypothèse est la raison pour laquelle tant d'équipes sous-estiment le travail. Le parsing technique est facile. Le problème n'est pas le parsing.
Le format n'est pas le problème
Le CSV est d'une simplicité triviale en tant que spécification. Quelques lignes de code suffisent pour lire n'importe quel fichier CSV bien formé. La difficulté commence dès que vous rencontrez de vrais fichiers provenant de vraies sources.
Aucun fichier CSV dans la réalité n'est exactement identique à un autre. Le même champ apparaît comme « Email » dans un fichier et « email_address » dans un autre. Les colonnes arrivent dans des ordres différents. Certains fichiers incluent des champs optionnels, d'autres les omettent. Certains utilisent des virgules comme délimiteur, d'autres des points-virgules ou des tabulations. Certains sont encodés en UTF-8, d'autres en Windows-1252. Les valeurs sont formatées de manière incohérente, les dates en particulier. Prises individuellement, chacune de ces différences est mineure. Ensemble, elles rendent un parser CSV générique inutilisable pour tout ce qui dépasse les exemples jouets.
| Name | Phone | |
|---|---|---|
| ana@acme.io | Ana Ortiz | +1 415 555 0102 |
| sam@hooli.co | Sam Lee | +1 415 555 0188 |
| raj@initech.com | Raj Patel | +1 415 555 0144 |
| email_address | client_name | phone_number |
|---|---|---|
| ana@acme.io | Ortiz, Ana | 4155550102 |
| sam@hooli.co | Lee, Sam | 4155550188 |
| raj@initech.com | Patel, Raj | 4155550144 |
| ; Full name | ; Mobile | |
|---|---|---|
| ana@acme.io | Ana Ortiz | 415-555-0102 |
| sam@hooli.co | Sam Lee | 415-555-0188 |
| raj@initech.com | Raj Patel | 415-555-0144 |
| NAME | TEL | |
|---|---|---|
| ANA@ACME.IO | ORTIZ ANA | 0014155550102 |
| SAM@HOOLI.CO | LEE SAM | 0014155550188 |
| RAJ@INITECH.COM | PATEL RAJ | 0014155550144 |
Chaque CSV reflète un système différent
Un fichier CSV n'est pas qu'un fichier. C'est un export d'un autre système, généralement un CRM, un ERP, un tableur, ou un outil historique. Chacun de ces systèmes a sa propre structure de données, ses propres conventions de nommage, et ses propres hypothèses sur ce à quoi un champ devrait ressembler.
Quand votre client exporte des données clients depuis son CRM, la forme de cet export est déterminée par le CRM, pas par votre système. Quand il exporte des données de commandes depuis son ERP, cela reflète la façon dont son ERP conçoit les commandes. Vous ne recevez pas un CSV générique. Vous recevez la sortie du système de quelqu'un d'autre, formatée selon ses conventions, pas les vôtres.
Pourquoi les imports commencent à échouer à l'échelle
Au début, une fonctionnalité d'import CSV semble fonctionner. Quelques clients chargent des fichiers, des problèmes remontent, vous les corrigez manuellement, l'équipe s'adapte.
À mesure que vous grandissez, les chiffres se retournent contre vous. Plus de clients signifie plus de variations. Plus de variations signifie plus de cas particuliers. Plus de cas particuliers signifie plus d'interventions manuelles. L'équipe qui gérait confortablement trois imports par semaine en gère maintenant cinquante, et prend du retard. L'onboarding ralentit. Les demandes de support augmentent. Les développeurs sont mobilisés pour débugger des fichiers qui auraient dû être triviaux.
À un certain point, la fonctionnalité qui semblait simple au lancement devient une source continue de friction.
Les solutions habituelles, et pourquoi elles ne tiennent pas
Les équipes essaient généralement trois solutions, dans l'ordre, et chacune rencontre ses propres limites.
La première solution est d'imposer un template. Vous publiez un modèle CSV, vous demandez aux utilisateurs de le suivre, et vous rejetez les fichiers qui ne correspondent pas. En pratique, les utilisateurs modifient le template, omettent les champs optionnels, introduisent une dérive de formatage au fil du temps, ou ne peuvent tout simplement pas produire le format exact parce que leur système source ne l'exporte pas de cette manière. Imposer un template crée de la friction sans résoudre le problème sous-jacent.
La deuxième solution est le nettoyage manuel. L'équipe ouvre chaque fichier, l'examine, corrige les problèmes, et importe la version nettoyée. Cela fonctionne à petite échelle mais ne passe pas à l'échelle. C'est lent, cela introduit des erreurs humaines, et cela monopolise des membres de l'équipe sur du travail répétitif.
La troisième solution est la logique de parsing personnalisée. Les développeurs écrivent du code pour gérer les variations courantes. Cela fonctionne mieux que les deux précédentes, mais chaque nouveau cas particulier nécessite des modifications de code. Avec le temps, la logique de parsing accumule des branches, des cas spéciaux et des exceptions. Ce qui commençait par quelques centaines de lignes devient un petit produit interne qui nécessite une maintenance continue.
Le vrai problème : la variation des formats
Les imports CSV n'échouent pas parce que le CSV est défaillant. Ils échouent parce que les mêmes données arrivent structurées différemment à chaque fois. Même quand toutes les parties impliquées essaient de suivre les règles. C'est ce qu'on appelle la multiplication des formats, et c'est la cause sous-jacente de presque tous les problèmes d'import CSV que vous rencontrerez.
Une fois que vous voyez les choses ainsi, la nature de la solution change. La réponse n'est pas un meilleur parser ou un template plus strict. La réponse est un système qui accepte la variation comme la norme et s'y adapte automatiquement.
La meilleure approche
Au lieu de forcer les utilisateurs à correspondre exactement à votre format, acceptez la variation à la source. Laissez les CSV entrants avoir des noms de colonnes différents, des ordres différents, des délimiteurs différents, des encodages différents. Interprétez la structure automatiquement. Mappez les champs vers votre format attendu en vous basant sur des patterns et le contexte, pas sur des correspondances exactes. Transformez les valeurs de manière cohérente, quel que soit leur formatage d'origine.
C'est ce que les systèmes d'import de données sont conçus pour faire. Les CSV qui faisaient échouer les imports deviennent des entrées de routine, parce que le système est construit autour de l'hypothèse que la variation existe.