Plans et droits

Opfield propose les plans Community, Personal, Business et Enterprise. La disponibilité des fonctionnalités, les conditions d’usage commercial, la licence de déploiement d’Opfield et les quotas des services hébergés séparément sont des notions distinctes.

Choisissez un plan à partir des exigences d’exploitation, et non de la taille de l’organisation. Partez des processus qui doivent être pris en charge, des limites de ressources dont ils ont besoin, des contrôles de sécurité exigés par la politique et des conditions de support ou commerciales exigées par l’acheteur. Le responsable de l’installation est chargé de surveiller la santé de la licence ; les responsables des ressources doivent savoir quelles opérations dépendent de droits payants.

Les fonctionnalités payantes disponibles sont appliquées à la frontière des opérations comme dans l’interface. Lorsqu’un plan payant prend fin, l’infrastructure existante continue de fonctionner : après la période de grâce, la création de ressources payantes et la modification de leur configuration sont bloquées, tandis que les ressources payantes existantes continuent de fonctionner. La révocation, le transfert vers une autre installation et la désactivation n’ont pas de période de grâce. Les périodes de grâce et la disponibilité exacte des fonctionnalités peuvent évoluer avec les versions du produit ; consultez la matrice actuelle avant toute publication.

Les installations Community ne nécessitent pas de clé. Une clé Personal, Business ou Enterprise correspond à une instance Opfield active ; les quotas de ressources à l’intérieur d’une instance Opfield ne doivent pas être confondus avec les quotas de services hébergés séparément.

Auto-hébergement et cloud managé

Chaque plan — Community, Personal, Business et Enterprise — peut être auto-hébergé. Une clé payante débloque les fonctionnalités et limites payantes sur une installation que vous exploitez ; aucun plan n’exige qu’Opfield héberge le plan de contrôle. Le cloud managé, dans lequel l’équipe Opfield exploite le plan de contrôle, est une option des plans Personal et Business, vendue avec la clé de licence dans votre compte Opfield ; une installation managée se passe de l’assistant de configuration, et son propriétaire se connecte d’abord avec le compte Opfield et peut ensuite passer à son propre SSO ou à une autre méthode de connexion. Dans une installation auto-hébergée, les identifiants chiffrés et la clé maîtresse restent dans votre environnement ; voir Où se trouvent les secrets dans une installation auto-hébergée. Pour les questions fréquentes avant achat, voir Évaluer Opfield.

Progression des plans

Plan	Frontière habituelle des fonctionnalités
Community	Ingress de base, Docker, Apps, découverte des projets Compose externes, supervision, identité, API REST, automatisation OAuth et MCP, chat d’AI Workspace, Inference, et jusqu’à 25 nœuds gérés, 3 utilisateurs et 1 groupe de permissions personnalisé
Personal	Community plus connexions aux bases de données externes, connexions de stockage, bases de données et stockage objet managés, liens entre conteneurs, sauvegarde et restauration des bases de données, intégration GitLab, Plan Mode, Scenarios et Sandboxes d’IA, cycle de vie Compose mononœud géré, Pages, pages de statut, opérations d’archive et de migration, et quotas de base documentés illimités
Business	Personal plus Workload Availability (HA) multinœud, groupes d’ingress, bases de données et stockage objet managés sur plusieurs serveurs, déploiement au push depuis Git, Build Workers isolés, Secure Runtime, admission selon les vulnérabilités, journalisation structurée, export de l’audit et accès facultatif aux registres externes
Enterprise	Business plus PKI interne, export de l’audit vers un SIEM et avantages commerciaux dédiés

La matrice exacte des fonctionnalités dépend de chaque version. Les pages produit indiquent les prérequis et cette page explique le comportement du cycle de vie ; la tarification et les conditions contractuelles relèvent du contrat commercial applicable. Les tarifs publiés actuels figurent sur le site web d’Opfield.

Guided Onboarding and Configuration Review (Business et Enterprise) et Assisted Deployment and Migration (Enterprise) sont des avantages du plan fournis par l’équipe Opfield, et non des fonctionnalités d’exécution ; leur étendue est définie par le contrat commercial. Quel que soit le plan, Migrer votre pile vers Opfield indique l’ordre de la migration.

