Cette rubrique décrit les principales évolutions fonctionnelles et les corrections de bugs publiées pour Realtime Compute for Apache Flink le 29 juillet 2026.
Le déploiement de cette version s'effectue par phases sur l'ensemble du réseau. Pour suivre la progression de la mise à niveau, consultez les dernières annonces dans le volet droit de la console Realtime Compute. Si les fonctionnalités décrites ne sont pas encore disponibles pour votre compte, cela signifie que la mise à niveau progressive n'a pas encore atteint votre environnement. Pour accélérer le processus, soumettez un ticket en précisant vos besoins métier ; nous planifierons l'intervention en conséquence.
Présentation
Cette publication met l'accent sur trois axes : le renforcement de la sécurité au niveau entreprise, l'ouverture des capacités d'IA aux tiers et l'amélioration de l'expérience opérationnelle. Côté plateforme, l'accès sans identifiants aux Connectors et un test de reprise après sinistre haute disponibilité ont été ajoutés, rehaussant ainsi le socle de sécurité et de conformité. Côté OpenAPI, les endpoints pour l'Assistant IA, la gestion des politiques Autopilot, les requêtes de compétences (skills) et les interrogations de données sont désormais exposés, permettant aux grands comptes d'intégrer les fonctionnalités Flink AI et Data dans leurs propres plateformes. En matière d'expérience utilisateur, la liste des opérations sur les jobs intègre des filtres multidimensionnels et une colonne indiquant le nombre de redémarrages, tandis que les diagnostics basés sur le score de santé incluent une règle liée au nombre de redémarrages. Ces évolutions font passer les opérations d'une logique réactive à une approche proactive de prévention.
Fonctionnalités de la plateforme
Test de reprise après sinistre haute disponibilité
Les namespaces haute disponibilité prennent désormais en charge le lancement d'un test de reprise après sinistre au niveau de la zone de disponibilité (AZ). Le système évince et relance automatiquement les nœuds de job, restaure l'état des jobs et surveille la migration en temps réel. À l'issue du test, un rapport est généré avec des métriques clés telles que le RTO (Recovery Time Objective) et le taux de récupération des jobs. Les clients disposant de la haute disponibilité peuvent désormais effectuer ces tests sans intervention manuelle, répondant ainsi aux exigences d'audit de conformité telles que MLPS ou ISO. Ce processus devient ainsi un flux de travail visualisable, auditable et exécutable en un clic depuis la console.
Accès aux Connectors sans identifiants (aperçu public)
Cette évolution ajoute la prise en charge des rôles RAM, l'intégration avec la gestion des identifiants via KMS et un point d'entrée amélioré pour la gestion des variables. Le Connector OSS permet d'accéder aux sources de données via un rôle RAM, tandis que le Connector PostgreSQL-CDC prend en charge l'accès aux identifiants KMS via un rôle RAM. Les configurations de job n'ont plus besoin d'embarquer les paires AccessKey/SecretKey ou les mots de passe de base de données, bien que les configurations explicites existantes restent prises en charge. Cette approche découple les identifiants sensibles du code des jobs, élimine les risques liés aux clés en clair, réduit la pression lors des audits de sécurité et permet la rotation des clés sans modifier chaque job individuellement.
Améliorations de l'expérience utilisateur
Améliorations des opérations sur les jobs
La liste des opérations sur les jobs permet désormais de filtrer par version du moteur et par type de job (SQL / JAR / Python / YAML), et affiche une colonne indiquant le nombre de redémarrages. Ces modifications répondent à l'absence de filtrage lorsque le nombre de jobs augmente, à l'invisibilité des anomalies internes de redémarrage et à la difficulté de localiser les anomalies par lot selon l'historique temporel. L'objectif est de faire évoluer les opérations vers une prévention proactive plutôt qu'une réponse réactive.
Amélioration des diagnostics basés sur le score de santé
Une nouvelle règle de score de santé basée sur le nombre de redémarrages a été ajoutée : un nombre cumulé de redémarrages supérieur à 0 est classé comme Moyen, supérieur à 100 comme Élevé, et supérieur à 300 également comme Élevé. Cette évolution comble le manque de notation pour les métriques continues et élimine l'angle mort où « des centaines de redémarrages affichent toujours un score de 100 ». Les risques deviennent ainsi visibles et les scores cohérents.
OpenAPI
OpenAPI de l'Assistant IA
L'interface complète du cycle de vie de l'Assistant IA est désormais ouverte, avec une conception privilégiant l'asynchrone. Elle permet de soumettre une session, d'interroger son statut et de récupérer les résultats en mode asynchrone, tout en proposant une interface de streaming SSE pour les conversations en temps réel avec l'utilisateur final. Une nouvelle opération a été ajoutée :
Démarrer une conversation (
ChatAiAgent)
OpenAPI Autopilot
Les interfaces de gestion des politiques Autopilot et d'interrogation de l'historique des ajustements (tuning) sont désormais ouvertes. Elles permettent aux clients de configurer des politiques d'ajustement en masse et de suivre les résultats depuis leurs propres plateformes. Cette évolution comble la dernière lacune de la boucle d'automatisation et supprime la nécessité de basculer vers la console pour des opérations manuelles. Trois nouvelles opérations ont été ajoutées :
Interroger la politique Autopilot (
GetAutopilotPolicy)Mettre à jour la politique Autopilot (
UpdateAutopilotPolicy)Lister les historiques d'ajustement Autopilot (
ListAutopilotTuningHistories)
OpenAPI d'interrogation des données
L'interface de gestion complète du cycle de vie des scripts de requête de données SQL est désormais ouverte. Les systèmes externes peuvent ainsi exécuter des requêtes SQL, récupérer les résultats et gérer les fichiers de script via l'API. Six nouvelles opérations ont été ajoutées ; combinées à l'opération existante StartSqlExecution, elles forment une boucle fermée complète pour l'API de requête de données SQL. Cela permet d'interroger directement les données Flink depuis votre propre plateforme sans avoir à vous connecter à la console :
Arrêter l'exécution d'une requête (
StopSqlExecution)Récupérer les résultats d'exécution de la requête (
FetchSqlExecutionResult)Créer un script de requête (
CreateSqlFile)Obtenir un script de requête (
GetSqlFile)Mettre à jour un script de requête (
UpdateSqlFile)Supprimer un script de requête (
DeleteSqlFile)