Lorsqu'il s'agit de gérer les niveaux de criticité des bugs (P0, P1, P2, P3) dans le développement agile, il est essentiel de les prioriser et de les traiter en fonction de leur impact sur la fonctionnalité et l'expérience utilisateur de l'application. Voici comment chaque niveau devrait influencer la stratégie de publication de votre application mobile ou votre site internet :
💥P0 - Bloquant/Critique
Définition : Ce sont des bugs critiques qui doivent être traités immédiatement, car ils bloquent le développement, les tests ou le déploiement, impactent fortement l'expérience utilisateur, ou posent des risques de sécurité graves.
- Exemple : L'application plante au démarrage, ou une faille de sécurité majeure permet des violations de données.
- Impact sur la publication : Bloque totalement la publication tant qu'il n'est pas résolu. Aucune mise à jour ou nouvelle version ne doit être déployée tant qu'un problème P0 est en suspens.
⛈️ P1 - Priorité haute
Définition : Problèmes significatifs qui affectent des fonctionnalités clés mais n'empêchent pas complètement le fonctionnement du produit ; cependant, ils empêchent certaines fonctionnalités majeures de fonctionner correctement.
- Exemple : Une fonctionnalité telle que la réinitialisation de mot de passe ne fonctionne pas, ou bien l’application rencontre des problèmes de performance majeurs.
- Impact sur la publication : Ces problèmes retardent généralement les publications ou les mises à jour jusqu'à ce qu'ils soient résolus, afin d’éviter tout impact négatif sur les utilisateurs.
⏰ P2 - Priorité moyenne
Définition : Bugs qui impactent la fonctionnalité du produit dans une moindre mesure, affectant des fonctionnalités moins critiques ou présentant des solutions de contournement raisonnables.
- Exemple : Glitches dans l'interface utilisateur, échecs intermittents dans des fonctionnalités non critiques.
- Impact sur la publication : Les bugs de niveau P2 sont généralement documentés et programmés pour être corrigés dans le cycle de publication régulier, à moins qu'ils ne se détériorent et n'affectent plus d'utilisateurs ou des fonctionnalités critiques.
💢 P3 - Priorité basse
Définition : Bugs mineurs qui ont un impact minimal sur l'expérience utilisateur, souvent liés à l'esthétique de l'interface ou des problèmes causant peu ou pas d'inconvénients.
- Exemple : Fautes de frappe, problèmes d’UI mineurs.
- Impact sur la publication : Ce sont les bug les moins critiques et peuvent être corrigés dans les mises à jour de maintenance planifiées, permettant aux développeurs de se concentrer d'abord sur des problèmes plus urgents.
📱 Spécificité des publications mobiles :
- Correctifs immédiats : Pour les problèmes de niveaux P0 et parfois P1, une action immédiate est requise, souvent sous forme de correctifs ou de patches. Cependant, il est important de noter que la distribution de ces correctifs peut être retardée par les processus de validation des stores (App Store, Google Play, etc.), ce qui prend généralement 2 à 3 jours avant que l'application puisse être republiée. Pour minimiser l'impact de ces délais, nous utilisons des outils comme Sentry pour la surveillance des erreurs en temps réel et Uptimerobot pour le suivi de la disponibilité de l'application.
- Mises à jour planifiées : Les problèmes de niveaux P2 et P3 peuvent être regroupés et corrigés dans des mises à jour planifiées, en fonction de leur urgence et de leur impact sur les utilisateurs.
- Retour des utilisateurs : Mains dans la main avec nos clients, nous recueillons en continu les retours des utilisateurs afin de réévaluer la priorité des bugs existants tout en tenant compte des enjeux business premiers.
- Assurance qualité : Des tests fréquents sont mis en place dès le début du cycle de développement pour identifier les bugs le plus tôt possible, ce qui permet de réduire le nombre de problèmes de haute priorité au moment de la publication. En définissant clairement les niveaux de criticité et en comprenant leur impact sur les releases, notre équipe de développement peut mieux prioriser les tâches, assurant ainsi un processus de publication plus fluide. En privilégiant des itérations régulières et des publications fréquentes, nous allégeons également la charge de travail continue et évitons l’accumulation de problèmes majeurs en cours de développement.
💡Notes : le cas des releases web
La publication des releases web, à la différence des applications mobiles, est quasiment immédiate, car elle ne nécessite pas de processus de validation par des stores comme l’App Store ou Google Play. Cela permet ainsi une plus grande flexibilité pour déployer des correctifs ou des améliorations rapidement, parfois même plusieurs fois par jour.
Cette agilité est particulièrement utile pour corriger des bugs de priorité élevée (P0 ou P1) sans attendre les délais de validation imposés par les stores d’applications. De plus, les outils de déploiement continu facilitent la mise à jour régulière des versions web, réduisant les temps d’attente pour les utilisateurs.
