Remonter d'un résultat faux à la règle qui l'a produit
Sur une feuille de mille lignes, la question utile n'est pas « que fait ce modèle » mais « quel modèle a produit ce nœud de sortie ». C'est l'inverse du parcours habituel.
Un débogueur ordinaire répond à « où en suis-je ». Devant une sortie fausse, la question qui fait
gagner du temps est l'autre : ce <total> erroné, quelle règle l'a écrit ?
Parcourir la feuille dans le sens de la lecture pour y répondre revient à simuler la transformation de tête. C'est faisable sur cent lignes, coûteux sur trois cents, illusoire au-delà.
La démarche inverse — partir du nœud de sortie et remonter à l'instruction — s'appelle le back-mapping. Elle donne une réponse exacte dans un cas précis, et rien du tout dans deux autres. Savoir lesquels est ce qui la rend utilisable.
Ce qu'elle donne
✅ Pour tout nœud directement produit par une instruction littérale, elle désigne l'instruction et le nœud source qui était courant à ce moment-là.
<xsl:template match="facture">
<total><xsl:value-of select="sum(ligne/montant)"/></total>
</xsl:template>
Un <total> faux dans la sortie remonte ici en un geste : l'élément littéral <total>, le modèle
qui le contient, et la facture traitée. Les deux moitiés du problème sont sur la même ligne —
la règle et la donnée.
C'est la situation la plus fréquente, et c'est celle où reconstituer le chemin de tête coûte le plus cher, parce que rien dans la sortie ne nomme le modèle.
Ce qu'elle ne donne pas
⚠️ Une valeur qui a transité par une variable globale perd son lien. L'instruction qui écrit
n'est plus celle qui a calculé : le back-mapping désigne le xsl:value-of qui a émis la valeur,
pas le xsl:variable qui l'a fabriquée. La piste reprend alors sur la variable elle-même, et ses
causes de vacuité sont décrites dans
une variable XSLT vide : les trois causes qu'on ne voit pas.
⚠️ Le texte produit par les règles par défaut n'appartient à aucune règle écrite. Quand la sortie contient du texte nu sans balise, il n'y a rien à remonter : c'est précisément le symptôme n° 4 des cinq causes silencieuses d'un XSLT vide, et la réponse est qu'aucun de vos modèles ne s'est appliqué.
⚠️ Un nœud absent ne se remonte pas. Le back-mapping explique ce qui a été écrit, jamais ce qui ne l'a pas été. Pour un élément manquant, la question redevient « quel modèle aurait dû s'appliquer », et l'outil est le point d'arrêt — voir poser un point d'arrêt dans une feuille de style XSLT.
🔴 Cette asymétrie est la propriété la plus importante de la démarche : elle est excellente sur le faux, muette sur le manquant. La confondre fait chercher pendant des heures une règle qui n'existe pas.
Les deux sens, et quand employer lequel
| La question | Le sens | Ce qu'on regarde |
|---|---|---|
| « quelle règle a écrit ce nœud ? » | sortie → feuille | un résultat faux, précis, isolé |
| « qu'est-ce que ce modèle produit ? » | feuille → sortie | un modèle suspect, ou une modification à valider |
Le second sens est le complément naturel du premier : une fois la règle trouvée, on la modifie, et la question devient « qu'est-ce que ça change dans la sortie ». Les deux se lisent dans le chapitre analyser du manuel.
Une méthode manuelle, quand l'outillage manque
Sans back-mapping, la démarche se bricole — et il vaut mieux savoir comment, parce qu'elle marche partout :
<xsl:template match="facture">
<total origine="facture/total">
<xsl:value-of select="sum(ligne/montant)"/>
</total>
</xsl:template>
Un attribut temporaire nommant le modèle rend la sortie auto-descriptive. ⚠️ Le coût est réel : il faut instrumenter chaque modèle suspect, la sortie n'est plus conforme au schéma attendu, et l'attribut finit un jour en production si personne ne le retire. C'est un dépannage, pas une méthode.