Mettre un mot en gras en Markdown prend quatre astérisques. L'italique en prend deux. Jusque-là, tout va bien. Puis on essaie de souligner un passage avec deux underscores, on obtient du gras, et la simplicité du format Markdown commence à montrer quelques failles.

Si vous découvrez encore le format lui-même, commencez par le guide Fichier Markdown (.md) : qu'est-ce que c'est et comment l'ouvrir ?.

Je pars des syntaxes les plus utiles, puis j'aborde leurs pièges, leur compatibilité dans GitHub, Obsidian et Fude, et les problèmes de rendu les plus fréquents.

1. Choisir la bonne syntaxe

Voici les syntaxes que vous utiliserez le plus souvent :

Style	Syntaxe recommandée	Autre syntaxe	Compatibilité
Gras	`texte`	`__texte__`	Markdown standard
Italique	`texte`	`_texte_`	Markdown standard
Gras et italique	`*texte*`	`___texte___`	Markdown standard
~~Barré~~	`~~texte~~`	variable selon l'outil	Extension GFM
Souligné	aucune	HTML selon l'outil	Non standard

En pratique, je recommande les astérisques pour le gras et l'italique :

**texte en gras**
*texte en italique*
***texte en gras et en italique***
~~texte barré~~

Rendu : texte en gras · texte en italique · texte en gras et en italique · ~~texte barré~~

Ils sont lisibles, portables et évitent les ambiguïtés avec les underscores présents dans les noms de fichiers, les identifiants et le code.

2. Mettre du texte en gras

Pour mettre un mot ou une phrase en gras, placez deux astérisques avant et après le texte :

Cette décision est **importante**.

Rendu : Cette décision est importante.

Vous pouvez formater plusieurs mots :

**Ne supprimez pas ce fichier avant la migration.**

Rendu : Ne supprimez pas ce fichier avant la migration.

La seconde syntaxe utilise deux underscores :

Cette décision est __importante__.

Rendu identique : Cette décision est importante.

Les deux formes sont valides. Elles produisent généralement un élément HTML , qui exprime une importance forte et ne se limite pas à un choix visuel.

Je préfère malgré tout **texte**. Les astérisques restent plus faciles à repérer dans la source, surtout au milieu d'un paragraphe contenant des noms comme user_profile ou release_notes.

Ne laissez pas d'espace à l'intérieur

Les marqueurs doivent toucher le texte :

**texte en gras**    ← correct
** texte en gras **  ← incorrect

La seconde ligne peut rester visible telle quelle selon le moteur de rendu. Vous pouvez placer des espaces et de la ponctuation dans le passage, mais pas immédiatement après les astérisques ouvrants ou avant les astérisques fermants.

**Attention : cette action est définitive.**

Rendu : Attention : cette action est définitive.

3. Mettre du texte en italique

Pour écrire en italique, utilisez un astérisque de chaque côté :

Ce réglage est *facultatif*.

Rendu : Ce réglage est facultatif.

Vous pouvez aussi employer un underscore :

Ce réglage est _facultatif_.

Rendu identique : Ce réglage est facultatif.

Les deux formes produisent généralement un élément HTML . L'italique indique une emphase, un terme introduit pour la première fois, un titre d'œuvre ou une nuance dans la phrase.

Là encore, je choisis généralement les astérisques. Les underscores ont une règle particulière à l'intérieur des mots. Cette restriction évite que des identifiants comme mon_fichier_final deviennent partiellement italiques, mais elle crée aussi des différences parfois surprenantes entre les moteurs de rendu.

Comparez :

in*croyable*ment
in_croyable_ment

Dans Fude, seule la séquence « croyable » passe en italique : incroyablement. La seconde forme reste affichée telle quelle : in_croyable_ment.

Les astérisques peuvent donc marquer une partie d'un mot. Les underscores placés au milieu d'un identifiant restent de simples caractères dans Fude et dans la plupart des moteurs modernes. Pour une documentation portable, entourez plutôt un mot ou une expression complète.

Ne confondez pas italique et underscore

Un underscore isolé ne représente pas un soulignement :

_italique_

Rendu : italique. Le texte n'est pas souligné.

