Éditions Farfadet

Contexte & problème résolu

Le marché du livre jeunesse personnalisé est encombré d'acteurs qui promettent « votre enfant en héros » mais livrent en réalité un avatar générique où l'enfant ne se reconnaît pas, ou des contenus 100 % automatisés sans garde-fou. Éditions Farfadet prend le positionnement inverse (« Humain + Farfadets ») avec une promesse produit précise : un livre où la ressemblance réelle de l'enfant est obtenue à partir d'une photo, rassurant à acheter, et livré presque instantanément en numérique.

Traduire cette promesse en produit exploitable posait quatre problèmes d'ingénierie, tous adressés en production : obtenir une cohérence visuelle sur une vingtaine de pages illustrées ; garantir la fiabilité d'une chaîne longue et faillible sans double-traitement ni dérapage de coût ; assurer la sûreté et la conformité alors que l'on traite des données de mineurs (dont des photos de visages d'enfants) ; l'un des périmètres réglementaires les plus sensibles ; et maîtriser le coût d'une chaîne de génération intensive pour la rendre soutenable en production.

• Cible : livre illustré de ~24 pages où l'enfant est le héros, livré en eBook PDF et lisible dans un lecteur en ligne.
• Aucune intervention humaine entre le paiement et la réception du livre.
• Périmètre réglementaire : RGPD art. 8 (mineurs), CNIL, DSA, obligations CSAM/LCEN, PCI-DSS SAQ-A.

Stack & architecture

La solution est organisée en trois plans articulés autour d'une base de données managée partagée. Un plan client (navigateur : tunnel de commande, espace personnel, lecteur 3D) ; un plan applicatif serverless (Next.js sur Netlify : rendu des pages, routes API, webhook de paiement, tâches planifiées) ; et un plan de calcul (worker Python sur Google Cloud Run qui héberge le moteur de génération). Au centre, Supabase (PostgreSQL + Storage) est la source de vérité : le plan applicatif y écrit les commandes, le worker les lit puis y réécrit le livre généré.

Le déclenchement se fait par push (le webhook de paiement appelle le worker, qui répond immédiatement puis génère en tâche de fond) plutôt que par polling : prise en charge immédiate et autoscaling jusqu'à dix générations en parallèle, chacune isolée dans sa propre instance. Autour gravitent les services tiers : Stripe (paiement), Resend (e-mails), Cloud Scheduler et Cloud Storage (planification et sauvegardes chiffrées), OVH (DNS).

• Frontend : Next.js 16 (App Router, React Server Components), React 19, TypeScript, Tailwind v4, état Zustand, lecteur de livre 3D en Three.js.
• Données : Supabase ; PostgreSQL (~21 tables, 44 migrations, 3 buckets privés), Auth, Storage, Row Level Security, pg_cron, procédures RPC SECURITY DEFINER.
• Calcul : worker Python (Flask derrière gunicorn) sur Cloud Run ; un livre par instance (concurrency=1), maxScale=10, no-cpu-throttling pour le thread de fond.
• Paiement Stripe Embedded Checkout (webhooks signés, 3DS/SCA), e-mails Resend, hébergement Netlify.

Moteur de génération : un actif propriétaire

Au cœur du produit, un moteur de génération propriétaire produit un livre personnalisé (texte calibré et illustrations fidèles à la photo de l'enfant). Son fonctionnement interne (méthode de cohérence visuelle multi-pages, technique d'ancrage de la ressemblance, structure des prompts, optimisations de coût) constitue le savoir-faire de l'entreprise et n'est pas exposé.

Ce qui relève de l'ingénierie logicielle démontrable, c'est tout ce qui entoure ce moteur : gating de sécurité, modération, résilience, contrôle d'intégrité, assemblage et livraison. Le contenu est notamment calibré par âge sur sept niveaux de lecture (de 3 à 9 ans) afin d'adapter la longueur et le registre du texte au lecteur.

