Mémoire de Master — Analyse et questions d'examinateur

1. Le Directeur de mémoire est purement et simplement absent. p. i
La page de garde couv. désigne M. EDI Kouassi Hilaire, Maître de Conférences, UNA, Directeur du mémoire. Son nom n'apparaît nulle part dans les remerciements — ni en tête, ni en fin, ni sous aucune forme. La page cite le cabinet Heymann's Inc., le binôme KOUADIO PASCAL, le responsable KOUADIO AIME, le directeur M. LOHORE, l'enseignant DR KASSI, l'encadreur Dr Morié et la famille. Sept mentions, et pas une pour le Directeur du mémoire.
C'est le manquement le plus lourd de la page. Le directeur de mémoire est l'autorité scientifique sous laquelle le travail est déposé et soutenu ; son omission dans les remerciements d'un document qui porte son nom en couverture ne peut pas être lue comme une simple coquille.

Élément de comparaison à la disposition du jury. Les deux autres mémoires soutenus devant le même jury remercient tous deux explicitement cette personne :

La comparaison n'a pas vocation à accabler le candidat, mais elle établit que l'omission n'est pas une pratique locale ni une convention du parcours : c'est un oubli propre à ce document.

2. Une casse appliquée à tous… sauf à l'encadreur. p. i
Le candidat écrit systématiquement les patronymes en capitales :

Puis, pour la seule personne responsable de l'encadrement scientifique du mémoire :

Cinq noms, une seule exception, et c'est celle de l'encadrant. Une convention typographique appliquée quatre fois sur cinq n'est plus une convention : c'est une inattention qui a porté précisément là où elle se voyait le plus. Que la personne dont le candidat reconnaît lui-même qu'elle l'a suivi « depuis la structuration du sujet jusqu'à la rédaction finale » soit la seule à ne pas bénéficier du traitement réservé à tous les autres est difficile à justifier.

3. Le nom de l'encadreur est mal orthographié. p. i
Le patronyme exact est Morié. Le mémoire écrit « Morie », sans accent. Ce n'est pas isolé : le document entier est dépourvu d'accentuation (cf. §2.2), mais le fait que ce défaut global vienne frapper le nom de l'encadrant aggrave le premier point au lieu de l'excuser. Un candidat relit en priorité les noms propres de son jury — c'est précisément ce qui n'a pas été fait.

4. Le nom de l'encadreur est tronqué en page de garde. couv.
La couverture porte : « M. MORIE Ma   Maitre Assistance, UNA   Encadreur ». Le prénom est coupé au milieu, le grade est fautif (« Maitre Assistance » pour « Maître-Assistant »), et le titre employé est « M. » alors que les remerciements utilisent « Dr » — trois erreurs sur une seule ligne, toujours la même personne. Cumulées avec le point 2, elles cessent de ressembler à des coquilles isolées.

5. La hiérarchie des remerciements est inversée. p. i
Ordre effectif dans le document : le cabinet Heymann's Inc. → le binôme KOUADIO PASCAL → le responsable KOUADIO AIME → le directeur M. LOHORE → l'enseignant DR KASSI → l'encadreur Dr Morié → la famille. Le Directeur du mémoire, lui, ne figure à aucune position.
L'encadrant scientifique arrive donc en sixième position, après cinq personnes rattachées à l'entreprise d'accueil ou extérieures à l'encadrement académique. Il est en particulier placé après « l'enseignant DR KASSI, qui nous a suivis de près et a formulé des remarques et suggestions utiles pour améliorer l'outil » — un tiers dont le rôle est décrit en des termes plus élogieux et plus concrets que celui de l'encadreur officiel, et dont le nom, lui, est correctement mis en capitales.
La convention académique place l'encadrant en tête, avant les remerciements professionnels et personnels. L'inversion ici n'est pas neutre : combinée aux quatre points précédents, elle donne l'impression que le mémoire a été vécu comme un projet d'entreprise auquel l'université a été associée tardivement.

Lecture d'ensemble. Pris isolément, chacun de ces points serait une coquille. Pris ensemble, ils dessinent un partage net :

Chaîne entreprise / extérieure	Chaîne académique
Heymann's Inc. — cité en premier KOUADIO PASCAL — capitales, 2e KOUADIO AIME — capitales, 3e M. LOHORE — capitales, 4e DR KASSI — capitales, 5e, éloges circonstanciés	Dr EDI Kouassi Hilaire, Directeur — absent Dr Morié, Encadreur — minuscules, sans accent, tronqué en couverture, 6e position

Les cinq mentions correctement traitées relèvent toutes de l'entreprise d'accueil ou d'un tiers ; les deux mentions défaillantes sont exactement les deux membres de l'encadrement universitaire. La régularité de ce partage est ce qui empêche de le classer comme un simple défaut de relecture.

