Le topic de la programmation: Et envoyez des sioux!

[William Vaurien]

4h de tests techniques c'est un peu lourd quand même... Par contre tu te places du point de vue où tous les dev sont de ton niveau voir meilleurs. Les questions te semblent simples, voir débiles, mais je suis certains que la plupart des candidats reçus n'entravent rien ni au C++ ni aux questions.
J'ai déjà vu des recrutements mal se terminer car aucun tests techniques, juste de la discussion (quelques questions techniques mais pas trop et de la mise en situation). Au final le candidat retenu n'a pas terminé sa période d'essai car techniquement il était à la ramasse: il avait vraiment juste le vernis suffisant pour un entretien pas trop stressant.
Avec un autre collègue nous avions évité les questions trop orientés framework par exemple en nous disant qu'une personne qui connait une techno x ou y peut aussi apprendre z.
Mais en fait non. Et le code produit par ce candidat était au final dangereux pour le projet, et il faisait les mêmes erreurs après explications multiples... et pourtant c'était du Java/Spring assez basique.

Maintenant je me méfie un peu plus: les tests techniques c'est pas la panacée mais ça filtre pas mal quand même. Et en plus là j'ai l'impression que c'est pour un projet un peu plus complexe que du "Java Enterprise" à base de formulaire.

[Anonyme20240202]

Effectivement je ne me suis jamais retrouvé dans la situation de l'entreprise qui cherche à recruter. Enfin j'ai déjà contribué à recruter des gens pour mon équipe, mais les enjeux sont assez faibles (pour moi). À vrai dire je veux surtout que le mec soit sympa et prêt à échanger

C'est sûr que la question du recrutement est complexe, comment garantir que tu n'embauches pas un guignol. Mais j'ai le sentiment qu'une discussion est le meilleur outil, avec simplement des exemples de codes et d'architecture "critiquez ce code", "critiquez cette archi".

Il m'apparait vraiment difficile de pouvoir passer pour ce qu'on n'est pas au cours d'une discussion informelle

À vrai dire un truc qui m'avait énormément plu c'était une boite Irlandaise qui m'avait donné un mini projet à faire. Le truc est faisable en quelques heures mais ils te donnent une semaine.

En l'occurence il fallait traiter 4GB de données financières (des ticks de prix), l'intérêt du truc c'est que y'avait un objectif de perf/temps d'exécution et qu'il fallait être malin et utiliser les algo dit "online" https://en.wikipedia.org/wiki/Algori...line_algorithm qui te permettent de faire des stats en ne lisant qu'une seule fois les données linéairement.

Je pense qu'un projet "clefs en main", où tu as vraiment le temps de tout faire dans les régles de l'art donne une bien meilleur idée de ce que vaut quelqu'un. Ca laisse le temps aux détails d'apparaitre et de voir comment fonctionne quelqu'un véritablement vu la part de liberté. Fallait aussi faire une mini doc, etc.

[Anonyme20240202]

Et sinon complètement hors sujet mais je découvre cette chaine, incroyable!

C'est un développeur qu'a bossé dans les années 90 sur des jeux vidéos et qui explique tous leurs secrets, de l'or en barre

[Nilsou]

Mais est-ce que c'est grave s'il est capable de les apprendre plutôt une fois en poste ? Est-ce que le savoir à la base, ça change bcp les choses ?

