Ce que nous livrons, semaine après semaine.

La sécurité d'exécution, l'isolation renforcée, Trino public ou privé

Vous voyez ce que font vraiment vos conteneurs, et l'isolation entre organisations ne repose plus sur notre seul code.

• Un agent de sécurité tourne sur chaque nœud. Il observe ce que font réellement les conteneurs, et chaque alerte indique l'organisation concernée.
• Toutes les alertes sont au même endroit. Une page du centre de contrôle rassemble les alertes de sécurité de la flotte entière.
• L'isolation passe dans Kubernetes. Une requête qui essaierait de contourner la plateforme est refusée directement par l'API Kubernetes, et plus seulement par notre code.
• Vous choisissez d'exposer Trino ou non. Le Trino d'un Data Dock est public ou privé, et vous passez de l'un à l'autre d'un clic depuis la console.
• Le réseau est fermé par défaut. Les accès à Trino, aux pipelines et aux bases PostgreSQL managées sont protégés sans que vous ayez une règle à écrire.
• Vous choisissez vos bases de vulnérabilités. Vous indiquez celles que l'analyse des images doit utiliser, y compris sur une installation coupée d'internet.
• Les images des composants tiers se configurent. Vous choisissez le registre depuis lequel elles sont téléchargées, dans le chart d'installation.

Les ports de sortie des runners, les objets d'un bucket en masse

Vos builds joignent enfin les dépôts qui n'écoutent pas sur le 443, et vous rangez un bucket sans l'ouvrir fichier par fichier.

• Vous ouvrez un port précis. Un runner peut atteindre un dépôt apt sur le port 80 ou un registre interne sur le port 5000. Avant, seul le 443 passait.
• Ou vous autorisez tout. Un pool de runners peut sortir sans aucune restriction, pour les builds qui téléchargent depuis trop de domaines pour tenir dans une liste.
• Un bucket se manipule comme un tableau. Tri par colonne, recherche, sélection multiple, suppression en masse et pagination.

Les liens entre services en Terraform, le centre de contrôle refondu

Vous décrivez en Terraform quels services ont le droit de s'appeler, au même endroit que le reste de votre infrastructure.

• Vous déclarez les autorisations d'appel en Terraform. La ressource hyperfluid_service_link indique quels services ont le droit de s'appeler, dans les mêmes fichiers que le reste de votre infrastructure.
• Une application expose plusieurs ports. Autant qu'elle en a besoin, et Terraform peut la désigner par son nom court.
• Le centre de contrôle ressemble à la console. Rail de navigation repliable, fil d'Ariane, et une palette qui ouvre n'importe quelle page en deux frappes.

Le journal d'audit se lit dans la console

Vous savez qui a demandé quoi, sur quelle ressource, et ce qui a été décidé, sans écrire une seule requête.

• Chaque décision d'accès est lisible. La page Vauban montre qui a demandé, sur quelle ressource, ce qui a été décidé, et la règle qui a tranché.
• Les requêtes SQL sont détaillées. Vous voyez les schémas, les tables et les colonnes touchés, avec les filtres de lignes et les masques appliqués.
• Vous filtrez la liste, puis vous ouvrez une ligne. Par action, par ressource, par décision ou par type d'événement, et chaque ligne montre la requête complète.

Slurm en libre-service, les modèles d'IA tiers, GitLab

Vous montez un cluster de calcul sans ticket, vous appelez des modèles tiers avec votre clé habituelle, et vous codez sur un dépôt GitLab.

• Vous créez un cluster Slurm vous-même. Vous choisissez ses partitions, la taille de ses nœuds et son nœud de connexion en ssh. Aucun ticket à ouvrir.
• La comptabilité des jobs est en option. Vous récupérez l'historique avec sacct et vous posez des limites de QOS par partition.
• Les modèles tiers rejoignent le catalogue. Chacun avec sa fenêtre de contexte et son prix, appelé par le même endpoint et la même clé que vos modèles locaux.
• Des crédits pour les payer. Un solde, le relevé de ce qui a été accordé et consommé, et un avertissement avant qu'un appel soit refusé.
• Vous travaillez sur un dépôt GitLab. Depuis une workstation, puis vous ouvrez la merge request et vous la suivez depuis la console.
• Une clé d'API ne peut plus monopoliser le débit. Vous fixez son plafond vous-même, dans la limite autorisée par la plateforme.
• hfctl gère les docks de calcul. Vous en créez un, vous le listez, vous le redimensionnez et vous vous y connectez depuis le terminal.

