DCM : comment booster la qualité du code de votre application Flutter ?

S’il y a bien une chose sur laquelle tous nos développeurs sont d’accord c’est que la qualité du code n’est jamais une option. Pas par dogmatisme, par expérience. La dette technique¹ est en effet une réalité inhérente à tout projet logiciel, depuis toujours : à partir du moment où on écrit la première ligne de code, elle commence à s'accumuler. L'enjeu n'est pas de l'éliminer — c'est impossible — mais de la maîtriser, car sur des projets mobiles qui s'inscrivent dans la durée, avec des équipes qui tournent et des bases de code qui grossissent, un code non surveillé finit toujours par coûter cher. Pas forcément tout de suite mais à terme, il coûte.

Alors comment maîtriser sa dette technique ? Chez USERADGENTS, nous pensons qu’il est nécessaire d’intégrer au cœur même du processus de développement un contrôle qualité rigoureux qui passe par la définition d’un ensemble de règles communes et le choix d’un outil d’analyse statique configuré à partir de celles-ci. Cette vision vaut pour tous nos projets d’applications — natives, web ou cross-plateformes — mais il est difficile d’y appliquer partout la même logique ou le même outillage. Qu’en est-il sur Flutter ? Nos experts vous donnent les clés après les avoir eux-mêmes éprouvées.

SonarQube, le choix de logique ?

Une référence sur le marché

Depuis plusieurs années, nous nous appuyons sur les solutions SonarQube pour contrôler la qualité de nos projets. Pour les applications natives, pour les applications web, SonarQube est clairement la référence. Un choix plutôt évident, donc. 

Mais pour les applications cross-plateformes sous Flutter, c’est beaucoup plus compliqué car initialement (il y a encore quelques années en tout cas), le langage Dart n’était pas supporté par la suite d’outils SonarQube.

Le plug-in flutter-sonar pour structurer le contrôle qualité des applications Flutter

Chez USERADGENTS, nous avons donc trouvé une alternative qui nous permettait de ne pas rompre totalement avec l’écosystème SonarQube (puisque nos développeurs travaillent à la fois sur des projets natifs et cross-plateformes) : sonar-flutter, un plug-in open source capable de faire remonter les anomalies remontées par l'analyseur statique natif de l'écosystème Dart dans SonarQube.

Cette solution nous a permis de poser les bases d’un vrai process de contrôle qualité solide pour uniformiser les pratiques, embarquer les bonnes conventions dès le début d'un projet et offrir de premiers retours continus aux développeurs Flutter sur la qualité de leur code. Nos équipes ont en effet collaboré pour créer un “Quality Profile” propre à l’agence, qui fait état de tous les principes à respecter pour créer une bonne application Flutter selon nos critères. Puisque toutes les règles proposées par le plug-in ne sont pas bonnes à prendre, il ne conserve que celles qui nous semblent indispensables, et c’est à partir de celles-ci que nous avons façonné notre “Quality Gate” qui, elle, définit les seuils et les metrics qui vont guider l’analyse statique sur nos projets.

Après quelques mois d'usage, nous avons pris conscience que notre solution (analyseur statique de Dart + plug-in sonar-flutter) avait un périmètre d'analyse limité. Les remontées concernaient majoritairement des questions de forme : longueur de lignes, préférences syntaxiques, conventions de nommage. Des informations utiles, mais qui ne disent rien sur la qualité réelle d'une application Flutter.

Ce que cela ne couvre pas, c'est tout ce qui est spécifique à Flutter : la qualité architecturale des widgets, les paramètres inutiles qui alourdissent les APIs, les fichiers orphelins qui s'accumulent, les dépendances mal déclarées. Autant de problèmes qui dégradent un projet silencieusement sur le long terme. Ce n'est pas un défaut du plug-in, c'est structurel. 

S'ajoutait à cela un problème de cohérence. Certaines règles du plug-in entraient en contradiction avec notre configuration DartLint locale. Un développeur qui suivait les alertes dans son IDE se retrouvait parfois à corriger dans un sens en local, et dans l'autre dans SonarQube.

DCM, la bonne alternative ?

