Aller au contenu
Tous les articles
Blog

La check-list marque blanche : ce qu'il faut demander à un éditeur après le logo

La marque blanche ne se résume pas à un logo. Les questions à poser : domaines, domaines d'envoi, liens de réinitialisation, héritage, et ce que révèle votre code source.

The Lurno teamAugmental13 min de lecture

La marque blanche échoue là où personne ne fait de démonstration. Le téléversement du logo fonctionne toujours. Ce qui décide si les équipes d'un client peuvent utiliser une plateforme pendant un an sans jamais croiser le nom de votre éditeur, c'est l'hôte contenu dans le lien de réinitialisation du mot de passe, le domaine qui a signé l'e-mail de notification, le texte dans l'onglet du navigateur, et la page de connexion sur laquelle on arrive à froid à 8 h du matin, avant qu'aucune session n'existe. Posez ces quatre questions avant celle des couleurs.

Tous les éditeurs répondent oui à « prenez-vous en charge la marque blanche ? ». Le mot recouvre tout, d'un code hexadécimal à un tenant qui est réellement le vôtre, et les deux réponses arrivent sur le même ton assuré. Ce qui suit est une check-list pour l'appel, rédigée sous forme de questions plutôt que de fonctionnalités : une liste de fonctionnalités appelle un oui, une question appelle une démonstration.

Marque blanche

Servir une plateforme sous votre propre nom, votre propre domaine et votre propre design, de sorte que les personnes qui l'utilisent n'aient aucune raison particulière de savoir qui l'a construite. Le thème n'en est qu'une partie : les couleurs, les polices et un logo sur les pages que voit un utilisateur connecté. La marque blanche, c'est toute la surface — barre d'adresse, en-têtes de messagerie, page de connexion, onglet du navigateur, code source. Le thème relève de la configuration ; la marque blanche relève surtout de l'architecture.

Le test utile n'est pas de savoir si le logo du client apparaît. C'est de savoir si un moment quelconque d'une semaine ordinaire — se connecter, réinitialiser un mot de passe, ouvrir un e-mail, coller un lien dans un ticket — fait remonter le nom de l'éditeur. Déroulez cette semaine à voix haute pendant l'appel.

Lurno

Le salarié d'un client se connecte sur le domaine de son employeur, reçoit des e-mails signés par le domaine de son employeur, et colle un lien d'assistance qui porte le nom de son employeur.

Not this

Un logo et un code hexadécimal sur un produit qui vit toujours à l'adresse yourcompany.vendor.com et qui écrit depuis no-reply@vendor.com.

Le domaine, et les parties d'une session qui en sortent

Le domaine personnalisé est l'élément porteur ; tout le reste est de la décoration posée dessus. Cinq questions vous mènent presque au bout.

  • Le domaine personnalisé est-il compris dans l'offre qui nous est proposée, ou est-ce une option ? Demandez la ligne du devis. Les domaines sont une option payante courante, et sur les plateformes anciennes, une prestation de services plutôt qu'un réglage.
  • Qui émet le certificat TLS, et que se passe-t-il au renouvellement ? Émission et renouvellement automatiques, ou un ticket tous les quelques mois. Demandez ce que voit un apprenant le matin où un renouvellement échoue.
  • Un domaine pour le compte, ou un par organisation ? Si vous exploitez plusieurs académies clientes ou plusieurs campus, demandez à quelle profondeur un nom d'hôte distinct cesse d'être possible.
  • Pouvons-nous le mettre en place nous-mêmes ? La bonne réponse est un écran qui affiche les enregistrements DNS exacts pour votre bureau d'enregistrement, et un statut en direct pendant l'émission du certificat. Le signe qui ne trompe pas, c'est un fil d'e-mails avec un service d'assistance.
  • Quelles parties d'une session sortent de notre domaine ? Les téléchargements, la vidéo, le lecteur d'évaluation, la vérification des certificats, un widget d'aide intégré, le passage de main à la connexion. Demandez-leur d'ouvrir l'onglet réseau sur un tenant en fonctionnement et de lire les noms d'hôtes à voix haute.

Les apprenants verront-ils un jour le domaine de l'éditeur si nous avons un domaine personnalisé ?

En général quelque part, et la question est de savoir où. Les fuites courantes sont la redirection pendant la connexion, les médias servis depuis un CDN partagé, la page vers laquelle mène le lien de vérification d'un certificat, et tout widget de discussion intégré. Chacune découle de la façon dont la plateforme a été construite, et chacune est visible par un apprenant : posez donc la question sur chacune, nommément.

