La demande de changement est revenue une troisième fois. Même fonctionnalité. « Juste un petit ajustement », disait le courriel, comme toujours. Je me souviens d'avoir remonté le fil un mardi après-midi, à regarder ce petit changement rebondir dans le build, dans les tests, dans une démo client qui a viré de bord tranquillement, et de comprendre enfin ce que j'avais manqué pendant trois tours : la chose qu'on réparait sans arrêt n'avait jamais été la chose brisée. L'exigence, elle, l'était.
C'est ça, la reprise des exigences, vue de l'intérieur. Pas un plantage spectaculaire. Une taxe lente. On la paie en billets rouverts, en sprints replanifiés, et dans la façon dont une équipe finit par ne plus croire que « terminé » veut dire terminé, parce que ça arrête de vouloir dire ça. Après 25 ans dans la livraison de logiciels d'entreprise, j'ai une opinion pas très populaire : presque toute cette reprise est évitable, et presque personne ne l'évite là où le monde va la chercher.
Qu'est-ce que la reprise des exigences, et où commence-t-elle?
C'est le travail qu'on refait parce que l'exigence était fausse, manquante ou mal lue, pas parce que le code avait un bogue. La distinction compte plus qu'elle en a l'air. Un défaut de code, c'est une erreur dans la façon dont une chose a été bâtie; un défaut d'exigence, c'est une erreur dans ce qu'on a décidé de bâtir au départ, ce qui veut dire que chaque heure de codage, de test et de revue qui a suivi a été passée à perfectionner la mauvaise cible.
Voici l'indice. Quand un correctif est livré et que la même fonctionnalité revient quand même, habillée d'une plainte un peu différente, ce n'est pas un bogue. C'est une exigence que personne n'a fixée. Le code fait exactement ce qu'on lui a dit. Ce qu'on lui a dit était incomplet, et c'était incomplet bien avant qu'une seule ligne existe, du temps où toute l'affaire était encore une conversation dans une salle.
Combien coûte réellement la reprise des exigences?
Plus que presque personne ne le budgète. Le problème, c'est que la reprise se cache. Elle n'arrive jamais sous une ligne intitulée « reprise ». Elle arrive déguisée en travail normal, un sprint qui a débordé, une fonctionnalité qui avait besoin de « peaufinage », une livraison qui a glissé d'une semaine, si bien que le vrai total reste invisible même quand il gruge tranquillement le tiers du calendrier. Deux chiffres aident à le sortir de l'ombre.
Ce chiffre vient de la construction, pas du logiciel, et je préfère le dire franchement plutôt que de le maquiller. Je le cite quand même, pour deux raisons. La fourchette tient sur un échantillon énorme et vérifié, et sa propre analyse des causes pointe droit vers le côté exigences de la maison : erreurs de conception, oublis, et changements demandés par le client. Remplace « client » par « partie prenante produit » et « conception » par « spec », et tu viens de décrire un projet logiciel mot pour mot.
Prends le bas de la fourchette et ça pique encore. Si le tiers de tout ce que ton équipe fait, c'est du travail refait, alors le tiers de ta paie, de ton calendrier et de la patience de ton monde s'en va dans quelque chose que tu aurais pu attraper plus tôt. C'est le propre fournisseur du marché qui te donne le plafond de l'occasion. La question arrête d'être si la reprise vaut la peine d'être combattue, et devient où la combattre.
Pourquoi la reprise commence-t-elle à la découverte, pas dans le code?
Parce que c'est à la découverte que l'écart se crée. Une exigence est manquée, mal comprise, ou tenue pour acquise en silence, et ensuite tout l'aval se bâtit fidèlement par-dessus cet écart. Le build ne crée pas le défaut. Il en hérite, il l'amplifie, et il le passe aux tests, qui trouvent un symptôme et ouvrent un billet qui décrit le symptôme, pas la cause. Fait que l'équipe corrige le symptôme. La cause, elle, est encore en amont, intacte, prête à produire le prochain billet.
Je pensais que c'était surtout un problème de communication, une affaire d'écrire des documents plus clairs. J'ai changé d'idée. Des documents plus clairs aident, mais l'échec réel est plus tôt et plus discret : la contrainte la plus importante n'a jamais été dite du tout, parce que tout le monde dans la salle tenait pour acquis que tout le monde d'autre la connaissait déjà. Le savoir tacite ne voyage pas dans une spec. Il voyage par la seule personne d'expérience qui se trouve dans la réunion, et seulement si quelqu'un pense à demander.
Il y a quelques années, j'ai mené une plateforme de réclamations bilingue pour un assureur québécois, et un module revenait sans arrêt. Le routage des approbations. On le livrait, une demande de changement rentrait, on l'ajustait, une autre rentrait. Trois tours. Tout le monde appelait ça un petit ajustement d'interface, et je le traitais comme tel, ce qui était mon erreur.
Au quatrième tour, j'ai arrêté de coder et j'ai fait une vraie séance de découverte à la place. Une table, à Boucherville, un analyste, un développeur, une testeuse, et pour la première fois, la superviseure des réclamations qui vivait le processus pour vrai. Vingt minutes plus tard, elle a dit la chose que personne n'avait écrite : au-dessus d'un certain montant, une réclamation exigeait un deuxième approbateur, et ce seuil changeait selon la région. Ça n'avait jamais été une exigence. C'était une hypothèse qui vivait dans la tête d'une personne. On l'a écrite comme une règle testable cet après-midi-là. Les demandes de changement sur ce module ont chuté à presque zéro sur les deux livraisons suivantes. Le correctif, ce n'était pas du meilleur code. C'était une question qu'on aurait dû poser en semaine un.
Quelles habitudes de découverte réduisent vraiment la reprise?
Quatre habitudes font le gros du travail. Aucune n'est brillante. C'est ça le point : réduire la reprise, ce n'est pas une technique révolutionnaire, c'est un petit lot de disciplines pas glamour appliquées avant le build, dans la fenêtre exacte où personne ne ressent la pression de ralentir et où tout le monde paie plus tard de ne pas l'avoir fait. Voici ce qui a marché sur des dizaines de mandats.
Poser les questions qu'on ne pose pas. Pendant la découverte, mets deux questions sur la table pour chaque fonctionnalité : qu'est-ce que ça ne doit jamais faire, et qu'est-ce qui arrive quand le chemin normal brise? Ces deux amorces font sortir les contraintes qui vivent dans la tête du monde. L'ingénieur d'expérience sait ce qui ne doit jamais arriver. La superviseure connaît l'exception. Personne ne l'offre spontanément, parce que pour eux c'est évident, et l'évident, c'est exactement la catégorie de savoir qui ne se rend jamais dans une spec.
Rendre ça concret avec un vrai exemple. Les abstractions cachent les désaccords. Fais marcher un analyste, un développeur et une testeuse à travers un exemple précis et réel de la fonctionnalité, du début à la fin, et les écarts sortent vite, parce qu'un cas concret force une réponse concrète là où une exigence vague laissait chacun imaginer tranquillement quelque chose de différent. Trois personnes, un exemple, trente minutes. C'est la demi-heure la plus payante de tout le processus.
Écrire chaque exigence pour qu'un test puisse la vérifier. « Le système devrait gérer les approbations correctement », ce n'est pas une exigence. C'est un souhait. « Les réclamations de plus de 10 000 $ passent à un deuxième approbateur dans la même région », ça, c'est une exigence, parce qu'un test peut réussir ou échouer là-dessus. Si tu n'arrives pas à imaginer le test, l'exigence n'est pas finie. Réécris-la jusqu'à ce que tu y arrives.
Revalider les règles tacites avec ceux qui les portent. Avant que le build commence, ramène les exigences à la personne qui connaît le domaine dans le corps, pas à celle qui a écrit le billet, et demande ce qui manque. C'est l'étape que les équipes sautent sous la pression de l'échéance, et c'est celle qui attrape le seuil régional, la ligne réglementaire, la règle que tout le monde tenait pour acquise. Cinq personnes dans une salle pendant une heure, c'est moins cher que cinq sprints de reprise. À chaque fois.
Un avertissement, appris à la dure. N'en fais pas un processus lourd avec des gabarits et des portes d'approbation, parce qu'à la seconde où la découverte ressemble à de la paperasse, le monde la contourne et te voilà de retour aux hypothèses. Garde ça léger et conversationnel. Le but, ce n'est pas la documentation. C'est la compréhension partagée, écrite juste assez pour qu'un test puisse la tenir.
Est-ce que l'IA qui analyse des exigences réduit la reprise, ou l'aggrave?
Les deux, et laquelle tu obtiens dépend entièrement d'où tu la pointes. Pointe l'IA sur le code avec une exigence floue et elle fait ce qu'elle fait de mieux : elle produit plus, plus vite. Plus de la mauvaise chose, plus vite, parce que le modèle optimise pour l'instruction qu'on lui a donnée et n'a aucun moyen de connaître le seuil régional que personne n'a écrit. Ce n'est pas hypothétique. C'est le motif derrière une bonne partie du coût caché des exigences manquées, et ça se compose comme on l'a décrit dans la règle du 29x : plus tard un écart d'exigence est attrapé, plus il coûte cher à corriger.
Maintenant, pointe la même capacité en amont, sur les exigences elles-mêmes. C'est là que ça devient vraiment utile. ScopeMaster, un outil d'IA qui analyse des exigences, teste les spécifications pour les écarts et l'ambiguïté avant le build, et affirme que l'analyse automatisée peut réduire la reprise de 20 à 50 % et raccourcir les échéanciers de 5 à 25 %. Traite les chiffres de fournisseur avec le scepticisme que les chiffres de fournisseur méritent. Même escomptée, la direction est ce qui compte : l'IA appliquée à la découverte attaque la reprise à sa source, tandis que l'IA appliquée au code sans découverte ne fait que l'industrialiser.
C'est toute l'idée derrière l'intelligence des exigences. C'est la version systématisée des quatre habitudes ci-dessus : faire remonter les contraintes non écrites, lever l'ambiguïté, et transformer les hypothèses en exigences testables avant que le code existe, que ce soit un humain ou un agent qui écrive ce code ensuite. On a parlé de comprimer ce travail de découverte sans couper les coins ronds dans comment comprimer la phase des exigences. La vitesse n'est pas l'ennemie de la qualité ici. La vitesse non gouvernée l'est. Donne au build une spec complète, y compris les parties que tout le monde tenait pour acquises, et la même vélocité qui fabriquait de la reprise se met à la prévenir.
Le chemin le plus court vers moins de reprise
La reprise est un des plus gros coûts cachés de la livraison logicielle, quelque part entre le cinquième et la moitié du travail, et tu ne peux pas la couper là où elle apparaît. Le temps qu'un billet rouvert arrive, le défaut est déjà vieux. Il a été créé en amont, à la découverte, dans une contrainte que personne n'a écrite.
Alors déplace le combat en amont. Pose les questions qu'on ne pose pas, rends les exigences concrètes avec un vrai exemple, écris chacune pour qu'un test puisse la vérifier, et revalide les règles tacites avec ceux qui les portent. Fais ça avant le build, et tu arrêtes de payer trois fois pour la même fonctionnalité.
Quelles sont les questions les plus fréquentes sur la réduction de la reprise?
