LaTeX/À l'aide !
Si LaTeX est un programme très stable (il ne plante pas), il y a en revanche des possibilités de faire des erreurs en entrant les instructions. Cela va se manifester par des messages d'erreur et un résultat non conforme à vos désirs, voire pas de résultat du tout…
"Voir aussi Premier exemple > Déroulement de la compilation."
Comme il s'agit d'un logiciel libre, vous avez une communauté du Web qui sera prête à vous aider, à condition que vous vous montriez poli !
Nous allons voir quelques erreurs communes, comment les éviter, et comment demander de l'aide sur le Web.
Utiliser un éditeur de texte adapté.
Nous avons vu précédemment que le choix d'un éditeur de texte adapté était fondamental (voir "Installer LaTeX > Choisir un éditeur de texte") :
Faire des essais.
Vous voudrez probablement, à un moment ou à un autre, faire des essais, pour tester une commande que vous venez de découvrir ou de créer par exemple. Deux outils peuvent vous être utiles : la classe de document codice_1 et l'extension codice_2.
La classe de document codice_1, comme son nom l'indique, contient le minimum requis pour faire un texte, et rien d'autre. De ce fait, tout ce que vous utilisez dans votre document ne marche pas, mais l'utilisation d'une classe minimale permet de faire fonctionner ce qui est « universel ». Par exemple, vous ne pouvez pas mettre de sectionnement (codice_4, codice_5, …), les listes s'affichent sans symbole ou numéro en tête d'alinéa, les tableaux n'ont pas de filet, …
L'extension codice_2 fournit la commande codice_7, qui génère sept paragraphes d'un texte en pseudo-latin (le fameux "« Lorem ipsum… »"), occupant environ une page. Le texte complet comporte 150 paragraphes, et s'obtient avec codice_8, ce qui représente une vingtaine de pages. Vous pouvez ne mettre que le premier paragraphe en utilisant codice_9. Ceci permet de faire du remplissage.
Voici par exemple un document de test minimal :
 \lipsum
