Bienvenue sur le podcast Artisan Developer, l'émission pour les programmeurs qui veulent
vivre une carrière épanouissante.
Prêts à passer au niveau supérieur ? C'est parti !
Aujourd'hui, je suis avec Julien Delange, Julien Bonjour.
Salut Benoît, ça va ?
Il faut que tu comprennes pourquoi on rigole, ça fait juste deux heures quand tu chates
avec Julien.
Mais voilà, on attaque l'épisode que maintenant avec un immense plaisir.
Je suis ravi de te retrouver Julien.
Tu étais déjà venu sur le podcast et tu avais commencé à nous parler de ta start-up
et je te propose que ce soit un peu le thème de la journée.
Mais avant ça, est-ce que tu peux te présenter un petit peu pour ceux qui ne te connaîtraient
pas ?
Donc, je m'appelle Julien et j'habite aux États-Unis, à Denver dans le Colorado.
Avant, je travaillais chez Twitter en tant que staff engineer.
Avant, j'étais chez Amazon Web Services, Carnegie Mellon.
J'ai aussi fait une thèse à Telecom Paris Tech quand j'habitais en France.
Et aujourd'hui, en fait, il y a un an, je décidais de me lancer dans l'entrepreneuriat
et de démarrer ma start-up, donc Codiga.
Et le but, c'est d'aider les développeurs à produire du mi-aircode.
Donc, ça fait un an.
Là, on a passé pas mal de milestone et j'espère qu'on va avoir l'opportunité d'en discuter.
Bon, moi, ce qui m'intéresse vraiment, c'est tout ton parcours entrepreneuriel.
Alors, je pense que c'est intéressant de mettre un petit peu de contexte, surtout
que le produit va parler aux développeurs.
Je pense que ça peut être intéressant que tu introduises le produit pour qu'on se
fasse une idée de ce que ça fait.
Et après, j'aimerais bien qu'on creuse cette dimension entrepreneurielle.
Quand t'étais venu, on avait pu s'explorer le côté différence culturelle entre les
US et la France.
Ce que je te propose là, c'est qu'on profite du fait que tu as eu un certain parcours,
surtout que tu as dépassé certaines milestones, que tu nous racontes tout ça, que tu nous
racontes les hauts, les bas, les moments joies, les moments plus difficiles et qu'on avance.
Alors, ça fait quoi Codiga ?
Donc, en fait, Codiga, on a commencé comme un produit qui fait du code review, qui fait
de l'automisation de code review.
Donc, tu pousses ton code sur GitHub et puis on flag ce qui va pas.
On a commencé avec ce produit-là et c'est un produit qui est toujours live et qui a
aujourd'hui plus de 14 minutes utilisateurs.
Le but, c'était quoi ? C'était quoi le bénéfice que tu attendais pour le développeur ?
Tu flaggues l'erreur dans la poulre request.
Donc, l'idée, c'est de lever les problèmes le plus en amont possible.
Voilà, exactement.
Donc, la promesse est gagne du temps sur ton cycle de dél, parce qu'on va t'éviter
des merdes que tu n'as pas à te prendre plus tard.
Oui, exactement.
Donc, en général, tu t'envoies une poulre request et puis tu vois que tu as des erreurs,
mais tu as deux problèmes.
D'une, les développeurs dans ton équipe, ils vont mettre une heure à deux heures à te
lever des erreurs.
Et deuxièmement, c'est des humains.
Donc, ils vont aussi oublier, enfin, ils ne vont pas trouver certaines erreurs.
Donc, en fait, là, avoir un processus automatique, ça te permet d'avoir du feedback directement
en moins d'une minute et de deux, d'avoir des erreurs de manière consistante par rapport
au standard et à ce qu'il y a déjà trouvé.
Donc, ça, c'était le premier produit.
En fait, assez rapidement, on a eu du feedback en disant, oui, c'est cool.
Sur les entreprises, elles aiment bien, il y a des utilisateurs.
Mais en fait, le gros problème aujourd'hui, c'est qu'on a besoin d'écrire plus du
logiciel plus rapidement.
En fait, il y a plein de développeurs junior qui arrivent sur le marché et ils ne savent
pas écrire du code.
Donc, comment tu essayes, comment tu facilites l'écriture de code.
Ça, c'est un premier problème.
Le deuxième problème, c'est que tu as plein de gens.
Ils cherchent sur Google pendant 10 minutes, 15 minutes, comment faire un truc.
Alors qu'en fait, le bout de code pour faire le truc, il est très simple.
Donc, tu as des codes snippets qui sont disponibles un peu partout.
Le truc, c'est comment tu peux partager cette librairie de code snippet entre les gens de
ton équipe.
Donc, on s'est réorienté sur un produit où tu peux avoir une librairie de code snippet,
de code block, que tu peux réutiliser dans VS Code ou JetBrains, comme tu veux.
Et tu peux partager ce code snippet.
Donc, il y a une marketplace, tu peux aller sur app.coligas.hub ou code.snippets.dev.
Et tu peux voir la liste des snippets qu'on a.
Donc, en fait, là, on se positionne vraiment sur un produit où les gens, dans leur idea,
ils disent, je veux lire un fichier.
Et on leur propose du code.
Alors après, tu vas me dire, c'est quoi la différence avec Copilot ?
Le truc, c'est que Copilot, il est entraîné sur du code.
Il y a plusieurs aspects d'une copilot qui est entraînée sur du code qui est public
et qui n'est pas forcément sûr.
40% du code généré par Copilot, c'est du code qui est insecure.
Copilot, il écoute aussi le code que les développeurs envoient.
Donc, tu as un problème de privacy aussi.
Et puis, il te garantit pas que le code, tu puisses l'utiliser dans ton projet.
Si ton projet, par exemple, est propriétaire, tu vas mettre du code open source,
tu vas avoir une co-op damnation de la licence.
Et nous, on évite tous ces problèmes-là.
Donc, tu n'as pas tous ces problèmes-là.
Par contre, ce n'est pas AutoMLDriven dans le produit,
mais ce n'est pas autant MLDriven que Copilot.
Par contre, ça te file des bouts de code qui sont sûrs,
que tu puisses copier, qui sont autorisés par l'auteur,
que tu puisses les copier, et qui sont corrects
parce qu'ils ont été vérifiés par la communauté.
Ok, donc ça, c'est le produit aujourd'hui.
Ça donne une bonne situation de la base.
L'idée, là, la promesse, c'est de développer plus vite,
en allant chercher des petits bouts de code.
Au lieu d'écrire ton code octet par octet, tu l'écris par bloc, en fait.
Mais réfléchis un truc.
Aujourd'hui, la manière dont tu écris du code,
c'est que tu as un délégat.
Ça me parle complètement sur les smart contracts que j'écris.
En fait, un smart contract, il y a une spécificité,
c'est quelque chose à très forte densité.
Chaque octet a une très forte valeur ajoutée
par rapport à un code de classe classique limité de table.
Là où un smart contract, tu vas vraiment faire attention.
Si tu suis un peu les exploits qui sont faits,
tu veux dire plutôt le dire en anglais,
parce que ça ne veut pas tout à fait dire la même chose en français,
mais les hacks qui ont été faits,
parfois, tu te retrouves le dernier hack que j'ai vu.
Les mecs qui n'ont pas fait gaffe,
ils ont mis un supérieur au lieu de mettre un supérieur ou égal.
90 millions. 90 millions qui sont partis en fumée.
Donc autant te dire qu'un morceau de code,
un petit bout, tu fais gaffe.
Et moi, je réutilise beaucoup en fait.
Maintenant, j'ai mes propres libérés.
Donc ce que tu me dis, ça me parle.
J'ai mes propres bibliothèques.
J'ai mes propres contrats que j'ai testés, retestés,
validés dans tous les sens.
Et du coup, quand je dois refaire un morceau,
je ne vais pas me prendre la tête à le réécrire.
Je vais aller chercher les 5 à 10 lignes
qui me font dans mon contract que je sais qui marche très bien.
Et j'intègre le test et le code qui va avec.
Et aujourd'hui, tu n'as aucune solution
qui te permet de définir ce truc-là
et de les importer entre différents éditeurs.
Tu as un système de snippet qui marche pour VS Code,
un système de snippet qui marche pour JetBrains,
qui ne sont pas compatibles.
Et nous, on permet vraiment de partager le truc
et de pouvoir les importer sur toutes les plateformes
et de les partager avec ton équipe.
Donc ça, c'est top.
Et je commence à avoir l'utilité.
Tu vois, moi, je suis tout seul.
Je jongle entre mes trucs, ça me bat.
Mais j'imagine que si en plus,
je commençais à construire une équipe
et que je voulais homogénéiser les pratiques,
ça serait top d'avoir ce genre de choses.
Donc ça, c'est cool sur le produit.
Maintenant, si tu nous parles un petit peu
du parcours entrepreneurial.
Alors, c'est quoi les grosses maïstones
que tu as dû franchir durant ces 12 derniers mois ?
Alors, déjà, il y a eu le feedback sur le produit.
Donc comment tu colles avec le feedback
et ce que les joueurs pensent du produit ?
Parce que tu as quand même sacrément shifté
de passer d'une code review à des snippets de code.
Même si de loin, c'est en reste dans une même logique,
en termes de produit, c'est pas tout à fait le même.
C'est ni le même, ni la même promesse.
Ouais.
Et donc, en fait, ça, je vais expliquer.
En fait, d'une, il faut que tu as du feedback sur ton produit.
Ça, c'est le premier truc.
Le deuxième truc, c'est comment tu vas vendre ton produit.
Et en fait, le problème du code review,
c'est qu'en fait, tu vas vendre un produit
ou tu vas lire le code des utilisateurs.
Donc on a commencé à être ce sock to compliant.
On a passé des audits de sécurité et tout.
Mais en fait, il y a un moment,
tu as beaucoup de grosses boîtes.
Ce qu'elles vont vouloir, c'est d'avoir du déploiement on premise.
Donc tu déploies dans l'infrastructure de...
Elles vont pas vouloir te filer leur code.
Mais ouais, mais ça, le problème, c'est que faire ça,
ça va te tuer ta boîte et ton système.
Et ta culture.
Pourquoi ?
En fait, parce qu'en fait, quand tu commences à faire du
développement on premise, donc j'ai écrit un article de blog
complet là-dessus, pourquoi aller on premise ?
C'est une erreur.
Et en fait, au début, j'avais prévu d'aller on premise
et j'ai reçu un email d'un entrepreneur très successful,
enfin, très, très, qui a fait une boîte vraiment très, très utilisée
et qui m'a dit, ne fais pas ça.
C'est une erreur et tu vas et l'icace, enfin, si l'icace article
est tu vas comprendre.
Et en fait, ce qui se passe, c'est que...
Je pourrais être sûr pour qu'on se comprenne bien avec les
auditeurs on premise.
Ça veut dire que tu mets ton serveur qui amène l'intelligence et la
valeur ajoutée chez le client pour que le client et la main, en fait,
sur ce qu'il fait et il te paye une licence.
Au lieu de te payer un abonnement, il t'achète le serveur,
peut-être un peu de maintenance.
Ou marque peut-être que tu dois pouvoir louer mes fins bref.
En tout cas, le code tourne chez ton client.
Et toi, en tant qu'éditeur, tu n'as plus, tu n'as rarement
accès encore au serveur.
Ça veut dire plus de capacité à mettre à jour, plus de capacité
à faire des évolutions, à faire suivre le produit.
Et donc, en fait, ce qui va se passer quand tu vas faire un
produit comme ça, c'est que la manière dont tu vends le produit
va changer, va chifter dramatiquement.
Et oui, tu vas passer par des intégrateurs après.
Tu vas devoir payer un sales.
Tu vas...
Donc, en fait, sur l'article de bloc que j'ai, c'est un truc que je
publie et j'explique les aspects économiques.
Le problème, c'est que si tu passes sur du on-prem, ce que tu
dois faire, c'est contacter les roses boîtes.
Donc, tu vas payer un mec qui va faire du sales.
Donc, ce mec-là, aux États-Unis, il y a au moins 200 000 dollars, plus la
commission.
Tu vas devoir avoir quelqu'un qui va gérer les customer success.
Donc, quelqu'un qui va faire du service après-vente.
Plus, tu vas avoir aussi un ingénieur qui va fixer les bugs.
Parce que tu vas avoir quelqu'un qui va avoir GeekLab version 14,
l'autre qui va avoir GeekLab version 12.
Donc, tu as une différence entre les API et AI.
Oui, mais tout ça, tu l'as aussi si tu es en sales, non?
Non, parce qu'en sales, quand tu es sur GitHub, c'est toujours la même
version. Tu as GitHub.com.
Quand tu es sur GeekLab, tu as GeekLab.com.
D'accord, OK. Là, tu dois gérer l'étérogenéité du parc, là où tu
simplifie la vie en sales avec une seule version.
Voilà. Et donc, d'une salle de deux, à chaque fois, les mecs, ils vont
ils vont ils vont chier dessus avec, par exemple, le déploiement.
Ah oui, là, vous avez mis la mauvaise variable d'environnement pour
déployer ça va prendre deux heures parce que tu n'as pas le
contrôle sur les instances.
Donc, en fait, tu vas passer, tu vas passer beaucoup de temps et tes ressources.
Tes ressources vont être dédiées à faire du sales et du customer
succès. Alors qu'avant, tu étais dédié à faire de l'innovation.
Ce que je trouve super intéressant dans ce que tu décris, c'est que
finalement, un projet, c'est comment est-ce que la dimension business
est mise sur le marché à un impact majeur sur ton produit et qui en arrive
même du coup, ce que je devine en filgrant, c'est à te dire,
ben, si les contraintes business sont trop fortes ou m'amènent dans une
direction qui est toxique et ou étouffante pour la boîte, je préfère
changer de produit en fait.
Ben oui. Aujourd'hui, alors, il y a plusieurs aspects.
Regarde, à la chaîne, ils ont un produit qui s'appelle Bitbucket, qui
on premise. Il l'enlève du marché.
Bitbucket ne va plus aller en premise.
Ils ont décidé à la chaîne, a décidé que non.
Et en fait, c'est alors que c'est un peu des gros atlases,
c'est encore un peu considéré.
Oui, mais pourquoi pas.
Des gros, gros acteurs et les mecs qui disent non, on arrête.
Parce que le futur, il est dans le cloud.
Et qu'en fait, ce qui va aussi se passer, c'est que d'un point de
vue culture, d'un point de vue ingénierie, quand tu vas faire un
produit en premise, à moins que tu aies une très bonne culture de
comment tu développes le produit, comment tu développe des products,
des products, des lignes de produit.
Ce qui va se passer, c'est qu'il y a un moment, ton équipe d'ingénierie,
elle va forquer la version SAS pour faire une version de premise.
Ouais, c'est ça.
Et là, et là, tu vas avoir différentes features, il va falloir
maintenir. Donc en fait, maintenant, tu as plus un produit,
tu as deux produits.
On est à deux bases de code pour le même produit.
Là, ça devient l'enfer de maintenir tout ça.
Je reviens sur mon point d'un point de vue économique.
Un sel, c'est 300 000.
Un customer succès, c'est 100 000 dollars.
Un ingénieur, ça va être 150 000.
Tu vas rapidement dépenser un demi million de dollars pour
développer une version en premise.
Combien de sites tu dois vendre pour arriver un demi million de
dollars ?
Beaucoup, en mon avis.
Donc aujourd'hui, c'est beaucoup plus simple d'avoir un produit
SAS que tu que tu puisses vendre ou tu vas te dédié sur
l'innovation et les gens vont te prendre parce que tu es
innovant.
Et si ton produit est vraiment bien, si ton produit est vraiment
nickel, les boîtes n'auront besoin à un moment et assignauront
en premise ou pas en premise.
Et comment tu fais pour garantir la confidentialité des données
et du code ?
Remarque-toi, tu envoies dans ton nouveau produit, tu envoies dans le
Codiga, tu envoies pas de code.
En fait, tu fais qu'on téléchargeait, non ?
Oui.
D'une, ça, c'est le premier point.
D'une, tu as ça.
Après, tu peux être audité.
Troisièmement, tous ces aspects là.
Est-ce que tu es sécurisé ?
Est-ce que c'est des raisons pour ne pas t'utiliser ?
Je vais donner un exemple.
Il y a dix ans, personne n'aurait mis, personne n'aurait mis la
conversation des entreprises, de leur entreprise dans le cloud.
C'est là qui est arrivé.
Il y a dix ans, aucune entreprise ne dirait, je vais utiliser
GitHub, GitHub.com pour mettre en mon code source.
J'ai des centaines d'entreprises, de grosses entreprises américaines
qui utilisent Codiga pour la code review.
Donc, tu as un changement de mentalité.
Tout ça, ce sont que des raisons.
Et comment tu fais ?
Moi, ce qui m'intéresse vraiment, c'est comment tu gères tout ça
dans le point de vue entrepreneurial, parce que tu as un peu
un espèce d'un morcasse.
Il faut que tu gères ton produit.
À la base, j'imagine, venant de la tech, tu avais une passion
pour le produit.
J'imagine que tu as dû contribuer à le coder.
Et là, maintenant, il faut que tu gères ça, les enjeux de modèles
économiques, lever des fonds, parce que je crois que tu as réussi
à enlever entre temps.
Comment tu gères tout ça ?
Comment tu jongles ?
Tout ça, en fait, il faut que, à la fin, il faut que tu te
dises, en fait, même, regarde, toute ta vie, c'est une allocation
de ressources.
Combien de temps je passe avec mes gamins par jour ?
Combien de temps je passe avec ma femme ?
Combien de temps je passe au boulot ?
Combien de temps j'adore ?
Je sens que ça me plaire ce qu'il fait.
Mais non, mais tu ne fais que tu allouer.
Je suis à fond là-dedans, en ce moment, je suis à fond dans cette
considération.
Je n'aime pas ce que tu manières de voir les choses.
Tu dois allouer tes ressources.
Alors après, je ne dis pas que tu vas le faire de manière
intelligente.
Mais tu dois uniquement allouer correctement tes ressources.
Donc, en fait, il y a un moment, quand tu démarres ta journée,
ce que tu vas te dire, c'est combien de temps je vais dédié à coder,
combien de temps je vais dédié à lever des fonds,
combien de temps je vais dédié à te gérer.
Tu fais des budgets, en fait.
Tu fais un peu des enveloppes de budget temps par activité.
C'est comme ça que tu travailles, toi ?
Oui. En fait, chaque jour, je vais consacrer deux heures à faire
si, j'ai un tableau qui est sur ma gauche ou j'ai exactement ce que
je vais faire.
Après, j'ai aussi embauché.
Et là, le but d'embaucher, c'est de pouvoir déléguer des tâches
que d'autres personnes peuvent faire pour moi.
Parce qu'en fait, il y a des choses que tu dois faire.
Et il y a des choses que tu peux déléguer.
Exemple, et regarde le code.
Si tu vas sur codiga.io aujourd'hui, le site web, c'est en WebGL.
C'est super joli et tout.
Tout ça, c'est pas moi qui le fais.
J'ai un designer maintenant, on est 8 dans la boîte.
Donc, tu es un designer qui le fait ça.
J'ai un frontier ingénieur qui fait ça.
J'ai embauché quelqu'un en qui je crois vraiment qui
habitent en Colombie et qui est devenu le Tech Lead.
Je délègue énormément de travail.
Je code encore un peu.
J'arrive à garder les mains dans le code encore.
Ah oui, je code.
Je dois coder à peu près 3 à 4 heures par jour.
Ah, mais c'est comment ?
Ah putain, c'est génial.
Comment tu fais pour arriver à coder 3 à 4 heures par jour
et faire vite à Star Stop ?
Ça me paraît dingue, ça.
Bah, en général, en fait,
les je me lève en général à 7 heures du matin
entre 6 heures et 7 heures.
Et je finis bosser en général vers 8 heures.
Donc, ça te donne à peu près 12 heures, 13 heures par jour.
12 heures, 13 heures par jour. Non, stop.
Non, non, avec une heure de pause pour aller courir.
En fait, je vais courir.
Et tu manges camp dans l'histoire.
Bah, entre deux, enfin, voilà.
Vraiment, le truc,
mais le truc, c'est que tu vas te donner 4 heures de code.
Après, tu as...
Mais après, c'est sûr que 4 heures sur une journée de 12 heures,
ça paraît tout de suite vachement plus raisonnable
que sur une journée de 7 heures.
Complètement.
Donc, après, ça dépend aussi du contexte.
Parce qu'en fait, quand j'étais en mode fundraising,
là, c'était vraiment chaud, parce qu'en fait, le fundraising,
c'est presque un travail à mitant.
Donc, en fait, à mitant, tu dois...
Je rédis même un travail à temps plein de lever des fonds
et d'aller rencontrer des gens, améliorer le pitch.
Ouais, alors déjà, le problème du lever des fonds...
Après, c'est toujours pareil.
Un temps plein sur un 12 heures,
c'est pas pareil qu'un temps plein sur un 7.
Ouais, c'est vrai, mais en fait, le fundraising,
la manière dont ça s'est passé,
c'est qu'au début,
au début, je parlais à la mauvaise communauté.
Donc, en fait, c'est un peu comme...
C'est un peu comme si un mec du Kentucky voulait
aller draguer les nanas en Californie.
Il y a un problème, ça ne matche pas, ça ne va pas.
Moi, au début, j'ai essayé de lever des fonds dans le Colorado.
Les mecs, ça ne leur parle pas.
Aujourd'hui, quand je suis allé dans le Colorado,
les gens me disaient, je ne vais pas investir dans ta start-up
si tu n'as pas un demi-million de revenus annuel.
Mais mec, si je viens de demi-million de revenus annuel,
j'ai plus besoin de toi, en fait.
On est d'accord.
Donc, pendant deux mois,
je n'avais que des noms de gens
qui étaient dans le Colorado, dans le Montana et compagnie.
Alors, juste pour qu'on se...
Tout le monde ne connaît pas la géographie américaine,
mais l'image que j'ai de ces régions-là,
c'est plutôt des régions assez rurales au sens...
Ouais, c'est ce qu'on appelle le Midwest.
C'est-à-dire que...
Ouais, voilà, c'est ça.
Je garde des souvenirs de la Iowa,
c'est le seul endroit au monde où j'ai vu des champs à perte de vue.
C'est-à-dire, littéralement, tu te mets au bord du champ
jusqu'à la ligne d'horizon, tu vois, du soja et du corn beans.
Voilà.
Et donc, enfin, le Colorado, c'est pas ça parce que tu as le montagne,
mais tu n'as pas une culture de risque.
Et en fait, il y a un moment, ce que je me suis risqué...
De risque ou de tech ?
De tech, mais même de prendre des risques.
Même de prendre des risques.
Je vais donner un exemple.
Donc, j'étais dans le Colorado...
A simile de la start-up américaine,
c'est quand même plus sur les côtes,
c'est plus sur les côtes, quoi.
Ben ouais.
STS et STV.
Donc, au bout de deux mois, j'avais levé...
Alors déjà, quand tu lèves du pognon,
les gens qui vont investir dans toi,
c'est les gens qui te connaissent parce qu'ils croient avant toi.
Ils ne croient pas au produit, ils ne s'en foutent, ils ne savent pas.
Ils s'en foutent, ils regardent,
toi qui tu es comme individuel.
Et les gens qui vont investir, c'est des gens qui ressemblent à toi.
C'est triste à dire,
mais moi, mon premier investisseur, c'est un Français
qui m'a suivi depuis deux ans.
Après, en fait...
Il a bossé chez Twitter et qui habite en Californie.
Non, non, non, il ne bosse pas.
Non, non, il a un réseau d'Angel, San Francisco.
Mais en fait, j'avais levé très peu de pognon.
Au bout de deux mois, j'ai pris ma voiture,
je suis à la San Francisco,
et là, j'ai commencé à avoir des meetings
où littéralement, tu t'assis à Palo Alto, dans un café.
Tu donnes ton idée.
Une heure après, le mec, ton main d'email, il dit,
ok, je mets 40 m, ok, je mets 100 m.
Juste sur l'idée.
Donc en fait, la culture, la culture est complètement différente.
Et très rapidement,
et en fait, ce qui est marrant dans...
Alors, je ne sais pas si tu voulais parler de fundraising,
mais en fait, quand tu...
On était sur la dimension entrepreneur,
elle, c'est un volet qui est hyper intéressant,
malgré tout.
Ce que je trouve intéressant, c'est comment
est-ce qu'on changeant de contexte,
finalement, même aux U.S., qui est quand même
finalement un grand pays avec des sous-cultures différentes,
finalement, presque par état.
En changeant de contexte et en t'adressant à la bonne personne,
tu as littéralement changé les choses.
Au moment donné, il a fallu que tu sortes un peu de...
On va dire que tu te sortes les doigts du fondement,
excuse-moi l'expression, et que tu prennes ta bagnole,
que tu fasses quelques centaines de bornes
pour arriver au bon endroit.
Ce n'était pas quelques centaines de bornes,
c'était plutôt dans les 1000 miles,
ou 1300 miles, un truc comme ça.
Oui, donc plutôt, on était plutôt sur 2000 bornes.
Voilà, mais c'est juste conduire pour 24 heures,
ça, tu t'en fous.
Mais en fait, être...
C'est très important que tu sois dans le bon contexte.
Tu sais, t'as plein d'histoire,
après, sur les réseaux sociaux,
de...
T'es la bonne place, ça n'a pas pour toi.
Mais en fait, ça a vraiment drastiquement changé
après comment j'ai pu lever des fonds.
J'ai réussi à lever des fonds après
de CEO qui ont des boîtes de SaaS super connues.
J'ai levé des fonds de Jason Calacanis,
qui est un des premiers investisseurs de Huber, par exemple.
Et toi, c'est cette mentalité.
Jamais...
T'as accès, du coup, aujourd'hui à Segal,
où il te voit comme une espèce de microline
dans leur liste d'investissement,
ou si tu as bien appelé le mec,
tu prends le téléphone et tu peux l'avoir au téléphone.
Tu as un Slack Channel dédié où tu peux contacter toute l'équipe.
Ah, c'est génial.
Donc tu as un Slack Channel dédié,
tu peux contacter l'équipe, tu peux leur parler.
Ça, ça a une valeur qui est supérieurement
à mes yeux à l'argent qu'il a pu mettre dans la boutique.
Aujourd'hui, par exemple,
je vais donner un exemple.
Comment j'ai aussi de l'aide.
J'ai...
J'ai comment dire...
J'avais un problème, il fallait que j'arrive un contrat pour un client.
J'ai envoyé un email et j'ai dit j'ai besoin d'aide.
En 30 minutes, j'avais l'aide.
En 30 minutes, j'avais la réponse.
Donc en fait, c'est aussi un réseau que tu construis qui aide,
qui est vraiment énorme.
Enfin, ça a été...
Alors, on arrive à la fin de la boîte de temps.
Moi, je trouve ça tout ça passionnant et on aurait de quoi parler des heures.
Alors, tu m'as donné l'idée de faire un format long.
Peut-être que ça sera l'occasion de revenir.
Mais avant de se quitter, est-ce que tu pourrais donner
si tu devais prendre toute ton expérience là de ces 12 derniers mois.
Donner un conseil à un développeur qui veut lancer son produit
pour qu'il arrive à bout de strapper son projet.
OK. Premier premier truc, le plus important.
Pensez à ta droite un seul.
Construis une communauté.
Construis une communauté.
Construis une communauté autour de ton produit.
Parce qu'en fait, une fois que tu construis une communauté
autour de ton produit, parce qu'en fait,
99% des startups, elles vont construire des produits.
Tout le monde s'en fout.
Ils vont même pas avoir un utilisateur.
Tu as plein de boîtes dans Y Combinator.
Les mecs, ils font un produit, ils mettent 6 mois à faire un produit.
Il dépense 100 000 millions de dollars à faire un produit
pour à la fin avoir zéro utilisateur.
Quand tu as une communauté, tu as des gens qui te suivent.
Tu as des gens qui croient en toi.
Tu as des gens qui voient l'utilité du produit.
Ces personnes, elles vont te suivre.
Et ça, c'est très important parce qu'elles vont t'utiliser.
Elles vont te soutenir quand tu vas lever des fonds.
Quand tu vas lancer ton produit sur Product Hunt, par exemple,
ils vont faire en sorte que ce soit sur la première page.
C'est des gens qui croient en toi.
Et surtout dans tout ce qu'est outil Developer Tools,
dans mon domaine, la communauté, c'est vraiment tout.
C'est quelque chose qui est important.
Et aujourd'hui, si tu regardes comment les businesses se forment,
c'est principalement fondé sur la communauté.
Tu regardes les nannas qui font
tout ce qu'il y a en fluenceur, les business influenceurs,
ils ont créé une communauté et après, monétise la communauté.
Donc je me fais follow-up sur Instagram
et après, je vends du parfum, je vends des vêtements.
C'est la même chose, attire les gens.
Alors je t'avoue que forcément,
ce n'est pas moi qui vais te contredire.
Mais j'avoue que je ne m'attendais pas à ça,
mais ça me plaît énormément.
Du coup, ce sera le mot de la fin
jusqu'à ce qu'on trouve sur le podcast, Julien.
Si jamais les auditeurs veulent en savoir plus,
ils veulent découvrir CodeGa et ils peuvent venir où ?
CodeGa.io, CodeGa.io et Code-snipet.dev,
qui est le moteur de recherche pour tous les codes snippets.
Merci beaucoup Julien d'être venu aujourd'hui.
Merci.
Quart à toi, cher auditeur, comme d'hab, j'espère que t'as kiffé cet épisode.
Et si tu as envie d'apprendre à écrire du code durable,
apprendre à faire du TDD, refactoriser ton code et créer du code propre,
je t'invite à venir découvrir le cursus artisan developer
dans la maison des compagnons sur
compagnons.artisandeveloper.fr rubrique formation.
Je te souhaite une bonne fin de journée et je te dis à bientôt.