Assistant de messagerie

Proposition d'architecture pour le comité. Le complément Outlook devient une application à part entière du SI, dont le cycle de vie est détaché de celui de la GRC, et qui s'appuie sur trois blocs existants ou à construire : l'IA, le CRM et le métier.

État actuel : ce qui tourne aujourd'hui est un prototype — moteur d'analyse bouchonné, garde-fou par domaine de messagerie, hébergement hors socle. Le schéma ci-dessous décrit la cible, pas l'existant.

1. La proposition en une image

Le complément ne connaît qu'une seule adresse. Les trois blocs ne connaissent qu'un seul appelant. C'est ce double découplage qui rend le complément remplaçable.

2. Le complément n'appelle qu'`assistant-mail-service`

C'est le choix structurant, et il est arrêté : le complément ne s'adresse jamais directement à l'IA, au CRM ou au métier. Il ne connaît qu'une seule adresse. La comparaison ci-dessous n'est pas une question ouverte — elle est là pour montrer au comité que l'alternative a été examinée, et pourquoi elle a été écartée.

Le paradoxe des appels directs : plus le complément parle directement aux blocs, moins il est remplaçable — parce qu'il devient le seul endroit où l'enchaînement est écrit.

Décision retenue

Le complément passe par assistant-mail-service, et par lui seul. L'objectif porté — une application autonome et facilement remplaçable — est précisément ce qui l'impose. Un complément Outlook est la pièce la moins maîtrisable de la chaîne : il s'exécute chez l'utilisateur, dans un moteur imposé par Microsoft, avec des versions que l'on ne force pas. Tout ce qui compte doit donc se trouver derrière lui, pas dedans.

Ce choix ne crée rien d'exotique : il reprend le patron déjà en place au MDPA, un *-service dans le socle et son *-service-client publié sur Nexus. grc-service et grc-service-client en sont l'exemple.

Il prend un relief particulier avec la migration de la messagerie : au passage d'Exchange on-premises à Exchange Online, c'est le mode d'authentification qui change (§ 4). Parce que la vérification d'identité vit dans le service, cette migration touche un seul composant au lieu de se propager à tout ce qui appelle le SI.

3. Ce que le découplage achète concrètement

Un cycle de vie propre

Le complément se livre sans release de la GRC, sans redémarrage de Tomcat, sans fenêtre de déploiement partagée. Une correction d'affichage part le jour même.

Un client jetable

Si Microsoft change son modèle de compléments, on réécrit un volet contre un contrat inchangé. Ce n'est pas théorique : la migration vers Exchange Online éteindra le mode d'authentification actuel. Le travail métier, lui, sera préservé.

Une porte, pas trois

Les blocs IA, CRM et métier n'ont qu'un appelant à connaître, à autoriser et à surveiller. Le jour où le modèle d'IA change, un seul composant bouge.

Une trace unique

Qui a poussé quel message, quand, et ce que le modèle a répondu : la question se pose à un seul endroit. Impossible à tenir si trois blocs sont appelés séparément.

4. L'identité : deux âges de la messagerie, une seule couture

La messagerie est aujourd'hui en Exchange on-premises et migrera vers Exchange Online. Ce n'est pas un détail d'exploitation : les deux mondes n'offrent pas le même moyen de prouver qui est l'utilisateur, et le mécanisme d'aujourd'hui sera éteint par la migration. L'architecture doit donc porter la bascule dès maintenant, sans attendre la date.

Le complément change de source de jeton ; le service change de vérificateur. Le reste de la chaîne — résolution de l'acteur, appels aux trois blocs — ne bouge pas.

Dans les deux cas, l'enchaînement est le même :

Le complément obtient un jeton attestant de l'utilisateur connecté à Outlook. Aucune saisie, aucune fenêtre.
assistant-mail-service vérifie ce jeton auprès de l'autorité qui l'a émis — le serveur Exchange aujourd'hui, Entra ID demain.
Il résout l'acteur correspondant dans le SI et obtient le jeton interne attendu par le socle.
Les appels aux trois blocs partent avec cette identité-là. Le complément n'a jamais vu le jeton interne.

Ce que la situation on-premises change — en mieux

Microsoft documente explicitement le jeton d'identité Exchange pour trois cas, dont deux décrivent la situation du MDPA mot pour mot : « uniquement lorsque le complément est utilisé par des utilisateurs Exchange on-premises » et « lorsque le complément a besoin d'accéder à un service non-Microsoft que vous contrôlez ». C'est très exactement assistant-mail-service.

Conséquence pratique : une authentification véritable est possible tout de suite, sans attendre la moindre inscription d'application. Ce jeton est signé par le serveur Exchange et se vérifie côté service — ce n'est pas le garde-fou déclaratif du prototype, c'est une preuve. Le chantier Entra ID devient une échéance de migration, pas un préalable.