Problèmes de rendu.
Les fichiers générés, utilisés pour la visualisation ou l'impression, sont au format "device independent" (fichier codice_10), Adobe PostScript (fichier codice_11) ou Adobe Portable Document Format (fichier codice_12). Ce ne sont pas des « images figées » qui sont simplement affichées par le visualiseur ; le visualiseur « redessine » à chaque fois le document à partir des informations contenues dans le fichier.
De fait, les différents programmes de visualisation n'ont pas "exactement" le même comportement, et l'on peut obtenir un affichage légèrement différent de ce à quoi on s'attend. L'impression, elle, est en général correcte (elle est gérée par le pilote d'impression, ou "driver", qui interprète « correctement » le fichier).
Ce genre de problème ne se produit pas avec du texte simple, bien que certains visualiseurs peuvent avoir un rendu assez mauvais des polices Computer Modern et Extended Computer Modern. Il va surtout survenir avec des fonds colorés, où l'on peut voir des décalages entre le pavé de couleur et le filet (contour de la boîte), ou bien si l'on fait des dessins (problèmes d'épaisseur de trait).
Face à un tel problème, on peut
pour voir si le problème vient du rendu ou du fichier (et donc du code que vous avez tapé ou bien d'une bogue de l'extension employée).
Nettoyage des fichiers générés.
Parfois, vous pensez avoir corrigé le problème, mais un message d'erreur persiste. Les fichiers générés (codice_17, éventuellement codice_18 et codice_19 pour la bibliographie, et codice_20 et codice_21 pour un index) peuvent contenir des erreurs générées par la compilation de l'ancienne version du document LaTeX. Le fait d'effacer ces fichiers — mais en faisant attention à bien conserver le fichier codice_22 (ils portent tous le même nom …) — peut résoudre le problème.
Consultation du journal des erreurs.
Lors de la compilation, codice_23 (ou codice_24) génère des messages indiquant le bon déroulement de l'opération, ou bien des avertissement et messages d'erreur.
Si vous compilez en ligne de commande, les messages s'affichent dans la fenêtre du "shell". Il peuvent aussi s'afficher dans une fenêtre dédiée de votre éditeur de texte. Sinon, ils sont placés dans un fichier portant le nom du fichier source mais l'extension codice_25, appelé « fichier de "log" » ou « journal des erreurs ».
La première chose à faire est donc de consulter le journal des erreurs afin de voir les problèmes. Il s'agit d'un fichier de texte, s'ouvrant avec n'importe quel éditeur de texte.
Démarche de déverminage.
La première chose à faire est de tenter de résoudre les erreurs indiquées dans le journal des erreurs.
Voir "Chasse aux erreurs"
Parfois, vous n'arriverez pas à résoudre certaines erreurs. La première chose à faire est d'isoler le passage problématique. En effet, une erreur peut se manifester bien plus loin ; par exemple, si vous oubliez de fermer une accolade ou un environnement, tout le texte qui suit est considéré comme influencé par la commande ou faisant partie de l'environnement, et le message peut apparaître lorsque le contenu devient incompatible avec la commande ou l'environnement.
Ordre des extensions.
L'ordre dans lequel les extensions sont déclarées dans le préambule peut avoir de l'importance. En effet, certaines extensions redéfinissent le comportement d'une ou plusieurs fonctions de LaTeX, une fonction peut ainsi se voir redéfinir par plusieurs extensions.
De manière générale, il faut :
Il existe des exceptions, qui sont en général mentionnées dans la documentation de l'extension. Par exemple, l'extension codice_30 doit être placée en dernier (après codice_31) dans le préambule.
Isoler le passage problématique.
Le message d'erreur indique le numéro de ligne où se produit l'erreur. Si vous avez un éditeur de texte adapté, vous retrouverez facilement cette ligne. Il faut alors isoler le passage :
Le passage en cause contiendra évidemment la ligne citée, mais
Puis, on recompile cet ECM. Si l'erreur ne se produit pas, c'est que le problème se trouve ailleurs, on fera une recherche par dichotomie (cf. ci-après). Sinon, on va essayer de simplifier encore l'ECM afin d'isoler vraiment l'erreur.
Pour cela, 
On enregistre et on recompile après chaque simplification : si le problème disparaît, c'est que l'on a enlevé une partie contribuant au problème ; il faut alors la remettre et continuer la simplification.
Cette démarche peut vous permettre de déceler l'erreur. Sinon, vous disposez d'un fichier ECM que vous pourrez soumettre à la communauté Internet.
Recherche par dichotomie.
Si le problème ne se situe pas dans le passage pointé par le journal d'erreur, il va falloir chercher le passage incriminé… La stratégie la plus rapide est la dichotomie :
En quelques étapes, on arrive à isoler l'erreur : si un fichier fait lignes, il contiendra à la première étape, à la deuxième, …, et 10 lignes à la dixième étape.
Si vous n'arrivez pas à résoudre le problème isolé ainsi, vous disposez d'un ECM à soumettre à la communauté Internet.
Rechercher sur Internet.
Mais avant de faire appel à la communauté, il convient d'essayer de vous débrouiller par vous-même.
La première chose à faire consiste à consulter les foires aux questions (FAQ) ; vous avez de nombreuses ressources sur :
Si une extension est en cause, il faut penser à consulter la documentation de cette extension ; une recherche par mots-clefs devrait vous permettre de la trouver.
Notez que vous avez également une documentation installée avec LaTeX. Sous un système Unix, vous pouvez taper en ligne de commande codice_38 pour avoir la documentation en HTML, et codice_39 pour l'avoir en PDF. Si ces commandes ne fonctionnent pas, essayez de chercher « latex2e » sur votre disque dur. Avec la distribution TeXlive sous MacOS X, la documentation HTML se trouve en codice_40, et les fichiers PDF sont dans codice_41 (il existe un répertoire pour chaque extension importante, et un répertoire codice_42 pour LaTeX en général) — le tout en anglais.
La deuxième chose consiste à faire une recherche avec un moteur de recherche, contenant comme mots-clefs les instruction, environnement, extension en cause, ainsi que « latex ». Une recherche dans les archives du groupe usenet fr.comp.text.tex s'impose : vous n'êtes sans doute pas le premier à avoir eu le problème, la solution s'y trouve sans doute déjà. Les archives se trouvent sur
Enfin, si tout cela est infructueux, vous pouvez poster votre problème sur news:fr.comp.text.tex, (fctt pour les intimes) avec un agent usenet (rechercher « usenet » dans l'aide de votre système d'exploitation ; Microsoft Outlook remplit cette fonction, sinon, pensez à Mozilla Thunderbird).
Si vous n'avez jamais posté, la première chose consiste à configurer le lecteur de forums. vérifiez que vous postez bien en texte pur et pas en HTML (en général dans le menu Outil | Options ou bien le menu Préférences de l'application). Cherchez votre adresse mél dans la configuration, et maquillez-là pour éviter d'avoir des messages non-sollicités (spam). Puis, allez faire un test en postant sur le groupe news:fr.test. 
Ceci fait, postez sur fctt :
Surveillez le forum afin de voir les réponses, on vous demandera peut-être de fournir des précisions. Si personne ne répond au bout de 2-3 jours, relancez poliment : personne n'est peut-être compétent sur votre problème, mais peut-être que quelqu'un connaît un endroit où chercher, mais attendait de voir les réponses des autres.
Si l'on vous apporte la solution, n'oubliez pas de dire merci (-:
« Protéger » les commandes « fragiles ».
Dans certains cas, vous utilisez une commande de manière correcte, mais le résultat est erroné en raison du contexte dans lequel elle se trouve. Par exemple, telle commande se comporte bien dans du corps de texte, mais donnera des résultats bizarre si elle est insérée dans une commande codice_4 ou un environnement codice_44.
Une telle commande est dite « fragile ». On peut souvent résoudre le problème en « protégeant » cette commande, c'est-à-dire en mettant une commande codice_45 devant lorsque le problème se pose.
Exemple de commandes fragiles :
Chasse aux erreurs.
Avertissements fréquents.
Avertissements de références.
Voir "Structuration du texte > Erreurs possibles".
Compilation en ligne de commande.
Si vous compilez en ligne de commande, les messages s'affichent dans la fenêtre du "shell", et à moins que vous ne l'ayez précisé par un option, la compilation s'interrompt à la première erreur.
Si vous ne voulez pas que la compilation s'arrête à chaque erreur, il faut la lancer avec l'option codice_62 :
 latex -interaction=nonstopmode "nom_du_fichier"
Dans le cas contraire, la compilation peut s'arrêter et attendre une action de votre part :