Bienvenue sur Double Slash, le podcast dédié aux outils et aux techniques pour le développement
web.
Bonjour à tous, bienvenue sur ce nouvel épisode de Double Slash.
Donc comme d'habitude, je suis avec Alex.
Salut Alex.
Salut Patrick, salut tout le monde.
Et nous avons un invité, c'est Sébastien Lorbert et bienvenue.
Salut.
Merci.
Salut.
Merci d'avoir accepté l'invitation.
Merci d'avoir invité aussi.
Avant de commencer, je vous rappelle que nous avons désormais Twitter, Discord,
je ne sais plus.
Vous pouvez aller directement sur le Twitter et vous allez aussi sur tous les épisodes
enregistrés sur YouTube et aussi on fait du live code sur Twitch.
Donc vous pouvez tout suivre.
Je te la ferai à chaque fois.
On a tellement de plateformes aujourd'hui que je ne sais plus.
On est partout.
Sébastien, aujourd'hui, tu es venu nous parler un petit peu de pas mal de choses, notamment
de Nocusouris et de React Tech Dota à newsletter, mais on va te laisser avant de commencer
et te présenter tout ce que tu fais, ou à d'où tu viens, ton background.
D'où je viens, on va dire que j'ai commencé à faire du développement il y a une quinzaine
d'années.
J'ai fait NECO en Genère, après j'ai fait pas mal de Java.
Après, je me suis mis à Scala et j'ai rejoint la start-up en CTO où en fait, j'étais
pas encore front-end, mais je me suis rendu compte que mon équipe avait besoin de moi
sur l'application front-end.
Et du coup, je me suis mis à React en 2014 et puis j'ai pas arrêté depuis.
Aujourd'hui, je ne sais presque plus que ça et je ne fais plus de backend en Scala
ou en Java.
Et depuis 2017, je suis en Freenance et je travaille pour Facebook sur un projet open
source qui s'appelle Docusouris depuis à peu près deux ans.
D'accord.
Et pour ceux qui ne connaissent pas Docusouris, en fait, c'est quoi exactement ?
C'est un générateur de sites statiques qui est basé sur Node.js et React qui permet
de créer des sites de documentation vraiment très simplement.
On peut démarrer en cinq minutes vraiment très rapidement en écrévrant jusqu'à
que fichent et markdown.
Et puis si jamais il y a besoin de faire des sites plus avancés, on a mis en place
des systèmes assez flexibles qui permettent de créer des documentations qui sont quand
même à sa boutique.
Par exemple, le site de React Native ou de Supabase ou même des entreprises comme Figma
vont utiliser Docusouris aujourd'hui pour créer leurs documentations.
Excellent.
Aimit, on parlera peut-être un petit peu plus de Docusouris dans la deuxième partie
de l'émission.
Mais tout à l'heure, on a dit que tu avais une newsletter.
En fait, tu partages ton temps entre Docusouris et cette newsletter ou pas ?
Oui, c'est ça.
En fait, au début, avant de travailler sur Docusouris, j'étais frélande.
C'est ce que je voulais faire, c'était vendre du conseil à des TGM un peu plus élevés.
Donc je me suis dit je vais commencer à créer du contenu et je me suis retrouvé à poster
sur LinkedIn tous les jours.
Après, il y a des gens qui m'ont dit tu devrais créer une newsletter.
J'ai essayé et ça a plutôt bien marché.
Aujourd'hui, j'ai une newsletter avec 12 000 abonnés, dont 3000 en français.
Il s'appelle Reacttabdo.fr.
Ça m'occupe maintenant deux jours par semaine de mon temps.
Je le considère comme un vrai business parce que forcément, à deux jours par semaine,
il faut qu'il y ait quand même un peu de retour sur l'investissement.
Je fais tourner des sponsors et tout ça.
Du coup, j'essaie de cloisonner un peu mon activité entre deux jours par semaine sur
la newsletter en début de semaine et trois jours par semaine sur Docusouris en fin de
semaine.
J'essaie de faire en sorte que ça ne me piète pas trop l'un sur l'autre parce que les deux
activités peuvent être très chronophages.
Si tu leur donnes plus de temps, ça prend plus de temps.
Donc il faut un moment donné fixer des limites et dire voilà, ça doit être fait en deux
jours et trois jours et j'ai pas envie de travailler plus non plus.
Et il existe en deux versions, tu dis en version anglaise et en version française ?
C'est deux newsletter séparés ?
En fait, au début, ce que j'ai fait, c'est que j'ai créé la version française qui
est tournée comme ça pendant un certain temps.
Ensuite, j'ai converti la version française sous forme de fred sur Twitter et ça a plutôt
très bien marché.
J'ai commencé à enregistrer des sign-up sur des anglais qui étaient intéressés pour
que potentiellement je lance une version anglaise.
Et au bout de 500 abonnés en version anglais, je me suis dit, on va traduire.
J'avais un peu peur que ça prenne du temps de traduire, mais en fait, c'est assez rapide.
Bon, moi, je suis pas un anglais natif, mais j'utilise des outils comme Dipe, les Google
Translate pour m'aider un peu.
Et puis de toute façon, je fais sûrement plein d'erreurs, mais les gens, ils s'en foutent,
c'est pas trop le problème.
Le problème, tant que les liens sont bons et que les commentaires arrivent à comprendre,
je pense que ça leur apporte suffisamment de valeur pour que ce soit pertinent.
Et du coup, j'ai commencé à traduire la nouvelle état en anglais, je pense l'année
dernière.
Et aujourd'hui, en anglais, il y a à peu près 8000 ou 9000 abonnés, je crois, en tout
comme ça.
C'est énorme.
Donc, t'as eu beaucoup plus de croissance sur la version anglophone parce que, on va
dire mathématiquement, il y a plus de personnes qui parlent anglais ou qui vont lire des
news en anglais.
C'est aussi l'activité, le trait sur Twitter qui me rapporte beaucoup de visibilité chaque
semaine.
Donc, je pense que ça contribue aussi, mais effectivement, il y a beaucoup plus de gens
qui parlent en anglais.
Il y a aussi des Français qui préfèrent être abonnés en anglais parce qu'en fait, ils
me disent, je préfère les termes en anglais que les termes français.
Alors moi, je les traduis pas.
Je mets beaucoup d'anglicisme parce que bon, je ne suis pas hyper fan de la conversion
entre certains termes anglais et français.
Donc, je ne me gêne pas pour les laisser tel quel.
Mais il y a des Français qui préfèrent vraiment recevoir les news en anglais.
De toute façon, les articles sont majoritairement en anglais.
C'est vraiment le même contenu dans les deux.
Il y a éventuellement quelques trucs en plus sur la version française comme des
affreux d'emploi local ou des sponsors qui sont que pertinents pour les Français ou
alors des quelques liens français de temps en temps.
Il n'y en a pas forcément beaucoup.
Mais globalement, la plupart du contenu est déjà en anglais.
Donc, de toute façon, les gens qui parlent pas anglais ont du mal à suivre
l'actualité réacte de manière générale.
Ouais, c'est clair.
OK. Moi, je suis personnellement abonné depuis un moment.
T'as un newsletter.
Donc, je sais que tu parles principalement de réacte, mais est-ce que c'est
toujours principalement tourné sur réacte ou tu commences à te diversifier un
petit peu ?
Bah, en fait, moi, j'ai toujours pris le parti qu'en fait, il faut rester
ouvert d'esprit.
Donc, je mets toujours une section autre à la fin de la newsletter parce que
déjà, il y a des nouvelles qui sont pertinentes pour un développeur
réacte, mais qui ne sont pas forcément liées à Recte directement, par exemple,
tout ce qui est bundler, Txtrip et tout ça.
Et puis ensuite, même, moi, j'aime bien suivre aussi les newsletter qui
font, je ne sais pas, qui parlent de Jetpack Compose, SwiftUI, Flutter et tout
ça, pour savoir un peu ce qui se passe, par exemple, dans l'écosystème
mobile.
Esprit Ragnatif reste toujours une solution pertinente pour faire du cross
plateforme, des choses comme ça.
C'est important de le savoir, même si,
enfin, s'il y a par exemple des innovations intéressantes dans d'autres
écosystèmes, je trouve que c'est important de le savoir.
Moi, personnellement, j'ai créé une newsletter réacte, mais si demain, il y a
quelque chose qui me plaît plus que Recte, je ne vais pas rester sur Recte
par dogmatisme et puis, puis me dire, bah voilà, je vais faire cette
techno pendant 20 ans parce que, parce que voilà, enfin, pour moi, ça n'a pas
de sens, quoi.
À un moment donné, il faut savoir évoluer et considérer les alternatives.
Qu'est-ce que c'est super clair après passer d'une techno à l'autre, peut-être
que tu refras une autre newsletter.
Je sais pas si demain, après, est-ce que tu penses que tu pourras migrer
ta communauté ou les personnes qui te suivent sur d'autres techno, si on
voit qu'il y a une appétence divergente ?
Je pense que oui, parce que de toute façon, je pense qu'il y a des tendances dans
l'industrie qui sont suivies par pas que, pas que moi, si par exemple, je décide,
je sais pas sur le web, il y a Quick qui fait pas mal parler de lui en ce moment et
qui a des idées nouvelles, c'est pas impossible que dans cinq ans, le truc soit,
soit beaucoup plus gros.
Je me dis si jamais moi, je migre progressivement à Quick, vers Quick,
peut-être qu'il faudrait que j'élargisse un peu le scope de manu de l'Etat pour faire
rentrer d'autres outils et parler plus simplement du frontaine dans le général
plutôt que de juste réacte.
Après, ça me choque point d'outen se faire.
On peut commencer sur une niche de newsletter et puis ensuite élarger en
fonction du besoin.
Je pense que c'est plus facile de commencer par une niche parce que aujourd'hui,
si je commençais par créer une newsletter qui parle de un peu de tout et de rien et de,
et de à la fois du JavaScript et puis après du SQL et puis après du système
embarqué ou je sais pas quoi, c'est un peu difficile de convaincre des lecteurs
de me suivre sachant qu'à chaque fois, il y a des mails que j'envoie qui sont pas
pertinents pour certains lecteurs.
Donc tu restes quand même niché et tu penses que c'est plus facile d'être
niché.
Après, je pense que c'est aussi, enfin ton audience, une fois que tu l'as acquise,
c'est plus facile de faire en sorte qu'ils te suivent dans ta transition.
Je crois même qu'on a quand même quelques exemples, enfin, pas forcément en
France, mais par exemple, je crois qu'en CIDOT, ils faisaient beaucoup du
angulaire avant et ils étaient un peu connus dans ce domaine-là et puis ils
ont réussi à faire un transitionner correctement côté réacte et aujourd'hui,
je pense pas qu'ils font encore du angulaire.
Non.
En tout cas, il y a des gens comme ça qui font des transitions dans l'écosystème
à l'autre et pour autant, ça n'en pense pas que, bah, si ils avaient déjà une
audience avant qui avait un intérêt, il y avait peut-être déjà, dans leur
audience, des gens qui avaient déjà fait leur transition eux-mêmes, donc ils sont
plutôt contents justement de voir que la personne qui suit depuis des années
suit cette même mouvance.
Après, c'est peut-être parce que tous les développeurs angulars sont
pas sur réacte.
Bon après, je ne peux pas bâcher.
En France, je pense qu'il y a encore beaucoup de gens qui font du angulaire en
France.
J'ai l'impression que c'est un peu entier un peu en retard sur cette transition.
Après, on voit aussi le marché.
On le voit au niveau des frameworks qui sont de plus en plus frameworks
agnostiques.
En fait, maintenant, on peut utiliser des petits techno sur des générateurs
de si statiques.
Donc peut-être qu'il faudra suivre un peu la tendance aussi dans le futur.

