Par défaut, 2LRN4 envoie tous les e-mails destinés à tes apprenants depuis une adresse qui lui est propre. Cela fonctionne, mais les collaborateurs ne reconnaissent pas toujours l'expéditeur. Tu peux donc faire en sorte que l'e-mail parte de l'adresse de ton organisation, et même qu'il soit réellement envoyé depuis votre propre environnement de messagerie. Depuis août 2026, c'est possible pour toutes les organisations ; auparavant, cela était réservé aux clients disposant d'un environnement Microsoft.

Tu trouves ce choix dans Organisations → ton organisation → modifier, sous la rubrique Assistance, à Mode d'envoi pour cette organisation.

Les quatre modes d'envoi

Le mode qui convient dépend de l'endroit où tourne votre messagerie. Si vous êtes sur Microsoft 365 ou sur Google Workspace, choisis le mode correspondant. C'est ce qui donne la meilleure remise, car l'e-mail sort alors vraiment de votre propre environnement.

Via 2LRN4 (par défaut)

L'e-mail est envoyé par nos soins. Si tu indiques dans E-mail d'assistance une adresse de ta propre organisation, c'est elle qui apparaît comme expéditeur ; si tu laisses le champ vide, nous utilisons l'adresse de 2LRN4.

Attention si tu utilises ta propre adresse sur ce mode. L'e-mail vient alors de ton adresse, mais il est envoyé par notre serveur. Beaucoup d'organisations ont défini dans leur DNS qui peut envoyer au nom de leur domaine (SPF, DKIM et DMARC). Si ce réglage est strict, le serveur de messagerie destinataire peut placer ces messages dans les indésirables, voire les refuser. En cas de doute, parles-en avec ton administrateur informatique, ou choisis l'un des trois modes ci-dessous, où la question ne se pose pas.

Depuis votre propre boîte aux lettres Microsoft

L'e-mail est envoyé via Microsoft Graph depuis une boîte aux lettres de votre propre environnement Microsoft 365. L'expéditeur et la remise sont alors corrects d'eux-mêmes, puisque l'e-mail quitte tout simplement votre propre environnement Microsoft.

Dans la plateforme, tu as besoin de trois choses :

1. Une connexion Entra pour cette organisation. Si tu n'en as pas encore, l'écran t'indique où en créer une. Voir aussi Synchroniser les utilisateurs.
2. L'enregistrement d'application de cette connexion doit avoir le droit d'envoyer des e-mails. Si tu utilises une connexion existante configurée uniquement pour la synchronisation des utilisateurs, elle n'a généralement pas encore ce droit ; ci-dessous, tu trouves ce que ton administrateur informatique ajoute.
3. L'adresse indiquée dans E-mail d'assistance doit être une boîte aux lettres existante dans cet environnement, avec des droits d'envoi. Un alias, ou une adresse qui n'existe que sur le papier, ne fonctionne pas.

Ce que ton administrateur informatique règle dans Azure, dans l'enregistrement d'application de la connexion existante :

1. Ouvre l'enregistrement d'application et va dans Autorisations d'API.
2. Ajoute une autorisation via Microsoft Graph → Application permissions et choisis Mail.Send. Utilise exclusivement des application permissions ; les delegated permissions ne fonctionnent pas ici, car la plateforme envoie sans utilisateur connecté.
3. Accorde le consentement administrateur (admin consent) pour la nouvelle autorisation.
4. Vérifie que l'adresse d'expéditeur est une boîte aux lettres Exchange Online valide.
5. Limite l'autorisation à cette seule boîte aux lettres. C'est l'étape la plus importante, et elle est souvent oubliée. Par défaut, Mail.Send vaut pour tout l'environnement : techniquement, l'enregistrement d'application peut alors envoyer au nom de n'importe quelle adresse de votre tenant, alors que nous n'en utilisons qu'une. Avec une application access policy (stratégie d'accès aux applications) dans Exchange Online, tu limites cela à la boîte aux lettres que tu indiques ici.

   Ton administrateur informatique le fait avec deux commandes dans Exchange Online PowerShell. Place d'abord la boîte aux lettres dans un groupe de sécurité à extension messagerie, puis rattache-lui l'enregistrement d'application :

   New-DistributionGroup -Name "2LRN4 boîte d'envoi" -Type Security `
     -PrimarySmtpAddress "2lrn4-boite-envoi@tondomaine.fr" `
     -Members "noreply@tondomaine.fr"
   
   New-ApplicationAccessPolicy `
     -AppId "" `
     -PolicyScopeGroupId "2lrn4-boite-envoi@tondomaine.fr" `
     -AccessRight RestrictAccess `
     -Description "2LRN4 ne peut envoyer que depuis la boîte d'envoi"

   Vérifier que cela a fonctionné :

   Test-ApplicationAccessPolicy -Identity "noreply@tondomaine.fr" -AppId ""

   Le résultat doit être Granted pour cette boîte aux lettres, et Denied pour toutes les autres. Compte une heure avant que le réglage soit appliqué partout.

