Bonjour à tous, bienvenue dans ce nouvel épisode de Double Slash, le podcast où on parle
de développement web.
Et comme d'habitude, nous sommes avec Alex puisque nous sommes deux dans le podcast.
Salut Alex !
Salut Patrick, salut tout le monde.
Et je suis… tu vois, je ne m'en rappelle, il y avait un boss, je bossais pour une boîte
qui me disait c'était avec une grande émotion, il commençait toujours ses réunions, c'était
avec une grande émotion.
Et là, c'est un peu avec une grande émotion qu'on se retrouve pour le centième épisode.
Centième, ouais, ouais, ouais.
La aventure qui a commencé en avril 2020, si je ne me trompe pas.
Ouais, c'est ça.
En plein Covid-2.
Et quatre ans après, on est encore là et on y prend toujours plaisir.
On est passé de l'audio à la vidéo, on est passé sur différents formats, des news,
des workshops, des choses comme ça, des invités.
Et ça nous plaît toujours autant et je pense qu'on pourrait remercier toutes les personnes
qui nous ont accompagnées dans cette aventure Double Slash.
Certains sont là depuis le départ, un grand merci à eux.
Certains sont arrivés en cours de route.
Beaucoup de commentaires, de questions, beaucoup de likes, d'abonnements sur YouTube qui nous
ont aidés à gagner en visibilité.
Et aussi, toutes les personnes qui nous soutiennent financièrement via GitHub sponsor à leur
moyen, à leur contribution.
Et tout ça, un grand merci pour toutes les personnes qui nous ont accompagnées dans
cette aventure.
Mais c'est pas fini, Patrick, on est d'accord ?
Non, c'est pas fini.
Non, merci à tous les contributeurs, aux auditeurs, visionneurs parce que sur YouTube,
je sais pas, c'est pas des auditeurs.
C'est des viewers.
Des viewers.
C'est vrai qu'au début, on a commencé en audio uniquement et après on a basculé
tranquillement sur YouTube.
Alors au début, c'était juste un petit peu...
On sortait des vidéos sur YouTube.
Et puis c'est vrai que maintenant, on est presque plus sur YouTube qu'en audio, mais
on est toujours présent en audio évidemment sur les plateformes de podcast, Spotify, Apple
podcast et compagnie.
Même si Spotify, c'est un peu mieux que Apple podcast, on va dire.
Disons qu'ils ont poussé un peu plus le podcast que Apple qui fait rien depuis des
années en fait, alors que c'est eux qu'on crée un petit peu le support.
Mais complet, complet.
Complait depuis très, très, très, très longtemps, Apple a vraiment initié...
C'était les précurseurs du podcast.
Podcast, ça commence par...
iPod, c'était le même délire quoi.
C'était vraiment, mais vraiment les premiers et aujourd'hui, ils ont un peu délaissé ça.
Bon, tant pis, c'est pas grave.
Donc c'est cool.
Ouais, donc on avait donc posé sur Twitter sur YouTube, on avait proposé aux audits,
à tout le monde, de poser des questions, mais libre comme vous voulez, un peu de tout.
Donc on a récolté toutes les questions, et on a fait un petit slide-ev.
Ouais, on a profité pour passer justement, pour essayer et tester cet outil de présentation,
pour créer des présentations à partir de fichiers Markdown.
Tout est fait à base de conventions, donc ça marche out of the box, c'est super bien.
Sauf que comme toujours, il faut connaître les conventions,
et quand tu connais pas les conventions, tu galères, tu cherches, et tout,
on a réussi rien de bien compliqué.
Donc aujourd'hui, en fait, un épisode où on va pas parler de tech spécifiquement,
sur une techno particulière, on va surtout écouter et répondre à toutes vos questions
que vous avez, on va les prendre une par une.
Et je pense qu'on fera ça de temps en temps, des épisodes spécifiques,
où on viendra justement répondre à toutes vos questions.
Donc si vous avez des questions, posez-les dans les commentaires,
et on y répondra dans un épisode dédié spécifique.
Et puis le jour où j'ai la fibre, on pourra faire un live.
Ce que pour l'instant, c'est pas possible avec ma connexion.
Mais le jour où ils mettent enfin la fibre, ou je déménage, on sait pas,
et bien on pourra faire des lives avec des questions live, ça sera cool.
Et ça, ça sera vachement bien.
Allez, on attaque Damien qui nous pose une question d'ordre plutôt méthodologique.
Comment vous faites pour être aussi régulier ?
Comment vous vous organisez et structurez le temps qu'on dédie à Double Slash,
avant chaque épisode ? Comment vous préparez et partagez les actualités ?
Qu'est-ce qui vous motive le plus à tenir le podcast et à contribuer aussi régulièrement ?

Là, c'est plus une question de méthodeau.
Clairement, sur la motivation.
En fait, je pense que la régularité, elle se fait de manière assez simple,
tant qu'on a de l'actualité.
Et en fait, je pense que aussi bien toi que moi, on est toujours un peu en veille sur l'actualité.
Donc on va regarder notre fille de Twitter, on va regarder, on va suivre des personnes
qui, pour nous, qu'on considère comme influents et qui sont au fait de nouvelles technologies.
On va les lire pour nous.
Et si on juge intéressant, on les met dans un ocean partagé.
Et une fois qu'on a la quantité qu'on juge conséquent, on la structure,
on l'ordonne un petit peu et puis on enregistre.
Et là-dessus, ça, on va dire, c'est le process.
Après, sur la régularité, parfois, c'est un peu plus dur.
On ne va pas se cacher.
Dans l'ensemble, je n'ai essayé de ne pas réfléchir aux questions.
Mais celle-là, je l'avais eu passer.
J'ai réfléchi à ça, justement, quand je l'ai sous ma douche, tranquillement.
Je me suis dit, en fait, à mon avis, le fait qu'on soit régulier et qu'on continue,
qu'on soit à l'épisode 100 et que...
Je pense que c'est dû au fait qu'on soit deux.
Et à mon avis, si tu avais lancé le podcast toi ou moi, tout seul,
je pense qu'il n'arrête peut-être pas durer.
C'est-à-dire que tout seul, des fois, tu vas louper un épisode,
tu vas le faire un, une fois par mois, au lieu de faire deux fois par mois.
Et après, tu commences à perdre la motivation, etc.
Là, tous les deux, en fait, on se motive un peu tous les deux.
On s'est posé des dates aussi.
On dit, voilà, on fait ça tous les mercredis, machin, tout ça.
Et à chaque fois, ça nous force, en fait, à être régulier.
Et complet, parce que quand il y en a un qui est un peu dans le dur,
qui a mon envie, qui est fatigué, l'autre, il est taqué.
Et en fait, c'est jamais la même personne qui va pousser ou qui va tirer.
Et pour le coup, c'est indispensable d'être deux.
Ça a été un grand gage de régularité, indéniablement.
Et après, le fait qu'on se partage le travail aussi,
tu t'occupes plus du montage, tout ça.
Moi, je fais un peu les textes et tout.
Donc ça, ça joue aussi parce que ça fait un peu moins de travail pour chacun.
Jouer en équipe, clairement.
Ouais, c'est ça, ouais.
Donc, ouais, je pense que notre force, c'est d'être deux.
Clairement.
Mais en même temps, c'est double slash, quoi.
Il y a double, il y a cette notion de dualité.
Seul avec froid.
Alors, on va reprendre les pseudo que vous nous avez données sur Twitter.
Ou sur...
Faciles.
Pour l'instant, on est encore sur du facile.
Parfois, c'est un petit peu plus compliqué.
La question est comment on pourrait décrire le métier de DevWeb
et son écosystème dans dix ans.
Alors, c'est nous, notre souhait, dans dix ans vers quoi ça va aller.
Et après, c'est plus une question de répartition de temps,
donc d'organisation au quotidien,
entre le temps pour les clients, le temps pour les projets persos,
notre veille et la transmission à travers ce podcast.
Et comment ça peut évoluer dans le fil des années.
Vas-y, sur la projection à dix ans, tu commences.
C'est chaud, à dix ans.
À dix ans, dans le web, c'est une éternité.
Déjà, il y a dix ans, t'imagines.
C'est difficile à répondre.
Après, je ne suis pas sûr que ça change tellement, en fait.
Parce que, déjà, il y a dix ans, on pensait que ça allait beaucoup changer.
Et finalement, on est toujours sur le même...
Tu vois, le PHP, toujours là, etc.
Les techno, toujours là.
On fait toujours le CSS.
On fait toujours le CSS du JS.
Ce qui a beaucoup évolué, par contre, c'est que les langages ont évolué,
les navigateurs ont évolué.
Aujourd'hui, c'est beaucoup plus facile.
Ça, c'est clair qu'il y a dix ans.
Il y a moins de hacks dans le code, etc.
JS, maintenant, il est super mature.
Voilà, c'est un vrai langage.
Donc, en fait, c'est plutôt de l'évolution qu'on a eue d'il y a dix dernières années,
sur la facilité.
C'est vrai que les devs aujourd'hui qui arrivent, ils trouvent ça super simple.
CSS, c'est flex, grid, tout ça.
C'est le top.
Donc, je pense que, en fait, dans dix ans, je ne sais pas si ça aura tellement changé,
à moins que le support change aujourd'hui, c'est les navigateurs.
Est-ce que demain, le support, ça sera le Vision Pro,
est-ce que ça sera, je ne sais pas.
Après, on nous a tellement pris des choses qui n'ont jamais pris.
Par le smartphone qui a été vraiment une révolution,
où c'est vraiment un device qui appart,
et ça nous a vraiment poussé aux responsives, etc.
Ouais, mais regarde, même ton device,
il a toujours un écran avec une taille.
L'interface, elle n'a pas changé.
Je pense que, nous, notre métier web pur,
je pense que ça va changer un peu légèrement
sur les interfaces,
mais on gardera toujours notre techno web,
et c'est la techno web qui se mettra de plus en plus dans les interfaces.
Par contre, moi, je suis un peu plus persuadé que notre métier va plus évoluer,
ou aujourd'hui, on est mega assisté,
enfin, ou en tout cas fortement assisté,
avec des briques d'IA, ou des techno hyper spécifiques.
Par contre, je pense que la maturité des clients
pour utiliser tous ces systèmes-là
est juste d'exprimer son besoin
et de traduire le besoin client en langage informatique
et utiliser des briques techno,
ça, avant que ça soit remplacé,
je pense qu'on est très, très large.
Donc, le métier pur dev,
en mode avec un cahier des charges ultra précis
pour pisser du code, on va dire.
Ça, oui, je pense que ça, ça va sans doute mourir.
Par contre, comprendre le besoin,
traduire le besoin, exprimer le besoin,
et toute la partie créativité.
Je pense que là, il y a une grosse, grosse partie
qui va pas changer.
C'est clair que l'IA va changer les choses aujourd'hui,
ça va beaucoup changer encore.
Après, il faut voir comment ça va évoluer l'IA,
mais pour l'instant, ça va très, très vite,
mais après, ça va calmer un petit peu, je pense.
C'est clair qu'on sera de plus en plus productifs,
non seulement par rapport au langage, mais aussi par rapport à l'IA.
Potentiellement, oui, il y aura peut-être moins besoin
de développeurs dans le futur.
Pour une boîte qui a 10 développeurs,
ils en ont besoin peut-être que de 5,
parce qu'il y a plus productifs.
Nous ne remplacera pas, je pense, ça c'est sûr,
parce que comme tu dis, le jour où les clients
seront capables de faire un cahier des charges précis, etc.,
c'est pas demain.
Donc ça, c'est bon, de ce côté-là, on est tranquilles.
Mais c'est clair, ça va évoluer,
donc c'est vrai qu'il y aura peut-être moins besoin
de développeurs, moins nombreux en tout cas.
Enfin, c'est ce qu'a prédit, en tout cas,
tout ce qui est Amazon, tout ça.
Des grandes boîtes qui aujourd'hui,
on fait des prédictions de l'avenir.
C'est clair qu'ils pensent déjà
embaucher beaucoup moins de développeurs dans le futur.
Yes.
Et autre question,
sur la répartition du temps,
perso-client, veille,
vie perso, vie pro,
toi, tu t'organises comment ?
Ecoute,
déjà nous,
on est indépendants tous les deux,
on est donc à notre compte.
Donc c'est un petit peu différent que si on était salariés.
Donc on a quand même plus de liberté à ce niveau-là.
Donc c'est vrai que, par exemple,
là, on enregistre, on serait salariés,
on ne pourrait pas enregistrer comme ça le matin,
en plein milieu de matinée, ça, c'est clair.
Ah ouais.
À moins que notre employeur se superopène,
mais je ne pense pas.
Moi perso, j'essaie d'avoir un bon équilibre.
Donc, déjà,
je ne travaille pas le week-end tout ça.
Le soir, j'essaie de couper,
je ne travaille pas le soir, la nuit, tout ça.
Donc je suis plutôt à avoir un équilibre,
une santé mentale normale,
à ce niveau-là, voilà que le boulot ne bouffe pas la vie perso.
Après, on est assez sportifs tous les deux.
Donc moi, je fais beaucoup de sport.
Donc ça me permet aussi de beaucoup évacuer.
C'est hyper important. Je suis incapable de vivre
sans faire du sport.
Donc là, en ce moment, je cours beaucoup,
mais ça peut être le vélo, ça peut être n'importe quoi.
Et puis le podcast,
après, le podcast, ça ne prend pas énormément de temps.
C'est souvent la chance qu'on a par rapport à ce qu'on fait aujourd'hui.
On prépare les news, on les note au fur et à mesure, etc.
Après, on enregistre.
Mais ce n'est pas aussi un temps énorme.
C'est vrai que si on faisait plus de workshops,
tout ça, ça serait un peu plus compliqué.
Mais non, ça va.
Pour l'instant, l'équilibre est correct.
Après, ça dépend. Il y a des moments de coups de bourg
où on a vraiment beaucoup de projets.
Comme là, il y a pendant deux mois,
j'ai eu beaucoup de trucs à faire.
Donc c'était un peu plus compliqué, mais on arrive toujours
à équilibrer.
Et toi ?
C'est toujours précaire.
C'est quelque chose qui évolue tout le temps.
Alors moi,
j'ai la chance d'avoir d'être mon éditeur de ski
aussi l'hiver.
Donc je moque 3-4 mois de l'année
où je suis un peu plus off
côté code.
Même si l'année dernière,
j'ai fait double emploi.
Mais il y a une notion en ski
qu'on utilise.
On n'essaie pas de chercher l'équilibre.
On apprend à gérer le déséquilibre.
Et en fait, c'est vraiment ça.
Moi, j'ai jamais l'impression
d'être toujours
bien proportionné
sur mon temps client,
mon temps pro, perso, tout ça.
Pour moi, c'est tout le temps,
je dois toujours me poser la question.
Sinon, en fait, je vais me faire croquer.
Et je me rends compte souvent trop tard
que je me suis fait croquer sur mon projet client.
Ou
je suis complètement à l'amour parce que
j'ai pris trop de temps perso.
Et donc,
oui, moi, j'aurais plutôt tendance
à me faire niquer et à bosser beaucoup trop.
Et à me rendre compte
à posteriori que j'ai trop bossé.
Et je m'arrête que
quand je suis vraiment au bout,
donc, c'est pas bien.
J'apprends avec le temps.
Mais
ce qui est sûr, c'est que
ces moments, tu vois, où on échange
sur le podcast.
Ou à travers
des workshops qui sont, comme tu dis,
bien plus chronophages en termes de préparation.

