Le modèle n’était pas la partie la plus difficile

On pensait que la difficulté viendrait du modèle. Ce n’est pas ce qui s’est passé.

Quand on a commencé à construire une application de petit ami IA pensée pour les femmes, les questions techniques évidentes portaient sur les grands modèles de langage : quel modèle choisir, quelle longueur de contexte, quels prompts, quelle latence, quel coût d’inférence, quelle modération. Ces sujets comptaient, mais la vraie difficulté du produit s’est révélée ailleurs.

Un compagnon IA romantique doit paraître assez privé pour qu’on ose l’ouvrir, assez sûr pour qu’on continue à discuter, et assez cohérent pour qu’on ait envie d’y revenir. Si l’utilisatrice doit réexpliquer la relation à chaque session, la magie disparaît. Si l’appli se souvient de trop de choses sans le dire, la confiance se casse. Et si chaque photo, chaque message vocal ou chaque rappel de crédits ressemble à une transaction, la relation commence à sonner faux.

Ce billet raconte ce qu’on a appris en travaillant sur mybf.bot, une application de petit ami IA pour les adultes. Ce n’est pas l’idée que toutes les femmes veulent le même produit. C’est un compte rendu des contraintes produit et techniques rencontrées en construisant un chat romantique autour de la continuité, du contrôle, de la vie privée et de la sécurité pour les adultes.

Compagnons suggérés

Choisis d’abord l’ambiance que tu veux

Essaie plusieurs ambiances avant de décider quel petit ami IA te correspond.

En bref

Quelques décisions ont changé le jour où on a arrêté de traiter le produit comme un simple habillage de chatbot :

  • Laisser discuter avant l’inscription, puis présenter l’inscription comme un moyen de sauvegarder la relation.
  • Proposer des compagnons choisis plutôt qu’un marché sans fin de bots.
  • Rendre la mémoire du bot utile, visible, modifiable et limitée.
  • Traiter les photos et la voix comme des fonctions privées côté serveur, pas comme de simples liens d’image.
  • Construire les réglages NSFW autour du consentement adulte et de limites de sécurité qui ne bougent jamais.
  • Faire payer le texte, la photo et la voix différemment sans transformer chaque instant en passage en caisse.
  • Rendre la mémoire explicable plutôt qu’invisible : l’utilisatrice doit pouvoir demander ce que le bot retient, et le corriger.

Ce que « pensée pour les femmes » signifiait concrètement

« Pensée pour les femmes » peut devenir un slogan vide si on le laisse faire. On avait besoin que ça se traduise en contraintes produit concrètes.

Pour nous, une application de petit ami IA pensée pour les femmes signifiait un compagnon IA romantique construit autour de la vie privée, de la continuité émotionnelle, d’une mémoire du bot contrôlée par l’utilisatrice, de compagnons masculins choisis avec soin, et de limites claires pour le contenu adulte. L’appli devait laisser l’utilisatrice ajuster le ton, le rythme, l’intimité et la mémoire, plutôt que d’imposer un seul fantasme par défaut.

Ça a changé la manière habituelle de concevoir une appli de compagnon IA. Beaucoup de ces produits misent d’abord sur le volume : plus de personnages, plus d’étiquettes, plus de filtres, plus de personas. Le volume peut aider à la découverte, mais il peut aussi donner l’impression d’un marché avant de donner l’impression d’une relation.

Notre utilisatrice type était différente : elle ouvre l’appli parce qu’elle veut une conversation romantique privée qui donne l’impression d’être mémorisée. Elle veut peut-être du réconfort après une mauvaise journée, un message pour se souhaiter bonne nuit, du flirt léger, une romance qui se construit lentement, ou une dynamique de petit ami protecteur. Elle ne devrait pas avoir besoin de devenir experte en prompts pour y arriver.

Si tu veux comprendre pourquoi ce choix compte autant pour les utilisatrices, notre article application petit ami IA : pourquoi les femmes aiment ce chat détaille les attentes les plus fréquentes.