A. Confusion entre « CRM reconnue » et « exposition résiduelle E* » — erreur sur le mécanisme central du mémoire. p. 28 · p. 31-32
Le §3.4 p. 28 pose : E* = max(0, EVA − CVA) et précise, correctement, que « ce résultat représente l'exposition résiduelle après prise en compte de la garantie ». Puis, deux lignes plus loin sur la même page, il pose : EAD_net = EAD − CRM_reconnue.
Ces deux formules sont incompatibles : dans la méthode globale de la valeur ajustée de Bâle II, E* est l'exposition nette — on ne la soustrait pas une seconde fois de l'EAD. Le mémoire mélange deux formalisations concurrentes du même mécanisme.
L'Exemple 3 p. 31-32 rend l'erreur explicite : EVA = 50 M, CVA = 51 M, donc « la CRM reconnue est de max(0 ; 50 M − 51 M) = 0 ». Si l'on applique alors EAD_net = EAD − CRM_reconnue, on obtient EAD_net = 50 M − 0 = 50 M, soit un RWA plein — alors que le texte conclut au contraire, et à juste titre sur le fond, que « le collatéral suffit à couvrir entièrement l'exposition ajustée ». Le résultat 0 est l'exposition résiduelle, pas la CRM.
L'Exemple 1 p. 31 confirme la confusion : la CRM y est calculée par 30 M × (1 − 0,20) = 24 M, c'est-à-dire par la valeur ajustée du collatéral — troisième formalisation, différente des deux précédentes, et dans laquelle la décote He sur l'exposition n'est jamais appliquée.
Trois écritures différentes du même calcul coexistent entre les pages 28 et 32. Ce point doit être élucidé : soit le code est correct et la rédaction est fautive, soit l'erreur est dans le moteur de calcul.

B. Erreur factuelle sur le superviseur prudentiel de la zone CEMAC. p. 5 · p. 44
Le mémoire écrit p. 5 « La BEAC, qui supervise la zone CEMAC » et attribue à la BEAC la production du dispositif prudentiel (« instructions BCEAO-CEMAC », « seuil de dégradation BCEAO et BEAC » p. 60). Or, en zone CEMAC, la banque centrale est la BEAC, mais le superviseur bancaire et l'auteur des règlements prudentiels est la COBAC (Commission Bancaire de l'Afrique Centrale). Le sigle COBAC n'apparaît qu'une seule fois dans tout le document — p. 44, « textes prudentiels BCEAO et COBAC » — et ne figure même pas dans la liste des abréviations p. ii. Dans un mémoire dont le titre annonce la zone CEMAC, confondre la banque centrale et le régulateur prudentiel est une erreur de fond que tout jury bancaire relèvera.

C. Confusion entre UML et normalisation relationnelle. p. 22 · p. 37 · p. 40
§3.1 p. 22 : « produire le schéma de la base de données, en appliquant les règles UML pour éviter les redondances et garantir la cohérence ». §3.5.2 p. 37 : « La base de données est structurée selon les principes UML ». §4.2 p. 40 : « Ce choix respecte les règles UML, chaque information est stockée à un seul endroit et dépend entièrement de la clé primaire de sa table ».
La propriété décrite — « chaque information dépend entièrement de la clé primaire » — est la définition des formes normales (2NF/3NF de Codd), et n'a rien à voir avec UML, qui est un langage de notation graphique sans aucune règle de normalisation. Pour un parcours MIAGE, où la modélisation des données est au cœur de la formation, cette confusion est significative.

D. Contradictions sur le périmètre réellement livré. p. v · p. vi · p. 11 · p. 45 · p. 60-61
Trois affirmations incompatibles coexistent sur la zone CEMAC :

• Résumé p. v : « Cette application couvre l'intégralité des catégories prudentielles UEMOA et CEMAC ».
• Abstract anglais p. vi : « covers all UEMOA prudential categories » — la CEMAC a disparu. Les deux résumés ne disent pas la même chose.
• §4.10 p. 61 : « La première et principale limite est l'absence d'implémentation des règles métier de la zone CEMAC ».

