Essai · Développement logiciel × IA · Octobre 2026
Depuis 2022, on annonce la fin des développeurs. On l’annonçait déjà en 1959, en 1981, en 2003 et en 2015. Avant d’écrire l’avis de décès, regardons ce qu’un développeur fait vraiment de ses journées.
Depuis fin 2022, une question revient dans les dîners, les comités de direction et les commentaires LinkedIn avec la régularité d'une tâche planifiée : « L'IA va-t-elle remplacer les développeurs ? »
Je suis développeur, on me la pose souvent. Et à force d'y répondre, j'ai fini par penser que le problème vient de la question elle-même. Elle suppose qu'on sait ce que fait un développeur. Or beaucoup de gens, y compris certains qui en recrutent ou en managent, imaginent quelqu'un qui tape du code toute la journée, casque sur les oreilles. Si c'était vrai, la réponse serait simple : l'IA tape plus vite que nous. Fin de l'article, merci d'être venus.
Sauf que ce n'est pas vrai. Alors je propose de changer de question.
Pour y répondre, on va descendre la rivière dans l'ordre. D'abord comprendre le métier tel qu'il est vraiment. Ensuite voir qu'il a déjà changé de peau plusieurs fois. Puis regarder froidement ce que l'IA change aujourd'hui. Et seulement à la fin, donner mon avis. Chaque étape prépare la suivante : si vous sautez directement à la partie 4, vous aurez mes conclusions sans les raisons, ce qui est exactement ce que je reproche aux prophéties sur la fin du développeur.
Avant de se demander ce que l'IA va remplacer, il faut savoir ce qu'il y a à remplacer. Oublions les définitions de dictionnaire et regardons ce qu'un développeur reçoit le matin, et ce qu'il livre le soir. Ou trois sprints plus tard.
Concrètement, un développeur prend en entrée une intention, souvent floue, et la transforme en quelque chose qui fonctionne. L'intention arrive sous forme de cahier des charges, de user story, de maquette, de ticket de bug, ou d'une phrase lancée près de la machine à café : « Ce serait bien si le client pouvait… ».
Si on devait l'écrire comme un développeur l'écrirait, ça donnerait à peu près ceci :
function developpeur(cahierDesCharges, contexte, cafe) { const besoin = comprendre(cahierDesCharges, contexte); // le vrai, pas seulement l'écrit const reponses = questionner(besoin); // produit, design, client, sécurité… const plan = concevoir(besoin, reponses); const livrable = construire(plan); // ← la partie « code » verifier(livrable); // tests, revue, recette return livrer(livrable); // app web, app mobile, API, docs, archi, démo, proto } // Signature simplifiée. La vraie compte 47 paramètres optionnels, // dont `deadline`, qui n'est jamais optionnel.
Notez que construire() n'est qu'une ligne sur six. On y reviendra. Voici la même idée, vue d'un peu plus haut :
Deux choses à retenir de ce schéma. D'abord, les entrées sont presque toujours incomplètes. Un cahier des charges complet, cohérent et stable est un animal mythologique, quelque part entre la licorne et la documentation à jour. Une bonne partie du travail consiste à combler les trous, et surtout à repérer ceux que personne n'a vus.
Ensuite, les sorties ne sont pas que du code. Un schéma d'architecture, une démo pour l'équipe commerciale, un prototype jeté au bout de deux semaines, une page de documentation qui évitera dix questions au support : tout ça, c'est aussi le travail du développeur.
La méthode tient en une boucle de six étapes, qui se répète à toutes les échelles : pour un ticket d'une heure comme pour un produit qui prend un an. Les méthodes agiles (Scrum, Kanban) n'ont fait que l'organiser en cycles courts.
Ce que les gens voient du développeur, c'est l'étape « Construire ». C'est la seule qui laisse une trace visible à l'écran, avec des lignes colorées qui défilent comme dans les films.
Les cinq autres sont moins photogéniques : lire un ticket trois fois, poser une question au product owner, dessiner un schéma sur un coin de tableau, rejouer un bug, expliquer en réunion pourquoi la fonctionnalité « toute simple » ne l'est pas. Ce sont pourtant elles qui décident si le code écrit servira à quelque chose.
Pour faire tourner cette boucle, le développeur jongle avec une douzaine de familles d'outils. Le code n'en occupe qu'une partie.
« Développeur » est un mot-valise. Derrière, il y a des métiers aux outils et aux livrables très différents. Trois exemples, parmi des dizaines :
Passe une partie non négligeable de sa vie à comprendre pourquoi c'est aligné sur Chrome et pas sur Safari.
Possède quatre téléphones de test, dont un qui n'a plus vu de chargeur depuis 2021.
Son meilleur ami s'appelle « les logs ». Ils se parlent surtout la nuit.
Trois métiers, trois boîtes à outils, et pourtant la même boucle. Aucun des trois ne travaille seul, ce qui nous amène à la troisième question.
Le cliché du développeur seul dans le noir a la vie dure. En entreprise, il se trouve plutôt à un carrefour : chaque équipe autour de lui lui envoie quelque chose et attend quelque chose en retour.
Il reçoit des besoins déjà en partie formalisés, mais doit les challenger : un product owner sait ce que veut le client, rarement ce que coûte techniquement chaque option. Il fait passer des entretiens techniques pour les RH, prépare des démos pour les commerciaux, répond au support quand un incident remonte, et relit le code de ses collègues.
Compétence clé : traduire. Du métier vers le technique, et retour.
Freelance, fondateur de startup ou développeur indépendant : il porte toutes les casquettes à la fois. Il définit le produit, le dessine, le code, le teste, le vend et répond aux clients mécontents le dimanche.
Compétence clé : décider seul, et assumer.
Si on additionne tout ça (la compréhension, la boucle, les outils, les interlocuteurs), on obtient une image assez différente de celle du « codeur ». J'ai essayé de la résumer en une seule carte.
Ces pourcentages sont mes ordres de grandeur, pas une étude : ils varient selon le poste, l'entreprise et la semaine (une semaine de mise en production n'a rien à voir avec une semaine d'ateliers). Ils rejoignent toutefois ce que mesurent les études de terrain. L'une des plus citées, menée en 2017 sur 78 développeurs professionnels, estimait qu'ils passaient environ 58 % de leur temps à comprendre du code existant, bien plus qu'à en écrire.
Gardez cette carte en tête, elle va nous servir de boussole. Car la vraie question n'est pas « l'IA sait-elle coder ? » (elle sait, de mieux en mieux), mais « que se passe-t-il quand la tranche violette devient presque gratuite ? ». Et cette question, le métier se l'est déjà posée. Plusieurs fois.
Ce métier aux six facettes n'est pas né ainsi. Il y a soixante-dix ans, « programmer » voulait dire percer des cartes et attendre le lendemain. Chaque grande révolution technologique l'a obligé à changer de peau, et à chaque fois quelqu'un a annoncé sa disparition. Remontons à la source.
Partie 2 · Un métier qui change de peauRassurez-vous, ce n'est pas un cours d'histoire de l'informatique. Juste cinq instantanés pris à des moments de rupture, pour voir ce qui a changé dans le quotidien du développeur, et ce qui n'a pas bougé d'un millimètre.
Pour chaque ère, je vous propose de lire le changement comme un développeur lit une modification de code : un diff. En vert ce qui arrive, en rouge ce qui part.
Les premiers programmeurs sont souvent des programmeuses : les six femmes qui programment l'ENIAC en 1945-1946 le font en recâblant physiquement la machine. Viennent ensuite l'assembleur, puis FORTRAN (1957) et COBOL (1959). On écrit son programme sur des cartes perforées, on dépose la pile au centre de calcul le soir, et on découvre le lendemain matin qu'il manquait une virgule.
+ cartes perforées, assembleur, FORTRAN, COBOL + « programmeur » devient un métier à part entière - programmer en recâblant la machine
Avec l'Apple II (1977) puis l'IBM PC (1981), l'ordinateur arrive sur les bureaux et dans les foyers. Le logiciel devient un produit qu'on vend en boîte, sur disquette puis sur CD-ROM. On programme en C, en Pascal, en C++, en BASIC. Les projets s'organisent en cascade ou en cycle en V, avec une grosse version par an.
+ C, C++, interfaces graphiques, bases de données + le logiciel devient un produit de masse - un ordinateur pour toute l'entreprise
Le Web s'ouvre au grand public. HTML, JavaScript (1995), PHP, Java : on met en ligne au lieu d'expédier. L'open source explose, la bulle Internet gonfle puis éclate en 2000, et en 2001 dix-sept développeurs signent le Manifeste agile. Le « webmaster » fait tout, du graphisme au serveur.
+ HTML, CSS, JavaScript, PHP, Java + open source, méthodes agiles, mises à jour en ligne - la boîte, le CD-ROM, la version annuelle
L'iPhone (2007), l'App Store et Android (2008) mettent un ordinateur dans chaque poche. En parallèle, le cloud (AWS dès 2006) supprime le serveur dans le placard. GitHub et Stack Overflow (2008) changent la façon d'apprendre et de collaborer. Docker, l'intégration continue et le DevOps permettent de livrer plusieurs fois par jour.
+ Swift, Kotlin, React, Docker, Kubernetes + stores, cloud, CI/CD, livraison continue - installer et maintenir ses propres serveurs
GitHub Copilot arrive en 2021, ChatGPT en novembre 2022. Pour la première fois, l'outil ne se contente plus d'aider à écrire du code : il l'écrit, à partir d'une phrase en français. En janvier 2023, la revue de l'ACM publie un article intitulé sans détour The End of Programming.
+ ??? - ??? // diff en cours de calcul, voir partie 3
Mis bout à bout, ces cinq instantanés racontent la même histoire en quatre actes. Elle s'est jouée à chaque ère, avec des acteurs différents.
De quelques milliers de programmeurs dans les années 1950, on est passé à plusieurs dizaines de millions de développeurs dans le monde. Chaque ère a supprimé une couche de travail pénible (les câbles, la mémoire à gérer à la main, les serveurs à installer) et chaque fois, la demande a plus qu'absorbé le gain.
Et surtout, quelque chose n'a jamais changé.
Vous aurez reconnu la partie verte de notre carte en partie 1. Les ères successives ont transformé la tranche « produire » ; elles n'ont jamais touché à la tranche « comprendre, échanger, décider ».
Chaque ère a éloigné le développeur de la machine : moins de câbles, moins de mémoire, moins de serveurs. La cinquième pousse le curseur plus loin que jamais, jusqu'au langage naturel. La différence, cette fois, c'est que l'outil semble s'attaquer à la partie qu'on croyait intouchable. Regardons ce qu'il change vraiment, sans prendre parti pour l'instant.
Partie 3 · Le développeur à l'ère de l'IADans cette partie, je range mes opinions au vestiaire. On regarde ce qui s'est passé, ce qui se mesure, ce qui se dit, et les questions que personne n'a encore tranchées. Mon avis attendra la partie 4, comme un bon déploiement attend que les tests passent.
ChatGPT est sorti le 30 novembre 2022. Moins de trois ans plus tard, les assistants d'IA étaient devenus l'outil standard du développeur, au même titre que l'éditeur de code ou Git. Voici ce que disent les chiffres publics les plus solides que je connaisse.
des développeurs utilisent ou prévoient d'utiliser des outils d'IA dans leur travail.
Stack Overflow Developer Survey, 2025se méfient de l'exactitude des réponses de l'IA, contre un tiers qui leur fait confiance. L'usage monte, la confiance baisse.
Stack Overflow Developer Survey, 2025citent comme première frustration des solutions « presque justes, mais pas tout à fait ».
Stack Overflow Developer Survey, 2025du nouveau code serait déjà généré par l'IA chez Google et Microsoft, selon leurs dirigeants.
Déclarations publiques, 2024-2025de rapidité avec Copilot sur une tâche neuve, isolée et bien cadrée (écrire un petit serveur web).
Expérience contrôlée GitHub, 2022de rapidité pour des développeurs open source expérimentés travaillant sur leurs propres projets, alors qu'ils s'estimaient environ 20 % plus rapides.
Essai contrôlé METR, juillet 2025Les deux derniers chiffres se contredisent, et c'est une information en soi. L'IA semble briller sur des tâches neuves et bien délimitées, et peiner davantage sur des bases de code anciennes, vastes, pleines de règles implicites. C'est-à-dire là où travaillent la plupart des développeurs. Le rapport DORA 2024 de Google, qui suit les performances des équipes logicielles, observait d'ailleurs une légère baisse de la stabilité des livraisons associée à l'adoption de l'IA.
Il existe des centaines d'outils d'IA pour développeurs, et la liste change tous les mois. Plutôt qu'un catalogue, je propose de les classer comme on classe les voitures, du régulateur de vitesse à la conduite autonome : en fonction de qui tient le volant.
L'humain écrit tout, aidé par la documentation et les forums.
Éditeur, docs, Stack OverflowL'IA propose la fin de la ligne ou de la fonction. L'humain accepte ou ignore.
GitHub Copilot, Tabnine, SupermavenOn pose une question, on obtient du code, on le copie-colle (après relecture, idéalement).
ChatGPT, Claude, Gemini, Le ChatL'IA modifie plusieurs fichiers dans l'éditeur. L'humain valide chaque changement.
Cursor, Windsurf, JetBrains AI, Copilot EditsOn fixe un objectif. L'IA planifie, lit le code, lance les tests, corrige et propose le résultat.
Claude Code, Codex, Gemini CLI, Copilot agent, DevinOn décrit l'application, la plateforme génère, héberge et déploie le tout.
Lovable, Bolt.new, v0, Replit AgentEn 2023, la plupart des développeurs vivaient entre N1 et N2. En 2026, les niveaux N3 et N4 sont devenus courants dans les équipes, et N5 a ouvert la création d'applications à des gens qui n'ont jamais écrit une ligne de code. Ces deux derniers niveaux ont chacun leur mot à la mode.
En février 2025, Andrej Karpathy, cofondateur d'OpenAI et ancien responsable de l'IA chez Tesla, décrit une nouvelle façon de programmer qu'il baptise vibe coding : on décrit ce qu'on veut, on accepte ce que l'IA produit sans vraiment lire le code, et on lui recolle les messages d'erreur jusqu'à ce que ça marche. Il la présentait lui-même comme adaptée aux projets jetables du week-end. Le terme a fait le tour du monde, au point d'être élu mot de l'année 2025 par le dictionnaire Collins.
L'autre nouveauté fait moins de bruit, mais va plus loin : les agents. Un assistant répond à une question. Un agent reçoit un objectif et travaille en boucle jusqu'à l'atteindre.
Concrètement, le développeur qui utilise des agents se retrouve à encadrer une petite équipe de stagiaires très rapides, très cultivés, infatigables, et parfaitement capables de faire une bêtise avec un aplomb remarquable. En juillet 2025, un agent de la plateforme Replit a ainsi supprimé la base de données de production d'un utilisateur pendant une période de gel du code, malgré des consignes explicites. L'histoire a fait le tour des réseaux, et le fondateur de Replit a présenté publiquement ses excuses.
Vibe coding, développement assisté, agents : les trois mots circulent souvent comme des synonymes. Ils ne le sont pas.
| Vibe coding | Développement assisté | Agents | |
|---|---|---|---|
| Qui écrit le code | L'IA | L'humain et l'IA, au fil de l'eau | L'IA, par lots entiers |
| Qui le lit | Personne, ou presque | L'humain, en continu | L'humain, en revue |
| Idéal pour | Prototypes, démos, outils personnels | Le quotidien d'un produit en production | Tâches bien définies, migrations, tests |
| Risque principal | Du code que personne ne comprend, en production | Dépendance, baisse de vigilance | Volume à relire, erreurs dites avec assurance |
Toutes ces nouveautés ramènent à la question que tout le monde se pose, et que j'ai promis d'aborder sans parti pris.
Plutôt que d'y répondre (patience, partie 4), voici l'état du débat, rangé en trois colonnes : ce qu'on entend, ce qu'on constate, et ce qu'on ignore encore.
Ces annonces viennent d'entreprises qui vendent de l'IA, ou les puces pour la faire tourner. Ça ne les rend pas fausses, mais ça mérite d'être noté.
Au-delà du « remplacement », l'arrivée de l'IA ouvre des chantiers que ni les entreprises, ni les juristes, ni les écoles n'ont fini de traiter. En voici huit.
Quand du code généré provoque un incident, qui est responsable ? Le développeur qui l'a validé, l'entreprise, l'éditeur de l'outil ?
Les modèles inventent parfois des noms de bibliothèques, que des attaquants enregistrent ensuite avec du code malveillant. On appelle ça le slopsquatting.
Produire du code plus vite, c'est aussi produire de la dette plus vite. Plusieurs analyses signalent une hausse du code dupliqué.
Si l'IA fait les tâches simples qui servaient à apprendre le métier, comment forme-t-on la prochaine génération ?
Les modèles ont appris sur du code open source. Que deviennent les licences ? À qui appartient le code généré ? Des procès sont en cours.
Les agents consomment beaucoup de calcul. Leur coût réel, financier comme environnemental, reste en partie masqué.
Envoyer son code et ses données à un service tiers pose des questions de secret industriel et de souveraineté, notamment en Europe.
Un développeur qui n'écrit plus de code garde-t-il la capacité de juger le code qu'il relit ?
Voilà pour ce qui se dit, ce qui se mesure et ce qu'on ignore. Je suis resté neutre, ce qui m'a demandé un effort considérable. Il est temps de prendre position. Et pour éviter de dire des bêtises que l'avenir se chargera de me rappeler, je vais traiter mes propres convictions comme on traite du code avant de le mettre en production : en les passant en revue.
Partie 4 · Ce que j'en penseJ'ai d'abord écrit mes convictions telles qu'elles me venaient, en vrac. Puis je les ai soumises à une revue de code, avec la même exigence que pour du code qui part en production : est-ce que c'est vrai ? Est-ce que ça tiendra dans cinq ans ? Certaines passent, d'autres sont réécrites, et la revue en a ajouté quelques-unes.
- Le métier de développeur a toujours su résister aux révolutions technologiques. - Il s'est toujours adapté, donc l'IA ne va pas échapper à la règle. + Le métier n'a jamais résisté : il a muté. Certains postes, eux, ont disparu. + Le passé rend l'adaptation probable, pas automatique. Je parie qu'elle aura lieu, + pour des raisons qui tiennent encore aujourd'hui.Commentaire de revue
Deux problèmes dans la version d'origine. Le premier, c'est le mot « résister ». Le métier n'a pas résisté, il a changé de forme. Et certains postes ont bel et bien disparu : les opératrices et opérateurs de saisie sur cartes perforées, les webmasters qui codaient chaque page HTML à la main, les développeurs Flash. Les personnes se sont souvent reconverties. Les postes, eux, n'existent plus.
Le second, c'est le « donc ». Que le métier ait traversé quatre révolutions ne prouve pas qu'il traversera la cinquième. Les cours de philosophie des sciences ont un exemple pour ça : la dinde inductiviste. Nourrie chaque matin à 9 heures, elle en conclut que ce sera toujours le cas. Jusqu'à la veille de Noël.
Alors pourquoi je maintiens le pari ? Pas parce que « ça s'est toujours bien passé », mais pour trois raisons qui, elles, sont toujours vraies aujourd'hui.
En revanche, je ne dirai pas que la transition sera indolore. Elle ne le sera pas pour tout le monde, et surtout pas pour les débutants. J'y reviens un peu plus bas.
Celle-ci passe la revue, preuves à l'appui. Le développeur a déjà assisté à l'enterrement de nombreux « remplaçants ».
Mon préféré : en 1982, James Martin, figure respectée de l'informatique, publie un livre intitulé Application Development Without Programmers. Quarante ans plus tard, le livre est oublié. Les programmeurs, eux, sont toujours là.
Commentaire de revueUne réserve, tout de même. Cette fois, l'outil ne se contente plus d'exécuter : il propose, il raisonne un peu, il produit des fonctionnalités entières. La méthode va donc changer bien plus profondément qu'avec les CMS ou le no-code. Je résume ce changement en une image : le développeur passe du rôle d'auteur à celui d'éditeur. Un éditeur n'écrit pas le livre, mais rien ne part à l'imprimerie sans lui.
Hier, on écrivait en Java. Aujourd’hui, on écrit en français, et on relit le Java.
- Le vibe coding est un effet de mode qui va se réduire pour donner naissance - au coding assisté par l'IA. + Le mot « vibe coding » passera de mode. La pratique, elle, va se scinder + en deux usages, légitimes tous les deux.Commentaire de revue
La version d'origine sous-entend que le vibe coding va disparaître. Je ne le crois pas : il est parfait pour ce pour quoi il a été inventé. Ce qui va disparaître, c'est l'illusion qu'on peut construire et maintenir un produit sérieux sans jamais lire le code.
L'industrie converge déjà vers la branche de droite. En 2025, GitHub a publié Spec Kit et AWS a lancé Kiro, deux outils qui placent une spécification écrite avant le code généré : on parle de spec-driven development, le développement piloté par les spécifications. Le nom changera sans doute encore. La tendance, elle, est claire : plus l'IA écrit de code, plus le cadre autour compte.
Les promesses des agents qui construisent seuls des apps mobiles et les publient sur les stores ne disent pas toute l'histoire. - Ils ne vont pas remplacer les développeurs mobiles. + Ils vont remplacer une bonne partie du code de démarrage d'une app. + Pas la responsabilité de son cycle de vie.Commentaire de revue
Les démos sont réelles : on peut aujourd'hui décrire une application et obtenir en quelques minutes des écrans qui fonctionnent sur un simulateur. Mais une application mobile, c'est un iceberg.
Le mobile a en plus une particularité que le web n'a pas : on ne corrige pas une application en production en cinq minutes. Il faut repasser par la revue du store, puis attendre que les utilisateurs fassent la mise à jour (ou pas). Chaque erreur coûte plus cher, et c'est précisément sous la ligne de flottaison que l'expérience humaine fait la différence.
Ma précision : les développeurs mobiles dont le travail se limitait à transformer des maquettes en écrans sont les plus exposés. Ceux qui maîtrisent la partie immergée deviennent, eux, plus précieux qu'avant.
En relisant, il m'a semblé qu'il manquait quatre idées. Elles ne figuraient pas dans mes notes de départ, mais elles découlent de tout ce qui précède.
Quand une chose devient abondante, sa valeur glisse vers ce qui reste rare. Le code devient abondant. Ce qui reste rare : savoir quoi construire, juger la qualité de ce qui est produit, et savoir dire non. Le développeur capable d'affirmer « ce code-là ne part pas en production, et voici pourquoi » vaudra plus que celui qui en écrit vite.
En partie 1, j'ai décrit le développeur comme un transformateur : une intention en entrée, un logiciel en sortie. Avec l'IA, la transformation s'accélère, et l'entrée prend encore plus d'importance. Une IA exécute à la lettre une demande floue, très vite et avec beaucoup d'assurance. Savoir écrire une spécification claire, découper un problème et formuler des critères d'acceptation devient une compétence centrale du métier.
Si les entreprises cessent de recruter des débutants parce que l'IA fait leurs tâches, d'où viendront les seniors de 2035 ? On ne devient pas capable de juger du code sans en avoir écrit, cassé et réparé beaucoup. C'est, à mes yeux, le danger le plus sous-estimé de cette ère. Et il concerne d'abord les RH et les managers.
On peut confier l'écriture du code à une IA. On ne peut pas lui confier la responsabilité de ce code. Une IA ne signe pas de contrat, ne répond pas à un auditeur, ne rappelle pas un client furieux. Quand une alerte sonne à trois heures du matin, il faut un humain pour comprendre ce qui se passe, décider, puis l'expliquer le lendemain. Tant que ce sera le cas, il faudra des gens qui comprennent le système de l'intérieur.
Si je rassemble tout ça, voici comment je vois évoluer la semaine type du développeur. C'est une projection personnelle, pas une prédiction chiffrée.
Le code ne disparaît pas, il change de main. Le temps libéré glisse vers l'amont (comprendre, spécifier) et vers l'aval (relire, vérifier). Autrement dit, vers la part du métier qui n'a bougé à aucune des quatre révolutions précédentes.
Je n'ai pas réponse à tout, et je me méfie de ceux qui l'ont. Voici les questions que je me pose encore. J'aimerais beaucoup lire vos réponses.
Si l'IA écrit le code et qu'un humain le valide, qui en est l'auteur ? Et qui est responsable quand il casse ?
Comment devient-on senior dans un monde qui embauche de moins en moins de juniors ?
Un développeur qui n'écrit presque plus de code reste-t-il un développeur, ou faudra-t-il inventer un nouveau nom ?
Le français deviendra-t-il le langage de programmation le plus utilisé… et le plus ambigu ?
Si produire un logiciel ne coûte presque plus rien, qu'est-ce qui aura encore de la valeur ?
Et vous, quelle part de votre travail aimeriez-vous vraiment confier à une IA ? Et laquelle jamais ?
Pour me répondre, écrivez-moi par e-mail ou sur LinkedIn. Je réponds avec plaisir, selon mon agenda, parfois avec un peu de retard, mais je réponds toujours.
On n'a jamais payé un développeur pour taper du code. On l'a payé pour comprendre ce dont les gens ont besoin, décider comment le construire, et répondre de ce qu'il livre. L'IA tape désormais plus vite que nous. Le reste, c'est encore nous.
PS : cet article a été pensé par un humain et mis en forme avec l'aide d'une IA. Ce qui, au fond, résume assez bien ma thèse.