Détails
Catégorie : Stages
Affichages : 60870


Cet article donne les consignes essentielles afin de produire un rapport de stage (et projet tuteuré) en accord avec les attentes des enseignants. De part sa longueur conséquente, il est réparti par défaut sur plusieurs pages, accessibles via le tableau ci à droite.Si vous cliquez sur toutes les pages, vous aurez l'article présenté sur une seule et longue page.

Une version au format openoffice est téléchargeable ICI.

Introduction

Votre stage en entreprise va constituer, pour nombre d’entre vous, votre première expérience professionnelle en tant qu’informaticiens. Il représente un atout maître que vous saurez faire valoir auprès de votre futur employeur, et ce, dès l’envoi de vos premiers C.V.

Comme vous le savez, affecté d’un coefficient qui pèse lourd…, il fait l’objet d’un retour pédagogique conséquent sanctionné par un rapport et par une soutenance.

 

Le rapport de stage répond à une triple exigence :

  • Juger de votre capacité à rendre compte du travail accompli durant le stage. Il s’agit nullement d’un rapport d’activité. Votre tâche consiste à mettre en évidence une problématique permettant d’en cerner au mieux l’intérêt, les attentes, les enjeux.

  • Juger de votre capacité à proposer des solutions informatiques valides et à les exposer avec logique et clarté.

  • Juger de votre capacité à concevoir un document permettant à des utilisateurs d’exploiter au mieux votre réalisation et, si besoin, de la faire évoluer.

Cette triple exigence prend corps dans la rédaction de trois rapports :

  • LE RAPPORT GENERAL,

  • LE RAPPORT TECHNIQUE,

  • LE MANUEL DE L’UTILISATEUR.

Chacun devant être complet et concis. Ainsi, un rapport d'une dizaine de pages, ou à interlignes doubles, est à proscrire, quand à contrario une quarantaine de pages, des pages blanches, une police de taille 10, etc. ne paraissent pas raisonnables.

 

Ce document traite uniquement du rapport général. Pour le rapport technique et le manuel de l'utilisateur, se référer aux souhaits du responsable de stage.

I - Objectifs

Vous aurez à cœur de rendre votre rapport clair, lisible et attractif.

Clair : la clarté renvoie à la logique. C’est la qualité première d’un informaticien. On va pouvoir en juger dès la lecture de votre SOMMAIRE et de votre TABLE DES MATIERES. On va vérifier si la démarche que vous annoncez dès votre INTRODUCTION s’inscrit dans la suite de votre rapport. On prêtera une attention toute particulière à vos bilans et à votre conclusion. A tout moment, on s’attachera à la cohérence de vos propos.

Lisible : « Ce qui se conçoit clairement s’énonce clairement ». Vous veillerez à la correction orthographique et syntaxique de votre rapport. Vous choisirez le mot juste. Les termes spécialisés, les sigles, le « jargon maison », si vous ne pouvez en faire l’économie, seront définis dans un GLOSSAIRE.

Gardez à l'esprit que vous ne pouvez pas écrire de la même manière que vous vous exprimez dans la vie de tous les jours : un rapport de stage n'est pas la narration de quelconques aventures, mais un document sérieux correctement rédigé, dans un style simple évitant autant que faire se peut la première personne du singulier.

La lisibilité s’entend enfin à un autre niveau : votre rapport général devra pouvoir être lu, sans difficultés majeures, par un non informaticien. C’est là une exigence à laquelle vous serez souvent confrontés dans l’exercice de votre futur métier, où vous devrez être entendus aussi bien par des praticiens chevronnés que par des clients, simples utilisateurs de l’informatique.

Attractif : Si la fantaisie n’est guère de mise, vous ferez néanmoins en sorte que votre rapport soit facilement identifié, pourvu d’un titre porteur, à défaut d’un titre choc, et piloté par une quatrième de couverture pertinente qui donne envie de le lire. Enfin, la mise en page doit être simple et plaisante.

II - Structure

