J'ai pas lu l'article seulement ton commentaire. Parfois les dev. me donnent l'impression qu'ils (surtout ils) se prennent pour des dieux, pour une espèce supérieure à celle de l'Homo sapiens en tout cas. Et je crains que l’intelligence artificielle n'oblige certains à se remettre en question.
Il est indéniable que le métier va évoluer, tout comme passer de l'assembleur au c, ou de l'ajout de framwork ont chamboulé la façon de travailler, ou la façon d'organiser / architecturer nos projet (micro-service, architecture hexagonale, agile, cycle en V…)
De mon expérience sur des petits truc simple, ça permet mes de se dispenser de faire du code, on itère un peu avec l'agent, il fait un truc qui fait le taf.
Par contre dès qu'on complexifie, l'approche par itération et correction génère pleins de code mort, inutile peu performant, ne fonctionnant pas dans pas mal de cas, chaque corrections sur ces cas risque d'en casser d'autre, l'agent iter, iter, iter… Alors qu'en quelques minutes je vois ce qu'il faut changer pour que ça marche, alors que l'ia iter, iter iter…
Cela reste un outil très puissant, permettant de faire des évolutions propres avec les tests, mais parfois elle se plante (trop compliqué, réinvente la roue, n'utilise pas l'existant, utilise une façon archaïque et inadaptée…) Bref si tu surveille pas, la dette technique celle qui fait que les évolutions sont de plus en plus difficile a faire explose.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
Je le dénis. Ou plutôt, ça se base sur une hypothèse qui est que le matériel et les services en ligne seront toujours disponibles et de mieux en mieux, que l'on n'aura pas de crise énergétique, de ressources ou des conflits géopolitiques à haute intensité.
Avec de la RAM très chère et des PC / téléphones / équipements que l'on ne peut renouveler, ça change déjà les hypothèses, avec un risque qu'il faille au contraire mettre le paquet sur l'optimisation, par absence de choix (l'autre possibilité étant payer très cher le matériel, ce qui rendrait aussi les développeurs / le logiciel compétitifs vis-à-vis du coût du matériel).
Bref tu as peut-être raison, peut-être pas, ça reste une intuition sur l'avenir / un début de prédiction. Mais « indéniable », non, de moins en moins.
La dépendance aux services en ligne et au bon vouloir de ceux qui les contrôlent est un gros soucis en effet.
Par contre on peut déjà faire tourner un agent IA sur un microcontrôleur à 4€ (clears your inbox, sends emails, manages your calendar, and checks you in for flights from WhatsApp, Telegram, or any chat app) et avec windows 365, on réinvente le thin client (mais ils sont pas assez fort chez MS pour en faire une station diskless ;)
C'est un complot pour faire disparaitre les power users qui compilent encore leur noyau à la main sur leur propres machines à mon avis.
"Si tous les cons volaient, il ferait nuit" F. Dard
Par contre on peut déjà faire tourner un agent IA sur un microcontrôleur à 4€ (clears your inbox, sends emails, manages your calendar, and checks you in for flights from WhatsApp, Telegram, or any chat app) et avec windows 365, on réinvente le thin client (mais ils sont pas assez fort chez MS pour en faire une station diskless ;)
Normal la partie qui consomme c'est l'IA, l'agent n'est qu'un petit programme qui envoie un peu de texte à ces IA à distance localement ou en ligne. Ce n'est pas demain que tu auras le même agent qui tourne localement sur ce genre de configs.
Il est indéniable que le métier va évoluer, tout comme passer de l'assembleur au c, ou de l'ajout de framwork ont chamboulé la façon de travailler, ou la façon d'organiser / architecturer nos projet (micro-service, architecture hexagonale, agile, cycle en V…)
Alors. Comment dire.
Des générateurs de code ça existe depuis des décennies. T'as même des générateurs de parsers de code, des codes qui décrivent des générateurs de parsers de code.
De l'architecture hexagonale ça existe aussi depuis des décennies. Et peut-être que tu découvriras un jour ce que c'est qu'une architecture urbanisée.
Et comme tout informaticien qui pète plus haut que son cul, exigence première de recrutement dans le métier : tu proclameras avoir découvert la prochaine révolution informatique.
J'aime de plus en plus ce métier. L'avantage c'est qu'en branlant rien de ces journée on est toujours parfaitement à jour…
J'aimerais bien qu'on me considère au rang de génie mais pas au rang de dieu.
Quand un client a besoin de toi et uniquement de toi, tu te sens au dessus de tout.
De manière générale avoir un sentiment de supériorité rend heureux (je ramènerai pas cela à la sécrétion de l'hormone du bien être, mais ça me tente quand-même de la citer)
Posté par Pol' uX (site web personnel) .
Évalué à 3 (+1/-0).
Dernière modification le 04 mars 2026 à 21:22.
il n'ose pas modifier ce qu'il a écrit il y a plus de 7 jours.
si on lui demander de faire évoluer une fonctionnalité, il pose la réécriture de la fonctionnalité comme un ré-requis. Il livre 7 jours après la fonctionnalité sans l'évolution mais avec des bugs différents.
Quand on automatise / simplifie, on ne remplace pas un métier, on le transforme avec souvent des effets rebonds :
l'invention de la tronçonneuse n'a pas remplacé les bûcherons : plus de gens peuvent couper des arbres eux mêmes dans leur jardin, mais pour raser une forêt, on appelle un bûcheron ;
l'arrivée des grands magasins de bricolage n'a pas fait disparaître les artisans : tout le monde peut bricoler à la maison et faire appel à un artisan pour de gros travaux ;
les langages de haut niveau, les générateurs de code et les LLM ne remplacent pas les devs : plus de gens peuvent faire du développement eux mêmes et appeler un expert quand on veut que ça marche si c'est trop complexe.
Bref si tout le monde peut être bûcheron, artisan ou dev, on a juste plus de bûcherons, plus d'artisans et plus de devs à la fin.
Ce post est offensant ? Prévenez moi sur https://linuxfr.org/board
# Beurk
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 10 (+13/-1).
Un article sur l'irremplaçabilité des développeurs qui s'ouvre avec une image moche générée par IA, il fallait le faire.
Les illustrateurs sont irremplaçables eux aussi…
[^] # Re: Beurk
Posté par Ysabeau 🧶 (courriel, site web personnel, Mastodon) . Évalué à 7 (+6/-2).
J'ai pas lu l'article seulement ton commentaire. Parfois les dev. me donnent l'impression qu'ils (surtout ils) se prennent pour des dieux, pour une espèce supérieure à celle de l'Homo sapiens en tout cas. Et je crains que l’intelligence artificielle n'oblige certains à se remettre en question.
Je n’ai aucun avis sur systemd
[^] # Re: Beurk
Posté par fearan . Évalué à 6 (+3/-0).
On en reviens toujours à ça :
https://www.commitstrip.com/fr/2016/08/25/a-very-comprehensive-and-precise-spec/
Il est indéniable que le métier va évoluer, tout comme passer de l'assembleur au c, ou de l'ajout de framwork ont chamboulé la façon de travailler, ou la façon d'organiser / architecturer nos projet (micro-service, architecture hexagonale, agile, cycle en V…)
De mon expérience sur des petits truc simple, ça permet mes de se dispenser de faire du code, on itère un peu avec l'agent, il fait un truc qui fait le taf.
Par contre dès qu'on complexifie, l'approche par itération et correction génère pleins de code mort, inutile peu performant, ne fonctionnant pas dans pas mal de cas, chaque corrections sur ces cas risque d'en casser d'autre, l'agent iter, iter, iter… Alors qu'en quelques minutes je vois ce qu'il faut changer pour que ça marche, alors que l'ia iter, iter iter…
Cela reste un outil très puissant, permettant de faire des évolutions propres avec les tests, mais parfois elle se plante (trop compliqué, réinvente la roue, n'utilise pas l'existant, utilise une façon archaïque et inadaptée…) Bref si tu surveille pas, la dette technique celle qui fait que les évolutions sont de plus en plus difficile a faire explose.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Beurk
Posté par Benoît Sibaud (site web personnel) . Évalué à 8 (+5/-0).
Je le dénis. Ou plutôt, ça se base sur une hypothèse qui est que le matériel et les services en ligne seront toujours disponibles et de mieux en mieux, que l'on n'aura pas de crise énergétique, de ressources ou des conflits géopolitiques à haute intensité.
Avec de la RAM très chère et des PC / téléphones / équipements que l'on ne peut renouveler, ça change déjà les hypothèses, avec un risque qu'il faille au contraire mettre le paquet sur l'optimisation, par absence de choix (l'autre possibilité étant payer très cher le matériel, ce qui rendrait aussi les développeurs / le logiciel compétitifs vis-à-vis du coût du matériel).
Bref tu as peut-être raison, peut-être pas, ça reste une intuition sur l'avenir / un début de prédiction. Mais « indéniable », non, de moins en moins.
[^] # Re: Beurk
Posté par Luc-Skywalker . Évalué à 3 (+1/-0).
oui et non.
La dépendance aux services en ligne et au bon vouloir de ceux qui les contrôlent est un gros soucis en effet.
Par contre on peut déjà faire tourner un agent IA sur un microcontrôleur à 4€ (clears your inbox, sends emails, manages your calendar, and checks you in for flights from WhatsApp, Telegram, or any chat app) et avec windows 365, on réinvente le thin client (mais ils sont pas assez fort chez MS pour en faire une station diskless ;)
C'est un complot pour faire disparaitre les power users qui compilent encore leur noyau à la main sur leur propres machines à mon avis.
"Si tous les cons volaient, il ferait nuit" F. Dard
[^] # Re: Beurk
Posté par Renault (site web personnel) . Évalué à 3 (+0/-0).
Normal la partie qui consomme c'est l'IA, l'agent n'est qu'un petit programme qui envoie un peu de texte à ces IA à distance localement ou en ligne. Ce n'est pas demain que tu auras le même agent qui tourne localement sur ce genre de configs.
Ce n'est pas ça qui importe en fait.
[^] # comment dire
Posté par Nicolas (site web personnel) . Évalué à 2 (+1/-0).
Alors. Comment dire.
Des générateurs de code ça existe depuis des décennies. T'as même des générateurs de parsers de code, des codes qui décrivent des générateurs de parsers de code.
De l'architecture hexagonale ça existe aussi depuis des décennies. Et peut-être que tu découvriras un jour ce que c'est qu'une architecture urbanisée.
Et comme tout informaticien qui pète plus haut que son cul, exigence première de recrutement dans le métier : tu proclameras avoir découvert la prochaine révolution informatique.
J'aime de plus en plus ce métier. L'avantage c'est qu'en branlant rien de ces journée on est toujours parfaitement à jour…
[^] # Re: Beurk
Posté par Amiralgaby . Évalué à 1 (+0/-0).
J'aimerais bien qu'on me considère au rang de génie mais pas au rang de dieu.
Quand un client a besoin de toi et uniquement de toi, tu te sens au dessus de tout.
De manière générale avoir un sentiment de supériorité rend heureux (je ramènerai pas cela à la sécrétion de l'hormone du bien être, mais ça me tente quand-même de la citer)
Amiralgaby#1847
[^] # Re: Beurk
Posté par devnewton 🍺 (site web personnel) . Évalué à 6 (+3/-0).
En duck typing, un dev est indissociable d'un Dieu:
Ce post est offensant ? Prévenez moi sur https://linuxfr.org/board
[^] # Re: Beurk
Posté par Benoît Sibaud (site web personnel) . Évalué à 7 (+4/-0).
[^] # Re: Beurk
Posté par Pol' uX (site web personnel) . Évalué à 3 (+1/-0). Dernière modification le 04 mars 2026 à 21:22.
Adhérer à l'April, ça vous tente ?
[^] # Re: Beurk
Posté par Ysabeau 🧶 (courriel, site web personnel, Mastodon) . Évalué à 3 (+0/-0).
D'une manière générale, il n'aime pas corriger des bugs. Il préfère en faire des nouveaux.
Je n’ai aucun avis sur systemd
[^] # Re: Beurk
Posté par fearan . Évalué à 3 (+0/-0).
Et quand c'est trop la merde, il arrive comme le messie pour dire comment faut faire, et se barre avant la mise en place de la solution
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Beurk
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2 (+0/-0).
En fait ce sont des animaux politiques quoi (:
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Beurk
Posté par Thomas (site web personnel) . Évalué à 0 (+0/-1).
# Automatisation != remplacement
Posté par devnewton 🍺 (site web personnel) . Évalué à 5 (+2/-0). Dernière modification le 04 mars 2026 à 11:06.
Quand on automatise / simplifie, on ne remplace pas un métier, on le transforme avec souvent des effets rebonds :
quand on veut que ça marchesi c'est trop complexe.Bref si tout le monde peut être bûcheron, artisan ou dev, on a juste plus de bûcherons, plus d'artisans et plus de devs à la fin.
Ce post est offensant ? Prévenez moi sur https://linuxfr.org/board
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.