Les lignes de code se sont trouvé un meilleur attaché de presse

 (curlewis.co.nz)
1 points par GN⁺ 4 시간 전 | 1 commentaires | Partager sur WhatsApp
  • L’évaluation de la productivité des développeurs doit se fonder sur des indicateurs de résultat comme la valeur client, le chiffre d’affaires et la fiabilité, plutôt que sur le volume de code
  • Les chiffres de communication récents de Google, Anthropic, OpenAI et Cursor sur le coding avec IA se concentrent tous sur des affirmations quantitatives comme la part de code générée ou le nombre de lignes de code
  • L’ancienne affirmation de GitHub Copilot d’une amélioration de 55 % de la vitesse de travail était un résultat vérifiable, mais la « part de code écrite par l’IA » peut augmenter sans aucun lien avec une amélioration réelle
  • Les études réelles donnent des résultats contrastés, allant de +26 % de tâches terminées selon Cui et al. à « 19 % plus lent » selon METR puis son revirement, jusqu’à une enquête où 90 % des entreprises ne mesurent aucun effet, ce qui place l’effet à l’échelle des organisations autour de 10 %
  • L’adoption de l’IA est nécessaire, mais la mesure des performances doit reposer sur des critères éprouvés comme les métriques DORA, la fiabilité, la vitesse des changements significatifs, le chiffre d’affaires et la valeur client

Le retour de l’indicateur du nombre de lignes de code

  • Il y a 15 ans, dans une entreprise SaaS, le simple fait qu’un des deux développeurs seniors ait écrit 40 % de code en plus que l’autre ne suffisait pas à en faire un meilleur développeur
    • Ce qui compte vraiment, c’est ce qui a été mis en production (ship) et a contribué aux clients, au chiffre d’affaires et à la stabilité ; le nombre de lignes de code et de PR est appris depuis des décennies comme une mauvaise façon de mesurer
  • En 2026, tous les chiffres phares mis en avant par le secteur se concentrent sur la part de code écrite par l’IA
  • Tous ces chiffres sont des affirmations de volume, et la « part de code écrite par l’IA » n’est rien d’autre que le nombre de lignes de code avec une formule marketing plus raffinée
    • Le fait que toutes ces entreprises soient des fournisseurs d’IA renforce l’incitation à gonfler les chiffres d’adoption

Autrefois, on avançait des résultats

  • Il y a quelques années, le chiffre central n’était pas seulement d’une autre ampleur, mais d’une autre nature
    • L’affirmation phare de GitHub était qu’avec Copilot, on terminait les tâches 55 % plus vite
    • Malgré de nombreuses critiques, c’était une affirmation de résultat (outcome) : ambitieuse, réfutable et liée à la valeur — si elle était fausse, on pouvait le démontrer
  • Les affirmations de 2026 sont construites pour ne pas pouvoir échouer
    • « 75 % du code est écrit par l’IA » peut être vrai et continuer à augmenter sans aucun lien avec des déploiements plus rapides, moins d’incidents ou une meilleure satisfaction client
    • Les chiffres de volume ne déçoivent que lorsque l’adoption stagne, et la plupart des gens s’accordent à dire que l’adoption est bien réelle
  • Les affirmations ont grossi, mais leur signification a diminué