Est-ce que cela fonctionne ? En bas du même écran se trouve le bouton Envoyer un message de test. Il envoie un seul message à ta propre adresse, exactement par le même chemin que l'e-mail destiné à tes apprenants. Enregistre d'abord tes modifications, car le test utilise les réglages enregistrés. Au-dessus du bouton figure le résultat du dernier contrôle, que nous effectuons automatiquement chaque matin.

Si tu reçois le message indiquant que votre propre mode d'envoi n'a pas fonctionné et que le message est parti via 2LRN4, c'est que le message de test est bien arrivé mais que le réglage n'est pas encore correct. La raison y est alors indiquée.

Messages d'erreur connus sur ce mode et ce qu'il faut faire :

Depuis votre propre boîte aux lettres Google

L'e-mail est envoyé via la Gmail API depuis une boîte aux lettres de votre Google Workspace. L'expéditeur et la remise sont alors corrects d'eux-mêmes, parce que l'e-mail quitte tout simplement votre propre environnement Google.

Dans la plateforme, il te faut trois choses :

1. Un compte de service dans Google Cloud, avec une clé JSON. Tu trouves plus bas comment ton administrateur Google le crée.
2. La délégation à l'échelle du domaine pour ce compte de service dans la console d'administration Google, avec uniquement le scope https://www.googleapis.com/auth/gmail.send.
3. L'adresse indiquée dans E-mail d'assistance doit être une boîte aux lettres existante dans ce Workspace. C'est la boîte depuis laquelle la plateforme envoie ; un groupe ou un alias ne fonctionne pas.

Ce que ton administrateur Google met en place, en deux parties : d'abord le compte de service dans Google Cloud, ensuite l'autorisation dans la console d'administration Google.

Partie 1 : le compte de service (Google Cloud Console)

1. Va sur console.cloud.google.com et choisis ou crée un projet pour votre organisation, par exemple « 2LRN4 mail ».
2. Active la Gmail API : va dans API et services → Bibliothèque, cherche « Gmail API » et choisis Activer. Sans cette étape, Google refuse chaque requête.
3. Crée le compte de service : IAM et administration → Comptes de service → Créer un compte de service. Donne-lui un nom reconnaissable, par exemple « 2lrn4-mail ». Aucun rôle n'est nécessaire ; tu peux passer cette étape.
4. Crée une clé : ouvre le compte de service, va dans l'onglet Clés et choisis Ajouter une clé → Créer une clé → JSON. Un fichier JSON est téléchargé. Conserve-le en lieu sûr, car c'est en pratique le mot de passe de ce compte.
5. Note l'ID client du compte de service. Il figure sur la page de détails sous « ID unique » et c'est un nombre d'environ 21 chiffres. Tu en as besoin dans la partie 2.

