Guide de Rédaction du Rapport du Stage de Perfectionnement

Ce guide s’adresse aux étudiants du département Technologies de l’Informatique qui doivent rédiger un rapport de stage de perfectionnement. Il présente une structure type et des recommandations précises pour chaque partie du rapport, depuis l’introduction jusqu’aux annexes, en insistant sur la clarté, la rigueur et la présentation professionnelle.

Présentation du cadre du stage

Ce chapitre comprend deux parties principales : la présentation de la société d’accueil et l’étude de l’existant.

Présentation de la société

Il s’agit de décrire brièvement la société où le stage s’est déroulé, en précisant son domaine d’activité, son organisation, et surtout son aspect informatique (activités liées à l’informatique, parc informatique). Il faut également indiquer le département où s’est effectué le stage en précisant sa vocation (développement, maintenance, etc.).

Attention : cette présentation ne doit pas être une publicité pour la société, mais une description objective.

Étude de l’existant

Cette partie se divise en trois sous-parties :

• Description de l’existant : expliquer comment le travail est actuellement effectué dans la société, en lien avec l’application à développer.
• Critique de l’existant : souligner les points forts et faibles de la solution actuelle, en insistant sur ses lacunes et insuffisances.
• Solution proposée : présenter brièvement la ou les solutions envisagées pour améliorer ou remplacer l’existant, en indiquant avantages et inconvénients, puis justifier le choix retenu.

Remarque : l’étude de l’existant peut constituer un chapitre indépendant.

Notions théoriques

Ce chapitre est facultatif et ne s’intègre que si le sujet du stage nécessite des notions peu communes ou non encore étudiées, mais indispensables à la compréhension du projet.

Spécification des besoins

Ce chapitre détaille ce que l’application doit faire, en précisant clairement les fonctionnalités attendues.

Besoins fonctionnels

Ce sont les besoins indispensables auxquels l’application doit répondre. Il est conseillé de les présenter sous forme de WBS (Work Breakdown Structure), c’est-à-dire en listant les besoins globaux puis leurs sous-besoins. Par exemple :

1. Besoin global 1
  1.1. Sous-besoin 1
  1.2. Sous-besoin 2
2. Besoin global 2
  2.1. Sous-besoin 1
  2.2. Sous-besoin 2

Besoins non fonctionnels

Ces besoins améliorent la qualité de service de l’application, comme la convivialité, l’ergonomie, ou le temps de réponse. Ils peuvent être présentés sous forme de listes à puces.

Diagrammes de cas d’utilisation

Présentation des acteurs

Cette section présente brièvement les différents acteurs qui interagissent avec l’application.

Description des cas d’utilisation

Les cas d’utilisation peuvent être présentés par acteur ou par fonctionnalité, selon que les fonctions sont indépendantes ou partagées entre plusieurs acteurs.

Chaque cas d’utilisation ambigu doit être complété par une description textuelle comprenant :

• Objectif : but du cas d’utilisation.
• Pré-condition(s) : conditions nécessaires pour exécuter le cas.
• Enchaînement nominal : scénario principal sans alternatives, pouvant être remplacé par un diagramme de séquence.
• Post-condition(s) : conditions pour considérer le cas comme achevé.

Il est possible d’ajouter des informations sur les acteurs primaires et secondaires selon le cas.

Conception

Ce chapitre décrit la solution conceptuelle proposée, répondant à la question « COMMENT FAIRE ». La conception est illustrée par des diagrammes issus soit de la méthode MERISE, soit du langage UML.

Conception de la base de données selon MERISE

La conception comprend plusieurs étapes :

Dictionnaire de données

Inventaire des attributs de la base de données, précisant leur désignation, type et signification, classés par entités.

Modèle conceptuel de données (MCD)

Le diagramme du MCD est placé ici. Il doit être réalisé avec un outil de conception (ex. POWER AMC). En cas de diagramme volumineux, il peut être décomposé ou limité à la partie principale, le reste étant en annexes.

Schéma relationnel de données

Liste des relations déduites du MCD, avec les clés primaires et étrangères mises en évidence. En cas de modèle imposant, seules 3 ou 4 relations sont présentées, le reste en annexes.

Conception de la base de données selon UML

Description des classes

Présentation et description brève des différentes classes, ou des principales si elles sont nombreuses.

Diagramme de classes

Le diagramme est placé ici, éventuellement accompagné de la description des classes. Les mêmes remarques que pour le MCD s’appliquent en cas de diagramme volumineux.

Modèle relationnel

Traduction du diagramme de classes en modèle relationnel, montrant la transformation des classes et associations en tables. Seules quelques relations sont présentées si le modèle est volumineux.

Conception des traitements

Les traitements effectués par l’application sont modélisés selon la méthode choisie :

• Avec MERISE : Modèle Conceptuel de Traitements (MCT).
• Avec UML : diagrammes de séquence détaillés ou diagrammes d’activités.

Il faut sélectionner les traitements les plus importants. Chaque diagramme doit être accompagné d’une explication textuelle concise.

Réalisation

Ce chapitre présente le produit fini développé par l’étudiant, généralement en deux parties :

Environnement de développement

Environnement matériel

Description des caractéristiques matérielles utilisées pour le développement (processeur, mémoire, équipements réseau, serveurs, etc.).

Environnement logiciel

Liste des outils logiciels utilisés pour le développement, la modélisation, la gestion de base de données, etc.

Principales interfaces graphiques

