Le Bambu Lab cloud a encaissé un pic à 20 millions de requêtes par jour sur un seul endpoint, et la marque a coupé l’accès sans prévenir personne. Derrière cette coupure, il n’y a ni attaque, ni botnet, ni concurrent jaloux. Il y a une intégration Home Assistant, un en-tête copié sur OrcaSlicer et une image de couverture qui ne se téléchargeait plus. Toute l’histoire est publique, documentée sur GitHub par un ingénieur de Bambu Lab lui-même, et elle dit tout haut ce que beaucoup d’ateliers découvrent trop tard : le Bambu Lab cloud reste un service privé, révocable, sans préavis et sans engagement de disponibilité.

Je n’ai pas de machine dans cette histoire, je n’ai pas reçu de communiqué et je n’ai aucun lien avec les projets cités. Ce que je fais ici, c’est lire le rapport, regarder ce que le Bambu Lab cloud a le droit de faire, recouper avec la presse spécialisée et en tirer ce que ça change concrètement pour toi, que tu aies trois imprimantes dans un garage ou trente dans un local commercial.

🚨 Ce qui s’est passé entre le 9 et le 12 novembre

Le point de départ est daté, et c’est rare. Dans le rapport public ouvert le 11 novembre sur le dépôt de l’intégration ha-bambulab, un ingénieur de Bambu Lab écrit noir sur blanc que depuis le 9 novembre 2026, la marque voit grossir très vite le volume de requêtes GET /v1/user-service/my/tasks envoyées au Bambu Lab cloud, l’appel qui renvoie le statut des tâches d’impression. Toutes ces requêtes arrivent de dizaines d’adresses IP résidentielles et portent l’identité client d’OrcaSlicer.

Au pic, le Bambu Lab cloud encaisse environ 20 millions de requêtes par jour, toutes servies en 200, et Bambu Lab explique que le Bambu Lab cloud approchait de sa limite de capacité. La sanction tombe vite : la marque bloque l’identité fautive pour protéger le Bambu Lab cloud. Le journal allemand 3Druck ajoute deux chiffres que je n’ai vus nulle part ailleurs : le trafic a été multiplié par 34 en une heure, et à ce rythme le Bambu Lab cloud serait tombé en quelques heures, ce qui aurait bloqué l’impression de millions d’utilisateurs. La même source précise que la coupure a touché des utilisateurs pendant que l’équipe ajustait ses règles, et que tout est rentré dans l’ordre depuis.

Une précision qui compte : la page de statut officielle de Bambu Lab n’affiche aucun incident pour le 11 ni pour le 12 novembre. Je l’ai vérifiée avant d’écrire. Un blocage volontaire d’un client tiers n’est pas une panne du point de vue du constructeur, et c’est exactement le genre de nuance qui fait mal quand tu construis un process dessus. Ton tableau de bord se vide, tes capteurs passent en indisponible, et côté fournisseur tout est vert.

🔍 La vraie cause : une image de couverture qui ne se télécharge plus

Le diagnostic technique est d’une précision rare, et c’est ce qui rend l’affaire intéressante. Bambu Lab ne se contente pas de dire « votre logiciel surcharge nos serveurs ». L’ingénieur pointe les lignes de code. Dans la version 2.3.0 de l’intégration, le déclencheur de rechargement des tâches a été élargi : il couvre désormais les états RUNNING, PAUSE et FINISH, plus l’état précédent « unknown ». Or une imprimante qui reste en FINISH satisfait cette condition à chaque message de statut.

Deuxième piège, plus vicieux : quand l’image de couverture du modèle ne peut pas être téléchargée, le code remet un drapeau à zéro et prévoit une temporisation de 300 secondes. Sauf que cette temporisation n’est vérifiée que dans la branche RUNNING. La branche FINISH et PAUSE ne la consulte jamais. Résultat : une imprimante qui reste en FINISH pendant que le média est introuvable relance l’appel au Bambu Lab cloud à chaque message, sans aucun garde-fou.

Bambu Lab a reproduit un cas concret, et c’est là que l’histoire devient très concrète pour un atelier. Sur une P2S en firmware 01.02.00.00, en mode cloud, avec la version 2.3.0 : tu laisses l’imprimante en FINISH, tu renommes le fichier .gcode.3mf du job pour qu’il ne corresponde plus, tu redémarres Home Assistant. L’appel « Getting latest task for printer from Bambu Cloud » est réémis 16 fois en 6 minutes, tous en 200, chacun précédé d’un échec de téléchargement du modèle. Tu remets le fichier en place et tu redémarres : zéro requête en 40 secondes.

