Spring Native + Cloud Run : cold-start 18, RAM 3, facture à 0 FCFA

Cet article est la version condensée de mon retour d'expérience complet sur ban.ga — config Maven -Pnative détaillée, registrar RuntimeHintsRegistrar pour la console H2, pipeline PowerShell de 200 lignes, et chaque piège décortiqué.

23h47, un dimanche soir à Libreville

Screenshot WhatsApp d'une dev fictive : sa fintech crash silencieux sur l'OTP en prod.

Cold-start Spring Boot sur Cloud Run : 3 740 ms.

Lundi matin, première vraie facture GCP. Quelques milliers de FCFA — pour une dev qui paye son cloud avec sa bourse de fin d'études, c'est un choc.

MOUSSAVOU, l'héroïne fictive que je trimballe d'article en article, vient de découvrir le truc à la dure. Tu peux ranger ton code en DDD + Hexagonal + Spring Modulith pendant six mois. Si ta JVM met près de 4 secondes à booter, les utilisateurs reçoivent leur OTP avant que /verifier ne soit prêt à le valider. Re-saisie. Re-cold-start. Re-perte.

Le calcul économique qui pique

C'est là que ça devient désagréable. Un cold-start de 3,8 secondes, c'est 3,8 secondes de vCPU et de RAM facturées par Cloud Run, qu'il y ait une transaction qui aboutisse au bout ou pas. Chaque utilisateur qui timeout retry. Chaque retry réveille une nouvelle instance, donc un nouveau cold-start.

Sortons la calculette. 200 utilisateurs le matin × 3 retries × 3,8 s :

= 2 280 vCPU-secondes brûlées
  avant qu'une seule transaction n'aboutisse

Plus 182 GB-secondes de RAM, pour la même raison. Le min-instances=0 protège la facture la nuit. Il ne fait rien contre les cascades d'échec le matin.

Le bench

J'ai recompilé MboloPay (mini mobile money open source) en natif avec GraalVM. Même code Java 25. Compilation différente. Chiffres bruts mesurés le 16 mai 2026 sur Spring Boot 4.0.2, Liberica NIK 25, Hibernate 7.2.1, H2 in-memory :

Étape	JVM Java 25	Natif GraalVM	Gain
Boot → Tomcat init	1 207 ms	36 ms	×33
Hikari pool startup	559 ms	65 ms	×8.6
JPA init	774 ms	14 ms	×55
JPA → Tomcat 8080	875 ms	76 ms	×11.5
Total « Started in »	3 740 ms	205 ms	×18,2
RAM résident	~250 Mo	~80 Mo	÷3
Build CI	~10 s	7-12 min	×12 (compromis)

La ligne qui fait mal : JPA init passe de 774 ms à 14 ms (×55). Hibernate fait énormément de réflexion pour mapper entités → tables. Le AOT processing pré-calcule ce mapping à la compilation. Le runtime n'a plus qu'à brancher.

Comment ça marche, sans la magie

Spring AOT fait le travail à la compilation. Trois mécanismes empilés :

1. Closed-world analysis — GraalVM considère que ton application est fermée. Aucune classe ne sera ajoutée au runtime. À partir du main(), il suit toutes les références, marque les classes utilisées, jette le reste.
2. Génération de code direct — Spring Boot 4 inclut un plugin Maven, spring-boot-maven-plugin:process-aot, qui s'exécute avant la compilation native. Il lit ta config, simule le démarrage, génère du code Java qui remplace la réflexion runtime par des appels directs.
3. Native image — GraalVM compile ce code direct en exécutable natif (ELF sous Linux, .exe sous Windows). Plus de JVM au runtime. Plus de JIT. Plus de classpath scan.

📝 Note de terminologie. « Spring Native » était à l'origine un projet incubator séparé (le module spring-native, 2021-2022). Depuis Spring Boot 3 (novembre 2022), ce support a été intégré directement au core Spring Boot. Le nom « Spring Native » reste largement utilisé par habitude.

Le point clé : ton code Spring ne change pas. @RestController, @Service, @Repository, @Transactional, tout marche. Ce qui change, c'est le quand : ce que Spring fait normalement au démarrage de la JVM, il le fait maintenant au moment du mvnw -Pnative. Le runtime n'a plus rien à apprendre, il sait déjà.

Activer le profil natif tient en 6 lignes

C'est la partie qui surprend toujours quand je la montre :

<build>
    <plugins>
        <plugin>
            <groupId>org.graalvm.buildtools</groupId>
            <artifactId>native-maven-plugin</artifactId>
        </plugin>
        <plugin>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-maven-plugin</artifactId>
        </plugin>
    </plugins>
</build>

Pas de version explicite (gérée par spring-boot-starter-parent). Pas de config custom. Tu lances :

./mvnw -Pnative native:compile

Ou pour produire directement une image Docker :

./mvnw -Pnative spring-boot:build-image

Spring Boot délègue à Paketo Buildpacks (builder paketobuildpacks/builder-noble-java-tiny). Pas de Dockerfile. Le buildpack détecte le mode natif, télécharge GraalVM, compile, et produit une image OCI minuscule prête à pousser sur Artifact Registry.

Les 5 pièges qui m'ont coûté 2 jours

Piège 1 — La console H2 ne marche plus

http://localhost:8080/h2-console te renvoie une page blanche en natif. La servlet H2 utilise de la réflexion dynamique non hint-ée par Spring AOT.