Parfois en entretien on me reproche (ou je fais l'erreur de reprocher) de ne pas connaître un truc. Mais ce truc c'est un détail qui se maîtrise en 5min, ou une techno que tu apprendras vite. Et on ne peut pas se targuer de tout connaître. Un bon dev, il évolue.
Donc modifier la façon d'allouer la mémoire, n'est-ce pas juste une histoire de convention à appliquer, et donc d'habitude à prendre sur le projet ? Demain tu passes sur un autre projet et on va te dire nan mais allo, nous on fait du Rust, ton C il est inutilement compliqué.

Pour moi c'est complétement l'inverse : le savoir fonctionne par couche. Tu veux faire du C++, je suis désolé, mais il faut connaitre un minimum de C. Tu veux faire du C++ moderne, OK mais il faut connaitre un minimum de C++ classique. C'est enseigné comme ça partout (et j'ai enseigné dans 3 endroits différents, de la FAC à l'école d'ingénieur publique et actuellement en école d'ingé privé) et ça a une logique de fond je pense. Tout comme il est nécessaire de connaitre des bases de math pour faire pleins de choses, même si tu ne les réutilise pas strictement ensuite, ce sont les briques de bases de ta compréhension.
Bah idem, pour moi la compréhension de la mémoire et de l’interaction programme-mémoire, c'est la brique de base de la prog. C'est tout à fait pertinent de faire un premier tri des candidats sur ce genre de question de base pour t'assurer que le candidat a bien le savoir nécessaire. Même si tu ne lui demande jamais ça ensuite.
Enfin du moins, c'est mon avis.

Justement, pour l'avoir vu dans un certain nombre de code scientifiques/HPC, faire des new/delete à tout bout de champs est une super mauvaise idée niveau performance.
Surtout que jusqu'en 2018 (je crois ?), il y avait toujours un mutex global sur la gestion de la mémoire dans la libc standard, donc dès que t'es sur un programme multithreadé, et que tu ne compiles pas avec un compilateur récent, tu le paies super cher en perfs.

Certes mais justement, ce que tu recherche à ce moment là c'est une maitrise parfaite du timing auquel tu libère ou tu alloue la mémoire. En fonction de la logique de ton programme. Ce que tu perds complétement en passant sur des mécanismes plus haut niveau.

[Tramb]

Toujours le même biais, je dirais.
"Les gens qui ne savent pas les trucs que je sais sont mauvais."
+
"Les savoirs que je n'ai pas ne servent à rien."

Parfois un peu vrai mais il faut lutter contre ça un minimum.

[Lazyjoe]

Certes mais justement, ce que tu recherche à ce moment là c'est une maitrise parfaite du timing auquel tu libère ou tu alloue la mémoire. En fonction de la logique de ton programme. Ce que tu perds complétement en passant sur des mécanismes plus haut niveau.

Ben c'est ce qu'on répète hein. On peut toujours trouver des cas particuliers où une gestion à la main est nécessaire, mais dans la grande majorité des cas avec les containers standards + une bonne gestion du scope des variables on a tout ce qu'il faut.

[Nilsou]

Certes, mais c'est pas tout à fait le propos initial de Kamikaze, qui avait l'air de dire que ce type de savoir était parfaitement obsolète. Et que de fait les questions posées par les recruteurs n'ont aucun sens.
Je ne suis pas d'accord avec cette analyse.

[gros_bidule]

Pour moi c'est complétement l'inverse : le savoir fonctionne par couche. (...)

J'imagine que nos divergences viennent de nos métiers. Tu évolues dans un domaine plutôt scientifique si je ne dis pas de bêtise ? En tous cas je crois avoir compris que tu ne passes pas tes journées à pondre des API REST abrutissantes :-) Si tu as des contraintes fortes de performances, ou simplement besoin de comprendre comment fonctionne le matos, ce genre de chose, je comprends que des connaissances plutôt bas niveau et/ou scientifiques soient nécessaires, tout comme maîtriser la plateforme/langage.

Perso, je travaille avec un niveau d'abstraction bien plus élevé, où l'on a pas forcément besoin de chercher les meilleures performances.
Une de mes dernières missions c'était par ex le Chèque Energie du gouvernement (API REST pour déclarer les chèques, des batchs pour faire les paiements, parsing de fichiers normés, ce genre de trucs basiques). Le projet type d'une grosse ESN (et c'était le cas), où tu vises la rentabilité maximale, et où un gosse qui sort de l'école est vite opérationnel là dessus (et justement, je devais encadrer des jeunes diplomés).
J'adore aller dans les détails, comprendre comment ça marche en interne (le fonctionnement d'une JVM, les trucs internes de Spring..., en général en entretien c'est moi qui explique le métier au recruteur) etc. Ca "peut" aider en cas de soucis, mais 99% du temps c'est inutile car on te demande juste de pisser du code. Sur les 1% restants, ton expertise coute trop chère, on préfère un workaround pété mais moins cher. Ca me désole.
En 12 ans je n'ai jamais rencontré un collègue qui était curieux de savoir comment ça marchait une JVM, un Spring Boot, un Spring Batch (la db qu'il y a derrière par ex), divers algos de compression ou de chiffrement... certains ne savaient même pas qu'il existait des types primitifs en Java (ce qui les amène à créer des booléens à 3 états dans des cas où ce n'est pas utile, ouaip : true/false/null, et tu te prends des NullPointer partout car le dev considère que ça n'arrive jamais), c'est dire... et pourtant c'est ce que demande le projet. Un type comme moi n'a pas sa place (et je l'ai assez vite perdue), je ne suis pas rentable et les chefs me l'ont souvent rappelé (et puis bon... je m'ennuyais à mourir aussi). Mon expertise je l'aime, c'est ma passion, j'apprends par couche, mais elle n'est pas reconnue (en France en tous cas, depuis que je suis au Canada c'est très, très différent).

Je comprends donc que l'apprentissage par étapes peut être nécessaire dans certaines disciplines, être un plaisir personnel pour certains aussi, mais hélas une partie de l'informatique se contente de gens que je considère comme peu passionnés, ou peu curieux. Ils apprennent directement le Java ou dotNET haut niveau, et n'ont jamais touché une ligne d'assembleur ou de C, donc ils ne savent même pas ce qu'est un pointeur, un pipe, un socket, ou pourquoi un GOTO c'est pas glop. Ces gens là n'ont aucune chance de passer des tests compliqués décrits plus haut dans le thread, alors qu'ils pourraient peut être faire le taff. Enfin bien... disons que le projet sera livré sans trop de retard et le patron gagnera plein de pognon.

[vectra]

Je suis dans le privé en France et je ne me reconnais absolument pas là-dedans.
Nulle offense hein, mais j'ai pas du tout performé en ESN et (par chance) assez facilement réussi à trouver des jobs en direct...

[gros_bidule]

Aucun soucis
Clairement, les ESN d'informatique de gestion c'est un monde à part J'aurais teeeeeellement aimé trouver des boites comme la tienne ou celle de Nilsou etc. Ce que je vois comme de la vraie informatique, où tu comprends ce que tu fais. Vos posts transpirent l'informatique, et même si ça fait un peu mal au crane, je trouve ça beau.

[Awake]

Je suis exactement dans le cas que tu donne gros_bidule. Incapable d'implémenter un sort ou d'optimiser une recherche dans un arbre. Mes connaissances en math s'arrêtent au niveau seconde (et encore...). Mais ce n'est pas un manque de curiosité ou de passion, que j'ai pour plein d'autres domaines dans le dev, simplement que je n'en ait jamais eu besoin et que c'est l'architecture et le haut niveau qui me plaisent. Un employeur qui me demande un algorithme pointu d'optimisation me prendrais pour un débutant, alors que si il a besoin d'une app web je pourrais surement faire très bien faire le taff.

Donc non Nilsou, je ne suis vraiment pas d'accord, pas besoin de connaître le C ou des maths pour faire un bon développeur.

[Nilsou]

Sauf qu'après c'est une question de langage choisi. Si tu veux faire une app web pas besoin de C sans doute, mais si tu veux faire du C++ c'est loin d'être accessoire.

Quant aux math, pour moi elles sont nécessaires pour tout bon développeur. Ou du moins, elles facilitent grandement l'apprentissage des langages et de nombreux concepts liés à ces langages. C'est toujours possible de faire un bon développeur avec des maths de niveau seconde. Est-ce efficient comme stratégie d'enseignement quand on veut amener le maximum de personne à un bon niveau dans un temps donné ? À mon sens, non. (raison pour laquelle, d'ailleurs, la plupart des écoles d'info ont tendance à recruter des gens qui sortent avec un bac ayant des maths dedans ...). Le cerveau fonctionne par acquis qui s'applique ensuite à l'apprentissage des autres acquis, couche après couche (cf : Piaget : apprentissage chez l'enfant). Tu peux sauter les étapes, mais c'est globalement inefficace en moyenne et ça peut amener à de gros troubles persistant dans la compréhension de certains concept (cf : méthode globale en lecture).

Puis la question est plus large en définitive, et un brin plus philosophique que la simple efficacité. Si le but n'est de former que des gens ultra-spécialisés en pissage de code, à la limite on peut éviter de leur enseigner l'histoire, le français et qu'une pomme qui tombe d'un arbre a une accélération liée à la gravitation. C'est juste pondre le « meilleur des mondes » que faire cela. Un monde de personne dans des cases qui seront ensuite incapables de changer de domaine en fonctions de leurs envies, incapables de s'adapter à des contraintes changeantes dans le temps, etc. Bref, de bons rouages de machines.

En général on essaie de pondre autre chose dans les milieux d'enseignements et de construire les cursus sur des bases larges, du moins spécialisé au plus spécialisé. Le but n'est pas que d’être efficace, mais d'amener une meilleure compréhension, une souplesse et une certaine « curiosité » comme le pointe gros_bidule.

[Awake]

Tout ce que je veux dire c'est que cette histoire de couche d'apprentissage ne me semble pas juste. C'est normal de se spécialiser de nos jours, et ne pas connaître les rouages des tonnes de couches d'abstractions qui sont en dessous de sa spécialité n'empêche pas d'être compétent. Bien sûr ça ne fait pas de mal d'être au courant, mais ce n'est pas sur des choses complètement en dehors du domaine de prédilection du candidat qu'un recruteur devrait le tester, sous prétexte que c'est "les bases".

[Nilsou]

D'un point de vue purement « méthode d'enseignement » et science de la formation du cerveau, cette histoire de couche d'apprentissage est un fait scientifique démontré dans le domaine des sciences cognitive (première formulation par Piaget, puis confirmation successive par la neurobiologie puis par les sciences expérimentale autant en science sociale qu'en IA).

