L’IA rend-elle un projet logiciel deux fois plus rapide ?

Rarement de bout en bout. Elle accélère l’écriture de code borné, mais cadrage, arbitrage, intégration, recette et mise en production gardent leur durée. Le gain global est donc une fraction du gain sur le code seul.

Que dit l’étude METR sur les assistants de code ?

Dans un essai contrôlé publié en juillet 2025, 16 développeurs expérimentés ont mis 19% de temps en plus sur 246 tâches avec l’IA, alors qu’ils pensaient gagner environ 20%. Le résultat vaut pour ce contexte précis, des outils du début 2025 et des bases de code qu’ils connaissaient bien.

Sur quelles tâches l’IA fait-elle vraiment gagner du temps ?

Sur les tâches bornées dont le résultat se vérifie vite : prototypes jetables, code répétitif, tests unitaires, documentation, refactorisation protégée par des tests.

Pourquoi un prix fixe convient-il mieux avec l’IA ?

Parce qu’il oblige à nommer les étapes incompressibles et à s’engager sur un périmètre, au lieu de vendre un gain de vitesse invérifiable facturé à l’heure.

Comment éviter un planning trop optimiste ?

Découpez par type d’étape, n’appliquez le gain IA qu’au développement, placez les dépendances externes en tête et mesurez le délai réel entre l’idée et la mise en production.

Ce que l’IA n’accélère pas dans un projet logiciel

Réponse directe : l’IA accélère l’écriture du code, pas le reste d’un projet logiciel. Comprendre le besoin, arbitrer, valider avec les utilisateurs, intégrer à des systèmes existants, relire et mettre en production restent des étapes aussi lentes qu’avant. Quand une seule étape devient rapide, les autres deviennent visibles : le goulot se déplace, il ne disparaît pas. Cet article liste les six étapes que l’IA ne compresse pas, ce qu’on peut raisonnablement attendre d’elle, et comment bâtir un planning qui n’intègre pas un gain imaginaire.

Nous livrons des produits avec des assistants de code tous les jours chez Tesseract Studio. Notre avis est donc celui d’utilisateurs, pas de sceptiques : l’outil est utile, mais le dire sans préciser où il ne l’est pas conduit à des budgets et des délais faux.

Pourquoi le code n’a jamais été le goulot d’étranglement

Dans un projet de quelques mois, l’écriture du code représente une part du temps, rarement la majorité. Le reste se passe en réunions de cadrage, en allers-retours sur les écrans, en attente d’un accès, d’un fichier de test ou d’une décision. Accélérer la part « écriture » de 30% ou de 50% ne raccourcit donc le calendrier que d’une fraction de ce gain.

C’est la logique d’une chaîne : sa vitesse est celle de son maillon le plus lent. Si l’on rend un maillon plus rapide, la file d’attente se forme juste avant le suivant. C’est ce que décrivent plusieurs analyses publiées en 2026 : l’IA expose des goulots déjà présents (spécification, tests, intégration, mise en production) plutôt qu’elle ne les crée.

Les mesures sérieuses sont moins flatteuses que les démos

Le meilleur point de repère public reste l’essai contrôlé de METR, publié en juillet 2025. Seize développeurs expérimentés de grands projets open source ont réalisé 246 tâches réelles, tirées au sort avec ou sans assistant IA. Résultat : 19% de temps en plus avec l’IA. Plus frappant encore, les développeurs prévoyaient un gain de 24% et, après coup, estimaient encore avoir gagné environ 20%.

Il faut lire ce résultat à sa juste portée. Les auteurs précisent qu’il concerne des développeurs expérimentés, des bases de code matures qu’ils connaissent très bien, et les outils du début 2025. Ils indiquent aussi que des mesures plus récentes, sur des outils de fin 2025, donnent des résultats différents. Ce n’est donc pas la preuve que l’IA ralentit, mais un avertissement solide : le ressenti de vitesse n’est pas la vitesse mesurée. Un planning bâti sur le ressenti sera faux.

Les six étapes que l’IA ne compresse pas

1. Comprendre le vrai besoin

Un assistant produit très vite ce qu’on lui demande. Il ne sait pas que la demande est mal posée. Savoir si l’on construit la bonne chose passe par des entretiens, des essais sur des cas réels et parfois par le constat que la fonctionnalité demandée n’est pas le vrai problème. Ce travail se fait avec des humains, au rythme des humains.

2. Arbitrer et décider

Quand on peut générer dix variantes d’un écran en une heure, la difficulté n’est plus de produire, mais de choisir. Plus d’options sans critère de choix rallonge la décision. Le bon réflexe est inverse : fixer le critère (conversion, délai, coût d’exploitation) avant de demander des variantes, et limiter à deux ou trois.

3. Relire et vérifier

Le code généré est presque toujours propre en apparence. L’erreur à chercher est la plausible : une règle métier oubliée, un test qui ne teste rien. La vérification coûte autant, voire plus, que si le code était écrit à la main, et elle ne se délègue pas à celui qui a généré. Nous avons détaillé ce changement dans la revue de code avec des assistants IA.

4. Intégrer à l’existant