Cette confusion est logique : dans un traitement de texte, le bouton « U » signifie souvent underline. En Markdown, l'underscore est seulement une alternative à l'astérisque pour l'emphase.

4. Combiner le gras et l'italique

Pour appliquer les deux styles à tout un passage, utilisez trois astérisques :

***Cette information est vraiment importante.***

Rendu : Cette information est vraiment importante.

Le moteur de rendu imbrique le gras et l'italique. Vous obtenez généralement un élément  contenant un élément , ou l'inverse.

Vous pouvez également mettre seulement une partie d'un passage en italique à l'intérieur du gras :

**Cette étape est _vraiment_ importante.**

Rendu : Cette étape est vraiment importante.

Ou ajouter du gras dans une phrase en italique :

*Cette option reste **expérimentale** pour le moment.*

Rendu : Cette option reste expérimentale pour le moment.

Ces formes fonctionnent dans les moteurs modernes, mais les marqueurs imbriqués deviennent rapidement difficiles à relire dans la source. Si vous devez compter les astérisques plusieurs fois pour comprendre la phrase, la mise en forme est probablement trop complexe.

Ma règle : trois astérisques pour une courte expression, et une imbrication explicite lorsque seule une partie du texte change de niveau d'emphase.

5. Barrer du texte en Markdown

Pour barrer un passage, entourez-le de deux tildes :

La version ~~2.3~~ 2.4 corrige ce problème.

Rendu : La version ~~2.3~~ 2.4 corrige ce problème.

L'ancienne valeur reste lisible, mais son trait indique qu'elle n'est plus valable.

Le barré est utile pour :

montrer une correction sans effacer l'information précédente ;
signaler une option abandonnée ;
conserver l'historique léger d'une décision ;
afficher une tâche annulée sans la supprimer.

- ~~Utiliser une base distante~~
- Conserver SQLite comme source de vérité locale

~~Utiliser une base distante~~
Conserver SQLite comme source de vérité locale

Contrairement au gras et à l'italique, ~~texte~~ ne fait pas partie du socle CommonMark. Le barré est une extension de GitHub Flavored Markdown, souvent abrégé GFM. Les moteurs GFM et de nombreux éditeurs modernes le prennent en charge, mais un parseur Markdown minimal peut afficher les tildes au lieu de barrer le texte.

Certains outils acceptent un seul tilde :

~texte barré~

Fude rend également cette forme comme du texte barré. Je la déconseille malgré tout : elle n'est pas aussi portable, et le tilde possède déjà d'autres usages dans certains systèmes. Deux tildes de chaque côté restent la convention la plus sûre.

Le barré ne fonctionne pas dans un bloc de code

Markdown n'interprète pas la mise en forme à l'intérieur du code en ligne ou des blocs de code :

`~~ancienneCommande~~`

Le lecteur affiche littéralement ~~ancienneCommande~~. C'est volontaire : le code doit rester exact, sans transformation typographique.

Si une commande est obsolète, barrez la phrase qui l'entoure plutôt que son bloc de code :

~~Utilisez la commande suivante :~~

`ancienne-commande`

Rendu :

~~Utilisez la commande suivante :~~

ancienne-commande

6. Souligner du texte en Markdown

Markdown standard ne possède pas de syntaxe pour souligner du texte.

Ces deux formes ne créent donc pas un soulignement :

_texte_     ← italique
__texte__   ← gras

Rendu : texte et texte. Aucun des deux n'est souligné.

Ce choix vient en partie du web : un texte souligné ressemble traditionnellement à un lien. Ajouter un soulignement décoratif au milieu d'un document peut laisser croire qu'un passage est cliquable.

Utiliser du HTML quand le moteur l'autorise

Quand le moteur autorise le HTML brut, vous pouvez rencontrer la balise <ins> :

Ce passage est <ins>souligné</ins>.

<ins> signifie sémantiquement que le texte a été inséré dans le document. Les navigateurs le soulignent par défaut, mais ce n'est pas un équivalent neutre à « je veux une ligne sous ce mot ».

Vous rencontrerez aussi la balise  :

Ce passage est <u>souligné</u>.