Matrice des fonctionnalités

Fonctionnalité	État	Community	Personal	Business	Enterprise
Gestion des nœuds d’infrastructure	Prêt	✅	✅	✅	✅
Gestion de l’ingress nginx multinœud	Prêt	✅	✅	✅	✅
Gestion des conteneurs Docker — environnement d’exécution Default (runc)	Prêt	✅	✅	✅	✅
Découverte, supervision et journaux des projets Compose externes	Prêt	✅	✅	✅	✅
Secure Links Docker ↔ nginx	Prêt	✅	✅	✅	✅
Registre Docker interne privé géré par Opfield	Prêt	✅	✅	✅	✅
Gestion des certificats SSL/TLS	Prêt	✅	✅	✅	✅
Gestion des domaines et du DNS	Prêt	✅	✅	✅	✅
Supervision de l’infrastructure	Prêt	✅	✅	✅	✅
Découverte, rattachement et supervision des GPU physiques	Prêt	✅	✅	✅	✅
Alertes et notifications par webhook	Prêt	✅	✅	✅	✅
Authentification, OIDC et MFA	Prêt	✅	✅	✅	✅
Contrôle d’accès basé sur les rôles, limité par dossier et par ressource	Prêt	✅	✅	✅	✅
Apps avec environnements, variables partagées, promotion, arrêt et coupe-circuit	Prêt	✅	✅	✅	✅
Liaison cloud avec un compte Opfield Cloud	Prêt, sur activation	✅	✅	✅	✅
Relais protégés sur des machines d’autres propriétaires	Prêt, sur activation	✅	✅	✅	✅
Journal d’audit	Prêt	✅	✅	✅	✅
API REST, automatisation OAuth et MCP	Prêt	✅	✅	✅	✅
Chat d’AI Workspace	Prêt, sur activation	✅	✅	✅	✅
Opfield Inference	Prêt, sur activation	✅	✅	✅	✅
Installation automatisée et mises à jour signées	Prêt	✅	✅	✅	✅
Export de configuration d’Opfield pour le transfert vers une autre instance	Prêt	✅	✅	✅	✅
Nœuds gérés	Limite du plan	25	Illimité	Illimité	Illimité
Utilisateurs	Limite du plan	3	Illimité	Illimité	Illimité
Groupes de permissions personnalisés	Limite du plan	1	Illimité	Illimité	Illimité
Niveau de support	Niveau de service	Communauté	Standard	Prioritaire	Prioritaire + dédié
Connexions aux bases de données externes et explorateurs	Prêt	—	✅	✅	✅
Connexions de stockage : S3, R2, MinIO et autres services compatibles S3, FTP, FTPS et SFTP	Prêt	—	✅	✅	✅
Intégration GitLab	Prêt	—	✅	✅	✅
Plan Mode, Scenarios et AI Sandboxes d’AI Workspace	Prêt, sur activation	—	✅	✅	✅
Export et import de conteneurs	Prêt	—	✅	✅	✅
Volumes Docker sur image disque	Prêt	—	✅	✅	✅
Deployments blue/green	Prêt	—	✅	✅	✅
Migration de conteneurs et de Deployments entre nœuds	Prêt	—	✅	✅	✅
Déploiement et cycle de vie Compose mononœud gérés	Prêt	—	✅	✅	✅
Bases de données managées avec Secure Links	Prêt	—	✅	✅	✅
Pages de statut publiques	Prêt, sur activation	—	✅	✅	✅
Pages	Prêt	—	✅	✅	✅
Découverte automatique du registre de conteneurs GitLab	Prêt	—	✅	✅	✅
Sauvegarde et restauration des bases de données managées et externes	Prêt	—	✅	✅	✅
Stockage objet managé (SeaweedFS, mononœud) avec liaisons privées et Secure Links	Prêt	—	✅	✅	✅
Liens entre charges de travail sur le même nœud ou sur des nœuds différents	Prêt	—	✅	✅	✅
Docker Secure Runtime (runsc/gVisor)	Prêt	—	—	✅	✅
Déploiement au push depuis un dépôt Git pour les Containers, Deployments, Compose et Pages ; Build Workers isolés	Prêt	—	—	✅	✅
Accès des clients Docker externes au registre interne	Prêt, sur activation	—	—	✅	✅
Workload Availability multinœud (Container, Deployment, Compose)	Prêt	—	—	✅	✅
Groupes d’ingress : Routes, domaines, Pages et page de statut servis par plusieurs nœuds Ingress	Prêt	—	—	✅	✅
Bases de données et stockage objet managés sur plusieurs serveurs, avec basculement automatique ou manuel	Prêt	—	—	✅	✅
Analyse des vulnérabilités des builds Git et politique d’admission	Prêt	—	—	✅	✅
Journalisation structurée	Prêt, sur activation	—	—	✅	✅
Export du journal d’audit	Prêt	—	—	✅	✅
Guided Onboarding and Configuration Review	Avantage du plan	—	—	✅	✅
PKI interne	Prêt	—	—	—	✅
Export de l’audit vers un SIEM	Prêt, sur activation	—	—	—	✅
Contact technique dédié	Avantage du plan	—	—	—	✅
Assisted Deployment and Migration	Avantage du plan	—	—	—	✅