• Le risque technique numéro un du projet (la ressemblance fidèle de l'enfant) a été résolu.
• Le pipeline de génération est mentionné pour le contexte mais reste volontairement secret.

Fiabilité : une chaîne de filets

La fiabilité d'un pipeline non déterministe est obtenue par couches de filets superposées, et non par un mécanisme unique. Le point de départ est un claim atomique : une mise à jour conditionnelle ne fait passer une commande en « génération » que si elle est encore en attente, garantissant qu'un seul processus la traite même si plusieurs instances s'éveillent simultanément.

La commande suit ensuite une machine à états à huit statuts, avec des transitions distinguées par acteur (worker automatique, tâche planifiée automatique, administrateur manuel). Sur erreur transitoire d'un fournisseur, un retry à back-off croissant réessaie plusieurs fois, à intervalles croissants, pendant que l'espace client affiche un bandeau neutre « panne réseau, on réessaie ».

• Claim atomique anti double-traitement entre instances.
• Retry à back-off croissant (de quelques minutes à quelques heures) + watchdog qui relance les générations bloquées au-delà d'un seuil.
• Plafond de coût en disjoncteur : le coût de chaque génération est suivi et la chaîne est coupée si un plafond de sécurité est atteint.
• Contrôle d'intégrité avant livraison, idempotence des e-mails, tâches planifiées de rattrapage (réconciliation des paiements, remboursement automatique).

Sécurité, modération & conformité

La sécurité est traitée comme un axe de premier plan, adossé à un audit interne de 13 axes avec vérification adversariale de chaque finding. La Row Level Security est activée sur toutes les tables en deny-by-default ; seules huit portent des policies utilisateur filtrées sur l'identité, les autres restant inaccessibles aux clients. Toutes les écritures sensibles passent par des server actions qui revérifient la propriété.

La protection des mineurs repose sur une modération multimodale appliquée à deux moments (sur les photos déposées (fail-closed, avant tout stockage et avant paiement) et sur les images générées (défense en profondeur)), complétée par une mise en quarantaine des incidents et un canal de signalement par un tiers au titre du DSA.

La confidentialité est pensée by design : la photo temporaire est supprimée en fin de génération, une copie durable n'étant conservée que si le parent choisit explicitement de sauvegarder le profil de l'enfant. La suppression de compte procède par anonymisation (squelette comptable conservé), avec export et effacement RGPD. Tech Fox a par ailleurs produit une procédure complète de gestion et de rotation des clés (cartographie des secrets, ordre optimal, secrets comparés en timing-safe) ; sans qu'aucune clé ne soit jamais exposée.

• Gating paiement : webhook n'acceptant que des champs signés, prix fixé côté serveur, blocage des commandes à 0 €.
• Snapshot de consentement immuable (IP/UA) + réacceptation obligatoire par commande.
• Sauvegardes chiffrées AES256 poussées deux fois par jour vers Google Cloud Storage.
• Garde-fou anti-biais : interdiction de fonder l'intrigue sur l'origine ethnique, culturelle ou religieuse de l'enfant.

Résultats, tests & validation

La chaîne a été validée sur données réelles : le risque numéro un (la fidélité de la ressemblance) est résolu, et le livre sort complet et cohérent sur une vingtaine de pages illustrées. Des tests unitaires couvrent le cœur de la logique ; la couverture end-to-end du pipeline et l'instrumentation du temps de génération sont identifiées comme chantiers restants.

L'audit de sécurité interne situe la posture globale à 6,7/10 avec un feu « GO avec réserves » et zéro finding critique après vérification adversariale ; les points ouverts (sauvegardes managées, double authentification administrateur, renforcement de la modération, purge programmée des photos) sont traités comme une feuille de route explicite plutôt que comme une dette cachée. La preuve la plus forte reste que le service est en ligne, fonctionnel, avec de vraies commandes.

• Une trentaine de livres complets générés de bout en bout, en une vingtaine de minutes chacun.
• Fidélité de la ressemblance résolue ; livre cohérent sur une vingtaine de pages illustrées.
• Service en ligne et fonctionnel, avec de vraies commandes traitées.

Difficultés & compétences démontrées

Au-delà de la cohérence visuelle (résolue par une méthode propriétaire), une régression de fidélité a été diagnostiquée jusqu'à sa cause racine (un paramètre d'appel non supporté, silencieusement ignoré, qui dégradait la personnalisation) puis corrigée : un débogage mené jusqu'au fond plutôt que contourné. Le choix d'hébergement du worker a été tranché en passant d'un polling à un déclenchement par push sur Cloud Run, au prix d'une réserve assumée (no-cpu-throttling obligatoire). Le gap de sauvegarde du free tier a été comblé par un pg_dump chiffré quotidien hors-Supabase.

Le projet démontre un spectre large : développement full-stack moderne, architecture cloud distribuée, ingénierie de fiabilité, modélisation de données PostgreSQL avec RLS, intégration de paiement en ligne, sécurité applicative et conformité (RGPD/DSA/LCEN, modération CSAM, gestion de secrets), orchestration d'IA au niveau infrastructure et ingénierie du coût ; le tout avec une méthode « hypothèse, test, mesure, décision » et une traçabilité « conçu vs implémenté » maintenue en continu.