Trouver un exemple complet de mémoire en informatique reste difficile : la plupart des modèles disponibles en ligne viennent de disciplines très différentes, où ni la structure ni les critères de qualité ne coïncident avec ceux attendus d’un travail de conception ou d’évaluation technique. Ce billet comble cette lacune avec un modèle commenté, chapitre par chapitre, construit sur un exemple fil rouge suffisamment concret pour être transposé à d’autres sujets.
L’exemple retenu porte sur l’analyse de sécurité d’une application web pour une PME — un sujet représentatif des mémoires en informatique qui combinent conception technique et évaluation rigoureuse, sans nécessiter un accès à des données sensibles impossibles à obtenir pour un travail de bachelor.
Le sujet fil rouge de ce modèle
Le sujet retenu pour illustrer chaque chapitre : « Analyse de sécurité et remédiation d’une application web de gestion de rendez-vous pour une PME suisse romande ». Ce sujet est représentatif parce qu’il combine une phase d’évaluation méthodique (identifier les vulnérabilités selon un cadre reconnu) et une phase de conception (proposer et justifier des correctifs), ce qui permet d’illustrer à la fois la rigueur méthodologique attendue et la dimension pratique propre aux mémoires en informatique.
Chapitre 1 : Introduction et problématique
L’introduction situe le contexte — une PME dont l’application web de gestion de rendez-vous n’a jamais fait l’objet d’un audit de sécurité formel — et formule la problématique : quelles vulnérabilités présente l’application selon un référentiel reconnu, et quelles corrections priorisées peuvent être proposées compte tenu des ressources limitées d’une PME ? Comment construire une problématique suffisamment précise pour porter tout le mémoire est détaillé dans l’article pour formuler la problématique de son mémoire. L’introduction se termine par l’annonce du plan, dans l’ordre où les chapitres seront effectivement présentés.
Chapitre 2 : État de l’art
Ce chapitre couvre trois axes : les référentiels de vulnérabilités reconnus (l’OWASP Top 10 pour les applications web), les méthodologies d’audit existantes (tests manuels, outils automatisés, tests d’intrusion encadrés), et les contraintes propres aux PME suisses en matière de cybersécurité — budget limité, absence fréquente d’équipe informatique dédiée. Chaque concept mobilisé ici doit réapparaître dans l’analyse ultérieure ; un chapitre théorique qui présente des concepts jamais réutilisés ensuite est l’un des défauts de plan les plus fréquents, comme le rappelle l’article sur le plan d’un mémoire.
Chapitre 3 : Méthodologie
Le chapitre méthodologie décrit précisément : le périmètre de l’audit (quelles fonctionnalités de l’application sont testées, lesquelles sont explicitement exclues), l’autorisation écrite obtenue de l’entreprise partenaire avant tout test, les outils utilisés avec leur version, et les critères de priorisation des vulnérabilités identifiées (par exemple une combinaison de sévérité technique et de facilité d’exploitation). Sans cette autorisation écrite documentée, aucun test de sécurité ne doit être entrepris — ce point mérite d’être mentionné explicitement dans le chapitre, pas seulement pratiqué en coulisses. Le chapitre précise également l’environnement de test utilisé : idéalement une copie de l’application isolée de la production, pour éviter tout risque d’interruption de service pendant les tests.
Chapitre 4 : Réalisation
Ce chapitre documente le déroulement effectif de l’audit : les vulnérabilités identifiées, classées selon le référentiel choisi, avec pour chacune une preuve reproductible (capture d’écran anonymisée, extrait de requête) et une évaluation de sévérité. Pour chaque vulnérabilité significative, une proposition de correction est formulée et justifiée techniquement. Ce chapitre est le plus long du mémoire et celui où la rigueur de documentation compte le plus : une vulnérabilité mentionnée sans preuve reproductible n’a pas la même valeur qu’une vulnérabilité démontrée.
Exemple : un extrait du tableau de vulnérabilités
| Vulnérabilité | Catégorie OWASP | Sévérité | Correctif proposé |
|---|---|---|---|
| Injection SQL dans le formulaire de recherche de rendez-vous | Injection | Critique | Requêtes préparées à la place de la concaténation de chaînes |
| Absence de limitation de tentatives de connexion | Défauts d’authentification | Élevée | Verrouillage temporaire après cinq tentatives échouées |
| En-têtes de sécurité HTTP manquants | Mauvaise configuration de sécurité | Moyenne | Ajout des en-têtes Content-Security-Policy et X-Frame-Options |
Ce format tabulaire, complété dans le mémoire réel par la preuve reproductible pour chaque ligne, permet une lecture rapide en chapitre 5 sans devoir reparcourir l’ensemble des détails techniques du chapitre 4.
Chapitre 5 : Évaluation des résultats
Ce chapitre présente les résultats sans encore les interpréter : le nombre de vulnérabilités identifiées par catégorie de sévérité, la répartition selon le référentiel utilisé, et une comparaison entre la situation avant et après application des correctifs proposés lorsque cela est possible dans le cadre du mémoire. La distinction entre présentation neutre des résultats et interprétation qui suit est un principe transversal à toute structure IMRaD, mais reste pertinente même dans un plan par étapes : mélanger résultat et interprétation dans le même paragraphe affaiblit la lisibilité du chapitre.
Chapitre 6 : Discussion et recommandations
La discussion confronte les résultats à l’état de l’art présenté au chapitre 2 : le profil de vulnérabilités trouvé correspond-il à ce que la littérature décrit comme typique pour ce genre d’application ? Les recommandations, clairement distinguées de la discussion scientifique, s’adressent à un destinataire précis — ici la direction de la PME — et sont proportionnées aux ressources réellement disponibles : une recommandation de recruter une équipe de sécurité dédiée n’a pas de sens pour une entreprise de cinq personnes, alors qu’une checklist de correctifs priorisés en a un.
Rapport de projet ou mémoire ? La ligne de partage
Le piège le plus fréquent dans les mémoires informatiques à forte composante pratique est de glisser vers le rapport de projet : une description chronologique de ce qui a été fait, sans justification méthodologique explicite. La différence tient dans le chapitre 3 : un rapport de projet décrit les outils utilisés, un mémoire justifie pourquoi ce référentiel de vulnérabilités et pas un autre, pourquoi cette méthode d’audit et pas une alternative, quelles limites ce choix implique. Cette même exigence de justification distingue plus largement, selon le niveau d’études visé, ce qu’on attend d’un travail de bachelor et d’un travail de master, comme le détaille l’article sur mémoire de bachelor HES ou mémoire de master universitaire.
Transposer ce modèle à d’autres sujets informatiques
La structure en six chapitres présentée ici pour un audit de sécurité se transpose directement à d’autres types de mémoires informatiques. Pour un projet de développement logiciel, le chapitre 2 devient une revue des technologies et architectures candidates, le chapitre 4 documente l’implémentation avec ses choix d’architecture justifiés, et le chapitre 5 évalue la solution contre des critères de performance ou d’utilisabilité définis en amont. Pour un mémoire comparant deux technologies — deux frameworks, deux bases de données, deux architectures cloud —, la structure IMRaD classique convient généralement mieux, avec les résultats de la comparaison présentés au chapitre résultats et leur interprétation dans la discussion. Le choix entre ces deux structures dépend avant tout de la nature du travail : conception et évaluation d’un artefact concret pour le plan par étapes, test d’une hypothèse comparative pour IMRaD.
Erreurs fréquentes
| Erreur | Conséquence |
|---|---|
| Tests de sécurité menés sans autorisation écrite documentée | Problème éthique et juridique grave |
| Vulnérabilité mentionnée sans preuve reproductible | Résultat non vérifiable par le jury |
| Résultats et interprétation mélangés dans le même paragraphe | Lisibilité affaiblie, structure confuse |
| Recommandations disproportionnées aux ressources réelles de l’entreprise | Recommandations jugées peu réalistes |
Questions fréquentes
Un mémoire en informatique suit-il toujours un plan par étapes ?
Pas toujours. Un mémoire comparant deux technologies ou évaluant une hypothèse précise peut suivre une structure IMRaD classique. Le plan par étapes convient particulièrement aux mémoires de conception ou d’audit, comme l’exemple présenté ici.
Comment éviter que mon mémoire ressemble à un rapport de projet ?
En justifiant chaque choix méthodologique par un critère explicite plutôt qu’en décrivant simplement ce qui a été fait. Le chapitre méthodologie est celui où cette différence se joue le plus nettement.
Faut-il une autorisation pour un audit de sécurité dans le cadre d’un mémoire ?
Oui, systématiquement, sous forme écrite et documentée avant tout test, définissant précisément le périmètre autorisé. Cette autorisation doit être mentionnée dans le chapitre méthodologie.
Ce modèle s’applique-t-il à un mémoire de développement logiciel plutôt que de sécurité ?
Oui, la structure en six chapitres se transpose directement : l’état de l’art couvre les technologies et approches existantes, la réalisation documente le développement effectué, et l’évaluation mesure la solution contre des critères définis au préalable.
Faut-il utiliser IMRaD ou le plan par étapes pour un mémoire comparant deux technologies ?
IMRaD convient généralement mieux, parce qu’une comparaison teste une hypothèse et produit des résultats mesurables à confronter ensuite. Le plan par étapes est plus adapté à un travail de conception ou d’évaluation d’un artefact concret comme dans l’exemple présenté.
Un mémoire en informatique convaincant ne se distingue pas par la sophistication technique de sa réalisation, mais par la rigueur avec laquelle chaque choix méthodologique est justifié et chaque résultat documenté de façon reproductible — c’est cette exigence, transposable à n’importe quel sujet technique, que ce modèle chapitre par chapitre cherche à illustrer.
Sujet technique choisi, structure à construire ? Tesify vous aide à organiser votre mémoire chapitre par chapitre.