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.