Ce que nous livrons, semaine après semaine.

Politiques CVE, modèles de décision, RabbitMQ géré

Vous décidez ce qu'une vulnérabilité déclenche sur vos charges de travail, de l'alerte au blocage du déploiement. Vous posez une question fermée à un modèle de décision depuis vos pipelines, vos agents ou le terminal, et vous créez un courtier RabbitMQ comme une base gérée.

• Une politique CVE dit ce qu'une faille déclenche. Depuis un préréglage, vos règles alertent, bloquent un déploiement, coupent le réseau ou arrêtent la charge de travail, en audit ou en application.
• Chaque faille est qualifiée, chaque image analysée. Un constat porte son score CVSS, sa présence au catalogue KEV et sa probabilité d'exploitation EPSS, et une image de votre registre ne démarre qu'une fois analysée.
• Un modèle de décision répond à une question fermée. Vous le déployez sur GPU ou sur CPU et l'interrogez depuis le terrain de jeu, hfctl ai decide ou l'API. Vos pipelines étiquettent et aiguillent leurs lignes avec, vos agents routent vers le bon spécialiste.
• Un courtier RabbitMQ se crée comme une base gérée. Vous choisissez un, trois ou cinq nœuds, agrandissez son stockage, activez stream, shovel, federation ou MQTT, et ses identifiants arrivent dans le gestionnaire de secrets.
• Vous invitez sans boîte mail. Quand votre organisation l'autorise, vous copiez un lien d'invitation, affiché une seule fois, et le transmettez vous-même à la personne.
• Qui accède à quoi se lit sur la ressource. Une application CaaSThor ou une base PostgreSQL gérée liste qui peut l'atteindre, et vous accordez un droit depuis ce même onglet.
• hfctl traite les modèles partagés comme les vôtres. hfctl ai list, get et chat couvrent les modèles de la plateforme, et ai catalog dit ce que votre organisation peut déployer, et pourquoi pas.
• Airflow parle à Oracle. L'image Airflow par défaut embarque le fournisseur Oracle : vos DAG utilisent OracleHook et OracleOperator sans construire d'image.

Toute votre organisation en Terraform, une page Profile

Vous décrivez vos droits, vos environnements et vos services dans un même code Terraform, documenté par votre console. Chacun gère son mot de passe, sa double authentification et ses sessions depuis sa page Profile.

• Les droits se déclarent en Terraform. Rôles, groupes et accès des utilisateurs et des comptes de service s'écrivent dans votre code, limités si besoin à un environnement (harbor) ou à une ressource.
• Le reste de la plateforme suit. Environnements, clusters SQL Engine et leurs catalogues, pipelines, Nextflow, compute docks, agents, alertes et machines virtuelles se créent avec le fournisseur 0.11.
• Une application CaaSThor se décrit en entier. Variables d'environnement, secrets et conteneurs d'initialisation passent en Terraform, dans les règles fixées pour votre organisation.
• Votre console documente le fournisseur. La page Terraform suit les menus de la console, donne un exemple par ressource et masque ce que votre organisation n'a pas activé.
• Chacun gère son compte depuis une page Profile. Nom, thème, mot de passe, double authentification et fournisseurs de connexion se changent après une nouvelle authentification.
• Vous voyez vos sessions ouvertes. Vous fermez celle que vous ne reconnaissez pas, ou toutes les autres d'un coup.
• Un compte de service automatise davantage. Depuis votre CI, il crée des environnements et des clusters SQL Engine, et active le SQL Engine de l'organisation.
• Une application CaaSThor signale les failles de son image. Sa vue d'ensemble vous prévient quand l'image contient des vulnérabilités critiques ou élevées.

Volumes partagés CaaSThor, accès aux données table par table

Vos applications CaaSThor passent à plusieurs réplicas sans renoncer à leur disque, et vous décidez qui lit quelle table de vos clusters SQL Engine. Dans Petite Requête, vous laissez tourner une requête aussi longtemps qu'il le faut, jusqu'à 15 min.