Sur l'aspect pratique de la discussion. Je ne vois pas comment on peut dire que connaitre un delete est « complétement en dehors du domaine de prédilection d'un candidat » quand celui-ci postule sur du C++, c'est quand même un brin exagéré ...

Tester les bases pour un recruteur est un très bon moyen de filtrer les candidats.

[Dross]

Je me prononcerai pas sur les aspects C++ (j'en ai touché qu'étant étudiant) mais pour le coté "questions d'entretiens" je suis toujours ambivalent sur les trucs un peu pointus/bas niveau/question académiques/truc qu'on utilise pas au quotidien.

Bien franchement si on me demande de recracher un truc d'algo en entretien, je décrirai plutôt "comment" je me comporterai dans une situation qui nécessiterai cette connaissance, que de recracher ladite connaissance. Car personnellement je trouve que c'est le plus parlant. D'ailleurs c'est ce dont je parle le plus en entretiens : qu'est-ce que j'ai fais, quels problèmes j'ai rencontré, comment je les ai résolu (ou tenter de résoudre) comment j'ai réussi / échoué et pourquoi. En général ça marque un max de points et on m'emmerde pas avec des questions à la con.

Et concernant la capacité de juger de la qualité technique d'un candidat : la période d'essai est justement là pour ça, vous aurez l'heure juste et ça vous évitera de juger sur un reflet de qualité franchement questionnable. Rien ne vous protégera d'un gars qui pourrai performer en entretien et être une véritable plaie une fois en poste. A mon avis, plutôt que de passer des mois à chercher le candidat parfait (comme ça se fait parfois en France) on ferai mieux de mettre à l'essai le premier qui semble faire l'affaire et le virer si ça va pas quelques jours/semaines plus tard.

