La journée d'un fondateur : contrôle financier à 09h00, rendez-vous client à 10h30, révision de la roadmap produit à 13h00, entretien 1-on-1 avec l'équipe à 15h00, rédaction stratégique à 18h00. Chaque transition exige 23 minutes (UC Irvine, 2021) de réchauffement cognitif. 5 rôles = 115 minutes de perte brute par jour. La solution n'est pas la routine superficielle mais une discipline de bloc profond — et ce n'est pas un simple calendrier en couleurs, c'est une refonte du mécanisme décisionnel.
Taux d'imposition de la commutation de contexte : le coût caché du calendrier du PDG
Combien de modèles mentaux différents un fondateur active-t-il en une seule journée ? Le réseau neuronal utilisé pour lire un tableau de bord financier n'est pas le même que celui activé lors d'un rendez-vous client. Chaque transition ouvre une nouvelle "charge mémoire de travail". L'étude de Gloria Mark (UC Irvine, 2021) le démontre : après une seule interruption, il faut 23 minutes pour retrouver la concentration. 5 sujets différents = 115 minutes de perte. La plupart des fondateurs ne voient pas cet impôt car le calendrier paraît "rempli".
La commutation de contexte n'est pas qu'une perte de temps, elle dégrade la qualité décisionnelle. La théorie de l'interférence duale (Pashler, 1994) est explicite : quand deux demandes cognitives sont actives simultanément, chacune fonctionne à 40 % d'efficacité. Consulter un tableau de bord financier à 09h00 puis se préparer à un appel client à 09h15 = ni les finances ne sont vraiment analysées, ni le contexte client n'est totalement chargé. Résultat : des demi-décisions dans les deux domaines.
Il faut mesurer les blocs calendaires non pas par "combien de contenu" mais par "combien de systèmes se chargent". La semaine d'un fondateur devrait idéalement se diviser en 3 modes majeurs : exécution (produit/opérations), externe (client/vente), stratégique (roadmap/recrutement). Chaque mode devrait occuper son propre bloc de 4 heures. Activer 3 modes le même jour = le taux d'imposition dépasse 60 %.
Bloc de deep work : fenêtre d'exécution ininterrompue de 4 heures
La définition du "Deep Work" selon Cal Newport : une tâche cognitivement exigeante menée en concentration totale sans interruptions. Dans le calendrier d'un fondateur, c'est généralement "écrire la roadmap produit", "réviser un pitch deck", "concevoir un pipeline de recrutement" — des travaux stratégiques. Mais la plupart des fondateurs les compressent dans des créneaux de 30 minutes. Résultat : une roadmap de 6 semaines s'étire sur 12 semaines.
Le bloc de 4 heures fonctionne selon une règle : un seul modèle mental actif, zéro signal externe. Slack fermé, téléphone en mode silencieux, client mail fermé, pas de réunion. Chez Roibase, ces blocs sont protégés 3 jours par semaine (lundi-mercredi-vendredi) de 09h00 à 13h00. Chaque bloc cible un seul livrable : une semaine sur la spécification produit, une semaine sur les critères de recrutement, une semaine sur la conception du pipeline de données. Si le travail n'est pas terminé à la fin du bloc, la portée est réduite.
Le ROI mesurable de cette discipline est clair : la roadmap Q2 2025 de Roibase a été rédigée en 4 blocs (16 heures). Auparavant, le même travail prenait 8 semaines (2 heures fragmentées par semaine). Seule différence : le temps ininterrompu, un seul contexte. Le ROI du bloc de deep work est 4x à l'heure. Mais ce n'est pas juste "bloquer le calendrier" — l'équipe doit aussi protéger ce bloc. Par exemple, chez Roibase, pendant le deep work, l'équipe ne mention pas le fondateur sur Slack, ne marque pas ses messages comme urgent.
Stack de time-blocks : exécution, externe, stratégique
La semaine d'un fondateur devrait se diviser en 3 stacks majeurs :
| Stack | Heures | Jours | Exemple d'activité |
|---|---|---|---|
| Exécution | 09h00-13h00 | Lun-Mer-Ven | Spec produit, pipeline de données, conception du recrutement |
| Externe | 14h00-17h00 | Mar-Jeu | Appel client, pitch, mise à jour investisseur |
| Stratégique | 18h00-20h00 | Mer | Révision roadmap, planification OKR, rétrospective d'équipe |
Le bloc exécution est 4 heures ininterrompues. Le bloc externe est divisé en créneaux de 45 minutes selon la cadence client (15 minutes de tampon entre). Le bloc stratégique est concentré 1 jour par semaine — pas fragmenté. Cette structure canalise les tâches superficielles vers un canal séparé : emails, Slack, validations, tous traités entre les blocs externes ou en fin de journée après la fenêtre stratégique.
Cadence de rendez-vous client : fenêtre de disponibilité prévisible
L'accessibilité du fondateur aux clients ne peut pas être constamment ouverte — mais ne peut pas non plus être fermée. La solution : 2 jours par semaine (mardi-jeudi), 14h00-17h00, créneaux de 45 minutes. Le client connaît cette fenêtre, le lien Calendly ne montre que ces horaires. Les demandes en dehors sont canalisées vers le canal async : vidéo Loom, fil email, doc Notion.
L'avantage de cette cadence est bidirectionnel : pour le fondateur, la commutation de contexte est minimale (2 jours en mode externe), pour le client, le temps de réponse est prévisible. Chez Roibase, le temps de réponse client moyen est 48 heures — mais ce n'est pas une "attente incertaine", c'est "créneau jeudi 14h00" bien défini. La satisfaction client vient de cette prévisibilité, pas d'une réaction instantanée.
Comment traite-t-on les demandes urgentes en dehors de la cadence ? Chez Roibase, "urgent" est étroitement défini : production down, deadline légale, réunion investisseur chevauchante. Ces demandes sont marquées sur Slack avec la commande /urgent et une notification push va au fondateur. Mais en Q2 2025, seulement 3 appels urgents sont arrivés — si la cadence est bien construite, le vrai urgent tombe sous 1 par mois.
Fenêtre de réponse asynchrone : SLA 24h, protocole de batching
La communication asynchrone est la discipline centrale du calendrier fondateur. Mais "async" ne signifie pas "pas de réponse". Le standard Roibase : réponse email/Slack SLA 24h, mais traitée en mode batch. Le fondateur traite l'inbox 2 fois par jour : 13h00 (fin bloc exécution) et 20h00 (fin bloc stratégique). Les notifications sont désactivées en dehors ces fenêtres.
Est-ce qu'un SLA de 24h suffit aux clients/équipe ? Les données disent oui. L'NPS client 2025 de Roibase est 72 — le temps de réponse médian est 18h. Aucun client n'attend une réaction instantanée car l'onboarding énonce clairement la cadence : "Les réponses aux emails arrivent dans les 24h, les demandes de réunion sont sur créneaux mardi/jeudi." La gestion des attentes vaut plus que le SLA.
Le deuxième avantage du batching : la qualité de réponse. Au lieu de répondre à un mail isolé immédiatement, accumuler 10 mails et les traiter dans le même contexte rend les réponses plus cohérentes. Par exemple, si 5 clients posent la même question différemment, le batching révèle ce pattern et le transforme en un seul doc Notion. Résultat : le temps de réponse diminue ET la base de connaissances grandit.
Outils asynchrones : Loom, Notion, références d'issues Linear
La réponse asynchrone n'est pas que du mail. Chez Roibase, quand une question client arrive, le fondateur utilise 3 formats :
- Vidéo Loom (2-3 minutes) : Si l'explication est complexe. Par exemple, une question "Comment configurer le pipeline BigQuery ?" reçoit un enregistrement d'écran de 2 min + voix off. Le client l'écoute quand il veut.
- Doc Notion : Si c'est une FAQ, un template Notion est créé. Le lien est envoyé. Le client peut commenter.
- Référence d'issue Linear : Si c'est une demande technique, une issue Linear est ouverte directement. Le client suivi la progression.
Le trait commun de ces formats : asynchrone mais traçable. Le client n'a pas besoin de demander "où en est-on" car Notion/Linear montre déjà l'état. Le fondateur ne répète pas la même question 5 fois car le lien Loom/Notion peut être renvoyé.
Hygiène calendaire : examen récurrent et discipline de protection du bloc
Si le bloc deep work n'est pas protégé, le système entier s'effondre. Chez Roibase, chaque vendredi 17h00-17h30 il y a un "examen d'hygiène calendaire". Le fondateur passe la calendrier de la semaine suivante au crible :
- Des réunions se sont-elles glissées dans les blocs exécution (09h00-13h00) ? Si oui, elles sont refusées ou déplacées au bloc externe.
- Y a-t-il des créneaux de plus de 45 minutes dans le bloc externe (14h00-17h00) ? Si oui, ils sont divisés en deux ou basculés en async.
- Le bloc stratégique (18h00-20h00) est-il fragmenté sur plusieurs jours ? Si oui, il est consolidé un seul jour.
Si cet examen n'est pas discipliné, les blocs s'érodent en 2 semaines. Par exemple, "juste cette fois" programmer un appel client lundi 10h00 fragmente le bloc exécution en 09h00-10h00 + 11h00-13h00. Résultat : au lieu d'un bloc de 4h, deux blocs de 2h — pas de deep work, juste du chaos superficiel.
Les réunions récurrentes sont la menace la plus grande. Chez Roibase, la durée par défaut d'une réunion récurrente est 6 semaines — pas l'infini. Après 6 semaines, la réunion se supprime automatiquement ; si elle est encore nécessaire, elle doit être ajoutée manuellement. Cette règle force la question "C'est toujours utile ?". En Q1 2025, il y avait 12 réunions récurrentes, en Q2 il n'en restait que 4. Aucune information ne s'est perdue car le canal async était actif.
Le calendrier du fondateur ne doit pas être mesuré par "combien de contenu" mais par "combien de systèmes se chargent". L'impôt de commutation de contexte approche 2 heures par jour — mais il est invisible car le calendrier paraît coloré et "productif". La solution : bloc de deep work de 4 heures, cadence client prévisible et SLA async de 24h. La discipline n'est pas de bloquer le calendrier mais de protéger le bloc — et l'équipe/les clients doivent aussi internaliser cette structure. L'expérience de 8 ans de Roibase montre ceci : quand le calendrier du fondateur est chaotique, l'équipe aussi l'est, et même la marque reflète ce manque de discipline opérationnelle. La discipline du time-blocking n'est pas un hack de productivité mais un standard culturel.