Idée principale

En lisant la documentation d'une autre équipe — une procédure de clôture d'intervention, une politique de sauvegarde —, on repère une erreur. On sait quoi corriger ; cela prendrait trente secondes. Il vaut mieux proposer la correction que la faire.

Celui qui repère l'erreur ne décide pas de la place définitive de la connaissance. C'est l'équipe qui en est responsable qui juge si la correction décrit vraiment son périmètre, ou seulement le cas particulier de celui qui la propose. Ce que le lecteur voit comme une erreur peut être une règle juste ailleurs que dans son propre cas.

Pourquoi c'est important

Cela empêche un résultat local de devenir, en silence, une vérité générale. Une correction directe a toutes les apparences d'un service rendu ; elle peut pourtant réécrire une règle à partir d'un seul point de vue, sans que le propriétaire le sache.

Cela garde aussi l'équipe propriétaire informée de ce que les autres voient dans sa documentation — un signal qu'une correction silencieuse supprime.

Nuances et limites

La règle suppose que proposer soit peu coûteux et que la proposition soit traitée. Si elle reste sans réponse, la tentation de corriger soi-même, ou de recopier une version corrigée chez soi, revient — et la règle produit l'effet qu'elle voulait éviter.

Pour une coquille sans portée sur le fond, le coût de la proposition dépasse le risque.

Questions ouvertes

• Quel délai de traitement une équipe propriétaire doit-elle tenir pour que la proposition reste préférée à la correction directe ?