Gestion des versions des extensions
Consultez l'état d'installation pour tous les types de contenu, analysez l'impact sur les workflows et mettez à jour les extensions depuis l'onglet Version & sécurité d'une extension.
La ligne d'une extension dans Paramètres → Plateforme → Extensions → Installées (et les onglets Inclus et Version & sécurité de sa fiche) est l'emplacement central pour suivre la version installée, consulter l'état d'installation par type de contenu et appliquer les mises à jour. Pour le modèle de versionnement complet du point de vue d'un auteur d'extension — règles semver, liste de contrôle de publication et fonctionnement des pins/politiques — voir Versionnement des extensions. Lorsqu'une extension dispose d'une mise à jour, sa ligne dans l'onglet Extensions → Installées l'affiche dans la colonne version — 1.3.0 → 1.4.0 — jamais sur la ligne d'état, afin qu'une mise à jour en attente ne masque jamais un identifiant défaillant. La mise à jour elle-même s'examine et s'applique dans l'onglet Version & sécurité de l'extension. Les sources de données ne font pas partie de cette mise à jour — elles se mettent à jour par espace de travail : lorsque des sources de données installées sont en retard sur la dernière version, la section Version installée de l'onglet indique combien et sur quelle version, et un administrateur de l'espace de travail les met à jour avec Mettre à jour vers vX dans Analytics → Marketplace (un clic réconcilie l'ensemble des sources de l'extension).
Comportement des mises à jour par type de contenu
Tous les types de contenu d'une extension ne se mettent pas à jour de la même manière — la plateforme applique le minimum d'automatisation qui reste sûr pour chaque type. Ce tableau est le modèle mental ; les sections ci-dessous détaillent chacun.
| Type de contenu | Mode de mise à jour | Pourquoi |
|---|---|---|
| Sources de données de référence statiques (données en ligne, sans appel externe) | Automatique à la synchronisation — installées dès qu'une mise à jour d'extension atteint votre catalogue, sauf si la politique de l'extension est Manuelle. | Additives, ne font aucun appel externe et ne peuvent pas écraser vos données — le type le plus sûr. |
| Sources de données externes (polling) | Installer depuis Analytics → Marketplace — Mettre à jour vers vX réconcilie l'ensemble complet des sources de l'extension. | Une nouvelle source commence à appeler un système externe ; son installation relève donc de votre décision. |
| Ontologie et domaines KB | Les nouveaux éléments de schéma s'appliquent automatiquement à la synchronisation dans chaque environnement d'espace de travail existant où l'extension est déjà installée ; les changements d'éléments existants, et les nouveaux domaines KB, s'appliquent lorsque vous cliquez sur Mettre à jour l'extension. | Ajouter de nouveaux types d'objets/liens est sûr ; les modifier ou les supprimer peut affecter les tables liées, l'analytique et le graphe. |
| Process flows | Automatique — toujours la dernière version du catalogue. | Un modèle n'apparaît que dans la galerie ; il n'exécute rien tant qu'un espace de travail ne s'y abonne pas. |
| Extensions | Par connexion : manual (par défaut), ou auto_patch / auto_minor en option ; les changements cassants sont toujours retenus. | Code fournisseur exécutable + identifiants + egress — le type le plus à risque. |
| Workflows | Déployés par environnement depuis la page Extensions agentic ; une version plus récente affiche Mise à jour disponible sur la ligne de cet environnement, et vous l’appliquez là. | Vous choisissez quel environnement exécute quelle version, et une mise à jour n’efface jamais les modifications faites dans cet environnement. |
| Notebooks | Stockés à l'installation ; matérialisés / mis à jour par espace de travail dans Analytics. | Rien ne s'exécute tant que vous ne l'avez pas matérialisé. |
Garanties de sécurité, toujours : une application automatique ne fait qu'ajouter — elle ne supprime jamais vos données, n'écrase jamais une source ou un type que vous avez déjà, ne démarre jamais un nouvel appel externe, et n'exécute jamais de nouveau code sans vous. Un changement cassant d'extension n'est jamais appliqué automatiquement — il est signalé et attend votre revue.
Chaque extension possède une politique de mise à jour (par défaut Automatique). Le contenu additif et sans egress — les sources de données de référence statiques et les nouveaux éléments de schéma d'ontologie — s'installe automatiquement dès qu'une mise à jour d'extension atteint votre catalogue. Réglez la politique d'une extension sur Manuelle pour revoir chaque mise à jour vous-même ; tout ce qui appelle un système externe, exécute du code ou modifie un élément existant conserve toujours son étape de revue, quelle que soit la politique. Pour que vous ne manquiez jamais une mise à jour retenue, l'onglet Inclus de l'extension signale les sources de données déclarées mais non installées (« N disponibles, non installées ») et la carte affiche un état non provisionné lorsque la table sous-jacente d'une couche est manquante — au lieu d'un « (0) » silencieux.
Lorsqu'une nouvelle version abandonne un élément d'ontologie
Une mise à jour ne supprime jamais un élément d'ontologie qu'une version plus récente de l'extension ne déclare plus — dans aucun mode, y compris Mettre à jour l'extension. L'élément reste actif, et la plateforme propose sa suppression à votre revue : elle ouvre une branche brouillon sur l'ontologie de l'extension, nommée par exemple osint-intelligence: 1 item no longer declared, review to retire (…), dans chaque environnement d'espace de travail où l'extension est installée. Retrouvez-la dans Ontology → History (Analytics). Soumettez puis publiez la branche pour retirer les éléments ; archivez-la pour les conserver. La même branche est réutilisée à chaque synchronisation ultérieure tant que l'ensemble des éléments abandonnés ne change pas : l'archiver est donc une décision durable. Seuls les éléments que l'extension elle-même déclarait dans sa version précédente sont proposés : ce que vous ou votre équipe avez ajouté à l'ontologie, et ce qu'une autre source y a apporté, ne fait jamais partie de cette branche.
Seuls les éléments dont le retrait ne peut entraîner aucune perte de données sont proposés : règles de surveillance, liaisons, types d'action, formes, règles et alias. Retirer une règle de surveillance conserve ses détections passées ; retirer une liaison conserve sa table et ses lignes. Un type d'objet ou type de lien abandonné n'est jamais proposé, car le retirer laisserait orphelins tous les enregistrements de ce type — il reste actif, et le supprimer est un changement de schéma délibéré que vous effectuez vous-même. La page Extensions ne renvoie pas encore vers ces branches.
Voir où une extension est utilisée
La colonne En cours d'utilisation du tableau du catalogue indique ce que chaque extension installée a réellement produit dans votre organisation :
- Workflows — workflows déployés depuis l'extension, par environnement d'espace de travail. Cliquez sur un workflow pour l'ouvrir dans Agentic.
- Process flows — instances de process flows actives créées à partir des modèles de l'extension. Le compteur représente le total réel ; le popover liste les 25 plus récents. Cliquez sur une instance pour l'ouvrir dans Agentic.
- Sources de données — sources de données installées depuis l'extension. Cliquez pour ouvrir la page des sources de données dans Analytics.
Un tiret (—) signifie que l'extension est dans votre catalogue mais n'est actuellement utilisée nulle part — signal utile avant de retirer une extension.
En développant une ligne d'extension, vous obtenez les mêmes informations en détail, ainsi que les Workflows utilisant les extensions de cette extension : les workflows de votre organisation dont les blocs appellent une extension installée par cette extension. Il s'agit de la même analyse d'impact que celle effectuée lors d'une mise à jour — affichée en permanence pour vous permettre d'évaluer le rayon d'action avant de retirer ou de mettre à jour une extension.
Si un panneau affiche État indisponible, un service sous-jacent n'a pas pu être atteint ; les autres panneaux restent exacts.
Colonne État d'installation
Chaque ligne de l'onglet Catalogue affiche une extension à sa version la plus récente disponible. La colonne État d'installation indique l'état le plus important parmi tous les types de contenu de cette extension :
| État | Signification |
|---|---|
| Mise à jour disponible | Au moins un type de contenu dispose d'une version plus récente dans le catalogue que celle actuellement installée. |
| Installé | Tous les types de contenu installés sont à jour (aucune mise à jour nécessaire). |
| Non installé | Aucun contenu de cette extension n'a été installé dans votre organisation. |
Lorsqu'une mise à jour est disponible, la colonne version affiche la version installée aux côtés de la plus récente : par exemple v1.1.0 → v1.1.1.
Pour le contenu d'ontologie, cet état à l'échelle de l'organisation est volontairement strict. Il n'est affiché qu'après lecture de tous les environnements d'espace de travail attendus et confirmation de la même version d'extension, de la même identité d'ontologie, de la même provenance de catalogue/source et du même manifeste normalisé dans chacun d'eux. Un environnement manquant ou divergent fait apparaître État indisponible dans le panneau d'ontologie au lieu de choisir une ligne et de la présenter comme vérité à l'échelle de l'organisation.
Ligne développée — État par type de contenu
Cliquez sur une ligne pour la développer et voir l'état d'installation ventilé par type de contenu :
Extensions
Une ligne par fournisseur inclus dans l'extension. Affiche la version installée et indique si une mise à jour est en attente. La vérification de mise à jour est basée sur le hash de l'artefact : si l'artefact publié diffère de celui installé, une mise à jour est disponible.
Ontologie et domaines KB
Affiche une version installée représentative de l'extension et la date de dernière application, mais uniquement lorsque tous les environnements d'espace de travail existants réussissent le contrôle de cohérence ci-dessus. Une installation ou mise à jour à l'échelle de l'organisation est diffusée vers chaque environnement existant ; une installation/mise à jour depuis Analytics → Marketplace ne cible que l'environnement actif.
La cohérence inclut la ligne du catalogue, l'identifiant de la source de l'extension et la référence de l'entrée, ainsi que l'instantané complet du manifeste normalisé. Les identifiants de révision et horodatages propres aux environnements peuvent légitimement différer et ne servent pas à comparer les versions. Les champs de source peuvent être vides pour les installations anciennes ou manuelles, mais les lectures fondées sur le kernel renvoient toujours l'instantané du manifeste et préservent toute provenance disponible.
Pour les consommateurs de l'API, InstalledExtensionRow reste compatible avec le code source existant : sourceId et sourceEntryRef sont des champs optionnels-nullables ajoutés, et les anciens fixtures TypeScript peuvent toujours omettre manifestSnapshot dans leurs entrées. Une ligne installée renvoyée par le kernel fournit toujours le manifestSnapshot normalisé complet et les deux champs de provenance (éventuellement null) ; un client ne doit pas remplacer l'instantané par un hash ni par un sous-ensemble reconstruit.
Workflows
Affiche une ligne par environnement d'espace de travail dans lequel les workflows de cette extension ont été déployés. Chaque ligne inclut :
- Le nom de l'environnement d'espace de travail.
- La version de l'extension installée, ou version inconnue si le workflow a été déployé avant l'introduction du suivi de version. « Version inconnue » est sans gravité — le workflow fonctionne, mais sa version d'extension ne peut pas être comparée.
Le déploiement d'un workflow dans un espace de travail est une action distincte effectuée sur la page Extensions agentic. L'onglet Inclus de l'extension affiche les workflows déjà déployés ; les environnements « non déployés » sont omis de la liste.
Mettre à jour un workflow déployé
Lorsque le catalogue contient une version plus récente d’un workflow que celle d’un environnement, la ligne de cet environnement sur la page Extensions agentic affiche Mise à jour disponible. Chaque environnement a son propre signal et sa propre mise à jour : mettre à jour l’environnement de développement ne touche pas la production.
Ces lignes sont regroupées dans leur propre section Mises à jour disponibles en haut de la page. Chaque ligne affiche les deux versions, par exemple Installée v1.0.0 → v2.0.0. Si l’environnement n’a jamais enregistré la version depuis laquelle il a été déployé, la ligne indique Version inconnue → v2.0.0. Pour n’afficher que ces lignes, activez le filtre Mises à jour à côté du filtre par type de contenu. Il indique combien de lignes ont une mise à jour, et vous pouvez le combiner avec un filtre par type de contenu. Tous les membres voient le signal. Seuls les administrateurs de l’espace de travail disposent de Examiner la mise à jour.
Si la nouvelle version indique ses notes de version (links.releaseNotes dans le fichier extension.json de l’extension), un lien Notes de version apparaît à côté des versions et les ouvre dans un nouvel onglet. Seuls les liens http et https sont affichés.
La plateforme détecte normalement une mise à jour en comparant le contenu de la version avec celui que l’environnement a installé. Un workflow déployé avant l’enregistrement de ce contenu n’a rien à comparer : pour ces workflows, la plateforme compare les numéros de version et n’affiche une mise à jour que si la version du catalogue est strictement plus récente.
Une version du catalogue inférieure à celle qu’exécute un environnement n’est jamais présentée comme une mise à jour, même si son contenu diffère. C’est le cas lorsqu’une version plus récente est retirée. L’environnement conserve sa version.
Un workflow est suivi par le package.id de son manifeste de workflow : dans une organisation, chaque identifiant de package appartient à une seule extension. La publication ou la synchronisation d’une extension dont un workflow utilise un identifiant de package déjà livré par une autre extension est refusée avec workflow_package_id_claimed, et le message nomme cette extension. Donnez au manifeste de workflow son propre package.id. Sinon, les deux extensions s’installeraient dans le même workflow de chaque environnement, et l’une pourrait remplacer celui de l’autre.
Si deux extensions livrent déjà le même workflow sous le même identifiant de package (par exemple, parce que les deux ont été publiées avant l’existence de cette vérification), l’extension qui a livré cet identifiant en premier peut toujours publier de nouvelles versions. L’autre reste refusée tant qu’elle ne change pas son package.id.
Tant qu’une seule extension ne le livre pas, le workflow apparaît dans une section Livré par plusieurs extensions de la page Extensions d’agentic, avec un badge Conflit qui nomme les deux extensions. Personne ne peut l’activer, le mettre à jour ou le désactiver depuis l’une ou l’autre extension, et aucune mise à jour n’est affichée pour lui nulle part. La plateforme ne peut pas savoir de quelle extension provient la copie d’un environnement : elle ne modifie donc rien plutôt que de risquer d’écraser la mauvaise. Une demande d’ajout, de mise à jour ou de suppression est refusée avec workflow_row_contested (HTTP 409), et le message nomme les deux extensions. Pour résoudre le conflit, donnez au manifeste de workflow de l’une des extensions son propre package.id, ou retirez l’une des extensions du catalogue.
Si un workflow que la mise à jour remplace change pendant qu’elle s’exécute, la mise à jour est refusée avec WORKFLOW_CONCURRENT_CHANGE (HTTP 409, avec retryable: true) et l’environnement garde les workflows qu’il avait. Relancez la mise à jour.
Le même signal est affiché partout où vous rencontrez le workflow, toujours pour l’environnement dans lequel vous travaillez :
| Où | Ce que vous voyez |
|---|---|
| Marketplace dans la barre latérale agentic | Le nombre de workflows de cet environnement disposant d’une version plus récente. Les espaces de travail personnels n’ont pas d’entrée Marketplace et n’affichent aucun compteur. |
| La liste des workflows (le sélecteur de workflow dans l’éditeur) | Un badge Mise à jour disponible sur la ligne du workflow. |
| L’en-tête de l’éditeur de workflow | Un badge Mise à jour disponible à côté du nom du workflow. |
| Paramètres → Extensions sur la plateforme | Un point à côté de la version de l’extension, et une carte Mises à jour de workflows dans les espaces de travail dans son onglet Version & sécurité, qui nomme les workflows et le nombre d’environnements, avec un lien vers le Marketplace (il ouvre votre espace de travail actif ; changez d’espace de travail si le workflow se trouve ailleurs). Le bouton Mettre à jour de l’organisation n’applique pas ces mises à jour. |
Les badges renvoient vers le Marketplace. Survolez un badge pour voir quelle extension propose la version plus récente et la version vers laquelle il passe. Le compteur s’actualise au plus toutes les quelques minutes : une mise à jour que vous venez d’appliquer peut donc mettre un moment à en disparaître.
Un administrateur de l’espace de travail clique sur Examiner la mise à jour pour voir, avant tout changement :
- Ce que la version modifie — blocs ajoutés, supprimés ou modifiés.
- Les modifications faites ici qui sont conservées — vos modifications dans cet environnement (un modèle, un prompt, un identifiant, un outil, un paramètre de déclencheur, et le fait qu’un bloc utilise ou non son mode avancé) sont reprises, pas réinitialisées.
- Les surfaces publiées qui restent sur leur version — un formulaire ou un agent publié reste sur la version de déploiement sur laquelle il a été publié. Republiez-le pour qu’il utilise la mise à jour.
Mettre à jour enregistre le workflow fusionné comme une nouvelle version de déploiement ; les versions précédentes restent dans l’historique. Les URL de webhook et les planifications sont conservées.
Lorsqu’une valeur a été modifiée ici et que la nouvelle version la modifie aussi, le panneau la liste sous Choisir la valeur à conserver. Pour chacune, choisissez :
- Utiliser la version de la release — votre modification de ce champ est abandonnée et la valeur de la version est utilisée.
- Conserver la mienne — votre valeur est conservée, et la modification de ce seul champ par la version est ignorée. Tout le reste de la version s’applique quand même.
Rien n’est choisi à votre place : Mettre à jour reste désactivé tant que chaque valeur listée n’a pas reçu de choix. La version précédente reste dans l’historique des déploiements, vous pouvez donc y revenir.
La mise à jour est refusée — et Mettre à jour reste désactivé — lorsqu’elle ne peut conserver l’une de vos modifications d’aucune autre manière. Le panneau nomme chaque raison :
| Raison | Que faire |
|---|---|
| Une valeur a été modifiée ici et la nouvelle version supprime son bloc ou son champ, ou change le bloc en un autre type (par exemple un identifiant choisi pour un fournisseur, sur un bloc qui en appelle désormais un autre) | Supprimez la modification ici, puis mettez à jour. |
| Un bloc a été ajouté ici, ou un bloc de la version a été supprimé ici | Annulez la modification structurelle, puis mettez à jour. |
| Les connexions ont été modifiées ici et dans la version, différemment | Rétablissez les connexions de la version, puis mettez à jour. |
| La version supprime le déclencheur derrière une URL de webhook ou une planification active | Déplacez d’abord les appelants de ce webhook, ou la planification, hors du déclencheur. |
| La version installée ne peut plus être lue (y compris un workflow déployé avant l’enregistrement du contenu, qui dispose d’une version plus récente) | Retirez le workflow de l’environnement et déployez-le à nouveau. |
Le serveur vérifie à nouveau, avec vos choix, lorsque vous cliquez sur Mettre à jour. Un conflit apparu après l’ouverture du panneau s’affiche dans la même liste, et rien n’est modifié.
Sources de données
Affiche une ligne par environnement d'espace de travail dans lequel une source de données de cette extension est installée. L'installation et la mise à jour des sources de données se font dans Analytics → Marketplace : lorsqu'une version plus récente de l'extension est dans le catalogue, chaque source installée y affiche une action Mettre à jour vers vX qui réconcilie l'ensemble des sources de données de l'extension — les sources existantes sont actualisées, les sources ajoutées par la nouvelle version sont installées, et celles qu'elle a supprimées sont retirées. Une source de données déjà ajoutée dans un autre environnement de votre organisation est ignorée — une source de données n'existe que dans un environnement à la fois — et c'est aussi le cas, dans un espace de travail personnel, d'une source de base de données, qu'aucune connexion ne peut y servir ; la mise à jour nomme chaque source ignorée et en donne la raison, et les autres sont mises à jour. Voir Extensions.
Process flows
Les process flows suivent toujours la version la plus récente du catalogue — ils n'ont pas de version installée fixe. La ligne développée affiche un badge le confirmant. Il n'y a pas d'action de mise à jour pour les process flows ; ils utilisent automatiquement le contenu de la dernière ligne de catalogue active pour cette extension.
Mise à jour d'une extension
Lorsqu'au moins un type de contenu dispose d'une mise à jour disponible, une barre de mise à jour apparaît en haut de la ligne développée.
Cliquez sur l'extension dans l'onglet Catalogue pour ouvrir la vue développée. Si une mise à jour est disponible, la barre de mise à jour affiche la version cible (par exemple, Mettre à jour vers v1.1.1) et un résumé des extensions qui seront affectées.
Pour les extensions incluant du contenu d'extension, la plateforme charge automatiquement une analyse d'impact sur les workflows — indiquant quels workflows référencent des outils des extensions de cette extension. Le bouton Mettre à jour l'extension reste désactivé jusqu'à la fin de cette analyse.
Si le chargement de l'analyse d'impact échoue, le bouton Mettre à jour l'extension reste désactivé. Vérifiez votre connexion réseau ou contactez votre administrateur de plateforme.
La plateforme compare les manifestes d'extension installé et cible, et liste les changements incompatibles détectés directement dans la barre de mise à jour : outils supprimés, nouvelles entrées obligatoires, types d'entrée/sortie modifiés ou changements de mode d'authentification — chacun annoté avec l'outil concerné.
Deux niveaux d'avertissement peuvent apparaître :
- Potentiellement incompatible (orange) — la mise à jour est une version majeure, ou le diff de manifeste a trouvé des changements incompatibles correctement déclarés par l'auteur.
- Changements incompatibles dans une mise à jour non majeure (rouge) — le diff de manifeste a trouvé des changements incompatibles mais la version n'est incrémentée qu'en mineur ou en patch. Traitez cela avec une vigilance accrue et contactez l'auteur de l'extension.
Examinez la liste des workflows affectés en lien avec ces constats avant de continuer.
La plateforme installe la dernière version du catalogue pour cette extension. Le code de l'extension reste la propriété de l'organisation ; le contenu d'ontologie et de KB est diffusé vers chaque environnement d'espace de travail existant. Un toast de succès ne confirme la mise à jour qu'une fois toutes les cibles d'ontologie réussies. Si une cible échoue, les cibles réussies restent appliquées et une nouvelle tentative reprend l'opération sans risque.
Le contenu par environnement est mis à jour depuis sa propre interface : les sources de données depuis Analytics → Marketplace (où la mise à jour réconcilie l'ensemble des sources de l'extension — voir Sources de données ci-dessus), et les workflows avec Examiner la mise à jour sur la ligne de chaque environnement de la page Extensions agentic (voir Mettre à jour un workflow déployé).
Cliquer sur Mettre à jour l'extension déplace également le pin de version de votre organisation pour les extensions de l'extension : les exécutions de workflows en cours se terminent avec la version qu'elles ont démarrée, et les nouvelles exécutions utilisent la version mise à jour.
Épinglage de version et politiques de mise à jour
Les versions d'extension installées sont épinglées par connexion. Une version plus récente arrivant dans votre catalogue (par exemple via une synchronisation de source d'extensions Git) est mise en attente mais inactive — rien ne change dans ce qu'exécutent vos workflows tant que le pin ne bouge pas. Le pin se déplace de deux façons :
- Manuellement — vous cliquez sur Mettre à jour l'extension après la revue d'impact (comportement par défaut pour chaque connexion).
- Automatiquement — une connexion peut s'inscrire aux mises à jour automatiques via sa politique de mise à jour :
| Politique | Comportement |
|---|---|
manual (défaut) | Les mises à jour sont uniquement mises en attente ; vous les appliquez depuis l'onglet Version & sécurité de l'extension. |
auto_patch | Les versions patch (1.1.0 → 1.1.1) s'appliquent automatiquement lorsque le diff de manifeste ne détecte aucun changement incompatible. |
auto_minor | Les versions patch et mineures s'appliquent automatiquement lorsque le diff de manifeste ne détecte aucun changement incompatible. |
Les mises à jour automatiques ne s'appliquent jamais lorsque le diff de manifeste détecte un changement incompatible — la connexion est signalée (mise à jour bloquée : breaking_diff) et la mise à jour attend votre révision manuelle dans l'onglet Version & sécurité de l'extension. Les versions majeures nécessitent toujours une mise à jour manuelle.
Erreurs de compatibilité SDK
Les versions de code sont compilées contre une version spécifique du SDK de création Scrydon. Si une archive a été construite contre un contrat SDK que la plateforme ne supporte plus (ou pas encore), vous verrez :
- Au moment de l'installation : l'installation de l'extension échoue avec
extension_contract_incompatibleet un message indiquant les versions de contrat concernées. - Au moment de l'exécution : les outils de l'archive échouent avec
BUNDLE_CONTRACT_INCOMPATIBLEau lieu de s'exécuter.
Ces deux messages signifient la même chose : l'archive doit être republiée avec une version actuelle de @scrydon/sdk-authoring. Si vous êtes l'auteur de l'extension, reconstruisez-la avec le dernier SDK et publiez une nouvelle version ; si elle provient d'un fournisseur, demandez-lui une version mise à jour. Les archives construites contre le contrat SDK immédiatement précédent continuent de fonctionner — la plateforme effectue la traduction automatiquement.
Versions retirées et mises en quarantaine
Chaque version de votre catalogue est active, mise en quarantaine ou retirée.
- Une version retirée a quitté le catalogue : un administrateur l'a retirée, ou sa source a cessé de la lister (voir Sources d'extensions). Elle ne peut plus être installée.
- Une version mise en quarantaine reste dans le catalogue mais est mise en attente d'examen. La quarantaine est posée par votre opérateur de plateforme ; le produit ne propose pas encore d'action pour la poser ou la lever.
Ce que permet chaque état :
| Active | En quarantaine | Retirée | |
|---|---|---|---|
| Installer, mettre à jour ou réparer depuis Analytics → Marketplace ou le panneau Ajouter une source de données | Oui | Non : listée comme indisponible, et l'installation est refusée avec marketplace_content_quarantined | Non : la version n'est pas proposée (marketplace_content_not_found) |
| Supprimer depuis la Marketplace | Oui | Oui | Sans objet |
| Appliquée automatiquement après une synchronisation de source | Oui | Non | Non |
| Une source de données déjà en cours d'exécution | Continue de fonctionner | Continue de fonctionner, avec un avertissement dans sa vue détaillée | Continue de fonctionner |
Une version mise en quarantaine ou retirée n'arrête jamais une source de données déjà en cours d'exécution : elle est signalée, jamais supprimée. Pour en sortir, installez une version prise en charge.
Lorsque l'application automatique après une synchronisation de source atteint une source de données issue d'une version retirée ou mise en quarantaine, l'application est refusée avant toute écriture, avec data_source_extension_retired ou data_source_extension_quarantined (HTTP 409).
Autres versions actives du catalogue
En bas de la ligne développée, Autres versions actives du catalogue liste les versions plus anciennes de cette extension encore présentes dans votre catalogue (par exemple, si une version précédente était installée et que le catalogue n'a pas été nettoyé). Ces entrées sont informatives — elles indiquent ce qui est disponible mais ne constituent pas la version installée active.
Trouver les mises à jour des extensions installées
Lorsqu'une extension dispose d'une mise à jour, la ligne du fournisseur dans Paramètres → Plateforme → Extensions → Installées l'affiche dans la colonne version sous la forme 1.3.0 → 1.4.0. La ligne d'état reste réservée à ce qui requiert une intervention humaine. Ouvrir la ligne mène à son onglet Version & sécurité, où la carte de mise à jour indique ce qui change et ce qui est conservé, et où vous l'appliquez.
Le catalogue Ajouter une extension ne propose que ce qui n'est pas encore installé ; une extension installée y est la ligne du fournisseur lui-même, atténuée sur place, avec Gérer qui ouvre sa fiche.