Douze connecteurs SQL, les compétences d'agent, l'admission control

Vous interrogez des bases que la plateforme n'héberge pas, et vos agents changent de compétences sans redémarrer.

• Douze bases de plus dans le catalogue SQL. MySQL, MariaDB, ClickHouse et la famille JDBC : un catalogue peut pointer vers une base que nous n'hébergeons pas.
• Les compétences d'agent s'éditent dans la console. Une modification atteint les workstations déjà démarrées, sans redémarrage.
• La console fait ce que faisait le terminal. Elle montre quelles compétences ont répondu, un sélecteur de tables groupé par schéma, et le temps de réflexion sous chaque réponse.
• hfctl parle aux agents. Vous les gérez, vous éditez leurs compétences et vous discutez avec eux depuis le terminal.
• hfctl pilote les pipelines. Vous en créez un, vous le déclenchez et vous suivez son exécution jusqu'à la fin.
• La passerelle IA sait dire non. Une politique d'admission décide quels appels elle accepte, et refuse les autres explicitement.

Les liens entre services en ligne de commande, la maintenance tracée

Vous déclarez depuis le terminal quel service peut en appeler un autre, et vous savez ce que chaque maintenance a fait à vos tables.

• hfctl déclare les liens entre services. Vous dites quel service a le droit d'en appeler un autre, sans passer par la console.
• Chaque maintenance Iceberg laisse une trace. Elle a son identité, ses métriques de résultat et ses logs, donc vous savez ce qui a tourné et ce que ça a donné.
• Les clés de modèle vivent dans le coffre. Le pipeline désigne la clé au lieu de la porter en clair.

Des catalogues vers vos bases existantes, les ports des workstations

Vous interrogez vos bases là où elles sont, sans les déplacer, et votre workstation publie ses ports toute seule.

• Un catalogue peut pointer ailleurs. Vers une base que la plateforme n'héberge pas, avec un formulaire d'identifiants propre à chaque connecteur.
• Les ports d'une workstation s'ouvrent d'un clic. N'importe quel port servi par votre code apparaît de lui-même dans la console.
• Une compétence d'agent reste dans son périmètre. Elle nomme les tables qu'elle a le droit de lire, et sa recherche ne va pas plus loin.
• Une carte montre qui parle à qui. Les liens déclarés entre services se lisent service par service.

Les requêtes planifiées, le support intégré, le GPU gouverné

Vous planifiez une requête et vous la laissez tourner, vous ouvrez un ticket sans quitter la console, et le GPU se pilote comme une ressource.

• Une requête peut tourner sans vous. Vous l'écrivez, vous la planifiez, elle s'exécute en arrière-plan avec sa propre autorisation.
• Le support est dans la console. Vous ouvrez un ticket depuis l'interface, il arrive directement à l'équipe plateforme.
• Le GPU devient une ressource gouvernée. Droit d'usage, budget et pool, accordés organisation par organisation.
• Une application sous-dimensionnée se signale. Le p95 CPU mesuré sur sept jours montre celle qui réserve plus qu'elle n'utilise.

TLS sur le protocole PostgreSQL, permissions au niveau objet

Vos connexions aux API data sont chiffrées jusqu'au client, vos autorisations descendent jusqu'à l'objet, et vous dimensionnez une application avec un seul nombre.

• Les connexions aux API data sont chiffrées jusqu'au client.
• Les autorisations sur les buckets descendent jusqu'à l'objet.
• Un seul nombre de vCPU par palier, dont dérivent la réservation et le plafond.

Secrets privés, réseau des workstations, journal des nouveautés

