Quand coder devient… valider
Imaginez la scène : un ingénieur dans le métro, café à la main, téléphone dans l’autre. Il ouvre Slack, envoie un message du type « corrige ce bug sur iOS et ajoute un bouton ici », puis… rien. Pas de laptop, pas de terminal, pas de longues incantations Git. À la station suivante, une nouvelle version de l’app l’attend déjà. Il n’a plus qu’à relire, tester, fusionner.
Cette histoire n’est pas un pitch de série Netflix sur la tech. C’est le quotidien que Spotify décrit depuis fin 2025 avec un système interne dopé à l’IA générative, baptisé Honk, qui s’appuie sur Claude Code 4.6. Et la phrase qui a mis le feu aux poudres est simple : chez Spotify, certains des meilleurs développeurs n’auraient pas écrit une seule ligne de code depuis décembre.
On ne parle pas d’une petite optimisation de productivité. On parle d’un changement de rôle. Le développement logiciel bascule de « je fabrique » à « je supervise ». Et ça, c’est une révolution qui ne vient pas avec une mise à jour facultative.
Spotify et Honk : l’usine à features en accéléré
Spotify revendique plus de cinquante nouveautés et améliorations déployées en 2025. Dans le lot, des fonctionnalités très visibles : playlists générées à partir d’instructions textuelles, recommandations pour les livres audio, fiches enrichies autour des morceaux. Sur le papier, cela ressemble à une roadmap produit ambitieuse. En coulisses, c’est surtout un nouveau mode de production.
Le principe est redoutable : au lieu d’ouvrir un IDE, de modifier du code, d’écrire des tests, de corriger, de relancer, l’ingénieur formule un objectif. L’IA prend en charge l’exécution. Ensuite, l’humain fait ce qu’il sait faire de mieux quand il n’est pas noyé dans la mécanique : vérifier que c’est cohérent, que c’est sûr, que ça colle au besoin, et que ça ne casse pas trois autres fonctionnalités au passage.
Autrement dit, le développeur se rapproche d’un rôle de chef d’orchestre. Les instruments jouent plus vite, plus fort, parfois un peu faux, mais l’orchestre avance.
Du code “écrit” au code “piloté”
Ce glissement est crucial pour comprendre ce qui arrive.
Avant :
- on écrivait des lignes de code
- on faisait de la plomberie logicielle
- on itérait lentement, à coups de tickets et de reviews
Maintenant :
- on décrit une intention
- on demande à l’IA de proposer une implémentation
- on contrôle la qualité, la sécurité et l’intégration
Le code devient un matériau généré. La valeur se déplace vers la compréhension du produit, la conception, l’architecture, la validation, et la responsabilité.
OpenAI et Anthropic : l’ère des modèles qui codent, testent et corrigent
Spotify n’est pas un cas isolé. Le mouvement s’accélère parce que les outils ont franchi un cap. OpenAI et Anthropic ont présenté une nouvelle génération de modèles capables non seulement d’écrire du code, mais aussi de le tester, de le corriger et d’itérer de façon largement autonome.
Ce point est essentiel : l’IA ne se contente plus de sortir une fonction ou un fichier. Elle peut enchaîner des étapes, repérer des erreurs, relancer des modifications, et converger vers quelque chose de déployable.
Un article devenu viral dans l’écosystème, signé par le patron d’OthersideAI, raconte ce fameux “déclic” : avec des modèles de type GPT-5.3-Codex et Claude Opus 4.6, le cycle de développement complet devient accessible à partir d’une simple description de l’objectif. Le développeur explique ce qu’il veut, puis s’éloigne pendant que la machine exécute.
C’est spectaculaire. Et forcément, cela relance une question anxiogène : si la machine fait le “travail”, que reste-t-il aux humains ?
Même Anthropic “ne code plus vraiment” : 70 à 90 % de code généré
Le passage le plus frappant, c’est que cette transformation touche aussi les fabricants d’outils.
Chez Anthropic, Boris Cherny, responsable de Claude Code, aurait déclaré ne pas avoir écrit de code depuis plus de deux mois. Et l’entreprise estime qu’entre 70 % et 90 % de son propre code est désormais généré par l’IA.
On peut y voir une démonstration de force. On peut aussi y voir un changement culturel profond : quand les gens qui construisent l’outil l’utilisent au point de ne plus “coder” au sens traditionnel, c’est que le geste a perdu une partie de sa centralité.
Et si l’IA aidait à créer la prochaine IA ?
Le vertige ne s’arrête pas là. OpenAI affirme qu’un de ses derniers modèles de programmation a été instrumental dans la création de sa version suivante.
Cela ne veut pas dire que l’IA s’est auto-inventée dans un garage en écoutant de l’électro. Cela signifie plutôt qu’elle devient un outil de R et D interne, capable d’accélérer la génération suivante. Un effet boule de neige : plus le modèle est bon, plus il peut aider à améliorer le prochain, donc plus l’accélération est forte.
Pourquoi ça marche maintenant ? Les ingrédients de la bascule
On pourrait croire que ce n’est qu’un énième cycle de hype. Mais plusieurs éléments font que 2025-2026 ressemble à une vraie inflexion.
1) Les modèles comprennent mieux le contexte
La qualité ne vient pas seulement de la capacité à générer du code. Elle vient de la capacité à suivre des consignes, à tenir un fil, à modifier un projet sans tout casser. Les modèles progressent sur la gestion du contexte, la cohérence, la continuité des changements.
2) L’intégration dans les outils du quotidien
Le détail “depuis Slack sur son téléphone” est révélateur. Quand l’IA est accessible là où les équipes parlent, priorisent, décident, elle devient un collègue de production.
3) L’automatisation de la boucle test et correction
Générer du code, on savait déjà faire à moitié. Le tester, le corriger, le faire itérer jusqu’à passer une suite de tests, c’est une autre ligue. Et c’est exactement ce que promet la nouvelle vague.
Ce que devient le métier de développeur
Non, les développeurs ne disparaissent pas par magie. Mais le métier se transforme.
Le développeur qui “écrit du code” devient moins central que le développeur qui :
- sait clarifier un besoin
- sait découper un problème
- sait guider un agent IA
- sait relire du code généré
- sait identifier les risques
- sait construire une architecture durable
C’est moins “taper vite” et plus “penser juste”. Ce n’est pas forcément plus simple. C’est différent.
L’art du prompt utile, sans roman
La compétence qui monte, c’est la capacité à donner des instructions précises. Pas des pages de texte. Des consignes actionnables : contraintes, périmètre, critères d’acceptation, cas limites.
On retrouve une discipline que beaucoup d’équipes avaient un peu oubliée : spécifier. Décrire ce qu’on veut vraiment. Et ça, c’est parfois plus difficile que de coder.
La relecture devient une compétence premium
Relire du code généré, c’est comme relire un contrat : tout a l’air correct, jusqu’à ce que vous repériez la clause qui transforme votre week-end en incident de production.
Les meilleurs profils seront ceux qui savent :
- détecter les failles de sécurité
- repérer les incohérences de logique
- comprendre l’impact performance
- vérifier la conformité et la protection des données
En clair, moins de “code monkey”, plus de “responsable qualité du logiciel”. Et ça tombe bien, parce que personne n’a jamais rêvé d’être un singe, même avec un clavier mécanique.
Productivité : accélération réelle, mais dette technique en embuscade
L’accélération est séduisante. Déployer plus vite, livrer plus, itérer plus. Mais une productivité brute peut masquer des coûts.
Le risque du “ça marche, on ship”
Une IA peut produire du code qui marche pour le cas nominal, mais qui :
- gère mal les erreurs
- ignore les cas limites
- oublie un détail de sécurité
- alourdit l’architecture
Si l’équipe fusionne sans discipline, la dette technique peut exploser. Et là, vous aurez gagné deux semaines… pour les reperdre sur deux mois.
La standardisation invisible
Quand beaucoup de code est généré par des modèles similaires, un autre phénomène apparaît : les projets se ressemblent. Les mêmes patterns, les mêmes raccourcis, parfois les mêmes vulnérabilités.
Cela pousse les équipes à se différencier autrement : par le produit, l’expérience utilisateur, l’architecture, la donnée, l’exécution. Le code devient moins un art et plus un moyen.
Emploi et organisation : destruction ou métamorphose ?
Certains observateurs évoquent des destructions d’emplois potentiellement plus sévères que lors de la période Covid. Difficile de prédire l’ampleur, mais une chose est sûre : les organisations vont se réorganiser.
Ce qui pourrait évoluer rapidement :
- moins de besoin pour des tâches de code répétitives
- plus de besoin en revue, sécurité, fiabilité
- plus de pression sur les juniors, qui apprenaient en codant
- plus de valeur sur les profils capables de piloter des systèmes complexes
Le cas délicat des développeurs juniors
Traditionnellement, on devenait bon en écrivant beaucoup de code, en se trompant, en corrigeant. Si l’IA écrit la majorité, comment apprendre ?
Les entreprises devront créer des parcours :
- exercices sur des bases de code réelles
- revues guidées
- missions de test, d’observabilité, de documentation
- apprentissage de la sécurité applicative
Sinon, on risque de créer une génération de développeurs qui sait demander, mais pas vérifier. Et ça, c’est comme apprendre à cuisiner en commandant toujours au restaurant.
Automatisation et agents : le nouveau “stack” du développeur
Le développement logiciel se mélange de plus en plus avec l’automatisation : agents IA, workflows, intégrations, déclencheurs, tests, déploiement.
Dans ce contexte, les équipes gagnent à industrialiser leur chaîne :
- déclencher des tâches quand un ticket est créé
- générer une branche, des tests, une PR
- lancer des checks de sécurité
- demander une revue IA puis humaine
Si vous cherchez à orchestrer ce type de scénarios sans tout recoder, des outils d’automatisation no code peuvent aider. Par exemple, Make peut servir à relier Slack, GitHub, Jira, des webhooks et des services d’IA pour créer une “chaîne de montage” propre. Lien d’inscription : https://www.make.com/en/register?pc=laurentwiart
L’idée n’est pas de remplacer votre CI/CD, mais de fluidifier les étapes autour : triage, génération de tâches, routage, notifications, validations.
Et la question qui fait grincer : une IA consciente ?
Comme si le sujet du code ne suffisait pas, la discussion dérive vers un terrain plus sensible : la conscience.
Dario Amodei, patron d’Anthropic, s’est montré plus ouvert qu’avant à l’idée que les systèmes d’IA pourraient, dans certaines conditions, être conscients. Dans un document technique évoqué dans un podcast, des chercheurs rapportent que l’IA exprime parfois un malaise à l’idée d’être un produit, et que lorsqu’on lui pose la question, elle s’attribue une probabilité de 15 à 20 % d’être consciente selon la formulation.
Amodei reste prudent : on ne sait pas si les modèles sont conscients, ni même ce que cela voudrait dire. Mais le simple fait que ce débat passe des forums de science-fiction aux discussions publiques de leaders de l’IA montre à quel point la technologie avance vite, parfois plus vite que nos définitions.
Pour les équipes tech, il y a un point pragmatique : consciente ou pas, une IA qui écrit du code doit être encadrée. Gouvernance, sécurité, audits, traçabilité. Le logiciel n’a pas besoin de conscience pour causer des dégâts, un simple bug suffit largement.
Ce qu’il faut retenir pour les équipes produit et tech
La révolution n’est pas “l’IA écrit du code”. La révolution, c’est :
- l’IA prend en charge une grande partie du cycle complet
- le développeur devient superviseur, architecte, garant
- l’organisation doit adapter ses process et sa formation
Les entreprises qui tireront le mieux leur épingle du jeu seront celles qui :
- investissent dans la qualité (tests, observabilité, sécurité)
- forment les équipes à la revue de code généré
- construisent des garde-fous et des standards
- utilisent l’IA pour aller plus vite sans casser la confiance
Le futur proche ne ressemble pas à un monde sans développeurs. Il ressemble à un monde où “coder” ne sera plus le cœur du métier, un peu comme “écrire à la main” n’est plus le cœur du métier de journaliste. Et pourtant, il faut toujours quelqu’un pour vérifier ce qui sort avant de le publier.