Cookuna : ce que construire notre propre SaaS nous a appris

La plupart de nos articles parlent des projets de nos clients. Celui-ci parle du nôtre. Cookuna est un carnet de recettes en ligne que nous avons conçu, développé et que nous exploitons nous-mêmes. On y colle le lien d’une recette trouvée sur le web, Cookuna en retire la publicité et le récit autour, on vérifie la fiche, puis on la retrouve partout, on la pose sur la semaine et on en tire la liste de courses.

Nous l’avons ouvert en bêta privée le 15 avril 2026. Six mois plus tard, il en est à sa sixième version. Ce texte raconte ce que ce produit nous a appris, avec une idée simple : les décisions que nous recommandons à nos clients, nous avons dû les prendre aussi, avec notre propre argent et notre propre temps. Certaines ont été faciles. D’autres beaucoup moins.

Si vous voulez d’abord voir à quoi ressemble l’application, les écrans sont sur la fiche réalisation de Cookuna. Ici, on parle des coulisses.

Le problème de départ : une recette enterrée sous la page

Tout le monde connaît la scène. Vous cherchez une recette de gratin, vous tombez sur une page qui commence par l’histoire d’un dimanche pluvieux chez une grand-mère, enchaîne trois blocs publicitaires, un bandeau de cookies, une invitation à la newsletter, puis, enfin, la liste des ingrédients. Le téléphone posé à côté de la planche à découper se met en veille, la page se recharge, la pub change de place et vous perdez la ligne où vous en étiez.

Le constat de départ tenait en une phrase : les recettes que les gens cuisinent vraiment sont dispersées entre des favoris de navigateur, des captures d’écran et des pages encombrées. Cookuna devait les rassembler dans un carnet personnel, propre, privé, utilisable d’une main en cuisine.

Ce constat ne dit rien de la technique. C’est voulu. Un produit qui démarre par sa stack démarre souvent du mauvais côté. Nous avons commencé par l’usage, puis nous avons choisi ce qu’il fallait construire pour le servir.

Un premier périmètre volontairement court

La première version publique, la 1.0.0, faisait peu de choses. Importer une recette depuis une URL. La relire et la corriger. La suivre étape par étape en mode cuisine. La partager par un lien privé. L’imprimer ou l’exporter en PDF. S’installer sur l’écran d’accueil du téléphone, comme une application.

Pas de planning, pas de liste de courses, pas de partage familial, pas d’application iPhone. Tout cela figurait pourtant déjà dans nos notes. Nous l’avons repoussé pour une raison que nous répétons souvent aux porteurs de projet : tant que le geste central n’est pas fiable, tout ce qui se construit autour hérite de sa fragilité. Ici, le geste central, c’était l’import. Si coller un lien ne donnait pas une fiche juste, aucune liste de courses ne sauverait le produit.

C’est exactement la logique que nous appliquons quand nous accompagnons le développement d’un SaaS sur mesure : trouver le plus petit produit qui prouve que l’usage existe, puis élargir sur des bases saines. Le reste du chemin s’est fait en versions courtes, chacune centrée sur une idée.

L’import, le cœur technique

Transformer n’importe quelle page de recette en fiche propre paraît simple tant qu’on n’a pas regardé le code source de quelques sites de cuisine. Chacun structure ses pages à sa façon, certains changent leur balisage sans prévenir, d’autres mélangent quantités et ingrédients dans la même ligne.

L’import de Cookuna lit donc une page en trois passes successives. D’abord les données structurées que beaucoup de sites publient pour les moteurs de recherche, au format schema.org Recipe : titre, ingrédients, étapes, temps, nombre de couverts. Ensuite la structure de la page elle-même, pour combler ce que ces données ne disent pas. Enfin un lecteur spécifique au site, quand nous en avons écrit un. Aujourd’hui, 29 sites ont leur propre lecteur, de Marmiton à Cuisine AZ en passant par 750g, Chefclub ou Ricardo, et un lecteur générique prend le relais pour les autres.

Ce découpage a une conséquence pratique : quand un site change son balisage, comme Marmiton l’a fait en septembre, nous corrigeons un lecteur isolé, testé à part, sans toucher au reste de la chaîne.

Promettre une vérification plutôt qu’une perfection

La décision la plus importante de l’import n’est pas technique. Nous avons renoncé à promettre une extraction parfaite. Aucun lecteur ne l’est. À la place, Cookuna montre ce qu’il a compris et signale ce qui mérite un coup d’œil : un ingrédient sans quantité, une étape vide, une unité ambiguë. L’utilisateur corrige en deux clics avant d’enregistrer.

