Red Hat: choisir un modèle IA devient une décision d'architecture
Le billet Red Hat du 24 août 2026 rappelle une réalité souvent sous-estimée: choisir un modèle IA ne consiste pas à prendre le plus grand ou le plus récent, mais à aligner capacité, coût, confidentialité, RAG, fine-tuning, licence, hébergement et exploitation quotidienne.
1. Ce que Red Hat met en avant
Red Hat propose une grille de lecture pour comparer les modèles avant de concevoir l'infrastructure qui les portera. Le billet passe par les paramètres, l'architecture, les données d'entraînement, les tokens, la fenêtre de contexte, la spécialisation par tâche, le RAG, le fine-tuning, la quantification, les formats de poids et les contraintes de production.
Le point utile pour l'entreprise est la hiérarchie des décisions: un modèle plus large peut mieux raisonner, mais il coûte plus cher, consomme plus de mémoire et augmente la latence. Une grande fenêtre de contexte peut absorber des documents longs, mais elle ne remplace pas un RAG bien gouverné. Un modèle self-hosted peut simplifier la résidence des données, mais il transfère à l'organisation la responsabilité du run, des versions, des incidents et de la supervision.
2. Ce que cela change pour une entreprise belge ou française
Pour une PME, le changement concret est de ne pas transformer chaque cas d'usage IA en projet d'infrastructure. Beaucoup d'usages de support, rédaction, recherche documentaire ou assistance commerciale peuvent commencer par une API entreprise avec clauses de confidentialité, connecteurs limités et validation humaine. Le self-hosting devient pertinent lorsque les volumes, les données sensibles ou les contraintes contractuelles le justifient réellement.
Pour une ETI, une grande entreprise ou une administration, la sélection du modèle doit entrer dans un processus de gouvernance: classification des données, criticité métier, contraintes RGPD, localisation de traitement, coût par token, licences, preuves, contrôle des versions et capacité interne d'exploitation. Cette grille vaut autant pour un agent RAG que pour une automatisation Odoo, un assistant juridique ou un outil de BI.
3. Lecture Underside: souveraineté, agents, RAG et Odoo
L'analyse Underside est que la souveraineté IA commence avant le choix du fournisseur. Elle commence par la cartographie des données et des actions: quelles données le modèle voit-il, quelle mémoire est conservée, quels outils l'agent peut-il appeler, quels champs Odoo peut-il lire ou modifier, quelles traces permettent de reconstruire une décision et qui valide une action engageante.
Dans un projet Odoo Entreprise, la décision ne se résume pas à "API ou modèle local". Un assistant qui résume des notes internes n'a pas les mêmes exigences qu'un agent qui prépare une relance client, modifie une commande, propose un achat ou alimente une facture. Le bon modèle dépend alors du niveau d'action, de la sensibilité des champs, du besoin de citation RAG, de la latence acceptable et du coût total d'exploitation.
4. RAG, fine-tuning et modèle dédié: trois réponses différentes
Le RAG convient lorsque les connaissances changent souvent, lorsqu'il faut citer des sources ou lorsque l'organisation veut éviter de réentraîner le modèle. Le fine-tuning peut stabiliser un format, une terminologie ou un comportement récurrent, mais il ne corrige pas une mauvaise gouvernance documentaire. Un modèle dédié ou self-hosted peut être utile pour des contraintes fortes de confidentialité, mais il impose une discipline d'exploitation plus lourde.
Pour les équipes IT belges et françaises, la bonne séquence est pragmatique: mesurer le cas d'usage, construire un jeu d'évaluation local, tester plusieurs tailles de modèles, comparer RAG et prompt seul, vérifier les licences et décider ensuite de l'hébergement. La décision doit être révisable, car les prix, les modèles, les capacités matérielles et les exigences réglementaires évoluent vite.
5. Le modèle n'est qu'une partie du système
Red Hat insiste sur un point important: l'organisation doit pouvoir opérer le modèle retenu. En API managée, il faut vérifier les conditions de rétention, les régions, la connectivité privée, les journaux et les engagements contractuels. En self-hosting, il faut provisionner la capacité, maintenir l'inférence, monitorer erreurs et latence, gérer les versions, sécuriser les poids et prévoir la continuité.
Pour une stratégie Apple Enterprise, cloud local, cloud européen ou hybride, le même principe s'applique: le lieu d'exécution n'a de valeur que s'il s'accompagne de droits explicites, d'une traçabilité exploitable, d'une réversibilité documentée et d'une intégration métier propre. Le choix du modèle doit donc être un livrable d'architecture, pas une préférence technique isolée.
Priorité: établir une matrice modèle par cas d'usage avec données accessibles, action autorisée, option RAG, besoin de fine-tuning, mode d'hébergement, coût par volume, logs, validation humaine et propriétaire métier.
Structurer le choix IA