Vous rangez vos secrets dans une zone qui n'appartient qu'à vous, vous contrôlez le réseau de vos workstations, et vous clonez plusieurs dépôts dans la même.

• Un chemin de secrets réservé par utilisateur, visible de son seul propriétaire.
• Onglet réseau sur les workstations, avec listes d'autorisation personnalisées.
• Plusieurs dépôts clonés dans une même workstation.
• Les nouveautés de la plateforme s'affichent directement dans la console.

Un namespace Kubernetes par environnement

• Chaque environnement reçoit son propre namespace Kubernetes, activable organisation par organisation.
• Les ressources d'un environnement sont isolées des autres, jusqu'au réseau.

Alerting de capacité, conversations d'agents, démonstration FHIR

Vous laissez un agent répondre à plusieurs conversations en parallèle, et vous êtes prévenu avant que la capacité ne manque.

• Alertes de capacité, avec plan de notification dans la console.
• Les agents répondent au courrier en parallèle, sérialisés par conversation.
• Une démonstration FHIR complète en une commande.

Inscription en essai libre, boîtes mail managées pour les agents

Vous ouvrez un essai sans nous solliciter, et vos agents reçoivent leurs propres adresses de courrier.

• Inscription publique en essai, avec file de validation dans le backoffice.
• Des boîtes mail hébergées par la plateforme pour vos agents.

Consommation de tokens par modèle et par principal

• Graphiques de consommation de tokens par modèle, sur la période de votre choix.
• Même vue par principal : utilisateurs et comptes de service, côte à côte.
• De quoi savoir précisément qui consomme quoi, modèle par modèle.

Backoffice d'administration de la plateforme

Vous administrez la plateforme depuis un backoffice séparé de la console de vos organisations.

• Un backoffice dédié à l'administration de la plateforme, séparé de la console des organisations.
• Création d'organisations, gestion des comptes, suivi transverse.
• Bâti sur le même système de design que la console.

Droits en masse, rôles et permissions de groupe

• Modification en masse des droits accordés directement à un utilisateur.
• Gestion des rôles et des permissions au niveau du groupe, plus seulement de la personne.
• Suppression d'un schéma Iceberg depuis l'interface.

Mesure des tokens par principal, utilisateurs comme comptes de service

• La consommation de tokens est attribuée à chaque principal : utilisateur ou compte de service.
• Le modèle OCR d'une automatisation se configure à la création : clé, nom et URL.

La permission manquante s'affiche sur un refus

• Un refus d'accès nomme la permission qui manquait, dans la console comme dans hfctl.
• Plus besoin de deviner quel droit demander à son administrateur.

Import et export des variables d'environnement des applications

• Export des variables d'environnement d'une application conteneurisée.
• À l'import, la syntaxe secret: de hfctl est reconnue : une variable peut pointer vers le coffre.
• hfctl signale qu'une mise à jour est disponible après une commande.

Consommation IA en temps réel, séries denses et plages rapides

• Séries de consommation plus denses, plages rapides et contrôle du rafraîchissement.
• Le suivi temps réel devient lisible sur des fenêtres courtes.

Inventaire GPU du cluster, tableau de bord de consommation

Vous voyez le parc GPU disponible, son usage réel, et l'historique de ce que vous avez consommé.

• Un onglet Ressources sur la passerelle IA : inventaire et usage des GPU.
• Modes temps réel et historique sur le tableau de bord de consommation.

Passerelle IA : mesure des tokens et modèles externes

Vous mesurez précisément votre consommation d'inférence, et vous exposez des modèles servis hors de la plateforme.

• Toute l'inférence passe par la passerelle, pour une mesure fiable de l'usage.
• Des modèles servis hors plateforme, exposés et découverts automatiquement.
• La console passe à Tailwind CSS v4.

Fil d'Ariane sur chaque page de détail, OCR local accéléré

• Un fil d'Ariane sur chaque page de détail : accueil, section, ressource, onglet.
• OCR local accéléré par une lecture directe de la couche texte des PDF, quand elle existe.

Airflow managé, conteneurs OCI dans les workstations

