Un tutoriel explique comment installer un outil en ligne de commande. Il montre la commande à taper, puis, juste en dessous, ce que le terminal affiche en retour : un message de succès, une erreur, un numéro de version. Ces deux lignes ne racontent pas la même chose, et HTML propose une balise différente pour chacune.
<samp> sert précisément à marquer ce que la machine renvoie : la sortie d'un programme, un message d'erreur, le résultat affiché par un système, jamais ce que la personne a tapé ni le code source qui produit ce résultat.
Définition
<samp> (pour sample output, exemple de sortie) enveloppe un texte présenté comme la sortie littérale d'un programme ou d'un système informatique : un message affiché dans un terminal, une réponse d'API imprimée pour l'exemple, un message d'erreur reproduit dans une documentation.
Le navigateur l'affiche par défaut dans une police à chasse fixe, la même que celle utilisée pour <code>, ce qui explique pourquoi les deux se confondent facilement à l'œil. La différence se joue dans le sens, pas dans l'apparence : <samp> montre un résultat, <code> montre le texte du programme lui-même.
Syntaxe et balisage minimal
C'est un élément en ligne, sans attribut spécifique au-delà des attributs globaux. Il s'utilise seul pour une sortie brève, ou enveloppe un bloc plus long à l'intérieur d'un <pre> quand la sortie tient sur plusieurs lignes et doit garder ses espaces et ses retours à la ligne.
<p>La commande affiche <samp>Connexion réussie</samp>.</p>Exemple concret
Une documentation d'installation combine souvent trois balises sur les mêmes lignes : ce que l'utilisateur tape, ce que le terminal répond, et le nom d'un fichier ou d'une commande cité en passant.
<pre><kbd>npm install believemy-cli</kbd>
<samp>+ believemy-cli@2.4.0
added 12 packages in 3s</samp></pre>La saisie et la sortie sont visuellement identiques, en chasse fixe, mais elles ne signifient pas la même chose : l'une est une action de l'utilisateur, l'autre une réponse du système. Un lecteur d'écran correctement configuré peut s'appuyer sur cette distinction pour annoncer le contexte, même si le rendu visuel ne change pas.
Différence avec <code> et <kbd>
Trois balises se ressemblent visuellement et se distinguent par ce qu'elles désignent : le texte du programme, l'action de la personne qui l'utilise, ou la réponse que le programme renvoie.
| Balise | Ce qu'elle représente | Exemple |
|---|---|---|
<code> | Le code source lui-même, ce qui est écrit dans le programme | fetch(url) |
| <kbd> | Ce que la personne saisit au clavier | npm install |
<samp> | Ce que le programme ou le système renvoie | added 12 packages |
Une confusion fréquente consiste à tout marquer en <code> par facilité, y compris les messages de retour. Cela fonctionne visuellement, mais efface une information : <code> dit « voici du code », alors que <samp> dit « voici ce que ce code a produit », une nuance utile pour qui lit la page mot à mot avec un lecteur d'écran ou extrait automatiquement le contenu d'une documentation.
Un message d'erreur affiché à l'écran d'une application, reproduit dans un article ou une documentation à titre d'exemple, relève aussi de <samp> : ce n'est ni du code écrit par un développeur, ni une saisie utilisateur, c'est une sortie du système, au même titre qu'un message de terminal.
Bonnes pratiques
Réservez <samp> à un texte réellement produit par un programme ou un système : sortie de commande, message d'erreur, réponse d'API. N'y recourez pas pour du texte que vous avez simplement envie d'afficher dans une police à chasse fixe, ce rôle purement visuel revient à une classe CSS, pas à une balise sémantique.
Pour une sortie longue de plusieurs lignes, enveloppez <samp> dans <pre> afin de conserver les espaces et les retours à la ligne tels qu'ils apparaissent réellement dans le terminal. Pour une sortie courte au fil d'une phrase, <samp> seul suffit.
Questions fréquentes
Peut-on utiliser <samp> pour un message d'erreur affiché dans une interface graphique ?
Oui, <samp> ne se limite pas aux terminaux. Un message d'erreur reproduit dans une documentation, qu'il vienne d'une ligne de commande ou d'une boîte de dialogue, reste une sortie du système et relève de cette balise.
Faut-il utiliser <samp> ou <code> pour une valeur de retour dans un exemple de code ?
Cela dépend de ce que la ligne représente. Si elle fait partie du programme, par exemple un commentaire qui montre la valeur attendue à l'intérieur du code, <code> reste pertinent. Si elle représente ce que le programme affiche réellement une fois exécuté, <samp> correspond mieux.
<samp> change-t-il l'apparence du texte plus que <code> ?
Non, les deux s'affichent par défaut dans la même police à chasse fixe et sont visuellement quasiment identiques. Ce sont des balises de sens, pas de style : la différence sert à qui lit le code source de la page, un moteur de recherche ou un lecteur d'écran, pas à l'apparence à l'écran.