La prémisse
La gestion infonuagique en 2026 ressemble en surface à celle d'il y a trois ans — les mêmes fournisseurs, les mêmes primitives, le même vocabulaire. En dessous, la forme de la charge de travail a suffisamment changé pour que le guide de jeu doive être réécrit.
Les charges d'inférence, les dépenses de GPU, la réglementation sur la résidence des données et les réalités opérationnelles de l'exécution de fonctionnalités d'IA à l'échelle de la production ont fait passer le nuage d'une conversation de réduction de coûts à une conversation de capacités. L'équipe qui ne le voit que comme une facture à optimiser n'est plus compétitive sur ce que l'application peut faire.
Cet article porte sur ce qui a changé, sur l'allure des nouvelles valeurs par défaut opérationnelles et sur la manière dont SDEN aborde les mandats infonuagiques dans ce nouvel environnement.
La facture est le symptôme, pas la maladie
Les dépassements de coûts infonuagiques en 2026 sont presque toujours un problème d'architecture, pas un problème de rabais.
Un schéma de mandat familier est l'équipe des finances qui fait remonter une facture infonuagique qui a doublé en six mois. Le réflexe est de négocier plus dur avec le fournisseur ou de pourchasser les coupables évidents — instances inactives, bases de données surdimensionnées, instantanés que personne n'utilise. Le réflexe capte de réelles économies au premier passage et presque rien au second.
Le véritable moteur des coûts dans les déploiements infonuagiques de 2026 est habituellement structurel : un schéma de charge de travail qui ne correspond pas au modèle de tarification des ressources sur lesquelles il s'exécute. De l'inférence d'IA en rafale sur des instances toujours actives. Des requêtes analytiques contre la base de données opérationnelle. De la sortie réseau entre régions que personne n'a remarquée à la revue d'architecture. Des journaux et des traces collectés en pleine fidélité, conservés indéfiniment.
Corriger l'architecture produit des économies d'un ordre de grandeur. Négocier le contrat en produit d'un seul chiffre. L'ordre compte.
Du provisionnement à la capacité
L'ingénierie infonuagique comprend toujours le travail qu'elle a toujours compris : conception d'architecture, provisionnement par infrastructure-comme-code, automatisation du déploiement, observabilité et la discipline opérationnelle d'exploiter la production. C'est le plancher.
Ce qui est nouveau, c'est la couche au-dessus du plancher. La planification de capacité pour des charges d'inférence aux profils de GPU en rafale et coûteux. L'architecture multirégion qui respecte la réglementation sur la résidence des données dans un monde où les règles américaines, canadiennes et de l'UE divergent de façon notable. Des modèles hybrides où la charge opérationnelle s'exécute sur le calcul le moins cher disponible et le service du modèle s'exécute là où la latence et la licence le permettent. Aucun de ces éléments n'était au cœur du travail de l'ingénieur infonuagique il y a cinq ans. Tous le sont maintenant.
Les mandats infonuagiques de SDEN ressemblent de plus en plus à des mandats d'architecture — concevoir la forme du déploiement — plutôt qu'à des mandats de provisionnement. Le provisionnement est automatisé depuis des années; la conception, non.
Valeurs par défaut opérationnelles pour une charge façonnée par l'IA
Les charges d'IA brisent certaines des hypothèses sur lesquelles s'appuient les architectures infonuagiques classiques. Elles sont en rafale plutôt que stables, coûteuses par appel plutôt que par octet, dépendantes de fournisseurs tiers dont l'architecte infonuagique ne contrôle ni la latence ni la disponibilité, et sensibles à l'endroit où les données sont physiquement situées d'une manière dont le reste de l'application ne l'est pas.
Les valeurs par défaut opérationnelles qui fonctionnent pour cette forme sont différentes. La mise en cache, le traitement par lots et la dégradation gracieuse à la couche applicative deviennent des préoccupations de premier plan. L'abstraction du fournisseur à la couche du modèle devient obligatoire, parce que chaque trimestre le bon modèle est un modèle différent. Et l'observabilité des coûts doit être câblée dans l'application elle-même, pas seulement dans la facture infonuagique, parce que les unités économiques d'une fonctionnalité d'IA se décident par requête et doivent être visibles par requête.
Quand SDEN conçoit une architecture infonuagique pour un produit qui utilise l'IA, c'est là que va l'essentiel du travail — pas dans les manifestes Kubernetes, mais dans la couche qui décide de ce qui se passe quand le modèle prend trop de temps, coûte trop cher ou retourne la mauvaise chose.
Ce qui change dans la pile infonuagique quand l'IA arrive
Quatre changements pratiques visibles dans les déploiements de production où l'IA est devenue une partie porteuse de l'application.
La capacité est planifiée par rapport à des profils de CPU et de mémoire en régime permanent. L'autoscaler maintient la grappe dans la plage et la facture est prévisible.
La capacité est planifiée par rapport à des profils de GPU en rafale avec des écarts d'un ordre de grandeur entre l'inactivité et le pic. Les décisions de l'autoscaler sont maintenant des décisions d'affaires : plus de capacité signifie plus de coût par requête.
À retenir · La planification de capacité devient une conversation d'unités économiques, pas une conversation de SRE.
L'observabilité suit la latence des requêtes, les taux d'erreur et la saturation — les signaux d'or classiques.
L'observabilité suit la latence du modèle, les erreurs du modèle, le coût par requête du modèle, la qualité de sortie du modèle et le taux de succès de cache qui détermine si la fonctionnalité est solvable.
À retenir · Le tableau de bord que regarde le SRE a de nouvelles lignes. Certaines appartiennent à l'équipe produit.
La facture infonuagique est ventilée par service : calcul, stockage, réseau.
La facture infonuagique est ventilée par fonctionnalité de produit, avec les dépenses du modèle attribuées au flux de travail qui les a déclenchées. Les finances peuvent répondre à la question de ce qu'une fonctionnalité d'IA coûte réellement.
À retenir · L'attribution devient un livrable d'ingénierie de premier plan, parce que l'alternative est de voler à l'aveugle.
La sélection de région est une décision d'architecture ponctuelle au lancement du projet.
La sélection de région est réévaluée chaque fois qu'une nouvelle réglementation tombe ou qu'un nouveau fournisseur ouvre une région — et l'architecture est conçue pour que le déménagement soit un changement de configuration, pas une réécriture.
À retenir · Les règles de résidence des données évoluent maintenant plus vite que les projets. L'architecture doit suivre.
Trois valeurs par défaut sur chaque mandat infonuagique
Nous ne livrons pas des nuages. Nous livrons des architectures qui se trouvent à s'exécuter sur un nuage. Les piliers ci-dessous sont ceux auxquels nous tenons.
Infrastructure-comme-code, de bout en bout
Chaque morceau de l'infrastructure est décrit en code, versionné, révisé et reproductible. Nous ne faisons pas de la production au clic. Nous ne faisons pas non plus de la préproduction au clic.
Observabilité des coûts au niveau de la fonctionnalité
Le coût est attribué aux fonctionnalités et tracé jusqu'aux requêtes qui l'ont provoqué. Les surprises dans la facture deviennent des exceptions, pas la norme.
Portabilité de région et de fournisseur là où ça compte
Nous choisissons un nuage comme base d'attache, mais l'architecture garde des voies de sortie ouvertes pour les charges qui pourraient en avoir besoin — pour des raisons de résidence des données, de nuage souverain ou de coût.
L'infrastructure dans laquelle l'équipe a confiance pour grandir
Le succès infonuagique est invisible. L'équipe utilise l'infrastructure et cesse d'y penser.
Une architecture infonuagique qui fonctionne permet à l'équipe d'ingénierie de se concentrer sur le produit, pas sur la plomberie. Les déploiements sont routiniers. La facture est prévisible, et lorsqu'elle ne l'est pas, l'équipe peut expliquer pourquoi. La capacité est provisionnée en avance de la demande et décommissionnée quand la demande prend fin. On répond aux organismes de réglementation avec une documentation qui a été générée, pas assemblée après coup.
Quand SDEN termine un mandat infonuagique, le test est simple : l'équipe d'ingénierie exploite-t-elle le système sans nous, confortablement, six mois plus tard. Si elle a besoin de nous, nous n'avons pas fait le travail.
La technologie sous le capot importe moins que cette propriété. Ce peut être AWS, GCP, Azure ou un hybride; ce peut être Kubernetes, Nomad ou sans serveur. Ce que ça ne peut pas être, c'est une boîte noire qu'un seul ingénieur comprend.
Infonuagique:
les questions qu'on nous pose.
Des réponses directes aux questions qu'on nous pose le plus souvent. Si la vôtre n'y est pas, écrivez à l'équipe.