L'histoire
Tout a commencé à un déjeuner. Avec Jonathan Bonzy — un ami de longue date, côté tech et réseau — on échangeait sur nos usages de l'IA agentique et sur ce que ça ouvrait comme possibilités. Au détour de la conversation, il me parle d'une idée qui lui trotte dans la tête : un « cahier de vacances » pour former les salariés à l'IA. On en discute vingt minutes. Le sujet est bon, clairement — mais on se quitte sans se dire qu'on va le faire.
Le lendemain midi — vingt-quatre heures plus tard — je lui envoyais le business plan, les canaux de distribution, l'analyse de marché, et les maquettes complètes du site vitrine et d'une partie des exercices.
Jonathan m'avait convaincu, et j'avais fait la seule chose que je sais vraiment faire dans ces moments-là : j'ai appliqué mon Sprint Fondateur à moi-même. Passer d'une idée de coin de table à un projet cadré, chiffré, maquetté et déjà amorcé — en vingt-quatre heures, en solo — parce que la bonne méthode et les bons outils le permettent désormais. C'est, au fond, la meilleure démonstration de ce que je raconte aux fondateurs.
Le contexte
aiffut n'est pas une mission client : c'est un produit que je construis avec Jonathan. La répartition est simple : lui porte la vente, le réseau et la commercialisation ; moi, je porte la plateforme et le contenu — le build, l'usine de contenu IA, la relecture. Je le mets ici pour une raison précise : c'est sans doute la meilleure vitrine de ce que je sais faire avec l'IA agentique, parce que je n'avais personne à convaincre. Juste un produit à sortir, vite et bien.
Le produit lui-même répond à un besoin très concret. Les salariés non-tech des TPE et PME entendent parler d'IA partout, mais n'ont presque jamais d'endroit pour s'entraîner sur leur propre métier. Les formations génériques coûtent cher et passent à côté de la pratique réelle ; les tutoriels gratuits sont partout mais ne laissent aucune trace, aucune progression, aucune montée en compétence ordonnée.
aiffut prend l'angle inverse : ~30 minutes par jour pendant 8 semaines, sur sa propre pratique métier. On y travaille des cas réels, on en ressort avec des réflexes, des prompts maîtres réutilisables, et une attestation qui matérialise le parcours. Le tout « pour le prix d'un livre, pas d'une formation ». Pour s'en convaincre, pas besoin d'argumentaire : 10 exercices gratuits suffisent — le produit est sa propre démonstration.
~30 min/jour × 8 semainesle format : s'entraîner à l'IA sur sa propre pratique métierEt il y a un vent arrière réel. L'article 4 de l'AI Act européen impose aux entreprises de garantir un « niveau suffisant de maîtrise de l'IA » de leur personnel, adapté à son métier et à son contexte d'usage. Dès qu'une équipe ouvre un ChatGPT ou un Copilot, l'entreprise est concernée. Cette obligation existe depuis février 2025, mais les autorités obtiennent leurs pouvoirs de contrôle au 2 août 2026. Ce n'est pas une amende qui tombe — c'est le moment où l'achat d'une formation IA cesse d'être un budget discrétionnaire pour devenir une démarche de conformité documentable. aiffut répond mot pour mot au texte : un programme par métier, et une attestation par salarié comme trace présentable.
Le défi
Le besoin est clair. Le défi, lui, est entièrement dans l'échelle.
L'ambition produit, c'est 20 métiers × 2 niveaux (Fondation / Maîtrise) = 40 programmes, 40 exercices chacun, sur 14 formats pédagogiques distincts — soit de l'ordre de 2400 exercices. Écrire ça à la main, à deux, dans une fenêtre de quelques semaines, est tout simplement impossible. Et le contenu pédagogique n'est pas un texte qu'on aligne : un bon exercice a un objectif, des étapes, un livrable, un cadre de sécurité, parfois un prompt maître. Multiplié par 2400, et exigé de qualité, c'est là que la plupart des projets s'effondrent — soit ils renoncent au catalogue, soit ils livrent du contenu creux généré en masse que personne ne relit.
Le vrai risque n'a jamais été la techno de génération. Générer du texte, tout le monde sait faire. Le risque, c'est de tenir trois exigences en même temps :
- L'échelle — produire 2400 exercices sans une armée de rédacteurs.
- La qualité — chaque exercice doit être juste, utile, et adapté au métier visé, pas un remplissage interchangeable.
- La récurrence — sortir un 21ᵉ métier, ou rejouer une session 6 à 12 mois plus tard, doit coûter quasiment zéro. Sinon le modèle ne tient pas.
Le piège classique aurait été de coder 40 programmes comme 40 pages, chacune avec sa logique. J'ai pris le chemin opposé, et c'est tout le sujet de ce cas.
Mon approche
Une usine de contenu IA, pas une rédaction à la chaîne
Plutôt que d'écrire les exercices, j'ai construit la machine qui les produit. Un pipeline de génération prend en entrée un brief métier (le contexte d'un RH, d'un commercial, d'un responsable finance…) et un moule pédagogique commun, puis génère le contenu via un LLM — en l'occurrence Mistral, hébergé en Europe, ce qui compte pour un produit RGPD destiné à des salariés.
La sortie n'est jamais du texte libre : c'est du YAML structuré, validé par un schéma. Un exercice qui ne respecte pas la forme attendue (objectif, étapes, format, livrable, payload typé selon le format) est rejeté à l'import. La conséquence est décisive : le contenu n'est pas « à peu près correct », il est structurellement conforme avant même qu'un humain le lise. La génération devient un poste de production industriel — briefs en entrée, exercices validés en sortie — au lieu d'un travail d'écriture artisanal qui ne passe pas l'échelle.
« Le contenu est de la donnée, jamais du code »
C'est le principe directeur de toute l'architecture, et c'est lui qui rend les 40 programmes atteignables à deux.
Un programme — Marketing Fondation, RH Maîtrise, Finance Fondation — n'est pas une page codée. C'est un fichier de données qui remplit un moule unique : la structure des 8 semaines, l'arc pédagogique, l'attestation finale sont identiques pour tous les programmes. Le métier n'est qu'un skin injecté dans ce moule.
1 moule × N métiersajouter un programme = ajouter un fichier, zéro déploiement de codeLes conséquences sont énormes pour un produit jeune :
- Le coût marginal d'un métier tend vers zéro. Sortir un 21ᵉ métier, c'est ajouter un fichier — pas développer une nouvelle page, pas redéployer.
- Le risque qualité est mutualisé. On n'améliore qu'un seul moteur de rendu et un seul moule : un correctif profite à 40 programmes d'un coup, au lieu d'être à répliquer 40 fois.
- La récurrence est gratuite. Une nouvelle session 6 à 12 mois plus tard, c'est un nouveau fichier dans le même moule — aucune logique saisonnière n'est codée en dur.
Le versioning du contenu se fait en git, pas dans un CMS : le dépôt fait office d'historique et de revue. Du code qui rend n'importe quel programme conforme ; de la donnée qui décrit chaque métier.
La qualité : une porte humaine outillée et un cadrage LLM strict
Industrialiser ne veut pas dire abandonner la qualité à la machine. Au contraire — c'est précisément parce que la génération est massive qu'il faut une porte de qualité humaine sérieuse.
J'ai donc construit un outil de relecture interne (/admin/relecture) : chaque programme est trié par charge de relecture restante, chaque exercice s'affiche exactement comme le verra l'utilisateur final, à côté d'une checklist de critères et de boutons « OK / à corriger ». Un pré-scan heuristique signale les exercices suspects avant même la relecture humaine, pour concentrer l'effort là où il compte. Un programme n'ouvre que lorsqu'il atteint son seuil de relecture — typiquement 100 % pour les programmes vitrine. La machine produit ; l'humain valide ; rien ne passe en ligne sans avoir été vu.
Le cadrage du LLM est tout aussi soigné — c'est un point sur lequel je suis intraitable, et qui distingue un usage pro d'un usage bricolé : clé d'API côté serveur uniquement (jamais exposée au client), génération confinée au contexte de l'exercice, kill switch et budgets pour borner la dépense, et surtout — aucune donnée de salarié ne transite par l'IA. La génération est offline : le contenu est figé avant qu'un seul utilisateur n'arrive. Côté produit, c'est ce qui permet de tenir une promesse RGPD propre sur une plateforme destinée à des milliers de salariés.
Multi-plateforme web / iOS / Android sur une seule API
Le contenu n'est qu'une moitié du produit. L'autre, c'est une plateforme complète — et là encore, l'enjeu était de couvrir un maximum de surface sans démultiplier le travail.
J'ai construit une seule API (Symfony 8 / MongoDB) qui sert trois frontends : un site et une application web (Next.js 16), une application iOS (SwiftUI) et une application Android (Kotlin / Jetpack Compose). Même source de vérité, même contenu, mêmes parcours — déclinés sur trois plateformes natives plutôt que sur un habillage cross-platform de compromis. À cela s'ajoutent les briques qui font qu'un produit existe vraiment : authentification, paiement (Stripe Checkout, ouverture des paiements en juin), console pour les RH qui achètent des licences pour leurs équipes, et attestation générée en fin de parcours.
Tout ça, à deux fondateurs, en environ 5 semaines de build, 441 commits. Ce n'est pas un prototype : c'est une plateforme multi-canal en production, alimentée par une usine de contenu, avec un site déjà en ligne.
Ce que ça montre
Ce cas n'a pas de témoignage client à brandir, et c'est volontaire : ce que je veux montrer ici, c'est une capacité de build IA de bout en bout, sur un produit où j'avais les mains entièrement libres.
Concrètement, ce que j'ai démontré sur aiffut :
- Penser un produit comme une usine, pas comme une liste de pages. L'idée que « le contenu est de la donnée, jamais du code » n'est pas une élégance d'architecte : c'est ce qui transforme un catalogue de 40 programmes impossible à écrire en un catalogue qu'on génère, relit et fait évoluer à deux.
- Mettre l'IA agentique au service d'un livrable réel. Pas une démo, pas un POC : ~2400 exercices générés, validés par schéma, passés par une porte de relecture humaine outillée, et servis en production.
- Cadrer un LLM comme un pro. Clé serveur-only, confinement au contexte, kill switch, budgets, zéro donnée utilisateur dans l'IA. C'est l'écart entre « brancher une API et croiser les doigts » et un usage maîtrisé, défendable côté RGPD.
- Couvrir une large surface technique seul (ou presque). Symfony, MongoDB, Next.js, SwiftUI, Kotlin — une API, trois frontends natifs, paiement et console — en quelques semaines, parce que l'architecture a été pensée pour mutualiser plutôt que dupliquer.
C'est exactement la posture que j'apporte quand j'accompagne une équipe : ne pas saupoudrer de l'IA sur un produit, mais rebattre l'architecture pour que l'IA devienne un levier de production durable. Le « ×10 » dont tout le monde parle ne vient pas du modèle — il vient de la façon dont on cadre le problème autour de lui.
Et après
aiffut est en lancement. Le site est en ligne, l'ouverture des paiements est prévue pour juin, et le butoir du 2 août 2026 — date à laquelle les contrôles de l'AI Act s'activent — donne au projet une fenêtre nette pour s'adresser aux PME qui doivent traiter leur obligation de littératie IA. Le catalogue se relit et s'ouvre programme par programme, en commençant par les vitrines.
Le produit continuera d'évoluer, mais l'essentiel est déjà là, et c'est ce que je voulais raconter : à deux, en quelques semaines, avec une usine de contenu IA et une architecture pensée pour l'échelle, on peut sortir ce qui ressemblait à un catalogue irréalisable. C'est cette capacité — construire l'IA dans le produit, pas à côté — que je viens mettre au service des fondateurs et des dirigeants.
Pour aller plus loin sur la méthode : Formation à l'IA agentique et Sprint Fondateur.