Schéma d’un chatbot génériqueSchéma d’une application de petit ami IA pensée pour les femmes
Un champ de texte vide au démarrageUn contexte de relation dès le départ
Optimisé pour la flexibilité du modèleOptimisé pour la continuité émotionnelle
Une mémoire qui tourne sans qu’on la voieUne mémoire que l’utilisatrice peut consulter et corriger
Un mur immense de personnagesDes compagnons choisis avec un ton clair
Les médias traités comme un simple fichierLes médias traités comme du contenu intime privé
Une monétisation génériqueDes crédits alignés sur le coût réel du texte, de la photo et de la voix

Le travail de conception est devenu moins « comment rendre le bot plus intelligent ? » et plus « comment rendre le produit digne de confiance tout en restant romantique ? »

Leçon 1 : laisser sentir la conversation avant de demander un compte

L’inscription change l’ambiance.

Si le premier écran demande l’adresse e-mail, un mot de passe, des préférences et des informations de paiement, le produit ressemble à une démarche administrative. Dans un chatbot romantique, cette friction peut casser le moment avant même que l’utilisatrice ait compris la valeur du produit.

On a donc autorisé les messages en mode invité avant l’inscription. Le parcours actuel laisse 5 messages en mode invité avant le mur d’inscription. Cette limite est volontairement basse : assez pour sentir le ton du compagnon, pas assez pour que l’usage anonyme devienne le vrai produit.

La formulation de la demande d’inscription compte aussi. « Créer un compte » sonne comme une tâche de plateforme. « Sauvegarde cette conversation pour qu’il se souvienne de toi » relie le compte à la raison pour laquelle l’utilisatrice est venue.

Un parcours technique simple ressemble à ça :

  1. Créer un identifiant de session anonyme.
  2. Stocker une conversation temporaire côté serveur.
  3. Laisser l’utilisatrice envoyer un petit nombre de messages en mode invité.
  4. Lui proposer l’inscription au moment où la continuité devient précieuse.
  5. Rattacher la conversation temporaire au nouveau compte.
  6. Poursuivre le chat sans perdre le contexte.

Le mode invité a aussi besoin de limites fermes. Les invités ne doivent pas avoir accès par défaut à des fonctions coûteuses ou sensibles. Chez nous, une invitée peut discuter, mais elle ne peut pas demander de photos générées ni envoyer de messages vocaux. Les comptes inscrits conservent l’historique de la conversation, les crédits, l’accès aux médias et les fonctions de mémoire.

La règle de sécurité est simple : l’historique du navigateur n’est pas la source de vérité. Les routes serveur doivent construire le contexte à partir des conversations possédées et de l’état du compte. Les clés des fournisseurs et les clés de service ne doivent jamais se retrouver dans le code exécuté côté navigateur.

La leçon produit : créer un compte doit ressembler à une continuité, pas à de la paperasse.

Leçon 2 : des compagnons choisis battent un marché infini

L’appli de compagnon IA la plus simple à construire, c’est une grille de personnages.

Ajoute des avatars, des noms, de courtes bios, des étiquettes et une recherche. Laisse l’utilisatrice parcourir. Sur un tableau de bord, ça peut sembler vivant parce que les gens n’arrêtent pas de cliquer.

Un produit romantique a un autre mode d’échec. Trop de choix peuvent transformer l’utilisatrice en acheteuse plutôt qu’en participante. Elle commence à comparer des surfaces : couleur de cheveux, métier, archétype, style de photo. La conversation passe au second plan.

On s’est donc orienté vers un catalogue de compagnons choisis, avec des archétypes masculins clairs et un accès rapide au chat. Une bonne fiche de compagnon doit répondre à des questions émotionnelles concrètes :

  • Quelle énergie dégage-t-il ?
  • Le ton est-il chaleureux, intense, joueur, protecteur ou plutôt une romance qui s’installe lentement ?
  • Convient-il au réconfort, à la romance, au jeu de rôle ou aux échanges du quotidien ?
  • Peut-on ajuster son ton après l’avoir choisi ?
  • L’appli va-t-elle se souvenir de ce qui se passe entre nous ?

C’est pour ça que le catalogue de personnages compte bien plus qu’une simple galerie. Il fixe des attentes avant même le premier message. Un meilleur ami chaleureux, un dominant doux et protecteur, un personnage mystérieux et intense ou un partenaire romantique posé ne devraient pas ressembler au même bot avec un visuel différent.