L’honnêteté de Bambu Lab mérite d’être soulignée, parce qu’elle est loin d’être la norme. Le rapport dit aussi ce qu’il ne sait pas : la cadence soutenue d’environ une requête toutes les 5 secondes observée en production n’a pas été reproduite, et « on ne peut pas encore affirmer que c’est le mécanisme derrière le trafic de production ». Une marque qui écrit ça dans un ticket public, c’est quelqu’un qui préfère comprendre que gagner. Cela ne change rien à la coupure, mais ça change la façon de lire l’événement.

🎭 OrcaSlicer accusé le premier, à cause d’un en-tête recopié

Le détail qui fait mal, c’est l’usurpation d’identité. Les requêtes qui ont saturé le Bambu Lab cloud portaient un en-tête User-Agent: bambu_network_agent/01.09.05.01, un X-BBL-Client-Name: OrcaSlicer, un X-BBL-Client-Version: 01.09.05.51, un X-BBL-OS-Version: 6.2.0 et aucun X-BBL-Device-ID. Autrement dit : tout pointait vers OrcaSlicer, le slicer open source que je suis depuis des mois.

Bambu Lab a donc contacté l’équipe OrcaSlicer en premier. Mauvaise piste : l’équipe a collaboré, cherché de son côté, et a orienté la marque vers d’autres intégrations qui reproduisaient le même motif. C’est comme ça que la trace a mené à ha-bambulab. Bambu Lab précise d’ailleurs que « d’autres projets copient cette identité », donc l’en-tête seul ne prouve rien, et l’entreprise n’a jamais confirmé que la totalité du trafic venait de cette intégration. 3Druck le dit aussi clairement.

Voilà pourquoi cette affaire dépasse largement Home Assistant. Un écosystème où chacun se présente sous le nom d’un autre devient impossible à diagnostiquer : quand un problème arrive, la marque bloque le mauvais projet, les utilisateurs du bon projet paient, et personne ne comprend pourquoi. Je l’ai déjà écrit à propos du firmware Prusa et des bobines NFC, l’identification propre n’est pas un détail administratif, c’est de l’hygiène d’infrastructure, et le Bambu Lab cloud en dépend autant que les makers.

🛠️ Le correctif en une demi-heure, publié le soir même

La chronologie du dépannage est presque gênante de rapidité. Le rapport est ouvert à 14 h 14 UTC le 11 novembre. À 16 h 20, le mainteneur principal répond : « c’est définitivement cette intégration, j’enquête, et si je ne trouve pas de correctif immédiat je désactive ce chemin de code ». Treize minutes plus tard il ajoute que le changement de code identifié est bien le problème, que ce qui devait être un appel unique par impression est devenu répétitif. La pull request de correction part à 16 h 32, la version 2.4.0 sort à 16 h 40.

Deux choses ont été corrigées, et la seconde est la plus intéressante pour la suite. D’abord le retour en arrière sur le changement fautif, avec un en-tête qui identifie enfin le projet proprement. Ensuite, une pull request séparée qui construit l’agent utilisateur à partir de la version de l’intégration : ha-bambulab/v2.4.0 au lieu du ha-bambulab/v1 figé d’avant. Conséquence directe : un futur blocage pourra viser une seule version fautive au lieu de toutes les installations de tous les utilisateurs. Le mainteneur précise que les installations encore en 2.3.0 continuent d’envoyer l’ancien en-tête et restent bloquées tant qu’elles ne mettent pas à jour. 289 tests passent sur la pull request.

Un détail à ne pas rater dans les notes de version : elles parlent d’un bug de « v2.30.0 ». C’est une coquille, la version fautive est la 2.3.0. Si tu lis vite, tu cherches un numéro qui n’existe pas. Ça n’enlève rien au travail abattu en une soirée par des bénévoles, mais ça montre aussi qu’une release publiée en urgence se relit mal.

🚧 Ce que Bambu Lab autorise encore aux logiciels tiers

