Dispatch d'emails dans un outil de gestion de projet
Comment une équipe a transformé sa boîte mail en file de tâches structurées — sans changer ses habitudes d'envoi, et sans validation manuelle systématique.
Contexte
Utilisateur d'un outil de gestion de projet interne. Les collaborateurs continuent d'envoyer et de recevoir des emails comme partout ailleurs — mais une fois reçu, chaque email pertinent doit être analysé, affecté au bon projet, et transformé en une ou plusieurs tâches priorisées. Ce travail manuel est chronophage, inégalement effectué selon les profils, et particulièrement coûteux sur les emails contenant plusieurs demandes à découper.
Le problème
- Tri manuel des emails entrants : projet ? priorité ? acteur ? — décisions répétitives toute la journée.
- Tâches qui passent à la trappe parce que l'email a été archivé sans être traité.
- Asymétrie d'usage : ceux qui maîtrisent l'outil l'utilisent bien, les autres reviennent à la boîte mail et le suivi se perd.
- Sur les emails complexes contenant plusieurs demandes, jusqu'à 10 minutes passées à découper le message en tâches distinctes.
Ce qu'on a livré
Sur transfert d'un email vers une adresse dédiée (du type task-<token>@projets.<domaine>), Claude l'analyse en une seule passe, identifie le projet concerné, isole les actions demandées et crée les tâches dans l'outil avec une priorisation cohérente. L'utilisateur ne change rien à son flux email ; le travail de tri se fait en arrière-plan. Les pièces jointes (PDF, images, captures d'écran) sont traitées et intégrées directement dans les tâches créées. En cas d'ambiguïté, l'IA n'invente pas : elle envoie l'email en file « À revoir » avec la raison explicite de son hésitation, pour que l'humain tranche.
Comment c'est construit.
- Modèle IA
Claude Haiku par défaut, Sonnet en escalade
Haiku traite l'écrasante majorité des emails entrants : rapide, économique, idéal sur un flux à fort volume. Quand le contenu est ambigu ou que la sortie ne satisfait pas le contrôle de cohérence, le système escalade automatiquement vers Sonnet pour une analyse plus poussée. Cette logique de routage cost-aware garde une facture Claude raisonnable tout en garantissant la qualité sur les cas complexes.
- Réception
Mailgun + webhook, pas d'IMAP
Chaque utilisateur dispose d'une adresse dédiée du type task-<token>@projets.<domaine>. Le token sert d'authentification implicite. Mailgun reçoit l'email, parse, et déclenche un webhook vers l'applicatif Rails. Pas de polling IMAP, pas de boîte mail intermédiaire à surveiller — c'est instantané et fiable.
- Prompt
Structured output JSON, single-pass
L'email entier est envoyé à Claude avec un prompt soigné et un schéma JSON très précis qui définit la sortie attendue : projet identifié, liste de tâches, priorité, métadonnées. Une seule passe suffit : le modèle classe, extrait, et structure en un seul appel. Pas d'étapes successives, pas de chaîne d'appels — c'est ce qui rend le système rapide et prévisible.
- Contexte
Liste des projets + domaines clients
À chaque appel, Claude reçoit en contexte la liste des projets actifs de l'utilisateur et les domaines des clients associés. Cette information de contexte est ce qui permet d'affecter un email au bon projet même quand le titre du mail est ambigu — un email envoyé depuis marie@société-X.fr est automatiquement orienté vers le projet lié à ce client.
- Stack back
Ruby on Rails + ruby_llm, Go en renfort
Backend principal en Ruby on Rails, avec la librairie ruby_llm pour orchestrer les appels Claude — excellente sur la gestion des outils, des prompts et du streaming. Pour les composants à fort asynchronisme et concurrence (traitement de pièces jointes, file de jobs), un backend Go dédié prend le relais — plus rapide que Ruby sur ce profil de charge. La transcription audio, utilisée chez d'autres clients, repose sur Mistral, mieux calibré pour le français.
Là où on a galéré.
Atteindre la précision « zéro retri côté utilisateur »
L'essentiel de l'effort technique est passé sur les prompts et le schéma JSON de sortie. La précision n'est pas un bouton qu'on tourne : c'est des dizaines de cycles de tests sur des emails réels, à ajuster la formulation du prompt, à enrichir les exemples in-context, à raffiner les types JSON pour qu'aucun champ ne soit mal interprété. L'objectif n'est pas seulement « ça marche » — c'est « l'utilisateur n'a rien à retoucher derrière ». Chaque manipulation manuelle coûte du temps gagné, donc on a itéré jusqu'à ce qu'elles deviennent l'exception.
Pièces jointes et images traitées au passage
Beaucoup d'emails métier arrivent avec des PDF, des photos, des captures d'écran. Plutôt que de les ignorer, on les traite : extraction du contenu utile, intégration dans les tâches créées, lien clair entre la tâche et la pièce jointe d'origine. Quand c'est pertinent, Claude analyse directement les images — un screenshot d'erreur devient une description de bug dans la tâche, sans étape intermédiaire.
Différenciation UI tâche IA / tâche humaine
Piège classique de ces systèmes : l'utilisateur perd la trace de ce qui a été créé automatiquement vs manuellement, et l'IA devient une couche opaque. Côté UX, chaque tâche dispatchée par l'IA reste visuellement distincte d'une tâche créée à la main : badge, marquage source, accès à l'email original en un clic. La transparence sur l'origine d'une donnée est ce qui fait que l'utilisateur garde confiance dans le système.
Mesures à J+30
+43 %
Temps gagné
Mesure validée client. Sur les emails complexes contenant plusieurs demandes, le temps de création d'une tâche est passé d'une dizaine de minutes à zéro.
—
Emails dispatchés / jour
Mesures en cours de consolidation avec le client.
—
Précision affectation
Mesures en cours de consolidation avec le client.
Ce qu'on referait, ce qu'on changerait.
À refaire pareil
- Combinaison Haiku par défaut + Sonnet en escalade — équilibre coût/qualité optimal.
- Ne rien changer au flux email côté utilisateurs — l'adoption a été immédiate.
- Mailgun + webhook plutôt que polling IMAP — instantané et fiable.
- Pattern single-pass avec structured output — plus simple à maintenir que des chaînes d'appels.
- Donner les domaines clients en contexte à Claude — clé de la précision d'affectation.
Ce qu'on changerait
- Mettre en place dès le départ un dashboard interne de monitoring des appels Claude (latence, coût, taux d'escalade Sonnet) — on l'a ajouté en cours de route, c'est utile dès le jour 1.
- Documenter les exemples de prompts gagnants plus tôt — quelques itérations auraient été plus rapides avec un fichier de cas tests référence.
Durée et budget
Projet livré en 4 semaines. Budget 5,5 k€ HT, dans la fourchette basse parce qu'on a réutilisé l'API existante de l'outil de gestion plutôt que d'en construire une nouvelle. Pas de changement d'UX côté utilisateurs — l'adoption a été immédiate, exactement ce qu'on visait. Sur les emails complexes contenant plusieurs demandes, le temps de création d'une tâche est passé d'une dizaine de minutes à zéro : l'IA découpe et structure pendant que l'humain est libre de continuer son travail.
Un projet similaire chez vous ?
Décrivez-nous votre processus, on revient sous 48 h avec une première lecture honnête.