Vous provisionnez Airflow depuis la console, et vous lancez des conteneurs directement dans votre workstation.

• Airflow managé, provisionné et supervisé depuis la console.
• Des conteneurs OCI utilisables directement dans une workstation.
• Un playground OCR compatible PDF.

Une console repensée en catalogue de services

Vous retrouvez vos services dans un catalogue, avec vos favoris épinglés. Les fonctionnalités ne changent pas, la façon de les atteindre change entièrement.

• Navigation en catalogue de services, avec favoris épinglables.
• Le SQL Engine adopte la même grammaire d'interface que les conteneurs et les bases.
• Les agents posent une question de clarification quand la demande est ambiguë.
• Contrat d'embeddings précalculés : le pipeline calcule, Bifrost recopie.

Agents accessibles par courrier électronique, requêtes gouvernées en CLI

Vous écrivez à un agent comme à un collègue, il répond dans le fil. Et vous interrogez vos données depuis le terminal, sous le contrôle de vos politiques.

• Un agent lit une boîte mail et répond dans le fil de conversation, en IMAP et SMTP.
• Un assistant de configuration guide le branchement de la boîte, fournisseur par fournisseur.
• hfctl query et hfctl search : interroger le data plane depuis le terminal, sous le contrôle des politiques.

Fournisseurs d'identité par organisation, playground OCR dédié

• Chaque organisation peut brancher son propre fournisseur d'identité, avec connexion sur invitation.
• Un playground OCR dédié aux modèles vision-langage.
• Explorateur de logs : histogramme des volumes, suivi en direct et export.

Rétention des logs par organisation, filtres avancés

• La rétention des logs se règle organisation par organisation.
• Filtres avancés sur l'explorateur de logs.

Logs embarqués, et le runtime des agents câblé de bout en bout

• Un moteur de logs embarqué dans la plateforme, avec sa page de recherche dans la console.
• Le runtime des agents est câblé de bout en bout : de l'assistant de création jusqu'au chat.
• Gestion des sauvegardes d'une base existante, depuis la console comme depuis hfctl.

Agents IA définis par l'utilisateur, de bout en bout

Vous définissez vos propres agents IA, de leur déclaration jusqu'à la conversation.

• Des agents IA définis par l'utilisateur, de la déclaration à la conversation.
• Création d'une base PostgreSQL managée à partir d'une sauvegarde.
• Dashboards : variables, filtrage croisé, rafraîchissement automatique et widgets texte.
• Accès Kafka par compte de service, en OAuth.

Dashboards pilotés par l'IA, gestion des topics Kafka

Vous construisez vos dashboards avec l'IA, et vous gérez vos topics Kafka depuis l'interface.

• Des dashboards pensés pour l'IA, construits dans la console.
• Gestion des topics Kafka depuis l'interface.
• Le SQL Engine gagne sa propre section : navigation par colonne, statistiques de cluster et onglet d'accès.

Playground des modèles partagés, portefeuille multi profils pour hfctl

• Playground et exemples de code pour les modèles partagés, avec l'URL de la passerelle.
• hfctl gère plusieurs profils d'authentification dans un même portefeuille.
• Une cible de sauvegarde par défaut sur chaque environnement.

Garde-fous et groupes dans Vauban, thème sombre dans la console

Vous posez des garde-fous par ressource et par groupe, et rien n'est exposé sur internet sans que vous l'ayez décidé.

• Vauban : niveaux d'accès par ressource, garde-fous et gestion par groupes.
• Thème clair et sombre, au choix, depuis le menu utilisateur.
• Les bases et les applications sont privées par défaut, l'exposition devient un choix explicite.
• hfctl gagne un groupe de commandes pour les caches clé-valeur.

Quotas PostgreSQL, zones de stockage par organisation

• Quotas de capacité sur les bases PostgreSQL managées.
• Zones de stockage Ceph activables par organisation.
• La console repère les variables d'environnement qui ressemblent à des secrets et propose de les ranger dans le coffre.

Interface de courrier entrant dans la console

