Mardi matin, 9 h 12, salle de conférence au centre-ville de Montréal. Un Scrum Master ouvre le sprint review devant une douzaine de personnes fatiguées. Il annonce fièrement : « On a livré 34 points ce sprint. » Tout le monde hoche la tête. Sauf que personne dans la salle ne pose la question qui tue : combien de ces 34 points ont servi à reconstruire quelque chose qu'on avait déjà livré le mois d'avant? J'ai vu cette scène, ou une variante proche, des dizaines de fois en 25 ans de livraison logicielle. Les équipes acceptent des délais de 3 mois pour 6 semaines de travail réel, et personne ne bronche. Pas parce qu'elles sont incompétentes. Parce qu'elles n'ont jamais vu à quoi ça ressemble sans le freinage constant des exigences floues, incomplètes ou mal alignées. C'est pourquoi la plus grande percée en logiciel ne viendra pas du code.
J'appelle ça le Problème invisible. Et tant qu'on ne le voit pas, oubliez ça, on ne peut pas le corriger.
Qu'est-ce que le "Problème invisible" dans la livraison logicielle?
Le gaspillage. Il se cache dans chaque estimation logicielle, sauf que personne ne l'a jamais nommé ni mesuré. On parle de l'écart (souvent énorme) entre ce qu'une équipe pourrait livrer si ses exigences étaient claires et validées, et ce qu'elle livre vraiment avec les specs ambiguës dont elle hérite d'habitude. Cet écart-là? Il existe dans à peu près toutes les organisations que j'ai accompagnées en 25 ans.
Concrètement? Un product owner à Québec ou à Gatineau rédige une exigence entre deux meetings. L'équipe de dev l'interprète du mieux qu'elle peut, elle build pendant deux semaines, et là, à la demo, le VP regarde l'écran et lâche : « Ben non, c'est pas ça que je voulais dire pantoute. » On recommence. Mais personne ne log ça comme un échec d'exigences. Ça passe sous « affinage », « itération », ou pire, ça se noie dans la vélocité du sprint suivant sans que personne ne s'en aperçoive. Réel. Le gaspillage est réel. Pas de nom. Pas de mesure. Pas de responsable.
Vous ne pouvez pas optimiser ce que vous ne voyez pas. Et la plupart des équipes n'ont jamais vu leur processus d'exigences assez clairement pour savoir combien cela leur coûte.
Pourquoi invisible? Aucun point de référence. Les équipes ont toujours fonctionné comme ça, depuis le premier sprint. Quel taux de retouche est sain? Bonne question. Personne ne l'a jamais suivi. Combien de scope changes par sprint, c'est « normal »? Personne ne les compte non plus. Le gaspillage finit par se fondre dans les attentes de vélocité, comme le chauffage qu'on paie sans jamais vérifier si les fenêtres sont ouvertes en plein janvier à Montréal.
attente, retouche et clarification des exigences
Comment savoir si votre équipe a un problème d'exigences?
Honnêtement? La plupart des équipes qui ont un problème d'exigences ne s'en doutent même pas. Les symptômes se déguisent. Dette technique. « Mauvaises estimations. » « Problèmes de capacité. » On blame les devs, on blame le process, on blame Jira (souvent avec raison, OK). Cinq questions de diagnostic suffisent pour percer le bruit et trouver la vraie source de friction, et si on répond « oui » à trois ou plus, c'est pas mal certain que l'équipe a un problème d'exigences invisible.
- Plus de 20% de l'effort du sprint va vers la retouche? L'étude Microsoft "Time Warp" de 2024 montre que les développeurs ne consacrent que 32% de leur temps à écrire du nouveau code. Le reste? Attente, retouche, clarification. Si l'équipe ne peut même pas répondre à cette question avec un chiffre précis, c'est déjà le premier red flag.
- Les parties prenantes disent-elles souvent « c'est pas ça que je voulais » aux demos? Si ça arrive plus qu'une fois par sprint, on build à partir d'hypothèses mal alignées. Le code est correct; c'est la spec qui était tout croche.
- Combien de scope changes arrivent en plein sprint? Les changements d'envergure ne sont pas mauvais en soi. Mais les changements non suivis, ça, c'est du gaspillage invisible pur. Si on ne les compte pas, on ne peut pas les gérer.
- Un dev peut-il expliquer la logique d'affaires des trois items principaux du sprint? Si les développeurs buildent des features sans comprendre le « pourquoi » derrière, ils prennent des centaines de micro-décisions de conception sans contexte. Chacune est une bombe à retardement pour l'alignement.
- Quand a-t-on retiré pour la dernière fois une feature livrée que personne n'utilisait? Si la réponse est « jamais », on ne mesure pas l'adoption. Et sans mesure d'adoption, on n'a aucune idée du pourcentage de l'effort qui produit réellement de la valeur.
Chez Spotify, les nouveaux ingénieurs prenaient plus de 60 jours pour merger leur dixième pull request. Soixante jours. Et le problème n'était pas la compétence technique. C'était de la friction invisible partout : des processus d'onboarding flous, de la documentation éparpillée dans une vingtaine de wikis, et aucun outillage standardisé. Les devs passaient leur temps à naviguer dans le système au lieu de builder.
Quand ils ont déployé Backstage (leur portail développeur interne qui centralise la doc, la propriété des services et les normes de projet), ce repère de 60 jours est tombé à 20. Ça fait 67% de réduction. Et les ingénieurs qui utilisaient la plateforme étaient 2,3 fois plus actifs sur GitHub que ceux qui ne l'utilisaient pas. C'est quand même pas rien.
La leçon? Le gaspillage était invisible parce que tout le monde l'acceptait comme « la façon dont ça marche ici, c'est normal. » Dès que Spotify a rendu la friction visible et standardisé le parcours, les gains ont suivi. Immédiatement.
Sources: InfoQ, Backstage at Spotify, Spotify Engineering Blog
Pourquoi les entreprises ne réalisent-elles pas combien la retouche leur coûte?
Mesure. Un mot. La raison fondamentale, si on est franc, tient là-dedans. On ne peut pas améliorer ce qu'on ne suit pas. La vélocité? Les équipes la trackent. Les bugs? Aussi. La fréquence de déploiement? Mesurée, graphiquée, présentée en comité avec des beaux slides. Mais d'où vient la retouche? Bizarrement, personne ne le suit. Ce point de données manquant crée un angle mort assez large pour cacher des milliards de dollars de gaspillage par année, à l'échelle de l'industrie.
principalement en raison d'exigences mal alignées
Trois raisons structurelles. J'ai mis du temps à les démêler moi-même. La première : mauvaises étiquettes. Une exigence mal comprise, ça atterrit dans Jira comme « bogue ». Feature reconstruite? « Dette technique. » Projet qui prend le double du temps? « Scope creep. » Chaque fois, l'étiquette détourne l'attention de la vraie cause, à savoir que les exigences n'étaient pas claires, pas complètes, pas validées par la bonne personne au bon moment.
Deuxième raison. Vicieuse, celle-là. La retouche est normalisée dans les attentes de vélocité. Quand une équipe livre 40 points par sprint, ce chiffre inclut déjà la surcharge de retouche, et personne ne se demande si ça pourrait être 55 ou 60 points sans cette surcharge. Pourquoi? Parce que personne n'a jamais vu la livraison sans. Pitcher des outils de codage IA par-dessus cette fondation brisée? Ça ne fait qu'accélérer le problème. On en parle en détail dans La gueule de bois Copilot.
Troisième raison. La plus frustrante, peut-être. Il n'existe aucune norme industrielle pour la qualité des exigences. Aucune. La qualité du code a ses outils de linting et d'analyse statique. La couverture des tests, ses suites automatisées. La fréquence de déploiement, ses dashboards. La qualité des exigences? Rien. Nada. Tant que ça ne change pas, le problème reste invisible pour tout le monde sauf ceux qui en souffrent quotidiennement.
À quoi ressemble une évaluation de la maturité des exigences?
La référence. C'est ça que ça donne, une évaluation de maturité des exigences : la référence que votre équipe n'a jamais eue. On mappe où l'organisation se situe sur une échelle de cinq niveaux, depuis le « tout est dans la tête de Marc » (ad hoc, et oui, la plupart des équipes sont là) jusqu'aux processus optimisés guidés par les données. La valeur? Pas le framework en soi. La visibilité qu'il crée. Parce qu'une fois qu'on sait où on en est, on arrête de deviner et on cible les bons chantiers.
| Niveau | Description | À quoi ça ressemble |
|---|---|---|
| Niveau 1 | Ad hoc | Les exigences vivent dans les esprits des gens, dans les fils de discussion Slack ou dans des documents dispersés. Pas de format cohérent. Pas de processus d'examen. Le succès dépend de la mémoire individuelle et de la connaissance tribale. |
| Niveau 2 | Documentée | Les exigences sont écrites, mais la qualité varie énormément. Certaines sont détaillées, d'autres sont des phrases uniques. Pas de modèle standardisé. Les examens se produisent de façon incohérente. |
| Niveau 3 | Standardisée | Modèles cohérents, processus d'examen structurés et propriété clairement définie. Chaque exigence suit un format défini et passe par une étape de validation avant que le développement ne commence. |
| Niveau 4 | Mesurée | Les métriques de qualité sont suivies: scores de complétude, taux de demandes de changement, analyse d'origine des défauts. L'équipe a des données sur l'origine du gaspillage et les utilise pour s'améliorer continuellement. |
| Niveau 5 | Optimisée | La qualité des exigences est continuellement améliorée en utilisant les perspectives guidées par les données. La validation assistée par l'IA détecte les lacunes avant qu'elles n'atteignent le développement. L'équipe mesure le coût de chaque changement d'exigences et optimise de manière proactive. |
Niveaux 1 ou 2. Soyons honnêtes, c'est là que la plupart des équipes qu'on croise opèrent. Elles savent que les exigences comptent (tout le monde le sait, en théorie), mais il leur manque la structure et surtout la mesure pour s'améliorer de façon systématique. Le truc qui surprend toujours les gens? Juste le passage du niveau 2 au niveau 3 réduit la retouche de 25 à 35 pour cent. Vingt-cinq à trente-cinq. Pourquoi? Parce que c'est exactement là qu'on introduit la validation structurée avant d'écrire la première ligne de code.
Comment commencer à mesurer la qualité des exigences dès maintenant?
Pas besoin d'une évaluation de maturité complète pour commencer. Sérieusement. Trois métriques suffisent, on peut les tracker dès ce sprint, et aucun nouvel outil à acheter : ce sont des observations faisables avec Jira, Azure DevOps ou n'importe quel système déjà en place. (Pour en savoir plus sur l'approche de Specira, consultez notre foire aux questions.)
Métrique 1: Score de complétude. Avant chaque sprint, on note chaque exigence engagée sur trois dimensions. Clarté : est-ce que n'importe quel membre de l'équipe peut l'interpréter de la même façon, sans appeler le PO à 17 h pour clarifier? Testabilité : est-ce qu'on peut rédiger des critères d'acceptation sans poser trois questions de plus? Et alignement des parties prenantes : est-ce que le parrain métier a explicitement confirmé « oui, c'est ça que je veux »? On note chaque dimension de 1 à 5. Toute exigence en dessous de 3 sur n'importe laquelle, c'est un risque de retouche. Point.
Métrique 2: Demandes de changement en cours de sprint. On compte chaque scope change qui arrive après le sprint commitment. Ça inclut les clarifications d'exigences qui changent la direction de l'implémentation, les feedbacks de parties prenantes qui altèrent le résultat attendu, et les dépendances qu'on découvre en plein milieu du sprint (ça, c'est le classique). On suit le volume par sprint et l'effort que chaque changement bouffe. Après trois sprints, on a une image assez claire de combien de capacité se perd dans les exigences qui n'étaient tout simplement pas prêtes quand le sprint a démarré.
Métrique 3: Origine du défaut après lancement. Pour chaque défaut de production, on étiquette la cause racine. C'était une erreur de codage? Un vice de design? Ou une lacune dans les exigences? La plupart des équipes supposent que les défauts viennent du code. Mais quand on commence vraiment à étiqueter les causes racines (et je veux dire avec rigueur, pas « ça semble être du code »), on découvre que les erreurs d'exigences détectées tard dans le cycle coûtent entre 3 et 78 fois plus cher à corriger que celles qu'on attrape tôt, selon les études de coût de cycle de vie de la NASA. Plus on trace les défauts à leur source rapidement, plus vite on arrête de payer ce multiplicateur qui saigne le budget.
Le changement qui change tout
Le Problème invisible persiste parce que les équipes mesurent la production (features livrées, story points complétés, burndown charts bien lisses) au lieu de mesurer l'alignement. Est-ce qu'on a construit la bonne affaire, pour la bonne raison, du premier coup? Cette question-là, presque personne ne la pose. Mais dès qu'on introduit ne serait-ce que des métriques de base sur la qualité des exigences, le gaspillage devient visible. Et du gaspillage visible, ça se corrige.
On n'a pas besoin d'un processus parfait pour commencer. On a besoin d'une référence, c'est tout. On commence à mesurer ce sprint. On compare les chiffres dans trois mois. Les résultats vont parler d'eux-mêmes, j'en ai vu la preuve trop souvent pour en douter. Et si on veut voir comment certaines équipes compriment six semaines de travail d'exigences en quelques heures, la voie est plus proche qu'on pense.
Questions fréquentes
