La pull request est approuvée. Mais le changement respecte-t-il encore les exigences ?
Résumer cet article avec :
Le code est propre. Les tests passent. La CI est verte.
Deux développeurs ont approuvé la pull request. Tout semble prêt pour le merge.
Pourtant, une question reste parfois ouverte : est-ce que le comportement introduit par ce changement respecte toujours les exigences du logiciel ?
Ce n'est pas une critique de la code review. Une bonne revue permet de détecter des erreurs, de discuter les choix d'implémentation et de vérifier les tests associés au changement. Elle reste indispensable.
Certaines équipes vérifient aussi directement les exigences pendant leurs reviews. D'autres travaillent avec des processus très structurés.
Le problème apparaît surtout lorsque le contexte est dispersé. Le code est dans le dépôt. Les exigences sont dans un autre outil. Les règles applicables sont dans des documents. Les tests apportent une partie des preuves.
Dans ce cas, une pull request peut être correcte d'un point de vue technique et introduire malgré tout un comportement qui ne respecte plus une exigence.
Un changement simple, une divergence simple
Prenons une exigence :
Exigence
Après trois tentatives d'authentification consécutives échouées, le compte doit être verrouillé pendant 30 minutes.
L'implémentation actuelle respecte cette règle.
La durée de 30 minutes est définie directement dans le code.
Lors d'un refactoring, l'équipe décide de déplacer cette valeur dans un fichier de configuration. L'objectif est simple : centraliser les paramètres liés à l'authentification.
Mais pendant la modification, la valeur configurée devient 15 minutes.
Le code compile.
Le changement est propre.
Les tests passent.
Pourquoi ?
Parce que les tests existants vérifient que le compte est bien verrouillé après trois tentatives échouées. Ils ne vérifient pas combien de temps il reste verrouillé.
La pull request peut donc être approuvée alors que le logiciel ne respecte plus l'exigence.
L'exigence dit 30 minutes.
L'implémentation utilise maintenant 15 minutes.
Les tests vérifient le verrouillage, mais pas sa durée.
Tout est vert. Pourtant, le comportement est faux.
Ce qui manque parfois dans le contexte de la review
Le reviewer voit le diff. Il voit les tests modifiés. Il peut comprendre précisément ce que le développeur a changé.
Mais cela ne suffit pas toujours pour savoir ce que le changement devait préserver.
Dans notre exemple, la valeur 15 minutes peut sembler parfaitement valide lorsqu'on la lit uniquement dans le code.
C'est l'exigence qui montre le problème.
Le même cas peut apparaître avec une limite numérique, un délai, une condition d'activation, une transition d'état ou une règle de sécurité.
Le problème n'est donc pas de revoir davantage de code.
Il faut relier le changement au comportement attendu.
Cela demande généralement de répondre à quelques questions : quelles exigences peuvent être affectées ? Qu'imposent-elles exactement ? Le nouveau comportement respecte-t-il encore ces contraintes ? Et les tests permettraient-ils de détecter une divergence ?
Partir du changement, puis regarder son impact
Il ne s'agit pas de relire toute la spécification pour chaque pull request.
L'effort doit rester proportionné au changement et au risque.
Un renommage ou un refactoring purement interne ne demande pas la même analyse qu'une modification d'un calcul critique, d'une machine à états ou d'un mécanisme d'authentification.
Le point de départ reste donc le changement.
À partir de là, on cherche ce qu'il peut affecter.
Dans notre exemple, le diff déplace une durée vers un fichier de configuration. La question devient immédiatement : cette durée est-elle contrainte par une exigence ?
Si oui, il faut vérifier que la valeur attendue est toujours respectée.
Une méthode en six étapes
Une review fondée sur les exigences suit la logique représentée dans cette image.
On part du changement. On cherche ensuite les exigences ou les règles qu'il peut affecter. Une fois ce contexte retrouvé, on regarde ce qu'il impose réellement au logiciel.
On peut alors comparer ces contraintes au nouveau comportement.
Les tests et les autres preuves viennent ensuite. La question n'est pas simplement de savoir s'ils passent, mais s'ils permettraient de détecter la divergence que l'on cherche.
Enfin, il faut prendre une décision. Le code peut devoir être corrigé. Un test peut manquer. Une exigence peut être ambiguë ou ne plus correspondre au besoin actuel.
Dans notre exemple, toute l'analyse tient en trois lignes :
Exigence : 30 minutes.
Implémentation : 15 minutes.
Tests : aucune vérification de la durée.
Le problème devient évident dès que ces informations sont réunies.
C'est justement le point difficile.
Voir 15 minutes dans un diff ne suffit pas à savoir que cette valeur est incorrecte. Il faut retrouver l'exigence qui impose 30 minutes, comprendre qu'elle s'applique à ce changement et vérifier que les tests ne couvrent pas cette durée.
Sur un exemple aussi simple, cela prend quelques secondes.
Le vrai problème est de refaire cette analyse à chaque changement
Un projet réel contient rarement une seule exigence et quelques tests.
Il peut en contenir des centaines ou des milliers. Plusieurs standards peuvent s'appliquer. Des politiques internes ajoutent d'autres règles. Les tests sont répartis entre plusieurs composants et plusieurs niveaux de vérification. Plusieurs pull requests évoluent en parallèle.
La méthode ne devient pas plus compliquée pour autant.
Ce qui devient difficile, c'est de réunir le bon contexte au bon moment.
Pour chaque changement, il faut retrouver ce qui peut être affecté, localiser les bonnes sources, lire les passages pertinents et les mettre en regard du code.
Puis recommencer à la pull request suivante.
Appliquer cette analyse à chaque pull request avec KomAInu
C'est précisément pour ce problème que nous avons développé le Compliance Reviewer de KomAInu.
Le principe reste celui que nous venons de décrire.
Le Compliance Reviewer part du changement de code dans la pull request et l'analyse avec le contexte applicable au projet : exigences, standards, politiques internes et autres documents fournis à KomAInu.
Il recherche alors les divergences potentielles entre ce que le changement introduit et ce que ces sources imposent.
Dans notre exemple, 15 minutes n'est pas un problème en soi.
La valeur devient problématique lorsqu'elle est comparée à l'exigence qui impose un verrouillage de 30 minutes.
C'est ce rapprochement qui compte.
Le reviewer n'a pas seulement besoin de savoir qu'une valeur a changé. Il a besoin de voir la règle avec laquelle ce changement peut entrer en conflit.
Le Compliance Reviewer cherche à apporter ce contexte pendant la review.
Lorsqu'un point est remonté, le finding est relié à sa source. Le reviewer peut voir pourquoi le changement est signalé et retrouver le passage qui justifie le constat.
Cela évite qu'un résultat se résume à une alerte difficile à interpréter.
La décision, elle, reste à l'équipe.
Le code peut effectivement devoir être corrigé. L'exigence peut avoir besoin d'évoluer. Une investigation supplémentaire peut être nécessaire. Le finding peut aussi ne pas être pertinent dans le contexte réel du projet.
KomAInu apporte le contexte et fait apparaître les divergences potentielles. Il ne remplace pas le jugement de l'ingénieur.
La valeur devient surtout visible à l'échelle.
Sur le cas 30 → 15, personne n'a besoin d'un outil pour comparer deux nombres.
Le travail difficile consiste à savoir que cette exigence existe, qu'elle est concernée par ce changement et que ce passage précis du document doit être regardé maintenant.
Puis à refaire cette recherche sur les changements suivants.
Avec KomAInu, cette logique peut être intégrée directement à la review des pull requests. Le reviewer n'a pas à reconstruire manuellement tout le contexte à partir de plusieurs artefacts avant de pouvoir commencer l'analyse.
La méthode reste la même.
Ce qui change, c'est la capacité à l'appliquer de façon plus systématique lorsque le projet et le nombre de changements grandissent.
Conclusion
Une pull request approuvée indique que le changement a été revu.
Des tests verts indiquent que les comportements qu'ils vérifient sont toujours satisfaits.
Mais lorsqu'un changement touche au comportement du logiciel, une dernière question reste utile avant le merge :
Qu'est-ce que ce changement devait préserver ?