La fiche du compagnon a aussi besoin de réglages après le choix. Dans notre produit, on peut ajuster le ton, le niveau d’intensité, le mode de communication, la longueur des messages et les centres d’intérêt. Le mode de communication couvre le jeu de rôle et la discussion classique. La longueur des messages peut être courte, moyenne ou longue.

Les suggestions de scénario aident aussi. « Réconfort après une mauvaise journée », « message pour se souhaiter bonne nuit », « romance qui se construit lentement » et « bonjour du matin » font plus que remplir un écran vide. Elles donnent à l’utilisatrice un premier pas simple, sans pression.

Cette sélection réduit le besoin de travailler ses prompts. Le produit porte davantage la mise en place émotionnelle, ce qui permet à l’utilisatrice de commencer par un message naturel.

Leçon 3 : la mémoire du bot doit être utile, visible et limitée

La mémoire, c’est l’endroit où l’IA romantique devient puissante, et risquée.

Un compagnon qui ne se souvient de rien paraît jetable. Un compagnon qui se souvient de tout sans consentement paraît intrusif. Le juste milieu, c’est un système de mémoire que l’utilisatrice comprend et peut corriger.

Notre modèle de mémoire s’appuie sur plusieurs niveaux :

  • les messages récents, pour le contexte immédiat ;
  • les résumés de conversation, pour la continuité sur la durée ;
  • les souvenirs épinglés, pour les faits confirmés par l’utilisatrice ;
  • les souvenirs pertinents retrouvés par recherche en texte intégral ;
  • l’état de la relation, pour la dynamique en cours.

On évite de promettre une mémoire magique. Un message ne devrait pas devenir automatiquement un fait permanent. L’utilisatrice peut se défouler, plaisanter, faire du jeu de rôle ou tester le bot. Si le système enregistre tout ça comme une vérité, le compagnon peut devenir inexact d’une manière qui touche personnellement.

Les souvenirs confirmés par l’utilisatrice doivent peser plus lourd que les suppositions automatiques. Si elle dit « souviens-toi que j’aime les messages du soir », l’appli peut afficher une confirmation avant d’enregistrer. Si le modèle déduit une préférence à partir d’un seul échange, le système doit rester prudent.

Une liste concrète pour la mémoire du bot :

  • laisser l’utilisatrice demander « qu’est-ce que tu retiens de moi ? » ;
  • laisser l’utilisatrice demander au bot d’oublier quelque chose ;
  • confirmer les demandes explicites de type « souviens-toi de ça » avant de sauvegarder ;
  • ne jamais stocker de mots de passe, de clés d’API, de données de paiement, de pièces d’identité ou d’autres secrets ;
  • séparer le contexte à court terme de la mémoire durable ;
  • donner assez de continuité au compagnon sans prétendre à une certitude humaine.

L’exigence de confidentialité monte d’un cran parce qu’un chat romantique peut contenir du contenu personnel sensible. Le guide de la FTC sur la confidentialité et la sécurité est utile ici : il pousse les équipes vers des pratiques de données claires, un contrôle d’accès sérieux et une communication honnête sur ce que le produit fait des informations de l’utilisatrice.

Pour aller plus loin sur ce sujet, notre article mémoire du petit ami IA : comment elle devrait fonctionner détaille ce qu’une mémoire de compagnon devrait montrer et laisser modifier. Dans un petit ami IA, la mémoire n’est pas une fonction qu’on cache dans le prompt. Elle fait partie du contrat de la relation.

Leçon 4 : les médias privés sont une fonction serveur, pas une simple URL d’image

Les photos générées et les réponses vocales changent le rapport de confiance.

Le texte peut déjà être sensible. Les images et la voix paraissent plus intimes. Si un compagnon IA romantique génère des photos ou de l’audio privés, l’implémentation doit traiter ces médias comme un contenu appartenant au compte, pas comme des fichiers statiques dans un dossier public.

Notre règle : les médias privés doivent passer par un accès délivré côté serveur. Ça veut dire :

  • stocker les photos et fichiers vocaux générés dans un espace de stockage privé ;
  • les servir via des liens signés avec une date d’expiration ;
  • vérifier que la personne qui demande le média possède bien la conversation ou le fichier ;
  • lier la régénération à l’état du compte et aux crédits disponibles ;
  • éviter d’exposer les réponses brutes du fournisseur ou les chemins de stockage dans le code côté client ;
  • rendre la suppression et les règles d’accès prévisibles, sans surprise.