L'e-mail, et le lien où le masque tombe

L'e-mail est la moitié de la marque blanche qui reste discrètement chez l'éditeur. Une adresse d'expéditeur est une chaîne d'affichage, et n'importe qui peut en définir une. Ce qu'un logiciel de messagerie lit en dessous, c'est le domaine qui a réellement signé le message.

From: Northbridge Academy <no-reply@learn.northbridge.edu>   <- the display line
Return-Path: bounces@mail.vendor-lms.com                     <- the envelope sender
DKIM-Signature: ... d=vendor-lms.com ...                     <- the signing domain

Gmail affiche un petit « via vendor-lms.com » à côté de l'expéditeur quand le domaine signataire ne correspond pas au domaine de l'expéditeur affiché. La DSI de votre client sait ce que cela veut dire. Alors demandez :

  • Quels messages partent de notre domaine, et lesquels du vôtre ? Demandez la liste complète — invitation, bienvenue, réinitialisation de mot de passe, inscription, relance, note publiée, certificat délivré, récapitulatif, alerte administrateur — puis lesquels peuvent porter notre expéditeur.
  • La ligne d'expéditeur seulement, ou aussi le domaine signataire ? La question suivante est celle des enregistrements DNS que vous publiez. Si aucun ne va chez votre bureau d'enregistrement, le courrier ne part pas vraiment de votre domaine.
  • Notre propre compte d'envoi et notre propre clé, ou votre réservoir partagé ? Sur un réservoir partagé, le taux de rebond d'un autre tenant devient votre problème de délivrabilité, sans que rien ne le montre.
  • Par organisation, ou une fois au sommet ? Un expéditeur unique pour tout le compte défait l'indépendance dès le premier e-mail.
  • Quel logo l'e-mail utilise-t-il, et où est-il hébergé ? Une image hébergée par l'éditeur affiche son URL dans le texte alternatif dès qu'une passerelle de messagerie bloque les images distantes.

Puis le lien à l'intérieur du message, là où la plupart des évaluations découvrent la vérité. Le corps peut porter votre logo, vos couleurs et votre expéditeur, et le bouton en son milieu peut malgré tout pointer vers l'hôte de l'éditeur — parce que les liens d'invitation et de réinitialisation sont en général forgés par la couche d'authentification, configurée une seule fois, globalement, avec une unique URL de site.

Les e-mails de réinitialisation de mot de passe et d'invitation utilisent-ils mon propre domaine ?

Souvent non, y compris sur des plateformes qui habillent bien le reste, et c'est l'endroit où le masque tombe le plus souvent. Ces liens sont en général générés à partir d'une seule URL de site configurée globalement : un message peut donc vous ressembler entièrement pendant que le lien qu'il contient mène à l'hôte de l'éditeur. Ne posez pas cette question — testez-la, et lisez vous-même la cible du lien et les en-têtes.

La page de connexion, l'onglet et les deux logos

La page de connexion est la plus difficile à habiller et la première que voit chaque apprenant. Avant que quiconque s'authentifie, la plateforme ne sait rien du visiteur, sinon le nom d'hôte par lequel il est arrivé. Si la marque est chargée depuis l'organisation d'un utilisateur connecté, un visiteur à froid obtient le thème par défaut de l'éditeur. Posez la question exactement dans ces termes : la marque est-elle résolue à partir du seul nom d'hôte, avant qu'aucune session n'existe ?

  • Qu'est-ce qui s'affiche sur notre domaine pour un visiteur sans session ? Le logo, le nom du produit, les couleurs, l'arrière-plan, le libellé du bouton de connexion.
  • Y a-t-il une mention « powered by », et qu'est-ce qui la supprime ? Une case à cocher, une offre supérieure, ou une clause du contrat. Les trois existent, et elles ne coûtent pas la même chose.
  • À quoi ressemblent les états d'erreur ? Mot de passe incorrect, invitation expirée, compte verrouillé — les pages qui ont le plus de chances d'être les modèles par défaut de l'éditeur, et celles qu'un utilisateur agacé lit le plus attentivement.
  • Qu'y a-t-il dans l'onglet du navigateur ? Le titre de la page sur chaque route, et le favicon. Demandez si le favicon est propre à chaque organisation ou s'il s'agit d'un fichier unique pour toute la plateforme ; le servir depuis un seul chemin statique est un raccourci courant.
  • Y a-t-il deux logos ? Un logo pour le thème clair, un pour le thème sombre, en général aussi une marque carrée. Demandez ce qui se passe si vous n'en téléversez qu'un et qu'un utilisateur bascule en thème sombre.
  • Qu'y a-t-il dans les documents qui sortent de la plateforme ? Les certificats en PDF, les rapports exportés, les relevés de résultats. Regardez le pied de page, puis les métadonnées du fichier, là où le nom d'un éditeur survit le plus longtemps.