Solution honnête : dev en JVM standard (./mvnw spring-boot:run), prod en natif. Si tu veux vraiment la console en natif, il faut écrire un RuntimeHintsRegistrar custom (squelette complet sur ban.ga) — quelques dizaines de lignes, à construire incrémentalement en réagissant aux ClassNotFoundException qui pop dans les logs Cloud Run. Plan une demi-journée.

Piège 2 — Spring Boot DevTools silencieusement ignoré

Tu as ajouté spring-boot-devtools au pom.xml. En JVM, hot-reload. En natif, ignoré sans erreur. Pas de log. Juste pas de hot-reload.

C'est logique : DevTools repose sur un classloader custom qui recharge les classes à chaud. Un binaire natif n'a pas de classloader. Tu ne peux pas hot-reloader du code machine.

Piège 3 — Les erreurs AOT bloquent le build

Le AOT processing tourne avant la compilation native. Si ton code a une erreur que l'AOT détecte (bean qui dépend d'une classe absente, circularité, config invalide), le build s'arrête. Aucun binaire ne sort.

[ERROR] Failed to execute goal org.springframework.boot:spring-boot-maven-plugin:4.0.2:process-aot
[ERROR] Caused by: java.lang.IllegalStateException: Failed to read candidate component class

C'est un faux ami : tu crois que c'est un problème natif, c'est en réalité un problème Spring détecté plus tôt qu'à la normale. Méthode debug : assure-toi d'abord que ./mvnw spring-boot:run démarre sans warning. Si la JVM démarre proprement, l'AOT démarrera aussi neuf fois sur dix.

Piège 4 — Liberica NIK ≠ Liberica JDK

Le grand classique qui fait perdre une demi-journée. Tu as installé Liberica JDK 25. Tu lances ./mvnw -Pnative native:compile. Tu obtiens :

native-image is not installed in your JAVA_HOME

Tu as installé la JDK Liberica 25, pas le NIK (Native Image Kit). La JDK seule ne contient pas native-image. Il te faut Liberica NIK 25, une distribution séparée qui inclut JDK + GraalVM + native-image.

Sous Windows, prévois aussi Visual Studio Build Tools (charge de travail « Développement Desktop en C++ ») — GraalVM Native Image utilise cl.exe (le compilateur MSVC). Lance la compilation depuis le « x64 Native Tools Command Prompt for VS 2022 ».

Piège 5 — docker-credential-gcr obligatoire sous Windows

Sur macOS et Linux, gcloud auth configure-docker installe correctement un helper. Sur Windows, il configure un helper qui pointe sur docker-credential-gcloud.exe… qui n'existe pas dans le PATH. À la fin de 10 minutes de build :

Cannot run program "docker-credential-gcloud": CreateProcess error=2

Il faut installer docker-credential-gcr séparément, l'ajouter au PATH, et :

docker-credential-gcr configure-docker --registries=<region>-docker.pkg.dev

Et ne pas oublier gcloud auth application-default login (ADC) en plus de gcloud auth login. Ce sont deux mécanismes d'authentification distincts. Sans les deux, push échoue avec auth: "invalid_grant" — après 10 minutes de build. Rageant.

Quand NE PAS faire du natif

Soyons honnêtes. Le natif n'est pas la solution à tout.

• Tu changes ton code 30 fois par jour — early-stage produit, sprint design-prod-design. Le build natif de 7-12 minutes en CI va te rendre fou. Reste sur JVM standard, déploie en 2 minutes, garde tes itérations courtes.
• Ton service tourne 24/7 sans jamais scale à zéro — trafic continu, instance jamais froide. Le cold-start n'est jamais payé. Pire : après warm-up JIT, la JVM peut être 10-20 % plus rapide en débit que ce qu'AOT a prédit à la compilation. Le natif gagne sur les workloads serverless / intermittents, pas sur les workloads stables.
• Tu utilises massivement de la réflexion dynamique ou des libs tierces non Spring — tu peux y arriver, mais le coût d'ingénierie devient significatif. Mesure avant.

Résultat MboloPay

Facture revenue à 0 FCFA / mois tant que la démo reste sous les 2 millions de requêtes du free tier GCP. min-instances=0. Cold-start mesuré : 205 ms. Sur un OTP fintech, c'est la différence entre une transaction qui passe et une transaction perdue.

Pour aller plus loin

Cet article est la version condensée. Sur ban.ga/posts/spring-native-cloud-run/, tu trouveras :

• Le RuntimeHintsRegistrar complet pour la console H2 (et pourquoi c'est « faisable mais pénible »)
• Le pipeline PowerShell de ~200 lignes qui orchestre git → bump → build natif → push → deploy → smoke-test
• La config gcloud run deploy détaillée avec les bons paramètres --concurrency / --cpu / --memory pour le natif
• Pourquoi min-instances=1 « pour éviter les cold-starts » est généralement une erreur quand tu es déjà en natif

Le repo MboloPay est ouvert sur GitHub : github.com/bangaromaric/mbolopay. La démo tourne sur mbolopay.banga.ga (Cloud Run, min-instances=0, cold-start le matin, 200 ms le reste du temps).

---

Et vous ? Vous l'avez tenté en prod ? Quel piège vous a fait perdre le plus de temps ?

Merci à Yannick Serge Obam pour sa relecture exigeante qui a rendu l'article plus juste.