Une semaine à mettre la roadmap sur pause pour se concentrer sur les corrections de bugs

 (lalitm.com)
20 points par GN⁺ 2025-11-25 | 2 commentaires | Partager sur WhatsApp
  • Une équipe d’environ 45 ingénieurs suspend chaque trimestre pendant une semaine la roadmap, le design et les réunions pour organiser une « semaine Fixit », consacrée à la résolution de petits bugs et de problèmes de productivité
  • Lors de ce Fixit, 189 bugs ont été corrigés, avec 40 participants, une médiane de 4 corrections par personne et jusqu’à 12 bugs fermés pour un même ingénieur
  • Des mécanismes comme la règle de résolution en moins de 2 jours, un système de points et de classement, ainsi que des t-shirts en récompense renforcent la motivation et le moral de l’équipe
  • L’usage d’outils d’IA a accéléré l’exploration du code et les propositions de correction, en réduisant le coût des changements de contexte
  • Fixit est perçu comme une pratique qui améliore la qualité du produit et renforce la cohésion de l’équipe, tout en ravivant le plaisir de résoudre de petits problèmes

Le concept de Fixit et son mode de fonctionnement

  • Fixit est une semaine intensive de correction de bugs organisée chaque trimestre, durant laquelle le travail normal sur la roadmap, le design et les réunions est entièrement suspendu
    • Les ingénieurs y corrigent de petites erreurs ou sources de perte de productivité qui gênaient les utilisateurs et les développeurs
    • Exemples : un message d’erreur resté flou pendant 2 ans, un glitch apparaissant lors de l’usage simultané du scroll et du zoom, ou encore des lenteurs de tests retardant la CI
  • Il y a deux règles
    • Aucun bug ne doit prendre plus de 2 jours
    • Le travail doit se concentrer sur l’amélioration pour l’utilisateur final ou sur la productivité des développeurs
  • Un système de points et un classement permettent de visualiser la participation, et des t-shirts en récompense sont attribués dans différentes catégories comme « premier bug corrigé » ou « bug le plus agaçant corrigé »

Résultats de Fixit

  • Résultats de ce Fixit
    • 189 bugs corrigés, 40 participants, médiane de 4 par personne, maximum de 12
  • Cas marquants

Les effets de Fixit

  • Côté produit : précision et finition

    • Un bon produit se caractérise par l’attention portée aux détails et la cohérence
    • Fixit offre l’occasion de faire progresser la qualité du produit d’un cran en éliminant de petits irritants que les utilisateurs ne remarquent pas toujours directement

  • Côté individuel : la satisfaction d’une exécution concrète

    • C’est une manière de retrouver le sentiment d’accomplissement immédiat des débuts de carrière : « repérer un problème → le corriger → le déployer »
    • Pendant Fixit, l’accent est mis moins sur “que construire ?” que sur “comment améliorer ?”, ce qui permet d’accumuler rapidement de petites victoires

  • Côté équipe : moral et collaboration renforcés

    • Quand 40 personnes réparties sur deux fuseaux horaires corrigent des bugs en même temps, l’énergie de toute l’organisation monte d’un cran
      • Partage des corrections en temps réel dans le chat, publication de captures d’écran, démonstrations… les échanges sont très actifs
    • Chaque matin, le nombre de corrections, le nombre de participants et le classement sont partagés pour renforcer la motivation

Conditions de réussite d’un Fixit

  • Préparation en amont

    • Tout au long de l’année, les bugs sont tagués comme « good fixit candidate » puis, la semaine précédant Fixit, classés en petits, moyens et gros (0,5 / 1 / 2 jours)
    • Des points de 1, 2 et 4 leur sont attribués selon leur taille, et une liste priorisée est préparée
    • Cette préparation est la clé pour éviter la confusion du premier jour

  • La règle de la limite à 2 jours

    • Dans le passé, un bug s’est révélé plus complexe que prévu et a consommé toute la semaine Fixit
    • Depuis, la règle est de stopper au-delà de 2 jours et de renvoyer le sujet au backlog, afin de préserver un sentiment d’accomplissement continu

  • La taille de l’équipe participante

    • Au départ, avec 7 personnes, il y avait des résultats, mais pas vraiment d’adhésion à l’échelle de l’organisation
    • C’est autour de 40 personnes qu’une masse critique s’est formée, maximisant l’énergie collective et l’immersion

  • La gamification

    • Les points privilégient le fun plutôt que la précision (1 / 2 / 4 points)
    • Les contributions sont reconnues largement : première correction, bug le plus agaçant, etc.
    • Le dispositif est séparé de l’évaluation de performance, pour préserver une motivation purement participative
    • Grâce aux normes sociales et à la taille de l’équipe, les abus du système sont presque inexistants

