Écrire un rapport de DEA


Ce texte n'est aucunement un manuel complet de rédaction de rapport. Il s'efforce simplement de recueillir un certain nombre de principes et idées qui, si ils peuvent paraître aller de soit, sont en pratique très couramment oubliés dans un très grand nombre de rapports.
A ce titre, la plupart des conseils sont valables pour la rédaction d'autres types de rapports que les mémoires de DEA.

Généralités.

Mettez-vous suffisamment tôt à votre rapport ! (1 mois pour les DEA, c'est pas du luxe). Ça prend plus de temps que vous croyez, il faut le rendre à l'avance, votre responsable voudra obligatoirement donner son avis avant la version finale (voire corriger plus d'une mouture).
Et de toutes façons, vous découvrirez des travaux inconnus en faisant votre biblio, qui vous donneront des idées, rendront caduque certains pans de vos travaux, ou vous obligerons à vous situer; de même lors des résultats et benchs, vous découvrirez qu'il vous faut quelques développements supplémentaires pour avoir des chiffres, des scènes intéressantes, des comparaisons, optimiser un peu plus, ou... enlever suffisamment de bugs pour être capable de faire tourner quelque-chose en vraie grandeur !

Commencez par soumettre un plan à votre responsable. Demandez-lui s'il préfère relire les chapitres au fur et à mesure, ou une version complète d'un coup. En tout cas, relisez-vous, et faites passer un correcteur orthographique avant ! Pensez bien également que vous n'êtes probablement pas son seul stagiaire, et sûrement pas sa seule source d'occupation...

Ménagez les ressources des autres: si plusieurs personnes vont relire, signalez les parties utiles à relire (qui ont raisonnablement changées, et qui sont raisonnablement stables); ne faites relire une version donnée qu'à une seule personne à la fois!

Le plan.

Comme dit plus haut, à soumettre ou à mettre au point avec votre responsable avant de se lancer à fond dans la rédaction.

Le sommaire doit pouvoir se lire et se comprendre de façon autonome, donc titres ni trop vagues, ni trop techniques.

Subdivisez largement votre document: cela permet au lecteur de bien comprendre ou il en est dans la progression logique, de sauter certaines parties, et de lire facilement en diagonale. Aucun pan de texte ne devrait faire plus d'une page (quitte à structurer avec des \paragraph{titre}), de même qu'il ne devrait pas y avoir de double-page sans figure ou image.
Toute partie ou section devra avoir été introduite avant (que l'on comprenne pourquoi on a besoin de parler de ça maintenant), et commencer par quelques mots (ou plus) d'introduction pour situer ce dont on va parler.

A la fin de l'introduction, vous devez impérativement introduire le plan approximatif de votre document, en référant aux numéros des principales parties ou sections.

La façon de présenter.

Vous n'êtes pas jugés à votre aptitude à faire un programme qui marche, mais à faire de la recherche, et à tirer des conclusions !
Vos programmes sont au mieux des validations, des preuves de concepts, des joujoux pour tester certaines idées. Votre rapport n'est donc surtout pas un manuel de référence ou de développeur du programme !
-> Vous vous êtes confronté à un problème ou une problématique, selon une approche ou une philosophie donnée, qui s'inscrit dans un contexte applicatif et une continuité de recherche, pour laquelle vous avez mis au point (ou vous êtes appropriés) des concepts, des représentations, des méthodes de traitement. Pour vos tests et études, vous avez développé des structures de données et des algorithmes qui n'en sont que des implémentations partielles, avec des limitations en plus, et une efficacité probablement améliorable. Néanmoins vos programmes donnent des résultats (images, benchs) qui permettent de se faire une idée de ce que permet et vaut la méthode.
-> dans vos discussions, distinguez très clairement votre modèle ou méthode de votre implémentation (les deux sont susceptible d'améliorations, mais ce qui concerne les possibilités et limites du modèle ou de la méthode est largement plus important). De plus, ça n'est pas parce qu'une partie du programme vous a demandé du temps qu'elle mérite beaucoup de pages (voire qu'il faille en parler), et réciproquement certains aspects triviaux à programmer correspondent à un aspect essentiel du modèle.

Le lecteur ne connaît pas vos travaux, voire il ne connaît pas vraiment le domaine (e.g. le jury).
-> l'introduction (contexte applicatif, scientifique, évocation du problème, principe de l'approche) devrait être compréhensible par tous (e.g. testez sur vos copains hors labo, sur votre petite soeur...).

Même s'il est du domaine, le lecteur n'est pas expert en tout, et de toutes façons il ne peut absolument pas deviner a priori où vous voulez en venir: toute notion doit être introduite, absolument toute notation doit être expliquée, tous les travaux doivent être référencés (à chaque mention ou presque), et surtout, faites apparaître extrêmement clairement ce qui existait avant et ce qui est votre contribution, i.e. utilisez le `nous' ou `je' explicitement. Un truc qui aide: bannissez autant que possible les passifs (une mode anglo-saxonne envahissante), ce qui permet d'expliciter que quelqu'un a agit (l'auteur d'un papier, ou vous).

Les outils d'édition.

A voir avec votre responsable, mais il y a de très fortes chances qu'il veuille du Latex. C'est l'outil standard en publication scientifique, son contenu et ses résultats (PostScript) sont lisibles par tous et pour longtemps, il évite des erreurs qui deviennent insupportables quand un traitement de texte classique a été utilisé, il se prête extrêmement bien au copier-coller et au recyclage intensif. L'investissement intellectuel est minime (surtout pour un programmeur comme vous!). Le seul point pénible est le placement des figures, mais tout un tas de packages vous facilitent aujourd'hui la vie, et Emacs est également étudié pour.

Pour la biblio, utilisez Bibtex. C'est très souple et aussi facilement recyclable, de plus il existe de nombreux serveurs de biblio à ce format sur web, e.g. Graphbib et. CS-bib. En outre, de nombreux auteurs fournissent l'entrée Bibtex à côté du PostScript de leur article.

Mettez des figures ! des résultats ! des images réelles ! On comprend bien mieux, ça aère, ça explicite l'objectif, et ça incite à la comparaison-validation.

Faites passer un correcteur orthographique (Ispell, ou correcteur sous Emacs) avant de donner à relire, et en tout cas avant la version finale ! et rappelez vous que la grammaire reste à votre charge...

La biblio.

Accumulez au cours de votre stage (sur une feuille, dans un fichier txt, dans un répertoire de bookmarks) les informations bibliographiques au sens le plus large (papiers, livres de références même non scientifiques, URLs). Rien de plus rageant au moment de la rédaction de devoir faire la pêche aux références dont on connaît pourtant le contenu. Pire encore, sans liste à checker au moment de rédiger sa biblio, on a toutes les chances d'oublier de parler de beaucoup de choses. N'hésitez pas à accumuler bien plus de références que nécessaire, `au cas où'. Vous ferez le tri uniquement lors de la rédaction. Il est facile d'ignorer une information en trop, tandis que reconstituer une information perdue peut être long et difficile (pire, si l'on ne pense même plus à son existence).
N'hésitez pas à piocher dans les bouquins d'art, ou de physique.

Ça parait bête, mais vous êtes aussi jugés sur le nombre de pages de la liste des références. Dans d'autres disciplines où la publication est plus facile, oubien la communauté plus large et ancienne, il n'est pas rare d'avoir 4 pages de références. Sans en arriver à autant, comme votre rapport sera comparé aux leurs, il ne faut pas donner l'impression d'avoir bidouillé son petit programme dans son coin sans s'informer sur l'existant dans votre domaine. Il ne faut pas exagérer non plus (ça se voit), cependant il n'est pas obligatoire d'avoir lu 100% des articles que l'on réfère: certains sont des papiers fondateurs, dont on a pris connaissance par d'autres sources (mais qu'il est honnête de citer), d'autres sont des livres de référence... De plus, surtout dans notre domaine et à notre époque, il ne faut pas hésiter à utiliser largement le web: faites des entrées @Misc avec le titre, l'auteur (ou l'institution) et l'URL de la page (e.g. dans le champ `note'). De même, pour tout document dont le contenu intégral, ou de la matière très proche, est disponible sur le web, n'hésitez surtout pas à ajouter l'URL à l'entrée Bibtex via le champs `note'.

Les résultats.

Prenez le temps de générer plusieurs images, en soignant le choix des paramètres, des points de vue, de la scène ! Vous venez de passer 6 mois à faire un gros programme; même s'il n'est pas parfait (on fait ce qu'on peut dans le temps imparti), globalement il marche, donc montrez ce dont il est capable ! Illustrez la richesse de l'espace explorable ! Servez-vous en si possible même pour illustrer les principes de votre méthode ! N'hésitez pas à mettre une image dès le début (réelle ou résultat), pour que l'on comprenne ce à quoi vous souhaitez parvenir.

Faites des benchs ! Vous n'êtes pas jugés sur votre aptitude à faire des programmes qui marchent, mais à faire de la recherche, et à tirer des conclusions !
-> votre modèle a des propriétés, il se confronte à des modèles concurrents: il faut argumenter, et pour cela chiffrer tout ça !
-> votre modèle est plus large que ce que vous avez implémenté; parlez de tout ce sur quoi vous avez réfléchi. Certaines performances ne sont pas mesurables faute d'implémentation, ou faute d'optimisations classiques mais longues à programmer: faites des extrapolations si vous voulez, mais donnez des mesures ! Ne vous cachez pas derrière des `ça dépend', `il est difficile de conclure': mouillez-vous ! qui d'autre que vous peut donner une opinion ?

Dans la rubrique `travaux futurs', vous indiquerez tout ce que vous n'avez pas eu le temps de faire (programme) ou de tester (modèle), ce qu'il faudrait étendre et comment, pour finir par quelques pistes sur le long terme, et la façon dont votre méthode (et ses prolongements éventuels) s'inscrit dans le contexte du domaine.

Du bon usage du français.

  • Relisez-vous, au strict minimum une fois, avant de laisser quiconque lire votre texte !
  • Essayez d'utiliser des termes français quand c'est possible (et que ça n'est pas ridicule). Ne vous privez pas de donner ensuite le terme courant (e.g. terme technique, terme anglais, sigle) entre parenthèses en italiques.
  • Écrivez i.e., et e.g., . Le mieux est encore d'introduire des macros: \newcommand{\ie}{/emph{i.e.,}~}    \newcommand{\eg}{/emph{e.g.,}~}
  • Attention aux é vs er, aux à vs a, aux pluriels, etc. Le correcteur ne voit pas ces erreurs là !
  • Attention aux accents, aux ç, aux oe. En iso, vous pouvez utiliser directement les accents sous Emacs, sans passer par les \'. (Attention à ce que toute la chaîne d'impression soit compatible !).
  • Attention aux guillemets ouvrants, différents des fermants.
  • `basé sur' est un anglicisme (d'accord, il devient difficilement contournable).
  • Pas de majuscule aux noms des mois en français (encore un anglicisme).

    Des sites pour vous aider:

  • Comment préparer et écrire un rapport
  • rapportdestage.com