Si le corps principal du rapport constitue l'essentiel de votre rédaction, ce n'est pas cette partie qui sera lue en premier par les rapporteurs. Les parties « périphériques » sont donc essentielles pour donner les premières impressions quant à la cohérence et à l'esprit de synthèse dont vous aurez fait preuve.

 

II.1 - Les parties « périphériques »

Votre rapport devra obligatoirement inclure une page de couverture, une quatrième de couverture, des remerciements, un sommaire, une table des matières. A ces parties s'ajoutent éventuellement une table des illustrations (si le document contient des images), un glossaire, une bibliographie et des annexes.

- La couverture :

Vous y ferez figurer : votre nom et vos prénoms, le nom de l’entreprise ou de la société ou vous avez effectué votre stage, éventuellement le nom du service, les dates du stage, sans oublier l’année de référence, votre appartenance au département informatique de l’IUT de Belfort-Montbéliard et le titre de votre rapport.

Tout ouvrage digne de ce nom se doit d’avoir un titre. Un bon titre est bref et pertinent, c’est-à-dire en rapport étroit avec le contenu et l’esprit de l’ouvrage désigné. S’il est « parlant » et s’il n’est pas long, vous pourrez reprendre le libellé du sujet qui vous a été notifié. A défaut, vous en proposez une formulation condensée. En cas de sujets multiples, vous en retiendrez leur dénominateur commun.

 

- La quatrième de couverture :

Elle est de mise et vous accorderez un soin tout particulier à sa rédaction et à sa mise en page. Sorte de « bande annonce » elle informe tout autant qu’elle incite à la lecture. Elle peut résumer un sujet, une démarche, des enjeux, être constituée de mots-clés.

Dans certains cas, votre encadrant vous demandera de la rédiger en français ET en anglais.

 

- Les remerciements :

En ouverture du rapport, on les souhaite brefs et sincères.

 

- Le sommaire :

