Créer le compte
L'inscription demande l'identifiant, l'email, le mot de passe et sa confirmation, l'entreprise, le secteur, le nom du site et son domaine. Les règles de sécurité Django contrôlent le mot de passe avant création.
Centre d'aide
Ce manuel décrit le fonctionnement réellement disponible : création de compte, essai gratuit, sécurité, sélection multi-site, dashboard, scoring, machine learning supervisé, leads, automatisations, connecteurs, consentement et conservation des données.
L'inscription demande l'identifiant, l'email, le mot de passe et sa confirmation, l'entreprise, le secteur, le nom du site et son domaine. Les règles de sécurité Django contrôlent le mot de passe avant création.
Un lien de confirmation valable sept jours est envoyé par email. L'essai reste accessible pendant la vérification, mais l'adresse doit être confirmée avant d'ajouter un autre site ou d'activer l'abonnement.
L'essai dure 60 jours, sans carte bancaire et sans prélèvement automatique. Des rappels sont prévus à J-15, J-7 et J-2.
Chaque site possède sa clé API. La détection technique de l'installation ne crée pas de session analytique.
La page Paramètres permet de modifier le prénom, le nom, l'identifiant, l'adresse email, l'entreprise et le secteur d'activité. Une modification d'adresse email déclenche une nouvelle vérification.
Cette zone permet de modifier le mot de passe après saisie du mot de passe actuel. Les règles de validation Django s'appliquent au nouveau mot de passe.
Les mots de passe sont hachés par Django et ne sont pas conservés en clair. Le changement de mot de passe est disponible dans les paramètres.
La page de connexion et les paramètres donnent accès à la réinitialisation par email.
Une modification d'adresse email impose une nouvelle vérification.
Les routes sensibles disposent d'une limitation persistante en base. La clé de limitation est hachée ; l'adresse IP n'est pas stockée en clair dans ce mécanisme.
Django Admin est réservé aux superutilisateurs. Les secrets serveur, clés privées et webhooks ne sont pas exposés aux clients.
Le sélecteur de site détermine le périmètre affiché. Sessions, prédictions, leads, opportunités, emails et modules sont limités au site sélectionné.
Résumé des données réelles du site sélectionné.
Les cartes de modules correspondent au site sélectionné, pas à tous les sites du compte.
Le dashboard indique si le site utilise actuellement le scoring à règles ou un modèle ML actif.
La vue d'ensemble n'affiche pas de compteurs fictifs. Les statistiques réelles sont dans le module e-commerce.
Une session regroupe les événements autorisés : pages vues, clics, durée, source, appareil et UTM. Le suivi analytique nécessite le marqueur de consentement attendu par l'API.
Une entreprise probable peut être déduite d'un domaine d'email ou d'un domaine référent. C'est un indice commercial à vérifier, jamais une identification certaine.
Sans modèle ML actif, PredictNeed IA applique des règles explicables à partir des signaux de session.
L'entraînement utilise uniquement les sessions du site dont le résultat commercial est connu : lead marqué Converti ou Perdu, ou opportunité liée marquée Gagné ou Perdu. Lorsqu'une opportunité possède un résultat final, ce résultat est prioritaire. Les sites ne sont pas mélangés dans un même modèle.
Il faut au moins 40 sessions résolues, dont au moins 10 conversions et 10 pertes. En dessous, aucun modèle n'est utilisé.
Le modèle est une régression logistique supervisée. Il est évalué sur un échantillon séparé et n'est activé que si les seuils de qualité configurés sont atteints.
Le moteur, la probabilité et la version du modèle sont enregistrés avec les prédictions produites par le ML.
Une probabilité de conversion n'est pas une certitude et ne remplace pas la qualification humaine.
Le simulateur public reste basé sur la grille de scoring de démonstration et n'utilise pas le modèle ML d'un client.
Un lead est créé lorsqu'une personne transmet volontairement un email ou un téléphone et accepte d'être recontactée au sujet de sa demande.
Lead reçu et pas encore traité.
Un échange commercial a commencé.
Résultat positif pouvant alimenter l'apprentissage ML.
Résultat négatif pouvant alimenter l'apprentissage ML.
Une opportunité CRM peut être créée depuis un lead puis avancer entre qualification, proposition, négociation, gagné et perdu.
Une vente réelle peut être enregistrée séparément du montant estimé. Une opportunité gagnée sans montant réel ne crée aucun chiffre d'affaires fictif.
Scoring, modèle ML lorsqu'il est éligible, probabilités, profils, intentions et leads prioritaires.
Segments comportementaux calculés sur le site sélectionné.
Événements produits, panier, achat et parcours réellement remontés.
Sessions, leads, sources, pages et funnel.
Évolution des sessions, prédictions, leads et opportunités par période.
Google, réseaux sociaux, email, accès direct et campagnes UTM.
Script, pixels et connexions externes disponibles lorsque leur configuration serveur existe.
Sessions publicitaires, UTM, intentions, leads et campagnes externes connectées.
Sites, modules, clés API masquées et consentements.
Le script contient la clé API propre au site. Le serveur refuse les clés invalides et vérifie le domaine lorsque l'origine est disponible.
Les connexions OAuth ne sont affichées que lorsque leur configuration serveur officielle est disponible. Chaque connexion externe est rattachée à un site précis : une synchronisation ne mélange jamais les campagnes de plusieurs sites. Les secrets restent côté serveur.
Les pixels Meta, Google Ads, TikTok, LinkedIn ou Pinterest ne sont chargés que si le retargeting est activé, qu'un identifiant existe et que le choix de confidentialité l'autorise.
La purge conserve par défaut les données analytiques détaillées pendant 395 jours et les leads pendant 1 095 jours. purge_donnees_rgpd reste une simulation tant que --execute n'est pas ajouté.
maintenance_quotidienne regroupe gestion des essais, purge réelle et nettoyage des anciennes limitations de sécurité. Chaque exécution est journalisée. L'ordonnanceur de production sera activé et vérifié après le déploiement final.
entrainer_modeles_ml peut être exécutée périodiquement et sort normalement sans erreur si les données sont insuffisantes.
Identifiant unique qui rattache un site à son espace.
Espace client limité au site sélectionné.
Transformation utilisée notamment pour les mots de passe et les clés de limitation.
Contact ayant transmis volontairement ses coordonnées.
Modèle appris à partir d'exemples dont le résultat est connu.
Estimation produite par le modèle ; elle ne garantit pas une conversion.
Calcul explicable utilisé immédiatement et comme solution de repli.
Session dont le résultat commercial est connu via un lead converti/perdu ou une opportunité gagnée/perdue.
Paramètres d'URL permettant d'identifier une source ou une campagne.
La première source, la campagne, les paramètres UTM, l'identifiant de clic et la page d'entrée d'une session sont conservés pour relier ensuite le lead et l'opportunité à leur origine marketing.
Parce qu'aucun modèle suffisamment alimenté et validé n'est actif pour ce site. C'est le comportement attendu.
Non. L'entraînement et l'inférence sont rattachés au site concerné.
Le compte et les paramètres restent accessibles et les données sont conservées, mais l'accès aux données payantes est verrouillé tant que l'abonnement n'est pas activé.
Utilisez le lien « Mot de passe oublié » pour recevoir un lien de réinitialisation par email.
Une plateforme OAuth n'est affichée que lorsque sa configuration serveur est présente.
Non. Les secrets Stripe restent internes au service.