Journal Et l’intelligence humaine, alors ?

58
22
sept.
2025

disclaimer : ce post pue la dépression. Si tu viens pour l’optimisme, t’es pas au bon guichet.

A l'heure ou 80% des commentaires sur linuxfr parlent de l'IA ou sont rédigés par l'IA ou évoquent l'IA, je me suis interrogé sur l'intelligence humaine et l'intelligence qu'on peut apporter dans son boulot.

Je me rappelle, il y a longtemps, on m’avait dit un truc du genre : "Fais de l’info, tu verras, c’est génial. Tu réfléchiras, tu seras pas juste un presse-bouton. Ton cerveau va vraiment servir à quelque chose." Et bordel… c’était vrai. Au début. Je découvrais des langages tous les mois, je développais des outils, je débuggais des trucs incompréhensibles, j’apprenais, j’étais en feu. Puis un jour j'ai failli devenir manager, mais j'ai réussi à m'échapper en changeant de boite et en restant développeur (youpi!).

Et puis, il y eut cette entreprise. Un projet exceptionnel. Du C bas niveau, des protocoles industriels complexes, obscurs parfois, à décoder, à comprendre. Des bugs improbables, fascinants, qui exigeaient une attention fine, presque chirurgicale. Et des optimisations qui forçaient le respect, comme patcher l’allocateur mémoire pour gagner les 10% de perfs qu'ils manquent pour s'assurer qu'une synchro n'a pas besoin de lock pour gagner 20% en perf au global, tout en restant 100% fiable (si si). C’était exigeant, c’était dense, mais c’était exaltant. Je n’éprouvais même plus le besoin d’écrire du code en dehors du travail: la journée suffisait à nourrir l’esprit. J’étais intellectuellement comblé. Un moment rare. Précieux. Le genre de période ou tu peux rester jusqu'à 23h devant un dump hexadécimal et trouver ça génial \o/

