Construire un outil interne n’a jamais été aussi accessible. Un développeur assisté par un LLM livre un premier outil en un temps qui aurait paru irréaliste il y a trois ans, et savoir le faire n’est presque plus un sujet.
Reste une question moins confortable, celle qu’un DSI finit toujours par se poser : ce qu’on vient de construire, qui va le porter pendant cinq ans ?
Ce qui a vraiment baissé
Le coût de production du code, et la baisse est réelle. Jusqu’à 30 % du code de Microsoft est écrit par l’IA, selon Satya Nadella en avril 2025. Le coût d’inférence est passé de 20 dollars par million de tokens en novembre 2022 à 0,07 dollar en octobre 2024, à performance constante, soit une division par 280 d’après l’AI Index 2025 de Stanford HAI.
Contester ces chiffres ferait perdre la conversation dès le premier paragraphe. Écrire du code est devenu bon marché, et on ne reviendra pas en arrière.
La production de code est devenue une ligne budgétaire mineure. Ce n’est plus là que se joue le coût d’un logiciel.
Ce qui n’a pas baissé
Un logiciel ne coûte pas seulement le jour où on l’écrit. Il coûte chaque mois ensuite : les évolutions demandées par le métier, les montées de version des dépendances, l’infrastructure, la documentation, la montée en compétence de celui qui arrive quand l’auteur s’en va. Aucune de ces lignes ne diminue parce que le code a été produit plus vite.
Le mécanisme joue même dans l’autre sens. Quand produire coûte moins cher, on produit davantage, et chaque ligne ajoutée entre dans le patrimoine à porter. Un parc applicatif construit deux fois plus vite n’est pas deux fois moins cher à entretenir. Il est surtout plus gros.
Et ce qui a monté
La vérification. Le rapport DORA 2026 lui donne un nom, la taxe de vérification, et modélise une hausse du taux d’échec des changements de 5 % à 6 %. Il chiffre les gains à 35 à 40 % sur un projet neuf, mais à 10 % ou moins sur un existant complexe, selon la synthèse publiée par InfoQ en mai 2026.
L’édition 2025 du même rapport, près de 5 000 répondants, montrait déjà le mouvement. 90 % des professionnels de la tech utilisent l’IA au travail. 30 % disent lui faire peu ou pas confiance, et seuls 24 % lui font vraiment confiance. Son adoption est corrélée positivement au débit de livraison et négativement à la stabilité. DORA la décrit comme un amplificateur : une équipe solide devient meilleure, une équipe fragile devient plus fragile, plus vite.
Un dernier résultat refroidit les estimations trop optimistes. En juillet 2025, METR a mesuré que des développeurs open source expérimentés mettaient 19 % de temps en plus avec l’IA, alors qu’ils estimaient après coup avoir gagné 20 %. L’essai était randomisé, sur 16 développeurs et 246 tâches réelles dans leurs propres dépôts. L’échantillon est petit, il s’agit d’experts travaillant sur du code qu’ils connaissent par cœur, avec les outils de début 2025, et les auteurs demandent eux-mêmes de ne pas généraliser. METR a tenté de refaire l’étude début 2026 et y a renoncé, faute de pouvoir constituer un groupe témoin : trop de développeurs refusaient de travailler sans IA. Ce qui reste utile, c’est l’écart entre le gain ressenti et le gain mesuré.
L’IA n’a pas supprimé la charge, elle l’a déplacée vers celui qui vérifie.
Le test automatisé, cas d’école
Écrire un premier test Playwright ne coûte presque plus rien, et avec un LLM encore moins. Mieux vaut le dire avant que le lecteur le pense.
Écrire un test et exploiter un patrimoine de tests restent deux métiers différents. Le second suppose de tenir dans la durée l’exécution quotidienne, la stabilité, les données, les environnements, les navigateurs, le diagnostic des échecs, le reporting, la chaîne d’intégration, et les compétences de ceux qui font tout cela. L’instabilité à elle seule est un sujet d’ingénierie, même dans les organisations les plus matures : un test qui passe puis échoue sans que rien n’ait changé coûte du temps chaque fois qu’il faut décider s’il ment.
Générer les tests par IA ne règle pas ce second métier. Une étude publiée en mars 2026 a porté sur 22 374 variantes de programmes et huit modèles de langage. Les tests sont générés sur la version d’origine du programme, et ils passent. Puis le code évolue et son comportement change. Les tests virent au rouge, et plus de 99 % de ces tests rouges passent sur la version d’origine tout en exécutant la zone modifiée. Les auteurs parlent d’un alignement résiduel avec le comportement initial. Autrement dit, le rouge dit qu’une chose a changé, il ne dit pas si le changement est bon, et quelqu’un doit trancher test par test (Haroon, Khan, Gulzar, arXiv 2603.23443). L’étude porte sur la génération de tests, pas sur leur correction assistée : l’appliquer à la maintenance d’un parc est une analogie, pas une démonstration.
Chez nos clients, l’entretien du parc revient à environ 5 minutes par mois et par scénario. C’est une observation interne, pas une mesure publiée. Nous donnons l’unité plutôt qu’un total, à vous de la multiplier par la taille de votre parc. Ce que recouvre cette charge est détaillé dans notre article sur le coût de maintenance des tests automatisés.
Automatiser un test est devenu facile. Maintenir un parc de tests fiable dans la durée ne l’est pas.
Trois questions à se poser en interne
Savoir faire ne dit pas où investir. Ce qui compte, c’est de savoir si votre équipe veut placer là son expertise pour les cinq prochaines années. Maîtriser un sujet n’oblige pas à en construire et en porter toute la technologie.
- Combien de personnes savent réellement maintenir cet outil aujourd’hui ?
- Quelle part de leur temps va à le maintenir plutôt qu’à produire de la valeur ?
- Si votre patrimoine double, devez-vous doubler l’effort pour le porter ?
Si la réponse à la première est une seule personne, le sujet devient un risque de continuité avant d’être un choix technique.
Ce que ça change pour nous
Quand un scénario tombe, l’incident remonte avec la vidéo de l’échec, et vous pouvez demander à l’IA une proposition de correction. Elle repart de l’intention du test, de ce que le scénario est censé prouver, pas seulement de l’élément qui a bougé. Votre équipe valide.
Le partage des rôles est simple. Vous gardez ce qu’il faut tester, pourquoi, quel comportement est correct et quels risques sont critiques. C’est ce que nous appelons l’intention du test. Mr Suricate porte l’exécution, l’entretien, la supervision et le passage à l’échelle. Et comme chaque scénario s’exporte vers Playwright, rien de tout cela ne vous enferme.
Combien coûte vraiment votre parc de tests à entretenir ?
Voyez comment Mr Suricate tient un parc de scénarios dans la durée, et ce que votre équipe garde en main.
Questions fréquentes
L’écriture, souvent oui, surtout avec un LLM. Le calcul change quand on compte ce qui vient après : l’exécution quotidienne, la stabilité, les données, le diagnostic des échecs, la reprise du parc quand son auteur part. C’est ce coût de possession qu’il faut comparer, pas le coût d’écriture.
Elle fait baisser le coût de construction, c’est incontestable. Elle ne réduit pas le coût de possession, et elle ajoute une charge de vérification que le rapport DORA 2026 appelle la taxe de vérification. Le calcul reste à faire, mais sur la durée de vie de l’outil et plus seulement sur sa construction.
C’est ce que coûte un logiciel sur toute sa durée de vie, au-delà de sa construction : maintenance, évolutions, infrastructure, documentation, montée en compétence des équipes, et désormais vérification de ce qui est produit par IA. Sur un outil interne, c’est la ligne qui dure le plus longtemps.
Chez nos clients, l’entretien du parc revient à environ 5 minutes par mois et par scénario. C’est une observation interne. Multipliez-la par la taille de votre parc pour obtenir un ordre de grandeur, puis comparez avec le temps que votre équipe y consacre aujourd’hui.
Avec Mr Suricate, les scénarios s’exportent vers Playwright. Ce qui a été construit reste exploitable en dehors de la plateforme.
Gardez en interne ce qui fait votre expertise : ce qu’il faut tester, pourquoi, et quel comportement est correct. L’exécution, l’entretien et la supervision peuvent être portés par une plateforme, à condition que le parc reste exportable et que votre équipe garde la main sur ce qui est jugé correct.