C’est quoi DCM ?

De plus en plus populaire dans la communauté Flutter, DCM (pour Dart Code Metrics) a commencé à attirer notre attention. Sa spécificité ? DCM n'est pas un linter généraliste “adapté à Dart”, il a été conçu spécialement pour ce langage et pour le framework Flutter. Il comprend les widgets, les patterns de l'écosystème et couvre même certaines librairies avancées comme Bloc ou GetIt. Près de 500 règles sont disponibles, là où un analyseur standard en propose bien moins.

Au-delà du lint, DCM mesure la complexité du code, évalue la qualité de construction des widgets, détecte les fichiers et traductions inutilisés et analyse les assets (images trop lourdes, résolutions manquantes, fichiers jamais référencés…). Il inspecte aussi les paramètres de chaque fonction, s’ils sont inutilisés, toujours identiques ou inutilement nullable. C'est ce niveau de détail qui change la nature des anomalies remontées. Là où le plug-in sonar-flutter analysait notre code Flutter avec des règles génériques, DCM voit toutes les spécificités propres à l’écosystème. 

Seule solution à présenter ces avantages sur le marché, nous avons quand même décidé de l’évaluer pour être sûrs de notre choix avant d’entamer une potentielle migration.

sonar-flutter vs. DCM : le match

Nous avons mené notre évaluation en trois étapes, sur le même projet de référence, pour avoir des résultats vraiment comparables.

Première étape : mesurer l'existant. 

Nous avons analysé le projet avec le plugin SonarQube seul, avec notre configuration en place jusqu'alors. Le résultat confirmait ce qu'on suspectait : des anomalies majoritairement de faible sévérité, centrées sur le style. Rien sur l'architecture, rien sur la performance.

Deuxième étape : ajouter DCM à l'existant. 

Nous avons intégré DCM en parallèle du plug-in et remonté ses résultats dans SonarQube via un rapport externe. Les anomalies détectées ont augmenté d'un tiers et surtout, leur nature a changé. DCM identifie des paramètres inutiles qui alourdissent les API, des fichiers orphelins qui s'accumulent, des dépendances mal déclarées. En somme, des problèmes de sévérité moyenne, directement liés à la maintenabilité du code.

Troisième étape : isoler DCM. 

Pour avoir une lecture propre, sans le bruit du plug-in existant, nous avons monté une instance SonarQube locale via Docker, sans toucher à l'infrastructure en production, avec  DCM seul aux manettes de l’analyse, sur le même projet. Le volume d'anomalies détectées représentait plus du double de ce que le plug-in remontait et leur pertinence n'avait surtout rien à voir, l’analyse était bien plus fine et experte (impact sur le garbage collector, gestion de la null-safety, opportunités de stabilité sur les constructeurs, qualité des widgets…).

1 point pour DCM ! En matière de performances, la comparaison est sans appel mais encore faut-il pouvoir l’intégrer — sans trop de dégâts — dans le workflow de nos développeurs.

DCM dans le quotidien des développeurs Flutter

Le processus de développement Flutter chez USERADGENTS Pour chaque développement de feature, nous effectuons une pull request pour valider l’intégration de la nouveauté dans la branche principale du projet. L’outil de contrôle qualité (SonarQube ou DCM) va alors déclencher l’analyse statique (en parallèle d’une relecture manuelle par un pair) pour vérifier que le code respecte bien la Quality Gate et les règles prédéfinies. S’il n’atteint pas les seuils, le code ne peut pas être intégré sur la branche principale. Ce mécanisme n'est pas là pour bloquer les équipes mais pour les guider. Il matérialise un engagement collectif : on ne dépose pas du code sans s'assurer qu'il répond à nos standards. C'est un outil d'amélioration continue, pas un outil de contrôle. Cela permet aux équipes de voir ce qui dégrade, ce qui s'améliore et d’appuyer les décisions techniques sur de vraies données, pas juste sur des impressions.

Une configuration partagée, versionnée, maintenue

