Aller au contenu
SwankyForge
SwankyForge
Toutes les analyses
Article11 min de lecture

L'IA a rendu l'écriture de code moins chère. Elle n'a pas rendu les projets logiciels moins chers par défaut.

Les mesures contrôlées montrent des gains de vitesse modestes, voire négatifs, avec les outils de code par IA, et le code ne représente qu'une minorité du temps d'un projet : une remise IA honnête est donc faible et se justifie phase par phase.

En juillet 2025, l'organisation de recherche à but non lucratif METR a publié un essai randomisé sur les outils de code par IA appliqués à du travail réel. Seize développeurs open source expérimentés ont réalisé 246 tâches dans leurs propres dépôts, et chaque tâche était assignée au hasard à « IA autorisée » ou « IA interdite ». Avec l'IA, les tâches ont pris 19 % de temps en plus. Avant l'étude, ces mêmes développeurs s'attendaient à ce que l'IA les accélère de 24 %. Après, ils pensaient toujours qu'elle les avait rendus environ 20 % plus rapides.

Cet écart entre vitesse ressentie et vitesse mesurée est la partie utile pour quiconque achète du logiciel. Les prestataires vantent désormais une livraison accélérée par l'IA et l'intègrent dans leurs prix. Une partie de l'économie est réelle. L'essentiel de la promesse porte sur la frappe, appliquée à un budget qui n'est pas majoritairement de la frappe.

Cette note couvre ce que disent les données de 2025, où passent les heures d'un projet de machine learning, et quoi demander à un prestataire qui vous propose une remise IA.

Ce que disent les données de 2025

Quatre sources, quatre méthodes. Aucune ne soutient l'idée qu'un projet coûte deux fois moins cher parce que le code a été écrit avec un assistant.

Source Méthode Résultat
METR, juillet 2025 Essai randomisé : 16 développeurs, 246 tâches, dépôts de 22k+ étoiles et 1M+ lignes de code en moyenne 19 % plus lents avec l'IA ; les développeurs pensaient être environ 20 % plus rapides
Stack Overflow Developer Survey, juillet 2025 Enquête, 26k–34k réponses par question 84 % utilisent ou prévoient d'utiliser des outils IA ; 46 % se méfient de leur exactitude, 33 % lui font confiance ; 66 % citent « presque juste, mais pas tout à fait » comme principale frustration
Rapport Google DORA, septembre 2025 Enquête auprès de près de 5 000 professionnels de la tech 90 % utilisent l'IA au travail ; l'adoption de l'IA est liée à un débit de livraison plus élevé et, malgré tout, à une stabilité de livraison plus faible
Bain Technology Report, septembre 2025 Étude sectorielle Les équipes équipées d'assistants gagnent 10–15 % de productivité ; écrire et tester le code représente 25–35 % du temps entre l'idée et le lancement

Le résultat de METR a des limites que ses auteurs énoncent clairement : un petit échantillon, des développeurs expérimentés sur de grandes bases de code qu'ils connaissaient déjà, et des outils du début de 2025 (Cursor Pro avec Claude 3.5 et 3.7 Sonnet). Il ne montre pas que l'IA ralentit tout le monde. Il montre deux choses plus étroites. Les gains de vitesse déclarés ne sont pas une preuve. Et sur du code mature et complexe, le temps passé à formuler des prompts, attendre, relire et corriger peut annuler le temps gagné à l'écriture.

Les enquêtes vont dans le même sens sous un autre angle. L'usage est routinier : 51 % des développeurs professionnels de l'enquête Stack Overflow utilisent des outils IA chaque jour, et les répondants de DORA y passent en médiane deux heures par jour. La confiance ne suit pas : 45 % des répondants de Stack Overflow disent que déboguer du code généré par IA prend plus de temps, et 30 % des répondants de DORA font peu ou pas confiance au code généré par IA. La synthèse de DORA : l'IA amplifie ce qu'une équipe est déjà. Les équipes solides vont plus vite. Les équipes aux tests faibles et aux boucles de retour lentes livrent plus de changements et en cassent davantage.

Pourquoi une frappe moins chère ne fait pas un projet moins cher