[Orhin]

Quant aux math, pour moi elles sont nécessaires pour tout bon développeur. Ou du moins, elles facilitent grandement l'apprentissage des langages et de nombreux concepts liés à ces langages.

Plus que les maths c'est surtout la capacité d'abstraction qui est très utile en info.
Est-ce qu'apprendre les maths aide à l'améliorer ? Certainement.
Est-ce que c'est le seul cursus qui permet de le faire ? J'en doute.

Tout ce que je veux dire c'est que cette histoire de couche d'apprentissage ne me semble pas juste. C'est normal de se spécialiser de nos jours, et ne pas connaître les rouages des tonnes de couches d'abstractions qui sont en dessous de sa spécialité n'empêche pas d'être compétent. Bien sûr ça ne fait pas de mal d'être au courant, mais ce n'est pas sur des choses complètement en dehors du domaine de prédilection du candidat qu'un recruteur devrait le tester, sous prétexte que c'est "les bases".

D'un point de vue purement « méthode d'enseignement » et science de la formation du cerveau, cette histoire de couche d'apprentissage est un fait scientifique démontré dans le domaine des sciences cognitive (première formulation par Piaget, puis confirmation successive par la neurobiologie puis par les sciences expérimentale autant en science sociale qu'en IA).

Non mais là vous ne parlez pas de la même chose et vous dites tous les 2 un truc juste.