Elle produit souvent un soulignement visuel dans les moteurs qui acceptent le HTML brut. En HTML moderne,  représente toutefois une annotation non textuelle, par exemple une faute signalée par un trait. L'utiliser uniquement pour décorer un mot n'est pas toujours le meilleur choix sémantique.

Surtout, aucune de ces solutions n'est portable. Certains lecteurs autorisent le HTML, d'autres le filtrent pour des raisons de sécurité, et d'autres affichent seulement le texte sans son soulignement.

Choisir une alternative plus claire

Avant d'ajouter du HTML, demandez-vous ce que le soulignement doit signifier :

une information importante : utilisez le gras ;
une emphase légère : utilisez l'italique ;
une information devenue fausse : utilisez ~~le barré~~ ;
un lien : créez un vrai lien Markdown ;
un ajout dans une révision : utilisez <ins> seulement si votre plateforme le prend en charge.

Dans la majorité des documents Markdown, le gras remplace mieux le soulignement. Il reste visible, sémantique et portable.

7. Ne pas confondre soulignement et surlignage

Le soulignement ajoute une ligne sous le texte. Le surlignage ajoute un fond coloré, comme un feutre fluorescent.

Certains outils utilisent deux signes égal pour le surlignage :

==texte surligné==

Dans un lecteur qui suit le format GFM sans extension supplémentaire, le rendu reste littéral : ==texte surligné==.

Cette syntaxe existe notamment dans plusieurs applications de prise de notes, mais elle ne fait partie ni de CommonMark ni de GitHub Flavored Markdown.

Le HTML propose aussi  :

Ce passage est <mark>surligné</mark>.

Mais vous retrouvez le même problème de portabilité que pour  et <ins>. Si votre fichier doit circuler entre plusieurs outils, ne construisez pas une information essentielle uniquement avec du soulignement ou du surlignage propriétaire.

8. Comparer le rendu dans GitHub, Obsidian et Fude

Les trois outils affichent sans différence majeure le gras, l'italique, leur combinaison et ~~le barré~~. Les écarts apparaissent surtout avec le HTML et les extensions qui ne font pas partie de GFM.

Sur GitHub

GitHub prend en charge ces syntaxes dans les fichiers .md, les issues, les pull requests et les commentaires.

Dans l'éditeur web, les raccourcis habituels fonctionnent :

Cmd + B sur Mac ou Ctrl + B sur Windows et Linux pour le gras ;
Cmd + I sur Mac ou Ctrl + I sur Windows et Linux pour l'italique.

GitHub autorise aussi <ins>texte</ins> pour obtenir un texte souligné. Gardez en tête qu'il s'agit alors de HTML accepté par GitHub, pas d'une nouvelle syntaxe Markdown. Le même fichier peut perdre ce rendu ailleurs.

La mise en forme peut être utilisée à l'intérieur des cellules d'un tableau. Si vous travaillez avec des données structurées, le guide Tableau Markdown : guide complet avec exemples couvre les limites des cellules, les caractères à échapper et les différences de rendu.

Dans Obsidian

En mode lecture, les marqueurs disparaissent et le texte est rendu. En mode édition, leur visibilité dépend du mode choisi et de la position du curseur.

Obsidian accepte également une partie du HTML brut, ce qui permet d'utiliser  dans de nombreux cas. Cette solution reste liée à Obsidian et aux moteurs qui autorisent la même balise. Si vous exportez vos notes ou les ouvrez dans une application plus stricte, le soulignement peut disparaître.

Pour une base de notes durable, je garde le HTML hors du contenu autant que possible. Le Markdown standard voyage mieux.

Dans Fude

Fude s'appuie sur GFM. Les syntaxes communes présentées plus haut fonctionnent dans l'application comme dans le lecteur Markdown gratuit de Fude.md. Le moteur produit un vrai rendu sémantique pour le gras, l'italique et le barré.

En revanche, Fude ne rend pas  ou <ins> comme du HTML souligné. Le moteur conserve le texte, mais filtre les balises HTML non prises en charge. Ce choix évite qu'un fichier Markdown arbitraire puisse injecter du HTML dans l'interface de lecture.

