Votre encadrant vous a dit « ton mémoire sera surtout technique », mais votre camarade de promotion prépare une évaluation utilisateur avec des tests statistiques — et vous ne savez plus lequel des deux formats votre propre projet doit suivre. En informatique, le mémoire ne prend pas une forme unique : le PFE (projet de fin d’études), le mémoire d’ingénieur et le mémoire de master recherche répondent à des logiques différentes, avec des attentes de jury qui n’ont presque rien en commun. Ce guide compare les deux grandes familles pour vous aider à cadrer le vôtre dès le départ, avant même de trancher entre méthode qualitative et méthode quantitative pour la partie évaluation.
Deux familles bien distinctes de mémoires en informatique
| Mémoire de projet logiciel | Mémoire de recherche empirique | |
|---|---|---|
| Objectif | Concevoir, développer et déployer un système fonctionnel répondant à un besoin identifié | Répondre à une question de recherche par une méthode reproductible (expérimentation, étude comparative, enquête) |
| Livrable central | Le code, l’architecture, la documentation technique et une démonstration fonctionnelle | Les résultats d’une évaluation formalisée (benchmark, étude utilisateur, analyse statistique) |
| Chapitre méthode | Choix d’architecture, technologies retenues, méthodologie de développement (agile, itératif), tests réalisés | Design expérimental, population/échantillon, variables mesurées, protocole d’évaluation |
| Format typique | PFE d’école d’ingénieurs, mémoire de master professionnel, projet de fin d’année de licence pro | Mémoire de master recherche, première étape avant une thèse de doctorat |
Aucun des deux formats n’est plus légitime que l’autre : un jury de PFE et un jury de master recherche n’évaluent tout simplement pas les mêmes critères de réussite. Le problème survient quand un mémoire mélange les deux registres sans le choisir explicitement — un projet logiciel abouti mais présenté comme s’il répondait à une hypothèse scientifique testée, ou une étude empirique dont le protocole reste flou parce que l’accent a été mis sur le développement d’un prototype accessoire.
La composition du jury diffère elle aussi selon le format, et cette différence explique une partie des attentes. Un jury de PFE en école d’ingénieurs associe généralement un enseignant-chercheur à un professionnel du secteur — parfois votre tuteur d’entreprise lui-même — dont les questions porteront davantage sur la pertinence industrielle et la robustesse technique des choix effectués. Un jury de master recherche est composé d’enseignants-chercheurs qui interrogeront en priorité la validité du protocole, la maîtrise de la littérature scientifique du domaine et la portée généralisable des résultats obtenus. Se préparer à la soutenance sans avoir identifié à l’avance ce profil de jury conduit souvent à répondre à côté des questions posées, même quand le fond du travail est solide.
Le mémoire de projet logiciel : ce que le jury évalue vraiment
Dans un PFE ou un mémoire de développement, le code et le système livré constituent le cœur de l’évaluation, mais le mémoire écrit ne doit surtout pas se limiter à une description technique linéaire. Les jurys attendent en particulier :
- Un cahier des charges clair, avec les besoins fonctionnels et non fonctionnels identifiés avant le développement, pas reconstitués a posteriori pour justifier ce qui a été fait.
- La justification des choix d’architecture : pourquoi ce framework, cette base de données, ce patron de conception plutôt qu’une alternative sérieusement envisagée — un jury pénalise systématiquement un choix technique non discuté.
- Une stratégie de test documentée : tests unitaires, tests d’intégration, éventuellement tests de charge, avec les résultats rapportés plutôt qu’une simple mention « le système fonctionne ».
- Une évaluation du système livré, même sommaire : performance mesurée, retour d’utilisateurs pilotes, comparaison avec l’existant que le projet remplace. C’est souvent le maillon faible des mémoires de projet, qui s’arrêtent à la livraison sans jamais évaluer si l’objectif initial est atteint.
Une erreur fréquente consiste à rédiger un mémoire de projet logiciel comme un manuel utilisateur ou une documentation technique interne, sans jamais prendre de recul analytique sur les choix effectués. Le mémoire doit démontrer une réflexion d’ingénierie, pas seulement décrire un résultat.
Le mémoire de recherche empirique : la rigueur du protocole avant le code
À l’inverse, un mémoire de recherche empirique en informatique — évaluation d’un algorithme, étude comparative de performances, expérimentation utilisateur sur une interface — s’évalue sur la rigueur de son protocole avant même la qualité du code produit. Le chapitre méthode doit préciser :
- La question de recherche précise et l’hypothèse testée, formulée avant l’expérimentation.
- Le protocole expérimental complet : jeux de données utilisés, métriques d’évaluation retenues et pourquoi, conditions de comparaison équitable entre les approches testées.
- Les outils statistiques mobilisés pour interpréter les résultats (tests de significativité sur des benchmarks répétés, intervalles de confiance sur des mesures de performance) — un simple tableau de chiffres sans test de significativité n’établit rien de généralisable.
- La reproductibilité : code, données et paramètres expérimentaux documentés de façon à ce qu’un tiers puisse reproduire vos résultats, une exigence de plus en plus vérifiée par les jurys de master recherche en informatique.
Le code produit dans ce format reste un outil au service de la démonstration scientifique, pas une fin en soi — un jury de recherche n’évalue pas la qualité du code de la même façon qu’un jury de PFE évalue une application de production.
Le format hybride : le projet comme terrain d’une question de recherche
Une troisième voie, de plus en plus fréquente, consiste à développer un système ET à l’évaluer selon un protocole rigoureux — typiquement un outil prototype testé auprès d’utilisateurs réels avec une méthode d’évaluation formalisée (questionnaire de charge cognitive, mesure de temps de tâche, comparaison A/B). Ce format exige une double compétence : ingénierie logicielle et méthodologie de recherche, ce qui en fait souvent le format le plus long à mener à bien dans le temps imparti à un mémoire de master. Si vous optez pour ce format, calibrez le périmètre du développement pour qu’il reste un moyen au service de l’évaluation, et non l’inverse — un prototype trop ambitieux laisse rarement le temps de conduire une évaluation sérieuse avant la date de dépôt.
Construire le protocole d’évaluation, quel que soit le format retenu
Que votre mémoire soit un projet logiciel avec évaluation finale ou une recherche empirique à part entière, la construction du protocole suit une logique commune que beaucoup d’étudiants en informatique découvrent tardivement, faute d’y avoir été formés en dehors des cours de méthodologie des sciences humaines. La démarche pas à pas — poser la question évaluée, choisir les métriques, définir les conditions de comparaison, anticiper les biais de mesure — est détaillée dans ce guide sur la construction d’un protocole de recherche, transposable à l’évaluation d’un système informatique en remplaçant les instruments de mesure des sciences sociales par des métriques techniques (temps de réponse, taux d’erreur, score de satisfaction utilisateur).
Si votre évaluation repose sur des données réelles — logs d’usage du prototype, retours d’utilisateurs identifiés — les mêmes exigences de conformité RGPD s’appliquent que pour tout autre jeu de données de mémoire, avec les techniques d’anonymisation propres à l’informatique détaillées dans ce guide sur le RGPD et l’anonymisation d’un jeu de données réel.
Comment choisir : ce qui doit trancher votre décision
Le choix du format ne doit pas dépendre de vos préférences personnelles mais de trois éléments objectifs : le type de master ou d’école préparé (professionnel vs recherche), les attentes explicites de votre encadrant et du référentiel de votre formation, et le contexte de stage éventuel (une entreprise attend généralement un livrable fonctionnel, un laboratoire de recherche attend une contribution scientifique). Clarifiez ce point avec votre encadrant avant de rédiger le premier chapitre : un mémoire qui change de registre à mi-parcours — commencé comme un projet logiciel puis reformulé en urgence comme une étude empirique pour « faire plus scientifique » — est immédiatement identifiable par un jury et pénalise la cohérence globale du travail.
Deux sujets voisins, deux formats radicalement différents
Pour rendre la distinction concrète, comparons deux formulations de sujet portant sur le même domaine applicatif :
| Formulation | Format induit | Ce que le mémoire doit produire |
|---|---|---|
| « Concevoir et développer une application de gestion des rendez-vous pour un cabinet médical » | Projet logiciel | Cahier des charges, architecture, code livré, tests, documentation utilisateur, retour du cabinet pilote |
| « Dans quelle mesure l’autocomplétion des créneaux réduit-elle le temps de saisie d’un rendez-vous pour le personnel d’accueil ? » | Recherche empirique | Protocole d’expérimentation contrôlée, mesure du temps de tâche avec et sans autocomplétion, test statistique de la différence observée, discussion de la validité externe |
Le premier sujet peut très bien intégrer une fonctionnalité d’autocomplétion sans jamais en évaluer l’effet formellement — ce serait alors un simple choix de conception parmi d’autres, justifié mais non testé. Le second sujet, à l’inverse, pourrait très bien s’appuyer sur un prototype minimal ne comportant que la fonctionnalité testée, sans jamais devenir une application de gestion complète. Confondre les deux logiques — développer l’application complète du premier sujet tout en prétendant répondre scientifiquement à la question du second — est la source la plus fréquente de mémoires jugés « ni tout à fait un projet, ni tout à fait une recherche » par les jurys.
Une terminologie qui varie selon l’établissement
Le vocabulaire employé pour désigner ces formats varie sensiblement d’un établissement à l’autre : PFE (projet de fin d’études) dans la plupart des écoles d’ingénieurs, mémoire de master professionnel ou master recherche à l’université, TFE (travail de fin d’études) dans certains cursus, ou encore mémoire de M2 dans les parcours combinant enseignement et recherche. Ne vous fiez pas uniquement à l’intitulé officiel de votre formation pour déduire le format attendu : le référentiel de compétences de votre diplôme et les consignes explicites de votre encadrant priment toujours sur l’étiquette administrative du mémoire.
Questions fréquentes
Un PFE d’école d’ingénieurs doit-il obligatoirement contenir une évaluation statistique ?
Non. Un PFE orienté projet logiciel s’évalue sur la qualité de l’ingénierie (architecture, tests, livrable fonctionnel) et non sur une démonstration statistique. Une évaluation quantitative simple (performance, retours utilisateurs) reste toutefois attendue pour montrer que l’objectif initial a été atteint.
Peut-on changer de format de mémoire en cours de projet ?
C’est possible mais risqué passé le premier tiers du calendrier. Un changement tardif de projet logiciel vers recherche empirique impose de reconstruire un protocole d’évaluation rigoureux dans un temps réduit. Discutez-en avec votre encadrant dès les premiers signaux de doute, plutôt qu’au moment de la rédaction finale.
Le format hybride est-il recommandé pour un mémoire de master 1 ?
Il est généralement plus prudent de le réserver au master 2, où le temps disponible et la maturité méthodologique permettent de mener de front le développement et une évaluation rigoureuse. En M1, un format simple et bien exécuté vaut mieux qu’un format hybride ambitieux mais bâclé sur l’un des deux volets.
Le dépôt Git du code compte-t-il dans l’évaluation du mémoire ?
Dans un mémoire de projet logiciel, oui : l’historique des commits, la structuration des branches et la qualité de la documentation du dépôt font souvent partie des éléments consultés par le jury, en complément du mémoire écrit. Dans un mémoire de recherche empirique, le dépôt sert surtout à garantir la reproductibilité des résultats plutôt qu’à démontrer une pratique d’ingénierie logicielle complète.
Structurez votre mémoire d’informatique avec Tesify
Tesify aide à cadrer un mémoire d’informatique quel que soit son format — projet logiciel, recherche empirique ou hybride — et à rédiger un chapitre méthode conforme aux attentes du jury.