Ce choix a changé le ton de tout le produit. Un import qui se trompe en silence trahit la confiance. Un import qui dit « vérifie la quantité de lait » la gagne. Nous retrouvons la même règle dans les logiciels métier que nous livrons : une automatisation honnête sur ses limites vaut mieux qu’une automatisation qui fait semblant.

Aller chercher une page web, c’est ouvrir une porte

Un champ qui accepte n’importe quelle adresse et demande au serveur d’aller la lire est une porte d’entrée classique pour les attaques. Sans précaution, quelqu’un pourrait faire lire à votre serveur des adresses internes qui ne devraient jamais sortir.

L’import de Cookuna n’accepte donc que des adresses publiques, vérifie chaque redirection avant de la suivre, fige la résolution du nom de domaine pour éviter qu’elle ne change entre la vérification et la lecture, et limite la taille de ce qu’il télécharge. Rien de tout cela ne se voit à l’écran. C’est précisément pour cela qu’il fallait le prévoir dès le départ : la sécurité ne se rajoute pas en rustine.

Six versions en six mois

Chaque version de Cookuna porte une idée, pas une liste de corrections. Voici le fil, tel que nous l’avons publié sur la page des nouveautés du produit.

• 1.0.0, 15 avril : importer, corriger, cuisiner pas à pas, partager, installer l’application depuis le navigateur.
• 1.1.0, 27 avril : un calculateur de portions qui ajuste toutes les quantités, fractions et plages comprises, onze nouveaux sites importables et une fiche recette repensée.
• 1.2.0, 6 mai : les vraies photos de plats, avec conversion automatique des photos d’iPhone et retrait des coordonnées GPS qu’elles contiennent, un mode pas à pas plus confortable sur téléphone et un thème qui suit le réglage clair ou sombre du système.
• 1.3.0, 25 juin : les collections pour ranger ses recettes, des minuteurs lancés depuis une étape (Cookuna repère les durées dans le texte) et huit guides pratiques.
• 1.4.0, 18 septembre : le planning des repas de la semaine et la liste de courses qui en découle, rangée par rayon, plus une nouvelle identité visuelle.
• 1.5.0, 9 octobre : la famille, pour partager recettes, planning et courses avec jusqu’à cinq proches, avec commentaires et journal d’activité.

Entre avril et septembre, le rythme a ralenti. Ce n’est pas un hasard : le planning et les courses ont demandé un vrai travail de fond. Un repas qui revient chaque mardi soir, une semaine sur deux, jusqu’à une date donnée, puis une exception un mardi précis : ce genre de règle se modélise mal à la va-vite. La liste de courses, elle, devait regrouper les mêmes ingrédients venus de plusieurs recettes, arrondir les quantités pour l’achat et, quand le planning change, proposer la mise à jour article par article sans jamais écraser ce que l’utilisateur a ajouté à la main.

Ce sont ces détails qui séparent une démonstration d’un outil qu’on garde. Ils ne se voient pas sur une capture d’écran, mais ils se sentent au troisième usage.

Ouvrir progressivement, compte par compte

Cookuna est en bêta privée, avec un accès par vagues. Les grandes fonctionnalités récentes, le planning, les courses et la famille, ne se sont pas allumées pour tout le monde le même jour. Elles s’ouvrent compte par compte.

Techniquement, chaque fonctionnalité sensible dépend de deux interrupteurs. Un interrupteur global sert de coupe-circuit : fermé, la fonctionnalité disparaît pour tous, sans déploiement. Puis un interrupteur par compte permet d’ouvrir d’abord à quelques personnes, d’observer, de corriger, puis d’élargir. Le code part en production fermé, il s’allume quand nous sommes prêts.

Cette mécanique a un coût : il faut tester chaque combinaison, écrire la procédure d’ouverture et la relire avant de l’exécuter. En échange, une nouveauté peut être livrée sans pari. Pour un client qui lance une évolution importante sur une base d’utilisateurs existante, c’est souvent la différence entre une mise en ligne sereine et une soirée à revenir en arrière.

La stack : des outils que nous connaissons par cœur

Cookuna repose sur la même base que la plupart de nos projets, et ce n’est pas un manque d’imagination. Un produit maison est un terrain d’essai, mais pas un terrain de jeu : il doit tenir dans la durée, et nous devons pouvoir le faire évoluer vite.

• Laravel pour le cœur applicatif : comptes, import, planning, courses, famille, file de tâches pour les e-mails et les notifications.
• Livewire pour l’interface interactive sans écrire une application JavaScript séparée, et Alpine.js pour les petites interactions locales comme les minuteurs.
• Tailwind CSS et une bibliothèque de composants pour une interface cohérente, en thème clair comme en thème sombre.
• Filament pour le back-office : suivi des comptes, ouverture des fonctionnalités, liste d’attente de la bêta.