Le rôle des outils d’IA

  • L’IA allège l’un des principaux défis de Fixit : le coût des changements de contexte
    • En explorant rapidement les fichiers concernés et en les résumant, elle réduit la charge cognitive
  • Exemples
  • Au final, cela accélère l’accès à un point de départ, et dans certains cas permet une correction immédiate

Critiques adressées à Fixit et réponses

  • « Est-ce que cela ne veut pas dire que les bugs sont ignorés le reste du temps ? »

    • C’est vrai en partie, mais cela compense une réalité : les petits bugs irritants (papercut bugs) passent souvent après le reste dans les priorités
    • Fixit est un moyen de réserver explicitement du temps pour traiter ces « petits problèmes, mais importants »

  • « Mettre la roadmap sur pause, n’est-ce pas du gaspillage ? »

    • Mobiliser 40 personnes pendant une semaine représente un coût important, mais celui-ci est compensé par une meilleure finition du produit et une hausse de la satisfaction utilisateur
    • Les gains de productivité liés à l’accélération des tests, à des messages d’erreur plus clairs et à des workflows raccourcis perdurent sur le long terme

  • « Ce n’est pas une méthode réservée aux grandes entreprises ? »

    • Même une petite équipe peut l’adapter avec un « Fixit Friday » ou un mini Fixit de 2 jours
    • L’essentiel est de disposer de temps protégé et concentré ainsi que d’un effort d’amélioration collectif

La valeur fondamentale de Fixit

  • L’objectif officiel est d’améliorer la qualité du produit et la productivité des développeurs
  • La raison officieuse est « le plaisir de réparer quelque chose »
  • Fixit est présenté comme un élément essentiel pour raviver la satisfaction des périodes plus simples et préserver une culture de fabrication produit attentive aux détails

À lire aussi

2 commentaires

 
t7vonn 2025-11-25

Cela me rappelle la culture « pit stop » de Baemin. J’ai entendu dire qu’elle n’existe plus aujourd’hui.
 
