La prévision changeante du cloud

Un modèle que j’ai déjà vu

J’étais professionnel lorsque le cloud est devenu une chose. De ce point de vue, j’ai vu l’adoption initiale : l’excitation, la flexibilité, le sentiment que tout allait aller plus vite. Cela a conduit à une adoption massive, où chaque charge de travail était un candidat et chaque fournisseur avait une histoire de cloud.

L’adoption, cependant, n’était que la moitié de ce que j’ai vu. Ensuite, j’ai vu l’autre côté : la répatriation. Les entreprises déplaçaient des charges de travail spécifiques vers l’arrière, se demandant si chaque application avait vraiment besoin de flexibilité cloud. Ce deuxième mouvement s’est produit pour une raison. Avec les changements économiques et la maturité des charges de travail, les hypothèses qui faisaient du cloud le choix évident pour littéralement tout ont cessé de tenir une fois que les organisations ont commencé à les examiner à grande échelle.

Ayant vécu le cycle complet une fois, je reconnais sa forme lorsqu’il commence à se former à nouveau. Maintenant, alors que j’aide les entreprises à déterminer ce que l’IA devrait réellement faire dans leurs environnements, le modèle d’adoption/rapatriation massif commence à me sembler familier.

La correction du cloud

Pour comprendre pourquoi la ressemblance est importante, il aide de commencer par ce qui s’est réellement passé au cloud, sur ses propres termes. Le passage au cloud était rationnel. Il a supprimé les frictions, donné aux organisations de la flexibilité et de la vitesse, et avait du sens pour les charges de travail qui étaient incertaines ou en constante évolution. C’était rationnel parce que c’était construit pour un type spécifique de travail. Les équipes DevOps sont allées cloud-first parce que le cloud était construit pour le travail qui est itératif, variable ou difficile à prédire.

Mais la chose qu’ils construisaient n’est pas restée immobile. Le cloud n’a pas changé, mais les charges de travail si. À mesure que les processus mûrissaient et devenaient prévisibles, les organisations ont pris conscience des coûts liés à la récupération de leurs propres données. Les frais de sortie, les coûts de stockage, les frais de transfert : des dépenses qui étaient faciles à ignorer lorsque la flexibilité en valait la peine, et difficiles à ignorer une fois que les charges de travail se sont stabilisées. En 2024, après des années de facturation pour la sortie de données, AWS, Azure et Google Cloud ont tous annulé ces frais pour les clients qui migraient hors de leurs plateformes, comme l’a rapporté DataCenterDynamics.

Une fois que ces coûts étaient visibles, les mathématiques ont cessé de fonctionner pour une part croissante du portefeuille. Les économies qui avaient rendu le cloud une bonne stratégie avec quelques inconvénients sont devenues économiquement non viables pour un nombre croissant de charges de travail orientées vers l’IA. Les entreprises ont affiné leurs crayons et se sont demandé si chaque application avait réellement besoin de ce que le cloud offrait. Lorsqu’ils ont réellement exécuté les chiffres, la réponse, pour un grand nombre de charges de travail, était non.

Ces réponses accumulées sont devenues une correction que l’industrie a mal étiquetée. Cette correction a été appelée “répatriation du cloud”, et elle est décrite de manière incorrecte la plupart du temps. Il s’agit en réalité de la maturité des charges de travail : des entreprises matures apprenant à faire correspondre chaque charge de travail au modèle d’infrastructure qui lui convient. Les données soutiennent la lecture sélective plutôt que la lecture globale. L’IDC a constaté que près de 80 % des organisations s’attendent à une certaine répatriation au cours des 12 prochains mois, même si moins de 10 % ont répatrié des charges de travail entières, selon les rapports de CIO.com.

Lire correctement, la conclusion n’est pas que le cloud était une erreur. Le cloud reste précieux, mais il a cessé d’être universel. L’état mature est hybride : le cloud où il a gagné sa place, l’infrastructure privée ou dédiée partout ailleurs.

Même courbe de correction, technologie différente

Cette courbe est maintenant terminée et étiquetée. La même forme commence à se former avec l’IA. Chaque fournisseur, chaque conférence, chaque appel de vente est actuellement sur l’IA. La saturation est identique à ce que j’ai vu se produire avec le cloud. Les dépenses sous-jacentes au bruit sont réelles : Gartner prévoit des dépenses mondiales en IA générative de 644 milliards de dollars en 2025, en augmentation de 76,4 % d’une année sur l’autre.

La même saturation implique la même correction à venir. Je crois qu’une correction similaire est en route, non pas parce que l’IA est mauvaise, mais parce que la même dynamique qui a produit la répatriation du cloud s’applique ici également. Elle est en route parce que les organisations poussent fort dans les flux de travail basés sur l’IA sans toujours savoir, dans leurs propres environnements, comment l’histoire se termine. L’écart entre l’adoption et la maturité est mesurable : McKinsey constate que 88 % des organisations signalent désormais une utilisation régulière de l’IA dans au moins une fonction, mais la majorité est toujours en phase de test et seulement environ 39 % signalent un impact EBIT au niveau de l’entreprise.

Pousser trop fort sans stratégie et le règlement de comptes n’est pas un peut-être. Cette correction arrive. Elle arrive toujours. Vous poussez trop fort sans stratégie, et éventuellement, les économies et la réalité opérationnelle obligent à un règlement de comptes.