De même pour le capital planning : exigence n° 2 du cahier des charges p. 11, déclarée « satisfaite structurellement » p. 60, puis déclarée absente p. 61 (« La troisième limite est l'absence de capital planning et ICAAP »).
Et pour le module opérationnel : §4.8 p. 45 et §4.9 p. 60 indiquent que l'écran Flutter est « en cours de finalisation », alors que le §4.9 conclut malgré tout que l'exigence « est satisfaite » — et que les figures 20 à 22 p. 58-59 montrent des écrans de risque opérationnel apparemment fonctionnels.

E. Incohérence sur le seuil réglementaire dans un commentaire de figure. p. 48
Commentaire des figures 4 à 6 p. 48 : « Si le ratio se rapproche du seuil réglementaire de 8,5 %, la décision est de renforcer les fonds propres ». Ce chiffre n'apparaît nulle part ailleurs : le mémoire établit 9 % (FPE cible) et 11,5 % (avec coussin) p. 30. D'où vient ce 8,5 % ? S'il est affiché par l'application, l'outil applique un seuil que le mémoire lui-même contredit.

F. Erreur d'unité dans l'Exemple 2. p. 31
« Le RWA est de 31 500 000 et le capital minimum UMOA cible est de 2 835 000, ce qui est bien inférieur aux 90 000 000 qu'on obtiendrait avec une pondération standard de 100 %. » On compare ici un capital (2 835 000) à un RWA (90 000 000). Le capital à 100 % serait 90 000 000 × 9 % = 8 100 000. La comparaison correcte est 2 835 000 contre 8 100 000.

G. Contradiction technologique : ORM ou pas d'ORM ? p. 18 · p. 39 · p. 62
§2.3 p. 18 : SQLite « pilotée directement via le module sqlite3 ». §4.1 p. 39 : « SQLite avec ORM a été retenu pour maintenir un contrôle total sur les requêtes […] déléguer cela a un ORM produit du code assez lisible et potentiellement performant ». Conclusion p. 62 : « pilotée directement via le module sqlite3 ».
Le §4.1 est doublement incohérent : il annonce un ORM alors que les deux autres sections l'excluent, et son argumentation est retournée — « déléguer à un ORM produit du code lisible et performant » est un argument en faveur de l'ORM, utilisé pour justifier de ne pas en employer. La phrase d'origine disait probablement l'inverse (« peu lisible et peu performant »). Trace d'une réécriture non relue.

H. Aucun appel de citation dans l'ensemble du document. p. 19-20 · p. 64
Le chapitre 2 s'intitule « État de l'art » p. 19-20 mais ne comporte pas une seule référence. Il affirme p. 19 que « plusieurs auteurs ont souligné l'importance de séparer la couche de calcul de la couche de présentation » sans en nommer aucun ; il renvoie aux « recommandations du Comité de Bâle sur la gouvernance des modèles de risque » sans identifier le texte (BCBS 239 ? BCBS 265 ?) ; il cite Axiom SL, FIS et Wolters Kluwer sans source. La bibliographie p. 64 compte 7 entrées, dont 4 documentations techniques en ligne (FastAPI, Flutter, SQLite) et un ouvrage d'architecture logicielle (Fowler) jamais mobilisé dans le texte. Il reste donc 3 sources primaires réglementaires et zéro référence académique. C'est insuffisant pour un mémoire de Master, et c'est le point qui distingue le plus défavorablement ce travail des deux autres du jury.

I. Sécurité et confidentialité : angle mort total. p. 17 · p. 37
L'application manipule des données bancaires nominatives (contreparties, encours, notations, garanties) couvertes par le secret bancaire. Le mémoire ne mentionne à aucun moment : le chiffrement de la base SQLite, l'authentification de l'utilisateur, le contrôle d'accès, la journalisation des accès (distincte du journal de calcul), ou le fait qu'une API FastAPI en écoute sur 127.0.0.1 p. 17 et p. 37 est accessible à tout processus local. Pour un outil destiné au secteur bancaire, c'est une omission sérieuse.

J. Contradiction entre l'architecture monoposte et les usages décrits. p. 17, 37 vs p. 49, 55, 59
L'architecture est explicitement « monoposte », « sans infrastructure serveur », base SQLite locale p. 17 et p. 37. Or les commentaires des écrans décrivent des usages collectifs : « l'écran que consulte un comité des grands risques » p. 49, « un directeur des risques s'en sert pour justifier auprès du régulateur » p. 55, « c'est l'écran destiné à la direction » p. 59. Comment plusieurs personnes consultent-elles un outil installé sur un poste unique, avec une base non partagée ?

K. Contribution personnelle non délimitée. p. i · p. 1 · p. 20 · p. 57-58
Les remerciements p. i indiquent : « mon collègue KOUADIO PASCAL, avec qui j'ai conçu l'outil présenté dans ce mémoire ». L'introduction p. 1 et le §2.4 p. 20 précisent que le risque de marché « a été développé par mon collègue ». Or les figures 18 et 19 p. 57-58 (dashboard et courbe des taux du risque de marché) sont présentées parmi les résultats du mémoire, et le tableau de bord général p. 48 consolide les trois risques. La frontière entre le travail propre du candidat et celui de son binôme n'est établie nulle part. Un jury doit pouvoir évaluer une contribution individuelle.

Position d'ensemble. Le candidat a réalisé un travail d'appropriation prudentielle sérieux et a produit une application qui fonctionne — ce n'est pas un mémoire creux. Mais le document ne reflète pas ce travail : il est non relu, non référencé, incomplet sur les livrables de conception attendus d'un MIAGE, et il contient des erreurs sur le mécanisme même qu'il prétend automatiser.

La soutenance orale sera déterminante, davantage que pour les deux autres mémoires du jury. Trois réponses conditionnent l'appréciation finale : Q1 (le candidat maîtrise-t-il réellement ce qu'il a écrit ?), Q6 (le moteur de calcul de la CRM est-il correct ?) et Q19 (quelle est sa contribution propre ?). Si ces trois réponses sont solides, le fond justifie une validation assortie d'une exigence de corrections. Si elles ne le sont pas, une révision substantielle avant validation paraît nécessaire.