Android Compose-first : quoi faire pour les équipes mobiles

À Google I/O 2026 cette semaine, Google a pris la décision que les développeurs Android attendaient depuis des années. Jetpack Compose est désormais la méthode officielle et par défaut pour créer des interfaces Android. Le toolkit View — l'univers des TextView, ListView, ConstraintLayout et Fragment sur lequel tourne encore la plupart des applications en production — est en mode maintenance. Il ne reçoit que des correctifs critiques, rien d'autre.

Google a été précis dans sa formulation. Les Views ne sont pas dépréciées et aucune date de suppression n'est annoncée. Mais « mode maintenance » a ici un sens précis. Aucune nouvelle fonctionnalité, aucune nouvelle API, et les nouveaux outils UI d'Android Studio sont figés, y compris l'éditeur de layout et l'éditeur de navigation. Les nouvelles bibliothèques Jetpack, la documentation, les codelabs et les exemples seront Compose-first. La recommandation officielle est claire : construisez les nouvelles interfaces en Compose et convertissez les écrans existants au fur et à mesure que vous les modifiez.

Nous livrons des applications Android natives dans les secteurs de la santé, de l'IoT et du e-commerce depuis des années, et la plupart d'entre elles ont démarré comme des projets basés sur les Views. C'est donc une vraie décision pour beaucoup d'équipes, pas juste un titre d'actualité. Voici comment nous l'interprétons.

Le risque pratique n'est pas que votre application plante. Elle ne plantera pas. Le risque est plus insidieux. Votre codebase dérive silencieusement vers une île sans support. Chaque nouvelle fonctionnalité Android, chaque nouveau composant Material, chaque amélioration des outils suppose désormais Compose. Une équipe encore sur les Views en 2027 n'est pas en danger immédiat — elle paie simplement un impôt croissant en contournements et en fonctionnalités manquantes.

L'instinct de « réécrire toute l'application » est la mauvaise approche. Nous avons vu des refactorings UI massifs stagner pendant des mois et introduire des régressions, et Compose est précisément conçu pour l'approche inverse. ComposeView et AndroidView permettent à Compose et aux Views de coexister sur le même écran, voire dans le même layout. Vous pouvez convertir un écran, puis un composant, et les utilisateurs ne voient jamais la jointure. Compose 1.11, également présenté à Google I/O, a amélioré les performances spécifiquement pour ces écrans hybrides.

Il y a aussi un angle recrutement facile à ignorer. Compose est ce qu'apprennent les nouveaux développeurs Android aujourd'hui. Les candidats s'y attendent, et la documentation actuelle le suppose. Une codebase encore très axée sur les Views devient de plus en plus difficile à staffier, et ce coût reste invisible jusqu'au moment où vous êtes trois mois dans une recherche.

Google a également présenté un Android Studio Migration Assistant qui utilise un agent IA pour porter des écrans, et AI Studio peut désormais générer des applications Compose à partir d'une invite. Ces outils aideront. Mais d'après notre expérience d'intégration d'agents IA dans de vrais pipelines de livraison, la leçon se répète : un agent qui convertit un écran n'est utile que si un développeur qui maîtrise Compose en examine le résultat. Traitez une migration générée comme un brouillon, pas comme un résultat final. Les équipes qui se font piéger sont celles qui laissent le volume de conversion dépasser leur capacité de revue.

Si vous maintenez une application Android basée sur les Views, faites une chose concrète ce trimestre. Choisissez votre prochain écran vraiment nouveau et construisez-le en Compose, de bout en bout, avec l'interopérabilité correctement câblée. Pas un spike — un écran que vous livrez vraiment. Cet exercice unique vous apprendra plus que n'importe quel document de planification : comment votre équipe gère l'état Compose, où votre design system a besoin d'équivalents Compose, comment votre build et vos tests s'en sortent. Puis fixez une règle simple. Chaque écran que vous touchez substantiellement est converti. Régulier et sans éclat, et ça s'accumule.

Une dernière chose pour les équipes qui gèrent à la fois iOS et Android. Compose-first sur Android s'aligne avec là où SwiftUI se trouve déjà sur iOS. Les deux plateformes attendent désormais une couche UI déclarative et pilotée par l'état. Si vous planifiez du développement iOS et Android natif, c'est un bon moment pour aligner votre architecture afin que les deux plateformes raisonnent sur l'UI de la même façon. Cela rend les codebases plus faciles à staffier et à réviser — quelque chose que nous avons vu porter ses fruits dans nos projets mobiles passés.

Ce n'est pas une urgence. C'est une direction. La plateforme UI d'Android a désormais un défaut clair, et le coût de l'ignorer n'est pas un crash. C'est une accumulation lente de friction.

Si une pile d'écrans Android basés sur les Views sans plan de migration clair vous semble familière, parlons-en.