Transfert maîtrisé de composants logiciels (images de conteneurs, charts Helm, modèles, fichiers) entre zones réseau cloisonnées, jusqu'aux environnements totalement isolés (air-gap). Cette édition consolide le périmètre initial et les fonctionnalités issues de l'étude de complétude de la conception, ordonnés par dépendances en sept jalons démontrables.
This roadmap is currently maintained in French. All other project documents — SRS, ADRs, format specification — are in English; an English version of the roadmap will follow with the bilingual documentation work (7.2).
Chaque fonctionnalité est décrite trois fois — pour l'équipe technique, en langage courant, et par ce qu'elle apporte au métier. Chacun lit sa colonne : les trois disent la même chose. Numérotation : 1.4 périmètre initial du jalon, R-12 fonctionnalité issue de l'étude de complétude de la conception — citez ces numéros tels quels dans vos retours.
Verrouiller tout ce qui est impossible à changer plus tard : le format des recipes, l'organisation du stockage, et la chaîne de fabrication de Tobby lui-même.
/healthz /readyz, métriques OpenMetrics, arrêt gracieux.distribution v3), stockage organisé selon la convention de relocalisation (ADR-0013) : chaque artefact rangé sous le nom de sa registry d'origine (docker.io/bitnami/wordpress → <zone>/docker.io/bitnami/wordpress).recipe.tobby.dev/v1alpha1 : kinds Recipe/Retriever, 4 types d'ingrédients, versions semver, digests obligatoires à la publication, schémas JSON stricts, SDK Go de validation. Publiée en licence Apache-2.0, dans un dépôt séparé.go test -race, -count=2 anti-flaky, couverture minimale par paquet — plus stricte sur les chemins de sécurité), lint strict (golangci-lint, zéro dérogation), intégration contre registries et IdP réels conteneurisés (aucun mock du protocole OCI), e2e cœur à chaque PR, e2e étendu en nightly. Document OpenVEX régénéré régulièrement sur les livrables de Tobby.Mettre une interface réelle entre les mains des futurs administrateurs et exploitants, sur un premier parcours complet — pour valider l'ergonomie avant de construire le reste par-dessus.
/api/v1, spécification OpenAPI servie par l'instance, parité stricte UI ↔ API (tout ce que fait l'un est faisable par l'autre).Le cœur du système : transformer une recipe signée en contenu vérifié dans le dépôt local — automatiquement, intégralement, et de façon rejouable sans effet de bord.
ContainerImage (multi-arch, sélection de plateformes), HelmChart, OCIArtifact (modèles IA, bases de données…), FileSet (fichiers empaquetés en image OCI, montables ou extractibles). Copie bit-exacte, streaming sans charger les blobs en mémoire.12.x, ^, ~, >=) résolues en tag + digest ; statut par ingrédient avant tout transfert : new / outdated / up-to-date ; idempotence (2ᵉ exécution = zéro transfert)./files/<fileset>/…) du contenu des FileSets vérifiés du dépôt local : activation par FileSet, requêtes Range supportées, garde-fous anti-évasion de chemin, accès anonyme opt-in pour le bootstrap. Aucune surface d'upload — seuls les fichiers arrivés par le canal signé sont servis.Premier mode complet : Tobby en service continu entre deux zones, qui maintient automatiquement la registry de destination au niveau voulu par le retriever.
docker login standard). Désactivation possible uniquement par choix explicite, avec bannière permanente.Second mode complet : préparer un média physique, le transporter, et pousser son contenu en zone isolée — avec des garde-fous à chaque étape pour un exploitant non expert.
Compléter la chaîne de contrôle : analyse de vulnérabilités avec politique configurable, et raccordement aux annuaires d'identité de l'entreprise.
Amener le produit complet au niveau « version 1.0 » : finition de l'interface, documentation bilingue, durcissement, et validation formelle des deux cas d'usage avec le client.
Fonctionnalités volontairement hors du socle 1.0, avec un contournement propre en attendant. Toutes sont compatibles avec le format et l'architecture livrés — aucune ne casse l'existant.