Nouveautés de 2.12 : les Apps avec tous les plans, et les bases de données et le stockage objet managés sur plusieurs serveurs en Business et Enterprise, y compris les paires répliquées avec basculement manuel. Les Apps ne vérifient jamais la licence : une app, ses environnements, la promotion, l’arrêt et le coupe-circuit fonctionnent de la même manière avec tous les plans, tandis que chaque ressource d’une app conserve sa propre exigence de plan. Les connexions de stockage, le stockage objet managé ainsi que la sauvegarde et la restauration des bases de données sont des nouveautés de 2.11 ; Workload Availability (HA) reste disponible en Business et Enterprise. L’export de configuration d’Opfield pour le transfert vers une autre instance est disponible en 2.12 avec tous les plans. SMB n’est pas un type de connexion de stockage pris en charge.

Voir Workload Availability pour les prérequis et les limites de la HA, et Mises à jour et sauvegardes pour les procédures de reprise manuelles actuelles.

Feuille de route

Les fonctionnalités ci-dessous ne figurent pas encore dans le produit ; la matrice ci-dessus les omet donc. Chacune indique les plans auxquels elle est destinée. Une version cible est une estimation ; un élément marqué Prévu n’a pas encore de version cible.

Fonctionnalité	Plans prévus	Cible
CLI Opfield générale pour les terminaux et la CI/CD	Community, Personal, Business, Enterprise	2.13
Démon de gestion Bastion / SSH	Business, Enterprise	2.14
Analyse plus large des vulnérabilités et de la sécurité des charges de travail	Business, Enterprise	Prévu
Mise à l’échelle automatique sur métriques	Business, Enterprise	Prévu
Plusieurs instances d’une même charge de travail sur une machine	Business, Enterprise	Prévu
Correspondance des groupes OIDC et provisionnement SCIM	Enterprise	Prévu

L’analyse des vulnérabilités des builds Git est déjà disponible et est distincte de l’analyse plus large des charges de travail. Le système de plugins est une infrastructure du cœur d’Opfield encore inachevée, et non une fonctionnalité de plan ; son calendrier provisoire n’est pas antérieur à 2.20, sans date de sortie engagée.

Application des droits

Les fonctionnalités payantes disponibles sont appliquées aux frontières des opérations côté serveur comme dans la Console. REST, OAuth, MCP, AI Workspace, les workers d’arrière-plan et les points de terminaison publics de jetons ne contournent pas les vérifications de droits.

Un droit manquant échoue sans supprimer les ressources existantes. Les vérifications du cœur public d’Opfield renvoient LICENSE_ENTITLEMENT_REQUIRED (HTTP 403). Les zones implémentées par le cœur commercial — par exemple les bases de données, le stockage, les sauvegardes, GitLab, Pages et la PKI destinée aux utilisateurs — sont masquées dans la Console avec un plan qui ne les inclut pas — en ouvrir une par son adresse affiche l’en-tête de la page avec un avis relatif au plan — et sont indisponibles via l’API jusqu’à ce que le plan et le cœur requis soient actifs. Un refus lié au plan n’apparaît jamais sous forme de message d’erreur : un chargement de page reste silencieux, et une action ouvre la boîte de dialogue du plan. Les quotas de plan atteints renvoient LICENSE_QUOTA_EXCEEDED (HTTP 409) tout en préservant les enregistrements actuels. Une incohérence de politique protégée échoue de manière fermée plutôt que de supposer un plan plus permissif.