• L'interface de courrier entrant arrive dans la console.
• Ergonomie des workstations revue.

Courrier entrant, quotas de capacité, secrets navigables

• Un transport de courrier entrant, côté plateforme.
• Import en masse des variables d'environnement, et sélecteur navigable dans l'arbre des secrets.
• Quotas de capacité sur les applications conteneurisées.

Provider Terraform servi par la console, vingt connecteurs de plus

• La console sert le provider Terraform Hyperfluid comme un registre.
• Vingt connecteurs de données ouvertes supplémentaires, dont data.gov.uk et SCB Suède.
• Thème de connexion Keycloak configurable par organisation.

Catalogue de données ouvertes filtrable

• Catalogue de données ouvertes filtrable, avec les métadonnées de chaque connecteur.
• Source d'image managée dans l'assistant de création d'application.

Vingt connecteurs de données ouvertes, français et européens

Vous croisez vos données avec vingt sources publiques françaises et européennes, sans écrire un script d'ingestion.

• Vingt connecteurs de données ouvertes : DREES, Ameli, Crossref, Zenodo, TfL, ONS et d'autres.
• Connecteurs français : data.gouv.fr, Enedis, DVF, GRDF, SNCF, RATP.
• hfctl se configure tout seul à partir du fichier de compte de service.
• Images de workstation allégées, et une base Rust.

Plan de contrôle Trino, orchestration Dagster, CI Forgejo

• Un plan de contrôle Trino : supervision, mise à l'échelle et gestion des catalogues.
• Orchestration Dagster, du CRD jusqu'à l'interface.
• Les jobs de CI Forgejo poussent vers le registre interne.
• Activation de Trino en un clic, dans une section SQL Engine dédiée.

Bifrost distribué, supervision embarquée, hfctl élargi

Vous montez en charge : Bifrost se distribue et s'autoscale, et vous supervisez la plateforme depuis la console.

• Bifrost devient un service à part entière, avec mise à l'échelle automatique.
• Un système de supervision embarqué, en production.
• PostgreSQL managé exposé à travers les catalogues Trino.

Modèles d'environnement pour les workstations, Source Control

• Des modèles d'environnement pour les workstations : CRD, catalogue et interface d'édition.
• Source Control arrive au catalogue, adossé à Forgejo.
• hfctl gagne les commandes storage et buckets.

Édition assistée par IA dans les workstations, premiers connecteurs ouverts

• Édition assistée par IA dans les workstations, à la manière d'un Cmd-K.
• Un modèle Qwen3 partagé, sans couplage à une organisation ni à une clé.
• Premier connecteur de données ouvertes : la Banque mondiale, vers une table Iceberg.
• Vauban passe du RBAC à l'ABAC pour l'accès à la console.

hfctl disponible pour macOS

• hfctl est distribué pour macOS, en plus de Linux.
• Détection du système dans le script d'installation.

Workstations : IDE éditable, LSP sans configuration, gestion de version

• L'IDE des workstations devient éditable, avec onglets multi-fichiers.
• Complétion, survol et navigation dans le code, sans configuration.
• Un onglet de gestion de version, avec l'indicateur de branche en direct.

hfctl, la ligne de commande Hyperfluid

Vous pilotez la plateforme au clavier, du service de modèles jusqu'aux logs d'une base.

• hfctl, la ligne de commande Hyperfluid, en implémentation complète.
• Commandes Sapience : service de modèles, inférence, modèles partagés et clés d'API.
• Invitations de membres depuis la console.
• Logs d'une base de données en flux, dans la console comme en CLI.

Runtime configurable pour les applications conteneurisées

• La classe d'exécution des applications conteneurisées se configure côté plateforme.

Persistance des applications, planification des connecteurs

• Volume persistant intégré pour une application conteneurisée.
• Planification cron configurable sur les pipelines de connecteurs.
• Test de récupération d'image et interface d'édition complète sur une application.

Stockage objet Ceph partagé par organisation

• Un stockage objet Ceph partagé par organisation, cloisonné par environnement.

Domaines personnalisés de bout en bout, fichiers montés dans les conteneurs

