Heroku est maintenant en mode ingénierie de maintien, et c'est un type de risque différent d'une hausse de prix
Le 6 février 2026, le chef des produits de Heroku, Nitin T Bhat, a publié un court texte intitulé « An Update on Heroku », annonçant que la plateforme passait à ce que Salesforce appelle un modèle d’ingénierie de maintien. Le texte est précis sur ce que ça signifie en pratique : les contrats Enterprise Account ne seront plus offerts aux nouveaux clients, et l’effort d’ingénierie se concentre désormais sur « la stabilité, la sécurité, la fiabilité et le soutien », avec une déclaration explicite que ça vient « plutôt que d’introduire de nouvelles fonctionnalités ». Les clients existants, dit le texte, ne voient aucun changement immédiat : le prix, la facturation et le service quotidien restent les mêmes, et les contrats Enterprise existants continuent d’être honorés et peuvent être renouvelés. Le cadrage de Salesforce lui-même pour ce virage, c’est qu’il redirige l’investissement en produit et en ingénierie vers « les domaines où nous pouvons offrir la plus grande valeur à long terme aux clients », spécifiquement les produits d’IA entreprise, ce qui est la vraie raison d’affaires derrière le changement, énoncée clairement plutôt que déduite.
C’est un type d’histoire différent des changements de prix que d’autres plateformes ont faits cette année, et ça mérite d’être traité différemment. Un prix qui augmente ou une allocation de bande passante qui se fait couper est une question de coût : faites le calcul, décidez si le nouveau chiffre fonctionne encore. Un logiciel qui cesse d’avancer est un type de risque différent, plus lent, et ça vaut la peine d’être précis sur ce que ça change vraiment au quotidien, plutôt que de tomber dans « il n’y a rien à craindre » ou « Heroku est mort », ce qui n’est ni l’un ni l’autre exact.
Que signifie vraiment « l’ingénierie de maintien » pour les utilisateurs de Heroku?
Le terme lui-même n’est pas exotique. C’est un mode reconnu dans les logiciels commerciaux à longue vie : un produit passé sa phase de croissance reçoit une équipe plus petite et dédiée dont le travail est de le garder fonctionnel, à jour et sécurisé, sans l’équipe qui bâtirait normalement ce qui vient ensuite. Le propre texte de Heroku prend soin de préciser que ce n’est pas un avis de fermeture. Les applications déjà en fonctionnement restent en fonctionnement. Les pipelines, les équipes et l’écosystème existant de modules complémentaires sont explicitement désignés comme non affectés. La facturation ne change pas pour les clients qui paient par carte de crédit via le tableau de bord. Rien de tout ça n’est du marketing; ça correspond à ce que l’ingénierie de maintien signifie partout ailleurs où on l’utilise, et le libellé de Heroku évite d’exagérer ou de minimiser la chose.
Ce que le texte confirme directement, c’est la partie qui compte pour quiconque planifie autour de Heroku pour les prochaines années : aucune nouvelle fonctionnalité. Pas « moins », pas « un rythme plus lent », la posture énoncée est que le développement de nouvelles capacités n’est plus ce que l’équipe fait. Combiné à l’absence de nouveaux contrats Enterprise pour les nouveaux clients, la lecture pratique, c’est que Heroku le produit, en date de février 2026, n’est pas quelque chose qu’une équipe devrait s’attendre à voir suivre le rythme des développements du reste de l’écosystème des plateformes. Quelle que soit l’allure de l’écosystème de buildpacks dans deux ans, quelles que soient les régions ajoutées par les plateformes concurrentes, quelle que soit la fonctionnalité de base de données gérée qui devient standard ailleurs, la réponse de Heroku à tout ça sera très probablement « ce n’est pas quelque chose qu’on bâtit », parce que l’équipe dont ce serait le travail ne fait plus ce travail.
Ce que ça coûte en pratique, pour une équipe encore dessus aujourd’hui
Pour une équipe avec une application stable, une croissance modeste, et aucun projet d’ajouter de nouveaux types de charges de travail, ça pourrait vraiment ne rien changer pendant longtemps. Le texte est honnête sur le fait que les fonctionnalités existantes continuent de fonctionner, et « stabilité, sécurité, fiabilité et soutien » est un vrai engagement, pas une coquille vide, en supposant que Salesforce s’y tienne. Les correctifs de sécurité pour l’écosystème existant de buildpacks, les corrections de bogues pour les fonctionnalités existantes, tout ça reste explicitement dans le périmètre.
L’exposition apparaît dans quelques endroits précis et prévisibles. Le soutien de nouveaux cadres applicatifs ou de nouveaux environnements d’exécution de langage est le premier : une équipe qui adopte une nouvelle version d’un cadre applicatif, ou un environnement d’exécution de langage que Heroku n’a pas déjà intégré, n’a aucune raison de s’attendre à ce que Heroku l’ajoute, parce que c’est du travail de nouvelle fonctionnalité par définition. Les nouvelles régions sont le deuxième : l’expansion d’infrastructure est du développement de produit, et une entreprise en mode maintien n’a aucune raison énoncée de bâtir de nouvelles régions, ce qui compte pour toute équipe dont les exigences de latence ou de conformité changent pendant la vie du produit. Le troisième, et celui qui s’accumule discrètement, c’est la réactivité face aux bogues qui ne sont pas critiques pour la sécurité : « stabilité et fiabilité » couvre le maintien du bon comportement existant, mais un bogue non critique, gênant plutôt que dangereux, est exactement le type de problème qu’une équipe plus petite et concentrée sur la maintenance déprioriserait raisonnablement, parce que c’est à ça que sert une feuille de route réduite. Aucun de ces éléments n’est catastrophique en soi. Ensemble, sur deux ou trois ans, ils décrivent une plateforme qui prend discrètement du retard sur la partie de l’écosystème encore activement développée, tout en continuant de bien fonctionner pour exactement la charge de travail qu’elle supportait déjà le jour de l’annonce.
Pourquoi c’est un risque structurel propre au fait de louer toute la pile
Le point le plus profond n’est pas à propos de Heroku en particulier, c’est à propos de ce que signifie dépendre entièrement de la feuille de route d’une seule entreprise pour votre propre infrastructure. Sur une plateforme entièrement gérée, un client n’a aucun chemin pour continuer à faire avancer les parties du service qu’il valorise si les priorités du fournisseur changent. Il n’y a pas de serveur à corriger soi-même, pas de couche d’infrastructure sous le produit que le client contrôle encore, c’est entièrement la feuille de route du fournisseur, et quand cette feuille de route est reprioritisée, les capacités futures de chaque client sont reprioritisées avec elle, sans possibilité de s’en exclure autrement qu’en quittant la plateforme complètement.
C’est le risque précis que représente l’ingénierie de maintien, et ça vaut la peine d’être juste sur pourquoi Salesforce a pris cette décision : une entreprise de logiciels entreprise en 2026 qui redirige ses investissements vers l’IA entreprise est une décision d’affaires rationnelle compte tenu du marché, et Heroku, qui approche les deux décennies, est un produit mature à la forme bien connue plutôt qu’un pari de croissance. Rien dans cette décision n’est imprudent ou malhonnête, l’annonce elle-même est d’une franchise inhabituelle sur ce qui change et pourquoi. Le risque n’est pas que Salesforce ait fait quelque chose de mal. C’est que tout client entièrement à l’intérieur de la pile gérée d’une seule entreprise n’a aucun levier à actionner quand les priorités internes de cette entreprise changent, parce que l’infrastructure n’a jamais été la sienne au départ.
Ce qu’un modèle à serveur apporté par le client change à ce risque précis
Une plateforme qui tourne sur des serveurs que le client possède ne peut pas éliminer complètement ce risque, le logiciel du plan de contrôle lui-même est encore bâti par une entreprise avec sa propre feuille de route et ses propres priorités qui pourraient changer. Mais ça change ce qui est vraiment en jeu si ça arrive. Le serveur lui-même, une simple machine Linux chez DigitalOcean, Hetzner ou Vultr, faisant tourner un conteneur Docker ordinaire derrière un proxy inverse standard, ne devient pas désuet parce que la feuille de route du plan de contrôle change. Si Railyard arrêtait de livrer de nouvelles fonctionnalités demain, les applications déjà déployées continuent de tourner sur une infrastructure que le client possède déjà et contrôle directement par SSH, sans dépendance envers le développement continu de Railyard pour continuer à servir le trafic. Le pire scénario pour un client dans cette situation, c’est de perdre l’accès à un tableau de bord et à une certaine commodité d’automatisation, pas de perdre l’infrastructure sur laquelle l’application tourne réellement, parce que cette infrastructure n’a jamais appartenu au fournisseur au départ.
C’est la réponse structurelle à « que se passe-t-il si l’entreprise derrière ma plateforme la déprioritise », et c’est une réponse sensiblement différente de tout ce qui est disponible pour un client sur une plateforme entièrement gérée. Ça n’exige pas que Railyard, ou toute plateforme à serveur apporté par le client, promette que ça n’arrivera jamais ici; ça exige que l’architecture rende la conséquence survivable si ça arrive, ce qui est une garantie qu’une pile louée ne peut pas offrir peu importe à quel point le fournisseur est bien géré.
Le constat honnête
L’annonce de Heroku de février 2026 n’est pas une crise pour quiconque tourne dessus aujourd’hui, et elle n’est ni malhonnête ni mal communiquée, si quoi que ce soit c’est une déclaration plus directe que ce que la plupart des entreprises donnent en déprioritisant un produit mature. La vraie leçon porte sur le type de risque lui-même : une équipe qui dépend entièrement d’une plateforme gérée dépend aussi, par construction, du fait que les décisions internes de feuille de route de cette seule entreprise restent alignées indéfiniment avec les propres besoins de l’équipe, sans filet si elles cessent de l’être. C’est une vraie propriété structurelle du fait de louer toute la pile, indépendante de la qualité ou des intentions de n’importe quel fournisseur en particulier, et ça vaut la peine d’être pesé pour ce que c’est, séparément de l’allure du prix ou de l’ensemble de fonctionnalités actuel le jour où une équipe s’inscrit.
FAQ
Quand Heroku est-il passé en mode ingénierie de maintien? Le chef des produits de Heroku, Nitin T Bhat, a annoncé ce virage le 6 février 2026, dans un texte intitulé « An Update on Heroku ».
Heroku va-t-il fermer? Non. Les applications, pipelines, équipes et modules complémentaires existants continuent de fonctionner, et les clients payant par carte de crédit ne voient aucun changement de prix ni de facturation. L’ingénierie de maintien signifie aucune nouvelle fonctionnalité et aucun nouveau contrat Enterprise pour les nouveaux clients, pas une fermeture.
Heroku va-t-il ajouter de nouvelles fonctionnalités ou régions? L’annonce est explicite : le développement de nouvelles fonctionnalités n’est plus le focus de l’équipe, ce qui veut dire qu’il ne faut pas s’attendre à de nouvelles régions ni à un nouveau support de cadre applicatif ou d’environnement d’exécution.
Est-ce un risque plus grand qu’une hausse de prix? C’est un type de risque différent. Une hausse de prix est une question de coût qu’on peut calculer une fois. Une plateforme qui cesse d’avancer est un risque qui s’accumule lentement sur des années, pendant que le reste de l’écosystème continue de livrer et qu’une plateforme figée, non.
Sources
- Heroku : « An Update on Heroku », par Nitin T Bhat, chef des produits, publié le 6 février 2026, l’annonce officielle de Heroku et Salesforce
- DeployHQ : « Heroku Enters Sustaining Engineering Mode: What It Means and When to Consider Alternatives », analyse des implications pratiques
- DevClass : « Heroku future in doubt as Salesforce freezes features to focus on AI », couverture indépendante de l’annonce de février 2026
- La page « comment ça marche » de Railyard pour les détails sur le fait de faire tourner des applications directement sur une infrastructure que vous contrôlez
Voyez comment Railyard se compare précisément pour une équipe qui évalue un changement : Comparer Railyard à Heroku, ou voyez comment Railyard tourne sur des serveurs que vous possédez.