• Une application CaaSThor garde son disque et passe à plusieurs réplicas. Le volume est partagé entre toutes, ou chaque réplica reçoit le sien, et l'autoscaling suit.
• Vous décidez qui lit quelle table. L'onglet Sécurité d'un cluster SQL Engine accorde ou refuse la lecture d'un catalogue, d'un schéma ou d'une seule table.
• Chacun ne voit que ce qu'il peut lire. Le catalogue de la console et Bifrost listent les tables permises, et une table dont seule la structure est visible le dit.
• Petite Requête laisse tourner une requête jusqu'à 15 min. Vous réglez la durée maximale à côté du bouton d'exécution, et la requête continue en arrière-plan.
• Un compte de service affiche toutes ses permissions. Chacune indique si elle vient d'un rôle ou d'un droit direct, et vous en accordez une en choisissant la ressource dans une liste.
• Le gestionnaire de secrets se range par environnement (harbor). Chaque environnement a ses dossiers, et vous donnez l'accès dossier par dossier.
• Une workstation signale les connexions sortantes bloquées. L'en-tête affiche les hôtes refusés, et vous les autorisez d'un clic sans quitter votre éditeur.
• Les bases de la plateforme s'archivent vers votre cible de sauvegarde. Sur une installation dédiée, leurs journaux partent en continu et une copie complète part chaque nuit.

Backends de stockage objet, CaaSThor qui suit la charge

Sur une installation dédiée, vous placez le stockage objet de vos organisations sur Ceph ou sur le service S3 de votre choix, et chaque organisation garde une seule adresse S3. Vos applications CaaSThor suivent leur charge et s'arrêtent quand personne ne les appelle.

• Le stockage objet repose sur des backends déclarés. Un cluster Ceph ou un service compatible S3 devient un backend que vous gérez depuis le cockpit, et chaque zone Ceph existante en devient un.
• Vous décidez quelles organisations utilisent chaque backend. Vous accordez l'accès depuis le cockpit, et si vous le retirez, les données restent en place, en lecture seule.
• Chaque organisation garde une seule adresse S3. Trino, les pipelines, le registre, Airflow, CaaSThor et hfctl passent tous par la passerelle S3 de l'organisation, quel que soit le backend.
• Les bases PostgreSQL gérées se sauvegardent sur tous les backends. Sauvegarde et restauration passent par la même passerelle, et la cible d'un bucket suit son environnement (harbor).
• Une application CaaSThor suit sa charge. Sur une installation équipée de KEDA, elle varie entre un minimum et un maximum d'instances selon le CPU, la mémoire ou les requêtes HTTP.
• Une application peut descendre à zéro instance. Elle s'arrête après une période sans trafic, et la requête HTTP suivante la redémarre et reçoit sa réponse.
• Une requête planifiée qui échoue vous alerte. Après 3 échecs d'affilée, votre organisation est prévenue par e-mail et par webhook, et vous coupez l'alerte requête par requête.
• Chaque charge de travail porte son environnement. Les pods que la plateforme gère indiquent leur organisation et leur environnement, et l'inventaire des charges de travail les classe par environnement.

Déploiement depuis Git, règles de sécurité par organisation

Vous déployez une application CaaSThor depuis votre dépôt Git : vous changez l'image dans un fichier du dépôt, et l'application la prend d'elle-même ou attend votre feu vert. Sur une installation dédiée, vous fixez depuis le cockpit des règles de sécurité propres à chaque organisation.

• Une application CaaSThor prend son image dans un dépôt Git. Un fichier hyperfluid.toml du dépôt indique l'image à déployer, sur GitHub, GitLab ou Forgejo.
• Vous suivez une branche ou la dernière version publiée. En suivant les tags, l'application prend le plus élevé de ceux qui correspondent à l'expression régulière que vous donnez.
• Vous choisissez entre mise à jour automatique et validation. En mode manuel, la console signale qu'une nouvelle image est disponible et attend que vous lanciez la synchronisation.
• Chaque synchronisation laisse une trace. L'historique liste les images appliquées ou proposées et les échecs, avec leur commit, et une alerte prévient quand le dépôt ne se lit plus.
• Le Forgejo de votre environnement se relie en un clic. La console crée l'accès au dépôt pour vous, sans jeton à copier.
• hfctl et Terraform pilotent la même source. hfctl apps sync lance une synchronisation, hfctl validate vérifie un hyperfluid.toml avant de le pousser.
• Les règles de sécurité se fixent organisation par organisation. Depuis le cockpit, vous posez une valeur pour toute la plateforme et la remplacez pour une organisation, en notant pourquoi.
• La première règle décide qui peut suivre Git automatiquement. Désactivée, elle fait passer toutes les applications d'une organisation en validation manuelle, sans toucher à leur configuration.

