Montée en compétences : mapping honnête entre le référentiel du Mastère Expert IT Applications Intelligentes & Big Data (FEDE) et la réalité du projet ALFRED

1. Pourquoi un mapping plutôt qu'une affirmation

Justifier une expérience professionnelle pour un diplôme, c'est démontrer que des compétences précises ont été mises en application — pas raconter qu'un projet "touche un peu à tout". Le référentiel du Mastère Expert IT Applications Intelligentes & Big Data de la FEDE liste des blocs de compétences précis, en Fondamentaux et en Perfectionnement. La seule façon honnête de répondre "est-ce qu'ALFRED couvre ce bloc ?" est d'aller vérifier le code, les fichiers de configuration, les tests et les dashboards de suivi — pas de se fier à l'impression générale que "c'est un gros projet donc ça doit coller".

2. La méthode : relire le code, pas la mémoire

Le mapping ci-dessous a été construit en repassant sur la structure réelle du projet — ALFRED_PC (le moteur), ALFRED_WEB (la vitrine), et le nouveau ALFRED_ANDROID — plutôt qu'en partant de ce que je pensais avoir fait. Sources vérifiées :

• requirements.txt des deux projets — les dépendances réellement installées, pas celles commentées "à activer plus tard" ;
• ROADMAP.md et BACKLOG.md, générés automatiquement depuis un manifest de fichiers suivis (1114 fichiers au 02/07/2026) ;
• les dashboards de suivi (tests, sécurité, conformité) — pas des captures d'écran figées mais des JSON régénérés par script ;
• les résultats de tests réels (pytest) et de scans sécurité (bandit, pip-audit).

Cette rigueur a un coût : elle fait remonter les points où ça ne colle pas. C'est précisément l'intérêt de la démarche.

3. Mastère 1 — Fondamentaux

Management de projet informatique

Dev et bases de données

Dev d'apps intelligentes et Big Data

4. Mastère 2 — Perfectionnement

Management de projet informatique

Dev et bases de données

Dev d'applications intelligentes et Big Data

5. Le gap identifié : Android et NoSQL absents

Le premier passage du mapping, fin juin 2026, a mis en évidence un problème net : le stack ALFRED est 100% Python côté moteur. Le référentiel FEDE cite explicitement Java/Kotlin Android et MongoDB/NoSQL. Ni l'un ni l'autre n'existait dans le projet — ALFRED_ANDROID/ était un dossier vide, et la persistance côté web reposait sur un dictionnaire Python statique et des fichiers JSON.

Deux options se présentaient : documenter ces compétences via une autre expérience professionnelle, ou les construire concrètement dans ALFRED. J'ai choisi la seconde — par cohérence avec le reste de la démarche (vérifier plutôt qu'affirmer), et parce que le roadmap prévoyait déjà une "exploration interface Android".

Les deux briques ont été testées, pas seulement écrites : 5/5 tests pytest sur l'API compagnon, scan bandit et pip-audit sans issue medium/high sur l'ensemble des nouveaux fichiers Python, et suivi intégré aux dashboards du projet (blocs B09 et B21).

6. La décision : combler dans le projet, pas ailleurs

Ce choix garde une limite assumée : l'authentification utilise un jeton partagé statique, pas encore l'authentification PIN/bcrypt déjà en place ailleurs dans le projet (Bloc 20). Le reste a été vérifié en conditions réelles le 02/07/2026 : ouvert dans Android Studio, synchronisé (plugin Compose Compiler requis depuis Kotlin 2.0, corrigé au passage), compilé avec succès, lancé sur émulateur Pixel 6, et connecté pour de vrai à l'API compagnon — statut ALFRED et rappels réels affichés dans l'app, pas une simple capture d'écran de code. Un mapping honnête doit dire ce qui n'est pas encore vérifié, mais aussi mettre à jour ce qui l'est devenu entretemps.

6bis. Un troisième gap comblé : Hadoop

Le Big Data distribué restait, jusqu'au 09/07/2026, dans la même situation que MongoDB et Android avant leur mise en pratique : une case du référentiel non couverte. Un PoC Hadoop a depuis été exécuté avec succès sur un cluster réel (cinq conteneurs, pattern MapReduce classique), à partir de journaux de sécurité anonymisés du projet, avec un résultat vérifié par recoupement avec un calcul local. Deux incidents réels rencontrés en cours de route — dimensionnement des ressources YARN, compatibilité Python de l'image communautaire utilisée — ont été documentés plutôt que masqués.

Ce PoC reste volontairement isolé : il ne s'intègre pas à l'architecture de production d'ALFRED, dont le volume de données actuel ne justifie pas un traitement distribué. La compétence est démontrée sans être sur-déployée — cohérence assumée avec le principe de sobriété numérique du projet.

7. Ce qui reste un vrai écart

Combler ces gaps n'efface pas les autres. Pour rester honnête jusqu'au bout :

• JEE / Oracle — aucune brique Java EE ni base Oracle dans le projet ;
• PHP — jamais utilisé, le web est en Python/Flask ;
• Cassandra — aucune base wide-column, MongoDB (document) ne couvre pas ce paradigme ;
• Node.js comme backend applicatif — Node.js est installé sur l'environnement de dev mais jamais utilisé pour servir une application.

Ces cases resteront probablement à documenter via une autre expérience professionnelle, sauf si un besoin réel du projet ALFRED justifie un jour de les construire — je ne veux pas ajouter de la technologie juste pour cocher une case du référentiel.

8. Tableau de correspondance complet

✅ couvert · 🟡 partiellement couvert / vigilance · ❌ non couvert

9. Conclusion

Un mapping de compétences n'a de valeur que s'il résiste à la vérification. Celui-ci a fait remonter trois vrais manques, ils ont été comblés par de la pratique réelle et testée — pas par une simple mise à jour de document — et il continue d'assumer ce qui reste hors périmètre. C'est cette rigueur, plus que le nombre de cases cochées, qui constitue à mes yeux la vraie montée en compétences.

Céline Rousselot — Cognitive Products Lab

Étudiante en Mastère Expert IT IA & Big Data et Cybersécurité chez EXXEA (référentiel FEDE), fondatrice du projet ALFRED (assistant IA adaptatif). Ce mapping fait partie du dossier de validation d'expérience professionnelle du Mastère.

Voir le profil →