LAMAS — Gestion d'assurance maladie

Le site et l'application web de la Mutuelle d'Action Sociale (MAS) reposaient sur Drupal — un CMS pensé pour la gestion de contenu, pas pour porter une application métier complexe. Résultat : une plateforme lente, peu évolutive et difficile à sécuriser, avec deux systèmes d'authentification distincts (un pour le web, un pour le mobile) qui créaient confusion et risques de sécurité. Le design daté et des fonctionnalités incomplètes ou mal structurées compliquaient l'expérience des adhérents, partenaires et gestionnaires. MAS ne disposait par ailleurs d'aucune application mobile dédiée.

Nous avons mené une refonte complète en séparant clairement les responsabilités : un site vitrine WordPress bilingue (français/arabe), optimisé pour le référencement, porte la présence publique de MAS ; trois applications métier Angular sécurisées — Espace Adhérent, Espace Partenaire et Back-office (avec des accès dédiés Admin, Support et Agent régional pour les dossiers hors Casablanca) — gèrent les opérations quotidiennes ; une application mobile Flutter native pour iOS et Android donne aux adhérents un accès mobile complet, une première pour MAS. Une authentification unifiée remplace les deux systèmes historiques distincts du web et du mobile.

La plateforme est aujourd'hui entièrement développée, testée et validée en environnement de préproduction — le passage en production reste à la seule confirmation du client. L'architecture modulaire (site, trois applications web, application mobile, deux API dédiées) permet des mises à jour indépendantes de chaque composant sans réingénierie globale, et l'application mobile ouvre à MAS un canal qui n'existait pas jusqu'ici.

Le projet a été découpé en trois lots livrés en parallèle : le site vitrine, les espaces web connectés (Adhérent, Partenaire, Back-office) et l'application mobile. Chaque lot a suivi le même cycle : cadrage fonctionnel et technique, développement itératif, tests utilisateurs (UAT), puis mise en production. Des points de suivi réguliers avec les équipes de MAS ont permis d'ajuster le périmètre au fil de l'eau, avec une approche agile plutôt qu'un cahier des charges figé.

La plateforme combine volontairement plusieurs technologies, chacune choisie pour son usage : WordPress pour le site vitrine (gestion de contenu simple pour l'équipe MAS, SEO natif), Angular pour les trois applications métier sécurisées (interfaces réactives, architecture modulaire), et Flutter pour l'application mobile (un seul code pour iOS et Android). Deux API Node.js distinctes assurent la séparation des responsabilités backend. Un point technique notable : le back-office lit — en lecture seule — la base de données Oracle du système interne existant de MAS, hébergée sur les serveurs du client. Cette intégration respecte les données et l'infrastructure déjà en place chez MAS, sans dupliquer ni migrer son système historique. La sécurité s'appuie sur une authentification JWT, un contrôle d'accès basé sur les rôles (RBAC), l'authentification multi-facteurs, le chiffrement des données sensibles et une conformité RGPD.

Pourquoi combiner WordPress, Angular et Flutter sur un même projet ?
Chaque technologie est choisie pour l'usage qui lui convient le mieux : WordPress pour un site institutionnel facile à maintenir par l'équipe MAS, Angular pour des applications métier sécurisées et complexes, Flutter pour une application mobile native performante sur iOS et Android. Cette approche évite de forcer un seul outil à couvrir des besoins très différents.

Comment intégrer une nouvelle plateforme avec un système interne existant ?
Quand un système legacy (comme une base de données Oracle interne) contient des données sensibles ou critiques, la meilleure approche est souvent une intégration en lecture seule via une API dédiée — plutôt qu'une migration complète, risquée et coûteuse. C'est l'approche retenue pour MAS : le nouveau système consulte les données existantes sans les dupliquer ni perturber le système en place.

Pourquoi séparer les espaces adhérent, partenaire et back-office ?
Séparer les interfaces par type d'utilisateur permet de sécuriser les données sensibles, d'adapter l'expérience à chaque audience, et de faire évoluer chaque espace indépendamment sans risquer de régression sur les autres.