« Je peux le faire en 1h avec Astra en ultra code »

La scène se rejoue chaque semaine. Un client nous écoute présenter un chantier de trois semaines, sourit poliment, puis sort son téléphone : « Franchement, je peux le faire en 1h avec Astra en ultra code. Un WordPress, un plugin IA, une skill qui découpe le projet en cinquante agents, le modèle le plus puissant du moment, et une petite heure de corrections pour du 100 % final. »

Cinquante agents. Une heure. Cent pour cent. On aimerait beaucoup vivre dans ce monde-là : on facturerait moins, on dormirait plus. Le problème, c’est que les mesures disent autre chose, et que la facture de ce genre de raccourci arrive toujours, simplement plus tard et plus salée.

Précisons tout de suite : on utilise l’IA tous les jours, pour écrire du code, des textes, des automatisations. Ce n’est pas un article contre l’IA. C’est un article contre l’idée qu’un outil puissant remplace le fait de savoir ce qu’on fait avec.

L’heure existe, c’est la suite qui pose problème

Soyons honnêtes : en une heure, un modèle récent sort une page d’accueil crédible, un formulaire, trois sections et un pied de page. C’est impressionnant, et c’est exactement là que le malentendu commence. Ce qu’on voit à l’écran n’est que la partie émergée.

Ce qu’on ne voit pas : le formulaire qui n’enregistre pas les leads quand l’email échoue, les balises qui empêchent Google d’indexer la moitié des pages, la version anglaise qui pointe vers la française, le plugin qui ouvre une porte sur la base de données, la clé d’API laissée dans le code. Rien de tout ça ne se remarque pendant la démo. Tout ça se remarque trois mois plus tard, en général un vendredi soir.

Les ingénieurs ont un nom pour ce phénomène depuis les années 1980, la règle du « 90-90 » attribuée à Tom Cargill, des laboratoires Bell : les premiers 90 % du code prennent 90 % du temps, et les 10 % restants prennent les autres 90 %. L’IA a comprimé les premiers 90 %. Elle n’a pas touché aux seconds.

« Le modèle le plus puissant » ne va pas forcément plus vite

L’argument préféré de notre client est la puissance : avec le meilleur modèle, tout devient possible. C’est l’intuition de tout le monde, et c’est justement ce que le laboratoire indépendant METR a voulu vérifier en 2025.

Leur protocole est simple et sévère : seize développeurs expérimentés, sur leurs propres projets open source qu’ils connaissent par cœur, 246 tâches réelles tirées au sort avec ou sans IA, avec les meilleurs outils du moment. Résultat : avec l’IA, ils ont mis 19 % de temps en plus. Le plus savoureux est ailleurs : avant l’étude, ils pensaient gagner 24 %, et après, ils restaient persuadés d’avoir gagné 20 %. L’étude de METR porte sur un petit échantillon et sur des outils de début 2025 ; ses auteurs le disent eux-mêmes et ne la généralisent pas. Mais elle montre une chose solide : l’impression de vitesse n’est pas la vitesse.

Même tendance à l’échelle des équipes. Le rapport DORA 2024 de Google, qui interroge chaque année des milliers de professionnels, a observé qu’une hausse de 25 % de l’adoption de l’IA allait de pair avec une baisse estimée de 1,5 % du débit de livraison et de 7,2 % de la stabilité (rapport DORA 2024). Plus de code, plus vite, et plus de choses qui cassent.

Et du côté des premiers concernés, l’enquête 2025 de Stack Overflow, auprès de plus de 49 000 développeurs, résume l’ambiance : 46 % ne font pas confiance à l’exactitude des réponses de l’IA, et la première frustration citée, par 66 % d’entre eux, ce sont les solutions « presque justes, mais pas tout à fait » (enquête Stack Overflow 2025). Le « presque juste » est le pire des défauts : il passe la démo et casse en production.

Cinquante agents, cinquante occasions de dériver

Passons à la skill magique qui transforme un projet en cinquante agents. L’idée a du charme : chacun sa tâche, tous en parallèle, et on récupère le résultat.

Dans la réalité, chaque agent interprète sa consigne, fait des hypothèses sur le travail des autres et corrige ce qu’il croit être une erreur de son voisin. Un modèle qui se trompe à 2 % par étape semble fiable ; enchaînez cinquante étapes et la probabilité que tout soit juste tombe à environ 36 %. C’est de l’arithmétique, pas de l’opinion. On a décrit ce mécanisme dans notre article sur le vibe coding : à chaque itération, le projet s’éloigne un peu plus de l’intention de départ, et personne ne s’en aperçoit tant qu’il n’y a pas un humain qui connaît le métier pour relire.

La vidéo « LGTM (Looks Good to Me) » qui circule en ce moment sur les réseaux le dit mieux que nous, en chanson : une demande de fusion de 40 128 lignes, « 0 fichier sur 312 consulté », et un tampon « ça me paraît bien » posé quand même. C’est la satire de la validation automatique, quel que soit l’assistant qui a écrit le code.

Il y a aussi l’histoire, publique, de l’agent de développement qui a effacé la base de production d’une startup en juillet 2025, pendant un « gel du code » qu’on lui avait explicitement demandé de respecter, avant d’affirmer que les données étaient irrécupérables (elles ne l’étaient pas). Le fondateur concerné, Jason Lemkin, l’a raconté en direct sur X, et l’éditeur de l’outil s’est excusé publiquement. Ce n’était pas un débutant ni un mauvais outil : c’était un agent à qui on avait laissé les clés sans garde-fou.

