Créer une application Android avec Python : outils, limites

Oui, une application Android écrite en Python existe et tourne sur un téléphone. Trois chaînes d’outils y mènent : Kivy avec Buildozer, BeeWare avec Briefcase, ou Chaquopy dans un projet Android Studio. Chacune embarque un interpréteur CPython dans le paquet installable. Le prix à payer se lit sur le poids du fichier et sur l’accès aux fonctions de l’appareil.

Pourquoi le système n’exécute aucun script tel quel

Android exécute du bytecode issu de Java ou de Kotlin, à travers son environnement d’exécution. Aucun interpréteur Python n’accompagne le système. Un fichier .py déposé dans la mémoire du téléphone ne démarre pas davantage qu’un fichier texte.

Conséquence directe : toute application en Python transporte son propre interpréteur, la bibliothèque standard et chaque extension écrite en C, recompilée pour les architectures de processeur visées. Cette contrainte façonne les trois outils décrits plus bas, leurs qualités comme leurs défauts.

Le langage a gagné une reconnaissance officielle avec la PEP 738, acceptée par le conseil de direction de Python, qui inscrit Android parmi les plateformes officiellement prises en charge par CPython, au premier échelon de son échelle de support. Le texte rappelle au passage que Chaquopy, BeeWare et Kivy portaient déjà le langage sur mobile depuis des années.

Ce statut change surtout la maintenance. Les tests Android tournent désormais dans l’intégration continue du projet Python, et les paquets binaires destinés au Python sur mobile ont trouvé leur place sur l’index officiel. Le choix du langage reste ouvert pour autant, les langages classiques du développement Android gardant l’avantage sur plusieurs critères.

Les trois chaînes qui produisent un paquet installable

Chaque outil répond à deux questions : qui dessine l’interface, et qui pilote la compilation.

Kivy et Buildozer, l’interface dessinée par le code

Kivy dessine ses propres composants sur une surface graphique accélérée. Le rendu obtenu reste identique sur toutes les plateformes, ce qui séduit pour un outil interne ou un jeu, et détonne pour une application grand public censée ressembler au reste du téléphone.

Buildozer, maintenu par l’équipe Kivy, orchestre la compilation. Il télécharge le kit de développement Android et son kit natif, appelle la chaîne python-for-android, puis produit un fichier APK ou un bundle qu’il sait pousser directement sur un appareil branché. Sa documentation le présente comme la voie la plus courte vers un premier paquet Android complet.

Un fichier de configuration unique concentre les réglages : liste des dépendances, permissions demandées, orientation de l’écran, icône, nom du paquet, versions ciblées. Ce fichier devient vite le vrai centre de gravité du projet.

BeeWare, des composants natifs pilotés depuis Python

Le projet BeeWare sépare les rôles. Briefcase fabrique le paquet, Toga fournit la boîte à outils d’interface, et cette boîte s’appuie sur les composants natifs des applications Android plutôt que sur un rendu maison. Une liste ressemble à une liste, un bouton se comporte comme un bouton.

Le point d’étape publié par BeeWare en juillet 2026 donne le rythme du chantier : arrivée du gestionnaire uv dans Briefcase, mise à jour du backend Android de Toga pour rester conforme aux exigences du kit de développement, et acceptation d’Android et d’iOS parmi les plateformes prises en charge par le projet NumPy. Ce dernier point pèse lourd dès que le projet touche au calcul.

Chaquopy, du Python greffé dans un projet Android Studio

Troisième voie, la plus discrète : garder un projet Android classique et y injecter du Python. Chaquopy prend la forme d’un greffon Gradle, s’installe dans un projet Android Studio standard, installe les paquets déclarés au moment de la compilation et ouvre des appels dans les deux sens entre Java et Python.

L’interface reste écrite en Kotlin ou en XML, le cœur métier reste en Python. Le code source du kit est publié sur GitHub sous licence MIT, avec le soutien d’Anaconda. Cette approche convient quand le résultat doit ressembler à une application Android ordinaire tout en réutilisant du code de traitement déjà écrit et déjà testé.

Du script isolé au fichier installable

L’enchaînement varie peu d’un projet à l’autre :

• séparer la logique métier de tout affichage en console, elle deviendra le cœur réutilisable ;
• choisir la boîte à outils d’interface avant d’écrire le premier écran, ce choix conditionne tout le reste ;
• déclarer chaque dépendance dans le fichier de configuration, sans jamais compter sur un paquet installé localement ;
• lancer une compilation complète très tôt, avant même que l’application soit finie ;
• tester sur un appareil physique et lire les journaux système, l’émulateur masque les lenteurs de démarrage ;
• signer le paquet avec une clé conservée hors du dépôt de code ;
• produire le format attendu par le magasin, puis passer par une piste de test interne.

Pourquoi la première compilation demande une machine Linux

La chaîne python-for-android tourne sous Linux et macOS. Sous Windows, la compilation passe par le sous-système Linux intégré, ou par un exécuteur d’intégration continue sous Linux. Cette contrainte surprend beaucoup de débutants et explique une bonne part des échecs racontés sur les forums.

Chaquopy échappe à la règle, puisque sa compilation passe par Gradle, donc par la machine qui fait déjà tourner Android Studio.

Signature, format de dépôt et volume téléchargé