La position officielle de la marque, telle que la résume 3Druck, est plus nuancée que ce que les réseaux sociaux en ont retenu. Les programmes d’autres éditeurs peuvent toujours interroger l’imprimante pour récupérer la température, la position, la vitesse et la progression d’impression. Ce qu’ils ne peuvent pas, c’est envoyer un volume de requêtes déraisonnable vers le Bambu Lab cloud, et Bambu Lab se réserve le droit de limiter ou de bloquer temporairement l’accès quand le service est menacé.

En revanche, les fonctions qui touchent directement à la machine restent fermées aux logiciels tiers : lier une imprimante à un compte, le flux vidéo en direct, le lancement d’une impression et les mises à jour de firmware. Pour piloter une imprimante depuis un programme extérieur, la marque renvoie vers Bambu Connect, son outil maison, dont la première fenêtre propose deux chemins : se connecter au compte ou découvrir les imprimantes en mode LAN. C’est écrit dans sa documentation officielle, pas dans une note interne qui aurait fuité.

Et la demande de la marque aux développeurs est simple : que chaque logiciel se présente sous son propre nom. Parce que le vrai coût de l’anonymat, on vient de le voir, c’est un blocage collectif décidé sur la foi d’un en-tête trompeur.

💼 Ce que ça change pour un atelier qui facture

Sur le papier, l’incident est réglé en une soirée. Dans un atelier, la facture est ailleurs. Si ton suivi de production passe par le Bambu Lab cloud, une coupure de trois heures, c’est trois heures sans savoir où en sont tes plateaux. Sur une ferme de vingt machines qui tournent la nuit, ça veut dire des pièces qui s’accumulent sans que personne ne sache lesquelles sont sorties, et un client qui appelle pendant que tu cherches l’information.

Le point le plus important n’est pas la panne du Bambu Lab cloud, c’est la gouvernance. Un Bambu Lab cloud propriétaire peut limiter ou couper ton accès quand il estime son service en danger, et il n’a aucune obligation de te prévenir ni de déclarer un incident. La page de statut restera verte. Ce n’est pas de la malveillance, c’est la définition même d’un service fermé : la disponibilité est garantie pour les usages prévus, pas pour les usages que tu inventes.

Je l’ai mesuré autrement quand j’ai regardé les fermes d’impression qui tournent en production : celles qui tiennent la charge ne pilotent pas tout par le Bambu Lab cloud. Elles gardent un chemin local, un tableau de bord maison et une alerte qui ne dépend pas d’un serveur à Shenzhen. Tu peux lire mon décryptage sur les 2 300 Snapmaker U1 d’une ferme d’impression 3D : la logistique compte plus que la fiche technique, et la supervision encore plus.

🧠 Mes quatre règles pour ne pas dépendre du Bambu Lab cloud

Je ne vais pas te dire de jeter tes Bambu Lab. J’en utilise, elles impriment vite et bien, et cette coupure visait un usage que le Bambu Lab cloud n’a jamais promis de supporter. Mais après avoir lu ce rapport en entier, voilà ce que j’applique et que je conseille à quiconque facture une pièce imprimée.

1. Un chemin local d’abord, le cloud ensuite. Mode LAN quand tu peux, supervision locale quand tu peux, et le Bambu Lab cloud seulement pour ce qu’il apporte vraiment : l’accès à distance et les fonctions qui n’existent pas en local. Si ton seul moyen de savoir ce que fait une machine passe par le Bambu Lab cloud et par Internet, tu n’as pas une supervision, tu as une dépendance.

2. Épingle les versions de tes intégrations. La version 2.3.0 de ha-bambulab a cassé quelque chose sans que personne ne touche à rien, simplement en élargissant une condition. Une mise à jour automatique un vendredi soir, sur un outil qui parle au Bambu Lab cloud, c’est un risque que je ne prends plus. Je lis les notes de version avant de valider, surtout quand le mot « critique » apparaît.

3. Frappe à la bonne porte, avec ton nom. Ce blocage a coûté du temps à OrcaSlicer pour rien. Si tu bricoles un script qui interroge une API constructeur, mets un en-tête qui dit qui tu es et quelle version tu utilises. Ça ne te protège pas d’un blocage, ça évite que le blocage tombe sur quelqu’un d’autre.

4. Prévois la disparition d’une fonctionnalité. Live view, lancement à distance, mise à jour de firmware : ce sont exactement les fonctions que le Bambu Lab cloud réserve aux outils de la marque, et elle peut les refermer. Un process qui repose sur l’une d’elles doit avoir une solution de repli qui ne passe pas par le Bambu Lab cloud, un bouton, un écran, une personne qui passe devant la machine.

