Carnet de notes

Catégorie : Vie professionnelle

  • Fin ou trans­for­ma­tion d’un métier

    BD tirée de CommitStrip. Première case: le chef/commercial parle avec l'ingénieur informaticien. Case 1 : le commercial vient voir l'informaticien, un mug à la main. L'informaticien est sur son PC, un mug à côté aussi. Commercial : un jour on n'aura plus besoin de codeur. On aura juste à définir des spécifications et ça générera automatiquement une application. Case 2 : le commercial est en train de boire dans son mug. Infoteux, devant son PC et un mug de café : T'as raison, il suffira simplement d'écrire des spécifications complètes et précises et pouf, plus besoin de codeur ! Commercial, l'air satisfait : c'est ça ! Case 3. Infoteux : Et tu sais comment on appelle des spécifications suffisamment complètes et précises pour qu'un programme puisse générer une application ? Commercial, dubitatif : Euh... Non ? Case 4. Informaticien, l'air blasé, pointant son clavier : Du code. On appelle ça du code. Le commercial est tellement surpris qu'il penche son mug par inadvertance et renverse un peu le breuvage sacré. (le alt n'est pas de moi et à été honteusement repompé)
    « Il suffira d’écrire des spéci­fi­ca­tions complètes et précises »

    Je revois cette planche de BD dans une conver­sa­tion et je trouve qu’elle passe à côté d’un élément fonda­men­tal : On ne trans­met pas juste­ment pas de spéci­fi­ca­tions complètes et précises au déve­lop­peur.

    Complé­ter, préci­ser

    Une grosse partie du boulot de déve­lop­peur c’est complé­ter et préci­ser ces spéci­fi­ca­tions incom­plètes et impré­cises.

    Complé­ter, préci­ser, le tout à partir du contexte projet, des habi­tudes et de l’im­pli­cite courant… C’est le cas d’usage exact des LLM.

    On essaie de leur faire faire « de l’IA » mais ces outils sont en premier lieu de formi­dables outils de complé­tion à partir d’un contexte et de l’im­pli­cite habi­tuel pour un type de tâche donnés. Bref, le travail d’un déve­lop­peur.

    Refor­mu­ler dans un langage plus formel

    Que fait le déve­lop­peur d’autre ? Il traduit ça dans un langage formel (le code).

    Refor­mu­la­tion, ça aussi c’est le cas d’usage parfait pour les LLM.

    La dernière tâche du déve­lop­peur est très tech­nique. C’est de l’in­gé­nie­rie logi­cielle, réus­sir à tout agen­cer pour que ce soit faci­le­ment testable, main­te­nable, évolu­tif, etc.

    Une grosse part de cette dernière tâche est basée sur l’ap­pren­tis­sage et la repro­duc­tion de motifs ou de pratiques. Le LLM est aussi parfait pour ça.

    Il reste aussi qu’il s’agit de rendre les choses testables, main­te­nables et évolu­ti­ves… par des humains. Peut être qu’une partie de ce besoin va dispa­raître ou du moins évoluer le jour où le code sera plus mani­pulé par des LLM que par des humains. Leurs besoins, faci­li­tés et diffi­cul­tés sont forcé­ment diffé­rents des nôtres.

    Appren­tis­sage

    Oui il faudra faire des aller-retours avec l’ou­til pour complé­ter ou corri­ger sa complé­tion. Il en va de même du déve­lop­peur, surtout lors de sa première arri­vée dans une équipe ou dans un projet.

    Oui un LLM fera des erreurs d’in­ter­pré­ta­tion. Un déve­lop­peur aussi.

    Est-ce que les allers-retours et erreurs seront plus impor­tants que ceux avec un déve­lop­peur ? Aujourd’­hui proba­ble­ment, demain je n’en sais rien, peut-être.

    Est-ce que ces allers-retours et correc­tions seront plus coûteux qu’un déve­lop­peur ? Alors là je n’en sais rien, mais je ne parie­rai pas dessus.

    Besoin d’ex­per­tise

    Est-ce qu’on aura toujours besoin d’un déve­lop­peur et d’ex­per­tise pour accom­pa­gner l’ou­til auto­ma­tique ? Très proba­ble­ment sur une partie, oui, mais proba­ble­ment moins en propor­tion qu’on n’en a besoin aujourd’­hui.

    Très certai­ne­ment aussi que le travail sera diffé­rent de celui d’aujourd’­hui, et que savoir inter­agir avec les outils auto­ma­tiques sera essen­tiel dans les compé­tences requises. C’est déjà partiel­le­ment le cas aujourd’­hui. On ne code pas comme au temps des cartes perfo­rées. C’est juste que les outils vont chan­ger et vont très proba­ble­ment prendre une plus grande place.

    Certi­tudes

    Je ne donne que mes certi­tudes, mes croyances et mes craintes. Je ne connais pas plus le futur que d’autres. J’ai juste le senti­ment, sans aucune tech­no­béa­ti­tude, qu’il est en train d’ar­ri­ver.

    On fait faire, dire ou espé­rer plein de choses quand on parle d’IA. Il ne s’agit pas de voiture volantes et autres IA sentientes ici.

    Ici je parle LLM, complé­tion et refor­mu­la­tion de textes. Je peux me trom­per et je ne mets ma main au feu à propos de rien, mais je me base sur des capa­ci­tés qui sont déjà là aujourd’­hui.

    Juger le futur

    Est-ce souhai­table socia­le­ment ? Est-ce soute­nable pour la planète ? Comment va-t-on gérer la tran­si­tion au niveau de la société ?

    Ce sont honnê­te­ment d’ex­cel­lentes ques­tions dont j’ai­me­rais avoir les réponses.

    Le fond n’est pas si je souhaite ou pas ce futur, c’est que je constate qu’il est en train d’ar­ri­ver, et que je veux pas faire semblant de l’igno­rer.

    Pour les futurs déve­lop­peurs

    Je crains une vraie crise dans le métier dans quelques années. Certains, beau­coup, vont rester sur le carreau.

    Je ne sais pas si j’en­cou­rage les plus jeunes à se lancer dans le déve­lop­pe­ment infor­ma­tique. Si vous le faites, je vous encou­rage à à la fois deve­nir très vite expert (parce que j’ima­gine qu’on aura besoin des experts pour complé­ter les LLM), et apprendre à coder via les LLM (pas juste « avec ») même si ce n’est pas rentable aujourd’­hui.

    Je suis conscient de la contra­dic­tion à deman­der aux juniors de deve­nir immé­dia­te­ment expert.

    Je ne suis pas certain qu’il y ait un avenir pour les déve­lop­peurs moyens, ou pour les junior. Leur valeur ajou­tée sera faible et il y aura dans un premier temps suffi­sam­ment de déve­lop­peurs formés pour jouer les experts sans devoir inves­tir des années dans des compé­tences inter­mé­diaires qui pour­raient deve­nir experts un jour.

    Pour choi­sir son futur

    Si vous êtes très tech, faites des maths, de la mani­pu­la­tion de données, des statis­tiques, et globa­le­ment de l’IA. Les places seront peut être chères et deman­de­ront des compé­tences plus avan­cées que pour être déve­lop­peur, mais il y aura du travail.

    Si vous avez envie de créer, pour moi l’ave­nir est plus dans les métiers du produit, des product mana­ger avec une colo­ra­tion et un inté­rêt tech­nique. Ça veut dire savoir parler busi­ness, marché, client, etc.

    Pour les déve­lop­peurs actuels

    Pour ceux qui sont encore majo­ri­tai­re­ment les mains dans le code, je vous conseille de passer au plus tôt dans le déve­lop­pe­ment via les LLM.

    Je sais que vous n’en ressen­tez pas le besoin, que ces outils font des erreurs que vous ne faites pas, que ça ne vous accé­lère pas aujourd’­hui.

    Le fond c’est que les plus jeunes ça les accé­lère, que demain ils auront déve­loppé leur exper­tise mais sauront aussi utili­ser ces outils, et qu’ils en compren­dront assez les limites et les défauts pour être l’ex­pert dont le métier aura besoin.

    Il y aura encore long­temps de la place pour des vieux experts du code pour la main­te­nance et pour les gros groupes qui ont plusieurs géné­ra­tions de retard. Il y a aujourd’­hui toujours besoin de déve­lop­peurs et Cobol. La vraie ques­tion : Est-ce le posi­tion­ne­ment auquel vous aspi­rez ?

    Et moi, direc­teur tech­nique ?

    Honnê­te­ment je ne sais pas. Je ne sais pas bien quel sera mon avenir.

    Le mana­ge­ment de grandes équipes de déve­lop­pe­ment risque d’être aussi has been demain que les vieux DSI dépas­sés d’aujourd’­hui. Est-ce que je veux être de ceux là ? Je ne sais pas.

    J’ado­re­rais prendre la tête d’équipes de data science, mais j’ima­gine qu’il y a une batte­rie de docteurs sur les rangs, avec une exper­tise qui me ferait défaut.

    Entre temps je vais proba­ble­ment au moins essayer d’in­té­grer des équipes qui ont sont alignées avec tout ce que je viens d’écrire.

  • Le chef qui ne décide pas

    Ceci est un brouillon qui mérite un peu de réflexion mais pour lequel je suis preneur dès à présent de savoir ce que ça vous inspire, ou comment vous vous diffé­ren­ciez par rapport à cette vision.

    En pleine intros­pec­tion, je regarde les déca­lages par rapport aux attentes qui m’ont été expo­sées par le passé.

    Une de celle là c’est celle du rôle du chef dans les choix et déci­sions.

    Je suis là pour permettre de penser et agir collec­ti­ve­ment, pas pour diri­ger des singes savants.

    Crédo person­nel

    Coro­laire : C’est aux sachants proches du terrain de faire les choix et prendre les déci­sions, pas au mana­ge­ment.

    Mon rôle c’est de les mettre en capa­cité, de m’as­su­rer qu’on mette les bons enjeux, les bons moyens, les bons process pour arri­ver à ce qu’on ait les bonnes personnes pour prendre les bonnes déci­sions au bon moment sur les bons sujets.

    Parfois, souvent, ça veut dire donner une direc­tion, mais dans l’idéal même cette direc­tion peut venir des équipes.

    Dans la réalité je prends plein de déci­sions, tout le temps, avec plai­sir et sans tergi­ver­ser, mais elles sont sur mes sujets, pas ceux de mes équipes, ou le moins possible.

    Je me rappelle l’in­ter­ro­ga­tion d’une équipe il y a plusieurs années à propos d’une mise à jour mineure de Post­greSQL. Fallait-il la faire ?

    C’était les premiers mois de la prise de poste. L’équipe n’avait pas eu de direc­teur avant et ne savait pas trop quoi en attendre.

    J’ai posé les ques­tions, savoir s’il y avait un enjeu de sécu­rité, si ça corri­geait un de nos problèmes, s’il y avait un effort ou un risque parti­cu­lier à la montée en version.
    L’équipe avait les réponses, il n’y avait ni enjeu ni risque, j’ai dû répondre quelque chose proche de « comme vous voulez ».

    Cette anec­dote a mis en évidence plus d’un an après le déca­lage entre ma concep­tion du rôle et celle de mon président de l’époque. Il aurait voulu quelqu’un qui « donne le ton à l’équipe », dès le début.

    Ce déca­lage est reve­nue plusieurs fois dans mon histoire, en partie parce mon curseur entre la mise en capa­cité et la prise de déci­sions est parti­cu­liè­re­ment à gauche, mais pas que pour ça.

    Il y a dans l’uni­vers profes­sion­nel une culture du chef qui reste assez marquée et à laquelle je n’adhère pas. En zone de stress j’ai vu la plupart des direc­tions repar­tir à la recherche d’un leader éclairé qui aligne­rait tout le monde en prenant les bonnes déci­sions inspi­rantes que les autres n’au­raient qu’à suivre.

    Je n’y crois pas, pas plus en entre­prise qu’en poli­tique. Au mieux ça donne des effets concrets et rapide mais on se pren­dra très fort le mur quand le chef pren­dra une mauvaise déci­sion ou s’en ira. Et ça arri­vera.

    Même avec 25 ans de bagages, je n’ai jamais la préten­tion de dire « ta gueule je sais ». Je peux me trom­per.
    Je me trompe encore. Si je décide et que j’at­tends des équipes qu’ils prennent du recul sur les enjeux pour m’ar­rê­ter quand je me trompe, ne suis-je pas en train d’in­ver­ser les rôles ?

    Mon objec­tif à moi c’est l’op­posé, c’est me rendre dispen­sable, faire en sorte que tout puisse tour­ner sans moi, y compris les déci­sions stra­té­giques et les sujets sensibles.

    Si je fais bien mon travail, je peux arrê­ter de travailler sans que ça ne se voit. Mon but est fina­le­ment de ne servir à rien.

    Consé­quence de mon posi­tion­ne­ment

    En aparté : Les deux posi­tions en exergues ont — j’es­père — l’air saines mais c’est loin d’être une évidence pour tous ni facile à porter. Elles ne faci­litent entre autres pas la valo­ri­sa­tion de mes propres actions auprès de mes propres enca­drants quand eux croient encore consciem­ment ou incons­ciem­ment au grand leader charis­ma­tique qui dirige tout.

    J’ai pu indi­vi­dua­li­ser trois phases dans ces cas là :

    1. Une première zone miti­gée, parce que la mise en place d’une respon­sa­bi­lité aux équipes ne se fait pas en un jour, et que ça passe par des échecs et une zone de flou quant à qui dirige.
    2. Une zone de confiance ensuite, parce que la machine commence à tour­ner et que les résul­tats sont là.
    3. Une zone de défiance voire de rupture de confiance quand il y a une période de stress ou de craintes pour de forts enjeux. Le fait de ne pas voir l’ac­tion directe du grand leader fait poser des ques­tions.

    Au-delà d’éven­tuels diffi­cul­tés concrètes — j’en ai, comme tout le monde — j’ai encore beau­coup de travail sur la commu­ni­ca­tion autour de mon approche : savoir comment montrer, expli­ci­ter et rassu­rer.

  • Choix d’équi­libre

    Je suis convaincu que le télé­tra­vail fonc­tionne, et que la ques­tion se situe surtout au niveau des orga­ni­sa­tions.

    Je ne saute pas pour autant à la conclu­sion que tout doit passer au télé­tra­vail et que c’est la seule orga­ni­sa­tion valable ou saine.

    Une fois que l’or­ga­ni­sa­tion est assez bonne pour permettre le télé­tra­vail, le reste est une ques­tion de choix et de culture. Tout est légi­time.

    Je ne vois pas plus de raison d’im­po­ser le presen­tiel à ceux qui pour­raient télé­tra­vailler que d’im­po­ser les condi­tions du télé­tra­vail à ceux qui auraient besoin ou envie de face à face avec leurs collègues.

    Vouloir une entre­prise pure­ment présen­tielle est aussi légi­time qu’une entre­prise qui permet le télé­tra­vail.

    Allez juste dans l’or­ga­ni­sa­tion qui vous corres­pond. Le télé­tra­vail n’est pas l’idéal pour tous.

    Il y a aussi des inter­mé­diaires qui peuvent avoir du sens pour vous.

    Person­nel­le­ment j’aime bien avoir le choix en open bar. Si je peux et que les bureaux ne sont pas loin, je vien­drai avec plai­sir 2  à 3 jours la plupart des semaines (mais pas forcé­ment toutes), et je préfère avoir un envi­ron­ne­ment où on se voit quand même tous au moins deux à trois jours par mois.

    Ça peut être moins, ou bien moins, mais j’ai du mal aujourd’­hui à m’ima­gi­ner ne voir les collègues en face à face qu’une fois l’an. Je ne l’ai jamais fait, peut être que c’est une crainte infon­dée et que ça me deman­dera juste d’or­ga­ni­ser ma vie autre­ment.

    Je crois par contre que j’au­rais du mal à m’im­po­ser la venue au bureau tous les jours toutes les semaines, ou même 4 jours par semaine toutes les semaines : J’ai besoin de me retrou­ver aussi moi-même certains jours pour mon équi­libre. L’idéal étant qu’on me fasse assez confiance pour choi­sir lesquels en fonc­tion du moment.

  • Le télé­tra­vail comme révé­la­teur de mauvaises orga­ni­sa­tions

    Le télé­tra­vail fonc­tionne.

    Pas partout. Ça demande une orga­ni­sa­tion qui va avec. On parle d’écrit, de commu­ni­ca­tion, d’im­pli­ca­tion, de prise de respon­sa­bi­li­tés et de confiance, entre autres.

    Ce que ça demande me paraît toute­fois perti­nent même pour qui souhaite rester en présen­tiel. Peut être que si pour vous le télé­tra­vail ne fonc­tionne pas, c’est un bon révé­la­teur de ce qui ne fonc­tionne déjà pas, télé­tra­vail ou pas, mais qui est d’aujourd’­hui contourné d’une façon ou d’une autre.

    Le télé­tra­vail démul­ti­plie le problème, il ne le crée pas.

    Corri­gez vos problèmes. Vous aurez tout le loisir de quand même garder une culture présen­tielle si vous le souhai­tez, mais elle sera d’au­tant plus fonc­tion­nelle.

    Impli­ci­te­ment : prévoir de rester en présen­tiel le temps de corri­ger les problèmes de culture et d’or­ga­ni­sa­tion (parce que le télé­tra­vail les démul­ti­plie­rait) me semble tout à fait légi­time tant qu’ef­fec­ti­ve­ment on prévoit un plan pour les corri­ger.

    C’est aussi quelque chose à entendre pour les sala­riés qui ne voient que l’ab­sence de perte de produc­ti­vité dans leur propre travail indi­vi­duel. Parfois, souvent, les problèmes induits sont au niveau de la colla­bo­ra­tion, de la coor­di­na­tion, du soutien humain, de l’ali­gne­ment global, de l’émer­gence d’idées nouvelles ou de trans­ver­sa­lité.

    Les mana­gers et direc­teurs, de par leur rôle, sont plus amenés à perce­voir et prendre en compte ces aspects. Écou­tez-les aussi au lieu de juste penser qu’ils ne font pas confiance.

    Est-ce qu’il y a des bonnes pratiques d’or­ga­ni­sa­tion du télé­tra­vail qui ne seraient pas aussi des bonnes pratiques en présen­tiel ? Possible, mais je n’en ai pas en tête.

  • Fréquence des face à face

    Le télé­tra­vail fonc­tionne. Je ne le remets pas en cause.

    Dans mon expé­rience en deux ans dans une entre­prise sans bureaux, on avait l’am­bi­tion de se voir toutes les 6 semaines dans un co-working à Paris.

    On orga­ni­sait des ateliers mais je suis assez convaincu que se voir était plus impor­tant que les ateliers eux-mêmes.

    L’am­bi­tion était de 6 semaines. Parfois on a fait légè­re­ment moins, souvent on a fait plus. J’ai constaté une dété­rio­ra­tion visible de la commu­ni­ca­tion et de la bonne colla­bo­ra­tion dès qu’on dépas­sait 4 à 6 semaines. C’était comme un pivot, pas quelque chose de graduel.

    Je ne sais pas si la dégra­da­tion que j’ai vu après 4 à 6 semaines nous était propre ou si elle est plus univer­selle.

    Le résul­tat c’est que dans une entre­prise suivante on a demandé aux télé­tra­vailleurs de reve­nir au moins une période de deux jours par mois, idéa­le­ment consé­cu­tifs.

    Je l’ai vu ailleurs mais je n’ex­clus pas que ce soient juste les têtes gouver­nantes qui ont parlé entre eux et repris l’idée. La tech française c’est énor­mé­ment de cargo cult où on copie ce qui se fait ailleurs.

    Ce « deux à trois jours par mois » me semble toute­fois un bon compro­mis là où c’est possible. Ça fonc­tion­nait pour nous.

    La commu­ni­ca­tion passait moins bien avec ceux qui ne jouait pas le jeu (sans qu’il me soit clai­re­ment possible de dire quel était la cause et quel était l’ef­fet entre leur faible venue et la diffi­culté de colla­bo­ra­tion).

    Bref, si je peux choi­sir et que les distances le permettent, je garde­rais bien ce « deux à trois jours par mois en commun », sous une forme ou une autre (certaines entre­prises donnent juste des budgets aux équipes pour se voir, sous la forme qu’elles préfèrent).

    Si se rencon­trer souvent ce n’est pas envi­sa­geable, l’éven­tuel coût induit que je décris ne me semble pas insur­mon­table non plus.

    Chaque orga­ni­sa­tion a ses propres faci­li­tés et diffi­cul­tés. Le présen­tiel aussi, qu’on voit moins telle­ment on y est habi­tué. Il s’agit juste de trou­ver la bonne orga­ni­sa­tion qui compense avec d’autres béné­fices.

  • Le télé­tra­vail fonc­tionne

    Je ne sais pas comment le tour­ner autre­ment. Ça peut deman­der des orga­ni­sa­tions adap­tées. Il y a, forcé­ment, des avan­tages et des désa­van­tages, voire des coûts. Ce n’est pas non plus la seule orga­ni­sa­tion légi­time ou perfor­mante et il y a d’autres choix possibles mais : ça fonc­tionne.

    Dire le contraire serait juste insul­tant pour les travailleurs de plein d’en­tre­prises de toutes tailles, y compris parmi les plus en vues, qui consi­dèrent que c’est une bonne orga­ni­sa­tion pour eux. Je l’ai vu moi-même pendant deux ans avec une boîte sans bureaux.

    Our employees are not children. Spotify will keep them working remotely.

    Si vous pensez que ça ne fonc­tionne pas, le problème est à coup sûr chez vous.

    De manière inté­res­sante, les très grands groupes tech qui sont récem­ment train de reve­nir vers du présen­tiel sont habi­tués à donner des indi­ca­teurs chif­frés pour tout et n’im­porte quoi. Ici, rien pour expliquer les revi­re­ments.

    Ça ressemble beau­coup à des choix idéo­lo­giques de la part des personnes en direc­tion.

  • Équi­va­lence free­lance-salaire

    C’est un sujet casse-gueule. J’avais fait des mouli­nettes bien compliquées par le passé pour faire des évalua­tions.

    On m’a demandé quelques équi­va­lences alors je pose ici ce que j’ai trouvé (pour un équi­valent 5 semaines de CP et 2 semaines de RTT) :

    Brut sala­riéTJM baseavec fraisavec risques
    40 k€ annuel275 € HT435 € HT520 € HT
    50 k€ annuel340 € HT510 € HT610 € HT
    60 k€ annuel405 € HT585 € HT700 € HT
    70 k€ annuel470 € HT660 € HT790 € HT
    80 k€ annuel535 € HT735 € HT880 € HT
    90 k€ annuel600 € HT810 € HT970 € HT
    100 k€ annuel665 € HT885 € HT1060 € HT
    ± 10 k€ annuel± 65 € HT± 75 € HT± 90 € HT
    Équi­va­lence pour un free­lance en SASU

    Le TJM base est pour quelqu’un qui fait des missions longues (6 mois et plus) avec aucun inves­tis­se­ment maté­riel ni poste de travail à ache­ter, aucun frais de fonc­tion­ne­ment, pas de trans­port, aucun arrêt mala­die, sans forma­tion ni confé­rences, et qui ne compte pas son temps commer­cial ou admi­nis­tra­tif.
    Ne faites pas ça.

    Le TJM avec frais je l’ai pris avec un niveau de service que j’es­time élevé : un maté­riel infor­ma­tique Apple haut de gamme, une prévoyance, des jours d’ad­mi­nis­tra­tif, de commer­cial, de la forma­tion avec frais de dépla­ce­ment, et des jours de non factu­rés cause mala­die, etc.
    On est sur du confort tout outillé, plutôt haut de gamme.

    Le TJM avec risque c’est le même +20% pour prendre en compte les risques : les acci­dents maté­riels, la mala­die longue durée, l’in­ter-contrat sans chômage, les litiges juri­diques.

    Tout ça est forcé­ment arbi­traire, surtout le +20%, mais ça permet de se donner une idée. Très proba­ble­ment, mon conseil sera d’es­sayer de se situer entre les deux dernières colonnes. Plus le risque est élévé (première mission, faible enga­ge­ment, métier ou contexte spéci­fique, aban­don de la piste CDI paral­lèle) plus on colle à la dernière.

    Dans tous les cas ça ne sera jamais direc­te­ment compa­rable, c’est plus pour avoir un ordre de gran­deur en tête.

  • Lecture d’Anne Vella : « Dear Soft­ware Engi­neer: It’s Time to Reclaim Your Role »

    Cita­tions d’Anne Vella :

    I totally agree that soft­ware engi­nee­ring should be a lot more than just writing code. When I studied compu­ter science at univer­sity, they taught us how to elicit requi­re­ments, write user stories, design user inter­faces and apply UX prin­ciples, archi­tect complex systems, create test plans, execute test cases and so much more. The whole shebang.

    De mon temps on appe­lait ça de façon mépri­sante les pisseurs de code. Et pour­tant, à cause de la spécia­li­sa­tion, je vois énor­mé­ment d’in­gé­nieurs tomber dans cette caté­go­rie de « déve­lop­peur expert ».

    J’en ai même vu s’in­di­gner qu’on arbitre trop souvent en faveur du produit et des utili­sa­teurs plutôt qu’en faveur d’une qualité de code interne.

    Rien qu’à dire ça je sais que je vais avoir quelques réac­tions assez fortes.

    Personne n’a raison mais ça devient des métiers diffé­rents.

    Steve Yegge recently wrote a follow-up to his contro­ver­sial article The Death of the Junior Deve­lo­per, refra­ming his posi­tion as The Death of the Stub­born Deve­lo­per. He talks about how if you’re not adop­ting Chat-Orien­ted Program­ming, or CHOP, you’re getting left behind

    Je ne joue­rai pas à qui va devoir chan­ger.

    Je suis convaincu que les déve­lop­peurs « produit » vont devoir chan­ger de façon de travailler. Pour autant, le besoin ne va pas dispa­raître, loin de là. Les juniors vont vite avoir des super-pouvoirs. Les seniors qui se reposent un peu trop sur leur savoir acquis, sur la complexité du code set sur le besoin de renou­vel­le­ment perma­nent de techno vont eux avoir du soucis à se faire parce que leur valeur ajou­tée va deve­nir faible.

    On ne rempla­cera pas les déve­lop­peurs « code » experts. L’IA tant vantée n’est quand même qu’un outil statis­tique et je ne la vois pas de si tôt créer du code profond tel qu’on peut en trou­ver dans les biblio­thèques de code qui forment les briques de base. On aura besoin de personnes qui comprennent le fonc­tion­ne­ment de tout ça pour savoir quoi faire (éven­tuel­le­ment assis­tés par de l’ia s’ils le veulent). Là ce sont les juniors qui vont avoir du mal à trou­ver une place.

    Pour être franc je ne sais pas si tout ça est vrai­ment neuf. L’IA va juste démul­ti­plier un effet déjà exis­tant, mais peut être au point de rendre certains posi­tion­ne­ments très diffi­ciles à tenir.

    So dear soft­ware engi­neer, please take heed. If you’re not a “product engi­neer” and have specia­li­sed in writing code, AI may indeed take your job. But this isn’t just a warning – it’s an oppor­tu­nity. It’s time to reclaim your role and return to what soft­ware engi­nee­ring was always meant to be: a craft that combines tech­ni­cal exper­tise with problem-solving, user empa­thy, and busi­ness acumen. The future belongs to those with curio­sity who can see beyond the code.

    Mes propos semblent peut être trop alar­mistes, ou trop futu­ristes. J’ai l’im­pres­sion qu’on passe des paliers très vite.

    Je ne saurais trop conseiller aux déve­lop­peurs qui veulent prévoir leur avenir de sauter sans filet et de passer au CHOP et BATON décrits dans le billet cité.

    Si ça n’ac­cé­lè­rera pas grand chose aujourd’­hui, savoir comment utili­ser ses outils correc­te­ment demande un chan­ge­ment de para­digme et donnera plusieurs longueurs d’avance d’ici quelques années au plus.

    Si vous avez vu le sex appeal des déve­lop­peurs « no code » (non, il n’y a pas contra­dic­tion), ça va vite de démul­ti­plier.

    C’est une croyance de ma part mais elle est très forte.

    Oui, je sais. Il y a aussi à côté d’énormes enjeux éner­gé­tiques. J’ai­me­rais bien qu’on puisse les igno­rer mais je ne le crois pas. Je ne les mets pas de côté.

    Main­te­nant consi­dé­rant le coût des ingé­nieurs, celui de l’usage de ces outils, la valeur qu’on en tire, le futur sera quand même celui là. On peut refu­ser mais il faudra au mieux se prépa­rer à oublier les périodes fastes du point de vue emploi et salaire, pour ceux qui trou­ve­ront un emploi.

    Je n’ai pas la solu­tion à tout ça. Je me contente d’ob­ser­ver.

  • Outil ou collègue

    Mon conseil pour les rares qui me suivent encore et que j’ai pu moti­ver à deve­nir deve­lop­peur: fuyez! Redui­sez vos dettes. Votre train de vie. […] inves­tis­sez tout et prepa­rez vous pour l’hi­ver.

    Je vous garan­tie que avant la fin de votre carrière (voir de la décen­nie) il faudra se recon­ver­tir. Préfé­ra­ble­ment dans un truc manuel.

    On lit toujours plein de choses alar­mistes sur le futur. Tout avance très vite mais les métiers dispa­raissent rare­ment en moins d’une géné­ra­tion. Jusqu’à présent.

    Et pour­tant, vu d’où je l’ai lu, ça m’a fait cogi­ter.

    J’ai repris un peu mes tâches pénibles habi­tuelles via Cursor. Rien de neuf. Je le fais régu­liè­re­ment. Si je trouve la complé­tion auto­ma­tique magique, pour moi c’est un outil en plus, pas de quoi éteindre le métier.

    Là j’ai suivi les traces de Simon Willi­son. J’ai utilisé l’agent et lui ai tout dicté, refu­sant de toucher à un quel­conque fichier direc­te­ment, de résoudre un quel­conque problème tech­nique moi-même.

    J’ai plein de posi­tif et plein de néga­tif mais… mon dieu je ne conseille­rai pas à mon fils de faire du déve­lop­pe­ment. C’est foutu pour lui. Je ne sais pas s’il aurait pu tout réali­ser sans rien savoir, mais ça n’en était pas loin. Dans 2 ans, 10 ans… oui la moitié des tâches de déve­lop­pe­ment au moins se passe­ront proba­ble­ment d’ex­perts tech.

    Ok, c’est de la boule de cris­tal. Je peux me trom­per. Je me suis déjà trompé par le passé. Oui ça ne remplace pas tout mais on a passé un sacré cap. Il me reste 20 ans au moins, la révo­lu­tion se fera pendant ma vie profes­sion­nelle, et elle sera lour­de­ment impac­tée.

  • Anglais ou français ?

    Ma recom­man­da­tion : Travaillez dans la langue mater­nelle de l’équipe aussi long­temps que vous le pouvez.

    Prema­ture opti­mi­za­tion is the root of all evil

    Donald Knuth

    On adore parler de dette tech­nique. Passer à l’an­glais trop tôt c’est une dette orga­ni­sa­tion­nelle, dont il faut payer les inté­rêts chaque jour, et qui se révèle rare­ment rentable.

    Je n’ai jamais eu vent d’en­tre­prise qui ait échoué parce qu’elle n’avait pas anti­cipé la mise à l’an­glais plusieurs années avant. J’ai par contre des dizaines de noms d’en­tre­prises qui ont coulé ou ont stagné parce que la commu­ni­ca­tion n’était pas fluide, ou parce qu’elles ont investi dans trop de choses pour plus tard avant que ce ne soit néces­saire.

    • Utili­ser l’an­glais est-il un besoin pour aujourd’­hui ou pour demain ?
    • Quelle est la proba­bi­lité que ce besoin se réalise vrai­ment ?
    • Le coût d’avoir utilisé le français aujourd’­hui dépasse-t-il vrai­ment celui d’avoir utilisé l’an­glais ?
    • Est-il perti­nent de payer ce coût aujourd’­hui plutôt que demain ?

    Si ces ques­tions semblent orien­tées c’est qu’elles le sont. Je pars du constat que l’uti­li­sa­tion de l’an­glais par des équipes françaises dans leurs échanges et leurs docu­ments n’est pas neutre. Le coût est même élevé.

    En utili­sant l’an­glais je dois en faire un pré-requis de recru­te­ment, évaluer réel­le­ment cette compé­tence lors des entre­tiens, former les personnes déjà embau­chées, et être prêt à me sépa­rer de ceux qui n’at­tein­dront pas le niveau cible.

    Même là, rare sont ceux qui sont bilingues au point d’avoir les mêmes nuances et la même flui­dité dans les deux langues. Il y a une perte de détail en plus d’une perte de compré­hen­sion, parfois même un frein à l’ex­pres­sion qui fait renon­cer en amont.

    Bref, il y a un coût. J’ai plus souvent vu les équipes le mino­rer ou l’igno­rer que le contraire, et au final prendre une dette pendant des années sans retour sur inves­tis­se­ment concret.

    Oui, peut-être qu’un client deman­dera une docu­men­ta­tion en anglais un jour, quand le produit sera inter­na­tio­nal, si tant est que le produit et sa docu­men­ta­tion n’au­ront pas changé d’ici là. Ce jour là on aura un problème de riche et proba­ble­ment que traduire une docu­men­ta­tion bien rédi­gée ne sera pas vrai­ment un élément bloquant. Peut-être par contre qu’a­voir une docu­men­ta­tion en mauvais anglais deman­dera bien plus de temps de réécri­ture.

    Oui, peut-être que les équipes s’ou­vri­ront à l’in­ter­na­tio­nal avec des bureaux ailleurs en Europe ou dans d’autres conti­nents. Peut-être pas, malgré les ambi­tions. Peut-être bien plus tard que prévu. Beau­coup de process vont chan­ger entre temps, et il y aura de toutes façons une période de tran­si­tion avec des locu­teurs fran­co­phones pour faire le pont néces­saires (si tant est que chatgpt ne soit pas suffi­sant en pratique).

    Est-ce que c’est main­te­nant que vous voulez payer le coût, risquer de moins bien se comprendre, de ralen­tir l’or­ga­ni­sa­tion, pour éviter un coût plus tard, une fois que l’en­tre­prise aura réussi et aura les moyens, sans même pouvoir assu­rer que ce futur arri­vera ou s’il arri­vera dans les années à venir ?

    Je suis certain que « oui » est parfois la bonne réponse. Je suis convaincu que c’est l’ex­cep­tion (et que par défi­ni­tion, vous avez toutes les chances de ne pas être dans l’ex­cep­tion).