La prémisse
La gestion cloud 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 cloud dans ce nouvel environnement.
La facture est le symptôme, pas la maladie
Les dépassements de coûts cloud 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 cloud 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 cloud 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 cloud 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 de l'UE, des États-Unis et de Suisse 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 cloud il y a cinq ans. Tous le sont maintenant.
Les mandats cloud 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 cloud 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 cloud 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 cloud, 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 cloud 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.
Trois valeurs par défaut sur chaque mandat cloud
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 cloud est invisible. L'équipe utilise l'infrastructure et cesse d'y penser.
Une architecture cloud 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 cloud, 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.
Cloud —
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.