Situé à « l’entrée » du rapport, le sommaire en dégage les grandes masses dans leur économie respective (un sommaire n'est pas une table des matières.) Dans l’ordonnance de ces parties et à travers leur intitulé on pourra d’ores et déjà juger de votre rigueur en même temps que se dégagera une vue d’ensemble de votre travail.

 

- La table des matières :

Située à la « sortie » du rapport, la table des matières en restitue, dans toutes ses composantes, l’architecture. Vous n’oublierez pas la référence des pages pour chacune des parties et sous parties distinguées auxquelles vous aurez donné un titre adéquat.

 

- La table des illustrations :

Elle permet de retrouver rapidement un tableau, une figure, dans votre rapport. Rappelons que de tels documents contiennent un titre et un numéro, que le texte éventuellement présent dans l'image doit être clair, lisible, en rapport avec l'illustration, et pleinement renseigné (les axes éventuels doivent avoir un intitulé, les valeurs des unités, etc.)

 

- Glossaire :

Proposez une définition des sigles et du « langage maison », lorsque vous l'avez employé dans vos rapports. Définissez quelques mots clés propres aux champs informatiques considérés, en excluant toutefois tous les termes qu’un lecteur « cultivé » non informaticien se doit néanmoins de connaître…

 

- Bibliographie :

Fournissez des références complètes comprenant le site de l’ouvrage, l’auteur, l’éditeur, la date de publication, voire les pages consultées. Fournissez de même les références des principaux sites visités, avec un court descriptif adéquat.

 

- Les annexes :

Elles reprennent les documents qui surchargeraient le corps du rapport, mais qui cependant apportent quelque éclairage à votre travail. Veillez à n'y mettre que des documents utiles à la compréhension du déroulement de votre stage : cette section n'est pas un fourre-tout! N'oubliez pas de référencer et renseigner ces documents.

II.2 - Le corps du rapport

 

Ne perdez surtout pas de vue que votre rapport va être accompagné d’un rapport technique et d’un manuel de l’utilisateur. Dans ce rapport général il va donc avant tout s’agir d’insister sur la démarche que vous avez mise en œuvre pour traiter le sujet proposé et de mettre en valeur les solutions que vous avez retenues - le tout en réponse à une demande clairement identifiée. Vous aurez le souci de basculer en annexe nombre de documents qui risqueraient de surcharger votre rapport ou d’en contrarier la lecture. Ces annexes seront dûment annoncées, numérotées et répertoriées.

 

Le corps du rapport est obligatoirement constitué de 7 parties : une introduction, une présentation de l'entreprise, une présentation du sujet, un cahier des charges, une description de la mise en oeuvre, un bilan et une conclusion.

 

- L’introduction :

Elle pose le sujet, le définit, le délimite, en situe les enjeux et donc l’intérêt et donne un bref aperçu de la démarche mise en œuvre pour le traiter. Comment imaginer dans ces conditions qu’elle se trouve réduite à une demi-douzaine de lignes…

Pour autant elle ne saurait être confondue avec la présentation générale de l’entreprise ou son historique ainsi que se l’imaginent encore trop d’étudiants y voyant là un moyen commode de « rallonger la sauce » ! L’introduction complète, en premier lieu, les informations sur le sujet qui découleront du choix du titre, de la quatrième couverture, du sommaire et de la table des matières. Elle s’adresse aux lecteurs, et aux utilisateurs de votre rapport dont il faut retenir d’emblée toute l’attention.

Le premier point que vous devrez aborder est la présentation du contexte général du stage aussi bien du point de vue informatique que de l'entreprise. Les lecteurs sauront ainsi quels domaines informatiques ont été abordés lors du stage et dans quel type d'entreprise.

Vous répondrez ensuite aux questions : pourquoi l’entreprise vous a proposé ce sujet, quelles sont ses attentes, quels sont ses besoins et où sont les enjeux. Vous vous efforcerez notamment d'exposer brièvement la situation qui prévalait jusqu’alors. Vous vous demanderez si un projet de même nature avait déjà été tenté (ne rentrez pas dans les détails : le corps du rapport est là pour ça.) Dans l’affirmative, vous vous demanderez pourquoi il a échoué ou pourquoi il n’a pas abouti.

En troisième point, vous présenterez le sujet en quelques lignes afin de préciser le contenu du stage en terme d'informatique.

 

Afin de relier l'introduction à la suite, vous terminerez par l'énoncé en quelques mots des différentes parties du corps du rapport et ce qu'elles contiennent.

 

- Présentation de l'entreprise :

Pour mieux saisir et apprécier la nature de votre contribution, il est absolument indispensable que l’on connaisse un tant soit peu votre cadre de travail. Ne vous croyez pas pour autant tenu de reprendre la masse de documents que l’entreprise est susceptible de mettre à votre disposition. Songez aussi que s’agissant d’entreprises grandes pourvoyeuses de stages, ces documents figurent à l’identique dans de nombreux rapports au fil des années. Allez à l’essentiel en faisant un effort de synthèse et en vous efforçant d’actualiser les données et surtout en les référant au mieux à votre sujet….

S’il s’agit d’une jeune entreprise votre approche sera différente et vous pourrez donner quelques indications sur son montage juridico-financier, son créneau économique et ses perspectives de développement.

N'oubliez pas de vous situer, en quelques mots, au sein de l'entreprise d'accueil : dans quel service vous allez travailler, au contact de quelles personnes, etc.

 

- Présentation du sujet :

Cette partie est très souvent baclée, se résumant à quelques lignes reprenant le vague sujet donné par l'entreprise avant le début du stage. Pourtant, c'est une des parties fondamentale puisqu'elle constitue la base sur laquelle va se construire les parties suivantes. Sans une bonne présentation du sujet, le lecteur ne percevra pas l'intérêt du stage, sa qualité, ses enjeux, ses difficultés, ... De plus, le rapport n'aura pas de fil conducteur et se résumera à des parties collées les unes aux autres, sans réelle cohérence.

 

Le premier point que vous aborderez doit faire le lien avec la présentation de l'entreprise. Il faut montrer que le sujet en en relation directe avec des besoins ou des axes de développement de l'entreprise.

Ensuite, vous devrez aborder le contexte précis du sujet. Ce contexte repose sur un (in)existant qu'il convient d'améliorer et constitue souvent la raison pour laquelle le stage a été proposé. Vous vous efforcerez de présenter cet (in)existant avec suffisamment de détails pour que le lecteur puisse juger dans la suite du rapport l'importance de votre contribution.

Vous vous intéresserez ensuite aux problèmes et avantages liés à ce contexte. C'est la partie critique de l'existant qui doit montrer si vous avez conscience des enjeux de votre stage. Cette critique doit également aboutir à des conclusions qui motivent l'existence du stage et qui préfigurent le sujet.

Enfin, vous présenterez le sujet de manière détaillée et structurée afin d'établir un lien direct avec le cahier des charges. Cette partie constitue donc les solutions envisagées par l'entreprise afin de répondre aux besoins et/ou améliorer l'existant.

 

- Le cahier des charges :

Il constitue un descriptif fonctionnel précis, neutre et le plus exhaustif possible (sans aller jusqu'à l'indigeste), constitué de l'ensemble des composants/fonctionnalités qu'il vous a été demandé de développer, ou que votre analyse du problème implique de développer. Sa rédaction est un exercice de « prise de recul » qui doit montrer si vous arrivez à sortir du rôle de développeur informaticien. Vous devez avoir et présenter une vision globale de ce que vous faites, notamment en prenant la place de ceux qui expriment les besoins du stage, en synthétisant sous une forme fonctionnelle des lignes de code que vous avez tapé, le tout en français et dans un jargon informatique.

Vous veillerez à rédiger ce cahier au présent, sans employer la première personne du singulier, et sans utiliser de termes techniques, ni de références temporelles : tout ajout de fonctionnalités, à quelque moment que ce soit durant le stage, doit y figurer, indépendemment de ce que vous avez réalisé.

Vous pourrez, si votre sujet s'y prête, diviser le cahier des charges en deux, voire trois parties : « descriptif fonctionnel » (ou « descriptif procédural » si le stage se résume à un modèle relationnel), « contraintes techniques » (langage, matériel, logiciels imposés par l'entreprise) et « contraintes temporelles » (planning imposé par l'entreprise).

 

- La mise en oeuvre :

Vous devriez ici porter un regard critique tant sur le travail demandé, que sur votre capacité à le réaliser. Cette partie s'ouvre sur vos choix argumentés, concernant la gestion de votre emploi du temps, le langage de programmation, l'architecture, bref tout ce qui n'a pas été imposé par le cahier des charges. Vous avez ainsi l'occasion de renseigner le lecteur sur votre manière de procéder, de mettre en oeuvre (et/ou d'élaborer) le cahier des charges. Un lecteur devrait, après avoir parcouru votre partie « mise en oeuvre », être en mesure de décider, pour chaque point du cahier des charges, s'il a été réalisé ou pas et avec quel degré de qualité. Dans la négative, le lecteur doit également savoir pourquoi.

Lorsqu'une analyse a été réalisée, elle peut être succinctement exposée, avec intelligence, tout en ayant soin de ne pas rédiger un rapport technique. Vous pouvez également présenter vos travaux grâce à quelques copies d'écrans, judicieusement choisies, dans la mesure où leur absence nuirait à la compréhension de votre ouvrage. Ces illustrations doivent être obligatoirement numérotées, référencées et commentées dans le texte.

A charge pour vous de juger de l'intérêt de présenter les problèmes rencontrés, les solutions que vous avez pu éventuellement développer pour les contourner, voire les raisons pour lesquelles certains problèmes n'ont pu être résolus. Dans le même esprit critique, vous pouvez terminer sur des propositions pour améliorer le cahier des charges, le résultat et même vos méthodes de travail.

 

- Le bilan :

Contrairement à ce que pensent beaucoup d'étudiants, cette partie n'est pas une conclusion. Un bilan permet de comparer plusieurs choses entre elles, par exemple les recettes et les dépenses. Dans le cadre d'un stage, il sert à exposer les différences entre l'avant et l'après stage.

Le bilan s'articule autour de trois axes principaux : le bilan pour l'entreprise, le bilan humain, le bilan pédagogique.

 

Le bilan pour l'entreprise : votre programme est-il dès à présent utilisé par l'entreprise, cette dernière est-elle pleinement satisfaite de votre travail ? Envisage-t-elle de l'améliorer peu ou prou, de l'incorporer dans un plus vaste projet ? Ce bilan est là pour répondre à ce genre de questions.

 

Le bilan humain : vous n’aurez guère le temps de vous intéresser à ce qui a trait aux relations humaines au sein de l’entreprise. Mieux vaut donc ne rien en dire que de donner le change en signalant la présence à l’étage d’une machine à café ou en évoquant la célébration de quelque anniversaire, promotion ou départ en retraite.

Vous pourrez, par contre, procéder à une évaluation de votre stage en tant qu’expérience humaine. Vous aurez sans doute davantage à dire sur vos rapports professionnels avec les membres de votre équipe, vos responsables, les futurs utilisateurs de votre travail et a fortiori vos clients si vous avez travaillé pour une société de service.

 

Le bilan pédagogique : faites le point de vos acquis et des connaissances que vous aurez mises en œuvre dans la réalisation de votre sujet. Si vous avez utilisé d’autres outils ou d’autres méthodes qu’à l’IUT, précisez-le. Vous saurez faire le partage entre la pertinence et l’impertinence.

 

- La conclusion :

Tout aussi indispensable que l’introduction par laquelle vous avez soigné votre entrée, la conclusion vous donne l'occasion de soigner votre sortie ! Vous devez, dans votre rapport, et encore plus dans cette dernière partie, aller à l'essentiel, porter un regard critique, et savoir prendre du recul.

L'exercice consiste ici à résumer ces quelques semaines de stage, en reprenant les grandes lignes du rapport, et en rappelant dans quelle mesure cette expérience a été pour vous enrichissante, et conclut idéalement deux années passées à l'IUT. Reste à clore votre rapport par quelques mots, recadrant votre stage dans un contexte plus général, par exemple en présentant les évolutions possibles de votre produit ou de votre carrière.

III - Remarques et conseils

 

Cette section contient des remarques et des conseils sur le rapport, notamment concernant son fond. Dans la plupart des cas, ne pas suivre ces conseils implique une mauvaise note. Quelques exemples à suivre ou éviter, selon le cas, sont donnés pour que vous ne tombiez pas sur les écueils les plus courants.

 

- Syntaxe, orthographe et style

 

- Le style oral est à proscrire. Par exemple, « Quand tout à coup, il m'apparut que j'avais fait une grave erreur en... » tient du roman d'aventure ou des souvenirs de vacances.

- Les phrases sans verbe sont à proscrire.

- Les phrases trop longues sont à proscrire.

- Chaque paragraphe doit correspondre à une idée. Il doit donc avoir une longueur pertinente permettant de développer l'idée dans son intégralité.

- Un paragraphe peut parfois être découpé en sous-paragraphes, par exemple pour marquer des étapes clés dans le développement de l'idée, ou bien parce que l'idée repose sur plusieurs concepts qu'il convient de différencier.

- Les changements de couleurs et de police de caractères répétitifs sont à proscrire.

- Les polices exotiques sont souvent peu lisibles. La police Times est sans doute la plus lisible et ce n'est pas pour rien que c'est la plus utilisée.

- Utilisez les styles de caractères (gras, italique, ...) de façon cohérente. Par exemple, ce document utilise l'italique et le gras pour des cas bien précis.

- Pour résumer, la forme du rapport constitue ce qui va marquer en premier le lecteur. Si ce dernier bute sur des fautes, des polices illisibles, des paragraphes hachés, des pages blanches avec un gros titre au milieu, des couleurs partout, etc. (la liste est longue), il aura certainement un à priori négatif et s'intéressera d'autant moins au fond du rapport.

 

- Introduction

 

- On ne commence pas le rapport par une phrase du type : « Dans le cadre de ma deuxième année, j'ai effectué un stage ... ».

- On commence souvent un rapport par des généralités sur le domaine informatique et sur le contexte du sujet : « La gestion de ... est une clé essentielle du développement des PMEs dans le domaine de ... C'est pourquoi les besoins logiciels de telles entreprises sont souvent basés sur de petites applications du type base de données ... ».

 

- Présentation de l'entreprise

 

- Deux ou trois pages suffisent généralement pour cette partie.

- Evitez de reprendre des plaquettes d'entreprise et d'utiliser un style publicitaire. Vous devez montrer que vous avez une vision globale de l'entreprise et de votre place en son sein.

 

- Présentation du sujet

 

- Le problème d'un existant peut être son absence au niveau informatique : par exemple une gestion papier qui doit être informatisée.

- Pour les solutions proposées : n'entrez pas dans les détails fonctionnels, c'est le rôle du cahier des charges.

- S'il y a plusieurs sujets, présentez toujours une vision globale reliant tous les sujets. C'est particulièrement difficile quand les sujets sont vraiment éloignés les uns des autres. Dans ce cas, vous pouvez toujours vous appuyer sur le contexte ou les problèmes communs pour donner une unité. Par exemple, un stage dont les sujets sont « gestion d'un parc de véhicules en VB – Access » et « écriture de routines C pour l'extraction filtrée de données d'un AS 400 » semble n'avoir aucune unité. Cependant, il existe des problèmes communs à ces deux sujets : le traitement de données. De même, le contexte est commun puisque c'est le même service qui s'occupe de leur réalisation. Il suffit d'introduire le sujet sous ces deux angles et l'unité est trouvée.

 

- Cahier des charges

 

- Si cette partie est bien faite, on doit avoir l'impression que c'est votre encadrant dans l'entreprise qui l'a écrit avant le stage et qui vous l'a donné tel quel comme base de travail précise.

- Si des fonctionnalités ont été abandonnées au cours du stage, elles ne doivent pas apparaître dans le cahier des charges mais être mentionnées dans la partie mise en oeuvre si elles ont été abordées.

- Dans la plupart des stages, il y a deux parties : « descriptif fonctionnel » et « contraintes technique » et très rarement une partie « contraintes temporelles ».

- Certains stages n'ont pas de partie développement et uniquement une partie analyse destinée à produire un modèle relationnel, un cahier des charges, un planning etc. ( pour certains stages passés, le cahier des charges était de faire un cahier des charges pour une application future de l'entreprise). Dans ces cas, le descriptif fonctionnel est remplacé par un descriptif procédural indiquant les méthodes, les étapes à suivre et les objectifs à atteindre lors de l'analyse. Cela représente généralement un volume moins conséquent à écrire que dans le cas d'une application à développer, mais beaucoup plus dur à synthétiser.

 

Exemple sur un cas classique (pour une appli Web de vente) :

3°/ Cahier des charges.

...

3.1°/ Vente en ligne.

Cette partie concerne la gestion d'un panier d'achat pour l'utilisateur désirant acheter en ligne sur le site.
3.1.1°/ Apparence.

La fenêtre principale du navigateur est divisée en trois parties :
- en haut, un bandeau avec des images représentant les sections du catalogue,
- en bas-gauche, un menu contenant les catégories d'articles de la section demandée
- en bas-droite, la partie principale faisant apparaître les articles disponibles selon section/catégorie

3.1.2°/ Bandeau
Le bandeau doit faire apparaître les sections suivantes sous forme d'images :
- bricolage
- jardinage
- ...

3.1.3°/ Menu catégorie
Ce menu doit correspondre à la hiérarchie de catégories donnée en annexe X.X et être représenté à l'écran comme une liste extensible (comme l'explorateur windows).
Un clic sur une catégorie doit faire apparaître les sous catégories.
Pour les catégories n'ayant pas de sous-catégorie, le clic provoque l'apparition de la liste des articles disponibles dans la partie bas-droite de l'écran.
...