GN⁺ 2025-11-25
Commentaires sur Hacker News

  • J’aime bien l’idée, mais la phrase « un bug ne devrait pas prendre plus de 2 jours » me paraît étrange
    En pratique, il est presque impossible de prédire combien de temps cela prendra avant d’avoir corrigé le bug
    Cela dit, sauf si un gros refactoring est nécessaire, je pense que ça dépasse rarement une journée
    En général, je traite les bugs selon leur gravité ou leur priorité. Plus un bug est grave, plus il est souvent facile à trouver de manière surprenante
    Une fois la cause identifiée, la résolution est rapide

    • J’ai travaillé autrefois dans une entreprise qui utilisait beaucoup MS SQL Server, et un Heisenbug survenait tous les quelques mois en arrêtant le cluster de serveurs
      Nous avons analysé les logs pendant des années sans trouver la cause, avant de découvrir qu’il était reproductible à 100 % avec une combinaison précise d’état de la base et de commit
      Après avoir signé un NDA, nous avons créé un binaire de reproduction minimal et automatisé le tout avec un script PowerShell, et Microsoft l’a corrigé en un mois
      En interne, cela ressemblait à un buffer overflow, mais je n’en suis pas certain
    • Dans la plupart des projets pleins de bugs sur lesquels j’ai travaillé, il y avait aussi ce genre de règle implicite
      Si on passait toute une semaine à corriger des bugs sans accumuler de story points dans Jira, plusieurs managers débarquaient pour demander pourquoi la vélocité baissait
      La leçon que j’en ai tirée, c’est qu’il vaut mieux éviter les bugs difficiles et abandonner tôt les tâches qui ne rapportent pas de points
    • Quand on travaille côté matériel, les bugs difficiles à reproduire peuvent parfois prendre des mois
      Impossible de savoir si le problème vient du code, du compilateur ou du matériel, et les bugs composites dus à plusieurs facteurs entremêlés sont parfois impossibles à reproduire isolément
    • Dans des architectures fortement imbriquées comme les jeux, on voit souvent des structures complexes où l’événement A déclenche B, mais différemment selon l’état de C
      Dans ce genre de cas, l’accumulation de rustines rapides finit plus tard par transformer une vraie correction de bug en rework massif
    • Il y a deux cas où un bug n’est pas corrigé
      1. la cause n’est pas claire, donc la majeure partie du temps est consacrée à la trouver
      2. la cause est claire, mais c’est une erreur d’architecture, donc la correction est un gros chantier
        Et dans des environnements à faible confiance, même un bug mineur ne peut pas être corrigé immédiatement à cause des procédures Jira

  • Quand je travaillais chez Meta, on faisait une Fix-it Week chaque trimestre
    Au début, je pensais que la direction se souciait de la qualité, mais en réalité c’était plutôt une période autorisée pour accumuler de la dette technique
    On essayait de corriger des bugs pendant une semaine, mais avec toute la dette déjà accumulée, on ne résolvait presque rien

    • Ça me rappelle la politique d’id Software — « si vous voyez un bug, corrigez-le immédiatement »
      Sinon, du nouveau code s’empile sur le bug et cela devient une base instable
      La vidéo de conférence de John Romero insiste sur la même philosophie
    • Chez Meta, la Fix-it Week était en réalité une semaine de refactoring
      Les développeurs y traitaient les TODO laissés plus tôt et augmentaient le nombre de LOC, et certains allaient jusqu’à écrire volontairement du mauvais code pour le « corriger » plus tard afin de gonfler artificiellement le nombre de diffs
    • Comme le dit le texte d’origine, la Fix-it Week est une semaine centrée sur les petits bugs ou les améliorations de l’expérience développeur
      Autrement dit, un moment pour traiter des problèmes non urgents mais agaçants
    • Ce genre de semaine devient au contraire une absolution mentale du type « pas besoin de le corriger maintenant, on le fera pendant la Fix-it Week »
      Il est plus important que la direction explique honnêtement les priorités business et montre clairement l’impact des bugs sur les utilisateurs
    • Si l’on se soucie vraiment de la qualité, le plus réaliste est d’intégrer naturellement la correction de bugs au développement des fonctionnalités

  • J’ai déjà vécu le cercle vicieux où, pendant le développement de fonctionnalités, les urgences et les changements de priorité se répétaient sans cesse
    Au final, le système devient rempli de contournements, et ni les clients ni les développeurs n’en sont satisfaits
    Dans ce genre de situation, on se dit qu’il aurait mieux valu tout arrêter dès le départ pour faire une correction de fond

    • Ce schéma est un symptôme typique d’effondrement organisationnel
      La communication se coupe, et les dirigeants s’agitent dans tous les sens en se contentant de donner des ordres
      Les développeurs deviennent les pompiers de tous les problèmes, et la fuite finit par être la seule solution
    • C’est clairement un échec du leadership
      Plus la vitesse baisse, plus les dirigeants paniquent et réaffectent le projet dans tous les sens, ce qui nourrit le chaos et une culture toxique
    • Pour éviter ce genre de situation, au lieu de chercher à satisfaire les clients à tout prix, il faut savoir gérer les attentes
    • Cela dit, si l’entreprise est encore au stade de la recherche du PMF (Product-Market Fit), passer du temps sur une ingénierie parfaite peut aussi être inefficace
    • En fin de compte, le problème n’est pas individuel mais relève d’une culture d’entreprise toxique. Le mieux est de partir au plus vite

  • J’ai toujours travaillé avec la philosophie « la correction des bugs d’abord »
    Si les fonctionnalités existantes ne marchent pas correctement, je n’en développe pas de nouvelles
    Cela permet de maintenir une base de code sans bugs et d’améliorer la productivité de l’équipe

    • Mais plus l’équipe grandit, plus la tendance est forte à privilégier le développement de nouvelles fonctionnalités plutôt que les bugs
    • On me demande souvent dans quel contexte une telle culture a pu exister
      Surtout en frontend, avec les problèmes liés à la diversité des environnements, un état totalement sans bug est presque impossible
      Et comme la définition d’un « bug » est floue, il arrive aussi que des managers classent comme bug une fonctionnalité qu’ils veulent
    • Les bugs aussi ont une priorité
      Par exemple, une erreur sur une page d’API presque jamais utilisée peut être moins importante qu’une nouvelle fonctionnalité
    • Les systèmes à grande échelle ont des milliers de bugs
      La plupart sont mineurs, donc la direction préfère les nouvelles fonctionnalités
    • En réalité, une base de code totalement sans bugs n’existe pas. Croire qu’il n’y a pas de bugs relève simplement d’un manque de visibilité

  • J’exploite un petit produit SaaS et je respecte le principe « corriger les bugs en priorité »
    Je résous d’abord les bugs signalés par les clients avant de travailler sur de nouvelles fonctionnalités
    Avec cette approche, le nombre de nouveaux bugs découverts diminue progressivement et les corrections deviennent plus simples
    D’un point de vue business, ce n’est peut-être pas optimal, mais du point de vue de la qualité et de la confiance des clients, c’est la meilleure stratégie
    Les clients adorent quand un bug qu’ils ont signalé est corrigé en quelques heures

    • D’autres partagent toutefois l’idée que ce principe est difficile à appliquer sur une base de code legacy vieille de 15 ans
    • J’ai aussi écrit un billet à ce sujet — Fix Bugs or Add New Features

  • Des dispositifs comme la Fix-it Week encouragent au contraire à retarder la correction des bugs
    Cela crée l’excuse : « on fera ça plus tard pendant la Fix-it Week »
    À la place, il vaudrait mieux inclure explicitement du temps de maintenance dans la planification trimestrielle ou des sprints
    Cela donne aux développeurs une légitimité pour corriger les bugs immédiatement et installe une culture d’amélioration continue
    La Fix-it Week serait mieux utilisée comme une mini-hackathon avec de petites améliorations ou des POC

  • Dans une ancienne entreprise, on répétait toujours le même cycle

    1. focus total sur le développement de fonctionnalités → 2) incident majeur chez un gros client → 3) arrêt de tout le développement puis semaine de correction de bugs
      Ce schéma était le signe d’une culture d’entreprise défaillante. Tant qu’on ne réserve pas du temps pour corriger les bugs au quotidien, rien ne change

  • Cela m’a rappelé le Joel Test proposé autrefois par Joel Spolsky
    Sa cinquième question était : « Corrigez-vous les bugs avant d’écrire du nouveau code ? »
    Vingt-cinq ans plus tard, cela reste un critère toujours pertinent
    Lien vers le texte original

  • Je suis d’avis qu’il ne faut pas attribuer de score ni d’estimation de taille aux bugs
    S’il faut vraiment leur donner un score, autant mettre 2 partout, ce sera juste en moyenne
    La correction de bugs doit être gérée en mode Kanban, en les traitant par ordre d’importance et en les terminant dans le temps imparti

  • Je suis l’auteur du billet. Je suis ravi de voir une discussion aussi animée

    1. Comme la complexité des bugs est difficile à prévoir, je recommande qu’après quelques heures d’enquête, si le périmètre grossit, cela soit transformé en autre sujet
    2. Nous utilisions le mot « bug » comme terme interne englobant non seulement les erreurs classiques, mais aussi les demandes d’amélioration fonctionnelle
    3. Il y a bien un risque que la Fix-it Week se transforme en « on repoussera ça jusque-là », mais chez nous elle était réservée aux petits bugs
      Ce n’était pas un substitut à l’hygiène technique ni à la résolution de gros problèmes
    • Un lecteur a dit avoir trouvé l’article intéressant et a demandé combien de régressions ou de nouveaux bugs avaient été provoqués par les corrections de bugs