Comment j'ai construit le site de Memoways sans écrire une ligne de code

Depuis le 26 septembre, memoways.com a remplacé le site que nous publiions jusque-là avec Super.so, à partir de nos pages Notion. Je l'ai construit en quelques mois sans écrire une ligne de code, en dialoguant avec des outils d'IA capables de produire du code à partir d'une description en langage courant. Voici comment ce chantier s'est organisé, ce que j'y ai appris en chemin et les envies qu'il a fait naître.

Une vitrine ne suffit pas; se mettre au service du visiteur

Notre ancien site faisait ce qu'on attend d'une vitrine : il montrait nos projets, nos ressources et nos billets, dans l'ordre où nous les avions rangés. Mais qui arrive sur un site pour le lire dans l'ordre ? On arrive avec une question, souvent floue (est-ce qu'ils pourraient m'aider ? ont-ils déjà fait quelque chose de proche ?), et on repart si la réponse ne vient pas assez vite.

J'avais envie d'un site qui se mette au service de cette personne : qu'il réponde à sa question, la rassure sur ce que nous savons faire et lui donne envie d'aller plus loin. Je voulais aussi qu'il montre cela au lieu de l'annoncer, en lui faisant vivre dès la première visite un avant-goût de ce que serait une collaboration avec nous.

C'est le rôle de la conversation, au cœur du nouveau site : on pose sa question, et l'agent répond en s'appuyant sur nos projets, nos billets et notre base de ressources. Les trois petites animations de la page d'accueil racontent ce trajet : des documents épars, puis une mémoire structurée, puis une voix qui oriente vers une action humaine.

Pourquoi maintenant

Ce site, je n'aurais pas pu le construire il y a deux ans, pour deux raisons qui se sont rejointes.

La première tient à notre propre travail. Depuis des années, nos projets, nos ressources et nos billets vivent dans des bases Notion structurées, avec des champs, des catégories et des liens entre eux. Un agent conversationnel y trouve une matière solide (sans cette mémoire organisée, il n'aurait rien de pertinent à dire sur nous).

La seconde tient aux outils. Les modèles d'IA savent désormais converser à partir d'une telle base sans trop inventer, et ils savent aussi écrire du code à partir de ce qu'on leur décrit. Quelqu'un comme moi peut donc construire un site complet sans équipe technique.

Le site lit nos bases Notion, les copie dans une base de données (Supabase) et les affiche avec un framework web (Next.js) : quand nous mettons à jour un projet dans Notion, le site suit. Une vidéo à venir montrera cette mécanique ; ici, je voudrais surtout raconter la méthode.

Préciser avant de construire

L'essentiel du travail a eu lieu avant la première ligne de code. J'ai d'abord pris le temps de reformuler nos intentions et notre stratégie, puis de rassembler ce que nous appelons nos Fondations : qui nous sommes, pour qui nous travaillons, ce que nous proposons et sur quel ton nous le disons.

J'ai ensuite consacré une dizaine de jours au PRD (product requirements document, en français le cahier des besoins). Ce document décrit ce que le site doit faire, pour qui et dans quelles situations, avant de se demander comment le programmer. L'écrire revient à préciser ses besoins jusqu'à ce qu'il ne reste plus d'ambiguïté. Que se passe-t-il quand un visiteur pose une question à laquelle nos contenus ne répondent pas ? Comment une fiche projet dans Notion devient-elle une page ?

Pour y arriver, je me suis beaucoup appuyé sur Grill Me, un skill (une consigne réutilisable pour un agent IA) publié par Matt Pocock, qui demande à l'IA de vous interroger jusqu'à ce que chaque réponse vague devienne une décision. Se faire presser le citron de cette manière est parfois inconfortable, mais c'est ce qui rend la suite possible. Un outil qui écrit du code comble chaque zone floue avec la solution la plus probable, donc la plus moyenne : ce qu'on n'a pas décidé soi-même finit par ressembler à n'importe quel autre site.

Découper en lots

Un PRD de cette taille ne se confie pas d'un bloc à une IA. Chaque grand chantier (la conversation, le design, l'administration du site…) est devenu une grosse tâche dans Notion, elle-même divisée en lots.

Un lot est une portion de travail assez petite pour être décrite, construite et vérifiée en une fois, avec ses propres critères de réussite. Par exemple, le temps d'attente avant le premier mot de la conversation est passé de 8,2 à 3,6 secondes au fil de cinq lots successifs. Certains lots m'ont pris deux ou trois journées entières d'affilée.

Ce découpage a un avantage que j'ai appris à mes dépens : quand quelque chose casse, on sait où chercher, et chaque session repart d'un contexte propre. Un jour, j'ai laissé un modèle très puissant (Claude Opus, dans Claude Code) enchaîner une session marathon, et la facture a atteint une cinquantaine de dollars d'un coup.