sur ces émissions de podcasts,
moi, ça me fait du bien, c'est cool.
Cette notion de transmission
est hyper importante.

je pense que la transmission nous anime.
Et donc, c'est important
de mettre les grosses pierres.
On connaît tous
l'image du
saut, là, où tu mets
les choses les plus importantes
dans le saut en premier, et puis après,
tu rajoutes ce que tu veux.
Mais c'est toujours compliqué.
Et c'est quelque chose qui évolue
dans le temps.
En tout cas, moi, je n'arrive pas à trouver
une semaine type
de dire, ok, là, tous les lundis,
je fais ça, tous les mardi, je fais ça, tous les mercredis,
je fais ça. J'arrive pas.
Je me force à le faire
parce que sinon, il y a rien qui sort.
Mais c'est très difficile.
Et c'est reste toujours précaire
et il faut constamment
le réévaluer.
Très difficile.
Surtout comme avec les clients,
des fois, ils sont toujours pressés,
c'est toujours pour avanquière, etc.
Ça aussi, il faut savoir temporiser les clients pour leur dire
bon, ok, mais oui,
on a tendance à toujours...
En fait, c'est ça,
personnellement,
moi, c'est un peu en montagne,
c'est-à-dire qu'à un moment, j'ai beaucoup, beaucoup de travail
et là, ça sera super speed.
Et à des moments comme là, en ce moment,
là, c'est un peu plus cool.
C'est hyper variable.
Après, c'est peut-être différent si t'es dans une agence,
ou les choses comme ça. Alors, les agences,
pour ceux que je connais, ils sont toujours à bloc,
mais c'est montagne russe, mais tout le temps en haut, en fait.
Moins drôle.
Beaucoup moins drôle.
Allez, on bascule
sur une question, pour le coup, un petit peu plus tech.
On revient sur...
sur de la tech, c'est Nicolas.
Vous avez marqué
que les LLM dans le navigateur,
si elle est là, il y a eu, il y a eu,
ça bouffe beaucoup de ressources clients.
Je crois que ça passait tout
côté serveurs.
Je galère parfois, est-ce que c'est normal ?
LIA nous aide
à coder, vous en pensez quoi ?
Ça va plus vite.
Et est-ce qu'il faut acheter
une machine de gamer pour utiliser
tout ça ?
Créa... Alors, il nous invite
à créer un petit moteur de recherche
pour les épisodes.
Ça serait... ça serait au top, et ça nous aiderait
à trouver tout facilement
les Pépites.
Allez, je vais commencer par la dernière question,
parce que je suis en lien direct.
Ouais, sujet...
sujet ouvert depuis un moment.
Pour le coup, on a
prévu de faire ça.
Moi, je voudrais vraiment mettre Melysearch
devant, en fait,
parce que le site Internet
de Double Slash est fait avec NUXT.
C'est moi qui ai codé et qui ai fait
le module open source de NUXT
avec Melysearch.
Melysearch est une solution
de moteur de recherche
interne, ultra rapide,
efficient, tout machin.
Sauf que, on va dire,
mon projet client
me prend beaucoup, beaucoup de temps
et j'ai avancé
un peu là-dessus.
Sauf que, peut-être, j'ai ouvert
la boîte de Pandorn, dans la mesure où
on dit, ok, on va faire toutes les transcriptions,
on va mettre les transcriptions, après, on va
mettre des embedding.
Donc, en fait, je me suis renté
dans une grande, grande mission, et pour
l'instant, elle est pas encore terminée.
2025,
je peux m'engager, il y a un moteur
de recherche sur
Double Slash.
C'est début ou fin 2025 ?
J'ai dit 2025.
Tu prends la question
LLM,
côté client,
ou...
Oui, bah écoute, je sais pas trop,
parce que...
Non, je vois pas,
enfin, je sais pas trop de quoi,
il voulait parler, c'est quoi, chat GPT, tout ça,
est-ce que, quand tu utilises chat GPT,
ça bouffe des ressources côté client, effectivement.
J'ai aimé remarquer ça, personnellement.
Ouais,
là, j'avoue, je suis un peu surpris,
parce que...
Normalement, en fait, c'est plutôt...
En fait, c'est
ton entraînement, ton
modèle qui va vraiment être chronophage
en ressources, et en CPU, tout ça.
Ok.
Après, si tu utilises
pour ce qu'on appelle l'inférence,
donc en fait, c'est la consommation
d'un modèle, tu vas poser ta question,
ton prompt, et lui, il va te
répondre. Toute ton inférence,
bah, si tu l'as fait sur
des serveurs type Openian
ou Mistral ou tout ça,
bah, ça va être...
La ressource va être déportée, donc elle est pas chez toi.
Bah ouais.
La seule possibilité, c'est
si tu héberges
en fait ton propre modèle,
et avec des solutions type Olamas,
où tu viens, en fait,
héberger ton propre modèle, et le
modèle tourne sur ta machine,
à ce moment-là, évidemment, que ton
inférence va te coûter de l'énergie.
Mais si tu es sur des sites Internet,
avec des serveurs distant, normalement,
ça devrait pas croquer
de la ressource, quoi.
Ouais, mais après, même si tu es
en local, tu vas bouffer de la ressource
ce temps de mordi, mais après, le
navigateur de site ne devrait pas monter
en ressource, donc c'est bizarre.
À moins que...
Alors après, il y a des librairies
GIS qui sont capables de
défectuer des choses
en niveau du navigateur pour comparer
des chaînes, tout ça. Il y a des choses
disponibles, donc c'est peut-être ça,
peut-être qu'il y a des gens qui utilisent des trucs comme ça,
ou du wasm, ou des trucs comme ça, je sais pas.
Ça va être assez étrange, c'est...
Avec des workers.
Préciser un peu plus le cas
d'usage. Mais après, il y a Edge
aussi qui a intégré l'IA dans leur navigateur.
Alors est-ce que ça, c'est bien...
Après, je fais confiance à Microsoft pour bien
intégrer les choses, mais... Ouais, étrange.
Il faudrait avoir plus de précision, ça nous
intéresse.
Voilà, tu vois, si
justement, ils utilisent des
workers pour exécuter
des requêtes,
enfin, de prendre de la
ressource machine sur le client
pour justement exécuter
des choses que eux n'ont pas à faire.
Je... Ouais.
Je sais pas. Après,
sur la question
IA,
on en pense quoi pour coder
est-ce que ça va pas poser des
soucis plus tard ?
Moi, je pense pas.
Je pense que ça... C'est que du
bénéfice. Et
c'est... Comme on le dit souvent,
c'est un super assistant qui va
nous accompagner, et qui va nous aider,
et qui va nous faciliter la vie
nous en tant que devre.
Et on voit qu'il y a de plus en plus
de contexte. IA
prend de plus en plus toute la code base.
Et donc, il va aussi
apprendre avec des conventions de
nommage, et donc, il va devenir
de plus en plus malin.
C'est indéniable. On le voit
sur les deux dernières années, entre
la première version de Copilot
et les dernières assistants qu'on a.
Le progrès est quand même plus
que significatif. Donc
je pense que ça va plutôt dans le
bon. Moi, je le vois plus comme un super assistant.
Après, est-ce que
on a besoin de faire tourner
des machines de... d'acheter une machine de
gamer pour faire tourner ça ?
Je ne pense pas.
Parce que tu as déjà
une machine de gamer.
Le mec il a déjà super rendu.
Non, c'est pas vrai.
Si, ça faut quand même monter les ressources.