Le magasin de Google attend le format de bundle applicatif pour les nouvelles applications, à la place du fichier APK unique. Ce format laisse le magasin livrer à chaque téléphone les seules bibliothèques natives correspondant à son processeur, ce qui réduit sensiblement le volume téléchargé. Sur un paquet Python, ce mécanisme compte double : les bibliothèques compilées représentent l’essentiel du poids.

La clé de signature mérite une attention particulière. Perdue, elle interdit toute mise à jour de l’application publiée. Sauvegardée dans le dépôt de code, elle finit tôt ou tard exposée.

Les limites qui décident du projet

Le poids arrive en tête. Un interpréteur, sa bibliothèque standard et quelques extensions compilées pèsent nettement plus lourd qu’un équivalent écrit en Kotlin. Chaque bibliothèque scientifique ajoutée gonfle encore la note.

Le démarrage suit. L’interpréteur s’initialise, les modules s’importent, et ce délai se voit au premier lancement. Réduire le nombre d’imports au démarrage devient un réflexe de survie.

La performance appelle une nuance. Le code interprété reste plus lent que du code natif, mais un calcul lourd confié à une bibliothèque écrite en C tourne à pleine vitesse. Un projet Python sur Android gagne donc sur le traitement de données et déçoit sur les animations d’interface les plus exigeantes.

Les dépendances forment le piège suivant. Un paquet écrit uniquement en Python s’installe sans histoire. Un paquet contenant du C réclame une recette de compilation pour Android ou un binaire déjà publié pour cette plateforme, faute de quoi la compilation s’arrête net.

Vient l’accès au matériel : appareil photo, position, notifications, vibreur, capteurs. Tout passe par l’interface de programmation d’Android, écrite pour Java. Des ponts existent, pyjnius du côté de Kivy, l’appel direct de classes Java du côté de Chaquopy, le backend natif du côté de Toga. Vous lisez donc une documentation Java pour écrire du code Python, et les permissions restent déclarées dans le manifeste.

La maintenance ferme la liste. Google relève régulièrement le niveau d’interface de programmation qu’une application doit viser pour rester publiée, selon un calendrier annoncé à l’avance et assorti d’une possibilité de demander un délai. Une chaîne de compilation abandonnée par ses mainteneurs devient une impasse à échéance connue.

Publier sur le magasin de Google sans mauvaise surprise

Le langage d’origine n’apparaît nulle part dans les critères de validation. Le magasin examine un paquet, ses permissions, sa politique de confidentialité et son comportement, pas la façon dont il a été écrit. La PEP 738 note d’ailleurs que des applications issues d’un développement en Python y sont publiées depuis des années, via Chaquopy, BeeWare ou Kivy.

Deux points bloquent plus souvent que le reste.

Le premier tient au compte. L’aide de la Google Play Console impose aux comptes de développeur personnels ouverts depuis fin 2023 un test fermé réunissant au moins 12 testeurs inscrits pendant 14 jours consécutifs, avant toute demande d’accès à la production. Un projet solo prévoit donc ce recrutement très en amont de la date de sortie espérée.

Le second tient au niveau d’interface de programmation ciblé, relevé d’un cran chaque année. Votre chaîne d’outils doit suivre ce rythme. Vérifiez la vitalité du projet avant de l’adopter : un outil dont la dernière version remonte à plusieurs années vous laissera bloqué au premier relèvement, avec une application retirée de la vitrine.

Le reste ressemble à n’importe quelle publication :

• une fiche descriptive et des captures d’écran aux formats demandés ;
• un formulaire de sécurité des données décrivant ce que l’application collecte ;
• une politique de confidentialité hébergée à une adresse stable ;
• une progression par paliers, du test interne au test fermé, puis vers la production.

Quand un autre choix sert mieux le projet

Trois signaux orientent ailleurs :

• interface riche, animations soignées, ambition grand public : le développement natif ou un framework multiplateforme tient la corde ;
• contenu surtout consultable et diffusion sans magasin : une progressive web app installable depuis le navigateur coûte moins cher à maintenir ;
• besoin simple et budget serré : les familles techniques décrites dans notre panorama des types d’applications mobiles méritent une lecture avant tout engagement.

Trois situations donnent au contraire l’avantage à Python. Un cœur métier déjà écrit dans ce langage, qu’une réécriture ferait payer deux fois. Un outil interne destiné à une flotte d’appareils maîtrisée, où le poids du fichier importe peu. Un prototype destiné à valider un usage réel avant un développement plus lourd. Dans ces trois cas, assumer une application Android plus volumineuse coûte moins cher que tout reprendre.

Les applications de terrain illustrent bien ce dernier cas : relevés, inventaires, saisies hors ligne, avec un traitement de données déjà rodé côté serveur. Le même code sert alors des deux côtés, et l’équipe reste sur un seul langage.

Prochaine étape : une compilation à vide cette semaine

Créez un projet vide, ajoutez uniquement vos dépendances réelles, et lancez une compilation complète avant d’écrire le moindre écran. Cette compilation à vide révèle en une soirée ce qu’un mois de travail vous apprendrait autrement : dépendance sans binaire Android, chaîne d’outils figée, poids final déjà hors budget.

Si le paquet sort et démarre sur un téléphone, continuez. Sinon, validez l’usage avant d’écrire du code, gardez Python côté serveur et confiez l’interface mobile à un autre outil.