L’intérêt de cette stack, pour un produit, tient en un mot : la vitesse de décision. Quand une idée mérite d’être testée, la question n’est pas « comment l’architecturer » mais « est-ce qu’elle sert l’usage ». C’est aussi pour cela que nous la recommandons sur les applications web de nos clients : le temps passé à lutter contre l’outil est du temps qui ne sert pas le produit.

Le mobile : d’abord le navigateur, ensuite l’iPhone

Une application de cuisine vit sur un téléphone posé sur le plan de travail. La tentation aurait été de commencer par une application native. Nous avons fait l’inverse.

Cookuna fonctionne depuis le premier jour dans le navigateur du téléphone et s’installe sur l’écran d’accueil comme une application. Ce choix nous a permis de valider l’usage sans passer par la validation des magasins d’applications, sans maintenir deux bases de code et sans faire télécharger quoi que ce soit aux premiers testeurs. Nous avons détaillé les forces et limites de cette approche dans notre guide native, hybride ou PWA.

Une application iPhone est désormais en préparation, et Android suivra. Elle s’appuie sur une interface de programmation que le serveur possède et documente : l’application mobile consomme ce que le serveur expose, elle ne réinvente pas les règles. C’est la même architecture que nous proposons quand un client nous confie une application mobile adossée à une plateforme web existante.

La confidentialité, une décision de produit

Un carnet de recettes paraît anodin. Il dit pourtant beaucoup : ce que vous mangez, pour combien de personnes, qui fait partie de votre famille, et parfois où vous avez pris une photo de votre plat.

Nous avons donc posé quelques règles simples. Chaque compte est isolé, et la bibliothèque n’est visible que par son propriétaire, ou par sa famille s’il en crée une. L’hébergement est européen et le service est conforme au RGPD. Les coordonnées GPS des photos sont retirées à l’envoi. Aucune donnée n’est revendue, et il n’y a aucune publicité. Nos conseils pour être en règle sans migraine ne sont pas restés théoriques : nous les avons appliqués chez nous.

Ces règles ont un effet secondaire intéressant : elles simplifient les décisions. Quand une idée de fonctionnalité suppose de collecter une donnée de plus, la question se tranche vite.

Les tests, notre filet de sécurité

Cookuna compte aujourd’hui plus de 3 000 tests automatisés. Ce chiffre n’est pas un trophée. Il décrit la seule façon de livrer six versions en six mois sans casser ce qui marchait déjà. Chaque lecteur de site est testé sur des pages réelles enregistrées, chaque règle de planning récurrent a ses cas limites, chaque interrupteur de fonctionnalité est testé ouvert et fermé.

Ce filet change la façon de travailler. Une modification du calcul des quantités dans la liste de courses n’est plus un pari : si elle casse le calculateur de portions de la fiche recette, nous le savons avant la mise en ligne, pas par un message d’utilisateur. C’est ce que nous appelons le soin invisible, celui qui fait qu’un produit dure.

Ce que Cookuna change pour vos projets

Construire notre propre produit nous a rappelé, de l’intérieur, ce que vivent nos clients. Quelques leçons valent bien au-delà des recettes de cuisine.

Couper le périmètre est une décision, pas un renoncement. Le planning et la liste de courses sont arrivés cinq mois après l’ouverture. Ils sont meilleurs parce que l’import était solide avant eux.

Dire ce qu’on n’a pas compris vaut mieux que deviner. La vérification avant enregistrement est probablement la fonctionnalité la moins spectaculaire de Cookuna, et l’une des plus utiles.

Livrer fermé, ouvrir progressivement. Les interrupteurs de fonctionnalités coûtent un peu de rigueur et évitent beaucoup de stress.

Le web d’abord, le natif quand l’usage est prouvé. Une application installable depuis le navigateur suffit souvent à valider un produit mobile.

Les tests sont ce qui permet d’aller vite. Sans eux, chaque version aurait été plus lente que la précédente.

Si vous hésitez encore entre un outil existant et un produit à vous, notre comparatif logiciel métier sur mesure ou SaaS pose les bonnes questions avant d’engager quoi que ce soit.

Où en est Cookuna aujourd’hui

Cookuna reste en bêta privée, gratuite et sans carte bancaire, avec une liste d’attente et des accès ouverts par vagues. L’application iPhone est en préparation, la famille s’ouvre progressivement, et le travail continue au rythme des retours des testeurs.

Vous avez une idée de produit et vous vous demandez ce qu’il faudrait vraiment construire pour la lancer ? C’est le genre de question que nous aimons trancher avec vous. Racontez-nous votre projet : nous vous dirons ce qui mérite d’être dans la première version, et ce qui peut attendre.