Je préfère être explicite sur cette limite : si votre document dépend du soulignement HTML, il ne conservera pas cette apparence dans Fude. Utilisez le gras ou l'italique pour les informations qui doivent rester mises en valeur partout.

Vous pouvez coller les exemples de cet article dans le lecteur en ligne pour comparer immédiatement la source et le rendu, sans créer de fichier .md.

Surligner sans modifier le fichier

L'application de bureau propose également un surlignage au niveau du lecteur :

sélectionnez un passage dans un document de votre bibliothèque ;
faites un clic droit sur la sélection ;
choisissez Surligner.

Fude enregistre cette annotation séparément du contenu. Il n'ajoute ni ==texte== ni balise  dans la source : le fichier .md présent sur le disque reste intact.

Pour supprimer l'annotation, faites un clic droit sur le passage concerné et choisissez Retirer le surlignage. Le même menu permet de copier le passage avec son contexte pour l'utiliser avec une IA.

Cette fonction est propre à Fude. Elle reste visible dans l'application, mais pas dans un autre lecteur Markdown.

9. Utiliser la mise en forme dans d'autres éléments

Le formatage en ligne fonctionne dans la plupart des paragraphes, titres, listes, citations, liens et tableaux.

Dans une liste

- **Priorité haute** : corriger la perte de données
- *Optionnel* : revoir les couleurs
- ~~Supprimé~~ : ajouter un second bouton

Priorité haute : corriger la perte de données
Optionnel : revoir les couleurs
~~Supprimé~~ : ajouter un second bouton

Dans un lien

Vous pouvez mettre en forme le texte visible d'un lien :

[Lire le **guide complet**](/fr/blog/fichier-markdown-comment-ouvrir)

Rendu : Lire le guide complet

Le résultat exact peut varier selon les parseurs lorsque les marqueurs sont imbriqués dans les crochets. Pour une compatibilité maximale, gardez le texte du lien simple et placez l'emphase autour de la phrase :

**Important :** consultez le [guide complet](/fr/blog/fichier-markdown-comment-ouvrir).

Rendu : Important : consultez le guide complet.

Le guide sur les liens Markdown détaille les liens en ligne, les références, les ancres et les chemins relatifs.

Dans un tableau

| Statut | Description |
| --- | --- |
| **Actif** | Fonction disponible |
| *Expérimental* | Comportement susceptible de changer |
| ~~Abandonné~~ | Option retirée |

Statut	Description
Actif	Fonction disponible
Expérimental	Comportement susceptible de changer
~~Abandonné~~	Option retirée

Le gras, l'italique et le barré fonctionnent bien dans les tableaux GFM. Le HTML brut et les extensions propriétaires sont moins fiables.

Autour d'une image

Vous ne pouvez pas rendre une image « grasse » ou « italique ». Vous pouvez en revanche mettre sa légende en italique :

![Aperçu du lecteur Fude](./fude-reader.png)

*Le même document affiché en mode lecture.*

Rendu de la légende : Le même document affiché en mode lecture.

Pour les chemins, le texte alternatif, les légendes et la taille, consultez le guide sur les images en Markdown.

10. Échapper les astérisques et les underscores

Parfois, vous voulez afficher les caractères sans déclencher de mise en forme. Ajoutez une barre oblique inversée devant chaque marqueur :

\*ce texte reste entouré d'astérisques\*
\_ce texte reste entouré d'underscores\_

Rendu :

*ce texte reste entouré d'astérisques*

_ce texte reste entouré d'underscores_

Pour afficher une syntaxe complète dans une phrase, le code en ligne reste plus lisible :

Utilisez `**texte**` pour écrire en gras.

À l'intérieur des backticks, Markdown n'interprète pas les astérisques, les underscores ou les tildes.

Cette règle est particulièrement utile quand vous écrivez un guide Markdown en Markdown, exactement ce que je fais dans cet article.

11. Choisir le bon style

La syntaxe ne suffit pas. Une page où chaque phrase est en gras ne possède plus aucune hiérarchie.