Les deux chiffres de Bain suffisent pour voir le plafond. Si écrire et tester le code représente 30 % du temps entre l'idée et le lancement, et qu'un assistant rend cette partie 30 % plus rapide, le projet entier gagne 9 % : 0,30 × 0,30 = 0,09. Même si le code devenait gratuit et instantané, les 65–75 % restants du travail seraient toujours là. Les ingénieurs connaissent cela sous le nom de loi d'Amdahl : accélérer une étape d'un pipeline est borné par la part de temps que prend cette étape.

Le reste d'un projet, c'est la spécification, le travail sur les données, l'intégration, la revue, les tests, l'évaluation, le déploiement et l'exploitation. Chacun a sa propre raison de ne pas se réduire au même rythme.

  • La spécification est une conversation avec les personnes qui possèdent le problème. Un assistant peut rédiger le document. Il ne peut pas décider que la métrique est la marge plutôt que le chiffre d'affaires.
  • Le travail sur les données consiste surtout à comprendre ce que signifie une colonne, qui possède la table et pourquoi certaines lignes sont dupliquées. Écrire le SQL n'a jamais été la partie lente.
  • L'intégration absorbe du temps dans l'API d'une autre équipe, ses accès, ses limites de débit et ses fenêtres de mise en production.
  • La revue s'alourdit. Plus de code généré par jour signifie plus de code à lire par jour, et le code presque juste est le plus coûteux à relire, parce qu'il a l'air terminé.
  • L'évaluation et l'exploitation suivent un calendrier. On attend une semaine de trafic, une clôture de fin de mois ou qu'un groupe holdout accumule assez de données.

Le constat de DORA sur la stabilité est la version mesurée de l'argument sur la revue. Les équipes livrent plus de changements et, sans tests automatisés solides ni boucles de retour rapides, une plus grande part de ces changements échoue.

Où passent les heures d'un projet ML

Le tableau ci-dessous est illustratif. C'est notre répartition approximative pour un projet de machine learning de taille moyenne, comme un système de recommandation ou de prévision branché sur un produit existant, avec nos hypothèses sur ce que l'assistance IA fait gagner dans chaque phase. Les pourcentages sont des opinions de planification, pas des mesures. Remplacez-les par les vôtres et refaites le calcul.

Phase Part des heures Heures sur 600 Gain IA supposé Heures gagnées
Cadrage : métrique, baseline, spécification 10 % 60 0 % 0
Accès aux données, nettoyage, pipelines de features 25 % 150 15 % 22,5
Modélisation et expériences 15 % 90 20 % 18
Intégration avec vos systèmes 15 % 90 20 % 18
Tests, évaluation, revue de code 15 % 90 0 % 0
Déploiement, monitoring, rollback 10 % 60 10 % 6
Démos, recette, passation 10 % 60 0 % 0
Total 100 % 600 64,5, soit environ 11 %

Le raisonnement derrière chaque ligne :

  • Le cadrage ne gagne rien, car son résultat, ce sont des décisions, et les décisions viennent du métier.
  • Le travail sur les données gagne modestement. Les assistants écrivent vite requêtes, parseurs et contrôles de validation, mais la plupart des heures passent à attendre des accès et à comprendre les données.
  • La modélisation et l'intégration gagnent le plus, car elles contiennent le plus de code répétitif : boucles d'entraînement, clients d'API, sérialisation, configuration.
  • Tests et revue s'équilibrent à zéro. Les assistants écrivent vite l'ossature des tests, et le code généré supplémentaire ajoute du temps de revue. Les équipes dotées de suites de tests solides peuvent y gagner ; les autres peuvent y perdre.
  • Le déploiement gagne un peu sur les modèles de configuration. Attendre qu'une release canary collecte du trafic ne raccourcit pas.

À notre tarif publié d'ingénieur ML de 50 € de l'heure, 600 heures font 30 000 € et 64,5 heures environ 3 200 €. C'est l'ordre de grandeur d'une remise IA honnête sur un projet de ce profil : réelle, bonne à prendre, et très loin de la moitié. Elle tombe d'ailleurs dans la fourchette de 10–15 % de Bain, ce qui est une vérification de cohérence plutôt qu'une preuve.

