1 L'étincelle
Trois fils qui se nouent d'un coup
Pourquoi j'ai démarré tout ça ? Bonne question — et honnêtement, le déclic est difficile à isoler, parce qu'il vient de trois fils qui se sont noués d'un coup :
- Trois mois à fond dans l'IA. Depuis février 2026, je ne fais quasiment que ça. Beaucoup de choses se percutent dans ma tête.
- Mon Club Bootstrap. On y parle autant d'IA que du métier de CEO — la solitude du dirigeant, l'émotion, les relations, ce qui se joue vraiment dans une boîte.
- L'envie de revenir au cœur de mon métier. J'avais déjà fait un média qui tourne tout seul, des agents qui fabriquent une entreprise, une idée. Là, je voulais refaire ce que je fais depuis toujours : fabriquer un éditeur logiciel, depuis le tout début.
Un jour, l'étincelle jaillit entre les trois. Je me dis : je vais le faire en bootstrap, un truc qui parle au CEO — au président — et je vais le faire tout seul. Surtout pas dans Jamespot : là-bas il y a une armada, une équipe, une marque, une plateforme, une dizaine d'applications qui tournent déjà. Non. Quelque chose à côté. Unitaire. Un pari.
Rien n'était vraiment planifié. J'avais juste en tête que le 1er mai arrivait et que j'aurais un peu de temps. Je suis parti sur une impulsion. (La suite — le produit en prod dès le 2ᵉ jour — est dans le Pilier II.)
2 Le vrai problème
L'insight avant le code
Avant d'écrire une ligne, je suis revenu à ce que je sais faire depuis toujours : chercher l'insight. Un produit doit résoudre un problème réel, sinon il ne sert à rien.
Le problème, le voici : le CEO d'une boîte qui grandit est souvent seul. Il ne sait pas vraiment ce qui se passe à l'intérieur. Il entend des choses dont il ne comprend pas l'origine. Il est débordé par le réel qui lui remonte à la figure — et qu'il n'a pas vu venir.
Ce que je voulais offrir, c'est l'inverse : une organisation paisible, en harmonie, alignée. L'alignement, c'est mon objectif numéro un.
Et je voulais l'atteindre par un angle particulier : aligner par l'émotionnel, pas par le rationnel. Pas un tableau de bord de plus — la voix des gens, leur ressenti, la vérité de terrain.
3 Le mur de Dunbar
Le cadrage fait émerger l'angle
Le concept, lui, est venu après — en faisant le travail de ciblage. Je m'attaque à qui, au juste ?
- Les petites boîtes (< 15) n'ont pas la douleur : pas de marché.
- Les grosses (> 150) ont déjà adopté Asana, Notion, Linear, Confluence : compétition frontale impossible.
En bornant ainsi — par la douleur en bas, par la concurrence en haut — une fenêtre est apparue : 15 à 150 personnes. Et avec elle, le mur de Dunbar : au-delà d'environ 150 relations stables, la coordination organique s'effondre (à 150 personnes, la théorie des graphes donne déjà plus de 11 000 canaux possibles). Le symptôme est mathématique, pas culturel — d'où ma conviction que les team buildings n'y peuvent rien.
Ce travail de conceptualisation, je l'ai fait avec l'IA. Elle m'a aidé à mettre un cadre, des mots, une théorie sur une intuition que j'avais déjà. Je l'assume : l'IA n'a pas seulement écrit du code, elle m'a aidé à penser le produit.
La cible s'est resserrée d'elle-même : CEO de boîtes de services de 15 à 150 personnes (sweet spot 60-120), ceux qui sentent le mur. Le détail du périmètre — ce qui est dans la V1, ce qui en est exclu — est dans le Pilier I.
4 Les partis pris
Trois convictions qui ont tout structuré
Trois convictions fortes, posées tôt. Elles ont tranché mille micro-décisions sans que j'aie à y revenir.
a. Contre l'anonymat — et la force de la parole
J'ai toujours eu un problème avec l'anonymat. On voit ce que ça donne sur X : les gens se lâchent, et c'est souvent le pire qui sort. L'anonymat crée les conditions du n'importe quoi.
Sauf qu'il y a un vrai double bind : un employé doit parler à son CEO et n'ose pas ; à son manager et n'ose pas non plus. L'anonymat « réglerait » ça — mais ouvrirait la porte à tous les débordements.
Ma réponse tient dans un déplacement : pas d'anonymat des personnes, mais la parole comme espace de liberté. Parce que quand on parle, on s'exprime tel qu'on est, avec l'émotion. Quand on écrit, on se relit, on se censure — « attention à comment les autres vont me lire ». C'est ce que l'école nous a appris. La voix, elle, laisse passer la vérité.
Tenez : ce chapitre, je vous le dicte à voix haute. Je parle, l'IA écrit. La preuve par l'exemple de ce que je crois profondément — la parole libère ce que l'écrit corsète.
Je l'assume : renoncer à l'anonymat complique le produit (il faut alors soigner la propagation, traduire le brut émotionnel en une couche « civile » partageable). Mais je parie que c'est ce qui lui donnera sa force dans le temps. On verra — chez ceux qui l'utilisent.
b. Souveraineté-first, pas souveraineté-only
C'est une conviction profonde : si on refait un truc génial mais qu'on reste sous les fourches caudines américaines, on n'avance pas. Alors j'ai voulu explorer le sujet sous cet angle.
Mais jamais une souveraineté absolue, idéale. Une souveraineté first : on fait souverain d'abord, majoritairement — et plus que majoritairement. Au final, DWG tourne sur une stack souveraine à plus de 90 %, avec la capacité, si je le veux, de débrider les IA américaines là où elles excellent.
C'est personnel, oui. Mais c'est surtout pour aider le secteur. Je veux donner un exemple, être un rôle modèle : montrer qu'on peut faire un vrai produit sans tomber, par réflexe, dans la stack américaine — sans dégainer Slack d'entrée.
c. Le solo comme exercice de style
Pourquoi seul ? Aucune idée cachée : c'est un test. J'ai toujours fait des choses avec les autres. Là, c'est l'exercice de style : est-ce qu'en 2026 on peut faire un vrai SaaS, tout seul ? Oui. Est-ce qu'on peut aller loin ? Oui.
Et moi, avec DeepWorkGraph, je suis sans doute allé plus loin, en aussi peu de temps, que je n'ai jamais réussi à le faire dans toute ma carrière. C'est ça qui est incroyable. Et c'est exactement pour ça que je veux partager la méthode — à d'autres.
5 Pourquoi ça paie
Le modèle posé tôt
Ces partis pris forts ne sont pas de la posture : ils structurent énormément les spécifications. Et surtout, ils rendent possible une bonne pratique décisive : parce que l'objectif du produit était clair et stable, le modèle de données — le modèle technique profond — a pu être posé dès le premier jour. Il collait à un modèle profond de l'application.
C'est, pour moi, un des vrais critères de succès. Le pire, à l'inverse, c'est de bouger en cours de route sur son objectif initial : là, tout part en vrille. On est obligé de changer le modèle, de changer la base de données, et l'édifice se fissure.
Le cadrage n'est pas de la théorie — c'est ce qui rend les « 12 jours » possibles.
Cadrer, ce n'est pas rédiger un cahier des charges. C'est trouver le vrai problème, poser les partis pris qui coupent, et s'y tenir. Le comment — de « ça tourne en local » à « c'est en prod » — est dans le Pilier I.