La première saison de cette série a décrit un même déplacement : l'IA produit, l'humain spécifie, vérifie, décide. Cette deuxième saison s'ouvre sur une question très concrète, celle qui tombe dès le lundi matin — combien de temps cette tâche va-t-elle prendre ? Or la génération de code a fait s'effondrer un poste de l'addition : produire un premier jet ne coûte presque plus rien. La tentation est alors de diviser l'estimation entière par le même facteur. C'est le piège. Car ce que l'IA accélère — la production — n'est qu'une part de la tâche ; tout le reste, comprendre l'existant, réviser, intégrer, traiter les cas limites, tester, durcir, ne se comprime pas. Estimer, aujourd'hui, ce n'est plus chiffrer la frappe : c'est dimensionner le travail de vérification et d'intégration qui demeure.
Produire ne coûte presque plus rien — le reste, si
Commençons par le fait nouveau, celui qui bouscule tous les repères. Générer du code est devenu bon marché : une fonction, un module, une batterie de tests candidats s'obtiennent en quelques secondes. Le poste qui pesait le plus lourd dans une estimation — écrire les lignes — s'est réduit d'un facteur spectaculaire. Et c'est précisément ce qui fausse le calcul. Quand un seul poste de l'addition fond, l'esprit extrapole : si produire va dix fois plus vite, la tâche entière devrait aller dix fois plus vite. Sauf qu'une tâche de développement n'est pas faite que de production (Fig. 1).
Décomposez n'importe quelle tâche réelle et le premier jet n'en est qu'une tranche. Avant de produire, il faut comprendre le code existant qu'on va toucher. Après avoir produit, il faut réviser et vérifier la sortie, l'intégrer au reste du système, traiter les cas limites que personne n'avait en tête, tester pour de vrai, puis durcir — sécurité, gestion d'erreurs, charge, maintenabilité. Aucune de ces tranches ne se raccourcit parce qu'un modèle écrit vite. Elles relèvent du jugement, pas de la frappe. La conséquence est arithmétique : dès que la production devient quasi gratuite, ce sont ces parts incompressibles qui dominent le total. Diviser l'estimation entière par le facteur de la seule production, c'est chiffrer une tâche qui n'existe pas.
Ce volet porte sur une seule chose : estimer une tâche maintenant que produire est bon marché — séparer ce que l'IA accélère de ce qu'elle n'accélère pas, et déjouer la fausse vitesse de la démo. Deux sujets voisins vivent ailleurs. Le risque de livrer du code qu'on ne comprend pas — l'emprunt qui se paie plus tard — est traité dans la dette de compréhension : la conséquence, pas le chiffrage. La bascule d'identité du développeur, de producteur vers réviseur de référence, décrit le nouveau rôle, pas la manière d'en estimer la charge. Ici, ni la dette ni le rôle : on cherche à répondre à « combien de temps ? » quand la production ne pèse presque plus rien dans la réponse.
La démo fluide n'est pas la tâche finie
Le mécanisme qui fabrique la mauvaise estimation a un nom informel : la fausse vitesse. Un modèle produit en quelques minutes un rendu qui compile, s'exécute et « a l'air de marcher ». Cette fluidité crée un sentiment puissant — la tâche paraît réglée. Elle ne l'est pas : ce qui vient d'être montré, c'est un premier jet sur le cas heureux, pas un travail fini (Fig. 2). Entre la démo et le « fini pour de vrai », il reste tout le bloc incompressible : comprendre ce qu'on touche, réviser ligne à ligne, intégrer, éprouver les cas limites, tester, durcir. La démo n'a traversé aucune de ces étapes ; elle les a seulement rendues invisibles.
Ce n'est pas une impression subjective : l'écart entre vitesse ressentie et vitesse réelle a été mesuré. Une étude randomisée de l'organisme d'évaluation METR, « Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity » (juillet 2025, arXiv 2507.09089), a suivi seize développeurs expérimentés travaillant sur leurs propres dépôts — matures, volumineux, connus de longue date. Le résultat est contre-intuitif : « lorsqu'on autorise les développeurs à utiliser des outils d'IA, ils mettent 19 % de temps en plus pour résoudre les tickets — un ralentissement significatif ». Or ces mêmes développeurs anticipaient un gain de 24 % avant l'expérience, et croyaient encore, une fois les tâches terminées, avoir été accélérés de 20 %. Entre le ressenti — plus rapide — et la mesure — plus lent —, l'écart approche quarante points. La leçon n'est pas que l'IA ralentit toujours — nous verrons qu'elle accélère bel et bien certaines tâches — mais que le ressenti de rapidité n'est pas une mesure. Fonder une estimation sur l'impression laissée par une démo, c'est estimer avec la partie de la tâche qui trompe le plus. Le jugement du développeur sur ce qui reste à faire — voilà l'estimation ; pas la vitesse à laquelle le premier jet est apparu.
Estimer une tâche, ce n'est jamais chronométrer la frappe : c'est prévoir l'effort pour amener un changement jusqu'à un état livrable et défendable. Quand produire coûtait cher, la production dominait cette prévision, et l'estimer suffisait à peu près. Quand produire devient quasi gratuit, l'estimation se vide de son ancien contenu et se remplit d'un autre : le reste à faire — comprendre, réviser, intégrer, éprouver, durcir. Le chiffre que vous annoncez ne mesure plus le temps d'écrire le code, mais le temps de le rendre juste et sûr dans votre système. C'est un déplacement de ce qu'on compte, pas seulement de combien on compte.
Ce que l'IA n'accélère pas — et pourquoi le mesurer
Soyons honnêtes sur l'état des preuves : il est mitigé, et c'est justement ce qui éclaire l'estimation. D'un côté, l'accélération est réelle sur les tâches où la production domine. Un essai contrôlé de 2023 (Peng, Kalliamvakou, Cihon, Demirer, arXiv 2302.06590) a mesuré que le groupe équipé d'un assistant de génération de code « a accompli la tâche 55,8 % plus vite que le groupe témoin ». Mais la tâche était étroite et neuve — « implémenter un serveur HTTP en JavaScript le plus vite possible », à partir de zéro : de la production presque pure, sans base de code existante à comprendre ni à ménager. De l'autre, dès qu'on quitte ce terrain pour du code réel, complexe et déjà existant, le gain se dissipe — voire s'inverse, comme l'a montré l'essai de 2025 évoqué plus haut. Ces deux résultats ne se contredisent pas : ils décrivent les deux bords de la structure de coût. Là où la tâche est presque tout entière du premier jet, l'IA brille ; là où elle est dominée par la compréhension de l'existant et l'intégration, elle ne comprime rien — parce que ce n'est pas ce travail-là qu'elle fait.
Deux raisons de fond expliquent pourquoi le « reste » résiste. La première tient à la nature du travail de maintenance : on passe bien plus de temps à lire et comprendre du code qu'à en écrire. Une génération instantanée ne change rien à ce ratio ; elle ajoute même du code à lire. C'est le cœur de la dette de compréhension : produire vite ne dispense jamais de comprendre, et comprendre ne s'accélère pas. La seconde raison est économique et bien établie : un défaut coûte d'autant plus cher qu'on le rattrape tard. Le rapport de la NASA « Error Cost Escalation Through the Project Life Cycle » (Stecklein, Dabney, Dick, Haskins, Lovell, Moroney, INCOSE 2004) chiffre l'escalade — corriger une erreur d'exigences vaut « 1 unité » à sa naissance, « de 29 à plus de 1500 unités » en exploitation — et rappelle le résultat fondateur de Boehm : « trouver et corriger un problème logiciel après livraison peut coûter jusqu'à 100 fois plus cher » qu'au stade des exigences. Une estimation qui saute la revue, l'intégration et les tests ne supprime pas ce coût ; elle le repousse là où il est maximal. C'est le même argument qui fonde spécifier avant de générer : ce qu'on n'éprouve pas en amont se paie, majoré, en aval.
Reste un facteur humain qui pèse directement sur l'estimation : la sur-confiance envers la sortie automatique. Le profil « IA générative » du NIST (AI 600-1) la nomme précisément — « les humains peuvent trop se fier aux systèmes d'IA générative […] Ce phénomène est un exemple de biais d'automatisation, ou de déférence excessive envers les systèmes automatisés ». Appliqué au chiffrage, ce biais pousse à croire la démo sur parole et à rogner l'estimation de tout ce qu'on n'a pas vu échouer. D'où la valeur d'un réflexe simple : ce qui n'a pas été révisé, intégré et testé n'est pas fait — et doit donc figurer dans le chiffre, pas en être retranché parce qu'un rendu « avait l'air juste ». Éprouver la sortie fait partie du travail, comme le rappellent les tests à l'ère de l'IA.
L'erreur la plus commune consiste à prendre le temps d'apparition du premier jet pour le temps de la tâche. « L'IA me l'a sorti en cinq minutes, donc c'est cinq minutes » — et l'estimation s'effondre à un dixième du réel. Ce qui a pris cinq minutes, c'est la production d'un brouillon plausible sur le cas heureux ; ce qui reste, c'est tout ce que la démo n'a pas montré. Le symptôme est reconnaissable : une estimation qui a fondu d'un coup, portée par un sentiment de rapidité plutôt que par une décomposition du travail. La parade n'est pas de gonfler le chiffre au hasard, mais de déplacer ce qu'on compte : partir du reste à faire — comprendre, réviser, intégrer, éprouver, durcir — et non de la vitesse à laquelle le code est apparu.
- Estimez le reste, pas la frappe. Comptez la compréhension de l'existant, la revue, l'intégration, les cas limites, les tests et le durcissement : c'est là qu'est désormais l'essentiel de la charge.
- Ne divisez pas toute la tâche par le facteur de la production. Seul le premier jet se comprime ; appliquer sa réduction au total est l'erreur de base.
- Traitez la démo comme un signal, pas comme un résultat. Un rendu qui « marche » prouve un cas heureux, pas une tâche finie ; ne chiffrez jamais sur cette impression.
- Séparez explicitement « accéléré » et « inchangé ». Distinguez, dans votre estimation, la part que l'IA raccourcit de celle qu'elle ne touche pas — vous verrez laquelle domine.
- Pesez les inconnues à leur juste place. Le code existant que vous ne connaissez pas encore, l'intégration incertaine, les cas limites non explorés : ce sont eux qui font déraper les délais, pas l'écriture.
Estimer, c'est dimensionner la vérification
Ce premier volet de la deuxième saison retrouve le fil rouge de la série et le rend tangible : le métier glisse de produire vers spécifier et vérifier. L'estimation n'y échappe pas — elle change d'objet en même temps que le travail. Tant que produire dominait, chiffrer une tâche revenait à chiffrer l'écriture. Maintenant que l'écriture ne coûte presque plus rien, chiffrer une tâche revient à chiffrer sa vérification et son intégration. Le nombre que vous annoncez mesure de moins en moins le temps de faire apparaître du code, et de plus en plus le temps de le rendre juste, sûr et intégrable dans un système réel.
C'est pourquoi le jugement du développeur sur ce qui reste devient l'estimation elle-même. Personne d'autre — et surtout pas une démo fluide — ne peut dire combien coûtera de comprendre l'existant, d'éprouver les cas limites ou d'absorber les inconnues de l'intégration. La bonne question n'est plus « en combien de temps l'IA produit-elle ce code ? », mais « en combien de temps puis-je en répondre dans mon système ? ». Estimer à l'ère de l'IA, ce n'est pas revoir ses chiffres à la baisse au rythme de la génération : c'est déplacer ce qu'on compte, de la production vers tout ce qui, autour d'elle, ne se comprime pas.
- La thèse : produire est devenu bon marché, mais seul le premier jet se comprime ; l'estimation juste est celle du travail qui reste — comprendre, réviser, intégrer, tester, durcir.
- L'erreur de base : diviser toute la tâche par le facteur de la seule production. Le total baisse bien moins que ne le suggère la vitesse de génération.
- La fausse vitesse : la démo montre un premier jet sur le cas heureux ; on la prend pour la tâche finie. Le ressenti de rapidité n'est pas une mesure.
- Preuves mitigées, assumées : l'IA accélère les tâches où la production domine, mais un essai contrôlé de 2025 a mesuré des développeurs expérimentés plus lents sur leur propre code — exactement là où le « reste » domine.
- Le fil rouge : estimer, ce n'est plus chiffrer la frappe, c'est dimensionner la vérification et l'intégration — le jugement humain sur ce qui reste est l'estimation.
Ce qui se creuse quand on livre sans comprendre : la dette de compréhension. Le nouveau rôle qui rend la revue centrale : réviseur plutôt que producteur. Pourquoi l'intention précise décide du coût en aval : spécifier avant de générer. Ce que « tester » veut dire quand l'IA écrit aussi les tests : les tests à l'ère de l'IA. Et côté outils, une part concrète du « reste » à chiffrer : déboguer son code avec l'IA.
Premier volet de la deuxième saison de notre série « Le métier dev change avec l'IA ». Pour situer l'IA sans céder au discours magique, téléchargez l'Atlas IA 2026 et abonnez-vous à la newsletter AISKILLSPRO.
Au-delà de l'IA, retrouvez nos guides, tutoriels et modules Odoo sur OdooSkills, le blog Odoo ↗ (nouvel onglet).