L’IA agentique n’est pas seulement une évolution logicielle : pour les entreprises, elle impose de revoir en profondeur l’architecture informatique. Un workflow agentique ne se contente pas d’interroger un modèle isolé ; il peut coordonner plusieurs agents en parallèle, conserver un contexte étendu, dialoguer avec des bases de données et des applications existantes, puis déclencher des opérations largement conventionnelles. La vraie question n’est donc plus seulement le choix d’un accélérateur, mais la manière dont l’ensemble du système déplace les données, répartit les tâches et consomme les ressources. Par nature, l’IA agentique est hétérogène.

Les premiers usages de l’IA générative en entreprise restaient limités à des tâches ponctuelles comme le résumé de documents, la génération de contenu ou le classement d’informations. Les systèmes agentiques visent, eux, des processus de bout en bout : ils décomposent un objectif en sous-tâches, mobilisent plusieurs capacités et orchestrent des travaux auparavant répartis entre plusieurs équipes ou applications. Cette parallélisation peut améliorer la productivité, mais elle accroît aussi la complexité, plusieurs agents pouvant fonctionner simultanément.

Dans cet environnement, le GPU demeure central pour l’entraînement et l’inférence. Mais le CPU reste tout aussi important pour l’orchestration, la gestion du contexte et de nombreuses applications lancées par les agents. Surtout, les logiciels et processus existants doivent continuer à fonctionner : l’IA agentique se connecte au patrimoine applicatif, elle ne le remplace pas. Pour les DSI, ce patrimoine doit donc être considéré comme une brique de l’architecture IA, et non comme un système périphérique appelé à disparaître.

L’optimisation doit désormais se penser au niveau du système entier. Dans un data center IA, la performance utile dépend autant de la circulation des données que de la puissance brute des moteurs de calcul. Les données doivent circuler avec une faible latence entre mémoire, CPU, GPU, réseau et stockage ; à grande échelle, le moindre 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 insuffisant : il faut optimiser leur fonctionnement collectif, du matériel jusqu’à la couche applicative.

Cela revient à traiter comme un seul problème d’architecture 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. Cloud, data center central, site industriel, edge et terminaux peuvent tous participer au même processus agentique. Aucun moteur de calcul n’est optimal pour toutes les étapes : certaines exigent une forte densité de calcul, d’autres privilégient la latence, 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 devient alors un facteur déterminant de coût. Exécuter chaque requête sur le plus grand modèle disponible n’est pas soutenable économiquement. Les entreprises devront combiner différentes tailles de modèles, différents moteurs de calcul et différents lieux d’exécution. Un grand modèle centralisé pourra être nécessaire pour des raisonnements complexes, tandis qu’un modèle plus léger et spécialisé suffira pour des tâches ciblées. Dans certains cas, une exécution locale sera préférable pour la latence, la confidentialité ou la continuité, en ne transmettant vers l’infrastructure centrale que les informations strictement nécessaires.

Le coût total de possession compte désormais autant que la performance maximale d’un composant. L’évaluation doit intégrer le coût de la tâche, 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. Les modèles ouverts peuvent contribuer à cette stratégie, mais il ne s’agit pas de les opposer systématiquement aux modèles propriétaires : les entreprises utiliseront les deux. Le principe directeur consiste à appliquer à chaque étape le niveau de capacité nécessaire, sans surconsommer de ressources.

Pour les DSI, la méthode est claire : partir du processus à transformer, en identifier les é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.

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.

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.

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

The post L’IA agentique impose de repenser toute la pile de calcul appeared first on Silicon.fr.