J+7
le moment où
vos utilisateurs partent
C'est le pattern qu'on retrouve sur presque tous les produits IA qu'on audite. Les 7 premiers jours : engagement fort, curiosité, effet "wow". Puis la courbe chute. Pas progressivement — brutalement. Et les équipes cherchent la cause au mauvais endroit.
Elles ajustent le modèle. Elles refonnt l'onboarding. Elles A/B testent le wording des prompts. Rien ne change.
Parce que le problème n'est pas là.
Le vrai diagnostic
La rétention à J+7 n'est pas un problème de modèle IA. C'est un problème d'architecture produit. L'IA est au mauvais endroit dans le parcours utilisateur.
Les 4 patterns qui tuent la rétention
En auditant des dizaines de produits IA ces deux dernières années, on a identifié quatre configurations qui reviennent systématiquement. Chacune a l'air raisonnable au moment de la conception. Chacune tue la rétention après la première semaine.
L'IA en sidebar — le "chatbot collé dessus"
L'utilisateur fait son travail dans le produit. L'IA est accessible via un bouton, un panneau latéral, ou un widget. Elle n'est pas dans le flux — elle est à côté.
Ce qu'il se passe réellement : les premiers jours, l'utilisateur explore la sidebar par curiosité. Après une semaine, il a oublié qu'elle existe. L'IA n'est jamais devenue un réflexe parce qu'elle n'est jamais devenue une étape naturelle du parcours.
✓ Ce qu'on fait à la place
L'IA doit intervenir au moment précis où l'utilisateur en a besoin — pas quand il pense à l'appeler. Ça veut dire l'intégrer dans les actions existantes, pas créer une action supplémentaire.
La valeur arrive trop tard dans le parcours
L'utilisateur doit d'abord créer son compte, remplir un profil, importer des données, configurer ses préférences — et c'est seulement après qu'il voit ce que l'IA peut faire.
Le problème : il a dépensé de l'énergie sans avoir reçu de valeur. Son niveau d'exigence est déjà élevé quand la fonctionnalité IA apparaît enfin. Et si elle déçoit à ce moment-là — même légèrement — il ne revient pas.
✓ Ce qu'on fait à la place
La première interaction avec l'IA doit arriver dans les 3 premières minutes de l'onboarding. Pas comme une démo — comme une valeur réelle, sur les données réelles de l'utilisateur.
L'IA fait tout — et donc rien de mémorable
"Notre IA peut faire X, Y, Z, W, et bien plus encore." Résultat : l'utilisateur ne sait pas quoi lui demander. Il teste vaguement, obtient des résultats vaguement satisfaisants, et ne voit jamais la magie.
Un produit IA qui fait tout ressemble à un couteau suisse dans un restaurant étoilé. La polyvalence est impressionnante. La précision, non.
✓ Ce qu'on fait à la place
Un cas d'usage primaire, exécuté à la perfection. L'IA doit avoir un "moment signature" — celui dont l'utilisateur parle à ses collègues le lendemain. Les autres cas d'usage viennent ensuite, progressivement.
L'IA ne s'améliore pas avec l'usage
L'utilisateur revient le jour 3, le jour 5, le jour 7. L'IA lui propose la même expérience qu'au jour 1. Elle ne se souvient pas de lui. Elle n'a pas appris de ses interactions. Elle ne personnalise rien.
C'est le problème du produit IA traité comme un outil — et non comme un système qui apprend. L'effet "wow" du jour 1 n'est pas un avantage compétitif si l'expérience ne progresse pas.
✓ Ce qu'on fait à la place
Architecturer une boucle de personnalisation dès le départ : l'IA doit collecter des signaux implicites à chaque interaction et les réutiliser. L'utilisateur doit sentir que le produit le connaît mieux à chaque session.
Le test des 3 questions
Avant de regarder les cohortes ou d'analyser les logs, on commence toujours par trois questions simples. Elles révèlent le pattern en moins de 10 minutes.
✕
Est-ce que l'utilisateur doit initier l'interaction avec l'IA ? Si oui — l'IA est en sidebar. Elle mourra après J+7.
✕
Est-ce que la valeur IA arrive après 3 étapes d'onboarding ou plus ? Si oui — vous demandez de la confiance avant d'avoir donné de la valeur.
✕
Est-ce que l'expérience au jour 7 est identique à l'expérience au jour 1 ? Si oui — votre produit n'a pas de mémoire. L'utilisateur non plus, bientôt.
✓
Si vous répondez non aux trois — votre architecture est solide. Le problème de rétention vient d'ailleurs. On peut aller chercher plus loin.
Ce qu'on observe
Dans 80% des cas, au moins deux de ces trois questions reçoivent un "oui". Ce n'est pas une critique de l'équipe — c'est la conséquence naturelle de construire l'IA après le produit, plutôt qu'avec lui.
Ce que ça change de construire l'IA de l'intérieur
La distinction n'est pas technique. Elle est architecturale — et elle se prend au moment du cadrage, pas au moment du développement. Une fois le produit construit, la rétrof est coûteuse.
❌ IA ajoutée après
Greffée sur un flux existant
Accessible mais pas naturelle
Pas de contexte utilisateur
Valeur perçue décroissante
Rétention chute à J+7
✓ IA architecturée dedans
Dans le flux, pas à côté
Se déclenche au bon moment
Apprend de chaque interaction
Valeur perçue croissante
Rétention se renforce après J+7
Les résultats quand on corrige l'architecture
Sur les projets où on a repris l'architecture IA après un problème de rétention, voici ce qu'on observe systématiquement dans les 6 semaines suivant la correction.
×2,4
rétention à J+7 après repositionnement de l'IA dans le flux
-60%
de tickets support liés à la compréhension de la valeur IA
J+3
premier "moment signature" atteint en moyenne après refonte
À retenir
La rétention ne se répare pas avec du marketing ou du copywriting. Elle se construit dans l'architecture du produit — avant la première ligne de code.
"L'utilisateur ne revient pas parce que votre IA est impressionnante. Il revient parce qu'il ne peut plus s'en passer."