Vous servez vos applications sous vos propres noms de domaine, de la vérification jusqu'à la mise en service.

• Vos propres noms de domaine sur les applications, de la vérification à la mise en service.
• Fichiers montés dans un conteneur : configuration en ligne, ou secret servi comme fichier.
• Page Data APIs responsive, et refonte de la barre latérale.

Domaines personnalisés : réconciliation par l'opérateur

• L'opérateur réconcilie les domaines personnalisés.

Routage des fichiers non PDF dans le tri de documents

• Les fichiers qui ne sont pas des PDF sont routés explicitement par le tri de documents.

Domaines personnalisés : les fondations

• Les fondations des domaines personnalisés : API, base et vérification de propriété.

Schéma médaillon par défaut sur Iceberg

• Un schéma médaillon par défaut sur les catalogues Iceberg.
• Suppression en cascade des ressources d'un lakehouse.

Connecteurs : statistiques et navigation dans les buckets

• Un onglet de statistiques sur chaque connecteur.
• Page de détail d'un connecteur Google Drive, avec navigation dans les buckets.
• Les identifiants Ceph sont publiés dans le coffre à secrets.

Sauvegardes PostgreSQL à la demande, connecteur Google Drive

• Sauvegardes PostgreSQL à la demande, en plus des sauvegardes planifiées.
• Connecteur Google Drive, de bout en bout.
• Les secrets d'un utilisateur de base sont accessibles depuis son onglet.

Cibles de sauvegarde, environnement par défaut par organisation

• Des cibles de sauvegarde déclarées comme ressources.
• Un environnement par défaut pour chaque organisation.
• Badges sur les tables Trino.

PostgreSQL managé joignable depuis l'extérieur

• Une base PostgreSQL managée peut être jointe depuis l'extérieur du cluster.
• Le point de connexion est publié dans les secrets de l'utilisateur.

Utilisateurs PostgreSQL managés, secrets organisés par chemin

• Des utilisateurs PostgreSQL managés, déclarés et réconciliés comme des ressources.
• Les secrets s'organisent par chemin.
• Connecteur de données ouvertes RNIC.

OCR : reprise automatique et suivi du contexte de traitement

• L'OCR reprend là où il s'est arrêté, sans refaire le travail déjà fait.
• Temporisation configurable sur les appels au modèle.

PostgreSQL managé : le CRD et son opérateur

• PostgreSQL managé : le CRD et son opérateur.
• Zones Ceph configurables sur un Data Dock.
• Un visionneur de logs réutilisable dans la console.

Recherche hybride : requêtes séparées, résultats fusionnés

• La recherche hybride lance ses deux requêtes séparément avant de fusionner les résultats.

Indexation continue de Bifrost

• L'indexation Bifrost tourne en continu.

Fusion paramétrable des résultats de recherche hybride

• Un paramètre de fusion sur la recherche hybride, pour un mélange des résultats prévisible.

Explorateur de produits de données repensé

• L'explorateur de produits de données est repensé de fond en comble.

Réinitialisation de mot de passe depuis le cockpit

• Réinitialisation de mot de passe depuis le cockpit.

Cockpit v3 : panneau d'administration et onboarding automatique

Vous administrez la plateforme depuis un vrai panneau, et une nouvelle organisation démarre sans intervention manuelle.

• Cockpit v3 : un panneau d'administration à état, pour la plateforme.
• Onboarding automatique d'une nouvelle organisation.

Embeddings BGE, et la couche mémoire Hippocampe

Vous disposez d'une couche mémoire à trois niveaux, et la recherche vectorielle passe aux embeddings BGE.

• Embeddings BGE pour la recherche vectorielle.
• Hippocampe : une couche mémoire à trois niveaux.

Champs additionnels sur l'API d'import

• Champs additionnels transmis par l'API d'import.

Cycle de vie et statut Ceph

• Cycle de vie et statut d'un stockage Ceph, visibles dans la console.
• Les champs additionnels de l'API d'import sont réutilisés par les pipelines.

Omnifeed, et découpage des documents par page

