Le Rework Rate : la métrique cachée qui révèle la vraie vélocité
La vélocité, cette illusion bien entretenue
Combien de fois avez-vous entendu un manager technique s'enthousiasmer de la sorte : "Depuis qu'on a déployé les assistants IA, nos développeurs produisent deux fois plus de code" ? C'est une réalité que nous observons chez SFEIR dans un nombre croissant d'organisations. Et c'est précisément là que réside le piège.
Produire plus de code n'est pas produire plus de valeur. Et l'une des révélations majeures du rapport DORA 2025 — cette référence incontournable sur la performance des équipes de développement logiciel publiée chaque année par Google — est de pointer du doigt une métrique que la quasi-totalité des équipes négligent : le Rework Rate, ou taux de retravail.
À l'heure où 90 % des développeurs utilisent l'IA au quotidien — une progression de 14 points en un an, soit l'accélération d'adoption la plus rapide jamais enregistrée pour une technologie — cette métrique devient le baromètre le plus honnête de la santé réelle de votre organisation. Elle est aussi, selon DORA 2025, "la nouvelle star" des métriques de performance pour 2025.
Dans cet article, nous allons décortiquer pourquoi le Rework Rate révèle ce que vos tableaux de bord habituels dissimulent, comment l'IA transforme cette équation, et ce que cela implique concrètement pour vos équipes.
Qu'est-ce que le Rework Rate, exactement ?
Le Rework Rate mesure la proportion du travail produit qui doit être repris, corrigé ou rejeté après sa première livraison. Dit autrement : sur tout ce que votre équipe développe, quelle part finit par repartir en arrière avant d'atteindre la production ?
Cette définition simple cache une réalité complexe. Le retravail peut prendre de nombreuses formes :
- Un bug détecté en phase de revue de code qui nécessite une correction et un nouveau cycle de validation
- Une feature rejetée lors de la démo parce qu'elle ne correspond pas aux besoins métier réels
- Du code généré par IA qui compile, passe les tests superficiels, mais introduit une logique incorrecte découverte plus tard
- Une migration de base de données qui doit être refaite parce que l'architecture initiale n'était pas adaptée au volume de données réel
- Des tests écrits après coup pour valider du code déjà fusionné — l'anti-pattern classique
Le problème fondamental du Rework Rate, c'est son invisibilité. La plupart des équipes mesurent leur vélocité en story points livrés, en commits par développeur, ou en features déployées par sprint. Ce que ces métriques ne capturent pas, c'est le coût caché du retravail qui pollue chaque sprint suivant.
Imaginez une équipe qui livre 40 story points par sprint. Si 15 de ces points correspondent à du retravail sur des fonctionnalités des sprints précédents, la vélocité nette de création de valeur est bien plus proche de 25 que de 40. Mais le reporting dit 40. Et le manager est satisfait.
C'est cette illusion que le Rework Rate vient briser.
L'Effet Miroir : quand l'IA rend le problème insupportable
Pour comprendre pourquoi le Rework Rate est devenu central en 2025, il faut comprendre ce que le rapport DORA appelle l'Effet Miroir de l'IA.
L'intuition de départ est simple mais souvent mal comprise : "L'IA est un amplificateur, pas une baguette magique. Elle ne résout aucun problème structurel. Elle les révèle, les accélère, les multiplie."
Voici comment cela se traduit concrètement. Avant l'IA, dans une équipe de développement classique :
- Écrire une feature prenait 3 jours
- La faire réviser et valider prenait 3 jours
Un certain équilibre existait. Les goulots étaient présents, mais masqués par la lenteur globale du processus. Personne ne se plaignait vraiment, parce que tout allait à peu près à la même vitesse.
Introduisez un assistant de code IA. Désormais :
- Écrire la même feature prend 3 heures
- La faire réviser et valider prend… toujours 3 jours
L'embouteillage devient soudainement visible et insupportable. Les développeurs produisent du code à une cadence que les processus humains de validation ne peuvent tout simplement pas absorber. Les seniors — ceux dont le jugement est irremplaçable — passent l'essentiel de leur temps à revoir du code au lieu de concevoir l'architecture de demain ou de résoudre les problèmes complexes. La qualité se dégrade parce que les revues sont bâclées. Et le Rework Rate explose.
C'est là que réside le paradoxe cruel : l'IA ne crée pas le problème structurel, elle le révèle avec une brutalité inédite. Les organisations qui pensaient avoir des processus "corrects" découvrent soudainement que ces processus ne tenaient que grâce à la lenteur naturelle du développement humain.
Ce phénomène a une conséquence directe sur le Rework Rate. Quand les revues s'accélèrent par nécessité mais sans les outils appropriés, quand le code généré par IA est accepté trop rapidement parce que la pression de livraison est forte, les erreurs se multiplient. Ce qui ne se voyait pas avant — parce que le rythme de production était plus lent — devient une avalanche de corrections.
Le Paradoxe de la Confiance : un Rework Rate invisible mais destructeur
Le rapport DORA 2025 révèle une donnée qui mérite qu'on s'y arrête : si 90 % des développeurs utilisent l'IA quotidiennement, environ 30 % d'entre eux ne valident pas systématiquement le code produit avant de l'intégrer.
Ce chiffre illustre ce que nous pourrions appeler le Paradoxe de la Confiance. Les assistants de code IA sont suffisamment convaincants dans leur output pour induire un biais cognitif puissant : le code semble correct, il compile, il respecte souvent les conventions de style — donc on lui fait confiance. C'est précisément pour cela qu'il est dangereux.
Le code produit par IA souffre de pathologies spécifiques que les outils de revue classiques ne détectent pas facilement :
- La cohérence de surface, l'incohérence de fond : le code est syntaxiquement correct mais logiquement défaillant dans le contexte métier spécifique
- Les hallucinations d'API : l'IA génère des appels à des méthodes qui n'existent pas ou ont changé de signature
- La dette technique silencieuse : les solutions générées sont fonctionnelles mais ignorent les patterns architecturaux établis dans le projet
- Les edge cases oubliés : l'IA optimise pour le cas nominal et néglige systématiquement certaines conditions limites
Chacun de ces défauts a le même destin : il sera découvert plus tard, en revue approfondie, en QA, ou pire, en production. Et à chaque fois, c'est du Rework Rate qui s'accumule silencieusement.
La conséquence sur les équipes est double. D'abord, un sentiment trompeur d'accélération — les développeurs livrent plus vite. Ensuite, une dégradation progressive de la stabilité — la fréquence des incidents en production augmente, les cycles de correction s'allongent, et les seniors s'épuisent à gérer des régressions qui n'auraient pas dû exister.
Chez certains de nos clients, nous avons observé cette trajectoire en l'espace de quelques mois seulement après l'adoption d'outils IA sans accompagnement structurel : une euphorie initiale suivie d'un plateau douloureux, voire d'une dégradation des indicateurs de stabilité.
L'Amplification IA : la même force, deux destins opposés
Si l'Effet Miroir est la face sombre de l'amplification, il existe une face lumineuse. DORA 2025 la nomme l'Effet Multiplicateur. Et c'est précisément là que le Rework Rate devient une métrique stratégique plutôt que simplement diagnostique.
La formule est brutalement simple : IA + Fondations Solides = Performance Exponentielle. À l'inverse, IA + Fondations Fragiles = Chaos Amplifié.
Pour les équipes qui ont construit des fondations robustes, l'IA multiplie la vélocité sans dégrader la qualité. Trois conditions sont identifiées par DORA comme déterminantes :
Des tests automatisés avec une couverture significative
Lorsque votre suite de tests est robuste, le code généré par IA peut être validé quasi-instantanément. Le Rework Rate reste bas parce que les régressions sont détectées en secondes, pas en jours. L'humain peut se concentrer sur la revue des aspects que les tests ne couvrent pas : la pertinence architecturale, la lisibilité, l'adéquation au contexte métier.
Un pipeline CI/CD mature
Un pipeline de déploiement continu avec rollback automatique transforme chaque livraison en événement à faible risque. Quand un problème lié au code IA atteint la production, il est détecté et corrigé rapidement, limitant l'impact du retravail à son strict minimum.
L'Infrastructure as Code
La gestion déclarative de l'infrastructure permet de provisionner des environnements à la volée. Les développeurs peuvent expérimenter avec le code IA dans des environnements isolés, valider, et promouvoir en production — sans que chaque expérience ne devienne une dette opérationnelle.
Ce que ces trois éléments ont en commun ? Ils déplacent la détection des erreurs le plus tôt possible dans le cycle de vie. Et dans la logique du Rework Rate, une erreur détectée pendant le développement coûte infiniment moins cher — en temps, en moral, en dette technique — qu'une erreur découverte en production.
L'IA, dans ce contexte favorable, devient ce qu'elle promet d'être : un accélérateur net qui libère du temps cognitif pour les problèmes à haute valeur ajoutée. Les seniors conçoivent l'architecture. Les développeurs juniors montent en compétences plus vite. Et le Rework Rate, loin d'exploser, peut même diminuer parce que les outils de validation sont meilleurs et plus rapides.
Mesurer le Rework Rate : par où commencer ?
L'une des raisons pour lesquelles le Rework Rate est une "métrique cachée" est qu'elle n'est pas nativement disponible dans la plupart des outils de gestion de projet. Il faut la construire délibérément. Voici les approches que nous recommandons chez SFEIR pour les équipes qui souhaitent commencer ce travail.
L'approche par les tickets de correction
La méthode la plus directe consiste à catégoriser vos tickets dans votre outil de suivi (Jira, Linear, etc.). Un ticket est du "retravail" s'il correspond à la correction ou la révision d'un travail déjà livré — qu'il s'agisse d'un bug, d'une non-conformité fonctionnelle ou d'une refonte technique liée à une mauvaise décision antérieure. Le ratio tickets de retravail / total des tickets sur une période donne une première approximation.
L'approche par les cycles de review
Une pull request qui nécessite plus d'un cycle de révision substantielle est un signal de retravail. En mesurant le nombre moyen de cycles par PR — et en distinguant les PR sur du code "humain" des PR sur du code généré par IA — vous obtenez un indicateur particulièrement révélateur de l'impact réel de l'adoption IA.
L'approche par les régressions
En production, le taux de régressions (fonctionnalités qui fonctionnaient et qui ont été cassées par une modification ultérieure) est une forme de Rework Rate à haute valeur. C'est aussi le plus coûteux. Votre système d'observabilité devrait vous permettre de le mesurer.
Quel que soit l'angle choisi, l'important est de séparer le retravail lié au code IA du retravail "traditionnel". Cette distinction révèle si votre adoption de l'IA est en mode Effet Miroir (amplification des faiblesses) ou en mode Effet Multiplicateur (amplification des forces).
Une précaution importante : le Rework Rate n'est pas une métrique à utiliser pour évaluer les individus. C'est un indicateur systémique. Un taux élevé pointe vers un problème de processus, de tests, d'architecture ou de culture — pas vers un développeur insuffisamment compétent.
Ce que le Rework Rate dit de votre maturité organisationnelle
Au-delà de son rôle de baromètre de l'adoption IA, le Rework Rate est un révélateur puissant de la maturité globale de votre organisation technique. DORA 2025 identifie plusieurs profils d'équipes selon leurs pratiques, et le Rework Rate est l'un des discriminants les plus nets entre ces profils.
Une organisation avec un Rework Rate chroniquement élevé souffre généralement de plusieurs dysfonctionnements simultanés :
- Des exigences floues : le travail est repris parce que personne n'avait vraiment défini ce qu'il fallait construire
- Une dette technique non gérée : chaque modification génère des effets de bord imprévus qui obligent à revenir en arrière
- Des silos organisationnels : le code livré par une équipe ne s'intègre pas avec le travail d'une autre, forçant des itérations coûteuses
- Un manque de feedback rapide : les erreurs sont découvertes trop tard dans le cycle, quand le coût de correction est maximal
À l'inverse, une organisation avec un Rework Rate maîtrisé présente des caractéristiques qui sont exactement les prérequis à une adoption réussie de l'IA : des processus clairs, des standards partagés, des boucles de feedback courtes et une culture de la qualité continue.
C'est pourquoi nous conseillons à nos clients de ne pas attendre d'avoir des problèmes visibles pour mesurer leur Rework Rate. Établir cette baseline avant d'accélérer l'adoption IA est une décision stratégique qui évite de nombreuses désillusions. Si votre Rework Rate est déjà problématique, l'IA va l'amplifier. Si vous l'avez sous contrôle, l'IA va amplifier votre capacité à livrer de la valeur.
La perspective SFEIR : transformer l'Effet Miroir en avantage compétitif
Chez SFEIR, nous accompagnons depuis plusieurs années des organisations dans la transformation de leurs pratiques de développement logiciel — bien avant que l'IA ne devienne le sujet de conversation dominant. Cette expérience nous a appris une chose essentielle : les crises révélées par l'IA sont rarement des crises nouvelles. Ce sont des tensions organisationnelles existantes qui attendaient le bon amplificateur pour devenir intenables.
C'est précisément pourquoi nous voyons l'Effet Miroir non pas comme une malédiction, mais comme une opportunité exceptionnelle. Pour la première fois, des problèmes qui étaient tolérés parce qu'ils étaient invisibles ou supportables deviennent des priorités stratégiques incontournables. Le dirigeant qui ne regardait pas les métriques de qualité doit maintenant s'y intéresser. L'équipe qui repoussait la refonte de son pipeline CI/CD n'a plus le choix.
Notre approche pour accompagner les équipes sur le sujet du Rework Rate s'articule autour de plusieurs axes complémentaires :
L'audit des fondations avant l'accélération
Avant de recommander ou d'accélérer l'adoption d'outils IA, nous évaluons systématiquement la maturité des fondations : couverture de tests, qualité du pipeline CI/CD, niveau de dette technique, pratiques de revue de code. Cet audit permet de prédire avec une bonne fiabilité si l'IA va opérer en mode Multiplicateur ou en mode Miroir.
La mise en place des métriques de qualité en amont
Nous aidons les équipes à instrumenter leur Rework Rate avant de déployer des outils IA, afin d'établir une baseline et de mesurer objectivement l'impact de l'adoption. Cette démarche transforme la conversation avec le management : au lieu de débattre de ressentis, on compare des données.
Le renforcement des pratiques de validation du code IA
La spécificité du code généré par IA nécessite des adaptations dans les pratiques de revue. Nous formons les équipes à identifier les patterns d'erreurs typiques de l'IA et à adapter leurs checklists de revue en conséquence — sans alourdir le processus, mais en le rendant plus ciblé.
L'accompagnement culturel
La dimension la plus sous-estimée est culturelle. Accepter de mesurer son Rework Rate, c'est accepter une forme de transparence sur les dysfonctionnements. Dans certaines organisations, c'est un changement significatif. Notre rôle est d'aider les équipes à vivre ce Rework Rate comme un levier d'amélioration et non comme un indicateur de performance individuelle.
L'objectif final n'est pas d'avoir un Rework Rate de zéro — ce serait le signe d'une organisation qui ne prend aucun risque et n'innove pas. C'est d'avoir un Rework Rate conscient, mesuré, et qui diminue progressivement à mesure que les pratiques s'améliorent.
Conclusion : la vraie vélocité se mesure en valeur livrée, pas en lignes de code
Le rapport DORA 2025 arrive à un moment charnière. Jamais autant de développeurs n'ont eu accès à des outils d'assistance aussi puissants. Et jamais la question de ce qu'on fait réellement de cette puissance n'a été aussi cruciale.
Le Rework Rate est la métrique qui tranche entre l'illusion de la vélocité et la réalité de la valeur créée. Une équipe qui produit deux fois plus de code mais dont 40 % finit en retravail n'est pas plus productive — elle est plus épuisée, plus frustrée, et accumule une dette technique qui hypothèque son futur.
L'Amplification IA ne fait qu'intensifier cette réalité. L'Effet Miroir révèle impitoyablement les faiblesses structurelles que vous aviez peut-être appris à ignorer. L'Effet Multiplicateur récompense généreusement les équipes qui ont investi dans leurs fondations.
La bonne nouvelle ? La trajectoire n'est pas une fatalité. Les organisations qui prennent conscience de leur Rework Rate et qui en font une priorité d'amélioration sont exactement celles qui, selon DORA 2025, tirent le meilleur de l'IA. Pas parce qu'elles ont les meilleurs outils. Parce qu'elles ont construit les meilleures conditions pour que ces outils fonctionnent.
Le vrai avantage compétitif de 2025 ne sera pas d'avoir adopté l'IA le plus vite. Ce sera d'avoir su mesurer honnêtement ce qu'elle révèle — et d'en avoir fait une opportunité de transformation durable.
Vous souhaitez évaluer le Rework Rate de votre organisation et comprendre comment l'adoption IA impacte réellement votre performance ? Les experts de SFEIR accompagnent des équipes techniques de toutes tailles dans cette démarche. Échangeons.