après, si tu réfléchis un petit
peu, codé avec IA.
Alors moi déjà, Super Maven en ce moment, je ne sais pas si
je suis le... Enfin, apparemment je ne suis pas le seul, parce que
Yohan Dev a le même problème actuellement.
J'utilise Super Maven.
Et je trouve que en ce moment, il répond pas terrible.
Et il est lent, des fois j'ai pas de réponse.
Et en fait, je trouve de moins en moins performant.
Alors peut-être que voilà, il a trop
succès et qu'il y a trop d'appel et ils n'arrivent pas à répondre.
Mais là, en ce moment, Super Maven,
il marche très mal et je me demande si je ne veux pas
repasser sur Gopilot, parce que en fait, je paye 10 dollars
pour pas grand chose, parce qu'il ne mette quasiment pas.
Le mot... Alors, le...
Le revers du truc, c'est... Alors nous,
on est... On va dire
senior entre guillemets, on est développeur,
on est capable de lire le code de IA,
qu'elle nous génère, etc. De corriger. Est-ce que
par contre, pour des juniors tout ça,
de utiliser IA, ça va pas leur donner
des mauvais réflexes.
C'est-à-dire que le code
est déjà maché, il est sorti. Alors déjà, il faut le lire,
l'analyser et dire ok, ça c'est bon, ça c'est pas bon.
Attends, je vais corriger ça parce qu'il y a une connerie
là. Déjà ça, faut être capable
de le faire. Et puis derrière, est-ce que
ça va pas
donner des mauvaises habitudes comme
quoi ? Bah je vais pas chercher la dog,
je vais pas approfondir dans la dog pour comprendre
comment ça marche, parce que j'ai IA qui
me sort le truc. Et puis en fait,
c'est ce que ça ne veut pas devenir fainiant
en fait, en tant que dev,
puisque IA fait notre boulot et que
finalement, elle n'a que de la relecture.
Ouais, je suis là,
là-dessus, je te rejoins totalement.
Je pense que c'est
très bien. Néanmoins,
tu dois quand même comprendre
ce que ton IA te sort.
Et si tu prends ça pour argent content,
bah tu t'exposes,
parce que des hallucinations,
elles en a. Donc
tu peux pas
donner un trust
à 100% sur ce qui sort
de l'IA.
Par contre, sur de la dog,
tout ça, elle va être super super maline,
c'est indéniable,
ça va te faire gagner du temps. Par contre,
c'est comme tout. Le côté magique,
si à un moment donné, tu comprends pas la magie,
ça va se retourner
contre toi. C'est
gros pouvoir, grosse responsabilité,
mais si tu sais pas
maîtriser tout ça, et t'as pas compris
les aboutissants
de ton code, clairement
ça se trouve, il va faire des trucs
complètement débiles. Donc il faut toujours garder
ton esprit critique.
Et cet esprit critique, c'est toujours la même
chose, tu dois connaître
ta techno. Par contre,
c'est un super moyen pour apprendre.
Pour apprendre.
Et tu vois, il t'est... Ouais, attends, j'ai vu,
là, en SQL, il a sorti un truc.
C'est quoi ça ?
Si toi, tu vas faire... Tu vas chercher
la doc,
et tu vas découvrir
potentiellement, ça peut être un super
assistant, un super enseignant
pour te faire
monter en compétence sur
des sujets. Par contre, c'est à toi de
toujours garder
ton esprit curieux
et d'aller chercher, et d'essayer
de comprendre ce que
ChatGPT te sort, ou CurSort,
ou n'importe.
Te sort tout prémaché.
Ok, c'est bien, ça fonctionne.
Mais ça, c'est le niveau 1, quoi.
Ça fonctionne.
C'est vraiment le niveau 1. Il faut comprendre
les tenants, les aboutissants, savoir comment
ça évolue, pourquoi, comment.
Et ça, il n'y a pas de choix.
T'es obligé de l'apprendre.
Et tu dois aussi
choisir
tes batailles. Parce que tu ne peux pas
tout apprendre tout de suite. C'est impossible.
Donc, tu choisis
de mettre ton focus sur un sujet.
Tu montes en compétence, et puis après
tu passes sur un autre sujet.
Mais
il faut garder en tête
que tu gardes ton esprit critique
et monter en compétence.
Ça, on ne pourra jamais te l'enlever, tu vois.
Ouais, c'était quoi ?
Il y avait une autre question, c'était quoi, l'autre ?
Non, c'était pas répondu, je crois.
Ouais, c'est
à peu près bon.
On parlait
de Seigneur,
il y a Amin B, je ne sais pas
si ça se prononce comme ça. Et tant Seigneur,
je suis plus amené à diriger des équipes
tant au niveau fonctionnel
qu'au point de vue des PR
qu'à coder,
expérimenter.
Est-ce que c'est la même chose pour vous ?
Comment vous faites-vous pour protéger du temps
conséquent dédié au DEV ?
Sur la gestion
des équipes.
On parlait tout à l'heure
de gérer
des personnes
et en fait
sur quoi tu mets ta grosse pierre ?
On parlait tout à l'heure
des sauts et des grosses pierres.
C'est quoi le plus important de ta journée ?
Si ta mission première
elle est
d'être avec les équipes
et de faire ta montée en compétence
sur des équipes,
c'est la chose que tu vas faire en premier.
Par contre,
si tu as pour objectif
ta mission première,
c'est d'expérimenter,
tu mets ça le matin et l'après-midi
et tout.
Donc en fait, le danger c'est de se faire croquer
parce que tu sais très bien que
quand tu fais de la montée
en compétence sur des DEVs,
tu vas passer vachement de temps
à expliquer des concepts,
à expliquer ton code,
à relire ton code
ou à voir comment on peut le faire évoluer.
Et ça c'est hyper chronophage.
Donc ta journée, elle dérive,
elle dérive, tu vois.
D'où l'importance en fait de bien mettre
la chose la plus importante en début de journée.
Par exemple, si tu dois, toi,
tu dois coder et expérimenter des choses,
tu fais ça le matin et ton après-midi, elle est dédiée
aux équipes, tu vois.
Et ça c'est un très, très bon moyen
de
t'organiser ton temps.
Mais là pour le coup, c'est vraiment
une organisation de temps.
Personnellement, je n'ai pas eu
à gérer
pendant des années des équipes.
Par contre, quand j'ai eu des juniors avec moi,
j'étais obligé de faire ça
et ça prend beaucoup de temps.
Ça prend beaucoup, beaucoup de temps.
Là, je ne sais plus comment il s'appelle.
C'était comme dans son nom,
je ne sais plus.
Ouais, a priori, ça lui manque de coder.
Sur les cas, la personne qui a mis le commentaire.
Et je le comprends.
Je pense qu'en fait, il est lead dev
ou en quelque sorte dans sa boîte
et qui se retrouve à gérer
les devs en dessous.
Évidemment, il ne fait que du
management et de revue de PR.
Parce que c'est le seigneur
et c'est le meilleur.
En général, le façon
de les revues de PR, c'est tout le monde qui se les fait.
Puisque ça a plusieurs personnes qui vont relire
une PR avant de la valider.
Mais moi, perso,
ça nous n'est pas...
On n'a pas de gestion comme ça de personne
puisqu'on est indépendants
et donc on s'intègre plutôt à des équipes.
Donc c'est un peu différent.
Après, ça m'est arrivé d'être intégré
dans une équipe ou un projet dans une boîte.
Et après, oui, je formais un petit peu
le dev en interne, notamment sur NEX
ou des choses comme ça. Mais c'est pas vraiment de la gestion.
Alors je comprends.
C'est difficile quand tu es dans une société
de...
Il n'y a pas le temps de coder.
Donc après, ce qui lui reste,
c'est de coder un petit peu à côté en side
projet, des trucs comme ça pour s'amuser,
expérimenter. Mais à moins que la boîte lui donne
un style 20% de son temps pour coder
et tester les trucs comme il fait chez Google.
Mais le problème, c'est que quand t'es le lead dev,
t'es obligé de gérer tout le monde.
Et puis pour le coup,
si tu es sur aussi des questions
stratégiques
ou intégrées dans le processus
de décision ou tout,
ou t'es à moitié CTO, tu vois.
Ouais, c'est ça.
Parce qu'il faut pas cela.
Il y a plein de boîtes où le lead dev, c'est le CTO.
Puis en fait, il y a
deux devs. En fait, c'est une équipe de 3.
Mais quand
le market a
un projet ou un truc,
ils sont obligés d'en parler au CTO pour voir
les impacts que ça a. Donc au final,
t'es au four et au moulin
et tu t'arrives plus à coder.
C'est très, très difficile.
Et c'est...
Si le code te manque,
il faut repasser
développeur simple.
Voilà.
C'est assez de solution.
Mais quand tu gères
Call and Mine, ou
des hommes, et de la revue
de code et de la montée en compétence,
c'est quand même assez sympa.
C'est quand même super sympa.
Mais quand t'es pas
sur de l'archi ou sur des trucs
théoriques,
et au final, t'es
plus dans le concret.
C'est totalement...
Quand tu passes tes journées à faire des revues de
code de PR, c'est...
ça va quoi. C'est vite soulant.
Ça doit être... ça doit être dur.
Tu parlais tout à l'heure
de Next.
De Next, ça avait fait
de la montée en compétence
sur Next. Patrick, je crois que la question
est plus pour toi.
Comment vous organisez
l'architecture des dossiers
sur Next 15
pour une application complète ?
Ça m'intéresserait de savoir comment vous structurez
les pages, les composants, les hooks,
la gestion des états, l'intégration des
API, tout ça.
Est-ce que vous utilisez des conventions,
quelles sont les best practices
que vous utilisez ?
Qu'est-ce qui guide vos choix ? La
maintenabilité, la perte, le déploiement.
Et si vous gèrez aussi des trucs comme
l'internalisation des tests,
l'optimisation des performances,
ça serait cool d'avoir des détails, surtout
sur les nouveautés de Next 15.
Next. Yes. 15.
Ouais, ça m'arrêterait presque un épisode entier
sur cette question.
Ouais, pour le coup, je suis complètement d'accord
que sur la structure,
tu vois,
on pourrait refaire un épisode
en complet, quoi.
Tous les deux, on fait... alors toi,
tu es plutôt Next, enfin, c'est
10 Next, on va dire, on ne va pas
plus tôt, tu es 10 Next.
Moi, je fais du Next aussi beaucoup, et du
Next, je fais les deux.
Next, il y a vraiment une convention
de
dossier, etc. voilà, tu as une structure,
tu structures comme c'est défini, il y a
une convention, et en plus, il y a l'autoloading
de component, etc.
La chose qu'on n'a pas du tout dans le
monde React et dans Next, et ça a
toujours été comme ça, en fait, React, ils ont
toujours été sans convention
au niveau de
ton projet, tu fais vraiment comme
tu veux, il n'y a vraiment aucune règle.
Donc après, évidemment, il y a des règles
qui sont plus ou moins suivies par
la majorité, mais il y a
aucune convention à ce niveau-là.
Next, j'ai 15, c'est la même chose que le 14
ou 13, parce que de toute façon, il n'y a pas eu
d'évolution depuis la 13 avec le app
Donc, ce qu'il faut favoriser,
c'est la maintenabilité, ça c'est clair.
Et savoir retrouver
les choses facilement.
C'est-à-dire que si t'arrives
dans un projet que t'as codé il y a 6 mois,
et que tu n'arrives pas les choses, c'est qu'il y a un
problème. Déjà, si tu ne sais pas
où est ton store, si tu ne sais pas où sont
tes hooks, ça veut dire que c'est le bordel,
que c'est mal rangé, etc.
Moi en général, je suis regardé vite fait
sur un des derniers projets Next que j'ai fait.
Alors, il y a toujours le débat
entre est-ce qu'on met tout dans
appp ou est-ce qu'on met à la racine
ou à débattre.
Ce qu'il faut savoir, c'est que
dans appp, en fait,
tant que tu peux mettre des dossiers tant que tu veux,
tant qu'il n'y a pas de pages
dedans, pointes TSX ou des JSX,
en fait, c'est pas une route.
Donc, il n'est pas considéré comme une route.
Donc, ça, à ce niveau-là, tu peux mettre tout ce que tu veux.
Donc, dans le dernier projet que j'ai fait, j'ai mis tout dans appp
et après, je sépare. Donc, le store
j'ai un dossier store,
les hooks, j'ai un dossier hook, etc.
Si j'ai des
calls vers une app, je vais
structurer dans un dossier app
ici, il faut.
Je sépare vraiment les choses dans des dossiers
pour que ce soit rangé. En fait,
comme quand tu rangerais ta chambre
ou ta maison, tu ranges pour des tiroirs, etc.
Donc, après, je suis peut-être
influencé aussi par Nux,
qui a aussi ce genre de dossier, etc.
où c'est vraiment rangé le store et tout ça.
Mais généralement, c'est surtout la
maintenabilité, la lisibilité
dans le futur, que ce soit pour nous,
dans le Dèv ou les autres personnes
de l'équipe qui arrivent à trouver
les choses facilement.
Après,
juste pour compléter
là, pour le coup, c'est beaucoup plus
global sur la structure.
Mais ça m'arrive
souvent de revenir sur un projet,
on va dire tous les six mois.
J'ai mon client qui me rappelle qui me dit
« Vas-y, on fait une évolution,
il faut faire ça, ça, ça. »
Et quand il me verbalise
la demande, je fais là « Oh putain, non,
je vais être obligé de tout refaire. »
Et en fait, quand t'arrives sur le code
et tu changes
trois, quatre lignes, tu mets ta condition,
tu mets ta fonction,
tu fais ta dérivation
et quand t'arrives
et que c'est le bordel,
tu t'en veux, tu te maudis.
Et moi, je l'ai eu plusieurs fois.
Et maintenant, tu dis « Ok, je vais prendre
peut-être un quart d'heure de plus,
ou 10 minutes de plus, ou peut-être parfois
une demi-heure de plus, pour refacto,
mais de telle manière que ça soit
clean, propre. Et
demain, en fait, ton futur
toi te remercie déjà, tu vois.
Parce que quand t'arrives sur le projet
et on t'a demandé
une modification, parce que la règle
a évolué, t'arrives sur le projet
et t'as mis trois et
tu mets trois lignes et baf, ça marche
directement. C'est
super jouissif.
C'est super jouissif. Donc,
pour moi, c'est vraiment
le plus important, c'est la
maintenabilité et l'évolution, parce
qu'il y aura toujours des évolutions.
À part si tu fais du clean,
enfin du
code poubelle,
tu sais que ça va mourir dans un an
et la durée de vie,
bon, là, ok, tu fais du quick
and dirty et c'est pas grave.
Mais si tu sais que ce projet
a pour vocation de durée dans le temps
et aussi toi,
en tant que
commercialement parlant,
on sort de l'aspect purement
tech, mais commercialement parlant
que tu sois un depth free
ou en agence, bah en fait
ton code de potentiellement, c'est toi qui va le récupérer
quoi. Donc,
est-ce que t'as envie d'être sympa avec toi
ou tu te mets toi même des bâtons dans les roues ?
Donc,
ça, c'est
à toi de voir, mais c'est vrai que
parfois ça peut prendre du temps.
Après, sur l'internalisation,
ouais, moi j'ai
pas mal joué avec ça.
Ce qu'il faut garder le concept,
ce qui est le plus chiant, c'est ta première langue.
Voilà, c'est tout.
Après, que t'en es 2,
3, 4, 5, 7, ça change
strictement rien, parce que
le taf est fait en fait.
Donc, c'est pas gênant.
Et plus
tu fais ça tôt, et mieux
tu sais aussi.
Et plus t'as mis des clés,
en fait, tu internationalises
ton appli le plus tôt possible.
Comme ça, t'as mis des clés
partout. Et
tu as rentré
les clés de traduction.
Et ça, c'est peut-être
le truc le plus chiant à gérer.
Et après, une fois que t'as toutes tes clés,
t'as ton fichier
FR, t'as ton fichier
EN, t'as ton fichier
ES,
allemand, italien et tout ce que tu veux.
Après, ça marche
plutôt bien.
J'ai pas eu à gérer
le SIO
sur l'internatisation. Donc, je mets mon B-Mole
là-dessus, je pourrais pas en parler.
C'est vrai que maintenant, c'est assez simple.
On a des systèmes
d'internationalisation
qui sont assez faciles à utiliser.
Donc, c'est souvent pas trop compliqué à mettre en place.
Il y a des librairies qui font ça
très bien. Comme tu dis, c'est vraiment tout ce qui est
chaîne de caractère. Tout ça va faire en premier.
C'est vrai que sur une application qui est vraiment destinée,
t'es sûr à 100% que ça ne sortira jamais de la France.
Tu vas faire en français, donc là, peut-être pas
besoin de s'embêter.
Après, si tu as une application
que potentiellement, tu pourrais un jour passer
dans une autre langue, bah ouais, d'entrée, tu le fais
en multi-langue et puis voilà, c'est parti.
Une fois que la première langue est faite.
Avec,
avec, avec quand même
garder en tête aussi, qu'on aurait
tendance à faire de la suroptimisation.
Oui.
En fait, on dit, ouais, mais si je fais ça
maintenant, demain,
ça sera vachement plus facile.
Moi, maintenant, je reviens un peu,
tu vois, de ça,
parce que tu te fais souvent baiser, tu vas
dire, en fait, tu vas ouvrir des portes,
tu vas dire, ouais, mais demain, ça sera vachement
plus facile, ça sera bien.
Sauf que demain, en fait,
ça va pas se passer comme ça. Et donc, ça ne sert
à rien de faire de la suroptimisation.
Pour moi, en fait,
si tu sais que dans les,
tu vas utiliser que
une langue, bah, tu fais tout en une langue
et tu informes
tes clients que,
que le jour où il voudra passer
sur la deuxième langue, ou gérer les deux
langues, il y aura un effort. Par contre, la
troisième langue sera beaucoup plus facile à
faire, parce que sinon, ça peut
engendrer plus de taf au départ.
Sans, pour autant, en fait,
justifier le truc. Il faut toujours trouver le
plus de ce milieu et c'est difficile.
Ouais, c'est clair. Sauf que
tu t'exposes
à ne serait-ce que poser la question aux
clients, dire, est-ce que ça sera
multilangue ? Et là, le mec, peut-être
un jour, mais on n'est pas sûr et tout. Alors
là, c'est bon. En fait, il ne s'est plus.
Bah bon. Il faut pouvoir la boîte de
Prendor, comme tu dis. Ah ouais, je voulais
revenir vite fait sur la première question,
sur, en fait, la
mentalité. C'est aussi, ouais, c'est qu'au
début, en fait, des fois, il faut savoir
perdre du temps au début du projet
pour le futur, en fait, pour
pas perdre du temps dans le futur. Et pareil
pour tout ce qui est test, en fait, faut pas
en fait, c'est vachement important quand même
de faire un minimum de tests au début
quand tu fais le projet, etc. pour que dans
6 mois, 1 an, quand tu viens modifier
des choses, tu puisses t'encer les tests et
voir si ça a pété des trucs, en fait, tout simplement.
Et quand tu fais ça un an après,
tu te remercies
d'avoir fait des tests. Parce que là, tu vois
que t'as pété un truc et si tu n'avais pas
fait, et bien t'aurais jamais pu le voir
et tu l'aurais mis en prod avec un truc cassé.
Voilà.
Pensez au futur.
Mais ce qui est sûr,
c'est que la structure
et la rigueur, on va dire, un petit
peu,
sur ton organisation,
de tout efficher, c'est ce
qui va conditionner beaucoup, beaucoup, beaucoup
de choses. Et pour le coup,
on voit vraiment ça, on voit une différence
entre un junior et quelqu'un qui est
expérimenté. Juste comment il a
structure et ses fichiers, comment
c'est, quelle convention de nommage il a appelé
les choses, tu vois.
Ça, c'est, tu le vois,
tu vois vraiment.
Petite anecdote de quand j'étais,
quand j'ai commencé le développement il y a très
longtemps et je faisais que du PHP à l'époque,
j'avais fait un projet dans une boîte,
c'était mon premier job en fait à Lyon
et j'avais fait un projet
et j'avais tout balancé, en fait, tous les fichiers
étaient à la racine, mais vraiment
bordel complet. Et là,
le dev qui était plus ancien que moi et tout,
il a commencé à regarder le truc, il disait, mais c'est quoi
ce bordel en fait ? Et j'avais du tout re-ranger
dans des dossiers et tout, c'est pareil. Il m'avait
fait tout re-ranger correctement. Donc, je me souviens
de ça, tu vois, et puis je pense que ça m'a servi
par la suite, tu vois,
junior, la différence avec un junior
et le seigneur de la...
Et anecdote
pareil, chez un client, j'arrive
deuxième jour et en fait, il monte la
code base, ma chance, c'était
une app Express
avec, je crois qu'il y avait 7000
ou 8000 lignes dans le index.js
avec Express,
quoi. En fait, il avait tout mis
comme ça. 8000 lignes.
Ouais. Et là, il fait mais c'est
qui qui a codé cette merde texto ?
Et en fait, le mec, il me regarde
c'est moi.
Et là, en fait,
c'était super, super
fru... Enfin, malaises,
malaises.
Après, tu dégonfles pas, de toute façon
tu dis, ok, de toute façon, il y a
deux possibilités, soit tu me vires
parce que j'ai été cruel
et peut-être pas diplomate.
Par contre, le problème va rester entier
pour toi. Bon, ok, moi j'ai perdu
ma mission, tant pis, je m'en remettrai.
Soit en fait,
on analyse
ce qui va pas et on regarde
la différence entre
là où t'en es aujourd'hui et là
où sont tes ambitions sur
l'appli, quoi. Et puis on travaille ensemble.
Mais bon, après ça, ça a soit de voir,
quoi. Il est sorti.
Alors, il est sorti, il a pris
deux minutes, il est revenu, il a dit
bon, merci, c'est bien.
Ok, on
on attaque. Et donc, j'ai bossé avec eux,
j'ai bossé quasiment six mois et j'ai refait toute l'appli
et j'ai fait plus avec
eux encore après donc
c'était un peu cruel, mais
ça marche. La vérité en même temps.
Ouais, exactement, exactement. C'est
très très très pragmatique.
Disons que si t'avais su que c'était lui qui avait codé,
t'aurais peut-être été plus gentil. Exactement.
Tu n'aurais pas rendu service peut-être. Exactement.
J'aurais été plus diplomate, je pense que ça aurait
été sans doute
mieux.
Question de
FourHitch48.
Plusieurs questions en fait qui
pour le coup
sont liées à de l'intégration.
Donc, c'est vraiment, je reçois la maquette
en tant que développeur. Je vais résumer
la question, elle est un petit peu longue.
En tant que
développeur, intégrateur, je reçois la
maquette.
Quelles sont en fait les premiers éléments
que je vais regarder ? Comment je vais créer
mes divisions ?
Comment je vais utiliser mes balises sémantiques ?
Quel est la bonne
méthode, en fait, pour
essayer de variable
tout de suite les espaces,
les couleurs
et que ça reste proble
et évolutif.
En clair,
quelles sont les étapes du process
pour que
gérer l'intégration complète
d'un template ?
C'est pas compliqué.
Ça dépend déjà si la personne qui a fait la maquette
a des notions de web ou pas du tout.
Blame le designer
déjà. Blame le designer.
C'est une maquette d'un designer print.
C'est la cathare, parce que ça n'a rien été
pensé correctement. Après, si t'as un
designer plutôt web qui utilise Figma,
la personne t'aura découpé des éléments
et d'heures, footers, etc.
Donc t'auras des components et tout ça.
C'est assez facile. En général, c'est assez facile.
Le header, le footer, c'est
identifié assez rapidement. Main,
c'est le conclu principal.
Au niveau des balises sémantiques, c'est pas très compliqué
à découper.
Comme je dis, souvent,
si t'as un vrai web designer,
il t'a découpé les choses correctement,
déjà, t'as déjà des components, tout ça,
qui sont vraiment séparés, tout ça.
Tout dépend comment tu refais la maquette.
Effectivement, si c'est
une maquette à l'ancienne, tout d'un bloc,
c'est à toi de découper
les éléments et de dire,
ça, c'est ça.
Ça doit faire le job. Après, tout ce
qui est couleur, etc.
c'est variable
au maximum.
CSS variable maintenant,
c'est hyper généralisé.
Variabilisé au maximum dans le CSS,
les couleurs, les marges, etc.
Ça permet d'avoir
une meilleure maintainabilité dans le temps
et de pouvoir changer
juste dans une variable. Ça va changer dans tout le code,
ou de craser, ou de varider.
On revient toujours au même point.
C'est toujours bien structuré.
Après,
ça,
ça sera propre
à toi et ça sera ton choix
d'utiliser Tailwind ou pas.
Mais l'avantage maintenant,
c'est que dans Tailwind, tu vas pouvoir
créer un thème. Et dans ce thème-là,
tu vas écrire tes propres règles.
Et toi,
tu auras une sorte de consistance
partout.
Moi, je considère,
mais ça n'engage que moi,
je considère que c'est plus facile de
garder une consistance avec Tailwind
qu'en CSS pure.
Mais peut-être que je suis mauvais
en CSS et je peux l'admettre.
Mais
au moins, tout est
normalisé
et toujours la même chose.
Donc, ça sera beaucoup plus facile.
Par contre,
est-ce que tu vas utiliser
du flex, du grid ?
Ça va être
toi et ta propre
compétence
sur lequel t'es plus à l'aise
de la compétence.
Grid, ça apporte quand même beaucoup
d'avantage.
Par contre, il faut maîtriser
tes flexbox. Je ne sais pas
à quel point tu en es
dans ton apprentissage.
Mais maîtrise déjà bien les flexbox.
Une fois que tu maîtrises bien les flexbox,
tu peux passer sur Grid. Ça sera beaucoup plus facile.
Tu auras un petit switch à faire,
mais ça sera beaucoup plus facile.
La qualité
de tes maquettes
va te faciliter la vie
de ma boule.
Ah bah oui, ça change tout.
Mais maquettes, c'est la base.
Mais après,
c'est aussi important d'échanger
en amont avec le designer
pour se mettre d'accord sur comment
il doit structurer le fichier, les couleurs, etc.
Parce que
c'est
un gros travail.
Actuellement, je travaille sur
l'intégration d'un design-système
avec
une base de CSS
avec tout le design-système,
les couleurs, etc.
Les tailles de titres, etc.
Et franchement,
ce n'est pas simple.
Ne serait-ce que pour trouver les noms,
les bonnes couleurs, etc.
Primeries, ou accents,
ou ce qu'on met là, machin, tu vois.
Il y a des échanges continuels là-dessus.
Ça prend beaucoup de temps.
La vérité absolue n'existe pas en fait.
Ça dépend des préférences.
Allez, question suivante.
Lina
Bouddali M5S
Désolé
si je décorche le nom.
Alors, pour le coup,
quel conseil donnerait-vous
un jeune
développeur récemment diplomé
d'une formation pour décrocher un emploi ?
Les formations en ligne, bien qu'utiles,
ne fournissent pas toujours les outils nécessaires
pour être pleinement opérationnels
et dits employables.
On se concentre principalement sur les bases
mais la véritable progression repose sur un apprentissage
continuant souvent en autodidacte.
Je pense qu'on ne peut que
abonder dans ce constat-là.
Ah bah oui.
Quel serait votre conseil pour intégrer un secteur aussi compétitif
que celui du développement, particulièrement
dans le contexte actuel, où la concurrence est forte
pour l'interrogation.
Que recommandez-vous en termes de routine,
méthodologie, d'approche
quotidien pour maximiser ces chances
de réussite ?
Voilà.
Vaste question.
Ouais.
C'est pas simple.
En plus, toi,
si je ne sais pas si tout le monde le sait,
mais toi, tu es formateur aussi dans une école,
donc tu participes à la formation
de pas mal de futurs développeurs.
Moi, personnellement, je trouve qu'aujourd'hui,
on forme trop de développeurs.
C'est mon avis, je ne sais pas si c'est d'accord,
mais je trouve qu'on forme trop de développeurs
et on se rend compte, enfin, si tu suis un petit peu
les réseaux sociaux, tout ça,
il y a beaucoup de juniors aujourd'hui qui ont du mal
à trouver un emploi. Alors je pense qu'on leur a vendu du rêve.
C'est malheureux, mais en tout temps,
c'est la formation,
les écoles de formation de Web, tout ça.
C'est leur business, c'est vendre des formations
et voilà, c'est ce qui vende, en fait.
Donc il faut qu'il fasse de l'argent, donc il vende du rêve.
Malheureusement, aujourd'hui,
il y a peut-être besoin de moins de développeurs,
donc c'est vrai que c'est un peu plus complexe
pour quelqu'un qui est junior et il cherche, apparemment,
de ce qu'il se dit, plus de seniors,
de gens qui sont de suite
prêts à bosser, tout ça.
Alors c'est dommage parce que souvent d'embaucher
des juniors, c'est bien aussi parce que tu vas les former,
tu vas les faire grandir et après, voilà,
ils sont bien, si tu les payes bien,
tu t'occupes bien d'eux, ils vont rester, peut-être,
ou partir, mais bon, dans tous les cas,
voilà, tu les formes, c'est toujours intéressant
de former comme on l'a dit déjà avant.
Donc c'était quoi la question déjà ?
Après,
qu'elle serait...
Alors, pour le coup,
moi je peux mettre
ma petite pierre à l'édifice qui est sûre,
c'est que rester employable,
quand tu sors de formations,
souvent des formations
continuent, ou en un an,
ou en deux ans,
toutes les formations dites
reconversion, tu vois, ou...
Malheureusement, pour moi,
tout le monde ne peut pas être développeur.
Et j'ai été formateur sur
des écoles comme ça,
il y a des erreurs de casting
au départ, qui sont monumentales,
mais monumentales,
mais pour des raisons de financement,
d'organisation, mais on peut pas
faire la formation si on n'est pas douze.
Donc, il n'y a que...
on va prendre les douze, même si
le douze, le onze, ou le douzième,
il est un peu limite,
on va le prendre quand même.
Et pendant un an, parfois 18 mois,
on va lui bourrer le mou,
en disant, non, mais il faut travailler,
il faut travailler, il faut travailler.
Mais tout le monde n'est pas
en capacité
de devenir développeur. Ça, c'est un fait,
déjà. Ça, c'est sûr et certain.
Ok.
Après, deuxième chose aussi,
sur ces formations, on
brosse hyper large. Donc, on voit plein de choses.
Derrière,
en fait, tu sais faire beaucoup de choses,
mais tu sais pas
faire tout bien nickel, quoi.
Et donc, moi,
mon approche, en fait, elle serait de se
spécialiser. Même si
j'ai dit complètement
l'inverse avant,
je pense aujourd'hui qu'on
a plus besoin de spécialistes.
Et donc, tu choisis ton
arme, tu vois.
Clairement, quand j'entends un mec
qui sort de formation, qui a moins de 2 ans
d'expérience, il y a 2 ans
il connaissait même pas le code, et
il fait du PHP, du Python,
du JS, du React,
du Next, et du SQL.
Wow,
je fais putain, soit t'es une putain de
machine, ce qui est possible.
Soit, en fait,
tu n'as fait que caresser
les choses, quoi.
Et la plupart du temps,
c'est ça. Donc, en fait,
l'apprentissage, ça prend du temps.
Donc,
choisis ton arme, et évite de faire
des switches dans tous les sens, en disant
je vais faire du PHP, après
je vais faire du JS, 2 mois après
je vais faire du Python, tout.
Non, tu choisis ta techno,
tu choisis ton langage, tu fais ça
pendant longtemps,
et tu bouffes des projets.
Et t'es confronté à la réalité
pour vraiment monter
en compétences
sur un sujet, et là,
en fait, tu vas gagner
en employabilité.
Autre point aussi, tendance actuelle.
Je vais pas me faire des amis aujourd'hui,
mais c'est pas grave, j'assume.
On n'est pas là pour ça.
Tout ce qui est
formation
ou bouquin
pour passer les tests
d'entretien.
On te forme à te passer
des tests d'entretien.
Cela, ça marche
sous couvert que tu as compris
de quoi tu parles. Parce qu'en fait,
si tu ne fais que
régurgiter ce que la personne a envie
d'entendre, oui, potentiellement,
tu vas potentiellement passer le test.
Mais au final, tu vas te faire bouler plus tard.
Parce qu'en fait, on va te rendre compte,
à un moment donné, ton employeur
va se rendre compte que
en fait, tu manques
de cruellement, de fondamentaux.
Donc, être capable
de passer le test d'entretien
de Google, parce que tu as appris
par coeur la réponse et tu sais que
c'est ça qu'il faut faire, ou c'est ça qu'il faut dire.
Et voilà, parfait, parfait.
Mais, là tu es vraiment compris.
Et c'est là, en fait,
toute la subtilité,
c'est que s'il y a des tests techniques,
le but, c'est pas
de te mettre en échec volontaire.
C'est juste de garantir
un socle
minimum technique, minimum.
Après, est-ce que
le test est bien fait ?
Ça, je veux dire,
ça, ce n'est pas ton problème.
Est-ce que
eux, ils ont fait
des tests techniques pertinents ?
Peut-être pas, mais
tu sais pas. Donc, te former spécialement
pour passer ces tests techniques,
pour moi, c'est une hérésie
si
tu n'as pas compris le sujet
principal. Donc, boss
ton sujet principal et tu n'auras pas besoin
de te former à passer des tests,
à passer les tests techniques.
Et, autre point
sur les tests techniques, et j'en finirais là.
Je pense, aujourd'hui,
que les tests techniques sont importants
soit, mais
tout le côté
soft skills, en fait,
prend d'autant plus sa valeur.
Clairement, un mec
qui a des compétences de ma boule,
c'est un tueur en SQL, tout, mais
impossible de lui parler.
Impossible de travailler
en équipe, il répond jamais,
il a un comportement
très très très bizarre,
il a pas envie de monter en compétences,
tout. Soit
il est méga high skill, et j'ai vraiment besoin
de ses compétences, dans ce cas-là, oui.
Par contre, quelqu'un qui est
un peu moins compétent, mais
qui va s'intégrer dans l'équipe, avec qui
on peut discuter, on peut échanger, qui a envie
d'apprendre, qui est dans un bon mood,
tout. Ben, ouais,
je pense que ça, ça peut vraiment jouer
en la faveur. Donc, je pense
qu'il n'y a pas que les hard skills,
il y a les soft skills aussi, qui jouent
indéniablement.