Bien franchement si on me demande de recracher un truc d'algo en entretien, je décrirai plutôt "comment" je me comporterai dans une situation qui nécessiterai cette connaissance, que de recracher ladite connaissance. Car personnellement je trouve que c'est le plus parlant. D'ailleurs c'est ce dont je parle le plus en entretiens : qu'est-ce que j'ai fais, quels problèmes j'ai rencontré, comment je les ai résolu (ou tenter de résoudre) comment j'ai réussi / échoué et pourquoi. En général ça marque un max de points et on m'emmerde pas avec des questions à la con.

Ceci.
Les capacités d'analyse, de recherche d'information et d'adaptation sont bien plus importantes pour un bon ingénieur que les connaissances purement théoriques.

[Foksadure]

Non mais là vous ne parlez pas de la même chose et vous dites tous les 2 un truc juste.

Je rejoins hijopr sur le fait qu'il y a probablement beaucoup de personnes avec des profils qui ne sont ni scientifiques ni même techniques, qui sont formées juste ce qu'il faut pour de la programmation "Ikea" et qui s'en sortent très bien.
I.e. s'appuyer sur des bibliothèques et des modules fonctionnels conçus et maintenus par des gens plus compétents que soi, et surtout savoir s'insérer dans un existant complexe sans forcément en maîtriser tous les rouages.

[William Vaurien]

Pour avoir travailler dans un lieu avec des centaines d'éminents scientifiques, le constat était que c'était de piètres développeurs. A tel point qu'un des devs de l'équipe "des trucs administratifs chiant pas scientifique en java" (la mienne) avait était débauché pour tenter de remettre de l'ordre dans un bordel monstrueux de Python/C++.
En gros chaque chercheur de chaque équipe avait ses bouts de pythons inmaintenables et quand le chercheur s'en allait, plus personne ne pouvait rien faire du code. Il n'y avait ni architecture commune, ni gestionnaire de source, ni standard de code. Le seul truc commun c'était les libs scientifiques et de dessins en C++ et/ou la glue python qui allait avec.
Et évidemment le code était toujours le plus concis et 'malin' possible, donc très dur à comprendre même pour d'autres chercheurs aux profils similaires.

Pour moi c'est clairement deux mondes distincts les "sciences" (maths/physiques/bio) et l'informatique. C'est des compétences finalement très différentes, même la capacité d'abstraction est différente: un matheux peu abstraire un algorithme en une formule ésotérique incompréhensible par le commun des mortels.
Un développeur sera capable d'abstraire un comportement pour le modéliser et le rationnaliser. Pourtant le cursus pour devenir dev c'est encore et toujours par les maths, et quand je dis "je suis ingé en informatique" j'ai souvent droit à "tu dois être balaise en Maths alors !" (en plus "de mon imprimante est en panne"...) alors qu'en fait je suis plutôt moyen.
Il y a tout une frange de dev qui sont aussi des matheux ou qui utilisent des outils mathématiques avancés, mais j'ai l'impression que c'est une minorité...

J'ai pu constater aussi que des devs juniors avec un parcours académique scientifique très poussé (genre thèse en physique nucléaire) luttaient tout autant que les autres avec des concepts d'abstraction type les proxy de Spring (AOP pour gérer les transactions par exemple).

Et pour revenir au sujet du recrutement, c'est vrai que c'est compliqué. Les petits projets maison c'est très sympa mais une frange de dev peut ne pas avoir le temps de consacrer une dizaine d'heures ou plus de sa semaine pour faire un TP. Le recruteur va aussi devoir prendre du temps pour bien éplucher tout ça. Les QCMS et autres tests sont toujours un peu nazes (périmés, à côté de la plaque, trop simple, trop compliqué)... Les énigmes à la Google (ils font encore ça ?) je trouve ça pas terrible non plus. C'est finalement assez compliqué de trouver le bon candidat...

[Lazyjoe]