Le point de non-retour. Le jeton d'identité Exchange a été coupé par Microsoft sur Exchange Online : il n'y survivra pas. Le jour de la bascule, un complément qui ne sait faire que cela cesse de s'authentifier. La vérification d'identité doit donc être écrite derrière une abstraction, avec deux implémentations, dès la première version — et l'inscription d'application Microsoft 365 doit être demandée avant la migration, pas après.

Deux autres effets de la bascule, à noter au dossier : le déploiement du complément est administré côté Exchange aujourd'hui, côté Microsoft 365 ensuite — c'est aussi par là que se restreint qui y a droit ; et le manifest XML retenu fonctionne dans les deux mondes, là où le manifest unifié au format JSON est réservé à Microsoft 365. Rester en XML est le choix qui traverse la migration.

5. Exposition et sécurité des échanges

Outlook impose HTTPS (TLS 1.2 ou supérieur) pour toutes les ressources d'un complément — la page du volet comme les appels qu'elle passe. Les échanges sont donc chiffrés, et ce n'est même pas une option : sans cela, le complément ne fonctionne pas.

Mais TLS protège le canal, pas l'accès. C'est une porte blindée sans contrôle de badge : personne ne lit ce qui passe, n'importe qui peut frapper. Ce qui décide de laisser entrer, c'est la vérification d'identité du § 4 — et elle seule.

La question « faut-il l'exposer » ne se pose pas comme un choix

Le volet s'exécute sur le poste de l'utilisateur, dans un webview : c'est un client web. Le service doit donc être joignable depuis là où se trouve l'utilisateur — et cela vaut pour la page du volet autant que pour l'API. Ce n'est pas une décision d'architecture libre, c'est une conséquence de la population desservie.

Vous êtes aujourd'hui en phase 1, et la messagerie on-premises vous y maintient. La phase 2 arrive avec la migration vers Exchange Online : même échéance, même dossier. Aucune raison de payer aujourd'hui la complexité de demain.

Ce service n'est pas un service exposé ordinaire

Quatre propriétés lui sont propres, et méritent d'être posées avant l'ouverture.

C'est un pont à travers le périmètre

Il détient de quoi se présenter au socle : la résolution de l'acteur et le jeton interne. Le compromettre ne donne pas accès à un service, cela donne un pied vers grc-service et les microservices métier. C'est le seul composant du schéma qui touche les deux côtés.

C'est un relais vers un modèle payant

Ouvert sans authentification, il devient un proxy d'IA gratuit pour qui trouve l'adresse. Le préjudice est financier avant d'être technique, et il se constate sur la facture, pas dans les journaux.

Il transporte des données sensibles

Hospitalisation, optique, dentaire, sinistres corporels : le courrier d'une mutuelle comporte des données de santé. Sous cette hypothèse — à confirmer sur le trafic réel — on relève de l'article 9 du RGPD, et la discussion change de nature.

L'entrée est hostile par construction

Le contenu d'un mail est écrit par un tiers. Quand le service créera des interactions, un message rédigé exprès pourra tenter d'orienter le modèle. La parade est architecturale : le modèle propose, l'agent valide.

Ce qui sécurise réellement, par ordre de valeur

L'identité vérifiée côté service. C'est le verrou ; tout le reste est secondaire. Jeton d'identité Exchange aujourd'hui, Entra ID après la migration (§ 4).
Un reverse proxy ou WAF en DMZ, avec seulement les chemins utiles publiés. Le service lui-même reste dans le réseau interne — jamais directement sur internet.
Un flux à sens unique. Le service appelle les blocs ; aucun bloc ne l'appelle. Il n'existe aucune route entrante depuis internet vers le SI hormis celle-là.
Des quotas par utilisateur et une journalisation. Contre l'abus, et pour pouvoir répondre à « qui a poussé quel message, et quand ».
Minimiser ce qui sort. Le service n'envoie au modèle que le nécessaire, et peut caviarder les identifiants avant l'appel. Le prototype sait déjà repérer IBAN, numéro de sécurité sociale et numéros de contrat : les masquer coûterait presque rien, et devient déterminant si le modèle est hébergé à l'extérieur.

Fausses pistes à écarter en séance. Le CORS protège les navigateurs, pas le serveur — ce n'est pas un contrôle d'accès. Un secret placé dans le code du volet est téléchargeable par tout le monde. Le filtrage par adresse IP casse le mobile et le télétravail, c'est-à-dire précisément les cas qui motivaient l'ouverture. Et l'obscurité d'une URL n'a jamais protégé personne.

6. La question de confidentialité, posée clairement