Les contraintes qui font perdre du temps sont rarement dans le code neuf : une API d’un fournisseur qui répond mal, un export comptable aux champs surprenants, un accès à obtenir auprès d’un tiers, une règle d’un logiciel métier que personne n’a documentée. L’IA ne peut pas deviner ce qui n’est écrit nulle part. Pour les cas où des données réelles font échouer une automatisation, voyez notre article sur les automatisations IA face aux vraies données.

5. Valider avec les utilisateurs

Un utilisateur ne teste pas plus vite parce que le code a été écrit plus vite. Prévoir une semaine de retours reste une semaine. Les cycles de validation (recette, formation, correction des écarts, accord formel) suivent le rythme de l’organisation cliente, et l’IA n’y change rien.

6. Exploiter, sécuriser, maintenir

Mise en production, supervision, sauvegardes, droits d’accès, conformité à la loi suisse sur la protection des données (nLPD) quand des données personnelles sont traitées : ces tâches ne disparaissent pas. Plus on livre de code, plus il y a de surface à maintenir. Un code produit vite mais mal compris devient une dette que quelqu’un devra payer plus tard.

Ce que l’IA accélère vraiment

Il serait faux de conclure qu’elle ne sert à rien. Elle apporte un vrai gain sur les tâches bien bornées : prototypes jetables pour tester une idée, code répétitif, tests unitaires à partir d’un comportement décrit, documentation, refactorisation encadrée par des tests, exploration d’une base de code inconnue. Dans ces cas, le résultat est vérifiable rapidement, donc l’erreur coûte peu.

La règle que nous appliquons : l’IA est rentable là où la vérification est bon marché. Là où vérifier demande autant de travail que produire (logique métier subtile, sécurité, architecture), le gain s’efface. Notre méthode de livraison, décrite dans livrer un produit en 90 jours, repose sur cette distinction : on accélère ce qui se vérifie vite, on protège le temps de ce qui ne se compresse pas.

Un exemple chiffré, à titre illustratif

Prenons un projet fictif de douze semaines, réparti ainsi avant l’IA : deux semaines de cadrage, deux de conception, quatre de développement, deux d’intégration, une de recette, une de mise en production. Ces chiffres sont un exemple de raisonnement, pas une mesure.

Supposons que l’IA divise par deux la durée de développement, ce qui est une hypothèse généreuse. Le développement passe de quatre à deux semaines, et le projet de douze à dix semaines : un gain de 17% sur le calendrier, pas de 50%. Si, en plus, la relecture et les corrections absorbent une demi-semaine, on arrive à dix semaines et demie. Le gain réel dépend donc de la part du développement dans le calendrier initial, et de ce que la vérification reprend.

C’est aussi pourquoi la promesse « livré deux fois plus vite » doit toujours déclencher la même question : sur quelle étape, et avec quelle hypothèse sur les autres ?

Comment bâtir un planning honnête

Découpez le projet par type d’étape, pas par fonctionnalité : cadrage, conception, développement, intégration, recette, mise en production.
N’appliquez le gain IA qu’à l’étape développement, et sur une hypothèse prudente. Si l’on vous promet un projet deux fois plus rapide, demandez à quelle étape.
Placez les dépendances externes en tête du planning : accès, jeux de données, validations juridiques ou comptables.
Gardez des jalons de validation avec les utilisateurs à intervalles fixes, par exemple chaque semaine.
Mesurez le délai réel entre l’idée et la mise en production, pas la quantité de code écrite.

Étape	L’IA accélère-t-elle ?	Pourquoi
Cadrage du besoin	Peu	Dépend d’échanges humains et de cas réels
Arbitrage de conception	Non, parfois l’inverse	Plus de variantes, même nombre de décisions
Écriture du code borné	Oui	Résultat vérifiable rapidement
Relecture et tests	Peu	La vérification reste entière
Intégration à l’existant	Peu	Contraintes non documentées
Recette utilisateur	Non	Rythme du client
Exploitation et conformité	Peu	Responsabilité humaine

Cinq questions à poser à un prestataire qui promet un gain IA

Sur quelle étape exacte le gain porte-t-il, et quelle part du calendrier cette étape représente-t-elle ?
Qui relit le code généré, et combien de temps est prévu pour cette relecture ?
Quelles dépendances externes (accès, données, validations) sont identifiées dès le départ ?
Comment le délai sera-t-il mesuré : en lignes de code livrées ou en date de mise en production ?
Que se passe-t-il si le gain annoncé ne se matérialise pas : le prix change-t-il ?

Ce que cela change pour le prix

Si le coût d’un projet baisse, c’est surtout parce que le développement de base coûte moins, pas parce que tout va deux fois plus vite. Nous préférons un prix fixe sur un périmètre défini, car il oblige à nommer les étapes incompressibles. La logique est expliquée dans forfait ou régie. Pour voir comment cela se traduit concrètement, consultez nos formules et nos prix.

À retenir

Chiffrez le développement avec l’IA, mais ne lui attribuez pas le reste. Si votre projet a un calendrier serré, le plus utile est de nous décrire vos dépendances externes : c’est là que se joue le délai. Voyez aussi tous les articles du blog.