Depuis que l’IA écrit une bonne part de mon code, mes journées ne sont pas plus courtes. Elles ont changé de contenu : écrire le code prend beaucoup moins de temps, et tout ce qui l’entoure a pris la place.
Ce qui est allé plus vite
Le premier jet d’un écran, une migration, les tests d’une règle métier déjà claire, une traduction, la documentation d’une API, la lecture d’un repo qu’on n’a pas ouvert depuis six mois. Sur ces tâches, le gain est net, parfois du simple au triple à vue de nez. Mais c’est la partie du métier qu’on voit, et la facture se remplit ailleurs.
Décider
Sur mon outil de prospection, un modèle note les entreprises selon la probabilité qu’elles m’achètent un logiciel. Il donnait presque la même note haute à tout le monde. Réécrire le prompt m’a pris une soirée.
Le reste a pris des jours : choisir quelle erreur me coûte le plus, un bon prospect jamais vu ou un mauvais qui me fait perdre une heure, puis trier à la main des dizaines de sociétés pour avoir de quoi mesurer. Aucun assistant ne prend cette décision, parce qu’il ne sait pas ce qui vous coûte.
Spécifier
Sur un logiciel de gestion, une entreprise de démonstration voyait s’afficher « votre abonnement est résilié », parce que le code ne distinguait pas « démo » de « arrêté ». La modification tenait en une condition et un message, cinq minutes.
La demi-heure d’avant a servi à répondre à ce que le code ne demande pas. Que doit lire une entreprise en démonstration ? Qui peut changer ce statut ? Que voit un administrateur qui usurpe le compte d’un collègue ? L’IA écrit très bien le comportement qu’on lui décrit, pas celui dont vous avez besoin.
Vérifier
Un assistant produit du code qui a l’air juste, et c’est ce qui le rend trompeur.
Une pull request corrige un bug et cite deux issues voisines comme dettes non traitées, avec un lien vers chacune. Une automatisation qui ferme « les issues liées » les ferme toutes les deux, et deux bugs toujours présents disparaissent du suivi.
Une version de ma gem de facturation électronique passait ses 317 tests et ne se chargeait pas chez qui n’avait pas déjà deux de ses dépendances. Aucun outil ne m’a signalé le contrôle qui manquait. Il fallait savoir que les tests tournent dans le repo, et que l’utilisateur installe le package.
Sécuriser
Cet été, les fuites se sont enchaînées. La DGFiP a confirmé des accès illégitimes à son système d’information entre juin et août, avec des identifiants usurpés, et 678 000 personnes seraient concernées selon le ministère. L’Éducation nationale a subi une intrusion dans sa plateforme de formation des personnels, qui a pu exposer les données de ses agents en poste depuis 2001. SFR a prévenu en août des clients Fibre dont les coordonnées ont été lues via un outil interne. Sur l’année 2025, la CNIL a reçu 6 167 notifications de violations de données, 9,5 % de plus qu’en 2024.
Beaucoup de ces fuites ne demandent aucun talent. Au printemps, 11,7 millions de comptes de l’ANTS ont été exposés par une faille attribuée à une IDOR : il suffisait de changer le numéro d’un dossier dans l’URL pour lire celui de quelqu’un d’autre, parce que le serveur ne vérifiait pas à qui il appartenait.
C’est exactement le genre de code qui a l’air juste. L’écran fonctionne, les tests passent, et la faille ne se voit qu’une fois exploitée. Relire chaque changement en cherchant qui pourrait en abuser prend autant de temps qu’avant, et produire plus de code en produit davantage à relire.
Répondre de la production
Lors d’un audit récent sur un logiciel, les corrections de code ont pris une fraction du temps d’il y a deux ans. Ce qui reste sur ma liste, ce sont des opérations d’exploitation qu’on ne rejoue pas, faites à la main par quelqu’un qui en répond. Et quand la production tombe un samedi soir, le modèle n’est pas d’astreinte.
Ce que ça change quand on commande un logiciel
Ran Craycraft, chez thoughtbot, pose bien la question : faire construire un prototype par une IA ne coûte presque plus rien, donc autant s’en servir pour vérifier qu’une idée mérite un vrai investissement. Il ajoute que le moment dangereux arrive quand le prototype marche et qu’on croit la production à portée de main. Un prototype sert à apprendre vite. Une application en production doit protéger des données, contrôler des accès et tenir quand quelque chose tombe.
Le code était rarement le poste le plus cher d’un projet, seulement le plus visible. Quand vous payez un prestataire, vous payez surtout les décisions qu’il prend avec vous, ce qu’il vérifie avant de livrer, sécurité comprise, et le fait qu’il réponde de ce qui tourne chez vous. Un devis « trois fois plus rapide grâce à l’IA » suppose que le projet se résumait à écrire du code : demandez ce que deviennent les décisions, les vérifications, la sécurité et la production.
Senko Rašić rappelle que dire « le code n’a jamais été la partie difficile » méprise un métier entier. Écrire du code demande toujours un savoir-faire. Son coût a baissé, celui du reste non.
Si vous hésitez entre un prototype et un vrai projet, on peut regarder votre contexte ensemble.