Passer au contenu
megapromotingDiscutons
Produits Cronberry

Information et coordination Développement & démonstrations

D’une information dispersée, un contexte de travail.

Cronberry réunit des sources autorisées, des conversations et des relations dans un espace de recherche et de coordination. La recherche sémantique et les agents aident l’équipe à trouver ce qui compte et à préparer l’étape suivante.

DocumenteConversațiiSurseSintezăAcțiuneEchipăContexteazăSurse autorizate. Acțiuni revizuite.
Cum funcționează Cronberry

Cronberry

De l’information au travail accompli.

01

Surse

Nous sélectionnons les sources et l’accès autorisé : documents, canaux et conversations pertinents.

02

Context

Nous organisons l’information par sujets, relations et projets, avec la possibilité de revenir à la source.

03

Coordonare

Nous préparons des synthèses et des actions pour révision, connectées au flux de travail de l’équipe.

Là où il devient utile.

Recherche et radar thématique

Le suivi des sujets d’intérêt et la récupération de l’information pertinente.

Relations et opportunités

Le contexte des interactions autorisées, dans un lieu accessible à l’équipe.

Le lien avec FlowMind

Nous explorons le pont entre l’information textuelle, les sujets suivis et le contexte géospatial.

Nous présentons la direction et les fonctions développées. L’implémentation, les sources connectées et la disponibilité se définissent dans le cadre d’une démonstration. L’accès aux données est contrôlé.

Cronberry en détail

Ce que vous pouvez faire avec ce projet.

Cronberry est un moteur d’intelligence relationnelle, pas un outil de recherche dans les documents. Il part d’une archive de conversations Telegram et en construit un graphe de connaissances dans Neo4j : contacts, entreprises, groupes, canaux, opportunités, campagnes, produits, lieux, événements et sujets — dix types d’entités — liés par huit types de relations, parmi lesquelles « connaît », « travaille sur », « a promis » et « s’est opposé à ».

Trois éléments le distinguent d’un CRM : les jumeaux numériques, c’est-à-dire des profils générés à partir de l’historique des messages d’une personne, avec lesquels vous pouvez parler pour anticiper une réaction ; un optimiseur qui teste deux variantes de message sur ces profils avant que vous n’envoyiez quoi que ce soit à une personne réelle ; et un simulateur Monte Carlo qui exécute un plan de travail des centaines de fois et renvoie une distribution de résultats, pas une seule valeur.

Il faut dire clairement quel type de chiffres il produit : des prédictions, pas des mesures. Quand le moteur renvoie une probabilité de réponse ou un intervalle de confiance, ce sont des sorties de la simulation. Dans le code, il existe la structure qui devrait comparer la prédiction à ce qui s’est réellement passé — `AccuracyStats`, avec taux de précision et calibration de la confiance — mais je n’ai trouvé dans le repo aucune série de mesures réelles pour la remplir. Tant qu’elle n’existe pas, les chiffres se lisent comme des hypothèses de travail.

01

Graphe de connaissances basé sur des relations réelles

Neo4j 5, avec une ontologie fixe de dix types d’entités et huit types d’arêtes, plus un mode dans lequel l’ontologie peut être générée par un modèle pour des analyses ponctuelles. L’enrichissement s’exécute en quatre passages : scores d’influence de type PageRank, détection de communautés par propagation d’étiquettes, pondérations d’arêtes à partir de la fréquence des messages et arêtes de type « a mentionné » extraites des motifs `@utilisateur` dans le texte des messages.

02

Jumeaux numériques avec mémoire à trois niveaux

Un profil généré à partir de l’historique d’un contact, avec mémoire courte, mémoire longue et mémoire de relation. Trois modes d’utilisation : conversation libre, préparation de négociation et prédiction de réponse.

03

Test d’un message avant son envoi

L’optimiseur réécrit un message vers un objectif déclaré et peut comparer deux variantes. Le test de stress pousse l’idée plus loin : il exécute des paramètres tels qu’une hausse de prix ou une pression de délai à plusieurs intensités et renvoie les zones où le contact réagit bien et celles à éviter.

04

Simulation Monte Carlo sur un plan écrit

Le plan entre sous forme de texte, avec la liste de contacts, le nombre d’itérations et l’horizon en jours. En sortent une probabilité de réussite avec intervalle de confiance, les points où le plan se bloque et la raison de chaque blocage. Les simulations ont un checkpoint, donc une exécution longue peut être reprise.

05

Les droits de la personne, implémentés comme des endpoints

