Concevez et développez une application web pour créer des campagnes e‑mail, envoyer de manière sûre, suivre les événements et améliorer la délivrabilité avec authentification, listes de suppression et monitoring.
Avant de choisir un fournisseur, concevoir votre base de données ou construire une file d'envoi, définissez ce que signifie « succès » pour votre application de gestion de campagnes e-mail. Un périmètre clair maintient le produit utile pour les marketeurs et sûr pour la délivrabilité.
Au minimum, l'application doit permettre à une équipe de créer, planifier, envoyer et analyser des campagnes e-mail tout en appliquant des garde-fous qui empêchent les mauvais comportements d'envoi (envois massifs accidentels, ignorance des opt-outs, ou envois répétés vers des adresses qui rebondissent).
Considérez le résultat comme : délivrabilité fiable + rapports dignes de confiance + conformité cohérente.
Votre périmètre doit inclure (ou exclure) explicitement ces flux, car ils ont des besoins de contenu, une cadence et des risques différents :
Si vous prenez en charge plusieurs types, décidez tôt s'ils partagent la même identité d'expéditeur et les mêmes règles de suppression — ou s'ils nécessitent des configurations séparées.
Définissez les permissions en termes simples pour éviter que les équipes ne se chevauchent :
Évitez de ne suivre que des métriques de vanité. Suivez un petit ensemble reflétant la délivrabilité et l'impact business :
Consignez vos limites maintenant :
Un livrable pratique ici est un « contrat produit » d'une page qui indique pour qui l'app est, quels types de messages elle envoie, et quelles métriques définissent le succès.
Avant de dessiner des boîtes sur un diagramme, décidez ce que vous construisez réellement : un gestionnaire de campagnes (UI + planification + reporting) ou un système de livraison d'e-mails (responsabilité au niveau MTA). La plupart des équipes réussissent en construisant l'expérience produit et en intégrant une infrastructure spécialisée.
Envoi : Utilisez une API e-mail/SMTP (SES, Mailgun, SendGrid, Postmark, etc.) à moins d'avoir une équipe dédiée à la délivrabilité. Les fournisseurs gèrent la réputation IP, les boucles de rétroaction, les outils de warm-up et les flux d'événements webhook.
Suivi des liens & analytics : Beaucoup de fournisseurs offrent le tracking clic/ouverture, mais vous pouvez vouloir votre propre domaine de redirection et des logs de clics pour des rapports cohérents entre fournisseurs. Si vous construisez le tracking, gardez-le minimal : un service de redirection + ingestion d'événements.
Templates : Construisez le workflow d'édition, mais envisagez d'intégrer un éditeur HTML e-mail mature (ou au moins un rendu MJML). Le HTML e-mail est exigeant ; externaliser l'éditeur réduit la charge de support.
Pour un MVP, un monolithe modulaire fonctionne bien :
Scindez en services plus tard uniquement si l'échelle ou la structure organisationnelle l'exige (par ex. service de tracking dédié ou ingestion webhook dédiée).
Utilisez une base relationnelle comme système d'enregistrement pour les tenants, utilisateurs, audiences, campagnes, templates, plannings et état de suppression.
Pour l'envoi et le suivi des événements, prévoyez un journal d'événements en append-only (ex. table partitionnée par jour, ou système de log). L'objectif est d'ingérer des événements à fort volume sans ralentir les opérations CRUD principales.
Si vous prenez en charge plusieurs marques/clients, définissez la multi‑tenancy tôt : accès aux données scindé par tenant, domaines d'envoi par tenant, règles de suppression par tenant. Même si vous débutez mono‑tenant, concevez le schéma pour ajouter un tenant_id plus tard sans réécriture majeure.
Si votre objectif principal est de livrer rapidement un gestionnaire de campagnes fonctionnel (UI, base, workers, endpoints webhook), une plateforme de prototypage peut aider à itérer plus vite tout en gardant le contrôle de l'architecture. Par exemple, Koder.ai permet de prototyper et d'exporter une app React + backend Go/Postgres.
Ceci est utile pour construire les parties « glue » — UI admin, CRUD segmentation, jobs d'envoi via queue, ingestion webhook — tout en continuant à s'appuyer sur un fournisseur spécialisé pour l'envoi critique à la délivrabilité.
Un modèle de données clair fait la différence entre « on a envoyé un e-mail » et « on peut expliquer exactement ce qui est arrivé, à qui et pourquoi ». Vous voulez des entités qui supportent la segmentation, la conformité et un traitement d'événements fiable — sans vous enfermer.
À minima, modélisez ces tables/collections en tant que ressources de première classe :
Un pattern commun est : Workspace → Audience → Contact, et Campaign → Send → Event, avec Send référant aussi l'instantané d'audience/segment utilisé.
Champs recommandés pour les contacts :
email (normalisé + en minuscules), plus name optionnelstatus (ex. active, unsubscribed, bounced, complained, blocked)source (import, API, nom du formulaire, intégration)consent (plus qu'un booléen) : stockez consent_status, consent_timestamp, consent_sourceattributes (JSON/champs personnalisés pour segmentation : plan, ville, tags)created_at, updated_at, idéalement last_seen_at / last_engaged_atÉvitez de supprimer les contacts pour « propreté ». Changez plutôt leur statut et conservez l'enregistrement pour la conformité et les rapports.
Pour les campagnes, suivez :
subject, from_name, from_email, reply_totemplate_version (référence immuable à un snapshot)tracking_options (suivi ouverture/clic activé/désactivé, UTM par défaut)Puis utilisez un enregistrement send pour les détails opérationnels :
scheduled_at, started_at, completed_atStockez les événements en stream append-only avec une forme cohérente :
event_type : delivered, opened, clicked, bounced, complained, unsubscribedsend_id, contact_id (et optionnellement message_id)Pour les objets clés (contacts, campagnes, segments), ajoutez created_by, updated_by, et envisagez une petite table de log de changements capturant qui a changé quoi, quand, et les valeurs avant/après. Cela facilite grandement le support, les demandes de conformité et les enquêtes sur la délivrabilité.
La gestion des audiences est l'endroit où une app de campagnes e-mail gagne la confiance — ou crée des problèmes. Traitez les contacts comme des enregistrements de longue durée avec des règles claires sur leur ajout, mise à jour et droit à recevoir des messages.
L'import CSV doit être simple pour les utilisateurs, mais strict en interne.
Validez les champs requis (au moins l'e-mail), normalisez la casse/espaces, et rejetez les adresses manifestement invalides. Ajoutez des règles de déduplication (typiquement par email normalisé) et décidez du comportement en cas de conflit : écraser uniquement les champs vides, toujours écraser, ou « demander à l'import ».
Le mapping des champs est important car les tableurs réels sont désordonnés (« First Name », « fname », « Given name »). Permettez aux utilisateurs d'associer les colonnes aux champs connus et de créer des champs personnalisés si nécessaire.
La segmentation fonctionne mieux comme des règles sauvegardées qui se mettent à jour automatiquement. Supportez des filtres basés sur :
Rendez les segments explicables : montrez un compte prévisionnel et un drill-down « pourquoi inclus » pour un échantillon de contacts.
Stockez le consentement comme première classe : statut (opté-in, opté-out), timestamp, source (formulaire, import, API) et, si pertinent, à quelle liste ou finalité il s'applique.
Votre centre de préférences doit permettre d'opter pour des catégories spécifiques tout en restant inscrit à d'autres, et chaque changement doit être traçable. Liez ce flux de préférence à /blog/compliance-unsubscribe si vous traitez le sujet ailleurs.
Les noms et adresses ne sont pas universels. Supportez Unicode, des champs nom flexibles, des formats d'adresse selon le pays, et un fuseau horaire au niveau du contact pour la planification des envois « 9am local time ».
Avant d'enqûeter les destinataires, filtrez pour n'inclure que les contacts éligibles : non désinscrits, non sur listes de suppression, et avec un consentement valide pour ce type de message. Affichez la règle dans l'UI pour que les utilisateurs comprennent pourquoi certains contacts ne recevront pas la campagne.
Une pipeline d'envoi peut être parfaite et sous‑performer si le contenu est difficile à lire, incohérent ou manque d'éléments obligatoires. Traitez la composition comme une fonctionnalité produit : elle doit rendre le « bon e-mail » par défaut.
Commencez par un système de templates construit à partir de blocs réutilisables — header, hero, texte, bouton, grille produit, footer — afin que les campagnes restent cohérentes entre équipes.
Ajoutez le versioning pour les templates et blocs. Les éditeurs doivent pouvoir :
Incluez des envois de test à deux niveaux : envoyer un template à soi-même avant de l'attacher à une campagne, et envoyer un brouillon de campagne à une petite liste interne avant la planification.
La plupart des apps adoptent plusieurs modes d'édition :
Quelle que soit l'option, stockez la « source » (HTML/Markdown/JSON blocs) et le HTML rendu séparément afin de pouvoir régénérer après corrections de bugs.
Fournissez des aperçus pour les points de rupture courants (desktop/mobile) et les principales particularités clients. Même des outils simples aident : bascules de viewport, simulation dark-mode, option « afficher bordures de tableaux ».
Générez toujours et permettez d'éditer une version texte. Elle est utile pour l'accessibilité, réduit les frictions avec certains filtres anti‑spam et améliore la lisibilité pour les utilisateurs qui préfèrent le texte seul.
Si vous suivez les clics, réécrivez les liens de façon lisible (conservez les paramètres UTM et montrez la destination au survol). Gardez les liens internes relatifs dans votre UI (ex. lien vers /blog/template-guide).
Avant d'autoriser l'envoi, exécutez des vérifications :
Rendez le contrôleur actionnable : mettez en évidence le bloc exact, suggérez des corrections et classez les problèmes en « doit corriger » vs « avertissement ».
La pipeline d'envoi est le « système de circulation » de votre app : elle décide comment le courrier est envoyé, quand il est libéré, et à quelle vitesse il monte sans nuire à la délivrabilité.
La plupart des apps commencent par un fournisseur (SendGrid, Mailgun, SES, Postmark) car vous obtenez mise à l'échelle, webhooks de feedback et outils de réputation avec moins d'effort. Les relais SMTP conviennent lorsque vous avez besoin de compatibilité avec des systèmes existants. Un MTA auto‑hébergé offre un contrôle maximal, mais ajoute un travail opérationnel continu (warm-up d'IP, traitement des rebonds, gestion des abus, monitoring).
Votre modèle de données doit considérer l'expéditeur comme un « canal de livraison » configurable pour pouvoir changer la méthode plus tard sans réécrire les campagnes.
N'envoyez pas directement depuis une requête web. Enquétez des jobs au niveau destinataire (ou petits lots) et laissez des workers les délivrer.
Mécanique clé :
{campaign_id}:{recipient_id}:{variant_id}.La planification doit supporter les fuseaux horaires (stocker le fuseau préféré de l'utilisateur ; convertir en UTC pour l'exécution). Pour la délivrabilité, throttlez par domaine destinataire (ex. gmail.com, yahoo.com). Cela permet de ralentir les domaines « chauds » sans bloquer la campagne entière.
Une approche pratique est de maintenir des seaux par domaine avec des limites de type token-bucket indépendantes et d'ajuster dynamiquement face aux déférés.
Séparez les envois transactionnels et marketing (idéalement sous-domaines et/ou pools d'IP distincts). Ainsi une campagne à grand volume n'empêchera pas l'envoi d'un mot de passe ou d'une confirmation de commande.
Stockez une trace immuable par destinataire : queued → sent → delivered/soft bounce/hard bounce/complaint/unsubscribe. Cela supporte le support client (« pourquoi je n'ai pas reçu ? »), les audits de conformité et un comportement de suppression précis ensuite.
La délivrabilité commence par prouver aux fournisseurs de boîtes mail que vous êtes autorisé à envoyer « au nom » de votre domaine. Les trois contrôles de base sont SPF, DKIM et DMARC — plus la configuration des domaines.
SPF est un enregistrement DNS listant quels serveurs peuvent envoyer pour votre domaine. À retenir : si votre app (ou votre ESP) envoie depuis votremarque.com, SPF doit inclure le fournisseur utilisé.
Votre UI doit générer une valeur SPF (ou un snippet “include”) et avertir clairement de ne pas créer plusieurs enregistrements SPF (erreur de configuration fréquente).
DKIM ajoute une signature cryptographique à chaque e-mail. La clé publique est dans le DNS ; le fournisseur s'en sert pour confirmer que l'e-mail n'a pas été altéré et qu'il est lié à votre domaine.
Dans l'app, offrez « Créer DKIM » par domaine d'envoi, puis affichez l'hôte/valeur DNS exacts à copier-coller.
DMARC indique aux boîtes ce qu'il faut faire quand SPF/DKIM échouent — et où envoyer les rapports. Commencez par une politique de monitoring (souvent p=none) pour collecter les rapports, puis durcissez en quarantine ou reject une fois stable.
DMARC est aussi là où l'alignement compte : le domaine visible dans le champ “From” doit être aligné avec SPF et/ou DKIM.
Encouragez les utilisateurs à aligner le domaine From avec le domaine authentifié. Si votre fournisseur permet de configurer un return-path personnalisé (domaine de rebond), orientez les utilisateurs vers le même domaine organisationnel (ex. mail.votremarque.com) pour réduire les problèmes de confiance.
Pour le suivi clic/ouverture, supportez un domaine de tracking personnalisé (CNAME comme track.votremarque.com). Exigez TLS (HTTPS) et vérifiez automatiquement le certificat pour éviter des liens cassés et des avertissements navigateur.
Construisez un bouton « Vérifier DNS » qui contrôle la propagation et signale :
Liez les utilisateurs à une checklist d'installation comme /blog/domain-authentication-checklist pour accélérer le dépannage.
Si vous ne traitez pas les rebonds, plaintes et désinscriptions comme des fonctionnalités de première classe, ils draineront silencieusement la délivrabilité. L'objectif : ingérer chaque événement du fournisseur, le traduire dans un format interne unique, et appliquer les règles de suppression automatiquement — et rapidement.
La plupart des fournisseurs envoient des webhooks pour delivered, bounced, complained, unsubscribed. Votre endpoint webhook doit être :
Une approche commune est de stocker un ID d'événement fournisseur unique (ou un hash de champs stables) et d'ignorer les répétitions. Enregistrez aussi le payload brut pour audit/debug.
Les fournisseurs nomment différemment les mêmes choses. Normalisez en un modèle interne, par exemple :
event_type : delivered | bounce | complaint | unsubscribeoccurred_atprovider, provider_message_id, provider_event_idcontact_id (ou email), campaign_id, send_idbounce_type : soft | hard (si applicable)reason / smtp_code / categoryCela rend le reporting et la suppression cohérents même si vous changez de fournisseur plus tard.
Traitez les rebonds permanents (adresse invalide, domaine inexistant) comme suppression immédiate. Pour les rebonds temporaires (boîte pleine, échec temporaire), supprimez seulement après un seuil — tel que « 3 rebonds temporaires en 7 jours » — puis mettez en refroidissement ou suppression permanente selon votre politique.
Gardez la suppression au niveau de l'identité e-mail (email + domaine), pas juste par campagne, pour éviter de retenter une adresse problématique.
Les plaintes (via feedback loops) sont un signal fortement négatif. Appliquez une suppression instantanée et arrêtez tout futur envoi à cette adresse.
Les désinscriptions doivent aussi être immédiates et globales pour la portée de liste promise. Conservez les métadonnées de désinscription (source, timestamp, campagne) pour que le support réponde à « pourquoi je ne reçois plus d'e-mails ? » sans ambiguïté.
Si vous le souhaitez, liez le comportement de suppression à la page de paramètres utilisateur (ex. /settings/suppression) pour que les équipes comprennent ce qui se passe en coulisses.
Le tracking aide à comparer les campagnes et détecter les problèmes, mais il est facile de surinterpréter les chiffres. Construisez des analytics utiles pour la prise de décision — et honnêtes sur l'incertitude.
Le suivi des ouvertures se fait généralement par une petite image pixel. Quand le client e-mail charge cette image, vous enregistrez une ouverture.
Limitations à concevoir :
Approche pratique : considérez les ouvertures comme un signal directionnel (ex. « cet objet a mieux performé »), pas une preuve d'attention.
Le suivi des clics est plus actionnable. Motif courant : remplacer les liens par une URL de tracking (votre service de redirection), puis rediriger vers la destination finale.
Bonnes pratiques :
Vous n'attraperez pas tout, mais réduirez l'inflation évidente.
Modelez l'analytics à deux niveaux :
Soyez clair dans l'UI : « unique » est une estimation, et le « taux d'ouverture » n'est pas un taux de lecture.
Si vous suivez des conversions (achat, inscription), connectez‑les via UTM ou un endpoint côté serveur léger. L'attribution reste imparfaite (multi‑appareils, actions différées, bloqueurs).
Fournissez des exports CSV et une API pour les événements et les statistiques agrégées afin que les équipes utilisent leur BI. Gardez les endpoints simples (par campagne, plage de dates, destinataire) et documentez les limites de débit à /docs/api.
Vous ne pouvez pas améliorer la délivrabilité si vous ne voyez pas ce qu'il se passe. Le monitoring doit répondre rapidement à deux questions : les messages sont‑ils acceptés par les fournisseurs de boîtes, et les destinataires s'engagent‑ils ?. Construisez des rapports pour qu'un marketeur non technique repère les problèmes en minutes, pas en heures.
Commencez par un panneau simple « santé de délivrabilité » combinant :
Évitez les graphiques de vanité qui masquent les problèmes. Une campagne avec de fortes ouvertures mais des plaintes en hausse est un futur blocage.
Le placement réel en boîte est difficile à mesurer directement. Utilisez des métriques proxy qui corrèlent fortement :
Si vous intégrez des boucles de feedback fournisseur ou des outils postmaster, traitez‑les comme des signaux, pas des vérités absolues.
Les alertes doivent être actionnables et liées à des seuils/fenêtres temporelles :
Envoyez les alertes par e-mail + Slack, et liez‑les directement à une vue filtrée (ex. /reports?domain=gmail.com&window=24h).
Détaillez les métriques par domaine destinataire (gmail.com, outlook.com, yahoo.com). Le throttling ou le blocage commence souvent chez un seul fournisseur. Montrez taux d'envoi, déferrals, rebonds et plaintes par domaine pour cibler où ralentir ou mettre en pause.
Ajoutez un journal d'incidents avec horodatages, périmètre (campagne/domaine), symptômes, cause suspectée, actions entreprises et résultat. Avec le temps, cela devient votre playbook — et rend réutilisable un correctif déjà appliqué.
La sécurité et la conformité ne sont pas des ajouts pour une app de campagnes e-mail — elles façonnent la façon dont vous stockez les données, envoyez et utilisez les informations des destinataires.
Commencez par des rôles et permissions clairs : par exemple, « Owner », « Admin », « Campaign Creator », « Viewer », et un rôle « API‑only » limité pour les intégrations. Rendez les actions à risque explicites et auditables (export contacts, changer domaines d'envoi, éditer listes de suppression).
Ajoutez 2FA pour les utilisateurs interactifs, et traitez l'accès API comme une fonctionnalité de première classe : clés API scindées par scope, rotation, expiration et permissions par clé. Pour les clients enterprise, incluez des allowlists IP pour l'UI admin et l'API.
Chiffrez les données sensibles au repos (identifiants de contact, métadonnées de consentement, champs personnalisés sensibles). Gardez les secrets hors de la base lorsque possible : utilisez un gestionnaire de secrets pour les identifiants SMTP, secrets de signature webhook et clés de chiffrement.
Appliquez le principe du moindre privilège partout : le service d'envoi ne devrait pas pouvoir lire des exports complets de contacts, et les jobs de reporting ne devraient pas pouvoir écrire dans la facturation. Journalisez aussi l'accès aux endpoints sensibles et aux exports pour permettre aux clients d'investiguer des activités suspectes.
La gestion des désinscriptions doit être immédiate et fiable. Stockez les enregistrements de suppression (désinscriptions, rebonds, plaintes) dans une liste durable, conservez‑les assez longtemps pour éviter un renvoi accidentel, et gardez la preuve : timestamp, source (clic lien, événement webhook, action admin) et campagne.
Tracez le consentement de façon prouvable : ce que l'utilisateur a accepté, quand et comment (formulaire, import, API). Pour plus sur les fondations d'authentification liées à la confiance et la conformité, voir /blog/email-authentication-basics.
Respectez les limites d'envoi et fournissez un « mode sûr » pour les nouveaux comptes : plafonds journaliers faibles, schedules de warm-up imposés, et avertissements avant les envois massifs. Associez cela à des limites de plan claires et des parcours d'upgrade sur /pricing.
Votre première release doit prouver la boucle complète : créer une audience, envoyer une vraie campagne, et traiter correctement ce qui arrive ensuite. Si vous ne faites pas confiance au flux d'événements (rebonds, plaintes, désinscriptions), vous n'êtes pas encore en production.
Visez un ensemble restreint mais utilisable :
Considérez la segmentation et le traitement webhook comme critiques :
La stabilité en production est surtout une question d'opérations :
campaign_id, message_id)Commencez par des campagnes internes, puis un petit pilote, et augmentez progressivement le volume. Appliquez des limites de débit conservatrices au départ et étendez seulement si rebonds/plaintes restent dans les cibles. Gardez un « kill switch » pour mettre les envois en pause globalement.
Une fois la boucle core fiable, ajoutez tests A/B, parcours automatisés, centre de préférences et templates multilingues. Un guide d'onboarding léger sur /blog/deliverability-basics réduit aussi les erreurs des premiers expéditeurs.
Si vous itérez vite, des fonctionnalités comme snapshots et rollback peuvent réduire le risque lors du déploiement (snapshots de segmentation, logique de suppression, traitement webhook). Par exemple, Koder.ai supporte des snapshots pour revenir rapidement après une régression — utile lors de la montée en charge du MVP à la production.
Commencez par définir le « succès » comme délivrabilité fiable + rapports de confiance + conformité cohérente. Concrètement, cela signifie pouvoir créer du contenu, planifier des envois, traiter automatiquement les rebonds/plaintes/désinscriptions, et expliquer exactement ce qui est arrivé à n'importe quel destinataire.
Une bonne feuille de route d'une page inclut : types de messages pris en charge, rôles/permissions requis, métriques clés et contraintes (budget, conformité, volume).
Considérez-les comme des « flux » séparés car ils diffèrent par l'urgence, le risque et le volume :
Si vous prenez en charge plusieurs flux, prévoyez des configurations séparées (idéalement sous-domaines/pools d'IP distincts) pour que les pics marketing ne retardent pas les reçus ou réinitialisations de mot de passe.
La plupart des équipes devraient intégrer un fournisseur d'e-mails (SES, SendGrid, Mailgun, Postmark) et se concentrer sur l'expérience produit (UI, planification, segmentation, rapports). Les fournisseurs gèrent déjà la réputation IP, les boucles de rétroaction et la montée en charge.
Vous ne construisez votre propre MTA que si vous disposez d'une équipe dédiée à la délivrabilité et aux opérations (warm-up, gestion des abus, monitoring et réglages constants).
Utilisez une base relationnelle comme source de vérité (tenants, utilisateurs, contacts, audiences, campagnes, envois, état de suppression). Pour les événements à haut volume (livrés/ouvertures/clics/rebonds), prévoyez un journal d'événements en append-only (tables partitionnées par date ou pipeline de logs) afin que l'ingestion d'événements n'alourdisse pas les opérations CRUD.
Conservez les payloads bruts des fournisseurs pour le débogage et les audits.
Modélisez l'intention et l'exécution :
Cette séparation permet de répondre aux questions de support (« que s'est‑il passé pour ce destinataire ? ») et d'assurer la cohérence des rapports.
Avant d'enqueter les destinataires, filtrez pour n'inclure que les contacts éligibles :
Affichez la règle dans l'UI (et idéalement un « pourquoi exclu » pour un échantillon) afin de réduire la confusion et d'éviter des envois non conformes.
Utilisez les webhooks de votre fournisseur, mais partez du principe que des doublons et des livraisons hors ordre arriveront. Votre handler de webhook doit :
Appliquez ensuite automatiquement les règles de suppression (rebond permanent, plainte, désinscription) et mettez à jour le statut du contact immédiatement.
Planifiez une architecture « queue-first » :
{campaign_id}:{contact_id}:{variant_id} pour éviter les doublonsSéparez aussi les queues transactionnelles et marketing pour que les mails critiques ne soient pas bloqués par de grandes campagnes.
Aidez les utilisateurs à configurer SPF, DKIM et DMARC :
Si vous faites du tracking clic/ouverture, proposez un domaine de tracking personnalisé (CNAME) et imposez TLS pour éviter des redirections cassées et des problèmes de confiance.
Considérez les ouvertures comme directionnelles et les clics comme plus exploitables :
Dans l'UI, étiquetez les métriques honnêtement (par ex. « unique = meilleure estimation ») et fournissez des exports/API pour que les équipes valident dans leurs outils BI.