ça fait partie intégrante.
Et pour moi, je pense
qu'on rentre dans l'air du temps
où
les soft skills prennent tout, tout, tout
leur valeur, quoi. Donc,
c'est pas...
Compétent, aujourd'hui c'est ce qui fait la différence
entre plusieurs candidats,
voilà, comment l'entretien s'est passé,
comment la personne réagit, tout ça, s'il est ouvert.
Et puis après derrière, travail en équipe, c'est
hyper important quand t'es intégré dans une équipe.
Si dès que quelqu'un lit à PR et te dit
« ça, ce code, ça va pas, tu le prends mal, tu commences
à t'énerver et tout ça, ça va pas
durer longtemps, quoi. » Donc, c'est
capacité de, voilà, d'apprendre
d'accepter qu'on n'est pas
parfait, que notre code, des fois, il y a des erreurs.
Donc, on accepte les critiques des
autres, accepte et puis évoluer.
Comme tu dis, aujourd'hui, ouais, c'est clair qu'on est
dans une air où les soft skills sont plus importants
que les, enfin, personnellement, moi, j'ai
déjà fait des recrutements dans
des boîtes d'avant et j'ai toujours recruté
plus sur les soft skills que sur
les compétences réelles parce que je sais que la personne
s'il a envie d'apprendre, elle va
monter en compétence et ça prendra peut-être
un peu plus de temps, mais au moins
tu sais que, voilà,
ce se passe bien et que tous les jours, voilà.
Et au quotidien, c'est
tellement plus facile à gérer,
tellement plus facile, plus
facile à gérer. Un des boîtes
où j'ai bossé le boss, je disais toujours,
pour savoir, en fait,
si tu peux
travailler avec quelqu'un ou quelque chose,
ou embaucher, il disait, tu t'imagines
si, est-ce que tu pourrais faire un long
trajet en voiture avec cette personne, en fait.
Voilà. Tu vas discuter.
Et là, déjà, tu te réponds pas mal
à la question.
Mais question
très difficile
et légitime
et on entend et on voit et on lit
de plus en plus
des personnes qui sont dans ta situation
et
c'est compliqué. Mon conseil
assez court, mais
c'est toujours difficile de
donner conseil, tu vois, parce que je suis pas
dans ta situation
avec ton bagage, donc c'est
toujours difficile.
Moi, j'aurais plutôt tendance à
essayer de me focus sur
une techno, un skills
et je mets all-in dessus.
Mais c'est aussi
ma personnalité
qui parle, tu vois, peut-être
que toi, t'es pas en raccord avec ça
et donc
c'est très très très difficile
de donner des conseils en tout cas.
Ouais, mais en fait, non, mais t'as raison.
Choisir une techno et se focus
là-dessus et être bon. Alors, une techno
qui est demandée, parce que...
Bien sûr, évidemment...
Va pas faire du cobble.
C'est un choix, c'est aussi un choix
potentiellement, mais...
Ouais, une techno, surtout quand
t'es junior, donc essayer de te spécialiser
dans une techno et de la maîtriser, et puis
une techno qui est demandée et là, peut-être que tu te crois
déjà un premier job. Ce qui est important
aussi, parce que je reviens
sur le truc, en apprentissage continu.
Oui, notre métier, développeur, c'est
en apprentissage continu, c'est-à-dire
que... Enfin, j'imagine que c'est pareil, mais...
Ah oui, clairement. Je faisais il y a
15 ans, c'est pas du tout la même chose qu'aujourd'hui
et j'apprends tout le temps, en fait, personnellement
et là, en ce moment, je fais du piton pour faire
de l'IA, etc. Voilà, j'apprends
tout le temps, on apprend tout le temps, c'est...
Et c'est aussi ce qui cool dans ce métier, c'est qu'on
en évolue tout le temps, on apprend plein de choses et tout
et ça, c'est génial. Donc on reste pas
figé sur une seule chose, une seule techno
et... Ça, c'est important.
Et pour le premier job, je dirais...
Peut-être...
Ce qu'on vous a vendus, à la base
dans les écoles, où les formations, je sais pas
quoi, vous avez les gagnés, je sais pas combien, par mois,
3 000, 5 000 euros, peut-être
mais vous pourrez revenir un petit peu à la base.
Visé peut-être un job
dans une agence plus simple, peut-être moins bien payée
mais ça vous fera votre première
expérience et après, vous verrez viser
un petit peu plus haut, donc... Alors après, c'est facile
hein, il faut déjà trouver le premier job
mais c'est pas
évident, souvent, mais
peut-être viser un petit peu moins haut et se contenter
d'un premier job, c'est ce que j'ai fait, personnellement
j'ai accepté quand j'ai fait ma
reconversion à l'époque et c'était pas comme aujourd'hui
de gagner moins d'argent, mais ça m'a
permis de mettre le pied
à l'étrier et puis voilà. Après, derrière
j'ai pu avoir d'autres jobs, mieux payés.
Allez, question
de Nico Mildev
j'adore, existe-t-il
un décalage entre les outils dont vous parlez
est-ce qu'il est
est-ce qu'il est réellement utilisé
en entreprise ?
En clair, Patrick, est-ce que
t'es pas en train de nous vendre
mito, machin, mais que toi-même
tu n'utilises pas ?
Et Nico, on ne dit pas que t'es mito
on ne dit pas que tu nous prends pour
des mitos, on n'est pas des mitos
Non, pour le coup
moi je peux te répondre
clairement, il y a
plein de sujets sur l'actualité
où
on est curieux
on va regarder la techno
par contre
on ne va pas l'utiliser
un exemple typique
j'ai appris avec Gritsum
je pense que toi t'as appris avec Gatsby
où on a fait des
sites en prod
pour des clients et aujourd'hui la techno
elle est morte, c'est terminé
c'est fini, il n'y a plus rien qui est évolué
là-dessus
donc il y a aussi
ce côté là où
est-ce que la techno est suffisamment
mature pour pouvoir
la déployer chez un client
à l'inverse
dans les actualités
là on va parler de toutes les
ferversances qu'il y a
et on est les premiers à dire encore un framework
et est-ce qu'on va tous les utiliser
en prod chez les clients ?
Non, clairement pas
parce qu'on va regarder la maturité
l'évolution
le taux d'implémentation
et la stabilité
moi ce que je regarde aujourd'hui c'est la stabilité
de la techno
est-ce qu'elle est mature pour être en prod ?

