L'IA ressemble aux débuts du cloud : la vraie course est opérationnelle

Au cours des deux dernières années, l'essentiel du bruit autour de l'IA s'est concentré sur la course aux modèles – quel modèle est plus grand, plus rapide ou obtient de meilleurs scores aux benchmarks. Mais alors que l'IA passe des pilotes au cœur des produits et des workflows, un schéma familier des débuts du cloud computing réémerge : les systèmes sont plus programmables que jamais, mais aussi beaucoup plus difficiles à exploiter. Cela signifie que la compétition la plus importante dans l'IA se déplace : de celui qui a le « meilleur » modèle à celui qui peut opérer l'IA de manière fiable, efficace et sécurisée à grande échelle.

En examinant la télémétrie réelle de milliers de systèmes de production, un tableau clair se dessine. Près d'une requête IA sur cinq échoue une fois que les applications atteignent l'échelle, et la majorité de ces échecs proviennent désormais de limites de capacité telles que les limites de débit, les quotas et les limites de concurrence, plutôt que de bugs de modèle ou d'une faible précision. C'est une histoire très différente des graphiques de benchmarks que la plupart des équipes utilisaient pour obséder. La quantité de données envoyées par requête augmente également : les utilisateurs médians ont plus que doublé leur utilisation de tokens, tandis que les utilisateurs intensifs ont vu leurs volumes croître plusieurs fois. Cette croissance est à la fois un symptôme de cas d'utilisation plus ambitieux de l'IA et un moteur direct des coûts et du stress sur l'infrastructure informatique.

L'impact est le plus visible dans ce que de nombreuses équipes décrivent maintenant comme l'étalement des GPU : des parcs fragmentés répartis entre clouds et clusters sur site. Certains GPU sont inactifs tandis que d'autres sont constamment saturés, et il y a très peu de corrélation entre l'endroit où les heures GPU sont dépensées et où elles créent de la valeur commerciale. Le résultat est familier à quiconque a vécu l'adoption précoce du cloud computing : des dépenses incontrôlées, des performances imprévisibles et des crises de capacité qui surgissent de nulle part.

Dans la région Asie-Pacifique, et en particulier dans l'ASEAN, nous observons actuellement des pressions structurelles : l'adoption de l'IA s'accélère, mais la maturité opérationnelle est inégale. Singapour est plus avancé en matière de gouvernance et d'observabilité, en partie grâce aux attentes réglementaires et à un paysage cloud plus mature. Pendant ce temps, des marchés comme l'Indonésie, la Malaisie et la Thaïlande avancent très rapidement sur le déploiement, poussant souvent l'IA dans les services destinés aux clients alors que les pratiques opérationnelles rattrapent leur retard. Les organisations sont confrontées à des problèmes de fiabilité, une visibilité limitée et des performances de modèle incohérentes. L'utilisation des tokens augmente rapidement, mais les pratiques d'optimisation, comme la mise en cache des prompts et l'ingénierie du contexte, sont sous-utilisées.

Pour réussir durablement, les équipes IA doivent adopter quatre disciplines opérationnelles. La première est d'établir la visibilité et l'attribution : il faut voir comment les heures GPU et les tokens correspondent à des applications, équipes et cas d'utilisation spécifiques, afin de relier cette utilisation à la latence, aux taux d'erreur et à l'impact utilisateur. La deuxième est d'imposer des contrôles et des garde-fous : sans eux, les systèmes IA consommeront autant de capacité que vous leur donnez. Les mesures pratiques incluent les limites de débit, les plafonds budgétaires et des protections contre les boucles infinies. La troisième est d'optimiser l'utilisation des GPU avant d'augmenter l'offre : la plupart des équipes se tournent vers plus de GPU alors qu'elles ont en réalité un problème d'utilisation. La quatrième est d'adopter une discipline financière similaire au FinOps pour le cloud afin de gérer les coûts de l'IA. Ces disciplines aideront les équipes à gérer la complexité et à éviter les dettes opérationnelles et de coûts.