Le module GDPR n’est pas une page de politique : il comporte un export complet des données d’un contact (art. 15 et 20), une suppression qui s’applique simultanément dans SQLite, dans Neo4j, dans les prédictions et dans le registre de consentement, avec journal de suppression (art. 17), rectification (art. 16), état et révocation du consentement, le registre des activités de traitement (art. 30) et un endpoint d’explication d’une prédiction, pour l’exigence de transparence du règlement européen sur l’IA.

06

Le coût du modèle, comptabilisé

Le client de modèle tient un compteur de coût par appel et un cache en mémoire avec expiration à 3600 secondes et au maximum 512 entrées, plus un limiteur propre de requêtes par minute vers le fournisseur. Le modèle principal est Azure OpenAI, avec Groq comme variante rapide de secours.

Données et fonctionnement

Ce qui entre dans le système. Ce qu'il faut vérifier.

Le corpus actuel est privé et personnel
Le chemin dans la configuration de démarrage indique une base SQLite avec l’historique Telegram personnel. Cela convient au développement et est totalement inadapté à un service : une implémentation chez un client commence avec ses sources, avec l’objectif déclaré et avec la base de traitement, pas avec ce corpus.
Deux dépôts, une seule suppression
Les données se trouvent dans SQLite (la source) et dans Neo4j (le graphe), et les prédictions dans un troisième endroit. La suppression à la demande les touche tous les trois, plus le registre de consentement, et écrit un journal — car une suppression qui laisse la copie dans le graphe n’est pas une suppression.
Ce qui protège le service à l’entrée
Limitation de requêtes avec un seau de jetons : 100 requêtes sur 60 secondes par adresse IP, globalement, plus des limites plus strictes sur les endpoints coûteux. En-têtes de sécurité stricts, avec une politique de contenu qui bloque les scripts et les cadres, HSTS pendant un an avec sous-domaines et politique d’autorisations qui ferme la caméra, le microphone, la localisation et les paiements. Les origines autorisées se configurent via une variable d’environnement.
Ce manque à l’entrée, et c’est important
L’authentification. Dans votre propre plan de sécurité, le chapitre d’authentification et d’autorisation est entièrement non coché : sans validation de jeton sur les endpoints du moteur, sans rôles, sans clés API stockées sous forme de hash, sans blocage en cas de tentatives répétées. Tant que ce n’est pas résolu, le moteur fonctionne derrière un réseau contrôlé, pas sur Internet.

De l'exploration à l'implémentation

Comment nous préparons un projet avec Cronberry.

01

D’abord la source et le fondement, puis le code

La première étape n’est pas technique : quelles données l’organisation a le droit de traiter, dans quel but et pour combien de temps. Le corpus de développement n’est pas réutilisé.

02

Nous construisons le graphe à partir des données du client

Import dans Neo4j, puis les quatre passes d’enrichissement. L’ontologie fixe couvre le modèle de CRM sur Telegram ; pour un autre type de contenu, une ontologie spécifique peut être générée.

03

Nous fermons la porte avant toute exposition

L’authentification, les rôles et les clés stockées sous forme de hash sont une condition de lancement, pas une amélioration ultérieure. La limitation des requêtes et les en-têtes de sécurité existent déjà et restent actives.

04

Nous calibrons les prédictions sur des résultats réels

La structure de mesure de la précision existe dans le code. Un pilote utile signifie enregistrer ce que le moteur a prédit et ce qui s’est passé, jusqu’à ce que les chiffres aient un historique derrière eux.

Des questions qui méritent d’être clarifiées.

Puis-je aller sur cronberry.ai pour voir ?

Non, et ce n’est pas un problème temporaire de serveur. Le domaine ne se résout pas du tout : la requête DNS renvoie NXDOMAIN, et le registre .ai répond `Domain not found` — vérifié le 6 septembre 2026. Le serveur indiqué dans la documentation du projet, `74.248.16.185`, ne répond pas non plus sur le port du moteur. Ce qui existe et peut être montré : le code, qui fonctionne en local, et une démonstration préparée sur un jeu de données convenu.

Le site le décrit comme un espace de travail pour les documents et la recherche sémantique. C’est bien ça ?

Non, et c’est une erreur que nous corrigeons. Le projet n’est pas un moteur de recherche sur des documents. C’est un moteur d’intelligence sur les relations, construit à partir d’une archive de conversations : graphe Neo4j, profils de contact générés à partir de l’historique, test de messages sur ces profils et simulation Monte Carlo sur un plan. Le texte du site décrit un produit différent du code existant.

Que signifie « probabilité de réponse 0,67 » ?