oui de toute façon c'est clair
c'est ça, soit le client
ça en fout et ça te fait confiance
donc ça va toi de choisir la techno
généralement choisir un truc qui est fiable
après souvent des fois les clients
peuvent poser la question est-ce que c'est fiable
la techno qu'on part, d'ailleurs Next.js
sur un projet qu'on a fait
qui est 3-4 ans
au début
le responsable
qui m'a dit est-ce que c'est fiable de Next
est-ce que dans 4 ans ça sera encore là
j'ai dit oui, oui, pas de problème
et aujourd'hui ça marche encore le projet de tournage
il est toujours maintenu
des technos fiable
mais c'est vrai qu'il y a tellement dans les news
on a tendance à parler de nouveautés et tout ça
mais il y a des choses, tant que c'est pas mature
il faut pas les utiliser en prod
parce que si à chaque montée de version
tu dois refaire la matière du code
c'est pas du tout rentable
ni pour toi, ni pour qui
par contre, tu vois ce qui est
ce qui est
ce qui est par contre
intéressant c'est
sur ces nouvelles techno en fait
de toi faire un petit side project avec
pour tester
tu fais un petit pogue, tu fais un truc à la con
juste pour tester, pour monter en compétence toi
ça te permet aussi de voir
est-ce que tu arrives
à te projeter avec tes clients
là-dessus, à faire des
des transitions potentielles
ou pas mais
ouais c'est quand même pas mal
de pouvoir tester
avant de jouer en prod
sur une techno quoi
moi je vais pas sortir
une techno du chapeau
avec un client
s'il y a un enjeu commercial trop fort
je vais pas sortir
une techno ésotérique
vraiment
après c'est bien de tester
les techno
même si c'est pas pour pointer en prod
j'ai testé la version 2
comment ça s'appelle
e-commerce
Medusa ouais
je me suis invité avec la version 2 de Medusa il y a 2 semaines
ou il y a une semaine je sais plus
pour voir comment ça fonctionne tout ça
j'ai suivi le tuto tout ça c'est toujours intéressant de tester
pour voir éventuellement si c'est matur
si ça peut convenir un projet
c'est bien de se tenir au courant
et de tester
sur des trucs, des petits tutos
peut-être que Nico
il est peut-être
il y a un petit
gégère entre développeurs PHP
le JS
souvent les développeurs PHP te disent
non mais vous nous faites chier
faut faire du PHP c'est stable
ou du rubis
peut-être que Nico fait du PHP
il nous emmerde avec le frère morgies
oui bien sûr
après c'est
c'est la gégère permanente
ça sera la gégère permanente
de toute façon
aujourd'hui
comme dans tout milieu
on est bercés par l'idéologie
et l'idéologie a plus
de valeur que le pragmatisme
à mon grand des arrois
mais c'est comme ça
non mais après voilà non
moi je fais du PHP du JS
et donc PHP c'est très valable
la Ravel, la Symphonie
c'est bien, c'est très bien
et tout ce qui est JS aujourd'hui c'est très matur aussi
Next, Next etc
réactue vu tout ça c'est matur
donc tout peut être utilisé en prod
et ça recoupe
un peu la question
suivante de Cycloper
000
comment vous faites pour évoluer en tant que développeur
quelles sont les stratégies
pour faire votre veille
et améliorer votre compétence
théorique, pratique, algorithmique
comment on organise notre veille
YouTube, Twitter, Blog
Doc
et
diffancer les sources
et comment on s'organise
dans notre emploi du temps
pour ne pas être subbergé par la masse
d'informations
parce que ça évolue super vite
ça recoupe un peu
là peut-être comment
toi tu fais ta veille
c'est quoi tes choses
beaucoup sur Twitter
Blue Sky maintenant j'ai envie de dire
j'en train de migrer un petit peu mais je reste pas quand même sur Twitter
pendant un moment parce que c'est pas encore la migration
totale
YouTube c'est chaud parce que t'as beaucoup
de bullshit de vidéos
ou les mecs qui vont faire juste un Hello World
et finalement ils ne maîtrisent même pas le truc
donc j'en peux plus
j'en peux plus
c'est souvent difficile de trouver
des vraies vidéos intéressantes techniques
sur YouTube mais ça se trouve
oui il y en a
beaucoup de Twitter qui te renvoient
forcément vers les documentations officielles
souvent parce que c'est des comptes officielles comme React
et après tu vois un lien
tu cliques, tu lis un peu la doc
c'est beaucoup des choses comme ça en fait
moi je trouve
c'est vachement par phase
en fait
là pour le coup
transparent
moi je suis dans ma phase SQL
tu vois je suis en train
de...
il faut savoir qu'il a des phases Alex
ouais exactement
mais tout ce qui est DB ça fait un moment que ça dure
en fait j'ai eu ma phase Redis
et pour le coup
je suis vraiment fan de Redis
je pense à avoir bien poussé
même si on peut toujours pousser Redis encore plus
on est complètement d'accord
mais là je suis dans ma phase SQL
et en fait
bah ouais tu ponces le sujet
tu reviens
et tu lis la doc
tu vas lire des vidéos techniques
ou enfin non tu vas regarder
des vidéos techniques
il pras pousser
sur...
pour le coup comment tu vas faire
des triggers, comment tu vas
déclencher des triggers qui vont
lancer des fonctions, qui vont appeler du code
enfin tu peux aller super loin
et puis après
j'aurai une autre phase où je vais passer
autre chose donc
ça se fait un peu naturellement
et par contre ce qui est sûr c'est que
tout ce que tu apprend
en fait ça te sert pour ton
prochain projet quoi
parce que ça te sert toujours
toujours toujours donc
aujourd'hui moi je viens plutôt de l'univers
Front
donc je bascule plutôt côté
serveur, algo
et DB
et là pour l'instant je suis dans ma phase
DB
même si tu vois je viens de prendre
une mission où je vais déployer
tout l'archi
pour mon client
et donc je dois
ouais mais je fais mes choix
aussi stratégiques en disant que ok
moi je peux pas gérer Kubernetes
et
AWS et tout le bordel et tout ça
donc je fais des choix stratégiques
aussi pour pouvoir gérer le truc
donc
comme on disait tout à l'heure
le fait d'être indépendant on a
plus de souplesse on est moins tenu
par
cette rentabilité horaire en fait
si on dépasse on dépasse
à toi
de bien vendre quand t'es un dépe
de bien le vendre comme ça
t'as pas de pression
financière et moi
je trouve ça super cool que mon client
il paye ma montée en compétence
quoi
donc c'est plutôt cool
après comment j'organise
mon emploi du temps
je sais pas t'as un
secret magique
pour pas te le subir
je vais te demander à ma femme tu verras
ouais c'est ça
non j'ai pas l'organisation
ça dépend aussi des projets si je suis super occupé
ou pas évidemment si j'ai
des choses en cours je peux pas s'appliquer
mais je vais te donner une question
sur les projets clients
actuellement
je suis plus cool depuis une semaine
donc là je travaille sur
moi je suis dans ma phase IA
donc voilà
j'ai en train d'apprendre comment ça fonctionne
exactement etc
je me fais une face
du piton alors que je suis complètement
débutant un piton mais bon
c'est pas un langage qui est compliqué
mais ça ça prend