Les quotas Community de nœuds gérés, d’utilisateurs et de groupes de permissions personnalisés ne sont vérifiés que lorsque vous créez l’un d’eux, lorsqu’un utilisateur est provisionné à sa première connexion via OIDC ou lorsqu’un utilisateur supprimé est restauré. Le décompte des nœuds inclut les nœuds en attente et hors ligne. Les nœuds, utilisateurs et groupes qui dépassent déjà un quota — par exemple après une rétrogradation ou une mise à niveau depuis 2.10 — continuent de fonctionner et ne sont jamais supprimés ni désactivés. Les vérifications de droits lisent l’état de licence mis en cache dans l’installation ; une opération individuelle n’attend donc jamais le service de licences.

Cœur commercial

Les plans Community et payants exécutent les mêmes images Opfield. Les fonctionnalités payantes sont livrées sous la forme d’un cœur commercial signé séparément, qu’Opfield télécharge auprès du service de licences pour une installation qui détient ou a détenu une activation payante, et qu’il vérifie avant utilisation : la signature, la version exacte d’Opfield, les tailles de fichiers et les empreintes doivent correspondre. Opfield ne charge le cœur qu’à son démarrage.

L’activation d’une clé payante dans Settings > General > License prépare le cœur correspondant via le mécanisme de mise à jour signé pendant qu’Opfield continue de servir les requêtes, puis redémarre Opfield pour le charger. Si la préparation échoue, la clé reste activée et Enable paid features la relance. Une clé activée pendant l’assistant de configuration initiale ne prépare pas le cœur ; ouvrez ensuite les paramètres de licence et sélectionnez Enable paid features. Lorsqu’une clé valide est présente mais que le cœur est manquant ou refusé, la Console signale que les fonctionnalités payantes ne sont pas prêtes, ce qui est différent d’un plan insuffisant, et l’infrastructure existante continue de fonctionner.

Mettre à niveau une installation Community depuis 2.10

2.11 applique immédiatement après la mise à niveau les nouvelles limites et la nouvelle liste de fonctionnalités de Community :

• Les nœuds, utilisateurs et groupes au-delà de 25, 3 et 1 continuent de fonctionner, mais vous ne pouvez pas en ajouter.
• Les connexions aux bases de données externes, les connecteurs GitLab et les données de Plan Mode existants sont conservés dans la base de données, mais ne peuvent pas être ouverts en Community. La supervision des bases de données et la synchronisation GitLab s’arrêtent.
• Les autres fonctionnalités Community, notamment Docker, l’ingress, TLS, la supervision, l’identité, l’automatisation par API et MCP, le chat d’AI Workspace et Opfield Inference, continuent sans changement.

L’application d’une clé Personal ou supérieure rétablit l’accès aux enregistrements conservés.

Les clés payantes émises avant 2.11 conservent leur plan. Les clés Personal, Business et Enterprise utilisant un ancien format de droits incluent les nouvelles fonctionnalités de connexions de stockage, de connexions aux bases de données externes, de stockage managé, de liens entre conteneurs, de volumes sur image disque, ainsi que Plan Mode, Scenarios et Sandboxes d’IA.

Communication avec le service de licences

Opfield conserve une liste signée des adresses du service de licences et utilise celle qui répond. Autorisez https://license.opfield.dev dans une liste d’autorisation du trafic sortant, ainsi que l’hôte de mise à jour https://get.opfield.dev. Pour faire transiter les requêtes de licence par une adresse qui vous est propre, comme un proxy sortant, définissez LICENSE_SERVICE_URL dans le fichier .env d’Opfield (plusieurs adresses séparées par des virgules) et redémarrez Opfield ; cette adresse est essayée en premier. Opfield ne contacte le service de licences qu’aux fins suivantes :