Changer d'outil selon le moment

Les outils changent vite, et leurs performances aussi : ce qui fonctionnait remarquablement bien cet été fonctionne parfois moins bien quelques semaines plus tard. J'ai donc pris l'habitude d'alterner et de comparer ce que chacun proposait, plutôt que de m'attacher à un seul.

Le système de design, c'est-à-dire les couleurs, typographies, espacements et composants que tout le site réutilise, a demandé de nombreuses itérations avec différents agents de design, toujours à partir de nos contenus Notion. Pour juger ces essais, j'ai fait construire dans l'administration du site un petit laboratoire qui affiche quatre formes d'un même bloc (standard, carte, section, compact) dans le vrai rendu des pages. On évite ainsi de trancher sur une maquette ce qui se joue en réalité à l'écran.

Le chemin entre l'idée et le code s'est aussi raccourci. Notion est désormais connecté à ces outils, et je lance des agents Cursor directement depuis une conversation dans Notion, là où vivent déjà la tâche, son contexte et l'historique des décisions. Je leur donne ce contexte (d'où vient le projet, où il en est, ce que nous aimerions qu'il devienne) sans leur dire comment s'y prendre techniquement. Je leur demande d'abord un plan, que je discute et corrige avant qu'une seule ligne soit écrite.

Chaque décision importante est consignée dans un ADR (architecture decision record), une courte fiche qui dit ce qui a été décidé et pourquoi ; il y en a aujourd'hui plus de soixante. C'est l'idée du compound engineering : chaque lot laisse derrière lui de la documentation et des règles qui rendent le suivant plus rapide et plus sûr.

Ce que les tests ne voient pas

Un site construit de cette manière est vérifié en permanence par des tests automatiques. J'ai appris à m'en méfier autant qu'à m'y fier : il est arrivé que le site se construise sans erreur alors que des contenus s'affichaient dégradés.

Une vérification au vert ne garantit pas un bon résultat.

Plus parlant encore, nous avons simulé 86 visiteurs posant des questions à la conversation. Sur les quatre questions qui portaient sur notre offre, l'agent n'apportait de vraie réponse à aucune. Il a suffi de lui transmettre notre offre publiée pour qu'il réponde aux quatre. Il ne lui manquait que la bonne matière, ce qui ramène, au fond, au travail de préparation du début.

Ce que j'ai appris en chemin

Je ne sais toujours pas écrire une ligne de code, et pourtant, d'une certaine manière, je suis devenu développeur : j'ai appris à faire générer du code, à orchestrer les outils qui le produisent, et surtout à obtenir du code utile, qui fonctionne.

Les bases de données bien pensées, je les pratiquais déjà depuis des années dans Notion. Ce chantier m'a fait descendre plus bas dans la machine, vers ce qu'il y a derrière une interface : comment une base de données est construite sous le capot, comment on en relie deux entre elles (ici Notion et Supabase, qui doivent rester d'accord sur chaque fiche), ce que demande la sécurité et sur quels principes elle repose. J'ai aussi compris, en le vivant, pourquoi on compartimente et on modularise : séparer les parties pour qu'une erreur dans l'une n'emporte pas les autres. Et comment installer des cycles vertueux, où chaque correction améliore la méthode en même temps que le site.

Ce fut un voyage très riche dans les rouages d'un site, et l'appétit vient en mangeant : plus le site avançait, plus les idées sur ce qu'il pourrait devenir se multipliaient.

Ce que nous avons envie de construire ensuite

La conversation évoluera au rythme de ce qui la nourrit : notre base de ressources et un travail de curation (filtrer, sélectionner, synthétiser pour d'autres) que nous voulons élargir bien au-delà des questions techniques. Cette générosité se voit déjà dans certaines pages projets, comme celle d'Ava, un projet de médiation que nous avons pu raconter en profondeur.

Nous aimerions ensuite ouvrir un portail pour nos clients et partenaires : des accès selon les projets, une base de connaissances partagée, et un recueil de petits outils, faits maison ou intégrés, pour des tâches du quotidien comme détourer une image.

Nous voulons aussi reprendre ce que nous avions amorcé l'an dernier avec Open Research : partager nos questions de recherche en groupe, réactiver notre Discord et réunir un collectif de développeuses et développeurs qui échangent leurs pratiques et leurs questions.

Le site passera bientôt en anglais. En attendant, le plus simple pour voir où nous en sommes est de lui poser une question (et, si la réponse vous laisse sur votre faim, de nous dire ce qui lui manque).

Pour aller plus loin