Mardi matin, 9 h 12, salle de conference au centre-ville de Montreal. Un Scrum Master ouvre le sprint review devant une douzaine de personnes fatiguees. Il annonce fierement : « On a livre 34 points ce sprint. » Tout le monde hoche la tete. Sauf que personne dans la salle ne pose la question qui tue : combien de ces 34 points ont servi a reconstruire quelque chose qu'on avait deja livre le mois d'avant? J'ai vu cette scene, ou une variante proche, des dizaines de fois en 25 ans de livraison logicielle. Les equipes acceptent des delais de 3 mois pour 6 semaines de travail reel, et personne ne bronche. Pas parce qu'elles sont incompetentes. Parce qu'elles n'ont jamais vu a quoi ca ressemble sans le freinage constant des requis floues, incompletes ou mal alignees. C'est pourquoi la plus grande percee en logiciel ne viendra pas du code.
J'appelle ca le Probleme invisible. Et tant qu'on ne le voit pas, oubliez ca, on ne peut pas le corriger.
Qu'est-ce que le "Probleme invisible" dans la livraison logicielle?
Le gaspillage. Il se cache dans chaque estimation logicielle, sauf que personne ne l'a jamais nomme ni mesure. On parle de l'ecart (souvent enorme) entre ce qu'une equipe pourrait livrer si ses requis etaient claires et validees, et ce qu'elle livre vraiment avec les specs ambigues dont elle herite d'habitude. Cet ecart-la? Il existe dans a peu pres toutes les organisations que j'ai accompagnees en 25 ans.
Concretement? Un product owner a Quebec ou a Gatineau redige un requis entre deux meetings. L'equipe de dev l'interprete du mieux qu'elle peut, elle build pendant deux semaines, et la, a la demo, le VP regarde l'ecran et lache : « Ben non, c'est pas ca que je voulais dire pantoute. » On recommence. Mais personne ne log ca comme un echec de requis. Ca passe sous « affinage », « iteration », ou pire, ca se noie dans la velocite du sprint suivant sans que personne ne s'en apercoive. Reel. Le gaspillage est reel. Pas de nom. Pas de mesure. Pas de responsable.
Vous ne pouvez pas optimiser ce que vous ne voyez pas. Et la plupart des equipes n'ont jamais vu leur processus de requis assez clairement pour savoir combien cela leur coute.
Pourquoi invisible? Aucun point de reference. Les equipes ont toujours fonctionne comme ca, 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 velocite, comme le chauffage qu'on paie sans jamais verifier si les fenetres sont ouvertes en plein janvier a Montreal.
attente, retouche et clarification des requis
Comment savoir si votre equipe a un probleme de requis?
Honnêtement? La plupart des equipes qui ont un probleme de requis ne s'en doutent meme pas. Les symptomes se deguisent. Dette technique. « Mauvaises estimations. » « Problemes de capacite. » 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 repond « oui » a trois ou plus, c'est pas mal certain que l'equipe a un probleme de requis invisible.
- Plus de 20% de l'effort du sprint va vers la retouche? L'etude Microsoft "Time Warp" de 2024 montre que les developpeurs ne consacrent que 32% de leur temps a ecrire du nouveau code. Le reste? Attente, retouche, clarification. Si l'equipe ne peut meme pas repondre a cette question avec un chiffre precis, c'est deja le premier red flag.
- Les parties prenantes disent-elles souvent « c'est pas ca que je voulais » aux demos? Si ca arrive plus qu'une fois par sprint, on build a partir d'hypotheses mal alignees. Le code est correct; c'est la spec qui etait 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, ca, c'est du gaspillage invisible pur. Si on ne les compte pas, on ne peut pas les gerer.
- Un dev peut-il expliquer la logique d'affaires des trois items principaux du sprint? Si les developpeurs buildent des features sans comprendre le « pourquoi » derriere, ils prennent des centaines de micro-decisions de conception sans contexte. Chacune est une bombe a retardement pour l'alignement.
- Quand a-t-on retire pour la derniere fois une feature livree que personne n'utilisait? Si la reponse est « jamais », on ne mesure pas l'adoption. Et sans mesure d'adoption, on n'a aucune idee du pourcentage de l'effort qui produit reellement de la valeur.
Chez Spotify, les nouveaux ingenieurs prenaient plus de 60 jours pour merger leur dixieme pull request. Soixante jours. Et le probleme n'etait pas la competence technique. C'etait de la friction invisible partout : des processus d'onboarding flous, de la documentation eparpillee dans une vingtaine de wikis, et aucun outillage standardise. Les devs passaient leur temps a naviguer dans le systeme au lieu de builder.
Quand ils ont deploye Backstage (leur portail developpeur interne qui centralise la doc, la propriete des services et les normes de projet), ce repere de 60 jours est tombe a 20. Ca fait 67% de reduction. Et les ingenieurs qui utilisaient la plateforme etaient 2,3 fois plus actifs sur GitHub que ceux qui ne l'utilisaient pas. C'est quand meme pas rien.
La lecon? Le gaspillage etait invisible parce que tout le monde l'acceptait comme « la facon dont ca marche ici, c'est normal. » Des que Spotify a rendu la friction visible et standardise le parcours, les gains ont suivi. Immediatement.
Sources: InfoQ, Backstage at Spotify, Spotify Engineering Blog
Pourquoi les entreprises ne realisent-elles pas combien la retouche leur coute?
Mesure. Un mot. La raison fondamentale, si on est franc, tient la-dedans. On ne peut pas ameliorer ce qu'on ne suit pas. La velocite? Les equipes la trackent. Les bugs? Aussi. La frequence de deploiement? Mesuree, graphiquee, presentee en comite avec des beaux slides. Mais d'ou vient la retouche? Bizarrement, personne ne le suit. Ce point de donnees manquant cree un angle mort assez large pour cacher des milliards de dollars de gaspillage par annee, a l'echelle de l'industrie.
principalement en raison de requis mal alignees
Trois raisons structurelles. J'ai mis du temps a les demeler moi-meme. La premiere : mauvaises etiquettes. Un requis mal compris, ca atterrit dans Jira comme « bogue ». Feature reconstruite? « Dette technique. » Projet qui prend le double du temps? « Scope creep. » Chaque fois, l'etiquette detourne l'attention de la vraie cause, a savoir que les requis n'etaient pas claires, pas completes, pas validees par la bonne personne au bon moment.
Deuxieme raison. Vicieuse, celle-la. La retouche est normalisee dans les attentes de velocite. Quand une equipe livre 40 points par sprint, ce chiffre inclut deja la surcharge de retouche, et personne ne se demande si ca pourrait etre 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 brisee? Ca ne fait qu'accelerer le probleme. On en parle en detail dans La gueule de bois Copilot.
Troisieme raison. La plus frustrante, peut-etre. Il n'existe aucune norme industrielle pour la qualite des requis. Aucune. La qualite du code a ses outils de linting et d'analyse statique. La couverture des tests, ses suites automatisees. La frequence de deploiement, ses dashboards. La qualite des requis? Rien. Nada. Tant que ca ne change pas, le probleme reste invisible pour tout le monde sauf ceux qui en souffrent quotidiennement.
A quoi ressemble une evaluation de la maturite des requis?
La reference. C'est ca que ca donne, une evaluation de maturite des requis : la reference que votre equipe n'a jamais eue. On mappe ou l'organisation se situe sur une echelle de cinq niveaux, depuis le « tout est dans la tete de Marc » (ad hoc, et oui, la plupart des equipes sont la) jusqu'aux processus optimises guides par les donnees. La valeur? Pas le framework en soi. La visibilite qu'il cree. Parce qu'une fois qu'on sait ou on en est, on arrete de deviner et on cible les bons chantiers.
| Niveau | Description | A quoi ca ressemble |
|---|---|---|
| Niveau 1 | Ad hoc | Les requis vivent dans les esprits des gens, dans les fils de discussion Slack ou dans des documents disperses. Pas de format coherent. Pas de processus d'examen. Le succes depend de la memoire individuelle et de la connaissance tribale. |
| Niveau 2 | Documentee | Les requis sont ecrites, mais la qualite varie enormement. Certaines sont detaillees, d'autres sont des phrases uniques. Pas de modele standardise. Les examens se produisent de facon incoherente. |
| Niveau 3 | Standardisee | Modeles coherents, processus d'examen structures et propriete clairement definie. Chaque requis suit un format defini et passe par une etape de validation avant que le developpement ne commence. |
| Niveau 4 | Mesuree | Les metriques de qualite sont suivies: scores de completude, taux de demandes de changement, analyse d'origine des defauts. L'equipe a des donnees sur l'origine du gaspillage et les utilise pour s'ameliorer continuellement. |
| Niveau 5 | Optimisee | La qualite des requis est continuellement amelioree en utilisant les perspectives guidees par les donnees. La validation assistee par l'IA detecte les lacunes avant qu'elles n'atteignent le developpement. L'equipe mesure le cout de chaque changement de requis et optimise de maniere proactive. |
Niveaux 1 ou 2. Soyons honnetes, c'est la que la plupart des equipes qu'on croise operent. Elles savent que les requis comptent (tout le monde le sait, en theorie), mais il leur manque la structure et surtout la mesure pour s'ameliorer de facon systematique. Le truc qui surprend toujours les gens? Juste le passage du niveau 2 au niveau 3 reduit la retouche de 25 a 35 pour cent. Vingt-cinq a trente-cinq. Pourquoi? Parce que c'est exactement la qu'on introduit la validation structuree avant d'ecrire la premiere ligne de code.
Comment commencer a mesurer la qualite des requis des maintenant?
Pas besoin d'une evaluation de maturite complete pour commencer. Serieusement. Trois metriques suffisent, on peut les tracker des ce sprint, et aucun nouvel outil a acheter : ce sont des observations faisables avec Jira, Azure DevOps ou n'importe quel systeme deja en place. (Pour en savoir plus sur l'approche de Specira, consultez notre foire aux questions.)
Metrique 1: Score de completude. Avant chaque sprint, on note chaque requis engagee sur trois dimensions. Clarte : est-ce que n'importe quel membre de l'equipe peut l'interpreter de la meme facon, sans appeler le PO a 17 h pour clarifier? Testabilite : est-ce qu'on peut rediger des criteres d'acceptation sans poser trois questions de plus? Et alignement des parties prenantes : est-ce que le parrain metier a explicitement confirme « oui, c'est ca que je veux »? On note chaque dimension de 1 a 5. Toute requis en dessous de 3 sur n'importe laquelle, c'est un risque de retouche. Point.
Metrique 2: Demandes de changement en cours de sprint. On compte chaque scope change qui arrive apres le sprint commitment. Ca inclut les clarifications de requis qui changent la direction de l'implementation, les feedbacks de parties prenantes qui alterent le resultat attendu, et les dependances qu'on decouvre en plein milieu du sprint (ca, c'est le classique). On suit le volume par sprint et l'effort que chaque changement bouffe. Apres trois sprints, on a une image assez claire de combien de capacite se perd dans les requis qui n'etaient tout simplement pas pretes quand le sprint a demarre.
Metrique 3: Origine du defaut apres lancement. Pour chaque defaut de production, on etiquette la cause racine. C'etait une erreur de codage? Un vice de design? Ou une lacune dans les requis? La plupart des equipes supposent que les defauts viennent du code. Mais quand on commence vraiment a etiqueter les causes racines (et je veux dire avec rigueur, pas « ca semble etre du code »), on decouvre que les erreurs de requis detectees tard dans le cycle coutent entre 3 et 78 fois plus cher a corriger que celles qu'on attrape tot, selon les etudes de cout de cycle de vie de la NASA. Plus on trace les defauts a leur source rapidement, plus vite on arrete de payer ce multiplicateur qui saigne le budget.
Le changement qui change tout
Le Probleme invisible persiste parce que les equipes mesurent la production (features livrees, story points completes, 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-la, presque personne ne la pose. Mais des qu'on introduit ne serait-ce que des metriques de base sur la qualite des requis, le gaspillage devient visible. Et du gaspillage visible, ca se corrige.
On n'a pas besoin d'un processus parfait pour commencer. On a besoin d'une reference, c'est tout. On commence a mesurer ce sprint. On compare les chiffres dans trois mois. Les resultats vont parler d'eux-memes, j'en ai vu la preuve trop souvent pour en douter. Et si on veut voir comment certaines equipes compriment six semaines de travail de requis en quelques heures, la voie est plus proche qu'on pense.
Questions fréquentes