Exemple sur un cas d'analyse pure (analyse d'une application de gestion des services) :

3°/ Cahier des charges.

 

L'objectif de l'étude est de fournir plusieurs documents (planning, cahier des charges, etc. ) en vue de réaliser une application de gestion des services. Cette étude est découpée en trois phases essentielles sur lesquelles il convient d'itérer jusqu'à la validation finale du cahier des charges. Ces trois phases sont : l'expression des besoins, l'analyse, la production du cahier des charges.

 

3.1°/ Expression des besoins.

 

Les utilisateurs finaux de l'application doivent être interrogés sur :

- l'aspect global de l'application

- les informations essentielles à l'application.

- les fonctionnalités manipulant ces informations.

- les documents et leur apparence produits par l'application.

 

3.2°/ Analyse.

 

En fonction des besoins, on doit déterminer :

- les composants matériels et logiciels nécessaires à l'exécution de l'application.

- un modèle conceptuel des données reliant les données de l'application.

- un modèle relationnel

 

3.3°/ Production des documents.

 

En utilisant l'outil graphique XXX de gestion de projets, on doit produire :

- un planning de mise en oeuvre découpé en semaines.

- une évaluation des moyens humains nécessaires et les plaquer sur le planning.

- un découpage des tâches de développement en fonction des contraintes de dépendances entre les différentes fonctionnalités de l'application.