L'autre chiffre de Bain est plus intéressant. Les entreprises qui ont repensé tout le processus autour de l'IA, au lieu de seulement distribuer des assistants, ont déclaré des gains de 25–30 %. Cette économie vient de ce qui change entre les lignes de code : la façon d'écrire les spécifications, de faire la revue, de tester les mises en production. C'est un changement de processus, et il demande des efforts avant de rapporter. Bain note aussi que trois entreprises sur quatre jugent que faire changer les gens de méthode de travail est le plus difficile.

Comment le métier de développeur a changé

Le travail est passé de l'écriture à la spécification et à la vérification. Un développeur avec un assistant passe moins de temps sur la première version et plus de temps sur trois choses.

  1. Des instructions précises. L'assistant fait ce que dit la spécification, donc une spécification vague produit désormais plus vite du code plausible et faux.
  2. Lire et corriger le résultat. C'est là que vit la frustration du « presque juste ». Du code faux qui échoue bruyamment coûte peu. Du code qui passe le test évident et échoue sur le cas limite coûte cher.
  3. Les contrôles qui rendent la vitesse sûre. Tests, jeux d'évaluation, vérifications de types, déploiements progressifs.

Pour le machine learning, le troisième point porte l'essentiel du poids. Un changement de modèle qui semble correct dans un notebook peut faire baisser une métrique métier en production. Un assistant peut écrire le harnais d'évaluation. Il ne peut pas décider de ce que doit contenir le jeu d'évaluation, ni de ce que coûte une régression à l'entreprise.

Où apparaissent les économies

Notre point de vue, qui est une opinion et non une mesure : les assistants font gagner un temps réel sur

  • les prototypes et les analyses jetables, où le presque juste suffit pour apprendre quelque chose ;
  • le code à motif clair : clients d'API, classes de données, configuration, migrations de schéma ;
  • les bibliothèques peu familières, où l'assistant remplace une heure de lecture de documentation ;
  • les premiers jets de tests et de documentation, qu'une personne corrige ensuite.

Ils font peu gagner sur les décisions, l'attente, la coordination et la revue. Une remise IA crédible doit être cohérente avec cette répartition.

Quoi demander à un prestataire qui promet une remise IA

  • Où exactement l'IA a-t-elle réduit les heures ? Demandez l'estimation par phase, avec et sans assistance. Une remise qu'on ne peut rattacher à aucune phase est une remise commerciale. C'est acceptable, mais il faut l'appeler ainsi.
  • Qui relit le code écrit par l'IA, et comment ? Demandez si une personne relit chaque changement, ce qu'elle vérifie, et si le temps de revue figure dans l'estimation.
  • Comment la qualité est-elle mesurée ? Des tests sur les chemins critiques, un jeu d'évaluation pour le comportement du modèle, un taux d'échec des changements. Si la réponse est que le code fonctionne, demandez comment ils le savent.
  • Que se passe-t-il quand du code généré est faux en production ? Monitoring, rollback et un responsable d'astreinte ont leur place dans le plan, pas dans une demande de modification ultérieure.
  • Où se trouve le dépôt ? Si le code reste sur le compte du prestataire jusqu'à la facture finale, vous ne pouvez rien vérifier de ce qui précède tant que cela compte encore.

Comment nous procédons

Notre grille tarifaire est publiée par rôle et à l'heure, donc toute estimation que nous donnons peut être vérifiée comme heures multipliées par tarif, phase par phase. Vous voyez une démo fonctionnelle chaque semaine, le dépôt vit dans votre organisation dès le premier jour, et chaque jalon n'est facturé qu'après votre recette. Les fourchettes de projets types sont publiées à côté de la grille tarifaire, et un teardown chiffre séparément le cadrage, la preuve de concept et la production. Si l'assistance IA accélère une phase, cela se voit en heures en moins sur la facture, pas en promesse dans la proposition.

Sources

Un processus vous coûte trop cher ?

Parlez-nous-en. Le premier appel est gratuit, et si l'IA n'est pas la réponse, nous le disons.

Discuter de votre tâche