Le besoin de traiter et échanger des données entre divers système est plus que courant, en particulier quand on se spécialise dans l'intégration de solutions. Il y a presque toujours à la base d'un projet un ou deux fichiers de données à charger, soit en guise de paramètres initiaux ou régulièrement pour importer/exporter des données live depuis/vers un autre système.
La plupart du temps le format d'échange est le bon vieux CSV, et on n'a pas à s'occuper trop du format de ces données, qui est fixé au départ du projet et n'a pas vocation à évoluer. Ce besoin étant omniprésent, il est normal qu'un certain nombre de solutions existantes permettent de considérer un fichier CSV comme n'importe quelle base de données. Mais il n'est pas rare que certains fichiers aient un format un peu plus exotique, et nécessitent des ajustements.
Au fil des projets, le composant qui est chargé de transcoder un fichier CSV pour en faire une base de données "en mémoire" du point de vue de l'application, s'est étoffée de paramètres et fonctionnalités de nettoyage/transtypage simples et efficaces.
Et un jour un projet atypique pointe son nez, en l'apparence au début assez classique, car il s'agit essentiellement de transcoder des données texte, XML et base de données. La solution exigée par le client doit être simple d'utilisation, il n'est donc pas question d'utiliser un outil ETL lourd à configurer et utiliser. D'ailleurs à l'époque ce type de solutions n'était pas encore très répandu.

Je décide donc, plutôt que de faire une application très spécifique qui réponde uniquement au besoin du client, de continuer dans la voie du transcodage Fichier(s) <=> BD en mémoire, traitements inter-source avec les tables "uniformisées", et hautement configurable pour pouvoir modifier la solution sans avoir à repasser par la case recompilation. Cette approche a été payante dès le premier projet, car le client (et la société de service qui m'a sous-traité la réalisation) n'avait pas bien fait son travail de spécifications et est revenu sur les formats d'échanges plusieurs fois avant la stabilisation du projet (qui a eu lieu bien après que mon outil soit fini).
Le fait d'avoir ma propre solution d'ETL simple à utiliser et efficace, m'a permis de répondre à une demande d'un autre client, la SNCF, qui était en peine sur la mise en conformité de ses trajets régionaux (les trains n'avaient plus le droit de dépasser des quais dans aucune des gares où ils s'arrêtent). J'ai repris la base du projet précédent, ajouté les fonctionnalités manquantes, et repackagé dans une application spécifique. Pour ce projet, les données à croiser étaient nettement plus lourdes, et plus complexes d'un point de vue conceptuel, c'était donc une très bonne chose de n'avoir finalement pas trop à me soucier du format, et pouvoir me concentrer sur les traitements.