Ce que fait l’IA
Elle lit le contexte d’un message ouvert (sujet, expéditeur, contenu) et propose des aides concrètes : résumé, brouillon de réponse, suggestion d’événement, idée de classement. Elle propose — elle n’exécute pas.
Maillard-Dev
Des agents IA pour vos mails,
hébergés chez vous.
Nous concevons des assistants de messagerie basés sur des LLM auto-hébergés : vos données restent sur votre infrastructure, et aucune action n’est exécutée sans validation humaine.
En clair — c’est quoi ?
Pour tout le monde
Un assistant pour vos e-mails, installé chez vous, qui propose des idées mais attend toujours votre feu vert.
Pour les informaticiens
Agent messagerie + LLM self-hosted + human-in-the-loop ; données et inférence dans votre trust boundary.
Le projet
Quel est le but ?
Réduire le temps passé sur les tâches administratives liées aux e-mails, sans confier vos contenus à une IA cloud tierce, et sans laisser une machine agir à votre place.
Ce que garde l’humain
Chaque proposition passe par un circuit approuver / modifier / rejeter. Tant qu’un collaborateur n’a pas validé, aucune action sortante (envoi, déplacement, création d’événement) n’est déclenchée.
Ce que change l’auto-hébergement
Le modèle de langage (LLM) tourne sur votre serveur (ou celui que vous contrôlez). Les mails ne partent pas vers une API IA publique pour le traitement métier. C’est le cœur de l’offre Maillard-Dev.
En clair — c’est quoi cette section ?
Pour tout le monde
Imaginez un assistant qui lit un mail et vous propose quoi faire — comme un collègue expérimenté. Il ne clique jamais à votre place. Et au lieu d’envoyer le mail à une IA « dans le cloud » d’une grosse entreprise, le cerveau tourne sur votre ordinateur serveur.
Pour les informaticiens
Copilote messagerie avec LLM self-hosted, human-in-the-loop obligatoire, et séparation claire entre génération (inférence) et side-effects (API messagerie / calendrier après ack utilisateur).
Architecture
Comment ça fonctionne
Une chaîne simple, volontairement claire : la messagerie, un panneau d’assistant, une API centrale, un moteur LLM interne, et l’exécution uniquement après validation.
Le LLM n’appelle jamais directement la messagerie pour exécuter. Seule l’API, après un clic humain, déclenche une action réelle.
-
1
Ouverture du contexte
L’utilisateur ouvre un mail et lance l’assistant. Le panneau récupère le contexte nécessaire (pas toute la boîte par défaut).
-
2
Proposition par le LLM
L’API envoie ce contexte au moteur auto-hébergé. Le modèle renvoie une proposition structurée (résumé, brouillon, calendrier, classement…).
-
3
Décision humaine
L’utilisateur lit, corrige si besoin, puis approuve ou rejette. Sans cette étape, le flux s’arrête.
-
4
Exécution contrôlée
Si approuvé, l’API exécute uniquement l’action validée via les connecteurs autorisés (par ex. API de messagerie / calendrier).
En clair — c’est quoi cette section ?
Pour tout le monde
Le parcours est toujours le même : vous ouvrez un mail → l’assistant propose → vous dites oui / non / je corrige → seulement après, quelque chose se passe vraiment. L’IA est un conseiller, pas un robot autonome.
Pour les informaticiens
Pipeline : client messagerie → task pane → API HTTPS authentifiée → runtime LLM (ex. Ollama en localhost) → retour proposition → commit d’action via connecteurs uniquement après validation explicite. Pas d’appel direct LLM → Graph / SMTP.
Gestion des données
Où vont vos informations ?
Pour un client, la question n’est pas seulement « est-ce que ça marche ? », c’est « qui voit mes mails ? ». Voici le modèle Maillard-Dev, expliqué sans jargon inutile.
Ce que nous recommandons de clarifier avec vous
- Transit : le contenu traverse l’API le temps de la génération, en HTTPS.
- Stockage : faut-il zéro conservation du corps du mail, une fenêtre courte, ou un journal d’audit ?
- Logs : métadonnées (qui a validé quoi, quand) vs contenu sensible.
- Accès : qui peut administrer le serveur LLM, qui voit les logs, combien de temps.
Ce que le client doit retenir
L’auto-hébergement n’est pas une magie de confidentialité absolue : c’est un changement de responsabilité. Au lieu de déléguer le traitement à un fournisseur IA externe, vous (ou votre hébergeur) contrôlez le serveur, les accès et la politique de rétention.
Maillard-Dev aide à poser cette politique clairement, puis à l’implémenter techniquement.
En clair — c’est quoi cette section ?
Pour tout le monde
Vos mails ne partent pas « chez ChatGPT ». Ils restent dans un cercle que vous contrôlez (votre entreprise / votre hébergeur). Mais attention : contrôler veut aussi dire être responsable — comme avoir un coffre chez soi plutôt qu’à la banque.
Pour les informaticiens
Data residency & trust boundary : inférence on-prem / VPS dédié, pas d’exfiltration vers API LLM SaaS pour le workload métier. Politique de rétention (éphémère vs audit logs) à contractualiser ; secrets et accès admin du runtime LLM = surface à durcir (bind localhost, reverse proxy, IAM).
Transparence
Avantages & inconvénients
Un projet sérieux montre aussi ses limites. Voici une lecture honnête pour décider en connaissance de cause.
Avantages
- Maîtrise des données — le traitement LLM reste dans votre périmètre ; pas d’envoi métier vers une IA cloud tierce.
- Contrôle humain — aucune action automatique sortante : idéal pour des organisations régulées ou prudentes.
- Alignement conformité — plus simple d’expliquer à un DPO / RSSI « où circule le mail » et « qui valide ».
- Personnalisation — agents et instructions adaptés à vos process (ton, formats, règles métier), sans dépendre d’un prompt générique cloud.
- Indépendance fournisseur IA — vous n’êtes pas liés aux changements de prix / conditions d’une API externe pour le cœur du produit.
- Auditabilité — on peut journaliser les propositions et validations (métadonnées) pour la gouvernance.
Inconvénients
- Charge d’exploitation — serveur, mises à jour, monitoring, sauvegardes : vous (ou un partenaire) devez les assumer.
- Qualité / latence du modèle — un petit modèle CPU est économique mais moins fluide / précis qu’un grand modèle cloud.
- Coût d’infra — l’auto-hébergement n’est pas « gratuit » : VPS, GPU éventuel, temps d’admin.
- Responsabilité accrue — une faille sur votre serveur est votre risque ; il faut durcir l’accès (LLM non exposé, HTTPS, auth).
- Montée en charge — beaucoup d’utilisateurs simultanés demande du dimensionnement (files d’attente, instances).
- Pas un remplacement humain — l’outil accélère l’administratif ; il ne décide pas à la place d’un expert métier ou réglementaire.
En clair — c’est quoi cette section ?
Pour tout le monde
Le pour : plus de contrôle et de confiance sur vos données. Le contre : ce n’est pas « magique et gratuit » — il faut un serveur, de l’entretien, et parfois l’IA est un peu moins rapide ou moins « brillante » qu’un service cloud géant. On vous dit les deux pour que vous choisissiez en connaissance de cause.
Pour les informaticiens
Trade-off classique self-host vs managed LLM API : contrôle / conformité / vendor independence d’un côté ; ops burden, capacity planning, qualité modèle et latence CPU de l’autre. Human-in-the-loop réduit le risque opérationnel mais n’élimine pas le besoin de hardening infra.
Sécurité
Principes que nous appliquons
Ces règles sont le socle technique et organisationnel du projet. Elles doivent être compréhensibles pour un décideur non technique.
Moindre privilège
L’assistant ne demande que les droits nécessaires aux actions prévues. Pas de compte « dieu », pas d’accès à toute la boîte sans besoin métier.
Séparation des rôles
Le LLM génère du texte / des propositions. L’API orchestre. Le connecteur messagerie exécute. L’humain décide. Aucun de ces rôles ne doit tout faire seul.
Traçabilité
On peut enregistrer qui a demandé quoi, quelle proposition a été faite, et si elle a été approuvée ou rejetée — sans pour autant stocker inutilement le corps des mails.
En clair — c’est quoi cette section ?
Pour tout le monde
On empile plusieurs verrous : la personne est bien connectée, la connexion est chiffrée, le serveur vérifie qui appelle, le cerveau IA n’est pas ouvert à tout Internet, et rien d’important ne se fait sans un « oui » humain. Comme plusieurs portes avant le coffre.
Pour les informaticiens
Defense in depth : authN messagerie, TLS, API keys / OAuth + CORS allowlist, least-privilege scopes, LLM non routable publiquement, audit trail des décisions. Séparation génération / exécution pour limiter blast radius d’une hallucination ou d’un prompt injection.
Cible
Pour qui est-ce fait ?
Organisations sensibles
Assurance, finance, santé, administration, ou toute structure où les e-mails contiennent des données clients / internes à protéger.
Équipes admin-lourdes
Beaucoup de mails répétitifs (demandes, paperasse, prise de rendez-vous) où un assistant accélère sans supprimer le contrôle.
Décideurs qui veulent de la clarté
Direction, IT, conformité : besoin d’un discours simple sur le flux, les risques, et ce qui est volontairement hors scope (ex. envoi automatique sans clic).
En clair — c’est quoi cette section ?
Pour tout le monde
Ce projet s’adresse surtout aux entreprises qui ont beaucoup de mails sensibles ou répétitifs, et qui veulent gagner du temps sans perdre le contrôle. Ce n’est pas un jouet « IA qui envoie tout seule ».
Pour les informaticiens
Fit produit : organisations regulated / data-sensitive, workloads mail à fort volume administratif, stakeholders IT + conformité. Hors scope volontaire : automation totale, remplacement décisionnel métier, app native mobile dédiée.