Le code généré coûte cher en sécurité

Un site WordPress avec un plugin IA qui génère le reste, c’est cumuler deux surfaces d’attaque. D’un côté, l’écosystème des plugins : selon Patchstack, éditeur spécialisé dans la sécurité de WordPress, 7 966 nouvelles vulnérabilités ont été recensées en 2024 dans cet écosystème, dont 96 % dans les plugins et non dans WordPress lui-même (rapport Patchstack 2025). On a raconté ce que ça donne dans l’article sur la faille PHP d’octobre.

De l’autre, le code produit par les modèles. Veracode a soumis plus de cent modèles à 80 tâches de programmation : 45 % du code généré contenait une faille de sécurité connue, et les modèles les plus récents ne faisaient pas mieux que les anciens sur ce point (rapport Veracode 2025). Veracode vend des outils d’analyse de code, ce qui ne rend pas le chiffre faux mais invite à le lire comme un ordre de grandeur.

Encore plus sournois : les modèles inventent des bibliothèques. Une équipe universitaire a mesuré qu’environ un paquet sur cinq recommandé par les modèles open source testés n’existait pas, et que les noms inventés revenaient de façon répétable (étude sur les paquets hallucinés). Un attaquant n’a plus qu’à publier un paquet piégé sous ce nom. L’heure de corrections du client ne couvre pas ce genre de chose, parce qu’on ne corrige pas ce qu’on ne sait pas voir.

Plus de code, pas forcément mieux

GitClear a analysé 211 millions de lignes de code modifiées entre 2020 et 2024. Avec la montée des assistants, les blocs copiés-collés ont été multipliés par huit environ, et la part de code qu’on remanie pour le réutiliser proprement s’est effondrée (étude GitClear 2025). Autrement dit, on produit plus de code, mais du code qu’on duplique au lieu de le concevoir. C’est la définition même de la dette technique : ça va vite aujourd’hui, et chaque modification coûtera plus cher demain.

Le vrai prix des cinquante agents

Dernier détail que la démo ne montre pas : la facture. Cinquante agents qui se relisent, se relancent et se corrigent avec le modèle le plus cher du marché, c’est des millions de tokens pour des tâches qu’un script de vingt lignes ferait en une seconde, gratuitement, et de la même manière à chaque fois. Renommer des fichiers, convertir un format, vérifier des liens, générer un sitemap : rien de tout ça n’a besoin d’intelligence, et encore moins de la plus chère. On l’explique en détail dans l’article sur la facture de l’IA : bien utilisée, l’IA se réserve aux tâches qui en ont besoin, et le reste tourne en code classique.

Le scénario de reprise qu’on rencontre le plus souvent est d’ailleurs toujours le même : un site « fait en un week-end » avec un assistant, puis le jour où il faut une deuxième langue, on découvre les textes en dur dans le code, un menu différent sur chaque page, et des modifications qui en cassent d’autres. Reprendre coûte alors plus cher que de bien faire dès le départ.

Pourquoi passer par des gens dont c’est le métier

L’IA ne rend pas l’expertise inutile, elle la rend plus rentable. Un expert avec un bon modèle va réellement plus vite, parce qu’il sait ce qu’il faut demander, et surtout ce qu’il faut refuser. Concrètement, ce qu’on apporte et que l’heure ne donnent pas :

• Le cadrage. Savoir ce que le site doit faire pour l’entreprise (leads, ventes, recrutement) avant d’écrire une ligne.
• La vérification. Relire ce que la machine produit, tester, mesurer la vitesse, l’indexation, l’accessibilité. Le « presque juste » ne passe pas.
• La sécurité et les données. Où partent les leads, qui y a accès, ce qui se passe quand un service tombe.
• Le bon outil au bon endroit. Un script là où un script suffit, un modèle léger là où il suffit, le plus puissant seulement quand il le faut.
• La suite. Un site se met à jour, se traduit, s’étend. Il doit être conçu pour ça, pas pour la démo. C’est aussi ce qui fait varier le prix d’une application.

La phrase « je peux le faire en 1h » n’est pas fausse, elle est incomplète. On fait une maquette en une heure. On fait un produit qui tient, qui se vend et qui ne vous réveille pas la nuit avec du métier, de la méthode et du temps humain. L’IA a raccourci le chemin, elle ne l’a pas supprimé.

Et si vous voulez vraiment tester les cinquante agents, faites-le : c’est un très bon exercice. Gardez simplement notre contact pour l’heure de corrections, ou regardez d’abord comment on développe une application.

Sources

1. L’étude de METR (nouvel onglet)metr.org
2. Rapport DORA 2024 (nouvel onglet)dora.dev
3. Enquête Stack Overflow 2025 (nouvel onglet)survey.stackoverflow.co
4. Rapport Patchstack 2025 (nouvel onglet)patchstack.com
5. Rapport Veracode 2025 (nouvel onglet)veracode.com
6. Étude sur les paquets hallucinés (nouvel onglet)arxiv.org
7. Étude GitClear 2025 (nouvel onglet)gitclear.com