mais je sais que ça sert pour le reste
parce que je me souviens quand j'étais plus jeune développeur
j'avais
je faisais beaucoup de PHP et tout ça
j'avais un moment donné fait de l'action script 3
qui était pour flash
et action script 3 m'a appris la programmation
donc ça m'a servi après pour le PHP
comme je faisais de l'objet tout ça
donc voilà quand tu apprends des choses ça te sert aussi à d'autres langages etc
puisqu'en fait finalement
les langages sont à peu près tous pareils
transferts
transferts
voilà voilà
yes
Quentin qui est venu
avec beaucoup beaucoup de questions
qu'on va peut-être regrouper avec des questions
suivantes
mais
grosse tendance
c'est quoi la
grosse tendance
pour nous en ce moment
ça serait quoi
la tendance actuelle
tendance
sur quoi ?
sur le
js
c'est quoi la tendance du moment
le projet du moment
le truc
moi je peux répondre
déjà sur le fait qu'on essaye
et je pense que tu partages
mon avis
c'est qu'on essaye
de voir la différence
entre la hype
le bruit
et
une véritable tendance
une tasse de quelque chose
du bruit du signal
le signal il y a quelque chose
le bruit ça brasse
il y a pas grand chose
est-ce qu'il y a
juste du bruit non
je pense qu'il y a vraiment une tendance
l'assistant
pour les devs c'est une vraie tendance
l'IA va rentrer dans tous nos logiciels
voilà
ça c'est quasiment sûr
et aujourd'hui
ma mère connait chat gpt
donc c'est un signe de dire
qu'il y a un taux de pénétration
et de maturité
de la globalité des personnes
pour ok elle ne sait pas coder
elle ne sait pas utiliser un prompt
elle sait ce que c'est
et donc il y a une acceptation
du mass market
qui va faire que donc ça c'est une vraie tendance
est-ce que
nous on peut en profiter en tant que devs
oui indéniablement
et je pense qu'on va
faire un épisode là dessus
ça fait plusieurs fois qu'on le dit
qu'on va faire un épisode
d'EB, enfin pardon
un épisode devs IA
et comment nous développeurs on peut intégrer
l'IA dans nos logiciels
c'est quoi les...
alors qui est question plus spécifique
c'est quoi la suite
de double slash
c'est quoi les projets dans les tuyaux
de double slash
c'est quoi la suite
ben voilà
c'est quoi la suite
bon on aimerait avoir plus de temps
mais bon le problème c'est que
sinon on aimerait faire plus
de workshop on aimerait faire des
formations etc évidemment
mais ça ça fait un petit moment donc il faut que
on arrive à libérer plus de temps
et
pour faire ces choses là
et déjà un moteur de recherche
tu vois comment on l'a dit
sur 2025
un moteur de recherche
sur le site
ça pourrait être pas mal
on va garder la question pour la stack
parce qu'il y a une autre question
qui est un petit peu sous-jouant
suivante derrière donc
on pourrait
revenir
my own puffer fish
comment vous arrivez à gérer
la pression quand vous avez des gros projets
qui prennent du retard et qui s'accumulent
le sport
et comment vous lancez
dans un projet avant de vous apercevoir
qu'il vous dépassent
si cela arrive
la pression au moment
j'ai la gère mal
donc comme je dis
le sport ça me permet d'évacuer
parce que si je fais pas
des fois
c'est souvent les clients qui te mettent la pression
déjà la première chose je me dis
calme toi on n'est pas médecin
on sauve pas des vies donc c'est bon
c'est des applications web, c'est des sites web
ça va pas changer la phase du monde si on prend un peu de retard
déjà la première chose faut relativiser
par rapport à ce qu'on fait
après évacuer si vraiment il y a trop de pression
évacuer avec le sport
prendre du recul aussi
c'est des fois on se cépide et on commence à faire n'importe quoi
c'est nerveux donc c'est de prendre du recul
et puis la question
si ça dépasse
ça peut arriver que le projet
c'est plus compliqué que ce qui j'imaginais
ma technique
c'est de prendre step by step
c'est à dire que
j'y vais étape par étape
si le truc est vraiment ambitieux
je commence par faire ci
et petit à petit avance
en faisant des petites choses par ci par là
et puis à la fin tu arrives à finir
mais faut vraiment se concentrer
sur l'étape que tu es en train de faire
et pas penser au projet global et puis essayer d'avancer
petit à petit paradrique
voilà
pour le coup j'adhère complètement
j'arrive sur la fin
d'un énorme projet que je suis
depuis quasiment un an
alors pour le coup moi ça m'a pas mis la pression
toi qui a mis la pression client
exactement
pour le coup
et par contre sur la gestion de retard
je pense que le plus important
c'est de communiquer
et en fait
plus tu communiques en amont
plus tu es transparent
en disant on va avoir du retard
on a
ou aussi
si le client a du retard
parce que ça arrive souvent aussi
ou en fait eux ils nous demandent une extrême rapidité
alors que eux
ne se sont pas respectés les délais
donc en clair de communiquer en amont
sur
le 10 du mois
vous nous avez envoyé les données
le 20 vous allez avoir
votre première version
si le 12 ils n'ont pas envoyé
tu communiques tout de suite en disant
vous avez croqué
toute votre marge donc nous on ne peut plus
assurer le délais
et en fait plus tu viens communiquer
en amont plus c'est facile
pareil ici
si ça n'avait pas été prévu
d'une date
et toi tu vois que tu ne vas pas sortir
tu appelles tout de suite ton client
ou le chef de projet l'appelle
mais
faire l'autre ruche et rien c'est encore pire
en fait donc
plus tu viens communiquer en amont plus c'est facile
vraiment
pareil sur des merdes, des complications
tu informes tout de suite ton client
et en fait plus
tu informes tôt sur des trucs
parfois insignifiant
plus en fait
il est décontracté parce que
la majorité des clients
ne comprennent pas notre métier
c'est complètement abstrait
c'est fumeux tout et tu dis
ouais mais en fait j'ai mon serveur
j'ai galéré pour le déployer tout, lui il comprend pas
il s'en fout, il n'entend pas
et lui il entend nia nia nia nia nia
et donc en fait
plus tu lui expliques les choses
et dans son vocabulaire
à lui en disant voilà j'ai rencontré
des problèmes
je pensais être capable de faire ça
en 10 jours
je constate que au bout de 10 jours c'est toujours pas fini
il me faut tant de jours de plus
est ce que t'as géré
à la journée, au forfait, voilà après
il y a toute cette notion commerciale par contre
ce qui est sûr c'est commercialement
si t'attends le dernier moment pour dire qu'il y a
du retard c'est encore pire
parce que t'as perdu toute crédibilité
et donc plus t'as anticipé ça
plus tu passes pour un pro
en tout cas pour moi
et plus ça passe mieux avec ton client
ouais tout à fait
t'as raison
communication c'est hyper important
t'as bien fait de me rappeler
parce que c'est
communiquer au maximum avec le client
parce qu'en fait il faut éviter toute rupture de communication
parce qu'à un moment donné si jamais tu communiques pas bien etc
tu arrives, j'ai du retard
et là tu peux risquer un rupture de communication avec le client
et c'est là où ça sent venu
il m'en fait les choses et
donc c'est hyper important de toujours communiquer au maximum
quoi et je voulais vite
enfin revenir vite fait
dans les agences souvent
si vous le faites pas, si vous
ceux qui écoutent là, les auditeurs, auditrices
vous êtes dans une agence et vous faites pas ça
essayez de le faire, c'est que tous les matins généralement
il y a un délit, voilà on arrive à 9h
il y a le délit à 9h15
tout le monde se connecte ou se voit dans une salle de réunion
et dit ce qu'il fait aujourd'hui, ce qu'il a fait hier
et dit éventuellement
sur quoi il est coincé etc
pour que d'autres devs viennent l'aider
pour une feature qu'il arrive pas à faire etc
et ça c'est hyper important parce que ça aide
à se décoincer, ça communique etc
donc si vous êtes dans une agence aujourd'hui ou dans une boîte
où vous ne faites pas de délit, essayez de commencer à en faire
parce que c'est important de communiquer sur les endroits
où on est coincé dans le code etc
ou alors s'il n'y a pas un délit d'être aussi
en capacité de verbaliser
son problème, de dire là
help, help et n'attendez pas
et pour le coup toi je sais pas
si ça t'arrive parfois
mais moi je bosse beaucoup seul
et en fait parfois quand t'es bloqué
sur un problème c'est très difficile
en fait tu vois parce que j'ai pas
un lit d'œuf qui dit
hey mec, ça serait cool
mais là c'est pas le cas
et donc savoir s'entourer
savoir discuter avec d'autres personnes
si t'es freelance par exemple
de discuter avec d'autres freelance
que ça soit technique, que ça soit
commercial, que ça soit marketing
si toi tu te vends tout seul
tu dois couvrir tout le spectre
du métier et donc
discuter avec des homologues
ou des compères
ça va vachement t'aider si t'es seul
et si t'es pas en équipe
si t'es en équipe, joues l'équipe évidemment
clairement. Ouais, être sur des
Slack ou Discord pour aller discuter avec d'autres devs
tout ça, sur des problèmes etc
trouver si quelqu'un a déjà eu le problème
Yes. Rust
en tarou
qu'est-ce que vous pensez
de Rust, est-ce que ça va continuer
à prendre de plus en plus de passe dans les outils
au point qu'il sera
utilisé en backend
avez-vous déjà essayé
je sais pas comme Yves
ou Youu
je sais pas comment ça se prononce
donc tu comprendras que personnellement
non, je n'ai pas joué
avec Rust
et je me suis pas mis à Rust
même si
force est de constater que beaucoup de choses sont récris avec Rust
par contre
de là
à ce que Rust devienne un outil
et en tout cas le langage principal
en backend
je pense qu'il y a
encore du chemin à faire
Rust est ultra rapide
pour tout ce qu'est outil
tout ça indispensable
tout ce qui est librairie, on va gagner en efficience
là-dessus il n'y a pas photo
par contre
que ça devienne
le langage principal du backend
là je suis un petit peu plus sceptique
parce que mine de rien, la courbe d'apprentissage
en Rust elle est pas donnée
pour avoir lu
un petit peu
tu vois quand même que tu peux pas
t'improviser
Dev, Rust comme ça
du jour au lendemain
tu as vraiment un effort à fournir
à être tout une montée en compétence
et ça en fait c'est pas donné à tout le monde
donc
oui, il y aura de plus en plus d'outils
qui vont être fait en Rust
mais de là à devenir le standard
pour le backend, je n'y crois pas personnellement
moi je pense que tous les outils vont passer en Rust
c'est sûr et certain
en tout cas les outils de Dev, JS tout ça
c'est sûr, ils passent sur Rust dans les prochaines années
il n'y aura plus que du Rust
ça c'est évident
après en backend
je pense que c'est utilisé par des boîtes
qui ont des problématiques de montée en charge
ça c'est sûr, je me semble que Doc Tolib
l'utilise mais je ne peux pas dire de conneries
ou c'est peut-être du goût mais je sais qu'ils utilisent
des choses comme ça pour les montées en charge
ensuite le framework
j'ai regardé là, parce que ça m'a intéressé
et ça m'a déçu
il disait un framework en Rust
et j'ai regardé, ça a l'air pas mal en fait
j'ai envie de tester un petit peu, j'ai envie de m'amuser un petit peu avec
ça a l'air plutôt bien fait
c'est un framework avec des templates
pour faire du framework complet
pour faire du backend, des rendes, des vues
ça a l'air vraiment intéressant
je ne savais pas qu'il y avait des frameworks
comme ça en Rust
de là, ce que ça devient
le langage majoritaire
ça m'étonne
après pourquoi pas, c'est un super langage
en tout cas
je ne sais pas si c'est beaucoup enseigné
dans les formations
tout ça, il me semble pas
je ne pense pas
en tout cas, moi j'ai toujours
à chaque fois, je suis
plutôt motivé pour apprendre à faire un peu de Rust
parce que je trouve ça...
ouais ouais, le langage est assez concis
il est bien pensé
c'est un peu comme tout ce qui est nuk
tu as des conventions, tu as des outils officiels
tu as la gestion de librairie
c'est standardisé
donc en fait, tu as assez guidé
donc mis à part à prendre la syntaxe
tout ça qui est différent
de ce qu'on connaît
ouais, c'est vraiment un langage intéressant
je pense
ok
SCAR-81100
est-ce que vous vous formez ?
est-ce que vous formez à Next, à Nuxt, à Astro ?
quelle est la formation top
à suivre ?

