Toutes les mises à jour ne se ressemblent pas. Celle-ci ne se voit pas à l'écran : pas de nouveau module, pas de nouvelle couche, pas de nouveau bouton. Elle rend l'application plus légère, plus stable, plus économe en mémoire et elle acte une décision que je repoussais depuis des mois : sortir la réalité augmentée de KiloDelta pour en faire une application à part.
Une version sans fonctionnalité, c'est un choix
Je vais commencer par ce qui va décevoir : en 1.24.0, il n'y a rien de nouveau à essayer. Pas de module, pas d'écran, pas d'option.
C'est volontaire. Depuis maintenant plusieurs mois, j'ai ajouté beaucoup de code : la simulation, le DPIF, le SITAC (acces restreint), les messages radio, le ROD, et en 1.23 toute la bascule météo vers Météo-France. À un moment, il faut s'arrêter et regarder l'état réel de ce qu'on a construit. Pas ce qu'on croit avoir construit mais ce que les téléphones en font vraiment, sur le terrain, avec des appareils qui ne sont pas des modèles de démonstration.
Ce que je regarde pour ça, ce sont les vitals de la Google Play Console : le taux d'ANR (l'application qui ne répond plus), le taux de plantage, la consommation mémoire. Ce sont les chiffres que Google mesure sur les vrais appareils de vrais utilisateurs, et ce sont eux qui décident si votre application est mise en avant ou pénalisée dans le classement du store. Mais surtout, et c'est ça qui m'intéresse, c'est ce que vit le sapeur qui ouvre l'app en intervention.
Une application qui gèle trois secondes quand vous cherchez un point d'eau, c'est un outil qu'on arrête d'ouvrir. Et un outil qu'on n'ouvre pas ne sert à rien, quelle que soit la qualité de ce qu'il y a dedans.
La réalité augmentée sort de l'application
C'est la décision la plus lourde de cette version, et il faut que je sois franc sur les raisons.
KiloDelta embarquait depuis plusieurs versions un module de réalité augmentée : la possibilité, dans le cadre d'une formation, de projeter une émulation d'un incendit réellement sur le terrain. C'était l'une des idées dont j'étais le plus fier, et sur le papier ça avait du sens : voir le front de flamme et les fumées plutôt qu'un formateur qui vous donne comme unique indication que le feu est dans le sens de la VLHR.
Dans les faits, ça n'a jamais été assez fiable. Le module reposait sur un pont natif en C++, un moteur de rendu 3D, un filtre USB spécifique au matériel, et une pile de dépendances qui ne cohabitaient jamais bien longtemps avec le reste de l'application. Chaque montée de version de Flutter ou d'Android rouvrait des bugs. Et pendant ce temps-là, ces composants pesaient sur toute l'application y compris pour l'immense majorité des utilisateurs qui n'ont pas de lunettes et n'ouvriront jamais ce module.
J'ai fini par accepter une évidence : ce n'était pas un module, c'était un autre produit. La réalité augmentée a des contraintes de rendu, de latence et de matériel qui n'ont rien à voir avec une application cartographique. Vouloir faire cohabiter les deux, c'était pénaliser l'une pour une promesse que je ne tenais pas sur l'autre.
Donc : la réalité augmentée quitte KiloDelta. Elle fera l'objet d'une application dédiée, développée hors Flutter, avec les outils adaptés à ce type de rendu. Ce n'est pas un abandon du sujet, c'est le contraire. C'est en sortant de KiloDelta que ce travail a une chance d'aboutir.
Le bénéfice immédiat, lui, est chiffrable : 51 Mo de bibliothèques natives en moins. Plus le pont C++ maison, plus le moteur de rendu, plus la configuration de compilation native qui allait avec. C'est autant de code qui n'est plus chargé, plus scanné, plus maintenu.
Au passage, j'ai aussi retiré la navigation vocale. Même logique, à plus petite échelle : une fonction peu utilisée, portée par une bibliothèque qui n'évoluait plus, et qui bloquait des mises à jour ailleurs. Je la remettrai proprement si le besoin remonte du terrain.
Se rapprocher de la gestion mémoire d'Android
Le reste de la version, c'est un travail d'ingénierie qui ne se raconte pas facilement, mais qui se sent à l'usage.
Ce que fait un téléphone quand il manque de mémoire
Android ne prévient pas poliment. Quand la mémoire manque, le système tue l'application, ou lui demande de tout relâcher d'un coup et c'est souvent là que naissent les blocages et les plantages. Une application cartographique est particulièrement exposée : elle manipule en permanence des images (les tuiles), des milliers de marqueurs, et des calculs lourds.
La bonne réponse n'est pas de « faire attention ». C'est de borner : décider à l'avance combien de tuiles on garde en cache, combien de marqueurs on dessine, combien d'images de radar on conserve et adapter ces plafonds à l'appareil qu'on a réellement sous la main. Un téléphone de service avec 3 Go de RAM et un modèle récent avec 12 Go ne doivent pas se comporter pareil.
Ce que j'ai corrigé en 1.24
Le moteur de rendu graphique. J'ai monté Flutter vers sa version 3.47. Le motif n'était pas cosmétique : cette version embarque un correctif du moteur de rendu Impeller sur un plantage précis : une saturation de la compression de textures qui tuait le fil de rendu. Ce correctif n'a jamais été porté dans la branche que j'utilisais, et il correspondait exactement à une famille de plantages que je voyais remonter sur Android 16. Il n'y avait pas d'autre chemin que la montée de version.
Deux bugs trouvés en chemin. La montée de version s'accompagne toujours de nouveaux contrôles automatiques, et ils ont mis le doigt sur deux choses réelles :
- Une division qui pouvait produire une valeur invalide dans la gestion des images du radar météo, et faire planter l'application dans un cas limite. Corrigé, avec un test qui empêche le retour du problème.
- Plus intéressant : quand une tuile de carte échouait à se décoder, elle n'était jamais évincée du cache. Résultat, la carte la gardait indéfiniment en « chargement ». Une seule instruction manquante, un symptôme que j'avais déjà vu sans jamais l'expliquer.
L'allègement du binaire. J'ai resserré les règles d'optimisation du code au moment de la compilation. Sans entrer dans le détail, l'outil qui supprime le code mort et compacte l'application était bridé par des règles de protection trop larges, héritées de mes débuts. Google me signalait dans la console que seule une fraction de l'application était réellement optimisée. C'est corrigé : le code inutile part, les ressources non utilisées aussi.
La chaîne de compilation. Toute la base technique Android a été remise à niveau : outils de build, compilateur Kotlin, bibliothèques d'authentification biométrique, de stockage sécurisé, de notifications. Ce n'est pas glamour, mais c'est ce qui permet de continuer à publier sur le Play Store : Google impose des niveaux de compatibilité minimums, et une application qui ne suit pas finit par ne plus pouvoir être mise à jour du tout.
Ce que ça change pour vous
Rien à apprendre, rien à reconfigurer. Concrètement, vous devriez constater :
- une application plus légère à télécharger et à installer ;
- moins de gels au pan et au zoom sur les cartes denses, en particulier sur les appareils un peu justes en mémoire ;
- moins de plantages sur les appareils récents sous Android 16 ;
- des tuiles qui ne restent plus bloquées en chargement ;
- et la disparition du module Réalité augmentée depuis l'écran d'accueil.
Tout le reste : cartographie, DPIF, simulation, météo Météo-France, points d'eau, hors-ligne fonctionne exactement comme avant.
