Retour au blog

Red Hat AI 3.5: gouverner les agents IA en production

Article créé le 11 septembre 2026 · Publication analysée: 9 septembre 2026 · Source: Red Hat

Red Hat AI 3.5 réunit évaluation de sécurité, isolation multi-tenant, observabilité des agents et mesure des ressources. Pour les entreprises belges et françaises, l'enjeu n'est plus seulement de réussir un pilote: il faut exploiter l'IA comme un service critique, gouverné et mesurable.

1. Ce que Red Hat annonce

La version, annoncée disponible le 9 septembre, étend EvalHub aux modèles apportés ou adaptés par l'entreprise, avec des tests ciblant notamment l'injection de prompt, les jailbreaks, l'exposition de données personnelles et la toxicité. Elle ajoute aussi des modèles validés avec scores de sécurité, ainsi qu'un déploiement progressif contrôlé pour limiter le risque lors des mises à jour.

Pour l'exploitation, Red Hat documente le suivi des jetons par utilisateur, les performances des modèles et agents, le traçage agentique avec MLflow et l'utilisation des GPU. Des plans de contrôle dédiés et des machines virtuelles OpenShift renforcent l'isolation entre locataires, tandis que la gestion des priorités protège l'inférence temps réel des traitements d'arrière-plan.

2. Ce que cela change pour une entreprise belge ou française

Une PME ou une ETI peut désormais formuler son cahier des charges autour de preuves concrètes: tests avant mise en production, séparation des environnements, consommation par équipe, traces des appels et procédure de retour arrière. Pour une grande entreprise ou une administration, l'isolation multi-tenant permet de mutualiser l'infrastructure sans confondre données, quotas et responsabilités.

Les DSI doivent néanmoins distinguer fonctionnalité produit et conformité démontrée. Un score fournisseur ne remplace ni l'analyse de risque RGPD ou AI Act, ni les tests sur les données, langues et scénarios réels de l'organisation. Le lieu d'hébergement, l'administration, les sous-traitants et la réversibilité restent à vérifier contractuellement.

3. Analyse Underside: industrialiser RAG, agents et Odoo

L'analyse Underside est que l'observabilité doit relier trois niveaux: la ressource consommée, la décision de l'agent et l'effet métier. Un tableau de bord GPU ou jetons maîtrise le coût, mais il faut aussi tracer les documents RAG utilisés, les outils appelés, les autorisations, les validations humaines et le résultat dans le système cible.

Pour Odoo Entreprise, un agent de vente, support ou comptabilité doit donc disposer d'une identité séparée, de droits minimaux et de limites par opération. AutoRAG et les modèles d'agents peuvent accélérer l'intégration, mais la souveraineté dépend de toute la chaîne — données, modèles, calcul, journaux et exploitation — en local, cloud européen ou hybride selon le risque.

4. Recommandation opérationnelle

Avant d'élargir un pilote, définissez un service avec propriétaire, SLO, budget, jeu d'évaluation, niveaux d'accès et seuils d'arrêt. Testez les mises à jour sur un trafic limité, mesurez coût et qualité par cas d'usage, puis conservez les traces nécessaires à l'audit sans accumuler inutilement des données sensibles.

Priorité concrète: exigez une fiche de contrôle par agent couvrant données, identité, outils, évaluations, coût, supervision humaine, rollback et portabilité avant toute connexion à un ERP ou à une API métier.

Cadrer une plateforme IA gouvernée

Lire la source officielle