• Omnifeed : une entrée unique pour alimenter les pipelines.
• Découpage d'un document par numéro de page, tel que l'OCR le rapporte.

Écrans de connexion aux couleurs de votre organisation

• Les écrans de connexion prennent les couleurs de votre organisation.
• Politiques réseau Cilium sur les applications conteneurisées.

Self service et quotas

• Parcours en self service, avec des quotas par organisation.

Conteneurs Kata : isolation matérielle des applications

• Les applications peuvent s'exécuter dans des conteneurs Kata, isolés au niveau matériel.

Secrets de registre et politiques réseau pour les conteneurs

• Secrets de registre et politiques réseau sur les applications conteneurisées.

Blueprint Lakehouse v2 sur Ceph

• Un blueprint Lakehouse v2, adossé au stockage Ceph.

Optimisation des tables Iceberg

• Optimisation des tables Iceberg, déclenchée depuis la plateforme.
• Détection plus rapide des changements sur les pods d'application.

CaaSThor : conteneurs applicatifs, ingress et logs

Vous déployez un conteneur applicatif depuis la console, avec son ingress, ses pods et ses logs sur la même page.

• CaaSThor : déployer une application conteneurisée depuis la console.
• Ingress, liste des pods et logs, dans la même page.
• Sélecteur de bucket sur les catalogues Iceberg.

Kafka, et refonte des index et caches Bifrost

• Kafka rejoint le catalogue de services.
• Index et caches Bifrost refondus.

Coffre à secrets

• Un coffre à secrets intégré à la plateforme.

Pré-calcul des index Bifrost

• Les index Bifrost sont pré-calculés plutôt que construits à la demande.

Service de métriques Observatory

• Observatory : un service de métriques pour la plateforme.

Étiqueteur interne en production

• L'étiqueteur interne passe en production, en remplacement de l'API externe.

Modèles globaux, expiration des logs, supervision de Petite Requête

• Des modèles globaux, disponibles pour toute la plateforme.
• Supervision de Petite Requête.
• Expiration automatique des logs de pipeline.

OCR local sur GPU avec Qwen2.5-VL

Vos documents ne sortent plus de la plateforme pour être lus : l'OCR tourne localement sur GPU.

• L'OCR tourne localement sur GPU, avec Qwen2.5-VL, sans appel à une API externe.

Création par lots des références de fragments

• Création par lots des références de fragments.

Petite Requête, et le Data Dock Ceph

Vous interrogez vos données depuis Petite Requête, et votre stockage objet s'adosse à Ceph.

• Petite Requête : l'exécuteur SQL prend son nom et sa documentation.
• Un Data Dock adossé à Ceph.
• Interface de stockage objet revue.

Un exécuteur SQL dans la console

• Un exécuteur SQL dans la console, pour interroger sans quitter la plateforme.

Copie S3 dans les pipelines

• Copie S3 dans les pipelines.

Duplication de tables au sein d'un catalogue Iceberg

• Duplication d'une table au sein d'un même catalogue Iceberg.

Rôle hyperfluid-users

• Un rôle hyperfluid-users, socle des accès de la plateforme.

Refonte des pipelines et de la navigation

• Les pipelines et la navigation de la console sont repensés.
• Chargement différé des pages lourdes.
• Valeurs dynamiques dans l'étiquetage.

Connexion API d'import et contrôle des suffixes

• Un type de connexion API d'import dans les pipelines.
• Contrôle des suffixes de fichiers à l'import.

Tri de fichiers dans les pipelines

• Une étape de tri de fichiers dans les pipelines.

Imports et exports ZIP, Vauban 0.2

• Imports et exports au format ZIP.
• Vauban 0.2, et la première page d'accueil publique.

Data Dock PostgreSQL, et sécurité au niveau ligne

Vous branchez une base PostgreSQL comme source, et vos politiques filtrent jusqu'à la ligne.

• Un Data Dock PostgreSQL.
• Sécurité au niveau ligne dans les politiques.
• Synchronisation des utilisateurs et des rôles depuis une API externe.