Pour avoir travailler dans un lieu avec des centaines d'éminents scientifiques, le constat était que c'était de piètres développeurs. A tel point qu'un des devs de l'équipe "des trucs administratifs chiant pas scientifique en java" (la mienne) avait était débauché pour tenter de remettre de l'ordre dans un bordel monstrueux de Python/C++.
En gros chaque chercheur de chaque équipe avait ses bouts de pythons inmaintenables et quand le chercheur s'en allait, plus personne ne pouvait rien faire du code. Il n'y avait ni architecture commune, ni gestionnaire de source, ni standard de code. Le seul truc commun c'était les libs scientifiques et de dessins en C++ et/ou la glue python qui allait avec.
Et évidemment le code était toujours le plus concis et 'malin' possible, donc très dur à comprendre même pour d'autres chercheurs aux profils similaires.

So true.
Dans mon labo, vu que les codes sont aussi utilisés par des partenaires industriels on a une mini-équipe qui bosse uniquement sur l'intégration et la qualité du code pour être sûr que ce qui doit sortir de la partie recherche est utilisable par d'autres.

[Teocali]

Et pour revenir au sujet du recrutement, c'est vrai que c'est compliqué. Les petits projets maison c'est très sympa mais une frange de dev peut ne pas avoir le temps de consacrer une dizaine d'heures ou plus de sa semaine pour faire un TP. Le recruteur va aussi devoir prendre du temps pour bien éplucher tout ça. Les QCMS et autres tests sont toujours un peu nazes (périmés, à côté de la plaque, trop simple, trop compliqué)... Les énigmes à la Google (ils font encore ça ?) je trouve ça pas terrible non plus. C'est finalement assez compliqué de trouver le bon candidat...

