« Je n’écris plus, je relis du code généré par l’IA » : le quotidien d’une dév en 2026

 

Et si le vrai coût de l’IA en entreprise n’était pas le code qu’elle écrit, mais la compréhension qu’elle remplace ? Récit fictif d’une développeuse qui voit son métier glisser de l’architecture vers la relecture de code généré par des agents.

 

 

Hier j’ai passé deux heures à relire une pull request (PR) générée par le PM. Pas un dév, un product manager. Il a branché Cursor sur le repo, a décrit ce qu’il voulait, et il a ouvert une PR. Les tests automatiques avaient validé son code. Mais, surprise : le code ne faisait pas ce qu’il prétendait faire. Fatiguant.

 

Dans ce code, une fonction de 80 lignes gérait à la fois la validation métier, l’accès à la base SQL et le formatage de la réponse HTTP. Aucune séparation de responsabilité, aucune réutilisation de code pré-existant. Le genre de truc qu’on corrige chez un stagiaire en semaine 2. Sauf que là, c’est en prod et c’est le PM qui a mergé sa propre branche sur main parce que les tests sont verts. Depuis quand son agent a les droits, déjà ! ? J’ai mis quarante minutes à écrire un commentaire de revue suffisamment diplomatique pour ne pas déclencher une n-ième réunion de crise. Enfin, moi j’ai écrit la version franche, Claude l’a rendue acceptable.

 

Les tâches de ce genre s’empilent. Mon backlog explose. Depuis janvier, un dév sort 7 PR par jour, c’est insensé. Je n’écris plus, je relis du code vibe-codé.

 

Un process, un agent. C’est le mantra du moment. Revue de PR ? Agent. Cohérence entre documentation et code ? Agent. Lien entre specs et implémentation ? Agent. Et tout ça dans un empilement de couches fragiles, qui tient tant que les serveurs d’Anthropic, Microsoft et Google tournent et que personne ne change le nom d’une variable globale dans un fichier que trois agents différents indexent indépendamment. La tour de Babel version IA. Mais les dashboards disent que tout va bien, alors on va les croire, non ? On sait comment ça a fini : mal.

 

Ce matin, le pipeline de compilation est cassé parce qu’Anthropic avait un incident à 3 heures du matin. Toute la CI bloquée. Stand-up réunion à 9 heures, personne ne comprenait pourquoi les builds étaient rouges. Incident ouvert depuis 4 h 47. Notre quota de tokens n’était pourtant pas atteint… J’ai vérifié la page Anthropic en trente secondes. Personne n’avait eu l’idée. Une boîte de cent cinquante personnes, dépendante des SLA semi-moisis d’une boîte californienne dont on n’est même pas client entreprise. On utilise la version gratuite de leurs interfaces de programmation (API) avec un plafond de tokens qu’on dépasse en milieu de mois. Le CTO appelle ça « optimiser les coûts ». Moi j’appelle ça « construire sur du sable ». Mais ça plaît beaucoup aux membres du conseil d’administration, alors on applique.

 

La semaine dernière un junior a posé une question à propos du comportement bizarre de SQLAlchemy ; ça sentait la session qui se ferme trop vite ou mal. Mon tech lead l’a interrompu en plein milieu : « T’as demandé à Claude avant ? » Le junior a ouvert une fenêtre de chat, a copié-collé son message et cinq minutes plus tard Claude lui a donné trois pistes dont deux fausses et une qui marchait par accident. Il a implémenté la troisième, sans trop comprendre. J’aurais pu lui répondre en quarante secondes, et lui expliquer pourquoi. Là, le code est « tombé en marche » et le junior n’a rien appris. Les communicants de StationF [une pépinière de start-up] appellent ça la « capitalisation des savoirs ». J’ai vingt ans d’expérience, et je sais voir la fragilité quand je la vois. C’est flagrant.

 