Requête	Quand	Données envoyées
Enregistrer l’installation	Au premier démarrage, ou lorsque le jeton d’installation stocké n’est plus valide	Identifiant de l’installation, un nonce d’enregistrement généré localement, nom de l’installation, version d’Opfield et version du schéma des droits
Signal de présence	Peu après le démarrage, puis toutes les 15 minutes avec une clé payante ou toutes les 30 minutes en Community, et lorsqu’un administrateur sélectionne une vérification manuelle	Jeton d’installation, nom de l’installation, version d’Opfield et version du schéma des droits
Activer ou désactiver une clé	Lorsqu’un administrateur applique ou retire une clé payante	Jeton d’installation et version du schéma des droits, plus la clé payante lors de l’activation
Autoriser une version	Avant une mise à jour d’Opfield et lors de l’activation des fonctionnalités payantes	Jeton d’installation, version cible d’Opfield et version du schéma des droits
Télécharger le cœur commercial	Pendant une mise à jour ou l’activation des fonctionnalités payantes d’une installation qui détient ou a détenu une activation payante	Jeton d’installation, version cible d’Opfield, identifiant de version, chemin du fichier et version du schéma des droits

Chaque requête transporte aussi un nonce de requête aléatoire et les identifiants des clés de signature épinglées par la version d’Opfield. L’identifiant de l’installation est un identifiant aléatoire généré par l’installation. Le nom de l’installation est le nom d’hôte de l’URL publique configurée d’Opfield, ou le nom d’hôte du serveur lorsqu’aucune URL publique n’est enregistrée. Opfield n’envoie ni configuration de l’infrastructure, ni contenu des ressources, ni secrets, ni journaux, ni nombre d’utilisateurs ou de ressources, ni prompts, ni réponses des modèles. La clé de licence, le jeton d’installation et le nonce d’enregistrement sont stockés chiffrés dans l’installation. Les installations Community restent utilisables pendant que l’enregistrement est en attente ou que le service est injoignable. L’activation d’une clé payante, ainsi que la mise à jour d’une installation qui détient ou a détenu un plan payant, exigent que le service soit joignable ; une mise à jour refusée ou en échec laisse la version actuelle en fonctionnement. Une installation Community sans clé, sans plan payant et sans cœur commercial se met à jour même lorsque le service est injoignable, car elle ne télécharge rien de privé. Voir Mises à jour, sauvegardes et restauration.

États de licence signés

Le service de licences signe avec Ed25519 chaque état de licence qu’il renvoie — pour l’enregistrement, les signaux de présence, l’activation, la désactivation et l’autorisation de version. La signature couvre l’identifiant de l’installation, l’objet de la requête, le nonce de requête, l’heure d’émission et l’état complet, y compris le plan, les droits, l’expiration et l’échéance de la période de grâce. Les versions d’Opfield épinglent les clés publiques du service et n’appliquent un état que lorsque :

• la signature est valide pour une clé épinglée ;
• l’état a été signé pour cette installation, ainsi que pour l’objet et le nonce de cette requête, de sorte qu’une réponse capturée ne peut ni être rejouée ni être utilisée par une autre installation ;
• l’heure d’émission se situe à moins de 15 minutes de l’horloge locale.

Une réponse non signée, falsifiée, rejouée, étrangère ou périmée est traitée comme un service injoignable : le dernier état signé valide reste en vigueur et la période de grâce hors ligne continue à partir de son heure d’émission. L’enregistrement et l’activation échouent plutôt que de stocker des identifiants issus d’une réponse non signée, et un téléchargement du cœur commercial n’est autorisé que par un état signé pour cette requête. Opfield stocke les états signés et les revérifie chaque fois qu’il lit la licence ; modifier la licence en cache dans la base de données ne peut donc pas élever le plan. Gardez l’horloge de l’hôte Opfield synchronisée ; une horloge décalée de plus de 15 minutes fait paraître chaque réponse périmée.

Rétrogradation et expiration

Un plan payant peut prendre fin par expiration, rétrogradation vers un plan inférieur, indisponibilité du service de licences, révocation, transfert de la clé vers une autre installation ou désactivation explicite. Jusqu’à la fin de la période de grâce correspondante, tout continue de fonctionner comme avant, y compris la transmission vers le SIEM et l’accès des clients Docker externes au registre interne.