Partie 2 : l'autorisation d'envoyer au nom de la boîte aux lettres (console d'administration Google)

1. Va sur admin.google.com, choisis Sécurité → Contrôle des accès et des données → Commandes des API, puis tout en bas Gérer la délégation au niveau du domaine.
2. Choisis Ajouter. Dans ID client, saisis le nombre de la partie 1, étape 5, et dans Champs d'application OAuth exactement ce seul scope : https://www.googleapis.com/auth/gmail.send. D'autres scopes ne sont pas nécessaires, et il vaut mieux ne pas les accorder.
3. Choisis Autoriser. Compte de quelques minutes à une heure avant que le réglage soit appliqué partout.

Pourquoi uniquement le scope d'envoi ? La délégation à l'échelle du domaine vaut pour tout le domaine : techniquement, le compte de service peut ainsi envoyer au nom de n'importe quelle adresse de votre Workspace, même si la plateforme n'en utilise qu'une. Avec seulement gmail.send, il ne peut au moins rien lire ni gérer. Si tu veux resserrer davantage, tu peux restreindre la Gmail API par unité organisationnelle dans la console d'administration ; vois cela avec ton administrateur informatique.

Dans la plateforme

Choisis le mode Depuis la boîte aux lettres Google de l'organisation. Ouvre le fichier JSON téléchargé dans un simple éditeur de texte (pas un traitement de texte) et colle le contenu complet, de la première { à la dernière }, dans le champ Clé du compte de service (JSON). Dans E-mail d'assistance, indique la boîte depuis laquelle envoyer, puis enregistre.

La clé est conservée chiffrée et n'est plus affichée après l'enregistrement ; tu vois seulement à quel compte de service elle appartient. Si tu veux la retirer plus tard, tu peux le faire avec la case Supprimer cette clé ; choisis d'abord un autre mode, car tant que le mode Google est sélectionné, la clé reste nécessaire.

Est-ce que cela fonctionne ? En bas du même écran se trouve le bouton Envoyer un message de test. Il envoie un seul message à ta propre adresse, exactement par le même chemin que l'e-mail destiné à tes apprenants. Enregistre d'abord tes modifications, car le test utilise les réglages enregistrés.

Messages d'erreur connus sur ce mode et ce qu'il faut faire (la ligne de motif elle-même s'affiche en néerlandais) :

Via votre propre serveur de messagerie (SMTP)

Si vous n'utilisez ni Microsoft ni Google, tu peux indiquer votre propre serveur de messagerie : serveur, port, chiffrement, nom d'utilisateur et mot de passe. Le mot de passe est conservé chiffré et n'est plus affiché après l'enregistrement ; si tu laisses le champ vide lors d'une modification ultérieure, le mot de passe existant reste en place.

Vérifie avec ton administrateur informatique si ce serveur a le droit d'envoyer au nom de votre domaine, faute de quoi l'e-mail pourrait tout de même être refusé.

Ce qui se passe en cas de problème

Si l'envoi par votre propre mode échoue, par exemple parce qu'un mot de passe a expiré, qu'une autorisation a été retirée ou qu'une boîte aux lettres a été déplacée, le message part malgré tout via 2LRN4. Ton apprenant reçoit donc bien sa réinitialisation de mot de passe ou son invitation ; simplement, c'est notre adresse qui figure alors comme expéditeur, avec votre adresse comme adresse de réponse. C'est voulu : un message portant votre domaine comme expéditeur mais partant de notre serveur entre en conflit avec les réglages SPF et DMARC de votre domaine, et finirait dans les indésirables.

En même temps, l'organisation est signalée. Tu le vois sur l'écran du mode d'envoi, et nous le voyons dans un contrôle quotidien qui détermine, pour chaque organisation, si l'envoi est encore possible. En cas de problème persistant, nous prenons contact avec toi.

Questions fréquentes

Est-ce que quelque chose change pour nos apprenants ?

Seulement l'expéditeur. Le contenu, la mise en forme et le moment de l'envoi restent identiques.

Nous utilisions l'ancien réglage « Enable azure mailing ». Devons-nous faire quelque chose ?

Non. Les organisations qui envoyaient via Microsoft ont été basculées automatiquement vers le mode Depuis votre propre boîte aux lettres Microsoft ; tout continue à fonctionner comme avant.

Pouvons-nous revenir au mode par défaut ?

Oui, à tout moment. Remets le choix sur Via 2LRN4 ; l'e-mail repart alors de notre adresse. Les identifiants enregistrés sont conservés jusqu'à ce que tu les supprimes toi-même, pour que tu puisses rebasculer plus tard.

Cela vaut-il aussi pour les simulations de phishing ?

Non. Elles sont envoyées via un environnement distinct et disposent de leurs propres réglages d'expéditeur.

Et le formulaire d'assistance dans la plateforme ?

Il suit le même mode d'envoi que le reste de tes e-mails.