VIEUX SCRIPT DÉTECTÉ
“J'ai hérité ce bazar et maintenant tout le monde pense que c'est de ma faute”
Essaie cette réponse :
“Ce bug a une date de naissance, et elle précède mon premier commit ici.”VOIR LA PRATIQUE
Crée une réponse à cette pensée et un geste pour la mettre à l’épreuve.
LA PENSÉE
“J'ai hérité ce bazar et maintenant tout le monde pense que c'est de ma faute”
TA RÉPONSE ENREGISTRÉE
“Ce bug a une date de naissance, et elle précède mon premier commit ici.”
UN PAS PRIVÉ
Choisis un ticket ouvert sur du code hérité et écris une note de deux lignes : c'est quoi le bug, et quand le code a été introduit grossièrement. Ne l'envoie nulle part pour l'instant.
Le ticket qui porte maintenant ton nom
- 01 / Le champ assigné
Un rapport de bug arrive. La stacktrace pointe vers un module que trois ingénieurs ont touché avant même que tu ne découvres le repo. Ton nom figure dans le champ assigné quand même, parce que tu es maintenant celui qui possède le service. Tu ouvres le fichier, tu vois les raccourcis que quelqu'un a pris il y a des années, et tu sens ton estomac se nouer comme si c'était toi qui les avais écrits.
- 02 / Expliquer au lieu de corriger
La pensée tombe vite : ils croient que c'est de moi. Donc au lieu de déposer une note rapide disant que la cause racine précède ton arrivée, tu commences à construire une explication plus longue, parfois un doc entier, en défendant la conception originale pour que personne ne soupçonne que tu as hérité d'un système que tu ne peux pas maîtriser. Ça te couvre pendant quelques heures. Mais ça te dresse à traiter chaque faille héritée comme un événement de réputation, donc le ticket suivant reçoit le même traitement, et la vraie correction attend derrière la défense.
- 03 / La ligne avant de répondre
Le point d'interruption, c'est la seconde avant que tu commences à taper une justification. Remarque-la et pose une question plus étroite d'abord : ce ticket a-t-il besoin d'une correction, ou a-t-il besoin que je prouve que je ne suis pas responsable du passé ? Répondre à la question de la correction seule est généralement plus rapide que la défense que tu étais sur le point d'écrire.
TRACE · 01/04
Comment ce script te dirige
- Tu rédiges des explications sur pourquoi l'ancien code a été écrit de cette façon avant même d'avoir cerné le vrai bug.
- Un message de commit d'une ligne devient un paragraphe justifiant des décisions pour lesquelles tu n'étais pas présent.
- Tu ressens un éclair de culpabilité en lisant du blâme dans un message qui ne te nomme jamais.
SOURCE_LOCATED · 02/04
La règle cachée en dessous
Le Script de l'Héritage Légué
Si une faille est dans le système que je possède maintenant, les autres la liront comme ma faille, alors je dois en rendre compte avant que quelqu'un ne mette en doute ma compétence.
FORGING_REPLACEMENT · 03/04
Lignes de remplacement (à enregistrer)
- Ce bug a une date de naissance, et elle précède mon premier commit ici.
- Une note de correction suffit. Je ne dois pas une défense du code que je n'ai pas écrit.
- Posséder le système n'est pas être l'auteur de chaque ligne dedans.
Générées par personne dans l'app — ceci donne le ton, pas ton script. Le tien se construit à partir de tes mots exacts.
INSTALL · 04/04
Le protocole, sur une carte
Quand je pense
“J'ai hérité ce bazar et maintenant tout le monde pense que c'est de ma faute”
Je dis
“Ce bug a une date de naissance, et elle précède mon premier commit ici.”
Puis je fais une chose
Choisis un ticket ouvert sur du code hérité et écris une note de deux lignes : c'est quoi le bug, et quand le code a été introduit grossièrement. Ne l'envoie nulle part pour l'instant.
STATUS: READY_TO_INSTALL
Effacer cette pensée4 minutes. Ta voix. Gratuit.
Le protocole de wipe
- Écris la pensée exactement comme elle tourne : « J'ai hérité ce bazar et maintenant tout le monde pense que c'est de ma faute ». Mot pour mot — le wipe vise la phrase, pas l'ambiance.
- Repère la règle et l'action évitée. De quoi cette pensée t'excuse-t-elle si commodément ?
- Enregistre les lignes de remplacement ci-dessous avec ta propre voix. Parle pour de vrai — pas d'enregistrement, pas d'installation.
- Fais tourner la boucle : écoute matin et soir, note une action-preuve par jour pendant 7 jours.
Réponses directes
Et si le bug a vraiment empiré sous mon contrôle, pas seulement hérité ?
Alors note spécifiquement ce qui a changé depuis ton arrivée par rapport à ce qui était déjà cassé. Diviser la chronologie en avant-toi et pendant-toi est une étape de délimitation, pas une admission, et ça montre généralement que les dégâts sont plus petits que la culpabilité le suggère.
Pourquoi je me sens responsable même quand personne dans l'équipe n'a dit que c'était de moi ?
Être le propriétaire actuel d'un système te rend le point de contact visible pour son histoire, donc toute plainte sur le système peut sembler dirigée vers toi même quand elle vise le code, pas la personne qui le maintient.
Est-ce mal d'expliquer le contexte hérité à un collègue qui pose une question sur un bug ?
Non. Le contexte est utile quand quelqu'un le demande. Le pattern à surveiller, c'est de rédiger préventivement cette explication avant que quelqu'un ne demande, comme assurance contre un blâme qui n'est pas arrivé.
Vieux scripts liés
Auto-évaluations associées
Recherches associées
Chercheurs à découvrir
Mécanismes associés
La recherche derrière ce script
- Postmortem Culture: Learning from Failure — Google SRE, Google SRE Book, 2016
- Invisible Labor in Open Source Software Ecosystems — Champion et al., arXiv, 2024
- Stack Overflow 2025 Developer Survey: Trust in AI at an All-Time Low — Stack Overflow, 2025
- A Mosaic of Perspectives: Understanding Ownership in Software Engineering — arXiv, 2025