John Data · Votre architecte data IA
Parlez de votre business. John construit vos rapports.
Vous expliquez ce que vous voulez mesurer. John connecte vos sources, organise vos données et construit le rapport. Chaque chiffre remonte à son origine.
Produit en développement · Premiers POC accompagnés et payants
« Quel est notre revenu récurrent ce mois-ci ? »
Vos sources connectées
John retrouve les données utiles.
Un modèle pour votre activité
John relie les données et vos règles métier.
Un rapport qui s’explique
Vous consultez, vérifiez et exportez.
01 / 04 Une question métier. Tout ce qu’il faut derrière la réponse.
02 / 04 · La démo
Du besoin au chiffre, avec John.
Un SaaS B2B veut comprendre son revenu récurrent. Voici comment le rapport prend forme.
Le rapport est calculé, ses données sont consultables
Avec John
ConversationVous · Fondateur
Salut John, on vend un logiciel B2B par abonnement, au mois ou à l’année. Peux-tu calculer notre revenu récurrent mensuel et expliquer l’écart entre avril et mai, hors taxes ?John
Je prépare le rapport et relie clients, abonnements et offres. Les abonnements annuels seront ramenés au mois. Où sont vos données ?
Vous · Fondateur
Tout est dans notre base PostgreSQL. J’ai autorisé un accès en lecture seule.John
Je me connecte avec l’accès autorisé et retrouve vos clients, abonnements et offres.
John
Je fais correspondre vos données au modèle, puis je les charge pour calculer le rapport.
John
Votre revenu récurrent passe de 40 000 à 45 000 € : +6 000 € de nouveaux clients, +2 000 € d’expansion et −3 000 € de résiliations. Vous pouvez remonter aux données derrière chaque chiffre.
Salut John, on vend un logiciel B2B par abonnement, au mois ou à l’année. Peux-tu calculer notre revenu récurrent mensuel et expliquer l’écart entre avril et mai, hors taxes ?
Scénario prédéfini · Aucun message transmis
Modèle analytique
3 entités reliéesClients
- id_client
- clé
- nom
- texte
- segment
- texte
Abonnements
- id_abonnement
- clé
- id_client
- lien
- id_offre
- lien
- revenu_mensuel
- € HT
- mois
- date
Offres
- id_offre
- clé
- nom
- texte
- périodicité
- texte
Clients
- id_client
- clé
Offres
- id_offre
- clé
Abonnements
- id_client · id_offre
- liens
- revenu_mensuel
- € HT
1 client → plusieurs abonnements · 1 offre par abonnement
Connexion simulée
Centimes → euros · Montants annuels ÷ 12
Rapport · Revenu récurrent
Avril → MaiRevenu récurrent mensuel · Mai
45 000 €
+12,5 % vs avril
- Revenu récurrent en avril
- 40 000 €
- Nouveaux clients
- +6 000 €
- Expansion des comptes existants
- +2 000 €
- Résiliations
- −3 000 €
- Revenu récurrent en mai
- 45 000 €
Calculé · Données fictives
Exporter CSVVoir les données source
PostgreSQL → subscription_snapshots · Extrait fictif de l’abonnement sub_02. Deux lignes pour comprendre les 2 000 € d’expansion.
| month | amount_cents | billing_period |
|---|---|---|
| 2026-04 | 14400000 | year |
| 2026-05 | 16800000 | year |
Montants annuels hors taxes en centimes, pour un abonnement actif. John divise par 100, puis par 12.
Voir les tables du modèle
Clients → Abonnements ← Offres. Extrait de la table Abonnements après chargement, pour le même abonnement sub_02.
| mois | id_client | revenu_mensuel |
|---|---|---|
| 2026-04 | cli_02 | 12 000 € |
| 2026-05 | cli_02 | 14 000 € |
14 000 − 12 000 = +2 000 € d’expansion. Chaque montant conserve son lien avec les données source.
Voir les chiffres et la méthode
| Mouvement | Montant |
|---|---|
| Revenu récurrent en avril | 40 000 € |
| Nouveaux clients | +6 000 € |
| Expansion des comptes existants | +2 000 € |
| Résiliations | −3 000 € |
| Revenu récurrent en mai | 45 000 € |
Hypothèse : abonnements ramenés à un montant mensuel, hors taxes et revenus ponctuels. Aucun autre mouvement dans cet exemple simplifié. Calcul : (45 000 − 40 000) / 40 000 = 12,5 %.
Revenu récurrent mensuel · Mai
— €
En attente de données
Calcul en cours
Somme des abonnements actifs, ramenés au mois, hors taxes. La variation sera calculée par rapport à avril.
Rapport défini · Modèle préparé
Scénario fictif, connexion et chargement simulés. La vitesse de la démo ne reflète pas celle d’un pilote.
03 / 04 · Le POC
Commençons par un rapport qui compte pour vous.
Le produit vise à se connecter à vos outils et à construire vos rapports automatiquement. Pour ce premier POC payant, nous travaillons ensemble à partir d’extraits, sans ouvrir l’accès à vos systèmes.
Vous repartez avec un rapport vérifié, un modèle de données et des règles de calcul explicites.
Périmètre et prix convenus avant le démarrage.
- 01
Un besoin concret
Nous choisissons un rapport utile à votre activité, ses règles de calcul et le prix du POC.
- 02
Un premier rapport sur vos données
Nous préparons ensemble les extraits nécessaires. Avec John, je construis le modèle et le rapport.
- 03
Des chiffres vérifiés ensemble
Nous comparons le résultat à votre référence, testons une mise à jour et identifions les sources à connecter ensuite.
Un premier échange, sans données à transmettre.
Décrivez votre activité et le rapport souhaité. Avant tout partage, nous convenons des données nécessaires, du transfert, des accès, de la conservation et de la suppression.
À propos de la confidentialitéQuelques questions
Le pilote est-il payant ?
Oui. Le prix dépend du rapport à préparer. Nous le fixons avant de commencer. Le premier échange est sans engagement.
Pourquoi commencer avec des extraits ?
Pour évaluer John sur un cas réel sans vous demander d’accès à vos systèmes. Nous choisissons et préparons ensemble un périmètre limité de données, en CSV ou Excel. Les connexions directes restent l’objectif du produit.
Peut-on se connecter directement à nos sources ?
John Data dispose de connecteurs PostgreSQL et S3. Nous regardons ensemble s’ils conviennent à votre environnement. La démo illustre une connexion PostgreSQL ; les autres systèmes sont à étudier selon votre besoin.
Puis-je utiliser John Data seul ?
Pas encore. Le produit est en développement. J’accompagne personnellement chaque POC, du choix du rapport à la vérification des chiffres.
04 / 04 · Derrière John
Pourquoi je construis John Data
Pascal Luttgens · Créateur de John Data
Après dix ans de data engineering, j’ai constaté que le principal défi de la donnée dépasse la technique : il faut s’accorder sur des définitions claires et partagées. C’est un enjeu de gouvernance, avant d’être une question d’outils.
Je pense que l’IA est aujourd’hui suffisamment mature pour nous aider à construire ce langage commun et à le traduire en modèles et en rapports cohérents. C’est cette conviction qui m’a conduit à créer John Data.