Transparence & souveraineté des données

Museo est développé et hébergé par Wilder Labs. La chaîne complète :

Aucun autre sous-traitant au sens RGPD (traitement de données pour notre compte) : pas de CDN tiers pour les données, pas d'analytics externe, pas de tag marketing sur les portails. Distinct des sources externes interrogées ponctuellement par le module Témoins (Wikidata, Steve Morse — question 3) : ce sont des recherches que vous déclenchez vous-même vers des bases publiques tierces, pas des sous-traitants qui traitent vos données pour notre compte.

OVHcloud : société française, datacenters en France (Roubaix / Gravelines / Strasbourg). C'est là que vivent la base de données, les fichiers, les photos et les sauvegardes.

Google LLC, Stripe Inc./Stripe Payments Europe (Dublin) et Cloudflare Inc. sont des sociétés américaines ou de droit irlandais pour la filiale européenne. HelloAsso est une société française.

Le socle — base de données, photos, documents, sauvegardes, journaux applicatifs — reste en France chez OVH, sans réplication hors UE.

Quatre flux sortent, tous optionnels et tous activés à votre demande :

• OCR : si vous utilisez le module de lecture automatique de registres, les images de vos registres et le texte extrait sont envoyés à Google (Cloud Vision puis Gemini) aux États-Unis. C'est le seul flux qui expose du contenu documentaire.
• Paiements : si vous activez la billetterie/boutique/dons par Stripe, les données de transaction et l'email de l'acheteur transitent par Stripe. HelloAsso (France) évite ce transfert.
• Connexion Google Sign-In : si vous l'activez pour vos comptes utilisateurs, Google apprend qu'une personne se connecte à Museo et nous transmet son email vérifié (question 6). Désactivé par défaut.
• Assistant de recherche multi-sources (module Témoins) : si vous l'utilisez pour rechercher une personne, la requête (nom, dates) part vers 6 sources externes ; 4 sont en France ou UE (Mémorial de la Shoah, AJPN, Mémorial GenWeb, Arolsen Archives — Allemagne), mais 2 sont hébergées aux États-Unis : Wikidata (Wikimedia Foundation) et Steve Morse. Ce flux ne concerne que les recherches ponctuelles que vous lancez, jamais un envoi automatique de votre base.

Museo peut tourner avec ces quatre flux coupés — voir question 5. Pour le module Témoins spécifiquement, Wikidata et Steve Morse sont décochés par défaut dans l'interface de recherche — c'est l'utilisateur qui doit les inclure explicitement pour une recherche donnée, jamais l'inverse.

Google (OCR, et si activés : avis Places, connexion Google), Stripe pour la partie américaine du groupe, Cloudflare pour le DNS. Aucun autre. Pas d'AWS, pas d'Azure, pas de Microsoft, pas d'OpenAI, pas d'Anthropic dans le produit livré.

Oui. En configuration « souveraine », vous perdez uniquement l'OCR automatique des registres (la saisie manuelle et l'import Excel restent disponibles), les avis Google sur le site public et la connexion par compte Google.

Tout le reste — inventaire, récolement, prêts, constats d'état, expositions, portail public, exports Joconde/LIDO/CIDOC, billetterie via HelloAsso, dons — fonctionne intégralement sans aucun service américain.

Concrètement : ne pas renseigner les clés Google dans les paramètres et choisir HelloAsso pour l'encaissement. Nous pouvons livrer votre instance dans cette configuration par défaut et l'écrire au contrat.

Oui : Google apprend que la personne se connecte à Museo, et nous recevons de Google son email vérifié et un identifiant unique. C'est pour cette raison que la connexion Google est désactivée par défaut.

Les méthodes recommandées sont le mot de passe avec double authentification, au choix : application d'authentification (TOTP), code par email, ou clé/empreinte (passkey WebAuthn). Aucune ne fait sortir de donnée.

Trois cadences, selon la nature de la donnée :