Présentation des interfaces graphiques principales développées, accompagnée d’un court paragraphe explicatif (2 à 3 lignes). Seules les interfaces les plus importantes ou différentes sont présentées ici, les autres étant en annexes.

Conclusion générale

La conclusion rappelle l’objectif du stage et récapitule le travail réalisé en présentant les résultats obtenus, c’est-à-dire les réponses aux problèmes posés. Elle doit aussi comporter un regard critique sur le travail, en soulignant les insuffisances ou pistes d’amélioration.

La conclusion est rédigée en un paragraphe d’une page environ, sans liste à puces.

Bibliographie et Nétographie

Cette partie regroupe les références documentaires utilisées :

Bibliographie

Liste des ouvrages, articles, revues consultés, classés soit par ordre alphabétique d’auteur, soit par ordre d’apparition dans le rapport. Exemple de référence :

[1] REEVES, Hubert. « Bases de données relationnelles », Paris, Editions du seuil, 1988, 288p.

Nétographie

Liste des sites web consultés, avec une brève description du contenu (1 ou 2 lignes). Exemple :

[2] http://www.asp.net/ : Fondements du langage ASP.NET.

Ne doivent pas être mentionnés les moteurs de recherche ni les cours étudiés à l’ISET.

Il est impératif de référencer ces sources dans le rapport.

Annexes

Les annexes sont facultatives et contiennent des documents complémentaires non indispensables à la compréhension, mais utiles :

• Explications plus détaillées sur le projet ou l’environnement de développement.
• Documents fournis par la société d’accueil (fiches, formulaires).
• Interfaces graphiques non présentées dans le corps du rapport.
• Diagrammes supplémentaires.
• Extraits de code source illustrant des points particuliers.

Propositions de mise en forme

• Titres et sous-titres : précéder le titre du chapitre par son numéro (ex. Chapitre 1 : …), même niveau vertical, différenciation par taille de police, pas de « : » en fin de titre, pas de soulignement ni italique, ne jamais placer un titre en fin de page.
• Corps du texte : texte justifié, interligne 1.5, police Times New Roman 12 pts.
• Puces : uniformes dans tout le rapport, même retrait, chaque puce se termine par une virgule sauf la dernière qui se termine par un point.
• Entête et pied de page : entête avec titre du chapitre courant et ligne séparatrice, pied de page avec numéro de page, titre du projet, et ligne séparatrice. Ne pas mentionner le nom de l’étudiant ou de la société.
• Marges : 2.5 cm sur tous les côtés.
• Couleurs : à éviter sauf nécessité (ex. interfaces).
• Numérotation des pages : commence à l’introduction, annexes peuvent avoir une numérotation différente.

Diverses recommandations

• Les annexes peuvent contenir des compléments intéressants, notamment des interfaces ou du code source.
• Le temps verbal à utiliser dans le rapport est impérativement le présent.
• Il est préférable d’utiliser l’impersonnel ou le pronom « nous » même si le stage est individuel.
• Les chapitres doivent être équilibrés en longueur, avec un nombre de pages approximativement similaire.
• La longueur totale du rapport (de l’introduction à la conclusion) ne doit pas dépasser 30 pages, idéalement entre 15 et 30 pages, privilégiant la qualité à la quantité.

Glossaire des termes clés

• Application : logiciel ou programme développé durant le stage.
• Besoins fonctionnels : fonctionnalités indispensables que doit assurer l’application.
• Besoins non fonctionnels : critères de qualité améliorant l’application (ergonomie, performance).
• Diagramme de cas d’utilisation : représentation graphique des interactions entre acteurs et système.
• MERISE : méthode de modélisation utilisée pour la conception des bases de données et des traitements.
• MCD (Modèle Conceptuel de Données) : diagramme représentant les entités et leurs relations dans la base de données.
• MPD (Modèle Physique de Données) : représentation physique de la base de données.
• MLD (Modèle Logique de Données) : traduction du MCD en modèle relationnel.
• UML : langage de modélisation orienté objet utilisé pour la conception logicielle.
• Diagramme de classes : diagramme UML représentant les classes et leurs relations.
• Modèle relationnel : représentation des données sous forme de tables relationnelles.
• MCT (Modèle Conceptuel de Traitements) : modélisation des traitements selon MERISE.
• Diagramme de séquence : diagramme UML illustrant l’enchaînement des interactions pour un cas d’utilisation.
• Diagramme d’activités : diagramme UML représentant le flux des activités dans un traitement.
• WBS (Work Breakdown Structure) : structure hiérarchique décomposant les besoins ou tâches.

Points clés à retenir

• Le rapport doit suivre une structure claire, avec une introduction, un développement en chapitres équilibrés, et une conclusion.
• La présentation doit être professionnelle, avec une mise en forme soignée et homogène.
• La description de la société doit être objective, sans faire de publicité.
• La spécification des besoins doit être précise, distinguant besoins fonctionnels et non fonctionnels.
• La conception doit être illustrée par des diagrammes adaptés à la méthode choisie (MERISE ou UML), accompagnés d’explications.
• La réalisation décrit l’environnement matériel et logiciel ainsi que les interfaces principales.
• La conclusion synthétise les résultats et propose une auto-évaluation critique.
• La bibliographie et la nétographie doivent être rigoureusement référencées.
• Les annexes complètent le rapport sans alourdir la lecture principale.
• Le rapport doit être rédigé au présent et privilégier la qualité à la quantité.