Gautier Stefanini 03e4aecd5e Le rappel des titres repasse en mars, et cesse d'opposer deux nombres

Remontée juste : la carte affichait « 13 semaines avant les vacances d'été »
à côté d'une description parlant de la règle des 6 mois de validité. Les
deux ne répondent pas à la même question — l'une dit quand REGARDER, l'autre
ce qu'il faut vérifier SUR la date lue — mais juxtaposés bruts, ils se
lisaient comme deux réponses concurrentes.

En creusant, un défaut plus net apparaît : treize semaines, c'est le seul
délai de fabrication, sans marge, ce qui plaçait le rappel début avril pour
un départ début juillet. Or la page publique de la fiche écrit noir sur
blanc « pour partir en juillet, la demande se fait en mars, pas en mai ».
Une fiche qui contredit sa propre page se trompe forcément d'un côté, et
c'était du côté qui coûte un voyage. L'avance passe à dix-sept semaines.

Le libellé nomme désormais ce que le délai couvre — « le temps de refaire un
titre » — plutôt que l'écart arithmétique qui l'a produit, et la description
du passeport enfant dissocie explicitement le délai d'obtention de la règle
des 6 mois.

Docs remis à niveau au passage : le cadrage annote ses 4 piliers en cinq
comme il annote ses autres révisions, l'audit du 28/07 porte en tête ce que
D-019 et D-020 ont changé depuis, et les compteurs périmés tombent
(quiz.md 66 → 72 fiches, pilier-vehicules 11 → 12, README, contrats et
papiers sur le nombre de piliers).

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

2026-07-28 17:27:40 +00:00

74 KiB

Raw Permalink Blame History

Document de cadrage — Projet « Veille du foyer »

Marque sœur de Kankwa, éditée par MIAW · Version 1.0 — cadrage validé point par point le 22 juillet 2026 · Nom de code : fokan

1. Résumé exécutif

Un service web qui monte la garde sur les échéances dormantes du foyer (maison, véhicules, papiers, animaux) et en tient le registre, sans jamais créer de tâche nouvelle pour l'utilisateur.

Le problème : des dizaines d'échéances que personne ne stocke nulle part (entretien chaudière, contrôle technique, passeport des enfants, résiliations de contrats...), qui pèsent sur une seule personne du foyer, avec des enjeux légaux, financiers et de sécurité réels.
La solution : un quiz de 2 minutes + des détections automatiques (plaque, adresse) génèrent le calendrier complet du foyer. Le service prévient par mail au bon moment, avec l'action incluse. L'utilisateur réagit en 10 secondes ou ignore — sans conséquence, sans culpabilisation.
Le modèle : freemium à révélation graduée. Gratuit = quiz complet + preview verrouillée (email requis) + guides trouvables mais pas parcourables. Payant = 19,99 €/an par foyer (abonnement annuel, moteur de revenu passif) = full reveal, veille active, plan véhicule personnalisé, ics vivant, catalogue de guides, délégation conjoint. Complété plus tard par un abonnement mensuel pour la bannette (phase 2). Affiliation en opportunité, licence B2B2C à terme. Détail complet et arbitrages en § 10.
La barrière : la base de connaissance des échéances françaises (règles, fréquences légales, délais, enjeux) + le pipeline de compréhension de documents. Le produit, c'est le savoir ; le code n'est que son véhicule.
L'objectif : plusieurs milliers d'euros de revenu récurrent mensuel, en solo, avec une charge serveur minimale.
Le constat de marché : demande massive et documentée (88 % des Français touchés par la charge mentale), sept fronts concurrentiels tous verticaux et/ou réactifs, le quadrant « proactif × foyer entier » est vide. Chaque composant du produit est validé séparément par un acteur existant ; personne n'a fait l'assemblage. Potentiel évalué : 8/10, avec une contrainte de tempo (les indés du scan IA itèrent vite).

Le pitch en une phrase : Personne ne retient tout ça — c'est normal. Nous, c'est notre métier.

2. Vision, promesse et positionnement

2.1 La promesse

Décharger la charge mentale des échéances du foyer sans en créer une nouvelle. Le service est un majordome silencieux : il sait déjà, il prévient au bon moment, il fournit le premier pas de l'action, il se tait le reste du temps, et il tient la mémoire de ce qui a été fait.

2.2 Ce que le produit EST

Un service de veille (push) : il prévient, l'utilisateur réagit.
Un registre (la bannette) : il comprend les documents qui passent et en conserve le sens.
Un savoir expert : les échéances françaises que les gens ignorent devoir connaître (obligations légales, délais administratifs réels, saisonnalités).

2.3 Ce que le produit N'EST PAS (refus définitifs)

Pas une to-do list ni un organiseur du quotidien (courses, repas, ménage, linge) — territoire saturé (Cozi & co) et incompatible avec la promesse.
Pas un coffre-fort documentaire — bataille perdue face à Digiposte ; on n'archive pas, on indexe (voir § 8.4).
Pas un dashboard à tenir — pas de complétion, pas de gamification, pas de compteurs rouges, pas de tâches « en retard ».
Pas un produit santé — frontière stricte (hébergement HDS, responsabilité). Aucune donnée médicale, jamais.
Pas un réseau social ni un produit cadeaux/anniversaires — les gens connaissent ces dates ; c'est le territoire de Kankwa (passerelle discrète possible).
Pas un conseiller financier — les finances n'existent que via la couche contrats (résiliations, renégociations), jamais en conseil de placement.

2.4 Positionnement concurrentiel

Deux axes structurent le marché : réactif vs proactif et vertical vs foyer entier. Tous les acteurs identifiés sont réactifs (on les sollicite quand le problème est là) et/ou verticaux (un seul domaine). Le produit occupe le quadrant vide : proactif × foyer entier. Différenciation résumée : les autres rangent tes papiers ou listent tes tâches ; nous, on sait déjà, on prévient avant, et on comprend ce qui passe.

2.5 Marque

