Du cadrage méthodologique à la mise en œuvre technique : validation, écarts et gouvernance réelle des données du projet ALFRED — vers un déploiement public
Master Expert IT — Applications Intelligentes & Big Data · FEDE · Fin de formation — 30 septembre 2026
Introduction
Je m'appelle Céline Rousselot et je conçois, depuis janvier 2026, un assistant intelligent local-first nommé ALFRED. Ce projet est né dans un contexte particulier : un arrêt maladie prolongé, associé à une situation de handicap invisible et à des épisodes de ralentissement cognitif liés à la maladie — sans jamais interrompre ma vision produit, ma capacité d'analyse ni ma volonté de concevoir un système technique complet.
Cette expérience a fait émerger un besoin concret : disposer d'un assistant capable de soutenir l'organisation quotidienne, de faciliter la reprise d'idées et de maintenir une continuité dans les tâches lorsque la fatigue ou la charge cognitive rendent les échanges et la planification plus difficiles. Au-delà de mon usage personnel, ALFRED répond à un besoin plus large : celui d'outils d'assistance numérique respectueux de la maîtrise des données par l'utilisateur, moins dépendants d'une infrastructure cloud opaque.
ALFRED n'est pas né dans l'abstrait. Un premier travail de cadrage, formalisé dans le mémoire professionnel D42 selon la méthodologie Lean Six Sigma (cycle DMAIC), a posé les fondations du projet — architecture, gouvernance, sécurité dès la conception. Cette thèse professionnelle (épreuve D52) documente la confrontation entre ce cadrage et la mise en œuvre technique réelle : ce qui a été construit, testé, validé, et ce qui reste à consolider.
Problématique
Comment concevoir, sécuriser et gouverner un assistant intelligent local-first et multi-plateforme, en faisant évoluer son architecture de données du relationnel léger vers des briques relationnelle avancée, NoSQL et Big Data, pour préparer un déploiement public respectueux de la sobriété numérique et de la protection des données utilisateur ?
Hypothèse de travail
Une architecture local-first et modulaire, conçue selon des principes de gouvernance dès la conception — privacy by design, security by design, sobriété numérique — et dotée d'une architecture de données évolutive, permet de concilier performance fonctionnelle, maîtrise des risques et extensibilité multi-plateforme, y compris pour un projet mené avec des moyens limités.
Méthodologie
Étude de cas unique associée à une démarche de recherche-action : je suis à la fois conceptrice et analyste du terrain étudié, posture assumée et compensée par une double validation croisée (professeur référent et contact du réseau professionnel).
Plan de la thèse
Partie 1 — Cadrer le problème
Gouvernance et sobriété d'un assistant intelligent local-first : état de l'art, problématique et méthodologie, présentation du terrain ALFRED.
Partie 2 — Concevoir et sécuriser l'architecture
Résultats datés (08/07/2026 → 30/09/2026) : architecture multi-plateforme, architecture de données (PostgreSQL, MongoDB, PoC Hadoop), sécurité et gouvernance by design, sobriété numérique.
Partie 3 — Évaluer, comparer et tirer les enseignements
Confrontation à l'hypothèse, comparaison avec des projets similaires (Home Assistant, Mycroft/OpenVoiceOS, Rhasspy), limites et perspectives.
Partie 1 — Cadrer le problème
Avant d'analyser les résultats de conception, cette partie situe ALFRED dans son contexte théorique et distingue clairement le périmètre de cette thèse de celui du mémoire professionnel D42, déjà réalisé et validé : le D42 documente ce qui a été planifié, cette thèse documente ce qui a été effectivement construit, testé et validé.
1.1 — État de l'art
L'état de l'art mobilise les architectures locales et le mouvement local-first (Kleppmann), la génération augmentée par récupération ou RAG (Lewis et al.), les cadres de gouvernance de l'IA (NIST AI RMF, réglementation européenne) et la sobriété numérique comme principe d'arbitrage plutôt que comme présomption. Ce cadrage théorique permet d'évaluer ALFRED comme un objet de recherche appliquée, et non comme une simple expérimentation personnelle.
1.2 — Problématique, hypothèse et méthodologie
L'hypothèse de travail comporte trois critères de réfutabilité explicites : l'absence de preuve technique vérifiable pour une brique donnée, une dépendance externe non maîtrisée sur une brique critique, ou un surdimensionnement technologique manifeste. Sur le plan méthodologique, ce travail relève d'une étude de cas unique associée à une recherche-action : je suis à la fois conceptrice et analyste du terrain étudié, posture compensée par une double validation croisée (professeur référent et contact de mon réseau professionnel).
1.3 — Présentation du terrain : le projet ALFRED
ALFRED se structure en plusieurs briques complémentaires : ALFRED_PC (cœur applicatif local), ALFRED_WEB (vitrine publique et futur point d'entrée multi-utilisateur), ALFRED_ANDROID (prototype de client compagnon mobile) et une API compagnon FastAPI assurant le pont entre elles. Cette thèse distingue explicitement l'état constaté au 08/07/2026 de l'état cible visé au 30/09/2026, afin de ne jamais confondre les preuves déjà disponibles avec les objectifs de consolidation prévus avant la soutenance.
Partie 2 — Concevoir et sécuriser l'architecture
Cette partie documente les résultats effectivement obtenus, et non une architecture cible théorique. Chaque brique technique est datée et qualifiée selon quatre statuts homogènes, afin de ne jamais confondre un résultat déjà démontré avec un objectif de consolidation encore à atteindre.
2.1 — Architecture applicative multi-plateforme
L'architecture applicative repose sur quatre briques articulées plutôt que sur une application monolithique. ALFRED_PC, cœur fonctionnel développé en Python, est validé dans son principe : moteur conversationnel, routeur de modèles de langage, mémoire vectorielle. ALFRED_WEB, développé avec Flask, est validé comme vitrine publique et intègre désormais un socle PostgreSQL pour les comptes utilisateurs (onze tests automatisés passés contre une base réelle), en cours de consolidation réglementaire avant toute ouverture publique. ALFRED_ANDROID, client compagnon natif Kotlin/Jetpack Compose, est un prototype fonctionnel validé en conditions réelles le 02/07/2026. L'API compagnon FastAPI, qui relie ALFRED_PC et ALFRED_ANDROID, avait été validée à cette même date mais son fichier source s'est révélé absent du dépôt au 08/07/2026 — une régression assumée et documentée plutôt que masquée. Le composant a depuis été entièrement reconstruit (13/07/2026), avec la même authentification par jeton en temps constant, et huit tests automatisés le valident aujourd'hui ; seule la re-validation de bout en bout avec l'application Android reste à refaire, ce qui le qualifie désormais « prototype fonctionnel ».
2.2 — Architecture de données : du relationnel léger au Big Data
Le cadrage initial du mémoire D42 envisageait une modélisation relationnelle unifiée (méthode Merise). La mise en œuvre réelle a conduit à une architecture de persistance hétérogène et proportionnée : SQLite pour la mémoire locale mono-utilisateur, PostgreSQL pour les comptes utilisateurs (relationnel avancé), MongoDB pour les contenus documentaires — articles validés en production, conversations au stade de prototype — et un PoC Hadoop isolé, exécuté avec succès sur un cluster réel, démontrant les principes du traitement distribué sans les imposer à un volume de données qui ne le justifie pas.
2.3 — Sécurité et gouvernance by design
La gouvernance s'appuie sur un cadre réglementaire européen mouvant (RGPD, NIS2, AI Act, Digital Omnibus) et sur une sécurité by design déjà mature côté ALFRED_PC : architecture Zero Trust, modélisation des menaces STRIDE, hachage bcrypt des mots de passe, protection anti-CSRF. Une gap analysis article par article du règlement européen sur l'intelligence artificielle a par ailleurs révélé qu'ALFRED répond vraisemblablement à la définition légale de système de reconnaissance des émotions, via son module d'analyse d'expression faciale, ce qui le classerait en système à haut risque dès son ouverture publique — un constat traité par anticipation plutôt que différé : ALFRED est conçu, dès maintenant, pour répondre aux exigences d'un système à haut risque.
2.4 — Sobriété numérique et transition écologique
Le choix local-first constitue un levier de sobriété numérique, mais pas une garantie automatique : chaque brique de persistance est évaluée selon sa pertinence fonctionnelle réelle. Le PoC Hadoop illustre directement cette tension entre démonstration de compétence académique et sobriété revendiquée : exécuté avec succès sur un cluster réel, il a notamment révélé deux incidents opérationnels concrets en cours de route, confirmant qu'introduire un système conçu pour des volumes de l'ordre du pétaoctet dans un projet mono-utilisateur constituerait le type même de surdimensionnement que l'hypothèse de ce travail identifie comme facteur d'invalidation.
Cette lecture différenciée fait apparaître un tableau contrasté plutôt qu'un état homogène — et c'est précisément ce contraste documenté, plus qu'une réussite uniforme, qui nourrit l'évaluation critique de la Partie 3.
Partie 3 — Évaluer, comparer et tirer les enseignements
Cette troisième partie évalue la portée réelle du travail mené : dans quelle mesure les résultats obtenus confirment, nuancent ou infirment l'hypothèse formulée en introduction, comment ALFRED se positionne face à des projets comparables, et quelles limites et perspectives structurent la suite du projet.
3.1 — Résultats au regard de l'hypothèse
L'hypothèse est validée pour l'essentiel de son périmètre : preuves techniques vérifiables (MongoDB, PostgreSQL, Android, scans de sécurité), sécurité intégrée dès la conception, extensibilité multi-plateforme confirmée comme trajectoire. Deux points la nuancent : le démonstrateur Hadoop, exécuté avec succès mais délibérément non intégré à la production car disproportionné au regard du besoin réel, et l'API compagnon, dont l'authentification doit être renforcée avant tout usage élargi.
3.2 — Comparaison avec des projets similaires
ALFRED est mis en perspective avec trois projets emblématiques de l'écosystème local-first : Home Assistant Assist (finalité domotique plutôt que cognitive), Mycroft et son successeur communautaire OpenVoiceOS (leçon sur le risque de dépendance à un porteur unique), et Rhasspy (modularité forte, moins intégré comme assistant cognitif complet). Cette comparaison montre qu'ALFRED ne prétend pas inventer seul les briques de l'assistance locale, mais les combine autour d'une finalité différente : un assistant cognitif personnel, centré sur la mémoire, l'accessibilité et la gouvernance des données.
3.3 — Limites et perspectives
Les limites assumées portent sur l'authentification de l'API compagnon, le périmètre encore restreint du client Android, le champ volontairement circonscrit du démonstrateur Hadoop, et la qualification réglementaire encore à sécuriser juridiquement. Le portage du projet par une seule personne constitue également un point de vigilance identifié par la comparaison avec Mycroft. Les perspectives à court terme portent sur le durcissement de l'authentification, la consolidation de la politique de conservation des données et la production de l'analyse d'impact avant toute ouverture publique.
Cette évaluation conduit à une réponse nuancée à la problématique : ALFRED démontre la faisabilité d'une architecture local-first, modulaire et gouvernée, mais cette faisabilité reste conditionnée à une consolidation progressive des briques les plus sensibles avant tout déploiement public.
Conclusion
Ce travail est parti d'une question centrale : comment concevoir, sécuriser et gouverner un assistant intelligent local-first et multi-plateforme, en faisant évoluer son architecture de données du relationnel léger vers des briques relationnelles avancées, NoSQL et Big Data, afin de préparer un déploiement public respectueux de la sobriété numérique et de la protection des données utilisateur ? La réponse apportée est nuancée : ALFRED démontre la faisabilité d'une architecture local-first, modulaire et évolutive, sans renoncer à ses principes fondateurs — maîtrise locale des données, sécurité dès la conception, limitation des dépendances, documentation des preuves et proportionnalité des choix techniques.
L'hypothèse de travail se trouve validée pour l'essentiel de son périmètre : la persistance documentaire MongoDB est validée, le socle PostgreSQL des comptes utilisateurs est testé, le client Android compagnon est fonctionnel au stade de PoC, et le démonstrateur Hadoop a été exécuté avec succès sur un cluster réel. Cette validation n'est ni totale ni complaisante : le démonstrateur Hadoop reste disproportionné au regard du volume réel d'usage d'ALFRED et n'a pas été intégré à la production, et l'API compagnon nécessite une consolidation de son authentification avant tout usage élargi. Ces écarts ne disqualifient pas l'hypothèse — ils en confirment au contraire l'utilité : une hypothèse réellement réfutable doit permettre d'identifier les cas où une brique ne satisfait pas pleinement les critères annoncés.
Ce travail comporte des limites assumées. La première est méthodologique : je suis à la fois la conceptrice du système étudié et l'analyste de ce même système, un risque de subjectivité atténué par une double validation croisée. La seconde tient au caractère unique du cas étudié, qui ne permet pas de généraliser directement les conclusions à tous les projets d'assistants intelligents local-first — mais qui offre une grille de lecture transférable : dater les preuves, qualifier les niveaux de maturité, documenter les écarts, arbitrer les choix techniques au regard du besoin réel.
Les perspectives découlent directement de ces limites : à court terme, consolider l'authentification de l'API compagnon, stabiliser les politiques de conservation des données et produire l'analyse d'impact relative à la protection des données avant toute ouverture publique. La comparaison avec des projets comme Home Assistant, Mycroft/OpenVoiceOS et Rhasspy rappelle par ailleurs qu'un projet porté par une seule personne doit compenser cette fragilité par une discipline renforcée de documentation et de gouvernance.
Au terme de ce travail, ALFRED ne peut pas être présenté comme un système achevé. Il doit être présenté comme un système gouverné : un système capable d'expliciter ses choix, d'associer ses résultats à des preuves, d'identifier ses limites et de justifier ses arbitrages. Ce travail ne clôt donc pas le projet ALFRED — il en stabilise une étape, et montre qu'un assistant intelligent local-first peut être pensé non seulement comme un objet technique, mais comme un système à gouverner.
Note de transparence sur l'usage de l'intelligence artificielle
Dans le cadre de la rédaction de cette thèse professionnelle et de la mise en œuvre technique du projet ALFRED, j'ai eu recours à des outils d'intelligence artificielle générative, notamment ChatGPT et Claude Code, comme outils d'assistance. Ces outils ont été mobilisés pour accompagner la rédaction, la reformulation, la structuration et la clarification de certains contenus, ainsi que pour soutenir ponctuellement le développement, la relecture, le débogage et la documentation de scripts techniques liés au projet ALFRED.
Cet usage s'inscrit d'abord dans un objectif précis : faciliter le processus de rédaction tout en limitant la saisie manuelle prolongée, compte tenu d'une tendinite de De Quervain nécessitant une immobilisation partielle des pouces et une réduction des sollicitations répétées. L'intelligence artificielle a ainsi été mobilisée comme un dispositif d'accessibilité et de compensation, permettant de préserver la continuité du travail de recherche et de rédaction sans aggraver la contrainte physique.
Il s'inscrit également dans la logique même explorée par le projet ALFRED et par la démarche Cognitive Products Lab : concevoir des outils d'assistance capables d'accompagner l'utilisateur dans la structuration de ses idées, la clarification de ses raisonnements et le questionnement critique de ses choix. Dans ce cadre, l'IA n'est pas envisagée comme un substitut à l'auteure, mais comme un appui permettant de pousser les concepts, de challenger les formulations et d'identifier des angles morts.
Les outils d'IA ont été mobilisés principalement pour :
- Proposer des reformulations alternatives à partir de contenus rédigés ou structurés par l'auteure
- Améliorer la fluidité rédactionnelle de certains passages
- Aider à vulgariser ou clarifier certains concepts techniques, réglementaires ou méthodologiques
- Soutenir l'organisation du plan, des transitions et des articulations entre les parties
- Faciliter la relecture stylistique et la cohérence générale du manuscrit
- Accompagner ponctuellement la formalisation de contenus techniques issus du projet ALFRED, sans se substituer aux preuves, aux tests ou aux développements réalisés
L'utilisation de ces outils ne constitue pas une délégation de la réflexion, de l'analyse ou de la responsabilité académique. Les choix de problématique, d'hypothèse, de méthodologie, d'architecture, de gouvernance, d'interprétation des résultats et de positionnement critique relèvent de ma responsabilité d'auteure. Les contenus proposés par l'IA ont été relus, sélectionnés, corrigés, adaptés et validés par mes soins avant intégration dans le manuscrit.
Les outils d'intelligence artificielle n'ont pas été utilisés comme auteurs ou co-auteurs de ce travail. Ils sont mentionnés uniquement au titre d'outils d'assistance utilisés dans le processus de rédaction et de mise en forme. Le présent manuscrit demeure un travail personnel, dont j'assume l'intégralité du contenu soumis à évaluation.
Une attention particulière a été portée au respect des règles relatives au plagiat, à la citation des sources et à la traçabilité des références mobilisées. Les formulations assistées par IA ne dispensent pas de l'obligation de citer les sources lorsqu'une idée, un cadre théorique, une donnée, une réglementation ou un résultat technique repose sur une source identifiable.
Cette démarche de transparence répond à trois principes : le respect des sources, la responsabilité de l'auteure et l'explicitation des conditions réelles de production du manuscrit.
Annexes techniques
Dossier d'annexes techniques vivant reliant les affirmations du manuscrit à des preuves datées. Version web condensée, sans détail opérationnel sensible.