Cause	Période de grâce	À compter de
Expiration	24 heures en Personal, 3 jours en Business, 7 jours en Enterprise	La date d’expiration
Service de licences injoignable	100 jours, jamais au-delà de la période de grâce d’expiration	L’heure d’émission du dernier état de licence signé valide
Rétrogradation vers un plan payant inférieur	La période de grâce du plan supérieur : 24 heures, 3 jours ou 7 jours	Le dernier état signé qui indiquait encore le plan supérieur
Révocation, transfert vers une autre installation, désactivation, clé invalide	Aucune	—

Pendant la période de grâce d’expiration, l’état de la licence est Expired — grace period et le tableau de bord affiche un avertissement ; tant que le service est injoignable, il est Licensed with warning. Opfield évalue les échéances localement et n’attend pas un nouveau signal de présence.

Après la période de grâce — ou immédiatement après une révocation, un transfert ou une désactivation —, les nouvelles actions utilisent les droits Community, tandis que les ressources payantes existantes conservent un droit de continuité correspondant au plan payant le plus élevé qu’a détenu l’installation, tel que prouvé par un état de licence signé stocké :

• Continue de fonctionner : toutes les charges de travail existantes et le plan de données — Containers, Deployments, projets Compose, Routes, Secure Links, liaisons aux bases de données et au stockage managés, relais, déploiements Pages publiés, listes de révocation de certificats de la PKI interne et ingestion des journaux structurés. Les sauvegardes planifiées existantes, leur conservation, Run now, l’annulation et les restaurations dans des bases existantes continuent. Workload Availability continue de réparer et peut démarrer, arrêter et redémarrer les charges de travail existantes. Les bases de données et le stockage sur plusieurs serveurs continuent de basculer, et vous pouvez toujours changer de primaire, reconstruire une copie, retirer un serveur et désactiver Availability. Les connecteurs GitLab existants continuent de se synchroniser. Pour les ressources payantes existantes, vous pouvez toujours les consulter, lire les journaux et la supervision, tester les connexions, afficher et faire tourner les identifiants, révoquer et exporter des certificats, et les supprimer.
• Est suspendu : la transmission vers le SIEM et l’émission de jetons pour l’accès des clients Docker externes au registre interne. Leurs paramètres, le point d’entrée externe du registre et l’historique d’envoi SIEM sont conservés, et les enregistrements déjà en file pour le SIEM sont livrés après le renouvellement ; les événements d’audit qui surviennent pendant la suspension ne sont pas mis en file. Les deux reprennent au renouvellement sans reconfiguration.
• Est bloqué : la création de ressources payantes, la modification de la configuration des ressources payantes existantes, l’écriture de données via les explorateurs de bases de données et de stockage objet (la suppression de lignes, de clés, d’objets et de buckets reste possible), la restauration d’une sauvegarde dans une nouvelle base managée, et les opérations réservées aux plans payants comme l’export et l’import d’archives, la migration, l’export de l’audit et les builds à partir de sources Git. Les créations au-delà des limites Community de nœuds, d’utilisateurs et de groupes sont refusées. Ces opérations renvoient LICENSE_ENTITLEMENT_REQUIRED ou LICENSE_QUOTA_EXCEEDED.

Opfield ne modifie jamais la configuration stockée, ne désactive pas de modules et ne supprime pas de ressources gérées parce qu’un plan a pris fin. Le renouvellement ou la réactivation d’une clé rétablit toutes les opérations payantes sans reconstruire l’infrastructure existante. Les Paid Key Terms déterminent si vous pouvez continuer à exploiter des ressources payantes après une révocation ; Opfield lui-même ne les arrête pas.

Une installation continue de recevoir des mises à jour après la fin de son plan payant. Une installation qui détient ou a détenu une activation payante — y compris expirée, révoquée, transférée ou désactivée — reçoit le cœur commercial correspondant avec chaque mise à jour ; ses ressources payantes existantes continuent donc de fonctionner selon ces règles. Une installation qui n’a jamais détenu de plan payant se met à jour en tant que Community.

Vérifications opérationnelles