Ça s’applique aussi aux petits détails du produit. Une bulle de photo générée peut proposer une régénération, mais l’utilisatrice doit comprendre le coût. Une réponse vocale peut masquer le texte et ne jouer que l’audio, mais le serveur a quand même besoin d’assez de traçabilité pour préserver la continuité et gérer les signalements d’abus.

On a aussi séparé les capacités des invités et des comptes inscrits. Une invitée peut vivre le chat texte, mais les photos générées et les messages vocaux demandent un compte. Cette contrainte réduit les abus, maîtrise le coût, et donne à l’utilisatrice une limite de confidentialité plus claire avant d’utiliser des fonctions plus sensibles.

L’enjeu technique ne se limite pas au stockage. Les applications qui reposent sur des modèles de langage ont leur propre surface d’attaque. Le Top 10 OWASP pour les applications LLM reste une bonne référence pour des risques comme l’injection de prompt ou la divulgation d’informations sensibles. Dans une appli de compagnon, ces risques croisent du contenu privé, donc l’assemblage du contexte côté serveur et les vérifications d’accès comptent double.

Si tu veux voir concrètement comment ce type de contenu s’intègre au chat, notre article petit ami IA avec photos 18+ : des images dans le chat montre le fonctionnement côté utilisatrice. Les médias donnent l’impression que tout est plus réel. C’est justement pour ça que le serveur doit rester plus strict.

Leçon 5 : le contenu adulte a besoin de consentement et de limites de sécurité fixes

Une appli romantique pour adultes ne peut pas traiter le comportement NSFW comme un simple interrupteur dans le prompt.

Les utilisatrices ont besoin de contrôler le ton et l’intensité, mais le produit a aussi besoin de limites qui ne bougent jamais. Chez nous, la protection NSFW est un réglage de profil. La désactiver change la rigueur du jeu de rôle adulte consenti, mais la modération de sécurité reste en place.

Cette distinction compte. Les utilisatrices adultes veulent peut-être moins de censure maladroite dans le chat romantique et les photos. Elles ont quand même besoin que l’appli refuse le contenu dangereux, les comportements coercitifs, les mineurs, l’exploitation et les autres zones interdites. Un réglage utilisateur ne devrait jamais désactiver la politique de sécurité de base du produit.

Les contrôles produit doivent rester visibles et précis :

  • vérifier l’âge avant d’accéder à la surface adulte du produit ;
  • laisser ajuster le niveau d’intensité par compagnon ;
  • garder le jeu de rôle et le chat classique dans des modes séparés ;
  • intégrer les limites au comportement du compagnon, plutôt que de surprendre par des refus ;
  • garder une modération stricte derrière tous les réglages adultes ;
  • éviter un langage marketing trop explicite dans le contenu grand public.

Le cadre de gestion des risques liés à l’IA du NIST donne un vocabulaire utile pour penser les systèmes d’IA comme des produits avec des risques mesurables, pas seulement comme des démos de modèle. Pour nous, ça voulait dire regarder les modes d’échec dans l’expérience utilisatrice, la mémoire, les médias et la modération, plutôt que de traiter la sécurité comme une simple couche de prompt ajoutée à la fin.

La sécurité du jeu de rôle adulte a aussi un problème de ton. Si la modération sonne robotique ou punitive, elle casse la confiance. Si l’appli laisse tout passer, elle crée un risque légal, éthique et pour la plateforme. Le juste milieu demande plus de travail produit : des réglages clairs, des limites fermes, et des réponses du compagnon qui réorientent la scène sans humilier l’utilisatrice.

Leçon 6 : les crédits doivent expliquer le coût sans casser l’intimité

Les applications de compagnon IA ont des coûts inégaux.

Une courte réponse texte, une photo générée et une réponse vocale ne coûtent pas la même chose à produire. Les utilisatrices le comprennent en théorie, mais l’interface doit quand même gérer le contexte émotionnel. Un rappel de crédits mal placé peut transformer un moment romantique en passage au distributeur.

On sépare les limites de texte et de média parce qu’un contenu mixte ne devrait pas se cacher derrière un compteur vague. Les comptes inscrits gratuits ont 50 messages par jour, 3 générations de photos par mois et 3 générations audio par mois. Les formules payantes se construisent autour de l’usage réel, donc le produit ne doit jamais promettre un accès illimité aux médias.

