Votre application a trop de bugs : sortir du cycle correction, régression

Comment savoir que l'instabilité est devenue structurelle ?

L'instabilité est devenue structurelle quand corriger un bug en fait apparaître un autre ailleurs. Le scénario est connu : un loueur de matériel fait corriger le calcul des remises dans son application de réservation ; la semaine suivante, l'export comptable ne sort plus les bons montants. La correction avait été faite directement sur le serveur de production un vendredi soir, sans test, et plus personne ne sait exactement quelle version tourne.

Les signes qui ne trompent pas :

• les mêmes anomalies reviennent après avoir été déclarées corrigées ;
• les clients signalent les bugs avant que l'entreprise ne les voie ;
• chaque mise en production est redoutée et se fait hors des heures d'activité ;
• les évolutions sont gelées parce que « ce n'est pas stable » ;
• les anomalies sont éparpillées entre e-mails, messages et appels.

Que coûtent vraiment les bugs ?

Les bugs coûtent du temps de support, des gestes commerciaux et, pour une application mobile, de la visibilité. Android Developers indique que les indicateurs essentiels d'une application influencent sa visibilité sur Google Play : au-delà d'un seuil de mauvais comportement, Google Play peut réduire la visibilité de l'application et afficher un avertissement sur sa fiche. Ces seuils sont publiés :

Google Play évalue la qualité sur les 28 derniers jours de données. Côté Apple, la règle 2.1 des App Review Guidelines demande de tester l'application sur appareil avant soumission et précise qu'Apple rejette les binaires qui plantent ou présentent des problèmes techniques évidents : une version instable peut donc retarder une mise à jour urgente.

Le coût le moins visible est interne : une équipe qui éteint des incendies toute la semaine ne livre plus rien de neuf.

D'où vient l'instabilité ?

L'instabilité vient presque toujours d'une méthode de travail, rarement d'un développeur en particulier.

• Aucun test automatisé : chaque modification est vérifiée à la main, partiellement, quand on y pense.
• Pas de préproduction : les corrections sont essayées directement face aux clients.
• Des livraisons trop grosses : quinze changements partent ensemble, et quand quelque chose casse, impossible de savoir lequel est en cause.
• La dette technique : code dupliqué, raccourcis jamais repris, dépendances obsolètes.
• Des règles métier jamais écrites : ce que l'un appelle un bug, l'autre l'appelle le comportement prévu.

Les cinq filets de sécurité, dans l'ordre

Cinq filets de sécurité, posés dans cet ordre, suffisent à arrêter les régressions avant de s'attaquer au fond.

1. Un registre unique des anomalies, où chaque signalement indique comment le reproduire, la gravité, l'appareil et la version. Les e-mails épars disparaissent.
2. Une préproduction, copie de la production, où chaque correction est vérifiée avant de partir. Dans sa fiche « Tester vos applications », la CNIL recommande de ne pas utiliser les données réelles de production pour les tests et de construire un jeu de données fictives représentatif, en anonymisant les données personnelles si des configurations de production doivent être reprises.
3. Des tests automatisés sur les parcours qui comptent : création de compte, commande, paiement, facture. La même fiche recommande un système d'intégration continue qui lance les tests automatiquement après chaque modification du code source.
4. Une recette écrite avant chaque mise en production, rejouée par une personne du métier, selon la méthode de notre guide de la recette logicielle. Pour le mobile, les canaux de test des stores servent de dernier filet : TestFlight permet d'inviter jusqu'à 100 testeurs internes et 10 000 testeurs externes, et la Play Console propose un test interne ouvert à 100 testeurs, puis des tests fermés et ouverts.
5. Des livraisons petites et fréquentes, que l'on peut annuler en quelques minutes si un problème apparaît.

Comment trier les anomalies ?

Toutes les anomalies ne se valent pas : une grille de gravité, partagée avec le métier, décide de ce qui se corrige tout de suite et de ce qui attend.

Klass. : 269 contrôles rejoués à chaque mise à jour

Sur Klass., plateforme de sous-traitance pédagogique entre écoles, CFA et formateurs (projet dont le fondateur de YMHB Web est cofondateur), un programme de vérification maison rejoue 269 contrôles automatisés à chaque mise à jour : accès, cloisonnement entre établissements, scénarios métier, liens, données structurées et accessibilité. La règle est simple : si un seul contrôle échoue, la mise à jour ne part pas.

Ce niveau de contrôle se justifie par la structure de la plateforme, qui compte trois portails et douze rôles utilisateurs : une erreur de droits exposerait les données d'une école à une autre. Sur une application plus simple, quelques dizaines de tests ciblés sur les parcours critiques suffisent souvent à casser le cycle des régressions.

Faut-il commencer par un audit ?

Un audit s'impose lorsque plus personne ne sait vraiment ce que contient le code, par exemple après le départ du prestataire d'origine. Il cartographie les zones fragiles, mesure ce qui est testé, liste les dépendances obsolètes et propose un ordre de remise à niveau ; notre page sur le prix d'un audit de code détaille son contenu. Quand le code est récent et connu, on peut poser directement les filets sur les parcours les plus touchés.

Dans les deux cas, YMHB Web suit le même ordre : registre et préproduction d'abord, tests sur les parcours critiques ensuite, puis correction des anomalies par gravité, sans nouvelle fonction tant que la stabilité n'est pas revenue. Le code et les tests écrits appartiennent au client au paiement intégral.

Quand le problème n'est pas dans le code

Une partie des « bugs » ne se corrige pas avec du code, et un développement supplémentaire n'est pas toujours la bonne dépense.

• Les spécifications sont floues : si personne n'a écrit ce que l'application doit faire dans tel cas, chaque comportement inattendu est vécu comme un bug. Écrire les règles fait disparaître une partie des « bugs ».
• Le besoin est standard : pour une prise de rendez-vous ou une facturation classique, un logiciel du marché, éprouvé par des milliers d'utilisateurs, sera plus stable qu'un développement spécifique.
• L'usage est très faible : pour un outil interne utilisé par trois personnes, une liste de vérification manuelle avant chaque mise à jour peut suffire.
• La feuille de route déborde : ajouter des fonctions à une application instable aggrave la situation. Geler les évolutions quelque temps est souvent la décision la plus rentable.