Cette histoire a un autre mérite : elle montre à quoi ressemble une intégration open source respectueuse. Un rapport précis, un mainteneur qui répond en deux heures, un correctif publié le soir, des tests, et un mainteneur qui assume publiquement l’erreur. Si tu veux voir l’autre bout de la chaîne, mon article sur OrcaSlicer et ses six bénévoles raconte comment un logiciel gratuit tient tête à un constructeur. Et pour la partie firmware et consommables, l’affaire du AMS 3H et de ses 7 bobines est un bon rappel de la vitesse à laquelle l’écosystème bouge.

✅ Mon verdict

La marque a protégé son Bambu Lab cloud, et sur le fond je comprends la décision : 20 millions de requêtes par jour sur un endpoint de statut, personne ne laisse tourner ça. La communauté a corrigé en quelques heures, proprement, avec des tests et une transparence que beaucoup d’éditeurs devraient copier. Mais l’événement laisse une trace plus utile qu’un simple fait divers.

Le Bambu Lab cloud n’est pas une infrastructure publique. C’est un service privé, avec des règles écrites par la marque, applicables sans préavis, et une page de statut qui ne bougera pas quand ton accès est coupé. Tant que tu imprimes pour toi, le Bambu Lab cloud suffit. Dès que tu imprimes pour quelqu’un qui paie, ça devient un risque de production à documenter, avec un Bambu Lab cloud dont les règles peuvent changer du jour au lendemain, exactement comme une pièce d’usure ou un délai de livraison.

❓ FAQ : le blocage du Bambu Lab cloud en quatre questions

Pourquoi Bambu Lab a bloqué OrcaSlicer ?

Bambu Lab n’a pas bloqué OrcaSlicer, elle a bloqué une identité client qui portait le nom d’OrcaSlicer, et le Bambu Lab cloud a refusé cette identité pendant quelques heures. Les requêtes venaient d’une intégration qui se présentait avec les en-têtes d’OrcaSlicer. Après enquête commune avec l’équipe OrcaSlicer, la piste a mené vers l’intégration Home Assistant ha-bambulab, en version 2.3.0, et la marque n’a pas confirmé que la totalité du trafic venait de là.

Mes impressions en cours ont-elles été perdues ?

Non. Ce qui a été coupé, c’est l’accès au Bambu Lab cloud pour une identité client donnée, pas les imprimantes. Les machines continuent d’imprimer, et le rapport précise que le Bambu Lab cloud est redevenu stable. Ce que tu perds pendant un blocage, c’est la visibilité à distance et les fonctions qui passent par le cloud, pas la pièce en cours.

Home Assistant peut-il encore suivre mon imprimante Bambu Lab ?

Oui, à condition de mettre à jour. La version 2.4.0 corrige la boucle de requêtes et change l’agent utilisateur pour identifier le projet. Les installations restées en 2.3.0 continuent d’envoyer l’ancien en-tête et restent bloquées. Sur le Bambu Lab cloud, la marque autorise toujours la lecture de la température, de la position, de la vitesse et de la progression, dans la limite d’un volume de requêtes raisonnable.

Faut-il passer toutes mes machines en mode LAN ?

Si tu imprimes pour quelqu’un d’autre que toi, oui, au moins pour les machines critiques. Le mode LAN te garde un chemin de supervision qui ne dépend pas du Bambu Lab cloud, et Bambu Connect propose justement de découvrir les imprimantes en mode LAN. Tu perds l’accès à distance par le Bambu Lab cloud, tu gagnes une supervision qui ne s’arrête pas quand un constructeur décide de bloquer un client.

📚 Sources

Rapport public de Bambu Lab sur le trafic anormal, ouvert le 11 novembre 2026 : issue #2244 du dépôt ha-bambulab.

Notes de version du correctif : version 2.4.0, et la pull request qui versionne l’agent utilisateur : PR #2249.

Reprise presse avec les chiffres de croissance du trafic et les règles d’accès aux logiciels tiers : 3Druck, 12 novembre 2026.

Documentation officielle de Bambu Connect : wiki Bambu Lab. Page de statut du service : status.bambulab.com. Dépôt du slicer concerné : OrcaSlicer sur GitHub.

Johan

Le CréAtelier