De notre coté, on a fait un choix : on écrème les CVs sur des critères sommaires mais peu restrictif (langue, localisation vraiment pas compatible, expérience annoncée vraiment trop réduite par rapport aux attentes), et on balance un test technique en ligne via la plateforme CodingGame (QCM et de vrai exos de prog), et on prendra le haut du panier pour un entretien technique qu'on fera sans doute par visio, l'idée étant surtout de garder le coté technique pur au strict minimum (juste s'assurer que le candidat est bien celui qui a passé le test technique) mais surtout de voir si l'etat d'esprit est compatible avec le reste de l'équipe.

D'ailleurs, si y'a des devs Java/Spring (une connaissance de kotlin est un vrai plus mais pas indispensable) dispo sur Lyon et ses environs (ça sera du full TT dans un premier temps, mais on passera sans doute a un ou deux jours en local a moyen/long terme, les locaux seront choisis en fonction des dispos et de la localisation des membres de l'equipe), faites péter les CVs. Je mord pas (Shotmaster peut témoigner) et le projet est plutot cool.

[gros_bidule]

Je hais SpringBoot. Je hais SpringBoot. Je hais SpringBoot. Bon, je l'adore et le hais à la fois.

Passage de SpringBoot 2.5.x à 2.6.0 -> tous mes messages d'erreur sont vides (API REST, Spring Security et Spring Validation). Après plusieurs jours je découvre que, si tu utilises Spring Security, il fallait donner accès à "/error". Je découvre aussi que cette règle ne date pas d'hier (j'ai évidemment épluché les changenotes et guides de migration), mais j'avais une config particulière qui a bypassé ça durant des années sans le savoir et donc ça fonctionnait bien, je n'avais jamais pris le temps de monter un projet hello-world avec Spring Security pour me rendre compte (je l'avais fait sur à peu près tout : Spring Batch, Cache, Data, Retry, Cloud, etc, mais comme un con jamais Security, c'est bête).
Purée de purée de purée, tout ça pour ça.

[Teocali]

ah. ah. ben tu vas rire. c’est exactement le souci que j’ai en ce moment.

[Kamasa]

J'ai fait du Spring pendant des années. Je connais assez bien. Je m'y étais habitué.

Mais ça fait 1 an que je bosse sur une application sans serveur d'application (sur une architecture Cloud toute basée sur des lambdas AWS) et j'ai tellement plus envie de refaire du Spring

[William Vaurien]

c'est intéressant et intriguant ton commentaire Kamasa, tu pourrais détailler comment ça se passe une appli sans serveur ? Je suis aussi habitué à Spring/SpringBoot que je connais suffisamment bien pour servir de référent pour mon équipe alors qu'en fait j'ai juste lu (et compris) un peu la doc. Je suis à l'aise avec (sauf Spring Secu que je trouve ... cryptique et Spring Batch qui est bien trop compliqué pour le service rendu dans notre cas) et du coup j'ai du mal à imaginer faire sans...

[Teocali]

Kamasa, tu m'interromps si je dit de la merde, mais en gros, le serverless, c'est une application par fonction (pour faire simple) que tu refiles a un herbergeur cloud, et c'est lui qui s'occupe de tout le boiler plate : Scale up/scale Down, hebergement, routage, et tutti quanti. Y'a toujours un serveur, of corse, mais c'est absolument plus toi qui t'en occupes. En tout cas, c'est comme ça que j'ai compris le truc. Les technos derrières, c'est les lamba pour AWS et Google Functions pour Google cloud.

[William Vaurien]

Ok, mais en quoi ça change le besoin d'un framework ? Je vois des équipes faire des micros services avec Springboot pour l'accès aux données, les contrôleurs REST et toute la panoplie.
La sécurité est déléguée via une API gateway.

J'étais intéressé par le côté sans Spring.

[gros_bidule]

Serverless, ce n'est pas server d'application less ?
J'entends par là :
- une webapp SpringBoot packagée en war et installée dans Tomcat -> serveur pas less
- une webapp SpringBoot packagée en jar et qui embarque un tomcat embed -> serverless, car c'est le jar que tu lances directement

Des applis serverless je peux te donner un exemple, c'est ce qu'on fait à mon taff (Spring je n'en fais plus que sur des projets perso et projets démo pour ne pas perdre la main ) :
on gère l'infra d'un FAI via des microservices python, + quelques applis serveurs tout de même. Les microservices python sont effectivement chacun liés à une tâche précise (ex : installer des routeurs virtualisés), et techniquement on a un dockerfile qui lance python3 monPointDentreePython.py, et roule ma poule : script helm et on met ça dans des pods Kubernetes.
On n'utilise pas de "framework" (au sens lourd, genre Jango, etc) dans nos microservices Python car on n'en ressent pas le besoin, mais on utilise plein de libs. Pas besoin d'un framework quand ton script tient dans une fonction main et qu'une lib tierce suffit pour communiquer avec le système dont tu as besoin (requêtes SQL, Mongo, Kafka, HTTP, SSH, etc). Certains écoutent sur HTTPS et reçoivent des ordres (configurer un routeur X avec la config Y), d'autres sont autonomes (pool en continu d'un topic kafka + réaction en fonction des messages lus).
Mais honnêtement, on serait une équipe Java-iste, on ferait des microservices SpringBoot, ça marcherait super bien, ne serait-ce que pour l'injection de dépendances, la gestion de la config, tous le helpers etc. Un framework c'est tout de même super pratique quand tu le maîtrises. Là en Python sans gros framework, on s'est développé une armée de helpers, malgré les libs tierces.
Et nos microservices n'ayant pas de contrainte sur le temps de démarrage, même un gros microservice (certains disent migroservice ^^) SpringBoot bien lent à démarrer ne poserait pas problème. Je dis ça car on entend souvent qu'un microservice "doit" démarrer vite, c'est pas vrai (et que SpringBoot serait lent, c'est aussi faux, juste que les gens ne le maîtrisent pas). Une lambda Amazon éphémère que tu paies à la seconde ok, mais un microservice qui va exister 6 mois et hébergé sur ta propre infra, tu te fiches que ça démarre en 1s ou 10s.
Nota : on fait du Python car l'équipe de maintenance fait du Python.

[TwinBis]

Non serverless ce sont ce qu'on appelle les Lambdas ou Functions (en fonction du vendeur).

Donc pas de Tomcat du tout, juste des méthodes.

[gros_bidule]

Haaa ok, mais pourquoi on ne dit pas juste fonction
Ton serveur c'est Kubernetes

[William Vaurien]

Et j'aurais aimé en savoir un peu plus (juste un peu, pas un article de blog) sur comment passer d'un dev avec Spring (ou JEE) en monolithe ou micro-service à un dev serverless avec "juste des méthodes".