Ce qui n’arrive pas jusqu’aux panneaux publicitaires

  • Ce qui s’est passé entre-temps, c’est que les preuves de résultats sont devenues plus complexes

  • Des résultats qui soutiennent l’adoption

    • Cui et al. : sur environ 5 000 développeurs, +26 % de travail terminé, avec la plus forte amélioration chez les développeurs juniors — difficilement contestable

  • Des preuves allant dans l’autre sens

    • GitClear : plus l’adoption de Copilot s’approfondit, plus le churn du code augmente, avec un effondrement du refactoring
    • METR : des développeurs open source expérimentés utilisant l’IA sur leur propre base de code étaient 19 % plus lents, tout en croyant être 20 % plus rapides

  • Revirement de METR

    • En février 2026, METR a de fait retiré sa position — une estimation de suivi s’est inversée en gain de vitesse (speedup), avec toutefois une marge d’erreur très large
    • Les développeurs refusent désormais de travailler sans IA et ne peuvent plus auto-déclarer de manière fiable le temps pris par le travail des agents, au point de jeter le design de recherche lui-même
    • Position la plus récente : en 2026, l’IA augmente probablement la vitesse des développeurs, mais il est impossible de mesurer proprement l’ampleur de cet effet

  • Effet à l’échelle de l’entreprise

    • Enquête NBER auprès d’environ 6 000 dirigeants : 69 % des entreprises utilisent l’IA, et environ 9 sur 10 déclarent n’observer aucun effet mesurable sur la productivité
    • Le consensus transversal des études situe le gain à l’échelle organisationnelle autour de 10 % — utile, mais loin d’un monde où « les développeurs ne sont plus nécessaires »
  • Les sceptiques qui continuent à ne citer que le « 19 % plus lent » font eux aussi du cherry-picking ; les études continuent d’être mises à jour, tandis que le secteur change simplement ce qu’il mesure

La version IA des vanity metrics

  • Ce n’est pas seulement un problème propre aux affirmations des fournisseurs d’IA

  • Modèles de maturité et échelles

    • Carnegie Mellon SEI et Accenture ont lancé il y a quelques jours un AI Adoption Maturity Model — 5 niveaux, 8 dimensions, avec la statistique « 95 % des organisations n’ont pas de rendement » recyclée en marketing
    • Les « 8 levels of AI-assisted development » de Steve Yegge classent selon les outils utilisés et le niveau de supervision
    • Tous les fournisseurs d’outils lancent leur propre échelle de maturité, dont le sommet revient généralement à « utiliser davantage leur produit »
    • Ces échelles mesurent l’intensité d’adoption tout en l’appelant maturité : le même substitut, avec un emballage différent

  • Confusion dans les définitions

    • Quand Augment a demandé à 219 responsables engineering ce qu’était l’« AI-native engineering », ils ont donné 219 réponses différentes

  • Le double visage d’Anthropic

    • Tout en affirmant « 8 fois plus de code livré », l’entreprise a aussi publié l’une des études les plus rigoureuses de l’année
    • Résultat d’un RCT : les développeurs assistés par IA ont obtenu un score 17 % plus faible en compréhension du code qu’ils venaient de livrer, sans gain de productivité statistiquement significatif
    • Le pôle recherche met à jour ses conclusions pendant que le marketing compte le volume ; les deux peuvent être vrais en même temps

Pourquoi cela mérite de l’attention

  • Ces chiffres ne sont pas décoratifs : ils influencent les budgets, les attentes de performance et la planification des effectifs

  • Réductions d’effectifs justifiées par l’IA

    • En février, Jack Dorsey a réduit les effectifs de Block de plus de 40 % (4 000+ personnes), en présentant explicitement l’IA comme argument central — « des équipes plus petites peuvent faire plus, et mieux, avec les outils que nous construisons »
    • Quelques semaines plus tard, Atlassian a supprimé 10 % de ses effectifs (environ 1 600 personnes), en reconnaissant que « prétendre que l’IA ne change pas le mix de compétences ou le nombre de rôles nécessaires ne serait pas honnête »
    • Dans la même annonce, Dorsey soulignait que l’activité restait solide et que la marge brute continuait de croître

  • Doutes sur les affirmations de productivité

    • Si « l’IA rend tout le monde plus productif, donc moins de personnel est nécessaire », alors on devrait pouvoir voir cette preuve, mais elle n’existe pas à ce jour
    • Il faudrait démontrer qu’une partie des effectifs est réellement inoccupée ou sous-utilisée ; or les entreprises produit/SaaS ont des roadmaps sans fin, donc une capacité accrue devrait normalement se traduire en valeur client et en vitesse — visible dans les MAU, la conversion ou le chiffre d’affaires
    • Choisir les licenciements est un signal que l’argument de productivité sert déjà de PR à une décision prise pour d’autres raisons, comme le sureffectif ou la pression des investisseurs
  • Il peut y avoir des cas où des réductions fondées sur l’efficacité sont justifiées, mais dans ce cas il faut utiliser les systèmes d’évaluation individuelle déjà en place, et non le nombre de tokens, la « part de code écrite par l’IA » ou une note sur une échelle de maturité
    • Si la sélection repose sur des vanity metrics, alors cette sélection n’est rien d’autre qu’« une loterie avec du rouge à lèvres »