Adresses internes CaaSThor, sauvegarde chiffrée des secrets

Vous savez comment appeler une application CaaSThor depuis votre environnement sans chercher le nom de son service. Sur une installation dédiée, vous sauvegardez le coffre de secrets et les secrets de la plateforme, chiffrés, vers votre propre stockage.

• La page d'une application CaaSThor donne son adresse interne. Le nom d'hôte ca-<nom> et l'URL sur son port HTTP principal s'affichent à côté de l'URL publique.
• Chaque adresse se copie d'un clic. Les références d'image demandée et en cours d'exécution aussi, affichées en entier.
• Le coffre de secrets est sauvegardé à intervalle régulier. Toutes les 6 heures par défaut, un instantané d'OpenBao part vers le stockage S3 de votre choix.
• Les sauvegardes sont chiffrées avant de quitter le cluster. Elles sont chiffrées avec age pour les destinataires que vous désignez, puis relues pour vérifier leur taille et leur empreinte.
• Les secrets de la plateforme partent avec l'instantané. L'autorité de certification interne et les accès d'administration sont regroupés dans la même sauvegarde, et une alerte prévient si elle n'a pas réussi depuis 12 heures.

Santé des applications CaaSThor, période du journal d'audit

Vous voyez d'un coup d'œil quelles applications CaaSThor vont bien et lesquelles demandent votre attention. Dans le journal d'audit, vous choisissez la période affichée et la partagez par un simple lien.

• La liste des applications CaaSThor devient une vue de santé. Des tuiles résument les applications saines, les instances prêtes, les redémarrages et la consommation CPU et mémoire sur la journée.
• Un filtre ne garde que les applications à surveiller. Celles qui sont en échec, qui approchent 80 % d'une limite ou qui ont redémarré dans les dernières 24 heures.
• Chaque ligne dit ce qui ne va pas. Instances manquantes, mémoire, CPU et redémarrages s'affichent à côté des courbes CPU et mémoire de la journée.
• Une ligne se déplie sur ses instances. Vous lisez l'état et la consommation de chacune, et un menu redémarre ou arrête l'application sans quitter la liste.
• Vous choisissez la période du journal d'audit. Les dernières 24 heures, 7 jours, 30 jours ou des dates précises, dans la console comme dans le centre de contrôle.
• La période fait partie du lien. Une vue filtrée du journal d'audit s'envoie telle quelle à un collègue, qui l'ouvre sur les mêmes événements.
• La vue sécurité de votre organisation se concentre sur votre code. Les bases de données, Kafka, Airflow ou les modèles que la plateforme gère et met à jour pour vous n'y figurent plus.
• Le centre de contrôle décide pour chaque organisation. Un interrupteur rend les services gérés de nouveau visibles à une organisation qui veut les suivre.

Réanalyse globale en un clic, la sécurité de vos seules images

Après une mise à jour de la plateforme, vous relancez l'analyse de toutes les images en service depuis le centre de contrôle, en une seule action. La vue sécurité de votre organisation liste les images que vous déployez et pouvez faire évoluer, et elles seules.

