Bruno:
La programmation, c'est un peu comme une recette de cuisine. Sur le papier, ça a l'air simple. Tu mélanges quelques ingrédients, tu enfournes et voilà. Bien sûr, en cuisine, on peut trouver des commis, des chefs de partie, des chefs plus ou moins étoilés. On ne cuisine pas tous avec les mêmes ingrédients, ni même avec les mêmes ustensiles, mais tout n'est qu'un assemblage d'ingrédients. Mais alors, pourquoi plane-t-il toujours ce mythe du métier impossible à comprendre pour les autres ? L'informatique serait-elle devenue le secret le mieux gardé depuis la cuisson du fondant ? Et surtout, est-ce qu'on a encore vraiment besoin de savoir ce qu'il y a derrière l'ORM pour réussir son plat ? Pour répondre à ces questions en toute simplicité, je ne reçois pas Norbert Terer, mais il connaît la recette des meringues. Anan, bonjour.
Adnan:
Bonjour.
Bruno:
Alors Anan, est-ce que tu pourrais te présenter pour les quelques personnes qui ne te connaîtraient peut-être pas ?
Adnan:
Alors je m'appelle Ananita, je suis tombé dans la tech quand j'ai été, on ne va pas dire tout bébé, mais j'ai appris à lire en même temps que j'ai appris à utiliser un ordinateur. J'ai fait plein de choses durant toutes ces années et aujourd'hui, là depuis 5 ans, je suis cofondateur et CTO de Sherlock, où on faisait à la base du cadenas partagé pour vélo et maintenant de l'assurance vélo.
Bruno:
Quand on s'est contacté pour faire cet épisode on avait des points de vue, alors pas forcément en opposition, ni forcément complémentaires en tout cas, parce qu'effectivement sur ce podcast j'ai partagé à plusieurs occasions que, j'avais une vision un peu qu'on avait un métier qui s'était beaucoup complexifié je prends souvent l'exemple du Front, qui dans les années 90-2000 c'était juste de l'intégration HTML et aujourd'hui c'est un vrai métier c'est une vraie techno aussi complexe que plein d'autres technos et que donc il m'arrive de dire sur ce podcast que le métier de dev full stack à mon sens a peut-être beaucoup moins de sens que ce que ça pouvait être il y a 10 ans 15 ans ou même 20 ans et toi ce que tu me disais c'était l'inverse c'est qu'au final on fait un métier qui est assez simple qui a toujours été assez simple et pour reprendre tes propos qu'il suffit d'apprendre.
Adnan:
Alors, ce n'est pas exactement ça. Je dis que le métier est de plus en plus simple.
Bruno:
De plus en plus simple.
Adnan:
Si on reprend un peu l'histoire, les premiers ordinateurs à programmer, bon courage. Puis on en est venu aux cartes perforées où pour arriver à faire un programme, il fallait une armée de personnes pour être capable de faire juste un Hello World sur des cartes perforées. Puis on est venu à des langages compilés, de l'assembleur déjà qui permettait directement de programmer le microprocesseur, puis on a créé des couches d'abstraction au-delà pour simplifier, le C et le C++ à tel point qu'à l'époque on considérait que les gens qui faisaient du C et du C++ n'étaient pas des, informaticiens parce qu'en fait ils ne savaient pas comment ça marchait en dessous Oui.
Bruno:
Parce qu'effectivement quand le C est arrivé les développeurs assembleurs considéraient que le C c'était trop haut niveau.
Adnan:
Mais le C a été inventé pour donner accès à la programmation informatique à plein de gens, peut-être pas à tout le monde, mais à plein de gens qui avant n'avaient pas cette capacité-là. Puis on a créé des langages encore plus haut niveau. Après, le Java, c'est toujours un long débat, mais si on parle du JavaScript, du Python, du Ruby, on peut relativement simplement considérer que c'est des langages encore plus haut niveau. Et aujourd'hui avec l'IA on se pose même la question est-ce que l'IA ne serait pas les LLM ne seraient pas juste une couche d'abstraction supplémentaire ? Moins déterministe, ce qui peut causer un peu plus de problèmes, mais ce qui ne serait pas une façon supplémentaire de simplifier encore cet empilement technique. Quand on regarde il y a 40 ans, la plupart des gens comprenaient comment marchait un microcontrôleur, un microprocesseur, ce que c'était des portes logiques, qu'est-ce qui allait s'exécuter dans la machine. Même les premiers développeurs C comprenaient comment ça allait être compilé et traduit finalement d'un langage vers un autre. La compilation, c'est ça. On en est arrivé à d'autres langages comme le Java où on n'a pas directement traduit en code compréhensible par la machine, mais en code compréhensible par une machine virtuelle qui elle va se charger de l'exécution et de la transposition d'instructions au niveau du microprocesseur à des langages, interprétés purement en se passant de la machine virtuelle comme au début le Ruby, dans une certaine mesure le Python, on pourrait dire que le Python il y a une transpilation d'abord vers un espèce de pseudocode et puis après une exécution. Vers des langages purement interprétés comme le Node enfin le javascript ou ce genre de choses, on est parti de quelque chose qui était extrêmement complexe qui demandait une somme de temps faramineuse pour finalement accomplir très peu à aujourd'hui quelque chose de beaucoup plus simple et qui nous permet avec très peu de produire ce qui nous paraissait en tout cas faramineux parce que si ça se trouve dans 30 ans on aura encore inventé d'autres paradigmes et d'autres choses qui vont encore paraître que ce qu'on fait aujourd'hui est extrêmement complexe comparé à ce qui sera disponible dans une trentaine d'années.
Bruno:
Je me permets une petite disgression, je l'ai partagé sur un seul épisode, donc peut-être que tout le monde ne l'a pas écouté. Tu parlais tout à l'heure des débuts de la programmation sur les cartes perforées. Est-ce que tu savais que c'est de là que nous vient le terme patch ? Quand on fait un fixe en programmation, on appelle ça un patch.
Adnan:
Oui, c'est parce qu'on mette un bout de scotch sur la carte pour combler le trou.
Bruno:
Exactement, je trouve cette information sympa.
Adnan:
Mais d'ailleurs, tu sais d'où vient le mot bug ?
Bruno:
Alors j'ai beaucoup entendu l'histoire comme quoi il y avait un vrai insecte qui a été trouvé quelque part, mais j'ai découvert il n'y a pas très longtemps que le mot bug serait apparu avant qu'on trouve ce fameux insecte, et qu'il aurait été scotché sur la feuille en disant que pour une fois ils avaient trouvé un vrai bug, un vrai insecte dans le...
Adnan:
Je ne sais pas, moi je connaissais l'histoire de l'insecte à une époque même avant les cartes perforées où on était avec des ordinateurs à diodes et ce genre de choses, voire des ordinateurs mécaniques et avec l'insecte qui posait effectivement un problème dans l'ordinateur en question, d'ailleurs les premiers microprocesseurs avaient des problèmes, aléatoires qu'on avait du mal à expliquer et donc on a dû implémenter des mécanismes au niveau du processeur de correction d'erreur parce qu'on s'est aperçu qu'il y avait un certain nombre de rayonnements, je ne sais pas d'où ils viennent, du soleil ou cosmique qui venait potentiellement altérer des bits de manière aléatoire à l'intérieur du, microprocesseur et donc on a implémenté des mécanismes de correction d'erreur pour pallier à ces problèmes là dans les microprocesseurs et aujourd'hui avec les ordinateurs quantiques on se retrouve finalement la difficulté aujourd'hui c'est pas de manipuler le qubit, c'est d'être capable d'avoir des qubits résilients aux erreurs sans que ça démultiplie la taille du système qu'on est obligé de construire pour, avoir cette erreur là donc la grosse bataille ça va être combien de qubits je suis obligé effectivement d'avoir pour être capable d'avoir un qubit reliable je.
Bruno:
Vois tant qu'on allait sur les termes parce que tu sais aussi pourquoi on parle de hardware et de software ? Non en fait c'est comme sur les matelas en fait parce qu'en fait t'as le hardware c'est les, la dureté du matelas t'as les matelas qui sont résistants middle ou mous donc hard, middle, software et c'est pour ça qu'on a le hardware, le middleware et le software ça vient de ces trucs là.
Adnan:
Je n'étais pas au courant de ça J'avoue, je vais devoir chercher après derrière, voir si c'est vrai. Je suis dubitatif, mais OK.
Bruno:
Je reboucle cette... Enfin, je ferme cette digression. Tu parlais effectivement... Au début, on a eu des langages compilés, et après, avec un certain niveau de langage interprété, et que maintenant, on peut considérer, grâce au LLM, qu'au final, le langage usuel est devenu un mode de programmation. Est-ce que, malgré tout, le métier de développeur et de développeuse, maintenant qu'il utilise, on va dire, le langage usuel en reste un métier accessible à tous et à toutes ?
Adnan:
Je ne pense pas. Le métier de développeur, en fait, le problème, c'est qu'on a eu tendance... À considérer, et je pense plus ces 20 dernières années qu'avant, à considérer que le métier de développeur, c'était d'écrire du langage machine, du langage compréhensible par la machine. Le métier de développeur ou d'ingénieur développeur n'a jamais été d'écrire du langage machine. Le métier, c'est de comprendre une problématique et de trouver une solution à cette problématique. Le langage machine n'est qu'une manière d'instruire la machine de quelle solution on a trouvé et de pouvoir conduire la machine à régler le problème d'un point de vue algorithmique. Mais le métier n'a jamais été d'écrire. Le gros problème de ça, c'est pour ça qu'aussi on a aujourd'hui beaucoup de développeurs qui disent moi je ne suis pas développeur, moi je suis artisan du code, je suis craftman, je suis machin. Désolé si vous voyez là-dessus, mais c'est parce que on a mis au même niveau deux populations qui ne faisaient pas du tout le même métier. Il y avait une population qui, effectivement, étaient des gens qui construisaient des architectures, qui pensaient des choses, qui résolvaient des problèmes, avec des gens, entre guillemets, qui n'étaient là que pour écrire du langage machine. De la même manière que quand on avait les cartes perforées, il y avait les gens qui écrivaient les algos et il y avait les gens qui perforaient les cartes pour pouvoir feeder la machine par rapport à l'algo. Ben oui, mais c'était pas le même métier exactement. Et donc effectivement, est-ce que le métier d'ingénieur en développement change avec les LLM ? Ma conviction personnelle est que non, c'est le même métier de je comprends un problème, j'apporte une solution au problème, j'expérimente éventuellement pour voir est-ce que la solution que j'apporte elle marche, elle ne marche pas, etc. J'évolue et je vais trouver des solutions toujours plus satisfaisantes, voire des problèmes toujours plus complexes à résoudre. La partie langage de code est finalement qu'un accessoire. Et c'est pour ça aussi qu'on a un problème à la fois dans l'éducation par rapport à ces métiers-là et dans le recrutement que font certaines sociétés. Vous avez des sociétés qui, pour le recrutement, vous disent, vous posent un problème, en mode, ça peut être un problème algorithmique, ça peut être un problème de j'ai une super liste compliquée avec tant d'éléments. Fais-moi un algo de tri. Et les gens se disent, ouais mais en fait du coup il faut que je bachote ça et pourquoi ils me demandent ça est-ce que vraiment connaître par coeur l'algo du triabule ou l'algo du tri par dichotomie ou l'algo du... Non, c'est pas ça qui est important ce qui va intéresser le recruteur c'est de te poser une problématique si possible une problématique auquel tu n'as pas été confronté, de voir comment tu raisonnes et d'essayer de voir comment en influant sur ton raisonnement, comment tu vas te comporter. Pour tester deux choses, un, ta capacité à régler un problème, et deux, ta réactivité face à un feedback donné ou à l'évolution d'une situation. Et donc, il y a des boîtes qui recrutent comme ça. Et il y a d'autres boîtes qui te disent « Ouais, fais-moi un test technique qui peut être plus ou moins complexe, ça va du « fais-moi un fou-bar ». Oui, bon, ok, tu sais parler le langage de la machine et me faire une boucle avec un if, super. Je veux dire que tu prends quelqu'un qui ne sait pas faire ça, combien de temps il faudrait pour lui expliquer. Pas grand-chose. Pour peu que la personne ait envie d'apprendre. Mais pas grand-chose. Est-ce que c'est ça vraiment le sujet ? Je ne sais pas. Et c'est pour ça aussi qu'il y a beaucoup de gens qui se rebellent contre ces tests techniques-là. Après, il y a des gens qui se disent « Ouais, mais moi, j'ai un test technique qui est vachement plus élaboré parce que je te donne à la maison à coder une API qui doit faire ci, qui doit faire ça et je vais regarder comment tu as structuré le projet. Est-ce que tu as utilisé des principes solides ? Est-ce que t'as bien écrit ton Rizmi ? Est-ce que t'as mis en place du linting, ce genre de choses, etc. ? Oui, ça peut être intéressant, etc. de voir, mais est-ce que, encore une fois, c'est ça la problématique ? Je ne sais pas. Pour moi, c'est pas ça le métier de développeur. Le métier de développeur, c'est comprendre une problématique et le métier n'est d'accessoire. C'est pour ça que je suis parfois pas mal embêté par des gens qui me disent moi je suis développeur PHP, ou moi je suis développeur JavaScript, ou moi je suis développeur Python ça n'a pas de sens un langage de programmation, sauf quelques-uns, c'est une trentaine de mots-clés allez, 40 mots-clés alors il y en a certains qui en ont 125, qui en pinaillent. Comparé à une langue humaine où on estime qu'il faut 3000 mots pour être capable de parler à peu près correctement la langue, hormis la grammaire et les règles, de grammaire, de conjugaison et tout ça, il faut connaître 3000 mots. Là, il faut en connaître vraiment pas beaucoup. Limite, on peut les avoir sur une chitchit à côté au début. Et les trois premiers jours, on va avoir la petite ref à côté, et puis au bout de trois jours, on n'aura plus besoin de la ref. C'est marrant. Et un certain nombre de design patterns à comprendre qu'on pourrait estimer si on fait le parallèle avec l'humain avec tes règles de conjugaison et une grammaire pour tel type de langage qui soit impératif, fonctionnel, objet, etc. Il y a un certain nombre de patterns qui existent, qui sont utiles dans certains cas de figure, qui sont à apprendre, mais qui sont réplicables sur tous les langages qui, plus ou moins, respectent ces patterns-là. À quelques subtilités près. L'objet en JavaScript, c'est pas tout à fait de l'objet, il faut comprendre un peu la subtilité par rapport à du Java ou du C++. Et même entre Java et C++, l'objet n'est pas tout à fait pensé de la même manière et ce n'est pas exactement les mêmes patterns. Mais n'empêche, si vous avez vu l'un des trois et que vous le maîtrisez, le passage de l'un à l'autre, il va se faire assez facilement. Ce n'est pas très compliqué. Moi, je recrute des ingénieurs qui, généralement, n'ont jamais utilisé les technologies qu'on utilise.
Bruno:
C'est marrant parce que ton propos sur le fait que le code n'est qu'un outil, ça me rappelle mon premier maître de stage, dont j'ai pas mal parlé sur les premiers épisodes, mais c'est vrai que je réalise que ça fait quelques années, peut-être que je ne l'ai pas recité, mais qui m'a donné une phrase qui est quand même restée avec moi, c'est quand je suis arrivé dans mon stage, il m'a dit, bravo, t'as appris un outil, maintenant il faut que t'apprennes un métier.
Adnan:
Parce qu'effectivement c'est.
Bruno:
Exactement ce que tu viens de dire c'est que le code le langage en fait ce n'est que un outil mais il faut que tu apprennes maintenant à utiliser ton outil dans un contexte où ton outil a de la valeur ou apporte de la valeur.
Adnan:
Et on a le même problème dans l'administration système où il y a des gens qui ont tendance à se dire ok moi je suis admin 6 parce que je sais, dans mon firewall ou mon load balancer à 10 que les boutons il faut cliquer là pour faire ça ou dans active directory, ça, ça se configure ici, ça, ça se configure là, etc. Et puis tu as des autres admin 6 qui comprennent comment ça marche l'architecture de serveur, ils savent que quelque part il doit y avoir un paramètre, ok, ils vont le chercher, ils vont le mettre, mais le fait de savoir où il est n'est pas la question. Le fait de comprendre par contre, si on reprend le parallèle sur l'admin 6, comment ça marche un réseau, c'est quoi les différentes couches du lérosie, comment tout ça, ça a été construit, qu'est-ce que c'est que des I.O. comment ça marche un file system, etc. Me semble plus importante que de savoir précisément sur telle ou telle technologie d'outil utilisé comment ça marche sur cet outil-là.
Bruno:
Mais tu vois... J'entends que... Alors, une partie de ce que... Enfin, pardon. Ce que je comprends de ton propos, c'est que la base de notre métier, c'est pas de tout connaître, mais c'est d'avoir en fait une culture... Tu parles là de l'adminsys qui sait comment fonctionne un file système, qui sait comment fonctionne le réseau. Tout à l'heure, quand on prend notre digression, tu nous parlais de ces interférences sur les microprocesseurs. Tu vois, donc c'est un ensemble de choses qu'il faut connaître un peu pour savoir appréhender les différents problèmes qui peuvent se présenter dans notre métier d'ingénieur. Mais quand je vois en fait toutes les couches d'attraction qui s'accumulent aujourd'hui dans nos différents métiers en fait les gens aujourd'hui sont extrêmement loin de la machine en tant que telle et la semaine dernière je faisais justement le refacto, d'un épisode qui a généré l'extrait qui a le plus buzzé sur TikTok où il y avait le responsable Android de Deezer qui disait, regretter de voir de plus en plus de gens d'entretien qui ne connaissent pas les différences entre TCP et UDP. Et en fait, dans les commentaires, ça a explosé avec plein de gens qui disent « Mais moi, je fais du React, en fait, j'en ai rien à foutre de la différence entre TCP et DP, parce qu'en fait, c'est très loin de moi. » Mais en même temps, dans cette démarche d'ingénieur, tu peux te dire « Bah ouais, mais en fait, ça peut être bien de quand même connaître ces éléments. » Et c'est aussi de ça dont je parle quand je parle, qu'on a un métier qui s'est complexifié, c'est que pour avoir cette culture générale de la tech, aujourd'hui, il faut maîtriser beaucoup plus de concepts que ce qu'on avait il y a 20 ans ou 30 ans.
Adnan:
Je ne trouve pas. Parce que si tu me reprends l'exemple de TCP UDP, il y a 20 ans, il y a 30 ans, c'était déjà TCP UDP. Mais des protocoles réseaux.
Bruno:
Tant d'un de la dôtre, qui se sont ajoutés sur le tas.
Adnan:
Pas tant que ça. Enfin, je veux dire, aujourd'hui, on marche encore en IP majoritairement. Ce qui sert pour les backbones d'Internet, BGP, etc., c'est les mêmes qu'il y a longtemps. Alors, on pourrait considérer que les protocoles peer-to-peer soient une évolution, effectivement, sur ces 30 dernières années, mais encore, même il y a 20 ans, il y avait déjà ces protocoles-là. On pourrait dire, la machine, oui, mais maintenant, on a du Docker, donc on n'a pas seulement de la virtualisation de machines, mais on a système de containers, etc. Mais j'ai envie de dire, ça aussi, ça a 20 ans. Alors, oui, on a construit beaucoup d'outils par-dessus. On a construit du Kubernetes, on a construit du Helm, on a construit énormément de choses pour manipuler finalement ces concepts-là. Mais les concepts, ils ont très peu bougé. Même en intelligence artificielle, on a eu les transformeurs qui ont conduit à plein de nouveaux outils assez sympathiques. Mais il n'y a pas eu une évolution radicale du domaine. C'est pour ça qu'ils continuent à inviter Yann Lequin et compagnie, alors que leurs recherches, elles datent quand même un peu. et pourtant elle est actueuse.
Bruno:
Maintenant, si on prend le métier de dev, on nous demande de comprendre effectivement tout un ensemble de sujets d'IA liés au LLM et comment on les implémente et compagnie. Il faut maîtriser bien évidemment des sujets plus classiques, on va dire, de fonctionnement d'un système, mais il faut aussi comprendre le réseau. Il y a aussi des problématiques de cybersécurité. Tu as un ensemble de sujets qui s'accumulent, qui sont des sujets qui étaient moins prenants ou qui étaient moins présents quand on remonte un peu dans le passé.
Adnan:
Alors, il faut faire la différence entre comprendre le sujet et avoir connaissance du sujet et la maîtrise du sujet en tant que tel. C'est-à-dire, généralement, quelqu'un qui vous dit je suis triste que vous connaissiez pas la différence entre TCP et UDP, je parle qu'il parle du principe même de pourquoi TCP, pourquoi UDP ? Il ne parle pas du fait de, dans le header TCP, que le premier bit, c'est ça, que le deuxième bit, c'est ça, que le troisième bit, c'est ça, et que dans le header UDP, le premier bit, c'est ça, le deuxième bit, c'est ça, le troisième bit, c'est ça. Donc, il y a une différence entre maîtriser à 100% le sujet et comprendre exactement, OK, en fait, sur l'UDP, c'est absolument ces bits-là dans l'header, etc. Et généralement, ce qu'on demande aux gens quand on leur parle de la différence entre TCP et UDP, C'est le fait qu'il y en a un qui a un acknowledge et l'autre qui n'a pas d'acknowledge. C'est tout ce que généralement on va vous demander de savoir. Et de comprendre que ça c'est construit par-dessus IP et qu'IP est construit encore par-dessus d'autres couches un peu plus basses, etc. Et qu'au-dessus de votre TCP, vous avez par exemple du HTTP ou du FTP qui sont des protocoles au-dessus. Pour revenir à ta question de, moi, je fais du React, pourquoi j'aurais besoin de comprendre ça ? Dans plein de cas, tu n'as pas besoin, tu ne seras pas impacté. Soit parce qu'il y a quelqu'un d'autre dans l'équipe qui le sait. Soit parce qu'à aujourd'hui, vous n'avez pas cette problématique-là. Mais tôt ou tard, peut-être que la boîte va grossir, que vous allez être dans un mode où vous allez vous poser la question de, « Ah ouais, mais là, on aimerait bien que le flux de données soit inversé. On aimerait bien pouvoir accélérer l'application dans certains cas parce que ce message-là, en fait, il n'est pas ultra critique. Et j'aimerais bien qu'il parte. Mais s'il ne part pas tout le temps, ce n'est pas trop grave parce que c'est juste pour de la stat. Mais en même temps, je n'ai pas envie d'attendre parce que j'aimerais bien que machin. » Le fait de comprendre que TCP existe, que UDP existe, ça va vous amener peut-être à chercher, à comprendre qu'il y a des choses qu'on appelle les WebSockets, alors on est toujours en TCP, ou qu'il y a d'autres outils qui permettent de l'utiliser. On va parler souvent de choses comme du Kafka ou ce genre de choses qui aussi touchent, ont tendance à toucher à ces sujets-là. Donc oui, fondamentalement, vous n'en avez pas besoin à l'instant T. La question, c'est surtout avec les LLM. Et le fait que l'aspect écrire purement du langage machine est quelque chose qui a perdu de la valeur, qu'on le veuille ou non, parce que c'est capable globalement de le faire. Et donc ça ne veut pas dire qu'on devient inutile, mais ça veut dire qu'une personne peut probablement produire, ou pourra probablement produire à terme, l'équivalent travail de ce qu'avant on avait besoin de deux, de trois, peut-être de quatre personnes. Donc forcément les places vont devenir un peu plus chères plus vous en savez plus vous serez résilients, dans cet environnement parce que justement qu'est-ce qui va faire la différence comparé aux autres, c'est peut-être que vous avez une culture générale qui est plus large, que juste savoir qu'en React, en fait j'ai un DOM virtuel et que la bonne pratique pour régler un composant c'est ça et que c'est bien de ne pas mettre 8 composants dans le même fichier, et qu'il faut éviter de redéfinir un composant dans un composant parce que ce n'est pas idéal, etc. Donc c'est cool de savoir tout ça. Mais honnêtement, c'est une connaissance qui vous est utile à un instant T, qui sera utile pendant une période relativement courte de votre vie, parce qu'il y a 9 champs sur 10 que dans 15 ans, on ne fasse plus de React, on fera autre chose.
Bruno:
Tu reviens sur le fait que la techno en tant que telle, c'est un outil.
Adnan:
La techno en tant que telle, c'est un outil. Mais comme aujourd'hui, si tu es développeur React, si tu croises quelqu'un qui fait encore du jQuery, tu vas te foutre de sa gueule. Ce n'est pas gentil, mais je peux comprendre. Parce que pourquoi utiliser un outil pas très puissant quand on a un outil beaucoup plus puissant à disposition qui va permettre de faire plus simplement la même chose, si ce n'est mieux ?
Bruno:
Il y a deux éléments le premier c'est que tu parles de cette connaissance générale elle te servira quand la boîte va grossir quand les problématiques vont arriver, la réponse qu'on pourrait aussi y voir en fait c'est que les cas où ça va se présenter au final c'est assez réduit parce que c'est sous réserve que la boîte grandit tu vois par exemple si on tire le trait, Facebook dans leur début, dans leur recherche d'optimiser le moindre micro-seconde de temps de requête ils en sont arrivés à réécrire le firmware de leur disque dur parce que dans leur data center ces micro-seconde gagnées en lecture et en écriture de disques c'était, mais enfin tu vois le nombre de personnes, le nombre de boîtes qui sont à ce niveau là de problématiques de volumétrie des sujets aussi pointus on parle de quelques dizaines de boîtes à travers le monde donc en fait pour la très grande majorité des développeurs et développeuses, le fait de devoir un jour se poser la question bah tiens peut-être que là on va choisir UDP plutôt que TCP, on parle d'un développeur ou une développeuse sur, sur 1000, sur 10 000.
Adnan:
Je ne sais pas. Le sujet n'est pas « vous avez absolument besoin de savoir ça pour pouvoir avancer ». Mon sujet, c'est plus « où est-ce que vous voulez aller et pourquoi vous faites ce métier-là ? ». A priori, vous avez quand même envie, à terme, de gagner de plus en plus d'argent, ou de rester employable si le marché change et se constreint. Et forcément, tôt ou tard, il y a quelque chose qui va faire la différence entre les individus d'une même population. Et quand tu recrutes deux seniors, il y en a un qui sait, l'autre qui ne sait pas. Tu vas dire, je prends celui qui sait plutôt que celui qui ne sait pas. Donc je ne dis pas que c'est absolument nécessaire à l'instant T de tout savoir sur toute l'informatique. Je reviens à ma thèse, c'est pas plus compliqué aujourd'hui qu'avant. Parce que les fondamentaux sont finalement à peu de choses près, relativement les mêmes, qu'il y a 20 ans, qu'il y a 30 ans, qu'il y a 40 ans, ils ont relativement faiblement évolué. Par contre, on a construit des couches d'outils au-dessus de ces fondamentaux, qui sont de plus en plus je ne vais pas dire complexes ils sont complexes dans leur conception mais ils sont de plus en plus simples à utiliser aujourd'hui, je prends un exemple je reviens dans l'admin 6, je ne sais pas pourquoi mais, il y a 20 ans ou 30 ans, vous vouliez faire une architecture de haute disponibilité avec des load balancers, avec ce genre de choses, waouh c'était du taf c'était une équipe entière, c'était des moyens de il fallait raquer des load balancers la plupart étaient propriétaires il y avait les balbutiements d'achats proxy mais bon il fallait quand même apprendre à le manipuler à comprendre comment faire le routing de manière intelligente à régler tout ça, c'était assez rude aujourd'hui et.
Bruno:
Surtout qu'en plus il faut prendre en compte que quand tu faisais de la haut dispo il y a 20 ans ou 30 ans la haut dispo c'était sur des volumes de requêtes qui sont bien inférieurs à ce qu'on a aujourd'hui.
Adnan:
Ça dépend Parce que moi, je me souviens de mon stage à la Direction Générale des Impôts. C'était la deuxième année où il y avait la télédéclaration des revenus. Et la première année, ça avait été un échec catastrophique. Donc j'ai passé l'ensemble de mon stage à être sûr de tenir l'objectif qui était d'arriver à avoir 10 millions de déclarations en l'espace d'une heure. C'était quand même une sacrée volumétrie pour l'époque. Pour 2005, c'était pas mal.
Bruno:
Même encore aujourd'hui, pour le coup, 10 000 communiques connexions en une heure, c'est un trafic qui est honorable par rapport à ce que...
Adnan:
Ça dépend de la complexité des calculs que vous faites derrière, mais oui, ça reste un trafic honorable. A priori, si vous avez ce volume-là, il y a des chances que vous faites déjà pas mal d'argent.
Bruno:
C'est le cas des impôts.
Adnan:
C'est le cas... Oui, enfin, aujourd'hui, ils sont plutôt déficitaires, mais...
Bruno:
Mais c'est un autre débat.
Adnan:
C'est un autre débat. Pour en revenir, c'était extrêmement complexe de monter une architecture de haute disponibilité. Pour peu que l'architecture soit en plus multi-sites, c'était presque impensable et presque inaccessible pour 99,9% des boîtes du marché, tellement c'était des investissements colossaux et une complexité très difficile à absorber. Aujourd'hui, vous voulez de la haute dispo multi-sites, voire multi-cloud, je ne vais pas dire que c'est trois clics, mais pas loin. Je veux dire la plupart des providers que ça soit même les providers souverains comme on les aime à parler d'eux aujourd'hui ou les providers américains type AWS ça reste assez facile de mettre en place ce genre de mécanisme, avec tous les outils qui ont été construits finalement dans ces 30 dernières années et vous n'avez pas forcément besoin de maîtriser exactement comment va marcher l'outil Ça peut être utile, mais vous n'avez pas besoin de le maîtriser. Par contre, si vous êtes sensible à ce que ça veut dire la disponibilité, peut-être que dans le choix des outils que vous ferez, il y aura peut-être un impact à la hausse ou à la baisse en fonction de ce que vous avez choisi par rapport à vos contrats. Donc, ce n'est pas indispensable de savoir, de maîtriser, d'être capable de recoder HAPRO aussi, GYNX, etc. Mais comprendre un tout petit minimum dans les grandes lignes comment ça marche, franchement, ça coûte 15 minutes de lecture. Et vous n'avez même pas besoin de rentrer derrière dans le sujet.
Bruno:
Sur ce point, je suis complètement aligné. Je pense qu'effectivement, on a quand même, de manière globale, on a réussi sur ces dernières décennies à baisser la barrière à l'entrée parce qu'effectivement faire de l'assembleur c'était clairement pas accessible à tout le monde faire de la programmation de microprocesseurs directement c'était clairement pas accessible à tout le monde et aujourd'hui effectivement tu peux construire une application ou un service ou un SaaS de manière extrêmement simple donc on a baissé la barrière à l'entrée sur ce métier qui est quand même un métier formidable et si on rajoute.
Adnan:
Les détracteurs du low-code et du no-code il y a même plein de choses.
Bruno:
Que vous.
Adnan:
Pouvez construire qui sont au final de l'informatique que vous le voyez ou qu'on le veuille ou non qui permettent de faire plein de choses sans connaissance particulière du langage de la machine et ce qui est important c'est de comprendre le problème et comment je résous mon.
Bruno:
Problème mais tu vois malgré cette, simplification ou cette barrière à l'entrée qui a baissé au fur et à mesure des années sur ces dernières décennies, on a pu constater qu'au même moment la demande en développeur en développeuse n'a fait qu'augmenter c'est à dire que la demande du marché aujourd'hui enfin aujourd'hui il y a 4 ans ou 5 ans était périmètre, Je ne sais pas combien de facteurs fois plus importantes que ce que c'était avant qu'on ait tous ces outils de simplification. Pourquoi est-ce que l'IA semble dire, pourquoi tout le monde semble dire que l'IA va faire en sorte qu'on va permettre d'avoir besoin de moins de développeurs ? Alors que justement, on a démontré jusque-là avant qu'en libérant beaucoup de développeurs et de développeuses de comment est-ce qu'on crée un site web pour le coiffeur du coin, enfin tu vois on a libéré énormément de temps aux développeurs on en a malgré eu besoin de plus en plus, pourquoi est-ce qu'avec l'IA on va avoir besoin de moins de développeurs alors que du coup on pourrait suivre la même logique ?
Adnan:
Alors il y a plusieurs différences le. Le marché a augmenté en termes de besoins aussi parce que le marché en termes d'usage a augmenté de manière exponentielle, il y a 20 ans il n'y avait pas de smartphone donc on faisait que des apps web il y a 20 ans ou il y a 30 ans il y avait. Presque personne qui était sur internet si je prends il y a 20 ans il y avait pas tant de monde que ça qui était sur internet là aujourd'hui quasiment tout le monde, entre guillemets dans les pays développés même si j'aime pas trop le terme mais entre guillemets dans les pays qui ont de l'argent, a internet même aujourd'hui dans beaucoup de pays d'Afrique et un peu partout, même dans des régions qui commencent à être isolées d'Afrique, il y a Internet. L'Internet sans fil, 4G, 5G, etc. Ont permis un essor explosif finalement des utilisateurs. Donc forcément, comme l'utilisation a augmenté plus vite et les besoins ont augmenté plus vite que la capacité à produire malgré la simplification, on a toujours besoin de plus de monde. Arrive quand même un moment où le marché commence à être un peu mature. Aujourd'hui, on n'a plus d'augmentation exponentielle du nombre d'utilisateurs d'Internet. Les gens sont à peu près tous équipés d'un smartphone, voire d'une tablette, d'un PC, etc. Je connais très très peu de gens, mais il y en a un. Mais généralement, c'est par conviction plus que par problème, en tout cas en France, qu'ils n'en ont pas. Je crois qu'effectivement.
Bruno:
De mémoire je crois que c'est à peu près deux tiers de l'humanité qui se connecte à internet au moins une fois par mois je crois que c'est un truc comme ça.
Adnan:
Ouais quelque chose comme ça et puis je crois qu'il y a plus de PC que de PC personnel qu'il y a d'habitants, de population dans le monde je crois qu'il y a plus de smartphone par habitant que d'habitants dans certains pays aujourd'hui on est arrivé à un marché qui est quand même très mature alors oui il y a sans arrêt des nouvelles Spartan avec des nouvelles technologies enfin nouvelle technologie, tout est relatif super il y a un nouvel emoji sur le nouvel iPhone, achetez-le, ouais je sais pas si t'as besoin vraiment du nouvel emoji quoi mais bon après il y a des gens qui vont dire mais l'appareil photo il est tellement mieux etc mais bref donc les besoins ont explosé il y a aussi un deuxième impact non seulement les besoins ont explosé mais il y avait un certain nombre d'activités qui n'étaient pas digitalisées, à l'époque et avec l'explosion de l'adhésion à Internet et de l'accès à Internet, on a aussi digitalisé énormément de fonctions, notamment les impôts. Aujourd'hui, presque plus personne ne fait sa déclaration d'impôt en papier. Il y a un certain nombre de services, que ce soit public ou pas public, où aujourd'hui, ce n'est plus du papier. Aujourd'hui, quand votre médecin vous dit « je n'ai pas la carte vitale, il va falloir que tu envoies la fiche de soins », Et personnellement, moi, je ne suis vraiment pas content parce que ça m'embête énormément d'envoyer du papier alors que c'était la norme il y a quelques années. Et donc, on a digitalisé énormément de choses. Bien, mal, avec de la dette technique, tout ce qu'on veut, etc. Mais n'empêche que le niveau de maturité de qu'est-ce qu'on est capable de faire aujourd'hui sur Internet versus il y a 30 ans n'est pas du tout le même de manière significative. À tel point qu'il y a des gens aujourd'hui qui ont une espèce de phobie de parler aux gens au téléphone en mode, ben non, je peux t'envoyer un texte ou pourquoi dans l'appli je ne peux pas cliquer à tel endroit pour dire que je ne suis pas content là-dessus, pourquoi il faudrait que j'appelle pour dire que je ne suis pas content. Donc oui, le paradigme, il a changé. Ce que change l'IA, c'est que déjà le facteur de transformation est beaucoup plus important que les simplifications précédentes. Parce qu'avant on a simplifié, mais c'était une simplification qui était longue au cours du temps. Mine de rien, quand on regarde l'âge de ce qu'on utilise aujourd'hui, alors on va me dire, ouais, mais React, c'est pas si récent, 2017, 2018, je sais pas la date exacte, 2016 peut-être. Et encore, avant, c'était les versions bêta, en fait, ça a explosé que depuis 2019, 2020, j'en sais rien. C'est un peu plus vieux que ça, je crois. Mais ce que j'ai dû en faire en 2017, C'est React Native qui est venu un peu plus tard. Je crois que c'est peut-être 2015. Enfin bref, peu importe. Mais ce n'est pas React en tant que tel qui a révolutionné tout azimut les choses. D'ailleurs, il y a eu plusieurs tentatives d'avoir des frameworks équivalents, qui d'ailleurs même ont parfois commencé avant avec du Angular, avec du Vue, avec du Météor, avec... Je ne connais pas tous ceux qui sont morts sur l'échafaud du développement mobile mais il y en a au moins 6 ou 10 de plus et ça c'est que pour l'écosystème javascript de la même manière que Ruby a mis énormément d'années avant d'éclater et ce qui a permis de dynamiser Ruby à l'époque. 2004-2005 c'était Ruby on Rails qui a changé ce langage en mode ouais ok fine ah ouais mais en fait tu peux construire des API hyper facilement avec ça et c'est cool. Et même Java, aujourd'hui, plus personne ne fait des EJB et des trucs comme à l'époque. Aujourd'hui, tout le monde fait du Spring Boot en mode, vas-y, c'est cool. Pourquoi j'utiliserais les trucs de l'époque pour faire du dynamic web ? Ce qui était d'une complexité. Donc la complexité, c'est réduite, mais de manière lente dans le temps. Alors que sur l'IA ça a été un choc assez rapide finalement, en espace d'un an on est passé de tout le monde dit ouais ça génère que de la merde ça m'intéresse pas, va-t'en. Un an plus tard, où les gens ont dit je ne peux plus m'en passer, c'est trop cool. Ou voir certains qui te disent j'ai repris goût à faire du code parce que je m'amuse à nouveau alors que j'avais arrêté de m'amuser. Et maintenant, je m'amuse à lui demander des choses de plus en plus compliquées, à essayer de lui mettre de plus en plus de problèmes façon de parler, mais dans la face. À lui demander de me faire cinq, six variantes, comme ça je garde la variante qui me plaît le plus, etc. Et donc ils ont un nouvel outil, j'ai presque envie de dire un nouveau jouet avec lequel jouer, mais qui change radicalement les choses. Moi j'étais parmi les premiers à dire ouais c'est cool pour faire un script de temps en temps. Depuis, allez, je vais dire février-mars de cette année, le shift il a été brutal en l'espace d'un mois ou deux. Je suis passé de j'en veux pas de ce truc là, ça m'apporte rien. Je sais plus m'en passer en fait. je sais vraiment plus m'en passer. Limite quand le truc tombe, je ne suis pas content quoi.
Bruno:
Alors on voit effectivement des rumeurs, mais en tout cas il se dit qu'on commence à recruter des gens pour corriger le code généré par des curseurs Codex, Windsurf et autres, ce qui est une possibilité, mais je pense que ça va rester anecdotique. J'entends ce que tu dis sur la rapidité du changement. Je ne sais pas si c'est de l'optimisme de ma part, mais moi, dans ce que je vois dans l'usage que je peux avoir de Cursor, c'est qu'il y a quand même un besoin d'une certaine maîtrise technique pour pouvoir l'orienter, le guider, et l'amener à prendre certains chemins qui correspondent plus à ce que toi, tu as envie de faire. Et je me dis quand même que, de la même manière que. Une autre analogie que je fais souvent sur ce podcast c'est l'émergence de Youtube ou de TikTok. Qui permettent en fait à des créateurs de contenu à travers le monde entier de faire des contenus, fabuleux, ça n'empêche pas qu'on continue à faire des films à l'ancienne ça n'empêche pas qu'on continue à faire des films de merde qu'on fait des films très bons mais sur TikTok et sur Youtube tu vois aussi des créateurs de contenu qui font des trucs brillants avec des moyens moindres. Mais on continue à faire beaucoup plus de films que ce qu'on faisait il y a 10 ans, il y a 20 ans, il y a 30 ans. La production cinématographique ne s'est jamais aussi mieux portée que les dernières années. Et donc, en fait, mon analogie, c'est de dire, en fait, je pense que ces nouveaux outils vont permettre à ce qu'il y ait plus de gens qui deviennent des créateurs d'applications et des créateurs de services. Et que ce métier d'ingénierie que tu évoquais dans le début de l'épisode, sur notre capacité à comprendre un problème et d'y apporter une solution, va se démultiplier, on va avoir de plus en plus de choses qui vont apparaître, et je pense que notre métier va se changer, c'est-à-dire qu'on va écrire du code en français ou en anglais, ou on s'inscrit dans la langue que tu veux, mais peut-être pas directement en javascript ou en C. Mais j'ai quand même un espoir que la demande de développeurs et développeuses reprennent vers le haut, mais pas au sens où on l'entend aujourd'hui. Tu vois ce que je veux dire ?
Adnan:
Je vois ce que tu veux dire et je suis d'accord avec toi et je vais faire un parallèle avec, je ne sais plus comment on appelle ça, mais l'étude des êtres vivants dans une population d'êtres vivants. En gros on est arrivé à un stade à mon avis où finalement la population d'individus, on va dire le développeur mais ça peut être, on va dire c'est la population de serres dans une zone donnée est devenue trop importante et donc il va y avoir un choc brutal, probablement plus que nécessaire de la population de développeurs, du fait de ce changement là.
Bruno:
Au début Qui est du coup peut-être plus un rééquilibrage économique, on va dire.
Adnan:
Qui est en partie un rééquilibrage. Pourquoi ? Parce qu'il y a deux choses dans ces coupes-là. Il y a un, l'amélioration de l'outil de production. Et il y a deux, la réalisation que, pour beaucoup de boîtes, en fait, ils avaient déjà trop de monde, qu'on parlait avant. Quelle boîte, quelle grosse boîte, entre guillemets, ne s'est pas mise à réinventer parfois complètement la roue, Parce que probablement, ils avaient trop de temps à tuer et trop de liberté. Tu me parlais de Facebook qui a réimplémenté je ne sais plus quoi, là.
Bruno:
Les firmwares du disque dur.
Adnan:
Le firmware du disque dur. Est-ce qu'il n'y avait pas d'autres moyens de simplifier le problème et d'améliorer les choses ? Je ne sais pas. Je n'étais pas dans la problématique. Mais il y a Criteo qui, à un moment, s'est mis à réinventer DNS, et ce n'est pas les seuls. Il y a d'autres boîtes qui se sont mises à réinventer FTP ou réinventer d'autres choses, oui mais peut-être qu'il y avait déjà d'autres choses en fait qui permettaient de simplifier tout ça, pour gagner quoi est-ce que c'était vraiment là qu'était le problème d'un point de vue business etc, je ne sais pas donc je pense qu'il y a aussi ce rééquilibrage du fait que même avant l'IA il y avait beaucoup de boîtes qui étaient surstaffées en termes de développeurs, comparées à ce que ça aurait dû être. Là dessus et qui coupent deuxièmement il y a un deuxième phénomène qui est le rendement décroissant du travail c'est à dire vous avez une boîte d'une personne un développeur, vous rajoutez un deuxième développeur, vous multipliez quasiment par deux la capacité de production, vous avez une boîte où il y a déjà 400 développeurs, vous rajoutez 50 développeurs en fait le pourcentage que ça augmente est bien moins, que l'équivalent des 50 développeurs en pourcentage pour que ça soit des pourcentages plus faciles à calculer j'avais 100 développeurs, j'en rajoute 20 j'ai pas 20% de plus d'efficacité j'ai peut-être 5%, 6% et donc, combiné à des outils on se dit, et ça paraît logique de se dire, si un développeur est capable de produire beaucoup plus et que j'en ai beaucoup moins non seulement je gagne en efficacité parce qu'ils ont gagné en efficacité je vais gagner à réduire, mais en plus comme le rendement était décroissant par rapport à tout ce que j'avais je vais encore gagner plus et donc il y a un rééquilibrage assez massif. Est-ce que par la suite, ça va repartir à la hausse ? Probablement. Est-ce que ça va réatteindre les niveaux qu'on avait ? Ça, j'en sais rien. Je sais pas. Mais je pense qu'effectivement, il va y avoir un gros choc et ça va repartir avec une pente probablement assez douce, petit à petit, jusqu'à ce qu'on retrouve une situation à peu près d'équilibre de la population par rapport aux besoins réels nécessaires pour avancer sur ces sujets-là.
Bruno:
Ce qui est intéressant, peut-être pour conclure cette conversation, c'est qu'on est parti de points de vue, on peut dire, un peu opposés. C'est-à-dire que moi, je parlais d'une complexification de notre métier et toi, au contraire, d'une complexité latente, voire même descendante par rapport à ce qu'on avait avant. Mais ce sur quoi on se rejoint, c'est que notre métier n'est pas d'écrire du code, mais de comprendre un métier et d'y apporter une solution. Et qu'au final, on se dirige vers un métier qui ne sera plus que ça, de ce que tu dis, et qu'on ne va plus avoir besoin de se préoccuper de ce que notre métier, c'est d'écrire du code ou pas, parce qu'au final, on ne va plus en écrire.
Adnan:
Alors, à très long terme, peut-être, et je vais rebondir sur ce que tu disais tout à l'heure, sur les boîtes qui commencent à recruter des gens pour corriger le code produit par l'IA, il y a de fortes chances que la partie écriture de code qu'on faisait avant va se transformer en une partie relecture de code et correction de code. Aujourd'hui, le bottleneck dans la plupart des boîtes qui produisaient de la valeur, c'était généralement la capacité à produire du code. Et finalement, il y avait du temps qui était passé pour la relecture, selon les boîtes, mais on va dire que chaque boîte faisait bien les choses et qu'elle relisait le code. Il y avait une production peut-être en amont de, selon comment elle fonctionne, de user story, de maquette, de whatever. mais souvent ce qu'était le bottleneck à aujourd'hui c'était la production même du code. Là ce bottleneck là était réglé mais du coup le bottleneck s'est déplacé et aujourd'hui beaucoup de boîtes commencent à se poser la question de mon bottleneck il est devenu soit en amont décider qu'est-ce que je vais faire, soit en aval relire ce qui a été produit pour s'assurer qu'on ne fasse pas complètement n'importe quoi. Et forcément, quand on a un bottleneck, qu'est-ce que fait l'esprit humain ? Je vais essayer de réduire mon bottleneck, parce que finalement, c'est ce qui est le plus lent dans ma chaîne, donc c'est ce qui va cadencer toute ma chaîne de production. Donc si je suis capable d'améliorer la productivité du bottleneck, en fait, j'améliore l'efficacité de toute ma chaîne de production. Donc ça ne me paraît pas complètement déconnant que certains se disent, je vais embaucher des gens spécifiquement pour relire le code lié par la I, parce que c'est un bottleneck. Le bottleneck en amont, de décider quoi faire, la question c'est, est-ce que c'est un bottleneck, et donc il faut que je trouve plus de gens pour réfléchir à ce que je vais faire ou est-ce que c'est parce que le reste est peut-être trop sizé et, peut-être qu'il faut que je diminue ma capacité de production parce qu'en fait j'ai pas vocation à réinventer tout le modèle business model de la boîte tous les 3 jours. Et donc il y a beaucoup de boîtes qui vendent l'IA en mode non mais vous inquiétez pas, c'est pour augmenter la productivité, c'est pour tout ça, tout ça, qu'ils vont tôt ou tard réaliser que, bah oui, c'est sûr, ils ont amélioré les différentes étapes, mais s'ils ont un bottleneck en amont, on n'a pas grand-chose à leur faire faire, ils vont assez rapidement se dire, on ferme une usine, histoire de gagner de l'argent, d'être un peu plus rentable, et de faire plaisir aux actionnaires, ou aux patrons, ou j'en sais rien.
Bruno:
Je vois. Merci beaucoup, Adnan, pour cette conversation. J'aurais deux dernières questions pour toi, qui sont les questions rituel de ce podcast. La première, c'est est-ce qu'il y a un contenu que tu souhaiterais partager avec l'ensemble des auditeuristes ?
Adnan:
Allez, je vais donner un contenu tech, un contenu non tech. Le contenu tech, alors c'est une vieille bible, il y en a même deux. Il y en a une, c'est le Knut. Je pense que ça ne fait pas de mal à aujourd'hui de le lire, voire de le relire.
Bruno:
Non, je ne connais pas du tout.
Adnan:
Tu pourras chercher. The Art of Computer Programming de Knut. Et Il y en avait un autre mais qui est moins sympa mais moi c'est ce que je lisais aux toilettes il y a 25 ans c'était Unix Power Tools, qui permettait de mieux comprendre de manière générale alors là c'est plus sur l'outil qu'autre chose mais c'est sûr que plus on est efficace là-dessus, plus indirectement ça crée aussi un skill set qui est utile et c'est très difficile aujourd'hui de trouver, moi je trouve que c'est beaucoup plus difficile aujourd'hui de recruter un admin 6 ou quelqu'un qui comprend comment faire de l'admin 6. Alors on peut appeler ça senior lability engineer, appeler ça comme vous... DevOps, appeler ça comme vous voulez. Au final, c'est la même chose. En essence, désolé. Que de recruter un développeur. Parce que cette partie-là est devenue beaucoup plus complexe et on ne peut pas dissocier l'outil du fonctionnement. Contrairement aux développants où tu peux rapprendre le nouveau langage avec tes 30 mots-clés, tes 3 design patterns et tu vas t'en sortir. Là, c'est un peu plus hardcore et j'ai beaucoup plus de mal à recruter ça. Voilà pourquoi j'aimerais bien qu'il y ait plus de gens qui lisent ce bouquin-là. Notamment, ça parle de TCP, du DP. Et contenu non tech, c'est plus pour les gens qui travaillent dans les grands groupes. Un magnifique bouquin qui s'appelle Influence et Manipulation. Déjà de comprendre la différence entre les deux, ce qui est important. Et deuxièmement, parce que c'est tout un tas de choses qui vous permettront, soit dans la vie, d'éviter de vous faire avoir. Je pense que c'est le principal avantage. Et dans l'autre sens, de comment potentiellement influer sur les autres. Pas forcément sur YouTube en faisant des vidéos à danser. Mais comment influer pour faire peser éventuellement votre point de vue ou votre décision à l'intérieur d'une organisation.
Bruno:
Ok et la dernière question qui est peut-être la plus importante de ce podcast, Adnan est-ce que tu es plutôt espace ou tabulation ?
Adnan:
Alors, il y a 25 ans, j'étais plutôt espace. Aujourd'hui, c'est même pas un sujet. J'avoue, je vois même pas qu'est-ce qu'on utilise, tellement peu importe le langage de programmation que vous utilisez. En fait, vous avez mis normalement un Prettier ou un Linter ou n'importe quoi qui va, que vous ayez mis l'un, gérer l'autre. Ce qui est important, c'est que dans une même base de code, que ça soit cohérent parce que sinon, ça pique les yeux. Et la plupart des idées aujourd'hui font la différence. pour vous de toute façon, c'est-à-dire que vous avez mis un tableau ou un espace, même si c'est une chaîne de deux espaces, si vous dites revenir en arrière, il revient de deux espaces comme si c'était une tabulation. Je ne la sens même plus cette différence-là aujourd'hui.
Bruno:
Très bien. Merci beaucoup Adnan.
Adnan:
Merci à toi.
Bruno:
Et merci à tous d'avoir suivi cette conversation. Je pense que le message qui en reste, c'est qu'on a un métier qui est en train de changer mais qui en même temps est en train de rester le même. C'est qu'on est là pour résoudre des problèmes. Il faut avoir un maximum d'outils dans sa besace pour le faire. Donc, continuez à vous cultiver sur tout ce qui fait la beauté de notre métier dans tous ses aspects, dans toutes ses aspérités. Aussi, d'une certaine manière, parce que c'est aussi comme ça qu'on se démarque. Je vous remercie beaucoup aussi de partager ce podcast autour de vous. N'hésitez pas à aller checker en description le lien vers le Tipeee si vous souhaitez contribuer à ce podcast. Je vous remercie beaucoup. Je vous souhaite une très bonne fin de semaine. Je vous dis à la semaine prochaine et d'ici là codez bien.
