Une agence a passé en revue 4 910 devis : on provisionne désormais 2,2 fois moins d'heures pour l'authentification

Quand les PDG affirment que l'IA écrit 20 %, 30 % ou même 90 % du code, le client n'a qu'une question : combien coûte désormais une application ? Sergueï Nikonenko, directeur d'une agence de développement mobile et web, a décidé d'y répondre en heures et en roubles. Il s'est appuyé sur des données internes : devis, temps saisis dans Jira et commits GitLab. Il n'a pas pris en compte les pourcentages de code généré.

Ce que montrent les devis

L'archive contient 4 910 devis, mais peu se prêtent à la comparaison : il faut des documents à la structure identique. L'authentification a pu être comparée dans 12 devis de 2025 et 19 devis de 2026. La médiane des heures prévues est tombée de 124 à 56, soit un facteur 2,2. La dispersion s'est aussi resserrée : la moitié centrale des estimations allait de 64 à 178 heures, elle va désormais de 24 à 70.

Le prix de l'heure a évolué plus modestement. Sur sept devis par année, le taux médian de développement est passé de 3 900 à 3 600 ₽, soit environ 8 %. L'auteur ne multiplie pas les deux médianes pour obtenir le prix d'une fonctionnalité : heures et taux proviennent d'échantillons différents, et un tel calcul exige des paires issues des mêmes devis.

En pratique, cela signifie qu'il est temps de revoir les tâches courantes dans les modèles de devis. Mais on ne peut pas inscrire dans le modèle le minimum de 12 heures pour l'authentification : sous un même intitulé d'epic se cachent des implémentations différentes selon les produits.

Jira et GitLab : des chiffres plus délicats

Le réel est plus compliqué. Respecter le devis ne dit pas grand-chose en soi. Une application mobile avec back-office est restée dans le budget à 100 % (1 359 heures sur 1 360). Un produit de développement personnel conçu autour de l'IA a atteint 101 % (520 sur 515), alors que le projet est toujours en cours. Mais il a été estimé en tenant déjà compte des agents : l'économie attendue a pu être déduite à l'avance, et 101 % ne dit pas si l'IA a aidé ou non. Un projet à périmètre croissant est monté à 182 %, mais il compte 23 réestimations, et c'est le budget initial qu'il faut comparer.

Autre problème de suivi : pour le service d'expéditions, Jira affichait 311 heures, alors qu'environ 120 heures de travail n'avaient pas été saisies dans le tracker. L'auteur les a ajoutées par estimation. Sans cette correction, l'économie paraîtrait plus belle, mais le calcul serait moins bon.

GitLab sert à repérer la participation des agents grâce au trailer Co-Authored-By: Claude dans le message de commit. Pour le site de cosmétiques, 92 % des 802 commits portent la mention de co-écriture par l'IA, et ils ont été faits par un seul développeur en 37 jours ouvrés. Dans l'application mobile, l'image est plus parlante : aucune mention avant juin 2026, puis presque dans chaque commit à l'automne.

Pourtant, le trailer ne témoigne que d'une co-écriture déclarée. Il ne dit ni combien de lignes l'IA a écrites, ni combien d'heures elle a fait gagner. Et si un développeur a utilisé l'IA sans mettre la mention, son travail reste invisible.

On ne peut donc pas qualifier de développement sans IA les projets dépourvus de trailers.

Coefficients finaux et leurs limites

Le résultat principal est le suivant : on divise le budget par les heures réelles. Pour le site de cosmétiques, on obtient environ 2,5× (594 heures de budget contre 240 réelles). Mais 594 correspond à 80 % des 742 heures initiales, et ces 80 % d'avancement ont été déclarés par le propriétaire du projet, sans vérification indépendante sur les tâches closes. Pour le service d'expéditions, 1 627 heures de budget contre environ 431 réelles donnent environ 3,8×. Dans sa conclusion, l'auteur a prudemment arrondi à 3× : c'est son choix, pas une borne statistique.

Il énumère lui-même les limites :

• Les projets n'ont pas été répartis aléatoirement entre travail avec et sans agents.
• Il n'y a que deux cas AI-first comparables aux anciens budgets. Tous deux web, en Next.js et Nest.js.
• Les chefs de projet sont exclus : ce sont donc des heures de développement, pas le coût de revient complet.
• Les délais calendaires de livraison n'ont pas été comparés.

Il existe aussi un contre-argument. Dans l'expérience randomisée de METR, des développeurs expérimentés équipés d'outils d'IA, travaillant sur des tâches open source familières, étaient 19 % plus lents. L'auteur ne prétend pas avoir réfuté cette étude : son type de comparaison est différent, et ses données n'expliquent pas pourquoi les résultats divergent.

Que faire de tout cela

Pour les équipes qui chiffrent des devis, la conclusion est pragmatique. Premièrement : revoyez les normes d'heures pour les tâches types comme l'authentification, et ne reportez pas automatiquement les anciens chiffres sur les nouveaux projets. Deuxièmement : ne promettez pas au client que tout coûtera plusieurs fois moins cher, car le prix de l'heure bouge bien plus lentement. Troisièmement : mettez en place un suivi correct. Si une partie du travail échappe au tracker, tout coefficient d'accélération sera enjolivé. Quatrièmement : ne prenez pas la part de commits marqués IA pour une mesure de productivité. Ce n'est qu'une trace dans l'historique du dépôt.

L'étude elle-même est honnête, car elle expose ouvertement ses faiblesses. Pour l'industrie, elle est utile comme exemple : comment vérifier sur ses propres données les affirmations sur une « accélération de plusieurs fois » sans faire passer une comparaison avec des devis pour une expérience contrôlée.