• Le centre de contrôle relance l'analyse de toutes les images en un clic. Après confirmation, chaque image en service sur le cluster est mise en file d'attente, et un message indique combien l'ont été.
• L'analyse globale inclut les images de la plateforme elle-même. Ce sont celles qu'une montée de version remplace en premier, et aucune organisation ne peut les relancer seule.
• La vue sécurité de votre organisation montre ce que vous pouvez faire évoluer. Les composants que la plateforme installe et met à jour pour vous, comme le SQL Engine d'un Data Dock, n'y figurent pas.
• Dans une base PostgreSQL gérée, vous voyez la base. Le conteneur PostgreSQL et son pooler restent listés, les conteneurs d'amorçage et de sauvegarde ajoutés par la plateforme sont masqués.
• Les chiffres portent sur ce que vous voyez. Les tuiles de synthèse, les totaux par environnement (harbor) et les redémarrages sont calculés sur la liste affichée.
• Le centre de contrôle garde la vue complète. Les composants de la plateforme y restent visibles, signalés par un badge Internal.

Métriques métier de vos applications, tableaux de bord intégrés

Votre application expose ses propres métriques Prometheus et vous les retrouvez dans la console, à côté du CPU et de la mémoire, sans installer de Grafana. Vous construisez un tableau de bord à partir de ces métriques en un clic.

• Vos applications CaaSThor exposent leurs propres métriques. Vous indiquez le port et, si besoin, le chemin (/metrics par défaut), et la plateforme les collecte.
• L'onglet Métriques réunit système et métier. Les courbes de CPU et de mémoire restent en haut, vos indicateurs propres s'affichent juste en dessous.
• Un clic crée un tableau de bord. La console le construit à partir des métriques que votre application expose déjà, et vous l'ajustez ensuite.
• Un widget affiche une requête SQL ou une métrique d'application. L'éditeur propose la liste des métriques disponibles et montre un aperçu avant l'enregistrement.
• Chaque application ne voit que ses propres métriques. Une requête est toujours limitée à l'application qui l'émet, même si l'application publie des étiquettes trompeuses.
• hfctl apps metrics interroge ces métriques depuis le terminal. Vous listez les métriques d'une application avec --names ou lancez une requête PromQL avec --query.

Environnements Nextflow, supervision des workloads, import Excel

Vous lancez vos pipelines Nextflow et nf-core dans un environnement isolé, depuis la console ou le terminal. Vous voyez d'un coup d'œil ce qui tourne dans votre organisation, avec les CVE de chaque image, et vous importez un classeur Excel directement dans une table.

• Un environnement Nextflow exécute vos pipelines nf-core. Vous le créez dans un environnement (harbor), avec son volume de travail partagé, ses buckets attachés et son propre quota.
• Vous lancez, reprenez et annulez une exécution. La console suit chaque run avec ses journaux en direct, la liste de ses tâches et leur code de sortie, et une reprise repart du cache du run précédent.
• hfctl nextflow fait la même chose depuis le terminal. Vous créez un environnement, lancez un pipeline avec --follow et lisez les journaux d'une tâche sans ouvrir la console.
• Vauban recense tout ce qui tourne dans votre organisation. Chaque workload s'affiche avec l'image qu'il exécute, son exposition à Internet et les règles réseau qui le couvrent.
• Les CVE affichées sont celles de l'image en cours d'exécution. Chaque image est analysée chaque semaine par défaut, vous réglez ce rythme par organisation, et vous relancez une analyse à la demande.
• Chaque environnement a ses onglets de sécurité. Workloads, redémarrages et réseau : un redémarrage de conteneur mène aux journaux du moment où il s'est produit.
• Vous importez un classeur Excel ou OpenDocument dans une table Iceberg. Un aperçu montre les colonnes et leur type avant l'écriture, et vous choisissez la feuille et la ligne d'en-tête.
• Un connecteur SharePoint se modifie après sa création. Vous changez la source, les identifiants ou la planification, et chaque exécution de l'historique ouvre ses journaux.

Import de dumps PostgreSQL, documentation Atlas, passerelle S3

Vous chargez un dump ou un script SQL dans une base PostgreSQL gérée, depuis la console ou le terminal. Votre organisation dispose de sa propre documentation dans la console, et de sa propre passerelle S3.