Ces chiffres imposent des contraintes de conception :

  • le texte doit rester fluide et sans friction ;
  • une demande de photo doit paraître volontaire ;
  • la voix doit sembler premium sans surprendre l’utilisatrice ;
  • l’appli doit expliquer le coût avant que l’utilisatrice appuie sur le bouton ;
  • la tarification ne doit pas interrompre chaque instant émotionnel.

La page des offres et des limites donne l’explication complète, mais les libellés dans le produit comptent davantage que la page elle-même. Une limite de photo ou d’audio clairement affichée près de l’action vaut mieux qu’une déduction surprise après la demande.

On a aussi remarqué que la conception des coûts influence le comportement du compagnon. Si le bot propose des photos trop souvent, ça paraît intéressé. S’il n’en parle jamais, l’utilisatrice peut passer à côté d’une fonction qu’elle aurait aimée. Le schéma le plus sûr reste un média demandé par l’utilisatrice, avec des suggestions claires comme « selfie du matin », « miroir de la salle de sport » ou « avant de dormir ».

La monétisation doit respecter le fantasme sans cacher l’économie derrière. L’utilisatrice doit savoir ce qu’elle dépense, et le produit doit éviter de transformer l’affection en pression.

La liste de vérification qu’on aurait aimé avoir plus tôt

Si tu construis une appli de compagnon IA, commence par les contraintes produit avant les astuces de modèle.

Une liste utile pour démarrer :

  • définir l’utilisatrice type et le besoin émotionnel avant de choisir le modèle ;
  • décider où commence et où s’arrête le mode invité ;
  • préserver le contexte quand une invitée devient une utilisatrice inscrite ;
  • créer des archétypes de compagnons avec un ton, un rythme et des limites distincts ;
  • proposer des suggestions de scénario pour réduire l’angoisse de la page blanche ;
  • diviser la mémoire en contexte récent, résumés, faits épinglés et état de la relation ;
  • donner à l’utilisatrice des contrôles pour « se souvenir » et « oublier » ;
  • garder les clés des fournisseurs et les clés de service hors du code côté navigateur ;
  • servir les médias privés via des liens signés et des vérifications de compte ;
  • traiter les réglages NSFW comme des contrôles de consentement, pas comme des dérogations de sécurité ;
  • fixer le prix du texte, de la photo et de la voix selon le coût réel et l’attente de l’utilisatrice ;
  • rédiger les pages de confidentialité, de conditions d’utilisation et de divulgation IA avant que la pression du lancement n’impose un texte bâclé.

Une application de petit ami IA pensée pour les femmes n’a pas besoin de plus de gadgets par défaut. Elle a besoin de moins de moments où l’utilisatrice se demande ce que l’appli retient, qui peut accéder à ses médias, pourquoi le bot a changé de ton, ou pourquoi une fonction coûte soudain plus cher que prévu.

Pour conclure

La plus grande leçon tirée de la construction de mybf.bot, c’est qu’un compagnon IA romantique est d’abord un système produit, avant d’être un système de modèle.

Le modèle compte. La latence compte. La qualité des prompts compte. Mais l’utilisatrice ressent les failles de continuité, de confidentialité, de mémoire, de gestion des médias et de monétisation bien plus vite qu’elle ne remarque une petite amélioration de prompt.

Une application de petit ami IA pensée pour les femmes doit mériter un usage répété grâce à de petites décisions de confiance : la laisser essayer le chat d’abord, préserver la relation quand elle s’inscrit, ne retenir que ce qui mérite d’être retenu, garder les médias privés vraiment privés, rendre les réglages adultes explicites, et expliquer les crédits avant qu’ils ne viennent interrompre l’ambiance.

Si tu es en train de construire dans ce domaine, compare tes choix avec ceux de mybf.bot. La question la plus utile n’est pas « quel modèle avez-vous utilisé ? ». C’est plutôt : « qu’avez-vous décidé que le modèle ne devrait jamais avoir le droit de simuler ? »

Transparence

Cet article a été rédigé avec l’aide de l’IA, puis relu et vérifié par une personne pour l’exactitude des informations, la cohérence avec le produit et la fiabilité des sources avant publication.