Un assistant de messagerie fait sortir le contenu de mails de sociétaires de son application d'origine. Le schéma rend cette sortie visible, et c'est volontaire : le comité doit pouvoir dire où s'arrête le périmètre.

Le complément ne transmet qu'un message à la fois, à la demande explicite d'un agent.
Le service ne conserve rien : il relaie, il ne stocke pas.
Reste à trancher : où s'exécute le modèle. Un modèle hébergé au MDPA ou chez un fournisseur sous contrat ne pose pas les mêmes questions qu'une API publique. C'est cette décision, et non la technique du complément, qui détermine ce que l'on a le droit de pousser.

7. Le bloc CRM sait déjà recevoir ce que le complément produit

Point vérifié dans grc-service-client : la création d'interaction n'est pas à construire, elle est exposée. IGrcService (@Path("/grc")) offre notamment :

POST /grc/creer/interaction-grc — prend un InteractionDTO, rend l'identifiant créé ; variante /groupe-emetteur pour préciser l'émetteur.
POST /grc/creer/echange/sous-type-activite — dont les paramètres sont, mot pour mot, ce que le complément produit : sujet, message, sousTypeActivite, codePriorite, nso, destinataire, codeSousAgence, loginUtilisateur, externalID, reponseObligatoire, idTechniqueSinistre.
POST /grc/creer/emailsortant pour tracer une réponse, et POST /grc/modifier/interaction-grc/{id}/etat/{etat} pour la suite de vie.
GET /grc/get/interactions?nso=… pour rattacher le message à l'historique existant du sociétaire.

Le InteractionDTO accueille l'intégralité de la sortie de l'analyse : codeSousTypeActivite pour la qualification, codePriorite pour la priorité, compteRendu pour le résumé, messageSubject / messageBody / messageHTML pour le mail lui-même, listeNSOSocietaire et listeIdPersonne pour le rattachement, et fichiersAttaches pour les pièces jointes.

Nuance à ne pas masquer au comité. grc-service réutilise les DTO du progiciel — InteractionDTO vient de com.edeal.frontline.mdpacustom.webservices.server.dto. C'est donc une façade REST devant la GRC, pas un système indépendant : elle en suit les évolutions et en partage la disponibilité. Cela ne change rien à la décision — c'est la bonne porte — mais le « bloc CRM » du schéma est bien une porte, pas une couche d'isolation.

8. Ce qui existe, ce qui reste à faire

Élément	État	Commentaire
Bloc métier — microservices `fr.mdpa.ms`	Existe	Sociétaire, contrat, sinistre, GED, acteur, droit. Clients Nexus par domaine.
Bloc CRM — `grc-service`	Existe	Déjà exposé en REST dans le socle. Sert les sous-types d'échange (`/echange-viseo/sous-type/…`, que le prototype embarque encore en dur) et la création d'interaction (§ 6).
Complément Outlook	Prototype	Volet fonctionnel, manifest installable, garde-fou par domaine. À réécrire contre le contrat définitif.
`assistant-mail-service`	Embryon	Le serveur du prototype en tient déjà le rôle et fige le contrat d'API. À reprendre aux normes du socle.
Authentification — jeton d'identité Exchange	Faisable tout de suite	Supporté en Exchange on-premises, vérifiable côté service. Ne dépend d'aucun prérequis externe.
Authentification — jeton Entra ID	Avant la migration	Obligatoire dès le passage en Exchange Online, où le jeton précédent est coupé. Suppose une inscription d'application côté administrateur Microsoft 365.
Bloc IA	À construire	Rien d'équivalent dans le SI aujourd'hui. C'est la décision structurante.

9. Ce que l'on demande au comité

Valider le principe d'une application distincte, avec son service dédié, plutôt qu'une fonctionnalité de plus dans la GRC.
Désigner le bloc IA : quel modèle, hébergé où, sous quel contrat. C'est le seul vrai manque du schéma, et la décision dépasse ce projet.
Arbitrer le périmètre de sortie des données : quels messages ont le droit d'être poussés vers le modèle, et lesquels non.
Valider le schéma d'exposition (§ 5) : phase 1 entièrement interne, phase 2 derrière un reverse proxy en DMZ, le service n'étant jamais publié directement.
Caler le calendrier sur celui de la migration de la messagerie. La première version s'authentifie avec le jeton Exchange on-premises ; l'inscription d'application Microsoft 365 doit être obtenue avant la bascule, sous peine de rupture d'authentification le jour J.
Confirmer le rattachement du service aux conventions du socle : nommage, dépôt, publication du client sur Nexus, supervision.

À noter qu'aucune de ces cinq demandes ne bloque le démarrage : le bloc CRM et le bloc métier existent, et l'authentification du premier âge ne dépend de personne d'autre que l'équipe.

Prototype et code : page du complément · volet en démonstration