• Vous importez un dump dans une base PostgreSQL gérée. Un onglet Imports accepte une archive pg_dump, un script .sql, compressés ou non, ou du SQL collé directement.
• Un import s'applique en entier ou pas du tout. Il tourne dans une seule transaction, sous le rôle éditeur que vous choisissez, et chaque objet importé appartient à ce rôle.
• La même opération se lance depuis le terminal. hfctl db import envoie le fichier, lance l'import et suit son avancement jusqu'au bout.
• Atlas réunit la documentation de votre organisation. Guides en français et en anglais, recherche plein texte, favoris, notes et procédures que les responsables publient pour leurs équipes.
• L'aide s'ouvre à côté de l'écran où vous travaillez. Depuis le stockage, Petite Requête, Sapience ou les applications, le guide correspondant s'affiche sans quitter la page.
• Chaque organisation a sa propre passerelle S3. Elle répond sur une adresse dédiée, et les clés d'accès que délivre la console lui sont propres.
• Les ressources créées par la plateforme sont signalées. Un bucket, une base ou une application porte sa source, et ce que la plateforme a créé pour vous ne peut pas être supprimé par erreur.
• Un agent démarre dans le dépôt de votre choix. Sur une workstation, vous choisissez le dépôt, la branche ou le worktree d'une session, et ses pull requests ouvertes s'affichent au-dessus de la conversation.

Requêtes planifiées gouvernées, Ask AI, Airflow et SQL Engine

Vous choisissez le compte de service sous lequel tourne chaque requête planifiée, et vous savez quelle identité a lu les données à chaque exécution. Petite Requête écrit votre SQL à partir d'une question, et vos DAG Airflow interrogent le SQL Engine sans manipuler de secret.

• Une requête planifiée tourne sous le compte de service que vous lui donnez. Vous accordez à ce rapport précis les seuls accès dont il a besoin, et vous les retirez de la même façon.
• Chaque exécution enregistre l'identité qui a lu les données. L'historique conserve le compte qui portait le jeton ce jour-là, même si vous en attribuez un autre ensuite.
• Vous fixez l'objectif de point de reprise d'une base gérée. À la création, vous choisissez l'intervalle qui borne la perte de données possible, 5 minutes conseillées, 60 secondes au plus court.
• Un environnement Airflow se connecte au SQL Engine. Vous déclarez la connexion vers un catalogue, vos DAG l'utilisent par son nom, et chaque requête reste soumise aux autorisations de votre organisation.
• Petite Requête écrit le SQL à partir d'une question. Vous décrivez ce que vous cherchez, la requête arrive en brouillon dans l'éditeur, et vous restez seul à décider de l'exécuter.
• Vous choisissez le modèle qui répond. L'assistant SQL se rattache au modèle Sapience de votre choix, avec l'authentification et le décompte d'usage par organisation.

Restauration à un instant précis, étiquettes RLS, hfctl airflow

Vous ramenez une base PostgreSQL gérée à la minute que vous choisissez, depuis la console ou le terminal. Vous filtrez les lignes que lit un compte de service comme vous le faites pour un utilisateur, et vous pilotez vos environnements Airflow avec hfctl.

• Une base gérée se restaure à un instant précis. Depuis l'onglet des sauvegardes, vous choisissez une date et une heure à la minute près, et la base est reconstruite dans l'état où elle était à ce moment.
• La console affiche la période que vous pouvez restaurer. Chaque base indique depuis quand et jusqu'à quand ses sauvegardes permettent de revenir, et le choix de l'instant est borné à cette période.
• La même restauration se lance depuis hfctl. hfctl db restore --at accepte un instant daté ou un décalage comme -2h, pour revenir deux heures en arrière sans calculer l'heure.
• Une alerte part quand une sauvegarde planifiée n'a pas eu lieu. Une base dont la sauvegarde quotidienne n'a pas abouti depuis 26 heures vous prévient sur vos canaux, même si tout le reste est au vert.
• Un compte de service porte des étiquettes RLS. Vous lui attribuez les étiquettes qui filtrent les lignes qu'il peut lire, depuis sa page dans la console, comme pour un utilisateur.
• hfctl airflow pilote vos environnements Airflow. Vous les créez, les mettez en veille, les redémarrez, lisez leurs journaux et gérez leurs connexions sans ouvrir la console.
• Un rôle personnalisé se renomme. Vous modifiez son nom et sa description, et les membres qui le portent comme ses permissions restent en place.
• Vous changez les rôles d'un membre depuis la liste des utilisateurs. Une fenêtre présente les rôles de l'organisation avec leur description, et vous cochez ceux que le membre doit porter.

