En résumé : 28 heures de formation avec un directeur d'agence d'assurance expert du funéraire ont abouti à trois résultats concrets : un cahier des charges de 15 pages rédigé avec l'IA pour une application de collecte d'avis partenaires, une première version fonctionnelle de l'application développée avec Lovable (vibe coding), et une méthode reproductible pour continuer à développer cet outil en autonomie.
Quand cet apprenant m'a contactée, il avait une idée précise et une frustration de longue date : vingt ans passés à travailler avec des opérateurs funéraires indépendants, et aucun outil adapté pour mesurer leur satisfaction. Les grandes plateformes d'avis ne correspondent pas à ce secteur. Les questionnaires génériques ne prennent pas en compte la spécificité des actes — souscription, sinistre, acte de gestion. Et les petites pompes funèbres n'ont pas le temps de remplir de longs formulaires.
L'objectif de la formation était donc double : apprendre à utiliser l'IA au quotidien, et avancer concrètement sur ce projet d'application. En vingt-huit heures — treize heures de formation avec moi, quinze heures d'e-learning — nous avons fait les deux.
Un marché de niche qui manquait d'outils adaptés
Le secteur funéraire, et plus précisément la prévoyance obsèques distribuée par les opérateurs funéraires indépendants, est l'un des segments les moins numérisés du marché de l'assurance. Non par négligence, mais par spécificité : les acteurs sont souvent de petites structures, avec peu de temps disponible, une maturité numérique variable, et des processus métier très codifiés.
Dans ce contexte, mesurer la satisfaction des partenaires — les pompes funèbres — relevait presque de l'artisanat. Ce qui remontait, c'était principalement de l'insatisfaction, portée par les commerciaux, sans traçabilité ni système de suivi.
L'idée de départ était simple : transformer les "pépins" en "pépites". Capter les retours d'expérience après chaque acte traité — souscription, sinistre, acte de gestion — et les exploiter pour améliorer les services et nourrir une démarche qualité. Ce que les grandes entreprises font depuis longtemps avec des outils coûteux, et que ce directeur voulait reproduire à l'échelle des indépendants, avec des moyens appropriés.
La question n'était pas "est-ce qu'un tel outil existe ?" — il n'existe pas, ou pas sous cette forme. La question était "comment le construire sans être développeur ?"
Construire son cahier des charges avec l'IA
Avant d'écrire une seule ligne de code, il fallait savoir exactement ce qu'on voulait construire. C'est là qu'intervient Claude — non pas comme outil de développement, mais comme architecte et interlocuteur de réflexion.
La méthode que nous avons appliquée ensemble :
- Clarifier l'idée hors de tout outil IA — décrire le projet, ses utilisateurs, leurs parcours respectifs, les données à traiter, les cas d'usage prioritaires.
- Utiliser Claude comme expert UX/UI — en lui demandant de poser toutes les questions nécessaires pour rédiger un cahier des charges précis. Ce n'est pas l'IA qui impose une structure : c'est elle qui force à penser à ce qu'on n'aurait pas formulé seul.
- Itérer sur le document — en important le cahier des charges dans un projet Claude, en l'enrichissant session après session avec les décisions prises, en ajoutant des fichiers CSV fictifs pour tester la structure des données.
Le résultat : un document de quinze pages détaillant les trois profils utilisateurs (courtier, partenaire, manager), les parcours complets, la structure des données importées depuis le logiciel existant, les règles de filtrage et de dédoublonnage, l'écran de prévisualisation avant envoi, le système de tokens uniques pour les formulaires partenaires, et la couche d'analyse IA.
"Quinze pages pour une application ciblée — ça montre le niveau de précision nécessaire. Et c'est justement ce niveau de précision qui permettra ensuite à Lovable de produire quelque chose de correct."
Ce travail préparatoire n'est pas un luxe : c'est la condition sine qua non d'un développement réussi en vibe coding. Une instruction floue produit une interface floue. Un cahier des charges précis produit un prototype exploitable.
De l'idée à l'application : le vibe coding avec Lovable
Une fois le cahier des charges stabilisé, nous avons ouvert Lovable — une plateforme de développement par IA qui génère des applications web React à partir d'instructions en langage naturel.
Le principe est simple en apparence : vous décrivez ce que vous voulez, Lovable le construit. La réalité est plus subtile. Lovable fonctionne en trois modes complémentaires :
- Mode Plan : pour réfléchir, poser des questions à l'IA avant qu'elle code, éviter les erreurs structurelles coûteuses.
- Mode Build : pour demander des modifications concrètes dans l'application.
- Mode Visual Edit : pour sélectionner un élément de l'interface et demander une modification graphique précise, sans toucher au code.
Ce que nous avons construit ensemble en une session de quatre heures :
- Un espace courtier avec authentification
- Un tableau de bord principal
- Un module de création de campagne avec import CSV
- Un écran de prévisualisation avant envoi des demandes d'avis
- Un historique des campagnes
- Un formulaire d'avis côté partenaire, accessible sans connexion via un lien unique
- Un aperçu des emails générés
- Une interface de consultation des avis reçus
Un premier prototype fonctionnel, construit en partant de zéro, sans écrire une seule ligne de code.
Un point clé appris en session : les crédits Lovable peuvent partir vite si l'on envoie des demandes vagues ou mal préparées. La règle d'or — préparer chaque modification dans Claude avant de l'envoyer dans Lovable — permet de maximiser l'efficacité de chaque crédit et d'éviter les boucles de correction coûteuses.
Ce que l'IA change pour les acteurs de niche du funéraire
Le secteur funéraire a une particularité que j'ai rarement rencontrée dans d'autres domaines : la densité d'expertise métier est inversement proportionnelle à la maturité numérique. Les professionnels qui y travaillent connaissent leur activité mieux que n'importe quel développeur ou consultant généraliste. Ce qu'ils n'ont pas, c'est le temps et les ressources pour traduire cette expertise en outils numériques.
C'est précisément là que l'IA change la donne. Pour la première fois, un expert métier peut :
- Décrire son besoin en langage naturel — sans avoir à l'encoder dans un cahier des charges technique réservé aux développeurs.
- Générer un prototype fonctionnel en quelques heures, pour le tester avec de vrais utilisateurs avant d'investir.
- Itérer rapidement sur les fonctionnalités, sans attendre des semaines de développement.
- Comprendre les enjeux techniques — hébergement, RGPD, souveraineté des données — suffisamment pour prendre des décisions éclairées.
Pour un marché de niche comme le funéraire, où aucun éditeur SaaS généraliste ne proposera jamais une solution sur mesure, cette capacité à créer ses propres outils représente une rupture profonde.
Les points de vigilance abordés en formation
La formation n'était pas que de l'enthousiasme. Nous avons passé du temps sur les limites réelles de ces outils, pour que l'apprenant puisse avancer les yeux ouverts.
Sur Lovable et le passage en production : Lovable est excellent pour prototyper. Le passage à une application de production — hébergée, sécurisée, intégrée avec les contraintes techniques existantes — nécessitera probablement l'intervention d'un développeur pour reprendre et auditer le code. Lovable donne le 70-80% ; un développeur finit le reste.
Sur la souveraineté des données : Supabase, le backend utilisé par Lovable, peut être configuré pour déployer en région Europe (Francfort). Ce n'est pas un cloud souverain français au sens strict. Si l'application traite des données sensibles liées à des contrats obsèques, la question de la conformité RGPD et de l'hébergement doit être traitée en amont — pas après le développement.
Sur le RGPD et les données sensibles : le secteur funéraire traite des données liées au décès. L'application a été conçue pour ne collecter que le strict nécessaire — le champ "cause décès" a été volontairement retiré du cahier des charges lors de la session. Moins de données collectées, moins de risques.
Sur le modèle de crédit Lovable : ce qu'il faut savoir avant de commencer
Lovable fonctionne avec un système de crédits par action. Des utilisateurs rapportent avoir consommé 60 à 150 crédits sur des problèmes de layout créés par l'IA elle-même. Pour un projet de cette complexité, prévoir au minimum un plan à 50 $/mois (500 crédits). La meilleure pratique : préparer chaque demande dans Claude avant de la soumettre à Lovable, pour éviter les corrections en cascade.
La méthode Claude + Lovable : deux outils, deux rôles
Ce qui distingue cette approche d'un simple "j'ai demandé à une IA de faire une application", c'est la clarté des rôles entre les outils :
- Claude joue le rôle de l'architecte — il structure les idées, rédige le cahier des charges avec un langage précis, identifie les manques, génère des données de test, prépare les instructions pour Lovable.
- Lovable joue le rôle du développeur — il génère et exécute le code de l'application à partir du cahier des charges. Le code produit est en React, avec Supabase comme backend.
Cette séparation est clé. Tenter de tout faire dans Lovable sans préparation aboutit systématiquement à des résultats décevants et des crédits gaspillés. Investir du temps dans Claude en amont, c'est réduire les itérations en aval.
Le principe que l'apprenant a retenu : le facteur le plus critique est la qualité et la précision du cahier des charges. Plus il est clair et complet, meilleurs sont les résultats. Une session mal préparée peut épuiser tous les crédits disponibles sans résultat exploitable.
Ce que cet accompagnement illustre sur la formation IA individuelle
Vingt-huit heures de formation, c'est court pour apprendre à développer une application. C'est suffisant pour apprendre à piloter le développement d'une application — ce qui est une compétence très différente, et bien plus accessible.
Ce que cet accompagnement illustre, c'est la valeur de partir d'un projet réel, concret, ancré dans une expertise métier solide. L'apprenant n'avait pas besoin de comprendre React ou Supabase. Il avait besoin de comprendre comment traduire ce qu'il sait faire depuis vingt ans en instructions que l'IA peut exécuter.
C'est exactement ce que la formation IA individuelle est censée produire : non pas des techniciens de l'IA, mais des professionnels capables d'en exploiter le potentiel dans leur domaine spécifique.
Vous avez un projet d'outil numérique dans un secteur de niche et vous ne savez pas par où commencer ?
❋ Réserver 1h de consultation ❋ Résultat obtenu ou remboursé