Premier enjeu : comment garantir que tous nos projets Flutter appliquent les mêmes règles d'analyse, sans que chaque équipe ait à reconfigurer DCM de son côté ? En réalité, c’est plutôt simple. DCM se configure via le fichier analysis_options.yaml, déjà présent dans tout projet Flutter. Nous aurions pu dupliquer ce fichier projet par projet mais c'est une dette technique en puissance avec des règles qui divergent, des mises à jour à propager manuellement, des incohérences qui s'installent dans la durée.

Nous avons donc fait le choix de créer un package interne dédié qui centralise l'ensemble des règles de lint et de DCM dans un seul endroit versionné. Chaque projet se contente de le référencer. Quand on fait évoluer les règles, on publie une nouvelle version du package, les projets choisissent quand ils montent de version, en connaissance des impacts grâce à un changelog maintenu. Une approche déjà éprouvée sur nos projets mobiles natifs.

Une intégration naturelle grâce à la compatibilité avec SonarQube

Dans notre pipeline CI/CD, qui tourne sur Bitrise, DCM ne devait pas alourdir les temps de build ni complexifier une infrastructure qui fonctionne. C’est (presque) le cas. Seulement deux étapes s'ajoutent avant l'envoi vers SonarQube. La première permet d’installer le CLI DCM sur la machine de build. La seconde de lancer l'analyse et de générer le rapport dans un format compatible SonarQube. Ce rapport est ensuite transmis à sonar-scanner via une propriété de configuration, SonarQube le récupère et affiche les anomalies DCM aux côtés des autres, identifiées par un tag distinct. 

Le temps d'exécution additionnel est donc marginal. L'infrastructure existante n'est pas modifiée. Et les équipes (chefs de projets compris) retrouvent leurs résultats dans le dashboard où elles ont l'habitude de les consulter.

En conclusion

Changer d'outil n'est jamais une décision anodine, surtout quand il s'agit d'un élément central du workflow de développement. Cela ne se fait pas à la légère et cette évaluation nous a permis de le faire avec des arguments concrets plutôt que des intuitions.

DCM devrait commencer à remplacer, petit à petit et en partie, le plug-in sonar-flutter dans le contrôle qualité de nos projets Flutter. Pas parce que c'est nouveau, pas parce que c'est tendance, mais parce que les résultats sont meilleurs, plus fins, plus experts, parce que l'outil est maintenu activement et parce que son intégration dans notre écosystème existant s'est faite sans friction.

Cette configuration n'est pas figée pour autant. Les règles qualité que l’on applique aujourd'hui sont le fruit de discussions d'équipe et ces discussions ne s’arrêtent jamais. L'objectif n'est pas d'appliquer un ensemble de règles génériques mais de définir nos propres règles, celles qui reflètent notre manière de travailler et comme la technologie, elle évolue en permanence.

Alors oui, si l’application de ces règles et l’usage d’outils comme DCM sont clés pour développer des projets Flutter d’envergure qui sont durables dans le temps, ils ne font pas disparaître la dette technique pour autant. Elle ne disparaît jamais vraiment. Mais on la voit mieux, on la comprend mieux et surtout, on peut agir dessus avant qu'elle ne devienne immaîtrisable. 

La qualité de nos productions est une marque de fabrique chez USERADGENTS. Notre ambition ne se limite pas à livrer une application : nous accompagnons nos clients sur le long terme dans une véritable vision produit.Dans cette perspective, il est essentiel d’industrialiser nos processus de contrôle qualité et de les intégrer pleinement au cœur de workflows de production efficaces.

Il faut également souligner le dynamisme de l’équipe qui, grâce à un travail constant de veille et à une excellente connaissance de l’écosystème Flutter, nous permet d’aborder ces problématiques avec des outils adaptés et performants. Cette démarche témoigne de l’expertise technique globale que nous avons développée autour de notre approche Flutter.

Mathieu Pisonero, CTO

Vous avez un projet d’application Flutter ? Contactez nos experts techniques ! 

^{1  La dette technique, c’est l’écart entre un code idéal et son état réel. Elle vient des compromis, du manque de temps, d’erreurs minimes ou de mauvaises décisions qui génèrent des problèmes qu’il faudra corriger plus tard. Et qui s’accumulent.}