Marque sœur sous MIAW : identité propre, distincte de Kankwa (l'événementiel joyeux et collectif vs la sérénité domestique, sobre et de confiance).
Signature commune : « par le créateur de Kankwa ». Passerelles discrètes entre les deux produits (audience partagée : l'organisateur par défaut).
Valeurs communes revendiquées : artisan français indépendant, hébergement France, pas de publicité, pas de revente de données, transparence.
Le nom : chantier dédié, hors cadrage. Le ton : complice et déculpabilisant, jamais productiviste ni moralisateur.

3. Cible

3.1 Décision validée : produit universel, acquisition par portes verticales

Le produit vise tout le monde : le quiz adapte le service. Un locataire sans voiture avec un chat obtient un hub à ~12 échéances ; un propriétaire multi-équipé en obtient ~45. Personne ne voit de pilier vide.
Le marketing ne vise jamais « tout le monde » : chaque canal d'acquisition cible une douleur ou un moment précis (une page SEO « quand contrôle technique », une vidéo sur le passeport enfant expiré), et tous débouchent sur le même quiz universel. Les données d'usage désigneront les segments qui convertissent et retiennent le mieux.

3.2 Cœur de valeur (le foyer qui reçoit le plus)

Le foyer propriétaire 30-55 ans multi-équipé : maison individuelle + 1-2 véhicules + enfants + souvent animaux. 30-50 échéances dormantes, plusieurs centaines d'euros d'enjeu annuel (résiliations, amendes évitées, sinistres couverts). Ordre de grandeur : 8-10 millions de foyers en France.

3.3 Persona de référence

Léa, 32-40 ans, « organisatrice par défaut » du foyer (héritée de Kankwa) : charge mentale élevée, c'est elle qui pense à tout ; son conjoint Thomas participe si on lui assigne directement. Variantes servies par le même produit : le solo propriétaire, le couple sans enfants, l'aidant de parents âgés (multiplicateur an 2), le bailleur (multiplicateur an 2).

4. Philosophie produit — les règles gravées

Ces règles constituent la constitution du produit. Elles ont été validées intégralement et servent d'arbitre à chaque demande de feature future.

4.1 La règle d'or

Chaque interaction doit supprimer plus de travail qu'elle n'en coûte. Budgets stricts : onboarding ≤ 2 minutes ; aucune interaction récurrente > 10 secondes ; le mode « je ne fais rien » reste un mode parfaitement servi.

4.2 L'outil sait déjà (inférence > saisie)

Tout ce qui peut être déduit ne doit jamais être demandé (type de chauffage → entretien obligatoire ; année du véhicule → contrôle technique ; département → Loi Montagne).
Aucune saisie obligatoire. Unique exception validée : les contrats (voir § 5.5), parce que c'est la seule saisie à récompense monétaire directe — et la détection (transfert de mail) la rendra progressivement inutile.
Le quiz ne pose que des questions factuelles et faciles (choses qu'on sait sans chercher). Jamais de question mémoire (« quand a eu lieu ton dernier ramonage ? » est interdit).

4.3 « Je ne sais pas » est une réponse de première classe

Le moteur manipule des fenêtres avec niveau de confiance, pas des dates exigées :

Date connue (rare) : précision réelle (ex. contrôle technique via la plaque).
Fenêtre estimée : « cette année / l'an dernier / aucune idée » — si aucune idée, rappel programmé à la prochaine fenêtre saisonnière logique.
Sans date du tout : les échéances saisonnières et légales n'ont besoin d'aucune info personnelle (≈ la moitié de la base).
La donnée se construit par l'usage : « déjà fait » en un tap devient la date. Jamais d'interrogatoire.

4.4 Le silence comme feature

Budget notifications strict : jamais plus de quelques envois par mois, regroupés quand c'est possible (« 3 choses ce mois-ci »), priorisés (l'obligatoire légal avant le confort).
Chaque rappel a un « plus jamais ça » sans culpabilisation.
La confiance vient de là : quand il sonne, c'est que c'est important.

4.5 Aucune dette d'entretien, aucune comptabilité morale

Une échéance passée sans réponse glisse silencieusement vers la prochaine fenêtre. Pas de rouge, pas de retard, pas de taux de complétion, pas de gamification, pas de streaks.
Au retour après 6 mois d'absence : une seule question douce (« la chaudière, c'est fait finalement ? »), jamais un cimetière de tâches.
Le test universel : « est-ce que ça marche pour quelqu'un qui a oublié que le service existe ? » Si oui → conforme. Si non → to-do list déguisée → refus.

4.6 Le ton : majordome, pas moniteur

L'imprécision est assumée par le service, jamais reprochée à l'utilisateur (« si c'est déjà fait, dis-le-moi et je me tais »).
Le pourquoi, toujours, en une ligne : chaque rappel donne la raison et l'enjeu (« obligatoire, et exigé par l'assurance en cas de sinistre »). On aide un adulte, on ne donne pas d'ordre.
Le marketing dit « personne ne retient ça, c'est normal », jamais « soyez organisé ».

4.7 Conséquence assumée sur les métriques

Les métriques d'engagement (DAU, temps passé, sessions) seront volontairement mauvaises — c'est le signe que le produit fonctionne. Voir § 12 pour le pilotage réel.

5. Périmètre fonctionnel

5.1 Vue d'ensemble

Un moteur · ~~4 piliers (Maison, Véhicules, Papiers, Animaux)~~ 5 piliers (Maison, Véhicules, Papiers, Enfance & scolarité, Animaux — révisé par D-019, 28/07/2026) · contrats intégrés aux piliers ~~en opt-in~~ ~~déclarables au quiz, complétables en opt-in après (révisé par D-006, 25/07/2026)~~ déclarables au quiz uniquement (révisé par D-007, 25/07/2026) · 2 multiplicateurs an 2 · 1 bannette · 2 canaux (hub + mail) · 0 appli native. Frontière temporelle du périmètre : tout ce qui se prévoit à plus de 2 semaines, rien de ce qui se fait dans la journée.

5.2 Pilier Maison (~20-25 échéances)

Entretien & sécurité : chaudière gaz/fioul (annuel obligatoire), PAC/clim (bisannuel), ramonage (annuel, souvent exigé par l'assurance — règlement sanitaire départemental), détecteurs de fumée (piles + remplacement 10 ans), VMC, chauffe-eau (détartrage), adoucisseur (sel/entretien), fosse septique (vidange ~4 ans), purge radiateurs.
Saisonnier extérieur : gouttières (automne), inspection toiture, taille haies/élagage (obligations de voisinage, périodes), piscine (hivernage / remise en route / analyses), commande de bois avant l'hiver.
Administratif & financier logement : taxe foncière, redevance ordures, assurance habitation (échéance, renégociation), AG de copropriété (convocation, pouvoirs), révision loyer IRL / bail, fin d'offre énergie à prix fixe, diagnostics à durée limitée (si vente/location en vue), déclaration des biens immobiliers.
Équipements & garanties (via bannette, phase 2) : dates de fin de garantie extraites des factures = échéances dormantes.

5.3 Pilier Véhicules (~10-12 échéances par véhicule)

Contrôle technique (4 ans puis 2 ans ; contre-visite 2 mois) — date réelle obtenue par la plaque, réservée au payant (fenêtre estimée générique en gratuit à partir du type/année déclarés ; cf. § 10.2 et § 10.6 pour l'arbitrage économique).
Révision constructeur (km ou date), vidange, courroie de distribution (l'oubli qui coûte un moteur — préconisations par modèle), plaquettes, pneus (usure + hiver : Loi Montagne, 1er nov-31 mars selon département), batterie (alerte avant l'hiver), recharge clim.
Assurance auto (échéance, renégociation), carte grise (changement d'adresse : 1 mois), Crit'Air / règles ZFE (par département).
Deux-roues, vélos, remorque : mêmes mécaniques, en option du quiz.

5.4 Pilier Papiers (~8-10 échéances)

CNI (15 ans), passeports (10 ans adulte, 5 ans enfant — le piège classique), permis format carte (15 ans).
La valeur experte : ce n'est pas la date d'expiration qui compte, c'est date − délai d'obtention réel − règle des 6 mois de validité exigée par certains pays. Rappels calés sur les délais mairie/ANTS constatés et sur les départs en vacances.
Déclaration de revenus (calendrier par département), déclaration/modulation du prélèvement à la source, recensement citoyen (16 ans) + JDC (inféré de l'âge des enfants).
Sous-module CESU/emploi à domicile : déclarations, attestation fiscale annuelle, crédit d'impôt 50 % (une question de quiz : « tu emploies quelqu'un à domicile ? »).
Papiers d'identité : dates extraites par photo si l'utilisateur le souhaite ; les scans ne sont jamais conservés (voir § 8.4).

5.5 Pilier Animaux (~6-8 échéances par animal)

Vaccins (rappel annuel), antiparasitaires (mensuel, saison avril-oct minimum), vermifuge (trimestriel), bilan vétérinaire senior (selon l'âge), mise à jour I-CAD (si déménagement), assurance animale (échéance).
Garde à réserver : déclenchée par l'approche des vacances scolaires.
Inférence triviale (« chien, chat, autre ? âge ? »), attachement émotionnel maximal, présence régulière du service entre deux grosses échéances.

5.6 Les contrats — intégrés aux piliers , en opt-in , déclarables au quiz et complétables en opt-in après (révisé par D-006, 25/07/2026) , déclarables au quiz uniquement (révisé par D-007, 25/07/2026 — cf. docs/decisions.md)

Pas de pilier « Contrats » dans l'interface. Chaque contrat vit dans le pilier qu'il sert : assurance habitation et énergie → Maison ; assurance auto → Véhicules ; assurance animale → Animaux ; mutuelle, box, mobile, salle de sport, assurance emprunteur → rattachés au foyer.
Existence conditionnée au renseignement par l'utilisateur : proposé après le quiz (jamais dedans), au moment pertinent, en deux champs maximum (« chez qui ? mois d'échéance approximatif ? », « je ne sais pas » accepté → fenêtre par défaut), contre une promesse monétaire explicite. Un écran de quiz dédié, dans le prolongement direct des papiers/passeport (pas un volet à part), propose les contrats pertinents pour le foyer déjà connu à ce stade (véhicule → auto, animal → animale, propriétaire → emprunteur, le reste toujours proposé) — un seul champ par contrat (« mois d'échéance approximatif ? », « je ne sais pas » accepté), rien d'obligatoire. L'assureur n'est pas demandé ici : il ne sert aucune inférence, seule l'échéance en déclenche une. Le moment post-quiz reste ouvert pour tout ce qui n'a pas été déclaré là (nouvel animal, nouveau véhicule, contrat oublié) — la promesse monétaire ne conditionnait que ce second moment, pas la déclaration initiale ; là, faute de contexte, « chez qui ? » redevient utile pour distinguer un contrat oublié. Il n'y a plus de rattrapage post-quiz (révisé par D-007) : un contrat ignoré ici — ou une assurance devenue pertinente après coup (nouveau véhicule, nouvel animal) — n'est plus déclarable du tout, en connaissance de cause.
La détection rattrapera la déclaration : en phase 2, transférer le PDF du contrat = le renseigner.
C'est le gisement principal de l'affiliation future (loi Hamon, loi Lemoine, fins d'engagement) — proportionnelle à la confiance donnée.

5.7 Multiplicateurs (an 2 — même moteur, plus de périmètre)

Le foyer des parents (aidance) : « ajoute la maison de tes parents » — marché en explosion, pile la cible (l'organisateur par défaut gère aussi ça), ARPU multiplié.
Le bien locatif (bailleur) : révision IRL, régularisation des charges, validité des diagnostics, échéances fiscales — périodicités très codifiées, willingness-to-pay élevée.
La structure multi-foyers du modèle de comptes (§ 6.3) les rend natifs.

6. Architecture produit

6.1 Le hub web (PWA)

Un hub par foyer, centralisé, accessible web/mobile. Pas d'appli native.
Résidence secondaire, pas principale : on peut être un utilisateur parfaitement servi sans jamais l'ouvrir spontanément. On y atterrit depuis un mail (lien magique, sans login) pour agir en 10 secondes.
Écran d'accueil = un état, pas une liste : « ✓ Tout est sous contrôle — prochaine échéance : ramonage, octobre. » Rassurant, vide d'obligations.
Contenu : les échéances par pilier, la bannette (phase 2), les membres, les réglages de notifications, le récap.

6.2 Les canaux

Le mail est le moteur (décision : mail seul au MVP). Chaque rappel = objet clair (l'échéance), corps = enjeu en une ligne + boutons d'action ([✓ Fait] [Déjà fait] [→ Déléguer] [Premier pas de l'action]). Zéro habillage marketing.
Délivrabilité = infrastructure critique : domaine d'envoi dédié, SPF/DKIM/DMARC, routeur sérieux, montée en volume progressive, monitoring spam. Un rappel en spam = la promesse rompue.
Abonnement ics en option : flux webcal en lecture seule (« voir mes échéances dans mon agenda »), qui se met à jour seul. L'export .ics statique reste l'objet du gratuit.
Extensions ultérieures (phase 3, optionnelles) : SMS pour le critique à sanction (excellent taux de lecture, coût unitaire), push PWA pour qui installe.

6.3 Comptes et foyer (modèle validé)

Le foyer est l'objet central : un foyer = un quiz, une base d'échéances, une bannette, un abonnement (facturé au foyer, rattaché au compte payeur).
Comptes légers : lien magique par mail (ou passkey), pas de mot de passe. Rejoindre un foyer = cliquer l'invitation + confirmer son mail (~20 secondes).
Membres égaux : pas de hiérarchie admin/invité — esprit de redistribution de la charge. Seule la facturation est individuelle.
Chaque échéance a un responsable, réassignable en un tap : c'est le geste de délégation, cœur de la promesse. Le membre assigné reçoit directement ses rappels (la charge est redistribuée, pas relayée).
Asymétrie assumée : l'organisateur démarre seul, le produit vaut à 100 % en solo ; l'invitation du conjoint arrive au moment naturel (première délégation), jamais exigée.
Multi-foyers natif : un compte peut être membre de plusieurs foyers (le sien, celui de ses parents, son bien locatif) — fondation des multiplicateurs.
Continuité long terme : le modèle survit aux séparations, décès, changements de mail (chaque personne contrôle son accès — conformité RGPD).

7. Le moteur d'intelligence

7.1 Les trois sources, par ordre de déploiement (décision : « tout l'API-sable en premier »)

Phase 1 — L'inférence par quiz + les détections API

Le quiz : 6-8 questions factuelles en 2 volets (logement / véhicules) + animaux + papiers. Résultat : 30-50 échéances générées instantanément.
La plaque d'immatriculation : un champ → marque, modèle, année, motorisation, Crit'Air, date réelle du prochain contrôle technique + préconisations d'entretien du modèle. L'« effet waouh » du quiz. Sources : API agrégateurs SIV, payantes à l'appel (~5-50 centimes selon richesse — HistoVec est une interface publique, pas une API exploitable). Étude des fournisseurs à mener au build.
L'adresse : pré-suggestion du logement via l'open data gratuit (DPE ADEME, Base Adresse Nationale, BDNB) — type de chauffage, année, surface. Toujours en suggestion corrigeable (« D'après les données publiques : chauffage gaz, maison de 1974 — c'est toujours ça ? »), jamais en vérité imposée : couverture et fraîcheur imparfaites assumées. Une inférence fausse non corrigeable détruirait la confiance.

Phase 2 — Le pipeline de compréhension de documents (entrée mail)

Transfert d'un mail (facture, contrat, attestation) vers l'adresse dédiée du foyer → OCR + LLM → extraction (type, émetteur, date, montant, échéance liée) → confirmation en un tap → alimentation de la bannette + mise à jour des fenêtres.
Décision technique ouverte au build : l'endpoint (adresse entrante par foyer via service d'inbound mail, vs upload web, vs les deux).

Phase 3 — Le même pipeline, entrée photo

Scan photo du courrier papier (avis de taxe foncière, convocation d'AG, relance) : capture de l'imprévisible, complément du moteur d'inférence qui couvre le prévisible.
Mail entrant et scan partagent ~90 % du code : un seul moteur de compréhension, deux portes d'entrée. Le mail (PDF propres) rode le moteur avant la photo (plus difficile).

7.2 Règles de fonctionnement du moteur

Fenêtres de confiance (§ 4.3), glissement silencieux (§ 4.5), reprogrammation invisible au « fait ».
Jamais d'automatisme silencieux sur une extraction : toute donnée extraite d'un document est montrée pour confirmation (« Taxe foncière, 1 247 €, avant le 15 octobre — c'est bien ça ? »). Une date fausse sur un avis d'impôt = crédibilité morte.
Chaque fiche d'échéance de la base porte : règle d'inférence, récurrence, fenêtre par défaut sans info, saisonnalité, enjeu/pourquoi (une ligne), comportement au « fait », comportement de glissement, document attendu et qui peut le réclamer, potentiel d'affiliation, source légale/référence.

7.3 La règle de gratuité des détections (décision validée)

Indexée sur le coût des sources : ce qui est issu d'API/open data gratuit est offert à tous (l'adresse) ; ce qui repose sur des API payantes est ajusté (la plaque : réglage pressenti = 1 plaque offerte au quiz avec limites anti-abus et cache des résultats, véhicules supplémentaires et re-vérifications au payant — à trancher au vu des prix réels).

8. La bannette (décision révisée — remplace le « carnet »)

8.1 Le principe : on n'archive pas, on indexe

La bannette est la boîte de réception intelligente du foyer : un input entre (transfert de mail en phase 2, photo en phase 3), il est analysé — l'analyse est un prérequis absolu, pas de bannette sans analyse — et ce qui est conservé est le sens, pas le fichier.
Chaque entrée du registre : type de document, émetteur, date(s), montant, échéance/équipement lié, action proposée, statut (confirmé/ignoré), provenance (« reçu par mail le 12/09, objet : Facture entretien »).
Le document brut est jeté après confirmation (conservation transitoire le temps de l'analyse uniquement).

8.2 Pourquoi ce choix

Taille disque minimale (objectif explicite) : le contrat « infra à quelques euros/mois » tient à l'échelle.
Pas de coffre-fort : aucune concurrence frontale avec Digiposte ; positionnement limpide (les autres rangent tes papiers ; nous, on les comprend et on en tire les conséquences).
Posture sécurité/RGPD radicalement allégée : pas de scans de CNI stockés, pas d'archive sensible à protéger à vie. Les papiers d'identité restent servis : photo → extraction de la date d'expiration → échéance créée → image supprimée.

8.3 La parade à la perte d'archive

Les moments de valeur historiques du « carnet » (sinistre, garantie, revente) reposaient sur l'original. Réponse : la provenance. L'original reste là où il vit déjà (la boîte mail de l'utilisateur) ; le registre est la table des matières qui sait dire où le chercher. Zéro disque, valeur largement préservée. Le registre structuré (historique daté des entretiens, montants, prestataires) garde en propre sa valeur de journal du foyer (revente, suivi, mémoire).

9. Parcours utilisateurs de référence

Note (mise à jour économique) : les sections ci-dessous décrivent le parcours de référence issu du cadrage initial. Certains détails (export .ics gratuit, « abonnement mensuel ») sont antérieurs à la réécriture du § 10 et n'ont pas encore été reconciliés avec le nouveau modèle annuel à révélation graduée — voir le journal des décisions pour l'arbitrage retenu.

9.1 Onboarding (Léa, 2 minutes)

Landing (via une page SEO ou le bouche-à-oreille) → volet logement (maison/appart, proprio/locataire, chauffage, cheminée, extérieur/piscine — pré-suggéré par l'adresse si fournie) → volet véhicule : elle tape sa plaque → « Peugeot 308 de 2019, prochain contrôle technique avant mars 2027 » → animaux (« un chat ») → papiers (« des papiers de +10 ans ? Je ne sais pas » — accepté) → le hub s'affiche, déjà rempli : 34 échéances sous contrôle, les 3 prochaines visibles. Choix : export ics gratuit / activer la veille (abo mensuel).

9.2 L'année type, pilier par pilier

Maison (septembre) : mail « Ta chaudière gaz mérite son entretien annuel avant l'hiver — obligatoire, et ton assurance peut exiger l'attestation. Si c'est déjà fait, dis-le-moi et je me tais. [✓ Fait] [Déjà fait] [3 chauffagistes près de chez toi] ». Un tap → atterrissage sans login → reprogrammation invisible. Octobre : gouttières (glisse en silence si ignoré).
Véhicules (janvier) : « Le contrôle technique de la 308 est à faire avant le 12 mars — 135 € d'amende sinon. Les délais s'allongent en février. [Prendre rdv] [Fait] ». Date réelle issue de la plaque, zéro saisie.
Papiers (mars) : « Le passeport de Jules (valable 5 ans seulement pour un enfant) expire en novembre. Certains pays exigent 6 mois de validité : pour partir cet été, c'est maintenant — les rdv mairie prennent 2-4 mois. [Trouver un créneau] ». La valeur = date − délai − règle des 6 mois.
Animaux (avril) : « Saison des tiques : antiparasitaire du chat à reprendre. » (juin, déclenché par les vacances) : « Vous partez cet été ? Les gardes se réservent tôt. »
La bannette (phase 2-3) : l'avis de taxe foncière arrive → transfert de mail ou photo → « Taxe foncière 2027, 1 247 €, avant le 15 octobre — c'est bien ça ? [Oui] » → registre alimenté, échéance créée, rappel J-7, suggestion mensualisation. L'original reste dans la boîte mail, la provenance est tracée.

9.3 Le conjoint

Léa assigne le CT à Thomas → « Thomas n'est pas encore là — l'inviter ? » → lien magique, 20 secondes → il est membre égal du foyer et reçoit directement ses rappels. Métrique vitale : le taux de foyers à 2+ membres (assurance anti-churn).

9.4 Le cycle de facturation (mensuel)

Chaque mois, le prélèvement arrive avec sa preuve : le récap mensuel (« ce mois-ci : 3 échéances surveillées, 1 rappel envoyé, rien n'a reposé sur ta mémoire »). Le récap n'est pas un nice-to-have : c'est l'organe vital de la rétention d'un produit conçu pour être oublié et facturé au mois.

10. Modèle économique

Section réécrite in extenso — version finale issue de l'audit de scénarios (juillet 2026). Remplace toute mention antérieure d'un modèle mensuel à 4-5 €, d'un one-shot pur, ou d'un export .ics statique gratuit.

10.1 Architecture : deux moteurs de revenu séquencés

Moteur 1 — « La Veille », abonnement annuel, 19,99 €/an par foyer. Le produit principal, au cœur du lancement. Coût marginal quasi nul (batch quotidien, mails à quelques centimes, données déjà en base) — chaque renouvellement est une marge proche de 100 %. C'est ce moteur qui construit le revenu passif par effet de stock (le même client repaie chaque année ; l'acquisition sert à faire grossir un stock, pas à courir après un flux qui ne s'arrête jamais).

Moteur 2 — « La Bannette », abonnement mensuel complémentaire, phase 2. Vendu plus tard, à la base installée déjà convaincue (bien meilleure position de vente qu'à du trafic froid). Facturation mensuelle justifiée par sa structure de coût différente (LLM local, usage irrégulier, service qu'on ajoute/retire librement). Prix à définir en phase 2 (repère marché : SOS Papier, MyAdmin IA ~5-7 €/mois pour le scan seul).

10.2 La frontière gratuit/payant — ligne par ligne

GRATUIT — la porte d'entrée (principe : prouver sans délivrer)

Les guides, en accès individuel uniquement, jamais en catalogue navigable. Un guide se trouve (recherche Google, lien direct, mention dans un autre guide) ; il ne se parcourt pas en liste. Le catalogue complet est réservé aux abonnés — c'est lui, la valeur du produit : la charge mentale, c'est ne pas savoir qu'il faut chercher, pas seulement oublier une date connue. Indexation Google assurée par sitemap XML (découple crawl et navigation humaine) ; maillage interne en liens contextuels dans la prose des articles. Frange résiduelle acceptée : site:fokan.fr/guide reste possible sur Google — cohérent avec la règle « accessible si on sait quoi chercher », pas un problème à corriger.
Le quiz complet, 100 % déclaratif, zéro appel API payant : logement (avec pré-suggestion par adresse, open data gratuit), véhicules (type + année, déclaratifs), papiers, animaux.
Le pilier Véhicules en gratuit reste générique : le moteur applique les mêmes fenêtres de confiance que les autres piliers (§ 4.3) à partir du type + de l'année déclarés (« prochain contrôle technique estimé courant 2027 »). Aucun appel API plaque au stade gratuit — décision motivée par le coût (§ 10.6).
La preview post-quiz, ~~email requis avant affichage (capture du lead + friction anti-scraping)~~ sans aucune contrepartie demandée (révisé par D-005, 25/07/2026) : total et répartition par pilier (« 34 échéances sur 4 5 domaines »), le rythme de l'année (timeline 12 mois, pastilles anonymes par mois et par pilier), 2-3 échéances urgentes entièrement détaillées, le reste en cartes verrouillées (titre + pilier visibles, date/enjeu masqués). L'adresse mail se demande après le service rendu, comme un service supplémentaire et non comme une porte. Ligne directrice consolidée : révéler l'inventaire, jamais le mode d'emploi.
Pas d'export .ics statique gratuit (retiré : supprimait le risque qu'un fichier recopiable suffise à lui seul).

PAYANT — La Veille, 19,99 €/an

Le tableau de bord complet : full reveal de toutes les échéances, dates, fenêtres, enjeux.
Le plan d'entretien véhicule personnalisé : l'abonné ajoute sa vraie plaque — un seul appel API par véhicule, mis en cache immédiatement en base, jamais rejoué — date réelle du contrôle technique, préconisations constructeur. C'est le débloquant explicite du pilier Véhicules (2 véhicules inclus, plafond doux au-delà — anti-abus plus que contrainte de coût à ce stade).
Le suivi : « fait »/« déjà fait », reprogrammation automatique, glissement silencieux, historique des occurrences.
Les rappels mails au bon moment, action incluse.
L'abonnement ics vivant (webcal, à jour en permanence).
L'enrichissement automatique et continu : toute fiche publiée dans la base apparaît chez les foyers concernés sans action (réconciliation § 20.4) — l'abonnement achète un service qui s'améliore tout seul.
Les guides contextualisés : catalogue complet en navigation libre + version appliquée au foyer, liée depuis chaque échéance.
La délégation au conjoint (invitation, assignation, rappels directs).
Le récap annuel, qui sert aussi de préavis de renouvellement (jamais de débit surprise).
Recommandés, non encore développés : chiffrage du risque personnalisé (« X € de risques sous surveillance cette année »), attestation annuelle générée à la demande (jamais stockée — cohérent § 8).

EXCLU du modèle : publicité, compteurs freemium mesquins, Open Banking, stockage de documents, remboursement/garantie affichés (§ 10.7), abonnement mensuel pour la Veille (tranché en faveur de l'annuel, cf. § 10.3).

10.3 Pourquoi l'annuel plutôt que le mensuel ou le one-shot (arbitrage documenté)

Trois familles testées : mensuel (rejeté — le produit est conçu pour être oublié, donc le churn mensuel silencieux est le pire scénario pour ce cas précis) ; paiement unique à vie (rejeté — casse l'effet de stock qui rend le revenu passif ; exigerait ~100 ventes neuves chaque mois, indéfiniment pour maintenir le CA, contre 75-150 en annuel une fois le régime de croisière atteint) ; annuel (retenu — même effet de stock que le mensuel, un seul moment de rupture par an au lieu de douze, coût marginal quasi nul donc marge quasi totale sur chaque renouvellement). Le récap annuel (§ 9.4, § 10.2) transforme ce moment unique en preuve de valeur plutôt qu'en risque.

10.4 L'affiliation (décision : en opportunité, une fois la base constituée)

Règles non négociables : uniquement dans les rappels où l'action sert l'utilisateur ; toujours affichée (« lien partenaire — c'est ce qui finance la veille ») ; proportionnelle à la confiance (surtout les contrats renseignés).
Dès le jour 1 : liens d'action neutres dans les rappels (comparateurs, annuaires, prise de rdv) — bascule vers du commissionné triviale plus tard.
Gisements par rendement décroissant : assurance emprunteur (loi Lemoine), assurances habitation/auto (loi Hamon), énergie, contrôle technique, chauffagiste/ramoneur, assurance animale.

10.5 La licence B2B2C (an 3, après preuve de rétention)

Inchangé : agents immobiliers/notaires, assureurs habitation, constructeurs. Modèle : X € par foyer activé ou marque blanche.

10.6 Pourquoi l'API plaque sort du quiz gratuit (arbitrage chiffré)

À 90 000 quiz cumulés (repère de l'équation § 10.8) et ~1,3 véhicule déclaré en moyenne, un appel systématique en gratuit (même à 10-15 ct) représente 10 000 à 25 000 € facturés pour des visiteurs dont 96-98 % ne convertiront jamais — un CAC caché absent du calcul initial. Bascule : le gratuit reste générique (déclaratif, fenêtres de confiance), l'appel réel devient le débloquant explicite du payant, porté uniquement par des foyers qui ont déjà payé 19,99 € — à 1 800 foyers actifs, même à 2 véhicules et 50 ct/appel, le coût total (~1 800 €/an) reste sous 5 % du CA.

10.7 Pas de remboursement affiché — point légal à sécuriser

Décision produit : aucune garantie de remboursement affichée. Vigilance légale non négociable : en UE/France, un service à distance ouvre en principe un droit de rétractation de 14 jours (Code de la consommation, art. L221-18 et s.), y compris pour un abonnement numérique — sauf renonciation expresse de l'acheteur au moment de l'achat (art. L221-28), via une case à cocher obligatoire au paiement : « Je demande l'exécution immédiate du service et renonce à mon droit de rétractation de 14 jours. » Sans cette case, le parcours quiz → paiement → full reveal instantané → rétractation resterait un moyen quasi gratuit de consommer le produit une fois — la case ferme cette faille légalement, pas seulement dans les intentions. À faire valider par un professionnel du droit avant le lancement.

10.8 Équation économique — 19,99 €/an

Objectif 3 000 €/mois = 36 000 €/an → ~1 800 foyers actifs en permanence.
À 2-4 % de conversion quiz → abonné : 45 000 à 90 000 quiz cumulés nécessaires.
Régime de croisière (rétention 50-75 %/an) : 75 à 150 nouvelles conversions/mois pour maintenir le stock — ordre de grandeur cohérent avec un trafic SEO en régime établi.
Frais PSP : ~2,8 % du CA à ce prix (contre ~6,5 % testé à 4,99 €/an — la part fixe des frais de carte pénalise disproportionnellement les prix bas).
Point mort (infra + outils) : quelques dizaines de foyers.
Horizon réaliste : 24-36 mois (délai SEO + un premier cycle de renouvellement complet pour stabiliser la rétention réelle).
Coûts variables : API plaque (réservée au payant, cf. § 10.6), LLM (phase 2, réservé au payant), mails (négligeable), stockage (minimal par design de la bannette).
Prix testés et écartés : 4,99 €/an (volume ×5 par rapport à 19,99, frais PSP disproportionnés, signal de sérieux affaibli face aux comparables à 40-80 €/an) ; 49 €/an (jugé trop cher par le porteur de projet, frein de conversion anticipé au lancement sans preuve sociale encore établie).
Levier de répétition hors renouvellement : les multiplicateurs (§ 5.7 — foyer des parents, bien locatif) génèrent un second abonnement annuel par foyer engagé, sans dépendre de la seule fidélité du premier achat.

11. Acquisition

11.1 Réalisme viral

La boucle virale native est faible (l'invitation conjoint touche 1 personne du même foyer → rétention, pas croissance). La croissance repose sur le contenu et le bouche-à-oreille. Décision : SEO dès le MVP, TikTok en option ultérieure.

11.2 Le SEO longue traîne — canal n°1

La base de connaissance est bicéphale : chaque échéance documentée = une fiche moteur (règles, fenêtres, messages) + une page publique SEO (« Ramonage : obligation, fréquence, prix, sanctions » → CTA quiz). Rédiger la base, c'est produire le site — un seul chantier.
Territoire vaste et faiblement disputé : « périodicité ramonage », « validité CNI », « quand contrôle technique », « courroie de distribution quand », « passeport enfant durée », « loi montagne pneus départements »...
~30 pages au MVP, extension continue. Délai incompressible : 6-12 mois avant traction — d'où le démarrage immédiat.

11.3 Les autres leviers

L'objet viral : le résultat du quiz (« les 34 échéances de ton foyer ») et l'export .ics gratuit, conçus pour être montrés/partagés.
Le bouche-à-oreille du récap (« ce truc m'a évité 135 € d'amende ») et la signature « par le créateur de Kankwa » + passerelles discrètes depuis l'audience Kankwa.
TikTok (option ultérieure) : registre « La vie d'orga » version foyer — le passeport enfant expiré à l'aéroport, la courroie oubliée, la contre-visite. Aléatoire mais capable de pics.
Portes verticales : chaque canal cible une douleur précise, tous convergent vers le quiz universel (cf. § 3.1).

12. Roadmap validée

Phase 0 — Le test de désirabilité (avant toute construction produit)

Landing + quiz réel (avec détections API) + hub figé + prix mensuel affiché. Objectif : mesurer l'étoile polaire (conversion) pour un coût quasi nul. C'est l'hypothèse la plus incertaine du projet (« les gens paieront-ils ? ») : on la teste en premier.

MVP — La veille seule

Le quiz + détections API (adresse open data pour tous, 1 plaque offerte).
Le hub figé gratuit + export .ics statique.
L'abonnement mensuel : rappels d'action par mail, « fait »/« déjà fait », reprogrammation et glissement, partage conjoint (liens magiques, membres égaux, assignation), récap mensuel, flux ics vivant.
Les liens d'action neutres dans chaque rappel.
~30 pages SEO issues de la base de connaissance.
L'infrastructure mail (domaine dédié, SPF/DKIM/DMARC, montée en volume progressive).

Phase 2 — Le pipeline de compréhension + la bannette

Mail entrant (endpoint à trancher) → OCR/LLM → extraction → confirmation → registre avec provenance, document brut jeté.
Les contrats se renseignent par transfert de PDF.
Extension de la base de connaissance et des pages SEO en continu.

Phase 3 — Extensions

Scan photo du courrier papier (même pipeline, entrée caméra).
Multiplicateurs : foyer des parents, bien locatif (+ réflexion palier de prix supérieur).
Affiliation activée en opportunité (bascule des liens neutres).
Option annuelle en rétention. SMS critique éventuel. Push PWA éventuel.
Pré-étude licence B2B2C.

Note (mise à jour économique) : cette roadmap (Phase 0 « prix mensuel affiché », MVP « abonnement mensuel », hub figé + .ics gratuits) est antérieure à la réécriture du § 10 (modèle annuel à 19,99 €/an, révélation graduée, pas d'ics gratuit). Voir le journal des décisions pour l'arbitrage retenu sur ces mentions restées non reconciliées dans le document source.

13. Métriques et pilotage

13.1 L'étoile polaire (décision : fixe)

La conversion quiz complété → abonné. C'est elle qui arbitre les priorités : toute feature, toute page, toute semaine de travail se juge à sa capacité à transformer un curieux en payant.

13.2 Le garde-fou

Le churn mensuel : s'il dépasse ~7-8 %/mois, il prend temporairement le volant (le produit convertit mais ne tient pas sa promesse dans la durée → priorité au récap, à la pertinence des rappels, à l'invitation du conjoint).

13.3 Le tableau de bord complet

Conversion quiz → abonné (étoile polaire).
Churn mensuel (garde-fou).
Taux de réaction aux rappels (« fait »/« déjà fait »/action cliquée — la preuve que la garde sert ; indicateur avancé du churn).
Taux de foyers à 2+ membres (assurance anti-churn).
Délivrabilité et taux d'ouverture des mails (infrastructure vitale).
Trafic SEO → quiz complétés (le moteur d'acquisition).
(Plus tard) Revenu d'affiliation par abonné actif ; MRR en objectif de fond, non piloté directement.

13.4 Rappel philosophique

DAU, sessions et temps passé seront volontairement mauvais : c'est conforme. La valeur se mesure en échéances honorées et en euros économisés, pas en engagement.

14. Synthèse de l'audit de marché

14.1 La demande

Charge mentale : 88 % des Français touchés (OpinionWay 2022) ; portée par une seule personne dans ~80 % des couples (IFOP 2021) ; 8 femmes sur 10 concernées (Ipsos 2026) ; 91 % des parents la ressentent, 44 % en souffrent régulièrement (Wecasa/YouGov 2024).
Marché adressable : ~30 M de résidences principales, ~40 M de voitures particulières ; cœur solvable ~8-10 M de foyers propriétaires multi-équipés.
Nuance clé : une douleur documentée n'est pas un marché solvable — la solvabilité est validée par les points de prix constatés (cf. 14.3), pas par les sondages.

14.2 Les sept fronts concurrentiels (état juillet 2026)

Organiseurs familiaux (Cozi ~400 k$/mois après 15 ans + pub ; FamilyWall ; MyFamiliz 2,99 €/mois ; Mental Loadless 3,99-19,99 €/mois, hébergé France, Balance Score + IA ; Share(d), 3,7 M€ levés) : le flux quotidien — l'anti-territoire du produit. Leçon : le B2C organiseur payant est un cimetière ; ne jamais y glisser.
Contrats/abonnements (Origame : gratuit, commission à la bascule, détection Open Banking, 560 €/an d'économies moyennes revendiquées ; banques avec détection d'abonnements) : gratuit financé par l'affiliation = la norme du front. Valide l'étage affiliation ; interdit un abo « contrats seuls ».
Véhicule (Drivvo, My Garage, Simply Auto, CarFul — préconfiguration par carte grise —, Odopass — historique pour la revente —, CodeNekt — gratuit financé par les garages) : fragmenté, sans gagnant, orienté passionnés. L'inférence existe en vertical ; jamais reliée au foyer, jamais pour les distraits.
Maison/CIL (CIL obligatoire logements neufs depuis 01/2023 ; Mon Suivi Logement 130 000+ foyers en B2B2C constructeurs ; Hommy/Leroy Merlin ; Le bon'home) : distribution verrouillée par les pros du bâtiment ; l'acquisition directe grand public est libre.
Coffre-fort numérique (Digiposte/La Poste : des millions à plus de 10 M d'utilisateurs selon les sources, Premium ~39,99 €/an, hébergé France, valeur probante ; Arkevia/Crédit Agricole ; LockSelf) : valide le point de prix (~40 €/an) et l'appétence « France/tranquillité ». Range sans comprendre ni anticiper. Ne jamais se positionner « coffre-fort » (d'où la bannette).
Scan IA de courrier — front émergent (MyAdmin IA : OCR + Mistral, adresse mail dédiée, Premium 6,90 €/mois ; SOS Papier : freemium, 4,99 €/mois ou 39,99 €/an ; Importemps : analyse d'un courrier + brouillon de réponse) : micro-acteurs, tous réactifs et sans structure (pas de foyer, pas de moteur proactif, pas de registre lié aux échéances). Valide le besoin et le prix du pipeline ; impose un tempo (la fenêtre se referme) ; confirme que la différenciation est l'assemblage, jamais le scan seul.
IA générique (ChatGPT, Claude...) : sait générer la liste des échéances gratuitement ; ne monte pas la garde. La défense = l'exécution durable (notifications fiables sur des années, reprogrammation, registre, délégation) + le pipeline + la base maintenue.

14.3 La lecture stratégique

Deux axes : réactif vs proactif × vertical vs foyer entier. Tous les acteurs sont réactifs et/ou verticaux. Le quadrant proactif × foyer entier est vide.
Chaque composant du produit est validé séparément par un acteur existant : le prix par Digiposte et SOS Papier (~40-60 €/an), l'inférence par CarFul, la monétisation par Origame, la distribution B2B2C par Mon Suivi Logement, le pipeline par les indés du scan. Personne n'a fait l'assemblage. Le risque n'est pas « est-ce que ça se vend » mais « qui assemble le premier ».
Le transversal se vend mal en une requête Google → marketing par portes verticales (acté § 3.1 et § 11).
Verdict : potentiel 8/10 — le meilleur ratio effort/revenu/défendabilité des pistes explorées, avec une contrainte de tempo réelle.

14.4 Précédents de modèle

Cozi prouve qu'un organiseur peut générer plusieurs M$/an (mais en 15 ans, avec pub). Digiposte prouve la solvabilité de masse à ~40 €/an sur la tranquillité administrative. Ohai.ai (US, 6 M$ levés, 25 $/mois avec assistants humains) prouve qu'on paie cher un service qui pense à ta place — le produit se situe dans l'espace de prix intermédiaire, avec l'anticipation sans le coût humain.

15. Risques et parades (par gravité)

La conversion gratuit → payant ne décolle pas (l'hypothèse existentielle). Parade : la phase 0 la teste avant toute construction ; le double filtre gratuit/payant est tunable ; l'effet plaque maximise la démonstration.
Le churn silencieux du mensuel (produit conçu pour être oublié + prélèvement mensuel). Parade : le récap mensuel systématique comme preuve de valeur ; l'invitation du conjoint (2 ancres > 1) ; l'option annuelle en rétention ; le garde-fou à 7-8 %. (Nuance : le modèle retenu au § 10 est désormais annuel dès le lancement — ce risque et sa parade visaient le modèle mensuel initial.)
La vitesse des indés du scan IA (SOS Papier & co pourraient ajouter du proactif). Parade : le moteur d'inférence et la structure foyer sont longs à copier ; exécuter vite ; ne jamais réduire le pitch au scan.
L'entrée d'un gros à 3-5 ans (La Poste ajoutant des rappels à Digiposte, une banque, un assureur). Parade : la vitesse, la niche transversale, l'angle indépendant (pas de conflit d'intérêt sur les résiliations) ; à terme, être l'acteur qu'on licencie plutôt que celui qu'on écrase.
La confiance sur l'extraction et les inférences (une date fausse = crédibilité morte). Parade : confirmation systématique en un tap, pré-suggestions toujours corrigeables, jamais d'automatisme silencieux.
La délivrabilité mail (un rappel en spam = promesse rompue). Parade : infrastructure soignée dès le MVP (§ 6.2), monitoring permanent.
Le coût éditorial permanent de la base (ZFE, lois, périodicités qui changent). Parade : l'assumer comme le cœur du métier — c'est le coût ET la barrière ; mutualisé avec le SEO (base bicéphale).
L'exemplarité données (courriers fiscaux et personnels via API LLM tierce). Parade : fournisseur choisi pour la conformité (option UE), zéro conservation chez le tiers, document brut jeté (design bannette), transparence totale — un sujet de marque autant que de technique.
Le feature creep (les utilisateurs demanderont une to-do list, du stockage, du quotidien). Parade : la constitution du § 4 et les refus du § 2.3 — ce document.

16. Exigences transverses

Hébergement France (doctrine MIAW), RGPD by design (comptes individuels, suppression réelle, minimisation par la bannette).
Sécurité : liens magiques à durée limitée, chiffrement en transit et au repos pour le peu qui est stocké, pas de mots de passe à protéger, surface minimale par design (pas d'archive de documents).
Charge serveur minimale (contrat fondateur) : données textuelles structurées, pas de stockage de fichiers, PWA statique + API légère, mails. Coûts variables bornés (plaque, LLM) et adossés au payant.
Accessibilité et simplicité : le hub doit être utilisable par le conjoint le moins motivé du foyer.

17. Décisions ouvertes (à trancher au build, hors cadrage)

Sujet	Options	Échéance
Le nom et l'identité visuelle	Chantier dédié marque sœur MIAW	Avant phase 0
Fournisseur API plaque et coût réel	Étude comparative des agrégateurs SIV	Phase 0
Réglage exact de la gratuité plaque	1 offerte / limites IP / cache	Phase 0
Grille détaillée gratuit vs inclus	Tuning sur le double filtre coût/valeur	MVP puis itératif
Endpoint de la bannette	Adresse entrante par foyer / upload web / les deux	Phase 2
Fournisseur LLM du pipeline	Critères : conformité UE, zéro conservation, coût	Phase 2
Palier de prix supérieur (multi-foyers)	Avec les multiplicateurs	An 2
Structure juridique de l'affiliation	Plateformes vs partenariats directs	En opportunité

18. Les 14 décisions de cadrage (référence rapide)

Cible : produit universel, acquisition par portes verticales.
Périmètre : ~~4 piliers (Maison, Véhicules, Papiers, Animaux)~~ 5 piliers (D-019, 28/07/2026) ; contrats intégrés aux piliers, ~~en opt-in renseigné~~ ~~déclarables au quiz et complétables en opt-in après (D-006)~~ déclarables au quiz uniquement (D-007) ; refus définitifs maintenus.
Philosophie : gravée intégralement (règle d'or, inférence, « je ne sais pas », silence, glissement, ton majordome).
Canaux : hub web (PWA) destination ; mail seul moteur au MVP ; ics en option.
Comptes : foyer objet central, membres égaux, liens magiques, un abonnement par foyer, multi-foyers natif.
Détection : phase 1 = tout l'API-sable (adresse gratuite pour tous, plaque selon coût) ; puis mail entrant ; puis scan photo. Gratuité indexée sur le coût des sources.
Mémoire : la bannette, pas le coffre — analyse prérequise, conservation du sens + provenance, jamais du fichier brut.
Gratuit/payant : double filtre coût + valeur ; gratuit = savoir instantané, payant = garde + registre ; curseur à tuner. (Voir § 10 pour la version finale, plus stricte : révélation graduée.)
Prix : (Voir § 10 pour la version finale — palier unique annuel à 19,99 €/an dès le lancement ; la mention historique « mensuel au lancement (~4-5 €/mois) » ci-dessous est conservée pour mémoire de la décision initiale, remplacée par la réécriture du § 10.) Palier unique, mensuel au lancement (~4-5 €/mois par foyer) ; récap mensuel comme preuve ; annuel plus tard en rétention.
Affiliation : en opportunité une fois la base constituée ; liens d'action neutres dès le jour 1.
Marque : sœur sous MIAW, « par le créateur de Kankwa ».
Acquisition : SEO dès le MVP (base de connaissance bicéphale) ; TikTok en option.
Roadmap : Phase 0 (test de désirabilité) → MVP (veille seule) → Phase 2 (pipeline + bannette) → Phase 3 (scan, multiplicateurs, affiliation, annuel).
Pilotage : étoile polaire = conversion quiz → abonné (fixe) ; churn en garde-fou (~7-8 %/mois).

PARTIE II — Architecture technique de référence

Complément au cadrage produit · Décisions validées point par point le 22 juillet 2026

19. Exigences et audit des approches

19.1 Les trois exigences fondatrices

Un nouveau pilier réutilise les schémas et écrans existants — ajouter un pilier ne doit demander aucun nouveau code (ni table, ni endpoint, ni écran).
L'enrichissement de l'intelligence génère automatiquement les rappels — publier une nouvelle fiche de connaissance déploie l'échéance chez tous les foyers concernés, sans migration ni action utilisateur.
La base de connaissance est générique et évolutive — déclarative, versionnée, avec une sémantique de migration définie.

19.2 Approches auditées et rejetées

A. Modélisation par pilier (tables/modèles maison, vehicule...) : rapide au début, condamnée ensuite — chaque pilier = migrations + code + écrans. Viole l'exigence 1. Rejetée.
B. Ultra-générique EAV/graphe (tout en entité-attribut-valeur) : requêtes illisibles, intégrité impossible, perfs médiocres. La généricité doit être au bon niveau, pas partout. Rejetée.
C. Moteur de règles du commerce / workflow engine (Drools, Temporal, Camunda) : la bonne idée conceptuelle (règles = données) mais infra lourde et courbe d'apprentissage injustifiées pour un domaine « récurrences + fenêtres » porté par un solo. Rejetée, patterns retenus.
D. LLM à l'exécution (l'IA évalue quelles échéances s'appliquent) : non-déterministe (deux foyers identiques → résultats différents), coûteux à chaque évaluation, non-testable. Rejetée — et gravée en règle : le LLM vit aux frontières (pipeline documents), jamais dans le moteur d'échéances, qui est 100 % déterministe.
E. Ontologie à 3 couches + moteur de réconciliation déclaratif : le pattern des systèmes qui ont exactement ce problème — un état désiré défini par des règles versionnées, réconcilié avec un état réel contenant de l'historique utilisateur (Kubernetes, Terraform, React). Retenue.

19.3 Les invariants d'architecture (gravés)

IDs de templates stables à vie — un identifiant publié ne change jamais de sens.
Réconciliation idempotente — rejouable à volonté sans effet de bord.
État utilisateur inviolable — les « fait », mute, responsables, dates apprises survivent à toute évolution de la base.
Séparation stricte des 3 couches — Connaissance / Instance / Occurrences.
LLM aux frontières uniquement — le cœur est déterministe et testable.
Contenu multi-canal dans le template — mail, hub et SEO issus de la même fiche (bicéphalie structurelle).
Un pilier = de la configuration, jamais du code.

20. Le pattern : ontologie 3 couches + réconciliation

20.1 Couche 1 — Connaissance (les templates, la valeur du produit)

La base de connaissance est un ensemble de DeadlineTemplates déclaratifs : des fichiers de données (YAML + blocs MDX pour les contenus longs), versionnés dans Git, jamais du code. Format de référence :

id: chaudiere-gaz-entretien        # identifiant STABLE à vie
version: 3                          # incrémenté à chaque modification
pilier: maison
applicabilite:                      # prédicat sur les attributs de l'asset
  asset_type: logement
  when: { chauffage: "gaz" }
recurrence:
  rrule: "FREQ=YEARLY"
  fenetre_saisonniere: [sept, oct]
fenetre_defaut: prochaine_saison    # comportement si « je ne sais pas »
glissement: silencieux              # comportement si non traité
enjeu:
  type: legal+assurance
  resume: "Obligatoire ; attestation exigible par l'assurance en cas de sinistre."
contenus:                           # bicéphale par construction
  mail: { objet: ..., corps: ... }
  hub: { titre: ..., description: ... }
  seo: { slug: periodicite-entretien-chaudiere-gaz, page: ./chaudiere-gaz.mdx }
actions:
  - label: "Chauffagistes près de chez toi"
    slot_affiliation: chauffagiste  # lien neutre au MVP, commissionné plus tard
document_attendu: attestation_entretien   # pour la bannette (phase 2)
reclamable_par: [assureur]
source: "Décret 2009-649"

Le DSL d'applicabilité : prédicats simples sur les attributs d'assets — égalité, comparaison, présence/absence, appartenance à une liste, combinaisons ET/OU. Volontairement minimal.
La soupape des stratégies nommées : pour les ~2 % de règles réellement complexes (ex. courroie de distribution : km ET années, par modèle), le template référence une stratégie implémentée en code (strategy: courroie_distribution). La généricité a une soupape, pas une religion.
Champs portés par chaque fiche (rappel § 7.2) : règle d'inférence/applicabilité, récurrence, fenêtre par défaut sans info, saisonnalité, enjeu/pourquoi en une ligne, comportement au « fait », comportement de glissement, contenus multi-canaux, actions et slots d'affiliation, document attendu et qui peut le réclamer, source légale.

20.2 Couche 2 — Instance (le foyer)

Deux entités génériques suffisent à tous les piliers présents et futurs :

Asset : type + attributs en JSONB. Un logement, un véhicule, un animal, un document d'identité, un contrat sont des assets. Un pilier n'est pas une table : c'est un asset_type.
Deadline : template_id + asset_id + l'état utilisateur — fenêtre courante, niveau de confiance de la date, responsable (membre assigné), muet (« plus jamais ça »), contrat renseigné le cas échéant.
Le Foyer agrège assets, membres (égaux), deadlines et l'abonnement. Un compte peut appartenir à plusieurs foyers (multiplicateurs an 2 natifs).

20.3 Couche 3 — Occurrences (la timeline, append-only)

Chaque cycle d'une deadline = une Occurrence : fenêtre due, statut (à venir / fait / déjà fait / glissé), source de la date (inférée, apprise, détectée, extraite).
Les envois de notifications y sont journalisés (idempotence des rappels : jamais deux fois le même).
Le registre de la bannette (phase 2) s'y branche : une entrée = un événement documentaire (type, émetteur, dates, montant, action, provenance) rattaché à un asset et/ou une occurrence. Conforme au § 8 : le sens est conservé, jamais le fichier.

20.4 Le moteur de réconciliation — la pièce maîtresse

Un job idempotent qui, pour chaque foyer :

calcule l'état désiré = templates actifs × assets du foyer (évaluation des prédicats d'applicabilité) ;
le diffe avec l'état existant ;
applique les transitions :

Situation	Action du moteur
Template nouvellement applicable (nouvel asset OU nouvelle fiche publiée)	Création de la deadline + première occurrence (fenêtre par défaut)
Template modifié (version incrémentée)	Mise à jour des occurrences futures uniquement ; l'historique est intouché
Template déprécié	Archivage silencieux des deadlines (pas de notification, pas de trace visible)
Asset supprimé/modifié rendant le prédicat faux	Archivage silencieux des deadlines liées
Deadline mutée par l'utilisateur (« plus jamais ça »)	Jamais recréée, quelles que soient les évolutions de la base

Règle sacrée : l'état utilisateur est toujours préservé (invariant 3). C'est ce mécanisme qui réalise l'exigence 2 : publier une fiche « détartrage chauffe-eau » dans le repo → à la réconciliation suivante, tous les foyers concernés ont l'échéance. Enrichir la connaissance = enrichir le produit, sans migration, sans code, sans action utilisateur.

Déclencheurs : publication d'une version de la base (batch global) · mutation d'un foyer (quiz, ajout/modif d'asset, réponse à un rappel) · passage quotidien de sécurité. Un batch quotidien suffit (les échéances se jouent à +2 semaines) : pas d'event-driven, pas de temps réel, pas de complexité inutile.

20.5 Le scheduler de notifications

Job quotidien : occurrences entrant en fenêtre de rappel → application du budget notifications (regroupement « 3 choses ce mois-ci », priorisation légal > confort, plafond mensuel — le budget est une politique du moteur, pas de chaque template) → écriture en outbox → envoi via l'adapter mail → journalisation. Idempotent et rejouable : un cron manqué se rattrape sans doublon.

20.6 Quiz et formulaires : déclaratifs aussi

Chaque asset_type définit son schéma d'attributs (JSON Schema/Zod) et ses questions de quiz ; le front les rend génériquement (composants de formulaire pilotés par le schéma). Ajouter un pilier = ajouter des fichiers (un asset_type + ses questions + ses templates) — zéro écran, zéro endpoint nouveau (exigence 1).

20.7 SEO : le même repo

Les blocs contenus.seo + fichiers MDX des templates génèrent les pages statiques (SSG Next). Rédiger une fiche produit simultanément la règle moteur ET la page d'acquisition — la bicéphalie du § 11.2 est structurelle, pas une bonne intention.

20.8 Les adapters — frontières du système

Le cœur (moteur + scheduler) ne connaît aucun service externe. Tout passe par des adapters aux contrats stricts :

Détection plaque : entrée = plaque ; sortie = attributs d'asset véhicule + dates apprises (CT). Fournisseur interchangeable.
Détection adresse : entrée = adresse ; sortie = attributs suggérés de logement (jamais imposés). Sources open data (DPE ADEME, BAN, BDNB).
Envoi mail : entrée = message composé (React Email) ; sortie = statut d'envoi. Le plan B (routeur SaaS) est à un fichier de config (cf. § 26.2).
Pipeline LLM (phase 2) : entrée = document (mail entrant, puis photo) ; sortie = événement de bannette candidat (extraction à confirmer) + attributs. LLM local par défaut, repli API conforme documenté.
Paiement : abonnement du foyer (webhooks à retries — tolérants à l'indispo, cf. § 26.1).

21. Modèle de données (schéma de référence)

Tables principales (PostgreSQL, via Drizzle) :

Table	Rôle	Champs clés
`users`	Comptes légers	email, credentials (hash) ; sessions better-auth
`households`	Le foyer, objet central	abonnement (statut, période), réglages
`memberships`	Lien user↔foyer	rôle unique « membre » (égalité), préférences de notification par personne
`assets`	Instances génériques	`household_id`, `asset_type`, `attributes JSONB`, provenance (quiz/détection/bannette)
`deadlines`	Échéance instanciée	`template_id` (+ version appliquée), `asset_id`, responsable, confiance, muted, état contrat
`occurrences`	Timeline append-only	`deadline_id`, fenêtre due, statut, source de date, timestamps
`notifications_log`	Journal d'envois (outbox)	occurrence, canal, statut, message-id — idempotence
`bannette_entries` (phase 2)	Le registre	type, émetteur, dates, montant, `asset_id`/`occurrence_id`, action, statut, provenance ; aucun blob
`knowledge_versions`	Versions de base déployées	hash de la release, date, stats de réconciliation

Notes : attributs d'assets et contenus en JSONB (souplesse) sur socle relationnel (intégrité foyer→deadline→occurrence) — le meilleur des deux mondes, pas de NoSQL. Index sur (household_id), (asset_type), prédicats JSONB fréquents (GIN ciblé), (deadline_id, fenêtre) pour le scheduler. Volumétrie cible triviale : 10 000 foyers × 40 échéances = quelques centaines de milliers de lignes — le batch quotidien est un calcul négligeable.

22. Stack applicative (décisions 1-2 validées)

TypeScript de bout en bout — choix motivé par : un seul langage partout (vélocité solo, zéro changement de contexte), les types comme colonne vertébrale de la base de connaissance (fiches validées par des schémas partagés entre moteur, quiz, mails et SEO : une fiche mal formée casse la CI, pas la prod), l'écosystème le plus actif sur tous les besoins du produit (SSG/SSR, PWA, mails composables, SDK LLM). Alternative Python écartée : avantage IA marginal contre la taxe permanente de deux langages.

Brique	Choix	Justification
Framework	Next.js (App Router), unique	Un framework pour les trois visages : pages SEO statiques (SSG), hub PWA, API. Pas de split Astro+API : deux frameworks = taxe permanente pour un solo
Base de données	PostgreSQL + Drizzle ORM	Relationnel + JSONB ; ORM typé, léger, migrations propres (jouées au déploiement)
Jobs & cron	pg-boss	Files et planification dans Postgres — zéro Redis, zéro infra supplémentaire ; réconciliation et scheduler = jobs pg-boss
Validation	Zod partout	Un seul système de schémas : templates, quiz, API
Mails	React Email + adapter d'envoi	Mails d'action = composants typés, testables, prévisualisables
Base de connaissance	YAML + MDX dans le repo	Parsée et validée au build (cf. § 23)
Front hub	PWA légère (installable, notifications futures)	Pas d'appli native (cadrage § 6.1)

23. Édition de la base de connaissance (décision 3 validée : Git-only)

Workflow : fiches éditées dans l'IDE → une PR par ajout/modification → CI valide (schémas Zod, stabilité des IDs, incrément de version, rrule valide, non-régression) → merge → build SEO + déclenchement de la réconciliation globale.

Arbitrage documenté (pour mémoire de la décision) :

Git-only — pour : zéro dev, validation CI imbattable (une fiche invalide ne peut pas atteindre la prod), historique/diff/rollback natifs, revue de soi-même par la PR, branches = préversions gratuites. Contre : seul le fondateur édite, ergonomie moyenne du contenu long (mitigée par MDX), pas d'édition mobile, prévisualisation à construire.
Back-office — pour : édition ouverte (rédacteur, expert, partenaire), ergonomie, corrections rapides. Contre : semaines de dev immédiates pour un besoin hypothétique, validation réimplémentée (moins bien), historique à recoder, surface d'attaque en plus, risque de publication impulsive.
L'argument décisif : A est réversible (la source de vérité étant des données validées par schéma, un back-office futur peut devenir un client qui commit), B ne l'est pas. Critère de bascule : le jour où quelqu'un d'autre doit éditer régulièrement.

24. Hébergement et exploitation (décision 4 validée : prod locale)

24.1 Le choix et sa justification

Production sur le serveur local existant (Docker + Caddy natifs, LLM local disponible). Justification spécifique au produit : tolérance exceptionnelle à l'indisponibilité (échéances à +2 semaines, rappels en batch quotidien, rien de temps réel — 6 h de panne = zéro impact ; un cron manqué se rejoue le lendemain, le glissement est dans le design ; les webhooks de paiement ont des retries sur plusieurs jours ; pas de pic de trafic type Kankwa). « Hébergé en France » rigoureusement vrai. Coût nul, souveraineté totale.

24.2 Les 5 mitigations — exigences non négociables

Perte de données = seul risque inacceptable : dumps Postgres quotidiens chiffrés vers un stockage objet externe français (S3 type Scaleway), restauration testée régulièrement. LA condition.
Jamais d'IP résidentielle exposée : tunnel (Cloudflare Tunnel ou équivalent) ou petit VPS frontal en reverse proxy devant Caddy ; surface minimale ; mises à jour disciplinées.
Détection de panne externe : monitoring type UptimeRobot + heartbeats sur les crons (« le job quotidien n'a pas pingé » → alerte). Sans ça, le scénario « scheduler planté depuis 5 jours » reste possible.
Électricité/réseau : onduleur ; une coupure box d'une journée est absorbée par le design.
Réputation mail indépendante du serveur : cf. § 26.2 (relais par IP propre).

24.3 La clause de sortie (gravée)

Tout est Docker + Postgres standard : migration triviale vers PaaS/VPS. Seuil de réexamen formel : ~200-300 foyers payants (des clients qui paient pour de la fiabilité). Alternatives documentées le jour venu : PaaS français (Scalingo, Clever Cloud — ~25-50 €/mois, Postgres managé, zéro ops) ou VPS français + Coolify.

24.4 Le LLM local (phase 2) — l'atout souveraineté

Pipeline de la bannette exécuté sur le LLM local : « vos courriers sont analysés sur nos serveurs, en France, et ne sont jamais transmis à un tiers » — argument qu'aucun concurrent du scan IA ne peut revendiquer (tous en API Mistral/OpenAI). Résout le risque n°8 du cadrage (exemplarité données), supprime le coût variable par document (détend le filtre coût du gratuit/payant), latence indifférente en batch. Condition : benchmark de qualité d'extraction sur documents réels (dates, montants sur factures/avis) avant activation — la confirmation en un tap tolère un peu d'erreur, pas beaucoup. Repli documenté : API conforme (option UE, zéro conservation) si la précision ne suit pas.

25. Authentification (décision 5 validée)

better-auth auto-hébergé (pas de service tiers : Clerk/Auth0 = SaaS américain contradictoire avec la posture, coût par utilisateur, dépendance). Modes : login/mot de passe + liens magiques. Le mot de passe offre le chemin familier (hachage sérieux, reset — qui repasse par le mail) ; le lien magique reste le véhicule des invitations au foyer et de l'atterrissage sans login depuis les rappels (liens à durée limitée). Passkeys ajoutables plus tard. Sessions en Postgres.

26. Envoi des mails (décision 6 validée : auto-hébergé sous conditions)

26.1 Le choix

Envoi auto-hébergé depuis l'infrastructure, en s'inspirant du setup Kankwa existant. Différence d'enjeu assumée : pour Kankwa, une invitation en spam est un désagrément ; ici le mail EST le produit — un rappel en spam = la promesse rompue en silence (risque n°6 du cadrage).

26.2 Les trois conditions gravées

Jamais d'envoi depuis une IP résidentielle (plages en PBL Spamhaus par défaut, port 25 souvent bloqué par les FAI). Solution : le VPS frontal du § 24.2 fait aussi relais SMTP sortant — IP fixe et propre, PTR/rDNS configuré, réputation constructible. Un composant, deux rôles. (Vérifier le routage réel du setup Kankwa.) Révisé par D-014 (26/07/2026) : le setup Kankwa vérifié n'utilise aucun VPS relais mais une soumission SMTP authentifiée vers Infomaniak (mail.infomaniak.com:587) — le risque d'IP résidentielle ne s'applique qu'à l'envoi direct vers le serveur du destinataire, pas à une soumission authentifiée vers un relais externe. C'est donc ce montage, sans composant supplémentaire à héberger, qui est retenu pour fokan.
Hygiène complète : SPF, DKIM, DMARC en politique stricte, domaine d'envoi dédié (ex. mail.<domaine>.fr), montée en volume progressive (warming), List-Unsubscribe même en transactionnel.
Monitoring de délivrabilité en métrique de prod : taux d'ouverture par FAI (postmaster tools Gmail/Outlook/Orange), vérification automatisée de blacklists, alertes. Plan B à un fichier de config : l'envoi passe par l'adapter (§ 20.8) — bascule vers un routeur SaaS (Brevo — français — ou Postmark) en une heure en cas de dégradation. Souveraineté par défaut, jamais au prix de la promesse.

27. Organisation du code, CI et déploiement (décision 7 validée)

Monorepo : app Next + moteur + adapters + base de connaissance (YAML/MDX) ensemble — la CI valide code ET connaissance d'un même mouvement.
CI GitHub Actions : lint, typecheck, tests du moteur de réconciliation en priorité absolue (la pièce la plus critique : suites sur les transitions du § 20.4, l'idempotence, l'inviolabilité de l'état utilisateur), validation Zod des fiches, build.
Déploiement : image Docker construite en CI → tirée par le serveur (webhook/SSH) → migrations Drizzle jouées au déploiement.
Deux environnements : staging + prod (sur l'infra locale), une branche = une préversion de la base de connaissance testable.

28. Décisions techniques ouvertes (à trancher au build)

Sujet	Note	Échéance
Fournisseur API plaque	Étude comparative agrégateurs SIV (coût, richesse CT)	Phase 0
Choix du tunnel/VPS frontal	Cloudflare Tunnel vs petit VPS FR — ~~qui ferait aussi relais SMTP~~ plus nécessaire pour le mail, cf. D-014	MVP
~~Vérification du setup mail Kankwa~~	✅ Tranché par D-014 (26/07/2026) : relais Infomaniak authentifié, pas de VPS — voir docs/decisions.md	~~MVP~~ fait
Modèle LLM local + benchmark extraction	Précision dates/montants sur corpus réel ; seuil d'acceptation	Phase 2
Endpoint bannette	Adresse entrante par foyer (service inbound) vs upload vs les deux	Phase 2
Prestataire de paiement	Stripe vs alternative — webhooks à retries requis	Phase 0/MVP
Stockage objet des backups	S3 français (Scaleway ou équivalent), chiffrement	MVP
Case de renonciation au droit de rétractation	Formulation exacte, emplacement au checkout, validation par un professionnel du droit (art. L221-28 Code conso) — cf. § 10.7	MVP, bloquant avant tout encaissement réel
Plafond de véhicules inclus dans l'abonnement	2 inclus proposé — confirmer le seuil et le prix du supplément	MVP

Prochains chantiers d'exécution, dans l'ordre : ① Phase 0 (questions exactes du quiz + landing + prix affiché à 19,99 €/an + étude API plaque) · ② Base de connaissance v1 (~45 fiches au format § 20.1, bicéphales) · ③ Squelette technique (monorepo, schéma Drizzle, moteur de réconciliation + ses tests) · ④ Nom et identité.

74 KiB Raw Permalink Blame History Unescape Escape