Connexions Airflow, export SIEM, maintenance Iceberg isolée

Vous déclarez les connexions d'un environnement Airflow sans saisir un secret, vous envoyez vos journaux d'audit et de plateforme vers votre SIEM, et la maintenance de vos tables Iceberg tourne sous sa propre identité, dans un groupe de ressources qui ne gêne pas vos requêtes.

• Airflow reçoit des connexions gérées. Vous déclarez une connexion vers une base PostgreSQL gérée ou un bucket, et vos DAG l'utilisent par son nom, sans secret dans leur environnement.
• Une base gérée vous alerte quand ses sauvegardes n'avancent plus. Dès que l'archivage des journaux de transactions prend du retard, une alerte critique part sur vos canaux avec le nombre de segments en attente.
• La maintenance Iceberg a sa propre identité. Le compactage et l'expiration des instantanés tournent sous un compte dédié, limité à ces opérations, et chaque écriture lui est attribuée dans le journal d'audit.
• Et son propre groupe de ressources. Le SQL Engine plafonne la maintenance à 8 requêtes en parallèle et 15 % de sa mémoire, pour que vos requêtes gardent la priorité.
• Vos journaux partent vers votre SIEM. Les événements d'audit et les journaux de la plateforme sont envoyés vers VMware Aria Operations for Logs, ou vers tout autre SIEM en syslog RFC 5424 sur TLS.
• Un seul domaine pour tous les aperçus de workstation. Une installation sert les aperçus de chaque organisation sous un domaine dédié, avec un seul enregistrement DNS et un seul certificat pour tout le cluster.
• Kafka est livré avec la plateforme. L'opérateur Strimzi s'installe depuis le chart Hyperfluid, avec les images de broker et de Kafka Connect construites à chaque version.

L'image qui tourne vraiment, CPU et mémoire sur mesure dans hfctl

Vous voyez quelle image tourne réellement derrière chaque application conteneurisée, y compris sur un tag flottant ou pendant une mise à jour. Depuis le terminal, vous listez les paliers proposés et vous fixez vous-même le CPU et la mémoire d'une application.

• Une application conteneurisée montre l'image qui tourne vraiment. Sa vue d'ensemble liste chaque image en service par son digest, avec son nombre de pods, et signale un tag flottant comme latest.
• hfctl liste les paliers d'application. hfctl apps tiers affiche chaque palier proposé par la plateforme, avec son CPU et sa mémoire.
• Vous fixez le CPU et la mémoire d'une application depuis le terminal. --cpu et --memory remplacent le choix d'un palier, à la création comme à la mise à jour, dans les bornes de la plateforme.
• hfctl montre ce qui tourne, et à quelle taille. hfctl apps get affiche le palier de l'application ou sa taille sur mesure, et chaque image en service avec son nombre de pods.

Le stockage Ceph se surveille dans le centre de contrôle

Vous suivez la santé, la capacité et l'activité de votre stockage Ceph depuis le centre de contrôle, sans ouvrir un outil de supervision à part.

• Une page montre l'état de votre cluster Ceph. La santé, les alertes en cours et le quorum des moniteurs s'affichent et se rafraîchissent toutes les 30 secondes.
• Vous voyez la capacité et ce qui l'occupe. La capacité brute, l'occupation de chaque pool et l'état des groupes de placement se lisent sur la même page.
• Chaque disque a sa ligne. L'état, le remplissage et la latence d'écriture de chaque OSD vous permettent de repérer celui qui ralentit.
• Les débits et les IOPS s'affichent sur la durée. Lectures et écritures sont tracées sur une fenêtre que vous choisissez, de 15 minutes à 24 heures.
• Une mesure manquante ne passe pas pour un stockage sain. Quand un échantillon manque ou qu'une requête échoue, la page le signale au lieu d'afficher un stockage inactif ou en bonne santé.

