CKAN

CKAN est une solution de catalogue et portail de données ouvertes. Elle propose des organisations, jeux de données, ressources, métadonnées, recherche, API et extensions. Son code ouvert permet de l’installer sur une infrastructure choisie, d’étudier son fonctionnement et de l’intégrer à d’autres outils.

Les organisations utilisent ce type de solution pour catalogues publics, bibliothèques de jeux de données, portails thématiques et diffusion de ressources tabulaires. L’enjeu n’est pas seulement de remplacer un fichier ou une application : il s’agit de clarifier qui crée l’information, qui peut la modifier, comment elle circule et à quel moment elle devient utile à une décision.

CKAN sépare la description d’un jeu de données, son fichier, son indexation et son exploitation par API. Cette structure facilite la découverte, la mise à jour et la réutilisation des données par des publics différents.

Des organisations, jeux de données, ressources, métadonnées, recherche, api et extensions. Une mise en œuvre commence par un périmètre métier précis, un vocabulaire partagé et des rôles d’accès. Les fonctions techniques prennent alors place dans un processus compréhensible par les utilisateurs, les administrateurs et les responsables des données.

L’architecture réunit l’application CKAN, PostgreSQL pour les métadonnées et le DataStore, Solr pour la recherche, Redis pour les tâches, un worker et DataPusher pour l’import tabulaire. Chaque composant répond à une responsabilité distincte : interface, logique métier, traitement différé, recherche ou état durable. Cette séparation guide la supervision, les mises à jour et la sauvegarde.

Les programmes de développement travaillent avec des équipes distribuées, des processus qui évoluent et des données parfois sensibles. Une solution ouverte offre davantage de choix sur l’hébergement, l’intégration et la durée de conservation. Elle exige en retour des responsabilités explicites pour l’administration, la sécurité, les sauvegardes, l’assistance aux utilisateurs et l’évolution fonctionnelle. CKAN répond à un besoin de catalogue : décrire des jeux de données, publier des ressources, organiser les responsabilités entre producteurs et administrateurs, et rendre l’ensemble découvrable par recherche et API.

Le choix doit partir du besoin : nombre d’utilisateurs, connectivité, volume, sensibilité des informations, fréquence des changements et compétences disponibles. Un pilote limité aide à valider le vocabulaire, les droits et les parcours avant une généralisation. Un portail utile commence donc par un schéma de métadonnées, une politique de publication et un circuit de mise à jour, avant le choix des extensions ou de l’habillage.

Un service géré réduit la charge d’exploitation. Un hébergement autonome donne davantage de contrôle sur la localisation des données, le réseau et les intégrations. Entre les deux, une plateforme comme Coolify simplifie le déploiement Docker tout en laissant à l’organisation la responsabilité du serveur, des secrets, de la supervision et de la reprise. La composition associe l’application CKAN, un worker RQ, DataPusher, PostgreSQL pour les métadonnées et le DataStore, Solr pour l’index et Redis pour les tâches.

Le profil retenu doit respecter l’architecture du logiciel. Une installation compacte peut convenir à un usage limité ; une topologie séparant application, travailleurs et stockage facilite l’évolution lorsque les charges et les responsabilités augmentent. Le stockage de fichiers complète cet ensemble.

Avant l’ouverture aux utilisateurs, il faut définir les propriétaires fonctionnels et techniques, les catégories de données, les règles d’accès, la durée de conservation et la procédure de départ d’un collaborateur. Les sauvegardes doivent couvrir tous les états autoritatifs et leur restauration doit être exercée. Le domaine public reste attaché à CKAN ; DataPusher et les magasins d’état utilisent le réseau interne et ne doivent pas recevoir de route publique.

Le Digital Lab publie un déploiement Coolify versionné, un modèle Docker Compose téléchargeable, des guides d’exploitation et une étude de cas technique. Ensemble, ces ressources permettent de comprendre la solution, de reproduire l’architecture et d’adapter les contrôles au contexte de l’organisation. La validation ne s’est pas arrêtée à la page d’accueil.

Une adoption réussie commence par un petit nombre de parcours prioritaires. L’équipe décrit les rôles, construit un jeu d’essai, teste les imports et exports, puis observe le temps nécessaire aux utilisateurs. Les retours servent à simplifier les formulaires, les catégories et les règles d’accès avant l’ouverture à un groupe plus large. Elle a créé une organisation et un jeu de données, importé un CSV de 1 193 lignes, ouvert l’aperçu DataStore, interrogé l’API, vérifié la recherche et observé le worker après redéploiement.

La formation doit couvrir les gestes courants, mais aussi les situations d’erreur : doublon, donnée mal classée, accès perdu, import incorrect ou synchronisation interrompue. Les administrateurs disposent ainsi d’une procédure d’assistance et les utilisateurs savent comment signaler un problème sans créer de nouveaux risques. Cette chaîne a permis de distinguer l’état sain de PostgreSQL de l’initialisation réelle du DataStore et de l’index Solr.

L’API, les exports et les connecteurs permettent d’inscrire la solution dans un système plus large. Chaque échange doit préciser l’identifiant utilisé, la fréquence, le sens de circulation, les contrôles et la conduite à tenir en cas d’échec. Cette carte évite les doubles saisies et les synchronisations silencieuses. Le Compose doit être relu avec trois contrats en tête : le fichier de configuration CKAN monté comme fichier, les URL internes utilisées par DataPusher et les tâches, et le hook d’initialisation réellement exécuté par l’image.

La continuité inclut la documentation des configurations, la disponibilité des compétences, la gestion des comptes et la possibilité d’extraire les informations dans un format exploitable. Ces dispositions facilitent également une migration future. Les signes dollar placés dans un contenu géré ne suivent pas les mêmes règles que ceux d’une commande Compose ; les échapper mécaniquement peut rendre la configuration invalide.

CKAN répond à un besoin de catalogue : décrire des jeux de données, publier des ressources, organiser les responsabilités entre producteurs et administrateurs, et rendre l’ensemble découvrable par recherche et API. Un portail utile commence donc par un schéma de métadonnées, une politique de publication et un circuit de mise à jour, avant le choix des extensions ou de l’habillage.