Maintenant?
Rien. Du vide. De l’ennui. 70 de QI. Des réunions stériles, des ateliers à animer, des experts auto-proclamés à écouter réciter des PowerPoint sans âme. On me demande d’analyser du vieux code (s'il était pas si vieux j'aurai dit qu'il était vibe-codé tellement il est laid), avec une doc à la ramasse ou tout simplement fausse. C’est moche, ça plante, ça pue l’usine à gaz bricolée par 3 générations de prestataires. Rien de valorisant. Rien de stimulant. Le seul conseil qu’on me donne face à un bug est d’ouvrir un ticket, ou de réclamer du matériel plus puissant (mais pourquoi??). La réflexion, l’analyse, la compréhension? Non merci.
L’absurde a même pris des formes caricaturales : quatre heures de réunion sur la méthode ITIL v4 (WTF?? lol!!), et une inscription imposée à un séminaire intitulé "Low-code / no-code : comment créer de la valeur sans développeur" (des heures de bonheur je le sens).

Ce qui me pèse le plus, ce n’est pas tant le manque de reconnaissance (auquel, avec le temps, on finit par être indifférent) mais l’absence totale de nécessité de penser. Je dis pas que je suis le plus malin, mais là, aucune intelligence n'est sollicitée. Je pourrais être remplacé par une IA ou un stagiaire : le résultat serait sans doute le même. Et paradoxalement, on me félicite. Parce que je rends mes livrables dans les délais. Parceque mon code compile. Parceque mon code se déploie. Parce que la documentation est à jour. Quelle victoire…

J’ai recommencé à scroller github le soir, comme un ado qui cherche un sens à sa vie. J'ai commencé à documenter un truc qui me titille depuis longtemps sur la mesure de perf, histoire d’avoir l’illusion que mes neurones servent encore à quelque chose.

Alors je te pose la question à toi, lectrice, lecteur qui me lit, peut-être dans la même lassitude silencieuse:
Dans ton travail, as tu encore le sentiment d’exercer une véritable intelligence? Pas simplement celui de résoudre des tickets, ou d’interfacer un formulaire avec une base de données. Mais bien cette sensation rare, précieuse, d’avoir compris un problème de fond, d’en avoir extrait une solution élégante, inattendue, juste?
Ce moment de clarté, où tout s’aligne, où l’on sent que quelque chose s’est éclairé? Histoire de savoir si c'est plutôt normal ou plutôt exceptionnel?

  • # La fin d'une belle période

    Posté par  (site web personnel) . Évalué à 10 (+26/-0).

    Tout pareil.

    Le fait d'arrêter de rechercher a améliorer le code et se dire que de toute facon sur les machines sur lesquelles ca va tourner, il y a des ressources, ça date de bien avant l'arrivée de l'IA.

    L'important c'est que ça tourne.
    L'important c'est que ce soit livré en heure.
    L'important c'est que il y ai du "ROI".

    Avec l'arrivée de l'IA, je viens de comprendre reellement ce que "pisser du code" veut dire. Sauf que je ne pisse pas. Je ne fais que tenir le sexe de l'IA à ce stade.

    Et, oui, on nous remercie pour cela.

    • [^] # Re: La fin d'une belle période

      Posté par  . Évalué à 8 (+6/-0).

      Avec l'arrivée de l'IA, je viens de comprendre reellement ce que "pisser du code" veut dire. Sauf que je ne pisse pas. Je ne fais que tenir le sexe de l'IA à ce stade.

      C'est grossier, mais très évocateur. Je la ressortirai celle-là :)

  • # Travail ≠ Fun

    Posté par  (site web personnel) . Évalué à 10 (+9/-0).

    Salut Octane.. ou qui ? [0]

    Tu sembles rechercher l'émerveillement, celui que beaucoup d'entre nous ont trouvé en alignant leurs premières lignes de code.

    À titre personnel, je le trouve aussi en découvrant les jolies constructions des autres. Et cela tombe bien, il y en a beaucoup ! Cela ne conduit pas forcément à des outils, des projets où autre chose de productive, plus souvent à des petits bouts de code lancés dans le terminal pour découvrir, expérimenter, comprendre et finalement atteindre ce petit bonheur de "ooooh, j'ai compris comment ça marche" et pas seulement "ah, ça marche".

    Je vais prendre un exemple : je suis tombé (ouille) sur https://clang.llvm.org/docs/BoundsSafety.html . Je l'ai lu, ça m'a plu, alors j'ai compilé la version suggérée de clang, et j'ai observé. Fait des expériences, regardé le code généré, comment l'optimiseur s'en sortait, essayé de piéger l'outil etc. Et je pense avoir finalement bien compris. Et ça m'a plu. C'est ça le sentiment que tu cherchais, non ? Le fait que cela ne rentre pas dans le cadre du contrat qui te lie à ton employeur n'est pas si important.

    Un peu comme un biologiste avec sa loupe qui découvre avec ravissement la nature qui l'entoure, tu peux prendre ta loupe informatique et regarder ce qui t'entoure, il y a beaucoup de choses dont on peut s'émerveiller !

    À titre perso, j'en ai fait un petit jeu, et quand je trouve un de ces bonbons informatiques, je les transcris dans un petit article. Avant j'en faisais un journal ici, maintenant je le mets dans une petite série "les codes fantastiques" pour GNU Linux Magazine France (p.e. https://connect.ed-diamond.com/gnu-linux-magazine/glmf-271/les-codes-fantastiques-un-zero-pointe, https://connect.ed-diamond.com/gnu-linux-magazine/glmf-268/les-codes-fantastiques-co-vide , https://connect.ed-diamond.com/gnu-linux-magazine/glmf-270/les-codes-fantastiques-rembourrage ça passe en CC by ND après un délai).

    C'est un peu hors sujet par rapport à ta question sur l'aspect professionnel, mais peut-être pas tant que ça ?

    [0] ceci est un jeu de mot de piètre qualité

  • # reconversion?

    Posté par  (Mastodon) . Évalué à 10 (+11/-0). Dernière modification le 22 septembre 2025 à 10:29.

    Je dirais que si travailler dans l'IT ne payait pas si bien j'aurais fais une reconversion depuis bien plus longtemps. Je ne sais pas si c'est l'aliénation lié au travail dans une grande entreprise, les corporate bullshits, la réunionite et autres problèmes mentionnés dans ce journal ou si c'est juste l'âge et que je préfèrerais faire des trucs avec mes mains.

    J'imagines que plus il y a des gens dans ma/notre situation, moins ça va s'arranger car on autoalimente la merdification de notre travail.

    • [^] # Re: reconversion?

      Posté par  (site web personnel) . Évalué à 3 (+1/-0).

      Je ne sais pas, moi j'ai l'impression de lutter contre à mon échelle. C'est dur, c'est pas drôle mais je pense que ça marche un peu.

      Je refuse les réunions qui puent la merde et j'encourage mes collègues plus jeunes / moins courageux à faire de même. Je remets en question la nécessité des réunions sans objectif clair. Je creuse à fond chaque fois que que quelqu'un sort du bullshit, en espérant que ca le dissuadera de recommencer. Bref, j'essaie de garder la barre technique un peu au dessus du sol, et j'ai l'impression que ça aide.

      Pour ça, ça aide aussi d'avoir des alliés, même silencieux. Si ils ne peuvent qu'encourager en privé ou acquiescer en public c'est déjà bien.

  • # Paradoxe?

    Posté par  (site web personnel) . Évalué à 10 (+8/-1). Dernière modification le 22 septembre 2025 à 10:49.

    Je pourrais être remplacé par une IA ou un stagiaire : le résultat serait sans doute le même. Et paradoxalement, on me félicite. Parce que je rends mes livrables dans les délais. Parceque mon code compile. Parceque mon code se déploie. Parce que la documentation est à jour. Quelle victoire…

    Le code de l'IA ou du stagiaire ne compile pas, ne se déploie pas et la doc… quelle doc?

    Le système à base de stagiaires/alternants/vibecave coders ne tient que parce qu'il y a des vrais devs qui s'ennuient à mourir à corriger les bugs des autres.

    Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

  • # J'ai quitté, pour mieux revenir

    Posté par  . Évalué à 10 (+14/-0).

    J'ai bossé dans ce genre de boite, bien avant l'arrivée de l'IA. Moi c'était les VM. C'est aussi débile.Puis je suis parti, ou plutôt on m'a mis à la porte. Salement. Je l'ai mal vécu. Mais un pote m'a dit. Tu verras c'est la meilleure chose qui te soit arrivé. Et 10ans plus tard il avait raison.

    Aujourd'hui je fais tout ce qu'on ne voulait pas me laisser faire dans mes anciennes boites, et je le fais pour mes clients. Comme moi je veux. Je choisis mes clients et je ne travaille avec eux uniquement si on travaille ensemble et pas les uns contre les autres. J'ai déjà mis fin à des contrats avec des clients uniquement pour cette raison.

    Aujourd'hui j'aide donc des développeurs complétement perdu avec leur application qui est le résultat d'années de n'importe quoi, à optimiser, debugger et simplifier leur application. Ce n'est pas du très au niveau technique, loin de la. Mais je suis heureux de voir que les développeurs avec qui je travaille sont content. Moi ça me suffit.

    Après être patron c'est d'autres emmerdes, mais j'ai eu l'incroyable chance de trouver un associé qui gère toute cette partie.

  • # Problème de fond

    Posté par  (site web personnel) . Évalué à 10 (+16/-0).

    C'est sûr qu'on change d'époque. Il y a plus d'informatique partout, mais du coup aussi plus de boites "à la con", là où il y a une vingtaine d'année on trouvait une plus grosse proportion d'enthousiastes (parfois foutraques, ce qui est un autre sujet). Pour moi c'est un peu les dérives habituelles du capitalisme : on affine les process, encore et encore, et parfois ça fait des économies d'échelles, mais souvent aussi ça génère pas mal de non-sens, de frictions humaines, et ça conduit à perdre la saveur qu'un chouette travail peut amener. Ya sans doute des managers qui kiffent à mort, là, à faire des programmes de séminaires et des réunions à la chaine, qui ont l'impression de faire des choses biens. J'espère pour eux, même si j'ai un peu un doute…

    Je pense qu'il y a toujours un certain nombre d'entreprises où on peut faire un job comme ce que tu décris ; il faut juste les trouver au milieu des autres. Ce qui est devenu aussi compliqué que de trouver une page web sur un sujet précis, qui n'aie pas été bullshité par une IA. J'ai même la croyance qu'il n'y en a pas moins de "biens" (des entreprises comme des pages web), sauf qu'elles sont perdues dans un océan toujours plus vaste de trucs moches.

    Il me semble que quand on ressent ce que tu décris, pour ne pas devenir maboul, faut trouver de quoi vibrer "autrement". Je ne suis pas un exemple, j'ai eu tendance à quitter mes jobs dès que je m'y ennuyais. J'ai exercé des métiers variés, prenant plaisir à découvrir, mais il y a toujours un moment où ça devient routinier, où je n'ai plus à réfléchir à ce que je fais, dans quel sens, comment améliorer mes gestes etc, bref mon esprit décroche et assez rapidement je vais ailleurs. Ça me fait un CV absolument foutraque qui faisait ouvrir de grands yeux aux formateurs lors des stages "apprendre à faire un CV" (le pire étant que je sais très bien reformater ça pour me faire embaucher ensuite, ces formations obligatoires sont une telle perte de temps).

    Je comprends aussi qu'on reste dans un job dont le fond est devenu ennuyeux, mais dont les à-côtés sont confortables. Sans parler de la difficulté à trouver un autre job correspondant à nos autres critères, mais avec le fun en plus. Dans ce cas, acter que le job est devenu d'un ennui total, voir ce qu'on peut négocier là dedans, voir même si on ne peux pas se libérer du temps (bosser un jour de moins ? Dans une autre équipe ? Disparaitre discretos durant les séminaires imposés après avoir émargé ? Prétendre prendre des notes en réunion alors qu'on écrit des poèmes d'amours à son algorithme préféré ?). Et surtout trouver à côté, dans le reste de sa vie, de quoi se nourrir. Généralement en trouvant des projets sympas où participer bénévolement.

    Perso je suis vraiment adepte de la méthode "tout cramer" (repartir sur des bases saines étant un peu en option). J'ai quitté des jobs, des apparts, des compagnons, tout un tas de situations confortables, pour aller galérer comme pas permis. Mais je ne me suis pas ennuyée, ça c'est sûr !

    Par ailleurs ça peut être utile de faire un vrai bilan. Pas juste de compétences, mais de voir ce qui est important et ce qui l'est moins. Tu as su refuser un poste de manager, donc j'imagine que le fait de monter les échelons n'était pas très haut sur ta liste de priorité ;) Parfois on peut trouver un job bien plus sympa, mais en acceptant de gagner beaucoup moins, par exemple. Ou de déménager (ce qui peut être compliqué si on a une famille, une maison etc). Où sont les marges de manœuvres ?

    Dans ton travail, as tu encore le sentiment d’exercer une véritable intelligence? Pas simplement celui de résoudre des tickets, ou d’interfacer un formulaire avec une base de données. Mais bien cette sensation rare, précieuse, d’avoir compris un problème de fond, d’en avoir extrait une solution élégante, inattendue, juste? Ce moment de clarté, où tout s’aligne, où l’on sent que quelque chose s’est éclairé?

    C'est un sentiment que je vis régulièrement dans ma vie. Pas dans un job salarié, parce qu'handicap et travail rémunéré, c'est parfois trop compliqué. Mais ce bonheur, ce flow, quand les choses s'alignent et que je comprends comment tout s'emboite, comment mettre les choses en place, oui. Je ne sais pas comment on peut tenir le coup si on n'a pas ce truc régulièrement. Donc je te souhaite vraiment de retrouver comment mettre ça dans ta vie.

    • [^] # Re: Problème de fond

      Posté par  . Évalué à 10 (+13/-0).

      Personnellement c'est la voie que j'ai pris.

      Je bossais dans les systèmes embarqués, des projets intéressants techniquement mais dans une boite "world company".
      J'ai mis un pied dehors en obtenant de haute lutte un télétravail 100% remote et en temps partiel (avant le covid, c'était clairement pas trivial) pour pouvoir quitter l’île de France et aller vivre dans un coin paumé qui me plaît.
      La boîte m'a mis le 2ème pied dehors en virant tout le monde et en fermant le site de R&D dans lequel j'étais quelques mois pus tard.

      J'ai rebondi en m'auto-formant au développement web, et j'ai trouvé du taff (toujours en remote) dans le secteur associatif, quelque chose qui me tenait à cœur.
      Techniquement, c'est pas fou. Déjà le dev web me branche moins que l'embarqué (le C me manque, et j'aime pas le JS…), mais en plus dans mon association la dette technique est monstrueuse parce que je suis le 1er embauché pour reprendre en main des années de travail en dilettante sur le sujet par des prestataires.

      MAIS!

      Mais je bosse pour une cause qui me tiens à coeur. Mon cerveau turbine à plein car même si je bosse un peu les mains dans la m****, j'apprends toujours plein de choses sur des nouveaux langages, comment ça marche internet, comment ça marche le web, tiens comment cette lib fait pour faire ci ou çà, tiens comment on pourrait encaisser les pics de trafic plus facilement en faisant ci ou ça, bref, même si de base ça me plaît moins que mon précédent taff, j'ai toujours de quoi stimuler mon cerveau.
      Et le secteur fait une grosse différence quand t'as pas envie de t'y remettre un lundi matin, tu bosses pas pour l'actionnaire mais pour "la Kauze" qui vaut le coup pour toi.

      Certes, il a a fallu encaisser la baisse de salaire. Mais ça l'évite de finir en burn ou en bore out.

    • [^] # Re: Problème de fond

      Posté par  . Évalué à 4 (+2/-0).

      Je comprends aussi qu'on reste dans un job dont le fond est devenu ennuyeux, mais dont les à-côtés sont confortables. Sans parler de la difficulté à trouver un autre job correspondant à nos autres critères, mais avec le fun en plus. Dans ce cas, acter que le job est devenu d'un ennui total, voir ce qu'on peut négocier là dedans, voir même si on ne peux pas se libérer du temps (bosser un jour de moins ? Dans une autre équipe ? Disparaitre discretos durant les séminaires imposés après avoir émargé ? Prétendre prendre des notes en réunion alors qu'on écrit des poèmes d'amours à son algorithme préféré ?). Et surtout trouver à côté, dans le reste de sa vie, de quoi se nourrir. Généralement en trouvant des projets sympas où participer bénévolement.

      ouais, j'ai négocié du temps de travail en moins (je suis environ à 80%), donc j'ai gagné du temps.

      Mais ce bonheur, ce flow, quand les choses s'alignent et que je comprends comment tout s'emboite, comment mettre les choses en place, oui. Je ne sais pas comment on peut tenir le coup si on n'a pas ce truc régulièrement. Donc je te souhaite vraiment de retrouver comment mettre ça dans ta vie.

      je suis ok avec ça, merci

  • # Mais c'est trop bien !

    Posté par  (site web personnel) . Évalué à 4 (+4/-0).

    Tu fais comme moi. Tu bosses 1 ou 2 jours par semaine. Le reste du temps tu te trouves une occupation sympa.

    • [^] # Re: Mais c'est trop bien !

      Posté par  (Mastodon) . Évalué à 10 (+8/-0).

      Tu viens de décrire le temps de travail effectif de la plupart des employés de bureau.

    • [^] # Re: Mais c'est trop bien !

      Posté par  (site web personnel) . Évalué à 9 (+7/-0). Dernière modification le 22 septembre 2025 à 12:00.

      Non désolé
      Sans projet motivant tu tournes en rond
      L'informatique reste encore un truc ou il faut échanger "en live" avec de vrais humains
      car la tu peux recevoir et transmettre

      J'ai bossé trop longtemps pour une boîte qui ne voulait pas évoluer, évitait d'investir, et n'acceptait les formations que contraint et forcé

      D'ailleurs je suis sur qu'ils utilisent encore ce que j'ai mis en place en … 2008
      un VM linux avec SAMBA pour faire du partage windows

      Non si tu veux évoluer il faut rencontrer des gens et échanger des idées

      Le geek asociable qui reste dans sa piole comme une huitre risque fortement de mal finir

      PS : je précise il s'agit d'un conseil de vieux c..

      • [^] # Re: Mais c'est trop bien !

        Posté par  (site web personnel) . Évalué à 3 (+1/-0).

        Le reste du temps tu te trouves une occupation sympa.

        C'est ça le projet motivant. Ton (ou tes) projet(s) open source sur lesquels tu passes 80% du temps.

        Je connais quelqu'un qui fait ça et ça lui plaît. Honnêtement, ce qu'il fait au boulot a l'air sympa aussi, mais ça lui prend pas plus de 20% de son temps. Et ses collègues (non informaticien, il est le seul informaticien) sont tous hyper content de son boulot, sans avoir conscience qu'il fait ça beaucoup plus rapidement que ce qu'ils pensent.

    • [^] # Re: Mais c'est trop bien !

      Posté par  . Évalué à 3 (+1/-0).

      Pourquoi pas en effet. Mon cousin faisait ça, le reste de la semaine étant consacré à l'apprentissage d'un nouveau futur métier en auto-didacte (PAO + photoshop 1.0, graphiste 3D sur Maya 1.0, gestion de robots industriels pour la TV, …). Hyper stimulant, mais il faut le courage d'investir et de persévérer.

    • [^] # Re: Mais c'est trop bien !

      Posté par  (site web personnel, Mastodon) . Évalué à 10 (+17/-0).

      Sinon il y a la version soft. Perso, je suis passé à 80% : que des week-ends de 3 jours et des semaines de 4 : c'est plus simple à négocier en restant dans le salariat.

      Je ne me suis rien fixé comme objectif sur le temps dégagé, mais ça a servi pêle-mêle à prendre soin de moi et mon lieu de vie, jardiner, cuisiner, contribuer à des projets opensource, coder juste pour moi, me balader, être là pour mes proches.

      Le ratio temps pour gagner de quoi vivre / temps pour vivre est déjà perceptiblement meilleur, et permet d'aborder beaucoup plus sereinement les tracas du quotidien.

      • [^] # Re: Mais c'est trop bien !

        Posté par  (site web personnel) . Évalué à 6 (+4/-0).

        La semaine de 4 jours … (80%)

        Sincérement cela fait 25 ans que je suis passé à la semaine de 4 jours, ne travaillant pas les mercredis et je ne regrette pas que du bonheur.

        Bientot la retraite progressive … et je vais passer à la semaine de 3 jours de travail. C'est possible depuis le 1er septembre si tu as plus de 60 ans et plus de 150 trimestres
        mais attention il y a 5 mois de délai …

  • # Ça n'est pas que toi, c'est le monde du travail

    Posté par  . Évalué à 10 (+13/-0).

    Ce moment de clarté, où tout s’aligne, où l’on sent que quelque chose s’est éclairé? Histoire de savoir si c'est plutôt normal ou plutôt exceptionnel?

    Malheureusement, les statistiques concernant le mal-être au travail en France dressent un portrait assez terrible de la réalité quotidienne d'une bonne part de la population. En cherchant (trop) rapidement, je n'ai pas déniché de rapport complet, récent, et accessible gratuitement, mais des sources diverses et variées se trouvent facilement. Et ce constat négatif est unanime.

    Entre le le burn-out, le bore-out, le stress en général, le manque de sens, le manque de reconnaissance ou encore le harcèlement au travail, de nombreux phénomènes entrent en jeu ; je serai mal placé pour en faire une synthèse, ça n'est pas ma spécialité. Néanmoins, en vrac :

    Dans ton travail, as tu encore le sentiment d’exercer une véritable intelligence? Pas simplement celui de résoudre des tickets, ou d’interfacer un formulaire avec une base de données. Mais bien cette sensation rare, précieuse, d’avoir compris un problème de fond, d’en avoir extrait une solution élégante, inattendue, juste?

    Je fais un métier ou les "IA" n'ont pas de sens à être vraiment utilisées et ou mon cerveau (et mon corps en général) sont plutôt très sollicités. Donc ça va. Par contre je suis effroyablement mal payé (à peu près au smic, et à temps partiel), ça crée un d'autres problèmes dans ma vie.

    Je ne me vois pas travailler dans la grand monde l'informatique, je pense que ça se terminerait en dépression ou un burn-out à court ou moyen terme.

  • # Bienvenue dans l'industrie

    Posté par  (site web personnel) . Évalué à 10 (+10/-0).

    Dans une industrie au vrai sens du terme, il ne faut surtout pas que ses acteurs aient besoin d'être intelligents/malins. Tu t'attends à ce que le système arrive à délivrer assez même en mettant de la force brute, mais suffisamment pour dépasser ses couts, aussi élevés soient-ils.

    Si je prends ton exemple d'optimisation de l'allocateur mémoire: si tu n'y étais pas arrivé, c'était le drame et une gros risque non? C'est pour éviter de tomber dans ce risque qu'ils vont préférer prendre "comme tout le monde", même si c'est moins efficace que du sur mesure. Çà "marche" pour tout le monde, donc ça marchera également ici (en théorie hein…).

    C'est moins efficace? Oh que oui. C'est moins sympa? Oh purée carrément. C'est plus sûr? Oui. Donc dans un processus industriel, tu vas le préférer et passer au problème suivant.

    Si on rajoute le fait qu'on a tellement industrialisé le côté matériel que désormais c'est le cout du développeur qui est autrement plus élevé que celui du/des serveurs, la question économique ne se pose même plus sur le besoin d'optimisation.

    Est-ce que dans quelques années, ou après une invasion d'une certaine ile, on aura des couts matériels qui vont exploser et qu'il faudra alors dépenser moins en matériel et revenir à plus "réfléchir" en amont? Peut être. Et d'une certaine manière tant mieux, on arrêtera de jeter des ressources par la fenêtre juste car c'est plus rentable économiquement.

    D'ici là on va continuer à faire du joli/malin/agréable sur notre temps libre.

  • # Mauvais taff => Changer de taff

    Posté par  . Évalué à 5 (+4/-1).

    C’est pas pour te jeter la pierre, mais si tu ne te retrouve plus dans ton taff actuel, pourquoi ne pas en changer ?
    Certes le marché n’est pas a son mieux en ce moment, mais je les meilleurs postes et surtout ceux que tu recherches ne sont pas sur les places de marchés. Ils sont dans les réseaux pro, les contacts humain, les asso, les side project, etc.

    Tu a une grande responsabilité dans ta carrière, si elle te plait pas, il ne tient qu’a toi de trouver mieux. Tu cherches des projets qui peuvent te retourner le cerveaux et t’obliger a écrire de l’assembleur ? Va voir VideoLan, ils ont pleins de défis dans ce genre.

    Bref, si t’as du temps a perdre, essaye d’en profiter pour trouver mieux :P

  • # Travailler pour le logiciel libre

    Posté par  . Évalué à 5 (+3/-0).

    Il y a tant de projets qui cherchent des contributions de vrais humains.

    Si tu manques d'idées je peux en suggérer quelques unes :)

    aussi sur le salon xmpp:linuxfr@chat.jabberfr.org?join

    • [^] # Re: Travailler pour le logiciel libre

      Posté par  . Évalué à 4 (+2/-0).

      Ça c'est très très cool mais ça ne fait pas fait rarement un gagne-pain malheureusement.

      C'est pour cela que je rejoins les commentaires sur le temps partiel.

  • # Ça s’appelle la prolétarisation des cadres

    Posté par  . Évalué à 10 (+11/-0).

    Nos chers dominants bourgeois ont réussi le tour de force de faire de sa petite armée de surveillants un gisement « d’employés » corvéables à merci, grâce au forfait jour.

    C’est criant dans mon domaine d’activité, l’informatique de gestion bancaire site central : quand j’ai découvert ce monde en 2000, j’ai commencé à travailler dans un bureau de un, avec une porte tout-ça tout-ça. Au bout d’un an, j’étais internalisé (c’était contractuel). Et 5 ans après avec quelques collègues, nous avons porté un projet de refonte complète d’une application dont je suis devenu responsable.

    Aujourd’hui, plus 60 % des développeurs sont externes (ils n’y sont pour rien, mais comment avoir une vue à long terme quand on part au bout de trois ans, le temps minimal pour commencer à comprendre ce qu’on fait dans mon domaine ?), la « compétence » la plus « importante », c’est saisir son US dans JIRA. Avoir la responsabilité d’une application ? Que nenni. Tout est découpé, siloté, et au final, l’application absurde de la méthode agile a fini par épuiser tout le monde, nul n’étant tenu d’être capable de « sprinter » pendant 10 ans…

    « Y a même des gens qui ont l’air vivant, mais ils sont morts depuis longtemps ! »

    • [^] # Re: Ça s’appelle la prolétarisation des cadres

      Posté par  (site web personnel) . Évalué à 10 (+10/-0).

      l’application absurde de la méthode agile a fini par épuiser tout le monde, nul n’étant tenu d’être capable de « sprinter » pendant 10 ans…

      La première fois que j'ai fait de l'agile, il y avait toujours un intersprint. Et puis il a disparu parce que les managers, lors d'un séminaire en Guadeloupe, ont trouvé que c'était vraiment du temps inutile.

      Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

      • [^] # Re: Ça s’appelle la prolétarisation des cadres

        Posté par  (site web personnel) . Évalué à 8 (+7/-1). Dernière modification le 23 septembre 2025 à 15:12.

        l’application absurde de la méthode agile a fini par épuiser tout le monde, nul n’étant tenu d’être capable de « sprinter » pendant 10 ans…

        Le record du marathon serait de ~ 1h28min …

        Pour le détail :
        J'ai pris le record du 800m (qui est la dernière épreuve considérée comme du sprint, après c'est du semi fond, il me semble) : ~1min40 => 100s

        Distance marathon : 42,195 km

        => 42195 / 800 * 100 = 5274,375s
        5274,375 / 60 = 87,9 min => ~1h28 min

      • [^] # Re: Ça s’appelle la prolétarisation des cadres

        Posté par  . Évalué à 6 (+4/-0).

        Ça fait un an que je bosse en sprints (avec Scrum), et une de mes premières questions était de savoir quand est-ce qu'on consolide, on prend du recul, on se cultive/documente… Bref, un intersprint (j'avais pas le mot)… 'Paraît que les sprints doivent s'enchaîner.

        C'est dommage je trouve.

        • [^] # Re: Ça s’appelle la prolétarisation des cadres

          Posté par  . Évalué à 7 (+4/-0).

          chez nous il font des sprints de consolidation corrections de bugs, pas de nouvelle fonctionnalité juste corrigé ce qui a été trop vite fais.

          Et je ne parle pas des tâche de refactoring que les tech-lead négocient durement qui parfois s'étirent sur plusieurs sprint, ou la dette technique qui monte beaucoup plus vite que dans l'ancien projet remplacé par le nouveau ;)

          Bref la méthode agile (ou scrum ou…) c'est juste une formalisation de la rache

          Bon j'exagère tout n'est pas à jeter, mais le découpage en sprint cours, c'est bon en phase de prototypage, pas pour un projet devant durer 10 ans

          Il ne faut pas décorner les boeufs avant d'avoir semé le vent

        • [^] # Re: Ça s’appelle la prolétarisation des cadres

          Posté par  (Mastodon) . Évalué à 10 (+7/-0). Dernière modification le 25 septembre 2025 à 07:48.

          J'ai l'impression qu'ici il y a une ignorance crasse de ce qu'est la méthode SCRUM.

          Le principe du sprint c'est de découper le temps de travail en périodes courtes pour ne pas se perdre dans 20000 deadlines différentes et de faire un état des lieux et avoir l'opportunité de réétablir les priorités entre chaque période, trouver des pistes d'améliorations. On les adopte coe.on veut mais c'est à ça que servent toutes les cérémonies (planification, daily, revue et retrospective)/de la méthode SCRUM. C'est justement fait pour avoir l'opportunité de pouvoir prendre du recul.

          Ça n'a rien à voir avec le fait de sprinter et tout faire vite en ne se concentrant que sur du code et en oubliant le reste.

          La documentation tu la prends en compte dans l'effort nécessaire à effectuer une tâche. Il y a même des tâches dédiées à la recherche, les spikes, où le travail délivré est obtenir une information.

          Et quoiqu'il en soit toute la partie veille techno que tu fais n'es pas forcément inclue dans le sprint. Si la politique de ta boite dit que tu peux dédier 10% ou 20% de ton temps de travail dans de la veille et de la formation, tu le prends en compte dans la planification de tes sprints pour ne pas êtee surchargé de tâches et d'avoir ce temps que tu peux consacrer.

          Moi perso je préfère avoir un chef de projet qui sait qu'il va avoir les tâches A B C réalisée dans les 15 jours que de travailler en waterfall ou kanban et d'avoir tout le temps quelqu'un sur le dos et des priorités et deadlines qui changent tout le temps, ou de se rendre compte 6mois/1 an après que les specs et le cahier des charges était foireux et qu'on est bon pour tout refaire différemment.

          • [^] # Re: Ça s’appelle la prolétarisation des cadres

            Posté par  (site web personnel) . Évalué à 9 (+7/-0). Dernière modification le 25 septembre 2025 à 09:07.

            Tout à fait d'accord, le sprint ne veut pas dire qu'il faut bâcler. Dans toutes les boîtes où j'ai fait du scrum, avec plus ou moins de rigueur, on mettait un ou deux gros sujets top prio par personne, quelques sujets plus petits mais importants, et une ou deux tâches d'hygiène et de confort. Le tout en laissant de la marge pour que les devs puissent respirer entre deux tâches. Et ça fonctionnait très bien ! Parfois on termine en avance et on pioche des tâches dans le backlog, parfois on bloque et on laisse tomber la tâche et on la repense pour un autre sprint. Ça permet de toujours avancer et de maintenir le projet dans un état convenable. Et comme on accepte que tout soit toujours en travaux et qu'on va améliorer les choses au fur et à mesure, on évite les grosses décisions d'abstraction basées sur des hypothèses de besoins a priori, qui vont certainement ne pas coller au besoin réel, et on s'épargne l'envie de faire de grosses refactos qui bloquent tout.

          • [^] # Re: Ça s’appelle la prolétarisation des cadres

            Posté par  . Évalué à 6 (+3/-0).

            Un jour j'irai vivre en théorie :) Car la bas tout se passe bien :)

            De ce que je constate, c'est une course permanente avec la deadline, un découpage pas forcément des plus heureux pour pouvoir faire rentrer l'évolution, où l'on se retrouve avec des interdépendances entre les US, le refacto qu'arrive et qui gèle ou collisionne certaines évolutions…

            Alors sur un petit projet on a pas ce genre de soucis (ou moins); mais sur un gros juste à coté…

            Moi perso je préfère avoir un chef de projet qui sait qu'il va avoir les tâches A B C réalisée dans les 15 jours

            Avant qu'on passe sur les méthodes à Gille, on avait une intégration presque continue, avec les évolutions distribuées entre les développeurs, et on envoyait les PR à l'intégrateur quand c'était prêt, et le chef de projet suivait ce qui se passait, et pouvait reprioriser les évols, on avait une réunion par semaine pour indiquer ce qui avait été intégré ou prêt à intégrer, ou si on avait des difficultés particulière (ou surtout si on prévoyait d'en rencontrer, car si on est bloqué faut voir rapidement avec un collègue)

            On avait pas ce découpage artificiel en période de n semaines.

            Le point positif c'est la création des PO qui permet d'avoir un interlocuteur à qui poser les questions.

            Il ne faut pas décorner les boeufs avant d'avoir semé le vent

            • [^] # Re: Ça s’appelle la prolétarisation des cadres

              Posté par  (site web personnel, Mastodon) . Évalué à 8 (+5/-0).

              On avait pas ce découpage artificiel en période de n semaines.

              Il ne faut pas oublier aussi que la méthode SCRUM est juste un exemple de résultat d'une méthode agile. C'est fait par des gens qui ont expérimenté les méthodes agiles et sont arrivés à une organisation stable et qui leur convient.

              L'idée des méthodes agiles, c'est surtout d'adapter les choses en fonction des besoins. Tu vois qu'il y a un truc qui ne sert à rien, tu l'enlèves. Tu vois que c'est la merde tous les mois parce qu'il manque un truc (genre tu fais pas de tests avant de livrer), tu l'ajoutes.

              Si tu ne sais pas par où commencer pour mettre ton projet en place, SCRUM te donne un exemple de façon d'organiser les choses, qui peut servir de point de départ à faire évoluer ensuite.

              Si tu n'aimes pas les sprints et que ce n'est pas pertinent dans ton cas, tu peux prendre une méthode qui ressemble plus à Kanban: il y a une liste de trucs à faire, tu pioches dedans quand tu es disponible pour démarrer une nouvelle tâche, il y a un suivi individuel de chaque tâche.

              Dans mon cas on pratique un mélange des deux: il y a une planification par sprints parce que ça permet d'estimer la capacité de l'équipe (prévoir à peu près combien de tâches on va pouvoir compléter chaque mois et chaque trimestre), mais si il y a une tâche qui dure 2 mois de suite, ce n'est pas bloquant, il faut juste tenir compte du fait que une personne ne va faire que ça pendant 2 mois.

              Et pour les sprints qui ne seraient pas tenables: dans SCRUM c'est l'équipe qui choisit combien de "points" (et donc de tâches à compléter) sont prévues dans chaque sprint. Si vos sprints ne sont pas tenables, il suffit de moins les remplir. Bien évidemment, ce n'est pas facile à expliquer au management, mais ça, ce n'est pas le problème de la méthode SCRUM (qui n'a peut-être pas été conçue pour fonctionner avec un management hostile à ce genre de choses).

            • [^] # Re: Ça s’appelle la prolétarisation des cadres

              Posté par  (Mastodon) . Évalué à 6 (+3/-0).

              Un jour j'irai vivre en théorie :) Car la bas tout se passe bien :)

              Ce qu'il y a de sûr, c'est que le problème n'est pas forcément dans la méthode utilisé. C'est plus une question de culture d'entreprise, si le ratio cadre/ingés est défavorable, si on cultive les promesses intenables à ses clients, etc, etc.

              • [^] # Re: Ça s’appelle la prolétarisation des cadres

                Posté par  . Évalué à 2 (+0/-0).

                Yep, merci tout le monde. Je pense qu'en pratique, on se sert assez mal de l'outil dans mon équipe.

                En fait, souvent, on nous demande d'estimer des tâches avant qu'on commence à travailler dessus. Il y a assez souvent une part d'inconnu, qui fait que parfois, on se plante d'un facteur 5 ou 10, dans un sens comme dans l'autre. Comme les sprints sont un peu longs, on aime pas faire une tâche "défrichage" pour pouvoir estimer la tâche "réalisation" qui sera dans le sprint suivant.

                Je dirais que l'intérêt, c'est surtout qu'on se limite à bosser sur les trucs du sprint sans trop déborder. Finalement, ça pourrait ressembler à du Kanban, mais avec un mini-backlog.

                Et quand on termine en avance, on va en effet piocher des bonbons dans le backlog :p.

                • [^] # Re: Ça s’appelle la prolétarisation des cadres

                  Posté par  (site web personnel, Mastodon) . Évalué à 2 (+1/-0).

                  Dans mon équipe, quand on nous demande de chiffrer une tâche et qu'il y a une complexité évidente qui rend incertain le chiffrage, on prévoit une tâche initiale d'étude. Cette étude à pour objectif de produire une page pour décrire la solution envisagée, les hypothèses, les pré-requis, et le chiffrage / découpage envisagé.

          • [^] # Re: Ça s’appelle la prolétarisation des cadres

            Posté par  (site web personnel) . Évalué à 1 (+5/-4).

            Le principe du sprint c'est de découper le temps de travail en périodes courtes

            Le découpage en micro-tâche c’est du fordisme. SCRUM est le travail à la chaîne du CSP+. Faut vraiment être lobotomisé pour adhérer à ce point à sa propre aliénation.

            c'est à ça que servent toutes les cérémonies (planification, daily, revue et retrospective)

            La réunionite aiguë a encore frappé. (J’ai souffert pour l’avoir vécu…)

            • [^] # Re: Ça s’appelle la prolétarisation des cadres

              Posté par  (Mastodon) . Évalué à 6 (+4/-1). Dernière modification le 26 septembre 2025 à 00:56.

              1/4 d'heures de daily par jour et 3 réus tous les 15 jours ce n'est pas de la réunionite si on te laisse la paix le reste du temps.

              • [^] # Re: Ça s’appelle la prolétarisation des cadres

                Posté par  (site web personnel) . Évalué à -3 (+0/-3).

                Je crois que t'as même pas idée de ce que c'est qu'un travail d'un vrai ingénieur. À un certain niveau de qualification tu as droit — et tu exiges ! — un niveau d'autonomie qui est totalement incompatible avec le fait de se voir attribuer des tâches et rendre des comptes tous les jours. Entre ½ journée et ½heure par semaine, c'est pas du tout négligeable. Et clairement dans le premier cas c'est un management que j'estime passablement problématique.

                Enfin c'est le cas quand il n'y a pas trop de lèche-derche dans la boîte. Étant presta, j'ai eu l'occasion de voir du pays (c'est d'ailleurs assez rigolo de constater qu'en règle générale le niveau de compétence est inversement proportionnel…).

                • [^] # Re: Ça s’appelle la prolétarisation des cadres

                  Posté par  (site web personnel) . Évalué à 7 (+4/-0). Dernière modification le 26 septembre 2025 à 20:51.

                  À un certain niveau de qualification tu as droit — et tu exiges ! — un niveau d'autonomie qui est totalement incompatible avec le fait de se voir attribuer des tâches

                  Tout travail est un ensemble de tâches, si tu as un projet à réaliser tu peux t'organiser comme tu veux à la fin tu appliques une succession de tâches.

                  rendre des comptes tous les jours.

                  Le but du daily n'est pas de rendre des comptes en tant que tel, c'est surtout pour se synchroniser et avoir évidemment une aide en cas de blocage.

                  C'est pour éviter la blague d'une équipe qui ne communique pas et 2 semaines après Toto attend toujours le travail de Roger pour avancer et ne comprend pas pourquoi ça traine autant.

                  Cela peut permettre aussi de lever des blocages qui ont des conséquences qui n'étaient pas attendues.

                  • [^] # Re: Ça s’appelle la prolétarisation des cadres

                    Posté par  (site web personnel) . Évalué à -2 (+2/-4).

                    Non là tu me ressers la soupe. Ça vaut rien et ça résiste pas à un raisonnement parfaitement rigoureux : le SCRUM ne résoud pas un pb de comm' voir l'empire si mauvaise entente parce qu'il oblige à se parler tous les jours. Ce que tu le sers ce sont des prétextes, des justifications, de la propagande. D'ailleurs c'est assez rigolo de constater que tout ce que tu me décris je l'ai vécu… en Scrum (à fortiori le coup des 15j pris dans les dents c'est typique parce que "ah bah c'était pas dans notre sprint").

                    La réalité s'obtient en analysant objectivement les moyens mis en place et leurs effets sur le travail. En très gros — ça mériterait d'être développé mais bon un peu de sens critique et de recul sur l'organisation des entreprises permet quand même de se faire sa propre opinion plutôt que de recracher la propagande — il s'agit de réduction de coûts par l'intensification du travail¹, d'obtenir la loyauté des employés en leur faisant croire qu'ils ont un contrôle sur leur organisation (alors que c'est parfaitement anecdotique), et de diminuer les moyens (notamment rh) sans que ça se voit. Je n'ai parlé que du système de travail à la chaîne induit par la méthode, mais ça a d'autres effets, puisque par suite ça permet un contrôle très fin de l'activité des employés (non tu décides de rien du tout c'est juste une illusion, juste que t'es bien corporate comme il faut pour que le management n'ait pas besoin de te recadrer TOI), de complètement leur retirer du pouvoir sur les objectifs et la finalité du travail (il est assez significatif que depuis le début vous ne parlez que des moyens à mettre en œuvre pour la réalisation de vos tâches, mais assez peu du rejet pur et simple ou de pousser vos propres projets --- ah si en bas y'a qq1 qui en parle.. et qui est justement contre le délire de l'agile). Après y'en a à qui ça convient très bien, libres d'obéir.

                    Tu crois que le Scrum est MAL appliqué ? Mais au contraire il remplit parfaitement ses objectifs… qui ne sont pas ceux que ton esprit influençable à gobé.


                    ¹ avec le petit bémol qu'à vouloir jouer au plus couillon, une fois le système pigé y'a moyen de le mettre bien à l'envers au patronat. Mais pour les quelques salariés qui feront et sauront s'y prendre pour retourner le game tu auras toujours une masse critique suffisamment aliénée pour rendre l'opération rentable. Donc qq part je te dis merci. C'est grâce à des gens comme toi que je peux bosser seulement 2j/semaine sans être inquiété.

                    • [^] # Re: Ça s’appelle la prolétarisation des cadres

                      Posté par  (Mastodon) . Évalué à 2 (+1/-2).

                      Le SCRUM c'est adopté et choisi par les équipes et pour les équipes, pas pour les managers.

                      • [^] # Re: Ça s’appelle la prolétarisation des cadres

                        Posté par  . Évalué à 3 (+2/-0).

                        Heu, c’est une blague ? Dans quel (heureux) endroit les employés peuvent choisir leur organisation de travail ?

                        « Y a même des gens qui ont l’air vivant, mais ils sont morts depuis longtemps ! »

                        • [^] # Re: Ça s’appelle la prolétarisation des cadres

                          Posté par  (site web personnel) . Évalué à 3 (+2/-1).

                          Dans l'encadrement.

                          Adhérer à l'April, ça vous tente ?

                        • [^] # Re: Ça s’appelle la prolétarisation des cadres

                          Posté par  (Mastodon) . Évalué à 4 (+1/-0). Dernière modification le 28 septembre 2025 à 18:32.

                          J'ai vu ça ces 12 dernières années dans plusieurs boites:

                          • une pratiquant l'holacracy.

                          • une boite américaine avec des squads de developpement devops indépendantes les unes des autres.

                          • dans la boite où je travaille maintenant ils fonctionnent en Kanban mais ont essayé le scrum et ont décidé que ce n'était pas pour eux, ils ont choisi eux, pas la direction au dessus.

                          • dans une autre boîte où j'ai bossé, l'équipe avait adopté le scrumban après avoir testé SCRUM et kanban. La encore d'autres équipes étaient encore en SCRUM.

                          • [^] # Re: Ça s’appelle la prolétarisation des cadres

                            Posté par  . Évalué à 2 (+0/-0).

                            Hey !

                            une pratiquant l'holacracy

                            en as-tu profité ? Quel est ton ressenti ?

                            J'avais lu Reinventing Organizations, et après ça me suis pas mal documenté sur ces systèmes, c'est hyper intéressant ! Par conséquent je suis curieux d'avoir un retour de quelqu'un qui a baigné un peu dedans.

                            • [^] # Re: Ça s’appelle la prolétarisation des cadres

                              Posté par  (Mastodon) . Évalué à 5 (+2/-0). Dernière modification le 28 septembre 2025 à 20:42.

                              J'aimais bien oui. Je ne les ai quitté que parce que Covid et télétravail oblige j'ai cherché et trouvé bien plus loin de ma zone geo originale et pu trouver des opportunités salariales bien au dessus, presque le double du salaire.

                              Mais j'ai une amie, une ex-collègue qui travaillait dans une autre équipe, qui ne l'avait pas vécu aussi bien et trouvait qu'il y avait beaucoup de bullshit dans les réu[1] Dans un sens on te dit que tout le monde est bien plus égal mais il y a toujours des gens qui sont des leaders naturelspar leur attitude et leur capacité à s'exprimer et mener les discussions.À côté d'autres sont bien plus passifs , préfèrent se laisser guider et/ou ont peur des confrontations et duels argumentaires. Si tu es plus réservé et qu'une personne qui a des idées qui ne te plaisent pas prends le dessus dans l'êquipe ça peut être mal vécu.

                              [1] une réu dans ce type d'orga commence en général par un tour de table où chacun peut éventuellement expliquer/évacuer ses frustrations/distractions du moment(perso ou pro) pour que ça ne perturbe pas la suite et en fin de réu un autre tour de table est fait pourque cvaque intervenant s'exprime sur son sentiment vis à vis de la réu: a t'elle servit? es-tu frustré par les décisions prises en commun, tu veux alerter quelqu'un sur le fait qu'il coupait la parole aux autres, tu veux t'excuser d'avoir élevé la voix, etc.

                              • [^] # Re: Ça s’appelle la prolétarisation des cadres

                                Posté par  (site web personnel) . Évalué à -3 (+0/-2).

                                Là ça pue carrément ton truc. Je sais que Méta de choc (podcast qu'on retrouve notamment sur Youtube) avait fait quelques émissions sur l'entrisme des sectes dans les milieux professionnels. On est à un tout autre niveau que le simple Scrum.

                                Quoique je me faisais la réflexion qu'un commentaire plus haut sur Scrum est typiquement une rhétorique qu'on retrouve chez les adhérents d'une secte, c'est pour ça que je répondais plus. Mais là en même temps ça craint et en même temps la dérive de la discussion n'a rien de surprenant.

                • [^] # Re: Ça s’appelle la prolétarisation des cadres

                  Posté par  (Mastodon) . Évalué à 7 (+4/-0).

                  Ben si c'est mon travail justement.

                  Les tâches tu ne te les faits pas attribuer puisque c'est toi qui les créées, découpes et en estime l'effort nécessaire.

                  Le SCRUM c'est une méthode pour travailler en équipe afin que les différents membres se s'accordent sur chaque sprint/période de temps sur quoi ils vont bosser et quels livrables ils vont fournir.

                  Après chaque équipe décide comme elle veut, dans certains cas c'est décidé en début de sprint qui va s'attribuer quelle tâche, dans d'autres cas on pioche au fur et à mesure et dans certaines tâches plus ardues 2 voire 3 membres peuvent décider de le voir ensemble.

        • [^] # Re: Ça s’appelle la prolétarisation des cadres

          Posté par  (site web personnel) . Évalué à 6 (+4/-0).

          savoir quand est-ce qu'on consolide, on prend du recul, on se cultive/documente

          bin, au fur et à mesure :

          • doc : use-cases, tests, MàJ doc utilisateur, produit (besoin utilisateur, besoin logiciel, architecture logicielle), installation
          • code/tests unitaires + CI voire CD à une cadence selon pré-requis
          • tests intégration bout en bout régulièrement, résorption des « bouchons » conditionnant la fin du sprint,
          • les bugs ajoutés et régressions font partie du livrable, yolo _o/

          Paraît que les sprints doivent s'enchaîner

          oui, bwalors ça : avant de démarrer un nouveau sprint, demande quelle est la ligne d'imputation sur laquelle imputer et à partir de quand elle sera ouverte, ça devrait te donner le temps pour la veille technologique^W^W glande sur Internet :-) et tu imputes ton prévisionnel dès le début, ce qui validera le démarrage du sprint, si tu ne peux pas, ça décale et tu as gagné du temps.
          Et les sprints, ça peut ne pas être que de coder une nouvelle fonctionnalité, mais aussi faire du refactoring, vider le backlog d'un ensemble de tâches « faciles ».

          tu peux aussi faire remarquer que si à 6 le daily dure plus de 15 min, ça permet d'identifier les sujets à reporter au sprint suivant ou à changer les priorités (généralement ça stabilise le besoin ou le réduit à ce qui a correctement été identifié — au prix d'augmenter la longueur du backlog).
          Ah et une règle : commit du vendredi, build foiré pour le lundi :/

          La meilleure qu'on m'ait sortie : « ya pas de doc', on fait de l'agile » o_O comme si la liste de use-cases constituait la doc' produit / installation / utilisateur… En même temps, si le commanditaire accepte que le product owner perde toute maîtrise de l'appli, à un moment, ce n'est plus vraiment de ta responsabilité…

  • # Bien sur que oui

    Posté par  (site web personnel) . Évalué à 6 (+5/-0).

    Je suis peut être un chanceux, mais je suis dans une boite où avoir un cerveau est encore utile.

    Je suis responsable d'un service informatique, dans une ETI (250 salariés), où nous avons pris la décision de ré-internaliser le service informatique.

    Le côté obscur du job, c'est qu'il faut supporter le support de mes collègues.

    Le côté ultra positif, c'est que l'on construit nos applications autour de notre ERP.

    Nous avons pu mettre une chaine de valeur pour concevoir des outils utiles, utilisés par nos collègues, dans un secteur relativement actif.

    Donc oui, des jobs ou son cerveau est utile, cela existe. Il ne faut peut être pas viser les trop grosses structures. Mais dans les entreprises de taille moyenne, c'est largement faisable.

    Pour le ROI, c'est vite vendable. Les intégrateurs se "gavent" à 1200 € la journée d'un travail baclé (Ou je n'ai pas eu de chance avec nos sociétés d'infogérance, d'ERP et pour la GEIDE).
    Il faut juste travailler "propre", avoir une véritable chaine de validation (nos collègues travaillent, ils ne sont pas là pour valider en production les développements) et l'on peut apporter un e véritable valeur, dans un budget contenu.

    • [^] # Re: Bien sur que oui

      Posté par  (site web personnel) . Évalué à 2 (+1/-0).

      Les intégrateurs se "gavent" à 1200 € la journée

      Après plusieurs années en CDI en interne d'une grosse boîte je viens de me retrouver dans une ESN (j'appelais ça une SSII avant…) et on est effectivement autour de ça. Sachant que le coût réel par jour d'un ingé français est entre 400 et 800 en moyenne, et que les "frais de château" sont d'environ 30%, ça laisse de la marge.
      Bon après dans cette marge il y a aussi les jours d'inter-contrat, donc quand le marché est à la peine ça fond vite…

  • # Privilège de bourgeois, Néo.

    Posté par  . Évalué à 8 (+10/-3).

    Bienvenue dans le monde réel, celui dont vous avez tenté de vous extirper pendant des années, comme la plupart des gens intelligents ici.

    Ici, vos neurones moyens n'intéressent guère, ils n'ont aucune particularité, vous êtes remplaçables, puisqu'automatisés, et c'est un monde que vous avez bâti ; comment vous plaindre en 2025 des apanages dont vous vous êtes repus longuement ? Nous autres n'avons jamais douté, c'est l'inconvénient d'avoir pris la pilule très tôt.

    Désormais, c'est l'inertie qui vous maintiendra, la discrétion vous permettra de survivre ; l'intelligence n'a plus cours.

    Il ne vous reste que peu d'échappatoires : l'imagination en premier lieu, mais comme beaucoup, vous en manquez terriblement car l'information l'a remplacée. Et qui sait combien de temps elle va résister ? Peu de temps certainement pour qu'on ne la confonde avec l'illusion. Et en second lieu, c'est la révolte, contre vous-mêmes, votre confort (que vous avez accepté), votre microcosme (que vous avez verrouillé).

    Vous le savez au fond de vous ; vous n'avez pas pu combattre le besoin de votre manque d'intelligence (c'est ce que vous avez offert avec les années, vous le dites vous-même, c'est votre bêtise qui est devenue nécessaire) et avez laissé faire, mais il est toujours temps de tout foutre en l'air. Ça aussi, c'est souvent un privilège de bourgeois !

    ;)

  • # ITIL

    Posté par  . Évalué à 5 (+5/-0).

    Je suis surpris du peu de critiques qu'on trouve sur ITIL et les méthodes du même genre. Cette méthodologie américaine est totalement inadaptée aux informaticiens français. Elle fait un mal fou je pense.

    Rien que le "saucissonnage" des tâches en tickets, la microspécialisation ridicule qu'elle entraîne souvent (il faut 3 intervenants pour le moindre truc dans l'IT des grosses entreprises de nos jours)… Tout cela est totalement aberrant, tout le monde le voit. Et ce n'est qu'une petite partie d'ITIL… Déresponsabilisaiton, perte de sens, démotivation, tout ça pour ça…

    • [^] # Re: ITIL

      Posté par  (Mastodon) . Évalué à 4 (+4/-0).

      Je suis surpris du peu de critiques qu'on trouve sur ITIL et les méthodes du même genre. Cette méthodologie américaine est totalement inadaptée aux informaticiens français. Elle fait un mal fou je pense.

      Une question que je me pose du coup, si ce genre de méthodo est débile pour nous, ne l'est-elle pas pour les ricains aussi ? Ils ont pas le cerveau si différent du notre, normalement… (encore que…)

      🎃 Si Macron dissout il lui arrivera ce qui est arrivé à Chirac 🎃

      • [^] # Re: ITIL

        Posté par  . Évalué à 3 (+3/-0).

        Comme je n'ai travaillé qu'en France, je limite mon avis à cela…

        Mais je soupçonne vaguement, notamment suite à quelques lectures (notamment Philippe d'Irribarne a écrit sur les "valeurs" du travail en France vs. dans les pays anglo saxons, c'est très intéressant), que c'est encore pire pour les français que pour les américains. Apparemment en France on aime savoir pourquoi on travaille, avoir des responsabilités et des objectifs, mais pas être guidés dans les moindres détails (encore une fois j'ai lu sur tout ça plus que je ne l'ai constaté).

        ITIL c'est vraiment tout le contraire, c'est vraiment un truc où les "process" prennent le pas sur tout le reste, et du coup la responsabilité individuelle s'en trouve allégée.

    • [^] # Re: ITIL

      Posté par  (site web personnel) . Évalué à 7 (+6/-0).

      déjà ITIL n'est pas une méthode — c'est un recueil de bonnes pratiques — rien que le nom donne un indice : Information Technology Infrastructure Library

      Effectivement, tous ceux qui ont calé leur organisation sur le découpage proposé par ITIL — qui ne présage à la base pas de l'organisation — ont rencontré des problèmes. Un point à retenir : c'est la pratique qui s'adapte à l'organisation, pas le contraire.

      Exemple typique : pas forcément besoin de 3 intervenants… simplement, le même intervenant mais n'ayant pas les mêmes activités lorsqu'il intervient sur un incident (qui ne requière que peu d'analyse a priori, celui qui ouvre, traite et ferme le ticket peut être la même personne) ou sur un problème (qui mobilise un ensemble d'incidents, et là peut requérir un peu plus de lourdeur et de coordination inter-équipes à la marge, cas que l'on souhaite éviter : délais, coûts qui seraient à imputer à un projet et à la maintenance d'une application).

      À ce titre, les déclinaisons d'ITIL que j'ai pu rencontrer sont au mieux bancales (la classique erreur d'équipes distinctes « Changement / Incident+Problème ») ou catastrophiques comme tu l'indiques en terme de lourdeur administrative lorsque le principe de subsidiarité n'est pas respecté : son pendant étant de n'impliquer que les personnes concernées et de ne pas rajouter de lourdeur inutile.

      Comme toujours, si l'outil est la solution, c'est le début des problèmes :D

      • [^] # Re: ITIL

        Posté par  . Évalué à 1 (+2/-2).

        ITIL c'est joli en théorie (quoique déjà… pour avoir passé la certification la plus basique, c'est d'un ennui…). Mais en pratique, partout où je l'ai vu appliquer, c'est une cata. Et plus c'est appliqué, pire c'est… Il faut croire que ça plait au management, qui a des jolis tableaux de bord (totalement décorrélés d'une quelconque réalité mais bon…)

        Ceci dit il n'y a pas qu'ITIL hein, la pratique du "ticketing" à outrance mériterait déjà une bonne revue critique…

        • [^] # Re: ITIL

          Posté par  . Évalué à 5 (+4/-0).

          ITIL met quelques définitions en place, ça peut être utile quand on ne sait pas par où commencer, tout de même. Y avait-il besoin de pondre des bouquins de 1000 pages pour en parler ?

          De ce que j'en retiens de bien :
          - on s'oriente sur le service, et plus spécialement sur la qualité de service
          - on met en place de la traçabilité

          Comment c'est mis en place, chaque structure fait bien comme elle veut et elle peut. Le piège étant de respecter à la lettre le cadre.

          Perso je trouve la logique des tickets (demande écrite avec des états et un historique synthétique) plutôt chouette à long terme.

          • [^] # Re: ITIL

            Posté par  (site web personnel) . Évalué à 4 (+3/-0).

            Perso je trouve la logique des tickets (demande écrite avec des états et un historique synthétique) plutôt chouette à long terme.

            Tout à fait d'accord. Et plus l'organisation est importante, plus c'est indispensable.
            Et comme toute chose indispensable, ça se régule avec des chartes/règles, et ça se régule avec à minima un responsable du ticketing (qui n'est pas obligé de ne faire que ça…) pour contrôler que le processus reste pertinent, efficace et respecté. Une DSI qui oublie ce point se paye en général un aller simple pour le chaos et les surcoûts qui vont avec.

            • [^] # Re: ITIL

              Posté par  . Évalué à 0 (+0/-0).

              Ah mais "la logique des tickets" est bonne, effectivement il faut bien une façon d'organiser le travail. Ce qui est horrible et mériterait à mon sens qu'on y réfléchisse c'est ce que ça devient concrètement dans la vie réelle dans beaucoup d'entreprises.

  • # Bienvenue chez les adultes

    Posté par  . Évalué à -3 (+5/-9).

    Désolé, je vais être à contre-courant et un peu brutal.
    Ce que je lis, c'est un pilote de formule 1, qui explique qu'il est mieux que la majorité de la plèbe, que lui, il optimise les trajectoires pour grapiller quelques secondes à chaque tour. Et après ça, le pilote méprise les livreurs, routiers, ambulanciers et autres taxis, ces gens "sans âmes à 70 de QI [cf]", qui conduisent mollement. Contrairement à ce que pense le pilote de F1, le livreur réfléchi : Il doit suivre le code de la route, optimiser ses livraisons. Mais le pilote, visiblement ne veux pas entendre parler du code de la route : Trop chiant. Réfléchir pour inverser deux if en hexa, ça l'amuse. Mais réfléchir pour modifier progressivement une architecture complexe et la corriger tout en respectant les contraintes opérationnelles, là, il n'y a plus personne. Il n'aime pas être confronté au réel. C'est, quelque part, encore un enfant. En attendant, c'est grâce au travail inlassable du livreur qu'on a nos légumes au supermarché du coin. Livreur qui n'a pas de reconnaissance, contrairement au pilote de F1. Il ne va certes pas très vite, mais il va bien quelque part.
    Si je change de domaine, je lirais un médecin qui ne veux soigner que des cancers complexes. Les appendicites ou autres arrêts cardiaques n'étant pas assez "stimulants" à son goût. Imagine la gueule du système de soins, si n'y a que ce genre de médecin…

    Tu sens que "quelque chose s’est éclairé [cf]" ? Tu viens de découvrir le monde réel. Fini les caprices d'enfants gâtés. La vie, ce n'est pas passer son temps à jouer à la PS5 (ou piloter une F1), c'est aussi faire la vaisselle et ranger sa chambre (ou autres taches ennuyeuses). Les licornes n'existent pas. Bienvenue chez les adultes.

    • [^] # Re: Bienvenue chez les adultes

      Posté par  . Évalué à 6 (+5/-0).

      Je pense que vous avez mal interprété ce journal. Je ne sais pas qui l’a écrit, mais je partage une expérience similaire.

      J’ai eu la chance dans les années 2003 de pouvoir réécrire une application complètement avec 4 collègues internes, en mode patrimoine : nous avions la maintenance des applications à remplacer, et nous avions participer à l’étude d’existant pendant laquelle nous avions épluché chaque ligne de code.

      L’application (monétique) était composée d’un référentiel et de la gestion des opérations porteurs. En mesurant très large, ça a couté 3 500 jours.

      En 2005, avec entre-temps la mise en place d’une « méthode projet », j’ai observé de loin la refonte du référentiel commerçant (sans les opérations donc). Mise en place de forfaits tout ça tout ça (avec une équipe d’une dizaine de personnes) : 25 000 jours ! Ledit référentiel n’a pas pu être branché tout de suite aux opérations (en fin si, mais pendant 30 minutes seulement étant donné les performances catastrophiques), le branchement, qui a demandé un nouveau projet de plus de 1 000 jours, n’a eu lieu qu'en 2011 ! Le traitement d’intégration des mises à jours quotidiennes était le traitement le plus couteux existant, coût « forfaitaire » (ça coutait même s’il n’y avait aucune mise à jour). Cette application est en cours de démantèlement…

      Et pourtant, j’ai rencontré le programmeur le plus brillant que je connaisse parmi ceux qui ont comme ce désastre, et la responsable du projet était loin d'être incompétente.

      C’est donc bien un problème de système et non de personne.

      La responsable de la monétique des années 2000 ne se serait jamais préoccupée de « détail » de projet de moins de 100 jours, quand désormais (c’est du vécu) il peut remonter au DSI d’arbitrer un dépassement de 5 jours !

      « Y a même des gens qui ont l’air vivant, mais ils sont morts depuis longtemps ! »

    • [^] # Re: Bienvenue chez les adultes

      Posté par  . Évalué à 10 (+8/-0).

      Ce que je lis, c'est un pilote de formule 1, qui explique qu'il est mieux que la majorité de la plèbe, que lui, il optimise les trajectoires pour grapiller quelques secondes à chaque tour.

      oulà, non. Juste un pilote qui aime réfléchir à ses trajectoires.

      Et après ça, le pilote méprise les livreurs, routiers, ambulanciers et autres taxis, ces gens "sans âmes à 70 de QI [cf]", qui conduisent mollement.

      Ah non, c'est moi qui dit avoir 70 de QI, je ne juge pas les autres. Après s'être rendu compte qu'optimiser des trajectoires ça me plait, on me dit que rouler à 10 à l'heure sur une ligne droite, ça va être mon boulot, désolé d'être déçu, hein.

      Mais réfléchir pour modifier progressivement une architecture complexe et la corriger tout en respectant les contraintes opérationnelles, là, il n'y a plus personne.

      ah bah si, ça m'intéresserait. Là, on me demande d'utiliser l'existant ou d'ouvrir un ticket chez le prestataire si ça va pas.

      C'est, quelque part, encore un enfant. Les licornes n'existent pas. Bienvenue chez les adultes.

      c'est triste ton avis sur les licornes. Bon, je vous laisse, faut que je finisse mon quatre heures et je dois aller ranger mes peluches avant de faire mes devoirs du soir, maman va bientôt rentrer.

Envoyer un commentaire

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.