alors non, on ne forme pas spécialement
enfin moi je ne forme pas spécialement
on pourrait
à tout ce qui est Astro, tout ça
mais bon, il y a déjà pas mal de ressources, je pense, sur le net
ah mais vous formez en fait
ouais, formez
ouais, en fait, j'ai mal lu la question
la question c'est est-ce que
on se forme à Nu, en fait
ou est-ce que vous formez ?
non
alors non, on ne forme pas
pas encore
exact, j'aime ça, j'aime ça Patrick
non, pas encore
après, pour être transparent
on en a discuté
avec Patrick
et c'est vrai qu'on aimerait faire plus de formation
plus de workshop
des formations complètes
sur
personnellement
sur Nuxt, ça c'est sûr
sur Astro, pourquoi pas
top, ce framework
pour faire des sites internet
Next, c'est sûr
enfin, je suis persuadé qu'il y aurait
des choses à faire
malheureusement, comme je l'ai dit
là, je viens de passer un énorme projet
j'arrive à la fin du projet
donc pour moi
2025, justement, je voudrais basculer
sur un autre format
moins travailler pour mes clients
et plus travailler
sur des sujets comme ça
donc
personnellement, oui, j'aimerais
faire des formations à Nuxt
vu et graphique
des choses que je maîtrise
que j'utilise au quotidien, clairement
mais après, c'est...
oui, pareil, mais après c'est
un gros taf
faire des formations, des vidéos
tourner, énormément de travail
donc potentiellement, oui, c'est un jour
en fait, ça sera
éventuellement payant, une partie
en tout cas, parce que
c'est vraiment beaucoup de travail, ça prend énormément de temps
de créer une formation, de tourner les vidéos
etc.
Mais de toute façon, vous serez au courant
vous n'inquiétez pas
vous serez largement au courant
donc
de donner une date
clairement, on est incapable
aujourd'hui, il faut qu'on trouve
un meilleur équilibre
pour améliorer tout ça
même si on a
une envie réciproque aussi bien patrique
que moi, de tendre
vers ça, clairement
clairement
Johan, c'est quoi votre techno préféré ?
Vas-y, toi
moi c'est clairement
moi j'ai choisi mon camp
je suis un mec du front
je viens du front
je fais du vu et je fais du nuxt
et
je suis intimement convaincu
qu'aujourd'hui, si tu as des compétences
en front et tu sais gérer
des stores et des management
système intermédiaire
et tout ça, quand tu vas faire
ton bac en js
tu vas t'en sortir. Par contre
moi j'ai fait le choix de jouer full js
même si pendant longtemps
j'étais un gros adept
de Ruby & Rails
donc je pissais rouge
j'étais Ruby Ruby Ruby & Rails
j'ai succombé
au louange du js
aujourd'hui, je fais que du js
Mastac est full js
et comme je dis tout le temps
front is the new back
parce que
tu t'en js maintenant
il va s'exécuter sur le edge
la limite
entre la techno pure
back & front
est en train de se réduire
donc moi je suis un mec
du nuxt
et puis en plus ils ont des logos avec de la montagne
et moi je viens de la montagne
j'habite en montagne
en plus c'est pour ça que je vais les faire
donc si tu veux
nuxt, il y a même pas de débat
voilà, terminé
la question est difficile à répondre
je dirais html
parce que sans html il y a pas de web
il est bon il est bon
c'est des questions auxquelles je suis incapable de répondre
parce que j'aime bien
faire pleins de choses
si je parle fremmor
js, j'ai fait beaucoup de next
mais actuellement
je préfère utiliser nuxt
parce qu'il est beaucoup plus facile
j't'ai converti ou quoi ?
j't'ai converti ? non non j'étais toujours fan
de vue tout ça mais
non non c'est juste que next
c'est devenu tellement complexe
et moins
développeur friendliste
c'est trop complexe
après ça se fait j'aime bien next, j'adore React
mais quand tu dois faire un truc, nuxt
tellement facile à mettre en place, ça marche tout seul
vu avec Reactivity
tout ça c'est génial
fremmor, js, nxt
après il y a plein d'autres technos qui sont super
la ravelle avec la voyeur
il y a plein de trucs
je suis incapable d'avoir une techno préférée
en fait ça dépend du projet
je prends la techno qui s'adapte de plus
et qui correspond plus
plutôt que de
j'aime pas avoir un seul outil
et faire tout avec cet outil
donc j'aime bien si ce projet
il faut faire un WordPress
parce que ça colle
parce que c'est juste un truc avec des pages
un WordPress peut faire le job
si c'est une application, un next
un backend, peut-être la ravelle
voilà, je sais pas
ça dépend
puis une fois, je devais faire une application
en printemps, j'avais dit
j'ai fait un next et l'agence m'a dit
on maîtrise pas vue en interne
donc ça sera du React
il y a aussi ça qui rentre en compte
ça dépend de qui reprend la
derrière
mais pour le coup
sur nos stacks
on a quand même des stacks de cœur
tu vois
évidemment
Pierre, R9P
le podcast est très bien
merci Pierre
ça me fait super plaisir
est-ce que vous allez faire plus de workshop ?
on aimerait ?
oui
on aimerait
hyper intéressant si tu veux qu'on fasse
plus de workshop, quel type de workshop
tu voudrais qu'on fasse ?
n'hésite pas à nous le dire dans les commentaires
ou même les autres personnes
si vous voyez des workshops
bien spécifiques
on ne dit pas qu'on va tous les faire, attention
mais
il faut aussi qu'on ait un minimum de compétences
sur le sujet parce que sinon
ça ne me paraît pas du tout pertinent
on ne serait pas pertinents
est-ce que vous allez parler des techniques
un peu plus exotiques
par exemple du Askel ou du Erlang
est-ce que vous parlez
est-ce que
vous pourrez parler des technologies
à utiliser selon les différents
cas
clairement
du Erlang et du Askel
tu connais toi
tu as déjà pratiqué
tu as déjà joué avec ?
non du tout
disons que nous on est plutôt un podcast
de développement web
c'est pas des langages qu'on maîtrise
surtout
je suis un peu ridicule de parler de ces langages
parce que je maîtrise pas du tout
on a tendance à plutôt parler
des choses qu'on maîtrise
ou qu'on connaît en majorité
parce qu'après des langages qu'on maîtrise pas du tout
est-ce que ça intéresse vraiment les gens
sur des trucs vraiment
des petites niches
ou je sais pas
alors pour le coup
je pourrais reprendre le cours
que j'ai donné
à des masters
où justement
on essayait de brosser
toute la palette
de tous les langages possibles imaginables
pourquoi il y avait autant de langages
et en fait
chaque langage répond à un problème
quelle a été
le problème abordé
pourquoi on a créé ce langage là
et quel paradigme il a
et en fait de comprendre nous
en tant que développeur web
ou même programmeateur
ou développeur de manière sans-slage
de savoir qu'il y a plein de langages
et de savoir à quoi ça sert
et quel est le paradigme de ce langage
je pense que ça peut vachement nous aider
aussi dans nos choix de carrière
c'est-à-dire ok moi je veux aller là
parce que ça
et avec tous les impacts que ça a
et je pense que oui ça serait super intéressant
de faire une palette
en fait de faire un épisode
très très pédagogique
comme on peut le faire quand on présente une techno
là on prend un peu
sur des fondamentaux
mais de savoir
quel est le paradigme du C
du Rust
pourquoi il est sorti
qu'est-ce qu'il amène sur le marché
à ce qu'elle
l'air langue, elme
tout ça
ça sort d'où
pourquoi c'est sorti
et quel est le paradigme
de ce langage là
ça peut être super intéressant
d'avoir ça en fait
en termes de connaissance
très théorique, globale
clairement
les mecs qui ont créé Java c'est pas ce qu'ils étaient payés
à la ligne de code c'est ça non ?
peut-être
il régumit bizarrement
yes
bah écoute
on a brossé
toutes les questions qu'on a reçues
aujourd'hui
on le redit
c'est un épisode
question-réponse aujourd'hui
on va s'arrêter là
sur la réponse
sur la réponse des questions
si jamais on en a oublié une ou deux
désolé
mais de toute façon
ce qui est sûr c'est qu'on va
refaire ce type d'épisode question-réponse
donc on vous invite
à mettre toutes les questions
dans
les commentaires, tout simplement
aussi bien du podcast, de Spotify ou de Youtube
et nous en fait
soit on y répondra directement dans les commentaires
soit on pourra
l'extraire
et on y répondra dans un épisode dédié
parce qu'on pense que ça peut être intéressant
de développer la question
au lieu de vous donner la réponse
directement
donc voilà
un grand merci à tout le monde d'être resté jusqu'au bout
de l'épisode
un petit pouce, un petit like, partager
l'épisode ça fait toujours plaisir
et on vous dit à bientôt
pour la suite
et on va rentrer dans la centaine
donc le prochain ça sera le 101 et c'est parti
pour la centaine
ciao à bientôt
merci à plus