Sur scène, un agent traite une demande, consulte des documents et déclenche une action en quelques secondes. Dans l’entreprise, la même séquence doit composer avec des droits d’accès, un logiciel ancien et une facture. Le RAISE Summit, rendez-vous parisien consacré à l’intelligence artificielle, offre une entrée utile dans cet écart entre promesse et exploitation. À l’horizon de septembre 2026, la question n’est plus seulement de savoir ce qu’un modèle peut produire, mais dans quelles conditions on peut lui confier un travail. Cette analyse s’appuie sur des évolutions documentées avant cette échéance ; les prolongements vers septembre 2026 sont prospectifs, et non un compte rendu d’annonces à venir.
Le modèle le plus puissant est-il le bon ?
La course aux modèles a installé un réflexe : comparer les scores, puis choisir le premier du classement. Or une entreprise n’achète pas une place sur un podium. Elle cherche, par exemple, à extraire des clauses contractuelles ou à répondre correctement sur un catalogue. Ces tâches sollicitent des capacités différentes. Une performance moyenne élevée sur des tests publics ne garantit ni la maîtrise d’un vocabulaire métier ni la robustesse face à des documents mal structurés.
Première question à poser derrière une démonstration : sur quel jeu d’évaluation le système a-t-il été validé ? Il faut des cas représentatifs, des erreurs connues, des documents récents et des situations où la bonne réponse consiste à s’abstenir. Pour un assistant de support, mesurer uniquement la satisfaction apparente peut masquer des réponses convaincantes mais fausses. Il faut aussi suivre les résolutions effectives et les corrections humaines.
Les familles Llama, Mistral ou Qwen ont rendu crédible l’usage de modèles à poids ouverts dans de nombreux scénarios. Cela ne signifie pas automatiquement logiciel libre, absence de restrictions ou exploitation gratuite. À l’inverse, une API propriétaire peut accélérer le démarrage, tout en créant une dépendance aux tarifs, aux versions et aux conditions du fournisseur. Le bon arbitrage porte sur le système complet, pas uniquement sur la disponibilité des poids.
RAG, adaptation, agents : demander pourquoi
La génération augmentée par récupération, ou RAG, consiste à fournir au modèle des informations recherchées dans une base documentaire. Elle peut actualiser les réponses sans réentraîner le modèle. Mais elle déplace une partie du problème : les documents sont-ils correctement découpés, indexés et filtrés selon les permissions ? Si le moteur récupère une procédure périmée, le meilleur générateur peut produire une mauvaise réponse avec une assurance impeccable.
L’adaptation d’un modèle par entraînement complémentaire répond à d’autres besoins, comme stabiliser un format ou spécialiser un comportement. Elle ne remplace pas nécessairement une source documentaire actualisée. Quant aux agents, capables d’enchaîner des appels à des outils, ils ajoutent une nouvelle surface de défaillance. Une erreur de lecture peut devenir une mauvaise modification dans un logiciel métier.
La question utile devient : pourquoi cette architecture plutôt qu’une solution plus simple ? Un moteur de recherche classique, des règles explicites ou un petit modèle spécialisé peuvent suffire. Lorsqu’un agent est nécessaire, ses permissions doivent être limitées, ses actions traçables et les opérations sensibles soumises à validation. L’autonomie n’est pas une qualité absolue : c’est un niveau de risque à justifier.
L’inférence : la facture après les applaudissements
L’entraînement attire l’attention, mais l’inférence — l’exécution du modèle à chaque utilisation — façonne l’économie quotidienne du service. Une démonstration de quelques requêtes ne dit presque rien du coût lorsque des milliers d’utilisateurs arrivent ensemble. Avec une API, la tarification dépend souvent des volumes de texte traités et générés. En hébergement propre, il faut payer les accélérateurs, la mémoire, l’exploitation et la capacité réservée, même lorsqu’elle reste partiellement inutilisée.
Le coût pertinent n’est donc pas seulement celui du million de tokens. C’est le coût par tâche correctement accomplie. Un modèle moins cher qui multiplie les tentatives peut revenir plus cher. Un agent qui lance plusieurs recherches et vérifications transforme une demande en une chaîne d’appels. Les approches consacrant davantage de calcul au raisonnement renforcent cet arbitrage : une meilleure réponse éventuelle s’achète aussi en temps et en ressources.
- Combien d’appels et de tokens faut-il pour terminer une tâche réelle ?
- Quelle latence observe-t-on aux heures chargées, notamment pour les utilisateurs les moins bien servis ?
- Quelle part des résultats nécessite une reprise humaine ?
- Que devient le coût lorsque l’usage double ou que les documents s’allongent ?
La mise en cache, le regroupement des requêtes et l’orientation des tâches simples vers de petits modèles peuvent réduire la dépense. La quantification, qui diminue la précision numérique des paramètres, peut alléger les besoins en mémoire. Mais chaque optimisation demande une nouvelle évaluation : une économie technique n’a de valeur que si elle préserve la qualité nécessaire au métier.
L’infrastructure ne se résume pas aux GPU
Les accélérateurs sont devenus le symbole de la compétition en IA. Pourtant, disposer de GPU ne suffit pas. La mémoire disponible, les échanges entre machines, le stockage et la capacité à alimenter le modèle en données influencent le débit. Les longs contextes et les conversations simultanées consomment aussi de la mémoire pendant l’exécution. Une infrastructure adaptée à un test isolé peut saturer sous une charge interactive.
Il faut demander où se trouvent les marges : capacité réellement disponible, délais d’extension, alimentation électrique, refroidissement, continuité de service. Pour un projet hébergé, ces contraintes restent présentes, même si elles sont transférées au fournisseur. Les limites de débit, les engagements de disponibilité et les possibilités de bascule deviennent des éléments du produit.
La souveraineté mérite également une définition précise. Un centre de données situé en France ne règle pas à lui seul les questions de juridiction, d’accès administratif ou de dépendance logicielle. Où passent les requêtes ? Qui conserve les journaux ? Qui contrôle les clés de chiffrement ? Peut-on migrer vers un autre fournisseur sans reconstruire toute l’application ? Ces réponses valent davantage qu’une étiquette « souveraine ».
La fiabilité se construit après la démonstration
Un service d’IA évolue : les données changent, les utilisateurs trouvent des usages imprévus, une nouvelle version du modèle modifie les réponses. Il faut donc prévoir une surveillance continue, des tests de non-régression et un retour arrière. Les documents récupérés peuvent aussi contenir des instructions malveillantes : l’injection de prompt devient particulièrement préoccupante quand le système possède des outils ou des accès sensibles.
Dans le contexte européen, le règlement sur l’IA adopté en 2024 ajoute un cadre dont l’application est progressive. Les obligations dépendent notamment du rôle de l’organisation et de l’usage concerné. Sans confondre conformité juridique et sûreté technique, documenter les limites, les données et la supervision facilite les deux. À un fournisseur, il faut demander les preuves de ce travail, pas seulement une déclaration de conformité.
Et maintenant ? En septembre 2026, un prolongement plausible de ces tendances serait une sélection plus pragmatique des projets : plusieurs modèles plutôt qu’un seul, une autonomie graduée et des budgets calculés par résultat utile. Ce n’est pas une évolution acquise. Le RAISE Summit peut servir de point de rencontre entre ambition et réalité, à condition de prolonger chaque démonstration par trois demandes simples : montrez les erreurs, détaillez le coût complet et expliquez le fonctionnement quand la charge augmente. C’est là que commence l’industrialisation.
