Un thérapeute reçoit un cold mail. Il clique sur "Oui". Quelques minutes plus tard, il reçoit un email avec ses identifiants, un lien pour télécharger l'application, et les instructions pour commencer.
Je n'ai rien fait. Je n'ai même pas été impliqué.
C'est ça la vraie valeur ajoutée — pas juste la séquence de relance, mais le fait que tout le cycle, du cold mail à l'utilisateur actif, est automatisé de bout en bout. Je reçois une notification à la fin. C'est tout.
Le contexte : un POC en phase fermée
Nuance est une application Android de colonnes de Beck interactives, pensée comme un prolongement des séances TCC. Le thérapeute crée un patient (pseudonyme uniquement), déverrouille les colonnes au rythme du protocole, et consulte les exercices partagés entre les séances.
L'accès est fermé et contrôlé — pas de self-service public. Ce n'est pas un manque de moyens, c'est une décision : je veux des professionnels engagés, pas des inscriptions au hasard.
Étape 1 — Identifier les bons praticiens
Je n'attends pas que les thérapeutes viennent à moi. Je vais les chercher.
L'AFTCC (Association Française de Thérapie Cognitive et Comportementale) publie un annuaire de ses membres — des praticiens certifiés, formés à la TCC, qui utilisent les colonnes de Beck dans leur pratique quotidienne. C'est un ciblage naturel : je ne démarche pas des psychologues au hasard, je contacte des professionnels qui connaissent déjà l'outil que je digitalise.
Je récupère les contacts, je nettoie la liste, et j'envoie un cold mail court avec une question simple et deux boutons.
Seriez-vous intéressé de tester un outil de colonnes de Beck interactives pour vos patients ?
[Oui, je veux tester] · [Non merci]
Pas de pitch. Pas de liste de features. Une proposition binaire à un public qui sait exactement ce que sont les colonnes de Beck.
Le bouton "Non merci" redirige vers un formulaire de refus — raison, commentaire, option de désinscription. Je collecte de la donnée même sur les non.
Étape 2 — Le clic déclenche tout
Quand un thérapeute clique sur "Oui", il tombe directement sur une page de bienvenue personnalisée avec son prénom — que j'ai déjà récupéré sur l'annuaire AFTCC. Pas de formulaire, pas de saisie. Juste :
"Ravi de vous compter parmi les premiers testeurs, [Prénom]. Je génère actuellement vos accès personnels. Vous recevrez vos codes de connexion par email d'ici 5 à 10 minutes."
Ce clic déclenche en cascade, sans aucune intervention de ma part :
1. Création du compte
Un compte thérapeute est créé en base avec un mot de passe temporaire généré aléatoirement. Le flag must_change_password est activé — à la première connexion, l'app force le changement.
$tempPassword = bin2hex(random_bytes(8)); // 16 caractères hex
$passwordHash = password_hash($tempPassword, PASSWORD_BCRYPT);
insert('users', [
'email' => $email,
'name' => $name,
'password_hash' => $passwordHash,
'must_change_password' => 1,
'is_active' => 1,
]);
2. Création du patient personnel
Un patient virtuel "Mes exercices" est automatiquement créé avec le flag is_therapist_self = 1. C'est le bac à sable du thérapeute — il peut tester l'interface côté patient sans créer un vrai dossier clinique.
3. Génération d'un code de téléchargement
L'APK n'est pas public. Un code à usage unique est généré et associé au compte. Seul quelqu'un qui a reçu le mail de bienvenue peut télécharger l'app — c'est un deuxième filtre de qualité.
4. Mise en file d'attente du mail de bienvenue
Le mail ne part pas instantanément. Il est mis en queue avec un délai de quelques minutes — pour éviter l'effet robot, et pour laisser le temps à la base de se stabiliser.
insert('pending_welcome_emails', [
'user_id' => $userId,
'email' => $email,
'name' => $name,
'temp_password' => $encryptedPassword, // chiffré en base
'send_after' => date('Y-m-d H:i:s', strtotime('+5 minutes')),
]);
5. Notification admin
Je reçois un email de synthèse : nom, email, heure d'inscription. C'est tout ce que je fais dans ce flow — lire une notification.
Étape 3 — Le mail de bienvenue
Quelques minutes après le clic, le thérapeute reçoit un email complet avec :
- Ses identifiants (email + mot de passe temporaire)
- Son code de téléchargement APK
- Un bouton pour accéder au dashboard web
- Les 5 étapes pour démarrer, dans l'ordre
Tout est personnalisé, tout est fonctionnel. Aucune pièce du puzzle n'attend une action de ma part.
Étape 4 — La séquence de relance automatique
Un mail de bienvenue bien fichu ne suffit pas. Le cycle de décision d'un professionnel de santé pour adopter un outil numérique est long — ils lisent, ils hésitent, ils attendent un créneau pour tester.
J'ai construit deux séquences parallèles de 3 emails, espacés de 7 jours, qui tournent via un cron nocturne.
Séquence 1 — Compte non activé
Pour les thérapeutes qui n'ont pas encore ouvert l'application. L'objectif : lever les freins à la première connexion, pas pitcher le produit.
| Step | Sujet | Angle |
|---|---|---|
| 1 | "Vos accès pour tester Nuance (rappel)" | Un espace personnel vous attend déjà |
| 2 | "Moins de papier, plus de clinique ?" | Le gain de temps concret |
| 3 | "Un souci pour accéder à votre espace ?" | La main tendue, dernier message |
Le step 3 est délibérément humain — "c'est mon dernier message". Pas d'urgence artificielle. Juste une invitation à répondre directement si quelque chose bloque.
Séquence 2 — Compte activé, pas encore de patient réel
Pour ceux qui se sont connectés mais n'ont pas encore intégré l'outil dans leur pratique. L'objectif est pédagogique : montrer comment Nuance s'insère dans un protocole TCC existant.
| Step | Sujet | Angle |
|---|---|---|
| 1 | "Un premier pas avec vos patients sur Nuance ?" | Le patient virtuel 'Mes exercices' |
| 2 | "Le saviez-vous ? (Colonnes interactives)" | Les colonnes déverrouillables |
| 3 | "Dernier petit conseil pour votre pratique" | La note 'à chaud' sur mobile |
Chaque email enseigne une seule chose. Une. C'est suffisant pour déclencher une action.
La condition de sortie : créer un vrai patient
Les deux séquences s'arrêtent dès qu'un thérapeute crée son premier vrai patient (hors espace personnel). La requête SQL vérifie ça à chaque passage du cron :
SELECT u.*, s.last_step, s.last_sent_at,
(SELECT COUNT(*) FROM patients p
WHERE p.therapist_id = u.id
AND p.is_therapist_self = 0) as real_patient_count
FROM users u
LEFT JOIN user_onboarding_sequence s ON u.id = s.user_id
WHERE (
s.last_step IS NULL
OR (s.last_step < 3 AND (s.last_sent_at IS NULL
OR s.last_sent_at <= DATE_SUB(NOW(), INTERVAL 7 DAY)))
)
AND u.created_at <= DATE_SUB(NOW(), INTERVAL 2 DAY)
AND u.unsubscribed_at IS NULL
Dès que real_patient_count > 0, l'utilisateur sort de la sélection. Les emails s'arrêtent. Pas de relance sur quelqu'un qui est déjà actif.
L'unsubscribe : non négociable
Chaque email contient un lien de désinscription. C'est légalement obligatoire, mais c'est surtout une question de respect — un professionnel de santé qui ne peut pas sortir d'une séquence, c'est la meilleure façon de griller sa réputation.
Le token est regénéré dans le bloc try, juste avant l'envoi. Pas avant. Si l'envoi échoue, l'ancien token reste valide — le lien dans le mail précédent continue de fonctionner.
try {
$unsubToken = bin2hex(random_bytes(16));
dbExecute(
"UPDATE users SET unsubscribe_token = ? WHERE id = ?",
[$unsubToken, $user['id']]
);
// génération du mail + envoi
// mise à jour de la séquence seulement si succès
}
Petit détail, vraie conséquence si on l'oublie.
La stack
- PHP — backend, création de compte, génération des tokens, templates email
-
PHP CLI + Crontab — séquence de relance,
0 8 * * * -
MySQL —
users,pending_welcome_emails,user_onboarding_sequence - PHPMailer — envoi SMTP
Rien d'exotique. Pas de queue manager, pas de worker asynchrone. Un cron, quelques tables, et une logique de ciblage bien pensée. Le tout tourne sur un hébergement mutualisé standard.
Le principe est simple : chaque étape du parcours utilisateur doit pouvoir se dérouler sans moi. Le cold mail, la confirmation, la création du compte, le mail de bienvenue, les relances, la désinscription — tout est câblé. Je reçois des notifications, je lis des stats. C'est tout.
Ce n'est pas de la flemme. C'est une décision de conception.
Je suis développeur avant d'être commercial. Ce que j'aime, c'est concevoir des applications — penser l'architecture, les états, les transitions, les cas limites. Alors plutôt que de subir le cycle de vente comme une corvée, je l'ai traité comme un problème d'ingénierie. Ce flow d'onboarding est une application : elle a des entrées (le cold mail), des états (inscrit, activé, patient créé), des transitions (les emails de relance), et une condition de sortie (l'utilisateur actif).
Le résultat : je passe mon temps à ce pour quoi je suis fait. Le reste tourne tout seul.
Top comments (0)