Les nouveaux n’ont pas de full TT. Les anciens l’ont gardé, sinon on démissionnait, mais je ne suis plus sûr que ce soit encore un avantage. On ne se parle plus vraiment. La communication d’équipe s’est restructurée autour d’un machin qui ne se souvient de rien d’une session à l’autre. Les décisions d’archi se prennent dans des fils de chat avec un modèle IA sous ecstasy. La semaine d’avant, on avait trois agents qui se contredisaient sur ce que la spec disait. Un pour les PR, un pour la doc, un pour les tickets de suivi. Aucun ne lisait le même état du repo. Le dév qui avait mis ça en place était fier. Il appelait ça du harness engineering. Je ne sais même plus ce que ça veut dire, je croyais qu’il fallait utiliser OpenClaw, du MCP et des skills.

 

Ah ! Les skills. Que du bonheur. Ici, on en a cinq pour avaler du tableur et des csv, et trois pour ne pas écrire de requêtes SQL. La base de la base de l’ETL, pourtant. Je n’en peux plus. Plus personne n’apprend rien, personne ne progresse et je passe ma vie à débugger leurs… créations. La dette technique prospère, la dette cognitive enfle.

 

Il y a douze mois je faisais de l’architecture. Je participais à des décisions techniques. J’étais dans la conception. Maintenant je fais de la relecture de code que personne n’a écrit, dans des environnements que personne ne veut comprendre : Python 3.9, 3.11 et 3.13, pyenv ici, uv là, un venv qui traîne depuis deux ans, trois containers Docker régénérés toutes les nuits car personne ne veut s’attaquer à la conf, et des specs un peu partout qui ont été transformées en tickets par un agent et en code par un autre. On a automatisé la partie intéressante et gardé la partie pénible.

 

Je suis fatiguée. Pas du boulot, mais de ce que le boulot est devenu. Si je suis là encore en septembre, je remplace deux gars. Un dév sénior sur Reddit disait que l’IA amplifie ce qui est déjà là, les bonnes pratiques comme les mauvaises. Chez nous, elle a surtout amplifié le désordre. On a donné des outils pour pousser du code à des gens qui n’ont pas appris à en écrire. Je ne sais pas comment on va faire. Le web va-t-il tenir ?

 

 

Les mots du dév

Branche main : branche principale, état de référence du code. Ce qui part en production.

Builds : résultat de la CI. Le programme compilé et testé. « Les builds sont rouges » = quelque chose est cassé.

CI/Chaîne d’Intégration continue : système automatisé qui compile, teste et vérifie le code à chaque modification. Si ça passe, c’est vert. Si ça casse, c’est rouge.

Cursor : éditeur de code (fork de VS Code) avec intégration IA native, vibe coding. Permet de générer du code directement dans l’éditeur via un chat ou des raccourcis.

ETL : Extract-transform-load. Pipeline qui extrait des données d’une source, les transforme, les charge ailleurs.

Harness : ensemble de règles et conventions données à un agent pour encadrer son comportement. Pratique de gestion d’agents IA à la mode.

MCP : Model context protocol. Standard qui permet à un agent IA d’appeler des outils externes (chercher dans une doc, faire une recherche web, interroger une base).

Merger : fusionner une branche dans une autre. Intégrer le travail terminé.

Product manager (PM) : responsable produit. Définit les fonctionnalités, priorise le backlog, fait le lien entre le métier et l’équipe technique. N’est pas censé coder.

Pull Request (PR) : demande de fusion de code. Un dév termine son travail sur une branche, ouvre une PR pour que ses collègues relisent avant d’intégrer dans la branche principale.

Repository/Repo : espace de stockage versionné du code source. En pratique, un projet sur GitHub, Gitlab, etc.

Skills : fichiers de connaissance semi-structurés fournis à un agent IA pour lui donner du contexte métier ou technique persistant.

SLA : Service level agreement. Engagement contractuel de disponibilité d’un service. « 99,9 % d’uptime » par exemple.

Specs/Spécifications : document qui décrit ce qu’un développement doit faire, avant de le faire. Peut être fonctionnel (comportement attendu) ou technique (comment c’est construit).

TT : télétravail.

Vibe coding : produire du code en le faisant écrire par des outils de génération IA.