L'héritage, et à quelle granularité

Si vous exploitez plus d'une organisation — entreprises clientes, établissements d'un groupe, filiales par pays —, « la marque est-elle héritée ? » est une question de granularité plutôt qu'une question fermée, et c'est la granularité qui fait que le travail disparaît ou se multiplie.

  • Si une organisation enfant ne définit rien, qu'obtient-elle ? La marque du parent, ou le thème par défaut de l'éditeur. Pour un groupe, la seconde réponse est mauvaise : chaque nouvel établissement commence sa vie à l'image de l'éditeur.
  • Tout ou rien, ou champ par champ ? Un établissement qui veut la palette du groupe et son propre blason a besoin d'un repli au niveau du champ. Un héritage par bloc oblige chaque enfant à redéclarer quatorze couleurs pour changer un logo.
  • Les logos clair et sombre reviennent-ils au parent comme une paire ? S'ils sont repris indépendamment, un enfant qui ne téléverse qu'un logo clair laisse le logo sombre du parent échoué contre sa nouvelle palette. Une petite question qui produit un silence instructif.
  • Qui a le droit de le modifier ? L'administrateur de l'enfant lui-même, ou bien chaque changement passe par votre équipe centrale. La seconde réponse est une file d'assistance que vous ferez encore tourner dans un an.
  • Jusqu'à quelle profondeur cela descend-il ? Deux niveaux, c'est courant. Un éditeur dont les établissements ont des campus en demande davantage.
  • La terminologie est-elle héritée au même titre que le design ? Si vous pouvez renommer « apprenant » en « stagiaire », demandez si cela se propage vers le bas, et si cela se paramètre séparément pour chaque langue.

Chaque sous-organisation peut-elle avoir sa propre marque et son propre domaine, ou seulement le compte principal ?

C'est ce qui varie le plus dans toute cette liste, et c'est ce qui sépare une plateforme multi-tenant d'une plateforme mono-tenant thématisée. Beaucoup de produits habillent le compte et donnent aux comptes enfants une vue filtrée de la marque du parent — très bien pour des services, inadapté pour des clients. Demandez si un enfant peut détenir son propre nom d'hôte, son certificat, sa paire de logos, sa palette et son expéditeur, et à quelle profondeur tout cela s'arrête.

Des tests à mener vous-même

L'expérience mobile

Établissez d'abord ce qu'on vous vend, parce que « nous avons le mobile » recouvre deux produits dont l'histoire de marque diffère. S'il s'agit d'une application native, les questions sont commerciales plutôt que cosmétiques. Quel nom figure sur la fiche du magasin d'applications ? Qui détient le compte développeur, et qui soumet les versions ? Y a-t-il une compilation distincte par client, et un cycle de validation distinct avec elle ?

S'il s'agit d'une application web responsive, la marque emprunte le même chemin de code que le site sur ordinateur, ce qui est en général la meilleure réponse ici. Demandez à la voir à la largeur d'un téléphone sur votre propre domaine, puis demandez quel nom et quelle icône apparaissent quand un apprenant l'ajoute à son écran d'accueil.

Le code source de la page

Quelqu'un finira par afficher le code source — l'équipe informatique d'un client, un apprenant curieux. Vous ne cachez rien ; vous vérifiez si la plateforme a été construite pour être servie sous le nom de quelqu'un d'autre. Deux commandes répondent à l'essentiel.

# Quel nom figure sur le certificat servi sur votre domaine ?
openssl s_client -connect learn.yourbrand.com:443 \
  -servername learn.yourbrand.com </dev/null 2>/dev/null \
  | openssl x509 -noout -text | grep -A1 'Subject Alternative Name'

# Que disent le HTML et les en-têtes de réponse ?
curl -sL https://learn.yourbrand.com | grep -io 'vendorname' | wc -l
curl -sI https://learn.yourbrand.com | grep -iE 'server|x-powered-by|content-security-policy'