Il y a déjà un nom pour le modèle correctif, et il n’est pas le mien. La répatriation de l’IA, l’acte de déplacer des tâches spécifiques hors des systèmes de probabilité IA et de les ramener dans des flux de travail déterministes une fois que ces tâches sont stables et répétitives, n’est pas un concept que j’ai inventé. C’est un modèle que je vois se dérouler. Je ne suis pas le seul à le voir : Gartner prévoit que plus de 40 % des projets d’IA agente seront annulés d’ici la fin de 2027, citant les coûts croissants, la valeur commerciale peu claire et les contrôles de risque inadéquats.

À quoi ressemble la correction de l’IA

Pour anticiper la correction, il aide d’avoir des définitions claires pour les deux types de flux de travail impliqués.

Un flux de travail déterministe est basé sur des règles, prévisible et répétitif. La même entrée et les mêmes règles produisent la même sortie, chaque fois. Il est rapide, il est fixe. Il fait exactement ce pour quoi il est conçu, rien de plus, rien de moins. Un flux de travail probabiliste utilise l’IA ou le raisonnement basé sur des modèles pour interpréter le contexte et produire une réponse probable. Il est utile lorsque les processus impliquent de l’ambiguïté, des informations non structurées ou des appels de jugement où les règles fixes se brisent et les inférences supportent la charge.

Avec les définitions établies, la question de timing se répond d’elle-même. Les flux de travail probabilistes sont souvent l’outil approprié au début, lorsque les processus ne sont pas encore pleinement compris. Ils deviennent problématiques lorsque les entreprises continuent à les utiliser lorsque les processus sont clarifiés.

Un flux de travail concret rend cette distinction tangible entre le début et la fin. Une partie de ce flux de travail nécessite réellement l’IA. Identifier le bon compte à partir d’une transcription d’appel, par exemple, nécessite des inférences qu’un système déterministe ne peut pas faire. D’autres parties, comme joindre un fichier à un enregistrement ou publier une notification, sont des tâches déterministes. Une règle fixe, un appel d’API direct, est la même sortie chaque fois. Je suis coupable de cela moi-même : je suis actuellement en train de construire une automatisation interne qui relie les transcriptions d’appel, achemine les informations vers notre CRM, attribue des éléments d’action et pousse les mises à jour vers Slack.

La tentation est de faire tourner tout cela à travers l’IA, et cette tentation comporte un fardeau réel et récurrent. Alors que l’on est tenté de faire tourner l’ensemble du processus à travers des appels IA, chaque appel IA introduit de la latence et comporte des coûts d’utilisation et d’infrastructure. Les systèmes IA nécessitent une surveillance, une gestion de prompt et des garde-fous, car le modèle sous-jacent est en constante évolution (et de manière imprévisible) par son propriétaire. Vous ne savez jamais quand il commencera à se comporter différemment ; les sorties peuvent varier de manière à créer des problèmes de gouvernance à grande échelle, rapidement.

Joué suffisamment loin, ce fardeau se transforme en pur gaspillage. Pensez à une entreprise qui utilise l’IA pour analyser 50 000 tickets de support. L’IA identifie les cinq chemins de résolution les plus courants. Au début, l’IA gère la routage de manière probabiliste : en lisant chaque ticket et en faisant un jugement. Au fil du temps, l’entreprise valide ces modèles. Les chemins de résolution sont maintenant connus. Les convertir en branches de flux de travail déterministe ne retire pas l’IA du processus, mais il retire la pratique redondante de payer l’IA pour redécouvrir des réponses qui sont maintenant connues.

C’est l’impôt probabiliste : le coût supplémentaire, la latence et le fardeau de gouvernance de l’exécution de l’IA comme runtime pour le travail qui n’a plus besoin de raisonnement probabiliste.

À quoi ressemblent les modèles d’exploitation matures

Si exécuter un travail résolu sur l’IA est un impôt, le mouvement mature est de diviser le travail par type. La maturité du cloud a produit une infrastructure hybride, le cloud où il a gagné sa place, l’infrastructure dédiée partout ailleurs. Je prédis que la maturité de l’IA produira des opérations hybrides avec la même logique.

Cette division produit une règle d’exploitation claire. Les systèmes probabilistes sont précieux là où il existe une ambiguïté réelle. Les humains sont ambigus. Les données non structurées sont ambigues. Les processus qui ne sont pas encore pleinement compris sont ambigus. L’inférence est l’outil approprié pour tout cela. L’autre moitié de la règle est tout aussi importante : les systèmes déterministes sont là où l’échelle, le coût, la vitesse et la gouvernance sont importants. La couche probabiliste découvre et interprète. La couche déterministe exécute.

Sur le terrain, deux signaux vous indiquent à quel côté une charge de travail donnée appartient :

1. Si vous constatez que votre équipe s’appuie sur l’IA pour quelque chose qui est devenu stable, répétitif et bien compris, c’est un candidat pour la répatriation, car vous payez un impôt probabiliste pour un travail déterministe.
2. Si vous constatez que votre code déterministe se remplit de gestionnaires d’exceptions et de considérations de variabilité, c’est un signe que vous avez peut-être réellement besoin de l’IA. L’ensemble de règles tente d’approximer l’inférence.

Dans la pratique, cette limite est tracée comme un seuil de confiance. Un seuil de confiance spécifique, s’engageant à prendre une décision lorsque le modèle est supérieur à 90 % certain, ou échouant de manière élégante en dessous, est souvent là où cette limite est tracée dans la pratique.

Cela reframe ce que gagner avec l’IA nécessite réellement. Les entreprises les plus réussies qui adoptent l’IA ne seront pas celles qui l’utilisent le plus, mais celles qui savent quand l’utiliser et quand la suppléer.