Le SBOM de la version installée, des runners CI orientés CPU

Vous remettez à votre RSSI la nomenclature logicielle (SBOM) de la version installée, téléchargée depuis le centre de contrôle avec ses rapports. Vos runners CI prennent des tailles orientées CPU, et le formulaire vous montre ce qu'un pool réserve.

• Le centre de contrôle affiche le SBOM de la version installée. Il est produit par le build qui a construit l'image, au commit de la release, et décrit donc exactement ce qui tourne chez vous.
• Vous téléchargez le SBOM et ses rapports. Un document CycloneDX 1.5 par livrable, un agrégat de l'ensemble et une synthèse pour votre RSSI sont prêts à archiver.
• Les licences à arbitrer passent en tête. Le copyleft fort et les licences indéterminées sont mis en avant, parce que ce sont les deux cas que votre DSI doit trancher.
• Les vulnérabilités connues sont listées par composant. Chacune porte son score CVSS et la version qui la corrige, et la page met à part celles notées au-dessus de 7 sur un composant réellement livré.
• L'infrastructure a son propre inventaire. Le socle Kubernetes, le stockage, les moteurs de requête et le bus de messages y figurent avec leur version déployée.
• Vos runners CI gagnent quatre tailles orientées CPU. De C2 à C8, elles prévoient un Go de mémoire par vCPU, pour les builds qui demandent du calcul plutôt que de la mémoire.
• Le formulaire affiche ce qu'un pool réserve. Il calcule le CPU et la mémoire d'un runner, Docker compris, puis le total d'un pool GitHub à son nombre maximal de runners.

Les runners CI filtrent leurs sorties, la matrice de flux

Vous appliquez à vos runners CI les mêmes listes de sortie réseau qu'à vos workstations, vous choisissez leur taille, et vos jobs construisent des images Docker dans leur micro-VM. Le centre de contrôle produit la matrice de flux à remettre à votre équipe réseau, relevée sur le cluster.

• Vos runners CI suivent les listes de sortie de l'environnement (harbor). Un runner Forgejo s'attache aux mêmes listes d'autorisation que vos workstations, et se modifie en place, sans le recréer.
• Une seule page Runners. Les pools GitHub et les runners Forgejo se gèrent au même endroit, comme deux variantes d'une même chose.
• Dix-sept listes de sortie prêtes à l'emploi. Debian, Node.js, Rust, Python, Docker Hub, GitHub, Kubernetes et dix autres : vous les activez d'un clic dans une liste d'autorisation.
• Vous choisissez la taille de vos runners. Quatre tailles de S à XL, chacune avec son disque Docker, ou une taille sur mesure que vous fixez dans les bornes de la plateforme : CPU, mémoire et disque.
• Chaque runner embarque son propre démon Docker. Il tourne dans la micro-VM du runner, sur un volume bloc dédié, et seul le job qu'il sert peut le joindre.
• Le centre de contrôle génère votre matrice de flux. Une page décrit chaque flux réseau à ouvrir, sa criticité et son chiffrement, et l'exporte en XLSX en français ou en anglais, prête pour l'équipe réseau.
• La matrice est relevée sur le cluster. Adresses et registres d'images sont lus dans le cluster, résolveurs et serveurs de temps sur les machines, et chaque valeur dit si elle a été lue ou déclarée.
• Vous déclarez les capacités d'un modèle externe. Un modèle partagé hébergé hors du cluster porte sa fenêtre de contexte et son support des outils, et un flavor peut le servir sous un nom stable.

Plusieurs Airflow par harbor, les files Trino, l'audit du SQL

Vous créez plusieurs environnements Airflow dans un même harbor, chacun avec son espace d'exécution et ses sorties réseau. Vos requêtes interactives ne patientent plus derrière un traitement de masse, et Vauban montre le SQL exact que chaque requête a exécuté.