La vérification du certificat est la plus intéressante. Certaines plateformes émettent un certificat par nom d'hôte client ; d'autres regroupent de nombreux clients sur un seul certificat multi-noms. Si la liste des noms alternatifs sur le domaine de votre client nomme d'autres clients, c'est une information publique sur les autres organisations que sert l'éditeur, et une revue de sécurité la trouvera.

Dans le HTML, lisez le titre de la page, la balise `og:site_name`, le manifeste web, les noms d'hôtes depuis lesquels les scripts et les images sont chargés, et les points de collecte d'analytique et de remontée d'erreurs déclarés dans l'en-tête de politique de sécurité du contenu. Ce sont ces points de collecte qui trahissent le plus souvent, parce que personne ne les considère comme relevant de la marque.

Comment mener l'appel

  1. Demandez un tenant en fonctionnement sur un domaine que vous contrôlez, pas une démonstration enregistrée. Une journée de travail DNS est un test moins cher qu'une année de contrat.
  2. Faites-leur envoyer une vraie invitation et une vraie réinitialisation de mot de passe à une adresse que vous contrôlez. Lisez la cible du lien et les en-têtes.
  3. Ouvrez la page de connexion à froid, dans une fenêtre de navigation privée, en thème sombre, sur un téléphone.
  4. Exécutez les deux commandes ci-dessus sur votre propre nom d'hôte.
  5. Rassemblez les réponses dans un document partagé, daté. « En cours de développement » est une bonne réponse quand elle est écrite, et une mauvaise quand on la découvre au quatrième mois.

Insistez sur les questions qui produisent la démonstration d'un écran au lieu d'une réponse. Cette réaction est rarement une esquive — elle signifie en général que personne n'avait posé la question avant.

Où se situe Lurno

Nos propres réponses, y compris sur ce qui n'est pas fini. Les domaines sont propres à chaque organisation, à n'importe quelle profondeur de l'arborescence, et se paramètrent depuis les réglages de cette organisation : saisissez le nom d'hôte, publiez les enregistrements DNS que l'écran vous indique, suivez le statut jusqu'à ce que le certificat soit actif, puis désignez-le comme domaine principal. Les noms d'hôtes passent par Cloudflare ; le TLS est émis et renouvelé automatiquement. La page de connexion résout le logo, le titre, le slogan, le thème et l'arrière-plan à partir du seul nom d'hôte, avant que quiconque s'authentifie. Une fois un domaine désigné comme principal, les liens d'invitation de cette organisation sont construits dessus.

La marque, ce sont dix-sept champs — quatorze jetons de couleur, la police d'affichage, la police de texte, le rayon des angles — plus un logo clair, un logo sombre, un favicon, un titre et un slogan. L'héritage répond à la question de granularité posée plus haut : une sous-organisation sans thème reprend l'intégralité du thème du parent, la paire de logos est héritée comme un tout, si bien que vous ne pouvez pas laisser un logo sombre échoué sur un fond clair, et le titre, le slogan et le favicon se replient champ par champ. La terminologie est renommable par langue, et les e-mails de notification partent du sous-domaine propre à l'organisation. Le modèle complet est sur la page marque blanche ; qui envoie le courrier figure dans la liste des sous-traitants ultérieurs sur la page sécurité.

Les manques, clairement. Il n'y a pas d'applications mobiles natives — Lurno est une application web responsive, si bien que le mobile porte la même marque que tout le reste, mais il n'y a pas d'application à votre nom dans un magasin, et les applications natives sont sur la feuille de route plutôt que livrées. L'authentification unique SAML et OIDC est également sur la feuille de route ; ce qui existe aujourd'hui est l'authentification partenaire, où votre backend transmet une assertion signée pour un apprenant qu'il a déjà authentifié. Les paiements et le paiement en ligne sont en cours de développement.

La marque blanche n'est pas une fonctionnalité que l'on active à l'inscription. C'est une propriété de l'endroit où un éditeur a tracé ses frontières des années avant votre appel, et ces frontières se lisent dans la barre d'adresse, les en-têtes de messagerie et le code source d'un tenant en fonctionnement. Une demi-heure avec un vrai domaine tranche davantage de points de cette liste qu'un après-midi d'appels — le nôtre compris, et c'est à cela que sert une démo.