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 refont l'onboarding. Elles A/B testent le wording des prompts. Rien ne change.
Parce que le problème n'est pas là.
La rétention produit IA à J+7 n'est pas un problème de modèle. C'est un problème d'architecture. L'IA est au mauvais endroit dans le parcours utilisateur.
Les 4 patterns qui tuent la rétention produit IA
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.
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.
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.
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.
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 pour diagnostiquer votre architecture
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.
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.
Architecturer l'IA de l'intérieur change tout
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, le rétrofit est coûteux.
- Greffée sur un flux existant
- Accessible mais pas naturelle
- Pas de contexte utilisateur
- Valeur perçue décroissante
- Rétention chute à J+7
- 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 produit IA
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.
La rétention produit IA 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."