• Base de données — tous les jours à 2 h. Sauvegarde PostgreSQL complète du schéma du musée, compressée, avec contrôle de taille : un fichier anormalement petit (échec d'authentification, sortie corrompue) est rejeté et déclenche une alerte plutôt que d'écraser une bonne sauvegarde.
• Documents et pièces jointes — tous les jours, dans la même passe.
• Photographies (stockage objet) — tous les 7 jours, cadence découplée volontairement : ce volume évolue lentement et une copie complète quotidienne produisait des doublons sans gagner de point de restauration utile.

S'y ajoute, toutes les 6 heures, un second mécanisme de sauvegarde au niveau de la plateforme : un dump complet de la base de données (question 23) et de la configuration système (certificats, réseau) — et un export en autonomie depuis vos paramètres, à tout moment.

Soit 30 points de restauration quotidiens sur le mois écoulé pour la base, et 90 jours de profondeur pour les photographies.

S'y ajoute une archive mensuelle conservée 12 mois, exclue de la rotation courte : une anomalie détectée tardivement reste rattrapable jusqu'à un an en arrière. Un mécanisme dédié (question 49) retire un tenant résilié de ces archives passées, pour que la purge sous 90 jours reste vraie même avec cette profondeur d'archive.

Oui, sur deux niveaux successifs.

• Niveau 1 — relais externalisé : les sauvegardes chiffrées quittent le serveur de production chaque nuit vers un second serveur distinct.
• Niveau 2 — stockage d'archivage : elles sont ensuite recopiées sur un matériel de stockage entièrement séparé, qui n'est ni le serveur de production ni le relais, et qui constitue le magasin de référence.

La politique est explicite : le serveur de production est considéré comme éphémère, le stockage d'archivage est la source de vérité. Les fichiers volumineux (photographies) sont même retirés de la production une fois leur copie confirmée sur l'archivage.

Oui. Le serveur de production et le relais externalisé sont deux machines distinctes ; le stockage d'archivage final est sur un site physique différent des deux. La destruction du datacenter de production ne fait perdre aucune sauvegarde.

Oui. Les sauvegardes de base de données sont chiffrées en GPG avant de quitter le serveur de production. Elles transitent chiffrées et sont stockées chiffrées sur l'archivage — les fichiers y portent l'extension .gpg.

Mieux : le contrôle automatique nocturne ne se contente pas de vérifier la présence du fichier, il teste le déchiffrement. Une sauvegarde chiffrée mais illisible serait détectée le lendemain matin, pas le jour de l'incident.

Par ailleurs : secrets applicatifs chiffrés en base en AES-256-GCM, et toutes les communications en TLS.

Les photographies et pièces jointes sont chiffrées selon le même procédé (GPG, vérification du déchiffrement avant suppression du clair) et transitent chiffrées vers le stockage externalisé.

Wilder Labs détient la clé GPG des sauvegardes et la clé de chiffrement des secrets applicatifs. C'est la règle en service hébergé : l'exploitant doit pouvoir restaurer sans vous solliciter en pleine nuit.

Les clés ne sont jamais dans le code source ni dans un dépôt versionné ; elles vivent uniquement dans la configuration des serveurs.

Les données ne sont pas perdues : la sauvegarde de la veille est chiffrée et présente sur deux infrastructures distinctes du serveur détruit. La reprise consiste à reconstruire l'application (déploiement automatisé) puis à restaurer la base, les photographies et les documents.

La procédure de restauration est écrite, versionnée et testée — elle n'est pas improvisée le jour de l'incident. Des exercices de restauration automatiques tournent chaque semaine sur la plateforme pour vérifier qu'une sauvegarde se remonte réellement.

Pour une indisponibilité temporaire (panne réseau, incident OVH), le service revient sans aucune perte au rétablissement.

RPO (perte maximale de données) : 24 heures pour l'inventaire et les documents, correspondant à la sauvegarde quotidienne dédiée à votre musée. Jusqu'à 7 jours pour les photographies, qui suivent une cadence hebdomadaire. Contractuel (CGV, article 5.8).

RTO (délai de remise en service) : 4 heures visées, sur la plage 9h-18h du lundi au vendredi, hors jours fériés, pour une reprise complète après un incident majeur — engagement de moyens contractuel (CGV, article 5.8), la nature de l'incident n'étant pas connue à l'avance. À distinguer du délai de prise en charge (diagnostic, début de traitement), lui aussi contractuel et ferme (CGV, article 5.3, « 4 heures ouvrées » pour une panne bloquante) : aucun éditeur ne peut engager un délai de résolution ferme sur une cause inconnue à l'avance (CGV, article 5.4).

En complément de la sauvegarde quotidienne, un second mécanisme au niveau de la plateforme dumpe l'ensemble de la base toutes les 6 heures — un filet de sécurité supplémentaire qui réduit en pratique la perte possible bien en-deçà des 24 heures.

Des audits de sécurité internes, complets et documentés : oui. Un pentest par un cabinet tiers indépendant : non, pas à ce jour. Nous restons ouverts à ce qu'un musée mandate et finance un test d'intrusion par un prestataire indépendant de son choix, avant ou après la mise en service — nous nous engageons alors à en recevoir et traiter les conclusions dans les mêmes délais que nos propres audits (question 29), et à en partager une synthèse écrite.

À cela s'ajoute un audit automatisé hebdomadaire, sur deux périmètres complémentaires : le code de chaque application (dépendances vulnérables, secrets, configuration des conteneurs) le dimanche, et l'infrastructure en exécution le lundi — certificats TLS, en-têtes de sécurité réellement servis, vulnérabilités des images déployées, privilèges des conteneurs, ports ouverts, correctifs système en attente.

Chaque rapport est conservé 12 mois : l'historique de conformité est donc consultable, et non pas affirmé.

Les audits internes couvrent authentification et sessions, injection SQL, XSS, CSRF, isolation multi-tenant, gestion des secrets, webhooks, téléversements de fichiers, en-têtes de sécurité, limitation de débit, fuites de données personnelles.

Trois campagnes à ce jour, la plus récente le 1er septembre 2026. Sur cette dernière : 22 constats, dont les bloquants, critiques et majeurs corrigés et vérifiés en production le jour même. Quelques constats mineurs restent ouverts, sans urgence. L'isolation multi-tenant décrite question 35 est l'état actuel, déjà vérifié sur ces trois campagnes.

Réalisés en interne par Wilder Labs, sur 6 puis 8 axes (sécurité, base de données, performance, architecture, UI/UX, CI-CD, RGPD, conformité), avec vérification contradictoire de chaque constat avant correction.

Oui, sous accord de confidentialité : une synthèse écrite (nombre de constats par famille, taux de correction, délais de traitement), pas les rapports bruts. Les rapports détaillés décrivent des vulnérabilités précises, corrigées ou non — les transmettre tels quels serait une mauvaise pratique de sécurité, même envers un client de confiance.

En pratique oui, formalisée partiellement : analyse des dépendances à chaque construction d'image, correction des vulnérabilités remontées, campagnes d'audit périodiques, journalisation des correctifs dans l'historique du code.

Exemple concret : une mise à jour de la bibliothèque de téléversement a éliminé 7 vulnérabilités classées élevées.

Le cycle est cadencé : détection automatique hebdomadaire (les deux audits ci-dessus), qualification, correction selon les délais engagés à la question 29, et trace écrite du correctif dans l'historique du code.

Cette procédure est formalisée dans un document communicable, incluant une politique de divulgation responsable, avec un point de contact unique : contact@wilderlabs.fr.

En pratique : dans la journée pour un correctif critique, la chaîne de déploiement étant automatisée (moins de 5 secondes d'interruption).

Engagement retenu : correctif critique sous 48 h, élevé sous 7 jours, moyen sous 30 jours (jours ouvrés). Aligné sur la pratique constatée — un correctif de vulnérabilité élevée a déjà été déployé le jour même.

L'obligation légale est claire : notification à la CNIL sous 72 h et information des personnes concernées si le risque est élevé (RGPD art. 33-34).

Oui, procédure écrite : détection, qualification de la gravité selon la grille du Comité européen de la protection des données, confinement, information du musée sous 24 heures, notification à la CNIL sous 72 heures (décision qui vous revient en tant que responsable de traitement, avec notre assistance), information des personnes concernées si le risque est élevé, tenue d'un registre des violations. Un modèle de notification prêt à l'emploi est joint.

Oui, et il faut le dire franchement : l'exploitant d'un service hébergé a nécessairement un accès technique. Concrètement il existe un mode d'assistance qui permet à un administrateur Wilder Labs d'ouvrir une session dans votre espace pour diagnostiquer un incident.

Ce mode est encadré : jeton signé cryptographiquement, valable 5 minutes, utilisable une seule fois, limité à 5 tentatives par minute, et l'accès est tracé.

Techniquement, oui — comme tout hébergeur. Nous nous engageons à n'y accéder que pour l'exploitation du service ou sur votre demande d'assistance.

Pour être précis sur ce que cela permet : une session d'assistance peut être ouverte par un administrateur Wilder Labs sans validation préalable explicite de votre part (c'est un mécanisme d'urgence, pensé pour ne pas dépendre de votre disponibilité en pleine nuit) — mais jamais sans laisser de trace : chaque accès est journalisé, daté, tracé à l'intervenant, dans votre propre piste d'audit consultable par vous à tout moment.

L'ensemble de ces garanties techniques (isolation, journalisation, chiffrement, sauvegardes) vient en appui direct de l'accord de sous-traitance RGPD (DPA, question 79) — ce sont les moyens par lesquels Wilder Labs tient ses engagements de sous-traitant, pas un sujet distinct.

Chacun de nos accès est inscrit dans votre propre piste d'audit — la même table que celle qui trace les modifications de vos fiches. Vous y voyez la date, l'heure, l'intervenant, l'adresse IP et le motif. Nos accès sont donc consultables par vous, au même endroit que ceux de vos utilisateurs, sans nous le demander.

Chaque musée dispose de son propre schéma de base de données — un espace nommé distinct qui contient ses ~62 tables (objets, photos, prêts, contacts, récolements…). Une requête émise dans le contexte d'un musée ne s'exécute que dans son schéma ; le contexte est fixé par la session authentifiée, jamais par un paramètre d'URL.

Les fichiers et photos sont séparés de la même façon dans le stockage objet.

Séparation par schéma dans une instance PostgreSQL mutualisée. C'est une isolation logique forte — pas un simple filtre par colonne « identifiant client », qui est le modèle le plus courant et le plus fragile.

Un musée qui exige une base ou un serveur physiquement dédié : c'est réalisable en offre sur mesure, avec un surcoût d'hébergement.

• Le schéma est déterminé par la session serveur, jamais par une valeur envoyée par le navigateur.
• Le nom de schéma est validé par une expression stricte avant toute utilisation, ce qui bloque l'injection de schéma.
• Les requêtes sont paramétrées (protection contre l'injection SQL).
• Le compte de base de données de l'application n'est pas superutilisateur et ne peut pas contourner les politiques de sécurité au niveau des lignes.
• La sécurité au niveau des lignes (RLS) de PostgreSQL est activée sur la quasi-totalité des tables — une seule exception connue (la table des comptes Stripe Connect), le code qui l'interroge ne posant pas encore le contexte tenant ; son isolation repose aujourd'hui sur la seule couche applicative (schéma). Reprise prévue.
• Une politique restrictive de sécurité au niveau des lignes (Row-Level Security PostgreSQL) est active sur les 4 espaces musée en production : le moteur de base de données lui-même refuse toute ligne hors du musée courant, y compris pour le compte technique propriétaire des tables (contrainte « FORCE »). Ce n'est plus seulement l'application qui isole les musées entre eux — le moteur de base de données le fait aussi, en dernier recours.

Autrement dit, deux couches indépendantes protègent l'isolation : la couche applicative (schéma déterminé par la session, jamais par une valeur externe) et le moteur de base de données (politique restrictive au niveau des lignes). Une faille dans l'une ne suffit pas à exposer les données d'un autre musée si l'autre tient.

Oui, sur les deux couches indépendantes qui protègent l'isolation. Une série de tests automatisés, exécutée à chaque modification du code, crée deux musées de test et vérifie :

• Couche applicative : lecture croisée, requêtes simultanées, absence de résidu de contexte entre deux requêtes successives, rejet de huit tentatives d'injection de nom de schéma.
• Couche moteur de base de données : la politique de sécurité au niveau des lignes est testée directement, indépendamment du code applicatif — lecture bloquée sans le bon identifiant de musée, lecture bloquée si l'identifiant pointe vers un autre musée, écriture rejetée avec une erreur explicite plutôt que silencieusement perdue, confirmation qu'avec le bon identifiant les données réelles sont bien accessibles, et lecture bloquée sur une requête visant explicitement un autre espace musée par son nom, même avec un contexte par ailleurs valide.

Résultat : aucune fuite constatée sur les deux couches pour les tables couvertes par la seconde couche (question 35 : une table encore en cours de reprise n'a que la couche applicative). Une faille dans l'une ne suffit pas à exposer les données d'un autre musée si l'autre tient — ce qui est vérifié, pas seulement affirmé.

L'audit hebdomadaire d'infrastructure vérifie en complément que les ports des bases de données ne sont pas exposés publiquement, ce qui couvre la voie d'accès la plus directe hors application.

Le musée, sans réserve. Wilder Labs n'est qu'hébergeur et sous-traitant : nous détenons les données pour votre compte, nous n'en acquérons aucun droit.

Vous. Nous n'obtenons aucune licence d'exploitation, ni de réutilisation, ni de communication à des tiers. Museo gère d'ailleurs un indicateur de droits par photographie, qui permet d'autoriser ou non sa diffusion sur le portail public.

Vous, dans les mêmes termes qu'à la question 38.

Non. Aucune exploitation commerciale, aucune revente, aucun entraînement de modèle d'IA sur vos données, aucune cession à un tiers.

Une nuance de bonne foi : le service compte des volumes agrégés purement techniques (nombre d'objets, espace occupé, nombre d'appels OCR) pour la facturation et les quotas. Ce sont des compteurs, jamais des contenus.

Sans réserve pour tout ce que nous maîtrisons : nous n'utilisons et n'utiliserons jamais vos données pour entraîner un modèle d'IA (article 6.3 des CGV).

Une réserve honnête sur un seul flux : le module optionnel de lecture automatique de registres (OCR) envoie les images concernées à un service tiers (Google Cloud Vision / Gemini). Ce module est désactivé par défaut pour tout musée (CGV, article 2.7) — nous ne l'activons jamais pour votre compte sans votre accord écrit préalable, vous seul pouvez le configurer depuis vos paramètres. L'offre payante que nous utilisons n'entraîne pas ses modèles sur ces données à ce jour — mais nous ne maîtrisons pas les conditions contractuelles de ce tiers et ne pouvons pas en garantir la permanence dans le temps, contrairement à ce que nous maîtrisons nous-mêmes. C'est la seule chose que nous ne pouvons pas promettre sans réserve.

Oui. L'export en un clic parcourt l'intégralité des tables de votre espace — y compris récolements, radiations, constats d'état, expositions, événements et thésaurus.

L'export interroge la base pour savoir ce qu'elle contient, plutôt que de suivre une liste figée : il ne peut donc pas prendre de retard sur le produit à mesure que de nouveaux modules s'ajoutent.

Chaque archive contient en outre un manifeste : liste des tables exportées, nombre de lignes par table, et le cas échéant les tables n'ayant pas pu être exportées. Vous pouvez donc vérifier l'exhaustivité de votre export sans nous croire sur parole.

Un dump PostgreSQL complet du schéma reste disponible sur demande, sans frais.

Oui, entièrement en autonomie, depuis votre interface d'administration (rôle admin, aucune sollicitation de Wilder Labs) : export JSON global, export CSV complet, exports Joconde (XML et CSV), LIDO, CIDOC-CRM, et téléchargement des photographies.

L'export JSON global n'est pas un sous-ensemble : il découvre dynamiquement toutes les tables du schéma et en extrait l'intégralité du contenu — l'équivalent fonctionnel d'un dump SQL exhaustif, en libre-service, gratuit, immédiat.

• JSON — structure complète, réimportable
• CSV — exploitable dans Excel ou LibreOffice
• Joconde XML et CSV (22 colonnes POP) — format du ministère de la Culture
• LIDO 1.0 — standard CIDOC, conforme au schéma lido-v1.0.xsd, utilisé par Europeana et l'OAI-PMH
• CIDOC-CRM en RDF/XML — web sémantique
• Dump PostgreSQL — sur demande, exhaustif
• Photographies — fichiers d'origine, dans leur définition initiale

Oui. Museo conserve le fichier d'origine tel que téléversé ; les versions réduites sont générées à part pour l'affichage. Vous récupérez les originaux.

Oui dans les formats structurés : le JSON et le dump SQL conservent tous les liens (objet ↔ photographies, objet ↔ donateur, objet ↔ prêt, objet ↔ exposition, objet ↔ thésaurus). Le CSV, par nature, aplatit certaines relations — c'est une limite du format, pas du logiciel.

Rien. Ni à l'usage, ni à la sortie. Facturer la récupération de ses propres données serait un mécanisme de rétention ; nous ne le pratiquons pas.

60 jours. Votre espace reste accessible en lecture seule pendant 60 jours après la fin de l'abonnement, ce qui vous laisse le temps d'exporter tranquillement, sans urgence et sans nous solliciter.

Les exports restent gratuits et illimités pendant toute cette période (question 47).

Le schéma de base de données et les fichiers (photographies, documents) sont supprimés à l'issue des 60 jours. Les sauvegardes chiffrées contenant encore vos données s'effacent ensuite selon leur cycle de rotation, au plus tard 90 jours après la résiliation.

Précision sur l'archive mensuelle 12 mois (question 17) : un script dédié retire spécifiquement un tenant supprimé de cette archive longue durée, plutôt que d'attendre sa rotation naturelle. Actif en production (tâche planifiée mensuelle), il tourne après chaque archive du mois pour que la purge sous 90 jours reste vraie même avec cette profondeur d'archive.

Oui. Un email de confirmation, daté, est envoyé automatiquement au musée dès la suppression effective du schéma de base de données — sans action manuelle de notre part.

Oui, sans difficulté : formats, délais, gratuité, attestation de suppression. C'est le genre de clause qui vous distingue nettement des éditeurs historiques du secteur.

Trois garanties combinées, engagées au contrat : un préavis (90 jours, voir plus bas), un export final automatique de la totalité de vos données déclenché dès l'annonce d'arrêt, et la libération du code source sous licence libre (question 55). Vos données restent de toute façon exportables à tout moment dans des formats normalisés du secteur (Joconde, LIDO, CIDOC-CRM), reprises par n'importe quel autre logiciel de gestion de collections sans dépendre de notre survie.

Oui, 90 jours, dans le scénario de cessation d'activité de Wilder Labs (question 52). C'est une durée volontairement large pour une structure de notre taille : le temps de trouver et migrer vers un autre outil sans précipitation, avec un export automatique déclenché dès l'annonce.

Accès maintenu normalement pendant toute la durée du préavis de 90 jours (question 53). Les 60 premiers jours de ce préavis, l'accès reste garanti au minimum en lecture seule, pour vérifier et compléter l'export automatique déclenché dès l'annonce de la cessation (CGV, article 8). Le code source est par ailleurs publié sous licence libre à cette même occasion.

Non aujourd'hui. Il n'existe pas de dépôt du code chez un tiers séquestre.

Engagement retenu, plus fort qu'un séquestre : en cas de cessation d'activité, le code source de Museo est publié sous licence libre. Le musée, ou le prestataire de son choix, peut alors reprendre l'outil et continuer à l'exploiter.

Nous préférons cet engagement au séquestre classique, qui coûte 1 000 à 3 000 € par an, immobilise du code que personne ne consulte, et suppose une procédure de déblocage lourde. La libération du code répond au même besoin, immédiatement et sans condition.

Oui, : un export complet vous est déposé automatiquement chaque mois, par email, sans action de votre part. Vous détenez ainsi en permanence une copie autonome de vos données, indépendamment de notre existence.

L'export reprend l'intégralité des tables de votre espace (le même mécanisme exhaustif que la question 42) et vous informe de son contenu — nombre de tables, taille. Si un mois donné l'archive dépasse la taille transmissible par email (typiquement à cause de photos volumineuses dans la boutique), vous en êtes averti avec un renvoi vers le téléchargement direct depuis vos réglages, plutôt qu'un échec silencieux.

Grille actuelle : Découverte gratuit, Essentiel 25 €/mois ou 150 €/semestre, Professionnel 50 €/mois ou 300 €/semestre, Sur Mesure sur devis.

Prix garanti 24 mois à compter de la souscription. Pour une association qui doit faire voter un budget, cette visibilité fait partie de l'offre.

Préavis de 3 mois avant toute hausse tarifaire, notifié par email. Le tarif en vigueur au moment de la notification reste applicable jusqu'à la fin de la période déjà payée (mois ou semestre en cours). Vous conservez à tout moment un droit de résiliation sans frais, avec export complet de vos données.

Non, aucune indexation automatique. Pas de clause d'indexation SYNTEC ni d'augmentation mécanique liée à l'inflation : toute évolution tarifaire est une décision explicite, notifiée avec le préavis de 3 mois de la question 58 — jamais une hausse silencieuse en fin d'année.

Chaque formule inclut un quota de stockage : 500 Mo (Découverte), 5 Go (Essentiel), 50 Go (Professionnel), Sur Mesure sur devis. Le dépassement bloque les nouveaux téléversements de photos, il n'est jamais facturé à la surconsommation — pas de mauvaise surprise sur la facture. Si le quota devient trop juste, la solution est de passer à la formule supérieure, pas de payer au Go.

Le nombre d'utilisateurs est plafonné par formule, pas facturé à l'unité. Attention : la formule Découverte est mono-utilisateur. Avec 3 personnes minimum, votre musée relève au minimum de la formule Essentiel.

L'import Excel est intégré au produit, utilisable en autonomie, sans supplément. Pour 600 objets depuis un tableur, c'est l'affaire d'une séance.

La reprise accompagnée est offerte à la mise en service : une séance avec vous pour la mise en correspondance des colonnes de votre tableur et le contrôle des doublons sur le numéro d'inventaire. C'est peu de travail de notre côté, ça sécurise votre démarrage, et ça évite les allers-retours après coup.

Museo intègre des bulles d'aide contextuelles pour l'usage quotidien. Une visioconférence de prise en main d'une à deux heures est offerte à la mise en service, pour les référents désignés par le musée. Les sessions de formation supplémentaires (nouveaux bénévoles, remise à niveau) sont facturées sur devis.

Est inclus, sans supplément, dans toutes les formules payantes : identité visuelle du portail (logo, couleurs, textes), champs personnalisés sur les fiches, vocabulaires et thésaurus propres au musée. Un développement spécifique (fonction sur mesure, intégration tierce) relève du devis, dans la formule Sur Mesure.

Museo expose une API et un point d'accès OAI-PMH pour le moissonnage. L'accès API est inclus à partir de la formule Professionnel (voir aussi question 92) ; les exports normalisés (Joconde, LIDO, CIDOC-CRM), eux, restent disponibles sans limitation dans toutes les formules, y compris Découverte et Essentiel (voir question 66).

Oui, dans toutes les formules, sans limitation de nombre. Voir question 47.

Assistance par email dans toutes les formules, y compris Découverte. Assistance téléphonique sur rendez-vous à partir de la formule Professionnel — un créneau se fixe par email, pour un sujet qui le justifie (blocage, mise en service, question complexe). Cela permet de préparer la réponse plutôt que de gérer l'appel à chaud, ce qui est plus fiable pour une structure d'une personne.

Oui : le portail public (galerie des collections, notices, actualités, agenda, page de dons, formulaire de demande de visite, y compris demandes de chercheurs) est inclus, sans coût d'hébergement supplémentaire.

Ces modules sont intégrés à Museo, sans supplément d'abonnement. La newsletter est incluse dans toutes les formules, y compris Découverte. La billetterie, la boutique en ligne et le module de dons sont inclus à partir de la formule Essentiel — ils impliquent l'encaissement de fonds pour le compte du musée, ce qui suppose un accompagnement minimal à la mise en service que la formule gratuite ne couvre pas.

En revanche les commissions de l'encaisseur s'appliquent toujours et ne nous reviennent pas : Stripe environ 1,5 % + 0,25 € par transaction européenne, HelloAsso sans commission obligatoire (contribution volontaire du donateur).

Aucune fonction présente dans votre formule au moment de la souscription ne sera retirée ni rendue payante pendant votre durée d'engagement. Cela vaut clause figée : le prix garanti 24 mois de la question 57 porte sur le contenu de la formule, pas seulement sur son montant. Les nouveaux modules développés après votre souscription pourront relever d'une option payante, mais jamais rétroactivement sur ce que vous avez déjà.

Un point à signaler par honnêteté : l'OCR par intelligence artificielle a un coût à l'appel qui nous est facturé par Google. Il est aujourd'hui plafonné par un quota mensuel inclus par musée ; s'il devait un jour devenir une option payante au-delà de ce quota, ce serait annoncé avec un préavis, jamais activé sans prévenir.

99,5 % de disponibilité mensuelle, hors fenêtres de maintenance annoncées — soit au maximum 3 h 40 d'indisponibilité par mois. Contractuel (CGV, article 5.2), avec avoir proportionnel en cas de non-respect (article 5.5).

Nous n'annonçons délibérément pas 99,9 % : ce seuil n'autorise que 43 minutes par mois, nuits et week-ends compris. Un prestataire de notre taille qui l'affiche ne le tient pas.

4 heures ouvrées pour une panne bloquante (service inaccessible ou fonction cœur hors service), 1 jour ouvré pour un dysfonctionnement majeur (fonction secondaire affectée), 5 jours ouvrés pour le reste. Contractuel (CGV, article 5.3). « Prise en charge » signifie que le sujet est diagnostiqué et traité, pas nécessairement résolu — voir question 73.

Un délai de prise en charge s'engage fermement (question 72) ; un délai de résolution ne peut pas s'engager de la même façon, la cause d'une panne n'étant pas connue à l'avance. Engagement de moyens contractuel (CGV, article 5.4) : information régulière du musée jusqu'au rétablissement, plutôt qu'un délai ferme intenable. En pratique, sur l'historique du service, les incidents bloquants ont toujours été résolus en quelques heures.

Oui, avoir proportionnel sur l'abonnement : 10 % du montant mensuel par tranche de 0,5 % de disponibilité manquante sous le seuil de 99,5 % (question 71), plafonné au montant du mois concerné. Sur 25 €/mois, l'enjeu financier reste symbolique — mais l'engagement contractuel, lui, est réel.

Non. Email dans toutes les formules ; téléphone sur rendez-vous à partir de Professionnel (question 67). Ce n'est pas un centre d'appels avec permanence, c'est un contact direct avec l'éditeur — pour une structure de notre taille, c'est souvent plus efficace qu'une hotline.

Réponse honnête : le support est assuré en jours ouvrés. Une astreinte week-end n'est pas soutenable à ce niveau de tarif — mieux vaut le dire que de le promettre et de le rater.

Le musée, pour les données qu'il saisit et pour celles de ses visiteurs, donateurs et acheteurs. C'est lui qui détermine les finalités et les moyens.

Oui. Nous traitons vos données uniquement sur votre instruction, pour l'exécution du service.

Oui. Un accord de sous-traitance conforme à l'article 28, établi sur la base du modèle de la CNIL, est disponible : objet et durée, finalités, catégories de données et de personnes concernées, instructions documentées, confidentialité, mesures de sécurité détaillées, sous-traitants ultérieurs, transferts hors UE, assistance à l'exercice des droits, notification de violation, sort des données en fin de contrat, audit.

Il est accompagné de deux annexes : la procédure de notification de violation de données et la politique de gestion des vulnérabilités. Point restant à documenter précisément : la base juridique de chaque transfert hors UE listé à la question 1 (clauses contractuelles types ou Data Privacy Framework selon le prestataire).

Oui — c'est le tableau de la question 1, à annexer au DPA, avec engagement d'information préalable en cas d'ajout ou de remplacement.

En France, chez OVHcloud. Les données personnelles concernées : comptes utilisateurs du musée, contacts (donateurs, prêteurs, artistes), abonnés à la lettre d'information, acheteurs et donateurs, demandeurs de visite, et les fiches du module Témoins de l'Histoire lorsqu'il est utilisé.

Les données de collection sont conservées tant que dure le contrat — elles constituent l'inventaire du musée, dont la conservation est une obligation légale de sa part.

Pour les données à caractère personnel, une durée est fixée par catégorie :

Ces durées sont reprises à l'identique dans le DPA (même tableau, même article), pour éviter la divergence qu'un juriste relèverait en premier (même principe qu'aux questions 48-49). La purge automatique s'applique à toutes les catégories de ce tableau. Pour les contacts (donateurs, prêteurs, artistes), la purge ne retire que les fiches sans aucun lien actif restant — un donateur dont l'objet fait toujours partie de la collection n'est jamais supprimé, la provenance étant un registre patrimonial permanent distinct de la conservation des données personnelles.

• Journal d'activité sur les fiches (piste d'audit) : 5 ans, purge automatique au-delà.
• Statistiques de consultation du portail : 180 jours, purge automatique.
• Contributions publiques modérées : 1 an.
• Journaux techniques du serveur : quelques jours, rotation par la couche d'exécution.

La table d'historique : chaque modification d'une fiche d'objet, avec l'auteur, la date, le champ modifié, l'ancienne et la nouvelle valeur, ainsi que les connexions réussies et échouées avec l'adresse IP.

C'est ce qui permet la traçabilité exigée pour un inventaire réglementaire — et cette durée se justifie précisément par là (RGPD art. 30, ISO 15489).

Oui, et elle est structurelle. Le portail public n'expose que les objets dont la zone de localisation vaut « exposition », et il ne lit que des champs explicitement publics : désignation, auteur, période, matières, dimensions, notice publique. La valeur d'assurance, le prix d'acquisition, la localisation précise en réserve et les coordonnées des donateurs ne figurent dans aucune requête du portail.

Oui, et c'est le comportement par défaut : une fiche n'apparaît publiquement que si elle est explicitement placée en zone d'exposition. Le défaut est donc la non-publication, pas l'inverse.

Chaque photographie porte en plus son propre indicateur d'autorisation de diffusion : une fiche peut être publique sans que telle photographie le soit.

Oui. La localisation précise (réserve, salle, meuble, étagère) est une donnée strictement interne, jamais servie au portail public. Seule la mention générique du statut d'exposition apparaît.

La séparation existe à deux niveaux : la fiche (publiée ou non) et la photographie (diffusable ou non). Les champs sensibles (valeur d'assurance, prix d'acquisition, localisation précise) sont exclus du portail public par conception — filtrage au niveau de la requête, pas un réglage qu'on pourrait désactiver par erreur.

Le même filtrage s'applique à l'API v1 : GET /api/v1/objects et /objects/:id excluent systématiquement le prix d'acquisition, la valeur d'assurance et la date d'estimation avant l'envoi de la réponse. Nuance à connaître : GET /api/v1/stats renvoie la valeur d'assurance totale agrégée de la collection (une somme, jamais par objet) — cohérent avec la question 74 sur l'indemnisation SLA, mais à garder en tête si l'agrégat lui-même est sensible pour vous.

Elles le sont déjà, par construction : aucune requête du portail public ne lit les champs de valeur d'assurance, de prix d'acquisition ou d'estimation. Il n'y a pas de réglage à activer, donc pas de risque d'erreur de manipulation.

Oui, en ligne à https://museo.wilderlabs.fr/api/docs : authentification, limites de débit, chaque point d'accès avec ses paramètres. Les champs financiers par objet (prix d'acquisition, valeur d'assurance, date d'estimation) sont exclus de la réponse API (question 88) — la clé API reste néanmoins à traiter comme un secret administrateur pour tout le reste des données, jamais intégrée dans du code exécuté côté navigateur.

Un point d'accès OAI-PMH est exposé séparément, protocole standard pour les moissonneurs institutionnels (Europeana, agrégateurs régionaux).

Oui, pour protéger le service : 120 requêtes par minute sur l'API, 60 écritures par minute, 10 téléversements par tranche de 5 minutes, 100 tentatives d'authentification par quart d'heure. Ces plafonds sont très au-dessus d'un usage normal et ajustables pour un besoin de moissonnage.

Oui. L'accès à l'API applicative est inclus, sans supplément, dans la formule Professionnel et dans Sur Mesure (voir question 65). Il n'est pas ouvert dans Découverte ni Essentiel — mais les exports normalisés (Joconde, LIDO, CIDOC-CRM) et le point d'accès OAI-PMH, eux, restent disponibles dans toutes les formules.

Oui : par l'API, par OAI-PMH pour le moissonnage de notices, et par les exports normalisés (Joconde, LIDO, CIDOC-CRM) que les logiciels du secteur savent lire.

Il n'existe pas de connecteur automatique vers tel ou tel logiciel concurrent — cela n'existe d'ailleurs nulle part dans le secteur. Ce qui existe et qui compte : les formats de sortie sont les formats normalisés que ces logiciels importent nativement, donc la reprise ne dépend pas de notre coopération.

Oui, et c'est la bonne façon de répondre : joindre un fichier réel plutôt que de le décrire. Museo produit trois sorties Joconde depuis l'interface : XML simplifié, XML complet, et CSV à 22 colonnes prêt pour POP (la plateforme ouverte du patrimoine).

Pièce disponible : un export Joconde XML d'exemple, généré par Museo sur des notices de démonstration, est joint au dossier (docs/normes/exemple-export-joconde.xml).

Oui. Museo génère du LIDO 1.0 conforme au schéma officiel lido-v1.0.xsd — le standard CIDOC utilisé par Europeana et les agrégateurs OAI-PMH.

Pièce disponible : un fichier LIDO d'exemple est joint (docs/normes/exemple-export-lido.xml). Les 40 éléments que Museo émet ont été vérifiés comme existant dans le schéma officiel LIDO 1.0.

Réponse précise, sans surenchère : Museo produit du RDF/XML utilisant un sous-ensemble du CIDOC-CRM, centré sur les entités et propriétés qui portent réellement l'information d'une notice d'œuvre :

• E22 Human-Made Object — l'objet
• E42 Identifier via P1 — le numéro d'inventaire
• E35 Title via P102 — la désignation
• E55 Type via P2 — la catégorie
• E57 Material via P45 — matières et techniques
• E54 Dimension via P43 — les mesures
• E12 Production via P108i, avec E21 Person (P14) et E52 Time-Span (P4) — auteur et datation
• E40 Legal Body — l'institution détentrice
• P3 has note — description et notes
• E53 Place via P53 — localisation actuelle ou passée
• E8 Acquisition via P4/P23, avec E39 Actor — donateur et date d'entrée

Ce n'est pas une implémentation exhaustive du modèle CIDOC-CRM — très peu de logiciels du marché en proposent une. C'est un export conforme au vocabulaire CIDOC, réutilisable en web sémantique.

Oui, documentation disponible : tableau à trois colonnes — champ Museo, code Joconde officiel, règle de transformation — extrait du code d'export lui-même. Le document signale les champs Joconde non alimentés, les champs Museo sans équivalent, et le niveau exact de CIDOC-CRM implémenté.

Trois constats relevés en produisant ce document, tous corrigés depuis, sauf le dernier :

• Quatre générateurs Joconde distincts et non alignés entre eux : le champ HIST recevait la notice interne dans l'un, un texte d'étiquette dans les autres. Unifiés — un seul point de mapping pour les 4 exports, HIST tranché en faveur du texte destiné à diffusion.
• Aucun export ne lisait la notice publique dédiée : tous republiaient la notice scientifique interne vers Joconde, POP et Europeana. Corrigé.
• Un code non officiel (NOTE), alimenté par un champ de travail interne, était diffusé dans deux des exports. Retiré — même principe que HIST.

Un document exploitable, et c'est une des fonctions les plus abouties de Museo.

• Récolement cadré par zone, salle ou collection, conformément à l'article L451-2 du Code du patrimoine.
• Pointage individuel ou en lot, avec photographie de constat par objet.
• Procès-verbal signé : PDF horodaté portant une empreinte SHA-256 du contenu. Toute modification ultérieure d'une donnée casse l'empreinte — le PV est donc vérifiable.
• Signature réservée aux administrateurs, PV archivé et téléchargeable.
• Suivi des objets non retrouvés : bascule automatique en recherche, tableau de bord dédié, cycle recherche → retrouvé → perdu.
• Récolement décennal suivant clonable depuis le précédent, périmètre conservé.

Museo couvre également la sortie d'inventaire (radiation) selon l'article R451-19 : proposition, validation par un administrateur, PV PDF avec empreinte, six motifs normalisés, et interdiction définitive de réemploi du numéro d'inventaire.

Une réserve d'honnêteté : ces documents sont conformes dans leur contenu et leur traçabilité, mais aucun logiciel ne peut certifier à lui seul la validité juridique d'un récolement — celle-ci tient aussi à la procédure suivie par le musée et à la signature de ses responsables.

Le fondateur de Wilder Labs conçoit, développe, déploie et maintient Museo au quotidien. Wilder Labs est une structure indépendante à taille réduite, sans équipe de développement salariée derrière le produit. Nous sommes deux : un second collaborateur, aujourd'hui intervenant externe, rejoindra prochainement la société — il apporte une capacité de reprise technique, une expertise complémentaire, et sécurise la continuité de la structure au-delà du seul fondateur.

Museo n'est pas conçu en vase clos : l'association qui gère le musée de Tercé, premier musée à l'utiliser en production, a contribué à l'élaboration de l'application — ses besoins réels de terrain (récolement, gestion des prêts, constats d'état) ont directement orienté les fonctionnalités réglementaires du produit.

Ce que cela change concrètement, en bien comme en moins bien :

• Réactivité : un correctif critique est déployé dans la journée, sans validation hiérarchique à traverser.
• Une dépendance réelle au fondateur pour la maintenance quotidienne, que nous ne cherchons pas à masquer — l'arrivée d'un collaborateur l'atténue sans l'annuler tant que son intégration n'est pas formalisée. C'est précisément ce que couvrent en complément les engagements de réversibilité et de pérennité : exports aux formats normalisés du secteur (Joconde, LIDO, CIDOC-CRM) qui vous rendent reprenables par n'importe quel autre logiciel, préavis contractuel de 90 jours, et publication du code source sous licence libre en cas de cessation d'activité (questions 43 à 56).

Le tarif reflète cette structure, avec un inventaire réglementaire complet accessible dès 25 € par mois.

Continu : les correctifs et améliorations sont déployés dès qu'ils sont prêts, sans attendre une version trimestrielle. Le déploiement est automatisé et n'occasionne quasiment aucune interruption.

Oui, comme tout logiciel qui évolue : de nouveaux champs et de nouvelles tables apparaissent. Ces évolutions passent par des migrations versionnées, séquentielles et tracées (la 101ᵉ à ce jour), et sont additives : on ajoute, on ne supprime pas de données existantes.

Museo pratique par ailleurs la suppression logique sur les tables sensibles : une donnée effacée est marquée comme telle plutôt que détruite, ce qui préserve l'historique.

Oui, deux environnements distincts de la production : un environnement de développement et une préproduction. Le code passe par une chaîne d'intégration continue avec vérification de syntaxe et exécution des tests avant tout déploiement ; l'image livrée est signée cryptographiquement et sa signature vérifiée au déploiement.

Oui : 178 tests automatisés s'exécutent à chaque validation de code, et le pipeline CI (Gitea Actions) fait dépendre techniquement le job de déploiement du job de tests (needs: [check]) — un échec de test bloque physiquement la publication, ce n'est pas une convention d'équipe contournable. Complété par un test de bout en bout sur la production et une recette manuelle.

La couverture de tests automatisés est en cours d'extension module par module.

Wilder Labs détient le code source et les droits patrimoniaux sur Museo. Vous détenez vos données, sans aucune réserve (questions 37 à 41).

Voir la question 55 : nous pouvons nous engager contractuellement à libérer le code sous licence libre en cas de cessation d'activité, ce qui garantit la continuité de l'outil au-delà de notre existence.