• Vérifiez l’identifiant de l’installation et l’instance active prévue avant d’appliquer une clé.
• Surveillez l’expiration et l’échéance locale de la période de grâce.
• Testez les opérations premium requises avant un lancement en production.
• Consignez les opérations qui seront bloquées après la période de grâce, et le fait que la transmission vers le SIEM et les jetons des registres externes sont suspendus.
• Rétablissez le droit avant de remplacer manuellement des ressources conservées.

N’utilisez pas l’ancienne terminologie homelab et ne déduisez pas la disponibilité des fonctionnalités à partir de textes tarifaires, de captures d’écran ou d’une autre version d’Opfield.

Choisir et changer de plan

Constituez un petit registre de décision listant les fonctionnalités requises, le nombre de ressources attendu, les environnements, les contrôles de conformité et la conséquence d’une indisponibilité temporaire des droits. Testez les opérations réelles sur la version cible avant l’approbation de l’achat. Le nom d’une fonctionnalité dans un contrat ou une matrice ne prouve pas que l’installation dispose de la capacité de nœud ou du fournisseur externe requis.

Avant une rétrogradation, une expiration ou un transfert vers une autre installation :

1. identifiez les ressources premium et l’automatisation qui cesseront d’accepter de nouveaux travaux ;
2. préservez les paramètres de source, les artefacts de build, la PKI, la journalisation et la configuration SIEM ;
3. confirmez quelles ressources en cours restent opérationnelles et quelle période de grâce s’applique ;
4. communiquez l’échéance opérationnelle et son responsable ;
5. rétablissez le droit et confirmez que la transmission SIEM et l’accès aux registres externes suspendus ont repris ;
6. vérifiez les chemins clients plutôt que de supposer que la configuration précédente a repris.

Ne supprimez pas des ressources conservées pour « faire disparaître » un avertissement de droit. Leur état conservé constitue le chemin de reprise une fois le bon plan rétabli.

Limites de la licence

La licence Opfield couvre l’installation Opfield active conformément à sa clé et au contrat. Les identifiants, quotas ou abonnements des fournisseurs externes — DNS cloud, gestion de sources, registres, e-mail, IA ou autres services hébergés — restent distincts. De même, la consommation affichée par Opfield Inference est une comptabilité opérationnelle et doit être rapprochée des données du fournisseur pour les décisions commerciales.

Le code source actuel, publié sous le nom Opfield par son Concédant, Alexandr Slavinschii ([email protected]), est disponible sous PolyForm Perimeter 1.0.1. PolyForm Perimeter autorise l’utilisation, la modification et la redistribution à des fins non concurrentes, y compris l’usage interne ordinaire en entreprise. La finalité exclue est la fourniture à des tiers d’un produit commercialisé comme substitut à Opfield, que ce soit sous forme de logiciel, de service hébergé, de portage ou d’offre gratuite.

Une clé Personal, Business ou Enterprise débloque les fonctionnalités et limites des plans payants ; elle n’est pas requise du seul fait qu’une organisation utilise Community en interne. Une clé ordinaire n’accorde pas de droits OEM, de marque blanche, de revente, de service hébergé concurrent ou d’autre produit de substitution. Ces usages nécessitent un accord écrit distinct avec le Concédant actuel. Après l’expiration ordinaire d’une clé, les conditions de continuité de la clé préservent les ressources des plans payants configurées avant l’expiration, tout en bloquant les nouvelles créations et extensions réservées aux plans payants.

Chaque version officielle est aussi accompagnée du Product Continuity Grant. Il prend effet lorsque, pendant 12 mois consécutifs, aucune nouvelle version n’est publiée alors que le service de licences est indisponible, lorsque le Concédant annonce la fin d’Opfield, ou lorsque le Concédant décède ou n’est plus en mesure d’agir. Le service de licences est le service de licences que le Concédant exploite pour Opfield, à toute adresse qu’il publie ; il est considéré comme disponible tant que l’une de ces adresses répond. Dès lors, le code source de la dernière version, y compris le cœur commercial, est mis à la disposition de tous sous licence MIT, et le détenteur d’une clé valide à ce moment conserve aussi une licence perpétuelle d’utilisation et d’auto-hébergement de cette version pour son plan, et peut l’exécuter sans le service de licences. Le Grant lui-même fait foi quant à sa portée, ses conditions et ses exclusions. Les plans payants sont régis par les Opfield Paid Key Terms.