Et est-ce qu'aujourd'hui, tu as des retours sur tes auditeurs?
Est-ce que c'est plutôt des frilances ?
Des gens qui sont en entreprise, des gens qui ont un niveau plutôt débutant,
advanced.
Est-ce que tu arrives comme à avoir un peu de ce type de métrique?
En fait, je n'ai pas fait de fondage.
Après, moi, j'ai un peu la mauvaise manie de regarder vraiment tous les emails qui
signent up.
Donc je vois les membres des entreprises et des fois, je vois des emails connus et
puis je me dis que c'est chouette à lui et s'abonner.
Je pense que j'ai une audience assez variée dans le sens où
je vais avoir des gens qui sont vraiment très qualifiés, des mecs qui sont
engineering manager chez Airbnb ou chez Facebook.
Mais à côté, je veux aussi avoir des gens qui ont des profils, qui sont beaucoup
plus juniors, qui vont par exemple, il y a des bootcamp en France, par exemple,
qui vont dire à leur...
Allumni.
Oui, à leur Allumni de s'inscrire à Manus Lether en fin de parcours pour suivre
l'actualité et continuer à se former régulièrement.
Donc ça, c'est des profils qui sont un peu moins, enfin, un peu plus juniors.
Et on va dire que certains vont avoir du mal à suivre Manus Lether au début.
C'est déjà arrivé que par exemple, qu'il y a un junior qui me dise,
bah au début, je ne comprenais rien.
Et puis maintenant, sauvage commence à comprendre.
Ça fait un an que je lui ai dit que je n'ai pas mis les Lether.
Bah du coup, ça me fait plaisir parce que je me dis, voilà, c'est pas
adressé pour eux à la base.
C'est plus pour un profil de gens qui connaissent déjà React.
Mais il y a quand même des gens qui s'accrochent et qui arrivent à suivre
malgré le fait d'être junior et de...
et de monter en compétences progressivement en fonction des articles
que tu lis.
Mais bon, c'est une bonne chose d'avoir quelqu'un qui filtre un peu les articles
en amour.
Pour leur dire, bah voilà, ça, il y a quelqu'un qui peut te garantir
que c'est pas...
L'article ne raconte pas trop de conneries parce que...
Faut quand même pas se le cacher.
Il y a quand même...
Si tu regardes sur Medium et que tu fais que ta veille sur Medium, par exemple,
ou sur DevTool, les choses comme ça.
Non.
Bon, il y a beaucoup de conneries.
C'est toujours des tutoriels où en fait, tu comprends pas trop pourquoi.
Alors peut-être que le mec, ce qu'il fait, si tu fais exactement
la même état que lui, ça marche.
Mais tu sais pas pourquoi il les a faites
ni pourquoi il a fait ses choix techno.
C'est juste vraiment des tutoriels à dérouler par rapport...
Ça marche pour certains figures, mais c'est pas...
Pour moi, c'est pas comme ça qu'on montre vraiment en compétences.
Ouais, il y a beaucoup d'articles.
On s'ature beaucoup de...
Tu vois, à un moment donné, il faut arrêter avec le Hello World.
Mais OK.
Top.
Alors sans dévoiler tous tes chiffres.
Aujourd'hui, tu as une base, une audience qui est assez conséquente.
Tu es dédié deux jours par semaine.
Est-ce que tu arrives à tirer quand même de l'argent de cette activité
là qui te prend beaucoup de temps ou ça reste encore sur des équilibres précaires ?
Toutes mes chiffres sont publiques.
Indy Hacker qui détaille vraiment,
moi par mois, le reporting de tout ce que je fais.
Donc, si je veux, il y en a qui s'intéresse un peu plus à comment on fait
pour monter une newsletter tech et la rendre petit à petit profitable.
J'essaie de dévoiler un peu tous les dessous du truc.
Quoi donc...
Excellent.
On mettra les liens.
Super.
À partager ça.
Pour donner une idée, au début, ça ne prenait pas de jour par semaine.
Donc, c'était aussi moins qu'à l'île.
Je faisais peut-être en une demi-journée, j'arrivais à envoyer un truc où en fait,
je faisais vraiment au tout début, en fait,
je faisais cinq postes sur LinkedIn par semaine
et puis ensuite, j'envoyais un mail avec les cinq postes par semaine.
Alors, les postes étaient quand même assez intéressants,
mais par contre, il fallait cliquer sur les liens.
Donc au final, dans le mail, il n'y avait pas grand-chose intéressant.
Aujourd'hui, je suis parti sur une approche un peu plus électoriale où je me dis
voilà, le but, c'est qu'en fait, les lecteurs puissent savoir vraiment
avoir un aperçu de l'actualité sans avoir à ouvrir 15 liens et avoir à lire
plein de trucs parce que je mets quand même beaucoup de liens dans les
menus de l'éteur et si je ne peux pas demander aux gens de cliquer
sur tous les liens, ce n'est pas possible.
Par contre, c'est bien de savoir qu'en fait, il y a telle chose qui s'est passée
sans avoir à cliquer le lien.
Tu sais que voilà, si jamais tu as besoin de retrouver le lien, tu ferais une recherche
plus tard dans tes emails et puis tu le retrouveras.
Il y aura au moment où c'est parti, non, mais au moins,
tu as une idée de quelque chose qui s'est passé dans l'écosystème
intéressant.
Donc j'essaye vraiment d'apporter la valeur directement dans l'email et de
pas forcément maximiser, on va dire, le nombre politique certain.
J'ai commencé aussi à créer des articles complets.
J'en ai écrit un pour l'instant, ce n'est pas beaucoup.
Mais pour moi, l'idée, c'est par exemple de dire voilà, je vais essayer
d'écrire un article qui est assez intéressant, éventuellement un peu
interactif et relativement court et de l'envoyer aussi par email.
Comme ça, les gens, en fait, pourront directement lire l'article dans l'email.
Donc il y a des problématiques un peu intéressantes à résoudre,
comme si par exemple, tu utilises une techno comme MDX qui permet d'utiliser
du réact dans du Markburn.
Comment tu convertis ça pour un email?
Bon, moi, je fais des gifs, par exemple, j'avais fait des gifs sur un email
et ça se convertissait pas mal.
Et il y a aussi, par exemple, comment tu fais pour envoyer des codeblocks?
Est-ce que tu fais une image?
Est-ce que tu essaies de faire une sorte que ton
ton run d'erreur de Saint-Axellating, il soit compatible avec le Markup email?
C'est pas évident.
Moi, j'ai réussi à faire un petit truc qui marche à peu près, mais je suis pas hyper
satisfait encore.
Mais en tout cas, c'est quelque chose que j'aimerais faire, c'est de dire,
bah voilà, j'aimerais envoyer des codeblocks dans l'email qui ont une belle
gueule et puis qu'on peut copier, coller et tout ça.
OK.
Bon, on mettra tous les liens de toute façon de ta newsletter, de ta page Indie Hacker
pour aller voir tous ces liens.
Donc, super.
À limite, je te propose qu'on bascule sur la deuxième partie,
où tu structures ta semaine en deux parties, ta newsletter et docusorus.
Peut-être revenir dessus, parce que c'est quand même un projet assez conséquent.
Aujourd'hui, on est à fond, il y a toute une effervescence sur le statique,
sur la génération de sites statiques.
Alors, c'est venu et rentré par les sites de documentation.
Maintenant, on voit que ça s'étend encore plus sur des sites, on va dire, plus éditoriales.
Et on arrive aussi à un mix entre les sites statiques, semi-statiques avec les Island et tout ça.
Mais en tout cas, toi, tu bosses sur docusorus, qui est full statique.
Est-ce que tu peux nous parler peut-être un peu de la jeunesse du projet,
comment t'es arrivé sur ce projet-là, l'histoire derrière ?
Alors, moi, je n'étais pas à la jeunesse du projet,
donc je ne pourrais pas trop vraiment dire dans les détails, mais dans les grandes lignes.
C'est Facebook, ils ont plein de projets techniques,
aussi bien interne qu'externe, en fait, on ne voit pas forcément,
mais il y a plein de projets en interne aussi qui ne sont pas open source et que eux, ils doivent gérer.
En fait, ils ont besoin de créer plein de sites de documentation,
mais ils n'ont pas envie d'avoir de créer un nouveau site complet de zéro à chaque fois.
Donc ça, c'est des problématiques qu'ils devaient avoir autour de 2015-2016.
Ils ont commencé à copier-coller un template Jekyll pour chaque projet.
Donc ça, ça marchait pas mal dans le sens où en fait,
il y avait une équipe qui développait le template Jekyll,
mais ce n'était pas très maintenable sur le long terme,
parce qu'en fait, si tu upgrade ton template Jekyll, tu rajoutes des features,
après, il faut réussir à intégrer ces nouvelles features dans tous les projets
qui ont déjà été initialisés.
Moi, je n'étais pas là à cette époque-là,
mais j'imagine que c'est un peu compliqué à gérer sur le long terme
d'avoir tous ces projets qui divergent dans le temps.
Donc l'idée de Docusaurus, c'est vraiment de faire un autre type de documentation
qui permet de mutualiser, on va dire, l'outil,
de s'assurer qu'en fait, quand tu upgrade l'outil,
tu bénéficies de nouvelles features et tout ça.
Donc, tu n'as pas besoin de merger les nouvelles features du template upstream
dans ta doc finale pour en bénéficier, ça se fait automatiquement en upgradeant.
Donc voilà, ils ont essayé de créer un projet sur lequel tu peux
en fait te concentrer vraiment sur le contenu.
Donc en gros, tu as un repo avec quelques fichiers Markdown.
Tu lances un outil en ligne de commande de Docusaurus,
et derrière, ça te génère un site statique,
et puis tu peux le deployer sur l'e-top page ou sur un autre hébergeur statique.
Par contre, c'est vraiment la base, c'est quand même du Markdown.
Donc c'est vraiment orienté documentation.
Donc le cœur et tout le contenu va être généré et géré en Markdown.
C'était vrai à l'époque où en fait, c'était que sûr du Markdown.
Aujourd'hui, c'est moins vrai, en fait,
Docusaurus, on le vend toujours comme un outil de documentation,
parce que bon, c'est produit des raisons marketing.
Mais en vrai, c'est un peu un outil générique comme Gatsby.
Imagine Gatsby mais sans la couche GraphQL, c'est Docusaurus.
Donc ça présente quelques challenges,
parce que par exemple, si tu ne veux pas avoir la couche data de Gatsby en GraphQL,
ça présente quelques challenges dans Docusaurus.
Par exemple, si tu as fiché les trois blog posts les plus populaires
sur ta page d'accueil en Docusaurus,
il va falloir recoder des trucs,
parce qu'en fait, on ne peut pas dire sur la page d'accueil du site Docusaurus.
Je veux les trois blog posts qui commencent par les lettres A, tout ça.
Donc ça, c'est des choses que tu vois qu'on ne peut pas faire.
Mais globalement, en fait, c'est une architecture qui est assez inspirée de Gatsby.
Mais qui a été simplifiée.
Mais en haut, tu peux créer toi-même tes propres plugins
et puis faire des choses qui vont lire des fichiers Yamel
si tu as envie ou une source de données externes ou n'importe quoi.
OK.
Et quelqu'un qui veut monter un site de Doc,
par contre, il a des compétences un peu limitées en React.
Est-ce qu'il y a quand même possibilité d'utiliser Docu
pour justement, enfin, Docusaurus, pour justement générer son site
ou le passage est obligatoire pour React ou...
Non, vraiment, à la base, Docusaurus,
c'est tu peux créer ton site de documentation avec juste du markdown
et un peu de config.
En fait, déjà, tu as défiché markdown pour la documentation
et tu peux potentiellement, nous, quand on initialise un nouveau site
de Docusaurus, on crée une learning page qui est codée en React
parce que c'est plus flexible.
Mais si tu as envie, tu peux créer un fichier index.ind dans le dossier
pages de Docusaurus et ça te crée ta learning page en markdown.
Donc, tu n'as pas besoin, en fait, de faire du React du tout.
Tu peux juste avoir que défiché markdown.
Par contre, c'est quand même un générateur de sites statiques
basés sur notre JS et React.
Donc, il faut que tu saches faire un NPM install.
Il faut que tu saches envoyer des fichiers statiques sur le guide de pages
ou sur un hébergeur.
Donc, ce n'est pas forcément à la portée de ta grand-mère,
mais c'est pas hyper compliqué.
C'est un développeur node, il n'a pas de souci.
Et un développeur, je pense, dans notre écosystème
qui est capable de faire quelque commande en adresse,
il n'aura pas de souci, il n'a pas de souci.
Il n'a pas de souci.
On est plus dans la philosophie de J.K.
où vraiment, tu n'étais pas obligé de faire à part du texte.
Tu avais pas besoin que Gatsby ou Gatsby,
tu es quand même un peu obligé de faire du React dans l'ensemble.
Oui, oui, je ne sais pas.
Il doit sûrement avoir des plugins pour s'intégrer avec McDonne,
mais c'est pas le...
Enfin, l'enfer de gens ne l'utilise pas de cette manière-là.
Et aujourd'hui, il y a beaucoup de personnes qui utilisent de Cuseruse.
C'est ce que vous avez, ce genre d'information
de remonter des grosses boîtes qui utilisent ça.
Oui, oui, oui.
Enfin, moi, je suis au courant.
Officiellement, il n'y a pas de documentation qui va dire
oui, il y a telle entreprise qui utilise ça ou qui utilise ça.
Mais moi, je vois bien, par rapport au retour sur Twitter,
aux gens qui posent des questions sur GitHub et tout ça,
que l'outil, il commence à vraiment être pas mal utilisé.
Sur les NPM Downloads, on est à presque la moitié de Gatsby.
C'est quand même...
Enfin, toi, pour un projet qui est un peu niche,
ça te fait...
C'est quand même assez impressionnant.
Après, les downloads NPM, ce n'est pas forcément très...
Oui, c'est pas grave.
C'est pas tant qu'il ne s'y fume plus, mais bon.
Mais bon, par exemple, quand tu regardes les projets techniques
un peu réactes de Shopify,
il y en a plein qui sont de Cuseruse.
Je sais qu'il y a 200 sites de Cuseruse chez Microsoft.
Il y a SAP, IBM, des plainte boîtes.
Des petites boîtes, quoi.
Pas que des petites boîtes.
Il y a un peu de tout.
C'est théorique.
C'est vraiment...
Il y a Snapchat, Figma, Superbase, Ionic.
Enfin, bref, tu vois, il y a pas mal de...
Il y a un peu de tout.
Il y a pas mal de projets Indie Hacker.
Il y a aussi pas mal de projets qui sont beaucoup plus simples.
Tu vois, par exemple...
Ce qui est bien avec de Cuseruse, c'est que tu peux vraiment partir simple,
avoir ton site qui est en ligne tout de suite en sa ménuée climite,
mais qui sera un peu moche,
enfin, qui se refondreraurent tous, comme le template de base.
Mais par contre, tu peux vraiment le customiser
pour aller vraiment beaucoup plus loin.
Et on a mis en place des systèmes
qui permettent d'override un peu n'importe quel composant
réacte du thème par tes propres composants.
Donc, tu peux au final, à terme, remplacer n'importe quel composant par les tiens,
écrire des nafs, des barraux, des footers sur mesure
qui correspondent un peu à ce que tu as sur ton site marketing principal.
Comme ça, la transition, ça se voit pas, quoi.
Il y a pas mal d'entreprises qui font ça
pour justement que le footer soit exactement pareil sur les deux sites.
Du coup, quand tu passes de ta home page à ton site de doc,
on ne sait pas que tu as fait une transition à part si tu as un peu le haï.
Tu vois que ce n'est pas une transition single-page application,
tu ne sauras pas, quoi.
OK.
Et si, on parlait de Gatby,
mais ce n'est pas vraiment un système pour faire des documentations,
quels sont les autres concurrents, on va dire, entre guillemets,
de docusorus pour faire de la documentation
et tout l'engagement que l'on fait?
Alors, il y a des concurrents qui sont plus ou moins directs, je pense.
Dans le...
Je pense que l'outil aujourd'hui le plus populaire qui est proche de docusorus,
c'est N4x dans l'écosystème Python,
qui a un peu une philosophie similaire,
dans le sens où on fait que tu écris les fichiers marques d'un,
et puis tu as une ligne de commande Python,
et puis ça te build un site statique.
Maintenant, on a aussi d'autres projets qui sont comme...
l'écosystème vu, tu as vu presse et vite presse
qui sont un peu similaire de docusorus.
Ils ont un peu moins de features,
mais ils ont certains avantages de, par exemple,
vite presse d'être survite,
qui est peut-être une archéthéctique un peu plus moderne.
Par contre, ils sont un peu plus limités sur les features.
Et c'est survu aussi, donc si tu fais du réact,
tu as peut-être pas envie de faire du vue pour ta doc, ça dépend.
Genre, les devs au piton, ils aiment bien Mkdocs,
les devs réact, ils aiment bien de plus de russe.
Ouais, ça reste assez niché, quoi.
Je veux rester dans mon langage pour éviter de réapprendre
un langage ou...
Parce qu'à un moment donné, il y a toujours cette nécessité
de faire un petit peu du custom,
de devenir un peu modifié des choses.
Tu peux peut-être avoir un design système
qui n'est que dans une techno aussi,
que tu as envie de l'utiliser.
Si tu veux documenter ta livrairie graphique,
c'est mieux si ça s'intègre bien,
tu vois que tu n'es pas besoin de rendre l'air des composants réact
dans ta doc vue ou des choses comme ça,
c'est un peu ouvert-biel.
Donc oui, je pense qu'il y a un intérêt
de rester sur la technocrométrise de manière générale.
Et puis, docus de russe,
globalement, à plus de features que les autres, je pense.
Parce qu'il y a de part l'historique,
de part en fait, un peu plus longtemps,
parce qu'il y a eu plus de demandes.
Ça fait un moment qu'on travaille dessus,
et puis globalement, le projet est plus ancien
que Ville-Cresse, par exemple.
Et puis, après, je t'avoue que je ne sais pas trop comment ça se fait.
Mais en tout cas, c'est les retours que j'ai,
c'est que globalement, il y a certaines choses
qu'on ne peut faire depuis les russes
qu'on ne peut pas aujourd'hui faire avec les autres.
Ce qui est à la fois un avantage et un inconvénient,
parce qu'il y a certains projets qui ont envie de dire,
moi, je n'ai pas envie que mon outil soit trop complexe,
donc des fois avoir moins de features,
ça permet de simplifier l'usage.
Donc c'est à double tranchée de toute façon,
il en faut pour tout le monde.
Et c'est super intéressant ce que tu dis,
parce que là, on est sur un projet qui est totalement open source.
On est d'accord ?
Et justement, comment toi, tu vas prioriser les actions,
quelle feature ?
Parce que là, on parle un petit peu plus de gestion open source,
mais est-ce que tu vas te mettre des focus sur,
d'abord les issues, les features court-termes, les fixes,
comment tu écris ta roadmap et vous travaillez sur la roadmap ?
La roadmap, on va dire qu'on se fait à peu près dans les grandes lignes
ce qu'on veut faire.
Après, moi, j'essaie de prioriser essentiellement
ce qui me semble va apporter un retour sur un investissement relativement important.
Enfin, il n'y a pas des ressources énormes non plus sur ce projet-là,
donc le but, ce n'est pas d'essayer de prioriser
ce qui peut avoir un impact au plus vite.
Après, je tabouque, il n'y a pas forcément une gestion très avancée de la roadmap.
Donc, ça peut presque qu'on veut faire dans les trois prochains mois.
C'est dans notre tête.
Après, il faut arbitrer entre le support et la gestion des issues,
et c'est sûr que les poudres request soient bien mergées.
Et en même temps, avancer sur les grandes lignes du projet,
ce n'est pas toujours évident.
Moi, je travaille trois jours par semaine dessus.
Donc, généralement, quand je reprends sur de plus aux Russes,
ce que je fais, c'est que je dépile les notifications la première journée.
J'essaie de balancer tout ce qui est facile à traiter tout de suite.
Comme ça, après, je conserve que les éléments qui sont un peu plus complexes.
J'essaie d'en traiter certains.
J'essaie de merger quelques peu les requests.
Et puis, j'essaie au moins de me garder une journée
pour avancer sur les problématiques de fonds
pour qu'il y ait du proprès sur...
Parce que sinon, je ne peux faire que du support.
C'est ça le...
La problématique, c'est qu'il ne faut pas tomber dans le piège de dire
« Je vais répondre absolument tout. »
C'est un peu mon problème.
C'est que j'ai tendance à ne pas aimer des...
Il y a une issue où il y a personne qui a répondu,
il y a un mec qui a un problème, ça a l'air légitime.
C'est difficile de dire « Non, ce mec-là, je ne vais pas lui répondre. »
Parce que si je lui réponds, je n'avance pas sur des trucs de fonds.
Et du coup, si je n'avance pas sur des trucs de fonds,
il y a un autre mec qui va vous donner un issue,
qui va me dire « Tu n'as pas avancé sur ce truc-là, on ne peut pas le faire. »
Du coup, au final, il travaille sa cumule.
Donc, c'est important de faire un peu les deux.
Il faut arbitrer entre débloquer les utilisateurs
pour qu'ils aient une alternative tout de suite,
mais en même temps avancer sur le truc qui permet de faire en sorte
qu'il n'y ait pas besoin de l'alternative et qu'il y ait un support officiel
pour faire ce qu'ils ont besoin.
Et tu parles de pull request.
Vous avez beaucoup de contributeurs sur le projet ?
Autre, de l'extérieur.
Oui.
Je ne sais pas ce que c'est beaucoup,
mais on a régulièrement des pull requests.
Je pense qu'on en a peut-être 5 ou 6 par semaine qui s'ouvrent.
Mais quand même.
On va faire des contributeurs externes.
Et tant de mers à peu près combien par semaine ?
Tu sais ?
Oui, à peu près pareil.
Franchement, ça dépend vraiment des semaines.
Les pull requests sont plus compliqués que d'autres.
Donc, forcément, c'est pas évident.
Et le fait d'avoir, excuse-moi de te couper,
mais le fait d'avoir en fait d'Ocusorius qui est implémenté dans plein de boîtes
et des grosses boîtes, est-ce que ces grosses acteurs qui utilisent cet outil
sont un peu dans le money back ?
C'est-à-dire est-ce qu'ils détachent du temps de leur développeur
pour venir aussi contribuer à ce projet-là ?
Ou pas trop ?
Pas trop.
Ok.
Pas trop.
Maintenant, après, on a un open collective avec, je crois,
il y a Temporal qui nous verse 200 euros par mois.
Mais je crois que c'est le plus gros montant.
Donc, c'est un projet qui est financé plus par Facebook.
Tu peux avoir quelques gens dans certaines entreprises
qui vont contribuer de temps en temps.
Comme par exemple, je crois qu'il y a un dev chez OnePassword
qui nous a ouvert quelques pull requests.
C'est assez intéressant, tu vois, récemment.
Mais c'est vrai que globalement,
il n'y a pas forcément de support des autres entreprises.
Et après, c'est aussi le tort de Facebook.
Moi, je l'aurais déjà dit, mais je ne sais pas.
Tu pourras très bien aller voir Netlify ou Bercel et puis leur dire,
ben, je ne sais pas, on fait un partenariat,
on va financer un peu le projet, on vous met en avant pour que ce soit la solution.
Tu vas recommander pour déployer un type de Cusorius.
Ils ne sont pas trop intéressés par ce côté-là.
Est-ce que c'est parce que sur ce projet-là,
en fait, il y a Facebook derrière,
si c'était un projet peut-être open source avec un mec dans son garage,
peut-être qu'il financerait plus facilement.
Le fait qu'il y ait Facebook, il se dit que c'est bon, ils ont du fric, pas besoin.
Je pense aussi qu'il y a ce côté-là,
il y a tous les gens qui disent toujours,
ouais, c'est un projet Facebook, mais je ne comprends pas.
Vous pouvez rajouter trois nouveaux développeurs dessus,
ça irait plus vite.
Tu regardes l'équipe React,
nous on aime toute petite équipe,
tu regardes l'équipe React ou React Native,
ils sont tous moins de 10,
c'est pas pour un projet de cet ampleur-là,
les gens, ils s'imaginent qu'il y a toujours 100 personnes dessus.
Alors que c'est pas le cas,
et puis de toute façon, même s'il y avait 100 personnes,
ça n'avancerait pas forcément plus vite,
parce que c'est pas toujours en mettant plus de moyens qu'on avance plus.
Après, je pense qu'effectivement,
avoir quelqu'un en plus sur Cusorius,
qui allégerait un peu la partie support,
ça pourrait aider pour se concentrer un peu plus
sur les problématiques de fond.
D'accord.
Après, il y a toujours,
on l'a vu sur d'autres projets avec d'autres invités,
temps en temps, il y a des gens qui participent au projet Open Source.
Activement, il y a un moment donné,
ils sont intégrés souvent dans les boîtes,
comme Microsoft, tout ça, pour travailler à plein temps sur le projet.
Donc on peut encourager les gens à aller justement
faire du support sur les Open Source,
pour un jour travailler pour la boîte qui finance le truc.