• Plusieurs environnements Airflow par harbor. Chacun a son adresse, son espace d'exécution isolé pour les tâches, sa liste de sorties réseau et ses réglages airflow.cfg, créés depuis la console.
• Les requêtes interactives passent devant les traitements de masse. Le SQL Engine sépare les files d'attente, et une recherche de quelques millisecondes ne patiente plus derrière une flotte de pipelines.
• Vauban montre le SQL de chaque requête. Le texte exact, le résultat, les colonnes lues et les statistiques d'exécution rejoignent le journal d'audit de chaque requête Trino.
• Les comptes de service ont un nom dans le journal d'audit. Un compte de service apparaît sous son nom plutôt que sous son identifiant, et se filtre comme un utilisateur.
• Un rôle de compte de service se limite à un harbor. Vous liez un rôle à l'organisation entière ou à un seul harbor, et une liaison de harbor ne porte que les permissions de ce harbor.
• La forge range ses fichiers dans le bucket de l'organisation. Objets Git LFS, pièces jointes, paquets et artefacts vivent dans votre stockage objet, et survivent à une désinstallation.
• Les modèles d'embedding Triton répondent en OpenAI. Sapience reconnaît le protocole d'un modèle partagé et traduit un appel /v1/embeddings vers un modèle KServe v2, avec le tokenizer déclaré sur le modèle.
• Un mode audit pour les workstations, organisation par organisation. Désactivé par défaut, il enregistre ce qui est demandé à l'agent et ce qui est tapé au terminal, et l'utilisateur en est averti.

Des conteneurs plus grands, leurs volumes, l'audit par requête

Vous dimensionnez un conteneur au millicœur près, vous voyez le remplissage de ses volumes, et vous lisez l'activité de vos données requête par requête.

• Les conteneurs montent à 8 vCPU. Deux gabarits prolongent la grille existante, 2xlarge (4 vCPU, 4 Gio) et 4xlarge (8 vCPU, 8 Gio).
• Ou vous saisissez la taille exacte. Vous entrez le processeur et la mémoire voulus, facturés et calculés comme n'importe quel gabarit.
• Le remplissage des volumes se lit dans la console. Chaque volume affiche son point de montage, sa taille, sa classe de stockage et son occupation, avec une alerte au-delà de 80%.
• L'onglet sépare les volumes des fichiers montés. Vous voyez d'un coup d'œil ce qui survit à un redémarrage et ce qui est simplement déposé dans le conteneur.
• L'audit se lit requête par requête. Les évènements d'accès sont regroupés par requête SQL, et le bruit du planificateur Trino est écarté.
• Vous suivez l'activité en direct. Une vue temps réel montre les évènements d'accès avant leur agrégation, avec leur détail.
• Petite Requête garde le schéma en mémoire. Les catalogues sont explorés en parallèle, et si l'un d'eux ne répond pas, les autres s'affichent quand même.

Le connecteur SharePoint, le plan de données, les pages publiques

Vous ingérez une bibliothèque SharePoint comme n'importe quelle autre source, vous voyez l'état du plan de données sans ouvrir un terminal, et vous modifiez le texte de vos pages publiques vous-même.

• SharePoint devient une source. Une bibliothèque de documents est ingérée dans un bucket via Microsoft Graph, sur le même modèle que Google Drive.
• Une page montre l'état du plan de données. La passerelle LLM et Bifrost y affichent leur disponibilité, leurs redémarrages et leur trafic, modèle par modèle.
• Sept règles d'alerte veillent sur ces deux composants. Une panne de la passerelle ou de Bifrost se signale d'elle-même.
• Les métriques de Bifrost sont collectées. Le débit et la latence du proxy PostgreSQL sont visibles, et le moteur d'embedding dégradé est nommé.
• Un conteneur arrêté se relance. Il repart au nombre de répliques qu'il avait, et les boutons de démarrage et d'arrêt sont mis en évidence.
• La mémoire s'affiche à côté du processeur. Le panneau des ressources d'un conteneur donne les deux.
• Vous choisissez les modèles des fonctions IA. L'assistant SQL, les tableaux de bord, la génération d'ontologie et la classification de tables se règlent depuis le centre de contrôle.
• Les pages publiques se modifient sans déploiement. Le texte de l'inscription, de l'accueil et des invitations se change depuis le centre de contrôle, en direct.

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.