É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