Faire traverser toute l’architecture par un fichier CSV

Un portail de données doit rendre les ressources trouvables et compréhensibles sans dissocier publication et responsabilité. CKAN organise les producteurs en organisations, décrit les jeux par des métadonnées et relie chaque ressource à une page stable. Le travail éditorial porte autant sur les titres, formats, licences et fréquences de mise à jour que sur le serveur.

Une ressource tabulaire peut être chargée dans le DataStore par DataPusher. PostgreSQL conserve alors une représentation interrogeable, tandis que Solr indexe les métadonnées pour la recherche. Ces deux fonctions doivent être testées séparément : un fichier téléchargeable n’implique pas un aperçu tabulaire réussi, et un jeu enregistré n’implique pas qu’il soit déjà visible dans les résultats.

L’acceptation a créé une organisation et un jeu de données, importé un CSV de 1 193 lignes, ouvert l’aperçu, interrogé l’API, recherché le contenu et suivi le worker. Après redéploiement, le même jeu et ses données restaient disponibles. Ce parcours relie interface, DataPusher, files Redis, worker, PostgreSQL, DataStore et index Solr.

Chaque jeu reçoit un propriétaire, une licence, une fréquence et une règle d’archivage. Les données individuelles ou sensibles ne sont pas publiées par défaut : elles sont agrégées ou restent dans un espace contrôlé. L’API facilite la réutilisation, mais elle doit exposer les mêmes définitions et mises à jour que l’interface afin d’éviter deux versions du catalogue.

La supervision observe l’application, le worker, DataPusher, la croissance du FileStore, le DataStore et l’index. Une alerte de recherche ne conduit pas à réinitialiser PostgreSQL ; une erreur d’import commence par la tâche et le format reçu. La sauvegarde protège métadonnées, DataStore et fichiers, puis la restauration se termine par une recherche et un aperçu.

L’ingénierie et l’éditorial se rejoignent dans le même contrat : une ressource décrite, accessible, importable, interrogeable et maintenue. La page Solution présente CKAN, le Déploiement explique sa topologie, le Compose permet de la reproduire et cette étude montre le parcours qui transforme un fichier en ressource publique réutilisable.

Avant l’ouverture du portail, l’équipe définit les champs obligatoires, les vocabulaires, les formats et les responsabilités de validation. Un titre lisible, une description du périmètre, une période, une licence et un contact de maintenance rendent une ressource compréhensible hors de son projet d’origine. Les identifiants et slugs restent stables afin que les intégrations et citations survivent aux révisions éditoriales.

CKAN possède un vaste écosystème d’extensions. Chacune ajoute pourtant du code, des migrations, une compatibilité de version et une responsabilité de maintenance. Le profil commence avec les fonctions nécessaires au parcours public, puis introduit une extension dans un environnement isolé. L’acceptation vérifie l’interface, l’API, les tâches et les index avant de promouvoir la nouvelle composition.

Le plan de reprise associe un export de PostgreSQL, les données du DataStore, le FileStore et la configuration des extensions. Solr peut être reconstruit à partir des données autoritatives, mais le temps de réindexation entre dans le délai de retour au service. Une restauration réussie retrouve le jeu témoin, son fichier, son aperçu, son résultat de recherche et sa réponse API.

Un portail cesse d’être utile lorsque les utilisateurs ne savent plus si les ressources sont actuelles. Les tableaux de suivi portent donc sur les jeux à réviser, les erreurs d’import, les liens rompus et les requêtes sans résultat. Ces observations servent à corriger les métadonnées, accompagner les producteurs et prioriser les améliorations qui rendent les données plus faciles à trouver et à réutiliser.

Les comptes d’administration sont nominatifs et les clés API attribuées à un usage précis. PostgreSQL, Solr, Redis et DataPusher restent sur le réseau interne. Les journaux évitent d’enregistrer les contenus sensibles ou les jetons. Les mises à jour d’extensions sont traitées comme du code applicatif : revue, environnement d’essai, sauvegarde, migration et parcours d’acceptation avant promotion.

Lorsqu’un CSV échoue, le diagnostic commence par son encodage, ses en-têtes, ses types et la réponse de DataPusher. Il vérifie ensuite la file et le worker avant d’examiner le DataStore. Cette progression conserve le fichier d’origine et produit un message exploitable pour le producteur. Une correction de données est documentée et une nouvelle ressource est importée sans modifier silencieusement le jeu déjà publié.

La capacité dépend moins du nombre brut de jeux que du volume des ressources, de la fréquence des imports, de l’indexation et de l’usage API. Les métriques suivent temps de réponse, files, erreurs DataPusher, connexions PostgreSQL, taille du FileStore et durée de réindexation. Ces mesures permettent d’ajuster workers, stockage ou maintenance sur des besoins observés plutôt que sur une architecture spéculative.

Les consommateurs doivent disposer d’URL stables, de formats décrits et d’une manière de détecter les mises à jour. L’API CKAN facilite l’automatisation, tandis que la page du jeu apporte le contexte humain. Un catalogue évite la duplication lorsqu’il désigne clairement la ressource autoritative et maintient ses liens ; il ne devient pas une seconde base métier chargée de corriger les systèmes producteurs.

Le portail est considéré utilisable lorsque les producteurs peuvent publier selon le circuit convenu et que les lecteurs trouvent, comprennent, téléchargent ou interrogent une ressource sans assistance technique. Les critères couvrent aussi la fraîcheur des métadonnées, la disponibilité de l’API, le délai d’import et la capacité de reprise. Ils sont revus avec les responsables de données, car une plateforme techniquement saine peut rester inefficace si les responsabilités éditoriales ne sont pas tenues.