Conclusion

  • Ce n’est pas un texte anti-IA ; au contraire, la position est que tous les ingénieurs devraient utiliser l’IA chaque jour
    • Qu’on appelle cela AI-first ou AI-proficient, peu importe le nom : il faut tester avec curiosité les nouveaux outils et les derniers modèles
    • Le secteur a déjà absorbé les langages de haut niveau, les IDE, l’autocomplétion, l’agile et le devops ; il y a toujours eu des nostalgiques pour résister avant de finir par suivre
    • Cette fois, la différence, c’est la vitesse — on pouvait survivre en repoussant le « cloud » de quelques années, mais avec l’IA, ce ne sont peut-être que quelques mois
  • L’adoption de l’IA est une ligne de départ, pas un tableau de score
    • On sait déjà comment mesurer la performance engineering : métriques DORA, fiabilité, part de changements significatifs, et au final chiffre d’affaires et valeur client
    • Il n’y a aucune raison d’abandonner des méthodes éprouvées au profit de scores de vanité liés à l’IA
  • La question à poser face à un pitch vendeur, une revue de direction ou un fil LinkedIn : « s’agit-il d’un résultat, ou d’un volume ? »
  • La manière de travailler doit être AI-first, mais la manière de mesurer doit rester battle-tested

À lire aussi

