Faire modifier un comportement déjà en service

Quand l’employer

À employer quand quelque chose fonctionne et doit fonctionner autrement. À ne pas employer pour une fonctionnalité neuve : le risque n'est pas le même, et le gabarit d'incrément complet convient mieux.

Les 5 trous à remplir avant d’envoyer

Chaque trou est une décision déjà prise. Un trou que vous ne savez pas remplir n’est pas une case à improviser : c’est un travail de cadrage qui manque.

{COMPORTEMENT_ACTUEL}

Que fait le système aujourd'hui, exactement, dans les mots de ce que voit l'utilisateur ?

Pourquoi ce trou existe. Décrire l'état de départ empêche l'agent de corriger ce qu'il croit être un défaut alors que c'est une règle voulue.

Si vous ne savez pas répondre. Faites la manipulation vous-même et notez ce que vous voyez, écran par écran. Ce que vous notez est le comportement actuel.

{COMPORTEMENT_VOULU}

Que doit-il faire à la place, en des termes que vous pourrez vérifier à l'écran ?

Pourquoi ce trou existe. Un comportement voulu formulé comme un souhait laisse l'agent choisir son interprétation, et il choisira la plus facile à écrire.

Si vous ne savez pas répondre. Écrivez la phrase « avant je voyais ceci, après je dois voir cela ». Si vous ne pouvez pas la finir, la demande n'est pas mûre.

{CE_QUI_NE_DOIT_PAS_CHANGER}

Quels comportements voisins doivent rester rigoureusement identiques ?

Pourquoi ce trou existe. Une modification touche presque toujours plus large que prévu, et sans liste des invariants, vous ne saurez pas ce que vous devez retester.

Si vous ne savez pas répondre. Cherchez ce qui utilise la même donnée ou le même écran. Ces voisins-là sont vos invariants.

{DONNEES_DEJA_EN_BASE}

Que deviennent les données créées sous l'ancien comportement ?

Pourquoi ce trou existe. Un changement de règle laisse derrière lui des données conformes à l'ancienne règle, et le logiciel doit savoir quoi en faire.

Si vous ne savez pas répondre. Décidez entre trois options avant de lancer le travail : on les laisse telles quelles, on les convertit, on les signale. Il n'y en a pas de quatrième.

{PREUVE_DE_NON_REGRESSION}

Comment prouverez-vous que les comportements voisins n'ont pas bougé ?

Pourquoi ce trou existe. Sans preuve de non régression, un changement réussi et un changement destructeur ont exactement la même apparence.

Si vous ne savez pas répondre. Listez trois manipulations voisines à refaire après le changement. C'est le minimum, et c'est déjà mieux que la confiance.

Le corps du gabarit

Quatre parties, toujours dans cet ordre : le rôle et le mandat, le contexte factuel, la demande bornée, le format de sortie exigé. Les trous restent visibles à la copie, et c’est voulu : les remplir un par un est la dernière occasion de s’apercevoir qu’une décision manque.

## 1. RÔLE ET MANDAT

Tu es développeur, et tu interviens sur du code en service. Ton mandat est de changer un comportement et un seul, en laissant tout le reste rigoureusement identique. Une modification qui améliore au passage est une modification refusée.

## 2. CONTEXTE FACTUEL

Comportement actuel : {COMPORTEMENT_ACTUEL}
Comportement voulu : {COMPORTEMENT_VOULU}
Comportements voisins qui ne doivent pas changer : {CE_QUI_NE_DOIT_PAS_CHANGER}
Sort des données créées sous l'ancienne règle : {DONNEES_DEJA_EN_BASE}
Preuve de non régression exigée : {PREUVE_DE_NON_REGRESSION}

Le comportement actuel est voulu tant que je ne dis pas le contraire. Ce que tu prendrais pour un défaut à corriger en passant est peut-être une décision. Tu le signales, tu ne le corriges pas.

## 3. DEMANDE BORNÉE

Change ce comportement, seul.

Ce que je veux :
1. le plus petit changement qui produit le comportement voulu ;
2. la liste des fichiers touchés, avec pour chacun ce qui a changé en une ligne ;
3. la réponse écrite à la question des données existantes, appliquée dans le code ;
4. la marche à suivre pour constater le nouveau comportement ;
5. la marche à suivre pour constater que chaque comportement voisin est intact ;
6. la liste des endroits du code que tu as vus et volontairement laissés en l'état.

Ce que je ne veux pas : un nettoyage du code environnant, un renommage, une correction d'un autre défaut aperçu au passage, une amélioration de performance, une mise à jour de dépendance.

## 4. FORMAT DE SORTIE EXIGÉ

Deux marches à suivre distinctes et numérotées : une pour le nouveau comportement, une pour les invariants. Les fichiers touchés sont listés avant le code. Tout défaut aperçu et non corrigé figure dans une liste « vu, non touché », avec une phrase sur ce qu'il produit.

Ta réponse est refusable si elle contient une correction non demandée, si la liste « vu, non touché » manque alors que tu as manifestement lu du code voisin, ou si la question des données existantes reste sans réponse appliquée.

Ce que vous devez recevoir

• Le plus petit changement produisant le comportement voulu, et lui seul.
• Une marche à suivre pour constater le nouveau comportement.
• Une seconde marche à suivre pour constater que chaque voisin est intact.
• Un traitement explicite et appliqué des données créées sous l'ancienne règle.
• Une liste « vu, non touché » des défauts aperçus et volontairement laissés.
• La liste des fichiers touchés, avec le motif de chaque modification.

Ce qui doit vous faire refuser

Ces motifs sont écrits comme des constats : « un fichier hors périmètre a été modifié » se vérifie, « le travail manque de rigueur » ne se vérifie pas.

• Un second comportement a changé, même en mieux, alors qu'un seul était demandé.
• Le code environnant a été nettoyé ou renommé, ce qui rend la relecture impossible.
• Les données créées sous l'ancienne règle sont ignorées, sans décision écrite.
• La marche à suivre de non régression est absente ou se résume à une affirmation.
• Un défaut a été corrigé au passage sans être signalé, mélangeant deux sujets.
• L'agent a modifié un comportement voisin en affirmant qu'il était incohérent.

Selon pour qui vous construisez

Pour mon employeur.

Prévenez avant la modification les personnes qui utilisent le comportement actuel. Un changement juste, découvert sans préavis, se vit comme une panne.

Pour un client.

Un changement de comportement en service est une demande formelle, écrite et datée, même quand elle vient d'une conversation. Sans écrit, elle deviendra un reproche.