L’IA agentique est souvent présentée comme une évolution logicielle : des agents capables de raisonner, de recourir à des outils et d’enchaîner des actions pour accomplir une tâche. Pour les entreprises, elle pose pourtant un problème d’infrastructure très concret. Un workflow agentique ne sollicite pas un modèle isolé.
Il peut coordonner plusieurs agents en parallèle, conserver un contexte étendu, interagir avec des bases de données et des applications existantes, puis exécuter des opérations qui restent largement conventionnelles. La question n’est donc plus seulement de savoir quel accélérateur choisir, mais comment l’ensemble du système déplace les données, répartit les tâches et utilise les ressources. L’IA agentique est, par nature, hétérogène.
Les agents orchestrent les applications existantes Les premiers usages de l’IA générative en entreprise étaient souvent circonscrits : résumer un document, générer du contenu ou classer des informations. Les systèmes agentiques visent des processus de bout en bout. Ils décomposent un objectif en sous-tâches, mobilisent différentes capacités et coordonnent des travaux auparavant réalisés successivement par plusieurs équipes ou applications.
Lire aussi : Mistral et Cloudera scellent un partenariat pour une IA « souveraine » Cette parallélisation peut améliorer la productivité, mais elle accroît aussi la complexité, plusieurs agents pouvant fonctionner simultanément. Dans ce contexte, le GPU reste essentiel notamment pour l’entraînement et l’inférence. Mais l’orchestration, la gestion du contexte et de nombreuses applications lancées par les agents reposent aussi sur le CPU.
Les logiciels et les processus utilisés depuis des années doivent impérativement continuer à fonctionner car l’IA agentique se connecte à cet environnement, elle ne le remplace pas. Pour les DSI, le patrimoine applicatif doit donc être considéré comme une composante de l’architecture de l’IA, et non comme un système périphérique destiné à disparaître. L’optimisation doit se faire au niveau du système Dans un data center IA, la performance utile dépend autant de la circulation efficace des données que de la puissance théorique des moteurs de calcul.
Les données doivent circuler entre la mémoire, les CPU, les GPU, le réseau et le stockage avec une faible latence. À grande échelle, tout déséquilibre peut créer un goulet d’étranglement et laisser des ressources coûteuses sous-utilisées. Optimiser chaque composant reste nécessaire, mais ne suffit plus.
Il faut optimiser leur fonctionnement collectif, du matériel à la couche applicative. Cela revient à traiter le dimensionnement des CPU et GPU, la mémoire, la bande passante réseau, le stockage, les logiciels d’orchestration et le lieu de déploiement comme un seul et même problème d’architecture. Le cloud, le data center central, le site industriel, l’edge et les terminaux peuvent tous participer au même processus agentique.
Aucun moteur de calcul n’est optimal pour chaque étape. Certaines tâches demandent une forte densité de calcul. D’autres privilégient une réponse immédiate, la proximité des données ou l’accès à des applications existantes.
Les organisations auront donc besoin de plusieurs systèmes optimisés, coordonnés par le logiciel. Le placement des workloads déterminera les coûts Exécuter chaque requête sur le plus grand modèle disponible peut rapidement devenir difficile à justifier sur le plan économique. Les entreprises devront combiner différentes tailles de modèles, différents moteurs de calcul et différents lieux d’exécution.
Lire aussi : AI Gateway : la prochaine bataille des infrastructures IA Un grand modèle centralisé peut être nécessaire pour les raisonnements complexes tandis qu’un modèle plus léger et plus spécialisé suffit pour les tâches ciblées. Dans certains cas, une exécution locale répondra mieux aux exigences de latence, de confidentialité ou de continuité en ne transmettant que les informations nécessaires à l’infrastructure centrale. Le coût total de possession devient alors aussi pertinent que la performance maximale d’un composant.
L’analyse doit porter sur le coût de la tâche accomplie, l’utilisation de l’infrastructure, les mouvements de données, le temps de réponse et la capacité de l’architecture à évoluer sans réécrire les applications. Si les modèles ouverts peuvent contribuer, il ne s’agit pas de les opposer systématiquement aux modèles propriétaires car les entreprises utiliseront les deux. Le principe directeur doit plutôt d’appliquer à chaque étape le niveau de capacité nécessaire, sans consommer davantage de ressources que nécessaire.
Pour les DSI, la recommandation est simple : partir du processus à transformer, identifier ses étapes, puis choisir pour chacune le modèle, le moteur de calcul et le lieu d’exécution les plus adaptés. À l’ère agentique, l’avantage ne viendra pas d’un composant unique, mais de la qualité de l’orchestration de l’ensemble. *Mark Papermaster est Chief Technology Officer de AMD Photo : © DR