M9 — 3 Systématiser les instantanés de dossiers
Trois systèmes réels. L'un en production chez Bausele en ce moment, transformant le chaos de « chaque nouvelle goutte est un nouveau lancement » en un cycle de 10 semaines reproductible. L'un est en direct dans cette session exacte — le système qui a produit la page que vous lisez. Un autre est un espace réservé pour le premier fondateur de la première cohorte de l'Accélérateur.
Cas A — Playbook Bausele Next Drop (EN DIRECT, verrouillé le 28 avril 2026)
Le cycle de 10 semaines qui a transformé chaque lancement de produit d'une improvisation fraîche en une opération reproductible.
Le problème que le playbook résout. Bausele lance un nouveau modèle tous les 2-3 mois. Pendant la majeure partie de l'histoire de la marque, chaque lancement était traité comme un événement unique — nouvelle séquence d'e-mails, nouvelle création publicitaire, nouveau calendrier de campagne, nouvelles réunions internes pour décider qui fait quoi et quand. Le modèle du 14 avril — construit goutte à goutte — s'est effondré sous sa propre complexité, avec des décisions de séquençage prises trop tard et des artefacts opérationnels réinventés à chaque fois. Le diagnostic n'était pas « le marketing est faux ». Le diagnostic était « chaque lancement est géré comme un processus de découverte, et non comme une opération connue ». Le même problème que tout fondateur rencontre à grande échelle : l'improvisation est bien quand l'opération se déroule quatre fois par an et deux fois mieux quand elle se déroule une fois — jusqu'à ce que cela ne le soit plus.
Le système tel que verrouillé. Le 28 avril 2026, le Next Drop Playbook a été verrouillé. La forme : un cycle de 10 semaines, relatif aux lancements — ce qui signifie que chaque action est programmée en fonction du jour de lancement (jour de lancement moins X) plutôt que d'une date calendaire fixe, de sorte que le même playbook se reproduit à chaque lancement sans reconstruction. Les composants : un flux d'e-mails principal de 8 e-mails séquencés par rapport au jour de lancement, un flux « Arrivées tardives » de 2 e-mails supplémentaires pour les acheteurs qui rejoignent la liste dans la dernière fenêtre avant le lancement, 9 campagnes réparties sur les 10 semaines, et un entonnoir Meta Direct-to-PDP qui fonctionne en parallèle à partir du jour de lancement moins 3. Le playbook vit dans Notion (ID de page 34f1a028-e81b-81e6-bbd8-cdf2d0b9e1e6) comme source unique de vérité — détenue, versionnée, éditée sur place plutôt que recréée.
Pourquoi l'architecture est plus importante que le contenu. Les 8 e-mails, les 2 e-mails d'arrivées tardives, les 9 campagnes et l'entonnoir Meta changeront tous en détail d'un lancement à l'autre — produit différent, coloris différent, saison différente, taille de liste d'attente différente. Ce qui ne change pas, c'est l'architecture : 8 emplacements dans le flux d'e-mails, 9 emplacements dans la grille de campagne, jour de lancement moins X comme épine dorsale de la planification. À chaque lancement, l'équipe remplit les emplacements plutôt que de concevoir les emplacements. La charge cognitive de l'exécution d'un lancement a diminué d'un ordre de grandeur — non pas parce que le travail a disparu, mais parce que le travail est passé de « concevoir l'opération » à « exécuter l'opération ». L'équipe se dispute maintenant sur le texte de l'emplacement 4, et non sur la question de savoir si l'emplacement 4 devrait exister.
Ce qui a dû casser en premier. Le playbook n'a pas été construit lors d'une semaine de planification tranquille. Il a été construit dans les décombres du modèle du 14 avril qui s'est effondré — décisions tardives, séquençage désordonné, post-mortems qui pointaient tous vers la même cause profonde : pas d'architecture fixe, chaque lancement réinventé. Les documents système les plus importants ne sont presque jamais écrits avant un échec. Ils sont écrits immédiatement après un échec, alors que le coût de l'échec est suffisamment frais pour combattre la tentation d'ajouter « juste un petit peu plus de flexibilité ». Le playbook est rigide à dessein. La rigidité est ce qui le rend reproductible.
La leçon : Un système n'est pas le document. Le système est la cadence que le document impose. Le Next Drop Playbook est constitué de deux pages de structure qui verrouillent 10 semaines d'opérations — chaque lancement s'exécute maintenant selon le même squelette, chaque membre de l'équipe sait qui possède quel emplacement à quelle date, chaque lancement produit des données comparables au précédent parce que l'opération est comparable. Le fondateur n'est plus le système d'exploitation des lancements de Bausele. Le playbook l'est.
Cas B — Modèle de construction et de publication de modules du Kit d'outils EXITR (EN DIRECT, mai 2026)
Le système qui a produit la page que vous lisez actuellement.
La configuration. Mai 2026. Le Kit d'outils EXITR a besoin de 12 pages de module en ligne sur Shopify, chacune avec un héros, un slogan, un espace réservé pour une vidéo, un récit de ce que vous ferez, une section de modèles, un pack de 10 invites, une auto-vérification, une page complémentaire de feuille de travail de 6 pages et 3 pages complémentaires d'étude de cas. Si cela est fait un module à la fois, manuellement, dans un nouveau chat à chaque fois, cela représente une semaine de 30 à 40 heures de négociation sur le format, le ton, la structure, le nommage des fichiers, les identifiants de page et les commandes de publication. Fait de manière improvisée, les modules 2 à 12 auraient ressemblé à 11 pages différentes, liées entre elles par un nom de marque.
Le système tel qu'exécuté. Début mai 2026, Christo et l'agent généraliste EXITR (Sasha) ont suivi un modèle fixe, semaine après semaine, module après module. La forme : (1) convention de fichier unique — chaque brouillon se trouve dans ~/exitr/toolkit-modules/M[n]-draft-v[n]-en.md, sans exception, facile à trouver, facile à comparer ; (2) un modèle de module fixe — héros → slogan → vidéo → ce que vous ferez → modèles → pack de 10 invites → auto-vérification → feuille de travail de 6 pages → 3 études de cas — appliqué inchangé à partir du M2 afin que chaque module ait une parité structurelle avec le précédent ; (3) un rituel de révision fixe — brouillon livré en ligne dans le chat, trois options de clôture : publier / modifier / jeter ; (4) une opération de publication fixe — quatre opérations Shopify par module (modèle + page de feuille de travail + page de cas + renommage du titre d'administration) exécutées dans un ordre connu ; (5) une mise à jour de mémoire fixe — le résultat enregistré dans la mémoire du projet afin que la prochaine session s'ouvre avec le contexte déjà chargé.
Ce que le système a produit. Sept modules livrés de bout en bout en une seule session de travail — M2 à M8 — chacun avec la page principale, le compagnon de feuille de travail, le compagnon de cas et le titre d'administration. Même parité structurelle. Même ton. Même rythme opérationnel. Les décisions qui ont pris 40 minutes de négociation en M2 prennent moins de 5 minutes à partir du M5, non pas parce que quelqu'un va plus vite, mais parce qu'il n'y a plus rien à décider qui n'ait pas été décidé au niveau du système. Le travail est passé de « concevoir le module » à « exécuter le module » — le même changement que le playbook Bausele Next Drop a produit pour les lancements.
Pourquoi il s'agit de l'étude de cas pour ce à quoi ressemble réellement le M9 en temps réel. La page que vous lisez a été produite par le système qui l'a produite. Elle ne décrit pas le système de manière abstraite. Le lecteur peut vérifier : ouvrez le répertoire de fichiers du module du kit d'outils et voyez M2-PUSHED, M3-PUSHED, M4-PUSHED, M5-PUSHED, M6-PUSHED, M7-PUSHED, M8-PUSHED dans le même modèle de nommage que M9-draft-v2-en-PUSHED.md à côté d'eux. Le modèle est visible. La cadence est visible. L'effet cumulatif est visible — M9 prend moins de temps que M8, M8 moins de temps que M7, M7 moins de temps que M6, car le système fait plus de travail à chaque cycle. C'est ce que le pack d'invites ci-dessus demande au fondateur de construire pour sa propre offre. Un système qui, au module M12, aura produit 11 pages supplémentaires sans qu'aucune d'entre elles ne fasse l'objet d'une nouvelle négociation.
La leçon : Un système digne de ce nom se compose. Le premier cycle est lent — M2 a pris plus de temps que prévu car le modèle était en cours de construction pendant que le module était livré. Le second a été plus rapide. Le troisième encore plus rapide. Au septième, le système produisait des modules à un rythme que l'improvisation ne peut égaler en termes de qualité à grande échelle. La question du fondateur en M9 n'est pas « que devrais-je systématiser ». La question est « quelle est la prochaine chose que le système peut absorber afin que le fondateur fasse moins de travail répétable chaque semaine et plus de travail irremplaçable ». La page que vous lisez est ce à quoi ressemble la capitalisation lorsqu'elle est visible.
Cas C — [Nom du fondateur], cohorte 1 de l'Accélérateur (espace réservé)
La dimension services / SaaS / marque personnelle.
Cet emplacement sera rempli le jour où la cohorte 1 de l'Accélérateur terminera le M9. Même convention que M2-M8 — réécrit avec l'ensemble des piliers de contenu d'un vrai fondateur, leur calendrier de cadence de 90 jours avec le taux de livraison réel par rapport à l'objectif, le canal du M8 qu'ils ont choisi de systématiser en premier, la couche de suivi des conversions qu'ils ont construite, le seuil d'alerte qui s'est déclenché en semaine 4 et ce qu'ils ont reconstruit, et l'audit honnête de la préparation à la passation de pouvoir qui a décidé ce que le M11 leur enlèvera en premier.
En attendant, un principe de travail tiré de vingt-cinq ans à observer des fondateurs franchir — et ne pas franchir — la ligne de la systématisation :
Le fondateur qui échoue au M9 est rarement celui qui ne sait pas créer les documents. Il les crée. Les piliers sont définis. Le calendrier est dessiné. Le SOP est écrit. Le tableau de bord est configuré. Trois mois plus tard, le calendrier est à moitié vide, le tableau de bord n'a pas été ouvert depuis six semaines, et le fondateur est de nouveau en train de décider quoi livrer chaque lundi matin comme il le faisait en M1. Les documents existaient. La cadence ne s'est pas déroulée. Le mode d'échec le plus courant du M9 est de confondre les artefacts avec le système. Les artefacts sont une décoration. Le système est ce qui se passe dans la pièce le lundi matin à 9h quand le fondateur ouvre ou n'ouvre pas le tableau de bord.
Un fondateur avec qui j'ai travaillé lors d'un cycle précédent avait un magnifique espace de travail Notion — trois piliers définis, un calendrier de 90 jours construit, des invites de rédaction par IA écrites, un tableau de bord de conversion configuré jusqu'aux seuils d'alerte. En examinant l'espace de travail à la semaine 8, le diagnostic était visible dans le journal d'audit : le calendrier n'avait pas été touché depuis la semaine 2. Le tableau de bord n'avait pas été ouvert depuis la semaine 3. L'invite de rédaction n'avait été utilisée que deux fois. Le système que le fondateur avait construit était le système que le fondateur s'était décrit. Le système que le fondateur utilisait réellement était le même rythme improvisé qu'en M1, habillé d'outils améliorés. La solution n'était pas plus de documents — c'était un seul bloc de calendrier récurrent le lundi à 9h, 30 minutes, tableau de bord ouvert, calendrier examiné, trois éléments rédigés à livrer cette semaine. À partir de là, le système a commencé à fonctionner. Non pas parce que les artefacts ont changé. Mais parce que la cadence a finalement changé.
Le premier étranger qui paie en M8 est gagné par le fondateur qui sait demander. Les quinze suivants sont gagnés par le fondateur qui sait construire une cadence et la maintenir. La phase 3 ne peut pas fonctionner sur l'improvisation. M9 est le module où le fondateur cesse d'être le système d'exploitation de l'entreprise et commence à en être l'éditeur. M11 ne peut commencer tant que cela n'est pas vrai.