Gras : information importante, libellé, avertissement court ou terme à repérer en scannant.
Italique : emphase légère, terme introduit, titre d'œuvre ou nuance.
~~Barré~~ : information supprimée, corrigée ou devenue obsolète mais volontairement conservée.
Souligné : cas exceptionnel, avec une raison claire et un moteur de rendu connu.

Je limite généralement le gras aux éléments qui doivent survivre à une lecture en diagonale. L'italique doit rester léger. Le barré raconte un changement ; s'il n'apporte aucun contexte, supprimer le texte reste souvent plus propre.

Le soulignement est le style le moins portable et le plus ambigu. Sur le Web, il ressemble à un lien. Dans un fichier Markdown, il nécessite souvent du HTML. C'est beaucoup de compromis pour une ligne sous un mot.

12. Résoudre les problèmes courants

« Les astérisques restent visibles »

Vérifiez que vous regardez le rendu du document, pas sa source. Un éditeur de texte affiche naturellement **gras**. Un lecteur Markdown affiche le mot en gras.

Si vous êtes déjà dans un aperçu, vérifiez les espaces :

**correct**
** incorrect **

Rendu : correct, tandis que ** incorrect ** conserve ses astérisques.

« Deux underscores ne soulignent pas le texte »

C'est le comportement attendu :

__texte__

Rendu : texte. Cette syntaxe produit du gras ; Markdown n'a pas de marqueur standard pour le soulignement.

« Le barré ne fonctionne pas »

Votre moteur utilise peut-être uniquement le Markdown de base, sans les extensions GFM. Essayez le fichier dans GitHub, Obsidian ou Fude. Si les tildes restent visibles, votre outil ne prend probablement pas en charge le barré.

Utilisez toujours deux tildes :

~~texte barré~~

Rendu : ~~texte barré~~

« Le formatage s'arrête au milieu de la phrase »

Vérifiez que les marqueurs ouvrants et fermants correspondent :

**gras*       ← incorrect
**gras**      ← correct

Évitez aussi de mélanger astérisques et underscores sans raison. Une imbrication comme **gras et _italique_** est valide ; une alternance improvisée devient vite difficile à déboguer.

« Le HTML souligné disparaît »

Le lecteur filtre probablement le HTML brut. Ce comportement est courant dans les applications qui rendent des documents non fiables.

Si le soulignement porte une information importante, remplacez-le par du gras. Si son apparence est seulement décorative, acceptez que le document puisse s'afficher sans lui.

« Le gras ne fonctionne pas dans du code »

C'est volontaire :

`**pas de gras ici**`

Rendu : **pas de gras ici**. Le code en ligne et les blocs de code affichent leur contenu littéralement. Sortez le texte des backticks si vous voulez appliquer du gras.

13. Le mémo à copier

# Gras
**texte en gras**
__texte en gras__

# Italique
*texte en italique*
_texte en italique_

# Gras et italique
***texte en gras et en italique***
**texte en gras avec _une partie en italique_**

# Barré — extension GFM
~~texte barré~~

# Souligné — HTML, non portable
<ins>texte inséré et souligné</ins>
<u>annotation visuellement soulignée</u>

# Caractères littéraux
\*pas en italique\*
\*\*pas en gras\*\*

# Syntaxe affichée comme du code
`**texte**`

Rendu des syntaxes portables : texte en gras · texte en italique · texte en gras et en italique · ~~texte barré~~

Le gras et l'italique font partie du coeur de Markdown. Le barré est une extension devenue presque universelle. Le soulignement reste l'exception : il dépend du HTML ou d'une syntaxe propre à l'application.

La règle que je retiens est simple : ** pour le gras, * pour l'italique, ~~ pour le barré, et pas de soulignement sauf si le contexte l'exige vraiment. Ce choix garde le fichier lisible dans sa source et prévisible lorsqu'il passe de GitHub à Obsidian, puis à Fude.

Pour compléter votre syntaxe, consultez les guides sur les liens, les images, les tableaux et les lignes horizontales.

Et pour vérifier le résultat sans installer d'application, collez votre texte dans le lecteur Markdown gratuit de Fude.md.

📌 Télécharger Fude

Gras, italique, barré et souligné en Markdown