Un mémoire d’informatique qui livre un système fonctionnel n’est pas automatiquement un mémoire réussi. Des jurys refusent ou ajournent des mémoires d’informatique qui présentent pourtant du code qui tourne, une application qui se lance, un prototype qui fait une démonstration correcte — parce que la discipline informatique a ses propres motifs de rejet, distincts de ceux des sciences humaines, et souvent mal anticipés par les étudiants dont l’essentiel du travail s’est concentré sur le développement. Ce guide détaille les motifs de rejet propres à un mémoire d’informatique : ce que les jurys sanctionnent réellement, au-delà du seul fonctionnement du système livré.
Ce que le jury évalue au-delà du fait que « ça marche »
Le réflexe d’un étudiant en informatique confronté à une difficulté de rédaction est souvent de se rassurer avec l’argument technique : le système fonctionne, la démonstration a été concluante, le tuteur d’entreprise est satisfait. Cet argument ne suffit pas à un jury de mémoire, qui évalue un travail intellectuel documenté et défendu, pas seulement un livrable technique. Un système qui fonctionne mais dont le mémoire ne justifie aucun choix, ne discute aucune alternative et n’évalue rien au-delà d’un « ça fonctionne » constaté, expose à un refus ou à un ajournement — même quand le code lui-même est de bonne qualité.
Motif 1 — Un système livré sans évaluation ni preuve de performance
C’est un motif très courant dans les mémoires de projet logiciel : le mémoire décrit la conception et le développement d’un système, puis s’arrête à la livraison sans jamais évaluer si l’objectif initial est réellement atteint. Un jury attend une mesure, même sommaire — temps de réponse, taux d’erreur, retour d’utilisateurs pilotes, comparaison avec l’existant que le système remplace — pas une simple affirmation que « le système fonctionne comme prévu ». Un mémoire qui documente une stratégie de test (tests unitaires, tests d’intégration, éventuellement tests de charge) avec des résultats rapportés, plutôt qu’une mention générique, évite ce premier motif de rejet.
Motif 2 — Des choix techniques non justifiés
Pourquoi ce framework plutôt qu’un autre ? Pourquoi cette base de données, ce patron de conception, cette architecture ? Un jury pénalise un choix technique présenté comme allant de soi, sans discussion d’au moins une alternative sérieusement envisagée. Ce motif touche particulièrement les mémoires rédigés en fin de projet, une fois les choix déjà figés depuis des mois : l’étudiant reconstruit alors une justification a posteriori, souvent perceptible par un jury habitué à distinguer une justification réfléchie d’une rationalisation tardive. Documenter les alternatives envisagées et les critères de décision au moment même où les choix sont faits, plutôt qu’en fin de rédaction, reste la meilleure protection contre ce motif.
Motif 3 — Confondre projet logiciel et recherche empirique
Un mémoire qui change de registre à mi-parcours — commencé comme un projet de développement puis reformulé en urgence comme une étude empirique pour « faire plus scientifique », ou inversement un projet de recherche qui s’arrête à un prototype sans jamais formuler ni tester d’hypothèse — est vite identifié par un jury et pénalise la cohérence globale du travail. Le mémoire de projet logiciel s’évalue sur la qualité de l’ingénierie (architecture, tests, livrable fonctionnel évalué), le mémoire de recherche empirique s’évalue sur la rigueur du protocole (question de recherche précise, métriques d’évaluation justifiées, outils statistiques mobilisés). Confondre les deux registres dans un même mémoire, sans le choisir explicitement dès le départ, est l’un des motifs de rejet les plus spécifiques à l’informatique. Notre guide comparatif entre mémoire de projet logiciel et mémoire de recherche empirique détaille les critères qui doivent trancher ce choix avant la rédaction.
Motif 4 — Réutilisation de code sans attribution ni discussion de licence
Un mémoire d’informatique intègre presque toujours des bibliothèques, des extraits de code trouvés en ligne, ou des composants open source — ce n’est pas en soi un problème. Le motif de rejet apparaît quand cette réutilisation n’est pas explicitement documentée : code copié depuis un dépôt public ou un forum de questions-réponses sans mention de la source, absence de discussion sur la licence du composant réutilisé et sa compatibilité avec le projet, ou pire, une présentation du travail qui laisse entendre qu’une fonctionnalité substantielle a été développée intégralement par l’étudiant alors qu’elle provient largement d’un tiers. Un jury attend une distinction claire, dans le mémoire, entre ce qui a été développé par l’étudiant et ce qui a été intégré, adapté ou réutilisé — cette distinction protège autant contre une accusation de plagiat de code que contre une évaluation faussée de l’ampleur réelle du travail personnel.
Motif 5 — Des résultats non reproductibles
Pour un mémoire orienté recherche empirique, la reproductibilité est une exigence importante pour les jurys de master recherche en informatique : jeux de données utilisés, métriques d’évaluation, paramètres expérimentaux et conditions de comparaison doivent être documentés de façon à ce qu’un tiers puisse reproduire les résultats annoncés. Comparer deux approches sur des conditions différentes — jeux de données différents, charge différente, environnement d’exécution différent — invalide la comparaison, même si les chiffres présentés semblent favorables à l’approche développée par l’étudiant. Un simple tableau de chiffres sans conditions de test identiques entre les approches comparées, ni test de significativité sur des mesures répétées, n’établit rien de généralisable et constitue un motif de contestation méthodologique fréquent en soutenance.
Motif 6 — Un ancrage insuffisant dans la littérature scientifique du domaine
Un mémoire qui ne s’appuie que sur de la documentation technique officielle et des blogs d’ingénierie, sans aucune référence à des travaux de recherche publiés sur le même problème, reste académiquement fragile même si le travail technique sous-jacent est solide. Un jury attend une mise en perspective par rapport à ce qui a déjà été établi ou tenté par d’autres — articles de conférences du sous-champ concerné, retours d’expérience publiés et évalués par les pairs, comparaison explicite avec des approches existantes plutôt qu’une présentation du système comme s’il évoluait dans un vide bibliographique. Ce motif touche particulièrement les mémoires très appliqués, adossés à un stage, où la pression du livrable technique laisse peu de temps pour la revue de littérature — un déséquilibre que le jury repère rapidement à la lecture du chapitre théorique.
Motif 7 — Des données réelles manipulées sans conformité RGPD
Un mémoire qui s’appuie sur des données réelles — logs applicatifs, export d’une base utilisateurs, corpus collecté par scraping — sans traiter explicitement la conformité RGPD expose à un motif de rejet distinct, parfois disciplinaire plutôt que purement académique. Écrire « données anonymisées » dans le chapitre méthode alors que seule une pseudonymisation réversible a été appliquée, ou présenter un jeu de données d’entreprise sans mention de l’accord du responsable de traitement, sont des erreurs qu’un jury identifie dès les premières questions sur le pipeline de traitement. Notre guide sur la conformité RGPD et l’anonymisation d’un jeu de données réel pour un mémoire d’informatique détaille les techniques attendues (généralisation, k-anonymat, hachage salé) et la distinction précise entre pseudonymisation et anonymisation que beaucoup de mémoires confondent encore.
Motif 8 — Une soutenance orale qui ne défend pas les choix du mémoire
Un mémoire écrit solide peut malgré tout être pénalisé, voire ajourné, si la soutenance orale ne parvient pas à défendre les choix qui y sont exposés. C’est particulièrement vrai en informatique lorsque le code a été en partie produit avec l’aide d’un tiers, d’une IA générative, ou d’un composant réutilisé : le jury attend que l’étudiant puisse expliquer, argumenter et discuter chaque choix technique oralement, pas seulement le décrire. Une présentation qui se limite à dérouler l’architecture sans jamais répondre aux questions sur les alternatives écartées est un signal négatif fort, indépendamment de la qualité du document écrit. Notre guide sur les scénarios de soutenance qui tournent mal et les stratégies de récupération détaille comment répondre à une question méthodologique imprévue sans se laisser déstabiliser, un exercice qui vaut aussi bien pour un mémoire de sciences humaines que pour un mémoire d’informatique.
Sécuriser son mémoire d’informatique avant le dépôt : la checklist
Avant de déposer un mémoire d’informatique, quelques vérifications ciblées permettent d’éliminer la plupart des motifs de rejet évoqués plus haut :
- Le registre est fixé et cohérent : le mémoire est explicitement un projet logiciel évalué ou une recherche empirique testée, pas un mélange des deux non assumé.
- Chaque choix technique majeur est justifié, avec au moins une alternative discutée et le critère de décision retenu.
- Une évaluation existe, même sommaire, du système livré ou de l’hypothèse testée — pas seulement une déclaration de fonctionnement.
- Le code réutilisé est distingué du code développé, avec les sources et licences mentionnées.
- Les conditions expérimentales sont documentées de façon à permettre une reproduction par un tiers, si le mémoire relève de la recherche empirique.
- Au moins quelques travaux de recherche publiés sont cités et discutés, en plus de la documentation technique.
- La conformité RGPD est traitée explicitement si des données réelles sont mobilisées, avec la distinction pseudonymisation/anonymisation correctement posée.
- Chaque choix est préparé pour être défendu oralement, pas seulement écrit — anticipez les questions sur les alternatives écartées.
Un refus qui reste rare, mais qui sanctionne des manquements précis
Comme pour l’ensemble des disciplines, un refus pur et définitif d’un mémoire dès la première soutenance reste un scénario minoritaire : l’issue la plus courante face à des manquements est l’ajournement, qui laisse la possibilité de corriger le travail et de se représenter. Notre guide général sur les motifs de refus d’un mémoire, la note éliminatoire et les recours possibles détaille le mécanisme de décision du jury, commun à toutes les disciplines ; les huit motifs présentés ici en constituent la déclinaison propre à l’informatique.
Foire aux questions
Un mémoire d’informatique peut-il être refusé uniquement parce que le code ne fonctionne pas parfaitement ?
Rarement à lui seul. Un système imparfait mais dont les limites sont identifiées, discutées et évaluées honnêtement est généralement mieux reçu par un jury qu’un système présenté comme abouti sans aucune évaluation critique. C’est l’absence de recul analytique, plus que l’imperfection technique elle-même, qui pèse le plus lourd.
Faut-il obligatoirement une évaluation statistique dans un mémoire de projet logiciel ?
Non. Un mémoire orienté projet logiciel s’évalue sur la qualité de l’ingénierie plutôt que sur une démonstration statistique. Une évaluation quantitative simple — performance mesurée, retours d’utilisateurs pilotes — reste toutefois attendue pour montrer que l’objectif initial du projet a été atteint.
Comment le jury détecte-t-il du code réutilisé sans attribution ?
Souvent par des questions ciblées en soutenance sur des portions précises du code, ou par comparaison avec des dépôts publics connus dans le sous-champ concerné. La meilleure protection reste une documentation explicite, dans le mémoire lui-même, de toute réutilisation de composants tiers.
Un mémoire qui s’appuie uniquement sur de la documentation technique et des blogs est-il automatiquement refusé ?
Pas automatiquement, mais il reste académiquement fragile face à un jury qui attend une mise en perspective avec la littérature de recherche publiée. Ajouter quelques références académiques discutées, même pour un sujet très appliqué, renforce nettement la solidité du chapitre théorique.
Que faire si mon sujet mélange développement et recherche sans que je l’aie décidé explicitement ?
Tranchez ce choix avant la rédaction finale, pas pendant : identifiez si votre travail est avant tout un livrable technique évalué ou une question de recherche testée, et structurez le mémoire en conséquence. Un format hybride assumé et cohérent reste préférable à un mélange non assumé des deux registres.
La conformité RGPD concerne-t-elle aussi les mémoires qui n’utilisent que des données de test fictives ?
Non, tant que les données sont réellement fictives et ne dérivent d’aucun individu réel. La vigilance RGPD s’impose dès qu’un jeu de données, même partiellement, provient de logs, d’utilisateurs réels ou d’un scraping de plateforme, même publiquement accessible.
En résumé
Un mémoire d’informatique ne se joue pas uniquement sur la qualité du système livré : les jurys sanctionnent avant tout l’absence d’évaluation, les choix techniques non justifiés, la confusion entre projet logiciel et recherche empirique, la réutilisation de code non documentée, les résultats non reproductibles, le manque d’ancrage dans la littérature, la conformité RGPD négligée et une soutenance qui ne défend pas les choix du document écrit. Anticiper ces huit motifs dès la conception du projet, plutôt qu’au moment de la rédaction finale, reste la meilleure protection contre un ajournement ou un refus.