Ce qui est assez...
Nous, on a deux contrées du Torextein qui sont assez actifs,
qui en soi pourraient potentiellement être employés par Facebook un jour.
Il y en a un qui en réussit, c'est un peu compliqué pour lui en ce moment.
Je crois qu'il y a une maladie chronique
qui fait que des fois, il y a des périodes où en fait,
il disparaît pendant un mois et on n'attend plus par les deux.
Et là, en ce moment, la frontière entre la Russie et l'Ukraine,
c'est un peu tendu, je pense.
Et puis même Facebook, on peut y avoir un développeur remote en Russie.
Il y a toute une histoire de politique derrière,
que je pense que ça ne passe pas.
Compliqué quoi.
Et puis, on a un autre gros contributeur qui est en Chine.
Enfin, qui est en Chine et aujourd'hui,
c'est un étudiant aux États-Unis aujourd'hui,
mais qui est de Chine.
Et du coup, il a ses études encore pendant un certain nombre d'années.
Donc voilà, c'est pas forcément...
Il y a un peu de tout dans les profils,
mais c'est vrai que pour l'instant, les contributeurs les plus actifs,
c'est des gens qui ne peuvent pas forcément être recroutés à court terme,
en tout cas par Facebook.
OK.
Et dédié plus que nécessaire.
Bien clair.
Et est-ce que toi, à titre personnel,
en fait, le fait de bosser sur un projet comme ça,
ça t'a fait monter en compétence ?
Qu'est-ce que ça t'a apporté ?
Je pense que en termes de compétences,
ça m'a appris des choses qui sont un peu niches.
J'ai vu comment ça marchait un générateur de sites statiques en réel.
C'est pas du tout pareil que les applications d'entreprises
sur lesquelles la plupart des lèvres travaillent.
Donc c'est intéressant, mais en même temps,
c'est des compétences que j'aurais du mal à porter dans une entreprise
et à vendre...
Enfin...
On dirait quoi ?
Ouais, enfin, tu vois, par exemple, c'est un peu con,
mais tu vois, les gens qui disent « Manus Vector »,
ils disent « Ouais, le mec qui doit te connaître tout de réact,
il a utilisé tout les livres ».
En vrai, ça fait deux ans que je n'ai pas fait de réact natif,
à part des petites applis pour tester.
Ça fait que je m'ai utilisé Rack Query,
ni SWR ou X-Tel, tout ça.
J'ai pas d'expérience pratique sur toutes ces liblettes.
Tu vois, donc...
Aujourd'hui, c'est ce qu'ils utilisent en entreprise.
Decuseruse, c'est un produit qui est vraiment très particulier.
Même la manière de tester le code et tout ça,
c'est pas tout à fait pareil,
parce qu'en fait, le vrai code de deux plusieurs russes,
il n'y a pas de règles de métier, tu vois.
C'est des fichiers statiques,
donc il faut vérifier que les aides sont bien là,
que le prefetting fonctionne et tout.
Donc, ce n'est pas du tout pareil que...
On va dire, les aides d'entreprise, il y a des règles de gestion.
Il faut faire un test unitaire pour...
Ouais, des règles de métier hyper précises.
Voilà.
Là, le...
C'est qu'en fait, voilà, tu as un rendu,
il faut que ce soit joli à des données.
Il faut que le tel composant reçoive telle donnée.
C'est des tests, on va dire, un peu plus techniques que métier.
Et je pense que ce que j'ai eu le plus à prix,
c'est comment on gère un projet open source,
comment on gère la communauté et la communication, le marketing et tout ça.
Ça, c'est des aspects qu'on ne pourra peut-être pas de la même manière d'entreprise.
Enfin, je ne dis pas que la communication d'entreprise, c'est pas important.
Mais sur un projet open source comme ça,
il y a quand même une activité de marketing
qui est importante pour que le projet se développe.
Il faut écrire des blogs post pour que le projet
devienne populaire.
Il faut s'assurer que le support soit bon.
Il faut s'assurer que tu communiques bien quand il y a une nouvelle release
pour qu'en fait, les gens soient au courant.
Enfin, voilà, il y a tout un tas de choses qui font qu'en fait,
qui vont avec le projet dont je m'occupe aussi pour que le projet se développe.
OK.
Ouais, tu as quand même une obligation,
enfin, une obligation, pardon.
Tu as quand même un besoin de communiquer, quand même,
pour communiquer sur le projet,
toutes les évolutions, tout ça pour que les gens qui n'assurent le projet
et soient motivés pour l'utiliser et le faire évoluer.
Ouais, c'est vrai que c'est un aspect qu'on a tendance à oublier
sur l'open source, mais c'est marketing.
Parce qu'aujourd'hui, il y a plein de...
Enfin, tu vois, par exemple, il y a plein de gens qui créent des blogs open source
qui font un GitHub avec un petit rymi.
Bah, le problème, c'est qu'en fait, déjà, le rymi est souvent
il n'est pas forcément très bien fait.
Ça aussi, c'est important.
Et ensuite, les mecs, ils disent,
il y a personne qui utilise ma libre.
Même moi, j'ai changé de contexte dans mon entreprise.
Du coup, je l'abandonne parce que
ni moi, ni personne ne l'utilise.
Donc, ça n'a plus de sens de passer du temps.
Alors qu'au final, tu vas lui dire...
Alors qu'il aurait peut-être tué une communauté.
Parce que potentiellement, le mec, il ne s'est concentré que sur l'implémentation.
Et derrière, il n'y a pas eu de marketing.
Alors qu'en fait, il faut peut-être au moins la moitié de marketing.
Et tu vois, il faut que ce soit bien réparti.
Si tu fais un super truc, mais que tu n'en parles jamais,
la personne ne saura que ça existe.
Ouais, ouais.
C'est un sens que je dis.
Et à l'inverse, le mec qui communique sur un de fou,
mais qui fait un truc tout pété et son produit n'est pas top,
ben ça ne va pas faire non plus.
C'est vraiment le double, c'est que je fais et je communique sur ce que je fais.
Mais je pense qu'on a surtout de manière générale.
Alors, toi, tu n'es pas du tout dans cette règle,
dans la mesure où tu communiques assez facilement.
Mais on voit quand même qu'il y a une grosse tendance sur les développeurs,
ce ne sont pas les meilleurs communicants en termes de marketing,
en termes d'écriture, en termes de création de contenus.
Même s'il y a une tendance qui va vers...
Il y a de plus en plus de personnes qui créent du contenu.
Donc ça, c'est plutôt une bonne chose.
Mais on va dire la typologie classique des développeurs,
ce n'est pas toujours les meilleurs communicants.
Oui, mais je pense que ce n'est pas que les développeurs.
Je pense qu'il y a aussi pas mal de...
Enfin, il y a toujours des développeurs,
mais je veux dire dans les startups et tout ça,
il y a pas mal de boîtes qui se montent aussi
où ils essaient de créer un produit et ils savent pas encore comment le vendre.
Aujourd'hui, c'est assez connu qu'en fait, c'est important.
Il faut investir sur le marketing et ne pas juste penser aux produits,
mais aussi penser à tout l'aspect distribution.
Et une libre open source, même si c'est gratuit, c'est un produit.
Tu dois convaincre les gens que ça vaut le coup
d'investir dans ta livrairie, d'apprendre leur API,
de s'assurer que le truc sera maintenu dans le temps et pas abandonné,
parce qu'une entreprise qui installe une nouvelle livrairie,
derrière, si elle a une dépendance,
potentiellement, c'est mieux peut-être pour elle
de copier et coller le code directement et de l'intégrer comme ça,
que de dépendre du code de quelqu'un qui ne va pas le maintenir.
Bien sûr. Bien sûr.
C'est clair. Ce qu'on a fait dernièrement sur une partie du site,
c'est vu que le code n'était pas maintenu depuis deux ans.
J'ai dit non, je fais copier, coller, ce sera plus simple.
Et surtout, la documentation des projets open source, c'est super important.
C'est pour ça qu'il faut utiliser de l'horiz.
Voilà.
Super. Surtout que ce n'est pas très compliqué.
En plus, c'est ça qui a un peu dommage.
C'est qu'en fait, en cinq minutes, tu as déjà deux, trois fichiers mardins,
tu peux avoir un site en ligne.
Alors, il ne sera pas forcément beau, mais tu vois, au moins,
les gens, ils seront plus contents que de naviguer dans des fichiers.
Oui, la porte d'entrée, la barrière à l'entrée est vraiment minimum.
Donc, en fait, documenter même quatre pages,
mais propres et avoir documenté sa libre open source aussi petite qu'elle soit,
c'est vachement plus facile de le faire correctement avec des outils
type decuserus.
Et c'est même pas juste la documentation.
C'est, tu vois, dans la spring marketing, il n'y a pas d'autre chose comme
rien que le fait d'ajouter une social card à ton projet,
tu vois, sur GitHub.
Quand tu partages un lien GitHub, il faut qu'il y ait une image qui s'applique.
Si tu fais pas ça, tu te prives du marketing.
Tu vois, à chaque fois qu'il y a un mec qui va partager ton lien,
tu vas avoir une prévie de toute pété qui va s'afficher.
Alors que tu pourras avoir une belle image bien designée.
Alors, t'es pas obligé de faire un truc très compliqué.
Il faut juste que les gens comprennent ce que ça attire l'œil.
Bien sûr.
Super conseil.
Super conseil.
Écoute, Sébastien, je crois qu'on a fait le tour un petit peu du sujet.
De toute façon, on reprendra toutes tes coordonnées.
Evidemment, ta newsletter, le lien pour Docuserus,
le site de Doc de Docuserus pour savoir comment utiliser Docuserus.
Et donc, on mettra tous les liens dans la description de l'épisode.
Un grand merci, Sébastien.
Merci à vous de m'avoir invité aussi.
Au plaisir.
Merci.
Et on en fera sûrement un épisode avec toi pour parler de React dans quelques temps,
je pense, parce que lui, il a un expert au niveau de React,
les React Notives.
Et bien, tu reviendras à nous voir, c'est bon ?
Oui, très bien.
Allez, un grand merci à tous.
Merci à toutes d'être restées jusqu'au bout de l'épisode.
Et un grand merci à tout le monde.
Ciao ciao.
Merci ciao.
Salut.
Retrouvez Double Slash sur le plateforme de podcasts préférés.
Et sur le site internet du podcast,
www.slash-podcast.fr.
Sur le site, vous allez retrouver tous les liens d'épisode,
les références évoquées durant l'émission.
Sous-titres réalisés par la communauté d'Amara.org