1 commentaires

 
GN⁺ 4 시간 전
Commentaires sur Hacker News

  • Cette étrange tendance semble avoir culminé en février 2026 avec un billet de blog d’OpenAI [1]. Un post récemment arrivé en page d’accueil [2] parle du processus de création de quelque chose écrit à 100 % par des agents
    Mais il n’explique pas ce qu’est réellement cette chose, ni quelle valeur elle apporte aux utilisateurs. La description la plus proche est : « ce produit est utilisé en interne par des centaines de personnes, avec même des power users internes qui s’en servent tous les jours »
    En revanche, le fait qu’il y ait 1 million de lignes de code est répété deux fois dès les quelques centaines de premiers mots
    [1] https://openai.com/index/harness-engineering/
    [2] https://news.ycombinator.com/item?id=48416264

    • Si « ce produit est utilisé en interne par des centaines de personnes, avec même des power users internes qui s’en servent tous les jours », c’est probablement un filtre d’e-mails
      Et si c’est « 1 million de lignes de code » et « écrit à 100 % par des agents », ça paraît encore plus probable. Ou alors c’est un menu JS pour le wiki d’un département, qui revient en pratique à réécrire jquery en MS JScript puis à le transpiler en JS 5
    • L’ensemble du noyau Linux fait environ 40 millions de lignes, et sans les pilotes on est autour de 16 millions. J’ai du mal à imaginer que, sous prétexte que le machin d’OpenAI représente 6 % du nombre de lignes du noyau Linux, son utilité approche elle aussi des 6 %
      Même si les LLM sont très puissants, ça me semble presque impossible à maintenir
    • Le champ de distorsion de la réalité autour d’Anthropic est lui aussi puissant. Anthropic publie aussi quantité de billets de blog creux, qui semblent entièrement écrits par IA sans rien dire, et ça arrive en une avec des centaines d’upvotes de manière régulière
    • Ce n’était pas ça ?
      https://github.com/openai/symphony
    • J’ai été déçu par le manque de détails. Du coup, je pense qu’on verra bientôt des projets open source ou des tentatives montrant à quel point ce genre de chose est réellement efficace
      Dans une interview en podcast, ils disent que c’est une appli Electron que les utilisateurs téléchargent, donc ils produisent régulièrement de nouveaux builds. Voir la section « Autonomous Merging Flow » ici : https://www.latent.space/p/harness-eng

  • Je repense sans cesse à cette personne chez Microsoft qui avait posté quelque chose du genre « on veut 1 million de lignes de code par ingénieur et par mois ». Pour la plupart des ingénieurs à qui j’en ai parlé, ça se lisait comme de la satire, mais en réalité ce n’en était pas du tout, et ça reflétait assez bien l’attitude de nombreux CEO face à la génération de code par LLM
    Cela dit, ces derniers mois, j’ai l’impression que l’emballement autour de la production de volumes de code ingérables s’est un peu calmé. Des points de vue plus pratiques et plus réalistes sont davantage partagés publiquement, et ils commencent même à atteindre, petit à petit, les plus hauts niveaux de certaines entreprises tech. Tout n’est peut-être pas complètement foutu

    • J’ai déjà travaillé dans une entreprise qui exigeait 80 % de couverture de code. Un prestataire malin avait un script qui générait un seul fichier redimensionnable et sa propre suite de tests, afin d’atteindre 80 % sur l’ensemble de la base de code
      En pratique, l’essentiel du code n’était pas testé
    • 1 000 000 / 25 / 8 / 60 = plus de 83 lignes par minute
      1 million de lignes par mois / 25 jours par mois / 8 heures par jour / 60 minutes par heure
      Pour la personne qui fait la revue de code, ça semble poser un sacré problème
    • C’était vraiment hilarant de voir les dirigeants réaliser soudainement que les tokens, ça coûte de l’argent, puis corriger immédiatement les consignes d’utilisation de l’IA pour les employés
      Faire produire 1 million de lignes de code par mois à chaque ingénieur sans réfléchir à la manière dont ces lignes allaient faire gagner de l’argent à l’entreprise, ni au nombre de tokens qui allaient partir en fumée ni à leur coût, ça ne ressemblait visiblement pas à un plan très mûrement réfléchi
    • Pour parler du code généré en masse par l’IA, le mot slop était un bon choix. Même pour les non-techniciens, ça parle et ça transmet bien le côté répugnant. Il est évident que le slop est quelque chose à éviter
      À l’inverse, la dette technique n’a jamais eu le même effet sur les dirigeants. Une dette est généralement perçue comme quelque chose qui peut devenir problématique, mais qu’on peut ignorer ou repousser tant que le problème n’est pas encore là
    • Je me demande si la baisse de l’emballement autour de la production de volumes de code ingérables, ces derniers mois, vient aussi un peu du fait que les gens du business et du produit ont commencé à intégrer concrètement l’IA dans leur travail quotidien
      J’ai vu ça dans les deux petites entreprises où je travaille. Il y a quelques mois, on a eu Claude Cowork, tout le monde était très enthousiaste, et on l’utilise toujours chaque jour, mais par rapport à la magie attendue, c’est assez décevant
      Les résultats sont banals et verbeux, se trompent sur des choses très élémentaires, butent sans arrêt sur les limites de tokens, et on entend souvent dire qu’il est plus rapide de le faire soi-même, donc on revient au manuel
      Il y a sans doute aussi, au début, une part de mauvaise utilisation de l’outil, mais les gens réalisent qu’il existe encore un écart entre ce que racontent les CEO de l’IA, les marchands LinkedIn et les vendeurs de compléments AI sur YouTube, et la réalité

  • Si une entreprise dit que « l’IA a rendu tout le monde plus productif, donc on a besoin de moins de monde », j’aimerais voir les preuves. Pour l’instant, je ne crois pas que ces preuves existent
    En réalité, c’est du baratin, et l’IA sert d’excuse pour revenir sur la surembauche de l’époque Covid. En même temps, cela permet de donner aux investisseurs l’image d’une organisation plus agile et plus efficace en coûts parce qu’elle a adopté la dernière technologie à la mode

    • Donner aux investisseurs l’image d’une organisation plus agile et plus efficace en coûts parce qu’elle a adopté la dernière techno à la mode, ce n’est pas nouveau. On a juste changé le nom
    • La surembauche de l’époque Covid, c’est une excuse assez généreuse. À mes yeux, ça ressemble surtout à une tentative générale de faire baisser les salaires. Il y a eu plusieurs vagues de licenciements depuis, donc cette excuse vieille de six ans sonne particulièrement creux
      Je pensais que les investisseurs se souciaient davantage des profits que de l’adoption de la dernière techno à la mode
      Et une entreprise qui dit « nous aussi, on utilise une technologie tape-à-l’œil que n’importe quel imbécile dans sa chambre peut utiliser ! » est aussi une entreprise totalement dépourvue d’avantage concurrentiel

  • Il est sans fin cocasse que, pendant des décennies, notre secteur ait expliqué que « ce que nous faisons est complexe et prend du temps, donc on ne peut pas mesurer facilement la productivité », et que dès l’arrivée de l’IA, des choses comme le nombre de lignes de code, des multiplicateurs en Nx, ou le nombre de tickets par semaine soient soudain vénérées comme des indicateurs utiles ou objectifs.
    Les raisons pour lesquelles on rejetait des métriques comme le nombre de lignes de code n’ont pas changé. L’essentiel, ce n’est pas le volume de code produit, mais la qualité du résultat. L’IA a les mêmes problèmes que les humains. Et pourtant, pour une raison quelconque, on jette par-dessus bord ce qu’on avait appris, ce qui est un peu honteux

    • Des non-techniciens détiennent le pouvoir et ne sont pas liés à la réalité comme le sont les ingénieurs. Au final, la réalité objective l’emportera, mais cela n’empêche pas les dégâts à court terme
    • Est-ce qu’on a vraiment passé des décennies à expliquer que la productivité ne se mesure pas facilement ? Depuis dix ans, ce que j’ai vu, c’est surtout des ingénieurs comme des non-ingénieurs vénérer de plus en plus les graphiques d’activité GitHub. À mon avis, ce bazar s’était déjà égaré bien avant l’IA
    • Certains groupes d’ingénieurs logiciel ont peut-être développé le besoin de mesures prudentes. Mais le domaine de la programmation dans son ensemble ne s’est jamais vraiment détaché de l’idée des métriques simplistes.
      C’est parce qu’il y a toujours eu des managers peu impliqués, mais agressifs et exigeants. Et, malheureusement, même un manager dont la fonction principale consiste à extraire plus d’efforts de ses employés, sans contribuer à la coordination ou au reste, a une certaine valeur économique.
      Donc il y a toujours eu un nuage où coexistaient deux approches : les résultats réels et des mesures comme le nombre de lignes de code.
      L’IA fournit tous les outils nécessaires pour satisfaire ces managers peu impliqués mais très exigeants. Donc il y aura désormais encore plus de gens qui aiment prendre le nombre de lignes de code et l’ajout de fonctionnalités comme métriques. Parce que c’est devenu plus facile
    • En gros, toute cette manœuvre sert à pousser des machines à slop pour que la classe des milliardaires puisse mettre les gens à la rue

  • Si un développeur senior A+ passe 8 mois à construire une fonctionnalité qui ne sera finalement jamais livrée, ou qu’un MVP est abandonné, alors ce développeur senior A+ a été gaspillé, et sa productivité devient équivalente à celle de deux ingénieurs B+ sur le même projet.
    C’est en réalité un problème très courant, mais il est généralement ignoré dans le recrutement ou l’allocation des ressources sur les projets. L’IA ne changera probablement pas cela de manière significative.
    L’équipe pourra peut-être finir le travail bien plus vite, mais la couche bureaucratique au-dessus restera probablement la même, et dans ce cas les gains tirés du coding avec l’IA seront minimes. Pour s’adapter à l’IA, il faudrait reconstruire l’entreprise depuis le sommet, et cela n’arrivera presque jamais

    • Les ingénieurs ont tendance à voir cela de façon trop excessive comme du gaspillage. Cet investissement n’a pas été gaspillé : il a payé pour l’option de pouvoir lancer cette fonctionnalité ou ce MVP, ainsi que pour le coût de recherche nécessaire pour savoir si ce lancement se justifiait
    • Êtes-vous sûr que ces 8 mois ont vraiment été consacrés uniquement au « coding » ? Il y a la conception, les retours de l’équipe produit, les itérations, etc. Je ne sais pas où vous avez vu cette scène où un ingénieur A+ s’isole seul dans son box, puis ressort X mois plus tard avec un MVP, déconnecté de tout

  • La poussée pro-IA à la fin est étrangement infondée. Il n’y a ni raison, ni objectif, ni démonstration des bénéfices ; c’est juste « utilisez l’IA, les développeurs doivent adopter les nouveautés ».
    J’ai lu récemment d’autres textes qui faisaient semblant de critiquer l’IA sur un court paragraphe de contexte, pour finir ensuite en publicité pour l’IA, sans aucun lien entre les deux

    • L’IA est le nouveau cloud. Il n’y a pas de marché pour les personnes ou les entreprises qui ne s’y consacrent pas. Aucun développeur qui refuse d’utiliser l’IA ne sera embauché par la moindre entreprise, et si une entreprise décide de ne pas utiliser l’IA, elle aura du mal à retenir ses développeurs. Parce qu’il lui en faudra davantage.
      Les investisseurs et les gros clients y réfléchiront aussi à deux fois avant de signer des contrats importants.
      Donc il faut utiliser l’IA. Il ne faut pas chipoter sur les coûts et les bénéfices. Le monde va dans cette direction, et si vous voulez vivre du développement logiciel, vous devez aller dans cette direction vous aussi
    • Malgré tout, la valeur de l’IA est supérieure à 0. Ce n’est pas un point controversé

  • Le passage « cette fois, la différence, c’est la vitesse. On pouvait survivre en adoptant le cloud avec quelques années de retard. Pour l’IA, ce sera peut-être quelques mois » est étrange.
    L’auteur semble comprendre que les affirmations pro-IA des entreprises d’IA sur le caractère indispensable de leurs produits sont irréfutables, puis recule aussitôt avec un « attendez, n’allez pas croire que je suis anti-IA ».
    En quoi l’affirmation ci-dessus est-elle plus rigoureuse que les affirmations sur la productivité qu’il critique dans le reste du texte ? L’idée qu’on ne pourrait pas « survivre » sans adopter l’IA en l’espace de quelques mois ?
    Ce n’est pas vrai quand c’est un CEO de l’IA qui le dit, et ce n’est pas plus vrai quand quelqu’un qui dénonce les absurdités des CEO de l’IA dit exactement la même chose pour une autre raison

    • Si les CEO de l’IA disent cela, c’est pour faire monter le cours de l’action. Je n’ai jamais fait confiance aux CEO de l’IA parce qu’ils avancent des affirmations invérifiables sans aucun fondement.
      Dire qu’on licencie des gens à cause de l’IA laisse bien trop de place à l’interprétation et déplace la responsabilité de soi-même vers l’IA. En pratique, il ne faut pas attribuer à l’IA ce qu’un CEO a décidé de faire. Il aurait aussi pu requalifier ses employés pour les adapter à l’IA, mais il ne l’a pas fait. Pourquoi ? Peut-être parce que ce n’est pas vraiment à cause de l’IA
    • Il parle de considérations culturelles liées non pas à la productivité, mais à l’employabilité
    • C’est l’auteur. Critique valable, et merci d’avoir lu. Quand j’ai écrit « quelques mois », je voulais parler non pas de la survie des entreprises, mais des habitudes de travail individuelles, et je ne l’ai pas formulé assez clairement.
      Je l’ai bien écrit moi-même, ce n’est pas fabriqué en « AI slop » comme on le dit ailleurs, donc c’est probablement juste devenu « sloppy » de manière humaine à la fin.
      Vous avez raison sur le fait que je n’ai pas étayé le passage du « attendez », mais je maintiens quand même que les gens devraient essayer l’IA. Il faut expérimenter et trouver les façons dont cela peut vous aider. Même parmi des ingénieurs similaires, le spectre des manières d’en tirer de la valeur était très large.
      Le coût pour essayer sérieusement l’outil est presque nul, et la position « adoptez-le volontairement et mesurez-le avec des méthodes éprouvées et ennuyeuses » n’est pas la même chose que « si vous ne l’adoptez pas, vous mourrez »
    • Il est normal que les gens prennent en compte les motivations derrière les propos. Ici, je pense que les motivations sont suffisamment différentes pour qu’il y ait une différence. Un CEO de l’IA a un motif clair pour mentir, alors que quelqu’un qui qualifie cela de bullshit n’a pas de motivation aussi évidente

  • Quand une entreprise dit que « l’IA a rendu tout le monde plus productif, donc on a besoin de moins de personnel », elle dit implicitement qu’elle ne veut pas devenir plus productive
    Elle veut la même productivité en payant moins un plus petit nombre de personnes plus productives
    Pourquoi existe-t-il un tel déséquilibre entre l’argent que l’employeur reçoit par unité de production et celui que reçoit l’employé ?

    • Parce que le travail est exploité pour enrichir davantage les propriétaires. C’est le fait de base, et la classe des propriétaires a financé beaucoup de propagande pour le justifier et le dissimuler
    • Ne veut-on pas parler non pas de « même productivité », mais de même production avec moins de personnes ? Par définition, dans ce cas la productivité de l’entreprise a augmenté. La productivité au niveau d’une entreprise ou d’un pays est le ratio entre la production et les intrants
      Obtenir la même production avec moins de personnes améliore la productivité de l’entreprise ou du pays
      Avec moins de personnes et la même productivité, la production diminue en proportion, donc il n’y a aucun gain pour l’entreprise, et avec des coûts fixes cela peut même être pire
      https://www.mckinsey.com/featured-insights/mckinsey-explaine...

  • Je considère que le nombre de lignes de code n’est pas très différent du temps passé au bureau. Avant la pandémie, on entendait toujours : « S’ils ne sont pas au bureau, comment savoir s’ils travaillent ? »
    C’est simple. Il suffit de regarder ce qu’ils apportent à l’entreprise à travers les indicateurs de résultats déjà utilisés pour évaluer tous les employés

  • Je pense que si les lignes de code sont encore perçues comme un actif plutôt qu’un passif, c’est en grande partie la faute de nous, les ingénieurs. Nous sommes fiers de ce que nous créons, mais pour expliquer à quel point quelque chose est “grand”, il faut une mesure, et on finit par revenir à celle qu’il est le plus facile de compter
    Il faut changer de vocabulaire. En particulier, il faut utiliser beaucoup plus souvent des formulations comme « ...et cela a coûté N lignes de code ». Il faut aussi dire à quoi ces lignes de code ont servi
    « Nous avons implémenté la nouvelle fonctionnalité X, et cela n’a coûté que 200 lignes »
    « Ce bug était vraiment très difficile à trouver, mais au final il n’a coûté que 6 lignes de code »
    « Dans le cas X, on faisait quelque chose qu’on ne faisait pas dans le cas Y, mais il s’est avéré que cette distinction elle-même n’était pas nécessaire. Du coup, en corrigeant le problème, on a aussi économisé 20 lignes de code »
    Les lignes de code sont le prix que nous payons. Nous ne nous vantons pas d’avoir dépensé 200 dollars sans dire ce que nous avons acheté. Pourquoi le ferait-on avec les lignes de code ?
    « J’ai dû payer 200 dollars de plus parce que j’ai fait ma demande trop tard » et « J’ai acheté un support de lampe artisanal en céramique peinte à la main pour seulement 200 dollars ; la version industrielle sur Amazon coûte plus de 1 200 dollars » sont deux choses totalement différentes, et dans le code cela correspond exactement à la même distinction.