Cela signifie un résultat de simulation, pas une mesure. Le moteur exécute le plan des centaines de fois sur des profils générés à partir de l’historique et en rapporte la distribution. Dans le code, il existe la structure qui comparerait la prédiction à la réalité — taux de précision et calibration de la confiance — mais nous n’avons trouvé aucune série de mesures pour la remplir. Donc le chiffre sert à classer des options entre elles, pas à promettre un résultat.

Peut-il fonctionner sur les données de nos clients, pas sur une archive personnelle ?

Oui, mais c’est la première étape de toute implémentation, pas une adaptation de fin. Le corpus actuel de développement est une archive Telegram personnelle, indiquée directement dans la configuration de démarrage, et il n’est pas réutilisé. L’import part des sources de l’organisation, avec un objectif et un fondement de traitement établis à l’avance.

Que se passe-t-il lorsqu’une personne demande la suppression des données ?

Il existe un endpoint dédié, et la suppression n’est pas partielle : elle touche SQLite, Neo4j, les prédictions générées sur cette personne et le registre de consentement, et écrit un journal de suppression. L’export complet, la rectification, l’état du consentement, le registre des traitements et l’explication d’une prédiction sont également implémentés.

Est-ce prêt à être exposé sur internet ?

Non, et la raison est précise : l’authentification. Le chapitre d’authentification et d’autorisation de votre propre plan de sécurité est entièrement non coché — il n’y a pas de validation de token sur les endpoints du moteur, de rôles, de clés API stockées sous forme de hash ou de blocage après des tentatives répétées. Ce qui existe déjà : une limitation à 100 requêtes par 60 secondes et par IP, des limites plus strictes sur les endpoints coûteux, des en-têtes de sécurité stricts et des origines configurables. Avec la porte d’entrée fermée, la discussion sur le lancement devient réelle.

La documentation interne coche beaucoup de choses comme faites. Peut-on le vérifier ?

Partiellement, et cela mérite d’être dit. La liste de sécurité renvoie à des fichiers qui n’existent pas dans le dépôt (`swarm_api.py`, `security_middleware.py`, `gdpr_routes.py`). Le code correspondant existe pourtant, mais ailleurs : `cronberry_swarm/security/rate_limiter.py`, `headers.py` et `gdpr.py`. Donc les coches décrivent une fonctionnalité réelle, mais les références sont fausses — je les ai suivies dans le code, pas dans la liste.

Exemple illustratif

Un plan de travail passé par simulation avant d’être lancé

Un scénario d’utilisation, sans données client ni résultats commerciaux attribués.

Situation initiale

Une équipe rédige un plan en texte — qui contacter, dans quel ordre, sur quel canal — et choisit la liste de contacts, le nombre d’itérations et l’horizon en jours.

Comment ça fonctionne

Le moteur exécute le plan des centaines de fois sur les profils générés à partir de l’historique de chaque contact, sur le modèle de la plateforme Telegram. L’exécution a un checkpoint, donc elle peut être reprise si elle est interrompue.

Rezultatul

Une probabilité de réussite avec un intervalle de confiance, la liste des étapes où le plan se bloque et la raison de chaque blocage, ainsi que l’ordre suggéré des contacts. Tout cela sont des sorties de simulation, à utiliser pour comparer des variantes entre elles.

Ce este necesar:Sursă de date proprie a organizației, cu scop și temei de prelucrare stabilite; Neo4j pornit și graful importat; cheie de model configurată. Nu există azi o instanță publică pe care să rulezi asta.

Possibilités de collaboration

Cronberry, dans le contexte de votre organisation.

Flux internes et information

Connexion des sources autorisées, organisation de l’information et revue des actions par l’équipe, avec accès séparé par rôles.

Entreprises privées

Nous définissons un pilote autour d’un processus réel : utilisateurs, données, intégrations, coûts et critères d’acceptation. L’extension suit après l’évaluation du résultat.

Institutions et entreprises publiques

Nous établissons les exigences d’accessibilité, d’hébergement, de protection des données et d’interopérabilité. Toute connexion avec des services AGE ou STISC nécessite la validation de l’éligibilité, de l’accès et des approbations.

Ce sont des scénarios d’adaptation, non des déclarations sur des contrats ou partenariats existants. Les fonctions proposées sont confirmées dans le périmètre de travail du projet.

Discuter d'un pilote

Faisant partie d’un écosystème.

Qu'est-ce que vous voudriez voir mieux fonctionner ?

Racontez-nous votre processus. Ensemble, nous décidons ce qui vaut la peine d'être construit, ce que nous pouvons connecter et comment nous vérifions le résultat.

Discutons