...

- Mise en oeuvre

 

- Pour la présentation des choix : si tel langage ou logiciel a été choisi (ou imposé), ne faites pas une description complète de ses possibilités mais essayez de montrer en quoi il est adapté à la mise en oeuvre du cahier des charges, et éventuellement ses inconvénients. La description précise doit éventuellement être faite en annexe ou bien dans un glossaire.

- Une copie d'écran est pertinente à partir du moment où son absence ne permet pas de justifier l'existence ou la qualité de la mise en oeuvre. Inclure une copie d'écran pour montrer que la charte graphique a été respectée est pertinent. Inclure une fenêtre de connexion avec pour commentaire « Sur la figure 2, on voit que l'utilisateur peut se connecter en utilisant un identifiant et un mot de passe », c'est complètement idiot.

- Le vocabulaire technique peut être utilisé à condition qu'il soit référencé dans un glossaire.

- Utiliser du technique ne veut pas dire parler « informaticien ». L'exemple ci-dessous n'est compréhensible que par un informaticien (et encore...). Ce style est donc proscrit.

« la partie vente (cf. section 4.1) a été réalisée grâce a trois frames en utilisant les feuilles de style CSS et la balise <div>. /.../ La frame bas-droite utilise les primitives mysql de php pour établir une connexion au serveur mysql et lancer une requete SQL en réalisant une jointure entre les tables x, y, et z. La liste obtenue est affichée sous forme d'état dans une table html dont la première colonne (le nom de l'article) est un lien cliquable qui permet d'ouvrir un pop-up contenant la photo de l'article ... »

- De façon similaire, n'incluez pas un MCD « brut de forge » ou bien du code. Dans le premier cas, focalisez-vous sur les parties cruciales et n'en présentez que des versions extrêmement simplifiées, commentées pour prouver que c'est la meilleure solution, la plus simple,... Dans le deuxième cas, si l'application dépend d'un algorithme crucial, il n'est pas nécessaire de le décrire sous forme de pseudo code. Le français littéral est suffisant pour donner une idée de son fonctionnement et pourquoi il convient.

- Il se peut que certaines fonctionnalités aient été abordées mais ne fassent pas partie du résultat (donc du cahier des charge). Si vous pouvez justifier cet abandon, parlez-en. Sinon, abstenez-vous.